AI研修 LMS

NTTドコモがネットワーク保守向け AI エージェントを商用化｜100 万台以上の装置データで「複雑な故障」の被疑箇所を特定し対処案を提示、対応時間 50% 以上削減（同社発表）【AI活用事例】

公開: 2026-11-06

NTTドコモ通信ネットワーク運用保守（複雑な故障の分析と対処案の提示）大手モバイルネットワーク保守業務向け AI エージェントシステム（ドコモ開発・生成 AI 活用）複数の AI エージェントの組み合わせ（マルチエージェント構成）Amazon Bedrock AgentCore

この事例でわかること

  • NTTドコモが、生成 AI を活用したモバイルネットワーク保守業務向け AI エージェントシステムを開発し、2026 年 2 月 4 日から商用利用を開始（公式発表 2026-02-25）
  • 対象は、手順が事前に決まっている故障ではなく、対処方法が明確でない「複雑な故障」。これまでは複数の保守担当者が大量のデータを集めて分析していた
  • 基地局からコアネットワークまでの 100 万台以上の装置のトラフィック情報・警報情報を、複数の AI エージェントで横断的にリアルタイム分析し、異常検知・被疑箇所の特定・対処案の提示までを行う。対処案は保守担当者に提示される
  • 効果は「従来と比べて対応時間を 50% 以上削減」と同社が発表。比較条件・対象件数・測定方法は非公表で、保守要員やコストの削減率ではない
  • 学べる型は、定型手順の自動化と AI エージェントの担当範囲を分け、AI には「調べて候補を出す」まで、実行の判断は人に残すこと（演習は Links-Create の研修用提案）

主な指標（一次ソース確認済み）

障害発生時の対応時間
従来比 50% 以上削減（同社発表）

NTTドコモ公式報道発表（2026-02-25）の「従来と比べて対応時間を50%以上削減することでモバイルネットワーク障害発生時のサービス影響時間を短縮し」に基づく。比較対象の「従来」の具体的な手順・期間、対象とした故障の件数や種類、測定方法、実測値か見込みかの区別は非公表。対象は「障害対応の時間」であり、障害件数・保守要員数・コストの削減率ではない。同社自身による発表値で、第三者検証ではない。

分析対象のネットワーク装置
100 万台以上

公式発表の「基地局からコアネットワークに至るまでの100万台以上のネットワーク装置から収集されるトラフィック情報や警報情報などのデータ」に基づく。データの量（件数・容量）や収集間隔は非公表。台数は分析の対象範囲であり、AI が故障を特定できた件数ではない。

商用利用の開始日
2026 年 2 月 4 日

公式発表に「2026年2月4日（水曜）からドコモのモバイルネットワークサービスにおいて商用利用を開始」と記載。発表日は 2026 年 2 月 25 日。商用開始後の対応件数・的中率・誤検知率などの運用実績は非公表。

一次ソース: https://www.docomo.ne.jp/info/news_release/2026/02/25_01.html （公開: 2026-02-25）

要約

NTTドコモが、生成 AI を活用したモバイルネットワーク保守業務向け AI エージェントシステムを開発し、2026 年 2 月 4 日から商用利用を開始しました（公式発表 2026-02-25）。

狙いは、手順が決まっていない**「複雑な故障」への対応時間を短くすること**です。公式発表から読み取れるポイントは次の 3 つです。

  • 役割の分担: 対処方法が明確な故障は、従来どおり事前に定義した手順の自動化で対応。対処方法が明確でない故障を AI エージェントが分析する
  • AI の担当範囲: 100 万台以上の装置のデータを複数の AI エージェントで分析し、異常検知・被疑箇所の特定・対処案の提示まで。対処案は保守担当者に提示される
  • 成果は自社発表の数値: 従来と比べて対応時間を 50% 以上削減すると同社が発表。比較条件は非公表

本記事は NTTドコモの公式報道発表（2026-02-25）を一次ソースに、事実の整理と Links-Create の分析・研修用の演習を分けて解説します。演習は研修用の提案であり、ドコモが実施した事実ではありません。

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

発表主体は NTTドコモ自身であり、効果の数値も同社による発表値です。この点を前提に読んでください。

システムの概要

