次次世世代代電電子子行行政政ササーービビスス

基基盤盤等等検検討討ププロロジジェェククトトチチーームム

中中間間報報告告（（案案））

平成21年10月26日

次世代電子行政サービス基盤等検討プロジェクトチーム

資料４

目次

I 標準モデル構築に向けた技術的方策を中心として................................................................................ 1

１． はじめに..........................................................................................................................2 １．１ 次世代電子行政サービスの目標 ............................................................................................. 5

（１） 利用者視点でのサービス提供 .........................................................................................................6 （２） 組織横断的な行政事務の 適化の推進 ..........................................................................................7 （３） 民間企業活動の活性化...................................................................................................................8 （４） 国民と行政の信頼強化 ...................................................................................................................8

１．２ 次世代電子行政サービス基盤のイメージ図 ........................................................................... 10 （１） 利用者へのサービス .....................................................................................................................10 （２） 民間の業務サービスとの連携........................................................................................................ 11 （３） 各種ポータルサイトとの連携.......................................................................................................... 11 （４） 行政サービス連携と民間サービス連携 .......................................................................................... 11

２． ライフイベントに関する次世代電子行政サービス ............................................................12 ２．１ ライフイベントに関する行政サービスへのニーズ .................................................................... 12

（１） ライフイベントに伴う手続の利便性イメージ .....................................................................................12 （２） 実際に経験した者が不便に感じたライフイベント関連手続...............................................................12 （３） ライフイベント関連手続の際にどのような点を不便に感じたか（個人）...............................................13 （４） ライフイベント関連手続の際にどのような点を不便に感じたか（企業）...............................................14

２．２ 添付書類の調査結果 ............................................................................................................ 15 ２．３ 情報提供サービスの必要性 .................................................................................................. 17 ２．４ 調査結果を踏まえて .............................................................................................................. 18

３． 次世代電子行政サービスを実現する技術的方策の方向性 .............................................19 ３．１ 次世代電子行政サービス基盤の全体像 ................................................................................ 19 ３．２ 公共サービスポータルに関する方策 ...................................................................................... 20 ３．３ サービス連携を実現するために「公共サービス連携基盤（仮称）」側に求められる機能 ............ 22

（１） 各機関への申請振り分けと処理状況の管理 ..................................................................................22 （２） 各機関とのサービス連携 ...............................................................................................................23 （３） 各機関のハブ機能等.....................................................................................................................23

３．４ サービス連携を実現するために各機関側に求められる機能 ................................................... 24 （１） バックオフィス連携用データストア ..................................................................................................25 （２） 外部連携サービス.........................................................................................................................25 （３） 標準変換アダプタ..........................................................................................................................25

３．５ データの標準化を推進する方策............................................................................................. 25 （１） 全体標準ライブラリ .......................................................................................................................26 （２） 標準のデータ仕様に変換するための各種変換ライブラリの提供 ......................................................26 （３） データ標準化に向けたルール........................................................................................................27

３．６ 検討すべき技術要素 ............................................................................................................. 28 ４． 公共サービスポータルを実現する技術要素....................................................................30

４．１ 公共サービスポータルの検討 ................................................................................................ 30 （１） 公共サービスポータルの要件 ........................................................................................................30 （２） プル型情報提供機能/カスタマイズ機能 ..........................................................................................30 （３） インテリジェント検索機能 ...............................................................................................................31 （４） プッシュ型情報提供機能 ...............................................................................................................32 （５） エージェント型情報提供機能 .........................................................................................................33 （６） ワンストップ申請機能 ....................................................................................................................34 （７） 認証・署名機能 .............................................................................................................................34

５． 「公共サービス連携基盤（仮称）」を実現する技術要素 ....................................................36 ５．１ 接続機関との連携方式の検討............................................................................................... 36

（１） 「公共サービス連携基盤（仮称）」の要件.........................................................................................36 （２） 「公共サービス連携基盤（仮称）」の機能概要 .................................................................................38 （３） サービス連携利用イメージ.............................................................................................................40 （４） 各機関とのサービス連携方式のパターン .......................................................................................44 （５） 連携方式の同期レベル .................................................................................................................48 （６） 次世代電子行政サービス基盤におけるセキュリティの考え方 ..........................................................49 （７） ディレクトリの考え方......................................................................................................................50 （８） 各機関の保有するデータの文字コードに関する検討.......................................................................52

５．２ データ標準化等の検討 .......................................................................................................... 53 （１） データ標準化に関する現状 ...........................................................................................................53 （２） データ標準化における「公共サービス連携基盤（仮称）」の位置づけと機能 ......................................54 （３） 標準ライブラリの考え方.................................................................................................................56 （４） 標準変換アダプタの考え方............................................................................................................57 （５） データの連携粒度と段階的ステップ ...............................................................................................59 （６） 標準化ルールの概要 ....................................................................................................................62 （７） 標準化ルールの関連性.................................................................................................................63

５．３ 利用者と行政情報の連携の検討 ........................................................................................... 64 （１） 利用者と行政情報の連携に関する課題と方向性............................................................................64 （２） 方向性を実現するための基盤のイメージ........................................................................................65

６． 次世代電子行政サービスの実現に向けて ......................................................................67 ６．１ 実現に向けての作業 ............................................................................................................. 67

（１） 業務改革の流れ ...........................................................................................................................67 （２） 電子行政サービス基盤の技術面からのあるべき姿の検討 ..............................................................69 （３） 提供サービスメニューの整理 .........................................................................................................69 （４） 必要なデータ項目を保管しているシステムの洗い出し.....................................................................70 （５） データ標準化の進め方..................................................................................................................71 （６） 文字コードに関する検討................................................................................................................72 （７） 利用者と行政情報の識別子に関する今後の検討課題 ....................................................................73

６．２ 実現に向けての展望 ............................................................................................................. 74

Ⅱ引越ワンストップサービス実現へ向けての段階的アプローチ（案）

Ⅲ退職ワンストップサービス実現へ向けての段階的アプローチ

I .標準モデル構築に向けた技術的方策を中心として １．はじめに

1

I 標準モデル構築に向けた技術的方策を中心として

I .標準モデル構築に向けた技術的方策を中心として １．はじめに

2

１．はじめに

20世紀後半より急速に展開した情報通信技術（Information and Communication

Technology）によって、21世紀の社会は大きな変容を遂げようとしている。具体的には、全

人類において情報の発信が可能となる情報爆発時代となり、その対応のため、いかに情報

通信技術を積極的に利活用していくかという課題に直面している。また、ブロードバンド化

による情報ネットワーク化やグローバル化は、国家と個人の在り方を含め社会システムの

基礎の部分を大きく変化させつつある。

ネットワークの高度化、低コスト化により、内部におけるイノベーションを活性化するとい

う意図を持って外部と協働し、爆発的に増加する情報をダイナミックに利活用して新しい価

値を共創する時代を迎えようとしており、このような時代に対応できるインフラ環境や制度

などの整備が必要となっている。

こうした流れの中で電子政府・電子自治体の取組は、国の手続の92%がオンライン化済

みだがオンライン利用率は34.1%1と低迷している。これまでの縦割り行政のまま行政手続を

オンライン化しても利用者にとっては利便性が低く、サービス提供側でも業務の効率化がで

きないため利用が促進されない状態である。そこで、国民や企業にとって飛躍的に簡素で

便利、かつ効率的な行政サービスの実現に向けて、「次世代電子行政サービス基盤等検

討プロジェクトチーム」が平成19年10月に設置された。このプロジェクトチームにおいて、

国・地方の枠を超えた電子行政窓口サービスの展開を念頭に置き、フロントオフィスとバッ

クオフィス、及びバックオフィス相互の連携や民間手続との連携等を図ることにより、様々な

行政手続を基本的にワンストップで簡便に行える次世代の電子行政サービス基盤の標準

モデルの構築に向けた検討を行ってきたところである。

しかし、次世代の電子行政サービス基盤は手続のワンストップサービスを提供するレベ

ルに止まらず、その先には産・官・学が参加するネットワークを含むITやそれ以外の手法を

有機的に結びつけて、日本社会におけるイノベーションや、国際競争力の強化をもたらす

「国民本位の究極の電子社会の実現」を 終的な目標とするものであり、ワンストップサー

ビスは「国民本位の究極の電子社会の実現」に向けたインフラ構築のための第一歩となり

得るものである。

国民本位の究極の電子社会の実現はIT環境を整備すれば達成できるものではなく、行

政における国民視点でのサービス提供というサービス向上への意識改革、フロントオフィス

やバックオフィス、組織単位での 適化ではなく、組織の垣根を取り払った行政全体での全

体 適化を意識した業務改革、行政ガバナンスを意識した透明性の確保などを伴い初め

て実現できるものであることを肝に銘じて実現に向けて推進するものである。

I .標準モデル構築に向けた技術的方策を中心として １．はじめに

3

（中間報告に当たって）

平成20年6月の「次世代電子行政サービスの実現に向けたグランドデザイン」を受けて、

同年10月から行われた、標準モデル構築に向けた技術的方策を中心とした検討、かつ、引

越及び退職サービスのワンストップサービス実現へ向けての段階的アプローチをまとめた

ものが、この度の中間報告である。特に、次世代電子行政の技術的方策について、バック

オフィス連携を進める観点からできるだけ具体的に示すことが、今回の中間報告の中心で

あると言えよう。

複数の関連する手続を一度に行えるようにするワンストップ化は、国・地方のバックオフィ

ス間のデータ連携が実現して初めて可能になる。それらが実現していない状態でサービス

のワンストップ化を進めても、マニュアル業務や重複投資が増え、コストや人的負担、入力・

照合ミスなどが増大してしまう。バックオフィス連携を実現するために重要なのは、各機関

の保有するデータの連携と、国民の個人情報を保護する第三者による監視の仕組みの導

入である。行政実務の現場においては、データの連携なくしては情報の正確かつ効率的な

管理と運用が困難である。年金記録の管理不備に見られるように、むしろ国民に不利益を

もたらしてしまう。データの連携状況を監督するため、個人情報保護に関する第三者的な

監視の仕組みを導入し、個人情報の適切な管理・運用をチェックする体制を整えれば、行

政の透明化を推進しながら、行政業務・システムの抜本的な改革を推進することが可能に

なろう。

行政組織が保有するデータの連携は、集中管理ではなく、疎結合（ 小限の影響、依存

関係での連携）による分散管理で実現することができる。わが国の行政情報化には長い歴

史があるため、多くの行政組織は基幹系のレガシーシステムを抱えている。行政組織間で

データを連携させるためには、今ある業務とデータを見える化し、より標準的なシステムへ

と抜本的に再構築することも、場合によっては必要になるであろう。しかし、連携させたいデ

ータを構造化し、メタデータ（行政情報の所在、保有している機関、およびアクセス方法等や

データの形式に関するデータ）を参照できるような仕組みと、インターフェースの仕様と変換

ルールのみ整えられれば、異なる技術仕様に基づく既存システムを連携させることが技術

的には可能である。行政情報を一か所に蓄積するのではなく、公共サービスの連携機能を

付与された基盤が各データのメタデータを管理し、開示・利用可能なデータそのものは当該

データが格納されているデータベースを保有する各行政機関が管理することにより、一カ所

に集約されたデータ漏洩の影響等に関して、セキュリティリスクを低減することも可能にな

る。

1 出典：総務省 平成 20 年度における行政手続オンライン化等の状況 http://www.soumu.go.jp/main_content/000031924.pdf

I .標準モデル構築に向けた技術的方策を中心として １．はじめに

4

なお言うまでもなく、バックオフィスにおける業務フローの見直しを行う際にも費用対効果

の見極めが重要である。SOA（Service Oriented Architecture、サービス基点のアーキテク

チャ）ベースの電子行政サービス基盤を構築し、コンポーネント化された業務モジュールを

ASP（Application Service Provider）やSaaS（Software as a Service）の仕組みを用いて 大

限活用しようと思うならば、現行の業務用システムをゼロベースで見直す必要があるかもし

れない。だが一方で、少なくとも移行期においては、既存のシステムを活用することがコスト

面で合理的でありうる。したがって、今後、標準仕様によるデータ連携やシステム連携を実

現することを前提とし、府省間、自治体間、そして国・地方間など多階層のレベルで、段階

的に、しかし着実にデータや業務の標準化を進める必要がある。

国・地方のバックオフィス連携が実現すると、国民、企業等からの申請等に基づいた行

政視点でのサービス提供だけではなく、行政サービスを国民のニーズに基づいて効率的か

つ積極的に提供することができるようになる。たとえば、公共サービスの連携に同意した人

が出産した時には、その出生を届け出るだけで、本人が申請せずとも市町村から児童手当

が支給され、必要に応じて乳幼児医療費の助成が適用されるというようなプッシュ型のサ

ービスを提供することが可能になると考えられる。

将来的には、行政情報のみならず、民間企業のデータベースとの疎結合によって新たな

プロアクティブなIT サービスを創出し、オープン・イノベーションを推進できるIT基盤を整備

すべきであろう。SOA ベースの電子行政サービス基盤に、健康情報活用基盤や地理空間

情報基盤などを接続すれば、このIT基盤は、行政システムのみならず、医療・福祉などの

機関の経営 適化をもたらし、さらには官民連携によるプロアクティブな新サービスの創出

をも可能にするだろう。国と地方の行政組織、地域の医療・福祉関係機関、そして民間企業

をつなぐ電子行政サービス基盤は、短期的な雇用創出や内需拡大に資するだけでなく、中

長期的な競争力の強化につながるものと期待される。

以上のような展望をもって、次世代電子行政サービスの実現に向けた取組を強力に推

進すべきである。

I .標準モデル構築に向けた技術的方策を中心として １．はじめに

5

１．１ 次世代電子行政サービスの目標

次世代電子行政サービス基盤は情報爆発時代においてITを利活用することにより日本

社会を知識創造の社会へ導き、社会インフラの刷新を伴うイノベーションの連鎖を関係する

機関などが情報や知識を共有化し力を発揮できる環境として組織化するものであるが、よ

り具体的に表現すると次の4点の目標により国民本位の究極の電子社会の実現を目指す

ものである。

利用者視点でのサービス提供

組織横断的な行政事務の 適化の推進

民間企業活動の活性化

国民と行政の信頼強化

出典：次世代電⼦⾏政サービス（eワンストップサービス）の実現に向けたグランドデザイン（2008年6⽉4⽇）⼀部修正

２．組織横断的な⾏政事務の最適化の推進

３．企業活動の活性化

４．国⺠と⾏政の信頼強化

ＩＴの活⽤による⾏政サービスの付加価値の向上と効率化の推進フロントオフィスとバックオフィスの双⽅における全体最適を意識した業務プロセス改⾰と標準化の推進紙を中⼼とした業務プロセスから電⼦的処理を原則とする業務プロセスへの変⾰と相談業務などの充実次世代電⼦⾏政サービス実現にあたり費⽤対効果を⼗分意識して推進分散された情報や埋もれた情報のマッシュアップにより、今まで実現できなかったサービスの実現

企業が届出先機関を意識せず⼿続でき、かつ社内業務と⾏政サービスがシームレスに連携できることによる、社内業務の⽣産性向上を実現⾏政サービスに関連する⺠間サービスとの連携を可能とすることで⺠間による新たなサービス創造を可能とし、⺠間企業の成⻑を助勢⾏政が保有する情報を活⽤した新たな⺠間サービス創設の環境作り

サービス向上と新たな価値あるサービスの提供⾏政におけるサービスや情報の⾒える化による、国⺠の意思決定に必要な情報の提供と政策決定プロセスへの参画機会の提供個⼈情報へのアクセス履歴の本⼈からの閲覧プロジェクトの費⽤対効果や進捗状況の透明性の確保⾏政事務の進捗状況を確認できるなどのプロセスの⾒える化の実現個⼈情報保護や適切なセキュリティレベルを意識した安⼼・安全なサービスの提供

国⺠本位の究極の電⼦社会の実現

１．利⽤者視点でのサービス提供国⺠や企業が必要とする⾏政サービスの情報提供と簡素で便利に⼿続できるワンストップサービスの実現サービスを組織単位に提供するのではなく、縦割り⾏政を排除したポータルにて提供

□ イベント時に必要な⼿続情報、⼿続を選択するための情報、国⺠の⾃⼰に関する⾏政情報、埋もれているサービスの⾒える化の実現ＩＴの活⽤による申請主義から脱却したプッシュ型のサービスの実現ＩＴとそれ以外（対⾯、電話など）の⼿段を⽤いた利⽤しやすいワンストップサービスの提供官と⺠の融合したワンストップサービスの実現サービス開始にあたり地域的な差が⽣じない全国規模での⾏政サービス提供

次世代次世代電⼦⾏政電⼦⾏政サービスのサービスの

⽬標⽬標

□

□

□

□

□□

□

□

□

□

□

□

□

□

□□

□□□

□

図 I-1 次世代電子行政サービスの目標

I .標準モデル構築に向けた技術的方策を中心として １．はじめに

6

（１） 利用者視点でのサービス提供

従来の行政サービスは、国民、企業等からの申請等に基づいて、各行政機関の各部署

が各々の業務のみを遂行することに主眼をおいてサービスが組み立てられている。次世代

電子行政サービスは、この行政視点でのサービス提供から国民や企業などの利用者目線

で簡素で便利な行政サービスの提供に大きく方向性を変えるものであり、例えば利用者の

複数機関・複数回の訪問を削減・不要とするために、添付書類の削減や電子化、申請様式

の統一化などが求められる2。

その実現のためには、組織単位ではなく全体 適を意識した行政側の意識改革や業務

プロセスの簡素化等、IT以外の手段も活用したサービスの提供が必要となる。また、企業

の手続も対象とすることで、より利用者の利便性に寄与する広範囲なサービス展開が期待

できることから、民間企業の手続を含めたサービス提供の環境も構築する必要がある。

利用者の利便性と行政の効率化を目的として、複数の関連する手続を一括で行うサー

ビスのことを、ここではワンストップサービスと呼び、その具現化を目指す。ワンストップでの

サービス提供の範囲は、様々考えられるが、国民の生活に密着したサービス提供を目指し、

結婚や引越等のライフイベントを基準として検討を行う。

引越の場合、最⼤７訪問機関、１３添付書類が必要引越の場合、最⼤７訪問機関、１３添付書類が必要退職の場合、最⼤６訪問機関、１５添付書類が必要退職の場合、最⼤６訪問機関、１５添付書類が必要

訪問機関は訪問機関は11か所、添付書類は不要（か所、添付書類は不要（oror電⼦化して提出）電⼦化して提出）●国・地⽅の垣根を取り除いたワンストップサービス●国・地⽅の垣根を取り除いたワンストップサービス●プッシュ型・エージェント型サービス●プッシュ型・エージェント型サービス●申請主義からの脱却●申請主義からの脱却

現状< Government Centric >

現状現状< Government Centric > < Government Centric >

理想像< Citizen Centric >

理想理想像像< Citizen Centric > < Citizen Centric >

⼿続①⼿続①

⼿続②⼿続② ⼿続③⼿続③

⼿続④⼿続④A機関AA機関機関

B機関BB機関機関 C機関CC機関機関

D機関DD機関機関総合総合窓⼝窓⼝

⼿続①⼿続①

⼿続②⼿続② ⼿続③⼿続③

⼿続④⼿続④A機関AA機関機関

B機関BB機関機関 C機関CC機関機関

D機関DD機関機関

図 I-2 ワンストップサービスの概要

行政視点でのサービス提供から、国民や企業などの利用者の目線で、簡素で便

2 国連の E-Government Readiness Index (2008) によれば、日本の電子政府に関する進捗度は世界で１１位、また、各国政府の顧客サービス成熟度調査 2008（アクセンチュア調べ）

によると、公共サービスに対する日本の市民の満足度は低く、調査 21 か国中 20 位に止まっている。後者の調査では、「均一なサービス（公平性）よりも利用者のニーズに応じたサー

ビス（選択性）に注力すべき」と回答した日本の市民の割合が 70%に上り、「ニーズに応じたサービス提供において、日本の産学官民の連携の在り方は効果的ではない」との回答が 8

割近くに達している。

I .標準モデル構築に向けた技術的方策を中心として １．はじめに

7

利な行政サービスの提供に方向性を変換。

利用者の活動起点となるライフイベント単位で手続をワンストップ化し、利用者の

行動フローに即したサービス提供を目指す。

（２） 組織横断的な行政事務の 適化の推進

次世代の電子行政サービスにおいては、国民や企業の利用者の利便性の向上だけで

なく、行政事務の効率化を図る検討が必要である。

行政事務は紙を前提とした業務の 適化や組織内での 適化が図られており、ある程

度の効果は表れているものの、未だITを 大限に活用することを想定した業務の 適化が

達成されているわけではなく、また、行政全体や社会全体から俯瞰した全体 適化の視点

からは、十分に取り組まれているとは言い難い。今後、ITをさらに活用し、電子的処理を前

提とし、かつ縦割り行政を排除した全体 適を目指した業務プロセスに変革していくことが

求められる。

もちろん、この業務プロセスの変革は、利用者視点でのサービス提供を踏まえ、かつ複

数機関において同様な業務が存在する場合には標準化や共同利用などの要素により効率

化を図るものでなければならない。システムにおいても、業務システムの 適化、適応性や

拡張性を考慮し、場合によってはSOA3（Service Oriented Architecture）適用も必要なところ

である。

これらの行政事務の 適化を推進することにより、サービスレベルを向上しつつコストを

削減できることから、更なるサービス向上、新たなサービス創出、地域活性化への投資又

は財政の健全化など機関で優先すべき分野への資源の再配分が可能となる。

（ア） 行政事務の効率化イメージ

次世代電子行政サービス基盤は、利用者に対するワンストップサービスやプッシュ型情

報提供のみならず、行政機関の側でバックオフィス業務の電子的処理を実現させることに

より、入力作業の手間が省けるなど業務効率の向上や、入力ミスがなくなるなど処理の正

確性の向上が期待できる仕組みである。

例えば、ある行政機関と他の行政機関との間で、法令等により通知を義務付けられてい

る事務や、業務上必要な場合に他の行政機関に対して証明書等を請求・発行する事務が

ある。次世代電子行政サービス基盤の構築は、これらの事務を、紙ベースの入出力、郵送

等による方法から、ネットワークを介した電子的な情報流通による方法へ転換させることを

I .標準モデル構築に向けた技術的方策を中心として １．はじめに

8

可能とする。

××××通知書通知書

業務システム業務システム

作成・作成・封⼊・封⼊・送付送付 ⼊⼒・⼊⼒・

確認・確認・更新更新

業務業務システムシステム

（１）通知事務（１）通知事務

業務システム業務システム

抽出・抽出・送付送付

確認・確認・更新更新

業務業務システムシステム

事務作業の軽減等による効率化事務作業の軽減等による効率化

（２）業務上必要な証明書等の請求・発⾏事務（２）業務上必要な証明書等の請求・発⾏事務

××××証明書の証明書の請求書請求書

請求書の作成・請求書の作成・封⼊・送付封⼊・送付

業務業務システムシステム

検索・検索・発⾏発⾏

××××証明書証明書 封⼊・封⼊・送付送付

業務業務システムシステム

確認・⼊⼒確認・⼊⼒

請求請求業務業務

システムシステム

業務業務システムシステム

確認・更新確認・更新 参照⽤参照⽤DBDB

認証認証

事務作業の軽減等による効率化事務作業の軽減等による効率化

現⾏のイメージ現⾏のイメージ 将来のイメージ将来のイメージ

A機関

A機関

B機関

B機関

B機関A機関

B機関A機関

図 I-3 行政事務の効率化イメージ

図 I-3に示すように、（１）の通知事務ではA機関で作成・封入・送付、B機関で入力・確

認・更新と合計6ステップの作業が発生しているが、将来のイメージではそれを4ステップに

し、また、（２）の業務上必要な証明書等の請求・発行事務は、9ステップが4ステップというよ

うに、データ連携を行うことで国民の手続に係る作業・時間を削減でき、国民にとっての利

便性を向上させるとともに、行政の効率化を図る。その際、あわせて、電子的処理を前提と

した、行政事務全体の 適を目指した業務プロセスへ移行させるために、徹底したBPR

（Business Process Reengineering）4が必要である。

（３） 民間企業活動の活性化

民間企業の行政手続との接点部分において生産性の向上を図るだけではなく、次世代

電子行政サービス基盤により行政と民間の情報やサービスの融合や産・官・学によるコラ

ボレーションを可能とし、相互作用を活性化する新たなサービス創出の場とし、社会に知識

を創造するイノベーションをもたらす。また、大量なデータ処理や情報の高度化のために

産・官・学の協働により、世界における日本のプレゼンス向上の活動にも結びつけるもので

ある。

（４） 国民と行政の信頼強化

サービスの質の向上や業務の効率化による信頼強化だけではなく、行政サービス、行政

3 SOA とは、大規模なシステムを「サービス」の集まりとして構築する設計手法。サービスとは、外部から標準化された手順によって呼び出すことができる一まとまりのソフトウェアの

集合であり、単体で人間にとって意味のある単位の機能を持つものを指す。アプリケーションソフト自体に他のソフトウェアとの連携機能を持たせたものと考えても良い。

4 BPR とは、一般的に企業活動に関するある目標(売上高、収益率など)を設定し、それを達成するために業務内容や業務の流れ、組織構造を分析、 適化することを目指す。

I .標準モデル構築に向けた技術的方策を中心として １．はじめに

9

管理の個人情報のアクセス履歴、業務プロセス、事業の進捗などの見える化や透明性を

確保し、信頼強化を深める。また、国民にとっては今まで見えなかった様々なサービスや情

報に触れることで、意思決定のための情報を備えることもできるため、行政における政策決

定プロセスへの積極的な参画も期待できる。

なお、下記図 I-4は国民本位の究極の電子社会の実現に向けた課題について、大きく

「コスト・利用者・業務・ITマネジメント」の４つの観点から、階層的にその関係性を整理した

ものである。ITマネジメントにかかる環境を整備した上で、業務プロセスを見直し、利用者が

使いやすい利用されるサービスを目指す。その結果、システムと業務が 大限効率的に働

く、ムダのない国民本位の電子行政サービスを実現する。

また、今回の取組みによる効果を、生活者に対するサービスレベルの向上にかかる体制

等に振替えることで、努力する機関ほど結果的に住民の利便性向上に寄与する仕組みづ

くりが重要である。

コスト削減、及びコスト削減、及び資源の有効活⽤資源の有効活⽤

利便性向上利便性向上

業務プロセスの改善業務プロセスの改善

技術・体制・法制技術・体制・法制の拡充の拡充

国⺠本位の究極の電⼦社会の実現国⺠本位の究極の電⼦社会の実現

オンライン利⽤率のオンライン利⽤率の向上向上

総合窓⼝化総合窓⼝化

⾏政⼿続にかかる⾏政⼿続にかかる時間時間（待ち時間含む）（待ち時間含む）の削減の削減

複数回・複数場所複数回・複数場所訪問の廃⽌訪問の廃⽌

業務の標準化業務の標準化チャネルの多様チャネルの多様化（化（TVTV、携帯、、携帯、

コンビニ等）コンビニ等）

ワンストップ推進ワンストップ推進組織の確⽴組織の確⽴

添付書類の削減添付書類の削減

⾏政情報の⾏政情報の共同利⽤共同利⽤

⾏政事務の⾏政事務のペーパーレス化ペーパーレス化

サービスのサービスのワンストップ化ワンストップ化

⾏政事務⾏政事務負荷の負荷の削減削減

国⺠国⺠中⼼のｅワンストップ法中⼼のｅワンストップ法制の整備制の整備

オンラインの普及オンラインの普及

コストコスト

利⽤者利⽤者

業務業務

ＩＴマネジメントＩＴマネジメント

ポータルの技術ポータルの技術検討検討

バックオフィス連携のバックオフィス連携の技術検討技術検討

認証・署名の認証・署名の技術検討技術検討

標準化の技術標準化の技術検討検討

⾏政情報の透明化⾏政情報の透明化

⾏政の⾒える化⾏政の⾒える化

ネットワークネットワーク検討検討データ標準化データ標準化

個⼈情報保護に係個⼈情報保護に係るセキュリティ検討るセキュリティ検討

資源の再配分資源の再配分

図 I-4 次世代電子行政サービス 課題の関係整理

