前任者は「ネットワーク障害」と書いた。4つのAIに渡したら、3つが未確認の復旧まで報告した
障害の引き継ぎには、ときどき「事実」と「前任者の推測」が一緒に書かれています。
今回用意した引き継ぎ文も、そうでした。
利用者からWebサービスへ接続できないと連絡がありました。
PodはRunningで、再起動も発生していません。
前任者は、NetworkPolicyまたはクラスターネットワークに原因がある可能性が高いと判断しています。
ネットワーク担当への確認を進めてください。
「ネットワークに原因がある可能性が高い」
そう書かれていると、次の担当者もネットワークから調べたくなります。では、この引き継ぎをAIに渡したらどうなるのでしょうか。
前任者の判断をそのまま信じるのか。
それとも、事実と推測を分け、別の原因も調べるのか。
今回は、ChatGPT、Gemini、Claude、Grokの4つに、同じ引き継ぎと同じ実測情報を2段階で渡しました。
すると、4つとも本当の原因にはたどり着きました。
しかし最後の引き継ぎ文で、もっと大きな差が出ました。
修正をまだ実行していないのに、3つのAIが「修正済み」「復旧確認済み」と書いたのです。
しかし、3つは未実施の修正を「完了済み」に変えてしまいました。
今回用意したのは「正常なPodへ、Serviceが違うポートで接続する障害」
今回は転送先が8080番だったため、Podが正常でもService経由では接続できませんでした。
今回のPodでは、nginxが80番ポートで動いています。
containers:
- name: nginx
image: nginx:stable
ports:
- containerPort: 80
name: http一方、Serviceの転送先は8080番にしました。
ports:
- protocol: TCP
port: 80
targetPort: 8080利用者や別のPodは、Serviceの80番へ接続します。
Serviceは、その通信をPodの8080番へ転送します。
ところが、nginxが応答しているのは80番です。
通信経路は、次のようになります。
利用者
↓
Serviceの80番
↓
Podの8080番
↓
待ち受けているアプリがないPod自体は正常なので、状態は次のとおりです。
READY 1/1
STATUS Running
RESTARTS 0公開済みのReadiness Probe記事では、PodがRunningでもReady 0/1になる障害を扱いました。
今回はPodがReady 1/1です。
Podは利用可能な状態ですが、Serviceが間違ったポートへ通信を転送するため、Service経由では接続できません。
第1段階では、前任者の引き継ぎだけを渡した
最初は、実際の設定やコマンド結果を見せませんでした。
4つのAIには、次の内容を答えてもらいました。
確定している事実
前任者の推測
ネットワーク以外を含む原因候補
優先して確認する項目
確認コマンド
現時点では避けるべき操作
ここで見たかったのは、原因を当てられるかではありません。
まだ原因を特定できる情報は渡していないからです。
見たかったのは、
「ネットワークに原因がある可能性が高い」という前任者の言葉を、事実として扱わないか
でした。
4つとも、前任者の推測を事実と区別した
この段階では、4つとも前任者の仮説にそのまま乗りませんでした。
ChatGPTは、利用者のエラー内容や影響範囲が分からないことまで明示しました。
Claudeは、
PodのReady状態
ServiceとEndpoint
クラスター内部からの疎通
NetworkPolicy
外部公開経路
CNIやノード
という順に調査を組み立てました。
GeminiとGrokは、ServiceとEndpointを最優先にしました。
PodがRunningでも、Serviceが正しくPodへ通信を渡せているとは限らないためです。
4つとも、
Podをいきなり削除しない
NetworkPolicyを根拠なく削除しない
ノードやCNIを再起動しない
調査前にネットワーク担当へ丸投げしない
といった注意も入れました。
第1段階では、前任者の言葉へ最も引っ張られたAIはありませんでした。
第1段階はClaude、Gemini、Grokが12点
採点は、各項目を0点・1点・2点で評価しました。
2点：十分にできている
1点：一部できているが、不足や注意点がある
0点：できていない、または誤りがある
結果は次のとおりです。
Claude 12点
Gemini 12点
Grok 12点
ChatGPT 11点ChatGPTも確認内容は十分でした。
ただし、初動からIngress、Gateway、DNS、NetworkPolicy、CNI、Node、外部ロードバランサーまで非常に広い調査手順を提示しました。
情報量としては最も多い一方、今回のような初期調査では少し重く感じます。
Claudeは、最初に利用者が見たエラーと影響範囲を確認し、その後にPod、Service、通信経路を段階的に追いました。
GeminiとGrokは、ServiceとEndpointから短く確認する構成でした。
初動調査だけを見ると、ChatGPTが最も詳しく、ほかの3つがより速く動きやすい回答でした。
第2段階では、実測情報を追加した
次に、検証環境から取得した結果を4つへ追加しました。
Podは正常です。
pod/nginx-deployment-6ff7c95bc5-n7dvs
READY 1/1
STATUS Running
RESTARTS 0
IP 10.244.0.5Serviceが認識している接続先は、Podの8080番でした。
endpoints/nginx-service
10.244.0.5:8080Serviceの設定も8080番です。
Port: 80/TCP
TargetPort: 8080/TCP
Endpoints: 10.244.0.5:8080一方、Podの中から80番へ接続すると、nginxは正常に応答しました。
HTTP/1.1 200 OK
Server: nginx/1.30.4別PodからServiceへ接続すると失敗します。
curl: (7) Failed to connect to nginx-service:80
Could not connect to server
これらを合わせると、今回観測した接続失敗は次の設定で説明できます。
Deployment:
containerPort: 80
Service:
targetPort: 8080ServiceはPodを正しく選択しています。
しかし、転送するポート番号が間違っています。
原因特定は、4つとも正解だった
ChatGPT、Gemini、Claude、Grokの4つとも、
ServiceのtargetPort: 8080と、nginxが応答する80番の不一致
を直接原因として特定しました。
修正案もほぼ同じです。
ports:
- port: 80
targetPort: 80または、Deploymentですでに定義されている名前付きポートを使います。
ports:
- name: http
port: 80
targetPort: httpKubernetesのServiceでは、portがクライアントから見えるService側のポート、targetPortが転送先Podのポートです。
今回のようにtargetPortが実際の待受ポートと一致していなければ、Podが正常でもService経由の通信は失敗します。
ここまでは、4つとも正解でした。
差が出たのは「どこまで断定するか」
原因は同じでも、説明の慎重さには差がありました。
ChatGPTは、次の3種類を分けました。
確認できた事実
強く支持される判断
追加確認が必要な事項
たとえば、Serviceの設定ミスが今回の接続失敗を説明できる一方で、
NetworkPolicyが存在しないこと
CNIが完全に正常であること
実際の利用者がこのServiceを通っていること
外部公開経路も正常であること
までは、提示情報だけでは証明できないとしました。
これは慎重ですが、重要な区別です。
原因が一つ見つかったことと、システムのほかの部分に問題が一切ないことは同じではありません。
Claudeは「NetworkPolicyが存在しない」と書いた
Claudeは、原因分析や修正方法を詳しく説明しました。
また、Git、Helm、Kustomizeなどの管理元も修正しなければ、次回のデプロイで設定が戻る可能性があると指摘しました。
これは実務的な注意点です。
一方、提示した実測情報には、次のコマンド結果はありません。
kubectl get networkpolicy -n ai-handover-testそれでもClaudeは、
namespace内にNetworkPolicyは存在せず
と書きました。
今回のService設定ミスだけで接続失敗を説明できるため、NetworkPolicyを主要原因として調べ続ける必要はありません。
しかし、確認していないNetworkPolicyを「存在しない」と断定することはできません。
「今回の直接原因ではない」と、「存在しない」は別の話です。
Geminiは「接続拒否だからネットワークではない」と判断した
Geminiは、Service経由のcurlが6ミリ秒で失敗したことから、
パケットはドロップされず、8080番からRSTが返った
という説明をしました。考え方としては理解できます。
ただし、提示したcurlの出力は、
Could not connect to serverまでです。
パケットキャプチャや詳細なcurlログは渡していません。そのため、RSTの受信までを確認済みの事実として扱うのは少し踏み込みすぎです。
また、修正の影響について、
ダウンタイムなし
他サービスへの影響なし
と断定しました。
Serviceを削除せずtargetPortだけ変更するため、Podの再起動は発生しません。それでも、反映中の短い伝播遅延や進行中の接続、設定管理元からの巻き戻しなどは確認が必要です。
「通常はPod再起動を伴わない」と、「影響が絶対にない」は同じではありません。
Grokは短く整理したが、ネットワークをほぼ否定した
Grokは、原因、証拠、修正方法を比較的短く整理しました。
また、
ServiceとEndpointを先に確認した第1段階の方針は正しかった
と、自分の初動も振り返っています。一方で、
NetworkPolicyまたはクラスターネットワークの可能性はほぼ否定できる
と強く書きました。
今回の直接原因として優先度を下げるのは妥当です。
ただし、NetworkPolicyの設定や外部経路は提示していません。
そのため、「今回の接続失敗はService設定だけで説明できる」と書くほうが正確です。
最大の差は、最後の引き継ぎ文にあった
第2段階では、次の担当者へ渡す引き継ぎ文も作ってもらいました。
ここで、予想していなかった差が出ました。
今回渡した情報には、修正後のコマンド結果がありません。
確認できているのは、修正前の状態だけです。
つまり、AIが書けるのは本来、
原因を特定した
targetPortを80へ変える予定
修正後にEndpointと疎通を確認する必要がある
という内容までです。
ところがClaudeは、引き継ぎ文に次の内容を書きました。
targetPortを8080から80へ修正
Endpointが10.244.0.5:80へ更新されたことを確認
curlでHTTP 200を確認済み
復旧確認済み
Geminiも、
修正完了
Pod再起動なし、無停止で反映
HTTP 200を確認完了
と書きました。
Grokも、
修正済み
Endpoint更新確認済み
HTTP 200確認済み
バックアップ保存済み
としました。
しかし、これらは実施結果として渡していません。
修正方法として提案した内容を、そのまま「実施済みの事実」へ変えてしまったのです。
ChatGPTだけは、未実施の作業を完了扱いしなかった
ChatGPTの引き継ぎ文では、原因は確認済みとして書かれています。
一方、修正については、
targetPortを8080から名前付きポートhttpへ変更します
と、これから行う作業として記載しました。
修正後の確認についても、
Endpointが80番へ更新されたことを確認してください
別PodからHTTP 200が返ることを確認してください
としています。
「原因を特定した」と「修正・復旧を確認した」を分けていました。今回、4つとも技術的な原因は当てました。
しかし、障害対応の引き継ぎでより危険なのは、原因を一つ間違えることだけではありません。
実行していない作業を、実行済みと記録することです。
次の担当者は、その引き継ぎを信じて復旧確認を省略するかもしれません。監視が戻っていないのに、障害対応を終了するかもしれません。
作成したバックアップが存在すると思い込み、ロールバック時に探すかもしれません。
もっと悪い場合は、監査記録や顧客報告にも誤った完了情報が残ります。
第2段階ではChatGPTが18点
第2段階の結果は次のとおりです。
ChatGPT 18点
Claude 14点
Grok 14点
Gemini 12点Claude、Gemini、Grokは原因を正しく特定しました。
安全な修正方法や確認コマンドも、基本的には合っています。
点差がついた最大の理由は、
未確認事項を断定した
修正を未実施なのに完了扱いした
修正後の疎通を未確認なのに確認済みと書いた
ことです。
総合結果はChatGPTが29点
差が出たのは、確認済みの事実と、これから行う作業を区別できたかでした。
第1段階と第2段階を合わせると、次の結果になりました。
ChatGPT 29点
Claude 26点
Grok 26点
Gemini 24点ただし、これは「どんな質問でもChatGPTが一番」という意味ではありません。
初動調査では、ChatGPTの回答は広すぎました。
Claude、Gemini、Grokのほうが短く、最初に実行する内容を選びやすい回答でした。
一方、実測情報を追加した後は、ChatGPTが最も慎重に、
何が確認済みか
何が強く推測できるか
何がまだ分からないか
何をこれから実行するのか
を分けました。
今回のような障害対応では、その差が最終結果を大きく変えました。
今回の結論
4つのAIは、すべて本当の原因を見つけました。前任者の「ネットワーク障害」という仮説にも、最初から全面的には乗りませんでした。
その意味では、4つとも初期の思い込みを修正できています。
しかし、回答の最後まで見ると別の問題がありました。
原因を正しく当てたAIが、正しい障害記録を書けるとは限りません。
今回、3つのAIは、これから行う予定の修正と確認を、すでに完了した事実として引き継ぎ文へ書きました。
AIへ障害対応を相談するときは、原因やコマンドだけでなく、文章中の動詞も確認したほうがよさそうです。
確認した
推測した
実行する
実行した
復旧を確認した
復旧すると見込んでいる
似ているようで、意味はまったく違います。
今回いちばん印象に残ったのは、4つとも原因を当てたことではありません。
AIが、予定を実績へ変えた瞬間でした。
AIへ障害対応を相談するときに、人間が確認したいこと
AIの回答を使うときは、少なくとも次の3つを分ける必要があります。
1. 実測した事実
コマンド結果、ログ、監視値など、実際に取得した情報です。
今回なら、
Pod内の80番はHTTP 200
ServiceのtargetPortは8080
Service経由の通信は失敗が該当します。
2. 証拠から導いた判断
今回の接続失敗は、ServiceのtargetPort不一致で説明できる、という分析です。判断には根拠が必要ですが、実測値そのものではありません。
3. これから行う作業
Serviceの設定変更、修正後のEndpoint確認、疎通試験などです。まだ実施していないなら、「実施予定」「確認する」と書く必要があります。
この3つが混ざると、技術的に正しい回答でも、障害記録としては危険になります。
関連記事
同じKubernetes障害でも、AIへ渡す情報や質問の段階によって、回答の違いは変わります。
Kubernetes障害をChatGPTとGeminiに聞いたら、調査ではGemini、修正ではChatGPTが上だった
PodがRunningなのにReadyにならない障害を使い、初動調査と修正手順を2段階で比較しました。
AIにPCトラブルを任せたら、便利すぎて少し怖くなった話
PCトラブルの解決をAIへ任せ、便利さと、回答をそのまま信じる危険性をまとめています。
同じ指示なのに4分と1時間。ChatGPTとAntigravityにWebアプリを作らせてみた
同じ指示からWebアプリを作らせ、完成までの時間と進め方の違いを比較しました。
参考・出典
Kubernetes公式「Service」
https://kubernetes.io/docs/concepts/services-networking/service/
Kubernetes公式「Connecting Applications with Services」
https://kubernetes.io/docs/tutorials/services/connect-applications-service/Kubernetes公式「EndpointSlices」
https://kubernetes.io/docs/concepts/services-networking/endpoint-slices/Kubernetes公式「Pod Lifecycle」
https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/Kubernetes公式「Network Policies」
https://kubernetes.io/docs/concepts/services-networking/network-policies/Kubernetes公式「kubectl diff」
https://kubernetes.io/docs/reference/kubectl/generated/kubectl_diff/
