自治体窓口DXSaaS概要説明

令和５年５月９日【本資料の対象】• 自治体のみなさま• ガバクラ上にパッケージシステムをセットアップし、サービスとして窓口DXの機能を提供していただく事業者
のみなさま
1.0版

目次
•

１．窓口DXSaaSとは•

２．窓口DXSaaSプロジェクトの目的•

３．窓口DXSaaSが想定しているこれからの自治体窓口の姿•

４．窓口DXSaaSの形態、運営方法•

５．自治体窓口における解決すべき課題とソリューションのあり方•

６．SaaSとしての実装イメージ•

７．窓口DXSaaSで提供を想定しているサービスの機能•

８．窓口DXSaaSのサービス調達方法（デジタル庁）•

９．窓口DXSaaSの申請及び利用にかかるプロセス（自治体向け）•

10．DXは業務改革(BPR)とシステム導入作業がセット•

11．デジタル庁による窓口BPR支援事業について（自治体向け）•

12．窓口BPR支援事業への参加方法（自治体向け）•

13．窓口DXSaaSのサービス準備工程表•

14．全体工程表•

15．ベンダー向け情報•

16．トータルデザインの中での「窓口DX SaaS」の位置づけ•

17．事業スローガン•

18．窓口DXSaaS利用に向けた参考情報•

19.

窓口DXSaaS利用に向けた参考情報

2

窓口DXSaaSを自治体の皆様と共創し、今年夏ごろ目途にサービスインを目指します
窓口DXSaaSのサービスインまでの流れ…窓口DXSaaS

デジタル庁が提供する窓口DXSaaSは、主に共創PFに参加している全ての自治体の皆様と連携をしながら作成中

主体
デ
ジ
庁

自
治
体

窓口DXSaaSの仕様検討(12月～3月)
デジ田交付金Type１
募集(～2/16)

デ
ジ
庁

➢

実施内容：自治体と連携しつつ必要な機能を極力仕様に反映➢

実施期間：令和４年12月１日～令和５年３月末目途➢

方法：主に共創プラットフォームにてBPR業務改革（BPRアドバイザー派遣事業）(3月～)
デジ田交付金に自治体窓口DXSaaS活用で応募した自治体を中
心に、希望する自治体にはアドバイザーを派遣し窓口BPRを支援

募集・調達※複数ベンダーへの調達・構築を想定

ベ
ン
ダ
ー

自
治
体

デジ田交付金でデジタル庁が提供する窓口DXSaaSを活用して窓口DXに取り組む自治体については、デジ田事務局が交付金対象事業の採択にあたり加点➢

実施計画の提出：令和5年２月９日～２月16日➢

審査期間：令和５年３月中旬➢

交付決定：令和５年４月…デジ田交付金…BPRアドバイザー
派遣事業

構築開始

➢

支援内容：現状調査、推進体制の構築支援、BPR等➢

支援期間：令和５年２月下旬～随時➢

支援頻度：3日間/１団体(オンライン/オフライン)※応募方法等の詳細は後日案内

ラインナップ公開（2023夏頃）
希望する自治体が順次導入※デジ田交付金等活用

3

１．窓口DXSaaSとは

4

窓口DXSaaSとは• デジタル庁のガバメントクラウド上に、複数のベンダーに「窓口DXに資するパッケージシステム」を支度していただき、そのシステムの機能を「サービスとして自治体に提供してもらう」
ことで、自治体が窓口DXに取り組む際のハードルを「ちょっとでも簡単にしたい」というの試みです。
• 自治体は、自分たちでシステムを用意する必要はなく、自分たちに合ったサービスを選択肢の中から「選ぶ」イメージです。
5

窓口DXSaaSのイメージ※デジタル庁が示す要件を満たす場合は、全てガバメントクラウド上に構築することが可能

SaaS
サービ
ス提供

X社
窓口DXSaaS

Y社
窓口DXSaaS（マルチテナントアプリ）（マルチテナントアプリ）【事業者】（ガバクラ上に
SaaS構築）Z社
窓口DXSaaS（マルチテナントアプリ）【デジタル庁】

SaaS
導入①要件の提示②ガバメント
クラウドの提供【各自治体】

業務
BPR

BPRは独自、又は窓口BPR人材派遣事業の活用

選定
利用

選定
利用

※基幹業務システム等
との接続。

選定
利用

②窓口DXSaaSの選定④窓口DXSaaS利用に向けた基幹業務システムとの連携・構築

デジ田交
付金対象

【各自治体】③窓口DXSaaSの利用（提供される機能や価格等をもとに自治体が選ぶ）※窓口DXSaaSの利用にあたって必要となる申請手続き等のプロセスについては現
在検討中【デジタル庁】

窓口BPRアドバイザー派遣事業①業務のBPR

A市

B町

C区
6

≪補足≫調達範囲
ガバメントクラウド
窓口DXSaaS導入時
点で、ガバメントク
ラウドとのネットワ
ーク接続環境が地方公共団体側で設計できていない場合は、
SaaSのオプション
サービスとして、
NaaS等との「接続環境（Gateway）」
を提供。（ガバメン
トクラウドのシング
ルベンダー共同利用方式に準拠）

