## 1-1. リファレンスアーキテクチャとはリファレンスアーキテクチャとは、ガバメントクラウドにRebuild移行するシステムのアーキテクチャを検討する際のリファレンスとして提供されるものである。より具体的には、各システムにおいてゼロからシステム構成を検討するのではなく、本リファレンスアーキテクチャをベースにシステム構成を検討されることを想定している。 ## 1-2. リファレンスアーキテクチャの目的本リファレンスアーキテクチャの目的は、各システムにおけるモダン化されたクラウドネイティブなシステム品質の確保に加え、アーキテクチャ設計の生産性を向上することにある。また、アーキテクチャ設計における車輪の再発明を最小化し、優れた設計を広く共有することも企図している。更には、リファレンスアーキテクチャを用いることで、見積り依頼や調達仕様書で示すシステム構成についても、品質と生産性の向上が期待される。 ## 1-3. リファレンスアーキテクチャの構成本リファレンスアーキテクチャは以下の内容で構成する。 | 項目 | 概要 | |------|-----| |ブロック⼀覧|多くの⾏政システムが必要とする業務的な機能を業務ブロック、非業務的な機能を⾮機能ブロックとして分類し⼀覧化している。| |代表的なシステムパターン | 代表的なシステムパターンとそれを構成するためのブロックの組み合わせを例⽰している。
「個別に実装」とされているものは各システム毎に実装する必要があるが、「共用サービス化も可能」とされているものは、共用サービスとしてプロジェクト、事業者、各府省等の単位で共用サービス化すること、ガバメントクラウド上でSaaS化することも想定される。 | |システムアーキテクチャ例|行政における代表的なシステムのシステム構成例を一定の最適化を行った上で挙げている。| |ブロック実現例|業務ブロック、⾮機能ブロックの各クラウドサービス（CSP）上での実装例を挙げている。
システム構築時にはベースとするCSPは原則として一つにすべきだが、SaaSや共通サービスが別CSPになることは問題ない。| ## 1-4. リファレンスアーキテクチャの活用ポイントガバメントクラウドにおけるシステム刷新では、**ガバメントクラウド手続き概要**に挙げる工程「システム計画」,「予算要求」,「調達」やその後の「設計・構築」に沿ってシステム構成を具体化・最適化していくことになる。本章では、各工程の想定タスクを交えてリファレンスアーキテクチャの活用ポイントを紹介する。一連の工程や実施主体は図表1-4-1 を前提とし、また、タスク内容やインプット・アウトプットなどは一例として記載している。実際のシステムや体制に応じて適宜読み替えつつ、システム構成を検討する際にリファレンスアーキテクチャを活用されたい。なお、システム刷新検討にあたってはPMOにクラウドCoEを併設し、各工程でクラウドCoEに相談することを推奨する。 ![ガバメントクラウド移行におけるタスク](/images/general_ra-01_migration_journery.png) 図表1-4-1: システム刷新工程ごとのタスク、および実施主体 ### 【 1 】システム要件抽出システム計画工程では、システムに求める要件（機能、非機能）や調達スコープを検討し、後続工程のインプットとなりえる情報の収集、整理が求められる。本工程のタスクはリファレンスアーキテクチャを利用しない想定であり、「ガバメントクラウド手続き概要 2.システム計画」に準じるため、そちらを参照されたい。また、本工程は要件を決定するのではなく、移行の方向性を固めることが主な目的であることを留意されたい。 ![システム要件抽出](/images/general_ra-01_migration_journery_task1.png) 図表1-4-2: システム要件抽出タスク概要 ### 【 2 】ブロックマッピング、見積もり取得予算要求工程における「ブロックマッピング」では、前工程で定義した移行スコープや要件をもとにシステム全体像の具体化を行ったうえで、移行費用を見積もるためのインプット情報を整理する。具体的に、前工程で検討した機能一覧や業務フローなどと本リファレンスアーキテクチャをもとにしてシステムの全体像を描く工程となる。また、「見積もり取得」でシステム全体像をインプットとして、モダン技術に明るい事業者に依頼してクラウド利用料概算を見積もるのが好ましい。 ![ブロックマッピング、見積もり取得](/images/general_ra-01_migration_journery_task2.png) 図表1-4-3: ブロックマッピング、見積もり取得タスク概要
![ブロックマッピング、見積もり取得詳細](/images/general_ra-01_migration_journery_task2_detail.png) 図表1-4-4: ブロックマッピング、見積もり取得タスク詳細 ### 【 3 】アーキテクチャ最適化調達工程における「アーキテクチャ最適化」では、モダン技術に明るい事業者が主体となり、フィジビリティ向上やコスト最適化の観点で必要に応じて前工程までに策定したシステム構成をブラシュアップする。利用予定機能のブロック間連携の具体化、また、非機能要件をもとにしたブロックパターンの見直しなどを想定する。 ![アーキ最適化](/images/general_ra-01_migration_journery_task3.png) 図表1-4-5: アーキテクチャ最適化タスク概要 ### 【 4 】仕様書反映調達工程における「仕様書反映」では、これまでに整理した移行システム要件や構成を用いて、RFPの開示や環境審査のための各種申請を行う。本工程のタスクはリファレンスアーキテクチャを利用しない想定であり、「ガバメントクラウド手続き概要 2.システム計画」に準じるため、そちらを参照されたい。 ![仕様書反映](/images/general_ra-01_migration_journery_task4.png) 図表1-4-6: 仕様書反映タスク概要 ### 参考 (1),(2),(5) [ブロック一覧、システムアーキテクチャ例一覧](https://guide.gcas.cloud.go.jp/general/reference-architecture-overview/#2-ブロック一覧) (3) [利用CSPごとのリファレンスアーキテクチャ](https://guide.gcas.cloud.go.jp/general/quotation-request-procurement/) 5～8章 (4) [ブロック、システムアーキテクチャ例 DL資材](https://guide.gcas.cloud.go.jp/general/reference-architecture-document-download/) (6) [調達仕様書ひな形](https://guide.gcas.cloud.go.jp/member/member-general/quotation-request-procurement/) ### 留意事項本リファレンスアーキテクチャやブロックは全ての機能を網羅するものではないため、適宜、各システムにおいて必要なブロックを追加されたい。また、追加されるブロックに汎用性が期待される場合やより優れた実装を行う場合、内容陳腐化が明らかな場合には、ガバメントクラウドチームにフィードバックをお願いしたい。また、政府情報システムには特殊で例外的なシステムも少なからず存在する。これらのシステムにおいては、本リファレンスアーキテクチャのシステム構成例や業務ブロックでは単純に対応できないことが想定される。そのような場合は業務ブロックの技術要素を活用して業務機能を独自に検討されたい。また、そのような場合においても非機能ブロックは共通的に利用できるので、非機能ブロックについては積極的に活用されたい。 # 2. ブロック一覧行政システムが備える共通的な機能処理を**業務ブロック**、**非機能ブロック**ごとに挙げる。 ## 2-1. 業務ブロック | 項番 | ブロック名 | 説明 | 含有機能 | 共用サービス化/個別実装 | |------|------------|--------------|----------|--------| | 1-1-1 | 利用者認証_本人確認機能（レベルA） | 行政サービスの利用にあたり保証レベルに応じた本人確認を行う。
（身元確認保証レベル3、当人認証確認レベル3） | ・マイナンバーカードやそれ相当の身元確認でのアカウント作成
・マイナンバーカードやそれ相当の当人認証でのサービス利用認可
・マイナンバーカードによる電子署名を付与 | 共用サービス化も可能 | | 1-1-2 | 利用者認証_本人確認機能（レベルB） | 行政サービスの利用にあたり保証レベルに応じた本人確認を行う。
（身元確認保証レベル2、当人認証確認レベル2） | ・マイナンバーカードやそれ相当の身元確認でのアカウント作成
・多要素認証（知識認証、所有物認証、生体認証）による当人認証でのサービス利用認可 | 共用サービス化も可能 | | 1-1-3 | 利用者認証_本人確認機能（レベルC） | 行政サービスの利用にあたり保証レベルに応じた本人確認を行う。
（身元確認保証レベル1、当人認証確認レベル1） | ・メールアドレスや電話番号など身元確認不要情報を用いたアカウント作成
・単要素認証による当人認証でのサービス利用認可 | 共用サービス化も可能 | | 1-2-1 | 申請・届出_申請・届出機能 | 所管する行政手続について利用システムを通じて申請・届出の受付、修正、取り下げを行う。 | ・申請・届出画面の表示
・入力データの保存
・利用者への受理通知
・入力データ、および提出ファイルの形式チェック | 共用サービス化も可能 | | 1-2-2 | 申請・届出_添付資料管理機能 | 申請・届出時に添付する本人確認者や各種証明書等の資料の管理を行う。 | ・添付ファイルのアップロード受付 | 共用サービス化も可能 | | 1-2-3 | 申請・届出_ステータス管理機能 | 利用者や職員による申請・届出を行った案件のステータス照会を行う。 | ・ステータス画面の表示
・利用者、案件ごとのステータスの取得 | 個別に実装 | | 1-2-4 | 申請・届出_公文書ダウンロード機能 | 利用者に対して申請・届出を行った案件する行政機関からの電子公文書交付を行う。 | ・ダウンロード用URLの発行 | 共用サービス化も可能 | | 1-2-5 | 申請・届出_公文書公開機能 | 行政機関から発出する電子公文書のインターネット公開を行う。 | ・公開用ファイルの登録
・公開時限の設定 | 共用サービス化も可能 | | 1-2-6 | 申請・届出_手数料等電子納付機能 | 申請時の手続き費用、税金などの国民から国への納付に係る金銭処理を行う。| ・納付データの登録
・納付データの外部連携 | 共用サービス化も可能 | | 1-2-7 | 申請・届出_補助金等電子交付機能 | 申請後の補助金交付、還付金などの行政機関から国民への公金交付の金銭処理を行う。 | ・交付データの登録
・交付データの外部連携 | 共用サービス化も可能 | | 1-2-8 | 申請・届出_電子決裁機能 | 申請から承認までの決裁ワークフロー、および申請案件管理（登録、更新、参照）を行う。 | ・ワークフローの登録、更新
・案件ごとの決裁処理（承認、差し戻しなど） | 個別に実装 | | 1-3-1 | 審査・承認_審査・承認機能 | 行政業務における審査の受付やその承認処理を行う。 | ・審査依頼画面、審査画面の表示
・案件登録
・案件ステータス更新（承認、差し戻しなど） | 個別に実装 | | 1-4-1 | データ管理_データ連携機能 | 申請・届出等で登録された当該システム内の他機能でも扱えるように、必要に応じて加工（名寄せや個人情報マスキングなど）や情報付与（未納税金額や債権など）を行う。
また、処理を行ったの情報を他機能が利用可能なかたちで保管する。| ・保持情報の整形
・保持情報の更新、統合
・他機能での利用を目的した情報の保管 | 個別に実装 | | 1-4-2 | データ管理_データ収集機能 | 利用者からWebフォームやファイルにより送付されるデータを受領し、保管する。 | ・Webフォームの表示
・入力データの保存
・（既存含む）Webフォーム、ファイルのデータチェック
・ファイルへのOCR処理によるデータ抽出、および保存 | 共用サービス化も可能 | | 1-4-3 | データ管理_分析用ダッシュボード機能 | 行政データ分析を行うためのダッシュボードの提供、および分析に必要な前処理やダッシュボード管理を行う。 | ・データを可視化するために必要となる事前処理
・分析用ダッシュボードの作成
・分析用ダッシュボードの表示 | 個別に実装 | | 1-4-4 | データ管理_統計処理機能 | 行政データの統計処理を行う。 | ・対象データに対してETL処理（抽出データの変換）
・処理完了データの保管 | 個別に実装 | | 1-4-5 | データ管理_統計情報公開機能 | 行政に係る統計データをダッシュボードとして公開する。 | ・データを可視化するために必要となる事前処理
・分析用ダッシュボードの作成
・分析用ダッシュボードの表示 | 共用サービス化も可能 | | 1-4-6 | データ管理_文書検索機能 | 蓄積した複数の文書（ファイルやWebコンテンツ）から特定キーワードを全文検索する。 | ・全文検索 | 個別に実装 | | 1-4-7 | データ管理_IoT連携機能 | IoTデバイスやセンサからの観測データを取り込む。 | ・ IoTデバイスと利用システムとの接続性の確立
・データ取り込みパイプラインとの連携 | 共用サービス化も可能 | | 1-4-8 | データ管理_大量データ取り込み機能 | 高頻度に送られてくる観測データやリアルタイム集計が必要となるデータの管理、集計、保存を行う。 | ・データ取り込み用パイプライン作成
・リアスタイム集計
・データ蓄積 | 個別に実装 | | 1-5-1 | 利用者通知_メッセージ通知機能 | 利用者に対して申請・届出を行った案件に関連する通知や手続に関する案内を行う。 | ・利用者へのメッセージ通知（受付、完了、補正指示など） | 共用サービス化も可能 | | 1-5-2 | 利用者通知_プッシュ通知機能 | 行政スマホアプリに対して通知や手続に関する案内を行う。 | ・利用者へのプッシュ通知（受付、完了、補正指示など） | 共用サービス化も可能 | | 1-5-3 | 利用者通知_アラート通知機能 | 緊急性のあるメッセージをあらかじめ登録されているメールアドレスやSMSなどにアラート通知する。 | ・通知登録先へのアラートメッセージ通知 | 共用サービス化も可能 | | 1-6-1 | コンテンツ管理_Webページ（静的コンテンツ）公開機能 | 職員による登録、もしくはサーバにて生成されたWebページを利用者に提供する。 | ・公開コンテンツの保管
・公開時限設定
・ Webページ生成 | 個別に実装 | | 1-6-2 | コンテンツ管理_Webページ（動的コンテンツ）公開機能 | 動的に生成されるWebページ（電子掲示板や個人情報表示、検索ツールなど）を利用者に提供する。 | ・利用者アクセスごとの動的コンテンツ生成と表示 | 個別に実装 | | 1-6-3 | コンテンツ管理_Webコンテンツ管理（CMS）機能 | Webページで配信するコンテンツ（テキストや画像、ファイル）の管理を行う。 | ・コンテンツ管理
・コンテンツ保持用リポジトリ | 個別に実装 | | 1-7-1 | コミュニケーション_問い合わせフォーム機能 | 職員、もしくは利用システムと利用者とのコミュニケーションを目的にメール受領、メール配信を提供する。 | ・メール配信、受信 | 共用サービス化も可能 | | 1-7-2 | コミュニケーション_コールセンター/チャット機能 | 職員、もしくは利用システムと利用者とのコミュニケーションを目的に音声ガイダンス、チャット機能を提供する。 | ・リアルタイムチャット
・電話応答 | 共用サービス化も可能 | | 1-7-3 | コミュニケーション_チャットボット機能 | 職員、もしくは利用システムと利用者とのコミュニケーションを目的にチャットボットを提供する。| ・チャットボット
・検索対象データの管理 | 共用サービス化も可能 | | 1-7-4 | コミュニケーション_ヘルプデスク支援機能 | 職員と行政サービス利用者とのコミュニケーションの円滑化を目的にヘルプデスク支援を行う。 | ・問い合わせ管理
・ FAQ管理 | 共用サービス化も可能 | | 1-8-1 | 外部連携_申請処理連携機能 | 申請・届出の案件処理にあたって後続処理のために外部システムの機能（API）を呼び出す。 | ・ API実行 | 個別に実装 | | 1-8-2 | 外部連携_外部連携機能（API公開） | 外部システムからの処理を受け付けるための機能（API）を公開する。 | ・ API公開 | 共用サービス化も可能 | | 1-9-1 | 書類出力_書類出力機能 | 郵送宛名ラベルや送付書類などの業務関連書類を出力する。
以下のサブ機能から構成される。 | ・印刷書類のダウンロード
・印刷委託事業者への原稿送付 | 共用サービス化も可能 | | 1-9-2 | 書類出力_法定帳票作成機能（外部） | 法令により定められた帳票（国民向け）の作成を行う。 | ・利用者識別子割り当て
・入力フォーマット表示
・入力データの形式チェック
・入力データの保存 | 共用サービス化も可能 | | 1-9-3 | 書類出力_法定帳票作成機能（内部） | 法令により定められた帳票（システム利用府省庁向け）の作成を行う。 | ・利用者識別子割り当て
・入力フォーマット表示
・入力データの形式チェック
・入力データの保存 | 個別に実装 | | 1-10-1 | スマホアプリ連携_スマホアプリ連携機能 | スマホアプリをユーザインタフェースとして利用する。|・認証
・プッシュ通知| 共用サービス化も可能 | | 1-99-1 | 意思決定管理機能 | 業務に係るルールやプロセスをもとにした一貫した意思決定や自動化のサポート機能を提供する。 | - | 個別に実装 | ## 2-2. 非機能ブロック | 項番 | ブロック名 | 説明 | 含有機能 | 非機能推奨ブロック | 利用イメージ | 共用サービス化/個別実装 | |------|------------|--------------|----------|----------|----------|--------| | 2-1-1 | 利用者認証_ユーザ認証機能（国民向け） | 行政サービスの利用にあたり国民固有の識別情報を用いて認証を行う。 | ・ユーザ識別子の追加、更新、保持
・外部連携（フェデレーション）
・ユーザの認証、トークン発行 | - | トークン払い出し、認証処理などは自動で行われる。
必要に応じて利用者アカウントをIDプロバイダのユーザプールに登録、更新、削除を手動で行う。| 共用サービス化も可能 | | 2-1-2 | 利用者認証_ユーザ認証機能（企業ユーザ向け） | 行政サービスの利用にあたり企業ユーザ固有の識別情報を用いて認証を行う。 | ・ gBizIDとの連携（発行トークンを用いた認可）
・ユーザ識別子の追加、更新、保持
・外部連携（フェデレーション）
・ユーザの認証、トークン発行 | - |トークン払い出し、認証処理などは自動で行われる。
必要に応じて企業ユーザアカウントをIDプロバイダのユーザプールに登録、更新、削除を手動で行う。| 共用サービス化も可能 | | 2-1-3 | 利用者認証_ユーザ認証機能（職員向け） | 行政サービスの利用にあたり職員固有の識別情報を用いて認証を行う。 | ・ユーザ識別子の追加、更新、保持
・外部連携（フェデレーション）
・ユーザの認証、トークン発行 | - | トークン払い出し、認証処理などは自動で行われる。
必要に応じて職員アカウントをIDプロバイダのユーザプールに登録、更新、削除を手動で行う。 | 共用サービス化も可能 | | 2-8-1 | 外部連携_システム間認証機能 | 外部システムへ当該行政システム利用の一次権限の付与を行う。 | ・ユーザ識別子の追加、更新、保持
・アクセス権限の追加、更新
・ Web API公開
・非同期処理連携
・ファイル連携 | - | トークン払い出し、認証処理などは自動で行われる。
必要に応じて連携システムをIDプロバイダのユーザプールに登録、更新、削除を手動で行う。 | 個別に実装 | | 2-11-1 | セキュリティ_セキュリティ管理機能 | 発見的統制に抵触する操作、設定、脆弱性の有無を検知し、ダッシュボードへの表示と通知を行う。 | ・検知されたセキュリティリスク事項のダッシュボード表示、管理
・検知されたセキュリティリスク事項の通知 | 〇 | 脆弱性や不正な操作などの検知や自動復旧は自動で行われる。
運用者は検出されたセキュリティリスクをCSP提供のセキュリティ、インシデントダッシュボードで確認する。 | 個別に実装 | | 2-11-2 | セキュリティ_通信を介した攻撃への保護 | 利用システムへのセキュアなアクセス実現する。 | ・アプリケーション層のファイヤーウォール（WAF）
・高度なDDoS攻撃からの保護（Shield Advanced）
・ネットワーク層のファイヤーウォール（Security Groupなど）
・コンテンツへのアクセス制御（CloudFront）
・ SSL通信の強制
・ドメイン取得、管理 | 〇 | 悪意のある通信の防御、検知、通知は自動で行われる。
運用者はアクセスログなどを分析し、必要に応じて通信元制御やWAFルールの更新を行う。| 個別に実装 | | 2-11-3 | セキュリティ_保管データの暗号化 | 利用システムにおける保管データの暗号化などを実現する。 | ・保持するデータの暗号化の強制 | 〇 | 業務データやログデータ、バックアップデータなどをセキュアに保管する。 | 個別に実装 | | 2-12-1 | ネットワーク_行政システム、拠点とのネットワーク接続性確立 | 府省庁拠点や他システムとの専用線接続（GSSネットワーク、NaaS、情報提供NW、LGWANなど）を提供する。 | ・各種ネットワーク構成で必要となるNWコンポーネント | - | 府省庁拠点や他システムとの接続を行う。 | 個別に実装 | | 2-13-1 | 構成管理_システム構成管理機能 | システム内に展開されたインスタンスなどの設定を管理する。 | ・システム構成情報の取得
・システム構成情報の保存 | 〇 | 利用しているクラウドリソースの構成情報をCSP提供の構成管理サービスで自動収集、ストレージサービスに一元管理する。
運用者はクラウドリソースの構成情報の検索、変更確認などを行う。 | 個別に実装 | | 2-14-1 | バックアップ_バックアップ機能 | システム内のインスタンス・サービスの設定およびデータを管理する。 | ・データやストレージ、設定情報のバックアップ
・拠点被災を想定したリージョンまたぎのバックアップ | 〇 | 事前に設定された定義をもとにデータベースやストレージなどをデータストアのバックアップを自動で行う。
運用者はバックアップ情報を用いてリストアを行う。 | 個別に実装 | | 2-15-1 | オブザーバビリティ_システム監視機能 | 業務アプリケーションやリクエスト応答性などの監視、および異常時のアラート発報を行う。 | ・利用CSPのサービス異常時の通知
・システム特有の監視対象異常時の通知
・監視対象の状態を表示するダッシュボード | 〇 | システムの監視、異常時の検知および通知は自動で行われる。
通知をうけた運用者は異常内容確認などのためCSP提供の監視ダッシュボードを参照する。 | 個別に実装 | | 2-15-2 | オブザーバビリティ_サービス状態監視機能 | 利用者目線でのサービス状態（システムの応答時間やレスポンスなど）の監視と通知を行う。 | ・定期的なサービスへのアクセスによる監視
・監視対象異常時の通知 | 〇 | サービス状態の監視（外形監視）やサービスのパフォーマンス把握等を自動で行う。
通知をうけた運用者は異常内容確認などのためCSP提供の監視ダッシュボードを参照する。 | 共用サービス化も可能 | | 2-15-3 | オブザーバビリティ_KPI可視化機能 | システムのKPIの可視化を行うためのダッシュボードの提供、および分析に必要な前処理やダッシュボード管理を行う。 | ・データを可視化するために必要となる事前処理
・分析用ダッシュボードの作成
・分析用ダッシュボードの表示 | - | システムから発生するログやメトリクスを元にした可視化したKPIを管理、分析する。 | 個別に実装 | | 2-16-1 | ログ管理_ログ管理機能 | システム内のインスタンス、アプリケーションなどが出力するログを集約・管理する。 | ・ AWSサービスのAPI実行ログの収集
・インスタンス、アプケーションログの収集
・ネットワークトラヒックログの収集
・収集ログの可視化 | 〇 | アプリケーションやNWコンポーネント、システム操作などのログの収集、保管、破棄は事前の定義内容に応じて自動で行われる。
運用者はCSP提供のログ可視化サービスを用いて想定外事象対応やシステム改善などを行う。 | 個別に実装 | | 2-17-1 | CI/CD_CI/CDパイプライン機能 | 職員が利用システム上のインフラストラクチャー、アプリケーションの更新のためのコード管理、ビルド、テスト、デプロイ機能を一元的に提供する。 | ・コードのビルド
・コードのテスト
・ビルドした資材の保管
・資材のバージョン管理
・資材のデプロイ | - | ビルドやテスト、デプロイは事前に定義したパイプラインコードに従って自動処理される。
本番環境へのリリース時には手動でリリース内容の確認、および承認を行う。また、発生したエラー解析のために各パイプラインのコンソール参照を行うことがある。 | 個別に実装 | | 2-18-1 | データ共有_複数組織データ分離格納方法 | 複数自治体の情報をDBに保管する際に、自治体ごとに分離せずに統合し、互いに活用するためのデータ格納を実現する。 | ・保持情報の整形
・保持情報の更新、統合
・複数組織での利用を目的した情報の保管 | - | 組織毎に発生するデータを組織間で活用するため、データを蓄積、他組織に共有する。 | 個別に実装 | | 2-19-1 | 機械学習・AI_機械学習・AI機能 | 機械学習・AIサービスを用いて実装する行政業務システムの一例をあげる。 | ・関連資料やフォーマットなどをもとにした生成AIによるテキストデータの回答 | - | 省庁内文書をもとにして機械学習・AIサービスを用いて業務効率の向上を図る。 | 個別に実装 | | 2-20-1 | メンテナンス_DB直接メンテナンス機能 | 定常的運用あるいは非定常的運用としてデータベースを直接操作する機能を提供する。 | ・ユーザ認証
・データベース操作 | - | 運用者は本ブロックであげる方式に基づいて運用作業としてデータベース操作を行う。| 共用サービス化も可能 | | 2-20-2 | メンテナンス_起動停止スケジューリング機能 | コスト抑制を目的に環境のリソースをスケジュールに応じて起動・停止する。 | ・起動停止スケジュール管理 | - | 夜間や週末など環境を利用しない時間帯をあらかじめ定義し、スケジュールに応じて環境を停止、または再開する。| 個別に実装 | | 2-21-1 | コスト管理_課金管理機能 | システムが利用しているクラウドサービス利用料金が予算超過をしていないかを監視する。 | ・閾値超過時の通知 | - | あらかじめサービス使用料金を予算額に達した場合に、メールで運用担当者に通知する。| 個別に実装 | | 2-99-1 | その他_API管理機能 | 行政システムが公開する機能（API）の管理を行う。 | ・ APIへのアクセス制御（認証、接続元制御、スロットリング制御など）
・リリース戦略に基づいたAPIの更改 | - | 運用者は公開するAPIに対して接続元制御やリソース設定を行う。また、API更新を行う。| 個別に実装 | | 2-99-2 | その他_ローコード開発機能 | 必要最低限のコーディングでアプリケーション開発を行えるローコード開発機能を提供する。 | - | - | 開発者はローコード（少ないコーディング）でのアプリケーション開発を行う。| 個別に実装 | | 2-99-3 | その他_既存政府システムとの連携 | ガバメントクラウドから他の政府システム（住民基本台帳ネットワークシステム（住基ネット）やREPS連携基盤など）と連携を行う。 | - | - | ガバメントクラウドから他の政府システムと連携に関する留意事項を示す。| 個別に実装 | なお、非機能ブロックのうち必須ではないが実装を強く推奨するブロックを上表にて「非機能推奨ブロック」として示している。優先的に取り込みを検討していただきたい。
# 3. 代表的なシステムパターン前項にて挙げたブロックの組み合わせについて、以下の代表的なシステムパターンを例⽰する。なお、各システムパターンにおいてCSPごとに提供可能なサンプル構成図がある場合「〇」で示している。 | 項番 | システムパターン | AWS | Google Cloud | Azure | OCI | |------|------------|-----|-------|--------------|-----| | 1 | 電子申請・審査システム | 〇 | - | 〇 | 〇 | | 2 | 税金関連システム | 〇 | 〇 | - | 〇 | | 3 | 許認可関連システム | 〇 | 〇 | - | 〇 | | 4 | データ収集・公開システム（災害・気象情報等）| 〇 | 〇 | 〇 | 〇 | | 5 | 人事系システム | 〇 | 〇 | - | 〇 | | 6 | オンライン調査システム | 〇 | - | 〇 | 〇 | | 7 | データ管理型システム（防災、施設・設備等の管理、地図情報利用、IoT機器利用等） | 〇 | 〇 | - | 〇 | | 8 | 府省庁Webサイト | 〇 | 〇 | - | 〇 | | 9 | 統計システム | 〇 | - | 〇 | 〇 | | 10 | 資格管理システム | 〇 | - | - | 〇 | ## 3-1. 電子申請・審査システム

