9月24日、AWSが「From portal-hopping to instant answers: HEMA's journey with MCP and Amazon Bedrock」と題した記事を公開した。1926年創業（2026年で100周年）のオランダ小売企業HEMAが、社内知識の断片化問題をMCP（Model Context Protocol）とAmazon Bedrock AgentCoreで解決した実践的な構築事例だ。認証まわりには「DCRのエミュレーション」という一筋縄ではいかない設計判断も登場する。
「ポータルをたらい回し」という技術的負債
HEMAはオランダを代表する小売チェーンで、750店舗以上を複数国で展開する。ITエンジニア、プロダクトオーナー、ビジネスアナリストで構成される技術組織は、デジタル変革の途上にあった。
問題の核心はシンプルだ。「APIへのアクセスを申請するにはどうすれば？」「新しいグループのプロビジョニングを依頼するには？」——こうした手続き的な質問に答えられる「場所」が存在しなかった。サービスカタログ（どのチームがどのサービスを持ち、どのAPIを公開しているか）は整備されていたが、「何が存在するか」は分かっても「どうやるか」は分からないという状況が続いていた。
答えを探すには複数のポータル、Wiki、ドキュメントを渡り歩く必要があり、半日かけても答えが見つからないこともあった。組織が大きくなるにつれ「隣の人に聞けばいい」モデルは破綻し、新人エンジニアのオンボーディングは遅く、回答の品質は担当者によってバラバラになっていった。
HAL：MCPとAmazon Bedrock AgentCoreで作った社内AIアシスタント
HEMAが構築したのはHALと呼ぶ社内AIアシスタントだ。設計思想は明快で、「知識を一か所にまとめ（HALの役割）、その知識をすでに使っているツールの中から引き出せるようにする（MCPの役割）」という2軸で構成されている。
なぜMCPか
MCP（Model Context Protocol）は、AIクライアントとバックエンド機能をつなぐ標準インターフェースだ。各知識ソースをMCPツールとして一度だけ公開すれば、HALのWebチャット、Kiro、Claude、その他のエージェントがカスタム実装なしに同じツールを利用できる。「どの日常ツールからでもアクセスできる」という目標を、ツールごとの個別開発なしに実現するのがMCPの利点だ。
なぜAmazon Bedrock AgentCoreか
Amazon Bedrock AgentCoreは、カスタムMCPサーバーのインフラを自前で立てずに済む点が決め手だった。HEMAが特に重視した機能は以下の通りだ：
- Gateway：OpenAPI仕様とAWS Lambda関数から直接MCPツールを生成。カスタムMCPサーバーコードの記述・運用が不要になるため、チームの運用負荷を最小化できる
- Identity：Microsoft Entra IDによるJWT認証と、内部APIへのOAuth2トークン管理を提供。クライアント側にAWSクレデンシャルを持たせない
- Runtime：Strandsフレームワークで構築したエージェントをコンテナとしてホスト
- Memory / Guardrails：会話履歴の管理とコンテンツフィルタリング。EUリージョンでのオランダ語サポートにも対応
認証設計の核心：DCRエミュレーションという判断
アーキテクチャの中で最も技術的に興味深いのが、外部MCPクライアント向けの認証設計だ。
AgentCore Gatewayは1つのGatewayに1種類のインバウンド認証しかサポートできないという制約がある。内部エージェント用にはIAM SigV4認証を使っているため、外部MCPクライアント（KiroやClaude）向けには別途Entra MCP Gatewayを追加する必要があった。
しかし問題はそれだけではない。外部クライアントがAWSクレデンシャルなしで認証できるよう、MCP認証プロキシ（API Gateway v2 + Lambda）を前段に配置したのだが、MCPクライアントが標準として期待するDynamic Client Registration（DCR）のPOST /registerエンドポイントに対し、実際には固定の事前プロビジョニング済みクライアントIDを返すスタブ実装で対応している。
真のDCRではなく「エミュレーション」だが、この割り切りには合理的な理由がある。エンドユーザーにとってはプロキシURLを設定してブラウザで初回ログインするだけで済み、AWSクレデンシャルを一切扱わずに済む。既存のEntra ID SSOの認証フローをそのまま活用できるため、セキュリティモデルを新たに設計する必要もない。標準への完全準拠よりも実用性と既存資産の活用を優先した、現場感のある設計判断だ。
2段階で成長したアーキテクチャ
Step 1：スタンドアロンのチャットUIとして立ち上げる
最初のHALは、Next.jsで作ったWebチャットUIとStrandsエージェント（Linux/ARM64コンテナ）だけのシンプルな構成だ。まず動くものを最小構成で作り、社内で検証を積み重ねることを優先した。エージェントは2つの経路で知識にアクセスする：
- ローカルツール経由：Amazon Bedrock Knowledge BasesのRetrieve APIを直接呼び出す。IT手順書、API/OpenAPI仕様、KafkaトピックとAvroスキーマ、DCLデータ交換チャネル、サービスカタログ（人・チーム・サービス・API）をRAGで検索する。検索品質向上にはAmazon BedrockのリランキングとチームIDによるメタデータフィルタリングを組み合わせており、初回Knowledge Base検索でカバーできない場合は
fetch_full_documentでドキュメント全体を取得する2ステップ構成だ - MCP経由でAgentCore Gateway：ライブAPIやサービスカタログのルックアップにはGateway経由でIAM SigV4認証を使う。Knowledge Baseへの静的検索では補えないリアルタイム性の高い参照を、こちらで担保している
Step 2：KiroやClaudeなど日常ツールへの開放
HAL自身のチャットUIで動作確認できたあと、外部MCPクライアント（KiroやClaude）からも同じ知識ベースにアクセスできるよう拡張した。前述のEntra MCP GatewayとMCP認証プロキシを追加し、読み取り専用のKnowledge Basesのみを外部に共有する構成とすることで、セキュリティ境界を明確に保っている。既存ツールへの統合を先送りにして内部検証を先行させたのは、知識ベースの品質と認証設計の妥当性を本番投入前に固めるための判断だ。
誰がどう使っているか
HALはエンジニア向けツールとして始まったが、現在はクロスロールアシスタントとして機能している：
- エンジニア：Kiroやチャット内からAPI仕様、Kafkaトピック、サービスカタログを検索
- プロダクトオーナー：手順書やプロセス知識を参照（以前は「どこにも書かれていなかった」層）
- ビジネスアナリスト：どのサービスが存在し、誰が所有しているかをサービスカタログから取得
現在は読み取り専用だが、次のステップは「回答」から「実行」への拡張だ。まず目指すのはAWSアカウントのプロビジョニング——現在は専用ポータルへのアクセスが必要な作業を、チャットやKiroから直接リクエストできるようにする。既存のEntra ID SSOとActive Directoryグループ認可がそのまま使えるため、新たなセキュリティモデルは不要だという。
インフラはすべてAWS CDK（TypeScriptモノレポ）で定義されており、本番投入前に1ヶ月間のステージング環境でエンジニアとビジネスユーザーの双方がハンズオンテストを実施した。
詳細はFrom portal-hopping to instant answers: HEMA's journey with MCP and Amazon Bedrockを参照していただきたい。
