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

５．地域情報プラットフォーム関連事業の成果
本章では、政府等が推進している地域情報プラットフォーム関連事業の成果に関する事項として、下記の2 点について記載する。
Ⅰ．地域情報プラットフォーム関連事業の成果に基づく地域情報プラットフォーム標準仕様の実現手段や課題
Ⅱ．地域情報プラットフォーム関連事業の取組み事例の紹介

５．１ 地域情報プラットフォーム標準仕様の実現手段・課題の検討
５．１．１

自治体間連携サービス（１）バックオフィス連携基盤の活用
平成 20 年度総務省地域情報プラットフォーム推進事業（引越ワンストップサービス分野）、平成 21 年度総務省地域情報プラットフォーム推進事業（バックオフィス連携分野、引越・退職分野）では、地域情報プラットフォームを活用した解決策を検討し、住民の利便性、行政の効率化を実現する次期モデル案を検討した。
次期モデル案は、住民が行う申請や情報参照、添付書類削減等のために自治体間で行う情報照会や情報通知を実現するため、ポータル⇔自治体間、自治体⇔自治体間等の団体間の情報連携の仕掛けを取り入れた。団体間の情報連携の実現手段としては、バックオフィス連携基盤の活用を採用した。バックオ
フィス連携基盤は、連携先団体の宛先管理、データ流通の仲介等の役割を担うことを目指している。
以下に、自治体とバックオフィス連携基盤の関係を示した概要図を示す。
利用者
申請
情報参照
ポータル
申請手続

住民向けの情報提供

自治体A

自治体B
団体間の情報連携（照会・通知等）

情報照会

情報照会
情報通知

バックオフィス連携基盤

情報通知
自治体間連携

図 ５．１．１

バックオフィス連携基盤の概要図

自治体間のデータ連携を仲介する役割を持つバックオフィス連携基盤を利用した際の、自治体間連携のアーキテクチャを示す。
自治体間連携のアーキテクチャでは、自治体にあるサービス基盤の PF 共通機能の位置付けとして、外部連携機能を利用することを想定している。ここで、外部連携機能とは、サイト間連携用のインタフェースを持ち、自治体内の業務ユニットとの連携を仲介する機能である。

－1－地域情報プラットフォームガイドライン＜Ａ自治体＞

業務ユニットバック系
業務ユニットフロント系
業務ユニット共通系
業務ユニット業務ユニット間インタフェース
統合ＤＢ機能サービス基盤
PF通信機能
ＢＰＭ機能

外部連携機能PF共通機能サイト間連携用
インタフェース

サービス基盤

自治体間連携＜バックオフィス連携基盤＞： 業務ユニット： サービス基盤＜Ｂ自治体＞

サービス基盤
業務ユニット間インタフェース

業務ユニット

図５．１．２

フロント系
バック系
共通系
業務ユニット 業務ユニット 業務ユニット

地域情報 PF の自治体間連携のアーキテクチャ（２）自治体間連携における署名のユースケース例
電子署名は、本人確認、改ざんの防止（検知）、否認防止を目的に利用される。自治体間連携においても、電子署名の適用が想定される。
本節では、引越ワンストップサービスを事例に、電子署名実施にあたっての課題と適用例を示す。
（ア）引越ワンストップサービスのユースケース
自治体間連携を署名のユースケースとした処理の流れを以下の図に示す。例では、利用者（住民）が引越した際に、団体間で情報の照会・取得の行うようなケース（転入先市町村が転出元市町村から情報を取得）としている。
署名適用することによって、照会元の団体で、照会対象の情報の内容の正しさ、照会先団体の確認を行うことを目的とした実現イメージを示す。

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

利用者ポータルサービス提供者

バックオフィス連携基盤

照会元団体（転入先市町村）

団体間情報連携

ワンストップ窓口支援システム

1
回答送付

2

団体間連携
情報

回答受取原課

4

4回答受付

1

照会依頼

照会依頼受付

照会先団体（転出元市町村）

3

ワンストップ窓口支援システム

3

照会回答
原課

参照用情報
依頼受付

照会依頼送付2

図５．１．３

3

