アーキテクチャ標準仕様V3.2

アーキテクチャ標準仕様

V3.2

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

アーキテクチャ標準仕様V3.2

目次
本書の位置づけ .......................................................................... 1
１．策定の背景 .......................................................................... 3
１．１ 電子自治体の推進 ................................................................................................................................. 3
１．２ ユビキタスネットワーク社会に向けての課題 ................................................................................ 4
２．課題解決の方向性 .................................................................... 5
３．地域情報 PF に求められる要件 ......................................................... 6
３．１ 地域情報 PF の要件.............................................................................................................................. 6
４．実現するためのアーキテクチャ ........................................................ 7
４．１
４．２
４．３
４．４
４．５
４．６

アーキテクチャおよび技術標準の採用方針 .................................................................................... 7
地域情報 PF の全体アーキテクチャ .................................................................................................. 8
業務ユニット...................................................................................................................................... 10
開発 ..................................................................................................................................................... 15
サービス基盤...................................................................................................................................... 15
地域情報 PF の実装イメージ ............................................................................................................ 47

５．採用する技術標準 ................................................................... 49
５．１ 採用する標準...................................................................................................................................... 49
５．２ 技術マップ.......................................................................................................................................... 49
５．３ 地域情報 PF におけるオプションの考え方 .................................................................................... 50
６プラットフォーム通信における MEP とエラー時の対応処理 ............................... 51

７．用語集 ............................................................................. 52
７．１
７．２
７．３
７．４
７．５
７．６

ユニット、システム等の考え方－用語の意義 .............................................................................. 52
ユニット、システム等の考え方－用語集 ...................................................................................... 52
申請データ、様式の考え方－用語の意義 ...................................................................................... 53
申請書の考え方－用語集 .................................................................................................................. 53
その他用語.......................................................................................................................................... 54
差し替えの定義.................................................................................................................................. 55

アーキテクチャ標準仕様V3.2

修正履歴(アーキテクチャ標準仕様 V3.1 から V3.2)
項番

該当ページ

修正概要

備考

1

1,24,31,33

クラウド間の定義を追記

211,12,13,33,34

検討テーマ(即時性要件)による見直し

335,36,39

誤植修正(保障456

Copyright 修正(2016 → 2018)5全頁

ページヘッダ修正(V3.1 → V3.2)

6

14,42,43

図表の再作成→保証)

アーキテクチャ標準仕様 V3.2

本書の位置づけ
地域情報プラットフォーム標準仕様（以降、地域情報 PF 仕様と表記）は、業務モデル標準、サービ
ス協調技術標準の仕様、およびガイドライン一式である。
本書「アーキテクチャ標準仕様」は、サービス協調技術標準の仕様に位置づけられ、地域情報プラットフォーム（以降、地域情報 PF と表記）のアーキテクチャを規定するものである。

図０．１

地域情報 PF 仕様の体系

本標準仕様書における表記の説明
・サイト内とサイト間の仕様差異の表現方法
本仕様書においてサイト内とサイト間、クラウド間で仕様に差異がある場合の表記方法を下記に示す。
【サイト内】の定義【サイト間】の定義： 自治体内システム間を連携する場合の仕様を規定する箇所を識別する： 自治体間や自治体と民間のそれぞれのシステムを連携する場合の仕様を規定する箇所を識別する【クラウド間】の定義 ： 同一自治体内システムにおいて、連携する業務システムの一方または、双方が自庁舎外のクラウド環境に置かれている場合に、サイト内とは異なる仕様を規定する箇所を識別する【共通】の定義： サイト内とサイト間、クラウド間で同一の仕様を規定する箇所を
識別する

‐1‐

アーキテクチャ標準仕様 V3.2
・PF 準拠確認チェックルール表記の説明
PF 準拠確認チェックルールとは、地域情報 PF のサービス基盤の機能を本仕様書で定めた規定事項にそって機能単位で列挙したものである。これはベンダ等が提供(または提供を予定)する各種システム製品が、地域情報 PF 仕様に準拠しているかどうかの確認に利用することができる（PF 準拠についての詳細は、「地域情報プラットフォーム準拠確認及び相互接続確認仕様」を参照）。
PF 準拠確認チェックルール表記方法を下記に示す。

◆準拠ルール識別番号 : 準拠ルールを識別するための番号◆準拠ルール本文: 準拠ルールの内容を表す文◆準拠ルール本文の語尾 : 準拠ルールが（必須）、（オプション）、（推奨）のいずれかを表す◆章節項番号

記載例: 準拠ルールの元となった仕様書の本文の記載箇所を特定するための章、節、項の番号：＜＜準拠ルール＞＞【共通】(CS-R020001) ：(CS-R020002) ：【サイト内】(CS-R020008) ：【サイト間】(CS-R020010) ：TCP/ IP による通信が可能である。（必須）[ 2.2.1 ]HTTP は、HTTP 1.1 を使用する。（必須）[ 2.2.1 ]・・
データ交換システムパターンのサポートはオプションである。（オプション）[ 2.3.2 (2) ]・
データ交換システムパターンのサポートはオプションである。（オプション）[ 2.3.2 (2) ]・‐2‐

アーキテクチャ標準仕様 V3.2

１．策定の背景
本章では、地域情報 PF における本書の策定の背景について記述する。

１．１ 電子自治体の推進2010 年 5 月、高度情報通信ネットワーク社会推進戦略本部いわゆるＩＴ戦略本部が「新たな情報通信技術戦略」を策定いたしました。この戦略の中の 3 本柱の一つに、国民本位の電子行政の実現があります。その具体的取組の一つとして、全国共通の電子行政サービスを実現するために、クラウドコンピューティング技術を活用した情報システムの統合集約化などとともに、地方
自治体相互間における標準仕様を活用したバックオフィス連携と業務プロセスの改革等を推進するとしています。
また、2010 年 6 月に閣議決定されました「新成長戦略」では、21 世紀の日本の復活に向けた
21 の国家プロジェクトの一つとして、「情報通信技術の利活用の促進」が掲げられ、「自治体クラウドなどを推進するとともに、週７日 24 時間ワンストップで利用できる電子行政を実現し、国民・企業の手間（コスト）を軽減するとともに、医療、介護、教育など専門性の高い分野での徹底した利活用による生産性の向上に取り組むことが急務である」とされています。
さらに、２０１３年６月に閣議決定された「世界最先端 IT 国家創造宣言」では公共サービス
がワンストップで誰でもどこでもいつでも受けられる社会の実現としてクラウドの活用や社会保障・税番号制度（以下「番号制度」という。）の導入を見据え、業務改革を計画的に進め、利用者が望むワンストップサービスやモバイルを通じたカスタマイ
ズ可能なサービスなど利便性の高いオンラインサービスを提供するとともに、効率的な行政運営を実現すると述べられています。
番号制度の導入は自治体保有の多くの業務システムに影響があるとともに、団体間の情報連携を前提とした業務プロセスのありようにも大きな変化をもたらすものです。
地域情報プラットフォームではこのような社会情勢の変化にあわせ、自治体への番号制度導入
を円滑に進め、これまでの地域情報プラットフォーム対応で培われた庁内の情報連携と一体的な対応が可能となるよう仕様拡充を進めました。
中間サーバとのやり取りに必要となる情報項目と庁内の各業務ユニットが管理する情報項目との整合性確保はもちろん、通信技術要件の互換性、番号制度の要となる団体内統合宛名と地域情報プラットフォーム標準仕様との関係性等を明確にし、地域情報プラットフォームに対応することがそのまま番号制度に対応することにつながる標準仕様としました。

出典：一般財団法人全国地域情報化推進協会「地域情報プラットフォーム基本説明書」より
以降、複数サイトに跨る将来的な課題および自治体における課題を記載する。

‐3‐

アーキテクチャ標準仕様 V3.2

１．２

ユビキタスネットワーク社会に向けての課題

１．２．１

複数サイトに跨るサービス連携に対する課題

近年のインターネット、ブロードバンドおよび携帯ネットワーク端末の爆発的普及に伴い、ネット
ワークを利用した各種サービスが自治体・民間を問わず様々な形で提供されるようになってきた。将来的には、更なるサービスの充実が見込まれ、利用者が窓口へ直接出向いたり書類に記入したりすることなく、情報端末からの簡便な入力で容易にサービスを享受することが広い範囲で可能となるだろう。例
えば利用者の住居の引越しなど、生活の環境や状況の変化に伴うサービス提供者への個人情報の変更や申請（電気・ガス・水道の解約および新規申し込み、自治体への転入・転出届、児童手当の認定請求など）は多岐に渡っている。
しかし、現状では、それら様々なサービスの提供状況を、利用者自身がすべて把握した上で必要なものを適切に取捨選択し、それぞれを個別に正しく順を追って処理していかなければならないなど、本来期待される利用者の利便性という観点では、未だ不十分なものであるといえる。また、今後のサービスの増加により、さらにサービスの利用が複雑化していくことも懸念される。
さらには、u-Japan 政策による「いつでも、どこでも、何でも、誰でもネットワークに繋がるユビキ
タスネットワーク社会」の実現を視野に入れると、これからはネットワーク上で提供されるサービスそのもののあり方を改めて見直さなくてはならない。我が国が推進する施策の本質的な部分の更なる向上を目指していくためには、ネットワーク上に散在する個々のサービスが適切に連携し、利用者にとって真に利便性に優れた高付加価値サービスの提供が必須であり、それを実現するためのプラットフォームとなるサービス基盤技術の確立が急務となる。
ところが、サービスを提供する個別のソフトウェアが市場ニーズに応えるべくますます高機能化する
一方で、ユーザに利便性を高めるために個別のサービスを連携させる試み、また、安心・安全なシステ
ムを構築するための工夫が個別に行われている。すなわち、現在、提供されているサービスは、単一サイトに閉じた形で他サービス連携を考慮していないものが多く、複数サイトに跨った取り組みがほとん
ど見られない。
以上のことにより、ユビキタスネットワーク社会の実現に向けて、複数サイトに跨る際の課題を解決するための要素技術の研究開発およびサービス基盤としての全体技術の確立に向け NICT 委託研究にて研究開発が行われた。

１．２．２

自治体内での課題

前節に至るまでには単一サイト内での課題を解決する必要がある。特に自治体が提供する行政サービ
ス向上およびコスト削減を実現しなければ、ユビキタスネットワーク社会の実現に至ることはできない。
ベンダおよび地方公共団体が集まった全国地域情報化推進協会では、自治体における現状の課題を解決することの必要性を述べている。
（１） 多様化する住民ニーズへの対応
 住民の利便性向上
 教育・医療・防災サービスの充実（２） コストの削減
 IT 経費の削減
 庁内事務の効率化‐4‐アーキテクチャ標準仕様 V3.2

２．課題解決の方向性
前項で述べた課題を地域情報 PF により解決し、高付加価値サービスの実現を目指す。地域情報 PF 仕様では、高付加価値サービスを図２.１のワンストップサービスと位置づけている。
実現に向けては、地域情報 PF をポータル事業者、自治体、民間企業などの各サイトに導入し、通信方式を統一させて相互接続を可能とする。

電子的に
アクセス

【民間会社：SaaS】
SaaSの
利用

従来窓口
へ来庁
官民連携
ﾜﾝｽﾄｯﾌﾟ

自治体内
ﾜﾝｽﾄｯﾌﾟ【ポータル事業者】

地域情報PF

電子申請

【自治体】

地域
ポータル
（引越し等）

児童手当

既存窓口

自治体
ポータル

電子申請

総合窓口
（新）

【他自治体】

住基

児童手当

情報提供
ネットワーク
住民税

地域情報PF
申請データ

異動データ
参照窓口
（新）

地域情報PF
自治体引越
しｻｰﾋﾞｽへ振り分け

民間ｻｰﾋﾞ
ｽへ振り分
け

従来窓口
へ来庁

課税紹介

【民間会社：ガス、水道、銀行等】
既存窓口
行政サーﾋﾞ
申し込み

地域情報PF

職員ポータル

従来業務ｽの利用(可能性？)

地域情報PF

地域PFと独
自PF変換
地
域
情
報
PF

【民間会社：ASP】

ＧＷ

ASP業務

独自PF(BPM)

民間プロトコル

民間他

住民／企業
従来(既存)
サイト個別ﾜﾝｽﾄｯﾌﾟｻｰﾋﾞｽ
官民連携ﾜﾝｽﾄｯﾌﾟｻｰﾋﾞｽ

民間ｻｰﾋﾞｽへ振り分け

原課／窓口職員

図２．１ 課題解決の方向性（ワンストップサービスの実現）‐5‐

アーキテクチャ標準仕様 V3.2

３．地域情報 PF に求められる要件
３．１

地域情報 PF の要件

３．１．１

要件定義の目的

地域情報 PF の構築にあたっては、「サービス利用者」「サービス提供者」「システム調達者」といった、様々なステークホルダの観点が関わる。よって、地域情報プラットフォーム標準仕様、ガイドライン(指針)の策定において、まず『どのような要件が求められているのか』を定義する必要がある。

３．１．２

地域情報 PF の要件

地域情報 PF は高付加価値サービスを提供し、マルチベンダ化を図ることができるものである。

地域情報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 の段階について】
第 1 段階
業務ユニットの定義
第 2 段階
業務ユニット間のデータ交換
第 3 段階業務サービス連携
第 4 段階自治体内におけるワンストップサービスの実現
第 5 段階自治体間、民間連携におけるワンストップサービスの実現
地域情報 PF 仕様では、第 5 段階までを対象とする。

‐6‐

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

（（自治
自治体
体間）
間）

民間

（官 民連携
民連 携））【標準 対象】
・PF共通機 能地域も含めたﾜﾝﾝｽﾄｯﾌﾟｻｰﾋﾞｽのための認証やﾌﾟﾛｾｽ連携のため、PF共通機能仕様の明確化

アーキテクチャ標準仕様 V3.2

４．実現するためのアーキテクチャ
４．１

アーキテクチャおよび技術標準の採用方針

地域情報 PF の各規格領域において、以下の①から④の観点で技術標準を採用する。
また、いったん採用した仕様も、定期的に見直しを行う。
① 標準化団体にて標準化が確定している。または、検討中の仕様
ただし、標準化されていない仕様を参照している場合は、対象から削除する。また、標準が確定していない場合、下記の観点の仕様を採用の対象とする。
・標準化団体で標準化済仕様の次期バージョンアップ仕様
・標準化団体で策定中の新しい領域の標準化候補仕様
・NICT の本関係研究成果の仕様②

ライセンスフリーの考え方を基本とした仕様③

自治体および地域情報化で実現性が高い仕様
国内の人が使えるものであり、オープンソースの実装があるものや、多くのベンダが採用し製品出荷がなされるもの④

標準仕様や相互接続ガイドラインで、相互接続の仕様が存在する仕様
可能な限り製品間での相互接続の実績があるもの‐7‐

