1 はじめに

ガバメントクラウドは単なるインフラ環境やクラウド環境ではない。システムのモダン化（高コストの要因となる旧来技術からの脱却）を目的とする利用システムに、最適なクラウド環境を手段として提供するのがガバメントクラウドである。

「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」への準拠、クラウドCoE（Center of Excellenceの略。専門家を中心としたBPR・クラウド活用推進組織）による支援体制の確保がガバメントクラウド利用の前提となる。また、モダン化の前提として、BPRについても可能な限り実施されたい。

ガバメントクラウドにおけるモダン化の定義については、「ガバメントクラウドにおけるモダン化の定義open_in_newOpens in new tab」を参照すること。

1.1 本文書の目的

本文書はガバメントクラウドの概要を記した文書であり、対象読者がガバメントクラウドの全体像や特徴などを理解することを目的とした文書である。

1.2 本文書の位置づけ

ガバメントクラウドは「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」に示される考え方に則って運営される。まずは「ガバメントクラウド利用検討の基本的な考え方open_in_newOpens in new tab」を参照し、ガバメントクラウドの利用について検討すること。
ガバメントクラウドの全体像や特徴を「ガバメントクラウド概要解説」に記述する。職員が見積りや調達を行う際には「リファレンスアーキテクチャ」も参照すること。
ガバメントクラウドの技術的要素をCSP毎の「ガバメントクラウド利用概要」及び技術マニュアルに記述する。受注後の公共情報システムの事業者が、システム設計・構築・運用を行う際には「リファレンスアーキテクチャ」も参照すること。ただし、IT一般やCSPの一般的な情報は原則として記述せず、ガバメントクラウドに特化した記述とする。

なお、ガバメントクラウドの具体的な利用方法については、GCASアカウントを取得の上、GCASガイド(メンバー専用ページ)で公開されているドキュメントを参照すること。

地方公共団体等においては、標準的な作業項目やフェーズ毎に想定される主な作業手順等について「地方公共団体情報システムガバメントクラウド移行に係る手順書」を参照すること。

図 1‑1 本文書と関連文書の関係

1.3 対象読者

本文書の読者は、ガバメントクラウドの利用を検討する、または利用している政府情報システム及び地方公共団体情報システム等の管理者およびシステムに係る事業者を想定している。

1.4 改訂方針

ガバメントクラウドの仕様変更、クラウドサービスの更改・仕様変更、「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」の変更などガバメントクラウドを取り巻く状況の変化等があった場合には、必要に応じて本文書の改訂を実施する。

1.5 用語の定義

本文書における用語の定義を下表に示す。

表 1‑1 用語の定義

また、ガバメントクラウド対象のCSPは、2024年2月15日時点においてAWS、Google Cloud、Azure、OCIがあるが、本文中は、AWSを例として記載している。Google Cloud、Azure、OCIについては、下表のとおり読み替えること。

表 1‑2 各CSPのサービス対応表

2 背景・目的・目指す姿

2.1 背景と目的

・「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」の「1.1 背景と目的」より抜粋

2018年6月に初版決定された「政府情報システムにおけるクラウドサービスの利用に係る基本方針」（以下、「旧方針」という。）は、クラウド・バイ・デフォルト原則に基づき政府情報システムのオンプレミスからクラウドへの移行を促すものであった。旧方針に基づいて多くの政府情報システムがクラウドに移行されたが、一方でクラウドへの移行そのものが目的化されてしまい、必ずしもクラウドサービスの利用メリットを十分に享受できていないといった例も散見された。

こうした状況を踏まえ、ガバメントクラウドでは、政府情報システムが単にクラウドに移行するだけではなく、クラウドの利用メリットを十分に得られるようにするための、スマートなクラウド利用を促すことを目的に情報システムの利用環境として用意されたものである。

2.2 目指す姿

ガバメントクラウドは公共情報システムのスマートなクラウド利用を促すことで、システムや運用のモダン化を通じたクラウド最適化によるコスト最適化（インフラ構築管理コスト削減、インフラ構築管理工数削減、セキュリティ品質向上、開発スピード向上、継続的改善の実現）を目指す。

図 2‑1 スマートなクラウド利用による効果

3 概要

3.1 ガバメントクラウドとは

ガバメントクラウドとは、公共情報システムの効果的かつ効率的な整備及び運用を推進するため、公共情報システムの整備又は運用において国と公共情報システム整備運用者が共同して利用することができるものとされたクラウド・コンピューティング・サービスを利用することができるようにデジタル庁が整備したクラウド環境であり、選定するCSPがサービス機能やリファレンスアーキテクチャとして提供するセキュリティ対策に加え、ガバメントクラウドとして必要と考えられるセキュリティ対策やガバナンス機能が適用されるクラウド環境である。
ガバメントクラウドでは、選定するCSPが提供するクラウドサービスのメリットを最大限享受できるよう、必要最小限のガバナンスおよびセキュリティ設定の適用を除き、原則として独自に共通的な機能・サービスを実装し提供することは行わず、可能な限りクラウドサービスをネイティブに利用することが出来る。
なお、情報システムの構築や運用は、独自にクラウドを調達する場合と同様、利用機関のポリシーや利用システムの要件を踏まえ、利用システムの責任において行う必要がある。

令和6年度において、ガバメントクラウドとして利用できるクラウドサービスはアマゾン ウェブ サービス ジャパン合同会社のAmazon Web Services（以下「AWS」という。）とグーグル・クラウド・ジャパン合同会社のGoogle Cloud、日本マイクロソフト株式会社のMicrosoft Azure（以下「Azure」という。）、日本オラクル株式会社のOracle Cloud Infrastructure（以下「OCI」という。）となる。このほか、さくらインターネット株式会社のさくらのクラウドについては、令和7年度末までにガバメントクラウドとしての技術要件を満たすことができれば、利用環境として利用可能となる。

3.2 対象システム

ガバメントクラウドの対象システムは、「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」において対象とされている情報システム、「ガバメントクラウド利用検討の基本的な考え方について」において公共情報システムと定義されている情報システムである。

　
・「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」の「1.2 適用対象」より抜粋
本方針は、デジタル・ガバメント推進標準ガイドラインが適用されるサービス・業務改革並びにこれらに伴う政府情報システムの整備及び管理に関する事項に適用するものとする。
ただし、特定秘密（特定秘密の保護に関する法律（平成25年法律第108号）第3条第1項に規定する特定秘密をいう。）及び行政文書の管理に関するガイドライン（内閣総理大臣決定。初版平成23年4月1日。）に掲げる秘密文書中極秘文書に該当する情報を扱う政府情報システムについては対象外とする。
また、安全保障、公共の安全・秩序の維持といった機微な情報及び当該情報になり得る情報を扱う政府情報システムについても対象外とする。

・「ガバメントクラウド利用検討の基本的な考え方について」の「3.1 公共情報システムの範囲」より抜粋

デジタル行政推進法第二十三条第一項において、「公共情報システム」は、「国又は地方公共団体の事務の実施に関連する情報システム」とされており、具体的には、以下の情報システムを想定している。
なお、公共情報システムといっても多種多様の情報システムが存在しており、②～⑤では分類できない類型であっても、国又は地方公共団体の事務の実施に関連するシステムに該当するものとして利用を希望する場合には、所管部局等からデジタル庁（ガバメントクラウド担当）に申請があれば、内容を確認の上、公共情報システムとして認める場合もある（⑥に該当）。

① 政府情報システム及び地方公共団体等の情報システム

② デジタル行政推進法に基づく行政手続等に係る独立行政法人等情報システム

③ 政府又は地方公共団体職員に利用されている独立行政法人等情報システム

④ 政府又は地方公共団体情報システムとデータ連携している独立行政法人等情報システム

⑤ 重点計画に記載の公共・準公共分野に該当し、制度官庁が標準仕様を定める情報システム※

⑥ ①～⑤に該当しないものであって、国又は地方公共団体の事務の実施に関連する情報システムに該当するものとして、所管部局等からの申出に基づきデジタル庁が公共情報システムと認めた情報システム※

※ 民間事業者が整備又は運用する場合を含む。

3.3 全体像

ガバメントクラウドではデジタル庁がCSPと契約し、クラウド利用料を支払い、利用システムに対して、デジタル庁より利用環境の払い出しを行う。

3.3.1 環境の全体像

