ブロック実現例

ブロック実現例 説明

[1]

• 本人確認の保証レベルがレベルAの場合には、公的個人認証サービスと連携し、マイナンバーカードに搭載された電子証明書によって利用者の身元確認と当人認証を行う手法がガイドラインで示されている。身元確認(ID作成)では、署名用証明書を用い、4情報(住所、氏名、生年月日、性別)を取得し、また、当人認証(システム利用)では、利用者証明証証明を用いることを想定している。
• 利用者は、スマホ等の端末で電子証明書に設定したPIN/パスワードを入力し、マイナンバーカードの読み取りを行う。
• ※ 利用システム向けの機能が公的認証サービスから直接提供されるわけではなく、認証・署名サービスが別途必要である。認定事業者の既存サービスまたは独自に構築する選択肢がある。公的個人認証サービスに関する技術情報(インタフェース仕様、連携のための手続きや制約事項等)は、別途確認する必要がある。また、アプリケーションのトークン発行に関するAzure AD B2Cの構成はあくまで例であり、実現性を保証するものではない。認証・署名サービスとの接続仕様や利用システムの要件に応じて構成を検討する必要がある。

[2]

• Azure AD B2Cのユーザー管理機能を使用し、公的個人認証サービスによって認証されたユーザに対するトークンを発行する。
  [3]
• ユーザ情報を管理するためのWebAPIはAPI Managementにより構築される。
• API ManagementはAzure AD B2CをWebAPIの呼び出し可否の判断に使用するオーソライザーとして連携することが可能である。
• Azure AD B2Cをオーソライザーとして設定することで、トークンの有効性確認の処理をAPI Managementに任せることができる。
• API Managementのポリシーなどの活用によりスロットリング制限やIP制限などのセキュリティ対策を実施することができる。
  [4]
• Azure Cosmos DBに格納されたユーザー情報に対してAzure Functionsから新規作成や更新等のデータ管理を行う。
• Azure Functionsについてはアプリケーションの要件によってAzure Container AppsやApp Serviceなども選択できる。
• データベースサービスについても同様に、Azure SQL DatabaseなどのRDBMSも選択可能である。

ブロック実現例

ブロック実現例 説明

[1]

• 本人確認の保証レベルがレベルBの場合には、公的個人認証サービスと連携し、マイナンバーカードに搭載された電子証明書によって利用者の身元確認を行う手法がガイドラインで示されている。
• 一方、利用者の当人認証については、マイナンバーカードもしくは多要素認証による手法がガイドラインで示されており、本パターンではマイナンバーカードによる手法を示す。身元確認(ID作成)では、署名用証明書を用い、4情報(住所、氏名、生年月日、性別)を取得し、また、当人認証(システム利用)では、利用者証明証証明を用いることを想定している。利用者は、スマホ等の端末で電子証明書に設定したPIN/パスワードを入力し、マイナンバーカードの読み取りを行う
• ※ 利用システム向けの機能が公的認証サービスから直接提供されるわけではなく、認証・署名サービスが別途必要である。認定事業者の既存サービスまたは独自に構築する選択肢がある。公的個人認証サービスに関する技術情報(インタフェース仕様、連携のための手続きや制約事項等)は、別途確認する必要がある。また、アプリケーションのトークン発行に関するAzure AD B2Cの構成はあくまで例であり、実現性を保証するものではない。認証・署名サービスとの接続仕様や利用システムの要件に応じて構成を検討する必要がある。

[2]

• Azure AD B2Cのユーザー管理機能を使用し、公的個人認証サービスによって認証されたユーザに対するトークンを発行する。
  [3]
• ユーザ情報を管理するためのWebAPIはAPI Managementにより構築される。
• API ManagementはAzure AD B2CをWebAPIの呼び出し可否の判断に使用するオーソライザーとして連携することが可能である。
• Azure AD B2Cをオーソライザーとして設定することで、トークンの有効性確認の処理をAPI Managementに任せることができる。
• API Managementのポリシーなどの活用によりスロットリング制限やIP制限などのセキュリティ対策を実施することができる。
  [4]
• Azure Cosmos DBに格納されたユーザー情報に対してAzure Functionsから新規作成や更新等のデータ管理を行う。
• Azure Functionsについてはアプリケーションの要件によってAzure Container AppsやApp Serviceなども選択できる。
• データベースサービスについても同様に、Azure SQL DatabaseなどのRDBMSも選択可能である。

ブロック実現例

ブロック実現例 説明

[1]

• 本人確認の保証レベルがレベルBの場合には、公的個人認証サービスと連携し、マイナンバーカードに搭載された電子証明書によって利用者の身元確認を行う手法がガイドラインで示されている。
• 一方、利用者の当人認証については、マイナンバーカードもしくは多要素認証による手法がガイドラインで示されており、本パターンでは多要素認証による手法を示す。Azure AD B2Cにより、ワンタイムパスワードを用いた多要素認証を行う。
• ※ 利用システム向けの機能が公的認証サービスから直接提供されるわけではなく、認証・署名サービスが別途必要である。認定事業者の既存サービスまたは独自に構築する選択肢がある。公的個人認証サービスに関する技術情報(インタフェース仕様、連携のための手続きや制約事項等)は、別途確認する必要がある。また、アプリケーションのトークン発行に関するAzure AD B2Cの構成はあくまで例であり、実現性を保証するものではない。認証・署名サービスとの接続仕様や利用システムの要件に応じて構成を検討する必要がある。

[2]

• Azure AD B2Cのユーザー管理機能を使用し、公的個人認証サービスによって認証されたユーザに対するトークンを発行する。
  [3]
• ユーザ情報を管理するためのWebAPIはAPI Managementにより構築される。
• API ManagementはAzure AD B2CをWebAPIの呼び出し可否の判断に使用するオーソライザーとして連携することが可能である。
• Azure AD B2Cをオーソライザーとして設定することで、トークンの有効性確認の処理をAPI Managementに任せることができる。
• API Managementのポリシーなどの活用によりスロットリング制限やIP制限などのセキュリティ対策を実施することができる。
  [4]
• Azure Cosmos DBに格納されたユーザー情報に対してAzure Functionsから新規作成や更新等のデータ管理を行う。
• Azure Functionsについてはアプリケーションの要件によってAzure Container AppsやApp Serviceなども選択できる。
• データベースサービスについても同様に、Azure SQL DatabaseなどのRDBMSも選択可能である。

ブロック実現例

ブロック実現例 説明

[1]

• 本人確認の保証レベルがレベルBの場合には、公的個人認証サービスと連携し、マイナンバーカードに搭載された電子証明書によって利用者の身元確認を行う手法がガイドラインで示されている。
• 一方、利用者の当人認証については、マイナンバーカードもしくは多要素認証による手法がガイドラインで示されており、本パターンでは多要素認証による手法を示す。ID管理のOSSにより、ワンタイムパスワードを用いた多要素認証を行う。
• ※ 利用システム向けの機能が公的認証サービスから直接提供されるわけではなく、認証・署名サービスが別途必要である。認定事業者の既存サービスまたは独自に構築する選択肢がある。公的個人認証サービスに関する技術情報(インタフェース仕様、連携のための手続きや制約事項等)は、別途確認する必要がある。

[2]

• OSSで実現するID管理では、ユーザ情報の保管先としてマネージドなデータベースを第一の選択肢として利用する。
• 利用するOSSがサポートするデータベースに準拠し、データベースを選択する。ここでは例としてAzure Cosmos DBを掲載しており、Azure Cosmos DBは、MongoDB、PostgreSQL、Gremlinなどと互換性がある。
  [3]
• ID管理機能が発行したトークンによるアクセス制御を行い、他のWebAPIを提供する機能ブロックへアクセスする。
• トークンの検証は、API Managementのポリシーで実現する方法が考えられる。

ブロック実現例

ブロック実現例 説明

[1]

• 本人確認の保証レベルがレベルBの場合には、確認書類の郵送による身元確認と多要素認証による当人認証を行う手法がガイドラインで示されている。
• ID管理のOSSにより、ワンタイムパスワードを用いた多要素認証を行う。法人・個人事業主向け共通認証システムであるGビズIDでは、gBizIDプライムまたはgBizIDメンバーが保証レベルのレベルBに対応している。(※の2.4 保証レベルより)
• なお、GビズID発行について、個人事業主向けにはすでにオンライン発行可能となっている。また、法人代表者向けには令和5年度末にオンライン化が予定されている。
• ※ gBizID システム連携ガイド（行政サービス向け）: https://gbiz-id.go.jp/top/system_guide/system_guide.htmlopen_in_newopen_in_newOpens in new tab

[2]

• Azure AD B2Cのユーザー管理機能を使用し、GビズIDとの連携(フェデレーション)を実行する。
• gBizIDとは、標準的な認証の仕様であるOpenID Connectのフローに従い、ユーザの認証を行う。
  [3]
• ユーザ情報を管理するためのWebAPIはAPI Managementにより構築される。
• API ManagementはAzure AD B2CをWebAPIの呼び出し可否の判断に使用するオーソライザーとして連携することが可能である。
• Azure AD B2Cをオーソライザーとして設定することで、トークンの有効性確認の処理をAPI Managementに任せることができる。
• API Managementのポリシーなどの活用によりスロットリング制限やIP制限などのセキュリティ対策を実施することができる。
  [4]
• Azure Cosmos DBに格納されたユーザー情報に対してAzure Functionsから新規作成や更新等のデータ管理を行う。
• Azure Functionsについてはアプリケーションの要件によってAzure Container AppsやApp Serviceなども選択できる。
• データベースサービスについても同様に、Azure SQL DatabaseなどのRDBMSも選択可能である。
  [5]
• Azure AD B2Cが発行したトークンによるアクセス制御を行い、他のWebAPIを提供する機能ブロックへアクセスする。トークンの検証は、API Managementのポリシーの機能を用い実現する方法が考えられる。

ブロック実現例

ブロック実現例 説明

[1]

• 本人確認の保証レベルがレベルCの場合には、身元確認が不要であるが、アカウント作成時に入力されたメールアドレスや携帯電話番号の正当な所有者であることの確認を行う。 Azure AD B2Cでは、メールまたはSMSによるアカウント作成時の検証をサポートしている。
• また、当人認証に関しては、Azure AD B2Cが保管するIDとパスワードを用いて実現する。
  [2]
• ユーザ情報を管理するためのWebAPIはAPI Managementにより構築される。
• API ManagementはAzure AD B2CをWebAPIの呼び出し可否の判断に使用するオーソライザーとして連携することが可能である。
• Azure AD B2Cをオーソライザーとして設定することで、トークンの有効性確認の処理をAPI Managementに任せることができる。
• API Managementのポリシーなどの活用によりスロットリング制限やIP制限などのセキュリティ対策を実施することができる。
  [3]
• Azure Cosmos DBに格納されたユーザー情報に対してAzure Functionsから新規作成や更新等のデータ管理を行う。
• Azure Functionsについてはアプリケーションの要件によってAzure Container AppsやApp Serviceなども選択できる。
• データベースサービスについても同様に、Azure SQL DatabaseなどのRDBMSも選択可能である。
  [4]
• Azure AD B2Cが発行したトークンによるアクセス制御を行い、他のWebAPIを提供する機能ブロックへアクセスする。
• トークンの検証は、API Managementのポリシーを用い、実現する方法が考えられる。

ブロック実現例

ブロック実現例 説明

[1]

• 本人確認の保証レベルがレベルCの場合には、身元確認が不要であるが、アカウント作成時に入力されたメールアドレスや携帯電話番号の正当な所有者であることの確認を行う。
• OSSは、認証に関する要件に応じて選択するものとする。例えば、OpenID ConnectのOPの機能を実現するミドルウェアや、シンプルなIDとパスワードによる認証を実現するライブラリなどから、要件に応じて選択する。
• また、ミドルウェアやライブラリの利用に関しての制約が一般的には少ないコンテナ(Azure Container Apps) に加え、Azure Functionsによるサーバレス構成も検討できる。
  [2]
• OSSで実現するID管理では、ユーザ情報の保管先としてマネージドなデータベースを第一の選択肢として利用する。
• 利用するOSSがサポートするデータベースに準拠し、データベースを選択する。ここでは例としてAzure Cosmos DBを掲載しており、Azure Cosmos DBは、MongoDB、PostgreSQL、Gremlinなどと互換性がある。
  [3]
• ID管理機能が発行したトークンによるアクセス制御を行い、他のWebAPIを提供する機能ブロックへアクセスする。
• トークンの検証は、API Managementのポリシーで実現する方法が考えられる。

ブロック実現例

ブロック実現例 説明

[1]

• SPA（Single Page Application）における静的ファイル（HTML、JavaScript、CSS）をAzure Front Door及びAzure Storage Accountsで配信する。
• ファイルは高耐久なオブジェクトストレージであるAzure Storage Accountsに保管する。Azure Front DoorはCDNとしての機能を提供し、大量のリクエストにも低レイテンシーでの応答を実現する。
• またWAFによりインターネット経由で行われる様々な攻撃からフロントエンド配信機能を保護する。

[2]

• ユーザーは他の機能ブロックにおいてユーザー認証を行い、認証トークンを取得する。

[3]

• 申請・届出の入力データはREST APIで送信される。
• REST APIはAPI Management及びAzure Functionsにより構築される。
• またWAFによりインターネット経由で行われる様々な攻撃からAPIを保護する。

[4]

• APIリクエストの認可は認証系の機能ブロックにより発行されるトークンを検証することによって行われる。
• API ManagementはAuthorization ヘッダーで示される連携機能から取得されたアクセストークンを検証し、APIリクエストヘッダーに含まれるトークンの有効性を検証する。
• トークンが有効な場合のみ、APIリクエストは受理される。

[5]

• 認可されたリクエストは、申請・届出内容処理関数によって入力データ、および提出ファイルの形式チェックを行う。
• 内容に問題がない場合はデータベースに保存される。
• データベースはマネージドなAzure SQL Databaseを利用し、運用コストを削減する。

[6]

• 他の機能ブロックは申請・届出内容保管データベースを参照することができる。

ブロック実現例

ブロック実現例 説明

[1]

• SPA（Single Page Application）における静的ファイル（HTML、JavaScript、CSS）をAzure Front Door及びAzure Storage Accountsで配信する。
• ファイルは高耐久なオブジェクトストレージであるAzure Storage Accountsに保管する。Azure Front DoorはCDNとしての機能を提供し、大量のリクエストにも低レイテンシーでの応答を実現する。
• またWAFによりインターネット経由で行われる様々な攻撃からフロントエンド配信機能を保護する。

[2]

