公共SaaSに乗り出すために、事業者が知っておくべきこと
はじめに：「日本の公共システムをイケてるシステムにしたい」
株式会社アンチパターンの信田健児です。普段は民間企業のSaaS開発支援をすることが多いですが、今回は、公共SaaSについてです。デジタル庁のイベント記事などもみながら、僕なりの解釈で書いてみたいと思います。
デジタル庁ガバメントクラウドチームは、2023年11月の日本オラクル主催セミナーで、ガバメントクラウド移行の狙いをこう語っています。
日本の公共システムを「イケてるシステム」にしたい※1
この言葉に、私たち株式会社アンチパターンは強く共感しています。
デジタル庁が推進する「公共SaaS」は、単なるクラウド移行の話ではありません。日本の公共ITが「所有」から「シェア」へと構造転換し、規模の大小を問わず全国の地方公共団体、国の政府機関、準公共団体、独立行政法人、などの公共組織がモダンな技術の恩恵を受けられる社会を目指す ── そういう大きな意志を持った取り組みだと、私たちは受け止めています。
その変革に参加できるのは、もはや大手SIerだけではありません。デジタル庁が運営するデジタルマーケットプレイス（DMP）には、2025年7月時点で、すでに300を超えるソフトウェアが掲載されており、登録事業者の約8割を中小・スタートアップが占めています。※2モダンな技術とSaaSのノウハウを持つ事業者にこそ、大きな機会が広がっています。
本記事では、公共SaaSへの参入を検討するソフトウェア事業者向けに、「何が必要か」「民間SaaSとどう違うのか」を制度・ビジネス・技術の3軸で整理します。
公共SaaSとは何か — ガバメントクラウドとDMPの位置関係
公共SaaSの定義
デジタル庁が公開しているGCASガイド「ガバメントクラウドにおけるSaaS（公共SaaS）について」（2025年4月公表）によれば、公共SaaSは次のように整理されています（要旨）。
- 利用環境：ガバメントクラウドを利用環境とするSaaS
- 対象領域：重点計画に記載の公共・準公共分野※4、および制度官庁等が標準仕様を定める情報システム（後述するように、近年は対象が拡張されつつあります）
- 運営主体：①府省庁（国営）、②民間事業者（民営）の双方を想定
- 提供範囲：業務システム相当に加え、特定機能（粒度の大きいマイクロサービス）を共通サービスとして提供することも対象
平たく言えば、国の機関・地方公共団体等がガバメントクラウド上で共同利用できるよう設計されたSaaSです。
従来の自治体システム調達との違い
従来の行政システムは、各自治体がベンダーと個別に契約し、要件定義からスクラッチ開発・運用まで丸抱えする構造でした。この「個別発注・個別開発」モデルは、法改正のたびに莫大な改修費が発生し、ベンダーロックインを生み、システムの陳腐化を加速させてきました。
公共SaaSはこの構造を根本から変えます。
- 共通インフラ＝ガバメントクラウド
- その上で複数の事業者が公共SaaSを提供
- 国の機関・地方公共団体等はDMP（デジタルマーケットプレイス）で比較・調達
「個別開発・個別保有」から「共通基盤上の共同利用」へ、という構造転換です。
ガバメントクラウド／公共SaaS／DMPの三者関係
混同されがちですが、3つは異なる役割を担っています。
ここで重要なのは、DMPは行政機関が利用しうるSaaSを集めるカタログとして運用されており、デジタル庁は製品品質の高度な審査は行わず、資格要件・情報の不備確認といった形式的な審査を経て広く掲載する形をとっています。
一方、ガバメントクラウド上で稼働する「公共SaaS」になるには、GCASガイドの要件適合やアーキテクチャレビュー等のプロセスが必要です。
本記事では、「DMPに掲載されること」と「ガバメントクラウド上の公共SaaSとして稼働すること」を分けて整理します。
デジタル庁が公共SaaSで実現しようとしていること
デジタル庁の発信を読み解くと、公共SaaS推進の狙いは大きく4つにまとめられると、私たちは解釈しています。
- 「所有」から「シェア」への構造転換：個別開発・個別保有ではなく、共通機能をSaaSとして共同利用することで、行政全体のコストを最適化する
- 地方も含めたデジタルの恩恵への公平なアクセス：大都市だけでなく、リソースの限られた小規模自治体でも最新のシステムを使えるようにする
- 公共IT市場に優秀なエンジニアが集まる構造をつくる：旧来の重厚な発注モデルから脱却し、モダンな技術を活用できる市場へ
- 標準仕様にそのまま合わせる「Fit to Standard」発想によるプロダクトの健全な進化：個別カスタマイズを抑制し、標準仕様の共通機能をサービスとして育てるエコシステムを作る
「Fit to Standard」はSaaS業界で使われる考え方ですが、これを公共調達の世界に持ち込もうとしているのが、公共SaaS構想の本質的なポイントだと私たちは捉えています。
ソフトウェア事業者にとってのメリット — なぜ今、参入すべきか
公共SaaSへの参入を「難しそう」「大手向け」と捉える方もいるかもしれません。しかしビジネスモデルとして整理すると、民間SaaSと比べて非常に魅力的な側面があります。
1. 全国の地方公共団体（市区町村数約1,700）がターゲットになる
従来の公共ITは、自治体ごとに個別のシステムを構築・カスタマイズする労働集約的なモデルだったため、リソースの限られた事業者が全国展開を進めることは物理的に困難でした。しかし、公共SaaSの枠組みでは、業務アプリケーションのソースコードとバージョンを共通化することが原則となります。
つまり、自社が磨き上げた「たった一つの標準プロダクト」のまま、全国約1,700の地方公共団体という巨大な市場セグメント全体を同時にターゲットにできるようになります。
労働集約型のSI（システムインテグレーション）から、プロダクト主導型のSaaSビジネスへのシフト。これこそが、資本力や組織の規模ではなく「プロダクトの完成度と技術力」で勝負できる、中小・スタートアップにとっての大きな参入意義です。
2. 「個別カスタマイズしない」がベンダーの盾になる
公共SaaSの要件として、デジタル庁は個別カスタマイズを行わない方針※3を掲げています（運用パターン別のサービスやオプション機能は許容、アドオンは真に必要な場合に限る）。
従来のシステム開発では、発注者からの個別要望を断れずにカスタマイズを重ね、気づけばコードが複雑化し、運用コストが膨張する ── という構造的な問題が頻発してきました。公共SaaSでは「デジタル庁の方針でカスタマイズはできません」と言える。自治体と事業者が一体となって共通機能を育てていくことで、SaaS本来の健全なエコシステムが成立しやすくなります。
もちろん、現場のカスタマイズ要望がすぐにゼロになるわけではありませんが、「共通の指針がある」こと自体が事業者にとって大きな後ろ盾になります。
3. 積み上げ型の収益構造と乗り換えリスクの低減
案件ごとに個別開発を繰り返す従来のSIとは異なり、公共SaaSは単一のプロダクトを複数自治体で共有するため、新規導入がそのままダイレクトに「収益のベースアップ」へとつながります。
リプレースのたびに売上がリセットされるリスクを抑え、獲得した顧客数がそのまま収益の積み上げになります。長期的かつ予測可能な成長を維持できる、というのが公共SaaSの構造的な強みです。
4. マルチテナント化によるインフラ・運用コストの削減
公共SaaSが求める「マルチテナント構成」を実現することで、自治体ごとの個別インフラが不要になります。インフラ原価と運用保守の工数を大幅に削減しながら、顧客数を増やせるスケーラブルなビジネスモデルが成立します。
公共SaaSになるための要件 — 審査で見られる4つのカテゴリ
公共SaaSとして認定されるための要件は、大きく4つのカテゴリに整理されています。以下は、デジタル庁が公開しているGCASガイド「ガバメントクラウドにおけるSaaS（公共SaaS）について」（2025年4月）をもとに、要点を整理したものです。
カテゴリ①：基本要件
まず前提として、自社のSaaSが「公共・準公共に特化した共通的な業務機能」に該当する必要があります（制度官庁が標準仕様を定めている業務領域では、その準拠も求められます）※3。 その上で、SaaS事業者として特に意識すべき要件は以下です。
- 価格表（定価）の公開：有償の場合に必須。値引きは否定しない
- データの所有権と移行可能性：所有権はテナント側にあり、 いつでもデータを持ち出せる設計が必要
- ガバメントクラウド上での稼働と内部統制：目的外利用を防ぐ 仕組みも併せて求められる
カテゴリ②：管理要件
必須事項は1点です。
- サービスレベルや障害情報を含む運用状況を公開すること
加えて、
- テナントごとの利用状況をダッシュボード・APIで取得可能にし、GCASと連携できることが推奨されています
カテゴリ③：セキュリティ要件
事業者として特に押さえておくべき点は2つです。
- テナントごとの予防的・発見的統制を自動設定すること
（テナント作成時に自動でアクセス制御・監視が走る設計が必要）
- サービス開始前にSOC2等の監査・脆弱性検査の結果をデジタル庁と共有すること
ISMAPは必須ではなく推奨です（詳細は後述）。
カテゴリ④：アーキテクチャ要件
- カスタマイズ（個別改修）は行わない
- マルチテナント構成が前提（管理機能は共通化が必須）
- 業務アプリケーションのソースコードは全テナント共通
- 外部システムとのデータ連携はAPI連携
- 利用者認証・課金の仕組みを適切に実装すること
- SaaS管理環境（コントロールプレーン）をアプリケーション環境と分離すること
※詳細は後述の「コントロールプレーンを早期から設計する理由」セクションで整理します。
4カテゴリのうち、特にカテゴリ④（アーキテクチャ要件）は純粋な技術力が問われる領域です。マルチテナント設計、コントロールプレーンの分離 など、ここが「公共SaaSになれるかどうか」の事業者側の考慮すべき重要なポイントになります。
標準仕様の有無を問わない領域も広がりつつある
もともと公共SaaSは、対象領域として「重点計画に記載の公共・準公共分野※4、かつ制度官庁等が標準仕様を定める情報システム」が中心と整理されていました。
ただし、GCASガイドや関連文書の継続的な改定により、標準仕様の有無にかかわらず、複数の利用対象が存在し汎用性の高い仕様であれば公共SaaSとして検討できる方向に、徐々に射程が広がっているようです（最新のスコープは必ずGCASガイドの最新版で確認してください）。
ISMAPの位置付け：必須ではなく「効率化の枠組み」
公共SaaSのセキュリティ要件で気になるのが、ISMAP（政府情報システムのためのセキュリティ評価制度）の扱いです。整理すると以下のようになります。
- ISMAP登録は「推奨」（一律必須ではない） ISMAP登録されていないサービスであっても、デジタル庁が定める公共SaaS向けのセキュリティ基準への適合性が確認されれば、公共SaaSとして利用が可能です。ただし、国の機関が利用するSaaSでは実務上ISMAPが求められる場面が多い点には留意が必要です。
- ガバメントクラウド利用による「管理策の継承」 ガバメントクラウド自体がISMAP登録済みの強固なインフラであり、デジタル庁の統一的なセキュリティ統制のもとで開発・運用すれば、本来ISMAPで求められる管理策のうちインフラに起因する項目を評価済みにできたり、デジタル庁の統制を継承したりできる場合があります。
- 公共SaaSとしての適格性審査 ISMAP登録を必須条件として一律に求めるのではなく、デジタル庁が用意した枠組み（公共SaaSとしての評価プロセス）を通じてセキュリティ担保を確認する設計です。
- ISMAP-LIUという中間ステップ 2022年11月から運用されているISMAP-LIU（低リスク利用業務向けSaaS用）は、機密性2以下の情報を扱うSaaSに特化し、評価項目や監査手続きが簡素化されています。重いISMAPフルセットの前段として活用できる選択肢です。
なお、ISMAPフル取得には第三者監査費用や準備コストが相当の規模になるケースが多く、スタートアップや中小事業者にとって現実的なハードルになりえます。ISMAP-LIUの活用やガバメントクラウドの管理策継承を組み合わせることで、コストを抑えながら公共市場へ参入するルートを検討することをお勧めします。
「ISMAPによる信頼性を尊重しつつ、ガバメントクラウドの利用環境を活かして、より効率的なプロセスで公共市場への参入を果たす」── このバランスこそが、開発事業者にとっての現実的かつ大きなメリットであり、行政の安全なSaaS利用を促進する鍵だと考えています。
ビジネスモデルの注意点 — 民間SaaSとの違いを押さえる
プライシングは公開が前提
公共SaaSはGCASガイドの基本要件として、価格表（定価）の公開が必須とされています（値引きは否定されません）。「価格を公開したくない」というベンダーの声もありますが、デジタル庁の方針として「価格の透明性を保ち、自治体が比較検討できること」が重視されています。
定額か従量かはベンダーの判断ですが、公共SaaSとして選ばれるためのプライシング設計が重要です。たとえば、利用が特定の時期・時間帯に集中する学校や行政窓口のような利用形態では、従量課金より定額モデルの方が自治体に受け入れられやすい場合があります。
先行投資と回収シナリオの設計
公共SaaS参入には、GCASアカウント取得・デジタル庁のアーキテクチャレビュー・ISMAP対応・技術要件への準拠など、複数の先行投資フェーズがあります。コスト構造と回収シナリオを丁寧に設計した上で参入を判断することが重要です。
コントロールプレーンを早期から設計する理由
公共SaaSの審査基準に「分離されたSaaS管理環境（コントロールプレーン）」が明示されているように、コントロールプレーンは公共SaaS参入の技術的に重要な点です。
コントロールプレーンとアプリケーションプレーン
SaaSのコンポーネントは、AWSの公式アーキテクチャガイド※5でも整理されているとおり、大きく2つのプレーンに分けられます。
- アプリケーションプレーン：顧客に直接価値を届けるコア機能群（業務アプリケーション本体）
- コントロールプレーン：SaaSを安定的に運営・管理するための共通機能群（テナント管理・認証認可・課金・メータリング・監視・監査ログ）
多くのベンダーは「まずコア機能を作る、コントロールプレーンは後から」というアプローチを取りがちです。しかし、公共SaaSとして複数の自治体に展開する段階で、コントロールプレーンが弱いと「自治体ごとの個別対応」が積み重なり、運用コストが膨張します。
コントロールプレーンは初期段階から構想し、簡易なところから始めて、事業成長に合わせて段階的に拡張していくのが現実解です。
公共SaaS特有のコントロールプレーン要件
民間向けSaaSの基本設計に加え、公共SaaS（特にガバメントクラウドへの展開）では、行政機関が求める「透明性」「説明責任」「環境への適応力」を支える管理機能が上乗せされます。
(1) 厳格な論理的テナント分離と接続制限
テナントごとにアクセス制御・権限分離による論理分割を整備し、テナント作成時に自動で設定・管理することを求めています（必須）。これを実装面で突き詰めると、自治体特有のネットワーク環境に合わせた接続制限や、権限管理を動的に行うポリシー制御ロジックといった設計が有効になります。
(2) 行政機関の認証基盤との相互運用性（アイデンティティ連携）
導入先（テナント）が指定する認証基盤（Microsoft Entra ID等の外部IdP）と、標準プロトコル（SAML/OIDC）で連携できる能力が求められるケースがあります。これにより、職員の異動に伴うID管理の効率化、二要素認証（MFA）の強制といった行政側のセキュリティポリシーをSaaS側でも維持できます。
(3) ISMAP管理基準を意識した監査・統制機能
「利用者識別と認証」「監査ログの取得・保護」といった管理策への適合は、公共市場における事実上の標準要件です。「誰が・いつ・何をしたか」の証跡を改ざん不可能な状態で記録・保存し、行政機関の求めに応じて速やかに抽出・提供できる仕組みが、サービスの信頼を支えます。
(4) GCAS等を通じた運用可視化とAPI連携
公共SaaSのコントロールプレーンには、2種類の可視化機能を用意することが推奨されます。 ひとつは、各テナント（自治体・機関）が自らの利用状況やコストを確認できるダッシュボードおよびAPIです。 もうひとつは、GCAS（ガバメントクラウドの利用窓口機能）へのAPI連携です。なお、GCAS連携のAPI仕様は現時点で段階的に整備中※6との記載があるため、設計段階から連携を見越したアーキテクチャにしておくことが重要です。
まとめ：公共SaaS参入チェックリスト
「日本の公共システムを『イケてるシステム』にしたい」というデジタル庁クラウドチームの言葉が示すように、公共SaaS市場は技術力のある事業者が本領を発揮できる場へと変わりつつあります。民間SaaSで培ったマルチテナント技術・コントロールプレーン設計のノウハウは、そのまま公共SaaSへの最大の武器になります。
参入を本気で検討するなら、まず以下の3つの問いに自社のSaaSを当ててみてください。
- 対象領域の問い：自社のSaaSは、複数の利用対象が存在する汎用性の高い仕様か？（標準仕様の有無は問わない方向に広がりつつあるが、最新のスコープはGCASガイドで要確認）
- アーキテクチャの問い：マルチテナント／共通ソース／コントロールプレーン分離は、設計レベルで対応できているか？
- ビジネスモデルの問い：価格公開・データポータビリティ ── この2点に対応できるか？
3つにYesと言えるなら、次のステップはGCASアカウント取得とアーキテクチャレビューへの準備です。Noの項目がある場合でも、設計を見直すことで挑戦できる可能性は十分にあります。
株式会社アンチパターンでは、民間で培ったSaaSのノウハウをベースに、公共SaaS参入を検討する事業者様のご支援を実施しています。「自社のSaaSが要件を満たすか確認したい」「どこから手をつければいいかわからない」という段階からでも、SaaSus Platformや10 Days SaaSificationを通じてお気軽にご相談ください。
SaaSus Platformにご興味がある方はこちらです。
参考リンク