ガバメントクラウドではCSPごとに全体管理のための「共通領域（全体管理機能）」と「利用システム向け領域」が存在する。

各利用システムは、利用システム向け領域に払い出された分離された環境のなかにシステムを構成する。各環境は、独立した管理機能を保持しており、環境ごとの管理画面や管理機能を有し、利用システムが操作できる。また、許可しない限り他環境とネットワーク的に接続されることはない。

環境は本番と検証のリソース混在防止、課金単位の分離のため、本番環境と検証環境を分けて利用すること。

ガバメントクラウドでは原則として開発環境は提供しないが、CI/CDを実施する利用システムについてのみ開発環境の提供を行う。その場合、インフラ部分のCI/CDについては、ガバメントクラウドで指定するツールやテンプレートを用いてCI/CD環境を構成すること。それ以外のCI/CD環境をインフラ部分に選択する場合は、その合理性がガバメントクラウド管理組織で認められる場合のみとする。アプリケーションのCI/CD環境については、インフラ部分と同じ構成でも、独自の構成でも構わないものとする。なお環境とは具体的には以下を指す。

• AWS：アカウント
• Google Cloud：プロジェクト
• Azure：サブスクリプション
• OCI：コンパートメント（一部テナント）

　
共通領域（全体管理機能）

• システム共通の管理機能を保持。
• 利用システムのシステム管理者の払い出しや監査ログの収集管理、セキュリティアラート情報の収集などを想定。
• デジタル庁内にて構築・運用され、利用システムに必要機能が連携される。

　
利用システム向け領域

• 利用システムの各環境が（本番環境・検証環境などの単位）テンプレートで払い出され、その環境内に利用組織側で利用システムを構築する。
• 利用組織側でアプリケーションや関連サービス・実行環境を配置・構築が可能。その際、基本アーキテクチャのテンプレートや利用ガイドはデジタル庁より提供される。
• 利用システムの各環境用の、構成ルール、セキュリティ監視等の一部の基本的なセキュリティ機能は、環境払い出し時に基本設定済み。
• システムごとの追加運用機能（アプリ監視やログ出力監視、アラート設定など）やシステムとして必要なセキュリティ対策機能は、ガイドを見ながら利用側で設定する。

図 3‑1 環境の全体像

デジタル庁より提供されるテンプレート

• ガバメントクラウドテンプレートを構成する自動適用テンプレート、必須適用テンプレート、サンプルテンプレート及び個別適用テンプレート（国の行政機関向け）の概要は下表のとおり。
  自動適用テンプレート、必須適用テンプレートは、環境払い出し時にデジタル庁で自動的に適用させるもの（共通）と、利用システム側で必要なパラメータ等を入力して実行するもの（システム単位）の２種類に分かれる。
• サンプルテンプレートは、環境構築に必要な典型的な構成を定義したテンプレートであり、利用システム側にて、環境構築時に適宜内容をカスタマイズし使用する。
• 個別適用テンプレート（国の行政機関向け）は、利用システム側で適宜判断して任意で適用するものであり、適用するCSP環境、あるいはガバメントクラウド全体の利便性やガバナンスの向上を目的としている。
• 詳細については、GCASアカウントを取得の上、GCASガイド（メンバー専用ページ）で公開されているガバメントクラウドテンプレート（メンバー専用ページ→ガバメントクラウドテンプレート/ポリシー→ガバメントクラウドテンプレート/ポリシーのダウンロードページ）を参照すること。

表 3‑1 テンプレート一覧

3.3.2 ユーザーの全体像

ガバメントクラウドでは、ガバメントクラウド利用組織からの利用申請の情報に基づき、デジタル庁より必要な数のシステムを稼働させるクラウド環境が払い出される。また、その環境を管理する管理者権限ユーザーが提供される。管理者権限ユーザーはシステムの運用責任者、運用リーダーに向けたもので、環境に対してのほとんどの権限を持つ。なお、管理者権限以外の各ユーザーアカウントは令和6年度より展開される、GCASアカウントによる各CSP環境へシングルサインオン機能の利用前後で以下の対応とする。

• シングルサインオン機能利用開始前
  • 管理者権限ユーザーが各CSP環境内でユーザーアカウントを作成する。
• シングルサインオン機能利用開始後
  • GCASアカウントによる各CSP環境へのシングルサインオンが可能になるため、各CSP環境内でユーザーアカウント作成は不要であり禁止する。

管理者権限ユーザーに付与される権限については、技術マニュアル「ユーザー管理方法」を参照すること。管理者権限ユーザーが侵害される可能性を減らすため、本番環境の管理者権限ユーザーの人数は3名までを推奨する。通常の運用時は、必要最小限の権限を付与したユーザーで実施する。
　

図 3‑2 ユーザーの全体像（国の行政機関）

図 3‑3 ユーザーの全体像（地方公共団体等）

3.3.3 ネットワークの全体像

ガバメントクラウドとして提供する複数のCSPと利用組織間のネットワークは国の行政機関と地方公共団体等で繋ぎ方が異なる。

国の行政機関においてはガバメントクラウドでの一般ユーザー・各府省拠点からの接続やシステム間連携の接続はセキュリティが十分担保された上でインターネット経由での接続を基本とし、同一CSP間のシステム連携は、CSPサービスの利用を検討すること。ただし、各府省拠点からの接続について、インターネット経由での接続を許容できない場合は、デジタル庁ガバメントソリューションサービス（以下GSSネットワークとする）経由での接続や専用線を用いた閉域網での接続を検討すること。利用組織共通で利用するサービスがガバメントクラウドで稼働する場合の拠点やデータセンタからの接続や、共通サービスへのガバメントクラウド上のシステムからの利用で使用する接続も提供される。

地方公共団体等においては「地方公共団体における情報セキュリティポリシーに関するガイドライン」に従い接続すること。詳細については、「地方公共団体情報システムガバメントクラウド移行に係る手順書」を参照すること。

接続に関する技術的な詳細や接続方法の選択フロー、システム間連携については、GCASアカウントを取得の上、GCASガイド(メンバー専用ページ)で公開されているドキュメントを参照すること。

3.4 体制

ガバメントクラウドの責任範囲に係る企画・立案、調達及びサービス提供は、デジタル庁が担当する。また、ガバメントクラウドに係る体制および連携は以下体制図の通りである。

図 3‑4 クラウドCoEによる各府省・地方公共団体支援体制

デジタル庁では以下を行う。

• デジタル庁(デジタル庁)から利用システムに対してクラウド利用料を調査した上で、クラウドサービスに係る予算要求及び調達を一括して行う。
• 全体管理アカウントを管理し、利用システムに対し、環境利用のためのアカウントや管理者用のアカウントを払い出すとともに、各利用システムのクラウド利用料を一括して支払う。
• 利用システムからのガバメントクラウド自体やそのテンプレートに関する問合せ対応、FAQの整備、ガバメントクラウド利用に関するドキュメント、利用システムの円滑な運用のサポートを提供する。
• クラウドCoE体制を通して、利用システムが行うクラウド環境移行作業（環境構築、ネットワーク接続、データ移行等）に関して支援を行う。
• ガバメントクラウドが推進するモダンアプリケーション化に向けて、企画段階を含む各工程における助言等支援を行う。

3.5 責任分界点

ガバメントクラウドの責任分界点はクラウドサービス事業者、デジタル庁、利用システムに分けられる。

デジタル庁の責任範囲はインフラ層に限定され、各プロジェクトのアプリケーションを中心としたプロダクト管理は利用システムの責任となる。

図 3‑5 責任分界点の全体像

3.5.1 情報資産の責任範囲

データ、アプリケーション、ソフトウェア、ハードウェアといった情報資産の観点から見た責任範囲のイメージは下図のとおり。各利用システムにて独自にクラウドサービスを調達する場合と同様に、CSPから提供されているIaaS、PaaS、SaaSを利用し、各CSPの責任共有モデルに応じて、利用システムの責任の下、システム稼働環境を設計・構築・運用する。ここで、ガバメントクラウドとしては、政府情報システムのモダンアプリケーション化推進の観点から、CSPが提供するマネージドサービス等の活用を積極的に推奨する。利用システムの要件により、やむを得ず持ち込みソフトウェア・ミドルウェアを利用する場合などは、クラウドサービスとの重複投資がないよう留意すること。

