Telco AN への適用② — サービス展開とベンダー GUI の壁

Telco × Agentic AI ／ 第 10 回
2026 年 6 月 ／ 著：ヒキノ ヒロユキ
🎧 音声で聴きたい方はこちら

本文を読む前に、音声で全体像をつかみたい方はこちらからどうぞ。
再生ボタンを押すだけで聴けます。

はじめに：「戻す」業務から「作る」業務へ

第 9 回では、障害対応 — つまり異常から戻す業務にクローズドループを適用した。
そして前回の番外編（第 9.5 回）では、そのループが運用とともにルールを結晶化させ、自らを育てていく 育つ自律ネットワーク（Self-Cultivating AN） という時間軸の構想を、連載の予告として置いた。

今回は、いったん具体の業務に視点を戻す。
取り上げるのは、第 9 回とは逆方向の業務、平常時に新しい状態を作り出す側である。

具体的には、Telco の現場で長年「自動化の谷」と呼ばれてきた領域である。

• 法人向け 5G ネットワークスライスの払い出し

• IMS（音声・SMS 系）の加入者プロビジョニング

• コア装置の新規 NF（ネットワーク機能）展開・パラメータ配布

• BSS（請求・契約管理）と OSS（運用管理）の連携処理

これらの業務は、技術的には「API を叩けば終わり」のはずなのに、現場では異様に手作業が多い。
なぜか。
そして、第 8 回までの道具立てが、この谷をどう越えるのか。
今回はそこを論じたい。

なぜサービス展開は自動化されないのか

業界外の人にこの話をすると、ほぼ全員が同じ反応をする。

現場の人間からすれば、半笑いの反応である。
理由は、構造的に 3 つある。

理由 1：API があるのは一部、ベンダー 専用GUIが残る

5G コア・IMS・トランスポート系を構成する装置群は、世代もベンダーも混在している。
新しい NF はクラウドネイティブで API も整備されているが、古い装置・ベンダー独自管理系・運用ツールの一部は、GUI でしか操作できないものが残る。

第 5 回で論じた「API 自動化の射程の狭さ」が、サービス展開でもそのまま顔を出す。

理由 2：BSS と OSS の谷間が、人手の塊

BSS（契約・請求・顧客管理）と OSS（ネットワーク運用）の間には、設計思想・データモデル・運用文化のすべてが異なる境界がある。
そこに加えて、料金プランの組合せ・契約条件・SLA・地域制約 — これら全部を「正しく」コア装置のパラメータに落とすには、人間の判断が大量に挟まる。

API があっても、その API に何を渡すかを決める判断が自動化されていない。
ここが、最大の谷である。

理由 3：監査・承認が必須、属人化された Excel

加入者プロビジョニングや料金関連の変更は、監査要件が極めて厳しい。
誰が、いつ、どの権限で、何を変えたか — これを全件追跡できる仕組みがなければ、運用組織は自動化に踏み切れない。

結果として、Excel ベースの承認台帳・チケット・スクリーンショット添付という、属人化された運用が温存される。

第 8 回までの道具立てで、この 3 つはどう解けるか?

それぞれの理由に対して、本連載で揃えてきた道具立てを当てがってみる。

理由 1 への解：CUA on W365A

ベンダー GUI 専用の装置に対しては、CUA（Computer-Using Agent）が W365A の上で人間と同じ手順で GUI を操作する。
これにより、「API がないから自動化できない」という構造的制約が消える。

注意したいのは、これは「無理やり GUI を叩く力技」ではないという点である。
本連載で繰り返し述べてきた通り、GUI 操作は Defacto OS である Windows がエージェントの実行環境として整備されたことで、初めて監査・隔離・統制が効いた状態で実現する。
力技と統制を両立させる設計が、W365A + Entra Agent ID の本質である。

理由 2 への解：判断エージェント＋ Opal

BSS / OSS の谷間は、API ではなく判断ロジックの問題だ。
ここに、第 6 回で論じた「自然言語の意図を理解し、手順を自律生成する」エージェントが入る。

たとえば、

という指示を、Opal が以下のように動的なワークフローに分解する。

1. BSS から契約データを取得

2. ネットワーク設計エージェントが、スライス ID、リソース割当、隣接 NF パラメータを決定

3. 各装置の払い出し手順を、API があれば API で、なければ CUA で実行

4. 検証エージェントが KPI とサービス疎通を確認

5. BSS にステータスを返却し、課金開始トリガーを発行

ここで重要なのは、人間が手順書を書いていないことだ。
人間が定義したのは「目的・制約・SLA」だけである。
これが、第 8 回で述べた「目的を渡す運用」への転換の実装である。

理由 3 への解：Entra Agent ID + Purview

監査・承認・データ境界の問題は、第 7.5 回の Entra Agent ID と、データガバナンス側の Purview が担う。

