平成１７年度官民連携標準策定事業（官民連携ポータル検討）
報告書

2006 年 3 月
官民連携ポータル検討会

目 次
１ 本検討会の目的 ···············································································································································１
２ 官民連携ポータルの必要性と課題 ···········································································································２（１）官民連携ポータルの必要性 ·······················································································································２（２）申請受付事業者の現状 ·······························································································································５（３）官民連携ポータル事業の現状 ··················································································································８（４）実現に向けた検討課題 ································································································································１０
３ 実証実験の概要 ···············································································································································１２
４ 個人認証方法に関する検討 ························································································································１７（１）検討の必要性と方法 ·····································································································································１７（２）現状 ······································································································································································１９（３）実証実験における個人認証方法と課題································································································２７（４）官民連携ポータルにおける個人認証のあり方 ···················································································２９
５ 個人情報保護に関する検討 ························································································································３７（１）検討の必要性と方法···················································································３７（２）現状 ·······································································································３８（３）実証実験における個人情報の取り扱い方法と課題 ·············································４４（４）官民連携ポータルにおける個人情報保護のあり方 ·············································５０
６ データ標準化に関する検討··························································································································６２（１）官民連携ポータルにおけるデータ標準化の必要性··········································································６２（２）データ標準化の現状······································································································································６３（３）官民データ連携のためのアプローチ·······································································································６５（４）官民連携データ標準化のフレームワーク ·····························································································６６（５）官民連携データセットの利用に関する検討事項················································································７６
７ まとめ ································································································································································８１
参考資料

１ 本検討会の目的
2001 年に策定された e-Japan 戦略は本年度目標年度を迎え、本年１月１９日には、いつでも、どこでも、誰でもＩＴの恩恵を実感できる社会の実現を目指し、ＩＴ新改革戦略が策定された。これまでの間、電子商取引分野では、2004 年現在の市場規模が 100 兆円を越え、2001 年の約 3 倍と急成長した（経済産業省・ECOM・NTT データ経営研究所調べ）。また、
電子政府、電子自治体分野では、総合行政ネットワーク（LGWAN）に全ての地方公共団体が接続され、電子申請・届出サービス及び公的個人認証サービスも開始された。今後、電子
政府・電子自治体分野と電子商取引分野をより円滑に結合することにより、国民生活の利便性向上や、より効率と利便性の高い俊敏な経済、活発な企業活動と新たなビジネス機会の創出などを実現していくことが望まれる。
例えば、国や地方公共団体における電子申請・届出や、電力、ガスなどの公益企業及び民間企業における各種手続きのオンライン化である。現状は各手続きごとにオンライン化され、複数の手続きを行う場合には、複数のサイトにアクセスする必要がある。今後は、これらの手続きを一括して完結するようなワンストップ化を目指したサービスへと移行する事が予想され、住所変更などのワンストップサイトも登場しはじめている。
ネットワークサービスを利用して手続きを行うワンストップサービス化は、今後、電子商取引
分野と電子政府・電子自治体分野を横断して、ますます進展していくものと考えられる。このようなサービスの中核となるのが「官民連携ポータル」である。
本検討会では、以上の様な状況に鑑み、2005 年 2 月 24 日に IT 戦略本部において決定された、IT 政策パッケージ 2005 に基づいて、官民連携ポータル事業を円滑に推進するための条件整備について検討を行い、その成果を本報告書として取りまとめた。

1

２ 官民連携ポータルの必要性と課題
官民連携ポータルとは、申請・届出を行う住民等の利用者の立場に立って、申請・届出作業を行う側からの利便性を追求するものである。
すでに国、地方公共団体を含む申請受付事業者は、インターネット上で申請届出サービスを開始しているものも多く、これらのサイトを接続することにより、ワンストップサービスを実現する環境が整いつつある。
しかしながら、現状では、個別事業者、システム、手続きごとに電子化・システム化されているため、利用者にとっては、必ずしも利便性が高くなく、利用率が上がらないことが課題となっている。利用者の立場に立てば、行政区分や官民などの事業体に関係なく、必要な手続きを一度に処理できることが望ましく、そのためには官民が連携したポータルの構築が必要である。
本章では、官民連携ポータルのイメージを明確にするとともに、官民を含めた多くのサイトを連携させる際に必要となる課題について検討する。
（１）官民連携ポータルの必要性
官民連携ポータルの活用場面としては、国民の生活活動（転居、結婚などのライフイベントなど）から、企業活動（創業、貿易、海外進出、雇用関係など）まで、様々な分野が考えられる。
中でも住所変更手続きは、官民それぞれの手続きにおいて幅広く必要となる場合が多いことから、以下、引越し時の住所変更手続きを例として、官民連携ポータルの必要性やメリットなどを検討していくこととする。
１）現在の手続き方法
現在、例えば引越しの際には、・まず必要な手続きとその方法を調べ・各手続きに必要な書類等を用意し・各手続きの窓口（または電話や郵送、電子申請・届出など）などにおいて手続きすることが必要となる。
現状では、手続きによって、別々の窓口などに出向く必要があり、官と民で様式や必要な添付書類が異なるなど、混在してわかりにくい状況にある。また手続きの内容も、住所、氏名等、共通の項目が多いが、現状では、各手続きごとに、新旧住所など同じ内容についてそれ
ぞれ、変更手続きを行わなければならない。（次図参照）

2

様々な手段

電力会社

必要な手続き、方法、連絡先を調べる
ガス会社

それぞれに対して手続する
同じことを何度も繰り返す必要がある
方法も、電話、窓口、インターネットなど様々

電話（共通情報）
・住所（現住所、移転先）
・名前（必要に応じて家族全員）
・引越日時（転入、転出日、立会日時など）

住民（個別手続情報）・お客様番号
・転校手続
・自動車登録、軽自動車、原付自転車移転
・印鑑登録廃止、申請
・国民健康保険・国民年金
・郵便物転送手続によっては書類の入手が必要
また、手続の際、他の手続の結果得られる書類（住民票など）が必要になる場合もある

水道事業者

役所

窓口
電話会社

警察

インターネット
金融機関

その他、葉書、
ファックスなど

NHK
CATV会社
その他、様々な
住所変更手続など

図２－１ 従来の手続き方法
出所：ワンストップポータルにおける行政関連手続きに関する調査研究（平成17年3月 経済産業省）

3

２）官民連携ポータルのイメージ
このような手間を省略し、一度に必要な手続きを済ませることを可能にするのが、官民連携ポータルである。各手続きには、共通の記入事項（氏名、旧住所、新住居、連絡先など）があるため、これらの共通情報について、一度入力するだけで全ての手続きに活用し、さらには個別に必要となる情報についてポータル上での入力、手続きを可能とするものである。
これにより、利用者にとっては、一度でインターネット上での手続きが完了し、窓口に出向いたり、書類の入手、郵送等の手間が最小限で済むようになる。
また、申請受付事業者にとっても、利用者から個別に手続き申請がなされる場合と比べて、誤記入の減少や電子申請利用の促進などのメリットが得られる。
官民連携ポータル事業者は、両者をつなぎ、双方に利便性を提供する役割を果たすものである。例えれば、利用者が消費者、申請受付事業者が生産者や卸売り事業者、官民連携
ポータル事業者が総合スーパー等の小売店の役割を果たすことになる。これにより、個々の申請受付事業者は業務の効率化（事業者間の手続きの共通化や合理化など）に専念することができ、利用者にとっての使い勝手や利便性向上などは、官民連携ポータル事業者の努力に委ねることが可能になる。

電力会社

基本情報入力・現住所、氏名・移転先住所・移転（引越し）予定日など

ガス会社

水道事業者

家族の属性など選択・就学児童の有無
・自動車などの所有
・国民年金加入の有無
・犬の有無など

役所

必要手続き一覧、書類（ウェブ）表示
各書類の必要項目記入（基本情報入力済）

インターネット

電話会社▲▲▲▲▲▲▲▲▲▲●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●◆◆◆◆◆◆◆－－－－－－－－－－
●●●●●
●●●●●

●●●●●
●●●●●

●●●●●
●●●●●

●●●●●
●●●●●

●●●●●
●●●●●

●●●●●

●●●●●

●●●●●

●●●●●

●●●●●

警察

住民
＊代行サービス・不動産会社・引越し会社・行政書士など

住基カードなどで認証必要手続完了必要に応じて書類が郵送されてくる＊行政窓口のワンストップ化＊コンビニ、郵便局での代行＊コールセンターでの代行など

金融機関

NHK
CATV会社

その他、様々な
住所変更手続など

図２－２ 官民連携ポータルのイメージ
出所：ワンストップポータルにおける行政関連手続きに関する調査研究（平成17年3月 経済産業省）

4

（２）申請受付事業者の現状
１）国の各行政機関における申請・届出等のオンライン化の状況
平成 16 年度現在、国の各行政機関における申請・届出等のオンライン化の状況は、対象
手続き 14,205 件に対し、13,669 件（96％）であり、ほとんどの申請・届出等が電子化されている。また、申請・届出等以外の手続きについても、対象手続き 17,895 件に対し、11,388 件（64%）が電子化されている。
今後のオンライン利用促進に向け、年間申請件数の多い手続等を中心に１７５の「オンライン利用促進対象手続」を定めており、各手続きごとに、利用者視点に立ったシステムの整備、手数料の見直し、手続きそのものの簡素化・合理化の徹底等の具体的利用促進措置を定める「オンライン利用促進のための行動計画」を、平成 17 年度中に策定することとしている。
表２－１ 国の行政機関が扱う手続きのオンライン化状況
区分
申請・届出等手続き
申請・届出等以外の手続き

対象手続き（単位：件）
平成 17 年度

実施手続き

以降実施

14,205

13,66996%536(13,853)(13,317)

(96%)

(536)

17,895

11,38864%

6,507(18,045)(10,993)(61%)(7,052)※（ ）内は平成 15 年度
出所：総務省ホームページ http://www.soumu.go.jp/s-news/2005/050727_2.html

２）地方公共団体における申請・届出等のオンライン化の状況
地方公共団体が扱う申請・届出等について、汎用受付システムを導入している団体は平成
17 年４月１日現在で、都道府県 37 団体、市町村 493 団体である。平成 18 年度中には、都道府県で 45 団体が導入予定となるなど、地方公共団体における申請・届出等のオンライン化は着実に進展している。
また、都道府県単位で汎用受付システムの運用を共同で実施している団体は、平成 17 年
４月１日現在で、14 団体であり、今後７割ほど（32 団体）の都道府県で共同化が実施される予定である。
３）オンライン利用率の向上等
本年１月１９日にＩＴ戦略本部において決定された「ＩＴ新改革戦略」においては、「利便性・サービス向上が実感できる電子行政（電子政府・電子自治体）を実現し、国・地方公共団体に対する申請・届出等手続におけるオンライン利用率を 2010 年度までに 50%以上とする」こと
が目標の１つとして掲げられており、また、電子自治体における基盤として「公的個人認証に5対応した電子申請システムを、全都道府県においては 2008 年度までに、全市町村においては 2010 年度までに整備する」こととされ、その取組みが求められている。

都道府県

市町村

図２－３ 地方公共団体における申請・届出等のオンライン化の状況
出所：「地方自治情報管理概要」（平成 17 年 10 月 総務省）

◆開始済みの都道府県（14）福島県、茨城県、東京都、山梨県、愛知県、島根県、岡山県、広島県、徳島県、高知県、香川県、熊本県、
大分県、鹿児島県図２－４ 電子申請（汎用受付システムの運用）の共同化の状況
出所：「都道府県を中心とする電子自治体構築に向けた共同化の取組状況調査結果」（2005 年 4 月 1 日時点）

6

３）電子商取引分野の手続オンライン化
これまでにも、オンラインによる企業間の受発注や決済の電子化（BtoB）は行われてきたが、インターネットの普及、活用により、より多くの企業が低コストで電子商取引を行うことが可能になった。その市場規模は、2004 年現在で 100 兆円を越えるに至った。
また、企業と消費者の間の取引きの電子化（BtoC）や、消費者同士の取引き（CtoC、ネット
オークションなど）も可能となり、市場規模は 2004 年現在、5 兆円を超えた（ともに経済産業省・ECOM・NTT データ経営研究所調べ）。

7

（３）官民連携ポータル事業の現状
１）国内の取組み事例
国内の住所変更分野の官民連携ポータルへの取組み事例としては、引越れんらく帳（東京電力）、関西引越し手続きサービス（関西手続きワンストップ協議会）などが、ワンストップポー
タルサービスを開始している。また札幌市でも、２００４年度に官民連携ポータルによる住所変
更手続きの実証実験が行われた。
表２－２ 官民連携ポータルへの取組みの例
サービス名称
運営主体

引越れんらく帳
東京電力

関西引越し手続きサー札幌地区目的指向ポータ

ビス

ルモデル（実験）

関西手続きワンストップ 札幌市
協議会

開設時期（実験の 平成 14 年 1 月スタート 平成 17 年 1 月スタート

平成 16 年 12 月、

場合は実験期間）

平成 17 年 1 月～2 月

図２－５ 引越れんらく帳（左）と関西引越し手続きサービス（右）引越れんらく帳：http://www.tepore.com/hikkoshi/renraku/
関西引越し手続きサービス：http://www.hikkoshi-onestop.jp/portal/

8２）海外の「官民連携ポータル」への取組み事例
海外では、例えば英国の「I am moving.com」が注目される。「I am moving.com」は英国内の個人を対象とした引越ポータルサイトで、登録し、旧住所と新住所を入力すれば、自治体、パスポートや運転免許証などの政府機関、電気・ガス・水道などの公共サービス、金融機関、
クレジットカード・保険・スポーツクラブなどの民間企業へ住所変更手続きなどを一括して行うことができる。参加団体は約 750 団体である。
１９９９年からサービスを開始し、現在では、広告収入なども得られるなど事業として継続性があるビジネスモデルとして運営されていると考えられる。

図２－６ 「I am moving.com」
http://www.iammoving.com/

9

（４）実現に向けた検討課題
以上のような現状を踏まえ、既存サイトの運営主体（東京電力、関西手続きワンストップ協議会、札幌市）へのアンケートやヒアリング調査、地方公共団体の取り組み状況や、官民の利用規約などの調査等により、利便性に関する検討及び官民連携ポータル事業を立ち上げ、運営する際の制約要因の抽出を行った。
さらには、別途実施された実証実験から得られた知見や課題などについても盛り込んだ。
検討にあたっては、以下の３点を中心に行った。各課題の詳細については、次項以降に述べる。
１）個人認証方法
既存の様々な申請受付事業者は、それぞれの事情に応じて、手続きを行う本人性の確認を様々な手段を講じて行っている。インターネットによる手続きにおいては、公的個人認証サービスを始めとした、第三者の電子証明書を必要とするもの、ＩＤ、パスワードなどの利用、郵送との組み合わせなど、いくつかの手段がある。
例えば、電気、水道、ガスのように、定期的に担当者が出向いて検針をするような業務形態の場合、手続きの際の本人確認を簡便に行い、検針時の現場での確認を重視する場合もある。銀行の住所変更などは、届出印による書類の提出が必要となる。行政関係手続きについては、窓口で身分証明書等による本人確認が必要な場合が多い。
このように、各手続きごとに本人確認方法が異なっていることから、これらを統合して一括で本人確認をし、データを更新する事は困難であり、現在のポータルでは、個別の手続き先サ
イトでのそれぞれの認証に委ねている場合が多い。この方法では、手続きごとに認証を行う必要があり、利用者にとっては煩雑であると感じられる。一度に全ての手続きをノンストップで行う
ためには、できるだけ少なく、かつ簡単な認証方法で全ての手続きを完了できることが望まれる。そのための考え方を整理することが課題である。
２）個人情報保護
個人情報保護法や個人情報保護条例の制定により、民間企業や地方公共団体等において、個人情報を厳格に取り扱うことが必要となっている。現在、サイトで個人情報の入力などを行う場合、個人情報の取得目的、利用範囲、提供制限、管理等に関する事項などを明記し、本人の承認を得た上で、プライバシーポリシーなどに沿って厳格に管理、利用されることになる。
官民連携ポータルの場合、一度の情報入力により複数の手続きを行うことから、ポータルと各接続事業者との手続き間で個人情報のやりとりが生じる。従来、サイト（単独主体）内で完結
していた個人情報の取り扱いに対し、複数主体に対する情報流通を前提とした、個人情報保護対策のあり方や、セキュリティ確保の方法などを明らかにする必要がある。

10

３）データセットの標準化
各申請受付事業者が有する既存システムについては、手続きやシステムごとに、様々なデータ形式やデータ仕様等が用いられている。官民連携ポータルでは、複数の手続きを一括して行うことから、これらの様々なシステム間の異なったデータ形式を一括して取り扱う必要がある。このため、システム改造によるデータセットのすりあわせ、異なったシステム間のデータ変換等が必要となる。対象となる手続き、システムが増えると、指数関数的に、こうした作業が増大し、個別にデータ変換を行うことが難しくなる。このためデータ形式の統一、標準化が必要となる。
現在、中央省庁間、地方公共団体間、中央省庁と地方公共団体間などで、標準化の検討が進んでいる。また、民間においても、電子商取引、財務、電子カルテ、旅行、新聞など、業
種や分野ごとの標準化の検討が進みつつある。しかし、官民連携ポータルのように、官民双方の多様な主体が参加、関与するものについては、データセットを共有し、標準にしていく仕組みは課題となっており、今後作り上げていく必要がある。
また、官民連携ポータルサイトが自立的に運営されるための収支構造、いわゆるビジネスモ
デルを確立する必要がある。
現在、国内でサービスを開始している 2 事例は、電力事業の付加サービス的な位置づけ（引越れんらく帳）や、サービス立ち上げ後間もない（関西引越し手続きサービス）ことなどから、事業単体での採算性はまだ得られていない。利用可能な手続きがまだ少なく、中でも行政手続きに関しては水道などの一部事業を除いて実現できていない点も課題である。
英国の「I am moving.com」では、手続き可能な団体が約 750 と多く、住所変更を行う利用者からは料金をとらず、これらの団体から料金を徴収するとともに、広告収入（ページ内バナ
ーなど）や、連携プロモーション（引越しに関係して必要なサービスサイトへの誘導など）による収入により、事業採算性を向上させている。
我が国において、官民連携ポータルのビジネスモデルを構築するためには、利用可能な手続きを拡大することにより、利用者にとっての利便性の向上を図るとともに、収入源の多様化、拡大を図る必要がある。
また、官民連携ポータル事業の立ち上げ、運営コストを削減することが必要である。特に、前述したように、個人認証や個人情報保護に関する関係者間での合意形成、緊急時の責任分担、これらに係るコストなど制度的リスクや、関係情報システム間でのデータ連携のために必要な技術的投資リスクの削減が必要である。
ビジネスモデルの検討に関しては、実証実験の中で別途検討されている。本検討会では、
今後、ポータルに取り組む、あるいは連携の可能性のある事業者にヒアリングを行い、その結果の概要を巻末の参考資料に取りまとめた。

11

