16
10

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@k2_naka

自治体におけるインターネット分離10年の総括 —— 技術類型・運用の現実・ゼロトラストへの道

16
Last updated at Posted at 2026-07-26

筆者

役割 担当
課題提示 K⁺oji Na⁺kamura
原案作成 Claude Fable 5,GPT-5.6 Sol
出典確認支援・加筆 GPT-5.6 Sol
技術面のチェック K⁺oji Na⁺kamura

TL;DR

  • 2015年の日本年金機構事案を契機とする自治体の「三層の対策（三層分離）」は、制度化から約10年を迎えた
  • LGWAN接続系から安全にWebを閲覧する「インターネット分離」の実現方式は、実行場所 × 分離粒度 × 転送方式 の3軸で4類型に整理できる（本稿独自の便宜的整理）
  • 分離の成否を実運用で分けたのは方式そのものより、ファイル無害化との連携（脱PPAP後に増えたWeb経由のファイル受け渡しを含む）・県セキュリティクラウドのSSL復号・Web会議やクラウドサービスとの接続設計 という摩擦点だった
  • セキュリティ面では、LGWAN接続系にインターネットへの直接経路を原則持たせない構造が、直接通信型のC&Cや外部へのデータ送信を構造的に成立しにくくした。これは検知に依存しない防御として正当に評価できる。ただし「感染しても攻撃が成立しない」とまでは言えない
  • 政策は、複数端末とUSB受け渡しに依存した三層分離の解消と、ゼロトラストの考え方を取り入れた国・地方共通ネットワーク（2030年頃目途）へ段階的に向かっている。ガイドライン上はローカルブレイクアウトを制度化した「α'モデル」が2024年10月に正式追加され、実態を制度が追認する形が既に始まっている。2026年の検証結果は、移行が既存分離の全面撤去ではなく、機密性に応じて論理分離・境界防御を併用するハイブリッドで進む現実解も示した
  • 補講として、「分離をやめる」を先行させたGIGAスクール（教育）、「線の閉域」で並走した医療DX、そして分離の外側から迫るサプライチェーンリスク（イセトー事案・サイバー対処能力強化法）との比較から、次の10年の設計条件を考察する。補講2では「ファイルを運ぶ行政」から「APIが動かす行政」への転換（公共サービスメッシュ）で信頼境界がどこへ移るかを、補講3ではAIの進展・普及が攻撃・利用・防御にもたらす変化と「無害化」「分離」の概念拡張を考察する

本稿の方式分類（4類型）は、調達・運用上の違いを理解しやすくするための筆者の便宜的整理であり、公的または業界標準の分類ではない。実際の製品には複数類型の機能を併せ持つものがあり、相互排他的な分類ではない。また、本稿は2026年7月時点の公開資料に基づく。製品名は技術方式を説明するための代表例であり、特定製品の推奨や全機能の網羅ではない。仕様・ライセンス体系は変わるため、導入時には最新資料とPoCでの確認を勧める。

本稿の読み方

  • 第1章〜第6章が「インターネット分離10年」の本編です
  • 補講1は教育・医療・サプライチェーンとの比較です
  • 補講2は公共サービスメッシュとAPIの信頼境界を扱います
  • 補講3はAI時代の無害化・分離・権限管理を扱います

技術方式と運用上の論点だけを確認したい場合は、第1章〜第4章までで独立して読めます。

1. 前提：三層の対策とインターネット分離

2015年の日本年金機構の情報漏えい事案を受け、総務省の自治体情報セキュリティ対策検討チームは、同年11月24日に報告「新たな自治体情報セキュリティ対策の抜本的強化に向けて」を取りまとめた1。これを基礎に同年12月25日の総務大臣通知（総行情第77号）で対策の抜本的強化が示され、平成27年度補正予算での補助金創設を経て全国展開されたのが、庁内ネットワークを3つに分ける「三層の対策」である2。各自治体には、マイナンバー情報連携の開始に合わせた2017年7月までを目途とする対応が求められ、その後、全国で三層の対策と自治体情報セキュリティクラウドの実装が進められた。

あわせて、都道府県単位でインターネット出口を集約する「自治体情報セキュリティクラウド」が構築された。

ここで問題になるのが、LGWAN接続系の端末からどうやってWebを閲覧するかである。物理的に端末を分ければ実行環境と通信経路の境界は明瞭になるが、コストと利便性の犠牲が大きく、USB等のデータ移送経路は別途統制する必要がある。総務省はVDI・SBC・仮想ブラウザといった仮想化技術により、インターネット接続系側で実行したデスクトップやブラウザの表示結果だけをLGWAN接続系の端末へ転送する「論理分離」を示した3。当初はこの画面転送型の論理分離が中心だったが、その後、DOMミラーリング型のクラウドRBIや、端末内の隔離領域で実行する方式など、複数の実装へ発展していく。本稿ではこれらを総称して「インターネット分離」と呼ぶ。

2. 技術類型 —— 4つの方式

インターネット分離の実現方式は、製品カタログ上は「仮想ブラウザ」「セキュアブラウザ」等の呼称が入り乱れているが、次の3軸で整理すると見通しが良くなる。

軸 選択肢
分離実行環境の場所 庁内/DCのサーバー ／ パブリッククラウド ／ 端末内の隔離領域
分離の粒度 デスクトップ全体 ／ ブラウザのみ
端末への転送方式 画面（ピクセル・フレーム）転送 ／ 描画情報（DOM）転送 ／ 転送なし（端末内実行）

この3軸をたどると、代表的な製品は次のように4類型へ落ちる（①はDaaS形態ではパブリッククラウド上で実行される）。

類型① 仮想デスクトップ方式（VDI／DaaS）

代表製品: Citrix DaaS、Citrix Virtual Apps and Desktops、Omnissa Horizon（旧VMware Horizon）、Azure Virtual Desktop

インターネット接続系（またはパブリッククラウド上）にデスクトップOSごと仮想マシンとして構築し、LGWAN系端末には画面のみを転送する。ブラウザに限らずメーラーや各種アプリも分離環境側で実行できる。

  • 利点: 業務自由度が最も高い。導入実績・ノウハウの蓄積が厚く、既存シンクライアント基盤と統合しやすい
  • 欠点: 仮想マシンごとのライセンス費用と、Windows環境の二重管理（パッチ・アップデート）が恒常的な負担。派生形のSBC/RDS方式は集約性に優れる一方、RDS CALのコストとサーバー障害時の全ユーザー影響という別のトレードオフを持つ

製品名の変遷に注意。Citrix DaaSは旧「Citrix Virtual Apps and Desktops service」の現行名称であり、オンプレミス製品のCitrix Virtual Apps and Desktopsは現在も別製品として存在する。一方「Citrix Workspace app」は、これらの仮想アプリ・仮想デスクトップへ接続するクライアント（旧Citrix Receiverの後継）である4。また、VMware HorizonはBroadcomによるVMware買収後のEUC部門分離によりOmnissa Horizonとなった。過去の調達仕様書と現行製品名の突き合わせ時に混乱しやすい。

類型② サーバー型仮想ブラウザ方式（コンテナ＋画面転送）

代表製品: RevoWorks SCVX、SKYDIV Desktop Client（仮想ブラウザ方式）

デスクトップ全体ではなくブラウザだけをサーバー側で分離実行する。RevoWorks SCVXはLinux上のDockerコンテナでブラウザを実行し画面のみを転送する構成で、ブラウザ起動時にコンテナが生成され、終了時に破棄される。万一コンテナ内で感染しても、他のセッションやホスト環境への波及を抑え、セッション終了時に環境を破棄することで残存を防ぐ設計である。Linuxベースのため、VDI/RDS構成で大きなコスト要因となるRDS CALが不要という調達上の利点も大きい5。

  • 利点: ブラウザ用途に限定することでVDIより集約効率が高い。コンテナの都度生成・破棄による構造的な感染リセット。Windowsライセンス体系からの脱却
  • 欠点: ブラウザ以外の業務には使えない。画面転送である以上、メディア処理は分離環境側に集中する。サーバーのキャパシティ設計・障害対応の責任は導入側に残る

SKYDIV Desktop Clientは製品としてはVDI方式・SBC（RDS）方式・仮想ブラウザ方式の3方式を併せ持つスイート型であり6、「コンテナ化製品」と一括りにするのは不正確。類型①と②を跨ぐ製品と整理するのが妥当である。

類型③ クラウド型リモートブラウザ分離（RBI）

代表製品: Menlo Security、Ericom Shield

類型②と同じ「ブラウザの遠隔実行」だが、実行場所がベンダーのクラウド（SaaS）である点が異なる（Ericom等、オンプレミス提供形態を持つ製品もある）。転送方式は製品・設定により分かれるため、副分類しておく。

  • DOMミラーリング型: Menlo SecurityはAdaptive Clientless Renderingにより、クラウド上のブラウザで実行した結果を、ピクセルではなくDOMベースの無害化済みコンテンツとして端末側の既存ブラウザ（Chrome/Edge等）に描画させる7
  • ピクセル／フレーム転送型・ハイブリッド型: Ericom Shieldはポリシーに応じてFrame（画像フレーム転送）・Stream（メディアはストリーム）・Crystal（安全と判断したDOM等を転送）を使い分ける8。「描画情報転送型」と一括りにはできない
  • 利点: 端末側の普段のブラウザをそのまま使える操作性（ベンダーは「ローカル同等の体験」を訴求する7）。サーバー基盤の構築・保守・キャパシティ設計からの解放。無害化やSWG機能との統合が進んでいる
  • 欠点: 月額課金の継続コスト。LGWAN接続系からクラウドサービスへの経路設計が必要で、閉域前提の従来設計とは思想が異なる。海外SaaS依存に伴うデータガバナンスの説明責任

類型④ ローカルサンドボックス方式（端末内分離）

代表製品: RevoWorks Browser、Soliton SecureBrowser（+ Soliton SecureGateway）

分離実行環境を端末の中に作る方式。RevoWorks BrowserはローカルPC内にコンテナを生成し、コンテナがVPN経由でゲートウェイ・プロキシを通ってインターネットに接続する。ダウンロードファイルはコンテナ内に留め置かれ、無害化を経てローカルへ転送される9。Soliton SecureBrowserは端末内の隔離領域でブラウザを実行するため、ブラウザ実行用の大規模なVDI/SBC基盤を必要としない。ただし、認証・アクセス経路制御のためSoliton SecureGateway（物理/仮想アプライアンスまたはクラウドサービス）を組み合わせる構成となる10。

  • 利点: ブラウザ実行サーバーが不要でコスト構造が軽い。画面転送を介さないため動画等の操作性が良い。小規模団体に向く
  • 欠点: 分離境界が「ネットワーク間」ではなく「同一端末内の論理境界」になる。端末台数分の展開・パッチ管理も残る

