NTTドコモ、現場主導のデータ管理は定着したのか――自作AIエージェントが直面した意外な現実

NTTドコモは、ネットワーク事業で扱う膨大なデータを、中央の専門チームだけで管理する体制から、データを生み出す各部署が自ら管理・公開する仕組みへと転換した。各部署が社内向けにデータを"出品"することで、必要な人が直接利用できる環境を目指す取り組みだ。

この移行から1年、現場では何が進み、何が課題として残っているのか。「Snowflake Summit 2026」で、NTTドコモ R&Dイノベーション本部サービスイノベーション部ビッグデータ基盤担当兼ネットワーク本部ネットワーク部技術企画部門 Principal Data Engineer 松原侑哉氏、同安田匠吾氏に話を聞いた。

左から、NTTドコモ R&Dイノベーション本部サービスイノベーション部ビッグデータ基盤担当兼ネットワーク本部ネットワーク部技術企画部門 Principal Data Engineer 松原侑哉氏、同安田匠吾氏

なぜ中央管理をやめたのか

日本最大級のモバイルネットワークを運営するNTTドコモは、ネットワーク領域だけで数十ペタバイト規模のデータを保有している。データ量の増加に加え、AI活用のニーズも広がる中、中央の運営チームがすべてのデータ処理と管理を担う従来の体制では、現場からの要求に追いつくことが難しくなっていた。

もう一つの課題が、データの意味や使い方を正確に説明するための知識だった。各データが何を示し、どのような業務で利用できるのかを理解しているのは、そのデータを生み出した部署やシステムの担当者である。中央の運営チームだけでは、こうした現場固有の知識を十分に把握できず、利用者にとって分かりにくいデータや、品質の低いデータが提供されるケースも生じていたという。

こうした課題を受け、ドコモは2025年度から、データを生み出す各部署・各システムが、自らデータ処理と説明情報の整備を担う「セルフサービス型」の運用へと転換した。各部署は、整備したデータを社内マーケットプレイスへ“出品”し、利用者からの問い合わせにも原則として直接対応する。中央の運営チームが一括して管理する体制から、データを最もよく知る現場が品質と価値に責任を持つ体制へ移行した形だ。

この改革に先立ち、ドコモはデータ基盤そのものの刷新も進めていた。それまで複数のデータウェアハウス製品を併用していたが、運用負荷の増大や障害対応の複雑化を受け、2024年にSnowflakeへ全面移行した。

Snowflakeの導入後は、障害対応やリソース調整といった基盤運用の負担が大きく減ったという。松原氏は現在の稼働状況について「予想していた通り」と手応えを語る。基盤の維持管理に追われる場面が減ったことで、中央の運営チームも、データの流通や活用を支える役割へ軸足を移しやすくなった。

セルフサービス化から約1年。現場によるデータの“出品”は、どこまで定着したのか。

データを"出品"してもらう仕組みづくり

セルフサービス化から約1年。松原氏は「自発的にデータを出品する部署が見られるようになってきた」と一定の手応えを語る。一方で、「すべてが満足のいく状態かというと、まだそうとは言えない」とも話す。

最大の壁の一つが、オンプレミス環境で稼働する既存システムだった。オンプレミスのシステムは、クラウド環境と専用線で接続してデータを処理する構成になっており、これが出品のハードルを高くしている。ドコモは現在、オンプレミスからクラウドへのシステム移行を進めており、移行が完了したシステムから順次、Snowflakeのアカウントを払い出して出品を可能にしているという。ただし、こうしたシステムは開発スパンが長く、出品の検討を始めてから1年が経っても、ようやく要件定義に入れる段階というケースも少なくないという。

一方、ビジネスメタデータの入力の敷居については、テーブルの各カラムが何を意味するかといった基本項目を埋めるルールになっており、大きな障害にはなっていないようだ。「データの中身さえ理解していれば、エンジニアでなくても書き込める」と松原氏。この手軽さが浸透を後押ししている一方、運営チームが確認できるのは入力が機械的に完了しているかどうかまでで、記述内容の質までは十分にチェックしきれていないのが実情だという。この点は今後の監視体制構築における課題として残っている。

ドコモは、「出品してください」と呼びかけるだけでは浸透しないと考えた。「このデータとあのデータを組み合わせれば、こういう業務価値が生まれる」と具体的なユースケースを示した上で、出品を働きかけている。実際に、将来のネットワーク需要予測データ、投資判断データ、基地局の負荷状況データなどを組み合わせることで、将来の設備投資計画の精緻化につなげる事例も生まれている。

さらに、データ出品を継続させるため、人事評価や表彰制度にも組み込んでいる。ドコモでは、ネットワーク領域の業務改革を担う部署と連携し、データ出品・活用を組織目標として設定する取り組みを進めている。組織目標として設定されれば、それは下位組織へとカスケードダウンし、達成度が人事評価にも関わってくる。また、社内のデータ活用コミュニティにおける表彰や称号の付与、データ活用の実績を社内の人事ポイント制度に組み込み、昇格条件の一つ（OR条件）として認定する仕組みも進めているという。

このようにドコモは、技術基盤の整備に加え、業務価値の提示や人事制度の見直しを通じて、現場がデータを“出品したくなる”仕組みづくりを進めている。