X社
窓口DX
SaaS

Y社提供
窓口DX
SaaS

Z社提供
窓口DX
SaaS

A市接続環境Gateway

B町接続環境Gateway

C区接続環境Gateway

NaaS等

A市庁内
NW

NaaS等

B町庁内
NW

NaaS等

C区庁内
NW

デジタル庁
公募範囲

R5はこの部分のガバメ
ントクラウド利用料もデジ庁負担。

各地方公共団体
構築部分※ガバメントクラ
ウド側のネットワ
ーク環境まで自治体で構築する必要がある。

7

２．窓口DXSaaSプロジェクトの目的

8

なぜSaaSなのか• SaaS＝ガバメントクラウド上に展開された様々なサービスに接続し、セットアップすることでサービスが利用できる環境を用意する。
• 住民、職員の双方の課題の解決を目指す窓口業務改革の取り組みを迅速に全国に広げるため、SaaSという形態を活用。
• 優良な先行事例の業務改革プロセスとそれをサポートするサービスの横展開
をガバメントクラウドの活用により加速度的に進めていく。
※このSaaSの仕組みは選択肢のひとつであり、自治体に導入の義務を課すものではありません。
※SaaSサービスを導入すること自体が目的でもありません。目的はあくまで窓口DXです。

9

３．窓口DXSaaSが想定している
これからの自治体窓口の姿【要注意】「自治体窓口はこうでなくてはならない」というつもりはありません。
自治体ごとに目指す窓口の姿が様々なことも当然です。
ここで想定している「これからの姿」は、あくまでそのなかのひとつの姿です。
10

窓口改革でユーザーの体験を変えたい
ユーザーとは、住民だけでなく、自治体の職員も含まれる。

窓口DXSaaSが想定している自治体窓口の姿

住民に
やさしい

書かない

待たない

回らない

マイナンバーカードや公金受取口座登録のメリットも実感

職員に
やさしい

職員負担の軽減

サービス平準化

窓口とともにバックヤードも改革

経験の浅い職員も窓口対応可能12

これからの窓口• 「住民の負担を減らす」と「職員の業務負荷を減ら
利便性の向上 × 職員の業務の効率化

す」の両立を本気で目指す。
• オンライン化（行かない窓口）が進み、窓口に来る人が将来減るからこそ、窓口はコンパクトに。
• デジタルのチカラを最大限活用して自治体の準備や運用をラクに。
• デジタル３原則（①デジタルファースト、②ワンス
オンリー、③ワンストップ）が実現する社会の先鞭に。
13アプローチ例：「手書き」を減らし効率化• 紙申請でなくデータで受付• 基幹システムと窓口支援システムのデータを双方向で活用• 職員向け手続きガイダンス機能で受付を平準
化• マイナンバーカードを使って情報を転記し事務ミスを削減将来、スマホなどからのオンライン申請や住民向けナビゲーションとの連携も。
etc（埼玉県深谷市資料より引用、改変）
14

４．窓口DXSaaSの形態、運営方法

15

窓口DXSaaSの形態、運営方法• SaaSの利用者：自治体• SaaSの提供者（運営者）：ベンダー（複数）• SaaSの所有者（オーナー）：ベンダー• SaaSを提供するクラウドプラットフォーム：ガバクラ• ガバメントクラウドの提供者：デジタル庁
ベンダーがガバメントクラウド上に SaaS 環境を構築するのにあたり、対応する
CSPのユーザーアカウントをデジタル庁（メンバーアカウントオーナー）において用意し、これへのアクセス権を事業者に付与します。
16

窓口DXSaaSの形態、運営方法のイメージ
様々なベンダー、多用なカバー範囲のパッケージ（SaaSサービス）

X社提供

Y社提供

Z社提供

窓口DX
SaaS提供者/所有者：ベンダー SaaS
サービス

窓口DX
SaaS
サービス

窓口DX
SaaS
サービス

ガバメントクラウド提供者：
デジタル庁

ガバメントクラウド

A市
データ

SaaS利用者：自治体
A市

17

ポイント
• 自治体は、ラインナップされた複数の窓口DXSaaSの中から、自らが解決したい課題や思い描く将来の窓口の姿にあわせたサービスを選定することができる。
（自治体が新規にシステムを作る必要はなく、短期間で窓口DXに着手可能）• ベンダーは、自らの提供するSaaSが自治体に選ばれるために、創意工夫によりパッケージの機能やサービスを充実させ、またアジャイ

ルで改善していく。
18

５．自治体窓口における解決すべき課題とソリューションのあり方

19自治体窓口における解決すべき課題の事例
≪住民側≫

≪職員側≫

• 手続きに必要となる届出書や申請書等のすべてに氏名や住所等多くの項目を記入する必要があり、手続きに手間がかかっている。

• 届出書等毎に記入方法の説明、記入内容のチェック作業が必要であるため、職員の事務負担が大きい。

• サービスを受けるのにどんな種類の申請や書類が必要なのかわからない。

