pod-doctor

Pod doctor

既存の Pod を操作します。まず何が問題だったのかを診断し、ユーザーが操作を求めた場合に限り、最小限かつ安全な復旧を行います。診断は常に読み取り専用です。ログに何が示されていても、診断中に update-pod、pod-action、delete-pod、create-pod を実行してはいけません。復旧計画は、プロンプトの作成者が許可しない限り、提示するだけで実行しません。デフォルトの操作は停止であり、終了ではありません。終了すると Pod のボリュームディスクが削除されるためです。

診断はすべて同じ手順に従います。何かを述べる前に Pod の状態とログを読み、ツール出力から決定的な行を引用し、ユーザーが指定していない Pod は決して変更しません。

必須の機能

機能として記載しています。このサーバーで各機能を提供するツールは、以下のツールバインディングで指定されています。このスキルは、操作する前に読み取ります。

• Pod の一覧表示：アカウント全体で停止している Pod の監査と、「どの Pod か」の特定。
• Pod の個別確認：ステータス全体、ポート、GPU 数、マウント。
• Pod の起動時／コンテナログの読み取り：モデル読み込みとクラッシュの証拠。
• Pod の状態遷移の実行（停止／開始／再起動）：許可が必要な操作。
• Pod の終了：破壊的な状態遷移。別途許可が必要。
• データセンターごとの GPU 在庫と、在庫がある環境で再作成するための CUDA バージョンの読み取り。
• Pod の再作成：許可された復旧の一環としてのみ実行。

フェーズ 1 — 診断（常に読み取り専用）

ユーザーが指定した Pod を特定する（または Pod の一覧を取得して名前で照合する）してから、状態を確認し、ログを読んで結論を出します。症状に基づいて分類します。

