AIエージェントの本番運用、計画はモデルに実行は登録済み操作に

本番環境のAIエージェントにとって最も危険なのは、推論を誤る瞬間ではないかもしれません。むしろ、自らの推論をそのまま実行に移す瞬間かもしれません。エージェントがクラスターの不調を判断し、再起動の手順まで即興で組み立てて実行したとしても、その手順が正しいと保証する仕組みはどこにもありません。NetflixでオーケストレーションエンジンConductorを最初に作ったエンジニアは、役割をはっきり分けるべきだと主張します。次に何をすべきかはモデルが決め、それをどう実行するかは、事前に登録してテストした操作だけを使う決定論的な実行レイヤー、つまりハーネスが決めるという考え方です。モデルが頭脳で、ハーネスが手です。

本番のエージェントの多くはチャットボットではない

よく思い浮かべるエージェントの姿は、リクエストとレスポンスのループです。ユーザーがプロンプトを送り、ボットがツールを呼び出し、応答が返ってきます。カスタマーサポートのチャットボットが典型例です。しかし、この図は実際の企業向けソフトウェアを表すにはあまりに小さすぎます。本番環境のエージェントの多くは、人が見守ったり指示したりしない状態で動いているからです。エージェントをチャットボットとしてしか捉えていないチームは、最も価値の高いバックグラウンド処理やイベント駆動の自動化を見落とすおそれがあります。

人がその場にいないほど、何が実行を制御するのかという問いは安全性の問題になっていくように見えます。

エージェントは部品、ハーネスがアプリケーション

この設計はマイクロサービスとよく似ています。企業はアプリケーションのロジックをすべて一つのサービスで処理しようとはしません。役割を絞った多数のサービスを動かし、その上のオーケストレーション層が状態、ルーティング、ポリシー、障害復旧を管理します。エージェントも同じ道をたどっています。単一のエージェントループは部品であって、アプリケーションではありません。アプリケーションとは、エージェントを人、データベース、API、MCPサーバーと結び付けるハーネスのことです。MCP（Model Context Protocol）は、AIモデルを外部ツールにつなぐための標準的な仕組みです。

作業を分けることは、ハルシネーション、つまりモデルがもっともらしいが誤った出力を生み出す傾向を抑えることにもつながります。一つのエージェントにすべての運用手順を任せると、そのリスクは大きく高まります。

二種類の作業

エージェントシステムの中の作業は、二つのグループに分かれます。

• 非決定的な作業（エージェントが担当）： 計画、推論、分類、要約、次のステップの選択、再計画
• 決定的な作業（ハーネスが担当）： 決済、クラウドインフラのプロビジョニング、法的承認、コンプライアンス監査、ロールバック、そしてサービスレベルの約束を管理するSLAタイマー

後者は、確率的に動くモデルがハルシネーションを起こしたり即興で処理したりしてはならない作業です。Kubernetesクラスターの再起動が好例です。再起動では毎回、同じ検証とデプロイの手順を同じ順序で踏む必要があります。エージェントが再起動が必要だと判断するのは妥当です。しかし、再起動をどう行うかはハーネスが厳格に制御しなければなりません。本番環境では、破壊的な操作の前にエンジニアへ承認を求めるSlackメッセージのような、人による承認ゲートもハーネスに組み込むべきです。モデルが安全ポリシーを踏み外さずに守ってくれると信じるのは危険です。実行上の制約はコードで担保すべきです。

▲ エージェントを包むハーネス

耐久性は参加の前提条件

本番のエージェントのワークフローは、一つのHTTPリクエストの中には収まりません。数時間、数日、数週間、あるいは数カ月にわたって動きます。たとえば受注管理のワークフローは、配送業者や倉庫の承認を数日から数週間待つことがあります。その間、ハーネスは人のレビューを待ち、非同期イベントに反応し、スケジュールどおりに処理を起動し、クラッシュから復旧しなければなりません。分散クラウドインフラでは、ネットワーク分断、コンテナのクラッシュ、ハードウェア障害は避けられません。

そのため、耐久性のある実行は付加価値のある機能ではなく、最低限の要件になります。ランタイムは作業を重複させたり状態を失ったりすることなく、止まった場所から正確に再開できなければなりません。