I .標準モデル構築に向けた技術的方策を中心として １．はじめに

10

１．２ 次世代電子行政サービス基盤のイメージ図

次世代電子行政サービスのステークホルダーは利用者、行政機関、サービスを提供す

る民間企業と次世代電子行政サービスと連携する様々な外部のサービス提供者からな

る。

各種ネットワーク各種ネットワーク

⺠間企業⺠間企業⺠間企業

銀⾏銀⾏ 保険保険 ｅｔｃｅｔｃ..健保組合健保組合

国国国

省庁省庁

都道府県都道府県都道府県

都道府県都道府県 省庁省庁

市町村市町村市町村

市町村市町村

市町村市町村

都道府県都道府県

⺠間の⺠間の業務サービス業務サービス

（ＡＳＰ、ＳａａＳ）（ＡＳＰ、ＳａａＳ）

⺠間の⺠間の業務サービス業務サービス

（ＡＳＰ、ＳａａＳ）（ＡＳＰ、ＳａａＳ）

⺠間の⺠間の業務サービス業務サービス

（ＡＳＰ、ＳａａＳ）（ＡＳＰ、ＳａａＳ）

⺠間の⺠間の業務サービス業務サービス

（ＡＳＰ、ＳａａＳ）（ＡＳＰ、ＳａａＳ）

⺠間の⺠間の業務サービス業務サービス

（ＡＳＰ、ＳａａＳ）（ＡＳＰ、ＳａａＳ）

⺠間の⺠間の業務サービス業務サービス

（ＡＳＰ、ＳａａＳ）（ＡＳＰ、ＳａａＳ）

⺠間の⺠間の業務サービス業務サービス

（ＡＳＰ、ＳａａＳ）（ＡＳＰ、ＳａａＳ）

⺠間の⺠間の業務サービス業務サービス

（ＡＳＰ、ＳａａＳ）（ＡＳＰ、ＳａａＳ）

⺠間の⺠間の業務サービス業務サービス

（ＡＳＰ、ＳａａＳ）（ＡＳＰ、ＳａａＳ）

各種ポータル各種ポータルサイトサイト

各種ポータル各種ポータルサイトサイト

各種ポータル各種ポータルサイトサイト

各種ポータル各種ポータルサイトサイト

各種ポータル各種ポータルサイトサイト

各種ポータル各種ポータルサイトサイト

各種ポータル各種ポータルサイトサイト

各種ポータル各種ポータルサイトサイト

各種ポータル各種ポータルサイトサイト

チャネルチャネルチャネルパソコンパソコン 固定電話・固定電話・携帯携帯電話電話

ＫＩＯＳＫＫＩＯＳＫ端末端末 ｅｔｃｅｔｃ..窓⼝窓⼝

〜〜 MMenuenu 〜〜次世代電⼦⾏政サービス次世代電⼦⾏政サービス

電⼒会社電⼒会社 ガス会社ガス会社 公共放送公共放送 データデータ

データデータ

データデータ

データデータ

データデータ

データデータ

利⽤者利⽤者利⽤者 個⼈個⼈ 企業企業 ・法⼈認証カード・法⼈認証カード・ＩＤ・パスワード等・ＩＤ・パスワード等

・公的個⼈認証・公的個⼈認証・ＩＤ・パスワード等・ＩＤ・パスワード等

サービス提供

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

⺠間サービス連携⺠間サービス連携⺠間サービス連携 ⾏政サービス連携⾏政サービス連携⾏政サービス連携

⼿続ワンストップサービス⼿続ワンストップサービス⼿続ワンストップサービス 情報提供サービス情報提供サービス情報提供サービス

署名・認証署名・認証署名・認証

⼿続－情報提供連携サービス⼿続－情報提供連携サービス⼿続－情報提供連携サービス

テレビテレビ

図 I-5 次世代電子行政サービス基盤のイメージ図

（１） 利用者へのサービス

次世代電子行政サービスの利用者は個人や民間事業者を想定している。利用者はポー

タルにアクセスし、利用するサービスによって認証なし、ID・パスワード、PKIなどの手段によ

って認証を受け、サービスを利用する。サービス利用に当たりパソコンや携帯電話を活用し

たWebによるサービス以外にも電話、双方向サービスの地上デジタルテレビ、KIOSK端末、

役所などの窓口でもサービス利用できる環境を目指す。なお、民間企業への住民票の提

出等も考慮が必要であることから、KIOSK端末等での住民票の電子交付についても利用者

の利便性向上から重要であると考えられる。

ポータルにおけるワンストップサービスは、添付書類の削減や電子化、複数機関・複数

回の訪問の不要、統一化された申請様式などを実現したサービスを提供し、情報提供サー

ビスにおいては利用者が必要とする行政サービスや個人の情報についてサービス提供機

関を意識することなく閲覧することのできるサービスも提供する。

I .標準モデル構築に向けた技術的方策を中心として １．はじめに

11

（２） 民間の業務サービスとの連携

企業内部で様々なシステムを導入し業務の効率化を図っているが、これらのシステムと

行政への手続が連携できると企業において更なる効率化を図ることが可能となる。

（３） 各種ポータルサイトとの連携

企業や地方公共団体では既にポータルサイトを運営し、情報発信や手続に関するサー

ビスを提供しており、多くの方が利用している。これらのサービスと次世代電子行政サービ

スが連携することにより、利用者にとって利便性が向上するとともに次世代電子行政サー

ビスの利用者も増加する効果も期待できる。

（４） 行政サービス連携と民間サービス連携

フロントオフィスとバックオフィスの連携やバックオフィス間の連携などのサービスを提供

する。これにより利用者は複数機関の申請において申請先を意識せずに一度に処理でき、

手続のために必要な証明書などの添付書類を行政機関に請求する手続を省略することが

できる。また、行政機関や民間企業においても利用者や他の機関との間において電子的な

情報によって処理することにより、入力作業などの手間が省けるなどの業務効率性を高め

ることができる。各行政機関において電子的処理を原則とする業務プロセスへの移行であ

る業務のBPR(Business Process Reengineering)とシステムの標準化を進めることにより、サ

ービスレベルの向上を図りつつコスト削減や業務の効率化を図る。

また、行政機関と民間企業とのサービス連携も可能となり行政発行の証明書を民間企

業に展開する、または民間企業発行の証明書を行政機関に展開するなどの官民連携サー

ビスも可能となる。民間企業とのサービス連携は、国民の利便性を飛躍的に高めることや、

民間企業における手続等の業務効率の向上、国民への新たなサービスの創出等の高い

付加価値が期待できることから、実現に向けた検討を着実に行う。

I .標準モデル構築に向けた技術的方策を中心として ２．ライフイベントに関する次世代電子行政サービス

12

２．ライフイベントに関する次世代電子行政サービス

２．１ ライフイベントに関する行政サービスへのニーズ

ライフイベント5に関する次世代電子行政サービスの検討に当たり、そもそも利用者のニ

ーズとしてどういった行政サービスが求められているか、またどういった改善を希望してい

るかを把握するために、平成21年上半期にWebアンケートによる調査を行った。

（１） ライフイベントに伴う手続の利便性イメージ

利用者のライフイベントに伴う手続の利便性に関するイメージをアンケート調査したところ、

「不便に感じる」とした回答が、引越55.2%、退職40.1%、就職（新規就職、再就職等）38.4%等

との回答結果が得られた。（平成21年3月Webアンケート。全国1000名有効回答。手続経験

の有無不問）

5 5 .2 %

4 0 .1 %

3 8 .4 %

3 7 .7 %

3 5 .7 %

3 2 .8 %

3 2 . 7 %

3 2 .1 %

2 5 .0 %

2 5 . 4 %

3 9 . 7 %

3 2 .2 %

4 6 . 0 %

5 3 .5 %

5 4 . 9 %

4 6 . 3 %

3 7 . 9 %

4 9 . 1 %

1 9 . 4 %

2 0 . 2 %

2 9 .4 %

1 6 . 3 %

1 0 .8 %

1 2 . 3 %

2 1 . 0 %

3 0 . 0 %

2 5 .9 %

0 % 1 0 % 2 0 % 3 0 % 4 0 % 5 0 % 6 0 % 7 0 % 8 0 % 9 0 % 1 0 0 %

引 越 し

退 職

就 職

育 児

介 護

死 亡 手 続 き

出 産

結 婚

妊 娠

不 便 に 感 じ た ど ち ら と も い え な い 不 便 に 感 じ な か っ た不 便 に 感 じ な い

引 越

死 亡 手 続

不 便 に 感 じ る

図 I-6 利便性イメージの回答結果

（２） 実際に経験した者が不便に感じたライフイベント関連手続

実際に手続を経験した者のみを対象に、利便性に関して質問したところ、介護73.8%、引

越61.5%、育児54.5%が「不便に感じた」との回答結果が得られた。

5 ライフイベントとは、生活に身近な誰もが経験する可能性のあるイベントを時系列に整理したもので、本調査においては「結婚、妊娠、出産、育児、引越、就職、退職、介護、死亡」

の９つの分類にて調査を行った。

I .標準モデル構築に向けた技術的方策を中心として ２．ライフイベントに関する次世代電子行政サービス

13

○ 介 護 （ 経 験 あ り： 70 名 ）

○ 引 越 （ 経 験 あ り： 59 1名 ）

○ 退 職 （ 経 験 あ り： 39 4名 ）

○ 死 亡 ⼿ 続 （経 験 あ り： 1 24名 ）

○ 育 児 （ 経 験 あ り： 24 7名 ）

7 3 .8 % 1 5 . 5 % 1 0 . 7 %

0 % 2 0 % 4 0 % 6 0 % 8 0 % 1 0 0 %

経 験 あ り

不 便 に 感 じ た ど ち ら と も い え な い 不 便 に 感 じ な か っ た

6 1 . 5 % 1 9 . 0 % 1 9 . 5 %

0 % 2 0 % 4 0 % 6 0 % 8 0 % 1 0 0 %

経 験 あ り

不 便 に 感 じ た ど ち ら と も い え な い 不 便 に 感 じ な か っ た

5 4 . 5 % 2 2 . 3 % 2 3 . 2 %

0 % 2 0 % 4 0 % 6 0 % 8 0 % 1 0 0 %

経 験 あ り

不 便 に 感 じ た ど ち ら と も い え な い 不 便 に 感 じ な か っ た

5 2 .5 % 2 6 . 5 % 2 0 . 9 %

0 % 2 0 % 4 0 % 6 0 % 8 0 % 1 0 0 %

経 験 あ り

不 便 に 感 じ た ど ち ら と も い え な い 不 便 に 感 じ な か っ た

5 2 . 0 % 2 9 . 8 % 1 8 . 1 %

0 % 2 0 % 4 0 % 6 0 % 8 0 % 1 0 0 %

経 験 あ り

不 便 に 感 じ た ど ち ら と も い え な い 不 便 に 感 じ な か っ た

○ 介 護 （ 経 験 あ り： 70 名 ）

○ 引 越 （ 経 験 あ り： 59 1名 ）

○ 退 職 （ 経 験 あ り： 39 4名 ）

○ 死 亡 ⼿ 続 （経 験 あ り： 1 24名 ）

○ 育 児 （ 経 験 あ り： 24 7名 ）

7 3 .8 % 1 5 . 5 % 1 0 . 7 %

0 % 2 0 % 4 0 % 6 0 % 8 0 % 1 0 0 %

経 験 あ り

不 便 に 感 じ た ど ち ら と も い え な い 不 便 に 感 じ な か っ た

6 1 . 5 % 1 9 . 0 % 1 9 . 5 %

0 % 2 0 % 4 0 % 6 0 % 8 0 % 1 0 0 %

経 験 あ り

不 便 に 感 じ た ど ち ら と も い え な い 不 便 に 感 じ な か っ た

5 4 . 5 % 2 2 . 3 % 2 3 . 2 %

0 % 2 0 % 4 0 % 6 0 % 8 0 % 1 0 0 %

経 験 あ り

不 便 に 感 じ た ど ち ら と も い え な い 不 便 に 感 じ な か っ た

5 2 .5 % 2 6 . 5 % 2 0 . 9 %

0 % 2 0 % 4 0 % 6 0 % 8 0 % 1 0 0 %

経 験 あ り

不 便 に 感 じ た ど ち ら と も い え な い 不 便 に 感 じ な か っ た

5 2 . 0 % 2 9 . 8 % 1 8 . 1 %

0 % 2 0 % 4 0 % 6 0 % 8 0 % 1 0 0 %

経 験 あ り

不 便 に 感 じ た ど ち ら と も い え な い 不 便 に 感 じ な か っ た

図 I-7 経験者が不便に感じたライフイベント

（３） ライフイベント関連手続の際にどのような点を不便に感じたか（個人）

実際に手続を経験した者を対象に、ライフイベント関連手続について、どのような点に不

便を感じたかを質問した（複数回答可）。

各ライフイベントの各ライフイベントの⼿続の経験者⼿続の経験者（１０００⼈中）（１０００⼈中）

いつどこでどんな⼿続いつどこでどんな⼿続をする必要があるのかをする必要があるのかわからなかったわからなかった

⼿続に必要なもの（⼿続に必要なもの（印鑑や添付種類な印鑑や添付種類など）がわからなかったど）がわからなかった

⼿続のために役所に⼿続のために役所に⾏かなくてはならず不⾏かなくてはならず不便だった便だった

同じ役所なのに、い同じ役所なのに、いろいろな窓⼝に⾏かろいろな窓⼝に⾏かなくてはならず不便だなくてはならず不便だったった

役所の受付時間に役所の受付時間に制限があり不便だっ制限があり不便だったた

添付書類（住⺠票・添付書類（住⺠票・源泉徴収票など）が源泉徴収票など）が多くて⾯倒だった多くて⾯倒だった

その他その他

結婚結婚 407407 8383 147147 197197 6262 108108 5858 1010( 20.4%)( 20.4%) ( 36.1%)( 36.1%) ( 48.4%)( 48.4%) ( 15.2%)( 15.2%) ( 26.5%)( 26.5%) ( 14.3%)( 14.3%) ( 2.5%)( 2.5%)

妊娠妊娠 219219 5454 5959 123123 2929 4646 77 44( 24.7%)( 24.7%) ( 26.9%)( 26.9%) ( 56.2%)( 56.2%) ( 13.2%)( 13.2%) ( 21.0%)( 21.0%) ( 3.2%)( 3.2%) ( 1.8%)( 1.8%)

出産出産 250250 6363 6868 127127 4848 6363 1111 55( 25.2%)( 25.2%) ( 27.2%)( 27.2%) ( 50.8%)( 50.8%) ( 19.2%)( 19.2%) ( 25.2%)( 25.2%) ( 4.4%)( 4.4%) ( 2.0%)( 2.0%)

育児育児 247247 6161 5959 121121 6060 5353 2222 77( 24.7%)( 24.7%) ( 23.9%)( 23.9%) ( 49.0%)( 49.0%) ( 24.3%)( 24.3%) ( 21.5%)( 21.5%) ( 8.9%)( 8.9%) ( 2.8%)( 2.8%)

引越引越 591591 112112 138138 332332 134134 186186 6868 1717( 19.0%)( 19.0%) ( 23.4%)( 23.4%) ( 56.2%)( 56.2%) ( 22.7%)( 22.7%) ( 31.5%)( 31.5%) ( 11.5%)( 11.5%) ( 2.9%)( 2.9%)

就職就職 385385 108108 8888 136136 4545 9595 5454 3333( 28.1%)( 28.1%) ( 22.9%)( 22.9%) ( 35.3%)( 35.3%) ( 11.7%)( 11.7%) ( 24.7%)( 24.7%) ( 14.0%)( 14.0%) ( 8.6%)( 8.6%)

退職退職 394394 122122 9898 153153 7373 9292 6666 1818( 31.0%)( 31.0%) ( 24.9%)( 24.9%) ( 38.8%)( 38.8%) ( 18.5%)( 18.5%) ( 23.4%)( 23.4%) ( 16.8%)( 16.8%) ( 4.6%)( 4.6%)

介護介護 7070 2929 1919 2525 2424 1717 1313 11( 41.4%)( 41.4%) ( 27.1%)( 27.1%) ( 35.7%)( 35.7%) ( 34.3%)( 34.3%) ( 24.3%)( 24.3%) ( 18.6%)( 18.6%) ( 1.4%)( 1.4%)

死亡死亡 124124 5050 4343 5151 2929 2121 2121 44( 40.3%)( 40.3%) ( 34.7%)( 34.7%) ( 41.1%)( 41.1%) ( 23.4%)( 23.4%) ( 16.9%)( 16.9%) ( 16.9%)( 16.9%) ( 3.2%)( 3.2%)

各ライフイベントの各ライフイベントの⼿続の経験者⼿続の経験者（１０００⼈中）（１０００⼈中）

いつどこでどんな⼿続いつどこでどんな⼿続をする必要があるのかをする必要があるのかわからなかったわからなかった

⼿続に必要なもの（⼿続に必要なもの（印鑑や添付種類な印鑑や添付種類など）がわからなかったど）がわからなかった

⼿続のために役所に⼿続のために役所に⾏かなくてはならず不⾏かなくてはならず不便だった便だった

同じ役所なのに、い同じ役所なのに、いろいろな窓⼝に⾏かろいろな窓⼝に⾏かなくてはならず不便だなくてはならず不便だったった

役所の受付時間に役所の受付時間に制限があり不便だっ制限があり不便だったた

添付書類（住⺠票・添付書類（住⺠票・源泉徴収票など）が源泉徴収票など）が多くて⾯倒だった多くて⾯倒だった

その他その他

結婚結婚 407407 8383 147147 197197 6262 108108 5858 1010( 20.4%)( 20.4%) ( 36.1%)( 36.1%) ( 48.4%)( 48.4%) ( 15.2%)( 15.2%) ( 26.5%)( 26.5%) ( 14.3%)( 14.3%) ( 2.5%)( 2.5%)

妊娠妊娠 219219 5454 5959 123123 2929 4646 77 44( 24.7%)( 24.7%) ( 26.9%)( 26.9%) ( 56.2%)( 56.2%) ( 13.2%)( 13.2%) ( 21.0%)( 21.0%) ( 3.2%)( 3.2%) ( 1.8%)( 1.8%)

出産出産 250250 6363 6868 127127 4848 6363 1111 55( 25.2%)( 25.2%) ( 27.2%)( 27.2%) ( 50.8%)( 50.8%) ( 19.2%)( 19.2%) ( 25.2%)( 25.2%) ( 4.4%)( 4.4%) ( 2.0%)( 2.0%)

育児育児 247247 6161 5959 121121 6060 5353 2222 77( 24.7%)( 24.7%) ( 23.9%)( 23.9%) ( 49.0%)( 49.0%) ( 24.3%)( 24.3%) ( 21.5%)( 21.5%) ( 8.9%)( 8.9%) ( 2.8%)( 2.8%)

引越引越 591591 112112 138138 332332 134134 186186 6868 1717( 19.0%)( 19.0%) ( 23.4%)( 23.4%) ( 56.2%)( 56.2%) ( 22.7%)( 22.7%) ( 31.5%)( 31.5%) ( 11.5%)( 11.5%) ( 2.9%)( 2.9%)

就職就職 385385 108108 8888 136136 4545 9595 5454 3333( 28.1%)( 28.1%) ( 22.9%)( 22.9%) ( 35.3%)( 35.3%) ( 11.7%)( 11.7%) ( 24.7%)( 24.7%) ( 14.0%)( 14.0%) ( 8.6%)( 8.6%)

退職退職 394394 122122 9898 153153 7373 9292 6666 1818( 31.0%)( 31.0%) ( 24.9%)( 24.9%) ( 38.8%)( 38.8%) ( 18.5%)( 18.5%) ( 23.4%)( 23.4%) ( 16.8%)( 16.8%) ( 4.6%)( 4.6%)

介護介護 7070 2929 1919 2525 2424 1717 1313 11( 41.4%)( 41.4%) ( 27.1%)( 27.1%) ( 35.7%)( 35.7%) ( 34.3%)( 34.3%) ( 24.3%)( 24.3%) ( 18.6%)( 18.6%) ( 1.4%)( 1.4%)

死亡死亡 124124 5050 4343 5151 2929 2121 2121 44( 40.3%)( 40.3%) ( 34.7%)( 34.7%) ( 41.1%)( 41.1%) ( 23.4%)( 23.4%) ( 16.9%)( 16.9%) ( 16.9%)( 16.9%) ( 3.2%)( 3.2%)

回答が20%超回答が30%超

I .標準モデル構築に向けた技術的方策を中心として ２．ライフイベントに関する次世代電子行政サービス

14

図 I-8 不便に感じた理由（個人）

殆どのライフイベントにおいて、「手続のために役所に行かなくてはならず不便だ

った」が も多く、次いで「いつどこでどんな手続をする必要があるのかわからな

かった」、「手続に必要なもの（印鑑や添付種類など）がわからなかった」という結

果となった。

特に退職、介護、死亡については、 「いつどこでどんな手続をする必要があるの

かわからなかった」点に不便さを感じた者が多い。

今回の調査結果においては、引越に伴う手続が、9種類のライフイベントの中で も不便

に感じる者が多いという結果であった。実際に経験した者にとって、介護や引越、育児等の

手続は、想像していたよりも複雑であったため、不便に感じた割合が高くなったものと推測

される。９種類のライフイベント関連手続において、経験者による「手続のために役所に行

かなくてはならず不便だった」とする回答が35～56%に達しており、利用者の側からのオンラ

インによるワンストップサービスへの潜在ニーズは高い。特に引越に伴う手続は、一般に経

験する回数も多く、ワンストップ化による利便性の向上を利用者が実感しやすいモデルにな

ると考えられる。また、退職、介護、死亡関連の手続等については、「いつどこでどんな手

続をする必要があるのかわからなかった」とする回答も多く、まず、わかりやすい情報提供

を行った上で、ワンストップ化によって、手続に伴う負担を軽減することが必要と考えられ

る。

（４） ライフイベント関連手続の際にどのような点を不便に感じたか（企業）

行政機関への申請の利用者は、個人だけでなく、企業においても相当量あることから、

企業のニーズの傾向について調査を行った。企業から行政機関へ手続を行う業務の担当

者（総務、人事などの職務に従事し、企業における行政機関への手続を経験したことのあ

る者）に、ライフイベント関連手続について、どのような点に不便を感じたかを質問した。（複

数回答可）

I .標準モデル構築に向けた技術的方策を中心として ２．ライフイベントに関する次世代電子行政サービス

15

各ライフイベントの各ライフイベントの⼿続の経験者⼿続の経験者（１０００⼈中）（１０００⼈中）

必要な⼿続や問い合わ必要な⼿続や問い合わせ先などがわからなかっせ先などがわからなかったた

従業員へ必要な⼿続従業員へ必要な⼿続などを説明するのに⼿などを説明するのに⼿間がかかる間がかかる

電⼦申請できない⼿続電⼦申請できない⼿続が多いが多い

直接、窓⼝に⾏かなくて直接、窓⼝に⾏かなくてはならない⼿続が多いはならない⼿続が多い

社会保険、健康保険、社会保険、健康保険、税など分野や⼿続ごと税など分野や⼿続ごとに記⼊する企業コードがに記⼊する企業コードが異なり、管理が⾯倒異なり、管理が⾯倒

社内の⼈事・給与ソフト社内の⼈事・給与ソフトウェアと連動できないのウェアと連動できないので不便で不便

事業所ごとに⼿続が必事業所ごとに⼿続が必要で、本社で⼀括して要で、本社で⼀括して処理できない処理できない

その他その他

結婚結婚 308308 5757 9393 8686 106106 6565 3333 1919 99( 18.5%)( 18.5%) ( 30.2%)( 30.2%) ( 27.9%)( 27.9%) ( 34.4%)( 34.4%) ( 21.1%)( 21.1%) ( 10.7%)( 10.7%) ( 6.2%)( 6.2%) ( 2.9%)( 2.9%)

妊娠妊娠 203203 3636 6565 5353 5252 3737 2424 99 1010( 17.7%)( 17.7%) ( 32.0%)( 32.0%) ( 26.1%)( 26.1%) ( 25.6%)( 25.6%) ( 18.2%)( 18.2%) ( 11.8%)( 11.8%) ( 4.4%)( 4.4%) ( 4.9%)( 4.9%)

出産出産 263263 5151 9494 6666 8484 4949 3636 1414 1111( 19.4%)( 19.4%) ( 35.7%)( 35.7%) ( 25.1%)( 25.1%) ( 31.9%)( 31.9%) ( 18.6%)( 18.6%) ( 13.7%)( 13.7%) ( 5.3%)( 5.3%) ( 4.2%)( 4.2%)

育児育児 212212 3939 7171 5353 5858 3737 2626 1414 1414( 18.4%)( 18.4%) ( 33.5%)( 33.5%) ( 25.0%)( 25.0%) ( 27.4%)( 27.4%) ( 17.5%)( 17.5%) ( 12.3%)( 12.3%) ( 6.6%)( 6.6%) ( 6.6%)( 6.6%)

引越引越 344344 5757 7171 9797 122122 5050 3535 3535 1313( 16.6%)( 16.6%) ( 20.6%)( 20.6%) ( 28.2%)( 28.2%) ( 35.5%)( 35.5%) ( 14.5%)( 14.5%) ( 10.2%)( 10.2%) ( 10.2%)( 10.2%) ( 3.8%)( 3.8%)

就職就職 384384 6363 134134 9595 119119 9898 4040 3030 2626( 16.4%)( 16.4%) ( 34.9%)( 34.9%) ( 24.7%)( 24.7%) ( 31.0%)( 31.0%) ( 25.5%)( 25.5%) ( 10.4%)( 10.4%) ( 7.8%)( 7.8%) ( 6.8%)( 6.8%)

退職退職 359359 5656 141141 9191 114114 9595 2929 3232 2929( 15.6%)( 15.6%) ( 39.3%)( 39.3%) ( 25.3%)( 25.3%) ( 31.8%)( 31.8%) ( 26.5%)( 26.5%) ( 8.1%)( 8.1%) ( 8.9%)( 8.9%) ( 8.1%)( 8.1%)

死亡死亡 173173 3737 5252 4646 7070 3535 1818 1212 1212( 21.4%)( 21.4%) ( 30.1%)( 30.1%) ( 26.6%)( 26.6%) ( 40.5%)( 40.5%) ( 20.2%)( 20.2%) ( 10.4%)( 10.4%) ( 6.9%)( 6.9%) ( 6.9%)( 6.9%)

各ライフイベントの各ライフイベントの⼿続の経験者⼿続の経験者（１０００⼈中）（１０００⼈中）

必要な⼿続や問い合わ必要な⼿続や問い合わせ先などがわからなかっせ先などがわからなかったた

従業員へ必要な⼿続従業員へ必要な⼿続などを説明するのに⼿などを説明するのに⼿間がかかる間がかかる

電⼦申請できない⼿続電⼦申請できない⼿続が多いが多い

直接、窓⼝に⾏かなくて直接、窓⼝に⾏かなくてはならない⼿続が多いはならない⼿続が多い

社会保険、健康保険、社会保険、健康保険、税など分野や⼿続ごと税など分野や⼿続ごとに記⼊する企業コードがに記⼊する企業コードが異なり、管理が⾯倒異なり、管理が⾯倒

社内の⼈事・給与ソフト社内の⼈事・給与ソフトウェアと連動できないのウェアと連動できないので不便で不便

事業所ごとに⼿続が必事業所ごとに⼿続が必要で、本社で⼀括して要で、本社で⼀括して処理できない処理できない

その他その他

結婚結婚 308308 5757 9393 8686 106106 6565 3333 1919 99( 18.5%)( 18.5%) ( 30.2%)( 30.2%) ( 27.9%)( 27.9%) ( 34.4%)( 34.4%) ( 21.1%)( 21.1%) ( 10.7%)( 10.7%) ( 6.2%)( 6.2%) ( 2.9%)( 2.9%)

妊娠妊娠 203203 3636 6565 5353 5252 3737 2424 99 1010( 17.7%)( 17.7%) ( 32.0%)( 32.0%) ( 26.1%)( 26.1%) ( 25.6%)( 25.6%) ( 18.2%)( 18.2%) ( 11.8%)( 11.8%) ( 4.4%)( 4.4%) ( 4.9%)( 4.9%)

