U MobileがAmazon Bedrock AgentCoreでエージェンティックな通信事業者オペレーションを構築した方法

マレーシアで最新の5GネットワークプロバイダーであるU Mobileは、これまで一貫して少ないリソースでより多くを達成するために、継続的な自動化によって通信事業者オペレーションを効率的に運営してきました。新しいAI機能が利用可能になると、U Mobileは基本的な生産性向上を超えてオペレーション効率を高める方法を模索しました。本当の機会は、オペレーションチームが問題をどのように診断・解決するかという、より上流の段階にありました。同じリーンな運営規律がAiDaHの基盤を形作りました。それは単発の技術イニシアチブではなく、複雑さを増やすことなくオペレーションを簡素化し、能力を拡大するという長期にわたる取り組みの次のステップでした。

契約者がデータアドオンを購入できない場合、その解決は単一の問題ではありません。それは調整の問題です。カスタマーサービスエージェントは、エラーコードのためにインターフェースログを取得する必要があります。同じエージェントがその後、契約者の利用資格を確認するためにビジネスサポートシステムのAPIを照会し、適用可能なビジネスポリシーについて内部ナレッジベースを相互参照しなければなりません。それらはすべて、返信の一文を書き始める前に、複数のシステムにまたがって行われます。そしてそれが失敗すると、チケットはバックエンドITチームにエスカレーションされ、契約者はさらに長く待たされることになります。

従来の自動化ツールは、エージェントがより良い返信文を作成する手助けはできます。しかし、複数のシステムを操作し、結果を分析し、是正措置を提案することはできません。このギャップを埋めるには、Amazon Bedrock AgentCore上に構築されたエージェンティックアーキテクチャが必要です。

U Mobileの情報システム部門（ISD）はまさにそれを構築しました。AWSおよびAWSパートナーのAxrailと協力し、任意のフレームワークやモデルを使用して大規模にエージェントを構築、接続、最適化するためのプラットフォームであるAmazon Bedrock AgentCore上に、AI-Driven Agentic HelpdeskであるAiDaHを作成しました。この選択を決定づけたのは2つの機能でした。マネージド型のエージェントランタイムにより、運用すべきエージェントインフラが不要になりました。組み込みのメモリにより、別途ステートストアを立ち上げることなく、ターンをまたいで会話のコンテキストを保持できました。この取り組みを開始して1年以内に、AiDaHは6つの事業部門にわたる150以上のドキュメント化されたオペレーションシナリオを処理するようになりました。U Mobileの社内測定では、主要カテゴリで障害チケットの件数が最大84.5%減少しています。

この記事では、AiDaHの背後にある6層アーキテクチャを解説します。その後、プラットフォームの下にあるセキュリティ基盤について説明し、最後にチームが構築に使用したスペック駆動型手法について簡単に触れます。

課題：多すぎるシステム、多すぎる摩擦

U MobileのIT環境は、現代の通信業界に典型的な複雑さを反映しています。ビジネスサポートシステムと顧客関係管理システム、モバイル番号ポータビリティプラットフォーム、ビッグデータ分析、そしてインフラストラクチャ監視ツールが、オンプレミスとクラウドのハイブリッド環境で稼働しています。

AiDaH導入前は、この断片化のため、日常的な診断でさえ、別々のシステムやポータルにまたがって、ログの手動確認、契約者の利用資格の照会、ビジネスポリシーに関するナレッジベースの参照が必要でした。参照のたびにコンテキストスイッチが発生し、コンテキストスイッチのたびに時間が失われ、解決されない問い合わせのたびにバックエンドITチームへのエスカレーションが発生していました。カバレッジを追加のオペレーションドメインに拡大すると問題はさらに悪化しました。新しいシステムが追加されるたびに、通常は専用の統合が必要になるためです。

ISDチームの戦略は3つの柱の上に成り立っていました。

1. Reach（リーチ）：バックエンドシステム全体をリアルタイムで連携するエージェント。
2. Depth（深さ）：複数ステップの根本原因分析のための思考連鎖（chain-of-thought）推論。
3. Community（コミュニティ）：ロールベースのアクセス制御と組み込みガードレールを備えた、安全なマルチテナントフレームワーク。すべての部門が利用可能。

