AI エージェントを本番環境にデプロイするには：デモから復旧・可観測性・ロールバックに対応した本番リリースまでのガイド

本番リリースへのロードマップ：まず境界を定義し、項目ごとに受け入れ確認

AIエージェントを本番環境にデプロイする際に重要なのは、モデルを増やしたりオーケストレーションを複雑にしたりすることではありません。タスクが失敗したときに状況を判断して復旧でき、変更時には検証して元に戻せるようにすることです。タスクと完了条件の定義、実行構成の選定、ランタイムと状態ストアの構築、セキュリティ境界の実装、代表的なタスクによる評価の順に進め、その後、一部のトラフィックで段階的にリリースし、当番体制とロールバックの手順を整えることを推奨します。

まず、起動条件、入力、呼び出しを許可するツール、最終的な業務成果、タイムアウト時の処理、人手による確認ポイントを明確にします。固定の処理フローで要件を満たせる場合は、「エージェント化」のためだけにマルチエージェントを導入する必要はありません。ワークフローとエージェントの使い分けについては、エージェントの構築方法に関する Anthropic の解説を参照してください。システムインターフェースとの接続とツールの権限については、AIエージェントを企業の既存システムと連携させる方法で詳しく説明しています。

デプロイ構成の選択：制約に応じて判断する

以下の表はアーキテクチャ上の制約を比較するためのものであり、性能や価格に関する結論を示すものではありません。候補となるプラットフォームの機能、クォータ、運用責任は、各プラットフォームの最新ドキュメントで確認してください。

モデル API 経由で推論を利用する場合、通常、デプロイの対象となるのはアプリケーションのランタイム、管理下のツール、状態管理サービスです。推論環境を自前で構築するかどうかは、レイテンシー、データ境界、モデルの可用性、運用要件に基づいて別途評価します。Kubernetes Deployment のドキュメントでは、ローリングアップデートとリビジョンのロールバックの仕組みを参考にできますが、Agent を必ず Kubernetes にデプロイしなければならないわけではありません。

最小限の本番アーキテクチャ：リクエスト、実行、状態、オブザーバビリティをつなぐ

调用方 → 鉴权入口/请求校验 → 任务执行器（同步短任务或异步任务 ID）
      → Agent 运行逻辑 → 模型端点/受控工具 → 状态存储与结果核验
      → 日志、指标、追踪与告警

短いタスクでは結果が返るまで待機できます。呼び出し元の待機可能時間を超える場合や、プロセスをまたいだ復旧が必要な場合は、タスク ID を返し、クライアントが状態を照会するか、完了通知を受け取る方式にできます。タスクの状態、キャンセル時の動作、タイムアウトの範囲、結果の読み取り権限を定義します。

システム連携の詳細はここでは繰り返さず、前述の AI Agent を企業の既存システムと連携させる方法を参照してください。オンコール対応とエンジニアリング連携の役割分担については、FDE のエンジニアリングデリバリーにおける責務と連携範囲を参考にできますが、具体的な責任はプロジェクト内で明確にする必要があります。

リリース成果物の準備：変更を再現可能にする

コード、依存関係のロックファイル、実行用イメージ、環境設定、プロンプトテンプレート、モデルとツールの設定バージョンを変更記録に含めます。依存関係はビルド時に検証し、開発・テスト・本番環境を分離します。認証情報は管理された設定の仕組みを通じて注入し、コードリポジトリや通常のログには書き込みません。モデル API キー、ツールサービスの認証情報、業務用の ID はそれぞれ個別に管理します。

リリースチェックリストでは、少なくとも以下を確認します。

• 実行エントリーポイント、ヘルスチェック、リソース制限、終了シグナルの処理が検証済みであること。
• 依存関係のバージョン、イメージのダイジェスト、設定変更を追跡できること。
• プロンプト、ツールの契約仕様、モデル識別子、主要パラメーターのバージョンが記録されていること。
• 回帰テスト用サンプルと評価結果をリリースバージョンに紐付けられること。
• ロールバック先のバージョンが起動でき、現在の状態形式を読み取れるか、処理を明示的に拒否できること。