セルフサービス化がAI活用を後押し

セルフサービス化の定着に伴い、運営負荷の軽減やデータ活用の効率化といった効果が現れ始めている。

まず運営チームの負担について、「出品済みデータへの問い合わせは、基本的に出品した部署へ直接届く」ことから運営チームが仲介する業務は減った、と松原氏。ただし「出品した側もまだ運用に慣れておらず、基盤の使い方に関する問い合わせは依然として多い」と付け加えた。

恩恵を受けているのは運営チームだけではない。これまでデータ利用者は、必要なデータを得るために運営チームを仲介する必要があったが、出品する部署と直接やり取りできるようになれば、データ入手までのリードタイムが短縮される。松原氏は、出品側の運用が自走するようになるほど、この効果はさらに大きくなると見ている。

こうした効果が出てきている中、ドコモはAI活用の一環として、これまで有効活用できていなかった非構造化データの掘り起こしも進めている。例えば基地局のサーバーラックや設備配置に関する設計図面は、構造化されたテーブルではなく画像データとして保管されてきた経緯があり、必要な情報を探し出すのに手間がかかっていた。

そこで、こうした図面をAIで読み取り、Snowflake上にある他のデータと組み合わせて検索・情報発見を行う仕組みの構築を進めている。まだ完全に業務へ組み込まれた段階ではないが、過去の資産をAIで再活用する取り組みの一つとして位置づけられている。

汎用AIが自社開発エージェントを"駆逐"した

AI活用の広がりは、データ分析のあり方そのものにも変化をもたらしている。

ドコモ社内には、以前からSQLでデータ分析を行える人材が一定数存在していた。ただし、過去から受け継いだSQLをそのまま使い続けるケースもあり、分析の裾野はある程度のところで頭打ちになっていたという。こうした状況の中、自然言語でデータ分析ができる生成AIが登場したことで、これまでSQLに触れてこなかった層も分析を試すようになる機運が生まれた。

この機運を受け、ドコモは当初、業務ごとに特化したAIエージェントを独自に複数開発していた。しかし、Snowflakeが提供する汎用ツール「CoCo（旧名称「Cortex Code」）」が極めて高い精度を発揮したことで、自社開発のエージェントの多くはその存在価値を失うことになった。

「われわれが中途半端に作ったエージェントは駆逐されるという状況が生まれました」と松原氏。だが、これはネガティブなことではなく、「CoCoが優れた回答を返せるのは、我々が基盤側のデータに対してビジネスメタデータを丁寧に整備してきたからこそ」と、同氏は分析する。基盤の整備が土台にあったことで、汎用ツールが高い効果を発揮する結果につながったという見方だ。

この変化は、実業務のワークフローにも組み込まれつつある。ネットワークの品質管理を担う部門では、現場で問題が発生した際、従来は支社・支店の担当者が自ら分析し、判断がつかない場合に本社の分析部隊へエスカレーションするという運用を敷いていた。現在は、まずCoCoで分析することが手順として定着し、それでも解決しない場合に本社へエスカレーションする流れに変わった。その際にはCoCoによる分析結果の添付が必須のルールとなっているという。「業務フローに完全に組み込まれたレベルまで定着している」と松原氏、現場の生産性向上にもつながっているとの手応えを語る。

特定ベンダーに依存しないデータ管理へ

一方で、データ基盤そのものも将来を見据えた刷新を進めている。

ドコモが扱うデータは、Snowflake上だけで完結しているわけではない。社内の別システムや他クラウドにもデータが存在することから、それらをコピーせずに連携する仕組みとして、オープンテーブルフォーマット「Apache Iceberg」の採用を進めている。

松原氏によると、狙いは特定ベンダーへの依存を避け、システム間の相互運用性を高めることだ。Apache Icebergを利用することで、データを複製することなく異なるシステム間で結合・分析できるようになり、将来的に利用するデータ基盤が変わっても柔軟に対応しやすくなるという。

現在は、他システムのデータについてApache Iceberg形式での保持を推奨するとともに、Snowflake内の既存テーブルについても優先度の高いものから順次移行を進めている。松原氏は、既存形式との性能差はほとんどなく、業務への影響を抑えながら段階的に切り替えていると説明する。

データもAIエージェントも出品する未来へ

今後の展望として松原氏が描くのは、データだけでなくAIエージェント自体もデータプロダクトとして扱い、マーケットプレイスに出品・サブスクライブできる世界観だ。基地局の設計判断やネットワークパラメータの設定など、特定の業務に特化した複数のAIエージェントを連携させ、あたかも一つの部門であるかのように機能させるエージェンティックワークフローの構築を、一部の領域で試験的に進めているという。

あわせて、ソフトウェア開発そのものをAIに委ねる取り組みも視野に入れる。安田氏によれば、人間が日本語で仕様を記述し、そこからAIがコードを生成、一定の品質のものをデプロイしてデータ処理を行わせる ── そうした開発スタイルへの移行を模索しているという。

セルフサービス化によるデータ流通の高度化、AIエージェントおよびAIが生成するデータへのガバナンス強化。松原氏は、この両輪を今後も推し進めていく考えを示した。