• 対応する窓口職員の判断が複雑化し、経験が長い職員でないと対応が難しいなど、業務が属人化している。また、
新人職員教育の負担が大きい。

• 自分が受けられるサービスがどんなものがあるか分からない。
• いろんな窓口に行かなければならず、そのたびに番号札を取って待たされる。
• 待ち時間が長い• 届出書等の内容確認後にシステム入力を行い、入力内容の確認も必要であるため、1つの届出で複数の確認（審査）が必要となり、工数がかかる。
• 対応する職員の判断が複雑化し、業務の属人化や待ち時間を含めた窓口対応時間の長期化が課題。

20

課題に対応したソリューションの事例
≪住民側≫

≪職員側≫

• 手続きに必要となる届出書や申請書等のすべてに氏名や住所等多くの項目を記入する必要があり、手続きに手間がかかっている。
→申請書作成支援→マイナンバーカードを使った転記• 届出書等毎に記入方法の説明、記入内容のチェック作業が必要であるため、職員の事務負担が大きい。
→手続きのガイダンス→申請書作成機能• サービスを受けるのにどんな種類の申請や書類が必要なのかわからない。
→手続きのナビゲーション（住民側）• 対応する窓口職員の判断が複雑化し、経験が長い職員でないと対応が難しいなど、業務が属人化している。また、
新人職員教育の負担が大きい。
→手続きのガイダンス• 自分が受けられるサービスがどんなものがあるか分からない。
→手続きのナビゲーション（住民側）• いろんな窓口に行かなければならず、そのたびに番号札を取って待たされる。
→総合窓口（ワンストップ）機能• 待ち時間が長い→複数の窓口DX機能の組み合わせにより短縮• 届出書等の内容確認後にシステム入力を行い、入力内容の確認も必要であるため、1つの届出で複数の確認（審査）が必要となり、工数がかかる。
→手書きを減らし受付からデータで処理し基幹系業務シ
ステムに連携する機能• 対応する職員の判断が複雑化し、業務の属人化や待ち時間を含めた窓口対応時間の長期化が課題。
→複数の窓口DX機能の組み合わせにより短縮
21

課題解決の実例①（北海道北見市資料より引用）

フロント業務改革「書かない × ワンストップ」■「書かない × ワンストップ」による受付時間の時間短縮イメージ（北海道北見市）（例）

書かない、やさしい、窓口を回らない

６分①１人世帯で転入
手書きの住民異動届書かないワンストップ窓口

住民異動届記入

他課での手続き

転入届

転入届

３分半

＋
浮いた時間で関連手続き案内＋ワンストップ受付

７分②４人世帯で市内転居
手書きの住民異動届書かないワンストップ窓口

住民異動届記入

転居届

他課での手続き

転居届

２分半

＋
浮いた時間で関連手続き案内＋ワンストップ受付

６分③住民票と所得課税証明書
証明書を２か所で申請書かないワンストップ窓口

申請書記入

住民票

住民票＋所得課税証明書

申請書記入

所得課税証明書

１分４０秒

バックヤード業務改革「RPA連携＆ライフイベントワンストップ」※上記はいずれも、手続きの受付にかかる時間を表す。受付をシステム化したことで、このあとの事後処理も高速化される。

22

（埼玉県深谷市資料より引用）

課題解決の実例②
フロント業務改革「書かない×データ連携」
旧

証明書：平均１０分

申請・届出作成

受付：本人確認、内容確認

10～15分

１分

入 力

３～４分

１～２分

滞
留

現在

住民異動：平均３０分削減！！

１～２分

審 査

３分

１分

滞
留

０分

RPA

０～８分

受付：本人確認、申請・届出書作成

自動入力

証明発行：
平均２０分
住民異動：
平均５０分

１分
証明発行：
平均１０分

滞
留

住民異動：
平均２０分

OR
直接連携
発券機

交 付

審 査

交 付

23

６．SaaSとしての実装イメージ

24

構成イメージ（案）ガバメントクラウド

自治体環境

インターネット

窓口
DXSaaS

キャッシュレス etc...
オンライン申請※オプションとして準備するか、自治体で用意するものを利用※オプションとして準備するか、自治体で用意するものを利用 データ連携

データ連携、もしくはデータを参照する仕組み他サービスとは柔軟にAPI連携

API連携等

API連携

標準化後
基幹系
システム

申請管理
システム

ぴったりサービス
申請API

データ連携

標準化前の
基幹系
システム

マイナポータル
ぴったりサービス

標準システム・窓口DXSaaSは標準化関連業務として、基幹系システムと連携して利用する想定。
・各システムとは疎結合を基本とし、データ連携はファイル連携またはAPI連携が考えられる。
・データ連携により、基幹系システムと異なるベンダーの窓口DXSaaSにすることも想定される。
・標準化前の基幹系システムとの連携については共通データベースやRPA、ファイル連携等の活用により対応することが想定される。 25

