地域情報プラットフォームガイドライン

第４章
業務ユニットを活用した各種サービスの検討～付加価値サービス、ワンストップサービス等

一般財団法人全国地域情報化推進協会

地域情報プラットフォームガイドライン第 4 章

項

版数

修正内容

1

2013.5.31

表紙及びヘッダのバージョン記載を削除

改版履歴

備考
版数表記を、バージョン標記から修正
日標記に変更内容の修正は行っていないため、版数の変更はなし地域情報プラットフォームガイドライン

目次

４．業務ユニットを活用した各種サービスの検討 ............................................ 2
４．１ 自治体内を中心とした付加価値サービスの検討 ............................................................................ 5
４．１．１ 各種情報照会サービス ................................................................................................................ 5
４．１．２ GIS 共通サービスインタフェースの活用 ............................................................................... 12
４．２ 自治体内ワンストップサービス、自治体間、官民連携サービスの検討 .................................. 17
４．２．１ ワンストップサービスの考え方 .............................................................................................. 17
４．２．１．１ ワンストップサービスとは .............................................................................................. 17
４．２．１．２ 地域情報プラットフォームにおけるワンストップサービスの考え方 ...................... 20
４．２．２ ワンストップサービスの構築方法 .......................................................................................... 25
４．２．２．２ サービスの考え方、粒度について .................................................................................. 29
４．２．２．３ ワンストップサービスの連携定義手順 .......................................................................... 33
４．２．３ 自治体サービス .......................................................................................................................... 34
４．２．３．１ 地域情報プラットフォームにおける自治体サービスの考え方 .................................. 34
４．２．３．２ 自治体内ワンストップサービス導入における検討課題事項 ...................................... 36【コラム】情報照会・検索型のワンストップサービスについて ............................................................. 52
４．２．４ 自治体間連携サービス .............................................................................................................. 54
４．４．２ 自治体間連携サービスの検討課題事項 .................................................................................. 58【コラム】自治体間、官民連携サービスのこんなサービスがあったなら？.......................................... 61
４．２．５ 官民連携サービス ...................................................................................................................... 63
４．２．５．１ 地域情報プラットフォームにおける官民連携サービスの考え方 .............................. 63
４．２．５．２ 官民連携サービスの検討課題事項 .................................................................................. 65【コラム】東京電力株式会社様 移転連絡ワンストップサービス「引越れんらく帳」 ...................... 68
付録４－ⅰ 付加価値サービスのサンプル .................................................................................................. 69
付録４－ⅱ 地域情報プラットフォームの利活用 ...................................................................................... 70
付録４－ⅲ 各種定義体サンプル .................................................................................................................. 72
付録４－ⅳ ワンストップサービス実現に向けた個人情報取り扱いの考え方 ...................................... 73－1－

地域情報プラットフォームガイドライン

４．業務ユニットを活用した各種サービスの検討
本章では、地域情報プラットフォーム標準仕様に準拠した業務ユニットを活用して検討するサービス
として、大きく下記の二点について記載する。
Ⅰ．自治体内を中心とした付加価値サービス(*1)の検討
Ⅱ．自治体内ワンストップサービス／自治体間連携サービス／官民連携サービスの検討
Ⅰ．については、自治体の業務運用においても必要性が高いと考えられる情報照会のサービス等に関して、業務ユニットを活用して実現できるユースケースを中心に紹介する。併せて、自治体業務において補足的な利活用が想定される地図情報について、GIS 共通サービスインタフェース(*2)を利用したユー
スケースについて記載する。いずれも、本内容をご参照頂き、業務ユニットの調達に合わせて、各自治体においてご検討頂ければ幸いである。
Ⅱ．については、今後、自治体での導入検討が増えてくると想定される自治体内ワンストップサービス、
さらには自治体間、あるいは自治体と民間機関の間におけるサービス連携の構築・導入を検討する際に、それぞれ必要または参考となる事項（分析手順、分析サンプル、検討事項等）について記載する。(*3)
以下、本ガイドラインにおけるⅡ．ワンストップサービスの記載に関して、その位置づけを補足する。

－2－

地域情報プラットフォームガイドライン

ワンストップサービス導入のメリットとしては、一般的に、・インターネット上の総合電子申請や庁内の総合窓口などの実現により、各種申請・届出手続きや情報照会をまとめて（一箇所で）対応することによる住民の利便性の向上
・BPM 機能の導入により、各原課で順次進めていく業務処理を中心に、職員事務の全体効率化
・ワンストップサービスの構築を検討するに際し、各業務プロセスの見直しを実施することで、業務改善へのつながりなどが挙げられる。
地域情報プラットフォームにおけるワンストップサービス導入の考え方では、ワンストップサービス
導入検討段階で設計工程別に必要となる、分析ドキュメント（書式）の規定類（記載ルール）を先ず提供する(*4)。 加えて、本ガイドラインにて同サービス構築に当たって必要となる検討事項を提示する(*5)。
さらに、自治体間同士や民間機関とのサービス連携を実現するための技術的要素を、「アークテクチャ標準仕様」等にて提示している。各自治体では、それらに沿って、ワンストップサービス導入の検討を進めることにより、上記に加えて下記のようなメリットが加わる。
・本ガイドラインにて提示する「4.2.2.3 ワンストップサービスの連携定義手順」に沿い、業務処理
整理表～WSDL 定義までシナリオ分析＆実装設計することにより、その後の各自治体内でのシナリオ追加が容易（効率的）に可能となる。
・各自治体内にて同様の手順に従って構築しておくことにより、将来的に、（同じく同手順に沿って構築している）自治体・民間機関とのサービス連携への拡大が容易となる（連携し易い）。と同時に、自治体間・官民間サービスの連携実現により、さらなる住民サービスの向上が図られる。
・将来、業務サービスインタフェースが新たに APPLIC（全国地域情報化推進協議会）から提供された
場合(*6)に、取り込み易い。
実際に自治体などでワンストップサービスを導入する際には、業務運用方式の変更、組織体制やシステム運用方式の変革、様々な法制度面の考慮など、現時点においては標準化が困難な部分があり、個々の自治体で協議、決定すべき事項が多数存在する。これらの一部は、本章の各所に検討が必要な事項として記載されており、ワンストップサービス導入時点において、事前に十分に検討されたい。
地域情報プラットフォームが提供する各種規約の普及に伴い、システム面からの相互運用性を高めることで、こうした課題解決への糸口となることが期待される。今後、地域情報プラットフォームを一つの起点として、自治体内から、自治体間、そして官民間のサービス連携の実現へと、高度な地域情報化サービスへと発展していくことが期待され、本ガイドラインをそうした将来に向けた検討の一助としていただければ幸いである。
なお、総務省における地域情報プラットフォームの普及促進に係る施策と、内閣官房の「次世代電子
行政サービス基盤等検討プロジェクトチーム」の検討状況についても、本ガイドラインと併せて参考としていただきたい。

(*1)自治体の業務運用において必要性が高い情報照会サービスなどを指す。詳細は 4.1.2 を参照のこと。
(*2)地域情報プラットフォーム標準仕様「GIS 共通サービス標準仕様」で提供されるインタフェースを指す。
(*3)各自治体における行政手続きの業務プロセスの考え方は非常に多種多様であり、それらを一つの標準として規定することは困難であることから、本ガイドラインの本章にて、検討に必要となる事項を提示することとする。
(*4)「自治体業務アプリケーションユニット標準仕様【業務 1-30】」参照。
(*5)本章では、地域情報プラットフォームとして必要な事項に限定して記載しているため、一般的にワンストッ
プサービス等の業務サービス連携の導入に必要となる検討事項全てを網羅しているものではない。
(*6)逆に、各自治体にて実施された事例は、APPLIC へフィードバックして頂けると今後の普及につながる。

－3－

地域情報プラットフォームガイドライン

また、地域情報プラットフォームにおいて、業務サービス連携に関する検討対象事項の全体像を、
図４．０．１に示す。検討対象事項は、「標準仕様にて規定されたもの」、「本ガイドラインにてサンプル提示するもの」、「本ガイドラインにてその考え方や検討の方向性を示すもの」の大きく 3 つに分けられ、それぞれその内容が記載されている章目番号を、各項目の最後に記している。
自治体ワンストップサービスをはじめとする業務サービス連携の導入を予定されている自治体では、それら必要箇所を参照の上、各自治体の状況に合わせて検討をお願いしたい。また、本章では詳細に記載していないが、署名、代理人、添付書類、あるいは電子納付といった事項についても、必要に応じて検討が必要である。

自治体内サービス連携・自治体サービス連携の定義(4.2.3.1)

・申請メッセージ様式(4.2.3.2(5))
・地域ポータルの考え方(4.2.5.2(2))

・分岐シナリオ判定の考え方(4.2.3.2(2))
・持ち回りデータの考え方(4.2.3.2(3))
・例外処理の考え方(4.2.3.2(4))
・メッセージ交換のパターン(*1)
・メッセージの共通ヘッダ仕様(*1)

・受付機能（4.2.3.2(1)）
・進捗結果通知機能（4.2.3.2(1)）
・文書交付機能（4.2.3.2(1)）

その他 共通事項
・ワンストップサービスの定義と形態(4.2.1)
・業務サービスの粒度の考え方(4.2.2.2)
・個人認証について(4.5.2(1))
・個人情報取り扱いの考え方(4-ⅳ付録)

自治体Ａ
総合窓口
（庁内電子申請）

ＢＰＭ（ビジネスプロセス制御）
I/F

I/F

I/F

I/F

I/F

I/F

業
務
ユ
ニ
ッ
ト
Ａ

業
務
ユ
ニ
ッ
ト
Ｂ

業
務
ユ
ニ
ッ
ト
Ｃ

申請データ
地域ポータル（電子申請）

民間機関Ａ

・ワンストップサービス連携定義手順(4.2.2.3)
・分析ドキュメント（書式）(*2)
・業務サービスインタフェースのサンプル（転入、結婚シナリオ）(4.ⅲ付録)

・ワンストップサービスにおける業務ユニットに必要な機能構成(4.2.2.1)

・自治体間のサービス連携・自治体サービスの定義(4.2.4.1)
・ネットワークインフラ(4.2.4.2(1))
・サービスの連携形態(4.2.4.2(1))

自治体Ｂ

・業務サービスインタフェースのサンプル（所得照会サービス）(4.ⅲ付録)

申請データ(*1)プラットフォーム通信標準仕様(*1)プラットフォーム通信標準仕様(*2)自治体業務アプリケーションユニット標準仕様(*2)自治体業務アプリケーションユニット標準仕様

官民間サービス連携
・官民間サービス連携の定義(4.2.5.1)
・官民間業務サービスインタフェースのサンプル(4.ⅲ付録)（民間機関として電力会社を想定。
引越転入に伴う住所変更届、電力開始／停止）

図４．０．１

青字：
青字： 標準仕様にて規定
標準仕様にて規定
緑字：
緑字： サンプルあり
サンプルあり黒字：
黒字： 該当事項についての考え方や必要検討事項を記載
該当事項についての考え方や必要検討事項を記載

地域情報プラットフォームにおける業務サービス連携の検討対象事項※申請の受付としては、図４．０．１にあるように、電子申請あるいは庁内（総合）窓口などが想定されるが、いずれの場合でも、本章では自治体におけるワンストップサービスの運用全般を規定するものではないため、各自治体の状況に合わせて十分な検討をお願いしたい。

－4－

地域情報プラットフォームガイドライン

４．１

自治体内を中心とした付加価値サービスの検討

本節では、「自治体業務アプリケーションユニット標準仕様」および「GIS 共通サービス標準仕様」にて策定済みのインタフェースを活用し、自治体の業務運用においても必要性が高いと考えられる付加価値的なサービスについて述べる。
一つ目は、例えば住基・税・福祉などの情報を個人と結び付けて総合的に照会する等、いわゆる複数の業
務ユニットに跨った情報照会サービスの例である。 これは、「自治体業務アプリケーションユニット標準仕様」にて策定済みの業務ユニットインタフェースを、そのまま活用して実現できるユースケースを中心に紹介する。
二つ目は、GIS（地理情報システム）の利活用であり、「自治体業務アプリケーションユニット標準仕様」
にて策定した 26 業務の中で、GIS を活用することで、その業務支援に役立つ例をいくつか選定して紹介する。
これは、すでに策定済みの「GIS 共通サービスインタフェース（～GIS 共通サービス標準仕様より）」を、業
務ユニット側から利用するユースケース例である。

４．１．１

各種情報照会サービス「自治体業務アプリケーションユニット標準仕様」では、26 業務ユニット間において基本的に必要なデー
タ連携について策定している。一方、自治体の実務運用においては、それらデータ連携とは別に、複数の業
務ユニットにまたがった各種の情報照会サービスの導入の必要性が高まっている。たとえば、庁内の総合窓
口的な受付の職員端末では、ある住民に関する住基・税・国保資格などの総合的な情報を同時に照会するサービスが必要とされ、また、福祉の相談窓口などの職員端末でも、当該住民の生活保護や児童手当等の受給状
況を総合的に照会するサービスなどが必要とされる。
このように、自治体の実際の業務運用において必要性が高いサービスを、地域情報プラットフォームでは「付加価値サービス」と位置づけ、本節においてユースケースを記載する。なお、今回は、「自治体業務アプ
リケーションユニット標準仕様」にて策定した「業務ユニットインタフェース」をそのまま活用して実現できる付加価値サービスをご紹介する。一方で、たとえば住民（個人）の情報を総合的に照会するサービスを実際に構築する際には、通常、「かな氏名」等による検索処理の機能とインタフェースを別途実装する必要があるが、このように「業務ユニットインタフェース」の活用だけでは実装が困難な事項（＝別途検討が必要となる事項）についても触れておく。
各自治体におかれては、本ユースケースを参考にして頂き、「自治体業務アプリケーションユニット標準仕様」を有効に活用した付加価値サービスを検討して頂ければ幸いである。

（１）付加価値サービスの考え方
まず、付加価値サービスの位置づけについて、もう少し具体的に整理しておくと、概念的には次のような定義が考えられる。
・単独または複数の業務ユニットが所管する業務データを参照し、各種情報を提供するサービス。
・それ自体は、所管する業務データ（業務 DB）は基本的には持たない。
－5－

地域情報プラットフォームガイドライン

・業務ユニットと同様に、自治体での最小調達単位を可能とする。
・業務ユニットや本サービスを実装するシステムとの間では、PF 通信機能をベースに連携する。
※なお、上記はあくまで理解を補助するための概念的な整理としての定義であり、地域情報プラットフォームとして厳格に規定したものではないことを予めご理解頂きたい。上記に当てはまらないものであっても、各自治体にて個別に検討頂き、一つの付加価値サービスとして柔軟に位置づけて頂いて差し支えない。

業
務
ユ
ニ
ッ
ト
Ｂ

業
務
ユ
ニ
ッ
ト
Ａ

業
務
ユ
ニ
ッ
ト
Ｃ

Ｐ
Ｆ
通
信
機
能
Ｐ
Ｆ
通
信
機
能

Ｐ
Ｆ
通
信
機
能

付加価値サービスＡ(*1)

Ｐ
Ｆ
通
信
機
能

(*1)例えば、住基・税などの情報照会サービス。
福祉相談における福祉情報照会サービス。
複数業務に跨ったＥＵＣサービス、
複数業務情報に跨った帳票出力サービス等。

図４．１．１

各種情報提供システム(*2)(*2)例えば、総合窓口システム、地域ポータル等。
また、サービスの内容や実装形式によっては、
業務ユニットなども含まれ得る。

付加価値サービスの考え方（２）付加価値サービスのインタフェース◆付加価値サービスのインタフェース
付加価値サービスでは、二種類のインタフェースが用いられる。
（Ⅰ）付加価値サービスのインタフェース：付加価値サービスが外部にサービスを提供するためのインタフェース（Ⅱ）付加価値サービスと業務ユニット間のインタフェース：付加価値サービスが業務ユニットから情報を取得するためのインタフェース（Ⅰ）の付加価値サービスのインタフェースは、付加価値サービスの内容により様々なものが考えられる。
例えば、即時で結果を返すようなサービスの場合は、SOAP のインタフェースとするモデルが想定される。なお、本章の付録 4-ⅰとして、情報照会サービスのインタフェースのサンプル（ユースケース例）を掲載しているが、それが本インタフェースに相当する。（図４．１．２参照）
また、（Ⅱ）の付加価値サービスと業務ユニット間のインタフェースについても、付加価値サービスで用いる情報により様々なモデルが考えられる。例えば、常に最新情報を必要とするサービスの場合は、SOAP のイ
ンタフェースとし、付加価値サービスに対して依頼がある度に業務ユニットから情報を取得するモデルが想定される。一方、情報が頻繁に更新されない場合は、付加価値サービスは業務ユニットから取得した情報を一時的に保管しておき、付加価値サービスに対して情報照会の依頼がある際は一時保管する情報をもとに結果を返すモデルが想定される。
（図４．１．２参照）－6－

地域情報プラットフォームガイドライン※なお、ここでは「付加価値サービス」「各種情報提供システム」は、それぞれ以下の機能を想定している。
・付加価値サービス：各業務ユニットから情報を取得し、情報を編集する機能

・各種情報提供システム：システム操作者の要求を受取り、結果を表示する機能（画面表示機能）等

モデル例(a)： 業務ユニットとのインタフェースとして、SOAP のインタフェースを定義する
no を利用： （Ⅰ）付加価値サービスのインタフェース

付加価値サービスに対して依頼がある度に業務ユニットから情報を取得する。

業務ユニットＡ（Ⅱ）

常務ユニットＢ： （Ⅱ）付加価値サービスと業務ユニット間のインタフェース（Ⅰ）
付加価値サービス

各種情報提供システム

ＰＦ通信機能業務ユニットＣ
ＰＦ通信機能モデル例(b)： 業務ユニットとのインタフェースとして、データ交換のインタフェースを定義する
定期的に、業務ユニットから情報を取得。

： （Ⅰ）付加価値サービスのインタフェース

付加価値サービスに一時保管する。

業務ユニットＡ（Ⅱ）

常務ユニットＢ

業務ユニットＣ（Ⅰ）
付加価値サービス： （Ⅱ）付加価値サービスと業務ユニット間のインタフェース

各種情報提供システム

ＰＦ通信機能付加価値サービスに対して情報照会の依頼がある際は一時保管する情報をもとに結果を返す。

図４．１．２

付加価値サービスのモデル例（その１）◆付加価値サービスにおける業務ユニットインタフェースの活用と検討事項（Ⅰ）の付加価値サービスと業務ユニット間のインタフェースは、前述の通り、基本的にはそれを導入する
各自治体において定義する必要がある。しかしながら、付加価値サービスと連携する複数の業務ユニットを提供するベンダが異なる（＝マルチベンダ環境である）場合には、各ベンダ間の調整などに相応の労力が必要になる。
そこで、「自治体業務アプリケーションユニット標準仕様」にて策定した「業務ユニットインタフェース」を、（Ⅱ）のインタフェースとして有効に活用することにより、マルチベンダ環境において必要となる労力の低減が期待される。
（図４．１．３参照）－7－

地域情報プラットフォームガイドライン

モデル例(a‘)（別案）： 業務ユニットインタフェース（SOAP のインタフェース）を活用する： （Ⅰ）付加価値サービスのインタフェース

付加価値サービスに対して依頼がある度に業務ユニットから情報を取得する。

業務ユニットＡ（Ⅱ）

常務ユニットＢ： （Ⅱ）付加価値サービスと業務ユニット間のインタフェース（Ⅰ）
付加価値サービス

各種情報提供システム

ＰＦ通信機能業務ユニットＣ
ＰＦ通信機能「業務ユニットインタフェース」をそのまま活用

図４．１．３

付加価値サービスのモデル例（その２）

一方で、この業務ユニットインタフェースは、業務ユニット間のデータ交換を目的として、自治体業務アプリケーションユニット標準仕様にて規定されたインタフェースであり、図４．１．３に示すように（Ⅱ）のインタフェースとしてそれを活用する場合には、導入する自治体において、下記のような事項について別途検討する必要がある。
・業務ユニットから取得する情報のデータ項目
業務ユニットインタフェースでは、業務ユニット同士のデータ交換で必要なデータ項目が定義されている。また、データ交換される情報はその時点の最新情報であり、いわゆる履歴情報のデータ交換は定義されていない。
それを前提とした上で、導入を検討される付加価値サービスにおいて(業務ユニットから取得する)データ
項目と、一方の「業務ユニットインタフェース」で定義されているデータ項目とを比較し、後者に不足がないか整理し、仮に不足している場合には追加検討する必要がある。
・問合せのキー項目
業務ユニットインタフェースでは、問合せの基本キー項目として識別番号が利用されている。地域情報
プラットフォームにおける識別番号は、人（外国人・住登外者・団体・法人を含む）を共通的に管理するための情報であり、 業務ユニットを跨って人を一意に特定することができる。
一方で、例えば付加価値サービスの一つとして、個人の住基・税の情報などを職員が（窓口端末等において）総合的に照会するサービスを構築する際には、窓口に来られた個人の識別番号をその場で確認することは困難であり、まずは当該個人の氏名などをキーとして、曖昧な検索処理を実現する機能（業務ユニットへの新たな問い合わせインタフェースを含む）が別途必要となる。

－8－

