IOS-XRとは？Cisco IOS・IOS-XEとの違いと特徴・対応機器を解説【2026年最新】

IOS-XR（Cisco IOS-XR）は、通信事業者や大規模ネットワーク向けにCiscoが提供するルーター用OSです。同じCisco製でも、企業ネットワークで広く使われるclassic IOSやIOS-XEとは設計思想・対応機器・コマンド体系が異なり、検索でも「IOSとIOS-XEとIOS-XRは何が違うのか」が最も多く調べられています。この記事では、IOS-XRとは何かを起点に、IOS・IOS-XEとの違いを比較表で整理し、分散型アーキテクチャの特徴、設定・運用の基本、仮想版XRv9000での検証、対応機器までを2026年6月時点の情報で解説します。なお本記事はCiscoのネットワークOSであり、Appleの「iPhone XR」とは無関係です。

まとめ：IOS-XRはSP・大規模向けの分散型ルーターOS、エンプラはIOS-XEが基本

先に結論です。IOS-XRは、ASR 9000やNCSシリーズといったキャリアグレード機で動く、プロセス分離型の高可用性ルーターOSです。classic IOSやIOS-XEがモノリシック（一体型）で1つのプロセスが落ちると影響が広がりやすいのに対し、IOS-XRは各機能を独立プロセスとして動かすため、一部の障害がシステム全体に波及しにくいのが最大の違いです。

使い分けの目安はシンプルです。支店・キャンパス・データセンターなど企業ネットワークならIOS-XE（Catalyst 9000やISR、ASR 1000）、ISPのバックボーンや大規模コアルーターならIOS-XR（ASR 9000、NCS 5500/5700）が基本です。中小規模のLANにIOS-XRは過剰で、学習目的なら実機を買わずに仮想版のXRv9000やXRdで十分検証できます。IOS-XRはCLIが他系統と別物で、設定は2段階コミット型、インターフェース名は4階層（例 GigabitEthernet0/0/0/0）になる点が、IOSから来た人がつまずきやすいポイントです。以下で違いと特徴を詳しく見ていきます。

IOS・IOS-XE・IOS-XRの違い（比較表で整理）

3つのOSはすべてCisco製ですが、成り立ちも対象機器も別物です。最初に全体像を表で押さえます。

表のとおり、IOS-XEは「中身がIOSのままLinux上で動く」ため学習コストが低く、IOS-XRは「別物として作り直された」ため作法から覚え直す必要があります。以下、違いを3つの観点で掘り下げます。

アーキテクチャの違い：モノリシックか、プロセス分離か

classic IOSは全機能が単一の共有メモリ空間で動き、プロセス間のメモリ保護がありません。1つの不具合が全体に波及しやすい構造です。IOS-XEはLinuxカーネルの上にIOSd（従来IOS相当の一体型アプリ）を載せ、フォワーディング管理などをLinuxプロセスとして分離した中間的な設計です。IOS-XRは当初QNXマイクロカーネル、バージョン5.0以降はLinuxベースで、IOSdの機能を多数の独立プロセスに分割しています。ルーティングプロトコルやパケット転送、管理機能が別プロセスで動くため、特定機能がクラッシュしても他に影響しません。大規模バックボーンで止められないネットワークほど、この分離設計の価値が効きます。

対応機器・用途の違い：エンプラはXE、SPはXR

対象機器が違うため、実務では「どの機器を使うか」で自動的にOSが決まります。IOS-XEはCatalyst 9000スイッチ、ISR 1000/4000、ASR 1000、Catalyst 8000エッジなど、企業の支店・キャンパス・データセンターで広く動きます。IOS-XRはASR 9000、NCS 5500/5700、NCS 540/560、8000シリーズなど、ISPや大規模事業者のコア／集約ルーターが対象です。逆に言えば、企業LANや小規模拠点にIOS-XR機を入れるのは過剰投資で、ここはIOS-XEが正解です。IOS-XRを選ぶのは、数十万〜数百万のBGP経路を扱う、無停止のソフト更新（ISSU）が要る、といったキャリアグレードの要件があるときです。

