総務省におけるオープンデータに関する技術の検討状況について 第1回データＷＧ資料 資料８ 総務省におけるオープンデータに関する技術の検討状況について　 （情報流通連携基盤の構築、オープンデータ流通推進コンソーシアム等） 平成２４年１２月２６日 総務省

Ⅰ オープンデータ戦略に係る総務省の取組（情報流通連携基盤の構築） ①背景 Ⅰ　オープンデータ戦略に係る総務省の取組（情報流通連携基盤の構築）　①背景 1 ■　従前、ＩＣＴの利活用は、個別分野ごとの「縦軸」の情報化の促進が中心だったが、東日本大震災では情報の横の連携の重要性が顕在化。 ■　このためには、急速に進展してきたブロードバンド環境を活かし、組織や業界内で利用されているデータを社会でオープンに利用できる環境（オープンデータ流通環境）の整備が必要。 ■　これにより、①様々な主体が自由にデータを加工したり組み合わせたりすることによる新事業・サービスの創出、②国民、産業界にとって有益な情報の入手の容易化、等が図られる。 ■　電子行政オープンデータ戦略（平成24年7月4日ＩＴ戦略本部決定）においては、「公共データの活用を促進するための取組に速やかに着手」することが重要とされている。 今後のＩＣＴ総合戦略 「横軸」の 取組強化 ＩＣＴ利活用の推進 研究開発等の推進 （個別分野） 行政 医療 教育 農業 ・・・ 情報流通連携基盤の構築 データ様式やＡＰＩの共通化等を通じた 「オープンデータ流通環境」の整備等 ＩＣＴ利用環境の整備 ＩＣＴ基盤（インフラ）の構築

Ⅰ オープンデータ戦略に係る総務省の取組（情報流通連携基盤の構築） ②具体的施策 Ⅰ　オープンデータ戦略に係る総務省の取組（情報流通連携基盤の構築）　②具体的施策 2017/3/6 2 ■　分野を超えたデータの流通・連携・利活用を効果的に行うために必要となる、①情報流通連携基盤共通ＡＰＩ※（標準データ規格（データモデル、データフォーマット、共通ボキャブラリ）及び標準ＡＰＩ規格）の確立・国際標準化、②データの２次利用に関するルール（データガバナンス方式）の策定、③オープンデータ化のメリットの可視化等のための実証事業を推進。 ※共通ＡＰＩ（Application Programming Interface）：情報・データの相互運用性を確保するための共通のデータ形式や通信規約 公共交通関連情報　 ボーリング（地盤）データ 公共交通情報サービス（スマホアプリ） 【現状】 【オープンデータ化】 共通API ・精密ハザードマップ ・３D地下構造図 ・災害予測シミュレーション 等の新サービス 国のボーリングデータ 運行情報 共通API 気象データ （雨、温度等） ・複数の公共交通機関の運行情報をリアルタイムに提供（→遅延情報等も勘案した最適ルート、終電乗り継ぎ案内等） ・各車両毎の温度や混雑状況、バリアフリー状況等を一覧的に提供 自治体のボーリングデータ 車両や駅の混雑データ 災害関連情報　 青果物・水産物の安全安心情報 ＜避難準備の促進、避難勧告の判断＞ 農薬、肥料、放射線量等 生産者 農場 　気象情報 　震度・震源情報 　津波警報・注意報 　大雨警報・注意報 　指定河川洪水予報 　土砂災害警戒情報 　大雪警報・注意報　等 栽培情報　　 生産地 気象庁 共通API 家屋被害　12件 共通API 品目 品質情報　　 取引時刻 避難経路 流通場所 流通業者 code 流通情報 業者名 現在地 避難所 code 購入場所 　ハザードマップ 　浸水エリア 　氾濫危険箇所 　地すべり危険個所 　避難所情報　等 ＜雪害時の行動判断＞ 購入日時 到着予定時刻 ○時△分頃 消費者 自治体 評価情報 トレーサビリティサービス 　除雪関連データ 　除雪計画道路 　除雪済経路 除雪済み道路 平成24年度は、公共交通、地盤、災害、青果物、水産物の各分野のデータについて、実証事業を行う。

