レッスン8：移行ロードマップ——3 年計画と、経営への説明

このレッスンで学ぶこと

パイロットとなる業務システムを選ぶ基準を理解する
並行運用期に発生する二重コストを見積もる発想を持つ
段階移行の典型的な順序と、その根拠を理解する
成熟度の推移を根拠に、経営へ投資対効果を説明する方法を身につける
ゼロトラスト・ウォッシュを見分け、よくある失敗パターンを回避する
修了後の学習の進め方を把握する

前回のレッスンでは、5 つの柱を束ねる横断的機能——継続的検証、可視化と分析、自動化とオーケストレーション、ガバナンス——を扱いました。これで、本コースが扱う設計の要素はすべて出そろいました。最終レッスンとなる今回は、ここまで学んできた要素を、実際に組織を動かすための移行ロードマップとして統合します。中核メッセージの 6 番目、「経営に説明できない移行計画は、2 年目の予算で必ず削られる」を、具体的な形にする回です。

ここまでの要素を統合する

レッスン 1 から 7 まで、次のような要素を積み上げてきました。

NIST SP 800-207 の 7 原則という、目指すべき設計思想（レッスン 1）
CISA ゼロトラスト成熟度モデルという、現在地を測る物差し（レッスン 2）
アイデンティティ・デバイス・ネットワーク・アプリケーションとワークロード・データという、5 つの柱ごとの設計（レッスン 3〜6）
継続的検証・可視化と分析・自動化とオーケストレーション・ガバナンスという、柱を束ねる横断的機能（レッスン 7）

移行ロードマップとは、これらの要素を、「いつ」「どの順序で」「どこまで」進めるかという、時間軸を持った計画に落とし込む作業です。技術的な設計が正しくても、時間軸の設計を誤ると、計画は途中で止まります。本レッスンでは、この時間軸の設計に焦点を当てます。

パイロット業務システムの選び方

移行の最初の一歩は、全社の全システムを一斉に対象にするのではなく、特定の業務システムを選んでパイロットとして進めるのが、現実的な進め方です。パイロットの選び方は、その後の計画全体の成否を左右します。

パイロットに適した業務システムには、いくつかの共通する特徴があります。

業務への影響範囲が限定されている：仮に想定外の問題が起きても、全社の業務が止まるほどの影響を持たないシステムであること
業務オーナーが明確である：パイロットの成果を評価し、次の判断につなげてくれる責任者が、はっきりしているシステムであること
技術的な複雑さが極端でない：レッスン 5 で触れたような、古い認証方式に依存する複雑なシステムをいきなり選ぶと、パイロットの段階でつまずきやすくなります
複数の柱にまたがる学びが得られる：アイデンティティとデバイスの両方の柱にかかわる業務システムを選ぶと、パイロットから得られる知見が、次のシステムへの展開にも活かしやすくなります

💡 ポイント パイロットの目的は、「完璧な成功事例を作ること」ではありません。むしろ、限定された範囲で失敗や想定外の事態を経験し、そこから学びを得て、次の展開に活かすことにこそ価値があります。失敗を許容できる規模のシステムを選ぶという視点が、パイロット選定の核心です。

パイロットの評価では、「問題が起きなかったかどうか」だけでなく、「何が想定外だったか」を、次の展開のために言語化しておくことが重要です。レッスン 2 の講師の現場メモで見た「古い生産管理システムが最新の認証方式に対応していなかった」という事実も、パイロットの段階で見つかっていれば、計画への影響はずっと小さく済んだはずです。パイロットは、成功を証明する場ではなく、計画の前提を検証する場だと捉え直すと、選び方や評価のしかたが変わってきます。

並行運用期の二重コスト

移行の途中では、古い仕組みと新しい仕組みが同時に稼働する期間が、避けられません。レッスン 5 の講師の現場メモで触れたとおり、一部の業務システムのために VPN を残しながら、ほかのシステムでは ZTNA を運用する、というような状態です。この期間を、並行運用期と呼びます。

