AIエージェントを本番環境で運用するには、スコープ付きアクセス、制限された実行、安全な書き込み、永続的な復旧、隔離されたコード実行、エンドツーエンドのトレース、再現可能な評価、検証済みの停止手段が必要です。人間が監視するデモの成功だけでは、これらの制御についてほとんど何も証明できません。
エージェントが、すべての手順を人間に監視されることなく、開発者が用意していない入力を受け取るようになった時点で本番運用は始まります。リリースゲートでは、失敗、反復、権限を必要とする経路をテストしてください。
自律性より先にIDを確立する
エージェント、デプロイ、セッションごとに、呼び出し元を特定し、アクセスできるテナント、リソース、アクションを制限する認証情報を与えます。その制限はデータを所有するサービスで強制します。ツールの説明とシステムプロンプトはモデルのコンテキストであり、バックエンドの認可ではありません。
OWASPのExcessive Agencyガイダンスは、ツールの機能、権限、自律性を最小限にすることを推奨しています。この順番で適用してください。まず不要なツールを削除し、残したツールの認証情報を狭め、影響の大きいアクションの前に承認を追加します。
AIエージェントのセキュリティガイドでは、認証情報のスコープ、シークレットの扱い、監査での帰属を詳しく解説しています。
コードで実行範囲を制限する
経過時間、モデルの支出、ツール呼び出し、反復回数、同時実行数、出力サイズに、サーバーが強制する上限を設定します。書き込みや支出を伴うツールには、より厳しい上限を使います。認可エラーや検証エラーを繰り返し再試行せず、実行を止めてください。
予算を使い切った後でも、モデルは次の手順を要求できます。ランタイムがこれを拒否しなければなりません。グローバルなレート制限だけでは不十分なのもこのためです。暴走したワークフローを遅らせることはできても、そのワークフローが与える損害の総量は制限できない場合があります。
外部への効果をすべて復旧可能にする
再試行可能な書き込みには、一つの論理操作IDまたは冪等性キーが必要です。結果をサーバー側に保存し、同じ操作が再試行されたらその結果を返します。クライアントがタイムアウトしたときは、効果を繰り返す前に操作記録を確認します。
外部への効果が確認された後にチェックポイントを保存してください。メール送信やデプロイ作成の直後にプロセスが失敗した場合、復旧したワークフローはその手順を再実行せず、次の手順から再開する必要があります。
Temporalの永続実行ドキュメントでは、永続化されたワークフロー状態がプロセス障害を越えて維持される仕組みを説明しています。ただし、外部サービスがリクエストを受理した直後にworkerが失敗する可能性があるため、アプリケーションのactivityには依然として冪等性が必要です。
生成コードや信頼できないコードを隔離する
エージェントが生成したコードは、アプリケーションプロセスの外で実行します。サンドボックスでは次の境界を定義します。
- 存在するファイルシステムパスと、永続化されるパス
- プロセスが接続できるホストとプロトコル
- 注入するシークレットと、その有効期間
- CPU、メモリ、プロセス、経過時間の制限
- 実行終了後の成果物とログの保持期間
コンテナ化しただけでは、これらの問いに答えられません。AIエージェント向けサンドボックスガイドでは、各境界をテストに変換しています。
判断から効果までをトレースする
ユーザーのリクエスト、モデル呼び出し、取得したコンテキスト、ツール選択、ポリシー判断、ツール実行、下流APIの処理を、一つのトレースとして記録します。安定したテナント、エージェント、実行、ツール呼び出し、操作の識別子を含め、認証情報と機密性の高いツール出力は除外します。
OpenTelemetryのGenAI規約は、モデル、エージェント、ツールの動作に関するフィールドを定義しています。これを基礎にして、誰がどのリソースを変更したか答えるために必要なプロダクト識別子を追加します。
変更をリリースする前に振る舞いを評価する
代表的なタスクを少数固定します。期待するツール選択、禁止アクション、承認地点、復旧ケース、合格基準を含めます。モデル、システムプロンプト、ツール説明、権限、再試行ポリシー、メモリ動作を変更したら、この一式を実行してください。
モデルのばらつきが影響するケースは繰り返し実行します。1回の成功は一例であって、成功率ではありません。エージェント評価ガイドでは、決定論的なアサーションとモデルによる出力評価を組み合わせる方法を説明しています。
人間が介入する経路を定義する
システムは重大なアクションの前に一時停止し、正確なリソース、アクション、スコープ、期待される効果をレビュー担当者へ示せる必要があります。また、エージェントが混乱している、または利用できないときにも使える運用経路が必要です。
- 新しい実行を停止する。
- 現在の実行を中断する。
- 影響を受ける認証情報を取り消す。
- その実行が触れたすべてのリソースと操作を特定する。
- 完了済みの効果を復元、補償、またはエスカレーションする。
この経路を隔離環境で練習してください。誰も実行したことのないrunbookは、まだ仮説にすぎません。
対応度スコアではなく、リリースゲートを使う
| ゲート | 必要な証拠 |
|---|---|
| アクセス | スコープ付き認証情報と下流の認可テスト |
| 書き込み | 冪等性と結果不明時の復旧テスト |
| 自律性 | サーバーが強制する実行制限と承認ポリシー |
| 実行 | サンドボックス境界とクリーンアップのテスト |
| 復旧 | チェックポイントからの再開と認証情報の取り消しテスト |
| 診断 | 成功と失敗について一つずつ完全なトレース |
| 振る舞い | 禁止アクションを含む再現可能な評価セット |
合計スコアを使うと、一つの制御の欠落を隠してしまいます。リリース対象のワークフローについて、各行を合格または不合格で判定してください。
以下のプロンプトは、本番環境をテストへ巻き込むことなく、最もリスクの高いワークフロー向けのゲートを作成します。