AIを「排除」するのではなく「コパイロット」として活用する。Human-in-the-Loop（HITL）とオブザーバビリティ設計が、AI時代のインフラエンジニアの生存戦略だ。
前編では、AIがインフラ障害のRCAで相関と因果を誤認するメカニズムを解説した。後編では「ではどうすべきか」に踏み込む。Human-in-the-Loop、オブザーバビリティ設計、そしてエンジニアのスキルシフトを具体的に紐解く。
前編の振り返り：AIはなぜRCAを間違えるのか
前編で解説した通り、LLMは統計的パターンマッチングの極致であり、データ間の相関発見には人間を凌駕する。しかしJudea Pearlの因果推論階層における「介入」「反事実」の推論ができず、因果の方向性を特定できない。この限界を無視してSelf-Healing権限を与えることは、運用リスクを増大させるだけだった。
では、AIを「排除」すべきなのか？ 答えはNoだ。
Human-in-the-Loop（HITL）：AIを安全に活用するアーキテクチャ
AnthropicがAI SREの自律性の限界を認めたことは、AIOpsの終焉ではない。ベンダ主導の非現実的な「完全自律型Self-Healing」というハイプからの健全な脱却であり、人間とAIの協調フェーズへの移行だ。
これからのインフラ運用では、AIは「自律的オペレーター」ではなく「超高性能なコパイロット（副操縦士）」として再定義される。
膨大なメトリクス・ログから「相関の強い異常事象のクラスタ」を瞬時に提示する。人間が1時間かかるアラートのトリアージを数秒で完了。
AIが出した仮説に対して、エンジニアが「アーキテクチャの知識」と「ビジネスロジックのコンテキスト」を適用し、真の根本原因を特定する。
ロールバック、インスタンスの強制終了、トラフィックのルーティング変更など、Write権限を伴うアクションは必ず人間がレビューし承認する。
HITLの原則
AIには「Read権限（観測と分析）」を与え、「Write権限（システム変更）」は人間の承認プロセスを必ず挟む。これがシステムの信頼性を担保するための必須要件だ。
AIに「文脈」を与えるオブザーバビリティ設計
HITLワークフローの効果を最大化するには、AIが少しでも正確な仮説を出せるよう、良質なコンテキストを与えることが重要だ。
エンジニアが設計すべき3つのコンテキスト
1. 分散トレーシング：OpenTelemetryを用いて、リクエストがどのサービスをどの順序で通過したかを可視化する。AIに因果の「矢印」のヒントを与える最も有効な手段。
2. ビジネスメトリクス：技術メトリクス（CPU・メモリ）だけでなく、注文数・決済成功率などビジネスKPIを計装する。AIが「何が本当に壊れているか」を判断する材料になる。
3. サービス依存関係マップ：サービスメッシュやサービスカタログで動的な依存関係を機械可読な形で管理する。AIがトポロジーを理解するための基盤。
これらは単なる「モニタリングの改善」ではない。AIが機械可読な形でシステムの構造を理解するための「インターフェース設計」だ。
AI時代にインフラエンジニアが身につけるべきスキル
エンジニアに求められるスキルセットは、手動でのログ解析やシェル実行から、「AIが正しく推論できるようにコンテキストを設計する」能力へとシフトする。
これからのコアスキル
・OpenTelemetryを用いた高度な分散トレーシングの計装
・ビジネスロジックに紐づくカスタムメトリクスの定義
・システムの依存関係をAIが理解できる形で構造化する設計力
・AIの出力に対する批判的思考（仮説の検証・棄却判断）
「AIがインフラエンジニアの仕事を奪う」のではない。「AIに適切なコンテキストを与えられないエンジニアが淘汰される」というのが、この技術トレンドが示す真の未来図だ。
まとめ：AIは「魔法の杖」ではないが、最強の「助手」になる
Anthropicの発表は、AI SREの「敗北」ではない。業界全体が「過度な期待」から「現実的な運用」へと成熟していくための重要なマイルストーンだ。
相関と因果の違いを理解し、AIのハルシネーションを適切にコントロールできるインフラエンジニアこそが、これからの時代に最も重宝される存在になる。AIを恐れるのではなく、最強のコパイロットとして使いこなす側に回ろう。
コメント