利用システムはクラウドサービスを直接利用できるため、クラウドサービス自体のサービスレベル（SL）は、各CSPが定めるSLAに準拠するものとする。クラウドサービス標準のSLAを参照しつつ、各システム自体の可用性や業務継続性の確保は、利用システムの責任において、十分に技術的対応策を検討する必要がある。ただし、止むを得ない場合については、大規模な天災等の不可抗力等と同様の扱いとすることを推奨する。

図 3‑6 情報資産の責任範囲

図 3‑7 可用性確保の責任範囲

3.5.2 セキュリティの責任範囲

各プロジェクトは、利用システムが必要とするセキュリティ水準の確保に向けて、必要なリスク分析やセキュリティ対策を設計し、クラウドのマネージドサービスを活用しながら実装する。ガバメントクラウドから提供する自動適用テンプレート、必須適用テンプレートは、クラウド設定に関するセキュリティ監視機能を提供するためこの実装に利用できる。

セキュリティインシデントのアラート監視や対応は利用システムの状況を把握する利用システムの運用組織が責任を持つ。デジタル庁では、共通的なリアルタイムでのセキュリティ監視は行わない。ただし、ガバメントクラウド全体としてセキュリティ状況を把握し、全体としてのセキュリティレベルの低下を防ぐため、各システムのセキュリティアラートは統計的に処理し利用する。

なお、セキュリティ水準を確保する上で基礎となる利用するクラウドサービス（IaaS、PaaS、SaaS）自体の保護は、前述のとおり、責任共有モデルの下、管理主体であるクラウドサービス事業者の責任範囲となる。

図 3‑8 セキュリティの責任範囲

4 特徴

4.1 クラウドサービスの一括調達

デジタル庁にて、クラウドサービス事業者と一括契約を行うことで、国の行政機関および地方公共団体等でのクラウド調達が不要になるため、クラウドサービス調達に必要な工数の削減に寄与する。

さらに、政府全体のバイイングパワーを発揮することで、例えば、クラウド標準サポートとしてより質の高いサポートを受けることが可能となるなど、有利な条件でクラウドサービスを利用することが可能となる。

また、クラウドサービス利用料の予算確保をデジタル庁にて一括で行うことで、全体的かつ一元的な管理を行うことが可能になる。

4.2 モダンアプリケーション化を支援

ガバメントクラウド利用の事前準備として、ガバメントクラウド利用組織が構築予定のアーキテクチャに関してモダンアプリケーション化が徹底されているかを精査し、ガバメントクラウドに構築する政府情報システムおよび地方公共団体情報システムは一定のモダンアプリケーション化を達成すること。

ガバメントクラウド利用組織はモダンアプリケーション化を実現する事で、クラウドサービス利用料削減や開発スピード向上、セキュリティ品質向上が可能となる。モダンアプリケーション化の実現において、SaaS利用は開発量の削減となるため強く推奨される。ただし、SaaS利用が無条件に推奨されるわけではない。利用者数の段階的な増加が見込まれる場合等、運用段階でSaaS利用料が高額となるケースもあるため、ライフサイクルコストの観点から真にコスト削減効果が発現するかを慎重に評価する必要がある。例えば、SaaSと同様の機能をマネージドサービスで実現することが可能であれば、ライフサイクルコストの観点から両方式を比較して十分に評価すべきである。

さらに、任意で利用可能なIaCでのモダンアプリケーションサンプルテンプレートの提供を行っているため、ガバメントクラウド利用組織はモダンアーキテクチャの設計・構築工数を大幅に削減することが可能となる。

サンプルテンプレートは最新技術の動向に合わせて追加、更新を行う方針である。

※サンプルテンプレートで構築したインフラの運用はガバメントクラウド利用組織の責務となるため、サンプルテンプレートの内容を理解したうえで利用すること。

図 4‑1 サンプルテンプレートの例

4.3 ベースラインのセキュリティを担保

ガバメントクラウド利用組織は、払い出された環境に対しての必須作業である必須適用テンプレートを適用する事で、クラウド利用に最適化されたベースラインのセキュリティ設定を行うことが可能となる。

デジタル庁が適用する自動適用テンプレートと利用組織が適用する必須適用テンプレートによる設定は予防的統制と発見的統制に分類される。

1. 予防的統制：不正な操作を事前に防止

• セキュリティや監査ログの収集に関するサービスの削除防止
• 管理者用及び作業者用ユーザーアカウントのログイン時にMFAを強制
• リージョナルサービスにおける東京/大阪リージョン以外の使用禁止、未有効化リージョンの有効化禁止
• セキュリティ上問題となりやすいサービスの禁止

2. 発見的統制：管理リソースのモニタリング及び不正の検出
   アカウント保護、ストレージ保護、セキュリティ監視、ログ管理、鍵保護、データ暗号化、攻撃対策等に関するクラウドサービスの有効化による管理リソースのモニタリング及び不正の検出

4.4 拠点とのネットワーク接続をパターン化

各府省拠点および一般ユーザーからガバメントクラウド利用システムへの接続に当たっては、インターネットを経由する接続、GSSネットワークを経由する接続（各府省又は拠点からの接続に限る）、専用線を用いた閉域網を経由する接続が選択可能である。

各接続方法における留意事項と作業分担を①～③に記す。

①インターネット経由での接続
ガバメントクラウドでの各種接続はインターネット経由での接続を基本とする。
インターネット経由での接続に際しては、ゼロトラストの原則とCSPが提供する各種提供サービスを利用して安全でスケーラブルなアーキテクチャを構築することを推奨する。
特に保守拠点からのガバメントクラウドのCSPの管理GUIへの接続については、一般的なガイドラインに準拠しセキュリティを担保すること。
接続に係る設計や設定は、利用システム（PJMO）が実施する。接続に係るCSPのクラウド利用料については、利用システム（PJMO）が見積り、GCASシステム情報登録のクラウド利用料の試算に含めて入力する。

②GSSネットワーク経由での接続
各府省拠点とGSSネットワーク経由でのガバメントクラウド接続は、GSS LAN、府省独自LAN、府省共通システムの接続パターンが選択可能である。利用システムは、各府省のネットワーク管理担当や各府省クラウドCoEに確認の上、接続パターンを適切に選択すること。
利用システム環境側で接続に必要となるサービスのクラウド利用料は、利用システム（PJMO）が見積り、GCASシステム情報登録のクラウド利用料の試算に含めて入力する。詳細については、「表 4-2 接続に係る役割分担」を参照すること。

③専用線を用いた閉域網での接続
CSPの提供する専用線サービスを使用すると、オンプレミスネットワークから同じリージョン内の1つ以上のVPCへの専用接続を確立し、インターネットを経由しないプライベート接続が可能になる。CSPの提供する専用線サービスを用いた閉域網での接続を必要とするかについては、コストやセキュリティの要件に応じて、各システムにて適切に選択すること。
接続に係る設計や構築は、各府省のネットワーク管理担当や各府省クラウドCoEに相談の上、利用システム（PJMO）が実施する。接続に係るCSPのクラウド利用料については、利用システム（PJMO）が見積り、GCASシステム情報登録のクラウド利用料の試算に含めて入力する。ただし、クラウド利用料以外の物理結線等に係る費用は、利用システムが個別に予算要求を行う。

• 保守環境での接続
  保守環境として各府省の保守拠点から各利用システムとの接続を行う際は、原則インターネットを経由した接続を利用する。安定的な専用ネットワーク帯域が必要である場合はGSSネットワーク経由での接続や専用線を用いた閉域網での接続を検討すること。各接続方法は下表の記載箇所を参照すること。

表 4‑1 接続方法の参照箇所

• 利用システム間の連携
  利用システム間の連携に当たっては、インターネットを経由する接続、GSSネットワークを経由する接続、専用線を用いた閉域網を経由する接続、CSPサービスを利用した接続が選択可能である。
  CSPサービスを利用した接続を含めた技術的な詳細等について、GCASアカウントを取得の上、GCASガイド(メンバー専用ページ)で公開されているドキュメントを参照すること。
  接続に係る設計や構築の主管、CSPのクラウド利用料の見積り分担について、下表に示す。利用システム（PJMO）においては、各府省のネットワーク管理組織や各府省クラウドCoEに相談した上で実施すること。

表 4‑2 接続に係る役割分担