３ 実証実験の概要
平成 17 年度官民連携標準策定事業「官民連携ポータルに関する開発・実証事業」（経済産業省）では、公募により下記のコンソーシアムを選定し、官民連携ポータルに関するシステムの開発および実証実験を行った。

「官民連携ポータル推進コンソーシアム」メンバー
・札幌総合情報センター株式会社
・東京電力株式会社
・関西手続きワンストップ協議会（松下電器産業株式会社）
・NEC ネクサソリューションズ株式会社
・株式会社トライ・ビー・サッポロ

以下に実証実験の概要を示す。より詳細な情報については、巻末参考資料を参照のこと。

12平成 17 年度官民連携標準策定事業「官民連携ポータルに関する開発・実証事業」の概要●目的
本事業は、経済産業省と総務省が共同開催している「官民連携ポータル検討会」の中間報告書の内容を踏まえ、「官民連携ポータルのサービスの在り方」、「広域連携のためのデータ標準化ならびにインターフェース開発」、「個人認証方法の現時点での方式と課題抽出」、「個人情報保護対策の調査研究」について調査研究を行い、官民連携ポータルが継続的に運用可能なビジネスモ
デルの導出を図り、官民連携ポータルによるワンストップサービスの実現を目的とした。
調査研究段階の結果については以下のとおりである。
・官民連携ポータルサービスの在り方＜手続きの範囲＞手続きの受付と転送とする。
＜サービス内容＞電話で受付を実施し，ポータルシステムへ一括入力。Web 連携が実施できない事業者へは FAX や届出用紙の印刷により対応。
・広域連携のためのデータ標準化ならびにインターフェース開発＜事業者連携方法＞ポータル側で共通，個別項目を設定し，事業者の違いを吸収。
＜情報交換方法＞標準データから各ポータルのローカルデータへ変換により実施。
＜データ標準化＞事業者情報検索を対象に XML データ仕様を策定。
・個人認証方法の現時点での方式と課題抽出＜個人認証＞各受付事業者の認証方式によることとし、ポータルシステムでの認証は実施しない。
＜ポータル間認証＞実績や信頼性からサーバ情報に関する認証とする。
・個人情報保護対策の調査研究＜個人情報保護＞個人情報の扱い等についてはポリシーを定め，周知を図る。
実証実験においては、上記の４つのテーマに関する調査研究を踏まえ、実際に官と民との手続連携及び地域ごとに存在するポータルサイトの連携を行い、実験から得られた結果から問題や課題の検証を実施し、今後のワンストップサービスのあり方について検討を行った。
実証実験における実施内容は以下のとおりである。
・札幌地域における官民連携引越し情報ポータルシステムの開発と実験運用
・複数のポータル事業者が連携するシステム開発と実験運用
・地域の中小事業者や代行利用事業者が活用できる代行 ASP サービスの開発と実験運用
・官民連携ポータル事業が継続的に運用できるビジネスモデルの研究
実証実験は平成 18 年 2 月 6 日（ポータル間連携は 13 日）から 2 月 28 日まで実施した。ビジネ
スモデルの研究に関しては，札幌地域をモデルに研究会を組織化（委員 8 名，手続き事業者を含
む産学官から選出）し，平成 17 年 11 月から平成 18 年 3 月までの間 5 回開催した。

13

実証実験での実施内容と結果
実証実験での実施内容とその結果は以下のとおり。
１）札幌官民連携引越し情報ポータル(H18/2/6～28)＜実験モニター数＞実際に引越しする人 20 名（手続き件数は 21 件）。これらのモニターに対してアンケート票を送付し，サービス満足度，改善点，利用意向等を調査。
＜対象手続き＞異動届[転入，転出，転居]（札幌市），水道停止/開始（札幌市水道局），電
気停止/開始（北海道電力），都市ガス利用停止/開始（北海道ガス），新聞購読（北海道新聞社）＜手続き方法＞電話にて手続き内容を実験モニターからの申請により受け付け。その後，オペレータがポータルシステムを用いて手続き情報を各事業者へ送信。ただし，Web 対応は水道と電気のみ。都市ガスは届出書類印刷の上，FAX 送信。異動届は届出様式印刷の上，実験モニター（申請者）へ郵送し，モニターが押印の上窓口提出。
＜個人情報＞電話ならびに文書でセキュリティポリシーを実験モニターへ周知。
＜個人認証＞モニター本人であることを登録された電話番号にコールバックすることにより確認。
＜データ連携＞全ての手続きデータについて事業者側が受け入れることができた。
＜アンケート結果＞実験サービスに対する満足度は高く（満足 63％），今後の利用意向も高かった（今後も利用する 81％）。また有料でも利用する意見が多かった（63％）。
＜課題＞手続き事業者の拡大。利用者の必要手続きのナビゲーションサービスの開発 ほか。
２）地域のポータルが連携した事業者情報検索(H18/2/13～28)＜連携するポータル＞札幌官民連携引越しポータル（札幌地域）、引越れんらく帳（関東地域）、「関西引越し手続きサービス」（関西地域）＜連携内容＞引越し手続事業者の連絡先情報について，郵便番号と住所の入力により連絡
先名称，連絡先（電話番号，URL など）を Web 上で提供。連携は，開発した共通インターフェースを用いて SOAP により実施。この際のデータは XML データ。
＜データ標準化＞入力情報（郵便番号と住所）および出力情報（事業者名称，連絡先など）について XML 化を実施。
＜認証＞ポータル遷移時に，利用者に対して明示的に表示し，利用者の意思を確認。
＜個人情報＞ポータル遷移時に，遷移先ポリシー概要を表示し，利用者の意思を確認。
＜実施結果＞総アクセス数 12,368 件。検索利用数合計 2,248 件。通信やアプリケーションエラーは発生しなかった（大きな問題なく処理できた）。
＜課題＞ポータル間連携が拡大する際の運用面において，責任範囲の調整や事業者追加時の管理コードの策定など。
※参考：関東－関西間では各ポータル事業者が持ち込んだ手続きの連携を実施。実現方法

14

は Web 連携。期間中の利用数は引越れんらく帳で 109 件，関西引越し手続きサービスで 90 件であった。
３）代行手続きサービス（ASP サービス）(H18/2/6～28)＜実験モニター数＞実際に引越しする人 11 名（手続き件数は 11 件）。これらのモニターに対して店舗窓口で，サービス改善点，利用意向等のアンケート調査を実施。また，実験場所となった不動産店舗についてもヒアリングを実施した。
＜対象手続き＞１）と同じ。ただし異動届に関しては記入済みの様式をモニターへ手渡し。
＜手続き方法＞不動産店舗の窓口にて手続き内容を実験モニターからの申請により受け付け。その後，オペレータがポータルシステムを用いて手続き情報を各事業者へ送信。
＜個人情報＞窓口にて口頭ならびに文書でセキュリティポリシーを実験モニターへ周知。
＜個人認証＞窓口にて本人を確認。
＜データ連携＞全ての手続きデータについて事業者側が受け入れることができた。
＜アンケート結果＞モニターに対するアンケート調査結果からは，手続き事業者拡大の意向が高いことがわかった。またすべてのモニターが有料でも利用すると回答した。一方，不動産
店舗のヒアリング結果では，代行サービス自体が主な収益源になる可能性は少ないものの，
内部業務効率化等でポータルサービスを活用できる可能性があることがわかった。
＜課題＞手続きに関する責任の所在を明確化すること。代行サービス（手続きポータル）のサ
ービス内容の充実化を図ること。
４）ビジネスモデルの検討① 札幌地域をモデルとした引越しポータル事業について検討した結果，関東・関西地域と同じ割合での利用件数では，地域の民間事業者が主体的に事業を継続的に運営できる可能性が低いと判断。サービスエリアの広域化ならびに代行サービス提供による利用件数増大を提示。
② 利用者を呼び込む方法として，地域情報ポータルサービスの開発を検討。ここでは引越
し前から引越し後までの利用者ニーズに対応するサービス内容を提供し，地域企業や団体の協賛や広告収入などを収入源として考えた。
③ 引越しポータルと地域情報ポータルの在り方について検討した結果，両者の一体的な運用や官民の枠組みという面から，協議会方式での運営とした。
④ ①～③までの結果を踏まえ，収支試算を行った結果，広域サービスの実現，ASP 提供（代行事業者の確保），参加企業数の拡大（より広範囲で簡易なサービス開発を前提に）などの条件をクリアすることで，3 ヵ年目には収支が均衡する結果を得た。
＜課題＞実用化を図るもの（地域情報ポータルの形成，ASP サービス実用化と代行事業者の獲得，全国型企業への働きかけとポータル間連携の実用化），実現可能性を検討するもの（住所移転通知サービスの開発，センター機能の開発・運用）。

15図３－１ 実証実験サイトの例（札幌官民連携引越し手続き実験サービス）
資料：http://sapporo1.sweb.co.jp/portalService/index.htm

16

４ 個人認証方法に関する検討
インターネットが急速に拡大した理由の一つは、ネットワーク利用者が匿名で様々なサービスを利用することが可能であったからである。しかしながら、官民に関わらず「手続き」というものは、利用者の権利・義務関係を設定するものであることから、インターネット上では、必ずしも不可欠とされなかった、本人確認、本人の同意、本人の所在、本人の所有関係といった、本人確認すなわち個人認証が必要となる。
官民連携ポータルは、官民の多様な手続きを一括して行うサービスを提供するものである
ことから、多様な主体が様々な手段で行っていた本人確認を、どのように扱うかが問題となる。
特に政府、地方公共団体においては、行政効率の確保、個人情報保護といった観点から民間の手続きサイトとの連携は慎重である。
本章では、個人認証に係る技術動向を概観するとともに、電子商取引分野、電子政府・電子自治体分野で行われている個人認証の実例を調査することにより、多数の主体を連携させる官民連携ポータルにおける個人認証のあり方について検討を行い、現時点で、官民連携ポータルに電子政府・電子自治体の手続きを連携する際の考え方をまとめた。
（１）検討の必要性と方法
１）検討の必要性
従来、官民の申請手続きは、窓口や、郵送、電話などで様々な厳重さのレベルで行われている。その際に必要な書類についても、実印、認め印、身分証明書の提示、署名、対面での確認など、本人確認の厳重さに応じて要求を変えている。このような手続きがネットワークに移行していく中で、公的個人認証サービスなどの電子証明書の確認、ＩＤ・パスワードの登録などの手段で本人確認を行っているのが現状である。
窓口での手続きの場合も、手続きの種別によって本人確認の厳重さが異なるのと同様、ネットワーク上での認証についても、手続きによって確定する権利義務関係の重要性、リスクの大きさ、事故等発生時の回復の容易さなど、手続きの種類によって、厳重な認証手段・手軽な認証手段を使い分ける必要がある。
ネットワーク上での認証については、ネット通販、ネットバンキングなど、民間サービスでの実績が蓄積されつつある。また行政サービスにおいても、電子申請・手続きのスタートにより、
公的個人認証サービス等による認証が始まっている。
しかしながら、手続きの性質による、本人確認（認証手段）の厳重さ（認証レベル）については、未だ、明確な関連付けが定まっておらず、申請受付事業者により、独自に判断されているのが現状である。官民連携ポータル事業を行う際には、申請受付事業者間の認証の違いを調整する時間とコストが負担になることが指摘されている。
２）検討のアプローチ
地方公共団体における個人認証の現状及び基本的な考え方、公的個人認証サービスの17

概要と、国や地方公共団体の手続きの対応状況などを整理するとともに、民間サービスにおける個人認証方法や、国内、海外のポータルにおける現状の認証方法などを整理し、官民連携ポータルにおける認証のあり方と課題について検討を行った。
また、実証実験において用いた方法とその理由、課題などもあわせて整理した。
なお、本検討会における議論の中で、官民連携ポータルについて、ビジネスモデルの点から、行政直営は適さないとの判断があった。そこで本章では、官民連携ポータルを民間事業者が運営することを想定して、個人認証に関する検討を行った。
また、認証技術やその利用については、急激に進歩、変化しており、今後とも適宜判断基
準を見直すことが必要である。

18

（２）現状１）行政機関等に対する電子申請・手続き等における認証方法の例
電子申請・届出を行っている地方公共団体における認証方法の一例を下表に示す。厳格な本人確認が必要な手続き（住民票の写しの交付請求、市・県民税納税証明書の交付請求、
固定資産評価証明書の交付請求など）では、公的個人認証サービス等を利用した電子署名が必要となっている。また、それほど厳密な本人確認を必要としない手続き（犬の登録変更
届、犬の死亡届など）や、別途、本人確認の機会がある手続き（水道使用開始届、水道使用中止届など）、もともと本人確認の必要がない手続き（公文書公開請求など）については、シ
ステム利用上必要となる ID/パスワードによる認証で可としている。
表４－１ 地方公共団体における電子申請・届出等の認証方法の例
地方公共団体名

オンラインで可能な電子署名が必要な

ID/パスワードに手続きの数（合計）

手続き数※

よる手続き数

岐阜県

153 件

109 件

44 件

大分県

101 件

81 件

20 件

岐阜市

32 件

24 件

8件

大分市

31 件

27 件

4件

※公的個人認証サービス（地方公共団体の認証局）、商業登記に基づく電子認証サービス（商業登記認証局）等による電子署名。
出所：各電子申請・届出サイトで確認（平成 17 年 6 月調査）

19２）行政機関等に対する手続きにおける電子署名の要否に関する基本的考え方
行政機関等に対する手続きについては、以下の理由から、一定の場合を除き、原則として
オンライン手続においては、電子署名が必要と考えられる。
①オンライン手続きの課題である成りすまし、改ざん、送信否認の防止には PKI（公開鍵基盤）による電子署名が有効である（ID・パスワード方式はフィッシングやパスワード漏えいのリスクあり）。
②手続きの多くに、保護すべき住民の個人情報・センシティブ情報が含まれる。
③電磁的記録の真正な成立の推定効を持つ電子署名には法的安定性あり（電子署名法第 3条）。
④全国どこに住んでいる人も安い費用で利用可能な基盤（公的個人認証サービス）が整備済。
⑤手続きを提供する地方公共団体に対しても、電子署名への対応方式を提示済（共通仕様）。
ただし、以下の理由のいずれかに合致する手続きについては、相対的に必要性が低く、電子署名を要しないとすることも許容される。なお、これらの手続きであっても、将来的に他システムとの統合等の場合には、団体としての統一的な管理の必要上、電子署名が必要となる。
表４－２ 電子署名を用いないことが許容される場合がある手続きの例
理由

手続き例

ア：性格上、本人確認の必要がない手 ・行政公文書の開示請求
続き
イ：別途利用時等に対面等で本人確認 ・職員採用試験受験申込みを行う手続き・各種講座参加申込み
・インキュベートルーム入居申込み
・青少年の家利用申込み
・親子でハイキング参加申込み
・手話通訳者派遣申込み
・保養施設利用券交付申請
ウ：重大な法律関係の変更等を伴わ ・水道使用開始届ず、仮に成りすまし等が生じても ・水道使用中止（廃止）届
権利関係の回復が容易な手続き ・犬の死亡届
・犬の登録変更届
・希望保育園変更・追加届
・人材バンク登録申請
・県政モニター応募
・競争入札参加資格審査申請書

20３）公的個人認証サービスの概要
成りすまし、改ざん、送信否認などのデジタル社会の課題を解決しつつ、電子政府・電子
自治体を実現するため、確かな本人確認ができる個人認証サービスを全国どこに住んでいる人に対しても安い費用で提供することを目的として、平成１６年１月２９日、公的個人認証サービスの提供が開始された。住民基本台帳カード等を用いて、各地方公共団体の窓口など
で電子証明書の発行を受けられる。電子証明書の発行手数料は 500 円、有効期間は 3 年である。

住民基本台帳
ネットワークシステム

都道府県単位認証局
署名検証者
都道府県単位認証局
都道府県単位認証局
指定認証機関への委任が可能
指定認証機関への→委任先：（住民の本人確認に活用）
指定認証機関への
異動等情報
委任が可能
財団法人自治体衛星通信機構
委任が可能
の提供
電子証明書の有効性確（ＬＡＳＣＯＭ）
全国サーバ／
失効
都道府県知事（ リス
認（失効リストへの問い
行政機関等
失失効
都道府県サーバ
都道府県知事合わせ）
証明書発行・失効情報（国・地方公共団体の機関等）
効リス
都道府県知事 （ ト
証明書発行・失効情報
リト（証明書発行・失効情報管理機関）
管理機関）
ス 総合行政ネットワーク（ＬＧＷＡＮ）等
管理機関）
本人確認情報ト
総合行政ネットワーク
公的個人認証の通知
民間認証事業者
サービス端末へ 総合行政ネットワーク（ＬＧＷＡＮ）
総合行政ネットワークの４情報の提供
コミュニケーション
市町村長（本…
市町村長（本人確認機関）
サーバ（ＣＳ）
人確認機関）
インターネット
市町村長
市町村窓口（本市町村窓口
人確認機関）
既存住基システム
電子証明書発行申請
電子申請等
電子証明書交付（基本４情報＋公開鍵）

住住民基本台帳カード等への秘密鍵・
電子証明書の記録

申請書等
（平文）

民

電子署名
電子証明書
（申請書等を住民の＋ 秘密鍵で署名） ＋ （住民の公開鍵付）＋＋

住民基本台帳カード
写真○○市
2013 年 8 月 31 日まで有効

20 mm
×16 mm

生年月日
氏
名

昭和 ○○ 年 ○月 ○○ 日 性別 女
住基 花子

住

○○県○○市 ○○町○丁目○番○号

所

図４－１ 公的個人認証サービスの概要
また、一定の要件を満たす民間認証事業者は、オンラインショッピング会社等からの電子証明書の有効性確認の請求に対応するため、公的個人認証サービス側に公開鍵証明書の有効性を確認することによりその失効等の事態（死亡、住所移転等）を把握し、失効リスト（CRL）を更新することができる。
公的個人認証サービスは、（ア）公開鍵暗号方式という高度な暗号技術に基づいて行われること、（イ）鍵ペアの作成が、利用者本人の操作によって市町村窓口の専用装置を用いて行われ、作成された鍵ペアは耐タンパ性を有するＩＣカード（住基カード）に厳重に格納されるなど、公的個人認証サービスでは公開鍵暗号方式の鍵ペアを生成・格納する環境の信頼レベルが極めて高いこと、（ウ）住民基本台帳に登録された情報に基づき電子証明書が発行されるため、電子証明書の信頼性が非常に高いことなど、極めて安全性・信頼性の高い電21

子認証サービスとして主にオンラインでの行政手続きにおいて活用されている。

民間
注文書

利用者

＋

電子証明書

オンラインショッピング会社⑥ オンラインショッピング（注文）⑨ 商品発送⑦ 民間電子証明⑤ 民間電子証明書を発行

書の有効性

民間
電子証明書

の確認

申請書

公的

＋ 電子証明書
電子証明書
民間認証事業者（認証業務を実施）③ 公的電子証明書の有効性の確認
本人審査時

回答（有効）

公的
電子証明書⑧ 回答（有効）