3-1-1. AWS

本アーキテクチャ例では、システムを複数のサブシステムに分割して構成する例を示す。サブシステムはブロックの組み合わせによって構成され、また、サブシステム単位で主要な業務を実現する想定である。 ### **アーキテクチャ例** ![ブロック概要](/images/general_reference-architecture-chapter-01-03-aws-01-01.png) ### **サブシステムの説明** 本アーキテクチャ例における各サブシステムの説明を以下に示す。説明のうち、「システム内の処理概要」に記載の番号は、アーキテクチャ例に記載の番号と対応しているため、アーキテクチャ例として示した構成図を適宜参照されたい。 #### **１. 申請・届出** * 実現する業務 * 申請者(国民)が、電子申請に必要な申請書を提出する。 * 構成されるブロック * 申請・届出_申請・届出機能 * 申請・届出_添付資料管理機能 * 申請・届出_ステータス管理機能 * 申請・届出_公文書ダウンロード機能 * 利用者通知_メッセージ通知機能 * システム内の処理概要 * 申請者(国民)は、Webアプリへ必要事項を入力して申請書を提出する。申請者(国民)が提出した申請書は電子データとして「申請・届出」ブロックのデータベース及び「添付資料管理」ブロックのストレージに保管する。（１、２） * 「申請・届出」ブロックは、提出された申請書のデータを、「審査・承認」ブロックへメッセージキューを利用して非同期連携する。（３） * 「申請・届出」ブロックは、審査結果を受信すると、審査結果を「申請・届出」ブロックのデータベースに保管し、審査結果を申請者(国民)へ通知するためのファイルを作成する。（８、９） * 「申請・届出」ブロックは、審査結果のファイルを申請者(国民)がダウンロードするためのURLを生成し、さらに、「メッセージ通知」ブロックは、電子メールによる通知を申請者(国民)へ送信する。（10、11） * 申請者(国民)は、Webアプリへアクセスすることで、審査状況や審査結果を確認する。審査状況や審査結果は、「ステータス管理」ブロックのデータベースと「公文書ダウンロード」ブロックのストレージに保管される。（12） * 補足説明 * Webアプリの実装はコンテナを利用し、フロントエンド、バックエンドを分離した構成とする。（「申請・届出」サブシステムでは、フロントエンドをCDN+オブジェクトストレージで実現） * 「申請・届出」サブシステムのデータベースには、NoSQLを利用する。（申請者(国民)からの大量のリクエストが一度に発生することを考慮し、データベースに対して高いスケーラビリティが求められるため）また、「申請・届出」ブロックの処理は電子申請の受付を主としており、データベースに対して多く発生する処理は、データの新規登録(インサート)と考えられる。したがって、トランザクションが求められることは少ないと想定し、NoSQLが適していると考えられる。 * 「審査・承認」サブシステムとの連携はシステムの柔軟性と拡張性を高めるため、メッセージングサービスを利用した非同期処理により実現する。各サービスが独立して動作し、必要に応じてスケーリングや更新が容易になるメリットや、ネットワーク遅延や一時的なダウンにも強いシステムとすることが期待される。 #### **２. 審査・承認** * 実現する業務 * 職員が、受け付けた電子申請に対する審査を行う。 * 構成されるブロック * 審査・承認_審査・承認機能 * システム内の処理概要 * 「申請・届出」ブロックから連携された申請書データを「審査・承認」ブロックのデータベースに保存する（４） * 職員は、「審査・承認」ブロックに保存された申請書をWebアプリで参照し、審査結果をWebアプリに入力する。（５） * 審査結果は、「審査・承認」ブロックのデータベースに保管する。（６） * 「審査・承認」ブロックは、審査結果のデータを「申請・届出」ブロックへ、メッセージキューを利用して非同期連携する。（７） * 補足説明 * Webアプリの実装はコンテナを利用し、フロントエンド、バックエンドを分離せず単一のコンテナアプリケーションで動作させる。（アクセス数が多くない前提のため、シンプルな構成とすることによる複雑性の回避、運用コスト削減を優先させるため）また、職員は、「審査・承認」サブシステムへ閉域網を経由して接続する前提としているため、インターネット経由を前提としたCDNは使用しない構成とする。 * 「審査・承認」サブシステムのデータベースには、RDBを利用する。（「審査・承認」サブシステムの利用者は審査を担当する職員のみであり、高いスケーラビリティは求められず、また、審査処理の中でデータベースに対してトランザクション処理が必要とされる場合が多いため） * 「申請・届出」サブシステムとの連携はメッセージングサービスを利用した非同期処理により実現する。 #### **３. 国民認証、４. 職員認証** * 実現する業務 * 申請者(国民)または職員が、システムの利用に必要となる本人確認を行う。 * 構成されるブロック * 利用者認証_ユーザ認証機能（国民向け） * 利用者認証_ユーザ認証機能（職員向け） * システム内の処理概要 * 申請者(国民)または職員は、IDとパスワードに代表されるユーザ認証情報を外部のID管理システムに入力する。外部のID管理システムにおけるユーザー認証の結果は「ユーザ認証（国民向け）」ブロックまたは「ユーザ認証（職員向け）」ブロックへ連携される。ユーザー認証結果の連携は、OpenID ConnectやSAML 2.0などの標準プロトコルを用いて実施する。 * 「ユーザ認証（国民向け）」ブロックまたは「ユーザ認証（職員向け）」ブロックは、外部のID管理システムから連携されるユーザ認証結果に基づいてユーザを一意に特定し、ユーザごとの属性情報をデータベースに保管する。 * 「ユーザ認証（国民向け）」ブロックまたは「ユーザ認証（職員向け）」ブロックは、申請者(国民)または職員がシステムを利用するためのアクセス許可証(トークン)を発行する。このアクセス許可証(トークン)は、「申請・届出」ブロックなどの他の機能ブロックを利用するために用いられる。他の機能ブロックは、リクエストに含まれるアクセス許可証(トークン)の有効性を確認することで、ユーザ認証が成功した申請者(国民)または職員のみに機能を提供する。 * 補足説明 * 「ユーザ認証（国民向け）」ブロックは、「申請・届出」ブロックのアプリケーションの一部として実現する想定である。そのため、「ユーザ認証（国民向け）」ブロック専用のデータベース等のリソースの作成は想定しない。過度な分割は避け、また、Webアプリ用のフレームワークやライブラリを活用して、ユーザ認証に関する機能を実装することで、構築作業を効率化することを期待している。 * 「ユーザ認証（職員向け）」ブロックも同様に、「審査・承認」ブロックのアプリケーションの一部として実現する想定である。 * 「申請・届出」ブロックのデータベースには、NoSQLを利用する想定である。「ユーザ認証（国民向け）」ブロックで管理するユーザごとの属性情報がシステム更改のタイミングで追加になる可能性からも、事前のスキーマ定義を必要としないNoSQLの方が適していると考えられる。 * 「ユーザ認証（職員向け）」ブロック並びに職員は、外部のID管理システムに対して閉域網経由で接続する前提である。

