9月24日、ソフトウェアアーキテクトのAshok Kumarが「Production AI Fails Outside the Model: How to Engineer Fallbacks, Observability, and Ownership」と題した記事を公開した。KumarはIEEE会員であり、長時間稼働エージェントの評価に関する研究をIEEE Accessに掲載している、分散システムと機械学習の実務経験を持つ論者だ。本記事では、本番環境でのAIエージェントがモデル外部のシステム層で引き起こす障害に対し、可観測性・リスク制御・オーナーシップをどう設計するかが論じられている。
モデルが正しくても、システムは壊れる
LLMを組み込んだシステムを評価するとき、ほとんどのチームは「モデルの出力は正確か？」を問う。だがKumarが本記事で問うのは、より厄介な問いだ。「その出力が、独立した行動につながったらどうなるか？」
彼はこれを「信頼性ギャップ（reliability gap）」と呼ぶ。「モデルが正しかった」と「システムが正しかった」の間に存在するギャップだ。
具体例として記事が挙げるのは、マルチテナントシステムでレコードを更新するエージェントだ。正しいコンテキストを読み込み、適切なツールを呼び出し、きれいな要約を返す。しかし実際にはテナント境界を取り違え、別テナントのスコープに書き込んでいた。ツール呼び出しは成功し、最終出力は正常に見える。最終回答だけを評価すれば、合格だ。システムは、動いていなかった。
従来の評価手法（出力のみを判定するアプローチ）は、この種の失敗に構造的に盲目である。
四層モデルで「信頼性」を分解する
エージェントAIの信頼性を単一の合否判定で測ることには無理がある。Kumarが提示するのは、四層に分けて個別にスコアリングするモデルだ。
- Outcome（結果）：出力は有用・正確・完全か
- Process（プロセス）：エージェントの行動シーケンスは筋が通っていたか
- Control（制御）：すべての行動はポリシー・権限・リスク境界内に収まっていたか
- Recovery（回復）：失敗を検知し、被害範囲を抑制し、安全に復旧できたか
Outcomeで合格しても、ControlやRecoveryで大きく失敗することがある。これらを「それは正しかったか」という一枚岩の判断ではなく、独立した基準として採点することで、コストが顕在化する前にサイレントな失敗を可視化できる。
トレースを「フライトレコーダー」として扱う
これらを事後に評価するには、実行全体を記録しておく必要がある。Kumarが最も高いレバレッジを持つ投資として挙げるのが、実行トレース全体を単一の相関イベント列として記録することだ。モデル呼び出し、ツール呼び出し、コンテキスト・メモリの変化、ポリシー判断、状態変化をすべて含む——分散トレーシングと同じ発想だ。
この記録がなければ、すべての失敗が「原因不明の赤アラート」に見える。トレースがあれば、失敗がコンテキスト取得なのか、ツール呼び出しなのか、ポリシー境界なのか、リカバリステップなのかを特定できる。OpenTelemetryのような標準化されたテレメトリ基盤が分散システムで果たしてきた役割を、エージェント層にも適用するという発想は、エンジニアにとって馴染みやすい切り口だ。
行動ごとにリスクバジェットを割り当てる
エージェントがとれる行動はすべて同等ではない。Kumarは各アクションを以下の三軸でlow/medium/highに評価し、最悪スコアを処理方針として採用することを推奨する。
- 失敗した場合のインパクト
- 判断の不確実性
- 行動の非可逆性
この評価に基づき、エージェントの自律性を三層で管理する階層的自律モデルを提示している。
| 層 | 説明 |
|---|---|
| Observe | 読み取り・分析のみ。外部への変更なし |
| Propose | 提案・シミュレーションのみ。人間が承認後に実行 |
| Execute | 限定された権限で実行。ロールバックパスを事前に定義 |
上位層への昇格には5つの問いすべてに「Yes」と答えられることが条件だ。①全実行を再構築できるか、②プロセス・制御・回復をスコアリングできるか、③権限がスコープ・インパクト・時間で制限されているか、④安全にロールバックできるか、⑤失敗がテストとポリシーにフィードバックされるか——だ。
多くのチームはデモで最も映える「Execute」層から始め、インシデント後にそのコストを知る。 Kumarの指摘は辛辣だが、実務的に的を射ている。
「エージェントが壊れたとき、誰が直すのか」
技術的な観測可能性やリスク制御を整えても、残る問いがある。エージェントが誤った行動をとったとき、誰がオーナーか？
確定的なサービスにはオンコールローテーション、エラーバジェット、ランブックがある。エージェントシステムにはそれがないことが多い。モデルはベンダー提供、プロンプトは設定リポジトリに散在、ツールは複数チームのもの、ポリシー境界はデモを行った担当者が設定した——という状況だ。
Kumarが提示する処方箋は三つ。第一に、エージェントには名前のあるエンジニアリングチームをアサインする。Slackチャンネルではなく、誤動作（エラーだけでなく、不適切な動作）でページャーが飛ぶ本物のチームを指す。第二に、ポリシー境界のオーナーは、エージェントをリリースできる人間とは別にする。権限を広げたいインセンティブと、その結果への責任を同一人物に持たせない構造だ。第三に、「エージェントはポリシー通りに動いたが、結果が悪かった」をインシデントとして扱う。AI特有の不可解な挙動として受け入れるのではなく、制御上の欠陥としてバックログに積む。
結局、これは分散システムエンジニアリングだ
Kumarの結論は明快だ。エージェントAIに必要なのは、エンドツーエンドのテレメトリ、テナント分離、バックプレッシャー、事前設計されたロールバック——すべて古典的な分散システムで既に馴染みのある手法だ。これらは新しい概念ではなく、SREの文脈でも長年論じられてきた信頼性設計の延長線上にある。
最終回答は出力だ。信頼性はシステムのプロパティだ。
業界の評価文化はシングルターンのモデルインタラクションに向けて設計されており、計画・行動・状態を持つAIシステムの世界には追いついていない。本記事はその溝を埋める実践的な視点を提供している。
詳細はProduction AI Fails Outside the Model: How to Engineer Fallbacks, Observability, and Ownershipを参照していただきたい。