インターネット銀行等④ 回答（有効）① 公的電子証明書の発行② 電子証明書発行申請

公的電子証明書の有効性の確認失効リスト更新のために必要な時の本人確認

公的個人認証サービス

図４－２ 民間認証事業者による公的個人認証サービスの利用イメージ

22４）公的個人認証サービスの普及に向けた取り組み
公的個人認証サービスの電子証明書発行件数は、平成 18 年 2 月末で 12 万 7 千枚余となっている。そこで、総務省では公的個人認証サービスの普及を促進するため、その利用範
囲の拡大に取り組んでいる。
まずは、国や地方公共団体における公的個人認証に対応した電子申請の対象手続きの拡大である。平成 18 年 2 月現在、国の 11 府省庁、45 都道府県、24 都府県内の市町村（うち、全ての市町村が対応しているのは 4 県のみ）で公的個人認証に対応したシステムが整備されているが、ＩＴ新改革戦略では、全都道府県において 2008 年度までに、全市町村において 2010 年度までに公的個人認証サービスに対応した電子申請システムを整備するという目標が明記されている。
次に、公的個人認証サービスの電子証明書の有効性を確認できる者の範囲については、
行政手続きを受ける行政機関等のほか、司法書士、行政書士など行政手続きの代理を行う者や公証人、医師など行政手続き等に必要な添付書類を発行する者が、連合会等の所属団体を通じて電子証明書の有効性を確認できるようにする法律の改正案を国会に提出しており、現在審議中となっている。
また、金融機関の口座開設時等における本人確認に公的個人認証サービスが利用できるよう、昨年 10 月に金融機関等本人確認法及び外国為替法の省令を改正したところである。
さらに、総務省の平成 18 年度地方行財政重点施策においては、電気、ガス、医療など公益的な分野へ利用範囲を拡大することを検討するとされており、個人情報保護に配慮しつ
つ、公的個人認証サービスの民間利用に向けた検討が始まっている。
加えて、こうした各種オンライン手続きにおける活用のほか、公的個人認証サービスの多面的な活用方法（電子ロッカー、電子錠、地域通貨システム、電子アンケートシステム、情報システムの職員認証（シングルサインオン）システム等）についても開発実証に取り組んでいる。

23５）民間サービスにおける認証方法の例
インターネットを用いた各種民間サービスでは、様々な認証方法が用いられている。下表はその一例である（比較のために公的個人認証など行政手続きも記載）が、認証のレベルについては、認証が厳格な順に、「第三者が認証する場合」「当事者間の認証」「当事者間の認証を行わない場合」の 3 つに大別できる。
第三者が認証する例としては、公的な認証基盤や民間の認証基盤の活用や、クレジットカ
ードにおける与信照会などが挙げられる。これらは、IC カードとネットワークで、登録センターにいつでも認証を要求することができる仕組みである。また、クレジットカードなどでは、不審な購入実績については、個々に電話でカード保有者に確認するなどの手段を講じて、安全性を確保している。
当事者間で認証する例としては、予め登録した内容（ID、パスワード等）との照合による認証である。これは、初期登録した ID とパスワードで本人性を確認するものであり、スキミングやスパイウェア、フィッシングによって ID、パスワードが盗まれた際には、なりすましによって被害にあう可能性がある。ＩＤ・パスワード方式については、一見簡便なように見えるが、特に複数ある場合に管理が困難になることや、最近はフィッシングやスパイウェアの脅威も増していることに留意が必要である。
一方、登録不要の掲示板への書き込みや、メールマガジンの受信においては、特に認証は行われない。この場合であっても、メールアドレスの登録を行うことが通常であり、利用料を必要とするプロバイダ発行のメールアドレスは有効であるが、利用料を必要としない匿名が可能なフリーメールでは申し込みを受け付けないものも存在する。
また、ウェブ上での認証だけでなく、申請したメールアドレスへの送信や住所への郵送など、他の手段を組み合わせることにより本人確認性を高める工夫をしている例も多い。

24

表４－３ インターネットを用いた各種サービスの認証方法の例
認証レベル

事例

本人確認方法（例）第 三 者 に よ る 公的な認証基盤を用いた行政手 住基カード等＋電子証明書＋パスワード
認証
続き（電子申請）
民間の認証基盤を用いた行政手 電子証明書＋パスワード
続き、民間手続き
クレジットカードを用いた支払い
カード番号＋有効期限＋与信照会（＋本人への利用明細の送付）
当事者間の認 ネット証券
認証方式（セキュリティコード方式、電子証
証（初期登録明書方式）を利用者が選択できる。
内 容 と の 照 合 ネットバンキング
ID＋生体認証・パスワード＋第２パスワードを行う）
会社のパソコンや社内ネットワー IC カード＋生体認証・パスワード
クへのログインネットオークション
ID＋パスワード（＋評判システム＋エクスロ
ー決済）
パスワードを忘れた場合の再取得 予め設定した質問（ペットの名前など）への回答＋メールアドレスへの通知
掲示板への書き込み（登録、ログ ID＋パスワード＋本名による発言＋ログのインが必要）
保存など
当事者間の認 掲示板への書き込み（登録、ログ 匿名、ログの保存
証なし
インが不要）
メールマガジン

登録したメールアドレスへ送付

25６）官民連携ポータル事業者における認証
国内及び海外の官民連携ポータル事例における認証方法を下表に示す。
国内の 3 事例においては、ポータル側では住所、氏名などの入力を行い、これを申請受付事業者のサイトへ送る際に、それぞれの事業者が必要に応じた認証を行っているのが現状である。
また、I am moving.com の場合も、最初に氏名等を登録するが、ここで特に本人確認を行う訳ではなく（あくまでも自己申告）、個々の手続き先で本人確認を行っている。
表４－４ ポータル事例における認証方法の例
事例

認証方法

引越れんらく帳・連携事業者の個別ポリシーで実施

関西引越し手続きサービス

・ポータル側での本人確認は無し
・引継ぎ先の各事業者サイト上での確認（方式は各事業者毎に行う）

札幌地区目的指向ポータ ・各手続きサイトの方法による
ルモデル（実験）・北海道電力、水道局：電話受付と同様
・北海道ガス、三ッ輪商会：受付後事業者から電話確認
・札幌市：印刷した申請書を本人が窓口で提出

I am moving.com（英国）・最初に、氏名、電話番号、E メールアドレス、パスワードを登録する。以降は、E メールアドレスとパスワードにより自分のアカウ
ントへのログインを行う。
・団体によっては、顧客番号などの追加情報を入力する必要があり、これらの追加情報により認証を行っていると考えられる。
・誤情報の送信は、 Computer Misuse Act（1990）に抵触すると記載している。

出所：国内事例については各事業者へのアンケート調査による。海外事例については、ウェブ上の記載事項等をもとに作成。

26

（３）実証実験における個人認証方法と課題
１）ポータルにおける個人認証
今回の実証実験に参加した引越れんらく帳、関西引越し手続きサービスでは、ともにこれまでもポータルでの個人認証は行っていなかったので、今回の実験でも、ポータルでの個人認証は行わず、すべて各手続きサイト側で確認が行われた。
※引越れんらく帳では、30 日間データを保持できる「マイれんらく帳」機能があるが、これは手続き途中などでデータを一時保存するためのものであり、手続き上の本人確認を行うものではない。
２）各手続き先における認証
引越れんらく帳や関西引越し手続きサービスの提携先事業者は、従来どおりの方法でお客様の確認を行った。主な方法としては、お客様番号などの利用者固有の番号による確認（電力、水道など）や、加えて ID、パスワードの登録、確認（クレジットカードなど）だが、引越し当日立会いなどが必要なため特にウェブ上での手続きでは特に本人確認は行わない（ガスなど）場合もある。
３）札幌官民連携引越しポータルにおける認証
札幌官民連携引越しポータルでは、あらかじめモニター登録した上で、実験センターのオ
ペレータが利用者から電話で引っ越し手続きに必要な情報を聞き取り、ポータルへの登録、送信や、受付確認の連絡などを行った。

27

＜ ①モニター 参加申し込み ＞ 引っ越し日の１０日以前（ モニター募集期間内で、引っ越しの１０日以前であれば申し込みできます。）
実験センターへ電話でお申し込みください
実験の手引き等の郵送に必要な、お名前・ご住所をお聞きします
引越し手続
受付実験センター

実験の手引き、アンケート票を郵送します

実験モニター

・①の資料が届いたら、引越し予定日の 5 日前を目処に，実験センターのオペレータが実験モニターに電話し、引越し手続きに必要な情報を聞き取り、紙に記録。

＜ ② 引越し手続き申し込み ＞ 引っ越し日の５日以前（ モニターとなられた方は、実験期間内であれば、手引書が届きしだい手続き申し込みができます。
手続き申し込みは、引っ越しの５日前までにお済ませください。）
実験センターへ電話でお申し込みください

必要

引越し手続きに必要な、お名前・ご住所などをお聞きします

実験モニター※あらかじ め郵送され た手 引きの内 容を確認し ていただき、必 要書類を ご用意 ください

手引き

＋ 書類

引越し手続
受付実験センター・②で記録した内容をもとに、実験センターのオペレータが札幌ポータルを用いて入力、送信。都市ガスについては，届出様式（必要事項記載済み）を印刷し、実験センター
から事業者へ FAX で送信（手動）。札幌市の届出については届出様式（必要事項記載済み）を実験センターから実験モニターへ郵送。
・電気、水道については事業者からの受付通知電子メール、都市ガスについては事業者からの受付確認 FAX をもとに、その旨を実験モニターに連絡。

＜ ③ 最終手続き ＞
転居届
転入届
転出届

電気
水道

実験モニター
転居届
転入届
転出届
印

都市ガス

転居届・転入届・転出届のうち該当する書類を郵送します

引越し手続
受付実験センター

新聞

・札幌市外へ転出する場合は、お送りした書類に押印し、現在お住まいの住所の区役所窓口へ提出または郵送してください。
。
・札幌市内での転居、札幌市へ転入の場合は、引っ越し後１４日以内に、新しくお住みになる住所の区役所窓口へ提出してください。

図４－３ 札幌官民連携引越しポータルにおける手続きの流れ

28

関係機関

（４）官民連携ポータルにおける個人認証のあり方
１）現状
現状の官民連携ポータルでは、以下のような個人認証方法が多く用いられている。
【民間手続き】「引越れんらく帳」や「関西引越し手続きサービス」では、ポータル上で必要な手続きの選択と共通情報（氏名、現住所、電話番号、引越し先住所など）の入力を行い、以降の手
続きは、各サイト上で行う。従って、個人認証も、各サイトがそれぞれの方法で行う。
★認証方法：各サイトが定める認証方法（ID・パスワード、お客様番号など）【行政手続き】行政手続きについては、水道など一部を除きポータルとの連携は進んでいない。
★認証方法：各サイト（水道など）が定める認証方法（お客様番号など）【利用者の主なメリット】
引越し時に必要な手続き（一部）を検索し、手続きサイトにアクセスできる。
どの手続きにも必要な共通情報の入力が一回で済む。
各手続きの進捗状況が確認できる。
【主な課題】
手続きの数が増えると、その分手間が増大する。
現状では、行政手続きはほとんど対応していない。

共通情報入力（住所、氏名、電話番号など）

共通情報
官民連携ポータル

利用者

認

民間手続Aのサイト

共通情報
認

民間手続Bのサイト

共通情報
認 民間手続Cのサイト

行政手続

認

・手続は各サイトで行う。
・共通情報は入力済みなので、個別手続に必要な情報を追加入力する。
・お客様番号等による本人確認。本人
確認方法は、各サイトにより異なる。
・手続によっては、共通情報の受渡しができないものもある。

・現状では、水道等の一部手続を除き、ポータルとの連携は進んでいない。

途中保存、手続状況確認のため、最初に登録番号等を取得し、本人確認。
DB

図４－４ 官民連携ポータルの現状（引越ポータルの場合）

29２）今後の方向①リンクによる連携と共通情報の受渡し（行政手続への拡大）【民間手続き】基本的には現状と同じで、ポータルでは必要な手続きサイトの検索、リンクと、共通情報の入力、受渡しのみを行い、本人確認を含む手続きは各サイトで個別に行う。現在、共通情報の受渡しが実現できていない民間手続きサイトにも拡大する。
★認証方法：各サイトが定める認証方法（ID・パスワード、お客様番号など）【行政手続き】ポータルにおける検索、リンク及び共通情報の受渡しを、行政手続きまで拡大する。本
人確認を含む手続きは各サイトで個別に行う。
★認証方法：各サイトが定める本人確認方法（公的個人認証、ID・パスワードなど）【利用者の主なメリット】
現状のメリットが、行政手続きまで拡大される。
【主な課題】
ポータルと各手続きサイト間で、共通情報の受渡しを行う場合には、特に手続きサイト側の対応（システム面での対応など）が必要となる。
行政手続きまで拡大するための、ポータルと各地方公共団体間の調整が必要。ポータルが全国約 2,000 の地方公共団体とそれぞれ個別に調整するのは物理的にも難しく、共同アウトソーシング等の形で調整先を統合することが望まれる。

共通情報入力（住所、氏名、電話番号など）

共通情報
認

民間手続Aのサイト

共通情報
官民連携ポータル

利用者

認
共通情報
認

民間手続Cのサイト

共通情報
認

公的個人認証

民間手続Bのサイト

行政手続Aのサイト

・ID・パスワード等で可能な手続（サイト上でID・パスワード等を入力）

共通情報
認 行政手続Bのサイト

図４－５ 行政手続きへの拡大

30

・公的個人認証等が必要な手続（サイト上で電子署名等）

②官民それぞれを出来るかぎりワンストップ化【民間手続き】民間手続においては、個別情報もポータル上で入力し、一括手続を可能にする。
一部の手続きについては、ポータルでのシングルサインオンを実現（各手続での認証を不要に）。ポータルのシングルサインオン以外の認証方法を用いる場合は、各サイト上で認証を行う。
★認証方法：
・ポータルおよびポータルの認証を用いるサイト：シングルサインオン（ID・パスワードなど）
・各サイト：各サイトが定める認証方法（ID・パスワード、お客様番号など）【行政手続き】行政手続に関しては、行政ポータル上でのワンストップ化を図る。行政ポータルとしては、
各地方公共団体のサイトや共同アウトソーシングサイトなどが考えられる。
官民連携ポータルから、共通情報を受け取ることで、入力の手間を省く。
手続きに必要な個別情報などを行政ポータル上で一括して入力。
各手続きに必要な認証について、ポータル上で一括して行う。同一地方公共団体サイト内や共同アウトソーシングサイトなど、同一システム上での運用の場合、シングルサインオンなどに対応しやすい。
★認証方法：
・ポータルおよびポータルの認証を用いるサイト：シングルサインオン（ID・パスワードなど）
・電子証明書等が必要なサイト：ワンクリックで必要な数だけ電子署名、電子証明書の添付を可能にする。
・その他のサイト：各サイトが定める認証方法（ID・パスワードなど）【利用者の主なメリット】
ワンストップではなく民間手続きと行政手続きのツーストップになるが、現状よりは大幅に利便性が高まる。
【主な課題】
民間手続きにおける個別情報入力も含めたワンストップ化、シングルサインオンおよび、
行政手続きポータルの実現が必要となる。
ポータルが ID・パスワードなどを用いてシングルサインオンを実現する場合、ID・パスワードなどを発行・管理する業務が生じるほか、シングルサインオンを利用する手続き先のサイトに対しても、ポータルとして保証する必要が生じる。ポータル側が厳格な管理を行わないと、信用が得られず、シングルサインが実現しない。この負担は、ポータルのビジネスモデルの成立を考える上でも課題となる。対応策としては、既に ID・パスワードを発行している主体（プロバイダー、ネットショッピングサイト、会員向けサービスサイトなど）がポータルを運営したり、外部の認証（公的個人認証や民間認証など）を用いることが考えられる。

31

共通情報
＋
個別情報入力認

シングルサインオン（ID・パスワード、電子署名など））共通情報および認証

認

民間手続Aのサイト

共通情報および認証

民間手続Bのサイト

民間手続Cのサイト（ポータルと異なる認証の場合）

認
認
共通情報

行政ポータル

公的個人認証官民連携ポータル

利用者

共通情報のみ・ポータル上で、各手続個別に必要な情報も入力し、一気に手続。
・ポータルの認証（ID、パスワー
ド、電子署名など）とのシングル
サインオン化。
・ポータルと異なる認証を行うサ
イトは、各サイト上で個別に認証（オンラインバンキングなど）。

共通情報および認証

行政手続Aのサイト

共通情報および電子証明書等

共通情報および電子証明書等認

行政手続Bのサイト

行政手続Cのサイト
認
共通情報（入力済み）＋
個別情報入力電子証明書（ワンクリックで必要手続きの数だけ添付）認

シングルサインオン（ID・パスワード、電子署名など）

図４－６ 官民それぞれを出来るかぎりワンストップ化

32

③ワンストップ化【民間手続き】ポータル上で、各手続き個別に必要な情報も入力し、一度で手続きを完了する。
ポータルと各手続きのシングルサインオンを実現。
電子証明書等もワンクリックで必要な数だけ添付。民間でも活用。
ポータルと異なる認証を行うサイトは、各サイト上で個別に認証を行う（オンラインバンキ
ングなど）。
★認証方法：
・ポータルおよびポータルの認証を用いるサイト：シングルサインオン（ID・パスワードなど）
・電子証明書等が必要なサイト：ワンクリックで必要な数だけ電子署名、電子証明書の添付を可能にする。
・その他のサイト：各サイトが定める認証方法（ID・パスワードなど）【行政手続き】ポータル上で、各手続き個別に必要な情報も入力し、一度で手続きを完了する。
ポータルと各手続きのシングルサインオンを実現。
電子証明書等もワンクリックで必要な数だけ添付。
ポータルと異なる認証を行うサイトは、各サイト上で個別に認証を行う。
★認証方法：
・ポータルおよびポータルの認証を用いるサイト：シングルサインオン（ID・パスワードなど）
・電子証明書等が必要なサイト：ワンクリックで必要な数だけ電子署名、電子証明書の添付を可能にする。
・その他のサイト：各サイトが定める認証方法（ID・パスワードなど）【利用者の主なメリット】
ほぼワンストップで、民間手続き、行政手続きをあわせた必要手続きを行うことができる。
【主な課題】
行政手続きにおいて公的個人認証サービスを用いる場合は、官民連携ポータルで失効リストの確認を可能にするなど、現行法制度（公的個人認証法）の改定が必要となる。
②の場合は、行政ポータルと各行政手続きサイトが、同一地方公共団体内、あるいは共同アウトソーシングによる同一システム内であるため、システム間連携（複数手続きのワンストップ化やシングルサインオンなど）を比較的行い易いが、官民連携ポータル（民間事業者が運営）と各行政手続きサイト（地方公共団体が運営）に分かれると、対応が難しくなる。
民間手続きにおいて公的個人認証サービスを用いる場合は、上記に加え、民間手続きサイトで失効リストの確認を可能にするなど、現行法制度（公的個人認証法）の改定が必要となる。官民連携ポータル事業者などが発行する民間電子証明書を用いる場合は必ずしも制度を改正する必要はない。ただし、民間事業者が電子証明書を発行する場合の本
人確認に公的個人認証サービスを利用する場合、現行制度では、認定認証事業者等しか利用を認められておらず、他の民間事業者が利用するためには、制度改正が必要であ33