• ユーザーは他の機能ブロックにおいてユーザー認証を行い、認証トークンを取得する。

[3]

• 申請・届出の入力データはREST APIで送信される。
• REST APIはAPI Management及びAzure Functionsにより構築される。
• またWAFによりインターネット経由で行われる様々な攻撃からAPIを保護する。

[4]

• APIリクエストの認可は認証系の機能ブロックにより発行されるトークンを検証することによって行われる。
• API ManagementはAuthorization ヘッダーで示される連携機能から取得されたアクセストークンを検証し、APIリクエストヘッダーに含まれるトークンの有効性を検証する。
• トークンが有効な場合のみ、APIリクエストは受理される。

[5]

• 認可されたリクエストは、申請・届出内容処理関数によって提出ファイルの形式チェックを行う。
• 内容に問題がない場合は申請・届出内容保管ストレージであるAzure Storage Accountに保存される。（ファイルの提出者などのメタデータについてはファイルのメタデータとして保存するか、もしくは別途のデータベースなどに保管する。）

[6]

• 他の機能ブロックは申請・届出内容保管ストレージを参照することができる。

ブロック実現例

ブロック実現例 説明

[1]

• SPA（Single Page Application）における静的ファイル（HTML、JavaScript、CSS）をAzure Front Door及びAzure Storage Accountsで配信する。
• ファイルは高耐久なオブジェクトストレージであるAzure Storage Accountsに保管する。Azure Front DoorはCDNとしての機能を提供し、大量のリクエストにも低レイテンシーでの応答を実現する。
• またWAFによりインターネット経由で行われる様々な攻撃からフロントエンド配信機能を保護する。

[2]

• ユーザーは他の機能ブロックにおいてユーザー認証を行い、認証トークンを取得する。

[3]

• 申請・届出の入力データはREST APIで送信される。
• REST APIはAPI Management及びAzure Functionsにより構築される。
• またWAFによりインターネット経由で行われる様々な攻撃からAPIを保護する。

[4]

• APIリクエストの認可は認証系の機能ブロックにより発行されるトークンを検証することによって行われる。
• API ManagementはAuthorization ヘッダーで示される連携機能から取得されたアクセストークンを検証し、APIリクエストヘッダーに含まれるトークンの有効性を検証する。
• トークンが有効な場合のみ、APIリクエストは受理される。

[5]

• 認可されたリクエストは、申請・届出内容処理関数によって提出ファイルの形式チェックを行う。
• 内容に問題がない場合は申請・届出内容保管ストレージであるAzure Storage Accountに保存される。（ファイルの提出者などのメタデータについてはファイルのメタデータとして保存するか、もしくは別途のデータベースなどに保管する。）

[6]

• ストレージにファイルが書き込まれたイベントをトリガーとして、Microsoft Defender for Storageがファイルのスキャニングを行う。このイベント連携は自動的に作成されるAzure Event Hubを介して行われる。
• スキャニングの結果はストレージ上のファイルのメタデータとして記録される。

[7]

• マルウェアなどの問題が検出された場合にはマルウェア検出ファイル除去関数を起動し、ファイルの除去や隔離を行う。
• また、管理者や運用者に対して必要なアラート発出をMicrosoft Defender for Cloud security alertを介して行う。

[8]

• 他の機能ブロックは申請・届出内容保管ストレージを参照することができる。

ブロック実現例

ブロック実現例 説明

[1]

• SPA（Single Page Application）における静的ファイル（HTML、JavaScript、CSS）をAzure Front Door及びAzure Storage Accountsで配信する。
• ファイルは高耐久なオブジェクトストレージであるAzure Storage Accountsに保管する。Azure Front DoorはCDNとしての機能を提供し、大量のリクエストにも低レイテンシーでの応答を実現する。
• またWAFによりインターネット経由で行われる様々な攻撃からフロントエンド配信機能を保護する。

[2]

• ユーザーは他の機能ブロックにおいてユーザー認証を行い、認証トークンを取得する。

[3]

• 申請・届出の入力データはREST APIで送信される。
• REST APIはAPI Management及びAzure Functionsにより構築される。
• またWAFによりインターネット経由で行われる様々な攻撃からAPIを保護する。

[4]

• APIリクエストの認可は認証系の機能ブロックにより発行されるトークンを検証することによって行われる。
• API ManagementはAuthorization ヘッダーで示される連携機能から取得されたアクセストークンを検証し、APIリクエストヘッダーに含まれるトークンの有効性を検証する。
• トークンが有効な場合のみ、APIリクエストは受理される。

[5]

• 認可されたリクエストは、申請・届出内容処理関数によって提出ファイルの形式チェックを行う。
• 内容に問題がない場合は申請・届出内容保管データベースであるAzure Cosmos DB for MongoDBに保存される。MongoDBはJSONなどの構造化ドキュメントを保存することに適したドキュメントデータベースであるため、申請内容がJSON等として扱える場合に利用できる。

[6]

• 他の機能ブロックは申請・届出内容保管ストレージを参照することができる。

ブロック実現例

ブロック実現例 説明

[1]

• SPA（Single Page Application）における静的ファイル（HTML、JavaScript、CSS）をAzure Front Door及びAzure Storage Accountsで配信する。
• ファイルは高耐久なオブジェクトストレージであるAzure Storage Accountsに保管する。Azure Front DoorはCDNとしての機能を提供し、大量のリクエストにも低レイテンシーでの応答を実現する。
• またWAFによりインターネット経由で行われる様々な攻撃からフロントエンド配信機能を保護する。

[2]

• ユーザーは他の機能ブロックにおいてユーザー認証を行い、認証トークンを取得する。

[3]

• 申請・届出の入力データはREST APIで送信される。
• REST APIはAPI Management及びAzure Functionsにより構築される。
• またWAFによりインターネット経由で行われる様々な攻撃からAPIを保護する。

[4]

• APIリクエストの認可は認証系の機能ブロックにより発行されるトークンを検証することによって行われる。
• API ManagementはAuthorization ヘッダーで示される連携機能から取得されたアクセストークンを検証し、APIリクエストヘッダーに含まれるトークンの有効性を検証する。
• トークンが有効な場合のみ、APIリクエストは受理される。

[5]

• 認可されたリクエストは、申請・届出内容処理関数によって提出ファイルの形式チェックを行う。
• 内容に問題がない場合は申請・届出内容保管データベースであるDataverseに保存される。DataverseはPower Platformでデータを扱うためのデータベースである。以降の処理でPower Platformを用いる場合に本構成が勧められる。ただし、Dataverseは6000アクセス / 5分などのアクセス上限があるため、大規模な利用が見込まれる場合には他構成を取ること。
• https://learn.microsoft.com/ja-jp/power-apps/developer/data-platform/api-limits?tabs=sdkopen_in_newOpens in new tab
• Power Platformの利用は、GSSに問い合わせるか、利用組織による調達を想定するものとする。

[6]

• 他の機能ブロックは申請・届出内容保管ストレージであるDataverseを参照することができる。

ブロック実現例

ブロック実現例 説明

[1]

• SPA（Single Page Application）における静的ファイル（HTML、JavaScript、CSS）をAzure Front Door及びAzure Storage Accountsで配信する。
• ファイルは高耐久なオブジェクトストレージであるAzure Storage Accountsに保管する。Azure Front DoorはCDNとしての機能を提供し、大量のリクエストにも低レイテンシーでの応答を実現する。
• またWAFによりインターネット経由で行われる様々な攻撃からフロントエンド配信機能を保護する。
  [2]
• ユーザーは他の機能ブロックにおいてユーザー認証を行い、認証トークンを取得する。
  [3]
• 申請・届出の入力データはREST APIで送信される。
• REST APIはAPI Management及びAzure Functionsにより構築される。
• またWAFによりインターネット経由で行われる様々な攻撃からAPIを保護する。
  [4]
• APIリクエストの認可は認証系の機能ブロックにより発行されるトークンを検証することによって行われる。
• API ManagementはAuthorization ヘッダーで示される連携機能から取得されたアクセストークンを検証し、APIリクエストヘッダーに含まれるトークンの有効性を検証する。
• トークンが有効な場合のみ、APIリクエストは受理される。
  [5]
• 認可されたリクエストは、申請・届出内容処理関数にて入力データおよび提出ファイルに対するテキスト抽出処理及び形式チェック処理を行う。
• Azure FunctionsとDocument Intelligenceにより、AI機能を利用して提出ファイルからチェックに必要なテキストを抽出する。
• Azure FunctionsとAzure OpenAI Serviceにより、AI機能を利用して入力データや抽出されたテキストに対してチェックを行う。
  [6]
• 内容に問題がない場合はデータベースに保存される。
• データベースはマネージドなAzure SQL Databaseを利用し、運用コストを削減する。
  [7]
• 他の機能ブロックは申請・届出内容保管データベースを参照することができる。

ブロック実現例

ブロック実現例 説明

[1]

• SPA（Single Page Application）における静的ファイル（HTML、JavaScript、CSS）をAzure Front Door及びAzure Storage Accountsで配信する。
• ファイルは高耐久なオブジェクトストレージであるAzure Storage Accountsに保管する。Azure Front DoorはCDNとしての機能を提供し、大量のリクエストにも低レイテンシーでの応答を実現する。
• またWAFによりインターネット経由で行われる様々な攻撃からフロントエンド配信機能を保護する。
  [2]
• ユーザーは他の機能ブロックにおいてユーザー認証を行い、認証トークンを取得する。
  [3]
• 申請・届出の入力データはREST APIで送信される。
• REST APIはAPI Management及びAzure Functionsにより構築される。
• またWAFによりインターネット経由で行われる様々な攻撃からAPIを保護する。
  [4]
• APIリクエストの認可は認証系の機能ブロックにより発行されるトークンを検証することによって行われる。
• API ManagementはAuthorization ヘッダーで示される連携機能から取得されたアクセストークンを検証し、APIリクエストヘッダーに含まれるトークンの有効性を検証する。
• トークンが有効な場合のみ、APIリクエストは受理される。
  [5]
• 認可されたリクエストは、申請・届出内容処理関数にて入力データおよび提出ファイルに対するテキスト抽出処理及び形式チェック処理を行う。
• Azure FunctionsとDocument Intelligenceにより、AI機能を利用して提出ファイルからチェックに必要なテキストを抽出する。
• Azure FunctionsとAzure OpenAI Serviceにより、AI機能を利用して入力データや抽出されたテキストに対してチェックを行う。
  [6]
• 内容に問題がない場合は申請・届出内容保管ストレージであるAzure Storage Accountに保存される。（ファイルの提出者などのメタデータについてはファイルのメタデータとして保存するか、もしくは別途のデータベースなどに保管する。）
  [7]
• 他の機能ブロックは申請・届出内容保管ストレージを参照することができる。

ブロック実現例

ブロック実現例 説明

[1]

• 本機能は、別機能における処理の中で添付資料のアップロードが必要になった場合に利用される想定。

[2]

• ユーザーは他の機能ブロックにおいてユーザー認証を行い、認証トークンを取得する。

[3]

• 添付資料はREST APIで送信される。
• REST APIはAPI Management及びAzure Functionsにより構築される。
  またWAFによりインターネット経由で行われる様々な攻撃からAPIを保護する。

[4]

• APIリクエストの認可は認証系の機能ブロックにより発行されるトークンを検証することによって行われる。
• API ManagementはAuthorization ヘッダーで示される連携機能から取得されたアクセストークンを検証し、APIリクエストヘッダーに含まれるトークンの有効性を検証する。
• トークンが有効な場合のみ、APIリクエストは受理される。

[5]

• 認可されたリクエストは、添付資料処理関数にてAzure Storage Accountへ保存される。
• この関数では要件に応じて、添付資料の整形や検証も行う。

[6]

• 他の機能ブロックは添付資料保管ストレージ内のファイルを参照することができる。

ブロック実現例

ブロック実現例 説明

[1]

• 本機能は、別機能における処理の中で添付資料のアップロードが必要になった場合に利用される想定。

[2]

• ユーザーは他の機能ブロックにおいてユーザー認証を行い、認証トークンを取得する。

[3]

• 添付資料はREST APIで送信される。
• REST APIはAPI Management及びAzure Functionsにより構築される。
  またWAFによりインターネット経由で行われる様々な攻撃からAPIを保護する。

[4]

• APIリクエストの認可は認証系の機能ブロックにより発行されるトークンを検証することによって行われる。
• API ManagementはAuthorization ヘッダーで示される連携機能から取得されたアクセストークンを検証し、APIリクエストヘッダーに含まれるトークンの有効性を検証する。
• トークンが有効な場合のみ、APIリクエストは受理される。

[5]

• 認可されたリクエストは、添付資料処理関数にてAzure Storage Accountへ保存される。
• この関数では要件に応じて、添付資料の整形や検証も行う。

[6]

• 上記に合わせて添付資料のメタデータを添付資料メタデータ保管データベースに保存する。（ユーザーなど他のRDB上のデータとの紐づきの強いデータの場合はAzure SQL Databaseに、不定形なタグデータの場合はAzure Cosmos DBに保存する。）

[7]

• 他の機能ブロックは添付資料保管ストレージ内のファイルを参照することができる。

ブロック実現例

ブロック実現例 説明

[1]

• 本機能は、別機能における処理の中で添付資料のアップロードが必要になった場合に利用される想定。

[2]

• ユーザーは他の機能ブロックにおいてユーザー認証を行い、認証トークンを取得する。

[3]

• 添付資料はREST APIで送信される。
• REST APIはAPI Management及びAzure Functionsにより構築される。
  またWAFによりインターネット経由で行われる様々な攻撃からAPIを保護する。

[4]

• APIリクエストの認可は認証系の機能ブロックにより発行されるトークンを検証することによって行われる。
• API ManagementはAuthorization ヘッダーで示される連携機能から取得されたアクセストークンを検証し、APIリクエストヘッダーに含まれるトークンの有効性を検証する。
• トークンが有効な場合のみ、APIリクエストは受理される。

[5]

• 認可されたリクエストは、添付資料処理関数にてAzure Storage Accountへ保存される。
• この関数では要件に応じて、添付資料の整形や検証も行う。

[6]

• ストレージにファイルが書き込まれたイベントをトリガーとして、Microsoft Defender for Storageがファイルのスキャニングを行う。このイベント連携は自動的に作成されるAzure Event Hubを介して行われる。
• スキャニングの結果はストレージ上のファイルのメタデータとして記録される。

[7]

• マルウェアなどの問題が検出された場合にはマルウェア検出ファイル除去関数を起動し、ファイルの除去や隔離を行う。
• また、管理者や運用者に対して必要なアラート発出をMicrosoft Defender for Cloud security alertを介して行う。