アーキテクチャ標準仕様 V3.2

４．２

地域情報 PF の全体アーキテクチャ

地域情報 PF は、業務ユニット、サービス基盤、開発、運用から構成されるものとする。図４．１に、地域情報 PF の全体アーキテクチャを示し、各要素を構成する機能および基本要件を示す。

利用 者（住民）

業務ユニット ⑨
フロン ト系
業務ユニット＜ポータル事業者＞＜Ａ自治体＞

バック系
業務ユニット共通系
業務ユニット業務ユニット間
業務ユニット間 業務ユニットインタフェース
インタフェース
イン タフェ ース 業 務サービスインタフェース

開発

⑧

⑥

地域ﾎﾟｰﾀﾙ統合ＤＢ機能サービス基盤サービス基盤サービス基盤＜民間企業＞

PPF通信機能
F通信機能

セキュリテ ィ 高信頼性通信

SS

EE

・・・

運用

③

プロセス制御メッセージ交換パターン

ユーティリティ

認証・認 可・・・

民間業務アプリサービス基盤サービス基盤⑩④＜Ｂ自治体＞＜Ｂ自 治体＞

モニタリング・・・⑤

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

ワンストップワンストップ
関連
定義
関連定義

②
ＳＯＡＰ

ＢＰＭ機能
ＢＰＭ機能

PPF共通機能
F共通機能

①

業務
ユニット

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

図４．１ 地域情報 PF の全体アーキテクチャ

図中の番号は表４．１に示す基本要件の番号と対応している。

‐8‐

⑦

シ
ステム運用
システム運用アーキテクチャ標準仕様 V3.2
表４．１ 基本要件
分類

要素を構成する機能

基本要件

業務ユニット⑧個別の業務モデル標準仕様等（例：自治体業務 APU 標準仕様、GIS 共通サービス標準仕様、教育情報 APU 標準仕様、防災業務 APU 標準仕様）で定義された業務ユニット間インタ
フェースに準拠すること⑨個別の業務モデル標準仕様等（例：自治体業務 APU 標準仕様、GIS 共通サービス標準仕様、教育情報 APU 標準仕様、防災業務 APU 標準仕様）で定義された業務ユニットに準拠する
こと

開発①ワンストップサービスを実現するために必要となる各種記
述（ワンストップ関連定義（ビジネスプロセス定義、インタ
フェース定義、メッセージ定義等））ができること②業務ユニット間のデータ交換および、自治体内、自治体
間、民間企業の業務サービスを連携できるようにする。添付
ファイルが扱え、セキュリティ機能とともに使用できること

BPM 機能(ビジネスプロセス
管理機能)③各種記述で定義された業務サービスのプロセス連携（順次実行）ができること

PF 共通機能異なるサイトに跨った業務サービスを連携する際に必要とな
る共通的な機能であり、以下の機能を提供できること④業務サービス連携において、不正使用や情報流出をしないための認証・認可機能や、セキュリティ機能⑤業務サービス連携において、ビジネスプロセス、サービ
ス、リソース全体の実行状態を監視するモニタリング機能⑩共通に使用するユーティリティ機能

統合 DB 機能⑥業務ユニット同士がデータ交換（情報を共有または連携）できるための機能を有すること。その実装方式は規定しない
が、統合 DB 機能が提供するインタフェースは本標準で規定する方式になっていなければならないこと⑧自治体業務アプリケーションユニット標準仕様に準拠した
インタフェースとすること

サービ ス基盤

PF 通信機能運用⑦地域情報 PF 導入時の運用設計～実施を行うこと（標準化対象外）
例） ・業務運用方式に依存したリカバリ、リスタート方式
・地域情報 PF 導入時の段階的移行方式

上記地域情報 PF の基本要件は最終形を想定している。
各ベンダが提供する地域情報 PF サービス基盤および業務ユニットの仕様準拠性の判断については、
相互接続性の検証の観点から順次決定していくこととする。

‐9‐

アーキテクチャ標準仕様 V3.2

４．３

業務ユニット【サイト内】
業務ユニットは、個別の業務モデル標準仕様等（例：自治体業務 APU 標準仕様、GIS 共通サービス
標準仕様、教育情報 APU 標準仕様、防災業務 APU 標準仕様）で定義されるものである。以下、アーキ
テクチャ標準仕様に関係する部分を記す。

４．３．１

業務ユニットの分類

業務ユニットは、フロント系業務ユニット、バック系業務ユニット(基幹系業務ユニット、内部管理系業務ユニット)、共通系業務ユニットに分類される。
地域ポータルサイト• 複数サイトに跨るサービスを提供する際に、住民とのインタフェース(UI)となる。
• 主に地域ポータルサイトとして実現され、官民連携を実現する際の出発点となる。

自治体業務ユニット

フロント系業務ユニット

業務の中で、電子的な窓口である業務(自治体ポータル・電子申請、電子調達等)

バック系業務ユニット

業務の中で、基幹業務・内部事務業務に関する業務(住民基本台帳、市町村民税、介護保険等)

共通系業務ユニット

自治体業務を実現させるため、複数の業務から共通的に利用される業務(住登外管理 等)

図４．２ 業務ユニットの分類

なお、この業務ユニットは、調達の最小単位であり、疎結合可能な範囲である。密結合となる共通業
務機能的なものは、地域情報 PF 仕様の対象外である。

４．３．２

業務ユニットの定義

業務システムは「業務ユニット」として整理され、差し替え可能を目指すこととする。
業務サービスは業務ユニットを構成する個々の機能をいう。
業務ユニットには、「業務ユニット間インタフェース仕様」が標準インタフェースとして定義される。業務ユニット間インタフェースには、「業務ユニットインタフェース」と「業務サービスインタ
フェース」がある。
「業務ユニットインタフェース仕様」は、HTTP 通信と SOAP を利用して業務ユニット同士がデータ交換を行うための仕様として定義される。
「業務サービスインタフェース仕様」は、同様に HTTP 通信と SOAP を利用して業務サービス連携・プ
ロセス連携を実現するための標準仕様として定義され、公開される場合もある。
「業務ユニット間インタフェース仕様」は、個別の業務モデル標準仕様等（例：自治体業務 APU 標準
仕様、GIS 共通サービス標準仕様、教育情報 APU 標準仕様、防災業務 APU 標準仕様）で定義され、「プラットフォーム通信標準仕様」における「3.2 XML 定義仕様」を参照して XSD と WSDL に関する定義体を作成する。
ただし、業務の特性上、HTTP 通信と SOAP を利用した「業務ユニットインタフェース」を標準定義できない「業務ユニット」も地域情報 PF 仕様に含まれる。そうした「例外」にあたる「業務ユニット」
については、個別の業務標準仕様において冒頭にその旨を宣言し、代替となるデータの交換方式を説明する。また、例外の「業務ユニット」でも「業務ユニットインタフェース仕様」を定義するドキュメン‐10‐アーキテクチャ標準仕様 V3.2
ト書式に従って、「業務ユニット」としての業務の粒度や機能要件、さらに扱う業務データ項目について標準仕様として定義する。この「例外」にあたる「業務ユニット」も XML 文書を標準仕様の一部として公開する場合は、「プラットフォーム通信標準仕様」の「３．２ XML 定義仕様」を参照して XSD を作
成する。

４．３．３

連携アーキテクチャ

業務ユニット間インタフェースは、データ交換時とサービス連携、プロセス連携時に応じた連携アー
キテクチャを規定する。
（１）業務ユニット間のデータ交換時ア）業務ユニットの役割
業務ユニットには、自らデータを管理（保持）して、他の業務ユニットにデータを提供する「提供側業務ユニット」と、他の業務ユニットのデータを利用（参照）する「利用側業務ユニット」の2 種類がある。これは、データ交換における業務ユニットの役割により区別するものであり、1 つの業務ユニットが、「提供側業務ユニット」として他の業務ユニットにデータの提供を行い、「利用側業務ユニット」として他の業務ユニットのデータを利用するのが一般的である。

DB
データ

データ

機能
利用側業務ユニット

提供側業務ユニット

図４．３ 提供側業務ユニットと利用側業務ユニットイ）業務ユニットのデータ交換処理の基本アーキテクチャ
地域情報 PF では、自治体内部の提供側業務ユニット毎に、業務ユニットインタフェースを仕様として規定している。この規定された仕様に基づき、実現される業務ユニットのデータ交換処理の
基本アーキテクチャを図４．４に示す。

‐11‐

アーキテクチャ標準仕様 V3.2

業務ユニット毎に業務ユニットインタ
フェースを規定
提供側

業務ﾕﾆｯﾄIF

利用側

業務ユニットA

業務ユニットX

ＤＢ－A

AＡ
機能 - X
業務ユニットB

ＤＢ－B

B

Ｂ

業務ユニット
インタフェース例

ＤＢの検索
結果
メッセージ
（ＸＭＬ）

SOAP ﾘｸｴｽﾄ
Ｗｅｂｻｰﾋﾞｽ
同期型通信
SOAP 回答

問合せ
メッセージ
（ＸＭＬ）

検索条件を
指定する。

利用

図４．４ 業務ユニット間のデータ交換処理モデル[業務ユニットインタフェース（通信仕様）]
提供側業務ユニットに規定される業務ユニットインタフェースを利用する際の通信仕様を下記のとおり規定する。
① 業務ユニットインタフェースは、SOAP による PF 通信機能仕様を採用する。
② 業務ユニットインタフェースは、入力メッセージと、出力メッセージを定義する。
③ 業務ユニットインタフェースは、入力メッセージに対して、出力メッセージを返信する。
ウ）データ交換処理モデル
業務ユニット間のデータ交換処理には、提供側業務ユニットが、ある特定のタイミングで能動的にデータ交換を行う「PUSH 型」と、利用側業務ユニットから要求（リクエスト）を受けたタイミン
グで受動的にデータ交換を行う「PULL 型」の 2 種類がある。

‐12‐

アーキテクチャ標準仕様 V3.2

○PUSH型業務ユニットインタフェース

DB
データ

データ
ＳＯＡＰリクエスト

機能

SOAPレスポンス
受信結果

提供側業務ユニット○PULL型

利⽤側業務ユニット

業務ユニットインタフェース

DB
データ

検索条件

ＳＯＡＰリクエスト

機能

ＳＯＡＰレスポンス
データ

提供側業務ユニット

利⽤側業務ユニット

図４．５ 業務ユニット間のデータ交換モデル［PUSH 型］
提供側業務ユニットは、入力メッセージに提供データを含めて PF 通信機能の SOAP リクエス
トとして送信する。
利用側業務ユニットは、出力メッセージに受信結果を含めて PF 通信機能の SOAP レスポンス
として返信する。
［PULL 型］
利用側業務ユニットは、検索条件（検索項目に対する条件値）を指定した入力メッセージを作成して PF 通信機能の SOAP リクエストとして送信する。
提供側業務ユニットは、出力メッセージに提供データを含めて PF 通信機能の SOAP レスポン
スとして返信する。
エ）業務ユニットのデータ交換処理における統合 DB 機能の利用
統合 DB 機能を利用した業務ユニット間のデータ交換処理は、オプションである。
統合 DB 機能を選択した際のデータ交換アーキテクチャや規定事項は「４．５．４ 統合 DB 機能」に示すが、業務ユニットは統合 DB 機能に対して次の役割を果たす必要がある。
【利用側業務ユニットの役割】
統合 DB 機能をデータ交換に使用する場合、利用側業務ユニットは他の業務ユニットとのデータ交換に統合 DB 機能を利用するべきであり、この際のインタフェースは統合 DB 機能によりサポート
されるものを使用する。
【提供側業務ユニットの役割】
統合 DB 機能をデータ交換に使用する場合、提供側業務ユニットは統合 DB 機能の方式に合った手
段により、自己が管理するデータを統合 DB 機能に提供する必要がある。
‐13‐

アーキテクチャ標準仕様 V3.2

①公開用 DB 方式の統合 DB 機能を使用する場合
公開用 DB 方式の統合 DB 機能を使用する場合、提供側業務ユニットは自己が管理する DB を更新
した後、速やかに統合 DB 機能がサポートする提供 I/F による PUSH 型のデータ提供により統合 DB
機能に更新したデータの提供を行う必要がある。
②共通インタフェース方式の統合 DB 機能を使用する場合
共通インタフェース方式の統合 DB 機能を使用する場合、提供側業務ユニットは自己が管理する
DB の対象データについて、統合 DB 機能がサポートする提供 I/F により、統合 DB 機能にデータを公開する機能（PULL 型データ提供機能）を持つ必要がある。

（２）業務ユニットのサービス連携、プロセス連携アーキテクチャ
業務ユニット間の単純なデータ交換ではなく、業務サービスとしてワンストップサービス等の高度な処理依頼をする場合は、業務サービスおよびそのインタフェースである業務サービス
インタフェースを開発し、BPM 機能等で制御し使用する。
この業務サービスインタフェースは、地域情報 PF では規定しない。ただし、実現するためのアーキ
テクチャ、適用技術仕様、メッセージ形式などをプラットフォーム通信標準仕様で規定する。さらに、
業務サービスインタフェースを構築するための手順を地域情報プラットフォームガイドラインに記載
し、個別団体での実現をサポートする。

サービ ス連携 ・プ ロセ ス連携

業務ユニット

＜Ａ自治体＞

フロント系
業務ユニット業務サービス

業務ユニット間
インタフェース

バック系
業務ユニット業務
サービス

共通系
業務ユニット

業務
サービス

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

サービス基盤
ＰＦ通信機能ＢＰＭ機能

図４．５ 業務ユニットのサービス連携、プロセス連携アーキテクチャ‐14‐アーキテクチャ標準仕様 V3.2

４．４

開発

地域情報PF 標準仕様では、規定しない。
ワンストップサービス定義の開発に関する例は、地域情報プラットフォームガイドライン第４章を
参照。

４．５

サービス基盤

地域情報 PF のサービス基盤は、・プラットフォーム通信機能（PF 通信機能）
・ビジネスプロセス管理機能（BPM 機能）・プラットフォーム共通機能（PF 共通機能）
・統合 DB 機能から構成される。
業務ユニット間の連携には、データ交換、サービス連携・プロセス連携があるが、それぞれの連携対象の業務ユニットには、業務ユニット間インタフェースが定義される。さらに業務ユニット間の連携では、PF 通信機能による通信が行われる。同様に、BPM 機能と業務サービス間の連携においても、PF 通信機能による通信が行われる。

４．５．１

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

プラットフォーム通信機能（PF 通信機能）は、業務ユニットおよび業務サービスが標準インタフェー
スや標準規約（セキュリティ、メッセージ等）に準拠して連携を実現するための「標準通信機能群」である。
詳細は「プラットフォーム通信標準仕様」で規定する。

４．５．２

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

