11月5日、AWSが「How U Mobile built agentic telco operations with Amazon Bedrock AgentCore」と題した記事を公開した。マレーシアの通信キャリア U Mobile が Amazon Bedrock AgentCore を用いて構築した自律型ヘルプデスクシステム「AiDaH」の実装詳細について詳しく紹介されている。
トラブルチケットが最大84.5%減——通信キャリアのエージェント実運用事例
AIエージェントの「実運用事例」は依然として少ない。U Mobileのケースが注目を集めるのは、150以上の業務シナリオを本番稼働でカバーし、特定カテゴリのトラブルチケット件数を最大84.5%削減という具体的な数字を出しているためだ。元記事によれば、この削減効果はITヘルプデスク向けL2サポートの一般的な問い合わせカテゴリを対象に計測されたものであり、システム稼働後の複数クォーターにわたる運用データに基づくとされている。
U MobileはマレーシアのMVNO（仮想移動体通信事業者）から出発した5Gキャリアで、少人数での効率運用を軸に成長してきた。ITヘルプデスクの課題は多くの企業と共通している。サポート担当者がひとつの問い合わせを解決するために、ログ確認・加入者資格照会・ナレッジベース参照といった複数システムをまたいだ手作業が発生し、解決できなければバックエンドIT部門にエスカレーションされる。
AiDaH（AI-Driven Agentic Helpdesk）はその構造そのものを変えるために作られた。
アーキテクチャ：6層構造とコスト最適化されたルーティング
AiDaHはAmazon Bedrock AgentCore上に構築され、アジアパシフィック（シンガポール）リージョンで動作する。スタッフのインターフェースはMicrosoft Teamsで、新しいアプリを覚えさせるのではなく「すでに使っている場所に持ってくる」設計だ。
6層のアーキテクチャの中で特にエンジニアが注目すべきはLayer 2（オーケストレーション層）のルーティング設計だ。
すべてのリクエストは3段階のコスト最適化ルーティングを通る：
- **約70%**：決定論的なキーワードマッチングで処理。LLMを含むモデルの呼び出し自体がゼロ（タイトルで「LLM不使用」と表現しているのはこの意味で、単に軽量モデルに切り替えるのではなく、推論ステップそのものが発生しない）
- **約20%**：軽量分類モデルで処理
- **約10%**：フルオーケストレーターが必要なケースのみ
「とにかくLLMに投げる」ではなく、最も安い経路で確実に処理できるものを先に振り分ける構成だ。本番規模でエージェントを動かす際のコスト管理として参考になる。
各層の役割は以下のとおり：
| 層 | 役割 |
|---|---|
| Layer 1（スタッフIF） | Microsoft Teams / Webポータル。バックエンドはAWS Lambda + REST API |
| Layer 2（オーケストレーション） | ルーティング、RBAC、ガードレール |
| Layer 3（スペシャリストエージェント） | CRM、番号ポータビリティ、SIM管理など8種のエージェント。A2Aプロトコルで相互委譲 |
| Layer 4（ゲートウェイ） | AgentCore GatewayがMCPインターフェースでバックエンドを統一公開 |
| Layer 5（データ・知識） | Amazon Bedrock Knowledge Bases（RAG）、OpenSearch Serverless、DynamoDB |
| Layer 6（業務システム） | オンプレミスシステムへはAWS Transit Gateway + Site-to-Site VPN（IPsec）経由 |
新しい業務ドメインを追加する際は、Layer 4にゲートウェイとMCPツール定義を追加するだけで済む。Layer 1〜4は変更不要という設計が、スケールアウトのコストを低く保つ鍵になっている。
「エージェント協調」の実装：A2AプロトコルとMCP
Layer 3には8種のスペシャリストエージェントが存在し、それぞれ担当ドメインが分かれている。元記事に挙げられている例では、CRM照会エージェント・番号ポータビリティエージェント・SIM管理エージェント・業務支援システムエージェントなどが含まれる。各エージェントは単独では解決できないクロスシステムのワークフローが発生した際に、Agent2Agent（A2A）プロトコルを通じてサブタスクを相互委譲し合う。
たとえば「番号ポータビリティの照会」がバックエンドで請求ブロックを原因としていた場合、ポータビリティエージェントが業務支援システムエージェントに処理を委譲し、結果を統合して一つの回答として返す。複数システムにまたがる問い合わせでも、スタッフからは単一の会話ターンで完結して見える点が実運用上の価値だ。
バックエンドとの接続にはModel Context Protocol（MCP）を採用。AgentCore Gatewayが各バックエンドをMCPツールとして公開しており、エージェントはツール名とスキーマで呼び出せる。個別のハードコード統合は不要だ。OAuth認可はAmazon Cognitoがブローカーし、センシティブなデータはモデルに渡る前にゲートウェイでマスキングされる。
セキュリティ設計：加入者データと課金システムを扱うための多層防御
加入者データや課金システムに直接触れるシステムである以上、セキュリティ設計は詳細に記述されている。
- スタッフはMicrosoft Entra ID経由でフェデレーション認証し、AgentCore Identityが短命トークンを発行
- 6階層のRBACがエージェント・ツール・データソースごとにアクセス権を制御
- すべてのプロンプト・ツール呼び出し・レスポンスはAgentCore Observabilityを通じてAmazon CloudWatch Logsに記録
- コンピュートはすべてプライベートVPCサブネット内で動作
- 暗号化キーはAWS KMSで管理
AiDaHはすでにU MobileのL2サポート標準業務手順書（SOP）に組み込まれ、運用監査の対象となっている。
開発の経緯
プロジェクトはAWSパートナーのAxrailと共同で進められた。「大きく考え、小さく始める」方針のもと、記事公開時点（2026年）から遡ると約1年前にあたる2025年末、まず2エージェントのパイロットとして概念実証を開始した。2026年Q1に4エージェント・20シナリオで社内ITヘルプデスクを稼働させ、Q3には8エージェントでL2コールセンターおよびブランチの50ユーザーに展開。現在は6事業部門にまたがる150以上のシナリオをカバーするまでに成長した。約3クォーターで2エージェントから8エージェント・150シナリオへと段階的に拡張できた点は、設計の拡張性を裏付けるデータとして元記事でも強調されている。
詳細はHow U Mobile built agentic telco operations with Amazon Bedrock AgentCoreを参照していただきたい。