[8]

• 他の機能ブロックは添付資料保管ストレージ内のファイルを参照することができる。

ブロック実現例

ブロック実現例 説明

[1]

• 本機能は、別機能における処理の中で添付資料のアップロードが必要になった場合に利用される想定。
  [2]
• ユーザーは他の機能ブロックにおいてユーザー認証を行い、認証トークンを取得する。
  [3]
• 添付資料はREST APIで送信される。
• REST APIはAPI Management及びAzure Functionsにより構築される。
  またWAFによりインターネット経由で行われる様々な攻撃からAPIを保護する。
  [4]
• APIリクエストの認可は認証系の機能ブロックにより発行されるトークンを検証することによって行われる。
• API ManagementはAuthorization ヘッダーで示される連携機能から取得されたアクセストークンを検証し、APIリクエストヘッダーに含まれるトークンの有効性を検証する。
• トークンが有効な場合のみ、APIリクエストは受理される。
  [5]
• 認可されたリクエストは、添付資料処理関数にてAzure Storage Accountへ保存される。
• この関数では要件に応じて、添付資料の整形も行う。
• 添付資料の検証を行う場合は、Azure FunctionsとDocument Intelligence、Azure OpenAI ServiceによりAI機能を利用して添付ファイルからテキストを抽出し、検証を行う。
  [6]
• 他の機能ブロックは添付資料保管ストレージ内のファイルを参照することができる。

ブロック実現例

ブロック実現例 説明

[1]

• SPA（Single Page Application）における静的ファイル（HTML、JavaScript、CSS）をAzure Front Door及びAzure Storage Accountsで配信する。
• ファイルは高耐久なオブジェクトストレージであるAzure Storage Accountsに保管する。Azure Front DoorはCDNとしての機能を提供し、大量のリクエストにも低レイテンシーでの応答を実現する。
• またWAFによりインターネット経由で行われる様々な攻撃からフロントエンド配信機能を保護する。

[2]

• ユーザーは他の機能ブロックにおいてユーザー認証を行い、認証トークンを取得する。

[3]

• ステータスはREST APIで取得される。
• REST APIはAzure Front Door及びAzure Functionsにより構築される。
• またWAFによりインターネット経由で行われる様々な攻撃からAPIを保護する。

[4]

• APIリクエストの認可は認証系の機能ブロックにより発行されるトークンを検証することによって行われる。
• API ManagementはAuthorization ヘッダーで示される連携機能から取得されたアクセストークンを検証し、APIリクエストヘッダーに含まれるトークンの有効性を検証する。
• トークンが有効な場合のみ、APIリクエストは受理される。

[5]

• ステータスはステータス取得関数にて他機能のデータベースやストレージから取得される。

ブロック実現例

ブロック実現例 説明

[1]

• 本機能は、別機能における処理の中で公文書のダウンロードが必要になった場合に利用される想定である。

[2]

• ユーザーは他の機能ブロックにおいてユーザ認証を行い、認証トークンを取得する。

[3]

• 公文書はREST APIを通じてダウンロードされる。このAPIはAzure Functionsにより構築される。
• サーバレスによるメリット（スケーラビリティの確保が容易、リクエストがない場合は料金発生なし等）を重視してAzure Functionsを採用している。

[4]

• APIリクエストの認可は認証系の機能ブロックにより発行されるトークンを検証することによって行われる。
• トークンが有効な場合のみ、APIリクエストは受理される。

[5]

• リクエストが認可された場合は、公文書取得関数がAzure Storage Accountから公文書を取得する。

[6]

• 他の機能ブロックが、公文書保管ストレージに公文書をアップロードする。

ブロック実現例

ブロック実現例 説明

[1]

• 本機能は、別機能における処理の中で公文書のダウンロードが必要になった場合に利用される想定である。

[2]

• ユーザーは他の機能ブロックにおいてユーザ認証を行い、認証トークンを取得する。

[3]

• 公文書のダウンロードURLはREST APIを通じて取得される。このAPIはAzure Functionsにより構築される。
• サーバレスによるメリット（スケーラビリティの確保が容易、リクエストがない場合は料金発生なし等）を重視してAzure Functionsを採用している。

[4]

• APIリクエストの認可は認証系の機能ブロックにより発行されるトークンを検証することによって行われる。
• トークンが有効な場合のみ、APIリクエストは受理される。

[5]

• リクエストが認可された場合は、Azure Functionsは対象のファイルに対してSAS（Shared Access Signature）キーを生成し、それを含むURLを返却する。
• SASキーは特定のファイルに対して期間と操作（作成・削除・変更）を限定してアクセス権を与えるためのキーである。

[6]

• クライアントはSASキー付きURLでAzure Storage Accountsから添付資料をダウンロードする。
• 本方式ではFunctionsを経由せず利用者とストレージ間で直接ファイルが送受されるため、比較的大容量なファイルなどにおいてもAPIサーバの負荷を高めることなくサービスを提供できる。

[7]

• 他の機能ブロックが、公文書保管ストレージに公文書をアップロードする。

ブロック実現例 （#サーバレスフロントエンド）

ブロック実現例 説明

[1]

• 公文書をファイル（PDF等）として、Azure Front Door及びAzure Storage Accountsで配信し、一般公開を行う。
• ファイルは高耐久なオブジェクトストレージであるAzure Storage Accountsに保管する。Azure Front DoorはCDNとしての機能を提供し、大量のリクエストにも低レイテンシーでの応答を実現する。
• またWAF(※)によりインターネット経由で行われる様々な攻撃からフロントエンド配信機能を保護する。
  
  ※WAFのルールグループについては非機能ブロック「セキュリティ_通信を介した攻撃への保護」を参照すること。
  [2]
• 公文書のファイルは、静的コンテンツの一部として公開される想定であり、コンテンツ管理_Webページ（静的コンテンツ）公開機能が提供するWebページに、公文書のファイルのダウンロード用URLが掲載される。
  [3]
• 連携機能が作成したファイル（PDF等）を公文書配信ストレージにアップロードする。
  [補足]
• 補足：時刻指定での公文書公開を行う要件がある場合は、Webコンテンツ管理（CMS）機能の利用が推奨される。

ブロック実現例 （#サーバレスフロントエンド）

ブロック実現例 説明

[1]

• 公文書をファイル（PDF等）として、Azure Front Door及びAzure Storage Accountsで配信し、一般公開を行う。
• ファイルは高耐久なオブジェクトストレージであるAzure Storage Accountsに保管する。Azure Front DoorはCDNとしての機能を提供し、大量のリクエストにも低レイテンシーでの応答を実現する。
• またWAF(※)によりインターネット経由で行われる様々な攻撃からフロントエンド配信機能を保護する。
  
  ※WAFのルールグループについては非機能ブロック「セキュリティ_通信を介した攻撃への保護」を参照すること。
  [2]
• 公文書のファイルは、静的コンテンツの一部として公開される想定であり、コンテンツ管理_Webページ（静的コンテンツ）公開機能が提供するWebページに、公文書のファイルのダウンロード用URLが掲載される。
  [3]
• 連携機能が作成したファイル（PDF等）を公文書配信ストレージにアップロードする。
  [補足]
• 補足：時刻指定での公文書公開を行う要件がある場合は、Webコンテンツ管理（CMS）機能の利用が推奨される。

ブロック実現例

ブロック実現例 説明

[1]

• 申請・届出機能等の他の機能ブロックにおいて、手数料の納付が必要になった場合、本機能へのリクエストが送信される。

[2]

• ユーザーは他の機能ブロックにおいてユーザー認証を行い、認証トークンを取得する。

[3]

• 手数料納付の入力データはREST APIで送信される。
• REST APIはAPI Management及びAzure Functionsにより構築される。
• またWAFによりインターネット経由で行われる様々な攻撃からAPIを保護する。

[4]

• APIリクエストの認可は認証系の機能ブロックにより発行されるトークンを検証することによって行われる。
• API ManagementはAuthorization ヘッダーで示される連携機能から取得されたアクセストークンを検証し、APIリクエストヘッダーに含まれるトークンの有効性を検証する。
• トークンが有効な場合のみ、APIリクエストは受理される。

[5]

• 手数料等の納付は、歳入金電子納付システム（REPS）と連携して行われる。REPSとの間で手数料の納付に関する情報を連携する。連携した情報をもとに、手数料納付ステータスを更新する。
  
  （注）REPSに関する技術情報（インタフェース仕様、連携のための手続きや制約事項等）は、別途確認する必要がある。

[6]

• 手数料の納付ステータスはデータベースに保存し管理を行う。データベースはマネージドなAzure SQL Databaseを利用し、運用コストを削減する。

ブロック実現例

ブロック実現例 説明

[1]

• 補助金等電子交付機能が実装されたフロントエンドの静的ファイルが配信される。
• フロントエンドへのアクセスはユーザ認証機能等の他の機能ブロックと連携してアクセス許可を行う。
• 承認者は配信されたフロントエンドを通してREST APIを利用して補助金等の交付を行う。

[2]

• 補助金交付の入力データはREST APIで送信される。
• REST APIの処理はAPI Management及びAzure Functions、データ領域はSQL Databaseによって構築される。
• 本機能は、ユーザ認証機能等の他の機能ブロックと連携してアクセス許可を行う。

[3]

• 補助金等の納付は、外部システムと連携して行われる。外部システムとの間で補助金の交付に関する情報を連携する。
• 連携した情報をもとに、補助金交付ステータスを更新する。
• (注)外部システムに関する技術情報(インタフェース仕様、連携のための手続きや制約事項等)は、別途確認する必要がある。

[4]

• 補助金の交付ステータスはデータベースに保存し管理を行う。
• データベースはマネージドなRDBであるSQL Databaseを利用し、運用コストを削減する。

ブロック実現例

ブロック実現例 説明

[1]

• 審査・承認_審査・承認機能等の他の機能ブロックにおいて、決裁ワークフローによる処理が必要になった場合、本機能へのリクエストが送信される。

[2]

• 決裁に関連する一連の処理を、Durable Functionsを用いてワークフローとして作成する。
• Durable Functionsでは、複数の機能ブロックを組み合わせたワークフローの作成が可能である。
• ワークフローの一例として、審査・承認の結果を帳票として作成及び交付し、利用者に通知する一連の処理を示している。Durable Functionsでは、各機能ブロックで使用するAzure Functions等を指定した順番で呼び出すワークフローの作成が可能である。

[3]

• ワークフローの構成要素して、条件分岐や並列処理、ループ処理などの、ワークフローの制御で必要になる処理があらかじめ用意されている。そのため、ワークフローの制御の部分をDurable Functionsの機能に任せることができる。
• また、Durable Functionsでは、外部イベントを用いて、ワークフローの実行を一時停止することができる。この機能を用いて、例えば、承認者の承認行為をワークフローの一部として構成することも可能である。

ブロック実現例

ブロック実現例 説明

[1]

• SPA（Single Page Application）における静的ファイル（HTML、JavaScript、CSS）をAzure Front Door及びAzure Storage Accountsで配信する。
• ファイルは高耐久なオブジェクトストレージであるAzure Storage Accountsに保管する。
• Azure Front DoorはCDNとしての機能を提供し、大量のリクエストにも低レイテンシーでの応答を実現する。
• WAFによりインターネット経由で行われる様々な攻撃からフロントエンド配信機能を保護する。

[2]

• ユーザーは他の機能ブロックにおいてユーザー認証を行い、認証トークンを取得する。

[3]

• 審査データの参照及び、結果入力はREST APIで行われる。
• REST APIはAPI Management 及びAzure Functionsにより構築される。
• WAFによりインターネット経由で行われる様々な攻撃からAPIを保護する。

[4]

• APIリクエストの認可は認証系の機能ブロックにより発行されるトークンを検証することによって行われる。
• API ManagementはAuthorization ヘッダーで示される連携機能から取得されたアクセストークンを検証し、APIリクエストヘッダーに含まれるトークンの有効性を検証する。
• トークンが有効な場合のみ、APIリクエストは受理される。

[5]

• 認可されたリクエストは、審査・承認処理関数にて処理される。
• 処理結果は審査データ保管データベース・ストレージに保存される。

[6]

• 審査結果は他の機能により参照される。

ブロック実現例

ブロック実現例 説明

[1]

• 審査データ保管データベースであるDataverseに審査・承認対象のデータが登録されたことをトリガーとしてPower Automateに登録された審査・承認通知フローが起動される。

[2]

• 審査・承認を行う職員に対してTeamsやメール等を通じて審査・承認リクエストが通知される。

[3]

• 審査・承認リクエストのURL等からPowerApps上に作られた審査・承認状況管理アプリを開く。
• Power Platformの利用は、GSSに問い合わせるか、利用組織による調達を想定するものとする。

[4]

• 必要に応じてユーザー認証機能（職員向け）などにより認証を行う。

[5]

• 審査・承認状況管理アプリで審査・承認を行うと、Dataverse上のデータが更新さ審査・承認のステップが進む。

ブロック実現例

ブロック実現例 説明

[1]

• SPA（Single Page Application）における静的ファイル（HTML、JavaScript、CSS）をAzure Front Door及びAzure Storage Accountsで配信する。
• ファイルは高耐久なオブジェクトストレージであるAzure Storage Accountsに保管する。
• Azure Front DoorはCDNとしての機能を提供し、大量のリクエストにも低レイテンシーでの応答を実現する。
• WAFによりインターネット経由で行われる様々な攻撃からフロントエンド配信機能を保護する。
  [2]
• ユーザーは他の機能ブロックにおいてユーザー認証を行い、認証トークンを取得する。
  [3]
• 審査データの参照及び、結果入力はREST APIで行われる。
• REST APIはAPI Management 及びAzure Functionsにより構築される。
• WAFによりインターネット経由で行われる様々な攻撃からAPIを保護する。
  [4]
• APIリクエストの認可は認証系の機能ブロックにより発行されるトークンを検証することによって行われる。
• API ManagementはAuthorization ヘッダーで示される連携機能から取得されたアクセストークンを検証し、APIリクエストヘッダーに含まれるトークンの有効性を検証する。
• トークンが有効な場合のみ、APIリクエストは受理される。
  [5]
• 過去の審査結果や審査基準等のドキュメント（以下、審査関連資料とする）を Azure AI Searchのインデックスとして事前に登録する。
• Azure AI Searchでは、キーワード検索、セマンティックランキング、ベクトル検索、及びこれらの組み合わせによる高度な検索が可能である。
• Azure AI Searchでは、Azure AI Document Intelligenceその他のAIサービスと連携した、より高度な情報抽出を基にしたインデックス化も可能である。
  [6]