ここから二つ目のルールが導かれます。再計画で変えられるのは未来だけで、過去は決して変えられないということです。完了した作業、副作用、承認、表面化した失敗は、耐久性のあるストレージに固定されたまま残ります。想定外のことが起きると、ハーネスは現在の状態をエージェントに返し、エージェントはそこから先の新しいステップを計画します。役に立つ制御ループは、エージェントのプロンプトチェーンの内側ではなく、現実の結果がエージェントへのフィードバックになる外側の境界にあります。

計画は自由に、語彙は固定する

エージェントが実行時に新しい計画を書くなら、ハーネスは初めて見る計画の振る舞いをどう保証できるのでしょうか。答えは、限定されたアルファベットです。計画は自由なままですが、実行できる操作の集合はデプロイ時に登録しておきます。このパターンはlate-bound sagaと呼ばれます。sagaは従来、人が手で書く決定的なワークフローでした。ここでは、エージェントが事前登録されたカタログから実行時にタスクをつなぎ合わせます。

状態を変える操作には、それを元に戻す補償タスクをそれぞれ登録しておきます。

これは分岐型のワークフローとは異なります。クローズドワールドの分岐型フローでは、すべての経路をデプロイ時に描いておく必要があり、プランナーは既存の分岐を選ぶだけです。late-bound sagaはオープンワールドです。エージェントは利用可能なツールを新たに組み合わせることができ、エンジニアは将来のあらゆる経路をハードコードする必要がありません。実行時のあらゆる組み合わせを事前に決めておくのはほぼ不可能であることを考えると、これは柔軟性と保証のあいだの現実的な折衷案に見えます。

障害対応エージェントの動き方

SREの修復エージェント、つまりサイト信頼性に関わるインシデントに対応するエージェントのデモを見ると、各要素がどう組み合わさるかがよくわかります。シナリオは一貫性を保つため事前に用意されたものですが、流れは参考になります。

1. 既存のエージェントをハーネスにつなぎます。エージェントの行動を登録済みのタスクに対応付けるのに必要なコードは約12行です。
2. 最初のサイクルで、エージェントはログの証拠を調べ、メトリクスを照会します。
3. モデルはそのコンテキストを受け取り、実行するタスクを並べた構造化JSONの計画を返します。
4. コンパイル用のツールが計画を、ステップとその順序を示す有向非巡回グラフ、つまり検査可能なDAGに変換し、Conductorがそれを実行します。
5. 計画は失敗したサービスのデプロイをロールバックし、メトリクスを照会し続けて復旧を確認します。各ステップは進行中から完了へと移り、完全な実行記録が残ります。
6. 次のサイクルで、エージェントは復旧した状態を確認し、ロールバックが成功したと認識して、繰り返さずに終了します。

▲ ロールバックと復旧確認の流れ

Conductorは、Netflixで最初に作られ、Apache 2.0ライセンスで公開されているオープンソースのオーケストレーションエンジンです。エージェントのワークフロー、長時間のループ、マイクロサービスのオーケストレーションを状態を永続化しながら実行し、LangChain、OpenAI Agents SDK、独自SDKで作ったエージェントと連携できます。

本番エージェントのための安全チェックリスト

核となる考え方はシンプルです。判断はモデルに、実行は決定論的なコードに任せることです。スケジュール型、イベント駆動型、長時間稼働のエージェントを運用している、あるいは計画している場合は、次の点を確認してください。

• 業務ロジックがモデルの推論ステップと決定的なタスクに分かれており、一つのプロンプトループに混ざっていない
• 決済、クラスターの再起動、コンプライアンスの執行をモデルが直接実行できない
• エージェントは事前登録された操作の中からしか選べず、任意のコマンドを生成できない
• 状態を変えるすべての操作に、補償タスクが定義されている
• 本番環境のリスクの高い操作は、Slackでの承認のような人による承認ステップを通る
• 完了した作業と副作用が変更不可能な記録として残り、再計画では後のステップだけが変わる
• モデルの計画は実行前に検査可能なDAGへコンパイルされ、追跡と安全な再実行ができる
• 実行レイヤーがネットワークの切断、マシンの再起動、長い待機に耐えられる