出産出産 263263 5151 9494 6666 8484 4949 3636 1414 1111( 19.4%)( 19.4%) ( 35.7%)( 35.7%) ( 25.1%)( 25.1%) ( 31.9%)( 31.9%) ( 18.6%)( 18.6%) ( 13.7%)( 13.7%) ( 5.3%)( 5.3%) ( 4.2%)( 4.2%)

育児育児 212212 3939 7171 5353 5858 3737 2626 1414 1414( 18.4%)( 18.4%) ( 33.5%)( 33.5%) ( 25.0%)( 25.0%) ( 27.4%)( 27.4%) ( 17.5%)( 17.5%) ( 12.3%)( 12.3%) ( 6.6%)( 6.6%) ( 6.6%)( 6.6%)

引越引越 344344 5757 7171 9797 122122 5050 3535 3535 1313( 16.6%)( 16.6%) ( 20.6%)( 20.6%) ( 28.2%)( 28.2%) ( 35.5%)( 35.5%) ( 14.5%)( 14.5%) ( 10.2%)( 10.2%) ( 10.2%)( 10.2%) ( 3.8%)( 3.8%)

就職就職 384384 6363 134134 9595 119119 9898 4040 3030 2626( 16.4%)( 16.4%) ( 34.9%)( 34.9%) ( 24.7%)( 24.7%) ( 31.0%)( 31.0%) ( 25.5%)( 25.5%) ( 10.4%)( 10.4%) ( 7.8%)( 7.8%) ( 6.8%)( 6.8%)

退職退職 359359 5656 141141 9191 114114 9595 2929 3232 2929( 15.6%)( 15.6%) ( 39.3%)( 39.3%) ( 25.3%)( 25.3%) ( 31.8%)( 31.8%) ( 26.5%)( 26.5%) ( 8.1%)( 8.1%) ( 8.9%)( 8.9%) ( 8.1%)( 8.1%)

死亡死亡 173173 3737 5252 4646 7070 3535 1818 1212 1212( 21.4%)( 21.4%) ( 30.1%)( 30.1%) ( 26.6%)( 26.6%) ( 40.5%)( 40.5%) ( 20.2%)( 20.2%) ( 10.4%)( 10.4%) ( 6.9%)( 6.9%) ( 6.9%)( 6.9%)

回答が20%超回答が30%超

図 I-9 不便に感じた理由（企業）

全体として、「従業員へ必要な手続などを説明するのに手間がかかる」、及び「直

接窓口に行かなくてはならない手続が多い」とする回答が多い。

雇用関係手続で、「社会保険、健康保険、税など分野や手続毎に記入する企業

コードが異なり、管理が面倒」という回答が多い。

このように、企業におけるニーズに関しても、個人のケースと同様に、わかりやすい情報

提供と、オンラインでのワンストップ申請が必要であると考えられる。また、企業においては

事業所単位などで複数名の申請を一括で行う必要があるため、利便性の観点から、それ

ぞれの行政機関の管理する複数のコード体系との関係を整理し、利用者が統一的に利用

できる環境を用意すること等についても検討する必要がある。

さらに、個人や企業のみならず、利用者のニーズを的確に把握し、真に利用されるサー

ビスの提供を目指すためには、高齢者や代理人等、全国民を対象として様々な利用者の

特性を分類し、それぞれのセグメントにおいてのニーズ調査を行う等、さらに詳細な調査が

必要となる。

２．２ 添付書類の調査結果

行政機関間のバックオフィス連携を行うことによって、利用者へのワンストップサービス

提供が可能となり、かつ、行政情報の電子化によって行政事務の効率化を図ることが可能

となるが、そのためには行政機関間においてどのようなバックオフィス連携が必要かを特定

することを目的として、平成21年上半期に、手続に用いられる添付書類について、手続毎

に必要な添付書類の種類、及び添付書類の発行元と提出先を調査した。

I .標準モデル構築に向けた技術的方策を中心として ２．ライフイベントに関する次世代電子行政サービス

16

例えば、添付書類が行政機関から発行され、利用者に交付され、再び別の行政機関に

提出されている場合、その添付書類を電子化して行政機関の間でやり取りする、あるいは、

添付書類に記載されているデータを電子的に行政機関の間で処理することで、利用者は手

続に係る添付書類の取得や、各機関に複数回往復する時間や手間を省くことができる。

（ライフイベントに関連する手続及び重点71手続6を対象とするプレ調査）

不動産登記申請、⾃動⾞の新⾞新規登録など⾃治体印鑑証明書

出産育児⼀時⾦⽀給申請、健康保険埋葬料請求など⺠間等領収書

児童⼿当認定請求、健康保険被扶養者（異動）届など⾃治体所得証明書

出産⼿当⾦⽀給申請、遺族補償年⾦請求など⺠間診断書

運転免許証記載事項変更届、⾃動⾞の新⾞新規登録など住⺠票

⼀般旅券発給申請、児童扶養⼿当認定請求など⾃治体⼾籍謄（抄）本

必要となる⼿続の例発⾏元添付書類名

⾃治体

不動産登記申請、⾃動⾞の新⾞新規登録など⾃治体印鑑証明書

出産育児⼀時⾦⽀給申請、健康保険埋葬料請求など⺠間等領収書

児童⼿当認定請求、健康保険被扶養者（異動）届など⾃治体所得証明書

出産⼿当⾦⽀給申請、遺族補償年⾦請求など⺠間診断書

運転免許証記載事項変更届、⾃動⾞の新⾞新規登録など住⺠票

⼀般旅券発給申請、児童扶養⼿当認定請求など⾃治体⼾籍謄（抄）本

必要となる⼿続の例発⾏元添付書類名

不動産登記申請、⾃動⾞の新⾞新規登録など⾃治体印鑑証明書

出産育児⼀時⾦⽀給申請、健康保険埋葬料請求など⺠間等領収書

児童⼿当認定請求、健康保険被扶養者（異動）届など⾃治体所得証明書

出産⼿当⾦⽀給申請、遺族補償年⾦請求など⺠間診断書

運転免許証記載事項変更届、⾃動⾞の新⾞新規登録など住⺠票

⼀般旅券発給申請、児童扶養⼿当認定請求など⾃治体⼾籍謄（抄）本

必要となる⼿続の例発⾏元添付書類名

⾃治体

図 I-10手続に必要となる添付書類の例

国から国7.5%

⾃治体から国

17.5%

⾃治体から⾃治体24.5%⺠間から国

18.7%

⺠間から⾃治体8.0%

本⼈から国11.0%

その他12.9%

N=653

発⾏元と提出先 件数 ％

国から国 49 7.5%

⾃治体から国 114 17.5%

⾃治体から⾃治体 160 24.5%

⺠間から国 122 18.7%

⺠間から⾃治体 52 8.0%

本⼈から国 72 11.0%

その他 84 12.9%

合計 653 100.0%

図 I-11 添付書類の発行・提出機関の割合

多く利用されている手続として重点71手続、及び一般的に利用者が利用すると想定した

9種類のライフイベントにおいて、それぞれの手続に用いられる添付書類全体を母集団とし

た際に、手続に主に用いられる添付書類の例を図 I-10に示し、その添付書類の発行元と

提出先の分類の割合を図 I-11に示す。（母集団は手続毎に必要な添付書類の種類数を

合計したもの。従って、同種類の添付書類が重複してカウントされている場合がある。）

6 重点 71 手続：「オンライン利用拡大行動計画」（平成 20 年 9 月 12 日ＩＴ戦略本部決定）において、国民が広く利用するオンライン化された手続のうち、国民や企業による利用頻度が

高い年間申請等件数が 100 万件以上のもの及び 100 万件未満であっても主として企業等が反復的又は継続的に利用する手続等と分類されている。

I .標準モデル構築に向けた技術的方策を中心として ２．ライフイベントに関する次世代電子行政サービス

17

これらのプレ調査結果によって、以下の可能性があることが示された。

● 添付書類のうち約半分が国、又は、地方公共団体等の行政機関が発行するもの。

● 仮に国・地方自治体間でバックオフィス連携を行い、国又は地方自治体が発行する

添付書類を不要化する場合、流通する添付書類の種類を半減できる可能性がある。

今後、添付書類の量（利用数）や、手続の特性等を踏まえて、添付書類の省略の可能性

やデータ連携の可能性等について、更に踏み込んだ調査・検討が必要である。特に、手続

の際に用いられる添付書類の記載内容には、データ連携においても必要性の高い情報が

含まれる可能性が高いため、実現するワンストップサービスのユースケースにおいて用い

られる添付書類につき、どういったデータがどういった目的に用いられているのか等、さら

に詳細な追加調査が必要である。

２．３ 情報提供サービスの必要性

特別テーマ評価検討委員会7では、国民に身近なライフイベントである｢結婚・妊娠・出

産・育児」について、平成20年度後半に重点的に検討を行った。その結果、結婚すると名義

や住所変更が大変ということや、出生届や児童手当の申請などで複数の窓口に様々な書

類を提出しなければならないという現状に、国民の約9割が不便に感じ、また、提出書類に

関しては、住所や氏名など何度も記入しなければならないことや、書き方がわかりにくいと

いう声があったとしている。それらの解決のためには、いつどんな手続が必要かを分かりや

すく情報提供し、データ連携を活用し、必要な人に、的確なタイミングでわかりやすく情報提

供することで、利用者の不便・不安（負担）を軽減できるとした報告書をとりまとめた。

7 http://www.kantei.go.jp/jp/singi/it2/tokubetu/index.html

I .標準モデル構築に向けた技術的方策を中心として ２．ライフイベントに関する次世代電子行政サービス

18

不便（負担）◆結婚すると名義や住所変更が⼤変

◆出⽣届や児童⼿当申請など、⼦供を抱えて様々な⼿続に⾛り回らないといけない

いろいろな窓⼝に様々な書類を提出

【役所】

【平均⼿続数】⇒⼥性が21種類、男性が7種類、

国⺠の約9割が不便と感じている＜主な声＞・毎回、いろんな役所に出向いたり、同じ役所内でも

いろいろな課に⾏かなくてはいけない・⼿続きのために会社を休まなくてはいけない

【⾏政が国⺠に提出を求める書類】⇒約６〜７割は既に⾏政が保有（住⺠票・⼾籍等）＜主な声＞

・住所、⽒名を何度も記⼊しなくてはいけない・書類の書き⽅が分かりにくい

利⽤者⽬線でわかりやすく情報提供を利⽤者⽬線でわかりやすく情報提供を⾏なうことで、⾏なうことで、情報不⾜による不安を軽減情報不⾜による不安を軽減

⇒いつどんな⼿続が必要かをわかりやすく⇒いつどんな⼿続が必要かをわかりやすく⇒データ連携を活⽤して、必要な⼈に⇒データ連携を活⽤して、必要な⼈に､､的確なタイミングでわ的確なタイミングでわ

かりやすく情報提供かりやすく情報提供

例例))パソコン・携帯電話を使って、パソコン・携帯電話を使って、「マイページサービス」と、本⼈の希望に「マイページサービス」と、本⼈の希望に応じた「プッシュ型サービス」を実現応じた「プッシュ型サービス」を実現＊韓国、北欧では同様のｻｰﾋﾞｽが既にｽﾀｰﾄ＊韓国、北欧では同様のｻｰﾋﾞｽが既にｽﾀｰﾄ

ＩＴ新改⾰戦略評価専⾨調査会（平成20年度 第3回）資料1：特別テーマ評価検討委員会 提⾔⾻⼦案国⺠が便利と安⼼を実感できる⾏政サービスの早期実現に向けて より

図 I-12 結婚・妊娠・出産・育児に関する問題点の指摘

２．４ 調査結果を踏まえて

ライフイベントに関する行政サービスへのニーズからは、国民・企業に向けたワンストッ

プサービスと分かりやすい情報提供の必要性が示された。また、添付書類の調査から、バ

ックオフィス連携を行う際には添付書類等のデータを含めて検討することで、業務効率化に

高い効果が期待できることが示された。さらに、結婚・妊娠・出産・育児に関する問題点の

指摘から、データ連携を活用した利用者目線での情報提供の必要性が示された。

ワンストップサービスの提供やデータ連携、利用者目線での情報提供の実現に向けては、

各機関のサービスとデータをバックオフィス間にて連携する仕組みと、利用者の総合的な

窓口となる仕組みが求められる。特に、バックオフィス間での連携を行う仕組みは国民・行

政（国・地方）・民間の様々な要素が関連することから、どういった技術を用いてどのように

実現できるかについて、具体的なイメージを共有することが重要となる。

そのため、本書においては、バックオフィス連携を可能とする仕組みを「公共サービス連

携基盤（仮称）」と呼称し、以降、「公共サービス連携基盤（仮称）」を中心とした技術的な方

策について、グランドデザインにて定義された要件や方向性等を踏まえ、まずはコンセプト

レベルでのコンセンサスの醸成を目的として、論理的な機能を用い解説する。

I .標準モデル構築に向けた技術的方策を中心として ３．次世代電子行政サービスを実現する技術的方策の方向性

19

３．次世代電子行政サービスを実現する技術的方策の方向性

ワンストップサービスに関係する機関を網羅してバックオフィス連携を可能とする基盤と

して、添付書類削減による利用者の利便性、バックオフィス業務の効率化、セキュリティの

観点を考慮し、各機関により分散管理されている行政情報のメタデータ（行政情報の所在、

保有している機関、およびアクセス方法等やデータの形式に関するデータ）を管理する「公

共サービス連携基盤（仮称）」を構築する。

開示・利用可能な行政情報そのものは、データベースを保有する機関によって管理され、

管理責任はそれぞれの機関にある。行政機関は、他の行政機関が保有する行政情報を

「公共サービス連携基盤（仮称）」を介して共有でき、審査等の業務遂行に必要な行政情報

を必要な形式で入手することができる。

これにより、申請者の側では、申請書の提出と同時に求められる添付書類を取得するこ

とが不要になり、一方で、行政機関は業務効率を向上させることができる。

３．１ 次世代電子行政サービス基盤の全体像

次世代電子行政サービスの基盤としては、公共サービスポータルと「公共サービス連携

基盤（仮称）」が必要不可欠である。公共サービスポータルは利用者の総合的な窓口として

わかりやすい情報提供や利便性を高めるインターフェースを提供する。バックオフィス連携

を可能とする「公共サービス連携基盤（仮称）」は、公共サービスポータルと各機関を疎結

合（ 小限の影響、依存関係での連携）により接続し、例えば、ワンストップ申請のプロセス

管理や、データ連携等の仕組みを集約する。

この次世代電子行政サービス基盤は、利用者と各機関を橋渡しする役目を担い、利用

者は複雑なプロセスや関係機関を意識することなく、ワンストップサービスを利用すること

ができる。例えば、ワンストップ申請を行う際には、どの府省がどの手続を所管しているか

をさほど意識せず、国・地方をまたがる複数の申請においても一括で処理することを可能と

し、さらに、民間企業との連携によって金融機関を通じた手数料の支払い等についても一

括して行うことが考えられる。

一方で、行政情報等の共有による利用者の不安を解消するために、利用者が希望した

場合のみ情報連携することを前提とし、また、個人情報についての本人が意図しない連携

や目的外の利用を抑制・防止するために、第三者機関等による監視が必要であることを示

している。

I .標準モデル構築に向けた技術的方策を中心として ３．次世代電子行政サービスを実現する技術的方策の方向性

20

●●⼀度の⼿続で完了⼀度の⼿続で完了●●わかりやすいわかりやすい情報の情報の⼊⼿⼊⼿

外部連携サービス外部連携サービス外部外部接続機能接続機能の標準的の標準的なインターフェースなインターフェース

外部連携サービス外部連携サービス外部外部接続機能接続機能の標準的の標準的なインターフェースなインターフェース

⾃治体⾃治体

ガスガス

電⼒電⼒

⾃治体⾃治体ハブハブ

⾃治体⾃治体

⺠間⺠間ハブハブ

府省府省

外部接続機能

外部外部接続接続機能機能

銀⾏銀⾏

認証認証機関機関

公共サービス連携基盤（仮称）公共サービス連携基盤（仮称）公共サービス連携基盤（仮称）公共サービス連携基盤（仮称）

業務プロセス

管理機能

業務業務プロセスプロセス

管理機能管理機能ディレクトリ

機能ディレクトリディレクトリ

機能機能アクセス制御

機能アクセス制御アクセス制御

機能機能

ログ管理機能

ログ管理ログ管理機能機能

⼀時情報保管機能⼀時情報⼀時情報保管保管機能機能

レジストリ機能

レジストリレジストリ機能機能

サービスバスサービスバスサービスバス

プル型情報提供機能／カスタマイズ機能

プル型情報提プル型情報提供機能／カス供機能／カスタマイズ機能タマイズ機能

ワンストップ申請機能ワンストップワンストップ申請機能申請機能

公共サービスポータル公共サービスポータル公共サービスポータル公共サービスポータル公共サービスポータル公共サービスポータル

エージェント型情報提供機能エージェント型エージェント型情報提供機能情報提供機能

プッシュ型情報提供機能

プッシュ型情報プッシュ型情報提供提供機能機能

インテリジェント検索機能

インテリジェントインテリジェント検索機能検索機能

認証・署名機能

認証・署名認証・署名機能機能

●●効率的な業務遂⾏効率的な業務遂⾏

国⺠等国⺠等

職員等職員等

要求

要求

返答

返答

返答

要求

ワンストップ申請

ワンストップ申請

情報提供

情報提供

バックオフィス連携

バックオフィス連携

公共サービスの公共サービスの総合窓⼝総合窓⼝

国⺠・⾏政・⺠間の仲介役国⺠・⾏政・⺠間の仲介役

●●情報不正情報不正利⽤の監視利⽤の監視

第三者機関第三者機関

パソコン

電話・携帯電話

窓⼝

業務端末

等・・・

プロセスプロセスIDID連携連携

証跡証跡 連携情報連携情報

疎結合疎結合

図 I-13 次世代電子行政サービス基盤の全体像

図 I-13に示した全体像は、韓国やベルギー等、他国における先進的なデータ連携基

盤を参考としているが、日本国内の現状を踏まえつつ必要な取組を推進するための配慮

がなされている。例えば、現在の縦割り行政から、利用者の行動フローに沿った複数の行

政機関の業務における横のつながりを強化するため、業務プロセス管理機能を整備し業務

プロセスを“見える化”することや、業務プロセスの利用状況に応じて業務プロセスの 適

化を促す。また、サービスバス8を用いてSOA準拠の基盤として構築することで、スモールス

タートの取組から始めた場合にも無駄な投資を 小限にしつつ進化することが可能となる

拡張性を備えている。さらに、外部接続機能等によって、各機関との接続に伴う移行の容

易性と 小限の投資での連携が可能なアーキテクチャー（設計思想）となっている。

３．２ 公共サービスポータルに関する方策

公共サービスポータルは利用者の総合的な窓口となる仕組みであり、利用者に真に利

用される行政全体の基盤を目指すために重要な要素である。利用者にとって分かりやすい

情報の提供や、接続機関からの必要に応じたプッシュ型の情報提供などを可能とし、公共

サービス全体の手続を集約するポータルサイトとなることを目指す。

8 サービスバスとは、連携対象のデータやサービスを流通させるための通り道のような存在。一般的にミドルウェアで実装され、標準をベースとしたメッセージ形式での連携を可能と

する。

I .標準モデル構築に向けた技術的方策を中心として ３．次世代電子行政サービスを実現する技術的方策の方向性

21

公共サービス連携基盤︵仮称︶

公共サービスポータル公共サービスポータル公共サービスポータル公共サービスポータル

エージェント型情報提供機能

プッシュ型情報提供機能

インテリジェント検索機能

認証・署名機能

⺠間等他のWebサイト 各府省各府省各府省・⾃治体等

プル型情報提供機能／カスタマイズ機能

公開情報登録・更新

情報収集

ワンストップ申請機能

サービス

各府省・⾃治体等の機関側から情報を提供する

呼出

参照

参照公開情報利

⽤者

公共サービスポータルを最⼤限活⽤するためには、各府省・⾃治体等において、情報の整理やデータの標準化が必要。各府省・⾃治体等が公開情報を公共サービスポータルに登録することで、プル型情報提供、インテリジェント検索、プッシュ型情報提供のサービスが充実する。

図 I-14 公共サービスポータルの概要

図 I-14に示すように、公共サービスポータルには、まず、利用者に必要な情報を簡便に

探してもらうために、必要な情報をわかりやすく体系化して提供するプル型情報提供機能

（ホームページによる情報提供等）、利用者が公共サービスポータルに表示する情報やレ

イアウト等を自由に設定するカスタマイズ機能（いわゆる一般的なWebサイトにて利用可能

なマイページ作成機能と同等の機能）、行政手続や書類名を正確に知らなくても必要な情

報が検索できるインテリジェント検索機能が求められる。

さらに、各府省・自治体等から希望する利用者に情報を発信するプッシュ型情報提供機

能や、利用者の代理人（エージェント）として公共サービスポータルが利用者に関係する情

報を収集するエージェント型情報提供機能が求められる。利用者がプッシュ型情報提供機

能やエージェント型情報提供機能を利用する際には、属性情報（性別、年齢、居住地等）や

関心のあるライフイベント等の情報を登録することで、利用者の属性や関心のあるライフイ

ベントに沿った情報提供を受けることが可能になる。

また、機微な情報を扱うサービスにおいては、既存インフラを活用したオンライン認証、

電子署名のための機能を提供する。

公共サービスポータルで提供するこれらの機能は、Webサービス技術9やマッシュアップ

技術10等の活用により、他のWebサイト（民間を含む）との連動を可能とする基盤ともなる。

例えば、ガジェット技術11はWebサイトに数行の記述を加えるだけで民間等の他のWebサイ

9 HTTP などのインターネット関連技術を応用して、SOAP と呼ばれるXML 形式のプロトコルを用いメッセージの送受信を行うことによって、ソフトウェアの機能をネットワークを通じて利

用できるようにする技術。

10 複数の異なる提供元の技術やコンテンツを複合させて新しいサービスを提供するための技術。

11 ガジェット技術とは、OpenSocial という共通規格によってサービスを部品化して、他の Web サイトに容易に貼り付けられる技術。日本においても多くのソーシャルサイトが採用する

技術である。

I .標準モデル構築に向けた技術的方策を中心として ３．次世代電子行政サービスを実現する技術的方策の方向性

22

トにサービスを埋め込むことが可能であり、公共サービスポータルの実装を「他Webサイト

からの参照を前提とした実装」と位置づけ、ガジェット技術を通じて民間による公共サービ

スポータルの実装を許容するというアプローチも考えられる。

３．３ サービス連携を実現するために「公共サービス連携基盤（仮称）」側に求められ

る機能

バックオフィス連携によって、各機関のデータを連携させるためには、そのデータを扱う

サービスの連携が必要となる。

提供されるサービスはそれぞれの接続機関が所管しているものであり、各機関を疎結合

な連携によってサービス連携させるためには、「公共サービス連携基盤（仮称）」が利用者と

接続機関とを橋渡しする存在として、サービスの順序や要求先、処理状況などを管理する

ことが必要となる。これによって、利用者は複雑な手続のプロセスや所管機関をさほど意識

することなく、ワンストップサービスを利用することが可能となり、また、自身の一括申請の

処理状況を確認することも可能となる。図 I-15に機能の概要と利用のイメージを示す。

⾃治体⾃治体

ガスガス

電⼒電⼒

⾃治体⾃治体

府省府省

外部外部接続接続機能機能

銀⾏銀⾏

公共サービス連携基盤（仮称）公共サービス連携基盤（仮称）公共サービス連携基盤（仮称）公共サービス連携基盤（仮称）

業務プロセス管理機能業務プロセス管理機能・ワンストップサービスの⼿続の順番や・ワンストップサービスの⼿続の順番や

処理状況を管理処理状況を管理

公共サービスポータル

公共サービスポータル

公共サービスポータル

各機関各機関各機関各機関

サービスバス

⾃治体⾃治体ハブハブ

処理要求処理要求

⾃治体⾃治体ハブハブ

⾃治体⾃治体ハブハブ

⺠間⺠間ハブハブ

⺠間⺠間ハブハブ

⼀括申請⼀括申請 分割分割

処理要求処理要求

結果返答結果返答

結果返答結果返答

結果⼊⼿結果⼊⼿ 申請状況の確認申請状況の確認

返答状況返答状況の通知の通知

業務プロセスのパターン業務プロセスのパターン定義定義

処理結果の処理結果の整形整形

結果の表⽰結果の表⽰

ディレクトリ機能ディレクトリ機能・・要求の送り先と要求の送り先とIDID連携を管理連携を管理

レジストリ機能レジストリ機能・・各機関のサービスの仕様を管理各機関のサービスの仕様を管理

送り先と送り先とIDID

接続先の接続先のサービスレジストリサービスレジストリ

等・・等・・

参照参照

⼀時情報保管機能⼀時情報保管機能・ワンストップサービスの⼿続の途中・ワンストップサービスの⼿続の途中状況状況やや

各機関からの結果情報を⼀時的に保管各機関からの結果情報を⼀時的に保管

オープンな標準オープンな標準技術技術に準拠したに準拠したインターフェースインターフェースを提供を提供

図 I-15 サービス連携を実現するために「公共サービス連携基盤（仮称）」側に求められる

機能

（１） 各機関への申請振り分けと処理状況の管理

公共サービスポータルで受け付けた一括申請は、「公共サービス連携基盤（仮称）」の業

務プロセス管理機能によりあらかじめ定義された業務プロセスに基づき、接続機関ごとに

個々の手続単位の申請に分割され、各機関に割り振られる。業務プロセス管理機能には、

ユースケースや利用者特性に基づいた業務プロセスが選択できるよう、業務プロセスのパ

ターンが登録されており、ディレクトリ機能に格納された関連機関の情報および連携用のID

（連携のみに用いられるID）、およびレジストリ機能に格納されたサービスレジストリ（送り先

I .標準モデル構築に向けた技術的方策を中心として ３．次世代電子行政サービスを実現する技術的方策の方向性

23

の外部連携サービスに関するアドレスやプロトコルの情報）を参照しつつ各機関への要求

を行う。また、業務プロセス管理機能は、各機関に振り分けた申請手続の処理順序および

処理状況を管理するものであるため、利用者は公共サービスポータルを介して業務プロセ

ス管理機能が管理する情報を問い合わせることにより、自身の一括申請の処理状況（処理

に関わる機関や審査状況等）を一元的に確認することができる。

（２） 各機関とのサービス連携

各機関とのサービス連携に当たっては、各機関の自立性を尊重し、疎結合（ 小限の影

響、 小限の依存関係）による連携とすることを基本的な方針とする。各サービスは各機関

によって提供されるものであり、「公共サービス連携基盤（仮称）」が各機関のサービスを呼

び出し、処理結果をまとめる機能を提供する。そのため、連携先となる様々な機関とサービ

ス連携が可能となるように、「公共サービス連携基盤（仮称）」内の外部接続機能に、以下

に示す標準インターフェース（図 I-15の中では凹型の図で示しているもの）を用意する。

（ア） 標準インターフェース

各機関の保有する既存システムは、様々な設計思想に基づいて構築されており、アプリ

ケーション、データ、インフラストラクチャ等が必ずしも統一されているわけではない。よって、

複数の機関にまたがっての円滑な連携を行うためには、連携のためのデータ・フォーマット

とプロトコルを取り決めた、「公共サービス連携基盤(仮称)」の用意する標準インターフェー

スを用いて接続することが必要となる。

標準インターフェースの仕様に関しては、現状において各機関で稼働している業務シス

テムと容易に連携できることを考慮し、レガシーシステム12、地域情報プラットフォーム13、

SOA準拠のシステム等の一般的なプラットフォームを対象として対応範囲を検討し、包括的

かつオープンな標準技術に準拠したインターフェースを用意する。

また、各機関の保有する既存システムには、様々なプラットフォームが存在することから、

標準インターフェースのプロトコルは、FTP14やSOAP15等の複数の国際標準的なプロトコル

をサポートすることとする。

（３） 各機関のハブ機能等

各機関が「公共サービス連携基盤（仮称）」と接続する方法として、機関ごとに個別で接

12 「レガシーシステム」とは、ここでは外部との接続・連携が困難なシステム全般を指す。