3-1-3. Azure

* **構成される業務ブロック** * 申請・届出_申請・届出機能 * 申請・届出_ステータス管理機能 * 申請・届出_電子決裁機能 * 審査・承認_審査・承認機能 * データ管理_統計処理機能 * データ管理_統計情報公開機能 * データ管理_文書検索機能 * 利用者通知_メッセージ通知機能 * コンテンツ管理_Webページ（静的コンテンツ）公開機能 * 書類出力_法定帳票作成機能（外部） * **構成される非機能ブロック** * 利用者認証_ユーザ認証機能（国民向け） * 非機能推奨ブロック * **アーキテクチャ例** ![ブロック概要](/images/general_reference-architecture-chapter-01-03-azure-01-01.png)

3-1-4. OCI

* **構成される業務ブロック** * 申請・届出_申請・届出機能 * 申請・届出_ステータス管理機能 * 申請・届出_電子決裁機能 * データ管理_統計情報公開機能 * データ管理_文書検索機能 * データ管理_統計処理機能 * コンテンツ管理_Webページ（静的コンテンツ）公開機能 * コンテンツ管理_ Webページ（動的コンテンツ）公開機能 * 書類出力_法定帳票作成機能（外部） * **構成される非機能ブロック** * 利用者認証_ユーザ認証機能（国民向け） * 利用者認証_ユーザ認証機能（職員向け） * **アーキテクチャ例** - パターン1 ローコード開発ツール利用 ![ブロック概要](/images/general_reference-architecture-chapter-01-03-oci-01-01.png) - パターン2 サーバレス利用 ![ブロック概要](/images/general_reference-architecture-chapter-01-03-oci-01-02.png)

