本番AIエージェントのチェックリスト：インフラ、セキュリティ、信頼性

AIエージェントが本番データへ触れる前に、スコープ付きIDを与え、再試行可能なすべての書き込みを冪等にし、破壊的または金銭的アクションを実行前に止めます。無人で実行する前に、制限付き実行、エンドツーエンドのtrace、検証済みの復旧経路を追加します。

このチェックリストは依存関係の順に並んでいます。後の制御は前の制御に依存します。各失敗が本番エージェントでどの程度起きるかを示す公開データセットはないため、発生確率順ではありません。

エージェントが本番データへ触れる前

各エージェントへスコープ付きIDを与える

• 帰属の記録が必要なエージェント、deployment、sessionごとに個別の認証情報を発行する。
• タスクに必要なtenant、resource、actionだけに制限する。
• ツール説明に読み取り専用と書かれていても、下流serviceで認可を強制する。
• 人間のユーザーアカウント削除とは独立して、認証情報を取り消せるようにする。

共有の管理者キーでは明確な監査証跡を作れず、一つのシークレット漏えいが広範なアクセスにつながります。OWASPのExcessive Agencyガイダンスは、ツール機能、権限、自律性を最小化し、下流システムで認可を強制することを推奨しています。

影響の大きいアクションを実行前に止める

• 破壊的、金銭的、異常に広範な操作には、人間またはポリシーの承認を求める。
• 承認手順で正確なresource、scope、結果を示す。
• 基盤systemが対応していれば、soft deleteなど復元可能な状態変更を優先する。
• 監査ログを保持するが、削除後に書かれた記録を予防制御として扱わない。

Railwayは2026年4月、エージェントがdisk上のaccount-scoped tokenを見つけ、古いvolume削除APIを呼び出したインシデントを公開しました。プラットフォームには4層の認可がありましたが、tokenのscopeと即時削除動作によってアクションは許可されました。Railwayはvolumeを復旧し、APIの削除をdashboardと同じ48時間のsoft-delete期間へ変更しました。このインシデント報告は、スコープ付きIDと、復元可能または承認付きの破壊的経路を組み合わせる具体的な理由を示しています。

書き込みを冪等にする

• 論理操作ごとに一つの冪等性キーを作り、すべての再試行で再利用する。
• サーバーに操作結果を保存し、同じキーが再び現れたらその結果を返す。
• 再利用したキーのparameterが元のリクエストと異なる場合は拒否する。
• キーの有効期間と、失効後の動作を定義する。

StripeのAPIは冪等性キーに対する最初の結果を保存し、キーを最大255文字まで許可します。現在のドキュメントでは、24時間以上経過したキーを削除できると記載されています。これらの数値はStripeの契約であり、普遍的なデフォルトではありません。保持期間は、エージェントで現実的に起こり得る最長の再試行または再開期間をカバーする必要があります。周辺フローは詳細なエージェントの再試行・復旧ガイドを参照してください。

エージェントを無人で実行する前

各実行を制限する

• ツール呼び出し、wall-clock time、モデル支出、同じアクションの反復試行に上限を設ける。
• モデル自身に制御させず、ポリシー上限に達したら停止する。
• read toolよりwrite toolに狭い上限を設ける。
• 認可エラーと検証エラーを繰り返さず、escalateする。

rate limitはエージェントが起こせる損害を減らしますが、安全でない権限を修正しません。IDと認可を設けた後の封じ込めレイヤーとして使います。

モデル、エージェント、ツールをまとめてtraceする

ユーザーリクエスト、model call、tool selection、tool execution、downstream API workを一つのtraceに記録します。tenant、agent identity、tool name、tool-call ID、outcome、duration、policy decisionを含め、シークレットと機密性の高いtool resultを除外します。

OpenTelemetryは現在、GenAIエージェントとツールのspanを定義しています。tool-call identifierやduration attributeも含まれます。これらの共通fieldを使うと、modelとapplication telemetryの間で一つのactionを追いやすくなります。AIエージェントのオブザーバビリティガイドでは、実用的なtrace shapeを紹介しています。

中断と復旧をテストする

• model responseの後だけでなく、外部への副作用が完了した後にcheckpointを永続化する。
• 実行全体をreplayせず、最後に検証したcheckpointから再開する。
• 書き込みを再試行する前に結果不明を照合する。
• エージェント認証情報の取り消しとactive runの停止を練習する。

結果不明は、サーバーがリクエストを完了した可能性がある一方、クライアントがresponseを受け取っていない状態です。復旧では、反復を決める前にoperation recordまたはidempotency keyを確認する必要があります。

利用規模が拡大する前

再現可能な評価セットを維持する

代表的タスク、期待するツール選択、禁止アクション、受け入れ基準を固定します。model、prompt、tool description、permission、retry behaviorを変更した後に評価を実行します。成功したデモでは上記の制御を実行しないため、失敗ケースも含めます。

インシデント経路を文書化する

on-call経路は、失敗したエージェントに頼らず次の4問へ答えられる必要があります。

1. 新しい実行をどう停止するか？
2. 影響を受けた認証情報をどう取り消すか？
3. エージェントはどのresourceとoperationへ触れたか？
4. 完了済みactionをどう復旧または補償するか？

telemetryとbackend stateから答えられなければ、無人の本番作業に対応できていません。

本番投入前に一つのワークフローを監査する

最も広い権限を持つワークフローを選びます。各書き込みについてID、認可ルール、冪等性の仕組み、承認要件、trace field、復旧actionを記録します。空欄を具体的なタスクにすれば、別の一般的なチェックリストは必要ありません。

空欄が最も多い行からテストします。以下のプロンプトは隔離されたCohesivityテナントを作成し、正常な実行と中断した実行を一つずつ試し、失敗した制御を報告します。本番環境は対象外です。