窓口DXSaaS
・自治体の窓口DXに資するシステム（サービス）・迅速な利用開始が可能となるよう、ガバクラ上にサービスとして展開。
・基本機能は指定するが、実装方法やカバー範囲、データ利活用等の範囲はベンダーの創意工夫領域。
基本イメージ図

ガバメント・クラウド
X社
窓口DX
SaaS

Y社
窓口DX
SaaS

Z社
窓口DX
SaaS

自治体窓口
サービス選択専用線やガバメントクラウ
ド接続サービス等

基本機能
・手続きガイダンス
・申請書作成・マイナンバーカード活用
・他サービスとAPI連携

・自治体は自己の解決課題に合致するサービスを選定

26

番号系NWでの実装事例と範囲（標準化前）
対面窓口を支援するシステムを、個人番号系ネットワークにて運用するケースの実装例

ガバメント・クラウド
窓口DX
SaaS
必須機能
・手続きガイダンス
・申請書作成・マイナンバーカード活用
・他サービスとAPI連携

実装事例

個人番号系ネットワーク

ガバクラ環境窓口DXSaaSサービスが参照するデータ
Ａ：ガバクラ側に置く手法（SaaSサービス側で簡易的に場所を用意する）
Ｂ：自治体既存環境側に置く手法（既存のデータ参照の仕組があれば使用）が考えられる

窓口DXSaaS
サービス

自治体既存環境

データ連携、もしくはデータを参照する仕組み

標準化前

各基幹系業務システム（住基など）

データ

既存の各基幹系業務システムからのデータ吐き出しは、自治体側の責任範囲で構築する必要

データ

基幹系業務システムへのデータ反映を自動化する場合は、デー
タ連携やRPAの活用が考えられる。

参照可能な基幹系業務システムのデータの種類が多いほど、 窓口DXSaaS側で取り扱える業務やデータの範囲は広くなることとなる。

27

番号系NWでの実装事例と範囲（標準化前）
ガバメント・クラウド

電子申請との組み合わせは必須要件ではないが、実装が期待される。
（データ参照・オンライン申請等連携ありタイプ）
・インターネット側については、各事業者によって大きく異なる、創意工夫の範囲かと思われます。

窓口DX
SaaS
必須機能
・手続きガイダンス
・申請書作成・マイナンバーカード活用
・他サービスとAPI連携

実装事例

個人番号系ネットワーク

ガバクラ環境窓口DXSaaS
サービス

インターネット
住民
オンライン
申請

LGWAN系ネットワー
ク
マイナポータル
申請管理

マイナポータル
ぴったりサービス
マイナポータルAPI

他のオンライン申請
自治体既存環境

データ連携、もしくはデータを参照する仕組み

標準化前

各基幹系業務システム（住基など）

28

標準化前後でのデータ連携方法の例示
連携頻度

標準化前

標準化後

データ参照

定時処理

・共通DB等・ファイル連携→既存の他システム連携用ファイルを活用

・共通DB等・ファイル、API連携→「データ要件・連携要件標準仕様書」の独自施策システ
ム 等連携仕様に従って連携

データ入力

リアルタイム

データ転記→RPA
帳票出力 →RPA

データ転記→RPA・API
帳票出力 →RPA•

標準化前の基幹系システムの改修を抑える方法の例•••

EUC機能、中間サーバ向けのデータ標準レイアウト、コンビニ交付用連携ファイル等の活用
RPAによるデータ入力

窓口DXSaaSで取り扱う業務範囲、連携するデータの種類・項目の整理は必要••

標準化前に連携手法やデータの整理をすることで、標準化後の連携がより円滑にできる
標準化後もデータを参照する仕組み（共通DB等）やRPAの活用は想定される

29

７．窓口DXSaaSで提供を想定しているサービスの機能

30

窓口DXSaaS 前提条件
● ガバメントクラウド上でサービスを提供すること。
● マイナンバーカード取得のメリットを住民に窓口で実感してもらえること。
● 窓口の手続をデジタルを活用して改善すること。
● デジタルを活用することで、住民だけでなく、地方公共団体の職員のユー
ザー体験（UX）も変革し、職員の業務負担と心的負担を軽減すること。

● 地方公共団体の保有する住民の情報（基幹系業務システムのデータ）を利用すること。

● 他サービスやシステムと連携ができること。
● SaaS間の乗り換えに対応できること。
31

窓口DXSaaS 必須要件（４つ）１．手続きガイダンスができること（職員対面向け用を想定）• 職員が住民対面で手続きをする際に、ライフイベントに合わせて漏れなく手続きができること• 基幹系業務システムのデータを活用して、申請者の状況に合わせた窓口受付やガイダンスの判定等ができること。
• 運用に合わせて柔軟に業務フローが設定できること

２．申請書作成ができること•••

基幹系業務システムのデータ及び手続きガイダンス機能で入力した内容を利用して申請書が作成できること
運用に合わせて、サービスを利用する職員が柔軟に申請書のフォーマットを変更できること
申請書の出力方法について、紙への印刷やタブレット端末への出力等、柔軟性を持たせること