自治体間連携における署名のユースケース例①照会を行うサービス提供者（照会元）が、バックオフィス連携基盤に対して照会依頼を送信する②バックオフィス連携基盤は、依頼を受け付け、サービス提供者（照会先）に依頼情報を送信する③依頼を受けたサービス提供者（照会先）は回答情報を準備し、バックオフィス連携基盤に送信する④バックオフィス連携基盤は、回答情報を受け取り、サービス提供者（照会元）に、回答情報を送信する
なお、本ユースケースにおけるワンストップ窓口支援システムは、引越ワンストップサービスにおいて、住民からの一括申請の受付や、他市町村からの照会依頼の受付・回答を行う役割として、平成 20 年度地域情報プラットフォーム推進事業（引越ワンストップサービス分野）において仮説として位置付けたものである。
（イ）署名付与・検証の実現イメージにおける規定事項
署名における規定事項として以下の事項が挙げらる。本節では、署名実施に関する規定事項を以下の表のようにした。

表５．１．１
No
1

規定事項の項目
対象処理に対する電子署名の必要性

2

電子署名付与の方法
34
5

実現イメージにおける規定事項例

電子署名の検証方法

実現イメージでの規定例
サービス提供者間の情報連携については、電子署名によって本人確認、改ざん防止を行う。

付与の対象（対象中の範囲含）①やり取りする情報の単位ですべての情報に署名を付与（情報の種類ごとに正当性を確認する）②情報全体へ署名を付与（回答者の確認、否認防止）

付与の権限（個人・職責など）①原課の職責にて署名②ワンストップ窓口の職責にて署名

検証者

ワンストップ窓口および原課にて検証する

検証範囲①情報単位に付与された署名を各原課にて検証（情報の正当性の確認）②情報全体に付与された署名を窓口にて検証（回答者の確認）－3－地域情報プラットフォームガイドライン

図５．１．４

団体間連携における実現イメージ① 照会先の情報を管理する各原課にて、各種証明書情報へ職責署名を付与する②-1 照会先のワンストップ受付窓口にて、署名付きの各種証明書情報を Base64 でエンコードし、電子封筒の添付書類タグ部へ、XML 値としてセットする。
②-2 照会先のワンストップ受付窓口にて、団体間連携情報全体がセットされた範囲に対して職責署名を付与し照会元へ送信する。
③

照会元のワンストップ受付窓口にて、団体間連携情報全体に付与された署名検証を行い、検証後、個別の各種証明書情報を各原課へ送付する。

④

照会元の各原課にて、各種証明書情報ごとに付与された署名の検証を行なう。

（ウ）署名実施における課題
署名実施にあたっては、対象となる処理、情報、署名付与・検証方法などの規定事項について、方針を決定することが望ましい。方針を決定するためには、対象の処理や情報に係る法令との関係を洗い出し、実施すべき事項を明確にする必要がある。

（３）

自治体間連携におけるサイト間連携用インタフェースの実装例

自治体間の連携方式として、バックオフィス連携基盤を利用した中継方式が方策の一つとして想定される。中継方式は、バックオフィス連携基盤にて、接続先サイト管理、BPM 機能、データの振分けの役割を担い、自治体側の開発コスト、運用コストの削減を図る方式である。
本節における課題、要件等は、平成 20 年度地域情報プラットフォーム推進事業（引越ワンストップサービス分野）における引越ワンストップサービスの団体間情報連携を事例にしている。本事例における自－4－地域情報プラットフォームガイドライン

治体関連携では、複数の連携元と連携先の組み合わせが発生するため、バックオフィス連携基盤で実行すべきビジネスプロセスの特定や、特定したビジネスプロセスに基づき転送先を特定することが必要であり、メッセージ中にこれらの情報を盛り込む必要性があった。
これらの課題を解決し、かつ、中継方式を効率的に行うための方策の一つとして、本節では、サイト間連携用インタフェース形式例及び、本インタフェース形式例を利用したサイト間の振分けイメージについて実装例を示す。

①引越ワンストップサービスにおける自治体間連携のユースケース
引越しワンストップサービスにおける自治体間の情報連携サービス（利用者（住民）が引越した際に、団体間で情報の照会・取得の行うようなケース（転入先市町村が転出元市町村から情報を取得）を例に、やり取りされる電子封筒の流れ（①～⑤）を以下に示す。