• どのエージェントが、どの権限で、何を変えたかが完全に追跡可能

• 高 Blast Radius 操作には、Opal の Human Checkpoint が標準で挟まる

• 加入者個人情報・契約情報には、Purview のラベリング・DLP が横断的に効く

ここで、本連載第 4 回で「実行層を担うものは統制を内蔵していなければならない」と論じたことが、製品として完成形に近づく。

業界含意：ベンダーロックインの「API 不在」問題が、構造的に迂回される

サービス展開を真に自動化する上で、業界が長年苦しんできた問題がある。

それは、ベンダーが意図的にせよ非意図的にせよ、API を出し切らないという構造的事実である。

• 古い装置の API は限定的

• 新装置でも、ベンダー独自管理機能は GUI 専用

• API 仕様が頻繁に変わる、互換性が崩れる

• マルチベンダー環境で、API の意味論が揃わない

これは Telco 業界の「API ロックイン構造」と呼ばれてきた問題で、TM Forum の Open API 整備でも、なかなか解けない領域だ。

CUA + W365A の組合せは、この問題を正面から解こうとしない。
代わりに、GUI 自律操作という迂回路で、API 不在の制約を構造的に無効化する。

これは長期的に大きな含意を持つ。
ベンダー側が API を出さない戦略は、エージェント時代には意味を失っていく。
なぜなら、GUI さえあれば、エージェントは API なしで操作できるからだ。

業界の力学そのものが、ここで一段変わる可能性がある。

次回予告：自己修復という、最後の山

ここまでで、障害対応（戻す）とサービス展開（作る）に、クローズドループ設計が適用できることを示した。

次回（第 11 回）は、L4 自律ネットワークの最終条件と言われる、自己修復・自己最適化に踏み込む。

ここでは、第 6 回で名前を出し、番外編（第 9.5 回）で「育つ自律ネットワーク」の心臓部として予告した Learning Loop（特に Procedural Memory：成功した手順の蓄積）が、現場で何を意味するのかを論じる。
そして、この回をもって、Telco AN への 3 つの適用シナリオが完結する。

注意事項（再掲）

• 本記事は個人としての見解であり、所属組織を代表するものではありません。

• 本稿で引用するベンダー独自仕様・業界慣行は、業界で広く知られた一般論として記述しており、特定ベンダー・特定キャリアの実装を指すものではありません。

• TM Forum Open API、3GPP 仕様、各 OSS/BSS 製品の機能は、各公式情報源をご確認ください。

連載インデックス

• 第 1 回：自律運用の壁 — なぜ L3 で止まるのか

• 第 2 回：AN Level 4 への到達条件 — 観測・判断・実行の 3 層構造

• 第 3 回：実行層という空白 — なぜ業界全体が詰まっているのか

• 第 4 回：頭・手・統制 — 実行層に必要な 3 要素

• 第 5 回：3 要素マトリクス — 既存アプローチを再評価する

• 第 6 回：Agentic AI ランタイムという新しい地平

• 第 7 回：Windows 365 for Agent — 業界が待っていた「実行層の基盤」が姿を現した

• 番外編（第 7.5 回）：95% は人のミスで起きる — エージェント ID という新しい主戦場

• 第 8 回：Project Opal — オーケストレーション層という未開拓地

• 第 9 回：Telco AN への適用① — 障害対応クローズドループ

• 番外編（第 9.5 回）：育つ自律ネットワーク（Self-Cultivating AN）— 自律性は、運用するほど安くなる

• 第 10 回：Telco AN への適用② — サービス展開とベンダー GUI の壁（本稿）

• 第 11 回：Telco AN への適用③ — 自己修復・自己最適化と Learning Loop

• 第 12 回：Why Microsoft — 構造的優位の理論

• 第 13 回：補論① — TM Forum AN フレームワークと本連載の接続

• 第 14 回：補論② — 統制の壁、その本当の高さ

• 第 15 回：補論③ — 観測の壁 — Substrate Observability から Outcome Observability へ

• 第 16 回：補論④ — 防御の壁 — 検知と構造防御は別の仕事である

• 第 17 回（最終回）：自律ネットワークの実行層、その先へ — Act 1 総括と、Act 2 への接続

本記事 約 4,500 字 / 読了 13 分

著者：ヒキノ ヒロユキ
通信業界 20 年。3G・4G・5G モバイルコアネットワーク設計 ／ 元 Cisco ネットワークエンジニア ／ 現 Microsoft（個人としての発信） ／ ディエスタデイ合同会社 代表

ご意見・ご質問は記事コメントまたは LinkedIn にて、お気軽にどうぞ。

もし本連載に共感いただけたら、ぜひ note のスキ・フォロー、LinkedIn でのリポストをお願いします。