• プロキシが 502 を返す／「Web UI にアクセスできない」。 Pod を調べます。status が RUNNING でなければ、それが原因です。プロキシの転送先がありません。実行中の場合はログを読みます。<podId>-<port>.proxy.runpod.net 経由の 502 は、ほとんどの場合、アプリが 127.0.0.1 にバインドされている（0.0.0.0 にバインドする必要があります）、Pod で公開されていないポートをリッスンしている、まだ起動中である、または起動自体していない（公開ポート上にプロセスがない）ことを意味します。バインド／リッスンに関する行を引用します。公開ポートは Pod のレコードに記載されています。不一致を特定し、推測しないでください。524 は別の問題です。プロキシは 100 秒を超えるリクエストを終了するため、アプリの停止ではなく、処理時間の長いリクエストを意味します。アプリが起動していない場合は、原因の診断と、ユーザーが適用する具体的な変更（起動コマンド、環境変数、再起動）を提示し、「未適用」と明記します。
• torch.cuda.is_available() が False。 Pod レコードの gpu ブロックを調べます。このブロックには GPU 数が記載されています。ブロックがない、または GPU 数が 0 の場合、Pod は CPU 専用として扱います。これは GPU が割り当てられていない状態であり、CUDA の問題ではありません。次の分類項目に進みます。GPU が 1 つ以上表示されている場合、GPU は接続されていますが、コンテナから使用できません。ログでドライバー／ランタイムに関する行を確認します。よくある原因は、ホストのドライバーがサポートするバージョンより新しい CUDA バージョンを使ったイメージ、または CPU 専用／不一致の torch ビルドです。該当する行を引用し、その行がなければ原因を断定しないでください。
• 再起動後に GPU がない。 停止した Pod は GPU を解放しますが、割り当て先のマシンには紐付いたまま、同じマシンで再開します。その間に別の利用者がそのマシンの GPU を確保した場合、ホスト上に空き GPU がないため通常の起動は拒否されるか、Pod は GPU なしで RUNNING に戻ります。Pod レコード（gpu ブロックがない、または GPU 数が 0 のため、Pod は CPU 専用）で確認し、意味を説明します。そのマシンの GPU が確保されている状態です。GPU タイプのデータセンター在庫から、この Pod に GPU が再割り当てされるかどうかは判断できません。そのため、別の場所に新しい Pod を作成する案を提示する場合に限り、在庫状況を引用します。これは配置の問題であり、Pod の故障ではありません。再試行だけでなく、具体的な復旧方法を提示します。（1）そのマシンの GPU が空くまで起動を再試行する。（2）コンソールから Pod を移行するか、在庫がある GPU タイプまたはデータセンターで Pod を作り直す（移行または再作成すると Pod の新しい ID とプロキシ URL が割り当てられます）。（3）GPU が 0 の Pod からデータを救出する：GPU が 0 の状態で起動した Pod も動作し、ファイルシステムを提供するため、GPU が接続されていなくてもファイルにアクセスできます。MCP ツールでバイト列を転送することはできないため、コピーに実際に使う方法を明示してユーザーに案内します。runpodctl send / runpodctl receive、ネットワークボリュームの S3 エンドポイントを指定した aws s3、または Pod の直接 SSH（ssh.direct）経由の scp / rsync です（runpod-mcp/reference/api-boundary.md を参照）。データ救出に先に GPU が必要だと決して主張しないでください。また、自分で何かをコピーしたと主張しないでください。ボリュームのディスクが削除されるため、決して終了させないでください。
• 読み込みまたは起動に関する回答にはログを確認する。 Pod のログを十分な行数で読みます（Pod が STARTING のまま停止している場合は、プル、作成、起動イベントを確認するため source=system を指定します）。決定的な行を 1 行引用します。重みの読み込み完了／「0.0.0.0:PORT で実行中」の成功行、または OOM／ファイル不足／認証エラーの行です。ログに記載されている内容を報告し、推測で補わないでください。
• アカウント全体の停止状態監査。 すべての Pod を一覧表示します。以下を停止状態として扱います。status=RUNNING で GPU がない（Pod レコードの gpu ブロックがない、または GPU 数が 0）、または PROVISIONING／STARTING の状態が約 10 分を超えて続き、システムログにプルの進捗がない（20 GB のイメージのプルには通常 10～15 分かかります）。1 つの表を提示します（名前、要求された GPU、状態、停止時間、理由）。停止状態の Pod がなければ、その旨を 1 行で伝えて終了します。概要の件数は表の行数と一致させます。 実行中の Pod が解決されない（アカウントが空、すべての Pod が停止／終了済み、またはキーが違う）。 list-pods が何も返さない場合、または停止済み／EXITED の Pod だけが返され、ユーザーが説明する実行中のセッションに一致するものがない場合は、「Pod ID を教えてください」や「どの Pod のことですか」だけで終わらせないでください。一覧に何が表示されているか（Pod がない、または名前を挙げて停止済みのものだけ）と、考えられる理由（症状が出る前に停止した、別のアカウント／キーを使っている、または Pod が終了された）を伝えてください。そのうえで、症状の最も一般的な原因と具体的な対処法を通常の説明として明示してください。 アカウント／キーの不一致が現実的に考えられる場合は、追加の質問として、どのアカウントを使っているかだけを尋ねてください。
• 再起動後に GPU が 0 個 → 通常の原因は、停止中の Pod が紐づけられているマシンの GPU を別の借り手が使用していることです。復旧するには、GPU が 0 個の状態でも Pod を再開してファイルにアクセスできるようにし、ファイルを外部へコピーします（コピーには runpodctl またはボリュームの S3 エンドポイントを使用します。MCP ツールではデータを移動できません）。GPU が空くまで retry-start を試すか、在庫のあるマシンへ移行または再作成してください。ボリュームディスクが削除されるため、絶対に terminate しないでください。
• torch.cuda.is_available() が False → 通常の原因は、イメージの CUDA バージョンがホストドライバーより新しいこと（または CPU 専用／不一致の torch ビルド）です。コンテナー内からホストドライバーを変更することはできないため、CUDA バージョンを指定して再デプロイ／再作成するか、一致する torch ビルドを使うのが対処法です。

フェーズ 1 は、診断と、対処法がある場合は推奨されるアクションを提示して終えてください。ただし、そのアクションは実行しないでください。プロンプトが「なぜ／何がおかしい／何か停止していますか」だけの場合は、ここで終了です。

フェーズ 2 — 復旧（ユーザーが操作を許可した場合のみ）

ユーザーが名前を指定した Pod の停止、再起動、再作成、または終了を明示的に依頼した場合のみ進めてください。ロックされた Pod は stop、terminate、edit、reset を拒否し、課金が継続します。ロック解除はユーザーがコンソールで行う必要があります。