## 3-2. 税⾦関連システム

3-2-1. AWS

本アーキテクチャ例では、システムを複数のサブシステムに分割して構成する例を示す。サブシステムはブロックの組み合わせによって構成され、また、サブシステム単位で主要な業務を実現する想定である。 ### **アーキテクチャ例** ![ブロック概要](/images/general_reference-architecture-chapter-01-03-aws-02-01.png) ### **サブシステムの説明** 本アーキテクチャ例における各サブシステムの説明を以下に示す。説明のうち、「システム内の処理概要」に記載の番号は、アーキテクチャ例に記載の番号と対応しているため、アーキテクチャ例として示した構成図を適宜参照されたい。 #### **１. 申請・届出** * 実現する業務 * 申請者(国民)が、税金に関連する電子申請に必要な申請および納付を行う。 * 構成されるブロック * 申請・届出_申請・届出機能 * 申請・届出_手数料等電子納付機能 * 申請・届出_補助金等電子交付機能 * 利用者通知_メッセージ通知機能 * システム内の処理概要 * 申請者は、Webアプリへ必要事項を入力して手数料等納付または交付の申請書を提出する。提出した申請書は電子データとして「申請・届出」ブロックのデータベースに保管する。（１、２） * 「申請・届出」ブロックは、提出された申請書のデータを、「審査・承認」ブロックへメッセージキューを利用して非同期連携する。（３） * 「申請・届出」ブロックは、納付または交付に関する審査結果を受信すると、審査結果を「申請・届出」ブロックのデータベースに保管し、審査結果を申請者へ通知するためのファイルを作成する。（９、１０） * また、「申請・届出」ブロックは、手数料等納付または交付の審査結果のファイルを申請者がダウンロードするためのURLを生成し、「メッセージ通知」ブロックは、電子メールによる通知を申請者へ送信する。（１１、１２） * 手数料等の納付または交付は、連携された納付に関する識別情報をもとに、金融機関等を経由して外部システム（歳入金電子納付システム（REPS））と連携して行われる。「審査・承認」サブシステムと、手数料の納付または交付に関する情報を連携する。連携した情報をもとに、手数料納付または交付ステータスを更新する。
（注）REPSに関する技術情報（インタフェース仕様、連携のための手続きや制約事項等）は、別途確認する必要がある。（１３） * 補足説明 * Webアプリの実装はコンテナを利用し、フロントエンド、バックエンドを分離した構成とする。（「申請・届出」サブシステムでは、フロントエンドをCDN+オブジェクトストレージで実現） * 「申請・届出」サブシステムのデータベースには、NoSQLを利用する。（申請者(国民)からの大量のリクエストが一度に発生することを考慮し、データベースに対して高いスケーラビリティが求められるため）また、「申請・届出」ブロックの処理は電子申請の受付を主としており、データベースに対して多く発生する処理は、データの新規登録(インサート)と考えられる。したがって、トランザクションが求められることは少ないと想定し、NoSQLが適していると考えられる。 * 「申請・届出」サブシステムの手数料納付ステータス管理用のデータベースについては、トランザクション処理が必要とされるためRDBを使用する。 * 「審査・承認」サブシステムとの連携はシステムの柔軟性と拡張性を高めるため、メッセージングサービスを利用した非同期処理により実現する。各サービスが独立して動作し、必要に応じてスケーリングや更新が容易になるメリットや、ネットワーク遅延や一時的なダウンにも強いシステムとすることが期待される。 #### **２. 審査・承認** * 実現する業務 * 職員が審査機能を用いて、受け付けた申請に対する承認を行う。 * 構成されるブロック * 審査・承認_審査・承認機能 * システム内の処理概要 * 「申請・届出」ブロックから連携された手数料等納付または交付の申請書データを「審査・承認」ブロックのデータベースに保存する（４） * 職員は、「審査・承認」ブロックに保存された手数料等納付または交付の申請書をWebアプリで参照し、審査結果をWebアプリに入力する。（５） * 審査結果は、「審査・承認」ブロックのデータベースに保管する。（６） * 手数料等の納付または交付は、外部システム（歳入金電子納付システム（REPS））と連携して行われる。REPSとの間で手数料の納付に関する識別番号情報を連携する。連携した情報をもとに、手数料納付または交付ステータスを更新する。
（注）REPSに関する技術情報（インタフェース仕様、連携のための手続きや制約事項等）は、別途確認する必要がある。（７） * 「審査・承認」ブロックは、審査結果のデータを「申請・届出」ブロックへ、メッセージキューを利用して非同期連携する。（８） * 外部システムで処理完了後の納付・交付完了通知については、外部システムから「審査・承認」ブロックに通知される。これを「審査・承認」ブロックのWebアプリケーションで受信する。（１４）
　（参考）Push方式（HTTP）等で通知される。 * 受信した納付・交付完了通知を「審査・承認」ブロックのデータベースに保管する。（１５） * 補足説明 * Webアプリの実装はコンテナを利用し、フロントエンド、バックエンドを分離せず単一のコンテナアプリケーションで動作させる。（アクセス数が多くない前提のため、シンプルな構成とすることによる複雑性の回避、運用コスト削減を優先させるため）また、職員は、「審査・承認」サブシステムへ閉域網を経由して接続する前提としているため、インターネット経由を前提としたCDNは使用しない構成とする。 * 「審査・承認」サブシステムのデータベースには、RDBを利用する。（「審査・承認」サブシステムの利用者は審査を担当する職員のみであり、高いスケーラビリティは求められず、また、審査処理の中でデータベースに対してトランザクション処理が必要とされる場合が多いため） * 「申請・届出」サブシステムとの連携はメッセージングサービスを利用した非同期処理により実現する。 * 本アーキテクチャでは、職員向けバックエンドアプリケーション用と、外部システムとの連携用では、求められる処理性能が異なるため、コンテナを分離配置している。 #### **３. 国民認証、４. 職員認証** * 実現する業務 * 申請者(国民)または職員が、システムの利用に必要となる本人確認を行う。 * 構成されるブロック * 利用者認証_ユーザ認証機能（国民向け） * 利用者認証_ユーザ認証機能（職員向け） * システム内の処理概要 * 申請者(国民)または職員は、IDとパスワードに代表されるユーザ認証情報を外部のID管理システムに入力する。外部のID管理システムにおけるユーザー認証の結果は「ユーザ認証（国民向け）」ブロックまたは「ユーザ認証（職員向け）」ブロックへ連携される。ユーザー認証結果の連携は、OpenID ConnectやSAML 2.0などの標準プロトコルを用いて実施する。 * 「ユーザ認証（国民向け）」ブロックまたは「ユーザ認証（職員向け）」ブロックは、外部のID管理システムから連携されるユーザ認証結果に基づいてユーザを一意に特定し、ユーザごとの属性情報をデータベースに保管する。 * 「ユーザ認証（国民向け）」ブロックまたは「ユーザ認証（職員向け）」ブロックは、申請者(国民)または職員がシステムを利用するためのアクセス許可証(トークン)を発行する。このアクセス許可証(トークン)は、「申請・届出」ブロックなどの他の機能ブロックを利用するために用いられる。他の機能ブロックは、リクエストに含まれるアクセス許可証(トークン)の有効性を確認することで、ユーザ認証が成功した申請者(国民)または職員のみに機能を提供する。 * 補足説明 * 「ユーザ認証（国民向け）」ブロックは、「申請・届出」ブロックのアプリケーションの一部として実現する想定である。そのため、「ユーザ認証（国民向け）」ブロック専用のデータベース等のリソースの作成は想定しない。過度な分割は避け、また、Webアプリ用のフレームワークやライブラリを活用して、ユーザ認証に関する機能を実装することで、構築作業を効率化することを期待している。 * 「ユーザ認証（職員向け）」ブロックも同様に、「審査・承認」ブロックのアプリケーションの一部として実現する想定である。 * 「申請・届出」ブロックのデータベースには、NoSQLを利用する想定である。「ユーザ認証（国民向け）」ブロックで管理するユーザごとの属性情報がシステム更改のタイミングで追加になる可能性からも、事前のスキーマ定義を必要としないNoSQLの方が適していると考えられる。 * 「ユーザ認証（職員向け）」ブロック並びに職員は、外部のID管理システムに対して閉域網経由で接続する前提である。