利用者ポータル

バックオフィス連携基盤⑤

利用別の団体間で交換された情報のログ情報の提供

あて先別の送付先
住所情報（サービス情報管理）

交換情報のログの蓄積と公開

ポータル宛
電子封筒

・あて先別に仕分ける
・送受信の同期・非同期、順番制御の実施
・指定のあて先住所に送付・受取確認実施し、送付状況を管理・写しを保持し、依頼により再送・交換情報のログの蓄積と本人への開示

④②

③

①
転入先市町村のワンストップ窓口

転出元市町村のワンストップ窓口
転出
元自治体

転出元宛
電子封筒

転入先宛
電子封筒

問合せ書類

問合せ
結果書類

転入
先
自治体

※

※
転出元市町村のバックオフィスの各担当

転出元宛
電子封筒

問合せ
結果書類

転入先宛
電子封筒

問合せ
書類

転入先市町村のバックオフィスの各担当※：「引越」ライフイベントにおける団体の役割

図５．１．５

引越ワンストップサービスにおける自治体間連携

上記ユースケースを踏まえると、自治体間連携におけるインタフェースに関する要件として以下の点が挙げられる。
【特徴 1】
参照元団体、参照先団体の組み合わせが複数かつ、その都度変わる。
【要件 1】
転出元自治体、転入先自治体等の連携の組み合わせが変わっても、適切な宛先へ電子封筒の転送が実現できる仕組みが必要。
－5－

地域情報プラットフォームガイドライン【特徴 2】
複数の業務の情報がやり取りされる。
【要件 2】
業務情報（データ項目）が変更になっても、インタフェースへの影響を少なくする仕組みが必要。
さらに、要件 1,2 をサイト間連携用インタフェースの要件として以下のように具体化できる。
【要件 1（詳細）】- 送信元団体における宛先指定を簡易にし、バックオフィス連携基盤で指定の宛先へ送付できること- ライフイベント情報や処理依頼事項、送付先情報、封筒の内容を示す情報が盛り込めること【要件 2（詳細）】- 電子封筒の作成、送付、受信、取り出し等の機能が、ライフイベントや書類形式とは、非依存の形式として実現できること（業務的な情報が変更されても通信のインタフェースを変更しなくてもよい）②サイト間連携用インタフェースの形式例(ア)メッセージ形式
引越ワンストップサービスのユースケースにおけるインタフェースの要件を実現するために、プ
ラットフォーム通信標準仕様の添付ファイルがある場合の電子封筒形式（メッセージ本体格納型）を活用したサイト間連携用インタフェース向けのメッセージ形式の一例を以下に示す。
電子封筒形式は、共通ヘッダ部と本文部にて構成されており、サイト間連携用インタフェースの形式例においても、本構成の枠組みの範囲内で事例を示す。以下に本形式例の特徴を示す。
a.本文部のタグとして“メッセージ属性タグ”を利用し、宛先情報、添付書類の情報を表現する【要件 1】
b.業務情報（ビジネス電文、業務ユニット間のデータ項目等）は、添付書類タグ内に格納する【要件 2】－6－

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

サイト間連携用インタフェースの形式例
包含関係

電子封筒形式

本文形式（サイト間連携用）
SOAPメッセージ形式

共通ヘッダ

共通ヘッダ
電子封筒形式

本文（ビジネス電文、及び、業務ユニット間のデータ交換で使用するメッセージ用の電子封筒）
第1メッセージ添付部（Base64ｴﾝｺｰﾃﾞｨﾝｸﾞ）第1メッセージ添付部（Base64ｴﾝｺｰﾃﾞｨﾝｸﾞ）本文

サイト間連携用
インタフェース形式＜メッセージ属性＞
<属性名>
<属性値>
＜/メッセージ属性＞
・・・<添付書類><添付書類名称><添付書類ファイル名称><添付書類内容>

電子封筒形式の枠組みで具体化

書類ﾃﾞｰﾀ(Base64)

or<添付書類>
・・・

共通ヘッダ

本文（業務データ項目）

本文形式（受領Ack）

サイト間連携用に形式を具体化したタグ

