要約

  • LACNICが9月9日に掲載した寄稿は、実行能力としての自動化と、決定能力としての自律性を分け、単一の領域と運用プロセスから始めるよう提案する。したがって、得られた段階もその対象から切り離せない。
  • 検証できる主張には、評価対象と期間、5次元の人間・システム分担、最低値から得た段階、根拠、基準値と成果、人間の介入権、変更後の再評価条件を持つシナリオ台帳が必要だ。

二つの通信事業者が、ともに自社をL3と説明したとする。一方は障害情報の収集と原因分析を自動化したが、設定変更は技術者が承認する。もう一方はサービス開通の判断と実行を自動化したものの、在庫情報の一部は人が確認する。同じ数字でも、止まりやすい場所も、責任が残る場所も違う。

LACNIC Blogは2026年9月9日、Hernán Arcidiaconoによる記事を掲載した。筆者はIplan ArgentinaのCTOでIANA Review Committeeのメンバーと紹介され、ページには見解が必ずしもLACNICを代表しないとの注記がある。記事の出発点は明快だ。自動化は実行する能力、自律性は決定する能力である。自動化された仕組みは固定ルールに従い、自律的な仕組みは自らの状態、目的や意図、環境を踏まえて動く。

議論の範囲は機器だけではない。記事が参照するTM Forumの枠組みは、リソース、サービス、ビジネスの三層を扱う。変わるのはネットワーク運用だけでなく企業の業務モデルだ。それでも着手点は狭く設定される。アクセスやIPなど一つの自律ドメインと、障害管理など一つのプロセスを選び、初期には人間を決定段階に残しながら進める。

この限定こそ評価の住所である。一つのアクセス障害ループが成功しても、請求、顧客対応、コア網、セキュリティ対応、電力最適化まで同じ成熟度とは言えない。企業の構想は全社的であってよいが、証明された能力はシナリオごとに発生する。

数字の前に評価対象を置く

TM ForumのIG1252公開ページは、ネットワークまたはその一部を、運用プロセス、下位プロセス、タスク、評価基準に沿って調べる方法だと説明する。会社名そのものを最小単位にはしていない。

ITU-T Y.3173は、ライフサイクル上のワークフローとネットワーク・サブシステムという二つの視点を用いる。ネットワーク全体の知能段階は、それら個別対象の段階を総合したものだ。関連するワークフローとサブシステムが一定段階以上に達して初めて、全体もその段階に達したとみなせる。対象はユースケースで変わるため、同じネットワークでも答えは一つとは限らない。

評価は五つの次元に分かれる。

  1. 要求の写像：運用要求を機器や機能が実行できる指示に変える。
  2. データ収集：状態把握と分析に必要な情報を得る。
  3. 分析：現状を解釈し、必要なら将来を予測する。
  4. 決定：設定またはサービス上の行動を選ぶ。
  5. 行動実装：選ばれた決定をネットワークに反映する。

各次元について、人間、システム、人間とシステムの共同のどれが担うかを判定する。ユースケースの総合段階は、該当する次元のうち最も低い段階で制約される。最も派手な機能の高さを、ループ全体へ繰り上げる方法ではない。

この最低値の原則は、展示向けの計算を防ぐ。アラーム分類が優秀でも、変更の承認が自律化されたことにはならない。エージェントが説得力のある計画を書けても、入力データの十分性や実行権限は別問題だ。高速に設定を変えられても、曖昧な意図は正しくならない。

Y.3173はさらに、どの段階でも人間の決定と実行指示が最高の権限を持つとしている。L4という表示だけでは、契約責任、停止権、例外の承認、損失負担は決まらない。段階は限定された能力配分を示し、ガバナンスは別に設計される。

能力と成果を同じ勘定にしない

自律度の上昇を、そのまま良いサービスの証拠にするのも危険だ。2025年12月承認のITU-T Y.3063は、自律能力の効果を別の枠組みで測る。四層は、事業価値目標、エンドツーエンド事業シナリオの成果、ドメイン固有の能力指標、その計算に使うネットワークデータである。