Ⅰ オープンデータ戦略に係る総務省の取組 ③推進体制、展開方策 Ⅰ　オープンデータ戦略に係る総務省の取組　③推進体制、展開方策 2017/3/6 3 ■　「電子行政オープンデータ戦略」を推進している政府のIT戦略本部や「オープンデータ流通推進コンソーシアム」等と連携して、オープンデータ流通環境の普及・展開を目指す。 ■　ITU-T（注1）やW3C（注2）へ標準化提案を行い、平成27年度までに国際標準化を目指す。 （注1）International Telecommunication Union Telecommunication Standardization Sectorの略。国際電気通信連合において、通信分野の標準策定を担当する部門。 　　　　　　　　　　　　　　　　　　　　　　（注2）World Wide Web Consortiumの略。World Wide Webで使用される各種技術の標準化を推進する非営利団体。 １．国内の推進体制 IT戦略本部 （公共データ活用のための 環境整備への貢献） 「電子行政オープンデータ戦略」（平成24年７月4日決定） 　⇒　「電子行政オープンデータ実務者会議」 協力 データ形式や必要なルール等についての成果 総務省 オープンデータ流通推進 コンソーシアム ・・・ 連携 （関係府省） ２．国際標準化に向けたスケジュール（想定） 実証プロジェクト実施期間（３ヵ年計画） 実証プロジェクト終了後 平成24年度 平成25年度 平成26年度 平成27年度 平成28年度 共通APIの策定 国際規格の ドラフト作成 国際規格の提案、議論、承認

Ⅱ オープンデータ流通推進コンソーシアム ①概要 Ⅱ　オープンデータ流通推進コンソーシアム　①概要 2017/3/6 4 ■　広く産官民が連携して、オープンデータ流通環境の実現に向けた基盤を整備するため、本年７月２７日に、「オープンデータ流通推進コンソーシアム」が設立。 ■　広くオープンデータの意義や可能性を社会にPRすることを目的として、気象データを対象にしたハッカソン「気象データハッカソン」を１２月１日に開催。 ■　また、オープンデータの意義や可能性について広く国民に周知し、オープンデータに係る取組の普及・啓発を図るため、オープンデータ流通推進コンソーシアムと総務省の共同で「オープンデータシンポジウム」を１２月１０日に開催。 ○オブザーバー 総務省、内閣官房、経済産業省、農林水産省、国土交通省、気象庁、国土地理院、日本経済団体連合会、ASP・SaaS・クラウドコンソーシアム ○会員（６１（12/26時点）） 企業・団体、自治体、有識者 オープンデータ流通推進コンソーシアム 会長：小宮山宏・三菱総合研究所理事長 顧問：坂村健・東京大学大学院情報学環教授 徳田英幸・慶應義塾大学大学院政策・メディア研究科委員長 村井純・慶應義塾大学環境情報学部長 渡辺捷昭・日本経済団体連合会副会長・情報通信委員長 技術委員会 データガバナンス委員会 利活用・普及委員会 ○オープンデータ推進に必要な技術標準の在り方等の検討 ・データ流通・連携のための共通APIの検討 ・国際標準化提案（ＩＴＵ－Ｔ等）の検討 →10/24に第1回開催。本年度は計４回開催予定。 ○オープンデータ推進に必要なライセンスの在り方等の検討 ・ネットワーク上におけるデータの2次利用に関するルール（著作権、プライバシー等の配慮事項を含む。） →9/26に第1回開催。11/14に第２回会合開催。 　本年度は計４回開催予定。 ○オープンデータ推進に関する情報発信・情報共有 ・ポータルサイトの開設　等 ○新たなサービス等の検討 ・データ連係によるサービスコンテストの開催等 →9/28に第1回開催。11/7に第２回開催。 　本年度は計４回開催予定。 主　査：中村 伊知哉 　　　　　（慶應義塾大学メディアデザイン研究科教授） 副主査：村上 文洋 　　　　　（三菱総合研究所地域経営研究本部副本部長） 委　員：石川 雄章（東京大学大学院情報学環特任教授） 大向 一輝（国立情報学研究所准教授） 川島 宏一（佐賀県特別顧問） 小林 巌生（有限会社スコレックス） 庄司 昌彦（国際大学GLOCOM主任研究員・講師） 野原 佐和子（イプシ・マーケティング研究所代表取締役社長） 福野 泰介（株式会社jig.jp代表取締役社長） 主　査：越塚 登 （東京大学大学院情報学環教授） 副主査：武田 英明 （国立情報学研究所教授） 委　員：中尾 彰宏（東京大学大学院情報学環准教授） 平本 健二（経済産業省ＣＩＯ補佐官） 深見 嘉明（慶應大学大学院政策・メディア研究科特任助教） 主　査：井上 由里子 （一橋大学大学院国際企業戦略研究科教授） 副主査：野口 祐子 （森・濱田松本法律事務所） 委　員：沢田 登志子 （一般社団法人ECﾈｯﾄﾜｰｸ理事） 友岡 史仁（日本大学法学部准教授） 森 亮二（英知法律事務所）

