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

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

V2.9

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

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

項

バージョン

V2.7
1
2018.3.12

V2.8
2
2019.7.3

ドキュメントファイル

改版履歴

改版有無 備考

表紙
第1章
第2章
第3章
第 3 章要約第4章
第 4 章(別冊)第 4 章付録 4-ⅰ
第 4 章付録 4-ⅲ
第5章
別冊 GIS
地域情報プラットフォーム
全体体系
表紙
第1章
第2章
第3章
第 3 章要約第4章
第 4 章(別冊)第 4 章付録 1
第 4 章付録 3
第5章
別冊 GIS有各標準仕様のバージョン最新化

有有Copyrights の年を 2018 に修正

有

各標準仕様のバージョン最新化

有

各標準仕様のバージョン最新化

有

本書の目的等を明確化
第 3 章 取り組み事例を追記
第４章 導入時のパターンや留意点を追記 等

地域情報プラットフォーム
有各標準仕様のバージョン最新化
全体体系
表紙
有
各標準仕様のバージョン最新化
第1章
2014.3.11
第2章
2014.3.11
第3章
2018.3.12
第 3 章要約
2014.3.11
第4章
2013.5.31
V2.9
3
第 4 章(別冊)2013.5.31
2020.5.7
第 4 章付録 1
2013.5.31
第 4 章付録 3
2013.5.31
第5章
2013.5.30
別冊 GIS2019.3.31
地域情報プラットフォーム
全体体系
改版有無：無印については、表紙ならびにヘッダー部分のバージョン表記の修正を実施している。
※各章のヘッダーのバージョン表記は、改版の発生時に修正するため、当面は全体のバージョンと異なるバージョンが記されている場合があります。

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

地域情報プラットフォーム ガイドラインのバージョン管理について
地域情報プラットフォーム ガイドラインは、表紙と各章別にファイルを分けて作成されています。最新バージョンの管理は、ガイドライン表紙ファイルにて各章の該当ファイルを改版履歴に記載することとしています。

改版履歴イメージ★：各章とファイル名の例
表紙：ガイドライン表紙(V2.9)_20200513.doc
第1章：ガイドライン第 1 章_20140311.doc
第2章：ガイドライン第 2 章_20140311.doc
第3章：ガイドライン第 3 章_20180312.doc
第 3 章要約 ：ガイドライン第 3 章要約_20140311.doc
第4章：ガイドライン第 4 章_20130531.doc
第 4 章(別冊) ：ガイドライン第 4 章（別冊）_ワンストップサービス連携定義手順_20130531.doc
第 4 章付録 1 ：ガイドライン第 4 章付録 1_付加価値サービスのサンプル（表紙）_20130531.doc
第 4 章付録 3 ：ガイドライン第 4 章付録 3_各種定義体サンプル（表紙）_20130531.doc
第5章：ガイドライン第 5 章_20130530.doc
別冊 GIS：ガイドライン別冊_GIS 共通サービスガイドライン_20190331.doc★：全てのファイルを zip ファイルとして管理する
ファイル名例：ガイドライン V2.9_2019.zip
・・・2019 年度版 V2.9 の例です-2 -

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

はじめに
本書は、
地域情報プラットフォームを導入する自治体向けに調達、構築の指針をまとめたものである。
本書の内容は、以下の標準仕様書に基づき作成されている。
｢アーキテクチャ標準仕様 V3.2｣｢プラットフォーム通信標準仕様 V3.2」｢地域情報 PF 準拠確認及び相互接続確認仕様 V3.5」｢自治体業務アプリケーションユニット標準仕様 V3.5｣
標準仕様を補完する内容も含まれることから、標準仕様の理解をより深めることができる。

自治体が、地域情報プラットフォーム標準に基づくサービス基盤の調達・導入を円滑に行えるよう、
本書には、実際の調達実務において具体的に検討すべき事項やその検討作業の実施手順と、標準仕様に基づいた基盤の調達仕様書の作成を支援するために、その作成に必要となる事項を記載している。

また、標準仕様策定にあたって検討された設計、開発、調達、運用に係る留意事項が記載されている。
これらの内容は、情報システムに係る調達についての各自治体での調達事例等や、民間での取り組みを踏まえて取りまとめており、この標準仕様が全ての自治体にそのまま適用できるものではないが、導入
自治体の指針となるものである。

調達者におかれては、調達実務を遂行するに当たり本書を参考としつつ、調達における課題解決やリスク低減等のための工夫を積み重ねていくことが重要である。また、実際の各自治体での基盤調達の個々のプロジェクトの実施に当たっては、調達担当は、受注者との役割分担を明確にし、発注者としての責務を適切に果たしていくことが特に必要であることを踏まえたうえで、本書を活用していただきたい。

なお、本書は、自治体の調達者に活用されることを目的として作成しているが、地域情報プラット
フォーム対応製品を開発、構築、販売する民間企業のベンダにおいても、調達指針の理解および、マル
チベンダ構成をする際の業務システム間連携方法の検討の一助となるものである。

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

目次
第１章
１．１
１．２

第２章
２．１
２．２
２．３
２．４
２．５

第３章
３．１
３．２
３．３
３．４
３．５
３．６
３．７
３．８
付録１
付録２
付録３
付録４
付録５

第４章

本ガイドラインの前提
前提条件
法改正の考え方

調達仕様
地域情報プラットフォームの調達について
サービス基盤の調達
プラットフォーム仕様準拠業務ユニットの調達
導入体制
移行計画

技術解説
PF 通信機能統合 DB 機能
BPM 機能セキュリティ
PF 共通機能 認証・認可・セキュリティ
モニタリング機能
PF 共通機能（ユーティリティ機能）
メッセージ交換パターンと異常系処理
AUDIT、インタフェースに関する詳細定義
実装コンポーネント構成に関する推奨モデル
共通定義の XML スキーマ定義
モニタリング機能の実装例
採用候補の技術使用の検討状況について

ワンストップサービスの導入

４．１
自治体内を中心とした付加価値サービスの検討
４．２
自治体内ワンストップサービス、自治体間、官民連携サービスの検討
付録４－ⅰ 付加価値サービスのサンプル
付録４－ⅱ 各種定義体サンプル
付録４－ⅲ 地域情報プラットフォームの利活用
付録４－ⅳ ワンストップサービス実現に向けた個人情報取り扱いの考え方

４章別冊 ワンストップサービスの連携定義手順
１．
２．
３．
４．

ワンストップサービス連携定義手順とはワンストップサービスの連携定義手順
参照定義
辞書

-4 -

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

第５章 地域情報プラットフォーム関連事業の成果
５．１
５．２

別冊

地域情報プラットフォーム標準仕様の実現手段・課題の検討
取り組み事例GIS 共通サービスガイドライン

第 1 章 本書の目的
第 2 章 GIS ユニットおよび GIS 共通サービスとは
第 3 章 GIS 共通サービスの活用と効果
第 4 章 GIS 共通サービスの導入・運用
第 5 章 地名辞典の整備・運用
第 6 章 GIS ユニットの調達
第 7 章 付録

-5 -

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

地域情報プラットフォームガイドライン
第１章 本ガイドラインの前提

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

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

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

項

版数

1

2014.3.11

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

改版履歴

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

目次
１．本ガイドラインの前提 ............................................................... 3
１．１ 前提条件................................................................................................................................................ 3
１．２ 法改正の考え方 .................................................................................................................................... 8

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

１．本ガイドラインの前提
１．１

前提条件

当ガイドラインは「はじめに」に記載されている通り、標準仕様書に基づいた調達、構築を行う際の指針をまとめたものである。
システム導入にあたり、自治体の業務、組織、システム運用方式、業務ユニット導入順序、データ移行方式など、個々の自治体で協議、決定する必要がある部分が多々存在する。これらは本文中の各所に記載されており、地域情報プラットフォームの調達を行う際、事前に十分に検討すべき事項である。
また、地域情報プラットフォーム仕様は、システムの具体的な実装方式については様々な実現形態があり、製品提供ベンダからの提案を充分に検討・協議する事が必要である。上記を了解いただいた上で、地域情報プラットフォーム導入時には本書を熟読いただき、システム調達の参考として活用いただきたい。
なお、本書は今後の地域情報プラットフォームの導入実績から有用な情報や標準仕様書の改版に伴って、逐次レベルアップし成長させていく方針である。

１．１．１

ガイドラインの位置づけ

地域情報プラットフォームは、業務モデル標準、サービス協調技術標準で規定する標準仕様、および
ガイドラインにより構成される。本書「地域情報プラットフォームガイドライン」は、業務モデル標準
およびサービス協調技術標準における仕様に準拠したサービス基盤、および業務アプリケーションを導入する際に必要な事項をとりまとめたものである。その中で特に 1 章、2 章には調達者向けに必要な情報を集約してまとめている。

地
域
情
報
プ
ラ
ッ
ト
フ
ォ
ー
ム
標
準
仕
様
書

業務モデル標準

サービス協調技術標準

自治体及び民間が提供する地域情報サービスの連携に必要な業務アプリケーションユニットのインタフェース仕様

サービス連携を支える基盤アプリの諸要件・プロトコ
ル等を取り決めた仕様

自治体業務アプリケーションユニット標準仕様
防災業務アプリケーションユニット標準仕様
教育情報アプリケーションユニット標準仕様
健康情報業務アプリケーションユニット標準仕様※

アーキテクチャ標準仕様
プラットフォーム通信標準仕様

GISを活用した業務ユニット、アプリケーションを構築するための共通仕様

GIS共通サービス標準仕様
各種システム製品等の地域情報プラットフォーム準拠及び相互接続を確認する仕様

地域情報プラットフォーム準拠確認及び相互接続確認仕様
仕様に準拠したサービス基盤および業務アプリケーションを導入する調達者向けに必要な事項をとりまとめたもの（指針）

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

その他

地域情報プラットフォーム基本説明書
地域情報プラットフォーム標準仕様運用規則

資参料考

地域情報プラットフォームガイドライン 技術解説 要約
地域情報プラットフォームにおけるＧＩＳ共通サービス基本提案書※ 今後、標準仕様体系に取り込み予定図１．１．１

地域情報プラットフォーム標準仕様の体系-3-

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

１．１．２

業務ユニットの考え方

業務ユニットは、調達の最小単位であり、疎結合可能な範囲である。業務システムは「業務ユニット」
として整理され、異なるベンダ間での相互接続を目指すこととする。
業務ユニットは、自治体業務アプリケーションユニット標準仕様により、業務ユニット間で交換する
データを定義した業務ユニット間インタフェース仕様が規定される。従って、自治体業務アプリケーションユニット標準仕様の業務ユニット間インタフェース仕様で規定されていない通信は、地域情報プラットフォーム仕様の対象外である。
業務ユニット間インタフェース仕様は、「プラットフォーム通信標準仕様」における XML (Extensible
Markup Language) 定義仕様の手段をもって外部公開されるものとする。

１．１．３

業務ユニットの差し替えの考え方

業務ユニットの差し替えの要件を以下に記す。
【要件 1 】業務ユニット調達単位で差し替えが可能であること。
【要件 2 】地域情報プラットフォームの PF 通信機能（プラットフォーム通信機能）を介し、標準化された XML タグでシステム間のデータ連携が可能であること。
【要件 3 】標準化された業務ユニットインタフェースを実装していること。
※業務ユニットを差し替える際、業務ユニットのマスタ DB の移行、バッチ処理によるデータ連携の実装、および導入団体個別の業務機能カスタマイズなどについては、その必要に応じて、導入時での対応が必要である。

-4-

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

図１．１．２

１．１．４

業務ユニットの差し替えの定義

仕様の策定段階の前提条件

地域情報プラットフォームの仕様を策定するにあたり、下図に示す 5 段階のフェーズを定義した。これは、地域情報プラットフォームの要件を満たすための仕様策定順序を表しており、アーキテクチャ標
準仕様 V2.1 及びプラットフォーム通信標準仕様 V2.1 で規定されている【地域情報プラットフォームの段階について】
第 1 段階

業務ユニットの定義
業務ユニットに含まれる機能の整理

第 2 段階

業務ユニット間のデータ交換
業務ユニット間で流通するデータ項目の整理第 3 段階業務サービス連携
業務サービス（ユニットを構成する機能単位）間で流通するデータ項目の整理第 4 段階自治体内におけるワンストップサービスの実現
業務サービス連携をワンストップで実現するための仕様の規定

第 5 段階自治体間、民間連携におけるワンストップサービスの実現
自治体から見た外部団体とのデータ連携における各種要件の整理と仕様の確定

当ガイドラインでは、地域情報プラットフォームの第 1 段階～3 段階（データ交換）、第 4 段階（自治体内ワンストップサービス）を中心に調達仕様に必要な記載をする。第 5 段階の、自治体間、民間連携-5-

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

におけるワンストップサービスの実現に関しては、今後、実績を踏まえ記載する。

地域情報PFの要件(1) 業務ユニット単位の差し替え（マルチベンダ化）が実現できるICT基盤であること（業務ユニットを差し替えるための業務ユニットのインタフェース定義を含む）(2) 業務サービスの連携が実現できるICT基盤であること(3) ワンストップサービスをも実現するICT基盤であること（自治体内、自治体間、自治体と民間間）(4) 上記(1)(2)(3)のいずれかを 「開発」、「実行」、「運用」の観点で、仕様として規定すること（特定の実装物では無い）

業務サービスの連携を実現
業務ユニットの差し替えの実現
第１段階：業務ユニットの第１段階：業務ユニットの
定義
定義

第２段階：業務ユニット間の第２段階：業務ユニット間の
データ交換
データ交換

第３段階：業務サービス
第３段階：業務サービス
連携
連携

ワンストップサービスを含む業務サービス連携の実現
第４段階：ワンストップサービス
第４段階：ワンストップサービス
自治体内連携自治体内連携

他自治体

自治体
A社
A社
業務
業務
ユニットＡ
ユニットＡ

B社
B社
業務
業務
ユニットＡ
ユニットＡ

A社
A社
業務
業務
ユニットＡ
ユニットＡ

C社
C社
業務
業務
ユニットＢ
ユニットＢ

A社
A社
業務ﾕﾆｯﾄA
業務ﾕﾆｯﾄA

C社
C社
業務ﾕﾆｯﾄB
業務ﾕﾆｯﾄB

業務
サービス

業務
サービス

第５段階：ワンストップサービス
第５段階：ワンストップサービス
自治体内⇒自治体間⇒官民連携
自治体内⇒自治体間⇒官民連携
民間

A社
B社
C社
A社
B社
C社
業務ﾕﾆｯﾄA
業務ﾕﾆｯﾄA 業務ﾕﾆｯﾄB
業務ﾕﾆｯﾄB 業務ﾕﾆｯﾄC
業務ﾕﾆｯﾄC
業務
サービス

業務
サービス

業務
サービス

（自治体内）

地域情報PF
地域情報PF

地域情報PF
地域情報PF

地域情報PF
地域情報PF

地域情報PF
地域情報PF【標準対象】
・業務ユニットの粒度
・業務ユニット内の業務サービスの粒度【標準対象】
・インタフェース（業務ユニット）
・データ項目

【標準対象】
・インタフェース（業務サービス）
・サービス連携のためのビジネスプロセス制御【標準対象】
・ワンストップサービスのためのビジネスプロセス制御【標準対象】
・PF共通機能業務ユニットをサービス呼び出しにより連携する仕様及びプロセス制御
による連携仕様の明確化

自治体内のﾜﾝｽﾄｯﾌﾟｻｰﾋﾞｽのためのビジネスプロセス
制御仕様の明確化

地域も含めたﾜﾝﾝｽﾄｯﾌﾟｻｰﾋﾞｽのための認証やﾌﾟﾛｾｽ連携のため、PF共通機能仕様の明確化

業務ユニットの粒度と、交換されるデータ項目とインタフェース仕様の明確化。

図１．１．３

１．１．５（自治体間）（官民連携）

地域情報プラットフォームの要件

共同アウトソーシングとの関係

共同アウトソーシング事業と地域情報プラットフォームの関係については、相互に補完し合うものである。
共同アウトソーシング事業は、小規模自治体向けに自治体間で共同して運営するシステムにより、業務の効率を高め、システムに関わる経費を適正化していくもので、その過程において業務の標準化、プ
ロセスの可視化を推し進めるものである。
地域情報プラットフォームにおいて提示される様々な事項は、各自治体が「自治体 EA」等の取り組み
を進め、業務の標準化へ向けて努力する中で、具体的な指標となるものである。すなわち、地域情報プ
ラットフォームはこれらの取り組みを通じて作成される「全体最適」を指向した仕様等の基盤となるものである。
これより、自治体 EA の考え方から住民サービスの高度化を目指し最適な業務の見直しを進め、システ
ム連携やサイト間の連携を確保するために、地域情報プラットフォームを踏まえつつ、それをより安価かつ安定的に運用する具体的方法として共同アウトソーシング事業を捉えることができる。
地域情報プラットフォームそのものは、共同アウトソーシングを前提としたものではないが、地域情報プラットフォームに準拠したシステムであれば、段階的に共同化を進めることも容易になるなど相乗的な効果が期待されるところである。

-6-

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

１．１．６

対象とする自治体規模(人口規模)

本ガイドラインでは、人口数十万人規模の比較的大きな自治体における地域情報プラットフォーム仕様準拠のサービス基盤、業務アプリケーションの調達を想定している。また、行政区を持ち一部の業務内容が異なる政令指定都市の特性については考慮していない。
人口規模の比較的小さな自治体においては、現実的に対応できる範囲での本標準仕様への準拠が想定
される。

１．１．７

システム基盤について

地域情報プラットフォームは、①業務ユニットの差し替えが可能であること、②業務サービスの連携ができること、③ワンストップサービスが実現できることを目的とした通信基盤（技術仕様）である。
一方、一般的にシステム基盤とは、認証、決裁、運用、開発等の機能の統一化を実現した ICT 基盤を指している場合が多い。
本書では、地域情報プラットフォームに、これらの機能を追加した基盤をシステム基盤と呼ぶ。
図１．１．４にシステム基盤の概念図を示す。

１．１．８

PF 共通機能の扱い

単独自治体の庁外との通信を行うサイト間を跨った際に使用する PF 共通機能（プラットフォーム共通機能）について、技術仕様を明確にした段階であり、各ベンダが製品を提供するためには、今後時間を要することが想定される。従って現段階（平成 25 年 3 月）においては、サイト間を跨った際に使用する
PF 共通機能は調達の対象外とし、第 3 章技術解説で機能および利用方法を紹介するという扱いとする。
当機能群が調達可能となるための、周辺環境の整備や留意事項と併せて記述する。
なお、PF 共通機能はサイト内で使用する時刻同期機能である。これは、調達範囲となる。

業務ユニット
フロント系業務ユニット
電子申請

電子調達 ・・・

地域情報プラットフォーム（サービス基盤）の標準化範囲
住民認証
職員認証
基盤連携
・認証基盤
・決済基盤

バック系業務ユニット
住基

国保

ＰＦ通信機能ＰＦ通信機能共通系業務ユニット
・・・

決裁等

・・・

ＰＦ通信機能ＰＦ通信機能アプリケーション
開発標準

BPM機能（※）
PF共通機能（※）
・時刻同期
・認証・認可（サイト間）
・モニタリング（サイト間）

帳票管理
統合DB機能（※）

外字管理

ＰＦ通信機能

データ変換

・
・
・

・
・
・
運用管理
ハードウェア・ソフトウェア・周辺機器等
ネットワークシステム基盤

図１．１．４（※）はオプション機能

システム基盤の概念図-7-

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

複数の異なるシステム基盤同士でデータ交換を行う場合は、PF 通信機能を介して行われる。

Ａ基盤

PF通信機能PF通信機能Ｃ基盤

PF通信機能Ｂ基盤

図１．１．５１．２

複数のシステム基盤連携の概念図

法改正の考え方

本標準仕様は、今後の法改正に対して、適切な対応を実施していくこととする。
ただし具体的な、改版仕様の提供方法などは今後の検討による。

-8-

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

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

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

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

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

項

版数

1

2014.3.11

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

改版履歴

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

目次
２．調達仕様 ........................................................................... 3
２．１ 地域情報プラットフォームの調達について .................................................................................... 3
２．２ サービス基盤の調達 .......................................................................................................................... 12
２．３ プラットフォーム仕様準拠業務ユニットの調達 .......................................................................... 14
２．４ 導入体制.............................................................................................................................................. 21
２．５ 移行計画.............................................................................................................................................. 27

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

２．調達仕様２．１

地域情報プラットフォームの調達について

２．１．１ 地域情報プラットフォームのシステム構成(1)地域情報プラットフォームの全体アーキテクチャ
地域情報 PF を構成するシステム構成単位について説明する。下図は、地域情報 PF の論理的なシステ
ム全体アーキテクチャである。 複数のシステム構成単位がネットワークで接続し、PF 通信機能（プラットフォーム通信機能）で連携する構成である。なお、地域情報 PF の各導入パターンでの、具体的なシステム構成は異なる。

利用者(住民)⑥ フロント系業務ユニット

PF通信機能自治体ポータル／申請

WSDL① ＰＦ通信機能
ＰＦ通信機能業務ユニット

ＰＦ通信機能① ＰＦ通信機能③ BPM機能① ＰＦ通信機能
ＰＦ通信機能業務
ｻｰﾋﾞｽ

ＰＦ通信機能① ＰＦ通信機能
利用

提供

業務
ｻｰﾋﾞｽ

②
統合DB機能⑤
利用者（職員）①

共通系業務ユニット

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

業務
ｻｰﾋﾞｽ

業務
ｻｰﾋﾞｽ

⑤
バック系業務ユニット

利用者（職員）④ PF共通機能

図２．１．１

地域情報 PF の全体アーキテクチャ(2)地域情報プラットフォームのシステム構成単位
地域情報 PF を構成するシステム構成単位を下表に示す。

表２．１．１
区分
サービス基盤

業務ユニットシステム構成単位
名称①

PF 通信機能②

統合 DB 機能③

BPM 機能④

PF 共通機能⑤

業務ユニット（共通系、バック系）⑥

業務ユニット（フロント系（ポータル、総合窓口※等）※住民サービス向上の観点から各種行政サービスを一個所で受けられる窓口のことをいう－ 3 －地域情報プラットフォームガイドライン

地域情報 PF を構成するシステム構成単位について以下に解説する。
①PF 通信機能
PF 通信機能は、国際標準 SOAP (Simple Object Access Protocol) 仕様に基づくサービス通信機能であり、セキュリティや高信頼性通信機能等がオプションで選択できる。PF 通信機能は、業務ユニットや
BPM 機能、統合 DB 機能といった他のシステム構成単位の前提ソフトウェアとなり、PF 通信機能単独でシステム構成単位とはならない。
②統合 DB 機能
業務ユニット間で、データを一元的に利用（参照）する仕組みである。SOAP のサービス呼び出しより情報を提供するため PF 通信機能を前提として持つ。また、業務ユニットとの連携を行うため、標準化された業務ユニットインタフェースと同様のインタフェースを連携に必要な単位で実装している。実装方
式として【公開用 DB 方式】と【共通インタフェース方式】がある。統合 DB 機能は、オプションである（統合 DB 機能は、業務ユニット間のデータ連携の際に、性能、その他の要件から柔軟にデータ交換を行う時に必要に応じて採用を検討するオプション機能である）。
③BPM 機能
ビジネスプロセス(BP)の実行を管理するシステム。国際標準 WS-BPEL(Web Services Business Process
Execution Language Version 2.0)に基づく BP 定義に基づき、業務ユニットが提供するサービスインタ
フェースを呼び出し、ビジネスプロセスを実行する。また、BP 実行の依頼元となる業務ユニットから呼び出される業務サービスインタフェースを持つ。
システム構成上、サービス通信を実施するため PF 通信機能を前提として持つ。BPM 機能は、ワンストッ
プサービス等でサービスを順次実行する際に利用するオプションである。
④PF 共通機能
PF 共通機能（プラットフォーム共通機能）としては時刻同期機能がある。なお、サイト間で使用する
PF 共通機能の各機能（モニタリング機能、サービスの認証認可機能、ユーティリティ機能）は、第 3 章の技術解説にて述べる。PF 共通機能は、オプションである。
⑤業務ユニット（共通系、バック系）
独立して特定の業務を処理するユニットである。PF サービス通信を実施するため PF 通信機能を前提として持つ。他の業務ユニットや BPM 機能から呼び出される業務ユニットインタフェース（詳細は、自治体業務アプリケーションユニット標準仕様 【インタフェース一覧】を参照）を持つ。なお、業務ユニッ
トが BPM 機能から呼び出される業務サービスインタフェースを持つのは、BPM 機能で連携するワンストッ
プサービスを実現する時のみである。
⑥業務ユニット（フロント系（ポータル、総合窓口等）
利用者（住民）や外部機関からの申請やサービスを受け付ける業務ユニットで、共通系やバック系の業務ユニットや BPM 機能を呼び出し、処理結果を利用者（住民）や外部機関に提示する。
PF サービス通信を実施するため PF 通信機能を前提として持つ。

(3)システム構成単位となる PF 準拠製品について
システム構成単位となる PF 準拠製品は下記が想定される。なお、PF 準拠製品とは、ベンダの提供する－ 4 －地域情報プラットフォームガイドライン

製品（サービス基盤製品、業務ユニット製品）が、地域情報プラットフォームの標準仕様に準拠してい
る確認がなされた製品のことである。これらの製品は、OS やミドルウェア、アプリケーションなど複数の製品によりシステム構成単位を実現されることもあり、ベンダの製品提供形態に依存する。PF 準拠製品の詳細は、地域情報プラットフォーム準拠確認及び相互接続確認仕様を参照。
① 自治体業務アプリケーションユニット製品（自治体業務ユニットの何れかを実装した製品）② GIS ユニット製品③ 防災業務ユニット製品④ サービス基盤製品（PF 通信製品、BPM 製品、統合 DB 製品）⑤ 教育情報アプリケーションユニット製品
・業務ユニット
・GISユニット
・防災業務
ユニットのユニット系
製品

全て同一提供者（PF通信内部実装型）

全て同一提供者（製品分離型）

X社がY社を前提
ソフトウェアとして申請

A社業務処理（ｻｰﾋﾞｽIF 処理）（PF通信処理）A社業務処理（ｻｰﾋﾞｽIF 処理）

X社業務処理（ｻｰﾋﾞｽIF 処理）

A社PF通信機能

Y社PF通信機能

全て同一提供者

全て同一提供者

A社 PF通信機能（含、ミドルウェア範囲）

サービス
基盤製品

X社がY社、Z社を前提
ソフトウェアとして申請
Z社ｱﾀﾞ
ﾌﾟﾀ

X社業務
処理

Y社PF通信機能

Z社アダプタにより、
業務ユニットｻｰﾋﾞｽIF
処理を実現

全て同一提供者

全て同一提供者

A社 BP
処理機能

A社統合DB(公開用DB方式)処理機能

A社統合DB(共通IF方式)処理機能

A社 PF通信機能

A社PF通信機能

A社PF通信機能

PF通信製品

統合DB製品(公開用DB方式) 統合DB製品(共通IF方式)

BPM製品

X社がY社を前提
ソフトウェアとして申請
X社サービス基盤
製品処理機能Y社PF通信機能
BPM製品、統合DB製品（公開用DB、共通IF）

図２．１．２システム構成単位となる PF 準拠製品の構成

下図に、自治体内システムにおいて地域情報プラットフォームを実装した例を示す。

利用者端末（住民）

インターネット
業務ユニットサーバ(フロント系)
ポータル
ポータル// 電子申請
電子申請

業務ユニットサーバ
(住基)
住基
住基AP
(シミュレータ)

業務ユニットサーバ(国保)

業務ユニットサーバ
(児童)

国保
国保AP
(シミュレータ)

児童
児童AP(シミュレータ)

WebサーバWebサーバPF通信機能WebサーバWebサーバPF通信機能WebサーバWebサーバPF通信機能WebサーバWebサーバPF通信機能

APサーバ
APサーバ

DBサーバ
DBサーバ

APサーバ
APサーバ

DBサーバ
DBサーバ

APサーバ
APサーバ

DBサーバ
DBサーバ

APサーバ
APサーバ

DBサーバ
DBサーバ

BPM機能
BPMサーバ

統合DB機能BPMサーバ

DB
サーバ
Webサーバ

利用者端末（職員）

図２．１．３

APサーバ
APサーバ

DB
サーバ
WebサーバPF通信機能BPM機能（オプション）

APサーバ
APサーバ

統合DB機能（オプション）

自治体内システムの実装例－ 5 －PF通信機能地域情報プラットフォームガイドライン(4) 地域情報プラットフォームのシステム調達構成パターン
地域情報プラットフォームのシステム構成パターンは、8 パターンに分類される。下表に地域情報 PFのシステム構成パターンの一覧を示す。このように、地域情報プラットフォームで定義されている機能は、必要に応じて組み合わせて使用することができる。
なお、PF 通信機能はシステムの構成単位（業務ユニット、統合 DB 機能、BPM 機能等）に包含されていることが前提である。

表２．１．２

地域情報プラットフォームのシステム調達構成パターン一覧

調達構成

統合ＤＢ機能の使用

パターン

目的

パターン 1

業務ユニット間での《1-1》業務ユニット連携

データ交換、サービス

（直接）

なし

あり
《1-2》業務ユニット連携（統合 DB 機能）

連携を行う
パターン 2

ワンストップサービス《2-1》ワンストップ連携を行う（業務ユニット《2-2》ワンストップ連携（BPM）（BPM、統合 DB 機能）

間連携）
パターン 3フロント系業務ユニッ《3-1》電子申請/総合窓口連携

トと連携したワンス《3-2》電子申請/総合窓口連（BPM）

携（BPM、統合 DB 機

トップサービスを行う

能）（業務ユニット間連携）パターン 4

ワンストップサービス《4-1》照会・検索型連携《4-2》照会・検索型連携（統を行う（複数の業務ユ合 DB 機能）

ニットへの並行問い合
わせ）以下に地域情報 PF のシステム構成をパターン別に示す。
①パターン 1
《1-1》業務ユニット連携（直接）業務ユニット間のデータ交換や、業務サービス連携を実現するシステム構成である。
《1-2》業務ユニット連携（統合ＤＢ機能）
業務ユニット間のデータ交換や、業務サービス連携を統合 DB 機能を仲介して実現するシステム構成である。

業務ユニットA

業務ユニットD

業務ユニットA

業務ユニットB

業務ユニットE

業務ユニットB

業務ユニットC

業務ユニットF

業務ユニットC

図２．１．４

業務ユニットD
統合DB
機能

業務ユニットE
業務ユニットF

業務ユニット連携（直接、統合 DB 機能）のシステム構成－ 6 －地域情報プラットフォームガイドライン②パターン 2
《2-1》ワンストップ連携（BPM）
自治体内ワンストップサービスを実現する、ビジネスプロセス管理機能による業務ユニット間連携プ
ロセス連携のシステム構成である。
《2-2》ワンストップ連携（BPM、統合 DB 機能）
上記構成において、業務間データ交換を統合 DB 機能により実現する構成である。

《2-2》

《2-1》

BPM機能

BPM機能

業務ユニットB

業務ユニットA

図２．１．５

業務ユニットA

統合DB
機能

業務ユニットB

ワンストップ連携（BPM）のシステム構成③パターン 3
《3-1》電子申請/総合窓口連携（BPM）のシステム構成
自治体内ワンストップサービスを実現する、ビジネスプロセス管理機能による業務ユニット間連携プ
ロセス連携のシステム構成を下図に示す。フロント系業務ユニットとバック系業務ユニットを、BPM のビ
ジネスプロセスにより連携するシステム構成である。
《3-2》電子申請/総合窓口連携（BPM、統合 DB 機能）のシステム構成
上記構成において、業務間データ交換を統合 DB 機能により実現する構成である。

《3-1 》《3-2 》

フロント系業務ユニット

フロント系業務ユニット

BPM機能

業務ユニットA

図２．１．６

BPM機能

業務ユニットB

業務ユニットA

統合DB
機能

電子申請/総合窓口連携のシステム構成－ 7 －業務ユニットB

地域情報プラットフォームガイドライン④パターン 4
《4-1》照会・検索型連携のシステム構成
自治体内ワンストップサービスを実現する、他のシステム構成を下図に示す。フロント系業務ユニッ
トから、複数のバック系業務ユニットへの並行問合せを行い連携するシステム構成である。複数業務ユニットへの状況の並行問合せ等で使用される。
バック系業務ユニットに並行問い合わせする構成である。
《4-2》照会・検索型連携（統合 DB 機能）のシステム構成
上記構成において、統合 DB 機能へも問い合わせする構成である。

《4-1》

《4-2》

フロント系業務ユニット

業務ユニットA

フロント系業務ユニット

業務ユニットB

図２．１．７

業務ユニットA

統合DB
機能

照会・検索型連携のシステム構成－ 8 －業務ユニットB

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

２．１．２

オプション機能一覧

地域情報プラットフォームで規定される各機能について、自治体内とサイト間でのオプションの一覧と選択基準を示す。なお、サイト間（自治体間、官民連携）でオプション機能を選択して通信する場合
は、管理主体同士による事前調整を行う必要がある。

表２．１．３ オプション選択一覧表№

機能○:オプション選択可―:該当なし

サイト内

サイト間

仕様

1

OS

Windows,UNIX,Linux

必須

必須

2

インターネットプロトコル

IPv4

必須

必須

3

通信路セキュリティ

SSL3.0,TLS1.0

○

必須

4

転送プロトコルHTTP1.1

必須

必須

5

基本メッセージ

SOAP1.1

必須

必須

6

高信頼性メッセージング

WS-R1.1,WS-RM1.1

○

○

7

添付付メッセージング

本文内埋め込み、SｗA

○

○

8

BPM 機能WS-BPEL2.0

○

○

9

インタフェース定義

WSDL1.1

必須

必須

10

ビジネス文書定義

XML Schema1.0

必須

必須

11

署名認証

XML Signature 等

―

○

12

職責認証

XML Signature 等

○(※１)

○

13

サービス認証

WS-Security1.1,SAML2.0 等

○(※２)

○

14

サービス認可権限基盤技術

○(※２)

○

15

プライバシ情報公開

P3P,プライバシ情報公開技術

―

○

16

サービス監査証跡

サービス監査証跡取得技術

―

○

17

Web サービス情報の登録と検索

UDDI2.0 など

―

○

18

モニタリング機能

モニタリング技術

○(※２)

○

19

サービス＆BP 定義手法

デザインパターン定義等

○

○

20

統合 DB 機能公開 DB 方式、共通 I/F 方式○―※１ 自治体内で職責認証を行う場合は選択可。
※２ 自治体内での当該機能を使用する場合においては、仕様で示された技術を使用せず、既存技術等を利用することも可とする。
【オプション機能の用途と選択基準】
以下に、オプション機能の用途と選択基準を示す。
なお、表２．１．３のオプション機能には、PF 共通機能が含まれている（No.13、No.14、No.15、No.16、
No.17、No.18、No.19）。これらの PF 共通機能について、技術仕様を明確にした段階であり、各ベンダが製品を提供するためには、今後時間を要することが想定される。従って現段階においては、調達の対象外とする。それを踏まえた上で個別導入を検討する場合は、ベンダの製品提供状況を確認し、慎重な導入検討を行う必要がある。

－ 9 －

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

No.3．通信路セキュリティ
通信相手（サイト/マシン）の認証に使用する。通信路上の 2 点間の秘匿性確保の目的でも使用する。
HTTP Basic 認証におけるパスワード方式に比べセキュリティ強度が強い。
No.6．高信頼性メッセージング
SOAP 通信処理の信頼性を向上したい時に使用する。メッセージの送達保障（失敗時再送）、重複排除、
順序性保障の機能を持つので、SOAP 通信にメッセージが紛失したり、重複して到着してしまうことを防ぐことができ通信の信頼性を高められる。
No.7．添付付メッセージング
業務ユニット間で「添付書類」を送受信する時に使用する。事前に業務ユニット間で添付書類の送受信方式を決めておけば、確実に添付書類メッセージを処理することができる。
No.8．BPM 機能
ワンストップサービス等、一連の業務処理を複数の業務ユニットで連携して行う時に必要となる。ビ
ジネスプロセスの実行・管理を自動化できる利点がある。
No.11．署名認証
電子申請等の文書（デジタル）の正当性の保証を高める時に使用する。
No.12．職責認証
自治体が発行する公文書（デジタル）の正当性の保証を高める時に使用する。
No.13.サービス認証
ID 体系の異なるサイト（サーバ）間で、シングルサインオンを実現するときに使用する。名前寄せを防止できる等、セキュリティ強度が高い。
No.14．サービス認可
権限管理を別サーバで一元管理し、各業務サーバのアクセス制御を行う時に使用する。権限管理を集中化させることにより、各業務ユニットでのアクセス制御の設計を共通化することができる。
No.15．プライバシ情報公開
サイトを跨って個人情報を交換する場合に使用する。利用者が許諾した情報だけを管理することができるので、利用者のプライバシの保護に役立つ。
No.16.サービス監査証跡
サイトを跨る処理で証拠保全が必要なときに使用する。サイトを跨る処理の効率的な監査や、情報漏
えい時の原因の特定に役立つ。
No.17．Web サービス情報の登録と検索
複数のサイト間で、情報の一元管理（登録、更新、削除、検索、参照）を行う時に使用する。サイト
間で情報を迅速で安全に管理することができる。

－ 10 －

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

No.18.モニタリング機能
サイト(サーバ)を跨る処理をする時に、他サイト（サーバ）に依頼した処理の状況を確認したい時に使用する。トラブルの事前回避やシステム改善・サービス改善を策定する際に有効な情報を収集することができる。
No.19. サービス＆BP 定義手法
APPLIC（財団法人全国地域情報化推進協会）で策定される各種 XML 標準定義の設計手法を明確にしたい時に使用する。標準仕様を取り込み独自に拡張するときに役立つ。
No.20．統合 DB 機能
業務ユニット間で必要となるデータを統合的に管理する時に使用する。業務ユニット間でのデータ連携を効率的に行うことができる。統合 DB 機能の詳細は第 3 章 3.2 を参照。

－ 11 －

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

２．２

サービス基盤の調達

地域情報プラットフォームのサービス基盤とは、以下の 4 機能である。
機能単位もしくは、機能の組み合わせで調達を行うが、実装形態は規定されていないため、複数の製品提供者から情報を収集し、調達仕様を決めることを推奨する。

２．２．１

プラットフォーム通信機能

プラットフォーム通信機能（PF 通信機能）は、業務ユニットおよび業務サービスが標準インタフェー
スや標準規約（セキュリティ、メッセージ等）に準拠して連携を実現するための機能群である。以下の機能を実現できること。
(1) HTTP 通信（IPv4、HTTP1.1）(2) 通信セキュリティ（通信路暗号 SSL3.0(TLS1.0)、サーバ認証）(3) 通信セキュリティ（通信路認証 SSL3.0(TLS1.0)、クライアント認証）(4) 通信セキュリティ（通信路認証 HTTP のベーシック認証）(5) SOAP 通信（SOAP1.1、document/literal、WS-I ベーシックプロファイル 1.0）
(6) 高信頼性通信（WS-Reliability1.1、WS-ReliableMessaging1.1）(7) 高信頼通信（MEP 方式）(8) メッセージの XML 定義仕様（XML Schema

1.0、PF 仕様の XML プロファイル）(9) サービス I/F の XML 定義仕様（WSDL1.1、PF 仕様の XML プロファイル）

２．２．２

統合 DB 機能統合 DB 機能とは、業務ユニット間で必要となるデータを統一的に管理することで、業務ユニット間のデータ交換を効率的に実現する機能である。したがって、業務ユニット同士がデータ交換（情報を共有
または連携）できるための機能を有する必要がある。
統合 DB 機能の実装方式は次の 2 種類から選定することができる。
(1) 公開 DB 方式（業務ユニット相当の SOAP インタフェース）(2) 共通インタフェース方式
また、統合 DB 機能は、業務ユニットが利用する時の利用側インタフェースとして必要な単位で自治体
業務アプリケーションユニット標準仕様に準拠した SOAP の業務ユニットインタフェースを有するものとする。オプションとして SQL インタフェースの採用も可能である。

２．２．３

ビジネスプロセス管理機能

ビジネスプロセス管理機能（BPM 機能）は、自治体の業務サービスおよび自治体間、官民連携業務サー
ビスの実行を制御する機能であり、サービスを順番に連携させるタイプのワンストップサービスに利用できる。
業務サービスインタフェースを組み合わせてビジネスプロセスを組上げ、ワンストップサービスや高付加価値サービスを構築することができる。このとき、BPM 機能は、プラットフォーム通信標準仕様に従う機能内容でなければならない。また、プロセス定義のためのスクリプトは、プラットフォーム通信標
準仕様に従うものでなければならない。以下の機能を実現できること。
ビジネスプロセスの XML 定義仕様（PF 仕様指定の WS-BPEL2.0：基本アクティビティ（receive、reply、
invoke）対応）ビジネスプロセス－ 12 －

地域情報プラットフォームガイドライン(1) ビジネスプロセスの XML 定義仕様（PF 仕様指定の WS-BPEL2.0：構造化アクティビティ（sequence、
flow、if、while）対応）(2) ビジネスプロセスの XML 定義仕様（PF 仕様指定の WS-BPEL2.0：変数処理（assign、XPath1.0 利用可能）対応）(3) ビジネスプロセスの XML 定義仕様（PF 仕様指定の WS-BPEL2.0：エラーハンドリング（fault、
throw）
対応）

２．２．４

プラットフォーム共通機能

プラットフォーム共通機能は、サイト内や、さらに、異なるサイトに跨った業務サービスを連携する
際に必要となる共通的な機能群である。PF 共通機能について、技術仕様を明確にした段階であり、各ベンダが製品を提供するためには、今後時間を要することが想定される。従って現段階においては、(1)時
刻同期機能以外の PF 共通機能は、調達の対象外とし、第 3 章技術解説で機能および利用方法を紹介するという扱いとする。
(1) 時刻同期機能
地域情報プラットフォーム内で動作するサーバ等の各マシン間で時刻を一致させる機能である。時刻同期の方法として以下のいずれかの方法をとること。
ａ．外部 NTP(RFC1305 準拠)サーバを用意する（インターネット経由で接続）。自治体等の地域情報 PFのサイト毎に決定する。インターネット経由で正確な時刻に基づく NTP サーバとしては、例えば、
NICT 公開 NTP サービス (NTP サーバ名: ntp.nict.jp)

等がある。

ｂ．内部のＮＴＰサーバを準備し、外部ＮＴＰサーバとの同期をとる。W32Time サービス（NTP を使った Windows Time サービス）機能を使用。プロトコル：NTP(RFC1305 準拠)。
ｃ．サイト内の全てのマシンを NTP クライアントとして、②のサーバに接続する。

２．２．５

サービス基盤の調達にあたって

サービス基盤の調達には、サービス基盤構築に必要なハードウェア及びソフトウェアの調達および、システム等の設計、開発、搬入、据付、調整及び試験ならびに保守、教育支援等システム運用のための役務の調達が含まれる。
また、本書に明示していない物品及び役務については、システム調達要求仕様に合わせて、別途、調達が必要である。
サービス基盤の調達にあたっては、庁内システム全体のライフサイクルを考慮し、多段階に分けた調達を行っていくことが望ましい。

－ 13 －

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

２．３

プラットフォーム仕様準拠業務ユニットの調達

自治体が、地域情報プラットフォーム標準仕様に準拠した業務ユニットを調達する際、その業務機能要件を検討するにあたって、実際に必要または参考となる事項について下記に示す。各自治体においては、下記事項を参照の上、各業務ユニットの調達仕様を作成して頂きたい。
地域情報プラットフォームでは、「自治体業務アプリケーションユニット標準仕様」(*1)にて規定された業務ユニットに関して、「調達の最小単位を可能とするもの」と位置付けている。そこで注意して頂きたい点は、実際に調達される粒度としては、必ずしもユニット単位（一つずつ切り分けて）である必要はなく、たとえば、住民基本台帳ユニット・印鑑登録ユニットの 2 つを一括で調達するといったように、各自治体の実状に合わせて検討頂くことになる。
なお、本章は、地域情報プラットフォーム標準仕様に準拠した業務ユニットの調達に関連する必要事
項に限定して記載しているため、一般的に業務システムの調達に必要となる事項全てを網羅しているものではない。
(*1)「自治体業務アプリケーションユニット標準仕様」の位置付けについては、「1.1.1 ガイドラインの位置づけ」を参照のこと。

２．３．１

業務ユニットの調達を検討する際に必要となる前提事項「自治体業務アプリケーションユニット標準仕様」では、各業務ユニットが持つ機能(*2)、各業務ユニット間の連携データ項目(*3)、およびオンラインによるデータ連携のインタフェース(*4)を規定しており、同仕様に準拠した業務ユニット製品はそれらを実装している。自治体においては、ここで規定されていない業務機能や連携データ項目などに関しては、個別に検討し、調達仕様へ業務機能要件として反映する必要がある。
そのような場合の変更方針の基本的な考え方としては、下記の２点がある。
・同仕様の中の基本的あるいは共通的な業務機能やデータ項目については、極力変更しないことが望ましい。
・そのような中でも、やはり個別の変更が必要となる場合においては、業務機能やデータ項目の【変更】や【削除】よりも【追加】が望ましい。標準仕様との差異を把握し、管理する上で、わかりやすいからである。
なお、これらの標準仕様にて規定された項目範囲(*2)～(*4)を、自治体にて独自に変更される場合には、業務ユニットの差し替え容易性の低下にもつながることになるので、よく留意されたい。
(*2) 「自治体業務アプリケーションユニット標準仕様」の「業務１－４ 機能一覧」にて規定されているが、この機能一覧の基本的な考え方として、各業務ユニット同士におけるデータ連携を実現するに必要となる業務機能を中心に、必要最小限なものに集約している。
(*3)「業務１－７ インタフェース仕様」「業務１－８ データ一覧」にて規定されている。「インタフェース仕様」に関しては、他の業務ユニットと連携されるデータ項目（オンライン、バッチ）を提示し、「データ一覧」は、そのうちオンライン連携となるデータ項目に集約したものである。
(*4)「業務１－９ インタフェース一覧」にて規定されている。
「データ一覧」にて規定されたオンラ
イン連携用のデータ項目に関して、実際にそれらを連携するための実装方式（SOAP インタフェー－ 14 －

地域情報プラットフォームガイドラインス）を規定したものである。
また、同標準仕様にて規定されていない範囲（＝上記以外の部分）(*5)に関しては、適宜最適な仕様・方式を検討した上で、必要に応じて調達仕様へ盛り込むこととなるが、いずれにしても各自治体固有の改修は必要最小限に抑えることにより、業務ユニットの差し替えを、より容易にすることが可能となる。
(*5) 詳細については、後述の「２．３．３規定された範囲と規定されていない範囲」を参照のこと。
なお、同標準仕様で規定された業務ユニットにおいては、主な前提事項として以下のものがある。自治体においては、同標準仕様に準拠した業務ユニットの調達を検討する際には、まずは以下を踏まえて検討して頂きたい。
※「自治体業務アプリケーションユニット標準仕様」における主な前提事項
・住登外管理ユニットでは、各業務ユニットで扱う住登外者と法人の基本情報を共通的に管理する。
・住登外管理ユニットは、同標準仕様 V2.3 以前は、住登外者の世帯は必要な業務ユニットがそれぞれの業務ユニット内で管理することを前提としていたが、同標準仕様 V2.4 にて、住登外管理ユニット
内で住登外者の世帯を管理する仕様と管理しない仕様のいずれかを選択可能としている。なお、住登外管理ユニットが世帯を管理しない仕様の場合、各業務ユニットで世帯を管理しなければならない。
○世帯を管理する仕様の場合
住登外管理ユニット
基本情報

自ユニット内で管理する世帯の情報

自ユニット内で管理する

各業務ユニット
住登外管理ユニットから情報を取得する
住登外管理ユニットから情報を取得する○世帯を管理しない仕様の場合
住登外管理ユニット
基本情報

自ユニット内で管理する世帯の情報

自ユニット内で管理しない

各業務ユニット
住登外管理ユニットから情報を取得する
自ユニット内で管理する※矢印の組合せの調達は、問題がある。
・収滞納管理ユニットは、税（個人住民税、法人住民税、固定資産税、軽自動車税）、および国民健康
保険税（料）を対象としており、同時に口座情報管理の機能も持つ。これらの税以外の料金を扱う業
務ユニットはそれぞれ当該業務ユニット内に収滞納管理と口座情報管理の機能を持つこととする。
・送付先情報は、必要な業務ユニットがそれぞれ当該業務ユニット内で管理する。
・同標準仕様 V1.5 においては、庶務事務ユニットは人事給与ユニットのデータエントリシステムとして位置づけ、両ユニットは同時調達を前提としていたが、同標準仕様 V2.0 において、人事給与ユニッ
トにもデータエントリ機能を追加し、両ユニットは単独調達を可能としている。
・外字を有するデータ項目としては、「氏名（名称）」・「住所」項目とし、これ以外のデータ項目には基本的に外字を用いない。また、外字の発生源としては、「住民基本台帳」、「戸籍」、「住登外管理」の3 つの業務ユニットを想定している。

－ 15 －

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

２．３．２

根拠法令と法改正対応状況、および留意事項

各業務ユニットが持つ業務機能の根拠となる法令、および自治体業務アプリケーションユニット標準
仕様の改定時点における各業務ユニットの法制度改正への対応状況(*6)については、同標準仕様「業務１－２０

法改正対応状況と留意事項」を参照されたい。また、同標準仕様において前提となっている

各業務ユニット固有の留意事項に関しても「業務１－２０（同上）」にて確認願いたい。
自治体においては、それらを把握した上で、各業務ユニットの調達（業務機能要件）の検討に入る必要がある。なお、各業務ユニットが持つ機能概要については、同標準仕様「業務１－２ 業務ユニット概要説明」を参照のこと。
(*6)同標準仕様に関する今後の法改正への対応は、適切な対応を実施していくものとする。ただし具体的な、改版仕様の提供方法などは今後の検討による。

２．３．３

規定された範囲と規定されていない範囲

以下に、同標準仕様における規定範囲について示す。なお、各項目の規定されていない範囲について
は、各自治体に適宜最適な仕様・方式を検討した上で、必要に応じて調達仕様へ盛り込むこととされたい。
また、本章目では、自治体業務アプリケーションユニット標準仕様に準拠した業務ユニットの調達に関連する必要事項に限定して記載しているため、一般的に業務システムの調達に必要となる事項全般を網羅しているものではない。それらに関しては、自治体個別に検討し、必要に応じて調達仕様へ盛り込む必要がある。
（１） 業務ユニットの機能
各業務ユニットが備える機能については、同標準仕様の「業務１－４ 機能一覧」で示しているが、その実装方式（サービスの単位や詳細な機能など）については規定しない。また、基本的な考え方として、各業務ユニット同士におけるデータ連携を実現するに必要となる業務機能を中心に、標準として必要最小限なものに集約しているため、同機能一覧にて規定されていない業務機能については、各自治体にて個別に検討し、必要に応じて調達仕様へ盛り込む必要がある。
（２）業務ユニット間で連携するデータ項目、および各業務ユニットが所管（管理）するデータ項目
業務ユニット間で連携するデータ項目のうち、標準として妥当なデータ項目については、同標準仕様「業務１－７ インタフェース仕様」で規定しているが、それに含まれていない連携データ項目があれば、必要に応じて各自治体にて調達仕様へ盛り込む必要がある。また、各業務ユニット内で独自に管理する
データ項目（＝他の業務ユニットとの連携の対象とならないもの）については規定していない。
（３）業務ユニットの画面、帳票など各業務ユニットのオンライン画面の画面展開、ユーザインタフェース、各種帳票等は、同標準仕様では規定しない。各自治体にて個別に検討し、必要に応じて調達仕様へ盛り込む必要がある。
（４） バッチ処理
業務ユニット間のデータ連携のうち、バッチ処理にかかるデータ連携の方式は、処理効率化のために
自治体ごとに最適な実装方式を検討することとし、同標準仕様では規定しない。なお、連携するデータ
項目は、「業務１－７

インタフェース仕様」に準拠することにより、実装方式にかかわらず、業務ユニッ－ 16 －

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

ト間の連携を容易に実現することが可能となる。
（５）コード辞書
同標準仕様に準拠した業務ユニットにおいては、各業務ユニット間のデータ連携時に、「業務１－１３
コード辞書」で規定されたコード値に変換してデータ連携ができるものとする。ただし、コード値については、導入する自治体ごとに変更は可能なものとする。なお、その場合、一自治体内では統一したコー
ド辞書で運用することが望ましい。特に共通のコード辞書（例：年号、性別、住民種別等）の変更は全体に広く影響するので、極力変更しないでそのまま利用することが望ましい。
（６）共通 DB
複数の業務ユニットで共通的に利用する DB（例：住所辞書等）は、１カ所にて保持し、一自治体内では共通（統一）的なアクセス方式で利用することを推奨する。ただし内容や形式は多様であるので、同標準仕様では、具体的なデータの内容、種別、辞書名、およびアクセス方式等は規定しない。
（７）業務ユニット横断的な検索機能
自治体業務においては、複数の業務ユニット（たとえば住民基本台帳、住登外管理等）にまたがって、「名前」や「生年月日」等で人の検索を行う機能の必要性が考えられる。しかし、検索の要件は多様であるため、同標準仕様では、このような検索方式については、具体的に規定しないものとする。このような複数業務にまたがった機能の仕様は、各自治体において、必要に応じて検討し、調達仕様へ盛り込
むものとする。
（８）業務ユニット間のデータ連携におけるサービス呼び出しの実装「業務１－９

インタフェース一覧」でデータを提供する側の業務ユニットの SOAP インタフェースの実装方式を規定しているが、データを参照する側の業務ユニットの実装方式は規定していない。業務ユニット間において、どこでどのようにオンライン連携するのかを充分に検討の上、実装すること。

－ 17 －

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

２．３．４

業務ユニットを実際に導入する際に検討すべき関連事項

同標準仕様に準拠した業務ユニットを実際に導入するにあたり、自治体側で検討すべき事項の中で、業務ユニットの調達に際しても予め検討しておく必要がある主な関連事項、およびその考え方の例を示す。
なお、本章目では、自治体業務アプリケーションユニット標準仕様に準拠した業務ユニットの導入に関連する検討事項に限定して記載しているため、一般的に業務システムの導入に必要となる検討事項全てを網羅しているものではない。それらに関しては、必要に応じて自治体個別に導入ベンダ含めて検討して頂きたい。

（１）業務ユニット導入・運用における同標準仕様の考え方とその利用①番号管理の検討
人（住民、住登外、法人等）に関しては、一自治体内では統一的なルールによるユニークな番号（同標準仕様では「識別番号」と称す）で管理することとし、異なる人に同じ番号が付番されることが無いようにすること。ある人に付番された番号は、その人が住民基本台帳、住登外管理のどこで管理されるにしても同じ番号のままであり、これらの間を移っても（例えば住民基本台帳に登録されていた住民が転出して住登外管理に登録される等の場合でも）同じ番号のままとする。ただし、具体的な番号体系（桁数やチェックデジット等）と付番管理の方式に関しては、自治体ごとに異なることが多いため、同標準仕様では規定しないが、導入の際に最適な方式を検討し、採用すること。また、各業務ユニットにおいては、人の同定をどんな方法で行うかも適宜検討し、実施すること。
②「独自領域」の利用検討
住民基本台帳と住登外管理は人に関する基本的な情報を扱うが、そこで管理するデータ項目に関しては、基本的な項目以外にも各種の要望があり、自治体ごとにそれぞれ要件が異なる。その中で特に、業務的な運用上の都合で、人の情報を何らかの属性で識別するようなフラグ的な項目を持つことも考えられる。
（例えば窓口業務で、このフラグが立っている人に対しては特別な対応をする等のケース）このよ
うな要求に対応するために、「独自領域」として一定の領域を同標準仕様として確保しており、ここに自治体ごとの固有の項目を定義することができる。
「独自領域」の利用方法は特に定めておらず、無理に利用する必要もない。利用方法は個々の自治体で何らかの具体的な要件が出てきた時に決まることを想定している。
③「異動中区分」の利用検討
住民基本台帳の業務ユニットにおいてオンラインで異動処理中のデータは、異動処理の開始時に「異動事由」と共に「異動中区分」に「1」をシステムで自動的にセットすることにより、現在その「異動事由」で異動処理中であることを示すことができる。異動処理が終了すれば、「異動中区分」を「0」にリセットする。異動処理実施中の一定時間だけ、「異動中区分」に「1」が立っている（ロックしている）
ことになる。同標準仕様として用意しているこの仕組みを、必要に応じて利用することにより、他の業
務ユニットが、住民基本台帳を参照しながら自業務の更新処理を行おうとする際、業務的に矛盾や不整合を起こさないように、住民基本台帳の異動処理が終了するまで自業務の更新処理を待つ、といった排他制御的な作りこみの実装が可能となる。例えば国民健康保険ユニットがある人の国保資格の異動を行おうとしたところ、対象者は住民基本台帳ユニットで「転居」の異動処理中であったため、住所や世帯構成の不整合を避けるため、更新処理を一時中止する、といったケースでの利用が考えられる。

－ 18 －

地域情報プラットフォームガイドライン④「異動年月日」の利用検討
同一人物の住民基本台帳データあるいは住登外・法人のデータを、複数取り出してきて一緒に扱う場
合に、データの新旧が容易に把握できるようにするために、同標準仕様では、データの登録・更新日付
を「異動年月日」として持っている。必要に応じて、この「異動年月日」でソートすることによってデー
タを時系列で並べることができる。蓄積された複数のデータの中から、最新のデータを判定して抽出することにも利用できる。住民基本台帳、住登外管理の各業務ユニットにおいては、最新のデータを登録・更新する際に、異動年月日に日付時間情報をセットする必要がある。
⑤｢宛名管理｣の検討
自治体では、業務ユニットをまたがって共通的に人の基本的な情報（氏名・住所など）を管理するいわゆる「宛名管理」機能を実現していることが多い。これは住民基本台帳ユニット・住登外管理ユニットを中心に、複数の業務ユニットの情報を合わせて管理することによって実現することができる。ただしその実現方法に関しては、「宛名管理」の利用目的・方法によって、管理すべき項目・関連する業務ユニットの範囲・実装方式が自治体ごとに多種多様であると考えられるので、大変重要な要素ではあるが、同標準仕様では規定しないこととしている。
「宛名管理」機能に関しては、必要に応じて個々に最適な実現方法を検討されたい。
⑥複数業務ユニットにて共有利用するデータの管理について
同標準仕様における住登外管理のデータ項目（住登外者、法人）は、実際の運用において、複数の業
務ユニットで同じデータを共有して利用することを想定しているが、データの更新・削除を行う際に、各業務ユニットの業務に支障をきたすことが無いように、更新・削除による影響範囲を把握できるように、同標準仕様では、次のような「最初登録業務ユニット」および「利用業務ユニット」のしくみを準備している。その必要性を検討の上、適宜利用されたい。
・まず、ある業務で住登外者または法人のデータを最初に登録する際に、その業務（業務ユニット番号）をセットする。
「最初登録業務ユニット」の業務ユニットがそのデータのいわばオーナーである。
・次に他の業務ユニットが同じ人物のデータを業務の対象にしようとする場合、「利用業務ユニット」の該当業務の箇所にフラグ「1」をセットする。こうすることによって、この業務ユニットもこのデータの利用業務ユニットのひとつであることを示すことができる。
・もし将来、この人物のデータが不要になって、削除をしようとする際には、利用業務ユニットそれぞれの利用状況を確認の上、削除してもよいかどうかを確認することができる。
なお、「利用業務ユニット」項目上において、各業務ユニットが項目の何桁目のフラグに対応しているかの対応づけは、あらかじめ決めておく必要がある。

（２）業務ユニットの導入・運用におけるその他検討事項①住登外管理の管理体制の検討
同標準仕様における住登外管理は、複数業務にまたがって利用するものであるが、住登外管理ユニッ
トのシステム管理責任部門と住登外情報・法人情報の管理責任部門は、自治体内にて事前に明確に定めておくことを推奨する。
②外字への対応の検討
外字を持つ業務データ項目等については、2.3.2 章に記載しているが、外字全体に関する対応方針の検討にあたっては、「プラットフォーム通信標準仕様」を参照の上、各自治体の既存の業務システムとの整合も配慮し、十分な検討が必要である。
－ 19 －

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

業務ユニットの導入に関する検討関連事項は以上であるが、これ以外に、自治体の業務運用において導入の必要性が高いと想定される各種サービス(*7)についても、各自治体において必要に応じて検討して頂きたい。それらサービスのサンプルとして、業務ユニットを活用したユースケース例を、第 4 章の4.1 節に紹介しているので参照して頂きたい。
(*7)たとえば、複数の業務ユニット（住民基本台帳、税系、福祉系など）にまたがって個人の情報を総合的に照会するサービスなど。

－ 20 －

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

２．４

導入体制

本章では、地域情報プラットフォーム導入時における調達者体制、ベンダ体制について記述する。
なお、この２．４導入体制に示す内容は一例であるため、実際は本書で示す内容を参考として個々の団体の状況に応じた体制づくりが必要となる。本章では「１．１．６

対象とする自治体規模(人口規模)」に示すとおり、人口数十万人規模の比較的大きな自治体における地域情報プラットフォーム導入を想定して記述しており、人口規模の比較的小さな自治体においては、自治体の実情に即した対応が必要となる。
また、一般的な情報システム導入時における体制について詳細に記述するものではなく、地域情報プ
ラットフォーム導入にあたっての留意点を中心に記載する。

２．４．１

調達者体制

地域情報プラットフォーム導入時における調達者体制について、関連部門と主な役割を以下に示す。

表２．４．１
部門
CIO
CIO 補佐官

情報化主管部門

主要
な部
門

情報システム部門

業務主管部門

全庁横断的意志決定チーム

調達者体制における関連部門と主な役割
主な役割
・ 自治体の情報化統括責任者であり、自治体の情報化戦略および地域情報プ
ラットフォームを含む情報システム調達の最終責任者。
・ CIO、および情報化主管部門に対し、専門的な見地から支援を行う。
・ 自治体の情報化戦略の主管部門であり、地域情報プラットフォームを含む
情報システム調達の主体となる部門。
・ 調達フェーズにおいては、調達仕様書の作成及び作成支援等を行う。また、調達フェーズにおける全体統制を行う。
・ 構築フェーズにおいては、全庁横断的意志決定チーム、プロジェクト管理
チームの事務局を担当する場合が多い。
・ 庁内で共通的に使用するネットワーク等のインフラや基盤系情報システ
ムに関する構築、運用、保守を主管する。地域情報プラットフォーム導入
後はサービス基盤の所管部門となる。
・ 調達フェーズにおいては、サービス基盤等のシステム共通部分について、調達仕様作成及びレビュー等を行う。
・ 構築フェーズにおいては、サービス基盤等のシステム共通部分について、仕様に関する確認・検討・試験、および運用に関する確認・検討を主体となって行う。
・ 業務ユニットを所管する部門であり、実際に情報システムを利用して住民サービスの提供等を行う部門。
・ 調達フェーズにおいては、業務ユニットの調達仕様の作成及びレビュー等を行う。
・ 構築フェーズにおいては、業務ユニットの仕様に関する確認・検討・試験、および運用に関する確認・検討を主体となって行う。また、業務ユニットのデータ移行について、検討および一部作業を行う。
・ 全庁にまたがる情報化戦略に関する意志決定を行う。通常、組織体制図上の関係する各部門からの参加メンバーにより構成される。
・ 調達フェーズにおいては、調達仕様書の最終レビュー等を行う。
・ 構築フェーズにおいては、プロジェクト全体に関わる事項等について意志決定を行う。

－ 21 －

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

部門

関
連
す
る
部
門

主な役割

プロジェクト管理チーム

・ 調達後の構築フェーズにおいて、プロジェクト管理（進捗管理、品質管理等）を実施する。通常、自治体、受託者の双方の参加者から構成される。

財政部門

・ 情報システムの調達における予算審査等を実施する。

総務部門

・ 情報システム調達を含む購買に関連する契約管理等を実施する。

首長
議会
自治体住民

２．４．２

・ 自治体の経営における最高責任者。情報システムの調達において、政策面で最終的な意志決定を行う。
・ 自治体の立法機関。情報システム調達における予算について、議決による意志決定を行う。
・ 情報システムを活用した住民サービスを受ける主体であり、パブリックコ
メントや選挙等を通じて、直接・間接的に情報システム調達に対する意志を表明する。

ベンダ体制

地域情報プラットフォーム導入時におけるベンダサイドの体制について、必要となるベンダと主な役
割、各々ベンダに要求される能力、および留意点を以下に示す。また、本項では物品のみを提供するベンダは除いている。
（１）必要となるベンダと主な役割
地域情報 PF 導入時におけるベンダサイドの体制について、必要となるベンダと主な役割を以下に示す。

表２．４．２
ベンダ・・
導入支援
コンサルタント
全
体
・
イ
ン
フ
ラ

・

・

システム基盤
構築ベンダ

・
・
・

・

必要となるベンダと主な役割
主な役割
情報化主管部門・情報システム部門を支援し全体的な導入計画の策定支援を行う。
調達フェーズにおいては、個々のベンダ、機器の調達仕様作成支援を行う。
構築フェーズにおいては、全庁横断的意志決定チーム、プロジェクト管理チームと協働して全体的な進捗管理支援、問題管理支援、調整支援を行う。
本ベンダを調達しない場合は、情報化主管部門・情報システム部門において本役割を全て担う必要がある。また、自治体側の体制・予算を考慮して上記内容から発注範囲を限定することも一般的である。
システム基盤について、設計・構築作業を行う。
システム基盤について、構築後の保守・運用を行う。
システム基盤に必要な物品（ハード製品・ソフト製品）については、本ベンダが必要な物品一覧（原則としてスペック指定）を行い、別途、競争的な調達を行うことが望ましい。
本ベンダを調達しない場合は、情報システム部門において本役割を全て担うか、住民基本台帳等の主要業務ベンダに併せて担わせる必要がある。

－ 22 －

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

ベンダ・

ネットワークベンダ

・
・

・
・

データセンタ・・・・

保守・運用統括ベン
ダ

・
・
・
・

○○業務
コンサルタント
・

・
業
務
ユ
ニ
ッ
ト

・
新規
○○業務ベンダ・・既存○○業務ベンダ

主な役割
既存ネットワークの地域情報プラットフォーム対応について、現状調査、
ToBe モデルの設計、移行計画の策定、移行・構築作業を行う。
ネットワークについて、構築後の保守・運用を行う。
ネットワークに必要な物品（ハード製品・ソフト製品）については、本ベンダが必要な物品一覧（原則としてスペック指定）を行い、別途、競争的な調達を行うことが望ましい。
本ベンダを調達しない場合は、情報システム部門において本役割を全て担うか、システム基盤構築ベンダに併せて担わせる必要がある。
地域情報プラットフォーム対応に関する機器の設置スペース、設備、電源等の提供、及び、機器等の運用・管理等におけるオペレータ業務を行う。
機器を自庁舎内に設置しない場合に調達が必要となる。
単独でデータセンタを調達する選択肢と、共同アウトソーシングを活用する選択肢が存在する。
システム基盤構築ベンダに併せて担わせる選択肢も存在する。
保守・運用には上記の全てのベンダの関与が必要であるが、保守・運用の全体を管理・統括するベンダも必要となる。
本ベンダを調達しない場合は、情報システム部門において本役割を全て担うか、システム基盤構築ベンダに併せて担わせる必要がある。
業務主管部門を支援し業務システムの導入計画の策定支援を行う。
調達フェーズにおいては、業務システムの調達仕様作成支援を行う。
構築フェーズにおいては、業務システムの仕様に関する確認・検討・試
験、および運用に関する確認・検討の支援を行う。また、業務システムのデータ移行についての検討を支援する。
本ベンダを調達しない場合は、業務主管部門において本役割を全て担う
か、導入支援コンサルタントに併せて担わせる必要がある。また、自治体側の体制・予算を考慮して上記内容から発注範囲を限定することも一般的である。
地域情報プラットフォーム対応の業務ユニットを用いて最小限のカスタ
マイズによる業務システムの設計・構築作業を行う。
業務システムに必要な物品（業務ユニットを構成するソフトウェア製品
等）については、本ベンダが必要な物品一覧（原則として製品指定）を行い、別途、競争的な調達を行うことが望ましい。
既存の業務システムからの移行について、移行計画の策定と移行・構築作業を行う。
本ベンダを調達しない場合は、業務主管部門・情報システム部門において本役割を全て担う必要がある。

・ 既存の業務システムからの移行について、移行計画の策定を既存システ
ムの観点から支援する。
・ 既存の業務システムからのデータ移行について、データの整備・抽出作業を行う。
・ 本ベンダを調達しない場合は、業務主管部門・情報システム部門において本役割を全て担うか、業務コンサルタント・新規業務ベンダに併せて担わせる必要がある。

－ 23 －

地域情報プラットフォームガイドライン（２）ベンダに要求される能力
地域情報ＰＦ導入時におけるベンダサイドの体制について、ベンダに要求される能力を以下に示す。

表２．４．３
ベンダ

導入支援
コンサルタント

全
体
・
イ
ン
フ
ラ

システム基盤構築
ベンダ

ネットワークベンダ

データセンタ

・
・
・
・
・
・

・
・
・
・
・

・
・
・
・
・

・
・
・
・

ベンダに要求される能力要求される能力
地域情報 PF への理解と知識・経験。
自治体業務への理解と知識・経験。
公共分野における IT 調達の方針・動向への理解と知識・経験。
コンサルティング能力と経験。
プロジェクト管理の能力と経験
特に以下の技術への知見と経験が望ましい。
インフラ基盤（高信頼性設計、性能設計、仮想化設計等）
IT ガバナンス・IT コンソリデーション
セキュリティ（ネットワークセキュリティ、SSO 等）
運用・管理（構成管理、バックアップ、監視、障害対策等）
SOA 技術（Web サービス関連技術、ESB、BPM、サービス管理等）
地域情報 PF への理解と知識・経験。
自治体業務への理解と知識・経験。
プロジェクト管理の能力と経験
インフラ設計・構築の能力と経験。
特に以下の技術への知見と経験が望ましい。
インフラ基盤（高信頼性設計、性能設計、仮想化設計等）
IT ガバナンス・IT コンソリデーション
セキュリティ（ネットワークセキュリティ、SSO 等）
運用・管理（構成管理、バックアップ、監視、障害対策等）
サービス基盤構築に係る SOA 技術（Web サービス関連技術、ESB、BPM、サービス管理等）
地域情報 PF への理解と知識・経験。
自治体業務への理解と知識・経験。
プロジェクト管理の能力と経験
ネットワーク設計・構築の能力と経験。
特に以下の技術への知見と経験が望ましい。
インフラ基盤（高信頼性設計、性能設計等）
セキュリティ（ネットワークセキュリティ、SSO 等）
運用・管理（構成管理、バックアップ、監視、障害対策等）
対災害性、セキュリティ対策に優れた設備、電源等の提供
プロジェクト管理の能力と経験
機器等の運用・管理等におけるオペレータ業務の能力と経験
特に以下の技術への知見と経験が望ましい。
インフラ基盤（高信頼性設計、性能設計、仮想化設計等）
セキュリティ（ネットワークセキュリティ、SSO 等）
運用・管理（構成管理、バックアップ、監視、障害対策等）－ 24 －

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

ベンダ

保守・運用統括ベンダ○○業務
コンサルタント

業
務
ユ
ニ
ッ
ト
新規
○○業務ベンダ

既存○○業務ベンダ

２．４．３

・
・
・
・
・

・
・
・
・
・
・
・

・
・
・
・
・

要求される能力
地域情報 PF への理解と知識・経験。
自治体業務への理解と知識・経験。
プロジェクト管理の能力と経験
インフラ設計・構築の能力と経験。
特に以下の技術への知見と経験が望ましい。
インフラ基盤（高信頼性設計、性能設計、仮想化設計等）
IT ガバナンス・IT コンソリデーション
セキュリティ（ネットワークセキュリティ、SSO 等）
運用・管理（構成管理、バックアップ、監視、障害対策等）
SOA 技術（Web サービス関連技術、ESB、BPM、サービス管理等）
地域情報 PF への理解と知識・経験。
自治体業務への理解と知識・経験。
公共分野における IT 調達の方針・動向への理解と知識・経験。
コンサルティング能力と経験。
プロジェクト管理の能力と経験
対象業務、業務システム、業務ユニットへの知見と経験
特に以下の技術への知見と経験が望ましい。
セキュリティ（ネットワークセキュリティ、SSO 等）
運用・管理（構成管理、バックアップ、監視、障害対策等）
SOA 技術（Web サービス関連技術、ESB、BPM、サービス管理等）
地域情報ＰＦへの理解と知識・経験。
自治体業務への理解と知識・経験。
プロジェクト管理の能力と経験
対象業務、業務システム、業務ユニットへの知見と経験
特に以下の技術への知見と経験が望ましい。
セキュリティ（ネットワークセキュリティ、SSO 等）
運用・管理（構成管理、バックアップ、監視、障害対策等）
SOA 技術（Web サービス関連技術、ESB、BPM、サービス管理等））－（既存ベンダであり、調達時に必要な能力は評価されていると考えられるた
め省略）

体制上の留意点

地域情報プラットフォーム導入にあたっての体制上の留意点を以下に示す。
（１）地域情報プラットフォーム標準仕様に関する理解
地域情報プラットフォームを導入する場合、調達仕様は地域情報プラットフォーム標準仕様がベースとなるため、調達仕様の策定にあたっては、地域情報プラットフォーム標準仕様の内容を踏まえ、調達を行う自治体の現状のシステム仕様との差異を考慮し、適切な調達仕様の策定、構築時の仕様検討を行うことができる体制が求められる。
（２）セキュリティ、個人情報保護に関する検討
地域情報プラットフォーム標準仕様は、他自治体や民間企業との連携も見据えた仕様となっており、導入にあたっては自治体全体、もしくは地域全体の最適化を意識したセキュリティ、個人情報保護の検討が必要となるため、全庁的なセキュリティ、個人情報保護に関する検討を十分に行うことができる体制が求められる。
－ 25 －

地域情報プラットフォームガイドライン（３）業務横断的な検討体制
地域情報プラットフォーム標準仕様においては、業務ユニット間インタフェースの標準化により、業務ユニット間連携の構築を容易に行えることを目標としているが、業務ユニット間連携に関する検討が不要になるということではない。また、文字（外字等の扱い）、共通コード等、ワンストップサービス導入等、特定業務システムのみでは解決できない要素もあり、業務横断的な検討を十分に行うことができる体制が求められる。また、業務主管部門の体制（役割分担）、業務システムの調達単位、業務ユニットの単位等において整理が必要となる場合も想定され、この点についても業務横断的な検討を十分に行うことができる体制が求められる。
（４）マルチベンダによる構築時の留意点
地域情報プラットフォーム標準仕様においては、特定ベンダに依存することのないオープンな仕様を採用するなど、マルチベンダ化の促進を目指した仕様となっている。こういったマルチベンダによる協働作業では、責任分界点の明確化による「抜け」の発生防止に特に注意が必要となり、責任分界点の整理・定義に加えて、全体を取りまとめる責任者の明確化にも注意が必要となる。全体を取りまとめる責
任は、情報化主管部門・情報システム部門、もしくは主要な業務主管部門が担うのが原則であるが、導入支援コンサルタント、業務コンサルタント、システム基盤ベンダ、保守・運用統括ベンダ等にも一定の役割を担わせて、自治体側の負荷を軽減することも有効である。
（５）長期視点に立った計画の策定と複数プロジェクトの管理
地域情報プラットフォームを全面的に導入する場合には広範囲における情報システムの入れ替えを行うことになるため、通常、長期間にわたって複数のプロジェクトを並行的、段階的に進めることになる。
自治体の情報化戦略の主管部門である情報化主管部門では、長期的な視点から導入計画を策定し、また、全体最適の視点に立って複数のプロジェクトの整合を図るなど適切なマネジメントを行っていく役割が求められる。この際に、CIO 補佐官や導入支援コンサルタントの支援により、自治体側の負荷を軽減することも有効である。

－ 26 －

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

２．５

移行計画

２．５．１ 移行方針の策定
地域情報プラットフォーム導入のスケジュール策定において特に留意すべき点は既存業務システムからの移行であり、そのための基本的な方針を決定しておく必要がある。基本方針策定上留意すべき主要な項目は次のとおりである。
（１） 既存業務システムと業務ユニットの粒度（機能範囲）の調整：
地域情報プラットフォームの基本的な連携単位は業務ユニットであり、既存業務システムから移行、
あるいは併存する時には両者の粒度（カバーする機能の範囲）の調整が必要であるが、可能な限り標準仕様に準じた粒度が望ましい。
（２） 標準インタフェース仕様と既存業務システムデータの整合性への対応：
業務ユニットへのデータ移行および併存する既存業務システムとのデータ交換においては、標準イン
タフェースとの整合性が求められる。既存業務システムにおけるデータ項目の過不足や定義の相違等への対応のために変換ルールや独自領域の利用ルールを定める必要がある。データ項目定義の相違について代表的なケースを以下にあげる。
—

同一データ項目で長さや属性が異なるケース—

コードデータ（続柄、異動事由、年号等）の定義や割当てが異なるケース—

データ項目の分割、区分方法が異なるケース（住所と方書き、姓と名等）—

レコードやデータの状態や属性を固有のフラグで表現するケース—該当しないデータ項目の記録方法（ブランク、Null 等）特に金額等数値データは要注意

具体的な検討事項は「２．５．３既存業務システムとの整合性について」で示す。
（３） 識別番号の統一
内部事務系の業務ユニットを除く業務ユニット間の業務ユニットインタフェースはサービス要求側業
務ユニットが個人または世帯の識別番号を提供側業務ユニットへ指定するルールとなっている。したがって要求側業務ユニットは何らかの方法で個人または世帯の識別番号を特定する必要があるが、既存
業務システムから移行するデータにこれ等の識別番号が含まれていない可能性がある。したがって地域
情報プラットフォームへの移行に当っては個人、世帯、法人等について全業務共通の識別番号を定め、名寄せ等の作業によってこの識別番号を各業務ユニットのデータベースに取込む必要がある。
この識別番号として既存住民基本台帳システムや住登外管理システムの個人、世帯番号を用いることが一般的であるが、自庁内でのみの識別番号であることから、他行政機関や民間とのサイト間連携を行う場合には、他機関共通でユニークとなる番号を利用する可能性を検討する必要がある。
（４） 文字セットの統一
地域情報プラットフォームでは、文字セットについては、JIS X0213:2004 の範囲を前提としている。
しかし、当面の経過措置として自治体内の合意に基づき、「内字」を JIS X0208 の文字に限定することや、
JIS X0213:2004 中の第一、第二水準文字に限定することができるものとしている。したがって既存業務システムで用いられている外字（ベンダ選定文字とユーザー選定文字）を含むデータの移行・交換においてもこの範囲の文字セット(JIS X0213:2004)に置換え・変換するのが前提である。しかし、書面で外部に出る字形の継続性や証明書類の証憑性の点で、これらの外字を含んだ、全ての業務ユニットで使用する文字セットについては、JIS X0213:2004 の範囲を前提に外字を追加していく形で拡張していくことが望ましい。この場合、外字の同定作業を行う必要があるが、特にベンダ選定文字はベンダによって文字セットが異なるため、既存業務システムが複数の異なったベンダのシステム環境で稼働している場合
は同定に注意を要する。
－ 27 －

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

また、他行政機関や民間とのサイト間連携を行う場合を考慮すると、新しく定義する文字セットは可
能な限り独自性を廃し、地域情報プラットフォーム内字、あるいは一般的に認識されている文字セットに準拠することが望ましい。例えば戸籍統一文字や法務省統一文字などが考えられる。
なお、地域情報プラットフォームの文字セットに関しては、「プラットフォーム通信標準仕様・３．３
メッセージの XML 定義仕様（３）文字コード・外字に関する規則」を参照。

２．５．２

段階的移行

（１） 段階的移行の必要性
地域情報プラットフォームによる行政情報システムの構築では、多くの場合既存行政情報システムからのアプリケーションの移行が必要となるが、多様な既存行政情報システムのアプリケーションを一斉に移行することは容易ではない。その主な理由は次のとおりである。
—

既存行政情報システム環境の多様性（汎用機、オフコン、CS 等）—

アプリケーション運用主体の多様性（情報システム部門、業務主管部門、外部委託先等）—

移行ワークロードおよびコストの集中—システム機器リースの満了—

アプリケーション改修の影響（新規制度の創設、既存制度の大幅な改正等）

したがって、地域情報プラットフォーム導入によって達成すべき目標と移行すべきアプリケーションの優先度等により行政情報システム全体の移行計画を策定し、その計画に沿って段階的に移行することが現実的である。
（２） 移行の形態
地域情報プラットフォーム基本説明書にあるとおり、既存行政情報システムの地域情報プラット
フォーム環境への移行の形態にはリホスト、リライト、リビルド（リエンジニアリング）が考えられる。
これ等の移行形態の選択は、移行コスト、既存業務システムの状態、業務継続性等によって、概ね図２．
５．１の様に類型化することができる。なお、図２．５．１において実線矢印は既存業務システムと地域情報プラットフォーム環境の併存を意味し、破線矢印は地域情報プラットフォームへの業務ユニットの置き換えを意味する。

－ 28 －

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

既存業務システムの環境
業務システム業務システム業務システム業務システム業務システム業務システム

A

B

C

D

E

F

① 併存・
統合ＤＢ連携②③

併存・

アダプタ連携

アダプタ

④

リホスト

⑤

リビルド

⑥

リビルド

⑦
新規導入

アダプタ連携リライト

業務システム業務ユニット業務ユニット業務ユニット業務ユニット

C

D

E

F

G

パッケージ適用

アダプタ

統合ＤＢ

サービス基盤地域情報プラットフォーム環境
図２．５．１

地域情報プラットフォームへの移行形態の例① 既存業務システム環境を併存して既存業務システムを移行せず、地域情報プラットフォームの統合データベース経由で連携する形態。既存業務システムのデータベースのデータを地域情報プ
ラットフォームの統合 DB 機能へ提供することで実現。主なコスト要因はレガシー環境併存のための運用コストであり、その他には比較的大きなコスト要因はないが、連携の範囲は限定的。
② 既存業務システム環境を併存して既存業務システムを移行せず、アダプタの開発・付加により連携する形態。アダプタの開発は既存業務システムのコンポーネント化の程度やアダプタによって実現する連携の範囲によって難易度・コストが異なる。既存業務システム環境併存のための運用コストと共に、アダプタ開発コストが判断の鍵となる。
③ 地域情報プラットフォーム環境で既存業務システムの稼働が可能な場合、既存業務システムを現状のままリホストしてアダプタの開発・付加により連携する形態。既存業務システム環境併存のための運用コストは不要となるが、仮想化等による両者が共存できるシステム環境の有無が判断の鍵となる。アダプタ開発は②と同様。
④ 既存業務システムの処理機能を、そのまま地域情報プラットフォーム環境の業務ユニットとして再開発する形態。地域情報プラットフォームとの親和性は高くなるが人が関与する作業を含めた業務処理の改善にはつながらない。また、標準仕様書で示される業務ユニットおよび業務サービスの要件との整合性を考慮する必要がある。
⑤ 人が関与する作業を含めた業務処理の内容を見直し、再設計して、地域情報プラットフォーム環
境の下で再開発する形態。業務・システム最適化を実現するために効果的な形態だが、移行に要する時間とコストが大きくなる。
⑥ 地域情報プラットフォーム準拠のパッケージ製品へ移行する形態。パッケージ製品が前提とする業務処理、人が関与する作業を自組織に適用することの可否がこの形態の鍵となる。
⑦ 新規に業務システムを地域情報プラットフォームに導入する形態。既存業務システムは存在しないので比較的自由度は大きい。通常は上記⑥同様にパッケージ製品を導入する。

－ 29 －

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

コラム ２．４．２ （２）移行の形態
地域情報プラットフォームへの移行の典型的な形態は⑥のパッケージ適用による業務システムのリビルドであり、標準仕様の目標である差換え可能性（カセッタブル）実現のためにも望ましい形態である。この形態では業務主管部門の業務処理をパッケージにあわせることを原則としてパッケージの改変（カスタマイズ）は極力避けるべきである。
業務処理の継続性や独自性を重視する場合は⑤リビルドまたは④リライトによるが、十分な体制と能力、および予算で開発および保守に当る必要がある。特にシステムライフ期間の保守体制と予算への配慮が重要である。
既存業務システムをそのまま地域情報プラットフォームに連携する形態の内、①および②は既存業務システムのシステム環境併存のための運用経費増となるため、移行のための経過措置と位置づけるべきである。また、③の形態は仮想サーバにより地域情報プラットフォームのシステム環境に既存業務システムの環境を導入するため、現時点では余り一般的ではない。

（３） アプリケーション移行優先度の考え方
地方自治体の業務体系には大きく分けて基幹情報系（住民基本台帳、税務等）と内部情報系（財務情報、人事給与等）に分かれる。どちらの体系を優先して移行するのか、または同時に移行するのかは各自治体の判断によるものである。
地域情報プラットフォームの要件でも示したように、地域情報プラットフォームで最初に実現することは標準インタフェースによる業務ユニット間データ交換である。特に住民基本台帳（以下住基と略す）、
税務、保健福祉等の住民サービス系アプリケーション群では住基アプリケーションが管理する住基デー
タとの連携が重要となるため、住基アプリケーションの既存行政情報システムから地域情報プラット
フォーム・住基業務ユニットへの移行順位が鍵となる。住基アプリケーションの移行順位には概ね次のように２つの考え方があり、いずれを採用するかは地方自治体の判断による。
①住基アプリケーションを優先移行する考え方
住民ポータルや総合窓口等のフロント系業務ユニットの構築・運用を優先したアプローチである。
住基業務ユニット移行を先行することによって、フロント系業務ユニットが必要とする住基データを中核とした統合データベースを早期に実現できる可能性があるが、既存システム環境で稼動する未移行の住民サービス系各アプリケーションは、住基業務ユニットに対するインタフェース（アダプタ）を個別に付加することが必要となる。
②住基以外のアプリケーション（住基データ利用アプリケーション）を優先移行する考え方
住民サービス系アプリケーションのバックエンド・アプリケーションの脱レガシー、置き換え可能性（カセッタブル）を優先したアプローチである。
そのために、既存システム環境で稼働する住基アプリケーションに業務ユニット標準インタフェース（アダプタ）を付加し、地域情報プラットフォーム移行済みの住民サービス系各業務ユニットと住基デー
タ交換を実現する。上記①に比べインタフェース開発のワークロードは少ないが、移行期間中の暫定処置であり、住基データを中核とした統合データベースの実現は遅れる。
（４）

既存行政情報システムとの併存

一般的に既存レガシー・システムを SOA 環境と連携させるために、アダプタを開発・付加することが提唱されているが、アダプタは既存レガシー・システム毎に個別開発する必要があり、既存レガシー・システムの改変を最小限に留めて SOA 環境が要求する全てのサービスインタフェースに対応することは非常に困難であり、その実現のためには多大な開発期間とコストが見込まれる。
したがって、移行期間中の既存行政情報システムと地域情報プラットフォーム・業務ユニットとの併
存では連携の範囲を次のような考え方で限定することが適当である。
－ 30 －

地域情報プラットフォームガイドライン①前提条件第 2 段階、第 3 段階におけるデータ交換、サービス連携
既存行政情報システムのアプリケーションがデータ提供側の業務ユニットとして機能する連携に限定する。既存アプリケーションが地域情報プラットフォーム・業務ユニットからデータの提供を受けて利用するためには、プログラムの大幅な改修が想定されるため現実的でない。
この連携のためには次のような方法が考えられる。
—

既存アプリケーションに一方通行（既存アプリケーション⇒業務ユニット）のデータ交換
インタフェースを提供するアダプタを開発・付加する。

既存システム

業務Ｂ

業務Ａ

業務Ｃ

業務ＤＢ

業務ＤＢ

・・・

業務ＤＢ

Ａ社
業務ユニットＡ

業務ＤＢ
既存アプリケーションとの連携インタフェース
業務ｻｰﾋﾞｽ
ｲﾝﾀﾌｪｰｽ
アダプタ
PF通信機能（SOAP通信）SOAPインタフェース

図２．５．２—

既存システム－業務ユニット間データ交換例

既存アプリケーションのデータベースのレプリカを地域情報プラットフォームの統合デー
タベース（公開データベース方式）と定義して、各業務ユニットからの連携を可能にする。

既存システム
業務Ａ

業務Ｂ

業務Ｃ

業務ＤＢ

業務ＤＢ

業務ＤＢ

・・・

Ａ社
業務ユニットＡ
業務ＤＢ
既存アプリケーションとの連携インタフェース
業務ｻｰﾋﾞｽ
ｲﾝﾀﾌｪｰｽ
統合ＤＢ機能アダプタ

PF通信機能（SOAP通信）SOAPインタフェースまたはSQLインタフェース
SOAPｲﾝﾀﾌｪｰｽ
または
SQLｲﾝﾀﾌｪｰｽ

統合ＤＢ

図２．５．３

既存システム－統合ＤＢ機能－業務ユニット間データ交換例－ 31 －

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

２．５．３

既存の業務システムとの整合性について

段階的な移行の場合、既存システムと新システム（地域情報 PF）との共存（連携）を考慮した、両システム間のデータ整合性について検討する必要がある。
既存システムの依存関係
業務システムA

業務システムB

業務システム
C

DB-A

DB-B

DB-C

ﾌｧｲﾙ

DB

段階的移行例

業務システムB、Cを業務ユニットb、cに移行
新シ ステ ム調達範囲
業務ユニット
b

DB-B

DB-C

DB-b

DB-c

既存シ ステ ム

既存デ ー タ移行

業務システム
A

地域情報PF

DB-A

図２．５．４

デ ー タ整合性確保業務ユニットc

統合DB

既存システムと新システム（地域情報 PF 準拠）との共存【データの整合性に関する検討事項】（１）新システムへの既存データ移行
既存システムから新システムへ円滑な切替えを行うために、データ移行について時期と方法（ツール）を明確にする。
調達する業務ユニット b、c に既存業務システム B、C のデータを移行する場合、事前に両データ間（DB-Bと DB-b、DB-C と DB-c）のギャップを分析し、策定した対策方法に従ってデータ移行を可能とするツールが必要になる（図２．５．４参照）。
（２）既存システムと新システム間におけるデータの整合性
既存システムと新システムが同期のとれたサービスを提供するために、両システム間のデータの整合性を確保する方法を明確にする。
既存業務システム A が、調達する業務ユニット b に即時公開を要求する場合、即時更新仕様の業務ユ－ 32 －

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

ニット b を調達する必要がある（図２．５．４参照）。
既存業務システム A が、調達する業務ユニット b に日時公開を要求する場合、即時更新または日時更
新仕様の業務ユニット b を調達する必要がある（図２．５．４参照）。
（３）文字データの整合性
新システム導入の際に「内字」の文字セットを決定する。地域情報プラットフォームでは、文字セッ
トについては、JIS X0213:2004 の範囲を前提としている。しかし、当面の経過措置として自治体内の合意に基づき、「内字」を JIS

X0208 の文字に限定することや、JIS X0213:2004 中の第一、第二水準文字に限定することができるものとしている。
（４）新システム（地域情報 PF）における文字の分類
新システム（地域情報 PF）の文字は「内字」と「外字」分類される。
「内字」は地域情報 PF 上のすべての業務ユニットで等しく認識され、また、確実な利用（連携）が保障される文字である。
「外字」は「内字」以外の文字であり、「標準外字」と「個別外字」に分類される。
「標準外字」は戸籍統一文字や法務省統一文字など、公的に整備されたものを候補として検討している。
「個別外字」は「標準外字」に含まれない文字を個別、独自に定義したもので、新システム（地域情報 PF）内においても利用（連携）が困難な文字である。
なお、システム内では文字を UCS(UTF-8 または UTF-16)に符号化して取り扱う。
（５）新システム（地域情報 PF）で利用できる文字
V1.0 の範疇では「内字」の利用（流通）を必須とする。
「外字」については、PUA を用いて表現し、自治体内で十分な管理がなされる範囲で流通を許す。ただし、「外字」の自治体外への発信は禁止する。
PUA : Private Use Area

外字私用領域

なお、業務ユニットの調達に際しては、「２．３．４
関連事項」も併せて参照のこと。

－ 33 －

業務ユニットを実際に導入する際に検討すべき地域情報プラットフォームガイドライン

２．５．４

テスト方式

地域情報プラットフォームによる行政情報システムは、多様なハードウェアに各々アプリケーションが搭載され、それらがネットワークによって連携される構造となる。本書でのテスト方式の検討では、
サービス連携基盤の各単体機能、業務ユニットについては地域情報プラットフォーム標準仕様に準拠（PF準拠）を満たし、且つ、各々のユニットでの単体テストは終了していることを前提とする。
住基ユニットのように業務ユニット間連携で主軸となるような業務ユニットから、税務、健康福祉のような個別業務ユニットまで、既存の行政情報システムが業務ユニットの単位で段階的に移行しながら、
統合データベースや地域情報プラットフォームによるサービス基盤上で新行政情報システムが構築されていく過程でのテスト方式という設定で検討を行う。
（１）テスト実施にあたっての基礎作業
通常、テスト計画を策定するに当たって、まず、下記の作業が必要となる。
① テストスコープの確立
冒頭でも述べたとおり、ハードウェアからネットワーク、アプリケーションといった構成のほかに、移行・構築にああっては複数の段階に渡る事となるため、テストすべき範囲と目的を明確に設定する必要がある。
② テスト方法の定義
テストの主催者は誰か、参加構成主体は誰か、各パートのテスト方式がセルフ方式かテスト
スィートを使う方式か、進行スケジュール、テストシナリオ、問題発生管理の方法、評価方法といった一連のテスト方法について決めておく必要がある。
③ リソース要件特定
テストに必要となるデータやソフトウェア、ハードウェア、さらには、作業空間や人材等の各種リソースについて、テスト種別毎に整理しておく必要がある。
（２）標準的なテストパターン
複合的なアプリケーションで構成される行政情報システムのような場合、標準的なテストパターンとしては以下のようなものがある。
① 単体テスト
本書では調達範囲ベンダにより実施済みとみなす。
② 統合テスト
本書では調達範囲の担当ベンダによるシミュレーションレベルでのテストは実施済みとみなす。
③ 総合テスト
このテスト結果が要件定義書・基本設計書を満たしているかといった視点から品質評価を行い、次フェーズの受入れテストへと円滑に進める。
サービス基盤における 4 機能および業務ユニットが複数存在するケースが想定され、開発導入時期も一致しないことから、各機能・ユニット間の連携テスト部分については、テスト計画、テストスケジュールの入念な調整が重要である。
④ 受入テスト
PMO(Project Management Office：マネジメント業務を横断的に調整し支援する組織）等を中心に第三者的に組織された体制が受入れテストを主体的に行い、当該自治体やその主要部門に対してサービス基盤およびその上での新業務ユニットの稼動を実演し、業務要件の充足や作業時の使い易さなどについての検証・評価を行い、移行運用へと円滑に進める。
業務要件を定義した部門・組織、システム開発ベンダ、主要部門における支援コンサル等が協同で受入れテストを実施することとなるが、体制面での役割分担や意思決定ロジック等の組織整－ 34 －

地域情報プラットフォームガイドライン備が重要となる。
また、現データベース、現システムデータの切り替えには、現行システム担当者・移行改修業者との連絡・調整が必要である。さらに、旧システム稼動場所と新システム稼動場所が異なる場合を想定したテスト環境の構築も検討しなければならない。
（３）テスト実施体制
地域情報プラットフォームによる行政情報システムの構築では、一般的には、調達側である当該自治体内に PMO が組織され、PMO が事務局となって、地域情報プラットフォーム推進会議といった全庁意思決定機関が設置されるケースが多いものと考えられる。テスト結果の承認や対応策協議によって結論を下すのは、この地域情報プラットフォーム推進会議といった体制で行われるはずである。ここを頂点にテスト実施体制としては、以下のように設置する事が想定される。
① 地域情報プラットフォーム推進会議
CIO 或いは首長を議長として主要な部門および関連する部門の長によって構成される調達者体制である。通常は、情報化主管部門か PMO によって事務局機能が提供され、当該自治体としての
地域情報プラットフォーム構築運用に係る最終意思決定機関となっている。
② テスト評価会議
情報化主管部門か PMO が単独か導入支援コンサルタントを加えて主催し、何種類かの総合テス
トや受入テストが、段階ごとに実施されていく際に、逐一、テストスコープや方法・シナリオ、結果に至るまでを評価する。
ここには、関連する主要業務部門の責任者、関連する機能やユニットのベンダ、既存ユニットのベンダ、既存ユニットの関連場所・リソース管理者等が参加して、テスト実施が円滑かつ効率的に行われると共に、結果を客観的に評価して、再テストの必要性や問題点や課題の洗い出しを行う。
・レビュー方針（チェックリスト）の作成
・ベンダが作成したテスト計画の評価・ベンダが作成したテストシナリオの評価
・ベンダが構築したテスト実施環境の評価
・ベンダが実施したテスト結果の評価と問題課題整理
・その他調整作業（テストデータ受け渡し等）③ テスト実施 TF
まず、サービス基盤の 4 機能に係るテスト実施 TF が必要な場合を想定しなければならない。この TF の必要性については、サービス基盤（全体インフラ）の構築段階によるが、本ガイドライン
では、サービス基盤 4 機能のテストの必要性も定義しておく。
各業務ユニット系の移行に際しては、各々TF を設置して実際のテストを行うこととなる。この
TF はサービス基盤ベンダあるいは当該 TF と調整をとって、まず、サービス基盤との総合テストを実施し、ついで、サービス基盤上で連携する他業務ユニットとの総合テストを実施する。
また、総合テストの実施結果によってサービス基盤や各業務ユニットに対して問題解決の必要性が生じた場合は、テスト評価会議が地域情報プラットフォーム推進会議に諮って実施を定めた
内容によって改修を実施することとなる。
以上の TF については、当該ベンダが主軸となって、関連する主要業務部門の担当者、関連する機能やユニットのベンダ、既存ユニットのベンダ、既存ユニットの関連場所・リソース管理担当者等に参加を呼びかけてテスト実施することとなる。
この際は、サービス基盤のテスト実施ＴＦを中心として、複数の TF で相互にテストし合う必要があり、全ての組合せについて各々がテスト結果をテスト評価会議に提出する方式が妥当と考えられる。
－ 35 －

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

地域情報プラットフォーム推進会議

テスト評価会議

複数のテスト実施ＴＦの組合を想定
サービス基盤
テスト実施ＴＦ

業務ユニットＡ
テスト実施ＴＦ

図２．５．５

業務ユニットＢ
テスト実施ＴＦ

・・・・・

テスト実施体制の例（４）テスト計画
地域情報プラットフォームによる行政情報システムの構築では、2 つの段階的な移行・構築パターンが示されているが、いずれもインタフェースやアダプタ、既存アプリケーションのデータベースのレプリ
カといったコンポーネントが統合環境の中に組み込まれることとなる。
これらを含めた統合システムとして全体を捉え、業務ユニットの統合化の順番や時期を考慮して有効な段階を区切るといったテストスコープ、その場合の方法、リソースを定義しつつ、総合テストおよび受入テストを実施していく必要がある。
① サービス基盤総合テスト
サービス基盤における PF 通信機能、統合 DB 機能、BPM 機能、PF 共通機能の 4 つの機能に対して、導入支援コンサルタントとシステム基盤構築ベンダ、ネットワークベンダ、データセンタベ
ンダ、保守・運用統括ベンダが定義されている。
なお、統合 DB 機能、BPM 機能、PF 共通機能はオプションとして位置づけられており、なおかつ、
PF 通信機能は SOAP として OS に組み込まれた状態で各業務ユニットに保有する形態も想定されており、最小構成の場合は、このサービス基盤総合テストは不要となるケースも考えられる。
PF 通信機能とどれかのオプション機能が装備される場合、上記ベンダも一括かあるいは複数存在する事となるが、その際には、各機能間と各ベンダ責任範囲間での総合テストが必要となる。
これにより要件定義書・基本設計書を満たしているかといった視点から品質評価を行い、次フェーズの受入れテストへと円滑に進めなければならない。
サービス基盤内機能が複数存在し開発導入時期も異なる場合は、各機能およびベンダ間の連携したテストとなるため、テスト実施ＴＦは導入支援コンサルタントを事務局とした関連ベンダで構成する事が望ましい。
・テスト評価会議へのレビュー方針（チェックリスト）の作成
・総合テスト計画・スコープの作成
・テストシナリオの作成
・テスト実施環境構築計画の作成
・テスト結果の評価方法の作成
・テストデータの作成－ 36 －

地域情報プラットフォームガイドライン② 業務ユニット系総合テスト
業務ユニットについては、共通系・バック系とフロント系との 2 種類で定義されているが、いずれの場合であっても、対サービス基盤あるいは業務ユニット間での連携が発生することとなる。
サービス基盤における PF 通信機能が各業務ユニットに内蔵されている場合は、関係する業務ユニット間での相互接続性テストとして各業務ユニットのテスト実施 TF によって全ての組合せでテストを実施する事となる。
PF 通信機能および統合 DB 機能、BPM 機能、PF 共通機能等をサービス基盤として具体的に形成する場合は、前項のサービス基盤総合テストを完了していると想定した上で、まず各業務ユニットとサービス基盤との総合テストが必要となる。ついで、サービス基盤を介しての関係する業務ユニット間の全ての組合せで相互接続性テストを行う。
これらの際に各々テスト実施 TF によって相互にテスト結果を得てテスト評価会議に図っていくこととなる。
下記の各作業は、サービス基盤および業務ユニットによるテスト実施 TF 間で協議の上遂行される必要があるが、その検討結果をテスト評価会議が調整して、テストの順番や評価方法について決定する必要がある。
・テスト評価会議へのレビュー方針（チェックリスト）の作成
・総合テスト計画・スコープの作成
・テストシナリオの作成
・テスト実施環境構築計画の作成
・テスト結果の評価方法の作成
・テストデータの作成
なお、本総合テストで問題や課題が発生した場合は、テスト評価会議の結果を受けて相互に調整するか、仕様の変更を必要とするレベルの対策についてはテスト評価会議の整理からさらに地域情報プラットフォーム推進会議の決定を受けて実施し、対策実施後は、再度テストをやり直すこととなる。
③ 受入テスト
受入テストについては、上記各総合テストが完了することによって実施可能となる。
ただし、既存システムと併用しながら段階的に業務ユニットが稼動するパターンが想定されており、サービス基盤形成や業務ユニット接続のタイミングを計りながら、必要なところで受け入れテストを実施し、既存システムと新システムとが共に実稼動するようにしなければならない。よって、
既存システムの入れ替えが完了するまで、必要回数の受入テストを行う必要があり、各自治体の推進スケジュールによってテスト計画は異なる。
この受入テストは、テスト評価会議が主体となって必要となるテスト実施 TF を統合して実データを扱うことによって実施される。サービス基盤およびその上での新業務ユニットの稼動について地域情報プラットフォーム推進会議に対して実演し、業務要件の充足や作業時の使い易さなどについての検証・評価を示す。この際、現データベース、現システムデータの切り替えには、現行システム担当者・移行改修業者との連絡・調整を行ったうえで実施する。さらに、旧システム稼動場所と新システム稼動場所が異なる場合は両方の環境が形成されている状況でテストして検証・評価を示す。
以上の検証評価方法については予め地域情報プラットフォーム推進会議に了承を得た方法を使い、問題・課題の管理方法についても予め決めておき、地域情報プラットフォーム推進会議の決定を受けておく。
・受入れテスト計画書（見直し）の作成
・受入れテストシナリオの作成－ 37 －

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

・受入れテストデータ（実データ）の準備
・受入れテストの実行環境構築
・受入れテストの実施
・移行データやシステム関連文書等、ソフトウェア以外の成果物のテスト・受入れテストの評価報告書の作成
・その他調整作業（ユーザのテスト参加等）－ 38 －

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

地域情報プラットフォームガイドライン
第 3 章 技術解説

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

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

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

項

版数

1

2018.3.12

2

2018.3.12

修正内容

改版履歴

備考

ページヘッダ修正(V2.7 → V2.8)
表紙及びヘッダのバージョン記載を削除

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

目次
３．技術解説 ............................................................................................................................................ 1
３．１ PF 通信機能 .................................................................................................................................. 1
３．２ 統合 DB 機能............................................................................................................................... 10
３．３ BPM 機能 .................................................................................................................................... 62
３．４ セキュリティ............................................................................................................................... 71
３．５ PF 共通機能 認証・認可・セキュリティ .................................................................................. 81
３．６ モニタリング機能 ..................................................................................................................... 109
３．７ PF 共通機能（ユーティリティ機能） ....................................................................................... 117
３．８ メッセージ交換パターンと異常系処理 ..................................................................................... 123
付録１ AUDIT、インタフェースに関する詳細定義 .............................................................................. 145
付録２ 実装コンポーネント構成に関する推奨モデル .......................................................................... 163
付録３ 共通ヘッダ、受領 ACK、添付書類の XML スキーマについて................................................. 169
付録４ モニタリング機能の実装例 ....................................................................................................... 173
付録５ 採用候補の技術仕様の検討状況について ................................................................................. 174

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

３．技術解説３．１

PF 通信機能

本節では、PF 通信機能（プラットフォーム通信機能）に関する補足的な説明等を提供する。以下のような構成となっている。
(1) HTTP 通信と通信セキュリティ (3.1.1 節)(2) SOAP 通信と通信モデル (3.1.2 節)(3) 高信頼性通信機能 (3.1.3 節)(4) 通信において設定すべき項目 (3.1.4 節)
上記 (1) では、プラットフォーム通信標準仕様の「２．２HTTP 通信と通信セキュリティ」に対する補足事項を説明する。
(2) は、プラットフォーム通信標準仕様の「２．３

SOAP 通信と通信モデル」に対応しており、SOAP、

電子封筒形式に関する簡単な説明のほか、添付ファイルがある場合の電子封筒形式やデータ交換システ
ムパターンの使い分けの目安を示す。
(3) は、プラットフォーム通信標準仕様の「２．４

高信頼性通信機能」に対応しており、高信頼性通信機能の説明、2 つの仕様が存在することによる問題点等を示す。
(4) では、サービス同士が通信できるために設定すべき項目を示す。

３．１．１ HTTP 通信と通信セキュリティ（１）

インターネットプロトコル

PF 通信の基盤となる通信プロトコルとしては、現在のインターネットの基盤プロトコルである IPv4
(Internet Protocol version 4) を採用する。IPv4 では、ネットワークに接続する各機器に割り当てられる IP アドレスが 32 ビットであり、ネットワーク接続機器の増大とともに、IP アドレスの枯渇が危惧されている。その問題を解決するために、128 ビットのアドレスをもつ IPv6 (Internet Protocol version
6) が策定されている。
現在 IPv4 から IPv6 への移行が徐々に進んでいるという段階であり、総務省でも、電子政府システムの IPv6 対応を進めるにあたり、各府省における計画策定の際に参考とすべき内容をまとめた「電子政府システムの IPv6 対応に向けたガイドライン」を策定し、公表している。
地域情報プラットフォームにおいても、今後、自治体、民間での普及状態を見て、IPv6 の採用を検討する。
•

参考：「電子政府システムの IPv6 対応に向けたガイドラインの策定について」
http://www.soumu.go.jp/s-news/2007/070402_5.html（２）

転送プロトコルPF 通信のアプリケーション層の通信プロトコルとしては、Web サーバ・Web ブラウザ間の通信で広く使われている、HTTP (Hypertext Transfer Protocol) 1.1 を採用する。
ただし、地域情報プラットフォームの中の補助的な機能において、HTTP 以外の通信プロトコルを採用する場合がある（時刻同期機能における NTP (Network Time Protocol) の使用など）。
（３）

通信セキュリティ

セキュリティに関する詳細については、プラットフォーム通信標準仕様の「５．プラットフォーム通
信標準における認証・認可・セキュリティ機能」および本ガイドラインの「３．４５PF 共通機能

認証・認可・セキュリティ」を参照のこと。
－ 1 －セキュリティ」、「３．

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

３．１．２ SOAP 通信と通信モデル（１）

SOAP 通信サービス連携実現には、SOAP (Simple Object Access Protocol) 1.1 を採用する。
SOAP は XML (Extensible Markup Language) をベースとしており、SOAP Envelope という電子封筒形式を規定している。SOAP Envelope は SOAP Header と SOAP Body から構成されており、SOAP Body に送信するメッセージ本体を置き、SOAP Header にメッセージの処理に関連する付加的な情報を置く。
<soap:Envelope><soap:Header>
ヘッダ情報</soap:Header><soap:Body>

メッセージ本体</soap:Body></soap:Envelope>図３．１．１

SOAP Envelope

SOAP 1.1 はまた、HTTP のリクエスト・レスポンスに SOAP Envelope を載せて通信する方法（バインディング）も規定している。

SOAP
メッセー
ジ
HTTPリクエスト
メッセージ
送信側

メッセージ
受信側
HTTPレスポンス
SOAP
メッセー
ジ

図３．１．２

SOAP の HTTP へのバインディング

SOAP の利点の 1 つとして、下位通信プロトコルに依存しないという点がある。現在の主流は下位プロ
トコルとして HTTP を使用することであるが、今後必要に応じて他のプロトコルを採用することが可能である。
SOAP の他の利点として、様々な機能を提供する Web サービスの仕様のスタックを利用できる点がある。
ミドルウェアが標準仕様のスタックの実装を提供することによって、セキュリティ、高信頼性等の機能を利用できるようになる。地域情報プラットフォームにおいては、仕様の標準化状況、実装の普及状況、相互接続性の実証状況、地域情報プラットフォームにおける要件等を考慮して採用を検討する。
SOAP 1.1 は標準化団体で審議された仕様ではないが、Web サービスの基本仕様として広く利用されており、WS-I (Web Services Interoperability Organization) で策定された Basic Profile において、－ 2 －地域情報プラットフォームガイドライン

仕様の曖昧な部分の明確化などがなされている。W3C (World Wide Web Consortium) においてすでに SOAP
1.2 が標準化されているが、現在の普及状況から SOAP 1.1 を採用する。併せて、Basic Profile 1.0 も
採用する。
（２）

電子封筒形式SOAP では SOAP Envelope と呼ばれる電子封筒形式を規定しているが、PF 通信においては用途に応じて
2 つの電子封筒形式を規定する。1 つは、ビジネス電文や業務ユニット間のデータ交換で使用するビジネ
スメッセージ用の電子封筒形式で、これは SOAP Body にプラットフォーム通信標準仕様で定める共通ヘッダとメッセージ本文を記述するものである。もう 1 つは、モニタリング機能等システム管理のためのシ
ステムメッセージ用の電子封筒形式で、これは SOAP Body にメッセージ本文をそのまま記述するものである。PF 通信機能は 2 つの電子封筒形式の両方をサポートできる必要がある。
（３）

添付ファイル

添付ファイルは、以下の場合に利用する。
・ 申請・届出において、申請書、もしくは届出書以外に、手続きに必要な書類を送信する場合
・ 申請・届出等を受け付け、処理を行った団体から、申請者に交付物を送信する場合
添付ファイルの利用イメージを下図に示す。
付随書類

団体Ａ
申請書

団体Ｂ
申請・届出

添付ファイル
業務ユニット
交付物
結果通知

結果通知

図３．１．３添付ファイルの利用イメージ

添付ファイル実装時には、書類のサイズに留意する必要がある。
・ 申請書の想定サイズ ： 数キロから数十 Kbyte（署名つき）×ワンストップサービスにおける手続き数（結果通知は申請書と同等もしくはそれ以下のサイズと想定される）・ 交付物の想定サイズ：

数百 Kbyte から 1Mbyte

上記の想定サイズから、添付ファイルを含む書類サイズは、数 Mbyte オーダを想定する必要がある。
なお、システム的なリソースの限界があり、無限に大きい添付ファイルの交換は、現実的でない。このため、上記の要件（数 Mbyte オーダ）以下を推奨サイズとする。

－ 3 －

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

PF 通信において、添付ファイルの取り扱いはオプションであるが、添付ファイルを扱うときのために、メッセージ本体格納型とメッセージへの添付型の 2 種類の電子封筒形式を規定する。
メッセージ本体格納型の場合、<添付書類>タグの<添付書類内容>タグの中に添付ファイルの内容を
Base64 エンコーディングして入れる。<添付書類名称>タグには、「住民票」など、添付ファイルの中身を示す文字列を入れ、<添付書類ファイル名称>タグにはファイルとして処理する場合のファイル名を入れる。<添付書類参照情報>タグは使用しない。
メッセージへの添付型の場合、SwA (SOAP Messages with Attachments) 仕様に基づき、MIME(Multipurpose Internet Mail Extension) パートに添付ファイルを置き、メッセージ本文から<添付書類>タグを使用して参照する。<添付書類ファイル名称>タグには、同時に送信する添付ファイル内でユ
ニークとなる英数字のファイル名称を設定する。また、<添付書類参照情報>タグに、対象の添付ファイ
ルを格納する MIME パートの Content-ID ヘッダに対応する cid URI を格納する。<添付書類内容>タグは使用しない。MIME ヘッダの情報と<添付書類>タグの情報の関係を図３．１．４に示す。
MIME-Version: 1.0
Content-Type: Multipart/Related; boundary=MIME_boundary;
type=text/xml;--MIME_boundary
Content-Type: text/xml; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-ID: <rootpart@example.com><?xml version='1.0' ?>SOAP Envelope<soap:Envelope ...>
<soap:Body>...
<添付書類>
添付書類タグ<添付書類名称>住民票</添付書類名称><添付書類ファイル名称>A0001.pdf</添付書類ファイル名称><添付書類参照情報>cid:XXXX@YYYY</添付書類参照情報></添付書類>...
</soap:Body></soap:Envelope>--MIME_boundary
Content-Type: application/octet-stream
Content-Transfer-Encoding: binary
Content-ID: <XXXX@YYYY>...添付ファイル(バイナリ)...
--MIME_boundary--

図３．１．４

メッセージへの添付型

メッセージ本体格納型は添付ファイルを Base64 エンコーディングするため、送信するメッセージのサイズが大きくなってしまう。そのため添付ファイルの容量が少ない場合のみ使用することが望ましい。
特にサイト間の通信においては通信容量の小さいネットワークを経由する可能性もあるため、メッセー
ジへの添付 (SwA) 型を使用することを推奨する。使い分けの目安を表３．１．１に示す。

表３．１．１

添付ファイルがある場合の電子封筒形式採用基準

添付方式

採用基準

1

メッセージ本体格納型

添付ファイル容量が 1Mbyte 未満の場合

2

メッセージへの添付 (SwA） 型

添付ファイル容量が 1Mbyte 以上の場合－ 4 －地域情報プラットフォームガイドライン（４）

データ交換システムパターン

PF 通信においては、データの受け渡し方法（本文内埋め込み、MIME で添付、統合 DB 機能利用）と BPM
機能との連携の有無の組み合わせで、6 種類のデータ交換システムパターンが考えられる。しかし、現在
BPM 機能の動作記述のために採用している WS-BPEL (Web Services Business Process Execution Language)
仕様が添付ファイルの処理について規定していないため、BPM 機能と連携した本文と添付（MIME で添付）型は採用しない。したがって、PF 通信機能で採用するのは、仕様書の記述通り 5 種類のデータ交換シス
テムパターンとなる。
統合 DB 機能経由のデータ交換システムパターン[Type3]、[Type5]については、統合 DB 機能自体がサイト内での利用を前提としたものであるため、サイト間では使用しない。

表３．１．２

データ交換システムパターン

BPM機能との連携なし[Type1]
本文内埋め込み
サイト内、サイト間[Type2]
MIMEで添付サイト内、サイト間[Type3]
統合DB機能を利用
サイト内のみBPM機能との連携あり[Type4]
サイト内、サイト間
採用せず[Type5]
サイト内のみ本文（添付ファイルを内包）[Type1]

サービス
要求側
業務ユニット

SOAP通信（本文処理）

サービス
応答側
業務ユニットBPM機能[Type2]（本文処理）

本文（添付ファイルを内包）（本文処理）

サービス
応答側
業務ユニット添
SOAP通信（SwA形式）

BPM機能（本文処理）

SOAP通信[Type5]

本文[Type3]

サービス
要求側
業務ユニット（本文処理）

サービス
応答側
業務ユニット

SOAP通信

本文
サービス
要求側
業務ユニット（本文処理）（本文処理）

統合DB機能（両タイプ含む）

図３．１．５

データ交換システムパターン

－ 5 －

サービス
応答側
業務ユニット（本文処理）

Data
Data

サービス
応答側
業務ユニット（本文処理）

サービス
要求側
業務ユニット（本文処理）

本文＋添付
サービス
要求側
業務ユニット

SOAP通信[Type4]

統合DB機能（両タイプ含む）

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

本文内埋め込み型の[Type1]、[Type4]と MIME で添付型の[Type2]はそれぞれ添付ファイルがある場合の電子封筒形式のメッセージ本体格納型とメッセージへの添付 (SwA) 型に対応しており、BPM 機能がある場合を除き、添付ファイルがある場合の電子封筒形式の採用基準を目安に使い分ける。
サイト内においては統合 DB 機能を利用するデータ交換システムパターン[Type3]、[Type5]が利用可能である。統合 DB 機能を利用するかどうかについては他の検討要素もあるが、次の用途で統合 DB 機能によるデータ交換システムパターンを推奨する。
①

メッセージ通信の負荷軽減②

データ統合（交換手段）の一元化•③

全データがメッセージに含まれて交換される負荷を軽減する。

•

提供側（情報源）を意識しないで統合 DB 機能経由のデータ交換を実現する。

•

利用側は統合 DB 機能だけを利用すればよいので負荷軽減できる。

既存システムのデータ活用•

地域情報プラットフォーム未対応の既存システムのデータも統合 DB 機能経由で活
用できる。

④

高度なデータ活用•

統合 DB 機能の応用的な使い方として、複数の提供側業務ユニットに跨るデータの統合結果を活用できる（「３．２．７．４

複数の情報源の複雑な統合」を参照）。

なお、統合 DB 機能の詳細については、アーキテクチャ標準仕様の「４．５．４
び本ガイドラインの「３．２

３．１．３

統合 DB 機能」およ

統合 DB 機能」を参照のこと。

高信頼性通信機能

高信頼性通信機能は SOAP 通信処理の信頼性を向上させるものであり、メッセージの送達保証（失敗時再送）、重複排除、順序保証の機能を持つ。送信側アプリケーションは高信頼性通信処理系にメッセージを渡すだけで、送信側と受信側の高信頼性通信処理系の間のメッセージ交換により、メッセージは高信頼で受信側アプリケーションに渡される。高信頼性通信処理系間では受領確認メッセージ（これは、プラットフォーム通信標準仕様の「６．プラットフォーム通信における MEP と異常系処理」のメッセージ
交換パターン (MEP) における受領 Ack とは異なる）送付やメッセージ再送等の処理を行うことによって信頼性を高めるが、アプリケーションがその通信プロトコルや処理を意識する必要はない。

送信側

受信側

アプリケーション

アプリケーション

メッセージ

メッセージ

高信頼性通信
処理系：

高信頼性通信
処理系

高信頼性通信プロトコル

図３．１．６

高信頼性通信機能－ 6 －地域情報プラットフォームガイドライン

以下に、高信頼性通信機能に含まれる個々の機能を説明する。
•

送達保証：送信側高信頼性通信処理系が受信側高信頼性通信処理系から受領確認メッセージを受け取るまでメッセージを再送することにより、メッセージの送達を保証する。受信側がメッセージを受け取っても送信側が受領確認メッセージを受け取れない場合に受信側が同じメッセージを複数回受け取る可能性が残る。これは、最低 1 回はメッセージが受領されることを保証するた
め At Least Once とも表現される。

•

重複排除：受信側高信頼性通信処理系が、同一メッセージを複数受け取った場合に受信側アプリ
ケーションに一度だけメッセージを渡すことによって、メッセージの重複が起こらないことを保証する。これは、最高 1 回しかメッセージが受領されないことを保証するため At Most Once とも表現される。

•

送達保証+重複排除：この 2 つを組み合わせることによって、送信側アプリケーションが送ったメッセージが確実に重複なしに受信側アプリケーションに達することを保証する。これは、正確に 1 回だけメッセージが受領されることを保証するため Exactly Once とも表現される。

•

順序保証：送信側から受信側に複数メッセージが送られるときに、送信側アプリケーションが送った順序で受信側アプリケーションがメッセージを受け取ることを保証する。これは In Orderとも表現される。なお、順序保証は機能的に送達保証と重複排除を含んでいる。

これまでも、確実なメッセージの送信が必要な場合においては、アプリケーションレベルでの送達確認等の手段により対応してきたが、ここにあげた仕様に基づいたシステムを実現することにより、アプ
リケーションよりも下位のレイヤで高信頼性な通信を行うことが可能となる。ただし、通信に回復不能
な致命的な障害が発生した場合においては最終的にはこれまでどおりのアプリケーションによる対応は不可欠である。
SOAP を高信頼にする仕様としては、共に OASIS (Organization for the Advancement of Structured
Information Standards) において標準化された次の 2 つが存在する。
•

WS-Reliability (Web Services Reliability) 1.1 (WS-R) [2004 年 11 月に OASIS Standard と
して承認]

•

WS-ReliableMessaging (Web Services Reliable Messaging) 1.1 (WS-RM) [2007 年 6 月に OASISStandard として承認]

これらの標準仕様は、送達保証、重複排除、順序保証の機能としては同等であるが、通信プロトコルが異なっており、現在のところ相互接続できない。そのため、PF 通信機能としての高信頼性通信機能の相互接続性を保証するためには、両仕様をサポートすることを必須とするか、何れかの仕様に一本化することが必要となる。一本化する場合、サイト内の通信に限定すれば、サイト毎にどちらか一方の仕様を選択して利用することが可能である。しかし、将来的にサイト間通信も行うことを考慮すると、サイト間の仕様と同じことが望ましい。サイト内の仕様とサイト間の仕様が異なる場合、サイト内とサイト間を繋ぐサービスにおいて両仕様をサポートするなどの対応が必要となる。

－ 7 －

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

送信側

受信側

アプリケーション

アプリケーション

メッセージ

メッセージ
通信できない高信頼性通信
処理系：(WS-R)

図３．１．７

高信頼性通信
処理系(WS-RM)

WS-R と WS-RM の相互接続

以上の説明は WS-R と WS-RM とが相互接続できないという前提とした場合であり、今後、標準化団体において、もしくは、地域情報プラットフォームの仕様として、2 つの仕様の実装同士を相互接続するための仕様を作成することによって、両仕様の混在が可能になることも考えられる。2 つの仕様の実装同士を相互接続するための仕様の例としては、以下のような通信プロトコル変換ゲートウェイのようなものが考えられるが、その実現可能性も含めて検討が必要である。

WS-R/WS-RM
ゲートウェイ

WS-R処理系
WS-Rプロトコル

図３．１．８

WS-RM処理系
WS-RMプロトコル

WS-R/WS-RM 接続ゲートウェイ

地域情報プラットフォーム標準仕様 V1.0 を策定した時点では、WS-R のみが唯一の標準仕様であったた
めこれを採用したが、V2.0 の策定段階において WS-RM が標準仕様として完成した。2 つの標準仕様の並存には上で説明したような問題があるため、V2.0 では高信頼性通信機能に関して仕様化していない。高信頼性通信は、これから利用が進む技術であり、相互接続性の確認や普及の状況を注視していく必要がある。現在の段階で高信頼性通信機能を採用する場合は、上記問題点を理解し、リスクをもって採用すること。
なお、プラットフォーム通信標準仕様および本ガイドラインでは、上位層における MEP（メッセージ交換パターン）を規定しており、障害を検出した場合の対応方針についても明記している。MEP は高信頼性
通信機能の上位に位置付けられるため、高信頼性通信機能の有無に係わらず、通信上で発生した障害は統一的に処理される。高信頼性通信機能を利用すると、回復可能な障害は高信頼性通信機能のレベルで吸収され、上位層では回復不能な致命的な障害を扱うことになる。プラットフォーム通信標準仕様の「６．
プラットフォーム通信における MEP と異常系処理」を参照のこと。

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

３．１．４ 通信において設定すべき項目
サービスが他のサービスと通信（連携）するためには、通信先のサービスの各種情報を設定しておく必要がある。設定すべき項目としては、以下のようなものが考えられる。
•

HTTP のタイムアウト•

本文メッセージの最大サイズ（最大バイト数など）•

各サービスのエンドポイント URL (Uniform Resource Locator) （DNS (Domain Name System) への設定）•

認証機能の設定•

認証方式の選択（SSL (Secure Sockets Layer) クライアント認証、HTTP ベーシック認証、等）•

認証情報の交換（信頼できる CA (Certification Authority) 情報や ID やパスワード、等）認
証機能の設定また、採用するオプション機能に応じて、そのオプション機能に固有の設定が必要になる場合もある。
これらの情報は通信するサービス間で何らかの方法で交換される必要がある。将来的にはサービスレ
ジストリ機能等を利用して交換されることが想定されるが、現時点では、サービスの管理者間の情報交換などにより手動で設定することが現実的である。

－ 9 －

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

３．２ 統合 DB 機能
統合 DB 機能は、業務ユニット間で必要となるデータを統合的に管理することにより、自治体内における業務ユニット間のデータ連携を効率的に行う機能である。
従来における業務ユニット間のデータ交換は、個別に開発・運用が行われており、標準化していない
ため、業務ユニットの差し替えが困難であった。
統合 DB 機能は、各業務ユニットで分散管理されているデータを統合して、標準化された手段（業務ユニット間のデータ連携のインタフェース）により必要とする業務ユニットに提供する。これにより、デー
タ交換の側面から業務ユニットの差し替えを容易にしている。
（図 3.2.1）【従来】ユニット間で個別にデータ交換【地域PF】標準化された統合DB機能を介してユニット間のデータ交換

業務ユニットA

業務ユニットB

業務ユニットA

業務ユニットB

機能 - A

機能 - B機能 - A

機能 - B

ＤＢ－Ａ

ＤＢ－B

ＤＢ－Ａ

提
供

統合DB
機能

ＤＢ－B

利用

業務ユニットC

業務ユニットD

業務ユニットC

業務ユニットD

機能 - C

機能 - D

機能 - C

機能 - D

ＤＢ－C

ＤＢ－D

ＤＢ－C

ＤＢ－D

▲ 業務ユニットの差し替えを阻害▲ 個別開発なので、コスト要因◎ 業務ユニットの差し替えを実現◎ 共通機能化してコスト削減

図３．２．１ 統合 DB 機能におけるデータ交換

自らデータを管理（保持）して、他の業務ユニットにデータを提供する役割を持つ業務ユニットを「提供側業務ユニット」、他の業務ユニットのデータを利用（参照）する業務ユニットを「利用側業務ユニット」と呼ぶ。これは、データ交換における業務ユニットの役割により区別するものであり、図 3.2.1
でも解るように、１つの業務ユニットが、「提供側業務ユニット」として他の業務ユニットにデータの提供を行い、「利用側業務ユニット」として他の業務ユニットのデータを利用するのが一般的である。
統合 DB 機能の視点からは、統合 DB 機能にデータを提供する役割を持つ「提供側業務ユニット」、統合
DB 機能を利用する「利用側業務ユニット」と、統合 DB 機能に関する役割により使い分けている。

－ 10 －

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

３．２．１

統合 DB 機能の基礎

統合 DB 機能はオプションであり、方式として「公開用 DB 方式」と「共通インタフェース方式」を選択できる。
最初に統合 DB 機能に共通の基礎概念を解説し、方式や実装に依存する部分は、次の項で解説する。
・方式に依存する解説 → 「3.2.2 統合 DB 機能の方式と選択基準」
・実装に依存する解説 → 「3.2.3 統合 DB 機能の実装モデル」

３．２．１．１ 統合 DB 機能の使われ方
アーキテクチャ標準仕様で定義している統合 DB 機能の使われ方 3 種類について解説する。
◇A：独立型（業務ユニット間の SOAP 通信を伴わないで、統合 DB によるデータ交換のみ）◇B：本文とリファレンス（統合 DB 機能の検索キーを交換）型◇C：BPM 機能と連携した本文とリファレンス（統合 DB 機能の検索キーを交換）型

Ａ

独立型（統合DB機能によるデータ交換のみ）

Ｃ

ＢＰＭ機能と連携した本文とリファレンス（統合DB機能の検索キーを交換）型

BPM
SOAP通信

本文
提供側
業務ユニットData

利用側
業務ユニットサービス
要求側
業務ユニット統合DB機能

Data

サービス
返答側
業務ユニット統合DB機能【ﾃﾞｰﾀ交換ｼｽﾃﾑﾊﾟﾀｰﾝのType ５】

Ｂ

本文とリファレンス
（統合DB機能の検索キーを交換）型

サービス
要求側
業務ユニット

業務標準との関係業務標準で既定する業務ユニット間のデータ交換インタフェースは本図における下記部分である。

本文
SOAP通信サービス
返答側
業務ユニット

利用側
Data

提供側
統合DB機能【ﾃﾞｰﾀ交換ｼｽﾃﾑﾊﾟﾀｰﾝのType ３】

図３．２．２ 統合 DB 機能によるデータ交換方式－ 11 －

地域情報プラットフォームガイドライン【A】「独立型（統合 DB 機能によるデータ交換のみ）」

BPM機能と連係していないケース→ 紙の申請書で窓口回り

転入届

国保
申請書

住民票

児童手当
申請書

住基ユニット

国保ユニット

児童手当ユニット

住基

国保

児童

住基DB

国保DB

児童DB

提供
Ｉ/Ｆ

提供
Ｉ/Ｆ

提供
Ｉ/Ｆ

利用
Ｉ/Ｆ

利用
Ｉ/Ｆ

利用
Ｉ/Ｆ

データによる排他制御と順序性の保障

業務ユニットは独立したマスタＤＢを管理して専門的なｻｰﾋﾞｽを提供する。

統合DB機能は、各業務ユニットのマスタＤＢを、
業務ユニット間で利用（参照）する
仕組みを提供する。

統合DB機能図３．２．３

統合 DB 機能の使い方（A 方式）

A の方式は、SOAP による業務ユニット間連係を行わない独立した業務ユニット間において、統合 DB 機能を介したデータ交換を行うものである。特にこの型は、完全には地域情報 PF に対応していない既存の業務ユニットにおいて、他の業務ユニットのデータを活用する手段として採用することができるので、段階的な地域情報 PF 対応を実現する手段として効果的である。
住基ユニットにおける転入届の処理が完了して住民票が出力されるのを待って、次の国保ユニットへの処理を依頼するなど、人の判断による運用により全体の順序性保障を行うことができる方式であり、
情報システムと人との役割を整理して、全体として矛盾の無い運用を行う必要がある。
【B】「本文とリファレンス（統合 DB 機能の検索キーを交換）型」(Type 3)
サービス要求側の業務ユニットは自身が管理するデータを更新（または登録）した後、SOAP 通信として、リファレンス（統合 DB 機能の検索キー）を付与した依頼メッセージをサービス応答側の業務ユニットに送信する。サービス応答側の業務ユニットは、依頼メッセージを受け取ると、その中のリファレン
スを参照して統合 DB 機能を検索することにより、サービス要求側の必要なデータを取得して、依頼された処理を実行することができる。
B の方式では、BPM 機能による業務の流れ制御が行われないため、各業務ユニットは、統合 DB 機能を介して得ることができる他の業務ユニットの状態（データ）を確認しながら、担当する業務を矛盾無く遂行する必要がある。
－ 12 －

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

例えば、図 3.2.4 の住基ユニットにおいて転入届が処理され、住基 DB に当該住民の情報が正常に登録完了しており、統合 DB 機能を介して住基 DB の該当データが参照できることを確認した後で、国保ユニッ
トは国民健康保険の受付処理を行うことにより、順序性を保障することが求められる。
ここで行う順序性の保障は、業務ユニットの処理として実現するものであり、統合 DB 機能は、必要な情報を利用可能にするという意味で、他の方式と役割や機能が変わるものではない。
B の方式における順序性保障は確実で影響範囲が狭い 3.2.1.2(2)を推奨する。
SOAP通信応答
SOAPで直接連係するケース

依頼
転入届

住基ユニット

国保ユニット

児童手当ユニット

住基

国保

児童

住基DB

国保DB

児童DB

提供
I/F

提供
I/F

提供
I/F

利用
I/F

利用
I/F

利用
I/F

データによる排他制御と順序性の保障

業務ユニットは独立したマスタＤＢを管理して専門的なｻｰﾋﾞｽを提供する。

統合DB機能は、各業務ユニットのマスタＤＢを、
業務ユニット間で利用（参照）する
仕組みを提供する。

統合DB機能図３．２．４ 統合 DB 機能の使い方（B 方式）【C】「BPM 機能と連携した本文とリファレンス（統合 DB 機能の検索キーを交換）型」(Type 5)
統合 DB 機能は、利用側業務ユニットから直接利用（参照）されるため、BPM 機能から直接制御されることはないが、C 方式の通信では、業務ユニット間の業務の流れを、BPM 機能が制御しているため、データの排他制御や更新順序性の保障などは、BPM 機能の制御下で実現されることとなる。
例えば図 3.2.5 において、住基ユニットは、依頼された転入手続きを実行して、自ら管理している
住基 DB に転入者の基本情報を登録した後、BPM 機能に処理完了を通知する。
次に BPM 機能から依頼を受けた国保ユニットは、転入手続きが完了して、住基ユニット内の住基 DBに登録された転入者の基本データを、統合 DB 機能の利用 I/F を通して参照することが可能になる。

－ 13 －

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

ワンストップ申請
ﾜｰｸﾌﾛｰ
(BPM)

始

転入

保険資格取得児童手当申請終電子申請

住基ユニット

国保ユニット

児童手当ユニット

住基

国保

児童

住基DB

国保DB

児童DB

提供
I/F

提供
I/F

提供
I/F

利用
I/F

利用
I/F

利用
I/F

BPMによる排他制御と順序性の保障

業務ユニットは独立したマスタＤＢを管理して専門的なｻｰﾋﾞｽを提供する。

統合DB機能は、各業務ユニットのマスタＤＢを、
業務ユニット間で利用（参照）する
仕組みを提供する。

統合DB機能図３．２．５ 統合 DB 機能の使い方(C 方式)

ここで重要な留意点は、次の３点である。
①業務ユニット内で、処理（トランザクション）が矛盾なく完結していること。
即ち、提供側業務ユニット（住基ユニット）は、自己が管理するデータベース（住基 DB）へのデータ
登録、統合 DB 機能に対するデータ提供など、全ての処理が完了したのを確認した後で、BPM 機能に処理完了の通知を行う必要がある。
②BPM 機能は、前の処理完了を確認して、次の処理要求を発行する順次制御を行うこと。
③統合 DB 機能は、提供側業務ユニットの必要なデータについて、その内容を即時反映して、最新の内容を利用側業務ユニットに応答することが求められる。
これらを遵守することで、BPM 機能による処理（ワンストップサービスによる申請など）を矛盾なく完結することができる。

－ 14 －

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

３．２．１．２

統合 DB 機能における順序性の保障

統合 DB 機能を利用する業務システム間のデータ交換では、適切な順序性保障によって、正しいデータが交換できるようにする必要がある。
一般的な順序性の保障方法としては概ね次の 3 つが考えられる。
（１）データに基づく保障
利用側業務ユニットが、処理開始前に統合 DB 機能を介して必要なデータが参照可能であることを確認する方法である。新規登録されたデータについてはデータの有無で確認できるが、更新、削除のケース
は、処理中フラグや、処理完了番号など、業務ユニット側の制御に必要な項目を統合 DB 機能が標準で持つデータに追加して制御する必要がある。
（２）処理完了情報による保障
提供側業務ユニットの処理完了報告を確認したあとで、利用側業務ユニットに依頼メッセージを送信する方法である。このとき、提供側業務ユニットは、統合 DB 機能を介して、自身が管理している該当デー
タを、利用側業務ユニットから利用できる状態になったことを確認した後で、処理完了報告を行うことが求められる。
（３）運用による保障
予め、提供側業務ユニットの処理結果について、統合 DB 機能を介して利用できる状態になるまでの処
理時間を決めておき、決められた時間を経過したことを確認して次の利用側業務ユニットの処理を開始する方法である。例えば、提供側業務ユニットの処理結果を、夜間のバッチ処理で統合 DB 機能に反映することを、運用前提として決めておき、次の利用側業務ユニットの処理は、翌日に行うように制御する方法である。

３．２．１．３ 統合 DB 機能における差し替えの考え方
業務ユニットA1

A

業務ユニット
B1

B

提供側

差
替

業務ユニットA2

A

業務ユニット
B1

B

提
供
Ｉ
Ｆ

提供I/F

提
供
Ｉ
Ｆ

統合DB
機能１

差
替

統合DB
機能２

利
用
Ｉ
Ｆ

A
B

利用I/F

利
用
Ｉ
Ｆ

A

業務ユニット
Z1

差
替

利用側

業務ユニットZ2

B□従来：差し替えにはDB及びアプリケーションの改修が必要 → 改善したい。
ここを狙う□現実：部品化されたオプションを選択して、設定変更などを行えば、差し替えられる。
既存システムを含めた実情に最適な方式を選択できる。
□理想：何もしないで差し替えられる。 → 広範囲の標準化が必要で、硬直化する恐れがある。

図３．２．６ 業務ユニットおよび統合 DB 機能の差し替え－ 15 －

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

統合 DB 機能を標準化する利点の１つは、「業務ユニットおよび統合 DB 機能の差し替え（互換性）を容易にすること。
」である。
何もしないで（コスト 0 で）各ユニットの差し替えを実現することが理想であるが、理想の実現には広範囲の詳細な標準化が必要となり、硬直化やコストアップの要因になる。
そこで、現実的な解として、「差し替えとは、できるだけ最小限のコストでユニットの差し替えが可能なこと。
」を目指している。
地域情報 PF に対応することにより「提供側業務ユニット」、「統合 DB 機能」、
「利用側業務ユニット」の替え性を高めることができる。

３．２．１．４ 統合 DB 機能の役割と標準化ポイント
統合 DB 機能および関連する業務ユニットの役割と標準化ポイントについて図３．２．７により解説する。

統合DB機能の役割

業務ユニットA

ＤＢ－A

業務ユニットXaa

データの統合

A

A

X

X

B

B

業務ユニットB

b

b

ＤＢ－B

データの受渡し提供側規定されたデータの管理を行い統合
DBに提供する。

提供Ｉ/Ｆ

利用Ｉ/Ｆ

標準化の
対象外

業務標準仕様で標準化される。

図３．２．７ 統合 DB 機能の役割と標準化ポイント－ 16 －

利用側

必要な情報を標準化された手段で利用（参照）できる。

地域情報プラットフォームガイドライン（１）提供側業務ユニット
統合 DB 機能にデータを提供する業務ユニット（以下提供側または提供側業務ユニット）は、「自治体業務アプリケーションユニット標準仕様」で規定するデータについて責任を持って管理を行い、統合 DB
機能にデータを提供する。
提供側におけるデータの管理方法（データモデルなど）は規定していないので、業務ユニットに最適な管理方法を採用することができる。
（２）提供 I/F
提供側から統合 DB 機能にデータを提供するインタフェース（提供 I/F）は、データモデル（データ構造）を含めて標準で規定していないので、提供側業務ユニットと統合 DB 機能との組み合わせにより、最適なインタフェースを採用することができる。但し、業務ユニットおよび統合 DB 機能の差し替え性を高めるために、統合 DB 機能の方式毎の提供 I/F について選択肢を推奨しているので参考にして頂きたい。
（詳細は 3.2.2.2～3 節で解説する。
）（３）統合 DB 機能
統合 DB 機能の役割は、提供側業務ユニットを意識することなく、提供側業務ユニットで管理されているデータを利用側業務ユニットから利用するための「データの受け渡し機能」である。
統合 DB 機能におけるデータの管理方法は規定していない。特に統合 DB 機能の方式や採用するデータモデルは、提供 I/F などへの影響が大きいので慎重に設計するべきである（3.2.5 参照）。
一般的に統合 DB 機能は、複数のデータを組み合わせて必要なデータを利用するための「データ統合機
能」を持っているが、この機能（図 3.2.7 の利用 I/F である X）については標準化していない。
（統合 DB
機能の応用として 3.2.7.4 節で解説する）（４）利用 I/F
統合 DB 機能を利用側業務ユニットから利用するためのインタフェース（利用 I/F）は、統合 DB 機能の方式に関わらず、「自治体業務アプリケーションユニット標準仕様」で標準化する SOAP による連係イン
タフェースを統合 DB 機能が実現する必要がある（必須）。利用 I/F として、SQL の採用も可能だが、インタフェースやデータモデルを標準で規定していないので、差し替え性に留意する必要がある。
（５）利用側業務ユニット
利用側業務ユニットは、他の業務ユニットで管理されている必要な情報を統合 DB 機能から取得して利用することができる。差し替え性を高めるために、他の業務ユニットで管理されているデータの参照は、
統合 DB 機能がサポートする地域情報 PF 標準に準拠した利用 I/F(SOAP)により行うことを推奨する。

－ 17 －

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

３．２．２

統合 DB 機能の方式と選択基準

業務ユニット間のデータ交換手段として選択できる次の 3 つの方式について、選択基準と併せて解説する。いずれの方式においても、利用側システムが必要とする正本データまたは、副本データが取得できることを提供側システムと確認する必要がある。
※ここでは、正本データを業務システムが持つデータとし、副本データを統合 DB 機能が持つデータとする。
（１）業務ユニット間の直接連携（２）公開用 DB 方式の統合 DB 機能（３）共通インタフェース方式の統合 DB 機能

３．２．２．１ 業務ユニット間の直接連携
業務標準仕様で、提供側業務ユニット毎に
データモデル及び連携I/Fを規定
連係
インタフェース

提供側

利用側

業務ユニットA

ＤＢ－A

A

データA

PULL

業務ユニットX

機能 - X
業務ユニットB

B

ＤＢ－B
データB

PULL

データ
の検索
結果
メッセージ
（ＸＭＬ）

問合せ
SOAP ﾘｸｴｽﾄ メッセージ
同期型のＳＯＡＰ通信SOAP 応答

（ＸＭＬ）

項目と
検索条件を
指定する。

利用

図３．２．８ 業務ユニット間の直接連携

統合 DB 機能を利用しないで、利用側システムが直接個々の提供側システムにアクセスして、必要なデータを取得する形態である。
地域情報プラットフォームの「自治体業務アプリケーションユニット標準仕様」では、各業務ユニッ
ト毎に同期型の SOAP 通信（サービス）として、データ連携のインタフェースを規定しており、地域情報
PF に準拠した提供側業務ユニットはこのインタフェースを実装している。
－ 18 －

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

このインタフェースは、統合 DB 機能が実現する利用 I/F と一致しているので、統合 DB 機能を利用しなくても業務ユニット間のデータ交換が可能である。
直接連係の利点および留意事項は次の通りである。
【利 点】（１）正本からデータを取得できる。
（２）統合 DB 機能が不要なので、システム構成が簡素化される。
【留意点】（１）利用側業務ユニットが、依頼先（SOAP の宛先）を意識する必要がある。
（２）文字コード系やデータ表現などを一致させる必要がある。
対策：これらの留意点は、SOAP 宛先の変換（ルーティング）、メッセージの変換などを行うように構成する対策により回避できる場合がある。
（３）提供側業務ユニットの負荷が増大する。
対策：提供業務ユニット側の負荷に余裕がない場合は、データベースのレプリケーションや、CPU の増強などの対策を実施する必要がある。
（４）統合 DB 機能の応用（3.2.7 節参照）には対応できない。
対策：利用側業務ユニットが標準外の統合 DB 利用 I/F（SQL など）を利用しないように管理する必要がある。
（５）提供側業務ユニットが稼動していないタイミングではデータ交換できない。
対策：提供側業務ユニットのデータ提供機能を分離して常時稼動するように構成することが必要になるが、この対策は統合 DB 機能を導入することと等しいため、統合 DB 機能の導入を検討す
ることを推奨する。

コラム３．２．１「同期型の SOAP 通信」
図 3.2.8 に示すように、利用側の連係インタフェースは、同期型の SOAP 通信として規定している。
（詳細は通信標準 6.2.3 を参照）
同期型の SOAP 通信とは、サービス要求側から発行された SOAP による依頼メッセージに対して、
サービス応答側は、依頼された処理が完全に完了するのを待って、処理結果を SOAP による応答メッ
セージとしてサービス要求側に返信する方式である。平行動作による効率化には制約を受けるが、逐次性が確保され、順番に決められた処理が実行される利点がある。

－ 19 －

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

３．２．２．２ 公開用 DB 方式の統合 DB 機能「公開用 DB 方式」の統合 DB 機能は、統合 DB 機能として物理的な DBMS に公開対象の二次データ（提供側から提供されたデータ）を保持し、この二次データを介してデータの受け渡しを行う方式である。

提供側

利用側

公開用ＤＢ方式の統合DB機能業務ユニットA
ＤＢ－A

業務ユニットB
ＤＢ－B

業務ユニットＣ
ＤＢ－Ｃ

【標準２】

ＰＵＳＨ型
データ提供
PUSH
機能
（ＳＯＡＰ）

Ｓ
Ｏ
Ａ
Ｐ

Ｓ
ＰＵＳＨ型
Ｏ
データ提供 PUSH Ａ
Ｐ
機能（ＳＯＡＰ）

連係
I/F
-A

ＤＢＭＳ

Ｓ
ＰＵＳＨ型
Ｑ
データ提供 PUSH
Ｌ
機能
（ＳＱＬ）

連係
I/F
-B

Ａ
Ｐ
Ｉ

【標準３】

PULL

PULL

ＰＦ準拠
SOAP通信ﾘｸｴｽﾀ

業務ユニットX

ＰＦ準拠
SOAP通信
ﾘｸｴｽﾀ

機能
X

ＳＱＬ
PULL

【標準１】

図３．２．９ 公開用 DB 方式の統合 DB 機能（１）各ユニットの役割と留意点
ユニット毎に具体的な動作および留意点について解説する。
①提供側業務ユニット
提供側業務ユニットは、PUSH 型データ提供機能によって、自己が管理するデータに更新が発生した
ときに統合 DB 機能(DBMS)の該当する二次データを更新する。このデータ更新は、利用側業務ユニットなど、他の機能とは無関係に提供側業務ユニットの制御により実行される。
公開用 DB 方式の統合 DB 機能では統合 DB 機能内の物理的な DBMS で管理されている二次データを提供側業務ユニットが更新する必要があるため、同時更新（提供側業務ユニット内のデータ更新と同時に統合 DB 機能内の二次データも更新すること）は理論的に不可能であり、更新タイミングについて(3)に示す考慮が必要である。
二次データの更新（提供）手段は規定していないので、レプリケーション、SOAP、DBMS のアクセス
手段(SQL)など、提供側業務ユニットと統合 DB 機能の実装によって可能な範囲で、任意の方式を採用できるが、差し替え性を考慮して次の点に留意すべきである。
－ 20 －

地域情報プラットフォームガイドライン◇SOAP を採用する場合
PUSH 型の SOAP インタフェースは標準で規定していないが、データモデル（XML タグ構成）は、「自治体業務アプリケーションユニット標準仕様」で標準化する SOAP によるインタフェースが参考になる。
標準で規定している SOAP インタフェースとは制御方向が逆になるので注意が必要である。
即ち、「自治体業務アプリケーションユニット標準仕様」は PULL 型であるのに対して、公開用 DB 方式の統合 DB 機能における提供側業務ユニットに求められる二次データの更新機能は PUSH 型になる。
（コラム 3.2.2 参照）◇SQL を採用する場合
SQL は統合 DB 機能で用いられる DBMS で規定されるインタフェースを使用して実行され、SQL 自身もDBMS に依存した仕様になるので、差し替え性を考慮すると、そのインタフェースは、ODBC、JDBC などの標準化されたものを採用し、SQL も DBMS に依存しない範囲で使用するべきである。
（3.2.7.3(3)参照）
・レプリケーションによる実現
SQL の代わりに、DBMS のレプリケーション機能により実現する方法もある。
レプリケーション機能は DBMS ベンダにより提供される場合が多いので、提供側業務ユニットで採用している DBMS と、統合 DB 機能で採用する DBMS との組み合わせ（相性）を考慮する必要がある。
②利用側業務ユニット
利用側業務ユニットは、提供側業務ユニットとは無関係に、利用 I/F を介して統合 DB 機能に検索要求を送信し、結果データを受け取る。即ち、利用側業務ユニットは、統合 DB 機能の有無および統合 DB
機能の方式に関わらず、標準化された利用 I/F によるデータ取得を実現できる。標準外で統合 DB 機能の利用 I/F として SQL を採用する場合は、統合 DB 機能で採用されている DBMS がサポートしている SQL
インタフェースとなるケースが多い。この場合、インタフェースおよびデータモデルは標準化していないので、利用側業務ユニットの対応と差し替え性に留意する必要がある。
③統合 DB 機能
統合 DB 機能は利用側業務ユニットからの要求に応じて、統合 DB 機能内で管理している二次データの検索を行い、利用 I/F を介して利用側業務ユニットに検索結果データを返す。
公開用 DB 方式の統合 DB 機能は、物理的な DBMS で二次データの集中管理を行うため、性能に関して特に配慮が必要である。
（3.2.3.1 参照）（２）仕様に関する留意点
公開用 DB 方式の統合 DB 機能を採用する場合に必要となる仕様として次のものがある。
【PUSH 型データ提供機能】

前項の①に示す機能が該当する。

◇提供側業務ユニットは、採用する統合 DB 機能に適合した PUSH 型データ提供機能を有すること。
◇統合 DB 機能は、対象とする各提供側業務ユニットからの PUSH 型データ提供機能を受けて、統合
DB 機能内の DBMS を更新する機能を提供側業務ユニットに公開すること。
ここで、提供側業務ユニットと統合 DB 機能の提供 I/F が適合していることが重要であり、システム要件として具体的に決定すべきである。特に統合 DB 機能側のデータモデル（表モデル）は標準化していないので配慮が必要である。（3.2.3.1 参照）－ 21 －

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

コラム３．２．２「PULL 型のデータ提供と PUSH 型のデータ提供」
FROM 側（提供側）で管理するデータを TO 側（統合 DB 機能）に提供する場合の制御方式として、公開用 DB 方式で使用する PUSH 型と、共通インタフェース方式で使用する PULL 型がある。
◇PUSH 型のデータ提供
FROM 側に「PUSH 型データ提供機能」を持ち、データ提供機能が呼び出されると、①で該当データの取得を行い、TO 側に関係なく取得したデータを TO 側に提供する方式である。
FROM 側の制御によりデータ提供を行うことができる利点がある一方、TO 側は、提供されたデータ（二次データ）の実体を保管する必要が生じる。
インタフェースとして SOAP を採用する場合は、TO 側に②で提供されたデータを受け取って、DBMSを更新する「PUSH 型データ提供機能」が必要になるが、SQL を採用する場合は、FROM 側のデータ提供機能から直接 TO 側の DBMS を更新できるので、③のデータ提供機能は不要である。

【PUSH型のデータ提供】
FROM側（提供側業務ユニット）

データA

インタフェース① データ提供

PUSH型

②提供

機能
（ﾘｸｴｽﾀ）

PUSH

TO側（統合DB機能）

PUSH型
データ提供 ③機能
（ﾚｽﾎﾟﾝﾀﾞ）

データA【PULL型のデータ提供】
FROM側（提供側業務ユニット）

②
データA

③

インタフェース

PULL型
データ提供
機能
（ﾚｽﾎﾟﾝﾀﾞ）

①要求
PULL

④提供

TO側（統合DB機能）

PULL型
データ提供
機能
（ﾘｸｴｽﾀ）

データA⑤

図３．２．１０ PUSH 型と PULL 型のデータ提供◇PULL 型のデータ提供
TO 側に「データ提供機能」を持ち、TO 側のデータ提供機能からの要求①に従って、FROM 側が要求されたデータを提供④する方式である。
TO 側の制御により必要なタイミングで必要なデータだけを利用できるので、TO 側における二次データの保管が不要になる利点がある。
インタフェースとして SOAP を採用する場合は、FROM 側に、要求①されたデータの検索②を行い、検索結果③を TO 側に提供④する「PULL 型データ提供機能」が必要になるが、SQL を採用する場合は、
TO 側のデータ利用機能から直接 FROM 側の DBMS を検索してデータを取得することができるので、FROM側のデータ提供機能は不要である。
－ 22 －

地域情報プラットフォームガイドライン（３）PUSH 型データ提供機能におけるデータ更新タイミング
提供側業務ユニット内のデータが、統合 DB 機能内の DBMS で管理している二次データに反映されるまでの時間的な遅れ（データ更新タイミング）が問題になる。
PUSH 型データ提供機能におけるデータ更新タイミングは、データの性質や利用側の要件、通信方式などを考慮して、データ毎に規定するべきであるが、システム全体の方式や性能に影響する重要な要件である。
通信方式として「3 型：本文とリファレンス型」を採用するケースでは、3.2.1.2 に示す順序性保障手段を講じることによって、遅延が許されるデータについては遅延更新が可能である。
一方、通信方式として「5 型：BPM 機能と連係した本文とリファレンス型」を採用するケースでは、BPM機能によるフロー制御の都合上、データ更新タイミングとして即時更新が求められる。

BPM
①
依
頼

③
回
答
アプリ

②更新

⑤
依
頼

時間差
あり

DB
A

提供側業務ユニット

PUSH

公開DB

⑧
回
答

⑥検索
PULL

⑦結果
④
公開用DB方式
PUSH
更新 の統合DB機能

アプリ
利用側業務ユニット④で更新する前の結果となる恐れが有る
図３．２．１１ PUSH 型更新タイミングの課題【課題】
公開用 DB 方式の統合 DB 機能における PUSH 型データ提供機能は、方式上、統合 DB 機能で保持している二次データの更新に一定の時間（遅延）が必要であるため、次のような問題が発生する恐れがある。
（図 3.2.11）
提供側業務ユニットは BPM 機能からの依頼①に対して処理を実行し、自身のデータを更新②して、該当データのリファレンス情報を BPM に処理結果として応答③する。
提供側業務ユニットは、更新されたデータを公開 DB に PUSH 型で提供④（統合 DB 機能の DBMS を更新）する。
BPM はその応答③を受けて、対象データのリファレンス情報を含んだ次の処理依頼⑤を利用側業務ユニットに送る。
利用側業務ユニットは、BPM から受け取った依頼⑤で指定されたリファレンス情報を参照して、統合
DB 機能に検索依頼⑥を送信することにより、その結果⑦を受け取る。
この時、④により統合 DB 機能に提供側 DB の更新データが反映される前のタイミングで⑥の統合 DB
機能の検索が実行さると、⑦の結果として④で更新される前のデータが返されるため、利用側が古いデータを使った処理となり、処理結果に矛盾を生じる課題がある。
－ 23 －

地域情報プラットフォームガイドライン【解決策】
図 3.2.12 で示すように、③と④の順序を入れ換えることで、この課題は解決できる。
即ち、提供側業務ユニットで自身のデータを更新②した直後に、統合 DB 機能への PUSH 型データ提供③を実行して、その完了を確認後に BPM への応答④を行うように構成することにより、③の完了後に⑤の依頼が発行されるので、⑦の結果が最新であることを保障できる。

BPM
①
依
頼

④
回
答

アプリ

⑤
依
頼

時間差
あり

②更新

DB
A

提供側業務ユニット

PUSH

公開DB

⑧
回
答

⑥検索
PULL

⑦結果
③
公開用DB方式
PUSH
更新 の統合DB機能

アプリ
利用側業務ユニット

結果が保証される
図３．２．１２ PUSH 型更新タイミングの解決策

この場合、③の PUSH 型更新機能の完了が遅れると、提供側業務ユニットの処理完了④も遅れるため、全体の処理遅延につながる。
従って、③の PUSH 型更新タイミングは、可能な限り即時に実行されるべきであり、許容される処理（遅延）時間を要件として規定すべきである。
この許容される処理（遅延）時間は、数秒～十数秒とするのが妥当だが、あまり小さい時間を指定す
ると実現が困難になるので、考慮すべきである。
許容時間を調達仕様書に明記するか、不整合を起こさない妥当な時間内で処理できること等を調達仕様書に明記すると良い。
より厳密なデータ更新の制御方式として「2 フェーズコミットメント」がある。
「2 フェーズコミットメント」は、データ更新を「準備」と「実行」の 2 段階に分けて、複数の DB を
矛盾なく更新する手法であり、提供側業務ユニットに閉じた制御は次の手順になる。
（括弧中の数字は図3.2.12 の数字と一致する）
・提供側業務ユニットは、自己の DB の更新準備（該当データのロックなど）を行う。
・提供側業務ユニットは、統合 DB 機能の更新準備を行う。
・提供側業務ユニットは、自己および統合 DB 機能の更新準備が完了したのを確認する。
・提供側業務ユニットは、自己および統合 DB 機能の更新を実行する（②③）
。
・提供側業務ユニットは、自己および統合 DB 機能の更新が成功したことを確認して BPM への応答を行う(④)。このとき、何れかのデータ更新でエラーが発生した場合には、両方のデータを元に戻した上で、リトライするかエラーを返す。
この方式は、統合 DB 機能が「更新準備」機能をサポートしている場合（一般的に SQL インタフェースを採用する場合）に採用することができる。
－ 24 －

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

３．２．２．３ 共通インタフェース方式の統合 DB 機能「共通インタフェース方式」の統合 DB 機能とは、統合 DB 機能内に物理的な DBMS による二次データの保持を必須とせず、提供側業務ユニットから公開される情報を利用側業務ユニットが必要とする情報として仮想的にアクセスするためのプログラムとして構成された統合 DB 機能である。

提供側

利用側

共通ｲﾝﾀﾌｪｰｽ方式の統合DB機能業務ユニットA
ＤＢ－A

ＰＵＬＬ型
データ提供
機能
（ＳＯＡＰ）

Ｓ
Ｏ
Ａ
Ｐ

連係
I/F
-A

Ｓ
Ｏ
Ａ
PULL Ｐ

連係
I/F
-B

PULL

ＰＦ準拠
SOAP通信
PULL

ﾘｸｴｽﾀ

PULL

ＰＦ準拠
SOAP通信ﾘｸｴｽﾀ

業務ユニットX

業務ユニットB
ＤＢ－B

ＰＵＬＬ型
データ提供
機能
（ＳＯＡＰ）

機能X

業務ユニットＣ
ＤＢ－C

【標準２】

API
（ＳＱＬ）

PULL

Ａ
Ｐ
Ｉ

Ｓ
Ｑ
Ｌ

【標準４】

ＳＱＬ
PULL

【標準１】

図３．２．１３ 共通インタフェース方式の統合 DB 機能（１）各ユニットの役割と留意点
ユニット毎に具体的な動作および留意点について解説する。
①提供側業務ユニット
提供側業務ユニットは、PULL 型のデータ提供手段によって、自己が管理する規定のデータを統合 DB
機能に公開する。ここで、公開とは、検索・参照する権限と手段を提供することである。
データの提供手段は規定していないので、SOAP、DBMS のアクセス手段(SQL)など、提供側業務ユニットと統合 DB 機能の実装によって可能な範囲で、任意の方式を採用できるが、差し替え性を考慮して次の点に留意すべきである。
◇SOAP を採用する場合
統合 DB 機能の利用側ＩＦを「自治体業務アプリケーションユニット標準仕様」で標準化する SOAP
－ 25 －

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

によるインタフェースに準拠させることにより、提供側業務ユニットが標準でサポートしている SOAPによるデータ提供機能をそのまま使うことができる。
地域情報 PF 標準以外の SOAP 仕様を採用することは推奨しない。
◇SQL を採用する場合
SQL は提供側業務ユニットに採用されている DBMS でサポートされるインタフェースを使用して実行され、SQL 自身も DBMS に依存した仕様になるので、差し替え性を考慮すると、そのインタフェースは、
ODBC、JDBC などの標準化されたものを採用し、SQL も DBMS に依存しない範囲で使用するべきである。
（3.2.7.3(3)参照）②利用側業務ユニット
利用側業務ユニットは、提供側業務ユニットとは無関係に、利用 I/F を介して統合 DB 機能に検索要求を送信し、結果データを受け取る。即ち、利用側業務ユニットは、統合 DB 機能の有無および統合 DB
機能の方式に関わらず、利用 I/F によるデータ取得が実現できる。
統合 DB 機能の利用 I/F として SQL を採用する場合は、
統合 DB 機能独自のインタフェースとなるケースが多い。この場合、インタフェースおよびデータモデルは標準化していないので、利用側業務ユニットの対応に留意する必要がある。（ODBC、JDBC などを推奨）③統合 DB 機能
統合 DB 機能は利用側業務ユニットからの要求に応じて、提供側業務ユニットにアクセスを行い、必要なデータを収集して、利用側業務ユニットが求めるデータ形式のデータとして、利用 I/F を介して利用側業務ユニットに検索結果を返す。
（２）必要となる仕様
共通インタフェース方式の統合 DB 機能を採用する場合に必要となる仕様として次のものがある。
【PULL 型データ提供機能】

上記の①の機能が該当する。

◇提供側業務ユニットは、採用する統合 DB 機能に適合した PULL 型データ提供機能を有すること。
◇統合 DB 機能は、対象とする各提供側業務ユニットから提供される PULL 型データ提供機能により、提供側業務ユニットにアクセスを行い、利用側業務ユニットが必要なデータを取得すること。

BPM
①
依
頼

③
回
答

アプリ

②更新

④
依
頼

DB

提供側業務ユニット⑥検索 共通ｲﾝﾀﾌｪｰｽ ⑤検索
PULL
PULL
方式の
⑦結果 統合DB機能 ⑧結果

⑨
回
答

アプリ
利用側業務ユニット

図３．２．１４ 共通インタフェース方式の統合 DB 機能におけるデータ更新タイミング－ 26 －

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

ここで、提供側業務ユニットと統合 DB 機能の提供 I/F が適合していることが重要であり、システム要件として具体的に指定すべきである。
本方式の統合 DB 機能は、利用側から要求された最新のデータを提供側からオンデマンドで取得するので、リアルタイム性（情報の鮮度）が高いという特徴がある。
（図 3.2.14）
従って、公開用 DB 方式の統合 DB 機能で課題とされたデータ鮮度に関するタイミング問題は存在しな
いので、特別な制御は不要である。
本方式の欠点として、統合 DB 機能の検索アクセスが提供側業務ユニットの性能に影響する可能性がある点や、提供側業務ユニットの停止時に統合 DB 機能の利用も止まる点が指摘されている。これらの欠点
は提供側業務ユニットと統合 DB 機能の間にレプリカを置くことにより回避できる。

コラム３．２．３「DBMS のレプリケーション機能」

DBMS のレプリケーション機能とは、マスタ表と同じ表（レプリカ）を別に作成して、その間の同期を制御する機能である。
初期状態としてマスタ表のコピーをレプリカとして作成しておく。
マスタ表が更新①されると、更新ログ（どのような更新が行われたのかを記録したデータ）が抽出②されてレプリカ側に転送③される。
レプリカ側では受け取った更新ログをレプリカ（表）に適用④する。
通常、この制御を更新トランザクション（アプリケーションからの DB の処理単位）毎に行うことにより、レプリカをマスタ表とほぼ同じ状態に保つことができる。
特徴として、レプリカとマスタ表は 1:1 となり、双方にキー項目が必要であることが多い。

抽出②

適用④

マスタ

レプリカ

更新①
更新
ログ

転送③

参照
更新
ログ

図３．２．１５ DBMS のレプリケーション機能－ 27 －

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

３．２．２．４ 統合 DB 機能の方式とインタフェースのまとめ
以上で解説した統合 DB 機能の方式について表 3.2.1 に整理する。また、統合 DB 機能の方式毎の業
務ユニットとのインタフェースについて、図 3.2.16 で整理する。

表３．２．１ 統合 DB 機能の方式比較№

項目

公開用 DB 方式

共通インタフェース方式

1 統合 DB 機能・二次データの保持◇提供された二次データを保持する。

◇二次データの保持は不要

・データ容量・二次データの総量を管理できること。

・一度に大量のデータを利用する際はメモリ容量に注意

提供機能の動作◇統合 DB に保持しているデータを検索して返す。

利用 I/F◇利用用側からの要求に応じて必要なデータを収集□SOAP（PF 標準のプロバイダ機能）

必須□SOAP （PF 標準のプロバイダ機能）

必須□SQL（統合 DB の DBMS に依存）

□SQL

□SOAP（ﾌﾟﾛﾊﾞｲﾀﾞ機能）□SOAP （PF 標準のﾘｸｴｽﾀ機能）□SQL（統合 DB の DBMS に依存）

□SQL（提供側 DBMS の RDB に対応）

利用データの鮮度◇提供されたデータの鮮度に依存する。

◇提供側業務ユニットの最新データを利用可能

順序制御◇提供側の順序制御が必要◇順序制御は不要

可用性◇二次データのバックアップ、復旧対策が必要◇二次データを持たないので並列運転に適する◇提供元の停止時も運転可能◇提供元の停止時の運転不可

提供 I/F→ レプリカで回避
主な実現技術2 提供側業務ユニット

運用負荷

◇DBMS

◇EII、フェデレーション◇PUSH 型のデータ提供機能で◇PULL 型のデータ提供機能で統合 DB を更新

統合 DB にデータ公開□提供 I/F = SOAP →統合 DB□提供 I/F = SOAP（PF 標準仕様）□提供 I/F = SQL□提供 I/F = SQL◇提供機能の実行負荷が有る。

◇統合 DB からの検索負荷が有る→ レプリカで回避

3 利用側業務ユニット□SOAP （PF 標準仕様） 推奨□SOAP （PF 標準仕様） 推奨□SQL（統合 DB の DBMS に依存）

□SQL

－ 28 －

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

提供側

利用側

（（カ
カ））
統合DB無し統合DB無し（（キキ））
公開用DB方式
公開用DB方式
ＳＯＡＰ(PUSH)
ＳＯＡＰ(PUSH)（（ク
ク））
公開用DB方式
公開用DB方式
ＳＱＬ
ＳＱＬ（ＰＵＳＨ）（ＰＵＳＨ）（（ケケ））
共通ｲﾝﾀﾌｪｰｽ
共通ｲﾝﾀﾌｪｰｽ
方式
方式
SOAP
SOAP

（（コ
コ））
共通ｲﾝﾀﾌｪｰｽ
共通ｲﾝﾀﾌｪｰｽ
方式
方式
ＳＱＬ
ＳＱＬ

業務ユニット

破線はPF準拠要件を示す

業務ユニット（（アア））
統合DB無し統合DB無しSOAP

DB

業務ユニット業務ユニットSOAP（PUSH）

DB

公開用DB
方式の
統合DB機能業務ユニット業務ユニットSQL（PUSH）

DB

DB

SQL

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

共通ｲﾝﾀﾌｪｰｽ方式の統合DB機能SOAP

業務ユニット
DB

ＰＵＳＨ
ＰＵＬＬ

（（イ
イ））
公開用DB方式
公開用DB方式
ＳＯＡＰ
ＳＯＡＰ

SOAP

業務ユニット

SQL

SQL

（（ウ
ウ））
公開用DB方式
公開用DB方式
ＳＱＬ
ＳＱＬ

（（エ
エ））
共通ｲﾝﾀﾌｪｰｽ
共通ｲﾝﾀﾌｪｰｽ
方式
方式
SOAP
SOAP

（（オ
オ））
共通ｲﾝﾀﾌｪｰｽ
共通ｲﾝﾀﾌｪｰｽ
方式
方式
ＳＱＬ
ＳＱＬ

：能動的な情報提供：受動的な情報提供

図３．２．１６ 統合 DB 機能の方式とインタフェースのまとめ

図３．２．１６は、中央に業務ユニット間のデータ交換方式（3 種）をあらわし、右側に利用側業務ユニットと統合 DB 機能間のインタフェース方式（ア～オ）、左側に提供側業務ユニットと統合 DB 機能間のインタフェース方式（カ～コ）を示している。
標準で規定しているのは、利用側業務ユニットから利用される SOAP インタフェース（ア、イ、エ）であり、他は最適な方式を選択することができる。
利用 I/F として SQL（ウ)（オ）も採用可能だが、差し替え性は自己責任となる。
提供側業務ユニットは上記の SOAP インタフェースをサポートしていることが必須であり、統合 DB
機能など、アダプタと組み合わせた実現も可能である。従って、破線で示している機能により地域情報 PF の準拠性を満足することができる。
提供側業務ユニットから見ると、統合 DB 機能無し（カ）と、共通インタフェース方式の SOAP（ケ）は同じであり、地域情報 PF 標準に準拠した業務ユニットはそのままで適用できる。

－ 29 －

地域情報プラットフォームガイドライン（キ）（ク）（コ）は統合 DB 機能と提供側業務ユニットの方式に依存する部分となる。
既存システム（地域情報 PF 未対応）の業務ユニットを提供側とする用途には、データの公開のみで済む（コ）が最も導入が容易である。
標準では、実情に合った方式の選択が可能なように必要最小限の規定をしているので、方式の選定に際しては、各方式の特徴を理解した上でシステム全体として整合性のある最適な構成になるように留意すべきである。

３．２．３ 統合 DB 機能の実装モデル「公開用 DB 方式」と「共通インタフェース方式」の 2 つの方式について、実際に統合 DB 機能を実装する際の参考となる事項を解説する。

３．２．３．１ 公開用 DB 方式の統合 DB 機能の実装
公開用 DB 方式の統合 DB 機能について実装パターンを図３．２．１７に示す。

提供側
業務A

A1

利用側

公開用ＤＢ方式の統合DB機能
DBMS

A

ＰＵＳＨ型
Y データ登録
データ提供
サービス
機能
ﾌﾟﾛﾊﾞｲﾀﾞ
PUSH
ﾘｸｴｽﾀ（SOAP）（ＳＯＡＰ）

ＰＦ準拠
SOAP通信ﾌﾟﾛﾊﾞｲﾀﾞ

A2

Aｘ
PULL

ＰＦ準拠
SOAP通信
ﾘｸｴｽﾀ

ＰＵＳＨ型
データ提供
機能
PUSH
（ＳＱＬ）

ＪＤＢＣ
ＯＤＢＣ
など

S
Q
L
機
能
・
更
新
系

業務C
（マスタ）

A3
機能
X

業務B

B1

業務X

レプリケーション機能

C1

B2

レプリカ

C2

S
Q
L

ＪＤＢＣ
ＯＤＢＣ
など

ＳＱＬ
PULL

機
能
・
参
照
系

検索機能

B3

C3

レプリカ

図３．２．１７ 公開用 DB 方式の統合 DB 機能の実装パターン

汎用的な事項は 3.2.2.2 で解説済みなので、ここではデータモデルおよび具体的な実装における留意点を中心に解説する。
－ 30 －

地域情報プラットフォームガイドライン（１）統合 DB 機能
統合 DB 機能は物理的な RDBMS（リレーショナルデータベース管理システム）を使用して実装するのが一般的である。XML データベースによる実装も可能であるが、その場合の提供 I/F、利用 I/F の実装は SOAPであることが多い。
DBMS で保管する二次データは、表として管理されるが、地域情報 PF で標準化しているのは SOAP(XML)即ちツリー構造なので、二次データのデータ構造は標準化したツリーのデータ構造（図 3.2.17 の Ax）を表現できる表構造（図 3.2.17 の A2）である必要があり、一度決定すると変更の影響が大きいので、慎重に決めるべきである。一般的に１つのツリー構造データを表現するには、複数の表が必要になる。
（詳細は 3.2.5 参照）（２）利用 I/F と利用側業務ユニット
利用側の SOAP インタフェースは、統合 DB 機能で実装することが必須である。具体的には、統合 DB 機
能側の機能として地域情報 PF 準拠の SOAP 通信を提供するプロバイダ機能を実装する。このプロバイダ
機能は、利用側からの依頼（リクエスト）に応じて、統合 DB 機能で管理している該当表(A2)の検索を行
い、検索結果(A2)をツリー構造(Ax)に変換して利用側に応答（レスポンス）する。
また、利用側業務ユニットは、SOAP インタフェースによる統合 DB 機能の利用を行う場合、統合 DB 機
能がサポートする SOAP 通信を呼び出す機能（リクエスタ）を実装することになる。このリクエスタ機能
では、ツリー構造(Ax)として得たデータを業務ユニット X 内のデータモデル(A3)に変換して利用するのが一般的である。
利用側のインタフェースとして SQL を採用する場合には、統合 DB 機能で採用している RDBMS でサポートされる SQL インタフェース（JDBC や ODBC など）を利用側業務ユニットが直接使用して SQL による統合
DB 機能の検索を行うのが一般的な実装となる。ツリー構造を介さないので、データ構造の変換が不要であり、統合 DB 機能側に特別な機能を実装する必要がないので、統合 DB 機能が簡素化でき、高速なインタフェースを実現することができる利点がある。一方、利用側で統合 DB 機能のデータ構造を意識して、統合 DB 機能で採用されている RDBMS に依存する SQL インタフェースを使用する必要があるので、差し替え性が阻害される恐れがある点が欠点である。
（３）提供 I/F と提供側業務ユニット
提供 I/F として、SOAP を採用する場合は、統合 DB 機能側の提供 I/F として統合 DB 機能に対するデー
タ登録（更新）を実現する SOAP 通信によるプロバイダ機能（データ登録サービス）を実装する。このプ
ロバイダ機能は、提供側からの依頼（リクエスト）に応じて、依頼内容(Ay)を表構造(A2)に変換し、統合 DB 機能で管理している該当表(A2)に対するデータ追加、更新、削除などを行い、その結果を提供側に応答（レスポンス）する。
また、提供側業務ユニットは、統合 DB 機能がサポートするデータ登録サービスを呼び出す機能（リクエスタ）を実装する。このリクエスタ機能では、提供側で管理している該当表(A1)を統合 DB 機能が規定するツリー構造(Ay)に変換して統合 DB 機能のデータ登録サービスに依頼することになる。
提供 I/F として SQL を採用する場合は、統合 DB 機能で採用している RDBMS によりサポートされる SQL
インタフェース（JDBC や ODBC など）を提供側業務ユニットが直接使用して SQL による統合 DB 機能へのデータ登録・更新・削除を行うのが一般的な実装となる。ツリー構造を介さないので、表とツリー間のデータ構造変換が不要であり、統合 DB 機能側に特別な機能を実装する必要がないので、統合 DB 機能が簡素化でき、高速なインタフェースを実現することができる利点がある。
－ 31 －

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

一方、提供側と統合 DB 機能のデータモデルは異なるので、提供側は統合 DB 機能のデータ構造を意識して、統合 DB 機能で採用されている RDBMS に依存する SQL インタフェースを使用する必要があるので、差し替え性が阻害される恐れがある点が欠点である。
提供 I/F の選択肢として DBMS がサポートするレプリケーションを使用することも考えられる。この方法は、提供側業務ユニットが管理する DBMS と、統合 DB 機能の DBMS をレプリケーション機能で繋ぐこと
により、提供側業務ユニットは、自己の DBMS の更新に専念することができるので、実装が容易になる。
（コラム 3.2.3 参照）
この場合、提供側と統合 DB 機能のデータ構造が異なるケースが多いので、レプリケーション機能がデータ構造変換を行う必要があり、一般的なレプリケーション（同じ構造の表を複製する）と異なるので注意する必要がある。また、統合 DB 機能および提供側業務ユニットが同じ DBMS を採用するなど、レプリ
ケーション機能がサポートできる組み合わせであることを確認する必要がある。
（４）性能への配慮
統合 DB 機能を物理的な DBMS で実現する性質上、統合 DB 機能に対する提供側および利用側からのアクセスが集中して、性能が劣化する恐れがあるので、性能への配慮が特に重要である。

提供側

利用側

公開用ＤＢ方式の統合DB機能

業務1

更新

業務2

DBMS

業務1

参照

業務2

業務3

業務3

業務4

業務4

業務5

業務5

業務6

業務6

業務7

業務7

業務8
業務9
業務10

業務11

提
供
側
Ｉ
Ｆ

レプリカ

利
用
側
Ｉ
Ｆ

業務12

業務8
業務9
業務11

業務10

業務12

業務13

業務13

業務14

業務14

業務15

業務15
利用側性能
の劣化

提供側性能
の劣化

図３．２．１８ 公開用 DB 方式の統合 DB 機能の性能劣化－ 32 －

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

提供側の性能が劣化すると、統合 DB 機能への登録を待って処理完了とする提供側業務の遅延に直結し、利用側の性能が劣化すると、統合 DB 機能経由で所得したデータに基づく利用側の処理が遅延する。
一般的に、1 つの業務ユニットが提供側・利用側の両方の役割で統合 DB 機能と連係しており、提供側
および利用側業務ユニットは、BPM などにより密接に関連しているので、統合 DB 機能の性能劣化は、業務システム全体の性能劣化に直結することになる。
回避策として、複数の統合 DB 機能に分割することが考えられるが、この場合、同じ二次データを複数の統合 DB 機能で管理すると、提供側は複数の統合 DB 機能に対する提供処理を行う必要があり、提供側
業務ユニットの遅延に繋がるので留意すべきである。この課題は管理する二次データを複数の統合 DB 機能に分割することで回避できるが、この場合利用側が複数の統合 DB 機能を使い分ける必要が生じ、管理面で複雑になる欠点がある。
（５）統合 DB 機能のデータベース容量
統合 DB 機能で交換対象の二次データの実体を保持して管理する必要があるので、
統合 DB 機能内の DBMS
が管理するデータベース容量に留意する必要がある。
具体的には図 3.2.18 からも解る通り、全ての交換対象データ（二次データ）の合計容量が統合 DB 機
能の DBMS で管理されるように構成する必要がある。
DBMS などの制約により、必要なデータ管理領域が確保できない場合は、統合 DB 機能を複数に分割するなど、必要な対策を講じることになるが、前項の性能など総合的にバランスのよい構成とするべきである。

コラム３．２．４「DBMS のビュー機能」

DBMS のビュー機能は、DBMS 内で物理的なデータを管理している表（実表）とは別に、実表の見え方
をビュー表として定義することにより、仮想的にビュー表として利用する機能である。利用側からは通常の表と同様にビュー表に対する検索が可能であるが、ビュー表は内部的に関係演算の結果表として定義され、ビュー表に対する検索はビューを構成する実表に対する関係演算として処理されるのが一般的である。
RDBMS
ビュー

実表
関係
演算
関係
演算
関係
演算

図３．２．１９ DBMS のビュー機能－ 33 －

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

３． ２．３．２ 共通インタフェース方式の統合 DB 機能の実装
共通インタフェース方式の統合 DB 機能は、統合 DB 機能に物理的な DBMS を必須とせず、提供側業務ユニットからのデータ提供機能が PULL 型（データを公開する機能）である特徴があり、具体的な実装として次の 3 パターンが考えられる。これらは実装が異なるだけであり、提供側または利用側から見ると全て同じ方式である。
（１） データ統合機能を持つ DBMS による実装（２） データ統合ミドルウェアによる実装（３） 専用アプリケーションによる実装
各実装パターンの仕組みと特徴は次の通り。
（１）データ統合機能を持つ DBMS による実装
図 3.2.20 は、データ統合機能を持つ RDBMS による実装パターンである。

提供側

DBMS

業務A
（マスタ）

A1

ＰＦ準拠
SOAP通信ﾌﾟﾛﾊﾞｲﾀﾞ

ＰＦ準拠
SOAP通信
X
ﾘｸｴｽﾀ

ＰＦ準拠
SOAP通信ﾌﾟﾛﾊﾞｲﾀﾞAｘ

ＰＦ準拠
SOAP通信
ﾘｸｴｽﾀ

業務X

A3

PULL

PULL

機能
X
SQL

（マスタ）

ＪＤＢＣ、
ＯＤＢＣ
など

B1

PULL

業務C

C1

ビュー
A2

A

業務B

（マスタ）

利用側

共通インタフェース方式の統合DB機能

ビュー
B2

ＳＱＬ

ＪＤＢＣ、
ＯＤＢＣ
など

検索機能
PULL

SQL
（レプリカ）
ﾚﾌﾟﾘ
ｹｰｼｮﾝ

B3

C3

ＪＤＢＣ、
ＯＤＢＣ
など

ビュー
C2

PULL

図３．２．２０ 共通インタフェース方式の統合 DB

実装パターン(1)DBMS 製品の中には、データ統合機能として外部の DBMS に存在するデータ（外部表）についても内部の表と同様に動的なビューを提供できるものがある。
統合 DB 機能として二次データを保持せず、利用側からのリクエストに従って提供側にアクセスを行い、－ 34 －

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

PULL 型のデータ検索によりデータを獲得するので、共通インタフェース方式に分類される。
統合 DB 機能に DBMS を採用しているので、利用 I/F の実現方法は公開用 DB 方式と同様になる。
SQL による提供 I/F、利用 I/F は DBMS が標準でサポートしているケースが多い。また、SOAP による提供 I/F、利用 I/F の実装は、地域情報 PF 標準の SOAP インタフェースをアプリケーションで実装することが多い。
DBMS から直接アクセスする外部表としては、提供側業務ユニットが持つマスタ表を直接設定する方法と、マスタ表のレプリカを設定する方法がある。このレプリカは統合 DB 機能の内部に作成すことも、外部に作成することもできる。
特徴はデータ統合機能を持つ DBMS が限られている点であるが、この種の DBMS は多くの種類の DBMS を入力としてサポートするものが多いので、提供側業務ユニットの DBMS について選択肢が広いが、DBMS の組み合わせに対する検証は必要である。
（２） データ統合ミドルウェアによる実装
図３．２．２１は、データ統合ミドルウェアによる実装パターンである。

提供側

業務A
（マスタ）

A1

ＰＦ準拠
SOAP通信ﾌﾟﾛﾊﾞｲﾀﾞ

ＰＦ準拠
SOAP通信
X
ﾘｸｴｽﾀ

ｽｷｰﾏ
A1

仮想表
A3

ＰＦ準拠
SOAP通信ﾌﾟﾛﾊﾞｲﾀﾞ

PULL

Aｘ

ＰＦ準拠
SOAP通信
ﾘｸｴｽﾀ

業務X

A3

PULL

機能
X
SQL
ＪＤＢＣ、
ＯＤＢＣ
など

（マスタ）

B1

ｽｷｰﾏ
B1

仮想表
B3

PULL

業務C

C1

データ統合ミドルウエア
（ＥＩＩ）

A

業務B

（マスタ）

利用側

共通インタフェース方式の統合DB機能

API（ＪＤＢＣ，
ＯＤＢＣ,
など）

ＳＱＬ
検索機能
PULL

SQL
（レプリカ）
ﾚﾌﾟﾘ
ｹｰｼｮﾝ

ＪＤＢＣ、
ＯＤＢＣ
など

B3

C3
ｽｷｰﾏ
C1

仮称表
C3

PULL

図３．２．２１ 共通インタフェース方式の統合 DB 実装パターン(2)統合 DB 機能に DBMS を使用せず、データ統合ミドルウェアに提供側業務ユニットのスキーマと、利用側に必要なスキーマを定義して、ミドルウェア（またはそのアプリケーション）の機能として利用 I/Fを実現する。具体的には、利用側からの検索要求を統合 DB 機能が受け取ると、必要な提供側業務ユニッ－ 35 －

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

トに対する検索要求に分解して提供側業務ユニットの検索を行い、その結果を統合して利用側に応答する処理が動的に行われる。
SQL による提供 I/F はミドルウェアが標準でサポートするケースが多く、SQL による利用 I/F はミドルウェアの API として提供されるケースがある。また、SOAP による提供 I/F、利用 I/F の実装は、地域情報 PF 標準の SOAP インタフェースをアプリケーションで実装することが多い。
統合 DB 機能に DBMS を持たず、検索処理が動的に行われ、検索結果は利用側が受け取った後は捨てられるので、統合 DB 機能側のデータ容量に対する配慮は不要である。
また、全てメモリ上で処理される実装では、複数のデータ統合サーバ（統合 DB 機能）を並列運用する
ことが容易であるため、性能面で有利である一方、検索結果を処理できるだけのメモリ量に留意する必要がある。
提供側業務ユニットへの影響を抑える目的で提供側のレプリカを使用する場合は、提供側にレプリカ用の DBMS が必要になる。
本方式は、オンデマンド、リアルタイム、柔軟な統合パターン、提供側の地域情報 PF 対応が容易などの共通インタフェース DB の長所を最も引き出せる実装である。
データ統合ミドルウェアとしては、EII(Enterprise Information Integration)という分野のソフト
ウェアが数社から提供が始まっており、フェデレーション機能と呼ばれることもある。
（３） 専用アプリケーションによる実装
図３．２．２２は、専用のアプリケーションによる実装パターンである。

提供側

専用
アプリケーション

業務A
（マスタ）

A1

利用側

共通インタフェース方式の統合DB機能

ＰＦ準拠
SOAP通信ﾌﾟﾛﾊﾞｲﾀﾞ

AX

ＰＦ準拠
SOAP通信ﾘｸｴｽﾀ

ＰＦ準拠
SOAP通信ﾌﾟﾛﾊﾞｲﾀﾞ

PULL

Aｘ

ＰＦ準拠
SOAP通信
ﾘｸｴｽﾀ

機能
X
API
（ＪＤＢＣ，
ＯＤＢＣ,
など）

ＪＤＢＣ、
ＯＤＢＣ ＳＱＬなど 検索機能

（マスタ）

B1

PULL

業務C

C1

A3

PULL

業務B

（マスタ）

業務X

ＳＱＬ
検索機能
PULL

SQL
（レプリカ）
ﾚﾌﾟﾘ
ｹｰｼｮﾝ

B3

C3

ＪＤＢＣ、
ＯＤＢＣ ＳＱＬなど 検索機能PULL

図３．２．２２ 共通インタフェース方式の統合 DB 実装パターン(3)－ 36 －

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

利用 I/F を含めて、地域情報 PF の統合 DB 機能専用のアプリケーションとして実装するパターンであり、特徴や留意点はパターン(2)と同様になる。
現時点では新規開発になるが、地域情報 PF の普及に伴って、統合 DB 機能専用のアプリケーションが開発されることにより現実的になるパターンである。

３．２．４

統合 DB 機能の導入

統合 DB 機能の導入に際して考慮すべき事項として、統合 DB 機能側の設定、既存の業務ユニットに対する統合 DB 機能の導入および、統合 DB 機能の移行（入れ替え）について解説する。

３．２．４．１ 統合 DB 機能側の設定
最初に統合 DB 機能側に必要な設定及び留意事項について表３．２．２にまとめる。
これらは、新規に統合 DB 機能を導入するケースは勿論、既存の業務ユニットに対する統合 DB 機能の導入、統合 DB 機能の移行（入れ替え）、業務ユニットの入れ替えに際して、導入する統合 DB 機能側または、変更する業務ユニットとの統合 DB 側 I/F に必要な共通事項である。

表３．２．２ 統合 DB 機能側の設定

公開用DB方式
SOAP

共通ｲﾝﾀﾌｪｰｽ方式
SQL

SOAP

SQL

□対象業務ユニットをサポートしていること □対象業務ユニットをサポートしていること□特に統合DB機能のデータ構造が十分か確認→不足項目はDBMSの表を拡張する。

提 □PUSH型のデー
供 タ登録サービスプロ
バイダ機能を設定
IF□JDBC,ODBCなど
によるPUSH型デー
タ提供機能の設定（DBMSの更新権を提供側業務ユニットに公開）□PF標準のSOAP
通信リクエスタを設定（提供側業務ユニットの参照権を設定）□提供側DBMSをサポートしていること□提供側のスキー
マなどを設定
□提供側業務ユニットの参照権を設定

利 □PF標準のSOAP □JDBC,ODBCなど □PF標準のSOAPによるPULL型データ 通信プロバイダ機
用 通信プロバイダ機
能を設定
検索機能の設定
能を設定
IF（DBMSの参照権を□利用側に必要なスキーマなどを設定□JDBC,ODBCなど
によるPULL型デー
タ検索機能の設定（統合DB機能の参照権を利用側業務ユニットに公開）

利用側業務ユニットに公開）－ 37 －

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

例えば、共通インタフェース方式の統合 DB 機能を導入する際に、提供 I/F として SQL を採用するケー
スでは、統合 DB 機能が対象業務ユニット及び、提供側業務ユニットの DBMS をサポートしている事を確認する。次に、提供側業務ユニットから提供されるデータのスキーマ及び提供側業務ユニットへのアクセス権を統合 DB 機能に設定する必要がある。
なお、これらの事項は代表的な統合 DB の実装についてまとめており、具体的には統合 DB 機能の実装毎に定められた設定を行うことになる。

３．２．４．２ 既存の業務ユニットに対する統合 DB 機能の導入
既存の業務ユニットが統合 DB 機能に対応するとき（統合 DB 機能の導入時）に必要となる事項を表３．
２．３に示す。
表３．２．３ 既存業務ユニットの対応

提供側

公開用DB方式
PUSH型のデータ提供機能（統合DB機能のデータ更新）①提供I/F=SOAP②提供I/F=ＳＱＬ

利用
側

統合DB機能の利用⑤利用I/F=SOAP⑥利用I/F=ＳＱＬ

共通ｲﾝﾀﾌｪｰｽ方式
PULL型のデータ提供機能（統合DB機能へデータ公開）③提供I/F=SOAP④提供I/F=ＳＱＬ（１）提供側業務ユニットの対応
提供側業務ユニットの対応は、統合 DB 機能の方式により必要な対応が異なる。
公開用 DB 方式の統合 DB 機能を採用する場合は、PUSH 型で統合 DB 機能にデータを提供する機能（統合DB 機能のデータを更新する機能）を提供側業務ユニットに実装する必要がある。このとき使用する統合
DB 機能の提供 I/F は、統合 DB 機能がサポートする①SOAP または②SQL となり、その仕様は一般的に統合
DB 機能の実装に依存する。
共通インタフェース方式の統合 DB 機能を採用する場合は、PULL 型で統合 DB 機能にデータを公開する必要がある。提供側業務ユニットが地域情報 PF 対応のものについては、提供 I/F として③SOAP を採用することにより、提供側業務ユニットがサポートしている標準の SOAP インタフェースをそのまま使用できる。
一方、提供側業務ユニットが地域情報 PF に対応していないものについては、提供 I/F として④SQL を採用することにより、提供側業務ユニットで採用されている DBMS へのアクセス手段を統合 DB 機能に公開することにより対応できるので、導入が容易になる。
（２）利用側業務ユニットの対応
利用側業務ユニットは、他の業務ユニットのデータを活用する際に統合 DB 機能を介して必要なデータを取得するようにすべきである。この際に使用する統合 DB 機能の利用 I/F は、地域情報 PF で標準化す－ 38 －

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

る⑤SOAP によるインタフェースを採用することにより統合 DB 機能の実装に関わらず、高い差し替え性を確保できる。
また、利用 I/F として統合 DB 機能がサポートする⑥SQL インタフェースを使用することも可能である。
この場合、インタフェースは統合 DB 機能に依存するが、性能などを追求することができる。
（３）段階的な導入
統合 DB 機能により、既存の業務システムへの地域情報 PF 導入を段階的に進めることができる。
①統合 DB を先行的に導入する②多くの業務ユニットにデータを提供する業務ユニットから順に、統合 DB 機能の提供側業務ユニットに対応し、管理しているデータを提供する環境を整える。
③統合 DB 機能に対応したデータから順次、利用側業務ユニットからの統合 DB 利用を開始する。

３．２．４．３ 統合 DB 機能の移行（差し替え）
既に導入されている統合 DB 機能を差し替える際に必要となる業務ユニットの対応について、提供側業
務ユニット、利用側業務ユニットに分けて解説する。なお、ここでは既存の業務ユニットは地域情報 PF
対応済みであること前提に説明している。
（１） 提供側業務ユニットの対応
旧統合 DB 機能を新統合 DB 機能に差し替える際に必要となる提供側業務ユニットの対応について表３．
２．４で整理する。

表３．２．４ 統合 DB 機能の差し替えにおける提供側業務ユニットの対応

新旧

公開用DB方式⑤SOAP

共通ｲﾝﾀﾌｪｰｽ方式

⑥SQL

⑦SOAP

⑧SQL

① SOAPのPUSH型
公 S 提供機能①を新しい統合DB機能の
開 O SOAP⑤に変更
A用
D P

SOAPのPUSH型
提供機能①を新し
い統合DB機能のSQL⑥に変更

既存の提供機能①を停止

既存の提供機能①を停止して、提供側
DBMSのSQLイン
タフェース⑧を公開

B ② SQLのPUSH型

SQLのPUSH型提供機能②を新しい統合DB機能のSQL⑥に変更

既存の提供機能②を停止

既存の提供機能②を停止して、提供側
DBMSのSQLイン
タフェース⑧を公開

共 ③ 新しい統合DB機
能のSOAPによる
通 S
PUSH型提供機能
I O ⑤を追加
F A

新しい統合DB機能のSQLによる
PUSH型提供機能
⑥を追加

○対応不要

提供側DBMSのSQLインタフェース⑧を公開

新しい統合DB機能のSQLによる
PUSH型提供機能
⑥を追加

○対応不要

○対応不要

提供機能②を新し
方 S い統合DB機能の式 Q SOAP⑤に変更
L方 P
式 ④ 新しい統合DB機

S 能のSOAPによるQ PUSH型提供機能⑤を追加
L－ 39 －

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

表３．２．４は、行方向（旧）が入れ替え前の統合 DB 機能の方式と提供側で採用されているインタフェー
スを示し、列方向（新）が差し替え後の統合 DB 機能の方式と提供側で新たに採用するインタフェースを示し、枠内はそれぞれの組み合わせにより必要となる提供側業務ユニットの作業を示している。共通インタフェース方式の統合 DB 機能は、比較的差し替えに強いことが解る。
（２）利用側業務ユニットの対応
旧統合 DB 機能を新統合 DB 機能に差し替える際に必要となる利用側業務ユニットの対応について表３．
２．５で整理する。
表３．２．５は、行方向（旧）が入れ替え前の統合 DB 機能の方式と利用側で採用されているインタフェー
スを示し、列方向（新）が差し替え後の統合 DB 機能の方式と利用側で新たに採用するインタフェースを示し、枠内はそれぞれの組み合わせにより必要となる利用側業務ユニットの作業を示している。
SOAP インタフェースを新旧共に利用 I/F として採用している場合は、統合 DB 機能の差し替えは利用側
業務ユニットには影響しない。
但し、利用 I/F として新旧いずれかに SQL を採用している場合には、利用側業務ユニットにも修正が必要となる。

表３．２．５ 統合 DB 機能の差し替えにおける利用側業務ユニットの対応

新旧

公開用DB方式⑤SOAP

共通ｲﾝﾀﾌｪｰｽ方式

⑥SQL

⑦SOAP

⑧SQL

○対応不要

標準SOAPによる
利用I/Fを新しい統合DB機能のSQL⑥に変更○対応不要

標準SOAPによる
利用I/Fを新しい統合DB機能のSQL⑧に変更

B ② 旧SQLによる利用

旧SQLによる利用
I/F②を新しい統合DB機能のSQL⑥に変更

旧SQLによる利用
I/F②を標準のSOAPに変更

旧SQLによる利用
I/F②を新しい統合DB機能のSQL⑧に変更

標準SOAPによる
利用I/Fを新しい統合DB機能のSQL⑥に変更○対応不要

標準SOAPによる
利用I/Fを新しい統合DB機能のSQL⑧に変更

旧SQLによる利用
I/F④を新しい統合DB機能のSQL⑥に変更

旧SQLによる利用
I/F④を標準のSOAPに変更

旧SQLによる利用
I/F④を新しい統合DB機能のSQL⑧に変更

①
公 S
開 O
A
用
D P

I/F②を標準の
方 S SOAPに変更
式 Q
L

共 ③
通 S
I O
F A

○対応不要

方 P
式 ④ 旧SQLによる利用
S I/F④を標準の
Q SOAPに変更
L－ 40 －

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

３．２．５

統合 DB 機能のデータモデル

地域情報 PF 標準で規定しているデータ連携のインタフェース（ツリー構造）と、統合 DB 機能の実装として採用する表構造間のマッピングについて考え方および留意点を解説する。
「自治体業務アプリケーションユニット標準仕様」で規定している業務ユニット間のデータ連携のイ
ンタフェースは SOAP(XML)で規定しており、データモデルとして「ツリー構造」を採用している。
一方、業務ユニットや統合 DB 機能の具体的な実装は、データの管理に RDB（リレーショナルデータベース）を採用するのが一般的であり、データモデルとして「表構造」を採用する必要がある。

コラム３．２．５「ツリー構造と表構造」

ツリー構造と表構造の一般的な性質について、表３．２．６にまとめる。

表３．２．６ データモデル

ツリー構造

表構造

□SOAPで使用するXMLはツリー構造□１つの親ノードが０～N個の子ノードを持つ階
層構造□ＲＤＢＭＳやＳＱＬは表構造を使用する□列方向にフラットな項目が並び、行方向にデータ（値）が並ぶ2次元構造

親
子
孫

項目１

項目２

項目３

子
孫

孫

□ツリーは先頭ノードで識別する□ノードの名前は任意（重複を許す）□ノードの性質は位置で決まる□存在しないノードを許す。
□ノードをたどって検索する□表は名前（表名）で識別する□項目名は表内でユニーク□項目の性質は列で決まる□値が無い項目も存在する（NULL値）◇ツリー構造は表構造を表現可能☆ノードの繰り返し構造◇表構造で表現できないツリー構造がある。
☆複数の表に分割することで表現可能□キー項目の値で検索する

・同じ位置に同じノード構造が複数存在する構造★ノードの再帰構造★再帰構造は表現できない

・１つのノード構造の中に自分のノード構造が存在する。

地域情報 PF 標準では表構造について規定していないが、地域情報 PF で標準化しているツリー構造は
表構造への変換を次の点で考慮しているので、相互に変換が可能である。
◇再帰的なツリー構造はない（ノードの繰り返しは存在する）
表構造とツリー構造の特徴を十分理解した上で、統合 DB 機能のデータモデル設計および変換機能の実装を行う必要がある。以下に変換規則の例を示す。
－ 41 －

地域情報プラットフォームガイドライン（１）原則的な変換（別表への分割）
全ての場合に変換可能であることを保障するためには、ツリー構造の繰り返し部分は、別の表に分割する。（図３．２．２３）

統合DB機能（複数の表）
キー項目の導入

連携I/F（ツリー構造）

利用側業務ユニット
資格者表

住基情報
Key

世帯０：M

世帯番号

住民表

世帯表
Key 世帯番号

Key

世帯番号

住所

住民ID

世帯主

住所

住所

氏名

世帯主

生年月日

０～M個
の
繰り返し

世帯主

世帯番号

住民 1：N
氏名

ﾏｯﾋﾟﾝｸﾞ
表→ﾂﾘｰ

ｷｰの参照

資格番号

生年月日

1～Ｎ個
の
繰り返し

氏名
生年月日

ﾏｯﾋﾟﾝｸﾞ
ﾂﾘｰ→表

図３．２．２３ データモデルの変換（データ構造例）【分割ルール】①ツリー構造の同じ位置に繰り返し現れる可能性のあるノードは、別の表に分割する。
②別の表に分割したノードには、ユニークなキー項目を追加して一意性を保障する。
③分割したノード位置には、②で追加した表への参照を置く。

統合DB機能（複数の表）

連携I/F（ツリー構造）

住基情報

世帯表
世帯番号 住所 世帯主001
北区 100002
南区 110世帯
世帯番号：001

住民表
住民ID
100
101
110

氏名
佐藤一郎
佐藤次郎
田中一郎

生年月日 世帯番号
1980.1.1
001
1981.1.1
001
1970.1.1
002

ﾏｯﾋﾟﾝｸﾞ
表→ﾂﾘｰ

住所：北区
世帯主：佐藤一郎
住民
氏名：佐藤一郎
生年月日：1980.1.1
住民

1～Ｎ個
の
繰り返し

氏名：佐藤次郎
生年月日：1981.1.1
世帯
世帯番号：002
住所：南区
世帯主：田中一郎
住民
氏名：田中一郎
生年月日：1970.1.1

図３．２．２４ データモデルの変換（データ例）－ 42 －

1～Ｎ個
の
繰り返し

０～M個
の
繰り返し

地域情報プラットフォームガイドライン（２）簡易的な変換（同一表への展開）
小さい表がたくさんできることを抑えるために、次の要件を満足する繰り返しノードは、別表に分割しないで、簡易的な変換とすることもできる。（図３．２．２５）【簡易的な変換の採用条件】◇繰り返し数の最大値が有限個であること。
◇繰り返し数の最大値が将来増えないこと。
◇繰り返し数の最大値が少ないこと。

統合DB機能（１つの表）

連携I/F（ツリー構造）

世帯表
Key

利用側業務ユニット

住基情報

資格者表

世帯０：M

世帯番号
住所

Key

資格番号
世帯番号

世帯番号

世帯主

住所

住民1_氏名
住民1_生年月日
住民2_氏名

住所

有限
繰り返し
の展開

住民 1：5

住民2_生年月日
住民3_氏名
住民3_生年月日

ﾏｯﾋﾟﾝｸﾞ
表→ﾂﾘｰ

氏名
生年月日

世帯主

０～M個
の
繰り返し

世帯主

1～5個
の
繰り返し

氏名
生年月日

ﾏｯﾋﾟﾝｸﾞﾂﾘｰ→表住民4_氏名
住民4_生年月日
住民5_氏名
住民5_生年月日

図３．２．２５ 簡易的なデータモデルの変換（データ構造例）【簡易的な変換の適用ルール】①ツリー構造の同じ位置に繰り返し現れるノードを、最大の繰り返し数だけ、別の名前の項目として展開する。（表構造で表現できる先頭ノードの繰り返しはそのままにする）②該当ノードの子ノードが存在する場合は、該当ノードと併せて 1 つの項目にする。
③該当ノードの子孫ノードは別途変換規則（原則的な変換または簡易的な変換）を再帰的に適用する。
【簡易的な変換の規則例】①繰り返し項目の表展開
有限回数の繰り返し項目について、統合 DB 機能は RDB 表として最大繰り返し数分の項目を準備する。(但し先頭ノードの繰返しは表のタプルとして表現されるので変換の対象外）②繰り返し項目の項目名変更
繰り返し項目は、表構造にしたときに同じ項目名にならないようにユニークな名前に置き換える。例えば、項目名の末尾に 1 から始まる追番を半角数字で付与する。
世帯番号

住民1

住民2

－ 43 －

住民3

住民4

住民5

地域情報プラットフォームガイドライン③子ノードの展開
子ノードを表に展開する場合は、子ノードの名前と併せてユニークな項目名とする。
例えば、ツリー構造のノード名の各階層を_(半角アンダーバー)で繋いだものを表構造の項目
名とする。

ツリー構造
世帯
住民

表構造
世帯番号
住民_氏名
住民_生年月日

氏名
生年月日④再帰的な構造の禁止

再帰的なツリー構造は表構造で表現しにくいので使用しない（地域情報 PF では使用しない）
。

世帯
住民
氏名

【再帰構造】
子（子孫）ノードに親（祖先）ノードの構造を再帰的に持つ

生年月日
住民
氏名
生年月日
住民
⑤再帰的な構造の例外

有限回数の再帰構造は次の手段により表構造に展開できるが、複雑になるので推奨しない。
表構造

ツリー構造
世帯
住民
氏名
生年月日
住民
１回だけの
再帰構造

氏名

世帯番号
住民_氏名
住民_生年月日
住民_住民_氏名住民_住民_生年月日

生年月日

図３．２．２６ 簡易的なデータモデル変換の規則例（３）留意事項
表構造は地域情報 PF で標準化していないが、一度実装されると変更することが難しくなるので、将来の拡張を考慮して慎重に設計すべきである。
①原則的な変換（別表への展開）の際は、性能や管理面を考慮して必要以上に小さな表にしない。
②簡易的な変換（同一表への展開）の際は、繰り返し項目の最大回数を現実的な値とする。
◇多すぎると性能劣化やデータ量増加の原因となる。
◇少ないと機能への制約になるばかりでなく、将来設計変更が必要となる。
③表名や項目名には外字や文字コード系に依存する文字を使わない。
－ 44 －

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

３．２．６

統合 DB 機能へのアクセス方式

利用側業務ユニットから統合 DB 機能を利用する場合の SOAP、SQL それぞれのアクセス方式について解説する。
（１） 標準化した SOAP インタフェース「自治体業務アプリケーション標準仕様」で規定している業務ユニット間のデータ連携のインタ
フェースを使用して、統合 DB 機能を利用する方法である。
標準化しているインタフェースの採用により、
統合 DB 機能の方式や実装に依存することなく、利用側業務ユニットは統合 DB 機能を利用して必要なデータを取得することができる。
（図３．２．２７）

SOAP Envelope (XML)
SOAP Header
SOAP Body(メッセージ本体）

ＢＰＭ

システム制御情報（共通ヘッダ部)依頼
ﾒｯｾｰｼﾞ
提供側
業務ﾕﾆｯﾄ

主キー情報：
統合DB
機能

SOAP Header

統合DB
機能の
利用

利用
Data

主キー情報：
世帯番号＝10010

SOAP Envelope (XML)

依頼
ＸＭＬ

更新

提供

利用側
業務ﾕﾆｯﾄ

ビジネス情報（XML本体部)

応答
ＸＭＬ

SOAP Body(メッセージ本体）
システム制御情報（共通ヘッダ部)

応答
ﾒｯｾｰｼﾞ

【利用側のインタフェース仕様】（ＷＳＤＬで定義）

ビジネス情報（XML本体部)

世帯全員
の
住基情報

図３．２．２７ 統合 DB 機能の利用 I/F（概念）

具体的には次の仕様として規定している。
◇自治体業務アプリケーション標準仕様【インタフェース一覧】資料№「業務 1-9」
この中で、提供側業務ユニット毎にサービス仕様(WDSL)およびデータ構造（XML スキーマ）を定義しており、統合 DB 機能に対するアクセスは、このインタフェース(SOAP)でアクセスすることになる。
例えば、図３．２．２８に示す「住民基本台帳」業務ユニットは、「個人情報メッセージ」を返す「1-1」と、「世帯情報メッセージ」を返す「1-2」の 2 つのサービスインタフェースを定義している。
－ 45 －

地域情報プラットフォームガイドライン【インタフェース定義】【依頼メッセージ】【応答メッセージ】

図３．２．２８ 自治体業務アプリケーション標準仕様【インタフェース一覧】（抜粋）－ 46 －

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

即ち、個人情報を参照する「1-1」のサービスを利用する場合は、利用側業務ユニットが住民個人を識別する「識別番号メッセージ」を統合 DB 機能に送信し、統合 DB 機能は指定された識別番号を持つ個人（1 名分）の「個人情報メッセージ」を応答として返す。
また、世帯情報を参照する「1-2」のサービスを利用する場合は、利用側業務ユニットが世帯を識別す
る「世帯番号メッセージ」を統合 DB 機能に送信し、統合 DB 機能は指定された世帯番号を持つ家族（1 名～50 名分）の「世帯情報メッセージ」を応答として返す。
このように、標準化した SOAP インタフェースは、規定した項目（キー項目）に対する検索条件（値）を指す依頼メッセージに対して、規定した検索結果を格納した応答メッセージを返すものであり、データ構造は XML で表現されたツリーを採用している。
利用側業務ユニットが表構造でデータを扱っている場合には、利用側業務ユニット内のデータモデルとの間で、マッピング（データ構造変換）が必要となる。
（２）SQL インタフェース
SQL による統合 DB 機能の利用 I/F は標準化していないため、その利用方法は統合 DB 機能の実装に依存
するが、性能や通信情報の削減によるネットワーク負荷軽減などの目的で採用することができる。
SQL インタフェースを利用 I/F として採用する場合の留意点について解説する。
①標準的なインタフェースの採用
SQL による統合 DB 機能の利用において使用するインタフェースは統合 DB 機能から提供されるものを利用することになるので、厳密には統合 DB 機能の実装に依存するが、依存部分を最小化するために ODBC、JDBC などの標準化されたインタフェースを優先して採用するべきである。
②データモデルへの配慮
SQL による統合 DB 機能の利用では、データモデルとして統合 DB 機能側で規定される表モデルを採用し、表に対する条件検索として利用することになる。この表モデルは標準化していないため、統合 DB 機能に
より利用方法が異なるので留意する必要がある。この時、「3.2.5 統合 DB 機能のデータモデル」で解説した事項へ配慮することで、非互換を最小化するのに役立つ。
③データ表現への配慮
統合 DB 機能の SQL インタフェースは統合 DB 機能の実装に依存して扱うデータの表現が異なる場合がある。例えば、JDBC インタフェースを利用する際の数値の表現（バイナリ表現）は、統合 DB 機能の実装（採用している DBMS など）により異なる場合がある。
④利用する SQL 機能への配慮
統合 DB 機能の SQL インタフェースにおける SQL 機能は、その文法も含めて厳密には統合 DB 機能の実装（採用している DBMS など）により異なる場合がある。対策として、利用する SQL 機能は統合 DB の実装に依存しない範囲の必要最小限の機能だけにすることにより、非互換を最小化することができる。推奨する SQL の利用範囲は「汎用検索インタフェース」の問い合わせ言語欄を参照のこと。
（3.2.7.3(3)を参照）－ 47 －

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

３．２．７

統合 DB 機能の応用

統合 DB 機能の応用として、「共通データの公開」「コード辞書の統合と公開」「汎用的な検索」「複数の情報源の統合」について解説する。これらは標準化していないが、有用な活用方法である。

３．２．７．１ 共通データ公開
複数の業務ユニットで共通的に利用する共通データのマスタを共通データ管理機能により集中管理する機能である。
この機能は標準化していないので自治体の実情に合った仕組みで導入されるが、統合 DB 機能が貢献できるポイントとして共通データの公開がある。
共通データのマスタは、専用のユニット（共通データ管理機能）で管理するべきである。また、複数の部署に跨るデータの管理になるので、共通データのメンテナンス体制を確立することも重要である。
独立して運用されている共通データ管理機能を 1 つの提供側業務ユニットとして扱うことにより、統合 DB 機能を利用して共通データを各業務ユニットから利用できるようにすると便利である（図３．２．
２９）。

共通データ管理機能

共通データ管理
管理者
宛名管理

住所辞書

コード
辞書

金融機関
ﾃｰﾌﾞﾙ

提供
I/F

住基ユニット

国保ユニット

児童手当ユニット

住基

国保

児童

住基DB

国保DB

児童DB

提供
I/F

利用
I/F

提供
I/F

利用
I/F

提供
I/F

利用
I/F

統合DB機能図３．２．２９ 統合 DB 機能による共通データの公開

また、共通データを物理的に集中管理するのではなく、複数の業務ユニットに分散して管理されている共通データを統合 DB 機能により統合して公開する方法もある。この場合、複数の業務ユニットに跨るデータになるので、「3.2.7.4 複数の情報源の複雑な統合」も参考になる。
－ 48 －

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

３．２．７．２

コード辞書の統合と公開

コード辞書は、次の業務標準に記述しており、自治体内で統一することを推奨している。
◇自治体業務アプリケーション標準仕様【コード辞書】資料№「業務 1-13」
統合 DB 機能でコード辞書の統合を行い、公開することにより次のメリットが期待できる。
①自治体内でコード辞書の利用を一本化することにより、各種コードが統一され、業務ユニット間のコード辞書非互換が是正される。
②コード辞書の分散管理が可能になる。
③将来の自治体間または民間との連携の際、コード辞書による読み替えや、コード辞書の変換を行う基盤となる。
コード辞書は次の２種類について業務標準で記述している。
・業務ユニットに共通のコードである「コード辞書（共通）」
・業務ユニット毎に定義されている「コード辞書（業務ユニット名）」
統合 DB 機能はマスタデータを管理する機能を持たないので、具体的なシステム構成として次の 2 種類がある。
（１）共通データとしてコード辞書のマスタを集中管理する方法
共通データとして全てのコード辞書の集中管理を行い、統合 DB 機能を介して各業務ユニットから利用（参照）できるように構成する方法である。コード辞書の管理を一本化できるメリットがある。
（２）「コード辞書（業務ユニット名）」の管理を業務ユニットに分散する方法
共通データとしては、業務ユニットに依存しない「コード辞書（共通）」のマスタ管理を行い、業務ユニットに依存する「コード辞書（業務ユニット名）」のマスタ管理は各業務ユニットに委ねて分散管理する方法である。
各業務ユニットで管理されているコード辞書は、統合 DB 機能で統合され、各業務ユニットに公開されるため、各業務ユニットは(1)と同様に統合されたコード辞書を活用することができる。
分散方式(2)のメリットは、コード辞書のメンテナンスを各業務ユニットに閉じて実施できる点と、業務ユニットの差し替えにより業務ユニットに依存するコード辞書に変更が生じた際の対応が容易になる点である。
また、体系の異なるコード辞書を使っている業務ユニットとのデータ交換では、交換時に業務コードの相互変換が必要になる場合があり、統合 DB 機能を介して双方のコード辞書を利用することにより変換機能の実装及び運用が容易になる効果も期待できる。

３．２．７．３

汎用的な検索インタフェース

自治体業務アプリケーション標準仕様で標準化している統合 DB 機能の利用 I/F（SOAP：3.2.6(1)参照）
は、規定したキーによる統合 DB 機能の利用(検索)であり、定型業務では有効である。一方、非定型業務など自由な条件による検索を利用したいケースもあるので、統合 DB 機能には、標準化した SOAP インタ
フェース以外に、汎用的な検索インタフェースを持つと便利である。
－ 49 －

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

ここでは、汎用的な統合 DB 検索インタフェースの仕様例について解説する。
（１）SQL インタフェース
SQL インタフェース（3.2.6(2)参照）は、キー項目以外の項目も検索条件として指定することができるので汎用的な統合 DB 検索インタフェースである。
（２）SOAP インタフェース
自治体業務アプリケーション標準仕様で標準化している統合 DB 機能の利用 I/F について、次の 2 件の拡張を行うことにより汎用的な条件検索を実現することができる。（汎用検索）◇依頼メッセージの検索条件として、汎用的な検索条件（SQL など）を記述できるようにする。
◇応答メッセージの検索結果は、依頼メッセージで指定された検索対象の構造を持つ検索結果となる
ように拡張する。
図３．２．３０に SOAP による汎用検索インタフェースの例を示す。

統合DB問合せフォーム

統合DB機能住基表

依頼

検索<検索条件><利用ユニット>15</利用ユニット><ＳＱＬ> ＳＱＬ文 </SQL></検索フォーム>

検索結果

印鑑登録表
汎用検索
インタフェース

固定資産税
課税表
国民年金表

結果

国民健康保険表

応答<検索結果><利用ユニット>15</利用ユニット><表名>住基表</表名><検索条件><ＳＱＬ> ＳＱＬ文 </SQL></検索条件><結果><識別番号>0010102</個人番号><世帯番号>002222</世帯番号><氏名>□□ □□</氏名><生年月日>2007.1.1</生年月日>
・・・・
</結果>
<ERROR>エラー状態</ERROR></検索結果>正常時

異常時

該当データが無い場合は<結果> </結果>となる

図３．２．３０ 汎用検索インタフェースの例(SOAP)①利用側業務ユニットは問い合わせフォームの<SQL>タグに検索条件を SQL で記述して統合 DB 機能に検索依頼メッセージを送信する。
②統合 DB 機能は、受信した検索依頼メッセージの<SQL>タグを参照し、SQL 文で指定された表の検索を実行してその結果を<結果>タグに格納して利用側業務ユニットに応答する。
－ 50 －

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

この時、結果が 0 件であれば、<結果>タグの値は空になる。
また、統合 DB 機能側で何らかのエラーが発生した場合には、<ERROR>タグでエラー内容を返す。
<結果>タグの内容として次の方法がある。
①検索対象表の項目名を<COLUMN>タグの属性値とするフラットな XML タグセットにして値を格納する。
②CSV フォーマットで検索結果を格納する。
◇「利用業務ユニット番号」は自治体業務アプリケーション標準仕様【業務ユニット番号一覧】資料№「業務 1-3」を参照

標準表名（１）XML<TABLE name=“標準表名”><RECORD><COLUMN name=“列名”> 値 </COLUMN>・・・・・・・・</RECORD>
・・・・・・・・<RECORD>・・・・・・・・</RECORD></TABLE>（２）CSV<TABLE name=“標準表名”
column=“列名, ・・・・・・・・” ><RECORD>
値,・・・・・・・・</RECORD>
・・・・・・・・<RECORD>・・・・・・・・</RECORD></TABLE>

列名１

列名２

・・・

列名n ←スキーマ

値１

値２

・・・

値n

・・

・・

・・・

・・

・・

・・

・・・

・・

←レコード

列数だけ繰り返し（NULL列は省略可)
レコード数だけ繰り返し

標準表のスキーマ（列名のリスト）
１行で１レコードを表すデータ（スキーマ順のコンマ区切り値リスト）
レコード数だけ繰り返し

図３．２．３１ 汎用検索インタフェースの結果例（３）必要最低限の検索言語(SQL)
汎用検索で使用する SQL タグの値として指定できる検索要求（SQL 文）は次に示す SQL の範囲で使用することが望ましい。
また、利用 I/F、提供 I/F として SQL インタフェースを採用する場合にも、実装(RDBMS)への依存をなくすため、必要最小限の SQL 機能を利用するとよい。
理由 1：実装依存の防止
SQL 文には実装に依存する仕様があるので、必要最小限の共通的な仕様に限定することで、非互換を最小限に抑える効果がある。
理由 2：実装を容易にする
SQL 文を単純にすることで、統合 DB 機能や SOAP サービス機能の実装が容易になる。
特に DBMS の実装を前提としない共通インタフェース方式の統合 DB 機能では、複雑な SQL を実装す－ 51 －

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

るコストが高い。
◇SQL 仕様

SELECT 選択リスト

FROM 標準表名

選択リスト ::= * | 選択項目[, 選択項目]...

WHERE 検索条件（＊は全項目の選択）

検索条件 ::= 検索条件 AND 検索条件 | 検索条件 OR 検索条件

| （ 検索条件)| 述部

述部 ::= 項目名 比較演算子 値 |項目名 LIKE 検索パターン

|

項目名

IN

（ 値 [ ,値 ] )比較演算子 ::= < | > | <= | >= | = | <>値 ::= 数字列 ｜ ‘ 文字列 ’・LIKE の検索パターンには曖昧検索条件値として、次のメタ文字を使える。
%: 任意の数の文字（ゼロ文字を含む）と一致する。
_: 厳密に 1 つの文字と一致する。
（マルチバイト文字も 1 文字として扱う）
・FROM 句に記述できるのは、1 つの標準表名のみ
・選択項目は、対象表の項目名
・項目名は、対象表の列名（留意点）①複数の対象表間における関係演算はしない（項目同士の比較演算も不要）→

同じ結果となるビュー表で対応できる。

②XML の値に記述できない記号はエンティティー参照を使用する。
例）<SQL>SELECT * FROM 住民台帳

WHERE 氏名=&apos;田中&apos;

AND 年齢 &gt; 20 <SQL>

置換対象文字エンティティー文字

<

&lt;

>

&gt;

‘

&apos;“&quot;－ 52 －

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

３．２．７．４

複数の情報源の複雑な統合

自治体業務アプリケーション標準仕様で標準化している統合 DB 機能の利用 I/F は、提供側業務ユニッ
ト毎に閉じたデータ構造になっており、複数の提供側業務ユニットに跨るデータの取得（検索）機能はない。より便利な統合 DB 機能の使い方として複数の情報源（提供側業務ユニット）に跨るデータの統合
機能について解説する。
統合対象の一次情報（マスタデータ）は、分散管理されていても良いが、何れかの業務ユニットで管理され、提供側として統合 DB 機能に設定することが前提となる。また、複数の情報源に跨るデータの検索には、統合 DB 機能がデータ統合機能を持つ必要がある。
提供側業務ユニットへの影響がなく、利用側業務ユニットは目的とするデータ構造で統合 DB 機能を利用できることが望ましい。統合 DB 機能の方式毎に実現方法を以下に示す。
（図３．２．３２）

検索I/F

提供I/F

提供側業務ﾕﾆｯﾄ

統合DB機能業務ユニットA

Ａ１
Ａ１

Ａ２

ＰＵＳＨ型

Ａ２ 更新機能

ＤＢ－A

Ａ３

X1
SOAP

Ｂ１
ＤＢ－B

Ｂ２

機能 – Ｙ

Y1
SOAP

業務ユニットB

Ｂ１

業務ユニット

統合DB
X1

Ａ３

ＰＵＳＨ型

Ｂ２ 更新機能
Ｂ３

Ｂ３

利用側業務ﾕﾆｯﾄ

ＤＢ－Ｙ

X2
X2
SOAP

公開用ＤＢ方式
DBMSの関係演算で複雑な検索を実現

業務ユニットC

C１

ＤＢ－C

C１

C２

C２
C３

業務ユニットD

D２

C３

D３

統合DB機能

JDBC

D２

X1

D１
D２
D３

ＳＱＬ

D３

業務ユニット

C１
C２
C３

SOAP

D１

ＤＢ－D

D１

PULL型
提供機能

X2

Y1

SOAP

機能 - X
ＤＢ－X

共通ｲﾝﾀﾌｪｰｽ方式
統合機能で複雑な検索を実現

図３．２．３２ 複雑な検索の実現例（１）公開用 DB 方式
公開用 DB 方式の統合 DB 機能は RDBMS により実現されるものであり、RDBMS のビュー機能を活用することで複数の情報源に跨るデータの検索（データ統合）を実現できる。
（２）共通インタフェース方式
共通インタフェース方式の統合 DB 機能は、RDBMS を必要とせず、統合 DB 機能が情報源（提供側業務ユニット）のデータモデルを意識して動的に仮想統合するものであり、複数の情報源のデータモデル（ス－ 53 －

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

キーマ定義）を持ち、情報源を仮想統合するための仮想ビューを利用側業務ユニットからアクセス可能にする機能により複数の情報源に跨るデータの検索（データ統合）を実現できる。

３．２．８

統合 DB 機能のセキュリティ

統合 DB 機能は、多くの業務ユニットのデータを公開する機能なので、セキュリティに対する考慮が必要である。
以下に統合 DB 機能のセキュリティに対する考え方および留意事項について記載する。
（１）自治体外部からの統合 DB 利用制限
統合 DB 機能は自治体内の業務ユニット間におけるデータ交換を担うものであり、自治体外部（サイト外）から直接利用されることは想定していない。
（サイト間におけるデータ交換はスコープ外である。
）従って、自治体間や官民連携など、サイトを跨るデータ交換は、外部データ連係専用の機能（外部ｻｰﾋﾞｽ連携機能）を介して実施する。（図３．２．３３）
この外部サービス連携機能とは、外部からの統合 DB 利用依頼に対して、認証や権限の確認を行い、外部に提供可能なデータであることを確認した上で利用側業務ユニットに代わって統合 DB 機能へのア
クセスを行い、外部向けのデータ表現に補正して外部にデータを提供する機能である。

業務ユニットB

業務ユニットA
機能

外部ｻｰﾋﾞｽ
連係機能

データ交換

ＤＢ

機能
ＤＢ

統合DB機能自治体２ / 民間１

自治体1

図３．２．３３ 自治体外部とのデータ交換（２）統合 DB 機能のアクセス権制御
統合 DB 機能で公開されるデータに対するアクセス権制御は、そのデータ毎に、利用側業務ユニット
単位で制御されるべきである。
個人に対する認証やアクセス権の制御は利用側業務ユニット側で実施されるべきである。
（３）データに対するアクセス権
統合 DB 機能で公開されるデータには、データ項目毎に公開または非公開とする業務を規定する方法がある。

－ 54 －

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

表３．２．７ アクセス権の設定方法
アクセス権の設定方法 指定業務から その他の業務からアクセス

データ項目単位にどちらの指定アクセス
公開する業務を指定○

×

方法で規定する

非公開の業務を指定

×○かを選択する。

何も指定しない○○（混在禁止）（４）統合 DB 機能は利用記録として次の項目のアクセスログを取得するべきである。
この利用記録を追跡する事により、統合 DB 機能の利用状況管理に役立つ。
表３．２．８ 取得すべきアクセスログ
記 録 項 目解説

アクセス日時

統合 DB 機能から情報を取得した日時

アクセス業務

利用業務ユニット番号(※1)およびメッセージ
ID

アクセス条件

統合 DB 機能に対する検索条件

アクセス結果件数 検索結果データ件数（※2）（※1）利用業務ユニット番号は自治体業務アプリケーション標準仕様【業務ユニット番号一覧】資料№「業務 1-3」を参照。
（※2）アクセスされたデータそのもの（データ実体）をログとして記録すると、ログを通して情報漏えいが発生するリスクがあるので、データ実体は記録しないことを推奨する。
（５）提供側業務ユニットへのアクセス権制御
統合 DB 機能は全ての提供側業務ユニットとデータ交換を行うため、そのアクセス権は統合 DB 管理以外の目的で利用されないように適切に管理すべきである。（例：アクセス権定義ファイルの暗号化）

３．２．９

統合 DB 機能におけるエラーの扱いについてアーキテクチャ標準仕様の「4.5.4.9 統合 DB 機能のエラー処理」および「4.5.4.10 統合 DB 機能における共通ヘッダの扱い」に規定する統合 DB 機能におけるエラーの扱いの考え方について解説する。
統合ＤＢ機能を適用する範囲（主に自治体内）においてエラーの扱い方について統一したルールが必要になると考えられる。従って、そうしたルールを策定する際に以降に示す解説が一助となれば幸いである。
図 3.2.34、図 3.2.35 に統合 DB 機能の方式毎に想定するエラーの発生箇所を「障№」で示す。表 3.2.9
ではエラー毎に「エラー状態」「統合 DB 機能における扱い」「共通ヘッダにおける扱い」を示す。
「障 1」～「障 6」は、統合 DB 機能の利用 I/F で想定するエラーを示し、統合 DB 機能の方式によらず共通である。表 3.2.A における「障 1」～「障 6」行の「9.業務結果」「10.結果」「11.システムエラー」
列は、アーキテクチャ標準仕様の「4.5.4.10 統合 DB 機能における共通ヘッダの扱い」で規定する利用側応答メッセージ②における共通ヘッダ№9～11 の値を示す。

－ 55 －

地域情報プラットフォームガイドライン「障 10」～「障 15」は、共通インタフェース方式の統合 DB 機能における提供 I/F で想定するエラーを示す。提供 I/F として SQL を採用する場合も対応するエラー状態を検出して利用側にエラーを通知することを推奨する。表 3.2.A における「障 10」～「障 15」行の「9.業務結果」「10.結果」「11.システムエラー」列は、アーキテクチャ標準仕様の「4.5.4.10 統合 DB 機能における共通ヘッダの扱い」
で規定する提供側応答メッセージ④における共通ヘッダ№9～11 の値を示す。
「障 16」～「障 18」は、公開用 DB 方式の統合 DB 機能における提供 I/F で想定するエラーを示す。
公開用 DB 方式の統合 DB 機能における提供 I/F では、共通ヘッダを使用しないので、表 3.2.9 の「9.
業務結果」
「10.結果」「11.システムエラー」列は規定しない。

利用側

提供側

①依頼メッセージ：
依頼
ＸＭＬ

公開用DB方式
統合DB機能提供側
業務ﾕﾆｯﾄ

障３

障２

利用側
業務ﾕﾆｯﾄ
障１

障17
障18

更新

統合ＤＢ
機能の利用

PULL

PUSH型
データ提供機能

障16
障４

障５

障６

応答
ＸＭＬ

Data

②応答メッセージ：
障Ｎは障害の検出場所を示す。

図３．２．３４【利用側のインタフェース仕様】（業務標準仕様のＷＳＤＬで定義）

公開用 DB 方式の統合 DB 機能におけるエラーの発生箇所

利用側

提供側
③依頼メッセージ：
提供側
業務ﾕﾆｯﾄ

依頼ＸＭＬ
障11①依頼メッセージ：

障10

障３

障12
更新

依頼
ＸＭＬ

共通ｲﾝﾀﾌｪｰｽ方式
統合DB機能
問合せ

PULL

障１

障２

統合ＤＢ
機能の利用

PULL

障13

Data

応答
ＸＭＬ

障14

障15

結果

障５

障６

応答
ＸＭＬ

④応答メッセージ：②応答メッセージ：【利用側のインタフェース仕様】（業務標準仕様のＷＳＤＬで定義）

提供側に業務標準仕様のSOAPｲﾝﾀﾌｪｰｽを使用する場合

図３．２．３５

障４

利用側
業務ﾕﾆｯﾄ

共通インタフェース方式の統合 DB 機能におけるエラーの発生箇所－ 56 －

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

表３．２．９
提供側

統合 DB 機能のエラー状態と共通ヘッダにおける扱い（詳細）

№

利用
側

障1

○

利用側業務ユニットの送信ｴﾗｰ

障2○

依頼ﾒｯｾｰｼﾞの通信ｴﾗｰ

関与しない（利用側業務ﾕﾆｯﾄにSOAP-Fault）

障3○

依頼ﾒｯｾｰｼﾞの受付時ｴﾗｰ

障4

○

障5
障6

9:業務
結果

10:
結果

◇⑤統合DB異常◇依頼ﾒｯｾｰｼﾞ異常①検索対象が存在しない(ｱｸｾｽ権無を含む)②該当項目が存在しない(ｱｸｾｽ権無を含む)③検索条件異常

なし

1

5
1
2
3

応答ﾒｯｾｰｼﾞの生成時ｴﾗｰ◇結果が無い◇⑤統合DB異常⑥情報量超過⑦タイムアウト◇④提供側異常

1
なし

0
1

なし
5
6
7
4

○

応答ﾒｯｾｰｼﾞの通信ｴﾗｰ

統合DBにSOAP-Fault（リトライ後にｴﾗｰ処理）

統合DB機能の処理結果○

利用側業務ユニットの受信ｴﾗｰ

関与しない（利用側業務ﾕﾆｯﾄで処理）

統合DB機能の処理結果

エラー状態

統合ＤＢ機能の動作

11:ｼｽﾃﾑｴﾗｰ

関与しない（利用側業務ﾕﾆｯﾄで処理）

次の６項目は共通インタフェース方式のみ（提供側にＳＱＬを使用する場合も該当するエラー状態を検出して利用側にエラー報告する）

障10○

統合DBの依頼ﾒｯｾｰｼﾞ送信ｴﾗｰ

利用側にエラー報告（⑤）

障11○

依頼ﾒｯｾｰｼﾞの通信ｴﾗｰ

統合DBにSOAP-Fault（利用側にｴﾗｰ報告④）

障12○

依頼ﾒｯｾｰｼﾞの受付時ｴﾗｰ

利用側にエラー報告（④）

なし

1

N

障13

○

応答ﾒｯｾｰｼﾞの生成時ｴﾗｰ

利用側にエラー報告（④）

なし

1

N

障14

○

応答ﾒｯｾｰｼﾞの通信ｴﾗｰ

利用側にエラー報告（⑦）タイムアウト

提供側業務ﾕﾆｯﾄの結果

障15○

統合DBの応答ﾒｯｾｰｼﾞ受信ｴﾗｰ

利用側にエラー報告（④）

提供側業務ﾕﾆｯﾄの結果

次の３項目は公開用DB方式のみ

障16○

提供側業務ユニットエラー

利用側にエラー報告（④）

障17○PUSH型データ提供機能エラー

利用側にエラー報告（④）

障18○

統合DB側PUSH更新エラー

利用側にエラー報告（④）

以下では、表 3.2.9 についてエラー状態毎に解説する。
【利用 I/F におけるエラー状態（統合 DB 機能の方式に共通）】「障 1」:

利用側業務ユニットにおいて、利用側依頼メッセージ①を統合 DB 機能に対して送信するまでに発生したエラーであり、利用側業務ユニット内で処理される。統合 DB 機能には依頼メッセージ
が届かないので統合 DB 機能は関与できず、共通ヘッダを有する応答メッセージを返すこともできない。
「障 2」:

利用側業務ユニットから正常に送出された利用側依頼メッセージ①が、統合 DB 機能に到着するまでの間に発生する通信エラーであり、利用側業務ユニットに対して SOAP-Falt が返されるので、利用側業務ユニットがエラーへの対処を行う。統合 DB 機能には依頼メッセージが届かないので統合 DB 機能は関与できず、共通ヘッダを有する応答メッセージを返すこともできない。
「障 3」:

到着した利用側依頼メッセージ①を統合 DB 機能が受信する際に発生するエラーである。統合

DB 機能は発生したエラー毎にアーキテクチャ標準「4.5.4.9

統合 DB 機能のエラー処理」で規定

するエラー状態を利用側応答メッセージ②の共通ヘッダに設定して利用側業務ユニットに送出す－ 57 －

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

る。ここで、「統合 DB 機能の動作」における丸付数字は、共通ヘッダ№11 の値を示す。例えば、利用側依頼メッセージ①で指定された検索対象が存在しない（無効である）場合や、検索対象に対するアクセス権が無い場合には、利用側応答メッセージ②の共通ヘッダ№10 の値として「１」を設定し、№11 の値として「１」を設定し、№9 は存在しない。
「障 4」:

統合 DB 機能が利用側依頼メッセージ①の受付を正常に完了した時点から、利用側応答メッセー
ジ②を生成して、利用側業務ユニットに送出するまでの間に、統合 DB 機能内において発生するエラーである。統合 DB 機能は発生したエラー毎にアーキテクチャ標準「4.5.4.9

統合 DB 機能のエ

ラー処理」で規定するエラー状態を利用側応答メッセージ②の共通ヘッダに設定して利用側業務ユニットに送出する。ここで、「統合 DB 機能の動作」における丸付数字は、共通ヘッダ№11 の値を示す。例えば、提供側業務ユニットの異常によって、正常な結果を返すことができない場合は、「④提供側異常」として、利用側応答メッセージ②の共通ヘッダ№10 の値として「１」を設定し、№11 の値として「４」を設定し、№9 は存在しない。
「障 5」:

統合 DB 機能から正常に送出された利用側応答メッセージ②が、利用側業務ユニットに到着するまでの間に発生する通信エラーであり、統合 DB 機能に対して SOAP-Falt が返される。統合 DB
機能は、リトライなど、可能な復旧策を講じ、異常が解消しない場合は送信をあきらめる他無い。
この場合、利用側業務ユニットには利用側応答メッセージ②は届かないので、利用側業務ユニッ
トはタイムアウトなどにより異常を検出して対処することになる。
「障 6」:

到着した利用側応答メッセージ②を利用側業務ユニットが受信する際に発生する利用側業務ユニット内のエラーであり、利用側業務ユニット内で対処する。統合 DB 機能の役割は終えているので、統合 DB 機能は関与しない。この利用側応答メッセージ②に含まれる共通ヘッダには、統合
DB 機能の処理結果により決まる処理状態が格納されている。
【提供 I/F におけるエラー状態（共通インタフェース方式の統合 DB 機能）】「障 10」:

統合 DB 機能において、提供側依頼メッセージ③を提供側業務ユニットに対して送信するまでに発生したエラーである。統合 DB 機能は、
「障 4」の「⑤統合 DB 異常」として処理する。提供側
業務ユニットは提供側依頼メッセージ③が届かないので、関与できず、提供側応答メッセージ④も返されない。
「障 11」:

統合 DB 機能から正常に送出された提供側依頼メッセージ③が、提供側業務ユニットに到着するまでの間に発生する通信エラーであり、統合 DB 機能に対して SOAP-Falt が返されるので、統合
DB 機能は、「障 4」の「④提供側異常」として処理する。提供側業務ユニットは提供側依頼メッセー
ジ③が届かないので、関与できず、提供側応答メッセージ④も返されない。
「障 12」:

到着した提供側依頼メッセージ③を提供側業務ユニットが受信する際に発生するエラーである。提供側業務ユニットは、共通ヘッダ№10 の値として「１」を設定し、№11 の値として「提供側業務ユニットで規定されたエラー値 N」を設定し、№9 は存在しない状態の提供側応答メッセー
ジ④を統合 DB 機能に送出する。この提供側応答メッセージ④を受信した統合 DB 機能は、「障 4」の「④提供側異常」として処理する。
「障 13」:

提供側業務ユニットが提供側依頼メッセージ③の受付を正常に完了した時点から、提供側応

答メッセージ④を生成して、統合 DB 機能に送出するまでの間に、提供側業務ユニット内において－ 58 －

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

発生するエラーである。提供側業務ユニットは、共通ヘッダ№10 の値として「１」を設定し、№11 の値として「提供側業務ユニットで規定されたエラー値 N」を設定し、№9 は存在しない状態の提供側応答メッセージ④を統合 DB 機能に送出する。この提供側応答メッセージ④を受信した統合 DB 機能は、「障 4」の「④提供側異常」として処理する。
「障 14」:

提供側業務ユニットから正常に送出された提供側応答メッセージ④が、統合 DB 機能に到着するまでの間に発生する通信エラーであり、提供側業務ユニットに対して SOAP-Falt が返される。
統合 DB 機能には提供側応答メッセージ④が届かないので、統合 DB 機能はタイムアウトとして異常を検出し、「障 4」の「⑦タイムアウト」として処理する。
「障 15」:

到着した提供側応答メッセージ④を統合 DB 機能が受信する際に発生する統合 DB 機能内のエラーであり、統合 DB 機能は、
「障 4」の「④提供側異常」として処理する。この提供側応答メッ
セージ④の共通ヘッダには、提供側業務ユニットの処理結果により決まる処理状態が格納されている。
【提供 I/F におけるエラー状態（公開用 DB 方式の統合 DB 機能）】「障 16」:

統合 DB 機能において、提供側業務ユニットのエラーを検出して、正常な値を返すことができない場合には、「障 4」の「④提供側異常」として処理する。
「障 17」:

統合 DB 機能において、利用側業務ユニットからの PUSH 型データ提供機能のエラーを検出して、正常な値を返すことができない場合には、「障 4」の「④提供側異常」として処理する。
「障 18」:

統合 DB 機能において、利用側業務ユニットからの PUSH 型データ提供機能に対する処理でエラーを検出し、正常な値を返すことができない場合には、「障 4」の「④提供側異常」として処理する。

３．２．１０ 統合 DB 機能の運用（バックアップ、リカバリ）
統合 DB 機能の運用に関する留意点について解説する。
特に統合 DB 機能の運用が停止すると、地域情報 PF 全体の業務が継続できなくなるので運用への配慮は重要である。
運用に関する事項は特に採用する製品が持つ機能に依存する部分が多いので、製品の利点や留意点を考慮して検討すべきである。ここでは、統合 DB 機能の方式における一般的な特徴と留意点について解説する。
（１）バックアップ
メタ定義や環境設定類は、構成変更毎に確実なバックアップを取得して復旧可能な状況にすること。
①公開用 DB 方式の統合 DB 機能
公開用 DB 方式の統合 DB 機能は、提供された全ての二次データを物理的に格納して運用されるため、二次データのバックアップについて工夫する必要がある。特に膨大な情報量となる二次データのバックアップと復元の仕組みは、異常時の停止時間を最小化するために重要であり、次の手法がある。
－ 59 －

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

・完全バックアップ＋

差分バックアップ・完全なレプリケーション
また、ディザスタリカバリ（緊急時の復旧対策）として遠隔地にバックアップセンターを設置して、オンラインバックアップを行う手法もある。
②共通インタフェース方式の統合 DB 機能
共通インタフェース方式の統合 DB 機能は、原則として二次データを蓄積管理しないので、
バックアップおよび復旧は、メタ定義や環境ファイルなど少ないデータ量で済む。
（２）負荷分散
各業務ユニットのデータ交換を仲介する統合 DB 機能の性能は、直接全業務ユニットの性能に影響するので、運用時の負荷見積や検証を確実に行い、柔軟な負荷分散によりスケーラブル性を確保すべきである。
①公開用 DB 方式の統合 DB 機能
公開用 DB 方式の統合 DB 機能を単純に負荷分散すると、提供側業務ユニットは分散運用している全ての統合 DB 機能に対してデータの提供を行う必要が生じるため、提供性能への負荷が増大するので工夫が必要である。
対策として次の手法がある。
・担当するデータ（提供側業務ユニット）を区切って複数の統合 DB 機能に分散する。
→この場合利用側は統合 DB 機能を対象データ毎に使い分ける必要があるので、支援機能が必要。
・高性能 DB サーバの採用
・DBMS 自体のレプリケーションや仮想化（クラスタリング）②共通インタフェース方式の統合 DB 機能
共通インタフェース方式の統合 DB 機能は、原則として二次データを蓄積管理しないので、全く同じ動作環境で複数の統合 DB 機能を分散運用することが可能である。
即ち、利用側業務ユニットからの要求に応じて必要な情報源（提供側業務ユニット）にアクセスして動的にデータを取得するので、共通の情報源にアクセスする統合 DB 機能を複数並列に運用し、利用側（または中継機能）がアクセスを振り分けることにより負荷分散を実現する。
（３）冗長運転可用性の確保のため、冗長運転構成は必須である。
なお、統合 DB 機能が運用停止した場合の回避策として、統合 DB 機能を経由しないで直接提供側
業務ユニットにアクセスする手段もある。
①公開用 DB 方式の統合 DB 機能
公開用 DB 方式の統合 DB 機能の冗長運転は、膨大な二次データの管理を行うので、採用している
DBMS の冗長構成により対応することが多い。
②共通インタフェース方式の統合 DB 機能
負荷分散の②で述べたように、共通インタフェース方式の統合 DB 機能は複数の統合 DB サーバを並行運転することが容易であり、この構成は冗長構成としても使用できる。即ち、アクセス中の統
合 DB 機能がエラーを起こした場合は、利用側業務ユニット（または中継する仕組み）が他の稼働中の統合 DB 機能に切り替えることで運用を継続できる。
－ 60 －

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

用語集：
本ガイドラインで使用する統合 DB 機能に関する用語を次表にまとめる。
用語

意味

1

統合 DB 機能業務ユニット間で、データを利用（参照）する仕組みであり、方式として【公開 DB 方式】と【共通インタフェース方式】がある。

2

共通データ

PF 全体で共通に使用するデータ（コード辞書など）

3

業務ユニット4

提供側業務ユニット（提供側）

独立して特定の業務を処理するユニットで、ユニット毎に業務固有のマスタ
DB を持つ統合 DB 機能に対して、自己で管理するデータを提供する役割を持つ業務ユニット

5

利用側業務ユニット（利用側）

統合 DB 機能で公開されているデータを利用する業務ユニット

6

提供 I/F

提供側業務ユニットから統合 DB 機能にデータを提供する機能を持つインタ
フェース

7

利用 I/F

統合 DB 機能を利用側業務ユニットからアクセス機能を持つインタフェース

8

二次データ

9

公開 DB 方式

10

共通インタフェース
方式

11

SQL

12

JDBC

13

ODBC

14

EII

業務ユニットで管理されているマスタデータ（一次データ）に対して、マスタデータの複製またはマスタデータから変換された二次的なデータを二次データと呼ぶ。公開 DB 方式の統合 DB 機能は、提供側業務ユニットから提供された二次データを統合 DB 機能内に保持して利用側に公開する。
物理的な DBMS に公開対象の二次データ（提供側から提供されたデータ）を保持し、この二次データを介してデータの受け渡しを行う仕組みを持つ統合 DB
機能の方式
統合 DB 機能内における二次データの保持を必須とせず、利用側からの要求に応じて、必要なデータを提供側から収集して利用側に回答することにより、利用側から提供側を仮想的に参照する仕組みを持つ統合 DB 機能の方式
Structured Query Language(構造化問合せ言語)の略称。
リレーショナル型データベース用のアクセス言語として、ANSI、ISO、JIS で規格化されている。
Java Database Connectivity の略称。
Java アプリケーションからデータベースにアクセスする機能を持つ API(アプリケーションインタフェース)。
Open DataBase Connectivity の略称。
Microsoft 社により提唱された、アプリケーションからデータベースにアクセ
スするための API。
Enterprise Information Integration の略称。
仮想的な統合を行うことでデータのフォーマットや、保管場所を変える必要がない分散データ管理を実現するデータ管理ソフトウェアの総称であり、フェデレーションと呼ぶこともある。

－ 61 －

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

３．３

BPM 機能本章では、BPM(Business Process Management)機能に関する概要、それを用いたシステムの構築、留意事項について概説する。

３．３．１ BPM 機能とは？
（１） 地域情報プラットフォームにおけるワンストップサービスと BPM の関係
ビジネスプロセスマネージメント(BPM)に関する業界団体の 1 つである、
日本 BPM 協会の定義によれば、ビジネスプロセスマネージメントとは、経営目標を実現させる業務（ビジネスプロセス）を迅速に設計し、その改善サイクルを継続的に進める新しい経営手法と定義され、業務の可視化、デザイン、業務プ
ロセス構築、業務モニタリング、業務実績評価という一連の業務改善サイクルを、ICT(Information andCommunication Technology)を利用し継続的に実施することと定義される。
地域情報プラットフォームでは、このビジネスプロセスマネージメントの考え方を広義概念として取り込み、自治体等を含めた住民サービス業務のあり方について改善するべく、一度の手続きで必要とする作業を全て完了でき、真に利便性に優れた住民サービスを提供できるワンストップサービス、並びに、
このワンストップサービスを実現するプラットフォームの標準の定義を試み、その普及促進を図っている。これにより、地域情報プラットフォームでは広義のビジネスプロセスマネージメントによる種々の
住民サービスの向上を指向すると伴に、副次的効果として公共領域における業務内容の可視化、開かれたガバナンス対応、各種コンプライアンス等も期待できることになる。
上記に基づけば、地域情報プラットフォームで「BPM 機能」という言葉を定義する場合、広義のビジネ
スプロセスマネージメントの定義よりも、むしろ、より限定された狭義の意味で用いられる。それは、前述ビジネスプロセスマネージメントの定義要素である着眼、モデリング、再設計、実装・配置、業務
適用、運用最適化、新たな着眼という一連のビジネスプロセス改善のライフサイクルのうち、再設計されたビジネスプロセスを具現化、自動実行するためのソフトウェア基盤の意味である。つまり地域情報
プラットフォームでは、BPM 機能と称するものはビジネスプロセス管理機能、すなわち自治体内の内部向けサービス、および、自治体間連携サービス、官民間連携サービスの実行を制御する機能であり、業務
サービスインタフェースを組み合わせてビジネスプロセスを組上げ、ワンストップサービスを構築することができるソフトウェア基盤の意味で定義される。
（２） 地域情報プラットフォームにおける BPM 機能に関する要件事項
地域情報プラットフォームの BPM 機能に関連した分野は、ワークフロー(Workflow)、企業アプリケー
ション統合（EAI: Enterprise Application Integration）、企業間ではビジネスプロセス統合(BPI:
Business Process Integration)と発展して来た、ICT 領域の中で比較的長い歴史を持つ分野である。これに従い、一口に BPM 機能と言っても、複数の標準化団体による関連標準案が複数提案されており、複数の実装方法が存在する。例えば、ワークフローに関する国際的な団体である WfMC(Workflow Management
Coalition)が定義する XPDL(XML Process Definition Language)は、従来のワークフローの標準化の流れを受けて定義されているものであり、BPM 機能の一部をも提供し得る。また、国連と OASIS(Organization
for the Advancement of Structured Information Standards)が共同で取り組んだ ebXML(Electronic
Business using eXtensible Markup Language)等でも似た機能として BPSS

(ebXML Business Process

Specification Schema)が定義されている。
地域情報プラットフォームでは、各業務サービスインタフェースを組み合わせてビジネスプロセスを組上げ、より高付加価値で利便性の高いワンストップサービスの実現を、その狙い、要件としている。
このことから、地域情報プラットフォームでは、必要時に必要な形で接続が可能となる疎結合特性を持つ Web サービスの技術を全面的に、そのアーキテクチャに採用している。このため、BPM 機能、並びにプ
ロセス定義のためのスクリプト等は、地域情報プラットフォームのプラットフォーム通信標準仕様の他－ 62 －

地域情報プラットフォームガイドラインの部分と十二分に親和性がある必要がある。そのため、プラットフォーム通信標準仕様のアーキテクチャ
では、SOAP(Simple Object Access Protocol)通信等と親和性が高く、最新版である WS-BPEL(Web Services
Business Process Execution Language 2.0)を全面的に採用している。
（３） BPM 機能の導入効果
BPM 機能を導入して得られる主要な期待効果は、高付加価値で利便性の高いワンストップサービスの導入ができる点にある。その意味で、BPM 機能だけではなく、それを応用した利便性の高いサービスが提供されて始めて狙いとする主要な期待効果が実現されることになる。
しかし ICT の論点で眺めてみると、BPM 機能は通常、XML(Extensible Markup Language)を利用した仕様言語、スクリプト言語により実行される。このため、柔軟性が高く、種々の評価指標に応じてビジネ
スプロセスを発展させるために、これらを変更することは容易にできる。このため、例えば業務ユニット間のデータ連携のため、単純・繰り返しに行なわれる操作プロセスの自動化、不必要な手続きの効率化・省力化、さらに、1 つの自治体内部に於けるビジネスプロセスの改善だけではなく、民間等へのアウ
トソーシング、BPO(Business Process Outsourcing)の実施等を、自治体内のプロセスと同等のインタ
フェースを維持しながら実施できる点で、BPM 機能は大きな副次的導入効果を持つと言える。

３．３．２ BPM 機能の構築手順（１）

地域情報プラットフォームでのビジネスプロセスマネージメントの実施手順と特徴的事項

一般的な民間企業において BPM 機能を導入する手順については、幾つかの文献や、各ベンダが提供するホワイトペーパー等が存在する。例えば、日本 BPM 協会の定義している図３．３．１の様な BPM 推進
フレームワークが該当する。この中では、モデリング(分析)～再設計等の一連のビジネスプロセスマネー
ジメントに関連した方法論も詳細に定義されており、全体の課題解決を網羅的に解決するフレームワー
クとしては概ね妥当なものと言える。
地域情報プラットフォームの展開においても、概ね同等の技術的な考え方を継承しているが、高付加価値・利便性の高いワンストップサービスを個々自治体等の組織体に限らず、全国の自治体、関係団体
で共通的に定義するため、標準的な業務標準、業務インタフェースを定義するという点において、一般の民間企業におけるビジネスプロセスマネージメントの実施手順とは質的に異なる面がある。その差分について図解したものを図３．３．２に記す。

－ 63 －

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

６．新たな着眼

１．モデリング

０．着眼・始動

５．運用

２．再設計

最適化

４．業務運用

３．実装・配備

出典：日本BPM協会 BPMコモンセンスWG

図３．３．１

日本 BPM 協会の提唱する BPM 推進フレームワーク

広義のビジネスプロセスマ
広義のビジネスプロセスマ
ネージメントと関連する範囲
ネージメントと関連する範囲
標準仕様検討運用、サービス品質の監視
各自治体のシステ
ム管理者からの仕様案に対する要請

全国地域情報化推進協会(APPLIC)における(APPLIC)における標準業務モデルの策定に関する作業
標準仕様の
取り込み

公開・展開
ビジネスプロセスの改善・再構築

各ベンダからの提案

各ベンダによる対応
パッケージソフトウェア製品・サービスの開発作業

各自治体での
運用/
運用/行政サービスの改善活動

パッケージソフトウェア製品を用いないシステム構築

適用後、ソフトウエア
差分の取り込み

運用開始

各自治体への個別案件対応作業

製品の適用
製品とのFit & Gap評価

システム構築図３．３．２

地域情報プラットフォームにおけるビジネスプロセスマネージメント

図３．３．２において、一点鎖線で囲まれた部分は、各自治体、関連団体により実施されるモデリン
グ(分析)～再設計等の一連のビジネスプロセスマネージメントに関連した作業に該当する。例えば、「各自治体での運用/行政サービスの改善活動」においては、先の図３．３．１の BPM 推進フレームワークのうち、「０．着眼・始動」「１．モデリング」「４．業務運用」「５．運用最適化」「６．新たな着想」等が－ 64 －

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

相当すると考えられる。これに対して、「各自治体での個別案件対応作業」では、「２．再設計」「３．実装・配備」等が相当すると考えられる。
この図３．３．２で明らかな様に、地域情報プラットフォームでは一般的なビジネスプロセスマネー
ジメントのフレームワークとは大きく２つの点で違いが存在する。一つは「全国地域情報化推進協会(APPLIC)における標準業務モデルの策定に関する作業」であり、他方は「各ベンダによる対応パッケー
ジソフトウェア製品・サービスの開発作業」である。
通常の BPM 推進フレームワークでは個々の自治体、企業内、もしくは特定の関係自治体群、企業群との関係に閉じて実施されることを指向しているのに対して、地域情報プラットフォームでは自治体固有の問題を除外した上で汎用的な標準業務モデルの構築を目指しており、これが従来のフレームワークに基づくアプローチ方法とは異なる点の一つである。
さらに汎用的な標準業務モデルに応じる形で、各ベンダがパッケージソフトウェア製品や、標準的なネットワーク上のサービスを提供する。そしてその製品や提供形態についてもさまざまであり、従来のフレームワークの前提とは異なる点が想像される。
加えてこれらの 2 つの差異に応じる形で、幾つかの付随的な問題も発生してくる。例えば、従来のフレームワークで重点的には討議されていない標準業務モデルの表現形式、モデルライブラリの管理の仕方、モデルライブラリの流通形式、そして各ベンダが提供するパッケージソフトウェア製品や、標準的なネットワーク上のサービスに対する準拠性に関する課題は、利用者が享受する利益を考慮した場合、従来のフレームワークに関する討議と同程度に大きな課題となる。つまり、以上に列挙した事項は、BPM
推進フレームワークが限定的に利用される場合においては課題とはならないが、地域情報プラット
フォームを浸透させるに当ってはインフラストラクチャ化の様相を示すことになる。
以上を踏まえて、次節ではガイドラインに含まれるワンストップサービス連携に関する定義策定手順に基づき作成される生成物のフローの関係を示し、ここで対象としている BPM 機能を導入するための段取り等について概説する。
（２） BPM 機能導入に向けた生成物のフロー
前述の様に、地域情報プラットフォーム における BPM 機能とは、着眼、モデリング、再設計、実装・配置、業務適用、運用最適化、新たな着眼という一連のビジネスプロセス改善のライフサイクルを意味する広義のビジネスプロセスマネージメントではなく、狭義の意味で、再設計されたビジネスプロセスを自動実行するためのソフトウェア基盤を意味する。
図３．３．３は、別に定義されるワンストップサービス連携定義策定手順に基づき作成される生成物のフローの概要を記したものである。地域情報プラットフォーム において、BPM 機能を導入する場合、必要になる定義類はワンストップサービス連携の定義手順の最終工程で作成される生成物となる。そして、図３．３．３上で網掛けされた WS-BPEL 定義(BPM 機能への実装用）部分が、これに相当する。ここでは、前工程から BPMN(Business Process Modeling Notation)の記述や、WS-BPEL(Abstract）の記述が、その入力となる。そして WSDL 定義（BPEL 用）や、XML Schema による定義が、必要に応じて参照されることになる。特に、これらは各案件の詳細設計～実装工程に相当する成果物として提供され、通常は各社の MDA(Model Driven Architecture)ツールの出力として期待されるべきものである。
これに対して、図３．３．３のユニット関連ブロック図や、ワンストップ処理フローは、ワンストッ
プサービス連携の定義手順では前工程に相当し、広義のビジネスプロセスマネージメントに相当する部分とも言える。この前工程の作業の主要部分を実施するに当り、それが図３．３．２の「全国地域情報化推進協会(APPLIC)における標準業務モデルの策定に関する作業」の中で実施するか、各自治体への個別案件対応作業の中で実施されるかは、策定するワンストップサービスの内容に依存する。
但し、どの様な業務標準モデルが定義されたとしても、各自治体への個別案件対応作業の中では、必ず一致と差異の特定を行なう「Fit＆Gap 評価」を実施する必要がある。この為、広範囲に定義・利用されるワンストップサービスの様なもので、全国地域情報化推進協会(APPLIC)における標準業務モデルの－ 65 －

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

策定に関する作業で標準的なものとして策定されたとしても、各自治体への個別案件対応作業の中では必ず、検証が必要になってくる。

ワンストップサービスの定義に基づく生成物のフロー
ワンストップサービスの定義に基づく生成物のフロー

参照リソース
自治体業務アプリケーションユ
ニット標準仕様

ライフイベント・ユニット間関連一覧

業務要件定義業務要件定義作業ステップ
作業ステップ

ユニット関連ブロック図（ワンストップＤＦＤ）・ユニット一覧・項目セット辞書
・コード辞書項目セット辞書

ワンストップ処理フロー（機能関連ブロック図）

ワンストップ
インタフェース定義

コード辞書
XMLデータ型辞書

プラットフォーム通信標準仕様

XML定義作業
XML定義作業
ステップ
ステップ

BPMN
(BP実装仕様）

WSDL定義用
ワークシートXML Schema定義用
ワークシート・XML関連規定
・WSDL関連規定
・WS-BPEL関連規定

項目共通定義WS-BPEL定義(Abstract)

WSDL定義（WS-BPEL用）（ｻｰﾋﾞｽ用）

XML Schema
定義

自治体内の開発工程

WSDLプロファイル
XML変換ルール
XMLデータ型辞書システム最適化計画
要件定義

業務設計
-DFD作成-WFA作成WS-BPEL定義(BPM機能への実装用）

基本設計-WSDL定義-XML Schema定義-BPMN定義

製品依存のアクティビティ
セット定義
開発環境のライブラリ

詳細設計(各社設計ツールを利用)
実装(各社設計ツールを利用)

図３．３．３３．３．３

ワンストップサービスの定義に基づく生成物のフロー概要

BPM 機能の製品選択時の留意点

BPM 機能の製品選定する場合の留意事項は次のとおりである。
（１）

プラットフォーム通信標準仕様の要件を満足するもの

プラットフォーム通信標準仕様では BPM 機能として WS-BPEL の V2.0 を採用している。従って、これを満足する製品でなければならない。
WS-BPEL は、OASIS により国際標準として勧告されたビジネスプロセスを記述するための言語ではあるが、製品間のポータビリティについて、完全に保証している訳ではない。そのため、地域情報プラット
フォームの機能範囲として、WS-BPEL の V2.0 の定義機能のなかで個々の製品が概ね実装・サポートしているアクティビティのセットに限定するように選定している。これは、各種機能のカセッタブルを実現するためであり、結果として、その相互運用性についても概ね保証される。なお、製品選定の際は、WS-BPELの V2.0 をサポートする製品の中でも、その実装範囲をマニュアル等でよく確認する必要がある。
（２）

セキュリティ要件に対して準拠、対応できるもの

地域情報プラットフォームを使い、各種のワンストップサービスを実現する場合、WS-BPEL の処理系の側面のみを注目して製品選定をすることは望ましいとは言えない。プラットフォーム通信標準仕様では、セキュリティに関する規定事項が定められており、選定するべき製品はこれらの事項に対しても準拠す
る、もしくは柔軟に対応できる必要がある。
－ 66 －

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

MDA 等の開発環境と親和性が高く、開発・実行環境が統合化されたもの

前節で説明した様に、地域情報プラットフォーム における BPM 機能を導入する作業は、実際にはワンストップサービス連携の定義手順概要における最終工程に位置付けられる WS-BPEL 定義(BPM 機能への実装用）の生成作業に関連し、広義のビジネスプロセスマネージメントの一連の作業フローの末端に位置付けられる。そして、その前工程では、例えば BPMN 等の計算機可読のモデリング言語・方法論を用いて、モデリング作業が実施される。従って、製品を選択する際には、MDA(Model Driven Architecture)による開発環境、開発ツール等が揃ったもの、もしくはそれに準じて MDA と親和性の高いものを選択するべきである。通常の製品は概ね、対象とするものをグラフィカルに描画し、そのプロパティ等で実際の起動コードを追加する様になっている。そのため、通常の製品では、モデルによる援用の点で効果的なプ
ログラミングが可能であるが、それに加えて完全に MDA 指向のものはビジュアルプログラミングが行なえるため、より効果的なモデリング～プログラミング作業を行なうことができる。
また、上記の様なモデリング言語・方法論については総じて、発展途上の段階にあり、必ずしもマル
チベンダ環境間でのポータビリティの保証が取れている訳ではない。従って開発環境、開発ツールを選定する場合、ベンダが変更になったとしても組織体として統一した開発環境および開発ツールの選定が必要であるとともに、その製品の相互接続性を考慮することも必要である。これは開発環境、開発ツー
ル間だけではなく、開発ツールと WS-BPEL の処理系・実行環境でも同様である。
（４）

サポートが安定して実績のあるもの

SOA(Service Oriented Architecture)、BPM(Business Process Management)の領域は、技術革新のス
ピードが速く、さまざまなベンダがそれぞれ特徴を持った製品を供給している。これに対して、実際のワンストップサービスの定義～再設計作業は比較的長い時間的スパンを要して実施され、発展する。その為、製品・技術とも安定して供給されていないと、継続的な実現することが出来なくなるリスクも存在する。製品を選定する上では、安定してサービス供給がされるものが必要となる。
（５）

システム運用ツールと連携の取れるもの

BPM 機能の実行系で障害等を検知した場合についての対処方法を、プラットフォーム通信標準仕様で規定している。プラットフォーム通信標準では、必要最小限の対処方法を規定しているため、より迅速か
つ詳細な対応を図る場合には、運用管理ツールを導入し、これと連携した障害状況のロギング等により異常検知の強化をおこなうことが望ましい。

３．３．４

留意事項

製品選択時の留意事項以外の BPM 機能に関する留意事項、その他の種々の技術的なポイントを下記に簡単に記す。
（１）

トランザクション、補償動作に関する事項

後続の３．８節、メッセージ交換パターンと異常系処理に関するガイドラインで言及する様に、現在のプラットフォーム通信標準仕様では、トランザクションの処理機能等は特段規定されていない。これは、複数仕様の並立、並びにミドルウェアの普及の点からである。このため、障害が検出された場合の対処を、特別に定めている。BPM 機能を利用する場合、製品によってはトランザクションの処理機能を既に実装しているものも存在する。しかし、ワンストップサービスが複数の組織体に跨って実行される場
合、必ずしもパートナーとなる組織体が採用する BPM 機能が、同等機能を有するとは限らない。従って、メッセージ交換パターン、異常系処理ではプラットフォーム通信標準仕様で定める方式に従う必要が出てくる。
－ 67 －

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

利用できるアクティビティのセットの限定に関する事項

上記（１）と同様な事項として、地域情報プラットフォームの現在のプラットフォーム通信標準仕様
では、WS-BPEL V2.0 の内、利用できるアクティビティのセットを限定している。これは、前述の通り、カセッタブルを指向して製品間のポータビリティを保証するためである。しかし、同時に地域情報プラットフォームの現在のプラットフォーム通信標準仕様では、各製品が独自に提供しているアクティビティ
セット・機能を利用することは禁じていない。これは、実際の BPM 機能の実装においては、独自のアクティビティセットを含んだコーディングが為されることも十二分に想定されることによるものである。
自治体内においては、複数ベンダから BPM 機能を持つ製品を導入する場合、独自のアクティビティセッ
トが WS-BPEL 記述を移植する上で問題となることがある。この様なことから、製品の導入にあたっては
独自アクティビティセットの利用を含めた拡張機能をどこまで利用するか、そのポリシーを統一的に定めておく必要がある。
（３）

地域情報プラットフォームの特有な事項

地域情報プラットフォームでは、ビジネスプロセス実施の依頼元に、そのビジネスプロセスのフロー制御について、規定事項が存在しており、プラットフォーム通信標準仕様の７章である「プラットフォー
ム通信仕様におけるメッセージ共通ヘッダ仕様」にて定義されるメッセージの共通ヘッダ部分にセットされる値に応じて、処理内容を動的に変更する等の規定が存在する。この為、WS-BPEL の記述が、複雑化する傾向がある。
複雑化に対する対処として、通常のプログラミング言語ではモジュール定義、サブルーチン定義による構造化という手段を用いるが、WS-BPEL V2.0 では、この様な概念を直接持たず、サービスの連鎖的な呼出と言う方法を用いて同等のことを実現する。従って、複雑な構造を持つものは、共通ルーチンとしてローカルに配置されるサービス化を行なうことで対処する必要がある。但し、このローカルサービス
化により、処理性能の悪化の可能性も否定出来ない。従って、ローカルサービス化にあたっては、処理性能とのトレードオフを考慮して実装することが必要になる。
（４）モニタリング機能との連携

地域情報プラットフォームでは、モニタリング機能はオプションである。しかしこの機能は、障害発生時の対応等において有効な機能でもある。なお、この機能は、将来、ミドルウェアなどのパッケージ
ソフトウェア製品として調達されることも考えられるが、相当機能をアプリケーションとして作り込むことも可能である。（※その場合は、メッセージ Audit、プロセス Audit と呼ぶものを生成する必要がある。
）BPM 機能において、モニタリング機能と連携するためのインタフェースをサポートし得ることは留意するべき事項である。
（５）「リクエスト・レスポンス型同期型受領 Ack＋非同期型レスポンス」時の対応関係

地域情報プラットフォームで選択可能なメッセージ交換パターンの一つである「リクエスト・レスポ
ンス型同期型受領 Ack＋非同期型レスポンス」時のリクエストの処理とレスポンスの処理を連携させる方
式は、業務ユニットの機能の一部として実装しなければならない。この場合、2 つの対処方法が存在する。
・[方式１]：非同期型レスポンスの応答メッセージの共通ヘッダ内の「RelatedTo」は、リクエストの要求メッセージの共通ヘッダ内の「MsgID」に相当する。従って、業務ユニット側で対応関係を確認する。

・[方式２]：非同期型レスポンスの応答メッセージの共通ヘッダ内の「受付番号」は、リク
エストの要求メッセージの共通ヘッダ内の「受付番号」に一致する。従って、業務ユニット側で対応関係を確認する。
－ 68 －

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

図３．３．４は、要求側の業務ユニットに係わるメッセージ処理を模式化したもので、上記の方式１を記したものである。この場合、点線矢印で対応付けられている様に非同期型レスポンスの応答メッセー
ジの共通ヘッダ内の「RelatedTo」は、リクエストの要求メッセージの共通ヘッダ内の「MsgID」に相当する。従って、要求側業務ユニットでは、これらの対応関係を取る必要がある。
応答側(BPM機能)

要求側業務ユニット

応答側（サービス１）

受付-OUTPUT①値=”00000001N”②タグ省略

受領メッセージ

転入-INPUT①値=”00000002N”②タグ省略①値=”01100003N”②タグ省略

受領メッセージ①値=”01100004N”②タグ省略

転入-OUTPUT①値=”01100005N”②値=”01100003N”

受領メッセージ①値=”01100006N”②タグ省略

応答側(サービス２)
国保資格処理資格取得-INPUT①値=”10300007N”②タグ省略

受領メッセージ①値=”10300008N”②タグ省略

国保資格処理資格取得-OUTPUT①値=”10300009N”②値=”10300007N”

受領メッセージ①値=”10300010N”②タグ省略

通知交付-INPUT①値=”00000011N”②値=“00000001N”

受領メッセージ

凡例：①MsgID ②RelatesTo①値=”00000012N”②タグ省略

図３．３．４（６）

リクエスト処理とレスポンス処理の関係付け

WS-BPEL が受信側となった場合の非同期型の受信タイムアウトの実装方式

プラットフォーム通信標準仕様の４.５節において、WS-BPEL が受信側となった場合、非同期型の受信タイムアウトに関して、WS-BPEL で実装することは規定外である。そのため、呼出元の業務ユニットでタ
イムアウト監視を行なうことを推奨している。
しかし、利用できるアクティビティセット以外のものを用いれば、WS-BPEL で実装することも可能である。必要に応じて検討されたい。
・

WS-BPEL 処理系が pick アクティビティに対応できるものであれは、受信に WS-BPEL のreceive ではなく pick と onMessage, onAlarm を組み合わせて使用することで、非同期メッセージのタイムアウトを WS-BPEL で記述することができる。

・

WS-BPEL 処理系によっては、独自拡張機能によるタイムアウト検知や、ネイティブコード
による受信処理記述が可能なものも存在する。

ただし、これらの方法は地域情報プラットフォームの仕様範囲外であるため、相互接続性は保障されない。このことを考慮して、採用の有無を検討する必要がある。

－ 69 －

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

排他制御に関する留意事項

WS-BPEL から、データの登録/更新/削除の操作を伴うサービスを利用するため、ある業務ユニットを呼び出す場合、その結果に応じて DBMS の同じ表に更新を実施する場合もある。例えば、図３．３．５には、ある WS-BPEL 内部で flow することで、処理を分割した結果、同じ DBMS 上の同じ表に対してサービス呼出を介して更新操作をする事例を記す。WS-BPEL 処理系側では、通常、この様な操作に対して排他制御は業務ユニット内部の責任で実施されることを想定している。その為、WS-BPEL 処理系側はロック等の排他操作を意識せずにサービスの呼出を行なう。
一般には、業務ユニット内部での排他制御の実施を基本とするが、それが困難である場合、WS-BPEL 処
理系側でも特別な対処も考慮しなければならい。その対処方法の一つとして、業務ユニットの起動をシングルトン化し、直列化することも考えられる。但し、この場合、シングルトン起動を保障するため、同じサービスの重複呼出時に、後発のサービス呼出をエラーとして扱われ、障害として検出される可能性も存在する。
より確実化させるには、図３．３．５の例の様に flow を用いる場合、そこから呼び出される Activity
が呼び出すサービスで、更新を伴う場合、同じ操作を呼び出してはならない、もしくは flow についての利用に制限を掛ける等も必要となる。

Receive

Activity B

Activity C
Sequence

Activity A[後発サービス呼出]

WS-BPEL

Activity C
Sequenceflow[先発サービス呼出]排他制御が難しい場合、シングルトン起動化
Updateサービス呼出業務ユニットUpdate Row-1
マスタ表_B

マスタ表_C

ローカル
DB機能

Row-1
排他制御の責任範囲

統合DB機能図３．３．５

排他制御に関する留意事項－ 70 －

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

３．４ セキュリティ
本節では、地域情報 PF に関連するネットワークと関連するセキュリティについて記載する。なお、PF通信機能に関する認証・認可・セキュリティの仕様に関してはガイドライン３．５節を参照のこと。

３．４．１

地域情報 PF に関連するネットワーク

地域情報 PF に関連するネットワークと想定される接続パターンを図３．４．１に示す。

電子申請者（人系）（住民、企業）地域ﾎﾟｰﾀﾙ

地域企業

Webブラウザ

⑪
JPKI
RA&VA

⑨
⑦

⑩

Internet

LGPKI
RA&VA

LGWAN
RA&CA

ローカル
RA&CA

自治体内
基幹系LAN

自治体内
情報系LANLGWAN-ASP

DMZ
周辺 LGWAN

外接系

自治体A

一般商用
一般商用
RA&CA
一般商用
RA&CA
RA&CA

⑧

④

②

③
ＧＷ

①

0

⑤

地域WAN
（広域ネットワーク等）

図書館、病院
公的機関
LGPKI：地方公共団体組織認証基盤
JPKI：公的個人認証サービス

図３．４．１⑥

霞が関ＷＡＮ

自治体B

官庁

LGWAN （総合行政ネットワーク）の解説：http://www.lasdec.nippon-net.ne.jp/lgw/lgwan.htm

地域情報 PF に関連するネットワークと接続パターン－ 71 －

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

以下の表３．４．１にて、図３．４．１のネットワークと接続パターンの解説を行う。

表３．４．１
番号(0)

地域情報 PF に関連するネットワークと想定される接続パターンの整理

接続の当事者

説明

同一 LAN 上の業務ユニット

自治体内の同一 LAN（基幹系 LAN,

内部情報系 LAN）

同士に接続する業務ユニット同士のデータ交換やサービス
連携する場合。

①

基幹系 LAN 上の業務ユニッ

基幹系 LAN と内部情報系 LAN 間の業務ユニット同士のトと内部情報系 LAN 上の業

データ交換やサービス連携の場合。自治体では、住民務ユニット

情報の漏洩の防止策として、基幹系ネットワークと情報系ネットワークを分離している場合がある。自治体のポリシーにより、基幹系 LAN と内部情報系 LAN の接続可否が異なる。

②

自治体内業務ユニットと外自治体がインターネット側の外部接続を行うサーバと部接続向けサーバ

自治体 LAN 側の内部の業務ユニットとの連携の場合。
自治体がインターネット側の外部接続を行うサーバ
は、ファイアウォールで仕切られた干渉エリア（DMZ）
周辺に配置され、自治体 LAN 側の内部の業務ユニットとの連携を行う。自治体のポリシーにより、インターネット側と自治体 LAN 側の接続可否が異なる。

③

自治体同士の外部接続サー

LGWAN を介して自治体の LGWAN 外部接続サーバ同士がバ同士接続する場合、個々の自治体で外部接続サーバを
LGWAN－ASP としての登録が必要。また、LGWAN 側の外部接続サーバは、DMZ 周辺に配置され、自治体 LAN 側の業務ユニットとの連携を行う。自治体のポリシーにより、LGWAN 側と自治体 LAN 側の接続可否が異なる。

④

自治体の外部接続サーバと

LGWAN 上で提供される ASP サービスと、LWGAN 側の外部

LGWAN 上の ASP のサーバ

接続サーバとの間でサービス連携する場合。ASP サー
ビスと外部接続サーバ間の接続と、クライアント―ASP
サービス間接続があり、現在は、自治体の LGWAN 端末
から LGWAN-ASP サービスを使うものが多い。

⑤

自治体の外部接続サーバと自治体の外部接続サーバと官公庁の外部接続サーバ

官公庁の外部接続サーバ

が、LGWAN と霞が関 WAN を経由して接続する。現在は、
GW サーバなどでネットワーク的に分断されていると想定される。

⑥⑦⑧

自治体の外部接続サーバと自治体の地域 WAN 側の外部接続サーバと地域の公共団

地域の公共団体のサーバ

体のサーバがサービス連携する場合。

地域ポータルサーバと自治地域ポータルサーバと自治体のインターネット側の外体サーバ部接続サーバがサービス連携する場合。

地域企業のサーバと自治体

地域企業のインターネット側の外部接続サーバと自治

サーバ

体のインターネット側の外部接続サーバがサービス連携する場合。

⑨

地域ポータルサーバと地域

地域ポータルサーバと地域企業のインターネット側の企業のサーバ

外部接続サーバがサービス連携をする場合。
－ 72 －

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

地域住民の PC と自治体の地域住民の PC と自治体のインターネット側の外部接サービスサーバ

続サーバが接続する場合。自治体の電子申請や情報提供サービス等を受ける。

⑪

地域住民の PC と地域ポータ

地域住民の PC と地域ポータルのインターネット側のルのサービスサーバ

外部接続サーバが接続する場合。自治体や民間の電子申請や情報提供サービスを受ける。

３．４．２

地域情報 PF におけるセキュリティの脅威と対策技術

地域情報 PF に関連するセキュリティ上の課題と対象技術について下記に記述する。

（１）なりすまし （他人に成りすましてのサービスの利用、文書の偽り）（２）否認 （送信の否認、受信の否認、等）（３）通信上の盗聴 （送信データの盗聴）（４）通信上の改ざん （送信データの改ざん、破壊）（５）データへの不正アクセス （データの改ざん、漏洩、削除、追加）（６）システムへの不正侵入 （システム侵入、不正なサービス利用）（７）ウィルス侵入 （感染したビジネス文書やウィルスそのものが侵入）（８）DDoS 攻撃 （多量の送信データを送信してシステム性能劣化）（９）プライバシ情報の不正利用、漏えい
DDoS(Distributed Denial Of Service)攻撃解説 ：http://www.ipa.go.jp/security/fy12/contents/crack/soho/soho/chap1/dos.html（上記は、「情報セキュリティにおける脅威と対応技術の動向」ECOM 資料を参考とした）

自治体等の１つの組織がセキュリティポリシーを定め、管理対象全体のセキュリティを確保するための技術は、既存の PKI 技術や、ファイアウォール等のインターネットの技術として確立されている。
異なるサイト間（自治体間、自治体・民間間等）におけるセキュリティ上の課題を図３．４．２に示す。

－ 73 －

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

サイトＡ（例、Ａ自治体）のＰＦ対応システム
サイトＢ
正式
シス
テム
（正式
使用）

ネット上
の
不正
シス
テム
（不正
使用）

(4）改ざん(3)盗聴（２）
提出の否認、受領の否認、
文書作成の否認(7) ウィルス浸入
正式システムＡ（サービス）
認証・認可
ポリシＸ
正式
システムＢ
（サービス）
認証・認可
ポリシＸ(9)プライバシー
情報の不正利用、漏えい(1)なりすまし
正式システムＣ（サービス）
認証・認可
ポリシＺ(6）システムへの不正侵入(8) DDOS攻撃

図３．４．２(5) システム
データへの不正アクセス(4）改ざん(10)漏洩
(1)なりすまし

正式システム(11) 正式システムの不正使用

異なるサイト間（自治体間、自治体・民間間等）におけるセキュリティ上の課題

異なるサイト間におけるセキュリティ上の課題に対する対策技術を下記に示す。
（a）認証技術・認証（Authentication）技術とは、本人であることを判定し証明する技術である。
（ここでいう本人とは、「クライアントのユーザ」「マシン」「サービス」の抽象的表現）
・対策対象：(1)なりすまし、(6)不正浸入（b）認可技術・認可(Authorization)技術とは、認証されたユーザに対し、システムまたはアプリケーションの使用許可を判定することである。
・対策対象：(3)盗聴、(10)漏洩（c）秘匿性確保技術
・秘匿性確保技術とは、通信の内容を第 3 者が参照できなくする技術である。
・対策対象：(3)盗聴、(10)漏洩（d）電子署名と検証技術
・電子署名と検証技術とは、情報に対し電子的な署名を行い、情報の改ざん検知や署名者の確認を可能にする技術である。
・対策対象：(1)なりすまし、(4)改ざん（e）サービス認証・サービス認可連携技術
・サービス認証・サービス認可連携技術とは、ワンストップ用のサービス認証・サービス認可情報の管理/伝播方法およびそのモデルに関する技術で、シングルサインオンなどが実現できる。
・対策対象：(1)なりすまし、 (5)データの不正アクセス、(6)不正浸入（f）プライバシ情報公開技術
・プライバシ情報公開技術とは、認証・認可の際やサービス処理におけるプライバシ情報の不正利用防止方法・交換許諾方法の技術である。
・対策対象：(9)プライバシ情報の不正利用、(10)漏えい－ 74 －

地域情報プラットフォームガイドライン（g）監査証跡技術
・正式なシステムを不正に使用していないかの情報を統一的に収集し監査したい場合に、使用する技術である。
・対策対象：(11)正式システムの不正使用(h)ウィルス対策技術
・感染したビジネス文書やウィルスそのもの浸入の検知や感染したデータの駆除等の技術である。
・対策対象：(7)ウィルス浸入(i) DDoS 攻撃対策技術
・複数のサイトから特定サイトへの集中アクセスによるシステムダウンやサービス停止の攻撃への対策技術である。負荷集中の監視やネットワーク機器の IP フィルタリング設定等の技術である。
・対策対象：

３．４．３(8)DDOS 攻撃

地域情報 PF に関連する接続パターン別セキュリティ要件

地域情報 PF に関連する接続パターン別セキュリティ要件を下表で整理する。整理の観点は、下記。
・漏洩防止（通信上の盗聴）・認証による対策（なりすまし対策、データの不正アクセス対策、システムの不正侵入）
・署名による対策（文書の改ざん防止、通信上の改ざん防止、否認防止）（なお、ウィルス侵入や、DDoS 攻撃は、地域情報 PF 独自の課題でなく、一般的な課題であり、その対策は、インターネット対策技術として現在使用されているもであるため、整理の観点からはずした）要件に対応した PF 通信機能に関する認証・認可・セキュリティの仕様に関しては、３．５節を参照。

表３．４．２
番号(0)①

地域情報 PF に関連するネットワーク上の接続パターンとセキュリティ要件

接続の当事者
同一 LAN 上の業務ユニット

・漏洩：ローカル LAN なのでシステム全体で考慮

同士

・認証：認証技術

基幹系 LAN 上の業務ユニッ

・漏洩：秘匿性確保技術（SSL(TLS)(以降 TLS 省略)）

トと内部情報系 LAN 上の業

・認証：認証・認可技術（ベーシック認証、

務ユニット
②

セキュリティ要件

SSL クライアント認証、SSL サーバ認証）

自治体内業務ユニットと外・漏洩：秘匿性確保技術（SS）

部接続向けサーバ

・認証：認証・認可技術（ベーシック認証、SSL クライアント認証、SSL サーバ認証）
・署名：電子署名と検証技術（自治体からの外部公文書には署名(LGPKI)）③

自治体同士の外部接続サー・漏洩：秘匿性確保技術（SSL（LGPKI））

バ同士

・認証：認証・認可技術（ベーシック認証、SSL クライアント認証（LGPKI））
・署名：電子署名と検証技術（自治体からの外部公文書には署名(LGPKI)）④

自治体の外部接続サーバと・漏洩：秘匿性確保技術（SSL（LGPKI））

LGWAN 上の ASP のサーバ

・認証：認証・認可技術（ベーシック認証、SSL クラ
イアント認証（LGPKI）、SSL サーバ認証）
・署名：電子署名と検証技術（自治体から外部公文－ 75 －

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

書には署名(LGPKI)）⑤

自治体の外部接続サーバと・漏洩：秘匿性確保技術（SS（LGPKI））

官公庁の外部接続サーバ

・認証：認証・認可技術（SSL クライアント認証（LGPKI））
・署名：電子署名と検証技術（自治体から外部公文書には署名(LGPKI)）⑥

自治体の外部接続サーバと・漏洩：秘匿性確保技術（SSL（LGPKI））

地域の公共団体のサーバ

・認証：認証・認可技術（SSL クライアント認証（LGPKI）、SSL サーバ認証）
・署名：電子署名と検証技術（自治体から外部公文書には署名(LGPKI)）⑦

地域ポータルサーバと自治・漏洩：秘匿性確保技術（SSL（一般商用 CA））

体サーバ

・認証：認証・認可技術（SSL クライアント認証（GPKI、SSL サーバ
認証,一般商用 CA））
・署名：電子署名と検証技術（自治体から外部公文書には署名(LGPKI)、住民からの電子申請には署名（JPKI））⑧

地域企業のサーバと自治体

・漏洩：秘匿性確保技術（SSL（一般商用 CA））

サーバ

・認証：認証・認可技術（SSL クライアント認証、SSL サーバ
認証,（一般商用 CA））
・署名：電子署名と検証技術（自治体から外部公文書には署名(LGPKI) 、住民からの電子申請には署名（JPKI））⑨

地域ポータルサーバと地域

・漏洩：秘匿性確保技術（SSL（一般商用 CA））

企業のサーバ・認証：認証・認可技術（SSL クライアント認証、SSL サーバ
認証,（一般商用 CA）
・署名：電子署名と検証技術（自治体から外部公文書には署名(LGPKI)、住民からの電子申請には署名（JPKI））⑩

地域住民の PC と自治体の・漏洩：秘匿性確保技術（SSL（一般商用 CA））

サービスサーバ

・認証：認証・認可技術（自治体の独自の ID/PW 管理
or SSL クライアント認証、SSL サーバ認証（一般商用 CA））
・署名：電子署名と検証技術（自治体から外部公文書には署名(LGPKI)、住民からの電子申請には署名（JPKI））⑪

地域住民の PC と地域ポータ・漏洩：秘匿性確保技術（SSL（一般商用 CA））

ルのサービスサーバ

・認証：認証・認可技術（地域ポータイル独自の ID/PW
管理、or

SSL クライアント認証、SSL サーバ

認証（一般商用 CA））
・署名：電子署名と検証技術（自治体から外部公文書には署名(LGPKI) 、住民からの電子申請には署名（JPKI））－ 76 －

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

３．４．４

地域情報 PF を実現する上での自治体ネットワークインフラの課題

本節では、自治体内やサイト間のサービス連携を実現する上で、自治体ネットワークに関する課題とその対策を記載する。
平成 18 年度 APPLIC で実施の自治体アンケート（母数 108 自治体）によると、自治体のネットワーク
設置状況は下記であった。
(a)54%の自治体が、基幹系業務ネットワークおよび内部系業務ネットワークを物理的に分離している。
(b)(a)と答えた自治体の内、ほとんどの自治体が、基幹系業務ネットワークおよび内部系業務ネット
ワークは分離しているが、ファイアウォール、VLAN で接続可能としている。
(c)25％の自治体が、ネットワーク分離の条例などを制定している。
(d)97％の自治体が、セキュリティポリシーを策定している。
上記のアンケートを元にした、自治体内やサイト間のサービス連携を実現する上での課題とその対策案を以下に記載する。自治体への PF 導入の際はネットワークポリシを参照し、システム連携の方針を策定する必要がある。
住基ネット

LGWAN
住基ネット

住基ネット

今回の記載範囲

F/W

本庁舎

LGWAN-SS

ＣＳ
F/W

F/W

ＬＧＷＡＮﾈｯﾄﾜｰｸ
Internet
住基ネット 住民

住民基本台帳

介護認定

外国人登録

生活保護

戸籍

戸籍ﾈｯﾄﾜｰｸ

施設管理
高齢者福祉
文書管理

健康管理

軽自動車税
国民健康保険

出先機関（支所・出張所）

図３．４．３

グループウェア

障害者福祉

児童福祉

内
部
情
報
系
ネ
ッ
ト
ワ
ー
ク

専用線

電子申請

財務会計
電子調達

ﾃﾞｰﾀｾﾝﾀ

人事給与
庶務事務
ＭＰＮサーバ

国民年金

専用線

WWW

情報公開

F/W

基
幹
系
ネ
ッ
固定資産税 トワ
個人住民税 ー
ク
法人住民税
印鑑

F/W

介護保険

ＭＰＮ
住基ネット

専用線

現在の自治体のネットワークの構成のイメージ図－ 77 －

地域情報プラットフォームガイドライン（１）LAN が異なる業務ユニット間のデータ交換（業務サービス連携）での課題と対策案【課題】
基幹系ネットワークと内部情報系ネットワークが切り離されている
場合があり、オンラインで業務間の情報を引き渡す方式を検討する必要がある。

住基ネット

LGWAN
住基ネット

①

①

対策案２の例

F/W

本庁舎

ＬＧＷＡＮﾈｯﾄﾜｰｸ
F/W

F/W

基
幹
系
ネ
ッ
業務ユニットＡ トワ
業務ユニットＢ ーク
業務ユニットＣ

戸籍

戸籍ﾈｯﾄﾜｰｸ

内
部
情
報
系
ネ
ッ
ト
ワ
ー
ク

②

①

LGWAN-SSF/W

ＬＧＷＡＮﾈｯﾄﾜｰｸ

①
専用線

電子申請

業務ユニットＦ
電子調達

ﾃﾞｰﾀｾﾝﾀ
戸籍

戸籍ﾈｯﾄﾜｰｸ

業務ユニットＥ

①

ＭＰＮ
住基ネット

専用線

専用線

F/W

Internet
住基ネット 住民

WWW

F/W

業務ユニットＤ

出先機関（支所・出張所）

LGWAN
住基ネット

F/W
ＣＳ

F/W

②

住基ネット

本庁舎

LGWAN-SS

ＣＳ

住基ネット

住基ネット

【対策案１】
調査結果のようにFWやVLANで接続する。
【対策案２】
IPリーチャビリティを遮断したシステム構成で対応する（例：DBサーバの設置）

基
幹
系
ネ
ッ
業務ユニットＡ トワ
業務ユニットＢ ーク
業務ユニットＣ

DB
サーバ

業務ユニットＤ

②

内
部
情
報
系
ネ
ッ
ト
ワ
ー
ク

F/W

F/W

業務ユニットＥ

業務ユニットＦ

基幹系ネットワークと内部情報系ネットワークの中間にDBサーバを設置する。

図３．４．４LAN が異なる業務ユニット間のデータ交換（業務サービス連携）での課題と対策案（２）自治体間連携での課題
現状の自治体業務を前提にした場合、システムが自動的に連携処理を行うようなニーズは少ないと思われるが、今後の新たな自治体間サービス連携として、職員が介在しないで自動的にデータを取り出してくるようなサービス連携も必要になる可能性がある。このようなサービス連携を実現する際は、ネッ
トワークインフラの検討が必要となる。
【課題】
・LGWANと内部情報系ネットワーク及び基幹系ネットワークが接続されていない場合、他自治体への照会等をLGWAN経由で行う際は、その実現方式を検討する必要がある。

LGWAN
住基ネット

LGWAN
住基ネット

①

①

Ｂ市

F/W

本庁舎
F/W

F/W

ＬＧＷＡＮﾈｯﾄﾜｰｸ

情報公開

②
戸籍

文書管理

②

①

専用線

専用線

②

電子申請
電子調達

ﾃﾞｰﾀｾﾝﾀ

戸籍

戸籍ﾈｯﾄﾜｰｸ①
出先機関（支所・出張所）

ＬＧＷＡＮﾈｯﾄﾜｰｸ

情報公開

①

内
部
情
報
系
ネ
ッ
ト
ワ
ー
ク

F/W

Internet
住基ネット 住民

WWW

F/W

戸籍ﾈｯﾄﾜｰｸ

基幹系
ネ
ッ 業務ユニットＡ
ト
ワ
ー
ク

①
LGWAN-SS

ＣＳ

基
幹
系
ネ
ッ
ト
ワ
業務ユニットＢ ー
ク

文書管理

②

専用線

図３．４．５

専用線

電子申請
電子調達

ﾃﾞｰﾀｾﾝﾀ①
出先機関（支所・出張所）

専用線

専用線

②

自治体間連携での課題－ 78 －

Internet
住基ネット 住民

①

内
部
情
報
系
ネ
ッ
ト
ワ
ー
ク

ＭＰＮ
住基ネット

②

①

WWW

F/W

F/W

LGWAN
住基ネット

①
F/W

LGWAN-SS

ＣＳ

F/W

本庁舎

住基ネット

F/W

住基ネット

住基ネット

Ａ市

ＭＰＮ
住基ネット

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

３．４．５

地域情報 PF における自治体の外部接続の実現と検討ポイント

本節では、自治体の外部接続の実現イメージを記載する。自治体の外部接続のネットワークとシステ
ム構成の例を図３．４．６に示す。
外部接続のネットワーク構成例

ＤＭＺ
ﾘﾊﾞｰｽ
ﾌﾟﾛｷｼ

・・・

ｳｲﾙｽ
ﾁｪｯｸ

DMZ
周辺

外部接続系
Ａ．自治体
ｻｰﾋﾞｽ受付

Ｂ．データの
公開受付

Ｃ．受付
ＧＷ

DB等の
GW

・・・

自治体内部
業務
ﾕﾆｯﾄ

図３．４．６

ＢＰＭ

・・・

統合ＤＢ

自治体の外部接続の実現イメージ（ネットワークとシステム構成）

上図の実現例では、

ネットワークのセグメントとして、下記の 3 エリアを想定している。

（１）DMZ（緩衝エリア、外部と内部とが両方アクセスできるエリア）
・ファイアウォール、NAT（アドレス変換）、リバースプロキシ、プロキシ等を設置（２）外部接続エリア（

外部接続サーバを配置）

・外部に公開されるサービスを実施するサーバを配置し、自治体内部とデータ交換する。
（３）自治体内部エリア
・自治体内部のサーバ群（情報系ネットワークと、基幹系ネットワークで分断されている場合
がある）
【対策案】
・自治体内部のサーバと、外部接続サーバとデータ交換するサーバは、IP リーチャビリティを遮断するため、DB や、共有サーバを中継して、外部接続サーバとデータ交換する。また、同様に、自治体内部で、情報系ネットと、基幹系ネットで分断されている場合、DB や、共有サーバを中継してデータ交換を行なう。
汎用受付等システムの構築・運用に関する共通事項(平成 15 年 6 月 6 日改定、共通システム専門部
会了承)を踏まえた、汎用受付システム構築の参考資料(調達編・共同方式の場合

最新 V1.2 版）が、下記に公開されているので参照してください。
（※１）URL：http://www.lasdec.nippon-net.ne.jp/rdd/elg15/02_kouchikuchoutatsu.pdf
現在は削除されています－ 79 －

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

次に、外部接続サーバと外部、自治体内部とのサービス呼び出し関連図を、図３．４．７に示す。なお、この図は、論理的なサービス呼び出し図となっており、物理的にネットワークが分断されている場
合は、データ交換や、サービス呼び出しの中継を行う GW 機能を、両方のネットワークの中間に設置する必要がある。

（①-1） 業務ユニットインタフェース

地域
ポータル

Web
ブラウザ

他サイトの
サービス

（①-2） 統合DBインタフェース（②-1） 業務サービスインタフェース（②-2） BPMインタフェース

（②-3）

（②-3）

（②-3）サイト間インタフェース（③-1）統合DB固有インタフェース

Internet
（②-3）

（②-3）

DMZ
周辺

自治体
ポータル

（②-3）

Ａ．自治体ｻｰﾋﾞｽ受付（サイト間業務サービス）
（②-1）

（②-2）

Ｂ．データの
公開受付

Ｃ．
受付
ＧＷ

Ｃ．
受付
ＧＷ
（②-3）

（②-1）

（②-2）

（②-1）

（②-1）

LGWAN

（②-2）

BPM

BPM

（サイト内業務サービス）

（②-2）

（②-2）

（②-1）

（②-1）

（②-1）

DMZ
周辺

（②-1）

業務ユニット業務ユニット業務ユニット業務ユニット（サイト内業務サービス）（サイト内業務サービス）（サイト内業務サービス）（サイト内業務サービス）

（①-1）
(③-1)
（①-2）

自治体
内部

他の自治体内部

（①-2）

統合DB
Ａ：申請手続きのＧＷ
Ｂ：サイト外にデータを公開する(モニタリング、
統合ＤＢサブセットなど）
Ｃ：外部のサービスからの依頼を汎用的に受付、内部の業務サービス呼び出す

ネットワークが分断されているためゲートウェイの導入が必要

図３．４．７

自治体の外部接続の実現イメージ－ 80 －

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

３．５

PF 共通機能 認証・認可・セキュリティ

本節では、異なるサイト間（自治体間、自治体・民間間等）における認証・認可・セキュリティに関して、ユースケースを想定し説明する。
なお、自治体等の 1 つの組織がセキュリティポリシーを定め、管理対象全体のセキュリティを確保するための技術は、既存の PKI 技術や、ファイアウォール等のインターネットの技術として確立されている。自治体内の、電子申請における申請者の認証、自治体内システムの職員端末とサーバマシン間のセ
キュリティに関しては、既に自治体内で採用されている仕様があり、PF 仕様としては、特に規定してい
ない。

３．５．１

サイト間システム連携におけるユースケースとセキュリティ要件

本節にて、PF に基づくサイト間のシステム連携に影響を与えるセキュリティ要件について、ユースケースを考慮しながら記載する。
（１）地域情報 PF 全体システムにおける電子申請ユースケースとセキュリティ要件
図３．５．１は、地域情報 PF で想定する、申請者、地域ポータル、自治体、連携する自治体、民間のシステム連携のユースケースである。本ケースでは、地域ポータル、自治体、連携する自治体、民間を、
サイトとみなした。
地域ポータル
ポータル
BPM

自宅
インターネット

連携する自治体
地域ポータル管理者

住民
自治体システム
自治体システム（共同センタ or 役所）

企業

受け付け
BPM

ネットワーク

業務
ユニット

受け付け
BPM

企業担当者

業務
ユニット

自治体職員

認証機関
（民間）

自治体職員

認証機関
（国）

民間企業
業務
ユニット

図３．５．１

地域情報 PF で想定するシステムのユースケース例

図３．５．１のユースケースにおいて、主に次の４つの業務処理を想定した。
１）申請者による申請書の送信
２）申請者による進捗状況の問合せ
３）自治体から他自治体への照会－ 81 －

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

４）自治体による公文書の配布
各業務処理のシーケンス図を図３．５．２に示す。

民間
地域
ポータル

申請者

業務
他自治体
ユニット

自治体

① 申請書フォーマット検索・取得

申請書の
送信

② 申請書送信③ 申請書転送④ 進捗状況問合せ⑤ 進捗状況問合せ

進捗状況
問合せ

⑥ 進捗状況通知
⑦ 進捗状況通知
⑧ 照会

他自治体
への照会

⑨ 照会結果⑩ 公文書配布⑪ 交付物取得依頼

公文書の配布⑫交付物送付図３．５．２

地域情報 PF のシステム連携で想定する処理の流れ

上記図で想定するセキュリティ要件について、以下、記載する。

（a-1）データは他の人に読み取れられないようにすること ：（a-2）データの改ざんが検出できること

：

秘匿性確保

改ざん防止、なりすまし防止（a-3）他のサイトからの処理依頼において依頼元を認証できること（a-4）正式システムの不正使用を監査できること：：

なりすまし防止

不正使用（a-5）複数サイトとの間の連携処理に認証や認可処理の一元化が必要な場合、認証認可の連携ができること：

改ざん防止、なりすまし防止（a-6）複数サイトとの間の連携処理に認証や認可処理の一元化が必要な場合、認証のための他サイトへのプライバシ情報公開制御ができること：
プライベート情報の不正利用や漏洩、なりすまし、不正浸入－ 82 －

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

次に、ユースケースの各場面別のセキュリティ要件と対応技術要件を示す。

地域
ポータル

通信路暗号

申請者

通信路暗号

通信路暗号

自治体

業務
他自治体

・申請者の認証・申請書の署名検証① 申請書フォーマット検索・取得

・地域ﾎﾟｰﾀﾙの認証
・申請書の署名検証② 申請書送信・申請文書への署名
・認証情報送付
・申請依頼③ 申請書転送・認証情報の送付
・申請依頼

・申請者の認証・地域ﾎﾟｰﾀﾙの認証④ 進捗状況問合せ・認証情報の送付・進捗問合わせ依頼

申請書の
送信

進捗状況
問合せ

⑤ 進捗状況問合せ・認証情報の送付・進捗問合せ依頼⑥ 進捗状況通知
・照会書類への署名
・認証情報の送付
・照会依頼⑦ 進捗状況通知

・自治体の認証・公文書の自治体署名の検証

・他自治体の認証・照会結果の署名検証⑧ 照会⑨ 照会結果⑩ 公文書配布・他自治体の認証・照会情報の署名検証⑪ 交付物取得依頼・照会結果への署名
・認証情報の送付・照会結果登録依頼⑫交付物送付・認証情報の送付・公文書取得依頼

・申請者の認証・公文書の自治体署名 の検証

図３．５．３

他自治体
への照会
公文書の
配布

・公文書への署名・認証情報の送付
・結果登録依頼

地域情報 PF におけるセキュリティ要件と技術要件

図３．５．３における、各場面別のセキュリティ要件と対策上使用する認証・認可・セキュリティ仕様について表３．５．１にまとめる。

表３．５．１①

地域情報 PF におけるセキュリティ要件と技術要件

ユースケース

セキュリティ要件（A⇒B B の側）採用する PF 仕様

申請書フォーマットの（PF 標準規定の範囲外）（PF 標準規定の範囲外）

申請者⇒

申請者の認証（PF 標準規定の範囲外）

地域ポータルへの申請書の改ざん防止

PF 本人電子署名・検証仕様

申請書の伝送路上の秘匿性確保

PF 秘匿性確保仕様

地域ポータル⇒

地域ポータルサイトの認証

PF サイト認証仕様

自治体（民間）への申請書による申請者の認証

PF 本人電子署名・検証仕様

申請書転送

申請書の改ざん防止

PF 本人電子署名・検証仕様

申請書の伝送路上の秘匿性確保

PF 秘匿性確保仕様

検索と取得
②

申請書送信
③

－ 83 －

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

④

申請者⇒

申請者の認証（PF 標準規定の範囲外）

地域ポータルへの問合せの伝送路上の秘匿性確保

PF 秘匿性確保仕様

地域ポータル⇒

地域ポータルサイトの認証

PF サイト認証仕様

自治体（民間）への進

問合せの伝送路上の秘匿性確保

PF 秘匿性確保仕様

問合せ結果の秘匿性確保

PF 秘匿性確保仕様

地域ポータル⇒

問合せ結果の伝送路上のPF 秘匿性確保仕様

申請者への

秘匿性確保

進捗問合せ（同期）⑤捗問合せ（同期）⑥

自治体（民間）⇒地域ポータルへの進捗状況通知（同期）⑦

進捗状況通知（同期）⑧⑨⑩自治体⇒他の自治体へ

依頼元自治体の認証

PF サイト認証仕様の照会

照会情報の認証

PF 自治体組織電子署名・検証仕様

照会情報の改ざん防止

PF 自治体組織電子署名・検証仕様

照会情報の伝送路上の秘匿性確保

PF 秘匿性確保仕様

他の自治体⇒自治体へ

依頼先自治体の認証

PF サイト認証仕様の照会結果

照会結果の認証

PF 自治体組織電子署名・検証仕様

照会結果の改ざん防止

PF 自治体組織電子署名・検証仕様

照会結果の伝送路上の秘匿性確保

PF 秘匿性確保仕様

自治体⇒

公文書配布元の自治体の認証

PF サイト認証仕様

地域ポータルへの公文書の認証PF 自治体組織電子署名・検証仕様

公文書の改ざん防止

PF 自治体組織電子署名・検証仕様

公文書配布

⑪

公文書の伝送路上の秘匿性確保

PF 秘匿性確保仕様

申請者⇒

申請者の認証（PF 標準規定の範囲外）

地域ポータルへの公文書の伝送路上の秘匿性確保

PF 秘匿性確保仕様

地域ポータル⇒

公文書の認証PF 自治体組織電子署名・検証仕様

申請者への公文書の改ざん防止

PF 自治体組織電子署名・検証仕様

公文書送付(同期)

公文書の伝送路上の秘匿性確保

PF 秘匿性確保仕様

公文書取得依頼(同期)⑫（※）
「（PF 標準規定の範囲外）」：要件に対応するセキュリティ仕様を採用するが、PF の通信に影響しないため、サイト独自に決定して良いことを示す。但し、サービスサイトの申請者や職員の認証の技術自体は、PF 標準の対象外で、既存の認証技術で実施してかまわないが、認証された後、そのサイトから他のサービスサイトへ PF 通信を行なう際、認証された情報を引継ぎ、サービスサ
イトでの認証に使用することがある。このため、サービスサイトの申請者や職員の認証が、正しく、且つ、安全に行なわれる必要がある点に注意が必要である。

－ 84 －

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

３．５．２

自治体職員の認証・認可方式と地域情報 PF との関係

本節では、特に、自治体職員の認証・認可方式と地域情報 PF との関係を記載する。
（１）業務ユニットの職員認証（PF 標準規定の範囲外）
本節では、自治体職員の認証・認可方式と地域情報 PF との関係について記載する。 大別すると
下記の 2 種類の認証方式が採用されている。
（a） 個別業務システム毎のログイン（認証と認可）(b)

Web アプリケーションや統合ソフトウェアによるシングルサインオン（SSO）

現在、認証方式も個別のベンダーソリューションを採用している場合が多い。
地域情報 PF の標準仕様では、特に、自治体内部の職員の認証や SSO に関する規定はない。
（２）サイト間の職責認証の処理方式（提言）
地域情報 PF の標準仕様では、特に、自治体内部の職員の認証や SSO に関する規定はない。今後、自治体間で職員による問合せ型の文書照会型のサービス（自治体間での処理依頼と結果通知）が、職員の職責で実施される場合が想定される。
自治体間問合せは、依頼元自治体内の業務ユニットにて、職員を認証し、起案、承認後、この職員が依頼文書に対し LGPKI で職責署名（PF 自治体組織電子署名・検証仕様）し、他自治体へ依頼文書を送付する。受けた自治体は LGPKI の証明書検証により、依頼元の職責を確認（PF 自治体組織電子署名・検証仕様）し、依頼された照会業務を職員が業務ユニットで実施し、回答文書を作成し返す。
この場合のシステム処理フローについて図３．５．４に示す。
自治体A
認証機能
職員の
認証処理

自治体B
照会依頼受付

業務ユニット

照会文書の
署名検証
照会文書
処理の実施
を受付一覧
へ確認

依頼元の職
責証明書で
照会分文書
に電子署名
照会文書
の自治体へ
の送付

回答文書の
確認

図３．５．４

照会文書の
受付一覧
から選択
照会文書
処理の実施
照会文書
の結果文書
作成

照会結果受付

上長の審査

照会結果
受付
サービス

回答者の
職責証明書
で回答文書
に電子署名

回答文書の
署名検証

回答文書
を依頼自治
体へ送付

依頼文書へ
の回答文書
として登録

サイト間の自治体職員の職責認証の処理方式－ 85 －

認証機能
職員の
認証処理

照会依頼
受付
サービス

照会文書
の作成と
照会状の
審査依頼
上長の審査

自治体A
職員

業務ユニット

自治体B
職員

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

３．５．３

住民の認証・認可方式と地域情報 PF との関係

本節では、公開されている Web サイトへのログイン時に行われる、住民に対する認証・認可の考え方、及びその延長で PF 通信を使用したサービス使用における PF 通信の認証・認可の考え方について記載する。
（１）住民が単一 Web サイトを利用する場合の認証と認可（PF 標準規定の範囲外）
住民がインターネットを使って単一サイト内のサービスをうける場合は、例えば、図３．５．５に示す Web アプリケーションとしての認証・認可の方式で対応する。

IDと認証するための情報（PW等）

サービスサイト※属性の例「名前」「年齢」「e-mail」「住所」「性別」等

認証用リポジトリ
認証確認機能（IDの認証を確認）<ID, PW, 属性>

ﾌﾞﾗｳｻﾞ

人
（
）

認証情報
登録管理
機能

NG（否認）

OK?

OK（クッキーによりセッションを引き継ぐ）
ID、クッキー、
処理依頼

NG（権限がない）
処理実行結果

広義の認証機能

認可機能（処理依頼に対しID者が許可されているかの確認）

認可ポリシ

認可情報
（ACL)
登録管理
機能

<属性.
許可する
サービス>

OK?

広義の認可機能サービス処理１

処理依頼の実行サービス処理２
サービス処理３

図３．５．５Web アプリケーションにおける認証・認可の処理方式（２）住民がポータルを経由して複数 Web サイトを利用する場合の認証と認可
地域情報 PF では、住民が地域ポータルで認証を受け、自治体や民間の地域サービスを使う場合が想定される。
実現方式の 1 つを下図に示す。この方式では、地域ポータルに、PF 通信で接続する自治体等のサービ
スの認証処理のための ID と認証情報（パスワード等）を地域ポータルに登録する必要がある。この実現
方式には、いくつか課題があり、対策については、３．５．７節に示す。

－ 86 －

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

ﾎﾟｰﾀﾙの認証が通ると自治体や民間の問合せ
系のサービスが全て使え、必要な情報が集約され依頼者へ提示。

住民

クライアントﾎﾟｰﾀﾙ独自認証
ﾕｰｻﾞ情報地域ポータル

注意）個別サイトのID/PW
情報をポータルが保持するため、ﾎﾟｰﾀﾙのﾕｰｻ
ﾞ審査やﾕｰｻﾞ情報の管理の責任がある。

PFサイト間認証
個別ID/PW

個別ID/PW

自治体A

自治体B

ﾕｰｻﾞ情報図３．５．６

ﾕｰｻﾞ情報個別ID/PW
民間
ﾕｰｻﾞ情報住民がポータルを経由して複数 Web サイトを利用する場合の認証・認可実現方式例

図３．５．６の地域ポータルと自治体の間は、PF 通信による自治体・民間が公開するサービスの呼び出しとなる。自治体の外接系サーバのサービスを呼び出しする場合の認証・認可処理の例を、図３．５．
７に示す。

認証・認可処理パターン（PF通信の場合）
サービスサイト

PF
AP

通
信
の
ク
ラ
イ
ア
ン
ト
（
ポ
ー
タ
イ
ル
の
等
）

ＰＦサイト認証仕様と処理依頼

認証用リポジトリ
認証確認機能（ＰＦサイト認証 ）

認証情報
登録管理
機能

<ID, PW, 属性>
受領アックにNG設定

OK?
広義の認証機能＜属性、処理依頼＞

受領アックに
NG設定

認可機能（依頼処理に対しID者が許可されているかの確認）

認可ポリシ
<属性.
許可する
サービス>

OK?
処理実行結果のXMLを返す

認可情報
（ACL)
登録管理
機能
広義の認可機能サービス処理１
処理依頼の実行サービス処理２
サービス処理３

図３．５．７

PF 通信における認証・認可の処理方式－ 87 －

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

３．５．４

地域情報ＰＦにおける「認証」機能の導入

図３．５．９に、認証の要件を記載する。地域情報 PF で想定される認証の対象として、「人（Web ブラ
ウザ等の AP 画面を操作する人）（PF 標準規定の範囲外）」「サービス（Web サービス）」
「文書」
「マシン」
が想定される。下図に認証に関する要件の定義例を示す。
次に、上記の認証のユースケースに対する、実現技術を図３．５．８に示す。

区分

技術要件

マ
シ
ン
系

・マシーンからの接続要求の認証⇒
マシン認証

ユースケース

・Ｌ１
ﾏｼﾝ
ﾏｼﾝ

自治体内

民間－自治体自治体－自治体

標準化済み：
・SSL(TLS)認証
・ＨＴＴＰベーシック
認証

標準化済み：
・ SSL(TLS)認証
・ＨＴＴＰベーシック認証

・サーバ認証・クライアント
認証

・自治体内：独自
・自治体間：LGPKI
・民間と自治体：民間

標準化対象：
申請を各ユニット
へ：

標準化対象：
地域ポータルから自治体へ・サービス認証・自治体内：独自
・自治体間：LGPKI
・民間と自治体：民間・WSS（ID/PW)
・独自・WSS（ID/PW)
・WSS+SAML (★)

標準化対象外職員ポータル：

標準化対象外住民が官と民へ：
・SAML (★)
・クッキー（独自）・SSO（ｼﾝｸﾞﾙｻｲﾝｵﾝ)

・自治体内：独自
・自治体間：未整備
・民間と自治体：
未整備

標準化済み：
自治体間：・電子申請形式

・署名検証
・証明書検証・自治体へ申請：JPKI
・自治体間：JPKI
・民間と自治体：(JＰＫＩは使えない、
新しい枠組みが必要）

一般用語

証明書・運用

ﾏｼﾝ

Ｌ１

サ
ー
ビ
ス
系
Ｌ２

Web

系
Ｌ３

・依頼元のサービス
認証⇒
サービス認証

WS
WS

・Ｌ２－２

WS

・人に割付けた
ID/PW or
証明書
でブラウザからのアクセスを認証⇒Webユーザ認証（PF標準規定の範
囲外）

・Ｌ３
Web
人

・クッキー（独自）

ブラウザ使用Web人

AP・データ作成者の
認証
⇒
電文認証

文
書
系

・Ｌ２－１

・Ｌ４－１
署名

Data

検証

・Ｌ４－２

標準化済み：
・電子申請形式

・Ｌ４－３

民間－自治体：×標準化未だ

Data

Ｌ４

（※）

用語の説明：

人 ：申請者や自治体職員等の特定の個人を示し、人がブラウザや電子申請ソフトウェアを使って操作をすることを意味する。
WS ：Web サービスのサービス要求者や Weｂサービス提供者のアプリケーションを示す
Web：Web アプリケーションを示し、人が Web ブラウザで操作する対象アプリケーションを示す。
AP ：Data の署名を検証し、正しい署名のとき、その申請者の権限に基づき、処理を行なうアプリ
ケーションを示す。
(★) 異なる運用組織間での SSO の実現では、IDP（ID プロバイダ）の運営母体の不在が課題

図３．５．８

認証のユースケースと実現技術の関係－ 88 －

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

＃

誰（何）を
（IDの保持者）

IDを何によって認証しIDに何の属性を付与するか？

Ｌ１

マ
シ
ン
系

・サーバ
（レスポンダ側）
・クライアント（リクエスタ側）

・SSLサーバ証明書
・SSLクライアント証明書
・HTTPベーシック認証

マシーンの分類：
・接続許可

Ｌ２

サ
｜
ビ
ス
系

・ＰＦ管理主体を同じくするサービス（ＡＰ）
・ＰＦ管理が異なるサービス（ＡＰ）
・異なるPFのサービス（ＡＰ）

認証連携：
・Ｗｅｂサービスセキュリティ
・ＸＭＬ署名、ＳＡＭＬ 等

同一ＰＦ内：
・認証グループ
異なるＰＦ間：
・管理団体

Ｌ３

W
e
b
系

・一般の人
・職員（事務系）
・職員（システム系）
・民間サービスの人（事務系）
・民間サービスの人（システム
系）

個人認証：
・電子証明書（ＰＫＣＳ＃１２）認証・パスワード認証
・ICカード認証や生体認証
シングルサインオン：・シングルサインオン（SSO)技術

ロール：
・自治体内の住民・システム管理者（自治体）
・業務実施者（自治体）
・システム管理者（民間）・業務実施者（民間）

文
書
系

・申請文書
・起案文書
・交付文書

個人認証：
・電子証明書（ＰＫＣＳ＃１２）認証・ＸＭＬ署名ロール：
・自治体内の住民・システム管理者（自治体）
・業務実施者（自治体）Ｌ４

図３．５．９

認証の要件定義の例（１） L1：マシン系（マシンの２点間の通信）で採用する認証技術（PF サイト認証仕様）
PF サイト認証仕様には、サイト間通信において、サービスのリクエスト側がサービス側の通信先マシン（サイト）を認証するサーバ認証と、サービス側がアクセスしてくるリクエスト側の PF 通信の通信元
マシン（サイト）を認証する SSL クライアント認証とがある。PF 標準書では、PF サイト認証仕様として、
下記の国際標準仕様を採用している。
異なるサイト間での PF 通信では、PF サイト認証仕様は必須であり、サーバ間での通信においてはSSL(TLS)サーバ認証および SSL(TLS)クライアント認証を必須となっている。また、リクエスト側がサーバではなく PC などの場合には SSL(TLS)クライアント認証の代用として HTTP Basic 認証も可能とすしている。
○SSL サーバ認証
SSL(TLS)で暗号通信を実施する場合、必須でサポートされている機能である。
○HTTP Basic 認証
HTTP プロトコルで規定されているベーシック認証。ユーザ毎に、ID とパスワードをサーバ側で設定し、クライアントのアクセス時に指定し認証する方法。
メリット：ほとんどの製品で対応している

デメリット：パスワードによる認証のため、セキュリティ強度が低い。また、パスワード
管理のコストがかかる。
○SSL クライアント認証
SSL(TLS)クライアント認証により、Web サービスクライアントを認証する。SSL(TLS)クライアント
証明書は Web サービスクライアントごとに発行する。
－ 89 －

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

メリット

：

デメリット：

ほとんどの製品で対応している。パスワードに比べセキュリティ強度が高い。
クライアント証明書の配布、管理の方法を検討する必要がある。

（２）L2：サービス通信系で採用するサービス認証技術○サービス通信系の認証技術として、Web サービスセキュリティ（略称：WSS）技術等があるが、必要に応じて、L1,L4 等の技術で代用することが可能。
（３）L3：Web アプリケーション系の SSO で採用する認証技術（PF 標準規定の範囲外）○クッキーによる SSO 技術
HTTP プロトコルの技術あるクッキー機能を使い、ID や認証情報の引継ぎを行う技術
同一ドメイン内の Web サイトで情報の引継ぎが可能。認証そのものには、ID/PW 等が使われる。
○SAML による SSO 技術
国際標準規格である、SAML V2.0 を使用する。普及状況をみて採用の可否を検討する。
（４）L4:データ（文書）の作成者を認証する技術○XML Signature：
メリット：

デメリット：XML Signature を用いてデータに署名をする。
データを SOAP 以外のプロトコルで送信する場合でも適用可能。
署名方法の自由度が高く、相互接続性に懸念がある（各種アルゴリズム、鍵の参照方法、署名タイプなど）。
クライアントに、XML 署名に対応したソフトウェアをインストールする必要がある。

３．５．５「認可」の要件、ユースケース、実現技術（PF 標準規定の範囲外）

本節では、認可についての要件とユースケースを記述する。図３．５．１０が、認可の要件定義の例
である。

許可の要件
IDに対する属性

認可の条件

許可の対象

認可の範囲

申請人

サービス時間内・申請（CRUD）

・同じ自治体内システム管理者（自
治体）

何時でも

・システムモニタ（CRUD）

・同じ自治体内の全システム

業務実施者（自治体） サービス時間内・ビジネスプロセス状態（R） ・同じ自治体内のBP状態のみ

システム管理者（民間）

サービス時間内

・自治体受付システムの状
態（R)・管理対象自治体の受付システム
のみ

業務実施者（民間）サービス時間内・自治体のＸＸ文書（R)・自治体内で正式承認されたもののみ※C（作成）R（参照）U（更新）D（削除）の権限を表す。

図３．５．１０

認可の要件－ 90 －

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

次に、認可のユースケースを図３．５．１１に示す。

ID＋認証情報
認証処理
処理依頼内容IDの属性情報
認可処理

権限無しの場合
処理依頼
ソフトウェア（IDの属性に基づき、処理依頼を許可して 良いかを判定）

エラー
処理１

権限有りの場合

処理２

処理結果

処理３

図３．５．１１

認可のユースケース

上記の認可のユースケースに対し、実現技術との関係を図３．５．１２に示す。認可は個別の技術でなく処理の考え方である。

認可処理
認証処理は、事前にされているものとする。

ＩＤ＋
処理依頼

ID⇒認可情報取得

ＡＣＬ

処理依頼の処理が権限上可能か判定

サービス１又は処理機能１
サービス２又は処理機能２

可能ならサービス
呼び出しサービス３又は処理機能３

ＡＣＬ違反通知か、処理結果を返す

図３．５．１２

認可処理の流れ－ 91 －

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

次に、認可処理に類似した情報フィルタモデルと認可処理モデルとの相違を示す。
（１）認可技術とは・認可（Authorization）とは、認証されたユーザに対し、システム又はアプリケーションの使用許可を判定することである。
・認可技術とは、認可を実現するコンピュータシステム、及び、ソフトウェアの実現技術である。
（２）情報フィルタ技術とは、・ユーザの権限により、情報へのアクセスを抑制したり、情報の内容を抑制する技術

認可処理

ＩＤ＋
処理依頼

ＡＣＬ

ID⇒認可情報取得

処理依頼の処理が権限上可能か判定

ＩＤ＋
処理依頼

サービス１又は処理機能１

参照系モデルの一部で使われる。

ID⇒認可情報取得

属性の大雑把な分類で可能なサービス呼び出し

サービス２又は処理機能２

可能ならサービス
呼び出し

処理結果により権限上提供できない情報を削除

サービス３又は処理機能３

ＡＣＬ違反通知か、処理結果を返す

処理結果を返す

図３．５．１３

３．５．５

情報フィルタ

更新系・参照系モデル
で使われる

ＡＣＬ
サービス１又は処理機能１
サービス２又は処理機能２
サービス３又は処理機能３

認可処理と情報フィルタ処理の違い

秘匿性確保の要件、ユースケース、実現技術

PF 秘匿性確保仕様とは、通信路上のデータの内容を第 3 者から参照させないための仕様である。秘匿性確保のためには、通信路上の 2 点間の秘匿性確保と、End-to-End での秘匿性の確保が必要となる。PF
秘匿性確保仕様ではサイト間における秘匿性確保を対象としていることから、通信路上の 2 点間の秘匿性確保仕様を異なるサイト間では必須としている。
（１） 通信路上の秘匿性の確保
ポータル、自治体、民間の間で、電子申請や公文書等を伝送される場合、データの漏洩を防止するた
め、SSL 及び TLS 通信仕様を、通信路暗号として使用する。

マシン１

マシン１

伝送路上のデータ漏洩のための暗号化
図３．５．１４

通信路上の秘匿性の確保（２） 通信路によりつながった複数中継点を経由した End-To-End での秘匿性の確保
申請データや公文書等の内容に、個人情報や、秘匿性が高い情報がある場合、電子申請や公文書等の全体、または、一部に暗号化を実施し、権限がある確認者のみ内容が見えることが必要である。実現技－ 92 －

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

術としては、XML 暗号仕様や SMIME 仕様がある。
（課題：本要件の実現には、暗号鍵の管理運用と密接であるため、具体的なユースケースを分析し、鍵の運用を含め慎重に導入を検討する必要がある）

Data

暗号 Data

マシン１

複合 Data

マシン２

マシン３

伝送路

伝送路

図３．５．１５

End-To-End での秘匿性の確保（３） 地域情報 PF では、秘匿性確保の技術として、通信路上の秘匿性の確保技術である以下の技術を採用している。
（XML 暗号等の技術は、必要要件がでた場合に検討する。但し、使用においては、
鍵運用の課題の解決が必要である）○SSL(TLS)：
メリット：
デメリット：

SSL(TLS)を使い TCP/IP 層での通信路暗号を行う技術。
通信路暗号として最もよく使われている技術。
通信路のみの暗号のため、中継を含む End-to-End の秘匿性確保には向かない。中継者にて情報が見えてしまう。

３．５．６ 電子署名と検証の要件、ユースケース、実現技術
地域情報 PF における、電子署名と検証の要件、ユースケースについて図３．５．１６に示す。
下図は、ワンストップ申請処理における申請書類形式と署名との関係を示した例である。
なお、電子署名はオプションであり、民間の業務サービスの申請への電子署名については、該当サービスの要件に応じて適用有無を決定する。

電子申請と電子署名
申請者

（申請）

地域ポータル/BPM

業務サービス（Ａ、Ｂ）

自治体BPM

自治体ポータル

SSL
ログイン

ID / PASS

申請書作成

様式ダウンロード

ユーザ認証

自治体内

署名
申請書送付

申請書＋署名
申請データ

A
A
BB

自

CC

民

全

・(全体署名) の署名検証
・証明書検証
申請書＋署名A
A
BB

・(自治体署名) の署名検証
・証明書検証
自

自

申請書

A
A
BB

全

申請書

A
A

申請書

申請書

審査
申請書

BB

審査

C民間業務サービス
申請書

CC

・(民間署名) の署名検証
・証明書検証民

民・申請書審査

図３．５．１６

ワンストップ申請処理における申請書類形式と署名との関係－ 93 －

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

次に、ワンストップ申請処理における申請結果の公文書形式と署名との関係を図３．５．１７に示す。

電子申請と電子署名
申請者（公文書配布）地域ポータル/BPM
SSL
ID / PASS

ログイン

業務サービス（Ａ、Ｂ）

自治体BPM

自治体ポータル

自治体内

ユーザ認証

証明書検証

X
X
審査結果
証明書＋署名自治体の審査結果と証明書の取得依頼

自

Y
Y 自
X
X 自
Y
Y 自

X
X 自
Y
Y 自

結果、証明書＋署名

X
X 自
C民間業務サービス
民

申請書

Y
Y
CC

自
民

・(民間署名) の署名検証
・証明書の自治体署名の検証

自・申請書審査審査結果
民間の審査結果

図３．５．１７

ワンストップ申請処理における申請結果の公文書形式と署名との関係（１） PF 本人電子署名・検証仕様
PF 本人電子署名・検証仕様は、通信路の仕様ではないが、電子申請者が申請する申請書を異なるサイト間で交換する際に使用し、情報の改ざん検知や署名者の検証を可能にする仕様である。電子申請
等、本人が作成したこと、及び、改ざん防止が必要な場合に使用する。本仕様は、オプションである。
電子申請では、なりすましによる申請、データ改ざん、送信否認などのセキュリティ脅威が考えられる。これらの脅威を防ぐに場合には、申請書に電子署名を付与することが有効であり、下記の仕様を選択することを PF 標準で規定している。
・実現する技術として、XML Signature を使用する。
電子申請する本人の端末で、申請データに XML Signature を行ない。XML Signature のある
電子申請を、オンライン申請する。 申請をうけたデータを受信した申請先は、その申請書の XML
Signature 検定を行う。
・住民が自治体用で申請する書類の電子署名は、JPKI を用いた電子署名技術を採用すると規定している。JPKI に関しては、公的個人認証サービスポータルサイト（http://www.jpki.go.jp/）を参照。
（２） PF 自治体組織電子署名・検証仕様
PF 自治体組織電子署名・検証仕様は、通信路の仕様ではないが、自治体が発行する照会書類や公文書書類を、異なるサイト間で交換する際に使用し、情報の改ざん検知や署名者の検証を可能にする仕様である。本仕様は、オプションである。
なお、異なるサイト間で照会書類や公文書を交換する場合、に応じて、下記の仕様を選択することを PF 標準で規定している。
－ 94 －

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

・書類が XML の場合、XML Signature を使用する。
・書類がファイルの場合、PKCS#7、または、XML Signature で署名する。
PKCS#7 の署名の場合は、ファイルと署名データを添付ファイルとして送信する。
PF 自治体組織電子署名・検証仕様として、自治体間の組織認証基盤である「LGPKI」仕様を採用すると規定している。LGPKI に関しては、Web サイト（http://www.lgpki.jp/）を参照。

３．５．７

PF サービス認証の実現技術

PF サービス認証技術は、複数サイトとの間の連携処理にサービス認証処理の一元化が必要な場合に使用する（オプション）。本節では、ワンストップサービス用のサービス認証情報の管理/伝播方法およびそのモデルに関する仕様を説明する。
(1) 対象領域
Web サービスなどを利用したワンストップサービスを実現する場合、一般的な Web アプリケーションとは異なり、必ずしもエンドユーザがサービスの利用者とはならないために、呼び出された側の Web サー
ビスではエンドユーザの認証を必ずしも行うことができないという問題がある。
例えば、エンドユーザが Web ブラウザを用いてポータルにログインを行った後、ポータルが自治体 Aの Web サービスを呼び出す場合を考える。この場合、呼び出された自治体 A の Web サービスで、エンドユーザの認証を行うには、ポータルと自治体 A で同一のユーザ ID を共有してこれを使いまわすといった手段が考えられる。しかし、これを行うには、ポータルとポータルが呼び出す全てのサービスでのユー
ザ ID の共有が必要となり、これを、自治体・民間間のように異なる ID 体系で連携を行う必要がある場
合には適用し難いことが分かる。
(2) ユースケース
以下の図３．５．１８に、自治体と民間におけるサービス認証処理を連携させる場合のユースケースを示す。

－ 95 －

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

ユースケース：入出金情報のマイポータル画面の提供【現行技術】
アカウントアグリゲーションサービス

前提条件：「各サイト別に個別にＩＤ管理されていること」

プライバシ保護型認証連携技術

概要各種サイトのID/PWをアカウントアグリゲーション
各種サイトのID/PWをアカウントアグリゲーション
サービスに登録する。以降、アグリゲーション
サービスに登録する。以降、アグリゲーション
サービスにアクセスするだけで、見たい情報をサービスにアクセスするだけで、見たい情報を一覧表示できる。
一覧表示できる。

各種サイトのID/PW発行した仮IDをIDPに登録し、各種サイトのID/PW発行した仮IDをIDPに登録し、IDP用のIDを発行する（各種サイトで紐付け管理）
IDP用のIDを発行する（各種サイトで紐付け管理）
以降、IDPへアクセスするだけで、見たい情報を
以降、IDPへアクセスするだけで、見たい情報を一覧表示できる
一覧表示できる

効果・利用者でのID・パスワードの管理が簡便・利用者でのID・パスワードの管理が簡便
・見たい情報と一覧表示できる
・見たい情報と一覧表示できる・利用者でのID・パスワードの管理が簡便・利用者でのID・パスワードの管理が簡便
・見たい情報と一覧表示できる
・見たい情報と一覧表示できる・仮IDを使用し、プライバシ情報の漏洩を防止
・仮IDを使用し、プライバシ情報の漏洩を防止

住民
住民
住民
住民

住民
住民

概
念
図

アクセス
アカウントアグリゲーションサービス
アカウントアグリゲーションサービス
各サイトの
ID/PW管理
ID/PW
ログイン

ID/PW
ログイン

金融機関
金融機関

自治体A
自治体A

口座情報等照会

手当等支給状況

各
サ
イ
ト
の
情
報
を
表
示

IDP
IDP

各サイトの情報を表示
地域ポータル
地域ポータル
各サイトのID/PW管理

仮ID
仮ID
仮ID
認証

サイトの情報を 仮ID
提供

金融機関
金融機関

サイトの情報を
提供

自治体A
自治体A

手当等支給状況
口座情報等照会

納付状況

図３．５．１８

ID
認証

ログイン
(ID/PW)

納付状況

プライバシ保護型認証連携技術のユースケース図①アカウントアグリゲーションサービスでのユースケース(ⅰ) 住民がアカウントアグリゲーションサービスへ金融機関、
自治体 A の ID/PW を登録する。
(ⅱ) 住民は、アカウントアグリゲーションサービスへログインを行う。
(ⅲ) アカウントアグリゲーションサービスは、登録されている住民の各サイトの ID/PW を使用して、口座情報の照会や児童手当の支給状況を取得、画面へ表示する。
②プライバシ保護型認証連携技術でのユースケース(ⅰ) 金融機関、自治体 A の ID/PW を住民があらかじめ入手する。
(ⅱ) 住民が金融機関、自治体 A、地域ポータルそれぞれにログインし IDP と連携を行うこと
で仮 ID が IDP から発行される。
(ⅲ) 住民は、地域ポータルにアクセスする際に、IDP から認証を受ける。
(ⅳ) 地域ポータルから、各サイトへアクセス時は、各サイトが IDP から仮 ID を入手することで、住民の識別と、サービスの提供を行う。
(3) 機能概要
以下では、サービス認証連携として、アグリゲーション型認証連携とプライバシ保護型認証連携の２つの方法を記載する。
①サービス認証（アグリゲーション型認証連携）
アグリゲーション型認証連携は、ポータル等のサービスを統合するサイトが、サイトの ID と個別サイトが提供する認証情報を紐付け保持し、サイトの認証後、バックの個々サイトのサービスを呼び出すとき、個別の ID と認証依頼情報でサービスを呼び出す方法である。
－ 96 －

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

図３．５．１９に、アグリゲーション型認証連携のモデルを示す。

使用者（ﾎﾟｰﾀﾙで認証）

クライアント
ポータルID
と認証情報でサービス呼出マイポータル

ﾕｰｻﾞ情報個別のサイトが提供する認証情報を、ポータル等のサービスを統合するサイト
がサイトのIDと紐付け個別に保持し、サイトの認証後、バックの個々サイトのサービスを呼び出しするとき、個別のIDと認証依頼情報でサービス呼び出す

個別のIDと認証情報でサービス呼出
自治体A

自治体B

個別
ﾕｰｻﾞ情報個別
ﾕｰｻﾞ情報図３．５．１９民間
個別
ﾕｰｻﾞ情報アグリゲーション型認証連携②サービス認証（プライバシ保護型認証連携）
プライバシ保護型認証連携は、ID 体系の異なるサイト間のサービス認証において、サービス間で認証情報の交換を可能とする機能（認証連携機能）と、認証情報を統合した場合に、複数サービスで使用されているプライバシ情報の名寄せを防止する機能（名寄せ防止機能）から成る。本機能を実現する標準仕様として、SAML V2.0 を採用する。
(a)認証連携機能
ID 体系の異なる様々なサービスが連携する際に、サービス間でサービス認証情報を交換することによってシングルサインオンを実現する機能である。
(b)名寄せ防止機能
名寄せを防止するには、他のサービスで提供される認証情報の伝播を防ぐ必要があり、例えば認証用の ID とは別の ID を使用するなどで情報の連鎖を切ることが可能になる。
サービス利用者に認証サー
バ内で認証に使用する ID とは異なる仮 ID を発行し、各サービスに割り当てる。認証情報を交換する
際は、認証サーバから連携サービスに割り当てられた仮 ID を受け取り、これを使用する。

－ 97 －

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

使用者（IDPのIDで認証）

連携時に個々のサイトで認証を行った後IDPより仮IDが発行される。
実行時は、IDPで認証を行いIDPから各サイトの仮IDを受け取ることで認証を行うことが出来る。

クライアント
サービス呼び出し

IDPの実ID
で認証依頼

使用者を認証マイポータル仮ID

IDP
ﾕｰｻﾞ情報PFサイト間認証
サービス呼び出し

仮ID

仮ID
自治体A

自治体B

仮ID
民間

ﾕｰｻﾞ情報ﾕｰｻﾞ情報ﾕｰｻﾞ情報図３．５．２０

プライバシ保護型認証連携技術

PF サービス認証（プライバシ保護型認証連携）では、IDP にて認証を行った使用者がサービス呼び出しを行った場合、IDP が使用者の仮 ID を呼び出し先のサービスに応じて提供する。これにより、サービ
ス側では認証連携が可能となる。
ただし、職員が他自治体の住民情報を照会するなどのケースでは、職員がサービス呼び出しを行った
際に、住民の仮 ID を照会先の自治体に応じて変換する仕組みが必要となる。この仕組みを実現する方法の１つとして、ID-WSF が考えられる。ID-WSF については、具体的な業務ユースケースへの適合性、標準化状況、普及の状況を鑑みて、今後採用候補として検討する。
（付録 5 参照）

①認証
②照会要求 ブラ
ウ

③職員の認証トークン＋住民Aの仮ID（XX）⑦照会結果 ザ職員

自治体A

④住民Aの認証トークン（AA）

実ID 仮ID 氏名

X

XX

住民A

IDP
⑤職員の認証トークン＋住民Aの認証トークン（AA）⑥住民情報

実ID 仮ID 氏名
自治体B A

AA

住民A

住民
情報

図３．５．２１

職員による住民情報の照会（ID-WSF による仮 ID 変換イメージ）－ 98 －

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

３．５．８

PF サービス認可の実現技術

PF サービス認可連携仕様とは、複数サイトとの間の連携処理にサービス認可処理の一元化が必要な場合に使用する（オプション）。
本節では、ワンストップサービス用のサービス認可情報の管理/伝播方法およびそのモデル、権限管理
基盤技術に関する仕様を説明する。
(1) 対象領域
従来のシステムでは、アクセス制御機能を実装し、サービス提供者によってサービス利用者のアクセス制御情報（権限情報）の管理は行われている。しかし、その多くは、アプリケーション
毎にアクセス制御機能が実装され、アクセス
住所変更
サービス

制御情報（権限情報）も個別管理されている。

住所変更のアクセス制御ルール

また、アクセス制御に利用するルールもアプ
リケーション毎に固有となっている。

反映操作

このため、サイト内の場合、サービス提供
者は、利用者 ID 情報の登録・削除の操作とと

図書館利用
サービス

もに、ID 情報と個別管理された権限情報の図書館利用のアクセス制御ルール

反映操作

マッピングを手作業で行っている状況にあり、サービス提供者

複数サイトでのサービス連携が実現した場合
反映操作

でも同様の問題は発生する。

介護
サービス

これには、アクセス制御の管理作業に多大

介護のアクセス制御ルール

なコストと時間を要するため、サービス提供者にとって大きな問題となる。
図３．５．２２

サービス提供者の問題点(2) 全体概要とユースケース
ⅰ.全体概要権限管理基盤技術は、異なるサイト間の認可において、複数のアプリケーションで使用されるサービス利用者の権限情報を一元的に管理し、サイトをまたがったサービス利用者に対しても権限情報の整合性を維持する機能である。
ⅱ.ユースケース
図３．５．２３に、自治体間における情報照会処理における認証・認可連携のユースケースを示す。

－ 99 －

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

A自治体

B自治体
IDP（認証）サーバ
PDP(認可）サーバ

業務ユニットA
認証オーソリティ

他自治体情報照会 ID/パスワード① ログイン

利用者情報
リポジトリ

認可オーソリティ

アクセス制御ポリシィ

認証アサーション
認証アサーション＋ 属性オーソリティ② 属性要求情報要求

属性アサーション

PDP(認可）サーバ

③
認可要求

携
連
の
報
情
限
権

認証アサーション＋
属性アサーション

アクセス権限の要求

認可決定応答（許可 or 却下）

認可オーソリティ⑥

認可決定応答（許可 or 却下）

業務ユニットB

アクセス制御ポリシィ

④

他自治体
情報照会

⑤ 照会受付

認証アサーション＋属性アサーション＋業務情報

受付
認可要求

⑦
図３．５．２３

照会

DB

権限管理基盤技術のユースケース① Ａ自治体の業務ユニット A がある申請者の B 自治体での情報を照会したい場合に、他自治体情報照会機能にログインする。
② IDP による認証を受け、認証アサーションと属性アサーションを受け取る。
③ 他自治体情報照会機能は、ログオンした職員が B 自治体にアクセスする権限があるかを PDP に対し問い合わせる④ 職員に権限がある場合は、情報照会に進み、B 自治体の業務ユニット B に対し認証アサーション、
属性アサーション、業務情報（対象の申請者情報等）を送付し、照会依頼をする⑤ B 自治体の業務ユニット B では、情報照会受付機能が④の認証アサーション、属性アサーション、
業務情報を受け取る。
⑥ 情報照会受付機能では、A 自治体から受け取った照会依頼している職員に情報照会の権限があるかを PDP に問い合わせる⑦ 職員に権限がある場合は、対象申請者の情報を A 自治体に送信する。
将来的には、自治体間の所得照会等の業務において、上記のようなユースケースの適用の検討も想定される。
(3) 機能概要
権限管理基盤ではサービス認可の機能を提供するが、その機能は権限情報提供機能と、権限情報同期機能から構成される。
(a) 権限情報提供機能
権限情報提供機能では、アクセス制御ルールを共通化し一元管理する。また、権限管理基盤を提供することにより、共通化したアクセス制御ルールによる判定を可能にする。

－ 100 －

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

権

住所変更
サービス
限

管

図書館利用
サービス
理

PF
サービス
通信

権限管理
基盤

反映操作

アクセス
制御ルール

サービス
提供者

基

介護
サービス
盤

図３．５．２４

権限情報提供技術のイメージ図

権限情報提供機能に関する規定は、プラットフォーム通信標準仕様に記載している。なお、自治体内での権限管理情報の一元管理では、LDAP,RDB 等が使われる。
(b)権限情報同期機能
権限情報同期機能では、「権限情報の連携」および「権限情報の整合性の維持」によりサイト間のアクセス制御ルールの管理および判定を実現する。
ドメインA
業務
サービス
A-1

業務
サービス
A-2

権
限
管
理
基
盤

業務
サービス
B-2

アクセス
制御ルール
(A-1,A-2)

ドメイン間でサービスの相互接続

ドメインB
業務
サービス
B-1

権限管理
基盤

権
限
管
理
基
盤

反映
操作
アクセス制御
管理者

相互接続に
向けた
整合性の維持

権限管理
基盤
アクセス
制御ルール
（B-1,B-2)
アクセス制御管理者

図３．５．２５

権限情報同期技術のイメージ図

権限情報同期機能に関する規定は、プラットフォーム通信標準仕様に記載している。
－ 101 －

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

３．５．９

PF プライバシ情報公開仕様

PF プライバシ情報公開仕様とは、複数サイトとの間の連携に際して認証や認可処理の一元化が必要な場合に使用するプライバシ情報の漏洩防止方法・交換許諾方法に関する仕様である。PF プライバシ情報
公開仕様は、オプションである。
（１）ワンストップサービスにおいて属性のようなプライバシ情報の交換を行う場合の課題
ワンストップサービスにおいて属性のようなプライバシ情報の交換を行う場合に次のような問題が発生する。まず、個人情報保護法遵守の観点からプライバシ情報の交換の際には、エンドユーザへその旨を掲示し、許諾を得る必要があるが、ワンストップサービスにおいて Web サービスを跨る度に許諾の作業を行う必要があるという効率の問題がある。さらに、認証時と同様の問題として、呼び出された側の Web サービスでどのようにエンドユーザから属性交換の許諾を得るかという問題もある。
（２）全体概要とユースケース① 全体概要ⅰ.プライバシ情報公開調整技術
サービスの提供、およびサービスの連携の局面において、サービスの提供者におけるプライバシ情報の利用目的と、サービスの利用者のプライバシ情報の利用許諾意志との間の調整を行い、サービスの利用者の意図したプライバシ情報の公開のみを保証する技術である。
② ユースケース
ⅰ.プライバシ情報公開調整技術
住民A◆ケース１（サービス利用時）

健康推進アプリケーション
健康推進アプリケーション
IDP
IDP

住民Aの実ユーザID
サービス毎の 統計情報収集 災害時医療
開示ポリシ サービス
支援アプリ
属性名
診療情報
検診情報
基本情報

×
○
○

利用許諾
意思ポリシ

住民Aの診療情報
住民Aの健診情報○○○

プライバシ情報
公開調整機能住民Aの基本情報

サービス名・・・統計情報収集サービス
属性名・・・性別、検診情報、診療情報目的・・・住民の健康情報の統計報告

サービス名・・・診療情報問合せサービス
属性名・・・性別、検診情報、診療情報目的・・・災害時の住民への医療支援

属性値の提供：基本情報、検診情報

属性値の提供：基本情報、検診情報、診療情報

関連機関B
関連機関B

病院C
病院C

利用目的ポリシ

利用目的ポリシ(サービスで使用する属性や使用目的)(サービスで使用する属性や使用目的)

プライバシ情報
公開調整機能地域住民の健康状態の統計
結果を国へ報告

図３．５．２６

調整要求

調整要求

回答

回答

統計情報収集サービス

プライバシ情報
公開調整機能
診療情報問合せサービス

住民Aが病院Cで診察を受ける際、診療情報(病歴、薬の投与歴)が入手できる。

プライバシ情報公開調整技術のユースケース図（サービス利用時）－ 102 －

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

住民A

◆ケース２
【前提】住民Aは下記を事前に登録する。
・IDPの実ユーザID
・属性名と属性値
・サービス毎の属性開示ポリシ

アクセス（ログイン）

地域ポータル
地域ポータル
住民Aの実ユーザID
サービス毎の 病院B情報提開示ポリシ 供サービス
属性名
氏名/○○○子
住所/A市××
保険番号/1234

開示可
開示可
開示不可

IDP
IDP
病院C情報提供サービス

病院情報検索サービス

利用許諾
意思ポリシ

開示可
開示可
開示可

プライバシ情報
公開調整機能回
属性値の提供：ポリシ適合しないため提供不可
答

回
答

属性値の提供：○○○子、A市××、1234

サービス名：病院B情報提供サービス
属性名：氏名、住所、保険番号
目的：病院情報検索サービスへ情報提供

調
整
要
求

利用目的ポリシ調
整要求サービス名：病院C情報提供サービス
属性名：氏名、住所、保険番号
目的：病院情報検索サービスへ情報提供

サ
ー
ビ
ス
依
頼

情
報
提
供

サ
ー
ビ
ス
依
頼

市立病院C
市立病院C

プライバシ情報
公開調整機能利用目的ポリシ(サービスで使用する属性や使用目的)

病院C情報提供
サービス

民間病院B
民間病院B
(サービスで使用する属性や使用目的)※地域の病院の情報(専門、診療内容、診療時間、休診日、予防接種受付有無、等)を一括で検索し表示する。

プライバシ情報
公開調整機能情報提供
されない

病院B情報提供
サービス

図３．５．２７

プライバシ情報公開調整技術のユースケース図（３）機能概要（a）利用目的ポリシーの作成機能提供するサービスの内容に応じて、使用するプライバシ情報の内容、およびその利用目的を記述した、サービスの提供者におけるプライバシ情報の利用目的ポリシー(P3P ポリシーと、P3P ポリシー
参照で記述)を作成する機能である。
(b)利用許諾意志ポリシーの作成機能利用するサービスの内容に応じて、利用されるプライバシ情報の内容、およびその利用目的に応じて、許諾の意思を記述した、サービスの利用者におけるプライバシ情報の利用許諾意志ポリシ(P3P
プリファリンスの記述)を作成する機能である。
(c)利用目的ポリシーと利用許諾意志ポリシーの調整機能
プライバシ情報を提供するサイトが、プライバシ情報を利用するサイトから送付された利用目的
ポリシーと、利用許諾意志ポリシー間の調整を行う機能。利用許諾意志ポリシーは、予めプライバ
シ情報を提供するサイトがエンドユーザから取得することもできるが、プライバシ情報を利用するサイトがエンドユーザから取得して送付することもできる。ポリシーが適合すればプライバシ情報をサービス提供者に提供し、ポリシーが適合しない場合にはプライバシ情報を提供しない。
本機能に対する技術仕様としては、ID-WSF が考えられる。ID-WSF については具体的な業務ユース
ケースへの適合性、標準化状況、普及の状況を鑑みて、今後採用候補として検討する。
（付録 5 参照）
（４）規定事項
・プライバシ情報を扱う際のポリシーの記述仕様として、P3P V1.0 の採用をプラットフォーム通信
標準仕様で規定している。
－ 103 －

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

３．５．１０

PF 監査証跡仕様

PF 監査証跡仕様は、個々に点在するセキュリティ監査情報や複数サイト間に跨るセキュリティ監査情報を統一的に管理し、監査する際の基本的な仕様（考え方）について、PF 標準書で規定したものである（オプション）。なお、自治体内等の単一サイト内における監査証跡について本仕様にて規定するものではないとしている。
（１）対象領域
今日、多くの自治体や民間企業で、システムへの不正アクセス等による情報漏えいなどの事件・事故が頻発し、システムのセキュリティ強化とともに、内部・外部監査や法令遵守を前提とした、監査証跡としてシステム上の各種ログなどの証拠保全が必要とされている。
今後、複数サイトでのサービス連携が実現した場合でも同様で、サイト間で連携を図りつつ、情報漏えい等の箇所や原因の特定を行う必要がある。
しかし、現状では、同一サイト内でも、アクセスや操作の記録が保存されてなかったり、保存されも監査証跡として十分な形でなかったり、アプリケーション毎に個別管理されている、などの状況にある。サイト間では、サイト毎にログフォーマットやセキュリティポリシーなどの違いがあり、効率的な監査や情報漏えい等の箇所や原因の特定が困難になると考えられる。
監査証跡取得の目的としては、システム監査とアクセス記録が存在する。
(a)システムに対する不正アクセスや不正利用等を検知するためにシステム管理者が実施する監査（システム監査）(b)自治体が保有する住民情報に対する不正アクセスや不正利用等を検知するために住民本人が実施する監査（アクセス記録）
尚、アクセス記録については、以下の要件が存在する。
自治体間連携におけるアクセス記録を出力できること
自治体間連携で用いる ID により、特定の住民に対するアクセス記録を収集できること
住民が参照可能なのは、自己情報に対するアクセス記録のみとなるよう制御できること（２）全体概要とユースケース① 全体概要
様々なサービスの連携において、サイト内のアプリケーション毎の収集管理を行い、サイト毎に異なるアクセス記録を、サイト間での合意に基づき相互流通させることで監査の効率化を行う。そのための監査証跡収集項目や、監査証跡収集インタフェース（業務アプリケーション向けインタフェース）、
収集サービス機能を提供する。

－ 104 －

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

自治体Ａ(1)住民向けサービスにログイン(6)ログビューアにログイン

ログを送信(2)転出届(7)ログを監査

業務サーバＡ

監査サーバＡ(3)職員向けサービスにログイン(4)申請内容の確認(5)受付処理
利用者か
らの操作
には影響
無し

自治体一般職員

サービス利用者の操作ロ
グは監査サーバに自動的に収集されるシステム管理者

住民(15) 監査ログ交換
(8) 住
民
(9) 転
入

向けサ
ービ

ログを送信
スログ
イン

(13)ログビューアにログイン

業務サーバＢ届

監査サーバB(14)ログを監査

自治体Ｂ(10)職員向けサービスログイン

システム管理者
収集した段階で時系列順になっている
ため時系列に並べ替える作業が不要(11)申請内容および転出の確認(12)転入処理

図３．５．２８

自治体一般職員※図の番号は操作の順番を示しています

監査証跡取得機能の全体概要図② ユースケース
以下に、他自治体情報照会での自治体間におけるユースケースを示す。
(ア) 自治体 A において自治体 B への情報照会処理を実施後、監査の実施または情報漏えい等の問題が発生した場合、自治体 B も含めた一覧の処理における監査ログの収集と解析が必要となる。
(イ) 自治体 A、自治体 B の合意のもと、自治体 A は自治体 B より関連する監査ログを収集する。

－ 105 －

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

自治体B
自治体B

自治体A
自治体A
業務ユニットA

①

ログイン

案件選択

案件一覧表示②

審査画面表示ログイン

サービス利用者(職員)

案件選択

案件一覧表示③

審査画面表示情報照会依頼文送信⑧⑩システム管理者
監査者

情報受信

回答文作成

⑨

ログアウト

監査証跡収集サービス

監査証跡収集サービス

監査ログ
監査証跡管理サービス

監査ログ
監査証跡管理サービス

監査証跡管理API

監査証跡管理API

管理ツール

管理ツール

図３．５．２９

情報検索

回答文送信

ログアウト
回答文

⑦

検索処理

④
サービス利用者
（職員）

依頼文

⑥

査

情報照会依頼文作成

業務ユニットB

情報照会依頼文受信サービス利用者（職員）

審⑤

サービス利用者(職員)

監査証跡取得機能でのユースケース図

以下に、詳細な処理フローを示す。
－自治体 A－① 職員（サービス利用者）は、業務ユニット A へログインする。この時点で監査ログ（ログイン実行）が生成され、これらを監査証跡収集サービスが収集し、監査ログファイルに蓄積する。
② 職員は、審査等の処理を行う。
③ 職員は情報照会のための処理を行う。この時点で監査ログ（アプリケーション機能開始）が生成され、これらを監査証跡収集サービスが収集し監査ログファイルに蓄積する。
④ 職員は、システムログアウトする。この時点で監査ログ（ログアウト実行）が生成され、これらを監査証跡収集サービスが収集し、監査ログファイルに蓄積する。
－自治体Ｂ－⑤ 業務ユニット B は、依頼文を受信する。
⑥ 職員は、業務ユニット B へログインする。この時点で監査ログ（ログイン実行）が生成され、これらを監査証跡収集サービスが収集し監査ログファイルに蓄積する。
⑦ 職員は、情報照会に対する審査、情報照会等の処理を行う。
⑧ 職員は、回答のための処理を行う。この時点で監査ログ（アプリケーション機能開始）が生成され、これらを監査証跡収集サービスが収集し、監査ログファイルに蓄積する。
⑨ 職員は、システムログアウトする。この時点で監査ログ（ログアウト実行）が生成され、これらを監査証跡収集サービスが収集し監査ログファイルに蓄積する。
－自治体Ａ・自治体Ｂ－⑩ 自治体Ａで問題が発生した場合、自治体Ａのシステム管理者（または監査者）は、管理ツールから監査ログの収集処理の起動を行う。
これにより、自治体Ａの監査証跡 API が自治体 A と自治体 B の監査証跡管理サービスから監査ログ－ 106 －

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

を統一形式で収集する。
（３）機能概要
PF 監査証跡仕様は、個々に点在するセキュリティの監査証跡情報や複数サイト間に跨るセキュリ
ティ監査証跡情報を統一的に管理し、監査する際の基本的な仕様（考え方）について規定したものである。
PF 監査証跡仕様に基づき、サイト内の監査情報を外部のサイトに公開するサービスを監査証跡情報提供サービスと呼ぶ。
図３．５．３０に、監査証跡取得機能におけるシステム構成例を示す。
監査情証跡報提供側サイト

システム
管理者

監査証跡情報活用サイト

システム監査：システムに対する
不正アクセスや不正利用等を検知する

監査向け
監
査
ログ
公開用
証
跡 監査証跡情報
情 データ項目
監査向け
報
ログ
提
供
サ
ー
監査向け
ビ 公開用
ログ
ス
監査情報

監査情報
活用
アプリケーション

業務ユニットA
業務ユニットB

業務ユニットC

監査情報提供側サイト
住民

公開用
監査情報
XML形式

アクセス記録：
自己情報に対する
不正アクセスや不正利用等を検知する

図３．５．３０

監査向け
監
査
ログ
公開用
証
監査証跡情報
跡
情
データ項目
監査向け
報
ログ
提
供
サ
ー
ビ 公開用
ス
監査情報

業務ユニットZ
業務ユニットX

監査証跡取得機能のシステム構成例

また監査証跡情報提供サービスに関連するアプリケーションについて表３．５．２に示す。

表３．５．２

監査証跡情報提供サービスに関連するアプリケーション

アプリケーション名

機能概要

業務ユニット

監査対照の監査ログを生成する業務アプリケーション。

監査証跡提供サービス

監査証跡取得機能を実現するサービス。サイト間で公開する公開用監査情報を自治
体内のログから取得蓄積管理し、PF サービス通信での取得依頼に基づき、情報を提供するサービス。

監査情報活用

監査ログの収集サービスにより収集された監査ログを、監査を目的に閲覧や分析するたアプリケーションめのアプリケーション

ヘルスケア分野における関連情報としては、監査ログ生成の契機として、RFC3881 で定義されたイベン
トカテゴリが、また、ヘルスケア分野における監査証跡のメッセージ標準規約が以下の URL にある。
http://www.jahis.jp/standard/seitei/st06-002/st06-002.htm－ 107 －

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

PF としてのサイト間で共有する共通監査情報項目については、今後、サイト間で実施する監査要件を明確化する検討を実施し、その結果に基づき、情報項目を規定していく。
用語辞書
項番

用語

1

認証技術

2

秘匿性確保技術意味
本人であることを判定し証明する技術
対策対象：

データの内容を第 3 者が参照できなくする技術
対策対象：

3

電子署名と検証技術

4

プライバシ情報公開技術

5

監査証跡技術

なりすまし、不正浸入
盗聴、漏洩

電子署名と検証技術とは、情報に対し電子的な署名を行い、情報の改ざん検知や署名者の確認を可能にする技術
対策対象： なりすまし、不正浸入、データの不正アクセス
プライバシ情報公開技術とは、認証・認可におけるプライバシ情報の漏洩防止方法・交換許諾方法の技術
対策対象： プライベート情報の不正利用や漏洩
正式なシステムを不正に使用していないかの情報を統一的に収集し監査したい場合に、使用する技術
対策対象： 正式システムの不正使用

略語
略語

正式名称

DDoS

Distributed Denial of Service

JPKI

Japanese public key infrastructure

LGPKI

Local Government Public Key Infrastructure

LGWAN

Local Government WAN

OASISOrganization for the Advancement of Structured Information Standards

PKI

Public Key Infrastructure

P3P

Platform for Privacy Preferences

SAML

Security Assertion Markup Language

SSL

Secure Socket Layer

SSO

Single Sign-On

TLS

Transport Layer Security

WS-I

Web Services Interoperability Organization

WS-Security

Web Services Security－ 108 －

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

３．６

モニタリング機能

本節では、モニタリング機能に関して下記事項について概説する。
(1)モニタリング機能の実装意義と、Audit 収集の価値(2)モニタリング機能における実装例、その留意事項(3.6.1 節)(3.6.2 節)(3)Audit 群とモニタリング問い合わせインタフェースとの関係(3.6.3 節)

上記(1)では、モニタリング機能の実装意義と、Audit を収集することの価値について説明する。ここで Audit とは、ログの概念を一般化したものである。従来、サービスやシステムリソースのある一時点の状態を示すデータ、スナップショット像、あるいはそれらの集合は、領域毎に呼称が異なり、統一化
されない状況であった。例えばシステムリソースの分野では、“ログ”が一般的であるのに対して、ビジ
ネスプロセスでは“イベントログ”、“AuditTrail”等の語彙が使われる。モニタリング機能はビジネ

スプロセス、サービスという複合的な領域を対象とするため、シノニムとして扱われるこれらに対して統一的な「呼称」「概念」を与える必要がある。そこで、地域情報プラットフォームの仕様では、“ログ”
等を一般化した概念として“Audit”という語彙を導入している。
ビジネスプロセスの改善では、モニタリング機能は大きな役割を持ち得るが、その為には、この Auditの内容に依存する。そこで、Audit の定義、ならびにその品質が高い程、モニタリング機能の価値が高まることについて概説する。
続く(2)では、モニタリング機能の実装例とそのガイドラインについて概説する。モニタリング機能は概して新たな要件に応える機能である。その為、種々の国際標準が出揃わない部分的な機能も、その構成要素に取り込んでおり、仕様事項が抽象化しやすい事情がある。ここでは、実装例を明示することで、より実際の機能イメージについて言及する。
続く(3)では、アーキテクチャ仕様書で定義されるモニタリング問い合わせ通信プロトコルと、奨励す
る Audit 群との関係について説明する。
最後に関連する付録として以下の 2 つの推奨事項を記載すると伴に、マルチベンダ下でモニタリン
グ機能を実装した場合の例も記す。
[付録１]Audit、インタフェースに関する詳細定義
推奨する Audit の形式等の詳細事項について記載する。なお、このガイドラインで定義する
Audit は推奨案に留まっている。本 Audit と等価で別な形式のものがある場合は、本方式以外の実装も許容する。
[付録２]実装コンポーネント構成に関する推奨モデル
実装コンポーネント構成に関する推奨モデルを定義する。モニタリング機能の構成、アーキテ
クチャについては、アーキテクチャ標準仕様に定義があるものの、実装に対する推奨事項はない。ここでは推奨モデルとして記載する。
[付録４]モニタリング機能の実装例
マルチベンダ下でモニタリング機能を実装した場合の例を記す。

３．６．１
（１）

モニタリング機能の意義と、Audit 収集の価値
モニタリング機能の意義

運用のポリシー、アーキテクチャが異なる複数組織間連携の基盤として SOA (Service Oriented
Architecture)が注目を浴びているが、これを要約すると、各組織が利用・保持する機能を外部から利用しやすい形に切り出して、サービスとして定義・提供し、さらには複数のサービスを組み合わせることでシステム間連携を実現するアーキテクチャ、と言うことができる。SOA 化が進展することで、組織をまたがるシステム間の連携を大規模に実現することができ、この結果としてビジネスプロセスと呼ばれる－ 109 －

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

大きなサービス実施、ワンストップサービスの実現が可能になる。
高い潜在力を持つ SOA ではあるが、さらに、より高い価値を提供するためには、その上で進められる
ビジネスプロセスの実施状況・品質をモニタリングでき、サービス選択の幅が広いことも重要になる。
ビジネスプロセスの実施状況・品質をモニタリングすることができれば、その品質を低下させているサー
ビスや、それを実施しているシステムリソースを特定でき、対策を講じることができる。
以上の様なビジネスプロセスを改善するために実施状況・品質を正しく把握しようとする取り組みを「可視化」とも呼ぶ。この「可視化」のためには、組織間に散在し、実施結果を意味する各種情報を Audit
として収集する仕組みが必要になる。モニタリング機能は、散在する情報を Audit として収集する仕組みを提供し、実施状況の把握、進捗管理を通して「可視化」の基盤を提供するものである。
（２）

Audit の定義とその収集・管理の価値

以上の様な意義を持つモニタリング機能ではあるが、その直接的な効果は、複数組織を跨るビジネス
プロセスが実行された場合の、実施状況の把握、進捗管理にある。このため、モニタリング機能は、アー
キテクチャ標準仕様で定義されるように収集された Audit の利用を基礎としている。地域情報プラット
フォームの仕様では、この Audit に、BPM(Business Process Management) Audit、WS アプリケーション
Audit、メッセージ Audit と言うものを定義している。
この Audit は、事象が発生した段階で発生するものであるから、これを収集し、解析することでサービス、ビジネスプロセスの種々の特性、KPI (Key Performance Indicator)を把握することが可能である。
そして、これが、本来の目的であるビジネスプロセスの改善に関連し得る。
以上から、Audit 収集の密度が高く、その品質が高いほど、モニタリング機能をより高次な段階まで利用することが出来、結果としてビジネスプロセスの改善を促すことができる様になる。現在の Audit に関する仕様は、斯様な要求を見通して、その内容を詳細に定義している。

３．６．２
（１）

モニタリング機能の実装例とその留意事項
モニタリング機能の実装例

自治体、民間会社、地域ポータル等の横断的なサービスを事例とした場合のモニタリング機能の実装例について模式化したものを図３．６．１に記す。図３．６．１は、地域情報プラットフォームのアー
キテクチャ標準仕様に記されたものをより、実装に近い形で記した図である。各組織間のセキュリティ
ポリシー等の違いのため、ファイアウォール装置、ルータ装置、LGWAN(総合行政ネットワーク)等を含めて明記するべきであるが、図３．６．１はモニタリング機能の実装・配置に力点を置いているため、省略している。
モニタリング機能は、各要素が分散的に配置されるが、その中心となる監視アプリケーションに関しては、大きくは四つ配置されている。1 つはポータルサイト、もしくは集中管理センターに配置されるべき監視アプリケーション、監視クライアントである。これは、当該モニタリング機能の通常利用を想定している。これに対して、他の 3 つは、地域ポータル、自治体 A、民間企業等の各々に配置される Audit
Proxy や監視アプリケーションである。これは、当該モニタリング機能の拡張利用時を想定しており、各々の組織体内、もしくは組織体からのプロセス監視、サービス監視を行なう。
地域ポータル、自治体 A、自治体 B、民間企業の各々に配置される BPM 機能、業務ユニット等はマルチベンダ条件下で調達されるため、各 Audit 提供機能、その変換機能はそれぞれ、Audit のガイドラインに適合しつつも調達機器に適合する形で実装される。例えば、BPM Audit 提供は、図３．６．１の自治体 Aの様に BPM 機能のサーバに組み込まれる場合もあるが、専用のアダプタ装置が置かれる場合もある。また、メッセージ Audit を取得するに当たっては専用の収集モジュールを配した装置が置かれる場合がある。また、これらの Audit 機能に関する国際標準化も、今後、検討が進むと予想されるため、このガイ－ 110 －

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

ドラインでは、Audit 提供の配置について実際の運用条件に柔軟に対応するため、緩やかな構成を推奨する。
また、このガイドラインでは Audit の形式についても推奨案を定義しているが、これも実際の運用条
件に柔軟に対応するため、緩やかな定義を前提とする。このため、付録４に見られる様に XML によるメッセージング、ソケット通信等のものを許容している。これらの対応策として、以上の様な柔軟性を確保する為に、そのインタフェースを運用の段階で必要に応じて公開する等の処置が必要となる。
監視アプリケーションと Audit Proxy 間の通信プロトコルについては、アーキテクチャ標準仕様に基づき、実装され、その問い合わせは受付番号等を用いて為される。アーキテクチャ標準仕様においては、十分な柔軟性を許容している。アーキテクチャ標準仕様では、監視アプリケーションと Audit Proxy 間の通信プロトコルについて、
プラットフォーム通信標準仕様である SOAP(Simple Object Access Protocol)を許容しているが、限定的に利用可能な場合、プラットフォーム通信標準仕様との相互連携を前提の上で他方式も利用可能とする。例えば、付録４の場合、WSDM(Web Services Distributed Management V1.1)を利用している。
ポータルサイト

監視クライアント

BPM機能

統合化Audit

付録1-(5)

監視アプリケーション

3.6.3-(1),付録1-(2)

自治体A

民間企業

DMZ

Audit Proxy

統合化Audit

BPM Audit

Message Audit

自治体
ポータル

3.6.3-(2)Audit Proxy DMZ
業務ユニット付録1-(6)

自治体B

BPM Audit提供

BPM機能

ログファイル等 変換 BPM Audit

Audit Proxy

DMZ

BPM呼出し他
Message Audit提供

付録1-(3)
業務ユニットSOAPメッセージ 変換 Message Audit

監視アプリケーション
付録1-(4)
業務ユニット

監視クライアント

図３．６．１ モニタリング機能の実装模式図

モニタリング機能では、アーキテクチャ標準仕様で定義されるように、モニタリング問い合わせイン
タフェース、監視クライアントインタフェース、BPM・WS アプリケーション Audit 提供インタフェース、
メッセージ Audit 提供インタフェースの４つが存在する。この図３．６．１では、監視クライアントイ
ンタフェース以外の 3 つについて、網掛け・番号付けて定義している。例えば、モニタリング問い合わせインタフェースについては、3.6.3 節(1)、並びに付録 1－(2)に、その詳細な説明を記す。なお、マル
チベンダ下でモニタリング機能を実装した場合の事例を付録４に記す。

－ 111 －

地域情報プラットフォームガイドライン（２）モニタリング機能実装における留意事項

本節では、モニタリング機能を実装する上での留意事項を記す。
・ このガイドラインが執筆された段階で、モニタリング対象に関する情報モデル等で、国際的な標準類が策定されていない状況にある。しかし、いずれはこの分野で国際標準化が進むのは確実と考えられる。その為、各 Audit 提供等ではインタフェースの構成を柔軟にし、変換モジュール等の組込みが柔軟にできる設計が求められる。付録４の実装例でもその様な方式を採用している。
・ モニタリング機能のアーキテクチャ標準仕様に基づき、監視アプリケーション等のアーキテクチャについては規定していない。その為、監視アプリケーションの配置位置を柔軟に選択・構成できるが、より広域にモニタリングを実現する上で、Audit Proxy 等との密結合な実装は推奨しない。
・ 監視クライアントと監視アプリケーション間のインタフェースについても、仕様事項としては規定
しない。

３．６．３
（１）

Audit 群とモニタリング問い合わせインタフェースとの関係
モニタリング問い合わせインタフェースと Audit 取得モデルの関係

Audit 取得モデルとは、Audit Proxy が各種 Audit 提供から Audit を入手する方式についてモデル化したものである。図３．６．２は、モニタリング機能が採用する Audit 取得モデルについて、概要と位置付けを記したものである。この図ではアーキテクチャ標準仕様書に規定されているモニタリング問い合
わせインタフェースとの関係も記される。
モニタリング問い合わせインタフェースと Audit 取得モデルは、基本的に階層を成し、一体化している訳ではない。これに従い、実行タイミングも異なっている。モニタリング問い合わせインタフェース
によるクエリが、システム運用管理者からの要求がきっかけで、送信される可能性が高いのに対して、
Audit 取得モデルは、それに追随するとは限らない。詳細は、次節にて説明する。
Audit Proxy が、必要とする Audit (BPM Audit ないし WS アプリケーション Audit)を取得する方法としては、大きく 2 つの方法が考えられる。一方は、Audit 提供から Audit Proxy へ一方的に送付するプッシュ方式であり、他方は Audit Proxy が必要とする Audit を Audit 提供に要求し、取得するクエリ－レ
スポンス方式である。適時性の点ではプッシュ方式のほうが有利であるが、ネットワークに必要以上に負荷を掛けない様にすることを配慮して、クエリ－レスポンス方式を奨励する。
このため、BPM Audit 提供から BPM Audit を取得するためのインタフェースとしてクエリ形式が用意されている。これに基づき実装されている場合は、BPM Audit 提供に対し、取得したい BPM Audit を特定するクエリを送信することで、該当する BPM Audit を収集できることになる。同様に WS アプリケーション
Audit 提供から WS アプリケーション Audit を取得するためのインタフェースとしてもクエリ形式が用意されている。これに基づき実装されている場合は、WS アプリケーション Audit 提供に対し、取得したい
WS アプリケーション Audit を特定するクエリを送信することで、該当する WS アプリケーション Audit を収集できることになる。
BPM Audit 提供および WS アプリケーション Audit 提供は、BPM 機能を実装した WS-BPEL(Web Services
Business Process Execution Language 2.0)処理系、および WS アプリケーションのそれぞれ複数のもの
から実行状態に関する情報を取得し、Audit を生成する。そこで各 Audit 提供は、それが担当する WS-BPEL
処理系、WS アプリケーションから取得した Audit のインスタンスにシーケンス番号(sequenceNo)を付与
し、一時的に管理する。このシーケンス番号は各 WS-BPEL 処理系、WS アプリケーション毎に独立して採番する値で、例えば Audit の発生時刻基づき昇順に値を採番しても良い。奨励するクエリ形式が具体的に定義されており、BPM Audit 提供から BPM Audit を取得するクエリ形式、WS アプリケーション Audit
提供から WS アプリケーション Audit を取得するクエリ形式は、同じ様な形式を用いる。付録１にて推奨する形式を記す。
－ 112 －

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

監視アプリケーション(プロセス監視)アーキテクチャ標準仕様にて規定：XMLメッセージ、

モニタリング問い合わせIF
モニタリング問い合わせIF

クエリ

レスポンス

問い合わせの情報項目を規定し、WSDLは個々で実装・開示。

Audit取得モデルの規定範囲

Audit Proxy
クエリ (引数：シーケンス番号など)

クエリ (引数：シーケンス番号など)
クエリ
レスポンス (Audit)
シーケンス
番号を付与

レスポンス (Audit)

BPM Audit提供
BPM Auditの元データ

レスポンス (Audit)

Message
Audit提供

WSアプリケーション
Audit提供

流通するMessage

WSアプリケーション
Auditの元データ

BPM
BPM機能

シーケンス
番号を付与

WSアプリケーション
WSアプリケーション

図３．６．２ Audit 取得モデルの構成とモニタリング問い合わせインタフェースとの関係（２）

モニタリング問い合わせインタフェースと Audit 取得モデルの論理的な関係

図３．６．３は、Audit 取得モデルにて実行されるクエリ－レスポンスの XML メッセージと、モニタリ
ング問い合わせインタフェースで流通する XML メッセージの関係を記した図である。前述の様にモニタ
リング問い合わせインタフェースと Audit 取得モデルは階層を成し、一体化している訳ではない為、実行されるタイミングも異なる。ここでは、Audit Proxy の実装方式までは言及しないが、この実行タイミ
ングのずれから、Audit Proxy には、適宜起動する問い合わせモジュール相当のもの、Audit 取得モジュール相当のものが必要となる。
Audit 取得モジュールは、Audit 取得モデルを実現するものであり、定期的もしくは、それに準じた条
件で関連する Audit データを全ての Audit を収集し、Audit Proxy 内に保持する。これに対して問い合わ
せモジュールは、モニタリング問い合わせインタフェースに応じて、クエリを処理し、収集済みの全ての Audit から該当するものを選定し、モニタリング問い合わせインタフェースのレスポンス形式に変換する。

－ 113 －

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

監視アプリケーション(プロセス監視)<XMLMsg><!--モニタリング問い合わせIF(クエリ)-- ><受付番号>
ABC12345</受付番号></XMLMsg><XMLMsg><!--モニタリング問い合わせIF(レスポンス) -- ><受付番号>ABC12345</受付番号><処理状態>終了[ABC100]</処理状態>･･･</XMLMsg>

Audit Proxy<XMLMsg><!--モニタリング問い合わせIF(クエリ)-- ><受付番号>
ABC12345</受付番号></XMLMsg>

問い合わせモジュール

問い合わせモジュールは、監視ア
プリケーションから、クエリを受けると事前に保持しているAudit群を検索し、同じ受付番号を持つ
ものをXMLメッセージで応答する。

受付番号が同じもの対象<auditQuery><!—Audit (クエリ) -- >････</auditQuery>

BPM Audit提供
Audit提供

Audit取得モジュール
Audit取得モジュール
BPMAuditから進捗情報を得てマッピング<MessageAudit><MessageAudit><BPMAudit><!—Message Audit (結果) -- ><MessageAudit><!—Message<!—BPM Audit (結果) -- ><Message> Audit (結果) -- ><!—Message<Message> Audit (結果) -- ><status>ABC100<status><messageid><Message><messageid><BPELActivityInstance>
ABC500<messageid>
ABC500<Message></messageid>
ABC500</messageid><messageid><messageContents></messageid><messageContents>
ABC500・・・・・
メッセージID <messageContents>
・・・・・</messageid><受領メッセージ>
・・・・・で対応付ける<受領メッセージ></Message><システム制御情報><受領メッセージ><システム制御情報></BPELActivityInstance><受付番号><共通ヘッダ><受付番号></BPMAudit>
ABC12345<受付番号>
業務メッセージ
ABC12345</受付番号>
ABC12345</受付番号>(圧縮+Base64</システム制御情報></受付番号></システム制御情報></受領メッセージ></共通ヘッダ>
エンコード)</受領メッセージ>
・・・・・</受領メッセージ>
・・・・・</messageContents>
・・・・・</messageContents></Message></messageContents></Message></
MessageAudit ></Message></
MessageAudit ></ MessageAudit >Msg Audit提供
Audit提供
BPM Audit提供
Audit提供
Msg Audit提供
Audit提供

Audit取得モジュールが、定期的に
Audit類を収集し、Audit Proxyに保持する。

図３．６．３ Audit とモニタリング問い合わせインタフェースの論理的な関係

続いて、処理の概要について説明する。モニタリング問い合わせインタフェースの WSDL(Web Services
Description Language)については事前に公開されているが、Audit Proxy 毎に異なることも想定している。そこで、監視アプリケーションは、問い合わせ対象の Audit Proxy 毎に受付番号に関する指定値を記載した XML メッセージを準備する。その後、監視アプリケーションから当該 XML メッセージを各 Audit
Proxy に送付する。
任意の Audit Proxy が XML メッセージを受理すると、この XML メッセージに記載される受付番号に関する指定値を取り出す。その後、この値を用いて該当する Audit を検索する。図３．６．３の様に、Message
Audit が存在する場合、受付番号は、Message Audit に含まれる圧縮、Base64 エンコーディングされた業
務メッセージ内のシステム制御情報のヘッダの一部として含まれている。従って、流通する業務メッセー
ジ全てに対応する Message Audit を対象として、該当するものを検索する。検索の結果、ある一連のMessage Audit 群を入手した場合は、
今度は BPM Audit を検索する。その際、Message Audit 並びに BPM Auditで記載される messageid を連携のキーにすることで、該当する BPM Audit を全て見つけることができる。
Message Audit が存在しない場合、受付番号を含むデータを BPM Audit や WS アプリケーション Audit に変数(Variable)として含め、Variable から受付番号を取り出すことも可能である。
検索された該当 BPM Audit には、BPM 機能の実行状態を意味する status 情報が記載されている。そこ
で、この status 情報をビジネスプロセス上の状態に対応させることで、モニタリング問い合わせインタ
フェースのレスポンスを作成することができる。前述の様に、モニタリング問い合わせインタフェースの WSDL については事前に公開されているが、Audit Proxy 毎に異なることも許容している。そして、事前公開される WSDL には、前述 status 情報とビジネスプロセス上の状態対応が事前に定義されることが求められる。このため、状態の意味に関する調整は監視アプリケーション側で事前に行なわれていることが必要である。このため、各 Audit Proxy に定義している XML メッセージ形式で、前述レスポンス相－ 114 －

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

当の XML メッセージを作成することが可能となる。
（３）

ビジネスプロセスの進捗管理手順

最後に、モニタリング機能が実現するビジネスプロセスの進捗管理を実施する手順の一例について、ステップを追って概説する。ここでは、オプションである Message Audit(メッセージ Audit)が存在する
場合を考える。従って、Message Audit(メッセージ Audit)が存在しない場合は、それに相当する手順で実装することも可能である。
ステップは大きく 3 つの部分から構成される。[ステップ 01] [ステップ 02]は、Audit が発生する度に、適宜実施される。これに対して、[ステップ 10]以後は、システム運用管理者からの明示的な起動要求があって、初めて実施される。これは、前述の通り、モニタリング問い合わせインタフェースと Audit 取
得モデルが一体化している訳ではなく、さらに監視アプリケーションでは、システム運用管理者からの明示的な起動要求が無ければ、特に動作は発生しないためである。
[ステップ 01]：全ての Audit Proxy において、Message Audit(メッセージ Audit)、BPM
宜受信する。モニタリング機能を実装する限りにおいて、BPM

Audit を適

Audit は必ず生成し、

Message Audit(メッセージ Audit)は状況に応じては、生成されない場合も存在する。
[ステップ 02]：受信された Audit は、後の利活用のために、適切な形で管理される。特に、Message
Audit(メッセージ Audit)が生成される場合、後に指定「受付番号」を持つ Message
Audit(メッセージ Audit)が検索される。この「受付番号」は Message Audit(メッセー
ジ Audit)に含まれる圧縮、Base64 エンコーディングされている業務メッセージ内のシステム制御情報のヘッダに一部として含まれているので、Message Audit(メッセージ
Audit)を受信し、管理する段階で、Base64 デコーディング、解凍等を事前に実施しておき、検索時に利用する「受付番号」の文字列と伴に、Message Audit(メッセージ Audit)を管理する等の事前処置を行なう。
（但し、奨励）[ステップ 10]：監視アプリケーションを起動する場合、システム運用管理者は監視クライアントを介して、進捗管理の対象となるビジネスプロセスが持つ「受付番号」を指定する。
[ステップ 11]：続けて、監視アプリケーションは、問い合わせ対象の Audit Proxy 毎に定義されるモ
ニタリング問い合わせインタフェースの WSDL に応じて、問い合わせの XML メッセージを準備する。
[ステップ 12]：監視アプリケーションから当該 XML メッセージを各 Audit Proxy に順次送付する。ここで、監視アプリケーションは対象とする Audit Proxy 全てに、この処理を実施する
ため、上記[ステップ 11]と本[ステップ 12]を繰り返し実施する。
[ステップ 13]：ある Audit Proxy が XML メッセージを受理すると、この XML メッセージに記載される「受付番号」に関する指定値を取り出す。
[ステップ 14]：続けて、この Audit Proxy が内部に管理し、流通する業務メッセージ全てに対応する
Message Audit(メッセージ Audit)群を対象として、先の「受付番号」を持つ Message
Audit(メッセージ Audit)を検索する。受付番号は Message Audit(メッセージ Audit)に含まれる圧縮、Base64 エンコーディングされている業務メッセージ内のシステム制
御情報のヘッダに一部として含まれている。従って、検索の段階で Base64 デコーディ
ング、解凍等を行なう、もしくは、事前に取り出した「受付番号」を用いて検索を行
なう。MessageAudit(メッセージ Audit)自身は、オプションとなっているため、何等かの理由により Audit が生成されない場合もあり、全てが取り扱われるとは限らない
ことを考慮する必要がある。
－ 115 －

地域情報プラットフォームガイドライン[ステップ 15]：該当する Message Audit(メッセージ Audit)を検索した後、Audit Proxy では、BPM Audit
を検索する。その際、Message Audit(メッセージ Audit)並びに BPM Audit で記載される messageid を連携のキーにすることで、該当する BPM Audit が見つける。なお、BPM
Audit 自身は、指定必須となっているが、messageid が指定選択となっているため、該当する BPM Audit の全て検索出来ない場合も考慮する必要がある。
[ステップ 16]：検索された BPM Audit 上では、BPM 機能の実行状態を意味する status 情報が記載されている。そのため、この status 情報をビジネスプロセス上の状態に対応させることで、モニタリング問い合わせインタフェースのレスポンスである XML メッセージが作成される。
[ステップ 17]：その後、モニタリング問い合わせインタフェースのレスポンスである XML メッセージ
は、要求元の監視アプリケーションに送信される。
[ステップ 18]：送信元の監視アプリケーションは、当該 XML メッセージを受信する。モニタリング問
い合わせインタフェースの WSDL については事前に公開されおり、Audit Proxy 毎に異なることも許容している。そこで、監視アプリケーションは、当該 XML メッセージをチェックし、当該 XML メッセージで符号化されている前述 status 情報を、監視アプリ
ケーション自身で定義するビジネスプロセス上の状態に対応付ける。
[ステップ 19]：送信元の監視アプリケーションが、全てのモニタリング問い合わせインタフェースのレスポンスである XML メッセージを自身すると、監視クライアントを介して進捗状況
について、システム運用管理者に表示できる様に、指定された画面作成処理を行う。

－ 116 －

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

３．７

PF 共通機能（ユーティリティ機能）

本節では、PF 共通機能における、「ユーティリティ機能」について、その位置付けや機能概要についての技術解説を示す。PF 共通機能におけるユーティリティ機能とは、データ交換、サービス連携、プロセス連携などを実現する地域情報 PF の開発、実行、運用に関連し、横断的に使用される下記の機能を集めたものであり、アーキテクチャ標準仕様４．５．３プラットフォーム共通機能に規定されている。
(1) 時刻同期機能(2) サービスレジストリ機能(3) リポジトリ機能(4) 統合レジストリ機能(5) ビジネスメッセージルーティング-ゲートウェイ（BMR-GW）機能

３．７．１ 時刻同期機能
地域情報 PF 標準を採用し動作するサーバ等のマシンの「時刻同期機能」を実施する機能である。
（１）時刻同期機能を必要とする条件
a.マシン間の時刻が一致していることを前提にしている機能がある。
モニタリング機能、監査証跡機能、等
b.問題発生時のトラブルシューティング時に各マシン間の時刻を踏まえたログなどから責任切り分けなどを実施する必要があるため。
（２）時刻同期機能とシステム例
時刻同期の方法と運用上の時刻同期処理に関しては、NTP サーバと NTP クライアントの設置と設定に関する定義が、アーキテクチャ標準仕様の４．５．３．３

ユーティリティ機能に記載されているので参照ください。図３．７．１に、階層的に配置した NTP サーバと NTP クライアントのシス
テム例を示す。サイト内の業務ユニットや BPM 機能や統合 DB 機能等のサーバマシンが、NTP クライ
アントとなる。NTP クライアントは、マシンが起動された段階で、サイト内の NTP サーバにアクセ
スし、時刻同期を行う。
インターネット
NTP
サーバ
サービス

NTP
サイト内

NTP
サイト内
NTP
サーバ

NTP

図３．７．１

サイト内
NTP
クライアント

サイト内
NTP
クライアント

時刻同期の実装例－ 117 －

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

３．７．２

サービスレジストリ機能

サービスレジストリ機能とは、サービス情報を管理する蓄積庫である。サービス情報のライフサイクル（登録、更新、削除）を管理し、これら登録されたサービス情報の検索できるサービスを提供する機能である。各種 Web サービスの登録・検索・公開するケース、もしくは対象者の情報を持つサイトのサービスを検索するケースがある。また前者のケースには動的にサービス先を探す UDDI 等を使用する場合と、サービス情報を Web サイト等で公開する静的な方法がある。詳細な定義は、アーキテクチャ
標準仕様の４．５．３．３

ユーティリティ機能に規定されている。

地域情報 PF によるサービスレジストリ機能のユースケースを下記に示す。
ア）ユースケース１：

PF 標準仕様に基づく各種 Web サービスの登録・検索・公開

管理者：各種サービスを提供するコミュニティの主体者（地域ポータル運営者、など）
使用者：登録された各種 Web サービスを利用し、地域サービスなどを提供する主体者
要件 ：管理者が管理・登録する Web サービス（自治体や民間等）のカタログ情報を使用者が検索、ダウンロードできる。
イ）ユースケース２：

対象者の情報を持つサイトのサービスを検索する場合

管理者：自治体の Web サービスと ID 情報の紐づけ情報の管理者
使用者：住民の情報を取得する自治体職員もしくは住民
要件 ：住民（ID 情報）と紐づいた Web サービス（自治体や民間等）を使用者が検索できる。
自治体の Web サービスのライフサイクルを管理（登録、変更、削除）できる。
自治体の Web サービスと住民（ID 情報）の紐付け情報のライフサイクルを管理（登録、変更、削除）できる。
本ユースケースに対する技術仕様として、ID-WSF が考えられる。ID-WSF については具体的な業務ユー
スケースへの適合性、標準化状況、普及の状況を鑑みて、今後採用候補として検討する。（付録 5 参照）

３．７．３

リポジトリ機能

リポジトリ機能とは、標準仕様関連書類、システム開発仕様、プログラム、用語定義、項目辞書等を、蓄積・管理するデータベース等の蓄積機能である。詳細な定義は、アーキテクチャ標準仕様の４．５．
３．３

ユーティリティ機能に規定されている。

地域情報 PF によるリポジトリ機能のユースケースを下記に示す。
ア）ユースケース１：

PF 標準仕様のバージョン別の各種ドキュメントの蓄積と公開管理者：PF 標準仕様の管理者
使用者：公開する各種ドキュメントを参照する人（自治体、製品ベンダ他など）

要件 ：管理者は、地域情報 PF 標準仕様運用規則に基づき、下記の PF 標準仕様の管理と使用者への公開ができること。
a)ドキュメント類の例
・自治体業務アプリケーションユニット標準仕様
・アーキテクチャ標準仕様、プラットフォーム通信標準仕様
・地域情報 PF 準拠及び相互接続仕様
・地域情報プラットフォームガイドライン
・地域情報 PF 基本説明書b)XML 定義類の例－ 118 －

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

・自治体業務アプリケーションユニット標準仕様で規定される XML 定義類-業務ユニットインタフェースに関する標準規定の XML 定義類(WSDL/XSD)-ワンストップサービスに関するサンプル XML 定義類(BPEL/WSDL/XSD 等)イ）ユースケース２：

PF 標準仕様を活用した自治体の設計共通リポジトリ（文書管理）

管理者：地域情報 PF に対応した自治体システムを調達～運用・保守する自治体の管理者
使用者：地域情報 PF に対応した自治体システムの開発を実施する担当者
要件 ：管理者は、使用者が作成した下記の自治体システムに関する設計情報の管理ができる。
・PF 標準仕様や、自治体個別要件に基づきカスタマイズした自治体内標準仕様書
・工程管理資料、設計ドキュメント、UML、ソースコード

３．７．４

等

統合レジストリ機能「統合レジストリ機能」について記載する。本機能はオプションである。
（１）統合レジストリ機能の目的
高付加価値サービスをサービス利用者に対して迅速に安定して提供するためには、サービス提供者またはサービス管理者がサービスの運用状況や、サービス利用者との合意に基づいた目標品質を管理・把握し、これら「サービス情報」をサービスの品質にフィードバックすることが可能なサービス管理基盤が必要である。
そこで多様化するサービス利用者とサービス提供者間の関係（サービス利用形態）を二者間の｢合意｣として策定し、UDDI(Universal Description, Discovery and Integration)、等の従来のレジストリが管理する情報とあわせて｢サービス情報｣として管理・監視する統合レジストリ機能を用い、高付加価値
サービスの効率的な提供を実現する。
（２）統合レジストリ機能の利用シーンについて住民が地域ポータルを経由して転居などの各種申請を行う際、地域ポータルの裏では自治体の提供する各種サービスや民間企業の提供する住所変更サービスとの連携が必要となる。このように連携した形でサービス（高付加価値サービス）を提供する際、複数サイトを跨ってのセキュリティ（暗号化）の確保や、必要に応じたログの提供、取得を行うことが必要である。
これらのニーズに対し、あらかじめサービス利用者とサービス提供者との間でセキュリティ（暗号化）や、目標品質（サービスレスポンスタイム）の管理について合意交渉を行うことで、住民に対し必要な情報を提供すると同時に、サービス管理者の運用状況把握も容易にすることで、安定した高付加価値サービスの提供をすることが可能となる。また、サービス間の連携や、その際の品質・運用状
況の管理を行う場合、既存のサービスに対し接続や管理に関する機能追加や運用フローの拡充などが必要となるが、それら機能追加をエージェント機能が提供することで連携する地域ポータルのサービ
ス管理者、サービス提供者の双方にとって負担が軽減され、効率的なサービス提供を実現することができる。
図３．７．２に統合レジストリ機能の利用シーンを示す。

－ 119 －

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

合意した内容のサービスへの適用
合意適用状況の監視地域ポータル運営会社
サービス
利用

住民

地域ポータル運営会社
または、国または、自治体

自治体Ａ

統合レジストリ機能（エージェント機能）

地域ポータル

サービス

レジストリ利用
合意交渉
地域ポータ ル運営会社
または、国

民間企業
連携

統合レジストリ機能（レジストリ機能）

レジストリ利用

サービス

合意交渉
サービス情報の登録、提供
サービス利用条件について合意交渉、策定

図３．７．２

統合レジストリ機能の利用シーン（３）統合レジストリ機能の処理概要
アーキテクチャ標準仕様４．５．３．３（４）②統合レジストリの機能要件に記載されている機能要件を満たした統合レジストリ機能を利用することにより、実現できる処理フローと、処理概要を示
す。
ア）統合レジストリ機能の処理フロー

統合レジストリ
利用者

③合意交渉
②サービス
情報検索

レジストリ機能
合意交渉
合意交渉

①サービス
登録
サービス提供者
サービス関連情報サービス関連情報
サービス運用状況
サービス運用状況

エージェント機能

サービス利用者③合意交渉

統合レジストリ
利用者

連携（運用
情報収集）

セキュリティ（暗号化）
セキュリティ（暗号化）④サービス利用

目標品質
目標品質

ログ取得
ログ取得

サービス

統合レジストリ機能

図３．７．３

統合レジストリ機能の処理フローと処理概要

イ）統合レジストリ機能の処理機能a）、b)のエージェント機能を提供することができる。
a)暗号化処理
サイトを跨ってサービス利用者とサービス提供者間でのメッセージを交換する際、サービス－ 120 －

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

提供者側がメッセージ暗号化を行えない場合、エージェントがメッセージ暗号化を代理することによる通信路上のセキュリティの確保
b)目標品質（サービスレスポンスタイム）の管理
サイトを跨ってサービス利用者とサービス提供者間がサービス連携をする際、予めサービス利用者とサービス提供者の間で取り交わしたレスポンスタイムなどに基づき、サービス提供者側のリクエス
ト、レスポンスタイムの計測による目標品質の管理ができる（４）統合レジストリ機能の実装モデル
ア)エージェント機能の Web サービス化
実装モデルとして、アーキテクチャ標準仕様４．５．３．３（４）③の図を図３．７．４に示す。

②サービスを閲覧／検索する

レジストリ機能
従来のレジストリ機能①サービスを登録する

合意交渉
合意交渉

サービス提供者
サービス
③合意交渉
を行う

①サービスを利用する
SOAP④エージェントの管理、制御エージェント機能
合意適用
合意監視

SOAP

サービス利用者

サービス
統合レジストリ機能

図３．７．４

３．７．５

統合レジストリ機能の実装モデル

ビジネスメッセージルーティングゲートウェイ機能（BMR-GW）

BMR-GW 機能は、業務メッセージの送信先を、受信した申請書類の内容や業務プロセスの処理結果に応じて動的に変更する要求がある。例えば、ポータルからの情報照会の申請書類から照会先団体を取り出し、その団体名に基づいて照会依頼を送信するような利用シーンが考えられる（図３．７．５）。あるいは、ある団体からの業務メッセージの処理結果を後日返信する場合、業務メッセージの送信元に応じた
返信先の動的変更が必要となるような利用シーンが考えられる(図３．７．６)。
地域情報 PF では、この動的な業務メッセージ送信先の制御機能を「ビジネスメッセージルーティング
ゲートウェイ機能（略称：BMR-GW 機能）」と呼ぶ。BMR-GW 機能は、オプションであるが、複数個所から呼び出される非同期呼び出しがある場合は必須となっている。

－ 121 －

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

図３．７．５ 動的な送信先変更

団体 A
業務プロセス

申請の送信元に応じて結果の返信先を
動的に変更

申請

団体 C

処理
結果

団体 B
業務プロセス

図３．７．６

申請
処理
結果

送信元に応じた動的な返信先の変更

WS-BPEL で記述されたビジネスプロセスで送信先の動的変更を実現する場合、WS-BPEL 仕様に従って
EndpointReference を使用することが考えられる。しかし、ビジネスプロセス配備時に送信先を静的にバインドする WS-BPEL 処理系の場合、こうした機能が使用できない可能性がある。また、一般的な業務ユ
ニットにおいても、複数の呼び出し元から非同期で呼び出される場合や、業務内容により呼び出し先の業務ユニットを動的に変える必要がある。このため、動的に送信先を変更するゲートウェイ（BMR-GW）
機能をプラットフォームに用意する。

－ 122 －

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

３．８

メッセージ交換パターンと異常系処理
本章では、メッセージパターンと異常系処理の下記事項について概説する。

(1) メッセージ交換パターンの種類と選定理由：想定されるメッセージ交換パターンについて説明した上で、プラットフォーム通信標準仕様として定めたメッセージ交換パターンの選定理由について説明する。
(2)応答側処理におけるメッセージ交換パターンの制約：
データ交換システムパターンに関連し、組み合せて利用されるメッセージ交換パターンのうち、特に応答側処理における制約、奨励事項について説明する。
(3)異常系処理における問題解決、障害復旧対応の概説：
問題を複雑化させないように、地域情報プラットフォームでは、異常系処理については、プラット
フォーム通信標準仕様に関係する事項のみに限定している。ここでは、地域情報プラットフォームにおける問題解決のための手順概要を説明する。
(4)異常系処理における留意するべき事項 ：異常時の WS-BPEL(Web Services Business Process Execution Language 2.0)プロセスをどのように扱うかなどをはじめとして、障害発生時に留意すべき事項について概説する。

３．８．１

メッセージ交換パターンの種類と選定理由（１）考えられ得るメッセージ交換パターンの定義（１）

メッセージ交換パターン類型

メッセージ交換パターンの検討にあたっては、レスポンスの有無により「リクエスト型」と「リクエスト・レスポンス型」の 2 種類に分類し、その上で受領 Ack(Acknowledgement)の有無、受領 Ack もしくはレスポンス受信方法の同期、非同期等の観点で細分化した。この結果、下記７パターンが定義される。
・リクエスト型受領 Ack なし
・リクエスト型受領 Ack あり・リクエスト型非同期型受領 Ack・リクエスト・レスポンス型同期型レスポンス
・リクエスト・レスポンス型非同期型レスポンス
・リクエスト・レスポンス型同期型受領 Ack＋非同期型レスポンス
・リクエスト・レスポンス型非同期型受領 Ack＋非同期型レスポンス
これらのメッセージ交換パターンについて以下に説明する。なお、以降の説明において使用する用語
および表記法については、プラットフォーム通信標準仕様の６．１ 概念、用語の定義に準じる。
（２）

リクエスト型

リクエスト型のメッセージ交換パターンとは、要求メッセージのみで構成され、業務処理結果を含んだ応答メッセージが存在しないパターンである。リクエスト型の例としては、業務ユニットからの帳票
出力指示、バッチプログラムや他の業務ユニットへの通知などが想定される。リクエスト型のメッセー
ジ交換では、受領 Ack の有無および受信の仕方により以下の３パターンが存在する。
a.リクエスト型受領 Ack なし－ 123 －

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

開始側から処理要求等の要求メッセージを送信し、応答側では要求メッセージに対する受領 Ack を含めて応答を返さないパターンである。
【特徴】
・送信のみであるため実装が容易である。
・受領 Ack も応答メッセージも相手から通知されないため、SOAP(Simple Object Access Protocol)通信レベルよりも上位の送達確認を行うことができない。
・障害検知も SOAP レベルから下位となるため、他の方法による上位層の障害検知が必要となる。
【シーケンス】
・開始側：要求メッセージ送信・応答側：要求メッセージ受信 ⇒ 内容に基づく処理

要求側
要求側

応答側
応答側

送信
req
受信
要求メッセージの処理

図３．８．１

リクエスト型受領 Ack なし

b.リクエスト型受領 Ack あり
同期型のメッセージ交換パターンである。開始側は、処理要求等の要求メッセージを送信するとともに、同一セッションで応答側からの受領 Ack の受信も行う。一方、応答側では、要求メッセージに対す
る応答メッセージは返さないが、受領 Ack を同一セッションにて送信するパターンである。
【特徴】
・比較的簡単なプロセス定義、サービスプログラミングにより、応答側での要求メッセージの受信の成功もしくは失敗を検知できる。
・開始側にて送達確認を行うことができる。
・応答側での処理結果が開始側に返されないため、要求メッセージに基づく処理が成功したかどうか
を開始側で確認できない。
【シーケンス】
・開始側：要求メッセージ送信 ⇒ 受領 Ack 受信 ⇒ 受領 Ack チェック
－ 124 －

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

・応答側：(要求メッセージ受信)⇒ 受領 Ack の生成 ⇒ 受領 Ack 返信 ⇒ 要求に基づく処理

要求側
要求側

応答側
応答側

送信
req
受信
受領ack
生成
受領ack
チェック

返信
ack

要求メッセージの処理

図３．８．２

リクエスト型受領 Ack あり

c.リクエスト型非同期型受領 Ack
要求メッセージに同期して同一のセッションで受領 Ack を返すのではなく、非同期で受領 Ack を返す
パターンである。開始側は、処理要求等の要求メッセージを送信してセッションを終了させ、応答側からの受領 Ack を、別セッションにて受信する。同様に、応答側では、要求メッセージを受信したならセッ
ションを終了させ、別セッションにて受領 Ack を開始側に送信するパターンである。
【特徴】
・開始側における障害検知能力としては、前述(b)の同期型受領 Ack と同等である。
・前述の「b.リクエスト型受領 Ack あり」と比較して処理方法が複雑になる可能性がある。
・開始側のセッションタイムアウト時間よりも、応答側の受領 Ack 生成に時間がかかる場合に有効である。
【シーケンス】
・開始側：要求メッセージ送信 ⇒ 受領 Ack 受信（非同期）⇒ 受領 Ack チェック・応答側：要求メッセージ受信 ⇒ 受領 Ack 生成 ⇒ 受領 Ack 送信（非同期）⇒ 要求に基づく処理－ 125 －

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

要求側
要求側

応答側
応答側

送信
req
受領ack
生成
ack

受信

受信

送信

受領ack
チェック
要求メッセージの処理

図３．８．３（３）

リクエスト型非同期型受領 Ack

リクエスト・レスポンス型

このパターンはリクエストとそれに対する業務データを含むレスポンスの組で構成される。受領 Ackの有無、および、受領 Ack とレスポンスの送受信の仕方で以下の４パターンが存在する。
a.リクエスト・レスポンス型同期型レスポンス
要求メッセージの送信と同一のセッションで、応答側からの業務処理結果情報の応答メッセージを返す同期型のパターンであり、受領 Ack の通知は行わない。開始側は、要求メッセージの送信を行った後に同一のセッションで応答側からの応答メッセージを受信する。一方、応答側は要求メッセージを受信後、受信確認用の受領 Ack を返すことなく、要求された業務処理を実施し、その後、その結果情報を開始側に応答メッセージとして返す。
【特徴】
・ 開始側にて処理結果の確認を行うことができる。
・ 照会処理や更新処理など幅広い処理に対応できる。
・ 同一セッションにて処理結果を受信する方式のため、後述のメッセージ交換パターンと比較して実装が容易である。
・ 開始側のセッションタイムアウト時間内に応答側の処理が終了して応答メッセージを返せるような、
比較的軽い処理に有効である。
・ 開始側のセッションのタイムアウト時間内に応答側の処理が終了しなかった場合、開始側ではすべてタイムアウトとして検知されるので、開始側では通信障害なのか、業務処理の遅延によるタイム
アウトなのか判断できない。
【シーケンス】
・開始側：要求メッセージ送信 ⇒応答メッセージ受信 ⇒受信後の処理
・応答側：要求メッセージ受信 ⇒ 要求に基づく処理、応答メッセージ生成 ⇒返信－ 126 －

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

要求側
要求側

応答側
応答側

送信
req
受信
要求メッセージの処理
応答メッセージの生成

応答メッセージの処理
返信
res

図３．８．４

リクエスト・レスポンス型同期型レスポンス

b.リクエスト・レスポンス型非同期型レスポンス
要求メッセージの送信とは別セッションで応答側からの業務処理結果情報の応答メッセージを返す非同期型のパターンであり、受領 Ack の通知は行わない。開始側は、要求メッセージの送信を行ったセッションとは別セッションで応答側から応答メッセージを受信する。一方、応答側は要求メッセージを受信してセッションを切断後、受信確認用の受領 Ack を返すことなく、要求された業務処理を実施し、その後に新たなセッションを開設して結果情報を開始側に応答メッセージとして返す。
【特徴】
開始側にて処理結果の確認を行うことができる。
照会処理や更新処理など幅広い処理に対応できる。
開始側から要求された処理が応答側にて比較的時間のかかる、あるいは、人手が介するような処理に有効である。
応答側で要求メッセージを受信したにも関わらず、後続の処理に失敗したなどの場合、開始側での応答メッセージの受信あるいは受信タイムアウトまで障害検知が行えない。
正常系における応答メッセージの送信に数時間～数日かかる処理において、要求メッセージの受信で検出される通信障害が発生した場合、迅速な異常系処理の対応が困難となる。
（受領 Ack 等を返すパターンであれば即座に通信障害を検知できる）【シーケンス】
・開始側：要求メッセージ送信 ⇒ 応答メッセージ受信 ⇒ 受信後の処理
・応答側：要求メッセージ受信 ⇒ 要求に基づく処理、応答メッセージ生成 ⇒ 返信

－ 127 －

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

要求側
要求側

応答側
応答側

送信
req
受信
要求メッセージの処理
応答メッセージの生成
送信
res
受信
応答メッセージの処理

図３．８．５

リクエスト・レスポンス型非同期型レスポンス

c.リクエスト・レスポンス型同期型受領 Ack＋非同期型レスポンス
リクエスト・レスポンス型非同期型レスポンスと同様、要求メッセージの送信とは別セッションにて応答側から業務処理結果情報の応答メッセージを返す非同期型ではあるが、本パターンでは要求メッ
セージおよび応答メッセージのそれぞれに対して相手側から受領 Ack を受信するものである。なお、応答側（レスポンス送信側）にて応答メッセージに対する受領 Ack を無視することも許容する。
【特徴】
照会処理や更新処理など幅広い処理に対応できる。
開始側から要求された処理が応答側にて比較的時間のかかる、あるいは、人手が介するような処理に有効である。
同期型として同一セッションにて受領 Ack を受信するため、後述 d.の非同期型と比較して簡潔に双方向の受領 Ack を含むメッセージ処理が記述可能である。
要求メッセージの送信に失敗した場合、受領 Ack のタイムアウト検出により異常系処理の対応が迅速に行える。
【シーケンス】
・開始側：要求メッセージ送信 ⇒ 受領 Ack 受信 ⇒ 受領 Ack チェック ⇒ 応答メッセージ受信 ⇒受領 Ack 生成 ⇒ 受領 Ack 返信 ⇒ 受信後の処理
・応答側：要求メッセージ受信 ⇒ 受領 Ack 生成 ⇒ 受領 Ack 返信 ⇒ 要求に基づく処理 ⇒応答メッセージ生成 ⇒ 返信 ⇒ 受領 Ack 受信 ⇒ 受領 Ack チェック

－ 128 －

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

要求側
要求側

応答側
応答側

送信
req

受信

要求メッセージの処理
応答メッセージの生成

返信

受領ack
生成

ack
受領ack
チェック

受領ack
生成

送信
受信

res

返信
ack
応答メッセージの処理

図３．８．６

受領ackチェック(無視も許容)リクエスト・レスポンス型同期型受領 Ack+非同期型レスポンス

d.リクエスト・レスポンス型非同期型受領 Ack＋非同期型レスポンス
これは要求メッセージに対して、同期の返信で応答メッセージを返さず、非同期で受領 Ack、応答メッ
セージをそれぞれ返すもので、要求メッセージ、応答メッセージとそれぞれの受領 Ack 全てを別のセッション（非同期）で送受信する。このパターンは、一組のリクエスト・レスポンス交換に 4 セッションを使用することになり、開始側、応答側ともに送受信処理の記述が非常に複雑になる。
【特徴】
・照会処理や更新処理など幅広い処理に対応できる。
・開始側から要求された処理が応答側にて比較的時間のかかる、あるいは、人手が介するような処理に有効である。
・要求メッセージの送信に失敗した場合、受領 Ack のタイムアウト検出により異常系処理の対応が迅速に行える。
・非同期型として別セッションにて受領 Ack を受信するため、複雑な処理になる。
【シーケンス】
・開始側：要求メッセージ送信 ⇒ 受領 Ack 受信 ⇒ 受領 Ack チェック ⇒ 応答メッセージ受信 ⇒受領 Ack 生成 ⇒ 受領 Ack 返信 ⇒ 受信後の処理
・応答側：要求メッセージ受信 ⇒ 受領 Ack 生成 ⇒ 受領 Ack 返信⇒ 要求に基づく処理 ⇒応答メッセージ生成 ⇒ 返信 ⇒ 受領 Ack 受信 ⇒ 受領 Ack チェック

－ 129 －

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

要求側
要求側

応答側
応答側

送信
req
受信
受領ack
生成
送信

ack

受信

要求メッセージの処理
応答メッセージの生成

受領ack
チェック

送信

res

受信
受領ack
生成
送信

ack
受信

受領ack
チェック

応答メッセージの処理

図３．８．７

リクエスト・レスポンス型非同期型受領 Ack+非同期型レスポンス（２）選定理由
地域情報プラットフォームとしては、・実装が容易であること。
・障害検知が容易であること。
・障害検知の仕組みが明確に定義できること。
・業務の要件に応じた最適な方式が選択可能であること。
・SOAP 1.1 等の Req-Res パターン合致すること。
という観点に基づいて、これまで述べたメッセージ交換パターンの評価を行い、次の３種類のメッセー
ジ交換パターンを標準仕様として採用した。なお、利用に際しては業務処理時間やタイムアウト時間などを含めた業務要件に応じてメッセージ交換パターンを選択する必要がある。
【標準仕様】
・リクエスト型受領 Ack あり・リクエスト・レスポンス型同期型レスポンス
・リクエスト・レスポンス型同期型受領 Ack＋非同期型レスポンス－ 130 －

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

３．８．２

応答側処理におけるメッセージ交換パターンの制約(１)概説
プラットフォーム通信標準仕様では、メッセージ交換パターンを要求側と応答側間の一般的なメッセージのやり取りとして定義している。このため、地域情報プラットフォームの全ての点で適用可能である。しかし、応答側は実際には応答側 BPM(Business Process Management)機能、並びに応答側業
務ユニットから構成され、この中でも要求側と応答側間のメッセージ交換パターンと同様のメッセー
ジ交換パターンを利用する。そして、一部にはメッセージ交換パターンの組み合せに関する制約事項も存在する。この様な制約事項は、概ね、データ交換システムパターンとメッセージ交換パターンの関係の中で定義されているが、ここではメッセージ交換パターンの組み合せ、特に発生する制約事項に関してより具体的に概説する。
制約を大別すると２つに分類される。一つは、応答側が一つの BPM 機能と一つの業務ユニットから成る基本的な構成における制約である。もう一方は、応答側が一つの BPM 機能に対して、複数業務ユニットから成る一般的な構成における制約である。そこで以下、奨励する基本的構成、一般的構成、そして奨励しない構成について説明する。
(２)奨励する基本的な構成
図３．８．８～図３．８．１０は、応答側が応答側 BPM 機能、並びに一つの応答側業務ユニットで構成されている場合に、組み合わされて実施されるメッセージ交換パターンの手順について記したものである。この場合、要求側は、要求側 BPM 機能、要求側業務ユニットのいずれも可能である。

req

送信

req

送信

req

受信

受領ackを受理してから終了aｃｋ

応答側
応答側
業務ユニット業務ユニット

応答側BPM機能
応答側BPM機能

要求側
要求側

aｃｋ

前提：リクエスト型同期型受領Ackあり
前提：リクエスト型同期型受領Ackありの採択の採択

受領ackを受理してから終了

受信

aｃｋ

返信

送信

req
aｃｋ

この部分
は無くとも
良い

返信

データ交換システムパターン[Type4]のメッセージ
データ交換システムパターン[Type4]のメッセージ
交換パターンの要件に基づき「リクエスト型同期型
交換パターンの要件に基づき「リクエスト型同期型
受領Ackあり」を選択する。
受領Ackあり」を選択する。

MEP上では応答側とまとめて定義
MEP上では応答側とまとめて定義

図３．８．８

リクエスト型受領 Ack ありの組み合せ制約(基本的な構成)

図３．８．８は、要求側～応答側間のメッセージ交換パターンが、「リクエスト型受領 Ack あり」となった場合の一連の処理フローである。この場合、応答側の内部である応答側 BPM 機能～応答側業務－ 131 －

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

ユニット間で為されるメッセージ交換パターンにおいても、「リクエスト型受領 Ack あり」が選択される必要がある。これは、データ交換システムパターン[Type4]のメッセージ交換パターンの要件に基づく。応答側業務ユニットにおいては、業務ユニット内部で受領 Ack を明示的に戻す必要はなく、業務ユニット部分の SOAP 処理系が受領 Ack を戻すことでもよい。

要求側
要求側
req

送信

応答側
応答側
業務ユニット業務ユニット

応答側BPM機能
応答側BPM機能
req

送信
受信

req

resを受理してから終了

受信タイムアウト検知
受信タイムアウト検知

受信

送信
受信

res
res

res

送信

req
res

統合DB機能は同期型
統合DB機能は同期型
でアクセス
でアクセス

送信

受信

受信

前提：リクエスト・レスポンス型同期型
前提：リクエスト・レスポンス型同期型
レスポンスの採択
レスポンスの採択

データ交換システムパターン[Type4]のメッセージ
データ交換システムパターン[Type4]のメッセージ
交換パターンの要件に基づき「リクエスト・レスポンス
交換パターンの要件に基づき「リクエスト・レスポンス
型同期型レスポンス」を選択する。
型同期型レスポンス」を選択する。

MEP上では応答側とまとめて定義
MEP上では応答側とまとめて定義

図３．８．９リクエスト・レスポンス型同期型レスポンスの組み合せ制約(基本的な構成)

図３．８．９は、要求側～応答側間のメッセージ交換パターンが、「リクエスト・レスポンス型同期型レスポンス」となった場合の一連の処理フローである。この場合、応答側の内部である応答側 BPM
機能～応答側業務ユニット間で為されるメッセージ交換パターンにおいても、「リクエスト・レスポン
ス型同期型レスポンス」が選択される。これは、データ交換システムパターン[Type4]のメッセージ交換パターンの要件に基づく。また、応答側業務ユニットが、さらに統合 DB 機能に対してアクセスする
場合、データ交換システムパターン[Type5]のメッセージ交換パターンの要件に基づき、「リクエスト・
レスポンス型同期型レスポンス」が利用される。また、要求側の業務ユニットでは受信タイムアウト
についての検知が行なわれる。
なお、図３．８．９の方法は、リクエスト・レスポンス型同期型レスポンスの組み合わせであるため、比較的短時間に要求側～応答側間のメッセージ交換パターン全体が終了することが期待される。
従って、応答側業務ユニットにおいて、自治体職員等の操作者が介在して処理を進める場合、若干のレスポンスの遅れに対しても、要求側の業務ユニットで受信タイムアウトとなるリスクも存在する。
このため、応答側業務ユニットにおいて自治体職員等の操作者が介在して処理を進める場合は、これは奨励しない。
これに対して、図３．８．１０は要求側～応答側間のメッセージ交換パターンが、「リクエスト・レ
スポンス型同期型受領 Ack+非同期型レスポンス」となった場合の一連の処理フローである。この場合、－ 132 －

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

応答側の内部である応答側 BPM 機能～応答側業務ユニット間で為されるメッセージ交換パターンにおいても、「リクエスト・レスポンス型同期型受領 Ack+非同期型レスポンス」が選択される。この場合も要求側の業務ユニットでは、非同期に受信する応答メッセージに対して受信タイムアウトについての検知が行なわれるが、非同期型レスポンスであるため、十二分に長い時間が想定される。このため、応答側業務ユニットにおいて自治体職員等の操作者が介在して処理を進める場合は、この方法を奨励する。
なお、応答側業務ユニットが、さらに統合 DB 機能に対してアクセスする場合、データ交換システム
パターン[Type5]のメッセージ交換パターンの要件に基づき、「リクエスト・レスポンス型同期型レス
ポンス」が利用されることになる。

req

送信

req

送信

受信タイムアウト検知
受信タイムアウト検知

aｃｋ

aｃｋ

送信

受領ackを受理してから終了

受信

aｃｋ

返信

送信

req
aｃｋ

統合DB機能は同期型
統合DB機能は同期型
でアクセス
でアクセス

返信
res

送信

res

この部分
は無くとも
良い

req

受信

受領ackを受理してから終了

res
ack

応答側
応答側
業務ユニット業務ユニット

応答側BPM機能
応答側BPM機能

要求側
要求側

送信

res

受信

受信

返信

ack

この部分
は無くとも
良い

返信

ack

ack
無視されることも考えられる。

受信
前提：リクエスト・レスポンス型同期型
前提：リクエスト・レスポンス型同期型
受領Ack＋非同期レスポンスの採用
受領Ack＋非同期レスポンスの採用

データ交換システムパターン[Type4]のメッセージ
データ交換システムパターン[Type4]のメッセージ
交換パターンの要件に基づき「リクエスト・レスポンス型同期型
交換パターンの要件に基づき「リクエスト・レスポンス型同期型
受領Ack＋非同期レスポンスの採用」を選択する。
受領Ack＋非同期レスポンスの採用」を選択する。

MEP上では応答側とまとめて定義
MEP上では応答側とまとめて定義

図３．８．１０

リクエスト・レスポンス型同期型受領 Ack+非同期型レスポンスの組み合せ制約(基本的な構成)(３)奨励する一般的な構成
図３．８．１２～図３．８．１４は、応答側が一つの応答側 BPM 機能、並びに複数の応答側業務ユニットで構成されている場合に、組み合わされて実施されるメッセージ交換パターンの手順について記したもので、一般化された構成を記したものある。この場合、要求側は、要求側 BPM 機能、要求側
業務ユニットのいずれも可能である。
図３．８．１２の上段は、要求側～応答側間のメッセージ交換パターンが、「リクエスト型受領 Ackあり」となった場合の一連の処理フローであり、応答側業務ユニット呼び出しを直列化して実施する場合である。WS-BPEL では、構造化アクティビティとして sequence を用いる。
これに対して下段は、要求側～応答側間のメッセージ交換パターンは、上段と同様に「リクエスト型受領 Ack あり」となった場合の一連の処理フローであるが、応答側業務ユニット呼び出しを並列化－ 133 －

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

して呼び出す場合である。WS-BPEL では、構造化アクティビティとして並列化する部分に対して flow
を用い、並列化された各々は sequence を指定する。
図３．８．１１の上下段に関係なく、データ交換システムパターン[Type4]のメッセージ交換パターンの要件、並びに図３．８．８に記した基本的な構成に基づき、応答側の内部である応答側 BPM 機能～応答側業務ユニット間で為されるメッセージ交換パターンにおいても、「リクエスト型受領 Ack あり」が選択される。各々の応答側業務ユニットにおいては、業務ユニット内部で受領 Ack を明示的に戻す
必要はなく、各々の応答側業務ユニットの SOAP 処理系が受領 Ack を戻すことでもよい。

req

送信

受信

req

sequence化し最後の受領ackを受信した後、受領ackを送信してから終了。

ack

送信

応答側
応答側
業務ユニットN
業務ユニットN

応答側
応答側
業務ユニット1
業務ユニット1

応答側BPM機能
応答側BPM機能

要求側
要求側

送信

送信

req

受信

ack

送信

req

受信

ack

送信

この部分は
無くとも良い

req
ack

返信

送信

req
ack

返信

ack

req

送信

req

flowによる並列化し最後の受領ackを受信し、受領ackを送信してから終了。
送信

ack

この部分は
無くとも良い

受信

送信

送信

req

送信

req

送信

この部分は
無くとも良い

req
送信

req
この部分は
無くとも良い

受信
受信

ack
ack

返信

ack

ack
返信

ack

MEP上では応答側とまとめて定義
MEP上では応答側とまとめて定義

前提：リクエスト型同期型受領Ackあり
前提：リクエスト型同期型受領Ackありの採択の採択

図３．８．１１

データ交換システムパターン[Type4]のメッセージ
データ交換システムパターン[Type4]のメッセージ
交換パターンの要件に基づき「リクエスト型同期型受領Ackあり
交換パターンの要件に基づき「リクエスト型同期型受領Ackありの採用」を選択する。
の採用」を選択する。

リクエスト型受領 Ack ありの組み合せ制約(一般的な構成)

図３．８．１２は、要求側～応答側間のメッセージ交換パターンが、「リクエスト・レスポンス型同期型レスポンス」となった場合の一連の処理フローである。この場合、データ交換システムパターン[Type4]のメッセージ交換パターンの要件、並びに図３．８．９に記した基本的な構成に基づき、応答側の内部である応答側 BPM 機能～応答側業務ユニット間で為されるメッセージ交換パターンにおいても、「リクエスト・レスポンス型同期型レスポンス」が選択される。
複数の応答側業務ユニットを呼び出す場合、直列化して実施する、並列化して実施するどちらでも可能である。この場合、WS-BPEL では、構造化アクティビティとして並列化する部分に対して flow を用い、並列化された各々は sequence を指定する。但し、「リクエスト・レスポンス型同期型レスポンス」であるため、受信タイムアウトは比較的短い時間が設定されることも想定されるため、並列化して実施することを奨励する。
また、応答側業務ユニットにおいて自治体職員等の操作者が介在して処理を進める場合、若干のレ
スポンスの遅れに対しても、要求側の業務ユニットで受信タイムアウトとなるリスクが存在する。このため、応答側業務ユニットにおいて自治体職員等の操作者が介在して処理を進める場合は、これは奨励しない。
－ 134 －

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

各々の応答側業務ユニットが、さらに統合 DB 機能に対してアクセスする場合、データ交換システム
パターン[Type5]のメッセージ交換パターンの要件に基づき、「リクエスト・レスポンス型同期型レス
ポンス」が利用される。また、要求側の業務ユニットでは受信タイムアウトについての検知が行なわれる。これらは、基本的な構成と同様である。

req

送信

req

受信
送信

req

受信

受信

res

送信

送信

req

受信

受信

res

送信

受信タイムアウト検知
受信タイムアウト検知

res
res

応答側
応答側
業務ユニットN
業務ユニットN

応答側
応答側
業務ユニット1
業務ユニット1

応答側BPM機能
応答側BPM機能

要求側
要求側

送信

送信

送信

req
res
統合DB機能は同期型
統合DB機能は同期型
でアクセス
でアクセス

送信

req
res

統合DB機能は同期型
統合DB機能は同期型
でアクセス
でアクセス

sequence化、もしくはflowによる並列化が可能。最後の受領ackを受信し、受領ackを送信してから終了。
MEP上では応答側とまとめて定義
MEP上では応答側とまとめて定義

前提：リクエスト・レスポンス型同期型
前提：リクエスト・レスポンス型同期型
レスポンスの採択
レスポンスの採択

図３．８．１２

データ交換システムパターン[Type4]のメッセージ
データ交換システムパターン[Type4]のメッセージ
交換パターンの要件に基づき「リクエスト・レスポンス型同期型
交換パターンの要件に基づき「リクエスト・レスポンス型同期型
レスポンスの採用」を選択する。
レスポンスの採用」を選択する。

リクエスト・レスポンス型同期型レスポンスの組み合せ制約(一般的な構成)

図３．８．１３は、要求側～応答側間のメッセージ交換パターンが「リクエスト・レスポンス型同期型受領 Ack+非同期型レスポンス」となった場合の一連の処理フローである。この場合、要求側～応答側間のメッセージ交換パターンには「リクエスト・レスポンス型同期型受領 Ack+非同期型レスポン
ス」を用い、応答側の内部である応答側 BPM 機能～応答側業務ユニット間で為されるメッセージ交換
パターンにおいても、「リクエスト・レスポンス型同期型受領 Ack+非同期型レスポンス」が選択される。
そして、応答側 BPM 機能は一連の動作を全て制御する。
この場合も要求側の業務ユニットでは、非同期に受信する応答メッセージに対して受信タイムアウ
トについての検知が行なわれるが、非同期型レスポンスであるため、十二分に長い時間が想定される。
このため、応答側業務ユニットにおいて自治体職員等の操作者が介在して処理を進める場合は、この方法を奨励する。
なお、留意事項として応答側 BPM 機能では、リクエスト(req)とレスポンス(res)を分割して記述してはならない。これに対して、要求側の業務ユニットでは、リクエスト(req)とレスポンス(res)を一体化して処理してはならない。これらは、次節の奨励しない構成の中で解説する。

－ 135 －

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

req

送信

受信

req

送信
sequence化、もしくはflowによる並列化が可能。最後の受領ackを受信し、受領ackを送信してから終了。

送信

送信

req

送信

受信

ack

送信

req

受信

ack

受信タイムアウト検知
受信タイムアウト検知
ack

応答側
応答側
業務ユニットN
業務ユニットN

応答側
応答側
業務ユニット1
業務ユニット1

応答側BPM機能
応答側BPM機能

要求側
要求側

この部分は
無くとも良い

req
ack

返信

送信
返信

req

この部分は
無くとも良いack

ack
統合DB機能は同期型
統合DB機能は同期型
でアクセス
でアクセス

ここだけで
sequence
化が必要
sequence化、もしくはflowによる並列化が可能。最後のresを受信し、ｒｅｓを応答後、受領ackを受信してから終了。

送信
res

res

受信

res

受信

res

返信

ack

返信

ack

送信

統合DB機能は同期型
統合DB機能は同期型
でアクセス
でアクセス
送信

res
送信

受信

無視されることも考えられる。

ack

ack

受信
ack
MEP上では応答側とまとめて定義
MEP上では応答側とまとめて定義

ack

前提：リクエスト・レスポンス型同期型
前提：リクエスト・レスポンス型同期型
受領Ack＋非同期レスポンスの採択
受領Ack＋非同期レスポンスの採択

図３．８．１３

res

データ交換システムパターン[Type4]のメッセージ
データ交換システムパターン[Type4]のメッセージ
交換パターンの要件に基づき「リクエスト・レスポンス型同期型
交換パターンの要件に基づき「リクエスト・レスポンス型同期型
受領Ack＋非同期レスポンスの採択」を選択する。
受領Ack＋非同期レスポンスの採択」を選択する。

リクエスト・レスポンス型同期型受領 Ack+非同期型レスポンスの組み合せ制約(一般的な構成)

図３．８．１３においても、図３．８．１２と同様に、複数の応答側業務ユニットを呼び出す場合、直列化して実施する、並列化して実施するどちらでも可能である。直列化、並列化に関しては通常、障害（異常）の対処方法に応じて決める必要がある。このため、業務内容に依存して適切なものを選択しなければならない。応答側業務ユニット呼び出しを直列化して実施する場合、WS-BPEL では構造化アク
ティビティとして sequence を用いる。これに対して、並列化する場合は WS-BPEL では、構造化アクティ
ビティとして並列化する部分に対して flow を用い、並列化された各々は sequence を指定する。また、各々の応答側業務ユニットが、さらに統合 DB 機能に対してアクセスする場合、データ交換システムパターン[Type5]のメッセージ交換パターンの要件に基づき、「リクエスト・レスポンス型同期型レスポンス」が利用される。また、要求側の業務ユニットでは受信タイムアウトについての検知が行なわれる。これらは、図３．８．１３や基本的な構成と同様である。
(４)奨励しない構成
図３．８．１４は、基本的構成に対して奨励しないメッセージ交換パターンである。図３．８．１４では、要求側～応答側間のメッセージ交換パターンが「リクエスト・レスポンス型同期型受領 Ack+非同期型レスポンス」であるのに対して、応答側の内部である応答側 BPM 機能～応答側業務ユニット間で為されるメッセージ交換パターンでは、同期型である「リクエスト・レスポンス型同期型レスポンス」を利用している。この方式は、可能ではあるが、データ交換システムパターン[Type4]のメッセージ交換パ
ターンの要件に基づくと、図３．８．１０の「リクエスト・レスポンス型同期型受領 Ack+非同期型レス
ポンス」が優先的に利用されるべきであるため、奨励しない。

－ 136 －

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

req

応答側
応答側
業務ユニット業務ユニット

応答側BPM機能
応答側BPM機能

要求側
要求側
送信

req

受信タイムアウト検知
受信タイムアウト検知

受信

aｃｋ

aｃｋ

返信

送信

req

受領ackを受理してから終了

受信

送信

送信

res
ack

送信

res

送信

res

受信

req

res

統合DB機能は同期型
統合DB機能は同期型
でアクセス
でアクセス

受信

受信

返信

受信
ack

この部分
は無くとも
良い

受領ackを受理してから終了前提：リクエスト・レスポンス型同期型
前提：リクエスト・レスポンス型同期型
受領Ack＋非同期レスポンスの採用
受領Ack＋非同期レスポンスの採用「リクエスト・レスポンス型同期型レスポンス」の選択も可能であるが、「リクエスト・レスポンス型同期型レスポンス」の選択も可能であるが、データ交換システムパターン[Type4]のメッセージ交換パターンの要件
データ交換システムパターン[Type4]のメッセージ交換パターンの要件に基づき、これは選択しないことを奨励する。
に基づき、これは選択しないことを奨励する。

MEP上では応答側とまとめて定義
MEP上では応答側とまとめて定義

図３．８．１４ リクエスト・レスポンス型同期型受領 Ack+非同期型レスポンスの組み合せ制約(奨励しない)

図３．８．１５～図３．８．１６は、一般的な構成に対して奨励しないメッセージ交換パターンである。図３．８．１５では、要求側～応答側間のメッセージ交換パターンが、「リクエスト・レスポンス型
同期型レスポンス」であるのに対して、応答側の内部である応答側 BPM 機能～応答側業務ユニット間で為されるメッセージ交換パターンでは、「リクエスト・レスポンス型同期型受領 Ack+非同期型レスポンス」
を利用している。この場合、応答側の内部である応答側 BPM 機能～応答側業務ユニット間で為されるメッセージ交換パターンが、比較的長時間に渡る処理を前提としているのに対して、要求側～応答側間のメッセージ交換パターンには、「リクエスト・レスポンス型同期型レスポンス」故に短い応答時間を期待されることになるため、要求側の業務ユニットで実施・検知される受信タイムアウトが頻発され易くなる。
メッセージ交換パターンを遵守することは、障害（異常）の対処方法を標準化し、通信品質の向上を目指すことであるため、受信タイムアウトが頻発され易くなる危険性を内包するメッセージ交換パターン
は、採択するべきではなく、奨励しない。

－ 137 －

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

req

送信

req

受信
送信

req

送信

受信

ack

送信

req

受信

ack

受信タイムアウト検知
受信タイムアウト検知

res

この部分は
無くとも良い

req
ack

返信

送信
返信

req

この部分は
無くとも良いack

統合DB機能は同期型
統合DB機能は同期型
でアクセス
でアクセス

sequence化、もしくはflowによる並列化が可能。最後の受領ackを受信し、受領ackを送信してから終了。

送信

応答側
応答側
業務ユニットN
業務ユニットN

応答側
応答側
業務ユニット1
業務ユニット1

応答側BPM機能
応答側BPM機能

要求側
要求側

統合DB機能は同期型
統合DB機能は同期型
でアクセス
でアクセス
受信

res

受信

res

送信

res
送信

返信

ack

返信

ack

受信

res

無視されることも考えられる。

ack

送信

受信

ack

MEP上では応答側とまとめて定義
MEP上では応答側とまとめて定義

res

前提：リクエスト・レスポンス型同期型
前提：リクエスト・レスポンス型同期型
レスポンスの採択
レスポンスの採択

図３．８．１５

要求側～応答側ＢＰＭ機能が、リクエスト・レスポンス型同期型レスポンスの採用をし要求側～応答側ＢＰＭ機能が、リクエスト・レスポンス型同期型レスポンスの採用をしているため、この「リクエスト・レスポンス型同期型受領Ack+非同期レスポンス」はているため、この「リクエスト・レスポンス型同期型受領Ack+非同期レスポンス」は受信タイムアウトを引き起こすリスクがある。その為、採択しない。
受信タイムアウトを引き起こすリスクがある。その為、採択しない。

リクエスト・レスポンス型同期型受領 Ack+非同期型レスポンスの組み合せ制約(奨励しない)

図３．８．１６も、奨励しないメッセージ交換パターンである。要求側～応答側間のメッセージ交換
パターンが、「リクエスト・レスポンス型同期型受領 Ack+非同期型レスポンス」であるのに対して、応答側の内部である応答側 BPM 機能～応答側業務ユニット間で為されるメッセージ交換パターンでは、「リク
エスト・レスポンス型同期型受領 Ack+非同期型レスポンス」を利用している。この場合、応答側 BPM 機
能は一連の動作を全て制御せず、要求メッセージに同期して同一のセッションで受領 Ack を受信した後、一度終了する。そしてレスポンスを受信する場合は、別の応答側 BPM 機能のロールを用いる。この場合、WS-BPEL の持つコリレーションセットの機構を用いて要求メッセージに対するレスポンスの対応付け、並びに複数のレスポンスの関係付けを行なうことが困難であるため、デッドロックを発生させる危険性もあり、奨励しない。

－ 138 －

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

req

送信

受信

req

送信

sequence化、もしくはflowによる並列化が可能。最後の応答を受けてからresを送信
し、終了

送信

ack

req

受信

ack

送信

req

受信

ack

受信タイムアウト検知
受信タイムアウト検知
送信

応答側
応答側
業務ユニットN
業務ユニットN

応答側
応答側
業務ユニット1
業務ユニット1

応答側BPM機能
応答側BPM機能

要求側
要求側

送信

この部分は
無くとも良い

req
ack

返信

送信
返信

req

この部分は
無くとも良いack

ack
統合DB機能は同期型
統合DB機能は同期型
でアクセス
でアクセス
応答側BPM機能を分割すると、res側のメッセージの対応付けが困難になる。

送信
res

res

統合DB機能は同期型
統合DB機能は同期型
でアクセス
でアクセス
受信

res

受信

res

返信

ack

返信

ack

送信

送信

res
送信

受信

無視されることも考えられる。

ack

ack

受信
ack
MEP上では応答側とまとめて定義
MEP上では応答側とまとめて定義

ack

採択しない。
採択しない。

前提：リクエスト・レスポンス型同期型
前提：リクエスト・レスポンス型同期型
受領Ack＋非同期レスポンスの採択
受領Ack＋非同期レスポンスの採択

図３．８．１６

res

リクエスト・レスポンス型同期型受領 Ack+非同期型レスポンスの組み合せ制約(奨励しない)

３．８．３

異常系処理における問題解決と障害復旧手順

ここでは、地域情報プラットフォームのメッセージ交換パターンにて検知された障害（異常）の対処
方法について、その概要を説明する。
（１） 地域情報プラットフォームの異常系処理の定義と位置付け
プラットフォーム通信標準仕様では、通信障害に対して次のような３段階での処理を規定している。
・ 障害の検知・ 即時対応処理
・ 異常系処理ここで障害検知とは、異常を捕捉することである。即時対応処理とは、障害検知を受け、それを通知する等の問題解決を伴わない対応処理である。これに対して異常系処理とは障害検知、即時対応処理を受けて、障害を解決するための一連の処理である。
異常系処理は、システム運用管理の一プロセスとして位置づけられ、システム運用設計のアウトプッ
トとしてシステム運用手順書等の形でマニュアルとしてドキュメント化されるべきものである。このドキュメントには異常系処理として、典型的な障害事象と原因の内容定義、その後の対処シナリオおよび再起動のための手順（以降、リランマニュアルと呼ぶ）が個々のシステム運用条件やシステム構成に対応して設計・整備されている必要があり、その詳細は共通的に定義できるものではない。そこで、本節では、地域情報プラットフォームの BPM 機能によるユニット間連携を前提として、メッセージ通信にお－ 139 －

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

ける異常系処理の手順概要を説明するにとどめることとする。
地域情報プラットフォームにおいて異常が検知された場合、適切な処置を講じずに処理を継続すると、それまでに処理した関連データと以降で処理されるデータとの間でデータの不整合が発生するリスクや、他のビジネスプロセスにおいても同様の不具合が発生するリスクを抱えることになる。従って、副次的な問題の発生、事態の複雑化を避けるために、異常系処理ではビジネスプロセスを停止・中断することを強く推奨する。
以降では、異常系処理の最初のステップであるビジネスプロセスの停止・中断から原因究明、復旧に至るまでのスケルトンを定義している。実システムへの適用に当たっては、このスケルトンを取り込む
形で、システム運用設計を行い、システム運用管理者をはじめとする各担当者（部門）の役割を含めた作業手順についてシステム運用手順書等の形で整備されることを推奨する。
（２） 異常系処理の手順例に関する解説
メッセージ通信における異常系処理手順の概要を図３．８．１７に記す。実運用にあたっては、既に述べているように個々の団体の規模、運用組織および運用形態などに応じて処理手順の見直しを行い、例えば、次のような観点での手順の詳細化が必要である。
・ 管理対象となるシステムの特性・ 導入済みあるいは導入予定のツールの状況
・ 個々の作業をシステム系（機械系）と人間系のいずれで行うかの切り分け
・ システムを構成する関連組織と重要度、影響の明確化
・ システム運用体制
次に、詳細化した異常系処理手順に基づいて対処シナリオを作成する。また、システム運用手順書の作成に当たっては、それのみで異常系処理の対応が行えるように具体的な作業項目まで落とし込まれていることが望ましい。なお、地域情報プラットフォームが対象とするシステムは、複数のサイト内の部
署・部門、サイトを統括する組織体に跨ることが想定されるため、システム運用体制や緊急連絡先を維持・整備しておくことは言うまでもないことである。

－ 140 －

地域情報プラットフォームガイドライン[手順.01][手順.01] 問題検知・問題の通知受理
問題検知・問題の通知受理[手順.17][手順.17] 正常運用に戻す
正常運用に戻す[手順.02][手順.02] 初期の運転抑制実施
初期の運転抑制実施[手順.03][手順.03] ビジネスプロセス特定
ビジネスプロセス特定[例えば無視出来る問題等]

対処判断？
対処判断？
[要対応]
登録必要？
登録必要？
[不要]

[必要]

[手順.04][手順.04] 運用管理プロセスへ問題登録
運用管理プロセスへ問題登録

サイト内外の判定
サイト内外の判定[他組織と関連][自サイトのみ][手順.05][手順.05] 他組織体に通知
他組織体に通知
対応必要？
対応必要？
[対応必須][通知要組織あり]

全て通知？
全て通知？
[関連組織に通知][対応不要]

対応必要？
対応必要？
[対応必須][手順.06][手順.06] 責任組織体内で真の原因・付随対応
責任組織体内で真の原因・付随対応[原因残][手順.16][手順.16] 正常運用に戻す
正常運用に戻す[対応不要][手順.11][手順.11] 責任組織体内で真の原因・付随対応
責任組織体内で真の原因・付随対応

全原因解決？
全原因解決？

[手順.07][手順.07] 解決報告、解決された旨の報告受理
解決報告、解決された旨の報告受理[手順.08][手順.08] 運転再開方針について他組織体と協議
運転再開方針について他組織体と協議
[未決定]

方針決定？
方針決定？

[再開決定][棄却決定]

対応方針判断対応方針判断[手順.09][手順.09] データの整合の目視確認
データの整合の目視確認[手順.12][手順.12] 処理強制終了
処理強制終了[手順.10][手順.10] 再開処理
再開処理

[手順.13][手順.13] データ修正、整合性補償
データ修正、整合性補償[手順.14][手順.14] 後処理
後処理[手順.15][手順.15] 運用管理プロセス登録を更新、解決
運用管理プロセス登録を更新、解決

[必要]
[不要]

登録必要？
登録必要？

図３．８．１７ 異常系処理の手順例

表３．８．１
手順番号

異常系処理の手順概要

処理内容の概説

処理後に移行する手順番号[手順.01]

問題検知・問題の通知受理[手順.02]

プラットフォーム通信標準仕様で規定される「障害の検知」「即時対応処理」を行った段階に相当し、業務ユニットやミドルウェア等のログチェックや異常検出通知、システム監視ツール（管理機能）
による自動通報や自治体職員等の操作者からの報告などにより異常として検知される。
[手順.02]初期の運転抑制実施[手順.03]

障害から生じる二次障害を避けるため、必要に応じて運転抑制を行なう。特に必要が無い場合は、この限りではない。
[手順.03]

ビジネスプロセスの特定[対処判断]

問題が発生しているビジネスプロセス、対象業務ユニット、対象
情報（受付番号など）などを特定する。問題箇所の特定においては、
業務ユニットやミドルウェア、OS(Operating System)などのログ情報やガイドラインにて述べているモニタリング機能等の情報を利用することにより行うのが一般的である。
[手順.04]

運用管理プロセスへの問題登録
ITIL(Information Technology Infrastructure Library)に基づく－ 141 －

[サイト内外判
断]地域情報プラットフォームガイドライン

運用規定により、標準プロセスとしてインシデント管理や問題管理が定義されている場合は、インシデントとして登録し問題管理に引き継ぐ。
[手順.05]

他組織体（関係組織体）に通知[通知確認]

問題となっているビジネスプロセスが、他サイトに影響する、あるいは他サイト管轄のものである場合は、当該サイトのシステム運用管理者に通知する。
[手順.06]

責任組織体内で真の原因・付随対応[原因解決確認]

問題の検知・通知を受けて、自らの責任範囲で真の原因を特定し、修正する。また、検知・通知された問題に付随して発生した事項についても是正処置を行い、本来の状況に戻す。なお、問題解決の途
上で、別の問題であることを発見した場合は、[手順.05]に戻り、再度調整を行なう。
[手順.07]

解決報告、解決された旨の報告受理[手順.08]

自らの責任範囲で、真の原因を特定・解決し、付随した問題も解決した場合は、[手順.04]で問題をインシデントとして管理している
システム運用管理者に対して、問題が解決した旨を報告する。
[手順.08]

運転再開方針について他組織体と協議[方針決定確認]

上記[手順.07]の結果を受けて、問題解決後の対応策について、協議を行なう。その際、データ等の整合性についても確認するべきである。運転再開方針の協議においては、最終的に処理を棄却するか、再開するかを決定する。
[手順.09]

データの整合の目視確認[手順.10]

処理の再開を決定した場合には、関連するデータの整合性について改めて確認する。なお、データ確認は、[手順.08]でも実施されているが、ここでの確認は再開に向けた最終的な確認である。
[手順.10]

再開処理[登録判断]

システム運用手順書（またはリランマニュアル等）に基づき、処理を再開する。
[手順.11]

責任組織内で真の原因・付随対応[対処方針判断]

問題が、自らの責任範囲に留まる場合、問題の検知・通知を受けて、自らの責任範囲で真の原因を特定し、修正する。検知・通知された問題に付随して発生した事項についても是正処置を行い、本来の状況に戻す。
[手順.12]

処理強制終了[手順.13]

強制的に終了することを決定した場合は、関連する処理途上のものを全て終了させる。
[手順.13]

データ修正、整合性補償[手順.14]

強制的に終了させた場合には、分散環境で処理されたデータについて不整合が発生することが想定される。地域情報プラットフォー
ムでは、トランザクションに関する４要素(原子性,一貫性,隔離性,持続性)を維持する機構は実装（規定）していないため、システム運用手順書等のドキュメントに基づいて、不整合データの修正を行い、整合性を確保する。
[手順.14]

後処理[手順.15]－ 142 －

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

データ修正、整合性補償の後に、残っている後処理等をシステム
運用手順書に基づき実施する。
[手順.15]

運用管理プロセス登録を更新、解決[手順.16]ITIL に基づいて運用規定により標準プロセスとして、インシデン
ト管理や問題管理が定義されている場合は、[手順.04]にてインシデントとして登録された事項は、問題解決が完了した段階で更新する。
[手順.16][手順.17]

正常運用に戻す[手順.01]

障害から生じる二次障害を避けるため、[手順.02]で運転抑制を行なった場合は、抑制状態を解き、正常な運用に戻す。

（３） 異常系処理手順における補償・回復処理の例外事項
地域情報プラットフォームのプラットフォーム通信標準仕様では、副次的な問題の発生、事態の複雑化を避けるために、自動化された異常系処理ではビジネスプロセスの停止・中断迄を実施し、その後の一連の回復処理については全て手動で対応することを推奨している。
しかし、次のようなケースにおいては、より効率的な運用管理が可能となることから、例外事項として補償・回復処理の自動化を行うことも許容する。
例外事項１：プラットフォーム通信標準仕様外での補償・回復処理の自動化
プラットフォーム通信標準仕様の範囲外で実施されるビジネスプロセスであり、かつ、異常系処理による不整合を発生させないとの保証がある場合においては、補償・回復処理を自動化させることができる。
例外事項２：同一運用ポリシーによる限定的範囲での補償・回復処理の自動化
自治体内等の組織体で、同一の運用ポリシーに基づいて運用されている同一サイト間での通信であり、かつ、異常系処理による不整合を発生させないとの保証がある場合においては、補償・回復処理を自動化させることができる。
ここで、例外事項として認める補償・回復処理について簡単に説明する。補償・回復処理とは、異常が発生した場合に、既に実行された処理をキャンセルするなどにより、一連の処理が行われる前の状態に戻す処理である。例えば、複数のサイトに跨って実施されるトランザクションにおいては、従来から 2
フェーズコミットメントが一般的な分散トランザクションの手法である。この 2 フェーズコミットメン
トでは、サービス要求側の業務ユニットが、他の複数サイト全てに対して必要な更新処理を行い、コミッ
トメントが可能か否かを確認した後、一斉に複数サイトの更新についてコミットメントを実施する方式である。この方式では、通常、データ更新をする複数のサイトは、階層的な呼出、呼び出しのネストがない同等・等価レベルであることが好ましい。
Web サービスの分野においても、この 2 フェーズコミットメントを実施する方法も存在する。しかし
WS-BPEL に代表される様に、１つのサービス呼出が他のサービス呼出を連鎖的に起動し、2 フェーズコミッ
トメントにおけるコミットメントを実施するまでが長時間となる場合が想定される。その場合、更新に対するロック等も実施されるため、分散トランザクションのスループットを指数関数的に悪化させてしまう問題が発生する。そのため、このような長時間に亘って生存するトランザクションの問題を解決するために、ロングトランザクションという考え方を導入した方式も提案されている。ロングトランザク
ションでは、2 フェーズコミットメントの実行をせず、更新処理等の要求を受けた段階で、各サイトは一度、更新を完了させてしまう。その後、ロングトランザクションの最終段階で、トランザクションを完結させるには問題となる事象が確認された場合、このロングトランザクションの途上で実施した更新処理に関して、キャンセル等の処理を実施し、最終的にはトランザクションを無効（失敗）とする方式である。
－ 143 －

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

３．８．４ 異常系処理における留意事項（１） MEP 処理系で滞留するビジネスプロセスの処置
プラットフォーム通信標準仕様の「６.３.７節

開始側の MEP 実行系レベル以上の障害検知、即時対応方法」では、MEP 処理系でタイムアウトの検出が出来ない場合、上位の業務ユニットレベルで応答の有無に対するタイムアウト判断を行なうよう推奨している。しかし、MEP 処理系ではタイムアウトが検出できないために、半永久的に応答待ちの状態を維持し続ける。この様な状況が複数のプロセスで発生し、これを処置しないまま運転を継続すると、MEP 処理系を実装する計算機資源を占領し、その結果、応答性能の悪化、他の処理に対する不必要なタイムアウトの誘発等の悪循環を発生させることになる。そこで、この問題に対する対処方法として、以下の方式を提案する。
(a) 独自例外処理による対応
コマンドレベルで操作可能な MEP 処理系であれば、外部から MEP 処理系の不必要なプロセスを終了（Kill）させる様なバッチプログラムを作成し、業務ユニットレベルがタイムアウトを検知した段階で、このプログラムを起動させる。
(b) 人間系による対応
コマンドレベルでの操作が不可能な MEP 処理系については、業務ユニットレベルからのタイムアウト
通知をシステム運用管理者が確認し、マニュアル操作（人間系での操作）により不必要なプロセスを終了（Kill）させる。なお、マニュアル操作も難しい場合には、MEP 処理系だけ計画停止を定義し、計画停止段階で関連データ等の削除を強制的に行なう。
（２） システム実行状況の監視（モニタリング機能および運用管理ツールとの連携）システムの実行状況の監視において、MEP 実行系製品の管理画面、コンソール画面だけでは、限定的な
BPM 処理のみが対象となり、通信相手のビジネスプロセスが処理中で、その結果待ちとなっているのか、あるいはタイムアウトになっているのかが判断出来ない場合がある。その様な対処としては、モニタリ
ング機能による処理のトラッキングなどが必要になってくる。また、システム上の不具合を早期に発見するために運用管理ツールと連携した運用を強く推奨する。

－ 144 －

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

付録１

Audit、インタフェースに関する詳細定義（１）概要
付録として、Audit に関する各種の推奨形式について記載する。記載するものは、以下の通りである。
この奨励形式と等価で別な形式のものがある場合は、本方式以外の実装も許容される。
(a)Audit 取得モデルにおけるクエリの形式(b)BPM(Business Process Management) Audit および WS アプリケーション Audit の形式(c)メッセージ Audit の形式(d)Audit 項目のセマンティクスを定義する情報モデルと構成要素(e)Audit 取得モデルにおける推奨インタフェース(f)各メッセージに関する事例（２）Audit 取得モデルにおけるクエリの形式
Audit 取得モデルに置けるクエリの情報項目を表．付１．１に記載する。なお、基数制約は UML(Unified
Modeling Language)の表記を取り入れており、必ず１つ存在する場合を「1」、オプションとして存在す
る場合もある、しない場合もある場合は「0..1」、一つ以上任意の場合を「1..*」とする。

表．付１．１

Audit 取得モデルにおけるクエリに関する推奨事項

連

区分

区分直下のクエリ

基数

番

(親区分)

項目

制約

1

auditQuery

説明

-

1

クエリのルートエレメント。[指定必要]

-

0..1

当該 Audit 提供が収集しているエンジンの Audit 全てを対象(この親区分はトップ)2

engineAll(この親区分はとする。engines タグと二者択一である。子エレメントとし

auditQuery)て、少なくとも duration と filter タグのどちらか一つ以上を設定する。duration と filter タグの両方を設定することも可能である。
複数の検索条件を設定した場合、それらの AND 条件とする。
オプショナルの属性 “limit”を指定すると、各エンジンに対応
する検索結果の数に上限が設けられる。limit 属性を用いる場
合は、エンジン ID ごとに、エンジンで検索された結果の内、時刻の古い Audit から時刻順に最大 limit 個を検索結果とする。limit を設定しない場合は、検索結果に合致した全てのAudit を時刻順に返す。[指定選択]

3

4

engines-

0..1

当該 Audit 提供が収集しているエンジンのうち、engine タグ(この親区分はで指定するエンジンの Audit のみを対象とする。

auditQuery)engineAll タグと二者択一である。[指定選択]

engine-1..*

取得対象とするエンジンを指定する。必須の属性 “engineId”
で検索対象とするエンジンのエンジン ID を指定する。

(この親区分は engines)

オプショナルの属性 “limit”を指定すると、各エンジンに対応
する検索結果の数に上限が設けられる。limit 属性を用いる場
合は、エンジン ID ごとに、エンジンで検索された結果の内、時刻の古い Audit から時刻順に最大 limit 個を検索結果とする。limit を設定しない場合は、検索結果に合致した全ての－ 145 －

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

Audit を時刻順に返す。少なくとも sequenceNo と duration
タグのどちらか一つ以上を設定する。sequenceNo とduration タグの両方を設定することも可能である。
複数の検索条件を設定した場合、それらの AND 条件とする。
[指定必要]
5

sequenceNo

-

0..1

検索対象とする sequenceNo の範囲を指定する。gt タグとle タグの両方が設定された場合は、それらの AND 条件とす

(この親区分は engine)る。audit データの sequenceNo が条件を満たすものを検索結果とする。[指定選択]
6

gt

1

この値より大きな sequenceNo を検索対象とする(greaterthan)。[指定必要]

7

le

0..1

この値以下の sequenceNo を検索対象とする(less than orequal to)。[指定選択]

8

duration-

0..1

当該期間に発生した Audit データを検索する。from タグと(この親区分はto タグ両方の条件を満たすものを検索結果とする。

engineAll、engine)[指定選択、但し、親区分が engineAll の場合は必要]

9

from

1

この値を含む時刻以降に発生した audit データを検索対象とする。[指定必要]

10

to

1

この値を含む時刻以前に発生した audit データを検索対象とする。[指定必要]

11

filter-0..1

定した場合は、それらの OR 条件とする。[指定選択](この親区分は12

engineAll、engine)

Audit データの activityId で検索する。複数の type タグを設

type

1..*

この値を、activityId 文字列の最後の子エレメント名として持つ Audit データを検索対象とする。[指定必要]
例えば activityId が“/process[1]/scope[1]/sequence[1]/invoke[1]” のとき、
type タグの値が “scope” → 該当しない。
type タグの値が “invoke” → 該当する。

（３） BPM Audit および WS アプリケーション Audit に関する情報項目
モニタリング機能はオプションであるが、モニタリング機能を実装する場合、この BPM Audit およびWS アプリケーション Audit の生成は必要となる。
BPM Audit および WS アプリケーション Audit に格納する情報項目を表．付１．２に定義する。ここで、図．付１．３の情報モデルに基づき、WS アプリケーション Audit は、BPM Audit の形式と同一とし、WS
アプリケーションを擬似的に WS-BPEL(Web Services Business Process Execution Language 2.0)定義で表現できることを前提としているため、表．付１．２は、WS アプリケーション Audit と BPM Audit との間で同じコンテキストとして扱われ、共用されている。表．付１．２で各項目は階層的に表現され、表中の区分と親区分はそれぞれ注目する区分とその親に相当する区分を表す。項目のルートは「トップ」
を記してある。またリソース項目が「-」の欄は、その区分自体の基数制約を表す。
表．付１．２を元に、図．付１．１に推奨する BPM Audit、WS アプリケーション Audit の XML Schema
表現を記す。この推奨 BPM Audit 形式定義では、ルートエレメントとして “BPM Audit”を用いる。BPM Auditの子エレメントとして “processInstance” を複数個格納可能である。
また、BPM Audit において、推奨方式である SOAP(Simple Object Access Protocol)を用いず、WSDM(WebServices Distributed Management 1.1)等により実装する場合は、図．付１．１を拡張要素として利用すれば良い。
－ 146 －

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

表．付１．２

BPM Audit、WS アプリケーション Audit データに関する推奨事項

連

区分

区分直下の監視

基数

番

(親区分)

対象リソース項目

制約

-

1..*

1

2

processInstance説明
BPM Audit ないし WS アプリケーション Audit 1 個には、複(この親区分はトップで、数の ProcessInstance 情報を格納可能とする。

processInstance タグを[指定必要]

持つ。)

sequenceNo

1

シーケンス番号。Audit データ実装時特有の値。
Query-Response で Audit データを取得する際に Audit を区別するために用いる。[指定必要]

3

processInstanceId

0..1

プロセスインスタンス ID。BPM Audit の場合は必須。
[指定選択]

4

createdDate

0..1

プロセスインスタンスの生成日時。BPM Audit のときは必須。InnerState の属性を継承。[指定選択]

5

updatedDate

0..1

プロセスインスタンスの更新日時。BPM Audit のときは必須。InnerState の属性を継承。[指定選択]

6

status1

状態。プロセスの実行中ないし終了を表す。InnerState の属性を継承。[指定必要]

7

processDefId

1

プロセス定義名。ProcessDefinition の属性を使用。
[指定必要]

8

BPELActivityInstance-1

一形式で扱う。[指定必要](この親区分は9

processInstance で、

date

1

activity タグを持つ。)
10

BPELActivityInstance と WSApplicationActivityInstance を同

アクティビティインスタンスの発生日時。ActivityInstanceの属性を継承。[指定必要]

activityId

1

BPM Audit の場合は BPELActivityDefinition の activityId 属性、WS アプリケーション Audit の場合はActivityDefinitionForWS の checkpointId。[指定必要]

11

status1

アクティビティの実行中(開始)ないし終了を表す。
InnerState の属性を使用。[指定必要]

12

message-0..1(この親区分は
13

BPELActivityInstance でメッセージ。指定選択ではあるが、指定可能時は指定する。
[指定選択]

messageId

0..1

message タグを持つ。)

メッセージ ID。BPM Audit でメッセージ生成が伴わない
BPM Activities の場合、メッセージ ID が存在しない。
[指定選択]

14

messageContents

0..1

メッセージ内容。メッセージを圧縮し、base64encoding したもの。[指定選択]

15

type

0..1

メッセージタイプ。出力メッセージ、入力メッセージのど
ちらかを指定する。[指定選択]

16

createdDate

0..1

メッセージの生成日時。[指定選択]

17

sentDate

0..1

メッセージが送信された日時。[指定選択]

18

receivedDate

0..1

メッセージが受信された日時。[指定選択]

19

processedDate

0..1

メッセージが処理された日時。[指定選択]

-

0..1

Scope インスタンス。[指定選択]

20

ScopeInstance－ 147 －

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

21(この親区分はactivityId

1

processInstance で、

BPELActivityDefinition の属性を使用。スコープを指定する
ために Process の activityId を指定する。[指定選択]

scope タグを持つ。)
22

variable-0..*

Variable のインスタンス。[指定選択]

23(この親区分はvalue

1

変数の値。[指定選択]

ScopeInstance で、

updatedDate1

変数の更新日時。[指定選択]

24

variable タグを持つ。)

variableName

1

変数名。VariableDefinition の属性を利用。[指定選択]

25

correlation

-

0..*

Correlation インスタンス。[指定選択]26(この親区分はPropertyVariable1

correlation 値。[指定選択]

27

ScopeInstanceactivityId

1

Correlation を更新したアクティビティのアクティビティ

で 、

correlation タグを持つ。)

ID。[指定選択]

28

updatedDate1

更新日時。[指定選択]

29

correlationSetName

1

correlationSet の名称。CorrelationDefinition の属性を使用。
[指定選択]

30

propertyName

1

プロパティ名。CorrelationPropertyDefinition のpropertyName 属性を使用。[指定選択]

31

BPELEngine-

1

BPEL エンジン。[指定必要]

32(この親区分はengineId

1

エンジン ID。Engine の属性を継承。[指定必要]

-

1..*

実行体。BPM 機能が複数の実行体を用いて構成・実行されprocessInstance で、engine タグを持つ。)
33

34

machine(この親区分はるときに、それらの 1 台以上の情報を Audit データに設定すprocessInstance で、る。[指定必要]

machine タグを持つ。)

machineId

1

実行体 ID。[指定必要]（注）表．付１．２は階層構造を含まず、並列化されて表現されている。
<?xml version="1.0" encoding="utf-8"?><xsd:schema
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified"><xsd:element name="BPMAudit" type="BPMauditType"/><xsd:complexType name="BPMauditType"><xsd:sequence><xsd:element minOccurs="1" maxOccurs="unbounded" name="processInstance"><xsd:complexType><xsd:sequence><xsd:element type="xsd:unsignedLong" name="sequenceNo"></xsd:element><xsd:element minOccurs="0" name="processInstanceId"><xsd:simpleType><xsd:restriction base="xsd:string"><xsd:maxLength value="128"/></xsd:restriction></xsd:simpleType></xsd:element>－ 148 －

地域情報プラットフォームガイドライン<xsd:element minOccurs="0" type="xsd:dateTime" name="createdDate"></xsd:element><xsd:element minOccurs="0" type="xsd:dateTime" name="updatedDate"></xsd:element><xsd:element name="status"><xsd:simpleType><xsd:restriction base="xsd:string"><xsd:enumeration value="running"/><xsd:enumeration value="finished"/></xsd:restriction></xsd:simpleType></xsd:element><xsd:element name="processDefId"><xsd:simpleType><xsd:restriction base="xsd:string"><xsd:maxLength value="128"/></xsd:restriction></xsd:simpleType></xsd:element><xsd:element name="activity"><xsd:complexType><xsd:sequence><xsd:element type="xsd:dateTime" name="date"></xsd:element><xsd:element type="xsd:string" name="activityId"></xsd:element><xsd:element name="status"><xsd:simpleType><xsd:restriction base="xsd:string"><xsd:enumeration value="begin"/><xsd:enumeration value="end"/></xsd:restriction></xsd:simpleType></xsd:element><xsd:element minOccurs="0" maxOccurs="1” name="message"><xsd:complexType><xsd:sequence><xsd:element type="xsd:string" name="messageId"></xsd:element><xsd:element type="xsd:base64Binary"name="messageContents"></xsd:element><xsd:element name="type"><xsd:simpleType><xsd:restriction base="xsd:string"><xsd:enumeration value="incoming"/><xsd:enumeration value="outgoing"/></xsd:restriction></xsd:simpleType></xsd:element><xsd:element minOccurs="0" type="xsd:dateTime"－ 149 －

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

name="createdDate"></xsd:element><xsd:element minOccurs="0" type="xsd:dateTime"
name="sentDate"></xsd:element><xsd:element minOccurs="0" type="xsd:dateTime"
name="receivedDate"></xsd:element><xsd:element minOccurs="0" type="xsd:dateTime"
name="processedDate"></xsd:element></xsd:sequence></xsd:complexType></xsd:element></xsd:sequence></xsd:complexType></xsd:element><xsd:element minOccurs="0" name="scope"><xsd:complexType><xsd:sequence><xsd:element type="xsd:string" name="activityId"></xsd:element><xsd:element minOccurs="0" maxOccurs="unbounded" name="variable"><xsd:complexType><xsd:sequence><xsd:element type="xsd:base64Binary" name="value"></xsd:element><xsd:element type="xsd:dateTime" name="updatedDate"></xsd:element><xsd:element type="xsd:string" name="variableName"></xsd:element></xsd:sequence></xsd:complexType></xsd:element><xsd:element minOccurs="0" maxOccurs="unbounded" name="correlation"><xsd:complexType><xsd:sequence><xsd:element type="xsd:string" name="propertyVariable"></xsd:element><xsd:element type="xsd:string" name="activityId"></xsd:element><xsd:element type="xsd:dateTime" name="updatedDate"></xsd:element><xsd:element type="xsd:string" name="correlationSetName"></xsd:element><xsd:element type="xsd:string" name="propertyName"></xsd:element></xsd:sequence></xsd:complexType></xsd:element></xsd:sequence></xsd:complexType></xsd:element><xsd:element name="engine"><xsd:complexType><xsd:sequence><xsd:element type="xsd:string" name="engineId"></xsd:element>－ 150 －

地域情報プラットフォームガイドライン</xsd:sequence></xsd:complexType></xsd:element><xsd:element minOccurs="1" maxOccurs="unbounded" name="machine"><xsd:complexType><xsd:sequence><xsd:element type="xsd:integer" name="machineId"></xsd:element></xsd:sequence></xsd:complexType></xsd:element></xsd:sequence></xsd:complexType></xsd:element></xsd:sequence></xsd:complexType></xsd:schema>

図．付１．１ BPM Audit および WS アプリケーション Audit の XML Schema（４）メッセージ Audit に関する情報項目
メッセージ Audit の生成はオプションである。但し、モニタリング機能をより高度に利用する場合、
例えば、(i)ワンストップサービス時に発生するエラーについて捕捉する、(ii)運用状況を捕捉する、(iii)各種 KPI(Key Performance Indicator)を設定しサービスを改善する等の場合、サービスの実行状況を直接反映するメッセージ Audit が生成されることを奨励する。
メッセージ Audit に格納する情報項目を表．付１．３に示す。項目は階層的に表現され、表中の区分と親区分はそれぞれ注目する区分とその親に相当する区分を表す。項目のルートは「トップ」を記してある。またリソース項目が「-」の欄は、その区分自体の基数制約を表す。
表．付１．２を元に、図．付１．２に推奨メッセージ Audit の XML Schema 表現を記す。この推奨メッ
セージ Audit 形式定義では、ルートエレメントとして “messageAudit” を用いる。messageAudit の子エレメントとして “message” を複数個格納可能である。また、メッセージ Audit において、推奨方式である SOAP 形式を用いず、WSDM 等により実装する場合は、図．付１．１を拡張要素として利用する。
表．付１．３

メッセージ Audit データに関する推奨事項

連

区分

区分直下の監視対象リ

基数

番

(親区分)

ソース項目

制約

1

message-2(この親区分はトップで、 sequenceNo

説明

1..*

メッセージ。[指定必要]

1

クエリの開始点。デフォルトは 0 が指定される。

message タグを持つ。)[指定必要]

3messageId

1

メッセージ ID。[指定必要]

4

relatesTo

1

関連するメッセージの messageId で、共通ヘッダに指定されたものがセット。存在しない場合は、タグのみ存在
し、コンテンツは指定しない。[指定必要]

5

messageContents

1

メッセージ内容。メッセージを圧縮し、Base64 エンコー
ディングしたもの。[指定必要]

6

type

1

メッセージタイプ。出力メッセージ、入力メッセージのどちらかを指定する。[指定必要]－ 151 －

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

7

createdDate

0..1

メッセージの生成日時。[指定選択]

8

sentDate

0..1

メッセージが送信された日時。[指定選択]

9

receivedDate

0..1

メッセージが受信された日時。[指定選択]

10

processedDate

0..1

メッセージが処理された日時。[指定選択]-

1

エンドポイント情報(URI(Uniform Resource Identifier)に

11

endpoint

関する)。[指定必要](この親区分は message
12で、endpoint タグを持

uri

1

つ。)

Endpoint の URI。[指定必要]
これは明示的な url のタグは存在せず、endpoint のデータ型としてされる。

13

PartnerLink

-

0..1

(この親区分は message

エンドポイント情報(partnerLink に関する)。
[指定選択]

14

で、partnerLinkInfo タグ

partnerLinkName

1

partnerLink の name 属性。[指定選択]

15

を持つ。)

portTypeName

1

portType の name 属性。[指定選択]

operation1

operation の name 属性。[指定選択]16（注）表．付１．３は階層構造を含まず、並列化されて表現されている。
<?xml version="1.0" encoding="utf-8"?><xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified"><xsd:element name="messageAudit" type="messageAuditType"/><xsd:complexType name="messageAuditType"><xsd:sequence><xsd:element minOccurs="1" maxOccurs="unbounded" name="message"><xsd:complexType><xsd:sequence><xsd:element type="xsd:unsignedLong" name="sequenceNo"></xsd:element><xsd:element type="xsd:string" name="messageId"></xsd:element><xsd:element type="xsd:string" name="relatesTo"></xsd:element><xsd:element type="xsd:base64Binary" name="messageContents"></xsd:element><xsd:element name="type"><xsd:simpleType><xsd:restriction base="xsd:string"><xsd:enumeration value="incoming"/><xsd:enumeration value="outgoing"/></xsd:restriction></xsd:simpleType></xsd:element><xsd:element minOccurs="0" type="xsd:dateTime" name="createdDate"></xsd:element><xsd:element minOccurs="0" type="xsd:dateTime" name="sentDate"></xsd:element><xsd:element minOccurs="0" type="xsd:dateTime" name="receivedDate"></xsd:element><xsd:element minOccurs="0" type="xsd:dateTime" name="processedDate"></xsd:element><xsd:element type="xsd:anyURI" name="endpoint"></xsd:element><xsd:element minOccurs="0" name="partnerLinkInfo"><xsd:complexType><xsd:sequence>－ 152 －

地域情報プラットフォームガイドライン<xsd:element type="xsd:string" name="partnerLinkName"></xsd:element><xsd:element type="xsd:string" name="portTypeName"></xsd:element><xsd:element type="xsd:string" name="operation"></xsd:element></xsd:sequence></xsd:complexType></xsd:element></xsd:sequence></xsd:complexType></xsd:element></xsd:sequence></xsd:complexType></xsd:schema>

図．付１．２ メッセージ Audit の XML Schema（５）Audit 項目のセマンティクスを定義する情報モデル
Audit の各項目は、図．付１．３に定義されるモニタリングすべきプロセス、またはサービスの情報モ
デルに基づく。この分野では、適当な既存情報モデルは存在していないため、本仕様独自の情報モデルである。この情報モデルでは定義、実行、実行履歴に関する情報モデルのすべてを含んでおり、実行時に BPM Audit、WS アプリケーション Audit、メッセージ Audit として出力される情報は、概ね、この情報モデルの一部分をインスタンスとしている。

－ 153 －

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

図．付１．３ プロセス、サービスに関する情報モデル－ 154 －

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

図．付１．３に示した情報モデルにおける構成要素の概要を表．付１．４に示す。

表．付１．４連

情報モデルにおける構成要素

クラス名

概要説明

番
1

ActivityDefinitionForWS

非 WS-BPEL アプリケーションのアクティビティ定義。本来は WS-BPEL
で定義されていない WS アプリケーションの動作を擬似的に WS-BPEL で記述したときの、アクティビティに関する定義。

checkpointId

非 WS-BPEL アプリケーションのアクティビティ定義を WS-BPEL 定義内
で一意に識別するための識別子。

2

ActivityInstance

アクティビティインスタンス。WS-BPEL 仕様で定義される basic activitiesと structured activities のインスタンスに相当する。

date
3

BPELActivityDefinition

アクティビティインスタンスが発生した日時。
WS-BPEL アクティビティ定義。WS-BPEL 定義におけるアクティビティ
に関する定義に相当する。

activityId

WS-BPEL アクティビティ定義を WS-BPEL 定義配下で一意に識別するための識別子。

activityType

WS-BPEL 仕様で定義されるアクティビティの種類を表す。

activitySequence

アクティビティ順序。同一の親アクティビティを持つアクティビティ間の順序関係を表す。

4

BPELActivityInstance

WS-BPEL アクティビティインスタンス。WS-BPEL エンジン上でWS-BPEL 定義が実行されるときに生成される、WS-BPEL アクティビティ
定義に対応するインスタンス。

5

BPELDefinition

WS-BPEL 定義。WS-BPEL を用いて記述したプロセス定義であり、
WS-BPEL 処理系(WS-BPEL エンジンとも呼ぶ)で実行される。

6

BPELDefinitionForWS

非 WS-BPEL アプリケーションの WS-BPEL 定義。WS アプリケーションの動作を擬似的に WS-BPEL で記述したものである。この定義がそのまま
WS アプリケーションで実行されるのではない。

7

BPELEngine

WS-BPEL エンジン。WS-BPEL を処理する処理系の実装のこと。

8

BPELScopeDefinition

BPELscope 定義。WS-BPEL アクティビティ定義の内、scope 定義に相当する。

9

BusinessKey
keyType

業務キー。業務主キーと業務関連キーの総称。
キー名。業務キーの名称。非 WS-BPEL アプリケーションの WS-BPEL 定
義配下で一意。

keyValue
10

BusinessPrimaryKey

キー値。業務キーの値。
業務主キー。業務実行上、業務インスタンスを識別する ID 等キーとして用いる情報。

11

BusinessProperty
businessPropertyType

プロパティ。業務における、業務主キーと業務関連キー以外の情報を扱う。
プロパティの種別。非 WS-BPEL アプリケーションの WS-BPEL 定義配下
で一意。

businessPropertyValue
12

BusinessRelatedKey

プロパティの値。
業務関連キー。業務実行上、業務主キーと関連した、業務インスタンスを識別する ID 等のキーとして用いられる情報。

13

BusinessRelationInformation

関係づけ情報。業務主キーと業務関連キーを関係づける。

－ 155 －

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

14

Communication

ある通信路に関する、送信側エンドポイントと受信側エンドポイントの対を定義する。

15

16

Correlation
correlationValuecorrelation 値。

activityId

Correlation 値を更新したアクティビティのアクティビティ ID。

updatedDate

更新日時。

CorrelationDefinition
correlationSetName

17

18

Correlation 定義で定義されるアクティビティのインスタンス。

CorrelationHistory

Correlation 定義。WS-BPEL 定義の内、correlation 定義を扱う。
correlationSet の名称。WS-BPEL 定義配下で一意。
Correlation 履歴。Correlation 情報を保存する。

correlationValuecorrelation 値。

activityId

アクティビティ ID。

updatedDate

更新日時。

CorrelationPropertyDefinition

CorrelationProperty 定義。WS-BPEL において、correlation で用いる
property を定義する。

propertyName

プロパティ名。WS-BPEL の property の name 属性。

propertyType

プロパティ型名。WS-BPEL の property の type 属性。

messageTypecorrelation で用いるメッセージタイプ。

query

メッセージタイプで指定されたメッセージから correlation で用いる文字列を抽出するための検索文字列。

19

CrossSitesProcessDefinition

仮想プロセス定義。要素のプロセスを定義するプロセス定義を複数集め、それらを含み、かつ統合する形で導出されるプロセスの等価プロセス定義
であり、必ずしもプロセスを形式化された言語で記述したものとは限らない。

crossSitesProcessName
20

21

22

CrossSitesProcessHistory

仮想プロセス名。グローバルで一意。
仮想プロセス履歴。仮想プロセス状態の履歴を管理する。

updatedDate

更新日時。

status状態。実行中ないし終了。

CrossSitesProcessStatus

仮想プロセス状態。仮想プロセス定義のインスタンスに相当する。

createdDate

生成日時。

updatedDate

更新日時。

status状態。実行中ないし終了。

Endpoint

エンドポイント。Web サービスのインタフェースが実装された通信上の端点。partnerLinkName、portTypeName、uri の組でグローバルに一意。

23

partnerLinkName

WS-BPEL で定義される partnerLink の name 属性。

portTypeName

WSDL で定義される portType の name 属性。

uribinding 情報で定義される、このエンドポイントの URI。

operation

WSDL で定義される operation の name 属性。

inputMessageType

このエンドポイントに入力されるメッセージのメッセージタイプ。

outputMessageType

このエンドポイントが出力するメッセージのメッセージタイプ。
エンジン。処理系実装の総称であり、WS-BPEL を対象とする場合はEngineWS-BPEL エンジン、Web サービスを対象とする場合は Web サービスエンジンと呼ぶ。エンジンは 1 個以上の実行体で構成される。
engineId

処理系実装を識別するための識別子記述であり、グローバルで一意。

－ 156 －

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

24

履歴。業務ユニット等のアプリケーションでの状態を表すインスタンスをHistory

履歴として格納する。

25

createdDate

履歴の発生日時。

updatedDate

履歴の更新日時。

status状態。実行中か終了かを表す。

InnerExecutingUnit

内部実行単位。WS-BPEL におけるプロセスインスタンスに相当し、WS
アプリケーションを実行したとき業務のインスタンスを識別する単位。

26

InnerState内部状態。プロセスインスタンスと内部実行単位の親クラスであり、業務実行時の内部状態を表す。

27

createdDate

プロセスインスタンスに相当する内部状態の生成日時。

updatedDate

業務遂行に伴い内部状態が変化したときの変更日時。

status内部状態。実行中ないし終了。

Machine実行体。エンジンを構成するハードウェアのうち、1 つの OS の管理下にある固まりの単位。

machineId
28

Message

実行体を識別するための識別子で、グローバルで一意。
メッセージ。Web サービスのインタフェースの WSDL 定義に基づき、対をなすエンドポイント間でやりとりされる XML 形式の記述のこと。

messageId

メッセージ ID。メッセージのインスタンスを識別するための識別子。グローバルで一意。

29

messageContents

メッセージ内容。通信路を流れた SOAP メッセージの中身。

type

メッセージタイプ。

createdDate

メッセージの生成日時。

sentDate

メッセージが送信された日時。

receivedDate

メッセージが受信された日時。

processedDate

メッセージが処理された日時。

PartialCrossSitesProcessDefinition

部分仮想プロセス定義。仮想プロセス定義の一部分に相当する業務プロセ
ス定義。

30

ProcessDefinition
processDefinitionId

プロセス定義。プロセスを形式化された言語で記述したもの。
プロセス定義名。WS-BPEL で記述されるプロセス定義を識別するための識別子。エンジン ID との組で一意。

31

ProcessHistory

プロセス履歴。プロセスインスタンスの履歴を管理する。

32

ProcessInstance

プロセスインスタンス。プロセスを WS-BPEL エンジンに割り付け、インスタンス化したもの。WS-BPEL 定義の initial start activity 実行時に生成される業務プロセス単位。

processInstanceId

プロセスインスタンスを識別するための識別子で、WS-BPEL 定義配下でグローバルに一意。

33

ScopeHistory
createdDate

Scope 履歴。Scope インスタンスの履歴を管理する。
生成日時。

34

ScopeInstance

Scope インスタンス。

35

Variable

WS-BPEL 実行時の variable 値。

36

value

変数の値。

updatedDate

更新日時。

VariableDefinition
variableName

Variable 定義。WS-BPEL 定義における、variable タグに相当する。
variable の name 属性。BPELscope 定義配下で一意。

－ 157 －

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

messageType37

variable の messageType 属性。
Variable 履歴。Variable の履歴を管理する。

VariableHistory
value

値。

updatedDate

更新日時。

38

WebServiceHistory

WebService 履歴。内部実行状態の履歴を管理する。

39

WSApplication

WS アプリケーション。Web サービスのインタフェースを持つアプリケー
ションで、WS-BPEL エンジンから呼び出されるもの。

40

WSApplicationActivityInstance

WS アプリアクティビティインスタンス。WS アクティビティ上のインス
タンスを表す。

（６）インタフェース
図．付１．４に BPM Audit、WS アプリケーション Audit、メッセージ Audit を取得する場合の推奨イン
タフェースの WSDL(Web Services Description Language)、図．付１．５に XML Schema を記す。
図．付１．４の推奨インタフェースは、全て同期型のクエリ－レスポンス型で実装される。この奨励
インタフェース定義以外にも、WSDM 等により同等機能実装することは許容される。WSDM を利用する場合、当該インタフェース相当のインタフェース定義を公開しなければならない。また、当該インタフェース
に対して、新たに付加価値を付けたインタフェース、例えば、「メッセージ Audit 一括送信」機能および「メッセージ Audit 送信」機能を Web サービスとして実現される場合も、これらサービスの WSDL は新たに公開されなければならない。
<?xml version="1.0" encoding="UTF-8"?><wsdl:definitions name="audit-wsdl"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" ><wsdl:types><xsd:schema><xsd:include schemaLocation="BPMAudit.xsd" /><xsd:element name="BPMAudit" type="BPMauditType" /></xsd:schema><xsd:schema><xsd:include schemaLocation="MessageAudit.xsd" /><xsd:element name="MessageAudit" type="messageAuditType" /></xsd:schema><xsd:schema><xsd:include schemaLocation="query.xsd" /><xsd:element name="auditQuery" type="auditQueryType" /></xsd:schema></wsdl:types><wsdl:message name="BPMAudit-INPUT"><wsdl:part name="BPMAudit-INPUT" element="auditQuery" /></wsdl:message><wsdl:message name="BPMAudit-OUTPUT"><wsdl:part name="BPMAudit-OUTPUT" element="BPMAudit" /></wsdl:message><wsdl:message name="MessageAudit-INPUT">－ 158 －

地域情報プラットフォームガイドライン<wsdl:part name="MessageAudit-INPUT" element="auditQuery" /></wsdl:message><wsdl:message name="MessageAudit-OUTPUT"><wsdl:part name="MessageAudit-OUTPUT" element="MessageAudit" /></wsdl:message><wsdl:portType name="IF-ADMIN-01PT"><wsdl:operation name="IF-ADMIN-01"><wsdl:input name="IF-ADMIN-01-INPUT" message="BPMAudit-INPUT" /><wsdl:output name="IF-ADMIN-01-OUTPUT" message="BPMAudit-OUTPUT" /></wsdl:operation></wsdl:portType><wsdl:portType name="IF-ADMIN-02PT"><wsdl:operation name="IF-ADMIN-02"><wsdl:input name="IF-ADMIN-02-INPUT" message="MessageAudit-INPUT" /><wsdl:output name="IF-ADMIN-02-OUTPUT" message="MessageAudit-OUTPUT" /></wsdl:operation></wsdl:portType></wsdl:definitions>

図．付１．４

インタフェースの WSDL

推奨案ではあるが、モニタリング機能のインタフェース命名規則として、図．付１．４で記される様に全て”IF-ADMIN”と称するプリフィックスを持つ。図．付１．５には、図．付１．４から参照されるク
エリの推奨 XML Schema を示す。このタグ名の説明は表．付１．１を参照願いたい。
<?xml version="1.0" encoding="utf-8"?><xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified"><!-- TOP --><xsd:element name="auditQuery" type="AuditQueryType" /><xsd:complexType name="AuditQueryType"><xsd:choice><!-- engineAll か engines のいずれかを選択 --><xsd:element name="engineAll" type="EngineAllType" /><xsd:element name="engines" type="EnginesType" /></xsd:choice></xsd:complexType><xsd:complexType name="EngineAllType"><xsd:sequence><xsd:element name="duration" type="DurationType" /><xsd:element name="filter" type="FilterType" minOccurs="0" maxOccurs="1" /></xsd:sequence>－ 159 －

地域情報プラットフォームガイドライン<xsd:attribute name="limit" type="xsd:int" /></xsd:complexType><xsd:complexType name="EnginesType"><xsd:sequence><!-- 複数の処理系(エンジン)ごとの query を発行可能とする --><xsd:element name="engine" type="EngineType" minOccurs="1" maxOccurs="unbounded" /></xsd:sequence></xsd:complexType><xsd:complexType name="EngineType"><xsd:sequence><!-- sequenceNo か duration の少なくとも 1 つを必須とする。←XSD として表現できていない --><xsd:element name="sequenceNo" type="SequenceNoType" minOccurs="0" maxOccurs="1" /><xsd:element name="duration" type="DurationType" minOccurs="0" maxOccurs="1" /><xsd:element name="filter" type="FilterType" minOccurs="0" maxOccurs="1" /></xsd:sequence><xsd:attribute name="limit" type="xsd:int" /><xsd:attribute name="engineId" type="xsd:string" use="required" /></xsd:complexType><xsd:complexType name="SequenceNoType"><xsd:sequence><xsd:element name="gt" type="xsd:unsignedLong" /><xsd:element name="le" type="xsd:unsignedLong" minOccurs="0" maxOccurs="1" /></xsd:sequence></xsd:complexType><xsd:complexType name="FilterType"><xsd:sequence><xsd:element name="type" type="xsd:string" minOccurs="1" maxOccurs="unbounded" /></xsd:sequence></xsd:complexType><xsd:complexType name="DurationType"><xsd:sequence><xsd:element name="from" type="xsd:dateTime" /><xsd:element name="to" type="xsd:dateTime" /></xsd:sequence></xsd:complexType></xsd:schema>

図．付１．５ クエリの XML Schema－ 160 －

地域情報プラットフォームガイドライン（７）各メッセージ、推奨 Audit 形式例
推奨インタフェース定義で示したクエリの形式を用い、BPM Audit を推奨 Audit 形式で取得するときの例を以下に記す。これはクエリ－レスポンスで処理されるため、対で定義される。
(a) Audit 取得モデルにおける推奨するクエリ形式のメッセージ例
クエリ対象の BPM Audit 提供から、WS-BPEL 処理系の持つ「エンジン ID」が "bpel.a.municipal.jp" の
BPM の Audit で、シーケンス番号が 0 より大きな BPM Audit を取得する際のクエリのメッセージ例を図．
付１．６に示す。なお、クエリの結果が最大 123 個までになるよう、limit 属性を設定している。
<auditQuery><engines><engine engineId="bpel.a.municipal.jp" limit="123"><sequenceNo><gt>0</gt></sequenceNo></engine></engines></auditQuery>

図．付１．６ Audit 推奨モデルにおけるクエリのメッセージ例(b) Audit 取得モデルにおける推奨するレスポンス形式のメッセージ例
上記のクエリに対するレスポンスのメッセージ例を図．付１．７に示す。BPM Audit 提供から、WS-BPEL
処理系の持つ「エンジン ID」が "bpel.a.municipal.jp" で、シーケンス番号が 1 と 2 の BPM Audit が取得されている。なお、value タグのコンテンツは BPEL エンジンの variable 値を圧縮した上、Base64 でエンコーディングしているが、紙面の都合上途中を省略している。メッセージ Audit も同様であるが、この中には、モニタリング問い合わせインタフェースに関連し、業務メッセージ内のシステム制御情報のヘッダの一部として受付番号が含まれている。
<BPMAudit><processInstance><sequenceNo>1</sequenceNo><processInstanceId>1</processInstanceId><status>running</status><processDefId>lgAbp</processDefId><activity><date>2007-09-19T05:41:21.203Z</date><status>end</status><activityId>/process[1]/sequence[1]/receive[1]</activityId></activity><scope><variable><value>UEsDBBQACAAIAAp2MzcAAAA…BQAAAAA=</value><updatedDate>2007-09-19T05:41:21.203Z</updatedDate>－ 161 －

地域情報プラットフォームガイドライン<variableName>受付-OUTPUT</variableName></variable></scope><engine><engineId>bpel.a.municipal.jp</engineId></engine><machine><machineId>00-0C-29-0A-3E-8E</machineId></machine></processInstance><processInstance><sequenceNo>2</sequenceNo><processInstanceId>1</processInstanceId><status>running</status><processDefId>lgAbp</processDefId><activity><date>2007-09-19T05:41:21.359Z</date><status>end</status><activityId>/process[1]/sequence[1]/reply[1]</activityId></activity><scope><variable><value>UEsDBBQACAAIAAp2MzcAAAAAAAAAAAAAAAAIAAA…DAIAAAAA</value><updatedDate>2007-09-19T05:41:21.359Z</updatedDate><variableName>受領 Ack </variableName></variable></scope><engine><engineId>bpel.a.municipal.jp</engineId></engine><machine><machineId>00-0C-29-0A-3E-8E</machineId></machine></processInstance></BPMAudit>

図．付１．７ Audit 推奨モデルにおけるレスポンスのメッセージ例－ 162 －

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

付録２ 実装コンポーネント構成に関する推奨モデル（１）概要
付録として、モニタリング機能を実装するに当たっての実装コンポーネント構成に関する推奨モデルを記載する。アーキテクチャ標準仕様には、モニタリング機能の概略構成、アーキテクチャについて定義があるものの、実装に対する推奨事項は記載されていない。そのため、以下について推奨モデルとして記載する。
(a)奨励コンポーネントの概要(b)Audit 提供とのカージナリティの関係（２）奨励コンポーネントの概要
図．付２．１に奨励するコンポーネント群について、その構成要素を、機能階層と伴に展開したものを記す。表．付２．１では、図．付２．１の構成要素について解説する。
監視アプリケーション

audit 提供

Proxy

モニタリング対象

設計

ビジネス
プロセス
プロセス監視プロセス実行データ蓄積(BPM audit送信)

プロセス解析

WSDLファイル
出力プロセス audit proxy

BPM audit 提供

プロセス実行
データ蓄積

BPM auditデータ

プロセス定義
データ蓄積

BPM audit用WSDL

プロセス定義データ蓄積
モニタリング
問い合わせ
プロトコル

BPM機能
（プロセス）

プロセス設計ツール
BPMN
WS-BPEL

WS-BPEL
ファイル出力BPM audit送信

WSDL

メッセージaudit 提供
メッセージaudit送信

サービス
サービス監視サービスデータ蓄積

凡例

サービスデータ
蓄積

WSアプリケーション
定義出力
WSアプリケーション設計ツール

モニタリング問い合わせ
プロトコル

コンポーネント

プロセス定義データ蓄積

WSDL
WSアプリケーション
auditデータ

WSアプリケーション
audit送信

データ等

WSアプリケーション用
フロー定義

WSアプリケーションaudit 提供

インタフェース
既存インタフェース

図．付２．１

表．付２．１番

SOAP通信機能

メッセージaudit用
WSDL

サービス audit proxy

プロセス定義
データ蓄積
プロセス解析

メッセージauditデータ(WSアプリケーション
audit送信)

WSアプリケーション（サービス）WSDLファイル
出力

WSアプリケーション
audit用WSDL<< >> 依存形態
依存（既存）

コンポーネント図コンポーネントの説明

コンポーネント名

概要説明

号
1.

ビジネスプロセス

BPM(Business Process Management) Audit 提供およびメッセージ Audit 提供から提供される BPM Audit およびメッセージ Audit を、プロセス監視が収集しビジネスプロ
セスの分析を行う。

－ 163 －

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

2.

プロセス監視監視アプリケーションである。BPM Audit を観測することで、BPM 機能における業務実行の状況監視などを行う。さらに、メッセージ Audit を BPM Audit と関連させて分析することで、より精度の高い解析を行うこともできる。内部コンポーネントとしてプロセス解析(進捗管理)等の外にプロセス実行データ蓄積、プロセス定義データ蓄積を持ち得る。

3.

プロセス実行データ蓄積

BPM Audit およびメッセージ Audit を蓄積するもので DBMS を想定する。監視アプリ
ケーションが持っても良い。

4.

プロセス定義データ蓄積

モニタリング対象の把握・管理を実施するためメタデータ、種々の情報モデルを定義、管理、維持する。監視アプリケーションが持っても良い。

5.

プロセス解析(進捗管理)蓄積した Audit データとプロセス定義データから、ビジネスプロセスの進行状況等を
解析する。

6.

プロセス Audit Proxy

プロセス監視と BPM Audit 提供の間に配置され、BPM Audit のキャッシュをはじめとする情報統合化機能を提供する。通常は、モニタリング問い合わせインタフェースのクエリ－レスポンスのインタフェースでアクセスするが、プロセス監視からは BPM
Audit 提供のように見える設定も可能である。

7.

プロセス実行データ蓄積

BPM Audit およびメッセージ Audit を蓄積するもので DBMS を想定する。

8.

プロセス定義データ蓄積

モニタリング対象の把握・管理を実施するためメタデータ、種々の情報モデルを定義、管理、維持する。

9.

BPM Audit 提供

観測対象である BPM の WS-BPEL(Web Services Business Process Execution Language
2.0)処理系の Audit データを提供する。Audit データには WS-BPEL 処理系で業務を実行する際に発生する状態遷移に関する情報が含まれる。WSDL を通じてインタフェー
スが公開される。

10.

BPM Audit データ

観測対象である BPM の WS-BPEL 処理系が生成する各種のログ、BPM の内部状態等に基づく Audit データ。

11.

BPM Audit 用 WSDL

12.

メッセージ Audit 提供

BPM Audit を提供する Web サービスの WSDL。
観測対象である SOAP(Simple Object Access Protocol)通信機能の Audit データを提供する。Audit データには BPM 機能である WS-BPEL 処理系、ないし WS アプリケーショ
ン間でやり取りされる、業務に関する SOAP 通信の送信元、受信先、送信時刻、受信
時刻、やり取りされた SOAP メッセージなどの情報が含まれる。WSDL でインタフェー
スが公開される。

13.

メッセージ Audit データ

観測対象である SOAP 通信機能が生成する各種のログ、SOAP 通信の内部状態等に基づく Audit データ。

14.

メッセージ Audit 用 WSDL

メッセージ Audit を提供する Web サービスの WSDL。

15.

BPM 機能 (プロセス)

観測対象である BPM の処理系のことで、WS-BPEL 処理系等が相当する。

16

SOAP 通信機能

観測対象である SOAP 通信を実施する処理系のこと。BPM 機能である WS-BPEL 処理系、ないし WS アプリケーション間でやり取りされる業務に関する SOAP 通信から、メッ
セージ Audit 提供でメッセージ Audit が生成される。

17.

プロセス設計ツール

BPM 機能に関連する設計ツール群。例えば、BPM 機能である WS-BPEL 処理系で実行する WS-BPEL の定義ファイル、及び WSDL の定義ファイルを生成・編集するツールなどが相当する。

18.

BPMN

ビジネスプロセスを定義した BPMN(Business Process Modeling Notation)定義。

19.

WS-BPELBPMN 定義に従いビジネスプロセスを定義した WS-BPEL の定義ファイル。

20.

WSDL

BPMN 定義および BPEL 定義を提供する Web サービスの WSDL の定義ファイル。

21.

サービス

WS アプリケーション Audit 提供から提供される WS アプリケーション Audit を、サー－ 164 －

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

ビス監視が収集し、サービスの分析を行う。
22.

サービス監視監視アプリケーションである。WS アプリケーション Audit を観測することで、WS ア
プリケーションにおける業務実行の状況監視などを行う。内部コンポーネントとしてサービスデータ蓄積、プロセス定義データ蓄積、プロセス解析を持つ。サービスデー
タ蓄積は WS アプリケーション Audit を蓄積するものでデータベースを想定する。

23.

サービスデータ蓄積

WS アプリケーション Audit を蓄積するものでデータベースを想定する。監視アプリ
ケーションが持っても良い。

24.

プロセス定義データ蓄積

WS アプリケーション内の動作を擬似的に WS-BPEL を用いて記述した疑似 WS-BPEL 定
義と種々の情報モデルを定義、管理、維持する。監視アプリケーションが持っても良い。

25.

プロセス解析

収集した WS アプリケーション Audit とプロセス定義データを関連づけることで、WS
アプリケーション内の業務実行を監視するための各種情報を生成する。

26.

サービス Audit proxy

サービス監視と WS アプリケーション Audit 提供の間に配置され、WS アプリケーショ
ン Audit のキャッシュをはじめとする情報統合化機能を提供する。通常は、モニタリ
ング問い合わせインタフェースのクエリ－レスポンスのインタフェースでアクセスするが、サービス監視からは WS アプリケーション Audit 提供のように見える設定も可能である。

27.

サービスデータ蓄積

WS アプリケーション Audit を蓄積するものでデータベースを想定する。

28.

プロセス定義データ蓄積

WS アプリケーション内の動作を擬似的に WS-BPEL を用いて記述した疑似 WS-BPEL 定
義と種々の情報モデルを定義、管理、維持する。

29.

WS アプリケーション Audit 提供

観測対象である WS アプリケーションの Audit データを提供する。Audit データには
WS アプリケーションで業務を実行する際の状態遷移に関する情報が含まれる。WSDL
を通じてインタフェースが公開される。

30.

31.

WS アプリケーション Audit

モニタリング対象である WS アプリケーションが生成する各種のログ、WS アプリケー

データ

ションの内部状態等に基づく Audit データ。

WS アプリケーション Audit 用

WS アプリケーション Audit を提供する Web サービスの WSDL の定義ファイル。

WSDL
32.

WS アプリケーション(サービス)観測対象である WS アプリケーション。

33.

WS アプリケーション設計ツール

WS アプリケーションに関する設計ツール群。例えば、WS アプリケーションが提供するサービスの WSDL 定義ファイルを生成・編集するツールなどが相当する。

34.

WS アプリケーション用フWS アプリケーション内の動作を WS-BPEL を用いて記述した疑似 WS-BPEL 定義。

ロー定義
35.

WSDL

WS アプリケーション用フロー定義を提供する Web サービスの WSDL の定義ファイル。

（３）Audit 提供とのカージナリティの関係
Audit 提供とのカージナリティの関係に関しては、図．付２．２の様に推奨する。モニタリング機能の実装に対して、実装コンポーネント構成に関する推奨モデルを図．付２．１に奨励されているが、これに対して、Audit 提供等をどの様に対応付けるか、を図．付２．２では記載する。図中、灰色にて網掛けされているクラスが地域情報プラットフォーム内に実装されるクラス群である。各 Audit 提供は、各処
理系実装と１対１の関係で実装されることが望ましい。表．付２．２は、図．付２．２の情報モデルのクラスを説明したものである。

－ 165 －

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

Audit提供は、この基数にて対応付けられる。
BPM Audit提供機能

メッセージ Audit提供機能

通信の規定は無。SOAP以外のものも可能。 通信する

1
1..*

利用する

1..*

1

独立業務ユニット実装

WSアプリケーション Audit提供機能

0..1

1

1..*

1

<<Abstract>>
WSアプリケーション実装

1..*

1
個別業務ユニットI/F実装

WS-BPEL処理系実装 SOAP通信基盤実装

1..*

1..*

<<Abstract>>
プロセス/サービス

業務ユニット実装

モニタリング対象
1..*

BPM機能
含む
構成する
1..*

含む

0..*
実行体はクラスタ化、グリッド化
した実装も含む。

含む

含む
1

非PF実行体

1..*

PF実行体

1..*
論理ドメイン

業務ユニットI/F実装

1..*

実行体は必ずBPM
機能、もしくはPF
通信機能１つ含む。 1..*<<Interface>>
業務ユニットI/F<<Abstract>>

PF通信機能0..*1..*

地域情報PF実装

地域情報PFの実装範囲
実行体
0..1
モニタリング
機能実装

図．付２．２

Audit 提供との基数関係、クラス図

表．付２．２

Audit 提供との基数関係、クラス

クラス名
実行体

定義、デプロイメント制約
地域情報プラットフォーム実装の実行環境については、プラットフォーム通信標準仕様における OS 事項などの制限以外、デプロイメント・構成に関する制約事項は存在しない。
この「実行体」クラスとは、CPU 資源に代表される計算機資源を持ち、BPM 機能の実行やサービスの実行提供等を行う計算機を一般化したものである。
さらに、このクラスは、地域情報プラットフォームを実装、実現する際の資源を意味する「PF実行体」クラスと、地域情報プラットフォームから呼び出されて関連する機能を提供するための資源を意味する「非 PF 実行体」クラスの２つに分類される。

PF 実行体「実行体」クラスの一つで、地域情報プラットフォームを実装、実現する際の資源を意味する。そのため「地域情報 PF 実装」クラスは、これを複数含んで構成される。
「PF 実行体」クラスの一つのインスタンスは、０以上の「BPM 機能」クラスのインスタンス、もしくは１以上の「PF 通信機能」クラスのインスタンス、もしくは０以上の「業務ユニット I/F 実装」クラスのインスタンスを含み得る。
具体的には、地域情報プラットフォームの機能がインストール、実装されたサーバ等が該当する。

非 PF 実行体「実行体」クラスの一つで、地域情報プラットフォームから呼び出されて関連する機能を提供するための資源を意味する。具体的には、「業務ユニット I/F 実装」クラスの任意インスタン
スから呼び出されて、プロプラエタリの通信手段により、サービス実施を行うアプリケーショ
ンを意味する「独立業務ユニット実装」クラスの複数種の複数インスタンスを保持し得る。

－ 166 －

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

具体的には、業務ユニットやバックエンドの業務アプリケーション機能がインストール、実装されたサーバが該当する。これらは、地域情報プラットフォームの実装基盤からサービス呼出を受けるが、地域情報プラットフォーム実装の範囲内のサーバとしては扱われていないものである。
(Abstract)プロセス/サービスモ
ニタリング対象

プロセス、サービスについてのモニタリング対象を意味する抽象クラスである。この具体的な実装が、「BPM 機能」「PF 通信機能」「業務ユニット I/F 実装」「独立業務ユニット実装」の各クラスである。

BPM 機能地域情報プラットフォームの BPM 機能を意味するクラスであり、「プラットフォーム通信標準仕様、第４章、プラットフォーム通信標準のビジネスプロセス制御定義仕様」を満足する。BPM
機能の実装方式には規定がないため、「PF 実行体」クラスの１インスタンス上に１インスタン
ス以上を含めることができる。またクラスタ化された実装も考えられるため、逆に、このクラスの１インスタンスは、１以上の「PF 実行体」クラスのインスタンスに展開されることもある。
この「BPM 機能」クラスは、抽象クラスである「プロセス/サービス観測対象」クラスを継承する。さらに、「BPEL 処理系実装」クラスは、この「BPM 機能」の一つである。

PF 通信機能

プラットフォーム通信標準仕様を満たす通信機能を意味するクラスであり、「プラットフォー
ム通信標準仕様、第２章のプラットフォーム通信仕様」を満足する。PF 通信機能の実装方式には規定はないため、「PF 実行体」クラスの１インスタンス上に１インスタンス以上を含めることができる。
この「標準通信機能」クラスは、抽象クラスである「プロセス/サービス観測対象」クラスを継承する。さらに通常、「SOAP 通信基盤実装」クラスとして継承され、扱われる。

(Interface)業務ユニット I/F「アーキテクチャ標準仕様、第４章実現するためのアーキテクチャ」で定義される、汎化されたインタフェースであり、業務ユニットが持つべきインタフェースとして定義される。
(Abstract)業務ユニット I/F 実装「業務ユニット I/F」インタフェースを実装したクラスであり、抽象クラスである「プロセス/サービス観測対象」クラスを継承したものである。これは、実際のサービスを汎化したものとして定義され、実際のサービスを意味する「個別業務ユニット I/F 実装」クラスが、継承されて定義される。
「PF 実行体」クラスの一つのインスタンスは、０以上の「業務ユニット I/F 実装」クラスのインスタンスを含み得る。これは、実際のサービスを意味する「個別業務ユニット I/F 実装」
クラスのインスタンス数に相当する。

個別業務ユニット I/F 実装「業務ユニット I/F 実装」クラスを継承したもので、実際のサービス毎に実装される。例えば、A 業務、B 業務、C 業務と３つのインタフェースが存在する場合、これに基づき３インスタンス生成される。
これは、「PF 実行体」クラスの同じインスタンス上に置かれる、「業務ユニット実装」クラスのインスタンスに取り込まれるか、もしくは別の実行体である「非 PF 実行体」クラスのインス
タンス上に置かれる、「独立業務ユニット実装」クラスのインスタンスと通信を介して、サービスを提供するものである。

業務ユニット実装「アーキテクチャ標準仕様、第４章 実現するためのアーキテクチャ」で定義される、業務ユニットを実装したクラスであり、汎化されたものである。このクラスの各インスタンスが、具体的なサービスの処理を提供するものである。この場合、「PF 実行体」クラスのインスタン
ス上の、複数「個別業務ユニット I/F 実装」クラスのインスタンスを組み込んで構成される。

独立業務ユニット実装「アーキテクチャ標準仕様、第４章実現するためのアーキテクチャ」で定義される、業務ユニットを実装したクラスであり、汎化されたものである。このクラスの各インスタンスが、具体的なサービスの処理を提供するものである。このインスタンスは「非 PF 実行体」クラスのインスタンス上に配置されるもので、別の実行体である、「PF 実行体」クラスのインスタンス
上に配置される「個別業務ユニット I/F 実装」クラスのインスタンスに対して通信を介して処－ 167 －

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

理を行う。
(Abstract)
WS アプリケーション実装

サービスを実施する主体を抽象的に表現しているクラスであり、実際には、「アーキテクチャ
標準仕様、第４章

実現するためのアーキテクチャ」で定義される、業務ユニットを実装した

クラスに相当する「業務ユニット実装」クラス、もしくは「個別業務ユニット I/F 実装」クラスに相当する。
WS-BPEL 処理系実装「BPM 機能」クラスを継承したクラスであり、「プラットフォーム通信標準仕様、第４章、プラッ
トフォーム通信標準のビジネスプロセス制御定義仕様」に関する規定事項を満たす。

SOAP 通信基盤実装
地域情報 PF 実装「PF 通信機能」クラスを継承したクラスであり、プラットフォーム通信標準仕様を満たす。
地域情報プラットフォームのプラットフォーム通信標準仕様を満たす、具体的な実装であり、１以上の「PF 実行体」クラスのインスタンスを含んで構成される。さらに、「モニタリング機
能実装」インスタンスも、含み得るが、シングルトンを仮定する。

論理ドメイン「プロセス/サービスモニタリング対象」クラスを継承する複数のインスタンスを含んで構成される、プロセス/サービス監視の単位対象範囲のことで、同じ「プロセス/サービスモニタリ
ング対象」のインスタンスは複数の「論理ドメイン」に参加できる。１以上の任意個数の「標準通信機能」のインスタンスは、必ず登録される。
１つの「論理ドメイン」のインスタンスは、それを管理するシステム管理者がローカルに定める、セキュリティポリシーにより管理され、同一のポリシーで扱われる。従って、通常は組織単位で定義されるが、組織に跨って定義されても良い。

モニタリング機能実装

本仕様書の要件を満たす実装を意味するクラスであり、１つの「登録定義」クラスのインス
タンスのもと、「プロセス/サービス監視対象範囲」を１つ保持することができる。

BPM Audit 提供機能

BPM 処理系の動作を表す Audit を提供する。BPEL 処理系実装と１対１で関係付けられる。

メッセージ Audit 提供機能

ネットワーク上で流通する業務データの内容、状態を表す Audit を提供する。SOAP 通信基盤実装と１対１で関係付けられる。但し、メッセージ Audit 提供機能自身は、オプションであるため、基数的には１対(0..1)となる。

WS アプリケーション
Audit 提供機能

業務ユニット等のアプリケーションの動作を表す Audit を提供する。業務ユニット実装と１対１で関係付けられる。

－ 168 －

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

付録３ 共通ヘッダ、受領 Ack、添付書類の XML スキーマについて
本付録では、プラットフォーム通信標準仕様により定められている下記の地域情報 PF において共通的な XML スキーマについて説明する。
・共通ヘッダ・受領 Ack
・添付書類（１）共通ヘッダ
メッセージ共通のヘッダ（共通ヘッダの項目セット）は、プラットフォーム通信標準仕様における「７．
１．２

共通ヘッダの項目のＸＭＬスキーマ作成仕様」で規定した以下の形式を使用する。
表．付３．１№

データ項目

共通ヘッダのＸＭＬスキーマ仕様
XML データ型

最小

最大

最小

最大

文字数

文字数

出現回数

出現回数

1

共通ヘッダ

共通ヘッダ情報2

To

string

0

1024

0

1

3

MsgID

string

0

1024

0

1

4

RelatesTostring

0

1024

0

1

5

ReplyTostring

0

1024

0

1

6

受付番号

string

0

256

1

1

7

共通コリレーションセット

string

0

256

0

1

8

ビジネスプロセス制御情報

string

0

100

0

1

9

業務サービス結果情報

string

0

10

0

1

10

結果情報

string

0

1

0

1

11

システムエラー報告

string

0

1024

0

1

（２）受領 Ack
受領 Ack は、下図に従う。受領 Ack は、共通ヘッダとリクエストやレスポンスを受領できたかの成否のための受領ステータス、受領日時から構成される。
表．付３．２№
1

データ項目
受領 Ack

受領 Ack のＸＭＬスキーマ仕様
XML データ型

最小

最大

最小

最大

文字数

文字数

出現回数

出現回数

1

1

1

1

1

1

受領 Ack 情報

2

共通ヘッダ

3

受領ステータス4

受領日時

共通ヘッダ情報string年

string

4

4

0

1

月

string

2

2

0

1

日

string

2

2

0

1

時

string

2

2

0

1

分

string

2

2

0

1

秒

string2

2

0

1－ 169 －

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

№
5

データ項目

XML データ型

備考

string

最小

最大

最小

最大

文字数

文字数

出現回数

出現回数

0

1024

0

1

（３）添付書類
添付ファイルをメッセージ本文で扱う場合の 2 種類の方法を下記に示す。添付書類がある場合は、以下のいずれかの形式を、メッセージ設計時にメッセージの最後に追加する。
メッセージ本体格納型
SOAP Envelope (XML)
SOAP Header
SOAP Body （本体）
共通ヘッダ

本文

第１メッセージ添付部（Base64エンコーディ
ング)
第２メッセージ添付部（Base64エンコーディ
ング)

添付書類タグはメッセージの最後に置く。
※メッセージ本体格納型の場合は、・送信側は、添付書類内容タグを用いて、添付ファイルの内容を
Base64エンコーディングしてタグ値とする。
・受信側は、添付書類内容タグの有無を判定し、ある場合は、タグ値の内容を元に戻し、添付書類ファイル名称のファイルとして処理をする。
サンプル：<添付書類><添付書類名称>住民票</添付書類名称><添付書類ファイル名称>A0002.pdf</添付書類ファイル名称><添付書類内容>falkdsjfaidfujoiwa ・・・・90aus3fjlakjefa9uajaf</添付書類内容></添付書類>メッセージへの添付 (SwA: SOAP Messages with Attachments) 型

SOAP Messages with
Attachments(Mime Multipart)
SOAP Envelope (XML)
SOAP Header
SOAP Body （本体）添付ファイルタグはメッセージの最後に置く。
※メッセージへの添付 (SwA) 型の場合は、添付ファイル名称タグの値として、同時に転送する添付ファイル
内でユニークとなる英数字のファイル名称を設定する。
また、添付書類参照情報タグには、対象の添付ファイルを格納するMIMEパートのContent-IDヘッダに対応するcid URIを
格納する。

共通ヘッダ
本文
<添付書類>

第１メッセージ添付部（任意のファイル形式)

サンプル：<添付書類><添付書類名称>住民票</添付書類名称><添付書類ファイル名称>A0002.pdf</添付書類ファイル名称><添付書類参照情報>cid:XXXX@YYYY</添付書類参照情報></添付書類>

第２メッセージ添付部（任意のファイル形式)

図．付３．１

添付ファイルのための XML タグ形式

－ 170 －

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

表．付３．３
№
1

データ項目
添付書類

添付書類のＸＭＬスキーマ作成仕様
XML データ型

最小

最大

最小

最大

文字数

文字数

出現回数

出現回数

添付書類情報2

添付書類名称

string

(※1)

(※1)

1

1

3

添付書類ファイル名称

string

(※1)

(※1)

1

1

4

添付書類内容string

(※1)

(※1)

1

1

5

添付書類参照情報

Ref.swaRef

(※1)

(※1)

1

1

(※1)最小文字数・最大文字数に関しては、プラットフォーム通信標準仕様 V2.1 では規定していない。
（４）ＸＭＬスキーマファイルに関して前述した、共通ヘッダ、受領 Ack、添付情報の３要素の定義を、プラットフォーム通信標準仕様 V2.1の一部として、単一のＸＭＬスキーマファイルで提供する。
プラットフォーム通信標準仕様の「３．２ （５）ＸＭＬに関する取り決め」に示してあるとおり、
共通ヘッダ、受領 Ack、添付書類のいずれか、もしくは全てを扱う場合には、プラットフォーム通信標
準仕様として提供しているスキーマを使用することとする。
ＸＭＬスキーマファイルの名称は、「プラットフォーム通信標準仕様 V2.1」の「３．２．
（７）④ファ
イル命名規約（※2）
」に従い、次に示すとおりである。
ファイル命名例）common-2010-01.xsd（※2）次のファイル命名形式が示されている。
・ファイル命名形式{地域情報PF仕様種別の文字列}＋{定義識別子}＋{s}＋{-バージョン文字列}.{拡張子}・共通ヘッダ、受領 Ack、添付書類の３定義を単一のファイルとして提供するため、定義識別子は設定しない。
（５）「common-YYYY-NN.xsd」のファイルの更新規約に関して
本スキーマファイルは、共通ヘッダ、受領 Ack、添付書類のいずれかの定義に変更が行われた場合、スキーマファイルの更新に合わせ、スキーマファイル内の名前空間 URI のバージョン文字列と、ファイル名に使用されるバージョン文字列の同期をとって更新する。
そのため、前述した「common-YYYY-NN.xsd」が更新された場合は、他の仕様でこれをを参照しているスキーマ内の「名前空間識 URI」と「参照先ファイル名」の更新が必要となる。

（６）使用する定義に関して
各業務仕様で共通ヘッダ、受領 Ack、添付書類のＸＭＬスキーマを使用する場合は、そのスキーマファ
イル内でグローバル要素定義されている、共通ヘッダ、受領 Ack、添付書類の要素を原則使用する。
使用例）○ <xsd:element ref=“common:共通ヘッダ”/>○ <xsd:element ref=“common:受領 Ack”/>○ <xsd:element ref=“common:添付書類”/>－ 171 －

地域情報プラットフォームガイドライン（７）タグの値省略に関して
共通ヘッダ、受領 Ack、添付書類のＸＭＬスキーマでは、タグの値が無い（NULL 値）の場合は、プ
ラットフォーム通信標準仕様の「表３．２．２

データ項目の値が省略された場合のＸＭＬ表現方法」の「No.1 タグを省略する」を使う。xsi:nil での NULL 値表現は不可とする。
（８）ＸＭＬスキーマと対応する標準仕様のバージョン情報について「プラットフォーム通信標準仕様 V2.1」の「３．２（５）ＸＭＬに関する取り決め⑫」に「『XML

スキーマの<xsd:documentaion>の領域に、そのスキーマを提供している地域情報プラットフォーム標
準仕様情報』について記述する」表記ルールが示されている。
その表記ルールを踏まえた「common-YYYY-NN.xsd」における情報の記載例を次に示す。

<?xml version="1.0" encoding="UTF-8"?><xsd:schema
targetNamespace="urn:applic:xmlns:pf:common:schema:2010-01"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:common="urn:applic:xmlns:pf:common:schema:2010-01"
xmlns:ref="http://ws-i.org/profiles/basic/1.1/xsd"
elementFormDefault="qualified"><xsd:annotation><xsd:documentation>
本文書は「共通ヘッダ」と「受領 Ack」と「添付書類」に関する XML スキーマである。
管理主体：APPLIC
著作権：APPLIC
ファイル名：common-2010-01.xsd
PF 仕様:プラットフォーム通信標準仕様

Ｖ2.1

作成日：2010/05/31</xsd:documentation></xsd:annotation><xsd:import namespace="http://ws-i.org/profiles/basic/1.1/xsd"
schemaLocation="http://ws-i.org/profiles/basic/1.1/swaref.xsd" /><xsd:element name="共通ヘッダ" type="common:共通ヘッダ情報" /><xsd:element name="受領 Ack" type="common:受領 Ack 情報" /><xsd:element name="添付書類" type="common:添付書類情報"/>
図．付３．２「common-YYYY-NN.xsd」における<xsd:documentation >領域の記述例－ 172 －

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

付録４ モニタリング機能の実装例
【凡例】
凡例】

【地域ポータル、もしくは集中管理センター】

BPM Audit取得・変換・転送
udit取得・変換・転送::監視クライアントメッセージA
メッセージAudit取得・変換・転送
udit取得・変換・転送::
WSアプリケーション
WSアプリケーション Audit取得・変換・転送
udit取得・変換・転送((利用時)
利用時):
転送(
転送(特に参照利用されない場合)
特に参照利用されない場合)：

監視アプリケーションサーバ
(ベンダB)

業務メッセージ：

監視ｱﾌﾟﾘｹｰｼｮﾝ（プロセス監視モジュール）

この問い合わせ方式を標準にて規定

OS#注：実装例のWSDM
は奨励ではないが、利用可能。
注：実装例のWSDMは奨励ではないが、利用可能。

【地域ポータル】【民間：電力会社】

ＢＰＭサーバ(ベンダA)OS
BPEL処理系
LOG出力

メッセージ Audit提供/
Audit proxyサーバ(ベンダB)

WSDL/SOAP

OS
BPEL処理系【自治体Ａ】LOG出力
WSDM/SOAP
Audit Proxyサーバ（LOG収集モジュール）
OS

BPEL生
LOGﾌｧｲﾙ

LOG送信（SOCKET通信）

ＢＰＭサーバ（ベンダC）

ＢＰＭサーバ（ベンダB）

ＢＰＭ Audit 提供アダプタ(ベンダA)

WSDL/SOAP
BPM Audit提供/
メッセージ Audit提供/
Audit Proxy
Audit proxyサーバ(ベンダB)WSDM
BPEL生
LOGﾌｧｲﾙ
ｸﾗｲｱﾝﾄ/SOAP
LOG送信（SOCKET通信）

WSDM
BPM Audit提供アダプタ（Java,APサーバなど）
OS

OS

BPM Audit提供アダプタ（Java,APサーバなど）
OS

ＢＰＭ Audit 提供アダプタ(ベンダA)
WSDM

Audit Proxyサーバ(ベンダA)
監視ｱﾌﾟﾘｹｰｼｮﾝ,DBｴﾝｼﾞﾝ（Java,APサーバ,DBMS）
OS

受付
LOG出力

WSｱﾌﾟﾘ生
LOGﾌｧｲﾙ＊LOG出力PKG
PF標準Webｻｰﾋﾞｽ
連携ﾓｼﾞｭｰﾙ

DB
ｱﾀﾞﾌﾟﾀ

BPEL生
LOGﾌｧｲﾙ

LOG送信（SOCKET通信）

OS

監視アプリケーション
サーバ(ベンダA)

業務アプリケーションC
ｻｰﾋﾞｽﾓｼﾞｭｰﾙ
LOG出力

WSｱﾌﾟﾘ生
LOGﾌｧｲﾙ

Audit Proxyサーバ(ベンダA)

Audit Proxyサーバ(ベンダA)

監視ｱﾌﾟﾘｹｰｼｮﾝ,DBｴﾝｼﾞﾝ（Java,APサーバ,DBMS）

監視ｱﾌﾟﾘｹｰｼｮﾝ,DBｴﾝｼﾞﾝ（Java,APサーバ,DBMS）

PF標準Webｻｰﾋﾞｽ
連携ﾓｼﾞｭｰﾙ

OS

OS

ｱﾌﾟﾘｹｰｼｮﾝｻｰﾊﾞ

ｱﾌﾟﾘｹｰｼｮﾝｻｰﾊﾞ＊LOG出力PKG
DB
ｱﾀﾞﾌﾟﾀWSDL/SOAP

WSDL/SOAP

OS

OS

監視クライアント

WSDL/SOAP

業務サービスサーバ（ベンダC）
LOG送信（SOCKET通信）
監視アプリケーション
サーバ(ベンダA)

業務アプリケーションＢ

LOG出力

BPM Audit 提供アダプタ（Java,APサーバなど）

LOG送信（SOCKET通信）
監視アプリケーション
サーバ(ベンダA)OS
BPEL処理系

Audit Proxyサーバ（LOG収集モジュール）

ＢＰＭ Audit 提供アダプタ(ベンダA)

業務アプリケーション・ユニット
サーバ（ベンダB）

メッセージ Audit提供/
Audit proxyサーバ(ベンダB)
WSDM/SOAP

監視クライアント－ 173 －

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

付録５ 採用候補の技術仕様の検討状況について
本章で、実現方法の１つとして ID-WSF を候補としている記載がある。ID-WSF については、具体的なユースケースや、技術仕様の標準化動向を踏まえた検討が必要であるとされた。APPLIC における検討状況について以下に示す。
（1）具体的なユースケースに基づく必要性の検討
自治体が保有する情報を自治体間で相互に連携することで、例えば、現行の申請手続きにおいて、住民が各行政機関を訪問し、必要な証明書を取得するといった手続きが不要となるなどの効果が期待できる。
現在の申請業務

住民が自身の状況（住所情報、家族構成等）に応じて各行政機関から証明書を取得する。

自治体で情報連携を行う場合の申請業務

情報を保有
する自治体
訪問

証明書

訪問

情報を保有
する自治体
情報を保有
する自治体

住民の同意に基づく連携の制御
情報連携

証明書

申請書 証明書
申請者（住民） 訪問

図．付５．１

情報を保有
する自治体

申請を行う
自治体

申請者
（住民）

申請書
訪問
または電子申請

自治体が、住民の状況（住所情報や家族構成等）に応じて情報連携を行う。

情報連携

申請を行う
自治体

住民の同
意の取得

自治体で情報連携を行う場合の申請業務

自治体が保有する情報に、無条件で他の自治体が連携することにより、住民にとって新たな脅威となる可能性もあるため、住民の同意に基づく連携の制御や、住民の情報に対するアクセス記録を確認できる仕組みが必要と考える。
上記の仕組みの必要性については、具体的なユースケースに基づき、適用する範囲や内容を検討する必要がある。検討ポイントを以下に示す。
・法制度による情報連携(公用照会)等、住民同意によらない情報連携の検討
・情報連携制御に求められる要件を明確化するための、ユースケースの具体化
・本人同意の範囲、同意の取得のタイミング、住民の解り易さの検討
・本人同意に基づく連携を制御する仕組みの検討
・技術面および運用面の観点
・既存技術と組み合わせた実装の検討（※）※ 補足
例えば、住民情報へのアクセスについて、照会先自治体の職員が承認許可をする為には、ID-WSF と PF サービス認
可仕様や非同期 2WAY など MEP と組み合わせた実装が必要となる。
この規格の組み合わせについては、ユースケースへの適合性、実装が複雑にならないか、性能、信頼性等について十分に検討する必要がある。

－ 174 －

地域情報プラットフォームガイドライン(２) 技術仕様の標準化動向の検討
地域情報プラットフォーム標準仕様書では、技術標準採用基準として以下の 4 つの観点を挙げており、観点に基づく技術評価が必要となる。
(a) 標準化団体にて標準化が確定しているまたは検討中の仕様(b) ライセンスフリーの考え方を基本とした仕様(c) 自治体および地域情報化で実現性が高い仕様(d) 標準仕様や相互接続ガイドラインで、相互接続の仕様が存在する仕様
ID-WSF について 4 つの観点の状況を示す。
※ ID-WSF2.0、2010 年時点(a) 標準化団体にて標準化が確定しているまたは検討中の仕様
Liberty Alliance による標準化がなされた後、現在は、Liberty Alliance から引き継がれた Kantara
Initiative により ITU への提案活動を行っている。ただし、Kantara Initiative は自らを標準化団体として位置づけておらず、他団体への草案提出を活動内容としている。
(b)ライセンスフリーの考え方を基本とした仕様
Liberty Alliance の活動は特許使用許諾（ライセンス）の条件として RF 及び RAND を認めており、RAND
宣言猶予期間は 45 日間と定められている。
ID-WSF2.0 策定期間において RAND 宣言はされていない。
(c)自治体および地域情報化で実現性が高い仕様
オープンソースでの実装は存在するが、実運用はされていない。現在国内で(4)に示す相互接続認定を受けているのは 1 社である（世界では 2 社）
。今後の普及動向を見ていく必要がある。
(d) 標準仕様や相互接続ガイドラインで、相互接続の仕様が存在する仕様
相互接続試験を行う団体として、Liberty Alliance、2009 年以降は Kantara Initiative が存在する。
ただし、ID-WSF 2.0 の相互接続認定試験は 2006 年 12 月以降実施されていない。

－ 175 －

地域情報プラットフォームガイドライン
技術解説 要約

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

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

項

版数

1

2014.3.11

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

改版履歴

備考
版数表記を、バージョン標記から修正
日標記に変更内容の修正は行っていないため、版数の変更はなしはじめに
本書は、「地域情報プラットフォームガイドライン」の「第 3 章 技術解説」を要約したものであり、単独自治体の庁外との通信で使用するプラットフォーム通信機能とプラットフォーム共通機能について説明しています。

■ 本マニュアルの目的
・

地域情報プラットフォーム導入時に、技術的な解説の参考とする■ 対象読者
・

自治体においてサービス基盤および業務アプリケーションを導入する調達者■ 前提知識・システム構築に関する一般的な知識

・

ネットワーク構築に関する一般的な知識

・

アプリケーション開発に関する一般的な知識

・

オペレーティングシステムに関する一般的な知識■ アイコンについて
アイコン

意味

【ヒント】
役に立つ情報や関連情報などを表します。
【重要】
記載内容のまとめや特に重要な情報を表します。

目次
第1章

概要 ................................................................................................................... 1

第2章

機能説明 .......................................................................................................... 4

2.1 PF通信機能 ................................................................................................................................................5
2.2 統合DB機能................................................................................................................................................7
2.3 BPM機能 ................................................................................................................................................... 12
2.4 セキュリティ対策 .................................................................................................................................... 15
2.5 認証・認可機能....................................................................................................................................... 21
2.6 モニタリング機能 ................................................................................................................................... 27
2.7 ユーティリティ機能 ................................................................................................................................ 30
2.8 メッセージ交換パターン ...................................................................................................................... 37

第 1 章 概要
ここでは、地域情報プラットフォーム標準仕様の体系と本書の位置付けについて説明します。

-1-

■ 地域情報プラットフォーム標準仕様の体系
地域情報プラットフォーム標準仕様は、業務モデル標準、サービス協調技術標準で規定する標準仕様、
およびガイドラインで構成されます。
地域情報プラットフォーム標準仕様の体系を、図 1.1 に示します。

地
域
情
報
プ
ラ
ッ
ト
フ
ォ
ー
ム
標
準
仕
様
書

業務モデル標準

サービス協調技術標準

自治体及び民間が提供する地域情報サービスの連携に必要な業務アプリケーションユニットのインタフェース仕様

サービス連携を支える基盤アプリの諸要件・プロトコ
ル等を取り決めた仕様

自治体業務アプリケーションユニット標準仕様
防災業務アプリケーションユニット標準仕様
教育情報アプリケーションユニット標準仕様
健康情報業務アプリケーションユニット標準仕様※

アーキテクチャ標準仕様
プラットフォーム通信標準仕様

GISを活用した業務ユニット、アプリケーションを構築するための共通仕様

GIS共通サービス標準仕様
各種システム製品等の地域情報プラットフォーム準拠及び相互接続を確認する仕様

地域情報プラットフォーム準拠確認及び相互接続確認仕様
仕様に準拠したサービス基盤および業務アプリケーションを導入する調達者向けに必要な事項をとりまとめたもの（指針）

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

その他

地域情報プラットフォーム基本説明書
地域情報プラットフォーム標準仕様運用規則

資参料考

地域情報プラットフォームガイドライン 技術解説 要約
地域情報プラットフォームにおけるＧＩＳ共通サービス基本提案書※ 今後、標準仕様体系に取り込み予定

図 1.1 地域情報プラットフォーム標準仕様の体系『地域情報プラットフォームガイドライン』は、業務モデル標準とサービス協調技術標準における仕様に準拠したサービス基盤、および業務アプリケーションを導入するときに必要な事項をとりまとめたものです。
第 1 章、第 2 章では、調達者向けに必要な情報を集約してまとめ、第 3 章では PF 通信機能、PF 共通機
能と、その利用方法についての技術解説としてまとめています。第 4 章ではワンストップ導入および連携
定義手順、別冊として GIS 共通サービスガイドラインを紹介しています。

- 2 -■ 本書の位置付け
本書は、『地域情報プラットフォームガイドライン』の 3 章の一部を簡単に要約したものです。
プラットフォーム共通機能のごとに、概要、導入時のメリット、留意事項、ユースケースを説明しています。
地域情報プラットフォームのシステム基盤の概念を図 1.2 に示します。
下図の赤枠内が、本書の「第 2 章 機能説明」で説明している機能です。
業務ユニット
フロント系業務ユニット
電子申請

電子調達 ・・・

地域情報プラットフォーム（サービス基盤）の標準化範囲
住民認証
職員認証
基盤連携
・認証基盤
・決済基盤

バック系業務ユニット
住基

国保

ＰＦ通信機能ＰＦ通信機能共通系業務ユニット
・・・

決裁等

・・・

ＰＦ通信機能ＰＦ通信機能アプリケーション
開発標準

BPM機能（※）
PF共通機能（※）
・時刻同期
・認証・認可（サイト間）
・モニタリング（サイト間）

帳票管理
統合DB機能（※）

外字管理

ＰＦ通信機能

・
・
・

データ変換

・
・
・
運用管理
ハードウェア・ソフトウェア・周辺機器等
ネットワークシステム基盤（※）はオプション機能

図 1.2 システム基盤の概念図

プラットフォーム共通機能（PF 共通機能）の扱いについて
PF 共通機能とは、自治体単独のサイト内や、庁外の異なるサイトにまたがった業務サービスを連携するときに必要となる、プラットフォームに共通の機能群のことです。
「地域情報プラットフォームガイドライン」の第 3 章では、PF 共通機能と利用方法の紹介という扱いとし、周辺環境の整備や留意事項もあわせて記載しています。

-3-

第 2 章 機能説明
ここでは、PF 通信機能と PF 共通機能ごとに、概要、導入時のメリット、留意事項、
ユースケースを説明します。

- 4 -PF 通信機能

2.1■ PF 通信機能とはプラットフォーム通信機能（以降、PF 通信機能）とは、業務ユニットと業務サービスが標準インタフェース
や標準規約（セキュリティ、メッセージなど）に準拠して連携を実現するための機能群のことです。次の 9つの機能を実現できることが求められています。
・HTTP 通信（IPv4、HTTP1.1）

・

通信セキュリティ（通信路暗号 SSL3.0(TLS1.0)、サーバ認証）

・

通信セキュリティ（通信路認証 SSL3.0(TLS1.0)、クライアント認証）

・

通信セキュリティ（通信路認証 HTTP のベーシック認証）

・

SOAP 通信（SOAP1.1、document/literal、WS-I ベーシックプロファイル 1.0）

・

高信頼性通信（WS-Reliability1.1、WS-ReliableMessaging1.1）

・

高信頼通信（MEP 方式）

・

メッセージの XML 定義仕様（XML Schema 1.0、PF 仕様の XML プロファイル）・

サービスインタフェースの XML 定義仕様（WSDL1.1、PF 仕様の XML プロファイル）

PF 通信機能は、業務ユニットや BPM 機能、統合 DB 機能など、他のシステム構成単位の前提
ソフトウェアとなります。上記の太字の機能が、最低限必要な機能です。
また、PF 通信機能単独でシステム構成単位とはなりません。

■ 導入時のメリット
PF 通信機能を導入すると、次のようなメリットがあります。
・

サービス連携実現に採用している SOAP (Simple Object Access Protocol) 1.1 により、下位通信プロ
トコルに依存しません。
現在は、下位プロトコルとして HTTP を使用することが主流ですが、今後、必要に応じて他のプロトコルを採用できます。

・SOAP 通信により、さまざまな機能を提供する Web サービスの仕様のスタックを利用できます。
ミドルウェアが標準仕様のスタックの実装を提供することにより、セキュリティ、高信頼性などの機能を利用できるようになります。

・

高信頼性通信機能により、SOAP 通信処理の信頼性を向上させ、メッセージの送達保証（失敗時再送）、重複排除、順序保証が実現されます。
送信側アプリケーションは高信頼性通信処理系にメッセージを渡すだけで、送信側と受信側の高信
頼性通信処理系の間のメッセージ交換により、メッセージは高信頼で受信側アプリケーションに渡されます。

・MEP（メッセージ交換パターン）により、通信上で発生した障害は統一的に処理されます。
高信頼性通信機能を利用すると、回復可能な障害は高信頼性通信機能のレベルで吸収され、回復不能な致命的な障害は、上位層で扱われます。

-5-

■ 留意事項
サービスが他のサービスと通信（連携）するためには、通信先のサービスの各種情報を設定しておく必要があります。設定すべき項目として、次のようなものが考えられます。
•

HTTP のタイムアウト•

本文メッセージの最大サイズ（最大バイト数など）•

各サービスのエンドポイント URL (Uniform Resource Locator)、DNS (Domain Name System)

•

認証機能

•

認証方式の選択（SSL (Secure Sockets Layer) クライアント認証、HTTP ベーシック認証など）•

認証情報の交換（信頼できる CA (Certification Authority) 情報や ID、パスワードなど）

また、採用するオプション機能に応じて、そのオプション機能に固有の設定が必要になる場合もあります。
これらの情報は、通信するサービス間で何らかの方法で交換される必要があります。将来的にはサービ
スレジストリ機能などを利用して交換されることが想定されますが、現時点では、サービスの管理者間の情報交換などにより、手動で設定することが現実的です。

- 6 -統合 DB 機能

2.2■ 統合 DB 機能とは
統合 DB 機能とは、業務ユニット間で必要となるデータを統一的に管理することで、業務ユニット間のデータ交換を効率的に実現する機能です。このため、業務ユニット同士がデータ交換（情報を共有または連携）できるための機能を有する必要があります。
統合 DB 機能の役割は、提供側業務ユニットを意識することなく、提供側業務ユニットで管理されている
データを利用側業務ユニットから利用するための「データの受け渡し」です。業務間の連携を疎とすることを目的としており、統合 DB 機能におけるデータの管理方法(実装方式)は規定していません（一般的に統合 DB 機能は複数のデータを組み合わせて必要なデータを利用するための「データ統合機能」を持っていますが、この機能については標準化していません）。統合 DB 機能は、業務ユニットが利用するときの利用側インタフェースとして必要な単位で自治体業務アプリケーションユニット標準仕様に準拠した
SOAP の業務ユニットインタフェースを有するものとします。オプションとして SQL インタフェースも採用できます。
統合 DB 機能の役割と標準化ポイントを、図 2.2.1 に示します。
統合DB機能の役割

業務ユニットA

業務ユニットX

a

a

ＤＢ－A

データの統合

A

A

X

X

B

B

業務ユニットB

b

b

ＤＢ－B

データの受渡し提供Ｉ/Ｆ

提供側規定されたデータの管理を行い統合
DBに提供する。

利用Ｉ/Ｆ

標準化の
対象外

業務標準仕様で標準化される。

利用側

必要な情報を標準化された手段で利用（参照）できる。

図 2.2.1 統合 DB 機能の役割と標準化ポイント
統合 DB 機能には、次の 2 種類の実装方式があります。
・

公開 DB 方式（業務ユニット相当の SOAP インタフェース）
統合 DB 機能として、物理的な DBMS に公開対象の 2 次データ（提供側から提供されたデータ）を保持し、この 2 次データを介してデータを受け渡す方式です。

・共通インタフェース方式
統合 DB 機能内に物理的な DBMS による 2 次データの保持を必須とせず、提供側業務ユニットから公開される情報を利用側業務ユニットが必要とする情報として仮想的にアクセスするためのプログラ
ムとして構成された統合 DB 機能です。

-7-

「提供側業務ユニット」と「利用側業務ユニット」
自らデータを管理（保持）して、他の業務ユニットにデータを提供する役割を持つ業務ユニットを「提供側業務ユニット」、他の業務ユニットのデータを利用（参照）する業務ユニットを「利用側業務ユニット」と呼びます。これは、データ交換における業務ユニットの役割により区別するもので、1 つの業務ユニットが「提供側業務ユニット」として他の業務ユニ
ットにデータを提供し、「利用側業務ユニット」として他の業務ユニットのデータを利用するのが一般的です。
統合 DB 機能の視点からは、統合 DB 機能にデータを提供する役割を持つ「提供側業
務ユニット」、統合 DB 機能を利用する「利用側業務ユニット」と、統合 DB 機能に関する役割によって使い分けています。

統合 DB 機能は、業務ユニット間のデータ連携時に、性能、その他の要件から柔軟にデータ交換を行えるように、必要に応じて採用を検討するオプション機能です。

■ 導入時のメリット
統合 DB 機能を導入すると、次のようなメリットがあります。
・

自治体内における業務ユニット間のデータ連携を効率的に行えます。

・

データ交換の側面から、業務ユニットの差し替えが容易になります。

・

既存の業務システムへの地域情報プラットフォーム（以降、地域情報 PF）導入を、段階的に進めることができます。

・

利用側業務ユニットから SOAP インタフェースを使用して統合 DB 機能を利用すると、統合 DB 機能の方式や実装に依存することなく、利用側業務ユニットは必要なデータを取得できます。

・共通インタフェース方式の統合 DB 機能は、利用側から要求された最新のデータを提供側からオンデマンドで取得するため、リアルタイム性（情報の鮮度）が高くなります。

■ 留意事項
統合 DB 機能の導入時には、次の事項に留意します。
・統合 DB 機能は多くの業務ユニットのデータを公開する機能であるため、次のようなセキュリティに対する考慮が必要です。
-

自治体外部（サイト外）からの統合 DB 利用を制限する。

-

統合 DB 機能で公開するデータは、そのデータごとに、利用側業務ユニット単位で制御する。

-

統合 DB 機能で公開するデータは、データ項目ごとに、公開または非公開とする業務を規定す
る。

・

-

利用記録としてアクセスログを取得する。

-

提供側業務ユニットへのアクセス権は適切に管理する。

統合 DB 機能の運用が停止すると、地域情報 PF 全体の業務が継続できなくなるため、運用への配慮が重要です。運用に関する事項は、特に採用する製品が持つ機能に依存する部分が多いため、製品の利点や留意点を考慮して検討します。
-

メタ定義や環境設定類は、構成変更ごとに確実なバックアップを取得し、復旧可能な状況にする。

-

運用時の負荷見積や検証を確実に行い、柔軟な負荷分散によってスケーラブル性を確保す
る。

- 8 -

-

冗長運転構成によって可用性を確保する。

公開 DB 方式の統合 DB 機能の導入時には、次の事項に留意します。
・

物理的な DBMS で 2 次データの集中管理を行うため、統合 DB 機能に対する提供側および利用側
からのアクセスが集中し、性能が劣化する恐れがあります。性能への配慮が特に重要です。

・

統合 DB 機能で交換対象の 2 次データの実体を保持して管理するため、統合 DB 機能内の DBMS
が管理するデータベース容量に留意する必要があります。

共通インタフェース方式の統合 DB 機能の導入時には、次の事項に留意します。
・

すべてメモリ上で処理されるデータ統合ミドルウェアによる実装、および専用アプリケーションによる実装では、複数のデータ統合サーバ（統合 DB 機能）を並列運用することが容易であるため、性能面で有利である一方、検索結果を処理できるだけのメモリ量に留意する必要があります。また、提供側
業務ユニットへの影響を抑える目的で提供側のレプリカを使用する場合は、提供側にレプリカ用のDBMS が必要です。

■ ユースケース
公開 DB 方式の統合 DB 機能の実装パターンを、図 2.2.2 に示します。
統合 DB 機能は物理的な RDBMS（リレーショナルデータベース管理システム）を使用して実装するのが一般的です。XML データベースを使用して実装することもできますが、この場合、多くの提供インタフェース、利用インタフェースは SOAP を使用して実装されます。
提供側
業務A

A1

利用側

公開用ＤＢ方式の統合DB機能
DBMS

A

ＰＵＳＨ型
Y データ登録
データ提供
サービス
機能
ﾌﾟﾛﾊﾞｲﾀﾞ
PUSH
ﾘｸｴｽﾀ（SOAP）（ＳＯＡＰ）

ＰＦ準拠
SOAP通信ﾌﾟﾛﾊﾞｲﾀﾞ

A2

Aｘ
PULL

ＰＦ準拠
SOAP通信
ﾘｸｴｽﾀ

ＰＵＳＨ型
データ提供
機能
PUSH
（ＳＱＬ）

ＪＤＢＣ
ＯＤＢＣ
など

C1

S
Q
L
機
能
・
更
新
系

業務C
（マスタ）

A3
機能
X

業務B

B1

業務X

レプリケーション機能

B2

レプリカ

C2

S
Q
L

ＪＤＢＣ
ＯＤＢＣ
など

ＳＱＬ
PULL

検索機能

機
能
・
参
照
系

レプリカ

図 2.2.2 公開 DB 方式の統合 DB 機能の実装パターン

-9-

B3

C3

共通インタフェース方式の統合 DB 機能の実装には、次の 3 種類が考えられます。
・

データ統合機能を持つ DBMS による実装
統合 DB 機能として 2 次データを保持せず、利用側からのリクエストに従って提供側にアクセスを行
い、ＰＵＬＬ型のデータ検索によってデータを獲得します。

・

データ統合ミドルウェアによる実装
統合 DB 機能に DBMS を使用しないで、データ統合ミドルウェアに提供側業務ユニットのスキーマと、利用側に必要なスキーマを定義し、ミドルウェア（またはそのアプリケーション）の機能として利用イン
タフェースを実現します。具体的には、利用側からの検索要求を統合 DB 機能が受け取ると、必要な提供側業務ユニットに対する検索要求に分解して提供側業務ユニットを検索し、その結果を統合して利用側に応答する処理が動的に行われます。

・

専用アプリケーションによる実装
利用インタフェースを含めて、地域情報 PF の統合 DB 機能専用のアプリケーションとして実装するパターンです。特徴や留意点は、データ統合ミドルウェアによる実装と同じです。

共通インタフェース DB の長所を最も引き出せる実装パターン
データ統合ミドルウェアによる実装が、オンデマンド、リアルタイム、柔軟な統合パターン、提供側の地域情報 PF 対応が容易など、共通インタフェース DB の長所を最も引き出せます。
データ統合ミドルウェアとしては、EII(Enterprise Information Integration)という分野のソフトウェア
が数社から提供されており、フェデレーション機能と呼ばれることもあります。

データ統合機能を持つ DBMS による実装パターンを図 2.2.3 に示します。
提供側

DBMS

業務A
（マスタ）

A1

ＰＦ準拠
SOAP通信ﾌﾟﾛﾊﾞｲﾀﾞ

ＰＦ準拠
SOAP通信
X
ﾘｸｴｽﾀ

ＰＦ準拠
SOAP通信ﾌﾟﾛﾊﾞｲﾀﾞ

PULL

Aｘ

ＰＦ準拠
SOAP通信
ﾘｸｴｽﾀ

業務X

A3

PULL

機能
X
SQL
ＪＤＢＣ、
ＯＤＢＣ
など

（マスタ）

B1

ビュー
B2

PULL

業務C

C1

ビュー
A2

A

業務B

（マスタ）

利用側

共通インタフェース方式の統合DB機能

ﾚﾌﾟﾘ
ｹｰｼｮﾝ

検索機能

B3

PULL

SQL
（レプリカ）

ＳＱＬ

ＪＤＢＣ、
ＯＤＢＣ
など

C3

ＪＤＢＣ、
ＯＤＢＣ
など

ビュー
C2

PULL

図 2.2.3 共通インタフェース方式の統合 DB 機能のデータ統合機能を持つ DBMS による実装パターン- 10 -

データ統合ミドルウェアによる実装パターンを図 2.2.4 に示します。
提供側

データ統合ミドルウエア
（ＥＩＩ）

業務A
（マスタ）

A1

ＰＦ準拠
SOAP通信ﾌﾟﾛﾊﾞｲﾀﾞ

ＰＦ準拠
SOAP通信
X
ﾘｸｴｽﾀ

A

仮想表
A3

ＰＦ準拠
SOAP通信ﾌﾟﾛﾊﾞｲﾀﾞAｘ

ＰＦ準拠
SOAP通信
ﾘｸｴｽﾀ

業務X

A3

PULL

機能
X
SQL
ＪＤＢＣ、
ＯＤＢＣ
など

（マスタ）

B1

ｽｷｰﾏ
B1

API
（ＪＤＢＣ，
ＯＤＢＣ,
など）

仮想表
B3

PULL

ＳＱＬ
検索機能

SQL
（レプリカ）
ﾚﾌﾟﾘ
ｹｰｼｮﾝ

B3

PULL

業務C

C1

ｽｷｰﾏ
A1

PULL

業務B

（マスタ）

利用側

共通インタフェース方式の統合DB機能

ＪＤＢＣ、
ＯＤＢＣ
など

C3
ｽｷｰﾏ
C1

仮称表
C3

PULL

図 2.2.4 共通インタフェース方式の統合 DB 機能のデータ統合ミドルウェアによる実装パターン
専用アプリケーションによる実装パターンを図 2.2.5 に示します。
提供側

専用
アプリケーション

業務A
（マスタ）

A1

利用側

共通インタフェース方式の統合DB機能

ＰＦ準拠
SOAP通信ﾌﾟﾛﾊﾞｲﾀﾞ

AX

ＰＦ準拠
SOAP通信ﾘｸｴｽﾀ

ＰＦ準拠
SOAP通信ﾌﾟﾛﾊﾞｲﾀﾞ

PULL

Aｘ

ＰＦ準拠
SOAP通信
ﾘｸｴｽﾀ

機能
X
API
（ＪＤＢＣ，
ＯＤＢＣ,
など）

ＪＤＢＣ、
ＯＤＢＣ ＳＱＬなど 検索機能

（マスタ）

B1

PULL

業務C

C1

A3

PULL

業務B

（マスタ）

業務X

ﾚﾌﾟﾘ
ｹｰｼｮﾝ

B3

PULL

SQL
（レプリカ）

ＳＱＬ
検索機能

C3

ＪＤＢＣ、
ＯＤＢＣ ＳＱＬなど 検索機能PULL

図 2.2.5 共通インタフェース方式の統合 DB 機能の専用アプリケーションによる実装パターン- 11 -

BPM 機能

2.3■ BPM 機能とは
ビジネスプロセス管理（Business Process Management）機能（以降、BPM 機能）とは、自治体の業務サー
ビスおよび自治体間、官民連携業務サービスの実行を制御する機能です。BPM 機能は、業務サービス
インタフェースを組み合わせてビジネスプロセスを組み上げ、ワンストップサービスや高付加価値サービスを構築できます。
BPM 機能は、プラットフォーム通信標準仕様に従う機能内容でなければならず、プロセス定義のためのスクリプトは、プラットフォーム通信標準仕様に従うものでなければなりません。
アーキテクチャには、SOAP 通信などと親和性が高く、最新版である WS-BPEL(Web Services Business
Process Execution Language) 2.0 を全面的に採用しています。WS-BPEL2.0 の、次の機能を実現できる必要があります。
・

基本アクティビティ（receive、reply、invoke）対応

・

構造化アクティビティ（sequence、flow、if、while）対応

・

変数処理（assign、XPath1.0 利用可能）対応

・

エラーハンドリング（fault、throw）対応

ワンストップサービスとは必要とする作業を一度の手続きですべて完了でき、真に利便性に優れた住民サービスを提供できるサービスのことです。

日本 BPM 協会の定義によるビジネスプロセスマネージメント
日本 BPM 協会は、ビジネスプロセスマネージメントを次のように定義しています。
・ 経営目標を実現させる業務（ビジネスプロセス）を迅速に設計し、その改善サイクルを継続的に進める新しい経営手法
・ 業務の可視化、デザイン、業務プロセス構築、業務モニタリング、業務実績評価という一連の業務改善サイクルを、ICT(Information and Communication Technology)を利用して継続的に実施すること
地域情報 PF では、このビジネスプロセスマネージメントの考え方を広義概念として取り込み、普及促進を図っています。

BPM 機能は、ワンストップサービスなどでサービスを順次実行するときに利用するオプションです。システム構成上、サービス通信を実施するため、PF 通信機能を有することが前提となります。

- 12 -

■ 導入時のメリット
BPM 機能を導入すると、次のようなメリットがあります。
・

高付加価値で利便性の高いワンストップサービスを導入できます。
さらに、BPM 機能を応用した利便性の高いサービスを提供できます。

・

自治体内のプロセスと同等のインタフェースを維持しながら、次のようなことを実施できます。
-

単純に繰り返して行われる操作プロセスの自動化-

不必要な手続きの効率化、省力化-

1 つの自治体内部のビジネスプロセスの改善-

民間等へのアウトソーシング、BPO(Business Process Outsourcing)■ 留意事項BPM 機能の製品選定時には、次の事項に留意します。
・

プラットフォーム通信標準仕様の要件を満足する製品であること

・

セキュリティ要件に対して準拠、または柔軟に対応できる製品であること

・

MDA などの開発環境と親和性が高く、開発および実行環境が統合化された製品であること

・安定したサポートが供給され、実績のある製品であること

・システム運用ツールと連携できる製品であること

次の技術的なポイントにも留意します。
・

トランザクション、補償動作
メッセージ交換パターンおよび異常系処理は、プラットフォーム通信標準仕様で定める方式に従います。

・

アクティビティセット
独自アクティビティセットの利用を含めた拡張機能をどこまで利用するか、そのポリシーを統一的に定めておきます。

・

WS-BPEL の記述
WS-BPEL の記述が複雑な構造になっているものについては、共通ルーチンとしてローカルに配置されるサービス化を行います。
ローカルサービス化にあたっては、処理性能とのトレードオフを考慮して実装します。

・モニタリング機能との連携
障害発生時の対応などに有効なモニタリング機能と連携するためのインタフェースをサポートできるように留意します。

・「リクエスト・レスポンス型同期型受領 Ack＋非同期型レスポンス」時の対応
地域情報プラットフォームで選択可能なメッセージ交換パターンの 1 つである「リクエスト・レスポンス型同期型受領 Ack＋非同期型レスポンス」時のリクエストの処理とレスポンスの処理を連携させる方
式を、業務ユニットの機能の一部として実装します。

・WS-BPEL が受信側となった場合の非同期型の受信タイムアウトの実装
呼出元の業務ユニットで、タイムアウト監視を行うことを推奨します。

・

排他制御
排他制御は、一般には業務ユニット内部での実施を基本とします。しかし、これが困難である場合は、
WS-BPEL 処理系側でも特別な対処を考慮します。

- 13 -

■ ユースケース
一般的な民間企業で BPM 機能を導入する手順については、いくつかの文献や、各ベンダが提供するホワイトペーパーなどが存在します。たとえば、日本 BPM 協会の定義している BPM 推進フレームワークが該当します。
地域情報 PF の展開においても、ほぼ同等の技術的な考え方を継承しています。ただ、自治体などの個々の組織体に限らず、全国の自治体、関係団体において高付加価値で利便性の高いワンストップサービスを共通して定義するために、標準的な業務標準、業務インタフェースを定義するという点において、一般の民間企業におけるビジネスプロセスマネージメントの実施手順とは質的に異なる面があります。その差分を、図 2.3.1 に示します。
広義のビジネスプロセスマ
広義のビジネスプロセスマ
ネージメントと関連する範囲
ネージメントと関連する範囲
標準仕様検討運用、サービス品質の監視
各自治体のシステ
ム管理者からの仕様案に対する要請

全国地域情報化推進協会(APPLIC)における(APPLIC)における標準業務モデルの策定に関する作業
標準仕様の
取り込み

公開・展開
ビジネスプロセスの改善・再構築

各ベンダからの提案

各ベンダによる対応
パッケージソフトウェア製品・サービスの開発作業

各自治体での
運用/
運用/行政サービスの改善活動

パッケージソフトウェア製品を用いないシステム構築

適用後、ソフトウエア
差分の取り込み

運用開始

各自治体への個別案件対応作業

製品の適用
製品とのFit & Gap評価

システム構築図 2.3.1 地域情報 PF におけるビジネスプロセスマネージメント
上図の一点鎖線で囲まれた部分は、各自治体、関連団体によって実施されるモデリング(分析)から再設計などの、一連のビジネスプロセスマネージメントに関連した作業に該当します。
地域情報 PF では、自治体固有の問題を除外したうえで、汎用的な標準業務モデルの構築を目指しています。これが、従来のフレームワークに基づくアプローチ方法とは異なる点の 1 つです。

・

ワンストップサービスの導入については、『地域情報プラットフォームガイドライン』の「第 4 章 ワンス
トップサービスの導入」を参照- 14 -

セキュリティ対策

2.4

本節では、地域情報 PF に関連するネットワークのセキュリティ対策について説明します。
最初にセキュリティの脅威について説明し、自治体間および自治体と外部接続のセキュリティ対策と課題について説明します。

■ セキュリティの脅威
地域情報 PF に関連するネットワークと接続パターンを、図 2.4.1 に示します。
電子申請者（人系）（住民、企業）地域ﾎﾟｰﾀﾙ

地域企業

Webブラウザ

⑪
JPKI
RA&VA

⑨
⑦

⑩

LGPKI
RA&VA

LGWAN
RA&CA

ローカル
RA&CA

自治体内
基幹系LANLGWAN-ASP

DMZ
周辺 LGWAN

外接系

自治体A

一般商用
一般商用
RA&CA
一般商用
RA&CA
RA&CA

⑧

Internet

自治体内
情報系LAN

④

②

③
ＧＷ

①

0

⑤

地域WAN
（広域ネットワーク等）

図書館、病院
公的機関
LGPKI：地方公共団体組織認証基盤
JPKI：公的個人認証サービス⑥

霞が関ＷＡＮ

自治体B

官庁

LGWAN （総合行政ネットワーク）の解説：http://www.lasdec.nippon-net.ne.jp/lgw/lgwan.htm

図 2.4.1 地域情報 PF に関連するネットワークと接続パターン
このようなネットワーク接続において、次のようなセキュリティへの脅威に対応する必要があります。
・

なりすまし（他人になりすましたサービスの利用、文書の偽り）・否認（送信の否認、受信の否認など）

・

通信上の盗聴（送信データの盗聴）

・

通信上の改ざん（送信データの改ざん、破壊）・

データへの不正アクセス（データの改ざん、漏えい、削除、追加）

・システムへの不正侵入（システム侵入、不正なサービス利用）

・

ウィルス侵入（感染したビジネス文書やウィルスそのものが侵入）

・

DDoS 攻撃（多量の送信データを送信してシステム性能を劣化させる）

・

プライバシ情報の不正利用、漏えい- 15 -

これらのセキュリティへの脅威に対応するために、自治体などの 1 つの組織がセキュリティポリシーを定めています。管理対象全体のセキュリティを確保するための技術は、既存の PKI 技術やファイアウォールなどのインターネットの技術として確立されています。
自治体間や自治体と民間間など、異なるサイト間におけるセキュリティ上の課題を図 2.4.2 に、セキュリテ
ィ上の課題への対策技術を、表 2.4.1 に示します。

サイトＡ（例、Ａ自治体）のＰＦ対応システム
サイトＢ
正式
シス
テム
（正式
使用）

ネット上
の
不正
シス
テム
（不正
使用）

(4）改ざん(3)盗聴（２）
提出の否認、受領の否認、
文書作成の否認(7) ウィルス浸入
正式システムＡ（サービス）
認証・認可
ポリシＸ
正式
システムＢ
（サービス）
認証・認可
ポリシＸ(1)なりすまし(6）システムへ
の不正侵入

正式
システムＣ
（サービス）
認証・認可
ポリシＺ(8) DDOS攻撃(9)プライバシー
情報の不正利用、
漏えい(5) システム
データへの不正アクセス(4）改ざん(10)漏洩
(1)なりすまし

正式システム(11) 正式システムの不正使用

図 2.4.2 異なるサイト間におけるセキュリティ上の課題
表 2.4.1 異なるサイト間におけるセキュリティ上の課題への対策技術
対策技術

内容

認証（Authentication）

本人（クライアントのユーザ、マシン、サービス）であることを判定し証明する

・なりすまし・不正侵入

認可(Authorization)

認証されたユーザに対し、システムまたはアプリケーションの使用許可を判定する

・盗聴
・漏えい

秘匿性確保

通信内容を第三者が参照できないようにする

電子署名と検証

情報に対して電子的な署名を行い、情報の改ざ
ん検知や署名者の確認を可能にする

・盗聴
・漏えい
・なりすまし・改ざん

サービス認証ワンストップ用のサービス認証・サービス認可情報の管理、伝播方法、およびそのモデルに関する技術で、シングルサインオンなどを実現する

・なりすまし・データの不正アクセス・不正侵入

プライバシ情報公開

認証時、認可時、およびサービス処理時におけるプライバシ情報の不正利用防止および交換許諾

・プライバシ情報の不正利用
・漏えい

監査証跡

正式なシステムを不正に使用していないか、情報を統一的に収集し監査したい場合に使用する・正式システムの不正使用

ウィルス対策

感染したビジネス文書やウィルスそのものの侵入の検知や、感染したデータの駆除など

・ウィルス侵入DDoS 攻撃対策

負荷集中の監視やネットワーク機器の IP フィルタリング設定などで、複数のサイトからの特定サイトへの集中アクセスによるシステムダウンやサービス停止に対応する

・DDoS 攻撃

サービス認可連携- 16 -

対象課題

自治体のネットワーク設置状況
平成 18 年度 APPLIC で実施の自治体アンケート（母数 108 自治体）の結果を次に示します。
・ 54%の自治体が、基幹系業務ネットワークおよび内部系業務ネットワークを物理的に分離しています。
さらに、この自治体のほとんどが、基幹系業務ネットワークおよび内部系業務ネットワーク
は分離していますが、ファイアウォール、VLAN で接続可能としています。
・ 25％の自治体が、ネットワーク分離の条例などを制定しています。
・ 97％の自治体が、セキュリティポリシーを策定しています。
自治体に地域情報 PF を導入するときは、ネットワークポリシーを参照し、システム連携の方針を策定する必要があります。

■ 自治体間でのセキュリティ対策と課題
ここでは、地域情報 PF に基づく自治体間のシステム連携に影響を与えるセキュリティ要件について、ユースケースを考慮しながら説明します。
地域情報 PF で想定する、申請者、地域ポータル、自治体、連携する自治体、民間のシステム連携のユースケースを図 2.4.3 に示します。
地域ポータル
ポータル
BPM

自宅
インターネット

連携する自治体
地域ポータル管理者

住民
自治体システム
自治体システム（共同センタ or 役所）

企業

ネットワーク

業務
ユニット

受け付け
BPM

企業担当者

業務
ユニット

自治体職員

認証機関
（民間）

受け付け
BPM

自治体職員

認証機関
（国）

民間企業
業務
ユニット

図 2.4.3 地域情報 PF で想定するシステムのユースケース例
上図のユースケースでは、地域ポータル、自治体、連携する自治体および民間をサイトとみなし、主に次の 4 つの業務処理を想定しています。
・

申請者による申請書の送信

・申請者による進捗状況の問い合わせ- 17 -

・

自治体から他自治体への照会

・

自治体による公文書の配布

これらの業務処理シーケンスを、図 2.4.4 に示します。
民間
地域
ポータル

申請者

自治体

業務
他自治体
ユニット

① 申請書フォーマット検索・取得② 申請書送信④ 進捗状況問合せ申請書の送信③ 申請書転送⑤ 進捗状況問合せ

進捗状況
問合せ

⑥ 進捗状況通知
⑦ 進捗状況通知
⑧ 照会⑨ 照会結果他自治体への照会⑩ 公文書配布⑪ 交付物取得依頼

公文書の配布⑫交付物送付図 2.4.4 地域情報 PF のシステム連携で想定する処理の流れ
上図で想定するセキュリティ要件を、次に示します。
・

データは他の人に読み取れられないようにすること： 秘匿性確保・

データの改ざんを検出できること： 改ざん防止、なりすまし防止・

他のサイトからの処理依頼において、依頼元を認証できること： なりすまし防止・

正式システムの不正使用を監査できること： 不正使用・

複数サイト間の連携処理に認証や認可処理の一元化が必要な場合、認証認可が連携できること： 改ざん防止、なりすまし防止・

複数サイト間の連携処理に認証や認可処理の一元化が必要な場合、認証のための他サイトへのプ
ライバシ情報公開制御ができること： プライベート情報の不正利用や漏えい、なりすまし、不正侵入の防止

自治体内システムの職員端末とサーバマシン間のセキュリティに関する仕様
自治体内システムの職員端末とサーバマシン間のセキュリティに関しては、すでに自治体内で採用されている仕様があり、プラットフォーム標準仕様としては特に規定していません。

- 18 -

■ 自治体の外部接続のセキュリティ対策と課題
ここでは、地域情報 PF における自治体の外部接続の実現と検討ポイントについて説明します。
自治体の外部接続の実現イメージを、図 2.4.5 に示します。
外部接続のネットワーク構成例

ＤＭＺ
ﾘﾊﾞｰｽ
ﾌﾟﾛｷｼ

・・・

ｳｲﾙｽ
ﾁｪｯｸ

Ａ．自治体
ｻｰﾋﾞｽ受付

Ｂ．データの
公開受付

DMZ
周辺

外部接続系
Ｃ．受付
ＧＷ

DB等の
GW

・・・

自治体内部
業務
ﾕﾆｯﾄ

ＢＰＭ

・・・

統合ＤＢ

図 2.4.5 自治体の外部接続の実現イメージ（ネットワークとシステム構成）
上図では、ネットワークのセグメントとして、次の 3 エリアを想定しています。
・DMZ（緩衝エリア、外部と内部とが両方アクセスできるエリア）
ファイアウォール、NAT（アドレス変換）、リバースプロキシ、プロキシなどを設置

・

外部接続エリア（外部接続サーバを配置）
外部に公開されるサービスを実施するサーバを配置し、自治体内部とデータ交換する

・

自治体内部エリア
自治体内部のサーバ群（情報系ネットワークと基幹系ネットワークで分断されている場合がある）

このような場合、次のような対策が必要です。
・

自治体内部のサーバと、外部接続サーバとデータ交換するサーバは、IP リーチャビリティを遮断する
ため、DB や共有サーバを中継して、外部接続サーバとデータ交換します。

・

同様に、自治体内部で情報系ネットと基幹系ネットで分断されている場合は、DB や共有サーバを中継してデータ交換します。

- 19 -

次に、外部接続サーバと外部、自治体内部とのサービス呼び出しの関連図を、図 2.4.6 に示します。
これは、論理的なサービスの呼び出し図です。物理的にネットワークが分断されている場合は、データ交換やサービス呼び出しの中継を行うゲートウェイ機能を、両方のネットワークの中間に設置する必要があります。
（①-1） 業務ユニットインタフェース

地域
ポータル

Web
ブラウザ

他サイトの
サービス

（①-2） 統合DBインタフェース（②-1） 業務サービスインタフェース（②-2） BPMインタフェース

（②-3）

（②-3）

（②-3）サイト間インタフェース（③-1）統合DB固有インタフェース

Internet
（②-3）

（②-3）

DMZ
周辺

自治体
ポータル
（②-1）
（②-2）

Ｂ．データの
公開受付

Ｃ．
受付
ＧＷ

Ｃ．
受付
ＧＷ
（②-3）

（②-1）

（②-2）

（②-1）

（②-1）

LGWAN

（②-2）

BPM

BPM

（サイト内業務サービス）

（②-2）

（②-2）

（②-1）

（②-1）

（②-1）

DMZ
周辺

（②-3）

Ａ．自治体ｻｰﾋﾞｽ受付（サイト間業務サービス）（②-1）

業務ユニット業務ユニット業務ユニット業務ユニット（サイト内業務サービス）（サイト内業務サービス）（サイト内業務サービス）（サイト内業務サービス）

（①-1）
(③-1)
（①-2）

自治体
内部

（①-2）

他の自治体内部統合DB
Ａ：申請手続きのＧＷ
Ｂ：サイト外にデータを公開する(モニタリング、
統合ＤＢサブセットなど）
Ｃ：外部のサービスからの依頼を汎用的に受付、内部の業務サービス呼び出す

ネットワークが分断されているためゲートウェイの導入が必要

図 2.4.6 自治体の外部接続の実現イメージ（サービスの呼び出し）- 20 -

認証・認可機能

2.5■ 認証・認可機能とは
認証とは、本人であることを判定し証明することです。ここでいう本人とは、クライアントのユーザ、マシン、サービスの抽象的表現です。
認可とは、認証されたユーザに対し、システムまたはアプリケーションの使用許可を判定することです。
地域情報 PF においては、自治体職員の認証・認可と、公開している Web サイトのログイン時に行う住民に対する認証・認可を考慮する必要があります。
自治体職員の認証・認可では、次の 2 つを考慮します。
・

業務ユニットの職員認証
これは地域情報 PF の標準規定の範囲外ですが、次の 2 つの認証方式が採用されています。
-

個別業務システムごとのログイン（認証と認可）-

Web アプリケーションや統合ソフトウェアによるシングルサインオン（SSO）

現在は、認証方式も個別のベンダーソリューションが多く採用されています。
・

サイト間の職責認証
今後、自治体間で職員による問い合わせ型の文書照会型のサービス（自治体間での処理依頼と結果通知）が、職員の職責で実施される場合が想定されます。
この場合の処理フローを、図 2.5.1 に示します。
-

依頼元自治体内の業務ユニットで、職員を認証し、起案、承認後、この職員が依頼文書に対し
LGPKI で職責署名（PF 自治体組織電子署名・検証仕様）し、他自治体へ依頼文書を送付する。

-

受けた自治体は LGPKI の証明書検証により、依頼元の職責を確認（PF 自治体組織電子署名・検証仕様）し、依頼された照会業務を職員が業務ユニットで実施し、回答文書を作成し、返す。
自治体A
認証機能
職員の
認証処理

自治体B
照会依頼受付

業務ユニット

照会文書の
署名検証
照会文書
処理の実施
を受付一覧
へ確認

依頼元の職
責証明書で
照会分文書
に電子署名
照会文書
の自治体へ
の送付

回答文書の
確認

照会文書の
受付一覧
から選択
照会文書
処理の実施
照会文書
の結果文書
作成

照会結果受付

上長の審査

照会結果
受付
サービス

回答者の
職責証明書
で回答文書
に電子署名

回答文書の
署名検証

認証機能
職員の
認証処理

照会依頼
受付
サービス

照会文書
の作成と
照会状の
審査依頼
上長の審査

自治体A
職員

業務ユニット

回答文書
を依頼自治
体へ送付

依頼文書へ
の回答文書
として登録

図 2.5.1 サイト間の自治体職員の職責認証の処理方式- 21 -

自治体B
職員

住民に対する認証・認可では、次の 2 つの場合を考慮します。
・

住民が単一 Web サイトを利用する場合
これは、地域情報 PF の標準規定の範囲外です。
この場合の処理フローを、図 2.5.2 に示します。

・

住民がポータル経由で複数 Web サイトを利用する場合
地域情報 PF では、住民が地域ポータルで認証を受け、自治体や民間の地域サービスを使う場合が想定されます。この場合、PF 通信で接続する自治体などのサービスの認証処理のための ID と認証
情報（パスワードなど）を、地域ポータルに登録する必要があります。この実現方式の例を、図 2.5.3に示します。
なお、この実現方式には、いくつかの課題があります。課題への対策については、以降の「■ユースケース」の【サービス認証連携】を参照してください。

IDと認証するための情報（PW等）

サービスサイト※属性の例「名前」「年齢」「e-mail」「住所」「性別」等

認証用リポジトリ
認証確認機能（IDの認証を確認）<ID, PW, 属性>

ﾌﾞﾗｳｻﾞ

人
（
）

認証情報
登録管理
機能

NG（否認）

OK?

OK（クッキーによりセッションを引き継ぐ）
ID、クッキー、
処理依頼

NG（権限がない）
処理実行結果

広義の認証機能

認可機能（処理依頼に対しID者が許可されているかの確認）

認可ポリシ

認可情報
（ACL)
登録管理
機能

<属性.
許可する
サービス>

OK?

広義の認可機能サービス処理１

処理依頼の実行サービス処理２
サービス処理３

図 2.5.2

Web アプリケーションにおける認証・認可の処理方式

ﾎﾟｰﾀﾙの認証が通ると自治体や民間の問合せ
系のサービスが全て使え、必要な情報が集約され依頼者へ提示。

住民

クライアントﾎﾟｰﾀﾙ独自認証
ﾕｰｻﾞ情報地域ポータル

注意）個別サイトのID/PW
情報をポータルが保持するため、ﾎﾟｰﾀﾙのﾕｰｻ
ﾞ審査やﾕｰｻﾞ情報の管理の責任がある。

PFサイト間認証
個別ID/PW
自治体A
ﾕｰｻﾞ情報個別ID/PW
自治体B
ﾕｰｻﾞ情報個別ID/PW
民間
ﾕｰｻﾞ情報図 2.5.3 住民がポータル経由で複数 Web サイトを利用する場合の認証・認可実現方式例- 22 -

■ 導入時のメリット
サイトをまたがる業務連携システムにおける認証・認可情報を、継承できます。

■ ユースケース【認証】
地域情報 PF では、次の 4 つが認証の対象として想定されます。
・人（Web ブラウザなどのアプリケーション画面を操作する人）・サービス（Web サービス）

・

文書

・

マシン

認証の対象「人」は、PF 標準規定の範囲外となります。
これらの認証のユースケースと実現技術の関係を図 2.5.4 に、認証の要件を表 2.5.1 に示します。
区分

技術要件

マ
シ
ン
系

・マシーンからの接続要求の認証⇒
マシン認証

ユースケース

・Ｌ１
ﾏｼﾝ
ﾏｼﾝ

自治体内

民間－自治体自治体－自治体

標準化済み：
・SSL(TLS)認証
・ＨＴＴＰベーシック
認証

標準化済み：
・ SSL(TLS)認証
・ＨＴＴＰベーシック認証

・サーバ認証・クライアント
認証

・自治体内：独自
・自治体間：LGPKI
・民間と自治体：民間

標準化対象：
申請を各ユニット
へ：

標準化対象：
地域ポータルから自治体へ・サービス認証・自治体内：独自
・自治体間：LGPKI
・民間と自治体：民間・WSS（ID/PW)
・独自・WSS（ID/PW)
・WSS+SAML (★)

標準化対象外職員ポータル：

標準化対象外住民が官と民へ：
・SAML (★)
・クッキー（独自）・SSO（ｼﾝｸﾞﾙｻｲﾝｵﾝ)

・自治体内：独自
・自治体間：未整備
・民間と自治体：
未整備

標準化済み：
自治体間：・電子申請形式

・署名検証
・証明書検証・自治体へ申請：JPKI
・自治体間：JPKI
・民間と自治体：(JＰＫＩは使えない、
新しい枠組みが必要）

一般用語

証明書・運用

ﾏｼﾝ

Ｌ１

サ
ー
ビ
ス
系
Ｌ２

Web
系
Ｌ３

文
書
系

・依頼元のサービス
認証⇒
サービス認証

WS
WS

・Ｌ２－１
・Ｌ２－２

WS

・人に割付けた
ID/PW or
証明書
でブラウザからのアクセスを認証⇒Webユーザ認証（PF標準規定の範
囲外）・データ作成者の
認証
⇒
電文認証

・Ｌ３
Web
人

・クッキー（独自）

ブラウザ使用

Web

人

AP

・Ｌ４－１
署名

Data

検証

・Ｌ４－２

標準化済み：
・電子申請形式

・Ｌ４－３

民間－自治体：×標準化未だ

Data

Ｌ４

人： 申請者や自治体職員など特定の個人を示し、人がブラウザや電子申請ソフトウェアを使って操作することを意味する。
WS：Web サービスのサービス要求者や Web サービス提供者のアプリケーションを示す。
Web：Web アプリケーションを示し、人が Web ブラウザで操作する対象アプリケーションを示す。
AP：Data の署名を検証し、正しい署名のとき、その申請者の権限に基づき、処理を行うアプリケーションを示す。
(★) 異なる運用組織間での SSO の実現では、IDP（ID プロバイダ）の運営母体の不在が課題になる。

図 2.5.4 認証のユースケースと実現技術の関係- 23 -

表 2.5.1 認証の要件定義例＃

誰（何）を（IDの保持者）

IDを何によって認証しIDに何の属性を付与するか？

Ｌ１

マ
シ
ン
系

・サーバ
（レスポンダ側）
・クライアント（リクエスタ側）

・SSLサーバ証明書
・SSLクライアント証明書
・HTTPベーシック認証

マシーンの分類：
・接続許可

Ｌ２

サ
｜
ビ
ス
系

・ＰＦ管理主体を同じくするサービス（ＡＰ）
・ＰＦ管理が異なるサービス（ＡＰ）
・異なるPFのサービス（ＡＰ）

認証連携：
・Ｗｅｂサービスセキュリティ
・ＸＭＬ署名、ＳＡＭＬ 等

同一ＰＦ内：
・認証グループ
異なるＰＦ間：
・管理団体

Ｌ３

W
e
b
系

・一般の人
・職員（事務系）
・職員（システム系）
・民間サービスの人（事務系）
・民間サービスの人（システム
系）

個人認証：
・電子証明書（ＰＫＣＳ＃１２）認証・パスワード認証
・ICカード認証や生体認証
シングルサインオン：・シングルサインオン（SSO)技術

ロール：
・自治体内の住民・システム管理者（自治体）
・業務実施者（自治体）
・システム管理者（民間）・業務実施者（民間）

文
書
系

・申請文書
・起案文書
・交付文書

個人認証：
・電子証明書（ＰＫＣＳ＃１２）認証・ＸＭＬ署名ロール：
・自治体内の住民・システム管理者（自治体）
・業務実施者（自治体）

Ｌ４

【認可】
地域情報 PF では、認可については規定していませんが、認可の要件を表 2.5.2 に、認可のユースケー
スを図 2.5.5 に示します。
表 2.5.2 認可の要件
ID に対する属性

認可の条件

許可の対象

認可の範囲

申請人

サービス時間内申請（CRUD）

同じ自治体内システム管理者（自治
体）

何時でも

システムモニタ（CRUD）

同じ自治体内の全システム

業務実施者（自治体）

サービス時間内

ビジネスプロセス状態（R）

同じ自治体内の BP 状態のみシステム管理者（民間）

サービス時間内

自治体受付システムの状態（R）

管理対象自治体の受付シス
テムのみ

業務実施者（民間）サービス時間内

自治体の××文書（R）

自治体内で正式承認されたもののみ
C：作成、R：参照、U：更新、D：削除

ID＋認証情報
認証処理
処理依頼内容IDの属性情報権限無しの場合
処理依頼
ソフトウェア

認可処理（IDの属性に基づき、処理依頼を許可して 良いかを判定）

エラー
権限有りの場合
処理結果

処理１
処理２
処理３

- 24 -

図 2.5.5 認可のユースケース【サービス認証連携】
Web サービスなどを利用したワンストップサービスを実現する場合、一般的な Web アプリケーションとは異なり、必ずしもエンドユーザがサービスの利用者とはなりません。このため、呼び出された側の Web サービスではエンドユーザの認証を必ずしも行うことができないという問題があります。
例：エンドユーザが Web ブラウザを用いてポータルにログインした後、ポータルが自治体 A の Web サー
ビスを呼び出す場合呼び出された自治体 A の Web サービスで、エンドユーザの認証を行うには、ポータルと自治体 A で同一のユーザ ID を共有し、これを使う手段が考えられます。しかし、これを行うには、ポータルとポータルが呼び出す全サービスで、ユーザ ID の共有が必要となります。
これを自治体・民間間のように異なる ID 体系で連携して適用するのは、困難です。
これに対応するための、自治体と民間でサービス認証処理を連携させる場合のユースケースを、図 2.5.6に示します。
ユースケース：入出金情報のマイポータル画面の提供【現行技術】
アカウントアグリゲーションサービス

前提条件：「各サイト別に個別にＩＤ管理されていること」

プライバシ保護型認証連携技術

概要各種サイトのID/PWをアカウントアグリゲーション
各種サイトのID/PWをアカウントアグリゲーション
サービスに登録する。以降、アグリゲーション
サービスに登録する。以降、アグリゲーション
サービスにアクセスするだけで、見たい情報をサービスにアクセスするだけで、見たい情報を一覧表示できる。
一覧表示できる。

各種サイトのID/PW発行した仮IDをIDPに登録し、各種サイトのID/PW発行した仮IDをIDPに登録し、IDP用のIDを発行する（各種サイトで紐付け管理）
IDP用のIDを発行する（各種サイトで紐付け管理）
以降、IDPへアクセスするだけで、見たい情報を
以降、IDPへアクセスするだけで、見たい情報を一覧表示できる
一覧表示できる

効果・利用者でのID・パスワードの管理が簡便・利用者でのID・パスワードの管理が簡便
・見たい情報と一覧表示できる
・見たい情報と一覧表示できる・利用者でのID・パスワードの管理が簡便・利用者でのID・パスワードの管理が簡便
・見たい情報と一覧表示できる
・見たい情報と一覧表示できる・仮IDを使用し、プライバシ情報の漏洩を防止
・仮IDを使用し、プライバシ情報の漏洩を防止

住民
住民

概
念
図

住民
住民
住民
住民

アクセス
アカウントアグリゲーションサービス
アカウントアグリゲーションサービス
各サイトの
ID/PW管理
ID/PW
ログイン

ID/PW
ログイン

金融機関
金融機関

自治体A
自治体A

口座情報等照会

手当等支給状況

各
サ
イ
ト
の
情
報
を
表
示

IDP
IDP

ID
認証

ログイン
(ID/PW)

各サイトの
ID/PW管理

仮ID
仮ID
仮ID
認証

各サイトの情報を表示
地域ポータル
地域ポータルサイトの情報を 仮ID
提供

金融機関
金融機関

自治体A
自治体A

手当等支給状況
口座情報等照会

納付状況

図 2.5.6 サービス認証処理連携のユースケース- 25 -

納付状況

サイトの情報を提供【認証・認可連携】
自治体間の情報照会処理における認証・認可連携のユースケースを、図 2.5.7 に示します。このユースケースでは、権限管理基盤技術を使用しています。これは、自治体間の所得照会などの業務において、将来的な適用の検討が想定されます。
A自治体

B自治体
IDP（認証）サーバ
PDP(認可）サーバ

業務ユニットA
認証オーソリティ

他自治体情報照会 ID/パスワード① ログイン

利用者情報
リポジトリ

認可オーソリティ

アクセス制御ポリシィ

認証アサーション
認証アサーション＋ 属性オーソリティ② 属性要求情報要求

属性アサーション

PDP(認可）サーバ

③
認可要求

携
連
の
報
情
限
権

認証アサーション＋
属性アサーション

アクセス権限の要求

認可決定応答（許可 or 却下）

認可オーソリティ⑥

認可決定応答（許可 or 却下）

業務ユニットB

アクセス制御ポリシィ

他自治体
情報照会

④

⑤ 照会受付

認証アサーション＋属性アサーション＋業務情報

受付
認可要求

⑦

照会

DB

図 2.5.7 権限管理基盤技術を使用した認証・認可連携のユースケース① Ａ自治体の業務ユニット A が、ある申請者の B 自治体での情報を照会したい場合に、他自治体情報
照会機能にログインする。
② IDP による認証を受け、認証アサーションと属性アサーションを受け取る。
③ 他自治体情報照会機能は、ログオンした職員が B 自治体へのアクセス権限があるかを PDP に対し問い合わせる。
④ 職員に権限がある場合は、情報照会に進み、B 自治体の業務ユニット B に対し認証アサーション、
属性アサーション、業務情報（対象の申請者情報等）を送付し、照会を依頼する。
⑤ B 自治体の業務ユニット B では、情報照会受付機能が④の認証アサーション、属性アサーション、業
務情報を受け取る。
⑥ 情報照会受付機能では、A 自治体から受け取った照会を依頼している職員に情報照会の権限があるかを PDP に問い合わせる。
⑦ 職員に権限がある場合は、対象申請者の情報を A 自治体に送信する。

権限管理基盤技術とは異なるサイト間の認可において、複数のアプリケーションで使用されるサービス利用者の権限情報を一元的に管理し、サイトをまたがったサービス利用者に対しても権限情報の整合性を維持する機能です。

- 26 -

2.6

モニタリング機能■ モニタリング機能とはモニタリング機能とは、散在する情報を Audit として収集する仕組みを提供し、実施状況の把握、進捗管理を通して「可視化」の基盤を提供する機能です。
SOA (Service Oriented Architecture)は、運用のポリシー、アーキテクチャが異なる複数組織間連携の基盤として注目を浴びています。これは、各組織が利用・保持する機能を外部から利用しやすい形に切り出し、サービスとして定義・提供し、さらには複数のサービスを組み合わせることでシステム間連携を実現
するアーキテクチャです。SOA 化が進展することで、組織をまたがるシステム間の連携を大規模に実現でき、この結果としてビジネスプロセスと呼ばれる大きなサービス実施、ワンストップサービスの実現が可能になります。
このように、高い潜在力を持つ SOA ですが、さらに、より高い価値を提供するためには、そのうえで進められるビジネスプロセスの実施状況・品質をモニタリングでき、サービス選択の幅が広いことも重要です。
ビジネスプロセスの実施状況・品質をモニタリングできれば、その品質を低下させているサービスや、それを実施しているシステムリソースを特定でき、対策を講じることができます。
なお、モニタリングの範囲はワンストップサービス実施時における BPM の追跡までとし、システム稼働状
況（パフォーマンス監視、生死監視、ネットワーク監視など）は対象外とします。

「Audit」とは「サービスやシステムリソースの、ある一時点の状態を示すもの」を一般化した名称です（「ログ」の概念を一般化したもの）。従来この概念は、話題となる領域によって「ログ」、「イベントログ」、「Audit Trail」など、さまざまな名称で呼ばれてきました。モニタリング機能は複合的な領域を対象とするため、地域情報 PF の仕様では、これらを統一した概念として「Audit」を用います。
地域情報 PF の仕様では、次の Audit を定義しています。
・BPM(Business Process Management) Audit
・WS アプリケーション Audit
・メッセージ Audit■ 導入時のメリット
モニタリング機能を導入すると、ビジネスプロセスの改善を促進できます。
特にビジネスプロセスが複数組織をまたがって実行された場合の、実施状況の把握、進捗管理に直接的な効果があります。

モニタリング機能をより高次な段階まで利用するためにサービス、ビジネスプロセスの種々の特性や KPI (Key Performance Indicator)は、事象が発生した段階で発生する Audit を収集し、解析することで把握できます。よって、Audit 収集の密度が高く、その品質が高いほど、モニタリング機能をより高次な段階まで利用できます。

- 27 -

■ 留意事項
モニタリング機能を実装するときは、次の点に留意します。
・

Audit の提供時には、柔軟なインタフェースの構成と、柔軟に変換モジュールなどを組み込める設計が求められます。
-

Audit 機能に関して、今後、国際標準化の検討が進むと予想されるため、Audit 提供の配置について実際の運用条件に柔軟に対応するため、緩やかな構成を推奨します。

-

Audit の形式についても推奨案を定義していますが、これも実際の運用条件に柔軟に対応する
ため、緩やかな定義を前提としています。このため、柔軟性を確保するためには、インタフェースの運用の段階で、必要に応じて公開するなどの処置が必要となります。

・モニタリング機能のアーキテクチャ標準仕様に基づき、監視アプリケーションなどのアーキテクチャについては規定していません。このため、監視アプリケーションの配置位置を柔軟に選択・構成できま
すが、より広域にモニタリングを実現するうえで、Audit Proxy などとの密結合な実装は推奨しません。

・

監視クライアントと監視アプリケーション間のインタフェースについても、仕様事項としては規定しません。

■ ユースケース
自治体、民間会社、地域ポータルなどの横断的なサービスを事例とした、モニタリング機能の実装例を模式化したものを図 2.6.1 に示します。
この図は、モニタリング機能の実装・配置に力点を置いているため、ファイアウォール装置、ルータ装置、
LGWAN（総合行政ネットワーク）などは省略しています。
ポータルサイト

監視クライアント

BPM機能

統合化Audit

付録1-(5)

監視アプリケーション

3.6.3-(1),付録1-(2)

自治体A

民間企業

DMZ

Audit Proxy

統合化Audit

BPM Audit

Message Audit

自治体
ポータル

3.6.3-(2)Audit Proxy DMZ
業務ユニット付録1-(6)

自治体B

BPM Audit提供

BPM機能

ログファイル等 変換 BPM Audit

Audit Proxy
BPM呼出し他

Message Audit提供

付録1-(3)
業務ユニットSOAPメッセージ 変換 Message Audit

監視アプリケーション
付録1-(4)
業務ユニット

監視クライアント

図 2.6.1 モニタリング機能の実装模式図- 28 -

DMZ

モニタリング機能の各要素は分散的に配置され、監視アプリケーションがその中心となり、大きくは 4 つ配
置されています。
・

1 つは、ポータルサイトまたは集中管理センターに配置されるべき監視アプリケーション、監視クライ
アントであり、当該モニタリング機能の通常利用を想定しています。

・

他の 3 つは、地域ポータル、自治体 A、民間企業などに配置される Audit Proxy や監視アプリケーシ
ョンであり、当該モニタリング機能の拡張利用時を想定しています。各組織体内または組織体からプロセス監視、サービス監視を行います。

地域ポータル、自治体 A、自治体 B、民間企業に配置される BPM 機能、業務ユニットなどはマルチベン
ダ条件下で調達されるため、各 Audit 提供機能とその変換機能は、それぞれ Audit のガイドラインに適合しつつも調達機器に適合する形で実装されます。たとえば、BPM Audit の提供は、図 2.6.1 の自治体 Aのように BPM 機能のサーバに組み込まれる場合もありますが、専用のアダプタ装置が置かれる場合もあります。また、メッセージ Audit の取得にあたっては、専用の収集モジュールを配した装置が置かれる場
合があります。
監視アプリケーションと Audit Proxy 間の通信プロトコルは、十分な柔軟性を許容しているアーキテクチャ
標準仕様に基づいて実装され、その問い合わせには受付番号などが用いられます。監視アプリケーショ
ンと Audit Proxy 間の通信プロトコルは、プラットフォーム通信標準仕様である SOAP(Simple Object
Access Protocol)を許容していますが、限定的に利用可能な場合は、プラットフォーム通信標準仕様との相互連携を前提のうえで他方式も利用可能とします。
モニタリング機能では、アーキテクチャ標準仕様で定義されるように、次の 4 つのインタフェースがあります（図 2.6.1 内の赤い一点破線枠、参照先は『地域情報プラットフォームガイドライン』の「第 3 章 技術解説」）。
・

モニタリング問い合わせインタフェース

・

監視クライアントインタフェース

・BPM・WS アプリケーション Audit 提供インタフェース

・メッセージ Audit 提供インタフェース

・

マルチベンダ下でのモニタリング機能実装例については、『地域情報プラットフォームガイドライン』の「第 3 章 技術解説」の「付録 4」を参照- 29 -

ユーティリティ機能

2.7

本節では、次の 5 つのユーティリティ機能について説明します。
・

時刻同期機能・

サービスレジストリ機能・

リポジトリ機能・

統合レジストリ機能・

ビジネスメッセージルーティングゲートウェイ機能

時刻同期機能■ 時刻同期機能とは
時刻同期機能とは、地域情報 PF 標準を採用して動作するサーバなどのマシンの「時刻同期」を実施す
る機能のことです。
本機能はサイト内で使用するため、調達範囲になります。

■ 導入時のメリット
時刻同期機能を導入すると、次のようなメリットがあります。
・

モニタリング機能、監査証跡機能など、マシン間の時刻を統一できます。

・

問題発生時のトラブルシューティングに、マシン間の時刻をふまえて対応できます。

■ 留意事項
次の場合に、時刻同期機能は必須です。
・モニタリング機能、監査証跡機能など、マシン間の時刻が一致していることを前提にしている機能がある場合

・問題発生時のトラブルシューティングに、マシン間の時刻をふまえたログなどから責任を切り分ける必要がある場合■ ユースケース
階層的に配置した NTP サーバと NTP クライアントのシステム例を、図 2.7.1 に示します。
サイト内の業務ユニットや BPM 機能、統合 DB 機能などのサーバマシンが、NTP クライアントとなります。
NTP クライアントは、マシンが起動された段階で、サイト内の NTP サーバにアクセスし、時刻同期を行います。

- 30 -

インターネット
NTP
サーバ
サービス

NTP
サイト内

NTP
サイト内
NTP
サーバ

NTP

サイト内
NTP
クライアント

サイト内
NTP
クライアント

図 2.7.1 時刻同期の実装例

NTP（Network Time Protocol）とはネットワークに接続される機器において、機器が持つ時計を正しい時刻へ同期するためのプロ
トコルです。

・NTP サーバと NTP クライアントの設置と設定に関する定義については、『アーキテクチャ標準仕様』の「4.5.3.3 ユーティリティ機能」を参照

サービスレジストリ機能■ サービスレジストリ機能とはサービスレジストリ機能とは、サービス情報を管理する蓄積庫のことです。サービス情報のライフサイクル（登録、更新、削除）を管理し、これら登録されたサービス情報を検索できるサービスを提供します。
サービスの提供には、次の 2 つの方法があります。
・UDDI(Universal Description, Discovery and Integration)などを使用して、動的にサービス先を探す
方法

・Web サイトなどでサービス情報を公開する静的な方法

・

詳細な定義については、『アーキテクチャ標準仕様』の「4.5.3.3 ユーティリティ機能」を参照■ 導入時のメリット
サービス情報のライフサイクル（登録、更新、削除）を管理でき、これら登録されたサービスを提供できます。

- 31 -

■ ユースケース
プラットフォーム標準仕様に基づく各種 Web サービスの登録、検索、公開のユースケースを次に示しま
す。
・

管理者
各種サービスを提供するコミュニティの主体者（地域ポータル運営者など）・使用者登録された各種 Web サービスを利用し、地域サービスなどを提供する主体者

・要件
管理者が管理、登録する Web サービス（自治体や民間など）のカタログ情報を、使用者が検索し、ダウンロードできること

リポジトリ機能■ リポジトリ機能とはリポジトリ機能とは、標準仕様関連書類、システム開発仕様、プログラム、用語定義、項目辞書などを蓄積、管理するデータベースなどの、蓄積機能のことです。

・ 詳細な定義については、『アーキテクチャ仕様書』の「4.5.3.3 ユーティリティ機能」を参照■ 導入時のメリット統一された規約、制度のもとで、各種ドキュメント類を管理できます。

■ ユースケース【ユースケース 1】
プラットフォーム標準仕様の、バージョン別の各種ドキュメントの蓄積と公開のユースケースを次に示しま
す。
・

管理者
プラットフォーム標準仕様の管理者

・使用者
公開する各種ドキュメントを参照する人（自治体、製品ベンダなど）

・要件
管理者は、地域情報プラットフォーム標準仕様運用規則に基づき、次のプラットフォーム標準仕様の管理と使用者への公開ができること【ドキュメント類の例】
・ 自治体業務アプリケーションユニット標準仕様
・

アーキテクチャ標準仕様、プラットフォーム通信標準仕様

・

地域情報プラットフォーム準拠および相互接続仕様

・

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

・

地域情報プラットフォーム基本説明書- 32 -

【XML 定義類の例】
・ 自治体業務アプリケーションユニット標準仕様で規定される XML 定義類- 業務ユニットインタフェースに関する標準規定の XML 定義類(WSDL/XSD)- ワンストップサービスに関するサンプル XML 定義類(BPEL/WSDL/XSD など)【ユースケース 2】
プラットフォーム標準仕様を活用した、自治体の設計共通リポジトリ（文書管理）のユースケースを次に示
します。
・

管理者
地域情報 PF に対応した、自治体システムの調達から運用、保守までを担当する自治体の管理者

・使用者
地域情報 PF に対応した、自治体システムの開発を実施する担当者

・要件
管理者は、使用者が作成した次の自治体システムに関する設計情報を管理できること-

プラットフォーム標準仕様や自治体個別要件に基づいてカスタマイズした自治体内標準仕様書-

工程管理資料、設計ドキュメント、UML、ソースコードなど

統合レジストリ機能■ 統合レジストリ機能とは
統合レジストリ機能とは、多様化するサービス利用者とサービス提供者間の関係（サービス利用形態）を二者間の｢合意｣として策定し、UDDI(Universal Description, Discovery and Integration)などの従来のレジストリが管理する情報と合わせて｢サービス情報｣として管理、監視する機能のことです。サービス提供者またはサービス管理者が、サービスの運用状況や、サービス利用者との合意に基づいた目標品質を管理、把握し、これら「サービス情報」をサービスの品質にフィードバックできるサービス管理基盤を、本機能で構築できます。
アーキテクチャ標準仕様の統合レジストリに記載されている機能要件を満たした統合レジストリ機能では、
次の 2 つのエージェント機能を提供できます。
・

暗号化処理
サイトをまたがってサービス利用者とサービス提供者間でメッセージを交換するとき、サービス提供
者側がメッセージを暗号化できない場合、エージェントが代理でメッセージを暗号化することで通信
路上のセキュリティを確保します。

・

目標品質（サービスレスポンスタイム）の管理
サイトをまたがってサービス利用者とサービス提供者間がサービス連携をするとき、あらかじめサー
ビス利用者とサービス提供者の間で取り交わしたレスポンスタイムなどに基づき、サービス提供者側のリクエスト、レスポンスタイムの計測によって目標品質を管理できます。

- 33 -

統合レジストリ機能の処理フローと処理概要を、図 2.7.2 に示します。
統合レジストリ
利用者

レジストリ機能

③合意交渉

合意交渉
合意交渉

③合意交渉

統合レジストリ
利用者

①サービス
登録
サービス提供者

②サービス
情報検索

サービス関連情報サービス関連情報
サービス運用状況
サービス運用状況

エージェント機能

サービス利用者

連携（運用
情報収集）

セキュリティ（暗号化）
セキュリティ（暗号化）
目標品質
目標品質

④サービス利用

ログ取得
ログ取得

サービス

統合レジストリ機能

図 2.7.2 統合レジストリ機能の処理フローと処理概要
統合レジストリ機能の利用シーンを、図 2.7.3 に示します。
合意した内容のサービスへの適用
合意適用状況の監視地域ポータル運営会社

住民

サービス
利用

地域ポータル運営会社
または、国または、自治体
統合レジストリ機能（エージェント機能）

地域ポータル

自治体Ａ

サービス

レジストリ利用
合意交渉
地域ポータ ル運営会社
または、国

民間企業
連携

統合レジストリ機能（レジストリ機能）

レジストリ利用

サービス

合意交渉
サービス情報の登録、提供
サービス利用条件について合意交渉、策定

図 2.7.3 統合レジストリ機能の利用シーン■ 導入時のメリット
統合レジストリ機能を導入すると、サービス利用者に、高付加価値サービスを迅速に安定して提供できます。

■ 留意事項
統合レジストリで管理する範囲、運用主体などを、今後精査しておく必要があります。

- 34 -

■ ユースケース
統合レジストリ機能の実装モデルを、図 2.7.4 に示します。

②サービスを閲覧／検索する

レジストリ機能
従来のレジストリ機能①サービスを登録する

合意交渉
合意交渉

サービス提供者
サービス
③合意交渉
を行う

①サービスを利用する
SOAP④エージェントの管理、制御エージェント機能
合意適用
合意監視

SOAP

サービス利用者

サービス
統合レジストリ機能

図 2.7.4 統合レジストリ機能の実装モデル

ビジネスメッセージルーティングゲートウェイ機能■ ビジネスメッセージルーティングゲートウェイ機能とはビジネスメッセージルーティングゲートウェイ機能とは、メッセージヘッダ部に記載された送信先（To タグ
項目の値）に、メッセージ本体を動的に送信代行する Proxy として動作する機能のことです。
たとえば次のようなシーンでは、業務メッセージの送信先を、受信した申請書類の内容や業務プロセスの処理結果に応じて動的に変更する必要があります。
・

ポータルからの情報照会の申請書類から照会先団体を取り出し、その団体名に基づいて照会依頼を送信する（図 2.7.5）

・ある団体からの業務メッセージの処理結果を後日返信する場合、業務メッセージの送信元に応じた
返信先の動的変更が必要となる（図 2.7.6）

地域情報 PF では、この動的な業務メッセージ送信先を制御する機能を「ビジネスメッセージルーティング
ゲートウェイ機能（略称：BMR-GW 機能）」と呼びます。

- 35 -

図 2.7.5 動的な送信先変更

団体 A
業務プロセス

申請の送信元に応じて結果の返信先を
動的に変更

申請

団体 C

処理
結果

団体 B
業務プロセス

申請
処理
結果

図 2.7.6 送信元に応じた動的な返信先の変更■ 導入時のメリット
業務メッセージの送信先を、受信した申請書類の内容や業務プロセスの処理結果に応じて動的に変更できます。

■ 留意事項
ビジネスメッセージルーティングゲートウェイ機能は、オプションです。
ただし次のような場合は、動的に送信先を変更する本機能をプラットフォームに実装します。
・

複数箇所から呼び出される非同期呼び出しがある場合

・

WS-BPEL で記述されたビジネスプロセスで、送信先の動的変更を実現する場合
WS-BPEL 仕様に従って EndpointReference を使用することが考えられますが、ビジネスプロセス配備時に送信先を静的にバインドする WS-BPEL 処理系の場合、こうした機能が使用できない可能性があります。

・

一般的な業務ユニットで、複数の呼び出し元から非同期で呼び出される場合

・

一般的な業務ユニットで、業務内容によって呼び出し先の業務ユニットを動的に変える必要がある場合- 36 -

メッセージ交換パターン

2.8■ メッセージ交換パターンとはメッセージ交換パターンとは、メッセージ群の交換の類型を定義するものです。
地域情報 PF では、次の 3 種類のメッセージ交換パターンを標準仕様として採用しています。
・

リクエスト型受領 Ack あり
同期型のメッセージ交換パターンです。開始側は、処理要求などの要求メッセージを送信するとともに、同一セッションで応答側からの受領 Ack の受信も行います。応答側では、要求メッセージに対す
る応答メッセージは返しませんが、受領 Ack を同一セッションで送信するパターンです。
処理概要を図 2.8.1 に示します。
開始側

応答側
req
受信

送信

受領 Ack 生成

ack

返信

受領 Ack チェック

リクエストの処理

図 2.8.1 「リクエスト型受領 Ack あり」の処理概要

・

リクエスト・レスポンス型同期型レスポンス
要求メッセージの送信と同一のセッションで、応答側からの業務処理結果情報の応答メッセージを返す同期型のパターンです。受領 Ack の通知は行いません。開始側は、要求メッセージの送信を行った後に、同一のセッションで応答側からの応答メッセージを受信します。応答側は、要求メッセー
ジを受信後、受信確認用の受領 Ack を返すことなく、要求された業務処理を実施し、その後、その結果情報を開始側に応答メッセージとして返します。
処理概要を図 2.8.2 に示します。
開始側

応答側
req
受信

送信

リクエストの処理
レスポンス生成返信

res
レスポンスの処理

図 2.8.2「リクエスト・レスポンス型同期型レスポンス」の処理概要- 37 -

・

リクエスト・レスポンス型同期型受領 Ack＋非同期型レスポンス
要求メッセージの送信とは別セッションで、応答側から業務処理結果情報の応答メッセージを返す
非同期型です。要求メッセージと応答メッセージのそれぞれに対して、相手側から受領 Ack を受信します。応答側（レスポンス送信側）で、応答メッセージに対する受領 Ack を無視することも許容しています。
処理概要を図 2.8.3 に示します。
開始側

応答側
req
受信
受領 Ack 生成

送信
返信

ack
受領 Ack チェック

リクエストの処理
レスポンス生成応答側では連続して該当するインスタンスが生存しなければならない場合もある。

res
受信

受領 Ack 生成

返信

ack
送信

レスポンス処理

受領 Ack チェック

図 2.8.3「リクエスト・レスポンス型同期型受領 Ack+非同期型レスポンス」の処理概要

リクエスト型のメッセージ交換パターンとは要求メッセージだけで構成され、業務処理結果を含んだ応答メッセージが存在しないパターンです。業務ユニットからの帳票出力指示、バッチプログラムや他の業務ユニットへの通知などが想定されます。受領 Ack の有無と受信の仕方によって、次の 3 パターンがあります。
・リクエスト型受領 Ack なし
・リクエスト型受領 Ack あり・リクエスト型非同期型受領 Ack

リクエスト・レスポンス型のメッセージ交換パターンとは
リクエストと、それに対する業務データを含むレスポンスの組で構成されるパターンです。受領Ack の有無、受領 Ack とレスポンスの送受信の仕方によって、次の 4 パターンがあます。
・リクエスト・レスポンス型同期型レスポンス
・リクエスト・レスポンス型非同期型レスポンス
・リクエスト・レスポンス型同期型受領 Ack＋非同期型レスポンス
・リクエスト・レスポンス型非同期型受領 Ack＋非同期型レスポンス- 38 -

■ 導入時のメリット
地域情報プラットフォームが標準仕様として採用しているメッセージ交換パターンを導入すると、次のメリットがあります。
・

実装が容易である

・障害検知が容易である

・

障害検知の仕組みを明確に定義できる

・業務の要件に応じて最適な方式を選択できる

・

SOAP 1.1 などの Req-Res パターンに合致する■ 留意事項
メッセージ交換パターンを実装するときは、次の点に留意します。
・

業務処理時間やタイムアウト時間などを含めた業務要件に応じて、メッセージ交換パターンを選択します。

・「リクエスト型受領 Ack あり」では、応答側での処理結果が開始側に返されないため、要求メッセージに基づく処理が成功したかどうかを開始側で確認できません。

・「リクエスト・レスポンス型同期型レスポンス」では、開始側のセッションのタイムアウト時間内に応答側の処理が終了しなかった場合、開始側ではすべてタイムアウトとして検知されます。このため開始側
では、通信障害なのか業務処理の遅延によるタイムアウトなのかを判断できません。

■ ユースケース
プラットフォーム通信標準仕様では、メッセージ交換パターンを要求側と応答側間の一般的なメッセージのやり取りとして定義しています。このため、地域情報 PF のすべての点で適用できます。しかし、応答側には、メッセージ交換パターンの組み合わせに関する制約事項も、一部存在します。

・

メッセージ交換パターンの奨励する基本的な構成、一般的構成、および奨励しない構成と制約事項については、『地域情報プラットフォームガイドライン』の「3.8.2 応答側処理におけるメッセージ交換
パターンの制約」を参照- 39 -

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

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

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

地域情報プラットフォームガイドライン第 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－

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

第４章（別冊）
ワンストップサービスの連携定義手順

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

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

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

項

版数

修正内容

1

2013.5.31

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

改版履歴

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

目次

１．ワンストップサービス連携定義手順とは ................................................ 2
２．ワンストップサービスの連携定義手順 .................................................. 4
２．１ 業務要件定義作業ステップ（業務処理整理表～機能連携システムフロー） .............................. 4
２．２ XML 定義作業ステップ（BPMN 図～XML スキーマ定義、WSDL 定義、WS-BPEL 定義） ................. 10３．参照定義 .......................................................................... 18
３．１ 参照定義とは ....................................................................................................................................... 18
３．２ 共通定義 ............................................................................................................................................... 18
３．３ WSDL プロファイル .............................................................................................................................. 19
３．４ XML 変換ルール .................................................................................................................................... 22
４．辞書 .............................................................................. 25
４．１ 辞書の位置付け ................................................................................................................................... 25
４．２ 項目セット辞書コンテンツ ............................................................................................................... 26
４．３ XML データ型辞書コンテンツ ............................................................................................................ 28
４．４ BP パターン辞書コンテンツ .............................................................................................................. 30－1－

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

１．ワンストップサービス連携定義手順とはワンストップサービス連携定義手順は、自治体などが地域情報プラットフォームを利用してワンス
トップサービスを構築する際の作業手順であり、業務分析から計算機で解釈や実行が可能な国際標準のXML 定義を作成するまでの手順とワークシートを含んでいる。また、連携定義作業において参照する標準書や共通的に利用する定義類を参照定義及び辞書として位置付けている。
ワンストップサービス連携定義手順は、大きく２つの作業ステップに分かれる。前半は、構築するワンストップサービスの設計及び業務分析を行う「業務要件定義作業ステップ」で、主に自治体が中心となって行う。後半は、「業務要件定義作業ステップ」の結果をもとに、BPMN 図や WSDL 定義を作成する「XML定義作業ステップ」で、主にベンダが中心となって行う。
ワンストップサービス連携定義手順の全体の作業フローは、図１．１のようになっており、各ステップの成果物は表１．１のようになる。また、参照定義及び辞書を含めた各成果物の関連図を図１．２に示す。本書で例示されている図表は、地域情報プラットフォーム標準仕様 V2.0 を基に作成されている。
なお、本手順に沿った作業に入る前段階の作業として、まずはどのようなワンストップサービスを構築するかを検討する必要がある。構築するワンストップサービスの検討においては、ライフイベントが切り口の一つとなるので、参考までに APPLIC で整理したライフイベントとそれぞれ対象となる申請や届出などの一覧を付録４－ⅰ．１に付ける。

ワンストップサービス連携定義手順

業務要件定義作業ステップ
業務要件定義作業ステップ

ワンストップサービスの対象手続きと業務機能の整理
ワンストップサービスの業務機能の連携に関する整理
ワンストップサービスの業務フローの整理
ワンストップサービスの連携情報に関する項目定義
ワンストップサービスのシステム連携に関する整理

XML定義作業ステップ
XML定義作業ステップ

ワンストップサービスのビジネスプロセス設計
ワンストップサービスのインタフェース定義
ワンストップサービスのメッセージの項目定義
WS-BPEL定義
の作成

図１．１

WSDL定義、XMLスキーマ定義の作成

ワンストップサービス連携定義手順－2－

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

表１．１

ワンストップサービス連携定義手順の成果物
作業内容

成果物

１

ワンストップサービスの対象手続きと業務機能の整理

業務処理整理表２

ワンストップサービスの業務機能の連携に関する整理

ワンストップ DFD

３

ワンストップサービスの業務フローの整理

機能関連ブロック図

４

ワンストップサービスの連携情報に関する項目定義

ワンストップインタフェー
ス仕様

５

ワンストップサービスのシステム連携に関する整理

機能連携システムフロー

６

ワンストップサービスのビジネスプロセス設計

BPMN 図条件分岐定義７

ワンストップサービスのインタフェース定義

インタフェース一覧

８

ワンストップサービスのメッセージの項目定義

メッセージ定義

９

WSDL 定義、XML スキーマ定義の作成

WSDL 定義
XML スキーマ定義

１０

WS-BPEL 定義の作成

WS-BPEL 定義

ワンストップサービス
連携定義手順辞書

参照定義

業務要件定義作業ステップ
業務要件定義作業ステップ

業務処理整理表
ワンストップＤＦＤ

項目セット辞書

コード辞書

機能関連
ブロック図

XMLデータ型
辞書

ワンストップ
インタフェース仕様

自治体業務アプリ
ケーションユニット
標準仕様V2.0

機能連携
システムフロー

XML定義作業ステップ
XML定義作業ステップ

項目セット辞書

BPMN図

コード辞書

条件分岐定義APPLIC
PF通信標準仕様
・XML関連規定
・WSDL関連規定
・BPEL関連規定

インタフェース
一覧

XMLデータ型
辞書

メッセージ定義

共通定義
WSDLプロファイル

BPパターン辞書

図１．２

WS-BPEL定義

WSDL定義XMLスキーマ
定義

ワンストップサービス連携定義の成果物の関連図－3－

XML変換ルール

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

２．ワンストップサービスの連携定義手順
２．１ 業務要件定義作業ステップ（業務処理整理表～機能連携システムフロー）（１）

ワンストップサービスの対象手続きと業務機能の整理
本ステップの目的： ワンストップサービスに必要な業務機能を整理する

入力情報： 法令、条例等

成果物： 業務処理整理表

自治体業務アプリケーションユニット標準仕様 V2.0

本ステップでは、はじめにワンストップサービスの対象となる申請手続きを分析し、「自治体業務アプリケーションユニット標準仕様 V2.0」の「（業務１－４）機能一覧」を参考に、各申請手続きを処理するのに必要となる業務機能の洗い出しを行う。「（業務１－４）機能一覧」に該当する業務機能がない場合は、必要に応じて新たな業務機能を整理し、記入する。
次に、洗い出された各業務機能に関して、法令や条例等をもとに、各業務機能に必要となる
申請書、必要提出物、交付物に関する調査を行う。
また、申請者によって対象となる業務機能が異なるなどの場合には、当該業務機能が対象となる場合の条件を整理する。

図２．１．１－4－

業務処理整理表

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

ワンストップサービスの業務機能の連携に関する整理本ステップの目的： 業務機能間で連携する情報を整理する

入力情報： 業務処理整理表

成果物： ワンストップ DFD

自治体業務アプリケーションユニット標準仕様 V2.0

本ステップでは、「自治体業務アプリケーションユニット標準仕様 V2.0」の「（１－６）機能
情報関連図」を参考に、「業務処理整理表」で洗い出された各業務機能間を流れる情報の調査を行う。業務機能以外にも、情報の発生源や送信先として、ワンストップサービスの利用者や既存のシステム等がある場合には、それらの外部要素との間の情報の流れも整理する。業務ユニット内に蓄積された情報を他の業務機能が業務ユニット間インタフェースで参照する場合などについても、業務機能間の連携として整理する。
なお、本ステップでは「業務処理整理表」を入力情報としているが、本ステップで新たに必要な業務機能が洗い出されることもあるので、その場合は「業務処理整理表」にフィードバッ
クする。

図２．１．２

ワンストップ DFD－5－

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

ワンストップサービスの業務フローの整理
本ステップの目的： ワンストップサービスの業務フローを整理する

入力情報： 業務処理整理表

成果物： 機能関連ブロック図

ワンストップ DFD

本ステップでは、「業務処理整理表」と「ワンストップ DFD」をもとに、業務機能間の順序性に関する調査を行い、ワンストップサービスの業務フローを整理する。
フローの中に、業務機能に関する条件や業務処理結果等による分岐がある場合には、分岐条件も併せて整理し、各業務機能が、直列で実行されるのか並列で実行されるのかも明確にする。
１つの業務機能の中に、更に詳細な業務フローがある場合は、必要に応じて別シートに分けて記載する。
複数の団体や組織等で業務フローが構成される場合に、各業務機能がどこに含まれるかを明確に示す場合は、それぞれの団体や組織等に対してスイムレーンを設定し、各業務機能は該当するスイムレーンの中に含める。

図２．１．３

機能関連ブロック図－6－

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

ワンストップサービスの連携情報に関する項目定義
本ステップの目的： 業務機能のインタフェースのデータ項目を定義する

入力情報： ワンストップ DFD
自治体業務アプリケーションユニット標準仕様 V2.0
対象手続きの申請書、届出書

成果物： ワンストップインタフェース仕様

本ステップでは、「自治体業務アプリケーションユニット標準仕様 V2.0」の「（業務１－７）
インタフェース仕様」と対象手続きの申請書、届出書等をもとに、「ワンストップ DFD」で整理された連携情報のデータ項目の定義を行う。
定義する内容は、データ項目の名称、コード化の有無、データ型、桁数などのそのデータ項
目の属性と各業務機能等との入出力情報がある。
連携する情報の各データ項目を定義する際、「自治体業務アプリケーションユニット標準仕様 V2.0」の「（業務１－１２）項目セット辞書」に対応する項目構造がある場合には、該当する項目セットを適用する。定義されている項目セットと完全に同じ項目構造になっていない場
合でも、項目セットの一部分になっている場合には、設計作業の効率性の観点から、項目セットを適用しても構わない。但し、本来は不要なデータ項目がメッセージに含まれることになり、本来よりも通信量が増加することになるため、そのような点も考慮して、適用するかどうかを判断する必要がある。
また、頻出する項目構造が「（業務１－１２）項目セット辞書」に定義されていない場合は、新規に項目セットとして定義する。
対象のデータ項目をコード化して使用する場合には、「自治体業務アプリケーションユニッ
ト標準仕様 V2.0」の「（業務１－１３）コード辞書」を確認し、適用するコードを決定する。
「（業務１－１３）コード辞書」の中に該当のコードがない場合は、新規にコードを定義する。
入出力情報については、対象の業務機能等に対しての入出力という観点で定義する。
なお、「（業務１－７）インタフェース仕様」で定義されているデータ連携をそのまま利用する場合は、各データ項目の項目定義は省略する。また、必要提出物や交付物などのように、連携情報としてはデータ項目まで明確にする必要がないと想定される場合も、項目定義を省略しても構わない。

－7－

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

図２．１．４

ワンストップインタフェース仕様－8－

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

ワンストップサービスのシステム連携に関する整理本ステップの目的： システム間の情報及び処理の連携を整理する

入力情報： 業務処理整理表
機能関連ブロック図
ワンストップインタフェース仕様

成果物： 機能連携システムフロー

本ステップでは、「機能関連ブロック図」と「ワンストップインタフェース仕様」を参考にして、BPM 機能も含めた各機能及びシステム間の情報及び処理の連携を整理する。
業務機能または業務ユニット間でデータ交換がある場合には、付加情報として、各業務機能
または業務ユニットのインタフェース相当部分を明示する。

図２．１．５機能連携システムフロー－9－

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

２．２ XML 定義作業ステップ（BPMN 図～XML スキーマ定義、WSDL 定義、WS-BPEL 定義）（１）

ワンストップサービスのビジネスプロセス設計
本ステップの目的： ビジネスプロセス（BP）の実装仕様を定義する

入力情報： 機能関連ブロック図
機能連携システムフロー

成果物： BPMN 図
条件分岐定義本ステップでは、「機能関連ブロック図」及び「機能連携システムフロー」をもとに、BPMN（Business Process Modeling Notation）という表記法を用いて、ワンストップサービスのビ
ジネスプロセスの実装仕様となる「BPMN 図」を作成する。
各アクティビティは、「プラットフォーム通信標準仕様 V2.0」の「４．４WS-BPEL の適用

範囲、制約に関する規定」を参考に記載し、付加情報として、各アクティビティのインタフェー
ス相当部分を明示する。
BP 制御の考え方は、「プラットフォーム通信標準仕様 V2.0」の「４．３ビジネスプロセス（BP）のフロー制御に関する規定」を参考にし、BP 制御に必要な分岐条件を明確化する。各分
岐に関する内容は、「条件分岐定義」に記入する。

図２．２．１BPMN 図（BP 実装仕様）－10－地域情報プラットフォームガイドライン

図２．２．２－11－条件分岐定義地域情報プラットフォームガイドライン（２）

ワンストップサービスのインタフェース定義
本ステップの目的 ： ワンストップサービスのインタフェースを定義する
入力情報： BPMN 図、機能連携システムフロー

成果物： インタフェース一覧

本ステップでは、「BPMN 図」及び「機能連携システムフロー」をもとに、メッセージ交換及びデータ交換を行う場所を特定し、BPM 機能と業務機能間、業務機能と業務ユニット間などのワンストップサービスのインタフェースを定義する。
各インタフェースを定義する際には、「プラットフォーム通信標準仕様 V2.0」の「４．５セージ交換パターンに対する WS-BPEL 実装規定」及び「６．２メッ

地域情報プラットフォームにおける奨励メッセージ交換パターンの定義」を参考にし、該当の業務機能に関する業務要件を考慮して行う。
また、業務ユニットとのデータ交換に関して、「自治体業務アプリケーションユニット標準
仕様 V2.0」の「（業務１－９）インタフェース一覧」で定義されたインタフェースを利用する
場合は、該当のメッセージ定義名及び WSDL 定義を記入する。
なお、業務メッセージの他に、共通定義の受領 Ack などについても全て記入する。

図２．２．３

インタフェース一覧－12－

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

ワンストップサービスのインタフェースに関するメッセージの項目定義
本ステップの目的： ワンストップサービスのメッセージを定義する

入力情報： ワンストップインタフェース仕様

成果物： メッセージ定義

インタフェース一覧

本ステップでは、「インタフェース一覧」で定義された各メッセージに対して、「ワンストッ
プインタフェース仕様」をもとに、XML スキーマ定義に必要な情報を追加して、データ項目の定義を行う。
出現回数については、タグの省略が可能な場合は、最小には「0」を記入し、省略不可の場
合は、1 以上の値を記入する。最大には、該当のデータ項目またはデータ項目の集合の繰返し
回数の最大値を記入し、最大値が不定の場合は、「N」を記入する。
「プラットフォーム通信標準仕様 V2.0」の「７．プラットフォーム通信仕様におけるメッセー
ジ共通ヘッダ仕様」で規定されているメッセージの共通ヘッダについては、記入しなくても構わないが、該当のメッセージに関して、共通ヘッダの各データ項目に対して補足事項等を加えたい場合は、記入しても構わない。
また、インタフェースに添付ファイルがある場合は、メッセージの最後に記入する。
なお、「自治体業務アプリケーションユニット標準仕様 V2.0」の「（業務１－９）インタフェー
ス一覧」などで既に定義されているインタフェースについては、本ステップの作業は省略する。

図２．２．４－13－

メッセージ定義

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

WSDL 定義、XML スキーマ定義の作成
本ステップの目的： ワンストップサービスの WSDL 定義及び XML スキーマ定義を作成する

入力情報： インタフェース一覧

成果物： WSDL 定義

メッセージ定義
XML スキーマ定義
本ステップでは、インタフェース一覧で定義した各インタフェースに対する WSDL 定義及びXML スキーマ定義を「プラットフォーム通信標準仕様 V2.0」の「３．２３XML 定義仕様」「３．

WSDL の XML 定義記述要件」に基づき作成する。

WSDL 定義については、はじめに「３．３

WSDL プロファイル」を参考に、WSDL 定義用ワー

クシートを作成する。次に、作成した WSDL 定義用ワークシートをもとに、「３．４

XML 変換ルール」にしたがい、WSDL 定義を作成する。
メッセージに添付ファイルがある場合は、「３．２

共通定義」を参考にして、添付方式を決定する。
なお、WSDL 定義用ワークシートは必ずしも作成する必要はなく、直接 WSDL 定義を作成しても構わない。
XML スキーマ定義については、メッセージ定義をもとに、「３．４XML 変換ルール」にしたがい、作成する。この際、「プラットフォーム通信標準仕様 V2.0」の「７．プラットフォーム
通信仕様におけるメッセージ共通ヘッダ仕様」で規定されているメッセージの共通ヘッダを追加する。
なお、本手順で作成する XML スキーマ定義は、PF 通信で使用するメッセージ形式を想定したものであり、データ値の表現の形式や、DB スキーマ作成を意図したデータ型やデータ長を想定したものではない。

－14－

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

図２．２．５－15－

WSDL 定義

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

図２．２．６XML スキーマ定義－16－

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

WS-BPEL 定義の作成
本ステップの目的： WS-BPEL 定義を作成する

入力情報： BPMN 図

成果物： WS-BPEL 定義

本ステップでは、BPMN 図をもとに WS-BPEL 定義を作成する。
この際、「プラットフォーム通信標準仕様 V2.0」の「４. プラットフォーム通信標準のビジネスプロセス制御定義仕様」を参考にする。
なお、BPEL 文書（WS-BPEL アブストラクト）は配布用として準備する場合に作成し、実際の開発では、BPEL 文書（WS-BPEL アブストラクト）は作成せず、BPM 製品の BP 定義機能で代行し、以降の開発工程へ進めても構わない。

図２．２．７－17－

WS-BPEL 定義

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

３．参照定義３．１ 参照定義とは参照定義とは、「ワンストップサービス連携定義手順」において参照する、標準書や共通定義のことである。

ワンストップサービス
連携定義手順辞書

参照定義

業務要件定義作業ステップ
業務要件定義作業ステップ

業務処理整理表
ワンストップＤＦＤ

項目セット辞書

コード辞書

機能関連
ブロック図

XMLデータ型
辞書

ワンストップ
インタフェース仕様

自治体業務アプリ
ケーションユニット
標準仕様V2.0

機能連携
システムフロー

XML定義作業ステップ
XML定義作業ステップ

項目セット辞書

BPMN図

コード辞書

条件分岐定義APPLIC
PF通信標準仕様
・XML関連規定
・WSDL関連規定
・BPEL関連規定

インタフェース
一覧

XMLデータ型
辞書

メッセージ定義

共通定義
WSDLプロファイル

BPパターン辞書

図３．１．１

WS-BPEL定義

WSDL定義XMLスキーマ
定義

XML変換ルール

ワンストップサービス連携定義における参照定義の位置付け

大別すると、以下で構成される。
・標準書： APPLIC 標準書（「自治体業務アプリケーションユニット標準仕様 V2.0」、「プラットフォーム通信標準仕様 V2.0」を参照）

・共通定義： 共通ヘッダ等の「プラットフォーム通信標準仕様 V2.0」で規定されている共通定義

・WSDL プロファイル ： WSDL を記述する際の注意事項（一般用、BPEL 用）・XML 変換ルール： ワークシートから XML スキーマへの変換ルール

３．２ 共通定義
以下のデータ項目は、プラットフォーム通信標準仕様により定められている共通定義であり、必要に応じて使用する。
・受領 Ack 表現： 受領 Ack の形式については、「プラットフォーム通信標準仕様 V2.0」の・共通ヘッダ表現： 「プラットフォーム通信標準仕様 V2.0」の第７章「プラットフォーム通「６．６．１受領 Ack のメッセージ形式」を参照

信仕様におけるメッセージ共通ヘッダ仕様」を参照－18－

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

・添付ファイル表現 ： 添付ファイルを送信する際の電子封筒形式については、「プラットフォーム通信標準仕様 V2.0」の「２．３．２ 通信モデル」の（１）および（２）を参照

３．３ WSDL プロファイル
WSDL を記述する際の注意事項であり、国際標準である WSDL 仕様に対する、WS-I Basic Profile 1.0を踏まえ、さらに、日本語等の扱いの考え方、各項目の設定の考え方を記載している。
WSDL プロファイルには、一般用と BPEL 用があり、以下にそれぞれのプロファイルを示す。
なお、図 3.3.1 の WSDL プロファイルは添付ファイルが無い場合のもの（メッセージ本体格納型）
であり、添付ファイルが有る場合(SwA 型)の WSDL プロファイルは、今後作成予定である。

－19－

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

PF標準 WSDLプロファイル（一般Webサービス用）
No.

L1 L2 L3 L4 L5 L6 L7 L8

属性

データ型

備考
WSDLと、SOAPバインディングのバージョン
XMLのスキーマ定義言語
WSDLのファイル名の規則
エンコーディング
添付ファイル
管理主体、対象文書名、バージョン、作成日の情報
XMLに関するその他のガイドライン
名前空間

1
2

<?xml version="1.0"?>

文字コード、符号化規則は、デフォルトのUTF-8とする。

1..1 definitions

3
4

name
NMTOKEN
targetNamespace anyURI

ワンストップ例：引越転入サービスWSDL
業務ユニット例: なし
urn:applic.or.jp:xmlns:wsdl:2007-01

anyURI5

xmlns:prefix -wsdl

6

xmlns:prefix -xsd

7
8
9
10

xmlns:wsdlsoap
xmlns:xsd
xmlns
1..1

documentation

11
12
13

1..1
1..1

types
xsd:schema

anyURI

anyURI

1..1

16
17

1..*

message

18
19

1..1

part

anyURI

targetNamespace anyURI

http://schemas.xmlsoap.org/wsdl/soap/
http://www.w3.org/2001/XMLSchema
http://schemas.xmlsoap.org/wsdl/

1..1
1..1

23
24

1..*

定義名をあらわす名称を付けることを推奨する。
ユーザ定義のWSDLの名前空間宣言
ユーザ定義のWSDLの名前空間のQNAME定義"prefix"は定義
識別情報等で置き換える。日本語（２バイト文字）記載不可(パーセントエンコーディング(*)を含む)。
ユーザ定義のXSDの名前空間のQNAME定義"prefix"は定義
識別情報等で置き換える。日本語（２バイト文字）記載不可(パーセントエンコーディング(*)を含む)。
必須, WSDL1.1SOAPバインディング用。日本語（２バイト文字）
記載不可(パーセントエンコーディング(*)を含む)。
固定
必須、WSDL1.1用
文書の説明、管理主体、対象文書名、バージョン、作成日の情報を入れる

urn:applic.or.jp:xmlns:schema:2007-01

W3C XMLSchema で記述する。
ユーザ定義のXSDの名前空間のQNAME定義。日本語（２バイト文字）記載不可(パーセントエンコーディング(*)を含む)。

xsd:inlcude

1..1

21
22

25
26

anyURI

any

14
15

20

WSDL１．１ , SOAP 1.1 (SOAPバインディング)
W3C XMLSchema 1.0「定義識別情報＋バージョン＋.wsdl」
document / literal とする （PF標準はXML文書を交換するため）メッセージ内にエンコードされる
definitionsタグ下のdocumentationタグ内に記載する
PF通信のXML定義仕様記載のガイドラインを使用する。
PF標準全体で体系的な規則を作成する。

ユーザ定義のXSDを識別するURLを指定。日本語（２バイト文字）記載不可(パーセントエンコーディング(*)を含む)。

schemaLocation

anyURLname

NCNameワンストップ例： 受付メッセージ
業務ユニット例: 住民情報_問合せ

NMTOKEN

ワンストップ例：受付メッセージ
業務ユニット例: 住民情報＿問合せメッセージ

element

QName

ワンストップ例：oss1-xsd:受付メッセージAPPLIC: boｓｓ１－ｘｓｄ：識別番号メッセージ

typesにて定義されたelementをQNAMEで参照する

name

NCNameワンストップ例：引越転入PT
業務ユニット例: 住民基本台帳

抽象オペレーション群を束ねるポートタイプの名称。日本語（２バイト文字）記載不可(パーセントエンコーディング(*)を含む)。

NCNameワンストップ例： 引越転入
業務ユニット例: 住民基本台帳＿住民情報

抽象オペレーションの名称
inputの名称； portType内でユニークname

メッセージの名称； 本WSDL内でユニークメッセージパートの名称； message内でユニーク

portType

operation
name

1..1

input

27

name

NMTOKEN

ワンストップ例： 受付メッセージ
業務ユニット例: 住民情報_問合せメッセージ28
29

messageQname

ワンストップ例：oss1-wsdl:受付メッセージ
業務ユニット例: boss1-wsdl:住民情報_問合せ

message/partのname属性の参照
outputの名称； portType内でユニーク
message/partのname属性の参照

1..1

output30

name

NMTOKEN

ワンストップ例： 受領メッセージ
業務ユニット例: 住民情報_検索結果メッセージ

31
32

messageQname

ワンストップ例：oss1-wsdl:受領メッセージ
業務ユニット例: boss1-wsdl:住民情報_検索結果

0..*

fault

33

name

NMTOKEN

34
35

messageQname

ワンストップ例：フォルトメッセージ
業務ユニット例: 定義無し
ワンストップ例：refix -wsdl:フォルトメッセージ
業務ユニット例: 定義無し

バインディングの名称
portTypeのname属性の参照

1..*

36

name

NCName

37
38
39
40
41

type

Qname

ワンストップ例：oss1-wsdl:引越転入PT
業務ユニット例: oss1-wsdl:住民基本台帳

42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

wsdlsoap:bindingstyle
transport

1..*

document

http://schemas.xmlsoap.org/soap/http

固定
固定

name

ワンストップ例：引越転入
業務ユニット例: 住民基本台帳_住民情報

対応する抽象オペレーションの名称を設定する

soapAction

ワンストップ例：oss1_1-1-01
業務ユニット例: oss1_1-2007-01_1

nameワンストップ例： 受付メッセージ
業務ユニット例: 住民情報＿問合せメッセージ

portType/inputのname属性と同じ

use

literal固定

nameワンストップ例：受領メッセージ
業務ユニット例: 住民情報_検索結果メッセージ

portType/outputのname属性と同じ

use

literal固定

nameフォルトメッセージ

portType/faultのname属性と同じ

name
use

フォルトメッセージ
literalportType/faultのname属性と同じ
固定

ワンストップ例：引越転入サービス
業務ユニット例: 住民基本台帳サービスの名称

operation

1..1

soap:operation

1..1

input

1..1

soap:body

1..1

output1..1

soap:body

0..*

fault

1..1

soap:fault

1..1

service

1..1

port

name

NCName61

nameNCName62
63binding

Qname

64
65

1..1

message/partのname属性の参照

binding
ワンストップ例：引越転入SOAPBinding
業務ユニット例: 住民基本台帳SOAPBinding

1..1

faultの名称； portType内でユニーク

ワンストップ例： 引越転入
業務ユニット例: 住民基本台帳
ワンストップ例：oss1-wsdl:引越転入SOAPBinding
業務ユニット例: boss1-wsdl:住民基本台帳

portTypeのname属性を参照
bindingのname属性を参照

soap:address
location

http://somedomain/somelocation

サービスを提供するアドレス（URI) 。日本語（２バイト文字）記載
不可(パーセントエンコーディング(*)を含む)。
(*)パーセントエンコーディング(RFC3986参照)

図３．３．１WSDL 定義プロファイル－20－

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

PF標準 WSDLプロファイル（WS-BPEL用）
No.

L1 L2 L3 L4 L5 L6 L7 L8

属性

データ型

事例

備考

WSDLと、SOAPバインディングのバージョン
WSDL１．１ , SOAP 1.1 (SOAPバインディング)
XMLのスキーマ定義言語
W3C XMLSchema 1.0
WSDLのファイル名の規則「定義識別情報＋バージョン＋.wsdl」
エンコーディング
document / literal とする （PF標準はXML文書を交換するため）添付ファイル
メッセージ内にエンコードされる管理主体、対象文書名、バージョン、作成日の情報 definitionsタグ下のdocumentationタグ内に記載する
XMLに関するその他のガイドライン
PF通信のXML定義仕様記載のガイドラインを使用する。
名前空間
PF標準全体で体系的な規則を作成する。
1
2
3<?xml version="1.0"?>

文字コード、符号化規則は、デフォルトのUTF-8とする。

1..1 definitions
name

NMTOKEN
anyURI

4targetNamespace

5

xmlns:prefix -wsdl anyURI

6
7
8
9
10
11

xmlns:prefix -xsd
xmlns:plnk
xmlns:vprop
xmlns:xsd
xmlns

12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

1..1

documentation

0..*
1..1
1..2
1..1
1..1
0..*
1..1
0..1
0..1
0..*
1..1
1..1
0..1

plnk:partnerLinkType

1..1
1..1

types
xsd:schema

anyURI
anyURI
anyURI

anyURI
anyURI

http://docs.oasis-open.org/wsbpel/2.0/plnktype
http://docs.oasis-open.org/wsbpel/2.0/varprop
http://www.w3.org/2001/XMLSchema
http://schemas.xmlsoap.org/wsdl/

文書の説明、管理主体、対象文書名、バージョン、作成日の情
報を入れる

any
NCNamenameportType

NCNameQName

nameelement
type

NCName
QName
QName

propertyの名称；本ファイル内でユニーク；必須

propertyName
element

QName
QName

propertyの名称
対象はelement属性でメッセージを指定する
メッセージ内のタグ位置を記述する（XPath1.0を利用可）

vprop:property
対象はelement属性またはtype属性で指定する

vprop:propertyAlias
vprop:query

targetNamespace anyURI

W3C XMLSchema で記述する。
ユーザ定義のXSDの名前空間のQNAME定義。日本語（２バイト文字）記載不可(パーセントエンコーディング(*)を含む)。

schemaLocation

anyURL

ユーザ定義のXSDを識別するURLを指定。日本語（２バイト文字）記載不可(パーセントエンコーディング(*)を含む)。

name

NCName

メッセージの名称； 本WSDL内でユニーク

nameelement

NMTOKEN
QName

メッセージパートの名称； message内でユニーク
typesにて定義されたelementをQNAMEで参照する

name

NCName

抽象オペレーション群を束ねるポートタイプの名称

name

NCName

抽象オペレーションの名称

namemessage

NMTOKEN
QName

inputの名称； portType内でユニーク
message/partのname属性の参照

namemessage

NMTOKEN
QName

outputの名称； portType内でユニーク
message/partのname属性の参照

namemessage

NMTOKEN
QName

faultの名称； portType内でユニーク
message/partのname属性の参照

xsd:inlcude

1..*

message

1..1
1..1
1..1
1..*

part

1..1

name
role

1..1

1..*

定義名をあらわす名称を付けることを推奨する。
ユーザ定義のWSDLの名前空間宣言。日本語（２バイト文字）
記載不可(パーセントエンコーディング(*)を含む)。
ユーザ定義のWSDLの名前空間のQNAME定義"prefix"は定義
識別情報等で置き換える。日本語（２バイト文字）記載不可(パーセントエンコーディング(*)を含む)。
ユーザ定義のXSDの名前空間のQNAME定義"prefix"は定義
識別情報等で置き換える。日本語（２バイト文字）記載不可(パーセントエンコーディング(*)を含む)。
固定
固定
固定
必須、WSDL1.1用

portType
operation
input

1..1

output

0..*

fault

(*)パーセントエンコーディング(RFC3986参照)

図３．３．２

BPEL 用 WSDL 定義プロファイル－21－

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

３．４ XML 変換ルール
本節では、XML スキーマ定義用ワークシートから XML スキーマ定義への変換ルールを記載する。
変換ルールとして、メッセージの XML スキーマ定義ワークシートのタグの変換、項目セット辞書
ワークシートのタグの変換、データ型・桁数の変換、および出現回数の変換について、下記に示す。

（１）

メッセージの XML スキーマ定義ワークシートのタグの変換ルール

メッセージのルートタグ（メッセージの XML スキーマ定義ワークシートでは最上位行、L１列の位置に記入されたタグ）については、element 宣言に変換する。
L2 のタグ（L2 列に記入されたタグ）については、メッセージルートタグの element 宣言の複合型内容として列挙される element 宣言に変換する。同様に L3 のタグは、すぐ上の L2 タグのelement 宣言の複合型内容として列挙される element 宣言に変換する。以下の階層も同様とする。
<xsd:element name="住民基本台帳-転入メッセージ"><!-- ルートタグ --><xsd:complexType><xsd:sequence><xsd:element name="システム制御情報" .../><!-- L2 のタグが並ぶ --><xsd:element name="住民異動届"><!-- L2 のタグが並ぶ --><xsd:complexType><xsd:sequence><xsd:element name="異動事由"><!-- 住民異動届の下の L3 のタグが並ぶ --><xsd:simpleType><xsd:restriction base="xsd:string"><xsd:maxLength value="2"/></xsd:restriction></xsd:simpleType></xsd:element><xsd:element name="届出年月日" .../><xsd:element name="異動年月日" .../><xsd:element name="異動世帯情報"><xsd:complexType><xsd:sequence><xsd:element name="異動前住所" .../><xsd:element name="異動前世帯主氏名" .../><xsd:element name="異動後住所" .../><xsd:element name="異動後世帯主氏名" .../></xsd:sequence></xsd:complexType>・・・</xsd:element>（２）

項目セット辞書ワークシートのタグの変換

項目セット辞書ワークシートに記載された項目セットのうち、当該メッセージ定義中で参照する項目セットについては、complexType 宣言に変換する。この際、名前として、項目セット名の末尾に"Type"をつけたものを設定する。
項目セットの内容である項目群については、complexType 宣言の複合型内容として列挙される
element 宣言に変換する。項目群が階層を持つ場合は、（１）と同様に下位階層の内容を直前の上
位階層のタグの element 宣言の複合型内容として列挙される element 宣言に変換する。

－22－

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

例）人物情報<xsd:complexType name="人物情報 Type"><xsd:sequence><xsd:element name="氏名情報" ... ><xsd:complexType><xsd:sequence><xsd:element name="氏名" ... /><xsd:element name="フリガナ" ... /></xsd:sequence></xsd:complexType></xsd:element><xsd:element name="生年月日" ... ><xsd:complexType><xsd:sequence><xsd:element name="年号" ... /><xsd:element name="年" ... /><xsd:element name="年" ... /><xsd:element name="年" ... /></xsd:sequence></xsd:complexType></xsd:element></xsd:sequence></xsd:complexType>（３）<!-- 項目セット名 --><!-- 項目セット直下のタグが並ぶ --><!-- 氏名情報の下のタグが並ぶ --><!-- 氏名情報の下のタグが並ぶ --><!--項目セット直下のタグが並ぶ --><!-- 生年月日の下のタグが並ぶ --><!-- 生年月日の下のタグが並ぶ --><!-- 生年月日の下のタグが並ぶ --><!-- 生年月日の下のタグが並ぶ -->データ型・桁数の変換

項目セット辞書に定義された項目セットを参照する場合は、(2)で変換された complexType 宣
言の名前を参照する type 属性に変換する。
例）「システム制御情報」の変換例<xsd:element name="システム制御情報" type="システム制御情報 Type"... />XML データ型辞書にて提供される簡易表記により定義されているデータ型については、XML デー
タ型辞書を参照して、使用されている簡易表記に対応する XML スキーマの定義のとおりの変換を
実施する。

（４）

出現回数の変換

出現回数列の最小を minOccurs 属性値に、最大を maxOccurs 属性値に変換する。
ただし、値が 1 の場合は、変換しない。また、値が N の場合は、unbounded と、実装上問題を来たさない範囲の適切な数値（例、100）のいずれかとする。
例）変換例<xsd:element name="住民異動届" ... ><xsd:complexType><xsd:sequence>・・・<xsd:element name="異動世帯情報" ... />・・・<xsd:element name="異動個人情報" maxOccurs="100"/>
・・・</xsd:element>－23－<!-- 出現回数 1,1 なので変換無し --><!-- 出現回数 N は、適切な値に変換 -->地域情報プラットフォームガイドライン

次に、WSDL 定義ワークシートから WSDL 定義への変換ルールを示す。
WSDL 定義ワークシートから WSDL 定義を生成するには、L1 から L10 の列の内容をタグ名に、属性列の内容を直前行のタグの属性名に、値列の内容をタグ値もしくは属性値に対応させた、XML
文書を作成する。

－24－

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

４．辞書
４．１ 辞書の位置付け
辞書は、「ワンストップサービス連携定義手順」における再利用可能な定義を保持している。策定
手順の各ステップで参照し、辞書の活用による定義作業の効率化と、共通化を行なう。各定義作業で、辞書の改訂を実施する。

ワンストップサービス
連携定義手順辞書

参照定義

業務要件定義作業ステップ
業務要件定義作業ステップ

業務処理整理表
ワンストップＤＦＤ

項目セット辞書

コード辞書

機能関連
ブロック図

XMLデータ型
辞書

ワンストップ
インタフェース仕様

自治体業務アプリ
ケーションユニット
標準仕様V2.0

機能連携
システムフロー

XML定義作業ステップ
XML定義作業ステップ

項目セット辞書

BPMN図

コード辞書

条件分岐定義APPLIC
PF通信標準仕様
・XML関連規定
・WSDL関連規定
・BPEL関連規定

インタフェース
一覧

XMLデータ型
辞書

メッセージ定義

共通定義
WSDLプロファイル

WS-BPEL
定義

BPパターン辞書

図４．１．１WSDL定義XMLスキーマ
定義

XML変換ルール

ワンストップサービス連携定義における辞書の位置付け

地域情報プラットフォーム開発において再利用可能な定義を格納する仕組みを「辞書」、再利用する定義自体を「辞書コンテンツ」と定義する。
辞書コンテンツとして、以下の３種類を管理・提供する。辞書コンテンツを APPLIC で管理し公開
し、APPLIC での標準策定や自治体などでの BP 設計において利用することで、効率化と品質向上を実現することを目的としている。
・項目セット辞書コンテンツ： メッセージを構成する基本データ項目セット集（含、コード）・XML データ型辞書コンテンツ ： 各データ項目のデータ型の種類を規定した辞書
・BP パターン辞書コンテンツ： ビジネスプロセスを構成する基本パターン集、及びビジネスプ
ロセスとしてワンストップシナリオを表現した BP パターン集－25－

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

４．２ 項目セット辞書コンテンツ（１）

項目セット辞書コンテンツの形式

項目セット辞書コンテンツは、メッセージを構成する基本データ項目セット集である。項目
セット辞書のエントリである項目セットは、下記で定義される。
・項目セット名： 項目セットを識別するユニークな名称

・項目名： 項目セットを構成するデータ項目の名称・CD： データ項目のコード化（コード辞書の利用）の有無

・データ型： 基本データ型（「４．３XML データ型辞書コンテンツ」を参照。但し、他の項目セットを内部に持つ場合は、項目セット名）
・桁数： データ項目の最大桁数

・出現回数： データ項目の出現回数

以下、項目セット辞書コンテンツの例を示す。

図４．２．１

項目セット辞書の例－26－地域情報プラットフォームガイドライン

コード辞書コンテンツは、メッセージを構成するデータ項目が値としてとりうるコード集である。コード辞書のエントリは、下記で定義される。
・項目名： コード辞書のエントリ名

・データ型： 基本データ型（「４．３・桁数： コードとして取りうる最大桁数

・コード値： 列挙可能なコード値の場合、コード値

XML データ型辞書コンテンツ」を参照）

列挙できないコード値（外部団体の定義等）の場合、“－”・コード値の内容：

コード値の説明

以下、コード辞書コンテンツの例を示す。

図４．２．２（２）

コード辞書の例

項目セット辞書コンテンツのユースケース

・メッセージ設計において、データ項目を定義する際、項目セット辞書を見て、適切な項目セッ
トがあれば、積極的に使用する。
・使用する場合は、項目セット辞書に対応する項目名とそのデータタイプとして項目セット名を記載する。

（３）

項目セット辞書コンテンツの管理（APPLIC

技術専門委員会にて管理する）

・メッセージ設計において、新しい項目セットの候補がでた場合は、既存の項目との整合をみて、新規にエントリを作成するか、既存の項目セットを改訂するかを決定する。
・新規の場合は、項目セット辞書名が重複しないように命名する。
・更新の場合はオプションとして項目を追加する場合のみ可能とする。オプションでない場合は新規に作成する。
－27－

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

４．３ XML データ型辞書コンテンツ
XML データ型辞書は、各データ項目のデータ型の種類を規定した辞書である。
XML データ型辞書の目的は、・上流設計におけるデータ型の簡易表記を提供すること。
・下流設計における簡易表記に対する XML スキーマの表現形式を定義すること。

（１）

XML データ型辞書コンテンツとはXML データ型辞書コンテンツの提供するデータ型の簡易表記を下記の表に示す。
表４．３．１
データ型

XML データ型辞書コンテンツによるデータ型の簡易表記
記述形式

半角文字列

データ型
X

桁数
n

全角文字列

N

n

整数

9

n

小数点付き実数

9Vn,m

符号付き整数S9n

符号付き小数点
付き実数

S9V

n,m

（２）

説明
半角文字列で、文字数 n 個以下。
例）n=10 の場合
abcd，a12bcX5de，a123!#$FGH
全角文字列で、文字数 n 個以下。
例）n=10 の場合
業務分析，地域情報プラットフォ，
ＡＢＣ１２３，０９８ＤＥ＄％あいう
n 桁以下の正の整数例）n=2 の場合 0 から 99 までの整数
整数部 n 桁、小数部 m 桁の正の実数例）n=2、m=3 の場合
0.000 から 99.999 までの実数※ 0, 0.0, 0.00, 0.000 という表記も可
n 桁以下の整数。正の値の場合は「+」を付けても付けなくても良い。負の値の場合は「-」を付ける。
例）n=2 の場合 -99 から+99 までの整数
整数部 n 桁、小数部 m 桁の実数。正の値の場合は「+」を付けても付けなくても良い。負の値の場合は「-」を付ける
例）n=2、m=3 の場合-99.999 から+99.999 までの実数

簡易表記に対する XML スキーマの表現形式の定義

表４．３．１のデータ型については、下記のとおりの XML スキーマ表現形式を対応させる。
①

半角文字列
XML Schema 組み込みデータ型の文字列（xsd:string）を元に、桁数列の値を文字数の制約として付与した単純型として定義する。
例）「日付情報」「年」の変換例<xsd:element name="年" ... ><xsd:simpleType><xsd:restriction base="xsd:string"><xsd:maxLength value="4" /></xsd:restriction></xsd:simpleType></xsd:element>－28－

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

②

全角文字列
例）
「氏名情報」「氏名」の変換例<xsd:element name="氏名" ... ><xsd:simpleType><xsd:restriction base="xsd:string"><xsd:maxLength value="150" /></xsd:restriction></xsd:simpleType></xsd:element>③

整数
XML Schema 組み込みデータ型の正の整数（xsd: integer）を元に、桁数列の値に基づく最大数値の制約を付与した単純型として定義する。
例）「データ型 9, 桁数 4」の変換例<xsd:element name="整数 4" ... ><xsd:simpleType><xsd:restriction base="xsd: integer "><xsd totalDigits value="4" /></xsd:restriction></xsd:simpleType></xsd:element>④

小数点付き実数
XML Schema 組み込みデータ型の実数（xsd:decimal）を元に、桁数列の値に基づく最大数

値の制約を付与した単純型として定義する。
例）「データ型 9V, 桁数 4, 2」の変換例<xsd:element name="実数 4_2" ... ><xsd:simpleType><xsd:restriction base="xsd:decimal"><xsd totalDigits value="6" /><xsd fractionDigits value="2" /></xsd:restriction></xsd:simpleType></xsd:element>⑤

符号付き整数XML Schema 組み込みデータ型の正の整数（xsd:integer）を元に、桁数列の値に基づく最大数値の制約を付与した単純型として定義する。
例）「データ型 S9, 桁数 4」の変換例<xsd:element name="符号付整数 4" ... ><xsd:simpleType><xsd:restriction base="xsd:integer"><xsd totalDigits value="4" /></xsd:restriction></xsd:simpleType></xsd:element>－29－

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

符号付き小数点付き実数
XML Schema 組み込みデータ型の実数（xsd:decimal）を元に、桁数列の値に基づく最大数

値の制約を付与した単純型として定義する。
例）「データ型 S9V, 桁数 4, 2」の変換例<xsd:element name="符号付実数 4_2" ... ><xsd:simpleType><xsd:restriction base="xsd:decimal"><xsd totalDigits value="6" /><xsd fractionDigits value="2" /></xsd:restriction></xsd:simpleType></xsd:element>

４．４ BP パターン辞書コンテンツ（１）

BP パターン辞書コンテンツとはBP パターン辞書コンテンツは、BP パターンと登録ワークシートから構成される。その特徴を下記に示す。
・BP パターンとはビジネスプロセスをパターン化し、検索、再利用可能化したものである。
・BP パターンは BP の属性情報、BP 定義、WS-BPEL 定義や WSDL 定義の XML 定義（オプション）から構成される。これらは登録ワークシート上に記述され、BP パターン辞書に登録される。
・BP パターンは BP の属性情報、BP 定義、WS-BPEL 定義や WSDL 定義の XML 定義（オプション）から構成される。これらは登録ワークシート上に記述され、BP パターン辞書に登録される。
・BP 設計時、BP パターンを属性情報で検索し、適切な BP パターンを選択。BP パターン定義（BP
定義、XML 定義）を活用し新しい BP 定義を作成することにより新シナリオの BP を作成。新シナリオの BP はパターン化して辞書登録。
・BP パターンの属性は、BP パターンを識別する項目、BP の品質特性、機能的な仕様、非機能的な特徴等で規定される。
BP パターン辞書は、ビジネスプロセス（BP）の定型的なパターンを登録する辞書であり、BPを定義する際に、再利用することで、設計品質や設計効率を向上させるためのものである。
BP パターンは、大別すると下記の２種類があり、ユースケースが異なる。
①

部品 BP パターン内容

： BP 表現の基本パターンの BPMN 図とその WS-BPEL 記述例

ユースケース ： ワ ン ス ト ッ プ シ ナ リ オ の ビ ジ ネ ス プ ロ セ ス を 定 義 す る 際 の
基本構成要素として選択し、利用する。
例、分岐待ち合わせパターン②

シナリオ BP パターン内容

： 各種ワンストップシナリオのビジネスプロセスの定義

ユースケース ： 自治体等が、自自治体のワンストップシナリオを作成する際の参考シナリオとして選択し、自自治体用に変更する。

－30－

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

BP パターン辞書コンテンツの利用イメージ

次に、BP パターン辞書コンテンツの利用のイメージを下図に示す。なお、BP パターン辞書は、
まだ APPLIC では、運用を開始していない。

ＡＰＰＬＩＣＢＰ設計フェーズ

ＢＰパターン定義辞書
検索① BP設計時、BPパターン辞書を属性で検索

シナリオ表現
ＢＰパターン定義②適切なBPパターンを選択③ワークシート上の定義を活用し新しいBP定義を作成④新シナリオをBPパターンとして辞書登録

ＢＰパターン定義辞書
管理組織が整合管理

図４．４．１（３）

BP パターン辞書の運用のイメージ

部品 BP パターン

部品 BP パターンは、BP 表現の基本パターンの BPMN 図とその WS-BPEL 記述例のセットから構成される。ワンストップシナリオのビジネスプロセスを定義する際の基本構成要素として選択し、組み合わせることで全体を定義する。
①

部品 BP パターンの例#

パターン名称1

単純パターン2

直列パターン3

分岐待ち合わせパターン

図４．４．２

部品 BP パターン(トポロジー部品)一覧－31－地域情報プラットフォームガイドライン#

パターン名称

1

サービス開始、停止順序

2

保守実施時刻3

平行同時実行数

4

応答時間

5

平均処理件数6

タイムアウト時間

7

プロセス方式

8

トランザクション識別子

9

同時実行可否10

トランザクション属性

11

トランザクション特性

12

可用性

13

クラスタ構成情報

14

接続認証

15

接続可否権限情報16

メッセージ配信17

サービス仲介18

サービス斡旋19

サービス紹介20

コミュニケーション

21

セッション管理22

通信プロトコル

23

状態管理

24

トランザクション方式

25

セキュリティ方式

26

暗号化方式

27

署名付加

28

情報共有範囲29

コンテキスト引継要否

30

データ

31

ファイル転送方式

32

メッセージ変換方式

33

バッチ処理

34

定義更新時間35

監視方法定義

36

監視方法

37

メッセージ変換定義

図４．４．３

部品 BP パターン(非機能要件部品)一覧－32－地域情報プラットフォームガイドライン②

部品 BP パターン
以下に、部品 BP パターンの例を挙げる。

分岐待ち合わせパターン①BPEL表記<?xml<?xml version="1.0"
version="1.0" encoding="UTF-8"?>
encoding="UTF-8"?><process<process name="分岐待ち合わせパターン"
name="分岐待ち合わせパターン"targetNamespace="http://example.org/"targetNamespace="http://example.org/" xmlns="…">
xmlns="…"><sequence><sequence><receive<receive partnerLink="Role1"
partnerLink="Role1" operation="Op1"
operation="Op1" createInstance="yes"createInstance="yes" />/><invoke<invoke name="A"
name="A" partnerLink="Role2"
partnerLink="Role2" operation="Op2"
operation="Op2" />/><flow><flow><invoke<invoke name="B"
name="B" partnerLink="Role3"
partnerLink="Role3" operation="Op3"
operation="Op3" />/><invoke<invoke name="C"
name="C" partnerLink="Role4"
partnerLink="Role4" operation="Op4"
operation="Op4" />/></flow></flow><replypartnerLink="Role1"
operation="Op1"/><reply partnerLink="Role1" operation="Op1" /></sequence></sequence></process></process>②BPMN表記

4

図４．４．４22

部品 BP パターン(トポロジー部品)の例

通信プロトコル：<Protocol>①XML表記<process(業務フロー)<process(業務フロー)name=“AAA”
name=“AAA”>>※<extActivity<extActivity※name=“XXX”
name=“XXX”>><Protocol<ProtocolType=“soap”
Type=“soap”| |“ws-r”“ws-r”| |“soap-attachment”/>“soap-attachment”/>
・・・</extActivity>
・・・</extActivity>
・・・
・・・</process></process>※：extActivity・・・実際には、receive、invoke、reply等が入る。

②図形表記

AAA

SOAP

このように指定アクティビティ単位にプロトコルアイコンを関連付けることで、プロトコルを示す。

XXX
WS-R
SOAP
Attachment27

図４．４．５

部品 BP パターン(非機能要件トポロジー部品)の例－33－

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

シナリオ BP パターン

シナリオ BP パターンは各種ワンストップシナリオのビジネスプロセスの定義で構成される。
定義は BP の属性情報、BP 定義、WS-BPEL 定義や WSDL 定義の XML 定義（ｵﾌﾟｼｮﾝ）で構成される。
自治体等が、自自治体のワンストップシナリオを作成する際の参考シナリオとして選択し、自治体用に変更する。
①

シナリオ BP パターンのイメージ#

シナリオ BP パターン名

登録日

1

引越パターン

XXXX

2008/9/1

2

婚姻パターン

XXXX

2008/9/1

3

仕事パターン

XXXX

2008/9/1

4

出生・死亡パターン

XXXX

2008/9/1

5

国民年金加入パターン

XXXX

2008/9/1

6

住基登録パターン

XXXX

2008/9/1

図４．４．６②

登録団体

シナリオ BP パターン一覧

シナリオ BP パターン
以下にシナリオ BP パターンの例を示す。

図４．４．７

BP パターン例（BPMN）－34－

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

BP パターン登録ワークシート①

BP パターンの登録ワークシート
次に、BP パターンを辞書に登録するためのワークシートについて下記に示す。BP パターン

辞書のワークシートは、以下の４つのページから構成される。
・BP パターン登録フォーム（パターンを分類する情報）
・BP パターン－図形表現（BPMN 図、もしくは、開発ツールの BP 表現画面のハードコピー）
・BP パターン－XML 表現（WS-BPEL、オプション）・BP パターン－XML 表現（WSDL、オプション）
BP パターン登録フォームと、BP パターン－図形表現（BPMN 図）のイメージを下記に示す。

図４．４．８

BP パターン登録フォーム－35－

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

図４．４．９

BP パターン－図形表現の例－36－

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

第４章 付録４－ⅰ
付加価値サービスのサンプル

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

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

第４章 付録４－ⅲ
各種定義体サンプル

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

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

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

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

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

住民向けの情報提供

自治体A

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

情報照会

情報照会
情報通知

バックオフィス連携基盤

情報通知
自治体間連携

図 ５．１．１

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

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

－1－

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

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

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

サービス基盤

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

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

業務
ユニット

図５．１．２

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

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

－2－

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

利用者

ポータル

サービス提供者

バックオフィス連携基盤

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

団体間情報連携

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

1
回答送付

2

団体間連携
情報

回答受取

原課

4

4
回答受付

1

照会依頼

照会依頼受付

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

3

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

3

照会回答
原課

参照用情報
依頼受付

照会依頼送付2

図５．１．３

3

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

表５．１．１
No
1

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

2

電子署名付与の方法
345

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

電子署名の検証方法

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

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

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

検証者

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

検証範囲①情報単位に付与された署名を各原課にて検証（情報の正当性の確認）②情報全体に付与された署名を窓口にて検証（回答者の確認）－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

住民①

A

AA

住民①

図５．２．２

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

－15－

地域情報プラットフォームガイドライン V2.9 別冊

ＧＩＳ共通サービスガイドライン＜住民地図を活用して行政業務の高度化を実現＞

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

地域情報プラットフォームガイドライン 別冊
GIS 共通サービスガイドライン●発行日2019 年 3 月●編集

一般財団法人全国地域情報課推進協会
標準推進委員会/GIS ワーキンググループ

目
1.

2.

3.

4.

5.

6.

次

本書の目的............................................................................................................................................1
1.1.

本書の目的 .................................................................................................................................1

1.2.

本書の位置づけ .........................................................................................................................2

1.3.

GIS共通サービスに関する関連図書 ......................................................................................3

1.4.

本書の想定される利用シーン .................................................................................................4

GISユニットおよびGIS共通サービスとは ......................................................................................5
2.1.

GISユニットおよびGIS共通サービスの目的 ........................................................................5

2.2.

GISユニットおよびGIS共通サービスの概要 ........................................................................6

2.3.

GIS共通サービス利用機能 ......................................................................................................8

2.4.

GISユニットと統合型GISの関係 ............................................................................................9GIS共通サービスの活用と効果 .......................................................................................................11
3.1.

行政業務における活用事例と効果 .......................................................................................11

3.2.

危機管理における活用事例と効果 .......................................................................................14

GIS共通サービスの導入・運用 .......................................................................................................17
4.1.

GIS共通サービスの導入パターン ........................................................................................18

4.2.

GIS共通サービス導入に向けた手順 ....................................................................................23

4.3.

GIS共通サービスの運用 ........................................................................................................24

地名辞典の整備・運用 ......................................................................................................................25
5.1.

地名辞典の目的 .......................................................................................................................25

5.2.

自治体における地名辞典の歴史と重要性 ...........................................................................26

5.3.

地名辞典を活用した住民地図の整備 ...................................................................................28

5.4.

地名辞典の利用目的に合わせた整備レベル .......................................................................29

5.5.

地名辞典の要件 .......................................................................................................................34

5.6.

地名辞典の運用の考え方 .......................................................................................................37

5.7.

地名辞典の整備手法 ...............................................................................................................425.8.

地名辞典の更新手法 ...............................................................................................................55

GISユニットの調達 ...........................................................................................................................63
6.1.

GISユニットの調達の手順 ....................................................................................................63

6.2.

GIS共通サービスの調達・運用にかかる積算項目.............................................................67

6.3.

GIS共通サービスの調達仕様 ................................................................................................72

7.

付録......................................................................................................................................................75
7.1.

インタフェース仕様一覧 .......................................................................................................75

7.2.

区割り地図の整備・運用 .......................................................................................................77

7.3.

地方公共団体の地名辞典の整備・運用事例 .......................................................................84

7.4.

用語集 .....................................................................................................................................105

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

1. 本書の目的
1.1. 本書の目的
住所をはじめとした位置を指し示す情報は行政の様々な業務で頻繁に利用されている。住民や施設等の所在地を扱うサービス提供・事務等手続き・政策分析・政策判断など地域情報が必要とされる機会は多い。
地理空間情報と様々な業務システムを電子的に連携し、住民や施設等に関わる情報を簡便に地図上に描きだす（見える化）ことが可能となれば、住民支援サービスの高度化・日常業務の効率化・政策立案の向上が期待できる。
本書は、地理空間情報と業務情報の連携の実現ために定められた業務ユニット間インタフェースの共通仕様である「GIS 共通サービス標準仕様」について、調達・導入・管理・運用・活用等にかかる手順や指針をまとめたものである。特に、GIS の導入・改更や、GIS の更なる利活用を検討している自治体担当者において参考とされることを目的としている。
また、本書は、自治体の GIS の担当者に活用されることを目的として作成しているが、GIS
共通サービス標準仕様の対応製品を開発、構築、販売する民間企業のベンダーにおいても、調達指針等の理解の検討の一助となるものである。

1

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

1.2. 本書の位置づけ
地域情報プラットフォーム標準仕様は、自治体業務システムにおける情報連携の標準仕様を定めたものであり、「業務モデル標準」、「サービス協調技術標準」、「GIS 共通サービス標
準」及び「地域情報プラットフォームガイドライン」で構成されている。
本書は、地域情報プラットフォームガイドラインの別冊として、「目的」に記載したとおり、
GIS 共通サービス標準仕様の調達・導入・管理・運用・活用等にかかる手順や指針を示すもの
である。

地
域
情
報
プ
ラ
ッ
ト
フ
ォ
ー
ム
標
準
仕
様
書

業務モデル標準

サービス協調技術標準

自治体及び民間が提供する地域情報サービスの連携に必要な業務
アプリケーションユニットのインタフェース仕様

サービス連携を支える基盤アプリの諸要件・プロトコ
ル等を取り決めた仕様

自治体業務アプリケーションユニット標準仕様
防災業務アプリケーションユニット標準仕様

アーキテクチャ標準仕様

プラットフォーム通信標準仕様

・防災情報共有 ・避難行動要支援者名簿管理
・被災者台帳管理

教育情報アプリケーションユニット標準仕様
・校務基本情報データ連携 小中学校版
・校務基本情報データ連携 高等学校版
GISを活用した業務ユニット、アプリケーションを構築するための共通仕様

GIS共通サービス標準仕様
各種システム製品等の地域情報プラットフォーム準拠及び相互接続を確認する仕様

地域情報プラットフォーム準拠確認及び相互接続確認仕様
仕様に準拠したサービス基盤および業務アプリケーションを導入する調達者向けに必要な事項をとりまとめたもの（指針）

地域情報プラットフォームガイドライン
別冊： GIS共通サービスガイドライン （本書）
その他

地域情報プラットフォーム基本説明書
地域情報プラットフォーム標準仕様運用規則

資参料考

地域情報プラットフォームガイドライン 技術解説 要約
地域情報プラットフォームにおけるＧＩＳ共通サービス基本提案書
地名辞典整備の手引きと活用事例集
地域情報プラットフォームを活用した業務改善とシステム調達の手引き
地域情報プラットフォームにおけるGISユニット調達の手引き

図 1－1 地域情報プラットフォーム標準仕様書の構成と本書の位置づけ

2

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

1.3. GIS 共通サービスに関する関連図書
一般財団法人全国地域情報化推進協会（以下、APPLIC）においては、本書の他に GIS 共通
サービス標準仕様に関する以下の関連図書を作成している。本書は、これらの各種図書の内容を包括的に記述しているが、GIS 共通サービスをより深く理解する場合や、自治体担当者が庁内において関係者に説明する場合等には、用途に応じてこれらの関連図書を参考にすることが望ましい。

図 1－2 GIS 共通サービスに関する関連図書

3

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

1.4. 本書の想定される利用シーン
本書は以下のような状況で利用されることを想定している。

Ｇ
Ｉ
Ｓ

共
通
サ
ー
ビ
ス
の
導
入
高デ
度ー
活タ
用や
にア
かプ
かリ
るケ
検ー
討シ
ョ
ン
の

運効
用率
保的
守な

統合型GIS（庁内共通GISや共用空間データベース）の導入・リプレースの検討
新規でGISを導入する場合においては、GIS共通サービスに対応したGISを導入することが望ましい。

また、統合型GISにおける共用空間データの要素の一つとして、地名辞典（後述）を位置付けて導入することも考えられる。このような検討を実施する場合の基礎資料として、本書を活用することが可能である。

業務ユニット等のアプリケーションの導入・リプレースの検討
住基、税などの業務ユニットおよびそれ以外のアプリケーション、例えば、都市計画、インフラ管理、医療、農業、住民サービスなどの様々なシステムを自治体は導入している。この導入の際に、GIS共通サービスを搭載することにより、地図による可視化が可能となる。これらのシステムの導入やリプレイスの検討の場合において、参考とすることが可能である。

業務ユニットの更なる高度活用を検討
多くの自治体において、既に業務ユニットの導入・運用が行われている。これらに連携したGIS共通サービスを導入し、業務ユニットの各データをGISで地図として可視化させ、業務効率を向上させることを検討する場合において、本書を活用することが可能である。

既にGIS共通サービスを導入済だが更なる高度活用を検討
GIS共有サービスに対応したアプリケーション等を導入済であるが、業務システムとの連携を図り、データを活用した地域分析・政策立案を行う場合や、業務効率の更なる向上を図りたい場合など、
アプリケーションの更なる高度活用を検討する場合には、本書は有効な指針となる。その場合、本書のGIS共通サービスを活用したユースケース（事例）や、GIS共通サービスの管理・運用の記載を中心に参考とすることが可能である。

地名辞典などの地理空間データの効率的な運用等の検討
既にGIS共有サービスに対応したアプリケーションや地名辞典を導入している自治体において、今後の運用を効率的に実施したい場合に、本書を活用した検討を行うことが可能である。特に、地名辞典の高精度化や効率的な更新にかかる方法を理解し、取り入れていくことで、庁内におけるGISの利活用者を増加させることにつながり、庁内全体として、効果的な政策や業務効率の向上を図ることが可能となる。

4

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

2. GIS ユニットおよび GIS 共通サービスとは
2.1. GIS ユニットおよび GIS 共通サービスの目的
APPLIC では、地域情報プラットフォーム上での業務情報と地理空間情報との連携を目的とした「GIS 共通サービス標準仕様」を定めている。
「GIS 共通サービス」を実装した製品である「GIS ユニット」を導入し「地名辞典」を整備することで、自治体業務において運用管理される業務情報に位置情報を付加し、その所在を「見える化」できる。このように、住民に紐付く業務情報が見える化された地図のことを「住民地図」と呼び、「地名辞典」や「GIS ユニット」は「住民地図」を実現するためのツールである。
地名辞典の基本住民地図
例：避難行動要支援者の分布図

実現

しくみ

避難行動要支援者の分布を把握し、
災害時の支援等に活用！

避難行動
要支援者システム

地域情報プラットフォーム
要支援者の住所

住基情報

障害者福祉情報

要介護情報

健康管理情報（35.876，
139.988）

指定座標の
位置を表示

住所に座標付与

GIS共通サービスインタフェース
住民基本台帳
システム

住登外管理
システム

業務情報

団体内統合
宛名機能※

業務情報

GISDB
障害者福祉
システム

介護保険
システム

業務情報

業務情報

健康管理
システム
業務情報

団体内統合
宛名番号

地名辞典
（住所辞書） 地図データ

GISユニット※「団体内統合宛名機能」は地域情報プラットフォームにおいて、「団体統合宛名システ
ム」を実現する上で必要となる「住民基本台帳ユニット」と「住登外管理ユニット」と中間サーバを接続するのに必要となる機能を集約させたものです。

図 ２－１ GIS 共通サービスによる業務情報の見える化

5地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

2.2. GIS ユニットおよび GIS 共通サービスの概要
2.2.1. GIS ユニット
「GIS ユニット」は、「GIS 共通サービス」を実装した製品であり、様々な業務に対してGIS 共通サービスを提供する。
「GIS ユニット」には、以下のような役割がある。
・ 地理空間データの蓄積・管理
他の業務ユニットから共通的に参照される地理空間データを蓄積・管理するためのデータベースである「GISDB」を持つ。
・ GIS 共通サービスの提供
GISDB 内の地理空間データの検索・表示など、GIS としての共通的な機能をサービスとして提供するために、「GIS 共通サービス」を実装し「GIS 共通サービスインタフェース」として提供する。各業務ユニットは、GIS 共通サービスを呼び出して利用するために「GIS 共通サービス利用機能」を実装し、GIS ユニットから取得した地理空間デー
タを用いて、位置検索や地図表示などの機能を提供することができる。
・ 地理空間データの交換
地理空間データは、各業務ユニットから利用されることで自治体の各種業務に活用可
能なデータである。GIS ユニットは、他社製のものに差し替えられた場合であっても、容易に交換し移行できるように、データエクスポート・インポート機能を持つ。

地理空間データの蓄積・管理業務ユニット
位置検索

地図表示

その他機能

GIS共通サービス利用機能

GISユニット
GISDBGIS共通サービス

エ イ 交
ク ン 換
ス ポ 用
ポ ー 地
ー ト 理
ト 機 空
機 能 間
能 ・ デ
ー
タ

GIS共通ｻｰﾋﾞｽｲﾝﾀﾌｪｰｽ

地域情報プラットフォーム
GIS共通サービスの提供

図 ２－２ GIS ユニットの役割と構成

6

地理空間データの交換
交換用地理
空間データ
ス キーマ 仕様に 基づ
い た符号 化・復 号化

交換用データスキーマ仕様地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

2.2.2. GIS 共通サービス「GIS 共通サービス」は、「GIS ユニット」が提供し地域情報プラットフォーム上の業務ユニットなどが共通的に利用可能なサービスであり、「地名辞典サービス」と「地図表示サービス」の 2 種類で構成される。

（１） 地名辞典サービス
GISDB 内で管理される地名辞典のデータを検索し、住所などの地理識別子に対応する位置（地理座標＝緯度・経度など）を提供するサービス。
オプションとして、地名辞典内のデータを編集・更新するための簡易的な機能、および、地名辞典内の地理識別子の情報同士の関連を検索・編集するための機能を持つ。

○○さんの居住地を地図上に表示したいので、住所に対応する座標値（緯度・経度など）が知りたい。

行政の持つ「住所」に位置（座標）を付けて返す
住所：○○町二丁目2-2○ ○さん の居住 地位置 図

座標：（35.111，139.222）

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

GISユニット

図 ２－３ 地名辞典サービスの主たる機能（２） 地図表示サービス（オプション）
地域情報プラットフォーム上の業務ユニットなどから要求された条件に応じて、GISDB 内の地図データを地図画像として提供するためのサービス。応用的な機能として、業務ユニットなどが持つ統計情報などを主題図画像（例：字・町丁目界の色分け図）として提供するための機能を持つ。
なお、地図表示サービスは、GIS 共通サービス標準仕様ではオプションであり、GIS ユニットへの実装は必須ではない。

7

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

2.3. GIS 共通サービス利用機能
地域情報プラットフォーム上の各業務ユニットは、GIS ユニットが提供する GIS 共通サービスを利用するための機能として、「GIS 共通サービス利用機能」を実装することで、GIS ユニ
ットから取得した地理空間データを用いて、位置検索や地図表示などの機能を構築することができる。

業務ユニットGISユニット

位置

地図

その他

検索

表示

機能

GISDB

GIS共通サービス利用機能

GIS共通サービス
GIS共通ｻｰﾋﾞｽｲﾝﾀﾌｪｰｽ

地域情報プラットフォーム
GIS共通サービスの利用

図 ２－４ GIS 共通サービス利用機能の構成

8

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

2.4. GIS ユニットと統合型 GIS の関係
2.4.1. 統合型 GIS の概念
全国の自治体で導入が進んでいる統合型 GIS では、庁内の複数部署で様々な用途に利用可能な共用性の高い地理空間情報を「共用空間データ」と位置づけ、「共用空間データ」を整備・利用することで、データ整備の重複を防ぐとともに、様々な行政分野において住民サービスの向上・庁内の業務の効率化・高度化、地域の課題解決を実現することを目指している。
現在、統合型 GIS は多数の地方公共団体で導入が進んでおり、導入済みの地方公共団体では、構築段階から日常的な業務での活用段階に入っている。
統合型 GIS においては、そのシステムの構築について「全庁で利用できる“1 つのアプリケー
ションプログラム”で構成されるものではなく、1 つ又は複数のデータベースやアプリケーショ
ンプログラムが、共用空間データをベースに連携し、庁内で情報を共用できる構成」とすることとしている。
すなわち、GIS アプリケーションの統合は必ずしも必要ではなく、自治体が保有する地理空間情報の共有と流通が最も重要であると位置づけられている。

企画調整業務
GIS利用

防災業務
GIS利用

共用空間データ

固定資産業務GIS利用

地理空間情報都市整備業務
GIS利用

地名辞典（住所辞書）
福祉・子育て支
援業務
GIS利用

上下水道業務
GIS利用

○○業務
GIS利用

図 ２－５ 統合型 GIS の概念（共用空間データをベースに連携し庁内で情報を共用できる）
ただし、具体的な連携方式を規定しているわけでなく、「共通インタフェースやデータ交換
フォーマットを利用することにより、共用空間データベースと複数の個別業務用システムや GIS
ソフトウェアとのデータ交換が実現される」としている。

9

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

2.4.2. GIS ユニットと統合型 GIS の関係
この共通インタフェースにおける連携の考え方は、地域情報プラットフォームの考え方と共通するものであり、地域情報プラットフォームの「GIS 共通サービス標準仕様」で定められる
GIS ユニットは、統合型 GIS における共通インタフェースを提供するものと位置づけることができる。
また、「地名辞典」を「共用空間データ」のひとつとして位置したうえで、地域情報プラットフォーム準拠の「GIS ユニット」を導入することで、庁内の各種情報システムでの共用空間
データの利活用を促進させられる。

GISユニットは共用空間データを行政情報システムで利活用するためのシステム基盤
地域情報プラットフォームにより共用空間データを各情報システムで利活用

地域情報プラットフォーム
利用者（住民）＜Ａ自治体＞

業務ユニット業務ユニット
フロント系業務ユニット
フロント系業務ユニット＜ポータル事業者＞

電
子
申
請

共通系業務
共通系業務
ユニット
ユニット

バック系業務ユニット
バック系業務ユニット

電
子
調
達

個
人
住
民
税

住
民
基
本
台
帳

介
護
保
険

住
登
外
管
理

開発
業務標準定義業務標準定義ＧＩ
ＳIT標準定義IT標準定義共用空間データ

地域ポータル
地域ポータル

地名辞典

業務ユニット間インタフェース
業務ユニット間インタフェース
統合DB機能サービス基盤サービス基盤運用

サービス基盤
PF通信機能PF通信機能

SOAP

BPM機能
BPM機能

S

＜民間企業＞
民間業務アプリ
民間業務アプリサービス基盤サービス基盤

PF共通機能PF共通機能セキュリティ

システム運用システム運用高信頼性通信E・・・

プロセス制御メッセージ交換パターン

ユーティリティ

認証・認可

モニタリング

建物データ
河川データ

＜B自治体＞

業務ユニット間インタフェース
業務ユニット間インタフェース

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

道路データ

サービス基盤サービス基盤

フロント系
フロント系
業務ユニット業務ユニット

バック系
バック系
業務ユニット業務ユニット

共通系
共通系
業務ユニット業務ユニット

統合型GISによる共用空間データの整備➔統合型GISで整備される共用空間データを行政情報システムで利活用するためのシステム
図 ２－６ 地域情報プラットフォームの GIS ユニットと統合型 GIS の関係基盤となる。

10

地
名
辞
典
を
共
用
空
間
デ
ー
タ
と
し
て
整
備

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

3. GIS 共通サービスの活用と効果
3.1. 行政業務における活用事例と効果
行政業務へ住民地図や地名辞典を用いた活用事例を紹介する。

3.1.1. データを把握し交通空白地帯調査
住民の世帯構成や分布などを住民地図で分析し、バスの路線網と掛け合わせて交通空白地帯を抽出することで、バス路線の見直し・再編を行っている事例がある。
会津若松市では、「路線バスはしっかり検討して需要がある地域に路線を引かないと、利用者の減少から収益の悪化につながり、さらなる減便になるという負の連鎖が発生する。」ということから、総合的な公共交通の路線網とカバー人口やバス停ごとの乗降の相関分析、潜在需
要の分析など住民地図を利用して検証した。住民地図を用いた資料で現状を視覚化した上で、それらの資料を使って地域住民や運営企業との協議を重ねた。「住民地図を利用して視覚化したデータを活用することで多くの関係者の理解が得らえるようになった。また効果的な路線を引くことが可能となり、KKD（経験・勘・度胸）に頼っていた従来の考えかたから抜け出すことが可能となった」という。

図 ３－１ 住民地図の利用場面（会津若松市）

11

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

また、佐賀市でも交通空白地帯調査を職員自身で実施している。統合型 GIS の導入と合せて整備した住所辞書を用いて、住民地図を作成して公共交通から離れた箇所に居住している住民を把握した。
佐賀市では交通空白地調査の実施予定にあたる調査年度毎に委託予算を準備し、コンサルタ
ントへ発注していたが、住民地図を職員が利用できるようになり委託費が不要になった。

高齢者の世帯の住所をアドレスマッチング
バス停

図 ３－２ 公共交通空白地調査での住民地図の利用イメージ（佐賀市）

3.1.2. 庁内ポータルで住民地図のアドレスマッチング
西宮市では庁内ポータルサイトを設け、職員誰もが利用できる住所辞書を整備しており、GISの利便性を向上させている。
西宮市では庁内ポータルサイトに職員が誰でも利用できる GIS ソフトウェア（西宮市版地図作
成ソフト）と各部署が情報共有用に作成した地図情報が共有されている。市職員が日常業務で利用する資料には市内の住所録の情報を扱うことが多いが、住所が紐つく情報の地図展開を簡単にできるように、西宮市が整備してきた住所辞書をポータルサイトで利用できるようにした。
これにより市職員の扱う資料には住所の欄の横に座標を持たせることが容易にできるようになり、地図に展開しやすくなった。また、このシステムを用いることで、市が提供するオープンデー
タには座標とセットで提供されるようになり、オープンデータの利用者の利便性が向上している。

12

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

図 ３－３ 地名辞典（住所辞書）を用いた座標変換システム（西宮市）

3.1.3. 立地適正化計画の策定に住民地図を活用
室蘭市では、立地適正化計画の居住誘導区域を設定する際に、地形の標高モデルデータから傾斜角を表示し、傾斜のきつい土地は区域からはずすなど、データを用いた客観的な判断に GISを活用を検討している。立地適正化計画の策定に際し、住民の居所を適切に把握することが重要になり、住民地図の使用が効果的であると考えている。

図 ３－４ 急傾斜地と住民の居所を把握し立地適正化計画を検討（室蘭市）

13

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

3.2. 危機管理における活用事例と効果
3.2.1. 被災者予測と福祉情報の連携
住民の居所を示す住民地図は、危機管理の場面において非常に重要になる。
災害対策基本法では、避難行動要支援者リストの整備が定められており、避難行動要支援者の位置の把握は災害時の公助・共助を迅速にするためにも効果が高い。
また、災害の発生後には、被災家屋に暮らしていた住民に各種の支援を受けられるようにする「り災証明」の発行手続きに住民地図が重要になる。これらの実施には、被災者が居住していた場所を把握して、被災の状況と関連付けるといった作業を迅速に行う必要があるが、この作業に住民基本台帳と一致する地名辞典（住所辞書）で作成した住民地図と GIS が不可欠である。
下記は、地図と住民情報がリンクすることで、福祉情報まで繋がるという事例である。福祉情報
は、被災予測の段階では、支援すべき住民を明らかにでき、被災後であれば、避難所等で見守るた
めに必要なことを教える情報としての価値が生まれる。危機管理には欠かせない情報連携である。
埼玉県狭山市は平成 28 年度に被災者支援システムの導入に合せて住所辞書を作成した。その年の情報整備中に発生した水害では、
この被災者支援システムから出力できる調査票を用いて被災者支援にあたった。
また、
これらのシステムは福祉部門の情報と連携して、平時の防災訓練に活用し、GIS を用いて避難行動要支援者の居所と人数を把握することができるようになった。また狭山市
独自の評価点方式を用い、単身高齢者など共助の届きにくい避難行動要支援者を抽出できるような工夫も行われている。

図３－５ 危機管理システムの例（狭山市：被災者支援システム）14

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

図３－６ 福祉部門と共有して作成した避難行動要支援者の評点方式（狭山市）

奈良県平群町では、被災者支援システム・避難行動要支援者支援システムを導入して被災者支援
活動の迅速化を実施している。平群町では町役場職員が全人口約 2 万人（約 7900 世帯）の住所辞書を自力で作成した。
整備の着手段階ではそれまで保有していた住民の位置情報に不明なものが残っていたことから、福祉部門はそれを懸念としてシステムの利用に消極的であった。その後、住所辞書の整備を政策推進課において整備したことで、福祉部門においてシステムの利用や他の業務での活用に積極的な動きがでてきている。

15

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

3.2.2. 浸水想定区域の住民把握
住民地図の作成は、災害のシミュレーションに合わせた被害想定の把握に用いることができる。
例えば、浸水想定区域図は河川の氾濫のシミュレーションであるが、氾濫が想定される区域に居住する住民の人数や属性を把握できると対策に必要な物資、人員、行動の想定が可能になる。
会津若松市では住民地図を用い、浸水想定区域図から被災可能性のある住民を把握して、避難訓練に活用した。

新 浸水想定区域図
48 時間総雨量 533mm

浸水深 2.0m 以上の住民ポイント
該当者 15028 人

図 ３－７ 防災訓練での住民地図の利用（会津若松市）

16

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

4. GIS 共通サービスの導入・運用
GIS 共通サービスの導入に際し、「住民地図」を実現しその効果を生み出すために、以下の３つがポイントとなる。
① 地名辞典（住所辞書）の整備
住所情報などにその位置（座標）を付与し、「地名辞典」として整備し、整備・維持・利用を組織的に運営することにより業務連携の効果を期待できる。
② 業務分析・利活用シーンの想定導入にあたっては、業務分析を実施し、自治体の実情に即した利活用シーンを想定・検討することで、より一層の効果が期待できる。
③ GIS ユニットの導入
GIS ユニット製品を導入し、既存の業務アプリケーションに「GIS 共通サービス
利用機能」を実装するだけで、位置情報との連携が可能となる。

特に、「地名辞典（住所辞書）」の整備は、業務情報の地図上への「見える化」に必須であるため、本書の第 5 章で詳細に説明する。

17

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

4.1. GIS 共通サービスの導入パターン
4.1.1. 導入タイミング
GIS ユニット導入に適したタイミングは自治体の状況によって異なる。以下に GIS ユニット導入が想定されるタイミングのパターンを示す。
表 ４－１ GIS 共通サービスの導入タイミング

導入タイミング説明

統 合 型 GIS の 導
入・リプレースに合わせた導入

統合型 GIS の導入・リプレースにあわせて、統合型 GIS の要素の 1 つとして GIS ユニットを導入するパターン。統合型 GIS と自治体の業務情報を連携させたいケースや、将来、他の業務ユニットやアプリケーションに GIS
ユニットのサービスを提供するために導入するケースが考えられる。
業務ユニットやアプリケーションに GIS ユニットを利用するための機能も必要になる。
「地名辞典」を「共用空間データベース」の一つとして位置づけて、庁内の各業務ユニットやアプリケーションから、GIS ユニットを介して共通的に利用できるようにすることが望ましい。「地名辞典」を整備し、統合型
GIS のアプリケーション（全庁で利用される GIS アプリケーション）で、アドレスマッチング機能として提供するだけでも、住民地図の実現には大きな効果がある。

業務ユニットの導入・リプレースに合わせた導入業務ユニットの導入・リプレースにあわせて GIS ユニットを導入するパターン。業務ユニットと地理空間情報を連携させて業務サービスを向上するために導入するケースが考えられる。
業務ユニットに GIS ユニットを利用するための機能も必要になる。
同時に整備・導入する「地名辞典」は、庁内で共通的に利用できる資産となり得る。統合型 GIS が導入済みである場合は、「地名辞典」と「GIS ユニット」を統合型 GIS の要素として追加運用することも有用である。

業務ユニット以外のアプリケーションの導入・リプレースに合わせた導入業務ユニット以外のアプリケーション（例：防災アプリケーション、個別
GIS）の導入・リプレースにあわせて GIS ユニットを導入するパターン。ア
プリケーションと自治体の業務情報や地理空間情報を連携させるために、導入するケースが考えられる。
アプリケーションに GIS ユニットを利用するための機能も必要になる。
同時に整備・導入する「地名辞典」は、庁内で共通的に利用できる資産となり得る。統合型 GIS が導入済みである場合は、「地名辞典」と「GIS ユニット」を統合型 GIS の要素として追加運用することも有用である。

18

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

4.1.2. 地名辞典の整備・更新方法
地名辞典の整備・更新は、GIS 共通サービスの導入・運用にあたって必須であり、整備・更新の方法を定める必要がある。代表的な地名辞典の整備方法を以下に示すが、「住民地図」の実現に際し、住基情報をベースに地名辞典を整備することが重要である。
表 ４－２ 地名辞典の整備・更新方法のパターン

地名辞典の整備・更新方法(A)
住基情報を基準とした地名辞典を整備し、随時更新(B)
住基情報を基準とした地名辞典を整備し、定期更新

説明住民基本台帳等の住民情報をベースに地名辞典を初期整備するパターン。住所の位置に対応する座標は、住居表示台帳図・地番現況図等の既存のデータを活用して付与することを検討する。
住民異動受付や住居表示申請受付等の業務フローやシステムフ
ローを見直す事を前提に、これらの業務にあわせた地名辞典の随時更新対応を検討する。
（A)と同様に住民基本台帳等の住民情報をベースに地名辞典を初期整備するパターン。
あわせて、定期的に地名辞典を更新するために、自治体ごとの実情に即して更新頻度やその更新フローを検討する。年１回～数回程度以上の更新を行うことが望ましい。
既存の住所データ（市販データや無償公開データ）をそのまま地名辞典として利用するパターン。

（C）
既存の住所データをそのま
ま利用

住民情報をベースにした整備方法ではないため地名辞典の信頼性は低くなるが、比較的安価に地名辞典を整備することが可能。
更新の頻度は採用するデータの更新頻度に依存するが、一般的には１年～数年に１回程度となる。

19

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

4.1.3. サービスの方式
地名辞典を利用した GIS 共通サービスを実現するためには、GIS 共通サービスと地名辞典デ
ータがセットアップされた GIS ユニットを稼働させるサーバが必要なる。サービスの実現にあたってはオンプレミス（自治体内に独自のサーバを設置する方式）で実現する方法と、クラウド（LGWAN-ASP 等として LGWAN 上で提供されるサービスを利用する方式）で実現する方法がある。
実現方式は、各自治体の実情に応じて選択する。一般的にオンプレミスで実現すると、サーバ運用に関する自由度は高くなるが、サーバの調達費や、職員によるサーバメンテナンスのための必要な労力は多くなる。一方、クラウドで実現する場合は、サーバ運用に関する自由度は低くなるが、サーバの調達やメンテナンスを職員が直接行う必要がなくなるため、初期整備コ
ストや、運用のための職員の労力を低く抑えることが可能となる。また、クラウド方式で実現するメリットとして、複数の自治体でサーバ・サービスを共同化利用することで、コストを抑える余地がある。
以下に、各実現方式を採用する際のポイント示す。
表 ４－３ GIS 共通サービスの導入方式

サービス導入方式別の留意点・ポイント
地名辞典の整備・更新方法
オンプレミス方式(A)
住基情報を基準とした地名辞典を整備し、随時更新(B)
住基情報を基準とした地名辞典を整備し、定期更新

比較的多くの GIS ユニット製品が準拠登録されている。
住民情報と密接に関わる業務
アプリケーションとの連携も
問題ない。

同上。

クラウド方式（LGWAN-ASP）「GIS 共通サービス」の I/F に対応しているクラウドサービ
ス選択する必要がある。クラウドの形態によっては、住民情報と密接に関わる業務アプリケーションとの連携が難しい場
合がある。

同上。

同上。
同上。
（C)
既存の住所データをそのま
ま利用

定期的な更新データ調達や、更新作業のための保守費用等を見込む必要がある。

20

データ更新もクラウドサービ
ス提供事業側で実施することが基本であり、自治体職員はデータ整備・更新のための労力をゼロにすることが可能。

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

4.1.4. GIS 共通サービスのアプリケーションからの利用パターン
GIS 共通サービスは、「GIS 共通サービス利用機能」を備えた業務ユニットや業務アプリケーションから利用することが可能である。ただし、地理空間情報・地図情報の扱いに特化した統合型 GIS のアプリケーションや、専門的な個別 GIS で「地名辞典」を活用することも有用である。以下に、代表的なアプリケーションからの利用パターンを示す。
表 ４－４ GIS 共通サービスの利用パターン

アプリケーションからの利用パターン説明

当 該業務 の住民 地図

業務ユニット・
業務アプリケーション

業務情報

GIS共通サービス利用機能(1)「GIS 共通サー
ビス利用機能」を備えた業務ユニットや
業務アプリケーショ
ンでの利用

描
画
要
求

座
標

住
所

地
図
画
像

GIS共通サービスインタフェース
地名辞典サービス

地図表示サービス

地名辞典

地図データ

当 該業務 担当部 署の職 員

GISユニット「GIS 共通サービス利用機能」を備えた、業務ユニット・業務アプリケーションから、GIS 共通サービスを呼び出し、業務情報に位置情報（座標情報）を付与した上で、地図画像と重ね合わせて、当該業務に関する住民地図として業務ユ
ニット・業務アプリケーション側で見える化（地図表示）が可能となる。

手 元の業 務情報 の住民 地図

統合型GISアプリケーション（全庁職員利用向けGIS）
利用

GIS共通サービス利用機能

住所検索機能アドレスマッチング機能

住所(2)統合型 GIS アプ
リケーション（全庁
職員利用向け GIS
アプリケーション）
での利用

…
全 庁職員

GIS共通サービスインタフェース
地名辞典サービス

地図表示サービス

地名辞典

地図データ

手元の業務情報を
地名辞典を活用した
アドレスマッチングで
住民地図化
地図重畳

手 元にあ る業務 情報
識別番号

氏名

住所

00001

×山 健一

○ ○町３ －２

00002

△川 裕子

× ×町８ －１…

…

GISユニット

統合型 GIS アプリケーションにあわせて、「GIS ユニット」が導入される場合、「GIS ユニット」の機能が内包されることが想定できる。例えば、全庁の職員が、手元にある業務情報（例えば住所情報を持つ EXCEL ファイル）を、「地名辞典」を活用したアドレスマッチング機能を用いて、「住民地図」として、統合型
GIS アプリケーション上で表示・活用することが可能となる。

21

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

アプリケーションからの利用パターン説明

高 度な施 設管理 や空間 分析と組 み合わ せた住 民地図

個別GIS
利
用
GIS共通サービス利用機能

住所検索機能
分析機能
…機能

住
所

座
標

座標付与
業務情報

(3)個別 GIS での利用

GIS共通サービスインタフェース
地名辞典サービス

地名辞典

GISユニット

空地
間図
解重
析畳

地図データ

当 該業務 担当部 署の職 員

高度な施設管理機能や空間解析機能などを持つ、業務に特化した専門的な
GIS を内包するアプリケーションとして個別 GIS に「GIS 共通サービス利用機能」
を備えている場合、個別 GIS が持つ業務情報に住所に基づいた座標を付与したり、個別 GIS が持つ情報と組み合わせて分析をしたりして、より高度な利用が期待できる。

22

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

4.2. GIS 共通サービス導入に向けた手順
GIS 共通サービスの導入にあたっては、業務プロセス改革や住民サービスの向上を目指し、
地理空間情報を用いた業務改革を実施する心づもりでの導入が重要である。その点では、地域
情報プラットフォームの導入にあたって検討すべきことや、調達（導入）の手順と大きく変わることはない。
ただし、GIS 共通サービスは、住基情報と位置情報を組み合わせて「住民地図」を実現するための汎用的な仕組み・ツールであり、特定の業務を対象とはしていない。そのため、導入の目的を明確にすることと、その目的に応じてどのような地名辞典を整備し、更新運用をしていくかを定めることがポイントになる。また、持続的に広く利用してもらうための庁内組織体制の構築や、継続的な体制の構築もポイントである。
下図に、GIS 共通サービス導入（GIS ユニットの調達）のフローを示す。本フローの詳細は、「GIS ユニット調達の手引き」に記載されているので、参考にされたい。

※

Ｇ
Ｉ
Ｓ
ユ
ニ
ッ
ト
の
調
達
フ
ロ
ー
（
１
）

地
名
辞
典
の
調
達
フ
ロ
ー

(1)
目的の明確化(2)
プロジェクト計画

(1)-1
上位方針

(2)-1
環境分析

(1)-2
業務・シス
テム環境

(2)-2
実行計画

(1)-3
プロジェク
ト方針

(2)-3
ＷＢＳ

(1)
目的の明確化(1)-4.1
利活用分野の検討(1)-4.2
利活用シーン
の検討

(3)
組織の設定

(4)
現状整理・業務改善

(6)
調達方針

(5)
再構築方針

(4)-1
情報システム資産管理

(3)
推進組織
設定
(PMO・作業
部会等)

(4)-2
RFI
(4)-3 業務整理・改善
仕様(4)-3.1
業務
改善

(5)
再構築
(改修)
方針・基
本計画

(4)-3.2
選択1
クラウド・SOA開発

予
算
承
認

(6)-2
評価方針

(6)-3
運用

(4)-3.3
選択2パッケージ選定

(3)
組織の設定
(3)-1
GISユニット導入・運用のための
体制構築

(6)-1
RFP

(4)-4
地名辞典に係る業務整理・改善(4)-4.1
データ仕様の策定(4)-4.2
データ整備方法の策定(4)-4.3
データ整備フローの検討(4)-4.1.1
マッチングレベルの検討(4)-4.2.1
地名辞典整備方法の検討(4)-4.3.1
地名辞典の整備フローの検討(4)-4.2.2
地名辞典に
必要な情報
の収集

(4)-4.3.2
地名辞典の更新フローの検討(4)-4.1.2
住所を識別するキー及び代表点の検討（※１）「地域情報PFを活用した業務改善とシステム調達の手引き」で示されているフローに準じる

図４－１ GIS ユニット調達のフロー

23(4)-4.4
サービス実現方式の検討(4)-4.4.1
サービス
実現方式
の検討

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

4.3. GIS 共通サービスの運用
GIS 共通サービスは、各業務ユニットや業務アプリケーションから利用される汎用的なサービスであるため、運用にあたっては特に以下の事項の留意する必要がある。
・ 地名辞典の精度や更新頻度等の周知
整備した地名辞典の精度や更新頻度などを、利用者（利用側の業務ユニットや業務ア
プリケーション）に適切に周知し、利用目的と齟齬が出ないようにする。
・ バージョンアップ時の互換性の確保「GIS 共通サービス標準仕様」は、その性質を鑑みて、後方互換を考慮した標準仕様の更新を行っているが、それでも、インタフェースの拡張・変更が発生し、後方互換が維持できない場合もある。運用中の地域情報プラットフォーム準拠の各システムの準拠
バージョンは統一されていることを確認するとともに、バージョンアップのタイミングについては利用者（利用側の業務ユニットや業務アプリケーション）と十分な調整を行う。
・ データ資産の継続的運用
地名辞典は、自治体にとって貴重な資産であるため、システムリプレース等により GIS
ユニットを差し替えた場合であっても、新たに地名辞典を整備することなく、差し替え
前の地名辞典を容易に移行することが有用である。「GIS 共通サービス標準仕様」では、データ交換用のフォーマット（スキーマ）を規定しており、かつ、GIS ユニットにデー
タ交換用のフォーマットでデータをインポート・エクスポートできることを求めている。
システムリプレース時のデータ資産の移行には、この規定や機能の活用を考慮する。

24

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

5. 地名辞典の整備・運用
5.1. 地名辞典の目的
地名辞典とは、住所情報などの地理識別子と地理座標の関係を複数格納した“辞書”である。
地名辞典の目的は、業務 DB1 が持つ「位置を表す情報（住所情報など）」を地理座標に変換することである。これにより簡単に業務データ2 を GIS で活用することができる。

5.1.1. 地名辞典を有効活用した住民地図の作成について
地名辞典の活用として住民地図の作成がある。住民地図は地域課題を行政が客観的な情報に基づいて取り組む上で有用なツールである。地域課題に対する取り組みのうち、避難行動支援
や子育て支援などのように、住民ひとりひとりに対するきめ細やかな行政サービスの実現のためには、住民ひとりひとりが住んでいる位置を正確に把握することが必要不可欠となる。それには、確実に住民の居所を把握することが重要であり、住民基本台帳の住所に対応する位置情報の付与、すなわち地名辞典（住所辞書）の整備が促進されている。
自治体業務システムの見直しや最適化が予定される自治体においては、住民基本台帳の住所をもとに地名辞典を整備し、GIS 共通サービスを導入することで、きめ細やかな住民サービスの向上に役立つものとなる。

図 ５-１ 地名辞典（住所辞書）作成に用いるデータの例

1本書では、GIS ユニットを除く業務ユニット内の DB のことを業務 DB と呼ぶ。
2本書では、GIS ユニットを除く業務ユニット内の DB で管理されるデータを業務データと呼ぶ。

25

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

5.2. 自治体における地名辞典の歴史と重要性
5.2.1. 地名辞典の歴史
GIS は 1950 年代から米国の軍事技術やカナダの森林資源管理を目的とした科学技術研究を中心とした場面で利用されてきていた。その後、日本国内においても都市情報の把握の場面など、行政業務に活用する場面が登場した経緯がある。
1984 年、西宮市3では業務で使える GIS となる「総合住民情報システムと連携する西宮市位
置座標方式」の開発を行った。この時の開発コンセプトには、庁内のあらゆる業務に利用可能
な「宛名データベース」住所辞書の考え方があった。
阪神・淡路大震災以降、西宮市では「宛名データベース」を利用した被災者支援システムを迅速に立ち上げ、その後の災害応急に活用し全国から注目された。この GIS は、西宮市情報センターが運用した被災者支援システムとして全国で活用されている。
また、2007 年 8 月には、地理空間情報活用推進基本法（平成 19 年法律第 63 号）が施行された。APPLIC では、地理空間情報活用推進基本法の施行に伴い、地方公共団体において保有する地理空間情報が GIS を通じて多様な業務に活用されることと考え、地方公共団体での地理
空間情報の活用と普及を促進する活動を始めた。
APPLIC では、技術専門委員会の標準化ワーキングを通じて、住民基本台帳を取り扱う業務ユニットから GIS を扱うための標準ユニットの仕様を定め、GIS ユニットとして全国での普及に取り組んでいる。
現在定めた GIS ユニットの構成には、地方公共団体の活動で培った地名辞典（住所辞書）の考え方を重要視しており、ここには、西宮市で始まった「宛名データベース」のコンセプトが継承されている。

5.2.2. 地名辞典の重要性
地名辞典に相当する「位置に表す情報（住所情報など）」は各業務ユニットに散在している。
また、地方自治体の日常の活動の中で、住所等の情報は各所で保管されて利用される。
複数の部署で利用されている住所情報は、データの更新や情報の維持の方法が異なることか
ら、品質や整備時点がさまざまな状態に置かれることが多い。このような状況は、地方自治体の行政の非効率を招く恐れがあることや、場合によっては複数の部署で用いられる住所が別の位置を示すものとなる「アンマッチ」の原因となる場合も考えられる。
これらを集約し、地理座標を対応づけて、地名辞典を整備・管理することで、業務データを
GIS で効率的に活用することが可能となる。図５－２は、庁内に散在する住所情報を GIS ユニ
ットの地名辞典に集約するイメージである。

3 （西宮市に関する記載の出典：地方公共団体向け地理空間情報に関する Web ガイドブック

http://www.mlit.go.jp/kokudoseisaku/gis/gis/webguide/）26

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

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

Ａ

Ｂ

Ｃ

GIS
ユニット
…

業務ＤＢ

住所情報

業務ＤＢ

業務ＤＢ

住所情報

住所情報

住所情報

地理座標

○○町1丁目1-1 （35.876，139.988）○○町2丁目2-2 （35.111，139.222）

GISDB

：

：

住所情報

図 ５-２ 住所情報の散在と集約

GIS ユニットの地名辞典は、地域情報プラットフォームで規定されている業務データが地理座標に変換できることを基本としているが、その他のデータ（例えば、交差点など）を整備することも視野に入れている。
地方自治体では、住民基本台帳の管理を通じて、常に最新の状態の住民の住所情報が存在する。住民基本台帳から得られる地名辞典は、住基情報を扱う地方自治体において多様な活用場面がある。地名辞典を庁内で集約することで、地方自治体での業務情報の整理や新たな情報連携が考えられる。

27

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

5.3. 地名辞典を活用した住民地図の整備
5.3.1. 住民地図と地名辞典
第 3 章では GIS 共通サービスの活用事例として業務情報の見える化を通した地域課題の解決支援の事例を紹介した。
GIS 共通サービスを用いることで住民基本台帳の情報から住民地図が作成できることを説明したが、それは地名辞典が備わっていることで、住所によって示される位置情報を地図の配置へ転換できるからである。
全国の基礎自治体では住民基本台帳を整備している。住民基本台帳に記載された住民の住所の一覧は、その基礎自治体のみが作成できる非常に重要な情報である。
住民サービスの高度な実現や、政策評価、政策立案などあらゆる行政活動で住民の情報は用いられる。住民情報の可視化において、ICT 環境の整備が進んだ現在、自治体が持つ情報をそのまま利用できる環境を是非利用することが望ましい。

図５－３ 会津若松市の住民地図の作成画面

28

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

5.4. 地名辞典の利用目的に合わせた整備レベル
5.4.1. 地名辞典の利用目的と整備レベル
地名辞典（住所辞書）を整備し GIS 共通サービスを導入することで、「住民の安心・安全支
援」、「住民の居住位置把握による行政サービス」、「統計情報の可視化による政策支援」といった効果が期待できる。
利用目的によって、特定すべき位置の細かさや求められる信頼性（精度）が異なるが、きめ細やかな住民サービスの実現や、住民の安心・安全を守るといった観点からは、住民基本台帳
等の住基情報を基準にして精度の高い状態で地名辞典を整備・更新することが重要である。

（１） 地名辞典の利用目的と整備レベル
地名辞典を整備する場合は、利用目的、求められる信頼性、更新頻度、初期整備や更新のコ
ストのバランスを考慮し、各利用団体における最適なバランスがとれるようにすることで、効果的な運用と GIS 活用につながる。
図５－４は、地名辞典を利用する適用例と、その適用例における特定すべき位置の細かさを表したものである。

図５-４ 地名辞典の適用例と特定すべき位置の細かさ

29地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン（２） 特定すべき位置の細かさとマッチングレベル
特定すべき位置の細かさが明確化できると、調達する地名辞典に必要とされるマッチングレ
ベルが決まる。マッチングレベルには、主に「町丁目(字)レベル」、「街区レベル」、「号（番地）レベル」、「建物レベル」の４種類が考えられる。
図５－５は、特定すべき位置の細かさと地名辞典のマッチングレベルの関係を示したものである。
地名辞典の信頼性

高い

位
置特
の定
細す
かべ
き
さ

位

特

細 置
の定
す
か 細
かべ
い さき

粗
い

町丁目・字レベル

街区レベル

低い

号・番地レベル

建物レベル

地名辞典の信頼性

図５－５ 特定すべき位置の細かさと地名辞典のマッチングレベルの関係

30

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

また、それぞれのマッチングレベルについてイメージを図で示す。
町丁目レベル（○○町三丁目）②①

号（番地）レベル(○○町三丁目4番1号)

1

2

⑥
3
建物レベル（○○町三丁目1番4番1号-2)

4

③

④

5

⑤

…

街区レベル（○○町三丁目4番）（注）ここでは建物レベルの住所に枝番を付与しているが、枝番はない場合が多い。

図５－６ マッチングレベルのイメージ
図５－５に示した避難行動要支援者の情報や老朽危険家屋の調査といった安全・危機管理場
面で、住民地図を利用する場合などは、地名辞典に求める細かさは住民や住民世帯が特定できる細かさが必要になる。この場合の地名辞典は、図５－６のマッチングイメージでは、号（番地）レベルや、建物レベルのマッチングレベルが必要になる。
地名辞典の整備レベルについて、整備対象の地域によっては広大な範囲が一件の大字や町丁界、街区となる場合がある。また、小規模な面積の自治体では大字や町丁界が数件に集約されている場合がある。このような場合に地名辞典を大字や街区レベルで整備する意味が乏しく、地名辞典は号（番地）レベルや、建物レベルのマッチングレベルを備えることが望ましい。

31

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン（３） 地名辞典に求められる信頼性
地名辞典に求められる信頼性が明確化できると、調達する地名辞典に適した整備・更新方法が決まる。図５－７は、地名辞典に求められる信頼性と、地名辞典の整備・更新方法の関係を示したものである。
地名辞典の信頼性

住民情報を基準とした地名辞典を整備し、随時更新に対応

高い

住民情報を基準とした地名辞典を整備し、定期的な更新を実施

位
置特
の定
細す
かべ
き
さ

位

特

細 置
の定
す
か 細
かべ
い さき

粗
い

既存の住所データをそのまま利用低い
地名辞典の信頼性

図５－７ 地名辞典の信頼性と地名辞典の整備・更新方法の関係

地名辞典の信頼性は、住民や世帯の所在である住所のデータベースの網羅率である。自治体
では住民の住家の新築や宅地造成などで住所が新規に生じており、これらの変化に地名辞典を整合していくことで信頼性を高めることができる。

32

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン（４） 地名辞典の整備レベルとコスト
地名辞典を利用した GIS 共通サービスの実現方法として、第 4 章で GIS 共通サービスの導入パターンを紹介し、その中で、地名時点の整備・更新の方法として以下の 3 パターンを例示した。
（A）住基情報を基準とした地名辞典を整備し、随時更新

住民基本台帳等の住民情報をベースに地名辞典を初期整備する。住所の位置に対応する
座標は、住居表示台帳図・地番現況図等の既存のデータを活用して付与することを検討する。住民異動受付や住居表示申請受付等の業務フローやシステムフローを見直す事を前提に、業務にあわせた地名辞典の随時更新対応を検討する。
（B）住基情報を基準とした地名辞典を整備し、定期更新（A)と同様に住民基本台帳等の住民情報をベースに地名辞典を初期整備する。あわせて、
定期的に地名辞典を更新するために、自治体ごとの実情に即して更新頻度やその更新フローを検討する。年１回～数回程度以上の更新を行うことが望まれる。
（C）既存の住所データをそのまま利用
既存の住所データをそのまま地名辞典として利用する方法。住民情報をベースにした整備方法ではないため地名辞典の信頼性は低くなるが、比較的安価に地名辞典を整備することが可能である。
更新の頻度は採用するデータの更新頻度に依存するが、一般的には１年～数年に１回程度となる。
上記のパターンごとに地名辞典の整備・更新に係る頻度やコストが異なる。
図５－８は、地名辞典の整備・更新の方法について、利用目的に応じた信頼性や更新頻度、コストについての関係を示したものである。

図５-８ 地名辞典の利用目的と整備・更新方法

33

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

5.5. 地名辞典の要件
GIS 共通サービス標準仕様において、地名辞典の要件として以下が規定されている。これらの要件は、地域情報プラットフォームの GIS ユニットにおける地名辞典として、必ず満たさな
くてはならないものである。本節では地名辞典の要件について簡単に説明する。
・ GISDB 内の地理空間データは、異なる GIS ユニット間で交換できる必要があり、GIS
ユニットには、交換用地理空間データエクスポート機能及び交換用地理空間データイ
ンポート機能を実装しなくてはならない。
・ 地名辞典の実装方式や内部形式は仕様では規定しないが、GIS 共通サービスインタフ
ェースで規定されるインタフェース定義に準拠したデータ交換ができるように、GIS
共通サービス標準仕様で定義されるデータを、利用側の業務ユニットに対して提供できなければならない。（GIS 共通サービスインタフェースに準拠した地名辞典）
・ 地名辞典は、「住所情報」や「所在地情報」、「目標物」などの地理識別子の種類ごとに、蓄積・管理できる必要がある。すなわち、GISDB では、論理的に複数の地名辞典を保持することができなければならない。また、住所情報地名辞典を必須で保持しなくてはならない。

5.5.1. 交換可能な地名辞典
地名辞典は、自治体にとって貴重な資産であるため、GIS ユニットを差し替えた場合であっても、新たに地名辞典を整備することなく、差し替え前の地名辞典を容易に移行することが有用である。
地名辞典の実装方式は規定しないが、交換用のデータスキーマは GIS 共通サービス標準仕様
で規定している。
ＧＩＳユニット（Ａ社製）

ＧＩＳＤＢ

地名辞典
住所情報

地理座標

○○町1丁目1-1 （35.876，139.988）

ＧＩＳユニット（Ｂ社製）
Ｇ
イＩ
ンＳ
タ共
フ通
ェサ
ーー
スビ
ス

GISユニット
を差し替え

地名辞典
住所情報

地理座標

○○町1丁目1-1 （35.876，139.988）○○町2丁目2-2 （35.111，139.222）
：

ＧＩＳＤＢ

○○町2丁目2-2 （35.111，139.222）

：

：

：

地名辞典（交換用）
住所情報

エクスポート

地理座標○○町1丁目1-1 （35.876，139.988）○○町2丁目2-2 （35.111，139.222）：：

図 ５-９ 地名辞典の交換のイメージ

34

インポート

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

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

5.5.2. GIS 共通サービスインタフェースに準拠した地名辞典
自治体内で業務ユニットから地名辞典を利用する場合はもちろん、広域連携において他の自治体が整備した地名辞典を相互利用するためには、標準インタフェースを実装し、共用可能なサービスとして公開することが求められる。GIS 共通サービス標準仕様は、この標準インタフ
ェースを GIS 共通サービスインタフェースとして規定している。
地名辞典については、内部構造や実装形式は規定しないが、この GIS 共通サービスインタフ
ェースに準拠したデータ構造でデータ交換ができることを規定している。
GISユニット（B市）
GISユニット（B市）

B市○○町2丁目2-2？

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

業務ユニット（Ａ市）
業務ユニット（Ａ市）

ＧＩＳＤＢ

地名辞典
住所情報

地理座標

○○町1丁目-1-1（35.876，139.988）○○町2丁目-2-2（35.111，139.222）（35.111，139.222）

GISユニット（C市）
GISユニット（C市）

業務DB
C市××町2丁目2-2？

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

（36.444，138.666）

GISDB

地名辞典
住所情報

地理座標

× ×町1丁目-1-1（36.345，138.678）

× ×町2丁目-2-2（36.444，138.666）

図 ５-１０ 地名辞典の広域連携のイメージ

35

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

5.5.3. 複数の地名辞典
GIS 共通サービス標準仕様において、GISDB は複数の地名辞典を保持できるよう規定されている。例えば、以下のように「住所情報地名辞典」、「目標物地名辞典」などを持つことができる。どのような地名辞典を持つかは自治体ごとに決めることができるが、「住所情報地名辞典」は必ず作成するものと規定されている。具体的な地名辞典の構築方法は、「5.7 地名辞典の整備手法」で示す。

GISDB
地名辞典

住所情報地名辞典
地理識別子○○町一丁目2番1号○○町一丁目2番2号○○町一丁目2番3号…

目標物地名辞典

地理座標（35.123, 135.123）（35.456, 135.456）（35.789, 135.789）
…

…
…
…
…
…

住民の居所

地理識別子
○○公民館
××小学校
△△市役所
…

地理座標
（36.111, 136.111）（36.222, 136.222）（36.333, 136.333）
…

…
…
…
…
…

住民の居所以外（施設名称、交差点
名、自然地名等）

図 ５-１１ 複数の地名辞典のイメージ

36

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

5.6. 地名辞典の運用の考え方
地名辞典の要件は前述のとおりであるが、本節では、自治体が実際に地名辞典を構築・運用するにあたり、必要となる考え方や具体的な方法例について示す。ここでの内容は、仕様として規定するものではなく、自治体の実情に合せて工夫し定めるための参考とされたい。

5.6.1. 地名辞典の運用の基本的な考え方
地名辞典を運用するにあたり必要となる基本的な考え方を以下に示す。ここで示す考え方は、
本ガイドラインにおける地名辞典の作成方法や、実際の初期構築と運用更新を理解する上で重要なものである。

（１） 地名辞典で扱う地理識別子について
地名辞典で扱う地理識別子は、その基となるデータによって大きく２つに分類される。一つは「地域情報プラットフォームにおいて規定されている業務データ」を地理識別子の基データとする場合であり、もう一つは、その他のデータを地理識別子の基データとする場合である。

ア） 地域情報プラットフォームにおいて規定されている業務データ
地域情報プラットフォームにおいて、各業務ユニットが管理するデータは、「自治体業務 AP
ユニット標準仕様」の「（業務 1-8）データ一覧」で規定されており、業務ユニット間インタフ
ェースを用いて、これらの業務データを交換できることが定められている。
GIS ユニットの大きな役割は、これら業務データを簡単に GIS で活用できるようにすることである。よって、地名辞典で使用する地理識別子は、業務 DB が持つ「位置を表す情報（住所情報など）」を利用する必要がある。
例えば、介護保険ユニットの業務データを地理座標に変換するためには、地名辞典は、介護保険 DB における「位置を表す情報（住所情報など）」を地理識別子とする。
介護保険ユニット

GISユニット○○町2丁目2-2の地理座標は？

介護保険ＤＢ・・・

被保険者情報・・・

・・・○○町1丁目-1-1

・・・

・・・

○○町2丁目-2-2

・・・（35.111，139.222）

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

GISDB

地名辞典
地理識別子

地理座標

○○町1丁目-1-1（35.876，139.988）○○町2丁目-2-2（35.111，139.222）

対応

図 ５-１２ 地理識別子と業務データ

イ） その他のデータ
地域情報プラットフォームにおいて特に規定されていないデータを、地名辞典の地理識別子として扱うことも可能である。例えば、交差点の情報は地域情報プラットフォームにおいて特に規定されていないが、自治体において、交差点の名称を地理座標に変換したいというニーズがあれば、地理識別子として交差点の名称を整備することで、業務に役立てることができる。

37

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドラインウ） 地理識別子の表記の問題について一般的に住所情報については、表記方法が複数ある場合があり、また表記にゆらぎが存在するという“表記の問題”がある。

住所情報の“表記の問題”について
・同じ住所等を表すのに略称、通称、過去の名称等の間違ではない複数の表記があり得る。
・表記の仕方においてゆらぎが避けられない。
【住所表記のゆらぎの例】
東京都千代田区九段北一丁目二番地三号○○ビル 5 階
東京都千代田区九段北１丁目２番地３号○○ビル 5 階
東京都千代田区九段北 1-2-3○○ビル 5F
東京都千代田区九段北１－２－３－５Ｆ
東京都千代田区九段北一ノ二ノ三○○ビル五階【住所表記のゆらぎのパターン】
・詳細地名の省略
丁目や番地、番、号などの省略や、ハイフンや「ノ」等で略記される。
・アラビア数字による代用
丁目などの漢数字がアラビア数字により代用される。
・異体字の使用
常用漢字にない漢字が地名に用いられている場合に、よく似た漢字で代用される。
・小文字の省略・追加「が」「ヶ」「ケ」「ャ」「ヤ」「ツ」「ッ」は、それぞれ混合して使用あるいは省略
する、場合によっては余分に追加されることがある。

地域情報プラットフォームにおける業務データにおいても“表記の問題”が存在する。また、
地域情報プラットフォームにおいて住所情報は複数の業務ユニットで管理されているため、業
務ユニットのそれぞれが、住所情報の“表記の問題”を抱えている可能性が高い。
地名辞典は、業務データの住所情報について、“表記の問題”に対応し、確実に地理座標に変換できることが重要である。しかし、地名辞典では、業務データにおける住所情報について、正誤はもちろん、“表記の問題”の対応方法について、完全には判断できない。また、地名辞典が独自に“表記の問題”を解釈した場合、その解釈次第で期待しない地理座標になってしまう。
そこで、地名辞典は、業務データにおける住所情報の“表記の問題”に関与せず、業務デー
タで表現されている住所情報を正として取り扱うことを推奨する。

38

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン<<表記のゆらぎに対応する際の留意点>>
座標情報の元となる情報と住所情報の元となる情報をマッチさせて地名辞典を構築する際には、住所の文字列でマッチングさせる方法と、住所コードでマッチングさせる場合が考えられる。住所文字列でマッチングさせる際には、以下に示すような住所表記のゆらぎに留意する必要がある。
※住所表記のゆらぎの例
・詳細地名の省略
丁目や番地、番、号などの省略や、ハイフンや「ノ」等で略記される。
・アラビア数字による代用
丁目などの漢数字がアラビア数字により代用される。
・異体字の使用
常用漢字にない漢字が地名に用いられている場合に、よく似た漢字で代用される。
・小文字の省略・追加「が」「ヶ」「ケ」「ャ」「ヤ」「ツ」「ッ」は、それぞれ混合して使用あるいは、省略、場合によっては余分に追加されることがある。
これらの表記のゆらぎに注意しながら住所文字列を利用してマッチングをさせる方法もあるが、予想していない表記のゆらぎが存在する可能性もある。そのため、住所コードを利用してマッチングするほうが、結果的に良いマッチング結果を得られる可能性がある。その場合、「住所情報へ付与する座標情報を作成するために候補となる情報」には、住民基本台帳等の住所情報に付与されている住所コードは付与されていないことが一般的であり、コード変換等を行いながら住所コードを付与した上でマッチング作業を実施することになる。どのようにマッチングを実施するかは、利用するデータの特性を踏まえて、結果的にマッチングする件数が多くなるような手法を選択することが重要である。
<<マンション名等の方書の扱い >>住民基本台帳等の住所情報にはマンション名や部屋番号等の方書情報が含まれているが、多くの場
合、「住所情報へ付与する座標情報を作成するために候補となる情報」には方書情報は含まれていない。そのため、住所文字列でそのままマッチング処理を実施してしまうと、多くの情報がアンマッチとなってしまう。より多くの情報がマッチするようにするためには、事前に住所情報から方書に関する情報を削除した上でマッチング処理を実施することが重要になる。

39

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

5.6.2. 地名辞典の種類と地理識別子（１） 地名辞典の種類について「5.5.3.複数の地名辞典」で述べたように、GIS 共通サービス標準仕様は、GISDB において複数の地名辞典を保持できるように規定している。また「住所情報地名辞典」は必須としている。
GISDB の地名辞典は、地理識別子の種類ごとに地名辞典を作成する。「住所情報地名辞典」の他に、地域情報プラットフォームで規定された業務データを基にして整備できる地名辞典として「識別番号地名辞典」が挙げられる。その他のデータを基として整備できるものとして、
例えば、「目標物地名辞典」「交差点地名辞典」「距離標地名辞典」などがある。
複数の地名辞典について「○○町二丁目」という地理識別子があった場合、これは住所を示すものか、交差点を示す
ものか、その意図は地名辞典の利用者にしか知りえない。また、応答すべき地理座標が異なってくるため、地名辞典において、「○○町二丁目」に対応する地理座標を２つ用意する必要がある。このような場合は、「住所情報地名辞典」と「交差点地名辞典」の２つの地名辞典を作成する。また、地名辞典の利用者は、その意図に合せてこの２つ地名辞典を使い分ける必要がある。

（２） 地名辞典の地理識別子について「住所情報地名辞典」「識別番号地名辞典」については、業務 DB が持つ「位置を表す情報（住所情報など）」4をそのまま地理識別子とする。
各地名辞典で整備するべき地理識別子について以下に説明する。

ア） 住所情報地名辞典の地理識別子
業務データのうち次のものを「住所情報地名辞典」の地理識別子とする。
⚫

データ型が住所情報であるデータ

そのうち、次に示す３つの住所情報を、「住所情報地名辞典」の地理識別子を整備する時の基礎データとする。
⚫

住民基本台帳ユニットにおける、住基情報の現住所情報⚫

住登外管理ユニットにおける、住登外情報の住所⚫

住登外管理ユニットにおける、住登外情報の法人情報理由としては、３つの住所情報は識別番号と密接に関連しており、３つの住所情報を地名辞典に整備することで、各業務ユニットで管理されている識別番号から地理座標を求めることが、担保されるからである。

業務 DB が持つ「位置を表す情報（住所情報など）」について、具体的に「付録４ 業務 DB が持つ「位置を表す情報（住所情報など）一覧」に一覧表で示す。これは、地域情報プラットフォームで規定されている「自治体業務 AP ユニット標準仕様」の「（業
務 1-8）データ一覧」について、抽出したものである。
440

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドラインイ） 識別番号地名辞典の地理識別子
業務データのうち次のものを「識別番号地名辞典」の地理識別子とする。

⚫

識別番号を示すデータ

自治体では住民に関連するデータを主に扱うため、識別番号は重要なデータと位置づけられる。識別番号には住民基本台帳と関連して利用されている庁内の基幹システムが用いる ID 番号
や世帯を示す番号などがある。地名辞典によって識別番号から地理座標が取得できることが重要である。

ウ） その他の地名辞典の地理識別子
上記ア）イ）以外の地理識別子を地名辞典に整備してもよい。以下に地理識別子の例を示す。
「目標物地名辞典」の地理識別子•○○市役所、○○駅、○○公園、○○病院、・・・「交差点地名辞典」の地理識別子•○○町一丁目、○○前、○○入口、・・・「距離表地名辞典」の地理識別子•

国道○号○○キロ、県道○号○○キロ、○○川○○キロ、・・・

これらの地名辞典で整備する地理識別子については、自治体のニーズに合せて設定できるも
のとする。

41

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

5.7. 地名辞典の整備手法
5.7.1. 地名辞典整備の資料の準備（１） 地名辞典に必要な情報の収集
地名辞典の整備・更新方法に何を選択するかによって、地名辞典整備のために必要な情報が異なる。地名辞典整備に必要な情報の有無等を確認し、収集し、必要に応じて調達時の条件とする。

ア） 地名辞典整備に必要な情報
地名辞典の整備・更新方法が、「既存の住所データをそのまま利用」の場合は、既存の住所データを用意すれば地名辞典を整備可能であるが、それ以外の整備・更新方法の場合は、住所を識別するキー情報を作成するために必要な情報と、座標情報を作成するために必要な情報を組みあわせて地名辞典を整備する。
下図に自治体の住所情報になりうる地点における住所を識別するキー情報と座標情報との関係の概念図を示す。

住所を識別するキー情報を作成するために必要な情報

座標情報を作成するために必要な情報

・位置参照情報(街区レベル)が指し示す地点
・電子国土基本図(地名情報)「住居表示住所」が指し示す地点
・住居表示台帳上で指し示す地点)※例：官有地、道路、河川等

住 5
所
候住
補居
情表
報示
の実
あ施
る地
地区
点の

(

(6)無番地)(3)上の(1) 、(2)の住所情報が指し示す地
点には含まれない地点※例：空き家、駐車場、公園、公共施設+(2)住登外情報の住所が指し示す地点

住 4
居
表住
示所
実候
施補
地情
区報
の
住あ
る
居地
表点
示
未
実
施
地
区
)

(1)住民基本台帳の住所が指し示す地点

(
(

自
治
体
の
住
所
情
報
に
な
り
う
る
全
地
点

・地番・家屋現況図が指し示す地点
・民間会社が販売する住所データが指し示す地点(7)無番地図５－１３ 住所を識別するキー情報と座標の関係の概念図

42

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドラインイ） 地名辞典に利用する住所を識別するキーの情報を作成するために必要な情報「地名辞典に利用する住所を識別するキーの情報を作成するために必要な情報」の候補を下表に示す。(A)、(B)の方法では、基本的に、住民基本台帳および住登外情報から住所を識別する
キーを作成する。(C)の方法では、整備する地名辞典のマッチングレベルに応じた既存の住所データを入手・購入することが必要になる。
表５－１ 住所の識別用のキーとして候補となる情報

地名辞典の整備・更新方法

住所を識別するキーの情報を作成するために候補となる情報(A) 住基情報を基準とした地
名辞典を整備し、随時更新⚫ 住民基本台帳（住民基本台帳ユニット）の住所情報(B) 住基情報を基準とした地
名辞典の整備し、定期更新※上記住所情報が指し示す地点には含まれない地点に関して
は、「住所情報へ付与する座標情報を作成するために必要な情報」の中の住所を識別するキーを活用して作成。

(C) 既存の住所データをそのまま利用⚫ 消防局などの庁内機関で従来用いられていた住所録情報⚫ 国土交通省国土政策局「位置参照情報」⚫ 国土地理院「電子国土基本図（地名情報）住居表示住所」⚫ 民間会社が販売する住所データ⚫ 住登外情報（住登外ユニット）の住所情報

ウ） 住所情報へ付与する座標情報を作成するために必要な情報「住所情報へ付与する座標情報を作成するために必要な情報」の候補を下表に示す。
地名辞典の整備・更新方法の種類にかかわらず、整備する地名辞典のマッチングレベルに応じて必要になるデータ等を入手する。
住居表示台帳図や地番・家屋現況図等は自治体が保有する情報であるが、部門間で調整し、利用条件や情報の授受体制等を確立させる必要がある。
これらの情報が電子化されている場合は、座標情報を作成する際のコストを抑えることができる。
また、住居表示実施地区の場合は、自治体の住居表示台帳図から作成された電子化された情報であり、初期整備には有効に活用できる。
民間会社が販売する住所データを購入し、地名辞典を整備するために活用することも考えられるが、二次的なデータベースを作成することは禁止していることもあるため、ライセンスや利用条件について十分に留意する必要がある。

43

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

表５－２ 座標の付与に候補となる情報

地名辞典の整備・更新方法(A) 住 基 情 報 を 基 準とした地名辞典を整備し、随時更新(B) 住 基 情 報 を 基 準とした地名辞典の整備
し、定期更新(C) 既 存 の 住 所 デ ー
タをそのまま利用

住所情報へ付与する座標情報を作成するために候補となる情報
住居表示実施地区⚫ 住居表示台帳図（電子化されているものが望ましい）⚫ 国土地理院「電子国土基本図（地名情報）住居表示住所」

住居表示未実施地区 住居表示実施関係なし⚫ 地番・家屋現況図⚫ 消防局などの庁内機（電子化されてい関で従来用いられてるものが望ましい）
いた住所録情報⚫ 建築確認調書（同上）⚫ 国土交通省国土政策局「位置参照情報」⚫ 民間会社が販売する
住所データ

5.7.2. 地名辞典における位置情報の持ち方（１） 地名辞典に備える位置情報
地名辞典には、地理識別子と地理座標のほかに様々なデータを格納することができる。以下に、場所インスタンスが持つことができるデータの項目を示す。
• 地理識別子と空間参照系の組• 場所型名称• 代替地理識別子（地理識別子の別名）• 地理範囲• 位置（代表点の座標）• 管理者（場所インスタンスの特質を定義する責任がある組織の名前）• 時間範囲これらのデータは自治体の運用にあわせて管理することになる。“位置”と“地理範囲”については後述する。
表 ５-３ 地名辞典に備えるその他の住所情報のイメージ
地理識別子と空間参照系 地理識別子： 東京都千代田区九段北１－２－３の組
空間参照系： ＡＰＰＬＩＣの住所情報
場所型名称
代替地理識別子
地理範囲
位置（代表点の座標）
管理者
時間範囲

住所情報型
とうきょうとちよだくくだんきたいっちょうめにばんちさんごう―（35.123 , 135.123）○○課○○氏19XX 年 X 月 X 日から現在

44

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン（２） 地理識別子に付与する位置情報の具体的な取得位置
次に、地理識別子に付与する位置情報について説明する。位置情報は、上記の“位置”と“地理範囲”が対応する。
地名辞典の地理識別子に付与する位置情報の、具体的な取得位置の推奨事項を示す。
広域連携も想定するため、位置情報の取得位置は一貫性があることが望ましい。

④
③

⑤
⑥

②
⑦
①

凡例
建物の位置

⑧

⑫

土地の位置
フロンテージ境界

図 ５－１４ 地理識別子の種類と位置情報のイメージ

ア） 住所情報
住所情報が示す位置情報は、住民の位置を示すデータとして利用することが多く考えられる
ため、建物の位置（代表点）とする。
また、地理識別子と地理座標が１対１の関係にない場合は以下のように対応することを推奨する。
●複数の建物が同じ住所情報で表される場合（１：Ｎ）
母屋と離れのような場合は、母屋の建物の代表点とする。
住所情報の方書が不十分である場合など、建物の候補が複数ある場合、複数の建物の代表点とする。このとき地名辞典の精度が悪くなることに注意が必要である。
●複数の住所情報が同じ建物を表す場合（Ｎ：１）
集合住宅や二世帯住宅の場合など、複数の住所情報が同じ建物を表す場合、一つの建物の代表点に複数のポイントを置くものとする。

45

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン（参考）
図５－１５は、同一の住所に複数の建物（座標）が付与される場合のイメージを示したものである。宅地の細分化が行われる際に、元の住所を同一とする複数の建物が建てられる場合がある。この時に、住居表示や地番が同一のままで更新手続きが行われると同一住所で複数建物の世帯が発生する。

面積の広い宅地が分割されてミニ開発が入ったが、住居表示のフロンテージが同じであったため同一住所となってしまった場合

敷地の広い宅地に、家族用（子供世帯など）の新築住宅が建った場
合（地番地区で起きやすい）（住居表示地区で起きやすい）

図５－１５ 同一住所に複数の座標が付与される場合（１：Ｎ）

46

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドラインイ） 識別番号
識別番号は、個人を特定する番号である。識別番号に対応する個人の位置情報は、住所から特定される建物の位置（代表点）とする。
識別番号を用いて作成した地名辞典は、その件数が住民の数と一致する。
なお、直接的に住民の識別番号を GIS の操作で扱う場面は比較的限られる。地名辞典として日常的な利用を全庁的に行う場合は、住民の居所となる住所情報が地名辞典として利用できる。
この場合、一件の住所につき住民（世帯構成人数分）の数だけの検索結果が応答することとなる。その他、識別番号を地名辞典として用いる場合のメリットと留意点を示す。
＜識別番号を地名辞典に用いるメリット＞
・住民の位置を居所に相当する建物の位置で代表でき、住民の分布を把握しやすい。
・住民一人と 1 ポイントが対応するため、区割り地図（7.2 節参照）等による集計作業等を
GIS の機能で容易に行える。
・住民福祉などの名簿情報などを扱う分析や集計を住所を介さず直接に識別番号で連携した資料を作成できる。
・同一住所に複数の居所・世帯がある場合（図５－１５参考）に世帯別の配置を確実に把握
できる。
＜留意点＞
・可視化の際には、同一家屋、集合住宅にある住民ポイントが 1 か所に多数の点が生じることに留意する必要がある。
・住民の属性を直接に表示できるため、情報の取り扱い担当者や運用時のルールなどの庁内手続きを厳密に行う必要がある。

図５－１６ 住民の識別番号に対応した住民地図の例
会津若松市のサンプル資料を引用（各ポイントには、識別番号と住所及び座標が関連付
けられる）

47

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン（３） 地理識別子への位置情報を付与する形状
地理識別子には、それに対応する位置情報を付与しなければならない。地理識別子への位置情報の付与は、“位置”または“地理範囲”の２種類の方法がある。
前述のように、住所情報・識別番号については、“位置”の項目に位置情報を付与することを推奨する。ここでは、“地理範囲”として位置情報を付与する方法については参考として説明する。

ア） “位置”として位置情報を付与する方法
地理識別子の位置情報を、“位置”として付与する場合、地理識別子の位置情報を代表点 1点で表す。この場合、代表点 1 点で位置情報を付与できるため、“地理範囲”として付与する
場合に比べて位置情報の付与作業は容易である。しかし、地理識別子を 1 点で表すために、逆にその地理識別子の位置が分かりづらくなる場合がある。例えば、河川名や道路の路線名など
を地理識別子として地名辞典を整備した場合、対応する位置は比較的広い“領域”になるため、
代表点 1 点では、必ずしも対応する位置を十分に示しているとはいえない。つまり、整備する
地名辞典の利用目的に応じて位置情報を付与することが重要である。
表 ５-４ “位置（代表点の座標）”として位置情報を付与する方法

地理識別子

説明

実際の範囲に対して、代表点 1 点で与える。

長所及び短所

長所・作成が容易である。

短所

・1 点で表現するため、表示範囲や検索範囲の設定が別途必要となる。
・実際の範囲が広い場合は一部しか示せない。

イ） “地理範囲”として位置情報を付与する方法
地理識別子の位置情報を、“地理範囲”として付与する場合、さらに“地理範囲の境界をボックスで記述する場合”と“地理範囲の境界を多角形で表す場合”に分けられる。
（イ－１）地理範囲の境界をボックスで記述する場合“地理範囲の境界をボックスで記述する”とは、東西南北に直行した四角形で範囲を示すことをいう。この場合は、さらに範囲を緯度経度を用いて示す方法と、境界を座標値を用いて示す方法とがある。

48

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

表 ５-５ 地理範囲の境界をボックスで記述する場合

地理識別子

説明

実際の範囲に対して、東西南北に直交した矩形で与える。

長所及び短所

長所
短所

・作成が比較的容易である。
・表示範囲や検索範囲の設定が容易である。
・狭長物の場合は不当に広い範囲を示すことがある。

（イ－２）地理範囲の境界を多角形で表す場合“地理範囲の境界を多角形で表す”とは、地理識別子の範囲を、多角形を作成することで範囲を示すことをいう。データ作成の作業が煩雑になることが考えられる。
表 ５-６ 地理範囲の境界を多角形で表す場合

地理識別子

説明

実際の範囲に対して、境界多角形で与える。

長所及び短所

長所
短所

・表示や検索等の利用性が向上する。
・詳細な範囲を示すことができる。
・点が多いと作成が複雑で困難となる。

（４） 地理識別子への位置情報を付与する座標参照系
地理座標の座標参照系は、特に規定されておらず、自治体ごとに採用する座標参照系を定めてよいとされている。ここでは、より一般的な座標参照系である測地座標系（緯度経度座標）
もしくは平面直角座標系を採用することを推奨する。また、測地の基準となる測地系には、日
本測地系 2011（世界測地系）を採用することを推奨する。
さらに、地名辞典と地図データは同じ座標参照系であることが望ましい。

49

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

5.7.3. 地名辞典の初期構築（１） 推奨手順
地名辞典を初期構築する際の手順は、以下を推奨する。
① 各業務ユニットの業務 DB において地理識別子とするデータを決定する。このとき、住所情報は「住民基本台帳ユニットにおける住基情報の現住所情報」、「住登外管理ユニットにおける住登外情報の住所」、「住登外管理ユニットにおける住登外情報の法人情報」を対象のデータにすることが望ましい。また、地域情報
プラットフォームにおいて特に規定されていないデータを、地名辞典の地理識別子として扱う場合は、リソースとなるデータを準備する。
② 地理識別子とするデータから、「住所情報地名辞典」や「識別情報地名辞典」な
ど、どのような地名辞典を作成するか検討する。
③ 業務 DB において地理識別子としたデータをバッチ処理などで抽出し、地名辞典の地理識別子として格納する。
また、この段階においてデータ形式は、交換データスキーマなどにする。
④ 地理識別子に対応する地理座標を与える。必要に応じて、座標付与ツールを作成するとよい。
⑤ 地名辞典の交換データスキーマを用いて、地名辞典にインポートする。

①地理識別子とするデータを決定する②地名辞典の種類について検討する
住所情報地名辞典

住基情報
識別番号

・・・

現住所情報

000001

住所情報A

000002

住所情報B

・・・

：

000003③地理識別子として抽出する

住登外情報（住所、法人情報）
識別番号

抽出処理

業務DB

・・・

住所

000007

住所A

000008

住所B

・・・

業務DB

地理座標

住所情報A

（X1,Y1）

住所情報B（X2,Y2）

：

：

居住地A

（X3,Y3）

居住地B（X4,Y4）④「４．３．５」を参考に地理座標を付与する

：

：

住所A

（X5,Y5）

住所B（X6,Y6） 交換
データスキーマ：：：

000009

住所情報

所在地情報地名辞典
固定資産税情報
識別番号000010000011000012

・・・

所在地

・・・

所在地A
所在地B

業務DB

所在地情報

地理座標

所在地A

（ X2,Y2 ）所在地B（ X3,Y3 ） 交換
データスキーマ
：

：

：

地名辞典

目標物地名辞典（地域情報ＰＦで規定されていないデータ）
目標物データ

目標物情報

地理座標

目標物A

（ X9,Y9 ）目標物B（ X4,Y4 ） 交換
データスキーマ：：

住居表示データ

建築確認データ

図 ５-１７ 地名辞典の初期構築のイメージ

50⑤地名辞典にインポートする地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン（２） 地理座標の与え方について
本ガイドラインは、最善の地理座標の与え方を A)の方法とする。しかし、作業の労力／コ
ストと位置精度／業務データとのマッチング精度とを勘案し、自治体ごとの実情に合わせた整備方針をたてることも肝要である。
A) 地理識別子ごとに対話的に地理座標を付与する方法＜メリット＞
・地名辞典としての精度が高い。
・住基情報と一対で管理できる。
＜デメリット＞
・地理座標の付与に時間とコストがかかる。
・座標付与ツールの整備が必要になる。
B)

既存の地名辞典を利用して機械的に付与する方法＜メリット＞
・民間等の地名辞典を調達して利用することで、地理座標の付与にかかるトータルコストと時間の縮減が期待できる。
＜デメリット＞
・位置の精度が十分でない可能性がある。
・マッチしなかった地理識別子については A の方法が必要である。
・自治体が管理するデータについて、その位置座標が管理できない。

（３） アンマッチ対応
地名辞典の初期整備の際は、住所に対する座標が不明であるなどのアンマッチが生じる。初期整
備では、アンマッチの発生に備えた対処方法を備えることが望ましい。

ア）

アンマッチの主な発生原因

・過去の住所、現在は使用されていない字名称などが住民基本台帳の住所に登録されている。
・地図上にある複数の建物が同一の住居表示や地番に存在し、複数の建物から住民の居所を特定できない。
・過去のシステムや台帳記載の際の暫定措置（マンション肩書きなど予備枠に記入していた住所）などがある。
・住民が認識している住所と実際の登記上の住所・地番が異なっている。
など

イ）

アンマッチへの対応策

地名辞典の整備時に生じるアンマッチは、基本的には担当者が過去資料や現地確認を通じて調査を行い解決することが望ましい。

51

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

調査には、時間がかかることが予想されるため、地名辞典整備の作成工程には十分な期間を設けるか、アンマッチを含めた状態であっても、修正を継続しながら運用を開始する方法を取ることが望ましい。

ウ）

対応策の例

・ 現地調査や現地に詳しい担当者への聞き取りで調査を行う。
・ 消防部門の情報や税務部門の家屋図、空中写真などの現場資料と照合する。
・ 一つの住所に複数の建物がある場合を許容して、代表的な位置（街区代表点や、地番の親番号のある位置）で暫定的に運用を開始し、運用しながら地名辞典を修正する。
・ 地名辞典のテーブルに枝番号の領域を設け、同一住所にある複数建物を集合集宅等の肩書や部屋番号と同様に運用する暫定措置を採用する。

（４） 地名辞典整備に用いる情報別の整備手法例
地名辞典の初期構築では、使用する整備元資料に合わせてデータの精度や構築に係る時間期間が変化する。地目時点の整備・更新手法の分類と使用するデータの分類ごとに参考例を示す。

ア）

住所一覧に住基情報を用いて座標情報に庁内情報を使用する場合（例１）（例１）
住基情報を基準とした地名辞典を整備する場合

住所を識別するキーの情報を作成するための候補となる情報

住所情報へ付与する座標情報を作成するために候補となる情報（住所の一覧）（住所に係る座標）

座標情報を庁内にある情報から取得する場合

住民基本台帳

住居表示台帳（※）
または国土地理院「電子国土基本図（地名情報）住居表示住所」（※）

住登外情報

＜利点＞
・住基情報と一対で管理できる。
・自治体で更新をコントロールできる。
＜留意点＞
・地理座標の付与に時間とコストがかかる。
・座標の詳細さは、元資料の整備状況に応じる。

住所一覧
を抽出

地番図・家屋図

住所の一覧に座標を付与

建築確認調書消防局などの庁内機関で従来用いられていた住所録情報

アンマッチ
対応

現地調査・聞き取り等

地名辞典（住所辞書）（※）住居表示地区内

図 ５-１８ 地名辞典の初期構築（例１）52地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

イ）

住所一覧に住基情報を用いて座標情報に民間会社のデータを使用する場合（例２）（例２）
住基情報を基準とした地名辞典を整備する場合

住所を識別するキーの情報を作成するための候補となる情報

住所情報へ付与する座標情報を作成するために候補となる情報（住所の一覧）（住所に係る座標）

座標情報を民間会社の住所データを使用する場合

住民基本台帳
住登外情報＜利点＞
・地名辞典整備までの時間を短縮できる。
＜留意点＞
・位置の制度が不十分な可能性がある。
・アンマッチの対応件数が相当含まれる。
・住所データへの支払いや利用上の制約が生じる。

住所一覧
を抽出
住所の一覧に座標を付与

民間会社が販売する住所データ

アンマッチ
対応

現地調査・聞き取り等

地名辞典（住所辞書）

図 ５-１９ 地名辞典の初期構築（例２）ウ）

住所一覧と座標情報に庁内の既存情報を用いる場合（例３）（例３）
既存の住所データをそのまま利用住所を識別するキーの情報を作成するための候補となる情報

住所情報へ付与する座標情報を作成するために候補となる情報（住所の一覧）（住所に係る座標）

座標情報を庁内にある情報から取得する場合＜利点＞
・低コストで整備ができる。
・データ更新を自治体でコントロールできる。
＜留意点＞
・地理座標の付与に時間とコストがかかる。
・座標の詳細さは、元資料の整備状況に応じる。

住居表示台帳（※）
または国土地理院「電子国土基本図（地名情報）住居表示住所」（※）

住所一覧と
座標を抽出

地番図・家屋図
建築確認調書消防局などの庁内機関で従来用いられていた住所録情報

地名辞典（住所辞書）（※）住居表示地区内

図 ５-２０ 地名辞典の初期構築（例３）53地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドラインエ）

住所一覧と座標情報に民間会社のデータを使用する場合（例４）（例４）
既存の住所データをそのまま利用住所を識別するキーの情報を作成するための候補となる情報

住所情報へ付与する座標情報を作成するために候補となる情報（住所の一覧）（住所に係る座標）

民間会社の住所データを使用する場合＜利点＞
・地名辞典整備までの時間を短縮できる。

＜留意点＞
・位置の精度が不十分な可能性がある。
・住所データへの支払いや利用上の制約が生じる。

住所一覧と
座標を抽出

民間会社が販売する住所データ

地名辞典（住所辞書）

図 ５-２１ 地名辞典の初期構築（例４）54地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

5.8. 地名辞典の更新手法
地名辞典のデータは、地図データと同様に、データの新鮮さを保つことが重要である。例えば、市町村合併等によって新しい住所が制定されてもその情報が地名辞典に登録されていなけ
れば、利用価値の高い地名辞典とはいえない。
地名辞典の管理権限について
地名辞典の運用更新を確実に行うために、地名辞典ごとに運用更新を実施する管理部門を明確にすることを推奨する。また、管理部門以外が運用更新できないように、地名辞典には権限を設定するとよい。権限の設定は、「プラットフォーム通信標準仕様」の方針に従うものとする。

地理識別子の編集・削除について
地理識別子は、古い地理識別子もデータとして残しておくことが重要な場合がある。例えば、以前の図面等に記載された古い住所や施設名をキーワードとして検索を行う場面も考えられる。そのような場合のために、新しい地名辞典を作成した場合は、データを入れ換えるのではなく、追加をしていくことが重要である。
この場合、場所インスタンスの“時間範囲”という属性を用いて、古い地理識別子も保持し、管理することが推奨される。

地名辞典の運用方法について、以下の二つの方法が考えられる。

5.8.1. 定期的に更新する方法
一定の期間、更新情報を蓄積して、まとめてメンテナンスを行う方法である。この場合、更新間隔（次回の更新までの期間）や、更新時期（タイミング）については、適切な設定となるように検討しなければならない。
この方法は、初期構築と同様の方法で、更新情報（差分情報）を地名辞典に投入する。

初期構築の手順を差分で行うイメージ

業務DB
業務ＤＢから地理識別子
を差分で抽出

地名辞典

エクスポート

地理識別子に地理座標を付与する

交換
データスキーマ

インポート

地名辞典
【更新後】

【更新前】

図 ５-２２ 定期的に更新する方法のイメージ

55

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

5.8.2. 随時更新する方法（１） 随時更新の方法
日常的に修正のあった地理識別子の情報を随時更新していく方法である。地理識別子の更新が遅れると業務に支障をきたす場合や、地理識別子の更新量が小さい場合に用いることが考えられる。また、作成した地理識別子の内容（名称や地理座標等）に誤りがあった場合に随時更新を行うことは、地名辞典の情報の鮮度を保つことができ、日々業務ユニットから利用されるという観点から非常に有効である。

「住所情報地名辞典」の場合
更新量が大きいことが考えられるが、業務ユニットからの利用頻度が高いので、随時更新していく方法が望ましい。例えば、住基情報に新たな住所情報が追加された場合、同時に「住所情報地名辞典」にもこの住所情報を地理識別子として追加することが望ましい。
住民基本台帳ユニット
住民基本台帳ユニット

ＧＩＳユニット
ＧＩＳユニット

住民基本台帳ＤＢ

ＧＩＳＤＢ

地名辞典

住基情報
現住所情報

・・・

住所情報

地理座標

○○町1丁目-1-1

・・・○○町1丁目-1-1（35.876，139.988）○○町2丁目-2-2

・・・○○町2丁目-2-2（35.111，139.222）○○町3丁目-3-3

・・・

更新

随時更新は、場所インスタンス登録インタフェース5などを利用して行うことができる。
業務ユニットＡにおいて地理識別子としているデータが新たに登録されたときに、GIS ユニ
ットの“場所インスタンス登録インタフェース”を利用して、地名辞典にその地理識別子を追加する方法である。更新や削除時にも同様に、対応する場所インスタンス更新インタフェース”、
場所インスタンス削除インタフェース”を利用して、地名辞典の更新や削除を行うものである。
この方法では、図５－２３に示すように、業務ユニットＡ側は、これらのインタフェースを呼び出す処理の実装が必要になる。

5

GIS 共通サービス標準仕様 V3.2 において、“場所インスタンス登録”インタフェースは簡易的なものである。

56

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン
ＧＩＳユニット
ＧＩＳユニット

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

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

ＤＢーA
現住所情報

・・・

○○町1丁目-1-1

・・・○○町2丁目-2-2

・・・○○町3丁目-3-3

・・・

ＧＩＳＤＢ

地名辞典
住所情報

地理座標

○○町1丁目-1-1（35.876，139.988）○○町2丁目-2-2（35.111，139.222）

更新

登録・更新・削除されたときに対応するGIS共通インタフェー
スを呼び出す処理実装が必要である場所インスタンス登録インタフェース
場所インスタンス更新インタフェース
場所インスタンス削除インタフェース

図 ５－２３ GIS 共通サービスインタフェースを利用した地理識別子の運用更新のイメージ（２） 建物レベルの地名辞典の更新事例
住居表示と、建築図形を結びつけ、建物の位置を特定するレベルで、住民からの転入・転出・転居などの日々の利用の中で整備・更新を行う。
図５－２４は、平成 27 年度 G 空間プラットフォーム構築事業（官民連携型共通空間基盤データベースの開発・実証）の中で実施された、統合型 GIS を活用して住所に関する情報を相互参照する方法をイメージ化した図である。図中の①、②、③、④で示す住居表示係の受付や住民登録の受付等の運用のいずれかを活用して、日常的に地名辞典の更新を行う。

住居表示担当建築確認担当固定資産税担当

住民登録担当法務局登記情報受取建物図形(新築)の受付

課税客体の管理情報の更新

申請資料

家屋評価

建築確認データ
住居表示係 受付

・建物の仮図形
・申請に基づく
建物形状情報住居表示管理台帳

建物図形レイヤ

住民登録 受付

発行した
住居表示番号

・住居表示番号の符与

住居表示番号（住所コード）住所情報（住居表示番号）をもつ建物図形が、
地名辞典と同等の役割を担う。

家屋評価による
建物形状情報住居表示番号（住所コード）4情報（住所、氏名、性別、年齢）他の登録

家屋評価に基づく
建物形状情報地番図等の地図整備・更新

住民基本台帳
住居表示番号（住所コード）

行政の諸台帳
住居表示番号（住所コード）

職員による
現地調査

共用の建物レイヤの更新（ex. 年1回）

地番図・家屋図

④

①

②

③

建物レベルの地名辞典（住所辞書）

図 ５-２４ 建物レベルの地名辞典の随時更新のイメージ

57※ 住居表示が未実施でも運用可地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドラインア） 地名辞典の随時更新を行うための工夫（建物レベルの詳細さを必要とする場合）
住民基本台帳の更新のタイミングで地名辞典の更新を行う運用事例を図５－１８で紹介した。
この時、建物レベルの精度で地名辞典の位置情報を指定するためには、住民の転入・転居等で居所となる場所に発行する住所について、庁内から参考となる建物等の情報を共有することが必要になる。
居所の場所を示す住所の位置を確認する方法として、建築確認や家屋図から得られる建物の位置情報や、住居表示番号のフロンテージの箇所の情報から得られる位置情報を用いる方法がある。これらの情報は、地方公共団体において、下記の各部署がデータを管理する場合が多い。
表 ５‐７ 入居時に発行する住所について参照する位置情報

情報

部門

地番の登記情報（地番地区）
建築確認申請時に申請された土地の地番情報
住居表示申請の住居表示申請情報（建築主が住居表示番号を申請する）
固定資産税家屋建物の配置情報（入居者が既存の建物に入るとき）

固定資産税等の税務担当部門
建築確認を担当する部門
住居表示を担当する部門
固定資産税等の税務担当部門

上記情報は、それぞれ担当する部署が異なる。そのため、各部署が持つ情報を庁内で共有することが重要となる。位置情報の共有には、庁内の各部門が地図参照することが可能な統合型
GIS 等の活用が考えられる。図５－２４に示した横方向の破線矢印は、統合型 GIS 等を用いて位置図を共有することを示している。
また、住民課等の窓口業務において参照する位置図には、窓口に来庁した住民の転入先の住所が地図等で示されている必要がある。しかし、新築の建物などは、地図データとして整備されるまでには時間を要するため地図としては共有されない。
そのため、居所の確認に必要な、住居表示番号のフロンテージ情報や、地番、建築確認申請
で届けられた建物位置情報と建物所在の仮番号などが、住民の来庁のタイミングより早い段階で共有されていることが重要である。新規で入居される地区の地図情報などは、庁内の地図の最新情報であることから、建築確認申請などを受けた段階でタイムリーに仮情報として提供することが有効である。

図 ５-２５ 統合型 GIS を用いて建物位置をタイムリーに確認しているイメージ

58

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン（３） 住居表示のフロンテージや土地代表点レベルの地名辞典の更新事例
住居表示と街区を結び付け、住民からの転入・転出・転居などの利用の中で整備・更新を行う例を示す。

新規の住居表示対象地
住居表示
の適用

建築主（所有者）

売買

住民サービスの開始

住居表示番号発行
実施対象地の情報

入居の世帯主転入届け

住居表示付番申請

住居表示の実施

住居表示係り受付
地区名、街区符号

4情報（住所、氏名、性別、
年齢）他の登録発行した住居表示番号

適用範囲の情報

住居表示実施状況図

住民登録受付

住民基本台帳

住居表示管理台帳

世帯番号、
住所コード

住所、住所コード

フロンテージまたは土地代表点
レベルの地名辞典（住所辞書）

住所コード

宛名データベース

世帯番号

行政の諸台帳X,Y座標

デジタル地図の整備・更新
共用の地形図の更新（ex. 年1回）

GIS管理部門

縮尺1/2500のDM

住民基本台帳等の地図との連動

図５-２６ 住居表示のフロンテージや土地代表点レベルの地名辞典の随時更新のイメージ
地名辞典の対象とする位置情報について、土地代表点レベルでの詳細さで十分な場合、庁内で利用している GIS の背景図を用いて、手入力等で運用に応じた精度の位置情報を整備することも可能である。背景に必要な情報を簡易に調達することで、高精度な整備を行う場合に比べて早期に、また費用を抑えて地名辞典の整備に取り掛かることが可能になる。但し、この手法で作成した地名辞典は最高精度を求めるものではないため、利用用途に対して十分満足できる物であることを確認し、品質水準を認識した上で用いることが重要である。

59

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン（参考）住民窓口で随時更新する事例（会津若松市）
福島県会津若松市では、地名辞典の初期整備の段階では住民異動処理の責任部署である市民部市民課が主体的に整備したことを成功要因として挙げている。そして、更新
は随時（日単位）実施することで、データベースが常に実際の状況を反映したものとなっている。
地名辞典を随時更新する方法は、転入手続きの際に受付窓口の職員が印刷地図をもとに転入者に居住地を確認している。窓口で確認した居住地のデータは、業務終了後に受付窓口の職員が GIS に入力し、翌日には最新の地名辞典が庁内で参照可能な状態にしている。地名辞典のマッチング精度は、入力ミスなどによるエラーがないと仮定した場
合、理論的には 100%である。

毎夕方、データの更新を GIS に反映

窓口で異動場所について聞き取り（４） 精度向上に向けた取り組みア） 住所の参考となる情報の電子化と庁内の情報共有
住民基本台帳の住所の生成は、住民窓口が対応する住民の転入や転居の時に行われる。この際に、住所の参考となる住居表示の仮番号等の位置情報は、住民窓口担当者と共有しておくことが重要になる。
新築建物の位置や新規の住居表示番号の共有手法としては、統合型 GIS の活用などが効果的である。
住所の参考となる位置情報は、住所識別番号等と座標を GIS データとして管理し、データ発生源の各所管部門では、個人情報に配慮しつつ位置情報を他課で利用できるように共有化することが重要である。

イ） 住所に関する情報の高頻度の更新
住所の変化に関する情報（建築確認申請や、住居表示番号の仮発行など）について、更新と同時に庁内の関係者と情報共有することで、様々な部署において最新の情報が使えるようになり、時間精度が向上することから、庁内で運用方法を定め、随時更新を行うことが望ましい。
地番図の情報等は、多くの地方公共団体では、定期的にまとめて更新する手法がとられているが、更新頻度を高めることで、部門間においてデータを参照するときの時間的な差が縮小し、データが有効に活用される可能性が高くなる。以下に更新方法の例を示す。

60

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン（a）建物レベルで随時更新（高精度）
住基情報と対応する位置情報について、建築確認申請時の資料や住居表示の仮番号の位置情報を参照して随時更新する方法。建築確認申請等の建物の位置情報などは、統合型 GIS 等を活用して、タイムリーに庁内で情報を共有する。
（b）フロンテージや土地代表点レベルで更新
住基情報と対応する位置情報について、住居表示のフロンテージや地番図の位置情報を参照する方法。参照する位置情報は、庁内のデータ更新の頻度（年 1 回など）に合せて修正する。
（c）簡易な方式で地名辞典を更新
住民課の窓口で世帯の位置情報を地図上で指さし指示を住民にしてもらい、地名辞典の位置情報を更新する。
表 ５－８ 日常的に更新を行う場合の信頼性・更新頻度・初期コストの例（a）建物レベルで随時更新（高精度）（b）フロンテージや土地代表点レベルで更新（c）簡易な方式で地名辞典を更新

信頼性求められる更新頻度

コスト(初期)

高

随時

高

中～高

年 1 回～数回

中

低～高

随時

低

（参考）定期的な更新の頻度を高めて精度を向上させる
近年、統合型 GIS や固定資産税に関わる GIS を運用する地方公共団体では、地番図や背景地図の定期的な更新頻度を高めて、1 度あたりの更新数量を年間を通して平準化する方式を採用する団体がみられる。これは、システム運用の年間契約の中でデータの更新回数を複数回設定することで実現できる。
例えば、地番図の更新では、土地登記情報を 3 か月ごとに集約して、年間 4 回更新を行うものである。更新頻度を高めることで、年度末に集中するデータの保守作業を平準化するとともに、地図情報の新鮮度を高めることができる。

ウ） スモールスタートと継続的な情報更新
地名辞典の初期整備を行うと、実際は多数のアンマッチが生じる。そのため、初期整備の段階
ではアンマッチを多少許容しながら、運用を継続する中で調査判明したデータを更新し、精度を高めていくスモールスタートの手法も考えられる。住民の居所は日々異動があるため、継続的な更新を続けることが重要になる。

61

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン（５） 情報の共有化を推進するために情報の共有化を推進するためには次の 3 点が重要である。以下に示す推進活動は、日常の行政業務を通じて実践されることが望ましい。
ア） 推進部門の継続的な活動
GIS の活用に際しては、庁内推進体制を明確にし、推進部門のリーダーシップのもとで取り組みを行うことが効果的である。また、庁内における GIS 活用のノウハウを共有し、GIS の活用が庁内業務の向上に役立つという職員への意識付けも必要である。そのためには、一般職員
が GIS を日常的に活用することができるよう、推進部門主導で GIS の活用ワーキンググループを開催したり、ワークショップや研修の機会を提供するなど、職員のニーズを吸い上げたりス
キルアップに繋がる活動を行うことが効果的である。（対応部門：情報政策部門など）

イ） 住民対応部門の協力と動機付け
地名辞典の随時更新には住民窓口となっている部門の協力が不可欠である。データ利用推進
部門は、庁内において GIS がより効果的に活用できることを、住民異動処理を所管している部門に説明し、ワークショップなどでその効果を示すなど、協力を得られる動機付けが重要である。（対応部門：市民課など）

ウ） 情報共有のための運用ルールづくり
固定資産税の担当部門が管理する地番図や家屋図は、個人を特定する情報を削除し住所と座標の情報として、庁内での共有に取り組むことが重要である。地番図の利用に際し、地方公共団体の一部では、税務情報として目的外利用を制限している場合がある。その場合は、地番図の利用目的を限定している条例等の解釈を精査し、住所情報として活用するための方策を検討することで対応可能な場合がある。
空中写真や地番図などは統合型 GIS の供用空間データとして、情報整備の際にあらかじめ全
庁共有を目的として情報部門等が代表で整備を行うことで情報共有の利用制限が解消しやすくなる。（対応部門：情報政策部門や資産税課など）

62

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

6. GIS ユニットの調達
6.1. GIS ユニットの調達の手順
GIS ユニットの調達においては、業務プロセス改革や住民サービスの向上を意識し、地理空間情報を利用した業務改革にかかる目標を定め、実行可能な手順と体制を整える必要がある。
そのため、本章では、地方自治体が GIS ユニットの調達する際の手順等にかかる解説を行う。
なお、実際に調達の検討を進める際には、本ガイドラインの他、「GIS ユニット調達の手引き」
においても詳細な解説が記載されている。そのため、本ガイドラインではポイントのみを解説することとする。
なお、「地域情報プラットフォームを活用した業務改善とシステム調達の手引き」では業務改善を含んだシステム調達の手順を 6 つのフェーズに分けて説明している。GIS ユニットも同様の流れで調達することになるが、それぞれのフェーズについて、GIS ユニットの調達に特有の実施事項が存在する。また、GIS ユニットが動作するためには地名辞典が必要である。
GIS ユニットは、住基情報と位置情報を組み合わせる汎用的な仕組みで、特定の業務を対象とはしているものではない。そのため、「(1)目的の明確化」では、利活用分野や利活用シーンの検討を行い、GIS ユニットを実際にどのように利用するかを明確化していく必要がある。また、「(3)組織の設定」及び「(4)現状整理・業務改善」では、GIS ユニットの調達時に必要な実施事項として、地名辞典（住所辞書）の整備・更新組織を設定していくことが必要である。

※

Ｇ
Ｉ
Ｓ
ユ
ニ
ッ
ト
の
調
達
フ
ロ
ー
（
１
）

地
名
辞
典
の
調
達
フ
ロ
ー

(1)
目的の明確化(2)
プロジェクト計画

(1)-1
上位方針

(2)-1
環境分析

(1)-2
業務・シス
テム環境

(2)-2
実行計画

(1)-3
プロジェク
ト方針

(2)-3
ＷＢＳ

(1)
目的の明確化(1)-4.1
利活用分野の検討(1)-4.2
利活用シーン
の検討

(3)
組織の設定

(4)
現状整理・業務改善

(6)
調達方針

(5)
再構築方針

(4)-1
情報システム資産管理

(3)
推進組織
設定
(PMO・作業
部会等)

(4)-2
RFI
(4)-3 業務整理・改善
仕様(4)-3.1
業務
改善

(5)
再構築
(改修)
方針・基
本計画

(4)-3.2
選択1
クラウド・SOA開発

予
算
承
認

(6)-2
評価方針

(6)-3
運用

(4)-3.3
選択2パッケージ選定

(3)
組織の設定
(3)-1
GISユニット導入・運用のための
体制構築

(6)-1
RFP

(4)-4
地名辞典に係る業務整理・改善(4)-4.1
データ仕様の策定(4)-4.2
データ整備方法の策定(4)-4.3
データ整備フローの検討(4)-4.1.1
マッチングレベルの検討(4)-4.2.1
地名辞典整備方法の検討(4)-4.3.1
地名辞典の整備フローの検討(4)-4.2.2
地名辞典に
必要な情報
の収集

(4)-4.3.2
地名辞典の更新フローの検討(4)-4.1.2
住所を識別するキー及び代表点の検討（※１）「地域情報PFを活用した業務改善とシステム調達の手引き」で示されているフローに準じる

図６－１ GIS ユニットと地名辞典の調達フロー

63(4)-4.4
サービス実現方式の検討(4)-4.4.1
サービス
実現方式
の検討

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

6.1.1. 調達の手順のポイント（１） 目的の明確化
目的の明確化のフェーズにおいては、「利活用分野・利活用シーン」を検討することが特に重要なポイントとなる。GIS ユニットは住基情報と位置情報をつなげる汎用的な仕組みのため、様々な利活用方法が考えられる。そのため、まず GIS ユニットをどのような分野で活用するかを確認する必要がある。
この検討においては、本ガイドラインの 3 章「GIS 共通サービスの活用と効果」、付録 7.3「事例集」、「GIS 共通サービス基本提案書」等にも利活用分野やシーンが記載されているため、そちらを参照されたい。また、併せて地方自治体内の各部署にヒアリング等によってニーズを確認していくことにより、明確化していくことが望ましい。
GIS ユニットの利活用分野や利活用シーンが明確化できると、どのような条件の地名辞典が必要になるかが明確になり、どのような GIS ユニットおよび地名辞典を調達すれば良いかが判
断可能となる。こちらは、本ガイドライン 5.4「地名辞典の利用目的に合わせた整備レベル」を参照されたい。なお、「住民地図」を利用した業務の場合は、地名辞典の信頼性はより高いものが必要であることから、可能な限り高い精度で整備することが望ましい。

（２） プロジェクト計画
プロジェクト計画のフェーズにおいては、情報システム調達のみの観点での計画ではなく、GIS ユニットで利用される地名辞典の調達（整備）すなわちデータ調達（整備）の観点も加えていくことが重要である。また、地名辞典の整備方法、つまり請負・外注等による整備か、自庁で整備していくのかなどにより、プロジェクト計画が変わってくるため、次のフェーズとの整合をとりつつ随時見直しをかけていくことが必要である。

（３） 組織の設定
調達に向けて庁内の関係組織でプロジェクトを発足させるフェーズである。すでに構想のためのプロジェクトが立ち上がっている場合は、全体コントロールとしての意思決定機能の機関、さらに必要に応じて作業部会を設定するなどして業務内容を実行に向けたものに変えていく。
ここでの重要なポイントは、地名辞典の原典データを管理している主管部門を含めて、地名辞典の整備・更新体制を作ることである。また、体制の構築においては、自治体の規模・状況や利用目的により柔軟に進めていくことも重要である。以下に、組織を設定するうえでのポイン
トを記載する。
●GIS ユニット導入の推進体制の構築
GIS ユニット導入を推進・調整するための体制が必要になる。多くの部門が関わるケースでは、全体を統括する体制を設けて意思決定を迅速に進めることが重要である。
●GIS ユニットを利用する様々な部門が参画した利用目的の検討体制の構築
GIS ユニットは、特定の業務のみに寄与するものではなく、工夫次第で多様な業務での利活用が可能である。利用分野を広げ、GIS をユニット導入の効果を高めるためにも、庁内の様々

64

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドラインな部門から参画し検討する体制をつくることが重要である。また、発生する課題や、導入後の円滑な利活用において各種法令、条例への対応などについても確認を行うことが重要である。
●原典データを管理している主管課を含めた地名辞典整備・更新のための体制の構築
GIS ユニットが有効に機能するためには、常に地名辞典がメンテナンスされていることが重要である。そのため、地名辞典の整備・更新を実施する体制が必要となる。地名辞典は適切に更新されないと、陳腐化する恐れがあるため、特に地名辞典更新の体制が運用上重要となる。
●業務最適化に対する検討体制の構築
GIS ユニットを導入するにあたり、業務や関連システムの最適化が必要となる場合には、その業務に関連する部門を含めた業務最適化検討体制が必要となる。この場合、GIS ユニットの導入検討も、業務やシステムの全体最適化の一環として行われることが望ましいと言える。
地名辞典の整備方法によっても必要な体制は異なる。以下に、地名辞典の整備・更新方法と望まれる体制の一般的な関係を示す。
表６－１地名辞典に関する更新体制、方法

望まれる体制GIS ユニット導入
推進体制

GIS ユニッ
ト利用目的

業務最適化
検討体制

地名辞典整備・更新体制

検討体制

全体統
括・意思
決定体制
の確立

庁内の様々
な分野の利
用部門から
の参画

住居表示台帳図、
地番現況図、都市計画図などの位置に係るデータの主
管課の参画

住民基本台
帳管理部門
の参画

地名辞典の
整備・更新に責任を持つ部門の設定

業務・システム全体最適化の一環とし
ての体制確
立

随時
更新

○

○

○

○

○

○

定期
更新

○

○

○

○

○

△

既存の住所データを、そのまま利用

○

○

-

-

○

△

地名辞典の
整備・更新方法
住基情報
を基準とし
た地名辞
典を整備

65

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン（４） 現状整理・業務改善
GIS ユニットに関連する既存の資産（ハードウェア、ソフトウェア、ネットワーク、セキュ
リティ、規程）の確認や対応ベンダーの調査（RFI）を実施し、必要な情報を整理していくフェーズである。なお、ここで重要な事項としては、利用目的に応じた地名辞典の仕様や地名辞典の整備・更新フローを決めていくことである。
地名辞典データを保有していない場合には、新たにデータ整備や調達を行う必要がある。地名辞典データに相当するデータをすでに保有している場合であっても、先に検討した利用目的を満たせるかどうかを確認し、必要に応じて、データの調製等を行う必要がある。
いずれにしても、GIS ユニットの導入に当たっては、利用目的を満たすための地名辞典のデータ仕様を策定する必要がある。
仕様の策定にあたっては、本ガイドライン５章「地名辞典の整備・運用」を参照されたい。

（５） 構築方針（計画）の立案検討した内容の最終確認を行い、計画案を立案するフェーズである。また、費用の算定を行い、予算化を行っていく。GIS ユニットや地名辞典を組み入れた上で、「地域情報プラットフ
ォームを活用した業務改善とシステム調達の手引き」準じて、構築方針（計画）の立案を実施していくことが必要である。

（６） 調達計画の立案
提案依頼書（RFP）を策定し、実際に調達を実施していくフェーズである。RFP の作成のポイントは「地域情報プラットフォームを活用した業務改善とシステム調達の手引き」に準じますが、GIS ユニット調達にあたっては、GIS ユニット自体の RFP に加え、地名辞典の整備・更新にかかる RFP の策定も必要となる。
なお、GIS ユニットの調達と地名辞典の調達は別々に実施することも可能である。

66

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

6.2. GIS 共通サービスの調達・運用にかかる積算項目
GIS ユニットや地名辞典の調達・運用については、基本的にはコストが発生する。本章では、その調達・運用にかかるコストについて記載するが、以下のことに注意されたい。
まず、GIS ユニットについては、その多くがベンダーの GIS 製品・サービスとして販売されており、含まれている機能・サービス等の相違による価格の違いや、日々の市場価格の変動があることから、標準的な費用を提示することは困難である。そのため、本ガイドラインでは、構築方式のパターンによる費用的な面からの一般的な特徴のみを記載することとする。
地名辞典についても、自治体の人口規模や面積、既存データの活用などにおいて、整備のコ
ストは大きく変わってくる。また、市場から地名辞典の製品そのもの調達する方法もあり、その場合は事業者等のサービス提供価格に依存する。そのため、本ガイドラインでは、事業者の製品の価格については例示から除いたうえで、自治体が整備・運用する場合の代表的なパターンを示したうえで、想定される標準的なコストを例示することとする。
なお、例示したコストについても、技術の発展、市場の価格の変動および整備にかかる人件費の変動等により、将来的に保障されるものではない。

6.2.1. GIS ユニットの整備・運用コスト（１） GIS ユニットのサービス形式
GIS ユニットのサービス形式には、代表的なものとして、オンプレミス型（自治体内に独自のサーバを設置する方式）とクラウド型(LG WAN-ASP 等として LG-WAN 上で提供されるサービスを利用する方式)がある。以下、この二つのパターンのコスト的な特徴について述べる。

ア） オンプレミスの特徴
まず、上記方式の一般的な違いであるが、オンプレミスで実現した場合、サーバ運用に関する自由度が高まるとともに、場合によりソフトウェアの柔軟なカスタマイズ等が可能となる。
しかしながら、調達の際に実現したい内容やデータ量を明確にしたうえで、ハードウェア・OS・
ミドルウェア・ソフトウェアの選定を行うとともに、導入後にも職員による適切なメンテナン
スが必要となってくる。また、導入後概ね 5 年が経過すると、ハードウェア・OS・ミドルウェ
ア・ソフトウェアの更新が必要となるとともに、運用期間には一般的にバージョンアップ等は実施されない。

イ） クラウドの特徴
一方で、クラウド（LG WAN-ASP）の場合は、サーバ運用やソフトウェアのカスタマイズに関する自由度は低いが、サーバ、ミドルウェア・ソフトウェアに関して独自の選定をすることなく、パッケージ化されたサービスとして提供されるため、稼働や運用にかかる信頼性は高くなる。また、サーバメンテナンスやデータセットアップ等を行う必要がないため、運用のための職員の労力を低く抑えることが可能である。加えて、運用期間中のハードウェア・OS・ミ
ドルウェア・ソフトウェアのバージョンアップ等の対応が契約内容に含まれているサービスであれば、常に最新の状態で利用することが可能となる。

67

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

コスト面であるが、まずオンプレミス型では、ハードウェア・OS・ミドルウェア・ソフトウ
ェアの調達・設置・運用設定費用が必要となってくる。そのため、初期整備と更新時に費用が高額になるケースが多い。運用時には保守費用のみが必要となる。
一方で、クラウド型に関しては、月額等による利用料と初期導入時の設定費用が必要となる。
オンプレミス型と比較して、初期費用や更新費用を低額に抑えることが可能である。しかしな
がら、導入時以降には利用料を計上していくこととなる。

6.2.2. 地名辞典の整備・運用コスト（１） 地名辞典の整備コスト
自治体が地名辞典を整備する場合の標準的な事業項目をケース別に示す。本ケースは整備済
み自治体へのヒアリング結果を参考にして算出したものである。自治体が整備する場合、自庁の状況が各ケースの考え方のいずれかに当てはまるとは限らないため、ケースの内容を参考にしつつ、既存データ等の確認や、職員のリソース等の状況を加味したうえで、検討することが望ましい。また、本ケースは整備を外注した場合のコスト試算である。自庁内に地名辞典を整備するためのツール等があり、職員リソースもある場合は、自庁職員での整備も可能であり、その場合は、事業費を低減させることも可能である。なお、標準事業項目の算出にあたり、社会的条件と保有データ等の条件を設定している。設定した基準は以下のとおりである。
地名辞典を整備するにあたっては、ケース内容・条件・職員リソース等を加味したうえ柔軟な検討を実施することが必要である。

＜各ケースにおける想定条件＞●社会的条件-人口：10 万人-世帯数：3 万世帯-行政面積：100k ㎡●既存の保有データ等の条件-レベル 2500 デジタルマッピングデータまたは基盤地図情報レベル 2500 が全域存在-可住地域における地番図が存在しており、少なくとも毎年 1 回は更新
-空中写真（オルソ画像）データを保有-住民基本台帳システムを運用しており、住所データを抽出可能

68地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドラインア） ケース１ 住居表示データから整備を実施するケース
住居表示台帳の電子化を図りつつ、既存データを利用して作成する方法である。このケースの場合、住居表示地区の面積が事業費に大きく影響してくる。しかしながら、住居表示システ
ム等を導入することで、住居表示事務処理の効率化が可能となるケースである。
表６－２ 住居表示データから地名辞典を整備する場合
項目

数量

１．資料収集整理
２．打ち合わせ単位
13３．住居表示データ整備 ※1

備考
式
回・既存資料からの電子化業
務とし、認定作業は含めない
街区 ・この項目の数量と資料の状況について、コストへの影響
が大きい
式

1,000

４．データ加工処理

1

５．データ突合および アンマッチ情報作成

1

式30,000件

６．代表点データ修正

委託範囲は資料照合や、打件 合せに基づくデータ調整作業を想定※2 アンマッチ率 15%と想定。

７．アンマッチデータ確認・修正※24,500※1 住居表示地域は 1000 街区と想定。

イ） ケース２ 住居表示データの整備を含まないケース
本ケースは、すでに自庁において、住居表示台帳の電子化が終了している場合や国土地理院「住居表示住所」を利用して整備する場合、または住居表示地域なし（地番図データの利用）の場合を想定する。
表６－３ 地名辞典の整備に住居表示データ整備を含めない場合
項目

数量

単位

備考

１．資料収集整理
３．打ち合わせ３．データ加工処理
４．データ突合および アンマッチ情報作成
５．代表点データ修正

13
1
130,000式
回式
式
件

６．アンマッチデータ確認・修正※1

4,500

委託範囲は資料照合や、件 打合せに基づくデータ調整
作業を想定※1 アンマッチ率は 15%と想定。

69

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドラインウ） ケース３ 住居表示データの整備を含まないケース（消防部局が持つデータの利用）
消防部署が整備し、適時に更新されている座標付き住所台帳データが行政区域の全域で使用できる場合、既に地名辞典の基礎的なデータが整備されているため、データ整備にかかるコストを低減することができる。また、一般的にはアンマッチ率も低い。加えて、レベル 2500 デジ
タルマッピングデータ等にあわせて地名辞典の位置座標が整備されている場合は代表点データの修正点数が減少する。
表６－４ 地名辞典の整備に消防部局が持つデータを利用する場合
項目

数量

単位

１．資料収集整理
２．打ち合わせ３．データ加工処理
４．データ突合および アンマッチ情報作成
５．代表点データ修正※1

1
3
1
1
6,000

６．アンマッチデータ確認・修正※2

1,500※1 修正点数は世帯数の 20%と想定

備考
式
回
式
式
件

委託範囲は資料照合や、打合
件 せに基づくデータ調整作業を想定※2 アンマッチ率は 5%と想定（２） 地名辞典の運用コスト
地名辞典を整備し、運用フェーズに入った場合の事業費を以下に示す。なお、数量は（１）と同様の条件の下で実施している。
なお、一般的には、GIS ユニット等のシステムを用いて、自庁内で日次や週次による運用更新を行っていく自治体が多い。そのため、以下に示す事業費は、年次更新かつ、外注を行った
場合のみを示すこととする。さらに、利用する各種データの更新の時点と住民基本台帳データの時点で整合が取れない場合、突合時のアンマッチデータが多く発生するため、可能な限り突合するデータの時点は合わせることが望ましい。

ア） ケース１ 住居表示地域を含むケース
住居表示地域が自治体内に存在する場合は、住居表示台帳の異動分と地番データの異動分の両方を地名辞典に反映する必要がある。ただし、全域住居表示地域の場合は、住居表示の異動分の反映だけでよい。なお、地番図データは当該年 1 月 1 日時点に更新されていることを前提
とする。

70

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

表６－５ 住居表示データから地名辞典を更新する場合
項目

数量

単位

備考

１．資料収集整理
２．打ち合わせ３．異動分住居表示台帳データ入力
４．地番データ加工処理
５．データ突合および アンマッチ情報作成
６．代表点データ修正

1
3
150
1
1
900

式
回
件
式
式
件 全世帯の3%が異動と想定。

７．アンマッチデータ確認・修正

300

件

残存アンマッチは全世帯の1%と想定。

イ） ケース２ 住居表示地域を含まないケース
本ケースは、全域が地番地域であり、当該年の 1 月 1 日時点に更新された地番図データを加工して地名辞典に反映することを想定する。
表６－６ 地名辞典の更新に住居表示データ整備を含めない場合
項目

数量

単位

備考

１．資料収集整理

1式

２．打ち合わせ3回

３．地番データ加工処理

1

式

４．データ突合および アンマッチ情報作成

1式

５．代表点データ修正

900

件 全世帯の3%が異動と想定。

６．アンマッチデータ確認・修正

300

件

残存アンマッチは全世帯の1%と想定。

ウ） ケース３ 消防部局が持つデータを利用して更新するケース
消防部署が保有する更新された座標付き住所台帳データと住民基本台帳データの突合を行い、差分だけを反映する手法とする。
表６－７ 地名辞典の更新に消防部局が持つデータを利用する場合
項目

数量

単位

備考

１．資料収集整理
２．打ち合わせ３．データ加工処理
４．データ突合および アンマッチ情報作成
５．代表点データ修正

1
2
1
1
900

式
回
式
式
件 全世帯の3%が異動と想定。

６．アンマッチデータ確認・修正

300

件

71

残存アンマッチは全世帯の1%と想定。

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

6.3. GIS 共通サービスの調達仕様
6.3.1. GIS ユニットの調達
GIS 共通サービスの利用にあたり、GIS ユニットを調達する必要がある。また、GIS を GIS
ユニット以外の業務システムから利用する場合、関連するシステムに GIS 利用機能を備えることも検討する必要がある。
GIS ユニットの調達や関連システムへの GIS 利用機能の調達は、「地域情報プラットフォー
ムを活用した業務改善とシステム調達の手引き」に詳細を記載しており参照されたい。
情報システムの調達に関して、庁内における調達計画の策定には、複数のシステムベンダーに RFI,RFP の提出を求め、調達方針を定めていくことがある。
表６－８、表６－９に、GIS 共通サービスの調達に関する RFP,地名辞典の調達に関する RFPの項目例を示す。
GIS ユニットの調達に関して関連システムの改修や、新規システムの導入に関する計画については、下表中の項番「2.6.9 他の情報システムとの連携」の項目に記述される。また、GIS ユ
ニットに搭載するデータに関する項目も必要になる。

72

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

表６－８ ＧＩＳユニットを調達する際の RFP の項目例

項番
1
1.1
1.2
1.3
1.4
1.5
2
2.1
2.2
2.3
2.4
2.5
2.5.1
2.5.2
2.5.3
2.6
2.6.1
2.6.2
2.6.3
2.6.4
2.6.5
2.6.6
2.6.7
2.6.8
2.6.9
2.7
2.7.1
2.7.2
2.7.3
2.7.4
2.7.5
2.7.6
2.7.7
2.7.8
2.8
2.8.1
3
3.1
3.2
3.3
3.4
3.5

項目
概容
業務の名称
背景及び経過本調達の目的本構築計画の対象業務・システ
ム
本構築計画における調達範囲
本調達の要件業務作業範囲
期間
納品場所
成果物
業務要件
対象業務のユーザ
対象業務及び、周辺業務の概容
業務品質要件システム要件
ライフサイクルコスト
システム機能システム性能システム信頼性
ユーザインタフェース
ハードウェア構成
ネットワーク構成
ライセンス数
他の情報システムとの連携システム開発・運用要件
スケジュールシステム開発納品
導入
受け入れテスト
教育訓練
システム運用システム保守
データ要件
システムに搭載するデータ
留意事項
検収方法
権利の帰属
再委託
瑕疵担保責任その他

73

内容
調達する業務の名称
今までの経過調達の目的対象となる業務・システム
依頼範囲
業務として依頼したい内容
依頼期間
納品場所
具体的な成果物名
ユーザの概容（部門・人数等）
対象とする業務の整理
業務品質として指定する項目システムのライフサイクルコストに即したコストシステムで要求される機能システムで要求される性能システムの信頼性
ユーザの操作画面に関する定義指定されたハードウェアの構成要素指定されたネットワーク構成
必要なライセンス数
連携の必要なシステム一覧
開発のスケジュール要件
開発に関するルール、特記事項
納品のルール
導入のルール
受け入れテストの定義、評価基準の考え方
教育訓練の期待内容
システム運用についてのルール
システムに搭載するデータ検収要件開発したソフトウェアの帰属原則は禁止
瑕疵担保の特記事項

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

6.3.2. 地名辞典の調達
地名辞典の整備、更新に関する RFP の項目と内容例を以下に示す。
表６－９ 地名辞典を調達する際の RFP の項目例

項番
1
1.1
1.2
1.3
1.4
1.5
2
2.1
2.2
2.3
2.4
2.5
2.5.1
2.5.2
2.5.3
2.6
2.6.1

項目
概容
業務の名称
背景及び経過本調達の目的本構築計画の対象業務・データ
本構築計画における調達範囲
本調達の要件業務作業範囲
期間
納品場所
成果物
業務要件
対象業務のユーザ
対象業務及び、周辺業務の概容
業務品質要件地名辞典の整備・更新
データ仕様

2.6.2
2.6.3
2.6.4
2.6.5
2.6.6
2.6.7
3
3.1
3.2
3.3
3.4
3.5

提供可能なデータ
データ整備方法
データ整備フロー地名辞典の更新
データ更新仕様
データ更新フロー
留意事項
検収方法
権利の帰属
再委託
瑕疵担保責任その他

内容調達する業務の名称
今までの経過調達の目的対象となる業務・データ
依頼範囲
業務として依頼したい内容
依頼期間
納品場所
具体的な成果物名
ユーザの概容（部門・人数等）
対象とする業務、データの利用目的の整理
業務品質として指定する項目
地名辞典の整備仕様(マッチングレベル、住所を識別するキー及び代表点、座標の付与方法)
地名辞典整備にあたって提供可能なデータ
地名辞典の整備方法(利用するデータ等)
地名辞典の整備フロー
地名辞典の更新頻度、仕組み
地名辞典の更新フロー
検収要件
整備したデータの帰属原則は禁止
瑕疵担保の特記事項

74

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

7. 付録

7.1. インタフェース仕様一覧
これらの検討の過程に基づいて定めた GIS ユニットが GIS 共通サービスインタフェースを通じて提供する機能の一覧を以下に示す。それぞれの機能の詳細は、GIS 共通サービス標準仕様を参照のこと。
表７－１ GIS 共通サービス 機能一覧
業務名

機能一覧
機能種類

機能（レベル０１）

GS.1 地名辞典サー
GS.1.1 地名辞典基本機能
ビス利用機能ＧＩＳ共通サービス利用機能
機能（レベル０２）

機能説明

GS.1.1.1 地理識別子検索GS.1.1.2 場所インスタンス取得
GS.1.1.3 場所インスタンス登録
GS.1.1.4 場所インスタンス更新
GS.1.1.5 場所インスタンス削除
GS.1.1.6 サービスメタデータ取得

GS.1.2 場所インスタンス関連機能

GS.1.2.1 地理識別子変換
GS.1.2.2 場所インスタンス関連検索
GS.1.2.3 場所インスタンス関連登録
GS.1.2.4 場所インスタンス関連削除

機能種類

機能（レベル０１）

GS.2 地図表示サーGS.2.1 地図表示基本機能
ビス利用機能機能（レベル０２）

機能説明

必須/任意

必須
必須
任意
任意
任意
任意
任意
任意
任意
任意
必須/任意

GS.2.1.1 地図画像取得

地図表示サービスに対して、地図画像を取得する要求を行う。

任意

GS.2.1.2 地図画像URL 取得

地図表示サービスに対して、地図画像へアクセスするためのURL を取得する
要求を行う。

必須GS.2.1.3 凡例画像取得

地図表示サービスに対して、レイヤの凡例画像を取得する要求を行う。

任意

地図表示サービスに対して、地図画像上より地物の情報を取得する要求を行う。
地図表示サービスに対して、地図表示サービスメタデータを取得する要求を行う。

GS.2.1.4 地物情報取得
GS.2.1.5 サービスメタデータ取得
GS.2.2 主題図機能

地名辞典サービスに対して、検索語句などに対応する地名辞典内の地理識
別子を検索の要求を行う。
地名辞典サービスに対して、地名辞典名称と地理識別子などから、座標などを取得する要求を行う。
地名辞典サービスに対して、地名辞典に新たに地理識別子と位置座標などを登録する要求を行う。
地名辞典サービスに対して、地名辞典で管理されている地理識別子と位置座標などを更新する要求を行う。
地名辞典サービスに対して、地名辞典で管理されている地理識別子と位置座標などを削除する要求を行う。
地名辞典サービスに対して、地名辞典サービスメタデータを取得する要求を行う。
地名辞典サービスに対して、指定された地理識別子情報と関連付けられている地理識別子情報に変換する要求を行う。。
地名辞典サービスに対して、検索語句などに対応する地名辞典内の場所インスタンス関連を検索する要求を行う。
地名辞典サービスに対して、地名辞典に新たに場所インスタンス関連を登録する要求を行う。
地名辞典サービスに対して、地名辞典で管理されている場所インスタンス関連を削除する要求を行う。

任意
任意

GS.2.2.1 主題図画像取得

地図表示サービスに対して、主題図画像を取得する要求を行う。

任意

GS.2.2.2 主題図画像URL取得

地図表示サービスに対して、主題図画像へアクセスするためのURLを取得する要求を行う。

任意75

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

表７－２ 地名辞典サービス インタフェース定義一覧
インタフェース一覧
インタフェース
番号GS.1.1.1
GS.1.1.2
GS.1.1.3
GS.1.1.4

機能（レベル０２）

必須/任意

地理識別子検索場所インスタンス取得
場所インスタンス登録
場所インスタンス更新

必須
必須
任意
任意

GS.1.1.5

場所インスタンス削除

任意

GS.1.1.6

サービスメタデータ取得

任意GS.1.2.1
GS.1.2.2
GS.1.2.3
GS.1.2.4

地理識別子変換
場所インスタンス関連検索
場所インスタンス関連登録
場所インスタンス関連削除

任意
任意
任意
任意

入出力

サービス名

地名辞典

メッセージ定義

ＷＳＤＬ定義IN

SearchPI

OUT

SearchPIResponse

IN

GetLocationInstance

OUT

GetLocationInstanceResponse

IN

AddLocationInstance

OUT

AddLocationInstanceResponseIN

UpdateLocationInstance

OUT

UpdateLocationInstanceResponse

IN

DeleteLocationInstance

OUT

DeleteLocationInstanceResponse

IN

GetCapabilities

OUT

GetCapabilitiesResponse

IN

ConvertPIOUTConvertPIResponse

IN

SearchLocationInstanceAssociation

OUT

SearchLocationInstanceAssociationResponse

IN

AddLocationInstanceAssociation

OUT

AddLocationInstanceAssociationResponse

IN

DeleteLocationInstanceAssociation

OUT

DeleteLocationInstanceAssociationResponse

gisGS01s-2010-01.wsdl
gisGS01s-2010-01.xsd
common-2010-01.xsd

表７－３ 地図表示サービス インタフェース定義一覧
インタフェース一覧
インタフェース
番号GS.2.1.1
GS.2.1.2
GS.2.1.3

機能（レベル０２）
地図画像取得地図画像URL取得
凡例画像取得

必須/任意
任意
必須
任意

GS.2.1.4

地物情報取得

任意

GS.2.1.5

サービスメタデータ取得

任意GS.2.2.1

主題図画像取得

任意GS.2.2.2

主題図画像URL取得

任意

入出力

サービス名

地図表示

メッセージ定義

ＷＳＤＬ定義IN

GetMapOUT

GetMapResponseIN

GetMapUrl

OUT

GetMapUrlResponse

IN

GetLegendImage

OUT

GetLegendImageResponse

IN

GetFeatureInfo

OUT

GetFeatureInfoResponse

IN

GetCapabilities

OUT
IN
OUT
IN
OUT

GetCapabilitiesResponse
GetThematicMap
GetThematicMapResponse
GetThematicMapUrl
GetThematicMapUrlResponse

76

gisGS02s-2010-01.wsdl
gisGS02s-2010-01.xsd
common-2010-01.xsd

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

7.2. 区割り地図の整備・運用
学校区などの区域単位に表計算ソフトウェアなどで集計した台帳情報を、地図を使って色分け表示（ランキング表示）することは、ニーズとして高い。
このことから、様々な台帳情報を関連付けて色分け表示や集計を行うための白図（これを、以下、区割地図データという）を地理空間データとして整備することは有効と考えられる。
区割地図データは、区域単位（丁目（字）､学校区、メッシュなどのポリゴン形状をもった
区域単位）で構成されるもので、台帳情報を関連づけるための鍵（ID）を区域単位で持った、地理空間データである（図７－１参照）。

区割地図
データ
（校区など）

図 ７-１ 区割地図データの位置づけ

図７－２には、区割地図データの利用例として、町丁目単位の区域に台帳情報を関連づけて色分け表示するイメージを示す。

色分け図の例：町丁目界の地図

区割地図データを使った色分け表示の例

図 ７-２ 区割地図データとその利用のイメージ

77地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

7.2.1. 整備が推奨される区割地図データ
自治体のニーズについてのヒアリング調査等に基づき、地域情報プラットフォームでのGIS 構築において標準的に整備することが推奨される区割地図データの種類を、次に示す。
【推奨する区割地図データの種類】•

大字・町丁目界•

学校区（小学校区、中学校区）

•

メッシュ

表７－４及び表７－５に示すメッシュが、国勢調査の統計データや国土数値情報などで利用されている基本的なものである。
表 ７-４ 基準地域メッシュの区分方法
区画の種類
第１次地域区画第２次地域区画基準地域メッシュ
（第３次地域
区画）

区分方法
全国の地域を偶数緯
度及びその間隔(120分)を３等分した緯度における緯線並びに１度ごとの経線によって分割してできる区域
第１次地域区画を緯線方向及び経線方向に８等分してできる区域
第２次地域区画を
緯線方向及び経線
方向に 10 等分してできる区域

緯度の 経度の間
間隔
隔
40 分
１度

1 辺の長
さ
約 80km

５分

７分 30
秒

約 10km

30 秒

45 秒

約１km

地図との関係
20 万分の１地勢
図(国土地理院発行)の１図葉の区画２万５千分の１地
形図（国土地理院
発行）の１図葉の区画

表 ７-５ 分割地域メッシュの区分方法
区画の種類
２分の１地域メッシュ

４分の１地域メッシュ
８分の１地域メッシュ

区分方法
全国の地域を偶数緯度及びその間隔(120 分)を３等分した緯度における緯線並びに１度ごとの経線によって分割してできる区域
第１次地域区画を緯線方向
及び経線方向に８等分してできる区域
第２次地域区画を緯線方向
及び経線方向に 10 等分して
できる区域

78

緯度の間隔
15 秒

経度の間隔
22.5 秒

1 辺の長さ
約 500km

7.5 秒

11.25 秒

約 250m3.75 秒5.625 秒

約 125m地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

メッシュの他に、学校区や町界、大字界の区割り地図のイメージを示す。これらの基となる情報の一部には、国土数値情報等のオープンデータを用いることもできる。公表された情報を元に、時点更新を行うことでより正確な区割り地図を運用することが望ましい。

図７－３ 小学校区のイメージ（国土数値情報 小学校区から）

図７－４ 大字町界の区割り地図と公民館の配置図（西宮市）
本節には、推奨する区割地図データをあげたが、その他の区割地図データ（例えば、選挙区）について、自治体ごとに必要に応じて任意の区割地図データを整備してよいものとする。

79

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

7.2.2. 区割地図データを活用した色分け図の利用イメージ
GIS 共通サービスの活用により、業務データやその集計データから区割地図データを活用した色分け図を取得することができ、本節ではこれらの機能の活用イメージを示す。
図７－５に区割地図データを活用した色分け図の利用イメージを示す。業務ユニットまたは業務アプリケーションが持つ業務データやその集計データは、区割に相当する区域 ID と集計・統計結果である値を保有している。これを GIS 共通サービスを活用することより GIS ユ
ニットが持つ区割地図データに紐付け、値ごとに色分けをした色分け図を取得すると新たな主題図を作成することが可能となる。具体的には、利用者が GIS 共通サービスが提供する地図
表示サービスの主題図画像取得機能または主題図画像 URL 取得機能を利用して地図表示条件を指定することで欲しい画像を GIS ユニット側に要求し、GIS ユニットは指示に基づき画像を提供することで実現するサービスである。
集計データ

区域 ID
1
2
3
4

区割地図データを活用した主題図

値
0.1
20
10
5

GIS 共通サービスの利用

１
４

２
３

図 ７-５ 区割地図データを活用した色分け図の利用イメージ

7.2.3. 区割り地図の表示パターン
以降では、学区ごとの集計データを色分け図表示する以下の 3 つパターンでの利用イメー
ジを示す。
パターン 1：地図表示サービスで実現する場合
パターン 2：地名辞典サービスで実現する場合
パターン 3：地名辞典サービスの応用事例（１） 地図表示サービスで実現する場合
地図表示サービスにて色分け図表示する場合には、予め業務ユニットにて学区 ID 毎に集計した業務データを用いて、色分け図画像を取得する。色分け図を取得するための要求メッセー
ジには学区 ID、スタイル名称などを指定する。業務ユニットまたは業務アプリケーションは取得した色分け図画像を表示すればよい。図７－６に地図表示サービスで実現する場合のイメージを示す。
地図表示サービスで実現する場合の、業務ユニットまたは業務アプリケーションと GIS ユ
ニットの前提条件は以下となる。
【業務ユニットの前提条件】
・色分け図の区域単位を特定する ID（学区 ID）を知っていること

80

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

・色分け図表示を行いたい学区ごとに業務データの集計が予め行われていること
・色分け図表示する際の表示色などのスタイルを決めるものとすること【GIS ユニットの前提条件】
・GIS ユニットの地図データに学区の区割地図データレイヤを保持していること
・表示色などのスタイル定義を保持していること
業務ユニットまたは
業務アプリケーション
集計データ

学区 値
ID
1
2
3
4

0.1
20
10
5

GetThematicMap メッセージ
学区 ID＝1
学区 ID＝2
学区 ID＝3
学区 ID＝4

学区 ID

地図表示サービス
呼び出し処理

ドット
横線
横線
横線

学区 ID ＆ スタイル名
称

色分け図の画
像 １ ２
４

３

色分け図

１

２

４

３

地
図
表
示
サ
ー
ビ
ス
イ
ン
タ
フ
ェ
ー
ス

GIS ユニット

地図データ（学区の区割地図データ
レイヤを持つ）

１ ２

図 ７-６ 地図表示サービスで実現する場合のイメージ
また、図７－６のイメージでは、それぞれの学区に対する表示スタイルを個別に指定したが、学区 ID に対応する集計データの値とスタイルの適用条件（例えば、”値が 5 以上を横線、
1 以下をドット”）を指定することも可能である。

81

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン（２） 地名辞典サービスで実現する場合
地名辞典サービスにて色分け図表示する場合には、学区に対応するポリゴンデータを取得
し、このポリゴンデータに業務ユニットが重畳・色塗り表示することにより実現可能となる。
ポリゴンデータを取得するための要求メッセージには学区 ID などを指定する。図７－７に地名辞典サービスで実現する場合のイメージを示す。
この実現方法は、業務ユニット側にて背景図や他レイヤとの重ね合わせのための仕組みや、
ポリゴンデータに色を塗るための仕組みを別途用意することが必要であり、業務ユニット側の実装負担が大きくなる。
地名辞典サービスで実現する場合の、業務ユニットまたは業務アプリケーションと GIS ユ
ニットの前提条件は以下となる。
【業務ユニットの前提条件】
・色分け図の区域単位を特定する ID（学区 ID）を知っていること
・色分け図表示を行いたい学区ごとに業務データの集計が予め行われていること【GIS ユニットの前提条件】
・学区 ID を地理識別子として地名辞典を保持していること
・地名辞典には地理的範囲としてポリゴンデータを保持していること
業務ユニットまたは業務アプリケーション
集計データ

学区 ID
1
2
3
4

値
0.1
20
10
5

学区 ID

学区 ID

地名辞典サービス
ポリゴンデータ
呼び出し処理重畳・色塗り等の処理

ポリゴンデータ
１ ２
４ ３

地
名
辞
典
サ
ー
ビ
ス
イ
ン
タ
フ
ェ
ー
ス

GIS ユニット

学区地名辞典（地理的範囲としてポリゴンを持つ）

色分け図

１ ２
１
４

２
３
図 ７-７ 地名辞典サービスで実現する場合のイメージ

82地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン（３） 地名辞典サービスの応用事例（１）と（２）のパターンの前提条件である、業務データの学区 ID ごとの集計を行う際にも地名辞典サービスを補助的に利用することができる。地名辞典サービスを利用できる処理は、
地理識別子（住所など）に対応する学区 ID の判定である。図７－８に地名辞典サービスの応用事例を示す。
ただし、学区 ID ごとの集計・統計処理は業務のニーズに応じて多岐にわたるため、これらの処理は業務ユニット側で実装することとする。
業務ユニットまたは業務アプリケーション
元データ

住民番号
住所
1
○○町一丁目 2-3
2○○町一丁目 2-4
3○○町一丁目 2-5
4
…
5
…
6
…
7
…

値
0
0
0.1
10
10
3
2

GIS ユニット

住所

住所

地名辞典サービス

学区 ID
学区 ID
呼び出し処理業務データと学区 ID を紐付けたデータ

学区 ID
1
1
1
2
2
4
4

住民番号
1
2
3
4
5
6
7

値
0
0
0.1
10
10
3
2

地
名
辞
典
サ
ー
ビ
ス
イ
ン
タ
フ
ェ
ー
ス

住所
地名辞典

学区地名辞典（地理的範囲としてポリゴンを持つ）

集計・統計処理
集計データ

学区 ID
1
2
3
4

値
0.1
20
10
5
図 ７-８ 地名辞典サービスの応用事例

色分け図表示処理83地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

7.3. 地方公共団体の地名辞典の整備・運用事例
GIS 共通サービスガイドラインの改版にあたり、地名辞典（住所辞書）の整備に取り組まれ、GIS を活用されている自治体の協力を得て、インタビューを実施した。
インタビューでは地名辞典導入の経緯や整備の際の苦労した点などを伺い、得られたコメントの一部を事例として紹介する。
インタビューでは以下の項目について対話式で質問を行い意見等を伺った。
表７－６ インタビュー項目
１

項目
住所辞書整備を始めた経緯

２

手法

３
４

苦労した点
効果

５

インタビュー自治体における特徴
今後の課題
他団体に向けて

６
７

内容
地名辞典（住所辞書）を整備されたきっかけとなった出来事や、感じていた必要性など
地名辞典整備の際の作業手法や、用いた元資料など
地名辞典整備の際の苦労したポイント
地名辞典を整備して得られた効果、GIS を利用してできるようになったことなど
インタビュー対象の自治体が独自に取り組まれていることなど地名辞典整備後に感じている課題など
他団体に向けてのメッセージ84

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

事例１ 北海道室蘭市「全住民の所在を把握してデータに基づく政策立案を」
室蘭市では、住民の居所の座標を住民基本台帳に登録する居所位置確認システムを導入し、平成 30 年度中の運用を予定されております。
このシステムによって市内の全住民の居所の座標を把握し、GIS を用いて各種の政策立案などに役立てることを予定しています。
居所位置確認システムの開発と導入を先導した ICT推進課に、システムの整備に至る経緯や苦労された点についてインタビューを伺いました。

ICT 推進課 川口陽海主事■住所辞書の整備を始めた経緯
・ICT 推進課は全庁的に GIS の導入に取り組んでおり、庁内各課の業務課題解決について GIS を活用した支援を実施している。
・室蘭市では、政策の企画立案に住民に一人一人の正確な居所の位置情報が必要だと考えていた。住民個人の単位で座標を与えることで、データに基づく政策立案（EBPM）が実現すると考えられていた。
・しかし、住所では同一住所に複数の個宅が所在するケースもあり、住所だけでは居所を特定する情報が不十室蘭市役所分であると考え、個宅の単位での特定が必要だと考えていた。
・個宅の単位で住民の居所を把握する方法として、室蘭市では住民基本台帳の住民情報に座標を付与して管理する方法を採用した。

■整備の手法・平成 29 年度に開発し平成 30 年度に運用開始する居所位置確認システムは、住民基本台帳の住民情報（住所欄の右肩）に座標を併記するためのシステムである。
・GIS において住民地図を使用することを可能とする居所位置と座標のデータ整備の手法は次の通りである。
＜居所位置確認システムの概要＞
・居所位置確認システムは住民の転入・転居の際に、住民が窓口で手続きを行う際に使用する。
・住民は、転入届を記入する前に居所位置確認システムを用いて転居先の座標を取得する。座標の85

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

取得は、窓口でタブレットを用いてシステムを操作する。
・システムの画面には室蘭市の家屋外形などが表示され、住民は転居先の建物を画面で指定して、その場所の座標を確定させる。座標は QR コードに記録されシールプリンタでその場で印刷される。
・住民から転入届や転居届が提出された際に、用紙の備考欄等に座標が入った QR コードのシールを貼り付ける。
・住民窓口の職員は、提出された届を住民基本台

居所位置確認システムのタブレット

帳に登録する際に QR コードをバーコードリー
ダーで読み取り、座標も併せて入力する。
・QR シールを貼るというアイデアは、転入届の保管に用紙を増やさずに済ませる運用で採用した。
・座標の情報は世帯ごとに同じ座標を用いる。
＜これまでの居所位置の整備＞・システム導入前は、住所から機械的に地番等の場所にアドレスマッチングし、GIS 担当職員が全件を近傍の家屋図形の中に移動させて居所の座

QR コードのシールプリンタ

標情報を作成していた。
・運用上、窓口に住民が来られない場合など居所

位置確認システムで位置情報が取得できないケースの場合は、従来通りに GIS 担当職員が住所に相当する位置から家屋を特定して座標を与える運用を残している。

■苦労した点・居所位置確認システムの導入に際して、住民窓
口の部署への庁内調整に説明が必要であった。
・転入・転居の増える 3 月や 4 月において、窓口業務に対する業務量の増大を懸念されたためである。
・財政部門への説明で、住民情報の活用の重要性を理解されたためシステム整備の予算が付いた。予算が付いたことから、窓口の担当課も追って理解を得られた。

QR コードを貼り付けた住民異動届
86地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン■成果
・居所位置確認システムの整備によって、今後の転入・転居者の位置情報の更新の仕組みが確立した。
・従来から進めていた住民基本台帳の全住民の居所の座標について、今後の精度向上が期待できる。

■効果
・室蘭市庁内における様々な場面で住民の正確な情報が入手でき、業務の質の向上が期待できる。
・防災の場面では、住民情報が特に効果を発揮している。
・災害対策本部で GIS 班を立てており、平成 30 年の台風 21 号に備えた警戒本部では避難所開設の際の想定人数の把握に役立てられた。
・過去の被災箇所の位置情報と住民情報を重ねあわせることで、災害警戒時の自主避難所の開設に役立つと考えられる。
・GIS のことを単純な地図を見るシステムだと考えている職員が全庁的に多いが、GIS は分析政策立案に役立つものだと考える職員が増えてきた。

■室蘭市における特徴
・住民の位置を正確に把握するために住民基本台帳に座標を与えるという活動は、ICT 推進課の推進力があったことが大きな要因であり、室蘭市の特徴だと思う。
・GIS に搭載する地名辞典を作成するのではなく、住民基本台帳のデータベースに座標を与えることとした。結果的に全住民の位置を GIS の地図上にプロットできる。
・室蘭市では庁内に GIS のワーキンググループが活動している。ワーキンググループなど庁内からICT 推進課に GIS 関連の相談を受けることが多い。本年度の例では、GIS を活用して白鳥大橋のマラソン大会の立哨員配置や資材配置などを作成し、前回 5 年前の大会時よりも円滑な運用が実現した。
・室蘭市では GIS データに関して地番図やオルソ画像などを当初から全庁利用を目的として整備している。整備は ICT 推進課が担当している。そのため地番図などの利用に際して目的外使用の制限がかからない。現在、オープンデータとして地番図やオルソ画像などの情報を提供中であるが、データ整備時の利用目的の範囲内だと判断している。

■今後の課題・GIS の活用を広く庁内外にアピールしていきたい。
・GIS と住民情報を組み合わせ、立地適正化計画の策定等に GIS を用いた分析によるデータに基づいた政策立案をより進めていきたい。また、そのような GIS の技術の習得を GIS ワーキンググループを中心に行っていきたい。

■他団体に向けて・政策立案に GIS が有であることや、そのために座標を網羅することが必要であることは、GISに詳しい職員においては理解が早いが、そうでない職員には丁寧に事例を示して説明していく必要があると思う。
以上87

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

事例２ 福島県会津若松市「市民課主導で住民ポイントを作成し、全庁で利用」
会津若松市では、住民の窓口となる市民課が主導する形で GIS を導入し、全庁運用を続けています。
最大の特徴として、全市民の住民情報を GIS 上でポイント化した「住民ポイント」を住所辞書相当のデータとして整備・運用している点が挙げられます。
この整備について、市民課が主体として導入することとなった経緯や、現在も運用が継続できている
理由についてインタビューしました。

市民課 伊藤文徳様（左）国保年金課 目黒純様（右）■住所辞書整備を始めた経緯
・東日本大震災と南会津地方の水害の教訓から、ICTを活用した災害時要援護者支援の取組を検討し始めた。
・震災後の被災者受け入れ自治体として、支援体制を整備する必要があり、どのようなシステムが相応しいか模索していた。この際、防災部署は多忙を極めていたため、市民課がその役割を引き受けることとなった。
・当初、市民課では様々な災害・防災システムを検討したが、災害時に円滑にシステムを利用するため

会津若松市役所には、平時から職員が業務に利用する必要があるという考えに至った。
・被災者となる可能性があるのはすべての市民であることや、日常業務における GIS の活用の広がりを考えたときに、住民基本台帳を GIS 上で取り扱いでいる必要であると考え、市民課で住民ポイントを整備する決定に至る。
・平成 23 年 6 月に新潟県柏崎市で開催されたイベントにおいて、住基を使った GIS の活用事例を見て、これまでにない新しい次元からの視点を業務に取り入れることができると気づいたことが、住民の位置情報を整備するきっかけとなった。

■手法88

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

・市民課が中心となり整備を進めるべく、庁内のほぼすべての課にヒアリングを実施し、GIS が活用できるシーンを検討し、整備仕様を作成。
・H24 年度に、総務省の補助事業を活用し統合
GIS の導入や地名辞典の整備を実施。
・地名辞典の整備には、まず商用の住所データベースを用いた上で、アンマッチとなった 2 割程
度のデータについて、消防部門で独自に整備していたデータを基に補完する事でほぼ全てのデータを整備することができた。
市民課が登録した住民ポイントで作成した住民地図の例（データはサンプル）＜地名辞典作成手順＞

・会津若松市の消防部門が保有する情報を元にして当初の情報を作成する。
・消防部門の地図情報は、市の住基から 2 カ月に一度情報提供しており、消防部門の訪問でアンマッチを解消している。
・当初の情報として、消防部門の地図情報を受け取りそれを住民のポイントデータとしてチェックする。全体の 3-4％（5000 件）のアンマッチが発見されたが、その後の市民課の住居表示担
当部門の調査でアンマッチの解消をはかる。
＜地名辞典の維持＞
・地名辞典の更新は市民課で行うこととした。
・市内の 9 箇所にある市民センターなどで住民基本台帳等の更新を受け付けられる。この 9 箇所
で、ネットワーク型の GIS を用いて、住民異動のポイントや世帯番号を記録する。
・毎日の夜間に 9 箇所の窓口で更新した情報を、本 GIS に集約して更新する。

■苦労した点・GIS の整備と住民ポイントの整備の意義や活用イメージについて、これまでに無い概念だったことから庁内での理解を得るまでに時間を要した。
・限られた予算の中での背景地図の選定やシステム運用方法の整理。
・住民ポイントの概念を取り入れた GIS 導入の仕様書の作成。
・住民ポイントを使用した資料を作成する際には、それらを用いた市民参加のワークショップなど
で、個人が特定されることの無いよう配慮する必要があった。
・地名辞典を更新する運用体制の構築にあたっては、住民票の異動届出時に直接市民の方から聞くという運用が最も正確であり、かつ業務ルーチンに組み込む事で更新を確実に行える点や、住民基本台帳は自治事務であることなどの理由から市民課が担当することとなった。この運用について現場からは理解が得られ、特に反対は無かった。

89

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン■効果・あらゆる所属での GIS の利用シーンが具体化してきたこと。
・各種分析を職員の手で行えるようになった事で、品質の向上と費用の削減を両立することができた。分析作業を業務委託する場合においても、市から提供する基礎資料が高度化されたことで、委託業務の成果を底上げすることができた。
・自分たちでできることが増えた。バス停の利用状況の分析を担当職員が自ら GIS を用いて行い、地域住民との協議の際に視覚的・直観的な資料を使用することができた。
・統計処理を行える職員が増加し、分析の内容が高度化してきた。

■会津若松市における特徴
・庁内横断の組織「統合 GIS 活用検討チーム」を設置し、様々な現場の職員による情報共有やスキル共有の場を設けた。
・元々情報システム部門を始めとして「自分たちでやってみる」という気質があり、自ら実践的に
GIS の導入を行い始めたこと。
・住民異動の届の発生源となる市民課が住民ポイントを活用できる GIS の推進担当となったこと。
・毎月の定期的なワーキングチームや、年に一度ある GIS 報告会を通じて、GIS に関わる相談解決や操作説明が行われ、職員の中で普段使いのツールとしての意識が醸成されたこと。
・市民課に情報政策部門出身の職員が 2 人揃ったことも先進的なシステムの導入を円滑に進める一助になった。

■今後の課題・GIS と地名辞典・住民のポイントデータの管理について、可用性向上の課題がある。現在庁内のネットワークのセキュリティ対策のため、住民情報を扱う PC を基幹系ネットワークに移行し、それ以外の PC のネットワークから分断した。これにより、住民ポイントのデータを扱う GIS も基幹系ネットワークに移行され、全職員が利用できるものでは無なくなってしまった。今後は、基幹系ネットワーク以外の PC でいかに不便なく GIS や各種データを扱える体制を構築するのか、可用性の確保が課題になる。

■他団体に向けて・GIS の普及や地名辞典の重要性について組織内で理解を得るには、GIS がもたらす効果や革新性を職員にアピールする場を持つことが重要。
・統合 GIS 活用検討チームでは、年 1 回の活用事例報告会を開催しており、様々なアイデアや事例が現場の職員から報告される。今後の広がりに大きな期待と手ごたえを感じている。
以上

90

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

事例３ 新潟県三条市「費用ゼロ！自作の地名辞典」
三条市では、統合型 GIS の庁内利用に合せて地名辞典の整備と運用が行われています。複数ある地名辞典のうちの１つは消防部署との共同業務を通じて、住民基本台帳の異動情報を月次で更新しながら運用されています。
三条市の地名辞典の整備に至る経緯や苦労された点についてインタビューを伺いました。

情報管理課 山澤浩幸課長（左）■住所辞書の整備を始めた経緯
・三条市では、平成 19 年度から統合型 GIS の運用を開始している。当初は税務課整備の土地地番図と市販の住宅地図の 2 種類のデータを用いて、住所検索等に利用していた。その際、住宅地図の入れ替えを
3 年に一度行っていることや土地地番図の更新が 1
年に一度であることから、地名辞典の更新頻度を高めることが課題になっていた。
・平成 25 年度に住宅地図の更新のタイミングを迎えた際に、住宅地図の購入価格に改定があり、再検討を行うことになった。その際に、毎月の住民異動の三条市役所

情報を緊急指令通知に用いる消防運用システム上で、消防部署が世帯の位置情報を更新する業務があることが分かった。三条市はこれを活用して課題解決ができないかと考え、消防部署が整備しているデータベースを出力して統合型 GIS の地名辞典に反映させることを検討した。
・検討に際して、地名辞典の新規追加は統合型 GISのパッケージ付加機能の追加のみで対応可能なうえ、全世帯の位置情報のポイントを新規にレイヤとしてプロットすることも可能であることが分かった。整備に先立って実施した全庁的な利用ニーズのアンケート結果では有用との意見が多く、消防部署と連携した地名辞典整備を進めることとなった。

91

統合型 GIS で地名辞典を用いて被災世帯調査
結果をプロットした画面（模擬データ）

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン■整備の手法・統合型 GIS に追加となるパッケージ付加機能以外は費用の掛からない導入であった。
・データの整備と更新は全て三条市職員で行っている。
・データの整備手法は以下の通り。
① 情報管理課から消防部署に住民異動リスト（新規、更新、削除の区分を付けたもの）を提供② ①の情報をもとに、消防職員が消防運用システム側の更新作業を実施③ ②の作業後の座標付データを、情報管理課が消防部署から受領④ 座標変換を実施（緯度経度を XY 座標にする）⑤ 統合型 GIS のパッケージの付加ツールを用いて地名辞典のデータベースに更新を反映
・住民異動を基にした地名辞典は、土地地番図や住宅地図の住所情報とは別に整備するものであるた
め、住宅地図の更新等の影響を受けることが無い。
・統合型 GIS 側の作業体制は情報管理課職員 2 名（主担当、副担当）で実施する。作業は 1 人で実施できるボリュームである。
・住民異動の件数は、繁忙期の 3 月~5 月において、各月 300~500 件程度である。このうち、世帯情報に影響のあるデータを地名辞典へ更新している。
・消防部署で管理する地名辞典には、消防が情報検索で必要とする地物（道路や通りの名称、商業ビ
ル名など）の情報も世帯情報とともに管理されている。また、住民基本台帳に未届けの住民（住登外）の情報も消防部署が調査した範囲の内容で含まれている。
・複数の世帯が同居している集合住宅などは、世帯の数のポイントが一か所の建物にプロットされる。

■苦労した点・当初データの整備の際には、消防運用システム側で未更新のデータが相当数あったため、情報管理課の職員が入力作業の支援をして、データを完成させた。
・消防運用システムと統合型 GIS とで座標の記載方式が異なっていたため、無償の変換ツールを用いた座標変換の手順が生じた。
・消防部署へ提供する住民異動リストについて、消防側で不必要な情報を省くこと等、作業上の効率化のために、リストの項目等の調整を繰り返した。

■成果
・地名辞典の整備手順の確立によって、住民異動に対応した世帯情報の地名辞典の利用が可能になった。
・地名辞典の更新は毎月実施するため、地名辞典のタイムラグが 1 年（土地地番図のもの）から 1
か月へと短縮した。
・世帯情報のポイントの位置の精度は、消防部署の入力作業に依存するが、入力された情報についての庁内からの不具合要望などは生じていない。
・世帯情報のポイントの新規入力場所について、住居表示地区など周囲の住所情報から分かる場合は机上で作業を行い、住所の位置情報が不明なものは、消防が現地確認をして登録している。

92

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン■効果・世帯情報と対応した地名辞典を用いることで、アドレスマッチングの精度が格段に向上した。
住宅地図の更新頻度は 3 年に一度のため、時間経過とともにマッチング率が低下するが、世帯情報の地名辞典の更新頻度は毎月であり、精度の低下は見られない。
・活用する資料として、定期更新の要支援者名簿や災害時の被災状況図の作成がある。要支援者名簿
は、災害時の避難誘導や情報伝達が必要な人を地図にプロットしたものであり、支援をする人（民生員、自治会長等）に配布する資料となる。この地図の作成作業は年 4 回（全件登録 1 回、更新 3回）行っており、対象は約 1,400 件である。この 1,400 件は、住宅地図の地名辞典でアドレスマッ
チングを行うと約 1 割がアンマッチとなるが、世帯情報の地名辞典ではアンマッチは生じない（月次の更新タイミングの間にあった異動分のみ注意を要する）。
・アンマッチが解消したことで、毎回の作業時のデータ修正の作業が解消した。
・世帯情報のポイントのレイヤを扱えるようになったことで、災害時の被災箇所から被災世帯数の判定が可能になった。また、通常時においても世帯検索を行う日常業務で利用できるようになった。
・統合型 GIS の活用部署全体で、世帯情報のポイントの可視化ができた。

■三条市における特徴＜既成の運用ルールの活用＞
・過去、情報管理課では住民基本台帳や各種税等の情報システムをプログラム開発を含め自前で運用していた。そのノウハウにより、住民異動に関する情報を適切に抽出し、消防部署へやり取りすることができていること。
・消防部署において、世帯に対応する位置情報を管理するシステムがあったことと、そのシステムからの情報出力が職員によってできる状態であったこと。
・消防部署では従前の業務量を追加させることは無く、異動情報の提供に対するギブ＆テイクが成立していること。
・庁内の情報流通について、データの利活用の手続きは情報管理課が管理部署であり、必要な手続き上の懸念などは生じなかったこと。

■今後の課題・GIS の利活用の事例をより多く把握して、庁内の各部部署へ利用シーンをアピールし、真の「統合型」を目指していきたい。

■他団体に向けて・消防部署が庁内で提供できる情報を管理していることが多いと思う。この情報を活用する事で、ほぼ委託費用を使わずに地名辞典を整備できるのではないか。
以上

93

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

事例４ 兵庫県西宮市「庁内に根差した住所辞書の活用」
GIS の運用に古くから取り組んでおり、現在も全国の自治体をリードする西宮市に住所辞書を利用した、GIS の現在の取組ついてインタビューを行いました。

情報システム課 南晴久課長（左）木村雅人様（右）■住所辞書整備を始めた経緯
西宮市では昭和 50 年代に国主導で都市情報システム（UIS）を導入した。しかし、高額な費用に見合うだけの効果が出なかった点を反省し、基礎自治体が基幹業務で取扱う住民情報と連携した位置座標を同時に管理する必要性を強く認識した。
昭和 59 年度には位置座標方式で地図を扱うシステムを検討開始、昭和 62 年度に住所コードを備えた「宛名データベース」を構築
し、位置座標方式を確立、ホスト中心型のGIS を本格稼働させたが、現場からの評価

西宮市役所が得られず頓挫した。そこで、日常業務で使える GIS を自力で作成するために、平成 4 年度には PC 上で手軽に扱える MapInfo を導入して GISの活用を開始、平成 5 年にはホストからのデータコンバートにより、町別ランキングマップなどを作成、職員自らの手により、行政活動に GIS が活用され始めた。
平成 7 年の阪神淡路大震災では、被災状況や復興資料として、全国で始めて住民情報と連携した
GIS を活用して、全壊世帯分布図、街区別や町別の全壊世帯ランキングマップ、死傷者分布図などを震災直後に作成し、復旧対策や復興活動を行った。これらの資料は、復興時の都市計画、国・議員への陳情資料、復興記録、防災教育等に活用され、住民情報と連携した GIS の効果を広く伝えることとなった。震災直後の市役所機能へのダメージは多大なものがあったが、この危機管理下（緊急時・混乱時）に GIS を有効利用でき、また被災者データベースの構築を成し遂げることができたのは、普段からベンダー任せではなく職員自らシステムを構築できるノウハウを備えていたことが大きい。
震災時に住民（被災者等）の情報を GIS で可視化できたインパクトにより、GIS があらゆる行政業務に利用できることが改めて認識され、西宮市では GIS を各種業務に活用する基盤が用意されていった。平成 15 年 1 月からは庁内に、統合型 GIS 専門部会が発足し、GIS の導入やデータの活用94地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

に関する検討を継続的に実施するようになった。
現在は、情報システム課が管理する庁内ポータルサイトを通じて、職員の PC で扱える「西宮市版地図作成ソフト」やデータを自由にダウンロードできる「クリアリングハウス」、市民公開型の「にしのみや WebGIS」を運用し、住所辞書を活用した GIS を運用している。そこには、日常的に GISを利用することが、緊急時における利用が確実にできることを意図した運用が根付いている。

■地名辞典（住所辞書）の整備手法＜庁内の住所情報の管理部署との連携＞
地名辞典（住所辞書）の整備では、住所の基礎情報として土木調査課と資産税課のデータを用いている。
○土木調査課（住居表示を管理）：フロンテージ、家形管理 （市内の約 9 割の住所）○資産税課（地番を管理）：地番図の管理 （市内の残り約 1 割の住所）
各課は、日常業務における更新情報を課内で常時蓄積し、委託業務を通じて 1 年に一度のデータ更新を行っている。各課の課内で蓄積された更新情報は、情報システム課に年間 2 回集められ、情報システム課の職員が直営で住所辞書の更新を行っている。また、住所辞書の運用時に庁内職員から寄せられたデータの追加・修正要望に対応して、情報システム課担当者が都度対応して、住所辞書の更新を行っている。住所辞書のマッチング率は概ね 100％である。なお、一部には不確定な場所を指す座標が残っているため、庁外向けの資料を作成した際には、住所辞書の利用に関する注意書きを添える運用としている。現在、全 21 万世帯の住所について座標を把握している。
＜精度向上のための工夫＞
住居表示地区において、大きな街区が細分化した際などに、同一の住居表示内に複数の家屋が存在する場合がある。このような個所については、集合住宅の運用で用いている枝番号の欄を利用して、家形の区別を行っている。
（11 桁の住所コードを 15 桁に拡張）
住居表示への枝番の付与は、住民からの希望があれば本人に通知しており、非通知の場合であっても、土木調査課の内部資料では枝番を持っている。現在、土木調査課では重複する住居表示番号は解消しており、今後の住居表示の発行時には重複の無い番号で運用できる。
地番地区について、地番の親番号が同一で集中している箇所を「みなし街区」という扱いでエリアを設定している。地番地区において、新規の住所が見当たらない箇所については、地番から推測される「みなし街区」での座標を付与している。

■苦労した点・GIS のデータ整備の時から手作業で数万件の住所に対して座標を付与してきた。
・100％の住所辞書を目指して精度向上につい務めており、その点で苦労があった。
・地番の地区は、地番の表記と住基の住所表記の不一致が多く、職員が資料を調べて手作業で座標を付与している。
・現在、西宮市では GIS に係長以下 3 名の担当職員を配置し、ポータルサイトや住所辞書のメン
テナンス、システム改善、庁内職員への教育等を行っている。

95

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン■利用場面○被災者支援システムでの管理
・被災者支援システムに住所辞書を導入し、ほぼ 100％の住民の居所を利用できるように運用している。
○消防緊急情報システムへの情報提供
・消防部局へは毎日夜間バッチ処理で住所情報の更新データを送り、情報の共有化を実現している。

運用中の庁内ポータルサイトの画面
職員ポータルサイトからアクセス可能な、庁内で利用できるＧＩＳを集めたページ。リンク集であると同時○庁内ポータルサイト上の各種 GIS の運用に GIS 関連の最新情報が把握できる。

・庁内ポータルサイトには、庁内で作成した
GIS データが「クリアリングハウス」上で共有化されており、職員が自由に利用できる環境が揃っている。
・ポータルサイトには、「西宮市版地図作成ソフト」として、オープンソースの QGIS を基にした GIS ソフトがダウンロードできるようになっており、全ての職員が自身の PC を用いて、各種資料の作成ができるようになっている。
・庁内では、各部署が持つ住民情報を住所辞書と「西宮市版地図作成ソフト」を用いて地図化するなど、日常業務での利用が浸透している。
○座標取得ツールの開設
・庁内ポータルサイトに、「座標取得ツール」を公開しており、住所リストに座標（公共測量座
標、緯度経度、マッチング精度）を付与出来るアドレスマッチングツールがある。
・この座標取得ツールを用いることで、各部署が自らの業務データの住所に座標を付与することが容易になり、「西宮市版地図作成ソフト」を用いた資料作成や分析が促進され、座標付きオープンデータの公開も効率化された。
・西宮市では、公共施設一覧など住所のあるオープンデータには座標を付加するようガイドラインを作成して、利用者の利便性を高めている。
○公開サイト「にしのみや WebGIS」での住所検索
・住民公開型 GIS の「にしのみや WebGIS」の住所検索機能の DB として住所辞書を利用している。
・各部署で運用しているシステムに、「地域安心ネット」、「文化財管理」、「震災写真情報館」、「空き地空き家管理」、「防犯灯・防犯カメラ管理」、「公共施設台帳管理」、「建築申請管理」、「市民自然調査サイト」、「にしのみやデジタルアーカイブ」などがあり、これら庁内外のシス
テムは「にしのみや WebGIS」の API を用いて GIS 連携しており、全て住所辞書を用いている。

96地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン■効果・住所辞書の整備に加えて、「西宮市版地図作成ソフト」を自由に使える環境を整備したことにより、技術系の職員の利用が中心であった GIS が、事務系の職員に自ら率先して利用され始めた。
自分たちの資料を容易に分布図に加工でき、市民向けの資料などに活用している。
・オープンデータについては、住所辞書から座標の情報を付与したデータの方が、他のオープンデータよりダウンロード数が伸びている。2017 年 12 月に従来の平面直角座標第Ⅴ系に加えて緯度経度（ＷＧＳ８４系）を付与したアナウンスをして以来、ダウンロード数が伸びた。

■西宮市における特徴
・各部署の職員が住所辞書から座標を取得することが容易なツールを庁内公開することにより、業
務データの地図への展開や、座標情報を持つオープンデータの公開が進んでいる。
・10 年以上前から、統合型 GIS 専門部会の取り組みとして、庁内 GIS（MapInfo）研修を開催しており、延べ 300 名以上の職員が受講した。2014 年度からは、庁内で「西宮市版地図作成ソフト」研修も開催しており、延 100 名以上の職員が受講している。情報システム課では、庁内の各部署からの GIS に関する問い合わせや資料作成のレクチャの依頼など、GIS に関する多くの要望を随時受け付けている。

■今後の課題・集合住宅用の枝番号を用いる住所辞書の運用について、集合住宅にはこれ以上の枝番付与の余地がないため、運用方法を検討する必要が残っている。
・住基の住所の申請に対して市民課と連携できるのが理想的だが、市民課の業務量を増やさないで協力してもらえる方法を探る必要がある。
・避難所関連のオープンデータは、現在隣接自治体（阪神間）と様式を揃えたいと考えており、今後協議を検討している。
・平成 33 年度に予定している第二庁舎（危機管理センター）の新設に合せて、災害時に利用できるシステムの検討を行っており、それらの中でも住所辞書の活用を考えている。

■他団体に向けて
地名辞典（住所辞書）の整備については、住居表示の GIS データ、地番の GIS データがあれば、まず 8 割は整備可能だと考える。その後は、市職員による不明箇所の調査が必要だが、工夫することで精度の向上を図ることができる。
以上

97

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

事例５ 奈良県生駒郡平群町「やればできる住所辞書」
奈良県生駒郡平群町では、被災者支援システムの導入を切掛けに住所辞書の必要性を認識し、住所辞書の整備に着手しました。住所の辞書の整備にあたり、町で導入済みの統合型 GIS を操作して、自力で全町民の居所建物のポイントデータを作成されました。
住所辞書の整備を自力で行った経緯や手法についてインタビューを伺いました。

政策推進課

内藤潤三 様■住所辞書整備を始めた経緯
・防災対策で被災者支援システム、避難行動要支
援者関連システムの導入が、住所辞書を整備し始めた理由である。
（被災者支援システムでは、住所を元に地図を利用する機能がある。このとき住基にある住所の全ての地点を正確に把握することで、町民の所在を把握できる。そのため、住基にある住所の全ての位置を座標で示す正確な住所辞書が必要になる。
）
・一般的に住所辞書は民間企業が有償で提供しているものを利用するしかないが、住基情報を持たない民間企業は表札の情報から住所辞書を作成す

平群町役場

るしかなく、住基情報と突合すると、位置情報が検索できない地点が 1 割程度は含まれるものであった。
・全ての住民・避難行動要支援者の位置の把握及び適切な支援計画の策定にはマッチング率 100%の住所辞書が必要であり、存在しないものは自力で整備するしかないので 2017 年夏に全町範囲の住所
辞書の整備に着手した。
・当初、町にある地番データや地図データを用いれば概ね一致すると考えていたが、実際に突合してみると想像以上にアンマッチ（住基に記載された住所が存在しない。住所の位置が離れたところにあるなど）があった。
・基礎自治体は住民基本台帳で住民の「住所」を把握しているが、この「住所」は単なる文字列であり、その位置を示すものではない。特に住居表示未実施の地域では、住民基本台帳上の住所とは別の地番に家屋が立っているケースが多く、「住所がわかっても位置がわかるとは限らない」というのが不都合ではあるが、一般的な自治体における現実である。

98

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン■手法
・職員１名による直接作業で実施
・平群町に導入していた統合型 GIS を用いて、GIS データの編集作業を実施する。
・入力の基とした GIS データは 2 種類
平群町の固定資産システムから出力した地番のポイントデータ（地番地区）
国土地理院の住居表示フロンテージのデータ（H29.2）（住居表示地区）<作業手順>（１）用意した 2 種類の GIS データ（ポイント）を、地番地区と住居表示地区に分けて合成し、入力用の元データを作る（２）住所コードの枠を入力用データに与える。
（３）住基システムに記録されている住所文字列を全て取り出し、入力用の元データと突合をさせる。
（この部分の作業は、住基システムの担当者に依頼）→7920 件の住所の中で、7469 件の住所位置が GIS データの中で連携した。
（４）（３）で連携した GIS データ 7469 件については、全ての位置情報を統合型 GIS で表示した空
中写真の家形の中に移動させる。ほとんどは、フロンテージの箇所から近傍の家形への移動で済むが、地番地区では、異動先の家形が不明な個所が多数あった。このような不明は、地区に在住の町役場職員に聞き取って位置を確定させた。
（５）住基の住所が既存の GIS データに存在しなかった 451 件について、GIS データを追加して、位置を確定させた。
（４）と同様に不明箇所の多くは地元の職員への聞き取りで解決した。
なお、住所の位置が不明の原因は以下の通り
・地番地区で分筆等の原因で、住基に記載された住所がアンマッチとなったもの：239 件
・住居表示区域で、同一住居表示内に複数家屋が建築された場合など、枝番付の住所が生じた等の理由によるアンマッチ：212 件（４）（５）の作業は、全数 7920 件すべてのデータに対して確認を行い、2017 年秋に 100％の住所辞書が完成した。
＜作業期間＞
１名の職員での毎日１～2 時間の作業で、2 か月弱で完了した。
全数 7920 件分（集合集宅による共通点を除くと 6671 件）の住所辞書が完成した。

■苦労した点・GIS データの位置登録作業時に、住所コードを用意して（揺らぎの無いように）登録できるようにした。その際、住基に記載されている住所の体系を事前に把握して、必要なコードの桁数を用意することが重要であった。作業では途中でコードの桁数不足が生じ、一度コードを付与し直すことがあった。
・GIS によるデータ編集について、専用のソフトが無く、汎用の統合型 GIS 用いた。初心者からの操作の開始であったが、操作に慣れてくると特に問題はない。

99

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン■効果・当初目的であった、被災者支援システム、避難行動要支援者関連システムに、正確な住所辞書を搭載することができた。

■平群町における特徴
・多数のアンマッチについては、ほぼ町役場の職員への聞き取りで解消した。現地調査が必要だったのは 2 箇所のみ。
・アンマッチとなった原因は、過去の住基データの登録時の記載ミスによるものや、所有者が同じ複数の地番内での新築・建て替えで居所が変更されていながら引越し手続がされていない（郵便などは変更されているが、役場には申請されていない）ことなどであった。

■今後の課題・今後は活用場面を増やしていきたい。
・オープンデータとして住所と座標のデータの公開を検討していきたい。
・データの更新維持に関しては、情報担当が１名で新規ポイント発生時に都度更新を行っている。
これを業務手順として標準化し、組織として継続させていきたい。小さな団体では、業務が属人化しやすい。
・住民課が窓口となって住所辞書の更新を行えるとよい。例えば、住所辞書にない新規住所の申請があるときは、システム上でアラートが出るような仕組みがあればいいと思うが、基幹システムのベンダーとの連携が必要かと思っている。

■他団体に向けて・やってみたら意外とできた！という実感。 7920 件の確認も 2 か月でできた。
・本当に使える住所辞書を作成したら、福祉部門でも利用してみようという機運がでてきた。
・住所辞書は、国や県また民間企業では整備できない、基礎自治体の職員だから整備できる情報である。
・イレギュラーな住所の表記は住基の中に残っており住民が変更申請を出さない限り修正されない。
住所をコード化する際に枝番号等の状況をきちんと整理することが必要。
以上

100

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

事例６ 佐賀県佐賀市「職員提案をきっかけにした住所辞書(地名辞典)の整備」
佐賀市では、「地図上で市民の位置を把握しさま
ざまな政策立案に活用する」という職員のアイデア
が職員提案制度で優秀賞を受賞したことがきっかけ
で、住所辞書の整備が実現し、統合型 GIS や個別
GIS での住所辞書の利用が始まりました。
住所辞書の整備に至る経緯や苦労された点についてインタビューを伺いました。

情報課 矢ヶ部光様■住所辞書の整備を始めた経緯
・佐賀市では、職員からの提案を募集し、優秀な提案については事業化を検討する制度がある。住所
辞書の整備に関する提案が平成 28 年 5 月に優秀賞を受賞し、統合型 GIS を所管している企画調整部
情報課で平成 28 年度内に住所辞書を整備することになった。
・提案は、福祉政策や都市政策の担当者らからの「地図上に人の情報（住基）を展開して政策立案に利用したい」と要望が基になっている。
・庁内で自由に使え、できるだけ最新の状態で利用できる、自前の住所辞書の必要性を感じていた。

佐賀市役所

・住所辞書整備にあたり全庁に照会したところ、次のような利用用途が挙げられた。
＜住民基本台帳を扱う利用用途＞＜住民基本台帳を扱わない利用用途＞• 交通空白地帯の調査• 農地の管理• まちづくりに係る検討分析• 汚水処理状況の把握• 福祉政策に関する調査分析• 文化財位置図の更新■整備の手法・佐賀市では平成 28 年度に統合型 GIS のリプレースの業務を行っており、システムの入れ替えと庁内データの棚卸のタイミングであった。住所辞書は統合型 GIS でも活用できるため、リプレース
関連の予算内で整備を行った。

101

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

・佐賀市で自前の住所辞書を保有することを目標とした。
・住所辞書のデータ整備仕様の作成に際して、APPLIC のホームページを参考にした。
・インプットの情報は、市役所で調達可能な情報を集めて作成する方針とした。
・住所辞書の入力の基情報は以下の通り＜市役所で保有していた情報＞
・町字界データ
・地番図データ
・家屋図データ
・住居表示地区 地番対照表データ（一部地域のみ）
・住民基本台帳データ（住所データ）＜その他使用した情報＞
・住居表示フロンテージ（国土地理院）■苦労した点・データ整備に際し、佐賀市では住居表示に関する情報は電子化されていなかった。また、住居表
示地区の地番対照表データは、一部区域では適切な資料を提供できなかった。そのため、住居表
示と地番の対応表の精査に工数がかかった。また、データ整備の際に、住基に登録されている住所を利用してテストを行ったところ、主に次のような理由でアンマッチが発生した。
＜アンマッチの傾向＞
・今は使われていない大字名や小字が住所に記載されている・官有地・無番地・合併地等が住所に記載されている・住所のフィールドに方書情報が入っている（○○方、○○マンション等）
・住民が認識している住所と、家屋が存在する地番が異なる
・同一の住所に複数の家屋がある等
最も多いアンマッチのパターンは、一つの住所に複数の建物がある場合である。原因としては、複数家屋に同一の住居表示番号が付与されている場合や、筆界未定の土地に複数家屋が存在している場合などがある。また、住民が敷地内に家を建てた際に土地の登記（分筆等）を異動させていない場合などもあった。
＜アンマッチの解決方法＞
・建物ポリゴンが複数の土地（地番）にまたがる場合は、面積按分を行い、比率の大きい方の住所を採択した。
・同一の住所に複数の建物が存在する件については現状のデータ状況を受け入れている。アンマッチについては、運用を行いながら調査をして解決していく方針とした。
・資産税部門の家屋図にはデータ整備の際には使用しなかった属性があり、今後アンマッチ解決に使用できる可能性がある。

102

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン■成果・住所辞書として、家屋（建物ポリゴン）と土地（地番）に対して、｛「地番」－「住居表示住所」－「座標」｝の 3 つ組の変換テーブルを作成した。
・網羅率がほぼ１００％である住所辞書を搭載することができた。
住所から座標への変換⇒ 漏れは 1%未満（今は廃止された大字など）
59267 件中 40 件対象となる建物図形が複数候補存在する住所 ⇒ 48％程度：59267 件中 28223 件（ただし、近傍の位置特定ができることから地域分析等の利用上は十分とした。
）
・佐賀市の統合型 GIS は内部情報系のネットワークで運用しており、このネットワークでは住基からそのまま出力した情報の取り扱いができない。今回整備した住所辞書は、情報課内のセキュ
リティ区画内にある、個別 GIS が利用可能なスタンドアロン端末 1 台で分析用に扱えるようにした。また、統合型 GIS へも住所辞書のセットアップを行い、内部情報系のネットワークで事務を実施できる用途の範囲であれば、統合型 GIS での利用も可能とした。

■効果＜委託費用節約＞
・今回の住所辞書の整備は、155 万円の委託費用で作成した。この成果を用いて、公共交通
空白地調査を GIS で実施した。この公共交通

高齢者の世帯の住所をアドレスマッチング

バス停

空白地調査は、過去 5 年に 1 度の頻度で業務委託を行っていたが、住所辞書の整備によって直営で行え、委託業務費用を節約できた。
＜分析機会、可用性の向上＞※図はイメージです

・公共交通空白地調査と同様の分析については、住所辞書を用いた交通空白地調査の業者に委託せずに庁内でいつでも実施できる

画面イメージ

環境ができた。
＜新しい活用アイデア＞
・住所辞書を利用する GIS の活用アイデアについて、職員から情報課に問い合わせが増えた。単
独高齢者世帯からの将来の空き家発生の予測、ハザードマップと人口メッシュの分析など。
・空き家調査の調査前候補地の作成に使用した際は、予想よりも件数が多くでるなど、分析をしてみて分かることもあった。
・情報課に寄せられる相談は、毎月の運用定例会で報告し共有するようにしている。

■佐賀市における特徴＜庁内での着想や合意形成＞
・GIS に関して、福祉部門、都市政策部門、資産税部門等の職員による自発的なワーキングがあり、普段からアイデアの蓄積があったこと。
・佐賀市役所の職員提案制度を用いたことで、副市長説明の機会が得られたのち検討指示が通知

103

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

され、庁内でのプロジェクト進行がスムーズになったこと。
＜統合型 GIS＞
・佐賀市では全職員が統合型 GIS を利用できたため、住所辞書の必要性に気が付いた職員が出やすかった。定期的に GIS の操作講習会が行われており、ボトムアップ的に利用ニーズが広がってきたと感じる。
＜住所辞書の維持を担う責任部署＞
・職員提案制度によって発足したプロジェクトには担当部署が割り当てられる。住所辞書整備については、情報課が担当部署となりデータ整備とその後の運用を任されている。

■今後の課題・委託の業務の成果として、職員が統合型 GIS や個別 GIS を利用してデータを更新するための手順書を作成した。今後は手順書を活かして住所辞書のメンテナンスを行っていく。
・メンテナンスについて、庁内から情報を集約する運用ルールを今後のために残す必要がある。
・オープンデータに公表するデータへの座標付与ニーズがある。

■他団体に向けて・スモールスタートをお勧めする。最初から 100%のものを目指すのではなく、運用しながら精度向上を行っていってもよいのではないか。まずは GIS や住所辞書で出来ることを職員に知ってもらい、庁内での活用例を増やし、精度の向上を求める声が増えてくれば、予算を計上するチャンスになる。
・できるところから成果を示して、組織や上長にアピールすることが重要だと考えている。

以上

104

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

7.4. 用語集
用語

掲載頁

説明
地理・空間に関連付けられた情報。地理空間情報活用推進基本法では、次の二項目が定義されている。１．空間上の特定の地点又は区域の位置を示す情報（当該情報に係る時点に関する情報を含む。）２．上記の情報と、上記の情報に関連付けられた情報からなる情報。

地理空間情報1

業務ユニット間インタフェース

1

APPLIC が定めた標準仕様を用いた、業務ユニットの間で行う情報の授受方式の取り決め。

2

地域情報プラットフォームとは、様々なシステム間の連携（電子情報のやりとり等）を可能にするために定めた、各システムが準拠すべき業務面や技術面のルール（標準仕様）のことで、地方公共団体においては、地域情報プラットフォームを活用したシステム再構築を行うことで、業
務・システムの効率化や、マルチベンダー化が期待される。

地域情報プラットフォーム
標準仕様

2

地域情報プラットフォーム標準仕様は、APPLIC が定める
自治体業務システムにおける情報連携の標準仕様の総称のこと。住民基本台帳や税務、福祉や防災、教育、GIS 等の分野で利用され、住民基本台帳を始めとする２６業務の情報システムについて「自治体業務アプリケーションユニ
ット標準仕様」が策定済みである。

地名辞典

3

業務情報の見える化のために場所を表す地名や住所とその位置（座標）が対になったデータベース。

3「GIS ユニット」は、地域情報プラットフォームにおける「GIS 共通サービス標準仕様」の GIS 共通サービスを実装したもの。GIS 共通サービスにより、業務情報と位置情報を連携させた見える化が実現できる。

5「GIS 共通サービス」は、「GIS ユニット」が提供し地域情報プラットフォーム上の業務ユニットなどが共通的に利用可能なサービスであり、「地名辞典サービス」と「地図表示サービス」の 2 種類で構成される。

住民地図

5

GIS 共通サービスを導入することで、自治体業務において運用管理される業務情報に位置情報を付加し、その所在を見える化できる。このように住民に紐づく業務情報が見える化された地図のことを「住民地図」と呼ぶ。

GISDB

6

地名辞典や地図などの GIS ユニットが扱う地理空間情報のデータベース。

7

GIS 共通サービスに備えるサービスで、GISDB 内で管理される地名辞典のデータを検索し、住所などの地理識別子に対応する位置（地理座標＝緯度・経度など）を提供するサービス。

地域情報プラットフォーム

GIS ユニット

GIS 共通サービス

地名辞典サービス

105

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

7

GIS 共通サービスに備えるサービスで、地域情報プラット
フォーム上の業務ユニットなどから要求された条件に応じて、GISDB 内の地図データを地図画像として提供する
ためのサービス。

7

地物を一意に識別するラベルまたはコードの形式の空間参照。用語は、場所を特定するための地名などの情報として、ISO/CD19112 に規定されている。

主題図画像

7

統計情報などを利用目的に合わせて編纂して配置した地図。主題図画像は、GIS 共通サービスの機能を用いて作成した主題図の画像のこと。

共用空間データ

9

統合型 GIS において、庁内の複数部署で様々な用途に利用可能な共用性の高い地理空間情報のことを示す。

統合型 GIS

9

統合型 GIS とは、「地形図を使用者全員で共有し、同一のものを使用することで効率化を図る」仕組みのこと。

住民基本台帳14

住民基本台帳とは、市町村長または特別区区長が、住民全体の住民票（個人を単位として作成）を世帯ごとに編成し作成する公簿である（住民基本台帳法第 6 条 1 項）。氏名、生年月日、性別、住所などが記載された住民票を編成したもので、住民の方々に関する事務処理の基礎となるもの。

オンプレミス

20

企業や団体などが情報システムのハードウェア等の設備を自身で保有し、自身の設備において運用すること。

クラウド

20

クラウドコンピュータで提供されるサービス。サーバ管理などの管理負担が不要になる利点がある。

20

LGWAN-ASP サービスは、LGWAN という非常にセキュアなネットワークを介して、利用者である地方公共団体の職員に各種行政事務サービスを提供するもの。LGWAN
は、地方公共団体情報システム機構が管理する総合行政ネットワークのこと。

地理空間情報活用推進基本法

26

地理空間情報活用推進基本法（平成 19 年 5 月 30 日法律第63 号）は、地理空間情報の活用の推進に関する施策を総合的かつ計画的に推進することを目的として制定された法律。

測地座標系（緯度経度座標）49

地球上の位置を示す方法の一つ。基準面となる準拠楕円体とその表面の緯度と経度を用いた座標の体系。

49

地球上の位置を示す方法の一つ。ごく限られた範囲について、準拠楕円体を用いず疑似的に平面上の座標を使用して示す座標系。日本では公共測量などで、19 か所の原点を使用した平面直角座標系が用いられる。

49

現 在 日 本 で 使 用 さ れ て い る 準 拠 楕 円 体 （ TRF 座 標 系
GRS80 楕円体）を使用した測地測量成果の基準（2018 年
現在）。

地図表示サービス

地理識別子

LGWAN-ASP

平面直角座標系

日本測地系 2011（世界測地系）

106

地域情報プラットフォーム標準仕様 ＧＩＳ共通サービスガイドライン

52

地方公共団体が固定資産税務等の行政業務のために整備した家屋の配置地図。家屋図形を概ね地理情報レベル 1000程度で整備したもの。

空中写真

52

地方公共団体が自治体の行政区域の現況把握等を目的として航空機などから地表を撮影し、地図と重ねられるように加工した写真。

街区代表点

52

地理識別子の街区が示す位置として、対象の街区を示す位
置を座標などの GIS 上の点で示した箇所。

58

建築確認とは、建築基準法に基づき、建築物などの建築計
画が建築基準法令や建築基準関係規定に適合しているかどうかを着工前に審査する行政行為。

土地代表点

59

地理識別子で示された土地の位置を示す代表点。本書では土地の区画を示す地番や、住居表示の番号の示す街区上の位置として使用する。

住所識別番号60

住所の文字列のあいまいさを回避するために行政内部でコード番号を付与して用いる住所と対応する番号。

住居表示台帳68

街区（住居表示の○○丁目○○番）ごとに作成した街区内の建物その他の工作物の住居番号が確認できる台帳。

住居表示システム69

住居表示台帳に記載される情報を検索、登録、更新等を行うシステム。

家屋図

建築確認

107