3-2-2. Google Cloud

* **構成される業務ブロック** * 申請・届出_申請・届出機能 * 申請・届出_電子決裁機能 * 申請・届出_手数料等電子納付機能 * 申請・届出_補助金等電子交付機能 * 申請・届出_公文書ダウンロード機能 * 審査・承認_審査・承認機能 * データ管理_データ収集機能 * データ管理_データ連携機能 * データ管理_分析用ダッシュボード機能 * 利用者通知_メッセージ通知機能 * 書類出力_法定帳票作成機能 * **構成される非機能ブロック** * 利用者認証_ユーザ認証機能（国民向け） * 利用者認証_ユーザ認証機能（企業ユーザ向け） * **アーキテクチャ例** ![ブロック概要](/images/general_reference-architecture-chapter-01-03-gcp-02-01.png)

3-2-4. OCI

- **構成される業務ブロック** - 申請・届出_申請・届出機能 - 申請・届出_電子決裁機能 - 申請・届出_手数料等電子納付機能 - 申請・届出_補助金等電子交付機能 - 審査・承認_審査・承認機能 - データ管理_データ収集機能 - データ管理_データ連携機能 - データ管理_分析用ダッシュボード機能 - データ管理_統計処理機能 - 利用者通知_メッセージ通知機能 - 書類出力_法定帳票作成機能（外部） - **構成される非機能ブロック** - 利用者認証_ユーザ認証機能（職員向け） - 利用者認証_ユーザ認証機能（国民向け） - CI/CD_CI/CDパイプライン機能 - 非機能推奨ブロック - **アーキテクチャ例** - パターン1 ローコード開発ツール利用 ![ブロック概要](/images/general_reference-architecture-chapter-01-03-oci-02-01.png) - パターン2 サーバレス利用 ![ブロック概要](/images/general_reference-architecture-chapter-01-03-oci-02-02.png)

## 3-3. 許認可関連システム

3-3-1. AWS

* **構成される業務ブロック** * 申請・届出_公文書ダウンロード機能 * データ管理_データ収集機能 * データ管理_分析用ダッシュボード機能 * データ管理_統計情報公開機能 * コンテンツ管理_Webページ（静的コンテンツ）公開機能 * 書類出力_法定帳票作成機能（外部） * **構成される非機能ブロック** * 利用者認証_ユーザ認証機能（職員向け） * CI/CD_CI/CDパイプライン機能 * 非機能推奨ブロック * **アーキテクチャ例** ![ブロック概要](/images/general_reference-architecture-chapter-01-03-aws-03-01.png)

3-3-2. Google Cloud

* **構成される業務ブロック** * 申請・届出_公文書ダウンロード機能 * データ管理_データ収集機能 * データ管理_分析用ダッシュボード機能 * データ管理_統計処理機能 * データ管理_統計情報公開機能 * コンテンツ管理_Webページ（静的コンテンツ）公開機能 * 書類出力_法定帳票作成機能（内部） * **構成される非機能ブロック** * 利用者認証_ユーザ認証機能（職員向け） * **アーキテクチャ例** ![ブロック概要](/images/general_reference-architecture-chapter-01-03-gcp-03-01.png)

3-3-4. OCI

- **構成される業務ブロック** - 申請・届出_公文書ダウンロード機能 - データ管理_データ収集機能 - データ管理_分析用ダッシュボード機能 - データ管理_統計情報公開機能 - データ管理_統計処理機能 - コンテンツ管理_Webページ（静的コンテンツ）公開機能 - 書類出力_法定帳票作成機能（外部） - **構成される非機能ブロック** - 利用者認証_ユーザ認証機能（職員向け） - 利用者認証_ユーザ認証機能（国民向け） - CI/CD_CI/CDパイプライン機能 - 非機能推奨ブロック - **アーキテクチャ例** - パターン1 ローコード開発ツール利用 ![ブロック概要](/images/general_reference-architecture-chapter-01-03-oci-03-01.png) - パターン2 サーバレス利用 ![ブロック概要](/images/general_reference-architecture-chapter-01-03-oci-03-02.png)

## 3-4. データ収集・公開システム（災害・気象情報等）

3-4-1. AWS

* **構成される業務ブロック** * データ管理_大量データ取り込み機能 * データ管理_統計処理機能 * データ管理_統計情報公開機能 * 利用者通知_メッセージ通知機能 * コンテンツ管理_Webページ（静的コンテンツ）公開機能 * **構成される非機能ブロック** * CI/CD_CI/CDパイプライン機能 * 非機能推奨ブロック * **アーキテクチャ例** ![ブロック概要](/images/general_reference-architecture-chapter-01-03-aws-04-01.png)

3-4-2. Google Cloud

* **構成される業務ブロック** * データ管理_大量データ取り込み機能 * データ管理_統計処理機能 * データ管理_統計情報公開機能 * コンテンツ管理_Webページ(静的コンテンツ)公開機能 * 利用者通知_メッセージ通知機能 * **構成される非機能ブロック** * なし * **アーキテクチャ例** ![ブロック概要](/images/general_reference-architecture-chapter-01-03-gcp-04-01.png)

3-4-3. Azure

* **構成される業務ブロック** * データ管理_大量データ取り込み機能 * データ管理_統計処理機能 * データ管理_統計情報公開機能 * コンテンツ管理_Webページ(静的コンテンツ)公開機能 * 利用者通知_メッセージ通知機能 * **構成される非機能ブロック** * 非機能推奨ブロック * **アーキテクチャ例** ![ブロック概要](/images/general_reference-architecture-chapter-01-03-azure-04-01.png)

3-4-4. OCI

* **構成される業務ブロック** * データ管理_大量データ取り込み機能 * データ管理_統計処理機能 * データ管理_統計情報公開機能 * コンテンツ管理_Webページ(静的コンテンツ)公開機能 * 利用者通知_メッセージ通知機能 * **構成される非機能ブロック** * CI/CD_CI/CDパイプライン機能 * 非機能推奨ブロック * **アーキテクチャ例** - パターン1 ローコード開発ツール利用 ![ブロック概要](/images/general_reference-architecture-chapter-01-03-oci-04-01.png) - パターン2 サーバレス利用 ![ブロック概要](/images/general_reference-architecture-chapter-01-03-oci-04-02.png)

## 3-5. 人事系システム

3-5-1. AWS

* **構成される業務ブロック** * 申請・届出_申請・届出機能 * 審査・承認_審査・承認機能 * データ管理_データ連携機能 * データ管理_統計処理機能 * データ管理_統計情報公開機能 * コンテンツ管理_Webページ（静的コンテンツ）公開機能 * 外部連携_申請処理連携機能 * 外部連携_外部連携機能（API公開） * **構成される非機能ブロック** * 外部連携_システム間認証機能 * CI/CD_CI/CDパイプライン機能 * 非機能推奨ブロック * **アーキテクチャ例** ![ブロック概要](/images/general_reference-architecture-chapter-01-03-aws-05-01.png)

3-5-2. Google Cloud

* **構成される業務ブロック** * 申請・届出_申請・届出機能 * 審査・承認_審査・承認機能 * データ管理_データ連携機能 * データ管理_統計処理機能 * データ管理_統計情報公開機能 * コンテンツ管理_Webページ（静的コンテンツ）公開機能 * 外部連携_申請処理連携機能 * 外部連携_外部連携機能（API公開） * **構成される非機能ブロック** * 外部連携_システム間認証機能 * **アーキテクチャ例** ![ブロック概要](/images/general_reference-architecture-chapter-01-03-gcp-05-01.png)

3-5-4. OCI

- **構成される業務ブロック** - 申請・届出_申請・届出機能 - 審査・承認_審査・承認機能 - データ管理_データ連携機能 - データ管理_統計処理機能 - データ管理_統計情報公開機能 - コンテンツ管理_Webページ（静的コンテンツ）公開機能 - 外部連携_申請処理連携機能 - 外部連携_外部連携機能（API公開） - **構成される非機能ブロック** - 利用者認証_ユーザ認証機能（職員向け） - 利用者認証_ユーザ認証機能（国民向け） - 外部連携_システム間認証機能 - CI/CD_CI/CDパイプライン機能 - 非機能推奨ブロック - **アーキテクチャ例** - パターン1 ローコード開発ツール利用 ![ブロック概要](/images/general_reference-architecture-chapter-01-03-oci-05-01.png) - パターン2 サーバレス利用 ![ブロック概要](/images/general_reference-architecture-chapter-01-03-oci-05-02.png)

## 3-6. オンライン調査システム

3-6-1. AWS

