「Data,data and data」③

1. いつまで
洗わせるんだよ
＃GT３D

2. デジタルファースト
• 紙からデータへ
ワンス・オンリー
• データ項目を再利用
ワンストップ
• APIによるサービス連携
前提条件
・サービスデザイン思考で考えること
・サービスが見つけられること
・きちんと作られること
行政手続・民間取引ＩＴ化の３原則
基盤
・クラウドの活用
マスターデータ等基本データ導入実践ガイドブック
Webサイト等ドメイン管理ガイドライン
コード導入 実践ガイドブック
クラウドサービス利用方針
API テクニカルガイドブック
API導入実践ガイドブック
行政基本情報データ連携モデル
行政サービス・データ連携モデル
本人確認ガイドライン
文字環境導入実践ガイドブック
標準ガイドライン解説書
標準ガイドライン実践ガイドブック
デジタル・ガバメント推進標準ガイドライン
Webサイトガイドブック
Webサイトガイドライン
サービスデザイン実践ガイドブック（β版）
デジタル時代の本人確認手段
スマートフォンで扱える文字体系
RPAやAIに対応容易なデータ標準
再利用や連携が容易な基本データ群
サービス間連携
をするためのAPI
※推奨データセットや法人関連データ群とも連携を強化
デジタル・ガバメント
押印見直しガイドライン（H9策定済み）
サービス・カタログガイドブック
キャッシュレス決済入門
データ品質ガイドブック 正確性や最新性の評価
金融データの交換
まずはデータをきれいに作る
https://cio.go.jp/guides
＃GT３D

3. データクレンジングツールも便利
• 大量データの中から類似している名前を一括してデータの揺らぎを処理。
いくつかの項
目をまとめて
「大学キャン
パス」等に変
換することが
可能
途中にスペース区切りがある
「早稲田大学 文学部」も一括して処理可能
データ項目が定義されて
いるから処理が可能
＃GT３D