地域情報プラットフォームガイドライン（３）付加価値サービスのユースケース例：情報照会サービス
ここでは、付加価値サービスのユースケース例として、「情報照会サービス」を示す。
◆情報照会サービスの例
自治体の実務運用においては、近年の様々な課題（多様化する住民ニーズへの対応、コストの削減など）達成の観点から、複数の業務ユニットに跨った各種の情報照会サービスの導入の必要性が高まっている。
情報照会サービスは、利用形態や照会する情報の内容により、下記のような様々なものが考えられる。
［情報照会サービスの例］
・住民窓口業務の担当者が、個々の業務ユニットで管理している各種住民情報を照会する。
－住民の転出の手続を行う際、当該住民の住基情報、各種の保険情報などを確認する。
－福祉相談において、児童手当など各種手当の受給状況を照会して、総合的な福祉サービスを提供する。
・各業務の担当者が、担当業務において必要となる各種住民情報を他課に照会する。
－住民税や固定資産税などの課税情報などをまとめて照会する。
●住民窓口業務の担当者による利用
住民課
住民窓口
照会

保険福祉課
照会

税務課

照会

●各種業務の担当者による利用
住民課
各種業務担当課
照会

保険福祉課
照会

税務課

図４．１．４照会

情報照会サービスの利用イメージ

なお、図４．１．４に示す情報照会サービスのインタフェースのサンプルとして、当該住民の基本情
報、福祉情報、および税情報を提供するインタフェース例を、本章の付録４－ⅰに、ＤＦＤ、インタフェー
ス一覧、およびメッセージ定義として掲載するので、参考にして頂きたい。基本的には、業務ユニット
インタフェースで定義された情報（データ項目）をそのまま提供する例としているが、適宜各自治体において、データ項目を追加検討して頂いて差し支えない。※本サンプルの位置づけとしては、図４．１．
３で示す（Ⅰ）の「付加価値サービスと業務ユニット間のインタフェース」に相当するものである。
－9－

地域情報プラットフォームガイドライン◆情報照会サービスの導入における検討・課題事項など
情報照会サービスのインタフェースや情報照会サービス自体の機能については、各自治体において、下記のような事項に関しても別途検討する必要がある。
①利用者の権限
情報照会サービスのように部署・業務をまたがって情報を取扱う事務では、権限の確認が不可欠である。情報照会サービスの検討では各自治体の実務運用に照らし合わせて情報照会サービスの利用者の範囲を決定し、必要な認証手段を設ける必要がある。また、情報照会サービスの利用者の権限により、提供する情報のデータ項目を変えることも必要である。
②情報のデータ項目
先にも述べているが、情報照会サービスではサービスの利用形態により、照会される情報の内容は様々なものが想定される。情報照会サービスの検討では具体的なユースケース・利用場面を想定して、必要となる情報（データ項目）を洗い出すことが重要である。
③画面表示と実装方法
情報照会サービスの検討では、情報の見易さや操作性などを考慮して画面を構成することが重要であり、情報量が多い場合に複数の画面に分けた表示や、複数情報の比較表示、インクリメンタルサーチ（逐次検索）などの手法が考えられる。この様な画面表示を行う場合には、レスポンスや処理負荷を考慮し、例えば、各業務ユニットから取得した情報の一時保持や情報照会に用いる問合せのキー情報を工夫するなど、実装方法の検討が必要である。

－10－

地域情報プラットフォームガイドライン◆情報照会サービスの将来的モデル
情報照会サービスは、これまで、自治体内の部署間の情報連携を目的として導入されるケースが多いと考えられる。しかし、近年各自治体では、住民ニーズの多様化や IT の普及を受け、IT を活用した住民への情報提供や情報交換のためのインフラ整備の検討・導入が進められており、今後は、地域情報プラットフォー
ムの目的の一つでもあるサイト間の連携、例えば自治体から住民向けの情報照会サービスの実現も期待される。
（図４．１．５参照）① 住民向けの情報照会サービス
自宅
ネットワーク
住民課
自治体ポータル
照会

照会

保険福祉課
照会

携帯電話
税務課

照会

照会

② 複数の自治体、その他の団体による住民向けの情報照会サービス
ネットワーク自宅

自治体Ａ
ネットワーク
照会

地域ポータル
照会

自治体Ｂ
照会

携帯電話
照会

病院など

照会

図４．１．５

住民向け情報照会サービスの利用イメージ－11－

地域情報プラットフォームガイドライン

４．１．２

GIS 共通サービスインタフェースの活用

自治体の各業務において、地図情報を活用することは、業務の効率化を図る上でも有効であり、実際に GIS（地理情報システム）を導入されている自治体も多い。固定資産税業務、上下水道管理業務、および防災業
務などのように、地図情報を主体的に活用して業務を支援するものから、当該住民の住所位置を参照するた
めに地図情報を補足的に利用する業務など、様々な活用法が想定される。
ここでは、「GIS 共通サービス標準仕様」で策定された「GIS 共通サービスインタフェース」を活用することを前提に、後者の補足的に地図情報を利用する場合について記載する。

（１）業務ユニットと GIS ユニット
「GIS 共通サービス標準仕様」では、業務ユニットから共通的に参照される地理空間データを所管するユニットとして「GIS ユニット」、また、地理空間データを蓄積・管理するためのデータベースとして、「GISDB」が定義されている。そして、業務ユニットと GIS ユニットとの間で、処理要求と処理結果の回答を交換するためのインタフェースとして、「GIS 共通サービスインタフェース」が規定されている。

Ｇ
Ｉ
Ｓ
ユ
ニ
ッ
ト

業
務
ユ
ニ
ッ
ト
：地図表示対象の住所情報を業務ユニット内にて検索後、ＧＩＳ共通サービスインタフェースを呼び出す処理：ＧＩＳ共通サービスインタフェース（ＧＩＳ共通サービス標準仕様）：ＧＩＳ ＤＢ（地名辞典、地図データ）
図４．１．６：業務ユニットのＤＢ（住所情報など）

業務ユニットと GIS ユニットの連携「GISDB」には、地名辞典(*1)と地図データ(*2)が格納されており、業務ユニット側からみれば、それらの情報を、各業務処理において必要なタイミングにて参照する連携処理を組み込むことになる。その際の連携処理用インタフェースとして、「GIS 共通サービスインタフェース」を利用する。（図４．１．６参照）
なお、同サービスインタフェースの基本的な連携としては、以下の２ステップの流れとなる。
ステップ１：業務ユニット側から住所情報を渡し、GIS ユニット側からそれに対応する位置座標を受け取る。
ステップ２：業務ユニット側から同位置座標を渡し、GIS ユニット側から当該場所に相当する地図データを受け取る。
(*1)地理識別子（場所を識別するためのラベルやコード。例えば住所情報や建物名称など）と、それに対応する地理座
標の対の集合(*3)。
(*2)建物や道路線などの形状や位置などから構成されるデータの集合(*3)。
(*3)詳細は、「GIS 共通サービス標準仕様」を参照のこと。

－12－

地域情報プラットフォームガイドライン

一方、これまで策定した 26 業務において、地図情報を補足的に利用するユースケースの例として、下記のようなものが想定される。今回はこの中で、上述の基本的な連携で地図情報の活用が可能となる、収滞納管理業務、および障害者福祉業務の各ユースケースについて紹介する。
＜地図情報を補足的に利用するユースケース例＞
住民基本台帳
外国人登録●収滞納管理●障害者福祉

：転入・転居時に新しい住所を確認（家屋の有無など）：転入・転居時に新しい住所を確認（家屋の有無など）：滞納者の位置情報（分布）を表示：住民（障害者）の当該住所を中心とした福祉施設の所在地（複数）を確認＆表示
バリアフリー対策済みの建物、道路などの表示
就学：学校の表示、学校入学希望者の表示就学対象者と学校分布地図の表示（就学対象者の学校配置時など）
介護保険：要介護者の（在住場所の）表示
後期高齢者医療 ：75歳以上の対象者の分布表示
国民年金：学生納付特例者や免除者の表示、20歳以上の未加入者の表示
未納滞納者（法人を含む）の表示
健康管理：保険未指導者の表示、3歳児健康検査のための対象者と保健所の分布表示（２）GIS 共通サービスインタフェース利用のユースケース例
ここでは、各ユースケースにおける、当該業務ユニットのＤＦＤ(*4)上にて、GIS ユニットと GIS 共通サー
ビスインタフェースを介して連携する流れを朱記追記する。ただし、必ずしも、当該箇所（業務処理）での連携が正解ということではなく、あくまでも一つの例ということでご参照願いたい。
加えて、当該業務ユニットと GIS ユニットの間で連携する情報のやりとりを、上述のステップ１・ステッ
プ２の流れに沿って、簡単に示す。
(*4)「自治体業務アプリケーションユニット標準仕様」にて規定①ユースケース１
税の滞納管理業務において、滞納者に対する督促・催告を実施する場合、当該滞納者の住所情報からその居住位置を地図上にて確認し、臨戸徴収業務等を行う。

－13－

地域情報プラットフォームガイドライン

機能情報関連図（DFD）
階層１

階層２

9.収滞納管理業務名

9.3 滞納整理

階層３

収滞納管理

9.3.2 督促・催告
・住基情報

・催告書

（1）
住民基本台帳納税義務者（5）固定資産税（6）個人住民税（7）法人住民税（8）軽自動車税（10）国民健康保険

・外国人登録情報

（3）
外国人登録

・住登外情報
・法人情報

（30）
住登外管理

・送付先情報（1）
住民基本台帳(9.3.2.2)
催告書作成

・住基情報

・送付先情報

・滞納情報
（3）
外国人登録
（30）
住登外管理

・外国人登録情報(9.3.2.1)
督促状作成

・催告情報

・滞納情報

（9.3.1）
滞納者抽出

・督促情報

・住登外情報
・法人情報

・滞納情報

滞納情報

納税義務者
・督促状

・徴収猶予情報・納税誓約情報・延滞金減免情報（9.3.3）
相談対応

・臨戸調査結果

・滞納情報
・滞納者住所情報(9.3.2.3)
臨戸・調査

・地図情報

・督促情報
・催告情報

（9.3.4）
処分

ＧＩＳユニット

納税義務者
・臨戸調査結果(x-x)
機能

図４．１．７

(x-x)
外部環境

情報の滞留
情報の流れ

収滞納管理ユニットと GIS ユニットの連携例（ＤＦＤ）

収滞納管理ユニット側からみれば、滞納者の住所情報をもとに、その所在位置を背景地図と重ね合わせて表示する動作となる。ただし前提条件として、地理識別子（＝住民の住所情報）に対応する地名辞典 DB
が、GIS ユニット内に構築済みであることが必要である。
（図４．１．８参照）

GISユニット
GISユニット

収滞納管理ユニット
収滞納管理ユニット
滞納者を検索し、その住所情報を滞納者を検索し、その住所情報を抽出（Ｎ件）
抽出（Ｎ件）

地名辞典

地図データ

Ｇ
Ｉ
Ｓ
共
通
サ
ー
ビ
ス
イ
ン
タ
フ
ェ
ー
ス

住所情報（Ｎ件）
座標情報（Ｎ件）

座標情報（Ｎ件）

抽出した住所情報を、ＧＩＳユニット
抽出した住所情報を、ＧＩＳユニット
へ提供（Ｎ件）し、それに対応したへ提供（Ｎ件）し、それに対応した座標情報（Ｎ件）を受け取る。
座標情報（Ｎ件）を受け取る。

ＧＩＳユニットから受け取った滞納
ＧＩＳユニットから受け取った滞納者の座標情報（Ｎ件）をGISユニット
者の座標情報（Ｎ件）をGISユニットに提供し、滞納者の位置情報を表に提供し、滞納者の位置情報を表示した地図画像データを受け取る。
示した地図画像データを受け取る。

地図画像データ
地図画像データを
地図画像データを表示または印刷表示または印刷

図４．１．８

収滞納管理ユニットと GIS ユニットの連携例（情報の交換）－14－地域情報プラットフォームガイドライン②ユースケース２
障害者福祉の同サービス認定管理業務において、付加価値的な住民サービスとして、福祉サービス施設（複数）の位置を地図上にて確認し、住民へ紹介する。
機能情報関連図（DFD）
階層１

階層２

12.障害者福祉(1)
住民基本台帳

(3)
外国人登録

(30)
住登外管理

業務名

障害者福祉

・住基情報

住民／
(90)電子申請

障害程度区分
判定等ソフト・外国人登録情報※障害程度区分認定証明書（転出時）※意見書依頼書※請求用用紙※意見記入用紙

医療機関

・住登外情報・申請情報ファイル

(16)
生活保護

(6)
個人住民税

・生活保護情報・障害者住所情報
・ＧＩＳ付属情報（ﾚｲﾔ番号、範囲等）

・個人住民税情報

・判定情報ファイル

ＧＩＳ
ユニット

・地図情報

(12.2.2)
判定ｿﾌﾄ用
ﾌｧｲﾙ作成【認定証明書時】
障害程度区分認定証明書(12.2.3)
支給決定

・地図情報
※支給決定通知書兼利用者負担額減額・免除等決定通知書※障害程度区分認定通知書※却下決定通知書※支給変更決定通知書兼利用者負担額減額・免除等決定通知書※障害程度区分変更認定通知書※支給決定取消通知書※障害福祉サービス受給者証※療養介護医療受給者証※社会福祉法人等利用者負担軽減対象確認通知書

・福祉サービス情報

・住登外情報(12.2.1)
申請受付

・福祉サービス情報

・障害者情報・申請情報(12.1)
手帳交付※平成１８年度１０月制度改正版

12.2.障害福祉サービス認定管理

手帳情報

・支給情報

・福祉サービス情報
・手帳情報

・福祉サービス情報

福祉サービス情報

住民／(90)電子申請

住民／(90)電子申請・負担上限額情報※支給申請書兼利用者負担額減額・免除等申請書※支給変更申請書兼利用者負担額減額・免除等変更申請書※申請内容変更届出書※受給者証再交付申請書※社会福祉法人等利用者負担軽減対象確認申請書※世帯状況・収入・資産等申告書※預金（通帳のコピー）※年金証書の写し※障害程度区分認定証明書(12.2.4)
負担上限額
管理※サービス利用計画作成対象障害者等認定申請書※サービス利用計画作成依頼（変更）届出書※利用者負担上限額管理事務依頼（変更）届出書※利用者負担額特例減免申請書

・契約情報
・福祉サービス情報・福祉サービス支払情報(12.2.5)
契約内容
登録・福祉サービス認定情報・福祉サービス認定情報※サービス利用計画作成対象障害者等認定通知書※サービス利用計画作成対象障害者等認定取消通知書※利用者負担額特例減免決定（却下）通知書
・契約内容報告書(12.3)
障害福祉サー
ビス支払管理(12.3)
障害福祉サー
ビス支払管理(12.8)
統計・報告

(x.x)
機能

凡例

図４．１．９

事業所／(90)電子申請

(x.x)
外部環境

情報の滞留
情報の流れ

・ ○○○ ： 必須情報名※○○○ ：条件により必要となる情報名

障害者福祉ユニットと GIS ユニットの連携例（ＤＦＤ）

GISユニット
GISユニット

障害者福祉ユニット

住所情報（１件）

地名辞典

地図データ
（福祉施設レイヤ含む）

図４．１．１０

住民／(90)電子申請

Ｇ
Ｉ
Ｓ
共
通
サ
ー
ビ
ス
イ
ン
タ
フ
ェ
ー
ス

障害者を検索し、その住所情報
障害者を検索し、その住所情報を抽出（１件）後、ＧＩＳユニットにを抽出（１件）後、ＧＩＳユニットにその住所情報を提供し、それにその住所情報を提供し、それに対応した座標情報（１件）を受け対応した座標情報（１件）を受け取る。
取る。

座標情報（１件）
障害者の座標情報、および福祉施設の建物レイヤの番号

同座標情報（１件）、および福祉
同座標情報（１件）、および福祉施設の建物レイヤの番号を、ＧＩ施設の建物レイヤの番号を、ＧＩ
Ｓユニットに提供し、障害者のＳユニットに提供し、障害者の位置情報及び福祉施設を重ね
位置情報及び福祉施設を重ね合わせた地図画像データを受合わせた地図画像データを受
け取る。
け取る。

地図画像データ
地図画像データを
地図画像データを表示または印刷表示または印刷

障害者福祉ユニットと GIS ユニットの連携例（情報の交換）－15－

地域情報プラットフォームガイドライン

障害者福祉ユニット側からみれば、住民（障害者）の住所情報をもとに、その所在位置、および同位置を中心とした一定の範囲に含まれる福祉施設を、一つのレイヤとして背景地図と重ね合わせて表示する動作となる。ただし前提条件として、地理識別子（＝住民の住所情報）に対応する地名辞典 DB が、GIS ユニット内に構築済みであること、および福祉施設の建物レイヤが、GIS ユニット内の地図データとして構築済みであることが必要である。
（図４．１．１０参照）※なお、本節で記載したユースケースの業務ユニットと GIS ユニットの連携例については、「GIS 共通サービス標準仕様」を参考としているため、GIS ユニットの基本的な考え方や GIS 共通サービスインタフェースの詳細な仕組み等については、GIS 共通サービス標準仕様を参照して頂きたい。

（３）業務の観点からみた GIS 利用の今後
今回ご紹介したユースケースでは、「GIS 共通サービス標準仕様」の「GIS 共通サービスインタフェース」
をそのまま活用するということで、業務ユニット側からみれば、地図情報を補足的に利用する範囲に留まっている。実際の自治体では、各業務単位にて GIS を導入している実績はあるものの、費用対効果の面、および地図情報の具体的な活用の場面があまり出てこないという声もあり、なかなか自治体全体における統合的な GIS の導入や利用促進まで十分に至っていないのが実情であると考えられる。とくに、地図データの構築・維持にかかる費用に比べて、GIS 活用のメリットが小さいという声も聞かれる。
今回、GIS ユニットの GISDB（地名辞典、地図データ）については、各自治体にて構築済みであることを前提としているが、GIS を導入される自治体では、コスト面も含めて本 DB の構築・維持についての検討が非常に肝要である。地域情報プラットフォームでは、各業務ユニットに散在する位置に関する情報（住所情報など）が、業務ユニットがマルチベンダ環境である場合に（表記を含めた）統一が困難であることをも配慮し、位置に関する情報を最大公約数的に集約できる地名辞典という考え方を導入しているが、詳細については「GIS 共通サービスガイドライン」を参考として頂きたい。
一方、GIS の有効活用という観点では、例えば、地図データの表示・参照だけでなく、地図情報をベースにした、エリア別の人口分布・高齢世帯の分布状況・災害発生箇所と避難場所のルート探索など、様々な情報を解析・シミュレートし、その結果として複合的な観点から、例えば防災業務などの支援に強力に役立てるツールとして位置づけていくことが望まれる。さらに、広域災害での活用やコスト面を配慮した地図デー
タの統合的な管理を前提とすれば、単独自治体での利用ではなく、複数の隣接市町村、あるいは県レベルでの地図データ構築や GIS サービスの提供も考えられる。また、警察や消防などが所管する地図情報と連携し、防犯などのより高い住民サービスにつながる要素もあるというご意見も頂いている。
今後、地域情報プラットフォームとしての「GIS 共通サービス標準仕様」のさらなるサービスの拡張（地図上での計測機能など）の検討が予定されており、それを利活用した付加価値の高い業務サービス例の検討につなげていきたいと考えている。

－16－

地域情報プラットフォームガイドライン

４．２

自治体内ワンストップサービス、自治体間、官民連携サービスの検討

４．２．１ ワンストップサービスの考え方
地域情報プラットフォームを活用したワンストップサービスの実現を目指すにあたり、一般的なワンストップサービスの考え方と、地域情報プラットフォームにおけるワンストップサービスの考え方を示す。

４．２．１．１ ワンストップサービスとは
はじめに、一般的なワンストップサービスの定義を明確にする。
ワンストップサービスというと様々な利用例や提供形態の考えがある。本節では、ワンストップサー
ビスの考え方について整理し、併せてワンストップサービスの事例を記載する。
（１）ワンストップサービスとはワンストップサービスとは利用者が、一ヶ所もしくは一度の手続きで、必要とする関連作業を、一括して完了できるように設計されたサービス。
ワンストップサービスでは、従来は利用者に個別に提供されていたサービスを、組み合わせてひとつのサービスとして提供することにより、利用者に対して新たな付加価値を提供することが可能となる。
個別サービス（従来）利用者

ワンストップサービス

サービス提供者
サービス利用サービス

サービス利用

サービス

利用者

サービス
サービス
利用

サービス提供者
サービス利用図４．２．１

サービス提供者

新たな
付加価値

サービス

サービス
サービス提供者
サービス

従来の個別サービスとワンストップサービスのイメージ－17－地域情報プラットフォームガイドライン（２）ワンストップサービスの事例◆引越ワンストップサービス
住民が引越を行った場合、様々な申請・届出が必要となる。従来は、複数の申請先に対する複数の申請・届出をそれぞれに行う必要があったが、それらを一括して手続きできるようにするもの。

図４．２．２

従来の個別サービスとワンストップサービスのイメージ

引越と同様に、ライフイベントに沿って必要となる複数の申請・届出を一括して手続きできるようにしたワンストップサービスとして、以下のようなサービスが考えられている。
・

結婚手続き【婚姻届、国保の異動届、など】

・

出生手続き【出生届、児童手当認定申請、など】

・

退職手続き【社会保険（健康保険、年金）の資格喪失、給与所得者異動届、など】