本アーキテクチャ例では、システムを複数のサブシステムに分割して構成する例を示す。サブシステムはブロックの組み合わせによって構成され、また、サブシステム単位で主要な業務を実現する想定である。 ### **アーキテクチャ例** ![ブロック概要](/images/general_reference-architecture-chapter-01-03-aws-06-01.png) ### **サブシステムの説明** 本アーキテクチャ例における各サブシステムの説明を以下に示す。説明のうち、「システム内の処理概要」に記載の番号は、アーキテクチャ例に記載の番号と対応しているため、アーキテクチャ例として示した構成図を適宜参照されたい。 #### **１. 調査・配信** * 実現する業務 * 申請者(国民)が、調査回答を登録する。 * 構成されるブロック * 申請・届出_申請・届出機能 * データ管理_データ連携機能 * システム内の処理概要 * 申請者は、Webアプリへ必要事項を入力して回答書を提出する。提出した回答書は電子データとして「調査・配信」サブシステムのデータベース及び「調査・配信」サブシステムの添付資料管理ストレージに保管する。（１、２） * 「調査・配信」サブシステムは、回答内容保管データベースの差分ストリーム機能を利用して、提出された回答書のデータを「回収」サブシステムのストリームコンシューマである回答内容連携処理関数に連携する。（３） * 「調査・配信」ブロックから連携された差分データを「回収」サブシステムのデータベースに保存する（４） * 補足説明 * Webアプリの実装はコンテナを利用し、フロントエンド、バックエンドを分離した構成とする。（本構成ではフロントエンド側はCDN+オブジェクトストレージで実現） * 「調査・配信」サブシステムのデータベースには、NoSQLを利用する。（申請者(国民)からの大量のリクエストが一度に発生することを考慮し、データベースに対して高いスケーラビリティが求められるため）また、「調査・配信」サブシステムの処理は調査回答の登録を主としており、データベースに対して多く発生する処理は、データの新規登録(インサート)と考えられる。したがって、トランザクションが求められることは少ないと想定し、NoSQLが適している。 * 「回収」サブシステムとのデータの連携については、Amazon DocumentDB Change Streamを利用することで、データ変更を契機とするイベント駆動でのリアルタイムに連携することが可能となる。 #### **２. 回収** * 実現する業務 * 職員が、登録済みの調査回答に対して、調査回答の集計や分析を行う。 * 構成されるブロック * データ管理_統計処理機能 * 外部連携_システム間認証機能 * システム内の処理概要 * 回答内容分析DBでは回答内容保管DBからリアルタイムに連携された回答データの分析を行う（５） * 職員は、「回収」サブシステムの回答内容分析DBに保存された分析結果を回答内容分析ダッシュボードを通じて回答結果と分析結果を確認する。（６） * 他機関向けに、リアルタイムでの分析データをWebAPIで提供する。Amazon Cognitoのユーザプールの機能を使用し、認証されたユーザに対するトークンを発行する（７） * 回答内容参照関数にて回答内容保管DBの情報を検索して、結果を応答する。（８） * 補足説明 * 「回収」サブシステムは、利用者の処理特性に応じて異なるデータベースを採用している。具体的には、職員向けと他機関向けの2種類のデータベースを使い分けている。職員は主に大規模データの分析と集計を行うため、列指向データベースのAmazon Redshiftを採用している。 Redshiftは大量データの高速処理に優れ、効率的な集計処理を可能にする。一方、他機関は小規模な集計や柔軟な条件検索を頻繁に行うため、行指向データベースのAmazon Auroraを採用している。 Auroraはオンライントランザクション処理に適しており、迅速な検索が可能である。 * 回答内容保管DBと回答内容分析DBでのデータ連携については、Amazon Redshift との Amazon Aurora自動データ取り込み(Zero-ETL)により、リアルタイムでのデータ連携が可能となる。自動データ取り込み（Zero-ETL）を利用することで、 Amazon Aurora とAmazon Redshift でシームレスにデータを利用できるようになるため、抽出、変換、ロード (ETL) オペレーションを実行する複雑なデータパイプラインを構築して管理する必要が無くなるメリットがある。 * 国民を対象にした大規模なオンライン調査を前提としているが、調査の規模に応じて適切なアーキテクチャを検討する必要がある。「統計処理機能」ブロックにて、調査の規模に応じた構成パターンを例示しているため、参照すること。 * 分析者(職員)はQuickSightで可視化したデータへアクセスし、分析することが可能である。また単一ないしは複数のビジュアルを組み合わせて分析結果を作成し、ダッシュボードとして公開することが可能である。なお、ダッシュボードはPDFファイルとして出力することも可能である。なお、分析者(職員)のQuickSightへの接続はインターネット経由とし、QuickSight内部のユーザ管理を利用する前提としている。 * 他機関へのデータの提供については、イベント処理(データ提供イベント)を前提とし、サーバレスのサービスを採用している。利用頻度や、処理負荷、可搬性等を考慮してコンテナの採用も検討すること。 * 他機関へのデータの提供については、リアルタイム性を重視して、DBから最新のデータを提供する前提としている。リアルタイム性を重視しない場合は、S3に提供用ファイルを配置し、API経由で提供する案も検討すること。 #### **３. 国民認証** * 実現する業務 * 申請者(国民)が、システムの利用に必要となる本人確認を行う。 * 構成されるブロック * 利用者認証_ユーザ認証機能（国民向け） * システム内の処理概要 * 申請者(国民)は、IDとパスワードに代表されるユーザ認証情報を外部のID管理システムに入力する。外部のID管理システムにおけるユーザー認証の結果は「ユーザ認証（国民向け）」ブロックへ連携される。ユーザー認証結果の連携は、OpenID ConnectやSAML 2.0などの標準プロトコルを用いて実施する。 * 「ユーザ認証（国民向け）」ブロックは、外部のID管理システムから連携されるユーザ認証結果に基づいてユーザを一意に特定し、ユーザごとの属性情報をデータベースに保管する。 * 「ユーザ認証（国民向け）」ブロックは、申請者(国民) がシステムを利用するためのアクセス許可証(トークン)を発行する。このアクセス許可証(トークン)は、「申請・届出」ブロックなどの他の機能ブロックを利用するために用いられる。他の機能ブロックは、リクエストに含まれるアクセス許可証(トークン)の有効性を確認することで、ユーザ認証が成功した申請者(国民) のみに機能を提供する。 * 補足説明 * 「ユーザ認証（国民向け）」ブロックは、「申請・届出」ブロックのアプリケーションの一部として実現する想定である。そのため、「ユーザ認証（国民向け）」ブロック専用のデータベース等のリソースの作成は想定しない。過度な分割は避け、また、Webアプリ用のフレームワークやライブラリを活用して、ユーザ認証に関する機能を実装することで、構築作業を効率化することを期待している。 * 「申請・届出」ブロックのデータベースには、NoSQLを利用する想定である。「ユーザ認証（国民向け）」ブロックで管理するユーザごとの属性情報がシステム更改のタイミングで追加になる可能性からも、事前のスキーマ定義を必要としないNoSQLの方が適していると考えられる。 #### **4. 調査結果公開** * 実現する業務 * 職員が閲覧者に提供するコンテンツの管理を行う。 * 構成されるブロック * コンテンツ管理_Webコンテンツ管理（CMS）機能 * システム内の処理概要 * 閲覧者は静的コンテンツを「コンテンツ管理」ブロックのCDN+オブジェクトストレージから取得する。（９） * 開発者が変更を加える場合は、GitHub等コードレポジトリでの変更イベントをトリガーとし、ビルド及びデプロイプロセスを開始する。（１０） * ビルド時には必要に応じてCMSからコンテンツを取得する。（１１） * 職員（コンテンツ投稿者）によるコンテンツの編集はCDN+オブジェクトストレージから配信されるDecapCMSの管理者用ページから行う。コンテンツはコードレポジトリにて保管される。（１２） * 職員（コンテンツ投稿者）によるコンテンツ更新や、フロントエンド開発者によるフロントエンドアプリの更新をトリガーとして、Next.jsやNuxt.jsによるSSGが実行される。(１３) * SSG実行時にはDecapCMSがコードレポジトリからコンテンツを取得する。(１４) * 補足説明 * 本パターンは、小規模サイトでの利用を想定している。コンテンツのビルドに時間を要するSSGが前提となっており、また、コンテンツの保管先となるGitレポジトリ固有の制限(例. ファイルサイズの上限)を考慮する必要があるからである。 * ヘッドレスCMSはOSSでGitベースCMSに分類されるDecapCMSの利用を前提とする。 * 本構成では、コンテンツキャッシュを利用するため、ELB の前段に CloudFront を配置している。 * Amazon QuickSightのダッシュボードの埋め込み機能を利用することで、「回収」サブシステムにおいて作成した閲覧者向けのダッシュボードを、コンテンツの一部として公開可能ある。

3-6-3. Azure

* **構成される業務ブロック** * 申請・届出_申請・届出機能 * 申請・届出_添付資料管理機能 * 申請・届出_ステータス管理機能 * 審査・承認_審査・承認機能 * データ管理_統計処理機能 * データ管理_統計情報公開機能 * データ管理_分析用ダッシュボード機能 * 利用者通知_メッセージ通知機能 * コンテンツ管理_Webページ（静的コンテンツ）公開機能 * 書類出力_書類出力機能 * **構成される非機能ブロック** * CI/CD_CI/CDパイプライン機能 * 非機能推奨ブロック * **アーキテクチャ例** ![ブロック概要](/images/general_reference-architecture-chapter-01-03-azure-06-01.png)

3-6-4. OCI

- **構成される業務ブロック** - 申請・届出_申請・届出機能 - 申請・届出_添付資料管理機能 - 申請・届出_ステータス管理機能 - 審査・承認_審査・承認機能 - データ管理_統計処理機能 - データ管理_統計情報公開機能 - データ管理_分析用ダッシュボード機能 - 利用者通知_メッセージ通知機能 - コンテンツ管理_Webページ（静的コンテンツ）公開機能 - 書類出力_書類出力機能 - **構成される非機能ブロック** - 利用者認証_ユーザ認証機能（職員向け） - 利用者認証_ユーザ認証機能（国民向け） - CI/CD_CI/CDパイプライン機能 - 非機能推奨ブロック - **アーキテクチャ例** - パターン1 ローコード開発ツール利用 ![ブロック概要](/images/general_reference-architecture-chapter-01-03-oci-06-01.png) - パターン2 サーバレス利用 ![ブロック概要](/images/general_reference-architecture-chapter-01-03-oci-06-02.png)

## 3-7. データ管理型システム（防災、施設・設備等の管理、地図情報利用、IoT機器利用等）

3-7-1. AWS

* **構成される業務ブロック** * データ管理_統計処理機能 * データ管理_IoT連携機能IoT連携機能 * データ管理_大量データ取り込み機能大量データ取り込み機能 * データ管理_データ収集機能 * データ管理_分析用ダッシュボード機能 * データ管理_データ収集機能 * コンテンツ管理_Webページ（静的コンテンツ）公開機能 * コミュニケーション_チャットボット機能 * 外部連携_外部連携機能（API公開） * **構成される非機能ブロック** * 外部連携_システム間認証機能 * CI/CD_CI/CDパイプライン機能 * データ共有_複数組織データ分離格納方法 * メンテナンス_DB直接メンテナンス機能 * 非機能推奨ブロック * **アーキテクチャ例** ![ブロック概要](/images/general_reference-architecture-chapter-01-03-aws-07-01.png)

3-7-2. Google Cloud

* **構成される業務ブロック** * データ管理_データ収集機能 * データ管理_分析用ダッシュボード機能 * コミュニケーション_チャットボット機能 * データ管理_IoT連携機能 * データ管理_データ連携機能 * オンラインアプリ・API機能 * **構成される非機能ブロック** * データ共有_複数組織データ分離格納方法 * **アーキテクチャ例** ![ブロック概要](/images/general_reference-architecture-chapter-01-03-gcp-07-01.png)

3-7-4. OCI

- **構成される業務ブロック** - データ管理_統計処理機能 - データ管理_IoT連携機能 - データ管理_大量データ取り込み機能 - データ管理_データ収集機能 - データ管理_分析用ダッシュボード機能 - コンテンツ管理_Webページ（静的コンテンツ）公開機能 - コミュニケーション_チャットボット機能 - 外部連携_外部連携機能（API公開） - **構成される非機能ブロック** - 非機能推奨ブロック - 外部連携_システム間認証機能 - CI/CD_CI/CDパイプライン機能 - データ共有_複数組織データ分離格納方法 - メンテナンス_DB直接メンテナンス機能 - **アーキテクチャ例** - パターン1 ローコード開発ツール利用 ![ブロック概要](/images/general_reference-architecture-chapter-01-03-oci-07-01.png) - パターン2 サーバレス利用 ![ブロック概要](/images/general_reference-architecture-chapter-01-03-oci-07-02.png)

## 3-8. 府省庁Webサイト

3-8-1. AWS