Ⅱ オープンデータ流通推進コンソーシアム ②技術委員会 Ⅱ　オープンデータ流通推進コンソーシアム　②技術委員会 5 ミッション １．オープンデータを流通させるための標準技術仕様のあり方の検討 　○　静的なオープンデータ　　（例：各種統計データ等） 　　　　データの全部取得が容易で、ＡＰＩへの要求がシンプル 　○　動的なオープンデータ、ビッグデータ　　（例：センサーデータ、メーターデータ等） 　　　　必要なデータを取り出すＡＰＩが必要 　　 　⇒　実証実験で使用する情報流通連携基盤共通ＡＰＩ（ドラフト版）をたたき台として検討 　　　　　　(情報流通連携基盤共通ＡＰＩ) 　　　　　・標準データ規格：　データモデル、データ表現形式、共通ボキャブラリ 　　　　　　・標準ＡＰＩ規格：　　オープンデータを取得・交換するための標準的な手法に関する規格 ２．国際標準化のための作業の検討 　○　ITU-T、W3C等 実施内容（３ヵ年計画） １年目 ２年目 ３年目 検討の 基本方針 ・標準仕様の検討 ・国際標準化活動の動向調査 ・標準仕様の精査 ・国際標準化活動に関する検討 ・国際標準化提案活動 主な 検討事項 (1) 素案をベースとした標準仕様の検討（標準化すべき項目の整理） (2) 国際標準化の動向調査 (3) 国際標準化活動の体制検討 (1) 標準仕様の精査 　・データガバナンス委員会や利活用・普及委員会からの技術要求に対応 　・具体的なオープンデータを素材として仕様をブラッシュアップ (2) 国際標準仕様に付随する技術資料やツールに関する検討（利用ガイド・運用体制等） (3) 国際標準化活動に関する検討（仲間作り、素案の作成） (1) ２年目に引き続き、標準仕様のブラッシュアップ (2) 標準仕様に付随する技術資料やツールの精査（検討事項に基づく運用を含む） (3)　国際標準化活動に関する進展報告と意見交換

【参考】共通ＡＰＩ（情報流通連携基盤の外部仕様）について 6 共通APIは、（１）標準データ規格と（２）標準API規格から構成される。 【RDFモデルによる人口統計データの表現例】 （下線部は共通ボキャブラリ） （１）標準データ規格 主語 urn:ucode:_00001C00…00000001 ■標準データ規格とは？ ○政府・民間のオープンデータを、業界をまたいで流通・連携させるためのデータモデル、データ表現形式、 　　及びボキャブラリに関する共通規格 ■標準データ規格の規定範囲 　１．データモデル 　　○データの構造を規定するモデル・枠組。 　　○データをシンプルかつ拡張性をもって記述するために、RDF(*1)モデルを利用。　 　　　⇒・RDFモデルは主語・述語・目的語の3つ組みからなるシンプルなモデル｡ 　　　　 ・RDFモデルで利用できる、既存の識別子体系（ISBN、doi(*2)など）を、主語の識別子として利用。 　　　　 ・このような識別子体系が定義されていない実物・施設・組織・場所・データ等に対しては、 　　　　　ucode(*3)を付与して識別｡　　　 　２．データ表現形式 　　○データを表現する、機械可読型のフォーマット（XML形式）。 　　　⇒機械可読型の統一フォーマットを利用することにより、データの二次利用を容易化｡ 　３．共通ボキャブラリ 　　○利活用分野によらず共通的に利用される、意味を表すメタデータ　⇒同じ意味であるデータの表現を統一 　　（定義方針） 　　　・既存のボキャブラリセットで必要なものは取り入れる（OWL、ダブリンコア、DCMI、FoaF等） 　　　・その他のボキャブラリ（NIEM、ISA、SKOS等）との相互運用性を確保 　　　・既存のボキャブラリセットにないものや使い勝手のよくないものは新たに定義 　　　・ボキャブラリは必要に応じて追加登録可能とする（同義語の出現を許容） 目的語 rdf:type ex:PopulationStatistics 述語 (人口統計) dc:date 1985-04-01 rdf:value 52345 XML形式で表現 <?xml version=“1.0”?> <rdf:RDF xmlns:rdf=“http://www.w3.org/1999/02/22-rdf-syntax-ns#” xmlns:dc=“http://purl.org/dc/elements/1.1/” xmljs:ex=“http://www.exapmle.org/” > <rdf:description rdf:about=“urn:ucode:_00001C00…00000001”> <rdf:type rdf:resource=“http://www.exapmle.org/PopulationStatics” /> <dc:date>1985-04-01</dc:date> <rdf:value>52345</rdf:value> </rdf:description> </rdf:RDF> データ表現形式 主語 目的語 述語 (*1) RDF(Resource Description Framework): 主語・述語・目的語の3つ組で物事を表現するモデル。 　　　Web技術の標準化団体World Wide Web Consortium (W3C) が標準化。 (*2) doi (digital object identifier):インターネット上のドキュメントに恒久的に与えられる識別子。 (*3) ucode: ものや場所、データ等あらゆるものを識別できる番号体系｡ 　　　国連の標準化組織ITU-Tが規定する勧告H.642.1に準拠｡ 【標準データ規格なし】 【標準データ規格あり】 公開主体A 公開主体B 公開主体C 公開主体A 公開主体B 公開主体C DB DB DB DB DB DB 人口統計 データ要求 標準データ規格 1985年,1234人 1986年,1385人 … 人口統計 データ要求 人口統計 データ要求 … <dc:date>1985-04-01</dc:date> <rdf:value>12345</rdf:value> 標準データ規格 CSV 人口統計 データ要求 人口統計 データ要求 … <dc:date>1985-04-01</dc:date> <rdf:value>10425</rdf:value> ○○市人口統計 … 昭和60年,10.4千人 昭和61年,12.3千人 … 標準データ規格 53854 … <dc:date>1985-04-01</dc:date> <rdf:value>52345</rdf:value> 人口統計 データ要求 52345 CSV 昭和60 昭和61 PDF 各組織から得られるデータ形式がばらばらで、加工しづらい 機械可読なデータ形式に統一することにより、二次利用（マッシュアップ）が容易になる

