NTTドコモが AI エージェントで 5G コアの設計・構築を自動化｜AWS ハイブリッド環境で構築期間を約 80% 短縮【AI活用事例】

要約

NTTドコモが、AWS クラウドサービスと自社の仮想化基盤を併用するハイブリッド環境上で、5G コアネットワーク（5GC）の商用サービスを開始しました。AWS ジャパンの公式発表（2026-03-02）によれば、アジア太平洋地域の通信事業者としては初の事例です。

技術的な中核は、AI エージェント（Agentic AI）による 5GC の設計・構築自動化です。

• Amazon Bedrock AgentCore・Strands Agents・MCP（Model Context Protocol）・GitOps の統合により、5GC デプロイ時の設定作成と適用を自動化
• AWS 上での 5GC 設計・構築の期間を 従来比で約 80% 短縮
• 提供対象は 9,100 万契約者（ただしドコモ自社の仮想化基盤とのハイブリッド構成）

さらに別系統の取り組みとして、ネットワーク保守業務向け AI エージェントシステムが全国 100 万台超のノードのデータを AWS 上に集約し、熟練エンジニアのナレッジを持つ AI エージェントが障害の検知と復旧手段の自動提案を行う仕組みが、全国規模で商用稼働しています（BUSINESS NETWORK 取材記事、2026-06-23）。

本記事は BUSINESS NETWORK の取材記事（2026-06-23、坪田弘樹・編集部）と AWS ジャパン公式プレスリリース（2026-03-02）を一次ソースに、**「AI エージェントによるインフラ構築自動化」**の構造と、通信業界以外の一般企業の IT 基盤運用への示唆を、Links-Create の視点で整理したものです。

何が発表されたか（公式情報ベース）

公式発表および取材記事から確認できる事実を整理します。発表主体が AWS 側（AWS ジャパン）である点は、本事例を読むうえで重要な前提です。

取り組み 1: 5GC の設計・構築自動化

項目	内容
構成	AWS クラウド + ドコモ自社の仮想化基盤のハイブリッド構成
商用開始	2026 年 2 月（BUSINESS NETWORK）
位置づけ	アジア太平洋地域の通信事業者で初（AWS ジャパン公式）
対象規模	9,100 万契約者（AWS ジャパン公式）
AI 技術要素	Amazon Bedrock AgentCore、Strands Agents、MCP、GitOps
自動化対象	5GC デプロイ時の設定作成と適用
効果	構築期間を約 80% 短縮（AWS ジャパン公式）
その他技術要素	AWS Graviton プロセッサ、Amazon Neptune

ドコモ側コメント:「本取り組みは、ドコモが目指すネットワークの高度化を大きく前進させるもの」 — 出典: AWS ジャパン公式プレスリリース（2026-03-02）

取り組み 2: ネットワーク保守業務向け AI エージェントシステム

こちらは 5GC の構築自動化とは別系統の取り組みです（BUSINESS NETWORK 取材記事、2026-06-23）。

• 全国 100 万台を超えるノードからのデータを AWS 上に集約
• 熟練エンジニアのナレッジを持つ AI エージェントが分析・可視化
• 故障・障害の検知と復旧手段の自動提案
• 2026 年 3 月の MWC26 Barcelona で披露、全国規模で商用稼働中

同記事では海外の先行事例として BT・O2 テレフォニカ・C spire も紹介されており、AI エージェントの通信事業者への適用は国際的な潮流として位置づけられています。

公式発表で開示されていない情報（推論で書かない）

• 従来の 5GC 設計・構築に要していた期間の絶対値
• AWS 上で処理されるトラフィックの割合、機能配置の内訳
• AI エージェントの人手レビュー体制（どの工程で人間が承認しているか）
• 保守 AI エージェントの障害検知精度・誤検知率
• コスト面の効果

これらは公式情報がないため、本記事でも記載しません。

技術構造の整理（Links-Create による解説）

ここからは、公開情報から読み取れる構造を Links-Create の視点で解説します。以下は独自分析であり、NTTドコモおよび AWS の公式見解ではありません。

1. なぜ「5GC の設計・構築」が AI エージェント向きなのか

通信事業者のコアネットワーク構築は、AI エージェントの適性が非常に高い作業領域です。理由は 3 つあります。

1. 参照すべき知識が膨大で構造化されている — 3GPP 仕様書、ベンダー機器のマニュアル、社内設計標準、既存構成のパラメータ体系。人間のエンジニアが「どこに何が書いてあるか」を探す時間が支配的になりがちな領域です。
2. 出力が明確な形式を持つ — 最終成果物は設定ファイル群であり、自由記述の文章ではありません。フォーマットが定まっているものは、生成結果の検証がしやすくなります。
3. 作業が反復的だが完全定型ではない — エリアごと・機器世代ごとに条件が変わるため、単純なスクリプトでは吸収しきれず、かといって毎回ゼロから設計するほど個別性も高くない。この「準定型」領域が、ルールベース自動化では届かず AI エージェントが効く帯です。