• 認可されたリクエストは、審査・承認処理関数から、RAG（検索拡張生成）を構成したAzure OpenAI Service及びAzure AI Searchと連携して処理される。
• ユーザーからのリクエストを使用してAzure OpenAI ServiceがAzure AI Searchに対する検索文を生成する。
• Azure AI SearchはAzure OpenAI Serviceが生成した検索文から審査関連資料を検索し、審査関連資料内容を返信する。
• Azure OpenAI ServiceはAzure AI Searchから受信した審査関連資料内容に応じて回答を生成する。
  [7]
• 処理結果は審査データ保管データベース・ストレージに保存される。
  [8]
• 審査結果は他の機能により参照される。

ブロック実現例 （#サーバーレスデータ連携）

ブロック実現例 説明

[1]

• 本機能ブロックは他機能のデータストレージをデータソース対象とする。
• なお、レプリケーションを構成することにより（Azure SQL Databaseの場合はGeoレプリケーションもしくは読み取りスケールアウト、Azure Cosmos DB for MongoDBの場合はグローバル分散の構成）、読み取り処理と書き込み処理を分離して負荷低減をすることが可能である。

[2]

• データソースのデータはトリガーにより定期的に実行されるAzure Data Factoryのジョブにより抽出され、整形処理が行われた上で、処理済みデータ格納用ストレージへ保存される。

[3]

• 処理が完了したデータのストレージは、Azure SQL Database、Azure Synapse Analytics専用SQLプール、Azure Cosmos DB for MongoDB、Azure Storage Accountsが想定される。
• 構造化データの場合はAzure SQL DatabaseもしくはAzure Synapse Analytics専用SQLプールを、半構造化データの場合はAzure Cosmos DB for MongoDBを、柔軟なクエリの必要性が無い場合はAzure Storage Accountsがストレージとして推奨される。なお、Azure Storage Accounts（Blob Storage/ADLS Gen2）に保存されたデータはAzure Synapse AnalyticsサーバーレスSQLプールから読み取ることが可能である。

[4]

• 処理済みのデータはコンテンツ管理_Webページ（動的コンテンツ）公開機能やデータ管理_分析用ダッシュボード機能により利用者（職員）へアクセスが提供される。

ブロック実現例 （#サーバーレスデータ連携）

ブロック実現例 説明

[1]

• 本機能ブロックは他機能のデータストレージをデータソース対象とする。

[2]

• データソースのデータはストレージトリガーにより起動するAzure Functionsにより整形処理が行われた上で、処理済みデータ格納用ストレージへ保存される。

[3]

• 処理が完了したデータのストレージは、Azure SQL Database、Azure Synapse Analytics専用SQLプール、Azure Cosmos DB for MongoDB、Azure Storage Accountsが想定される。
• 構造化データの場合はAzure SQL DatabaseもしくはAzure Synapse Analytics専用SQLプールを、半構造化データの場合はAzure Cosmos DB for MongoDBを、柔軟なクエリの必要性が無い場合はAzure Storage Accountsがストレージとして推奨される。なお、Azure Storage Accounts（Blob Storage/ADLS Gen2）に保存されたデータはAzure Synapse AnalyticsサーバーレスSQLプールから読み取ることが可能である。

[4]

• 処理済みのデータはコンテンツ管理_Webページ（動的コンテンツ）公開機能やデータ管理_分析用ダッシュボード機能により利用者（職員）へアクセスが提供される。

ブロック実現例 （#サーバレスデータ連携）

ブロック実現例 説明

[1]

• 本機能ブロックは他機能のデータストレージをデータソース対象とする。

[2]

• データソースのデータは、ストレージトリガーにより起動するAzure Data Factoryのジョブにより抽出され、整形処理が行われた上で、処理済みデータ格納用ストレージへ保存される。

[3]

• 処理が完了したデータのストレージは、Azure SQL Database、Azure Synapse Analytics専用SQLプール、Azure Cosmos DB for MongoDB、Azure Storage Accountsが想定される。
• 構造化データの場合はAzure SQL DatabaseもしくはAzure Synapse Analytics専用SQLプールを、半構造化データの場合はAzure Cosmos DB for MongoDBを、柔軟なクエリの必要性が無い場合はAzure Storage Accountsがストレージとして推奨される。なお、Azure Storage Accounts（Blob Storage/ADLS Gen2）に保存されたデータはAzure Synapse AnalyticsサーバーレスSQLプールから読み取ることが可能である。

[4]

• 処理済みのデータはコンテンツ管理_Webページ（動的コンテンツ）公開機能やデータ管理_分析用ダッシュボード機能により利用者（職員）へアクセスが提供される。

ブロック実現例 （#ストリーム処理）

ブロック実現例 説明

[1]

• 本機能ブロックは他機能のデータストレージをデータソース対象とする。

[2]

• データソースのデータはAzure Cosmos DB for MongoDBの場合は変更フィード、Azure SQL Databaseの場合はSQL変更の追跡機能を利用し、ストリームのコンシューマへと差分データを連携する。
• SQL変更の追跡機能で差分連携する場合、Azure Functionsの従量課金プランでは自動スケールに未対応のため、データ変更の頻度やデータ量による負荷次第ではAzure FunctionsのPremiumまたは専用プランにアップグレードする、もしくはリアルタイム処理ではなく「パターン1 データーベースサービスとして利用」に変更するかを検討する。

[3]

• Azure Functionsを差分ストリームのコンシューマとして利用し、Event Hubsへ接続する。
• Event Hubs及びAzure Stream Analyticsはバッファとして機能し、Azure Stream Analyticsの組み込み関数及びユーザー定義関数を利用したデータ整形関数による個人情報マスキングやデータ形式変換などの処理も実現する。

[4]

• 処理済みのデータはDBまたはオブジェクトストレージへ保存される。
• 構造化データの場合はAzure SQL DatabaseもしくはAzure Synapse Analytics専用SQLプールを、半構造化データの場合はAzure Cosmos DB for MongoDBを、柔軟なクエリの必要性が無い場合はAzure Storage Accountsがストレージとして推奨される。

[5]

• 処理済みのデータはデータへのアクセスを提供する他の機能ブロックにより利用される。
  補足：差分ストリームの連携から格納までの処理においては最低１回の送信保証になるため、処理済みのデータの格納前もしくは格納後に重複データのチェック及び削除を行う等の実装が必要である。

ブロック実現例 （#サーバーレスバックエンド #サーバーレスデータ連携）

ブロック実現例 説明

[1]

• この機能は、他の機能により提供されるフロントエンドアプリからアクセスされることを想定する。
• またコンテンツの配信を担う他の機能ブロックによりWebフォームをユーザへ配信する。

[2]

• Webフォームへの入力データはREST APIで送信される。
• REST APIはAPI Management及びAzure Functionsにより構成する。

[3]

• Webフォームへの入力データはWebフォーム内容処理関数により内容のチェックを行う。
• 内容に問題がない場合には、JSON形式にてAzure Cosmos DBへ保管する。

[4]

• Azure Cosmos DBに蓄積されたデータのうち、差分データのみを年次や月次等の低頻度で収集し静止断面を確保する場合には、Azure Data Factoryを利用して、Azure Cosmos DBに蓄積されたデータのうち、差分データのみを同一フォーマットでAzure Storage Accountsへ一定期間ごとに収集する。
• また、Azure Data Factoryによる差分データの収集では、コンテナ単位ないしはドキュメント単位で収集することが可能である。

[5]

• 他の機能ブロックはWebフォームへの入力データを参照し分析等に利用することができる。

ブロック実現例 （#サーバーレスバックエンド）

ブロック実現例 説明

[1]

• この機能は、他の機能により提供されるフロントエンドアプリからアクセスされることを想定する。
• またコンテンツの配信を担う他の機能ブロックによりWebフォームをユーザへ配信する。

[2]

• Webフォームへの入力データはREST APIで送信される。
• REST APIはAPI Management及びAzure Functionsにより構成する。

[3]

• Webフォームへの入力データはWebフォーム内容処理関数により内容のチェックを行う。
• 内容に問題がない場合には、JSON形式にてAzure Cosmos DBへ保管する。

[4]

• Azure Functionsを使用し、Azure Cosmos DBの変更フィードから連携された変更内容をAzure Storage Accountsへ同一フォーマットで同期する。
• ただし、Azure Functionsが重複した変更内容を受け取る場合が想定されるため、Azure FunctionsにおいてAzure Storage Accountsへ収集済みのデータを確認した上で書き込む等の実装が必要である。

[5]

• 他の機能ブロックはWebフォームへの入力データを参照し分析等に利用することができる。

ブロック実現例 （#サーバレスバックエンド #サーバレスデータ連携 #サーバレスイベント処理）

ブロック実現例 説明

[1]

• 外部システムは、この機能が提供するREST APIの呼び出しに必要なトークンを連携機能を用いて取得する。

[2]

• 外部システムを起点とするデータ収集を行う場合、この機能が提供するREST APIを外部システムが呼び出す。REST APIはAPI Management及びAzure Functionsにより構成する。

[3]

• 収集したデータはデータ登録処理関数により内容のチェックを行う。
• 内容に問題がない場合には、JSON形式にてAzure Cosmos DBへ保管する。

[4]

• Azure Cosmos DBに蓄積されたデータのうち、差分データのみを年次や月次等の低頻度で収集し静止断面を確保する場合には、Azure Data Factoryを利用して、Azure Cosmos DBに蓄積されたデータのうち、差分データのみを同一フォーマットでAzure Storage Accountsへ一定期間ごとに収集する。
• また、Azure Data Factoryによる差分データの収集では、コンテナ単位ないしはドキュメント単位で収集することが可能である。

[5]

• この機能を起点とするデータ収集を行う場合、外部システムが提供するREST APIをこの機能が呼び出す。外部システムのREST APIの呼び出しは、Logic Appsを用いて定期的にAzure Functionsを実行することで実現する。 外部システムから取得するデータはJSON形式であると想定し、保管先はAzure Storage AccountsまたはAzure Cosmos DBが考えられる。

[6]

• 他の機能ブロックは収集したデータを参照し分析等に利用することができる。

ブロック実現例 （#サーバーレスバックエンド #サーバーレスイベント処理）

ブロック実現例 説明

[1]

• 外部システムは、この機能が提供するREST APIの呼び出しに必要なトークンを連携機能を用いて取得する。

[2]

• 外部システムを起点とするデータ収集を行う場合、この機能が提供するREST APIを外部システムが呼び出す。REST APIはAPI Management及びAzure Functionsにより構成する。

[3]

• 収集したデータはデータ登録処理関数により内容のチェックを行う。
• 内容に問題がない場合には、JSON形式にてAzure Cosmos DBへ保管する。

[4]

• Azure Functionsを使用し、Azure Cosmos DBの変更フィードから連携された変更内容をAzure Storage Accountsへ同一フォーマットで同期する。
• ただし、Azure Functionsが重複した変更内容を受け取る場合が想定されるため、Azure FunctionsにおいてAzure Storage Accountsへ収集済みのデータを確認した上で書き込む等の実装が必要である。

[5]

• この機能を起点とするデータ収集を行う場合、外部システムが提供するREST APIをこの機能が呼び出す。外部システムのREST APIの呼び出しは、Logic Appsを用いて定期的にAzure Functionsを実行することで実現する。 外部システムから取得するデータはJSON形式であると想定し、保管先はAzure Storage AccountsまたはAzure Cosmos DBが考えられる。

[6]

• 他の機能ブロックは収集したデータを参照し分析等に利用することができる。

ブロック実現例

ブロック実現例 説明

[1]

• Azure Data Factoryを利用して、SaaSアプリケーションからのデータ取得を行う。Azure Data Factoryは、Salesforce、SAP、などのSaaSアプリケーションに対するコネクタを提供している。Azure Data Factoryを利用し、SaaSアプリケーション上のデータをAzure Storage Accountsの収集データ蓄積ストレージに保管する。Azure Data Factoryでは、データの転送において、対象データの絞り込みやデータの変換も可能である。

[2]

• 他の機能ブロックは収集したデータを参照し分析等に利用することができる。
  補足：本機能ブロックを利用する際には、Azure Data Factoryのサポート状況を事前に確認することが推奨される。収集対象とするSaaSそのものに対するサポートがあるか、また、SaaSの中でも収集対象とするデータに対するサポートがあるか、等の確認を行うことが推奨される。また、収集対象とするSaaSによってはLogic Appsも対象サービスとなりえる。

ブロック実現例 （#サーバレスバックエンド #サーバレスイベント処理）

ブロック実現例 説明

[1]

• この機能は、他の機能により提供されるフロントエンドアプリからアクセスされることを想定する。
• またコンテンツの配信を担う他の機能ブロックによりWebフォームをユーザへ配信する。

[2]

• 入力ファイルはREST APIで送信される。REST APIはAPI Management及びAzure Functionsにより構成する。

[3]

• 入力ファイル処理関数によりデータおよびファイルの形式チェックを行う。
• 内容に問題がない場合はAzure Storage Accountsに保管される。ファイル保管によるイベントによりAzure Functionsをトリガーする。

[4]

• Azure Functionsのみで高精度な日本語に関するOCR処理は実現が困難のため、イベントによりトリガーされたAzure Functionsにより保管されたファイルを取得し、Document Intelligenceへ連携しOCR処理を実施する。

[5]

• OCR処理により抽出したメタデータ及び文字列データを他の機能が保持しているAzure AI Searchにてインデックス化する。

[6]

• 他の機能ブロックはOCR処理により抽出したメタデータ・文字列データに対して検索等実施することができる。

ブロック実現例

ブロック実現例 説明

[1]

• データ収集及び管理等を担う機能ブロックにより生成・蓄積されたデータを参照する。

[2]

• Fabric Data Factoryを使用し可視化に必要な事前処理を必要に応じて実施する。
• 事前処理後のデータはOneLakeへ保管し、メタデータは可視化対象データ メタデータカタログ機能により自動的にカタログ化が行われる。

[3]

• Power BIを用いて可視化対象データを可視化する。
• Power Platformの利用は、GSSに問い合わせるか、利用組織による調達を想定するものとする。

[4]

• 分析者はPower BIで可視化したデータへアクセスし、分析することが可能である。
• また単一ないしは複数のビジュアルを組み合わせて分析結果を作成し、ダッシュボードとして公開することが可能である。なお、ダッシュボードはPDFファイルとして出力することも可能である。

[5]

• 分析者が作成したダッシュボードは分析結果の公開を担う機能ブロックにより参照される。