脅威モデル上の評価として：端末内分離は、分離強度がサンドボックス実装とホストOSの健全性に依存する。サンドボックス脱出やホストOS脆弱性の影響を受け得る点は、ネットワークを跨いで実行環境を置く類型①〜③とは信頼境界の性質が異なる。ただしこれは一律の優劣ではなく、製品ごとの隔離実装、端末管理状態、EDR等の併用によって実効的なリスクは変わる。

類型比較表

① VDI/DaaS ② サーバー型仮想ブラウザ ③ クラウドRBI ④ ローカルサンドボックス
実行場所 庁内/DCまたはパブリッククラウド 庁内/DCサーバー（コンテナ） ベンダーのクラウド 端末内の隔離領域
分離粒度 デスクトップ全体 ブラウザのみ ブラウザのみ ブラウザのみ
転送方式 画面転送 画面転送 DOMミラーリング／フレーム転送／ハイブリッド 転送なし（端末内実行）
主な信頼境界 仮想化基盤・接続ブローカー・管理プレーン コンテナ/セッション・ホストOS・転送路 RBI事業者のクラウド・テナント分離・描画変換 ホストOS・隔離エンジン・端末管理
初期/運用コスト 高/高（Win+CAL） 中/中（CAL不要製品あり） 低/月額継続 低/中
操作性・動画 中 中（改善進む） 高 高
主な課題 二重管理・ライセンス ブラウザ限定・体感品質 クラウド依存・経路設計 端末内境界の評価・端末負荷

コスト・操作性の行は一般的傾向であり、同時接続数、ライセンス体系、端末性能、メディア最適化の有無等の構成によって変わる。

3. 運用の現実 —— 10年で顕在化した摩擦点

方式選定と同じかそれ以上に現場を悩ませてきたのが、分離環境と業務の接点で生じる摩擦である。本稿では、特に影響が大きかったと考えられる4点を取り上げる。

3.1 ファイル無害化との連携

インターネットから取得したファイルをLGWAN接続系に持ち込む経路には無害化が求められる。無害化の実装にはCDR（Content Disarm and Reconstruction：脅威となり得る要素を除去してファイルを再構築する方式）のほか、形式変換、マクロ除去、テキスト化・画像化、ウイルス検査との組み合わせ等があり、CDRはその代表的方式である。分離ソリューションとの連携パターンは4つに整理できる。

パターン 概要 典型例
(a) 分離ブラウザ組込み型 ダウンロードファイルをコンテナ内に留め置き、メニュー操作で無害化→ローカル転送 RevoWorks SCVX / Browser59
(b) ファイル授受システム中継型 分離環境とLGWAN系の間の中継システムがCDRエンジンを呼び出す 各ファイル授受製品 + 各エンジン11
(c) 分離ソリューション統合型 Web分離製品にファイル・メール無害化まで統合 Menlo、Ericom Shield
(d) メール無害化連携型 メールゲートウェイで添付ファイルを無害化処理 各メール製品 + 各エンジン11

代表的なCDRエンジンにはVotiro Disarmer、OPSWAT MetaDefender、国産製品（川口弘行合同会社 Sanitizer、プロット Fast Sanitizer等）がある11。導入規模については各社の公表値として、Votiroは「46都道府県・750以上の自治体」（2019年1月時点の販売元公表値）12、OPSWATは「日本の地方公共団体の70%超を保護」（2026年の自社公表）13がある。ただし両者は指標・時点・対象範囲が異なり相互排他でもないため、これらから市場順位を導くことはできない。※市場シェアを記載する場合はITR等の調査原典（調査対象・指標・年度）の確認が必要。

運用上の論点は3つある。第1に手数。中継型の典型手順は「インターネット接続系でダウンロード→無害化システムへアップロード→処理→LGWAN系側でダウンロード」という多段の手作業であり11、この動線自体が三層分離10年の業務効率低下を象徴している。

第2に暗号化ファイル。パスワード付き圧縮ファイルは、パスワードを取得して展開しない限りCDRエンジンが内部を検査・再構築できない。現在はパスワード入力や別画面展開を組み込んだ製品・連携方式もあるが14、通常ファイルより運用は複雑になる。第3に機能毀損。マクロ・埋込オブジェクトの除去により「無害化したらファイルが業務に使えなくなる」問題は、現場の定番の不満として残り続けている。

3.2 脱PPAPの副作用 —— 「Webから受け取り、LGWANへ持ち込む」手間の増幅

PPAPとは、パスワード付きZIPファイルをメールに添付し、そのパスワードを別メールで送る運用の通称である。ZIPとパスワードが同じメール経路を通るため盗聴対策としての効果が乏しく、暗号化された添付はメール配送経路上のウイルス検査・無害化を妨げる。3.1で見た「暗号化ファイルはCDRで処理できない」問題の、送信側の慣行としての現れがPPAPだと言ってよい。内閣府・内閣官房は2020年11月26日から自動暗号化ZIPファイルの送付を廃止し15、IPAも同年9月、パスワード付きZIPを悪用したEmotet攻撃が暗号化によってメール経路上の検知・検疫をすり抜けやすいと注意喚起していた16。したがって脱PPAPそのものは妥当なセキュリティ改善である。

問題は、その代替手段が三層分離下の受信者にどのような業務動線を生んだかである。脱PPAPの代替として広がったのは、送信者側でファイルをクラウドストレージやファイル転送サービスへ格納し、受信者にダウンロードURLをメールで通知する方式である。HENNGEの2023年調査では、PPAP代替策を導入済みとした110人のうち52.7%が「添付ファイルダウンロードサービス」を挙げ17（一事業者の調査であり市場全体の統計ではない）、同社利用者の集計でも、添付ファイル付きメールに占めるPPAPの割合は2021年10月の29.4%から2026年6月には6.2%へ低下している18。メール添付からWeb経由の受け渡しへ、という方向は明確である。

一般の企業ネットワークでは、この移行によって添付容量制限を避けられ、URLの失効・ダウンロード回数制限・受信者認証・操作ログといった制御を追加できる。ところが主たる業務端末をLGWAN接続系に置くαモデルでは、メール通知を受け取る場所と、実ファイルが置かれている場所が、異なる信頼領域に分かれる。

受信者の操作は、サービスによってさらに増える。メールアドレス認証、ワンタイムパスワード、短い有効期限、JavaScriptやCookieの要件と仮想ブラウザとの互換性、ダウンロード回数制限などが加わるためである。無害化後にマクロや埋め込みオブジェクトが失われれば、送信者へ原本や別形式での再送を依頼することもある。

受け渡し方式 受信側での安全化 αモデルで生じやすい操作
通常のメール添付 メールゲートウェイとCDRが自動連携できる場合がある 自動処理後の添付をLGWAN側で開く
PPAP 暗号化されたままでは検査・無害化できない パスワード取得、展開、再検査、手動搬入
ダウンロードURL・クラウド共有 実ファイルはメール経路を通らない 分離ブラウザで認証・取得し、授受基盤へ再登録、処理後にLGWAN側で再取得

ここで起きたのは、送信側のメールセキュリティ改善と、分離された受信側の業務効率低下という非対称である。それまで通常添付としてメールゲートウェイで自動無害化できたファイルまでWeb受け取りへ移ると、3.1の中継型5ステップの前段に「分離ブラウザでの認証・ダウンロード」が積み増され、手動の「インターネット側からLGWAN側への搬入」対象が全般的に増える。送信者にとっては添付がURLに置き換わっただけでも、受信自治体の職員にとってはファイル一つごとに信頼境界を越える作業が発生する。

解決の方向は、PPAPへ戻ることではなく、脱PPAPの受け取り経路と、無害化・系間転送を一体化することである。

  • 外部の送信者が自治体指定の受取ポータルへ直接アップロードし、ウイルス検査・CDR・承認・LGWAN側配信までを一連化する
  • メール連携型ダウンロードサービス、ファイル授受基盤、CDRをAPI等で連携し、職員による「ダウンロードして再アップロード」をなくす
  • 任意の外部サービスを個別に使わせるのではなく、受取経路・保存期間・認証方式・ログ・対応形式を標準化する
  • 調達評価に、製品機能だけでなく、1ファイル当たりの操作回数、待ち時間、期限切れ時の復旧、再送率、無害化による機能毀損率といった運用KPIを含める
  • α'モデル等で利用を認めるクラウドサービスには、テナント制御・端末統制・ダウンロード時検査を組み合わせ、低リスク情報まで一律に多段搬入させない

脱PPAPはメールの問題を改善した。しかし三層分離された自治体では、その改善が自動的に全体最適になるわけではない。「安全な送り方」だけでなく、「分離された相手が安全かつ少ない手数で受け取れるか」まで含めて設計しなければ、セキュリティ対策が別のセキュリティ運用負債を生む。

3.3 県セキュリティクラウドのSSL復号プロキシによる制限

都道府県セキュリティクラウドは市区町村のインターネット出口を集約し、プロキシでのSSL復号（SSLインスペクション）による通信内容検査を行う構成が一般的である。ここで生じる制限は構造的なものだ。

  1. 証明書ピンニングとの衝突: SSL復号は実質的に中間者構成であり、プロキシの代替証明書を端末に配布する前提となる。証明書ピンニングを行う通信は復号下で成立しない。Microsoft自身、Delivery Optimizationは証明書ピンニングを用いるためTLSインスペクション対象から外す必要があるとしている19
  2. クライアント証明書認証: TLS復号プロキシはクライアントの秘密鍵を持てないため、復号したままクライアント証明書認証を成立させることは原理的にできない。該当サイトは復号除外・パススルー等の個別対応が必要になる
  3. 処理負荷: 全県分のトラフィックを復号する負荷が遅延・帯域逼迫の原因になる
  4. 新プロトコル対応: QUIC/HTTP3は従来型の復号プロキシで扱いにくく、UDP/443を遮断してHTTP/2以下へフォールバックさせる運用が採られてきた。現在はHTTP/3を直接検査できる製品世代もあるため20、製品と検査方式の確認が必要である

制限と対策の対応を整理すると次のようになる。