これらのサービスについては、オンラインでの手続きだけでなく、自治体の総合窓口によるワンス
トップサービスも想定される。

－18－

地域情報プラットフォームガイドライン◆検索・照会のワンストップサービス
地域内を中心に、複数の照会先から、一括して情報を検索・照会できるサービス。
公立図書館の蔵書検索など、すでに実現されているサービスもある。
・

地域の図書検索サービス

・

地域の施設検索サービス

・

自治体手続等の案内サービス（受けられるサービスの検索など）◆すでに実現されているワンストップサービス
官、民ともに、いくつかのワンストップサービスがすでに実現されている。
また、官と民のサービスを組み合わせたプサービスも実現されてきている。
・

輸出入・港湾関連情報処理システム
・・・税関、関係行政機関及び関連民間業界をオンラインで連携

・

自動車保有関係手続きのワンストップサービス

・

東京電力引越しコンシェルジュ（東京電力他）

・

ジャパンネット銀行

JNB アグリゲーション

・・・金融機関の異なる複数の口座を一括管理できるサービス
表４．２．１

すでに実現されているワンストップサービス（例）の概要

サービス
輸出入・港湾関連情報処理

ポータル運営管理責任者
・

NACCS センター

自動車保有関係手続きの・OSS 推進警察協議会

ワンストップサービス

・

国土交通省

・

東京電力株式会社

システム（NACCS）

東京電力
引越しコンシェルジュ

サービス
提供者
官民
官のみ
民間のみ

サイト(URL)
専用ソフトを使用
http://www.oss.mlit.go.jp/portal/
http://www.tepore.com/
hikkoshi/
http://www.japannetban

ジャパンネット銀行
JNB アグリゲーション

k.co.jp/service/accoun
・ジャパンネット銀行

民間のみ

t/aggre/index.html（JNB アグリゲーション
の説明）

－19－

地域情報プラットフォームガイドライン

４．２．１．２ 地域情報プラットフォームにおけるワンストップサービスの考え方
前章で整理したワンストップサービスの考え方をふまえ、本章では、地域情報プラットフォームにおけるワンストップサービスの考え方を整理する。

（１）地域情報プラットフォームにおけるワンストップサービスのサービス区分
ワンストップサービスを、誰がどのようにサービスを提供するか、という観点で、3 つに大別する。
◆自治体サービス
あるひとつの自治体がサービス提供者となり、利用者に対して、サービスを提供する。
◆自治体間連携サービス
複数の自治体がサービス提供者となり、利用者に対してサービスを提供したり、自治体間でサービス連携することで、情報のやりとりを行ったりする。
◆官民連携サービス
官（自治体等の公的機関）が提供するサービスと、民（民間企業）が提供するサービスを組み合わせて、１つのワンストップサービスとして提供する。
利用者

自治体
自治体サービス
自治体サービス

自治体
ポータル

地域
ポータル

総合窓口

国

自治体サービス
自治体サービス
国・地方
国・地方
連携
連携
Ａ課

Ｂ課

本省・
地方局

Ｃ課

自治体サービス
自治体サービス
自治体間
連携サービス

自治体間
自治体間
連携サービス
連携サービス

自治体

自治体サービス
自治体サービス

官

自治体サービス
自治体サービス
官民
連携サービス

民間企業

民間サービス
民間サービス

図４．２．３

ワンストップサービスのサービス区分

－20－

民

地域情報プラットフォームガイドライン◆総合窓口サービスについて
本ガイドラインにおける「総合窓口サービス」の定義を、以下に記載する。
自治体の窓口サービスとは、自治体の窓口における、各種行政サービスに関わる対人的なサービス
であり、総合窓口サービスとは、これらの各種行政サービスを一個所で受け付け、必要な処理を行うことである。地域情報プラットフォームにおいては、総合窓口サービスの業務は、地域情報プラット
フォームを活用したシステムを利用することによって処理されるものと想定している。
総合窓口サービスの中で、利用者からの申請・届出を受け付ける場所が総合窓口である。本ガイド
ラインでは、この窓口は、自治体内に設置されているものと想定している。
利用者

自治体
総合窓口
引越申請

一括して
一括して
受付
受付

図４．２．４

各課に
各課に
申請情報
申請情報
を渡す
を渡す

Ａ課への
申請情報

Ａ課
各課から
各課から
処理結果
処理結果
を受け取る
を受け取る

Ａ課での
処理結果

Ｂ課への
申請情報

Ｂ課
Ｂ課での
処理結果

Ｃ課への
申請情報

Ｃ課
Ｃ課での
処理結果

地域情報プラットフォームにおける「総合窓口サービス」のイメージ

なお、従来、自治体の窓口の設置単位（一つの窓口の業務内容）は、自治体によって様々であり、
特に、住民票、戸籍、印鑑等のサービスは、同一の窓口で受け付けている場合もある。
しかし、ここで述べる総合窓口サービスは、従来の窓口の業務範囲を超えて、自治体内のすべてサービスが一つの窓口で受付可能となるようなものと考える。例えば、引越（転入）というライフイベン
トに対して、住民異動届に加えて、児童手当の認定申請といった福祉関連の手続きも、一つの窓口で受け付けられるものである。
また、本来の業務を含めて総合窓口で処理する場合もあるが、ここでは検討対象として、申請・届出の受付のみを行う窓口と定義し、本来の業務は各課（及び各課のシステム）で行うものとする。複数の業務を網羅した総合的な相談窓口も、対象外とする。

－21－

地域情報プラットフォームガイドライン（２）サービス形態の考え方
ワンストップサービスとして提供されるサービスの内容は様々であるが、大きくは「申請手続き型」「情報照会・検索型」の二つに分類することができる。
「申請手続き型」は、申請や届出を受け、決められた業務の流れに従って処理を行うサービス
であり、「情報照会・検索型」は、情報の要求を受け、複数のサービスから情報を取得し提供するサービスである。前者は、従来からの行政サービスの申請手続きがベースとなり、後者は、住民に対する新たなサービスの提供の可能性を含んでいるとも言える。サービスの実現に当たっては、これらのサービス形態の組み合わせによって総合的なワンストップサービスを提供する場合もあるが、「申請手続き型」のみ、「情報照会・検索型」のみ、といったサービス提供も想定される。
また、ワンストップサービスの導入において必要となる機能や、検討課題事項などは、これらのサービス形態によって異なるものと考えられる。
そこで、本ガイドラインでは、サービス形態を「申請手続き型」と「情報照会・検索型」に分けて記述する。以下に、それぞれの形態について、特徴や、サービス利用例を説明する。

① 申請手続き型
利用者が、複数のサービスに対する申請・届出を一括して手続きするもの。
【特徴】
・

利用者からの、申請や届出を受けて、処理の結果を返す。

・

ワークフローに従って、順次処理が行われる。

・

各業務ユニットで職員による作業が必要となる手続きでは、申請から結果通知という一つのワンストップサービスが完了するまでに時間がかかる場合もある。

【手続き例】
・引越、結婚、出生など、ライフイベントに沿って必要となる複数の申請・届出を、一括して行う手続き。

利用者

申請手続き型サービス
申請・届出
業務サービス
Ａ

結果通知

図４．２．５

業務サービスＢ

業務サービスＣ※ワークフローに従って処理が実施される。

申請手続き型サービスのイメージ－22－地域情報プラットフォームガイドライン② 情報照会・検索型
利用者が、一度に複数のサービスから情報を照会または検索できるもの。
【特徴】
・

利用者に対して必要な情報などを返す。

・

複数の業務ユニット（複数のサービス提供者の場合も含む）から、同時に情報を参照できる。

・

照会や検索要求に対して、即時に結果を返す場合もある。

【手続き例】
・

複数のサービス提供者や複数の業務で管理されている情報について、何かしらの観点で関連する情報をまとめて照会、検索する。
➢

地域の図書検索サービス➢

地域の施設検索サービス

利用者

情報照会・検索型サービス
業務サービスＡ
照会・検索

照
会
・
検
索

業務サービスＢ

業務サービスＣ

図４．２．６

情報照会・検索型サービスのイメージ

なお、他自治体への所得情報などのように、複数のサービスとの連携ではなく、一度の処理では、照会先や利用サービスがひとつの場合もあるが、各種条件によって異なる照会先に対して、同一の仕掛け、同一の作業で照会・共有可能となることから、地域情報プラットフォームではワンストップサービスとして整理する。

－23－

地域情報プラットフォームガイドライン（３）地域情報プラットフォームにおけるワンストップサービスの分類
前章までに整理したサービスの分類と、それぞれのサービス事例を表に示す。

サービス区分

サービス形態• 自治体の総合窓口サービス• オンラインによる引越（転入）ワンストップサービス≪自治体の手続き≫

申請手続き型自治体
サービス

自治体間連携
サービス

情報照会・
検索型

• 個人に関連する情報（資格情報、認定状況など）を表示
するサービス• 自治体内での、宛名情報の検索サービス• 自治体手続等の案内サービス（受けられるサービスの検索など）• 自治体の統計情報（人口動態等）を表示するサービス

申請手続き型• 港湾ＥＤＩシステム

• 自治体

情報照会・
検索型

申請手続き型
官民連携
サービス

サービス例

サービス提供者

情報照会・
検索型

• 自治体
• 自治体以外の
公的機関

• 自治体
• 自治体以外の
公的機関• 民間企業• 複数自治体の施設の空き状況検索サービス• 複数図書館の蔵書検索サービス• 自治体職員による、他自治体の住民であるかの照会• 自治体職員による、他自治体への所得情報の照会• オンラインによる引越（転入）ワンストップサービス≪自治体・民間の手続き≫• 口座の入出金や、引き落とし予定などを、民間、自治体から一括して取得して表示するサービス※ 地域ポータルなどの各種ポータルサービスには、「申請手続き型」「情報照会・検索型」の複合型もある。

－24－

地域情報プラットフォームガイドライン

４．２．２ ワンストップサービスの構築方法
本章では、ワンストップサービスの構築検討を実施する際に必要となる前提事項、留意事項、および実際の分析手法（定義手順）について述べる。なお、本章では、ワンストップサービスの形態として一般的である、「4.2.1.2(2)サービス形態の考え方」にて示した「①申請手続き型」について記載する。

４．２．２．１ ワンストップサービスにおける業務ユニットに必要な機能
申請手続き型のワンストップサービスは、「4.2.1.2(2)①申請手続き型」に示されるように、利用者からの申請を受付けた後、BPM を通しながら、業務処理が必要となる各業務ユニットへ渡って処理を順次進めていくという形態が一つの基本形である。（図４．２．７参照）
申請データ

I/F

：業務サービスインタフェース

地域ポータル（電子申請）

ＢＰＭ（ビジネスプロセス制御）
総合窓口（庁内電子申請）

I/F

I/F

I/F

I/F

I/F

I/F

I/F

I/F

業
務
ユ
ニ
ッ
ト
Ａ

業
務
ユ
ニ
ッ
ト
Ｂ

業
務
ユ
ニ
ッ
ト
Ｃ

業
務
ユ
ニ
ッ
ト
Ｄ

図４．２．７

ワンストップサービスにおける業務ユニット

地域情報プラットフォームでは、「自治体業務アプリケーションユニット標準仕様」にて、各業務ユニットに必要となる主な機能を提示しているが、今回のように、ワンストップサービスを実現するに当たり、BPM と業務ユニットが連携することが必要となる。
そこでまず、本章では、その場合に、業務ユニットに必要となる機能要素を明確にしておく。
ワンストップサービスにおいては、業務ユニット間の単純なデータ連携でなく、業務サービス（業務ユニットを構成する個々の業務処理機能）と BPM（ビジネスプロセス制御）機能との連携を実現する、業務
サービスインタフェース(*3)の実装が必要となる。その上で、業務ユニット側では、各種行政手続きの申請データを BPM から受け取り、当該業務処理を実行、そして、最終的にその処理結果を BPM へ送信する必要がある。

(*3)「自治体業務アプリケーションユニット標準仕様」で規定されている業務ユニット間のデータ連携インタフェースとは異なり、ワンストップサービスなどで業務サービスと BPM との間のサービス連携に必要となるインタフェースである。本章冒頭でも述べたが、各自治体における行政手続きの業務プロセスの考え方は非常に多種多様であり、それらを一つの標準として規定することは困難であることから、本インタフェースは規定していない。本章において、各自治体の現状に合わせたインタフェースを検討するための指針を示す。

－25－

地域情報プラットフォームガイドライン

ＢＰＭ（ビジネスプロセス制御）

業務サービスインタフェース

ＰＦ通信機能①③⑥（① 申請データがBPMより業務ユニットへ送られる）⑦② 申請データをBPMより受け取る機能
申請データを受領したという通知をBPMへ返す機能

業務サービスインタフェース（③ 受領したという通知が業務ユニットからBPMへ送られる）②受け取り ⑤結果通知機能機能④ 申請データにもとづいて業務処理を実施する機能（例．住民基本台帳の転入処理）（必要に応じて）持ち回りデータの参照とそれに応じた処理

業務ユニット⑤ 業務処理の結果をBPMへ送信する機能
ＢＰＭが結果通知を受領したという通知を受け取る機能

業務サービス④業務処理機能（⑥ 業務処理の結果が業務ユニットからBPMへ送られる）（⑦ 業務処理の結果を受領したという通知がBPMから業務ユニットへ送られる）

図４．２．８ワンストップサービスにおける業務ユニットの機能構成（例１）図４．２．８は、業務ユニットの中に、一つの業務サービスがあり、その中に「②受け取り機能」、「④業務処理機能」、および「⑤結果通知機能」が含まれているという一つの構成例(*4)であるが、ここでのポイントとしては、BPM と業務ユニットの関係において、業務ユニット側に最低限必要となる機能要素は、「受け取り機能」、および「結果通知機能」の二つであることを確認されたい。
※なお、図４．２．８は、BPM と業務ユニットのメッセージ交換パターンとしては、「プラットフォーム
通信標準仕様」にて定義されている「リクエスト・レスポンス型同期型受領 Ack＋非同期型レスポンス」
を例としているが、「リクエスト・レスポンス型同期型レスポンス」の場合であれば、図４．２．８における③と⑦が不要（①と⑥のみ必要）となり、かつ②は「申請データを BPM より受け取る機能」のみとな
り、⑤は「業務処理の結果を BPM へ送信する機能」のみとなる。
また、次章「（３）持ち回りデータの考え方について」にて述べるが、ワンストップサービス全体における処理の効率化を目的として、複数の業務ユニットにまたがって持ち回るデータ（例えば「識別番号」など）が申請データの中に格納されている場合には、その持ち回りデータを参照し、それに応じた処理(*5)
を実行させる機能などを、「④業務処理機能」の中にも含める必要がある。

(*4)業務ユニットと業務サービスの考え方については 4.2.2.2 節を参照のこと。
(*5)例えば、「識別番号」を参照して、該当の個人情報を、統合 DB へ検索に行く処理など。

－26－

地域情報プラットフォームガイドライン

なお、図４．２．８では、一つの業務ユニットの中に、「受け取り機能」や「結果通知機能」も含まれる構成を示したが、図４．２．９のように、その２つの機能と業務ユニットを分ける構成も考えられる。
この場合には、BPM と業務ユニットの間に、「受け取り機能」と「結果通知機能」のサービスを構築することになるが、この形態であれば、仮に「受け取り機能」や「結果通知機能」に改修が発生する場合でも、
業務ユニット側への影響は最小限に抑えられる。

ＢＰＭ（ビジネスプロセス制御）

業務サービスインタフェース

ＰＦ通信機能①③⑥⑦①～⑦は、図４．２．２と同様

業務サービスインタフェース

サービス②受け取り ⑤結果通知機能
機能

業務サービス
業務ユニット

図４．２．９④業務処理機能

ワンストップサービスにおける業務ユニットの機能構成（例２）

さらには、図４．２．９の形態の中に含まれるが、各自治体にて導入されている既存の業務システム（例えば汎用機システムなど）を、BPM と連携させることでワンストップサービスを構築するケースも想定される。その場合は、図４．２．10 の例で示すように、「受け取り機能」・「結果通知機能」を含んだサー
ビスと、既存の業務システムの間の連携方式として、ファイル転送や媒体・紙などによるやりとりが考えられるが、各自治体の既存の業務システムの形態に合わせて検討が必要である。

－27－

地域情報プラットフォームガイドライン

ＢＰＭ（ビジネスプロセス制御）

業務サービスインタフェース

ＰＦ通信機能①③⑥⑦①～⑦は、図４．２．２と同様

業務サービスインタフェース

サービス②受け取り ⑤結果通知機能
機能

ファイル転送、媒体渡し、紙ベースでのやりとり等
既存の業務システムの形態に合わせた方式。

④業務処理機能（既存の業務システム）

図４．２．10

ワンストップサービスにおける既存業務システムとの機能構成（例）

いずれにしても、地域情報プラットフォームでは、業務ユニットの機能構成については規定しないため、各自治体の業務システムの現状に応じて構築の検討を進めて頂くことになるが、申請手続き型のワンス
トップサービスを実現するに当たっては、少なくとも、前述の「受け取り機能」、および「結果通知機能」の二つを実装することが必要である。

－28－

地域情報プラットフォームガイドライン

４．２．２．２ サービスの考え方、粒度について
４．２．２．１節では、ワンストップサービスにおける業務ユニットの構成要素を考えるに際し、一つの業務ユニットの中に一つの業務サービスを含むモデルとして示したが、本来、業務ユニットと業務サービスの関係については下記の通り定義されている。
「業務サービスは、業務ユニットを構成する個々の機能をいう。」～「アーキテクチャ標準仕様」の「4.3 業務ユニット」より抜粋

つまり、一つの業務ユニットの中には、一つないしはそれ以上（複数）の業務サービスが含まれるものとなる。
ここでいう業務サービスとは、一つのまとまった業務処理である。業務サービスは様々な粒度で設計（定義）が可能であり、業務サービスの粒度や切り出し方には様々な考え方がある。
一般に、業務サービスの粒度は、業務変更が発生する単位を基準に、自己完結した独立可能な単位に設計（定義）することが望ましい。業務変更を行う際、粒度が大きい場合には業務サービスの組み替えだけで変化に対応することができず、反対に細かい場合には多くの業務サービスを組み替えなければならなくなる。
また、業務サービスの粒度を細かく設計（定義）すると再利用性は高まるが、極端に細かい業務サービスは、
インタフェースのやり取りが増えるためにサービス呼び出しの処理コストが高くなり、業務サービスの設計（定義）
・導入・保守のコストや障害の対策コストも増大する。
また、申請手続き型のワンストップサービスでは、業務ユニット内の一つ一つの業務処理は業務ユニットの責任において実行管理されるので、業務ユニットをまたがった業務処理の実行管理に主眼を置く必要があると考えられる。その様な場合、粒度の基本的な目安の一つとしては、「申請書の単位」が想定される。例
えば、住民基本台帳ユニットであれば、「異動（変更）」、「発行」といった比較的まとまった単位の場合、
あるいは、「世帯変更」、「住民票写しの交付」といったより細かな単位などが考えられる。
いずれにしても、地域情報プラットフォームでは、このようないわゆるサービスの粒度に関しては現時点においては規定しないため、「自治体業務アプリケーションユニット標準仕様」の「（業務１－４）機能一覧」や本ガイドラインの「４－ⅱ．各種定義体サンプル」などを参照し、各自治体における業務プロ
セスの形態に合わせて検討して頂きたい。逆に、これらの業務標準仕様やサンプルを参照し分析すること
により、各自治体の業務サービスの粒度についても自ずと整理されてくると考えられる。

－29－

地域情報プラットフォームガイドライン

図４．２．11 は、業務ユニット、業務サービス、および業務処理機能の構成イメージの一例であるが、一つの業務ユニットの中に複数の業務サービスが定義され、各業務サービスの中に一つずつ業務処理機能が定義されている形態である。例えば、業務ユニットが「住民基本台帳ユニット」、その中の一つの業務サービスが「異動（変更）」、さらにその中の一つの業務処理機能が「世帯変更」という定義が考えられるが、各自治体によって、それら業務サービスや業務処理機能の粒度が異なっても構わない。

ＰＦ通信機能I/F
I/F：業務サービスインタフェース

I/F

I/F

：業務処理機能：業務サービス

業務ユニット：業務ユニット

業務サービス
図４．２．11

業務サービスの構成例（１）－30－地域情報プラットフォームガイドライン

また、次の図４．２．12 のように、一つの業務サービスの中に、複数の業務機能を定義する形態も考えられる。

ＰＦ通信機能I/F
I/F：業務サービスインタフェース

I/F：業務処理機能：業務サービス

業務ユニット：業務ユニット

業務サービス

図４．２．12

業務サービスの構成例（２）

なお、参考ではあるが、ワンストップサービスの実現のために、４．２．２．１節にて述べた、「受け取り機能」・「結果通知機能」を実装する場合には、それらを一つのサービスとして定義し、業務ユニッ
トの中の各業務サービスと BPM とのやり取りを一括で担う形態が考えられる。（図４．２．13 参照）－31－

地域情報プラットフォームガイドライン

ＢＰＭ（ビジネスプロセス制御）

I/F

ＰＦ通信機能I/F：業務サービスインタフェース

I/F：受け取り・結果通知機能

サービス：業務処理機能業務ユニット

業務サービス
図４．２．13

ワンストップサービスにおける業務サービスの構成例

