本書の目的

本文書は、2025年4月１日に、ガバメントクラウドを利用して公共SaaSを効率的かつ効果的に整備いただくことを目的に、SaaSの共通要件等を整理した「ガバメントクラウドにおけるSaaS（公共SaaS）について」において、「別途整理するとしていた技術方針」を整理した文書である。
なお、当該方針については、引き続き関係者と意見交換を行い、必要に応じてアップデートしていく予定である。

公共SaaSの共通要件については、「ガバメントクラウドにおけるSaaS（公共SaaS）について 3.3open_in_newOpens in new tab」を参照。

---

3.3 公共SaaSの共通要件
公共SaaSにおける共通要件は、以下のとおりとする。なお、この要件にかかる技術方針は別途整理する。

１．基本要件
（必須要件）

• 公共・準公共に特化した共通的な業務機能であること
• 民間事業者が提供の場合は業務仕様が制度官庁等の業務標準に準拠していること （業務標準が存在しない場合や共通サービスについては別途、整理を行う）
• 価格表が詳細に公開されること（SaaS利用が有償の場合。値引きは否定しない）
• ガバメントクラウド上で稼働すること（外部連携は可能）
• ガバメントクラウドの不適切な利用（目的外利用）を防ぐ内部統制の仕組みを有すること
• データの所有権及び管理の権限がテナントにあること
• データ移行（取り込みと取り出し）が可能なこと

（以下略）

---

1. 公共SaaSの概要

1.1 公共SaaSの定義

「公共SaaS」とは、ガバメントクラウドを利用環境として、「重点計画に記載の公共・準公共分野に該当し、制度官庁等が標準仕様等を定める※情報システム」をSaaSとして構築したものを指し、具体的には、以下の要件を満たすSaaSをいう。（「ガバメントクラウド利用検討の基本的な考え方」より）

1. 「公共SaaS」では、SaaS事業者（開発又は管理を行う事業者）が業務システム等の機能をサービスとして提供し、SaaS利用者はシステム開発やシステム運用を行わずにサービスを利用する
2. 「公共SaaS」では、SaaS利用者毎の個別の稼働環境（シングルテナント）ではなく共同利用する環境（マルチテナント）を前提とするシステム構成とする
   1. 業務アプリケーションのソースは全テナント共通を前提としたサービス設計とする
   2. テナント毎の業務の一部機能の個別環境は柔軟に考えるが、管理機能は共通の機能とする
3. 「公共SaaS」では、SaaS事業者が、デジタル庁とガバメントクラウド利用権付与兼債務負担契約を締結し、公共SaaSのサービス提供に係るガバメントクラウド利用料は、SaaS事業者が負担する
4. 「公共SaaS」において、サービス利用料が有償の場合、SaaS事業者がSaaS利用者から必要な経費（公共SaaSのサービス提供に係るガバメントクラウド利用料を含む）をサービス利用料として徴収する

※「制度官庁等が標準仕様等を定める」については、標準仕様等の有無に応じて、以下の要件を満たす場合は、公共SaaSとして利用を検討することができる。

• 制度官庁が標準仕様又はそれらに準ずるもの（以下、「標準仕様等」）を定めている又は将来的に定めることが想定されている場合

  • 標準仕様等に準拠していること。
  • 当該業務と密接に関連する業務に関するものであって、標準仕様等に準拠したシステムと一体的に提供されることが望ましいシステム又は機能がある場合は、当該関連業務の範囲が標準仕様等に定められていること。なお、標準仕様等のほか制度官庁等が定める業務の仕様に関する方針等に定められている場合も可とする。

• 制度官庁が標準仕様等を定めていない場合

  • 当該システムの仕様における機能要件について、複数の利用対象、加えて制度官庁が明らかな場合には制度官庁の意見を十分に聞くとともに、汎用性の高い仕様の検討が行われていること。
  • 利用している又は利用を希望する組織（行政機関等のほか、準公共サービス※の提供事業者でも可）の存在が確認できること。
  • 将来的に当該業務の実施に用いるシステムの標準仕様が定められた場合は、当該標準仕様等を定めた制度官庁及びデジタル庁とその対応について協議すること。

  ※生活に密接に関連していて、国による関与（予算措置等）が大きく、他の民間分野への波及効果が大きい分野（準公共分野）において国と民間が協働して支えているサービスのこと。（「デジタル社会の実現に向けた重点計画（令和7年度6月13日）」より）