る。
また、②同様、シングルサインオンのために、ポータルで ID・パスワードなどの発行、管理を行う場合は、その負荷が生じる。

共通情報（入力済み）＋
個別情報入力電子証明書（ワンクリックで必要手続きの数だけ添付）認

シングルサインオン（ID・パスワード、電子署名など）共通情報および認証

民間手続Aのサイト

認
共通情報および認証

民間手続Bのサイト
共通情報のみ公的個人認証官民連携ポータル

利用者（ポータルと異なる認証の場合）

認

民間手続Cのサイト

共通情報および電子証明書等

民間手続Cのサイト
認
共通情報および認証

行政手続Aのサイト
共通情報および電子証明書等

共通情報および電子証明書等

認

行政手続Bのサイト

認 行政手続Cのサイト

図４－７ ワンストップ化

34

・ポータル上で、各手続個別に必要な情報も入力し、一気に手続。
・ポータルの認証（ID、パスワード、
電子署名など）とのシングルサインオン化。
・電子証明書等もワンクリックで必要な数だけ添付。民間でも活用。
・ポータルと異なる認証を行うサイ
トは、各サイト上で個別に認証（オンラインバンキングなど）。

３）個人認証の課題のまとめ①システム面の課題
手続き数が多くなるほど、個人認証を個別に行うのではなく、信頼性の高い認証方法でワンストップで行うことができるほうが、利用者の利便性は高い。公的個人認証サービスを用いて、個人認証をワンストップ化できれば、認証の手間は大幅に軽減されるが、公的個人認証
サービスの普及や、民間などへの活用範囲の拡大など、解決すべき課題もある。
また、現在の行政機関の電子申請・届出や民間企業の電子的な手続きは、利用者本人による利用を想定しており、個人認証についても、利用者本人が直接手続きを行うこと（あるいは代理人による手続き）を前提としている。従って、ポータル事業者が個人認証を一括して行うことは、現在の仕組み上は難しい面が多い。
手続きの際の個人認証をワンストップ化するためには、
１）電子署名や ID・パスワードなどによる個人認証のシングルサインオン化
２）各申請手続受付事業者への電子証明書送付などの個人認証の手順をポータル上で自動化等の方策が考えられるが、現状では、各申請手続き受付事業者は個別にそれぞれの方法で個人認証しており、このような共通での個人認証や自動化対応などを想定していない。対応には、ポータル経由での受付を想定したシステム構築（※）や、制度の整備が必要となる。
また、個人認証に限らず、ポータル事業者が申請手続き受付事業者と交渉する際、行政手続きについては、現状では 2,000 以上の個別地方公共団体との調整が必要となる。これは現実的には困難であり、例えば都道府県単位で共同アウトソーシング化により、47 箇所との調整で済むなどの対応が求められる。
（※）このようなシステムの基盤構築の一環として、全国地域情報化推進協議会によりウェブサービスを基礎としたサービス連携基盤仕様「地域情報プラットフォーム」の標準化活動が進められており、またそれに必要な技術開発が（独）情報通信研究機構により行われ
ている。
【現行】
手続

行政機関や企業など【ワンストップ化】
行政機関や企業など
手続

ポータル
事業者

行政機関や企業など
行政機関や企業など※ ポータル経由での受付を想定したシステム構築、制度づくりが必要

図４－８ 個人認証の課題

35

②制度面の課題
前述のように、公的個人認証サービスなどの、安全性・信頼性の高い電子認証（電子署名・電子証明書）を積極的に活用し、国民の権利義務や財産に大きな影響を及ぼす手続きの電子化や、手続きにおける個人認証のワンストップ化を進めていく方向が望ましいと考えられるが、民間手続きにおいて、公的個人認証サービスの利用を可能とするためには、制度改正が必要である。
官民の各種手続きのワンストップ化を実現するため、個人情報保護に配慮しつつ、官民ポータルの主要な受付事業者となることが想定される公益事業者を中心に、公的個人認証サービスの利用範囲の拡大について検討することが適当と考えられる。

36

５ 個人情報保護に関する検討
官民連携ポータル実現のための主要課題のひとつである個人情報保護について、検討の必要性と方法、現状、課題及びあり方等の検討を行う。

（１）検討の必要性と方法
１）検討の必要性
官民連携ポータルが実現することにより、利用者にとっては、多数の主体に関わる手続き
を、サイト上で一度に済ませることができるようになり、従来の手続きの手間を大幅に省くことが可能となる。官民連携ポータルによって、このような利便性の向上が図られる一方で、多数の主体が利用者の個人情報をやり取りすることになることから、個人情報の取扱いについては、厳格な対応が必要となる。とりわけ、平成 17 年４月からは、「個人情報の保護に関する法律」（以下、「個人情報保護法」）が全面施行されており、また、個人情報の保護に対する国民の意識が高まりを見せている中で、今後官民連携ポータルを順調に発展させていくためには、個人情報について適切な保護措置が講じられ、利用者が安心して利用できる仕組みを構築する必要がある。
現状、このような多数の主体が個人情報を取り扱う場合のルールや仕組み等が明確になっていないことから、これらのルール化等について検討を行う必要がある。
２）アプローチ方法
地方公共団体における個人情報保護に関する現状調査および、ポータル事例及び海外事例等におけるウェブからの個人情報取得・活用の際の対応方法の調査等を行い、個人情報取扱いに関するあり方の検討を行った。
また、実証実験において用いた方法とその理由、課題などもあわせて整理した。

37

（２）現状１）個人情報保護法制の体系
平成１７年４月に全面施行された個人情報保護法では、個人情報保護に関する官民を通じた基本理念、国・地方の責務等を定めるとともに、民間の事業者が保有する個人情報の取り扱いについて遵守すべきルール等を定めている。また、国の行政機関や独立行政法人については、それぞれ個別の法律により、また、地方公共団体については、それぞれが個人情報保護条例を制定し、個人情報の適正な取り扱いを確保することとなっている。

平成１６年
施 行 令

個人情報の保護に関する法律（５月２３日成立）
第１章～第３章
・基本理念

・国、地方公共団体の責務
・基本方針の作成

図５－１ 個人情報保護法施行のスケジュール
資料：総務省38

行

事業等分野のガイドライン

１２月１０日

H17/4/1
施令

布

個人情報取扱事業者の義務等

公布後２年以内（政令で定める日）政第４章～第６章

公（民間分野）

平成１７年

４月２日
個別分野の格別の措置等の検討

・国、地方公共団体の施策

１２月１０日

公布・
施行

・目的

５月３０日

個人情報の保護に関する基本方針
（
閣議決定）

平成１５年

基本法制①
・基本理念
・国・地方の責務
・基本方針の策定 等((

行政機関法制②

個別法

個人情報取扱事業者の義務
等

条例
団体
公共
制
地方
等法
法人
③
行政
独立

≪民間部門≫ ≪公的部門≫))

個人情報保護関連五法①個人情報の保護に関する法律（基本法と民間部門の一般法）
以下、公的部門（国の行政機関等）②行政機関の保有する個人情報の保護に関する法律③独立行政法人等の保有する個人情報の保護に関する法律④情報公開・個人情報保護審査会設置法⑤行政機関の保有する個人情報の保護に関する法律の施行に伴う関係法律の整備に関する法律

図５－２ 個人情報保護法の体系
資料：総務省39２）地方公共団体の取組み状況
個人情報保護条例については、平成 18 年 1 月１日現在、都道府県は 100%、市区町村
は 99.8%で制定済みであり、平成 17 年度中には全ての地方公共団体で制定される見込みである。
また、それぞれの地方公共団体における情報セキュリティ対策の基本方針となる情報セキュリティポリシーの策定状況については、都道府県は 100%、市区町村は 95.1%であり、ほぼ全ての団体で策定済みとなっている。

100%
90%

都道府県(47)
都道府県(47)
100%

100% 100% 100%

100% 100% 100%

78.8%

82.1%

82.8% 83.8% 85.8%

80%
70%
60%
50%

100% 100%
100%

76.7%
73.6% 75.1%

100% 100%99.8%
98.0% 98.9% 99.6%（2,070団体）

市区町村(
市区町村(2,075)
075)

40%
30%
20%

都道府県

10%

市区町村

0%
Ｈ15年4月

7月

10月

Ｈ16年1月

4月

7月

10月

H17年1月

4月

7月

10月

Ｈ18年1月

図５－３ 個人情報保護条例の制定状況（平成 18 年 1 月 1 日現在）
資料：総務省100%

都道府県(47)
都道府県(47)

90%

93.6%

80%
70%
60%

80.9%

100%

85.1%

市区町村(
市区町村(2,075
2,075))

50%

100%

100%

78.1% 80.8%

82.6%

97.9% 97.9% 100%

100% 100%

100%

95.1%
92.5% 93.7% 94.0%（1,974団体）

74.4%

56.3%
49.6%

40%
30%

35.5%

20% 29.5%

都道府県

10%

市区町村

0%
Ｈ15年4月

7月

10月

Ｈ16年1月

4月

7月

10月

H17年1月

4月

7月

10月

Ｈ18年1月

図５－４ 情報セキュリティポリシーの策定状況（平成 18 年 1 月 1 日現在）
資料：総務省40

３）官民連携ポータル事業者の個人情報の取得・利用
ウェブ上で電子申請として個人情報を取得し、利用する場合、地方公共団体については、
個人情報の取得目的、取得範囲、利用範囲、第三者への提供制限、委託先における保護措置、罰則の適用など、それぞれの個人情報保護条例等を踏まえ、利用者に対して個人情報の保護措置を明らかにすることが求められる。また、民間事業者等においても、サイトのプ
ライバシーポリシー等に沿って、同様の対応が必要となる。
下表は、取り組み事例として取り上げたポータル 3 事例における個人情報取り扱い方法である。官民連携ポータル事業者が個人情報を蓄積せずに申請受付事業者に引き渡す場合、サービスを充実するため一定期間ポータル事業者が個人情報を保管する場合がある。
また、次ページ以降の表は、行政サイト、民間サイト等において個人情報取得時の利用目的等に関する記載方法の例である。
表５－１ ポータル事例における個人情報の取り扱い方法
事例

利用に当たっての利用者の同意事項

データ保持方法

その他、個人情報取扱いに関する留意事項など

ポータルサイトに接続 －し、手続きを行ってい
る時間中のみ保持し、手続きが完了した時
点で情報を破棄する。
－
札幌地区目的指向ポ ウェブ上に利用規約を 無し
ータルモデル（実験）
準備し同意いただく。
「個人情報保護法に基づく一切の情報は取り扱わず、入力内容に関する情報は直接事業者とやり取りされます。個人情報の取扱い、問い合わせについては直接事業者と行うものとします。」
引越れんらく帳
サービス利用規約。
サーバ内に期間限定 当該サービスサイトのプラで保持。
イバシーポリシーを策定。
個人情報管理責任者の設置。個人情報取扱者を限定。個人情報保持期間を限定など。
関西引越し手続きサ 手 続 き を 行 う 事 業 者ービス（＝個人データを引き渡してもよい事業者）
を利用者側が選択。

資料：各事業者へのアンケート調査による。

41

表５－２ 個人情報の取り扱いに関する記載例
ケース

事例

記載内容（抜粋）

個人情報をポ 関 西 引 越 し 手 ・本サービスでは、住所、氏名、連絡先などの個人情報を入力し、手続きを行います。入力された情報は、本サービスを利用していータルに蓄積 続きサービス
しない場合
る間は、一時的に保持しますが、保存することはありません。利
用を終了した時点で、情報は破棄されます。
個人情報をポ 引越れんらく帳 ・当サイトにおける個人情報の取得は、当サイト上で提供するサーータルに蓄積ビスの充実ならびに円滑な提供（提携事業者によるサービスのする場合
提供を含む）および当サイトの円滑な運営を目的とし、その目的の達成に必要な範囲内で行います。
・取得した個人情報は、取得目的の範囲内で利用し、これらの目的以外で利用する場合には、利用者に対し事前に確認または同意を求めます。
個人情報を取 札 幌 市 コ ー ル ・札幌市コールセンターでは、基本的にお客様の個人情報は取得しない場合 センター
得・記録いたしません。
・折り返し電話をご希望の場合は、連絡先として以下の個人情報を一時的に記録させていただくことがあります。
・弊社は、下記のとおり、お客さまの個人情報を共同利用いたしま
個人情報を共 東京ガス
同利用する場
す。なお､共同利用させていただくにあたっては、公正競争の確合保に十分配慮いたします。
・共同して利用するお客様情報（以下略）・共同利用する者の範囲（以下略）・共同利用する者の利用目的（以下略）・上記お客さま情報の管理責任者（以下略）地方公共団体 東 京 電 子 自 治 ・サービス提供自治体は、個人情報保護関連法令･例規に基づで共同運用す 体 共 同 運 営 サ
き、個人情報の保護を行います。サービス提供自治体は、個人
ービス
る場合
情報保護関連法令･例規等で定める場合を除き、個人情報の目的外利用を行うこと及び、サービス提供事業者以外の第三者に個人情報を提供することは一切ありません。
・サービス提供事業者は、個人情報保護関連法令・例規等及びサービス提供自治体との委託契約において定める個人情報についての守秘義務等について遵守し、共同運営サービスの運用にあたります。
・利用者が共同運営サービスを利用してサービス提供自治体へ送
信又はサービス提供自治体から利用者へ送信する個人情報
は、データの暗号化によって保護されます。
・個人情報保護関連法令･例規等の規定に違反して保有する個人
情報を漏らした者には、法令等に基づく罰則を適用します。

42

ケース

事例

記載内容（抜粋）

地方公共団体 東 京 都 公 式 ホ ・個人情報の収集・利用・管理について、「東京都個人情報の保護における個人 ームページ
に関する条例」に基づき、次のとおり適切に取り扱うとともに、皆様
情報取扱いに安心して利用していただけるホームページづくりに努めていきます。
・本サイトを通じて東京都が個人情報を収集する際は、利用者ご本
人の意思による情報の提供(登録)を原則とします。
・皆様から提供(登録)いただいた個人情報は、あらかじめ明示した収集目的の範囲内で利用いたします。個人情報の収集目的を越えた当該実施機関内における利用及び当該実施機関以外の者
への提供は、個人情報保護条例で定める場合を除き、一切いたしません。
大 阪 府 電 子 申 ・個人情報の収集、利用、提供及び管理等について、個人情報の請・手続き案内 保護に関する法律及び大阪府個人情報保護条例（以下「条例」とサービスいう。）を遵守するとともに、個人情報が漏洩したり滅失することのないよう、次のようなセキュリティ対策を講じています。
・収集した個人情報の利用は、条例の規定に基づき、申請手続きにおいてのみ利用し、目的外の利用を禁止しています。
・システムを利用する大阪府の職員については、ユーザ ID・パスワ
ードを発行し、システムの利用を認められたもの以外はアクセスできない（以下略）。
・システムの保守管理を委託している事業者については、大阪府との委託契約書において、個人情報の保護に関する規定を明記（以下略）。
I am
海外事例
・住所変更を届け出た団体以外には、住所等の情報を開示しない
moving .com
ことを約束している。ただし、「ある期間内にガスの住所変更を行った人が何人いたか」といった総計としての情報は、マーケッティ
ングなどの目的に使用することがあるとしている。
・また、ピザ無料キャンペーンのようなプロモーションの際に情報を開示する場合がある（その際には、その旨を必ず明記する）。
・ イ ン ター ネッ トで の 通信に は 、 SSL を 用い ている 。 Moving
Technologies Limited 社内での取扱いについても、厳密な管理を行っている。
資料：各事例のサイト上の掲載内容より抜粋。

43

（３）実証実験における個人情報の取り扱い方法と課題
今回の実証実験では、引越しポータル間での個人情報の受け渡しを行った。例えば、関西引越し手続きサービスから、引越れんらく帳に個人情報を受け渡す際の画面の展開は、次ページ以降の通りである。
最初に、関西引越し手続きサービスでは、個人情報を保存しない旨の説明、確認を行い（図５－５）、個人情報を入力する（図５－６）。引越れんらく帳で手続きを行う事業者については、その旨が表示される（図５－７）。そして、サイトが移動する際には、移動先である引越れんらく帳の利用規約の確認を求めるとともに、引越れんらく帳では個人情報を最大 30 日保
存する旨が説明される（図５－８）。
このように、ポータル間で個人情報を受け渡す場合は、個人情報の取り扱い主体、方法などが変わることから、利用者に対して再度、説明と同意を得ることが必要になる。
生い立ちの異なるポータルが相互連携する場合、それぞれの運用ポリシーが異なり、利用者が混乱する可能性がある。例えば個人情報の扱いについて、「引越れんらく帳」は個人情報を保存してサイトへの再訪問に備えることができるが、「関西引越し手続きサービス」は逆に個人情報を持たないことを安全であることの証として利用者にアピールしている。
これは「引越れんらく帳」が東京電力の運営サイトであるのに対し、「関西引越し手続きサービス」は社団法人関西経済連合会の傘下での協議会が運営しているという運営主体の違いによるためでもある。前者は、東京電力の顧客に対するサービスを東京電力が責任をもって提供しているが、後者は協議会という法人格を持たない任意団体が提供しており、できるだけ運営リスクを軽減する必要もあって、このような違いが生じてきた。
このような場合、いずれか一方に揃えれば解決するという問題ではなく、このような事例は様々な性格のサイト間を連携しようとする場合に多数発生することが予見される。
そこで今回のポータル間連携では、利用者に相手側にコントロールを移すことを明確に示し、利用者が相手側の利用ポリシーなどを確認した上で遷移するよう工夫を行った。

44

図５－５ 関西引越し手続きサービスの個人情報に関する確認画面

45

図５－６ 個人情報の入力画面

46図５－７ 関西引越し手続きサービスでの手続き事業者選択後の画面

47図５－８ 関西引越し手続きサービスから引越れんらく帳に移動する際の画面

48

図５－９ 引越れんらく張に移動した後の画面

49