CLI・設定の違い：別系統コマンドと2段階コミット

IOS-XEはIOSとCLIが共通なので、IOS経験者はほぼそのまま操作できます。一方IOS-XRはコマンド体系が別物で、設定は入力直後に反映されず、candidate（編集中）に積んでから「commit」で確定する2段階方式です。誤設定はcommit前に破棄でき、確定後もロールバックできます。インターフェース名も分散・マルチシャーシ構造を反映して4階層（rack/slot/module/port、例 GigabitEthernet0/0/0/0）になり、プロンプトもRP/0/RP0/CPU0のような表記になります。経路制御はroute-mapではなくRPL（Route Policy Language）で記述します。下はIOS-XRでインターフェースにIPを設定してコミットする最小例です。

RP/0/RP0/CPU0:router# configure
RP/0/RP0/CPU0:router(config)# interface GigabitEthernet0/0/0/0
RP/0/RP0/CPU0:router(config-if)# ipv4 address 192.0.2.1 255.255.255.0
RP/0/RP0/CPU0:router(config-if)# commit

IOSの感覚で「設定したのに反映されない」と戸惑う原因はこのcommit待ちにあります。最後にcommitする、を癖づけるのが移行時の第一歩です。

IOS-XRの主要機能：高可用性・スケーラビリティ・自動化

IOS-XRの設計目標は、大規模ネットワークを止めずに運用することです。代表的な機能を実務での効きどころとあわせて整理します。

無停止運用を支える高可用性とISSU

IOS-XRはプロセスの自動リカバリ、アクティブ/スタンバイのコントロールプレーン冗長化に加え、ISSU（In-Service Software Upgrade）でルーターを再起動せずにソフト更新できます。コア機を落とさずにセキュリティパッチを当てられるため、メンテナンス枠の確保が難しいSP網で価値が高い機能です。

大規模トラフィックを捌くスケーラビリティ

データプレーン（パケット転送）とコントロールプレーン（経路計算）を分離し、ASICへのハードウェアオフロードで負荷を分散します。数十万〜数百万のBGP経路、MPLSやSegment Routingを使ったトラフィックエンジニアリングを前提に設計されているため、経路数の増加に対してパフォーマンスが崩れにくい構造です。

NETCONF/YANG/gRPCによるプログラマビリティ

IOS-XRはNETCONF・RESTCONF・YANGモデル・gRPCをネイティブにサポートし、設定を構造化データ（XML/JSON）として一括適用・バージョン管理できます。ストリーミングテレメトリでミリ秒〜秒単位の状態をプッシュ送信でき、SNMPのポーリングより細かい監視が可能です。CLIの手作業に依存しないため、設定ミスの削減と変更履歴の追跡につながります。設定をコードとして管理する考え方は、サーバー側のTerraformを用いた効率的なインフラコードの管理とバージョン管理と同じ発想で、ネットワークにも広がっています。

IOS-XRの設定・運用の基本：RPL・VRF・自動化

IOS-XR特有の作法を押さえると運用がぐっと楽になります。経路ポリシーは前述のRPLで記述し、条件分岐や再利用可能なポリシー定義が書けます。マルチテナントやL3VPNで使うVRFは、ルーティングテーブルを論理的に分離して同一機器で複数の独立した経路空間を持たせる機能で、IOS-XRでもコア機の定番構成です。運用自動化はPythonスクリプトやAnsible、Terraformと組み合わせ、NETCONF経由で複数台へ一括適用するのが一般的です。telemetryで集めたデータはGrafanaやPrometheusで可視化でき、ログ基盤としてGrafana Lokiとは何か：Prometheus由来の設計でコスト効率に優れたログ基盤を徹底解説のような仕組みと組み合わせると、障害の予兆検知まで踏み込めます。

IOS-XRv／XRdで実機なしに検証する