並行運用期には、二重のコストが発生します。旧来の仕組みの運用・保守にかかる費用と、新しい仕組みの導入・運用にかかる費用が、同時に発生するためです。さらに、運用担当者は、2 つの仕組みの両方を理解し、使い分ける必要があるため、人的な負担も増えます。この二重コストは、移行計画を検討する初期の段階で見落とされがちです。

移行計画を立てる際には、「新しい仕組みの導入費用」だけでなく、「並行運用期にどれだけの追加コストが発生し、それが何年続く見込みか」を、あらかじめ見積もっておくことが重要です。並行運用期を短くしようとして急ぎすぎれば、レッスン 3 で見た「ポリシーを厳しくしすぎて業務が止まる」というつまずきを招きます。逆に、並行運用期を漫然と長引かせれば、二重コストがかさみ続け、経営からの信頼を損ないます。並行運用期には、あらかじめ終了の目安となる時期を定めておくことが、実務上の勘所です。

📝 補足 並行運用期の二重コストは、決して失敗の証拠ではありません。境界防御からゼロトラストへの移行という、大きな設計思想の転換には、一定の移行期間が構造的に必要です。問題になるのは、二重コストの存在そのものではなく、それが見積もられておらず、経営への説明に反映されていない状態です。

段階移行の順序——アイデンティティ→デバイス→ネットワーク

レッスン 2 で確認したとおり、柱ごとの成熟度は、業務のリスクに応じて優先順位をつけるべきものであり、すべての組織に当てはまる唯一の正解はありません。とはいえ、多くの組織で共通して見られる、典型的な段階移行の順序があります。

アイデンティティ：レッスン 3 で見たとおり、ほかの柱の判断材料を組み立てる土台になるため、最初に着手されることが多い
デバイス：レッスン 4 で見たとおり、アイデンティティの柱の判断に、端末の状態というシグナルを加えることで、条件付きアクセスの精度が上がる
ネットワーク：レッスン 5 で見たとおり、アイデンティティとデバイスの判断材料が十分に揃って初めて、VPN からの出口を安全に設計できる

この順序が典型的である理由は、それぞれの柱が、前の柱の成果を土台にして精度を高めていく構造にあるからです。デバイスの柱が未成熟な段階でネットワークの柱だけを先に進めようとすると、レッスン 5 で見たとおり、判断材料が乏しいままアクセス制御の粒度だけを細かくすることになり、無理が生じやすくなります。

一方で、アプリケーションとデータの柱は、この順序の中に固定的に位置づけられるものではありません。データの機密度が特に高い業種や、規制上の要求が強い業界では、アイデンティティの柱と並行して、データの柱に早い段階で着手する判断もありえます。典型的な順序は出発点であり、自社の業種や業務リスクに応じて調整すべきものだという点を、レッスン 2 の「柱ごとに成熟度が違ってよい」という中核メッセージとあわせて思い出してください。

flowchart LR
  P1[アイデンティティ] --> P2[デバイス]
  P2 --> P3[ネットワーク]
  P3 --> P4[アプリケーションと<br/>データ]

成熟度の推移で経営に説明する

移行計画を経営に説明する際、最も効果的なのは、レッスン 2 で紹介した成熟度モデルの採点結果を、時系列で示すことです。「今年はアイデンティティの柱が伝統的から初期に進んだ」「来年はデバイスの柱に着手し、初期段階を目指す」という形で、柱ごとの推移を具体的に示せると、抽象的な技術用語を並べるよりも、はるかに伝わりやすくなります。

時期	アイデンティティ	デバイス	ネットワーク	データ
移行開始時	伝統的	伝統的	伝統的	伝統的
1 年目終了時	初期	伝統的	伝統的	伝統的
2 年目終了時	高度	初期	初期	伝統的
3 年目終了時	高度	高度	初期	初期

このような表を使えば、「何にいくら使ったか」という支出の説明だけでなく、「その結果、組織のどの部分が、どれだけ強くなったか」を、成熟度という共通言語で示せます。レッスン 2 の講師の現場メモで触れたとおり、1 年目の目に見える成果が、2 年目の計画見直しへの理解を得る土台になった、という経験は、この説明のしかたと直結しています。

投資対効果の語り方