（４）官民連携ポータルにおける個人情報保護のあり方
１）行政と民間の間での個人情報の受け渡しについて
現在、地方公共団体では、各団体が制定した個人情報保護条例、民間企業等では個人情報保護法に則って、個人情報の取得、利用が行われている。
これらの規定では、官や民が取得した個人情報を、本人の同意なしに第三者に提供したり、目的外に利用することが原則的に禁じられている。
地方公共団体の場合、例えば神奈川県の条例では、第 9 条で目的外の利用や第三者提供の制限を定めている。ただし本人の同意を得ているなど一定の場合には、目的外利用や第三者提供が認められている。
民間の場合、個人情報保護法第 2 条で、個人情報取扱事業者を、個人情報データベース（個人情報を電子計算機を用いて検索することができるように体系的に構成したもの）を事
業の用に供しているものと定義している。
個人情報取扱事業者は、個人情報保護法第 23 条に定めるように、あらかじめ本人の同意を得なければ、原則として個人情報を第三者に提供してはならないとしており、また、同法第15 条で、個人情報を取り扱うにあたり、その利用目的をできるだけ特定しなければならないとしている。
官民連携ポータルで上記の個人情報取扱事業者に該当する場合は、個人情報保護法第23 条を遵守する必要がある。したがって、利用者が個人情報を入力する際に、利用の目的、範囲、第三者に情報を提供する場合は、その提供先（連携している手続き先など）をあらかじめ明示し、利用者の同意を得ておく必要がある。同意を得ておけば、その範囲内で、官民連携ポータルから行政機関や民間企業、あるいは官民ポータル間で、個人情報を受け渡すことは問題ないと考えられる。
また、個人情報の他用途への利用については、個人情報保護法第 15 条の利用目的の特定と、同法第 16 条の本人の同意が関係する。あらかじめ、できるだけ具体的に目的、提供先を書いておき、同意を得ておけば、例えばダイレクトメールに利用する場合でも、引越しに関連するサービスということであれば考えられる。
個人情報の共同利用に関しては、個人情報保護法第 23 条 4 項第 3 号で規定している。
本人への通知（メール等でも可）、または本人が容易に知り得る状態にある（ホームページで閲覧可能な状態はこれに該当する）場合、本人の同意なしでも共同利用相手に提供することができると考えられる。
なお、ポータルの運営が地方公共団体からの委託を受けて行われる際は、当該地方公共団体の個人情報保護条例にも則る必要がある。
また、次項２）に示すように、官民連携ポータルの機能を、「ナビゲーション」「入力簡素化」「一括申請」と定義し、官民連携ポータル自体では個人情報の取得、蓄積を行わない（個人情報データベースを構成しない）と考えれば、ポータルから各手続きサイトへの個人情報の受け渡しそのものが発生しないと考えることができる。

50

２）官民連携ポータルにおける個人情報の取り扱いのパターン別の対応方法
以下、主要な個人情報の取り扱いパターンについて記述する。
①個人情報をポータルに蓄積しない場合
官民連携ポータルが提供するサービスを、
１）ナビゲーション：必要な手続きの案内
２）入力簡素化：共通情報を一度入力するだけで各手続きに自動入力される
３）一括申請：必要な手続きを一括して申請できると限定し、手続き終了と同時に情報を破棄するとすれば、官民連携ポータルは個人情報が通過するだけで、個人情報は残らない。関西引越し手続きサービスがこの方式をとっている。
この場合必要となるのは、
１）官民連携ポータルでは個人情報を蓄積しない旨の説明
２）個人情報は、各手続き先のサイトに入力され、各サイトのプライバシーポリシーに基づいて処理される旨の明示
３）各サイトで個人情報を活用することへの同意などである。
関西引越し手続きサービスでは、２）のプライバシーポリシーの明示と、３）の同意について
は、各手続き先サイト上で行われている。

個人情報
民間手続Aのサイト

利用者

官民連携ポータル

個人情報は、その都度入力する。

民間手続Bのサイト

行政手続Aのサイト

行政手続Bのサイト
官民連携ポータルが提供する機能
・ナビゲーション：必要な手続きの案内・入力簡素化：共通情報は一度入力するだけでいい
・一括申請：官民連携ポータルを活用すれば一度に申請できる

図５－１０ 個人情報を蓄積しない場合

51

②個人情報を蓄積する場合
官民連携ポータルが提供するサービスが前述の３機能であっても、個人情報を官民連携
ポータルで一度蓄積する場合は、官民連携ポータルは個人情報を取得することになることから、個人情報保護法等に則る必要がある。
引越れんらく帳の場合、期間限定であっても、個人情報をポータル内に蓄積することから、
このケースに該当する。
この場合、官民連携ポータルにおけるプライバシーポリシーや、個人情報取得の目的、利用の範囲、第三者に個人情報を受け渡す場合は、その相手先について明示し、同意を得る必要がある。
また、利用者からの開示請求や、第三者への情報提供の停止、個人情報の消去などの申し出に対応する必要がある。
個人情報の取得後、個人情報を受け渡す第三者が変更された場合の同意の取り方が課題となるが、第三者に受け渡す際にその都度利用者から同意を得る方法であれば、この問題は生じない。引越れんらく帳は、この方式である。

個人情報受渡し民間手続Aのサイト
官民連携ポータル

利用者

民間手続Bのサイト

行政手続Aのサイト
行政手続Bのサイト

個人情報（住所、氏名、電話番号など）を蓄積
DB

図５－１１ 個人情報を蓄積する場合

52

③個人情報を蓄積し他用途にも活用する場合
官民連携ポータルで個人情報を蓄積し、各手続き先サイトでの活用に加えて、他の用途（例えば、引越し先住所へのダイレクトメールの送付や、I am moving.com のようなピザの宅配サービスセールスなど）を行う場合には、他の用途について、利用目的、利用範囲などを明示し、利用者からあらかじめ同意を得る必要がある。
また、他の用途が追加、変更された場合には、その都度、利用者から同意を得る必要がある。利用者からの開示請求や第三者への提供の停止、個人情報の消去などの要請にも対応する必要がある。
官民連携ポータルの場合、現状では①あるいは②の方式が主であるが、ポータル事業としての収益性、採算性などを考えると、この③のような形で個人情報を蓄積し、他の用途に活用することで収益を上げる道を探る必要性が生じる可能性がある。
この場合は、他の個人情報取扱事業者同様、個人情報保護法等に則った厳格な運用が必要となる。

個人情報受渡し民間手続Aのサイト
官民連携ポータル

利用者

民間手続Bのサイト

行政手続Aのサイト

行政手続Bのサイト
個人情報（住所、氏名、電話番号など）を蓄積
他の用途にも活用（ダイレクトメールの発送など）

DB

図５－１２ 個人情報を蓄積し他用途にも活用する場合

53

④蓄積データの利用事業者を追加する場合等
ポータルにデータが蓄積される場合には、データを利用する接続事業者を追加する際の本人同意の取り方が課題となる。
個人情報保護法においては、個人データを共同利用しようとする場合は、あらかじめ、共同利用されるデータの項目、共同利用する者の範囲、利用目的等について、本人に通知するか、又は本人が容易に知り得る状態に置いておくことが必要になる。このため、蓄積データを利用する事業者を追加する際は、事前に本人にメール等で通知するか、または、ポータルに追加する旨を掲載するなどの方法により、本人が容易に知り得るよう工夫する必要がある。
なお、個人データの共同利用の場合等において、本人の求めに応じて個人情報の利用を停止させることができるよう、ポータルと本人との間であらかじめ契約等により手続きを明確にしておくことが適当である。

54

３）官民連携ポータルにおける個人情報の取り扱いについて
官民連携ポータルおよび手続き先のサイトなどにおいては、個人情報の取り扱いは慎重かつ厳格に行われるべきであるが、過剰になるあまり、利用者の利便性を損ねてはいけない。
利用者への的確な情報の提示と同意を得つつ、利用者にとって利便性の高いサービスを目指すことが重要である。
以下、官民連携ポータルにおける個人情報の取り扱いの留意点について記述する。
①サイト間の移動の明示
利用者が利用しているサイトが、官民連携ポータルから民間手続き A のサイト、あるいは行政手続き B のサイトへと移動すると、プライバシーポリシーも各サイトのものに則って適用されることになる。
今回の実証実験においても、「引越れんらく帳」から「関西引越し手続きサービス」に移動する場合は、その旨を利用者にわかるように明記し、以降は「関西引越し手続きサービス」のプライバシーポリシーに則って運用されることを明らかにしている。「引越れんらく帳」や「関西引越し手続きサービス」から各手続きサイトへと移動する場合も、同様である。
サイト間の移動が明確な場合は、上記のようにサイト間の移動を明示することで対応可能であるが、例えば、サイト内で他のサイトのサービスが動くような場合は、サイト間移動という概念があいまいになるため、プライバシーポリシーの設定、明示の方法についても、検討する必要が生じる。
②サイト間でのプライバシーポリシーの格差
官民連携ポータルや各手続きサイト間で、プライバシーポリシーやセキュリティなどに格差がある場合、本来ならば利用者が全てのサイトのプライバシーポリシーやセキュリティの違いを把握し、確認した上で利用する必要があるが、手続きが多くなればなるほど現実的には困難である。
そしてこの場合、利用者の多くは、最初の入り口となる官民連携ポータルへの信頼性を根拠として、各手続きサイトも利用することが考えられる。
従って、手続き先サイトを選定する場合には、官民連携ポータルとして、自ポータルの信
頼性を損なう恐れはないかなど、選定基準を設けて対応していくことが望まれる。また、ポー
タル間で連携する場合、連携相手の手続きサイトともつながることから、信頼性確保はより重要となる。事業者のプライバシーポリシーには、かなりの差があることから、ポータル事業者が提携先の選定基準を持つことは利用者にとっても望ましいと考えられる。さらには、ポータル
業界全体としての基準があれば、より望ましい。
なお、平成 16 年 4 月に閣議決定された「個人情報の保護に関する基本方針」において、個人情報取扱事業者に関する事項が示されている。この内容をいかに遵守しているかがひ
とつの基準となる。

55

参考：個人情報の保護に関する法律（主な関連条項のみ抜粋。下線は本報告書独自のもの。）
（定義）
第二条

この法律において「個人情報」とは、生存する個人に関する情報であって、当該情報に含まれる氏名、生年月日その他の記述等により特定の個人を識別することができるもの（他の情報と容易に照合することができ、それにより特定の個人を識別することができることとなるものを含む。）をいう。
２

この法律において「個人情報データベース等」とは、個人情報を含む情報の集合物であって、次に掲げるものをいう。
一

特定の個人情報を電子計算機を用いて検索することができるように体系的に構成したもの
二

前号に掲げるもののほか、特定の個人情報を容易に検索することができるように体系的に構成したものとして政令で定めるもの
３

この法律において「個人情報取扱事業者」とは、個人情報データベース等を事業の用に供している者をいう。ただし、次に掲げる者を除く。
一

国の機関

二

地方公共団体三独立行政法人等（独立行政法人等の保有する個人情報の保護に関する法律（平成十五年法律第五十九号）第二条第一項に規定する独立行政法人等をいう。以下同じ。）
四

地方独立行政法人（地方独立行政法人法（平成十五年法律第百十八号）第二条第一項に規定する地方独立行政法人をいう。以下同じ。）
五

その取り扱う個人情報の量及び利用方法からみて個人の権利利益を害するおそれが少ないものとして政令で定める者
４

この法律において「個人データ」とは、個人情報データベース等を構成する個人情報をいう。

５

この法律において「保有個人データ」とは、個人情報取扱事業者が、開示、内容の訂
正、追加又は削除、利用の停止、消去及び第三者への提供の停止を行うことのできる権限を有する個人データであって、その存否が明らかになることにより公益その他の利益が害されるものとして政令で定めるもの又は一年以内の政令で定める期間以内に消去す
ることとなるもの以外のものをいう。

６

この法律において個人情報について「本人」とは、個人情報によって識別される特定の個人をいう。

（利用目的の特定）第十五条

個人情報取扱事業者は、個人情報を取り扱うに当たっては、その利用の目的（以下「利用目的」という。
）をできる限り特定しなければならない。
２

個人情報取扱事業者は、利用目的を変更する場合には、変更前の利用目的と相当の関56

連性を有すると合理的に認められる範囲を超えて行ってはならない。
（利用目的による制限）
第十六条

個人情報取扱事業者は、あらかじめ本人の同意を得ないで、前条の規定により特定された利用目的の達成に必要な範囲を超えて、個人情報を取り扱ってはならない。
２

個人情報取扱事業者は、合併その他の事由により他の個人情報取扱事業者から事業を承継することに伴って個人情報を取得した場合は、あらかじめ本人の同意を得ないで、承継前における当該個人情報の利用目的の達成に必要な範囲を超えて、当該個人情報を取り扱ってはならない。

３

前二項の規定は、次に掲げる場合については、適用しない。
一

法令に基づく場合

二人の生命、身体又は財産の保護のために必要がある場合であって、本人の同意を得ることが困難であるとき。

三

公衆衛生の向上又は児童の健全な育成の推進のために特に必要がある場合であって、本人の同意を得ることが困難であるとき。
四国の機関若しくは地方公共団体又はその委託を受けた者が法令の定める事務を遂行することに対して協力する必要がある場合であって、本人の同意を得ることにより当該事務の遂行に支障を及ぼすおそれがあるとき。
（第三者提供の制限）
第二十三条

個人情報取扱事業者は、次に掲げる場合を除くほか、あらかじめ本人の同意を得ないで、個人データを第三者に提供してはならない。
一

法令に基づく場合

二人の生命、身体又は財産の保護のために必要がある場合であって、本人の同意を得ることが困難であるとき。
三

公衆衛生の向上又は児童の健全な育成の推進のために特に必要がある場合であって、本人の同意を得ることが困難であるとき。
四国の機関若しくは地方公共団体又はその委託を受けた者が法令の定める事務を遂行することに対して協力する必要がある場合であって、本人の同意を得ることにより当該事務の遂行に支障を及ぼすおそれがあるとき。
２

個人情報取扱事業者は、第三者に提供される個人データについて、本人の求めに応じて当該本人が識別される個人データの第三者への提供を停止することとしている場合であって、次に掲げる事項について、あらかじめ、本人に通知し、又は本人が容易に知り得る状態に置いているときは、前項の規定にかかわらず、当該個人データを第三者に提供することができる。
一

第三者への提供を利用目的とすること。

二

第三者に提供される個人データの項目

57

三

第三者への提供の手段又は方法

四

本人の求めに応じて当該本人が識別される個人データの第三者への提供を停止すること。

３

個人情報取扱事業者は、前項第二号又は第三号に掲げる事項を変更する場合は、変更する内容について、あらかじめ、本人に通知し、又は本人が容易に知り得る状態に置かなければならない。

４

次に掲げる場合において、当該個人データの提供を受ける者は、前三項の規定の適用については、第三者に該当しないものとする。
一

個人情報取扱事業者が利用目的の達成に必要な範囲内において個人データの取扱いの全部又は一部を委託する場合
二

合併その他の事由による事業の承継に伴って個人データが提供される場合

三

個人データを特定の者との間で共同して利用する場合であって、その旨並びに共同して利用される個人データの項目、共同して利用する者の範囲、利用する者の利用目的及び当該個人データの管理について責任を有する者の氏名又は名称について、あらかじめ、本人に通知し、又は本人が容易に知り得る状態に置いているとき。

５

個人情報取扱事業者は、前項第三号に規定する利用する者の利用目的又は個人データの管理について責任を有する者の氏名若しくは名称を変更する場合は、変更する内容について、あらかじめ、本人に通知し、又は本人が容易に知り得る状態に置かなければならない。
（保有個人データに関する事項の公表等）

第二十四条

個人情報取扱事業者は、保有個人データに関し、次に掲げる事項について、本人の知り得る状態（本人の求めに応じて遅滞なく回答する場合を含む。）に置かなければならない。
一

当該個人情報取扱事業者の氏名又は名称

二すべての保有個人データの利用目的(第十八条第四項第一号から第三号までに該当する場合を除く。)
三

次項、次条第一項、第二十六条第一項又は第二十七条第一項若しくは第二項の規定による求めに応じる手続（第三十条第二項の規定により手数料の額を定めたときは、その手数料の額を含む。
）

四前三号に掲げるもののほか、保有個人データの適正な取扱いの確保に関し必要な事項として政令で定めるもの

２

個人情報取扱事業者は、本人から、当該本人が識別される保有個人データの利用目的の通知を求められたときは、本人に対し、遅滞なく、これを通知しなければならない。
ただし、次の各号のいずれかに該当する場合は、この限りでない。
一

前項の規定により当該本人が識別される保有個人データの利用目的が明らかな場合

二第十八条第四項第一号から第三号までに該当する場合

58

３

個人情報取扱事業者は、前項の規定に基づき求められた保有個人データの利用目的を通知しない旨の決定をしたときは、本人に対し、遅滞なく、その旨を通知しなければな
らない。
（開示）

第二十五条

個人情報取扱事業者は、本人から、当該本人が識別される保有個人データの開示（当該本人が識別される保有個人データが存在しないときにその旨を知らせることを含む。以下同じ。）を求められたときは、本人に対し、政令で定める方法により、遅滞なく、当該保有個人データを開示しなければならない。ただし、開示することにより次の各号のいずれかに該当する場合は、その全部又は一部を開示しないことができる。
一

本人又は第三者の生命、身体、財産その他の権利利益を害するおそれがある場合

二

当該個人情報取扱事業者の業務の適正な実施に著しい支障を及ぼすおそれがある場
合三２

他の法令に違反することとなる場合
個人情報取扱事業者は、前項の規定に基づき求められた保有個人データの全部又は一部について開示しない旨の決定をしたときは、本人に対し、遅滞なく、その旨を通知しなければならない。
３

他の法令の規定により、本人に対し第一項本文に規定する方法に相当する方法により当該本人が識別される保有個人データの全部又は一部を開示することとされている場合には、当該全部又は一部の保有個人データについては、同項の規定は、適用しない。
（訂正等）

第二十六条

個人情報取扱事業者は、本人から、当該本人が識別される保有個人データの内容が事実でないという理由によって当該保有個人データの内容の訂正、追加又は削除（以下この条において「訂正等」という。）を求められた場合には、その内容の訂正等に関して他の法令の規定により特別の手続が定められている場合を除き、利用目的の達成に必要な範囲内において、遅滞なく必要な調査を行い、その結果に基づき、当該保有個人データの内容の訂正等を行わなければならない。
２

個人情報取扱事業者は、前項の規定に基づき求められた保有個人データの内容の全部若しくは一部について訂正等を行ったとき、又は訂正等を行わない旨の決定をしたときは、本人に対し、遅滞なく、その旨（訂正等を行ったときは、その内容を含む。
）を通知しなければならない。
（利用停止等）第二十七条

個人情報取扱事業者は、本人から、当該本人が識別される保有個人データが第十六条の規定に違反して取り扱われているという理由又は第十七条の規定に違反して取得されたものであるという理由によって、当該保有個人データの利用の停止又は消去

59

（以下この条において「利用停止等」という。）を求められた場合であって、その求めに理由があることが判明したときは、違反を是正するために必要な限度で、遅滞なく、当該保有個人データの利用停止等を行わなければならない。ただし、当該保有個人データの利用停止等に多額の費用を要する場合その他の利用停止等を行うことが困難な場合であって、本人の権利利益を保護するため必要なこれに代わるべき措置をとるときは、この限りでない。
２

個人情報取扱事業者は、本人から、当該本人が識別される保有個人データが第二十三条第一項の規定に違反して第三者に提供されているという理由によって、当該保有個人データの第三者への提供の停止を求められた場合であって、その求めに理由があることが判明したときは、遅滞なく、当該保有個人データの第三者への提供を停止しなければならない。ただし、当該保有個人データの第三者への提供の停止に多額の費用を要する
場合その他の第三者への提供を停止することが困難な場合であって、本人の権利利益を保護するため必要なこれに代わるべき措置をとるときは、この限りでない。

