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

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

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

はじめに：「外し」の補論を入れる理由

第 12 回までで、本連載の理論的中核は出揃った。

ここから先、第 13 回と第 14 回は、本論から少し外して補論を入れる。

補論を 2 本書く理由は、本連載がこれまで意図的に深入りしてこなかった、しかし業界読者から必ず問われる、2 つのテーマがあるからだ。

• 「で、TM Forum の AN フレームワークとの関係はどうなってるの？」（第 13 回・本稿）

• 「技術はわかった、でも統制が解けないと社内決裁が降りないんだけど」（第 14 回）

どちらも、現場感覚として極めて鋭い問いである。
ここに正面から答えておかないと、第 17 回（最終回）でいくら総括しても、業界の意思決定者には届かない。
今回は前者、TM Forum との関係を整理する。

TM Forum AN フレームワークの整理（業界一般としての位置付け）

まず、業界共通言語として TM Forum の AN フレームワークを、本連載の文脈で要約しておく。

このフレーム自体は、業界の共通言語として極めて重要である。
キャリア・ベンダー・コンサル・規制当局を含めて、AN を語る時の共有座標系として機能している。

ただし、ここで一つ、本連載の立場を明確にしておきたい。
TM Forum AN フレームワークは、組織成熟度のモデルである。
これは、第 11 回までで論じてきた技術アーキテクチャとは、視座が違う。

「組織成熟度モデル」と「技術アーキテクチャ」は別のもの

ここを混同すると、議論全体がねじれる。
分けて整理しよう。

これは、CMMI と TOGAF が両方とも必要だが別のもの、という関係に近い。
組織成熟度モデルだけでは、何を作るべきかは決まらない。
技術アーキテクチャだけでは、組織としてどこまで進んだかは測れない。

両方を持ってはじめて、業界の議論は地に足が着く。

接続点：3 層構造 × AN レベル

本連載の柱である「観測・判断・実行」の 3 層構造と、TM Forum AN レベルを重ねると、自然な対応関係が見えてくる。

この表で重要なのは、L3 と L4 の差は、実行の自動化にかかっているという事実である。
これは、本連載の第 1 〜 3 回で繰り返した「実行層という空白」の議論と、TM Forum 側から見た到達条件が完全に一致することを意味する。

裏返すと、本連載が論じてきた W365 for Agent / Entra Agent ID / CUA / Opal の道具立ては、TM Forum AN L4 の実行レイヤー成立条件を、初めて技術的に満たすセットになっている、と整理できる。

TM Forum の用語を借りる時の注意点

業界発信で TM Forum の用語を使う時、注意したい点が 2 つある。

注意 1：「L4」は到達点ではなく、目標である

業界文書では、しばしば「2027 年までに L4 到達」「2030 年までに L5 到達」といったロードマップが語られる。
しかし、L4 / L5 は組織成熟度の目標であって、技術コンポーネントの到達点ではない。

技術コンポーネントとしては、第 12 回で論じた 5 条件の揃いが成立した時点で、L4 の技術的前提は満たされる。
そこから先、組織としてどう運用に乗せるか、どう人材を再配置するか、どう監査・規制と整合させるか — これは TM Forum の議論の領域である。

注意 2：L5 は規制・倫理の議論を含む

L5 は技術論だけでは語れない。
全領域・全条件での自律は、規制対話・社会受容・労使対話を伴う領域に入る。
ここまで来ると、技術ベンダーが単独で語れる領域を超える。

本連載は、L4 までを技術論の射程に置き、L5 は技術的成立条件のみを示し、社会的成立条件は別議論として切り分ける立場を取る。

TM Forum の議論と本連載が補完関係になる理由

ここまでの整理を踏まえて、本連載と TM Forum AN フレームワークの関係を一文でまとめると、こうなる。

業界の議論の場で TM Forum の用語が出てきた時、本連載の議論をTM Forum を否定する形で持ち込むのは、生産的ではない。
TM Forum の組織成熟度の議論に対し、技術側からの実装条件として本連載の議論を接続する — これが、両者を建設的に並べる正しい姿勢である。

Catalyst プロジェクトとの接続可能性

TM Forum には、Catalyst プロジェクトという、CSP（キャリア）と複数ベンダーが共同で実証を行う仕組みがある。
ここでは、業界共通の課題に対して、マルチベンダーで実装可能な解を実証する場が用意されている。

本連載で論じてきた実行層の道具立ては、Catalyst プロジェクトの対象として、構造的に親和性が高い。
理由は単純で、

1. 課題が業界共通（L3 で止まる）

2. 解が単一ベンダー閉じではない（観測・判断・データ層は各社製品を組合せ可）

3. 統制レイヤー（W365 for Agent / Entra Agent ID）が業界 Defacto として整理可能

ここから先は、業界読者・キャリアの方々との具体的な対話領域である。
本稿で書ききる範囲を超えるため、別途、関心ある方とは個別に議論を進めたい。

次回予告：統制の壁、その本当の高さ

次回（第 14 回）は、もう一つの補論として、統制の壁に踏み込む。

技術が揃っても、社内決裁が降りない — これは Telco に限らず、エンタープライズが新技術を導入する時に必ず直面する局面である。
特に、エージェントが業務システムを動かすという話は、責任分界・監査・データ境界・サンドボックス・規制対話 — 統制論のフルセットが立ちはだかる。

ここを抜けないと、いくら技術が成立しても、現場には降りない。
構造的に解く道筋を、次回示す。

注意事項（再掲）

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

• 本稿の TM Forum AN フレームワークに関する記述は、TM Forum 公開資料・業界二次報道に基づく著者の理解・要約です。最新の公式定義は TM Forum 公式資料をご参照ください。

• Catalyst プロジェクトへの参加可否・要件は、TM Forum の公式案内をご確認ください。

連載インデックス

• 第 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 への適用① — 障害対応クローズドループ

• 第 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,400 字 / 読了 13 分

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

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

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