AIに障害調査を丸投げしても直らないKubernetesの本番障害
深夜のアラート対応で「AIエージェントに原因調査を任せれば早く終わる」と考えたことがある方は多いはずだ。実際、AIはPodのログを要約し、再起動コマンドを提案し、YAMLの修正案まで一瞬で出してくれる。だがKubernetes運用の現場では、それで根本原因が解決したケースより、「表面上は直ったように見えて数時間後に再発した」というケースの方が圧倒的に多い。
理由は単純だ。AIはユーザーが渡したコンテキストの外にある事実には気づけない。あるチェックアウト機能が遅いという相談に対してAIに最適化コードを書かせても、本当のボトルネックがデータベース設計や過剰なクエリ呼び出しにあった場合、コードをどれだけ書き直しても遅延は解消しない。Kubernetesの本番障害対応でも構造は同じだ。障害を起こしたPodを再起動して一見収まったように見えても、原因が別サービスのスロークエリやネットワークポリシーの誤設定にあれば、AIにその情報を渡さない限り正しい診断には到達しない。
この記事では、KubernetesでAIOps（AIによる運用自動化）を機能させるために不可欠な「分散トレーシング」という前提条件と、OpenTelemetryを使った導入ステップを整理する。観測性の土台部分をゼロから構築する余力がないチームも多いはずだが、KuboのようにPrometheus + Grafanaが標準搭載されたクラスタであれば、少なくとも監視基盤の構築そのものに時間を溶かさずに済む。
「AIに直させる」が失敗する現場のパターン
Kubernetesクラスタで障害が起きたとき、多くのチームがまず頼るのはPodのログとメトリクスのダッシュボードだ。AIエージェントにこれらの情報を渡して「原因を教えて」と聞けば、それらしい仮説はすぐに返ってくる。しかし、その仮説はAIに渡された情報の範囲内でしか成立しない。
典型的な誤診断パターンは次のようなものだ。
- Pod再起動で"解決"したように見える: メモリリークのように見えて、実は上流サービスからのリクエストが異常に多重化していたケース
- 特定のマイクロサービスのログだけを見て結論を出す: 実際の遅延の起点は3つ先のサービス呼び出しだったケース
- CPU使用率の急上昇だけを根拠に「スケールアップが必要」と誤診断: 実際にはリトライの多重発生がCPUを圧迫していたケース
いずれのケースも、単一サービスのログやメトリクスだけを見ている限り、AIも人間と同じように誤った結論に至る。Kubernetes公式ドキュメントが示す通り、標準のロギング機構はコンテナ単位の出力を集約するに留まり、サービス間の因果関係までは表現できない。
メトリクスとログだけでは"因果"が見えない
Prometheus + Grafanaによるメトリクス監視は、「いつ」「どのコンポーネントで」異常が起きたかを教えてくれる。だが「なぜ」「どこが起点か」という因果関係の特定には別のデータが必要になる。
分散システムの障害調査に詳しいCoralogixの解説によれば、分散トレーシングはマイクロサービス間を横断するリクエストの全経路を可視化する技術であり、メトリクスやログだけでは把握できないサービス間の依存関係と遅延の伝播経路を明らかにする。メトリクスは「何が起きたか」の集計値、ログは「その瞬間に何が記録されたか」の断片情報にすぎず、どちらも単体では「どのサービスの、どの呼び出しが遅延の起点か」という問いに答えられない。
AIエージェントに障害対応を任せる場合も同様の限界にぶつかる。ネットワーク運用領域でのAI活用について調査した業界動向でも、AIによる診断はまだ初期段階にあり、深い文脈理解を要する複雑な診断領域では人間の補助的な役割にとどまっているという指摘がある。AIが本当に役立つ判断を下すには、サービス境界を横断した構造化データが不可欠であり、それを提供できるのが分散トレーシングだ。
分散トレーシングがAIOpsの前提条件になる理由
分散トレーシングを整備すると何が変わるのか。W3C Trace Context標準に基づいてトレースIDをサービス間で伝播させることで、単一のリクエストが複数サービスをまたいで処理される様子を一つの視点で追跡できるようになる。さらにログレコードへトレースIDを自動的に注入しておけば、「あるログ行から、そのリクエストの完全なトレースへ」とたどることが可能になり、調査時間を数時間から数分規模へ短縮できるとされている。
こうした構造化されたトレースデータがあって初めて、AIエージェントによる自動診断も現実的になる。CNCFのSandboxプロジェクトとして開発が進むHolmesGPTは、Prometheusのアラートを起点にKubernetesクラスタのログ・メトリクス・イベントを横断的に取得し、LLMが「ReActパターン」で調査ツールを選択しながら段階的に根本原因を絞り込む仕組みを持つ。興味深いのは、こうしたAI SREエージェントの精度を決めるのはモデル性能そのものよりも、調査対象・利用可能なツール・注意事項を定義した「runbook」の有無だという点だ。適切なrunbookとトレースデータが揃っていれば数ステップで解決に至る一方、それらが欠けていると20ステップ以上を無駄にすることもあると報告されている。
つまり、AIOpsは「賢いAIを導入すれば解決する」話ではなく、AIが参照できる構造化された観測性データ、その中核である分散トレーシングが土台として存在して初めて機能する。本記事で述べた「因果が見えない」という問題は、そもそも監視基盤がどこまで整っているかで大きく左右される。Kubo CloudはPrometheus・Grafanaを標準搭載し、Captain UIによってクラスタの状態を可視化できるため、分散トレーシング導入前の土台部分をあらかじめ備えた状態でクラスタ運用を始められる。
KubernetesクラスタにOpenTelemetryを組み込む現実的なステップ
分散トレーシングをゼロから導入する場合、以下の順序で進めるのが現実的だ。
ステップ1: OpenTelemetry Operatorの導入
OpenTelemetry OperatorはKubernetes上でCollectorの管理と自動計装を担うOperatorで、OpenTelemetryCollectorとInstrumentationという2種類のCustom Resource Definitionを提供する。GitHubの公式リポジトリにHelmチャートやマニフェストが公開されており、既存のクラスタに追加でデプロイする形で導入できる。
ステップ2: 自動計装(Auto-Instrumentation)の有効化
対象のワークロードにinstrumentation.opentelemetry.io/inject-<言語>のようなアノテーションを付与するだけで、アプリケーションコードを変更せずにOperatorがトレース計装用のinit-containerを自動的に注入してくれる。まずは影響範囲を確認しやすい1〜2個のマイクロサービスから試すのが安全だ。
ステップ3: サンプリング戦略の設計
トレースデータを全件収集するとストレージコストが急増するため、サンプリング戦略の設計が欠かせない。Logz.ioの解説によれば、リクエスト開始時点で即座に記録可否を判定する「head-based sampling」は低コストだが情報が限定的であり、全スパンを収集してから判定する「tail-based sampling」はエラーやレイテンシー条件を使った精緻な判断ができる一方でリソース負荷が高い。Datadogが提唱するアプローチでは、決済APIのような収益に直結するエンドポイントは高いサンプリング率を維持しつつ、ヘルスチェックのような低優先度の呼び出しはサンプリング率を大きく下げることで、月次のトレーシング予算を超過させずに重要な障害だけを確実に捕捉できるとされている。
トレースの保持期間についても、直近の障害調査に使う「ホットストレージ」は数十日程度、長期トレンド分析用は安価な「コールドストレージ」に分けて設計することで、コストと調査性のバランスを取りやすくなる。
まとめ: AIOpsは監視ツールの置き換えではなく観測性基盤の上に成立する
AIエージェントに障害対応を任せることそのものは、決して間違った方向性ではない。しかし、AIに「原因を直して」と頼む前に、そのAIが根本原因にたどり着くための材料——サービス境界を横断した分散トレーシングデータ——が整っているかどうかが、成果を大きく左右する。
Kubernetesクラスタの観測性を、Prometheus・Grafanaによるメトリクス監視だけで止めてしまっているチームは少なくない。だが本番障害対応の質を一段引き上げるには、分散トレーシングという土台への投資が避けて通れない。
AI時代のインフラ運用で本当に問われるのは、AIエージェントをどう使うかだけでなく、AIエージェントに正しい判断材料を渡せる基盤をどう整えるかだ。モニタリングスタックをゼロから構築・運用するコストは決して小さくないからこそ、その土台部分をあらかじめ備えたインフラを選ぶかどうかが差になる。
分散トレーシングの整備からKubernetes運用を見直したい場合は、Kubo のお問い合わせから気軽に相談してみてほしい。EKSやAKSで同等の構成を組む場合と比べても、K3sベースのKuboならコスト効率よく観測性基盤を含めた本格的なKubernetes環境を構築できる。