13 「地域情報プラットフォーム」は地方公共団体や国・民間等の情報システム同士が相互に接続・連携することを可能にするために定められた、地方公共団体等の各システムが予

め準拠すべき業務面・技術面の標準（ルール）。

14 FTP (File Transfer Protocol) とは、インターネットやイントラネットなどの TCP/IP ネットワークでファイルを転送するときに使われるプロトコル。

15 SOAP (Simple Object Access Protocol) とは、XML や HTTP などをベースとした、他のコンピュータにあるデータやサービスを呼び出すためのプロトコル。

I .標準モデル構築に向けた技術的方策を中心として ３．次世代電子行政サービスを実現する技術的方策の方向性

24

続する方法以外に、接続ポリシーを同じくする複数の機関を束ねてハブ機能等を介して接

続する方法も考えられる。例えば、図I-15で自治体ハブと呼称しているものは、ある範囲で

の共同利用型の仕組みとなることも考えられ、その場合には「公共サービス連携基盤（仮

称）」には共同利用型の仕組みとの連携の機能が必要となる。同様に、民間ハブにおいて

は、金融業界やガス業界といった業界単位での連携の仕組みとなることも想定し、接続方

式を検討しなければならない。したがって、接続機関における統合化や集約化、標準化等

の取組状況を踏まえつつ、「公共サービス連携基盤（仮称）」がサポートする範囲を検討す

る必要がある。

３．４ サービス連携を実現するために各機関側に求められる機能

行政情報の共同利用を実現するサービス連携を 大限に活用するためには、本来、各

機関が保有する行政情報のデータ標準化が必要である。しかし、現状では各機関が保有

する行政情報の仕様は個別に管理・運用されており、様式やデータの呼称などは統一化さ

れていない。各機関の保有するデータを統一的に標準化し、システム的に対応をするには

多くの時間とコストが必要である。そのため、各機関への影響を 小限に抑えつつサービ

ス連携を実現するための方策として、各機関が内部で保有している行政情報を標準仕様に

統一することが困難な場合でも、機関の外部とやりとりするデータを標準仕様に変換するこ

とで連携を可能とすることを基本的な方針とする。

公共サービス連携基盤（仮称）公共サービス連携基盤（仮称）公共サービス連携基盤（仮称）公共サービス連携基盤（仮称）

利⽤者

各機関（各府省、各⾃治体、⺠間企業等）各機関（各府省、各⾃治体、⺠間企業等）各機関（各府省、各⾃治体、⺠間企業等）各機関（各府省、各⾃治体、⺠間企業等）

抽出登録処理要求業務プロセス

管理機能 固有データベース

固有データベース

固有データベース

標準変換アダプタ

バックオフィス連携⽤データストア

バックオフィス連携⽤データストア

返答

外部接続機能

標準変換アダプタ

標準変換アダプタ

公共サービスポータル

公共サービスポータル

公共サービスポータル

添付書類等の添付書類等のやり取りするやり取りする電⼦電⼦ファイルファイルの⼀時的な格納の⼀時的な格納や連携⽤や連携⽤のデータのデータを格納したデータを格納したデータベースベース

データスキーマデータスキーマ各種コード各種コード

⽂字コード等⽂字コード等を標準仕様に変換を標準仕様に変換

外部連携サービス

データの送受信データの送受信

IDID変換変換

図 I-16 サービス連携を実現するために各機関側に求められる機能

各機関固有のデータベースに格納されたデータは、様々な形式で管理されている。それ

らを 小限の影響で連携させるために、本人データを特定できるIDやコード、スキーマ（デ

ータの構造）をやり取りできる形式に変換する仕組みと、変換したデータを制御する仕組み

が必要となる。各機関の保有するシステムの状況に応じて必要となる機能を図I-16に示

す。

I .標準モデル構築に向けた技術的方策を中心として ３．次世代電子行政サービスを実現する技術的方策の方向性

25

（１） バックオフィス連携用データストア

各機関が保有する行政情報のうち他機関とのバックオフィス連携に必要となる情報につ

いて、標準変換アダプタを介して標準仕様に変換し、各機関が用意する「バックオフィス連

携用データストア」に格納する。また、この「バックオフィス連携用データストア」に対して「公

共サービス連携基盤（仮称）」からの情報提供要求を制御する機能として、各機関の側に

「外部連携サービス」を用意する。

「バックオフィス連携用データストア」に格納されるデータは、各機関の標準仕様への対

応状況に応じて、添付書類のような単位での電子的なファイルであったり、公開前提のデ

ータベース等であることが考えられる。

なお、既に各機関の持つデータベースが標準仕様に準拠している場合等において、バッ

クオフィス連携用データストアは物理的に必ずしも必要ではない。バックオフィス連携用デ

ータストアは、各機関におけるシステムのセキュリティポリシーや、運用の容易性等に応じ

て用意されるべきものであり、ここでは論理的な機能として示すものである。

（２） 外部連携サービス

外部連携サービスは「公共サービス連携基盤（仮称）」からのデータ連携要求に基づきデ

ータの送受信等の制御を行う。また、サービスの連携時に、連携用のIDと各機関のIDの変

換を行う。外部連携サービスは、バックオフィス連携用データストアに格納されるデータに応

じて、ファイルの送受信を制御するプログラムであったり、公開前提のデータベースを処理

する公開前提のサービス（例えば、住所情報検索サービス等）であることが考えられる。

なお、外部連携サービスは「公共サービス連携基盤（仮称）」を介してのみ利用される。

（３） 標準変換アダプタ

標準変換アダプタは各機関の固有データを「公共サービス連携基盤（仮称）」のデータ標

準仕様に変換するもので、データのスキーマやコード（自治体コードや性別コード等）ないし、

文字コードの変換を行う。この標準変換アダプタを介することで、各機関の保有するデータ

が必ずしも全て標準仕様に準拠していなくても、 小限の範囲での対応によってサービス

連携を行うことが可能となる。なお、既に標準仕様に準拠したデータを保有する機関には必

ずしも必要な機能ではない。

３．５ データの標準化を推進する方策

将来的に行政情報のみならず民間企業等の保有する情報も含めた広範囲での情報の

連携を実現するためには、標準データ変換アダプタを用いた必要 低限のデータ連携と並

I .標準モデル構築に向けた技術的方策を中心として ３．次世代電子行政サービスを実現する技術的方策の方向性

26

行して、緩やかでも、より効率的なデータ連携を目標とした広範囲でのデータの標準化の

取組が求められる。その際、標準化の仕組みも当初から 低限のものを整備して、徐々に

標準化の対象範囲を拡大していくよう考慮が必要である。これらを当初より整備しておかな

ければ、各分野や各機関での固有の標準化の取組が行われ、結果的に効率的なデータ連

携を阻害してしまう可能性がある。したがって、当初から一貫して必要な仕組みとして、デ

ータの標準化を推進するための以下の機能を用意する。

各機関（各府省、各⾃治体、⺠間企業等）各機関（各府省、各⾃治体、⺠間企業等）各機関（各府省、各⾃治体、⺠間企業等）各機関（各府省、各⾃治体、⺠間企業等）

抽出登録 固有

データベース

固有データベース

固有データベース

標準変換アダプタ

バックオフィス連携⽤データストア

バックオフィス連携⽤データストア 標準変換

アダプタ

標準変換アダプタ

外部連携サービス

公共サービス連携基盤（仮称）公共サービス連携基盤（仮称）公共サービス連携基盤（仮称）公共サービス連携基盤（仮称）

各機関（各府省、各⾃治体、⺠間企業等）各機関（各府省、各⾃治体、⺠間企業等）各機関（各府省、各⾃治体、⺠間企業等）各機関（各府省、各⾃治体、⺠間企業等）

抽出登録処理要求業務プロセス

管理機能 固有データベース

固有データベース

固有データベース

標準変換アダプタ

バックオフィス連携⽤データストア

バックオフィス連携⽤データストア

全体全体標準標準ライブラリライブラリ

個別個別標準標準ライブラリライブラリ

返答標準変換アダプタ

標準変換アダプタ

外部連携サービス

各機関の各機関の公開データに関する公開データに関する仕様や属性情報仕様や属性情報

外部接続機能

個別個別標準標準ライブラリライブラリ

収集収集

収集収集⽣成

⽂字コード⽂字コードデータデータ

変換変換ライブラリライブラリ

連携機関全体の連携機関全体の公開データに関する公開データに関する仕様や属性情報仕様や属性情報

登録登録

登録登録

活⽤活⽤活⽤活⽤コードコード

データデータ変換変換ライブラリライブラリ

スキーマスキーマ変換変換ライブラリライブラリ

変換テーブル等の変換テーブル等の雛型雛型

各種変換ライブラリ

図 I-17 データ標準化を推進する方策

（１） 全体標準ライブラリ

各機関において、公開可能な情報を定義する際に、データの仕様や属性情報等を個別

標準ライブラリに登録する。各機関の個別標準ライブラリに登録したデータの仕様や属性

情報等は、「公共サービス連携基盤（仮称）」の全体標準ライブラリに登録される。標準ライ

ブラリの中にはデータの用語や意味も管理されるため、辞書のような役割を持たせることが

できる。この情報を活用することにより、他機関が登録した用語とデータ形式、及び、その

関係を参照でき、新しく登録する用語、データ形式を事前に登録された情報と揃えることに

より、公開データの範囲の拡大や、更に効率的なサービス連携のためのデータ標準化を促

進することができる。

（２） 標準のデータ仕様に変換するための各種変換ライブラリの提供

各機関は「公共サービス連携基盤（仮称）」を利用するために、各機関の固有データを標

準のデータ仕様に変換するための標準変換アダプタを用意する必要があるが、標準変換

アダプタの構築を容易にするために、「公共サービス連携基盤（仮称）」の側でスキーマ変

換ライブラリ、コード変換ライブラリ、文字コード変換ライブラリを提供する。

スキーマ変換ライブラリとは、データの表現形式（XMLスキーマ）の雛形の集合体であり、

I .標準モデル構築に向けた技術的方策を中心として ３．次世代電子行政サービスを実現する技術的方策の方向性

27

コード変換ライブラリとはコードの表現形式（変換ロジックとテーブルの雛形）の集合体であ

る。また、文字コード変換ライブラリとは、文字コードの表現形式（変換ロジックとテーブルの

雛形）の集合体である。

各機関は提供された各変換ライブラリを、標準仕様への変換ロジックの作成や変換テー

ブルの作成時のリファレンスとして活用することが可能となるため、標準変換アダプタの開

発に係るコストを 小限に抑えることができる。さらに、自身の保有する固有データに関し

ても必要に応じて標準仕様に準拠するための取組を容易とすることで、より多くの機関をま

たがった広範囲でのデータ標準化を徐々に推進させることが期待できる。

（３） データ標準化に向けたルール

必要 低限のデータ連携の仕組みと合わせて、より広範囲でのデータの標準化を推進

するためには、標準を定めるルールの策定が必要となる。

地方公共団体のデータについては地域情報プラットフォームによって既に標準化が進ん

でいるが、府省や企業を含めた広範囲のデータの標準化には非常に多くの労力やコストを

必要とすることが予想される。それらの実現を、より効率よく、無駄な投資を 小限にしつつ

目指すためには、データ標準仕様について関係機関において十分に検討した結果を踏ま

え、統一的なルールを作成し、標準化の方向性を統一する必要がある。

以下のルールについて、まずは流通させるためのデータ標準仕様の策定に向けて検討

を行う必要がある。

行政情報作成ガイドライン

XML16タグの命名ルールを規定したもの。個別ないし全体標準ライブラリの登録・活用に

関するガイドラインも含まれる。なお、地域情報プラットフォームにおいて地方自治体のデー

タ標準が定義されているXMLプロファイルの成果を活用し、さらに、府省や企業等との接続

用途の拡大にしたがって、定義範囲の拡大や強化を行っていくことが望ましい。

行政情報カタログ

書誌情報を規定したルール。全体標準ライブラリでは属性や仕様として表現される。行

政情報カタログを整備することで、どの機関がどういったデータを保有しているか等の情報

を活用することができる。

（例、作成年月日、作成者、データの概要、等）

DRM（Data Reference Model：データ参照モデル）

DRMは、組織を超えて共有される可能性の高いデータ・情報について、名称、定義およ

I .標準モデル構築に向けた技術的方策を中心として ３．次世代電子行政サービスを実現する技術的方策の方向性

28

び各種の属性（桁数など）を統一的に記述したモデルである。データの共有・再利用・統合

などを促進するための、共通で一貫性のある分類・記述方法を提供し、個々のデータ体系

を作成する上で参照すべき標準となる。経済産業省の提唱するEA（Enterprise

Architecture）17においても、DRMの必要性が示されている。

なお、データ標準化のアプローチには、「公共サービス連携基盤（仮称）」が統一的な標

準化ルールを作成し、それに関係機関が準拠するトップダウンのアプローチと、各機関の

必要に応じて統一的な標準化ルールを拡大していくボトムアップのアプローチが考えられる。

まずは、データ連携に必要な 低限のルール作りをトップダウンで行い、運用後の連携範

囲の拡大にしたがってボトムアップでの標準化の取組を実施することが現実的である。トッ

プダウンでのアプローチに当たっては、地方公共団体のデータ標準を規定した地域情報プ

ラットフォームや、金融業界での財務情報の標準であるXBRL18等の先行した取組の成果を

活用して検討を行う。

３．６ 検討すべき技術要素

次世代電子行政サービス基盤を実現するために検討が必要と思われる主な技術要素を

図 I-18に示す。本書の第4章では、利用者への情報提供やプッシュ型サービス等、バック

オフィス連携を活用するために必要となる公共サービスポータルについて、技術的な要素

の各論を示す。また、第5章では「公共サービス連携基盤（仮称）」と接続機関とのサービス

やデータの連携において検討が必要となる技術的な要素の各論を示す。

16 XML (Extensible Markup Language) とは、文書やデータの意味や構造を記述するためのマークアップ言語の一つ。マークアップ言語とは、「タグ」と呼ばれる特定の文字列で情報

の意味や構造、装飾などを指定する言語のこと。XML はユーザが独自のタグを指定できることから、マークアップ言語を作成するための「メタ言語」とも言われる。

17 経済産業省 EA ポータル http://www.meti.go.jp/policy/it_policy/ea/index.html

18 XBRL (eXtensible Business Reporting Language) http://www.xbrl-jp.org/about/index.html

I .標準モデル構築に向けた技術的方策を中心として ３．次世代電子行政サービスを実現する技術的方策の方向性

29

公共サービス連携基盤（仮称）公共サービス連携基盤（仮称） 「項⽬番号」「項⽬番号」 「検討事項」「検討事項」「項⽬番号」「項⽬番号」 「検討事項」「検討事項」

アプリケーションアプリケーション関連関連

データ関連データ関連

インフラ関連インフラ関連

44.1 .1 プル型情報提供プル型情報提供44.1 .1 プル型情報提供プル型情報提供

44.1 .1 カスタマイズ機能カスタマイズ機能44.1 .1 カスタマイズ機能カスタマイズ機能

44.1 .1 インテリジェント検索インテリジェント検索44.1 .1 インテリジェント検索インテリジェント検索

44.1 .1 プッシュ型情報提供プッシュ型情報提供44.1 .1 プッシュ型情報提供プッシュ型情報提供

44.1 .1 エージェント型情報提供エージェント型情報提供44.1 .1 エージェント型情報提供エージェント型情報提供

44.1.1 ワンストップ申請ワンストップ申請44.1.1 ワンストップ申請ワンストップ申請

44.1.1 認証・署名認証・署名44.1.1 認証・署名認証・署名

ポータルサービスポータルサービス バックオフィス連携サービスバックオフィス連携サービス

ID ID

5.15.1 サービス連携サービス連携5.15.1 サービス連携サービス連携

5.15.1 セキュリティセキュリティ5.15.1 セキュリティセキュリティ

５５.1.1 ディレクトリ連携ディレクトリ連携５５.1.1 ディレクトリ連携ディレクトリ連携

5.15.1 ⽂字コード⽂字コード変換変換5.15.1 ⽂字コード⽂字コード変換変換

5.15.1 サービスレベルサービスレベル5.15.1 サービスレベルサービスレベル

５５.2.2 データデータ連携連携粒度粒度５５.2.2 データデータ連携連携粒度粒度

5.25.2 データデータ標準化標準化5.25.2 データデータ標準化標準化

５５.2.2 標準変換標準変換アダプタアダプタ５５.2.2 標準変換標準変換アダプタアダプタ

各機関各機関

図 I-18 検討すべき技術要素

これらの技術的な要素を、漏れなく体系的に検討し、要件を明確化していくことで、次世

代電子行政サービスを実現するための方策をより具体化する。

I .標準モデル構築に向けた技術的方策を中心として ４．公共サービスポータルを実現する技術要素

30

４．公共サービスポータルを実現する技術要素

４．１ 公共サービスポータルの検討

（１） 公共サービスポータルの要件

利用者が様々な行政サービスをワンストップで利用するために、公共サービスポータル

に求められる要件を図 I-19に示す。

プル型情報提供／カスタマイズプル型情報提供／カスタマイズ利⽤者に必要な情報を簡便に探してもらうために、必要な情報をわかりやすく整理して提供利⽤者に必要な情報を簡便に探してもらうために、必要な情報をわかりやすく整理して提供する（ホームページによる情報提供等）する（ホームページによる情報提供等）。。

インテリジェント検索インテリジェント検索⾏政⼿続や書類名を知らなくても必要な情報を検索可能。⾏政⼿続や書類名を知らなくても必要な情報を検索可能。

カスタマイズカスタマイズ利⽤者が公共サービスポータルに表⽰する情報やレイアウト等を⾃由に設定する（いわゆるマ利⽤者が公共サービスポータルに表⽰する情報やレイアウト等を⾃由に設定する（いわゆるマイページの作成）イページの作成） 。。

エージェント型情報提供エージェント型情報提供利⽤者の代理⼈（エージェント）として公共サービスポータルが情報収集する。利⽤者の代理⼈（エージェント）として公共サービスポータルが情報収集する。

プッシュ型情報提供プッシュ型情報提供各府省・⾃治体等から利⽤者に情報を発信する。各府省・⾃治体等から利⽤者に情報を発信する。

ワンストップ申請ワンストップ申請ライフイベント等に応じて必要となる複数の申請等をワンストップで⾏う。ライフイベント等に応じて必要となる複数の申請等をワンストップで⾏う。

いつ、どんな⼿続きをすればいいかいつ、どんな⼿続きをすればいいかわかわかりやすいりやすい

必要な情報が必要な情報が簡単に簡単に⾒つけられる⾒つけられる

⾃分が利⽤できる⾏政サービスが⾃分が利⽤できる⾏政サービスが事前にわかる事前にわかる

ワンストップで申請ができるワンストップで申請ができる

⾏政が⾏政が公開している情報公開している情報をを⾃動⾃動収集できる収集できる

機能として実装するもの機能として実装するもの

書いてある内容が理解しやすい書いてある内容が理解しやすい

認証・署名認証・署名オンラインで本⼈確認オンラインで本⼈確認をしたり、をしたり、電⼦データの作成者の実証と電⼦データの真正性を確認す電⼦データの作成者の実証と電⼦データの真正性を確認する。る。

利⽤者の要件

利⽤者の要件

図 I-19 公共サービスポータルに求められる要件

（２） プル型情報提供機能/カスタマイズ機能

（ア） プル型情報提供機能の概要

利用者に必要な情報を簡便に探してもらうために、必要な情報をわかりやすく整理して

提供する機能（ホームページによる情報提供等）。利用者が必要な情報を容易に得ること

ができるよう、分類、順序、言葉遣いに配慮したメニューを提供し、利用者が必要な情報に

容易にたどり着け、その内容をすぐに理解できるよう、分かりやすい表現で情報提供を行

う。

他のWebサイトが利用できるよう、コンテンツ（メニューや情報）を、Webサービス技術やマ

ッシュアップ技術等を用いて提供する他、ライブラリ19として提供することが考えられる。

19 ライブラリとは、ある特定の機能を持ったプログラムを、他のプログラムから利用できるように部品化したものを指す。

I .標準モデル構築に向けた技術的方策を中心として ４．公共サービスポータルを実現する技術要素

31

（イ） カスタマイズ機能の概要

利用者が公共サービスポータルに表示する情報やレイアウト等を自由に設定する機能

（いわゆるマイページの作成機能）である。サイト内部のコンテンツだけでなく、マッシュアッ

プにより、外部コンテンツも合わせて利用可能とすることが考えられる。

（ウ） 利用の流れ

図 I-20に示すように、利用者はカスタマイズ機能を用いて、公共サービスポータルに表

示する情報やレイアウト等を利用者情報格納エリアに登録する。変更する場合も同様の手

順で、利用者情報格納エリアの登録情報を更新する。利用者が、公共サービスポータルの

プル型情報提供機能を利用する際は、利用者情報格納エリアに登録された公共サービス

ポータルに表示する情報やレイアウト等の情報を参照し、利用者が設定したとおりに、コン

テンツを表示する。その際は、公共サービスポータルのコンテンツだけではなく、他のWeb

サイトのコンテンツを呼び出し、合わせて表示することが考えられる。また、他のWebサイト

が、公共サービスポータルから提供されたライブラリや、マッシュアップ技術の活用により、

公共サービスポータルの持つコンテンツを提供することも考えられる。

各府省・⾃治体等各府省・⾃治体等各府省・⾃治体等各府省・⾃治体等各府省・⾃治体等各府省・⾃治体等

公共サービスポータル

他のWebサイト

利⽤者情報格納

エリア

他のWebサイト

プル型情報提供機能

カスタマイズ機能

コンテンツプル型情報提供機能

（マッシュアップ）

プル型情報提供機能

呼出

登録・更新

参照

参照

ライブラリ提供 登録・更新

コンテンツ

コンテンツ

外部コンテンツの呼出

図 I-20 プル型情報提供機能／カスタマイズ機能

（３） インテリジェント検索機能

（ア） インテリジェント検索機能の概要

利用者が、具体的な行政手続名や書類名を知らなくても、 小限の情報で必要な情報を

検索できるようにする機能。曖昧検索、情報の重み付け等の技術を活用することが考えら

れる。また、他のWebサイトが利用できるよう、Webサービス技術やマッシュアップ技術等を

用いて提供することが考えられる。

なお、昨今の検索技術は著しく発達しており、 新の技術動向を踏まえ、必要に応じて

機能に取り込む必要がある。利用者の希望する情報を、より簡易に見つけることを可能と

I .標準モデル構築に向けた技術的方策を中心として ４．公共サービスポータルを実現する技術要素

32

する技術として、例えば、SEM（Search Engine Marketing：検索エンジンマーケティング）20、

SEO（Search Engine Optimization：検索エンジン 適化）21等の技術も参考となる。

（イ） 利用の流れ

図 I-21に示すように、利用者は、インテリジェント検索機能を用いて、必要な情報を検索

する。インテリジェント検索機能は、曖昧検索情報や重み付け情報を参照し、利用者が求

めるコンテンツを提供する。また、他のWebサイトが、マッシュアップ技術の活用により、公

共サービスポータルの持つインテリジェント検索機能を、自分のWebサイトのサービスとして

提供することも考えられる。

公共サービスポータル

他のWebサイト

インテリジェント検索機能

インテリジェント検索機能（マッシュアップ）

曖昧検索情報

重み付け情報

呼出呼出

参照参照

参照参照

参照参照

各府省・⾃治体等各府省・⾃治体等各府省・⾃治体等各府省・⾃治体等各府省・⾃治体等各府省・⾃治体等

コンテンツ 登録・更新登録・更新

図 I-21 インテリジェント検索機能

（４） プッシュ型情報提供機能

（ア） プッシュ型情報提供機能の概要

利用者の事前の情報提供要求登録に基づき、各府省・自治体等から利用者に対して、メ

ール等で情報提供を行う機能。各府省・自治体等から利用者へのお知らせなどを、利用者

の属性情報に応じて配信できる。本人確認が必要な情報については、メール等で案内をし、

オンライン認証をした上で情報を提供する。また、他のWebサイトが利用できるよう、Webサ

ービス技術やマッシュアップ技術等を用いて提供することが考えられる。

（イ） 利用の流れ

図 I-22に示すように、利用者は、情報提供要求登録機能を用いて、連絡先（メールアド

レス）や分類、属性情報等を利用者情報格納エリアに登録する。変更する場合も同様の手

20 検索エンジンを通じてサイトへの訪問者を増やすマーケティング手法を指す。

21 SEM の具体的な方法のひとつで、ロボット型検索エンジンに上位表示させるための手法を指す。

I .標準モデル構築に向けた技術的方策を中心として ４．公共サービスポータルを実現する技術要素

33

順で、利用者情報格納エリアの登録情報を更新する。各府省・自治体等は、公共サービス

ポータルに、分類や対象条件、配信期間などの属性情報を付加した状態で、情報を登録す

る。その際、分類や対象条件の区分は、利用者が登録する属性情報等と同じ区分とする。

公共サービスポータルは、定期的に利用者情報格納エリアと各府省・自治体等が登録した

情報を参照して、利用者が登録した分類や属性情報等に一致する情報を抽出し、利用者

に対してメールで情報を配信する。利用者は、メールなどで情報を確認する。本人確認が

必要な情報（例：ねんきん定期便、定額給付金等の個人あて通知）については、メールなど

の案内に従い、公共サービスポータルでオンライン認証をした上で、各府省・自治体等から、

情報を確認する。

各府省・⾃治体等各府省・⾃治体等各府省・⾃治体等各府省・⾃治体等各府省・⾃治体等各府省・⾃治体等

公共サービスポータル

利⽤者情報格納

エリア

情報提供を希望する利⽤者は、⾃⾝の連絡先（メールアドレス）や分類、属性情報等を登録する。

配信機能

分類や対象条件、配信期間などの属性情報を付加した状態で、

情報を登録する。分類や対象条件の区分は利⽤者が登録する情報と同じ区分と

する。情報提供要求登録機能

情報提供要求登録で登録した分類や属性情報に⼀致する

情報を抽出し、配信する。

本⼈確認が必要な情報は、オンライン認証をした上で情報を参照す

る。

本⼈確認が不要な情報（⼀時保存）

登録・更新

本⼈確認が必要な

情報参照

参照

認証／情報参照機能

参照

登録・更新

図 I-22 プッシュ型情報提供機能

（５） エージェント型情報提供機能

（ア） エージェント型情報提供機能の概要

利用者の代理人（エージェント）として、公共サービスポータルが行政情報を検索、収集

し、更新情報等を提供する機能。これにより、利用者は自分の関心のある事項に関する

新情報を容易に確認できる（例：受給可能な行政サービス、入札情報、道路更新情報）。

各府省・自治体等の公開情報が検索可能なフォーマット（検索用タグの定義等）であるこ

とが前提条件となる。また、タグの統一的なルール作りなども求められる。

また、他のWebサイトが利用できるよう、Webサービス技術やマッシュアップ技術等を用い

て提供することが考えられる。

（イ） 利用の流れ

図 I-23に示すように、利用者は、情報提供要求登録機能を用いて、メールアドレスや分

I .標準モデル構築に向けた技術的方策を中心として ４．公共サービスポータルを実現する技術要素

34

類、属性情報等を利用者情報格納エリアに登録する。変更する場合も同様の手順で、利用

者情報格納エリアの登録情報を更新する。

公共サービスポータルは、情報収集機能により、定期的に各府省・自治体等の公開情報

を収集する。また、利用者情報格納エリアを参照して、利用者が情報提供要求登録で登録

した分類や属性情報等に一致する情報を収集情報から抽出し、利用者に対してメールなど

で更新情報等を配信する。

各府省・⾃治体等各府省・⾃治体等各府省・⾃治体等各府省・⾃治体等各府省・⾃治体等各府省・⾃治体等

公共サービスポータル

利⽤者情報格納

エリア

情報提供を希望する利⽤者は、⾃⾝の連絡先（メールアドレス）や分類、属性情報等を登録する。

配信機能

情報提供要求登録機能

公開情報情報収集

登録・更新

参照

参照

情報収集機能

収集情報（⼀時保存）

図 I-23 エージェント型情報提供機能

（６） ワンストップ申請機能

ライフイベント等に応じて必要となる複数の申請等をワンストップで行う機能。既に、「次

世代電子行政サービスの実現に向けたグランドデザイン」（平成20年6月4日）において、引