３．マイナンバーカードが利活用できること• マイナンバーカードから読み取った４情報等の自己情報を申請書に自動入力ができること• マイナンバーカードに搭載されているアプリケーションや電子証明書、ICチップの空き領域等の利活用を検討する
こと

４．他サービス*とAPI等の連携ができるようにしておくこと• 他のシステム・サービスと連携が可能となった際に、柔軟に連携できるサービス設計となっていること※ 他システムやサービスとはマイナポータルや公共サービスメッシュ等が想定される

32

窓口DXSaaS 必須要件以外の機能の例示（ベンダーが自社のSaaSの差別化、競争力向上のために創意工夫を凝らして任意で機能を実装）★あくまで一例★

• 煩雑な申請内容の審査を自動化• 審査結果の電子交付• 証明書交付事務については、根拠法令等を参照できる• 「書かない」を外国人でも対応• 店舗等の「有人レジ」と「セルフレジ」のように導線を分ける• 音声案内によるガイダンス• 窓口やオンライン申請での支払いのキャッシュレス決済• 窓口と住民をオンラインでつなぐ（リモート窓口）• 窓口対応の統計情報のレポート …etc

オプションとして実装するかしないのか、実現方法も含めてベンダー次第
そして、魅力的と感じた自治体がオプションも含めて選択できる
33

８．窓口DXSaaSのサービス調達方法（デジタル庁）34

窓口DXSaaSのサービス調達方法（デジタル庁）• 窓口DXSaaSを準備（構築）する「場所」は、デジタル庁がガバメント

クラウド上に用意する。
• 窓口DXSaaSは、デジタル庁が基本的な要件を示し、窓口DXSaaSによるサービス提供を希望するベンダー（複数）に公募で調達する。
• 仕様の内容は、共創PFでデジタル庁と自治体でブラッシュアップする。

（※デジタル庁で案を作るので、関心のある自治体職員からフィード
バックをお願いするもの。）
35

９．窓口DXSaaSの申請及び利用にかかるプロセス（自治体）

36

窓口DXSaaSの申請及び利用にかかるプロセス（自治体）
７月のラインナップの公開の際に、以下のものを自治体に公開をする
ため、これらを参考に各自治体で調達を実施することを想定している。

• 操作性やサービスを利用した業務フロー等を事前に確認することを目的としたモックアップ環境• 必須要件の実装方法及びオプション等の創意工夫領域を含めたサー
ビスメニューの一覧が記載されているサービス紹介資料• SaaS利用に必要な費用を明記した「料金表」• 自治体で別途用意する必要がある機材等の明示（例：PC、カードリーダー、プリンタ、RPAツール等）※ガバメントクラウド接続サービスの利用については別途連絡予定37

10．窓口DXは業務改革(BPR)とシステム導入作業がセット38

窓口DXの前提条件は、窓口の業務改革（BPR）
求められる、業務改革
窓口が縦割りでバラバラ

分厚いマニュアル

紙だらけ

窓口を回っている

窓口業務は、情報処理

業務改革＝BPR

窓口DX成功のカギ（フロント・バックヤード）×

システム活用カギどころか、
BPRなしでSaaS（システム）だけ利用しても無意味39窓口DXは、業務改革のためにシステムを活用することシステム導入が目的ではない！

「ＤＸ」＝「業務改革」＝ＢＰＲ

何を解決したいのか、自分たちの自治体の窓口をどのような場所にしたいのか。
ありたい姿と本来の目的に立ち返ってシステムの活用を。
業務を変えずにシステムありき型（調達先行）で進めると・・・？
・このシステムがほしい！
・業務は変えたくない！
・うちの部署だけほしい！

調達※業務を変えないでツールだけ導入すると・・・

・やりたいことができない
・一部の機能しか使われない
・フロントのみの「デジタル化」

・こんなの何に使うの？
・思ってたのと違うかも。
・部署ごとに異なるシステムが導入？

自分たちの自治体内で、関係者が集まってじっくり議論して課題解決型（BPR）で進めると・・・
・この課題を何とかしたい・こんな風に業務を変えたい・こんなことできたらいいな

・こんな機能がほしい・こんな使い方がしたい
・みんなでBPRしようよ！

業務改革＆

業務改革の目的に見合ったシステムを使って業務改革

システム導入（北海道北見市資料より引用、改変） 40

11．デジタル庁による窓口BPR支援事業について（自治体向け）

41

「窓口BPRアドバイザー派遣事業」を参照

42

12．窓口BPR支援事業への参加方法
（自治体）

43

「窓口BPRアドバイザー派遣事業」を参照

44

13．窓口DXSaaSのサービス準備工程表

45

「窓口DXSaaS」を自治体のみなさまと共創し、全国展開を目指します
全国展開に向けたイメージ
R4年度までに窓口DXに取り組んでいる自治体
既に窓口DXに取り組んでいる先行自治体(R4年度デジ
田交付金事業（R3補正予算）の活用団体を含む)の更なるBPRやクラウド対応等を支援することで窓口DXの高度化、全体の底上げを支援。

実証協力団体（R４～）
R4年度デジ田交付金事業（R3補正予算）として、窓口DX先行自治体のシステムをガバクラ上で実装し、システムのマルチテナント化・デジ庁SaaS提供に向けた運用実証を行う。

