こちらの記事は公式チュートリアルを参考にkiroとチャットした会話をまとめた記事になります。

Amazon Bedrock AgentCore とは

Amazon Bedrock AgentCoreはPoCレベルで開発していたエージェントをaws環境に簡単にリリース、管理できるマネージドサービスです。

AgentCore全体アーキテクチャ

6つの核心コンポーネント

コンポーネント	本質的な価値	解決する課題
Runtime	サーバーレスエージェント実行基盤	コンテナ管理の複雑性排除
Gateway	外部リソースのエージェント互換化	API統合の標準化
Memory	エージェントの状態・パーソナライゼーション管理	文脈保持とカスタマイズ
Identity	マルチサービス横断の統一認証	アイデンティティ管理の統合
Tools	セキュアなCode実行 + Web操作	エージェント能力の安全な拡張
Observability	エージェント動作の透明化	トレース・デバッグの統一化

📍 本記事の位置づけ

この記事では、Gatewayに焦点を当て、外部リソースのエージェント互換化について詳しく解説します。

🧠 概要

Amazon Bedrock AgentCore Gatewayは、企業の既存システム群を統一MCPインターフェースに変換し、Semantic Search自動ツール選定機能と二重認証モデルにより、AIエージェントによる企業システム活用を実現する完全マネージドサービスです。

単なるAPI統合ツールを超えた「企業システム統合複雑性の根本解決基盤」として設計されています。

解決する根本課題

現代企業が直面する統合の複雑性は多岐にわたります。まず認証方式の乱立により、API Key、OAuth、IAM、Basic認証など、システムごとに異なる認証方式への個別対応が必要となっています。さらにプロトコルやデータ形式の非統一性により、REST、SOAP、GraphQLなど様々な通信方式とJSON、XML、独自形式などのデータ形式に対応する必要があります。

企業が100以上のシステムを統合する際には、ツール選択の複雑性が指数関数的に増大し、エージェント開発時には各システムとの個別統合コストが膨大になります。加えて、セキュリティ・監査要件が各システムに分散管理されているため、統一的なガバナンスが困難となり、認証情報の手動管理・更新負荷が運用チームに重くのしかかっています。

Gatewayの解決アプローチ

Protocol Translation: 任意のシステム → 統一MCPプロトコル
Authentication Abstraction: 複雑な認証 → 単一JWT認証
Tool Selection Optimization: 手動選択 → Semantic Search自動選定
Infrastructure Management: 個別運用 → 完全マネージドサービス

全体アーキテクチャフロー

実用例: 開発チームでの情報収集自動化

従来の課題: 開発者が障害調査を行う際、コード管理システムでエラーに関連するIssue・PRを手動検索し、ログ監視システムでログを個別確認、チャットツールで過去の議論を検索、タスク管理システムで関連チケットを調査するという、複数システムを横断した情報収集作業が必要でした。

Gateway導入後の改善: 「エラーXXXについて調査して」という一言の指示だけで、コード管理、ログ監視、チャット、タスク管理の各システムから関連情報を自動収集し、統合された調査レポートを生成します。さらに関連する過去の対応履歴も含めて提示されるため、調査時間が大幅に短縮されます。

💭 コメント
認証の抽象化がマジで便利。今まではコード管理システムのAPI Key、CRMのOAuth、クラウドサービスのIAMって全部別々に覚えて管理してたけど、Gatewayなら単一のJWTトークンだけでOK。新しいシステム統合するときの学習コストが激減するのはありがたい。

🔐 1. 二重認証アーキテクチャ

認証の責任分離

Layer 1: Inbound認証（エージェント → Gateway）

JWT Bearer Token検証: 企業IdP（認証基盤）との連携
スコープベース権限制御: 細粒度アクセス制御
セッション管理・監査: 全操作の証跡記録

Layer 2: Outbound認証（Gateway → ターゲットシステム）

API Key自動注入: コード管理システム、外部API等
OAuth Token自動管理: CRMシステム、オフィススイート等
IAM Credentials動的生成: クラウドサービス群
認証情報完全隔離: エージェントから認証情報を隠蔽

一般ユースケース例

ケース: セキュリティ強化された認証情報管理

