オープンデータ・バイ・デザイン

01｜オープンデータ・バイ・デザインとは

オープンデータ・バイ・デザインは、公開してよい公共データを二次利用しやすい形で提供できるよう、行政手続や情報システムの企画・設計段階から必要な措置を講じる考え方です。公開ボタンを最後に追加するだけでは、データの形式、権利、機密情報、更新責任といった根本問題を解決できません。

重要なのは「行政が保有するあらゆる情報を無条件に公開する」という意味ではないこと。対象データの範囲と公開の可否を分け、保護すべき情報を守りながら公開可能な部分の利活用を進めます。

02｜後から公開しようとすると何が起きるか

たとえば道路工事情報を各支所が自由入力のExcelで管理すると、日付形式が統一されず、住所は表記揺れを起こし、そもそも公開担当者も定まらない。毎月の更新を自動化できなければ、公開データが古いままになる問題も生まれます。

03｜オープンデータを成立させる3条件

デジタル庁の「オープンデータ基本指針」が示す定義は、次の3つをすべて満たすことです。インターネットで見られるだけでは不十分です。

たとえばPDFをWebに掲載しても、再配布が禁止されていたり、データとして抽出しづらかったりすれば、オープンデータの条件を十分に満たせません。具体的な利用可否は公開元の利用規約を確認します。

04｜なぜ営利目的の利用も認めるのか

避難所の位置情報を使った有料の防災アプリや、公共交通の運行データを組み合わせた経路案内サービスは、民間が公共データを付加価値へ変える例です。営利利用を一律禁止すれば、継続的なサービスの開発や投資を妨げます。

「誰でも自由に何をしてよい」という意味ではありません。出典の表示、免責、第三者の権利など、個々のデータに適用される利用条件は必ず確認します。

05｜機械判読とは：PDF・CSV・JSONの違い

機械判読とは、人が見るだけではなく、プログラムでデータを加工・集計・結合できることです。文字列としてコピーできることと、意味のある表として再利用できることは同じではありません。

06｜公開用データは業務データと分けて設計する

例では担当職員の個人電話番号を内部管理に残し、公開データには施設の所在地と公開可能な連絡先だけを含めます。公開用ビューを別に設け、公開前審査・権限分離・変更履歴を組み込めば、誤公開の可能性を減らせます。

匿名化しても、他の公開情報と突き合わせて個人が識別されることがあります。集計値でも少人数の属性を示すデータは再識別リスクを点検しなければなりません。

07｜データのライフサイクルと責任分担

データの生成、品質確認、公開判断、公開、更新、訂正、廃止を一連の業務にします。公開担当者だけでなく、元データを管理する業務部門、セキュリティ担当、法務、利用者からの問い合わせを受ける窓口が必要です。

08｜ライセンスと利用規約はデータの一部

「ダウンロードできます」だけでは利用条件は不明です。商用利用、改変、再配布、出典表示、免責、第三者権利の扱いを利用者が理解できるようにします。

国内の公的機関では、デジタル庁が紹介する公共データ利用規約（第1.0版）などが参照されます。以前の政府標準利用規約第2.0版やCC BY 4.0等を利用している場合もあり、具体的なデータセットの規約が優先して確認対象となります。

09｜公開してはいけないデータの扱い

オープンデータ推進は個人情報や営業秘密の全面公開を求めません。氏名と住所が結び付いた申請記録、個人の健康状態、秘匿が必要な施設情報、契約上公表できない第三者情報は慎重な判断が必要です。

10｜メタデータとデータカタログ

利用者が「どの部署の」「いつ時点の」「何を表す」データなのかを判断できなければ再利用は進みません。名称、説明、作成部署、更新日、更新頻度、対象期間、地理的範囲、形式、ライセンス、問い合わせ先をメタデータとして整備します。

データカタログは公開データを検索しやすくする入口です。単にファイルを置くより、再利用したい人が発見できる状態を重視します。

11｜品質管理：古いデータは誤判断を生む

避難所が閉鎖されたのにデータが更新されなければ、地図サービスが誤った案内をするかもしれません。完全性・正確性・一貫性・適時性・重複・有効性などの観点で確認し、欠損値や公開停止の理由も示します。

更新頻度は「毎日でなければならない」わけではありません。データの性質に応じて決め、実際の更新状況と一致させることが重要です。

12｜APIで提供する場合の追加設計

頻繁に変わる情報は、CSVの定期更新だけでなくAPIによる取得も選択肢になります。APIの仕様、ページング、応答形式、利用上限、版管理、エラー時の返答、廃止予告などを定め、利用者が安定して連携できるようにします。

一方、APIしか提供せず大量データの一括取得が難しければ分析には不便です。用途に応じてダウンロード形式とAPIを併用します。

13｜実例：自治体の避難所データ

架空の市役所が新しい施設管理システムを導入するとします。初期設計で施設ID、名称、住所、緯度経度、バリアフリー設備、更新日を定義し、公開不可の項目を分離します。定期更新でCSVを自動生成し、担当課が差分を点検してから公開する流れを整えます。

市民は最新情報を検索でき、民間企業は防災アプリに取り込めます。官民双方が同じ基礎情報を使えることに価値があります。なお避難所の収容可能人数や開設状況など、刻々と変わる項目は静的な施設一覧と更新頻度を分けて設計する方が適切です。

14｜企業での実例：公共データを使ったSaaS

地図分析SaaSを運営するスタートアップが、施設・人口・交通の公開データを組み合わせる場合を考えます。データ形式だけではなく、ライセンス、再配布可否、出典表示、更新履歴、利用規約の変更を記録します。複数自治体で施設コードが異なるときは、元データを保持したまま自社の共通スキーマにマッピングします。

オープンデータの活用と、企業が保有する顧客データの一般公開は別問題です。自社の顧客情報を勝手に公開してよいことにはなりません。

15｜混同しやすい関連概念

16｜設計レビューで使える確認事項

サービス企画時の設計レビューでは、①公開対象と対象外、②利用者ニーズ、③データ形式と項目定義、④二次利用ルール、⑤個人情報や第三者権利、⑥更新と品質、⑦担当者と問い合わせ窓口の7点を確認します。

大切なのは「公開の範囲を広げること」自体を目的にしないことです。安全性・利用可能性・継続性を一体で設計し、必要なら限定公開も選べるようにします。

17｜操作ラボ：公開可否と再利用しやすさを診断

架空の自治体データについて公開可否、形式、利用規約、更新方法を選択すると、公開前に必要な確認事項を表示します。実際の法的な公開判定に代わるものではなく、設計上のチェックを学ぶ教材です。

18｜まとめ：公開できる形で生まれるデータを設計する

公開の可否は厳格に判断しつつ、公開できる情報は、営利・非営利を問わず二次利用できる条件、機械判読可能な形式、無償利用という3条件を意識します。オープンデータ・バイ・デザインの核心は、後工程で頑張って公開するのではなく、企画・設計からデータの構造と公開運用を組み込むことです。

設計時には、利用者の使いやすさに加えて、プライバシー、法令、更新責任、品質まで含めて考えます。これが公共データを一時的なファイルから、社会で再利用される基盤へ変える第一歩です。