自治体のαモデルとβモデルの違い｜4分類と外部監査の義務

庁内の会議で「うちはαのままでいくのか」という話が出て、隣の席の人が黙ってしまった。そんな場面に心当たりはないでしょうか。

自治体のネットワーク構成には、α、α’、β、β’という4つのモデルがあります。ギリシャ文字とダッシュの組み合わせなので、正直、名前だけ聞いても何が違うのか分かりません。

しかも困ったことに、この4つは「2つの軸」で分かれています。αとα’を分ける基準と、βとβ’を分ける基準が、そもそも別物なのです。ここを知らないまま比較表を眺めても頭に入りません。

この記事では、総務省のガイドライン本体を読んで、4つの違いを2つの軸で整理します。そのうえで、ほとんどの解説記事が触れていない話をひとつ書きます。α以外を選ぶと外部監査がついてくる、という話です。

---

結論：4つは2本の軸で分かれている

先に答えを置きます。まず、主たる業務端末をどこに置くかで大きく2つに分かれます。

LGWAN接続系に置いたままにするか、インターネット接続系へ移すか。これがα系とβ系です。

そのうえで、それぞれにもう1本ずつ軸があります。

1. α系は、クラウドへの出口を持つかどうか
2. β系は、重要な情報資産まで一緒に動かすかどうか

この2本の軸が、そのまま4つのモデル名になっています。

モデル	主たる業務端末	重要な情報資産	クラウドへの出口
α（従来）	LGWAN接続系	LGWAN接続系	持たない
α’	LGWAN接続系	LGWAN接続系	LGWAN接続系から直接出る
β	インターネット接続系	LGWAN接続系	インターネット接続系
β’	インターネット接続系	インターネット接続系	インターネット接続系

表を縦に見ると分かります。αとα’は、端末も情報資産も動かしていません。変えたのは出口だけです。

一方でβとβ’は、業務端末をインターネット接続系へ移したうえで、重要な情報資産まで一緒に動かすかどうかで分かれます。

つまり、αとα’を分ける軸と、βとβ’を分ける軸は別物です。同じ「ダッシュ付き」でも、意味しているものが違います。ここが混乱の正体だと考えています。

αとα’の違い：端末は動かさず、出口だけ開ける

そもそも三層分離がなぜ生まれたのか、現場にどんな影響が出ているのかは別記事にまとめています。背景から知りたい方はこちらもどうぞ。

α’モデルについて、ガイドライン本体（令和8年3月版）はこう書いています。

主に外部のクラウドサービスの利用を目的として、LGWAN 接続系から接続先にローカルブレイクアウトする構成として、α’モデルが考えられる。

ローカルブレイクアウトというのは、途中の経路を通さず、そこから直接インターネットへ出ることです。

従来のαモデルでは、LGWAN接続系の端末からクラウドサービスを使えませんでした。使いたければインターネット接続系の端末に移動する必要があります。Web会議のたびに席を立つ、という話です。

α’は、その端末のまま外へ出る道を開けます。端末の置き場所は変わりません。ネットワークの構成を作り替える話ではなく、出口を1つ足す話です。

ただし、無条件ではありません。ここが重要です。

使えるクラウドサービスは限定されている

本体はこう定めています。

このため、本モデルにおいて利用可能なクラウドサービスは、ISMAP 管理基準を満たし、ISMAP クラウドサービスリストに登録されているサービスとする。

ISMAPは政府のクラウドサービス登録制度です。ここに載っていないサービスは、α’モデルでは使えません。

さらに、続けてこう注意しています。

なお、ISMAP に登録されたクラウドサービスを基盤として構築されたことをもって、その構築されたサービスを、ISMAP 登録サービスとして扱ってはならないことに留意する。

登録済みのクラウドの上に作られたサービスは、それ自体が登録されたわけではない、ということです。土台が登録されているから中身も大丈夫、とはならない。ここは読み飛ばしやすいところだと思います。

なお、個別のサービス名を挙げて「これは使える」と書くことは、この記事では避けます。ISMAPリストへの登録状況は変わりますし、上の注意書きのとおり判定も単純ではないためです。導入を検討する際は、その時点のリストで確認してください。

例外はセキュリティ関連サービス