R5年度以降窓口DXに取り組む自治体（R５～）
R5年度デジ田交付金事業として採択された団体を中
心に、ガバクラ上で窓口DXSaaSを提供。自治体業
務のBPR、窓口DXSaaSの仕様決定、SaaSを活用したサービス実装などを自治体の皆様と共創。

全国展開へ加速（R６～）

46

【再掲】窓口DXSaaSを自治体の皆様と共創し、今年夏ごろ目途にサービスインを目指します
窓口DXSaaSのサービスインまでの流れ…窓口DXSaaS

デジタル庁が提供する窓口DXSaaSは、主に共創PFに参加している全ての自治体の皆様と連携をしながら作成中

主体
デ
ジ
庁

自
治
体

窓口DXSaaSの仕様検討(12月～3月)
デジ田交付金Type１
募集(～2/16)

デ
ジ
庁

➢

実施内容：自治体と連携しつつ必要な機能を極力仕様に反映➢

実施期間：令和４年12月１日～令和５年３月末目途➢

方法：主に共創プラットフォームにてBPR業務改革（BPRアドバイザー派遣事業）(3月～)
デジ田交付金に自治体窓口DXSaaS活用で応募した自治体を中
心に、希望する自治体にはアドバイザーを派遣し窓口BPRを支援

募集・調達※複数ベンダーへの調達・構築を想定

ベ
ン
ダ
ー

自
治
体

デジ田交付金でデジタル庁が提供する窓口DXSaaSを活用して窓口DXに取り組む自治体については、デジ田事務局が交付金対象事業の採択にあたり加点➢

実施計画の提出：令和5年２月９日～２月16日➢

審査期間：令和５年３月中旬➢

交付決定：令和５年４月…デジ田交付金…BPRアドバイザー
派遣事業

構築開始

➢

支援内容：現状調査、推進体制の構築支援、BPR等➢

支援期間：令和５年２月下旬～随時➢

支援頻度：3日間/１団体(オンライン/オフライン)※応募方法等の詳細は後日案内

ラインナップ公開（2023夏頃）
希望する自治体が順次導入※デジ田交付金等活用

47

14．全体工程表

48

窓口DXSaaSのサービスインスケジュール
R5
3

⚫

デジタル庁

4

RFI

5

公募開始

事業者選
定・契
約

6

7

8

ガバクラア
カウント
払い出し

窓口DXSaaSのラインナップ公表

9

10

11

12

1

2

3

SaaS事業者との調整／運用チェック

SaaS利用のための自治体サポート

BPRアドバイザー派遣事業

✓

✓

事業者

自治体

応募(提案書とガバクラ
アーキ図)

窓口DXSaaSの構築（ガバクラ）モックアップ準備(事業者環境)

モックアッ
プ・料金
表公開

各自治体が窓口BPRをスタート（アナログ改革：窓口体験調査やワンストップの対象とする手続きの「幅と深さ」の調整、様式の統一の検討など）

自治体への営業活動・契約

調達開始

契約

各自治体が連携が必要なデータ項目を扱う基幹系システムベンダーと連携方法や周期について調整
基幹系システムで連携させるデータ連携
項目を確定

・事業者が窓口DXSaaSに自治体ごとのマスタ等セットアップ開始
・事業者が自治体ごとの基幹系システムとのデータ連携テス
ト・事業者ないしは自治体（自治体の別途委託先）がRPAシナ
リオ作成
サービス開始に向けた事業者との調整

各自治体で
受け入れ
検証

各自治体が
サービス開始（利用）49

15．ベンダー向け情報50

調達・構築スケジュール• ７月末にラインナップの公開を目標として、それに間に合うスケジュールで調達を実施• ５月上旬 ：公募開始• ６月上旬 ：事業者選定（複数）、ガバメントクラウドのアカウントの払い出し• ７月中旬 ：モックアップ環境、サービス紹介資料、料金表の公開• ７月下旬 ：ラインナップの公開• ８月～：各自治体で窓口DXSaaSの調達• 11月下旬～：各自治体で受け入れ検証－サービス利用51自治体窓口DXSaaSの非機能要件・SLA•

総務省とデジタル庁で公開している「地方公共団体情報システム非機能要件の標準」をベースとなる。

•

クラウドサービス自体のサービスレベルは、各CSPが定めるSLAに準拠する。クラウドサービス標準のSLAを参照しつつ、各システム自体の可用性や業務継続性の確保は、各サービス提供事業者において、十分に技術的対応策を検討すること。

•

ガバメントクラウドを利用するにあたり、各テンプレートが用意されるため、それらが適
用される。

•

セキュリティは、SCPと自動適用テンプレート、必須適用テンプレートが適用される。ア
プリ側の脆弱性対策は各サービス提供事業者で実施すること。

•

ガバメントクラウドへの接続方法は、ガバメントクラウド接続サービス等があるが、指定
はしない。
52