制限 典型的な影響 実務上の対策
証明書ピンニングとの衝突 Web会議ネイティブクライアント・M365の一部通信の接続断や機能不全19 復号除外（デコードバイパス）リスト
クライアント証明書認証 該当サイトが復号下で利用不可 宛先ごとの除外・パススルー
復号処理負荷 全県分トラフィックの遅延・帯域逼迫 機器増強、ローカルブレイクアウト
QUIC／HTTP3 従来型プロキシで検査不能・挙動不安定 UDP/443遮断によるフォールバック、HTTP/3検査対応の製品世代へ更新20

対策の第一は復号除外（デコードバイパス）リストの整備で、ベンダーの設定ガイドでも宛先別にポリシーを分け、特定宛先のSSLインスペクションを無効化してセキュリティとパフォーマンスのバランスを取る構成が示されている21。ただし除外リストの管理は「検査しない通信」を増やす判断であり、セキュリティクラウドの監視前提（ログ収集・分析）との整合をどう説明するかが県側の悩みどころとなる。もう一段進んだ対策が次項のローカルブレイクアウトで、除外を「経路ごと変える」発想に転換したものと位置づけられる。

もうひとつ実務的に重要なのは、除外リストの管理様式である。除外は接続トラブルのたびに増える一方で、消す契機がない。単なる接続対応表としてではなく、エントリごとに 所有者・除外の根拠・期限・代替対策（ログ取得等） を持つ「セキュリティ例外台帳」として棚卸し可能に管理しなければ、可視化を増やすほど例外が静かに積み上がるという逆説に陥る。

コラム：PQC対応

なお、復号と証明書という論点の先には、もうひとつ「次の10年」の宿題がある。耐量子計算機暗号（PQC）への移行である。2026年7月の重点計画は電子署名等の活用とともにPQC移行に向けた取組を進めると明記し、同年6月にはG7サイバーセキュリティWGもPQC移行準備に関する共同声明を公表した22。自治体ネットワークには、VPN・TLS・SSL復号装置・クライアント証明書・LGWANや行政サービス間の認証・電子署名・HSMと認証局・SASE/SSE接続・長期稼働するアプライアンスと、公開鍵暗号があらゆる層に埋め込まれている。重要なのは直ちにPQC対応製品を買うことではなく、使用中の暗号方式と証明書を棚卸しし、システム全体を更改しなくてもアルゴリズムを交換できるクリプトアジリティを次期調達要件に含めることだ。NISTも、PQC移行を契機として、運用を止めずに暗号を入れ替えられる能力の整備を求めている23。

3.4 Web会議との相性問題とローカルブレイクアウト（LBO）

Web会議は三層分離＋県セキュリティクラウド構成にとって負荷特性の厳しいワークロードである。画面転送型のVDI/仮想ブラウザでは、メディア最適化を導入しない場合、映像・音声処理が分離環境側に集中し「受信メディアの再エンコード＋画面転送」という二重処理で遅延・品質低下が起きやすい。現在はTeams等の音声・映像処理を端末側へオフロードするVDI向けメディア最適化も普及しているが24、最適化は端末からメディアサービスへの直接通信を前提とするため、LGWAN系端末がインターネットへ直接出られない構成ではそのまま適用できない。適用するには端末からの直接経路を開けることになり、それは既に分離の部分的緩和である。経路面でも、Web会議・クラウドストレージ系のトラフィックは集約ゲートウェイやプロキシを圧迫して輻輳・遅延を引き起こす25。コロナ禍でのWeb会議・テレワークの一斉普及は、この弱点を広範に露呈させた。

そこで定着したのが、Web会議・Microsoft 365系だけは県セキュリティクラウドを経由させず拠点から直接抜く ローカルブレイクアウト（LBO） である。Microsoft自身がM365のネットワーク接続原則として、ユーザーに近い場所からローカルにインターネットへ出し、ヘアピン経路や不要なプロキシ・パケット検査を避けることを推奨しており26、自治体がLBOを正当化する根拠として引かれてきた。

実装面の論点は2つある。

  • プロキシ設定との競合: 端末にプロキシ設定がある限り、経路上にLBO設定を入れても通信はプロキシへ向かう。基本手段はPACファイルで該当SaaS宛先をプロキシ除外にする方法だが27、宛先IP/ドメインの頻繁な変更に追随する運用負荷が重い。PAC運用の限界を理由に、宛先リストを自動更新する専用アプライアンスやクラウドプロキシへ移行した自治体事例も出ている28
  • モデル論との関係: LBOはαモデルの境界を局所的に緩める行為であり、実際、2024年10月2日のガイドライン改定（令和6年10月版）で、LGWAN接続系端末からLBOにより特定のクラウドサービスを直接利用するネットワーク構成が「α'モデル」として正式に規定された29。α'にはαより高度なセキュリティ対策（対象サービスの限定、アクセス制御、端末対策、ログ、外部確認等）が求められ、ケース別の対策例が示されている。改定検討過程では、α'モデルの技術的対策を実施した場合と、既にガイドラインで認められていた自治体情報セキュリティクラウド側でのLBOとでリスク値に差がないとするリスクアセスメント結果も示された30。現場のLBO実態を制度が後追いで枠づけた、と読める経緯である（この評価は筆者の分析）

4. 10年の評価

4.1 達成 —— 検知に依存しない構造的防御

総務省の見直し関連資料では、三層の対策の効果として、自治体におけるマルウェア感染等のセキュリティインシデントの減少が整理されている31。

この達成の構造的な理由が、外部通信経路の遮断である。三層の対策は、LGWAN接続系からインターネットへの直接経路を原則として持たせないことで、

  • 直接通信型のC&C（攻撃者サーバへのビーコン・遠隔操作）
  • 外部へのデータ送信（exfiltration）

を大きく制約した。個々のマルウェアを検知する方式とは異なる、構造的な防御として評価できる。より正確に言えば「検知しない」防御ではなく、検知だけに依存しない予防・封じ込めであり、侵入をゼロにする代わりに、攻撃者が使える通信経路と実行環境を限定するものである。パターンマッチング型検知の限界が指摘され続けた10年間において、この価値は正当に認められるべきである。類型②のコンテナ揮発性——感染してもブラウザ終了でコンテナごと破棄される——は、この思想を分離環境の内部にまで適用したものと位置づけられる。

一方、「感染しても攻撃が成立しない」とまでは言えない。プロキシを利用するマルウェア、許可済みクラウドサービスの悪用、内部ネットワーク内での横展開、設定不備、USB等の別経路は別途考慮が必要である。また、ランサムウェアの暗号化処理は外部との鍵交換なしに実行できる場合がある。攻撃者の公開鍵を実行ファイルに埋め込み、C&C通信なしで各ファイルを暗号化するランサムウェアが実際に解析されており32、二重恐喝についてもデータ窃取と暗号化は別工程である33。したがって三層分離の効果は、感染や暗号化を全面的に防ぐことではなく、攻撃者との外部通信や情報持ち出しの経路を限定する点にある。

効果の及ぶ範囲を攻撃の類型別に整理すると次のようになる。

攻撃・工程 インターネット分離の効果 補足
直接通信型のC2・遠隔操作 ◯ 構造的に成立しにくい 出口対策として機能
外部へのデータ持ち出し ◯ 経路を大きく制約 許可済みクラウドサービスの悪用は残る
ランサムウェアの暗号化 ✕ 埋め込み鍵型は外部通信不要32 データ窃取と暗号化は別工程33
プロキシ対応マルウェア △ 限定的 監視・検知との併用が前提
USB・保守回線・委託先経由の侵入 ✕ 守備範囲外 補講B・Cで詳述
内部不正・内部横展開 ✕ 守備範囲外 ゼロトラスト・最小権限の領域

※なお「同時期の民間企業・医療機関の被害状況と比べて自治体本体ネットワークの被害が相対的に抑えられたか」は、因果を示す全国横断の公開統計を確認できておらず、本稿では検証課題として留保する。

4.2 代償 —— 利便性・運用手数・継続費用

一方で自治体は約10年間、次の代償を払い続けた。

  • 業務効率: 無害化の多段手作業、画面転送の体感、Web会議品質、URLひとつ開くにも分離環境を経由する動線
  • 運用負荷: VDI基盤・仮想ブラウザサーバーの構築運用、Windows環境の二重パッチ管理、PACファイルと復号除外リストのメンテナンス
  • 継続費用: 仮想化ライセンス・RDS CAL・無害化エンジンライセンス・セキュリティクラウド負担金の積み上げ。多くの団体で5年程度の更改周期ごとに再投資が発生する
  • クラウド適応の遅れ: クラウド・バイ・デフォルト原則やテレワークへの対応が、閉域前提のアーキテクチャと衝突し続けた

公平を期すための留保。4.1の防御効果は、(1) β/β'モデルで業務端末をインターネット接続系に置いた場合は前提が変わる、(2) 上記の通りすべての攻撃経路に効くわけではない、(3) 「守れた」ことの裏で適応コストを払い続けた——という限界とセットで評価する必要がある。

5. これから —— 三層の対策の見直しとゼロトラスト

政策の方向は、物理的な三層分離と複数端末・USB受け渡しへの依存を減らし、ゼロトラストの考え方を取り入れた国・地方共通のネットワークへ段階的に移行することである。ただしこれは、境界防御やネットワーク分離を一律に廃止することを意味しない。モデルの系譜と将来像の関係を先に図示する。

経緯を時系列で整理する。

  • 令和2年（2020年）: 総務省「自治体情報セキュリティ対策の見直しについて」公表。三層の基本枠組みを維持しつつ、インターネット接続系に業務端末・システムを配置するβモデル等を提示34。同年12月のガイドライン改定でゼロトラストの考え方を取り入れた三層の対策の見直しを実施2
  • 2024年5月: デジタル庁「国・地方ネットワークの将来像及び実現シナリオに関する検討会」報告書が、2030年頃の将来像として「行政サービスの柔軟・セキュア・安定的な提供」「国・地方のネットワーク基盤の共用化」「一人一台のPCで効率的に業務ができ、テレワーク等の柔軟な働き方が可能」の3点を提示35
  • 2024年5月31日: 河野デジタル大臣（当時）が会見で、三層の対策をやめ、ゼロトラストアーキテクチャの考え方を導入する方針に言及36。ただし力点は「一人複数台のPC」「USBでの受け渡し」を伴う三層分離の解消に置かれており、境界防御の全面撤廃を意味するものではない。検討会でもゼロトラストと境界型防御は必ずしも矛盾せず併用され得ると整理されている37
  • 2024年10月2日: ガイドライン改定（令和6年10月版）でα'モデルを正式追加29。以降、令和7年3月・令和8年3月27日にも改定が続き、サイバーセキュリティ基本方針の策定・公表義務化（2026年4月1日まで）等が盛り込まれた38
  • 2026年3月31日: 「令和7年度 国・地方ネットワークの将来像の実現に向けた検証事業」の最終報告書が公表。国側のガバメントソリューションサービス（GSS）を自治体が試用する GSS試用型検証（宮城県・福井県・山口県） と、自治体提案型検証（北海道、岐阜県坂祝町、福岡県北九州市、鹿児島県肝付町）の結果が示された35
  • 2026年7月21日: 新たな「デジタル社会の実現に向けた重点計画」が閣議決定。2026年度に国が主体的に整備するネットワーク基盤の共用化を含む技術的実現可能性を検証し、2027年度以降に運用体制・移行環境を順次整備する方針を明記。自治体へのゼロトラスト導入に向けたガイドライン改定、参照手順書案の作成、効率的な共同運用の検討も盛り込まれた22