越及び退職のワンストップサービスについて、現状、方向性、課題と具体的方策、及び効果

を明らかにした。

また、引越ワンストップサービスについては、「引越ワンストップサービス実現へ向けての

段階的アプローチ」（平成21年10月26日予定：本報告書のⅡ部に挿入予定）を取りまとめる

予定である。退職ワンストップサービスについては、「退職ワンストップサービス実現へ向け

ての段階的アプローチ」（平成21年7月27日：本報告書のⅢ部に当たる）を取りまとめたとこ

ろである。

（７） 認証・署名機能

オンラインで本人確認をするためのオンライン認証機能と電子データの作成者の実証と

電子データの真正性を確認するための電子署名の機能。電子署名については、電子署名

及び認証業務に関する法律（平成12年法律第102号）、電子署名に係る地方公共団体の認

証業務に関する法律（平成14年法律第153号）に基づき、公的個人認証等の電子署名のた

めの基盤が整備されている。

I .標準モデル構築に向けた技術的方策を中心として ４．公共サービスポータルを実現する技術要素

35

また、電子政府ガイドライン作成検討会セキュリティ分科会において、手続ごとにリスク

評価を行い、リスク評価に基づく保証レベルの導出や認証・署名を中心としたセキュリティ

対策の在り方について、検討が行われている。

公的個人認証については、総務省の公的個人認証サービス普及拡大検討会において、

認証用途の付加、記録媒体の拡大、オンライン更新、有効期限の延長、署名検証者の拡

大、利用用途の拡大（署名メール及び暗号メール）について検討が行われている。

I .標準モデル構築に向けた技術的方策を中心として ５．「公共サービス連携基盤（仮称）」を実現する技術要素

36

５．「公共サービス連携基盤（仮称）」を実現する技術要素

５．１ 接続機関との連携方式の検討

（１） 「公共サービス連携基盤（仮称）」の要件

添付書類削減による利用者の利便性の向上やバックオフィス業務の効率化を実現する

ために、国、地方、民間企業等の複数機関のバックオフィスとの連携を可能とする基盤とし

て、「公共サービス連携基盤（仮称）」を構築する。

図 I-24に「公共サービス連携基盤（仮称）」に求められる要件と対応する解決策を示す。

利⽤者の要件

利⽤者の要件

ディレクトリディレクトリ利⽤者の希望するサービスの管理や、疎結合を⾏うための送り先機関の所在の管理、利⽤利⽤者の希望するサービスの管理や、疎結合を⾏うための送り先機関の所在の管理、利⽤者の利⽤する者の利⽤するIDIDと送り先機関とやり取りすると送り先機関とやり取りするIDIDの連携を⾏うもの。の連携を⾏うもの。

ログ管理ログ管理利⽤者の個⼈情報がどの機関から参照されたのかを、利⽤者に対して表⽰する。また、不正利⽤者の個⼈情報がどの機関から参照されたのかを、利⽤者に対して表⽰する。また、不正なやりとりの監視のために証跡を記録する。なやりとりの監視のために証跡を記録する。

業務プロセス管理業務プロセス管理現⾏の業務を利⽤者の利便性の観点から⾒える化（各プロセスの順序や申請の処理状況現⾏の業務を利⽤者の利便性の観点から⾒える化（各プロセスの順序や申請の処理状況等）し、業務プロセスをユースケースにそって管理する。等）し、業務プロセスをユースケースにそって管理する。

アクセス制御アクセス制御各機関のサービスおよびデータの連携状況に基づき、利⽤可能なサービスの制御を⾏う。各機関のサービスおよびデータの連携状況に基づき、利⽤可能なサービスの制御を⾏う。

レジストリレジストリサービス連携に必要なサービス連携に必要な各接続機関のサービスの仕様情報を各接続機関のサービスの仕様情報を管理管理する。する。

⼀時情報保管⼀時情報保管各機関との疎結合による連携を可能とするため、各機関からの各機関との疎結合による連携を可能とするため、各機関からの申請処理や照会処理等の申請処理や照会処理等の結結果を、任意のタイミングで、⼀時的に保管する。果を、任意のタイミングで、⼀時的に保管する。

⾏政情報の⽬的外の利⽤を禁⽌⾏政情報の⽬的外の利⽤を禁⽌

⾃分の情報がどこからどこへ送付されたか確認できる⾃分の情報がどこからどこへ送付されたか確認できる

情報の連携に当たっては本⼈の同意を得る情報の連携に当たっては本⼈の同意を得る

データ等の標準化データ等の標準化

疎結合な連携疎結合な連携（最⼩限の影響・依存関係での連携）（最⼩限の影響・依存関係での連携）

アプリケーションの認証アプリケーションの認証

SOASOA（（Service Oriented ArchitectureService Oriented Architecture））各機関における様々な既存システムとの各機関における様々な既存システムとの透過的な透過的な連携や、将来的な維持コストの削減、また、連携や、将来的な維持コストの削減、また、「「公共サービス連携基盤公共サービス連携基盤（仮称）」（仮称）」の拡張性を考慮し、の拡張性を考慮し、SOASOAベースでカセッタブルベースでカセッタブルな（疎結合でな（疎結合で柔軟に組み合わせ可能な）柔軟に組み合わせ可能な）アーキテクチャーを構築する。アーキテクチャーを構築する。

ポリシーの違いを意識した連携ポリシーの違いを意識した連携各機関の⾃⽴性を尊重しつつ、最適な範囲での連携を考慮する必要がある。情報の機微度各機関の⾃⽴性を尊重しつつ、最適な範囲での連携を考慮する必要がある。情報の機微度合やセキュリティ等のポリシーの違いを踏まえて、⾃治体や⺠間企業といったそれぞれの範囲で合やセキュリティ等のポリシーの違いを踏まえて、⾃治体や⺠間企業といったそれぞれの範囲での連携を考慮する必要がある。の連携を考慮する必要がある。

システムの要件

システムの要件

各機関データベースの⾃⽴性の尊重各機関データベースの⾃⽴性の尊重

第第33者機関による監視者機関による監視利⽤者の要件として、情報の勝⼿な連携や不正な利⽤を防⽌するために有効な仕組みとし利⽤者の要件として、情報の勝⼿な連携や不正な利⽤を防⽌するために有効な仕組みとして、第三者機関による監視が考えられる。て、第三者機関による監視が考えられる。

全体的に関連

現⾏業務の内容や流れを⾒直す現⾏業務の内容や流れを⾒直す

