初回開通
接続情報が未確認
注文直後に、モデル、ノード、ホストアドレス、ログイン方法、初期ネットワーク状態を確認したい場合に適しています。
開通時の確認項目を見る
開発タスクのサポート
まず状況を保存し、タスクの流れに沿って原因を特定
接続失敗、ビルドエラー、性能低下は通常それぞれ異なる問題です。PingMiniでは開通、アクセス、ツールチェーン、タスク実行、ストレージ、アカウントの6つの経路で確認事項を整理し、各ステップに入力、確認操作、検証可能な結果を用意しています。
- 6つの入口
- 現在のタスクに合う経路を選択
- 5つのコンテキスト
- 注文、ノード、時刻、エラー、手順
- 2つの連絡方法
- コンソールチケットまたはサポートメール
BUILD SUPPORT BOARD
タスクの状況を振り分け
トラブルシューティングの準備
ACCESS
アドレスとフィンガープリントを確認
ネットワーク
XCODE
バージョンを固定してビルドを再実行
ログ
RUNNER
失敗したタスクのディレクトリを分離
タスク
STORAGE
容量とキャッシュの増加を確認
容量
発生時刻と最後に正常だった状態を記録
CASE READY
入口を選ぶ
エラーコードではなく、実行中のタスクから始める
現在の停止箇所に最も近い入口を選びます。各経路には保存すべき情報と次の操作を示しています。複数の経路にまたがる場合は、最初に異常が発生した箇所から確認します。
リモート接続
セッション、ネットワーク、認証情報の異常
グラフィカルデスクトップ、SSH、ホストフィンガープリント、接続タイムアウト、キーボード配列、クリップボードポリシーの問題に使用します。
接続経路を確認
開発環境
Xcodeとツールチェーンが一致しない
バージョン切り替え、コマンドラインツール、証明書とプロビジョニングプロファイル、依存キャッシュ、ビルドログの確認に使用します。
ツールチェーンの確認へ
CI/CD
セルフホストタスクの実行失敗
タスク登録、作業ディレクトリ権限、キーチェーンアクセス、同時実行ポリシー、失敗タスクの回収までを一連の流れとして確認します。
タスク実行フローを確認
ストレージと性能
容量が増える、またはタスクが遅い
システムディスク、追加SSD、ビルドキャッシュ、プロジェクトデータを区別し、容量の問題を計算性能の問題と取り違えないようにします。
容量計画を見る
アカウントと注文
注文、更新、権限の確認が必要
注文番号、ノードコード、発生時刻、操作範囲を準備し、コンソールからサービス状況に関連付けた依頼を送信します。
サポート依頼を準備
初回利用の流れ
4つの確認で再現可能な出発点を作る
初回接続時に、プロジェクトの移行、ツールチェーンの変更、自動化タスクの追加を同時に行わないでください。まずノード、認証情報、ネットワークが利用できることを確認し、その後で開発環境を段階的に追加します。
-
01
結果：必要な項目がそろっている
接続情報を取得
コンソールで該当する注文を開き、ホストアドレス、接続方式、アカウント名、ノードコードを記録します。スクリーンショットだけでなく、注文番号と接続情報をチームで管理できる引き継ぎ記録に保存してください。
-
02
結果：構成が一致
ノードとモデルを確認
注文のノード、チップ、メモリ、SSDが用途に合っていることを確認します。カタログの3構成は、M4 / 16GB / 256GB、M4 / 24GB / 512GB、M4 Pro / 64GB / 2TBです。
-
03
結果：再ログインに成功
初回ログイン後に認証情報を変更
まず最小限のセッションを確立し、デスクトップまたはコマンドラインに入れることを確認してから初期認証情報を変更します。変更後はすぐにログアウトして再接続し、新しい認証情報が有効であることを確認します。
-
04
結果：ベースラインを再現可能
ネットワークと基本コマンドを確認
DNS名前解決、コードリポジトリへのアクセス、依存パッケージソースへの接続を確認し、システム状態を変更しない基本コマンドを1つ実行します。後で経路の問題を切り分けられるよう、ローカルネットワーク、クライアント、失敗時刻を記録します。
Xcodeとツールチェーン
「ビルド失敗」をバージョン、権限、キャッシュ、ログに分解
同じコードが環境によって異なる結果になる場合は、まずツールチェーンの入力を固定します。Xcodeのアップグレード、キャッシュ削除、偶然の成功による解決判断を同時に行わないでください。
推奨確認順序
VERSION
現在のXcodeとコマンドラインツールを確認
バージョン記録
グラフィカル版のバージョン、ビルド番号、コマンドラインツールの実際の参照先を記録します。プロジェクト、スクリプト、CIは同じ確認済みツールチェーンを参照してください。
SIGNING
証明書とプロビジョニングプロファイルの範囲を確認
権限範囲
ファイルの存在と権限、CI実行アカウントが必要なキーチェーンにアクセスできるかを確認し、失敗が解析、アーカイブ、署名のどの段階で起きたかを記録します。
CACHE
キャッシュを層ごとに削除
単一変数で再テスト
まずプロジェクトのDerived Dataを削除し、次にパッケージマネージャーのキャッシュを処理します。広範囲の環境クリーンアップは最後に行い、毎回1つの層だけ変更して同じビルドを再実行します。
LOG
最初の本当のエラーを残す
完全なログ
完全なログから最も早い失敗手順、コマンド、ターゲット、終了コードを特定します。最後の要約行だけをコピーしないでください。
送信前に保存
連絡情報の要件を見る
最小ビルド証拠パッケージ
- Xcodeとコマンドラインツールのバージョン
- プロジェクトのターゲットと失敗段階
- 完全なコマンド、終了コード、ログ抜粋
- 最後に成功したビルドとの差分
誤判定を避ける
ワークフロー事例を見る
環境を一度にすべて変更しない
バージョンのアップグレード、依存関係の再インストール、キャッシュ削除、署名素材の交換を同時に行うと、ビルドが復旧しても本当の原因を特定できません。1回の検証で変更する入力は1つだけにします。
CI/CDのトラブルシューティング
まずランナーの健全性を確認し、失敗タスクを再実行
自動化の失敗は、登録状態、実行アカウント、作業ディレクトリ、キーチェーン、同時実行の競合が原因かもしれません。タスクのライフサイクルに沿って確認し、ランナーの再登録を繰り返して根本原因を隠さないようにします。
タスクの登録状態を確認
ランナーがオンラインか、ラベルが一致しているか、実行アカウントが想定どおりかを確認します。タスクが取得されない場合は、ツールチェーンを再インストールせず、まずキューのルールとラベルを確認します。
- 入力
- ランナー名、ラベル、キュー状態
- 受け入れ条件
- 最小テストタスクを取得できる
ディレクトリとキーチェーンの権限を確認
実際の実行アカウントで作業、キャッシュ、成果物の各ディレクトリの読み書き権限を確認し、ビルドに必要なキーチェーンへアクセスできることも個別に検証します。
- 入力
- 実行アカウント、ディレクトリパス、権限結果
- 受け入れ条件
- 権限昇格なしで最小ビルドを完了できる
同時実行を制限し、残留物を回収
同時実行数を管理可能な範囲まで下げ、残留プロセス、ロックファイル、一時ディレクトリ、未完了のアーカイブを確認します。失敗タスクの終了後は、環境を使い続けるのではなく、明確な回収方針に従います。
- 入力
- 同時実行数、プロセス一覧、ディスク使用量
- 受け入れ条件
- 連続再実行しても結果が一致
登録状態は正常
権限が明確
単一タスクに成功
同時実行を段階的に戻す
SSHでMacに接続
鍵、フィンガープリント、ネットワーク、権限を個別に確認
接続タイムアウトと認証失敗は異なる段階の問題です。まずネットワークがホストに到達できることを確認し、次にホストのフィンガープリントと鍵の権限を確認して、最後に非対話コマンドを検証します。
最小接続フロー
明示的なパラメータでクリーンなセッションを1回確立
- 鍵を準備：現在の用途専用の鍵を作成し、秘密鍵ファイルの権限を制限します。同じ秘密鍵を複数人でコピーして使用しないでください。
- フィンガープリントを確認：初回接続前に、信頼できる注文情報からホストアドレスを照合します。フィンガープリントが変わった場合は接続を停止し、原因を確認します。
- タイムアウトを確認：ローカルネットワーク、出口ポリシー、ホストアドレス、ポートを確認し、タイムアウトをパスワードエラーと誤判定しないでください。
- 権限を最小化：タスク完了に必要な最小限のアカウント権限を使用し、非対話コマンドで自動化が利用できることを検証します。
ssh -i ~/.ssh/pingmini_ed25519 user@host
ssh -i ~/.ssh/pingmini_ed25519 user@host "uname -a"
接続タイムアウト
出力：経路の結論
到達経路を確認
ローカルネットワーク、ホストアドレス、ポート、発生時刻、クライアントエラーを記録します。まずネットワーク到達性を確認してから、認証を確認します。
認証に失敗
出力：権限の結論
鍵とアカウントを確認
使用した秘密鍵、対象アカウント、ファイル権限、サーバー側の許可範囲を確認します。不確かな認証情報を連続して試さないでください。
ストレージと性能
どの種類のデータが増えているかを特定
システムディスク、追加SSD、プロジェクトデータ、ビルドキャッシュではライフサイクルが異なります。容量計画では、現在のプロジェクト、ピーク時のビルド、アーカイブ成果物、利用期間終了前の移行用スペースを同時に考慮します。
| ストレージカテゴリ | 適した内容 | 重点的に確認 | 推奨アクション |
|---|---|---|---|
| システムディスク | OS、ツールチェーン、必要なアプリ、基本設定 | 空き容量、一時ファイル、ツールチェーンのバージョン数 | アーカイブ成果物を長期保存せず、安全余裕を確保 |
| 追加SSD | 大規模プロジェクト、素材、モデル、ビルド成果物、チーム引き継ぎデータ | 継続的な書き込み量、プロジェクト単位のピーク、移行時間 | アクティブデータとアーカイブデータをディレクトリで分けて管理 |
| ビルドキャッシュ | Derived Data、依存キャッシュ、再生成可能な中間ファイル | ヒット率、増加速度、失敗タスクの残留物 | 回収ルールを設定し、唯一のプロジェクトデータと混在させない |
| プロジェクトデータ | コード、設定、素材、テストデータ、最終納品ファイル | 独立したコピー、権限範囲、引き継ぎ責任者の有無 | プロジェクトごとにバックアップと利用期間終了前の移行リストを作成 |
空き容量と1日の増加量を記録
プロジェクトを取り込む前に初期使用量を記録し、通常運用後に標準的な稼働日の増加量を記録します。2つのデータから、継続的な増加、突発的なアーカイブ、失敗タスクの残留を判断できます。
入力、中間ファイル、成果物を同時に収容
動画変換、大規模アーカイブ、モデルテストでは、ソース、中間ファイル、出力結果を同時に保持する場合があります。最終成果物のサイズだけで容量を選ばないでください。
ディスク負荷と計算負荷を区別
タスク所要時間、空き容量、同時実行数、キャッシュ状態を記録します。容量上限への接近、頻繁な削除、複数タスクによる同一ディレクトリの競合は、いずれもタスクの遅延として現れることがあります。
セキュリティ対応フロー
異常を見つけたら、まずアクセス範囲を絞る
認証情報の漏えいが疑われる場合、異常なログイン、メンバーの引き継ぎ、利用期間の終了は異なる4つの状況ですが、いずれも拡散停止、記録保存、アクセスのローテーション、クリーンアップ確認の順に対応します。
関連アクセスを一時停止
認証情報の共有を止め、不要なセッションを終了し、影響を拡大する可能性のある自動化タスクを一時停止します。状況を記録する前にログを広範囲に削除しないでください。
異常のコンテキストを記録
注文番号、ノード、発見時刻、異常の発生源、影響を受けたアカウント、最後に正常だった操作を整理し、必要なクライアントとタスクのログを保存します。
認証情報と鍵をローテーション
影響を受けたログイン認証情報、SSH鍵、自動化用アクセス素材を交換し、不要になったチームメンバーの権限を取り消します。一部だけ変更して古い鍵を使い続けないでください。
確認してクリーンアップを完了
必要なアクセスを再テストし、古い認証情報が無効になったことを確認します。プロジェクトの引き継ぎまたは利用期間終了前に、プロジェクトデータ、ビルド成果物、鍵、証明書素材を移行し、チェックリストに沿ってノードを整理します。
サポートへのエスカレーション経路
十分な情報を添えて、すぐに調査へ進める
一般的な相談とサービス利用中の問題は、影響度と実行可能なコンテキストに応じて対応します。情報がそろっているほど、基本項目の確認にかかる往復を減らせます。
送信前にそろえる5つの情報
注文番号
モデル、利用期間、サービス記録との紐付けに使用します。
ノードコード
注文と一致するSG、JP、KR、HK、US-Eのいずれかを記入します。
発生時刻
タイムゾーンを明記し、最後に正常だった操作の時刻も追加します。
エラー情報
完全なテキスト、終了コード、最初の失敗箇所を保存し、切り取ったスクリーンショットだけを送らないでください。
再現手順
動作する状態を起点に、コマンド、入力、期待する結果、実際の結果を順番に記載します。
サービス利用中の問題
ログインしてチケットを送信
まずコンソールチケットを利用
注文、ノード、接続、実行中のタスクに問題がある場合、コンソールチケットを使うと依頼をサービス記録に関連付けられます。
一般的な相談
サポートメールを送信
共通のサポートメールを利用
プラン選定、チーム購入、請求、提携に関する相談は support@pingmini.com へ送信し、用途と希望する結果を添えてください。
接続に失敗した場合、スクリーンショットとテキストエラーのどちらを先に送るべきですか？
コピー可能な完全なエラーテキスト、クライアント名、発生時刻、操作手順を優先して送ってください。スクリーンショットは画面状態の補足にはなりますが、ホストアドレスの確認、終了コード、ネットワーク段階の判断の代わりにはなりません。
ビルドが時々成功するなら、ノードは正常に戻ったと考えてよいですか？
1回の成功だけで判断しないでください。Xcodeのバージョン、同じコードコミット、同じ依存関係、同じ同時実行条件を固定して連続再実行し、成功と失敗の入力差分を記録してください。
タスクが遅くなったら、すぐにモデルをアップグレードすべきですか？
まずCPU、メモリ、空き容量、キャッシュ状態、同時実行数、タスク段階を記録します。ボトルネックが容量不足、ディレクトリ競合、失敗タスクの残留にある場合、構成を変更するだけでは原因を解消できません。
次のステップ
コンテキストを準備して、問題をサポートチームに引き渡す
まだモデルを選定中なら、まず3つの固定構成を確認してください。サービスを開通済みの場合は、注文番号、ノード、時刻、エラー情報、再現手順を添えてチケットを送信します。