長時間タスクの復旧：チェックポイントは業務処理の厳密な1回実行を保証しない

復旧可能性には、タスクの記録、実行状態、業務上の副作用という3つの層が関わります。タスクがキュー待ち、実行中、人による対応待ちのいずれにあるか、どのステップまで実行したか、外部システムへの書き込みが成功したかを把握する必要があります。会話テキストを保存するだけでは実行時の状態を復元できるとは限らず、チェックポイントがあるだけでも外部への書き込み結果を確認できるわけではありません。

LangGraph を例にすると、ドキュメントでは、スレッドごとに実行状態を保存する checkpointer と、スレッド間でデータを共有する store を区別しています。プロセスの再起動後に復元するには、適切な永続化バックエンドを用意し、書き込み、読み取り、分離、保持、障害復旧を検証する必要があります。インメモリ型の保存機構を、再起動をまたぐ永続性の根拠にすることはできません。詳しくは LangGraph の永続化ドキュメントをご覧ください。

リトライ戦略では、試行ごとのタイムアウト、リトライ可能なエラー、リトライ回数を使い切った後の処理を区別する必要があります。副作用を伴うツールには、冪等性キーや重複排除の仕組みを設け、リトライ前に業務処理の結果を照会します。呼び出しがタイムアウトしても、書き込みが行われていないとは限りません。結果を確認できない場合は、人手による照合に切り替えるか、補償処理を実行します。チェックポイント、キュー、リトライだけでは、エンドツーエンドの exactly-once は保証されません。LangGraph の障害処理ドキュメントを参照してください。

セキュリティ制御：高リスクな操作にブロック条件を設定する

リリース前に、少なくとも以下を検証します。

• 外部ドキュメント、ウェブページ、ユーザー入力によって、ツールの権限が勝手に拡大されないこと。
• ツールサービスが呼び出しごとに認証情報、リソースの範囲、パラメーターを検証し、影響の大きい操作には人による明示的な確認を必須とすること。
• 認証情報を環境ごとに分離し、ローテーション可能にすること。また、機密性のレベルに応じてログの記録内容を最小限に抑え、マスキングし、保持期間を設定すること。
• 承認記録を、リクエスト、操作者、実行予定の操作、最終的な業務処理の結果に関連付けること。
• 権限逸脱、プロンプトインジェクション、重複送信、機密データの漏えいのテストで、想定どおりに拒否されること。

OWASP のエージェント型 AI の脅威と緩和策に関する資料は、脅威リストの作成に役立ちますが、本システムの安全性やコンプライアンスを証明するものではありません。

評価ゲート：結果とプロセスの両方を確認する

エージェント自身の「完了しました」という報告を、受け入れ判定の根拠にしないでください。タスクの種類ごとに、対象レコードの状態、出力形式、禁止操作など、環境内で検証可能な成功条件を定義します。実行トレースを保存し、計画、ツール呼び出し、結果検証のどこで失敗したかを特定できるようにします。Anthropic によるエージェントの評価手法の解説も参考になります。

テストケースには、正常な入力、フィールドの欠落、矛盾する情報、ツールのタイムアウト、権限による拒否、重複リクエスト、外部コンテンツによる誘導を含めます。重要なケースは複数回実行し、結果のばらつきを記録するとよいでしょう。リリースゲートには、タスクの結果、禁止操作、例外処理、復旧訓練、人への引き継ぎ経路を含めることができます。しきい値は、業務リスク、既存のベースライン、テスト結果に基づいて設定します。

モニタリング：品質、レイテンシ、復旧、コスト

各指標について、定義・算出基準、収集箇所、アラート条件、責任者を定めます。

トレースは複数ステップにわたる実行のずれを特定するために、業務の最終状態はタスクの完了を確認するために使用します。ログのマスキング対象フィールド、アクセス範囲、保存期間はプロジェクトごとに決定する必要があります。リリース初期にベースラインを観測し、その後、業務リスクに応じてアラートのしきい値を調整します。

