情報管理技術士 学習ノート
← 一覧へ
ネットワーク
#인텐트 기반 네트워킹#IBN#SDN#폐루프 자동화#네트워크 관리#3GPP TS 28.312#TM Forum
最終更新 · 2026-09-29

インテントベース・ネットワーキング（IBN）と意図駆動型ネットワーク運用

1. 概要

A. 定義

インテントベース・ネットワーキング（Intent-Based Networking, IBN） とは、運用者がネットワークに求める目標・要件・制約を宣言的に表現し、システムが実行可能なポリシーと設定に変換・適用した後、観測データによって達成状況を継続的に検証する閉ループ型のネットワーク運用方式である。

IBNの本質的な変化は、装置ごとのコマンドを人が直接記述する方式から、ネットワークが実現すべき業務成果を先に表現する方式への移行である。 運用者は「この経路を4ホップで設定せよ」ではなく、「社内ネットワークの決済トラフィックは遅延20ms以下、可用性99.99%を維持し、インターネットから直接アクセスできないようにせよ」と記述する。 システムは、目標を実際のトポロジー、リソース、ポリシー、装置機能と照合し、実行計画を作成し、変更後も要件が満たされるかを確認する。

したがってIBNは、単なる自然言語コマンドのインターフェースや設定スクリプトではない。 自然言語は入力を補助する手段となり得るが、実行前に曖昧さを除き、検証可能なモデルに正規化する必要がある。 また、自動化は装置に設定を書き込む段階で終わるのではなく、テレメトリで実際の結果を観測し、意図した成果と比較する保証（assurance）段階まで含まなければならない。

3GPPはインテントを、達成方法を指定せずにシステムへ与える要件・目標・制約を含む期待事項の集合と定義する。 この定義の要点は、何を（what） 達成するかと、どのように（how） 実装するかを分離することである。 IBNは通信ネットワークで具体化したが、データセンター、企業キャンパス、クラウドネットワークのポリシーやサービスレベル管理にも適用できる。

B. 背景と必要性

企業ネットワークは、オンプレミスのデータセンター、パブリッククラウド、支店、モバイル利用者、5G、IoTが複数のドメインにまたがって接続され、複雑化している。 装置ごとにCLIや設定モデルが異なり、変更が相互に依存するため、経験豊富な運用者でも影響範囲全体を把握しにくい。 装置数が増えるほど、反復的な設定・変更検証・障害調査にかかる時間も増え、手作業は設定差異と人的ミスを蓄積させる。

従来の自動化は、あらかじめ定義した一連のコマンドを迅速に実行するには有効だが、業務目標が実際に達成されたかは別途評価する必要がある。 IBNは目標をポリシーとして解釈し、観測された結果が目標と一致するかを確認し、逸脱があれば修正計画を提案するか、限定された範囲で自動措置を行う。 自律化の程度にかかわらず、人によるレビューと承認、変更履歴、ロールバックを統制策として維持すべきである。

IBNはソフトウェア定義ネットワーキング（SDN）の制御プレーンとデータプレーンの分離、プログラマビリティを活用するが、SDNとIBNは同義ではない。 SDNはネットワーク制御をソフトウェア化する基盤アーキテクチャであり、IBNはその上で業務要件を表現・実現・保証する運用モデルである。 つまりSDNは「制御できる能力」を、IBNは「望ましい結果を継続的に満たす管理方法」を重視する。

C. 主な特性

  • 成果中心：装置ごとの手順ではなく、サービス品質・到達性・セキュリティなどの結果を記述する。
  • 抽象化と変換：業務用語をネットワークのオブジェクト・ポリシー・設定へ変換し、実装詳細を隠す。
  • 検証可能性：インテントには測定指標、適用範囲、条件、制約が必要である。
  • 閉ループ運用：観測と評価を繰り返し、望ましい状態と実際の状態の差を小さくする。
  • ポリシーの一貫性：多数の装置やドメインに一貫してポリシーを適用し、競合を検出する。