窓口DX SaaSの契約・支払い形態
凡例※対応する CSPのユーザーアカウント
をデジタル庁（メンバーアカウントオーナー）において用意し、これへのア
クセス権をベンダーに付与する。

デジタル庁

ガブクラ利用料請求書

お金の流れ
契約関係
その他

CSP

ガブクラ利用料
契約B（サービス提供に係る業務委託）メンバー
アカウント 委託料
付与

ガブクラ
利用料

※令和５年度分はデジタル庁
が負担する窓口DXSaaS
ベンダー

契約C（アプリ利用申請）

契約C（アプリ利用申請）
サービス提供

アプリ
利用料

アプリ
利用料

契約D
（運用管理委託）契約D（運用管理委託）ガバメントクラウド
運用管理補助者

委託料

サービス
提供

委託料

自治体A

自治体B
サービス
提供

ガバメントクラウド
運用管理補助者

53

自治体及びデジタル庁と一緒に構築いただける事業者を募ります⚫ 窓口業務の改善は積年の課題です。デジタル社会の実現に向け大きく２つの視点で取り組みます。
⚫ 自治体の窓口業務は、令和7年度を目処に進められている基幹系業務システムの統一・標準化後も残ります。今回、構築される窓口DXSaaSでは、マイナンバーカードを利用した住民が、手続きの所要時間が大幅に短縮されたことを実感でき、いままでの先入観まで払拭されることと、窓口対応する自治体職員も、業務時間の短縮が実感できるツールの構築を一緒に目指します。
⚫ ガバメントクラウドの利用は開始されたばかりです。今後、マイナンバーカードを利用した様々な業務改善ツールの開発が加速すると考えられています。窓口DXSaaS構築参画事
業者においては、技術者のスキルアップや新たな事業展開の検討だけでなく、ガバメント
クラウド上で自治体業務効率化に資する新たなSaaS開発に向けて、住民や自治体との共創が、促されることを目指しています。
54

資格要件等
公募にあたり以下の資格要件等を求める• 令和4・5・6年度全省庁統一資格の「役務の提供等」 のA、B、C又はD等級に格付けされ、競争参加資格を有する者であること。なお、共同事業体（JV）による提案は想定していない。
統一資格審査申請・調達情報検索サイト｜ホーム (geps.go.jp)• ガバメントクラウド上で窓口DXSaaSを提供可能な事業者。
• パブリッククラウド環境のモダンアプリケーション技術に明るい事業者であること。（モダン技術への明るさの基準）• SaaSの開発・運用体制に、想定するCSPの上級資格保有者を含んでいること。（本業務の専任であることは求めない。）• 有資格者が環境構築等のインフラ作業に関与すること。
• 例）AWSの場合：Solution Architect Professional• GCPの場合：Professional Cloud Architect• Azureの場合：Azure Solutions Architect Expert• OCIの場合：Oracle Cloud Infrastructure xxxx Certified Architect Professional
・ 情報セキュリティに係る以下のいずれかの認定・認証を取得していること。
・ プライバシーマーク付与認定
・ 最新のJIS Q 27001（ISO/IEC 27001）を基準とした情報セキュリティマネジメントシステム（ISMS）の適合性に関する認証55

【窓口DXSaaS導入に向けた参考情報（現時点）】⚫ 準備時：令和５年７月予定のラインナップの公開からガバメントクラウド上での窓口
DXSaaSのサービス提供に当たっての環境を提供します。
※R５年度のサービス提供準備に係るガバメントクラウド利用料はSaaS構築ベンダーには発生しないようにします。
⚫ 運用時：自治体が窓口SaaSを利用する際のガバメントクラウド利用料は、
・R５年度：自治体にもSaaSベンダーにも発生しないようにします。
・R６年度以降：自治体が負担する予定。
※窓口DXSaaSの利用料は自治体が負担する。
⚫ デジタル庁ではサービスの運用保守実績に係る事務的経費の対価として、システム管理技
術者×0.2人月相当額／月を委託料としてSaaSベンダーに支払うことを想定。

56

16．トータルデザインの中での「自治体窓口DX SaaS」の位置づけ(TOBE)

57

トータルデザインにおける「自治体窓口DX SaaS」の位置づけ(ToBe)案「自治体窓口DX SaaS」はガバクラ上の公共サービスメッシュにおける住民との接点となる
公共サービスメッシュ

58

17. 事業スローガン

59

事業スローガン

窓口改革でユーザーの体験を変えたい
ユーザーとは、住民だけでなく、自治体の職員も含まれる。

60

18.窓口DXSaaS先行実証自治体

61◼

実証事業の概要・目的•

R5年夏頃の窓口DXSaaSの提供に向けて、ガバメントクラウド上でのシステムのマルチテナ
ント化や、標準化前の基幹システムとの連携、システムのモダン化等にかかる運用実証を実施する。

◼

H市を選択した理由•

R3年度補正デジタル田園都市国家構想交付金のタイプ1において、窓口業務改革(窓口DX)事業として採択済みの団体であった。（計70団体が採択）•

上記70団体のうち、パブリッククラウドに関連システムを構築する計画であった基礎自治体
であり、本実証の趣旨に賛同いただけたため。