３

個人情報取扱事業者は、第一項の規定に基づき求められた保有個人データの全部若し
くは一部について利用停止等を行ったとき若しくは利用停止等を行わない旨の決定をしたとき、又は前項の規定に基づき求められた保有個人データの全部若しくは一部について第三者への提供を停止したとき若しくは第三者への提供を停止しない旨の決定をした
ときは、本人に対し、遅滞なく、その旨を通知しなければならない。

60

参考：個人情報の保護に関する基本方針（主な関連項目のみ抜粋）（平成１６年４月２日閣議決定）※個人情報保護法第 7 条に基づく。
６ 個人情報取扱事業者等が講ずべき個人情報の保護のための措置に関する基本的な事項(1) 個人情報取扱事業者に関する事項
・個人情報取扱事業者は、法の規定に従うほか、２の(3)の①の各省庁のガイドライン等に則し、個人情報の保護について主体的に取り組むことが期待されているところであり、事業者は、法の全面施行に向けて、体制の整備等に積極的に取り組んでいくことが求められている。各省庁等におけるガイドライン等の検討及び各事業者の取組に当たっては、
特に以下の点が重要であると考えられる。
① 事業者が行う措置の対外的明確化
・事業者の個人情報保護に関する考え方や方針に関する宣言（いわゆる、プライバシーポ
リシー、プライバシーステートメント等）の策定・公表により、個人情報を目的外に利用しないことや苦情処理に適切に取り組むこと等を宣言するとともに、事業者が関係法令等を遵守し、利用目的の通知・公表、開示等の個人情報の取扱いに関する諸手続について、あらかじめ、対外的に分かりやすく説明することが、事業活動に対する社会の信頼を確保するために重要である。また、事業者において、個人情報の漏えい等の事案が発生した場合は、二次被害の防止、類似事案の発生回避等の観点から、可能な限り事実関係等を公表することが重要である。
② 責任体制の確保
・事業運営において個人情報の保護を適切に位置づける観点から、外部からの不正アクセスの防御対策のほか、個人情報保護管理者の設置、内部関係者のアクセス管理や持ち出し防止策等、個人情報の安全管理について、事業者の内部における責任体制を確保するための仕組みを整備することが重要である。また、個人情報の取扱いを外部に委託することとなる際には、委託契約の中で、個人情報の流出防止をはじめとする保護のための措置が委託先において確保されるよう、委託元と委託先のそれぞれの責任等を明確に定めることにより、再委託される場合も含めて実効的な監督体制を確保することが重要である。
③ 従業者の啓発・事業者において、個人情報の漏えい等の防止等、その取り扱う個人情報の適切な保護が確保されるためには、教育研修の実施等を通じて、個人情報を実際に業務で取り扱うこととなる従業者の啓発を図ることにより、従業者の個人情報保護意識を徹底することが重要である。

61

６ データ標準化に関する検討（１）官民連携ポータルにおけるデータ標準化の必要性
１）データ標準化フレームワーク構築の必要性①データ連携の課題
現状においては、後述のとおり、官民を通じて様々なデータセット（データ項目及びデータ定義の集合）の仕様が存在している。さらに、個別の事業者が独自にデータセットを定めて使用している場合もある。
仮に、官民連携ポータル事業者が、各申請受付事業者が扱っているデータの形式、内容、書式などの相違を考慮しつつ、自らデータセットを定めなければならないとすれば、接続対象事業者が増えるにつれ、指数関数的に負担が増大することとなり、官民連携ポータル事業の開始にあたり大きな支障となる。
また、１つの申請受付事業者が多数の官民連携ポータルサイトに接続する場合もあると考えられるが、官民連携ポータル事業者ごとに扱うデータセットが異なっていた場合、申請受付
事業者は、接続するポータルサイトの数だけ異なるデータセットを使用しなければならなくなるという問題もある。
②標準化の必要性
これらの状況を踏まえ、官民連携ポータルサイトが取り扱うデータセットは、官民連携ポータル事業者がそれぞれ独自に定めるのではなく、標準化を図るべきであり、そのためのフレーム
ワークの構築が必要である。また、ここで標準化されたデータセット（以下「官民連携データセット」という）を公開・周知し、必要に応じて改訂を行えるようにするためのフレームワークを構築していく必要がある。

62

（２）データ標準化の現状
１）ＸＭＬによるデータ標準化の全体フレームワーク
システムによってデータの定義が異なると、システム間でのデータ交換が行えないことから、政府、地方公共団体及び民間のそれぞれにおいて、準拠すべき標準的なデータ仕様を定める取り組みが行われている（図６－１）。これらの標準的なデータ仕様で用いられるフォーマット
としては、その記述の自由性等があることから、ウェブ技術標準化団体である World Wide
Web Consortium（W3C）が制定した XML（eXtensible Markup Language）が採用されていることが多い。XML は自由にデータセットを策定することができるため広く採用されているが、そのため多くのデータセット標準が策定され、それぞれの間で互換性がとれていないことが問題である。

政府
政府

自治体
自治体

政府基本問題専門部会・共通システム専門部会了承
政府基本問題専門部会・共通システム専門部会了承（平成14年3月）（平成14年3月）

申請データ設計ガイドライン
申請データ設計ガイドライン

申請者と各行政機関の汎用受付等システム間で受渡しする申請データ、共管手続における申請データを設計するための指針
財団法人ニューメディア開発協会（平成14年5月）
財団法人ニューメディア開発協会（平成14年5月）

電子申請用XML様式の
電子申請用XML様式の設計ガイドライン（第2版）
設計ガイドライン（第2版）

申請者から各行政機関の電子申請システムに提出される申請書様式の電子化のための指針。「申請データ設計ガイドライン」で参照・推奨されている。
財団法人ニューメディア開発協会（平成16年3月）
財団法人ニューメディア開発協会（平成16年3月）

平成14年度官民連携起業手続一元化
平成14年度官民連携起業手続一元化
事業
事業 「GPPデータセット仕様書」「GPPデータセット仕様書」
GPP方式による官民連携ワンストップサービス
における共通的なデータセット構成を定義

総務省（平成16年3月）
総務省（平成16年3月）

平成15年度
平成15年度
電子自治体推進パイロット事業
電子自治体推進パイロット事業

民間
民間
業界標準
G-XML
G-XML

XBRL
XBRL

地理情報

財務情報

ebXML
ebXML

UBL
UBL

電子商取引

電子商取引

電子自治体構築にあたり、データの標準化に関する検討及び作業を行うＷＧを設置。また地方公共団体の代表で構成する協議会を設置し、ＷＧの成果をオー
ソライズし、データ標準化を推進。

NewsXML
NewsXML

MML
MML

新聞業界

電子カルテ

総務省（平成16年～）
総務省（平成16年～）

TravelXML
cXML
TravelXML cXML

電子自治体推進パイロット事業の実証実験における汎用受付システムで使用するために設計されたXML
総務省（平成16年11月、平成17年３月）
総務省（平成16年11月、平成17年３月）

データ標準化ＷＧ、データ標準化推進地方
データ標準化ＷＧ、データ標準化推進地方公共団体協議会の設置
公共団体協議会の設置

・国・地方連携データのXMLタグ設計
・国・地方連携データのXMLタグ設計
・システム間連携データのXMLタグ設計
・システム間連携データのXMLタグ設計
・電子申請情報のXMLタグ設計
・電子申請情報のXMLタグ設計
・バックオフィスのデータベースのモデリング・バックオフィスのデータベースのモデリング

旅行業界

・・・

コンテンツ
情報

システム独自総務省
総務省

平成17年度
平成17年度
次世代地域情報プラットフォーム事業
次世代地域情報プラットフォーム事業

Webサービス技術による自治体情報システムのオー
プン化とプラットフォームの標準化を目指す

Aシステム
Aシステム

Bシステム
Bシステム

・・・

図６－１ 官民の主な標準的データ仕様
２）政府におけるデータ標準
政府では、電子申請における申請書で使用する基本情報の設計方針をまとめた「申請データ設計ガイドライン」を政府基本問題専門部会・共通システム専門部会で了承し、各府省の汎用受付等システムにおいて、各府省の個別手続きや共管手続きの申請データの設計の際に参照されている。また「申請データ設計ガイドライン」では、申請データを設計する際には、
基本情報以外の情報も含め、財団法人ニューメディア開発協会が策定した「電子申請用
XML 様式の設計ガイドライン（第２版）」を参照するよう明記されている。

63

３）地方公共団体におけるデータ標準
地方公共団体では、総務省が平成 15 年度に実施した電子自治体推進パイロット事業において、汎用受付システムにおける XML の検討が行われている。また、平成 16 年度からは、総務省の「電子自治体のシステム構築のあり方に関する検討会」の下に「データ標準化 WG」が設置され、データ標準化に関する検討や作業を実施しており、その成果は地方公共団体の代表で構成する「データ標準化推進地方公共団体協議会」において協議・オーソライズしている。ここでの標準化の検討対象は、電子申請データ、システム間連携データ、国・地方間
連携データなど、地方公共団体のシステム全般にわたっており、ここでオーソライズされた内容は、今後、全国の地方公共団体における情報システムの構築に反映されることになる。
４）民間におけるデータ標準
民間では、特定の業界や業種を対象としたデータ交換や電子商取引などを目的とする標
準的な XML 仕様がいくつか策定されている他、システム独自に開発した XML 仕様も多数存
在する。

64

（３）官民データ連携のためのアプローチ
官民間のデータ連携を行うため以下の検討を行った。
①標準化スキームの構築
官民連携データセットの標準化にあたり、仕様を策定し標準化を行うためのスキーム（体制）を検討した。また、官民連携データセット仕様の維持管理に関する体制についても検討した。
②データ項目の選定
官民連携データセットが対象とする業務・手続きは様々であるが、本検討会では、現在稼動中の内外の引越しワンストップサービスの実態を調査し、実施中のサービス、今後実施した
いと考えられるサービスについて、共通化すべき又は共通化が望ましいデータ項目を抽出した。
③標準化要素の検討
官民のデータ標準化活動及び代表的なデータ標準仕様を調査することにより、データの分
類、データの定義、構造、書式などデータセットの定義項目に関し、標準化の際に考慮すべき事項を整理した。
④策定手順の検討
データ標準化で考慮すべき事項をもとに、官民連携データセットの作成手順を検討した。
⑤利用に関する検討
官民連携データセットが策定された後、官民連携ポータル事業者や申請受付事業者などが、これを利用して官民連携ポータルサイトを構築する際の課題と対応方法について検討した。

65

（４）官民連携データ標準化のフレームワーク
１）標準化スキームの構築①官民の仕様検討組織
官民連携データセットの標準化スキームを図６－２に示す。
官民連携データセットの標準化にあたっては、官民連携ポータルの主たる接続対象となる地方公共団体と民間の申請受付事業者が互いに調整し、決定していくことが望ましいが、これを円滑に進めるためには、地方公共団体、民間それぞれのデータ標準化に関する代表的組織の間で連携・調整が図られる必要がある。
地方公共団体については、前述のとおり、データ標準化ＷＧにおいて地方公共団体のデータ標準化に関する検討や作業が実施されており、その成果を地方公共団体の代表で構成するデータ標準化推進地方公共団体協議会（以下「協議会」という）において協議・オーソライ
ズするという仕組みが整えられており、官民連携データセットについても同スキームで検討を行うことになる。
民側の仕様検討組織としては、仕様の一元化のため、官民連携ポータルサイトに関心があったり、データの標準化を必要とする官民連携ポータル事業者などが参加する民間標準化組織（仮称、以下「民間標準化組織」という）を創設し、官民連携ポータル事業者からの要望に基づき、他の標準化団体・組織とも連携をしながら、仕様の検討を行うことが適当である。
②標準化における各組織の役割
官民連携データセットにおけるデータ項目は大きく、「地方公共団体・民間 共通部分」「地方公共団体固有部分」「民間固有部分」に分けられる。
官民連携ポータルで扱う手続きの中で、地方公共団体に対する手続きは相当の割合を占めると予想されるが、ポータルと全国の地方公共団体のシステムの間での情報の受け渡しにおいてデータの変換が不要になることは、ポータル事業全体にとって大きなメリットになると考えられる。このため、「地方公共団体・民間 共通部分」については、全国の地方公共団体の情報システムにおけるデータ標準を定めるデータ標準化ＷＧ・協議会において決定することが適当である。
また、「地方公共団体固有部分」、「民間固有部分」については、それぞれ、データ標準化
ＷＧ・協議会、民間標準化組織において策定・決定することが適当である。
なお、官民連携データセットの標準化にあたっては、データセット全体の整合性確保等の観点から、データ標準化ＷＧと民間標準化組織が必要に応じて連携・調整を行うことが適当
である。

66

データセット

官民連携

地方公共団体固有部分

地方公共団体・民間 共通部分

民間固有部分
民間固有部分決定

決定

データ標準化推進地方公共団体協議会(メンバー)
全国知事会、全国市長会、全国町村会の代表団体
事務局：総務省

民間標準化組織（フォーラム／協議会など）

仕様管理

仕様策定
承認

連携・調整

連携・調整

電子自治体のシステム構築のあり方に関する検討会

情報共有

参加

データ標準化WG(メンバー)
学識経験者、地方公共団体、総務省（自治行政局、情報通信
政策局、行政管理局、統計局）

官民連携ポータル事業者等

地方公共団体民他標準化団体・組織間

図６－２ 官民連携データセット標準化スキーム③仕様の維持・管理組織
官民連携データセットを策定・標準化した後も、法改正、情報システムの更新、官民連携ポータルサイトのニーズの変化など、様々な要因により、官民連携ポータル事業者や申請受付
事業者が欲するデータ仕様が異なってくることが想定される。このため、官民連携データセット
仕様を永続的に維持し、必要に応じて更新などを行うための体制が必要となる。
地方公共団体においては、標準化されたデータ仕様の維持管理や普及促進を行うための体制の検討が進められている。
また、民間においては、民間標準化組織が仕様やガイドライン等の維持管理・広報活動などを実施することが適当である。この民間標準化組織は、官民連携データセット「民間固有部分」の維持管理に係るマニュアル・ガイドラインを作成し、仕様の維持管理を行う。新たに、「民間固有部分」に関するデータ仕様の標準化の要求が組織メンバーから挙がった場合、他のメンバーの合意に基づき、ワーキンググループを構成し、標準仕様に関する検討を行う。ワーキ
ンググループで策定されたドラフト案について、組織全体で合意が得られれば、標準仕様として採用する。「地方公共団体・民間 共通部分」に関するデータ仕様の標準化の要求が組織メンバーから挙がった場合、「民間固有部分」と同様に、仕様の検討を行うとともに、データ標
準化ＷＧに対して標準化の検討依頼を行う。データセット仕様の検討にあたっては、ルールやガイドラインの遵守チェック、シンタックスのチェックと妥当性検証、既存のデータ標準との重複チェックなどを実施し、共通化可能な部分の抽出を行う。
67

２）データ項目の選定①データセットの対象の検討
データセットの標準化において、官民の各種申請・届出等の手続きに必要となる全てのデータ項目に対する標準化を行うことは膨大な作業を伴い、これを一度に行うことは現実的でないため、利用者のニーズの高いものから順次進めることが適当である。
このため、本検討会では、データ連携の対象とすべき業務・手続きについて、ワンストップポータルサービスとして普及している住所変更手続きに関する官民連携ポータルサイトの先進的取り組みを行っている東京電力「引越れんらく帳」、関西手続きワンストップ協議会「関西引越し手続サービス」、財団法人さっぽろ産業振興財団「札幌地区目的指向ポータル」に対してアンケート調査を実施した。調査結果を図６－３に示す。
これによると、電気・ガス・水道などの公益事業者への届出等が既に連携の例として挙げられており、今後地方公共団体の住居移転関連手続きや郵便局の転送届など官側の手続きとの連携も期待されている。これらの業務・手続きから、現状では、個人の基本的な情報（住所、
電話番号など）の変更に伴う手続きのために必要なデータセットが有力な検討対象と考えられる。
地方自治体（電子申請、住居移転に伴う手続き）

旅行サービス（航空会社、ＪＲ：切符手配）（教育委員会：転出入手続き）（交通事業者：定期券）（環境：ごみ受付け）

雑誌購読（公安委員会：免許更新・変更）

慈善団体

水道（使用中止・開始）

通販（物流配送：住所変更）

凡例
赤字：連携例がある．

電話（ＮＴＴ西、ＮＴＴ東、携帯電話：移転連絡）労働組合

ガス（都市ガス：使用中止・開始）

スポーツクラブ電気（使用中止・開始）

専門団体

テレビ（ＮＨＫ、ＣＡＴＶ：新規契約・変更届）

出版（新聞：解約・新規申込）

銀行（住所変更届）

政府機関等（郵便局：郵便物転送届）

学校・同窓会（卒業証明、成績証明） 黒字：I am moving.comのカテゴリにあるが、3地（講座受講申込み）域の対象外のカテゴリ．
インターネット（変更届）

ロイヤルティカード（ＪＡＦ：住所変更）

クレジットカード（住所変更届）

国営血液センター

青字：既存に連携したい
手続きサイトがあるがまだ連携していない．
紫字：サービスが開始されれば連携したい．

年金※３地域のアンケート結果から保険（住所変更）（Ｉ ａｍ mｏｖｉｎｇ.cｏｍと対比して）

図６－３ 官民連携の対象業務・手続き②共通データ項目候補の抽出
上記のアンケート調査と同時に、共通化すべきデータ項目、共通化が望ましいデータ項目（これらのデータ項目を総称して、「共通データ項目候補」と呼ぶ）についてもアンケート調査を行った。共通化すべきデータ項目とは、官民連携ポータルと事業者と複数の申請受付事業者間でのデータ交換において、共通して使われるデータ項目で、アンケートの結果によると、
氏名、性別、生年月日や住所、電話番号などの連絡先に関する情報などの基本的な情報が68