なお、ガバメントクラウドとしては、GSSネットワークとの接続に特段の制限は予定していない。各クラウドサービスの上限値やGSSネットワーク等の制約（使用可能な帯域等）の範囲内での運用となる。

4.5 改善活動に向けたデータの可視化

ガバメントクラウド利用組織は、利用するCSPが提供するシステムメトリクス監視機能や、データ可視化機能を使って、自システム状況の可視化を実現できる。デジタル庁では、ガバメントクラウド全体管理の観点から、各システムのビジネスメトリクス、アラーム、主要システムメトリクス、ログ、コスト、セキュリティアラート等を統計的に処理しダッシュボードにてデータの可視化を実施する。ガバメントクラウドからこのうちの一部機能をサンプルテンプレートとして利用システムに提供する。このテンプレートは、いわゆる「システム運用」ではなく「サービス運用」を目指した定量的可視化を行うことを目的としている。システム運用者・システム提供者向けの運用ダッシュボードではなく、システム利用者に最適なサービスを提供し、改善し続けるためのダッシュボードである。「システムがどのような状態にあるのか」を把握するのはもちろん重要であるが、それ以上に「ユーザーにどのような利益や影響を与えていて、どう改善すべきか」を中心に考えるように設計されている。

これによりガバメントクラウド利用組織はコスト・セキュリティ・事業計画などの面でデータの可視化の実装を容易に実現でき、改善活動を推進することが可能となる。

可視化するデータの詳細は検討中のため、仕様が確定次第本書を更新予定である。

図 4‑2 可視化するデータのイメージ

5 制限・制約

5.1 アカウントのポリシー設定

ガバメントクラウド利用組織に払い出すアカウントはガバナンス・セキュリティに係るポリシーが設定されており、ガバメントクラウド利用組織はこの設定を変更することはできない。

主な設定内容は、各CSPの「ガバメントクラウド利用概要」を参照すること。

5.2 必須適用テンプレートの適用

ガバメントクラウド利用組織は払い出されたすべてのアカウントに対して、ガバナンス・セキュリティに係るIaCで記述された必須適用テンプレートを適用する必要がある。詳細については、GCASアカウントを取得の上、GCASガイド（メンバー専用ページ）で公開されているドキュメントを参照すること。

なお必須適用テンプレートが更新された際は、ガバメントクラウド利用組織の検証環境にて影響を確認後、本番環境に反映する必要がある。

主な設定内容は、「5.1 アカウントのポリシー設定」で記述した設定内容に含まれる。

5.3 インフラのIaC化

インフラの構築、変更はIaCにて行うことを原則とし、Webブラウザからログインする管理コンソールは参照時のみの利用を原則とする。自動適用テンプレート、必須適用テンプレートの適用においてIaCは必須となるが、サンプルテンプレートの適用も含め、その他の部分でのIaCは強く推奨されるが必須とはしない。

5.4 利用可能なリージョン

原則、日本国内のリージョンのみ利用可能である。

5.5 恒常的なアーキテクチャ見直し

ガバメントクラウド利用組織は、クラウドサービスの利用料が毎月変動するため、恒常的に適切なサイジングとなっているかを見直し、必要であれば適切なサイズや数に変更を行う。また、常に稼働する必要のないものは必要なときだけ起動する等の改善も行う。

年度毎にアーキテクチャの見直し及びコスト試算を行い、モダンアーキテクチャ化の推進やコスト削減を図る必要がある。

見直したコスト試算はデジタル庁にて確認、承認を行う。

5.6 地方公共団体等における制限・制約

地方公共団体等においては地方公共団体向けルールに準拠するため、地方公共団体等が本番相当環境の管理コンソールにインターネット経由で接続する場合に利用可能な機能を制限する予定である。 例えば、インターネット経由で管理コンソールから直接のデータ参照や一部のサービスや機能の利用制限を予定している。

6 必須検討事項

6.1 モダンアプリケーション化

ガバメントクラウド利用組織は旧来のアーキテクチャを単純移行するに留まらず、マネージドサービスやコンテナ、サーバレス、マイクロサービスなどを活用してモダンアプリケーション化を検討すること。モダンアプリケーション化の検討において、SaaS利用は開発量の削減に繋がるため強く推奨される。ただし、SaaS利用が無条件に推奨されるわけではない。利用者数の段階的な増加が見込まれる場合等、運用段階でSaaS利用料が高額となるケースもあるため、ライフサイクルコストの観点から真にコスト削減効果が発現するかを慎重に評価する必要がある。例えば、SaaSと同様の機能をマネージドサービスで実現することが可能であれば、ライフサイクルコストの観点から両方式を比較して十分に評価すべきである。

移行パターンについて、ガバメントクラウドでは「図 6‑1 ガバメントクラウドへの移行パターン」を想定しており、このうちRebuildをモダンアプリケーションと考え、Replatformは２段階移行における第一段階としての一時的なものと考える。

また、ガバメントクラウドへの移行時にはR1(Replatform)、R2(Rebuild)ともに、シンクラ、VDI、DaaSは原則として使用しないものとする。特にガバメントクラウド上でのVDI構成やDaaSの利用は行わない。シンクラ、VDI、DaaSを必要としないセキュリティ対策を行い、クラサバ方式やクライアント上のアプリやデータに依存する方式はWebシステム（フロントエンド・バックエンド分離型）に変更することを前提とする。但し、以下については例外とする。

＜例外１＞
組織内の既存の標準端末がシンクラ、VDI、DaaSであり、標準端末からガバメントクラウド上の利用システムを使う場合。

＜例外２＞
モダン化されることが予定されているが、それまでの間にオンプレミスで構築したVDI環境等の継続が困難であり、ガバメントクラウド上のDaaSを暫定的に使用することが合理的とガバメントクラウド管理組織で評価される場合。

＜例外３＞
クラサバ等によるPC内のデータ保護が目的ではなく、サービス利用、サービス連携等の手段としてVDI、DaaSの利用がCSPから推奨されており、他に技術的な選択肢がない場合。

図 6‑1 ガバメントクラウドへの移行パターン

6.1.1 バッチ処理のモダン化

クラウド移行により、システムリソースの制約からの解放やマネージドサービスの活用によって、以下の効果が期待できるため、従来のバッチ処理の在り方を再考すること。

• コスト削減
  • クラウドではオンデマンドでのリソース確保が可能となり、バッチ処理用のシステムリソースを常時確保する必要がなくなるため、コスト削減が可能
  • 高額なバッチ処理管理用のミドルウェアからクラウドのマネージドサービスに変更することでコスト削減が可能
• サービス提供価値の向上
  • システムリソース制約の解放やイベントドリブン型への変更を通じて、バッチ処理タイミングの見直しを行うことにより、利用者や関連システムへの情報連携、情報提供の間隔を短縮することが可能となり、サービス提供価値を向上することが可能
• 作業工数の削減
  • バッチ処理のタイミングに応じた運用業務を見直すことで、通常業務時間外の運用の削減が可能
  • 各種マネージドサービスを活用し、自動化を推進することで作業工数を削減することが可能

利用組織はクラウド移行による制限の解放（ストレージ容量、物理サーバ、ミドルウェアの機能、外部システム連携など）の観点でバッチ処理の在り方を見直し、クラウドに最適化されたバッチ処理を検討すること。

図 6‑2 バッチ処理の見直しとクラウド最適化

6.1.2 システム間連携のモダン化

クラウドネイティブ化が進む中で、複数のシステムを連携し、迅速に業務処理を遂行することが求められるケースが少なくない。そこで、データ/処理/アプリケーションの連携を考慮しつつシステムの統合や連携を図る必要性がある。システム間連携を行うことで業務スピードの向上、業務正確性の向上、データ統合による全容の可視化、データ管理のコストの削減といったメリットを期待できる。従来の基本的なシステム連携のパターンとしては、ファイル転送、ディスク共有、データベース共有、RPCやWebサービスなどのアプリケーション連携、メッセージングなどであるが、これらの連携方法のアーキテクチャは互いのシステムの依存関係が強く密結合しているケースが多く、1つのシステムの障害や変更の影響が全体に及びやすい。そのため比較的規模の小さいシステム間の連携に向いている。一方でガバメントクラウドにおいてはモダン化の観点からAPI連携の使用を推奨する。

6.1.3 運用監視のマネージドサービス化