ビジネスプロセス管理機能（BPM 機能）は自治体内の業務サービスおよび自治体間、官民連携業務
サービスの実行を制御する機能であり、ワンストップサービスの実現に必要となる。
業務サービスインタフェースを組み合わせてビジネスプロセスを組上げ、ワンストップサービスや高付加価値サービスを構築することができる。このとき、BPM 機能はプラットフォーム通信標準仕様に従う機能内容でなければならない。また、プロセス定義のためのスクリプトはプラットフォーム通信標準仕様に従うものでなければならない。
詳細は「プラットフォーム通信標準仕様」で規定する。

（１）ワンストップサービスと BPM 機能の処理範囲‐15‐アーキテクチャ標準仕様 V3.2

① ワンストップサービスの開始
ａ．地域情報PFが、受付などより、ワンストップサービスの処理開始依頼を受け取った時点② ワンストップサービスの終了
ａ．ワンストップサービスに関連する、すべての業務サービスについて、以下の条件が満たされた時点
・ 業務サービスが終了していること。
・ 地域情報PFから受付などに、業務サービス終了時点の連絡文、交付物を渡していること。
利用者 （
住民 ・
職員）

受付

地域情報ＰＦ（ＢＰＭ機能）申請情報入力業務サービスＡ

業務サービスＢ•連絡文•交付物• BPM機能の終了

業務事務 Ｂ

公文書作成

業務
サービスＢ

受付
審査
結果登録

業務事務Ａ

機能
BPM

•連絡文
•交付物

ワンストップサービ ス

公文書作成

業務
サービスＡ

受付
審査
結果登録

業務Aの交付物取得
業務Bの交付物取得

図４．６ ワンストップサービスと BPM 機能の処理範囲

４．５．３

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

プラットフォーム共通機能（PF 共通機能）は、サイト内や、さらに、異なるサイトに跨った業務サー
ビスを連携する際に必要となる共通的な機能群である。以下にこの機能群に含まれる個々の機能を列挙する。
・認証・認可・セキュリティ機能
PF サイト認証仕様、PF 秘匿性確保仕様、PF 本人電子署名・検証仕様、
PF 自治体組織電子署名・検証仕様、PF サービス認証・サービス認可連携仕様、
PF プライバシ情報公開仕様、サービス監査証跡機能。
・モニタリング機能
業務サービス連携において、ビジネスプロセス、サービス、実行状態を監視するモニタリング機
能。
・ユーティリティ機能
時刻同期機能、サービス・レジストリ機能とリポジトリ機能、統合レジストリ機能、
ビジネスメッセージルーティング-ゲートウェイ（BMR-GW）機能。
以下、プラットフォーム共通機能の各機能の概要を記載する。

‐16‐

アーキテクチャ標準仕様 V3.2

４．５．３．１

認証・認可・セキュリティ機能

プラットフォーム通信標準仕様で規定する。

４．５．３．２

モニタリング機能（１）概要、並びに目的
官民間連携サービス等により、地域の高付加価値サービス実現にあたっては、ビジネスプロセスやサービス連携の状態を把握し、問題発生の回避やシステム改善・サービス改善に役立てることが重要である。例えば、官民間連携サービス・自治体サービスを提供するポータルサイトが、サービスを提供している際に、依頼先の自治体の業務で何かの障害が発生し、サービス提供が遅れた場合、その責任範囲
を依頼先の自治体のみに限定することは現実的ではない。依頼先の自治体の提供するサービスの状況を
ポータルサイトや依頼元の自治体がモニタし、共有化できれば、先の官民間連携サービス・自治体サービスに関与する自治体で処理優先度を調整したり、当該官民間連携サービス・自治体サービスや各種申請手続きを受ける受益者たる住民に対して状況説明をしたりといった対応が可能となる。
以上の様なことを、例えば自治体内のみで適用される運用管理ツールや、ITIL(Information
Technology Infrastructure Library)等の IT サービスフレームワーク、その上の運用のポリシーだけを活用することで実現することは難しい。自治体間連携、官民間連携、自治体・民間連携等の複数の組織体が関与する官民間連携サービス等では、全体的なシステム改善・サービス改善を実現する上での各組織体の責任分界等の難しさがあり、新たに一貫した管理の実現を別途検討しなければならない。地域
情報プラットフォームでは、以上の問題を考慮してモニタリング機能をオプションとして定義している。
モニタリング機能の目的は、前述の様な複数の組織体を跨り、連携した業務サービスを実行する場合に、サービスを依頼した組織体が相手組織体のビジネスプロセスやサービスの実行状況を開示可能な範囲で把握することにある。
（２）モニタリング機能におけるユースケース定義
図４．７に、モニタリング機能の利用イメージ図を、表４．２にユースケース定義を記す。
組織A（サービス依頼側）

組織B（サービス提供側）

システム運用管理者

連携問合せ
連携問合せ
サービス
サービス
業務ユニットｂ
業務ユニットｂ
WSDL
WSDL

業務ユニットａ
業務ユニットａ
サイト間通信機能
サイト間通信機能

サイト間通信機能
サイト間通信機能

履歴
履歴

履歴
履歴
業務ユニットｄ
業務ユニットｄＷｅｂサービス
Ｗｅｂサービス（フローなし）（フローなし）組織Bに依頼したサービス処理が完了しているか否かが知りたい。

WSDL
WSDL

業務ユニットｃ
業務ユニットｃ
履歴相当
履歴相当
情報
情報

履歴
履歴
組織B内で呼び出しているサービス処
理の状況は不要。(知っても良い。)

図４．７ モニタリング機能の利用イメージ図‐17‐

アーキテクチャ標準仕様 V3.2
表４.２に定義された、複数の組織体を跨り、業務サービスやビジネスプロセスが実行される場合の業務サービス、ビジネスプロセスの実行状況の把握が、モニタリング機能の通常の利用方法である。一方、各組織体（例えば、自治体内部の各部門組織）で独立の運用のポリシーを採用している等の場合
は、任意の他組織体（自治体、民間企業等）間に跨ったビジネスプロセスと同等の運用状況と解釈することもできる。このため、モニタリング機能の拡張利用として、ある組織体内部での利用も可能とする。その場合、組織体外部の状況把握も可能な限り行うべきである。

表４．２ モニタリング機能のユースケース定義
利用者の定義他組織体（自治体、民間企

利用機会の定義

実施内容の定義-

住民等からの問合せに回答すサービスを依頼した組織体は、るために利用する。

他組織体が提供する連携問合せ-

システムメンテナンスのためサービスに問合せを行い、連携問に利用する。

合せサービスから得られた応答を各サービス処理の実行状況を分析し、依頼したサービスの実施考慮した処理優先付けに利用状況、ワンストップサービス全体する。

の実行状況を把握・確認する。

業等）にサービスを依頼した組織体（地域ポータル、
自治体等）のシステム運用
管理者-（３）モニタリング機能の位置づけと前提事項
地域情報 PF におけるモニタリング機能の位置づけ、並びに構成を図４．８および表４．３に記す。
図４．８は、図４．１の地域情報プラットフォームの全体アーキテクチャのうち、モニタリング機能部
分を取り出して、その構成について記したものである。
表４．３では、図４．８の構成要素を定義するが、それらの前提事項として Audit と呼ぶものが存在する。本仕様で Audit とは、ログの概念を一般化したものとして定義する。従来、サービスやシステム
リソースのある一時点の状態を示すデータ、スナップショット像、あるいはそれらの集合は、領域毎に呼称が異なり、統一化されない状況であった（例：システムリソースの分野では、“ログ”が一般的であるが、ビジネスプロセスでは“イベントログ”、“Audit Trail”等の語彙が使われている。
）。 モニ
タリング機能は、業務サービス、ビジネスプロセスという複合的な領域を対象とするため、これらに対して統一的な「呼称」「概念」を与え、従来の「呼称」をシノニムとして扱う必要がある。このため、“ログ”等を一般化した概念として“Audit”という語彙を導入する。

‐18‐

アーキテクチャ標準仕様 V3.2

＜事業者＞

＜民間企業＞

地域ポータル

民間
業務アプリケーション

実行②

利用者（住民,職員）

フロント系
業務ユニット

サービス基盤

サービ
実行
ス基盤
実行

サービ
ス 基盤
実行

＜自治体＞
バック系
業務ユニット共通系
業務ユニット

サービス基盤

実行 標準通信機能
標準通信機能ＰＦ通信機能プラットフォーム共通機能

ＢＰＭ機能
ＢＰＭ機能
ＢＰＭ機能
共通機能
ＰＦ共通機能共通機能

モニタリング対象
モニタリング対象ビジネスプロセ
ス・サービス実行状況、進捗

統合DB機能統合DB機能統合ＤＢ機能＜他自治体＞
フロント系
業務ユニットバック系
業務ユニットBPM(プロセス
BPM(プロセス))

共通系
業務ユニット

SOAP通信SOAP通信WSアプリケーション
WSアプリケーション((必要に応じて)
必要に応じて)

サービ
ス基盤
実行
実行

A
udit提供udit提供Audit提供

ガイドライン記載事項

モニタリング機能のメッセージAudit提供メッセージAudit提供
WSアプリケーション
WSアプリケーション Audit提供
udit提供BPM Audit提供
udit提供Audit
Audit Proxy
Proxy

自律的な起動システム運用管理者

プロセス Audit Proxy

サービス Audit Proxy

監視アプリケーション
アプリケーション
監視
監視アプリケーション
監視クライアントクライアント監視
監視クライアント
プロセス監視サービス監視インタフェース(標準仕様規定事項)
標準仕様規定事項)

図４．８ モニタリング機能の標準構成

モニタリング機能の前提事項は次の通りである。
・ 地域情報 PF におけるサービス基盤・プラットフォーム共通機能の１つである。
・ オプション機能であり、サービスを依頼されたすべての組織体がモニタリング機能を持つとは限らない。
・ 本仕様では、監視アプリケーションと Audit Proxy 間のインタフェースのみを規定事項とする。
本仕様に記載された以外の情報は理解を助けるための参考情報であり、ガイドラインの記載事項
を１つの構成例とする。
（４）モニタリング機能の構成
モニタリング機能に関する構成を以下に記す。
・ モニタリングは、論理的な機能構成として「Audit 提供」「Audit Proxy」「監視アプリケーショ
ン」「監視クライアント」の要素から構成される。各機能構成要素について、表４．３にその定義を説明する。

表４．３ モニタリング機能の構成要素定義
機能層
監視クライアント

定義・説明
システム運用管理者が操作する画面付プログラムである。スタンドアローンプログラム
や、監視アプリケーションにより提供される HTML を表示する Web ブラウザ等の実装方法が考えられるが、具体的な定義は行わない。

監視アプリケーション

Audit Proxy から取得した Audit 群を加工・利用し、監視クライアントに加工後のデータを提供するプログラムである。対象とする Audit の種類により「プロセス監視」と「サービス監視」が考えられる。監視アプリケーションの配置に関しては、下記に記す 2 つの方法

‐19‐

アーキテクチャ標準仕様 V3.2が想定されるが、実装に依存するため、規定事項としては定義しない。
(1) 業務サービスを依頼した組織体に配置する。
(2) 業務サービスを依頼された組織体に配置する。その組織体内でモニタリングを行う場
合や、他組織体の状況をもモニタリングする際に、進捗等の監視画面の構成情報のみ
で十分な場合に適する。
Audit Proxy

各種 Audit 提供から収集した Audit を、監視アプリケーションに対し提供する Proxy プロ
グラムで、以下 3 つの機能を担う。
(1) 組織体の DMZ(DeMilitarized Zone)に配置することで、外部アクセスに対するセキュリ
ティを確保する。
(2) 各種 Audit 提供機能の多様性を吸収し、監視アプリケーションに対し統一的なモニタリ
ング問合せインタフェースを提供する。
(3) 各種 Audit 提供機能から収集された Audit を蓄積・管理し、各監視アプリケーションで共有可能とすることで、Audit を複数の観点で利活用可能とする。また複数の Audit を加工・統合し、監視アプリケーションへ付加価値の高い情報を提供する。

収集する Audit の種類に応じて以下 2 つの Proxy が考えられる。
(1)プロセス Audit Proxy：BPM(Business Process Management)処理系と関連づいた BPM
Audit を扱う。
(2)サービス Audit Proxy：BPM 処理系や業務ユニットと関連づいたサービス Audit を扱う。
Audit 提供

Audit Proxy からの要求に応じ Audit を応答する。提供する Audit の種類に応じて以下 3 つの Audit 提供が考えられる。
(1)BPM Audit 提供：BPM 処理系の動作を表す Audit を提供する。
(2)メッセージ Audit 提供：ネットワーク上で流通する業務データの内容、状態を表す
Audit を提供する。
(3)WS アプリケーション Audit 提供：業務ユニット等のアプリケーションの動作を表す
Audit を提供する。
なお、モニタリング対象に関連した事象が発生した時点で Audit Proxy に Audit を通知することも可能ではあるが、このアーキテクチャ標準仕様では、その様な振舞いについては規定外事項として扱う。

（５）モニタリング機能における標準規定事項① 定義されるべきインタフェース
モニタリング機能の配置例、ならびに当該配置において、本来、定義されるべきインタフェー
ス群を図４．９および表４．４に記す。前述の様に、このアーキテクチャ標準仕様の対象事項としては、監視アプリケーションと Audit Proxy 間のモニタリング問合せインタフェースのみが規
定される。

‐20‐

アーキテクチャ標準仕様 V3.2

(通常利用時)監視クライアントアーキテクチャ標準仕様
規定事項

ポータルサイト（b）
監視アプリケーション

（b）

（a）

サービス
受付 & Proxy

DMZ
自治体
ポータル

Audit Proxy

（d）

BPM機能

Audit Proxy

メッセージAudit提供

（b）

（c）
（サイト内業務サービス）

DMZ サービス受付 & Proxy

監視アプリケーション

自治体内部
ガイドライン記載事項

BPM
Audit提供

民間企業ｻｰﾋﾞｽ受付（サイト間業務サービス）

業務ユニット業務ユニット（サイト内業務サービス）（サイト内業務サービス）－インタフェース定義(モニタリング機能)－(a)モニタリング問い合わせインタフェース [標準](b)監視クライアントインタフェース [規定なし](c)BPM・WSアプリケーション Audit提供インタフェース[ガイドライン](d)メッセージ Audit提供インタフェース [ガイドライン]

自治体内部
統合DB機能監視クライアント(拡張利用時)－凡例－[アーキテクチャ標準仕様で規定][モニタリング機能関係][通常の業務メッセージ]

図４．９ モニタリング機能のインタフェース

表４．４ モニタリング機能のインタフェース定義
定義
記号

インタフェース名(a)モニタリング問合せインタフェース