その歩み：ナレッジベースからエージェンティックプラットフォームへ

AiDaHは「大きく考え、小さく始める」という原則から始まりました。U Mobileは2025年末に、2つのパイロットエージェントと、フルマネージドの検索拡張生成（RAG）機能であるAmazon Bedrock Knowledge Basesを使って構想を開始しました。2026年第1四半期のパイロットでは、4つのエージェントと20のオペレーションシナリオで社内ITヘルプデスクをオンラインにしました。2026年を通じてプラットフォームは強化・拡大され、3層ルーティングを追加し、年央までに6つのエージェントに到達しました。AiDaHは2026年第3四半期に8つのエージェントで、L2コールセンターおよび支店の50人のユーザーに対して本番稼働し、現在は150以上のドキュメント化されたオペレーションシナリオをカバーしています。

エージェンティックとは実際に何を意味するのか

従来のAIアシスタンスとエージェンティックAIの違いは、実際の例を通して最もよく示せます。

従来のAIアシスタントでは、「海外でモバイルデータが使えない」という問い合わせを対応するサポートエージェントは、返信文の作成やトラブルシューティング手順の提案などの支援を受けられますが、ローミング状況の確認、利用資格の検証、チケットの起票、最終返信の送信は依然として手動で行う必要があります。

AiDaHでは、システムが自律的に契約者のローミング設定を確認し、国際データの利用資格を検証し、具体的な障害箇所を特定します。そして復旧計画を組み立てます。どのサービスをリセットするか、どの設定をプッシュするか、ネットワークチケットが必要かどうかです。サポートエージェントが確認して承認すると、アクションが実行されます。以前はエージェントの時間を消費していた調査が、最初の一文を読む前に完了しているのです。人間による判断のポイントは、重要な場所で保持されています。稼働中の契約者アカウントに何かが変更されるその瞬間に。

ある本番ケースでは、契約者がアドオンを購入できないと報告しました。AiDaHはこの障害を「Subscriber has pending order」というエラーコードにまで突き止めました。さらに、その顧客が3日間にわたり複数のチャネルを通じて同じ購入を30回以上試み、すべての試みが同じ根底にある保留中の注文によってブロックされていたことも明らかにしました。AiDaHは根本原因と修正手順を一回の応答で提示しました。以前はこれに複数のシステムにわたる手動調査が必要でした。

アーキテクチャ:6つのレイヤー、1つのインターフェース

AiDaHはAmazon Bedrock AgentCore上に構築されたレイヤードアーキテクチャで動作し、アジアパシフィック(シンガポール)リージョンにデプロイされています。スタッフはMicrosoft Teamsを通じてやり取りします。これは、多くのユーザーが既に作業している場所で対応するという意図的な選択であり、新しいアプリケーションを学ぶ必要もポータルの切り替えもありません。

次の図は、各レイヤーがどのように組み合わさっているかを示しています。

図1:AiDaHのレイヤードアーキテクチャ

図1に示すように、プラットフォームは6つのレイヤーで構成されています。

レイヤー1:スタッフインターフェース

スタッフはMicrosoft Teamsおよび、Amazon CloudFrontで提供されAWS WAFで保護されたウェブポータルを通じてAiDaHにアクセスします。バックエンドにはAWS Lambdaが使われ、プログラムによるトリガー用のREST APIも備えています。

レイヤー2:オーケストレーション

Amazon Bedrock AgentCore上のルーティング脳です。すべてのリクエストは、ロールベースアクセスコントロール、アイデンティティ検証、ガードレールをカバーする事前セキュリティチェックを通過した後、コスト最適化されたルーティングティアに入ります。リクエストの約70パーセントはモデルを呼び出さずに決定論的なキーワードマッチングで解決され、20パーセントは軽量モデルで分類され、10パーセントだけが完全なオーケストレーターを必要とします。リクエストを確実に処理できる最も安価な経路が実行されます。

レイヤー3:専門エージェント