ゼロトラストへの投資対効果を語る際、「導入すればコストが下がる」という単純な説明は避けるべきです。むしろ、次のような複数の観点を組み合わせて説明する方が、実態に即しています。

リスクの低減：侵害が発生した場合の被害範囲を、ラテラルムーブメントの抑制によって縮小できること
業務の柔軟性の向上：テレワークや取引先とのシステム連携など、境界防御では対応しにくかった働き方に、より安全に対応できるようになること
運用の効率化：例外だらけのポリシーや、台帳と実態が乖離した資産管理といった、地道な整理を通じて、長期的には運用の手間が減っていくこと

これらの効果は、いずれも短期間で数字として示せるものばかりではありません。だからこそ、成熟度の推移という、数値化しやすい指標をあわせて示すことが、説明の説得力を補強します。「リスクが下がった」という定性的な説明だけでなく、「柱がどこまで進んだか」という定量的な進捗を、セットで語ることが実務上の工夫です。

⚠️ 注意 投資対効果を、インシデントが起きなかったことの金額換算だけで語ろうとすると、説明に無理が生じます。何も起きなかったことの価値を金額で示すのは本質的に難しく、経営からも「本当にその金額の効果があったのか」と疑問視されがちです。成熟度の推移という、起きたことを直接示せる指標を軸にする方が、説明として安定します。

ゼロトラスト・ウォッシュ

移行の過程で警戒すべき現象に、ゼロトラスト・ウォッシュがあります。これは、ゼロトラストに関連する製品を導入したという事実だけをもって、「自社はゼロトラストに対応した」と説明してしまう状態を指します。

レッスン 1 で確認した誤解の 1 番目、「製品を買えば実現する」を思い出してください。ゼロトラスト・ウォッシュは、この誤解が、組織的な説明の場面にまで及んだ状態だと言えます。製品を導入したという事実は、成熟度モデル上のどこかの柱が、わずかに前進するきっかけにはなりますが、それだけで柱全体の成熟度が上がるわけではありません。

ゼロトラスト・ウォッシュに陥っているかどうかは、次のような問いで見分けられます。

導入した製品によって、実際のアクセス条件付きポリシーが、どう変わったかを説明できるか
導入前と導入後で、成熟度モデル上の柱の評価が、具体的にどう変化したかを示せるか
導入後も、レッスン 3 で見たような例外の積み重ねが起きていないか、定期的に確認できているか

これらの問いに答えられないまま、「ゼロトラスト対応製品を導入した」という事実だけを対外的な説明に使っている状態が、ゼロトラスト・ウォッシュです。取引先や監査からセキュリティ体制の説明を求められる場面では、この違いが厳しく問われることになります。

よくある失敗パターン

ここまでのレッスンで触れてきたつまずきを、移行計画全体の視点で整理し直すと、いくつかの典型的な失敗パターンが見えてきます。

すべての柱を同時に進めようとする：レッスン 2 で見たとおり、柱ごとの成熟度が違ってよいという前提を無視すると、予算と人員の両面で計画が破綻します
VPN の廃止を唯一のゴールに据える：レッスン 5 で見たとおり、VPN を止めることが目的化すると、廃止できなかったことが失敗に見えてしまい、計画全体の評価を歪めます
経営への説明を後回しにする：中核メッセージの 6 番目が示すとおり、技術的に正しい計画でも、経営に説明できなければ、2 年目以降の予算で削られます
ガバナンスを整備しないまま進める：レッスン 7 で見たとおり、例外管理や見直しの仕組みがないまま柱の成熟度だけを上げても、時間の経過とともに実態と乖離していきます
計画の見直しを想定しない：レッスン 2 の講師の現場メモで見たとおり、3 年計画を固定的に捉えると、想定外の事実が見つかったときに、経営との信頼関係を損ないやすくなります

これらの失敗パターンに共通するのは、いずれも技術的な設計の誤りというより、計画の進め方や説明のしかたに起因する点です。ゼロトラストへの移行は、技術の話であると同時に、組織運営の話でもあるということが、本コースを通じて繰り返し確認してきた視点です。

ロードマップに含めるべき要素のチェックリスト

