データの相互運用性向上のためのガイド

(2019 年 12 月ワーキングドラフト)

官民データ活用社会の実現へ向けた取組みの手順と実装例

2019 年 12 月 20 日

独立行政法人情報処理推進機構(法人番号 5010005007126)

i

目次

本ガイドについて ............................................................... 1

ガイドの目的 .......................................................... 1

デジタルトランスフォーメーションへのアプローチ ......................... 3

ガイドの想定読者 ...................................................... 4

本ガイドが伝えること .................................................. 4

本ガイドの構成 ........................................................ 5

第 1 章 目指す社会と克服すべき課題 ............................................... 6

1.1 官民連携の情報基盤づくり .................................................. 6

エビデンスに基づく合意形成と政策推進 .................................. 6

スマートシティとデータ連携基盤 ........................................ 6

行政サービスを高度化するデジタルデータ ................................ 8

1.2 データ流通・連携を阻む壁 ................................................. 10

ブラックボックス化したシステム ....................................... 10

組織によって異なるデータ資産の捉え方 ................................. 11

「壁」の背景と今後 ................................................... 12

「壁」の具体例 ....................................................... 12

第 2 章 解決に向けたアプローチ .................................................. 15

2.1 情報を公開・交換するための手法 ........................................... 15

データ資産の棚卸と運用 ............................................... 15

用語やコードの意味の伝達 ............................................. 17

情報を公開・交換するインターフェイスの共通化 .......................... 22

データ項目がもつ意味や用語の共通化 ................................... 25

2.2 共通フォーマットと語彙体系の活用 ......................................... 28

データ連携標準の体系 ................................................. 28

推奨データセットにみる共通フォーマットの活用例 ........................ 28

定義をデジタルに共有する枠組み ....................................... 29

枠組みの活用方法 ..................................................... 30

意味の共有 ........................................................... 33

応用語彙の定義方法 ................................................... 34

語彙の構造 ........................................................... 36

2.3 法人インフォメーションへの適用例 ......................................... 39

概要 ................................................................. 39

第 3 章 実装方法を事例から学ぶ .................................................. 43

3.1 企業開示情報の相互運用基盤 XBRL .......................................... 43

XBRLの概要 ................................................................. 43

ii

XBRL以前の課題 ....................................................... 43

改善したこと ......................................................... 43

3.2 ステークホルダーニーズを取り込み、使われる標準を整備 地方公共団体 B ....... 44

概要 ................................................................. 44

導入前の課題 ......................................................... 44

解決したこと ......................................................... 44

成功要因 ............................................................. 44

3.3 省庁 A における DX 推進 .................................................... 45

概要 ................................................................. 45

導入前の課題 ......................................................... 45

解決を目指すこと ..................................................... 45

利用方法 ............................................................. 45

合意形成 ............................................................. 45

3.4 製造サプライチェーンでのデータ連携と辞書整備 .............................. 46

概要 ................................................................. 46

導入前の課題 ......................................................... 46

解決したこと ......................................................... 46

成功要因 ............................................................. 46

その他特徴、近況など ................................................. 46

3.5 業界横断のデータ取引市場活性化の取組み .................................... 47

概要 ................................................................. 47

導入前の課題 ......................................................... 47

解決したこと ......................................................... 47

成功要因 ............................................................. 47

3.6 米連邦政府 NIEM ........................................................... 48

概要 ................................................................. 48

導入前の課題 ......................................................... 48

解決したこと ......................................................... 48

成功要因 ............................................................. 48

第 4 章 将来を見据えた取組み .................................................... 49

組織の主体的な活動 ................................................... 49

進化し続ける「ことばの基盤」と新しい社会 ............................. 50

この文書について .............................................................. 52

1

本ガイドについて

ガイドの目的

データ活用社会の実現へ向けて

私たちの日々の活動は、「データ」1と切り離して考えることはできない。SNSやスマートデバイス上で休み

なく行き交う検索や投稿、決済、移動等の行動データ、また道路、製品、車やドローン等に取り付けられた

センサー等を介して収集されるデータ、経営活動に伴って生成される業務データなど、枚挙にいとまがない。

今日ではこうしたデータの活用2は、自立的で個性豊かな地域社会の形成、新事業の創出や産業の健全な発

展、国際競争力の強化に不可欠である3。ビジネスシーンでは、マーケティング、製造等の業務や研究開発で

新たな知見を得たり、アプリケーションやサービスを通じ利用者に何らかの便益を提供したりといった、あ

らゆる活動の源がデータである。本ガイドでは官民データ活用基本法第 2条4に従い、「官民データ」という。

近年の ITの潮流であるクラウドコンピューティング、5G、仮想化技術、分散システム等は、膨大なデータ

の収集・蓄積・処理・加工・移転等の処理をかつてないスピードで可能にするが、官民データという社会資

産が、安全かつタイムリーに、より多くの人やシステム、デバイスから発見され、活用されるためには、デ

ータをつないで活用する、データフェデレーション5の時代への転換が急務である。

個別組織の情報システム内に閉じていたデータはいま、組織や時空の壁を超え流通し活用されようとして

いる。公共機関等によるオープンデータ公開の取組みや、行政機関が保有する個⼈情報を特定の個⼈が識別

できないよう加⼯した「⾮識別加⼯情報」の活用も検討されている。また、データ取引市場や情報銀行を通

じてデータを売買する環境も整いつつある。

個々の組織がそれぞれ人材、時間や資金等を投じ事業活動を通じて蓄積・保有するデータが、利害関係者

(ステークホルダー)の合意や適切な運用ルールのもとで公表・共有・再利用されれば、新たなデータ収集の

必要が減り、社会的コストの低減につながる。その結果、価値創造へ向けた「官民データ活用」へ重心が移

り、顧客や国民へ、よりニーズに合致したサービスを提供できるだろう。

ビジネス環境の変化に対応できるように、データ資産と IT システムを切り分けて考えることも重要だ。顧

客情報など、組織として蓄積し保護すべきデータ資産は何かを見極める必要がある。また、組織内に必要以

1 JIS X 0001における「データ」の定義は「情報の表現であって、伝達、解釈又は処理に適するように形式化され、再度情報として解

釈できるもの」とされているが、本ガイドではとくに記載がない限り、電子的に記録されたデジタルデータを「データ」という。

2 「データ活用」に明確な定義はないようだが、本ガイドでは、「1.1.1エビデンスに基づく合意形成と政策推進」等で説明するように、

ある事象をデジタルデータとしてインプットし分析や加工などの処理を行うことによってより良いアウトプットを求め、ビジネス等

の目的を達成するための営みと考えている。

3 官民データ活用基本法第 3条より。

4 公共機関及び事業者により、事務又は事業の遂行に当たり、管理され、利用され、又は提供される電磁的記録と定義されている。

5 フェデレーションという表現を、本ガイドでは「緩やかな連携」の意図をもって使っている。

2

上のデータをもたずに足りないデータは外部データで補い、それら内外のデータをつないで活用することが

求められる。20世紀から行われてきたように電子ファイル等による取引も可能だが、物理的に移転させず「つ

なぐ」ことを意味するフェデレーションが、データ取引における金銭面及び物流やエネルギー・環境の側面

からも社会的負荷が小さくなる。データ移転にもコストがかかっている。

一方、ITシステムはクラウドを視野に入れ、その時点で最も良いものを市場から調達し、更新できる。た

だし、組織のコントロール下にないクラウドサービス環境等の利用も含むことから、データに求められる要

件は変わる。例えばポータビリティ、トレーサビリティ、社会的合意に基づく品質基準などだ。重要なのは、

相互運用性(Interoperability)6の考え方である。

つながる官民データ活用社会では、データ作成者・保有者・利用者といった参加者に、相互運用性の理解

と参加の姿勢が求められる。これから向かうのは、データの活用、取扱いに際しての倫理観と透明性が、社

会的合意として共有される社会である。よりよいデータ活用社会の創造には、作り手・担い手としての参加

者の自発的かつ責任のある行動が欠かせない。

誰がどのようなデータをどう保有しているかという情報が社会全体として伝わりやすくなり、取引または

交換されたデータを、誰もが自分のデータ資産と組み合わせて活用できる意義、そしてそのためにデータ資

産を保有する組織に求められる資産管理手法や心構えをお伝えすることが、本ガイドの目的である。

政策における本ガイドの位置づけ

データ利活用及びその手段としての相互運用性向上は、官民データ活用推進基本法及び Society 5.0 をは

じめとする政策に基づく。

官民データ活用推進基本法は、官民データの適正かつ効果的な活用の推進に関する施策を総合的かつ効果

的に推進し、国民が安全で安心して暮らせる社会及び快適な生活環境の実現に寄与する目的で、2016年 12月

に制定された。データの「保護」一辺倒から、「適正な活用」への転換を目指すものである。相互運用性向上

の取組みは、第 15 条(情報システムに係る規格の整備及び互換性の確保等)に該当する。

[第 15 条 1 項]

国及び地方公共団体は、官民データ活用に資するため、相互に連携して、自らの情報システムに係る規格の整

備及び互換性の確保、業務の見直しその他の必要な措置を講ずるものとする。

[第 15 条 2 項]

国は、多様な分野における横断的な官民データ活用による新たなサービスの開発等に資するため、国、地方公

共団体及び事業者の情報システムの相互の連携を確保するための基盤の整備その他の必要な措置を講ずるもの

とする。

図 1-1 官民データ活用推進基本法

(1)で述べた変化に対応し、我が国の掲げるビジョンがある。それが先端技術をあらゆる産業や社会生活に

取り入れ、経済発展と社会的課題の解決を両立する新たな社会「Society 5.0」だ。

Society 5.0 は、社会の変革(イノベーション)を通じて、これまでの閉塞感を打破し、希望のもてる社会、

6 JIS X 0001は「それぞれの機能単位に固有な特性に関する知識を利用者がほとんど又は全く必要とせずに，各機能単位が互いに通信

し，プログラムを実行し又はデータを転送する能力」と定義している。「3.1企業開示情報の相互運用基盤」でとりあげる会計報告事

例のように、社会的に共通なルールが電子化されていて、言語に関わらず、ルールがナレッジとして共有できる状態を指す。

3

世代を超えて互いに尊重し合あえる社会、一人ひとりが快適で活躍できる社会を目指す。その大前提は、デ

ータ活用である。とくにフィジカル(現実)空間すなわち製造、農業、医療等の現場で生成されるデータは、

サイバー(仮想)空間でのデータ活用に遅れる日本が、巻き返し可能な領域として期待されている。

図 1-2 サイバー空間とフィジカル空間を高度に融合させる Society 5.0 のイメージ

(出典)内閣府 Society 5.0 広報ページ https://www.gov-online.go.jp/cam/s5/

デジタルトランスフォーメーションへのアプローチ

2018年 9 月に経済産業省が発表した「デジタルトランスフォーメーションレポート～ITシステム「2025年

の崖」の克服と DX の本格的な展開～」(以下、DX レポート)7は、Society 5.0 実現へ向けた政策とともに、

個々の企業におけるデジタルトランスフォーメーション(DX)の必要性を指摘している。

(日本政府は)政策として、様々な人やモノ、企業、産業等が相互に繋がることによってデータが流通し、新たな

付加価値が創出され、社会課題が解決できる産業の姿：“Connected Industries”を実現していくための施策を

推進している。しかし、“Connected Industries”を実現するためにも、個々の企業が DX を着実に実行してい

くことが不可欠であり、情報サービス産業がそれを支えるビジネスを展開していくことが極めて重要である。

図 1-3 DXレポートより抜粋

官民データの相互運用性向上は、DXの加速と表裏一体である。DXの定義は様々だが、提唱者エリック・ス

トルターマン教授は「IT の浸透が、人々の生活をあらゆる面でより良い方向に変化させる」概念、「DX 推進

指標」は「企業がビジネス環境の激しい変化に対応し、データとデジタル技術を活用して、顧客や社会のニ

ーズを基に、製品やサービス、ビジネスモデルを変革するとともに、業務そのものや、組織、プロセス、企

業文化・風土を変革し、競争上の優位性を確立すること」としている8。いずれにせよ、実現には円滑なデー

タ活用が不可欠である。

2019 年 10 月の消費増税時に始まったキャッシュレス・ポイント還元事業で、3600 ページに及ぶ参加店舗

の PDF ファイルが問題になった際、ある企業が PDF からデータを抽出し、たった 1 日で店舗検索アプリを開

7 https://www.meti.go.jp/shingikai/mono_info_service/digital_transformation/pdf/20180907_03.pdf

8 DXレポートをふまえ 2019年 7月に公表された DX自己診断指標。https://www.meti.go.jp/press/2019/07/20190731003/20190731003-

1.pdf

4

発、公開した事例は記憶に新しい9。データとシステムを分けることにより、「消費者がポイント還元店舗をス

ムーズに見つける」という体験が創造された10。

顧客起点を価値に掲げる限り、またデータや技術を取り巻く環境が革新を続ける限り、DXの取組みに終わ

りはない。組織には官民を問わず、変化を前提としたビジョンを内外に示し、データに基づく変革へ向けた

活動を素早く実行し顧客と語り合える体制とビジネスプロセスが求められる。データが共通言語として活用

される、組織風土や文化の醸成も欠かせない。

そして日本全体で DX が進むために、データの相互運用という文脈における官民をあげた協調領域を形成

し、データを活用しやすい社会を実現していかなければならない。

ガイドの想定読者

本ガイドの主たる想定読者は、オープンデータ、データ流通市場で取引されるデータ、社内システム上の

データを問わず、官民データ活用に携わるあらゆるステークホルダーである。「第 1章目指す社会と克服すべ

き課題」「2.1 情報を公開・交換するための手法」で説明する相互運用性の意義、「第 3 章実装方法を事例から

学ぶ」には、CDO(Chief Data Officer)あるいは CDO(Chief Digital Officer)、CIO(Chief Information

Officer)をはじめ、全ての参加者にお読みいただきたい。相互運用性の高いオープンデータの作成・公開を

求められる自治体と公共機関には、あらためて取組みの意義をご理解いただきたい11。

具体的な実装方法は、「第 2 章解決に向けたアプローチ」で、データモデル12設計を中心に説明する。CDOや

CIO、データ活用の取組み全般を統括するデータステュワードやデータモデル設計者を統括するデータ管理者、

データモデル設計者、アプリなどのシステム開発に携わるエンジニアに、とくにお読みいただきたい。

データ利用シーンは、データ自体を扱う場合もアプリやクラウドサービスのウェブアプリ等のツールを通

じたデータ処理の結果を活用する場合も考えられる。アナリストや、シビックテックを展開する市民もいる。

前述の通り、データ活用には、組織と日本社会の風土、文化が重要である。データを取り巻くあらゆるステ

ークホルダーが、相互運用性についての理解を深めていただきたい。

本ガイドが伝えること

本ガイドは、相互運用性の意義と官民データ活用時代に求められるデータ資産の扱い方をお伝えする。デ

ータを処理するシステムに深く関わるが、システムの話ではない。既存システムを改修したりデータを物理

的に移転したりしなくても、つながり合ったデータをより多くの組織や人々が正しく理解し活用できる社会

