リファレンスアーキテクチャ（第6章 Google Cloud）
2023/11/02 公開
6. ブロック実現例（Google Cloud）
「ブロック一覧」で挙げた業務ブロック、非機能ブロックを実現するためのGoogle Cloud版サンプル構成を本章にて示す。
サンプル構成を参考にし、刷新対象システムの要件に合わせて実際に採用するサービスや統合するサービス等を検討いただきたい。
6-1. 業務ブロック
以下の項目は折りたたまれているため、詳細を確認するには三角ボタンを押下すること。
6-1-2. 申請・届出
- 所管する行政手続について利用システムを通じて申請・届出の受付、修正、取り下げを行う。
- 申請者からの届出・申請内容の受理業務
- 届出・申請内容の修正や取り下げの受付
-
利用者の認証
- 利用者認証_ユーザ認証機能
-
データの収集・連携
- データ管理_データ連携機能
- マネージドなRDBであるCloud SQLを利用し、運用コストを削減する。
- 署名付きURLを発行し、非構造化データをマネージドなストレージサービスであるCloud Storageに保管する。
- Firebaseを使用することで、サーバーレスにホスティング及び申請・届出内容処理を行うモバイルバックエンドを実現し、マネージドなRDBであるCloud SQLにデータを保管する。
- Firebaseを使用することでサーバーレスに申請・届出を行うモバイルバックエンドを実現する。
- SPA（Single Page Application）における静的ファイル（HTML、JavaScript、CSS）をCloud Load Balancing及びCloud Storageで配信する。Cloud Armorにより、Cloud Load Balancingへの攻撃からから保護したり、バックエンドの保護を行う。
- 他機能ブロックを利用してユーザ認証を行う。
- 申請・届出の入力データはREST APIで送信される。APIサーバはCloud Load Balancing及びCloud FunctionsまたはCloud Runにより構築される。※Cloud Functions/Cloud Runはコンテナの柔軟な構成の要否など要件に応じていずれかを選択すること。
- 認可されたリクエストは、申請・届出内容処理関数によって入力データ、および提出ファイルの形式チェックを行い、Cloud SQLに保存される。
- SPA（Single Page Application）における静的ファイル（HTML、JavaScript、CSS）をCloud Load Balancing及びCloud Storageで配信する。
Cloud Armorにより、Cloud Load Balancingへの攻撃からから保護したり、バックエンドの保護を行う。 - 他機能ブロックを利用してユーザ認証を行う。
- 申請・届出の入力データはREST APIで送信される。APIサーバはCloud Load Balancing及びCloud FunctionsまたはCloud Runにより構築される。※Cloud Functions/Cloud Runはコンテナの柔軟な構成の要否など要件に応じていずれかを選択すること。
- 認可されたリクエストは、申請・届出内容処理関数によって入力データ、および提出ファイルの形式チェックを行い、その際署名付きURLを発行する。データはCloud Storageに保存される。
- SPA（Single Page Application）における静的ファイル（HTML、JavaScript、CSS）をFirebase Hostingで配信する。
- 他機能ブロックを利用してユーザ認証を行う。
- 申請・届出の入力データを、申請・届出内容処理関数によって入力データ、および提出ファイルの形式チェックをCloud Functions for Firebaseで行う。
- [3]で処理された入力データはCloud SQLに保存される。
- SPA（Single Page Application）における静的ファイル（HTML、JavaScript、CSS）をFirebase Hostingで配信する。
- 他機能ブロックを利用してユーザ認証を行う。
- 申請・届出の入力データを、申請・届出内容処理関数によって入力データ、および提出ファイルの形式チェックをCloud Functions for Firebaseで行う。
- [3]で処理された入力データはCloud Storage for FirebaseまたはCloud Firestoreに保存される。
- 申請・届出時に添付する本人確認者や各種証明書等の資料の管理を行う。
- 届出・申請時に添付された本人確認者や各種証明書等の管理
- UIを提供する機能
- コンテンツ管理_Webページ（静的コンテンツ）公開機能
- 申請・届出_申請・届出機能
- 認証機能
- ユーザ認証機能（国民向け）
- ユーザ認証機能（企業向け）
- ユーザ認証機能（職員向け）
- データ利用機能
- 申請・届出_ステータス管理機能
- 申請・届出_電子決裁機能
- Google Cloud Armorを配置し、Cloud Load Balancing及びバックエンドの保護を行う。
- Cloud Load Balancing及びCloud RunまたはCloud Functionsを利用することで、APIをサーバーレスに実現する。
- Cloud Storageを利用することでストレージの高可用性を実現し、データ量の制限を受けずに非構造化データを保存する。
- UIを提供する機能により、フロントエンドがユーザーへ提供される。
- 認証機能を利用してユーザー認証を行う。
- 添付資料管理機能の入力データはREST APIで送信される。
- Google Cloud Armorにより、Cloud Load Balancing及びバックエンドの保護を行う。
- APIサーバーはCloud Load Balancing及びCloud RunまたはCloud Functionsによって実現する。※Cloud Run/Cloud Functionsは処理時間、入力データの容量等の要件に応じて選択すること。
- 認可されたリクエストは添付資料処理関数にてCloud Storageへ保存される。
- 添付資料処理関数は要件に応じて入力データの整形または検証も行う。※入力データの整形を行う際はオリジナルデータの保存、アップロード元となるユーザー等のメタデータの管理についても検討を行うこと。
- データ利用機能はCloud Storage上のデータを参照することができる。
- 利用者や職員による申請・届出を行った案件のステータス照会を行う。
- 申請者による申請状況の照会。
- 職員による申請状況の確認業務。
- 利用者の認証
- 利用者認証_ユーザ認証機能（国民向け）
- 利用者認証_ユーザ認証機能（企業ユーザ向け）
- 利用者認証_ユーザ認証機能（職員向け）
- ステータス情報の取得先
- 申請・届出_申請・届出機能
- 申請・届出_電子決裁機能
- Google Cloud Armorを配置し、Cloud Load Balancing及びバックエンドの保護を行う。
- Cloud Load Balancing及びCloud RunまたはCloud Functionsを利用することで、APIをサーバーレスに実現する。
- Direct VPC EgressまたはServerless VPC Access connectorを利用することで、Serverless NEGからプライベートにDBへ接続する。
- Google Cloud Armorにより、Cloud Load Balancing及びバックエンドの保護を行う。
- Cloud CDNにより、静的コンテンツのキャッシングを行う。
- SPA（Single Page Application）における静的ファイル（HTML、JavaScript、CSS）をCloud Load Balancing及びCloud Storageで配信する。
- 認証機能を利用してユーザー認証を行う。
- ステータスはREST APIで取得される。
- APIサーバーはCloud Load Balancing及びCloud RunまたはCloud Functionsによって実現する。※Cloud Run/Cloud Functionsは処理時間、入力データの容量等の要件に応じて選択すること。
- 認可されたリクエストはステータス取得関数にて、VPCアクセスまたはAPIアクセスによってDBへ接続し、ステータス情報を取得する。
- VPCアクセスの場合、Cloud RunはDirect VPC Egressを利用する。Cloud FunctionsはServerless VPC Access connectorを利用する。
- 利用者が申請・届出を行った案件に関して行政機関から電子公文書交付を行う。
- 届出・申請の結果を含む公文書を、申請者に対して交付する業務。
-
公文書の作成
- 書類出力_法定帳票作成機能
-
公文書ダウンロード情報の通知
- 利用者通知_メッセージ通知機能
- 署名付きURLを発行しセキュアに公文書をダウンロードする。
- 他機能ブロックがFirebaseで実現している場合、Cloud Storage for Firebaseを選択することで包括することができる。
- 他の機能ブロックが交付用の公文書を作成し、Cloud Storageに出力される。その際、署名付きURLを併せて発行する。
- 他の機能ブロックにより、署名付きURLをエンドユーザに連絡し、ダウンロードを促す。
- 本機能は、別機能における処理の中で公文書のダウンロードが必要になった場合に利用される想定である。
- ユーザーは他の機能ブロックにおいてユーザ認証を行い、認証トークンを取得する。
- 公文書は認証済みユーザのみがダウンロード可能なセキュリティルールを設定したCloud Storage for Firebaseへリクエストすることでダウンロードする。
- リクエストの認可は認証系の機能ブロックにより発行されるトークンを検証することによって行われる。
- Cloud Storage for Firebaseはリクエストに含まれるトークンの有効性を検証する。トークンが有効な場合のみ、リクエストは受理される。
- 他の機能ブロックが、公文書保管ストレージに公文書をアップロードする。
- 行政機関から発出する電子公文書のインターネット公開を行う。
- 届出・申請の結果を一般公開する業務。
- 公文書の作成
- 書類出力_法定帳票作成機能（外部）
- 書類出力_法定帳票作成機能（内部）
- 公文書を表示するWebサイトの配信
- コンテンツ管理_Webページ（静的コンテンツ）公開機能
- Google Cloud Armorを配置し、Cloud Load Balancing及びバックエンドの保護を行う。
- SPA（Single Page Application）における静的ファイル（HTML、JavaScript、CSS）をCloud Load Balancing及びCloud Storageで配信する。
- 公文書をファイル（PDF等）として、Cloud Load Balancing及びCloud Storageで配信し、一般公開を行う。
- ファイルは高耐久なオブジェクトストレージであるCloud Storageに保管する。
- Cloud CDNを利用し、大量のリクエストに対する低レイテンシーの応答を実現する。
- WAFによりインターネット経由で行われる様々な攻撃からフロントエンド配信機能を保護する。
- 公文書のファイルは静的コンテンツの一部として公開される想定であり、コンテンツ管理_Webページ（静的コンテンツ）公開機能が提供するWebページに公文書のファイルのダウンロード用URLが掲載される。
- 連携機能が作成したファイル（PDF等）を公文書配信ストレージにアップロードする。
- 補足：時刻指定での公文書公開を行う要件がある場合は、Webコンテンツ管理（CMS）機能の利用が推奨される。
- 申請時の手続き費用、税金などの国民から国への納付に係る金銭処理を行う。
- 申請に係る手数料などの納付を受け付ける業務。
- 実際の金銭処理を担う外部システムと連携し、納付の状況を管理する。
- 手数料等の納付を必要とする申請を受け付ける機能
- 申請・届出_申請・届出機能
- マネージドなRDBであるCloud SQLを利用し、運用コストを削減する。
- 申請・届出機能等の他の機能ブロックにおいて、手数料の納付が必要になった場合、本機能へのリクエストが送信される。
- 手数料納付の入力データはREST APIで送信される。APIサーバはCloud Load Balancing及びCloud Functions (またはCloud Run)により構築される。※Cloud Functions/Cloud Runはコンテナの柔軟な構成の要否など要件に応じていずれかを選択してください。
- 手数料等の納付は、歳入金電子納付システム（REPS）と連携して行われる。REPSとの間で手数料の納付に関する情報を連携する。連携した情報をもとに、手数料納付ステータスを更新する。
（注）REPSに関する技術情報（インタフェース仕様、連携のための手続きや制約事項等）は、別途確認する必要がある。 - 手数料の納付ステータスはデータベースに保存し管理を行う。データベースはマネージドなRDBであるCloud SQLを利用し、運用コストを削減する。
- 申請における補助金など国から国民への交付に係る金銭処理を行う。
- 補助金や還付金などの交付を実施する業務
- 実際の金銭処理を担う外部システムと連携し、交付の状況を管理する
-
手数料等の納付を必要とする申請を受け付ける機能
- 申請・届出_申請・届出機能
-
利用者の認証
- 利用者認証_ユーザ認証機能
- マネージドなRDBであるCloud SQLを利用し、運用コストを削減する。
- 申請・届出機能等の他の機能ブロックにおいて、補助金の交付が必要になった場合、本機能へのリクエストが送信される。
- 手数料納付の入力データはREST APIで送信される。APIサーバはCloud Load Balancing及びCloud Functions (またはCloud Run)により構築される。※Cloud Functions/Cloud Runはコンテナの柔軟な構成の要否など要件に応じていずれかを選択してください。
- 補助金等の交付は、外部システムと連携して行われる。外部システムとの間で補助金の交付に関する情報を連携する。連携した情報をもとに、補助金交付ステータスを更新する。
(注)外部システムに関する技術情報(インタフェース仕様、連携のための手続きや制約事項等)は、別途確認する必要がある。 - 補助金の交付ステータスはデータベースに保存し管理を行う。データベースはマネージドなRDBであるCloud SQLを利用し、運用コストを削減する。
- 申請から承認までの決裁ワークフロー、および申請案件管理（登録、更新、参照）を行う。
- 届出・申請や審査・承認に関する様々な処理をワークフロー化して実施。
-
決裁ワークフローを開始
- 審査・承認_審査・承認機能
-
決裁ワークフロー内の個別処理
- ワークフローに必要な機能ブロックを選択
- Workflowsを使って複雑な処理を並列に実行する
- 他連携機能からWorkflowsを実行する。
- 申請案件管理(登録・更新・参照)を行う。
- 決裁ワークフロー内の各機能のアウトプットを行う。
6-1-2-1. 申請・届出_申請・届出機能
概要：
達成できる業務：
連携機能ブロック：
アーキテクチャのポイント：
申請・届出_申請・届出機能（パターン１ Cloud SQL保管）
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
[4][5]
申請・届出_申請・届出機能（パターン２ Cloud Storage保管）
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
[4][5]
申請・届出_申請・届出機能（パターン３ Firebaseによるホスティング・処理を統括しCloud SQLに保管）
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
[4]
申請・届出_申請・届出機能（パターン４ Firebaseによる機能包含）
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
[4]
6-1-2-2. 申請・届出_添付資料管理機能
概要：
達成できる業務：
連携機能ブロック：
アーキテクチャのポイント：
申請・届出_添付資料管理機能
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
6-1-2-3. 申請・届出_ステータス管理機能
概要：
達成できる業務：
連携機能ブロック：
アーキテクチャのポイント：
申請・届出_ステータス管理機能
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
[4]
6-1-2-4. 申請・届出_公文書ダウンロード機能
概要：
達成できる業務：
連携機能ブロック：
アーキテクチャのポイント：
申請・届出_公文書ダウンロード機能(パターン1 署名付きURLを利用したCloud Storageからダウンロード)
ブロック実現例
ブロック実現例 説明
申請・届出_公文書ダウンロード機能(パターン2 Cloud Storage for Firebaseからダウンロード)
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
6-1-2-5. 申請・届出_公文書公開機能
概要：
達成できる業務：
連携機能ブロック：
アーキテクチャのポイント：
申請・届出_公文書公開機能
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
[補足]
6-1-2-6. 申請・届出_手数料等電子納付機能
概要：
達成できる業務：
連携機能ブロック：
※実際の金銭処理を担う外部システムと納付の状況を連携するために、追加のインタフェースが必要になる可能性がある。例えば、外部システムが本機能ブロックに対して、納付状況に関するデータを送信するケースが該当する。 外部システムの仕様に合わせて、インタフェースの必要性を検討する必要がある。
アーキテクチャのポイント：
申請・届出_手数料等電子納付機能
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
[4]
6-1-2-7. 申請・届出_補助金等電子交付機能
概要：
達成できる業務：
連携機能ブロック：
※実際の金銭処理を担う外部システムと交付の状況を連携するために、追加のインタフェースが必要になる可能性がある。例えば、外部システムが本機能ブロックに対して、交付状況に関するデータを送信するケースが該当する。
アーキテクチャのポイント：
申請・届出_補助金等電子交付機能
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
[4]
6-1-2-8. 申請・届出_電子決裁機能
概要：
達成できる業務：
連携機能ブロック：
アーキテクチャのポイント：
申請・届出_電子決裁機能
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
6-1-3. 審査・承認
- 行政業務における審査の受付やその承認処理を行う。
- 統計調査やアンケートの回答内容を審査する。
-
承認処理を行うデータを連携する
- データ管理_データ連携
-
利用者の認証
- 利用者認証_ユーザ認証機能
- Cloud Runを利用してサーバレスに機能を実現し、利用者認証機能を用いて承認者(職員)のみがアクセスできるようにする。
- 職員は審査のためにインターネット経由でアプリケーションにアクセスする。IPアドレスの制限にはCloud Armorを使う。Googleアカウントによる制限を行う場合はIdentity-Aware Proxyを使う。
- 他機能ブロックを利用してユーザ認証を行う。
- 届出・申請内容の確認や審査・承認はCloud Runで行う。
- 審査・承認結果データをCloud SQLに保管する。
6-1-3-1. 審査・承認_審査・承認機能
概要：
達成できる業務：
連携機能ブロック：
アーキテクチャのポイント：
審査・承認_審査・承認機能
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
[4]
6-1-4. データ管理
- 複数自治体の情報をDBに保管する際に、自治体ごとに分離せずに統合し、互いに活用するためのデータ格納を実現する。
- 組織横断でのデータ活用する目的で、組織毎に蓄積されるデータセットを複数組織へ共有する業務
- データ利活用について企画・立案する目的で、共有されたデータカタログを検索し、必要となるデータセットを検索する業務
- ノーコードかつサーバーレスでBigQueryへの変更データキャプチャによるリアルタイム連携(CDC Streaming)
-データのコピーや移動を行わずに、BigQuery から Cloud SQL に存在するデータのクエリをリアルタイムで実行(連携クエリ) - Cloud SQL連携クエリを利用してデータセット単位で登録したデータをBigQueryへ登録ができる。
- また、Datastreamでリレーショナル データベースから BigQuery へのシームレスなレプリケーションが可能である。
- 連携クエリを利用する場合はCloud SQL データベースにクエリ ステートメントを送信し、結果を一時テーブルとして取得する。
- 利用者からWebフォームやファイルにより送付されるデータを受領し、保管する。
- 利用者からWebフォームやファイルにより送付されるデータを受領し、保管する業務。
- 保管したデータを連携機能向けに別ストレージに保管する業務。
- Firebaseを使用することで、サーバーレスでデータを収集するモバイルバックエンドを実現
-データソースから分析用データベースであるBigQueryやデータ分析用のツールへのシームレスな接続 - Firebaseを利用することでモバイルアプリやWebブラウザからの認証や利用者の入力情報の保管・閲覧を行うことができる。
- データベースとしてRDBを用いる場合はFirebase Cloud Functionsを利用してCloud SQL等のマネージドデータベースを利用することができる。
- Firebase Analytics等のデータをBigQueryに連携し、分析することも可能。
- FirestoreのデータをGCS経由でBigQueryにエクスポートすることができる。
- 必要であれば、特定のプロジェクトに対して、Google Cloud アセットのメタデータを自動的にカタログ化する。
- BigQueryを利用し、カタログに登録されているデータに対して、SQLでクエリを行う。
- 行政データ分析を行うためのダッシュボードの提供、および分析に必要な前処理やダッシュボード管理を行う。
- 分析者が対象データを可視化するために必要となる事前処理業務。
- 分析者が参照する分析用ダッシュボードの作成業務。
- 分析者が分析用ダッシュボードを分析する業務。
- データウェアハウス、データマート両方の用途に対応したBigQueryを使用することにより、BI用のデータアーキテクチャやパイプラインの作成が容易となる
-BIエンジンを使用することで、ノーコードでのクエリ時間の改善が可能 - データ収集及び管理等を担う機能ブロックにより生成・蓄積されたデータを参照する。
- BigQuery上のデータに対してアドホックな分析を実施BQML(BigQuery Machine learning)を使った予測を行うことも可能。
- 分析者はブラウザからダッシュボードを作成およびデータ分析を行う。
- BIエンジンを利用することでクエリのパフォーマンスを向上させることができる。
- Connected Sheet機能を利用することでスプレッドシートを利用した分析を行うこともできる。
- レポート作成はAppsheetを利用してレポート作成アプリを実装することで実現できる。
- アプリケーションからPDFなどのファイル出力を行うことも可能。
- 行政データの統計処理を行う。
- 行政に係る統計データをダッシュボードとして公開する。
- 分析者が対象となるデータをETL処理する業務。
- 分析者が事前処理済みのデータを統計処理する業務。
- 分析者が統計処理後のデータを連携機能向けに保管する業務。
- BigQueryのデータをCSV,JSON,Avro,Parquetといった様々な形式でCloud Storageにエクスポートが可能
- Looker StudioやAppSheetを利用したノーコードでの可視化が可能
- BigQuery上で処理したデータをCloud Storageにファイルでエクスポートする。エクスポートはコンソールから任意のSQLを発行する方法やスケジュール度クエリを利用することによる定期自動実行をすることができる。
- BigQuery上で処理したデータをLooker Studioでダッシュボード表示を行い公開する。
- Appsheetを利用してダッシュボードを実装する。
- IoTデバイスやセンサからの観測データを取り込む。
- IoTデバイスやセンサからの観測データを取り込むため、IoTデバイスと利用システムとの接続性の確立やデータ取り込みパイプラインとの連携を行う
- サーバーレスかつスケーラブルにリアルタイムなストリームエンジン
-様々なIoTスキーマに対応 - センサー等からIoTデータを収集する。
- 継続的に出力されるログデータや様々なIoTスキーマからのセンサーデータ等のストリームデータは、Pub/Subを利用して収集する。
- スキーマ変換が不要な場合はBigQuerySubscriptionを利用して直接データを書き込む。
- スキーマ変換が必要な場合はDataflowを利用してスキーマ変換を行った後にBigQueryにデータを保管する。
- 高頻度に送られてくる観測データやリアルタイム集計が必要となるデータの管理、集計、保存を行う。
- ストリーミングデータをリアルタイムに収集及び分析処理する業務。
- ストリーミングデータを形式を変更せずにリアルタイムに蓄積する業務。
- データ管理_分析用ダッシュボード機能
- スケーラブルで耐久性のあるイベントの取り込みおよび配信が可能、サーバーレスかつスケーラブルにリアルタイムなストリームエンジン
- Cloud Pub/Subによりストリーミングデータを収集する。
- データは、Hadoop、OLAP データベース (例: Teradata、Netezza)、またはファイル ストレージ サーバーなどの大規模なデータ ストレージ システムから抽出可能。
- リアルタイム分析・データ蓄積のためBigQueryに連携する。
6-1-4-1. データ管理_データ連携機能
概要：
達成できる業務：
アーキテクチャのポイント：
データ連携機能 （パターン1 CDC Streaming）
ブロック実現例
ブロック実現例 説明
[1]
データ連携機能 （パターン2 連携クエリ利用）
ブロック実現例
ブロック実現例 説明
[1]
6-1-4-2. データ管理_データ収集機能
概要：
達成できる業務：
連携機能ブロック：
3. データ受領向けフロントエンドアプリの配信
- Webページ(静的コンテンツ)公開機能
4. 収集対象データの利用
- データ管理_統計処理機能
- データ管理_文書検索機能
アーキテクチャのポイント：
データ管理_データ収集機能
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
6-1-4-3. データ管理_分析用ダッシュボード機能
概要：
達成できる業務：
連携機能ブロック：
4. 可視化対象データの収集・保管
- データ管理機能
- データ管理_データ収集機能
- 大量データ取り込み機能
5. 分析用ダッシュボードの公開
- データ管理_統計情報公開機能
アーキテクチャのポイント：
データ管理_分析用ダッシュボード機能
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
[4]
6-1-4-4/5. データ管理_統計処理機能/統計情報公開機能
概要：
達成できる業務：
統計処理機能
統計情報公開機能
4. 分析者が作成した統計処理後データ及び公開用ダッシュボードを公開する業務。
5. 分析者が作成した統計処理後データ、公開用ダッシュボードの元データセットに対して事前処理を実施する業務。
6. 分析者が事前処理後のデータを可視化した公開用ダッシュボードを作成する業務。
7. 分析者が事前処理後のデータ及び公開用ダッシュボードを公開する業務。
連携機能ブロック：
8. 可視化対象データの収集・保管
- データ管理機能
- データ管理_データ収集機能
- 大量データ取り込み機能
9. 分析用ダッシュボードの公開
- データ管理_分析用ダッシュボード機能
アーキテクチャのポイント：
データ管理_統計処理機能/統計情報公開機能(ファイルによる公開)
ブロック実現例
ブロック実現例 説明
[1]
※現在のガバメントクラウドのポリシーではCloud Storageの一般公開(allUsers権限付与)を禁止しています。一般公開を行う場合は、申請の上ポリシー緩和を予定している。
データ管理_統計処理機能/統計情報公開機能(ダッシュボードによる公開)
ブロック実現例
ブロック実現例 説明
[1]
[2]
6-1-4-7. データ管理_IoT連携機能
概要：
達成できる業務：
連携機能ブロック：
2. データを取り込むパイプライン機能
- 大量データ取り込み機能
アーキテクチャのポイント：
データ管理_IoT連携機能
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
6-1-4-8. データ管理_大量データ取り込み機能
概要：
達成できる業務：
連携機能ブロック：
3. 蓄積されたストリーミングデータの参照及び利用
アーキテクチャのポイント：
大量データ取り込み機能
ブロック実現例
ブロック実現例 説明
計測機器やアプリケーション等のストリーミングデータにおけるデータソース及びプロデューサが存在することを想定する。また、Google Cloud外部にデータソース及びプロデューサが存在していること前提とした構成図となるが、Google Cloud内部に存在することも想定される。
[1]
[2]
[3]
6-1-5. 利用者通知
- 利用者に対して申請・届出を行った案件に関連する通知や手続に関する案内を行う。
- 利用者に対して、更新があったことを連絡する業務。
- 通知が必要になるイベントの発生源
- データ管理_統計処理機能
- データ管理_統計情報公開機能
- WebhookによるHTTPリクエストで様々な通知サービスに対して連携が可能
- 通知が必要になるイベントをトリガーに、Cloud Functionsを実行し、Slack等にwebhook連携を行う。
6-1-5-1. 利用者通知_メッセージ通知機能
概要：
達成できる業務：
連携機能ブロック：
アーキテクチャのポイント：
利用者通知_メッセージ通知機能（webhook連携）
ブロック実現例
ブロック実現例 説明
[1]
6-1-6. コンテンツ管理
- 職員による登録、もしくはサーバにて生成されたWebページを利用者に提供する。
- 静的コンテンツを配信する。
- フロントエンドアプリが利用する機能
- Webページ(動的コンテンツ)公開機能
- ユーザ認証機能（国民向け）
- ユーザ認証機能（企業向け）
- ユーザ認証機能（職員向け）
- スケーラブルでトラフィックによるサーバ負荷を気にする必要がない低コストの環境が簡単に構築可能
- Cloud Storageに静コンテンツを配置する。Cloud CDNで、大量のリクエストにも低レイテンシーでの応答を実現する。Cloud Armorでインターネット経由で行われる様々な攻撃からWebページ(静的コンテンツ)公開機能を保護する。
- Firebase Hostingを利用して
作成したウェブページを登録し、公開して、URLを発行することが可能 - Webページで配信するコンテンツ（テキストや画像、ファイル）の管理を行う。
- Webサイトで配信するコンテンツの管理機能を提供する。
- コンテンツを利用者（閲覧者）へ提供する。
- Firebase Hostingに含まれるCDNのキャッシュ機能により高速な配信が可能である
- ヘッドレスCMSとしてDecap CMSを利用した例は下記のリンクを参照のこと。(https://digital-gov.note.jp/n/n9b38aa4daab3Opens in new tab)
- 本機能はコンテンツ管理を行うヘッドレスCMS部分と、そこから取得した情報を表示するためのフロントエンド配信部から構成される。
- Webサイトの閲覧者は静的コンテンツをCDNを経由してFirebase Hostingから取得する。
- フロントエンド開発者が変更を加える場合は、GitHub等コードレポジトリでの変更イベントをトリガーとし、GitHub Actions等によるビルド及びデプロイプロセスを開始する。
- コンテンツ投稿者は、CMSでの編集により、編集結果がGitHub等でのPull Requestとして生成され、それがマージされることにより、GitHub Actions等によってFirebaseへデプロイされる。
- 本機能はコンテンツ管理を行うヘッドレスCMS部分と、そこから取得した情報を表示するためのフロントエンド配信部から構成される。
- Webサイトの閲覧者は静的コンテンツをCDNを経由してFirebase Hostingから取得する。
- 静的コンテンツの初期データを外部のヘッドレスCMSサーバからAPIリクエストすることで取得しクライアント側でレンダリングを行う。
- フロントエンド開発者が変更を加える場合は、GitHub等コードレポジトリでの変更イベントをトリガーとし、GitHub Actions等によるビルド及びデプロイプロセスを開始する。
- コンテンツ投稿者は、CMSでの編集により、編集結果がGitHub等でのPull Requestとして生成され、それがマージされることにより、GitHub Actions等によってFirebaseへデプロイされる。
- 本機能はコンテンツ管理を行うヘッドレスCMS部分と、そこから取得した情報を表示するためのフロントエンド配信部から構成される。
- Webサイトの閲覧者は静的コンテンツをCDNを経由してFirebase Hostingから取得する。
- 利用者がFirebase HostingにアクセスするとCloud Functions for FirebaseあるいはCloud Runに連携される。
※Cloud Functions/Cloud RunはいずれもAPIサーバとして機能しますが、コンテナによる柔軟な構成の要否など要件に応じていずれかを選択してください。 - Cloud Functions for FirebaseあるいはCloud RunはCMSからコンテンツを取得しレンダリングした画面をユーザに返却する。
- フロントエンド開発者が変更を加える場合は、GitHub等コードレポジトリでの変更イベントをトリガーとし、GitHub Actions等によるビルド及びデプロイプロセスを開始する。
- コンテンツ投稿者は、CMSでの編集により、編集結果がGitHub等でのPull Requestとして生成され、それがマージされることにより、GitHub Actions等によってFirebaseへデプロイされる。
- Cloud CDNのキャッシュ機能により高速な配信が可能である。
- 本機能はコンテンツ管理を行うヘッドレスCMS部分と、そこから取得した情報を表示するためのフロントエンド配信部から構成される。
- Webサイトの閲覧者は静的コンテンツをCloud Load Balancingを経由してCloud Storageから取得する。
- フロントエンド開発者が変更を加える場合は、GitHub等コードレポジトリでの変更イベントをトリガーとし、GitHub Actions等によるビルド及びデプロイプロセスを開始する。
- コンテンツ投稿者は、CMSでの編集により、編集結果がGitHub等でのPull Requestとして生成され、それがマージされることにより、GitHub Actions等によってCloud Storageへデプロイされる。
- 本機能はコンテンツ管理を行うヘッドレスCMS部分と、そこから取得した情報を表示するためのフロントエンド配信部から構成される。
- Webサイトの閲覧者は静的コンテンツをCloud Load Balancingを経由してCloud Storageから取得する。
- 静的コンテンツの初期データをCMSからAPIリクエストすることで取得しクライアント側でレンダリングを行う。
- フロントエンド開発者が変更を加える場合は、GitHub等コードレポジトリでの変更イベントをトリガーとし、GitHub Actions等によるビルド及びデプロイプロセスを開始する。
- コンテンツ投稿者は、CMSでの編集により、編集結果がGitHub等でのPull Requestとして生成され、それがマージされることにより、GitHub Actions等によってCloud Storageへデプロイされる。
- 本機能はコンテンツ管理を行うヘッドレスCMS部分と、そこから取得した情報を表示するためのフロントエンド配信部から構成される。
- Webサイトの閲覧者は静的コンテンツをCloud Load Balancingを経由してCloud Storageから取得する。
- 利用者がCloud StorageにアクセスするとCloud Load Balancingにリダイレクトされ、Cloud FunctionsあるいはCloud Runに連携される。
※Cloud Functions/Cloud RunはいずれもAPIサーバとして機能しますが、コンテナの柔軟な構成の要否などの要件に応じていずれかを選択してください。
※Cloud Load BalancingのバックエンドにはCloud Functions/Cloud RunのServerless NEGを指定します。
Serverless NEGについては以下を参照すること。
[Cloud Run、App Engine、または Cloud Functions を使用して従来のアプリケーション ロードバランサを設定する]
https://cloud.google.com/load-balancing/docs/https/setting-up-https-serverless?hl=jaOpens in new tab - Cloud FunctionsあるいはCloud RunはCMSからコンテンツを取得しレンダリングした画面をユーザに返却する。
- フロントエンド開発者が変更を加える場合は、GitHub等コードレポジトリでの変更イベントをトリガーとし、GitHub Actions等によるビルド及びデプロイプロセスを開始する。
- コンテンツ投稿者は、CMSでの編集により、編集結果がGitHub等でのPull Requestとして生成され、それがマージされることにより、GitHub Actions等によってCloud Storageへデプロイされる。
6-1-6-1. コンテンツ管理_Webページ(静的コンテンツ)公開機能
概要：
達成できる業務：
連携機能ブロック：
アーキテクチャのポイント：
コンテンツ管理_Webページ(静的コンテンツ)公開機能(Cloud Storageで静的ホスティングを行う)
ブロック実現例
ブロック実現例 説明
[1]
※現在のガバメントクラウドのポリシーではCloud Storageの一般公開(allUsers権限付与)を禁止しています。一般公開を行う場合は、申請の上ポリシー緩和を予定している。
コンテンツ管理_Webページ(静的コンテンツ)公開機能(FireBase Hostingで静的ホスティングを行う)
ブロック実現例
ブロック実現例 説明
[1]
6-1-6-3. コンテンツ管理_Webコンテンツ管理(CMS)機能
概要：
達成できる業務：
連携機能ブロック：
更新予定
アーキテクチャのポイント：
コンテンツ管理_Webコンテンツ管理（CMS）機能（パターン1 SaaS利用・SSG・Firebase Hosting）
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
[4]
コンテンツ管理_Webコンテンツ管理（CMS）機能（パターン2 SaaS利用・CSR・Firebase Hosting）
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
コンテンツ管理_Webコンテンツ管理（CMS）機能（パターン3 SaaS利用・SSR・Firebase Hosting）
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
アーキテクチャのポイント：
コンテンツ管理_Webコンテンツ管理（CMS）機能（パターン4 SaaS利用・SSG・Cloud Storage）
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
[4]
コンテンツ管理_Webコンテンツ管理（CMS）機能（パターン5 SaaS利用・CSR・Cloud Storage）
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
コンテンツ管理_Webコンテンツ管理（CMS）機能（パターン6 SaaS利用・SSR・Cloud Storage）
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
6-1-7. コミュニケーション
- 職員、もしくは利用システムと利用者とのコミュニケーションを目的にチャットボットを提供する。
- ユーザーからの入力に対し、チャットボットが自動で応答する。
- UIを提供する機能
- Webページ(静的コンテンツ)公開機能
6-1-7-3. コミュニケーション_チャットボット機能
概要：
達成できる業務：
連携機能ブロック：
ブロック実現例
更新予定
6-1-8. 外部連携
- 申請・届出の案件処理にあたって後続処理のために外部システムの機能（API）を呼び出す。
- 外部のAPIへインターネット経由またはGSS経由でリクエストを送る。
- 外部のSaaSへデータを連携する。
- 外部連携を必要とする機能
- 申請・届出_申請・届出機能
- 申請・届出_電子決裁機能
- Cloud FunctionsまたはCloud Runを使ってサーバレスでマネージドに申請処理連携を実現
- Cloud Data Fusionを使ってフルマネージドかつクラウド ネイティブなデータ統合が可能。プラグインを利用して外部SaaSを含めたさまざまなデータのシンクを実施できる。
- 本機能は他の機能ブロックにおいて何等かの処理を実行する上で、外部システムへリクエストを送信する必要がある場合を想定する。
- 外部システム連携のトリガーはCloud Load balancing、Workflows、またはCloud Storage等のサービスによるイベントからEventarcのトリガーとすることが想定される。
- [1]の連携機能ブロック内で発生したイベントによってCloud FunctionsあるいはCloud Runがトリガーされ、他システムへリクエストが送信される。
※本アーキテクチャは、WebAPIを利用した外部システム連携を想定しています。ファイル連携にSFTPやMQを利用する際は、対応するクライアントライブラリがCloud Functions/Cloud Runで動作することを確認してください。 - 外部システムへのリクエストを固定されたIPアドレスから送信したい場合は、Cloud NATを経由してリクエストを行う。サーバーレスサービスからCloud NATを経由する場合はサーバーレスVPCアクセスコネクタを利用する。
※Cloud Runの固定IPアドレスの設定については参照すること。
[外向きの静的 IP アドレス]
https://cloud.google.com/run/docs/configuring/static-outbound-ip?hl=jaOpens in new tab - 本機能は他の機能ブロックにおいて何等かの処理を実行する上で、外部システムへリクエストを送信する必要がある場合を想定する。
- 外部システム連携のトリガーはCloud Load balancing、Workflows、またはCloud Storage等のサービスによるイベントからEventarcのトリガーとすることが想定される。
- 他の機能ブロックによりCloud FunctionsあるいはCloud Runがトリガーされ、他システムへリクエストが送信される。
※本アーキテクチャは、WebAPIを利用した外部システム連携を想定しています。ファイル連携にSFTPやMQを利用する際は、対応するクライアントライブラリがCloud Functions/Cloud Runで動作することを確認してください。 - GSSを経由した外部システムへのリクエストはCloud Router、Dedicated Interconnectを経由する。
- 本機能は他の機能ブロックにおいて何等かの処理を実行する上で、外部システムへデータを連携する必要がある場合を想定する。
- 外部システムへ連携するデータのソースは複数のデータソースを組み合わせて、様々なデータを効率的に統合することがなどができる。
- Cloud Data Fusionを利用しデータをSaaSへ連携する。
- Cloud Data Fusionは、プラグインを利用して多くの外部SaaSと連携することが可能。
※Cloud Data Fusionの概要については参照すること。
[Cloud Data Fusion の概要]
https://cloud.google.com/data-fusion/docs/concepts/overview?hl=jaOpens in new tab - 外部システムからの処理を受け付けるための機能（API）を公開する。
- 外部システムへ動的コンテンツを配信する
- Cloud Runを利用したサーバレスアーキテクチャ
- インターネットからのアクセスはCloud Load Balancerで受信する。
- IPアドレス制限やWAFなどを導入したい場合はCloud Armorを利用する。
- アプリケーションはCloud Runで実行する。
- Cloud RunからCloud SQL等のVPC内リソースにアクセスするためにServerless VPC Access Connectorを利用する。
6-1-8-1. 外部連携_申請処理連携機能
概要：
達成できる業務：
連携機能ブロック：
アーキテクチャのポイント：
外部連携_申請処理連携機能（パターン1 通常）
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
外部連携_申請処理連携機能（パターン2 GSS経由の場合）
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
外部連携_申請処理連携機能（パターン3 SaaS連携）
ブロック実現例
ブロック実現例 説明
[1]
[2]
6-1-8-2. 外部連携_外部連携機能(API公開)
概要：
達成できる業務：
アーキテクチャのポイント：
外部連携_外部連携機能(API公開)
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
6-1-9. 書類出力
- 郵送宛名ラベルや送付書類などの業務関連書類を出力する。
- アップロードされたファイルを印刷のために通知・送付する。
- 郵送書類の内容を生成する機能
- 申請・届出_ステータス管理機能
- 申請・届出_電子決裁機能
- Google Cloud Armorを配置し、Cloud Load Balancing及びバックエンドの保護を行う。
- Firestoreを配置し、ファイル出力時のメタデータを複数の関数から参照できるようにする。
- Secret Managerを配置し、認証情報を安全に管理する。
- 本機能は他の機能が出力するデータをもとに郵送書類を作成する機能である。
- なお、作成する郵送書類は郵送ラベル等の簡易的かつ一般的なフォーマットであること前提としている。
- 他機能はCloud Load BalancingへデータをREST APIで送信することで、郵送書類の生成を開始する。
- Cloud Armorにより、Cloud Load Balancingへの攻撃からから保護したり、バックエンドの保護を行う。
- Serverless NEG内のCloud RunまたはCloud Functionsは入力データを元に必要な書類をPDFなどの形式でCloud Storageへ出力する。
- また、入力データのメタデータ（宛先情報等）をFirestoreへ書き込む。※Firestoreは必要に応じて実装すること。
- EventarcがCloud Storageへのファイル出力を検出し、署名付きURLの生成/通知を行う関数を呼び出す。
- 署名付きURLの生成/通知を行う関数が署名付きURLを発行する。
- Firestoreからメタデータを読み込み、SendgridのAPIキー（認証情報）をSecret Managerから取得し、署名付きURLを利用者へ通知する。※Sendgridを利用する際はAPIキーが必要となるため、ヘルプデスクから問い合わせを行うこと。
- 利用者はCloud Storageからファイルをダウンロードし、印刷する。
- 本機能は他の機能が出力するデータをもとに郵送書類を作成する機能である。
- なお、作成する郵送書類は郵送ラベル等の簡易的かつ一般的なフォーマットであること前提としている。
- 他機能はCloud Load BalancingへデータをREST APIで送信することで、郵送書類の生成を開始する。
- Cloud Armorにより、Cloud Load Balancingへの攻撃からから保護したり、バックエンドの保護を行う。
- Serverless NEG内のCloud RunまたはCloud Functionsは入力データを元に必要な書類をPDFなどの形式でCloud Storageへ出力する。
- また、入力データのメタデータ（宛先情報等）をFirestoreへ書き込む。※Firestoreは必要に応じて実装すること。
- EventarcがCloud Storageへのファイル出力を検出し、ファイル送付を行う関数を呼び出す。
- ファイル送付を行う関数がFirestoreからメタデータを読み込み、SendgridのAPIキー（認証情報）をSecret Managerから取得し、ファイルを利用者へ送付する。※Sendgridを利用する際はAPIキーが必要となるため、ヘルプデスクから問い合わせを行うこと。
- 利用者は受領したメールからファイルを取得し、印刷する。
- 法令により定められた帳票の作成を行う。
- 届出・申請の結果などを法令で定められた形式で帳票として作成する業務
-
帳票の元データを出力
- 申請・届出_申請・届出機能
- 審査・承認_審査・承認機能
-
帳票を保管
- 申請・届出_公文書ダウンロード機能
- 申請・届出_公文書公開機能
-
帳票を外部システムに連携
- 外部連携_申請処理連携機能
- 利用者通知_メッセージ通知機能
- Cloud Pub/Sub、Cloud FunctionsまたはCloud Runを使ってサーバレスでマネージドに帳票作成を実現
- 他の機能ブロックが帳票作成のリクエストを送信する。Cloud Pub/Subへ通知送信のリクエストが送信されたことを契機として、Cloud FunctionsまたはCloud Runが自動的に起動する。
- Cloud Functions・Cloud Runはプログラムの実行環境をサーバレスで提供するものであり、帳票作成処理の実行環境を容易に構築可能である。
- 帳票のファイル形式としてPDFを想定するが、PDFの作成機能はマネージドサービスとして提供されていない。
したがって、PDFの作成に必要なライブラリの導入が必要である。ライブラリの仕様によってはコンテナイメージを実行可能なGKEも選択肢として検討できる。 - 作成した帳票は他の機能ブロック内に存在するストレージに保管したり、外部連携機能を使用して他システムに連携する。
6-1-9-1. 書類出力_書類出力機能
概要：
達成できる業務：
連携機能ブロック：
アーキテクチャのポイント：
書類出力_書類出力機能（パターン１ 署名付きURLからのダウンロード）
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
[4]
書類出力_書類出力機能（パターン２ ファイル送付）
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
[4]
6-1-9-2/3. 書類出力_法定帳票作成機能
概要：
達成できる業務：
連携機能ブロック：
アーキテクチャのポイント：
書類出力_法定帳票作成機能
ブロック実現例
ブロック実現例 説明
6-2. 非機能ブロック
以下の項目は折りたたまれているため、詳細を確認するには三角ボタンを押下すること。
6-2-1. 利用者認証
- 行政サービスの利用にあたり国民/企業ユーザ/職員の識別情報を用いて認証を行う。
- 利用者本人であることの確認を行う業務
- 利用者の情報を管理する業務
- 認証前のトップ画面を表示
- コンテンツ管理_Webページ（静的コンテンツ）公開機能
- 利用者の認証を要する機能
- 申請・届出_申請・届出機能
- 申請・届出_公文書ダウンロード機能 など
- 認証機能を提供するFirebase AuthenticationおよびIdentity Platformは、単体でのメール/パスワード認証やソーシャルログインなどのサービスに加え、OpenID Connect及びSAML2.0に対応した外部サービスと連携可能。Firebase Authenticationは、他のFirebaseサービスとシームレスに連携可能。Identity Platformには、稼働率99.95%のSLAが含まれる。
- ユーザの認証では外部のID管理システムとの連携を行う。
- 標準的な認証の仕様であるOpenID Connectのフローに従い、ユーザの認証を行う。
- Firebase Authenticationを使用し、外部IDプロバイダと連携することでユーザは認証(ログイン)される。
- 認証済みユーザのみがアクセス可能なセキュリティルールを設定したCloud Firestoreへリクエストする。
- Cloud Firestoreに格納されたユーザ情報に対して、新規作成や更新等の操作を行う。
- Firebase Authenticationが発行したトークンによる認可を行い、他のWebAPIを提供する機能ブロックへアクセスする。
- ユーザの認証では外部のID管理システムとの連携を行う。
- 標準的な認証の仕様であるOpenID Connectのフローに従い、ユーザの認証を行う。
- Identity Platformを使用し、外部IDプロバイダと連携することでユーザは認証(ログイン)される。
- ユーザ情報を管理するためのWebAPIはCloud Load Balancing/Cloud Functions/Firestoreにより構築される。
- またCloud Armorによりインターネット経由で行われる様々な攻撃からAPIを保護する。
- Cloud Functionsは、Identity Platformにトークンの有効性確認を行う。
- Firestoreに格納されたユーザ情報に対して、Cloud Functionsから新規作成や更新等の操作を行う。
- Identity Platformが発行したトークンによる認可を行い、WebAPIを提供する他の機能ブロックへアクセスする。
- 外部のID管理との連携が不要な場合、Firebase Authenticationを利用してのIDとパスワードの管理が可能である。
- 認証済みユーザのみがアクセス可能なセキュリティルールを設定したCloud Firestoreへリクエストする。
- Cloud Firestoreに格納されたユーザ情報に対して、新規作成や更新等の操作を行う。
- Firebase Authenticationが発行したトークンによる認可を行い、WebAPIを提供する他の機能ブロックへアクセスする。
- 外部のID管理との連携が不要な場合、Identity Platformを利用してのIDとパスワードの管理が可能である。
- ユーザ情報を管理するためのWebAPIはCloud Load Balancing/Cloud Functions/Firestoreにより構築される。
- またCloud Armorによりインターネット経由で行われる様々な攻撃からAPIを保護する。
- Cloud Functionsは、Identity Platformにトークンの有効性確認を行う。
- Firestoreに格納されたユーザ情報に対して、Cloud Functionsから新規作成や更新等の操作を行う。
- Identity Platformが発行したトークンによる認可を行い、WebAPIを提供する他の機能ブロックへアクセスする。
- WebAPIを提供する他の機能ブロックへアクセスする。
- リクエストはIdentity-Aware Proxyにインターセプトされ有効な認証トークンがあるかどうかチェックされる。
- 有効なトークンが無い場合、Googleログインへリダイレクトされ、認証を行う。
- 認証が成功すると、Identity-Aware Proxyから認証トークンを取得し、[1]のWebAPIにリダイレクトされる。
- 認証トークンがIdentity-Aware Proxyで有効と確認された場合、リクエストはバックエンドサービスにアクセス可能となる。
6-2-1-1. 利用者認証_ユーザ認証機能
概要：
達成できる業務：
連携機能ブロック：
アーキテクチャのポイント：
利用者認証_ユーザ認証機能（パターン1 外部IDプロバイダ連携 Firebase）
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
利用者認証_ユーザ認証機能（パターン2 外部IDプロバイダ連携 Identity Platform）
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
[4]
※Identity-Aware ProxyにおいてIdentity Platformを使用することで、Googleアカウントの代わりに外部IDプロバイダを利用したユーザー認証が可能となるため、当該実現例の代替策となる。
詳細については、以下を参照すること。
[外部ID]
https://cloud.google.com/iap/docs/external-identities?hl=jaOpens in new tab
利用者認証_ユーザ認証機能（パターン3 小規模システム向け Firebase）
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
利用者認証_ユーザ認証機能（パターン4 小規模システム向け Identity Platform）
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
[4]
※Identity-Aware ProxyにおいてIdentity Platformを使用することで、Googleアカウントの代わりに外部IDプロバイダを利用したユーザー認証が可能となるため、本構成の代替策となる。
詳細については、以下を参照すること。
[外部ID]
https://cloud.google.com/iap/docs/external-identities?hl=jaOpens in new tab
利用者認証_ユーザ認証機能（パターン5 Identity-Aware Proxy）
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
[4]
※ Identity-Aware Proxyがサポートするバックエンドサービスとして、App Engine、Cloud Run、Compute Engine、Google Kubernentes Engine、オンプレミスが挙げられる。
詳細については以下を参照すること。
[Identity-Aware Proxy の概要]
https://cloud.google.com/iap/docs/concepts-overview?hl=jaOpens in new tab
6-2-8. 外部連携
- 外部システムへ当該行政システム利用の一次権限の付与を行う。
- 機能を呼び出すシステムが正当であることの確認を行う業務
- システムの認証を要する機能
- 申請・届出_申請・届出機能 など
- Workload Identity Poolを利用してサービスアカウントキーの発行なしにGoogle Cloudリソースへアクセスする。
- Workload Identity Poolを利用して外部IDプロバイダと連携する。
- 外部システムは、外部IDプロバイダに認証を行い、クレデンシャル情報を取得する。
- Security Token Servicesでクレデンシャル情報の正当性をWorkload Identity Poolに登録した情報を使ってチェックし、一時トークンを作成する。
- 一時トークンを使ってサービスアカウントになりすまし、Google Cloudリソースにアクセスする。
6-2-8-1. 外部連携_システム間認証機能
概要：
達成できる業務：
連携機能ブロック：
アーキテクチャのポイント：
外部連携_システム間認証機能
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
[4]
6-2-11. セキュリティ
- 発見的統制に抵触する操作、設定、脆弱性の有無を検知し、ダッシュボードへの表示と通知を行う。
- セキュリティ管理および検知などの業務
- 管理対象セキュリティデータの収集
- 各機能（業務アプリケーション）
- Google Cloudには、さまざまなセキュリティソリューションが含まれており、各種リソースと組み合わせることでセキュリティ対策を講じることが可能。
- Artifact Analysisを用いて、Artifact Registryに保管するコンテナイメージに対する脆弱性スキャンを行う。
- Binary Authorizationにて、コンテナベースのアプリケーションを開発してデプロイする際に、ソフトウェア サプライ チェーンのセキュリティ対策を実装する。
- 監査ログを有効にすることで、管理アクティビティ監査ログやデータアクセス監査ログなどを記録し、監視設定することで異常検知を行うことができる。
- Cloud Armorにて、DDoS攻撃に対する保護を行う。
- Security Command Centerのダッシュボードから発見的統制によって検出された結果を確認ができる。また、通知メッセージを運用者に送付する構成を組んだ場合には、条件に応じて運用者が通知を受け取ることも可能。
- Security Command Centerの設定は、組織の発見的統制として必須適用テンプレートで定義されており、利用プロジェクトはその設定を継承している。
※詳細は、技術マニュアル「発見的統制内容説明(Google Cloud編)Opens in new tab」を参照すること。 - 利用システムへのセキュアなアクセスを実現する。
- 利用システムへのセキュアなアクセスを実現する
- 通信を介した攻撃への保護が必要な機能ブロック
- 各機能（業務アプリケーション）
- Google Cloud Armorを配置し、Cloud Load Balancing及びバックエンドの保護を行う。
- Identity-Aware Proxyを利用することで、アプリケーションへのアクセスに対する認証/認可の機能を実現する。
- Artifact Registry及びArtifact Analysis、Binary Authorizationを利用することで、コンテナイメージに対する安全性を向上させる。
- Cloud NGFWを配置し、ネットワーク層に対するセキュリティを実現する。
- IAMによってクラウドリソースへのアクセスを制限する。
- Security Command Centerのダッシュボードから発見的統制によって検出された結果を確認ができる。また、通知メッセージを運用者に送付する構成を組んだ場合には、条件に応じて運用者が通知を受け取ることも可能。
- Security Command Centerの設定は、組織の発見的統制として必須適用テンプレートで定義されており、利用プロジェクトはその設定を継承している。
※詳細は、技術マニュアル「発見的統制内容説明(Google Cloud編)Opens in new tab」を参照すること。 - Google Cloud Armorにより、Cloud Load Balancing及びバックエンドの保護を行う。※強力なDDoS対策が求められる場合、Google Cloud Armor Enterpriseの利用も検討すること。
- Identity-Aware Proxyにて、アプリケーションへのアクセスに対する認証/認可の機能を実現する。
- Artifact Registry及びArtifact Analysisを用いて、コンテナイメージに対する脆弱性スキャンを行う。
- Binary Authorizationにて、コンテナベースのアプリケーションを開発してデプロイする際に、ソフトウェア サプライ チェーンのセキュリティ対策を実装する。
- Cloud Firewall Rulesにより、VPC上の通信に対してFirewall機能を実現する。
- Cloud NGFWにより、VPC上の通信に対してIPS/IDS機能を実現する。 ※Cloud NGFW Enterpriseを選択する必要があるため、必要に応じて利用を検討すること。
- 利用システムにおける保管データの暗号化などを実現する。
- 利用システムにおける保管データの暗号化を実現する
- データの暗号化が必要な機能
- 各機能（業務アプリケーション）のデータ保管機能
- ログ管理_ログ管理機能
- バックアップ_バックアップ機能
- 暗号化要件に合わせ、Googleのデフォルトの暗号化または、Cloud KMSで生成した顧客管理の暗号鍵を使用する。
- データ保護が必要な業務データを分類し、対象データを保管するリソースに対して、Googleのデフォルトの暗号化または、Cloud KMSで生成した顧客管理の暗号鍵で暗号化を実施する。※暗号鍵の所有、鍵マテリアルの管理等の要件がある場合にCloud KMSの顧客管理の暗号鍵を選択する。
- データ保護が必要なログデータを分類し、対象データを保管するリソースに対して、Googleのデフォルトの暗号化または、Cloud KMSで生成した顧客管理の暗号鍵で暗号化を実施する。※暗号鍵の所有、鍵マテリアルの管理等の要件がある場合にCloud KMSの顧客管理の暗号鍵を選択する。
- データ保護が必要なバックアップデータを分類し、対象データを保管するリソースに対して、Googleのデフォルトの暗号化または、Cloud KMSで生成した顧客管理の暗号鍵で暗号化を実施する。※暗号鍵の所有、鍵マテリアルの管理等の要件がある場合にCloud KMSの顧客管理の暗号鍵を選択する。
6-2-11-1. セキュリティ_セキュリティ管理機能
概要：
達成できる業務：
連携機能ブロック：
アーキテクチャのポイント：
セキュリティ_セキュリティ管理機能
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
6-2-11-2. セキュリティ_通信を介した攻撃への保護
概要：
達成できる業務：
連携機能ブロック：
アーキテクチャのポイント：
セキュリティ_通信を介した攻撃への保護
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
[6]
6-2-11-3. セキュリティ_保管データの暗号化
概要：
達成できる業務：
連携機能ブロック：
アーキテクチャのポイント：
セキュリティ_保管データの暗号化
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
6-2-12. ネットワーク
- 府省庁拠点や他システムとの専用線接続（GSSネットワーク、NaaS、情報提供NW、LGWANなど）を提供する。
- 府省庁拠点や他システムとの専用線接続（GSS）を提供する
- 行政システム、拠点と接続が必要な機能ブロック
- 各機能（業務アプリケーション）
- 各パターンのユースケースを記載（詳細は各パターンを参照）
- パターン1 単一VPCとの接続
- 拡張性の考慮が不要であり、シンプルな構成とするケース。
- パターン2 単一VPC + VPC Peeringとの接続
- VPC Peeringを利用して、複数のプロジェクトでCloud Interconnectを共有するケース。
- VPC Peeringの制約（Peering数の上限等）が問題とならないケース。
- パターン3 共有VPCとの接続
- 共有VPCでネットワークを管理し、複数のプロジェクトでCloud Interconnectを共有するケース。
- VPC Peeringの制約（Peering数の上限等）に抵触する可能性があり、複数のシステム間にてVPCを共有することでVPC Peeringの制約を回避するケース。
- パターン4 Network Connectivity Centerとの接続
- VPC、Cloud Interconnect、Cloud VPN、ルーターアプライアンスVM間の相互接続を複数のプロジェクトで実現するケース。
- VPC Peeringの制約（Peering数の上限等）に抵触する可能性があり、Network Connectivity CenterをHubとすることでVPC Peeringの制約を回避するケース。
- パターン1 単一VPCとの接続
- GSSネットワーク経由で利用拠点との接続を実現する。
- Cloud Interconnectを経由してVPCに接続する。
- 行政システム、拠点側から利用システム側の名前解決は、行政システム、拠点側のDNSフォワーダーからCloud DNSへDNSクエリを転送し、DNSインバウンドサーバーポリシーに従って行われる。
- 利用システム側から行政システム、拠点側への名前解決は、Cloud DNSのDNS転送ゾーンに従ってDNSクエリが行政システム、拠点側のネームサーバへ転送し、行われる。
- DNS転送ゾーンを使用することで、特定のドメインだけを行政システム、拠点側に転送することができる。
- 本構成は本番、開発等の環境毎に作成する必要がある。
- ガバメントクラウド利用者は「GCASガイド(メンバー専用ページ)」からネットワーク接続の関連ドキュメントを確認すること。
- GSSネットワーク経由で利用拠点との接続を実現する。
- Cloud Interconnectを経由してVPCに接続する。
- Cloud Routerにて、オンプレミスと接続するVPC Peering先となるVPCの経路情報をオンプレミスへ広報する。
- Cloud Interconnectが接続されたVPCとオンプレミスと接続する連携機能を提供するVPC間にてVPC Peeringを接続する。
- VPC PeeringのImport/Export設定にて、Cloud Interconnectから広報されたオンプレミスの経路情報をオンプレミスと接続する連携機能を提供するVPCが学習する。
- 行政システム、拠点側から利用システム側の名前解決は、行政システム、拠点側のDNSフォワーダーからCloud DNSへDNSクエリを転送し、DNSインバウンドサーバーポリシーに従って行われる。
- Cloud Interconnectが接続されたVPCとオンプレミスと接続する連携機能を提供するVPC間にてDNS Peering（双方向）を接続し、名前解決を行えるようにする。
- 利用システム側から行政システム、拠点側への名前解決は、Cloud DNSのDNS転送ゾーンに従ってDNSクエリが行政システム、拠点側のネームサーバへ転送し、行われる。
- DNS転送ゾーンを使用することで、特定のドメインだけを行政システム、拠点側に転送することができる。
- 本構成は本番、開発等の環境毎に作成する必要がある。
- ガバメントクラウド利用者は「GCASガイド(メンバー専用ページ)」からネットワーク接続の関連ドキュメントを確認すること。
- GSSネットワーク経由で利用拠点との接続を実現する。
- Cloud Interconnectを経由してホストプロジェクトの共有VPCに接続する。
- ホストプロジェクトとサービスプロジェクトにおいて、共有VPCのネットワークと権限の分離が可能だが、正しく設計する必要がある。
- ホストプロジェクトの共有VPCにて、サービスプロジェクトが利用するサブネットを作成し、共有する。
- サービスプロジェクトは共有されたサブネット上にGCE等のVPCリソースを作成する。
- 行政システム、拠点側から利用システム側の名前解決は、行政システム、拠点側のDNSフォワーダーからCloud DNSへDNSクエリを転送し、DNSインバウンドサーバーポリシーに従って行われる。
- 利用システム側から行政システム、拠点側への名前解決は、Cloud DNSのDNS転送ゾーンに従ってDNSクエリが行政システム、拠点側のネームサーバへ転送し、行われる。
- DNS転送ゾーンを使用することで、特定のドメインだけを行政システム、拠点側に転送することができる。
- 本構成は本番、開発等の環境毎に作成する必要がある。
- ガバメントクラウド利用者は「GCASガイド(メンバー専用ページ)」からネットワーク接続の関連ドキュメントを確認すること。
- GSSネットワーク経由で利用拠点との接続を実現する。
- Cloud Interconnectを経由してRouting VPCに接続する。 ※Routing VPCは、Hybrid spokeと関連付けられているリソース（VLAN Attachment等）が存在するVPCを指す。
- VLAN AttachmentはHybrid spokeとしてNetwork Connectivity CenterのHubに接続する。
- オンプレミスと接続する連携機能を提供するVPCはVPC spokeとしてNetwork Connectivity CenterのHubに接続する。※VPC spokeとして接続されたVPC間は相互に通信することが可能となるため、オンプレミスに接続しないVPCも必要に応じてVPC spokeとして接続することが可能。
- 行政システム、拠点側から利用システム側の名前解決は、行政システム、拠点側のDNSフォワーダーからCloud DNSへDNSクエリを転送し、DNSインバウンドサーバーポリシーに従って行われる。
- Cloud Interconnectが接続されたVPCとオンプレミスと接続する連携機能を提供するVPC間にてDNS Peering（双方向）を接続し、名前解決を行えるようにする。
- 利用システム側から行政システム、拠点側への名前解決は、Cloud DNSのDNS転送ゾーンに従ってDNSクエリが行政システム、拠点側のネームサーバへ転送し、行われる。
- DNS転送ゾーンを使用することで、特定のドメインだけを行政システム、拠点側に転送することができる。
- 本構成は本番、開発等の環境毎に作成する必要がある。
- ガバメントクラウド利用者は「GCASガイド(メンバー専用ページ)」からネットワーク接続の関連ドキュメントを確認すること。
6-2-12-1. ネットワーク_行政システム、拠点とのネットワーク接続性確立
概要：
達成できる業務：
連携機能ブロック：
アーキテクチャのポイント：
ネットワーク_行政システム、拠点とのネットワーク接続性確立（パターン1 単一VPCとの接続）
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
[4]
[注]
ネットワーク_行政システム、拠点とのネットワーク接続性確立（パターン2 単一VPC + VPC Peeringとの接続）
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
[注]
ネットワーク_行政システム、拠点とのネットワーク接続性確立（パターン3 共有VPCとの接続）
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
[注]
ネットワーク_行政システム、拠点とのネットワーク接続性確立（パターン4 Network Connectivity Centerとの接続）
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
[注]
6-2-13. 構成管理
- Google Cloudサービスの構成情報を保管可能。また、Cloud Asset Inventoryではアセット検索が可能
- Cloud Asset Inventoryに各アプリケーションが稼働しているGoogle Cloudサービスの構成情報を取得する。
- [1]で取得した情報をGCSやBigQueryに蓄積する。BigQueryに蓄積した情報はクエリによるアセット検索が可能。
6-2-13-1. 構成管理_システム構成管理機能
アーキテクチャのポイント：
構成管理_システム構成管理機能
ブロック実現例
ブロック実現例 説明
CI/CDパイプライン機能を利用して業務アプリケーション機能をデプロイする。
[1]
[2]
6-2-14. バックアップ
- システム内のインスタンス・サービスの設定およびデータを管理する。
- システム内のインスタンス・サービスの設定およびデータを管理する機能
- バックアップ対象データの収集
- 各機能（業務アプリケーション）
- 各Google Cloudリソース毎にバックアップを行う。
- 各Google Cloudリソース毎にバックアップを行う。ここでは、Cloud SQL・BigQuery・Cloud Storageのバックアップについて記載する。
- Cloud SQLでは、オンデマンドバックアップと自動バックアップがあるので用途によって選択する。オンデマンドバックアップは自動で削除されないが、自動バックアップは世代の設定が可能である。
- BigQueryでは、リージョン内の2つのZoneにデータのコピーがデフォルトで保存され、Zone間でレプリケーションされる。
特定時点でのバックアップはテーブルスナップショットを利用する。
[Google Cloudドキュメント：テーブル スナップショットの概要]
https://cloud.google.com/bigquery/docs/table-snapshots-intro?hl=jaOpens in new tab
過去7日間分のデータはタイムトラベルよってデータ保持される。
[Google Cloudドキュメント：タイムトラベルとフェイルセーフによるデータの保持]
https://cloud.google.com/bigquery/docs/time-travel?hl=ja#time_travelOpens in new tab
その他データのバックアップを取得する場合はCloud Storageへのエクスポートを検討する。
[Google Cloudドキュメント：テーブルデータをCloud Storageにエクスポートする]
https://cloud.google.com/bigquery/docs/exporting-data?hl=jaOpens in new tab
バックアップ戦略に関しては下記ドキュメントを参考にすること。
[Google Cloudドキュメント：BigQueryのバックアップと障害復旧の戦略]
https://cloud.google.com/blog/ja/topics/developers-practitioners/backup-disaster-recovery-strategies-bigqueryOpens in new tab
- Cloud Storageでは、ライフサイクルを利用して、保持期間・アクション・ストレージクラスの変更等を行う。
6-2-14-1. バックアップ_バックアップ機能
概要：
達成できる業務：
連携機能ブロック：
アーキテクチャのポイント：
バックアップ_バックアップ機能
ブロック実現例
ブロック実現例 説明
[1]
[Google Cloudドキュメント：Cloud SQLバックアップについて|Cloud SQL for MySQL|]
https://cloud.google.com/sql/docs/mysql/backup-recovery/backups?hl=ja#types_of_backupsOpens in new tab
また、カスタムバックアップ ロケーションを指定することで別リージョンへのバックアップが可能になるため、必要に応じて検討すること。
[2]
[3]
[Google Cloudドキュメント：データ ライフサイクルを管理するオプション]
https://cloud.google.com/storage/docs/control-data-lifecycles?hl=jaOpens in new tab
6-2-15. オブザーバビリティ
- Cloud Monitoringは、ほとんどの Google Cloud サービスと統合されており、これらのサービスに関するパフォーマンス情報を自動的に収集して保存が可能
- アプリケーションが処理するのにかかる時間や、リクエストの処理時に実行されるオペレーションが完了するのにかかる時間を集計する。
- 監視対象の業務アプリケーションが生成するログを集約する。ログベース指標を利用して任意のエラー等のログを通知可能。
- 監視対象の業務アプリケーションの稼働状況を示す様々なメトリクス値を保存する。
- [2][3]で閾値超過時などの異常検出設定に従いメール・Slack等で通知する。また、Cloud LoggingからPub/SubとCloud Functionsを利用してWebhook連携でのSlack等の通知が可能である。
- Cloud Monitoringは、ほとんどの Google Cloud サービスと統合されており、これらのサービスに関するパフォーマンス情報を自動的に収集して保存が可能
6-2-15-1. オブザーバビリティ_システム監視機能
アーキテクチャのポイント：
オブザーバビリティ_システム監視機能
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
[4]
6-2-15-2. オブザーバビリティ_サービス状態監視機能
アーキテクチャのポイント：
オブザーバビリティ_サービス状態監視機能
ブロック実現例
ブロック実現例 説明
Cloud Monitoringでサービス監視対象のURL監視（外形監視）を行う。
収集したサービス応答時間やエラー発生率等をシステム監視機能のダッシュボード上に表示することで、定量的計測を行う。また、稼働時間のチェックも可能。
計測結果を必要に応じて、異常検出設定に従いメール・Slack等で通知する。
6-2-16. ログ管理
- Google Cloud コンソールを使用してログエントリをクエリ、表示、分析が可能
- 監視対象の業務アプリケーションが生成するログを集約し、必要に応じてログのクエリを行って抽出を行う。ログフィルタを利用することでログに係る料金を削減することが可能。
- ログシンクを利用してBigQuery等に転送したログを可視化可能。
- 運用者はLog AnalyticsやBiｇQueryを使って分析を行う。
6-2-16-1. ログ管理_ログ管理機能
アーキテクチャのポイント：
ログ管理_ログ管理機能
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
6-2-18. データ共有
- 複数自治体の情報をDBに保管する際に、自治体ごとに分離せずに統合し、互いに活用するためのデータ格納を実現する。
- 組織横断でのデータ活用する目的で、組織毎に蓄積されるデータセットを複数組織へ共有する業務
- データ利活用について企画・立案する目的で、共有されたデータカタログを検索し、必要となるデータセットを検索する業務
- 別組織のユーザ向けに元のデータセットを複製あるいは移動させることなくセキュアな分析環境を提供することが可能
- Shared Dataset(共有したいデータセット)を作成する。
- Shared DatasetのデータはSource Dataset (共有元となるデータセット)を必要に応じて不要データ削除やマスキングを行ったデータを利用する。
- [1]で作成したShared DatasetをAnalytics HubのListingsにpublish(登録)する。
- Listings Subscriber(サブスクライブ権限を持つ人)が[2]で作成したListingsをSubscribe(購読設定)する。
- 他組織・他プロジェクトのBigQueryで共有したデータセットへの読み取りクエリの実行が可能となる。
6-2-18-1. データ共有_複数組織データ分離格納方法
概要：
達成できる業務：
アーキテクチャのポイント：
データ共有_複数組織データ分離格納方法
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
[4]
6-2-20. メンテナンス
- プライベートネットワーク内のデータベースに対してインターネット経由で直接操作を行う。
- プライベートネットワーク内データベースに対して実施するメンテナンス業務
- 利用者の認証
- 利用者認証_ユーザ認証機能（国民向け）
- 利用者認証_ユーザ認証機能（企業ユーザ向け）
- 利用者認証_ユーザ認証機能（職員向け）
- メンテナンス操作対象のデータベース
- 各機能（業務アプリケーション）
- メンテナンス操作を実行する関数及びサーバーの構築
- CI/CD_CI/CDパイプライン機能
- 構成管理_システム構成管理機能
- メンテナンス操作を実行するサーバーの脆弱性診断及び対処
- セキュリティ_セキュリティ管理機能
- メンテナンス操作の実行ログ及びデータベース監査ログの保管
- ログ管理_ログ管理機能
- 踏み台サーバーを配置し、セキュアにDBへアクセスする方式としている
- Cloud SQL studioまたはAlloyDB studioを利用することでコンソールからプライベートDBへのアクセスを実現
- 認証機能を利用してユーザー認証を行う。
- Identity-Aware Proxyを経由して踏み台サーバーへ接続する。
- 連携機能により、踏み台サーバーの構築、構成管理情報を管理する。
- 連携機能により、踏み台サーバーの脆弱性診断等を行う。
- 踏み台サーバーからCloud SQLまたはAlloyDBへ接続し、DBのメンテナンスを行う。
- 踏み台サーバー上の操作ログ及び監査ログは連携機能へ送信される。
- Google Cloudコンソールへアクセスし、Cloud SQL studioまたはAlloyDB sudioを開く。
- Cloud SQL studioまたはAlloyDB sudioからCloud SQLまたはAlloyDBへ接続し、DBのメンテナンスを行う。
- Cloud SQLまたはAlloyDBの操作ログ及び監査ログは連携機能へ送信される。
6-2-20-1. メンテナンス_DB直接メンテナンス機能
概要：
達成できる業務：
連携機能ブロック：
アーキテクチャのポイント：
メンテナンス_DB直接メンテナンス機能（パターン1 踏み台サーバー）
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
[4]
[5]
[6]
メンテナンス_DB直接メンテナンス機能（パターン2 コンソールアクセス）
ブロック実現例
ブロック実現例 説明
[1]
[2]
[3]
- コスト抑制を目的に本番環境以外の環境のリソースをスケジュールに応じて起動・停止する。
- クラウド環境のリソースの起動および停止をスケジュールに従って実施する業務
- 起動および停止の対象となるリソースを有する機能
- 申請・届出_申請・届出機能
- コンテンツ管理_Webページ(動的コンテンツ)公開機能
- 利用者認証_ユーザ認証機能（国民向け）など
- Cloud SchedulerとCloud Functionsの間にPub/Subを配置することで、疎結合なアーキテクチャとしている。
- 本機能ブロックは、コストへの影響が大きいリソース(データベースまたはコンピューティング)を自動的に起動または停止することで、コストの最適化を図るものである。
- 起動または停止の対象として、検証環境を主に想定する。検証環境は、エンドユーザが操作する環境では無いため、常時稼働する必要性が低いからである。
- Cloud Schedulerの機能を使用し、起動停止イベントをPub/Subへ送信する。Cloud Schedulerは、cron等のスケジュール形式をサポートするサーバレススケジューラである。
[2] - Pub/Subは起動停止イベントを受信し、起動停止処理を実行するCloud Functionsを起動する。
[3] - Cloud Functionsにより、リソースの起動または停止の処理を対象のリソースに対して行う。
- なお、起動または停止の対象となるサービスについて、起動や停止に関する制限事項の有無を事前に確認すること。
6-2-20-2. メンテナンス_起動停止スケジューリング機能
概要：
達成できる業務：
連携機能ブロック：
アーキテクチャのポイント：
メンテナンス_起動停止スケジューリング機能
ブロック実現例
ブロック実現例 説明
[1]
6-2-99. その他
- 組織内の誰でも、コードなしでアプリケーションを構築、拡張可能な機能を提供する。
- ノーコード（コーディング不要）でのアプリケーション開発。下記の AppSheet で利用できる情報や仕掛けが作成可能。
- 複数のデバイスからの利用
- プラットフォーム連携
- スマホ通知
- メール送信
- バーコード、QRコード、NFCタグのスキャン
- Google Mapsを利用した地図情報、位置情報
- 写真撮影、OCR機能
- 電子サイン
- ロジック運用
- レポート作成
- ダッシュボード構築
※公式サイトのテンプレートも併せて参考にすること。
[App templates]
https://www.appsheet.com/templatesOpens in new tab
- なし
- AppSheet では、専用システムを導入することなく、Google Cloud 上で手軽にアプリの開発・運用が可能
- 複雑なプログラムコードの知識やスキルを必要とせず、AppSheetは、コーディング不要でアプリを作成できるプラットフォーム。AIによるアプリ自動作成支援機能も搭載されている。
- AppSheet は、Google サービスとの連携ができることはもちろん、ファイル共有サービスや Microsoft Office の各種サービス、Salesforce など豊富な外部サービスと連携でき、企業はさまざまなデータソースを中心にアプリを設計・運用可能
- スプレッドシートやデータベースなど、豊富なデータソースからアプリを作成することができ、認証プロバイダーも豊富にサポートしています。ブラウザだけで、アプリ䛾開発と利用ができる。
- AppSheetは、ガバナンスやセキュリティ対策が用意されているため、安心してアプリを利用することが可能。
6-2-99-2. その他_ローコード開発機能
概要：
達成できる業務：
連携機能ブロック：
アーキテクチャのポイント：
ブロック実現例
本ブロックは、AppSheet を含めた実現例を示している「6-1-4-4/5. データ管理_統計処理機能/統計情報公開機能」のシステム構成図を参照すること。
なお、ガバメントクラウドにおけるAppSheetの利用はライセンスやユーザ管理に伴う課題が懸念されるた
め、AppSheetの利用を検討される際は、GCASヘルプデスクの問い合わせを通じてデジタル庁へ事前に相談すること。
改訂履歴
| 改訂年月日 | 改訂理由 |
|---|---|
| 2023 年 11 月 2 日 | 新規作成 |
| 2023 年 12 月 22 日 | 業務ブロックおよび非機能ブロックの並び替え、名称変更、拡充 |
| 2024 年 03 月 29 日 | 「4章 システム構成検討における留意事項」の追加に伴う章構成変更 |
| 読みやすさ向上のため全体的な記載構成の見直し | |
| 2024 年 07 月 19 日 | 「6-1-2-2. 申請・届出_添付資料管理機能」「6-1-2-3. 申請・届出_ステータス管理機能」「6-1-2-5. 申請・届出_公文書公開機能」を追記 |
| 文言の修正 | |
| 2024 年 07 月 30 日 | 「6-1-9-1. 書類出力_書類出力機能」「6-2-11-2. セキュリティ_通信を介した攻撃への保護」を追記 |
| 2024 年 09 月 02 日 | 「6-2-11-3. セキュリティ_保管データの暗号化」6-2-12-1. ネットワーク_行政システム、拠点とのネットワーク接続性確立」「6-2-20-1. メンテナンス_DB直接メンテナンス機能」を追記 |
| 2024 年 10 月 01 日 | 「6-2-20-2. メンテナンス_起動停止スケジューリング機能」を追記 |
| 2025 年 3 月 19 日 | 「6-2-99-1. その他_ノーコード開発機能」のブロック名を「6-2-99-2. その他_ローコード開発機能」に変更 |
| 2025 年 5 月 30 日 | AppSheet利用時の相談方法を追記 |