図 1 公共SaaSの構成イメージ

1.2 構成イメージの補足

• SaaSユーザ環境は、SaaS利用者がアクセスしデータを格納する環境
• SaaS管理環境は、SaaSユーザ環境を管理するために使用する機能を配置する環境で、SaaS事業者（管理者）がアクセスし利用する
• SaaS開発環境は、SaaS事業者（開発者）が公共SaaSを開発テストする環境
• SaaSユーザ支援環境は、SaaS利用者が公共SaaSをすぐに利用できるように必要な情報を提供したり問い合わせ対応する機能を配置する環境
• SaaSユーザ環境／SaaS管理環境の分離以外は、構成イメージの図のとおりでなくてもよい

1.3 公共SaaSにおける責任分界

図 2 公共SaaSにおける責任分界

2. 公共SaaSへの共通要件

2.1 モダン化と公共SaaSの共通要件について

• 公共SaaSはこれまでの政府情報システムのガバメントクラウド利用と同様に、クラウドの特性を活かした効率的なシステム運用管理を実現するため、システム運用管理の省力化や自動化を含むモダン化が要請される。このため、SaaS事業者はデジタル庁への申請により、モダン化の確認手続を受けることとする。手続きについては、6章に後述する特例を除き、「公共SaaSの利用申請等（民間事業者提供）open_in_newOpens in new tab」を参照すること。
• モダン化についてはGCASガイドopen_in_newOpens in new tabを参照されたい
  • ガバメントクラウドにおけるモダン化の定義open_in_newOpens in new tab
• 公共SaaSについては、SaaSならではの特性とユーザデータを保管する責任の重さ、及び公共分野で共通的に運用される等の特性より、モダン化に加えて公共SaaSの共通要件が要請される。このため、SaaS事業者はデジタル庁への申請により、共通要件の確認手続を受けることとする。
• ただし、地方公共団体における標準化対象業務その他これに関連するシステムについては、「6. 地方公共団体における標準化対象業務その他これに関連するシステムに係る特例」を設けることとする。

2.2 公共SaaSの共通要件

基本要件
（必須事項）

• 公共・準公共に特化した共通的な業務機能であること。
• 民間事業者が提供の場合は核となる業務仕様が制度官庁等の標準仕様等に準拠していること（制度官庁が標準仕様等を定めていない場合も含め、詳細は「1.1 公共SaaSの定義」を参照）。
• 価格表で定価が公開されること（SaaS利用が有償の場合。値引きは否定しない）。
• ガバメントクラウド上で稼働すること（外部連携は可能）。
• ガバメントクラウドの不適切な利用（目的外利用）を防ぐため、デジタル庁との契約や社内規程等による仕組みを講じること。
• データの所有権と管理の権限がテナントにあること。
• データ移行（取り込みと取り出し）が可能なこと。

（推奨事項）

• 開発環境がガバメントクラウド上であること（後述の「セキュリティ要件について」を参照）。
• 連携ニーズの高い情報（別途、整理を行う）を扱うSaaSについてはガバメントクラウドの求めるデータ連携の仕組みが用意されること。

管理要件
（必須事項）

• 全体的な運用状況（サービスレベルや障害情報を含む）が公開されること。

（推奨事項）

• テナント毎の利用状況がダッシュボードやAPIで取得可能でありGCAS（ガバメントクラウドの利用窓口機能）と連携可能なこと。

セキュリティ要件
※詳細は後述の「セキュリティ要件について」を参照

（必須事項）

• SaaSとしてテナントのユーザー情報が安全に運用管理されること。

（推奨事項）

• 閉域網であることを前提としない（インターネットからの利用を前提としても機能する）セキュリティ対策が取られること。

※当面の間は、現行のガバメントクラウドへの接続方式によっても差し支えない。

アーキテクチャ要件
（必須事項）

• カスタマイズ（個別改修）は行わない。テナントの規模の相違によるニーズの相違等には運用パターン（規模）別のサービス、一部のテナントでのニーズにはオプション機能として対応すること。テナント毎への対応も、カスタマイズではなく設定による変更やメタデータによる変更を検討し、アドオン（個別追加）も真に必要な場合に限ること。
• テナント毎の個別の稼働環境（シングルテナント）ではなく共用を前提とする環境（マルチテナント）とするが、提供サービスの特性に応じて柔軟に対応すること。ただし、管理機能は共通化されること。
• 業務アプリケーションのソースコードは全テナント共通を前提としたサービス設計とする（業務アプリケーションのテスト・更新等による一時的な複数バージョンの併存は問題ない）。
• 外部システムとのデータ連携についてはAPI連携とすること。
• 利用者認証の仕組み及び課金の仕組み（有償の場合のみ）が適切に実装されていること。