先行事例としては、三重県がαモデルからβ'モデルへ変更し、コミュニケーションツールの外部クラウド化とゼロトラスト型のセキュリティ対策を追加した取り組みが知られる39。また現場では2025年頃から三層分離見直しの検討・相談が増えているとの実務家の報告がある40。α'・β'への移行は将来のゼロトラスト移行までの過渡期対応と捉え、次のステップを見据えた移行計画が必要という指摘もある41。

検証事業が示した効果と残った課題

2026年3月31日公表の最終報告書（概要）は、GSS試用型・自治体提案型の双方でゼロトラストの考え方を取り入れた環境を検証し、効果と課題の両方を具体的に示している35。

確認された主な効果 残った主な課題
一人一台のPCから、従来物理的に分けていた業務環境へアクセスできる 機微情報に対する情報漏えい防止機能（DLP）の検知精度
VDI接続・複数回ログイン・端末切替・ファイル転送の手間を削減できる ID管理・資産管理・ログ監視を回せる専門人材の確保
庁舎外や災害時の業務継続性を高められる 既存アプリ・オンプレミスシステム・専用端末の扱い
ID・端末・アクセスを一体的に管理しやすくなる 共用基盤と自治体の役割分担、障害時の切り分け
— ライセンス料・為替・物価上昇を含む継続費用

注目すべきは、検証が「分離の全面撤去」ではなかった点である。1台の端末から複数環境を利用しつつ、マイナンバー利用事務系・LGWAN接続系・インターネット接続系を論理的に分離する構成が確認され、北九州市等の検証ではゼロトラスト環境を構築しながらマイナンバー利用事務系に既存の境界型防御を残した35。移行期の実像は「境界型防御を捨ててゼロトラストへ全面置換」ではなく、ID・端末中心の制御を強めながら、情報資産の機密性に応じて論理分離・境界防御を併用するハイブリッドである。

境界装置が消えても、単一障害点は消えない —— 集中の可用性リスク

もうひとつ、検証結果から読み取るべきなのが可用性の論点である。従来の三層分離では、プロキシ・VDI・仮想ブラウザ・ファイル授受基盤が主な障害点だった。ゼロトラスト型の構成ではその一部が不要になる代わりに、IdPと多要素認証、端末管理と端末健全性判定、ポリシーエンジン、SSE/SASEやアクセスプロキシ、証明書・鍵管理、DNS、ログ・リスク判定基盤、そしてクラウド事業者の管理プレーンが、全業務に共通する依存先になる。最終報告書の概要でも、運用の一元化により自治体側で把握できる情報が限定され、障害原因の切り分けや復旧が複雑になる懸念と、共用基盤の運用主体と自治体の役割分担を明確化する必要性が示されている35。

つまり、ゼロトラストは単一障害点を消すのではなく、単一障害点の場所を変える。境界装置の障害が通信経路を止めた時代から、認証・端末判定・ポリシー配布の障害が複数業務を同時に止め得る時代への移行である。次期設計で明文化すべきは製品名ではなく、IdP・ポリシー基盤停止時にも継続すべき最低限の業務、緊急用アカウントと平時の封印・監査方法、通常の認証基盤から独立した管理経路、自治体側でも取得・保持するログと構成情報、国・共同運用主体・自治体・SaaS事業者の障害対応分担、SaaS停止・テナント誤設定・証明書期限切れ・ID同期不全を想定した訓練、そしてセキュリティ機能の稼働率ではなく業務単位のRTO/RPOと縮退運転の定義、といった設計事項である。NISTが2025年に正式化した実装ガイド（SP 1800-35）も、ゼロトラストを単一製品ではなく、ID・端末・SASE・マイクロセグメンテーション等を統合したシステムとして扱うことを前提にしている42。

「国・地方ネットワークの将来像の実現に向けた検証事業」は、補正予算を使って令和8年度も継続中

2030年は「完成期限」ではなく移行開始の目安

概要は段階的な進め方も示した。2026年度以降に追加分析と参照手順書案の作成、2027年度以降に将来像の具体化と環境整備、そして2030年度以降に将来像への移行を開始する、という道筋である35。この道筋は2026年7月21日閣議決定の重点計画で政府の年度計画に組み込まれ、「構想」から「2026年度の具体的な作業」へ一段進んだ22。2030年を「全国一斉の完成期限」と読むのではなく、制度・共用基盤・移行モデルを整えたうえで本格移行に入る目安と捉えるのが妥当だろう。裏を返せば、多くの団体にとって次の1〜2回の機器・ライセンス更改は、この移行期のただ中で設計することになる。

本稿の文脈で注視すべき論点を3つ挙げる。

  1. 参照実装としてのGSS: GSS試用型検証が3県で実施され最終報告まで出たことで、「国は共通基盤側でどう実装するか」が具体資料で読める段階に入った。将来像の「ネットワーク基盤の共用化」「一人一台PC」の実現形を占う一次資料として、概要から効果と課題は前節で整理したうえで、本体（自治体の詳細意見・各県プロジェクト資料を含む）の精読が今後の分析対象になる
  2. 分離基盤の埋没費用問題: 本稿で整理した分離基盤（VDI基盤・仮想ブラウザサーバー・無害化ライセンス）は継続費用型の資産である。ZTA方向への移行と各団体の更改サイクルの不整合は、「三層分離の埋没費用」を各団体に突きつける。標準化・ガバメントクラウド移行で見られた「期限先行・現場後追い」の構造が再演されないかが焦点となる（この評価は筆者の分析）
  3. 実態先行と制度追認: LBOという現場実態が先行し、2024年10月改定のα'モデルとして制度が後追いで枠づけた経緯は、次の段階——β'やゼロトラスト移行——でも同じ順序をたどる可能性を示唆する。モデルの正史と経路の実態の乖離・収斂は、各県セキュリティクラウド更改（第3期）の調達仕様書を突き合わせることで検証可能なはずだ（この評価は筆者の分析）

次期更改で問うべきこと

移行期の更改設計は、製品名称から構成を決める段階を終えた。少なくとも次の8つの問いを、調達仕様を書く前に明文化しておきたい（1〜6は検証事業と本稿の摩擦点の裏返し、7〜8は筆者の追加）。

  1. 守る情報資産は何か — マイナンバー、住民情報、内部文書、公開情報を同じ制御で扱う必要はない
  2. どこを信頼境界とするか — ネットワーク、ID、端末、アプリ、データ、管理プレーンのどこで制御するのかを図示する
  3. 攻撃のどの段階を止めたいか — 初期侵入、実行、権限昇格、横展開、C2、情報持ち出し、暗号化、復旧妨害を分けて対策を割り当てる（4.1の効果整理表はこの割り当ての出発点になる）
  4. 職員の1操作を何段階にするか — URL閲覧、ファイル受け渡し、Web会議、テレワークの操作回数と待ち時間をKPIにする（3.2の脱PPAP動線が典型例）
  5. 例外を誰が維持するか — PAC、復号除外、SaaS宛先、テナント制御、無害化対象外形式を、所有者・根拠・期限付きの例外台帳として自動更新・棚卸しできるか（3.3）
  6. 撤退・移行できるか — 複数年契約、データ持ち出し、設定移行、ログ保全、ライセンス終了時の代替策まで設計する
  7. 委託先まで信頼を設計できるか — 渡すデータの最小化、委託先・保守経路の監査可能性、再委託の把握を仕様に含める（補講C）
  8. 計測を維持できるか — 4のKPIや5の台帳は、更改時に一度作る文書ではなく月次で更新される生きた計測でなければ、次の10年もまた現場の体感と帳票が乖離する。国の政府情報システムでは2026年7月から統一指標による利用者満足度・利便性評価の導入が始まっており43、自治体ネットワークでも、セキュリティ機能の導入数ではなく、操作時間・待ち時間・再処理率・満足度を測り続ける仕組みが要る

この8問はいずれも、製品選定より前の要件定義の問いである。答えの用意がない項目こそ、次期更改のRFI・ベンダー対話の議題にすべきだろう。

デジタル庁、総務省で松竹梅の基本パターンは出してほしい

6. まとめ

インターネット分離の約10年は、検知に依存しない構造的防御が、直接通信型のC&Cや外部送信を制約するうえで確かな価値を持つ一方、利便性、運用手数、継続費用という負担を伴うことを示した。方式の違いだけでなく、無害化とファイル受け渡し（脱PPAP後のダウンロードURL動線を含む）、SSL復号と例外管理、Web会議やクラウドサービスとの接続をどう設計したかが、実際の使い勝手を大きく左右した。

今後は、従来の分離技術を一律に廃止するのではなく、その防御効果を引き継ぎながら、ゼロトラストの考え方、端末管理、ID中心のアクセス制御、クラウドへの直接接続を組み合わせた構成へ段階的に見直していくことになる。次の10年の設計では、セキュリティのために業務動線を過度に複雑化した、この10年の教訓を繰り返さないことが重要である。脱PPAPが示したように、ある層の安全化は、送り手・受け手・分離境界を通しで見なければ、別の層の運用負債に転化し得る。そして信頼境界はこの先、ネットワークとファイルから、API・サービスID・データ項目・イベント、そしてAIエージェントへ移っていく（補講2・3）。次の10年の問いは「分離するか、しないか」ではなく、 「どの信頼境界を、どの技術と運用で、どこまで自動化して守るか」 である。

補講1 —— 隣接領域との比較で見るインターネット分離

