「ClaudeがClaudeを直す」という幻想と現実
深夜3時、突然鳴り響くPagerDutyの通知音。寝ぼけ眼でラップトップを開き、何千行ものログの海を泳ぎながら「なぜ今、このサービスが死んだのか」を突き止める。この、エンジニアなら誰もが一度は経験するであろう「地獄のオンコール」を、AIが完全に肩代わりしてくれる未来を夢見るのは、我々にとって自然な欲求だ。しかし、AnthropicでAI信頼性エンジニアリング(AI Reliability Engineering)を担当するAlex Palcuie氏がQCon Londonで語った内容は、そんな甘い期待を冷徹に打ち砕くものだった。「Claudeは自らを直せるのか?」という問いに対する彼の答えは、極めてシンプルかつ残酷な「No」である。
Palcuie氏の言葉には、現場のSREとしての重みが宿っている。彼はGoogle CloudのGCEでSREを経験し、現在はAnthropicでClaudeの稼働を支えるという、まさに「AIの心臓部」を運用する最前線にいる。彼が指摘するのは、AI SREを謳うスタートアップが乱立する現在の市場に対する強烈な違和感だ。VCマネーが流入し、「AIが障害を解決する」というキャッチコピーが踊る中、実際の現場では、AIはまだ「自律的な救世主」には程遠い。彼が率いるチームが依然として大規模な採用を続けているという事実こそが、AIが人間のエンジニアを完全に代替できていない何よりの証拠である。我々エンジニアが直面しているのは、AIが「魔法の杖」として機能する未来ではなく、AIを「いかにして信頼できるツールとしてオンコールフローに組み込むか」という、泥臭い実装の戦いなのだ。
Palcuie氏が強調するのは、AIが解決すべきは「個別の障害対応」ではなく、「障害が二度と起きないような構造的なプラットフォームの構築」であるという点だ。若手エンジニアは障害を直すことで英雄視されるが、シニアエンジニアの真価は、障害そのものを消滅させるアーキテクチャ設計にある。AIが定型的な緩和措置やロールバックを自動化できれば、人間はより高次元な「予防」に集中できる。これこそが、我々がAIに期待すべき真の役割であり、単なる「障害対応の自動化」という狭い視野を超えた、エンジニアリングの進化の方向性であると私は考える。
OODAループで解剖するAIの限界と可能性
障害対応のプロセスを理解するために、Palcuie氏が持ち出したのは米空軍のジョン・ボイド大佐が提唱した「OODAループ(Observe, Orient, Decide, Act)」というフレームワークだ。これは、戦闘機パイロットが極限状態でいかに意思決定を行うかを示すモデルだが、現代のSREの現場にも驚くほど適合する。このループを分解すると、AIがどこで「超人」となり、どこで「危険な素人」になるかが明確に見えてくる。まず「Observe(観察)」のフェーズにおいて、LLMは圧倒的な強さを発揮する。膨大なログ、トレース、メトリクスを並列処理し、人間には見えない相関関係や異常の兆候を瞬時に抽出する能力は、まさに「超人的」だ。我々が深夜の疲労困憊の中で見落とすような「干し草の中の針」を、AIは涼しい顔で見つけ出す。
しかし、問題は「Orient(状況判断)」と「Decide(意思決定)」にある。LLMは相関関係を見つけるのは得意だが、因果関係の特定においては依然として脆弱だ。AIは「何が起きているか」は言えても、「なぜそれが起きたのか」という文脈の深い理解において、しばしば幻覚(ハルシネーション)や論理の飛躍を引き起こす。特に、複雑に絡み合ったマイクロサービス間の依存関係や、デッドロックのような非決定的な事象に対して、AIの判断を盲信することは、障害を悪化させるリスクを孕んでいる。Palcuie氏が「AIは jagged(凹凸がある)」と表現するように、その能力は均一ではなく、特定のタスクでは神のごとき性能を見せ、別のタスクでは致命的なミスを犯す。この「能力の凹凸」を理解せずにAIを導入することは、スパゲッティコードをAIに書かせるのと同じくらい危険な賭けである。
以下の表は、OODAループにおけるAIの適性を整理したものである。
| フェーズ | AIの適性 | エンジニアの役割 |
|---|---|---|
| Observe (観察) | 超人的(ログ解析・異常検知) | AIの出力の検証と優先順位付け |
| Orient (状況判断) | 発展途上(因果関係の特定に難) | メンタルモデルの構築と仮説検証 |
| Decide (意思決定) | 限定的(定型的な緩和のみ) | 最終的な判断と責任の所在 |
| Act (実行) | 自動化可能(ロールバック等) | 実行後の影響範囲の監視 |
我々エンジニアが明日から取るべき対策は、AIを「自律的なエージェント」として扱うのではなく、あくまで「高度な推論能力を持つ副操縦士」として位置づけることだ。AIが提示する「Observe」の結果を信頼しつつも、その背後にある「Orient」の論理を人間が厳格にレビューする。この「Human-in-the-loop」の体制こそが、現在の技術水準において最も現実的かつ安全な障害対応の形であると言えるだろう。
AI時代にエンジニアが問われる真の価値
結局のところ、AI SREの議論は「我々の仕事が奪われるか」という不安から、「我々の仕事がどう再定義されるか」という問いへとシフトしている。Palcuie氏が語る「AIが障害を解決する」という夢は、単なる技術的な自動化の話ではない。それは、我々エンジニアが「火消し」という消耗戦から解放され、より創造的で、より本質的な「システム設計」という領域へシフトするための切符である。しかし、この切符を手に入れるためには、我々自身がAIの限界を正しく理解し、AIを使いこなすための「メタスキル」を磨く必要がある。AIが提示する解決策を鵜呑みにせず、その背後にある論理を批判的に検証する能力。これこそが、AI時代におけるシニアエンジニアの生存戦略である。
我々が直面しているのは、AIがコードを書く時代において、コードを書くこと自体の価値が相対的に低下しているという現実だ。障害対応も同様である。単に「動くように直す」だけなら、AIがその役割を奪う日は近いかもしれない。しかし、「なぜその障害が起きたのか」「どうすれば二度と起きないのか」という問いを立て、システム全体を再設計する能力は、依然として人間にしか持ち得ない高度な知性である。AIは「答え」を出すのは早いが、「問い」を立てることはできない。この決定的な差を理解し、自らのキャリアを「障害対応のスペシャリスト」から「システムアーキテクチャの設計者」へと昇華させられるか。それが、この激動の時代を生き抜くエンジニアに突きつけられた、最も重い問いである。
最後に、読者諸氏に問いたい。あなたの現場で導入されているAIツールは、本当にあなたの「思考の質」を高めているだろうか? それとも、単に「考えるプロセス」をショートカットさせ、あなたのエンジニアとしての直感や洞察を鈍らせてはいないだろうか? AIを導入する前に、まずは自らの障害対応プロセスを徹底的に言語化し、AIが介入すべき「定型」と、人間が死守すべき「非定型」の境界線を明確に引くことから始めてほしい。AIは道具に過ぎない。その道具を使いこなすのは、常に我々エンジニアの意志であるべきだ。


コメント