【標準API規格なし】 【標準API規格あり】 7 （２）標準ＡＰＩ規格 DB DB DB DB DB DB ■標準API規格とは？ 　○オープンデータを業界をまたいで流通・連携させるために、データベースに格納されたオープンデータに対する検索・取得・更新等の操作を共通化するための標準技術規格 　　　（特長） データ提供元によらず、共通の問い合わせ形式でアクセス可能 - 共通の問い合わせ形式は、今日のWebサービスで広く使われているHTTP(*4)形式。なかでもHTTP/REST(*5)形式が中心。 ■標準API規格の規定範囲（提供機能） 　１．オープンデータの格納先を検索／登録するAPI 　　(1) Identification Resolution Command 　　　「識別子」と「それについて記述したオープンデータの格納先情報」との対応付けを管理。 　２．オープンデータに対する検索・取得・操作を行うAPI 　　(2) Raw Data Management Command 　　　　SPARQL (*6)に基づく複雑な検索と、データの流し込み／ダンプ機能。 　　(3) Traceability/RealtimeData Management Command 　　　　トレーサビリティに代表されるイベントを管理する機能｡（トレースフォワード・トレースバックを含む） 　　(4) Geographical Data Management Command 　　　　GIS等地理情報処理を必要とするデータ検索・取得・操作機能。 　　(5) Security Management Command 　　　　ユーザ・グループと、オープンデータのアクセスルールを管理する機能｡ 　　(6) Trigger Management Command 　　　　オープンデータの登録・更新をトリガとしてデータ利用者のシステムに 　　　　コールバックする（Notification）仕組み｡ (7) Vocabulary Management Command 　　ボキャブラリの管理機能｡ 　　LOV (Linked-open Vocabulary) やMetaBridgeとの相互運用性を考慮。 (8) Data Conversion Command 　　簡易的なRESTベースAPIでRDFデータを検索・取得・操作する機能｡ 　　センサが取得したデータを登録するような場面での利用を想定｡ (*4) HTTP (HyperText Transfer Protocol): Webブラウザ（またはWebアプリケーション）とWebサーバの間で、 コンテンツの送受信に用いられる通信規約。 (*5) HTTP/REST: データに対する取得・作成・更新・削除の各操作を、HTTPプロトコルが定めるコマンドである GET, POST, PUT, DELETEを用いて行う問い合わせ手法。 TwitterやFacebookなど、今日のWebサービスで広く利用されている。 (*6) SPARQL: RDFで記述されたデータを検索・操作する言語。W3Cにより標準化されている。 【標準API規格なし】 【標準API規格あり】 公開主体X 公開主体Y 公開主体Z 公開主体X 公開主体Y 公開主体Z DB DB DB DB 標準APIやDBの実装方法は、標準API規格の範囲外。 DB DB 独自API 独自API 独自API 標準API 標準API 独自API Y用の 問い合わせ 標準API X用の 問い合わせ Z用の 問い合わせ 既存の独自APIに標準 APIを被せてもよい。 また、サービスが独自に APIを提供することを妨げない。 ・サービスごとにオープンデータの取得方法を調査し、アクセスする必要あり ・データの取得先もサービスごとに違う トータルコストが上昇 ・データ提供元によらず共通の問い合わせ形式でアクセス可能 ・データの識別子から、そのデータの取得先を問い合わせられる