モダン化の第一段階として、運用監視のマネージドサービス化は必須となる。まずは、運用監視においては、ログベースアラートや通知設定で運用監視を自動化し、ジョブ管理においては、CSPから提供されるマネージドサービスの利用を検討すること。

なお、時間がなく改修費用を賄えない場合等（ただし、次期更改時のマネージド化は必須）については、少なくとも、監視やログ収集、バックアップといった運用監視はマネージドサービスを利用した上で、ジョブ管理においては、AWSであればEC2を利用したジョブ管理サーバを構築することは可能である。この場合もジョブ管理以外の監視はマネージドサービスを活用すること。

6.1.4 移行パターンR2でのアーキテクチャ見直し

移行パターンR2（Rebuild）ではアプリケーションを変更しクラウドサービスをフル活用したアーキテクチャとして、2つの基本形と例外形を定義しており、それぞれのアーキテクチャにおける検討事項を示す。
なお、移行パターンR2におけるコンピュートサービスはサーバレス、コンテナを用いることを前提としている。
加えて、このR2のアーキテクチャを採った場合でも、クラウドの柔軟性を活かし、定期的にシステムのスコープ見直しや技術進歩に伴う改修、BPR等を行い、システムの統廃合やSaaS・共通機能の利用を検討すること。

（１） 基本形1（マイクロサービスアーキテクチャ）
マイクロサービスとは、対象となるアプリケーションをコンポーネント分割して開発を行うアプローチやアーキテクチャを指し、システムをマイクロサービスアーキテクチャへ移行することによって以下のような利点が得られる。

従来システムアーキテクチャではリリースに係る調整コストがシステムメンテナンスに係る人件費の増加要因のひとつであったが、マイクロサービスアーキテクチャを採用することにより、コンポーネントごとのチーム組織やデプロイとなるためリリースに係る調整コストの低減も期待できる。

• マイクロサービスアーキテクチャの基準
  システム企画を進めるうえで、マイクロサービスアーキテクチャであるかどうかについて一定の仮定を置き検討することが必要と想定される。そのため、便宜のため、以下に基準を示す。

図 6‑3 マイクロサービスアーキテクチャ構成例と基準マッピング

（２） 基本形2（フロントエンド・バックエンド分離）
フロントエンド・バックエンド分離型Webシステムは、ユーザーインターフェース（フロントエンド）とデータ処理やサーバーサイドロジック（バックエンド）が明確に分離されているアーキテクチャのことを指し、分離することによって以下のような利点が得られる。

図 6‑4 フロントエンド・バックエンド分離構成例

また、複数の異なるシステムやサービスに対して共通機能や蓄積データを提供するシステム（一般的にAPI連携基盤、認証基盤、データ連携基盤、分析統計・データレイクシステムと称されるシステムを念頭に置く）は、必ずしもユーザーへ提供する業務機能や業務画面を有しているわけでなく、かつ必ずしもマイクロサービスアーキテクチャが相応しいとは限らない。
このようなシステムであっても、管理用の画面や機能などのフロントエンドがある場合においては、R2基本形1・2に沿った実装を行うこと。
管理用の画面や機能などのフロントエンドを全く有さず、かつ、マイクロサービスアーキテクチャが適さない場合においても、R2基本形2のバックエンド部分に準じた構成を行うこと。その際、バックエンドは適切な粒度まで機能分割をすること。

（３） 例外
R2例外1は以下状態のシステムを念頭に置く。

• 統廃合やSaaS利用、共通機能の利用へ切り替えなどによって将来的に廃止となるシステム
• 将来のアプリケーション改修を経てR2基本形となるシステム

また、システム企画を進めるうえで、R2例外1の「長期塩漬けシステム」や「今後の運用コストが極小のシステム」かどうかについては一定の仮定を置き検討することが必要と想定され、便宜のため以下に基準を示す。なお、政府情報システムを念頭に置いた記載となる。

図 6‑5 R2例外1 基準

6.2 データの可視化

ガバメントクラウド利用組織は利用システムの成功を判断するために、KPIの達成状況を計測・追跡するためのデータの可視化を検討すること。

利用システムとして成功しているかどうかの基準を数字で定義表現し、その数字を計測できるよう元となるデータを収集・加工・可視化を行う。たとえば、実際の利用者が増えることがそのシステムの成功とする場合、毎日の利用ユーザー数が増えていくことを数字で表現することを考え、その日ログインしたユニークユーザー数をアクセスログの収集・分析して算出し、グラフとして可視化する。毎日もしくは週次の運用でこのグラフを確認し、必要に応じて改善策等を検討する。

日次のユニークユーザー数というKPIはデジタル庁にも共有し、デジタル庁としてもシステムごとのKPIの数値を収集し、ガバメントクラウド全体での統計的分析に利用する。KPI情報の共有方法については別途定義し、GCASの運用に伴い順次整備を進めていく。

図 6‑6 データの集約と閲覧

データの可視化はオンプレミスの常識に囚われずに以下のような観点で抜本的に見直すこと。

• サービス／アプリケーションとしてのKPIとコストを監視する
• 不必要なアラートを発砲しないため、インフラの監視は原則実施しない
  • サービス／アプリケーションとして監視する
• 1ヶ月遅れの状況を見ても意味がないため、Word/Excelで月次運用報告書を作らない
  • 準リアルタイムに状況を可視化するダッシュボードを用意する
• 運用監視要員の貼り付け（常駐）を前提としない
  • 手順化できるものは自動化できるため、すべての監視とその対応を人間不要の自動化する
• Word/Excelの月次報告書を成果物や納品物として定義しない
  • 報告する側と報告を受けるだけの側に役割を固定せず、ダッシュボードで一緒に監視していく
  • 監視項目や可視化は運用中つねに相談しながら見直していく
  • 報告書が不可欠の場合は、ダッシュボードを報告書として整理する

可視化したデータを運用監視に活用する際は表 6‑1のようなオンプレミスとスマートなクラウド利用の違いを意識して活用すること。

表 6‑1 運用監視に関するオンプレミスとスマートなクラウド利用の違い

なお、データの可視化に関しては、定量的計測サンプルテンプレートの提供を予定している。

6.3 クラウドに適したディザスタリカバリ環境

クラウドのディザスタリカバリ（以下DRと称す）環境は、オンプレのような本番環境と同環境を用意する考え方と違い、データコピーの容易性、環境構築の俊敏性、リソースの柔軟性等、クラウドの特徴を活用し検討することに加え、DR環境のリージョンで利用できるサービスに不足がないことを確認しながら設計することが必要となる。また、関東圏全域といったリージョン全域にわたる大規模災害（以下大規模災害とする）への対策を想定するか否かもシステムアーキテクチャ、システム構成、及びコストに大きな影響を与えるために重要な要素となる。

ガバメントクラウドでは4つのDRパターンを定義しており、基本的にはこのパターンに従い、コスト効果の高いパターンを選択する。4つのDRパターンは、図6-7のとおり、
・(1)大規模災害を想定しないが、コスト効果が高く冗長性を担保したマルチゾーンパターン
・(2)大規模災害を想定し、データをクラウドの機能で遠隔保管することで発災時もデータを保護できコスト効果の高いバックアップパターン
・(3)コストはかかるものの災対リージョンでは縮小構成を保持しておき被災時には災対リージョンで稼働を続けるウォームスタンバイパターン
・(4)コストをかけてでも被災時にサービスを変わらず継続する必要のあるアクティブ-アクティブパターンである。

職員向けシステムや、一部領域や地域の国民向けサービスは、基本的にパターン(1)か(2)になり、広く国民向けサービスのうち、停止すると国民生活に影響のあるもののみ(3)か(4)を検討することになると想定する。

なお、各CSPにおける具体的な実装方式は、各CPSマニュアルを参照すること。

図 6‑7 DR環境の構成パターン

ただし、システムの複雑化と高コスト化の要因となるため、パブリッククラウドが全面的に利用不能となるレベルの災害を想定する場合を除き、オンプレミスを災害対策用に利用することは避けることとする。

6.4 クラウドに適したバックアップ

オンプレミスではアーカイブ、レプリケーション、世代管理などをバックアップソフトウェアやジョブ、運用で実現するケースが多かったが、クラウドではマネージドサービスを活用することで、バックアップに係る機能を容易に実現できるため、コスト削減（バックアップソフトウェアが不要になる、余分なストレージ容量が不要になるなど）や作業工数の削減が期待できる。