従来の課題: 開発者が直接認証情報を扱う際のセキュリティリスクが問題となっていました。コード管理システムのAPI Keyが環境変数やSSM Parameter Storeで管理されていても、エージェントコード内で直接取得・使用する必要があり、CRMシステムのOAuth Tokenがログファイルに出力されたり、クラウドサービスの認証情報がアプリケーションの実行時メモリに残存して、デバッグ時やクラッシュ時に意図せず露出するリスクがありました。

Gateway導入後の改善: 認証情報が完全に隔離されます。開発者はJWTトークンのみを知っていれば良く、各システムの認証情報は全てGateway内部で管理されます。エージェントコード、ログ、実行時メモリに認証情報が一切含まれず、OAuth Tokenの期限切れも自動更新で無人運用が実現されます。

💭 コメント
二重認証の設計がエレガント。特に「エージェントが認証情報に触れない」ってのが天才的。これまでのセキュリティリスクが根本的に解決されるし、開発者は認証のことを一切考えずにビジネスロジックに集中できる。これは本当に大きな進歩だと思う。

🧩 2. Target統合3パターン

統合パターンの使い分け

パターン	適用場面	特徴	開発速度
Lambda統合	社内システム・カスタムロジック	完全制御・高カスタマイズ性	中〜低
OpenAPI統合	外部SaaS・レガシーシステム	既存仕様活用・迅速統合	高
Smithy統合	クラウドサービス群	自動生成・標準準拠	高

一般ユースケース例

Lambda統合 - カスタムロジック実装

ケース: 既存Lambda関数のMCPツール化

従来の課題: 既存のLambda関数を個別にMCPサーバーとして公開するには、インフラ管理やホスティングが必要でした。

Lambda統合後の改善: 既存のLambda関数をそのままMCPツールとして利用できます。Gatewayが自動的にツール名やセッションIDを渡し、複数ツールを1つのLambda関数で実装することも可能です。クロスアカウントアクセスにも対応しています。

OpenAPI統合 - 既存資産活用

ケース: レガシー基幹システムのモダナイゼーション

従来の課題: 古い基幹システムが独立して稼働しており、AIエージェントから直接アクセスできない状況でした。システム刷新には大きなリスクとコストが伴うため、既存システムを活用しながら段階的にAI化を進める必要がありました。

OpenAPI統合後の改善: レガシーシステムをSOAP→REST変換でラッピングし、既存の顧客マスタや受注データをOpenAPI仕様で標準化できます。「顧客番号12345の受注履歴を確認」という要求で、レガシーシステムから自動データ取得が可能になり、段階的移行により既存業務への影響ゼロでAI化を推進できます。

OpenAPI統合 - 外部サービス連携

ケース: 外部SaaSサービスとの統合

従来の課題: 外部のCRMサービス、マーケティングツール、決済サービスなどをAIエージェントで活用するには、公式MCPサーバーの発表を待つか、自分でカスタムMCPサーバーを開発するしか選択肢がありませんでした。多くのSaaSサービスは公式MCPサーバーを提供しておらず、自作する場合も各サービスの独自API仕様に合わせた個別開発が必要で、開発・保守コストが高い状況でした。

OpenAPI統合後の改善: 各SaaSが提供するOpenAPI仕様を活用して、公式MCPサーバーを待つことなく、統一されたMCPツールとして自動変換されます。既存のOpenAPI仕様をそのままラッパーとして活用できるため、「顧客情報を更新してマーケティングキャンペーンに追加」といった複数サービス横断の処理が、カスタム開発なしで単一のエージェント指示で実行可能になります。新しいSaaSサービスの追加も、OpenAPI仕様の登録だけで完了します。

Smithy統合 - クラウドサービス群

ケース: クラウドネイティブなデータ分析基盤

従来の課題: 各クラウドサービスへの個別アクセスが必要で、サービス間の連携が複雑でした。新しいクラウドサービスが追加されるたびに、個別の統合コードを開発し、API仕様変更への対応も必要でした。

Smithy統合後の改善: オブジェクトストレージ、NoSQLデータベース、関数実行サービス、監視サービスが自動的にMCPツール化されます。「先月のWebアクセスログを分析して」という指示で、ストレージからログ取得、データベースでメタデータ参照、関数で分析実行が自動化されます。クラウドサービス仕様変更時も自動追従し、IAM Roleベースの細粒度権限制御も実現されます。