繰り返し構造（封筒の属性情報）

繰り返し構造（各サイト別情報）

共通ヘッダ

本文（業務データ項目）<受領ステータス><受領日時><備考>

受領Ack形式

メッセージ本体（例：自治体業務AP標準仕様で規定されたXMLを格納）

本文の形式として、メッセージ属性タグとプラットフォーム通信仕様の添付仕様のタグ<受領ステータス><受領日時><備考>

図５．１．６

単一のWSDLで定義⇒

用途に応じタグを規定する項目（例：自治体業務AP標準仕様のXMLｽｷｰﾏ）
タグが仕様化されている項目（例：Commonタグ）

単一のWSDLで定義

ライフイベントに依存しない、唯一のスキーマにより定義されている。

サイト間連携用のインタフェース形式例

プラットフォーム通信標準仕様の電子封筒形式とサイト間連携用インタフェースの関係を以下に示す。サイト間連携用インタフェース形式では、業務的な定義と通信の定義を分離し、通信の定義を固定的に利用可能とする形式である。
(イ)メッセージ属性タグと添付書類タグの使用例
添付書類タグは、サイト間で交換するデータの本体をプラットフォーム通信標準仕様で規定された添付形式で表現する領域である。メッセージ属性タグは、添付書類タグに関連する属性情報や、電子封筒のフロー制御情報等を保持する領域である。
これらメッセージ属性タグと添付書類タグは、サイト間連携用インタフェースを実現するにあたり、重要なタグであり、バックオフィス連携にてメッセージ本体を解析しなくても、振分け等の処理を実現することを目的としている。
以下に、引越ワンストップサービスを例とした、メッセージ属性タグおよび添付書類タグの使い方を記載する。

－7－

地域情報プラットフォームガイドライン◆メッセージ属性タグの使い方

#連携基
盤機能

記述
情報

1

ビジネスプロセス
実行

ビジネスプロセス
種別

メッセー
ジ分離・統合

2

メッセー
ジ転送

3

メッセー
ジ種別

内容

実行すべきビジネスプロセスを特定する情報を記述。
ライフイベント共通。
例

メッセージ本体の種類を記述し、メッセージ本体の内容を識別するための情報を格納する。
ライフイベント共通。
例

転送先
団体情報

認証・認
可

ＩＤ情報
権限情報

メッセージ種別、等

ライフイベント別に規定され、ビジネスプロセスで確定できないメッセージ本体の転送先の情報を記述する。

例

4

プロセス種別、等

転出元自治体、転入先自治体、等

引越ワンストップサービス環境を利用するためのID情報を記述する。
ライフイベント共通。

例

ポータル用ID、転出元自治
体用ID、認証レベル

図５．１．７<?xml version="1.0" encoding="UTF-8"?><PFサイト間電子封筒形式><共通ヘッダ><受付番号>2938281729029@R_Potal</受付番号></共通ヘッダ><メッセージ属性><属性名>ビジネスプロセス種別</属性名> <属性値>引越し申請手続</属性値></メッセージ属性><メッセージ属性><属性名>メッセージ種別</属性名><属性値>仮申請（ポータルからサービス連携基盤へ）</属性値></メッセージ属性><メッセージ属性><属性名>転出元自治体</属性名><属性値>東京都○△区</属性値></メッセージ属性><メッセージ属性><属性名>転入先自治体</属性名> <属性値>×○市</属性値></メッセージ属性><メッセージ属性><属性名>民間（電力）</属性名> <属性値>東西電力</属性値></メッセージ属性><メッセージ属性><属性名>ポータル名</属性名> <属性値>ＡＡポータル</属性値></メッセージ属性><メッセージ属性><属性名>ID</属性名> <属性値>tsdg-01058469251</属性値></メッセージ属性><メッセージ属性><属性名>認証レベル</属性名> <属性値>2</属性値></メッセージ属性><添付書類><添付書類名称>転出元自治体：申請書類</添付書類名称><添付書類ファイル名称>転出元自治体用申請書類.xml</添付書類ファイル名称><添付書類内容>alksdjfasijs09asdj398ja.......</添付書類内容></添付書類><添付書類>
・・・</添付書類><添付書類>
・・・</添付書類></PFサイト間電子封筒形式>