これらの特性は相互に依存する。 測定できない目標は保証できず、適用範囲や制約が曖昧な目標は変換段階で誤って解釈される可能性がある。 反対に、保護策を設けず広範な実行権限を付与すると、自動化の速度で障害やセキュリティ事故が拡大するおそれがある。

2. IBN参照アーキテクチャと閉ループ

IBNは、人や業務システムの要求をネットワークポリシーと装置動作につなぎ、結果を元の要求と比較する階層構造として説明できる。 論理機能は変換（translation）、実行・適用（activation）、保証（assurance）の3つに整理され、実装では1つのコントローラーまたは複数の管理システムに分散され得る。 次の図は、インテントがポリシー・設定となり、観測結果が保証機能へ戻る基本経路を示す。

flowchart LR
  U["業務利用者・運用者"] --> I["インテントモデル<br/>要件・目標・制約"]
  I --> T["変換・競合・実現可能性の検証"]
  T --> P["ポリシー・変更計画"]
  P --> O["オーケストレーター・コントローラー"]
  O --> A["ドメインアダプター<br/>API・NETCONF・CLI"]
  A --> N["ルーター・スイッチ・FW・クラウド網"]
  N --> M["テレメトリ・ログ・性能指標"]
  M --> Q["保証・逸脱分析"]
  Q --> I

インテント消費者は、サービスオーナー、ネットワーク運用者、アプリケーション、上位管理システムなどである。 消費者は詳細なネットワーク設定を指定せず、対象サービス、品質目標、範囲、有効期間、セキュリティ制約を提示する。 業務担当者の表現を未確認のまま本番環境に投入するのではなく、ネットワーク担当者とサービスレベルを合意し、測定可能な定義に変換する必要がある。

インテントモデルと変換機能は、要求を機械が解釈できる構造に正規化する。 変換機能は対象オブジェクトや指標を特定し、欠落値や相反条件を検出し、利用可能な機能とリソースに基づいて実現可能性を判断する。 要求が不可能または競合する場合、一部を黙って無視せず、競合項目と代替案または交渉可能な目標値を利用者へ報告すべきである。

ポリシー・計画の生成とオーケストレーションは、望ましい状態に到達するための変更をドメインごとの実行手順に分解する。 例えば「支店の決済システムだけが社内アプリケーションへアクセスできる」という目標は、アドレスグループ、ファイアウォール規則、ルーティング、認証ポリシーに分解できる。 計画段階では依存関係、影響範囲、リソース不足、変更順序、事前・事後確認、補償動作を考慮する必要がある。

ドメインアダプターとネットワークリソースは、抽象ポリシーを装置別またはクラウド事業者別のインターフェースを通じて伝達する。 アダプターはREST API、モデルベース管理インターフェース、装置固有APIなどを抽象化するが、機能差を完全に解消するわけではない。 マルチベンダー環境で一貫性を維持するには、機能カタログ、アダプターのバージョン、対応範囲、エラー処理のライフサイクルを管理しなければならない。

保証機能は、管理システム上の設定状態だけでなく、実際のパケット損失、遅延、可用性、到達性、セキュリティイベントなどのサービス指標を収集する。 目標と実測値の差、ポリシー適用状況、データの鮮度・信頼性を併せて分析し、目標の充足状況を報告する。 逸脱があれば、事前に定めた再計算・通知・承認要求・自動修正を実施し、修正後に再検証する。

この構造では、設定された望ましい状態（desired state） と観測された実際の状態（observed state） を区別する原則が重要である。 コントローラーにポリシーが登録されていても、装置が受け付けなかったり、トラフィック経路が迂回したりすれば、サービス結果は目標と異なり得る。 したがって保証では設定確認とサービス成果の検証を組み合わせ、各判定に証拠・時刻・信頼度を付与する必要がある。

3. インテントモデルとライフサイクル

A. インテントの構成要素