3. 公共SaaSの共通要件にかかる技術方針

3.1 ガバメントクラウド（IaaS/PaaS）の利用

---

１．基本要件
（必須要件）​
ガバメントクラウド上で稼働すること（外部連携は可能）

（「ガバメントクラウドにおけるSaaS（公共SaaS）について」の「3.3 公共SaaSの共通要件」より抜粋）

---

• 公共SaaSはガバメントクラウド（IaaS・/PaaS）上に構築されること。ただし、セキュリティレベルが低下しないことを前提に、合理的な理由による外部サービス（SaaS）の利用や外部システムとの連携は自由とする（必須事項）
• ガバメントクラウド上ではモダン化を前提に、利用サービスに特段の制限は設けず、通常の利用システムと同様の扱いとする（ストレージやDB等における利用者データの保管場所は国内リージョンに限定される）（必須事項）
• ガバメントクラウド上の通常の利用システムと同様に、ガバメントクラウドが求める予防的統制・発見的統制、ガバメントクラウドで定義された各種ガイド（GCASガイドに記載）に従う（必須事項）
• ガバメントクラウドが提供するGCASサービスについても利用可能（説明事項）
  • ガバメントクラウド内のマルチクラウド間を接続するネットワークサービス「GCAS Connect」を申し込んで利用可能
  • ガバメントクラウドの開発環境およびソースコードレポジトリとリリース管理（CI/CDパイプライン）のベストプラクティス「GCAS DevStack」を申し込んで利用可能（令和8年度から）
  • 上記のほか利用可能なサービスが提供される場合には、GCASガイド等で周知する
• CSPが提供するマーケットプレイスの利用は保管金制度の制約から不可とする（必須事項）

3.2 開発環境について

---

１．基本要件
（推奨要件）​
開発環境がガバメントクラウド上であること

（「ガバメントクラウドにおけるSaaS（公共SaaS）について」の「3.3 公共SaaSの共通要件」より抜粋）

---

• 開発環境（推奨事項）
  • 公共SaaSシステムの開発および検証を実施するガバメントクラウド上で、本番と同等の環境構成とすることが推奨される
• コード管理／CI/CD（説明事項）
  • 公共SaaSシステムのプログラムのソースコードを履歴や修正、承認含めて管理するレポジトリはガバメントクラウドより提供される
  • プログラムの各環境への展開（リリース）、プログラムへの自動チェック、リリースの承認等を自動で行うCI/CDパイプライン機能はガバメントクラウドより提供される
  • なお、ガバメントクラウドが令和8年度から提供する開発環境サービス（GCAS DevStack）を利用することも可能

3.3 テナントについて

---

１．基本要件
　（必須要件）
・データの所有権及び管理の権限がテナントにあること
・データ移行（取り込みと取り出し）が可能なこと
２．管理要件
　（推奨事項）
・テナント毎の利用状況がダッシュボードやAPIで取得可能でありGCAS（ガバメントクラウドの利用窓口機能）と連携可能なこと

（「ガバメントクラウドにおけるSaaS（公共SaaS）について」の「3.3 公共SaaSの共通要件」より抜粋）

---

• SaaSユーザ環境では、各テナント（利用者）自身が自らのデータのオーナーとなるように、論理分割の仕組み（アクセス制御や権限分離された運用管理の仕組み）を整備すること（必須事項）
• 各テナントの利用者データについて、外部へのデータ移行（取り込み、取り出し）ができるようにし、データ移行のためのツールを用意すること（必須事項）
• テナントおよびその環境の稼働状況がSaaS利用者からいつでも確認できるダッシュボードおよびAPIを用意することが望ましい（推奨事項）

3.4 サービスレベルの公開について

---

２．管理要件
（必須要件）​
全体的な運用状況（サービスレベルや障害情報を含む）が公開されること​

（「ガバメントクラウドにおけるSaaS（公共SaaS）について」の「3.3 公共SaaSの共通要件」より抜粋）

---