2. 「AI エージェント × GitOps」という組合せの意味

本事例で最も注目すべきは、AI エージェントに GitOps が組み合わされている点です。

GitOps は、インフラ構成を Git リポジトリ上の宣言的なファイルとして管理し、そのファイルの状態に環境を継続的に同期させる手法です。AI エージェントと組み合わせると、次のような流れが成立します。

段階	担当	成果物
仕様・マニュアル参照	AI エージェント（MCP 経由でデータソースに接続）	設計判断の根拠
設定ファイル生成	AI エージェント	Git 上の構成ファイル（差分としてレビュー可能）
レビュー・承認	人間のエンジニア	Pull Request の承認
環境への適用	GitOps パイプライン	実環境の状態
差分検知・ロールバック	GitOps パイプライン	宣言状態への自動収束

この構造の要点は、AI の出力が「実行される操作」ではなく「レビュー可能な構成ファイル」として表現されることです。AI が API を直接叩いて本番機器を操作する設計では、誤った判断がそのまま障害になります。一方、出力を Git の差分に落とせば、レビュー・履歴追跡・ロールバックという既存の統制手段がそのまま使えます。

ミッションクリティカルな基盤に AI エージェントを導入する際、**「AI の出力をどの中間表現で受け止めるか」**が安全性を決めます。本事例は、その中間表現として宣言的構成ファイルを選んだ実装例として読めます。

3. MCP が果たしている役割

MCP（Model Context Protocol） は、AI モデルが外部のツールやデータソースに接続するための標準プロトコルです。5GC 構築の文脈では、AI エージェントが仕様書・既存構成・機器情報といった社内データソースに、統一されたインターフェースで到達するための配管にあたります。

ここが実務上の分岐点です。AI エージェントの精度は、モデルの賢さよりも**「参照できる社内知識がどれだけ整備され、機械可読な形で接続されているか」**に大きく左右されます。同じモデルを使っても、仕様書が PDF のまま散在している組織と、構造化されて MCP 経由で引ける組織では、出力品質が根本的に変わります。

4. 「約 80% 短縮」をどう読むか

この数値を社内で引用する際は、次の 3 点を必ず併記すべきです。

• 対象工程が限定されている — 「AWS 上での 5GC の設計・構築」工程であり、ネットワーク全体の構築・試験・移行を含む全工程ではありません。
• 従来の絶対値が公開されていない — 短縮率のみの開示で、元が何か月だったかは公式発表に記載がありません。率だけでは投資対効果の試算はできません。
• 前提資産がある — ドコモが蓄積してきた設計標準・パラメータ体系があり、それを AI が参照できる状態に整備した結果としての数値です。知識整備のコストは短縮率には現れません。

また、発表主体が AWS 側である点も踏まえ、成果の範囲は公式表現の限度で扱うのが安全です。

5. 既存の通信 AI 事例との違い

Links-Create では通信業界の AI 活用事例を複数扱っていますが、技術系統も適用領域も異なります。

事例	AI 技術系統	適用対象	目的
本事例（NTTドコモ 5GC）	エージェント型 AI	コア網の設計・構築	構築リードタイム短縮
KDDI 基地局最適化	強化学習	無線アクセス網のパラメータ調整	通信品質の自律最適化
NTTドコモビジネス AI SOC	エージェント型 AI + SOAR	セキュリティ運用	アラート分析・対処の自動化

同じ「通信 × AI」でも、強化学習による継続的な最適化（KDDI）と、エージェント型 AI による構築作業の代替（本事例）は、設計思想も評価指標もまったく異なります。前者は「稼働中システムのパラメータを環境に合わせて動かし続ける」問題であり、後者は「知識参照と成果物生成を代行する」問題です。AI 導入の検討では、この技術系統の見極めが最初の分岐になります。

一般企業の IT 基盤運用への示唆（Links-Create の視点）

通信事業者以外の企業が本事例から取り出せる示唆を 3 つ整理します。

示唆 1: 「知識の整備」が先、「AI の導入」が後

本事例の 80% 短縮は、AI エージェントを買ってきたから実現したものではありません。参照される側の知識（仕様・設計標準・パラメータ体系）が構造化されていることが前提にあります。

自社で同様の取り組みを検討する場合、着手順序は次のようになります。

1. 構築・設定作業の手順とパラメータをドキュメントとして棚卸しする
2. 暗黙知（「この機器のこの設定は経験的にこうする」）を明文化する
3. それらを AI が参照できる形（構造化データ、MCP 経由で引けるソース）に整備する
4. その後で AI エージェントに生成を任せる