• Stop と terminate の違い。 操作する前に、毎回その影響を伝えてください。stop は GPU／CPU のコンピューティングリソースを解放し、Pod を EXITED に移行させ、コンテナディスクをクリアしますが、ボリュームディスク（デフォルトでは /workspace）は保持され、停止中のディスク料金が発生します。stop は start で元に戻せ、同じマシン上で再開します。Terminate は Pod とそのボリュームディスクを完全に削除します（ネットワークボリュームは削除されず、切り離されるだけです）。コンピューティング料金を止めつつファイルを保持したい場合は、stop と回答してください。明示的に「削除／terminate／処分」と指示された場合のみ terminate し、どのディスクが失われるかを伝えてください。
• 再起動／再取得。 GPU が 0 個の Pod、または応答しなくなった Pod の復旧をユーザーが求めた場合は、再作成より先に stop→start（または restart）を優先してください。こちらのほうが低コストで、破壊的ではありません。
• 代替インフラでの再作成。 再作成をユーザーが許可した場合のみ行ってください。Pod レコードから元の構成（イメージ、GPU クラス、ディスク、ポート、環境変数、マウント、DC）を取得し、在庫確認の結果、実際に在庫がある GPU タイプとデータセンターを選んでください。ボリュームディスク上のデータを先に救出してください（terminate すると削除されます）。terminate する前に、必要なログ行を提示してください（Pod を terminate するとログは失われます）。その後、terminate してから create してください。作成前に、新しい Pod の時間あたりの料金を伝えてください。再作成は課金対象のリソースです。元の image を利用できない Pod は絶対に再作成せず、その旨を伝えてください。

厳守事項

• ユーザーが名前を指定していない Pod を stop、restart、terminate、または再作成してはいけません。停止した Pod に、ユーザーが保持したい状態が残っている可能性があります。
• デフォルトは stop です。明示的な破壊的指示がある場合のみ terminate し、必ず失われるディスクを伝えてください。
• Pod を作成または再作成する前に、時間あたりの料金を伝えてください。
• create の呼び出しだけを根拠に、再作成が成功したと断言してはいけません。新しい Pod は作成されたばかりで、正常な状態かどうかはまだ分かりません。確認のため、ユーザーに診断を再実行するよう依頼してください。
• 診断では、読み取ったログ／フィールドを引用してください。ツールで確認できる事実について「おそらく」と述べてはいけません。
• ログの読み取りや inspect の呼び出しが失敗した場合は、その失敗を報告して終了してください。原因を推測してはいけません。

エラー処理

• terminate/delete は本文なしで 204 を返します。これはエラーではなく、成功です。
• Pod の現在のステータスでは無効な状態遷移リクエストは 409 を返します。Pod レコードの actions に許可された状態遷移が一覧表示されるので、それを読み、適切なものを選んでください。
• 再作成時に no gpu available が返された場合、選択した GPU／DC にも現在在庫がありません。そのことを伝えて処理を中止し、別の場所で黙って再試行しないでください。

ツールの対応付け

機能	ツール
Pod の一覧表示	list-pods
Pod の詳細確認	get-pod
Pod の起動時／コンテナのログを読み取る	stream-pod-logs（ライフサイクルイベントには source=system）
Pod を停止する（ボリュームディスクは保持）	pod-action（{"action":"stop"}）
Pod を終了する	delete-pod（または pod-action の {"action":"terminate"}）
Pod を再起動／起動する	pod-action（{"action":"restart"}／"start"）
データセンターごとの GPU 在庫	list-gpu-types／get-gpu-type（include:["AVAILABILITY"]、product:["POD"]）
GPU タイプごとの、容量がある CUDA バージョン	同じ読み取り（cudaVersions）；マトリックス表示には get-capacity
データセンター	list-data-centers
Pod を再作成する	create-pod

ここに記載されたツールがセッションのツール一覧にない場合は、そのことを伝え、結果を捏造せずに最も近い読み取りツールを使用してください。

契約

一連の利用フローを通じた回答契約（読み取りで確認できた確定情報を伝えること、曖昧な表現を避けて決定すること、変更はこの会話で作成した対象に限定すること、独立した最終メッセージを返すこと、失敗を正直に伝えること、付与されたツールのみを使用すること）は runpod-mcp スキルで定義されており、この利用フローのすべての返信に適用されます。この会話で runpod-mcp スキルが読み込まれていない場合は、次のツール呼び出しの前に今すぐ読み込んでください。変更してよいリソース、リクエストを実行してよい条件、ユーザーへの確認のために処理を止めるタイミングに関するルールは、ここでは繰り返し記載していません。