三層分離の設計思想を相対化するため、同じ約10年を別の解で走った2つの隣接領域（教育・医療）と、分離の「外側」から迫る新しいリスク（サプライチェーン）を比較する。

補講A GIGAスクール構想 —— 「分離をやめる」を先に実行した隣人

自治体の中には、行政系とは別にもうひとつの大きなネットワークがある。教育委員会・学校のネットワークだ。文部科学省「教育情報セキュリティポリシーに関するガイドライン」は2017年の策定時、校務系と学習系のネットワーク分離を軸としており、いわば三層分離の教育版だった。その後の改訂経緯が示唆的である。2019年改訂でGIGAスクール構想（1人1台端末）に対応し、2021年改訂でクラウド・バイ・デフォルト原則への対応と学習系・校務系のネットワーク分離原則の見直しを行い、2022年改訂ではゼロトラストモデルへの移行というトレンドを受けてアクセス制御による対策を推奨する内容へと転換した44。令和6年版では、次世代校務DXを見据え、ネットワーク分離を必要としない認証によるアクセス制御を前提とした目指すべき構成が明確化され45、2025年3月にもNext GIGAに対応する改訂が行われている46。

教育情報セキュリティポリシーガイドライン 主なポイント
2017年 策定 校務系・学習系のネットワーク分離が軸（三層分離の教育版）
2019年 改訂 GIGAスクール構想・1人1台端末への対応
2021年 改訂 クラウド・バイ・デフォルト原則への対応、学習系・校務系の分離原則の見直し
2022年 改訂 ゼロトラストのトレンドを受け、アクセス制御による対策を推奨
令和6年版 ネットワーク分離を必要としない認証によるアクセス制御前提の構成を明確化
2025年3月 改訂 Next GIGAへの対応

教育系が「分離解消」を先行できた背景には、児童生徒数百万台規模の端末にVDI型の分離を適用することの非現実性、クラウド前提の学習ツール（Google Workspace / Microsoft 365 Education）という所与、そして扱う情報の性質の違いがある。ただし「機密性が低いから可能だった」と片付けるのは正確ではない。校務系には成績・保健・家庭環境といった要配慮情報が含まれ、実際にネットワーク分離されていたはずの校務系での不正アクセスやランサムウェア被害も報道されている47。教育系の転換は、機密情報が存在しないからではなく、分離の代わりに多要素認証・端末統制・監視へ投資するというリスク受容の設計判断である。

行政系（三層の対策） 教育系（GIGA以降）
基本方針 ネットワーク分離の堅持 分離解消・アクセス制御へ転換
端末規模 職員数十〜数千台／団体 児童生徒1人1台（全国数百万台規模）
前提ツール 閉域・オンプレミス中心から出発 クラウドサービスが所与
守りの重心 経路（境界・出口） ID・端末・監視
主な機微情報 住民情報・マイナンバー 成績・保健・家庭環境等

考察：同じ自治体の中で、行政系は分離を堅持し、教育系は分離解消を先行させるという「自然実験」が約10年併走してきたことになる。行政系のゼロトラスト移行にとって、教育系は貴重な先行参照事例だが、その教訓は「分離をやめれば楽になる」ではなく「分離をやめることは、対策をやめることではなく対策を付け替えることであり、ID基盤・端末管理・監視という別の投資が立ち上がる」という点にある。行政系の移行コスト見積りは、教育系の実績から逆算できるはずだ。

補講B 医療DX（オンライン資格確認等）—— 「線の閉域」と「面の分離」

医療分野は、閉域網アプローチを行政と並走させてきたもうひとつの領域である。オンライン資格確認（2021年運用開始、2023年4月に原則義務化）は、医療機関と支払基金・国保中央会を結ぶ回線を、厚生労働省通知に基づき閉域IP網を利用したIP-VPN接続、ISDNダイヤルアップ、またはIPsec+IKEを組み合わせたインターネット接続に限定し、電子証明書による相手認証と暗号化で保護している48。電子処方箋など医療DXの後続施策も、このネットワーク基盤の上に拡張されている。医療機関側の規律は厚労省「医療情報システムの安全管理に関するガイドライン」第6.0版（令和5年5月）が担い、オンライン資格確認の義務化により多くの医療機関が外部と恒常的に接続されるようになったことを背景のひとつとして、境界型防御とゼロトラスト的な考え方の組み合わせ、閉域網にあるシステムにも侵入リスクがあるという前提を明示した49。

自治体と比較したときの構造的な違いは、統制の「面」と「線」にある。自治体の三層の対策は、庁内ネットワーク全体の構成（面）をモデルとガイドラインで規定し、セキュリティクラウドで出口まで集約した。医療は、国が規定するのは資格確認・レセプト請求という接続（線）の閉域性であり、院内ネットワークの面はガイドラインが考え方を示すものの、構成モデルを事実上強制する仕組みにはなっていない。

自治体（三層の対策） 医療（オンライン資格確認等）
統制の対象 庁内ネットワーク全体（面） 資格確認・請求の接続（線）
規定の手段 強靭性向上モデル＋ガイドライン 厚労省通知（回線種別）＋安全管理ガイドライン
出口の集約 都道府県セキュリティクラウド 支払基金・国保中央会の閉域網
組織内の構成 モデルで事実上規定 各機関の裁量（ガイドラインは考え方を提示）
実際に破られた箇所 委託先等の庁外（補講C） 保守用VPN・委託事業者という「横」

この差の帰結が、広く報じられた医療機関のランサムウェア事案である。徳島県の町立病院（2021年）、大阪の大規模公立病院（2022年）の事案は、いずれも閉域接続の「線」ではなく、その横——リモート保守用VPN装置の脆弱性や、給食委託事業者経由の接続——から侵入された（※詳細は各病院の公表した調査報告書を一次資料として参照されたい）。医療機関へのサイバー攻撃でVPN装置など外部接続機器の脆弱性が突かれる事例が多数報告されているという指摘は、ガイドライン6.0版の解説でも強調されている49。

考察：三層分離が批判されてきた「過剰な面の統制」は、裏返せば横穴の少なさでもあった。医療の教訓を行政側から読むなら、ゼロトラスト移行で「面の統制」を緩める際には、保守回線・委託事業者接続という横の経路の管理を先に固めなければ、医療の轍を踏むということになる。他方、医療DX側も電子カルテ情報共有サービス等のクラウド化が進むほど、閉域前提から認証・データ保護中心への移行圧力という、行政と同型の課題に直面しつつある。両者は10年遅れの相似形ではなく、同じ問題への異なる初期条件からの収斂として読める。

補講C サプライチェーンリスク対策強化 —— 分離の「外側」から来るリスク

最後に、インターネット分離がそもそも守備範囲としてこなかったリスクを見る。政策面では、令和6年10月のガイドライン改定が4本柱のひとつに業務委託先管理の強化を掲げた29。国全体でも、2025年5月に成立したサイバー対処能力強化法（正式名称「重要電子計算機に対する不正な行為による被害の防止に関する法律」、令和7年法律第42号。いわゆる能動的サイバー防御法）が2026年にかけて段階施行され、基幹インフラ事業者への資産届出・インシデント報告義務は、そのサプライチェーン企業・IT委託先にも間接的に及ぶ50。あわせて新たなサイバーセキュリティ戦略が2025年12月23日に閣議決定され51、経済産業省の3段階「セキュリティ対策評価制度（SCS評価制度）」は2026年3月27日に制度構築方針が確定して2026年度末頃の申請受付開始（★3・★4）を目指す段階に入り52、サプライチェーン全体の対策水準の底上げは検討から実装の局面へ移っている53。

施策・制度 時期 要点
ガイドライン改定（令和6年10月版） 2024年10月 4本柱の一つに業務委託先管理の強化29
サイバー対処能力強化法（令和7年法律第42号） 2025年5月成立・2026年段階施行 基幹インフラの資産届出・インシデント報告義務、IT委託先へも波及50
新サイバーセキュリティ戦略 2025年12月23日に閣議決定 脅威の防止・抑止、社会全体のレジリエンス向上等5351
セキュリティ対策評価制度（SCS評価制度） 2026年3月27日に制度構築方針を確定。★3・★4は2026年度末頃の申請受付開始予定、★5は継続検討。評価ガイドは2026年秋頃公表予定 3段階評価でサプライチェーン全体の対策水準を底上げ52
サイバーインフラ事業者ガイドライン 2026年3月31日に正式策定 ソフトウェアの開発・供給・運用事業者と顧客の責務、調達時の確認項目を整理54

この方針転換を自治体側で最も鮮烈に裏付けたのが、2024年5月のイセトー事案である。帳票印刷・発送等を受託する1社がランサムウェア攻撃（8Base）を受け55、最終的に約307万人分——うち行政機関等からの委託分だけで約56.6万人分——の個人情報が流出し、徳島県・豊田市をはじめ多数の自治体・金融機関に波及した56。三層分離も県セキュリティクラウドも、庁外へ渡したデータには一切及ばないことを、これ以上ない規模で示した事案だった。

インターネット分離の文脈で考慮すべき点は3つある。

  1. 分離基盤自体がサプライチェーンである: VDI基盤・仮想ブラウザサーバー・無害化アプライアンスと、それらのリモート保守回線は、三層の横に開いた「信頼済みの穴」である。境界装置・VPN装置の脆弱性悪用が主要な侵入経路になった傾向は医療分野で顕在化した通りで49、分離製品自体の脆弱性管理、保守経路の統制、SBOM等によるソフトウェア部品の把握が、分離の実効性の前提条件になった。2026年3月31日策定の「サイバーインフラ事業者に求められる役割等に関するガイドライン」は、分離製品・SASE・CDR・ID基盤などの供給者を、単なる委託先ではなくソフトウェアの開発・供給・運用責任を負う主体として評価する公的な物差しであり、次期調達の確認項目にそのまま使える54
  2. 集約点の集中リスク: 県セキュリティクラウド・LGWAN・ガバメントクラウド・共同利用ベンダーは、効率化と引き換えに攻撃価値と影響範囲を1点に集中させる。委託先1社の被害が数十団体に波及したイセトーの構図は、集約アーキテクチャの裏面そのものである
  3. 委託先は技術では分離できない: ゼロトラストは内部の暗黙の信頼を削る技術体系だが、委託先の人・環境・再委託は発注者の技術的統制の外にある。残るのは契約・監査・そしてデータ最小化（そもそも渡さない設計）であり、令和6年10月改定の委託先管理強化は、この認識の制度化と読める