メッセージ属性タグの使い方◆添付書類タグの使い方

#

5

サービス
基盤機能

記述
情報

メッセー
ジ
分離・統合・転送

転送先
団体別のメッセージ
本体

内容<?xml version="1.0" encoding="UTF-8"?><PFサイト間電子封筒形式>
・・・

ライフイベント別のサービスサ
イト向けのメッセージ本体（申請書等）を、添付する例

転入先市町村向け申請書。

<メッセージ属性><属性名>転出元市町村</属性名><属性値>東京都○△区</属性値></メッセージ属性><メッセージ属性><属性名>転入先市町村</属性名> <属性値>×○市</属性値></メッセージ属性><メッセージ属性><属性名>民間（電力）</属性名> <属性値>東西電力</属性値></メッセージ属性>
・・・<添付書類><添付書類名称>転出元市町村：申請書類</添付書類名称><添付書類ファイル名称>転出元市町村用申請書類.xml</添付書類ファイル名称><添付書類内容>alksdjfasijs09asdj398ja.......</添付書類内容></添付書類><添付書類><添付書類名称>転入先市町村：申請書類</添付書類名称><添付書類ファイル名称>転入先市町村用申請書類.xml</添付書類ファイル名称><添付書類内容>bbcdalfasijs09asdj39a.......</添付書類内容></添付書類><添付書類><添付書類><添付書類名称>電力；申請書類</添付書類名称><添付書類ファイル名称>電力申請書類.xml</添付書類ファイル名称><添付書類内容>k9kr7alksdjfasijs09asdj.......</添付書類内容></添付書類><添付書類></PFサイト間電子封筒形式>

図５．１．８

添付書類タグの使い方－8－地域情報プラットフォームガイドライン③団体間のフロー制御方式
引越ワンストップサービスをライフイベントとした場合の項目定義例として、以下の 4 つのタグ値の利用例を示す。
・ ライフイベント共通属性「ビジネスプロセス種別」の属性値タグの値（例、引越申請手続）
・ ライフイベント共通属性「メッセージ種別」の属性値タグの値（例、仮申請（バックオフィス連携基盤から転出元市町村））・ ライフイベント別属性の属性名タグの値と属性値タグの値（例、転出元市町村、転出先市町村、など）
・ ライフイベント別属性の属性名タグの値と関係付けられた添付書類名称タグの値と添付書類内容タグの値

表５．１．２
タグ
メッセージ属性
属性名
属性値メッセージ属性
属性名
属性値
メッセージ属性
属性名
属性値
メッセージ属性
・・
添付書類
添付書類名称添付書類ファイル名
称
添付書類内容添付書類参照情報
添付書類｢引越｣ライフイベントを例とした電子封筒形式の項目定義例
タグの役割
タグ値の例
（ライフイベント共通属性「ビジネスプロセス種別」）「ビジネスプロセス種別」を設定
ビジネスプロセス種別
ライフイベント別の値を設定
引越申請手続（ライフイベント共通属性「メッセージ種別」）「メッセージ種別」を設定
メッセージ種別
ライフイベント別の値を設定
仮申請（ライフイベント別属性、その 1）
ライフイベント別に規定された名称を設定する
転出元市町村ライフイベント別属性の値を設定
東京都港区（ライフイベント別属性、その 2）（ライフイベント別属性に関連付けられた添付書類、その1）
ライフイベント別属性の属性名をプレフィックスとし、添付書類の種別を設定する
ファイル名称を設定する
ライフイベント別属性に関連付けられた添付書類の内容を設定する
添付書類本体の外部参照を URL 形式で設定する（ライフイベント別属性に関連付けられた添付書類、その2）

転出元市町村：申請書類
転出元市町村用申請書類.xml
alksdjfasijs09asdj398ja.......
（★）未使用・・

上記の内容と、ライフイベント別に定義されたサイト間フロー定義（ビジネスプロセス制御定義）にもとづき、下図に示すシステム間フロー制御を行う。

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

引越ワンストップ
ポータル、他
PF通信（サイト間インタフェース形式）

サイト間インタ
フェース形式を規定（APPLIC電子封筒に基づく）

電子封筒
AB