ここまでの内容を、実際にロードマップの文書としてまとめる際に、確認しておきたい要素を一覧にしておきます。

現在地：レッスン 2 の方法で採点した、柱ごとの成熟度
優先順位：どの柱から着手するか、その根拠となる業務リスクの説明
パイロット：最初に対象とする業務システムと、選定の理由
並行運用期の見積もり：二重コストがどの程度、いつまで発生する見込みか
段階ごとの目標：各年度の終わりに、どの柱がどの成熟度に到達している想定か
ガバナンス：例外管理の運用ルールと、見直しの周期
説明の準備：成熟度の推移をどう可視化し、誰に、どのタイミングで報告するか

この一覧は、レッスン 1 から 7 までの内容を、時間軸に沿って並べ直したものです。技術的な設計そのものは、5 つの柱ごとのレッスンですでに学び終えています。ロードマップという文書の役割は、その設計を、いつ・誰が・どう進めるかという、実行可能な計画に変換することにあります。

修了後の学習方向

本コースは、ゼロトラストを測り、設計し、動かすための全体像を、8 レッスンでお伝えしてきました。ここから先、さらに専門的に学びを深めたい方には、公的機関が公開している一次資料にあたることをお勧めします。

NIST は、SP 800-207 で示した原則を、実際にどう実装するかを扱った、より実務的な文書として、SP 1800-35「Implementing a Zero Trust Architecture」を公開しています。複数のベンダーと連携した実証実験にもとづく実装ガイドであり、本コースで学んだ 5 つの柱の設計を、より具体的な構成例とともに掘り下げたい方に適しています。CISA が公開しているゼロトラスト成熟度モデルの原文にも、レッスン 2 で扱った内容をさらに詳しく確認できる、段階ごとの評価の考え方が記載されています。

これらの一次資料は、英語で書かれていますが、ゼロトラストの実務に継続的に関わる立場であれば、いずれ向き合うことになる文書です。本コースで得た全体像を地図として持ちながら、必要な箇所から少しずつ読み進めていくことをお勧めします。

また、本コースでは深く扱わなかった、攻撃者の具体的な手口や、インシデント対応の詳細な手順については、情報セキュリティ関連の入門コースが引き続き役立ちます。ゼロトラストの設計と、インシデントが実際に起きたときの対応は、別々に学びながらも、互いに補い合う知識です。ゼロトラストが「侵害の被害を構造的に抑える設計」であるのに対し、インシデント対応は「それでも起きてしまった侵害に、どう向き合うか」を扱う領域であり、両方を押さえておくことで、組織のセキュリティ体制はより厚みを持ちます。

コースのまとめ

8 つのレッスンを通じて、本コースが伝えたかったことを、最後にもう一度確認します。

ゼロトラストは製品ではなく、5 つの柱ごとに進む成熟度の階段である
「信頼しない」ではなく「毎回確かめる」。確かめる材料をどう集めるかが設計の中身である
柱ごとに成熟度が違ってよい。全部を同時に上げようとすると必ず止まる
VPN を止めることが目的ではない。止められる状態を作ることが目的である
アクセスを判断する材料は、認証だけでなく端末の状態にもある
経営に説明できない移行計画は、2 年目の予算で必ず削られる

この 6 つの中核メッセージは、レッスン 1 で提示し、以降のすべてのレッスンで、さまざまな角度から確認してきたものです。ゼロトラストへの移行に、決まった終着点はありません。5 つの柱を、自社の業務リスクに合わせて、着実に、しかし焦らずに育てていく。その歩みを支える地図として、本コースをお使いいただければ幸いです。

私自身、3 年計画の見直しや、VPN を止めきれなかった経験を、本コースの中で率直にお伝えしてきました。計画どおりに進まないことは、失敗ではありません。柱ごとの現在地を正しく認識し、なぜ計画を見直すのかを説明できる状態を保ち続けることこそが、移行を最後まで動かし続ける力になります。皆さんの組織にとっての現在地から、無理のない一歩を、今日から積み重ねていってください。

確認クイズ

このレッスンの理解度をチェックしましょう。