コラム：ゼロトラスト移行の足元に残るUSB

2026年7月、三重県は庁内で保有するUSBメモリ10,757個を調査し、47個・37所属からマルウェアを検知したと公表した。内訳は、過去に保存したメールデータ由来が29個、外部端末での使用時の混入が18個で、いずれも活動しておらず、感染や被害は確認されていない。県は、使用数の削減、登録管理、私物USBの禁止、自動スキャン、外部から受け取ったUSBを検査する専用端末の設置を対策に掲げている57。

この事例の読みどころは「47個も見つかった」という煽りではない。直接のインターネット接続を制限しても、ファイルを物理的に運ぶ必要性は残ったこと。古いメールデータや外部端末経由で、休眠状態のマルウェアが媒体に蓄積していたこと。端末側の自動実行制御やリアルタイムスキャンで感染は防げても、媒体管理そのものは別の統制であること。そして、ゼロトラストへの移行とUSB等の物理搬送の解消は、自動的には同時に進まないこと——の4点である。

言い換えれば、 USBは、論理的に遮断されたネットワーク間を人が接続する「手動API」 である。ネットワーク上の信頼境界をID中心へ移しても、可搬媒体によるデータ移動が残る限り、その媒体・操作端末・操作者・搬入元の信頼を別途管理しなければならない。三重県は第5章でゼロトラスト型対策の先行事例として登場した県でもあり、先進的なネットワーク改革と従来型の媒体管理が同居するという、移行期の現実をよく示している。

考察：三層分離の10年は、LGWAN接続系からインターネットへ直接通信する主要な経路を大きく制約した。しかしその間に、攻撃対象は保守回線・委託先・製品脆弱性・可搬媒体といった「信頼済みの経路」へ移った。インターネット分離の後継設計に求められるのは、経路の分離をやめることではなく、分離の対象を経路から信頼へ拡張し（最小権限・監査可能性・データ最小化）、それを委託先まで延伸することである。本編で述べた「実態先行と制度追認」の力学がここでも働くなら、次に制度化されるのは委託先を含めた監査可能性の要件だろう。

補講2 —— 「ファイルを運ぶ行政」から「APIが動かす行政」へ：公共サービスメッシュ時代の信頼境界

本編が総括した10年は、端的に言えば「人がファイルをダウンロードし、無害化し、別のネットワークへ搬入する」時代だった。3.1の中継5ステップも、3.2の脱PPAP動線も、その変奏である。ところが2026年7月21日閣議決定の重点計画は、オンライン申請のデータを職員の人力を介さず業務システムへ連携し、出生・死亡等のライフイベントに関するデータを公共サービスメッシュ上で業務システム間に自動連携する方針を明記した。API等の連携方式を標準化し、2027年度以降早期の実装を目指す。さらに同計画は、Rules as Code、AIエージェントによる制度改正対応、AIエージェントが行政サービスを提案し手続を完結させる将来像まで描いている22。

これは、本稿の主題を次の段階へ進める変化である。

過去10年 次の10年
ファイルを人が運ぶ API・イベントがデータを運ぶ
職員が認証される アプリ・サービス・AIエージェントも認証される
ネットワーク境界を越える サービス間の信頼境界を越える
CDRでファイルを無害化する API入力・データ項目・処理命令を検証する
ファイル授受のログを残す API呼出し・イベント・判断根拠を追跡する
マクロやスクリプトが攻撃要素 過剰なデータ参照・権限逸脱・不正なイベントが攻撃要素

中心命題は一文で書ける。ファイル搬入が減っても、信頼境界越えがなくなるわけではない。信頼境界が、ネットワークとファイルから、API・サービスID・データ項目・イベントへ移るのである。

技術面の足場は既に整理されつつある。NISTはクラウドネイティブ環境のゼロトラストについて、IPアドレスやサブネットではなくアプリケーションとサービスのIDに基づく認証・認可が必要であり、APIゲートウェイ・サイドカープロキシ・SPIFFE等のサービスID基盤で制御すると整理した58。OWASPのAPI Security Top 10は、オブジェクト単位の認可不備に加え、オブジェクトの特定項目を過剰に返したり変更を許したりする 「オブジェクトプロパティレベルの認可不備」 を主要リスクとして挙げ、必要な項目だけを返すこと、スキーマに基づいて応答を検証すること、データ構造を最小限にすることを求めている59。

自治体側で問うべき論点は、たとえば次のようなものだ。APIを呼ぶサービスやAIエージェントの本人性をどう確認するか。ある住民データへのアクセス権があっても、全項目を返してよいのか。読取りと更新の権限をどう分けるか。同じ申請イベントが再送されたとき、給付や登録を二重実行しないか（冪等性）。改ざんされたイベントや不正な入力値をどう検出するか。複数システムを横断した処理を、後から誰が再現・監査できるか。そして、AIエージェントに照会だけでなく更新・通知・給付まで許可してよいか。

見方を変えれば、これらは本編の問いの同型である。CDRの後継はAPI入力とデータ項目の検証であり、ファイル授受ログの後継はAPI呼出しと判断根拠のトレースであり、受け取り経路と無害化の「一体化」（3.2）の後継はメッシュ上の認可・検証・監査の設計である。道具は替わるが、「信頼境界を明示し、最小化し、監視する」という課題は替わらない。

結論はこうなる。三層分離の時代には「どのネットワークから来たか」が信頼判断の中心だった。公共サービスメッシュの時代には、「どのサービスが、どの住民の、どのデータ項目を、どの根拠で、何のために処理しようとしているか」を、トランザクションごとに判断する必要がある。ゼロトラストの本格的な対象は職員端末だけではなく、サービスID・API・イベント、そして次の補講3で扱うAIエージェントである。なお、公共サービスメッシュのアーキテクチャ自体（調達仕様・要件定義の読解）は筆者の別連載で扱っているため、本補講は信頼境界の観点に絞った。

公共サービスメッシュはシステム間連携の限定的な利用で、本筋は、AIエージェントによる自動化だろう。こちらも信頼の問題解決が必要。

補講3 —— AI技術の進展・普及に伴うサイバー脅威への対応

本編で総括した10年は、AI以前の脅威モデルを前提に設計された10年だった。次の10年はそうはいかない。IPA「情報セキュリティ10大脅威 2026」では、初めて脅威候補となった 「AIの利用をめぐるサイバーリスク」が組織向けの3位に初選出 された。なお1位「ランサム攻撃による被害」・2位「サプライチェーンや委託先を狙った攻撃」は4年連続で不動であり60、補講Cで見た構図の固定化とあわせて、脅威の重心がどこにあるかを示している。ここでは攻撃側・自治体自身のAI利用・防御側の3断面と制度の足場を整理する。

（1）攻撃側の変化 —— 検知と教育を最速で陳腐化させる

IPAが挙げるAIリスクには、AIの悪用によるサイバー攻撃の容易化・手口の巧妙化が含まれる60。生成AIによる自然な日本語のフィッシング・BEC文面の量産、ディープフェイクによる役員・首長級のなりすまし、専門知識を前提としないマルウェア開発は、いずれも「将来の可能性」ではなく現在進行形の変化である。

本編の文脈で重要なのは、この変化が対策の減価速度を選別することだ。「日本語が不自然なメールは疑う」という職員教育のヒューリスティックは、生成AIによって真っ先に失効した。検知パターンと人の注意力に依存する対策ほど速く陳腐化する一方、通信経路と実行環境を限定する構造的対策（本編4.1）は、攻撃文面がどれほど自然になっても迂回のコストが変わらない。三層分離が採った「構造で守る」思想は、AI時代にむしろ再評価される。ただし2つの留保がある。第一に、ディープフェイク音声による電話詐欺のような「人間を経由する攻撃」はネットワーク統制の外にあり、口頭での二次確認など業務プロセス側の対策領域である。第二に、AIによる脆弱性探索・エクスプロイト作成の高速化は、境界装置・保守経路という補講B・Cの「横穴」が突かれるまでの時間を短縮する。

（2）自治体自身のAI利用が生む新しい攻撃面 —— 「無害化」の定義が拡張する

生成AIの業務利用は自治体でも標準装備になりつつあり、総務省は2025年12月改訂の「自治体におけるAI活用・導入ガイドブック」第4版で生成AI利用ガイドラインのひな形まで提供した61。利用が進むほど、守るべき対象にAIそのものが加わる。

OWASPのLLMアプリケーション向けTop 10では、プロンプトインジェクションが2023年の初版から2025年版まで首位を維持している62。とりわけ間接型——Webページ・PDF・メールに埋め込まれた指示をAI（RAG、エージェント、AI搭載ブラウザ）が読み込み、本来の目標を書き換えられる攻撃——は、エージェント向けのOWASPのAgenticリスク分類でも筆頭級（2026年版の呼称ではAgent Goal Hijack）に位置づけられ、ツールの悪用（Tool Misuse）、過剰な代理権限（Excessive Agency）、メモリ汚染（Memory Poisoning）と並ぶ公式のリスク類型として整理されている63。

ここに本編との決定的な接続がある。一般的なCDRが対象とするのはマクロやスクリプト等の能動的コンテンツであり、自然言語として記述されたプロンプトインジェクションは、通常その除去対象にならない。AIが読む文書・Webを介した攻撃に対しては、無害化の対象を「能動的コンテンツ」から「AIへの指示になり得る内容と、AIに与えた権限」へ拡張して考える必要がある。

対策の型は、実はインターネット分離が10年かけて磨いてきた発想の相似形である。AIの実行環境の隔離、ツール権限の最小化（最小エージェンシーの原則63）、AIに渡すコンテキストのデータ最小化、出力の検証と記録——いずれも「信頼境界を明示し、最小化し、監視する」という本編の主題そのものだ。RBIベンダーがAI搭載ブラウザを隔離対象に含め始めた動き7は、分離技術がAI時代の要素技術として再利用される兆候と読める。また、α'モデルで利用を認めるクラウドサービスに生成AIが入るなら、テナント制御・DLP・ログの設計は、第5章で見た検証事業の残課題（DLP検知精度）と直結する。

観点 従来（本編の10年） AI時代
攻撃メールの見分け方 不自然な日本語・定型文が手がかり 生成AIで自然・個別最適化され、手がかりが消失60
マルウェア開発 専門知識が前提 AI支援で敷居が低下60
無害化の対象 マクロ等の能動的コンテンツ ＋AIへの指示になり得るテキスト6263
分離の単位 人が見る画面・通信経路 ＋AIが読むコンテキストとAIの操作権限
職員教育の効き 一定の効果 ヒューリスティックが急速に陳腐化
防御側の運用 人手の監視・トリアージ AI支援による監視（人材不足の緩和策）