サービス提供者Ａ（地方公共団体）

サービス提供者Ｂ（地方公共団体）

PF通信（サイト間インタフェース形式）

PF通信（サイト間インタフェース形式）

電子封筒
A

電子封筒
B

PF通信（サイト間インタフェース形式）
ＢＰ定義に基くフロー制御（電子封筒内容の分割と、その送信先制御）サイト間ＢＰ定義

ＢMＲ-ＧＷ機能＋送付先（論理⇒物理）変換

サービス情報を登録宛先（URL）の解決

ＢＰＭ

サービス・レジストリ機能（サービス情報）

バックオフィス連携基盤
図５．１．９システム間フロー制御方式

・ ビジネスプロセス種別とメッセージ種別にもとづき、関連するビジネスプロセス制御定義の実行制御(以下、BPM 機能と呼ぶ)を行う。
・ BPM 機能は、ビジネスプロセス制御定義にもとづき、受信したメッセージ内の添付書類タグの値を、各サービス提供者別に取り出し、必要なメッセージ属性タグをつけて、新しい電子封筒を作成する。
・ BPM 機能は、受信したメッセージ内のメッセージ属性タグの値にもとづき、新しい電子封筒の送信先サービス提供者を決定する。
・ BPM 機能は、送信先のサービス提供者を決定するために、以下の手順でメッセージルーティン
グ機能を使用する。受信した電子封筒内のメッセージ属性タグの値を引数に、サービス情報管理を検索し、エンドポイントを決定、決定したエンドポイントを新しい電子封筒の共通ヘッダ部に設定し、BMR-GW 機能で適切なサービス提供者へ送信する。
・ サービス提供者では、自サイト用の電子封筒を受信し、受信した電子封筒内のメッセージ属性タグの値や、添付書類タグのビジネス文書にもとづき、自サイトのサービスを実施する。
結果を、新たなメッセージに格納し返信する。
バックオフィス連携基盤におけるメッセージの解析と生成の手順を以下に示す。

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

バックオフィス連携基盤

BPM

引越しAターン

機能バックオフィス
連携BP実行のための情報

転出元（市町村A）

転入先（市町村B）

民間1（介護施設）③④

メッセージ属性
属性名

メッセージ属性

属性値

メッセージ属性

居住地結果 正常終了

取得情報(1-1)
取得情報(1-2)

非同期処理 なし

添付書類(2)

メッセージ属性②

取得情報(1-2)

共通ヘッダ（物理）To

メッセージ属性

添付書類(2)

取得情報(1-3)

www.front.lg.jp

1.
2.
3.
4.
5.
6.

市町村B

民間１

介護施設

共通ヘッダ（論理）

市町村B

市町村B

ReplyTo ﾊﾞｯｸｵﾌｨｽ連携

共通ヘッダ（物理）To…

ReplyTo www.aa.lg.jp①
図５．１．１０

市町村A

引越先

⑤

取得情報(1-1)

…

転出元
市町村

共通ヘッダ

ﾊﾞｯｸｵﾌｨｽ連携

+
庁内連携

共通ヘッダ

引越元

To

ReplyTo 市町村A

機
能送付
先変
換

…

To

…

BMR-GW

共通ヘッダ（論理）属性値プロセス種別 引越Ａパターン

取得情報(1-3)

市町村A

メッセージ属性
属性名

プロセス種別 引越Ａパターン

www.bb.lg.jp

ReplyTo www.front.lg.jp

庁内連携

転入先市町村⑥「引越」ライフイベント(団体間情報連携)における処理方式

PF 通信機能が、転出元市町村から、メッセージを受信する。
BMR-GW 機能+送付先変換機能が、共通ヘッダの値を参照して物理的な宛先から論理的な宛先へと変換する。
BPM 機能が、メッセージ属性タグからバックオフィス連携用の情報を抽出し、適切なビジネスプロセスの受付部へメッセージを送信する。
BPM 機能が、団体間連携用の情報をメッセージ属性タグの値を設定し、メッセージを生成する。
BMR-GW 機能+送付先変換機能が、共通ヘッダの値を参照して論理的な宛先から物理的な宛先へと変換し設定する。
PF 通信機能が、転入先市町村へ、メッセージを送信する。

