Tutorial
MikroTik RouterOS 更新・パッチ適用ガイド
ISPフリート全体でMikroTik RouterOSを更新・パッチ適用する方法：リリースチャネル、段階的展開、バックアップ、ロールバック、2026年のCVE。
概要 ISPフリート全体でのMikroTik RouterOSの更新は、ワンクリックの操作ではなく、制御されたプロセスです。SLAに合ったリリースチャネルを選び、すべてのデバイスをバックアップし、パイロットで検証してから、明確なロールバック経路を備えたトポロジー対応の波で展開します。2026年にはこれがこれまで以上に重要です。公開された悪用可能なRouterOSの脆弱性（CVE-2026-7668）と新しいstableリリース（7.23.1）により、パッチ未適用のエッジルーターは現実的なリスクとなっています。
ISPフリートにおけるRouterOSパッチ適用とは？
RouterOSのパッチ適用とは、MikroTikデバイスの集団をあるRouterOSバージョンから新しいバージョンへ引き上げ、セキュリティ上の欠陥、安定性のバグ、動作のリグレッションを修正する、規律ある作業です。しかも、その上で動作するサービスを壊すことなく行います。1台の家庭用ルーターであれば2分で済む作業です。しかし数百から数千のCPEやエッジルーターにわたると、運用プログラムになります。リリースチャネルのポリシー、バックアップの標準、ステージングの手順、段階的な展開、ロールバック計画が必要です。目標は言葉にするのは簡単ですが、大規模に実現するのは難しいものです。すべてのデバイスが最終的にパッチ適用済みとなり、その過程でどれもダウンしないことです。
これがきちんとしたワークフローに値するのは、アップグレードが、失敗したときに再び容易には到達できない唯一のものに触れるからです。それは、多くの場合CGNATの背後にある、顧客側エッジのルーターです。管理アクセスを失う不適切な配信は、現地出動につながります。そのため、以下のワークフローはまず安全性と到達性を、次に速度を最適化します。
今パッチを当てる理由：2026年のセキュリティ状況
パッチ適用のペースは、脆弱性が問題を突きつけるまでは静かな背景作業のままですが、2026年にはそれを引き締める具体的な理由があります。CVE-2026-7668はRouterOSのSCEPエンドポイントにおける範囲外読み取りで、CVSS 7.3（高）と評価されています。リモートでトリガー可能で、公開された悪用コードが存在します。このサイクルの別の勧告では、VXLANのソースIP検証における不適切なアクセス制御の問題（RouterOS 7.20以降で修正）と、認証されていない攻撃者が細工したパケットでトリガーできるSMBサービスのメモリ破損の欠陥が取り上げられています。
MikroTikのガイダンスは一貫しています。RouterOSを最新に保ち、信頼できないネットワークをブロックするファイアウォールの背後に置くことです。現行のstableブランチであるRouterOS 7.23.1（2026年6月2日リリース）は、BGPのメモリリークとDHCPv4スヌーピングの安定性問題も修正しています。これが、フリートが場当たり的なアップグレードではなく、再現可能なパッチプロセスを必要とする通常の理由です。
ステップ1 — 適切なリリースチャネルを選ぶ
RouterOSには複数のブランチがあり、その選択は好みではなくポリシーの判断です。stableリリースは数か月ごとに、テスト済みの機能と修正を伴って出荷されます。long-termリリースは重要な修正とセキュリティ修正のみを受け取り、バージョン間の変化がはるかに少なくなります。予測可能性を重視するISPのエッジおよびCPEフリートにとって、long-termブランチが正しいデフォルトであることが多く、stableはそれを必要とするハードウェアや機能のために留保します。何を選ぶにせよ、本番環境でtestingやdevelopmentビルドを実行してはいけません。決定をチーム全体で再現可能にするため、デバイスクラスごとにブランチを文書化してください。
ステップ2 — まずバックアップしてエクスポートする
復旧ポイントなしにアップグレードしてはいけません。バイナリバックアップ（/system backup save）と人間が読める設定エクスポート（/export file=）の両方を作成してください。エクスポートはバージョン変更を乗り越えて残り、バイナリバックアップが別のビルドに復元できない場合でも再構築を可能にするからです。両方をデバイスから管理システムへ取り出してください。開始前に新しいパッケージのための空き容量が十分にあることを確認し、有線またはコンソール接続を優先してください。Wi-Fiや不安定なリンク経由でのアップグレードは、書き込みの途中でルーターが文鎮化する原因です。復旧アクセスが本当の懸念となるデバイスについては、アップグレードが失敗したときのフォールバックとして当社のNetinstall復旧ガイドがあります。
ステップ3 — パイロット機でテストする
まず代表的なルーター1台をアップグレードし、それを観察してください。本番クラスを反映するデバイス（同じモデル、同じ役割、似た設定）を選び、メンテナンスウィンドウ中に対象バージョンを適用します。再起動後はバージョンを確認し、パッケージが有効になっていることを確認し、設定に影響する動作の変化（ファイアウォールのセマンティクス、デフォルトサービス、インターフェース命名）についてチェンジログを確認します。パイロットがクリーンであることを確認できて初めて、より広範な展開を承認します。この1つのステップが、最も高くつく障害モードを防ぎます。それは、すでに1,000人の顧客に配信された後でリグレッションを発見することです。
ステップ4 — トポロジー対応の波で展開する
大規模展開は、どこでも一斉にボタンを押すことではなく、順序とペース配分の問題です。連鎖したルーターが順番に更新されるよう、デバイスをトポロジーごとにグループ化してください。下流のデバイスがパッケージを取得する前に、上流のルーターが再起動するのは避けたいところです。それぞれ独自のメンテナンスウィンドウを持つ波を定義し、各デバイスを調整リストで追跡して、問題のあるユニットが忘れられるのではなく再キューされるようにします。インターネット帯域幅を削減するには、デバイスをローカルのパッケージミラーとして機能する中央ルーターに向けます。これにより、フリートが取得できるバージョンも制御されます。
段階的展開は、各デバイスが復帰したことを確認するために実際にすべてのデバイスへ到達できる場合にのみ機能します。それがCGNATの背後にあるCPEの運用上の落とし穴であり、まさに集中管理が真価を発揮するところです。
ステップ5 — 検証し、必要ならロールバックする
各波の後で結果を確認してください。報告されたバージョンを確認し、該当する場合はrouterboardファームウェアもアップグレードされたことを確認し（/system routerboard upgrade）、重視するサービスがトラフィックを通していることを検証します。デバイスが異常な動作をする場合は、以前のバイナリバックアップを復元するか、RSCエクスポートから再構築するか、最後の手段としてNetinstallで以前のバージョンを再インストールします。パッチプログラムは新しいバージョンがインストールされた時点で「完了」ではありません。すべてのデバイスが健全であると検証され、すべての例外が完了まで追跡された時点で完了です。
フリート規模のパッチ適用のヒント
- アップグレードを予測可能にするため、単一の堅牢化されたベースラインを標準化してください。当社のWinboxセキュリティのベストプラクティスとdevice-modeセキュリティ運用ガイドは、ほとんどのアップグレード問題がたどり着くベースラインを定義します。
- アップグレードの前後で管理アクセスをVPNまたは信頼できるIPに制限し、半分パッチが当たったフリートが決して露出しないようにします。
- CGNATの背後でも管理プレーンを到達可能に保ち、検証とロールバックに現地訪問が不要になるようにします。
- インシデントを待つのではなく、MikroTikのセキュリティ勧告を計画的に確認してください。
よくある質問
RouterOSはどのくらいの頻度で更新すべきですか？ 各リリースをブランチポリシーに照らして評価し、公開しているサービスに勧告が影響する場合はその都度、計画外でパッチを当てます。固定の間隔はなく、リスクによって駆動されるペースがあるだけです。
ISPフリートにはstableとlong-termのどちらがよいですか？ エッジとCPEにはlong-termがより安全なデフォルトです。新しいハードウェアサポートや機能が必要な場合は、ステージングで検証したうえでstableを使用してください。
アップグレードがリモートデバイスを文鎮化したらどうしますか？ バックアップまたはRSCエクスポートから復元します。デバイスが到達不能な場合はNetinstallで復旧します。だからこそ、いかなる波の前にも、テスト済みのバックアップと到達可能な管理経路が必須なのです。
現地出動なしでフリート全体にパッチを当てる
フリートのパッチ適用で最も難しいのはアップグレードそのものではなく、その後にすべてのデバイス、特にCGNATの背後にあるCPEへ到達して検証することです。MKControllerはMikroTikフリート全体の可視性を集中化し、NATCloudはポートフォワーディングなしで内側から外側への到達性を提供するため、段階的展開、検証、ロールバックがすべてリモートで行えます。