ウイルス定義ファイルやIPアドレス、URLドメインリストの更新をインターネット経由で受け取るサービスについては、本体が例外を認めています。更新情報の配信ツールだから、という理由です。

ただし3つの条件が付きます。行政文書やそれに相当する情報を扱わないこと。接続先のURLを確認したうえで、その接続先のみに接続を制限すること。信頼できる機関が発行した証明書を用いた認証で、提供元の真正性が担保されていること。

3つ目については、本体が「この対策だけではなく、上記のURLを用いた接続先制限も併せて実施すること」と念を押しています。認証があるからURL制限は省いていい、とは読ませない書き方になっています。

利用範囲で3つのケースに分かれる

α’モデルは、クラウドをどこまで使うかによって、さらに3つのケースに分けて対策が示されています。

ケース	どこまで使うか
（ア）	ライセンスの認証・認可とウイルス定義体の取得のみ。専用テナントを持たず、Web会議やメールは使わない
（イ）	Web会議やメールを使う。ファイル共有もするが、LGWAN接続系へのダウンロードは制限する
（ウ）	（イ）に加えて、外部とファイルの送受信を行う

それぞれに必須の対策が図表で示されています。（ア）から（ウ）へ進むほど、外に開く範囲が広がり、求められる対策も増えていきます。

本体自身が、この3つで足りるとは言っていません。「利用するクラウドサービスは多様であり、すべてのケースを想定することは困難」としたうえで、団体ごとに個別に検討する必要があると書いています。

βとβ’の違い：重要な情報資産まで動かすか

こちらは業務端末をインターネット接続系へ移すモデルです。本体の定義を引きます。

・β モデル：インターネット接続系に主たる業務端末を置き、入札情報や職員の情報等重要な情報資産は LGWAN 接続系に配置する方式

・β’モデル：インターネット接続系に主たる業務端末と入札情報や職員の情報等重要な情報資産を配置する方式

読み比べると、違いは1か所だけです。βは重要な情報資産をLGWAN接続系に残します。β’は端末と一緒にインターネット接続系へ持っていきます。

β’で扱う「重要な情報資産」について、本体は自治体機密性3に該当する秘密情報に相当するものを想定していると注記しています。あわせて、職員のマイナンバー情報をインターネット接続系に配置する場合は、取扱いに十分留意しアクセス制御等を適正に実施する必要がある、とも書かれています。

つまりβ’は、かなり踏み込んだ構成だという位置づけです。

なお、これらのモデルを採用する場合、本体はエンドポイント側の対策を求めています。境界での防御だけではマルウェアの侵入を防ぐことが困難になっている、という認識が示されており、未知の不正プログラム対策の導入が有効だとされています。

ここが落とし穴

α以外を選ぶと、外部監査がついてくる

これが、この記事でいちばん書きたかったところです。

ガイドライン本体には、外部監査に関する条文が入っています。β・β’について、こう書かれています。

また、β モデル又は β’モデルを採用する場合は、従来モデル（α モデル）と比較してインターネットからのリスクが増加し、より高度なセキュリティ対策の確実な実施が必要になることから、インターネット接続系と LGWAN 接続系を完全に分離する場合を除き、その実施について事前に外部による確認を実施し、その確認の報告書を地方公共団体情報システム機構に提出することとする。また、その後も定期的に外部監査を実施することとし、その監査報告書を地方公共団体情報システム機構に提出することとする。

読むべき点が3つあります。事前に外部の確認を受けること。その報告書をJ-LIS（地方公共団体情報システム機構）へ提出すること。そして、その後も定期的に外部監査を受け、監査報告書を提出し続けること。

一度きりではありません。構成を変えるという判断は、継続的な監査を受け入れるという判断とセットになっています。

導入事例の記事では、まずここに触れられません。仕方がない面もあります。監査は売り物ではないからです。

β・β’とα’で、条文が微妙に違う

さらに細かい話をします。α’モデルにも、ほぼ同じ内容の条文が別に置かれています。

α’モデルを採用する場合は、従来モデル（α モデル）と比較してインターネットからのリスクが増加し、より高度なセキュリティ対策の確実な実施が必要になることから、その実施について事前に外部による確認を実施し、その確認の報告書を地方公共団体情報システム機構に提出することとする。