ブロック実現例

ブロック実現例 説明

[1]

• データ収集及び管理等を担う機能ブロックにより生成・蓄積されたデータを参照する。​ミラーリングとショートカット機能により外部クラウドや各種データベース上のデータをシームレスに連携可能。

[2]

• 統計処理に必要な事前処理を実施する。基本的にはFabric Data Factoryを利用し、大規模な場合にはAzure Data Factory、リアルタイム性を求められる場合にはReal-Time Analyticsを利用する。
• Microsoft Fabricの利用は、GSSに問い合わせるか、利用組織による調達を想定するものとする。

[3]

• 加工・ロード済みのデータを統計処理対象データ保存ストレージであるOneLake上に保管する。保管されたデータは統計処理対象データ メタデータカタログ機能により自動的にカタログ化が行われる。

[4]

• OneLakeに保管されたデータをFabric Data Engineering（PythonとSparkによるパイプライン処理）やFabric Warehouse（SQLによる集計処理） といった統計処理エンジンにより統計処理を行う。Fabric WarehouseはOneLake上のデータを直接扱うことができ、統計処理後のデータについてもそのままOneLake上に保存される。

[5]

• 分析者はFabricのGUI （ブラウザでアクセス）やVisual Studio Codeの拡張機能、クエリエディタを利用して分析する

[6]

• 他の機能ブロックはAzure Data Lake Storage Gen2へ保存された統計処理後のデータをそのまま参照したり、Fabric Warehouse 統計処理データ保管論理データウェアハウス・処理エンジンのSQLインタフェースを介して統計処理後のデータを参照し、可視化等に利用することが可能である。

ブロック実現例

ブロック実現例 説明

[1]

• データ収集及び管理等を担う機能ブロックにより生成・蓄積されたデータを参照する。​

[2]

• Azure Synapse Pipelinesを使用し統計処理に必要な事前処理を実施する。
• 事前処理後のデータはAzure Data Lake Storage Gen2へ保管する。

[3]

• Azure Synapse Pipelinesを使用し、事前処理後のデータをAzure Synapse Analyticsへロードする。
• Synapse pipelineではSparkプールやDataflow （GUI）を利用してデータ加工ジョブを定義する。加工後のデータは統計処理データ保管データベースであるAzure Synapse専用SQLプールや統計処理後データ保存ストレージであるAzure Data Lake Storage Gen2へ格納する。

[4]

• 分析者はストレージ上のデータに対してサーバーレスSQLプールを利用してSQLでの分析や、Sparkプールを利用してPythonでの分析を行う。
• また、専用SQLプールに格納されたデータに対してはAzure Data StudioやSQL Server Management Studioなどのクエリエディタから分析を行う。

[5]

• 他の機能ブロックはAzure Data Lake Storage Gen2等に保存された統計処理後のデータを参照し、可視化等に利用することが可能である。
• アクセス方法としては分析用ダッシューボードなどからAzure Storageへアクセス、直接Synapse 専用SQLプールに接続して最新の情報取得、SynapseサーバーレスSQLプールへの接続などの方法がある。

ブロック実現例

ブロック実現例 説明

[1]

• データ収集及び管理等を担う機能ブロックにより生成・蓄積されたデータを参照する。​

[2]

• Azure Data Factoryを利用してデータの事前処理を行い、Azure Data Lake Storage Gen2にDelta format形式で格納する。
• リアルタイム処理の場合はAzure IoT HubやAzure Event Hubを利用する。

[3]

• Azure Data Factoryではストレージとコンピュートエンジンの分離が行われているため、加工・ロード済みデータはすべてAzure Data Lake Storage Gen2に格納される。
• Azure Data Lake Storage Gen2上のデータに対してNotebooksでSparkを利用した分析や、Databricks SQLを利用してSQLを利用しての分析・レポート作成を行う。処理後のデータについてもそのままAzure Data Lake Storage Gen2上に保管される。

[4]

• 分析者はブラウザからDatabricksワークスペースの画面にアクセスして分析を行う。

[5]

• 他の機能ブロックはAzure Data Lake Storage Gen2へ保存された統計処理後のデータをそのまま参照したり、Databricksの提供するSQLインタフェースを介してデータにアクセスし、可視化等に利用することが可能である。また、Delta sharingを活用してサードパーティーツールと接続も可能。

ブロック実現例

ブロック実現例 説明

[1]

• この機能は、他の機能により提供されるフロントエンドアプリからアクセスされることを想定する。
• またコンテンツを配信を担う他の機能ブロックにより統計情報を静的ファイル（CSVファイル、エクセル等）としてユーザーへ配信する。

[2]

• 統計処理結果のファイルは、他の機能ブロックによって生成され、統計情報配信ストレージに格納される。

ブロック実現例

ブロック実現例 説明

[1]

• この機能は、他の機能により提供されるフロントエンドアプリからアクセスされることを想定する。

[2]

• ユーザーは他の機能ブロックにおいてユーザー認証を行い、認証トークンを取得する。

[3]

• 全文検索の結果はREST APIとして提供される。REST APIはAPI Management 及びAzure Functionsにより構築される。
• またWAFはインターネット経由で行われる様々な攻撃からAPIを保護する。

[4]

• APIリクエストの認可は認証系の機能ブロックにより発行されるトークンを検証することによって行われる。
• API ManagementはAuthorization ヘッダーで示される連携機能から取得されたアクセストークンを検証し、APIリクエストヘッダーに含まれるトークンの有効性を検証する。
• トークンが有効な場合のみ、APIリクエストは受理される。

[5]

• 認可されたリクエストは、全文検索処理関数にて処理される。
• この関数はAzure AI Searchで全文検索を行い結果をユーザーへ返却する。
• Azure AI Searchでは、キーワード検索、セマンティックランキング、ベクトル検索、及びこれらの組み合わせによる高度な検索が可能である。
• Azure AI Searchでは、Azure AI Document Intelligenceその他のAIサービスと連携した、より高度な情報抽出を基にしたインデックス化も可能である。

[6]

• Azure AI SearchへはAzure Functionsを利用し差分データを取り込む。
• Azure Functionsのタイマートリガー機能を用いて一定間隔で実行される。
  
  ※Azure Functionsの実行上限（例: 従量課金プランでは5分）などを超える処理の場合にはDurable FunctionsまたはLogic Appsを選択する。

[7]

• 全文検索の対象となるデータは他の機能により生成される。
• データはAzure Storage AccountsやAzure SQL Databaseに保管されていると想定する。

ブロック実現例

ブロック実現例 説明

[1]

• この機能は、他の機能により提供されるフロントエンドアプリからアクセスされることを想定する。

[2]

• ユーザーは他の機能ブロックにおいてユーザー認証を行い、認証トークンを取得する。

[3]

• 全文検索の結果はREST APIとして提供される。REST APIはAPI Management 及びAzure Functionsにより構築される。
• またWAFはインターネット経由で行われる様々な攻撃からAPIを保護する。

[4]

• APIリクエストの認可は認証系の機能ブロックにより発行されるトークンを検証することによって行われる。
• API ManagementはAuthorization ヘッダーで示される連携機能から取得されたアクセストークンを検証し、APIリクエストヘッダーに含まれるトークンの有効性を検証する。
• トークンが有効な場合のみ、APIリクエストは受理される。

[5]

• 認可されたリクエストは、検索処理関数から、RAG（検索拡張生成）を構成したAzure OpenAI Service及びAzure AI Searchと連携して処理される。
• ユーザーからのリクエストを使用してAzure OpenAI ServiceがAzure AI Searchに対する検索文を生成する。
• Azure AI SearchはAzure OpenAI Serviceが生成した検索文から全文検索を行い検索結果を返信する。
• Azure OpenAI ServiceはAzure AI Searchから受信した検索結果内容に応じて回答を生成する。
• Azure AI Searchでは、キーワード検索、セマンティックランキング、ベクトル検索、及びこれらの組み合わせによる高度な検索が可能である。
• Azure AI Searchでは、Azure AI Document Intelligenceその他のAIサービスと連携した、より高度な情報抽出を基にしたインデックス化も可能である。
• Azure AI SearchとAzure OpenAI Serviceを組み合わせることで、検索文の文脈や意図をより深く理解した検索が可能になる。

[6]

• Azure AI SearchへはAzure Functionsを利用し差分データを取り込む。
• Azure Functionsのタイマートリガー機能を用いて一定間隔で実行される。
  
  ※Azure Functionsの実行上限（例: 従量課金プランでは5分）などを超える処理の場合にはDurable FunctionsまたはLogic Appsを選択する。

[7]

• 全文検索の対象となるデータは他の機能により生成される。
• データはAzure Storage AccountsやAzure SQL Databaseに保管されていると想定する。

ブロック実現例

ブロック実現例 説明

[1]

• MQTT、MQTT over WebSockets、AMQP、AMQP over WebSockets又はHTTPS通信が利用可能である観測機器をAzure IoT Hubへ接続し管理する。
• Azure IoT HubはMQTT v3.1.1に対しては制限付き機能サポート、MQTT v5に対しては制限付き機能サポートかつプレビューステータスのため、Azure IoT
  HubがサポートしてないMQTT v3.1.1の機能もしくはMQTT v5を使用する要件に対してはEvent GridのMQTTブローカー機能の利用を検討する。
• Azure IoT Hubは観測機器が提示する共有アクセス署名トークン又はクライアント証明書によるデバイス認証や、IoTデバイスのモニタリング等を行う。

[2]

• 観測機器とAzureクラウドの通信が不安定な場合や、デバイス間通信を実現する場合はAzure IoT Edgeをインストールしたエッジデバイスを利用する。
• クラウドとの切断時にはクラウド方向のすべてのメッセージを格納し、接続が復元されると再配信が行われる。
• Azure IoT Edgeモジュールによりビジネスロジックをエッジデバイス側に展開、管理することも実現可能である。

[3]

• 観測値はAzure IoT Hubから、連携機能のパイプラインへ送信される。

ブロック実現例

ブロック実現例 説明

[1]

• 計測機器やアプリケーション等のストリーミングデータにおけるデータソース及びプロデューサが存在することを想定する。
• Azure外部にデータソース及びプロデューサが存在していること前提とした構成図となるが、Azure内部に存在することも想定される。

[2]

• イベントデータなどのストリーミングデータは Azure Event Hubs から、IoT デバイスからのデータは Azure IoT Hub から収集し、Real-Time Analytics へ連携する。

[3]

• Real-Time Analytics によりストリーミングデータに対してリアルタイムで取り込み、変換処理を実施する。
• 出力先を Fabric KQL データベースまたは OneLakeとして連携する。
• Fabric KQL データベースへ出力されたデータを分析することができる。
• Microsoft Fabricの利用は、GSSに問い合わせるか、利用組織による調達を想定するものとする。

[4]

• リアルタイムでの分析が不要な場合にはデータの変更なしに Real-Time Analytics から OneLakeへ出力し、保管する。
• データはメタデータカタログ機能により自動的にカタログ化が行われる。

[5]

• 他の機能ブロックはOneLakeへ保存されたストリーミングデータを参照し、分析等に利用することが可能である。

ブロック実現例

ブロック実現例 説明

[1]

• 計測機器やアプリケーション等のストリーミングデータにおけるデータソース及びプロデューサが存在することを想定する。
• Azure外部にデータソース及びプロデューサが存在していること前提とした構成図となるが、Azure内部に存在することも想定される。

[2]

• イベントデータなどのストリーミングデータは Azure Event Hubs から、IoT デバイスからのデータは Azure IoT Hub から収集し、Azure Data Explorer へ連携する。

[3]

• Azure Data Explorer によりストリーミングデータをリアルタイムで取り込み、変換処理を実施する。
• Azure Data Explorer に取り込まれたデータに対して、時系列分析や異常検知などの分析を準リアルタイムで実現することができる。

[4]

• Azure Data Explorer に取り込まれたデータの保管先として、Azure Data Lake Storage Gen2 を連携する。
• Azure Data Lake Storage Gen2 を外部テーブルとして、Azure Data Explorer に事前に取り込まずに分析及びクエリを実行することができる。

[5]

• リアルタイムでの分析が不要な場合にはデータの変更なしに Azure Event Hubs または Azure IoT Hub から Azure Data Lake Storage Gen2 へ出力し、保管する。

[6]

• 他の機能ブロックは Azure Data Lake Storage Gen2 へ保存されたストリーミングデータを参照し、分析等に利用することが可能である。

ブロック実現例

ブロック実現例 説明

[1]

• 申請・届出_申請・届出機能等の他の機能ブロックが、通知送信のリクエストを送信する。
• 通知送信は、疎結合な非同期処理として、Azure Service Busをメッセージキューとして利用する。

[2]

• メッセージキュー（Azure Service Bus）へ通知送信のリクエストが送信されたことを契機として、Azure Functionsが自動的に起動する。
• Azure Functionsはプログラムの実行環境をサーバレスで提供するものであり、通知送信処理の実行環境を容易に構築可能である。
• Azure Functions内の処理で、通知メールの本文等のコンテンツを作成し、Azure Communication Servicesへ通知メール送信をリクエストする。

[3]

• 利用者への通知メール送信には、マネージドサービスであるAzure Communication Servicesを利用する。
• Azure Communication Servicesを利用することにより、自前でのメールサーバ構築が不要となる。

ブロック実現例

ブロック実現例 説明

[1]

• 申請・届出_申請・届出機能等の他の機能ブロックが、通知送信のリクエストを送信する。
• 通知送信は、疎結合な非同期処理として、Azure Service Busをメッセージキューとして利用する。

[2]

• メッセージキュー（Azure Service Bus）へ通知送信のリクエストが送信されたことを契機として、Azure Functionsが自動的に起動する。
• Azure Functionsはプログラムの実行環境をサーバレスで提供するものであり、通知送信処理の実行環境を容易に構築可能である。
• Azure Functions内の処理で、プッシュ通知の本文等のコンテンツを作成し、Azure Notification Hubsへプッシュ通知送信をリクエストする。

[3]

• 利用者へのプッシュ通知送信には、マネージドサービスであるAzure Notification Hubsを利用する。
• Azure Notification Hubsを利用して、利用者への個別の通知の送信が可能である。

ブロック実現例

ブロック実現例 説明

[1]

• 申請・届出_申請・届出機能等の他の機能ブロックが、通知送信のリクエストを送信する。
• 通知送信は、疎結合な非同期処理とし、Azure Service Busをメッセージキューとして利用する。
  [2]