なおCSPが公表している耐久性などのSLAは、満たされなくても返金処理されるだけとなり、消失したデータが復旧する訳ではないため留意すること。

図 6‑8 バックアップ要件毎の実現例

6.5 ハイブリッド構成について

クラウドとオンプレミスを組み合わせてデータを処理・保存する利用形態（ハイブリッド構成）については、オンプレミスからクラウドへの移行期、データの多重バックアップ、ネットワーク遅延が許容できない場合を除き、システムの複雑化と高コスト化の要因となるため、その適用を避けることとする。各構成の詳細を①～③に示す。

① オンプレミスからクラウドへの移行期
未移行部分がオンプレミス、移行済み部分はクラウドとなる、段階的にガバメントクラウドへ移行するような構成を指す。

② データの多重バックアップ
ガバメントクラウド上のデータをオンプレミスへバックアップするような構成を指す。

③ ネットワーク遅延が許容できない場合
ネットワーク遅延が許容されない部分はオンプレミス、それ以外の部分はガバメントクラウドを利用するような構成を指す。

さらに、主たる環境として利用するIaaS/PaaSのCSPを複数とするマルチクラウドはコストが増大することが多いため、真に必要性がある場合を除いては避けることとする。 上記を踏まえ、ガバメントクラウドにおけるハイブリッド構成の許容方針を図6-9に示す。

図 6‑9 ガバメントクラウドにおけるハイブリッド構成の許容方針

7 調達

7.1 概要

ガバメントクラウドを利用する政府情報システムは、利用に向けた各種作業の手戻り等が生じないよう、主に以下の点に留意の上、調達（クラウド環境構築・移行を含むシステム設計・開発等作業に係る調達）準備を進める必要がある。政府情報システムは、「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」に準拠した開発を行うことを調達仕様書に明記する必要がある。地方公共団体情報システムについては、調達仕様書に記載することを推奨する。

なお本ドキュメントにおいては、ｎ年度にガバメントクラウドを利用するシステムが、ｎ年度に上記調達事業者を必要とする前提で記載するが、必要に応じてn-1年度、n-2年度に調達を行うことも検討する。

図 7‑1 ガバメントクラウド利用における全体の流れ

7.1.1 ガバメントクラウドにおけるサービスレベルの考え方

ガバメントクラウドは、利用システムに対し、クラウド基盤上において共通的な機能・サービスを独自に定義し提供することや、利用に当たって特段の制約等を課すことは想定していない。

クラウドサービス自体のサービスレベル（SL）は、各CSPが定めるSLAに準拠するものとする。クラウドサービス標準のSLAを参照しつつ、各システム自体の可用性や業務継続性の確保は、利用システムの責任において、十分に技術的対応策を検討する必要がある。ただし、止むを得ない場合については、大規模な天災等の不可抗力等と同様の扱いとすることを推奨する。

CSPが定めるSLA未達時における、CSPとの支払い、返金対応については、デジタル庁にてCSPとの契約に従い管理するため、利用システムの調達仕様書では当該記載は不要とする。

7.1.2 ガバメントクラウドテンプレートの適用に向けた取組

ガバメントクラウドでは、ガバメントクラウドテンプレート（「表 3‑1 テンプレート一覧」参照）の提供を通じて、利用システムの環境構築・運用の自動化・効率化や、情報セキュリティ水準の向上を図ることとしている。

ガバメントクラウドテンプレートを活用し、インフラ環境の構築・保守のコード化（IaC化）を行うことで、業務や環境の変化への迅速かつ柔軟な対応が可能となるため、人海戦術的なインフラ構築作業や維持管理コストの高止まりといった状況からの脱却を図ることができる、といった効果が期待される。そのため、調達仕様書においては、IaCに基づくシステム構築・管理等の経験や知識を有する要員を求めるとともに、ガバメントクラウドテンプレートの適用を要件として示しつつ、テンプレート適用に向けた作業やそれを可能とする体制や実績を要件とすることなどを検討すること。

7.1.3 事業者に求める実績、スキル、役務等

ガバメントクラウドでは、原則としてクラウド基盤上に独自の機能・ソフトウェアを開発・提供することは行わない。そのため、ガバメントクラウド上のシステム構築・移行に係る役務の内容は、各府省で独自にパブリッククラウドを利用する場合の役務内容と基本的には同様である。

なお、ガバメントクラウド上のシステム構築・移行に際し、以下のような点に留意する必要がある。

(1) 事業者に求める実績、スキル等

クラウド移行を円滑に進め、クラウドサービスのメリットを最大限享受できるようなシステムとできるよう、事業者への要求事項として、クラウドサービスの導入・運用等に関する知見や実績を要件とすることが有効である。

ガバメントクラウドにおいては、デジタル庁が提供するテンプレートをもとにシステム構築等を行うこととなるため、クラウドテンプレートやIaCに基づくシステム構築・管理等に関する理解も求められる。

以上のような点を担保するため、実際にプロジェクトに参画する要員について、利用を想定するCSPの上級クラウド認定資格の保有を要件とすることが必須である。IaCでクラウドインフラを開発運用するスキルが求められる。その上で、その他どういうスキルを要求するか、どの程度の上級クラウド認定資格数を要求するかは利用システムの特性に応じてPJMOで個別に検討すること。

(2) 想定するクラウドサービス利用内容を念頭に置いた調達仕様書の記載・クラウド利用料のモニタリングに関する役務の明示

調達仕様書については、ガバメントクラウドにおいて利用を想定しているクラウドサービスを念頭に置いた記載とし、GCASシステム情報登録におけるクラウド利用料の試算前提と整合性の取れた記載とする必要がある。

また、GCASシステム情報登録に入力したクラウド利用料の範囲内で各利用システムにおいて申請した予算額を超過しないよう監視と管理をし、利用状況に応じたサイジングやアーキテクチャの見直しにより利用料をより削減していく努力を行う必要があるため、事業者の役務として、PJMOから提示されたクラウド利用料の範囲内に収まるようサービス利用実績についてモニタリングを行うこと、恒常的に利用状況やKPI指標をモニタリングしながらサイジングやアーキテクチャを見直し利用料削減策についてPJMOと協議すること等を明記することが望ましい。

7.1.4 その他ガバメントクラウド利用の検討に当たり留意すべき事項

(1) ガバメントクラウドの利用対象

政府情報システムにおいては「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」の適用対象となるシステムが、ガバメントクラウドの利用対象となる。一般会計のうち特定財源や特別会計で運用されるシステムについては、クラウド利用料の支払いにおいて支出委任が必要となるため、個別に相談されたい。

独立行政法人のシステムについては、個別に相談されたい。

地方公共団体情報システムについては「地方公共団体情報システム標準化基本方針」及び「地方公共団体情報システムのガバメントクラウドの利用に関する基準」の適用対象となるシステムが、ガバメントクラウドの利用対象となる。

(2) クラウドサービスの導入実績等を有する事業者への見積もりの協力依頼

クラウド環境構築を含む設計・開発調達に向けた概算要求額の積算に当たっては、既存システムがある場合、既存システムの事業者を中心に見積もりの協力依頼を行うものと見込まれるが、特にオンプレミス環境で稼働するシステムの運用・保守を行う当該事業者は、必ずしもクラウドサービスの取扱いに明るいわけではないことも想定される。そのため、利用を予定するクラウドサービスの導入実績、上級クラウド認定資格の取得状況、トレーニング受講状況等を確認し、当該事業者において求める要員を確保することが明らかに見込めないといった場合においては、利用を予定するクラウドサービス導入支援の実績を有する新規事業者への積極的な働きかけや情報提供依頼を行い見積もりに協力いただくこと。

8 利用の全体の流れ

8.1 利用の流れ

ガバメントクラウドの利用を検討しているシステムの管理者およびその委託を受けている事業者は、まずGCAS（オンボーディングツール）へユーザー登録を行う。GCAS（オンボーディングツール）は、ガバメントクラウドの各種ガイドを参照できる他、利用申請や問い合わせを行うためのサービスとして、ガバメントクラウドより提供される。

ガバメントクラウド利用組織は、各システムの予算取りのタイミングで、GCASシステム情報登録へ、CSP見積もりツールの見積もり結果もしくはそのリンク、アーキテクチャ構成その他のガバメントクラウドの利用前提確認に必要な情報を登録する。