いずれにしても、ワンストップサービス構築におけるサービスの粒度や業務サービスインタフェースの定義・実装については、その考え方や手順を記載した次の４．２．２．３節を参照の上、各自治体の業務プロセスの形態や運用に合わせて検討されたい。

－32－

地域情報プラットフォームガイドライン

４．２．２．３ ワンストップサービスの連携定義手順※第４章（別冊） 「ワンストップサービスの連携定義手順」 を参照のこと。

－33－

地域情報プラットフォームガイドライン

４．２．３

自治体サービス

４．２．３．１ 地域情報プラットフォームにおける自治体サービスの考え方（１）自治体サービスの概要
自治体サービスとは、ある一つの自治体がサービス提供者となり、利用者に対して、サービスを提供することである。
自治体内の複数の申請・届出を一度に手続きする「申請手続き型」のサービスや、複数の業務ユニットで管理している情報を、一度に検索するといった「情報照会・検索型」のサービスが想定される。

（２）自治体サービスのサービス形態
自治体において、「申請手続き型」のサービスは、主に従来の申請手続きを元に構築されるワ
ンストップサービスである。
一方、「情報照会・検索型」のサービスは、特に住民向けのサービスとしては、これまであまり提供されてこなかった新たなサービスを創出するものであり、今後、住民サービスの付加価値向上につながるものと考えられる。

－34－

地域情報プラットフォームガイドライン（３）自治体サービスの記述範囲①サービス形態「申請手続き型」と「情報照会・検索型」のいずれについても、地域情報プラットフォームでは検討対象であるが、本章では、現状分析を元にした、ワンストップ構築の手順や、導入における各種課題の整理として、「申請手続き型」のサービスを記述対象としている。
なお、「情報照会・検索型」の課題等については、今後検討していく予定である。

②申請手続き型のサービスにおける記述範囲
自治体サービスの実現方法については、総合窓口サービスや、電子申請サービスなどが想定されるが、いずれの場合でも、申請データ受付後の、BPM 機能を中心としたサービス連携の仕組みは同様である。また、ポータルや総合窓口といった、ユーザインタフェース部分は自治体によって要件や実装方式が異なる部分であり、地域情報プラットフォームとしての共通的な検討はそぐわないと考える。
そこで、自治体サービスの課題等の記述においては、申請データ受付後の、BPM を中心としたサービス連携の仕組みを対象とする。
なお、業務ユニットについては、ユニット内の処理は検討対象外とし、サービス連携のインタ
フェースのみを記述対象とする。

申請手続き型サービス
利用者

オンライン
での手続き

ポータル

業務ユニットＡ

業務ユニットＢ

業務ユニットＣ

電子申請サービス
申請・届出情報

利用者

窓口
での手続き

自治体
総合窓口

ＢＰＭ機能

自治体
職員

自治体サービスにおける記述範囲

総合窓口サービス

図４．２．14

自治体サービスにおける記述範囲－35－

地域情報プラットフォームガイドライン

４．２．３．２ 自治体内ワンストップサービス導入における検討課題事項
これまで、ワンストップサービスの定義やその分析手順について述べてきたが、ここでは、申請手続き型のワンストップサービスを実際に導入する際に、各自治体において検討が必要となる主な事項について述べる。

（１）ワンストップサービスにおける受付機能・進捗結果通知機能・文書交付機能について
申請手続き型のワンストップサービスでは、住民が、地域ポータルや自治体ポータルなどから申請手続きを実施するいわゆる電子申請による受け付け、および庁内に設けられた総合窓口から申請手続きを実施
して受け付けるなどがあるが、いずれにしても送られてきた申請データを BPM へ流す前に、処理すべき事項がある。たとえば、申請者の本人確認をする機能であり、申請手続きへの受付番号を付ける機能であり、BPM へ流した後に必要となる業務処理の順番（シナリオ）の確定などである。（図４．２．15 参照）
申請データ① or ②

地域ポータル（電子申請）

ＢＰＭ（ビジネスプロセス制御）

受付機能
受付機能
I/F

業
務
ユ
ニ
ッ
ト
Ａ

本人確認、
本人確認、
申請手続きへの受付番号付番、申請手続きへの受付番号付番、業務処理（シナリオ）の確定など
業務処理（シナリオ）の確定など

図４．２．15

I/F

I/F

I/F

総合窓口
（庁内電子申請）

I/F

I/F

業
務
ユ
ニ
ッ
ト
Ｂ

業
務
ユ
ニ
ッ
ト
Ｃ

ワンストップサービスにおける受付機能①地域ポータルなどからの電子申請受付の場合に必要と想定される機能（例）・地域ポータルからの申請を受けられるようにするための利用者申請の機能・利用者申請を受けた際に、当該利用者へ ID を付番し登録する機能・利用者から実際に申請を受け付ける際に、その申請データを受理する機能・受理した申請手続きに、受付番号を付番し登録する機能
・申請者の本人確認機能（署名検証など）
・申請手続きの業務処理の順番（シナリオ）を確定し登録する機能②庁内の総合窓口からの申請受付の場合に必要と想定される機能（例）・申請者の本人確認機能（住登者であれば、当人の関連情報を検索する機能なども必要に応じて）・受理した申請手続きに、受付番号を付番し登録する機能・受理した申請手続きのデータを登録する機能
・申請手続きの業務処理の順番（シナリオ）を確定し登録する機能※なお、図４．２．15 では、「受付機能」が、地域ポータル／総合窓口と BPM との間に描かれているが、システムの実装においては、例えば、①であれば地域ポータルのシステム内、②であれば総合窓口システム内などへの実装が想
定される。

－36－

地域情報プラットフォームガイドライン

また、上記受付機能にて処理した申請データを BPM へ流した後は、同機能にて確定された業務処理の順番（シナリオ）に従って処理されていくわけであるが、申請者や窓口職員が、当該手続きの進捗状
況や結果を確認するために、それらの情報を自治体ポータルなどへ送信する機能、および総合窓口の職
員端末の画面などへ表示する機能などが必要となる。（図４．２．16 参照）
なお、申請手続きの状態を参照することが必要となる本機能の実現に当たっては、「プラットフォー
ム通信標準仕様」にて規定されている「メッセージの共通ヘッダ情報」を活用すること、また「アーキテクチャ標準仕様」および本ガイドラインの第３章「技術解説」の中で、運用モニタリング機能としても定義・紹介されているので参照されたい。

地域ポータル（電子申請）

進捗状況
進捗状況

③

ＢＰＭ（ビジネスプロセス制御）
I/F

I/F

I/F

総合窓口
（庁内電子申請）④
I/F

申請手続きの進捗状況や結果など
申請手続きの進捗状況や結果などを送信、必要に応じて画面表示など
を送信、必要に応じて画面表示など

図４．２．16

業
務
ユ
ニ
ッ
ト
Ａ

I/F

業
務
ユ
ニ
ッ
ト
Ｂ

障害発生
障害発生
I/F

業
務
ユ
ニ
ッ
ト
Ｃ

ワンストップサービスにおける進捗結果通知機能③BPM へ流した手続きの進捗状況や結果を受け取り、申請者が確認できるように、地域ポータルなどへ送信する機能④BPM へ流した手続きの進捗状況や結果を受け取り、窓口職員が確認できるように、窓口端末へ送信し、必要に応じて画面表示する機能－37－

地域情報プラットフォームガイドライン

また、申請手続きに伴う各種証明書などの交付文書を、最終的に申請者へ渡すべく、各業務ユニットからの交付物を総合窓口の職員などへまとめて提供する仕組みが必要となる。電子申請からの申請手
続きの場合には、郵送もしくは庁内窓口での交付となるが、庁内総合窓口からの申請手続きの場合には、申請者が待っている同じ総合窓口（自治体によっては証明書交付専用窓口）からまとめて交付することがワンストップサービス上必要不可欠であり、そのためには、総合窓口の端末へ PDF 形式などの電子デー
タとして送信、あるいは同じく総合窓口のリモートプリンタなどへ各業務ユニットから直接印刷するな
どの方式が考えられる。
（図４．２．17 参照）

地域ポータル（電子申請）

ＢＰＭ（ビジネスプロセス制御）
I/F

I/F

I/F

総合窓口
（庁内電子申請）

I/F

I/F

⑤

業
務
ユ
ニ
ッ
ト
Ａ

⑥

業
務
ユ
ニ
ッ
ト
Ｂ

I/F

業
務
ユ
ニ
ッ
ト
Ｃ

申請者

電子申請による申請の場合は、郵送
電子申請による申請の場合は、郵送や庁内窓口での交付。
や庁内窓口での交付。
総合窓口による申請の場合は、同じ総合窓口による申請の場合は、同じ総合窓口からの交付が必要。
総合窓口からの交付が必要。

図４．２．17

ワンストップサービスにおける文書交付機能⑤電子申請からの申請者へは、各業務ユニットからの交付文書をまとめて、郵送または庁内窓口での交付を実施することになるため、それを担当する窓口などへまとめて提供する機能（または運用）。
⑥総合窓口からの申請者へは、同じ総合窓口からまとめて交付できるように、総合窓口の端末な
どへ PDF などの電子データにて送信する機能、あるいは各業務ユニットから直接、総合窓口のリモー
トプリンタなどへ印刷する機能

申請手続き型の自治体内ワンストップサービスを構築するに際し、検討が必要となる主な３つの機能について述べたが、いずれも、各自治体の業務・運用形態や窓口体制等と合わせて検討されたい。
また、機能の検討ではないが、とくに総合窓口などの検討では、各自治体での職務分掌規程や文書管理規程なども踏まえ、交付物の取り扱いや職員配置も含めた検討が必要である。
なお、同ワンストップサービスの仕組みの主となる、BPM と各業務ユニット間のサービス連携に関する検討事項（分岐・シナリオの判定、後続業務へのデータ受け渡し、エラー処理など）については、次節以降に記載する。
－38－

地域情報プラットフォームガイドライン（２）分岐・シナリオの判定について
業務のフローには、様々な分岐（業務担当者やシステムが状態を判断し、その後の作業を選ぶ処理）がある。ここでは、次の様な分岐の考え方について説明する。
・申請内容による分岐・前の処理の結果による分岐
なお、本項は地域情報プラットフォームとして分岐の考え方について規定するものではない。分岐の考え方は非常に多種多様であり、標準として規定することは困難であることから、本項にて検討に必要となる事項を提示することする。自治体においては、導入の際に必要に応じて個別に検討し、最適な方式を採用されたい。
また、フローの制御に関しては、「プラットフォーム通信標準仕様」の「４．プラットフォーム通信標準のビジネスプロセス制御定義仕様」を併せて参照のこと。
◆申請内容による分岐申請手続き型のワンストップサービスでは、利用者からの複数のサービスに対する申請・届出を一括して手続きを行うが、各サービスは必ずしも常に実行されるものでは無く、利用者からの申請内容により必要なサービスを選択して実行することがある。例えば、転入に伴う住民基本台帳の転入業務と国民健康保険の保険資格取得業務のワンストップサービスを考えた場合、転入業務は必ず実施されるが、保険資格取得業務は利用者の申請が有った場合のみ実施される。
分岐の判断
申請内容により必要なサービスを判断する処理は、手続きの数が多い場合や手続きに様々な前提条件がある場合、一般に、対象業務の業務知識やノウハウに基づく業務的な判断を必要とする。この様な場合、システムで分岐判断を行うと処理が複雑になる為、分岐判断を人手により行うことも考えられる。
なお、本項では分岐判断の方法については具体的に規定しない。分岐判断の方法はワンストップ
サービスの内容により異なる為、自治体においては、導入の際に必要に応じて個別に検討し、最適な方式を採用されたい。
BPM 機能を中心としたサービス連携の仕組みでは、分岐判断を行う所としては以下が考えられる。
・ポータルや総合窓口の受付機能（システムまたは人手）・BPM 機能・業務サービス（システムまたは人手）
受付機能

BPM 機能申請情報

分岐

業務サービス

図４．２．18

BPM 機能を中心としたサービス連携の仕組みにおける機能構成－39－

地域情報プラットフォームガイドライン

ポータルや総合窓口の受付機能での分岐判断は、例えば、利用者が主体的に対象となる手続きを選択する方法や、システムや窓口職員のナビゲーションにより対象となる選定する方法が考えられる。また、担当課職員の業務知識やノウハウを必要とする場合など受付機能で分岐判断を行うのが難しい場合には、受付機能ではなく、業務サービスで判断を行うことが考えられる。
BPM 機能での分岐判断は、BPM 機能では木目細かいフローの制御は出来ず、また、人手の処理を直接的に処理することは出来ない為、複雑な分岐判定には適していない。複雑な分岐判定は受付機能や業務サービスで行い、BPM 機能内では簡単な処理を行うことが望ましい。
業務サービスでの分岐判断は、対象業務の知識をもつという面では適している。しかし、手続きを行わない場合にも業務サービスへ依頼が行われるので効率が悪い。受付機能で分岐判定を行える
場合には受付機能で行うことが望ましい。
分岐制御の方法（受付機能で分岐判断する場合）
ここでは、分岐制御の一つの１つの考え方として、受付機能で分岐判断する場合における分岐制
御の方法について説明する。
なお、本項では分岐制御の方法については具体的に規定しない。分岐制御の方法は非常に多種多様な方法が考えられ、標準として規定することは困難であることから、本項にて分岐制御の方法の一案を提示することする。自治体においては、導入の際に必要に応じて個別に検討し、最適な方式を採用されたい。
BPM 機能を中心としたサービス連携の仕組みでは、業務サービスの呼び出しなどを含むフローの制
御は BPM 機能で行う為、受付機能で分岐判断した後、受付機能から BPM 機能に処理を流す際に、分岐の為の情報を引き渡す方法が考えられる。
（ⅰ）

（ⅲ）

受付機能内では、申請内容にBPM 機能内では、分岐情報をより必要なサービスを判断する。

参照して、フローの制御を行う。

受付機能

BPM 機能
申請情報

分岐
分岐情報

（ⅱ）

業務サービス

受付機能から BPM 機能に
分岐情報を引き渡す。

図４．２．19

申請内容による分岐の分岐制御の方法（受付機能で分岐判断する場合）

この方法では、以下の規定が必要となる。
・受付機能から BPM 機能に分岐情報を引き渡す為のインタフェース
・分岐情報に基づく BPM 機能の動作（振る舞い）－40－

地域情報プラットフォームガイドライン

受付機能から BPM 機能に分岐情報を引き渡す為のインタフェースについては、プラットフォーム
通信仕様においてメッセージの共通ヘッダ部分に「ビジネスプロセス制御情報」が定義されている。
（詳細については、「プラットフォーム通信標準仕様」の「７．プラットフォーム通信仕様におけるメッセージ共通ヘッダ仕様」を参照のこと。）

受付機能から BPM 機能に分岐情報を引き渡す場合、共通ヘッダの「ビジネスプロセス制御情報」に値をセットする方法がある。また、この他の方法としては、本文などの共通ヘッダ以外の業務メッセージの値でフローの制御を行う方法が考えられる。
分岐情報に対する BPM 機能の動作（振る舞い）については、「ビジネスプロセス(BP)のフロー制御に関する規定」及び「WS-BPEL の適用範囲、制約に関する規定」が定義されている。
（詳細については、同標準仕様の「４．プラットフォーム通信標準のビジネスプロセス制御定義仕様」を参照のこと。
）
分岐情報の内容
ここでは、分岐情報の一つの考え方として、以下の分岐情報について説明する。
・各分岐の分岐先を示す情報（例：

図 4.2.20）

・BPM 機能に定義されたシナリオ（業務処理の具体的な流れ）を示す情報（例：

図 4.2.21）

なお、本項では分岐情報の内容については具体的に規定しない。分岐情報の内容は非常に多種多様な方法が考えられ、標準として規定することは困難であることから、本項にて分岐情報の内容の一案を提示することする。自治体においては、導入の際に必要に応じて個別に検討し、最適な方式を採用されたい．

BPM 機能内では、分岐情報にある
各分岐の分岐先を参照して、フローの制御を行う。
従って、フローの制御を行う
フローの制御を行う。
受付機能

BPM 機能

分岐情報
分岐識別

分岐先

① 業務サービ スＡの呼び出し

1 呼び出す② 業務サービ スＢの呼び出し

0 呼び出さない

図４．２．20

分岐①

分岐②

業務サービス

業務サービスA

B

受付機能から BPM 機能に渡す分岐情報のサンプルモデル（１）各分岐の分岐先を示す情報の例－41－

地域情報プラットフォームガイドライン

シナリオの論理的な定義
シナリオ識別AB

BPM 機能内では、分岐情報のシナリオ識別を

シナリオ定義分岐識別① 業務サービ スＡの呼び出し② 業務サービ スＢの呼び出し

分岐先
1 呼び出す0 呼び出さない① 業務サービ スＡの呼び出し② 業務サービ スＢの呼び出し

1 呼び出す1 呼び出す参照して、予め定義されたシナリオ定義に従い、フローの制御を行う。
従って、フローの制御を行う
フローの制御を行う。
受付機能

分岐情報
シナリオ識別A

図４．２．21

BPM 機能分岐①

分岐②

業務サービス

業務サービスA

B

受付機能から BPM 機能に渡す分岐情報のサンプルモデル（２）BPM 機能に定義されたシナリオ（業務処理の具体的な流れ）を示す情報の例
なお、ワンストップサービスの内容により手続きの種類や数は異なり、必要となる分岐情報の数は未知数である為、分岐情報のデータ形式は拡張性のある形式が望ましい。
また、申請情報により呼び出す業務サービスが決まる場合などは、BPM 機能において申請情報の有無を確認することにより、特別な分岐情報を用いずに、フローの制御を行う方法も考えられる。

－42－

地域情報プラットフォームガイドライン◆前の処理の結果による分岐申請手続き型のワンストップサービスでは、業務処理に順序性がある場合、ある業務処理の結果により別の業務処理の実行が変化することがある。例えば、転入に伴う住民基本台帳の転入業務と国民健康保険の保険資格取得業務のワンストップサービスを考えた場合、申請の不備等の何らかの事由により転入業務処理の結果が異常であった場合には保険資格取得業務は行われない。
BPM 機能を中心としたサービス連携の仕組みでは、業務サービスの呼び出しなどを含むフローの制
御は BPM 機能で行う為、前の処理の結果による分岐判断を行う為には、業務サービスから BPM 機能に対して、処理の結果情報が引き渡される必要がある。
（ⅱ）
BPM 機能内では、処理の結果情報より分岐を判断して、フローの制御を行う。

して、フローの制御を行う。
BPM 機能分岐

処理の結果情報業務サービスA

業務サービス（ⅰ）
業務サービスから BPM 機能に

B

処理の結果情報を引き渡す。

図４．２．22

前の処理の結果による分岐の分岐制御の方法

この方法では、以下の規定が必要となる。
・業務サービスから BPM 機能に処理の結果情報を引き渡す為のインタフェース
・処理の結果情報に基づく BPM 機能の動作（振る舞い）
業務サービスから BPM 機能に処理の結果情報を引き渡す為のインタフェースについては、プラッ
トフォーム通信仕様においてメッセージの共通ヘッダ部分に「結果情報」が定義されている。
（詳細については、「プラットフォーム通信標準仕様」の「７．プラットフォーム通信仕様におけるメッセー
ジ共通ヘッダ仕様」を参照のこと。
） 業務サービスから BPM 機能に処理の結果情報を引き渡す場合、共通ヘッダの「結果情報」に値をセットする方法がある。また、この他の方法としては、本文などの共通ヘッダ以外の業務メッセージの値でフローの制御を行う方法が考えられる。
なお、処理の結果情報とては、例えば、「正常終了」と「異常終了（データなしの場合を含む）」のステータスを示す 0、1 の二値の情報が考えられる。
処理の結果情報に基づく BPM 機能の動作（振る舞い）については、「ビジネスプロセス(BP)のフロー制御に関する規定」及び「WS-BPEL の適用範囲、制約に関する規定」が定義されている。
（詳細については、同標準仕様の「４．プラットフォーム通信標準のビジネスプロセス制御定義仕様」を参照
のこと。
）
－43－

地域情報プラットフォームガイドライン（３）後続業務へのデータ受け渡しの考え方について申請手続き型のワンストップサービスでは、業務処理に順序性がある場合、ある業務で作成される情報の一部が別の業務で必要になることがある。例えば、転入に伴う住民基本台帳の転入業務と国民健康保険の保険資格取得業務のワンストップサービスを考えた場合、転入業務と保険資格取得
業務には順序性があり、保険資格取得業務では転入業務で作成される住基情報を必要とする。
この様な場合、一般的には、後に行う業務は自身の業務の開始に先立ち、当該情報を保有する業務に対して問合せを行い、情報を取得することが一般的である。しかし、後の業務で必要となる情報が分かっている場合には、先に行う業務が後に行う業務に対して、予め、情報を送り出すことにより、業務の効率化が図られることが期待される。
ここでは、後続の業務へのデータ受け渡しの考え方について説明する。
なお、データ交換システムパターンに関しては、本ガイドラインの「３．１．２

SOAP 通信と通信モデル」を併せて参照のこと。

利用者

自治体

申請書

申請情報

申請情報

業務ユニットＡ
業務ユニットＡで作成される情報の一部

ポータル／
総合窓口

業務ユニットＢ
処理結果

図４．２．23

処理結果

ワンストップサービスにおける後続業務への情報の受け渡し

BPM 機能を中心としたサービス連携の仕組みでは、後続業務へのデータ受け渡し方法として、二つの方法が考えられる。尚、プラットフォーム通信におけるデータ交換システムパターンに関しては、
本ガイドラインの「３．１PF 通信機能」を参照のこと。