9 日本最大級のオンライン家計簿サービス「Zaim」増税後にキャッシュレス還元のある実店舗や EC 店舗 18 万件を一覧化「キャッシュ

レス還元マップ」を公開 https://zaim.co.jp/news/archives/4635

10 店舗データが公開当初から相互運用性を確保していれば、より多くのアプリやサービスが生まれた可能性もある。

11 「IMI共通語彙に対応したデータ公開手順」を併せて参照されたい。https://imi.go.jp/goi/datalifecycle/

12 ビジネスモデルやルール、事業間の関係など、企業が営む事業活動とデータとの関係を、適切な粒度で表現したデータ定義、データ

要件。事業におけるデータと処理の流れを定義し、必要に応じ図式化する。

5

へ向けたデータ相互運用性向上の手順と実装例を示していく。相互運用性は、DXレポートで指摘される「協

調領域13」を実現する、具体的な要件である。

データそしてデータモデルやデータ項目定義14、データカタログなどを含む経営資源としてのデータ資産が

形式知として管理されている状態は、資産を定義づけるビジネスやルールが、適切に管理され共有されてい

る状態と同義である。形式知は、あらゆるステークホルダーが理解しやすいよう、極力汎用的かつ誤解の余

地がない表現で記述されることが望ましい。すなわち、相互運用性が確保された状態である。

データに価値を見出し、活用するのはあくまで利用者である。利用目的や利用方法をデータ作成者があら

かじめ把握できない場合も、データセットの設計図であるデータモデルが明示されていれば、多様な利用者

がデータを活用しやすい。政府 CIO ポータルが自治体向けに公開する「推奨データセット」15も、データモデ

ル検討に係る自治体の負荷軽減と相互運用性の高いオープンデータ公開及び利活用促進を目的にしている。

本ガイドの構成

第 1章 目指す社会と克服すべき課題

データ活用が求められる背景、スマートシティを支える官民連携データ連携基盤など、国内外の動向を整

理する。またデータ活用やデータ流通を阻害する課題、その要因を整理した。

第 2章 解決に向けたアプローチ

第 1 章で示した課題を解決するためには、データ資産の可視化と、情報交換の仕組みや手続きの共通化が

必要である。既存システムとデータ資産を最大限活用した緩やかな連携(フェデレーション)による情報交換

の仕組みや語彙の体系化について、「法人インフォ」におけるデータ相互運用性向上の事例を交えて説明する。

第 3章 実装方法を事例から学ぶ

データの相互運用には、ステークホルダーの理解と協力が不可欠である。データ活用という協調領域にお

ける目的を共有し、相互運用性を実現する事例をとりあげる。運用プロセスやインセンティブの設計、ガバ

ナンスにおける知見をデータ連携基盤や自治体オープンデータ標準化などの先行事例から学ぶ。

第 4章 将来を見据えた取組み

データ相互運用性向上の取組みは、組織と社会が協調し、場とナレッジを共有しながら継続的に行う必要

がある。持続可能な組織体制やコミュニティ連携の展望を示す。

13 DXレポートには、協調領域の事例として、損保会社 6社と IT企業 3社が協調して保険会社共通の商品を扱う共同システムを構築し、

従来個別に構築していたシステムの運用コストを大幅に削減したケースなどが紹介されている。

14 データ項目のグループ単位後との名称、型、形式、値域などを表したもの。

15 自治体向けのオープンデータ共通フォーマット。https://cio.go.jp/policy-opendata

6

第1章 目指す社会と克服すべき課題

本章では、我が国がデータ利活用において目指す未来像と海外先行事例、克服すべき現状の課題を整理する。適切

かつ円滑なデータの流通・利活用を支える社会基盤の構築・運用には、官民の協力・協調が欠かせない。

1.1 官民連携の情報基盤づくり

エビデンスに基づく合意形成と政策推進

国や地方自治体では、EBPM(Evidence Based Policy Making16)が推進されている。政策立案及び効果の測定

に関連する情報や統計等のデータを活用した EBPMの推進は、政策の有効性を高め、国民の行政への信頼確保

に資する。EBPMには、個別政策によって生じる資源の競合を抑え、政策全体を俯瞰してみた場合のトレード

オフを回避・軽減する意義がある。客観性の高い合理的な根拠を用いることで、仮説の立案、政策実施の評

価、継続・修正の判断が的確かつ迅速になり、限られた財源や人的リソースの有効活用が期待される。

観光や商業分野では、地方自治体におけるパーソントリップデータ活用の事例が知られる。スマートフォ

ン等を介して得た個人の動的な非識別加工情報17を用いた実証実験だ。実験店舗の出店前後で人の流れがどう

変化したのかを可視化し、賑わい創出や、まちづくりに生かす取組みである。客観的なデータを市民と共有

し、対話のツールとして活用することで、政策を進める上でも有意義な議論や納得のいく合意形成が期待さ

れる。小さな試行錯誤を繰り返しつつ、結果をデータという証拠で可視化し改善を図ることにより、まちづ

くりに参加する市民や企業、行政職員などのモチベーションや一体感の向上につながる。

スマートシティとデータ連携基盤

Society 5.0 の先行的な実現の場として進む取組みが、スマートシティである。データと先進的技術の活

用により、地域の機能やサービスを効率化・高度化し、社会課題の解決を図り、快適性や利便性を含めた新

たな価値を創出する。EBPMの観点で官民そして市民等がデータを共有し、データに基づいて生活の品質向上

や経済発展を図る都市像だ。自治体及び企業・研究機関及び内閣府、総務省、経済産業省、国土交通省等を

会員とする「スマートシティ官民連携プラットフォーム」18が発足し、全国各地で取組みが進んでいる。

海外では、ごみや大気など 1 日約 300 万レコードのセンサーネットワークデータを都市 OS「Sentilo」に

集積し、市民サービスに活用するスペインのバルセロナなどが知られる。

16 証拠に基づく政策立案

17 個人情報を個人情報の区分に応じて定められた措置を講じて特定の個人を識別することができないように加工して得られる個人に関

する情報であって、当該個人情報を復元して特定の個人を再識別することができないようにしたもの。「行政ビッグパーソナルデータ」

などとも呼ばれる。EBPMや民間企業による利活用が期待されている。

18 https://www.mlit.go.jp/scpf/

7

図 1-1 日本のスマートシティの強み

(出典) スマートシティ官民連携プラットフォーム

オープンデータや非識別加工匿名情報、スマートデバイスや IoT 機器などを通じて得られる交通、エネル

ギー、土地、建物、人流や医療・健康・教育といった行政サービス等に関わる官民データをつなぎ組み合わ

せて処理することで、物流や資源利用の最適化、防災、防犯、住民の生活品質向上や互助の促進、行政サー

ビスの最適化と品質向上などが期待されている。

これらデータが安心・安全に流通するためには、第 2 章「解決に向けたアプローチ」で説明するように、

誰もが信頼できるデジタルデータの流通・利活用基盤が整っていなければならない。スマートシティアーキ

テクチャは、サービス(ビジネス)とアセット(データリソース)を標準 APIで接続する各分野の基盤と都市 OS

で構成される。都市 OSは、共通機能群と、データカタログ、データポリシー、語彙・コードなどを含む分野

間データ連携基盤で構成される。

図 1-2 日本におけるスマートシティアーキテクチャのイメージ19

(出典)「戦略的イノベーション創造プログラム(SIP)第 2 期 ビッグデータ・AI を活用したサイバー空間基盤技術」における

アーキテクチャ構築及び実証研究

19 2019年時点のイメージ。内閣府実施、国立研究開発法人新エネルギー・産業技術総合開発機構が管理法人を務める「戦略的イノベー

ション創造プログラム(SIP)第 2期／ビッグデータ・AIを活用したサイバー空間基盤技術におけるアーキテクチャ構築及び実証研究」

8

都市 OS に含まれるデータ連携基盤が、政府が整備を進めてきた IMI(Infrastructure for Multilayer

Interoperability:情報共有基盤)である。IMIは、データに用いる文字や用語の同一性を特徴付ける概念を体

系的に分析・整理し、コンピューター処理に適した定義情報としてデータに付加することで、既存システム

に原則手を加えず運用を相互に維持しながら情報の共有や活用を円滑に行うための基盤である20。

「未来投資戦略 2018」21は、「行政機関や企業などの民間機関の間で散在するデータを全て連携することを

目指し、データ標準や共通語彙基盤(IMI)等を用いた横断的なデータ活用基盤を 3 年以内に整備する」「行政

データ標準の確立に向け、政府の文字情報基盤を整備するため、内閣官房において漢字、代替文字、フリガ

ナ及びローマ字等を含む文字情報の現状や導入方法に関するガイドについて整備するとともに、その運用に

ついて民間サービスとの連携の在り方も含めた検討を行う」としている。

行政サービスを高度化するデジタルデータ

海外の先行事例

米国では、連邦政府の出費を明細から開示する法律(Digital Accountability and Transparency Act: DATA

Act)及び DATA Act に基づくプロジェクト「USAspending.gov」が推進されている。

図 1-3 全政府機関の予実執行状況を公開する USAspending

(出典) https://www.usaspending.gov/

「USAspending.gov」は、連邦政府の支出という客観的なデータに基づく議会での討議などを可能にする、

にて、あらためて開発が予定されている。

20 共通語彙基盤と文字情報基盤からなり、行政データの相互運用性向上を図る。共通語彙基盤は、データに用いる様々な用語の表記、

意味、構造の特徴を抽出し、体系的に整理した上で、分野を超えてデータの検索性向上やシステム連携強化を実現する。文字情報基

盤は、行政で用いられる人名漢字等約 6万文字の漢字を整備し、外字作成等のコストを解消した(2017年 12月に国際規格化)。

21 2017年 6月閣議決定。https://www.kantei.go.jp/jp/singi/keizaisaisei/pdf/miraitousi2018_zentai.pdf

9

EBPM の基盤である。企業開示情報の相互運用基盤 XBRL22を用いて連邦政府横断で会計データとナレッジが開

示・共有されており、データは各機関のデータベースから API などを介して効率的に集約している。

約 130万人が暮らすエストニアでは、行政手続きのオンライン化率は約 99.8％以上に上る。不動産取引と

離婚以外の手続きはインターネット上ですべて完結する。ペーパーレス化や事務効率化により、エストニア

では GDP 約 2％に相当する額のコスト削減効果が得られた。また銀行などの金融サービスの電子化や医療機

関における電子処方箋なども定着している。なお、エストニアでは、住民が行政機関に一度提出した個人情

報の再提出要請を禁じる法律が施行され、ワンスオンリーの原則が実践されている。電子政府を支える情報

連携基盤は、ブロックチェーン技術を用いた分散型データベースで構築されている。

日本に求められる取組み

海外と比較すると、日本における取組みはまだ緒についたばかりだが、官民の協力と連携による国全体の

DX 推進は喫緊の課題であり、政府もデジタル・ガバメントの実現を急ぐ。2019年 5月に公布されたデジタル

手続法23では、図 1-4の「デジタル化の基本原則」が掲げられている。

①デジタルファースト：個々の手続・サービスが一貫してデジタルで完結する

②ワンスオンリー：一度提出した情報は、二度提出することを不要とする

③コネクテッド・ワンストップ：民間サービスを含め、複数の手続・サービスをワンストップで実現

図 1-4 情報通信技術を活用した行政の推進の基本原則

しかし、転居などのライフイベントに伴う個人の手続き、企業が会社を設立する際の手続きが全てオンラ

インで完結し、国民と行政がともに利益を享受する社会は、政府だけの取組みだけでは実現しない。官民デ

ータ活用推進基本法が第 3 条基本理念で「国、地方公共団体及び事業者の情報システムの相互の連携を確保

するための基盤」を掲げるのも、公共性の高い事業者をはじめ、日々の活動でデータを取り扱うステークホ

ルダーの参加が不可欠だからである。同法はまた、第 6 条に事業者の責務を記し、民間の協力を求めている。

(事業者の責務)

第六条 事業者は、基本理念にのっとり、その事業活動に関し、自ら積極的に官民データ活用の推進に努めるととも

に、国又は地方公共団体が実施する官民データ活用の推進に関する施策に協力するよう努めるものとする。

図 1-5 官民データ活用推進基本法第 6条

22 XBRLについては、「3.1企業開示情報の相互運用基盤 XBRL」を参照。

23 正式名称は、「情報通信技術の活用による行政手続等に係る関係者の利便性の向上並びに行政運営の簡素化及び効率化を図るための行

政手続等における情報通信の技術の利用に関する法律等の一部を改正する法律」。情報通信技術を活用した行政の推進の基本原則とし

て、国、地方公共団体、民間事業者、国民その他の者があらゆる活動において情報通信技術の便益を享受できる社会の実現(社会全体

のデジタル化)が掲げられている。

10

1.2 データ流通・連携を阻む壁

この節では、データ流通・連携を阻む壁とその背景を整理し、課題解決へ向けたヒントとする。

ブラックボックス化したシステム

DX レポートは、DX 阻害要因に「ブラックボックス化した既存システム」を挙げ、解消しない場合「データ

が活用できず、デジタル競争の敗者」に陥るリスクを指摘している。何が問題なのだろうか。

ブラックボックスの本質

ある財務会計システムに、次のような形式のデータ(項目名と値)があったとする。

売上高 1,000,000,000

項目名は「売上高」で、値が「1,000,000,000」という数字である。だが、これだけを見ても、値の意味を

理解できない。どの企業のなんの製品/サービスの売上高なのか不明である。「売上高」なので金額であろう

と推察はできるが、定かではない。金額だったとして、1,000,000,000「円」かもしれないが、1,000,000,000

「千円」かもしれないし、1,000,000,000「ドル」かもしれない。また、いつの売上高なのかもわからない。

正しくデータを理解するためには、データ項目定義書などのドキュメント、またはデータや財務会計シス

テムの関係者に確認する必要がある。

だが、次のような情報が付加されていると、どうだろうか。

会社 株式会社○○○○

年度 2018 年度

製品 XYZ

単位 円

金額項目

IFRS(国際会計基準)の売上高

株式会社○○○○社における製品 XYZ の 2018 年度の売上高 1,000,000,000 円(国際会計基準 IFRS に準拠)

であることが読み取れる。

「組織内にはデータが豊富にある」といっても、そのデータ(数字や文字列)のもつ意味や型(数値か、文字

列か、あるいは真偽を表す 1 または 0か、など)、桁数、単位などが定義されていなければ、意味のある「情

報の表現」として事業や研究などに活用することは難しい。伝達方法はさておき、上述の「付加情報」にあ

たる定義を、値とセットで相手に伝える必要がある。

「ブラックボックス化した既存システム」が抱える本質的な問題は、こうしたデータ項目定義が、共通認

識のもとで活用できる姿をしていないことにある。また、システムとデータが一体化しており、どのような

データ処理を経て「売上高 1,000,000,000」に至ったのかわからない点が「ブラックボックス」なのだ。

11

AI を「第二のブラックボックス」にしないために

人間中心の説明可能な AI(Explainable AI : XAI)では、これまで以上に、取り扱うデータ項目の定義やデ

ータ、値の根拠を明示する必要がある。「人間中心の AI 社会原則」24は、AI がもたらしかねない負の側面に