自動完了するタスクが増えても、可用性が上がるとは限らない。処理時間を短くして、まれな例外の費用を増やすこともある。省電力がカバレッジを損なう場合もある。手作業のチケットが減る一方で苦情が増えることも考えられる。成熟度は誰が作業するかを示し、効果は作業の後に何が変わったかを示す。

Y.3063は価値目標を顧客体験、運用効率、リソース効率に分ける。提供・開通時間、可用性、中断時間、平均復旧時間、導入時間、自動運用比率、電力、リソース充足などが指標例だ。すべての指標をすべてのシナリオに使うわけではない。基準値、観測期間、データと集計の対応が必要になる。

実践例はまず、関係する運用ドメインのエンドツーエンド・シナリオを棚卸しする。次に各シナリオの指標と寄与を定め、優先順位を付け、試行後に拡大する。先に全社スコアを選ぶのではなく、仕事と期待成果を定義してから、証明できた部分を広げる順序だ。

この考え方は、LACNICの記事が参加を促す中小ISPにも向く。地域ISPは巨大な全社改革をまねる必要がない。繰り返しが多い、高コスト、あるいは失敗しやすい一つのプロセスを選び、現在の人機分担を記録し、範囲を限って自動化し、前後を比較できる。規模ではなく証拠の質で比較できる。

シナリオ台帳の項目

ここで提案する台帳はTheo Marchの分析であり、LACNIC、TM Forum、ITU、ETSIの公式要件ではない。役割は、総合数字が落としてしまう接続関係を保つことだ。

最初に運用者、責任者、対象ドメインまたはネットワーク部分、ユースケース、ワークフロー、トリガー、評価期間、方法の版を記す。「障害管理」だけでは広すぎる。セル停止、光伝送障害、設定ドリフトは別の記録にする。

次に五次元ベクトルを置く。要求、データ、分析、決定、実行ごとに担当と根拠を示す。根拠には意図の版、データ参照、モデルまたはルール、決定記録、変更ID、事後状態の確認が含まれる。要約段階は該当最低値で、ベクトルも併記する。

三つ目は成果だ。基準値、シナリオに合う指標、観測窓、結果を分けて残す。平均復旧時間、可用性、自動化率は互換ではない。都合のよい一項目だけを後から選ばせない。

四つ目は制御である。人間の介入権、行動半径、例外経路、ロールバック責任者、終状態の証拠を結ぶ。仕様書にロールバック機能があるだけでは足りない。実際の発火、判断、変更、悪化、復元を一件の記録として追える必要がある。

最後に有効期限を置く。モデル、意図、トポロジー、データ、ベンダー、ソフトウェア、権限が変われば旧評価は古くなる。重要変更を再評価のトリガーにしなければ、過去の段階が別のシステムに貼り付いたままになる。

エージェントが増えるほど住所が要る

ETSI GS ZSM 002は、ドメイン内管理と複数ドメインをまたぐエンドツーエンド管理を分ける。異なる粒度の閉ループが同時に動き、横方向または階層的に協調できる。2026年1月のETSI GR ZSM 020は、人間が決定するコパイロット、監督付き自律エージェント、完全自律エージェントを区別し、機能と行動種類でも分類する。

ドメイン横断障害の例では、ローカル・エージェントが異常を検出し、能力を検索し、コーディネーターへ文脈を渡し、調査チームを組み、処理後のフィードバックを得る。複雑な協調の中に、人の重要な承認が残ることはあり得る。逆に狭いローカル処理が高い自律性を持っても、会社全体は語れない。

エージェントが増えるほど「当社はL4」だけでは不足する。どの能力を、誰が発見し、どんな依頼を受け、どの権限で実行し、何を確認したのかが必要だ。

段階は古くなる

評価が誇張される道筋は五つある。最も進んだタスクがループ全体を代表し、ループがドメインを、ドメインが企業を、能力が成果を、古い評価が変更後のシステムを代表する。境界を一つ消すたびに売りやすくなり、検証しにくくなる。

LACNIC掲載記事の強みは、一つの対象から段階的に始める点にある。その規律を全社バッジに変える必要はない。段階を残し、その数字が生まれたシナリオへ必ず戻れるようにすればよい。

自律度は終身称号ではない。再現可能で期限付きの技術判断である。

出典