段階的リリース、ロールバック、処理中タスクへの対応

リリース前に、コード、プロンプト、モデル設定、ツールのインターフェース仕様の組み合わせに対して回帰テストを実施します。まずはトラフィックを限定するか、低リスクのタスクで検証し、その後、段階的に対象を拡大します。業務結果の異常、権限逸脱テストの失敗、エラーや遅延がチームで定めた許容範囲を超えた場合など、停止条件を設定します。

障害発生時は、新規タスクの受け付けを一時停止するか、高リスクのツールを無効化し、実行中・待機中・完了済みのタスクを洗い出して、外部システムへの副作用を確認したうえで、検証済みのバージョンに戻します。旧バージョンが現在の状態データ形式と互換性を持つか確認してください。自動復旧できないタスクは人に引き継ぐか、承認済みの補償処理を実行します。Kubernetesを採用している場合は、Kubernetes Deploymentをリリースの参考にできます。アプリケーションをロールバックしても、すでに行われた業務データの書き込みが自動的に取り消されるわけではありません。

学習用演習：障害注入で復旧経路を検証する

以下は学習用の演習設計であり、顧客事例や実測結果ではありません。タスクを「レポートを生成し、人による確認後に結果を書き込む」と設定し、毎回、期待する結果、実際の結果、証拠を記録します。

演習では、業務の状態、実行記録、期待する結果が一致しているかを照合し、異常が発生したタスクの責任者と対応手順を明確にする必要があります。

本番リリースの受け入れチェックリスト

• タスクの範囲、完了の定義、禁止操作、人による確認ポイントが文書化されている。
• デプロイ形態が、タスクの実行時間、復旧要件、チームの運用能力に適合している。
• 依存関係、イメージ、プロンプト、モデル設定、ツールのインターフェース仕様を追跡できる。
• タスクの状態、永続化、業務上の副作用をそれぞれ検証でき、リトライ時の冪等性が確保されている。
• 権限、プロンプトインジェクション、機密情報を含むログ、人による承認に関するテストに合格している。
• 評価が、代表的なタスク、異常ケース、結果の検証、復旧シナリオを網羅している。
• 指標の定義、アラートの対応責任者、段階的リリースの停止条件、オンコール対応手順が確認されている。
• ロールバック先のバージョン、処理中タスクへの対応、状態データの互換性、業務上の補償処理の手順について演習済みである。

デプロイに関するよくある質問

質問：Kubernetes は必須ですか？ 回答：必須ではありません。既存のプラットフォームがタスクの実行時間、状態の復元、ネットワーク分離、運用の要件を満たしているなら、エージェントのためにクラスターを複雑化する必要はありません。

質問：エージェントのデプロイにはモデルの自前運用が必要ですか？ 回答：必須ではありません。モデル API 経由で推論を利用する場合、通常はアプリケーションランタイム、管理下のツール、状態管理コンポーネントをデプロイすれば十分です。推論基盤を自前で運用する場合は、データの取り扱い範囲、レイテンシー、可用性、運用要件を別途評価します。

質問：サービスを再起動するとタスクは失われますか？ 回答：タスクの記録、実行状態の永続化、復旧手順の検証状況によります。プロセス内のメモリーだけでは再起動後の復旧に対応できません。重複実行を避けるため、外部への書き込みが成功したかどうかも確認する必要があります。

質問：リトライによる重複書き込みを防ぐには？ 回答：業務操作に冪等性キーや重複排除用の記録を設け、リトライ前に外部システムの状態を確認します。確認できない場合は自動リトライを停止し、人手での照合や補償処理に切り替えます。

質問：本番リリースの成功率のしきい値はどの程度に設定すべきですか？ 回答：共通の基準値はありません。タスクのリスク、業務上の基準値、テスト結果に基づいてリリース判定基準とアラートを設定し、禁止操作の防止、人による引き継ぎ、復旧、業務成果もあわせて検証します。