• メッセージキュー（Azure Service Bus）へ通知送信のリクエストが送信されたことを契機として、Azure Functionsが自動的に起動する。
• Azure Functionsはプログラムの実行環境をサーバレスで提供するものであり、通知送信処理の実行環境を容易に構築可能である。
• Azure Functions内の処理で、プッシュ通知のタイトルや本文等のコンテンツを作成し、Azure Notification Hubsへプッシュ通知の送信をリクエストする。
  [3]
• 利用者のモバイル端末へのプッシュ通知の送信には、マネージドサービスであるAzure Notification Hubsを利用する。
• Azure Notification Hubsを利用して、利用者への個別のプッシュ通知の送信が可能である。
• Azure Notification Hubsは、Android向けのFirebase Cloud Messaging （FCM）や、iOS向けのApple プッシュ通知サービス （APNS）などのプッシュ通知サービスをサポートしている。
• なお、FCMやAPNS等のプッシュ通知サービスの利用のためには、プッシュ通知サービス側での認証情報の設定が必要である。

ブロック実現例

ブロック実現例 説明

[1]

• 申請・届出_申請・届出機能等の他の機能ブロックが、通知送信のリクエストを送信する。
• 通知送信は、疎結合な非同期処理とし、Azure Service Busをメッセージキューとして利用する。
  [2]
• メッセージキュー（Azure Service Bus）へ通知送信のリクエストが送信されたことを契機として、Azure Functionsが自動的に起動する。
• Azure Functionsはプログラムの実行環境をサーバレスで提供するものであり、通知送信処理の実行環境を容易に構築可能である。
• Azure Functions内の処理で、通知メールの本文等のコンテンツを作成し、Azure Communication Servicesへ通知メール送信をリクエストする。
  [3]
• 利用者への通知メール送信には、マネージドサービスであるAzure Communication Servicesを利用する。
• Azure Communication Servicesを利用することにより、自前でのメールサーバ構築が不要となる。

ブロック実現例

ブロック実現例 説明

[1]

• 申請・届出_申請・届出機能等の他の機能ブロックが、通知送信のリクエストを送信する。
• 通知送信は、疎結合な非同期処理として、Azure Service Busをメッセージキューとして利用する。
  [2]
• メッセージキュー（Azure Service Bus）へ通知送信のリクエストが送信されたことを契機として、Azure Functionsが自動的に起動する。
• Azure Functionsはプログラムの実行環境をサーバレスで提供するものであり、通知送信処理の実行環境を容易に構築可能である。
• Azure Functions内の処理で、プッシュ通知の本文等のコンテンツを作成し、Azure Notification Hubsへプッシュ通知送信をリクエストする。
  [3]
• 利用者へのプッシュ通知送信には、マネージドサービスであるAzure Notification Hubsを利用する。
• Azure Notification Hubsを利用して、利用者への個別の通知の送信が可能である。

ブロック実現例

ブロック実現例 説明

[1]

• 通知の一斉送信は、アラートの発報が必要なイベントの発生に合わせて自動化することが可能である。
• 連携機能がトリガーとなり、通知送信用キューに、通知の送信リクエストを送信する。
• 通知送信は、疎結合な非同期処理とし、Azure Service Busをメッセージキューとして利用する。
  [2]
• メッセージキュー（Azure Service Bus）へ通知送信のリクエストが送信されたことを契機として、Azure Functionsが自動的に起動する。
• Azure Functionsはプログラムの実行環境をサーバレスで提供するものであり、通知送信処理の実行環境を容易に構築可能である。
• Azure Functions内の処理で、通知の本文等のコンテンツを作成し、Azure Notification Hubsへ通知送信をリクエストする。

[3]

• 利用者へのプッシュ通知送信には、マネージドサービスであるAzure Notification Hubsを利用する。
• Azure Notification Hubsを利用して、利用者への通知の送信が可能である。
  [4]
• 通知の一斉送信は、運用者が手動で実行することが可能である。一斉送信に関する管理機能は連携機能により提供される。
• 連携機能において、一斉送信の宛先となるユーザを抽出し、抽出結果をAzure Cosmos DBに保存する。
• 連携機能を通じて、運用者が通知の内容や通知のタイミングなどに関するデータを入力する。入力されたデータに基づき、Azure Notification Hubsへ通知送信をリクエストする。

ブロック実現例

ブロック実現例 説明

[1]

• 静的ファイル（HTML、JavaScript、CSS）をAzure Front Door及びAzure Storage Accountsで配信する。
• ファイルは高耐久なオブジェクトストレージであるAzure Storage Accountsに保管する。
• Azure Front DoorはCDNとしての機能を提供し、大量のリクエストにも低レイテンシーでの応答を実現する。
• WAFによりインターネット経由で行われる様々な攻撃からコンテンツ管理_Webページ（静的コンテンツ）公開機能を保護する。

[2]

• 配信された静的コンテンツは他の機能とAPIを通じて連携する。

[注]

• 時刻指定でのWebサイト更新などをマネジメントコンソール外から行う要件がある場合は、Webコンテンツ管理（CMS）機能の利用が推奨される。

ブロック実現例

ブロック実現例 説明

[1]

• 本機能はコンテンツ管理を行うヘッドレスCMS部分と、そこから取得した情報を表示するためのフロントエンド配信部であるAzure Static Web Appsから構成される。

[2]

• Webサイトの閲覧者は静的コンテンツをAzure Static Web Appsから取得する。

[3]

• Azure Static Web Appsから取得されたクライアントサイトはヘッドレスCMSからコンテンツを取得しクライアントサイドレンダリング(CSR)を行う。
• またはAzure Static Web AppsのAPIを経由してヘッドレスCMSからコンテンツを取得し、クライアントサイドレンダリング(CSR)を行う。

[4]

• フロントエンド開発者が変更を加える場合は、GitHub等のコードレポジトリでの変更イベントをトリガーとし、GitHub Actions等によるビルド及びデプロイプロセスを開始する。

[5]

• コンテンツの配信及び職員によるコンテンツの編集は外部のヘッドレスCMSサービスで行う。

ブロック実現例

ブロック実現例 説明

[1]

• 本機能はコンテンツ管理を行うヘッドレスCMS部分と、そこから取得した情報を表示するためのフロントエンド配信部であるAzure Static Web Appsから構成される。

[2]

• Webサイトの閲覧者は静的コンテンツをAzure Static Web Appsから取得する。

[3]

• フロントエンド開発者が変更を加える場合は、GitHub等のコードレポジトリでの変更イベントをトリガーとし、GitHub Actions等によるビルド及びデプロイプロセスを開始する。

[4]

• GitHub Actions等によるビルド及びデプロイプロセスはビルド実行中にヘッドレスCMSからコンテンツを取得しコンテンツを埋め込んだ状態で静的サイトを生成する。

[5]

• コンテンツの配信及び職員によるコンテンツの編集は外部のヘッドレスCMSサービスで行う。

ブロック実現例

ブロック実現例 説明

[1]

• 本機能はWordPressをマネージドで提供するWordPress on App Serviceで構築・運用する。

[2]

• Webサイトの閲覧者はコンテンツをWordPressがホストされたWeb Appsから取得する。

[3]

• コンテンツの配信及び職員によるコンテンツの編集はWordPressの管理画面から行う。

[4]

• WordPress on App Serviceをデプロイするとコンテンツ管理用のAzure Database for MySQLが自動的にデプロイされ、コンテンツの保存先となる。

[注]

• 　WordPress サイトの作成open_in_newOpens in new tab

ブロック実現例

ブロック実現例 説明

[1]

• ユーザーがお問い合わせ内容を入力するフォームは静的コンテンツとして配信される。

[2]

• フォームの入力内容はAPI Management構築されたバックエンドAPIで受け付けられる。
• この際にAPI Managementの各種ポリシーによってリクエストのバリデーションや認証を行うことができる。

[3]

• APIのバックエンド処理を担うAzure Functionsは、問い合わせ内容をメールとしてAzure Communication Servicesから管理者へ送信する。
• この際にバックアップや分析を目的として問い合わせ内容をストレージへ保管する場合には、Azure Functionsを使用してAzure Storageや各種DBサービスへ保管する。

[4]

• 職員は受信したメールに対しての回答を個別に返信する。

ブロック実現例

ブロック実現例 説明

[1]

• SPA（Single Page Application）における静的ファイル（HTML、JavaScript、CSS）をAzure Front Door及びAzure Storage Accountsで配信する。
• ファイルは高耐久なオブジェクトストレージであるAzure Storage Accountsに保管する。Azure Front DoorはCDNとしての機能を提供し、大量のリクエストにも低レイテンシーでの応答を実現する。
• またWAFによりインターネット経由で行われる様々な攻撃からフロントエンド配信機能を保護する。

[2]

• ユーザーは他の機能ブロックにおいてユーザー認証を行い、認証トークンを取得する。

[3]

• フロントエンドで入力された問い合わせ文はREST形式のAPIリクエストとしてバックエンドAPIに送信される。
• バックエンドAPIはWAFによりインターネット経由で行われる様々な攻撃からAPIを保護されている。

[4]

• APIリクエストの認可は認証系の機能ブロックにより発行されるトークンを検証することによって行われる。
• API ManagementはAuthorization ヘッダーで示される連携機能から取得されたアクセストークンを検証し、APIリクエストヘッダーに含まれるトークンの有効性を検証する。
• トークンが有効な場合のみ、APIリクエストは受理される。また、必要に応じてリクエストやレスポンスのログ取得などもここで行われる。

[5]

• API Managementで認証やロギングなどの前処理が行われたリクエストはApp Service上で稼働しているバックエンドAPIサーバーにフォワードされる。ここから利用者からの問い合わせに応答するために以下のような処理が開始される。

[6]

• まず、バックエンドAPIサーバーは問い合わせ内容に合った検索文クエリを文書生成AIサービスにリクエストし、検索クエリを取得する。

[7]

• 次に、バックエンドAPIサーバーは取得した検索クエリを用いてドキュメント検索を行う。ドキュメントはあらかじめ参照ドキュメント保管ストレージにチャンク化され保存され、インデックスが作成されているものとする。
• ドキュメント検索はセマンティックランクやベクトル検索などによりクエリに対応する可能性の高いドキュメントURLをランキング形式で返却する。

[8]

• バックエンドAPIサーバーはドキュメント検索結果から取得されたドキュメントを取得する。

[9]

• バックエンドAPIサーバーは取得したドキュメントと利用者からの問い合わせ文を合わせて文書生成AIサービスにリクエストを送る。本構成を取り、文書生成AIサービスが問い合わせ文と回答の手掛かりとなるドキュメント内容がそろったリクエストを受け取ることで適切な回答を返すことができる可能性を高めることができる

ブロック実現例

ブロック実現例 説明

[1]

• 外部システムは外部連携_システム間認証機能により認証が行われトークンが発行される。

[2]

• 受信したリクエストに含まれるトークンを検証することにより、リクエストを認可する。

[3]

• ポリシーによって流量制限やロギングなどのポリシー適用が行われる。
• API ManagementはリクエストされたAPIを検証し、ポリシーを適用後にバックエンドAPIにりクエストをフォワードする。

ブロック実現例

ブロック実現例 説明

[1]

• 本機能は他の機能が出力するデータをもとに郵送書類を作成する。

[2]

• 他機能はAzure Functionsを起動することで、郵送書類の生成を開始する。
• Azure Functionsはペイロードデータをもとに必要な書類をPDFなどの形式で出力する。
• 書類はAzure Storage Accountsへアップロードされる。
  ※Azure Storage Accountsで共有アクセス署名（SAS）を有効にすること。

[3]

• Azure Storage Accountsのアップロードイベントを元に署名付きURLがAzure Functionsで発行される。
• Azure FunctionsからAzure Communication Servicesで利用者へEメールが送信される。

[4]

• 利用者はAzure Storage Accountsからファイルをダウンロードし、印刷する。

ブロック実現例

ブロック実現例 説明

[1]

• 申請・届出_申請・届出機能等の他の機能ブロックが、帳票作成のリクエストを送信する。
• 帳票作成は、疎結合な非同期処理とし、Azure Service Busをメッセージキューとして利用する。

[2]

• メッセージキュー（Azure Service Bus）へ通知送信のリクエストが送信されたことを契機として、Azure Functionsが自動的に起動する。
• Azure Functionsはプログラムの実行環境をサーバレスで提供するものであり、帳票作成処理の実行環境を容易に構築可能である。
• 帳票のファイル形式としてPDFを想定するが、PDFの作成機能はマネージドサービスとして提供されていない。
• したがって、PDFの作成に必要なライブラリの導入が必要である。
• ライブラリの仕様によっては、Azure Functionsではなく、コンテナイメージを実行可能なAzure Container Appsも選択肢として検討できる。

[3]

• 作成した帳票は、他の機能ブロック内に存在するAzure Storage Accountsをストレージとして保管する。

[4]

• 作成した帳票を他システムに連携する場合には、外部連携機能を使用する。

ブロック実現例

ブロック実現例 説明

[1]

• SPA（Single Page Application）における静的ファイル（HTML、JavaScript、CSS）をAzure Front Door及びAzure Storage Accountsで配信する。
• ファイルは高耐久なオブジェクトストレージであるAzure Storage Accountsに保管する。Azure Front DoorはCDNとしての機能を提供し、大量のリクエストにも低レイテンシーでの応答を実現する。
• またWAFによりインターネット経由で行われる様々な攻撃からフロントエンド配信機能を保護する。
  [2]
• ユーザーは他の機能ブロックにおいてユーザー認証を行い、認証トークンを取得する。
  
  ※ ユーザー認証については登録者と利用者で同じプロセスになるため、同一の項番で表記する。

[3]

• ユーザーからのリクエストはREST APIで送信される。
• REST APIはAPI Management及びAzure Functionsにより構築される。
• またWAFによりインターネット経由で行われる様々な攻撃からAPIを保護する。
  [4]
• APIリクエストの認可は認証系の機能ブロックにより発行されるトークンを検証することによって行われる。
• API ManagementはAuthorization ヘッダーで示される連携機能から取得されたアクセストークンを検証し、APIリクエストヘッダーに含まれるトークンの有効性を検証する。
• トークンが有効な場合のみ、APIリクエストは受理される。
• 登録者からのノウハウの登録リクエストはノウハウ登録関数へ、利用者からの検索リクエストはノウハウ検索処理関数へ送信される。
  [5]
• 認可されたリクエストは、ノウハウ登録関数によってノウハウ保管ストレージであるAzure Storage Accountに保存される。（ファイルの提出者などのメタデータについてはファイルのメタデータとして保存するか、もしくは別途のデータベースなどに保管する。）
  [6]