方法 A) 必要な情報全てが BPM 機能を介してデータ交換を行う
方法 B) BPM 機能を介したデータ交換と、業務ユニットインタフェースによるデータ交換を行う－44－

地域情報プラットフォームガイドライン

方法 A) 必要な情報全てが BPM 機能を介してデータ交換を行う
方法 A は、比較的シンプルな方法である。情報は BPM 機能を介してデータ交換を行う。この方法
は、自治体業務アプリケーションユニット標準仕様で規定されていない業務や業務標準のインタフェースで規定されていない情報のデータ交換を行う場合に適している。
BPM 機能（ⅰ） BPM 機能は、業務サービス A に処理を依頼する。
（ⅱ） 業務サービスＡは、BPM 機能に処理結果を回答する際に、当該情報を含んだ情報を送る。
（ⅲ） BPM 機能は、業務サービス B に処理を依頼する際に、

（ⅰ）

（ⅱ）

業務サービス A から受け取った情報を含んだ情報を

（ⅲ）

情報

送る。

業務サービス

業務サービスAB

図４．２．24

後続業務へのデータ受け渡し方法 A

方法 B) BPM 機能を介したデータ交換と、業務ユニットインタフェースによるデータ交換を行う
方法 B は、業務サービス A に業務サービス B が必要とする情報の業務ユニットインタフェースがある場合に用いることができる。この方法では、リファレンス情報（業務ユニットインタフェース
を用いてデータ交換を行う際に問合せのキーになる情報）のみを BPM 機能を介してデータ交換を行
い、情報の全体は業務ユニットインタフェースを用いてデータ交換を行う。例えば、先の転入に伴う住民基本台帳と国民健康保険の業務の例では、住民基本台帳ユニットと国民健康保険ユニットの間には住基情報の業務ユニットインタフェースがある為、このインタフェースの問合せのキーとなる識別番号のみ BPM 機能を介してデータ交換を行うことが考えられる。
BPM 機能（ⅰ） BPM 機能は、業務サービス A に処理を依頼する。
（ⅱ） 業務サービス A は、BPM 機能に処理結果を回答する際に、当該情報のリファレンス情報を含んだ情報を
送る。

（ⅰ）

（ⅱ）

業務サービスリファレンス情報（Ⅵ）（ⅲ） BPM 機能は、業務サービス B に処理を依頼する際に、（ⅲ）

業務サービス A から受け取ったリファレンス情報を含

業務サービスAB（ⅳ） 業務サービス B は、BPM 機能から受け取ったリファレ
ンス情報をもとに、業務サービス A に問合せを行い、情報（本体）
図４．２．25

んだ情報を送る。

情報を受け取る。

後続業務へのデータ受け渡し方法 B－45－

地域情報プラットフォームガイドライン

BPM 機能（ⅰ） BPM 機能は、住民基本台帳ユニットのサービスに処理を依頼する（転入の申請情報を送る）。
（ⅱ） 住民基本台帳ユニットのサービスは、転入業務を行い、住民を指す識別番号を付番した後、BPM 機能に処理結

（ⅰ）
（ⅱ）
識別番号
転入の
申請情報
（Ⅵ）

（ⅲ）

保険資格取得の申請情報

住民基本台帳国民健康保険

ユニット

ユニット
住基情報

果を回答する際に、識別番号を含む情報を送る。
（ⅲ） BPM 機能は、国民健康保険ユニットのサービスに処理を依頼する（保険資格取得の申請情報を送る）際に、住民基本台帳ユニットから受け取った識別番号を含んだ情報を送る。
（ⅳ） 国民健康保険ユニットのサービスは、BPM 機能から受取った識別番号をもとに、住民基本台帳ユニットに問合せを行い、住基情報を受け取る。

図４．２．26

後続業務へのデータ受け渡し方法 B の利用例（イメージ）

方法 A と方法 B を比較すると、方法 B は方法 A に比べてメッセージ通信の総回数は多いが、データ量の多い情報を含むメッセージ通信の回数は少なくなる為、メッセージ通信の情報量を減らす効果がある。
表４．２．２

方法 A

後続業務へのデータ受け渡し方法のメッセージ通信回数の比較（二業務間の場合）

必要な情報全てが BPM 機能を介してデータ交換

キー情報等の情報（本体）を含む

データ量の少ない情報を含む

データ量の多い情報を含む

メッセージ通信の回数

メッセージ通信の回数

ー

2回

2回

1回

を行う
方法 B

BPM 機能を介したデータ交換と、業務ユニットインタフェースによるデータ交換を行う

なお、後続業務へ受け渡すデータの内容とインタフェースは、ワンストップサービスの業務内容により異なる為、各自治体のワンストップサービスの業務内容に合わせて検討が必要である。また、検討においては、方法 B のリファレンス情報は複数のデータを受け渡す場合も考慮が必要である。

－46－

地域情報プラットフォームガイドライン（４）異常系処理の考え方について
ワンストップサービスではサービスの可用性が重要視される為、障害の対処は極めて重要である。
ビジネスプロセスの実行途中で何からの異常が発生した場合、現在の処理を中断又は中止して別の処理を行う必要がある。何を持って「異常」とするかは様々であるが、例えば、次の様なものを挙げることができる。
・ハードウェアの故障
・OS 等のソフトウェアの設定ミス
・業務システム（業務アプリケーション）の不具合
・操作者の操作ミス･･･

不適切なデータの入力、不適当な処理の実行、等

ここでは、異常系処理の考え方について説明する。
なお、異常系処理に関しては、本ガイドラインの「３．８メッセージ交換パターンと異常系処理」を併せて参照のこと。
BPM 機能を中心としたサービス連携の仕組みでは、異常系処理は業務サービスと BPM 機能の二つの範囲に大別して考えることができる。
業務サービスの範囲：
BPM 機能の範囲

サービスが呼出された後、BPM に対して正しく結果を回答するまで。

： ビジネスプロセスの開始から終了まで。
業務サービスとの連携部分は、サービスの呼出の処理まで。

－47－

地域情報プラットフォームガイドライン◆業務サービスにおける異常系処理
業務サービスは、BPM 機能からプラットフォーム通信にて呼び出されるサービスであるため、障害の対処はプラットフォーム通信における対応と同様の考え方ができる。つまり、業務サービスには、
業務サービス内で障害が発生した場合、障害を検知し、可能な限りサービスの呼び出し元である BPM
機能に通知することが求められる。

利用者

自治体
申請・届出
業務サービス
Ａ

結果通知

業務サービスＢ

業務サービスＣ

ＢＰＭ機能

BPM 機能内では、分岐情報にある
各分岐の分岐先を参照して、フローの制御を行う。
従って、フローの制御を行う

自治体

フローの制御を行う。
受付機能

BPM 機能図４．２．27

業務サービス

業務サービスA

B

ワンストップサービスにおける障害対処に関する範囲の考え方

なお、業務サービスから BPM 機能への障害通知には幾つかの方法が考えられるため、地域情報プ
ラットフォームでは障害通知の方法に関しては規定しない。ワンストップサービスを導入する自治体において障害通知の具体的方法に関して検討が必要である。
なお、プラットフォーム通信におけるエラー時の対応処理に関しては、プラットフォーム通信標
準仕様の「６．プラットフォーム通信における MEP とエラー時の対応処理」を参照のこと。

－48－

地域情報プラットフォームガイドライン②BPM 機能における異常系処理
BPM 機能には、BPM 製品に備わっている運用監視の機能・ツール等により、BPM 機能内で発生した障害を検知するとともに、業務ユニットから通知された障害情報を BPM 機能内の障害情報にエスカ
レーションし、BPM 機能のオペレータ等に障害情報を通知することが求められる。
利用者

自治体
障害発生

障害発生

業務サービス
Ａ
障害通知

障害発生

業務サービス
Ｂ

障害通知

業務サービス
Ｃ

障害通知

障害発生

ＢＰＭ機能
障害通知

オペレータ等図４．２．28

ワンストップサービスにおける障害対処に関する範囲の考え方

なお、障害の対処は全て自動化されることが理想ではあるが、適切な処理を講じなかった場合に副次的な問題の発生や事態の複雑化を避ける為に、自動化された処理ではビジネスプロセスの停止・中断迄を実施し、その後の一連の回復処理については全て手動で対応することが推奨される。
なお、異常系処理手順における補償・回復処理の考え方に関しては、本ガイドラインの「３．８メッセージ交換パターンと異常系処理」を参照のこと。

－49－

地域情報プラットフォームガイドライン（５）ワンストップサービスにおける申請メッセージ様式について
これまでは、利用者からの申請を受け付けた後の処理において、検討すべき事項を述べてきたが、受け付ける前、つまり利用者からの申請様式に関しても、申請手続き型のワンストップサービスでは、検討が必要である。
地域ポータルなどを利用した電子申請では、利用者がその申請内容を入力する入力様式や送信する申請
データのメッセージ様式などが対象であり、庁内の総合窓口では、窓口職員が（利用者の）申請内容を入力する入力様式や、同様に送信する申請データのメッセージ形式などである。
（図４．２．29 参照）①－１①－２ 申請データ

地域ポータル（電子申請）

ＢＰＭ（ビジネスプロセス制御）

受付機能
受付機能
総合窓口
（庁内電子申請）②－１

I/F②－２ 申請データ

I/F

I/F

I/F

業
務
ユ
ニ
ッ
ト
Ａ

I/F

I/F

業
務
ユ
ニ
ッ
ト
Ｂ

業
務
ユ
ニ
ッ
ト
Ｃ

①－１
①－１ 利用者が申請内容を入力する部分（入力様式）
利用者が申請内容を入力する部分（入力様式）①－２①－２ 送信する申請データ（メッセージ様式）
送信する申請データ（メッセージ様式）②－１②－１ 窓口職員が（利用者の）申請内容を入力する部分
窓口職員が（利用者の）申請内容を入力する部分②－１②－１ 送信する申請データ（メッセージ形式）
送信する申請データ（メッセージ形式）

図４．２．29

ワンストップサービスにおける申請様式の検討

上述の①－１や②－１に相当する、利用者や窓口職員が申請内容を入力する部分である、入力・確認画面などの実装部分については、各自治体ごとに地域ポータルや総合窓口システムの設計の中で検討されたい。
一方、①－２や②－２の申請データのメッセージ様式については、申請先団体が受け取るメッセージ様式の考え方を統一しておくことで、各業務ユニットとの（BPM を経由した）サービス連携の容易な実現、さらには今後の自治体間や官民間に渡るサービス連携へも拡張が容易になると考えられる。
申請データのメッセージ様式については、ワンストップサービス上、利用者から一度に複数の申請手続
き（たとえば、転入届出と国保加入届出など）が実施されることが想定され、複数の申請書の申請データ
項目を一つにまとめたいわゆる「シングル（統合）様式」の XML と、それぞれの申請手続き（申請書）ごとに該当申請データ項目を持つ「マルチ様式」の XML が考えられる。（図４．２．30 参照）※なお、図４．２．29 では、「受付機能」が、地域ポータル／総合窓口と BPM との間に描かれているが、システムの実装においては、例えば、地域ポータルのシステム内や総合窓口システム内などへの実装が想定される。

－50－

地域情報プラットフォームガイドライン

申請書様式のイメージ（例）
申請書様式のイメージ例②：複数の申請手続きを、1つの申請書にまとめたもの

申請書様式のイメージ例①：申請手続き単位に分けたもの

引越届（１／２）

転入届
申請者氏名
旧世帯主氏名
異動者氏名
住民票コード

国保加入届
申請者氏名
被保険者記号番号
異動者氏名
退職被保険者氏名

引越届（２／２）

児童手当認定請求申請者氏名（共）申請者氏名

旧世帯主氏名（転）異動者氏名（共）児童の同居別居区分

被保険者記号番号（国）住民票コード（転）異動者氏名

児童の同居別居区分（児）退職被保険者氏名（国）支払金融機関（児）支払金融機関（共）：共通申請項目（転）：転入届の固有項目（国）：国保加入届の固有項目（児）：児童手当認定請求の固有項目

申請書データのメッセージ様式（例）①シングル（統合）様式のＸＭＬ②マルチ様式のＸＭＬ
<転入届>
転入届>
<申請者氏名>
申請者氏名>>
申請者氏名>情報 太郎</
太郎</申請者氏名<旧世帯主氏名>
旧世帯主氏名>>
旧世帯主氏名> 情報 太郎</太郎</旧世帯主氏名<異動者氏名>>情報 太郎</>太郎</異動者氏名><住民票コード>
住民票コード>>住民票コード>1234567890</
1234567890</住民票コード</転入届></転入届><国保加入届>><申請者氏名>
申請者氏名>>
申請者氏名>情報 太郎</
太郎</申請者氏名<被保険者記号番号>
被保険者記号番号>>
被保険者記号番号>1234567890</
1234567890</被保険者記号番号<異動者氏名>>情報 太郎</>太郎</異動者氏名><退職被保険者氏名>退職被保険者氏名>>退職被保険者氏名>情報 花子</
花子</退職被保険者氏名</国保加入届>></<児童手当認定請求>><申請者氏名>
申請者氏名>>
申請者氏名>情報 太郎</
太郎</申請者氏名<児童の同居別居の別>児童の同居別居の別>1 </児童の同居別居の別>児童の同居別居の別><異動者氏名>>情報 太郎</>太郎</異動者氏名><支払金融機関>
支払金融機関>>支払金融機関> 地域銀行</
地域銀行</支払金融機関</児童手当認定請求>
>
</

<引越届>
引越届>
<申請者氏名>
申請者氏名>>
申請者氏名>情報 太郎</
太郎</申請者氏名<住民票コード>
住民票コード>>住民票コード>1234567890</
1234567890</住民票コード<被保険者記号番号>
被保険者記号番号>>
被保険者記号番号>1234567890</
1234567890</被保険者記号番号<児童の同居別居の別>児童の同居別居の別>1</児童の同居別居の別>児童の同居別居の別><異動者氏名>>情報 太郎</>太郎</異動者氏名><住民票コード>1234567890</
住民票コード>>住民票コード>1234567890</住民票コード<退職被保険者氏名>退職被保険者氏名>>退職被保険者氏名>情報 花子</
花子</退職被保険者氏名<支払金融機関>
支払金融機関>>支払金融機関> 地域銀行</
地域銀行</支払金融機関</引越届></引越届>

図４．２．30

ワンストップサービスにおける申請データのメッセージ様式（例）

ここでポイントとなるのは、繰り返しになるが、物理的な紙（申請書）の様式や入力画面様式ではなく、申請先団体へ送られる申請データのメッセージ様式である。
「４．２．２

ワンストップサービスの構築方法」でも述べたが、各業務ユニットが BPM から受ける

申請データのメッセージ様式（業務サービスインタフェース）については、その業務サービスの粒度も含めて、「自治体業務アプリケーションユニット標準仕様」の「機能一覧」を参照の上、各自治体にて検討する必要があり、そこでの検討対象としては、下記の理由から、「マルチ様式」を推奨する。
・各申請手続きの申請データ（申請書）については、原則として各業務ユニット側にて原本管理する必要が想定されるため、全ての申請データを一つに統合したものではなく、各業務ユニットに必要な申請
データのみをまとめたものが、情報保護の観点からも推奨される。
・「自治体業務アプリケーションユニット標準仕様」の「DFD」などでは、利用者から申請手続きごとの申請データが各業務ユニットに流れる処理を表現しているが、「マルチ様式」では、その流れ（申請デー
タ）とほぼ同様のため、ワンストップサービスにおける各業務ユニットとの接続も比較的容易である。
その他、必要に応じて、申請データへの署名とその検証方法、さらには申請書の原本管理方法に関しても、各自治体の方針に沿って検討されたい。

－51－

地域情報プラットフォームガイドライン【コラム】情報照会・検索型のワンストップサービスについて
ここまでは、申請手続き型のワンストップサービスを中心に述べてきたが、「４．２．１．２（２）サービス形態の考え方」にて定義した、情報照会・検索型のサービスについて少し触れておきたい。
一般的にワンストップサービスといえば、利用者からの申請手続きの流れをベースとした、申請手続き型のサービスを思い浮かべる割合が大きいと想定されるが、情報照会・検索型は、オンラインによる情報系サービスとして、様々な住民サービスの付加価値を創出していく形態であると考えられる。

ＤＭＺ←ー

②

自治体Ａ

②
自治体
ポータル

業務Ｘ

①

業務Ｙ

①

ＢＰＭ（ビジネスプロセス制御）

業
務
ユ
ニ
ッ
ト
Ｘ

業務Ｚ

業
務
ユ
ニ
ッ
ト
Ｙ

業
務
ユ
ニ
ッ
ト
Ｚ

インターネット①子供が生まれたとき、自分の個人情報を入力し、自分が受けられる
行政サービスを自宅から検索・確認。

②自分が受けられる行政サービスが③役所窓口へ出向き、

わかれば、申請すべき手続きを選択し、仮申請を自宅から実行。

本人確認の上、正式申請を実行(*)。

申請手続き型

情報照会・検索型

図４．２．31(*)各業務ユニットでは、すでに仮受付済みのため、利用者は窓口で本人確認するのみで、直ちに正式処理を実行可能。
業務の効率化と待ち時間の短縮に！

情報照会・検索型サービスの活用（例）図４．２．31 は、情報照会・検索型と申請手続き型を組み合わせたワンストップサービスの例である。利用者側の出生イベントにより、自分自身がそれによって受けられる行政サービスを、自宅の PC などから検索・確認し、その結果に従って、申請する手続きについて「仮申請」を（同じくPC から）行なう。前者が、情報照会・検索型、後者が申請手続き型のサービスに相当する。その後、役所の窓口へ出向き、本人確認の上、正式申請を実施する。すでに仮申請済みのため、各業務ユニッ
トでは直ちに正式処理を実行でき、業務の効率化や（利用者の）待ち時間の短縮につながる。
このように、情報照会・検索型サービスは、申請手続き型サービスと組み合わせることによっても、現実的かつ利便性の高いサービスを実現することが可能となり得る。
また、情報照会・検索型サービスでは、上記の例などでは、個人（利用者）の識別番号をキーと－52－

地域情報プラットフォームガイドライン

して、関連する個人情報を各業務ユニットから検索・取得するインタフェースが必要となるが、これは、「自治体業務アプリケーションユニット標準仕様」で規定した「業務ユニットインタフェース」
をそのまま活用し易いという利点もある。
本ガイドラインの４．２．１．２（３）の表にも、情報照会・検索型サービスの事例を示しているが、申請手続き型とは異なり、新たな住民サービスの創出に適していることから、自治体におかれても今後の前向きな検討が期待される。

－53－

地域情報プラットフォームガイドライン

４．２．４

自治体間連携サービス

４．２．４．１ 地域情報プラットフォームにおける自治体間連携サービスの考え方（１）自治体間連携サービスの概要
自治体間連携サービスとは、複数の自治体がサービス提供者となり、利用者に対してサービスを提供したり、自治体間でのサービス連携によって情報のやりとりを行ったりすることである。
複数の団体への申請を一度に手続きする「申請手続き型」のサービスや、複数の団体で管理している情報を一度に検索したり、団体間で情報照会を行う、といった「情報照会・検索型」のサービスが想定される。

（２）自治体間連携サービスのサービス形態「申請手続き型」、「情報照会・検索型」のそれぞれについて、連携のパターンを整理する。

①「申請手続き型」の連携パターンア） ワークフロー型

図４．２．32 ワークフロー型の連携イメージ【特徴】

ある公的機関での処理後に、別の公的機関での処理を実施する。

【手続き例】
・

前住所地の所得証明書を取得して、現住所地の市町村への児童手当申請時に添付する。
（1 月 1 日に別の市区町村に居住している場合）－54－

地域情報プラットフォームガイドラインイ） 通知・報告型

公的機関Ａ

公的機関Ｂ
通知書類、報告書類等
図４．２．33【特徴】

通知・報告型のイメージ

公的機関での処理の結果を、他の公的機関に通知、または報告する。

【手続き例】
・

住民基本台帳法 9 条 2 項通知

・

外国人異動に伴う外国人登録原票の送付

・福祉行政報告例の提出②「情報照会・検索型」の連携パターンア） 照会型【特徴】

他の公的機関の情報を照会する。

【手続き例（照会型）】
・

1 月 1 日時点の居住自治体への所得照会

・

ナンバープレート（車体番号など）の確認

照会型は、さらに文書照会型とデータ検索型に分けられる。
イ－１

文書照会型

図４．２．34【特徴】

文書照会型のイメージ

他の公的機関に照会依頼を行い、回答を受け取る。
（回答側に職員作業が発生）

イ－２

データ検索型

図４．２．35【特徴】

データ検索型のイメージ

他の公的機関のデータに直接検索を行い、情報を取得する。
（回答側の職員作業は不要）－55－

地域情報プラットフォームガイドラインイ） 情報集約型

図４．２．36【特徴】

情報集約型のイメージ

複数の公的機関の情報を集約する。

【手続き例】
・

自治体 A と自治体 B の施設の空き状況を、一括して検索する。

－56－