• 公共SaaSとしてのサービスレベルを定義し、ユーザ支援環境機能のWebサイトにて公開、もしくは関係者が参照できるようにすること。また、大規模災害時のサービス継続、復旧の方針を定義し、サービスレベルとして定義に含めること（必須事項）
• 公共SaaSの全体的な運用状況（サービスレベルや障害情報を含む）が公開されること（必須事項）
• 本体障害時にも参照可能なよう、別環境（リージョン等）での提供が好ましい。提供するサービスについて、CSPが提供するヘルスダッシュボードと同様の形態による情報公開が望まれる（推奨事項）
• 公共SaaSがテナント毎の利用状況がダッシュボードやAPIで取得可能でありGCAS（ガバメントクラウドの利用窓口機能）と連携可能であることが好ましい。GCASとの連携に係るAPI仕様等は別途、段階的に整備の予定（推奨事項）

3.5 公共SaaS利用者支援機能について

---

２．管理要件
（必須要件）​
全体的な運用状況（サービスレベルや障害情報を含む）が公開されること​

（「ガバメントクラウドにおけるSaaS（公共SaaS）について」の「3.3 公共SaaSの共通要件」より抜粋）

---

• Webサイト（必須事項）
  • 該当公共SaaSを外向けに説明するホームページをWebサイトとして用意すること
  • 公共SaaSユーザがSaaS利用時に参照するマニュアルやガイド、FAQ等の説明ページをWebサイトとして用意すること
  • SaaSの外向けAPIおよびそのAPIで取得できるデータの仕様や利用方法の紹介ページをWebサイトとして用意すること
  • SaaSを外部から利用するためのSDKやツール等を公開する場合にはダウンロード場所を用意すること
  • 公共SaaSユーザの役に立つトレーニング動画等の配信場所を用意すること（推奨事項）
• ヘルプデスク（サービスデスク）（必須事項）
  • 公共SaaS利用者が公共SaaSについて問い合わせができるヘルプデスクを用意すること
  • ヘルプデスクでは、利用者ごとにやり取りの履歴が残るようにすること
  • 個人情報等を削除したうえで汎用的なナレッジやFAQとして活用すること

3.6 セキュリティ要件について（全般）

---

３．セキュリティ要件
（必須要件）
SaaSとしてテナントのユーザー情報が安全に運用管理されること

（「ガバメントクラウドにおけるSaaS（公共SaaS）について」の「3.3 公共SaaSの共通要件」より抜粋）

---

• 公共SaaSにはGCASガイドで示すセキュリティ対策への準拠に加え、SaaSとしてテナントのユーザー情報が安全に運用管理されることが要求される。サービス開始前確認ではSOC2等の監査、脆弱性検査、ペネトレーションテスト等の計画と結果のデジタル庁との共有が必要となる。また、ISMAP登録や外部認証を予定する場合は、それらの状況報告も望まれる（必須事項）
• 高品質コードの流用、コード自動チェック、デプロイの自動化などによる開発効率、品質、セキュリティレベルの向上を目的にGCAS DevStack他サービスをGCASサービスとして提供していく予定であり、これを利用するか、提供サービスの特性に応じた仕組みを構築すること。これらのGCASサービスを利用することで、効率化に加えて実質的なセキュリティ管理の高度化を実現することを企図している​（必須事項）
• ガバメントクラウドはISMAP登録済のクラウドサービスを選定しており、デジタル庁において統一的なセキュリティ統制がとられていることから、ガバメントクラウドの開発環境を含む利用環境を提供することで、 ISMAP管理策の一部は対象外とすることが可能であり、行政機関等による安全な公共SaaSの利用が促進されるものと期待する（説明事項）
• 公共SaaSにおいてISMAP登録は推奨されるが必須とはしない。SaaS運営主体と利用者の判断とする。ガバメントクラウドは公共SaaSのセキュリティ確認で収集した情報を必要に応じて利用者に提供し、利用者でのリスク判断を支援する（説明事項）

3.7 セキュリティ要件について（予防的統制・発見的統制）

• テナントが作成されるタイミングで、特定範囲のデータアクセスに限定するDBMSスキーマ等の禁止設定（予防的統制）、あるいはデータストアへの強い権限設定をアラートする発見的統制の設定を自動で行うこと（必須事項）
• 予防的統制および発見的統制として、セキュリティリスクを高める操作や設定の禁止または、そのような事象の検知内容を定義すること（必須事項）
• 予防的・発見的統制の定義時には、アクセス経路やアクセス権限の変更や強化、認証やログに対する設定変更、あるいはデータに対する暗号化等の保護策の変更等の発生ポイントに対して重点的に検討を行うこと（必須事項）
• 予防的・発見的統制で禁止操作や特定操作を発見した際には利用者やSaaS管理者にアラート通知を送ることができるようにすること（必須事項）