カスタマーリレーションシップマネジメント、顧客問題管理、番号ポータビリティ、注文およびSIM操作、インフラストラクチャ監視、ビッグデータ分析、クラウドコスト管理、財務操作を網羅する8つの専門家です。エージェントはAgent2Agent(A2A)プロトコルで通信し、これによりサブタスクを委任し、単一のエージェントでは対応できないシステム横断的なワークフローを完了できます。

レイヤー4:ゲートウェイとバックエンドAPI

Amazon Bedrock AgentCoreの機能であるAgentCore Gatewayが、統一されたModel Context Protocol(MCP)インターフェースを通じてU Mobileのバックエンドをエージェントに公開します。各ゲートウェイの背後には、エージェントの意図を特定のシステムへの呼び出しに変換するAWS Lambda関数とMCPサーバーがあります。

レイヤー5:データとナレッジ

完全マネージドのRAG機能であるAmazon Bedrock Knowledge Basesが、Amazon OpenSearch Serverlessベクトルストアを使用して、統制されたコンテンツに基づいてエージェントの応答を根付けします。コンテンツは共有のエンタープライズナレッジベースと、別個の財務コーパスに及びます。Amazon Bedrock AgentCoreの機能であるAgentCore memoryがターンをまたいで会話のコンテキストを維持し、Amazon DynamoDBが6層のロールベースアクセスコントロールモデルとセッションメタデータを保持します。

レイヤー6:運用システム

U Mobileのオンプレミスおよびクラウドの運用システムには、AWS Transit GatewayとAWS Site-to-Site VPN(公開インターネットに露出しないIPsec暗号化トンネル)を通じてアクセスします。

リクエストがレイヤーをどのように流れるか

単一のリクエストを追跡することで、レイヤー間のやり取りが具体的になります。サポート担当者がMicrosoft TeamsのAiDaHチャネルにポートインのステータスに関する質問を入力する場合を考えてみましょう。

1. インターフェース: TeamsのメッセージはAWS Lambda関数に届き、この関数がリクエストと呼び出し者のフェデレーテッドアイデンティティをオーケストレーターに転送します。
2. 事前チェック: オーケストレーターは、Amazon DynamoDBに保持されている6層のロールベースアクセスコントロールモデルに対して呼び出し者を照合し、Amazon Bedrock AgentCoreの機能であるAgentCore Identityが発行したトークンを検証し、入力プロンプトにAmazon Bedrock Guardrailsを適用します。これらのチェックのいずれかに失敗したリクエストは、ここで停止します。
3. ルーティング: オーケストレーターは、リクエストを処理できる最も安価なティアを選択します。「port-in status」のような認識されたフレーズは決定論的に一致し、モデル呼び出しを完全にスキップします。曖昧な表現は軽量分類器に送られ、新規または複数部分からなる質問は完全なオーケストレーターに送られます。
4. エージェントのインスタンス化: 選択された専門エージェントは、Amazon Bedrock AgentCoreの機能であるAgentCore runtimeのセッションとして実行されます。AgentCore memoryが会話を再構築するため、エージェントはユーザーに再度尋ねることなく、契約者番号や以前のターンでの発見事項を引き継ぎます。
5. ツールの検出と呼び出し: エージェントは、使用が許可されたツールをAgentCore Gatewayに問い合わせます。各ゲートウェイはバックエンドを、型付きの入出力を持つMCPツールとして公開しているため、エージェントは手書きの統合ロジックではなく、名前とスキーマによってツールを選択します。Amazon Cognitoが呼び出しのOAuth認可を仲介します。
6. バックエンド呼び出し: ゲートウェイのLambda関数またはMCPサーバーが、ツール呼び出しを対象システムへのリクエストに変換し、AWS Transit GatewayとSite-to-Site VPNトンネルを通過して、オンプレミスの番号ポータビリティプラットフォームに到達します。機密性の高いフィールドは、応答がモデルに届く前に、返却の途中でマスキングされます。
7. 推論と協業: 回答が複数のドメインにまたがる場合、エージェントはAgent2Agentプロトコルを使って委譲します。例えば、ポートインの問い合わせが請求ブロックによるものだと判明した場合、ビジネスサポートシステムのエージェントに処理が引き継がれ、その結果が1つの説明文に統合されます。
8. 応答と監査: エージェントはその説明をAmazon Bedrock Knowledge Basesに基づいて裏付けを取り、その結果と提案された対策を人間の確認のためにTeamsへ返します。Amazon Bedrock AgentCoreの機能であるAgentCore Observabilityは、プロンプト、ツール呼び出し、トークン数、レイテンシーの完全なトレースをAmazon CloudWatchに書き込み、AWS CloudTrailが対応するAPIアクティビティを記録します。