地域情報プラットフォームガイドライン（３）自治体間連携サービスの記述範囲①サービス形態「申請手続き型」と「情報照会・検索型」のいずれについても、地域情報プラットフォームでは検討対象であるが、利用者からみた場合、自治体への手続きについては、主に居住している自治体に対して行う場合が多く、複数の自治体への手続きを一度に行うという要件は、あまり多くないと想定される。
一方、団体間の情報照会業務は従来でも行われていることから、本章では、「情報照会・検索型」のサービスを記述対象としている。
なお、「申請手続き型」の課題等については、今後検討していく予定である。

②連携対象
地域情報プラットフォームでは、自治体等の公的機関が他の公的機関と連携することを、「官官連携」と定義し、検討対象としている。ただし、本章では、まず自治体同士の連携に対象を絞り記述する。なお、国・地方連携については、内閣官房にて別途標準化検討などが行われている。

図４．２．37

自治体間連携サービスの記述範囲－57－地域情報プラットフォームガイドライン

４．４．２

自治体間連携サービスの検討課題事項（１）ネットワークインフラとサービス連携形態
自治体間連携サービスにおいて、自治体を相互に接続するネットワークインフラは何かということが課題となるが、現在すべての自治体に導入されている総合行政ネットワーク(LGWAN)を基本に考えることが現実的である。LGWAN は全ての都道府県・市区町村を高いセキュリティのネットワーク
で結ぶもので、電子自治体の基盤となるべく整備されたものである。特に、不特定多数の自治体間、
あるいは全国規模で自治体間連携サービスを実現しようとする場合、LGWAN を前提に考える必要がある。
なお、地域で固有にネットワークが存在するケースもあるが、自治体間連携サービスが一定の地域で閉じたものであれば、これらの地域のネットワークの活用も考えられる。また、公共施設予約サービスなどで、自治体職員以外の指定管理者などが実際にサービス提供（を代行）している場合、
LGWAN には触れないというケースもあり、その場合には LGWAN 以外のインターネットや専用線などの方法の検討が必要となる。
ここでは、LGWAN 利用を前提とした場合の課題事項を記述する。なお、自治体内や自治体間での業
務サービスの連携を実現する上で検討が必要となる、自治体ネットワークインフラの課題については、第 3.4.4 節にまとめて記載しているため、参照されたい。
① 基幹 LAN 上の業務ユニットから自治体間連携サービスをさせようとする場合の課題調査によれば、LGWAN は自治体内の基幹 LAN と接続されていないケースが多いとのことであるが、その場合は基幹系の業務ユニットが LGWAN 経由で自動的に連動するようなサービス連携は実現できないことになる。サービスを LGWAN に接続できる場所に配置する等の対応が必要になる。なお、後期高齢者医療において、広域連合とのデータ連携に LGWAN を利用している団体では、基幹システムとの間では、媒体利用による連携がほとんどであったが、最近では、その頻度や容量などの関係で、必要なセキュリティ措置を講じた上で、基幹 LAN と LGWAN をネットワーク接続している例も出てき
ている。

ＬＧＷＡＮ

自治体Ａ

自治体Ｂ

LGWANサービス提供設備
LGWANサービス提供設備

業
業
務
務
ユ
ユ
ニ
ニ
ッ
ッ
ト
ト

LGWANサービス提供設備
LGWANサービス提供設備

業
業
務
務
ユ
ユ
ニ
ニ
ッ
ッ
ト
ト

×
つながっていない
ためにＬＧＷＡＮと連携できない

庁内LAN

基幹LAN
図４．２．38

LGWAN と基幹 LAN－58－

地域情報プラットフォームガイドライン② LGWAN 上で自治体間サービス連携する形態についての課題
LGWAN 上では、アプリケーションサービスを提供する仕組みとして、LGWAN－ASP という方式が存在する。この形態を利用することで、自治体間でのサービス連携を構築することが可能であると考えられる。
自治体の外側にサービスを提供する ASP(Application Service Provider)を立ち上げて、これを介して自治体間サービス連携を実現することになる。以下の図のように多数の自治体で共同のアプ
リケーションサービスを利用する場合は、非常に効果的であると思われる。
この場合、一定の地域、県、国などの範囲で共通的な業務処理のしくみを共同で検討し構築することが必要である。また ASP をどのように運営するかが大きな課題である。なお、公共の共同 ASPの立ち上げとともに、民間 ASP との接続について、民間機関とのビジネスという別セグメントでの検討も想定される。

Ａ市

B市

自治体間のサービスは、特定の２団体だけではそのメリットも限定的
B市

A市

C市

多数の自治体間でそれぞれ個別に連携する状況は極めて非効率
D市

E市

共同でＡＳＰを立ち上げることによって、多数の自治体間で同じサービスを共有することができる
ＡＳＰセンタは任意の規模で設置できる

図４．２．39

ASP
A市

E市
B市

C市

自治体間サービスにおける共同 ASP

－59－

D市

地域情報プラットフォームガイドライン（２） 自治体間連携サービスを自動処理で行う場合
従来の自治体業務においては、自治体間の連携は「通知業務」「照会業務」が中心であるので、間に職員が介在しても支障はなく、システムが自動的に連携処理を行うようなニーズは少ないと思われる。しかし今後新しい自治体間連携サービスが登場すると、職員が介在しないで自動的にデータを取り出してくるようなサービス連携も必要になる可能性がある。その場合、自治体間で特定の対象者（個人等）を識別（ひも付け）する方法の検討が必要になる。
ある自治体の内部では、その自治体固有の番号体系の下に番号を付番して管理しているが、他の自治体ではまた異なる管理をしているので、両者の間で対象者を直接同定できる情報は無い。
同一の対象者をひも付けして連携できるようにする必要がある。このような使い方が許される全国共通の管理番号は現在のところ存在しないが、今後は必要に応じて対応方法を検討していくことが望まれる。

自治体Ａ

自治体Ｂ
自治体ＢにおけるＡさんのデータを取得するケース

自治体Ａの番号管理体系

自治体Ｂの番号管理体系
自治体Ａにおける識別番号をキーとして自治体Ｂのデータは取得できない

×
Ａさん識別番号：3587426

Ａさん識別番号：1234567

図４．２．40

自治体間連携サービスにおける自動処理に必要なキー情報（例）－60－

地域情報プラットフォームガイドライン【コラム】自治体間、官民連携サービスのこんなサービスがあったなら？
地域情報プラットフォームによるワンストップサービスを実現すると、複数の団体に対して、情報の検索や手続を一括して行えるようになる。このようなサービスについては、自治体のみ、民間企業のみという限定された範囲では実現されている場合もあるが、官民が連携するものや、情報検索から手続までを一括して行えるようなサービスは、まだ実現されていないのが現状である。
そこで、現状では実現されていないが、今後利便性向上に役立つのではないかと思われるサービスの例を紹介してみたい。
◆子育てポータルサービス

図４．２．41

子育てポータルサービスのイメージ

子育てに関しては、手当等の支援制度に関する各種手続や、子供のための様々な用品購入などが必要になる。子育てポータルは、そのようなニーズに対して、さまざまな情報やサービスを一元的に提供するポータルである。
このポータルサービスによって、利用者はそれぞれのニーズに応じた情報を取得したり、サービスを利用できるようになる。また、サービスを提供する側にも、購買チャネルが増える、情報発信が効率的に行えるといったメリットが想定できる。
このように、ある特定の利用者や利用目的に沿って、情報照会・検索型サービスと申請手続き型を組み合わせたり、官と民間を連携したりすることによって、利用者にとってもサービス提供者にとっても、価値の高いサービスが実現できると考える。

－61－

地域情報プラットフォームガイドライン◆介護情報共有サービス

自治体

情報の連携

介護情報共有サービス

介護支援事業者（地域包括支援センター）
介護サービス事業者
介護サービス事業者
介護サービス

住民（要介護者・要支援者）

図４．２．42

介護情報共有サービスのイメージ

自治体が、地域の住民に対して適正な介護サービスが提供されているかを管理するためには、地域の介護サービスの状況を、常に把握している必要がある。
しかし、現状では、事業者間の情報の受け渡しが紙で行われているなど、効率的な情報連携が行われていない場合がある。
そこで、地域情報プラットフォームによって、自治体と介護事業者を連携することで、スムーズな情報の受け渡しが行えるようになり、ひいては、要介護者、要支援者への適切な介護サービス提供へとつながることが期待できる。

－62－

地域情報プラットフォームガイドライン

４．２．５

官民連携サービス

４．２．５．１ 地域情報プラットフォームにおける官民連携サービスの考え方（１）官民連携サービスの概要
官民連携サービスとは、官（公的機関）と、民（民間企業）がサービス提供者となり、利用者に対して、サービスを提供することである。
複数の団体への申請を一度に手続きしたり、複数の団体で管理している情報を一度に検索する、といったサービスが想定される。

（２）官民連携サービスのサービス形態
住民のライフイベントでは、多くの場合、行政への申請・届出だけでなく、電気、ガス、水道、銀行などのさまざまな届出等が必要となる。これらは、主に従来の申請手続きを元に構築される
ワンストップサービスであるが、行政と民間の申請･届出等を一括して手続き可能とすることで、住民の利便性が飛躍的に向上するものと考えられる。
さらに、「申請手続き型」と「情報照会・検索型」のサービスを組み合わせることによって、新たなサービスを創出することが可能となる。

図４．２．43

官民連携サービスのイメージ－63－地域情報プラットフォームガイドライン（３）官民連携サービスの記述範囲①連携対象
地域情報プラットフォームでは、サービスの提供者について、官と民間を想定している。
これまでに整理した、「官官連携」「官民連携」以外に、民間企業のみが提供するワンストップ
サービスを「民民連携」と定義する。
「民民連携」のサービスは、現時点で実現されているサービスも存在するが、本ガイドライン
では、官のサービスが含まれる場合（「官官連携」「官民連携」）を記述対象としている。
なお、「官官連携」「官民連携」のいずれについても、現時点では業務サービスインタフェースを規定していない。今後、ワンストップサービスの導入や、サービス拡張に伴って標準化が進められるものと考える。

図４．２．44

本ガイドラインの記述範囲－64－地域情報プラットフォームガイドライン

４．２．５．２ 官民連携サービスの検討課題事項（１）本人確認について
本人確認という行為は、官民を問わず、日常生活の様々なシーンで実施されている。例えば、自治体業務では、申請・届出等の手続きにおいて、本人確認が必要となる手続きがある。また、民間では、商取引において取引相手の信用の為に本人確認が行われる。
本人確認とは、対象が確かに「その人」であることを確認することであり、通常、本人しか持ち得ないものを確証（裏付け）として、確認することにより行われる。
本人確認の内容は本人確認の目的により異なるが、一般に、本人確認には以下の要素が含まれる。
本人性の確認･･･

利用者が確かに利用者本人であるか

実在性の確認･･･

利用者が実在するか

また、本人確認の目的によっては、本人確認と同時に、対象が持つ資格等の属性や、一定の事実の確認を行う場合がある。
本人確認のレベル（確からしさ）は、本人確認の方法と確証（裏付け）に用いる情報の組合せにより異なる。
本人確認の方法と確証（裏付け）に用いる情報の組合せは様々であるが、例えば次のようなものを挙げることができる。
（A） 窓口等において、対面により行う（B） 書類の郵送により行う（C） オンライン（ネットワーク）で行う
方法

確証（裏付け）情報

確認内容
例

A

B

1

公的証明書（写真付き）※顔写真との照合を行・パスポート

本人性

実在性

可

可

推測可

可

う

・自動車運転免許書

2

公的証明書（写真無し、本人のみが所持するもの）

・健康保険証3

公的証明書（写真無し、本人以外が入手可能なもの） －

不可

可

1

公的証明書のコピー

推測可

可

推測可

推測可

・パスポートのコピー
・健康保険証のコピー

C

2

受付後に住所地に送付したものの返戻

・照会文書

1

電子証明書（電子署名）

・公的個人認証サービス

*1

*1

2

受付時にオンライン認証（利用者認証）

・ＩＤ／パスワード認証

*2

*2

3

受付後に電子メール・アドレスに返戻

－

不可

不可

*1：電子署名は、電子文書に付与する電子的な徴証であり、紙文書における印やサイン（署名）に相当する役割をはたすものである。主に署名・押印が要求される電子文書（申請書類、届出書類など）のやりとりを伴うオンライン・オフライ
ン手続において、電子文書の作成者のなりすまし、電子文書の改ざん、電子文書の作成者の否認の防止の為に用いられる。このため、本人確認の推測は可能であるが、その本人確認のレベル（確からしさ）は電子証明書の認証機関及び電子証明書の用途により異なる。
*2：オンライン認証（利用者認証）は、ログイン認証とも呼ばれ、機器やシステム、サービスを利用するためのアクセス許可（基本的に、電子文書のやりとりを伴わない）を要求するオンライン手続において、機器やシステム、サービスの利用者のなりすましを防止する為に用いられる。本人確認の可否は、認証に用いる情報や情報の管理･運用方法等により異なる。

表４．２．３

本人確認の方法と確証（裏付け）による本人確認のレベル（確からしさ）の例－65－

地域情報プラットフォームガイドライン

厳格な本人確認は、確証（裏付け）に写真付きの公的証明書を用いて、窓口等において対面にて本人の顔と確証の顔写真を照合することにより本人性の確認が行われる。また、より厳格な場合には、確証（裏付け）に記載された情報の他に、住民基本台帳等への照会が行われる手続きもある。
オンラインでは対面による本人確認は不可能であるため、厳格な本人確認を必要とする手続きはオンラインのワンストップサービスには適さない。
また、本人確認に、顔写真との照合を行う程のレベル（確からしさ）が必要ない場合には、一般に、
公的個人認証サービス等の電子証明書による電子署名による方法が用いられる。公的個人認証サービ
スは広く用いられているため、有力な方法である。しかし、公的個人認証サービスでは署名検証は認定認証事業者を除き民間企業は実施できないため、署名検証者の人格には考慮が必要である。また、団体が利用者となる場合には考慮が必要である。
また、厳格な本人確認は確証（裏付け）となるものを準備する必要があり、利用者の利便性を損ねたり、サービス提供者の運用面等の負荷を高める。そのため、手続きにおける本人確認の厳格性に適した本人確認の方法を検討する必要がある。本人確認の厳格性が低い場合には、ＩＤ／パスワード等の簡易な方法を用いることを検討することが望ましい。

－66－

地域情報プラットフォームガイドライン（２）地域ポータルについて
地域ポータルは、一般的に、都道府県や市区町村といった地域レベルにおいて、その地域の住民や企業等に対して、様々な情報発信やサービスの提供を行なう Web サイトとして捉えられる。利用者にとっては、インターネット上での手続きが一度で完了し、従来のように関連機関の窓口へ出向いたり書類の作成などの手間が最小限で済むという利点、一方、申請受付業者にとっても、申請書チェックなどの簡略化など事務効率化の面で利点が大きい。

Ｂ市

Ａ市
従来のイメージﾌﾟﾗｯﾄﾌｫｰﾑを活用した官民連携ｲﾒｰｼﾞ

市役所

転出手続き等

転出手続き等

使用停止

使用開始

使用停止

市役所

使用開始・開栓

電気

電気
使用停止
使用開始・開栓
使用料等
残額清算

ガス

ガス
使用料等
引落手続

ポータル
水道

銀行

水道

住所変更
郵便転送届等銀行

郵便局

図４．２．45

官民連携サービスにおけるポータルのイメージ

住民のライフイベントの大半は、行政サービスだけでなく、電気・ガス・銀行といった様々な
民間サービスが関係することから、地域ポータルも、官民連携ポータルとして統合された形態となることで、住民の利便性が飛躍的に向上する。その一方で、「個人認証方法」、「個人情報保護の関連」、「連携するデータセットの標準化」、および「ポータルサイトの運営方法」といった点について検討が必要となる。とくに、ポータルサイトの運営方法については、誰が主体となって運営し、その収支構造（ビジネスモデル）はどのようにするかといった観点での検討が必要であるが、官民の多様なサービスを提供する場合では、自治体がその運営主体となるには多くの制約があると考えられる。

－67－

地域情報プラットフォームガイドライン【コラム】東京電力株式会社様 移転連絡ワンストップサービス「引越れんらく帳」
官民連携ポータルでは、様々なサービスの提供が考えられるが、住民にとっては、「引越し」という
ライフイベントにおける行政サービスや民間サービスを一度にまとめて手続きできることは、その利便性の向上に大きく貢献する。現状では、行政サービスに関しては、電子申請に関する法制約等のため実現には至っていないが、民間サービスに関しては、様々なポータルサイトによるサービスが実現されつつある。
その中で、東京電力株式会社が提供しているポータルサイト「移転連絡ワンストップサービス・引
越れんらく帳」を簡単にご紹介したい。
（従来） 同じような移転連絡手続きを繰り返している。
Ａ電力会社
Ｂガス会社
Ｃ水道
ＮＨＫ
Ｘ銀行、Ｚカード会社

・・・（引越れんらく帳） インターネットを活用した引越手続きワンストップポータルで一括。
東京ガス
・氏名
・引越元住所
・引越先住所
他必要事項を入力！

東京電力（株）様
ワンストップ・ポータル「引越コンシェルジェ」

水 道●引越れんらく帳●引越れんらく帳

放送（ＮＨＫ）

クレジット会社

インターネット

http://www.tepore.com/hikkoshi/renraku/
図４．２．46

東京電力（株）様

引越れんらく帳のイメージ

損害保険会社・・・

図４．２．46 にあるように、従来は、引越をする住民が、住所変更などで関連する民間機関へそ
れぞれ連絡を取って手続きを行なっていたが、引越れんらく帳では、一度、氏名・引越先住所などの必要事項を登録すれば、あとは関連する民間機関へ当該情報を送ってくれるサービスである。さらに、移転元や移転先の住所情報から、手続きが必要と想定される民間事業者を検索する一種のナ
ビゲーション機能も提供している。住民からすれば非常に利便性が高いサービスであり、インター
ネットのさらなる普及に伴い、今後も利用者が増えていくと思われる。
引越れんらく帳は、民間サービスに限定されているが、今後、このようなワンストップ・ポータ
ルに、行政サービスとの連携が実現されてくると、本当の意味での引越ワンストップ・ポータルに近づくこととなり、利用者の利便性のさらなる向上が期待される。
－68－

地域情報プラットフォームガイドライン

付録４－ⅰ

付加価値サービスのサンプル

本節の各種定義体サンプルは、ＡＰＰＬＩＣのホームページを参照ください。

－69－

地域情報プラットフォームガイドライン

付録４－ⅱ

地域情報プラットフォームの利活用

地域情報 PF を導入(検討)するとともに、共通的、汎用的な利活用を想定した様々なサービス（付加価値サービス群）を整備・検討していくことは、（当該 PF の要件に定義されていない）個々の課題達成をも実現し、将来における PF の有効な利活用にも繋がるものである。

４－ⅱ．１ 付加価値サービス群の例
以下に、地域情報 PF の利活用促進及び自治体内での課題（多様化する住民ニーズへの対応、コストの削減）達成の観点から、整備することが有効と考えられる付加価値サービスを例示する。
表４．ⅱ．１
共通サービスの例

総合的に証明書類を発行する
サービス

基
盤
系
共
通
サ
ー
ビ
ス
の
例

汎用 EUCサービス

共通職員情報サービス

コンテンツ管理サービス

付加価値サービスの例
概要／利活用例[概要]
個々の業務ユニットが発行する各種証明書や各種帳票について、総合的に発行及びその制御を実施するサービス。
統合 DB 機能の利活用で実現することも可能。
[利活用例]
・ 証明書自動交付機（住民票,印鑑登録証明,納税証明,戸籍,附票など）
・ 総合的な証明書発行窓口（支所窓口,公民館,郵便局,病院,駅,コンビニエンスなど）[概要]
個々の業務ユニットが提供するインタフェース（提供データ）及び統合
DB が管理するデータを利活用することで、業務従事者等が自らそのデータの統計分析を実現できるようにするサービス。
[利活用例]
・ 従来のオフィスツール（表計算,クライアント DBMS 等）で実施していた各種統計や分析等の代替
・ 情報システム部門や既存ベンダ等に作成依頼していた汎用帳票等の作成代替（業務担当原課でのスポット帳票の作成等）[概要]
従来、個々の業務ユニットが管理していたシステムユーザー及び各種権限情報の一元管理等を実現するサービス。当該サービスによって、ガバナ
ンスの確立及び重複投資の排除等が期待できる。
[利活用例]
・ 地域情報 PF（サービス基盤層）でのトラステッド職員ソースの確立
・ 共通管理が可能である組織や役職等属性の一元管理
・ 職員認証／認可基盤への応用[概要]
ファイルサーバやグループウェア等に散々している各種電子ファイル（オフィス文書,マルチメディアファイル等）の一元管理等を実現するサービス。
[利活用例]
・ 共通的、汎用的な共通電子ファイルリポジトリの構築による行政ミド
ルオフィス業務や運用管理業務の効率化、ナレッジ共有の促進
・ 情報漏えい等セキュリティ／コンプライアンス対策の強化－70－

地域情報プラットフォームガイドライン

業
務
系
共
通
サ
ー
ビ
ス
の
例

横断的検索
サービス

[概要]
個々の業務ユニットや統合 DB、その他システム等に散々している各種情報（構造化データ,非構造化データ）を横断的に検索・表示するサービス。
[利活用例]
・ 職員等（ユーザー）が入力するキーワードを元に、各々の権限に応じた対象範囲の情報を一括検索（情報へのアクセス及び業務の効率化を実現）