3.8 セキュリティ要件について（ログ集約管理）

• SaaSユーザ環境やその他環境やそこで稼働するシステムに対する操作のログを取得し、SaaS管理環境に集めて管理すること（必須事項）
• 集めたログを集計処理し、以下の用途で利用することが望ましい（推奨事項）
  • 利用者（ユーザ）への課金の計算（必要に応じて）
  • ダッシュボード等でサービス利用状態やセキュリティ保持状況を可視化
  • ダッシュボード等でその利用範囲での状態やセキュリティ設定、コスト情報の可視化

3.9 セキュリティ要件・アーキテクチャ要件について（認証）

---

３．セキュリティ要件
（必須要件）
SaaSとしてテナントのユーザー情報が安全に運用管理されること

４．アーキテクチャ要件
（必須要件）
利用者認証の仕組み及び課金の仕組み（有償の場合のみ）が適切に実装されていること

（「ガバメントクラウドにおけるSaaS（公共SaaS）について」の「3.3 公共SaaSの共通要件」より抜粋）

---

• 公共SaaS内の共通の機能として、公共SaaSアクセス時のユーザ認証を行う機能と、認証機能へのユーザ登録や管理機能を提供すること。もしくは外部のユーザ認証サービスと連携して同等の機能を提供すること（必須事項）
• 認証機能としては、「デジタル社会推進標準ガイドライン DS-500 行政手続におけるオンラインによる本人確認の手法に関するガイドライン」 （各府省情報化統括責任者（ＣＩＯ）連絡会議決定） の最新版や、内閣サイバーセキュリティセンター（NISC）が定義するガイドに則った実装が推奨される（推奨事項）

3.10 アーキテクチャ要件を満たすシステム構成例と満たさない例

---

４．アーキテクチャ要件
（必須要件）
テナント毎の個別の稼働環境（シングルテナント）ではなく共用を前提とする環境（マルチテナント）とするが、提供サービスの特性に応じて柔軟に対応すること。ただし、管理機能は共通化されること

（「ガバメントクラウドにおけるSaaS（公共SaaS）について」の「3.3 公共SaaSの共通要件」より抜粋）

---

アーキテクチャ要件を満たすシステム構成を５例、満たさない構成を１例提示する。

アーキテクチャ要件を満たすシステム構成例1

図 3 アーキテクチャ要件を満たすシステム構成例1

アーキテクチャ要件を満たすシステム構成例2

図 4 アーキテクチャ要件を満たすシステム構成例2

アーキテクチャ要件を満たすシステム構成例3

図 5 アーキテクチャ要件を満たすシステム構成例3

アーキテクチャ要件を満たすシステム構成例4

図 6 アーキテクチャ要件を満たすシステム構成例4

アーキテクチャ要件を満たすシステム構成例5

図 7 アーキテクチャ要件を満たすシステム構成例5

アーキテクチャ要件を満たさないシステム構成例

図 8 アーキテクチャ要件を満たさないシステム構成例

3.11 システム構成について

---

４．アーキテクチャ要件
（必須要件）
テナント毎の個別の稼働環境（シングルテナント）ではなく共用を前提とする環境（マルチテナント）とするが、提供サービスの特性に応じて柔軟に対応すること。ただし、管理機能は共通化されること

（「ガバメントクラウドにおけるSaaS（公共SaaS）について」の「3.3 公共SaaSの共通要件」より抜粋）

---

• 公共SaaS提供のために必要な環境を事前に定義し、各機能やデータの配置を明確にすること（必須事項）
• 利用者の情報を格納するSaaSユーザ環境（テナント向け環境）と、SaaS管理環境（コントロールプレーン）については、明確に分けること（必須事項）
  • ユーザデータが含まれるかどうか、運用者の組織や役割が分かれるかどうか、等を判断基準に環境を分離すること
• 分析等ワークロードの種類が異なったり、一部の処理の全体影響度合いを制限したい場合、ユーザ数やデータ量を平準化できるグルーピングが考えられる場合は、サーバ分離や環境分離等の適切な粒度での分離を定義し、全環境の自動展開を行えるようにすること（必須事項）
• 負荷の増減が見込まれる場合はリソースの効果的利用のための自動でのスケール処理を実装すること（必須事項）