• Azure AI SearchへはAzure Functionsを利用し差分データを取り込む。
• Azure Functionsのタイマートリガー機能を用いて一定間隔で実行される。
  
  ※Azure Functionsの実行上限（例: 従量課金プランでは5分）などを超える処理の場合にはDurable FunctionsまたはLogic Appsを選択する。

[7]

• 認可されたリクエストは、ノウハウ検索処理関数から、RAG（検索拡張生成）を構成したAzure OpenAI Service及びAzure AI Searchと連携して処理される。
• ユーザーからのリクエストを使用してAzure OpenAI ServiceがAzure AI Searchに対する検索文を生成する。
• Azure AI SearchはAzure OpenAI Serviceが生成した検索文から全文検索を行い検索結果を返信する。
• Azure OpenAI ServiceはAzure AI Searchから受信した検索結果内容を整形した回答を生成する。
• Azure AI Searchでは、キーワード検索、セマンティックランキング、ベクトル検索、及びこれらの組み合わせによる高度な検索が可能である。
• Azure AI Searchでは、Azure AI Document Intelligenceその他のAIサービスと連携した、より高度な情報抽出を基にしたインデックス化も可能である。
• Azure AI SearchとAzure OpenAI Serviceを組み合わせることで、検索文の文脈や意図をより深く理解した検索が可能になる。

ブロック実現例

ブロック実現例 説明

[1]

• 外部のソーシャルIDプロバイダと連携してシステムへのログインを行う。
• Azure Active Directory B2Cは、Facebook、Microsoft アカウント、Google、Apple などの外部 ID プロバイダーopen_in_newOpens in new tab、および OAuth 1.0、OAuth 2.0、OpenID Connect、SAML の各プロトコルに対応した外部サービスと連携可能

[2]

• Azure Active Directory B2Cのを使用し、ソーシャルIDプロバイダとの連携（フェデレーション）を実行する。

[3]

• ユーザー情報の管理、トークンの有効性確認等はAzure Active Directory B2Cの機能を用いる。

[4]

• Azure Active Directory B2Cが発行したトークンによるアクセス制御を行い、他のWebAPIを提供する機能ブロックへアクセスする。
• トークンの検証は、API ManagementはAuthorization ヘッダーで示される連携機能から取得されたアクセストークンを検証し、APIリクエストヘッダーに含まれるトークンの有効性を検証等で実現する方法が考えられる。

ブロック実現例

ブロック実現例 説明

[1]

• Azure AD B2Cをファーストパーティとし認証を行う。
• ユーザー情報の管理、トークンの有効性確認等はAzure Active Directory B2Cの機能を用いる。

[2]

• Azure Active Directory B2Cが発行したトークンによるアクセス制御を行い、他のWebAPIを提供する機能ブロックへアクセスする。
• トークンの検証は、API ManagementはAuthorization ヘッダーで示される連携機能から取得されたアクセストークンを検証し、APIリクエストヘッダーに含まれるトークンの有効性を検証等で実現する方法が考えられる。

ブロック実現例

ブロック実現例 説明

[1]

• ユーザの認証ではGビズIDとの連携を行う。
• GビズIDとは事業者向け共通認証システムであり、このGビズが提供する標準的な認証の仕様であるOpenID Connectのフローに従いユーザの認証を行う。
• 本機能ブロックでは、多要素認証を行う例を示しているが、IDとパスワードによる単要素での認証が可能なユーザの種類(gBizIDエントリー)もGビズIDには存在する。
• なお、GビズID発行について、個人事業主向けにはすでにオンライン発行可能となっている。また、法人代表者向けには令和5年度末にオンライン化が予定されている。

[2]

• ユーザがGビズIDにログインしたのちにトークンを取得する。

[3]

• ユーザのリクエストが正当なIdPから発行されたトークンに基づくものであるかはAPI Managementにより検証される。
• API Managementはトークンの有効性を検証するポリシーを使用してリクエストに付加されたトークンが正当なIdPによって発行され、有効なものであるかを確認する。

[4]

• トークンの有効性が確認されたのち、実際の連携機能へリクエストが伝播される。

[注]

• GビズID システム連携ガイド（行政サービス向け）: https://gbiz-id.go.jp/top/system_guide/system_guide.htmlopen_in_newOpens in new tab

ブロック実現例

ブロック実現例 説明

[1]

• Azure AD B2Cをファーストパーティとし認証を行う。
• ユーザー情報の管理、トークンの有効性確認等はAzure Active Directory B2CなどOpenID Connectに準拠したIdPを用いる。

[2]

• ユーザのリクエストが正当なIdPから発行されたトークンに基づくものであるかはAPI Managementにより構築される。
• API Managementはトークンの有効性を検証するポリシーを使用してリクエストに付加されたトークンが正当なIdPによって発行され、有効なものであるかを確認する。
• トークンの有効性が確認されたのち、実際の連携機能へリクエストが伝播される。

ブロック実現例

ブロック実現例 説明

[1]

• ユーザの認証では外部のID管理システムとの連携を行う。
• 標準的な認証の仕様であるOpenID Connectのフローに従い、ユーザの認証を行う。

[2]

• ユーザのリクエストが正当なIdPから発行されたトークンに基づくものであるかはAPI Managementにより検証される。
• API Managementはトークンの有効性を検証するポリシーを使用してリクエストに付加されたトークンが正当なIdPによって発行され、有効なものであるかを確認する。

[3]

• ユーザが外部IDプロバイダにログインしたのちにトークンを取得する。
• ログインによって取得されたトークンを付与してリクエストを行う。

[4]

• トークンの有効性が確認されたのち、実際の連携機能へリクエストが伝播される。

ブロック実現例 説明

[1]

• 職員情報を管理するオンプレミスまたはクラウドの仮想マシン上に構築されたActive Directoryを使用して、職員のIDとパスワードを管理する。

[2]

• Entra ID Connectを使用することでActive DirectoryからMicrosoft Entra IDに対してアカウントを同期できる。

[3]

• ユーザのリクエストが正当なIdPから発行されたトークンに基づくものであるかはAPI Managementにより検証される。
• API Managementはトークンの有効性を検証するポリシーを使用してリクエストに付加されたトークンが正当なIdPによって発行され、有効なものであるかを確認する。

[4]

• ユーザが外部IDプロバイダにログインしたのちにトークンを取得する。
• ログインによって取得されたトークンを付与してリクエストを行う。

[5]

• トークンの有効性が確認されたのち、実際の連携機能へリクエストが伝播される。

ブロック実現例

ブロック実現例 説明

[1]

• WebAPIの呼び出し元の認証にはMicrosoft Entra IDを使用する。
• Azure内部の認証主体はマネージドIDを使用してEntra IDにトークン要求を行うが、この操作はAzure内部で自動的に行われるためユーザーが意識する必要はない。

[2]

• Azure内部の認証主体の場合はマネージドIDを使用して取得したトークンを用いてWebAPIを呼び出す。
• Azure外部の認証主体の場合はEntara IDに設定されたサービスプリンシパルのIDおよび秘密鍵または証明書を付加してWebAPIを呼び出す。

[3]

• WebAPIはAPI Managementにより構築される。
• API Managementはポリシーによって認証主体が要求に付加した認証情報（トークンなど）を検証する。

[4]

• API Managementがバックエンドへ要求を転送する場合も、同様にマネージドIDや外部サービスで定められた認証形式を設定できる。

ブロック実現例

ブロック実現例 説明

[1]

• WebAPIの呼び出し元の認証にはMicrosoft Entra IDを使用する。
• Azure内部の認証主体はマネージドIDを使用してEntra IDにトークン要求を行うが、この操作はAzure内部で自動的に行われるためユーザーが意識する必要はない。

[2]

• Azure内部の認証主体の場合はマネージドIDを使用して取得したトークンを用いてWebAPIを呼び出す。
• Azure外部の認証主体の場合はEntara IDに設定されたサービスプリンシパルのIDおよび秘密鍵または証明書を付加してWebAPIを呼び出す。

[3]

• 認証情報（トークンなど）を使用して、非同期連携またはファイル連携のためのAzureリソースへアクセスする。
• 非同期連携では、Service Bus/Queue Storage（メッセージキュー）、Event Hub（大量のイベントをリアルタイムに配信）、Event Grid（イベントルーティング）が送信先の例として挙げられる。
• また、ファイル連携ではオブジェクトストレージであるBlob Storageが例として挙げられる。

ブロック実現例

ブロック実現例 説明

[1]

• Microsoft Defender for Containers にてAzure Container Registry で保管するコンテナイメージに対する脆弱性のスキャンを行う。
• Microsoft Defender for Cloud DevOps にて Azure DevOps や GitHub 上のコードをに対する脆弱性のスキャンを行う。

[2]

• DNSクエリログ、Azure操作ログ（Activity Log）、SQL Database不正操作をMicrosoft Defender for Cloud にて情報収集し、異常検知を行う。

[3]

• Microsoft Defender for Storageにて、Azure Storage Accounts を対象として機密データの検出を行う。

[4]

• Azure Policyにて、Azure リソースの設定内容及びアクセス権限の評価を行い、問題を検知した場合にDefender ダッシュボードに通知を行う。

[5]

• DDoSネットワーク保護にて、グローバルIPに対するDDoS攻撃に対する保護を行い、攻撃を検知した場合Defender ダッシュボードに通知を行う

[6]

• 対処が必要なインシデントについては、Azure Logic Apps、Azure Functionsを使用して必要な復旧・対処を行う。

[7]

• 検出結果を、運用者がMicrosoft Defenderのダッシュボードにアクセスして確認する。

ブロック実現例

ブロック実現例 説明

[1]

• Azure DNSにて、ドメインを利用した通信を行うための、DNS機能を提供する。

[2]

• DDoSネットワーク保護にて、DDoS攻撃保護を行う。
• Application GatewayやAPI ManagementなどパブリックIPをアタッチできるサービスが保護対象となる。また、Azure DNSやFront DoorなどのPaaSサービスについては既定の Azure インフラストラクチャ DDoS 保護により追加コストなしで保護される。

[3]

• Azure WAFにて、通信を介した攻撃保護を行う。各業務機能ブロックで使用しているフロントAzureリソース（Azure Application Gateway、Azure Front Door）にアタッチすることで機能を有効化する。
• マネージドルールの使用が原則であるが、システムの特性上それでは満たされない場合のみカスタム ルールで独自の規則を記述する。

[4]

• Azure Firewallにて、許可されていない通信をブロックする。
• 必要に応じてIPS機能を有効にする。

[5]

• HTTPS通信を必須とする場合は、Azure Front Door で、HTTPをHTTPSにリダイレクトするか、HTTP通信を拒否する。

[6]

• Network Security Group にて、インスタンス向けの許可した通信のみを通過させる。

ブロック実現例

ブロック実現例 説明

[1]

• データ保護が必要な業務データを分類し、対象データを保管するAzureリソースに対して、Microsoftマネージドキーまたは、Azure Key Vaultなどで生成したカスタマーマネージドキーで暗号化を実施する。（キーの管理や制御が必要な場合や、要件等でカスタマーマネージドキーの利用が指定されている場合等を考慮し、 Microsoftマネージドキーまたは、カスタマーマネージドキーを選択する。）

[2]

• データ保護が必要なログデータを分類し、対象データを保管するAzureリソースに対して、Microsoftマネージドキーまたは、Azure Key Vaultなどで生成したカスタマーマネージドキーで暗号化を実施する。

[3]

• データ保護が必要なバックアップデータを分類し、対象データを保管するAzureリソースに対して、Microsoftマネージドキーまたは、Azure Key Vaultなどで生成したカスタマーマネージドキーで暗号化を実施する。

[4]

• Key Vault アクセス ポリシーを用いて、暗号化キーへのアクセス制御を行う。

ブロック実現例

ブロック実現例 説明

[1]

• 環境定義はAzure Resource Manager もしくは Bicep テンプレートで実装し、環境構築を実行する。
• IaCとして作成されたソースコードがシステム構成を表しており、変更時の差分確認も行うことが可能なパラメーターシート（構成管理）相当になる。

[2]

• 各アプリケーションが稼働しているAzureサービスの構成情報をTemplate Specsに蓄積し、監査時に変更管理に関わる証跡の保存として利用する。

ブロック実現例

ブロック実現例 説明

[1]

• Azure Backup Centerでバックアップ取得対象の設定を行う。

[2]

• 設定したルールに従って、バックアップが実行される。

[3]

• Azure Backup Center により、バックアップデータがBackup VaultsまたはRecovery Service Vaultsに保管される。

[4]

• 必要に応じて、バックアップデータのクロスリージョンコピーを実施する。

[5]

• バックアップ取得タイミングに業務処理との依存関係がある場合（バッチジョブ実行後の断面でバックアップを取りたい等）、Azure Logic Appsを利用することで他の処理と合わせてオーケストレーション制御が可能。
• 業務依存が無い場合は、Azure Backupにてスケジュール起動する。

[6]

• SQL Databaseなどデータベースサービスのバックアップについては、各データベース毎のバックアップ機能を利用する。

ブロック実現例

ブロック実現例 説明

[1]

• 監視対象の業務アプリケーションの稼働状況を示す様々なメトリクス値をAzure Application Insightsにて集約する。
• 監視対象のネットワークに関連する様々なメトリクス値をNetwork Insightsにて集約する。
• CPU使用率などのワークロードの基本的なメトリクスについてはAzure Monitorのメトリクス機能で監視する。

[2]

• 監視対象の業務アプリケーションが生成するログをLog Analyticsにて集約する。

[3]

• 閾値超過時などの異常検出設定に従い、Alertを発報する。

[4]

• Alert発報時は、メールで運用担当者に通知する。

[5]

• Azure Logic Appsを利用してSlackなどのチャットアプリケーションで通知する。

[6]

• サービス監視機能やセキュリティ_セキュリティ管理機能で検出したAlertをオブザーバビリティ_システム監視機能で集約して運用担当者に通知する。

[7]

• Log Analyticsからログ管理_ログ管理機能ブロックに対してログ可視化や分析のためにログ転送を行う。

[8]

• 運用者は収集したデータをAzure Dashboardにアクセスして確認する。

[9]

• Azureリリースのメンテナンス情報と障害情報の通知の確認にAzure Service Healthを使用する。

[10]

• 収集したイベント情報をLog Analyticsで一覧確認する。

ブロック実現例

ブロック実現例 説明

[1]

• Application Insightsでサービス監視対象のURL監視（外形監視）を行う。

[2]

• Application Insightsで実際のユーザートラフィック情報を収集し、ユーザー体験やサービスのパフォーマンス把握を監視する。

[3]

