Telco AN への適用③ — 自己修復・自己最適化と Learning Loop
Telco × Agentic AI ／ 第 11 回
2026 年 6 月 ／ 著：ヒキノ ヒロユキ
🎧 音声で聴きたい方はこちら
本文を読む前に、音声で全体像をつかみたい方はこちらからどうぞ。
再生ボタンを押すだけで聴けます。
本記事は個人としての見解であり、所属組織を代表するものではありません。
はじめに：L4 を成立させる「最後の山」
第 9 回と第 10 回で、障害対応とサービス展開の 2 つの業務に、クローズドループ設計を適用できることを示した。
ここまでで残っている、自律ネットワーク（AN）L4 の最後の条件は何か。
それは、 自己修復（Self-healing）と自己最適化（Self-optimization） である。
3GPP / TM Forum / ETSI が L4 / L5 の議論で繰り返し挙げてきた、業界の長年の念願がここにある。
障害の予兆を、人間が気づく前に察知し、構成を変える
KPI の劣化に対し、自律的にパラメータを最適化する
一度成功した対処を、組織知として蓄積し、次の事象に転用する
今回は、これらが第 8 回までの道具立てだけでは不足することを述べた上で、第 6 回で名前だけ出した Learning Loop がここで決定的な役割を担うことを論じる。
そして、これをもって、Act 1 の 3 つの適用シナリオが完結する。
自己修復は「迅速な障害対応」ではない
まず、自己修復という概念を、業界の言葉から正しく取り出しておきたい。
自己修復は、しばしば「障害対応を速くすること」と混同される。
しかし、両者は質的に違う。
| 項目 | 障害対応（第 9 回） | 自己修復 |
|---|---|---|
| トリガー | 顕在化したアラート | 予兆・微細な逸脱 |
| 主な作業 | 復旧 | 構成・容量・経路の事前変更 |
| 成功の定義 | サービスを戻す | 障害が顕在化しない |
| 必要な能力 | 観測 + 判断 + 実行 | 観測 + 学習 + 判断 + 実行 |
自己修復が成立するには、過去の事象に対する経験の蓄積が必須になる。
「同じ予兆の時に、過去はこう対処して、結果はこうだった」という知識を、組織の外（個人の頭の中・属人化された Excel）から、組織の内（再利用可能な知識資産）に取り出さなければ、自己修復は動かない。
ここで、Learning Loop の出番となる。
Learning Loop — 4 階層メモリという設計
第 6 回で、Agentic AI Runtime の枠組みを抽象的に語った時、Learning Loop には触れたが、深入りはしなかった。
ここで、4 階層に分けて整理する。
Learning Loop の本質は、Episodic Memory（個別ログ）を Procedural Memory（再利用可能な手順）に昇華させる仕組みである。
これがあると、現場で何が起きるか。
1 回目の事象：エージェントが試行錯誤しながら対処（時間がかかる）
検証エージェントが、成功した手順を標準化可能な形で抽出
Procedural Memory に格納、類似条件で再利用可能に
2 回目以降の事象：エージェントが過去の成功パターンを即座に呼び出して適用
組織として 「同じ問題を二度解かない」 状態が、ここで初めて成立する。
なぜ既存の OSS/BSS でこれが実現しなかったか
「これ、過去 20 年やろうとしてきたことじゃないの？」という疑問は当然出る。
実際、TM Forum の Knowledge-Based 自律運用、Self-Organizing Network（SON）、AIOps、CMDB ベースの自動化 — どれもこの理想を語ってきた。
しかし、現場で真に自己修復として機能した例は、極めて限定的だ。
理由は、4 階層のうちEpisodic と Semantic までしか持たなかったことに尽きる。
ログは溜まる（Episodic）
ナレッジベースは整備される（Semantic）
しかし、「成功した手順」を組織知として標準化する仕組み（Procedural）がない
そして、「組織として何をやってはいけないか」（Constitutional）が AI に明示的に渡せない
結果として、AI はナレッジ検索エンジン止まりで、自律実行に踏み込めなかった。
ここに、Agentic AI Runtime としての設計が違いを生む。
第 6 回・第 7 回・第 7.5 回・第 8 回で揃えてきた道具立てを、もう一度並べ直すと、
Procedural Memory：Copilot Workspace / Logic Apps / Opal Workflow テンプレート
Constitutional Memory：Purview / Entra Policies / Intune Compliance
Episodic / Semantic：Azure Monitor / App Insights / AI Search / Cosmos DB
つまり、4 階層メモリを製品として持つこと自体が、Microsoft スタックの構造的な特徴になる。
これは、第 12 回（Why Microsoft）への布石でもある。
自己最適化 — KPI と Closed Loop
自己修復のもう一つの顔が、自己最適化である。
5G の RAN（無線アクセス）や、コア網のトラフィックエンジニアリングでは、KPI（スループット・遅延・パケットロス・接続成功率）の最適化が、終わりなく続く運用業務となっている。
従来は、
ベンダー専用ツールでパラメータを変える
1 週間後に KPI を見て、効果を確認
良ければ全セル展開、悪ければ戻す
このサイクルが、属人化された熟練技に依存する
これを、第 8 回までのクローズドループに重ねると、
観測エージェントが KPI 劣化（あるいは改善余地）を検知
判断エージェントが、過去の Procedural Memory から類似ケースを引き当てる
実行エージェントが、限定セルで試験的にパラメータ変更
検証エージェントが、KPI 変化を継続観測
良ければ自動で範囲拡大、悪ければロールバック
結果を Procedural Memory に書き戻す
この**「観測 → 判断 → 実行 → 学習 → 再観測」のループ自体が継続的に回り続ける状態**こそ、TM Forum L4 の本質的な要件である。
そして、L4 を超えて L5（複数領域横断）に踏み込むには、Procedural Memory が領域を跨いで再利用される必要がある。
ここから先は、Act 2 の議論領域となる。
3 シナリオの統合 — 「閉じたループの群れ」としての AN
第 9 〜 11 回で、3 つのシナリオを並べた。
障害対応（戻す）
サービス展開（作る）
自己修復・自己最適化（保つ・育てる）
これらは、運用組織の機能としては別チームに分かれている。
しかし、構造としては、全て同じクローズドループの変奏である。
| シナリオ | トリガー | 主にどの Loop が回るか |
|---|---|---|
| 障害対応 | アラート | 観測 → 判断 → 実行 → 検証 |
| サービス展開 | 受注・契約変更 | 判断 → 実行 → 検証（観測は事前条件） |
| 自己修復・最適化 | 予兆・劣化 | 観測 → 学習 → 判断 → 実行 → 学習 |
3 つを同じ Runtime の上に乗せることができる、というのが本連載の到達点である。
ここから先、業界は「シナリオごとに別ツール」から「シナリオに依らない単一 Runtime」への発想転換を求められる。
次回予告：Why Microsoft — 構造的優位の理論
ここまでで、実行層の道具立てと、その業務への適用が一通り出揃った。
しかし、まだ最大の問いに答えていない。
「なぜ、これを Microsoft が担えるのか。なぜ他のクラウド・他のベンダーではないのか？」
次回はこの問いに、感情論ではなく構造論で答える。
実行層に必要な 5 つの条件と、それを揃えられるベンダーが誰なのかを、表で並べる。
歴史上の類似戦略（VMware SDDC、Salesforce Customer 360）との比較も入れる。
ここから先は、本連載で最もチャレンジングな回となる。
注意事項（再掲）
本記事は個人としての見解であり、所属組織を代表するものではありません。
3GPP / TM Forum / ETSI の規格・概念は、各団体の公式仕様をご確認ください。
「自己修復」「自己最適化」「SON」「AIOps」等の用語は、業界で広く用いられる一般概念として記述しています。
連載インデックス
第 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,600 字 / 読了 14 分
著者：ヒキノ ヒロユキ
通信業界 20 年。3G・4G・5G モバイルコアネットワーク設計 ／ 元 Cisco ネットワークエンジニア ／ 現 Microsoft（個人としての発信） ／ ディエスタデイ合同会社 代表
ご意見・ご質問は記事コメントまたは LinkedIn にて、お気軽にどうぞ。
もし本連載に共感いただけたら、ぜひ note のスキ・フォロー、LinkedIn でのリポストをお願いします。