3.12 マルチテナント対応について

---

４．アーキテクチャ要件
（必須事項）
・カスタマイズ（個別改修）は行わない。テナントの規模の相違によるニーズの相違等には運用パターン（規模）別のサービス、一部のテナントでのニーズにはオプション機能として対応すること。テナント毎への対応も、カスタマイズではなく設定による変更やメタデータによる変更を検討し、アドオン（個別追加）も真に必要な場合に限ること
・業務アプリケーションのソースコードは全テナント共通を前提としたサービス設計とする（業務アプリケーションのテスト・更新等による一時的な複数バージョンの併存は問題ない）
・テナント毎の個別の稼働環境（シングルテナント）ではなく共用を前提とする環境（マルチテナント）とするが、提供サービスの特性に応じて柔軟に対応すること。ただし、管理機能は共通化されること

（「ガバメントクラウドにおけるSaaS（公共SaaS）について」の「3.3 公共SaaSの共通要件」より抜粋）

---

• 全テナントに同じサービスレベルと同じ機能を提供可能なサービス構成とすること（同一コードベースとし、カスタマイズは許容しない） （必須事項）
• 特定テナントへの個別対応が必要な場合は、オプション機能として希望するテナントが利用できるように実装するか、アドオン（個別追加）として別環境に実装してネットワーク連携すること（必須事項）
• 論理分割の方法としては、次の粒度が例として考えられ、粒度が細かいほど運用負荷が減少してリソースの効果的利用ができコストが低い。一方で、特定の過負荷が全体に影響しやすくなる点に留意が必要となる（説明事項）
  • （粒度細）アプリ分離：サーバインスタンスやDBMSインスタンス内で、アクセス制御による分離やスキーマによる分離、暗号による分離を行う
  • （粒度中）サーバ分離：テナント内で、サーバインスタンスやDBMSインスタンス単位で分離する
  • （粒度粗）環境分離：テナント自体を分離する
• 粒度が細かいアプリ分離で検討し、全体影響度合いの軽減等の必要に応じて、一定のルールやグループでサーバ分離を行うことが推奨される（推奨事項）

3.13 テナント管理について

---

４．アーキテクチャ要件
（必須事項）
・テナント毎の個別の稼働環境（シングルテナント）ではなく共用を前提とする環境（マルチテナント）とするが、提供サービスの特性に応じて柔軟に対応すること。ただし、管理機能は共通化されること

（「ガバメントクラウドにおけるSaaS（公共SaaS）について」の「3.3 公共SaaSの共通要件」より抜粋）

---

• 定義したマルチテナント方針に則り、適切な論理分割（テナント、サーバインスタンス、アクセス制御等による）を自動で設定、管理できるようにすること（必須事項）
• テナント向け環境作成時において、CI/CDパイプライン実行、API呼び出し、画面のボタン押下等により、自動的に新しい論理分割区画（テナント）が作成され、利用者がそのテナントに適切な権限でアクセスできるようにすること（必須事項）
• テナント向け環境作成時には、予防的・発見的統制の設定、ログ取得や課金開始、請求との連携等も自動化を前提とした運用が行われること（必須事項）
• テナント向け環境への設定変更や、テナントの削除等も、適切なプロセスを経た後に自動で実行できるようにすること（必須事項）
• SaaSユーザ環境およびそのテナントへの操作は自動化を前提とすること（必須事項）

3.14 APIについて

---

４．アーキテクチャ要件
（必須事項）
・外部システムとのデータ連携についてはAPIを用意すること

（「ガバメントクラウドにおけるSaaS（公共SaaS）について」の「3.3 公共SaaSの共通要件」より抜粋）

---

• 外向けAPIは、その仕様と利用方法をユーザ支援環境機能のWebサイトにて公開、もしくは関係者が参照できるようにすること。また、その仕様には、そのAPIで取得できるデータの定義も含めること（必須事項）
• 外部利用者が外向けAPIをテストできるよう、検証環境を用意すること（推奨事項）
• APIは耐障害性の観点で非同期処理として用意されることが好ましい（推奨事項）
• APIを提供する機能およびモダン化を前提にサーバインスタンスを持つ場合はステートレスに構成すること（必須事項）
• 必要に応じて、外部の利用システムから利用しやすいように、プログラムコードから直接関数／メソッドとして利用できるような、APIを隠蔽するSDKを用意すること（推奨事項）
• フロントWebアプリケーションも、この外向けAPIを利用してデータを取得、更新することを適宜検討することが推奨される（推奨事項）