統合運用管理サービス[概要]
各種バックアップやリカバリ、ソフトウェア構成管理、プラットフォー
ムの更新プログラム(OS のパッチセット等)管理等の機能を提供するサービス。
[利活用例]
・ 個々の業務ユニット、統合 DB 等バックアップの自動実行処理、記録管理
・ 各種警告（CPU,ストレージ,ミドルウェア等）を運用管理者へ自動通知

住民情報取得
サービス

共同利用系
サービス
例：課税情報サー
ビスなど[概要]
個々の業務ユニット等が管理している各種住民情報の横断的な検索及び住民を中心とした統合的な情報（検索結果）抽出を実現するサービス。
[利活用例]
・ 総合窓口やコンシェルジェ業務等における住民情報端末
・ 非定時業務（災害,選挙等）における住民情報の検索[概要]
個々の業務ユニット毎に実装している各種機能の内、他の業務ユニット
でも利活用可能な部分を共通化するサービス。
重複機能排除による効率化、柔軟性の向上、コスト削減等が期待できる。
[利活用例]・ 複数の業務ユニットが持つ類似処理の共通化
・ 法制度改正時の対応（プログラム変更箇所の局所化）－71－地域情報プラットフォームガイドライン

付録４－ⅲ

各種定義体サンプル

本節の各種定義体サンプルは、ＡＰＰＬＩＣのホームページを参照ください。

－72－

地域情報プラットフォームガイドライン

付録４－ⅳ

ワンストップサービス実現に向けた個人情報取り扱いの考え方

４－ⅳ．１ 背景と課題検討の方向性について
地域情報プラットフォームの標準仕様が普及することで、地域に存在する様々な民間サービスや行
政サービスを相互に連携し、より利便性の高いワンストップサービスを実現することが期待されている。
一方で、そうした高度な地域サービスを利用者側が安心して活用できるようにするための環境整備も重要である。

昨今の個人情報の取り扱いに関する情勢を踏まえると、ワンストップサービスの利用者それぞれの個人情報が複数のサービス提供者間でどのように利用・管理されるのか、といったことが明示されなければワンストップサービス自体の利用促進にはつながらないと考えられる。
そこで本節では、ワンストップサービス実現にむけ検討が必要となる個人情報の取り扱いに係る制度の整理、制度的要件および課題検討の方向性を示す。
【ワンストップサービス検討における方向性】
・「住民サービスを向上させるための個人情報の利用」と、「個人の権利利益保護の必要性」という二つの観点を考慮した制度的・技術的な要件を踏まえ、ワンストップサービスを実現する必要がある。ただし、本節では制度的な要件や課題を中心に整理する。技術的な課題解決方法については、本ガイドラ
インの第３章 技術解説 ３．５ PF 共通機能 認証・認可・セキュリティを参照されたい。
※注： 制度的な要件については、内閣府や総務省および一般文献等に示されている法の解釈や運用基準を参考とした。ただし、地域情報 PF が構想するワンストップサービスへの個別具体的な要件適用については、法の解釈や運用基準を別途、専門的見地を踏まえ詳細検討する必要がある。
本資料は、そうした今後の具体的・発展的な課題解決にむけ、参考として位置づけられたい。

４－ⅳ．２ 個人情報の取り扱いに関連する法・制度体系概要（１）法律2005 年（平成 17 年）4 月 1 日に下記に示す主要な法律が 3 つ施行された。
個人情報の保護に関する法律（平成 15 年法律第 57 号）：
・一般個人情報保護法とも呼ばれる。政府部門と民間部門、両方に関係する個人情報取り扱いの基
本法的な内容を規定するとともに、民間部門における個人情報取り扱いの一般ルールを規定している。

行政機関の保有する個人情報の保護に関する法律（平成 15 年法律第 58 号）：
・行政機関個人情報保護法とも呼ばれる。国の行政機関が保有する個人情報の取り扱いのルールの基本を規定している。

－73－

地域情報プラットフォームガイドライン

独立行政法人等の保有する個人情報の保護に関する法律（平成 15 年法律第 59 号）：
・独立行政法人等個人情報保護法とも呼ばれる。独立行政法人等が保有する個人情報の取り扱いについて基本的なルールを定める。

なお、個人情報保護法の違反があった場合には、当該事業者に直ちに罰則が課せられるものではなく、主務大臣の判断の下、通例、報告の徴収・助言（法第 32 条、第 33 条）、勧告（法第 34 条第 2 項、第 3項）といった措置を経て、初めて罰則が適用される仕組みとなっている。i※ 福祉の分野においては、個人情報保護法とは別に、個別法（児童福祉法、社会福祉法、知的障害者福祉法、精神保健及び精神障害者福祉に関する法律、生活保護法等）に個人情報保護に係る規定がおかれている。
※ 個別法の個人情報保護規定は、対象を個人情報取扱事業者に限定していないから、個人情報取扱事業者に該当しない事業者に対しても法的拘束力を有することになる。
（２）事業分野毎のガイドライン
2007 年（平成 19 年）5 月 31 日時点で、事業等を所管する各省庁において、22 分野について個人情報の取り扱いに係る 35 のガイドラインが策定されている。これら事業分野毎のガイドラインの詳細については、本資料の最後に参考情報として整理する。
ただし、こうした事業分野ごとのガイドラインは、事業者による自主的な取組が強く期待されるものの、ガイドラインに示される規定の不遵守によって個人情報保護法で定める罰則が課されるものではな
い。ii
（３）条例
地方公共団体が保有する個人情報の取り扱いについては、地方公共団体が独自に定める個人情報保護条例によって規定される。それらの条例について、個人情報保護法第 5 条では、「地方公共団体は、この法律の趣旨にのっとり、その地方公共団体の区域の特性に応じて、個人情報の適正な取り扱いを確保するために必要な施策を策定し、及びこれを実施する責務を有する。
」と基本方針を示している。 iii
上記の地方公共団体が個人情報の適正な取り扱いを確保する上で必要な施策とは、地方公共団体が各々保有する個人情報の施策のほかに、区域の事業者が保有する個人情報の保護に関する施策を含む。
iv

2007 年（平成 19 年）4 月現在、全国の都道府県（計 47 団体）および市区町村（計 1827 団体）において、個人情報保護条例が制定済み(全地方公共団体における制定率は 100％)である。v－74－

地域情報プラットフォームガイドライン（４）地域情報プラットフォームのワンストップサービス概念と法制度の関連
地域に存在する様々な民間サービスや行政サービスを連携してワンストップサービスを実現する際に、考慮すべき法律、事業分野毎のガイドライン、そして条例を整理すると下記の図のようになる。

図４．ⅳ．１ 個人情報保護に関連する法制度と地域情報 PF を踏まえた
ワンストップサービス概念の相関図

４－ⅳ．３ 個人情報の取り扱いに係る要件整理の対象範囲（１）個人情報とは
現行の個人情報の保護に関する法律が保護の対象としている個人情報とは、個人の識別性を要件としている（法第 2 条第 1 項）。つまり、個人情報であるか否かの判断が求められる対象情報により、特定の個人が識別される情報を原則非公開とする規定を設けて、個人の権利利益を守ろうとする方針である。

－75－

地域情報プラットフォームガイドライン

表４．ⅳ．１
1

保護の対象となる個人情報の定義

対象

定義

個人情報

生存する個人に関する情報であって、特定の個人を識別することができるものとされている（個人情報保護法第 2 条第 1
項）
。また、他の情報と容易に照合することができ、それにより特定の個人を識別することができることとなるものを含む（同法第 2 条第 1 項）。

2

個人情報データ

個人情報を含む情報の集合物であって、特定の個人情報を電ベース

子計算機を用いて検索することができるように体系的に構成したもの、またはこれに準ずるものとされている（個人情報保護法第 2 条第 2 項）
。

3

個人データ

個人情報データベース等を構成する個人情報とされている（個人情報保護法第 2 条第 4 項）。

4

保有個人データ

個人情報取り扱い事業者が開示等の権限を有する個人デー
タであって、その存否が明らかになることにより公益その他の利益が害されるものまたは 6 ヶ月以内に消去することとなるもの以外のものとされている（個人情報保護法第 2 条第5 項及び個人情報の保護に関する法律施行令）。

（２）個人情報の「取り扱い」とは個人情報保護法において、個人情報は「個人の人格尊重の理念の下に慎重にとりあつかわれるべきものであることに鑑み、その適正な取り扱いが図られなければならない（法第 3 条）」とある。適正な「取り扱い」を実行・達成するために法律および多くの条例で、その「取り扱い」にあたる行為を下記のように区分しその義務を定めている。
表４．ⅳ．２
1

要件整理の対象とする個人情報の「取り扱い」の定義

取り扱いの区分規定により義務として定義されていること

取得・利用・個人情報を取得する際に、その利用目的を特定すること（法利用・個人情報を取得した際に、その利用目的は本人の同意を得

第 15 条）2

ること。また、目的外利用には予め本人の同意が必要（第16 条）。ただし、目的外利用が認められる例外もある。
3

提供

・取得した個人情報を第三者に提供するには、あらかじめ本
人の同意が必要であること。ただし下記のように本人の同意無しに第三者に提供することが認められてもいる。
①委託先への提供（委託もとに管理責任）
個人情報取り扱い事業者が利用目定の達成に必要な範囲内において個人データの取り扱いの全部または一部を委託する場合には、当該個人データの提供を受ける者
は第三者に該当しないとしている。
②合併等にともなう提供（当初の目的の範囲内）③グループによる共同利用（共同利用する者の範囲や利用目的等をあらかじめ明確にしている場合に限る）－76－

地域情報プラットフォームガイドライン

4

保管・管理

・取得した個人情報について、利用目的の範囲内で内容の正確性を確保すること（法第 19 条）。
・取得した個人情報について、漏洩・改ざん・滅失の危険にさらされることのないように技術的保護措置、組織的保護措置を確保すること（法第 20 条）。
・取得した個人情報の安全管理が図られるように、従業者及び委託先に対して監督を行なうこと（法 21、22 条）。

こうした行為区分に基づく制度的な規定を踏まえ、地域情報プラットフォームが構想するワンス
トップサービスにおける「個人情報の取り扱い」に係る要件の整理を行なう。ただし、取り扱いに係る要件のうち「管理」については、ワンストップサービスを提供する各々のサービス主体のセキュ
リティポリシーやセキュリティポリシーの運用体制整備に検討を委ねるため、本資料における詳細な検討の対象範囲外とする。

４－ⅳ．４ ワンストップサービス構想における個人情報取り扱い要件（１）申請手続き型ワンストップサービス

図４．ⅳ．２ 個人情報取り扱い要件と申請手続き型
ワンストップサービス概念の相関図①個人情報の取得・利用－77－

地域情報プラットフォームガイドライン

個人情報保護法（平成 15 年法律第 57 号）では、個人の情報を収集・利用するにあたり、下記の定義を行っている。
表４．ⅳ．３
1

個人情報の収集・利用にかかわる規定概要

適用対象

規定概要

利用目的の特定

個人情報の取扱事業者は、個人情報を取り扱うにあたっては、その利用の目的をできる限り特定しなければならない（第 15条）。

2

利用目的による制

個人情報取扱事業者は、あらかじめ本人の同意を得ないで、

限前条の規定により特定された利用目的の達成に必要な範囲を超えて、個人情報を取り扱ってはならない（第 16 条）。

3

適正な取得

個人情報取扱事業者は、偽りその他不正の手段により個人情報を取得してはならない（第 17 条）。

4

取得に際しての利用目的の通知等

・個人情報取扱事業者は、個人情報を取得した場合は、あらかじめその利用目的を公表している場合を除き、速やかに、その利用目的を、本人に通知し、または公表しなければならない。
・個人情報取扱事業者は、利用目的を変更した場合は、変更された利用目的について、本人に通知し、または公表しなければならない（第 18 条）。
・ただし、下記の場合には利用目的を通知公表することが適当ではないと示されている。
①本人または第三者の保護②事業者の権利保護③公的な事務への支障②個人情報の提供
a. 自治体内
自治体内において、異なる業務間で個人情報の提供を行なう場合に関係する規定を以降の表
４．ⅳ．４に示す。
表４．ⅳ．４の中で、下線のある太字による記述を踏まえると、自治体における異なる業務
間で個人情報の提供を行なう判断基準は、概ね次のように解釈できる。

・自治体における異なる業務間で個人情報を伴う情報の提供を行なう際には、各業務を所管する個別法において、その利用が認められていることが必要となる。例えば、住民票の記載事項を記録する
ため、国民健康保険業務から国民健康保険の被保険者情報や、児童手当の支給を受けているものについて、その受給資格に関する情報の提供をうけることは各個別法律上、認められている。
・ただし、所管業務の遂行に必要な場合であっても、本人または第三者の権利利益を不当に侵害するおそれがあると認められるときには、この限りではない。

－78－

地域情報プラットフォームガイドライン

表４．ⅳ．４

自治体内の異なる業務間で個人情報の提供を行なう場合についての条項概要

個人情報保護法

行政機関個人情報保護法

個人情報取扱事業者は、次に掲げる場合を○行政機関の長は、法令に基づく場合を除き、利用

除くほか、あらかじめ本人の同意を得ない

目的以外のために保有個人情報を自ら利用し、又で第三者に提供してはならない。
一 法令に基づく場合は提供してはならない（第 8 条第 1 項）。
○前項の規定にかかわらず、行政機関の長は、次の各号のいずれかに該当すると認めるときは、利用

二 人の生命、身体または財産の保護の目的以外の目的のために保有個人情報を自ら利ために必要がある場合であって、本人用し、又は提供することができる。ただし、保有の同意を得ることが困難であるとき

個人情報を利用目的以外の目的のために自ら利三 公衆衛生の向上又は児童の健全な育用し、又は提供することによって、本人又は第三成の推進のために特に必要がある場合者の権利利益を不当に侵害するおそれがあるとであって、本人の同意を得ることが困難であるとき四国の機関もしくは地方公共団体又はその委託を受けた者が法令の定める事認められるときは、この限りではない。
一

本人の同意があるとき、又は本人に提供するとき

二

行政機関が法令の定める所管事務の遂行に必務を遂行することに対して協力する必要な限度で保有個人情報を内部で利用する場合

要がある場合であって、本人の同意をであって、当該保有個人情報を利用することにつ得ることにより当該事務の遂行に支障を及ぼすおそれがあるときいて相当な理由のあるとき
三他の行政機関、独立行政法人等、地方公共団体
又は地方独立行政法人に保有個人情報を提供す（第 23 条第 1 項）

る場合において、保有個人情報の提供を受ける者
が、法令の定める事務又は業務の遂行に必要な限度で提供に係わる個人情報を利用し、かつ、当該個人情報を利用することについて相当な理由のあるとき四前三号に掲げる場合のほか、専ら統計の作成ま
たは学術研究の目的のために保有個人情報を提供するとき、本人以外の者に提供することが明らかに本人の利益になるとき、その他保有個人情報を提供することについて特別の理由のあるとき（第 8 条第 2 項）

b. 自治体間異なる自治体間において、個人情報の提供を行なう場合に関係する規定を以降の表４．ⅳ．
５に示す。
表４．ⅳ．５の中で、下線のある太字の記述を踏まえると、自治体間における個人情報の提供に関する調整基準を概ね次のように解釈できる。

－79－

地域情報プラットフォームガイドライン

・行政機関個人情報保護法の第 8 条第 2 項の第三号に示してあるとおり、各業務を所管する個別法においてその個人情報を利用することが認められている場合、他の自治体や独立行政法人に個人情報の提供を行なうことができる。その際、他の自治体への提供がどういった利用目的の範囲内で行なわれるかという旨、個人情報の保有者に対して事前に通知し、了解を得るべきである。
・ただし、国や自治体といった行政側の所管業務の遂行に必要な場合であっても、本人または第三者の権利利益を不当に侵害する恐れがあると認められるときには、他の行政機関に個人情報を提供すべきではない。
・また、自治体が制定している個人情報保護条例には、個人情報の利用や提供規制の一部として、国等も含む外部機関との通信回線の使用等による結合を禁止する規定（通称：オンライン禁止規定）も含んでいる場合がある。
・ただし、住民基本台帳ネットワークの実施が始まった 2002 年以降は、他の機関とのオンライン禁止
規定を設けている自治体数は減少した。そうした「禁止規定」の代わりに、法令等の規定（例：住民基本台帳法による住基ネットとの結合）も鑑み、個別のケースにおける提供可否の妥当性を判断する「制限規定」を条例に含む団体が増えている。したがって、その「制限規定」に照らし合わせて、自治体が保有している個人情報を他の自治体に提供できるか判断する必要がある。 vi

表４．ⅳ．５．

異なる自治体間で個人情報の提供を行なう場合に関係する条項概要

個人情報保護法

行政機関個人情報保護法

自治体の条例（例：藤沢市）

個人情報取扱事業者は、次に掲げ ○前項の規定にかかわらず、行政機 藤沢市個人情報の保護に関する条
る場合を除くほか、あらかじめ本

関の長は、次の各号のいずれかに 例（コンピュータの結合の制限）

人の同意を得ないで第三者に提該当すると認めるときは、利用目 ○実施機関は、登録事務について、供してはならない。

的以外の目的のために保有個人情コンピュータ処理を行なう場合

一

法令に基づく場合

報を自ら利用し、又は提供するこにおいては、実施機関内部、実施

二

人の生命、身体または財産のとができる。ただし、保有個人情機関相互又は実施機関以外のも保護のために必要がある場合報を利用目的以外の目的のためにのと通信回線の使用その他の方であって、本人の同意を得るこ

自ら利用し、又は提供することに法によるコンピュータの結合をとが困難であるときよって、本人又は第三者の権利利してはならない。ただし、次の各公衆衛生の向上又は児童の益を不当に侵害するおそれがある号のいずれかに該当するときは、健全な育成の推進のために特と認められるときは、この限りで

この限りではない。

に必要がある場合であって、本はない。

（1）法令等に定めがあるとき。

三

人の同意を得ることが困難で 一あるとき本人の同意があるとき、又は本四人に提供するとき

国の機関もしくは地方公共 二

行政機関が法令の定める所管事（2）前号に掲げる場合のほか、実施機関が必要があると認めるとき。

団体又はその委託を受けた者

務の遂行に必要な限度で保有個人 ○実施機関は、前項第 2 号に掲げるが法令の定める事務を遂行す

情報を内部で利用する場合であっ事由により実施機関内部、実施機ることに対して協力する必要て、当該保有個人情報を利用する

関相互又は実施機関以外のものがある場合であって、本人の同ことについて相当な理由のあるととコンピュータの結合を行なお意を得ることにより当該事務

きうとするときは、あらかじめ、藤の遂行に支障を及ぼすおそれ 三

他の行政機関、独立行政法人等、－80－

沢市個人情報保護制度運営審議

地域情報プラットフォームガイドライン

個人情報保護法があるとき（第 23 条第 1 項）

行政機関個人情報保護法

自治体の条例（例：藤沢市）

地方公共団体又は地方独立行政法会の意見を聞かなければならな

人に保有個人情報を提供する場合

い。

において、保有個人情報の提供を（第 19 条）受ける者が、法令の定める事務又は業務の遂行に必要な限度で提供に係わる個人情報を利用し、かつ、
当該個人情報を利用することについて相当な理由のあるとき四前三号に掲げる場合のほか、専ら統計の作成または学術研究の目的のために保有個人情報を提供す
るとき、本人以外の者に提供することが明らかに本人の利益になるとき、その他保有個人情報を提供することについて特別の理由のあるとき（第 8 条第 2 項）

c.自治体が保有する情報を民間に提供する場合について
行政機関個人情報保護法により定められている内容
前述した行政機関個人情報保護法では、行政機関等以外の者へ保有する個人情報を提供できる場合として、「専ら統計の作成または学術研究の目的のために保有個人情報を提供するとき（行政機関個人情報保護法第 8 条第 2 項第 4 号）」と示されている。
こうした提供先判断の根拠として、「統計の作成や学術研究のために個人情報を利用する場合は、特定個人が識別できないかたちで用いられることが通常であり、個人の権利利益が侵害されるおそれが少なく、かつ、公共性も高いと考えられること」が説明されている。vii
住民基本台帳法により定められている内容
住民基本台帳には、法に基づき収集された個々の住民に関する情報が記録されている。
その情報は、市町村において、住民の居住関係の交渉や選挙人名簿の登録その他の事務処理の基礎にするために活用されている。
従来、この住民基本台帳の一部の写し（住民基本台帳法に規定されている「本人確認情報」であり、個人情報と定義できる）を広く一般に公開する原則（「公開原則」とも呼ばれる）があった。しかし、個人情報保護の観点から、法改正を経て、原則非公開という位置づけとなった。これにより、住民基本台帳の一部の写しの閲覧請求時の審査が厳格化され、民間の事業者等がダイレクトメール送付などの営業活動のために閲覧することは認められなくなった。
－81－

地域情報プラットフォームガイドライン

また、行政機関が住民票コードを目的外利用することや住基法で定める範囲を超えてデータ連携に利用することは禁止されていることはもちろん、民間部門が住民票コードを利用することをも禁止している。viii
d.個人情報の第三者提供にかかわる制約について
これまでに参照した個人情報保護法第 23 条に示されているとおり原則としては、取得したその本人の個人情報をあらかじめ本人の同意を取らずに第三者に提供することは、禁止されている。
ただし、一定の条件に該当する場合には、本人の同意がなくとも第三者に提供できることも説明されている。その同意がなくても第三者に提供できる場合について次の表４．ⅳ．６に示す。
表４．ⅳ．６．
1