インテントは自然言語の一文ではなく、適用範囲と評価方法を持つ構造化された期待事項である。 一般に対象オブジェクト（object）、期待事項（expectation）、目標（target）、値または条件（condition）、コンテキスト（context）、制約（constraint）を区別する。 例えば「営業時間中、ソウル本社の決済サービスの往復遅延を20ms以下に維持し、インターネットから直接アクセスさせない」は、対象・時間範囲・性能目標・セキュリティ制約を含む。

対象オブジェクトは、インテントを適用するネットワーク、サービス、端末、エリア、スライスを識別する。 対象が曖昧だと、ポリシーが過度に広い範囲に適用されたり、一部の装置だけが対象となり、サービス経路が不完全になったりする。 固定IDだけでなく、タグや場所・役割などのコンテキスト条件で対象を選ぶ場合は、条件変更によって対象集合がどう変わるか評価する必要がある。

目標と期待事項は、達成したい結果と判定に使う指標を表す。 「速く」「安全に」といった表現だけでは判定できないため、遅延上限、可用性、許容損失、アクセス許可リストなどの数値・規則に具体化する。 ただし単一指標を過度に最適化すると、コスト・レジリエンス・セキュリティなど他の目標を損なう可能性があり、優先順位と許容範囲も定義する。

コンテキストと制約は目標が有効な条件を説明する。 時間帯、トラフィック種別、場所、容量上限、規制区域、保守期間、予算などを指定すれば、同じサービスでも状況に応じて適切なポリシーを選択できる。 制約は目標達成の過程で越えてはならない境界であり、例えば「可用性向上のためにコストを無制限に増やさない」といった運用上限も含み得る。

インテントレポートは、受理・実現可能性・充足状態・競合・失敗原因・達成指標を消費者に伝える。 要求を受領した確認（acknowledgement）と、目標の実際の達成（fulfilled）を混同しない状態モデルが必要である。 レポートは調整と監査に利用されるため、目標バージョン、適用範囲、観測時刻、判定根拠を保持すべきである。

B. 管理ライフサイクル

運用上のライフサイクルは、目標受付後の検証・実行・保証・変更・廃止まで続く反復プロセスである。 3GPPの管理サービスはインテントの作成・変更・削除・照会、有効化・無効化、レポート照会・購読、能力照会、実現可能性確認・交渉手順を扱う。 これらの機能により、サービス要求や季節・イベント需要が変わった場合でもポリシーを統制下で更新できる。

flowchart TD
  A["1. 業務要件を収集"] --> B["2. 表現を正規化し範囲を定義"]
  B --> C["3. 能力を探索し実現可能性を確認"]
  C -->|可能・合意済み| D["4. ポリシー・変更計画を生成"]
  C -->|不可能・競合| X["代替案提示・交渉・承認"]
  X --> B
  D --> E["5. リスク・影響を審査し承認"]
  E --> F["6. 段階的に有効化"]
  F --> G["7. テレメトリで保証"]
  G -->|目標達成| H["報告・継続観測"]
  G -->|逸脱・障害| R["調整・ロールバック・運用者介入"]
  R --> D
  H -->|要件変更・期限終了| A

第一に、要件収集と表現の正規化では、関係者間で用語を統一し、対象、指標、時間条件、優先度、責任者を特定する。 入力文を自動分析する場合でも、「できるだけ速く」のような曖昧な表現を任意のSLAに変換せず、追加確認または承認を求める。

第二に、能力探索と実現可能性確認では、担当ドメインが必要な指標・ポリシーをサポートし、装置とリソースが目標に対応できるか確認する。 実現可能性は文法チェックだけではなく、現在状態、他のインテント、共有リソース、安全・規制上の制約を考慮すべきである。 目標が現実的でない場合は、実現できない理由と調整可能な値または代替案を示す交渉が必要となる。

第三に、計画と承認では、変更順序、影響分析、リスク、障害時の復旧策を算出する。 業務影響が大きい経路では、計画が自動生成されても、運用者承認、保守時間帯、変更管理規程を通過してから実行する。 段階的な展開と小さな影響範囲は、誤りがネットワーク全体へ拡大するリスクを下げる。