触れたうえ、これを回避するためにも「社会システムのソフト面・ハード面の双方において、拡張性や相互

接続性、発展的な秩序形成への仕組み等を備えた柔軟なアーキテクチャ設計」「特に相互接続性・連携性を保

証するために、様々な社会システムに共通のデータ利活用基盤」の必要性に言及している。説明可能なデー

タは、安心して官民が AIを活用するための大前提である。AIを第二のブラックボックスにしてはならない。

組織によって異なるデータ資産の捉え方

データ資産の捉え方や活用状況は、組織による温度差が大きい。IPAが 2018年 11 月東京証券取引所一部、

二部、マザーズ上場企業を対象に実施したアンケート調査では、データ利活用に現状は「慎重または消極的」

「判断できない」との回答が依然 26%(278 社中 73社)に上っている25。

図 1-6 ビジネスにおけるデータ利活用の位置づけ

IPA「安全なデータ利活用に向けた準備状況及び課題認識に関する調査」より

CMMI(Capability Maturity Model Integration)Institute や Gartner などが、データマネジメントの成熟

度モデルを示しているが、そうしたデータの可視化やマネジメントの取組みは、現時点ではまだ社会的認知

を得ていない。プロジェクト単位の非継続的な活動としてのみ捉えている限定的な場合もあれば、ビジネス

成長やプロセス最適化、市場競争を勝ち抜く必須要件と捉えベストプラクティスが組織間や業界全体に共有

される段階に達するケースもあり、その成熟度は組織によって異なる。「データを活用する」組織能力、成熟

度は競争領域だが、データ活用社会へ向けた協調領域としては、教育・人材育成などの取組みも待たれる。

24 2019年 3月 29日統合イノベーション戦略推進会議決定。https://www8.cao.go.jp/cstp/aigensoku.pdf

25 ただし、「積極的に推進していくことが、経営計画や事業方針等で記載されている」のみ「今後の方向性」が「現状」より増加してい

ることから、今後の方向性としてはデータ利活用の推進が見込まれている。

12

「壁」の背景と今後

データが個別システムに囲い込まれていたシステムインテグレーションの時代は、業務に合わせてゼロか

ら開発された組織ごとの専用システム開発が主流だった。SIerが一体的にシステムとデータの開発、運用を

担っていたため、組織が主体的にデータを意識しなくてもビジネスが回っていたといえる。システム内にデ

ータが閉じていたことと技術的制約から、定義可能なデータ項目、処理可能なレコード数も限られていた。

しかし今後は、「0.1.1ガイドの目的」等で述べたように、官民連携による社会的なデータ活用を進めるデ

ータフェデレーションの時代である。とくに DX推進においては、より良い顧客体験を常に創造し続けるため

に、よりビジネスの現場に近い分野でのデータ活用とデータに基づくスピーディなサービス創造の繰り返し

が避けられない。情報産業によるビジネス支援も、従来のシステムインテグレーションから、ユーザー企業

とともに進化するありかたへのシフトが求められる。

マイクロサービスや SaaSの登場により、システム開発の工数は削減が期待される。個別システムやネット

ワーク以上に、そこを流れるデータが整っていること、そしてその全体像を把握し適切に維持管理する CDO

やデータ管理部門の役割が重要になる。そしてデータ活用には、トップのコミットメントによる組織文化の

醸成とデータに対する共通認識、一人ひとりのビジネス目的達成へ向けた活用マインドが不可欠である。

先端的な IT 技術やシステム開発手法が華々しく登場するが、表層だけに目を奪われないことは大切だ。文

字、用語・書式、コード、データカタログやメタデータなどの一元管理、不断のメンテナンスは、DX や Society

5.0 に必要なデータ連携を実現する上で最も基本となる。政府主導で文字情報基盤、共通語彙基盤の整備が

進められてきた背景も、そうした文脈の中にある。

「壁」の具体例

データ活用を阻む壁の具体例をとりあげる。基本的には、データ項目定義の伝達に関わる問題である。こ

れらデータを組み合わせつないで活用するため、データサイエンティストの多くは職人技でデータセットの

名寄せ、整形などを行うデータクレンジングや事前準備(前処理)を行い、業務時間の 70-80%を活用前の作業

に割かれているという。既にあるデータ資産の活用に伴う過大な負荷は、社会の損失である。

なお、見出し中色付きの部分は、解決策のキーワードを示す。クラウドを介して緩やかに結合した ITイン

フラを前提とする今日の現実的な解決に向けた改善方法は、「第 2 章解決に向けたアプローチ」で後述する。

データカタログやメタデータ台帳の不備 解決のヒント⇒2.1.1、2.2

そもそも社内にどのようなデータ資産が存在するか、把握していないケースは少なくない。データが、コン

ピューターやそれを使う人に「発見」されなければ、資産価値は眠ったまま退蔵される。他の部署でも同様

のデータを収集していれば二重、三重の費用を投じる無駄が生じる。データ資産が整理されていない状態は、

保護すべき資産がどこにどれだけ存在するか把握できていない、危険な状態でもある。

13

データ項目名や意味構造の定義がない 解決のヒント⇒2.1.2

組織間等でデータを共有しようとしても、各データセットのデータ項目名がバラバラで一致しない。似た

ようなデータベースや帳票画面も、個人、部署やシステムなど組織によって異なる名称や構造が使われてい

る。「仕入先」と「調達先」は同一であるという定義を与えない限り、コンピューターは両者を異なる文字列

として扱うため、データをつないで活用する際の壁になる。データ項目定義書が一元管理されていない結果、

複数データセットのデータ項目の表す意味の「一致」「不一致」等の判別や値の正確性の検証を妨げる。

品質低下を招くデータの型や基準の不備 解決のヒント⇒2.1.2(2)

値の型や基準が共有されていないと、データ品質に問題が起きやすい。いざ活用する際に作成者以外の担

当者が値の正確性を確認・修正する壁になる。値がないデータ項目は「ゼロ(“0”)」なのか「空白(““)」

なのか、単なる記入漏れか判断できない26。株式会社、(株)、㈱などの不統一や漢字で外字の混在等はよく聞

く話だ。また、誤字脱字などの入力ミスを完全になくすことは難しい。

コンピューターが図 1-7のような数字、文字が混在したレコードファイルを処理する際、カンマやタブで

区切られた各データ項目の順序が異なったり、欠落していたり、システムの許容桁数を超過したデータや、

数値欄に入力された漢字はエラーとなる。

00001, 01234, 独立行政法人, 情報処理推進機構, 東京都, 文京区本駒込 2-38-8, 文京グリーンコートセンターオフ

ィス, 円, A001, 情報 処理男

図 1-7 データレコードの例

型や基準の定義があってこそ、コンピューターはそうしたエラーを確認できる。定義のないデータは正確

性が担保されず、1.2.1(2)で述べたような AI の誤った学習を助長しかねない。

共通フォーマットなどのデータ変換のしくみがない 解決のヒント⇒2.1.3、2.2

データ項目定義書はあっても、データセット間、システム間でデータ同士を交換する仕組みやアプリケー

ションがない。表計算やデータベースに詳しい一部の「職人」に依存した手作業が蔓延している。組織内に

止まらず、社会全体で見た場合にも、官民データ活用の壁になる。1.2.3で概観したように、従来データ資産

は個々の組織の特定目的で開発されたシステムに閉じていたため、共通項の多いデータが少しずつ異なる形

式、状態で運用されている。民間調査会社がデータベース化する企業情報と「2.3 法人インフォメーション」

で一元的な提供を図る府省庁の保有する企業情報、全国自治体や公共機関の予算・決算情報、組織が蓄積す

る取引先情報等である。あるいは民間グルメサイトと自治体が保有する食品等営業許可・届出一覧といった

例だ。また、組織内でも、システムが異なればデータ項目定義や品質が異なることが多い。

ID・コードの不統一 解決のヒント⇒2.1.2

ID やコードの発番・管理が社内で一元的になされていない。同じ「仕入先」「会員」「社員」でも、異なる

複数のコードが割り振られ、コンピューターがそれぞれ異なるものとみなしてしまう。使わなくなったコー

26 例えば会計報告では四捨五入後の値を「0」と記載する場合がある。避難所種別コードであれば値としての「0」と未確認を意味する

空白とは厳密に分ける必要がある。

14

ドを別の値のコードとして再利用し、時系列での分析時にデータの整合性が損なわれることも少なくない。

システム間の連携やデータのやりとりが、人間を介在させなければ困難になる。

図 1-8 施設 IDのメンテナンス例。運用ルールと一元管理が不可欠。

データ収集・運用管理の目的や管理体制が曖昧 解決のヒント⇒2.1.1、4.1.1

「前任者から引き継いたため」等、経緯や利用目的、ステークホルダーが曖昧なまま運用されるデータは、

ブラックボックス化しやすい。分析の役目を終えたデータセットやデータ項目、あるいは役割を終えたかど

うかさえわからないデータ項目にも、収集、蓄積、保護のコストや人手はかかっている。必要以上の取得頻

度も通信回線のリソースを圧迫する。多種類のデータを収集するセンサーや IoT 機器などを設置すれば、ハ

ードウェアと回線、データの維持管理に費用がかかる。

id番号 公共施設の名称(name)

YS000000002 南区役所

YS000000003 南保健福祉センター（健康長寿推進課，生活福祉課，医療衛生コーナー）

YS000000004 南保健福祉センター（子どもはぐくみ室，障害保健福祉課）

YS000000005 芝出張所

YS000000006 小宮出張所

YS000000007 霧土出張所

YS000000008 南水区役所

YS000000009 南水保健福祉センター

YS000000011 左水区役所

YS000000012 左水保健福祉センター

YS000000015 清川出張所

YS0000A0050 堀出張所

id番号 公共施設の名称(name)

YS000000002 南区役所

YS000000003 南福祉事務所

YS000000004 南保健センター

YS000000005 芝出張所

YS000000006 小宮出張所

YS000000007 霧土出張所

YS000000008 南水区役所

YS000000009 南水福祉事務所

YS000000010 南水保健センター

YS000000011 左水区役所

YS000000012 左水福祉事務所

YS000000013 左水保健センター

YS000000015 清川出張所

2017年の施設一覧 2018年の施設一覧

閉鎖

統合

名称変更

新設

15

第2章 解決に向けたアプローチ

本章では、「第 1章目指す社会と克服すべき課題」をふまえ、官民データ活用社会の参加者に求められるデータ資産

の管理手法、データ項目定義の具体例について、ユースケースも交えて紹介する。

2.1 情報を公開・交換するための手法

データ資産の棚卸と運用

まず着手すべきは、組織にけるデータ資産27の棚卸である。図 2-1のような「データカタログ28」と呼ばれ

る表に整理することが多い。「誰(どのシステム)が」「いつ」「どこで」「誰(どのシステム)に向けて」「どのよ

うな目的・理由で」「どのようなツール等を用いて」「どの基準を参照し」作成し、「どう運用されている」デ

ータセットなのかといった、データ活用や管理のための情報29である。データカタログは、1.2.4(1)で述べた

守るべきデータ資産の可視化はもちろんのこと、オープンデータの利用促進やデータ流通市場での販売を含

め、データ資産活用へ向けた前向きな取組みとしても重要である。

図 2-1 データカタログのイメージ。データセットごとにタイトルや概要、管理者、更新頻度、ファイル

形式等のメタデータを付与し、適宜更新

データカタログには、データセットのタイトル、作成目的や作成/更新日や更新頻度、作成者及び責任者(ま

たはデータを生成したシステム等)、データセットの設計書の中でキーとなる情報、品質、著作権やライセン

ス、プライバシー保護などの利用条件をユーザーに伝える役割がある。とくにデータ取引など組織間でのデ

ータ活用では、使用条件や品質を明示する必要がある。

27 市場で購入したデータや商用データベース、オープンデータなども対象とすることが望ましい。

28 データ流通推進協議会「データカタログ作成ガイドライン V1.1(中間とりまとめ)」では、「データの所在や内容等の概要情報を項目別

に記入する書式の総称」と説明している。

29 メタデータ(データを説明するための上位のデータ)とも呼ばれる。メタデータについては ISO/IEC11179、JIS X 4181-3:2004を参照。

タイトル 出所 オーナー タグ 最終更新 種別 粒度 形式 精度 ・・

購買履歴 CRM XX 斉藤○○ 販売、顧客 2018-9-30 19:31 社内 個票 csv 99

店舗内行動 ▲▲システム 田坂○○ IoT、導線、 2018-9-27 09:28 社内 集計 XML 84

天候 気象庁 柴○○ 天気、気温 2018-9-27 07:48 オープンデータ 個票 csv 100

商品サイトA CMS YY 今田○○ ログ 2018-9-26 22:01 社内 集計 Excel 99

SNS画像 サービスZZ 斉藤○○ シェア 2018-9-20 19:05 外部 個票 png

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

メタデータ

メタデータ

メタデータ

メタデータ

社内外のデータ

データカタログ

ユーザー社内辞書

顧客

カスタマー

会員

VIP

整理・分類

16

カタログ化されたデータセットは、利用シーンにおいて作成時の目的と異なる価値を創造する可能性があ

る。そうした気づきなども適宜カタログへ反映していくと、データ活用の知見という資産になる。

「第 3章実装方法を事例から学ぶ」で述べるように、データ流通のためのデータカタログは標準化が進む。

図 2-2 データカタログ定義の例

(出典) データ流通推進協議会「データカタログ作成ガイド V1.1(中間とりまとめ)項目定義書」より

他には、GDPR対策のために英 Information Commissioner’s Office30が提供するセルフアセスメントツー

ルやデータセット管理用のスプレッドシート、「推奨データセット」のオープンデータ一覧なども活用できる。

図 2-3 ICO が提供するデータセット管理シート

(出典) Guide to the General Data Protection Regulation (GDPR)

利用者が必要なデータセットを探しやすいカタログサイトや、条件を組み合わせて検索しやすいツールな

どがあると望ましいが、まずは一覧にまとめ、資産として活用・管理可能な状態にすることが重要だ。

30 GDPRに基づき各国に設置されるデータ保護監督機関(Supervisory Authority)。

17

用語やコードの意味の伝達

データは、値が現場や現物などの事実を正しく反映した数字であることを確認できて初めて、人の判断を

裏付ける証左として活用できる。そのためには、全てのステークホルダーとコンピューターが、用語やコー

ドの意味を、常に正しく伝達し合っている必要がある。本稿ではその手順を示す。

データ資産の基本形

そもそもデータ資産とはどのような姿をしているのか簡単におさらいしておく。ある企業における「仕入

先」に関するデータ項目及び、対応する登録データ(値)を例に考える。仕入先については、図 2-4のような

データ項目が含まれるとする。

仕入先

ID(仕入先の識別)

仕入先名

仕入先区分

住所

仕入先に発注する際の使用通貨

支払条件

取引先担当者名

図 2-4 仕入先マスターデータの例

この組織では、取引するすべての仕入先について、これらのデータ項目に関する値を入力している。それ

ぞれのデータ項目に、2件分の値を入れると図 2-5のようになる31。

図 2-5 値を入力した例 *は別途定義された支払条件コードの例