3.15 生成AI利用環境等の提供について

• 生成AI利用環境等を提供する場合についても、基本的には通常のシステムと同様にモダン化と公共SaaSの要件が要請されるが、一般的なシステムと生成AI提供環境では相違点も大きいため、適宜、ガバメントクラウドチームと調整を行うこととする
• 業務標準に加えて政府や利用組織における生成AIガイドライン等へ準拠すること
  • 連携外部サービスの利用（海外との連携）
  • 情報保護のための方式
• 業務標準における機能要件については、以下を包含することが推奨される
  • モデルやLLMに関する部分
  • テナントの固有データ利用に関する部分
  • UI/UXに関する部分
  • プラグイン、チューニング、利用ノウハウ等の各種レベルでの共有に関する部分
    • 全テナント共通
    • テナント内の全体
    • テナント内の部門レベル
    • 個人レベル

4. 公共SaaSにおけるネットワーク

4.1 公共SaaSのネットワーク接続

• SaaS利用者の端末から公共SaaSへのアクセスはインターネット経由を原則とする。ただし、利用組織のルールにおいて閉域網接続が必要とされる場合は、 それらのルールに従うこと（ GCAS Connect（後述）の利用も可能）
• 公共SaaSのテナント間でデータ連携を行う場合は、公共SaaS内に閉じてセキュアに通信を行うものとする。公共SaaS内の通信は各々の公共SaaSで方式を定めて実装するものとする
• 公共SaaS間の通信やガバメントクラウド内の通信については、CSPの提供する機能やGCAS Connectを推奨する。各通信手段では、接続ポイント数を少なくし原則１つにすることが推奨される
• 公共SaaSがガバメントクラウド以外のサーバ等（外部SaaS、パブリッククラウド上のサーバ、SaaS利用者が所有するオンプレミスサーバ等）と通信を行う場合は各々の公共SaaSで方式を定めて実装するものとする
• 公共SaaSが方式を定めて実装する場合は、業務要件、セキュリティ、帯域幅・信頼性・可用性、コストから総合的に合理的な判断をすること

4.2 公共SaaSにおけるGCAS Connectの利用　

• GCAS Connectとは
  • ガバメントクラウドにおける閉域網の共同利用型標準通信サービスである
  • GCAS Connectのイニシャルコストはデジタル庁が負担し、ランニングコストは公共SaaS運営主体や公共SaaSテナントの利用分を負担する
• GCAS Connectのシステム構成とトポロジー
  • GCAS Connectは公共SaaSのガバメントクラウド利用環境を収容し、閉域通信によるネットワーク到達性を提供する
  • GCAS Connectは各利用組織のシステム環境、及び「共通サービス」（公共SaaSを含む）を提供するシステム環境（この両者を総じてGCAS Connectテナントと呼称する）に独立した仮想ルータを提供し、AS番号を付与することで各環境を独立した個別の環境として認識する
  • GCAS Connectの概要、およびトポロジーについては以下の図のとおり

4.3 公共SaaSにおけるネットワーク接続イメージ（地方公共団体の場合）

• サービスによって、インターネット、既存ガバメントクラウド接続ネットワークの分岐、GCAS Connect で接続して利用できる
• 公共SaaS間の通信やガバメントクラウド内の通信については、CSPの提供する機能やGCAS Connectを推奨する

図 9 公共SaaSにおけるネットワーク接続イメージ（地方公共団体の場合）

4.4 公共SaaSにおけるGCAS Connectの利用（補足）

• 名前解決機能について
  • GCAS Connectでは、GCAS Connectを経由した「共通サービス」 （公共SaaSを含む）への接続のために必要な名前解決機能を有している
  • GCAS Connect内でだけ名前解決可能なドメイン名（公共SaaS単位のサブドメイン、例：servicename.connect.gcas.cloud.go.jp）および公共SaaSテナントに対する名前解決機能（DNSサーバ）をGCAS Connectより提供する
  • 公共SaaSテナントからアクセスするフロントサーバ機能（ロードバランサ等）が公共SaaSテナントのノードにて正しく名前解決できるよう、GCAS Connectに設定値を申告すること
