生成AIエージェントを本番に乗せる前に決める6つのこと — コスト上限・可観測性・ガードレールの設計判断
生成AIエージェントの本番運用で、PoCでは見えないコスト暴走・無限ループ・冪等性事故・監査要件をどう設計するか。AWS（Amazon Bedrock AgentCore）を前提に、ハードキャップ・4テレメトリ層・多層ガードレールのトレードオフ込みで6つの設計判断に整理します。料金・クォータは2026年6月時点の参考値で、公式の最新情報もあわせてご確認ください。
- #生成AIエージェント
- #Amazon Bedrock
- #AgentCore
- #本番運用
- #可観測性
- #ガードレール
- #冪等性
プロトタイプ（PoC）で動いた生成AIエージェントを、そのまま本番に出してよいか――この判断で詰まるケースが増えています。「動く」と「任せられる」は別物で、その差はエージェントのロジックではなく周辺の運用設計にあります。本記事は、Amazon Bedrock AgentCore（AIエージェントを本番運用するためのAWSのマネージド基盤）で本番に乗せる前に決めておくべき6つの設計判断を、設定値とトレードオフ込みのチェックリストとして整理します。出発点は「暴走をどの設定値で止めるか」です。すでにAgentCoreの機能概要を把握している読者を想定しているため、機能紹介は最小限にとどめます。
本番化の4本柱と、PoCで踏むリスク
AWSはエージェント本番化のベストプラクティスを、governance & security（統制・セキュリティ）／ build & operations（構築・運用）／ evaluation（評価）／ observability（可観測性） の4本柱で整理しています。本記事の6判断はこの4本柱にぶら下がります。地図として先に示します。
PoCでは見えにくく、本番で初めて表面化する代表的な事故は3つあります。1回あたり数十円の処理が無限ループで数千円に膨らむ「コスト暴走」、どのステップで何が起きたか追えない「観測の穴」、リトライが副作用を二重に走らせる「冪等性の事故」です。いずれもエージェント本体は正しく動いているように見えるため、PoCの目視確認をすり抜けます。
各判断は「PoCで見えない → 本番で効く設定 → トレードオフ」の3点で見ていきます。
判断① コスト上限・暴走防止（ハードキャップ）
最初に決めるべきは、暴走を止めるハードキャップです。AgentCore Harness は「runaway agent（暴走したエージェント）がリソースを焼き切らないよう上限を設ける」ための項目を持ち、1呼び出し単位で上書きできます。
| パラメータ | 制御対象 | 既定値 |
|---|---|---|
maxIterations | 1呼び出しの推論・行動サイクル数 | 75 |
timeoutSeconds | 1呼び出しの実時間タイムアウト | 3600 |
maxTokens | 1呼び出しのトークン予算 | 既定なし（上限なし） |
idleRuntimeSessionTimeout | アイドル状態で warm を保つ秒数 | 900 |
maxLifetime | セッションの最大寿命（秒） | 28800（8時間） |
ここで見落としやすいのが maxTokens です。既定では上限がなく、明示しない限りトークンは青天井で消費され続けます。コスト事故の主因になりやすいため、本番では必ず値を設定します。これらのHarness設定の下支えとして、Runtime側に調整できない固定上限もあります。同期リクエストは15分、非同期ジョブは最大8時間、ストリーミングは最大60分、ペイロードは100MB、1セッションあたり2 vCPU・8GBです。InvokeAgentRuntime のレート25 TPSやアクティブセッション数は調整可能なクォータです。コンテキストの肥大には --truncation-strategy（sliding_window か summarization）で対処し、コスト配賦タグはCloudFormationのリソースまで伝播させておきます。
トレードオフは明確です。上限を絞るほど安全ですが、打ち切りによってユーザー体験は悪化します。タグ設計を最初に決めておかないと、後からコストの発生源を特定するのが難しくなります。
判断② 可観測性（4テレメトリ層）
AgentCore Observability は、無設定でも session count・latency・duration・token usage・error rates をCloudWatchのダッシュボードでリアルタイムに取得でき、OTEL（OpenTelemetry）互換です。計装の網羅性を確認する物差しとして、AWS公式は4つのテレメトリ層を示しています。
| テレメトリ層 | 取得対象 | SLOへの接続例 |
|---|---|---|
| Agent & framework | 推論ステップ・モデル呼び出し・ツール呼び出し | 思考の停滞・ツール失敗率 |
| Service | 依存するAgentCoreサービス内部（memory読み書き等） | 依存先の遅延 |
| Infrastructure | runtimeコンテナなどホスト環境のメトリクス | リソース枯渇 |
| Application | 複数エージェント横断の業務メトリクス | 業務SLOの達成率 |
ハマりどころは、初回のトレース表示の前に、CloudWatchの「Transaction Search」をアカウント単位で1回だけ有効化する必要がある点です。これを忘れると、無設定で生成されているはずのトレースが画面に出てきません。観測にも従量課金がかかります。取り込みは段階制（0〜10TBが$0.35/GB、10〜30TBが$0.20/GB、30〜72TBが$0.15/GB）、インデックスは取り込み済みの1%まで無料で超過分が100万スパンあたり$0.75、無料枠は3か月です（いずれも2026年6月時点の参考値で、東京リージョンの実値は公式の料金表でご確認ください）。
トレードオフは「入れるか否か」ではありません。SLO（latency や error rate の目標）に紐づけて、何を見たらアラートを出し、何が起きたら止めるかを決めることが本質です。token usage はコストと品質の両面から見ます。
判断③ ガードレール（多層防御の置きどころ）
安全策は1か所では足りません。確率的に検知する仕組みと、決定論的に止める仕組みを多層で配置します。
| 形態 | 挟む位置 | 自動遮断 | 補足 |
|---|---|---|---|
| インライン（Converse統合） | モデル呼び出し時 | あり | Converse APIに統合された標準形 |
| ApplyGuardrail | 任意テキスト | あり | 恒久ポリシーで非Converseモデルもラップ |
| InvokeGuardrailChecks | 各ステップ・リクエスト単位 | なし（検知のみ） | スコアを返し、遮断はアプリ実装 |
2026年6月に追加された InvokeGuardrailChecks は、guardrailリソースを作らずに各ステップへ適用できる軽量な検知APIです。detect-only、つまり自動でブロックせずスコアを返すだけで、遮断や再試行はアプリ側で実装します。対応するのはコンテンツフィルタ・プロンプト攻撃・PII（31種）で、denied topics・contextual grounding・word filters は非対応です（料金はコンテンツ$0.07、プロンプト攻撃$0.08、PII$0.10 / 1,000 text units・参考値）。これと別に、ツール呼び出しを実行前に毎回チェックする決定論的な制御として Policy（2026年3月GA）があり、ルールは自然言語または Cedar（AWSのオープンソースのポリシー記述言語）で書け、Gatewayと統合します。
トレードオフは、確率的な検知（Guardrails）を過信しないことです。detect-only は遮断までは行わないため、決定論ガード（Policy/Cedar）と組み合わせます。チェックを増やすほどレイテンシ（応答にかかる時間）とコストは増えます。InvokeGuardrailChecks の詳細はBedrock Guardrails の新API解説で扱っています。
判断④ セッション・冪等性・実行寿命
セッションは分離され、同期は15分、非同期は最大8時間で動きます。maxLifetime（既定28800）と idleRuntimeSessionTimeout（既定900）で、warm保持のコストとコールドスタートのどちらを取るかを設定値で決めます。
本番設計で最も誠実に線引きすべきなのが冪等性です。AgentCore のRuntime/Harnessに、ツール呼び出しの組み込み冪等性（exactly-once）保証は見当たりません＝アプリ側の責任です。むしろ公式は利用者側に実装を求めています。Gatewayインターセプタのベストプラクティスでは「Gatewayは失敗やタイムアウト時にインターセプタのLambdaへリトライしうるため、idempotencyキー・処理済みの追跡・ステートレス設計で重複呼び出しを安全に扱うこと」とされ、スロットリング（流量制限）や競合時はアプリ側で指数バックオフ（再試行間隔を段階的に広げる方式）とリトライを行うよう指示されています。なお CreateAgentRuntime などが持つ idempotency トークンは、リソース作成の重複を防ぐためのものであり、副作用を伴うツール実行を保証するものではありません（混同に注意します）。
トレードオフは副作用にあります。課金・送信・書き込みといった副作用を持つツールは、冪等キーで二重実行を防ぐのがアプリの責任です。「リトライで二重決済」はPoCではまず露呈しません。
判断⑤ 監査・ログ（説明責任）
受託案件では「誰が・どのエージェントに・何をさせたか」を後から説明できることが効いてきます。Harnessの操作はCloudTrailに記録され、管理イベント（CreateHarness／UpdateHarness／DeleteHarness／GetHarness／ListHarnesses）とデータイベント（InvokeAgentRuntime など）が残り、リソース型は AWS::BedrockAgentCore::Runtime です。
| 残すログ | 目的 | 勘所 |
|---|---|---|
| CloudTrail 管理イベント | 構成変更の追跡 | 誰が設定を変えたか |
| CloudTrail データイベント | 実行の追跡 | 量と課金に注意 |
| Observability トレース | 振る舞いの再現 | SLOと突き合わせ |
認証は既存のIdP（Cognito・Okta・Microsoft Entra ID・Auth0）と互換で、トークンVaultを持ち、VPC/PrivateLinkにも対応します。トレードオフは、データイベントが量と課金に直結する点です。監査要件に必要な粒度を見極めて取得します。
判断⑥ 評価（eval）とリリースゲート
最後に、品質を本番で担保する仕組みです。AgentCore Evaluations（2026年3月GA）は、エージェントやツールの品質を自動・データドリブンに評価し、Strands Agents や LangGraph のセッション・トレースに対応して、結果はObservabilityに統合されます。
トレードオフというより、運用への切り替えです。「目視で動いた」で止めず、回帰評価用のデータセットと本番トレースで継続的に評価します。品質低下を観測したらevalで定量化し、リリース判断に戻す――この回し方をパイプラインに組み込みます。
まとめ：本番化チェックリスト
6つの判断を1枚にまとめます。本番に出す前に、それぞれの「効く設定」と「トレードオフ」を埋められるか確認します。
| 判断 | 効く設定 | 主なトレードオフ |
|---|---|---|
| ① コスト上限 | maxIterations/timeout/maxTokens・タグ | 安全性とUXの打ち切り |
| ② 可観測性 | 4テレメトリ層・Transaction Search | 観測コストとSLO設計 |
| ③ ガードレール | 検知（detect-only）＋決定論（Policy/Cedar） | レイテンシ・コスト増 |
| ④ 冪等性 | 冪等キー・指数バックオフ（アプリ責任） | 副作用の二重実行 |
| ⑤ 監査 | CloudTrail・Identity連携 | データイベントの量と課金 |
| ⑥ 評価 | AgentCore Evaluations・継続評価 | 目視からデータ駆動への移行 |
「動いた」から「任せられる」への距離は、この6つを設定値とトレードオフで決め切れるかにかかっています。料金やクォータは改定されうるため、本番投入前に公式の最新情報をあわせてご確認ください。AgentCore全体の機能構成はAmazon Bedrock AgentCore とはで整理しています。