💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

なぜデモ以上の価値があるのか

2026年4月12日 現在、Amazon Bedrock AgentCore は単なる試作向けの足場ではない。AWS は 2025年10月13日 に一般提供を発表し、AgentCore を「任意のフレームワーク、モデル、プロトコルを使って、能力の高いエージェントを安全に大規模運用するためのプラットフォーム」と位置づけた。これは本番エージェントにとって重要だ。デモでは見えない失敗要因として、セッション漏えい、弱いツール権限、記憶の欠如、監査性の不足、ネットワーク境界の曖昧さがあるからだ。

安全な本番エージェントを作るチームにとって、AgentCore の魅力はインフラ接着剤を減らせることにある。GA では VPC、AWS PrivateLink、CloudFormation、resource tagging が追加され、AI 用に別のセキュリティモデルを作らずに、既存の企業統制へ自然に組み込めるようになった。

実際に見るべき問いは、プロンプトを1回回せるかどうかではない。次のような本番ライフサイクルを支えられるかどうかだ。

セッションを分離できるか
ツールアクセスを制御できるか
有用な記憶を保持できるか
失敗と遅延を観測できるか
通常の AWS ガバナンスで段階的に展開できるか

ここまで揃って初めて、デモ用スタックではなく本番プラットフォームと言える。

本番向けのセキュリティモデル

AgentCore の最重要ポイントは、エージェントのセキュリティを後付けではなく設計条件として扱っていることだ。

GA で AWS は Runtime における complete session isolation と 8 時間の実行ウィンドウを明示した。これは本番ではかなり重要だ。実運用のエージェントは長時間・状態保持・非同期の処理になりがちなので、1つのセッションを完全に分離し、何時間動いても他ユーザーの文脈を汚さないことが必要になる。

GA で追加された VPC、PrivateLink、CloudFormation、resource tagging も実務では効く。これにより次のような運用がしやすくなる。

トラフィックを private network boundary の内側に保つ
既存の IaC フローで自動デプロイする
所有者、コスト、監査の追跡を行う
既存のセキュリティ審査に合わせる

規制が厳しい環境や、情報保護が重要な環境では、これらは付加機能ではなく採用可否を決める要素だ。

Runtime: 安全な実行を担う場所

実行の安全性と運用の安定性が重要なら、まず Runtime を見るのがよい。

AWS のドキュメントでは、Runtime はエージェントやツールをホストする secure で serverless な実行環境として説明されている。任意のフレームワーク、任意のモデル、そして MCP と A2A の通信パターンに対応する。重要なのは互換性だけではなく分離だ。各セッションは専用リソースで動き、状態付きの推論が他ユーザーへ漏れないよう完全分離される。

Runtime は次のような用途に向く。

長い文脈を保持するカスタマーサポートエージェント
数時間動くリサーチや計画系エージェント
ツールを呼び出し、待機し、再試行しながら進むワークフローエージェント
役割分担と引き継ぎが必要なマルチエージェント構成

GA で A2A 対応が加わったことも重要だ。エージェント間連携をロードマップに入れているなら、プラットフォームの外に別構成を作る必要がない。

既にコンテナ中心で運用しているチームにとっても、Runtime はモデル API の周囲に独自のオーケストレーション層を積み上げるより、整理された選択肢になりやすい。

Memory: 文脈を便利に、壊れにくくする

エージェントが本当に製品になるかどうかは、記憶が要になることが多い。利用者は継続性を期待するからだ。

AgentCore Memory は、短期記憶と長期記憶の両方を扱う fully managed service だ。短期記憶はセッション内のターンごとの文脈を保ち、長期記憶はセッションをまたいで残すべき事実、好み、要約を保持する。この分離が重要なのは、即時の会話状態と永続的なユーザー知識を切り分けられるからだ。

実務上は次のような設計がしやすくなる。

サポート会話内の継続性
再訪時の好みの保持
長時間タスクの状態維持
プロンプトへの詰め込みと独自の状態管理の削減

ただし、本番で大事なのは「何でも覚えること」ではない。安全で、耐久性があり、本当に役立つ情報だけを残す必要がある。安全なエージェントは、十分に賢く振る舞えるだけの記憶を持ちつつ、制御不能なデータ保管庫になってはいけない。

Gateway: 接着コードなしでツールをつなぐ

AgentCore Gateway は、外部システムを手作業の統合作業なしで使えるようにする要素だ。

AWS は Gateway について、API、Lambda 関数、既存サービスを MCP 互換のツールへ変換できると説明している。既存の MCP サーバーへ接続できる点も重要で、すでに組織内にツール基盤がある場合に特に役立つ。

本番チームにとってこれは重要だ。なぜなら、各ツールはそのままセキュリティ境界でもあるからだ。Gateway は次を集約しやすくする。

認証
クレデンシャル交換
ツール発見
アクセス制御
プロトコル変換

そのため、エージェント層を使い捨てスクリプトの寄せ集めにしたくないチームに向いている。

さらに重要な更新が 2026年2月24日 にあった。AWS は Bedrock Responses API が AgentCore Gateway 経由の server-side tool execution をサポートしたと発表している。つまり、モデルが Gateway のツールを server-side で発見し、実行し、結果を受け取れるため、クライアント側の tool loop を自前で作る必要が減る。本番の安全性という観点では、オーケストレーションの複雑さを減らし、制御経路を AWS 管理の境界に寄せやすくなる。

Observability: 観測できないものは信頼できない

AgentCore Observability は、良い試作を実運用可能なシステムへ変える要素だ。

AWS は AgentCore が CloudWatch と統合し、OTEL 互換フォーマットで telemetry を出力すると説明している。さらに、trace、dashboard、session count、latency、duration、token usage、error rates も示されている。これにより、アプリログだけに頼らない本番フィードバックループを持てる。

エージェントシステムでは、次を把握できなければならない。

どのツールが選ばれたか
どこで処理が遅くなったか
失敗が prompt、tool、policy のどこで起きたか
セッションがどの程度 loop や retry を繰り返したか
セキュリティ制御が正しく効いているか

すでに observability スタックが OTEL に対応しているなら、AgentCore は閉じた専用の telemetry サイロより自然に組み込める。

本番ロールアウトの確認項目

本番投入の前に、次を確認したい。

どのタスクに Runtime、Memory、Gateway が必要かを定義したか
セッション分離と private networking が要件を満たすか確認したか
どのデータを短期記憶と長期記憶に分けるか決めたか
どのツールを許可し、どの ID が使え、どの承認が必要かを書いたか
CloudWatch と既存の OTEL パイプラインに可観測性をつないだか
resource tagging を所有者、コスト、監査のために設定したか
happy path だけでなく failure path も試したか
長時間実行や retry 時の挙動を確認したか
Gateway で API、Lambda、既存の MCP サーバーのどれを公開するか決めたか

これらが明確なら、本番候補としてかなり有望だ。曖昧なら、展開を広げる前にユースケースを絞るのが先だ。

✍️ 필사 모드: Amazon Bedrock AgentCore 実践ガイド: 2026年に安全な本番エージェントを作る方法