第四に、有効化と継続保証では、設定結果と実際のサービス性能を併せて評価する。 指標に異常があれば自動措置を実行できるが、権限、変更速度、再試行回数、停止条件を事前に制限すべきである。 ポリシーを変更した後も目標達成を再測定し、証拠が不確実または観測データが不足している場合は、自動措置より通知と人の判断を優先する。

4. 運用方式の比較と設計事例

従来の装置単位運用では、運用者が実装手順を決め、各装置にコマンドを入力する。 この方式は明示的な制御が可能で小規模環境では理解しやすいが、規模拡大に伴ってポリシー不整合と反復作業が増える。 スクリプトや構成管理ツールは実行を自動化するが、事前定義された手順を超える成果検証と目標駆動の再調整には別設計が必要である。

観点 装置コマンド・スクリプト SDNベースの自動化 インテントベース運用
入力の視点 装置動作・コマンド ネットワークリソース・ポリシー 業務目標・要件・制約
実装責任 運用者が手順を作成 コントローラーが抽象化・配布 変換・計画・検証機能を連携
検証レベル コマンド成功の確認 ポリシー・設定の適用確認 目標成果の継続的達成
フィードバック 事後確認または手作業 コントローラー状態・イベント テレメトリに基づく閉ループ保証
リスク 設定差異・人的ミス コントローラー・ドメイン依存 目標の誤解釈・過度な自動化

IBNはSDNを置き換える独立プロトコルではなく、SDNや既存管理システム上に構築する成果中心の運用アプローチである。 ポリシーベース管理や構成自動化と機能が重なることがあるため、製品名だけで導入有無を判断してはならない。 実適用の判別基準は、宣言した目標が機械可読な構造を持つか、実行後の目標達成を測定するか、逸脱に対する統制されたフィードバック経路があるかである。

事例：複数拠点の決済サービスに対する品質・セキュリティインテント

金融会社が支店とクラウドに分散した決済サービスを運用しているとする。 業務オーナーは「営業時間中、決済アプリケーション通信の往復遅延を20ms以下、月次可用性を99.99%とし、データベースへのインターネットからの直接アクセスを禁止する」と要求する。 ネットワークチームはこれをサービスグループ、時間帯、測定区間、指標に構造化し、遅延・可用性の算出方法、許容例外、データベースへのアクセス経路を定義する。

変換機能はWAN経路、クラウドのセキュリティグループ、ファイアウォールポリシー、サービスタグ、現在の帯域を確認して計画を作成する。 リンクが混雑していて目標達成が不可能なら、別経路の利用、帯域拡張、目標値調整などの選択肢を報告し、サービスオーナーの承認を得る。 承認済み変更はまず1拠点で検証した後に他拠点へ広げ、各段階で決済遅延と接続成功率を確認する。

運用中に遅延目標超過とファイアウォール規則の迂回可能性が同時に検知されても、性能調整とセキュリティ遮断を無理に1つの変更にまとめてはならない。 原因とポリシー競合を分類し、サービス継続性への影響を評価した上で、限定的な代替経路または承認済みロールバックを適用する。 この事例は、目標を一文で宣言することより、測定・競合解決・承認・証拠保存がIBNの信頼性を左右することを示す。

比較：ネットワークスライシングとIBN

ネットワークスライシングは、共有物理基盤上にサービス特性ごとの論理ネットワークを提供する資源分割・サービス提供技術である。 IBNは要求を表現し、ネットワークが望む成果を出すよう構成・観測・調整する管理方式である。 IBNがスライス管理者へ要求を渡し、スライス管理が具体的なリソースに実現できるため、両者は競合概念ではなく異なる階層で連携できる。

5. 発展：標準化、自律化の段階と限界

IBNという用語は業界で広く使われているが、全事業者に共通する情報モデルと動作を定める単一の汎用規格が完成したと断定すべきではない。 装置機能、インテント表現、レポート、競合処理、自動修正の範囲は製品・ドメインによって異なる。 したがって製品のマーケティング名称ではなく、データモデル、API、相互運用性、監査機能、自動化権限、実績測定基準を確認する必要がある。