開発構築事業者の調達の段階では、予算要求時からCSP見積もりやアーキテクチャ構成その他情報の更新を必要に応じて実施する。

開発構築プロジェクト実行段階では、GCASシステム情報登録を最終化し、必要な環境の払い出し申請を行う。払い出された環境でガバメントクラウドからガイドされる初期設定を実施し、その後その環境にてシステム構築を行う。

システム運用段階では、各種ダッシュボードを活用しながら、サービスのサイズや利用の最適化を行い、中長期的にはアーキテクチャ変更も含めて最適化していく。

GCASの利用にはインターネット接続が必須である。なお、GCASを利用するに当たり、GCASの整備、運用管理、サービス提供、利用及び調整に関する必要な事項については、GCASアカウントを取得の上、GCASガイド(メンバー専用ページ)で公開されているドキュメントを参照すること。

図 8‑1 利用の流れ

8.2 ユーザー登録

GCAS（オンボーディングツール）の利用開始の手続きとして、GCAS利用者本人が利用申請と初期設定を行う。GCASの利用にはインターネット接続が必須である。
なお、事業者は各府省庁又は地方公共団体等との間で守秘義務契約を締結した後に申請が可能となる。
GCASアカウントに紐づく情報の変更がある場合にも本項の記載に準じて行うこと。
アカウントの管理は利用システム単位で管理者が行い、定期的に棚卸を行うこと。異動等に伴うアカウント削除、権限の変更等の手続きについては、GCASアカウント取得後、GCASガイド(メンバー専用ページ)で公開されているドキュメントを参照すること。

(1) 利用申請

利用者本人が、GCAS機能を利用し、GCASアカウントの利用申請を行う。利用申請の際に、認証アプリケーションをインストールしたスマートフォンを使用してマイナンバーカードによる本人確認を行う必要がある。スマートフォンが認証アプリケーションに対応していない等により、認証アプリケーションを利用できない場合は、PC上で「デジタル庁GPKI電子署名アプリ」を用いて本人確認を行うこと。「デジタル庁GPKI電子署名アプリ」について、不明な点等がある場合、必ずガバメントクラウドチームまで問合せを実施すること。
なお、利用機関GCAS責任者が申請する場合は、マイナンバーカードによる本人確認に加えて、職責の確認のため、ガバメントクラウドチームが用意する電子署名を付与した所定の様式の添付が必要となる。申請後、承認者により申請が承認されるとGCASアカウントが発行され、申請者にGCASアカウント情報がメールで通知される。
国の行政機関と、地方公共団体等における詳細なGCASアカウント申請方法と所定の様式については、GCASガイド(メンバー専用ページ)で公開されているドキュメントを参照すること。

なお、利用申請の際に登録した職場メールアドレスは、今後GCASアカウントに紐づくメールのやり取りに利用されるため、常用されるものを選択すること。なお、GCASアカウント自体（Googleアカウント自体）が保有するGメールアドレス・Gメール機能はセキュリティの観点より利用を制限している。

(2) 初期設定

利用申請の承認後、利用者本人にアカウント発行通知が送付されるので、通知に記載されているアカウント情報をもとに初期パスワードの変更と多要素認証の設定を実施する。GCASのアカウント払い出し後の具体的な初期設定手順については、「(3) GCAS認証方法」を参照。アカウント払い出し後、2週間以内に多要素認証を設定しなければ、GCASアカウントが自動でロックされる。多要素認証の未設定によるGCASアカウントロックの解除手順については、「(4) 2段階認証ロックの解除方法」を参照。ログインできない、パスワードロック等、不具合があればガバメントクラウド管理組織から指定される所定の連絡先へ問合せを行うこと。

(3) GCAS認証方法

GCASのアカウント払い出し後の具体的な初期設定手順を解説する。

• ユーザー登録が完了次第、各アカウントのIDと初期パスワードが発行される。
• 利用者は、ブラウザから https://www.google.com/open_in_newOpens in new tab へアクセスし、「ログイン」をクリックすることで、Googleアカウントへのログインが行える。初回ログイン時には、初期パスワードを任意のパスワードに変更する。
• ログイン成功後、ブラウザから https://myaccount.google.com/open_in_newOpens in new tab へアクセスし、Googleマイアカウント画面を開く。個人所有のGoogleアカウント等ではなく、GCASのGoogleアカウントでログインできていることを確認する。
• IDとパスワードに加えて多要素認証を実現するため、Googleアカウント＞セキュリティをクリックし2段階認証プロセスの有効化ページへ遷移する(図 8‑2)。「2段階認証プロセスを有効にする」はこの時点では選択しない(電話番号の登録が求められるため。電話番号登録のリスクは後述する)。

図 8‑2 2段階認証プロセスの有効化ページ

　

• 2段階認証プロセス設定画面の「2つ目の手順」において、GCASにおける管理者権限の保有者または本番相当環境アクセス者は「パスキーとセキュリティキー」を選択し、セキュリティキーの設定を行う。それ以外の利用者は「認証システム」、「Googleからのメッセージ」または「パスキーとセキュリティキー」を選択可能である。
• 「パスキーとセキュリティキー」の登録では、事前に調達したFIDO規格対応のハードウェアトークンを利用する（ガバメントクラウドでは端末の特定が困難なパスキーの利用を禁止する）。なお、ハードウェアトークンは第三者が入手・悪用できないよう、適切に管理する。以降の手順はGoogle社の画面仕様の変更に依存して表示内容や手順が変わる可能性があるため参考情報とすること。前述の通り「パスキーとセキュリティキー」を選択後、遷移した画面でUSBポートにハードウェアトークンを挿しこみ、ボタンまたは金色のディスク部分をタップする(図8‑3)。

　

図 8‑3 パスキーとセキュリティキーの設定画面

　

• セキュリティキーへのアクセスの許可が求められるため「許可する」を選択する(図8-4)。セキュリティキーへのアクセス許可後、2段階認証プロセスの有効化が求められるため、「続行」を選択する(図8-5)。2段階認証プロセスは、図8-2の画面上で「2段階認証プロセスを有効化する」を選択して有効化する。有効化後、図8-6の画面」が表示される。

　

図 8-4 パスキーとセキュリティキーの設定画面

図 8-5 2段階認証プロセスの有効化を求める画面

図 8-6 2段階認証プロセスの有効化後の画面

　

• 2段階認証プロセスでは、さらに次に挙げる追加の認証方式を設定可能である。パスワードを紛失した場合に備えて、複数の認証方式の設定を推奨する（GCASにおける管理者権限の保有者または本番相当環境アクセス者を除く）。
  • 認証システム（スマートフォンにおいてGoogle Authenticatorアプリなどを利用する方式）
  • Googleからのメッセージ
  • バックアップコード
  • 電話番号
• 「認証システム」は、スマートフォンにおいてGoogle Authenticatorアプリなどを利用する方式である。他の方式より簡便に利用可能である。
• 「Googleからのメッセージ」は、利用者のAndroidスマートフォン上でGCASのGoogleアカウントへのログインまたはiPhone上でGoogle社提供のアプリを利用して同アカウントへのログインすることで、以後、GCAS用のGoogleアカウントへのログイン時にメッセージが通知され、スマートフォン上で要求されるログイン許可操作を2要素目の認証として利用する方式である。この設定のために、事前にスマートフォン上でGCASのGoogleアカウントを利用してログインを済ませておく。「Googleからのメッセージ」をクリック後、ログイン操作を行ったスマートフォンの型式が表示される。「続行」をクリックし登録する。iPhone上で利用可能なアプリは以下の通りだが、複数のアカウントを管理可能なSmart Lock アプリを推奨する。
  • Smart Lock アプリ、Gmail アプリ、Google フォト アプリ 写真、YouTube アプリ