新しい運用ドメインをオンボーディングする際は、ステップ5でゲートウェイとそのMCPツール定義を追加します。ステップ1〜4、およびステップ7と8は変更されません。この安定したコアこそが、新規ドメインごとの限界コストを低く保つ要因です。

本番環境におけるAmazon Bedrock AgentCoreの機能

以下の表は、各AgentCore機能とAiDaHにおけるその役割を対応付けたものです。

基盤の保護

加入者データ、課金システム、ネットワークインフラにアクセスするエージェentic AIプラットフォームの展開には、アプリケーションレベルのセキュリティ以上のものが求められます。セキュアなクラウド基盤が必要です。U Mobileは2つのアプローチを採用しました。基盤となるAWS Landing Zoneの検証と強化、およびAmazon Bedrock AgentCoreのセキュリティ機能の上に構築することです。

Landing Zoneのセキュリティ – AiDaHを本番環境へスケールする前に、U MobileはAWSと協力して、プラットフォームをホストするLanding Zoneに対するWell-Architected Security Reviewを実施しました。このレビューでは、環境がAWSのセキュリティベストプラクティスに適合しているかを検証しました。まず、AWS Control TowerのガードレールとAWS Organizationsのサービスコントロールポリシーによるインフラストラクチャ保護を確認しました。続いて、中央集権的なIDフェデレーションと、イングレスおよびエグレスに対するネットワークセキュリティコントロールを検証しました。AWS Security Hubでのセキュリティ調査結果の集約と、すべてのアーキテクチャ階層における暗号化標準の確認により、評価が完了しました。その結果は2つありました。すべてのAiDaHコンポーネントが独立して検証された基盤上で動作しているという確信と、継続的な改善のための優先順位付きロードマップです。

アプリケーションレイヤーのセキュリティ – エージェントのすべてのアクションは、認証された特定のユーザーに紐付けて追跡できます。スタッフはMicrosoft Entra IDを通じてフェデレーションし、AgentCore Identityがエージェントの呼び出しを許可する短命トークンを発行します。Amazon CognitoがゲートウェイでOAuth認可を仲介します。したがって、エージェントがアクセスできるのは、その呼び出し元ユーザーが参照を許可されているシステムのみです。6階層のロールベースアクセスコントロールモデルにより、エージェントごと、ツールごと、データソースごとに権限が強制されます。機密性の高い加入者データは、モデルに到達する前にゲートウェイでマスキングされ、Amazon Bedrock Guardrailsがコンテンツポリシーを強制します。

すべてのプロンプト、ツール呼び出し、レスポンスはAgentCore Observabilityを通じてAmazon CloudWatch Logsにストリーミングされ、AWS CloudTrailが基盤となるAPIアクティビティを記録します。この監査証跡が重要です。AiDaHは現在、U MobileのL2サポート標準運用手順書に組み込まれており、運用監査の対象となっています。すべてのコンピューティングはプライベートVPCサブネットで実行され、オンプレミスとの接続は exclusively 暗号化されたVPN経由に限定され、AWS Key Management Service (AWS KMS)が保存時および転送時のデータの暗号化キーを管理します。

文書化された150を超える運用シナリオ

AiDaHが対象とするシナリオは、現在6つのドメインにわたっています。以下の表に各ドメインのカバレッジをまとめます。

進捗の測定：AIコンピテンシーモデル

進捗を追跡し、組織全体で共通の語彙を確立するため、チームは、基本的なデジタルアクセスから自律的な自己修復運用までをカバーする8段階のAIコンピテンシーモデルを採用しました。これは、TM ForumのAutonomous Networks成熟度レベルなどの業界の考え方をU Mobileの運用環境に適応させたものです。次の表に8つのレベルを示します。