• 通信制御について
  • GCAS Connectの「共通サービス接続機能」はGCAS Connectから割り当てるIPv6アドレスのみで通信を行うことにより、各通信ノード間のアドレス重複の可能性を排除して多くのGCAS Connectテナントが等しく接続に参加できるように設計している
  • 各々のGCAS Connectテナントは固有のAS番号を付与し、個々のテナントをAS番号で認識・区別することで独立した個別のネットワークと扱う
  • 異なるGCAS Connectテナント間ではルーティング制御により通信を拒絶する。個々のテナントは接続を希望する共通サービスGCAS Connectテナントをあらかじめ申請することで、当該共通サービステナントとの間でだけ、通信が許可される

5. 公共SaaSの共通要件に対する技術確認

5.1 技術確認の目的と基本的な考え方

• 公共SaaSの運営主体にデジタル庁が寄り添い、一定の技術水準とセキュリティレベルを担保することを目的とする
• 進化スピードが著しく速い領域であるため、詳細化した内容のルール化、煩雑化は意図的に避ける
• 開発者の自主性、事業者のビジネス判断を尊重し、ウォークスルー（技術者同士による自由闊達なレビュー）による確認を基本とする
• セキュリティについては自動化ツールの利用を前提に、合理的な範囲で継続的、反復的な確認を目指す

5.2 公共SaaSの技術確認の手順

• 公共SaaSの計画時確認（国が提供は予算要求時）
  • ガバメントクラウド利用申請と並行して実施
  • 公共SaaSの共通要件が満たされているかを見積書や提案書、計画書ベースで評価
• 公共SaaSの技術確認①（環境払出し前）
  • ガバメントクラウド利用申請と並行して実施
  • 計画時確認との差分のみ設計書ベースで評価。差分がなければ省略可能
• 公共SaaSの技術確認②（SaaSサービスの開始前）
  • 公共SaaSの共通要件が満たされているかを実環境で評価
• 公共SaaSの追加技術確認（サービス開始後のサービス追加・変更前）
  • ガバメントクラウド利用申請と並行して実施
  • 公共SaaSの共通要件が満たされているかを実環境で評価

5.3 公共SaaS共通要件の確認

図 10 公共SaaS共通要件の確認1

図 11 公共SaaS共通要件の確認2

図 12 公共SaaS共通要件の確認3

6. 地方公共団体における標準化対象業務その他これに関連するシステムに係る特例

6.1 地方公共団体における標準化対象業務その他これに関連するシステムに係る特例

• ガバメントクラウド上に移行した地方公共団体における共同利用方式の標準化対象業務その他これに関連するシステムについては、共同利用という形態であり、個々の団体主導での継続的運用経費削減（FinOps）の実施が難しいため、ガバメントクラウドのアカウント払出し先を共同利用システムを提供する民間事業者に変更することで、民間事業者主導でFinOpsを実施できる環境を整備することとする
• アカウントの払出し先（契約先）を変更するだけで、システム自体の変更は想定せず、当分の間、公共SaaSにおける技術的な確認等も要しないこととする特例を設ける
• 本特例の対象は、ガバメントクラウド上に移行した共同利用方式の標準化対象業務（特定移行支援システムとして2030年度までにガバクラ移行するシステムも含む。）その他これに関連するシステムとする。この場合、共同利用方式の標準化対象業務その他これに関連するシステムに係るガバメントクラウドのアカウント払出し先については、地方公共団体ではなくSaaS事業者（以下「特例SaaS事業者」という。）とする（変更は該当のシステムを利用する全地方公共団体とする）
• 特例SaaS事業者と地方公共団体との契約は、アプリとインフラ（ガバメントクラウド利用料等）の一本化されたものに変更されることを想定する
• 特例SaaS事業者は、デジタル庁とガバメントクラウド利用権付与兼債務引受契約を締結することを必須とし、本特例の効果測定を目的に、特例SaaS事業者は以下の情報をデジタル庁に報告するものとする。（過去分は締結前、将来分は年度毎）デジタル庁はこれらの情報を必要な範囲で公表する場合もあるものとする
  • 共同利用に係る直近年度の各地方公共団体への請求額（利用月数、利用業務、共同利用に係る総額）
  • 本特例適用後の各地方公共団体への請求額（年度毎に利用月数、利用業務、共同利用に係る総額）
  • 実施したFinOpsの内容、その他、費用に大きな影響を与えた要因等（年度毎）

改訂履歴