規定事項
これは、監視アプリケーションと Audit Proxy 間の問合せイ
ンタフェースである。そして、このアーキテクチャ標準仕様
で規定される事項であり、表 4.4 にその内容を規定する。監視アプリケーションから必要な Audit Proxy を呼び出し、その結果を得る。

(b)

監視クライアントインタフェース

監視クライアントと監視アプリケーション間のインタフェースである。このアーキテクチャ標準仕様で規定される事項は存在しない。

(c)(d)

BPM・WS アプリケーション Audit 提供インタ

各種 Audit 提供機能が生成する Audit の形式および Audit 提フェース

供機能と Audit の授受を行うためのインタフェースである。

メッセージ Audit 提供インタフェース

ガイドラインにて奨励案を提示する。ただし、他の方式が存在する場合、必ずしも当該奨励案に従う必要はない。

② モニタリング問合せインタフェースの規定事項
表４．５は、モニタリング問合せインタフェースの規定事項である。

‐21‐

アーキテクチャ標準仕様 V3.2
表４．５ モニタリング問合せインタフェースの規定事項
定義番号
規定事項.1

規定内容
プラットフォーム通信標準仕様が定める SOAP(Simple Object Access Protocol)通信に従わなければならない。

規定事項.2

プラットフォーム通信標準仕様が定める 3 種類のメッセージ交換パターンから、１つ以上のパターン
を選択しなければならない。

規定事項.3

Audit Proxy は監視アプリケーションを認証し、必要以上に Audit を提供しないようにすべきである。サービス認証・サービス認可機能、セキュリティポリシーは、プラットフォーム通信標準仕様で定める方式に従わなければならない。

規定事項.4

Audit Proxy が提供するモニタリング問合せインタフェースの WSDL(Web Services Description
Language)は、形式を指定しないが、システムインテグレータ、もしくはシステム運用管理者により、公開されていることが必要である。

規定事項.4-1

監視アプリケーションから Audit Proxy へのモニタリング問合せインタフェース（モニタリング問合せ要求）は、以下を満足する。
(1) 監視アプリケーションは、呼出先のサービスサイトに設置された Audit Proxy に対して、XML 形
式の問合せのメッセージを送付する。この WSDL は、事前に公開されていなければならない。
(2) 問合せ XML メッセージには、以下の意味を持つ項目を持たなければならない。
－引数：問合せ対象の受付番号（データ型：整数型）

規定事項.4-2