AiDaHは最初のパイロットから9か月以内にレベル7に到達しました。専門エージェントが協調し、ツールを使用し、統制されたナレッジを検索し、複数のドメインにわたる運用の意思決定を支援します。人間の関与なしに問題が検知、診断、解決されるレベル8が現在の目標です。

導入の推進：ツールからチームメイトへ

AiDaHの展開は一つの課題でした。人々に信頼させ、使ってもらうことは別の課題でした。

ISDは早い段階で、導入は技術の問題ではなく行動変容の課題であることを認識していました。スタッフは確立されたワークフロー、信頼できるツール、馴染みのあるエスカレーション経路に慣れていました。AiDaHの導入は、深く根付いた習慣を変えるよう求めることを意味しました。また、AIに情報検索、問題診断、次のステップの提案を代行させることを信頼することも意味しました。

チームはディレクティッドプロンプティングを活用しました。自由な探索を期待するのではなく、ISDは一般的なシナリオ向けに構造化されたプロンプトテンプレートを提供しました。これらのテンプレートは「AiDaHに何でも聞いてみて」を「請求確認やポートイン状況の問い合わせ方法はまさにこれだ」と変えました。それにより躊躇が減り、即座に具体的な成果が生まれました。応答が速く、正確で、実行可能であることが証明されると、評判は広がりました。社内調査ではプラットフォームの使いやすさが5点満点中4.6と評価され、現在では日常的にフロントラインチームで使用されています。

最も明確なシグナルは、AiDaHがU MobileのL2サポート標準運用手順（SOP）に正式に組み込まれたときに現れました。任意のツールから監査可能なSOPへの移行こそが、実験から運用への転換を示すものでした。

ISDのアプローチは、完成されたソリューションを購入することでは決してありませんでした。それは旅を自ら所有すること、つまり社内のAI能力を構築し、責任ある実験を奨励し、実践的なAIリテラシーを日常の運用リズムに組み込むことでした。AiDaHそのものに加えて、ISDは専用の社内AIチャネルを維持しており、そこでチームはユースケース、技術、初期の実験を共有しています。目標はAIの専門知識を一つのチームに集中させることではなく、分散させることで、すべての部門が統制されたガードレールの中でAIを自信を持って使えるようにすることです。進展は直線的ではありませんでした。その道のりには挫折と再調整が伴い、その一つひとつがプラットフォームとチームをより強くしました。

結果

Uモバイルの社内測定によると、2026年1月から9月の間に、3つの主要カテゴリーすべてで月間障害チケット件数が減少しました:

• プロビジョニングとネットワーク関連のチケットは84.5パーセント減少しました。
• 一般的な問い合わせは81.6パーセント減少した。
• 請求と課金は48.7パーセント減少しました。

チームがどのように構築したか:Kiroによる仕様駆動開発

U Mobileは、仕様駆動開発を軸に構築されたAWSのエージェント型IDE「Kiro」を活用し、AiDaHの開発を加速させました。Kiroでは、新しい機能はプロンプトではなく仕様として始まります。まず要件、設計、タスクの分解を文書化してレビューし、その合意された成果物に基づいてコード生成が行われます。AiDaHにとって、これが最も重要だったのはエージェントとツールの境界部分でした。新しい業務領域を追加するたびに、新しいゲートウェイ、一連のMCPツール定義、そして誰がそれらを呼び出せるかを決めるロールベースのアクセス制御エントリが必要になります。これらを先に文書化することで、新しい領域ごとに改めて設計をやり直すのではなく、繰り返し可能な作業単位として取り組めるようになりました。

支えるツールチェーンは一般的な構成です。チームはローカル開発に、エージェントフックとMCP統合を備えたKiro IDEを使用し、パイプライン自動化にはKiro CLIを併用しました。ソース管理はGitLab上で行われ、AWS CodePipelineとAWS CodeBuildが継続的インテグレーションを駆動し、コンテナイメージはAmazon Elastic Container Registry(Amazon ECR)に公開され、SonarQubeが継続的なコード品質スキャンを提供しました。仕様がコード生成を主導しました。この規律により、小規模なチームは2つのユースケースの実証実験から、12週間のスプリントサイクルで150以上の文書化されたユースケースへと拡大することができました。