本アーキテクチャ例では、システムを複数のサブシステムに分割して構成する例を示す。サブシステムはブロックの組み合わせによって構成され、また、サブシステム単位で主要な業務を実現する想定である。 ### **アーキテクチャ例** * パターン1 CMSに外部のSaaSを利用したSSR ![ブロック概要](/images/general_reference-architecture-chapter-01-03-aws-08-01.png) * パターン2 CMSにセルフホスティングのOSSを利用したSSG(SG) ![ブロック概要](/images/general_reference-architecture-chapter-01-03-aws-08-02.png) ### **サブシステムの説明** 本アーキテクチャ例における各サブシステムの説明を以下に示す。説明のうち、「システム内の処理概要」に記載の番号は、アーキテクチャ例に記載の番号と対応しているため、アーキテクチャ例として示した構成図を適宜参照されたい。「コンテンツ管理」サブシステムにおいては、パターンごとに構成が異なる。そのため、処理概要と補足説明を構成に合わせてパターンごとに記載している。 #### **１. コンテンツ管理** * 実現する業務 * 職員が、利用者（閲覧者）に提供するコンテンツの管理を行う。 * 構成されるブロック * コンテンツ管理_Webコンテンツ管理（CMS）機能 * システム内の処理概要 * パターン1 CMSに外部のSaaSを利用したSSR * 利用者（閲覧者）は、コンテンツを「Webコンテンツ管理（CMS）」ブロックのアプリケーションから取得する。（１） * 開発者は、フロントエンドアプリのコードに対する修正をコードレポジトリへプッシュする。この変更イベントをトリガーとしビルド及びデプロイプロセスを開始する。（２） * ビルド時には必要に応じてCMSからコンテンツを取得する。（３） * 職員（コンテンツ投稿者）によるコンテンツの管理や編集は、外部SaaSのヘッドレスCMSを利用する。（４） * パターン2 CMSにセルフホスティングのOSSを利用したSSG(SG) * 利用者（閲覧者）は、静的コンテンツを「Webコンテンツ管理（CMS）」ブロックのCDN+オブジェクトストレージから取得する。（１） * 開発者は、フロントエンドアプリのコードに対する修正をコードレポジトリへプッシュする。この変更イベントをトリガーとしビルド及びデプロイプロセスを開始する。（２） * 職員（コンテンツ投稿者）によるコンテンツの管理や編集は、CDN+オブジェクトストレージから配信されるDecapCMSの管理者用ページから行う。コンテンツはコードレポジトリにて保管される。（３） * 職員（コンテンツ投稿者）によるコンテンツ更新や、開発者によるフロントエンドアプリの更新をトリガーとして、Next.jsやNuxt.jsによるSSGが実行される。SSGの実行結果ファイルがオブジェクトストレージにアップロードされる。(４) * 補足説明 * パターン1 CMSに外部のSaaSを利用したSSR * 本構成ではSSRを前提としており、Next.jsなどによるレンダリングを実行するためにコンテナを配置した構成としている。 * 外部SaaS（ヘッドレスCMS）については、利用システム側で最適なものを選択する必要がある。 * 本構成では、自動化による保守作業負荷の軽減を目的として、AWS CodeBuildやGitHubアクションを用いたビルドやデプロイの自動化を導入している。 * 本構成では、コンテンツキャッシュを利用するため、Elastic Load Balancing の前段にCDNとしてAmazon CloudFrontを配置している。 * パターン2 CMSにセルフホスティングのOSSを利用したSSG(SG) * 本パターンは、小規模サイトでの利用を想定している。コンテンツのビルドに時間を要するSSGが前提となっており、また、コンテンツの保管先となるGitレポジトリ固有の制限(例. ファイルサイズの上限)を考慮する必要があるからである。 * ヘッドレスCMSはOSSでGitベースCMSに分類されるDecapCMSの利用を前提とする。 * 本構成では、コンテンツキャッシュを利用するため、CDNとしてAmazon CloudFrontを配置している。 #### **２. コミュニケーション** * 実現する業務 * 職員（サイト管理者）が、利用者（閲覧者）とのコミュニケーションを目的にメール受領、メール配信を提供する。 * 構成されるブロック * コミュニケーション_問い合わせフォーム機能 * システム内の処理概要 * 利用者（閲覧者）は、「Webコンテンツ管理（CMS）」ブロックによって配信されるフォームに問い合わせ内容を入力する。（５） * フォームの入力内容はAPI Gatewayで構築されたバックエンドAPIで処理される。（６） * バックエンドAPIは、問い合わせ内容をメールとしてAmazon SESから職員（サイト管理者）へ送信する。（７） * 職員（サイト管理者）は受信したメールに対する回答を、利用者（閲覧者）へ個別に返信する。（８） * 補足説明 * 本構成では、問い合わせ受信処理と、メール送信処理との連携はメッセージングサービスを利用した非同期処理とすることにより、大量リクエスト発生時にも対応できる構成としている。 * 問い合わせ内容をバックアップや分析を目的としてストレージへ保管する場合には、バックエンドAPIを構成するLambda関数を使用してAmazon S3へ保管することも可能である。

3-8-2. Google Cloud

* **構成される業務ブロック** * コンテンツ管理_Webコンテンツ管理（CMS）機能 * コミュニケーション_問い合わせフォーム機能 * **構成される非機能ブロック** * CI/CD_CI/CDパイプライン機能 * 非機能推奨ブロック * **アーキテクチャ例** ![ブロック概要](/images/general_reference-architecture-chapter-01-03-gcp-08-01.png)

3-8-4. OCI

- **構成される業務ブロック** - コンテンツ管理_Webコンテンツ管理（CMS）機能 - コミュニケーション_問い合わせフォーム機能 - **構成される非機能ブロック** - CI/CD_CI/CDパイプライン機能 - 非機能推奨ブロック - **アーキテクチャ例** - パターン1 ローコード開発ツール利用 ![ブロック概要](/images/general_reference-architecture-chapter-01-03-oci-08-01.png) - パターン2 サーバレス利用 ![ブロック概要](/images/general_reference-architecture-chapter-01-03-oci-08-02.png)

## 3-9. 統計システム

3-9-1. AWS

* **構成される業務ブロック** * 申請・届出_申請・届出機能 * 申請・届出_ステータス管理機能 * 申請・届出_添付資料管理機能 * 審査・承認_審査・承認機能 * 書類出力_書類出力機能 * 利用者通知_メッセージ通知機能 * データ管理_データ収集機能 * データ管理_統計情報公開機能 * データ管理_統計処理機能 * データ管理_分析用ダッシュボード機能 * コンテンツ管理_Webページ(静的コンテンツ)公開機能 * **構成される非機能ブロック** * CI/CD_CI/CDパイプライン機能 * 非機能推奨ブロック * **アーキテクチャ例** ![ブロック概要](/images/general_reference-architecture-chapter-01-03-aws-09-01.png)

3-9-3. Azure

* **構成される業務ブロック** * 申請・届出_申請・届出機能 * 申請・届出_ステータス管理機能 * 申請・届出_添付資料管理機能 * 審査・承認_審査・承認機能 * 書類出力_書類出力機能 * 利用者通知_メッセージ通知機能 * データ管理_データ収集機能 * データ管理_統計情報公開機能 * データ管理_統計処理機能 * データ管理_分析用ダッシュボード機能 * コンテンツ管理_Webページ(静的コンテンツ)公開機能 * **構成される非機能ブロック** * オブザーバビリティ_システム監視機能 * オブザーバビリティ_サービス状態監視機能 * ログ管理_ログ管理機能 * バックアップ_バックアップ機能 * 構成管理_システム構成管理機能 * セキュリティ_セキュリティ管理機能 * CI/CD_CI/CDパイプライン機能 * **アーキテクチャ例** ![ブロック概要](/images/general_reference-architecture-chapter-01-03-azure-09-01.png)

3-9-4. OCI

- **構成される業務ブロック** - 申請・届出_申請・届出機能 - 申請・届出_ステータス管理機能 - 申請・届出_添付資料管理機能 - 審査・承認_審査・承認機能 - 書類出力_書類出力機能 - 利用者通知_メッセージ通知機能 - データ管理_データ収集機能 - データ管理_統計情報公開機能 - データ管理_統計処理機能 - データ管理_分析用ダッシュボード機能 - コンテンツ管理_Webページ（静的コンテンツ）公開機能 - **構成される非機能ブロック** - 利用者認証_ユーザ認証機能（職員向け） - 利用者認証_ユーザ認証機能（国民向け） - CI/CD_CI/CDパイプライン機能 - 非機能推奨ブロック - **アーキテクチャ例** - パターン1 ローコード開発ツール利用 ![ブロック概要](/images/general_reference-architecture-chapter-01-03-oci-09-01.png) - パターン2 サーバレス利用 ![ブロック概要](/images/general_reference-architecture-chapter-01-03-oci-09-02.png)

## 3-10. 資格管理システム

3-10-1. AWS

* **構成される業務ブロック** * 申請・届出_ステータス管理機能 * データ管理_データ収集機能 * コンテンツ管理_Webページ(静的コンテンツ)公開機能 * 外部連携_システム間認証機能 * 外部連携_外部連携機能(API公開) * **構成される非機能ブロック** * CI/CD_CI/CDパイプライン機能 * 非機能推奨ブロック * **アーキテクチャ例** ![ブロック概要](/images/general_reference-architecture-chapter-01-03-aws-10-01.png)

3-10-4. OCI

- **構成される業務ブロック** - 申請・届出_ステータス管理機能 - データ管理_データ収集機能 - コンテンツ管理_Webページ(静的コンテンツ)公開機能 - 外部連携_システム間認証機能 - 外部連携_外部連携機能(API公開) - **構成される非機能ブロック** - CI/CD_CI/CDパイプライン機能 - 非機能推奨ブロック - **アーキテクチャ例** - パターン1 ローコード開発ツール利用 ![ブロック概要](/images/general_reference-architecture-chapter-01-03-oci-10-01.png) - パターン2 サーバレス利用 ![ブロック概要](/images/general_reference-architecture-chapter-01-03-oci-10-02.png)

# 4. システム構成検討における留意事項本章では、システム刷新にあたって考慮すべき事項やリファレンスアーキテクチャの効率的な利用方法を示す。 ## 4-1. 災害対策構成「ガバメントクラウド概要解説 6.3 クラウドに適したディザスタリカバリ環境」に示すとおり、システムの構成検討では、RTO (目標復旧時間) やRPO (目標復旧地点)、クラウドの特徴（データコピーの容易性、環境構築の俊敏性、リソースの柔軟性など）の活用を意識した災害対策（DR：Disaster Recovery）の検討が必要となる。本節では概要解説に挙げる4つのDRパターン構成における留意事項などを示す。なお、アーキテクチャ構成例はAWSで示すが、他のCSPを利用する際も同様の考慮点を意識すること。また、システムの業務特性によって講じるべき災害対策は異なるため、**本リファレンスアーキテクチャを参考にして、費用対効果が高く、要求に適したレジリエンス（回復力）を実現できる構成を検討されたい。** ### DRパターンごとの構成留意事項

4-1-1. マルチゾーンパターン（シングルリージョン構成）

　マルチゾーンパターンは、リージョン内の複数ゾーンにて冗長性が担保されたサービスを利用し、ゾーン被災時はレプリケーションしたデータやアプリケーションの切り替えで復旧を行う構成である。

- 災害対策要件でリージョン全域にわたる大規模災害を想定しない場合でも、**可用性向上のためマルチゾーンでの構成をとることを推奨**する。 - マルチゾーンでの可用性が担保されるマネージドサービスで構成する場合、ゾーン被災時に備えた手順準備や運用作業などの考慮は基本的に不要となる。
ただし、ゾーン被災を考慮するべきマネージドサービスも存在するため、**利用するサービスのドキュメント等を確認し必要に応じて冗長化やバックアップを行うこと**を求める。

構成例（電子申請・審査システム（AWS））

![構成例1](/images/general_reference-architecture-chapter-01-03-drmultizone-01.png)

4-1-2. バックアップパターン