データベースにデータを入出力する際は、1 行に 1 レコードを記述した CSV や TSV、JSON、XMLなどのファ

イルを用いる。

31 データベースのテーブルにおいては「仕入先」をエンティティやクラス、データ項目名を属性などと呼ぶが、本ガイドでは特定の表

記法にこだわっていない。データモデルの表記法は複数存在し、例えば、IDEF1Xデータモデルでは「エンティティ」、UMLクラス図で

は「クラス」と呼ばれる。表記法によって呼び方が異なるが、基本的な考え方はおおむね共通している。

仕入先

データ項目 値1 値2

ID(仕入先の識別) X0123 X0124

仕入先名 独立行政法人情報処理推進機構経済産業省

仕入先区分 2(独立行政法人) 1(省庁)

住所 東京都文京区本駒込2-28-8東京都千代田区霞が関1-3-1

仕入先に発注する際の使用通貨 円 円

支払条件 A001(*) A001(*)

取引先担当者氏名 情報処理男 経済産業子

データセットの名前

データ項目名 値

00001, 01234, 独立行政法人, 情報処理推進機構, 東京都, 文京区本駒込 2-38-8, 文京グリーンコートセンターオフ

ィス, 円, A001, 情報,処理男

18

用語の形式、付加情報の整備

カンマ区切りに並んだ各値の形式や意味を、図 2-6の A-1～11のように付加情報で定義する。人やコンピ

ューターがデータを活用する際の情報源であるデータ項目定義書の、最も基本的な例である。

A-1 通し番号 レコードを識別する 5 桁の整数(00000～99999)

A-2 ID 仕入れ先を識別する 5 桁の整数(00000～99999)

A-3 仕入れ先情報 1 会社形態(10 文字以内)

A-4 仕入れ先情報 2 社名(20 文字以内)

A-5 仕入れ先住所 1 都道府県

A-6 仕入れ先住所 2 市区町村名、番地等(40 文字以内)

A-7 仕入れ先住所 3 建物名(40 文字以内)

A-8 使用通貨 10 文字以内

A-9 支払条件 10 文字以内の英数字

A-10 担当者情報 1 姓(20 文字以内)

A-11 担当者情報 2 名(20 文字以内)

図 2-6 CSV に記載するデータ項目名と各値の意味

意味構造の整理

データ項目定義に定める型や桁数、単位に合致した「文法的に正しいデータ」であることは、データ資産

に求められる最低限の要件である。「正しい」ためには、人と人とコンピューターがデータを活用しやすいよ

うに意味構造を定義する必要がある。意味構造の定義には、データ項目の分類と構造化が有効である。例え

ば図 2-7 の「法人関連申請手続き等」のデータセット定義を見てみると、説明部分から「申請手続き等」に

関わる項目(青字)、「申請主体」そのものに関わる項目(緑字)、「申請主体」の「法人名」や「本店所在地」、

「連絡先」に関わるサブ項目(赤字)に分類可能である。

◎=記述必須、○=記述推奨、空白=該当があれば記述

＃ ラベル 必須 説明

1 NO ◎ 申請手続き等の管理主体内でデータが一意になるように記載

2 申請の名称 ◎ 申請手続き等の名称を記載

3 法人番号/個人事業主管理番号 ◎ 申請主体の法人番号/個人事業主管理番号を記載

4 法人名/屋号 ◎ 申請主体の法人名/屋号を記載

5 法人名/屋号(かな) ◎ 申請主体の法人名/屋号のよみがなを記載

6 本店所在地/印鑑登録証明書住所(都道府県) ◎ 申請主体の本店所在地/印鑑登録証明書住所(都道府県)を記載

7 本店所在地/印鑑登録証明書住所(市区町村) ◎ 申請主体の本店所在地/印鑑登録証明書住所(市区町村)を記載

8 本店所在地/印鑑登録証明書住所(番地等) ◎ 申請主体の本店所在地/印鑑登録証明書住所(番地等)を記載

9 代表者名/個人事業主氏名(姓) ◎ 申請主体の代表者名/個人事業主氏名(姓)を記載

10 代表者名/個人事業主氏名(名) ◎ 申請主体の代表者名/個人事業主氏名(名)を記載

11 代表者役職 〇 申請主体の代表者役職を記載

12 設立年月日 ◎ 申請主体の設立年月日を記載

19

◎=記述必須、○=記述推奨、空白=該当があれば記述

＃ ラベル 必須 説明

13 事業規模 申請主体の事業規模を表す何らかの区分を制定し、記載

14 従業員数 ◎ 申請主体の従業員数を記載

15 業種 〇 申請主体の営む主な事業を、標準産業分類に従い記載

16 資本金 ◎ 申請主体の資本金を記載

17 連絡先郵便番号 申請主体の連絡先郵便番号を記載

18 連絡先住所(都道府県) 申請主体の連絡先住所(都道府県)を記載

19 連絡先住所(市区町村) 申請主体の連絡先住所(市区町村)を記載

20 連絡先住所(番地等) 申請主体の連絡先住所(番地等)を記載

21 連絡先住所(マンション名等) 申請主体の連絡先住所(マンション名等)を記載

22 連絡先会社部署名/部署名 申請主体の連絡先会社部署名/部署名を記載

23 連絡先氏名(姓) 申請主体の連絡先氏名(姓)を記載

24 連絡先氏名(名) 申請主体の連絡先氏名(名)を記載

25 連絡先電話番号 申請主体の連絡先電話番号を記載

26 連絡先メールアドレス 申請主体の連絡先メールアドレスを記載

図 2-7 法人関連申請手続き等のデータ項目定義例

図 2-7の分類を図に展開すると、各データ項目の意味構造を理解しやすくなる。データモデルを検討した

り、「2.2共通フォーマットと語彙体系の活用」で既存の語彙記法等を使って機械判読可能なデータの説明を

記述する際は、「法人関連申請手続き等」、「法人関連申請手続き等の申請主体の法人名」、「法人関連申請

手続き等の申請主体の本店所在地」、「法人関連申請手続き等の申請主体の連絡先」をひとつの塊32として検

討できる。各項目にどのような値が記述されるのか、実際のデータを使って検証することがポイントである。

32 いわゆるエンティティの考え方に近い。

20

図 2-8 分類構造を図示

意味構造の伝達

実際のデータ項目定義には、図 2-9のように、さらに詳細な説明書きや入力形式の規定、あるいは入力例、

さらにそのデータ項目の典拠となる法律などを記載することが多い。図 2-9の例だと「市区町村コード」は

全国地方公共団体コードを参照しており、「災害種別」は内閣防災情報のページ「避難場所等の図記号の標準

化の取組」33掲載の災害種別、「指定緊急避難場所」「指定避難所」は災害対策基本法を典拠にした分類である。

図 2-9 避難所データセットのデータ項目定義例

(出典)政府 CIO ポータル「推奨データセット」

こうした意味構造や定義、典拠等を、語彙として活用者やコンピューターへ正しく伝える努力が「データ

相互運用性」の取組みである。伝える手段は図 2-9のようなデータセットと別の定義書、図 2-10のような

33 http://www.bousai.go.jp/kyoiku/zukigo/index.html

NO

申請の名称

法人関連申請手続き等

申請主体

代表者

連絡先

連絡先郵便番号

連絡先住所（都道府県）

連絡先住所（市区町村）

連絡先住所（番地等）

連絡先住所（マンション名等）

連絡先会社部署名/部署名

連絡先氏名（姓）

連絡先氏名（名）

連絡先電話番号

連絡先メールアドレス

設立年月日

事業規模

従業員数

業種

資本金

法人番号/個人事業主管理番号

法人名/屋号

法人名/屋号（かな）

代表者名/個人事業主氏名（姓）

代表者名/個人事業主氏名（名）

代表者役職

本店所在地/印鑑登録証明書住所本店所在地/印鑑登録証明書住所（都道府県）

本店所在地/印鑑登録証明書住所（市区町村）

本店所在地/印鑑登録証明書住所（番地等）

項目

No.項目名

区

分説明 形式 記入例

先進自治

体公開有

無

共通語彙基盤 共通語彙基盤での値型

1 ID ◎

地方公共団体内で避難場所（注1）が一意に決まるよう、IDを設定し、

全地方公共団体において、同種類のデータセットでは一意に決まる組み合わせ記載。

※記載方法について、「データ項目特記事項」シートを参照。

文字列（半角数字） 1122410001 有 施設>ID>識別値 xsd:string

2 名称 ◎避難場所の通称や建物等の名前を記載。他言語版は別ファイルとする。ファイル名は

ファイル命名規則に従うこと。文字列 ○○小学校 有 施設>名称>表記 xsd:string

3 名称_カナ ◎

避難場所の通称や建物等の名前をカナで記載。※記載方法について、「データ項目

特記事項」シートの【共通ルール】を参照。他言語版は別ファイルとする。ファイル名は

ファイル命名規則に従うこと。

文字列（全角カナ） ○○ショウガッコウ 有 施設>名称>カナ表記 xsd:string

4 住所 ◎

避難場所の住所を記載。※記載方法について、「データ項目特記事項」シートの【共

通ルール】を参照。他言語版は別ファイルとする。ファイル名はファイル命名規則に従う

こと。文字列 北海道札幌市厚別区2-○-○ 有 施設>住所>表記 xsd:string

5 方書避難場所の住所の方書を記載。他言語版は別ファイルとする。ファイル名はファイル命

名規則に従うこと。文字列 ○○ビル1階 無 施設>住所>方書 xsd:string

6 緯度 ○避難場所の緯度を記載。※記載方法について、「データ項目特記事項」シートを参

照。文字列（半角文字） 43.064310 有 施設>地理座標>緯度 xsd:string

7 経度 ○避難場所の経度を記載。※記載方法について、「データ項目特記事項」シートを参

照。文字列（半角文字） 141.346814 有 施設>地理座標>経度 xsd:string

8 標高 避難場所の標高をｍ単位で記載。 文字列（半角文字） 30.5 無 施設>地理座標>測地高度>数値 xsd:decimal

9 電話番号

避難場所の連絡先（電話番号）を記載。※記載方法について、「データ項目特記

事項」シートを参照。

※電話が無い指定避難場所もあり

文字列（半角文字） 000-000-0000 有 施設>連絡先>電話番号 xsd:string

10 内線番号避難場所の連絡先（内線番号）を記載。※記載方法について、「データ項目特記

事項」シートを参照。文字列（半角数字） 00000 無 施設>連絡先>内線番号 xsd:string

11 市区町村コード ◎ 設置主体である市区町村コード（6桁）を記載。 文字列（半角数字） 011002 有施設>関与{役割＝’設置主体’}>関与者

{@組織型}>ID>識別値 （注2）xsd:string

12 都道府県名設置主体である地方公共団体名について、都道府県名を記載。他言語版は別ファイ

ルとする。ファイル名はファイル命名規則に従うこと。文字列 北海道 無

施設>関与{役割＝’設置主体’}>関与者

{@組織型}>住所>都道府県　（注2）xsd:string

13 市区町村名設置主体である地方公共団体名について、市区町村名を記載。都道府県について

は記載不要。他言語版は別ファイルとする。ファイル名はファイル命名規則に従うこと。文字列 札幌市 無

施設>関与{役割＝’設置主体’}>関与者

{@組織型}>住所>市区町村（注2）xsd:string

14 災害種別_洪水 ◎避難場所が対応している災害を記載。※記載内容について、「データ項目特記事

項」シートを参照。明示的に０を入れる文字列（半角数字） 1 有

施設>種別コード{種別＝’設置主体’}>識

別値（注3、4）xsd:string

15

災害種別_崖崩

れ、土石流及び地

滑り

◎

指定緊急避難場所が対応している災害(崖崩れ、土石流及び地滑り)を記載。※記

載内容について、「データ項目特記事項」シートの【10.指定緊急避難場所一覧】を

参照。

文字列（半角数字） 1 有

施設>種別コード{種別＝’災害種別_崖崩

れ、土石流及び地滑り’}>識別値（注3、

4）

xsd:string

16 災害種別_高潮 ◎指定緊急避難場所が対応している災害(高潮)を記載。※記載内容について、「デー

タ項目特記事項」シートを参照。文字列（半角数字） 1 有

施設>種別コード{種別＝’災害種別_高

潮’}>識別値（注3、4）xsd:string

17 災害種別_地震 ◎指定緊急避難場所が対応している災害(地震)を記載。※記載内容について、「デー

タ項目特記事項」シートを参照。文字列（半角数字） 1 有

施設>種別コード{種別＝’災害種別_地

震’}>識別値（注3、4）xsd:string

18 災害種別_津波 ◎指定緊急避難場所が対応している災害(津波)を記載。※記載内容について、「デー

タ項目特記事項」シートを参照。文字列（半角数字） 1 有

施設>種別コード{種別＝’災害種別_津

波’}>識別値（注3、4）xsd:string

19災害種別_大規

模な火事◎

指定緊急避難場所が対応している災害(大規模な火事)を記載。※記載内容につい

て、「データ項目特記事項」シートを参照。文字列（半角数字） 1 有

施設>種別コード{種別＝’災害種別_大規

模な火事’}>識別値 （注3、4）xsd:string

20災害種別_内水

氾濫◎

指定緊急避難場所が対応している災害(内水氾濫)を記載。※記載内容について、

「データ項目特記事項」シートを参照。文字列（半角数字） 1 有

施設>種別コード{種別＝’災害種別_内水

氾濫’}>識別値 （Q35）xsd:string

21災害種別_火山

現象◎

指定緊急避難場所が対応している災害(火山現象)を記載。※記載内容について、

「データ項目特記事項」シートを参照。文字列（半角数字） 1 有

施設>種別コード{種別＝’災害種別_火山

現象’}>識別値 （注3、4）xsd:string

22指定緊急避難場

所◎

指定緊急避難場所に該当するものを記載。※記載内容について、「データ項目特記

事項」シートを参照。文字列（半角数字） 1 有

施設>種別コード{種別＝’指定緊急避難場

所’}>識別値（注3、4）xsd:string

23 指定避難所 ◎指定避難所に該当するものを記載。※記載内容について、「データ項目特記事項」

シートを参照。文字列（半角数字） 1 有

施設>種別コード{種別＝’指定避難所との重

複’}>識別値 （注3、4）xsd:string

24 福祉避難所 ○指定避難所のうち、福祉避難所に該当するものを記載。※記載内容について、「デー

タ項目特記事項」シートを参照。文字列（半角数字） 1 有

施設>種別コード{種別＝’福祉避難施設

所’}>識別値（注3、4）xsd:string

25 その他の避難場所 ○その他の避難場所に該当するものを記載。※記載内容について、「データ項目特記事

項」シートを参照。文字列（半角数字） 1 有

施設>種別コード{種別＝’その他の避難場

所’}>識別値（注3、4）xsd:string

26 想定収容人数 ○ 避難場所に収容可能な人数を記載。※半角数字で記載されることが望ましい。 文字列 810 有施設>収容人数{種別='想定収容人数'}>

数値（注5）xsd:decimal

27搬入可能なトラック

の大きさ

搬入可能なトラックの大きさをコードで設定。※記載内容について、「データ項目特記

事項」シートを参照。文字列 1 無