アーキテクチャにおける重要な設計判断

AiDaHが概念実証から本番運用プラットフォームへとスケールする過程では、いくつかの選択がそのあり方を形作りました。特に際立つのが4つの選択で、いずれも次の運用ドメインを追加するコストを下げたり、プラットフォームが成長しても統制可能な状態を保ったりするものでした。

_managed infrastructure としての AgentCore –_ カスタムのエージェントフレームワークを構築するのではなく、チームはAmazon Bedrock AgentCoreに組み込まれたスケーリング、アイデンティティ、メモリ、オブザーバビリティの機能を活用しました。AWSが基盤となるプロビジョニング、スケーリング、パッチ適用を管理するため、インフラエンジニアリングのレイヤー全体が不要になりました。

「あらゆるツールへの接続を実現するMCP –」 Model Context Protocolへの標準化により、AiDaHはエージェントロジックを再構築することなく新しいバックエンドシステムを導入できるようになります。新しい運用ドメインごとに必要なのは新しいゲートウェイであり、新しい統合アーキテクチャではありません。

専門分野間の連携のためのA2A – Agent2Agentプロトコルにより、ドメイン専門家は互いにサブタスクを委任できます。顧客記録、インターフェースログ、課金データにまたがる問い合わせは、関連するエージェント間で自然にルーティングされます。

まずは安全な基盤を – 本番環境へスケールする前にLanding Zoneに対してWell-Architected Security Reviewを実行することで、セキュリティコントロールが後付けではなく、すべての新しいエージェントとゲートウェイに自動的に継承されるようになります。

次に何が起こるのか

U Mobileのロードマップは、広がりと深さの両面での拡大に焦点を当てています。さらなる運用領域やバックエンド統合を取り込みつつ、プラットフォームの能力を単一システムへの照会から複数システムにまたがる相関診断へと進化させます。より長期的な目標、すなわちコンピテンシーモデルのレベル8は、サポート担当者への情報提供から、自律的な問題解決への移行です。

セキュリティガバナンスも並行して成熟している。チームは、NIST SP 800-53、OWASP Top 10 for LLM Applications、CSA AI Trust Framework、MITRE ATLASに実務を整合させている。マレーシアの個人データ保護法およびマレーシア通信マルチメディア委員会の規制への準拠も並行して継続している。

結論

AiDaHは、AIが支援する立場から行動する立場に変わると何が変化するかを示しています。1年足らずの間に、U Mobileは2エージェントの概念実証から、150以上の文書化された運用シナリオに対応する8つの専門エージェントへと移行しました。U Mobileの社内測定によると、主要カテゴリーでトラブルチケットが最大84.5パーセント減少し、U Mobileは現在、このプラットフォームを正式なL2サポート手順に組み込んでいます。

私たちは6つのレイヤーを詳しく見て、Teamsからオンプレミスシステムへのリクエストとその応答を追い、本番環境へのスケールアップに先立って実施されたWell-Architected Security Reviewについて説明しました。技術的な基盤は重要でしたが、地味な作業も同様に重要でした。それは、スケーリング前にLanding Zoneを検証すること、スタッフが開始方法を把握できるよう構造化されたプロンプトを書くこと、そして導入を展開のマイルストーンとしてではなく、行動変容の問題として扱うことを意味しました。同様のシステム断片化に直面しているTeamsは、同じパターンが役立つと気づくかもしれません。まずマネージドなエージェントランタイムから始め、統合境界に標準のツールプロトコルを追加し、スケールアップの後にではなく前にセキュリティレビューを実施してください。

方向性は明確です。安全に拡大し、責任を持って自動化を進め、慎重で統治された歩みを一歩ずつ重ねながら、自律的で自己修復型の運用へと着実に前進していくことです。

詳細については、以下をご覧ください Amazon Bedrock AgentCore そしてその Amazon Bedrock AgentCore 開発者ガイド. spec駆動開発を詳しく知るには、次を参照してください Kiro.

著者について