第三者に同意がなくても提供できる場合の概要ix

該当条項類

概要説明

提供先が第三者に該当①委託先への提供（個人情報取扱事業者には、委託先に対すしないとされる場合（第 23 条第 4 項の 1 号～3 号）

る監督責任が課せられる）②合併・分社化により新会社に顧客情報等を提供（新会社でも個人情報が譲渡される前の利用目的の範囲内で利用されることが条件）③グループ企業による共同利用（共同利用の範囲、利用する情報の種類、利用目的、情報管理の責任者の名称等について、予め本人に通知し、又は本人が容易に知り得る状態に置くことが条件）

2

オプトアウトの要件を満たしている場合（第 23 条第 2 項の 1 号～
4 号）

・
「オプトアウト」という本人の求めに応じて当該本人の個人データの第三者提供を停止する手続、について事前に本人に通知もしくは容易に知り得る状態においていることを条件に、同意なく第三者提供が認められる。
・ただし、オプトアウト手続の設定により、守秘義務やプラ
イバシー侵害が免責されることはない。

3

4

法令に基づく場合（第 23・刑事訴訟法に基づく捜査関係事項照会があった場合

条第 1 項第 1 号）

・弁護士会の弁護士会照会に回答する場合

人の生命、身体または財・大規模災害や事故等の緊急時に、患者の家族等から医療機産の保護に必要な場合関に対して、患者に関する情報提供依頼があった場合（第 23 条第 1 項第 2 号）
5

売店に対して、顧客情報の提供依頼があった場合

公衆衛生・児童の健全育・疫学調査などを実施する場合

成に特に必要な場合

・地域がん登録事業において、自治体から医療機関に対し（第 23 条第 1 項第 3 号）
6

・製品に重大な欠陥があるような緊急時に、メーカーから販

国・地方自治体等に協力する場合（第 23 条第 1 項第 4 号）て、がんの診療情報の提供依頼があった場合・税務署等から事業者に対して、任意の顧客情報の提供依頼があった場合・犯罪の防止その他公共の安全と秩序の維持の観点から、警察機関が行なう情報収集活動に協力する場合－82－

地域情報プラットフォームガイドライン③個人情報の取り扱い事業者の定義について
個人情報保護法の規定に対して義務を負う「個人情報取扱事業者」は、「個人情報データベー
ス等の形式で識別可能な個人情報を５０００件以上保有している事業者」と、定義されている。
また、この定義において、営利か非営利かという事業形態は問われていない。つまり、営利目的
でも非営利目的でも事業者は義務を負う対象として定義されている。
ただし、下記に示す団体については「個人情報取扱事業者」としての提供除外規定もある。
・報道機関、著述業者、学術研究団体、政治団体、宗教団体がその目的で利用する場合（個人情報保護法 50 条）
・取扱量が 5000 件以下の事業者（政令 2 条）
・国の機関（行政機関個人情報保護法）、独立行政法人（独立行政法人個人情報保護法）、
地方公共団体（個人情報保護条例）は、各組織が括弧内に示した別の法律で規定されているため④個人情報の適正な保管・管理
前述したように、ワンストップサービスを提供する各々のサービス主体のセキュリティポリシー
やセキュリティポリシーの運用体制整備における検討範囲であるため、本資料では詳細な要件整理の対象外とする。ただし、ワンストップサービスの提供・運用に関係する主体間において、整合性のとれたセキュリティポリシーの策定および運用の重要性については認識されるべきである。

－83－

地域情報プラットフォームガイドライン（２）情報照会・検索型ワンストップサービス

図４．ⅳ．３

個人情報取り扱い要件と情報照会・検索型

ワンストップサービス概念の相関図①個人情報の取得・利用
個人情報を取得・利用する際に遵守すべき要件（法令等により定められている概要）については、
申請手続き型ワンストップサービスと個人情報保護法にかかわる論点に特に大きな違いはないため、前述した内容を参照のこと。
②個人情報の提供
本資料の情報照会・検索型ワンストップサービスで想定しているシナリオは、「自治体が保有している個人情報をその情報の当事者本人に提供する場合」である。したがって、申請手続き型ワンストップサービスにおける論点の検討と異なり、ある個人情報のやり取りが自治体の異なる業務間で行なわれることは想定しない。したがって、個人情報の提供に関して、提供先が当該本人に限られる場合、情報保護法においてそれは認めることができる。
③個人情報の当事者に対する提供（個人情報の開示請求について）前述したとおり個人情報保護法は、個人情報の当該本人が自らの情報を提供することを求める権利を認めている。これは、個人情報の正確性や実施機関の適正な取扱いを確保することを目的に、関連する他の法律や多くの条例にも定められている「本人関与の制度的な仕組み」にあたる。この「本人関与」について、関係する法律や自治体の条例において定められている条項の事例を
表４．ⅳ．７に示す。
－84－

地域情報プラットフォームガイドライン

地域情報プラットフォームを利用した情報照会検索型ワンストップサービス構想は、個人情報に関する制度的に整備された本人関与の仕組みを、技術の活用により一層発展させる可能性を含む。
表４．ⅳ．７．
個人情報保護法

個人情報の当該本人に提供に関する規定概要

行政機関個人情報保護法

自治体の条例（例：藤沢市）

・個人情報取扱事業者は、本人か ・何人も、行政機関の長に対し、当 藤沢市個人情報の保護に関する条

一

二

三

ら、当該本人が識別される保有該行政機関の保有する自己を本人 例（管理情報の開示義務）

個人データの開示（当該本人がとする保有故人情報の開示を請求 ・実施機関は、開示請求があったと識別される保有個人データがすることができる。（第 12 条）

きは、開示請求に係る管理情報に存在しないときにその旨を知次の各号に掲げる情報（以下「非らせることを含む。以下同じ。）

開示情報」という。）のいずれかを求められたときは、本人に対が含まれている場合を除き、開示

し、政令で定める方法により、請求者に対し、当該開示請求に係遅延なく、当該保有個人データ

る管理情報を開示しなければな

を開示しなければならない。たらない。

だし、開示することにより次の（1）開示請求者以外の個人に関す

各号にいずれかに該当する場

る情報であって、当該情報に含ま合は、その全部または一部を開れる氏名、生年月日その他の記述示しないことができる。

等により開示請求者以外の個人

本人または第三者の生命、身を識別することができるもの又体、財産その他の権利利益を害は開示請求者以外の特定の個人するおそれがある場合を識別することはできないが、開当該個人情報取事業者の業示することにより、なお開示請求

務の適正な実施に著しい支障者以外の個人の権利利益を害すを及ぼすおそれがある場合

るおそれがあるもの。ただし、次他の法令に違反することとなる場合のアからイまでに掲げる情報を（第 25 条第

除く。

1 項）

ア

法令等の規定により何人に・個人情報取事業者は、前項の規も閲覧もしくは縦覧または謄

定に基づき求められた保有個

本、抄本等の交付が認められて人データの全部または一部にいる情報ついて開示しない旨の決定をイ

慣行として公にされ、またはしたときは、本人に対し、遅延公にすることが予定されていなく、その旨を通知しなければ

る情報

ならない。
（第 25 条第 2 項）

・・・など

・他の法令の規定により、本人に（2）法人その他の団体（国、独立－85－地域情報プラットフォームガイドライン

個人情報保護法

行政機関個人情報保護法

自治体の条例（例：藤沢市）

対し第一項本文に規定する方行政法人等、地方公共団体お呼び法により当該本人が識別され

土地開発公社を除く。以下「法人る保有個人データの全部また等」という。）に関する情報又はは一部を開示することとされ開示請求者以外の事業を営む個ている場合には、当該全部又は人の当該事業に関する情報で一部の保有個人データについあって、開示することにより当該ては、同項の規定は、通用しな法人等又は当該個人の競争上のい。

地位その他正当な利益を害する
おそれがあるもの（3）開示請求者の指導、診断、評価、選考等に関する情報であって当該開示請求者に知らせないことが正当と認められるもの
・・・など（第 23 条）４－ⅳ．５ ワンストップサービス実現にむけて検討もしくは対応が必要な個人情報の取り扱いに係る課題群（１）地域ポータルの運用主体やサービス提供主体（民間事業者等）に求められる対応
個人情報保護法に定められている義務履行対象である「個人情報取扱事業者」の定義（＝主に個
人情報の 5000 件という保有量と 6 ヶ月という保有期間）に当てはまるか否かに係らず、個人情報の適正かつ安全な取得・保有・利用方法を運用管理規程として整備することが望ましい。
【補足説明】
個人情報の件数の保有量や保有期間を義務履行対象の条件として、条例に盛り込んでいない自治体もあるため（つまり、個人情報を取り扱う事業者は全て義務履行対象を負う）。
また、昨今の情勢を踏まえ個人情報保護法においても、この個人情報の件数の保有量や保有期間を義務履行対象である「個人情報取扱事業者」の定義条件から取り払う可能性があると考えられるため。
（２）本人同意（オプトイン）の原則適用
ワンストップサービスの実現・提供にあたり、地域ポータル運営主体やサービス提供主体（自治体・民間事業者）は、個人情報の取得や利用をはじめ提供や保管・管理について、サービス利用者
本人の同意を得たうえで行なうことを、絶対の条件とすることが望ましい。

－86－

地域情報プラットフォームガイドライン（３）オプトアウトの仕組み整備と周知徹底
個人情報を取り扱うワンストップサービス提供の際には、個人情報保護にかかわるオプトアウトの要件を満たしたうえで、そのサービスを整備することが望ましい。また、そのオプトアウトの仕組みについてサービス利用者側に周知徹底を行なうことが必要である。
前述した個人情報の提供にかかわる要件でも整理したとおり、本人の求めに応じて当該本人の個
人情報の提供を停止（オプトアウト：利用者側がサービス提供者に行使できる個人情報の除外を選択する権利）できる仕組みを整備し、そのことが本人にわかるように設定することを法律に示されている。また、そうした仕組みが担保されていることを踏まえ、サービス提供側は事前の本人の同意を得ずに個人のデータ を第三者に提供することができる（オプトアウト：サービス提供側が利用者の選択権を除外して個人情報 を提供できる状態）ことを、前述したその他の条件に合致するか否かにも留意し、個人情報保護法が認めている。
このような２つの観点を持つオプトアウトの仕組みについて、ワンストップサービスを提供側は利用者側に対して分かりやすく周知徹底したうえで、サービスを整備することが重要である。
【補足説明】
昨今、個人情報のやり取りについて不安をいだき、個人情報の提供に過剰に保守的な反応を示される事象もある。そうした不安材料のひとつが、個人情報の第三者提供にかかわる問題である。制度上では、個人情報の第三者提供に制約を加えるためオプトアウトの要件が示されているが、このオプトアウトの要件や運用基準がわかりづらい面もある。そのため、余計な不安を増殖するという悪循環も創出する。
したがって、ワンストップサービスを安心して利用してもらうためにも、サービス提供側は上記に示した 2 つの観点のオプトアウトの仕組みを利用者側に周知徹底し、特に本人の求めによる提供停止等については真摯に対応することが必要とされる。
（４）個人識別性の喪失
個人情報は前述したとおり個人の識別性を要件とすることから、この個人の識別性をなくしてし
まえば、個人情報保護法の規定遵守義務対象外となる。また、個人の識別性がないデータであれば、第三者に提供する際の個人情報の漏洩に関する懸念材料も少なくなる。したがって、ワンストップ
サービスを運用するなかで、個人情報の取得や提供、流通を行なう場合に、個人識別性を喪失させても支障がない場合には、極力その識別性をなくすことが望ましい。 なお、プラットフォーム通信標準仕様において、「プライバシー保護型認証技術」に記述があり、データ流通時の個人の識別性を難しくする方法について技術的な観点からも検討されている。
（５）情報管理体制の明確化と情報管理コストの勘案
ワンストップサービスを安心して利用してもらうために、利用者が提供する個人情報の取り扱いに係る規定の遵守や適正な情報管理が必要となる。そのためには、サービス提供側の情報管理体制を明確にし、地域の認定個人情報保護団体（個人情報の適正な取り扱いの確保を目的として、苦情の処理や情報の提供を行なう団体）との連携も重要となる。また、そうした情報管理体制の構築や維持には、それなりのコストも掛かるということをサービスの提供側も予め認識しておくことが必要となる。このような課題に対する相談窓口のような支援体制づくりも行政側には期待される。

－87－

地域情報プラットフォームガイドライン

４－ⅳ．６ 個人情報取り扱いに係わる参考情報

図４．ⅳ．４．

個人情報の保護に関する基本方針のイメージ（出典：内閣府）

http://www5.cao.go.jp/seikatsu/kojin/kaisetsu/index.html－88－地域情報プラットフォームガイドライン

図４．ⅳ．５．

個人情報の保護に関する条例の制定状況（出典：総務省）

http://www.soumu.go.jp/s-news/2007/070629_4.html

分 野 分野名

分野名

別 項 (大項目)(小項目)

表４．ⅳ．８．

事業分野ごとのガイドラインの策定・見直し状況x

所管省庁

ガイドライン名

厚生労働省①医療・介護関係事業者における個人情報の ①平成 16 年 12 月 24

策定・見直し時期

番
1

医療

一般

適切な取り扱いのためのガイドライン（局長 日策定、平成 18 年 4通達）

月 21 日見直し②健康保険組合等における個人情報の適切 ②平成 16 年 12 月 27
な取り扱いのためのガイドライン（局長通 日策定達）③平成 17 年 3 月 31 日

③医療情報システムの安全管理に関するガ 策定、平成 19 年 3 月
イドライン（局長通達）

30 日見直し④国民健康保険組合における個人情報の適 ④平成 17 年 4 月 1 日策
切な取り扱いのためのガイドライン（局長通 定
達）
2

医療

研究

文部科学省

①ヒトゲノム・遺伝子解析研究に関する論理①～③平成 16 年 12 月

厚生労働省

指針（告示）

28 日策定経済産業省②疫学研究に関する倫理指針（告示）③遺伝子治療臨床研究に関する指針（告示）－89－地域情報プラットフォームガイドライン

分 野 分野名

分野名

別 項 (大項目)

(小項目)

所管省庁

ガイドライン名策定・見直し時期

厚生労働省①臨床研究に関する倫理指針（告示）①平成 16 年 12 月 28

番
医療

研究

②ヒト幹細胞を用いる臨床研究に関する指 日策定
針（告示）②平成 18 年 7 月 3 日策定

3金融・信 金融金融庁

用①金融分野における個人情報保護に関する ①平成 16 年 12 月 6 日
ガイドライン（告示）策定②金融分野における個人情報保護に関する ②平成 17 年 1 月 6 日策
ガイドラインの安全管理措置等についての 定
実務指針（告示）
4

金融・信

信用

経済産業省

用

経済産業分野のうち信用分野における個人

平成 16 年 12 月 17 日

情報保護ガイドライン（告示）策定、平成 18 年 10 月
16 日見直し

5

情報通信

電気通

総務省

信

電気通信事業における個人情報保護に関す

平成 16 年 8 月 31 日策るガイドライン（告示）定、平成 17 年 10 月 17
日見直し

6

情報通信

放送

総務省

放送受信者等の個人情報の保護に関する指平成 16 年 12 月 31 日

針（告示）策定、平成 19 年 3 月
28 日見直し

7

事業全般

-

経済産業省

①個人情報の保護に関すうる法律について①平成 16 年 10 月 22の経済産業分野を対象とするガイドライン

日策定、平成 19 年 3（告示）

月 30 日見直し②経済産業分野のうち個人遺伝情報を用い②平成 16 年 12 月 17た事業分野における個人情報保護ガイドラ

日策定

イン（告示）
8

雇用管理

一般

厚生労働省

①雇用管理に関する個人情報の適正な取り①平成 16 年 7 月 1 日

扱いを確保するために事業者が講ずべき措策定

置に関する指針（告示）②平成 16 年 10 月 29

②雇用管理に関する個人情報のうち健康情日策定

報を取り扱うに当たっての留意事項について（局長通達）
9

雇用管理

船員

国土交通省

船員の雇用管理に関する個人情報の適正な平成 16 年 9 月 29 日策取り扱いを確保するために事業者が講ずべ

定き措置に関する指針（告示）
10

警察

-

国家考案委員

国会考案委員会が所管する事業を行なう者－90－

平成 16 年 10 月 29 日

地域情報プラットフォームガイドライン

分 野 分野名

分野名

別 項 (大項目)

(小項目)

所管省庁

ガイドライン名策定・見直し時期

会等が講ずべき個人情報の保護のための措置

策定

番に関する指針（告示）
警察

11

12

13

防衛

法務

外務

-

-

-

-

警察庁

防衛省

法務省

外務省

警察共済組合が講ずべき個人情報の保護の平成 17 年 3 月 29 日策ための措置に関する指針（局長通達）定

防衛省関係事業者が取り扱う個人情報の保平成 18 年 5 月 25 日策護に関する指針（告示）定①法務省が所管する事業をオ来ぬ事業者等①平成 16 年 10 月 29が取り扱う個人情報の保護に関するガイド

日策定

ライン（告示）②平成 16 年 12 月 16

②債権管理回収業分野における個人情報の日策定、平成 18 年 1

保護に関するガイドライン（課長通知）

月 11 日見直し

外務省が所管する事業を行なう事業者が取平成 17 年 3 月 25 日

り扱う個人情報の保護に関するガイドライ
ン（告示）
14

財務

-

財務省

財務省所管分野における事業者が講ずべき

平成 16 年 11 月 25 日

個人情報の保護に関する指針（告示）
15

教育

-

文部科学省

学校における生徒等に関する個人情報の適平成 16 年 11 月 11 日

正な取り扱いを確保するために事業者が講ずべき措置に関する指針（告示）
16

福祉

-

厚生労働省

福祉関係事業者における個人情報の適正な平成 16 年 11 月 30 日

取り扱いのためのガイドライン
17

職業紹介

-

厚生労働省

等

職業紹介事業者、労働者の募集を行うもの、 平成 16 年 11 月 4 日
募集受託者、労働者供給事業者等が均等待遇、労働条件等の明示、求職者等の個人情報の取り扱い、職業紹介事業者の責務、募集内
容の的確な表示に関して適切に対処するための指針（告示）

18

労働者派

-

厚生労働省

遣
19

労働組合

派遣元事業主が講ずべき措置に関する指針

平成 16 年 11 月 4 日

（告示）
-

厚生労働省

個人情報の適正な取り扱いを確保するため

平成 17 年 3 月 25 日に労働組合が講ずべき措置に関する指針（告
示）
20

企業年金

-

厚生労働省

企業年金等に関する個人情報の取り扱いについて（局長通達）－91－

平成 16 年 10 月 1 日

地域情報プラットフォームガイドライン

分 野 分野名

分野名

別 項 (大項目)

(小項目)

所管省庁

ガイドライン名策定・見直し時期

国土交通省①国土交通省所管分野における個人情報保①平成 16 年 12 月 2 日

護に関するガイドライン（告示）策定②不動産流通業における個人情報保護法の②平成 17 年 1 月 14 日

適用の考え方（課長通知）

策定

個人情報の適正な取り扱いを確保するため

平成 16 年 11 月 9 日

番
21

国土交通

22

農林水産

-

-

農林水産省

に農林水産分野における事業者が講ずべき措置に関するガイドライン（告示）合計 35 本のガイドライン

合計
22
分野

■出典/参照情報i

内閣府 国民生活局．「個人情報の保護に関するガイドラインについて」 平成 19 年 5 月 31 日．
http://www5.cao.go.jp/seikatsu/kojin/gaidorainkentou.html,（参照 2007-09）．

ii

内閣府 国民生活局．「個人情報の保護に関するガイドラインについて」 平成 19 年 5 月 31 日．
http://www5.cao.go.jp/seikatsu/kojin/gaidorainkentou.html,（参照 2007-09）．

iii

大橋豊彦．特集 埼玉県個人情報保護条例の改正，季報 情報公開 個人情報保護．2006，3，vol．20．

iv

大橋豊彦．特集 埼玉県個人情報保護条例の改正，季報 情報公開 個人情報保護．2006，3，vol．20．

v

総務省．個人情報の保護に関する条例の制定状況（平成 19 年 4 月 1 日現在）．平成 19 年 6 月 29 日．
http://www.soumu.go.jp/s-news/2007/070629_4.html,（参照 2007-07）．

vi

制限規定として、外部との接続をする前に審査会の意見を聞く必要性が含まれる場合が多い。ただし、犯罪の予防や刑事捜査協力等、公共の安全を目的として警察庁に提供する場合などは、例外事案として審査会での判断を必要としない規定を設けている自治体（例：宮城県や千葉県）もある。

vii

総務省．住民基本台帳の閲覧制度等のあり方に関する検討会報告書．平成 17 年 10 月 20 日．
http://www.soumu.go.jp/s-news/2005/pdf/051020_4_1.pdf

viii

特集：住基ネット 5 周年:住民基本台帳ネットワークについて，月刊 LASDEC －地方自治情報誌－．2007，
8，vol．37，NO.8，p.13-18

ix

次の資料を参考に表を作成：東京都．地域のくらしと個人情報．平成 19 年 10 月．; 内閣府．個人情報保護法の解説．
http://www5.cao.go.jp/seikatsu/kojin/kaisetsu/index.html,( 参照 2007-0７～10)．

x

内閣府 平成 19 年 9 月 「平成 18 年度 個人情報の保護に関する法律施行状況の概要」－92－