項目内容（公式発表の要約）
名称モバイルネットワーク保守業務向け AI エージェント（生成 AI を活用、ドコモが開発）
商用開始2026 年 2 月 4 日、ドコモのモバイルネットワークサービスで商用利用を開始
分析対象基地局からコアネットワークまでの 100 万台以上のネットワーク装置から集まるトラフィック情報・警報情報など
分析方法複数の AI エージェントを組み合わせ、横断的かつリアルタイムに分析
AI が行うこと異常の検知、被疑箇所の特定、対処案の保守担当者への提示
基盤AWS のマネージドサービス（Amazon Bedrock AgentCore、AI に最適化されたデータベースサービス）
効果（発表）従来と比べて対応時間を 50% 以上削減し、障害発生時のサービス影響時間を短縮

背景: なぜ「複雑な故障」なのか

公式発表は、現在のモバイルネットワークが 4G と 5G をまたいでサービスを提供し、複数のドメイン・複数のベンダーの機器が混在するため、運用が複雑になっていると説明しています。

そのうえで、故障を 2 種類に分けています。

  1. 対処方法が明確な故障: 事前に定義した手順を自動化して、すでに迅速に対応してきた
  2. 対処方法が明確でない複雑な故障: 複数の保守担当者が連携して大量のデータを集め・分析し、要因を特定する必要があり、人手による対応がサービス影響時間の長期化につながっていた

今回の AI エージェントは、2 つ目の課題に向けたものです。

担当部長のコメント

公式発表には、ドコモ ネットワーク本部 サービスマネジメント部長の牧山 隆宏氏のコメントが掲載されています。

「本取り組みは、ドコモがめざすネットワーク自律運用の実現に向けた大きな一歩となるものです。」 — 出典: NTTドコモ公式報道発表（2026-02-25）

同じコメントの中で、保全業務への AI エージェントの活用を通じて故障対処の自動化を進め、サービス影響時間をさらに短縮することをめざすと述べられています。現時点の役割は対処案の提示までであり、自動での対処は今後の目標として語られている点に注意してください。

媒体の取材で補足されていること（公式発表ではない）

BUSINESS NETWORK の連載記事（ドコモが挑むAgenticOps　5G安定稼働へAIと人が協働、2026-08-31）は、AI エージェントが状況を分析して行動する運用モデルを「AgenticOps」と呼び、本システムを取り上げています。同記事によれば、ドコモの担当者は、運用監視・保守業務を、役割を分担する複数の AI エージェントと人間のオペレーターの協働で遂行すると説明しています。これは取材記事の内容であり、公式発表の記載ではありません。

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

  • 「50% 以上」の比較対象（従来の手順・期間）、対象とした故障の件数・種類、測定方法、実測か見込みか
  • 商用開始後の対応件数、被疑箇所の特定の的中率、誤検知率
  • AI エージェントの数と、それぞれの役割の内訳
  • 使っている生成 AI のモデル名
  • 保守担当者が対処案を採用・却下する基準や承認の手順
  • 保守要員数・運用コストへの影響

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

設計の読み解き（Links-Create による解説）

ここからは、公開情報から読み取れる設計上のポイントを Links-Create の視点で解説します。以下は独自分析であり、NTTドコモや AWS の公式見解ではありません。

1. 「手順の自動化」と「AI エージェント」を置き換えではなく並べている

公式発表は、対処方法が明確な故障には従来の手順の自動化を使い続け、AI エージェントは手順がない故障に向けたと説明しています。AI エージェントを入れるときに、既存の自動化を全部置き換えるのではなく、自動化できなかった残りの部分に当てていると読めます。

一般の企業でも、「マニュアル化できている仕事」と「毎回人が調べている仕事」を分けると、AI エージェントの出番は後者に絞られます。前者を AI に任せると、決まった結果が出るはずの処理に、毎回ぶれる可能性のある仕組みを持ち込むことになります。

2. AI の担当は「調べて、候補を出す」まで

公式発表で AI エージェントが行うとされているのは、次の 3 段階です。

段階公式の記載誰が最終判断するか（解釈）
1. 見つけるネットワークに起こっている異常を検知AI
2. 絞り込む被疑箇所を特定AI（結果は人が確認できる形で提示されると読める）
3. 案を出す対処案を保守担当者に提示人（採用するかを担当者が判断）