2つを並べると、差が1か所あります。β・β’の条文にある「インターネット接続系とLGWAN接続系を完全に分離する場合を除き」という除外が、α’の条文にはありません。

この差が何を意味するのかは、条文を読んだだけでは断定できません。除外の条件が、そもそもα’では成立しにくいからかもしれません。ここは解釈が要る部分なので、判断が必要な場面では所管に確認したほうが確実だと考えています。

書いておきたいのは、こういう差が存在することです。総務省が出している解説資料では、この部分が「β・β’モデルやα’モデルを採用する場合、外部監査を実施し、監査報告書をJ-LISへ提出する必要がある」と1文にまとめられています。要約としては正しいのですが、除外の有無は消えています。

「ローカルブレイクアウト」が2種類ある

用語の話をひとつ。ガイドライン本体には、ローカルブレイクアウトが2か所に出てきます。

ひとつは、自治体情報セキュリティクラウドからのローカルブレイクアウトです。こちらは都道府県と市区町村が協議して判断するもので、原則として都道府県側の設定で実施することとされています。

もうひとつが、α’モデルのローカルブレイクアウトです。LGWAN接続系から出ます。

同じ言葉ですが、出口の位置も、決める主体も違います。検索して出てくる解説では区別されていないことがあるので、資料を読むときは、どちらの話をしているのか確認したほうがいいです。

監査を受ける人の条件も書かれている

条文の末尾に、こう付いています。

なお、外部による事前確認や外部監査を行う者については、監査の対象となる情報資産に直接関与しない者であることが望ましい。

「望ましい」なので必須ではありません。ただ、構築や運用に関わった事業者が、そのまま監査もやるという形は想定されていない、と読めます。

筆者の立場からの考察

筆者は自治体の情報システム部門に常駐して運用側の仕事をしています。ネットワーク構成をどうするかを決める会議には出ていません。決まったものが降りてきて、それを動かす側です。

この立場からしか書けないことを2つ書きます。

制度が変わってから現場が動くまで、1年ほどある

筆者は常駐先で日次の作業報告を11年ぶん書いてきました。項目を数えると、制度の動きと現場の動きがずれているのが見えます。

クラウドのIDやSaaSに関する作業項目は、2024年度まで年に1件あるかどうかでした。それが2025年度に17件へ増えています。α’モデルがガイドラインに追加されたのは2024年10月です。制度が動いた年度には、現場の作業はまだ動いていません。

同じことが以前にも起きています。仮想端末に関する項目は2018年度までゼロで、2019年度に突然20件になりました。三層の対策が示された時期より、あとです。

理由は想像がつきます。制度ができても、予算を確保して、調達して、検証してからでないと動けません。年度をまたぐのは自然なことです。

ここから言えるのは、「制度上できるようになった」と「現場で使えるようになった」のあいだには、年度単位の距離があるということです。検討を始めるなら、その距離を見込んでおいたほうがいい。逆に言えば、いま検討していない団体は、その距離のぶんだけ後ろにずれます。

なお、これは筆者が関わっている1つの現場の記録にすぎません。作業報告に書いた項目の数であって、工数でもありません。自治体全体がこうだ、という話ではないことは断っておきます。

決める立場にないからこそ、気になること

正直に書きます。筆者は、モデルの選択がどういう議論を経て決まるのかを知りません。派遣で常駐している立場なので、意思決定の場に立ち会うことがないからです。

だからこそ気になるのが、外部監査という継続的な義務が、決めた人と運用する人のあいだで共有されているのかという点です。

構築の話は引き継がれます。設定も手順も、ドキュメントとして残ります。一方で「毎年、外部監査を受けて報告書を出す」という約束事は、構築のドキュメントには載りません。担当者が替わったときに、それが引き継がれる仕組みがあるのかどうか。

ここは筆者には見えない部分です。見えないので断定はできません。ただ、構成を決めるときに一緒に決めておくべきことがある、とは言えると思っています。

この4モデルの選択でいちばん重いのは、技術的な難易度ではないと感じています。選んだ後にずっと続く義務のほうです。構築は終わりますが、監査は終わりません。

確認したいこと	αのまま	α’	β・β’
業務端末の配置を変えるか	変えない	変えない	変える
使えるクラウドの制限	（そもそも使わない）	ISMAP登録サービスに限定	本体に同様の限定の記載は見当たらない
事前の外部確認とJ-LIS提出	不要	必要	必要（完全分離の場合を除く）
定期的な外部監査	不要	必要	必要（同上）
監査を回す体制の準備	不要	要	要