IOS-XRの学習や検証で実機（ASR 9000など）を用意するのは現実的ではありません。そこで使うのが仮想ルーターのXRv9000（仮想マシン型）とXRd（コンテナ型）です。手元のサーバーやCisco Modeling Labs（CML）上でIOS-XRのCLIや2段階コミット、NETCONF自動化をそのまま試せます。資格学習や移行前の検証は、まず仮想版で作法に慣れてから実機に進むのが安全で安上がりです。アプリホスティング機能ではIOS-XR上でDockerコンテナを動かせるため、Kubernetesとは？初心者にもわかりやすく解説で扱うコンテナの基礎を押さえておくと、ネットワーク機器上でのアプリ運用も理解しやすくなります。

対応機器とソフトウェアの入手

IOS-XRが動く主な機器は、ASR 9000シリーズ、NCS 5500/5700、NCS 540/560、8000シリーズ、そして仮想のXRv9000/XRdです。ソフトウェアの基盤は64bit LinuxのXR7アーキテクチャで、リリース番号は2024年（24.1.1）から年ベースのX.Y.Z形式に変わりました。Xが西暦下2桁（24/25/26）、Yが四半期、Zが種別（1=フィーチャーリリース、2=拡張メンテナンスリリース）を表し、2026年は26.x系（26.1.1など）が出ています。旧来の7系（7.11など）はサポート終了が進んでいます。イメージの入手やアップグレードはCiscoのサポートサイトから行い、多くの機器でSmart Licensingによるライセンス管理が前提になります。対応プラットフォームやリリース番号は更新が速いため、導入前に必ずCisco公式のリリースノートとデータシートで使用機器に対応した最新版を確認してください。

IOS-XRに関するよくある質問

IOSとIOS-XEとIOS-XRの違いを一言で言うと？

classic IOSは一体型の従来OS、IOS-XEはそのIOSをLinux上に載せたエンプラ向けOS、IOS-XRはプロセス分離型に作り直したSP・大規模向けOSです。IOS-XEはIOSとCLIが共通で学習コストが低く、IOS-XRは別系統のCLIと2段階コミットを採用しています。対応機器も、IOS-XEはCatalyst 9000やISR、IOS-XRはASR 9000やNCSと分かれます。使う機器が決まればOSも自動的に決まると考えてよいでしょう。

IOS-XRはどの機器で動きますか？

ASR 9000シリーズ、NCS 5500/5700、NCS 540/560、8000シリーズなどのキャリアグレード機で動きます。加えて仮想ルーターのXRv9000（VM型）とXRd（コンテナ型）があり、検証や学習に使えます。企業の支店やキャンパス向けスイッチ・ルーターはIOS-XE機が対象で、IOS-XRは大規模コア／集約用途が中心です。

IOS-XRの最新バージョンは？

リリース番号は2024年から年ベースのX.Y.Z形式に移行しました。Xが西暦下2桁（24/25/26）、Yが四半期、Zが種別で、2026年は26.x系（26.1.1など）が出ています。以前の7系（7.7〜7.11など）から番号体系が変わり、基盤は64bit LinuxのXR7アーキテクチャが続いています。リリースと対応プラットフォームは頻繁に更新されるため、導入・検証時はCisco公式のリリースノートで使用機器に対応した最新版を確認してください。

IOS-XRのroute-policy（RPL）とは何ですか？

RPL（Route Policy Language）は、IOS-XRで経路の選択・加工を記述するための言語です。classic IOS/IOS-XEのroute-mapに相当しますが、条件分岐やポリシーの部品化・再利用ができ、大規模なBGP運用でも読みやすく保守しやすいのが特長です。BGPの経路フィルタリングや属性操作を、テンプレート的に管理したい場面で使います。

実機がなくてもIOS-XRを学べますか？

学べます。XRv9000やXRdといった仮想版を使えば、PCやサーバー、Cisco Modeling Labs（CML）上でIOS-XRのCLI操作、2段階コミット、NETCONF/YANGによる自動化を実機と同じ作法で練習できます。資格学習や移行前の検証は、まず仮想版で慣れてから実機に進むのが安全です。

関連記事

• Terraformを用いた効率的なインフラコードの管理とバージョン管理
• Kubernetesとは？初心者にもわかりやすく解説
• Grafana Lokiとは何か：Prometheus由来の設計でコスト効率に優れたログ基盤を徹底解説