10月5日、O'Reillyが「How to Build Reliable AI Agent Systems for Production」と題した記事を公開した。本番環境で信頼性の高いAIエージェントシステムを構築するための設計原則と実装手法を、具体的な失敗例を軸に論じた内容だ。

AIエージェントを本番環境に投入する際、「プロンプトを調整すれば精度が上がる」という発想で対処しようとするチームは多い。しかし記事の冒頭に挙げられた例が本質を突いている。

顧客がアカウント123の配送先住所を変更するよう依頼した。エージェントはサポートチケットのタイポを読み違え、アカウント132を更新してしまった。CRMは「成功」と返した。APIは正しくリクエストを処理したが、顧客が承認したアカウントと実際に操作されたアカウントが違うことを検知する仕組みがなかった。

モデルはシステムが許した範囲のことをしたに過ぎない。より強力なモデルに替えても、プロンプトを磨いても、「システムがエージェントの判断を最終権限として扱っている」という構造的問題は解決しない。この問題はAIエージェント固有のものではなく、ReActパターンやLangGraph・AutoGenといった既存のエージェントフレームワークでも共通して指摘されてきた課題だ。記事はその解決策を「モデルの外側のシステム設計」に求める。

判断・承認・実行を層で分離する

記事が最初に提示する設計原則は、モデルはアクションを「提案」するだけで、実際の可否はポリシーサービスが決定するという分離だ。

• モデル層：リクエストを解釈してアクションを提案する
• ポリシー層：そのアクションが許可範囲内かを検証する
• 実行層：ポリシーが通過したアクションのみを実行する

先の例にポリシーサービスを組み込むと、エージェントがアカウント132の更新を提案した時点で、ユーザーが承認した操作（アカウント123）と照合し、不一致を検知してリジェクトできる。エージェントが自信満々な口調であっても関係ない。

この構造では、実行ログに「どのリクエストが、どのポリシーバージョンのもとで、どんな結果になったか」を記録することも求められる。決定論的なソフトウェアで制約を強制することで、モデルの不確実性をシステム側で吸収する設計だ。ポリシーレイヤーの実装は、Open Policy Agent（OPA）のような汎用ポリシーエンジンを参照すると具体的なイメージが掴みやすい。

エージェントが持つ権限を最小化する

OAuthスコープで境界を設けているチームも多いが、writeスコープのような広い権限はエージェントに大きな裁量を与えすぎる。

記事が推奨するのはナロウ・ケイパビリティ（narrow capability）という考え方だ。ユーザーが承認した操作を「アカウント123の配送先住所を1回だけ更新できる」という単一の能力として発行し、その操作が完了したら期限切れにする。

この仕組みはプロンプトインジェクション攻撃への耐性も高める。エージェントが悪意のある指示を受け取って誤ったアクションを要求しても、ランタイムはケイパビリティの範囲外のリクエストをリジェクトできる。監査ログも「その操作に対して何の権限が付与されていたか」が明確になるため、インシデント後の原因調査が容易になる。最小権限の原則はセキュリティ設計の基本だが、AIエージェントの文脈では「操作単位・セッション単位でスコープを絞る」という粒度の細かさが特に重要になる。

エージェントのコンテキストを「信頼できない入力」として扱う

エージェントはユーザーの現在のプロンプト以外にも、SKILL.mdファイルや前回実行時の永続化メモリなど複数のソースから指示を受け取る。これらは便利だが、出所が古かったり、悪意ある書き換えが行われている可能性がある。

記事ではShub Arghaの研究を引用し、トラストプリアンブル（trust preamble：コンテキストの先頭に信頼の宣言を付加する手法）を導入することで、コンテキスト汚染の発生率が88.8%から33.3%に低下したと報告している。この研究はコンテキスト内のプロンプトインジェクション耐性を測定したものだが、残り33.3%は依然として失敗することも明示されている。警告の表示だけでなく、コンテキストの来歴（誰がいつ書いたか）を記録してリスクラベルを付与する技術的な検証が不可欠だと記事は指摘する。

プロンプトインジェクションの脅威については、OWASP LLM Top 10でも「LLM01」として最重要リスクに位置づけられており、設計段階からの対策が求められている。

停止・回復・監査の設計

記事はさらに3つの設計要素を挙げている。それぞれは独立した機能に見えるが、「エージェントの動作を人間が制御・検証できる状態に保つ」という共通の目的に向けて機能する。

エージェントを止めることを通常動作に組み込む：信頼度が閾値を下回ればヒューマンエスカレーション、人間が対応を引き継いだらエージェントの返答をキャンセル、といったルールをルーティング層・実行層に持たせる。モデル自身に「止まるかどうか」を判断させない。キルスイッチはモデルが計画の途中であっても機能しなければならない。エスカレーション設計はシステムの「例外ケース」ではなく、設計の「正規フロー」として組み込む必要がある。

状態を保持してリカバリーを可能にする：フォームの途中でページが変わったブラウザエージェントを例に、冪等性キー（idempotency key）を各アクションに付与し、再実行時に同じ操作が二重実行されないよう設計する。休止（ハイバネーション）を使う場合も、再起動時に必要な状態が確実に復元される前提が必要だ。ステートフルなエージェント設計については、LangGraphのpersistence機能が実装上の参考になる。

検査可能なエビデンスを残す：実行ログはエージェントが受け取ったコンテキスト・要求したアクション・それを許可したポリシー・返ってきた結果を紐づけて記録する。コンテキストグラフを使えば、過去のコード変更の意図を後続のエージェントが参照することもできる。ただしシークレット情報をログに含めないなどの制限は必要だ。ログ設計はインシデント対応だけでなく、モデルの挙動改善のフィードバックループにも直結する重要な投資だ。

制御を特定ランタイムに依存させない

複数のモデルやエージェントランタイムを使う組織では、権限がプロンプト内に散在し、モデルやツールを追加するたびにルールが揺らぎやすい。記事ではMCP（Model Context Protocol）を活用し、ツールの記述と呼び出しの共通インターフェースをサーバーまたはゲートウェイレベルで認可を強制する方法を提案している。MCPはAnthropicが策定したオープン仕様で、公式リポジトリで仕様とSDKが公開されている。どのモデルがリクエストしたかに関わらず、ポリシーを一貫して適用できる構造だ。

本番環境のAIエージェントに求められる信頼性は、「モデルの賢さ」ではなく「周囲のシステムの設計」によって担保される。この記事が提示するアーキテクチャは、その構造的な解答だ。

詳細はHow to Build Reliable AI Agent Systems for Productionを参照していただきたい。