「対処案を保守担当者に提示」という書き方から、実行の判断は人に残っていると Links-Create は解釈しています。止まると影響の大きい社会インフラでは、AI の誤りがそのまま実行されないように、「提案まで AI、実行は人」の線を引くのは自然な設計です。

3. 効いているのは「集める・突き合わせる」作業の短縮

従来は「複数の保守担当者が連携し、大量のデータを収集・分析し」て要因を特定していたと公式発表は述べています。複雑な故障では、原因を考える前のデータ集めと突き合わせに時間がかかります。複数の AI エージェントで装置横断のデータを同時に見ることは、この前段の時間を短くすることに向いています。

ただし、対応時間の内訳（どの工程が何分短くなったか）は公表されていないため、「どこが効いたか」は推測の域を出ません。

4. 既存の事例との違い

事例AI が担う範囲本事例との違い
NTTドコモの 5G コア構築自動化5G コアの設定ファイル作成と適用（構築）構築の自動化が主題。本事例は障害時の分析と対処案の提示
KDDI の強化学習による基地局最適化基地局パラメーターの自律最適化平常時の品質最適化。本事例は故障が起きた後の対応
NTTドコモビジネスの AI SOCセキュリティアラートの分析と対処の自動化対象がセキュリティ運用。本事例はネットワーク故障で、対処案の採否を保守担当者が判断する

自社に置き換える演習（Links-Create の研修用の提案）

以下の演習と表の例は、Links-Create が研修用に提案するものです。ドコモが実施した手順や事実ではありません。 表の「例」は架空の例なので、自社の業務に置き換えて記入してください。

演習 1: トラブル対応を「手順あり」と「手順なし」に分ける

直近 3 か月のトラブル対応を 10 件ほど書き出し、次の表に仕分けます。

トラブルの例（研修用の例）手順書があるか向いている方法
パスワード再発行の依頼ある定型の自動化・セルフサービス
特定の時間帯だけ社内システムが遅いない（毎回調べる）AI に関連ログを集めさせ、原因候補を出させる
顧客から「請求額が合わない」との問い合わせ一部ある手順の部分は自動化、例外は AI が資料を突き合わせて人に提示

「手順なし」に入ったものが、AI エージェントを試す候補です。

演習 2: AI に任せる範囲を 3 段階で決める

「見つける／絞り込む／案を出す／実行する」のうち、どこまでを AI に任せるかを業務ごとに決めます。

段階判断の目安
見つける・絞り込む間違えても人が確認すれば害が出ない範囲なら AI に任せやすい
案を出す根拠（どのデータを見たか）を必ず一緒に出させる
実行する取り消せない・顧客に影響する操作は人の承認を挟む

演習 3: 効果を「時間の内訳」で測る

「対応時間が半分になった」だけでは、どこが効いたかが分かりません。導入前後で次の 3 つを分けて記録します。

  • データを集めるまでの時間
  • 原因の候補が出るまでの時間
  • 人が判断して対処を終えるまでの時間

あわせて、AI の候補が外れた件数も記録すると、「速くなったが外れが多い」状態を見逃さずに済みます。

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

  1. AI エージェントは「残った仕事」に当てる — 既存の自動化を棚卸ししてから、手順化できなかった仕事を AI の候補にする
  2. 提案と実行を分ける — 研修では、AI の出力を「根拠つきの提案」として受け取り、人が採否を決める練習をする
  3. 数値は内訳で語る — 「〇% 削減」を社内で示すときは、比較対象と工程の内訳をそろえる

関連リソース

出典・引用ポリシー

本記事の事実情報は、次の公式発表を一次ソースとしています。

「AgenticOps」の呼称と担当者取材の内容は、次の記事を出典として区別して記載しています。

設計の読み解き・演習・研修への示唆は Links-Create の独自分析・研修用の提案であり、NTTドコモおよび AWS の公式見解ではなく、同社が実施した事実でもありません。定量値は公式発表の表現（従来比・同社発表・比較条件は非公表）を維持し、成果保証としては記述していません。公式情報の更新があれば、本記事も追従して更新します。

関連する AI 研修コース・ガイド

この事例で見た AI 活用を、自社のエンジニア・実務者が手を動かして再現できる 実装演習とガイド記事です。Anthropic Academy の概念入門の次に位置する、 実装力定着のためのカリキュラムをご覧ください。