💭 コメント
3つのパターンの使い分けが実用的でいい感じ。特にOpenAPI統合の「レガシーシステムのラッパー化」と「外部SaaS連携」の分離は、多くの企業が抱えてる現実的な課題への解決策だよね。既存システムをいじることなく段階的にAI化できるのは、リスクを抑えたい企業にとって超重要。

Simthy統合つかえば aws mcpを利用しなくても簡単にawsサービスを扱えるのかな？

🔍 3. Semantic Search技術

大規模ツール統合問題の解決

従来の限界:
├── 100+ツール → 10,000+トークン消費
├── コンテキスト不足 → 品質低下
├── 手動選択ロジック → 保守負荷
└── 新ツール追加 → 既存修正

Semantic Search解決策:
├── Vector検索 → 関連ツール自動抽出
├── 3-5ツールのみ → コンテキスト効率化
├── 自動学習 → 保守不要
└── 最大3倍高速化 → パフォーマンス向上

動的ツール選定の仕組み

一般ユースケース例

ケース: 大規模SaaS統合環境での自動ツール選定

従来の課題: 企業で100個のSaaSツールを統合した場合、エージェントに全ツールの説明を渡すと10,000トークン以上を消費してしまいます。「CRMで顧客データを更新」という単純な要求でも、無関係なコード管理、クラウドサービス、チャット等のツール説明で大部分のコンテキストが消費され、結果として本来の処理品質が大幅に低下していました。

Semantic Search導入後の改善: 「CRMで顧客データを更新」という要求に対して、自動的にCRM関連の3-5ツールのみが抽出されます。無関係なコード管理、クラウドサービス、チャットツールは除外され、コンテキストの80%を実際の処理に活用可能になり、レスポンス時間が最大3倍高速化されます。

💭 コメント
「エージェントにツール全部渡すんじゃなくて、クエリベースで必要なツールだけ動的選定」ってアプローチが革新的すぎる。これで企業が数百・数千のツール統合しても、エージェントは常に最適な状態で動作できる。従来の静的設計から動的適応への転換は、AIエージェントの実用性を劇的に向上させると思う。

🔐 4. AgentCore Identity統合

従来方式との比較

機能	従来の静的管理	AgentCore Identity
保存方式	静的Key-Value	動的Credential Provider
取得方式	明示的取得	Gateway経由自動取得
Token更新	手動実装	OAuth自動更新
エージェント可視性	取得可能	完全ブラックボックス
監査機能	基本ログ	詳細使用メトリクス

OAuth自動更新メカニズム

無人運用プロセス:
1. 初期設定: 企業IdP（認証基盤）でApp登録・Refresh Token取得
2. 自動監視: Access Token有効期限の事前監視（30分前）
3. 自動更新: 期限切れ前のRefresh Token実行
4. 安全配信: Gateway経由での一時的Token配信
5. 監査記録: 全プロセスのCloudTrail記録
6. 異常対応: 更新失敗時のアラート・手動介入

一般ユースケース例

ケース: オフィススイート統合での自動Token管理

従来の課題: オフィススイートAPI統合において、開発者がOAuth 2.0フローを手動実装し、Access Token（1時間有効）の期限管理を自分で実装する必要がありました。Refresh Tokenでの更新処理を手動実装し、Token期限切れ時のエラーハンドリングを個別対応する必要があり、運用負荷が高い状況でした。

AgentCore Identity導入後の改善: 初期設定で企業認証基盤でのアプリ登録とRefresh Tokenを一度だけ設定すれば、以降は完全自動でToken管理（30分前に自動更新）が行われます。エージェント開発者はToken管理を一切意識する必要がなく、「メール送信」「チャットメッセージ投稿」「ファイル共有」が全て同じ方法で実行可能になります。

💭 コメント
OAuth Tokenの期限切れ問題から解放されるのが最高。今まで「あ、またToken切れてる...」って手動で更新してたのが、全部自動でやってくれる。開発者としてはこういう面倒な作業が減るのは本当にありがたい。

📊 シリーズ進捗状況

#	コンポーネント	リンク
①	Runtime（実行基盤）	公式サンプルを参考にAgentCoreへDeepDive（Runtime）
②	Gateway（統合レイヤー）	👉 本記事
③	Memory（状態管理）	公式サンプルを参考にAgentCoreへDeepDive（Memory）
④	Identity（認証）	準備中
⑤	Tools（実行ツール群）	準備中
⑥	Observability（可観測性）	準備中

🔗 参考

チュートリアル