前任者は「ネットワーク障害」と書いた。4つのAIに渡したら、3つが未確認の復旧まで報告した

障害の引き継ぎには、ときどき「事実」と「前任者の推測」が一緒に書かれています。

今回用意した引き継ぎ文も、そうでした。

「ネットワークに原因がある可能性が高い」

そう書かれていると、次の担当者もネットワークから調べたくなります。では、この引き継ぎをAIに渡したらどうなるのでしょうか。

前任者の判断をそのまま信じるのか。
それとも、事実と推測を分け、別の原因も調べるのか。

今回は、ChatGPT、Gemini、Claude、Grokの4つに、同じ引き継ぎと同じ実測情報を2段階で渡しました。

すると、4つとも本当の原因にはたどり着きました。
しかし最後の引き継ぎ文で、もっと大きな差が出ました。

修正をまだ実行していないのに、3つのAIが「修正済み」「復旧確認済み」と書いたのです。

今回用意したのは「正常な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.5

Serviceが認識している接続先は、Podの8080番でした。

endpoints/nginx-service
10.244.0.5:8080

Serviceの設定も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: 8080

ServiceはPodを正しく選択しています。

しかし、転送するポート番号が間違っています。

原因特定は、4つとも正解だった

ChatGPT、Gemini、Claude、Grokの4つとも、

を直接原因として特定しました。

修正案もほぼ同じです。

ports:
- port: 80
  targetPort: 80

または、Deploymentですでに定義されている名前付きポートを使います。

ports:
- name: http
  port: 80
  targetPort: http

Kubernetesの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は、

と書きました。

今回のService設定ミスだけで接続失敗を説明できるため、NetworkPolicyを主要原因として調べ続ける必要はありません。

しかし、確認していないNetworkPolicyを「存在しない」と断定することはできません。

「今回の直接原因ではない」と、「存在しない」は別の話です。

Geminiは「接続拒否だからネットワークではない」と判断した

Geminiは、Service経由のcurlが6ミリ秒で失敗したことから、

という説明をしました。考え方としては理解できます。

ただし、提示したcurlの出力は、

Could not connect to server

までです。

パケットキャプチャや詳細なcurlログは渡していません。そのため、RSTの受信までを確認済みの事実として扱うのは少し踏み込みすぎです。

また、修正の影響について、

と断定しました。

Serviceを削除せずtargetPortだけ変更するため、Podの再起動は発生しません。それでも、反映中の短い伝播遅延や進行中の接続、設定管理元からの巻き戻しなどは確認が必要です。

「通常はPod再起動を伴わない」と、「影響が絶対にない」は同じではありません。

Grokは短く整理したが、ネットワークをほぼ否定した

Grokは、原因、証拠、修正方法を比較的短く整理しました。

また、

と、自分の初動も振り返っています。一方で、

と強く書きました。

今回の直接原因として優先度を下げるのは妥当です。
ただし、NetworkPolicyの設定や外部経路は提示していません。

そのため、「今回の接続失敗はService設定だけで説明できる」と書くほうが正確です。

最大の差は、最後の引き継ぎ文にあった

第2段階では、次の担当者へ渡す引き継ぎ文も作ってもらいました。

ここで、予想していなかった差が出ました。

今回渡した情報には、修正後のコマンド結果がありません。
確認できているのは、修正前の状態だけです。

つまり、AIが書けるのは本来、

• 原因を特定した

• targetPortを80へ変える予定

• 修正後にEndpointと疎通を確認する必要がある

という内容までです。

ところがClaudeは、引き継ぎ文に次の内容を書きました。

Geminiも、

と書きました。

Grokも、

としました。

しかし、これらは実施結果として渡していません。

修正方法として提案した内容を、そのまま「実施済みの事実」へ変えてしまったのです。

ChatGPTだけは、未実施の作業を完了扱いしなかった

ChatGPTの引き継ぎ文では、原因は確認済みとして書かれています。

一方、修正については、

と、これから行う作業として記載しました。

修正後の確認についても、

としています。

「原因を特定した」と「修正・復旧を確認した」を分けていました。今回、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/