なお、外部監査を継続的に受けるとなると、当然その費用も要ります。自治体でのクラウド関連の予算の組み方については別記事で扱っています。

もうひとつ思うことがあります。α’は「小さく試せる選択肢」に見えますが、監査の義務はβ・β’と同じように発生します。しかも条文上、除外の記載は付いていません。手軽そうに見えて、入口の軽さと出口の重さが釣り合っていないのではないか、というのが正直な感想です。

この点は、実際にα’を導入した団体がどう回しているかを知りたいところです。事例として公表されているものは、導入した技術の話が中心で、監査体制の話までは出てきません。

判断の分かれ道

どのモデルがよいかを、この記事で決めることはできません。団体の規模も体制も違うためです。ただ、判断の軸は整理できます。

αのままでいく場合。監査の義務は発生しません。一方で、クラウドを使う場面ではインターネット接続系の端末に移る運用が続きます。この不便を、職員の手間として受け入れられるかどうかが分かれ目です。

α’を選ぶ場合。端末の配置を変えずに済みます。ネットワークの作り替えが要らないぶん、構築の負担は軽い。ただし使えるサービスがISMAP登録品に限られ、外部監査は発生します。Web会議を庁内から使いたい、というのが動機なら合っています。

β・β’を選ぶ場合。業務端末をインターネット接続系へ移すので、影響範囲が最も大きくなります。そのぶん利便性は上がり、エンドポイント側の対策が必須になります。β’まで行くと重要な情報資産も移すことになるため、本体も慎重な書き方をしています。

いずれにしても、「クラウドを使うにはβへ行くしかない」という理解は正確ではありません。LGWAN接続系を動かさずにクラウドを使う道は、α’として制度上用意されています。ここを知らないまま検討を始めると、必要以上に大きな話になります。

まとめ

• 4モデルは、まず業務端末の場所でα系とβ系に分かれ、そのうえで別々の軸でもう一段分かれる
• αとα’の違いは出口の有無。端末も情報資産も動かさない
• βとβ’の違いは、重要な情報資産を端末と一緒に動かすかどうか
• α’で使えるクラウドはISMAP登録サービスに限られる。土台が登録済みでも中身は別扱い
• α以外を選ぶと、事前の外部確認とJ-LISへの報告書提出、その後の定期的な外部監査が発生する（β・β’は完全分離の場合を除く）
• β・β’の条文には「完全に分離する場合を除き」という除外があるが、α’の条文にはない
• 「クラウドを使うにはβしかない」は正確ではない。α’という道がある

構成の選択は、技術の選択であると同時に、監査を受け続ける体制の選択でもあります。そこまで含めて比べたほうがいい、というのがこの記事の主張です。

引っかかった点

条文を読んでいて、いちばん時間を使ったのが外部監査の条項が2か所に分かれていることでした。β・β’の説明箇所と、α’の説明箇所に、ほぼ同じ文章が別々に置かれています。片方だけを読むと、もう片方の存在に気づきません。

解説資料のほうは1文にまとめてくれているので分かりやすいのですが、まとめた結果として除外の有無が消えていました。要約から入ると速いけれど、差が落ちる。当たり前のことですが、実際に踏むと効きます。

もうひとつ。「αモデル」という語が本体に単独で定義されていない点も、最初は戸惑いました。本体では「従来モデル（αモデル）」という形で、β・β’やα’を説明する際の比較対象として出てきます。αという名前が先にあったわけではなく、後から付いた呼び方なのだと理解しています。

参考にした一次資料

• 地方公共団体における情報セキュリティポリシーに関するガイドライン（総務省） — 本記事は令和8年3月版（令和8年3月27日改定）を参照しています。年度ごとに改定されるため、必ず一覧ページから最新版を開いてください。
• 同ガイドラインの解説資料（令和8年度・自治行政局住民制度課サイバーセキュリティ対策室）
• ISMAPクラウドサービスリスト — α’モデルで利用可能なサービスの確認先

引用した条文はいずれも令和8年3月版の本文から取っています。この記事を読んだ時点で版が更新されている可能性があります。