④今後の検討課題
本事例で示したメッセージ形式を適用すると、業務情報を添付書類化するとともに、メッセージ形式が一意になり、WSDL 定義を単一化することが可能である。この利点として、業務情報の変更（データ項目の追加・削除など）が発生しても、サイト間通信の WSDL 定義に与える影響をなくすことがで
き、PF 通信機能に対する実装面の改修・追加を少なくすることができる。
ただし、以下の事項について今後の検討が必要である。
・ 業務ユニットとの連携方法について、外部連携機能の役割整理とあわせ、サイト間連携用インタフェースの規定のあるべき姿の検討（自治体業務アプリケーション仕様との関係も踏まえた検討）・ サイト間連携用インタフェースのメッセージ形式の本文（本節では例：メッセージ属性タグ）部分に関する標準化（必要性も含め）の検討－11－

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

５．２ 取り組み事例
５．２．１

平成 21 年度地域情報プラットフォーム推進事業(バックオフィス連携分野)の取組み

総務省では、国・地方公共団体・民間企業の枠を超えた公共情報サービスの高度化等の促進を図るた
め、「地域情報プラットフォーム標準仕様書」に準拠したシステムの実証実験を実施し、実現に向けた課題の抽出等を行っている。
総務省「平成 21 年度地域情報プラットフォーム推進事業（バックオフィス連携分野）」においては、住民の利便性向上と行政効率化の双方の実現を目標に、地方公共団体等における業務システム間の効率的な連携（バックオフィス連携）を行う仕組みの検討、実証を行った。

バックオフィス連携

都道府県

住民、企業等

バックオフィス連携基盤

ポータル
連携

図５．２．１

バックオフィス連携のイメージ

－12－

市町村

市町村

地域情報プラットフォームガイドライン（１）バックオフィス連携の目的・目標
バックオフィス連携を実現する仕組みの検討にあたって、地方公共団体等の各情報保有機関間の情報流通の観点において、以下を目標とした。
◆安心安全な情報流通と情報管理の最適化
バックオフィス連携においては、情報連携が容易になり住民や行政機関の利便性が向上する一方で、様々な機関・組織間で情報が電子的に連携することにより、住民の目に見えない形で多くの情報が流通することとなる。そのため、住民が安心してサービスを利用するために、住民が自らの情報の流通先を指定可能とし、さらにどのような情報が、誰に対して、どの範囲まで提供されているかといった、情報の所在やその流通先を見えるような仕組みとする必要がある。
また、バックオフィス連携においては、官民問わず、様々な分野の機関・組織が連携することによって、多くの情報が流通することとなる。そのため、安心安全な情報流通を実現するためには、適切な情報管理を行うことが重要となる。ここで流通させる情報は、セキュリティ事故等の発生の可能性を鑑みて、統合化による一極集中ではなく分散管理がなされるべきであると考える。そのため情報の管理責任を明確化し、情報は各機関、組織の責任範囲に応じて分散した情報管理がなされるように最適化を行う必要がある。
（２）バックオフィス連携の要件
安心・安全な情報流通と情報管理の最適化の実現にあたり、バックオフィス連携に求めるべき要件として、以下を定めた。
・情報の分散管理
情報が分散管理される状況においては、本人識別情報（ID）の体系が異なる住民情報を保有する各機関から情報を取得する仕組みが必要である。
また、各情報保有機関で管理している本人識別情報（ID）を伝搬させるのは名寄せの懸念も考えられることから、本人識別情報（ID）の紐付けに仮 ID を使用し、仮 ID を用いた情報連携を行うことができる仕組みが必要である。
・本人同意に基づく情報連携
住民のプライバシ情報の流通にあたっては、最終的な情報所有者である住民本人によって自らの情報の流通先を指定できる仕組みが必要である。
・情報流通先の把握
住民自身の情報が、誰に対して、どの範囲まで提供されているのかという、情報の所在やその流通先を可視化する仕組みが必要である。