• 収集したサービス応答時間やエラー発生率等をオブザーバビリティ_システム監視機能に連携し、ダッシュボード上に表示することで、定量的計測を行う。
• それぞれの計測結果を必要に応じて監視機能ブロックのアラーム機能に連携させる。

ブロック実現例

ブロック実現例 説明

[1]

• 各サービスのログを長期保存が必要な場合は、Azure Storage Accountsに保存する。
• 分析が必要な場合は、Log Analyticsに保存する。

[2]

• Network WatcherのNSGフローログをAzure Storage Accountsに保存する。
• NSGフローログはNetwork Watcher内のトラフィック分析ワークスペースにて分析する。

[3]

• Azure操作ログを取得するActivity LogsをLog Analyticsに転送する。

[4]

• Log Analytics上のログデータを長期保存のためにAzure Storage Accountsに保存する。

[5]

• Log Analyticsを使用して、ログを検索し確認する。
• Azure Storage Accountsに保管したログはAzure AI Searchで検索し確認する。

ブロック実現例

ブロック実現例 説明

[1]

• Azure Pipelinesを用いることで、ソースコードの変更をトリガに一連の流れを自動的に実行するパイプラインを構築する。
• Azure Reposでソースコードの管理を行う。

[2]

• Azure Pipelinesでソースコードをビルドテストを実施し、ビルドされたイメージをAzure Container Registryに登録する。

[3]

• Azure Pipelinesでアプリケーションを検証環境でテスト済みのコンテナイメージが登録されたAzure Container Registryから本番環境にB/Gデプロイする。

[4]

• 本番環境のリリースについては、安全のため手動承認フェーズを設ける。

[5]

• 開発環境のAzure Container Registryは本番環境・検証環境とば別に用意し、手動イメージ操作を許容する（開発環境の自由度を高め開発効率化を図る目的）が、本番環境・検証環境では許可しない方針とする。

ブロック実現例（#サーバレスデータ連携）

ブロック実現例 説明

[1]

• 本機能ではシステム毎に連携機能により蓄積されたデータを対象とする。

[2]

• システム毎に連携機能により蓄積されたデータをAzure Data FactoryのジョブによりETL処理を実施し、共有用のAzure Storage Accountsへ保存する。

[3]

• 共有用のAzure Storage Accountsに対してMicrosoft Purviewのスキャンを実施し、メタデータをデータカタログに登録する。

[4]

• Microsoft Purviewでは共有対象データ資産、非共有対象データ資産の全てを登録・管理する。

[5]

• 運用者は業務分析者および分析者のアカウントをMicrosoft Entra IDに登録する。
• 運用者は業務分析者に対してMicrosoft Purviewデータカタログ内の共有対象データ資産に対する参照権限を付与する。
• 運用者は分析者に対して共有対象データ保存ストレージ内のデータ参照権限を付与する。

[6]

• 業務分析者はデータカタログで管理されたメタデータをMicrosoft Purviewポータルにて参照する。

[7]

• 分析者は付与された権限に従ってデータを利用する。

ブロック実現例

ブロック実現例 説明

[1]

• 本機能は職員が省庁内文書を参照し実施する必要がある通常業務において、省庁内文書に対応したチャットボットの導入により、業務効率化（例. 文書の要約生成により内容を把握するための時間を短縮、業務に関連する文書抽出により文書を探すための時間を短縮など）を図るための機能である。
• なお、本機能は、他の機能により提供されるフロントエンドアプリからアクセスされることを想定する。

[2]

• Azure AI Searchでは、PDFやWord等の非構造化ドキュメント及びFAQを記述したCSVまたはJSONファイルの構造化ドキュメントの双方をインデックスとして登録することが可能である。
• Azure AI Searchでは、キーワード検索、セマンティックランキング、ベクトル検索、及びこれらの組み合わせによる高度な検索が可能である。
• Azure AI Searchでは、Azure AI Document Intelligenceその他のAIサービスと連携した、より高度な情報抽出を基にしたインデックス化も可能である。

[3]

• ユーザーは他の機能ブロックにおいてユーザ認証を行い、認証トークンを取得する。

[4]

• 生成AIサービスによる機能はREST APIとして提供される。
• REST APIはAPI Management及びAzure Functionsにより構築される。
• またWAFによりインターネット経由で行われる様々な攻撃からAPIを保護する。

[5]

• APIリクエストの認可は認証系の機能ブロックにより発行されるトークンを検証することによって行われる。
• API ManagementはAuthorization ヘッダーで示される連携機能から取得されたアクセストークンを検証し、APIリクエストヘッダーに含まれるトークンの有効性を検証する。
• トークンが有効な場合のみ、APIリクエストは受理される。

[6]

• Azure AI Foundryのプロンプトフローにてリアルタイム推論を行うためのフローを構築し、マネージドオンラインエンドポイントとしてデプロイする。
• ユーザーからのリクエストは、マネージドエンドポイントとしてデプロイされたAPIへ送信する。
• プロンプトフローでは、Azure OpenAI Service及びAzure AI SearchによるRAGの構成が可能である。

[7]

• ユーザーからのリクエストを使用してAzure OpenAI ServiceがAzure AI Searchに対する検索文を生成する。
• Azure AI SearchはAzure OpenAI Serviceが生成した検索文から関連文書を検索し、関連文書内容を返信する。
• Azure OpenAI ServiceはAzure AI Searchから受信した関連文書内容に応じて回答を生成する。

ブロック実現例 （#サーバレスバックエンド #ストレージ直接アクセス）

ブロック実現例 説明

[1]

• 本機能は職員が省庁内等のフォーマットが定められている文書作成する際に整形処理の補助として利用し、業務効率化を図るための機能である。
• なお、本機能は、他の機能により提供されるフロントエンドアプリからアクセスされることを想定する。

[2]

• ユーザーは他の機能ブロックにおいてユーザ認証を行い、認証トークンを取得する。

[3]

• 機械学習サービスによる機能はREST APIとして提供される。REST APIはAPI Management及びAzure Functionsにより構築される。
• また、WAFはインターネット経由で行われる様々な攻撃からAPIを保護する。

[4]

• 生成AIサービスによる機能はREST APIとして提供される。
• REST APIはAPI Management及びAzure Functionsにより構築される。
• またWAFによりインターネット経由で行われる様々な攻撃からAPIを保護する。

[5]

• リクエストが認可された場合は、Azure Functionsは対象のファイルに対してSAS（Shared Access Signature）キーを生成し、それを含むURLを返却する。
• SASキーは特定のファイルに対して期間と操作（作成・削除・変更）を限定してアクセス権を与えるためのキーである。

[6]

• 職員はSAS URLでAzure Storage Accountsへフォーマットを定義した文書をアップロードする。​

[7]

• Azure Functionsの中でフォーマットを解析してプロンプトに挿入することで整形対象のテキスト文を整形して回答を生成する。
• 対象とするフォーマットを扱うライブラリに対するAzure Functionsのサポート状況を事前に確認することが推奨される。

ブロック実現例

ブロック実現例 説明

[1]

• 本非機能ブロックは他機能のデータストレージをデータソース対象とする。

[2]

• データソースのデータはストレージトリガーにより起動する文書要約処理関数により取得される。

[3]

• 取得された文書はAzure FunctionsとDocument Intelligence、Azure OpenAI ServiceによりAI機能を利用してテキストを抽出され、要約される。

[4]

• 文書分類処理関数が要約された文書を受け取り、Azure OpenAI Serviceにより分類される。

[5]

• 要約された文書と分類情報はまとめてAzure Storage Accountsへ保存される。

[6]

• 他の機能ブロックは要約・分類文書保管ストレージ内のファイルを参照することができる。

ブロック実現例（#サーバレスバックエンド #サーバレスフロントエンド）

ブロック実現例 説明

[1]

• SPA（Single Page Application）における静的ファイル（HTML、JavaScript、CSS）をAzure Front Door及びAzure Storage Accountsで配信する。
• ファイルは高耐久なオブジェクトストレージであるAzure Storage Accountsに保管する。Azure Front DoorはCDNとしての機能を提供し、大量のリクエストにも低レイテンシーでの応答を実現する
• WAF（※）によりインターネット経由で行われる様々な攻撃からフロントエンド配信機能を保護する。
  ※WAFのルールについては非機能ブロック「セキュリティ_通信を介した攻撃への保護」を参照すること。

[2]

• 運用者は他の機能ブロックにおいてユーザ認証を行い、認証トークンを取得する。

[3]

• DBメンテナンス操作はREST APIで送信される。
• REST APIはAPI Management及びAzure Functionsにより構築される。
• WAFによりインターネット経由で行われる様々な攻撃からAPIを保護する。

[4]

• APIリクエストの認可は認証系の機能ブロックにより発行されるトークンを検証することによって行われる。
• API ManagementはAuthorizationヘッダーで示される連携機能から取得されたアクセストークンを検証し、APIリクエストヘッダーに含まれるトークンの有効性を検証する。
• トークンが有効な場合のみ、APIリクエストは受理される。

[5]

• 認可された操作は、メンテナンス操作実行関数により実行される。
• メンテナンス操作実行関数内にはデータベースへ接続するためのJDBC等のドライバーを配置し接続する。

[6]

• メンテナンス対象のデータベースは他の機能ブロックにより保持される。

[7]

• メンテナンス操作実行関数は他の機能ブロックにより構築される。

[8]

• メンテナンス操作実行関数の実行ログ及びデータベースの監査ログは他の機能ブロックにより管理される。

ブロック実現例（#サーバレスバックエンド #コンテナバックエンド）

ブロック実現例 説明

[1]

• SPA（Single Page Application）における静的ファイル（HTML、JavaScript、CSS）をAzure Front Door及びAzure Storage Accountsで配信する。
• ファイルは高耐久なオブジェクトストレージであるAzure Storage Accountsに保管する。Azure Front DoorはCDNとしての機能を提供し、大量のリクエストにも低レイテンシーでの応答を実現する
• WAF（※）によりインターネット経由で行われる様々な攻撃からフロントエンド配信機能を保護する。
  ※WAFのルールについては非機能ブロック「セキュリティ_通信を介した攻撃への保護」を参照すること。

[2]

• 運用者は他の機能ブロックにおいてユーザ認証を行い、認証トークンを取得する。

[3]

• DBメンテナンス操作はREST APIで送信される。
• REST APIはAPI Management及びAzure Container Appsにより構築される。
• WAFによりインターネット経由で行われる様々な攻撃からAPIを保護する。

[4]

• APIリクエストの認可は認証系の機能ブロックにより発行されるトークンを検証することによって行われる。
• API ManagementはAuthorizationヘッダーで示される連携機能から取得されたアクセストークンを検証し、APIリクエストヘッダーに含まれるトークンの有効性を検証する。
• トークンが有効な場合のみ、APIリクエストは受理される。

[5]

• 認可された操作は、メンテナンス操作実行サーバーにより実行される。
• メンテナンス操作実行サーバー内にはデータベースへ接続するためのJDBC等のドライバーを配置し接続する。

[6]

• メンテナンス対象のデータベースは他の機能ブロックにより保持される。

[7]

• メンテナンス操作実行関数は他の機能ブロックにより構築される。

[8]

• メンテナンス操作実行関数の実行ログ及びデータベースの監査ログは他の機能ブロックにより管理される。

ブロック実現例

ブロック実現例 説明

[1]

• DB操作に必要なクライアントツールが含まれたディスクイメージとAzure Resource ManagerテンプレートもしくはBicepファイルを用いてメンテナンス操作実行サーバーとなるAzure Virtual Machineをデプロイし、起動する。

[2]

• Azure Resource ManagerテンプレートもしくはBicepファイルを用いてAzure Bastionをデプロイする。

[3]

• 運用者は端末からブラウザを開き、Azure Portalにサインインする。

[4]

• Azure PortalからAzure Bastionを使用してAzure Virtual Machineにログインする。

[5]

• ログインしたAzure Virtual MachineからDBクライアントツールによりデータベースにログインし、メンテナンス操作を実施する。

[6]

• メンテナンス対象のデータベースは他の機能ブロックにより保持される。

[7]

• Azure Portalからリソースに対して実施した操作、Azure Bastion経由でのアクセスログ、データベースの監査ログは他の機能ブロックにより管理される。

ブロック実現例

ブロック実現例 説明

[1]

• あらかじめサービス使用料金を予算額として設定し、設定した料金に実績が近づいた場合の通知条件を（例：予算の 80% 超過等）を予算にて行う。

[2]

• サービス使用料が通知条件に達した場合に、メールで運用担当者に通知する。

[3]

• アクショングループと Logic Apps を利用して、文面をカスタマイズしたメール送信や Slack などのチャットアプリケーションで通知する。

[4]

• 閾値超過時などの通知を受信した場合、運用者は Cost Management で実際の使用状況を確認する。

• Power Platformの利用は、GSSに問い合わせるか、利用組織による調達を想定するものとする。

ブロック実現例

ブロック実現例 説明
※具体的な業務への適用については第7章の各業務ブロックに存在する Power Platform のパターンを参照のこと。

[1]

• Power Pages にて国民もしくは企業向け Web サイトを提供する。
• Web サイトは Power Pages 用の Web Application Firewall を設置して保護する。
• ユーザーの認証は他の機能ブロックにより行われるが、Power Pages と連携して動作する。

[2]

• 職員向けのアプリケーションは主に Power Apps により提供される。
• Power Apps におけるユーザー認証は Power Platform を利用している EntraID で行われる。

[3]

• 国民/企業向けの Web サイト、職員向けのアプリでデータの保存が必要になった場合には、Dataverseに要求して保存する。
• Power Automate フローによる処理の自動化でデータの保存が必要になった場合も Dataverse を利用する。

[4]

• 国民/企業向けの Web サイト、職員向けのアプリから依頼されるバックエンド処理は Power Automate がフローとして処理する。
• データの追加/変更といったイベントに伴って処理を行う場合にも Power Automate を利用する。

[5]

• 外部システムへの接続が必要な場合はデータコネクタを介してアクセスする。
• 事前構築済みのコネクタがある場合はそれを利用し、ない場合(独自システムへの接続など)はカスタムコネクタを作成する。

[6]

• 運用者/開発者はポータルページや管理センターを用いて Power Platform にアクセスする。
• アクセスに対するユーザー認証は Power Platform を利用している EntraID で行われる。

[7]

• Power Platform では CI/CD パイプライン機能を利用して開発・検証・運用といった各環境へのデプロイを自動化することができる。

[8]

• Power Platformを従量課金プランで利用する場合、Azure の課金管理機能を用いて課金状況の確認や課金アラートの定義を行うことができる。