• 「認証システム」や「Googleからのメッセージ」の設定後、2段階認証プロセスを有効にしていない場合は有効化を求める確認画面が表示されるので、図8-2の画面上で「2段階認証プロセスを有効化する」を選択して有効化する。この2段階認証プロセスの設定をもって、GCASのユーザー認証とする。
• なお、「電話番号の設定」が可能だが、ガバメントクラウドではSIMスワッピングなど昨今のSMS認証（設定画面では「コードまたは音声メッセージ」と表現される）に関するセキュリティ上の脅威増大を考慮し、通常の認証では利用を制限する（令和7年度以降に利用制限の強制を予定）。ただし、「Googleからのメッセージ」や「認証システムアプリ」でスマートフォンのアプリ利用が困難な利用組織においては、暫定的な運用として公用携帯または個人携帯の電話番号設定を許容する。その際、通話または通信が確実に行えることを確認し、当該電話を本人が利用可能であることを担保すること。なお、取得したワンタイムのコードがスマートフォンのロック画面上に表示されないよう通知設定を行うことを強く推奨する。
  • [iPhoneドキュメントの通知の設定を変更する]
    https://support.apple.com/ja-jp/guide/iphone/iph7c3d96bab/17.0/ios/17.0open_in_newOpens in new tab
  • [Androidドキュメント:スマートフォンのロック画面での通知の表示方法を管理する]
    https://support.google.com/android/answer/9079661?hl=jaopen_in_newOpens in new tab

　
選択した方法で確認コードがモバイル端末等に送信されるので、ブラウザのコードの入力欄に入力する。その際、フィッシングサイトではない正しいサイトへのアクセスであることをブラウザのURL欄の左のアイコンをクリックし（Chromeを想定）、URLの文字列(https://(任意の文字列).google.com/ から始まるURL)や証明書等で確認すること。

　

• 令和6年5月現在、国の行政機関ではアカウントリカバリの際、ガバメントクラウド管理組織による対応が必要になる。地方公共団体等ではGCAS管理者または本番相当環境アクセス者はアカウントリカバリの際、ガバメントクラウド管理組織による対応が必要になるが、それ以外の利用者はパスワードを忘れた場合のアカウントリカバリを自身で実施可能である。
• 2週間以内に2段階認証の設定を行わなかった場合、ロックがかかるようになっている。その場合、国の行政機関においては、各府省庁と事業者のPMO又はPJMOの管理者権限を保有する者へ、地方公共団体等においては、利用機関GCAS責任者又は開発運用委託業者管理グループGCAS責任者へ状況を連携し、ロックの解除を依頼すること。連携を受けた者は「(4) 2段階認証ロックの解除方法」を参照し、ロックの解除を実施すること。機能が実装されていない時点もしくは機能にアクセスできない場合は、「(2) 初期設定」に記載の連絡先へ問合せを行うこと。なお、90日以上利用されていないアカウントは、ガバメントクラウド管理組織で無効化する。無効化されたアカウントを再度利用する場合は、責任者が「(2) 初期設定」に記載の連絡先へ問合せを行うこと。
• 初期設定後の対応として、GCASアカウントの権限や所属するグループを追加、変更する場合、GCASアカウントを取得の上、GCASガイド（メンバー専用ページ）で公開されているドキュメントを参照すること。

　

(4) 2段階認証ロックの解除方法

GCASアカウント作成後、2週間以内に2段階認証を設定しない場合、GCASアカウントが自動でロックされる。
GCASアカウントがロック状態になった場合、該当GCASアカウントでGoogleにログインすることができない状態になり、ログイン後に行う2段階認証の設定も不可能になる。そのため、一時的に該当GCASアカウントのロックを解除し、2段階認証なしでログイン可能な状態にする。
2段階認証ロック解除は、国の行政機関においては、各府省庁と事業者のPMO又はPJMOで管理者権限を保有する者、地方公共団体等においては、利用機関GCAS責任者又は開発運用委託業者管理グループGCAS責任者が実施できる。
2段階認証ロック解除は一定期間のみ有効であり、規定の時間を過ぎると再度2段階認証ロックが有効になるので、2段階認証ロック解除後は速やかに2段階認証設定を行なうよう利用者に促すこと。また、2段階認証ロック解除はユーザー毎に一定回数のみ解除可能であり、規定回数（3回）を超えて2段階認証ロック解除操作を行なった場合、GCASアカウントがロックされるので、なるべく1回目の2段階認証ロック解除時に2段階認証設定を行う様、利用者に促すこと。
2段階認証ロック解除の操作方法を以下に示す。

（国の行政機関）

• GCASシステム登録へアクセスし、2段階認証ロック解除(図8-7参照)をクリックする。

図 8‑7 GCASシステム登録から2段階認証ロック解除ページへ

2段階認証ロック解除対象のGCASアカウントを入力し、”解除ボタン”(図8-8参照)をクリックする。

図 8‑8 2段階認証ロック解除ページ

（地方公共団体等）

• GCASシステム登録へアクセスし、利用機関用サイトへ又は運用管理補助者用サイトへ(図8‑9参照)をクリックする。

図 8‑9 GCASシステム登録から利用機関用サイトへ又は運用管理補助者用サイトへ（図は利用機関GCAS責任者用の画面）

• 利用機関用サイト又は運用管理補助者用サイトへアクセスし、2段階認証ロック解除(図8-10参照)をクリックする。

図 8‑10 利用機関用サイト又は運用管理補助者用サイトから2段階認証ロック解除ページへ（図は利用機関GCAS責任者用の画面）

• 2段階認証ロック解除対象のGCASアカウントを入力し、”解除ボタン”(図8‑11参照)をクリックする。

図 8‑11 2段階認証ロック解除ページ

8.3 見積もり登録＋利用申請

ガバメントクラウド利用システムの管理者は、前年もしくは前々年のプロジェクト予算獲得のタイミングで、GCAS（オンボーディングツール）へクラウド見積もり情報を登録する。この情報を元に、ガバメントクラウドとしての翌年度の予算枠を確保する。クラウドの見積もりは、必ずCSPが提供する見積もりツールを使って見積もる。見積もり登録時には、見積額だけでなく、見積もりツール実行結果もしくはそのリンクの情報も登録する。
情報を登録するには、GCASシステム情報登録に入力することで、デジタル庁に提出する。利用意向・クラウド利用料等調査については、第4四半期にデジタル庁から依頼するので、依頼の約一ヶ月後までに入力すること。
詳細については、GCASアカウントを取得の上、GCASガイドで公開されているドキュメントを参照すること。
なお、デジタル庁からシステム構成のモダナイズ化などの指摘を受けた場合は、GCASシステム情報登録の内容を修正し、デジタル庁に再提出する。
また、調達時の事業者の提案内容によって、採用するCSPやクラウド利用料及び閉域網接続に係る経費、過去策定したアーキテクチャに変動が生じることも考えられるため、必要に応じて再度GCASシステム情報登録の内容を修正し、デジタル庁へ提出する。

8.4 環境申請

プロジェクト開始後、環境が必要な適切なタイミングで、環境の払い出し申請を行う。申請時には、利用開始日も指定可能で、その他環境セットアップに必要な各種情報を登録する。

利用開始日前に、申請された情報に基づき申請された数の環境が払い出され、管理者に初期セットアップガイドとともに連絡が届く。

詳細については、GCASアカウントを取得の上、GCASガイドで公開されているドキュメントを参照すること。

8.5 環境セットアップ

払い出された環境には、利用組織側で必須適用テンプレートを使った初期セットアップが必要である。

初期セットアップ手順はCSPにより異なる。AWSでは、CLIとService Catalogを使用した2種類の適用方法があり、払い出されたAdminユーザーで管理コンソールからCLIもしくはService Catalogにアクセスし、必要な情報を入れて実行する。他CSPでは、必須適用テンプレートを直接デプロイする場合もある。

詳細については、GCASアカウントを取得の上、GCASガイド（メンバー専用ページ）で公開されているドキュメントを参照すること。

8.6 問合せ方法

ガバメントクラウドに関する質問や不明点等については、原則としてGCAS（オンボーディングツール）を利用してデジタル庁へ問合せを行う。ただし、GCASアカウントを取得する前の利用システムは(2)、(3)の方法で問合せを行うこと。問合せを行う前に、デジタル庁が公開しているドキュメントを参照すること。
(1) GCAS（オンボーディングツール）による問合せ

GCAS（オンボーディングツール）上で問合せを行う。GCASの利用開始に当たっては、デジタル庁にGCASアカウントの申請を行うこと。

(2) 問合せ（国の行政機関）

「ガバメントクラウド問合せ等連絡票」に問合せ内容を記載し、デジタル庁に送付すること。原則として、デジタル庁における問い合わせの確認は開庁日の17時までとする。

(3) 問合せ（地方公共団体等）

地方公共団体等からの問合せは、総務省所管の標準化PMOツールを用いて問合せすること。

以上

改訂履歴