－13－地域情報プラットフォームガイドライン（３）バックオフィス連携基盤を実現する技術
バックオフィス連携では複数の情報保有機関が相互に情報連携されることとなるが、連携される各機関にて個別の技術仕様を採用した場合、相互接続性が損なわれる可能性があるため、技術仕様の選定を行う必要があった。
技術仕様の選定にあたっては、バックオフィス連携の要件に基づき、仕様選定を行う必要がある。下表にバックオフィス連携の要件と、技術選定の方針について示す。
尚、当該実証実験では、要件を実現する仕様として、SAML2.0 および ID-WSF2.0 を利用した。

表５．２．１
バックオフィス連携の要件
情報の分散管理
情報の流通範囲

連携する識別情報
情報所在の把握

本人同意に基づく情報連携

本人情報連携他人情報連携情報流通先の把握

技術仕様選定の方針
技術選定の方針
自治体間のみ連携することを許可するなど、情報の流通範囲をコントロールする必要があり、情報の流通範囲を事前定義できること
ID による不正な情報の名寄せを防止する必要があり、仮 ID を用いた情報連携ができること
住民情報を保有する自治体のサービスを特定し、照会等を行う必要があり、情報所在を管理する為のレジストリ機能が存在すること本人への情報開示など、情報保有者と情報要求者が同一である情報連携について、情報保有者本人の許諾意志に基づき情報連携を制御できること
自治体職員が住民情報を要求するなど、情報保有者と情報要求者が異なる情報連携について、情報保有者本人の許諾意志に基づく情報連携を制御できること
情報保有機関がプライバシ情報を第三者へ提供した履歴を保管し、ポータル等を通じて本人にアクセス履歴として公開できる
こと

－14－

地域情報プラットフォームガイドライン（４）実現イメージ
SAML2.0、ID-WSF2.0 を用いたバックオフィス連携の実現イメージを以下に示す。
住民

障がい者福祉
ポータル
プライバシ情報の流通先の指定

プライバシ情報
流通先の指定自治体A

プライバシ情報の利用許諾ポ
リシー

（イ）

バックオフィス連携基盤
アクセス履歴の照会（ウ）アクセス履歴の照会アクセス履歴照会サービス

アクセス履歴SAML 2.0による紐付け管理

職責証明書＋住民の仮ID
（XX）

自治体X

職員

住民のSAML
ｱｻｰｼｮﾝ（AA）＋サービス情報

仮ID情報

（ア－２）

情報保有機関 サービス
情報の検索

住民情報の照会
住民情報の照会

住民の仮IDの変換＋

仮ID情報サービスとIDの紐付け情報サービス
情報サービス
情報サービス
情報

アク
セス
履
歴の出
力

住
民の指定に基づく
情報
流
通制
御（ア－１）

仮ID
情報

障がい者
情報
職責証明書
＋住民のSAML
ｱｻｰｼｮﾝ（AA）

実ID

仮ID

氏名

実ID

仮ID

氏名

X

XX

住民①

AAA

住民①

図５．２．２

バックオフィス連携の実現イメージ（ア）情報の分散管理（ア－１）情報保有機関及びサービスの特定サービスと ID の紐付け情報をバックオフィス連携基盤で管理し、各機関が仮 ID によりサービス情報を検索できる仕組みを構築した。これにより、職員が他自治体の住民情報を照会するケースなどにおいて、照会元となる自治体では容易に照会先となる自治体のサービスを特定可能となる。
（ア－２）本人識別情報（ID）体系が異なる機関からの情報取得
各機関の ID の紐付けをバックオフィス連携基盤で一元的に管理し、連携先に応じて ID を提供または変換する仕組みを構築した。また、ID の紐付けに際して、実際の本人識別情報とは別の仮 ID を用いることで、ID による名寄せの防止、ID 変更運用が柔軟になるなどの効果が期待できる。
（イ）本人同意に基づく情報連携
住民が指定するプライバシ情報の流通先に関する情報を自治体に連携し、利用許諾ポリシーとして登録する仕組みを構築した。
（ウ）情報流通先の把握
自治体に記録されるアクセス履歴をポータルに集約し、住民が自身のプライバシ情報の流通先を確認できる仕組みを構築した。例えば、ワンストップサービスにおけるアクセス履歴は複数の自治体に分散して出力されることになるが、この仕組みにより、住民は自治体を跨り連携されるプライバシ情報の追跡が可能となる。

－15－