（3）防御側 —— 人材不足の緩和と、新たな依存

第5章の残課題に挙がった「専門人材」に対し、ログ監視・アラートのトリアージ・一次対応へのAI活用は現実的な緩和策であり、都道府県セキュリティクラウドの次期更改でも監視業務のAI活用は論点になるだろう（この見通しは筆者の分析）。ただし、ログやアラートを外部のAIサービスへ渡す構成は、それ自体が補講Cで見たサプライチェーン・データガバナンス問題の再演である。処理場所、学習への利用有無、保持期間、再委託の確認という「委託先管理」の問いが、AIベンダーに対してそのまま繰り返される。

（4）制度の足場

制度面の整備は急速に進んだ。AI法（人工知能関連技術の研究開発及び活用の推進に関する法律）が2025年6月に公布され同年9月に全面施行、政府のAI基本計画も2025年12月に閣議決定された61。行政の利活用側では、デジタル庁が2025年5月に「行政の進化と革新のための生成AIの調達・利活用に係るガイドライン」（DS-920）の初版を策定し、生成AI関連技術の進展・ユースケースの拡大・国内外の制度動向を踏まえて2026年6月12日に第2.0版へ改定した。各府省庁ではAI統括責任者（CAIO）を中心とした統制が進められている64。事業者側の共通規範としてはAI事業者ガイドライン（第1.2版、2026年3月）がある65。自治体は、総務省のひな形61を土台に自庁ルールへ「翻訳」する段階に入っている。

考察 —— 第9の問い

AIは検知の軍拡競争を加速させる。だからこそ、10年前に選ばれた「構造で守る」思想は古びない。ただし、守るべき構造の単位が、ネットワーク経路と実行環境から、AIに与えるコンテキストと権限へ広がる。第5章の「次期更改で問うべきこと」8問に、第9問を足しておきたい。

  1. AIをどう統制するか — AIをどこで使い、AIに何を読ませ、AIにどこまでの操作権限を与え、その入出力をどう記録・検証するか。無害化・分離・例外台帳・委託先管理という本編の道具立ては、そのままAI統制の設計原則に持ち越せる

分離の10年が残した最大の資産は、個々の製品ではなく、「信頼境界を明示し、最小化し、監視する」という設計の習慣かもしれない。

脚注（出典）

参考資料（脚注以外）

三層の対策・制度全般

分離方式の類型・比較

各製品（補足）

ファイル無害化

SSL復号・ローカルブレイクアウト（補足）