順序を逆にすると、「AI が的外れな設定を出す」という結果になり、原因が AI ではなく知識の欠落にあることを見誤ります。

示唆 2: AI の出力は「実行」ではなく「レビュー可能な中間表現」で受ける

前述の GitOps の構造がそのまま応用できます。社内の IT 基盤運用に AI エージェントを入れる際は、

• AI に直接 API を叩かせ、本番環境を変更させる設計
• AI に構成ファイル・変更提案を生成させ、既存のレビュー・承認フローに乗せる設計

の 2 択のうち、後者から始めるのが実務的です。前者は自動化率は高くなりますが、AI の判断ミスが直接インシデントになり、事後の原因追跡も困難になります。後者は人間のレビュー工数が残りますが、「何を根拠にその設定にしたか」が差分として残るという統制上の価値があります。

示唆 3: 「準定型作業」を探して適用する

AI エージェントが最も効くのは、完全定型でも完全非定型でもない領域です。

• 完全定型（毎回同じ手順・同じ値） → スクリプト・IaC で十分。AI は過剰
• 準定型（手順は共通だが条件で分岐、大量の参照知識が必要） → AI エージェントの適性が最も高い
• 完全非定型（前例のない設計判断、事業上のトレードオフ） → 人間の判断領域

自社の業務を棚卸しする際、この 3 分類で仕分けると投資先の優先順位がつけやすくなります。5GC の設計・構築はまさに中央の帯にあり、だからこそ大きな短縮率が出たと読めます。

法人 AI 研修への示唆（Links-Create の視点）

1. エージェント型 AI と生成 AI の違いを共通言語にする — 本事例の AI は「文章を生成する」のではなく「目標に向けて外部ツールを使い、作業を連鎖させる」エージェント型です。この違いを技術者だけでなく決裁者も理解していないと、投資判断の議論が噛み合いません。基礎は AI エージェント入門ガイド で整理しています。
2. 「AI に任せる前に知識を整える」という順序を組織の常識にする — AI 活用が期待外れに終わる典型的な原因は、モデルの性能ではなく参照知識の未整備です。研修では「AI 導入プロジェクト = 社内知識の構造化プロジェクト」という枠組みで捉え直すことを推奨しています。
3. AI の出力を検証する形式を業務ごとに設計する — GitOps における構成ファイルのように、「AI の出力を人間が検証できる形式」は業務ごとに異なります。文書作成なら差分、分析なら根拠データ、設定作業なら宣言的構成。この設計を業務責任者が担えることが、実務適用の分かれ目になります。

関連リソース

• 生成 AI（Claude Code）を実務で使う実装演習 — 「生成 AI で何ができるか・できないか」を体験する無料コース。エージェント型 AI を理解する前提として最適
• AI エージェント入門ガイド — エージェント型 AI の構造（目標・行動・観測・ガードレール）を実務視点で整理
• MCP 入門ガイド — 本事例で使われている Model Context Protocol の基礎と、社内データソース接続の考え方
• KDDI が強化学習で基地局パラメーターを自律最適化（AI活用事例） — 同じ通信業界でも技術系統が異なる事例。強化学習とエージェント型 AI の違いの理解に
• NTTドコモビジネスが「AI SOC」でセキュリティ運用を自動化（AI活用事例） — エージェント型 AI を運用業務に適用した事例。本事例（構築工程）との対比で読むと適用領域の広がりが見える

出典・引用ポリシー

本記事の事実情報は、以下の 2 つを一次ソースとしています。

• BUSINESS NETWORK「AIエージェントが通信事業者を変える　ドコモの『5G on AWS』でも活躍」（2026-06-23、坪田弘樹・編集部）
• AWS ジャパン公式プレスリリース「NTTドコモ、AWS 上で 5G コアネットワークの商用運用を開始」（2026-03-02）

技術構造の解説・一般企業への示唆・研修への示唆は Links-Create の独自分析であり、NTTドコモおよび AWS の公式見解ではありません。

定量値は公式発表の表現（「約 80% 短縮」等の限定語を含む）をそのまま維持し、成果保証としては記述していません。「約 80% 短縮」は AWS 上での 5GC 設計・構築工程を対象とした実績値であり、従来の所要期間の絶対値は公式発表では開示されていません。また、5GC はドコモ自社の仮想化基盤と AWS を併用するハイブリッド構成であり、「コアネットワーク全体がクラウド上で動作している」という意味ではない点に注意が必要です。発表主体が AWS 側である点も踏まえ、社内提案で引用する際は前提条件を必ず併記してください。

公式情報の更新があれば、本記事も追従して更新します。