　バックアップパターンは、本番リージョンで取得したバックアップを異なる災対リージョンへ転送する構成であり、本番リージョンの被災復旧後に災対リージョンにてバックアップしていたデータなどを用いて本番リージョン上でシステムをリストアする。

- 手動作業によるバックアップは行わず、CSPが提供するバックアップサービスや機能を積極的に用いた災対リージョンへのバックアップを検討すること。 - バックアップサービスの対象外であったり、クロスリージョンレプリケーション機能を有さないサービスである場合、独自でバックアップ処理を実装する必要があるため事前に要否を確認することを推奨する。

構成例（電子申請・審査システム（AWS））

![構成例1](/images/general_reference-architecture-chapter-01-03-drbackuprestore-01.png)

4-1-3. ウォームスタンバイパターン

更新予定

4-1-4. アクティブ-アクティブパターン

更新予定

## 4-2. フロントエンド・バックエンド分離型 Web システム構成 `クラウド基本方針`や`ガバメントクラウド概要解説`に掲げるとおり、ガバメントクラウドでは、システム刷新時にフロントエンド・バックエンド分離型のWebシステムへ見直すことを必須検討事項としている。 **リファレンスアーキテクチャでは、フロントエンド・バックエンド分離を基本としてブロック実現例を示しており、本項や後述「4-3. ブロック構成例における方式パターン」で紹介する方式パターンとあわせてWebシステムの構成見直しを検討されたい。** フロントエンド・バックエンド分離型Webシステムは、ユーザーインターフェース（フロントエンド）とデータ処理やサーバーサイドロジック（バックエンド）が明確に分離されているアーキテクチャのことを指し、分離することによって以下のような利点が得られる。 |項目|説明（クラウド基本方針再掲）| |---|---| |高い再利用性|これまで画面生成に埋め込んでいた同じコードの繰り返し再利用による無駄（開発規模の肥大化）を解消でき、開発コストを削減できる。| |開発規模の適正化|利用者体験（ユーザエクスペリエンス）を踏まえた全体アーキテクチャ検討の後に、UX 設計をワイヤーフレーム（画面レイアウト）まで具体化したフロントエンドを作成することで、真に使いやすいシステムにできる。使いやすいシステムは多階層の大規模な画面構成とならないため、開発規模の適正化（開発コスト削減）にも寄与する| |高い変更容易性|フロントエンドとバックエンドを API によって独立させ、疎結合にすることで変更に強いアーキテクチャとなる。画面表示の修正はフロントエンドのみの修正、業務処理の修正はバックエンドのみの修正となり、将来の改修時の改修対象が限定、極小化され、保守費用が削減される。| |通信量やサーバ負荷の軽減|分離型にすると、バックエンドではインタフェースが API のみとなるのでアーキテクチャがシンプルになり、画面処理もなくなるのでセッション情報の維持なども減る。また、これまでサーバ側で処理していたレンダリング（画面生成）をクライアント側で行うので、サーバ（クラウド）側に必要なコンピュートリソースも少なくなってコスト削減につながる。更には、クライアントとサーバ（クラウド）間の通信も最小化され処理の高速化にも寄与する。

フロントエンド・バックエンド分離構成例

## 4-3. ブロック構成例における方式パターン本リファレンスアーキテクチャにて挙げるブロック実現例は、各クラウドサービス（CSP）が提供するサービスを組み合わせて構成している。 CSPが提供するサービスの組み合わせはパターン化し、複数のブロック実現例に同様のパターンが採用されている。本リファレンスアーキテクチャでは、パターン化したサービスの組み合わせごとに**方式パターンタグ**を用意し、ブロック実現例で採用している方式パターンのタグ付けを行なっている。このタグ付けにより、パターン化したサービスの組み合わせがどのブロック実現例において採用されているかを把握できる。なお、本項の方式パターン以外での固有構成もあるため、タグ付けが行われていないブロック実現例も存在する。 ### 4-3-1. 方式パターン一覧ブロック実現例では以下の方式パターンを採用している。 |

タグ

| 概要 | 説明 |

利用するサービス

| | :---| :--- | :--- | :--- | | `#コンテナバックエンド` | コンテナ上で処理を実行し、データベースまたはストレージに保管されたデータを管理するための機能をWeb APIとして公開する。| 複数のコンテナによる冗長化のために、ロードバランサーと組み合わせて構成する。
アプリケーションのソースコードや依存ライブラリ等を含めてコンテナイメージとしてパッケージングすることで、様々な環境でのアプリケーション実行が可能である。また、CSPによっては、サーバを意識せずにコンテナの起動が可能なサービスが提供されている場合もある。フロントエンド・バックエンド分離型のシステムを構築する場合、「サーバレスフロントエンド」のパターンとの組み合わせることができる。 | ・ロードバランサー
・アプリケーション実行（コンテナ）
・データベース
・ストレージ | | `#サーバレスバックエンド` | サーバレスのアプリケーション実行環境を用いて処理を実行し、データベースまたはストレージに保管されたデータを管理するための機能をWeb APIとして公開する。 | APIの呼び出し元の認証についても、サーバレスのID管理を用いて構成する。
アプリケーション実行については、サーバを意識せずに済む構成であり、フロントエンド・バックエンド分離型のシステムを構築する場合、「サーバレスフロントエンド」のパターンとの組み合わせることができる。 | ・API公開
・アプリケーション実行（サーバレス）
・データベース
・ストレージ
・ID管理 | | `#サーバレスフロントエンド` | コンテンツ配信ネットワーク（CDN）を経由して、ストレージに配置したフロントエンドのファイル一式を配信する。 | ファイルの配信のためにサーバの構築は不要であり、サーバの管理が不要となる。また、コンテンツ配信ネットワーク（CDN）にファイルをキャッシュすることにより、利用者に対して高速にフロントエンドを配信することができる。 | ・コンテンツ配信ネットワーク（CDN）
・ストレージ | | `#ストレージ直接アクセス` | ファイルのアップロードまたはダウンロードをストレージに対して直接実行する。 | サーバを経由しないため、ファイルサイズが大きい場合でも効率的にストレージへのアクセスが可能である。ストレージへのファイルのアップロードを契機として後続の処理を実行する、イベントドリブン型のシステムを構築する場合、「サーバレスイベント処理」のパターンと組み合わせることができる。 | ・ストレージ | | `#サーバレスデータ連携` | データベースに保管されたデータを抽出し、連携先に合わせたデータの変換などの処理を実行する。 | データ連携用のサーバレスサービスを用いて構成することで、サーバの管理が不要となり、規模の大きなデータに対しても柔軟に対応することが可能である。 | ・データベース
・データ連携（サーバレス） | | `#ストリーム処理` | リアルタイムに送信されるようなストリーム形式の入力に対して、変換などの処理を実行する。 | ストリーム処理用のサーバレスサービスを用いて構成する。ストリーム処理用のサーバレスサービスを用いて構成することで、サーバの管理が不要となる。 | ・ストリーム処理（サーバレス）
※ 以下は処理結果の保存先として利用
・ストレージ
・データベース | | `#サーバレスイベント処理` | ストレージへのファイルのアップロード等のイベントを検知し、処理を自動的に起動する。 | イベントドリブン型のシステムを構築する場合に用いられるパターンである。イベントドリブン型とすることで、バッチ処理用のリソースを確保することが不要となり、また、データの反映を即座に行うことができる。スケジュールに基づく定期的な起動もイベントのバリエーションの一つとする。 | ・イベント管理
・アプリケーション実行（サーバレス）
・アプリケーション実行（コンテナ）
・ストレージ ※イベントソースとして利用 | | `#メッセージキュー` | システムのコンポーネント間をメッセージキューで繋ぎ、メッセージキューに格納された処理対象に非同期で処理を実行する。 | コンポーネント間をメッセージキューで繋ぐことで、処理対象の数が急増した場合にも対応することができ、また、コンポーネントで障害が発生した場合の影響を局所化することができる。 | ・メッセージキュー
・アプリケーション実行（サーバレス）
・アプリケーション実行（コンテナ） | ### 4-3-2. 方式パターンごとのCSPでの構成例各CSPごとの方式パターンのサービス構成例を以下に示す。現在はAWSのみであるが、順次他CSPについても記載を予定している。

AWS

タグ

| 利用サービス例 | | :---| :--- | | `#コンテナバックエンド` | ・ロードバランサー：Elastic Load Balancing
・アプリケーション実行（コンテナ）：Amazon ECS
・データベース：Amazon DocumentDB、Amazon Aurora等
・ストレージ：Amazon S3等 | | `#サーバレスバックエンド` | ・API公開：Amazon API Gateway
・アプリケーション実行（サーバレス）：AWS Lambda
・データベース：Amazon DocumentDB、Amazon Aurora等
・ストレージ：Amazon S3等
・ID管理：Amazon Cognito | | `#サーバレスフロントエンド` |・コンテンツ配信ネットワーク（CDN）：Amazon CloudFront
・ストレージ：Amazon S3 | | `#ストレージ直接アクセス` |・ストレージ：Amazon S3 | | `#サーバレスデータ連携` | ・データベース：Amazon DocumentDB、Amazon Aurora等
・データ連携（サーバレス）：AWS Glue | | `#ストリーム処理` | ・ストリーム処理（サーバレス）：Amazon Kinesis Data Streams、Amazon Kinesis Data Firehorse
・ストレージ：Amazon S3等
・データベース：Amazon DocumentDB、Amazon Aurora等 | | `#サーバレスイベント処理` | ・イベント管理：Amazon EventBridge
・アプリケーション実行（サーバレス）：AWS Lambda
・アプリケーション実行（コンテナ）：Amazon ECS
・ストレージ：Amazon S3 | | `#メッセージキュー` | ・メッセージキュー：Amazon SQS
・アプリケーション実行（サーバレス）：AWS Lambda
・アプリケーション実行（コンテナ）：Amazon ECS |

## 改訂履歴 | 改訂年月日 | 改訂理由 | | ------------------- | -------- | | 2023 年 11 月 2 日 | 新規作成 | | 2023 年 12 月 22 日 | 2章の業務ブロックおよび非機能ブロックの並び替え、名称変更、拡充 | | 2023 年 12 月 22 日 | 3章の各CSPのシステムアーキテクチャ例の拡充 | | 2024 年 03 月 29 日 | 2章の業務ブロックおよび非機能ブロックの拡充 | | 2024 年 03 月 29 日 | 3章の各CSPのシステムアーキテクチャ例の拡充 | | 2024 年 03 月 29 日 | 4章を新規追加 | | 2024 年 06 月 14 日 | 3章 OCIのシステムアーキテクチャ例の拡充 | | 2024 年 09 月 02 日 | 3章 AWSのシステムアーキテクチャ例の変更（電子申請・審査システム） | | 2024 年 10 月 01 日 | 3章 OCIのシステムアーキテクチャ例の変更（電子申請・審査システム、許認可関連システム、データ収集・公開システム（災害・気象情報等）、府省庁Webサイト、資格管理システム） | | 2024 年 11 月 29 日 | 3章 AWSのシステムアーキテクチャ例の変更（オンライン調査システム）
3章 Azureのシステムアーキテクチャ例の追加（統計システム） |

リファレンスアーキテクチャ（第1～4章 全体概要）

リファレンスアーキテクチャ（第1～4章全体概要）