◼

対象とした手続•戸籍、住基、印鑑、税、国保、介護、後期高齢、児童手当、学齢簿

◼

評価

•

R4年度11月～1月の3ヶ月間でモダン化した検証環境と本番環境が構築でき、基幹系システム
62との連携テストを含めて完了。総合テストの結果、性能も十分であると判断できた。

（参考）実証協力団体(H市)の例
•

•
•
•

•
•
•

•
•
•

R4.3 デジ田交付金タイプ１採択
R4.4 庁内プロジェクトチーム設置
R4.4 北見市視察（6名）
R4.5 深谷市視察（6名）
R4.7 窓口DXシステム調達公告（WTO）
R4.9 契約締結
R4.10 要件定義等基本設計
R4.11 システム構築環境をガバクラに変更
R5.1 本番環境構築完了、基幹系システムとの連携開始
R5.2 操作研修、総合テスト、2/24本稼働（証明のみ）※7区役所＋51出先施設＝58窓口（証明29手続）•

R5.6 届出業務開始予定
63

先行実証団体ガバクラ環境 参考構成図AWS Cloud

運用・監視*サービス名称先頭のAmazon or AWSは省略

CodePipeline

CodeCommit CodeBuild

CDK

CloudWatch

VPC
Private Subnet

TGW
Private Subnet

ECS
Fargateアプリケーション処理

TGW

TGW
Private Subnet

ALB

Aurora
データベースWriterPrivate Subnet
ECS
Fargateアプリケーション処理

Aurora
データベース
Reader642023.03.01 株式会社北見コンピューター・ビジネス

（参考）実証協力団体(H市)でのポイント➊①

いちばん大事だと思ったのは「自分たちはいったいどういう窓口にしたいのか」というイメージ（ゴール）の共有。
（企画系の職員ではなく窓口の職員を数多く先行団体に視察で受け入れてもらえたのがとてもよかった）②

ゴールさえ決まれば、「そのためになにが必要か、なにを変えなければならないか」を考えた。
（例えば、ワンストップで行う手続きの範囲や深さの決定、様式の調整、本人確認書
類の統一、窓口や事務室のレイアウト変更や発券機やサイネージの位置など、必要な変化の大半はアナログの改革だった）③

アナログ改革に行き詰まったり、困ったときは、すぐに先行団体に相談した。
（オンラインツールは便利。迷惑だったろうけど、実際毎日毎日連絡して相談した）65

（参考）実証協力団体(H市)でのポイント❷④

システムは「ゴール」に必要な要件を仕様に書いて調達した。
（WTOだから調達期間が長くてつらかった。そのせいで、本稼働までのスケジュー
ルが苦しかった）⑤

基幹系システム→窓口DXシステムとの連携方法は、標準化
前に基幹系システムを改修したくなかったので、簡易な方法とした。
（いわゆるファイル連携。基幹系システムからは新規ファイルの吐き出しはせず、これまで中間SVやコンビニ交付など他システム連携用のファイルを転用。連携用に渡されたファイルの中から必要なデータ項目だけを窓口DXシステム側でピックして取り込み。連携頻度は、DVなど極力即時連携が必要なファイルは5分間隔）⑥

窓口DXシステム→基幹系システムとの連携方法も、標準化前に基幹系システムを改修したくなかったので、RPAで入力。
66

（参考）実証協力団体(H市)のガバクラ感想▪

ガバクラは、最初怖かった。でも実際は「お膳立て」がされていて、結果的に早かった。

デジ庁から実証の打診があったときは、ガバクラなんて自分たちも初めてだし、契約してたベンダーさんも初めて（ガバクラどころかパブリッククラウドが初めて）だったから、とても不安だった。でも実際ガバクラの自動適用テンプレートを走らせたら、デジ庁が決めたセキュリティ環境、いわば「ガードレー
ルがある状態」があっという間に準備されて、リモートですぐに作業がはじめられて、ベンダーさんも「なんてことはなかったです」と言っていた。

▪

結果的に、11月～1月の3ヶ月間でモダン化した検証環境と本番環境が構築でき、基幹系システムとの連携テストを含めて爆速で完
了できた。

▪

総合テストの結果、十分すぎる性能が確認できたので、これから繁忙期と閑散期のデータを取ってさらに効率的なクラウドの運用を検討していく。
67

19.窓口DXSaaS利用に向けた参考情報68

【仕様書に関する共創PFでの意見募集状況】

既に多くの自治体の皆様から仕様に関してのご意見・ご要望をいただいております！
⇩●●という機能があると良いと思います！

私の自治体では〇〇が大きな課題となっています！

▲▲という案に私も賛成です！！

69

共創プラットフォームへのご参加お待ちしております！
デジタル庁HPの申請フォームよりご登録下さい(所要時間：約５分)※窓口DXSaaSについては「#自治体窓口業務改革_行政手続オンライン化」チャネルでやりとりをさせていただきます

登録方法【申請フォーム】
https://forms.office.com/r/E7A93w4ygJ70