主に挙げられている。
また、共通化が望ましいデータ項目とは、官民連携ポータルと事業者と複数の申請受付事
業者間でのデータ交換において、共通して使われる可能性の高いデータ項目で、アンケートの結果によると、金融機関名称や口座情報、利用開始・変更希望・廃止日付などの日付に関する情報、行政区名称や世帯人数などの引越しに付随する情報が挙げられている。いずれも、
今後官民連携データセットを策定するにあたり、参考となる結果と考えられる。
３）標準化要素の検討①要素検討のためのアプローチ
官民連携データセットの標準化要素を抽出する目的で、既存のデータセットを複数選定し参照した。本検討会で参照したデータセットは、図６－１に掲載したもののうち、以下のものとなる。
政府間連で参照したデータセットとして、「申請データ設計ガイドライン」「電子申請用 XML様式の設計ガイドライン（第２版）」「GPP データセット仕様書」を選定した。「申請データ設計
ガイドライン」と「電子申請用 XML 様式の設計ガイドライン（第２版）」は、政府の汎用受付等シ
ステムの設計・構築において、申請データの電子化を行うために参照すべきガイドラインであり、多くの汎用受付等システムで参照されていると考えられるためである。また、「GPP データ
セ ッ ト 仕 様 書 」 は 、 官 民 連 携 手 続 き 一 元 化 方 式 （ GPP 方 式 ： Government Private
co-operation Portal）による官民手続き連携の仕組みを検討し策定したものであり、申請データの標準化については触れられていないが、システム間でやりとりされるデータパッケージに関する規定がされているため、参考とした。
地方公共団体関連としては、データ標準化 WG・協議会で検討、オーソライズされた内容を参考とした。
民間関連で参照したデータセットとして、ebXML（electronic business XML）と UBL（Universal Business Language）を参照した。これらは、特定の業種・業界に依存しない汎用的・世界的な電子商取引用 XML 標準を検討しており、民間システムでの利用が増えていくことが予想されることから選定した。
②データ標準化要素
先に抽出した共通データ項目候補に対し、これら参照したデータセットでどのような項目定義を行っているかを比較し、整理を行った。
その結果、官民連携データセットの標準化にあたっては、以下の課題を考慮して仕様を策定することが望ましいと考えられる。
ア．書式同じデータ項目であっても、データセットによりデータの表記方法が異なる場合がある。例69

えば、日付を表す場合、西暦表記を使う場合と和暦表記を使う場合があり、それぞれの意味は同じであるが、表記方法は異なる。
イ．文字コード
データセットによりデータを記述するコード体系が異なる場合がある。例えば、データを JISで表す場合、シフト JIS で表す場合、UTF-8 で表す場合など様々である。XML の場合、国際的な標準の観点から、UTF-8/UTF-16 が採用される場合が多い。
ウ．単位
数字データが表す意味がデータセットにより異なる場合がある。例えば、金額を表すデータ
項目であっても、数字が円であるかドルであるかユーロであるか分からない。単位によっては変換可能なものと不可能なものがあり、また、金額のレートのように変換値が可変である場合もある。
エ．構造
データセットによりデータの細分化のレベルが異なる場合がある。例えば、氏名について、氏名をまとめて扱うデータセットや、氏と名を分けて扱うデータセットが存在する。また、住所をまとめて扱うデータセットや、都道府県・市区町村・町名などに分解して扱うデータセットが存在する。構造が異なる場合、データ交換には個別に変換ルールが必要となり、場合によっては変換不可能となる可能性がある。
オ．粒度・意味
同じデータ項目であっても、データセットによりデータが表す意味の抽象度（粒度）や内容が異なる場合がある。例えば、氏名というデータ項目について、単に人の名前を意味するデータセットや、申請者の名前を意味するデータセットなどがあり得る。粒度や意味が異なって
いては、データ交換に混乱をきたすため、データ交換するデータセット間でデータの粒度や意味を揃える必要がある。
上記の各項目に対し、データ標準化要素は次の通りとなる。
「書式」「文字コード」「単位」の課題への対応については、官民連携データセットを含め各
データセットにおいて予め仕様を明らかにすることで、例えば、申請受付事業者が新たにシステムを構築する場合には、官民連携データセットを用いるよう設計すれば、そもそもデータ変換を行わないようにすることが可能となり、また、仮に仕様が異なっていて変換が必要な場合
でも、仕様が明らかになっていれば、一括して変換を行うことが可能となる。
「構造」の課題への対応については、個々のデータ項目に意味を持つ範囲で、なるべく構
造化（細分化、階層化）を図ることが考えられる。必要に応じて項目連携を行うなどにより、デ70

ータ連携の対象を広げることが可能となる。ただし、あまり細分化を進めると、入力項目数が増えるため、利用者のユーザインタフェースなどとの兼ね合いも考慮に入れる必要がある。
「粒度・意味」の課題への対応については、汎用的なものとするため、大きな粒度とすることを基本とし、必要に応じて粒度を細かくするような仕組みを考える必要がある。
４）官民連携データセットの策定手順の検討
データ標準化で考慮すべき事項のうち、「粒度・意味」については、前記のとおり、大きな粒度とすることを基本としつつ、必要に応じて粒度を細かくする仕組みが必要であり、その考え方を反映させたデータセットの策定手順を図６－４に示す。これは、地方公共団体・民間共通
部分を、レベル 0 の基本共通データ項目（仮称、以降同じ）とレベル 1 の目的別共通データ項
目（仮称、以降同じ）に分類し、レベル 0 で大きな粒度のデータ項目を、レベル 1 で細かい粒度のデータ項目を定義することを想定している。

官民連携データセット地方公共団体・民間共通部分
Ex.氏名、
レベル０:基本共通データ項目（仮称、以降同じ）
レベル０:基本共通データ項目（仮称、以降同じ）
住所・氏名、日付、住所など共通性が高いデータの項目を選定する。
・氏名、日付、住所など共通性が高いデータの項目を選定する。
・各データ項目の書式・文字コード・単位・構造・意味などの項目属性の定義を行う。
・各データ項目の書式・文字コード・単位・構造・意味などの項目属性の定義を行う。

項目属性継承レベル１:目的別共通データ項目
レベル１:目的別共通データ項目（仮称、以降同じ）（仮称、以降同じ）・官民連携ポータルの目的別に固有なデータ項目を定義する。ただし目的が異なっても同じ項目
・官民連携ポータルの目的別に固有なデータ項目を定義する。ただし目的が異なっても同じ項目定義が可能である場合は、個別に定義は行わない。
定義が可能である場合は、個別に定義は行わない。
・項目の属性は基本的にレベル０の定義内容を
継承する。
利用する。
・項目の属性は基本的にレベル０の定義内容を継承する。

会社設立ポータル用
データセット

引越ポータル用
データセット結婚ポータル用
データセット（Ex:事務所所在地、
本社住所）（Ex:引越元住所、引越先住所）（Ex:本籍地）

・・・

必要に応じデータ変換
・引越元住所
A社
データセット ・引越先住所・移転元住所
B社
データセット ・移転先住所

・旧住所
C社
データセット ・新住所

・・・・・

図６－４ 官民連携データセット 地方公共団体・民間 共通部分 策定手順
①データのレベル分け
レベル 0 の基本共通データ項目は、氏名、住所などどのような手続きにも必要となる共通性の高いデータに関する定義を行うものである。これらのデータ項目に対して、前述のデータ標準化で考慮すべき事項を踏まえ、書式、文字コード、単位、構造、意味などの項目属性を定
義する。

71

レベル 1 の目的別共通データ項目は、レベル 0 の基本共通データ項目定義を基に、様々な目的・用途の官民連携ポータルに特有のデータ項目の定義を行うもので、官民連携ポータ
ルサイトが申請受付事業者と連携する際に主に使用するデータ項目である。例えば、引越し
ポータル用のデータ項目として、レベル 0 の「住所」の定義を基に、レベル 1 では、「引越し元住所」「引越し先住所」「連絡先住所」などの項目の定義を行う。ただし目的が異なる場合でも、同じ項目定義が可能である場合は、重複して定義を行わないようにする必要がある。また、レベル 1 はレベル 0 で定義された属性を基本的に利用することを想定している。
②基本共通データ項目の定義例
図６－５に、レベル 0 の基本共通データ項目の定義例を示す。前述のように、レベル 0 では、
様々な手続きに共通するデータ項目を選定し、その書式、文字コード、単位、データ構造、粒度・意味を項目毎に定義する。こうした内容が公開されれば、官民連携ポータルの事業化や、官民連携ポータル事業者が、新たにレベル 1 の目的別共通データ項目案の作成を行うことに役立つ。なお、この表はサンプルであり、表中のデータ項目の種別や、各データ項目の定義
内容などは実際に標準化される内容とは異なる。

データ項目
氏名

上位項目
氏名

データ構造
下位項目
氏
名
氏フリガナ
名フリガナ

意味

書式

文字コード

基本共通データ項目の候補

人の名前の姓
全角
UTF-8
人の名前の名
全角
UTF-8
氏名フリガナ氏名フリガナ
人の名前の姓のフリガナ
全角カタカナUTF-8
人の名前の名のフリガナ
全角カタカナ
UTF-8
性別
性別
人の性別
”男”、”女”
UTF-8
生年月日 生年月日
年号
人が生まれた年の暦または年号 ”西暦”、”明治”、”大正”、”昭和”、”平成” UTF-8
年
人が生まれた年の数字半角数字。西暦の場合4桁、その他2桁
UTF-8
月
人が生まれた月
半角数字。1～12
UTF-8
日
人が生まれた日
半角数字。1～31
UTF-8
住所
住所
都道府県名
都道府県の名称
全角
UTF-8
都道府県名フリガナ 都道府県名のフリガナ
全角カタカナ
UTF-8
都道府県コード
都道府県のコード
半角
UTF-8
市区町村名
市区町村の名称
全角
UTF-8
市区町村名フリガナ 市区町村名のフリガナ
全角カタカナ
UTF-8
市区町村コード
市区町村のコード
半角
UTF-8
大字通称
大字通称の名称
全角
UTF-8
大字通称フリガナ
大字通称のフリガナ
全角カタカナ
UTF-8
大字通称コード
大字通称のコード
半角
UTF-8
町丁字等名称
町丁字等の名称
全角
UTF-8
町丁字等名称フリガナ 町丁字等の名称のフリガナ
全角カタカナ
UTF-8
町丁字等コード
町丁字等のコード
半角
UTF-8
番地
番地
全角
UTF-8
建物名
建物の名称
全角
UTF-8
棟番号
棟の番号
全角
UTF-8
部屋番号
部屋番号
全角
UTF-8
郵便番号 郵便番号
上３桁
郵便番号の上３桁
半角
UTF-8
下４桁
郵便番号の下４桁
半角
UTF-8
電話番号 固定電話番号
市外局番
電話番号の市外局番
半角
UTF-8
市内局番
電話番号の市内局番
半角
UTF-8
加入者番号
電話番号の加入者番号
半角
UTF-8
携帯電話番号
識別番号
携帯電話番号の識別番号
半角
UTF-8
事業者番号
携帯電話番号の事業者番号
半角
UTF-8
加入者番号
携帯電話番号の加入者番号
半角
UTF-8
FAX
市外局番
電話番号の市外局番
半角
UTF-8
市内局番
電話番号の市内局番
半角
UTF-8
加入者番号
電話番号の加入者番号
半角
UTF-8
電子メール 電子メールアドレス
電子メールのアドレス
半角@半角
UTF-8

図６－５ 基本共通データ項目（レベル０）定義例

72

単位
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし

③目的別共通データ項目の定義例
図６－６に、レベル 1 の目的別共通データ項目の定義例を示す。前述のように、レベル 1 では、レベル 0 の基本共通データ項目について、官民連携ポータルの目的にあわせ、さらに細かい規定が必要なものについて、レベル 1 のデータ項目を定義する。書式、文字コード、単位、
データ構造、粒度・意味などは基本的にレベル 0 の定義を利用する。こうした内容が公開されれば、官民連携ポータルの事業化に役立てることができ、官民連携ポータル事業者と各事業者間のデータ連携に関する負担軽減にもつながる。なお、この表はサンプルであり、表中のデータ項目の種別や、各データ項目の定義内容などは実際に標準化される内容とは異なる。
レベル０
データ項目
氏名

住所

レベル１
データ項目

データ構造
上位項目

申込者氏名

申込者氏名

送付者氏名

送付者氏名

移転元住所

移転元住所

移転先住所

移転先住所

送付先住所

送付先住所

レベル０

レベル１

意味

下位項目

申込者氏
手続を申し込んだ人の名前の姓
全角
申込者名
手続を申し込んだ人の名前の名
全角
送付者氏
手続の結果を送付する宛名の姓
全角
送付者名
手続の結果を送付する宛名の名
全角
移転元都道府県名
移転元の都道府県の名称
全角
移転元都道府県名フリガナ 移転元の都道府県名のフリガナ
全角カタカナ
移転元都道府県コード
移転元の都道府県のコード
半角
移転元市区町村名
移転元の市区町村の名称
全角
移転元市区町村名フリガナ 移転元の市区町村名のフリガナ
全角カタカナ
移転元市区町村コード
移転元の市区町村のコード
半角
移転元大字通称
移転元の大字通称の名称
全角
移転元大字通称フリガナ
移転元の大字通称のフリガナ
全角カタカナ
移転元大字通称コード
移転元の大字通称のコード
半角
移転元町丁字等名称
移転元の町丁字等の名称
全角
移転元町丁字等名称フリガナ 移転元の町丁字等の名称のフリガナ
全角カタカナ
移転元町丁字等コード
移転元の町丁字等のコード
半角
移転元番地
移転元の番地
全角
移転元建物名
移転元の建物の名称
全角
移転元棟番号
移転元の棟の番号
全角
移転元部屋番号
移転元の部屋番号
全角
移転先都道府県名
移転先の都道府県の名称
全角
移転先都道府県名フリガナ 移転先の都道府県名のフリガナ
全角カタカナ
移転先都道府県コード
移転先の都道府県のコード
半角
移転先市区町村名
移転先の市区町村の名称
全角
移転先市区町村名フリガナ 移転先の市区町村名のフリガナ
全角カタカナ
移転先市区町村コード
移転先の市区町村のコード
半角
移転先大字通称
移転先の大字通称の名称
全角
移転先大字通称フリガナ
移転先の大字通称のフリガナ
全角カタカナ
移転先大字通称コード
移転先の大字通称のコード
半角
移転先町丁字等名称
移転先の町丁字等の名称
全角
移転先町丁字等名称フリガナ 移転先の町丁字等の名称のフリガナ
全角カタカナ
移転先町丁字等コード
移転先の町丁字等のコード
半角
移転先番地
移転先の番地
全角
移転先建物名
移転先の建物の名称
全角
移転先棟番号
移転先の棟の番号
全角
移転先部屋番号
移転先の部屋番号
全角
送付先都道府県名手続の結果の送付先の都道府県の名称
全角
送付先都道府県名フリガナ 手続の結果の送付先の都道府県名のフリガナ 全角カタカナ
送付先都道府県コード手続の結果の送付先の都道府県のコード
半角
送付先市区町村名
手続の結果の送付先の市区町村の名称
全角
送付先市区町村名フリガナ 手続の結果の送付先の市区町村名のフリガナ 全角カタカナ
送付先市区町村コード手続の結果の送付先の市区町村のコード
半角
送付先大字通称
手続の結果の送付先の大字通称の名称
全角
送付先大字通称フリガナ
手続の結果の送付先の大字通称のフリガナ
全角カタカナ
送付先大字通称コード
手続の結果の送付先の大字通称のコード
半角
送付先町丁字等名称
手続の結果の送付先の町丁字等の名称
全角
送付先町丁字等名称フリガナ 手続の結果の送付先の町丁字等の名称のフリガ全角カタカナ
送付先町丁字等コード
手続の結果の送付先の町丁字等のコード
半角
送付先番地
手続の結果の送付先の番地
全角
送付先建物名手続の結果の送付先の建物の名称
全角
送付先棟番号手続の結果の送付先の棟の番号
全角
送付先部屋番号
手続の結果の送付先の部屋番号
全角

書式

文字コード
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8

単位
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし

図６－６ 目的別共通データ項目（レベル１）定義例④各レベルのデータ項目選定・定義スキーム
レベル 0 の基本共通データ項目の選定・定義スキームとしては、データ標準化 WG・協議会が民間標準化組織からの提案状況等を踏まえ、既存のデータ標準仕様などを考慮しながら、基本共通データ項目を選定した後、それぞれの項目に対する属性情報を定義し、決定することを想定する。
レベル 1 の目的別共通データ項目の選定・定義スキームとしては、次のとおり想定する。まず、民間標準化組織において、官民連携ポータル事業者からの要望などに基づき、目的別
共通データ項目の用途や必要性を検討する。次にレベル 0 の基本共通データ項目の定義内

73

容を参照した上で、データ標準化 WG・協議会の決定内容等を踏まえながら、目的別共通データ項目の選定や定義案を作成し、データ標準化 WG に提案を行う。データ標準化 WG において、提案された内容について、レベル 0 や他のレベル 1 のデータ項目との整合性や新規に定義する必要性などの観点から検討を行ったうえで、協議会において最終的な定義内容の協議・オーソライズを行う。
５）官民連携データセットの検討
データ標準化 WG では、電子自治体における様々な場面で共通して利用されるデータを中心に、共通部品スキーマの策定・利用に関するガイドラインを検討している。現在検討されている共通部品スキーマは、次表のとおり、官民連携データセットのうち、基本共通データ項
目に相当し、各項目について、RELAX NG、W3C XML Schema、DTD の３種類のスキー
マ言語による定義が行われている。また、共通部品スキーマの策定にあたっては、電子政府との整合を図るため、前述の「申請データ設計ガイドライン」及び「電子申請用 XML 様式の設
計ガイドライン」の内容を踏まえて検討されている。なお、データ項目については、今後順次追加が行われる予定である。
表６－１ 共通部品スキーマ（抜粋）区分

タグセット名

意味

人

氏名

人の名前

場所

住所

個人や法人の所在地等住所の情報を含むもの74

XML 定義<氏名><氏><フリガナ> </フリガナ><漢字> </漢字></氏><名><フリガナ> </フリガナ><漢字> </漢字>
</名>
</氏名>
<住所>
<都道府県><フリガナ> </フリガナ><都道府県名> </都道府県名></都道府県><市区町村><フリガナ> </フリガナ><漢字> </漢字></市区町村><町域><フリガナ> </フリガナ><漢字> </漢字>
</町域>
<番地>
<フリガナ> </フリガナ><漢字> </漢字>
</番地>
<建物等>
<フリガナ> </フリガナ><漢字> </漢字></建物等>
</住所>

時間

郵便番号

郵便番号

<郵便番号>

日付・西暦

西暦で表現する日付

日付・和暦

和暦で表現する日付<日付・西暦><年> </年><月> </月><日> </日></日付・西暦><日付・和暦><元号> </元号><年> </年><月> </月><日> </日></郵便番号></日付・和暦>

年度・西暦

西暦で表現する年度

年度・和暦

和暦で表現する年度<年度・西暦><年> </年></年度・西暦><年度・和暦><元号> </元号><年> </年></年度・和暦>

６）実証実験におけるデータセット仕様の検討
今回の実証実験では、札幌、関東、関西の３地域の引越し手続ポータル間連携のため、引越し手続で必要とされる共通的なデータ仕様が検討された。
データ仕様の策定にあたって、主に、関東と関西の２地域のポータルにおけるデータ定義を参照し、以下のような方針により検討が進められた。この方針は、本項の 2)データ項目の選定、3)標準化要素の検討、4)官民連携データセットの策定手順の検討の考え方を踏まえたものとなっている。
ア． 各ポータルで使用しているデータセットから、ポータル間の連携に最低限必要なデータ項
目を選定する。
イ． 書式については、複数のポータルで定義され、定義が異なるデータ項目については、それぞれのメリット・デメリットを比較し、JIS コードなど公的な規格の適用など、今後の拡張性を踏まえ検討する。
ウ． 文字コードについては、UTF-8 を使用する。
エ． 構造については、各データ項目の要素を意味レベルの最小単位に細分化する。
オ． 粒度・意味については、郵便番号、住所、氏名などの基本共通データ項目を定め、その項目属性を用いて、XML の階層構造により申請者情報、移転元情報、移転先情報、送付先情報を定義する。
カ． その他、コード類の体系について、公的な規格がないものについては、オリジナルで定義を行う。
今回の実証実験で策定したデータ仕様案を参考資料１７に示す。なお、詳細については、
官民連携ポータルに関する開発・実証事業の報告書を参照のこと。