通信分野では3GPP TS 28.312がモバイルネットワーク向けのインテントベース管理サービスを規定し、ライフサイクル、レポート、能力照会、交渉手順を扱う。 3GPPモデルは管理サービスの消費者と提供者、インテント期待事項、インテント処理機能、レポートを区別し、ネットワークドメイン間の管理インターフェースを構造化する。 2026年9月時点で3GPP公式技術ページはTS 28.312の最新バージョンをV19.1.0と示しているため、設計・調達時には適用Releaseと改訂版を公式ページで再確認する必要がある。 3GPPとは別に、TM Forumは自律ネットワークのインテント概念、共通モデル、ライフサイクル、管理APIの作業を進めており、各仕様の範囲とバージョンを区別して参照すべきである。

運用の自律性は段階的に拡大するのが望ましい。 初期段階では、インテントの収集・検証、影響分析、変更計画の作成に注力し、運用者がレビュー・承認する方式でリスクを抑える。 データとポリシーの品質が検証されたら、低リスク作業に限定した自動実行を認め、高影響作業には承認・ロールバック・停止条件を維持する。

閉ループ制御の安定性はネットワーク制御の遅延と観測周期の影響を受ける。 補正が速すぎると十分な観測前に変更を繰り返し、振動（oscillation）を発生させる可能性がある一方、遅すぎるとSLA違反を長く放置することになる。 ヒステリシス、安定化時間、変化率制限、再試行上限、措置ごとのクールダウンを設定し、実環境に近い負荷・障害条件で試験する必要がある。

6. 考慮事項と示唆

  • 目標の測定可能性と曖昧さの解消：業務表現を指標・範囲・時間・対象・例外に分解する。部門ごとに測定定義が異なれば、ダッシュボードが正常でも実際の要求を満たさない場合がある。
  • 競合と共有リソースの管理：インテントの優先度、リソース競合、ポリシー矛盾、委任範囲を明示する。不可能な目標を黙って無視せず、根拠と交渉案を報告する。
  • 変更の安全性と人の統制：影響分析、承認ゲート、段階展開、ロールバック、停止スイッチ、監査ログを実装する。自動化水準を業務影響と復旧可能性に応じて設定する。
  • 保証データの品質：テレメトリの完全性・正確性・時刻同期・収集遅延を管理する。データ欠落を目標達成の証拠とせず、観測不能状態を別に表示する。
  • マルチベンダー相互運用性：機能カタログ、共通オブジェクトモデル、インターフェースバージョン、例外処理を検証する。抽象化層はベンダー差を隠すのではなく、潜在制約を明らかにするよう設計する。
  • セキュリティ・権限・説明責任：インテント消費者と実行主体を認証し、役割ベース・最小権限、ポリシー署名、秘密情報保護、不変監査記録を適用する。入力経路が侵害されれば、正規の自動化が攻撃手段に変わり得る。
  • 成果指標と投資効果：展開速度だけでなく、変更失敗率、MTTR、SLA達成率、設定差異、自動修復後の再発率、運用者介入時間を測定する。技術導入を自律化の成果と誤認しない。
  • 段階的導入と運用能力：まず可観測性・ポリシー管理・構成自動化を成熟させ、単一ドメインの低リスク事例で検証する。ネットワーク・セキュリティ・アプリケーション各チームが共同で目標と責任を定義する。

情報管理技術士の観点では、IBNはSDN、ネットワーク自動化、AIOps、閉ループ制御、自律ネットワークをつなぐ成果中心の運用パラダイムである。 成功はAI導入の有無よりも、業務目標の形式化、信頼できる観測、安全な変更管理、責任体制によって決まる。 したがって導入ロードマップでは、「完全自律化」を単一目標とするのではなく、測定可能なサービス改善と統制可能な自動化範囲を段階的に示すべきである。

参考資料

一言まとめ: IBNはネットワークに目標と制約を宣言し、ポリシー・設定として実現した後、サービス指標で継続検証する閉ループ運用方式であり、測定可能なインテント、安全な自動化、信頼できる観測性が成否を決める。