施設>記述{種別='侵入可能なトラックの大

きさ'}>説明（注3、4）xsd:string

28対象となる町会・

自治会避難場所へ避難する対象の地域等を「;」（半角のセミコロン）区切りで記載。 文字列 ○○町;△△町 有

施設>記述{種別='対象となる町内会・自治

会'}>説明（注6）xsd:string

29 URL

避難場所のHPのURLを記載。

※防災のページ等で避難場所の防災備蓄倉庫の配置図や非常災害用井戸の位置

などを示したページを想定。無い場合は、通常の公式の施設のページでも可。

URI http://www.ooo.lg.jp/abc.html 有 施設>参照>参照先 xsd:anyURI

30 備考特記事項等あれば記載。他言語版は別ファイルとする。ファイル名はファイル命名規則

に従うこと。文字列 有 施設>備考 xsd:string

31 リンクID施設情報等、他の情報と紐付いてリンクするための自治体で管理しているIDコードを

記載。文字列 10001 有

施設>ID{種別='リンクID'}>識別値（注

7）xsd:string

データ項目（避難所基本情報） 参考情報

21

データセット本体への記述、2.2 で後述する DMD を利用した電子ファイルへの同梱、ウェブサイト上のデー

タ項目定義へのリンク、決まった相手とのデータ交換ならば社内システム上のデータセット同様ドキュメン

トの事前共有等、用途に応じ様々である34。いずれにせよ、データがもつ背景や正確性の判断材料を参加者が

共有できる工夫が、官民データ活用には欠かせない。

図 2-10 データセット中に定義行を記載した例

(出典) http://linkdata.org/work/rdf1s5372i/YOKOHAMA_spot.html?key=#work_information

システム間など、人が介在しないデジタル空間でデータを連携・流通させるには、人だけでなくコンピュ

ーター(機械)が判別できるように、データの意味や使用文字セットを含む定義(制約や形式等)、定義の典拠

などが、標準的なルールに基づいて定義されていて、かつ、相手に伝わる状態でなければならない。

ネーミングルールの整備

データ項目名のネーミングルールを整備する。組織内で利用頻度が高い「会員」「顧客」「カスタマー」と

いった同類の事物を指す用語は、意味構造を定義するリファレンスがあれば、ラベルが異なっても情報の相

互運用に向けた整理、交換は可能だ。図 2-11 では「会員」「VIP」を、より汎用性が高く抽象化された概念で

ある「顧客」という共通語彙として理解することにより、相互運用性の担保を図っている。データを活用し

ながら、段階的にこうした用語の共通点と相違点を整理する試みも有益である。

図 2-11 ネーミングルールの違いを整理35

34 例えば、人間の閲覧を想定した統計表であれば、表中の縦横のラベルから属性、単位など主要な値の意味を読み取れるが、詳細な分

析に必要なそもそもの調査対象や調査手法は別途「調査概要」「調査手法」などのテキストで補足するという作法が、広く実践されて

いる。

35 図 2-10の各データセットのデータ項目名を同じラベルに統一する必要はない。「郵便番号」と「〒」は日本語の表現が異なるが、電

子的な定義が同じであれば、コンピューターは同一のデータ項目だと判別できる。「2.3法人インフォメーションへの適用例」を参照。

「施設」のプロパティ⚫ 施設>名称⚫ 施設>説明⚫ 施設>参照⚫ ・・

「施設>住所」のプロパティ⚫ 施設>住所>都道府県⚫ 施設>住所>都道府県コード⚫ 施設>住所>市区町村⚫ ・・

22

システムや部門によって似て非なる、しかし一部は重複するデータ項目は少なくない。顧客という「人」

の「住所」という意味構造が共有できればデータを活用しやすい。データ項目名を変えずに相互運用性を高

める手法については、「2.1.3 情報を公開・交換するインターフェイスの共通化」を参照されたい。

ID・コードの標準化

ID とは、識別子(Identifier)を意味し、その適用範囲の中で、対象を特定し他のものと曖昧さなく区別で

きるようにするための情報(符号)である。図 2-12の場合、ID(仕入れ先を識別する 5桁の整数)が該当する。

何らかのサービスを利用する会員の「会員番号」、社員の「社員番号」なども ID の例である。

コードは、ある範囲の情報を、機械処理しやすく簡潔に示すために付与する符号のことで、図 2-12 では

「仕入先区分」や「支払条件」の「1」や「2」などの数字がそれに該当する。

政府 CIO ポータル「コード(分類体系)導入実践ガイドブック」36などを参照のうえ、ID・コードの設計及び

導入、運用ルールを策定する。

図 2-12 ID・コードの例

ID やコードを整備すると、複数のデータセットを組み合わせて活用する際、「仕入先」「社員」「仕入先区

分」といった対象物同士の関係を効率的に関連づけることができる。

情報を公開・交換するインターフェイスの共通化

本項では、異なる既存システムの間でデータを受け渡しするアプローチとして、システム間における情報

交換の手続きを共通化していく考え方と方法論を示す。異なる組織がデータカタログサイトに、それぞれ保

有するデータを揃えて公開する際にも活用できる考え方だ。ビジネス及びデータ流通のグローバル化が進展

するなかでの現実解と位置付けられる。

共通化の考え方

情報交換の手続きを共通化する仕組みの特徴は、データセットやそれを管理するシステムの間に変換機能

を仲介させることである。既存のデータ構造を生かした形でのスモールスタートが可能で、将来の変更を見

36 政府 CIOポータル標準ガイドライン群。https://cio.go.jp/guides

仕入先

データ項目 値1 値2

ID(仕入先の識別) X0123 X0124

仕入先名 独立行政法人情報処理推進機構経済産業省

仕入先区分 2(独立行政法人) 1(省庁)

住所 東京都文京区本駒込2-28-8東京都千代田区霞が関1-3-1

仕入先に発注する際の使用通貨 円 円

支払条件 A001(*) A001(*)

取引先担当者氏名 情報処理男 経済産業子

データセットの名前

データ項目名

ID

コード

23

越した拡張性や柔軟性を備える利点がある。

図 2-13 のシステム A とシステム B では、同じ住所を示しているが、データ構造や表記ルールが異なる。

「都道府県・市区町村等に分けて書いた住所」「一つにまとめて書いた住所」、「霞ケ関 3-3-3」「霞が関三丁目

三番地三」の違いを、コンピューターは同一の値と認識できない。各システムが住所データをもっていても、

連携しようとするシステムやデータセットごとに、再入力もしくはデータ変換の必要が生じる。

図 2-13 データ構造が異なるために交換または公開ができない例

そこで、図 2-14 のような変換を行う。共通するデータ構造に、データ項目及び値を置き換えることで、異

なるシステム A、B を運用したままでもデータのやり取りが可能になり、相互運用性が確保できる。

図 2-14 既存システムデータ構造は維持したまま共通フォーマットに変換し交換または公開(相互運用)

共通するデータ構造に、データ項目及び登録内容(値)を置き換えることで、異なるシステム A、B を運用し

たままでもデータのやり取りが可能になり、相互運用性が確保できる。

図 2-15 各システム個別の事情に応じた定義で情報を直接交換すると、その都度変換が必要 (左)。共通

フォーマットを間に挟むこと(右)で相互運用性が高まり、社会的コストが削減される。

データ項目 値

郵便番号 1000013

住所 千代田区霞ヶ関3-3-3

方書 GビルA132

…

データ項目 値

事業所 100-0013千代田区霞が関三丁目三番地三GビルA132

システムAのデータベース システムBのデータベース

×

システムA システムBデータ項目 値

種別 事業所住所

国 日本

都道府県 東京都

市区町村 千代田区

町名 霞が関

丁目 3

番地 3

号 3

ビル名 Gビル

ビル番号 A

部屋番号 132

住所コード

郵便番号 1000013

システムAのデータを共通フォーマットに変換

○交換可能

変換

データ項目 値

事業所 100-0013千代田区霞が関三丁目三番地三GビルA132

データ項目 値

郵便番号 1000013

住所 千代田区霞ヶ関3-3-3

方書 GビルA132

…

データ項目 値

種別 事業所住所

国 日本

都道府県 東京都

市区町村 千代田区

町名 霞が関

丁目 3

番地 3

号 3

ビル名 Gビル

ビル番号 A

部屋番号 132

住所コード

郵便番号 1000013

システムBのデータを共通フォーマットに変換

変換

定義A

定義B

定義C

定義..

定義E

定義D

共通フォーマット

定義A

定義B

定義C

定義..

定義E

定義D

24

共通フォーマットの用意

データ活用者ニーズを考慮しつつ、データベースやシステムの管理者、データ更新・管理担当者が相互の

理解、協力のもとで運用可能な共通フォーマットを決める37。「推奨データセット」など既存の共通フォーマ

ットを活用する場合は、それらからデータセットに近い構造のフォーマットを選ぶ38。

既存データセットのデータ項目と値を並べて見比べ、活用ニーズが高くかつ運用可能なデータ項目を選ん

だうえ、データ項目定義を検討していく方法が一般的である。政府 CIO ポータルの「行政サービス・データ

連携モデル」や、IMI共通語彙基盤「公開ドラフト語彙」なども、多くはその方法で検討した成果である。後

述する「コア語彙」などの標準的な用語体系を起点にデータ項目をあてはめていく方法だと、多くのデータ

項目は合致しづらいため、「対応できない」という確認に時間を費やすことになる。データ活用の観点を優先

して使いやすい構造を検討していく方が、データセットの意図に合致することが多い。何らかの目的をもっ

て運用されてきたデータセットを起点に、既存共通フォーマットを参考にすることが望ましい。

図 2-16 共通フォーマットの検討例

(出典)政府 CIO ポータル「行政サービス・データ連携モデル 調達」

共通フォーマットにデータ項目の目的や説明、典拠などを記すことで、データ項目の作成者ではないデー

タ管理者等による当該データの収集・蓄積・管理の必要性の判断や仕分けが容易になる。データ項目が何を

示すのか具体的にわかるように記載し、データ作成者以外の管理者やユーザーによる解釈の揺らぎを回避す

る。データ項目が取りうるデータ項目名の表記ラベル、値の制約情報、補足説明とともに、複数のサンプル

値を記載することが重要である。

37 一般社団法人データ流通推進協議会は、業界団体等で語彙やデータカタログを検討する手順を無料公開している。

38 例えば、IMI共通語彙基盤では図 2-17のような検討中の語彙を PD(Public Draft)として公開している。また、「政府 CIOポータル」

では自治体向けのオープンデータ共通フォーマットとして「推奨データセット」を公開している。https://cio.go.jp/policy-opendata

25

図 2-17 PD7102(こども体験イベントに関するデータ項目の検討)の例

マスターデータ39、マスターコードなどのデータ項目定義に準拠した値が登録されるように、定義側で入力

できる文字の種類などに制約条件を設ける。データ項目ごとに値型を定義しておくことによって、入力時の

システム機能でエラー警告が可能になる。データ項目定義はデータの検証ルールとしても利用できるため、

後から間違いを検出する際も有効である。

このように異なる複数のデータ構造モデルを共通フォーマットで緩やかにつなぐ方法を、本ガイドではフ

ェデレーションと呼ぶ。とくに組織外のシステム間等でデータをやり取りする際には、システムや既存デー

タ構造の変更が不要なフェデレーションによるアプローチが適している。

データ項目がもつ意味や用語の共通化

データ項目対応表を用意し、「文脈」に即して用語をマッピング(対応づけ)する

共通フォーマットがあれば、既存システムのデータ構造を変更する必要はない。共通フォーマットのデー

タ項目と、既存データセットのデータ項目を照らし合わせて、データ項目対応表を作成する。作成の際は「既

存のデータ項目を共通フォーマットのどのデータ項目に置き換えるのか」「既存データセットの値をどのよう

に共通フォーマットに割り当てるのか」を決める。

例えば、図 2-18のデータセットに図 2-15の共通フォーマットを適用する40。

39 ここでは、企業内データベースなどで、処理の基本となるデータを集めたテーブルなどを意図する。一般的には「社員マスター」「顧

客マスター」のように対象の種類ごとに整備される。マスターデータの整備については政府 CIO ポータル標準ガイドライン群「マス

ターデータ等基本データ導入実践ガイドブック」を参照。https://cio.go.jp/guides

40 レコードがない状態で設計する場合も、必ず実際に値を入れて検証することがポイントである。

データ項目

項目分類 項目名 選択肢(リストの場合) 説明 記入例

地域 都道府県 ＊＊県

機関等名 主催者 主催者を記入 ＊＊気象台

共催・協力 共催や協力する企業等を記入

取組内容 タイトル 実施イベントのタイトルを記入

実施イベントがグループ化されているときにはグループ

名を［］でタイトルの前に記入

あついぞ！＊＊

お天気フェア

サブタイトル 実施イベントのサブタイトルを記入

内容 実施内容を記入(最大1000文字)

※最初の100文字程度で要約を記入すると、参加者がイ

ベントの内容を把握しやすくなります。

お天気キャスターのミニお天気教室、各種実験と工作、

自然災害体験車による体験、白バイ、震災対策活動用車

の展示、施設見学ほか

サブイベント イベント内に時間を区切って行うサブイベントがある場

合に記入

体験内容 学ぶ ○

ふれる・感じる ○

体を動かす

奏でる

乗る

見る ○

作る・描く

収穫・採集する

その他

集合場所 集合場所 当日の集合場所を記入 受付

建物 集合場所場所の建物名を記入 ＊＊気象台

イベントが該当するものすべてに〇を記入

26

図 2-18 既存データセットの例

それぞれのデータ項目と値を並べてみて、各項目が「全く同じ」「意味は同じだが項目名が異なる」「デー

タ項目に該当する値がない」「値はあるがデータ項目がない」などの仕分けを行う。既存のデータ項目の意味

や定義(数値の桁数や、値型、単位など)について、関連するデータ項目定義や、定義を裏付ける法・ルール、

参照コードリストと典拠などがあれば参照したり、ない場合は開発・運用担当者へ確認したりする41。

決まった方法はないが、図 2-19 のように Excel等を使って確認していく場合もある。この例では、「意味

は同じだが項目名が異なる」場合は緑、「データ項目に該当する値がない」は紫、同じ「データ項目に該当す

る値がない」でも「説明」の値から記述することにした項目をオレンジなどと色分けしている。

図 2-19 Excel を使ったマッピングの例

共通フォーマット上の「住所」は、ある顧客の「住民票の住所」かもしれないし、「勤務先の住所」の可能

性もある。データを扱うシステム等が決まっている場合は、データ項目の利用目的という「文脈」を確認し

た上で、人が用語を対応させる必要がある。郵便を届けたい場合と、居住地と勤務地の距離や所要時間から

健康への影響を分析したい場合では、優先すべきデータ項目や品質が変わるためである42。

2.2.1 で説明する「DMD」のようなデータモデル定義で作られたフォーマットであれば、作業支援ツールな

どを活用してこの作業を視覚的に行うこともできる。

41 一度に完全形を目指さず、段階的に整備する方法もある。データセットを集めてみると「備考欄」に多くのレコードが「受付開始時

間」と記載しているといった共通性の発見につながり、次期改版でデータ項目追加の証左になる。日々の運用の中でスモールスター

トしていくことが望ましい。

42 公開後にユーザーが利用目的を決めるオープンデータなどの場合は、推奨データセットなどの既存共通フォーマットを活用すること

で相互運用性の高い社会データ資産形成に資する。

都道府県コード又は市区町村コード

NO 都道府県名 市区町村名 イベント名 イベント名_カナ 開始日 終了日 開始時間 終了時間 開始日時特記事項 説明 料金(基本) 連絡先名称 連絡先電話番号連絡先内線番号

主催者 場所名称 郵便番号 住所 緯度 経度 アクセス方法 駐車場情報 対象者 定員 参加申込終了日 参加申込終了時間 参加申込方法 URL カテゴリー 画像

131059 0000000001 東京都 文京区 親子で楽しむスナッグゴルフとパターゴルフ オヤコムスナッグゴルフトパターゴルフ 2018-12-01 2018-12-01 13:30 17:15 なしヨネックス株式会社との協働事業として実施する、小学生を対象とした

1人100円 スポーツ振興課 03-5803-1308 2591 文京区 総合体育館 113-0033 文京区本郷7-1-2 35.708287 139.763191 都営地下鉄大江戸線本郷三丁目駅4番出口より徒歩約5分 無 小学生とその保護者（２人１組、保護者か子が区内在住・在勤・在学であること） 40組 2018-11-14 23:59 区ホームページ・携帯電話用区ホームページの「電子申請」又は往復はがきに「親子で楽しむスナッグゴルフとパターゴルフ」・児童と保護者の住所・氏名（ふりがな）・電話番号・児童の年齢または学年（在勤の場合は勤務地、在学の場合は学校名も）・利き手と返信用にもあて先を明記し文京区スポーツ振興課へ http://www.city.bunkyo.lg.jp/bunka/sports/sports.html スポーツ 無131059 0000000002 東京都 文京区 ジュニアスキー教室 ジュニアスキーキョウシツ 2018-12-15 2018-12-15 9:30 15:30 なし

文京区スキー協会の指導のもと実施する、小学生を対象としたスキー

1人2500円 スポーツ振興課 03-5803-1308 2591 文京区 狭山スキー場 359-1153 埼玉県所沢市 35.768447 139.418718 西武池袋線「西武球場前」駅より徒歩約３分 有 区内在住・在学の小学生 40名 2018-11-18 23:59 区ホームページ・携帯電話用区ホームページの「電子申請」又は往復はがきに「ジュニアスキー教室」・参加者全員の住所・氏名（ふりがな）・電話番号・性別・年齢・学年（在学の場合は学校名も）と返信用にもあて先を明記し文京区スポーツ振興課へ http://www.city.bunkyo.lg.jp/bunka/sports/sports.html スポーツ 無131059 0000000003 東京都 文京区 はじめての親子フットサル教室 ハジメテノオヤコフットサルキョウシツ 2018-12-08 2018-12-08 9:15 11:45 指導時間は未就学児の部と小

文京区を拠点とするサッカークラブ「TOKYO UNITED」との協働事業と

1組200円 スポーツ振興課 03-5803-1308 2591 文京区 江戸川橋体育館 112-0006 文京区小日向1-7-4 35.710398 139.735532 東京メトロ有楽町線江戸川橋駅4番出口より徒歩4分 無 どちらかが区内在住・在学・在勤の4歳児～小学3年生の子とその保護者（子がフットサル・サッカー未経験であること） 各部15組30名 2018-11-26 23:59 区ホームページ・携帯電話用区ホームページの「電子申請」又は往復はがきに「親子フットサル教室」・参加者全員の住所・氏名（ふりがな）・電話番号・性別・年齢（在学の場合は学校名も）と返信用にもあて先を明記し文京区スポーツ振興課へ http://www.city.bunkyo.lg.jp/bunka/sports/sports.html スポーツ 無131059 0000000004 東京都 文京区 文京ベースボールフェスタ ブンキョウベースボールフェスタ 2018-11-25 2018-11-25 9:00 11:20 なし

トヨタ自動車、東京大学硬式野球部との協働事業として実施する、満５・

1組100円 スポーツ振興課 03-5803-1308 2591 文京区 東京大学弥生キャンパス硬式野球場113-0033 文京区本郷7-3-1 35.712056 139.762775 東京メトロ南北線東大前駅より徒歩1分 無 区内在住で事業実施日に 満5歳または6歳の子どもと保護者 50組100名 2018-11-12 23:59 区ホームページ・携帯版の「電子申請」又は往復はがきに、参加される方全員の住所・氏名(ふりがな)・性別・年齢・携帯・電話番号 ・メールアドレス・返信用はがきにもあて先を明記し文京区スポーツ振興課へ http://www.city.bunkyo.lg.jp/bunka/sports/sports.html スポーツ 無

地域 機関等名 取組内容 集合場所

都道府県 都道府県コード又は市区町村コード

NO主催者 共催・協

力

タイトルイベント名_カナ

サブタイト

ル

内容 サブイベ

ント

体験内容 集合場所

学ぶ ふれ

る・感

じる

体を動

かす

奏でる 乗る 見る 作る・

描く

収穫・

採集す

る

その他

都道府県名都道府県コード又は市区町村コードNO 市区町村名 イベント名 イベント名_カナ 説明 場所名称東京都 131059 0000000001 文京区 ○○株式会社親子で楽しむスナッグゴルフとパターゴルフオヤコムスナッグゴルフトパターゴルフ○○株式会社との協働事業として実施する、小学生を対象としたスナッグゴルフとパターゴルフの教室○ ○ 総合体育館東京都 131059 0000000002 文京区 ジュニアスキー教室 ジュニアスキーキョウシツ 文京区スキー協会の指導のもと実施する、小学生を対象としたスキー教室○ 狭山スキー場東京都 131059 0000000003 文京区 はじめての親子フットサル教室ハジメテノオヤコフットサルキョウシツ文京区を拠点とするサッカークラブ「TOKYO UNITED」との協働事業として実施する、4歳児～小学3年生の子とその保護者を対象としたフットサル教室○ 江戸川橋体育館東京都 131059 0000000004 文京区 ××自動車、▽▽大学硬式野球部文京ベースボールフェスタ　 親子ティーボール教室ブンキョウベースボールフェスタ　 オヤコティーボールキョウシツ××自動車、▽▽大学硬式野球部との協働事業として実施する、満５・６歳児及びその保護者を対象としたティーボール教室○ ▽▽大学キャンパス硬式野球場

27

図 2-20 IMIツールを使ったマッピングの例

(出典) https://imi.go.jp/tools/v2/convert

共通フォーマットは、初回のデータ交換前におけるデータ構造の整理に負担がかかるが、一度インターフ

ェイスを開発すると、2回目以降の変換作業の負担を大幅に減らせる。

運用開始後のデータ項目の変更管理

データとデータモデルは常に変化し続ける。法改正やルール変更、事業戦略やビジネスモデルが変化すれ

ば、それを表すデータモデルやデータ項目も変わる。データを扱うデバイスや技術も進化し続ける。変化を

前提として、活用ニーズを汲みつつ、データやデータモデルを管理する担当者が、一元的に変更を管理する。

「1.2 データ流通・連携を阻む壁」を防ぐための大切なルールである43。

共通フォーマットの変更管理

システム担当者間でどのような変更を行うのかに関する合意形成を行い、ロードマップの作成やスケジュ

ール管理を行う共通の「場」や推進体制を設ける。

43 データベースの品質管理は、データ保有者である業務部門など、責任を担う部署を特定することが望ましい。

28

2.2 共通フォーマットと語彙体系の活用

データ連携標準の体系

共通のデータ連携標準を使うと、社会全体でデータの相互運用性が高まりやすい。政府によるデータ連携

基盤、共通語彙基盤や「推奨データセット」をはじめとする具体的なフォーマットの整備、「第 3章実装方法

を事例から学ぶ」でとりあげる内外の取組みも、データ活用という協調領域における参加者の負担を抑制し、

活用されやすいデータの公開、流通を促進するために進められている。

日付、電話番号等データ記述の原則44に基づき、共通語彙基盤の基本項目を「避難場所」など現場で利用す

るデータセットの目的に合わせてモデル化したデータ項目定義書と入力テンプレートが「推奨データセット」

であり、推奨データセット等に基づき作成されたデータセットを、社会全体でデジタルに活用しやすいよう

定義するための枠組みが「データモデル記述(Data Model Description、以下 DMD)」である。第 3章でとりあ

げる米国 NIEMや XBRL なども、同様の円滑なデータ交換を目的とした枠組みやサンプルを提供している。45

図 2-21 政府 CIOポータルで示されるデータ体系の全体像

(出典)推奨データセットについて

推奨データセットにみる共通フォーマットの活用例

推奨データセットは「2.1.2 用語やコードの意味の伝達」で説明した通り、あらかじめ共通語彙基盤に則っ

たデータモデルや典拠が定義してあり、データ入力用の Excel シートと併せて提供されている。オープンデ

44 政府 CIO ポータルでは、手続や情報提供において分野を問わず使用される基本的なデータの形式について、データ連携を円滑に行え

るよう、基本的なデータの記述形式を示したモデルを「行政基本情報データ連携モデル」として公開している。2019年 12月現在、日

付時刻、住所、郵便番号、地理情報、電話番号、POIコード、POIコード一覧がある。

45 DMDは、NEIMにおける IEPD(information Exchange Package Documentation)に相当する。

・・・

行政データ連携標準（仮称）α版

共通語彙基盤

実装モデル群（策定中）

推奨データセット

コンピュータ上で表現する基本情報に関するデータ形式を規定

法人、連絡先等、社会で共通に使われるデータ項目と構造を定義（社会の情報化、デジタル・ガバメントのために整備中）

施設、イベント等、社会で実際に使うためのデータセットを定義（実装モデル群とDMDは将来融合）（社会の情報化、デジタル・ガバメントのために整備中）

公開ドラフト

データモデル記述（DMD）

具体的対象物に関するデータセット（官民データ法の推進の一環で作成）

文字情報基盤

コード体系

応用データ

共通データ

具体的対象物に関するデータセット（コミュニティやプロジェクトで作成）

コンピュータ上で使用する文字に関する規程

社会全体で使うコードを規定

独自コード

応用サービスに必要で追加したコード

・・・

データ体系の全体像

4

29

ータ推進を求められる自治体はもちろん、施設情報や避難場所等関連するデータセットのモデルを検討する

民間企業にも参考になる。共通フォーマットの存在により相互運用性の高いデータ公開が進んだ。

さらに、推奨データセットをもとに自治体職員やシビックテック参加者によってより使い勝手の良いデー

タフォーマットが検討され、「PD6943(避難所に関する語彙の検討)」として公開されている。その成果はやは

りシビックテックメンバーにより可視化され、市民にとって使いやすい形で利用できるようになっている。

図 2-22 推奨データセットをもとに相互運用性の高いデータ公開が進みアプリに活用された例

(出典) 避難所 MAP https://public.tableau.com/profile/sayoko.shimoyama.linkdata#!/vizhome/PJ_1/PJ

定義をデジタルに共有する枠組み

アプリ等での活用を想定する場合のデータ連携基準は、DMD などコンピューターが理解しやすい形で提供

されていると相互運用性が確保できる。共通語彙基盤 DMD の場合は、共通的な情報交換のため雛形となるフ

ァイル群とテンプレート、またデータを活用する人が DMDを記述するための技術仕様を公開している。DMDに

は図 2-23のような、コード等に関する条件、サンプルなどのファイル群が含まれる。

図 2-23 DMDの構成要素

DMD

DMD利用者へ向けた説明文書

データ作成

アプリケーション開発者

データ分析者

データ利用

データモデル利用者

データモデル設計者

アプリ等利用者アプリDMDヘッダー• メタデータ• DMDに含まれるファイルリスト

header.json

IMI定義文書• メタデータ• 語彙定義• クラス定義• プロパティ定義• 用語使用宣言

datamodel.txt

データモデルとデータ項目一覧との対応関係

mapping.json

サンプル

form.csvmeta.md

dmd.zip

30

DMDは、「2.1.2(4)意味構造の伝達」の手段のひとつである。「2.1 情報を公開・交換するための手法」で整

備したデータ項目定義を DMD に記述し、定義に沿ったデータをシステム等で交換、活用する際、人間とコン

ピューターが設計を正しく理解できる。2回目以降の変換作業の負担を大幅に減らすことができる。

共通語彙基盤が雛形として公開する DMDには、氏名、住所、組織、設備、イベント、避難施設、医療機関、

法人基本情報、法人活動情報など、十数種類がある。これらを応用し独自の定義を加えることも可能だ。

図 2-24 IMI共通語彙基盤が公開する DMD

(出典) https://imi.go.jp/dmd/

なお、共通語彙基盤は米国 NIEM (National Information Exchange Model)46を参考に検討された。DMDは

NEIMにおけるデータ項目定義の仕様である IEPD(information Exchange Package Documentation)に相当す

る。

枠組みの活用方法

データ対応表の作成

自組織内で保有するデータセットに近い構造の DMD が共通語彙基盤にある場合は、DMD のデータ項目に対

して対応表を作成する。IMI ツールを使うと、既存 DMD をアップロードまたは参照して読み込んだデータモ

デルと表形式のデータ項目を視覚的にマッピングできる。

46 3.6米連邦政府 NIEMを参照。

31

図 2-25 IMIツールを使った対応表の作成

(出典) https://imi.go.jp/tools/v2/convert

情報交換用データセットに変換

自組織の情報と共通語彙基盤の対応表、連携先のデータと共通語彙基盤の対応表を見て、情報交換方式を

検討する。双方ともに情報交換用データセットに変換して送受信を行えるように準備する。

IMIツールの場合、マッピングはブルーの線を使ってデータ項目同士を結び付けていく。データ項目名が全

く同じ場合は、自動的に対応づけがなされる47。

47 データ項目名が同一の「住所」であっても、「避難場所の住所」「イベント会場の住所」など、指し示す実態は異なる場合がある。ツー

ルを利用する場合も、「2.1.2用語やコードの意味の伝達」で説明した通り、実際の値を入れて整合を確認する必要がある。

① DMDを読み込む

② 表形式データのファイルを読み込む

読み込まれたDMD

読み込まれた表形式データ

32

図 2-26 表形式データのデータ項目(左)と、DMDのデータ項目をマッピング

(出典) https://imi.go.jp/tools/v2/

共通フォーマットのデータセット連携

データ連携先と、共通フォーマットの DMD を共有する。参加者が同じフォーマットを利用することにより、

システム Aもシステム Bも変更することなくデータを相互運用できる。

図 2-27 IMIツールの場合は、DMDに従って変換された構造化データとマッピングファイルを自動生成

(出典) https://imi.go.jp/tools/v2/

図 2-28に、DMDの利用手順(1)(2)(3)の位置付けを示す。

33

図 2-28 DMDの利用手順

IMIツールを使って DMDと表形式データファイルの対応を行った場合は、DMD仕様に沿った「マッピングフ

ァイル」が生成される。17ページ図 2-4仕入先マスターデータを例にすると、"ID"というデータ項目は、コ

ア語彙の ic:識別値で、すなわち応用語彙の定義の”ex:仕入先情報型>ic:メタデータ>ic:ID>ic:識別値"の

構造でわかる。

{

"mapping": {

"通し番号": "ex:仕入先情報型>ex:通し番号",

"ID": "ex:仕入先情報型>ic:メタデータ>ic:ID>ic:識別値",

"仕入れ先情報 1": "ex:仕入先情報型>ex:会社形態",

"仕入れ先情報 2": "ex:仕入先情報型>ex:会社名",

"使用通貨": "ex:仕入先情報型>ex:使用通貨",

"支払い条件": "ex:仕入先情報型>ex:支払い条件"

}

}

図 2-29 マッピングファイルの例((「ex:」は、サンプルとして仮に用いた接頭辞)

意味の共有

語彙は、単なるラベルではなく、データの本質的な意味を表す概念と、概念間の関係性、付加情報によっ

て記述されるナレッジを伝える。IMI 共通語彙基盤や「第 3 章実装方法を事例から学ぶ」でとりあげる NIEM

は、相互運用性の度合いに応じて、語彙を「コア語彙」と「ドメイン語彙」に分けて整理している。

共通語彙基盤におけるコア語彙は、「人」、「施設」、「イベント」といった事柄(事物やできごと)を表すクラ

ス概念と、「性別」や「所有者」といった、事柄のもつ特定の性質や属性を示すプロパティ概念で構成される。

一つの概念に一つの代表的な表記(概念の名称に対応する語)を用意した語が、「人」、「施設」、「イベント」

といった用語である。組織外データ連携などのシーンでは、「2.1.2(5)ネーミングルールの整備」で示した「顧

客」という抽象概念の相互運用性を、さらに向上させる必要が生じる。その際、データ項目定義をコア語彙

の「人」で記述することにより、データセット上のデータ項目名は「カスタマー」「VIP」あるいは「顧客」と

したままで、「人」を扱うデータであるという本質的な意味を組織内外で共有できる。

コア語彙は、IMI 共通語彙基盤が一元的に策定・運用し無償公開している。分野を問わず使われる基本的な

システムA システムBデータ項目 値

種別 事業所住所

国 日本

都道府県 東京都

市区町村 千代田区

町名 霞が関

丁目 3

番地 3

号 3

ビル名 Gビル

ビル番号 A

部屋番号 132

住所コード

郵便番号 1000013

システムAのデータを共通フォーマットに変換

○交換可能

変換

データ項目 値

事業所 100-0013千代田区霞が関三丁目三番地三GビルA132

データ項目 値

郵便番号 1000013

住所 千代田区霞ヶ関3-3-3

方書 GビルA132

…

データ項目 値

種別 事業所住所

国 日本

都道府県 東京都

市区町村 千代田区

町名 霞が関

丁目 3

番地 3

号 3

ビル名 Gビル

ビル番号 A

部屋番号 132

住所コード

郵便番号 1000013

システムBのデータを共通フォーマットに変換

変換

(1)(2) (3) (1)(2)

34

事柄を対象として、事柄を示すクラス用語(クラス概念)と、性質や属性を表すプロパティ用語(プロパティ概

念)が整備されている48。

ドメイン語彙は、防災、財務といった各分野において共通な用語の集合であり、コア語彙を継承して定義

されることを想定している。共通語彙基盤では、ドメイン語彙は誰でも検討することができる49。

ドメイン語彙やデータセットのデータモデル定義や更新にあたっては、コア語彙や既存のドメイン語彙だ

けでは不足することが多く、独自の語彙を定義する必要がある。こうしてビジネスや既存データセットに合

せて定義された語彙を、IMI 共通語彙基盤では応用語彙と総称している。応用語彙は、共通性の高い語彙の整

理などを経てドメイン語彙として共有されることを想定している50。

応用語彙の定義方法

「2.2.5意味の共有」で述べた通り、コア語彙のみでデータ項目を定義できるケースは少ない。合致する語

彙がない場合は、新たに定義する。

「ic:組織関連型」に定義された用語で表現できない「使用通貨」などのデータ項目は、図 2-30のように

新たな「ex:仕入先情報型」などのクラス用語を定義し、そのプロパティ用語として「ex:使用通貨{/{1,10}/」

を定義する。

#prefix ic: "http://imi.go.jp/ns/core/2#"

#prefix ex: "http://example.org/"

vocabulary "http://example.org/" ; class ex:仕入先情報型{@ic:組織関連型};

property ex:通し番号{@xsd:decimal};

set ex:仕入先情報型>ex:通し番号{/[0-9]{6}/};

property ex:会社形態{@xsd:string};

set ex:仕入先情報型>ex:会社形態{/{1,10}/};

property ex:会社名{@xsd:string};

set ex:仕入先情報型>ex:会社名{/{1,20}/};

property ex:使用通貨{@xsd:string};

set ex:仕入先情報型>ex:使用通貨{/{1,10}/};

property ex:支払い条件{@xsd:string};

set ex:仕入先情報型>ex:支払い条件{/[a-zA-Z0-9]{1,10/}; datamodel;

use ex:仕入先情報型>ex:通し番号;

use ex:仕入先情報型>ic:メタデータ>ic:ID>ic:識別値{<=999999};

use ex:仕入先情報型>ex:会社形態;

use ex:仕入先情報型>ex:会社名;

use ex:仕入先情報型>ex:使用通貨;

use ex:仕入先情報型>ex:支払い条件;

図 2-30 仕入先マスターデータの例における応用語彙の定義例

48 IMIのコア語彙バージョン 2.4.2は、63個のクラス用語、246個のプロパティ用語を公開している。

49 NIEMは「第 3章実装方法を事例から学ぶ」で説明する通り、ドメインごとにオープンな検討体制が設置されている。

50 デジタルプラクティス Vol.9 No.1(Jan. 2018)論文「IMI共通語彙基盤」より。

https://www.ipsj.or.jp/dp/contents/publication/33/S0901-S02.html

35

なお、仕入先の識別に用いる ID の値(0 から 999999 まで)はコア語彙で定義済みの構造と相互運用性をも

つ必要があるため、「ic:ID型」及び、そのプロパティ用語「ic:識別値」の定義をそのまま利用する。

コア語彙同様の構造定義の思想は、Schema.org などの標準でも採用されている。Schema.org は、ウェブペ

ージに構造化データを埋め込むための拡張可能な定義のセットである51。ウェブサイトの開発者や管理者が、

検索エンジンや各種アプリケーションで構造データを提供する際のデータ定義として参照する。Schema.org

は、主に語彙の実装をサポートするために設計された用語及びその説明を提供している。

例えば「映画(Movie)」を基軸にしたデータセットを見ると、図 2-31のようにクラス”Movie”型のデータ

構造を構成する複数のデータ項目のうちの”Person”が取りうる属性や関係として“director”や"author”

が定義されている52。director が特性(Property)であることは、図 2-31「Thing > Property > director」

の表現を用いて示されている。

ｓ

51 CreativeWorksのほか、ECサイト等で使える Productや Review、料理レシピやニュース記事などの定義が公開されている。

52 authorは"Person“のほか”Organization”で表現することも想定されている。

36

図 2-31 “Movie”のデータ構造を構成する複数のデータ項目のうち”Person”が取りうる値の属性の例

(出典)Schema.org

director や author などの特性は、Movie 型以外のクラス(TVSeries 型や VideoGame 型)でも用いられる。

言い換えると、directorやauthorのようなPerson等、複数の特性をデータ項目に備えた概念として”Movie”

や”TVSeries”等の型(クラス)が定義される。概念は、複数の特性によって構成され、意味を伝える。

”Movie”や”TVseries”といった概念の上位には”CreativeWork(創造的作品)”の概念が位置付けられ

る。逆に”CreativeWork”という概念の個表現(Thing)として”Movie”や”TVseries”等がある。”Movie”

と”TVseries”は、共通項はあるが別の概念であり、それぞれ必要な特性から構成される概念の構造をもつ。

コア語彙にせよ Schema.org にせよ、表現したい事象・事物の概念を特定すると、コンピューターは”Movie”

と”TVSeries”を区別しやすい。逆に、データ項目のラベルが「仕入先」「調達先」などと異っていても、概

念や特性の組み合わせが近ければ、類似する概念として、他の概念と区別できる。

語彙の構造

共通語彙基盤では、人の姓名を記述するための用語を以下のように表現する。

人型>氏名>姓名

人がもつ属性を備えた「人型」クラスのプロパティ「氏名」の先にある「姓名」プロパティを示している。

図 2-32 クラスとプロパティ

図 2-32で示すのは、以下の情報である。

37

⚫ 「人型」クラスは人の表現方法として氏名や性別など複数のプロパティをもつ

⚫ 「人型」の「性別」プロパティの値型は文字列(例:「男」)

⚫ 「人型」の「氏名」プロパティの値型は「氏名型」(人の氏名を表現するためのクラス用語)クラス

⚫ 「氏名型」クラスは氏名の表現方法として姓名や姓名カナ表記など複数のプロパティをもつ

⚫ 「氏名」プロパティ(氏名型)の先の「姓名」プロパティは文字列(例:「葛飾北斎」)

⚫ 「氏名」プロパティ(氏名型)の先の「姓名カナ表記」プロパティはカナ文字列(例:「カツシカホクサイ」)

なお、図 2-33 のように、実際には「人型」や「氏名型」は図 2-32 で例示した以外に多数のプロパティを

もっている。IMI共通語彙基盤ではこの仕組みにより、意味を理解しやすく語彙を定義することができる。

図 2-33 「人型」がもつプロパティの一部

クラス用語と、クラス用語に含まれるプロパティ用語には、それぞれデータの値型や、データとデータの

関係が定義されている。コア語彙の定義とデータセット中のデータ項目定義が完全に一致する場合は、デー

タ項目名と使用するクラス用語やプロパティ用語を対応づける53 。

図 2-34 プロパティ用語の定義例

53 クラス用語はデータモデルにおけるエンティティに相当し、プロパティ用語はデータ項目に相当する。

38

共通語彙基盤では、語彙を記述する文法である構造化項目名記法54を使い、あるクラスを継承して、プロパ

ティの追加により新たなクラスを定義できる55。このような共通語彙に基づいて作られたデータベースでは、

データ項目名ごとに値型などが事前に定義されているため、データを扱うルールが関係者の間で明確になる。

そのため、データの品質が高まり、より情報を公開または交換しやすい仕組みが実現できる。

IMI共通語彙基盤により、次のようなメリットが得られる。

(1) データモデルを DMD で定義することで、データベースやアプリケーションの開発者にデータの意図が

伝わりやすくなる。

(2) 第三者が後からそのデータベースを見たときに、データ項目定義や値の意味を理解できる。

(3) (2)は、特に組織外とデータセットをやりとりするときにも有効である。データセットに、DMDを添え

て流通させれば、データ流通の基盤を支える仕組みになる。

図 2-35 IMI対応であることを示したオープンデータの例

(出典)加古川市ホームページ「オープンデータの提供について」より。

http://www.city.kakogawa.lg.jp/soshikikarasagasu/kikakubu/jouhouseisakuka/opendata/opendata_kaishi.html

54 「人型>氏名>姓名」のように、クラス用語やプロパティ用語の継承関係の階層構造を一行の文字列で表現することができる記法

55 既存のクラス用語のプロパティを削除、制約することはできないが、該当するデータ項目がない場合は使用しなくて良い。

39

2.3 法人インフォメーションへの適用例

第 2章で説明してきたアプローチの適用例として、経済産業省が運用する「法人インフォメーション」を紹介する。

概要

「法人インフォメーション(法人インフォ)」は、省庁が保有する約 400 万団体の法人情報を一括検索しデ

ータを取得できるデータベースで、2017年 1 月から無料公開されている。法人番号、法人名、本店所在地の

「法人基本情報(3 情報)」及び代表者名、資本金、従業員数、営業品目、事業概要などの「法人基本情報」、

また男女別平均勤続年数や女性労働者比率などの職場情報、補助金、調達、特許、財務などの「法人活動情

報」などを提供している。

図 2-36 法人インフォでは 400万団体の法人情報を一括検索可能

(出典)法人インフォメーション

法人インフォのデータ源は、各府省が保有する法人活動情報である。国税庁「法人番号公表サイト」、総務

省「統一資格有資格者」、厚生労働省「職場情報総合サイト」、金融庁「EDINET」は API、それ以外は CSV 等の

データを府省担当者がアップロードしている。これらの情報は随時更新、拡充され、利用者が様々な条件を

もとに検索、ダウンロードできる56。

法人インフォは、官民データ活用推進基本計画が進める法人デジタルプラットフォームの中核データベー

スであり、分野間データ連携基盤の先行事例でもある。法人インフォに集約される法人データをもとに、法

人行政手続きのデジタル化が推進されている。

56 法人インフォの実装においては、蓄積されたデータを、表形式のリレーショナルデータベース(RDB)ではなく、グラフデータ(RDFデー

タ)として格納・配置している。そのため、SPARQLエンドポイントや SPARQL APIを介する高度な条件に基づく検索や、検索結果やダ

ウンロードデータに基づくシステム開発が可能になっている。REST APIを用いた IMI共通語彙基盤の語彙を用いないシンプルなデー

タ検索や取得環境も用意している。

40

図 2-37 法人インフォの全体像。各府省のデータ項目と法人情報語彙のプロパティ用語をマッピングし

た法人インフォ用 DMD を使いデータ変換や法人番号付与やデータの整形、名寄せをシステム化。

法人インフォにおけるデータ相互運用性確保の取組みマッピングと、データ項目(ラベル)の定義

法人インフォは、各府省が保有する、データ項目定義やデータ項目名の異なるデータを集約、更新するた

めに、共通語彙基盤の仕組み(データ項目へのマッピング)を利用している。

例えば、ある省庁が提供しているシステムの「認定日」というデータ項目を、法人インフォのデータへマ

ッピングするために、共通語彙基盤では mapping.json ファイルに次のように記述する。

図 2-38 法人インフォにおけるマッピングとデータ更新

2 行目の右端にある「ic:標準型日付」は、共通語彙基盤のコア語彙 2.4.2における「日付を記述するため

のプロパティ用語」を指す。

図 2-39 コア語彙 2.4.2「標準型日付」の定義。データ記述に使われる用語の意味は URI で指定可能。57

(出典)コア語彙 2.4.2

図 2-39 に記された「説明」では、「標準型日付」データの書式が、「XMLの xsd:date 型に準拠したもの」

であり、また、「日付型」(日付を表現するクラス用語)のプロパティ用語の 1つに該当していることを示して

57 この場合、https://imi.go.jp/ns/core/2 #ic:標準型日付。

41

いる。

xsd:date は、W3C XML Schema58標準で定義された値型で、「yyyy-mm-dd」の形式で年月日を表示することに

なっている。このように「ic:標準型日付」でデータの型を指定することで、「2019-04-01」以外の「2019/4/1」

や「平成三十一年四月一日」など異なる型の値は、システムが排除できる。この定義が「1.2.3「壁」の背景」

で触れたデータセット登録時の事前チェックルールであり、データ検証や品質の基準として機能している。

また、図 2-38の同じく 2行目において、「hj:」で始まる用語があるが、「hj:」は事前に定義・予約された

法人情報語彙59を示す接頭辞である(houjinから取っている)。

2 行目では、データ項目「認定日」が、「法人情報の法人活動情報の補助金の認定日」であり、「yyyy-mm-dd」

という数字と文字の組み合わせ(データフォーマット)で表記されることが定義されている。語彙を「>」で連

結する書き方は、前節で触れた構造化項目名記法である。

データ項目名は必ずしも、「認定日」というラベルでなくても構わない。例えば、「特許情報の届出認定情

報」における「出願年月日」でも差し支えない。「認定日」と「出願年月日」は日本語の表現が異なるが、電

子的に同じ定義がなされていれば、コンピューターは同一のデータ項目だと判別できる。

「出願年月日」であれば、「認定日」の時と同様、図 2-40のように「"認定日"」というデータ項目を「"出

願年月日"」に置き換えるだけで定義できる。法人情報語彙 DMDに含まれるマッピングファイル中のラベル部

分を、各府省の既存システムのデータ項目ラベルに書き換えることで、データ項目を対応づけられる。

図 2-40 ラベルとデータ項目のマッピング例

実際の運用と効果

法人インフォでは、上記の法人情報 DMD 定義に基づいて、各府省が保有するデータセットそれぞれのデー

タ項目をあらかじめマッピングし、ファイルで提供している。各府省担当者が行う法人インフォのデータフ

ォーマットに合せたデータセットの変換作業負荷が軽減されている。

58 XML Schemaは、マークアップ語彙の定義及び、XML文書で利用される語彙と、語彙のセマンティクス(意味)の定義を行う。World Wide

Web Consortium (W3C)が勧告として仕様が公開されている。

59 法人情報語彙はドメイン語彙として公開予定であり、名前空間は「http://imi.go.jp/ns/domain/hojin/」の配下に指定される。

"出願年月日":"hj:法人情報型>hj:法人活動情報>{補助金型{@hj:補助金型}>hj:認定日>ic:標準型日付}"

42

図 2-41 法人インフォにおける DMDの活用例

併せて、住所データの正規化60や、会社形態を表す「(株)」「株式会社」などの表記の違い(揺れ)、半角カ

ナ文字などを一定ルールにもとづいて自動変換する IMI ライブラリ機能を活用している。

法人インフォのデータは常に更新されているが、マッピングファイルによって作業負担軽減とデータ品質

向上に役立つ。データ項目が追加・変更された場合は、該当箇所のみマッピングを編集することで、システ

ムの更改に対する柔軟性と拡張性も保持される。

法人情報語彙は、IMI 共通語彙基盤におけるコア語彙の更新や、法人インフォで公開される情報種別の追

加に応じて、継続的に改善されている61。法人インフォは、法人デジタルプラットフォームの中核データベー

スとして、行政サービスにおけるワンスオンリーなどのサービス向上や政策効果分析での活用、事業創出な

どへの寄与が期待されている。また、「3.3省庁 Aにおける DX推進」でとりあげる「○○マスター」は、法人

インフォとの相互運用性を確保した開発を予定している。

60 「東京都文京区本駒込２丁目２８−８」のように一行に表記された住所の値を、法人情報語彙で定義された都道府県、市区町村、町名、

丁目、番地、号へ分割すること

61 XBRLコミュニティのメンバーとも積極的な知見の交換を行っている。

統一資格

e-Gov

公益法人

info

知財

法人インフォメーション

変換・登録

csv、xlsxなど

既存ウェブサービスのデータを取得

法人番号

自動変換・登録

API

で取得

府省管理情報を取得

DMD

調達

表彰

届出・認定

補助金

職場情報

EDINET

マッピング

マッピング

マッピング

マッピング

マッピング

WebAPI

マッピング

マッピング

マッピング

民間サービス

WebAPI

43

第3章 実装方法を事例から学ぶ

データの相互運用には、組織内外のステークホルダーの理解と協力が不可欠である。第 3 章では、データ活用とい

う協調領域における目的を共有しながら、分権的に利害調整などの運用を行う事例を分析する。

3.1 企業開示情報の相互運用基盤 XBRL

2020年 3月版で公開予定です。

XBRL の概要

XBRL 以前の課題

改善したこと

変化を前提にしたタクソノミの拡張とメンテナンス

合意形成の考え方

IMI 連携

44

3.2 ステークホルダーニーズを取り込み、使われる標

準を整備 地方公共団体 B

2020年 3月版で公開予定です。

概要

対象データ

参加者とリーダーシップ

受益者

典拠(政策、法制度など)

定義している標準

導入前の課題

解決したこと

成功要因

運用プロセス、体制など

技術面

45

3.3 省庁 A における DX 推進

2020年 3月版で公開予定です。

概要

対象データ

参加者とリーダーシップ

受益者

典拠(政策、法制度など)

定義している標準

導入前の課題

解決を目指すこと

利用方法

合意形成

46

3.4 製造サプライチェーンでのデータ連携と辞書整備

2020年 3月版で公開予定です。

概要

対象データ

参加者とリーダーシップ

受益者

典拠(政策、法制度など)

定義している標準

導入前の課題

解決したこと

成功要因

運用プロセス、体制など

技術面

その他特徴、近況など

47

3.5 業界横断のデータ取引市場活性化の取組み

2020年 3月版で公開予定です。

概要

対象データ

参加者とリーダーシップ

受益者

典拠(政策、法制度など)

定義している標準

導入前の課題

解決したこと

成功要因

運用プロセス、体制など

技術面

48

3.6 米連邦政府 NIEM

2020年 3月版で公開予定です。

概要

対象データ

参加者とリーダーシップ

受益者

典拠(政策、法制度など)

定義している標準

導入前の課題

解決したこと

成功要因

運用プロセス、体制など

技術面

49

第4章 将来を見据えた取組み

データ資産の可視化や、情報交換プラットフォームの維持管理は、運用開始後も継続的に行う必要がある。特に、拡

充される語彙の体系が自律的に発展していくには、関係者間における合意形成の場(コミュニティ)が欠かせない。

組織内で整備する持続可能な体制や取組みを、どのようにコミュニティと連携させていくのか、その展望を示す。

組織の主体的な活動

前章までに紹介した事例から、異なる組織間でデータを円滑に交換する、相互運用性の考え方と実装例を

述べた。実践には、官民データ活用社会の参加者である各組織が日々業務を行う上で留意点がある。これま

で記してきた内容を整理しつつ、まとめたい。

データ資産の把握とガバナンス

組織には、システムから独立したファイルとして運用されるデータセット、データベースやデータを処理

し活用するための情報システム上のデータセットが存在する。また、組織外から定期/不定期に、かつファイ

ルとしてあるいは API 等を通じ入手するデータも存在する。ただ、データ及びデータ項目の定義などを含む

付加情報は、組織の中に埋没しやすい。

まず、組織内にどのようなデータセットが存在するのか、システムや部署ごとに、第 2 章でとりあげたデ

ータカタログ等のテンプレートを活用して一覧に整理する。そして各データセットの設計図であるデータ項

目定義書などのドキュメントを整備し、業務で用いる用語との対応づけや値の品質を判断する基準などを一

元的かつ継続的に可視化する。言い換えれば、データが資産として活用可能で、かつ適切に管理・保護可能

な状況を整備する。整備した情報はデータ交換用フォーマットのデータ項目との対応づけで最も基本的な情

報になる。一度可視化しておけば差分情報の管理で済み、活用対象データの変化に適応しやすい。市場で提

供される可視化支援ツールの活用も一考に値する。

0.1.1 ガイドの目的で、サイバー(仮想)空間とフィジカル(現実)空間を高度に融合させる Society 5.0 に

触れた。現実をデジタルに表現しようとする仮想空間のデータは、現実の「写し鏡」である62。現実とデータ

をともに見つめながら、現実の変化に合わせて常に見直さなければならない。データ資産管理を組織におけ

るデータやナレッジの継承の営みと明確に位置づけ、引き継いでいくべきである。

「第 2 章解決に向けたアプローチ」の通り、データ項目定義に合致する「正しいデータ」を扱うことは、

データ活用の最低限の要件である。信頼性の高いデータを必要なタイミングで事業へ活用できる環境、そし

てビジネスゴール達成のためにウォッチすべき数値と解釈の価値観を共通言語として共有する文化や風土の

醸成が、データ活用社会における組織の競争力の源泉である。

データ活用には組織には、全員の参加と自覚が重要である。データやデータモデルの読み方、伝え方など

62 物理空間に実在するモノをサイバー空間のコンピューター上に再現した双子をメタファーに、「デジタルツイン」ともいう。

50

は組織内の共通言語として活用できるよう、業務知識の習得と併せて定期的な研修や教育の場を事業の一環

として設けることが望ましい。

継続的な運用管理体制の設置

データ資産の設計情報に関する可視化作業は、一度きりで終わりではない。ビジネスモデルを反映するデ

ータモデルやプロセスモデルを実体化したものがデータベースとデータを処理するシステムであり、ビジネ

ス上の競争環境や戦略に伴って常に変化するからだ。

密結合していたデータを収集・蓄積・処理するシステムとデータを切り分けて取り扱えると、老朽化した

システムを最新技術に合せて更新する作業や、より高度なデータ利用もやりやすくなる。

「2.1 情報を公開・交換するための手法」で説明したデータ資産運用や社内のデータ項目やコード、記述ル

ールなどの取組みが機能するためには、業務横断的なデータ資産管理部門の設置が望ましい。経営層と連携

して部署横断的に活動する権限をもつ統括的な CDO の設置も一部で進む。長期的なスパンにおけるデータ活

用人材育成への戦略的な投資も必要だ。「0.1.2 デジタルトランスフォーメーションへのアプローチ」で触れ

た通り、データ活用と DXは表裏一体である。

公開された語彙を利用

XRBLのタクソノミや IMI共通語彙基盤のように公開・運用されている体系的に定義された語彙や情報交換

用のフォーマット情報を活用する。標準的なナレッジの積極的な有効活用により、データ項目の定義などを

一から行う手間が省け生産性が高まる。データ共有相手、特にマルチステークホルダーとの社会的な合意形

成局面における調整などの負荷軽減につながる。

組織を超えたナレッジの共有と整備を推進

複数の組織間で頻繁に利用する、同じ定義をもつデータ項目名などについては、語彙体系を開発または運

用管理するコミュニティ側にフィードバックしていくことで、さらに複数組織間でのデータ交換を円滑にで

きる。IMI 共通語彙基盤でいえば、独自に作成した応用語彙をドメイン語彙に、さらにコア語彙として広く認

知・利用される効果も期待できる。

官民データ活用は、社会的損失を回避していく協調的な取組みであり、組織内の取組みよりも、一段次元

の高い視座が求められる。公共機関や地方自治体はもちろん、民間事業者においても、社会貢献が持続的な

成長の要件と認められる中で積極的な取組みを期待したい。

進化し続ける「ことばの基盤」と新しい社会

「1.1 官民連携の情報基盤づくり」で述べた通り、語彙は単なるラベルではなく、データの本質的な意味を

表す概念と、概念間の関係性、付加情報によって記述されるナレッジを伝える。ことばは常に変化を続ける

ため、語彙もまた社会的なルールや文化など人を取り巻く環境の変化に伴い、刻々と変わっていく。したが

って、語彙を体系化する技術論だけではなく、語彙の運用管理や関係者間の調整作業などを行うコミュニテ

51

ィがより重要である。その重要性はすでに前章で取り上げた XBRL において実証されている。「ことばの基盤」

は語彙を利用する人々の公共財であることから、特定の利益に偏重しない組織体が理想的である63。

もとより、持続的なコミュニティであるためには、民主的な合意形成や意思決定を行うための機関設計、

資金の調達や管理、活動成果物を利用するためのシステム環境、広報啓発活動などが必要になる。ここは産

官学民などの垣根を超えた協調領域といえるのではないだろうか。

コミュニティの体制については「3.1 企業開示情報の相互運用基盤」で取り上げた XBRLやデータ取引市場

活性化(DTA)などの事例から学ぶところは多い。いずれにせよ、NIEM は 10 年、XBRL は 20 年、UN/CEFACT64は

30 年以上、データの相互運用性を確保するためにステークホルダーが集い協力しながら、その時々に最適な

ことばの基盤を築き更新し続けている。その進化の担い手は当事者であるデータの作成者や利用者自身だ。

語彙をコミュニケーションや思考の道具として利用する「ひと」である。

利用者の意見を取り入れられる推進体制としての利用者主体のコミュニティを通じて、より使いやすいも

のとしていくことが、社会全体としてみた場合のリソースの最適配分や有効活用につながっていく。それが

新しい社会、Society 5.0の一つのあり方ではないだろうか。

63 コミュニティによる意思決定と運用管理は、公共財産としての「インターネット」や「オープンソースソフトウェア(OSS)」にもみら

れる。インターネットでは、民間非営利法人 ICANNがドメイン名や IPアドレスといったインターネットの識別子の割り振り・割り当

てをグローバルかつ一意に行うシステムの調整、DNS ルートネームサーバ・システムの運用及び展開の調整などインターネット資源

のグローバルな管理を行っている。OSSにおいても、数多くの開発コミュニティが存在し、エンジニアや IT企業などが利用者視点で

より使いソフトウェアの開発を進めている。

64 United Nations Centre for Trade Facilitation and Electronic Business. 国連欧州経済委員会(UNECE)によってホストされる貿

易簡易化と電子ビジネスのための国連センター。電子データ交換標準の UN/EDIFACTや、ebXML（OASISと共同）、UN/CEFACT Modelling

Methodologyなどを提供。

この文書について

このガイドは、官民データ活用社会の実現へ向けたデータの相互運用性向上の取組みについて、意義と実

践手順、実装例を示します。

◼ 表題 データの相互運用性向上のためのガイド(2019 年 12 月ワーキングドラフト)

官民データ活用社会の実現へ向けた取組みの手順と実装例

◼ 状態 改版を前提とした、公開時点のワーキングドラフトです。みなさまのご意見をふ

まえ、3 月に初版として公開する予定です。

◼ 公開日 2019 年 12 月 20 日

◼ 作成者 独立行政法人情報処理推進機構(IPA) (法人番号 5010005007126)

◼ 発行者 独立行政法人情報処理推進機構(IPA) (法人番号 5010005007126)

この文書のご利用にあたって

本資料の著作権は、独立行政法人情報処理推進機構が保有しています。

著作権は独立行政法人情報処理推進機構に帰属します。

本ガイド(2019 年 12 月ワーキングドラフト)は、改版を前提にした検討中の文書です。無断での引用、転載、改変、

複製、販売、出版、翻訳/翻案はご遠慮ください。

本書の内容を適用した結果生じたこと、また適用できなかった結果について、独立行政法人情報処理推進機構は、一

切の責任を負いませんのでご了承ください。

ご意見を募集しています

広くみなさまのご意見を募集しています。以下ご意見投稿のページに進み、ご記入ください。

2020 年 1 月 17 日(金)まで https://oscenq.ipa.go.jp/index.php/754996?lang-ja

*3 月正式版に可能な限り反映します

IMIについてのお問合せ https://imi.go.jp/o783/