地域情報プラットフォームとの連携地域情報プラットフォームとの連携(※

（※ 「地域情報プラットフォーム」は地⽅公共団体や国・⺠間等外部の情報システムとの間で、相互に接続・連携できるよう、地⽅公共団体の各システムが予め準拠すべき業務的・技術的な標準（ルール）。

機能として実装するもの機能として実装するもの

全体的な制約条件全体的な制約条件

図 I-24 「公共サービス連携基盤（仮称）」に求められる要件

図 I-24では、左側に「公共サービス連携基盤（仮称）」に求められる要件を挙げ、利用者

の要件とシステムの側の要件を分類し示している。

（ア） 利用者の要件

情報の連携に当たっては本人の同意を得る

利用者が希望した場合のみ情報連携し、本人の意図なく勝手には連携しないという、

利用者の不安を取り除くための要素。ただし、現状においても法令等で定められた

公用請求及び通知事務等によって他機関への情報の提供が認められているケース

I .標準モデル構築に向けた技術的方策を中心として ５．「公共サービス連携基盤（仮称）」を実現する技術要素

37

があることについて留意する必要がある。

行政情報の目的外の利用を禁止

行政情報を他の機関へ電子的に提供するに当たっては、相応のセキュリティ対策が

必要となる。例えば、行政情報にアクセスすることが可能となる役割の者においても、

自身の興味本位による情報収集や横串検索などを防止するということが求められ

る。

現行業務の内容や流れを見直す

電子的処理を前提とし、かつ縦割り行政を排除した全体 適を目指した業務プロセ

スに変革していく。もちろん、この業務プロセスの変革は利用者視点でのサービス提

供を踏まえ、例えば複数機関において同様の業務プロセスが存在する場合には、標

準化や共同利用などの要素により効率化を図るものでなければならない。

自分の情報がどこからどこへ送付されたか確認できる

利用者の個人情報が扱われる可能性があるため、利用者は自身の情報がどの機

関によって参照されたのかを確認できることが求められる。

（イ） システムの要件

疎結合な連携（ 小限の影響・依存関係での連携）

疎結合は本仕組みにおいて基本的な設計思想に当たるものであり、多くの機関を集

約する基盤に求められる重要な要素である。例えば、接続機関における影響を 小

限にとどめ連携を可能とすることや、比較的容易な範囲から徐々に取組を拡大して

いく際の、汎用的な拡張性等を考慮することが求められる。

データ等の標準化

複数の異なる形式でデータを扱う機関を連携させるためには、連携させるデータの

標準化、サービス連携方式の標準化等が必要となる。また、さらに効率的にデータ

連携を行うためには、中長期的に広い範囲でのデータ標準化が求められ、その推進

のための仕組みも求められる。

アプリケーションの認証

接続機関において処理を行う外部連携サービス等のアプリケーションは、セキュリテ

ィの観点から、個人で開発されたアプリケーションなどのすべてが接続可能となるわ

けではなく、あらかじめ登録されたアプリケーションのみが接続可能とする等の考慮

が必要となる。

各機関のデータベースの自立性の尊重

各機関が保有するデータベースの自立性を尊重しつつ、投資対効果を踏まえ、 適

な方法での連携を可能とするよう考慮する必要がある。

地域情報プラットフォームとの連携

既存のIT環境として、地域情報プラットフォームに準拠するシステムは、地方公共団

体において普及が始まっているため、地域情報プラットフォームにて規定されている

標準化の取組等を踏まえつつ、あらかじめ容易に連携可能となるよう検討する必要

I .標準モデル構築に向けた技術的方策を中心として ５．「公共サービス連携基盤（仮称）」を実現する技術要素

38

がある。

これらの要件を踏まえ、図I-24において解決する方策や機能を定義している。なお、同図

の右側では、桃色の四角で機能を示し、黄色の四角で全体的な制約条件を示している。

ディレクトリ

利用者の希望するサービスの管理や、疎結合を行うための送り先機関の所在の管

理、利用者の利用するID（ログインID）と送り先機関とやり取りするID（連携用ID）の

関係づけを行うもの。

第三者機関による監視

個人情報についての本人が意図しない連携や目的外の利用を防止するために有効

な仕組みとして、第三者機関による監視が考えられる。

業務プロセス管理

ワンストップの申請や各機関の業務サービスの連携を行う際、業務のプロセスを管

理し、プロセスの順番や処理状況を管理する。

ログ管理

利用者や各機関の行政情報がどこからどこへ送られたのかに関するログの記録や、

第三者機関等による情報の不正利用を監視・対策するためのログ管理機能。システ

ム障害の際のリカバリーにも活用される。

レジストリ

各接続機関のサービスの仕様情報を管理し、各機関との連携時に参照するレジスト

リ機能。

アクセス制御

各機関のサービスおよびデータの連携状況に基づき、利用可能なサービスの制御

を行う。

一時情報保管

利用者の申請情報を一時的に保管する、ないし、各機関からの処理結果を任意の

タイミングで受け取るための一時情報保管機能。

ポリシーの違いを意識した連携

各接続機関における、それぞれの範囲での連携や共同利用等、標準的な複数の仕

様での連携を可能とすること。

（２） 「公共サービス連携基盤（仮称）」の機能概要

（１）で挙げた要件を満たすために、「公共サービス連携基盤（仮称）」に図 I-25に示す機

能を持たせることとする。

I .標準モデル構築に向けた技術的方策を中心として ５．「公共サービス連携基盤（仮称）」を実現する技術要素

39

⾃治体⾃治体

ガスガス

電⼒電⼒

⾃治体⾃治体ハブハブ

⾃治体⾃治体

⺠間⺠間ハブハブ

府省府省

外部接続機能

銀⾏銀⾏

認証認証機関機関

公共サービス連携基盤（公共サービス連携基盤（仮称仮称））公共サービス連携基盤（公共サービス連携基盤（仮称仮称））

業務プロセス

管理機能ディレクトリ

機能アクセス制御

機能

ログ管理機能

⼀時情報保管機能

レジストリ機能

業務プロセス

管理機能ディレクトリ

機能アクセス制御

機能業務

プロセス管理機能

ディレクトリ機能

アクセス制御機能

ログ管理機能

⼀時情報保管機能

レジストリ機能

ログ管理機能

⼀時情報保管機能

レジストリ機能

サービスバス

①① ②② ③③

④④ ⑤⑤ ⑥⑥

プル型情報提プル型情報提供機能／カス供機能／カスタマイズ機能タマイズ機能

ワンストップワンストップ申請機能申請機能

エージェント型エージェント型情報提供機能情報提供機能

プッシュ型情報プッシュ型情報提供提供機能機能

インテリジェントインテリジェント検索機能検索機能

認証認証・署名・署名機能機能

公共サービスポータル公共サービスポータル

プル型情報提プル型情報提供機能／カス供機能／カスタマイズ機能タマイズ機能

ワンストップワンストップ申請機能申請機能

エージェント型エージェント型情報提供機能情報提供機能

プッシュ型情報プッシュ型情報提供提供機能機能

インテリジェントインテリジェント検索機能検索機能

認証認証・署名・署名機能機能

公共サービスポータル公共サービスポータル

⑦⑦

図 I-25 「公共サービス連携基盤（仮称）」の機能

以下に、サービス連携に必要な機能として抽出した各機能の概要を示す。

① ディレクトリ機能

利用者の希望するサービスリストの管理と、その要求をどの機関に送ればよい

か管理する機能。

利用者の登録するログインIDと、利用者が利用するサービスを管轄する接続機

関の連携用IDを関連付けする機能。機微な情報に当たるため、暗号化して格納

される。

② アクセス制御機能

利用者がどの機関のどのサービスを利用可能か管理する機能。

③ 業務プロセス管理機能

ワンストップサービスの手続の順番、ステータスを管理する機能。提供するサー

ビスをパターン化して定義する。一般にBPM22（Business Process Management）

を行う機能を持つ。

④ ログ管理機能

どの機関からどの機関へ情報のやりとりが行われたか、証跡を記録する機能

⑤ 一時情報保管機能

業務プロセスの途中状況、各接続機関からの結果情報を一時的に保管しておく

機能。この機能によって、結果の返答は各機関の任意のタイミング（非同期やリ

アルタイムなど）で可能となる。

22 BPM とは、業務管理手法のひとつで、業務の流れを単位ごとに分析・整理することによって、問題点を見出し、 適な作業の仕方を模索する、という管理手法のことである。

I .標準モデル構築に向けた技術的方策を中心として ５．「公共サービス連携基盤（仮称）」を実現する技術要素

40

⑥ レジストリ機能

各接続機関のサービスの仕様情報を管理し、各機関との連携時に参照するレジ

ストリ機能。サービスレジストリ23を管理する。

⑦ 外部接続機能

各機関とのサービス連携の窓口になる機能。複数のオープンな標準技術に準拠

したインターフェースを用いて接続する。

（３） サービス連携利用イメージ

「公共サービス連携基盤（仮称）」と公共サービスポータルおよびバックオフィスの各機関

がサービス連携してワンストップサービスを実現する際に、（２）で示した各機能が、どのよう

に利用されるのか、一般的に考えられるユースケースを用いて、ウォークスルー（ここでは、

定義した機能に抜けや漏れがないかを確認する手法として用いる）のイメージを、以下に

（ア）～（オ）の順で示す。

（ア） ログインから手続メニューの表示

図I-26に流れを示す。

(a) 利用者のログイン（A①）

利用者は、オンライン認証の仕組みを使い、公共サービスポータルからログインする。認

証機能は認証機関へ認証を依頼し、結果を取得する。

(b) 利用可能な手続メニューの取得（A②）

ワンストップ申請機能は、サービスバスを経由して、利用者がディレクトリ（利用者情報格

納エリア）に登録した利用を希望する手続メニューのリストを取得する。

(c) 利用可能な手続メニューの表示（A③）

ワンストップ申請機能は、利用者が希望する手続メニューのリストを表示する。

(d) ログの記録（A④）

サービスバスを経由する処理は、ログ管理機能によって記録される。

23 どんなサービスがどのシステムに実装されているか場所の管理，サービスの機能の記述，サービスの利用方法（パラメータ，メソッド，メッセージ構造），サービス同士の依存関係

の記述，バージョン管理の情報といったものを指す。

I .標準モデル構築に向けた技術的方策を中心として ５．「公共サービス連携基盤（仮称）」を実現する技術要素

41

AA①① ⾃治体⾃治体

ガスガス

電⼒電⼒

⾃治体⾃治体ハブハブ

⾃治体⾃治体

⺠間⺠間ハブハブ

府省府省

外部接続機能

銀⾏銀⾏

認証認証機関機関

公共サービス連携基盤（公共サービス連携基盤（仮称仮称））公共サービス連携基盤（公共サービス連携基盤（仮称仮称））

業務プロセス

管理機能ディレクトリ

機能アクセス制御

機能

ログ管理機能

⼀時情報保管機能

レジストリ機能

業務プロセス

管理機能ディレクトリ

機能アクセス制御

機能業務

プロセス管理機能

ディレクトリ機能

アクセス制御機能

ログ管理機能

⼀時情報保管機能

レジストリ機能

ログ管理機能

⼀時情報保管機能

レジストリ機能

サービスバスAA②②

AA③③AA④④

●ログイン

●⼿続きメニュー

プル型情報提プル型情報提供機能／カス供機能／カスタマイズ機能タマイズ機能

ワンストップワンストップ申請機能申請機能

エージェント型エージェント型情報提供機能情報提供機能

プッシュ型情報プッシュ型情報提供提供機能機能

インテリジェントインテリジェント検索機能検索機能

認証認証・署名・署名機能機能

公共サービスポータル公共サービスポータル

プル型情報提プル型情報提供機能／カス供機能／カスタマイズ機能タマイズ機能

ワンストップワンストップ申請機能申請機能

エージェント型エージェント型情報提供機能情報提供機能

プッシュ型情報プッシュ型情報提供提供機能機能

インテリジェントインテリジェント検索機能検索機能

認証認証・署名・署名機能機能

公共サービスポータル公共サービスポータル

図 I-26 ログインから手続メニューの表示への流れ

（イ） 手続の選択からワンストップ申請の開始

図I-27に流れを示す。

(a) 手続メニューの利用（B①）

利用者は、今回利用する手続メニューを申請情報等の必要な情報の入力と共に呼び出

す。

(b) サービスの利用可否の確認（B②）

ワンストップ申請機能はサービスバスを経由し、アクセス制御機能に問い合わせ、当該

サービスが利用可能かを確認する。

(c) 業務プロセスの呼び出し（B③）

ワンストップ申請機能はサービスバスを経由し、業務プロセス管理機能に定義された業

務プロセスを呼び出す。

(d) 一時情報の保管（B④）

業務プロセス管理機能はサービスバスを経由し一時情報保管機能を呼び出し、各プロセ

スの制御に必要なデータ以外を一時的に格納する。

I .標準モデル構築に向けた技術的方策を中心として ５．「公共サービス連携基盤（仮称）」を実現する技術要素

42

BB①① ⾃治体⾃治体

ガスガス

電⼒電⼒

⾃治体⾃治体ハブハブ

⾃治体⾃治体

⺠間⺠間ハブハブ

府省府省

外部接続機能

銀⾏銀⾏

認証認証機関機関

公共サービス連携基盤（公共サービス連携基盤（仮称仮称））公共サービス連携基盤（公共サービス連携基盤（仮称仮称））

業務プロセス

管理機能ディレクトリ

機能アクセス制御

機能

ログ管理機能

⼀時情報保管機能

レジストリ機能

業務プロセス

管理機能ディレクトリ

機能アクセス制御

機能業務

プロセス管理機能

ディレクトリ機能

アクセス制御機能

ログ管理機能

⼀時情報保管機能

レジストリ機能

ログ管理機能

⼀時情報保管機能

レジストリ機能

サービスバスBB②② BB④④BB③③

●⼿続を選ぶ□情報共有を希望するか？

●申請情報の⼊⼒

●ワンストップ申請（申請を受付ました）（審査完了はX⽇後）

プル型情報提プル型情報提供機能／カス供機能／カスタマイズ機能タマイズ機能

ワンストップワンストップ申請機能申請機能

エージェント型エージェント型情報提供機能情報提供機能

プッシュ型情報プッシュ型情報提供提供機能機能

インテリジェントインテリジェント検索機能検索機能

認証認証・署名・署名機能機能

公共サービスポータル公共サービスポータル

プル型情報提プル型情報提供機能／カス供機能／カスタマイズ機能タマイズ機能

ワンストップワンストップ申請機能申請機能

エージェント型エージェント型情報提供機能情報提供機能

プッシュ型情報プッシュ型情報提供提供機能機能

インテリジェントインテリジェント検索機能検索機能

認証認証・署名・署名機能機能

公共サービスポータル公共サービスポータル

図 I-27 手続の選択からワンストップ申請の開始への流れ

（ウ） バックオフィスへの処理要求

図I-28に流れを示す。

(a) 宛先の問い合わせ（C①）

業務プロセス管理機能は業務プロセスの定義に従って処理すべきサービスを特定し、デ

ィレクトリ機能に宛先を問い合わせる。

(b) 宛先の処理に必要な情報の問い合わせ（C②）

業務プロセス管理機能はレジストリ機能に宛先のサービスの情報を問い合わせる。

(c) 宛先に必要な情報の取得（C③）

業務プロセス管理機能は一時情報保管保存機能から、各宛先のサービスを利用するた

めに必要な情報を取得する。

(d) 接続機関への処理要求（C④）

業務プロセス管理機能はサービスバスを経由し、中央省庁、自治体、民間機関のサービ

スを呼び出す。

（※呼び出しは、順次もしくは並列でも、業務プロセスに応じて可能）

I .標準モデル構築に向けた技術的方策を中心として ５．「公共サービス連携基盤（仮称）」を実現する技術要素

43

⾃治体⾃治体

ガスガス

電⼒電⼒

⾃治体⾃治体ハブハブ

⾃治体⾃治体

⺠間⺠間ハブハブ

府省府省

外部接続機能

銀⾏銀⾏

認証認証機関機関

公共サービス連携基盤（公共サービス連携基盤（仮称仮称））公共サービス連携基盤（公共サービス連携基盤（仮称仮称））

業務プロセス

管理機能ディレクトリ

機能アクセス制御

機能

ログ管理機能

⼀時情報保管機能

レジストリ機能

業務プロセス

管理機能ディレクトリ

機能アクセス制御

機能業務

プロセス管理機能

ディレクトリ機能

アクセス制御機能

ログ管理機能

⼀時情報保管機能

レジストリ機能

ログ管理機能

⼀時情報保管機能

レジストリ機能

サービスバスCC①①CC②②

CC④④

CC④④

CC④④

CC③③

プル型情報提プル型情報提供機能／カス供機能／カスタマイズ機能タマイズ機能

ワンストップワンストップ申請機能申請機能

エージェント型エージェント型情報提供機能情報提供機能

プッシュ型情報プッシュ型情報提供提供機能機能

インテリジェントインテリジェント検索機能検索機能

認証認証・署名・署名機能機能

公共サービスポータル公共サービスポータル

プル型情報提プル型情報提供機能／カス供機能／カスタマイズ機能タマイズ機能

ワンストップワンストップ申請機能申請機能

エージェント型エージェント型情報提供機能情報提供機能

プッシュ型情報プッシュ型情報提供提供機能機能

インテリジェントインテリジェント検索機能検索機能

認証認証・署名・署名機能機能

公共サービスポータル公共サービスポータル

図 I-28 バックオフィスへの処理要求の流れ

（エ） バックオフィスから処理結果を取得

図I-29に流れを示す。

(a) 各機関の処理結果の取得（D①）

各接続機関のサービスは結果を一時情報保管機能に渡す。

（※結果の返答は、順次もしくは並列でも、業務プロセスの定義に応じて可能）

(b) 結果の格納をプロセス管理機能に通知（D②）

一時情報保管機能はサービスバスを経由し、業務プロセス管理機能へ結果が到達した

ことを通知する。

DD①①

⾃治体⾃治体

ガスガス

電⼒電⼒

⾃治体⾃治体ハブハブ

⾃治体⾃治体

⺠間⺠間ハブハブ

府省府省

外部接続機能

銀⾏銀⾏

認証認証機関機関

公共サービス連携基盤（公共サービス連携基盤（仮称仮称））公共サービス連携基盤（公共サービス連携基盤（仮称仮称））

業務プロセス

管理機能ディレクトリ

機能アクセス制御

機能

ログ管理機能

⼀時情報保管機能

レジストリ機能

業務プロセス

管理機能ディレクトリ

機能アクセス制御

機能業務

プロセス管理機能

ディレクトリ機能

アクセス制御機能

ログ管理機能

⼀時情報保管機能

レジストリ機能

ログ管理機能

⼀時情報保管機能

レジストリ機能

サービスバス

DD①①

DD①①

DD②②

（申請状況確認）■府省 完了■⾃治体 完了□電⼒ 処理中

プル型情報提プル型情報提供機能／カス供機能／カスタマイズ機能タマイズ機能

ワンストップワンストップ申請機能申請機能

エージェント型エージェント型情報提供機能情報提供機能

プッシュ型情報プッシュ型情報提供提供機能機能

インテリジェントインテリジェント検索機能検索機能

認証認証・署名・署名機能機能

公共サービスポータル公共サービスポータル

プル型情報提プル型情報提供機能／カス供機能／カスタマイズ機能タマイズ機能

ワンストップワンストップ申請機能申請機能

エージェント型エージェント型情報提供機能情報提供機能

プッシュ型情報プッシュ型情報提供提供機能機能

インテリジェントインテリジェント検索機能検索機能

認証認証・署名・署名機能機能

公共サービスポータル公共サービスポータル

※利⽤者は必要に応じて、ワンストップ申請の処理状況を閲覧することができる

図 I-29 バックオフィスから処理結果を取得する際の流れ

I .標準モデル構築に向けた技術的方策を中心として ５．「公共サービス連携基盤（仮称）」を実現する技術要素

44

（オ） 審査結果の通知と処理結果を集約した結果取得

図I-30に流れを示す。

(a) 審査結果の通知（E①）

業務プロセス管理機能はすべてのプロセスが完了すると、各機関の処理結果を一時情

報保管機能から収集し、 終的なサマリーをワンストップ申請機能へ渡す。場合によっては、

利用者のメールアドレス等へ処理が完了した旨の通知を行う。

(b) 利用者の集約結果取得（E②）

利用者は公共サービスポータルにアクセスし、ワンストップ申請の集約結果を入手する。

⾃治体⾃治体

ガスガス

電⼒電⼒

⾃治体⾃治体ハブハブ

⾃治体⾃治体

⺠間⺠間ハブハブ

府省府省

外部接続機能

銀⾏銀⾏

認証認証機関機関

公共サービス連携基盤（公共サービス連携基盤（仮称仮称））公共サービス連携基盤（公共サービス連携基盤（仮称仮称））

業務プロセス

管理機能ディレクトリ

機能アクセス制御

機能

ログ管理機能

⼀時情報保管機能

レジストリ機能

業務プロセス

管理機能ディレクトリ

機能アクセス制御

機能業務

プロセス管理機能

ディレクトリ機能

アクセス制御機能

ログ管理機能

⼀時情報保管機能

レジストリ機能

ログ管理機能

⼀時情報保管機能

レジストリ機能

サービスバスEE①①EE②②

（審査終了通知）メール等による

●申請結果の⼊⼿

プル型情報提プル型情報提供機能／カス供機能／カスタマイズ機能タマイズ機能

ワンストップワンストップ申請機能申請機能

エージェント型エージェント型情報提供機能情報提供機能

プッシュ型情報プッシュ型情報提供提供機能機能

インテリジェントインテリジェント検索機能検索機能

認証認証・署名・署名機能機能

公共サービスポータル公共サービスポータル

プル型情報提プル型情報提供機能／カス供機能／カスタマイズ機能タマイズ機能

ワンストップワンストップ申請機能申請機能

エージェント型エージェント型情報提供機能情報提供機能

プッシュ型情報プッシュ型情報提供提供機能機能

インテリジェントインテリジェント検索機能検索機能

認証認証・署名・署名機能機能

公共サービスポータル公共サービスポータル

図 I-30 審査結果の通知と集約結果取得の流れ

（４） 各機関とのサービス連携方式のパターン

連携方式を検討するに当たっては、各機関の既存システムへの影響を 小限にとどめ

つつ、「公共サービス連携基盤（仮称）」からの処理要求と各機関からの返答を集約すると

いう機能が求められる。また、各機関の保有するシステムは様々なプラットフォームで稼動

しているため、「公共サービス連携基盤（仮称）」は、各機関の固有の仕組みを極力吸収す

るよう、複数の標準的な仕組みをサポートする必要がある。さらに、各機関が「公共サービ

ス連携基盤（仮称）」と接続する方法として、機関ごとに直接「公共サービス連携基盤（仮

称）」に接続する方法以外に、接続ポリシーを同じくする複数の機関を束ねた共同利用型の

機能を介して接続する方法も考えられるため、各機関の状況を踏まえつつ連携方式を検討

する必要がある。

（ア） 処理要求と結果送付

「公共サービス連携基盤（仮称）」の業務プロセス管理機能により個々の手続単位に分割

I .標準モデル構築に向けた技術的方策を中心として ５．「公共サービス連携基盤（仮称）」を実現する技術要素

45

された申請データは、外部接続機能を経由し接続機関の外部連携サービスに渡される。各

機関の外部連携サービスはデータの送受信を制御し、各機関固有のIDへの変換を行う。

処理要求データの扱いは、各機関のシステムの対応状況によって外部連携サービスが制

御するが、ファイル等を前提とした場合には一旦バックオフィス連携用データストアに格納

され、基幹業務システムに取り込んで処理を行い、その処理結果が再びバックオフィス連

携用データストアに登録される。バックオフィス連携用データストアに格納された処理結果

は、外部連携サービスによって「公共サービス連携基盤（仮称）」の一時情報保管機能に一

時的に保管される。あるいは、バックオフィス連携用データベースに連携を前提としたデー

タベースが構築されている場合には、外部連携サービスがサービス受け入れ窓口となって

バックオフィス連携用データベースから必要なデータを抽出し、「公共サービス連携基盤（仮

称）」の一時情報保管機能に結果を送信する。

このように、各機関の処理状況に応じた任意のタイミングで結果が送信される仕組みと

なる。

なお、バックオフィス連携用データストアと基幹業務システムの間でデータをやり取りする

際は、標準変換アダプタによって、データスキーマ、各種コード、文字コード等の変換を行う。

これによって、各機関の固有のデータをすべて標準仕様に準拠していなくとも、サービスの

連携が可能となる。

また、各機関とのサービス連携を容易にするために、「公共サービス連携基盤（仮称）」

の外部接続機能に、レガシーシステム、地域情報プラットフォーム、SOA準拠のシステム等

の一般的なプラットフォームを対象とした複数の連携可能なインターフェースを用意する。

なお、本案においてはFTPについても許容するとしているが、将来的にはSOAP等による

単一のプロトコルに統一することが望ましい。複数のプロトコルをサポートすることによって、

セキュリティ対策上の管理対象が増えることや、メンテナンス時のテスト作業等も増大する

可能性がある。例えば、FTPをSOAPでラッピングしSOAPとして連携する等の手段も考えら

れ、接続機関のシステムの状況を踏まえつつ、サービス連携の方式を見直していく必要が

ある。

以下の（a）～（c）に、個別の例として、レガシーシステムとの連携、地域情報プラットフォ

ームとの連携、SOAシステムとの連携について、概要を示す。

(a) レガシーシステムとの連携

レガシーシステムと連携する場合、「公共サービス連携基盤（仮称）」と各機関の間の処

理要求・結果のやり取りが、“電子的な書類”等のファイルを用いる可能性があることや、手

作業の介在する連携である可能性も想定しておく必要がある。

I .標準モデル構築に向けた技術的方策を中心として ５．「公共サービス連携基盤（仮称）」を実現する技術要素

46

そうしたシステムとの連携においては、例えば、基幹業務システムの運用者が「公共サ

ービス連携基盤（仮称）からバックオフィス連携用データストアに送信されたファイル（処理

要求が記載されたファイル）を参照し、機関内で手続や審査等に必要なデータ等の確認を

行い、結果を「公共サービス連携基盤（仮称）にファイル転送するという手順が考えられる。

また、連携のプロトコルについては、「公共サービス連携基盤（仮称）の外部接続機能に

よってFTPやHTTP等の既存のものでも可能とする。

なお、レガシーシステムとの連携の場合では、外部連携サービス、バックオフィス連携用

データストア、標準変換アダプタ、ID変換用のディレクトリデータ等が必要となる。

各機関保有DB

外部接続機能

公共サービス連携基盤（仮称）公共サービス連携基盤（仮称）公共サービス連携基盤（仮称）公共サービス連携基盤（仮称）

①レガシーシステム①レガシーシステム①レガシーシステム①レガシーシステム

サービス連携に必要な機能

基幹業務システム業務

プロセス管理機能

ディレクトリ機能

アクセス制御機能

ログ管理機能

⼀時情報保管機能

レジストリ機能

業務プロセス

管理機能ディレクトリ

機能アクセス制御

機能業務

プロセス管理機能

ディレクトリ機能

アクセス制御機能

ログ管理機能

⼀時情報保管機能

レジストリ機能

ログ管理機能

⼀時情報保管機能

レジストリ機能

サービスバス

ディレクトリディレクトリ（（IDID変換テーブル）変換テーブル）

バックオフィス連携⽤バックオフィス連携⽤データストアデータストア

（処理要求と処理結果）（処理要求と処理結果）

IDの変換

処理要求

・データスキーマ変換・データスキーマ変換・各種コード変換・各種コード変換・⽂字コード変換・⽂字コード変換

結果送付

複数の複数の標準的な標準的なプロトコルプロトコル

各機関からの処理結各機関からの処理結果の⼀時的な保管果の⼀時的な保管

外部連携外部連携サービスサービス

・データの送受信・データの送受信・・IDID変換変換

標準変換標準変換アダプタアダプタ

処理結果の登録

処理要求の取込

FTP/HTTP

外部セグメント等連携

図 I-31 レガシーシステムとの連携イメージ

(b) 地域情報プラットフォームに準拠したシステムとの連携

地方自治体において導入が始まっている地域情報プラットフォームと連携する場合のた

めに、「公共サービス連携基盤（仮称）」の外部接続機能に地域情報プラットフォームに対

応したインターフェースを用意しておく。また、地方自治体においては、ある範囲にて共同利

用型の形態にて接続することも考えられるので、接続機関の状況に応じて、対応したインタ

ーフェースを用意する必要がある。

地域情報プラットフォームに準拠している先進的な地方公共団体とのシステム連携は、

庁内の業務システムも含めて標準化された仕組みによる連携が可能である。したがって、

標準仕様に基づく半自動的な（極力人手を排除した）連携により業務の効率化が期待でき

る。例えば、「公共サービス連携基盤（仮称）」からの処理要求に応じて、地域情報プラットフ

ォームの外部連携ユニットが個別業務を呼び出し、処理結果を「公共サービス連携基盤

（仮称）」の一時情報保管機能へ返信するという連携方式が想定される。

なお、地域情報プラットフォームに準拠している場合には、バックオフィス連携用データス

トア、標準変換アダプタ、ID変換用のディレクトリデータ等は必ずしも必要でない。

I .標準モデル構築に向けた技術的方策を中心として ５．「公共サービス連携基盤（仮称）」を実現する技術要素

47

外部接続機能

公共サービス連携基盤（仮称）公共サービス連携基盤（仮称）公共サービス連携基盤（仮称）公共サービス連携基盤（仮称）

SOAP

業務プロセス

管理機能ディレクトリ

機能アクセス制御

機能

ログ管理機能

⼀時情報保管機能

レジストリ機能

業務プロセス

管理機能ディレクトリ

機能アクセス制御

機能業務

プロセス管理機能

ディレクトリ機能

アクセス制御機能

ログ管理機能

⼀時情報保管機能

レジストリ機能

ログ管理機能

⼀時情報保管機能

レジストリ機能

サービスバス

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

統合ＤＢ機能

ＰＦ通信機能

ＰＦ共通機能

モニタリング認証・認可

････

サービス基盤

監査証跡

長澤 太郎 ｷV

届出

長澤 太郎 ｷV

届出

長澤 太郎 ｷV

届出

長澤 太郎 ｷV

届出

長澤 太郎 ｷV

届出

長澤 太郎 ｷV

届出

長澤 太郎 ｷV

届出

長澤 太郎 ｷV

届出

統合レジストリ

自治体業務ユニット

････

ＢＰＭ機能

住民基本台帳

個人住民税

国民健康保険

外部連携ユニット処理要求＋申請データ

処理結果＋結果データ

PFPF通信機能に準拠通信機能に準拠したプロトコルしたプロトコル

各機関からの処理結各機関からの処理結果の⼀時的な保管果の⼀時的な保管

図 I-32 地域情報プラットフォームに準拠したシステムとの連携

(c) SOAシステムとの連携

SOAシステムとの連携の場合、SOAシステム側では外部連携サービスとして各種サービ

スがSOA準拠の標準仕様によって公開され、「公共サービス連携基盤（仮称）」の業務プロ

セス機能から呼び出される連携方式となる。SOAに準拠している先進的な接続機関とのシ

ステム連携は、半自動的な（極力人手を排除した）連携が可能となり、より業務効率化に効

果を発揮すると考えられる。

なお、SOAに準拠している場合には、バックオフィス連携用データストアは必ずしも必要

ではないが、各機関の保有するデータの標準化の状況に応じて、標準変換アダプタが必要

であり、また、ID変換用のディレクトリデータについても必要になる。

SOAP/REST

サービスバス

外部接続機能

公共サービス連携基盤（仮称）公共サービス連携基盤（仮称）公共サービス連携基盤（仮称）公共サービス連携基盤（仮称）

業務プロセス

管理機能ディレクトリ

機能アクセス制御

機能

ログ管理機能

⼀時情報保管機能

レジストリ機能

業務プロセス

管理機能ディレクトリ

機能アクセス制御

機能業務

プロセス管理機能

ディレクトリ機能

アクセス制御機能

ログ管理機能

⼀時情報保管機能

レジストリ機能

ログ管理機能

⼀時情報保管機能

レジストリ機能

サービスバス

各機関保有DB

③③SOASOAシステムシステム③③SOASOAシステムシステム

サービス連携に必要な機能

基幹業務システム

処理要求＋申請データ

処理結果＋結果データ

連携⽤データの抽出

連携⽤データの登録複数の複数の標準的な標準的なプロトコルプロトコル

各機関からの処理結各機関からの処理結果の⼀時的な保管果の⼀時的な保管

・データの送受信・データの送受信・・IDID変換変換

住所変更申請サービス

納付状況照会サービス

ディレクトリディレクトリ（（IDID変換テーブル）変換テーブル）

バックオフィス連携⽤バックオフィス連携⽤データストアデータストア

（外部連携⽤（外部連携⽤DBDB））

外部連携外部連携サービスサービス

標準変換標準変換アダプタアダプタ

処理結果＋結果データ

・データスキーマ変換・データスキーマ変換・各種コード変換・各種コード変換・⽂字コード変換・⽂字コード変換

図 I-33 SOAシステムとの連携

I .標準モデル構築に向けた技術的方策を中心として ５．「公共サービス連携基盤（仮称）」を実現する技術要素

48

（５） 連携方式の同期レベル

各機関が保有するデータや「公共サービス連携基盤（仮称）」が管理する業務プロセス等

のトランザクションのパターンに応じて、 適な連携方式（リアルタイム性や同期性）を検討

する必要がある。データの一貫性を保ちつつデータの連携を行うためには、提供するサー

ビスのユースケースを分析し、各機関間や機能間のやり取りにおいて必要となる同期レベ

ルを検討する。

特に疎結合で各機関のデータを連携させるためには、本項で示す同期レベルに関する

検討が重要となる。例えば、「リアルタイム」の同期レベルの採用はデータの一意性などの

観点では優位であるが、トランザクションの窓口の負荷やネットワークの負荷が増大し、そ

れに伴いコストも増大する可能性がある。また、「非同期」の同期レベルの採用は、トランザ

クションの制御に求められるパフォーマンスやデータのやりとりの信頼性において非常に効

果が高いが、データの一貫性に関する配慮が必要となる。したがって、新業務要件の詳細

化に基づき、かつ費用対効果を踏まえ、 適な同期レベルを採用することが必要である。

今後、非機能要件の検討や物理設計の段階においては、同期レベルを重視し、連携の

仕組みを検討する必要があるため、表 I-2に連携時における同期レベルの例を整理して示

す。各機関間や機能間のやり取りを、これらの同期レベルのパターンに分類をすることで、

体系的に同期レベルを整理することができる。

表 I-2 連携方式の例

連携レベル 方式 概要 適用対象 留意点

ディスク共用 複数のシステム間で

ディスクを共用し、 デ

ータを共有する

リアルタイム性とデータの一意性

に対する要求が高く、大量データ

を処理する場合

・広帯域のネットワークが必要

・運用管理の責任分界点の整

理が必要

リアルタイム

ミドルウェア等

による連携（リ

アルタイム・オ

ンライン）

連携に必要な機能を

装備したパッケージソ

フトを活用し、リアルタ

イムの連携処理を実

現する

複数のシステム間を連携する必要

があり、リアルタイム性とデータの

一意性に対する要求が高く、大量

のトランザクションを実行する必要

がある場合

・高度な機能を利用する場合、

連携対象システム間でミドルウ

ェア等の統一が必要

・製品によっては、連携用アダ

プタの個別開発が必要

アプリケーショ

ン 開 発 に よ る

連携

連携に必要な機能を

個別に開発し、リアル

タイムや非同期の連

携処理を実現する

特定のシステム間を連携する必要

があり、リアルタイム性とデータの

一意性がある程度求められ、大量

のトランザクションを実行する必要

がある場合

・各システム毎に開発が必要

・運用上も個別の対応が必要

リアルタイム／非

同期

Ｗｅｂサービス

連携

Ｗｅｂサービスを活用

し、疎結合によるリア

ルタイムや非同期の

連携処理を実現する

複数のシステム間を連携する必要

があり、リアルタイム性とデータの

一意性がある程度求められ、多様

なトランザクションを実行する必要

・標準化が不十分であり、動向

に留意が必要

・標準化された機能だけで不十

分な場合、独自の開発が必要

I .標準モデル構築に向けた技術的方策を中心として ５．「公共サービス連携基盤（仮称）」を実現する技術要素

49

がある場合

ミドルウェア等

による連携（デ

ィレイド・オンラ

イン）

メッセージキューイン

グ24等の技術を活用

し、非同期の連携処

理を実現する

複数のシステム間を連携する必要

があり、リアルタイム性は求められ

ず、ヒューマンタスクなどを介する

ことが考えられリアルタイムでの

情報共有が難しい場合

・連携の双方に導入が必要 非同期

ファイル転送・

バッチ連携

ＦＴＰ等を用いて、ファ

イル等によるデータ交

換を実現する

複数のシステム間を連携する必要

があり、リアルタイム性は求められ

ず、ヒューマンタスクなどを介する

ことが考えられリアルタイムでの

情報共有が難しい場合

・データのフォーマットや一時保

管場所など運用等のルールの

取り決めが必要

オフライン

媒体授受 記憶媒体の手渡しや

郵送にてデータ交換

を実現する

・媒体のフォーマットや暗号化、

タイミング等の運用ルールの取

り決めが必要

（６） 次世代電子行政サービス基盤におけるセキュリティの考え方

「公共サービス連携基盤（仮称）」を運用するに当たっては、国民ならびに接続機関、双

方のセキュリティに対する不安を取り除くための考慮が必要である。特に、バックオフィス間

でデータを連携する際は、各機関の情報の取扱いに関する合意や、合意した事項の確実

な実施を実現するための、第三者機関等による監視の仕組みが必要である。

業務プロセス

サービスレジストリ ログ

第三者機関による第三者機関による不正利⽤監視不正利⽤監視

第三者機関による第三者機関による不正利⽤監視不正利⽤監視

照合照合

公共サービス連携基盤公共サービス連携基盤（仮称）（仮称）公共サービス連携基盤公共サービス連携基盤（仮称）（仮称）ポータル（国⺠）ポータル（国⺠）ポータル（国⺠）ポータル（国⺠） ポータル（⾏政）ポータル（⾏政）ポータル（⾏政）ポータル（⾏政）

接続機関接続機関接続機関接続機関

オンラインオンライン認証認証 職員職員

認証認証

プライベートネットワーク

接続機関接続機関接続機関接続機関

職員

職員

国⺠

アプリケーション（サービス）

アプリケーション（サービス）

図 I-34 「公共サービス連携基盤（仮称）」におけるセキュリティ

「公共サービス連携基盤（仮称）」は、扱う情報の機微さに応じて、セキュリティの高い環

境（例えばプライベートネットワーク）に構築されることが望ましく、そこにアクセスする利用

者や接続機関とのやり取りをいかにセキュアに保つかについて十分な検討が必要である。

なお、セキュリティを担保する仕組みには、技術的要素と制度的要素が関連するが、本項

においては技術的要素を中心に示している。表 I-1に、検討すべきセキュリティ要件につい

24 メッセージキューイングとは、送信側のソフトは相手の都合に依存することなく、キューと呼ばれる領域にデータを格納するだけで、確実にメッセージを送り届けることができる技術。

一時的に接続が途絶えるような状況が想定される場合でも、アプリケーション側では特に対策を行なわなくても確実に相手にメッセージが届く。

I .標準モデル構築に向けた技術的方策を中心として ５．「公共サービス連携基盤（仮称）」を実現する技術要素

50

て整理する。

表 I-1 「公共サービス連携基盤（仮称）」におけるセキュリティ要件

今後、詳細なセキュリティ設計を実施するに当たっては、利用者からの情報の不正利用

に関する審査要望等に対応できる仕組み等も含め、第三者機関の役割についても具体的

な検討が必要となる。

（７） ディレクトリの考え方

各機関の固有のデータベースと連携するために、「公共サービス連携基盤（仮称）」にお

ける本人データを特定できるＩＤの管理および関連付けの方法を検討する必要がある。

行政情報を保有する機関以外が他機関のIDを把握できないことでセキュリティ向上が期

待できること、また、各機関にて保有するIDを統一的なIDに変更することは接続機関のシス

テム改修のために相応のコストがかかること等の理由により、各機関の保有するＩＤは各機

関ごとに管理されることが望ましい。そのため、「公共サービス連携基盤（仮称）」は、利用

者の用いるポータルにログインするためのＩＤと各機関との連携用に発行するＩＤの関連付

け情報のみを管理する方針とする。図 I-35に検討の一案を示す。

機能 脅威 検討すべきセキュリティの仕組み

ネットワーク 盗聴 ・暗号化通信

・プライベートネットワークにおける物理セキュリティ

ポータルと「公共

サービス連携基盤

（仮称）」間 認証 なりすまし、

不正アクセス

・ポータルの認証を信頼（ポータルの認証では、利用者認証

だけでなく、サイト認証やアプリケーションの認証も検討が必要）

ディレクトリ

（ＩＤ管理）

ＩＤの漏洩、

なりすまし、

不正アクセス

・ログインIDと連携用ID（連携のみに用いられるID）の関連付

けデータの暗号化

・クレデンシャル（パスワード・証明書等）の有効期限、定期的

な変更、失効を管理する機能

一時情報管理 職員の不正利用 ・職員に対する制限、教育、ペナルティ、アクセス履歴等

・業務プロセスに定義されたフローに沿ってのみの利用

「公共サービス連

携基盤（仮称）」

ログ管理 ・ログによる点検・ログの改ざん防止

盗聴 ・暗号化通信

・プライベートネットワークにおける物理セキュリティ（既存の

仕組みである霞が関ＷＡＮ、ＬＧＷＡＮの活用等も検討する）

「公共サービス連

携基盤（仮称）」と接

続機関間

ネットワーク

なりすまし、

送信先間違い

・連携に関する契約の締結、ルールの規定

・接続機関の認証の仕組みを検討

ＩＤの漏洩、

なりすまし、

不正アクセス

・データの暗号化

・パスワードの定期的な変更を要求する機能

・サービスレジストリに事前に登録されたサービスのみとの連

携

接続機関内 バックオフィス連携

職員の不正使用 ・職員に対する制限、教育、ペナルティ、アクセス履歴等

・業務プロセスに定義されたフローに沿ってのみの利用

I .標準モデル構築に向けた技術的方策を中心として ５．「公共サービス連携基盤（仮称）」を実現する技術要素

51

AA機関機関

ディレクトリディレクトリ

BB機関機関

ディレクトリディレクトリ

ディレクトリディレクトリ

BB機関機関AA機関機関

DEFDEFABCABC

連携⽤連携⽤IDID

XXXXXXログインログインIDID

BB機関機関AA機関機関

DEFDEFABCABC

連携⽤連携⽤IDID

XXXXXXログインログインIDID

DEFDEF

連携⽤連携⽤IDID

456456

機関機関IDID

DEFDEF

連携⽤連携⽤IDID

456456

機関機関IDID

ABCABC＋基本＋基本44情報によって情報によって処理要求処理要求

ABCABCとは誰かをとは誰かを名寄せする名寄せする

暗号化保管暗号化保管

公共サービス連携基盤では、内部的にログイン公共サービス連携基盤では、内部的にログインIDIDとと各機関との連携⽤各機関との連携⽤IDIDを作成するを作成する

機関機関IDID変更・削除変更・削除利⽤者利⽤者

職員職員

ABCABCにて処理結果返答にて処理結果返答（以降、連携⽤（以降、連携⽤IDIDでやりとり）でやりとり）

ABCABC

連携⽤連携⽤IDID

123123

機関機関IDID

ABCABC

連携⽤連携⽤IDID

123123

機関機関IDID

削除された情報が削除された情報が双⽅でやり取りされる双⽅でやり取りされる

ログインログインIDIDである「である「XXXXXX」が変更（削除）された場合には」が変更（削除）された場合には「「DEFDEF」が変更（削除）された情報が」が変更（削除）された情報がBB機関に渡され、機関に渡され、BB機関において「機関において「456456」が変更（削除）された場合には」が変更（削除）された場合には「公共サービス連携基盤（仮称）」に「公共サービス連携基盤（仮称）」に「「DEFDEF」が変更（削除）された情報が渡される」が変更（削除）された情報が渡される

ログインログインIDIDの登録の登録

ログインログインIDIDの変更（削除）の変更（削除）

公共サービス連携基盤（仮称）公共サービス連携基盤（仮称）公共サービス連携基盤（仮称）公共サービス連携基盤（仮称）

①初回連携時①初回連携時①初回連携時

②変更・削除があった場合②変更・削除があった場合②変更・削除があった場合

図 I-35 バックオフィス連携とＩＤ管理

（ア） 「公共サービス連携基盤（仮称）」のディレクトリ機能

利用者がポータルにアクセスするためのIDは、「公共サービス連携基盤（仮称）」のディレ

クトリ機能で管理する。

「公共サービス連携基盤（仮称）」のディレクトリ機能は、ログインIDに対応した機関ごとの

連携用IDを発行し、管理する。（図I-35の例においては、A機関用にABC、B機関用にDEFと

いう連携用IDを発行している。）

「公共サービス連携基盤（仮称）」のディレクトリ機能に保有される利用者のログインIDと

各機関IDとの関連付け情報は暗号化して保管する等の対策を採り、漏洩へのリスクを考慮

した堅牢なセキュリティにて管理する。

（イ） 各機関における管理

ここで各機関が保有するデータベースの本人識別キーを「機関ID」と呼称する（図I-35の

例においては、A機関では123、B機関では456という機関IDが用いられている。）と、セキュ

リティの観点から機関IDは他の機関に知られないようにすることが望ましいので、連携用ID

と機関IDの関連付け情報は各機関が管理する方針とする。そうした場合に、ID連携を可能

とするためには、例えば、連携IDの発行時には、連携用ＩＤ（図中ABC）＋基本４情報（住所、

氏名、生年月日、性別）を用いて名寄せを行い、以降は連携用ID（図中ABC）によって「公

共サービス連携基盤（仮称）」との連携を行うことが考えられる。また、ログインID（図中

XXX）や各機関のID（図中456）に変更や削除があった場合には、それぞれの変更や削除

の情報をやり取りし、情報の整合性を確保する等の考慮が必要となる。

なお、地域情報プラットフォームにおいては、「プライバシー保護型認証連携技術」などの

I .標準モデル構築に向けた技術的方策を中心として ５．「公共サービス連携基盤（仮称）」を実現する技術要素

52

認証・認可・セキュリティの仕様が検討されており、これらも参考としつつ検討を行う。

（８） 各機関の保有するデータの文字コードに関する検討

「公共サービス連携基盤（仮称）」が接続機関とデータ連携を行う際には、文字コードに関

する検討が必要になる。一般に、情報を保有している機関がシステムで扱う文字コード体

系は複数（JIS X 0213、Unicode等）存在するため、データの連携先ごとに変換が必要な仕

組みとしてしまうと、煩雑な変換作業が発生してしまう。そのため、機関間におけるデータ連

携の際には、統一された文字コードでデータを交換できるようにする必要がある。加えて、

情報を保有している機関はそれぞれ独自に作成した外字を保有しており、同じ字体の外字

でも機関ごとに異なる文字コードで管理されている。そこで、外字を体系的に共有できる環

境を構築し、データ連携の際には共有化された識別子（文字図形番号等）によりデータ交

換することが求められる。なお、外字を内字として取り扱うための環境整備には相当の時

間やコスト等が必要となるため、まずは連携することを優先した過渡的な措置として解決の

一案を示す。将来において外字の内字化が進めば、その活用を前提とした形態に移行す

ることを再度検討する必要がある。

F040F040F041F041

フォントフォント ⽂字コード⽂字コード

F040F040F041F041

フォントフォント ⽂字コード⽂字コード

513280 513280 444580444580

フォントフォント ⽂字図形番号⽂字図形番号

513280 513280 444580444580

フォントフォント ⽂字図形番号⽂字図形番号

E002E002E005E005

フォントフォント ⽂字コード⽂字コード

E002E002E005E005

フォントフォント ⽂字コード⽂字コード

444580444580

513280513280⽂字図形番号⽂字図形番号

F041F041

F040F040⽂字コード⽂字コード⽂字フォント⽂字フォント

444580444580

513280513280⽂字図形番号⽂字図形番号

F041F041

F040F040⽂字コード⽂字コード⽂字フォント⽂字フォント

検索・取得検索・取得

作成作成

444580444580

513280513280⽂字図形番号⽂字図形番号

E005E005

E002E002⽂字コード⽂字コード⽂字フォント⽂字フォント

444580444580

513280513280⽂字図形番号⽂字図形番号

E005E005

E002E002⽂字コード⽂字コード⽂字フォント⽂字フォント

検索・取得検索・取得

作成作成

変換テーブル変換テーブル 変換テーブル変換テーブル

機関A機関機関AA 公共サービス連携基盤（仮称）公共サービス連携基盤（仮称）公共サービス連携基盤（仮称） 機関B機関機関BB

バックオフィスシステムバックオフィスシステム バックオフィスシステムバックオフィスシステム⽂字情報データベース⽂字情報データベース（全体データライブラリ）（全体データライブラリ）

統⼀された⽂字コードで対応統⼀された⽂字コードで対応（内字）（内字）

513280513280（（ ））444580444580（（ ））

変換変換 変換変換

変換変換変換変換

図 I-36 文字コードの問題の解決案

「公共サービス連携基盤（仮称）」の中では、統一された文字コードで外字を扱えるように

するために、文字図形番号を用いる。また、文字の重複の排除や対象とする文字の範囲な

ど、標準とする文字に関する基本的なルールを整理した上で、文字情報データベースを用

意する。

各機関では、外字変換テーブルを用意する。外字変換テーブルには、その機関が保有

する外字の文字コードと文字図形番号の対応を管理する。

データ流通時に外字を含む場合は、各機関で外字の文字コードを文字図形番号に変換

し、データを受け取った機関は自機関の文字コードに変換する。これにより、各機関がバッ

I .標準モデル構築に向けた技術的方策を中心として ５．「公共サービス連携基盤（仮称）」を実現する技術要素

53

クオフィスで保有しているデータの文字コードをそのまま利用しつつ、データ連携を行うこと

が可能となる。

５．２ データ標準化等の検討

（１） データ標準化に関する現状

行政事務は紙を前提とした業務の 適化や単独の組織内での 適化などが図られてお

り、基本的に個々の行政機関単位で局所的に 適化されていることから、複数の行政機関

間のつながりを意識したデータ構造となっていない。よって、現状のままでは各機関間のデ

ータ連携を行うことは難しく、個人・企業が複数の行政機関で申請等の手続を行う際に、そ

れぞれの行政機関の窓口に出向き、同じデータ（氏名や住所、電話番号等の情報）を違う

形式で何度も記入しなければならないといった非効率な作業が発生している。

また、データ活用における課題として、個人・企業が行政の保有している情報を入手しよ

うとした場合、多様なシステムがそれぞれの目的でデータを蓄積しており、保有するデータ

の内容が利用者に対して開示されていないため、利用者は、必要なデータを入手しようとし

た場合、その所在が分からず、必要なデータの入手に多大な労力を要することがある。ま

た、入手できたとしても、そのデータの仕様がそれぞれの機関によって独自のもので提供さ

れるため、データの活用が困難な場合がある。

このような状況から、データを標準的な仕様に準拠させていくことによって、効率的で広

範囲なデータ連携やデータのさらなる有効活用を実現することができる。

業務システム

⾏政情報

≠ データ仕様がシステムごとに異なる

？

どのようなデータがあるか分からない

データの所在が分からない

データの取得⽅法が分からない

データの仕様が分からない

すべてのデータを⼀元管理するのは困難 ？ 業務システム

⾏政情報

申請

A機関

B機関

C機関

D機関

E機関

国民・企業

証明書請求

交付

申請

申請

申請

入力 入力

入力

入力

図 I-37 データ標準化に関する現状

I .標準モデル構築に向けた技術的方策を中心として ５．「公共サービス連携基盤（仮称）」を実現する技術要素

54

我が国における行政機関や民間を含めたデータ標準化や情報公開に係る取組は、行政

の透明性の向上という世界的な潮流の中で、他国の政府における取組と比較すると、十分

とは言えない。例えば米国連邦政府の事例として、2009年5月末よりサービスが開始された

Data.gov25は、各機関から公開可能な情報をある程度標準化された特定のフォーマットで

Webサイト上に公開するというもので、政府のプロジェクトにかかっている実際の投資額、進

捗状況等がリアルタイムで閲覧でき、簡単な閲覧画面で分かりやすく、国民の税金がどこ

にどれくらい使われているかが一目で分かる仕組みとなっている。また、統計データを公開

することで、国民や企業がそのデータを表計算ソフトウェアで解析したり、様々なソフトウェ

アでマッシュアップして、解析などを行い、政府に直接フィードバック、提案をすることが可能

になっている。

以上のような点を踏まえ、データ標準化の方策は、目先の効果だけではなく、長期的な

視点で推進していく必要がある。

オバマ政権は国⺠に向けた「開かれた政府（open government）」を⽅針にオバマ政権は国⺠に向けたオバマ政権は国⺠に向けた「開かれた政府（「開かれた政府（open governmentopen government）」）」を⽅針にを⽅針に

http://http://www.data.govwww.data.gov//

情報公開情報公開情報公開 国⺠との対話国⺠との対話 国⺠とのコラボレーション国⺠とのコラボレーション 国⺠の意⾒を反映させる政策作り国⺠の意⾒を反映させる政策作り

RAWData（⽣データのカタログ）

図 I-38 米国政府のData.Gov 事例

（２） データ標準化における「公共サービス連携基盤（仮称）」の位置づけと機能

データ標準化を推進するに当たって、「公共サービス連携基盤（仮称）」は、データの標準

18 http://www.data.gov/

I .標準モデル構築に向けた技術的方策を中心として ５．「公共サービス連携基盤（仮称）」を実現する技術要素

55

仕様を管理・提供し、各機関の要望するデータの所在や標準仕様を開示する役目を担う。

（ア） データ標準化を推進する機能

「公共サービス連携基盤（仮称）」は、府省や自治体等の組織横断的なデータ連携を実

現するための 小限のデータ標準化だけでなく、各機関のデータを統合的に利用するため

の補助機能や、より広範囲でのデータの標準化を推進するための機能を提供する。図

I-39に示す機能について、概要を示す。

各機関（各府省、各⾃治体、⺠間企業等）各機関（各府省、各⾃治体、⺠間企業等）各機関（各府省、各⾃治体、⺠間企業等）各機関（各府省、各⾃治体、⺠間企業等）

抽出登録 固有

データベース

固有データベース

固有データベース

標準変換アダプタ

バックオフィス連携⽤データストア

バックオフィス連携⽤データストア 標準変換

アダプタ

標準変換アダプタ

外部連携サービス

公共サービス連携基盤（仮称）公共サービス連携基盤（仮称）公共サービス連携基盤（仮称）公共サービス連携基盤（仮称）

各機関（各府省、各⾃治体、⺠間企業等）各機関（各府省、各⾃治体、⺠間企業等）各機関（各府省、各⾃治体、⺠間企業等）各機関（各府省、各⾃治体、⺠間企業等）

抽出登録処理要求業務プロセス

管理機能 固有データベース

固有データベース

固有データベース

標準変換アダプタ

バックオフィス連携⽤データストア

バックオフィス連携⽤データストア

全体全体標準標準ライブラリライブラリ

個別個別標準標準ライブラリライブラリ

返答標準変換アダプタ

標準変換アダプタ

外部連携サービス

各機関の各機関の公開データに関する公開データに関する仕様や属性情報仕様や属性情報

外部接続機能

個別個別標準標準ライブラリライブラリ

収集収集

収集収集⽣成

⽂字コード⽂字コードデータデータ

変換変換ライブラリライブラリ

連携機関全体の連携機関全体の公開データに関する公開データに関する仕様や属性情報仕様や属性情報

登録登録

登録登録

活⽤活⽤活⽤活⽤コードコード

データデータ変換変換ライブラリライブラリ

スキーマスキーマ変換変換ライブラリライブラリ

変換テーブル等の変換テーブル等の雛型雛型

各種変換ライブラリ

図 I-39 データ標準化を推進する機能

全体標準ライブラリ

各機関において、公開可能な情報を定義する際に、データの仕様や属性情報等を個別

標準ライブラリに登録する。各機関の個別標準ライブラリに登録したデータの仕様や属性

情報等は、「公共サービス連携基盤（仮称）」の全体標準ライブラリに登録される。全体標準

ライブラリの中にはデータの用語や意味も管理されるため、辞書のような役割を持たせるこ

とができる。この情報を活用することにより、他機関が登録した用語とデータ形式、及び、そ

の関係を参照でき、新しく登録する用語、データ形式を事前に登録された情報と揃えること

により、公開データの範囲の拡大や、更に効率的なサービス連携のためのデータ標準化を

促進することができる。

各種変換ライブラリ

各機関は「公共サービス連携基盤（仮称）」を利用するために、各機関の固有データを標

準のデータ仕様に変換するための標準変換アダプタを用意する必要があるが、標準変換

アダプタの構築を容易にするために、「公共サービス連携基盤（仮称）」の側でスキーマ変

換ライブラリ、コード変換ライブラリ、文字コード変換ライブラリを提供する。

スキーマ変換ライブラリとは、データの表現形式（XMLスキーマ）の雛形の集合体であり、

コード変換ライブラリとはコードの表現形式（変換ロジックとテーブルの雛形）の集合体であ

I .標準モデル構築に向けた技術的方策を中心として ５．「公共サービス連携基盤（仮称）」を実現する技術要素

56

る。また、文字コード変換ライブラリとは、文字コードの表現形式（変換ロジックとテーブルの

雛形）の集合体である。

各機関は提供された各変換ライブラリを、標準仕様への変換ロジックの作成や変換テー

ブルの作成時のリファレンスとして活用することが可能となるため、標準変換アダプタの開

発に係るコストを 小限に抑えることができる。さらに、自身の保有する固有データに関し

ても必要に応じて標準仕様に準拠させるための取組を容易とすることで、より多くの機関を

またがった広範囲でのデータ標準化を徐々に推進させることが期待できる。

（３） 標準ライブラリの考え方

全体標準ライブラリ

個別標準ライブラリ

公共サービス連携基盤（仮称）

収集

職員

接続機関

・データの属性・データのスキーマ情報・コードの情報・⽂字コードの情報

配布・参照

⽣成

バックオフィス連携⽤データストア

バックオフィス連携⽤データストア

・公開データ

・データの属性・データのスキーマ・データの雛型・データの属性・データのスキーマ・データの雛型

・データの属性・データのスキーマ情報・コードの情報・⽂字コードの情報

収集収集

登録

登録

⽂字コード⽂字コードデータデータ

変換変換ライブラリライブラリ

コードコードデータデータ

変換変換ライブラリライブラリスキーマスキーマ

変換変換ライブラリライブラリ

図 I-40 標準ライブラリの仕組みと活用

（ア） 標準ライブラリの実現イメージ

標準ライブラリとは、より広範囲でのデータ標準化を推進することを目的として、各機関

の持つ個別のデータの構造を情報として集約し、それをデータ標準のマスターとしてある統

一的なルールに基づき標準化しながら改善を加え、さらに各機関にデータ標準の情報をフ

ィードバックすることで、各機関のボトムアップでのデータ標準化を推進する考え方である。

全体標準ライブラリの主な機能は、データ仕様の登録、管理、検索、類似データの仕様

の比較、仕様利用状況の登録などがあり、要素間のマッピングや要素ごとの仕様情報を管

理する。

個別標準ライブラリへの登録時においては、データ仕様のチェック機能の在り方、各機関

の既存のデータベースからデータ管理情報を自動抽出する仕組み、さらには標準変換アダ

プタでのデータマッピング結果のアップロードの機能の仕様等について検討が必要である。

また、標準ライブラリを運用する際の運用ルールを確立する必要がある。例えば、各機関

が新規に標準ライブラリに要素を登録する際には、既に登録されている要素を参照し、同

I .標準モデル構築に向けた技術的方策を中心として ５．「公共サービス連携基盤（仮称）」を実現する技術要素

57

一の項目が存在する場合には、その利用を義務付けるなど、効率よく標準化を推進するた

めの仕組みや運用等を検討していく必要がある。

（４） 標準変換アダプタの考え方

各接続機関（各府省、各自治体）では、既に基幹業務システムを始め、各種情報システ

ムなど、それぞれ個別に 適化されたデータベースシステムを構築して、管理している。各

システムのハードウェアの構成は汎用機からPCなど多様であるとともに、データベースの

仕様（DBMS26やデータベースの構造、コード等）もそれぞれ異なる。

データ連携を実現するためには、各システムが「公共サービス連携基盤（仮称）」内で使

用・提供される標準仕様のデータに対応することが必要であるが、全てのシステムを個別

に改修を行うことは、多大な時間とコストが必要となり、現実的に難しい。そこで、保有デー

タを標準仕様に準じた形式（標準XMLデータスキーマ、標準コード、標準文字コード形式）に

変換するツールをアダプタとして開発し、外部と連携する必要性の高いデータや特定の範

囲でのデータ連携を、短期間で実現することが現実的である。

（ア） 標準変換アダプタの実現イメージ

標準変換アダプタとは、既存の各システムで管理・保持されるデータを「公共サービス連

携基盤（仮称）」の標準仕様に準じた形式に変換するために必要となる、データ変換ツール

（コンバータ）である。アダプタを適用することで、既存の各システムの機能及び運用を変え

ることなく、標準仕様に準じた形式でのデータ連携が可能になる。

標準変換アダプタは、各機関の既存のデータベース仕様と標準仕様との関連を一定の

ルールで記述する定義ファイル（変換テーブル）を作成し、この定義ファイルを基に、各機関

のシステムに対応する変換機能を実現する。この汎用的な標準変換アダプタと、「公共サ

ービス連携基盤（仮称）」から提供されるスキーマ変換ライブラリ、コード変換ライブラリ、文

字コード変換ライブラリ（定義ファイルの雛形）を活用することにより、各機関における開発

コストが削減可能となる。

26 DBMS(DataBase Management System)とは、共有データとしてのデータベースを管理し、データに対するアクセス要求に応えるソフトウェアを指す。一般にデータの管理を専門のソ

フトウェアに任せることは、アプリケーションソフトの生産性や性能、資源の利用効率の向上につながる。管理するデータの表現形式(データモデル)によりいくつかの種類に分類でき、

代表的なものにはカード型、リレーショナル型、オブジェクト型などがある。

I .標準モデル構築に向けた技術的方策を中心として ５．「公共サービス連携基盤（仮称）」を実現する技術要素

58

標準変換アダプタ

標準変換アダプタ

固有データベース

固有データベース

固有データベース

バックオフィス連携⽤データストア

標準変換アダプタ

変換テーブル

変換テーブル

変換テーブルインポート

標準仕様データ

・・・

・・・

・・・

それぞれが独⾃の仕様でデータを整備し利⽤している。

標準仕様に変換されたデータを集約し、随時更新していくことで、外部とのデータ連携を可能とする。

各システムの機能および運⽤を変えることなく、各システムに対応する標準変換アダプタを介することで標準仕様のデータを作成する。（アダプタそのものも全システムに共通の機能を持つツール＝汎⽤アダプタとして開発し、変換ルールを定義したファイルにより各システムへ適合させるという⽅法も考えられる。）

独⾃仕様データ

図 I-41 標準変換アダプタのイメージ

汎用的な標準変換アダプタは、接続機関システムで管理・運用されている独自仕様デー

タのうち、リレーショナルデータベースのテーブルや表計算ワークシートファイル、CSV等の

テキストファイルなど一定の構造化がなされており、かつ利用頻度の高いデータ形式を調

査し、優先的に対応することが考えられる。

変換テーブルでは、独自仕様データの各項目と全体標準ライブラリに登録されている標

準仕様のスキーマライブラリ（XMLスキーマを想定）のデータ項目との対応関係を定義する。

I .標準モデル構築に向けた技術的方策を中心として ５．「公共サービス連携基盤（仮称）」を実現する技術要素

59

⽇単位

和暦

市区町村名

都道府県名

●00所得●0000年単位（¥）Income

平成X年×⽉×⽇

⽣年⽉⽇200XXXXX⻄暦Birthday

○○市BBB市コード

□□県住所AAA県コードAddress

独⾃データ標準データ

⽇単位

和暦

市区町村名

都道府県名

●00所得●0000年単位（¥）Income

平成X年×⽉×⽇

⽣年⽉⽇200XXXXX⻄暦Birthday

○○市BBB市コード

□□県住所AAA県コードAddress

独⾃データ標準データ

⽇単位所得

和暦⽣年⽉⽇

電話番号

郵便番号

市町村名

都道府県名住所

⽇単位所得

和暦⽣年⽉⽇

電話番号

郵便番号

市町村名

都道府県名住所

連係メッセージ標準仕様

<?xml version=“1.0”><xsd:schema …>

<xsd:annotation><xsd:documentation/>

</xsd:annotation>・・・</xsd:schema>

○○XMLXMLスキーマスキーマ

<xml>・・・

<id>2<id><address>

東京都△△区・・・</address>

・・・</xml>

<xml>・・・

<id>2<id><address>

千葉県○□市・・・</address>

・・・</xml>

<xml>・・・

<id>2<id><address>

東京都△△区・・・</address>

・・・</xml>

<xml>・・・

<id>2<id><address>

千葉県○□市・・・</address>

・・・</xml>

汎⽤的な標準変換アダプタ

汎⽤的な汎⽤的な標準変換標準変換アダプタアダプタ

各機関のシステムで特に利⽤頻度の⾼各機関のシステムで特に利⽤頻度の⾼い、データ形式やプロトコルを、変換定義い、データ形式やプロトコルを、変換定義に基づき標準仕様のに基づき標準仕様のXMLXMLスキーマとマッピスキーマとマッピングし、標準仕様データとして変換・出⼒ングし、標準仕様データとして変換・出⼒する汎⽤処理機能を実装。オープンなする汎⽤処理機能を実装。オープンなAPIAPIを装備し、拡張可能なものとする。を装備し、拡張可能なものとする。

標準仕様データと、標準仕様データと、独⾃仕様データの項⽬の対応や、独⾃仕様データの項⽬の対応や、接続機関システムのプロトコルや接続機関システムのプロトコルや

データ形式などの接続情報を定義。データ形式などの接続情報を定義。

（標準変換アダプターのパラメータになる）（標準変換アダプターのパラメータになる）

接続機関システム（RDBテーブル）

TableA

接続機関システム（CSVデータ）

Master.csv

年単位収⼊

和暦誕⽣⽇

電話番号

市コード

県コードじゅうしょ

年単位収⼊

和暦誕⽣⽇

電話番号

市コード

県コードじゅうしょ

⼊⼒

⼊⼒

⽣成⽣成マッチングマッチング

県コード市コード

Address

⻄暦Birthday

Income年単位（¥）

県コード市コード

Address

⻄暦Birthday

Income年単位（¥）

データ連携

データ連携

○○⽂字コード変換⽂字コード変換雛形雛形

○○コード変換コード変換雛形雛形

9D0E鴎9DD7鷗

独⾃コード標準コード⽂字

9D0E鴎9DD7鷗

独⾃コード標準コード⽂字

4000秋⽥3000岩⼿2000⻘森1000北海道

独⾃コード標準コード都道府県

4000秋⽥3000岩⼿2000⻘森1000北海道

独⾃コード標準コード都道府県

○○XMLXMLスキーマスキーマ変換テーブル変換テーブル

○⽂字コード変換テーブル○⽂字コード変換テーブル○コード変換テーブル○コード変換テーブル

F00B9D0E鴎F00A9DD7鷗

独⾃コード標準コード⽂字

F00B9D0E鴎F00A9DD7鷗

独⾃コード標準コード⽂字

d0014000秋⽥c0013000岩⼿b0012000⻘森a0011000北海道

独⾃コード標準コード都道府県

d0014000秋⽥c0013000岩⼿b0012000⻘森a0011000北海道

独⾃コード標準コード都道府県

全体標準ライブラリ全体標準ライブラリ 変換テーブル変換テーブル

各機関の独⾃仕様データ各機関の独⾃仕様データ

標準仕様データ標準仕様データ

図 I-42 汎用的な標準変換アダプタのイメージ

（５） データの連携粒度と段階的ステップ

データの連携の粒度（データ連携の単位）として、次の２種類を想定している。

ファイル単位：共通利用できる行政文書の単位などを想定しており、電子化され

た添付書類などが相当する。連携される機関側で準備可能なデータの単位。

データセット単位：共通利用できる行政情報であり、ある定められた様式の中の

１項目（例えば、名前や住所）、または、住民情報などのセット項目のデータを想

定する。「公共サービス連携基盤（仮称）」からの要求に応じた単位でのデータの

固まり。

（ア） データ連携実現の段階的ステップの必要性

システム間のデータ連携では、連携させるデータ粒度によって、連携を実現させる具体

的な方策が異なる。

将来的に利用者にバックオフィスでの基幹システム相互のデータ連携を意識させずに利

用者が必要とするデータ・サービスを実現させるためには、データセット単位での連携が必

要である。しかし、標準仕様を定めてデータセット単位での連携を実現するためには多くの

ルール作りとその徹底、既存データの変換処理等が必要となり、当初からデータセット単位

の連携を前提とした方策とすることは現実的ではない。

I .標準モデル構築に向けた技術的方策を中心として ５．「公共サービス連携基盤（仮称）」を実現する技術要素

60

そこで、当初は第1ステップとしてファイル単位での連携を実現させることとし、将来的に

第2ステップとしてデータセット単位でのデータ連携の実現を目指す方針とする。

ファイル単位での連携は、各々の行政機関が保有するデータを、その機関が提供してい

る形式をそのままの形で提供するものであり、添付書類等、何らかの固まりでのデータによ

る受け渡しを示している。これまでにも示しているように、添付書類等を機関間で電子的に

やり取り可能とすることで、利用者は手続に係る添付書類の取得や、各機関に複数回往復

する時間や手間を省くことができ、行政機関の側では、電子的な情報により処理することに

より、入力作業の手間が省けるなど業務効率の向上や、入力ミスがなくなるなど処理の正

確性の向上が期待できる。

将来的なデータセット単位での連携を実現すると、よりきめ細かいデータ連携が可能とな

り、添付書類のような固定的なデータの単位を前提としたサービスから、利用用途をさらに

拡大したサービスの提供が可能となる。例えば、バックオフィス連携用データストアを蓄積さ

れた情報を統合的にDWH(Data Ware House)27として利用することで、OLAP28やデータマイ

ニング29が可能となり、１つ１つのデータでは見えない相関性が浮き彫りとなり、例えば我が

国における政策立案等、意思決定を行うための材料として活用することができる。また、河

川や道路などに関する行政機関の持つ情報と、電力やガス、鉄道やバスなどに関する公

共企業が持つ情報等を総合的に扱い、被災者やその支援者に提供する新たなサービスの

創出等が可能になる。

27 DWH(Data WareHouse)とは、時系列に蓄積された大量の業務データの中から、各項目間の関連性を分析するシステム。

28 OLAP (On-line Analytical Processing)とは、蓄積したデータベースを多次元的に解析し、視覚化するシステム。データウェアハウスなどを使って集められた大量の元データを多次

元データベースに格納し、これを様々な角度から検索・集計して問題点や解決策を発見する。例えば、顧客の購入履歴を解析し、売上を地域別や製品別、月別など様々な次元から

瞬時に分析することができる。

29データマイニングとは、小売店の販売データや電話の通話履歴、クレジットカードの利用履歴など、企業に大量に蓄積されるデータを解析し、その中に潜む項目間の相関関係やパ

ターンなどを探し出す技術。従来は、こうした取引の「生データ」は、経理処理に必要なだけで活用されていなかったが、情報技術の向上により、潜在的な顧客ニーズが眠る「鉱山」と

して「採掘(mining)」されるようになった。

I .標準モデル構築に向けた技術的方策を中心として ５．「公共サービス連携基盤（仮称）」を実現する技術要素

61

公共サービス連携基盤（仮称）

第1ステップ：ファイル単位の連携①処理要求

接続機関

業務プロセス管理機能

基幹システム

②添付書類等のファイル

第2ステップ：データセット単位での連携

当初はワンストップサービスの実現を意識したファイル単位のデータ連携の実現を⽬指す。当初はワンストップサービスの実現を意識したファイル単位のデータ連携の実現を⽬指す。

将来的にはよりきめ細かいデータ連携を実現するためにデータセットレベルでのバックオフィス連携を⽬指す。将来的にはよりきめ細かいデータ連携を実現するためにデータセットレベルでのバックオフィス連携を⽬指す。

③処理結果

公共サービス連携基盤（仮称）①処理要求

接続機関

業務プロセス管理機能

基幹システム

②連携⽤データベースの参照

③処理結果

外部連携サービス

バックオフィス連携⽤データストア

バックオフィス連携⽤データストア

バックオフィス連携⽤データストア

バックオフィス連携⽤データストア

外部連携サービス

・・・・・・・・

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

図 I-43 データの連携粒度について

（イ） 段階的ステップに応じてバックオフィス連携用データストアに格納されるデータ

図 I-43に示す「バックオフィス連携用データストア」は、各々の機関が保有する情報のう

ち、公開可能なものを格納し外部からのアクセスを可能とするものである。各々の機関が

持つ基幹システムに外部の利用者が直接アクセスすることは、セキュリティ面での不安に

つながるため、こういった形で外部公開のためのデータベースを基幹システムの外に設け

ることが望ましい。

第1ステップでは、「公共サービス連携基盤（仮称）」からの要求に応じて、既存システム

に登録されているデータの中から添付書類等の各々の機関が作成しているファイル単位の

情報をバックオフィス連携用データストアに登録し、それをやり取りできる環境の実現を目

指す。

将来的なデータセット単位での連携では、バックオフィス連携用データストアにデータセッ

ト単位のデータを格納し、利用者からの処理要求に対して外部連携サービスが必要な判断

を行い、要求に合致した情報をバックオフィス連携用データストアから入手し、必要な加工

を施して処理結果を戻すサービスまでの実現を目指す。

ただし、ここでバックオフィス連携用データストアは物理的に必要なものではなく、セキュ

リティ面や利用者の利便性を考慮した基幹データベースとの論理的な分離であって、必ず

しも物理的な分離を意味するものではないことに留意する必要がある。物理的に分離する

I .標準モデル構築に向けた技術的方策を中心として ５．「公共サービス連携基盤（仮称）」を実現する技術要素

62

場合には、データの同期方法等についても留意する必要がある。

今後、第1ステップの実現のためには、ファイル単位で扱われている行政情報を整理する

ために、申請手続等においてファイル単位で各機関をまたがって共有化すべき行政情報の

洗い出しを行う必要がある。また、第2ステップの実現のためには、データセット単位での連

携に向けた行政情報のデータを分析する必要があり、バックオフィスの基幹システム相互

のデータ連携に必要となるデータ要素の洗い出しとその標準化（メタデータレベル）を行う必

要がある。

（６） 標準化ルールの概要

電子化された行政情報を円滑に利活用可能とするためには、システム的な仕組み以外

にデータ関連の標準化の取組が必要となる。

まず、ファイル単位での連携を実現させるためには、「行政情報作成ガイドライン」と「行

政情報カタログ」を整備する必要がある。「行政情報作成ガイドライン」とは、行政が保有す

る情報をXML形式で記述する際に情報共有を阻害しないよう 低限遵守すべきルールを

定めるもので、「行政情報カタログ」は、統一的に検索可能となる書誌的な情報を付与する

ためのルールを定めるものである。

また、データセット単位での連携を実現させるためには、「全体標準ライブラリ」に個別の

システム間で用いられている異なる用語の関係を整備し、登録することが必要になる。この

辞書の開発により、他機関の作成した公開データの情報を参照し、双方のシステムが理解

することが可能となる。また、データを構造的に整備していくために用いる雛形であるDRM

（データ参照モデル）を整備し、それらを全体標準ライブラリに登録していくことが必要であ

る。

表I-3 データ連携に向けて必要となる標準化ルール

整備項目 必要性 概要 参考とすべき標準事例

行政情報作成ガイドライ

ン

XML化された行政文書は自

由に作成可能であるが、一

定の統一化を図っておかな

いと、情報共有する上での

障害となる

タグの命名規則やスキーマ作成にお

ける 低限遵守すべきルールを定め

た規則。個別標準ライブラリ、全体標

準ライブラリの登録・利用に関するガ

イドラインも含まれる。

・ 米 国 連 邦 政 府 の NDR （ Naming &

Design Rules）30

行政情報カタログ 公開情報のデータセットを統

一的に検索可能とすること

が必要

書 誌 情 報 的 な メ タ デ ー タ を 定 め る

（Dublin Coreに準拠するなど検討）

・英国政府のIAR（ Information Asset

Register）31

・米国政府のData.gov

30 Federal XML Naming and Design Rules 9 June 2005 Draft.doc http://xml.coverpages.org/Federal-NDR-20050609.pdf

31 Information Asset Register http://www.opsi.gov.uk/iar/index

I .標準モデル構築に向けた技術的方策を中心として ５．「公共サービス連携基盤（仮称）」を実現する技術要素

63

DRM 個々の機関でデータモデル

を作成する場合に、参照可

能なひな形を用意すること

で、モデル間連携やモデル

流用等を促進

標準的な行政情報に関するデータ参

照モデルで規定すべき事項を明示

・ 米 国 連 邦 政 府 の DRM2.0 （ Data

Reference Model）32

全体標準ライブラリ データ項目レベルの意味お

よび表記の統一を図ること

で、効率的な電子データ化

および電子データの相互運

用性を確保

既存の国際標準をベースに、今後我

が国の行政部門で使われるデータレ

ベルの用語を規定

・ ebXML(UN/CEFACT) の Core

Component Library33

（注5）

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

諸外国の政府においては、このような標準化ルールの整備も先行して進んでいる。

我が国では、自治体の業務データについては、既に「地域情報プラットフォーム標準仕様

書」にXMLによる業務データ定義のルール、自治体内のデータ標準・データ形式、コード、

データ項目の意味付けについての辞書が整備されている。今後、多様な機関が関係する

データ連携の実現に向け、これら辞書を拡張・強化し、表I-3に示すようなルール作りやル

ール管理、メンテナンスの枠組に関する整備を積極的に検討・推進していく必要がある。

（７） 標準化ルールの関連性

（ア） 標準化ルールの関連性

標準化を進めていく際には、対象とする範囲全体にルールを徹底するトップダウン的な

アプローチと、個々のシステム等における改善を促して将来的な標準化につなげていくボト

ムアップ的なアプローチがあり、その双方のアプローチを適宜使い分けていくことが、確実

な標準化の推進においては必要である。

初期段階では、トップダウン的アプローチにより、「行政情報作成ガイドライン」と「行政情

報カタログ」を整備し、 低限のルールを徹底した上でデータ連携を行う。その後、将来的

なデータセット単位での連携を実現させていくために、「全体標準ライブラリ」、「DRM（Data

Reference Model）」を整備し運用を開始することで、ボトムアップ的な融合が進み、各機関

の固有システムにおけるデータ標準化を推進することが期待できる。

いずれのガイドライン類も、当初から完全なものを整備することは難しいが、初期に 低

限のトップダウン的な仕組みを作り上げて運用を開始し、随時改訂を加えていくことにより

標準化の範囲拡大が期待できる。

32 The Data Reference Model Version 2.0 November 17, 2005 http://xml.coverpages.org/FEA-DRMv20Final-2005.pdf

33 Core Component Library (UN/CCL) http://www.unece.org/cefact/codesfortrade/unccl/CCL_index.htm

I .標準モデル構築に向けた技術的方策を中心として ５．「公共サービス連携基盤（仮称）」を実現する技術要素

64

（イ） 今後の検討課題

図 I-44に示す４つの標準化ルールを国際標準化の動向も注視しつつ、順次設計・開発

していく必要がある。

⾏政情報⾏政情報カタログカタログ 実態の調査

⾏政情報作成⾏政情報作成ガイドラインガイドライン

第１版の作成 随時改訂を加える

DRMDRM 順次範囲を広げて開発し、全体標準ライブラリに登録

全体全体標準標準ライブラリライブラリ 順次追加整備

データセット単位の整備ファイル単位の整備

雛形の開発

先⾏的取組みを参考に開発

データセット単位データセット単位でで の連携の連携ファイル単位ファイル単位でで の連携の連携

トップダウンの標準化に必要なルール

ボトムアップの標準化に必要なルール

相互に反映

相互に反映

相互に反映

図 I-44 データ標準化ルールの関連性

５．３ 利用者と行政情報の連携の検討

（１） 利用者と行政情報の連携に関する課題と方向性

国民にとって利便性が高く、高度な行政サービスの享受等、また、サービスを提供する

側の行政機関にとっての更なる事務効率の向上を実現するためには、利用者と行政情報

との関連付けについて改善が必要なところである。図I-45に、関連付けされていないことに

よる課題と関連付けされることによる両面の課題について、解決の方向性を示す。

I .標準モデル構築に向けた技術的方策を中心として ５．「公共サービス連携基盤（仮称）」を実現する技術要素

65

解決の⽅向性関連付けされていないことによる課題

プッシュ型の情報提供サービス実現のための、⾏政の事務増に対する懸念

⾃⼰に関わる記録不備の可能性

個⼈特定作業において、個⼈情報が職員の⽬に触れる機会に対する不安

⼀⼈に対して複数の⾏政情報が存在する可能性

利⽤者と⾏政情報を結び付ける個⼈特定作業に関係する事務の⾮効率性

⾏政において⽂字の違い等により、申請内容と⾏政情報が⼀致しない場合の事務の⾮効率性

関連付けされることによる課題

⾏政における不適切な個⼈情報の集約・蓄積に対する懸念

利⽤者識別⼦のなし崩し的な利⽤拡⼤に対する懸念

⼀度に多くの個⼈情報が流出する可能性に対する懸念

利⽤者識別⼦を他⼈に知られることによる不安

⾏政情報保有機関側で利⽤者識別⼦が推測できない⽅式の採⽤

他の⾏政機関の⾏政情報を収集できない⽅式の採⽤（個⼈の興味本意で他⼈の情報収集をさせない。）

個⼈情報保護の観点から、システムの運⽤・管理等を監視する第三者機関などの設置

サービス利⽤にあたり、希望する者を前提とする制度の採⽤

利⽤者を⼀意に特定するための基礎となる基盤の活⽤

⾃らの個⼈情報に対するアクセス履歴の閲覧

図 I-45 利用者と行政情報の関連付けに関する課題と方向性

（２） 方向性を実現するための基盤のイメージ

利用者の利便性の向上・高度なサービスの実現や行政機関における事務の効率化のた

めには、利用者と行政情報の安心・安全かつ確実なる関連付けが必要であり、先に定義し

た解決の方向性に沿って、関連付けを行う仕組みを図 I-46に示す。

バックオフィス（⾏政情報保有）

バックオフィス（⾏政情報保有）

基盤（ディレクトリ機能）基盤（ディレクトリ機能）

分野識別⼦データ窓⼝・

ポータル窓⼝・

ポータル

アクセス

第三者機関等第三者機関等監視

基礎となる利⽤者に関する

データ

利⽤者情報に関するデータ

認証・本⼈特定 識別⼦の変換

①利⽤者識別⼦を⽤いたアクセス

アクセスログの管理DB

連携

連携

連携

②分野毎に発⾏された分野識別⼦を⽤いたデータ連携

アクセス履歴の参照同期

分野A

分野B分野C

各機関（分野）において、利⽤者識別⼦や他の分野識別⼦を把握できない⽅式の

採⽤

個⼈情報保護の観点から、システム全体の運⽤・管理を監視

⾃らに係る⾏政情報の共有化の状況を確認

希望者のみの利⽤

確実なる本⼈確認が成されたデータの活⽤が重要

公共サービス連携基盤（仮称）公共サービス連携基盤（仮称）

図 I-46 課題を解決する方向性のイメージ

利用者は本人の希望に応じて、①利用者識別子を用いたポータルへのアクセスを行う。

I .標準モデル構築に向けた技術的方策を中心として ５．「公共サービス連携基盤（仮称）」を実現する技術要素

66

その際、基礎となる利用者に関するデータと同期された利用者情報に関するデータによっ

て、認証・本人特定が行われ、分野ごとの分野識別子への変換が行われる。

②分野ごとに発行された分野識別子を用いて各機関とのバックオフィス連携が行われ

る。

この方式を用いることによって、各機関においては利用者識別子や他の分野識別子を把

握できない方式でありながらも、本人確認が確実になされた上での情報共有が可能となる。

また、利用者が自らに係る行政情報の共有化の状況を確認することを可能とし、各機関に

おける目的外の情報共有がされていないことを確認することができる。さらに、第三者機関

等によって、アクセスログの分析や個人情報保護の観点からの監視を行うことにより、利用

者と各接続機関、双方の情報共有への不安を解消し、安心かつ効率的なバックオフィス連

携が可能となる。

I .標準モデル構築に向けた技術的方策を中心として ６．次世代電子行政サービスの実現に向けて

67

６．次世代電子行政サービスの実現に向けて

次世代電子行政サービス基盤を具現化するためには、多くの技術要素が関連することを

示してきたが、それらの要素をどのような順番で効率的に検討していくべきか、そのステッ

プと検討課題を示す。

６．１ 実現に向けての作業

実現に向けての各作業の関係性を図 I-47に示す。

現⾏業務分析（現⾏フロー）

現⾏業務分析現⾏業務分析（現⾏フロー）（現⾏フロー）

業務⾯からのあるべき姿検討業務⾯からの業務⾯からの

あるべき姿検討あるべき姿検討

技術⾯からのあるべき姿検討技術⾯からの技術⾯からの

あるべき姿検討あるべき姿検討

新業務検討（新フロー、制度）

新業務検討新業務検討（新フロー、制度）（新フロー、制度）

提供サービスメニュー整理提供サービス提供サービスメニュー整理メニュー整理

該当システム調査・特定

該当システム該当システム調査・特定調査・特定

データ標準化データ標準化データ標準化

⽂字コード検討

⽂字コード⽂字コード検討検討

識別⼦の関連づけ検討

識別⼦の識別⼦の関連づけ関連づけ検討検討

次世代電⼦⾏政サービス提供

次世代電⼦⾏政次世代電⼦⾏政サービス提供サービス提供

（1）－（ア） （1）－（イ） （1）－（ウ）

（２） （３） （４）

（５）

（６）

（７）

（1）－（エ）

図 I-47 実現に向けての各作業の関係性

（１） 業務改革の流れ

ライフイベントに関する次世代電子行政サービス（ライフイベント・ワンストップサービス）

の提供に当たっては、現行の業務フローを分析し、IT活用の可能性や利用者の負担となっ

ている処理等について、機関をまたがった観点での 適化が必要となる。業務改革の検討

方法について、利用者視点でどのように進めるべきか、その例を示す。

（ア） 現行業務フローの洗い出し

一般的に考えられるライフイベント（結婚、妊娠、出産、育児、引越、就職、退職、介護、

死亡等）について、それぞれのイベントで必要な手続を洗い出し、ワンストップ化の範囲を

検討する。特に、引越、退職については先行的に検討を始めているので、検討の結果を活

I .標準モデル構築に向けた技術的方策を中心として ６．次世代電子行政サービスの実現に向けて

68

用する。また、利用者のセグメント（家族、単身者、老齢者等）を分析し、どういった人を対象

としたサービスか、またニーズの有無を検討する。

（イ） 業務プロセス改革（BPR）

次世代電子行政サービスにおいては、国民や企業等の利用者の利便性だけでなく、行

政機関の事務についても効率化を図れるよう、表裏一体での検討が必要である。行政事務

は紙を前提とした業務の 適化や組織内での 適化が図られており、一定の効果は出て

いるものの、ITを 大限に活用することを想定した業務の 適化ではなく、また、行政全体

や社会全体から俯瞰した場合の全体 適化の視点では、十分に取り組まれているとは言

い難い。今後、ITをさらに活用し、電子的処理を前提とした、かつ縦割り行政を排除した全

体 適を目指した業務プロセスに変革していく必要がある。

(a) 手続の省略、代替

各ライフイベントの業務フローを洗い出し、共有化すべき機能や短縮可能なプロセスを

特定し、各機関をまたがった業務フローを俯瞰的に 適化・簡略化していく。各ライフイベン

トに関連する手続の名称、根拠法、対象者、条件、申請先、申請数等を明らかにし、業務フ

ローの共通部分、繰り返しの処理を特定し、利用者の利便性の観点から、統合、省略する

ことが可能かを検討する。また、効果の観点から、申請数が多い手続を優先的に効率化す

ることも検討する。

(b) 添付書類のバックオフィス連携等による省略、代替

各手続に必要となる添付書類について、発行元、提出先、根拠法、添付の目的、添付

書類の受付件数、発行手数料等を明らかにし、電子的に送付可能なものや、自己保管や

士業による保管によって省略可能なもの、もしくは他の機関からのデータをバックオフィス

連携で入手することにより代替可能なものに分類し、利用者の負担となっている添付書類

の削減を図る。各ライフイベントの中での添付書類の受付件数から、削減することによって

効果の高いものを特定し、優先的に省略・削減する方法も検討する。また、同時に、手数料

の免除等、ワンストップ化することによる利用者へのインセンティブを検討する。

（ウ） 新業務フローの定義

現行業務フローを、利用者を起点としたシーケンス図にまとめ、関係機関、関係システム

を明らかにし、ワンストップを実現するためにはどのような連携が必要となるのかを検討す

る。各機関間でのデータの授受や、順番の定義も行う。安全性を確保しながらも、繰り返し

行われる処理は簡略化し、利用者の負担をなるべく減らし、可能な限り早く返答を返せるよ

I .標準モデル構築に向けた技術的方策を中心として ６．次世代電子行政サービスの実現に向けて

69

う検討する。

新業務フローを元に議論を行い、段階的に移行が可能な形を見極めていく。

当然ながら、新業務フローの策定に関しては、制度面での検討も合わせて必要となる。

個人情報保護法や各機関の所管する法律について、連携の障壁となるものについて、必

要性や解釈等を十分に関係機関において調整・協議した上で、利用者の利便性と行政の

効率化を実現するという大きな目標達成へ向けて、あくまでも、局所的ではなく俯瞰的な視

点から検討を行う。

また、重要な観点として、費用対効果の検討が必要である。新業務フローを定義すること

で、必要な基盤やコンポーネントが定義されるが、それらの物理的配置や既存IT環境の制

約事項、あるいは非機能要件を踏まえ、かかる費用を算出し、投資対効果を考慮しつつ実

現の方法を検討していく必要がある。

（エ） 新業務フローの評価と改善

新業務フローにて、ワンストップサービスを提供した後、利用頻度のログや利用者の声を

定期的に分析し、さらなる利便性向上のための評価と改善を行う。

（２） 電子行政サービス基盤の技術面からのあるべき姿の検討

次世代電子行政サービス基盤について、本書の中では「公共サービス連携基盤（仮称）」

を中心として、技術面からの基本的な概念を示したが、今後、これらの仕組みについて構

築する機関や関係する機関とのコンセンサスを醸成する必要がある。その際、これらの仕

組みの有用性の訴求や、デモシステム等による実現イメージの共有、実証実験等を行うこ

とで、より具体的な技術的方策の検討を行っていく。

なお、疎結合によるサービス連携は、拡張性・発展性は非常に高いが、一方で全体の制

御（途中でエラーが発生した際のやり直し処理等）やデータの一貫性等を担保するための

考慮が必要となる。したがって、構築する機関において実施される非機能要件の検討や物

理設計の段階では、本書に示した論理構造を物理構造に落とし込み、全体の制御やエラ

ー発生時のフロー等について、さらに検討を行う必要がある。

（３） 提供サービスメニューの整理

利用者への分かりやすい情報提供を目指し、まずやるべきことは、行政のサービスメニ

ューを整理し、利用者の視点で体系化することである。これらは、各サービスメニューの該

当条件や概要をキー項目とした検索機能の充実や、プッシュ型情報提供、エージェント型

の情報提供を行うためのコンテンツ整備の前提条件となる。図 I-48に取組の関連性につ

いて示す。

I .標準モデル構築に向けた技術的方策を中心として ６．次世代電子行政サービスの実現に向けて

70

⾏政サービスのメニュー整理⾏政サービスのメニュー整理⾏政サービスのメニュー整理

サービス検索機能の充実サービス検索機能の充実サービス検索機能の充実

プッシュ型情報提供プッシュ型情報提供プッシュ型情報提供

エージェント型情報提供エージェント型情報提供エージェント型情報提供

カスタマイズ機能カスタマイズ機能カスタマイズ機能

図 I-48 提供サービスのメニューの整備に関する取組

（４） 必要なデータ項目を保管しているシステムの洗い出し

ワンストップサービス提供に向けた具体的な業務・改革案の作成、課題の洗い出しと解

決策の検討のためには、国民・企業向けの行政サービスに係るデータ項目・データそれ自

体を保管しているシステムを洗い出す必要がある。また、さらに複数の関係機関間のデー

タ連携に用いるべきデータ項目・データそれ自体及び当該データが保存されたシステムに

ついて、データ連携方式等を含むインターフェース仕様やデータの取扱いに関する取り決

め等の策定のために必要な情報を収集する必要がある。図 I-49に必要なデータ項目を保

管しているシステムの洗い出しに関する方法の例を示す。

ネットワークネットワーク

（１）サービス提供に必要なデータ項⽬を保管しているシステムの洗い出し （２）システムに関する情報の収集

① 関係機関が処理する業務・⼿続について、添付書類の交付等も含め業務フローを明確化

① 関係機関が処理する業務・⼿続について、添付書類の交付等も含め業務フローを明確化

③ 複数の関係機関間のデータ連携に⽤いるべきデータ項⽬を特定し、それが保存されたシステムをサブシステムレベルで洗い出し

③ 複数の関係機関間のデータ連携に⽤いるべきデータ項⽬を特定し、それが保存されたシステムをサブシステムレベルで洗い出し

② 当該業務・⼿続を処理するシステムを洗い出し

② 当該業務・⼿続を処理するシステムを洗い出し

複数の関係機関間のデータ連携に⽤いるべきデータ項⽬・データそれ⾃体及び当該データが保存されたシステムについて、データ連携⽅式等を含むインターフェース仕様やデータの取扱いに関する取り決め等の策定のために必要な情報を収集

ワンストップサービス提供に必要な国⺠・企業向け⾏政サービスに係るデータ項⽬・データそれ⾃体を保管しているシステムを洗い出し

アプリケーションアプリケーション

ミドルウェアミドルウェア

ＯＳＯＳ

ＤＢ

収集すべきシステムに関する情報（例）

項目Ａ 項目Ｂ ・・・○△ ○× ・・・

通信⼿順・⽅式、認証⽅式、通信路セキュリティ等

ＤＢ管理システム(ＤＢ更新系の場合)

データ項⽬体系、コード体系等

その他：システム更新時期等

Ver.情報等

※ なお、このような既存データ・システムの洗い出し・情報収集に当たっては、既存の電⼦政府の推進に係る取組等との整合性を確保し、（情報資産台帳等の）関連する他の調査との連携・活⽤等により効率的かつ効果的に推進すべき。

システム洗い出しの流れ（例）

I .標準モデル構築に向けた技術的方策を中心として ６．次世代電子行政サービスの実現に向けて

71

図 I-49 システムの洗い出しに関する作業イメージ

（５） データ標準化の進め方

（ア） 先進国取組事例調査

手戻りを 小限とするために、先進的な取組によって得られたノウハウを活用する。成功

事例と失敗事例を分析し、我が国における効率的なデータ標準化の取組の参考とする。

（イ） 電子化現状調査

現状の各機関の保有するデータについて、電子化の状況を確実に把握することが必要

である。

（ウ） 標準化スキームの構築

トップダウンとボトムアップの双方向から進める体制づくりが重要と考えられる。データの

標準化は高度な業務分析能力とモデル化能力が求められるものであることから、専門知識

を有した特定の組織による長期間での対応が必要となる。

（エ） 優先的に標準化すべきデータの選定

異なるシステム間で共有化する可能性が高いデータ、あるいは既に複数のシステムで重

複管理しているデータ等を調査し、優先的な範囲を検討する。

（オ） 特に効果的な事例を先行して標準化

全データの標準化を対象として進めるのではなく、進めやすく効果的なスモールスタート

での先行事例を実践することが効果的と考えられる。さらなる地域情報プラットフォームの

活用等も検討する。

（カ） メタデータの標準化優先

疎結合を実現するメタデータの標準化を優先する。

（キ） データそのものの標準化にはデータ構造のモデル化が必要

DRMを事前に構築しておき、十分なコンセンサスを得た後、データそのものの標準化を

行うことが理想的と考えられる。データの標準化は抜け漏れを極力出さないように、体系的

に、かつ、慎重に行うべきである。

先進国取組事例調査先進国取組事例調査 標準化スキーム構築標準化スキーム構築

電⼦化現状調査電⼦化現状調査 優先的に標準化すべきデータの選定優先的に標準化

すべきデータの選定

メタデータの標準化メタデータの標準化

特に効果的な事例を先⾏して標準化

特に効果的な事例を先⾏して標準化

データ参照モデル（DRM）データ参照モデル（DRM）

データそのものの標準化データそのものの標準化

先進国取組事例調査先進国取組事例調査 標準化スキーム構築標準化スキーム構築

電⼦化現状調査電⼦化現状調査 優先的に標準化すべきデータの選定優先的に標準化

すべきデータの選定

メタデータの標準化メタデータの標準化

特に効果的な事例を先⾏して標準化

特に効果的な事例を先⾏して標準化

データ参照モデル（DRM）データ参照モデル（DRM）

データそのものの標準化データそのものの標準化

先進国取組事例調査先進国取組事例調査 標準化スキーム構築標準化スキーム構築

電⼦化現状調査電⼦化現状調査 優先的に標準化すべきデータの選定優先的に標準化

すべきデータの選定

メタデータの標準化メタデータの標準化

特に効果的な事例を先⾏して標準化

特に効果的な事例を先⾏して標準化

データ参照モデル（DRM）データ参照モデル（DRM）

データそのものの標準化データそのものの標準化

図 I-50 データ標準化に関する取組

I .標準モデル構築に向けた技術的方策を中心として ６．次世代電子行政サービスの実現に向けて

72

（６） 文字コードに関する検討

（ア） 文字情報データベースの整備

(a) 文字集合について

関係する機関が保有する全ての文字を標準的な文字集合とすることは、混乱を招きか

ねないため、例えば、既に実績・根拠のある住民基本台帳ネットワーク統一文字、戸籍統

一文字及び登記統一文字等を基準とし、適切な文字体系を構築する取組が必要となる。そ

のように範囲を特定した上で、各システムにて活用を可能とするために、我が国の標準的

な文字情報データベースの構築が必要となる。

(b) 文字情報データベースの機能について

関係機関における既存のシステムで管理されている文字と文字情報データベースの文

字を同定し、変換テーブルの作成が必要となることから、文字情報データベースには検索

機能やデータ提供機能が求められる。

(c) 文字情報データベースの整備について

文字情報データベースに登録する文字を選定する作業は、文字に関する相応の知識を

有した者による作業が必要である。また、場合によっては、運用開始後に追加する文字が

発生することも考えられることから、運用における対応も含めて検討が必要である。

文字情報データベースに登録される文字に関連する属性情報として、文字を一意に扱う

ための文字図形番号が必要であるが、それ以外に関係機関における文字の同定作業を促

進するための住民基本台帳ネットワーク統一文字コードのコード情報やシフトJISコード等も

必要であると考えられる。また、文字を検索するためには、画数、部首、読みによる検索に

必要な情報や異体字検索を可能とする情報も検討する必要がある。

（イ） 「公共サービス連携基盤（仮称）」における文字コードの取扱いについて

「公共サービス連携基盤（仮称）」を通じてデータ連携する際の文字の取扱いに関わる統

一的なルールについて、ガイドラインを策定し、関係機関に周知徹底する必要がある。ガイ

ドラインに規定すべき項目として、文字コード体系、文字図形番号にて取り扱うデータの定

義方法、文字情報データベースに取り込まれていない文字の取扱い等が挙げられる。

（ウ） 実現に向けての検討作業

以下の検討作業が必要となる。

・「公共サービス連携基盤（仮称）」における文字の取扱いに関するガイドラインの策定

・文字情報データベースの構築

・文字情報データベース等の運用設計

I .標準モデル構築に向けた技術的方策を中心として ６．次世代電子行政サービスの実現に向けて

73

・評価や改善等のサイクル

さらに、利用者にとって内字や外字を意識することのない利用環境が望ましいため、現

在、外字として扱われている文字が標準規格等に採用され、情報通信機器等において標

準サポートされる環境整備を推進する必要がある。

（７） 利用者と行政情報の識別子に関する今後の検討課題

（ア） 調査事項

個人や企業等を一意に特定することが可能な既存の基盤システムや制度についての調

査や行政機関側のバックオフィスシステムにおける識別子（番号等）の取扱いの状況調査

が必要となる。

（イ） 検討事項

基盤に求められる要件として以下を検討する必要がある。

個人や企業等を一意に特定するための基礎となる仕組み

利用者が利用する識別子

「公共サービス連携基盤（仮称）」における分野識別子の発行方法

個人情報保護の観点から求められる要件の整理

また、その体制についても検討する必要がある。

基盤の運営主体に関する検討

第三者機関等による監視に関する検討

I .標準モデル構築に向けた技術的方策を中心として ６．次世代電子行政サービスの実現に向けて

74

６．２ 実現に向けての展望

次世代電子行政サービスを実現するために、平成20年6月にまとめた「次世代電子行政

サービスの実現に向けたグランドデザイン」においては、行政サービスの中から個人に関

わる引越手続、企業の関与が大きい退職手続を標準モデル34として採用した。引越手続、

退職手続はライフイベントに関する行政手続の中では比較的多くの利用があり、添付書類

の存在、複数機関への訪庁、行政だけではなく民間の手続も存在するなど多くの要素を網

羅した手続であるため標準モデルの対象として選択したところである。これら引越手続、退

職手続に関する実証実験の成果を踏まえ、それ以外の分野についてもサービスを検討し、

国民本位の究極の電子社会に近づけていくものである。

今後、次世代電子行政サービスを推進していくためには、多くの行政機関や民間機関の

サービス提供者の参加が必要となる。限られたサービスや機関では、利用者側に提供され

るサービス自体の魅力が小さいものとなってしまう。したがって、次世代電子行政サービス

が広く一般的に利用されるためには多様かつ広範なサービスを提供することが望ましいと

ころであるが、短期間に参加団体や提供サービスを拡張することは困難であり、段階的な

移行を考慮する必要がある。また、次世代電子行政サービスの実現には、制度的、技術面

の全体的な課題の解決に加え、サービス提供者側の環境整備が非常に重要となることか

ら、実現に向けた工程においては、その点についても十分に配慮する必要がある。図 I-51

にその考え方を示す。

標準モデルの構築

（2010年度を⽬途に構築予定）

標準モデルの構築

（2010年度を⽬途に構築予定）

サービス提供者が単⼀のサービス開始サービス提供者が単

⼀のサービス開始サービス提供者が複数にまたがるサービスの開始サービス提供者が複数に

またがるサービスの開始制度整備環境整備制度整備

環境整備

基盤整備国・地⽅の包括したポータル

公共サービス連携基盤（仮称）基盤整備

国・地⽅の包括したポータル公共サービス連携基盤（仮称）

サービス提供側の環境整備（順次実施）サービス提供側の環境整備（順次実施）

基盤の拡張基盤の拡張提供するサービスとその順序の検討

提供するサービスとその順序の検討

全体全体

基盤整備

基盤整備

⼀部地域でのサービス開始⼀部地域での

サービス開始地域・サービスを拡充地域・サービスを拡充

図 I-51 次世代電子行政サービス実現に向けて

今後、技術面、制度面、運用面等の視点での課題の整理と具体的な方策について検討

し、2010年度を目途に次世代電子行政サービスの標準モデルを構築する。その際、基盤を

構築する機関の決定や関係機関の役割分担の明確化、第3者機関やデータ標準化のため

34 ここでいう「標準モデル」とは、当初実現モデルのみならず、理想モデルを含めて、方向性及び制度面、技術面等の観点から、課題及び、実証実験等の成果を基に、解決のための

具体的な方策をまとめたドキュメントを意味する。

I .標準モデル構築に向けた技術的方策を中心として ６．次世代電子行政サービスの実現に向けて

75

の体制や運用のための体制等について、基本的な構想をまとめる。その後、標準モデルに

従い、制度面の整備やインフラとなる基盤システムの構築を進め、並行してサービス提供

側でも環境整備を進める。提供するサービスについては、一度に全てのメニューを用意す

ることは困難であるため、まずは単独のサービス提供機関においても成立するサービスか

ら提供を開始し、徐々にサービスの種類や参加機関の増加を促進していき、 終的に複数

の機関をまたぐサービスをサポートしていくことも考えられる。さらに、一部地域において一

部サービスを先行的に実用化し、評価を行い、サービス提供機関の積極的な取組等を通じ

て成功事例を蓄積することによって、多彩かつ広範なサービス拡充を目指す。

もはや、企業のみならず政府においても、情報連携に関する取組を重視する傾向にあり

（イギリスのDirect Gov35やBusiness Link36、韓国のG4C（電子民願）37、ベルギーのCBSS38

等々）、それは世界的な潮流になっている。情報を連携させることによって、組織はよりスマ

ートに、正確性を高めつつ効率的に、臨機応変に世の様々な事象に対応できるようになり、

国際的にも競争力の高い組織へと生まれ変わることができる。我が国においても、ITを活

用したスマートな政府を目指し、着実に次世代電子行政サービスの実現に向けた取組を推

進していく必要がある。

35 Direct Gov http://www.direct.gov.uk/en/index.htm 36 Business Link http://www.businesslink.gov.uk/ 37 G4C http://www.egov.go.kr/ (※サイトにアクセスする際にプラグインの導入を求められますのでご注意ください。) 38 CBSS（ Crossroads Bank for Social Security ） http://www.ksz.fgov.be/