ゼロトラスト移行（補足）

  1. 総務省 自治体情報セキュリティ対策検討チーム（報告「新たな自治体情報セキュリティ対策の抜本的強化に向けて」2015年11月24日）: https://www.soumu.go.jp/main_sosiki/kenkyu/jichitaijyouhou_security/index.html ／ 報告書本文PDF: https://www.soumu.go.jp/main_content/000387560.pdf ↩

  2. 「地方公共団体における情報セキュリティポリシーに関するガイドライン」（令和6年10月2日改定版）冒頭の沿革記述（総行情第77号通知、令和2年12月改定等）: https://www.soumu.go.jp/main_content/000970479.pdf ／ 内閣府規制改革推進会議提出資料「『三層の対策』によるセキュリティ対策の強化について」: https://www8.cao.go.jp/kisei-kaikaku/kisei/meeting/wg/2210_05common/230420/common09_0202.pdf ↩ ↩2

  3. アシスト「総務省が提示する自治体情報セキュリティクラウドとインターネット分離に関するガイドライン」: https://www.ashisuto.co.jp/cm/insight/approaches/InternetSeparation_Guide.html ↩

  4. Citrix DaaS 公式ドキュメント: https://docs.citrix.com/en-us/citrix-daas/whats-new.html ↩

  5. RevoWorks SCVX（ジェイズ・コミュニケーション）: https://revoworks.jp/scvx/ ／ 両備システムズによる解説: https://service.ryobi.co.jp/infrastructure_platform/revowoks-scvx/ ↩ ↩2

  6. SKYDIV Desktop Client 仮想化方式（Sky）: https://www.skydiv.jp/virtual/ ↩

  7. Menlo Security「リモートブラウザ分離」: https://www.menlosecurity.com/ja-jp/what-is/remote-browser-isolation ／ 製品ページ: https://www.menlosecurity.com/ja-jp/product/remote-browser-isolation ↩ ↩2 ↩3

  8. Ericom Shield 管理者ドキュメント（Frame/Stream/Crystalのポリシー設定）: https://ericom-tec.ashisuto.co.jp/docs/esadmin/en/archivedversions/ericomshield1911/deploymentguide/Admin/policies.html ↩

  9. RevoWorks Browser（ジェイズ・コミュニケーション）: https://revoworks.jp/browser/ ／ NTTデータ中国による解説: https://www.nttdata-chugoku.co.jp/solution/internet_isolation/revoworks.html ↩ ↩2

  10. Soliton SecureBrowser / SecureGateway 製品ページ: https://www.soliton.co.jp/products/ssbssg/ ↩

  11. ジチタイワークス「業務効率を上げる無害化ソリューション」（中継型の手順・連携エンジン一覧）: https://jichitai.works/article/details/990 ↩ ↩2 ↩3 ↩4

  12. アズジェント「Votiro Disarmer」（46都道府県・750以上の自治体、2019年1月時点）: https://www.asgent.co.jp/products/apt/secure-data-sanitization.html ↩

  13. OPSWAT「OPSWAT Now Secures 70% of Japan's Local Governments」（2026年）: https://www.opswat.com/blog/opswat-now-secures-70-of-japans-local-governments ↩

  14. アズジェント プレスリリース（Votiro Disarmer パスワード付き圧縮ファイル対応、2019年）: https://www.asgent.co.jp/press/releases/2019/20190228-001389.html ↩

  15. 内閣府「平井内閣府特命担当大臣記者会見要旨（令和2年11月24日）」（内閣府・内閣官房における自動暗号化ZIPファイル送付の廃止）: https://www.cao.go.jp/minister/2009_t_hirai/kaiken/20201124kaiken.html ↩

  16. IPA「相談急増／パスワード付きZIPファイルを使った攻撃の例」（2020年9月2日、Emotetによる検知回避）: https://www.ipa.go.jp/security/emotet/situation/emotet-situation-04.html ↩

  17. HENNGE「『PPAP』代替手段に、52%の企業が添付ファイルダウンロードサービスを導入」（2023年2月27日）: https://hennge.com/jp/info/press/20230227_ppap/ ↩

  18. HENNGE「PPAP廃止が加速、利用比率は2年で約6%に半減」（2026年6月30日）: https://hennge.com/jp/info/press/20260630_ppaptrend/ ↩

  19. Microsoft Learn「Using a proxy with Delivery Optimization」（証明書ピンニングのためTLSインスペクション不可）: https://learn.microsoft.com/en-us/windows/deployment/do/delivery-optimization-proxy ↩ ↩2

  20. Fortinet「Inspecting HTTP3 traffic」（FortiOS 7.4）: https://docs.fortinet.com/document/fortigate/7.4.4/administration-guide/440398/inspecting-http3-traffic ↩ ↩2

  21. Fortinet「ローカルブレイクアウト設定ガイド 自治体情報システム強靭性向上モデル αモデル編」: https://www.fortinet.com/content/dam/fortinet/assets/deployment-guides/ja_jp/sdwan_deploy_guide_lbo_local_gov.pdf ↩

  22. デジタル庁「デジタル社会の実現に向けた重点計画」（令和8年7月21日閣議決定）: https://www.digital.go.jp/policies/priority-policy-program ／ 本文PDF: https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/5ecac8cc-50f1-4168-b989-2bcaabffe870/208168e8/20260721_policies_priority_outline_03.pdf ↩ ↩2 ↩3 ↩4

  23. NIST「NIST Publishes CSWP 39: Considerations for Achieving Crypto Agility」（2025年12月）: https://www.nist.gov/news-events/news/2025/12/nist-publishes-cswp-39-considerations-achieving-crypto-agility ↩

  24. Microsoft Learn「Microsoft Teams on Cloud PCs」（VDI環境でのTeamsメディア最適化）: https://learn.microsoft.com/en-us/windows-365/enterprise/teams-on-cloud-pc ／ 「Microsoft Teams for Virtualized Desktop Infrastructure」（AVD・Windows 365・Citrix・Omnissa・Amazon各環境の最適化対応）: https://learn.microsoft.com/en-us/microsoftteams/teams-client-vdi-requirements-deploy ↩

  25. IIJ「プロキシ環境でもローカルブレイクアウトはできる！」: https://ent.iij.ad.jp/articles/8970/ ↩

  26. Microsoft Learn「Microsoft 365 ネットワーク接続の原則」: https://learn.microsoft.com/en-us/previous-versions/microsoft-365/solutions/tenant-management-networking ↩

  27. IIJ プレスリリース（PACファイルによるプロキシ除外とLBO）: https://www.iij.ad.jp/news/pressrelease/2025/0303.html ↩

  28. A10ネットワークス「ローカルブレイクアウトソリューション」（四日市市のPAC運用脱却事例）: https://www.a10networks.co.jp/solutions/secure-services-cloud/localbreakout.html ↩

  29. ニュートン・コンサルティング「地方公共団体向けガイドライン改定（令和6年10月版）」（α'モデルの正式規定）: https://www.newton-consulting.co.jp/itilnavi/flash/202410_05.html ／ ガイドライン本文（令和6年10月2日改定版）: https://www.soumu.go.jp/main_content/000970479.pdf ／ 同（令和7年3月版）: https://www.soumu.go.jp/main_content/001001336.pdf ↩ ↩2 ↩3 ↩4

  30. 総務省自治行政局デジタル基盤推進室「地方公共団体情報セキュリティポリシーに関するガイドラインの改定方針」（令和6年7月、α'モデルLBOのリスクアセスメント）: https://sccs-jp.org/wp-content/uploads/2024/07/sccs28_horishima.pdf ↩

  31. 総務省「自治体情報セキュリティ対策の見直しについて」の公表（報道資料）: https://www.soumu.go.jp/menu_news/s-news/01gyosei07_02000098.html ／ マクニカ「【自治体】インターネット分離」（見直しポイント資料の引用）: https://www.macnica.co.jp/business/security/manufacturers/menlosecurity/municipality.html ↩

  32. Microsoft Security Blog「The Gentlemen ransomware: Dissecting a self-propagating Go encryptor」（2026年5月、埋め込み公開鍵による暗号化）: https://www.microsoft.com/en-us/security/blog/2026/05/28/the-gentlemen-ransomware-dissecting-a-self-propagating-go-encryptor/ ↩ ↩2

  33. CISA「#StopRansomware: Play Ransomware」（AA23-352A、窃取後に暗号化する流れ）: https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-352a ↩ ↩2

  34. 総務省 報道資料「『自治体情報セキュリティ対策の見直しについて』の公表」（βモデル提示等）: https://www.soumu.go.jp/menu_news/s-news/01gyosei07_02000098.html ↩

  35. デジタル庁「国・地方ネットワーク」（検討会報告書2024年5月の2030年頃将来像、令和7年度検証事業最終報告書2026年3月31日掲載）: https://www.digital.go.jp/policies/national-and-local-networks ／ 最終報告書【概要】PDF: https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/3fcb7ad0-50b3-4abe-b2ab-de16ab1488b3/f829a9a8/20260331_policies_national-and-local-networks_outline_01.pdf ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  36. デジタル庁「河野大臣記者会見（令和6年5月31日）」: https://www.digital.go.jp/speech/minister-240531-01 ↩

  37. デジタル庁「国・地方ネットワークの将来像及び実現シナリオに関する検討会（第5回）」: https://www.digital.go.jp/councils/local-goverments-network/17ac83b2-e3a7-4e7f-80e1-80726da32d51 ↩

  38. ALSOK「地方公共団体の情報セキュリティポリシー｜令和8年改定要点」（令和8年3月27日改定、基本方針策定・公表義務化）: https://www.digitalsales.alsok.co.jp/col_security-policy-guidelines ／ トレンドマイクロによる改定解説: https://www.trendmicro.com/ja_jp/jp-security/24/k/expertview-20241128-01.html ↩

  39. 三重県「三重県情報ネットワーク基本計画策定業務の企画提案コンペ」: https://www.pref.mie.lg.jp/NYUSATSU/m0364500007.htm ／ EnterpriseZine「三層分離モデルの弊害を"三重県らしいゼロトラスト"で解消へ」: https://enterprisezine.jp/article/detail/19102 ↩

  40. ITmedia「自治体DXを阻む『三層分離』の壁」（2026年4月）: https://www.itmedia.co.jp/business/articles/2604/22/news014.html ↩

  41. 日本総研「ゼロトラストへの移行を見据えた、自治体庁内ネットワーク見直しの必要性」: https://www.jri.co.jp/page.jsp?id=108726 ↩

  42. NIST SP 1800-35「Implementing a Zero Trust Architecture: High-Level Document」（2025年正式化、19種類の実装例）: https://csrc.nist.gov/pubs/sp/1800/35/final ↩

  43. デジタル庁「政府情報システムにおける利用者満足度評価の導入」（2026年7月23日公表）: https://www.digital.go.jp/policies/gov-system-user-satisfaction-evaluation ↩

  44. ユニアデックス「文部科学省の『教育情報セキュリティポリシーに関するガイドライン 改訂版』が示す教育DXの道筋となるセキュリティー対策」（2017年策定〜各改訂の経緯）: https://solution.uniadex.co.jp/column/annex/usefulinfo/education-dx.html ↩

  45. インテック「教育情報セキュリティポリシーに関するガイドラインの改訂ポイントとは？」（ネットワーク分離を必要としない認証によるアクセス制御を前提とした構成の明確化）: https://www.intec.co.jp/column/schoolcloud-02.html ↩

  46. サイバートラスト「2025年3月改訂！文科省『教育情報セキュリティポリシーに関するガイドライン』のポイント解説」: https://www.cybertrust.co.jp/blog/certificate-authority/client-authentication/educational-information-security-01.html ↩

  47. トレンドマイクロ「文科省『教育情報セキュリティポリシーに関するガイドライン（令和6年版）』を分かりやすく解説」（校務系での不正アクセス・ランサムウェア被害報道への言及）: https://www.trendmicro.com/ja_jp/jp-security/24/i/expertview-20240920-01.html ↩

  48. 社会保険診療報酬支払基金「セキュリティ」（厚生労働省通知に基づく回線種別：閉域IP-VPN／ISDN／IPsec+IKE）: https://www.ssk.or.jp/smph/goshitsumon/online/online_03.html ↩

  49. クライム「医療機関におけるサイバーセキュリティの羅針盤：厚生労働省『医療情報システム安全管理ガイドライン第6.0版』徹底解説」（VPN装置等の脆弱性悪用事例、オンライン資格確認義務化による恒常接続化）: https://www.climb.co.jp/blog_vmware/security-9016 ／ wiz LANSCOPE「医療システムの安全管理に関するガイドライン第6.0版を解説」（境界型防御とゼロトラスト思考の組み合わせ、閉域網でも侵入リスクありとする前提）: https://www.lanscope.jp/blogs/it_asset_management_emonpre_blog/20220524_24341/ ↩ ↩2 ↩3

  50. GMOインターネットグループ「サイバー対処能力強化法とは？」（令和7年法律第42号、2025年5月16日成立・23日公布、段階施行スケジュール）: https://group.gmo/security/security-all/information-security/blog/cyber-response-capability-enhancement-act/ ／ GSX「"つながる社会"を守る『能動的サイバー防御』」（2法構成、IT委託先への波及）: https://www.gsx.co.jp/securityknowledge/column/202509.html ↩ ↩2

  51. 国家サイバー統括室「主要公表資料」（新たなサイバーセキュリティ戦略・2025年12月23日閣議決定）: https://www.cyber.go.jp/policy/materials ↩ ↩2

  52. 経済産業省「『サプライチェーン強化に向けたセキュリティ対策評価制度に関する制度構築方針』（SCS評価制度の構築方針）を公表しました」（2026年3月27日）: https://www.meti.go.jp/press/2025/03/20260327001/20260327001.html ↩ ↩2

  53. 経団連タイムス「サイバーセキュリティ政策」（2025年10月30日号：新サイバーセキュリティ戦略の策定方針、経済産業省の3段階セキュリティ対策評価制度）: https://www.keidanren.or.jp/journal/times/2025/1030_09.html ↩ ↩2

  54. 経済産業省「『サイバーインフラ事業者に求められる役割等に関するガイドライン』の日本語版・英語版を策定しました」（2026年3月31日）: https://www.meti.go.jp/press/2025/03/20260331001/20260331001.html ↩ ↩2

  55. piyolog「イセトーのランサムウエア感染についてまとめてみた」（8Baseによる攻撃、影響組織の時系列、個人情報保護委員会の行政対応）: https://piyolog.hatenadiary.jp/entry/2024/06/15/011339 ／ イセトー「不正アクセスによる個人情報漏えいに関するお詫びとご報告」（フォレンジック調査完了報告）: https://www.iseto.co.jp/news/news_202410.html ↩

  56. セキュリティ対策Lab「イセトーのランサムウェアとサイバー攻撃による情報漏洩のまとめ」（最終集計3,076,477人、うち行政機関等委託分566,561人）: https://rocket-boys.co.jp/security-measures-lab/ransomware-cyberattacks-iseto/ ↩

  57. 三重県「県庁DX：USBメモリの庁内調査結果について」（2026年7月）: https://www.pref.mie.lg.jp/TOPICS/m0359600016.htm ↩

  58. NIST SP 800-207A「A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Cloud Environments」: https://csrc.nist.gov/pubs/sp/800/207/a/final ↩

  59. OWASP API Security Top 10「API3:2023 Broken Object Property Level Authorization」: https://owasp.org/API-Security/editions/2023/en/0xa3-broken-object-property-level-authorization/ ↩

  60. IPA プレス発表「情報セキュリティ10大脅威 2026」を決定（2026年1月29日、AIの利用をめぐるサイバーリスクが組織3位に初選出、1位ランサム・2位サプライチェーンは4年連続）: https://www.ipa.go.jp/pressrelease/2025/press20260129.html ／ 特設ページ: https://www.ipa.go.jp/security/10threats/10threats2026.html ↩ ↩2 ↩3 ↩4

  61. 総務省 報道資料「『自治体におけるAI活用・導入ガイドブック＜導入手順編＞（第4版）』の公表」（2025年12月16日。生成AIの利用方法・事例・留意事項を追加し、自治体が作成する生成AIシステム利用ガイドラインのひな形を別添収録）: https://www.soumu.go.jp/menu_news/s-news/01gyosei04_02000155.html ／ AI法（2025年6月公布・9月全面施行）およびAI基本計画（2025年12月閣議決定）を含む経緯の整理: https://aurant-technologies.com/blog/jichitai-seisei-ai-guideline/ ↩ ↩2 ↩3

  62. OWASP Top 10 for Large Language Model Applications（2025年版でもLLM01: プロンプトインジェクションが首位）: https://owasp.org/www-project-top-10-for-large-language-model-applications/ ／ 解説（間接型の位置づけ・2025年のインシデント動向）: https://introl.com/ja/blog/llm-security-prompt-injection-defense-production-guide-2025 ↩ ↩2

  63. OWASP GenAI Security Project（Agentic Security。2026年版のAgent Goal Hijack・Tool Misuse・Excessive Agency・Memory Poisoning等の公式リスク類型）: https://genai.owasp.org/ ／ 「OWASP GenAI Exploit Round-up Report Q1 2026」: https://genai.owasp.org/2026/04/14/owasp-genai-exploit-round-up-report-q1-2026/ ↩ ↩2 ↩3

  64. デジタル庁「『行政の進化と革新のための生成AIの調達·利活用に係るガイドライン（第2.0版）』を策定しました」（2026年6月12日決定）: https://www.digital.go.jp/news/decb64eb-f26e-41cb-8d37-f3dd173108b8 ／ 第2.0版本文PDF: https://www.digital.go.jp/assets/contents/node/information/field_ref_resources/decb64eb-f26e-41cb-8d37-f3dd173108b8/59054b35/20260612_resources_standard_guidelines_guideline_01.pdf ／ 初版策定（2025年5月27日、CAIO設置）: https://www.digital.go.jp/news/3579c42d-b11c-4756-b66e-3d3e35175623 ↩

  65. 総務省・経済産業省「AI事業者ガイドライン（第1.2版）」（令和8年3月31日）: https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/pdf/20260331_1.pdf ↩

16
10
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
16
10

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?