NTTドコモのプラットフォームサービス部は、業務の約30%をAIエージェント（自律的に指示を理解し、判断・作業を実行するAIシステム）に委ねることに成功した。しかし、その道のりは順調だったわけではない。同部を率いる桐生直樹氏（ネットワーククラウド事業本部 プラットフォームサービス部 部長）は、AIエージェント実装の初期段階をこう振り返る。
「実はわれわれは1回、『スーパーマン』型エージェントを実装しようとして失敗しました」
「最強」のはずのエージェントが失敗 一体何が起きていた？
プラットフォームサービス部が当初作ったのは、複数の業務を1つでこなす「万能型」AIエージェントだった。これをネットワーク障害対応の現場に投入した。
「それぞれ別々のAIに専用のタスク（個別の業務処理）やスキル（注1）を持たせる考え方は、今でこそ当たり前かもしれません」と桐生氏は語る。
生成AIブームの初期段階では、1体のAIにさまざまな業務を任せる自律型エージェントが理想像とされる傾向があった。当時は大規模システムにおける設計の標準パターンが確立されておらず、手探りで万能型を目指すアプローチが選ばれるケースが多かった。
「われわれも最初、1つのエージェントがこの仕事もあの仕事もこなすという、まるで『スーパーマン』のような設計で動かしていました。その結果、品質がものすごく低いアウトプットが返ってきたのです」（桐生氏）
障害分析を任せたところ、原因とは関係のない箇所の調査結果が返ってくるといった具合だったという。
マルチエージェント構成への切り替え
「なぜこんなことが起こるんだろう」――。予想外の結果に呆然とするプラットフォームサービス部の転機となったのは、パートナー企業からの助言だった。「1つのAIにすべての業務を担わせる構成そのものが良くない」と指摘を受け、設計の組み替えに踏み切った。
2025年5月、プラットフォームサービス部はエージェントアーキテクチャの検証・評価を実施し、シングル構成とマルチ構成の優位性を比較した。その結果として採用したのが、調査に必要な情報を収集する「情報収集エージェント」と、対象のネットワーク機器にコマンドを実行して結果を考察する「実機調査エージェント」の2体のサブエージェントを用意し、入力された質問を分析してそれらに指示を出す「スーパーバイザーエージェント」を配置する構成だ。
このように、役割ごとに特化した複数のAIエージェントを連携させる仕組みを「マルチエージェント」構成と呼ぶ。1体当たりの担当業務を絞れば、参照するデータと与える指示がその業務の範囲に収まる。業務の切り分け方そのものをシステム設計の対象にするアプローチだ。
この変更によって、アウトプットの品質は大きく改善した。役割を分けたことで、AIエージェントのメンテナンス性も向上したと桐生氏は振り返る。「試行錯誤を繰り返す中で、『AIの設計とはこういうことなのか』と理解しました」（桐生氏）
スーパーバイザーエージェントが配下のサブエージェントに指示を出し、サブエージェントから上がってきた結果を総合的に取りまとめて人間に報告する。人間が関与するのは、AIエージェントが提案したコマンドの実行を承認する段階と、最終報告を受けて判断を下す段階だ。実行前にどのツールをどの条件で使うかがUIに表示され、拒否する場合は理由を入力すると代替案が提示される。生成AIは誤った回答をすることがあり、一度実行したコマンドは取り消せないため、承認を必須にした。
2つ目の壁は「手順」だった
マルチエージェント構成への切り替えで、AIエージェントの精度は改善した。AIエージェントのメンテナンス性も向上した。だが、それだけでは業務を任せられる状態、つまり自立化とはならなかった。「手順を加えずに現場で使ってもらったところ、効果は限定的でした」と桐生氏は振り返る。結局は人間が確認するため、手間がほとんど変わらなかったからだ。
独自の情報を生成AIに与える方法として実装したのが、「手順書参照機能」だ。既存の解説手順書やオペレーターの頭の中にあるノウハウを、生成AIが読みやすい手順書の形式にして格納し、AIエージェントが必要だと判断したときにツール経由で参照する。システムプロンプトに組み込むと特定のネットワークに特化してしまうため、外部参照の形を採った。手順書参照機能を加えたことで、AIエージェントに一定の範囲を任せられる状態になった。
これらの段階的な精度向上施策を経て、2025年10月にプラットフォームサービス部はマルチエージェント構成のNW障害解析支援AIエージェントを業務に適用し始めた。AIエージェントの役割を分けた結果、AIエージェントが担う業務の範囲が広がった。問い合わせ対応に加えて、システム障害時の原因究明や、パッケージ製品のリリースノートを読ませて影響範囲を判定する仕組みも稼働している。
「リリースノートには重要度が書かれていません。人間の担当者だと、毎日届くリリースノート全てはなかなか確認しきれず、積ん放題になってしまいます。アップデートの内容がシステムに影響するかどうかを判断できる情報がなく、対応する前にアップデートが実施されて障害につながったこともありました」と、桐生氏は打ち明ける。
現在は、リリースノートの到着後、自社で提供・運用しているITシステムやサービスに影響があるかどうかをAIエージェントが自動でチェックし、インパクトの有無を自動で判定。アップデートを確実に実行しているという。
成果は数値に表れている。冒頭でも触れた通り、2026年8月時点で障害からの復旧時間の30%短縮という目標に対し、34%の短縮を達成した。2026年7月には、NW障害解析支援AIエージェントの商用適用も開始した。
権限を分けたもう一つの理由は「被害の局所化」
役割ごとにAIエージェントを分割する設計には、アウトプットの精度向上とは別の狙いもある。それがセキュリティ施策だ。
「1つのAIに権限を集中させるのは、セキュリティ面からも問題があります。強い権限を持つエージェントが乗っ取られた場合、社内ネットワークやサーバ、さらに顧客情報まで、あらゆる場所にアクセスされてしまいます。そのため、最初から権限を分散させた方が安全なのです」（桐生氏）
役割ごとに必要な範囲に権限を絞ることで、AIが侵害されても被害はその範囲に留まる。桐生氏はこれを「被害の局所化」と呼ぶ。この重要性は今後さらに増す。桐生氏が理由として挙げるのが、高度な能力を持つ最先端の大規模AIモデル、Anthropicの「Claude Mythos」をはじめとするフロンティアAIの台頭だ。
「フロンティアAIによってサイバー攻撃のスピードや、システムの脆弱（ぜいじゃく）性を見つけ出すスピードが段階的に速くなっています。攻撃を受けて被害に遭うのが当たり前になる。これからは『いかに被害を局所化するか』と『どうやって迅速に復旧するか』が最大の課題です」（桐生氏）
サイバーセキュリティでは全ての接続を疑い、何も信頼しないことを前提とする「ゼロトラスト」が主流になりつつあるが、これはAIエージェントの設計にも当てはまる考え方だ。どの業務をどのAIエージェントに任せ、それぞれにどこまでのデータアクセスを許容するか。AIが乗っ取られる前提で権限を最小限に絞る「最小特権の原則」は設計段階で組み込むべきことの一つだ。
AI活用の度合いは「利用時間」では測れない
実装段階より前に決めておくべきなのは、権限の設計だけではない。従業員がAIをどれだけ活用できているかを「何」で測るのか。これも、走り出してからでは決めにくい項目の一つだ。
NTTドコモは2026年3月1日、従業員のAI活用スキルを認定する「AI実践レベル判定」を開始した（注2）。認定レベルは初級から順に「WhiteBelt」「YellowBelt」「GreenBelt」「BlackBelt」の4段階に分かれる。対象は全従業員で、AIエージェントが客観的に評価するという。2027年度末までに、上位2段階に当たるGreenBelt以上の認定者を400人輩出することを目標に掲げている。
独自の認定の仕組みを設けた理由について、NTTドコモの増田恭子氏（総務人事部 キャリアデザイン部長）はこう説明する。
「誰がどのくらいAIを使っているかは、利用時間で確認できます。ただ、AIを長時間使っている人が『AIをよく活用している』と言えるかというと疑問です」。経営に貢献するAI活用の基盤を明確化することが、「AI実践レベル判定」の目的だ。
では、NTTドコモは具体的にどのようなAI利用を評価しているのか。
「業務時間の短縮は、AI活用による成果の一例です。しかしそれだけではなく、AIを活用することで業務をより高度化する、あるいは今までにない活用によって新たな価値を生み出す取り組みを可視化し、全社へ広げていくことがこの仕組みの目的です」（増田氏）
AI実践レベル判定によって、NTTドコモはさらにAI活用を推進する予定だ。増田氏は現状について、「社内で温度差はある」と認める。プラットフォームサービス部のようにAIを積極的に活用している部署の取り組みをさらに進め、まだ浸透していない部署の底上げを図る。その両方の効果を増田氏はこの施策に期待している。
AIを「点」で使うのではなく、全体の設計を考えるべき
ここまで、AIエージェントをどう実装すべきかについて、NTTドコモの取り組みから見てきた。桐生氏が特に強調するのが、全体設計の重要性だ。企業のビジネスとシステムの構造を全体として設計するエンタープライズアーキテクチャの推進に携わってきた桐生氏は、AIエージェントの実装もその一部として捉えている。
エンタープライズアーキテクチャとしてのAIエージェント実装は、どの業務でどのような成果を出すかを決める「ビジネス設計」、社内文書をAIが理解できる状態に整える「データ設計」、サブエージェントを統括するスーパーバイザーエージェントに任せる範囲を設定する「アプリケーション設計」から構成される。
桐生氏は、AIを本当の意味で活用するために必要なのは、RAGやMCP、LLMのそれぞれをどうすべきかという個別の話ではないと言う。
「ビジネスゴールを見据えて、どの社内データに対してどのような手順でAIに処理させるか。加えて、成果を中心に捉え、結果をどう出すかまで見据えて取り組む。『点』でAIを使うのではなく、エンタープライズアーキテクチャ全体でAI活用を推進すべきです」
（注1）AIに特定の業務を処理させるために設定する、ルールや外部ツールとの連携機能
（注2）「AI活用の実践＋スキル」を可視化する人材認定を3月から開始