4. エクセルだって頑張れる
https://renkei2.gsi.go.jp/renkei/130326mapsh_gijutu/index.html
０３（３５０１）２９６４ (03)3501-2964
03-3501-2964 (03)3501-2964
０３－３５０１－２９６４ (03)3501-2964
０３（３５０１）２９６４(代表） 03(3501)2964 (代表)
03-3501-2964 代表 03-3501-2964 代表
03-3501-2964 内線0000 03-3501-2964 内線0000
=CONCATENATE("(",SUBSTITUTE(SUBSTITUTE(ASC(A10),")","-"),"(",")"))
=CONCATENATE("(",SUBSTITUTE(ASC(A12),"-",")",1))
=LEFT(ASC(A16),12) =RIGHT(ASC(A16),LEN(ASC(A16))-12)
A B C
＃GT３D

5. もっと本格的なのはここから
＃GT３D

6. ツール紹介
2020-02-21 IMI Webinar
インディゴ株式会社 松澤有三
6

7. Index
7
①日付の正規化
②電話番号の正規化
③法人番号からの属性拡張
④住所からの属性拡張
⑤自由文への産業分類候補の推薦

8. ①日付の正規
化
令和元年12月三十一日
日付文字列
8
{
"@type" : "日付型",
"表記" : "令和元年12月三十一日"
}
共通語彙で構造化したデータ
{
"@type" : "日付型",
"表記" : "令和元年12月三十一日",
"標準型日付" : "2019-12-31"
}
共通語彙を使って構造化＋正規化されたデータ
日付型
モジュー
ル
ポイント
・標準型日付の付与
・例外検出

9. 9
使用方法

10. 10
実行例①

11. 11
実行例②

12. 12
実行例③

13. 13
実行例④

14. 14
エラー例①

15. ②電話番号の正規化
15
{
"@type" : "連絡先型",
"電話番号" :
"０３－５２５３－２１１１（内線番号
３１４２７）"
}
共通語彙で構造化したデータ
{
"@type" : "連絡先型",
"電話番号" : "(03)5253-2111",
"内線番号" : "内線番号31427"
}
共通語彙を使って構造化＋正規化されたデータ
０３－５２５３－２１１１（内線番号３
１４２７）電話番号文字列
連絡先型
モジュー
ル
ポイント
・電話番号表記のカッコ／区切りを正規化
・電話番号の付記を内線番号として分離
・例外検出

16. 16
使用方法

17. 17
実行例①

18. 18
実行例②

19. 19
実行例③

20. 20
実行例④

21. 21
特殊番号

22. 22
不正な市内局番

23. 23
存在しない市外局番

24. 24
市内通話用番号

25. 25

26. ③法人番号からの属性拡張
26
共通語彙で構造化したデータ
共通語彙を使って構造化＋正規化されたデータ
4000012090001
法人番号(13桁の数字)
法人型
モジュー
ル
ポイント
・法人番号をもとに表記や住所の属性を拡張
・例外検出
{
"@type" : "法人型",
"ID" : {
"識別値" : "4000012090001",
"ID体系" : {...}
}
}
{
"@type" : "法人型 "
"ID" : {...},
"組織種別" : {...},
"表記" : "経済産業省",
"名称" : {...},
"住所" : [{...},{...}]
}

27. 27
使用方法

28. 28
成功例①

29. 29
成功例②閉鎖

30. 30
成功例③合併

31. 31
桁数の過不足

32. 32
チェックデジットエラー

33. 33
存在しない法人番号

34. 34

35. ④住所からの属性拡張
35
共通語彙で構造化したデータ
共通語彙を使って構造化＋正規化されたデータ
霞が関2-1-10
住所文字列
住所型
モジュー
ル
ポイント
・住所表記からの属性抽出
・省略された都道府県・市区町村名の補完
・地方公共団体コードの付与
・緯度経度（大字・丁目レベル）の付与
・例外検出
{
"@type": "場所型",
"住所" : {
"@type": "住所型",
"表記" : "霞が関2-1-10"
}
}
{
"@type": "場所型",
"住所": {
"@type": "住所型",
"表記": "霞が関2-1-10",
"都道府県": "東京都",
"市区町村": "千代田区",
"町名": "霞が関",
"丁目": "2",
"番地": "1",
"号": "10",
"都道府県コード": "...",
"市区町村コード": "... "
},
"地理座標": {
"@type": "座標型",
"緯度": "35.675551",
"経度": "139.750413"
}
}

36. 36
使用方法

37. 37
成功例①

38. 38
成功例②

39. 39
消滅自治体

40. 40
旧住所

41. 41
あいまいな地名

42. 42
存在しない地名

43. 43

44. 44

45. 45

46. 産業分類
推薦
インターネット
[
{
"value": {
"@type": "コード型",
"識別値": "G",
"表記": "情報通信業",
"説明": "..."
},
"score": 16
},
{
"value": {
"@type": "コード型",
"識別値": "E",
"表記": "製造業",
"説明": "..."
},
"score": 14
},...
]
⑤自由文からの産業分類推薦
任意のテキスト
推薦結果の産業分類 46
ポイント
・入力されたテキストから適当な産業分類を推薦

47. 47
使用方法

48. 48
実行例

49. 49

50. コマンドライ
ン
WebAPI
ライブラリ
Node.js
ライブラリ
Browser
日付 〇 〇 〇 〇
連絡先 〇 〇 〇 〇
法人番号 〇 〇 〇 要外部データ
住所 〇 〇 〇 要外部データ
産業分類 〇 〇 〇 〇
提供形態
50

51. WebAPI の利用例
51
①Web API サーバを実行
②Web ブラウザから Web API を利用

52. データ品質の評価モデル
頃末 和義

53. データは品質が大事
データ活用を推進するためには、データの品質が重要になります。
副次的な利用では、データの品質が伝播します。外部データに品質の悪いものを利用すると
提供するデータの品質が悪くなってしまいます。
品質の悪いデータ 品質の悪いデータ
品質の悪いデータ

54. データの品質とは？
「データの品質」とは、単に間違いの有無ではなく、メンテナンス状況、信頼性、公開までの時
間、データを処理するシステムの品質などデータそのものの品質だけでも様々な面から考える
必要があります。
また、データの特性（制度や更新間隔など）はデータの目的によっても変わります。そのため、
データの特性は提供者と利用者の間で共有されていることも重要です。
さらに、データそのものの品質を持続的に維持していくためには、収集から提供・削除に至る
プロセスの構築や計画・監査などの管理体制の整備などが必要になります。
品質が良い
データ
管理体制
プロセス

55. 評価モデル
海外連携を考慮し、国際標準をベースとして構成されています。
データの提供者と利用者の間でデータ品質の基準が共有されていることが大事です。
文字の種類が多く、一つのことがらでも多くの書き換えができてしまう、文字数が多いなど日
本語固有の問題も考慮してあります。
個々の評価項目に対応してできる限り具体的な評価基準を決める
外部データを取り込む際の品質評価や自身がデータを提供する際のチェックリストとして活用
できます。
評価モデル自体は、合否判定をするものではありません。
詳しくは、「データ品質の評価モデルガイドブック（仮）」（来年度以降公開予定）を参照してくだ
さい。
また、簡単な評価ツールを提供します。

56. 評価モデル
ISO/IEC 25024
プロセスの評価
ISO/IEC 25012
データ品質の評価
ISO/TS 8000
管理体制の評価
データの収集、外部データの利用、データ統合、
提供、削除の一連のプロセスの観点から評価
正確性、最新性、信頼性など１５項目によるデー
タそのものの品質の評価
品質計画の策定など、管理体制の観点から評価
これら３つ観点は、それぞれ独立し
たものではなく、最終的なデータ品質
を維持するために深く関連しています
ので、３つの観点をバランスよく検討
することが必要です。
プロセス、データ、管理体制の３つの観点からデータ品質を
評価します。
評価モデルは、それぞれの観点について、複数の評価項目
を設けています。

57. データ品質の評価モデルガイドブック
プロセス、データ品質、管理体制の３つの観点からデータ品質の評価モデルを解説するガイド
ブックです。
上記の３つの観点について、複数の評価項目を設けています。
各評価項目について、具体的な評価基準を提示し、必要に応じて例を含めて解説します。

58. データ品質評価ツール
サービスで利用するデータや外部データを取り込む際の品質評価に利用します。
また、データ作成の際のチェックリストに使用することもできます。
結果はグラフで表示されるので、品質の傾向が一目で分かります。

59. 評価基準
アドホック
 常時行っているわけではない
 利用者が修復できない問題がある
 行っていない
部分対応
 部分的であるが、常時行っている
 利用者が修復できる程度の問題がある
 行っているが十分ではない
基本
 基本的な品質管理が行われている
 エラーは許容範囲である
サイテナブル
 持続的に品質管理を行うよう、マニュア
ルやシステムが整備されている。
全てにおいてガイドブックを参照しなくても選択できるように、日本語固有な事項や問題とな
ることが多い項目を中心とした評価モデルの評価基準の抜粋が記載されています

60. 評価
評価は評価基準を参照し４段階の中から選択します。
理由の欄には、選択の理由は具体的な問題点などを記入します。

61. 評価結果
評価結果は項目ごとの棒グラフとグループごとのレーダーグラフで表示されます。
視覚的に傾向が分かります。

62. ありがとうございました。