75

今回の実証実験において策定されたデータ項目のうち標準化が望ましいデータ項目もあると考えられ、これらも含めて、今後、データ標準化 WG において、更に基本共通データ項目を拡充させる検討が行われることが期待される。
（５）官民連携データセットの利用に関する検討事項
官民連携ポータル事業者が官民連携ポータルサイトを構築する場合、申請受付事業者などとの連携に関するコストを削減できることが期待されることから、策定された官民連携データセットをそのまま利用することが望ましいと考える。この場合、官民連携データセットの利用を促進するためには、技術者を支援し官民連携ポータル構築コストを低減させることが必要である。その手段としてチュートリアルや検査ツールの提供が挙げられる。
しかし、現状においては、申請受付事業者である民間企業の情報システムは、既に独自のデータセット（以下、「民間データセット」という）により構築されているものも多いことから、官民連携データセットと民間データセットの間でデータ変換が必要になることも想定される。こうした場合に、官民連携データセットと民間データセットの対応関係が明らかにされていれば、官民連携ポータルサイトと申請受付事業者システム間のデータ変換が容易になり、システム連携コストを低減することができ、官民連携ポータル事業が広がっていくことが期待できる。また、将来的に民間データセットから官民連携データセットへの移行を促進する効果も期待できる。
このような官民連携データセットと民間データセットの対応関係に関して検討すべき課題として、以下の３点が挙げられる。
①官民連携データセットと民間データセット間でのデータ項目の対応付け方法に関する検討
官民連携データセットと民間データセット間でデータ交換を行うため、それぞれのデータ項
目間の対応付けを行う必要があり、対応付けの形式や手順に関する検討を行う必要がある。
②データセット間の対応関係の改訂に関わる検討
官民連携データセットにおいて新たなデータ項目が追加された際に当該データ項目と民間
データセットにおいて該当するデータ項目との対応関係を追加したり、新たな民間データセッ
トとの対応関係を追加するなど、データセット間の対応関係の追加・変更等を行う場合の方法や手順などに関する検討を行う必要がある。
③データセット間の対応関係の申請受付事業者等への提供に関する検討
官民連携データセットと民間データセット間の対応関係を公開し、申請受付事業者から参照させることで、官民連携ポータルへの連携を促進させることが期待できる。この対応関係の公開や利用の仕組みに関する検討が必要である。
上記について、以下の項目で詳細を説明する。

76１）チュートリアルの作成
官民連携データセットの利用を促進するためには、単にデータセット仕様の公開を行うだけではなく、その仕様をもとに、どのようにして実際のデータセットを策定すれば良いかをチュー
トリアルとしてまとめ、公表することにより、官民連携ポータルサイトのシステム設計者、構築者の支援を行うことが望ましい。
例えば、引越しポータルを提供したいと考えている官民連携ポータル事業者が、申請受付
事業者との間で受け渡しを行うデータセット仕様を定めようとする場合、以下のような内容が記述されていると便利である。
①標準化済み基本共通データ項目の利用方法の解説
標準化されたレベル０の基本共通データ項目に関し、各データ項目の解説や、データ項目の利用方法について、説明・例示。
引越しポータル向けのデータ項目定義を行いたい場合、まずは既に標準として定まっている基本共通データ項目をそのまま使用することが考えられる。チュートリアルの内容は、基本
共通データ項目の書式、構造、意味、スキーマなどの定義内容についての分かりやすい説明
や、基本共通データ項目の中から自システムで必要なデータ項目を抽出する手順の説明などが考えられる。ただし、基本共通データ項目は、共通性の高いデータ項目の集合であり、システムでの処理にそのまま使用できない場合もあるため、あわせて注意事項として盛り込む必要がある。
②標準化済み目的別共通データ項目の利用方法の解説
標準化されたレベル１の目的別共通データ項目に関し、各データ項目の解説やデータ項
目の利用方法についての説明・例示。
引越しポータル向けの目的別共通データ項目がすでに策定されている場合、既に標準として定まっている目的別共通データ項目をそのまま使用することが考えられる。チュートリアルの
内容は、目的別共通データ項目の書式、構造、意味、スキーマなどの定義内容についての分
かりやすい説明や、目的別共通データ項目の中から自システムで必要なデータ項目を抽出する手順の説明などが考えられる。
③新たな目的別共通データ項目の設計手順の解説
目的別共通データ項目を設計するための手順や考慮すべき事項、注意すべき事項について説明・例示。

77

引越しポータル向けの目的別共通データ項目としてまだ定義されていないデータ項目を使用したい場合、新たにデータ項目を設計して使用することが考えられる。この場合、レベル０の基本共通データ項目の定義を参照し、その定義に準拠して目的別共通データ項目を設計することになる。チュートリアルの内容は、この手順において、基本共通データ項目の選定方
法、目的別共通データ項目の意味の粒度の考え方、タグ名の設計方法、書式、構造、スキー
マなどの定義方法などの説明が考えられる。
④新たな基本共通データ項目の設計手順の解説
基本共通データ項目を設計するための手順や考慮すべき事項、注意すべき事項について
説明・例示。
引越しポータル向けの目的別共通データ項目としてまだ標準化されておらず、かつその上位項目の共通データ項目にも適当な定義内容が存在しない場合、新たに共通データ項目から設計して使用することが考えられる。チュートリアルの内容は、この手順において、基本共通
データ項目の意味の粒度の考え方、タグ名、書式、構造、スキーマなどの定義方法などの説
明が考えられる。
⑤標準化手順の解説
上記③や④で新たに策定した基本共通データ項目や目的別共通データ項目を標準化したい場合のため、チュートリアルの内容は、標準化に必要な手続きの解説、標準化作業の概要の説明などが考えられる。
⑥データセット間のデータ項目対応付けの解説
官民連携ポータル事業者が既に民間データセットでシステムを構築している場合、チュート
リアルでは官民連携データセットと民間データセットとの間のデータ項目の対応付け方法に関する解説があることが望ましい。また、既に他で対応付けが行われている場合、その対応関係を参照することも考えられる。これらの手順について、詳細を次項以降で説明する。
２）検査ツールの提供
チュートリアルを用いて作成したデータセットが、正しく標準仕様の通りに作成されているかどうかを検査するツールがウェブで公開されれば、これを利用することで、データセット設計の作業負荷を軽減することが可能となる。ツールの概要としては、CGI 型のプログラムとし、作成したデータセットが格納された URI を指定することで、ツールがスキーマの定義などをチェック
し、問題がある箇所についてはエラーメッセージを表示するなどの機能が考えられる。

78

３）データセット間のデータ項目対応付け方法
官民連携データセットと民間データセット間でのデータ項目の対応付け方法としては、図６－７のようなデータセット同士のデータ項目の対応関係を表す表（以下、「データセット対応表」という）を用いて、官民連携データセットの定義内容に対する各民間データセットのデータ
項目の対応関係を表すことができる。この表は、官民連携ポータル事業者からの要望により、
民間標準化組織で策定し、官民連携ポータル事業者や申請受付事業者により利用されることを想定している。データセット対応表利用のイメージは後述する。なお、この表はサンプルであり、表中のデータ項目の種別や、各データ項目の定義内容、対応する民間データセットな
どは実際に標準化・作成される内容とは異なる。
官民連携データセット
レベル０
レベル１
データ項目 データ項目 上位項目
氏名

住所

データ構造
下位項目

引越れんらく帳

意味

タグ名

全角
全角
全角
全角
全角
全角カタカナ
半角
全角
全角カタカナ
半角
全角
全角カタカナ
半角
全角
全角カタカナ
半角
全角
全角
全角
全角
全角
全角カタカナ
半角
全角
全角カタカナ
半角
全角
全角カタカナ
半角
全角
全角カタカナ
半角
全角
全角
全角
全角
全角
全角カタカナ
半角
全角
全角カタカナ
半角
全角
全角カタカナ
半角
全角
全角カタカナ
半角
全角
全角
全角
全角

文字コード 単位 タグ名
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8

なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし

B1
B2
B3
B4
B5
B6
B7
B8
B9
B10
B11
B12
B13
B14
B15
B16
B17
B18
B19
B20
B21
B22
B23
B24
B25
B26
B27
B28
B29
B30
B31
B32
B33
B34
B35
B36
B37
B38

書式
全角
全角
全角
半角
全角
半角
全角
半角
全角
半角
全角
全角
全角
全角
全角
半角
全角
半角
全角
半角
全角
半角
全角
全角
全角
全角
全角
半角
全角
半角
全角
半角
全角
半角
全角
全角
全角
全角

文字コード
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8
UTF-8

単位
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし
なし

民間データセット

申込者氏名 申込者氏名 申込者氏
手続を申し込んだ人の名前の姓
A1
申込者名
手続を申し込んだ人の名前の名
A2
送付者氏名 送付者氏名 送付者氏
手続の結果を送付する宛名の姓
A3
送付者名
手続の結果を送付する宛名の名
A4
移転元住所 移転元住所 移転元都道府県名
移転元の都道府県の名称
A5
移転元都道府県名フリガナ 移転元の都道府県名のフリガナ
A6
移転元都道府県コード
移転元の都道府県のコード
A7
移転元市区町村名
移転元の市区町村の名称
A8
移転元市区町村名フリガナ 移転元の市区町村名のフリガナ
A9
移転元市区町村コード
移転元の市区町村のコード
A10
移転元大字通称
移転元の大字通称の名称
A11
移転元大字通称フリガナ
移転元の大字通称のフリガナ
A12
移転元大字通称コード
移転元の大字通称のコード
A13
移転元町丁字等名称
移転元の町丁字等の名称
A14
移転元町丁字等名称フリガナ 移転元の町丁字等の名称のフリガナ
A15
移転元町丁字等コード
移転元の町丁字等のコード
A16
移転元番地
移転元の番地A17
移転元建物名
移転元の建物の名称
A18
移転元棟番号
移転元の棟の番号
A19
移転元部屋番号
移転元の部屋番号
A20
移転先住所 移転先住所 移転先都道府県名
移転先の都道府県の名称
A21
移転先都道府県名フリガナ 移転先の都道府県名のフリガナ
A22
移転先都道府県コード
移転先の都道府県のコード
A23
移転先市区町村名
移転先の市区町村の名称
A24
移転先市区町村名フリガナ 移転先の市区町村名のフリガナ
A25
移転先市区町村コード
移転先の市区町村のコード
A26
移転先大字通称
移転先の大字通称の名称
A27
移転先大字通称フリガナ
移転先の大字通称のフリガナ
A28
移転先大字通称コード
移転先の大字通称のコード
A29
移転先町丁字等名称
移転先の町丁字等の名称
A30
移転先町丁字等名称フリガナ 移転先の町丁字等の名称のフリガナ
A31
移転先町丁字等コード
移転先の町丁字等のコード
A32
移転先番地
移転先の番地
A33
移転先建物名
移転先の建物の名称
A34
移転先棟番号
移転先の棟の番号
A35
移転先部屋番号
移転先の部屋番号
A36
送付先住所 送付先住所 送付先都道府県名手続の結果の送付先の都道府県の名称 A37
送付先都道府県名フリガナ 手続の結果の送付先の都道府県名のフリ A38
送付先都道府県コード手続の結果の送付先の都道府県のコード A39
送付先市区町村名
手続の結果の送付先の市区町村の名称 A40
送付先市区町村名フリガナ 手続の結果の送付先の市区町村名のフリ A41
送付先市区町村コード手続の結果の送付先の市区町村のコード A42
送付先大字通称
手続の結果の送付先の大字通称の名称 A43
送付先大字通称フリガナ
手続の結果の送付先の大字通称のフリガ A44
送付先大字通称コード
手続の結果の送付先の大字通称のコード A45
送付先町丁字等名称
手続の結果の送付先の町丁字等の名称 A46
送付先町丁字等名称フリガナ 手続の結果の送付先の町丁字等の名称のA47
送付先町丁字等コード
手続の結果の送付先の町丁字等のコード A48
送付先番地
手続の結果の送付先の番地
A49
送付先建物名手続の結果の送付先の建物の名称
A50
送付先棟番号手続の結果の送付先の棟の番号
A51
送付先部屋番号
手続の結果の送付先の部屋番号
A52

書式

図６－７ データセット対応表のイメージ
４）データセット間の対応関係の改訂に関わる検討
データセット対応表に関わる検討として、次のようなケースを想定した手続き・手順あるいはルールなどが必要と考えられる。具体的な手順の内容については、今後の検討課題とする。
①共通データ項目の改訂手順の必要性
官民連携ポータルにおいて、新たな共通データの取り扱いが必要となった場合、官民連携

79

データセットと民間データセットでの新たな対応関係を定義するためには、官民連携データセットのレベル 0 あるいはレベル 1 のデータ項目を定義する必要がある。官民連携データセット
への新たなデータ項目定義のスキームは、前述の官民連携データセットの各レベルのデータ
選定・定義スキームに準ずるが、官民連携データセットに新たなデータ項目が追加された後、データセット対応表の改訂に関わる手順などを明らかにしておく必要がある。
②民間データセットの追加・改訂の必要性
新たに民間データセットをデータセット対応表に追加したり、データセット対応表の定義内
容を変更したい場合のケースである。これは、官民連携ポータル事業者などが、他の事業者に対してポータルサイトへの接続を促すなどの目的で、既に使用している独自データセットと官民連携データセットとの対応関係を明らかにしたい場合などが該当する。データセット対応
表に新たな対応関係を追加したり、その内容を変更したりするようなデータセット対応表の維持管理に関する手続きあるいは手順などを明らかにしておく必要がある。
５）データセット対応表の公開・提供方法
データセット対応表の官民連携ポータル事業者や申請受付事業者への提供スキームとして、図６－８のような仕組みが考えられる。官民連携ポータル事業者や申請受付事業者は、前述のように他者との連携において、データセット間のデータ項目の対応関係を容易に把握できることで、連携のための負荷を軽減することができる。このため、データセット対応表を検索ツール等により官民連携ポータル事業者あるいは申請受付事業者向けの参照情報として提供されることが望ましい。データセット対応表の提供のためには、前述のようにデータセット対応表を維持管理するための仕組みが必要である。また、データセット対応表を効率よく利用するためには、官民連携ポータル事業者や申請受付事業者が欲する検索条件により、必要なデータ項目に関する情報などの検索が行えることが望ましい。具体的なツールの仕様については、さらに検討を行う必要がある。
対応表の利用者への提供

検索ツール
データセット対応表

データセットの選定
登録・更新

対応表の追加変更等

参照情報

官民連携ポータル事業者／
官民連携ポータル事業者／
接続事業者
接続事業者

官民連携標準化
官民連携標準化
組織
組織

データセット間のデータ
項目の対応付け

官民連携
官民連携
ポータル事業者
ポータル事業者

図６－８ データセット対応表の利用イメージ80

７ まとめ
このように、官民連携ポータルの実現、拡充を推進するためには、様々な課題が存在する
ことが改めて確認された。以下、課題を中心に今後の対応の方向性についてまとめる。
１）個人認証方法に関する観点から手続き数が多くなるほど、個人認証を個別に行うのではなく、信頼性の高い認証方法でワンストップで行うことができるほうが、利用者の利便性は高い。公的個人認証サービスを用いて、個人認証をワンストップ化できれば、認証の手間は大幅に軽減される。
公的個人認証サービスなどの、安全性・信頼性の高い電子認証（電子署名・電子証明書）
を積極的に活用し、国民の権利義務や財産に大きな影響を及ぼす手続きの電子化や、手続きにおける個人認証のワンストップ化を進めていく方向が望ましいと考えられるが、民間手続きにおいて、公的個人認証サービスの利用を可能とするためには、制度改正が必要である。
このため、個人情報保護に配慮しつつ、官民ポータルの主要な受付事業者となることが想定される公益事業者を中心に、公的個人認証サービスの利用範囲の拡大について検討することが適当と考えられる。
２）個人情報保護に関する観点から官民連携ポータルおよび手続き先のサイトなどにおいては、個人情報の取り扱いは慎重かつ厳格に行われるべきであるが、過剰になるあまり、利用者の利便性を損ねてはいけない。
利用者への的確な情報の提示と同意を得つつ、利用者にとって利便性の高いサービスを目指すことが重要である。
また、官民連携ポータルは、ポータル間やポータルと各手続きサイトなど、複数の運営主体によるサイト間を、利用者が行き来してサービスを利用することになるが、この際、サイト間で、プライバシーポリシーやセキュリティなどに格差がある場合、本来ならば利用者が全てのサイトのプライバシーポリシーやセキュリティの違いを把握し、確認した上で利用する必要があるが、手続きが多くなればなるほど現実的には困難である。
従って、官民連携ポータルが他のポータルと連携したり、手続き先サイトを選定する場合には、選定基準を設けて対応していくことが望まれる。さらには、ポータル業界全体としての基準があれば、より望ましい。
３）データ標準化に関する観点から地方公共団体におけるデータ標準化については、電子自治体のシステム構築のあり方に関する検討会データ標準化 WG やデータ標準化推進地方公共団体協議会において協議・
オーソライズが行われており、今後もこの枠組みのもとで標準化が進められることとなっている。民間においても具体的な標準仕様検討のための仕組みづくりを進め、図６－２の標準化

81

スキームのもとで官民連携データセットの標準化作業が進められることが期待される。
また、単にデータ標準を策定するだけではなく、策定された標準が実際に利用されるよう、
ガイドラインや各種ツール、チュートリアルなどの整備もあわせて検討していく必要がある。
４）ビジネスモデルの観点から
本検討会では、官民連携ポータルのビジネスモデルの検討のため、海外事例調査および関連事業者等へのヒアリングを行った。
海外事例（Iammoving.com など）での収益構造を参考にすると、対象手続きの拡大による利用者の拡大と広告媒体としての魅力向上、アフェリエイト（商用サイトなどに誘導する対価を収入として得る方式）などによる手続き提携先からの収入拡大など、収益性向上のための各種取り組みを推進することが必要性と考えられる。関連事業者へのヒアリングからは、連携拡大にむけた条件整備や、事業者にとってのメリット訴求の必要性などが指摘された。
また、実証実験の一環として、ビジネスモデルの検討が行われた。この中では、地域ポータルとの組み合わせによる収益可能性の拡大や、全国をつなぐ基幹系サービスと、地域でのサービスの連携の仕組みの必要性などが指摘されている。
さらには、ポータル事業者が立ち上げや初期段階のリスクを軽減するため、本検討会で検討したような共通の課題について、解決策を提示していくことも有効と考えられる。

82