Audit Proxy から監視アプリケーションへのモニタリング問合せインタフェース（モニタリング問合せ応答）は、以下を満足する。
(1) 監視アプリケーションからの問合せに対して、成功として扱う場合は、下記の意味項目を含んだXML 形式のメッセージで応答する。
－受付番号(データ型：整数型、引数で指定されたもの）－処理状態(データ型：列挙型で“終了”、“受理済”、“処理済”、”未受理”等に対応付けられていること。具体的な値と意味は、WSDL 定義時に取り決める。
）－実行時刻(データ型：文字列型、西暦年月日と秒までの時刻を含んだデータ。形式等は、WSDL
定義時に取り決める。）－場所(データ型：文字列型で形式自由。処理状態が発生した処理や手続きを特定する情報であり、WS-BPEL の Activities を意味する URI(Uniform Resource Identifier)を記載しても良い）－その他(データ型：文字列型で形式自由または WSDL で公開されている任意の XML データ)
(2) 監視アプリケーションからの問合せに対して、失敗として扱う場合は、下記の意味項目を含んだXML メッセージで応答する。
－受付番号(データ型：整数型、引数で指定されたもの）－エラー記述(データ型：文字列型で形式自由または WSDL で公開されている任意の XML データ)

規定事項.5

監視アプリケーションが Audit Proxy に対して問合せを行う際は、以下の制限を満足すること。
(1) 監視アプリケーションは、直接サービスを依頼した組織体の Audit Proxy に対して、問合せを行うことができること。
(2) 監視アプリケーションは、直接サービスを依頼していない組織体の Audit Proxy に対しては、問合せを行わないこと。ただし、直接サービスを依頼した組織体から関連性を指定された場合に限り、直接サービスを依頼していない組織体の Audit Proxy に対しても問合せを行うことができる
こととする。この結果、監視アプリケーションは、直接サービスを依頼した組織体が依頼した他の組織体のサービスの進捗も含め、ビジネスプロセス上で関係のある全進捗も把握し得る。
(3) 監視アプリケーションは、自分が依頼したサービスの受付番号のみ指定できる。

‐22‐

アーキテクチャ標準仕様 V3.2
③ 各種 Audit の形式等に関する事項
形式について、規定しない。ただし、ガイドラインにて各種 Audit 実装形式の奨励案を記載する。その際、項目の意味、モニタリング問合せインタフェースとの関連項目の指定等についても解説する。ガイドラインの実装形式を選択して良い。
④ 各種 Audit 提供の配置等に関する事項
その配置等について、規定しない。ガイドラインにて各種 Audit 提供配置例を記載する。その際、配置数、配置場所、アクセスポイント等について解説する。
＜＜準拠ルール＞＞【共通】(AS-R04561):地域情報 PF において、モニタリング機能はオプションである。（オプション）[4.5.3.2](AS-R04562)：サイトがモニタリング機能を採用しモニタリング情報を公開する場合(AS-R04561)、Audit
Proxy は、モニタリング機能が定義する標準インタフェースを持つこと。(必須) [4.5.3.2](AS-R04563)：サイトがモニタリング機能を採用しモニタリング情報を公開する場合(AS-R04561)、Audit
提供は、モニタリング機能が定義する Audit 形式の情報を収集し、Audit Proxy へ提供できること。(必須) [4.5.3.2](AS-R04564)：サイトがモニタリング機能を採用しモニタリング情報を公開する場合(AS-R04561)、監視ア
プリケーションは、各サイトの Audit Proxy が公開する標準インタフェースにプラット
フォーム通信機能を用いてアクセスし、モニタリング情報を取得することができること。
(必須) [4.5.3.2](AS-R04565)：サイトがモニタリング機能を採用しモニタリング情報を公開する場合(AS-R04561)、Audit
形式については、ガイドラインで規定されたものを奨励する。(推奨)
用語の定義

項番
1
2
3

用語

意味

Audit

ログの概念を一般化したもの。

監視クライアント

システム運用管理者が操作する画面付プログラム。

監視アプリケーション

Audit Proxy から取得した Audit 群を加工・利用し、監視クライアントに加工後のデータを提供するプログラム。

4

Audit Proxy

各種 Audit 提供から収集した Audit を、監視アプリケーションに対し提供する
Proxy 機能である。以下 3 つの機能を担う。
(1) 組織体の DMZ に配置することで外部からのアクセスによるセキュリティを確保する。
(2) 各種 Audit 提供機能の多様性を吸収し、監視アプリケーションに対し統一的なモニタリング問合せインタフェースを提供する。
(3) 各種 Audit 提供機能から収集された Audit を蓄積・管理し、各監視アプリ
ケーションで共有可能とすることで、Audit を複数の観点で利活用可能とする。また複数の Audit を加工・統合し、監視アプリケーションへ付加価値の高い情報を提供する。

5
6
7
8

Audit 提供

Audit Proxy からの要求に応じ Audit を応答する。

BPM Audit 提供

BPM 処理系の動作を表す Audit を提供する。

メッセージ Audit 提供

ネットワーク上で流通する業務データの内容、状態を表す Audit を提供する。

WS アプリケーション
Audit 提供

業務ユニット等のアプリケーションの動作を表す Audit を提供する。

‐23‐

アーキテクチャ標準仕様 V3.2

４．５．３．３

ユーティリティ機能

PF 共通機能における「ユーティリティ機能」の位置づけや機能を記述する。
PF 共通機能におけるユーティリティ機能とは、データ交換、サービス連携、プロセス連携などを実現する地域情報 PF の開発、実行、運用に関連し、横断的に使用される機能を集めたものである。本仕様
では、下記の機能を集め、規定している。
(1) 時刻同期機能(2) サービス・レジストリ機能(3) リポジトリ機能(4) 統合レジストリ機能(5) ビジネスメッセージルーティングゲートウェイ（BMR-GW）機能（１）時刻同期機能
業務ユニットやサービス基盤が動作するサーバ等のマシンの「時刻同期」を実施する機能である。
【共通】①時刻同期の方法
a．正確な時刻の起点となるサイト外部の NTP サーバを決定する。
b．サイト内部の NTP サーバの設置と、サイト外部の NTP サーバとの時刻同期
自治体等のサイト毎にサイト内部の時刻起点となる内部 NTP サーバを設置し、a.の NTP サーバとの時刻同期をとる。
なお、自治体内等のサイトで、電波をつかった機器等による信頼できる NTP サーバがある場合、a.のサイト外部の NTP サーバに代わり、そのサーバを内部の NTP サーバとする。
c．サイト内の時刻同期対象マシンの時刻同期
サイト内の時刻同期対象マシンを NTP クライアントとして、b.の内部 NTP サーバと時刻同期を実施する。
d. マシン間の時刻同期プロトコルは、NTP(RFC1305 準拠)を使用する。
②運用上の時刻同期処理
各マシンの起動後に、内部の NTP サーバと時刻同期を実施する。

【サイト内】
サイト内の業務ユニット、BPM 機能、統合 DB 機能が動作するマシンは、時刻同期の実施はオプションである。ただし、モニタリング機能や監査証跡機能を使用する場合は必須である。
【サイト間】
サイト間でサービス連携するサーバの時刻同期機能は必須である。時刻同期は各団体の責任で、標準時との時刻同期を実施する必要がある。
【クラウド間】
クラウド間でサービス連携するサーバの時刻同期機能は必須である。時刻同期は各団体の責任で、標準時との時刻同期を実施する必要がある。

‐24‐

アーキテクチャ標準仕様 V3.2

（２）サービス・レジストリ機能【共通】「サービス・レジストリ機能」の定義と採用技術を記載する。本機能は、オプションである。
①サービス・レジストリ機能の定義
サービス・レジストリ機能とは、サービス情報を管理する蓄積庫である。サービス情報のライフサイクル（登録、更新、削除）を管理し、これら登録されたサービス情報を検索できるサービスを提供する機能である。
②サービス・レジストリ機能で採用する技術
静的なサービス呼び出しと、動的なサービス呼び出しに応じて、技術を選択する。
（ａ-1）静的なサービス呼び出しの場合
静的にサービスの呼び出しを実施する場合は、下記の手法を選択する。
・Web サイトによるサービス情報の管理と公開（カタログ形式、バージョン管理）・スプレッドシートによる情報の管理と公開（ａ-2）動的なサービス呼び出しの場合
動的にサービスの呼び出し先を検索し、呼び出し処理を実施する場合は、下記の技術を選択する。
・UDDI 等（国際標準規格の技術動向と普及状況を踏まえ今後選定する）

サービス・レジストリ機能
・サービス情報を管理する蓄積庫であり、サービス情報のライフサイクルを管理する。
・サービス情報の登録、更新、削除、検索サービスを提供する。
サービス提供者向け － 登録、更新、削除
サービス利⽤者向け － 検索サービス・レジストリ機能

サービス情報サービス情報の登録、更新、削除

サービス情報の検索サービス利⽤サービス利⽤者
サービス提供者

図４．１０ サービス・レジストリ機能の実装例‐25‐

アーキテクチャ標準仕様 V3.2

動的なサービス呼び出しの中でも、自治体間連携において、職員が住民の情報を照会する際、照会対象となる住民（以下、対象者と記述）の情報を保有する自治体のサービスを検索する等、対象者の情報を持つサイトのサービスを検索する場合がある。
この場合、対象者の ID とサービス情報を紐づけて管理し、サービス情報を提供するサービス・
レジストリ機能が必要となる。
サービス・レジストリ機能（対象者の情報を持つサイトのサービスを検索する場合）・サービス情報を管理する蓄積庫であり、サービス情報のライフサイクルを管理する。
・対象者のIDとサービス情報の紐付け情報を管理する。
・サービス提供側サイトに、サービス情報及び紐付け情報の登録、更新、削除サービスを提供する。
・サービス利⽤側サイトに、対象者のIDによるサービス情報検索サービスを提供する。
（対象者が、自治体Aの住⺠Aである場合の利⽤イメージ）住⺠AのIDによりサービス・レジストリを検索し、自治体Aのサービス情報を取得する。

サービス・レジストリ機能
紐付け情報
住⺠AのID

サービス情報の検索サービス情報サービス利⽤自治体X

住⺠AのIDとサービス情報の紐付け情報の登録
サービス情報の登録、
更新、削除

自治体A

住⺠Aの情報サービス情報の登録、更新、削除

サービス利⽤側サイト

自治体B
サービス提供側サイト

図４．１１ 対象者の情報を持つサイトのサービスを検索する場合のサービス・レジストリ機能の実装例‐26‐

アーキテクチャ標準仕様 V3.2
（３）リポジトリ機能【共通】「リポジトリ機能」の定義と採用技術を記載する。本機能は、オプションである。
①リポジトリ機能の定義
リポジトリ機能とは、標準仕様関連書類、システム開発仕様、プログラム、用語定義、項目辞書等を、蓄積・管理するデータベース等の蓄積機能である。
②リポジトリ機能の採用技術管理する情報の種類や量、バージョン履歴の管理などの規模や工数を考慮し、文書管理ソフト
ウェア等の専用ソフトウェアでの実現と、国際標準規格である ebXML R&R 等の採否を検討する。
（４）統合レジストリ機能「統合レジストリ機能」の定義と採用技術を記載する。本機能はオプションである。
【サイト間】①統合レジストリ機能の定義
高付加価値サービスをサービス利用者に対して迅速に安定して提供するためには、サービス提供者またはサービス管理者がサービスの運用状況や、サービス利用者との合意に基づいた目標品質を管理・把握し、これらサービス情報をサービスの品質にフィードバックすることが可能なサービス
管理基盤が必要である。
「統合レジストリ機能」は、多様化するサービス利用者とサービス提供者間の関係（サービス利用形態）を二者間の｢合意｣として策定し、従来のレジストリ機能が管理する情報と合わせてサービス
情報として管理・監視する機能である。
②統合レジストリ機能の機能要件について
統合レジストリ機能は、従来のレジストリ機能を拡張した概念であり、統合レジストリ機能のレ
ジストリ機能とエージェント機能から構成される。以下、レジストリ機能とエージェント機能が満たすべき要件を示す。
ア）統合レジストリ機能のレジストリ機能要件［図４．１２ 合意交渉］
サービスに関する情報を蓄積し、またそれらの情報をもとにサービス利用者とサービス提供者との間で合意交渉を行える下記の機能要件であること。
・サービス提供者が、提供するサービスに関する情報を登録可能であることとする。
（従来のレジストリ機能）
・サービス利用者が、利用したいサービスについて検索可能であることとする。
（従来のレジストリ機能）
・サービス利用者とサービス提供者の間で、サービスの利用形態について合意交渉が可能であることとする。
・両者の間で合意した内容をサービス管理情報として管理することが可能であることとする。
・合意した内容をもとに、それらをサービスに反映するためのエージェント機能（Web サービス）の生成が可能であることとする。
・生成したエージェント機能を制御、管理するとともに、エージェント機能を経由してサービスの運用状況などの情報（サービス情報）を収集し、サービス利用者、サービス提供者またはサービス管理者へ提供することが可能であることとする。

‐27‐

アーキテクチャ標準仕様 V3.2

イ）統合レジストリ機能のエージェント機能要件
サービスとサービス利用者の間に介在し、サービス利用状況を収集することで合意を適用したサービスの提供状況について監視する機能を提供する。
統合レジストリ機能のレジストリ機能にてサービス利用者とサービス提供者の間で合意した内容の通りに、サービスが提供されているかどうかの監視が行えること（図４．１２ 合意適用、
合意監視）。
③統合レジストリ機能の実装モデル
統合レジストリ機能の実装者は、レジストリ機能、エージェント機能を実装する上で、以下の仕様を策定し実装することとなる。
合意をサービスに反映させるエージェント機能については、その役割から Web サービスの PF 通信で実現し、インタフェースを WSDL で規定することとする。

②サービスを閲覧／検索する

レジストリ機能①サービスを登録する

従来のレジストリ機能

合意交渉
合意交渉

サービス提供者
サービス
③合意交渉
を行う

①サービスを利用する
SOAP④エージェントの管理、制御エージェント機能
合意適用
合意監視

サービス利用者

SOAP

サービス
統合レジストリ機能

図４．１２ 統合レジストリ機能の実装モデル（５）ビジネスメッセージルーティングゲートウェイ機能（BMR-GW）「BMR-GW 機能」の仕様を記載する。本機能は、オプションである。
【共通】①BMR-GW 機能の定義
BMR-GW 機能とは、メッセージヘッダ部（詳細は、プラットフォーム通信標準仕様の「７．プラットフォーム通信仕様におけるメッセージ共通ヘッダ仕様」を参照）に記載された送信先（To タグ項‐28‐

アーキテクチャ標準仕様 V3.2目の値）に、メッセージ本体を動的に送信代行する Proxy として動作する機能である。BMR-GW 機能
は、送信元から送信されたメッセージのヘッダ部分を解析し、指定された送信先へメッセージをルーティングする。また、サービスを呼び出した際に同期で返ってくる結果を元々の送信元へ同期で返す処理を行う機能である。その実装形態は、サーバ型とした独立機能でも、業務ユニットや
BPM 機能が動作するマシンに組み込まれた機能でもよい。
②BMR-GW 機能を活用した動的な送信先変更の動作例

団体 A

実際の送信先を示す
ヘッダ情報を元に送信先を動的に制御

団体 B
照会サービスBMR-GW機能

団体 C
照会サービス

業務プロセス

図４．１３ BMR-GW 機能を使った動的に送信先を変更する例

動的に決定される送信先へのメッセージ送信の動作手順は以下の通りである。なお、図４．１３
では、BMR-GW 機能を使った動的に送信先を変更する例を示す。
(ⅰ)送信元のプロセスは、業務メッセージの To フィールドに送信先の URL を設定する。
なお、送信先 URL は、業務レベルの論理的な宛先とサービスと URL を表で管理保持し、処理時に適切に選択され指定されるものとする。
(ⅱ)送信元は、業務メッセージを BMR-GW 機能の固定 URL へ送信する。
(ⅲ)BMR-GW 機能は送信元からの送信代行要求を受け付ける。このとき、送信元からの HTTP セッ
ションはレスポンス返信のため保持しておく。
(ⅳ)BMR-GW 機能は送信先 URL として共通ヘッダの “To” フィールドを参照する。
(ⅴ)BMR-GW 機能は受け取った業務メッセージを送信先 URL へ Forward する。
(ⅵ)BMR-GW 機能は送信先からのレスポンスを(ⅲ)で保持していたセッションを介して送信元へ返す。
③BMR-GW 機能を活用した複数の送信元への処理結果を返信する例
受信した申請書類などの受領確認や処理結果の返信を非同期に行う場合、返信先の指定が必要となる。申請書類の送付元が固定であれば、返信先も静的に確定できるが、複数の送付元が考えられる場合は、その返信先を動的に制御する必要がある。その際の動作イメージを図４．１４に示す。

‐29‐

アーキテクチャ標準仕様 V3.2

団体 A

ReplyTo に返信先を設定して申請書送信

業務プロセス

申請
団体 C

業務サービス

処理
結果

団体 B
業務プロセスBMR-GW
機能

申請
処理
結果

ReplyTo に設定された返信先を To に設定してGW 機能を介して返信

図４．１４ BMR-GW 機能を使った複数の送信元への処理結果を返信する例

BMR-GW 機能を使った複数の送信元への処理結果を返信する例の動作手順は以下の通りである。
(ⅰ)非同期での返信を期待する場合、送信元は、メッセージヘッダの ReplyTo に返信先の URLを設定してから業務メッセージを送信する。
(ⅱ)業務メッセージを受信したサービスは ReplyTo から返信先 URL を参照する。
(ⅲ)サービスは、返信メッセージヘッダの To フィールドに(ⅱ)で参照した URL を設定する。
(ⅳ)サービスは、返信メッセージヘッダの RelatesTo フィールドに元メッセージのメッセージ
ID を設定する。
(ⅴ)サービスは、業務処理結果のメッセージを、BMR-GW 機能の固定 URL へ返信メッセージを送信する。
(ⅵ)BMR-GW 機能は、送信元（業務サービス）からの送信代行要求を受け付ける。このとき、送信元からの HTTP セッションはレスポンス返信のため保持しておく。
(ⅶ)BMR-GW 機能は受け取った業務メッセージを送信先 URL へ Forward する。
(ⅷ)BMR-GW 機能は送信先からのレスポンスを(ⅱ)で保持していたセッションを介して送信元へ
返す。

‐30‐

アーキテクチャ標準仕様 V3.2＜＜準拠ルール＞＞【共通】(AS-R045320) ：サービス・レジストリ機能を使用し、サービス情報を管理し、動的なサービスの呼び出しを行う場合、UDDI を使用してもよい。（オプション）[ 4.5.3.3(2) ](AS-R045321) ：ビジネスメッセージルーティングゲートウェイ (BMR-GW) 機能は、動的なメッセージ
ルーティングが必要な場合使用してもよい。（オプション）[ 4.5.3.3(5) ]【サイト間】(AS-R045322) ：PF 通信が行われるサーバは時刻同期機能を使用する。（必須）[ 4.5.3.3(1) ](AS-R045323) ：サイト間のサービスレベルの合意とサービス状態の監視を行う場合、統合レジストリ機
能を使用してもよい。（オプション）[ 4.5.3.3(3) ]【サイト内】(AS-R045324) ：PF 通信が行われるサーバは時刻同期機能を持つことを推奨する。（推奨）[ 4.5.3.3(1) ](AS-R045325) :モニタリング機能や監査証跡機能を使用する場合は、対象とするサーバは時刻同期機能を使用する。（必須）[ 4.5.3.3(1) ]【クラウド間】(AS-R045322) ：PF 通信が行われるサーバは時刻同期機能を使用する。（必須）[ 4.5.3.3(1) ]

用語の定義
項番

用語

意味

1

時刻同期機能サイト内で動作するサーバ等のマシンの「時刻同期」を実施する機能。

2

サービス・レジスト
リ機能

サービス・レジストリ機能とは、サービス情報を管理する蓄積庫であリ、サービス情報のライフサイクル（登録、更新、削除）を管理し、これら登録されたサービス情報の検索できるサービスを提供する機能。

3

リポジトリ機能

標準仕様関連書類、システム開発仕様、プログラム、用語定義、項目辞書等
を、蓄積・管理するデータベース等の蓄積庫機能。

4

統合レジストリ機能

多様化するサービス利用者と提供者間の関係（サービス利用形態）を二者間の｢合意｣として策定し、従来のレジストリ機能が管理する情報と合わせてサービス情報として管理・監視する機能。

5

ビジネスメッセージ
ルーティングゲート
ウェイ（BMR-GW）機能

メッセージヘッダ部（詳細は、PF 通信標準仕様の「７．プラットフォーム通信仕様におけるメッセージ共通ヘッダ仕様」を参照）に記載された送信先（To タグ項目の値）に、メッセージ本体を動的に送信代行する Proxy として動作する機能。

6

UDDI

Web サービスのレジストリ作成、レジストリへのアクセスコントロール方法、記録をほかのレジストリに転送する仕組みについてプロトコル仕様を定
めている。

‐31‐

アーキテクチャ標準仕様 V3.2

４．５．４

統合 DB 機能【共通】

４．５．４．１

統合 DB の目的

自治体の情報システム全体について、あるべき姿を明確に提示することにより、既存資産を有効活用しつつ、段階的かつ円滑なシステム移行を可能とし、最終的に実現するシステムの効率化を図る。
○○○

情報の統合管理（一元管理）と有効活用を図る。
業務システム間連携を容易化、高度化し、業務の効率化を図る。
ベンダに依存しないシステムの実現による柔軟性向上とコスト削減を図る。

地域情報 PF では、「業務ユニットのデータ交換処理の基本アーキテクチャ」で、性能、その他の要件から、柔軟にデータ交換を行うための仕組みとして「統合 DB 機能」を標準化している。
統合 DB 機能は、オプションである。

４．５．４．２

統合 DB 機能のスコープ【サイト内】
統合 DB 機能は、「単一自治体内部」をスコープとして利用されるものとする。
また、統合 DB 機能で交換されるデータは、自治体内の業務ユニット間で交換されるデータである。

業務ユニットA

自治体内部

機能 - A

業務ユニットB
提供機能 - B
ＤＢ－B

ＤＢ－Ａ
統合DB機能利用

業務ユニットC

業務ユニットD

機能 - C

機能 - D

ＤＢ－C

ＤＢ－D

図４．１５ 統合 DB 機能のスコープ【サイト間】
統合 DB 機能と外部(他自治体（自治体間連携）や民間（官民連携）などのサービス）とのデータ交換
は、スコープ外とする。外部とのデータ交換が必要な場合は、外部サービス連携機能により実現するものとする。
ただし、将来的に他自治体、民間などへのデータ公開手段（交換手段）として統合 DB 機能の利用を妨げるものではない。

‐32‐

アーキテクチャ標準仕様 V3.2

業務ユニットB

業務ユニットA
機能

外部ｻｰﾋﾞｽ
連係機能

データ交換

ＤＢ

機能
ＤＢ

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

自治体1

図４．１６ 自治体間、官民連携におけるデータ交換手段【クラウド間】
統合 DB 機能は、サイト内と同様に「単一自治体内部」をスコープとして利用されるものとする。
ただし、クラウド間の接続形態等を考慮した運用を行う必要がある。

４．５．４．３

業務ユニットとの関係【前提１】
業務ユニットには、自らデータを管理（保持）して、他の業務ユニットにデータを提供する「提供側業務ユニット」と、他の業務ユニットのデータを利用（参照）する「利用側業務ユニット」の２種類がある。これは統合 DB 機能を介したデータ交換における業務ユニットの役割により区別するものであり、一般的には１つの業務ユニットが提供側、利用側の両方を実装する場合が多い。

DB
データ

データ

機能
利用側業務ユニット

提供側業務ユニット

図４．１７ 提供側業務ユニットと利用側業務ユニット

４．５．４．４

統合 DB を前提としないデータ交換の基本アーキテクチャ

地域情報 PF の各ユニットは、SOAP で公開されたインタフェースを通じて、データ交換を行う。これがデータ交換の基本アーキテクチャである。
このインタフェースは、データ交換に主眼を置いたものと、サービス連携に主眼を置いたものがある。これらの具体的な仕様は、自治体業務をはじめとする各業務のアプリケーションユニット標準仕様
により別途規定されるが、ここでは、データ交換に主眼を置いたインタフェースについて、その方式を標準化するものである。

‐33‐

アーキテクチャ標準仕様 V3.2

自治体業務アプリケーションユニット標準仕様で、提供側業務ユニット毎にデータモデル
及び連携I/Fを規定
提供側

連係
インタフェース

利用側

業務ユニットA

ＤＢ－A

A

データA

PULL

業務ユニットX

機能 - X
業務ユニットB

B

ＤＢ－B
データB

PULL

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

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

（ＸＭＬ）

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

利用

図４．１８ 業務ユニット間データ交換の基本アーキテクチャ(例)[データ交換に主眼を置いたインタフェース(通信仕様）]
・業務ユニット間でデータ交換する際のデータ交換 I/F は、各業務アプリケーションユニット標準仕様で別途規定する。
① データ交換 I/F は SOAP による Web サービスを採用する。
② Web サービス仕様として、問合せ XML メッセージに対する結果 XML メッセージを定義する。
③ Web サービス仕様は「問合せメッセージ」に対して、「結果メッセージ」を回答する同期型とする。
[問合せメッセージ]
・利用側業務ユニットは、検索条件（検索項目に対する条件値）を指定した問合せメッセージ（XML）を作成して SOAP リクエストとして送信する。
[結果メッセージ]
・結果は、結果メッセージ（XML）として利用側業務ユニットに回答される。

‐34‐

アーキテクチャ標準仕様 V3.2

４．５．４．５

統合 DB によるデータ交換アーキテクチャ

データ交換に主眼を置いたインタフェース（通信仕様）には、性能、その他の要件から、柔軟にデー
タ交換を行う目的で提供される統合 DB 機能を使用する方法がある。

Ａ

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

Ｃ

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

BPM
SOAP通信

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

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

Data

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

Ｂ

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

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

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

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

利用側
Data

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

図４．１９ 統合 DB 機能によるデータ交換方式

統合 DB 機能は、業務ユニット間におけるデータ交換について、次の 3 種類の使われ方を前提として標準を規定する。
◇A：独立型（統合 DB 機能によるデータ交換のみ）
業務ユニット間で直接データ交換を行うものであり、利用側業務ユニットは統合 DB 機能を介して提供側業務ユニットが提供するデータを取得する。
◇B：本文とリファレンス（統合 DB 機能の検索キーを交換）型
サービス連携としてユニット間で行われる本文の SOAP 通信と連携して、サービス返答側業
務ユニットと、サービス要求側業務ユニット間で統合 DB 機能を介したデータ交換を行うものである。
ここでは、結果の一貫性を保証するため、次の順序によりデータ交換を行う。
‐35‐

アーキテクチャ標準仕様 V3.2
(1)サービス要求側業務ユニットは、サービス返答側業務ユニットに送るデータを準備して統合 DB 機能に提供する。
(2) サービス要求側業務ユニットは、(1)で統合 DB 機能に提供したデータのキー情報をリファレンスとして含むサービス依頼メッセージ（本文）をサービス返答側業務ユニットに送る。
(3) サービス返答側業務ユニットは、(2)のサービス依頼メッセージで指定されたリファレン
スを検索キーとして統合 DB 機能を利用することにより(1)で提供されたデータを取得する。
◇C：BPM 機能と連携した本文とリファレンス（統合 DB 機能の検索キーを交換）型
BPM 機能の制御に基づいて行われるサービス連携について、BPM 機能とユニット間で行われる本文の SOAP 通信と連携して、サービス返答側業務ユニットと、サービス要求側業務ユニット間で統合 DB 機能を介したデータ交換を行うものである。
ここでは、結果の一貫性を保証するため、次の順序によりデータ交換を行う。
(1)サービス要求側業務ユニットは、サービス返答側業務ユニットに送るデータを準備して統合 DB 機能に提供する。
(2) サービス要求側業務ユニットは、(1)で統合 DB 機能に提供したデータのキー情報をリファレンスとして含むサービス依頼メッセージ（本文）を BPM 機能に送る。
(3)BPM 機能は、受け取ったサービス依頼メッセージの処理に必要なサービス返答側業務ユニットに対して、リファレンスを含んだサービス依頼メッセージを送る。
(4) サービス返答側業務ユニットは、(3)のサービス依頼メッセージで指定されたリファレン
スを検索キーとして統合 DB 機能を利用することにより(1)で提供されたデータを取得する。
即ち、統合 DB 機能における利用 I/F の SOAP 通信は次の条件で使われる。
1.
2.
3.
4.

業務ユニットインタフェースを使用する。
通信方式は「リクエスト・レスポンス型同期型レスポンス」のみを使用する。
統合 DB 機能は BPM 制御を受けない。
統合 DB 機能はモニタリングの対象外である。

以上は、業務ユニット間におけるデータ交換以外の用途で統合 DB 機能を使うことを制限するものではないが、その場合も本標準で規定する方法に準じて統合 DB 機能を使う必要がある。
なお、プラットフォーム通信標準仕様の「2.3.2(3)データ交換システムパターン」ではデータ交換シ
ステムのパターンとして Type1～5 の 5 種類を定義しており、上記の「B」，「C」は「Type 3」,「Type5」にそれぞれ対応する。また、通信標準および上記の「サービス要求側業務ユニット」、「サービス応答側業務ユニット」は、統合 DB 機能の「提供側業務ユニット」「利用側業務ユニット」にそれぞれ対応する。
各データ交換方式に共通な統合 DB 機能によるデータ交換アーキテクチャを図４．２０に示す。

‐36‐

アーキテクチャ標準仕様 V3.2

提供モデル

提供側

利用モデル

利用側

業務ユニットA

統合DB

ＤＢ－A

業務ユニットX
A

表Ａ
機能 - X
業務ユニットB

B

ＤＢ－B
表Ｂ
提供Ｉ/Ｆ

【標準２】
提供側業務ユニットで管理され、提供されるデータ項目（データの形式は規定しない）

利用Ｉ/Ｆ

提供I/F及び提供モデルは規定しない【標準１】
利用I/F及び利用データモデル

図４．２０ 統合 DB 機能によるデータ交換アーキテクチャ

統合 DB 機能の標準を次の通り規定する。
【標準１】統合 DB 機能の利用 I/F◇データの参照は、利用側業務ユニットの責任で行う。
統合 DB 機能から取得したデータを利用側業務ユニットが、ローカルに保存、毎回取得、取得のタイミ
ングなど、提供側業務ユニットは関知しない。
利用側業務ユニットが自身の責任で必要に応じてデータを取得する。
なお、４．５．４．４ 統合 DB を前提としないデータ交換の基本アーキテクチャに示す業務ユニット
間におけるデータ交換インタフェースが、この標準１に該当する。
【標準２】提供側業務ユニットによるデータ公開◇データ公開は、提供側業務ユニットの責任で行う。
公開されるデータの更新および頻度は、提供側業務ユニット側の仕様として公開される。
(例：リアルタイム、日時更新、等）ただし、オンライン更新処理時は BPM 機能によるワンストップ
サービスの実現のため、即時更新を前提とする。
また、提供側業務ユニットは、自身のデータが更新されたことを通知しない。
なお、提供側ユニット内のデータベースについては、実装方式は規定しない。
‐37‐

アーキテクチャ標準仕様 V3.2

４．５．４．６

統合 DB 機能の方式

統合 DB 機能の実装は規定しないが、その方式として「公開用 DB 方式」と「共通インタフェース方式」を定義し、方式毎にデータ提供機能を「標準３」「標準４」として定める。

４．５．４．７

公開用 DB 方式

提供側業務ユニット側の DB とは別に、公開用の DB（公開用 DB）を持つシステム（サーバ）を統合
DB 機能として置き、提供側業務ユニットから公開用 DB に登録（提供）されたデータを利用側業務ユニットから参照（利用）する方式である。

提供側

業務ユニットA
ＤＢ－A

業務ユニットB
ＤＢ－B

業務ユニットＣ
ＤＢ－Ｃ

【標準２】
データ公開

利用側

公開用ＤＢ方式の統合DB機能
Ｓ
Ｏ
Ａ
Ｐ

ﾃﾞｰﾀ
交換
I/F
-A

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

ﾃﾞｰﾀ
交換
I/F
-B

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

ＤＢＭＳ

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

Ａ
Ｐ
Ｉ

【標準３】
データ提供

PULL

PULL

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

業務ユニットX

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

機能
X

ＳＱＬ
PULL

【標準１】
利用I/F

図４．２１ 公開用 DB 方式の統合 DB 機能






提供側業務ユニットは、自身の DB 更新に応じて公開用 DB を SOAP あるいは SQL を用いて更新する。
提供側業務ユニット内部でのデータの持ち方は規定しない。
公開用 DB のテーブル構造を含む実装方式については規定しない。
利用側業務ユニットは、提供側業務ユニットとは無関係に公開用 DB に対して SOAP あるいはSQL(SELECT 文)でデータ参照を行う(SQL を採用する際は、ODBC、JDBC 等の互換性の高い API を推奨す
る）。

‐38‐

アーキテクチャ標準仕様 V3.2

【標準３】PUSH 型データ提供機能
公開用 DB 方式の統合 DB 機能を採用する際に必要となる提供側ユニットの機能として、PUSH 型のデー
タ提供機能を次の通り規定する。
ここで、PUSH 型とは、提供側ユニットが、提供するデータに変更が発生したタイミングで、能動的に統合 DB 機能にデータ提供を行うことを指す。
◇

SOAP による PUSH 型データ提供
連係 I/F で規定する Web サービス仕様と等価の PUSH 型データ提供機能により、提供側業務ユニットが統合 DB 機能の DBMS を更新する。

◇

SQL による PUSH 型データ提供
統合 DB 機能の DBMS により規定される手段（SQL）により、提供側業務ユニットが統合 DB 機
能を更新する。

提供側業務ユニットにおいて、PUSH 型データ提供機能によって公開用 DB 方式の統合 DB 機能にデータ提供を行うタイミングと完了確認は、本仕様の 4.5.4.5 に整理されている 3 種類の統合 DB 機能の使われ方により、次のように制御する。
◇A：独立型（統合 DB 機能によるデータ交換のみ）
該当データに求められる最新の値であることに対する要求度合いを考慮して、許容される時間以内に完了するタイミングで PUSH 型データ提供を行う。
◇B：本文とリファレンス型
サービス返答側業務ユニットに渡すべきデータの更新は、該当データの PUSH 型データ提供を行い、その完了を確認した後で、サービス返答側業務ユニットに対する本文の送信を行うこと。
◇C：BPM 機能と連携した本文とリファレンス型
サービス返答側業務ユニットに渡すべきデータの更新は、該当データの PUSH 型データ提供を行い、その完了を確認した後で、BPM 機能に対する本文の送信を行うこと。但し、BPM 機能
側でサービス返答側業務ユニットに本文の送信をするまでの間に、一定の待ち時間を保証できる場合には、その時間内に PUSH 型データ提供が完了することを前提にして、先に BPM 機能に本文を送信することもできる。

４．５．４．８

共通インタフェース方式

統合 DB 機能内に、恒久的な統合データを保持することなく、利用側ユニットからの要求に応じて必要なデータを提供側ユニットから取得して、統合結果として利用側ユニットに回答する方式である。


提供側業務ユニットは、SOAP あるいは SQL でデータを公開する。
利用側業務ユニットは、統合 DB 機能に対して SOAP あるいは SQL(SELECT 文)でデータ参照を行う(SQL を採用する際は、ODBC、JDBC 等の互換性の高い API を推奨する）。
‐39‐

アーキテクチャ標準仕様 V3.2

【標準４】PULL 型データ提供機能
共通インタフェース方式の統合 DB 機能の実装を採用する際に必要となる提供側ユニットの機能として、PULL 型のデータ提供機能を次の通り規定する。
ここで、PULL 型とは、提供側ユニットはデータを提供する手段を公開するが、データの取得は、統合
DB 機能側から必要により行う受動的なデータ提供機能を指す。
◇

SOAP による PULL 型データ提供
連係 I/F で規定する Web サービス仕様と同じ PULL 型データ提供機能。

◇

SQL による PULL 型データ公開
提供側業務ユニットは、自己の DBMS がサポートする API により必要なデータを統合 DB 機能に公開する(API は統合 DB 機能のサポートに依存するが、ODBC､JDBC 等の互換性の高いものを推奨する）。

提供側業務ユニットにおいては、常に最新のデータを統合 DB 機能から PULL 型で参照できるようにすることが重要である。

提供側

利用側

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

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

Ｓ
Ｏ
Ａ
Ｐ

ﾃﾞｰﾀ
交換
I/F
-A

Ｓ
Ｏ
Ａ
PULL Ｐ

ﾃﾞｰﾀ
交換
I/F
-B

PULL

業務ユニットB
ＤＢ－B

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

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

PULL

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

業務ユニットＣ
API
ＤＢ－Ｃ

【標準２】
データ公開

（ＳＱＬ）

PULL

Ａ
Ｐ
Ｉ

Ｓ
Ｑ
Ｌ

【標準４】
データ提供

ＳＱＬ
PULL

【標準１】
利用I/F

図４．２２ 共通インタフェース方式の統合 DB 機能‐40‐

業務ユニットX

機能X

アーキテクチャ標準仕様 V3.2

４．５．４．９

統合 DB 機能における共通ヘッダの扱い

ここでは、プラットフォーム通信標準仕様の「7.1 共通ヘッダで規定するデータ項目」について、
統合 DB 機能における取り扱いを規定する。統合 DB 機能の利用 I/F として、自治体業務アプリケーションユニット標準仕様で規定するデータ交換 I/F を用いるときは、図４．２３に示すように依頼メッセー
ジおよび応答メッセージの SOAP Body 部に、共通ヘッダを使用する。
SOAP Envelope (XML)
SOAP Header
SOAP Body

共通ヘッダ

依頼
ﾒｯｾｰｼﾞ
提供側
業務ﾕﾆｯﾄ統合DB
機能更新

主キー情報：
依頼
ＸＭＬ

提供

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

SOAP Envelope (XML)
SOAP Header

統合ＤＢ
機能の
利用

利用
Data

利用側
業務ﾕﾆｯﾄ

ビジネス情報（メッセージ本体)

SOAP Body

共通ヘッダ

応答
ＸＭＬ

応答

ビジネス情報（メッセージ本体)

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

世帯全員
の
住基情報

４．２３ 共通ヘッダを有する統合 DB 機能の利用 I/F
公開用 DB 方式の統合 DB 機能および共通インタフェース方式の統合 DB 機能について、共通ヘッダを使用するインタフェースを図４．２４、図４．２５に示す。

利用側

提供側

①依頼メッセージ(XML)

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

共通ﾍｯﾀﾞ
ﾒｯｾｰｼﾞ本体

PULL

PUSH型
データ提供機能利用側
業務ﾕﾆｯﾄ

統合ＤＢ
機能の利用

共通ﾍｯﾀﾞ
Data

ﾒｯｾｰｼﾞ本体②応答メッセージ(XML)【利用側のインタフェース仕様】（業務標準仕様のＷＳＤＬで定義）

図４．２４ 公開用 DB 方式の統合 DB 機能における共通ヘッダ‐41‐

アーキテクチャ標準仕様 V3.2

利用側

提供側
③依頼メッセージ(XML)共通ﾍｯﾀﾞ

提供側
業務ﾕﾆｯﾄ

共通ﾍｯﾀﾞ

共通ｲﾝﾀﾌｪｰｽ方式
統合DB機能ﾒｯｾｰｼﾞ本体

更新①依頼メッセージ(XML)

問合せ

PULL

利用側
業務ﾕﾆｯﾄﾒｯｾｰｼﾞ本体

統合ＤＢ
機能の利用

PULL

結果
共通ﾍｯﾀﾞ

共通ﾍｯﾀﾞ
Data

ﾒｯｾｰｼﾞ本体

ﾒｯｾｰｼﾞ本体④応答メッセージ(XML)②応答メッセージ(XML)【利用側のインタフェース仕様】（業務標準仕様のＷＳＤＬで定義）

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

図４．２５ 共通インタフェース方式の統合 DB 機能における共通ヘッダ

利用側業務ユニットから統合 DB 機能を利用するための利用 I/F については標準１で標準化しており、統合 DB 機能の方式に係わらず同じインタフェースを用いる。即ち、利用側業務ユニットは「①依頼メッセージ」により統合 DB 機能に対する問い合わせを行い、統合 DB 機能は「②応答メッセー
ジ」により結果を利用側業務ユニットに返答する。
この利用 I/F における「①依頼メッセージ」「②応答メッセージ」に含まれる共通ヘッダの扱いを
表４．６に示す。
表４．６ 統合 DB 機能における共通ヘッダの扱い（統合 DB 機能の方式に共通）（※1）
No.
（※１）

共通ヘッダのデータ項目

ＸＭＬタグの必須・ｵﾌﾟｼｮﾝ

①利用側依頼ﾒｯｾｰｼﾞ②利用側応答ﾒｯｾｰｼﾞ（業務ﾕﾆｯﾄ→統合DB機能）（統合DB機能→業務ﾕﾆｯﾄ）

2

To

オプション

なし

3

MsgID

オプション

なし

4

RelatesTo

オプション

なし

利用側業務ﾕﾆｯﾄに依存してなし設定される。

5

ReplyTo

オプション

6

受付番号

必須

7

共通ｺﾘﾚｰｼｮﾝｾｯﾄ

オプション

なし

8

ﾋﾞｼﾞﾈｽﾌﾟﾛｾｽ制御情報

オプション

なし
№10の結果情報が０のとき
０：正常に値を返す。
１：返すべき値が存在しない。
（№10の結果情報が「１：提供側の異常」
利用側業務ﾕﾆｯﾄは通常、値 のときは存在しない）

9

業務サービス結果情報

オプション

10

結果情報

オプション

11

システムエラー報告

依頼ﾒｯｾｰｼﾞの値を複製する。

を設定しない。
値が設定されている場合も
統合DB機能は無視する。

０：正常処理１：異常処理異常の詳細状態を示す仕様（変換コード
表等）については今後検討する。
（№10の結果情報が「０：正常」のときは存
在しない）

オプション

(※1)表４．６における「№」はプラットフォーム通信標準仕様の「7.1 表 7.1.2」および「7.1
表 7.1.3」で定義されているデータ項目の「No.」を踏まえており、「No.1:共通ヘッダ」がここでは省略されている。

‐42‐

アーキテクチャ標準仕様 V3.2
①利用側依頼メッセージ：（利用側業務ユニット→統合 DB 機能）
・「№６：受付番号」項目の XML タグは必須だがその他の項目の XML タグは存在しなくても良い。
・№２～８の項目の値は、前提とするユースケースにより利用側業務ユニットが設定するものであり、統合 DB 機能としてはその内容を規定しない。
・№９～１１の項目は、応答メッセージ用の領域であり、利用側業務ユニットは通常、項目の値を設定しないが、設定されていても統合 DB 機能は無視する。
②利用側応答メッセージ：（統合 DB 機能→利用側業務ユニット）
・№２～５、№７、№８の項目は存在しない。
・「№６：受付番号」には、①利用側依頼メッセージの「№６：受付番号」項目の値を複製する。
・「№１０：結果情報」は、統合 DB 機能の処理が正常に完了した場合には「０：正常処理」を設定し、それ以外の場合は「１：異常処理」を設定する。
・「№９：業務サービス結果情報」は、「№１０：結果情報」が「０：正常処理」の場合にだけ存在
し、統合 DB 機能が何らかの値を処理結果として返す場合は「０：正常に値を返す」を設定し、処理結果として返す値が無い場合は「１：返すべき値が存在しない」を設定する。
・「№１１：システムエラー報告」は、「№１０：結果情報」が「１：異常処理」の場合にだけ存在し、その「異常の詳細な状態」を設定する。「№１１：システムエラー報告」への具体的な値の設
定方法の仕様は今後検討する。統合 DB 機能を適用する範囲（主に自治体内）において統一したルールが必要となるため、ガイドラインの３．２．９の解説も参考にされたい。
図４．２５に示すように、共通インタフェース方式の統合 DB 機能では、提供側のインタフェースとして、自治体業務アプリケーションユニット標準仕様で定義している SOAP インタフェースを使用することができる。即ち、統合 DB 機能は、「③提供側依頼メッセージ」によって提供側業務ユニットに問い合わせを行い、提供側業務ユニットは、求められた情報を「④提供側応答メッセージ」として統合 DB
機能に返す。この場合の SOAP メッセージに含まれる共通ヘッダの扱いについて、表４．７で規定する。
表４．７ 共通インタフェース方式の統合 DB 機能における共通ヘッダの扱い(※2)
No.
（※１）

共通ヘッダのデータ項目

ＸＭＬタグの必須・ｵﾌﾟｼｮﾝ

③提供側依頼メッセージ④提供側応答メッセージ(統合DB機能→業務ユニット)(業務ユニット→統合DB機能)

2

To

オプション

なし

3

MsgID

オプション

なし

4

RelatesTo

オプション

なし

5

ReplyTo

オプション

なし

6

受付番号

必須

7

共通ｺﾘﾚｰｼｮﾝｾｯﾄ

8

ﾋﾞｼﾞﾈｽﾌﾟﾛｾｽ制御情報

オプション

空値でも良いなし

提供側業務ユニットに依存して設定される。
・統合DB機能は全て無視する。

なし
オプション

なし

9

業務サービス結果情報

オプション

なし

10

結果情報

オプション

なし

11

システムエラー報告

オプション

なし

№10の結果情報が０のとき
０：正常処理１：結果が存在しない（№10の結果情報が「１：提供側の異常」のときは存在しない）
０：正常処理１：提供側の異常
異常の詳細状態を示す仕様（変換コード表等）については今後検討する。
（№10の結果情報が「０：正常」のときは存在しない）(※2)表４．７における「№」はプラットフォーム通信標準仕様の「7.1 表 7.1.2」および「7.1 表‐43‐

アーキテクチャ標準仕様 V3.2
7.1.3」で定義されているデータ項目の「No.」を踏まえており、「No.1:共通ヘッダ」がここでは省略されている。
③提供側依頼メッセージ：（統合 DB 機能→提供側業務ユニット）
・№６以外の項目について、XML タグは存在しない。
・「№６：受付番号」項目の XML タグは必須だが、その値は空値でも良い。
・個々の利用側依頼メッセージ①に対して提供側依頼メッセージ③を発行する方式の統合 DB 機能において、実装上可能な場合は、利用側依頼メッセージ①の№６：受付番号を提供側依頼メッセージ③の№６：受付番号に設定するのが望ましいが、空値を設定しても良い。
（自治体業務アプリケー
ションユニット標準仕様で規定するインタフェースを用いる際には、統合 DB 機能がモニタリング
対象外なので本項目も使用されない。ただし、受付番号の項目用途の性質から将来の仕様拡張を考慮して推奨するものである。）④提供側応答メッセージ：（提供側業務ユニット→統合 DB 機能）
・№２～８の項目は、提供側業務ユニットによって任意に設定されるが、統合 DB 機能は全て無視することができる。
・「№１０：結果情報」は、提供側業務ユニットの処理が正常に完了した場合には「０：正常処理」を設定し、それ以外の場合は「１：異常処理」が設定される。
・「№９：業務サービス結果情報」は、「№１０：結果情報」が「０：正常処理」の場合にだけ存在
し、提供側業務ユニットが何らかの値を処理結果として返す場合は「０：正常に値を返す」を設定し、処理結果として返す値が無い場合は「１：返すべき値が存在しない」が設定される。
・「№１１：システムエラー報告」は、「№１０：結果情報」が「１：異常処理」の場合にだけ存在
し、提供側業務ユニットの異常内容の詳細について、提供側業務ユニットで規定される値が設定される。
・統合 DB 機能は、№９～№１１の結果情報を受け取り、その内容を適切に判断することにより統合
DB 自身の処理結果の状態に反映して、利用側応答メッセージ②の№９～№１１に設定する。

４．５．４．１０

システムで共通的に参照するデータの扱い

金融機関テーブル、住所辞書等、全システムで共通的に参照するデータは業務間を連携するデータとは性格を異にしているため、統合 DB 機能の範囲外とする。これらのデータは基本的に参照のみのテー
ブル類であり、自治体内（団体内）で複数保持することなく、各自治体で個別に管理・運用されることとする。

４．５．４．１１

バッチ処理方式

バッチ処理については、処理性能を確保するために統合 DB 機能の利用を前提としない。
バッチ処理前に全データを順編成ファイルに抽出しておくなどの、SOAP や SQL アクセスに比較して、高速処理を可能とする方策を採用する。要求される性能要件とシステム運用方式により、バッチ処理方
式は確定されることとする。

‐44‐

アーキテクチャ標準仕様 V3.2

４．５．４．１２


文字コードに関する考え方

統合 DB 機能で交換されるデータの文字コードは、プラットフォーム通信標準仕様の「３. プラットフォーム通信標準のメッセージ定義仕様」を参照。
外字について規定しないが、統合 DB 機能は外字を含むデータの交換を行う必要がある。
外字およびフォントの流通は、統合 DB 機能とは別の仕組み(文字コード管理ミドルウェア）によって、自治体内の地域情報 PF 全体について統一した管理が行われるべきである。

＜＜準拠ルール＞＞【サイト内】(AS-R045401）: 地域情報 PF の統合 DB 機能は、オプションである。(オプション)[4.5.4](AS-R045402）: 統合 DB 機能を使用する場合（AS-R045401）、その方式は、公開用 DB 方式または共通インタ
フェース方式とする。(必須)[4.5.4](AS-R045403）: 統合 DB 機能を使用する場合（AS-R045401）、利用 I/F として、１つ以上の業務ユニットインタフェース標準を実装する必要がある。(必須)[4.5.4](AS-R045404）: 統合 DB 機能を使用する場合（AS-R045401）、利用 I/F として、SQL によるインタフェースを提供してもよい。(オプション)[4.5.4](AS-R045405）: 公開用 DB 方式の統合 DB 機能を使用する場合（AS-R045402）、提供側業務ユニットに対し、
統合 DB の DB 更新機能（PUSH 型データ提供機能）として SOAP または SQL のインタフェースを提供する必要がある。(必須)[4.5.4](AS-R045406）: 共通インタフェース方式の統合 DB 機能を使用する場合（AS-R045402）、提供側業務ユニットが公開する PULL 型データ提供機能（業務ユニットインタフェースまたは SQL）を使って、提供側業務ユニットの業務データを取得する必要がある。(必須)[4.5.4](AS-R045407）: 統合 DB 機能を使用する場合（AS-R045401）、統合 DB と業務ユニットの間で交換されるデー
タの文字コードは PF 標準（UTF-8 または 16）を推奨する。(推奨）[4.5.4](AS-R045408）: 統合 DB 機能を使用する場合（AS-R045401）、統合 DB は外字を扱える必要がある。（必須）[4.5.4]＜＜業務ユニットの準拠ルール＞＞【サイト内】(AS-R045451）: 統合 DB 機能を使用する場合（AS-R045401）、利用側業務ユニットは他の業務ユニットとのデータ交換に統合 DB 機能を利用するべきであり、この際のインタフェースは統合 DB 機能
によりサポートされるものを使用する。 (推奨)[4.5.4](AS-R045452）: 公開用 DB 方式の統合 DB 機能を使用する場合（AS-R045402）、提供側業務ユニットは自己が管理する DB 更新後、速やかに統合 DB 機能がサポートする提供 I/F による PUSH 型のデータ提供を行う必要がある (必須)[4.5.4](AS-R045453）: 共通インタフェース方式の統合 DB 機能を使用する場合（AS-R045402）、提供側業務ユニッ
トは自己が管理する DB の対象データについて、SOAP または SQL にて統合 DB にデータ公開する機能（PULL 型データ提供機能）を持つ必要がある。(必須)[4.5.4]‐45‐

アーキテクチャ標準仕様 V3.2

用語の定義
項番

用語

意味

1

業務ユニット

独立して特定の業務を処理するユニットで、ユニット毎に業務固有のマスタ
DB を持つ。

2

統合 DB 機能業務ユニット間で、データを利用（参照）する仕組みであり、実装方式として【公開用 DB 方式】と【共通インタフェース方式】がある。

3

提供側業務ユニット

統合 DB 機能に対して、自己で管理するデータを提供する役割を持つ業務ユ
ニット。

4

利用側業務ユニット

統合 DB 機能で公開されているデータを利用する業務ユニット。

5

提供 I/F

6

利用 I/F

7

PULL 型（のデータ交換）
PUSH 型（のデータ交換）

提供側業務ユニットから統合 DB 機能にデータを提供する機能を持つインタ
フェース。
統合 DB 機能を利用側業務ユニットからアクセスして利用（参照）する機能を持つインタフェース。
データの要求元から発行された要求に対して、求められたデータを要求元に送る方式。
データの送り側が、送り側のタイミングで能動的に送り先に対してデータを
送る方式。

8

‐46‐

アーキテクチャ標準仕様 V3.2

４．６

地域情報 PF の実装イメージ

自治体内ワンストップサービスをシステム実装する際、地域情報 PF を用いた自治体システムのシス
テム構成例および詳細なアーキテクチャ例を記す。

４．６．１

システム構成例

バリエーションとして、BPM 機能、統合 DB 機能は 1 台以上のサーバ装置で実装される。また両者を統合しても良い。

地域情報ＰＦ実装の例 －自治体内システムの構成例

利用者端末（住民）

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

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

業務ユニットサーバ
(住基)
住基
住基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サーバ

PF通信機能統合DB機能図４．２６ 地域情報 PF を用いた自治体内システムの実装例‐47‐

アーキテクチャ標準仕様 V3.2

４．６．２

実装アーキテクチャ例

地域情報 PF の適用範囲(基本的な構成例)を以下に示す。
・PF 通信機能 ・BPM 機能 ・統合 DB 機能【凡例】

利用者(住民)PF通信機能業務ユニット

フロント系業務ユニット

自治体ポータル／申請

WSDL
業務ｻｰﾋﾞｽ

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

BPM機能

サービス基盤

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

業務
ｻｰﾋﾞｽ

更新

業務
ｻｰﾋﾞｽ

参照

業務
ｻｰﾋﾞｽ

業務
ｻｰﾋﾞｽ

統合DB機能共通系業務ユニット

利用者（職員）

バック系業務ユニット

ＰＦ通信機能利用者（職員）図４．２７ 地域情報 PF の実装アーキテクチャ例（自治体）

地域ポータル
住民端末

地域ポータル

自治体ﾎﾟｰﾀﾙ/申請

受付

受付

認証依頼

BPM

受付・進捗
管理ＤＢ

国保ユニット

統合
結果取得
DB

BPM

進捗問合せ
格納
処理呼出し

受付・進捗
管理ＤＢ

進捗格納

ネットワークWeb
ブラウザ＋
クライアントソフトウェア

同様

署名検定

受付
住基ユニット

ＩＤ採番

ネットワーク

申請書送信

申請書受信

BPM

ネットワーク

署名付与

認証

申請書受信

認証

申請書作成

自治体Ｂ
自治体Ａ

認証

児童ユニット

BPM

公文書管理
取得管理

進捗問合せ
結果取得

認証依頼

認証

認証

銀行

受付

進捗確認
進捗問合せ

進捗問合せ

BPM

結果取得

公文書管理
取得管理
結果取得

サービス
モジュール

認証

結果格納

電力会社

受付
進捗問合せ

署名検定

結果取得

TLS暗号
申請者認証

税ユニット

結果取得

結果取得

TLS暗号
サイト認証＋申請者認証

BPM

サービス
モジュール

TLS暗号
職員認証

図４．２８ 地域情報 PF の実装アーキテクチャ例（自治体間や自治体と民間間）‐48‐

アーキテクチャ標準仕様 V3.2

５．採用する技術標準
５．１

採用する標準地域情報 PF は、高付加価値サービスを提供し、マルチベンダ化を図ることができるものである。このため、地域情報 PF の要件として、３．１．２で示したように、（１）業務ユニット単位の差し替えの実現（２）業務サービスの連携の実現（３）ワンストップサービスを含む業務サービスの連携の実現ができる基盤である必要がある。
上記の地域情報 PF の要件を実現するために、地域情報 PF 標準仕様では、世界的に標準化され、調達および実現が可能な技術標準を積極的に採用し、業務ユニット間やマルチベンダ間の相互接続性を確保する。
本章では、地域情報 PF で採用する技術標準、および、地域情報 PF の管理範囲、オプションの考え方について記載する。

５．２

技術マップ

技術マップは、地域情報 PF で採用する国際標準を、通信上のプロトコルスタックとして表現したものである。自治体内部や他自治体間、民間間を想定した基本となる技術マップを図５．１および、図５．２に示す。

【自治体内】

V2.0で追加した機能

ＩＣＴ
サービ ス

サービス連携型アプリケーション、運用管理アプリケーション

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

ビジネス文書定義、
インタフェース定義、
ビジネスプロセスの定義(BPMN、WS-BPEL 2.0
XML Schema 1.0 、WSDL 1.1)

ビジネスプロセス
管理機能（BPM機能）（オプション）(WS-BPEL 2.0)

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

ユーティリティ機能（オプション）
モデル定義言語(UML、BPMN)

時刻同期機能サービス・
レジストリ機能

リポジトリ機能

PF通信機能メッセージ交換パターン
開発環境

添付付きメッセージング （オプション）（メッセージ本体格納型 and メッセージへの添付 (SwA) 型）
高信頼性通信機能（オプション） (WS-Reliability 1.1、WS-ReliableMessaging 1.1)

基本メッセージ (SOAP 1.1 and Basic Profile 1.0)
転送プロトコル (HTTP 1.1)
通信セキュリティ (TLS 1.1 or TLS 1.2)
インターネットプロトコル (TCP/IP)

OS (Windows or UNIX or Linux)

サービス開発環境

地域情報プラットフォーム標準化範囲

図５．１ 技術マップ（自治体内）

‐49‐

ビジネス
メッセージ
ルーティングゲートウェイ機能

アーキテクチャ標準仕様 V3.2

【サイト間】

V2.0で追加した機能

ＩＣＴ
サービ ス

サービス連携型アプリケーション、運用管理アプリケーション

ワンストップＸＭＬスキーマ、
ＷＳＤＬ策定手順（WSDL&BP定義手法）（ガイドライン）

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

ビジネスプロセス
管理機能（BPM機能）（オプション）(WS-BPEL 2.0)

ビジネス文書定義、
インタフェース定義、
ビジネスプロセスの定義(BPMN、WS-BPEL 2.0
XML Schema 1.0 、WSDL 1.1)

モデル定義言語(UML、BPMN)

モニタリング機能（オプション）

ユーティリティ機能（オプション）

時刻同期機能サービス・
レジストリ機能

ビジネス
メッセージ
ルーティングゲートウェイ機能

統合レジストリ機能

リポジトリ機能

認証・認可・セキュリティ機能 （オプション）
PFサイト
認証仕様

PF秘匿性
確保仕様

PF自治体
組織電子
署名・検証
仕様

PF本人
電子署名・
検証仕様

PF
サービス認証・
サービス認可連携仕様

PFプライバシ
情報公開仕様

PF監査証跡仕様

PF通信機能開発環境

メッセージ交換パターン
添付付きメッセージング （オプション）（メッセージ本体格納型 and メッセージへの添付 (SwA) 型）
高信頼性通信機能（オプション） (WS-Reliability 1.1、WS-ReliableMessaging 1.1)

基本メッセージ (SOAP 1.1 and Basic Profile 1.0)
転送プロトコル (HTTP 1.1)
通信セキュリティ (TLS 1.1 or TLS 1.2)
インターネットプロトコル (TCP/IP)

OS (Windows or UNIX or Linux)

地域情報プラットフォーム標準化範囲

サービス開発環境

図５．２ 技術マップ（サイト間）

５．３

地域情報 PF におけるオプションの考え方（１）オプションの定義
・オプションとは、ユースケースにより要不要の判断が必要となるものであり、地域情報 PF の機能を構成する国際標準仕様（バージョン含む）およびプラットフォーム共通機能が対象となる。
・オプションの仕様・機能の導入可否の判断は地域情報 PF を導入する団体が行う。
・オプションは異なる業務ユニット間、および異なるサイト間(自治体間、官民など)の通信において支障を発生させず、通信が可能となるものがオプションとなる。
（２）オプションと通信のイメージ

自治体A

自治体B

自治体A

自治体B

必須仕様

必須仕様

必須仕様

必須仕様

必須

必須

OP

サイト間の通信にはオプションは
存在しない
図５．３

通信に影響を与えないものがオプションとなるオプションと通信のイメージ‐50‐

アーキテクチャ標準仕様 V3.2

６

プラットフォーム通信における MEP とエラー時の対応処理
本章では、地域情報 PF におけるサービス通信のエラー時の異常系処理について規定する。
詳細は「プラットフォーム通信標準仕様」で規定する。

‐51‐

アーキテクチャ標準仕様 V3.2

７．用語集
本章では、地域情報プラットフォームで使われる、用語集を記載する。

７．１

ユニット、システム等の考え方－用語の意義

機能（例:印鑑登録処理）

・・
・・
・・

機能（例：ＸＸＸ）
・・
・・
・・

機能
業務ユニットにおける、サービス部分

業務ユニットにおける機能（インタフェースが定義される単位）

業務アプリケーション
ユニットにおいて，電子化が可能な部分がプログラム・コーディングされたもの

ユニット、システム等の考え方－用語集├フロント系業務ユニット

・
・
・・
・
・
・
・・
・
・
・
・

ｨ I
iﾀ Iﾈ\ｻj└業務サービス

・
・
・・
・
・
・
・
業務ユニットにおける機能（イン ・タフェースが定義される単位）
・・
電子的な窓口となるユニット（電・子申請、電子調達、自治体ポー
用語の説明

ワンストップサービス及びマルチベ
ンダ化が実現できる業務システムの単位
地域情報PFでは業務の単位を業務ユニットと呼ぶ（自治体の
調達単位）

_ I
iTOIﾈ\ｻj

用語
業務ユニット用語

業務処理を実行するための、１台もしくは複数のコンピュータ、ソフトウェ
ア、ハードウェア、ネットワーク等から構成される業務処理装置+ 機能

業務アプリケーションにおける業務
処理部分+ 業務アプリケーション

利用者に業務サービスを提供するプ
ログラム
業務ユニットにおいて電子化が可能な部分がプログラム・コーディングされたものの総称+ PKG（パッケージ）

製品ベンダが業務アプリケーションのうち汎用的な部分を製品化したものタル等）└ポータルサイト

利⽤者とのインタフェースとなるユ
ニット├地域ポータルサイト

住⺠が官⺠連携サービスを利⽤する際の出発点となるサイト├自治体ポータルサイト

住⺠が自治体内・間連携サービ
スを利⽤する際の出発点となる
サイト├バック系業務ユニット

基幹業務、内部管理業務（住⺠基本台帳、市町村⺠税、介護保険等）└共通系業務ユニット

複数の業務で共通的に利⽤される業務（⽂書管理、電子収
納、電子決済等）

‐52‐

用語の説明

業務システム業務 アプリケーション

機能（例:転出処理）（（
パッケージ）
PKG

機能（例:転入処理）

業務サービス（例：ＸＸＸ）

業務サービス

７．２

業務システム（例：住基システム）
業務システム（例：住基システム）

職員による手作業の部分（
申請書の目視確 認など）

業務サービス（例:印鑑登録処理）

電 子化が可能な部分

電 子化が不可能な部分（
職員による申請書 の目視確認など）

業務サービス（例:転入処理）

業務処理を実行するための、１台もしくは複数のコンピュータ、ソフト
ウェア、ハードウェア、ネットワーク
等から構成される業務処理装置

物 理的 （実装的な表 現）論 理的 （
概念的な表 現）業務ユニット（例：住基）
業務ユニット（例：住基）

業務サービス（例:転出処理）

ＰＫＧ（パッケージ）（ＡＰＰ）
業務アプリケーションのうち，製品ベンダが汎用的な部分を製品化したもの

業務システム業務ユニットワンストップサービス及びマルチベンダ化が実現できる
業務システムの単位

アーキテクチャ標準仕様 V3.2

７．３

申請データ、様式の考え方－用語の意義
様式の考え方

申請データの考え方
申請情報＜シングル様式（１様式）＞

申請書

引越し届
申請書
様式

引越し届
名前 ：
旧住所：
新住所：
世帯主：
子供の年齢：
・
・

氏名

○○ ○○

新住所

××市 ××町

前住所△△市 △△町

届出日

XXXX年 XX月 XX日

署名

世帯所得
世帯構成
添付書類

＜マルチ様式（複数様式）＞

・
・
・

申請データ

転出証明書
署名
署名情報

７．４

転入届
名前 ：
旧住所：
新住所：
世帯主：
・
・
・

児童届
名前 ：
旧住所：
新住所：
子供の年齢：
・
署名
・
署名
・

異動届
名前 ：
旧住所：
新住所：
世帯主：
・
・
・

署名

申請書の考え方－用語集

用語

用語の説明

申請データ

申請手続きを電子的に行う上で申請者と行政機関間、共管申請の場合には関係行政機関間で受渡しする情報の全て├ 構成管理情報

申請データに含まれる各要素を取り纏めるための管理情報等├ 申請書

定められた申請書様式に申請情報が入力されたもの├ 申請書様式

地方公共団体にて定められた、申請書の様式├ シングル様式（１様式）

複数の申請手続きの申請様式を1つの申請様式にまとめた申請様式のこと└ マルチ様式（複数様式）

各申請手続き毎に申請様式をまとめた申請様式のこと└ 申請情報申請者により申請書様式に入力された情報├ 添付書類

各手続に必要となる申請書以外の情報(国・地方公共団体等が発行する証明書、図面等）└ 署名情報申請者が行った電子署名に関する署名値、申請者証明書等の署名関連情報‐53‐

アーキテクチャ標準仕様 V3.2

７．５

その他用語

項番

用語

意味

1

サイト

一箇所に設置された１台のコンピュータ、もしくは連動する複数のコンピュータで構成されるシステムであり、場所名や企業名等の一意の論理的な ID で他のコンピュータからアクセス可能なもの。

2

高付加価値サービス

ユーザが要求するサービスを単一のインタフェースのみで提供するサービス。例えば、引越しの申請をすると、住所変更だけでなく児童手当変更
や転校処理、ガス、電気、水道等の利用終了/開始処理を同時に行うようなサービスを示す。(コンポジットサービスの意)

3

プラットフォーム

システムの基盤となるハードウェア、OS、ミドルウェアの組み合わせ。
この上にサービスを構築する。

4

ビジネスプロセス

企業等の団体が業務を遂行するために行う処理の手順を示したもの。情報システムが実行するサービスや手動で行う処理を組み合わせて表現される。

5

サービス提供者

自治体、ガス会社、水道会社などの地域サービス提供者

6

サービス利用者

住民、地場企業、自治体などの地域サービス利用者

7

相互接続

複数（基本的に２つ以上）のシステム間をそれぞれ接続すること

8

トランザクション管理

9

PF 通信

トランザクション（一連の処理）が整合性を持って実行されることを管理する。
PF 通信機能同士によるプラットフォーム通信仕様に基づいた通信‐54‐アーキテクチャ標準仕様 V3.2

７．６

差し替えの定義（１）目的
業務ユニット単位で差し替えを可能とすることで、マルチベンダ化を実現する（自治体におけるシステムを独占するベンダを減らし、システム調達の適正化を図ることを可能とする）。
（２）要件
目的を達成するための条件を以下に記す。
【要件１】調達単位で差し替えが可能な範囲であること。
【要件２】地域情報 PF を介し、標準化された XML タグでシステム間のデータ連携が可能であること。
【要件３】標準化されたインタフェースを実装していること。
（３）差し替えの定義
下図に、要件に合わせて整理する。

差し替えの定義
Ａ

要件

業務アプリケーション+ ミドルウェア/OS
A

業務アプリケーションA

住基(A社)

業務アプリケーションA

住基(B社)
PF標準Webｻｰﾋﾞｽ
DB
連携ﾓｼﾞｭｰﾙ(B社)
ｱﾀﾞﾌﾟﾀｱﾌﾟﾘｹｰｼｮﾝ
ｻｰﾊﾞ(B社)
WSDL/SOAPOS

PF標準Webｻｰﾋﾞｽ
DB
連携ﾓｼﾞｭｰﾙ(A社)
ｱﾀﾞﾌﾟﾀｱﾌﾟﾘｹｰｼｮﾝ
ｻｰﾊﾞ(A社)
WSDL/SOAP
OS

備考

要件１

要件２

要件３

○
サーバごとの調達が可能で差し替えが容易。

○○
データ連携可能。 通信標準はミド
ルウェアを含めたインタフェー
スを規定している。

×
業務アプリ
ケーションとミ
ドルウェアの親和性のテストが必要。

○
×
データ連携可能。 業務アプリケー
ションデータのみの標準化インタフェースは規定していない。

OS
ｱﾌﾟﾘｹｰｼｮﾝ
ｻｰﾊﾞ

WSDL/SOAP

PF標準Webｻｰﾋﾞｽ
連携ﾓｼﾞｭｰﾙ

業務アプリケーションと親和性の高いミドルの選択が前提。
サーバ単位で調達する場合、
サーバ内のマルチベンダ構成は可能。

BPM(ﾜｰｸﾌﾛｰｴﾝｼﾞﾝ)

B

業務アプリケーション単体
B

業務アプリケーションB

業務アプリケーションA

住基(A社)

住基(B社)DB
ｱﾀﾞﾌﾟﾀDB
ｱﾀﾞﾌﾟﾀ

PF標準Webｻｰﾋﾞｽ
連携ﾓｼﾞｭｰﾙ(A社)
ｱﾌﾟﾘｹｰｼｮﾝ
ｻｰﾊﾞ(A社)OS

WSDL/SOAP

OS
ｱﾌﾟﾘｹｰｼｮﾝ
ｻｰﾊﾞ

WSDL/SOAP

PF標準Webｻｰﾋﾞｽ
連携ﾓｼﾞｭｰﾙ
BPM(ﾜｰｸﾌﾛｰｴﾝｼﾞﾝ)‐55‐

業務アプリケーションが前提としているミドルを選択できるか。

アーキテクチャ標準仕様 V3.2
利用条件
本書は、本書の内容および表現が変更されないこと、および出典、著作権表示を明示することを前提に、無償でその全部または一部を複製、転記、引用して利用できます。なお、全体を複製された場合は、本利用条件を明示してください。
一般財団法人全国地域情報化推進協会が公開するドキュメントの内容は無保証で提供されます。ここに含まれる情報の利用について商品性、特定目的適合性や第三者権利の不侵害その他一切の、明示的、黙示的保障を行いません。

Copyright ©一般財団法人全国地域情報化推進協会 2007-2018 All rights reserved.

‐56‐