公園オープンデータの可能性と限界——磐田市「都市公園一覧」を事例に

1. はじめに——問題の所在

磐田市は、市が管理する都市公園の一覧をオープンデータとして公開している。「都市公園一覧」と題されたこの表は94行からなり、CC BY 3.0（出典を示せば誰でも自由に使えるライセンス）で提供されている。当サイト（ATAWI PARK）は、この94行に市の施設ガイドにだけ載っている6園を加えて100園のデータベースを組み立て、0〜7歳の子を連れる親の目線で公園を調べられるようにすることを目指している。本稿はこの一枚の表を、情報学の対象として正面から読む試みである。

情報学とは、ここでは、データがどのように表現され、伝わり、意味を持ち、再利用されるかを扱う学問領域を指す。図書館情報学の資料組織論、計算機科学のデータベース理論、通信理論、そして近年のオープンデータ論やデータ品質論を含む広い呼び名として用いる。情報学は公園そのものを研究するのではない。公園について「何が、どのような形で、記録されているか」を研究する。滑り台やベンチや木陰ではなく、それらを表す文字列と数値と空欄が、本稿の対象である。

なぜそれが子育て世代や行政や地域の関係者にとって意味を持つのか。理由は単純で、私たちが公園について「知っている」ことの多くは、実は誰かが作った表を通して知っていることだからである。市のサイトの一覧、地図アプリの検索結果、当サイトの公園ページ——いずれも元をたどれば、行政の台帳やオープンデータや職員が書いた説明文という「記録」に行き着く。記録がどのように作られ、何を含み、何を含まないかを知らなければ、私たちはその記録の限界をそのまま自分の知識の限界として引き受けてしまう。

1.1 本稿の問い

本稿の問いは三つある。第一に、オープンデータとは何であり、何を約束する理念なのか。ライセンス・機械可読・5つ星といった言葉は、公園の表に当てはめたとき何を意味するのか。第二に、磐田市の「都市公園一覧」は、その理念に照らしてどこまでを満たし、項目としては何を持ち、何を欠いているのか。空欄は「無い」ことを意味するのか、それとも「書かれていない」ことを意味するのか。表記のゆれ、座標、更新の頻度は、データを使う側にどのような作業を強いるのか。第三に、そのようなオープンデータを一次ソースとして受け取ったとき、当サイトのように「その上に情報を重ねる」側は、どのような設計をとるべきなのか。

1.2 方法と資料

方法は三つの作業からなる。一つは文献整理であり、情報学とオープンデータ論の基本概念を、著者と年代が確実な古典と公的資料に限って整理する。二つめは概念分析であり、欠損値・識別子・名寄せ・鮮度といった概念を公園データに適用して、何が起きるかを検討する。三つめは事例参照であり、磐田市のオープンデータの項目構造と、当サイトがそれを受け取って構築した公園データベースの設計を、公開されている範囲で参照する。磐田市固有の数値（園数・種別・面積・地区・園名）は、当サイトが集計したファクトシートの範囲に限る。

あらかじめ断っておくべきことがある。当サイトの現地踏査はまだ始まっていない。したがって本稿は「データにはこう書いてあるが現地はこうだった」という比較を提示することができない。本稿にできるのは、データの側を読み尽くし、現地に行けば何が確かめられるはずかを列挙することまでである。この限界は本稿の弱点であると同時に、情報学の論考としては誠実な立ち位置でもある。データを読むとはまさに、現地を見ないで何が言えるかを見極める作業だからである。

1.3 構成

第2節で情報学とオープンデータ論の基礎概念と日本の政策史を整理する。第3節で「都市公園一覧」の項目を一つずつ読み、第4節で空欄と欠損値の意味を、第5節で表記ゆれと識別子と座標、すなわち突合の問題を、第6節で更新頻度と現地との乖離を検討する。第7節で当サイトのデータ設計を、一次ソースの一本化という観点から検討し、反論にも答える。第8節で磐田市の公園について具体的な示唆を述べ、第9節で結論と今後の課題をまとめる。

2. 先行研究と概念の整理

2.1 データ・情報・知識——三つの層

情報学の入門でしばしば引かれるのが、経営科学者ラッセル・アコフが1989年の論文「From Data to Wisdom」で示した、データ・情報・知識・知恵の階層である。データは記号の並びであり、それが「誰の・何の」という文脈を得て情報になり、情報が経験と結びついて知識になる、という整理である。公園の表でいえば、「458」という数値はデータであり、「只来下公園の面積は458平方メートルである」は情報であり、「その広さなら3歳児と親が目の届く範囲で遊べる」は（現地で確かめられれば）知識になる。オープンデータが提供するのは、この階層の最下層である。

この整理を支える古典が二つある。一つはクロード・シャノンの1948年の論文「通信の数学的理論」であり、情報を「選択肢の中から一つが選ばれたときに減る不確実さ」として量的に定義した。もう一つは人類学者グレゴリー・ベイトソンが1972年の『精神の生態学』で与えた「情報とは、差異を生む差異である」という定義である。二つを重ねると、表の一つの欄が情報を持つのは、その欄が別の値でありえたときだけだ、ということになる。すべての園が「有」なら、その列は何も伝えない。逆に「有」と空欄が混ざっている列は、何かを伝えている——ただしその「何か」が「無」なのか「未記入」なのかは、別の問題である（第4節）。

2.2 関係モデルと表という形式

私たちが「一覧」と呼ぶ縦横の表は、計算機科学ではエドガー・コッドが1970年に提案した関係モデルに由来する形式である。コッドは、データを「行（レコード）と列（属性）からなる表」として表し、表と表を共通の値で結びつけるという考え方を示した。この考え方は、のちのデータベース設計の基礎となった。関係モデルの要点は二つある。一つは、各行を一意に識別する「鍵」があること。もう一つは、表の中の値が「原子的」であること、つまり一つの欄には一つの意味の値だけを入れることである。公園の表でいえば、94行それぞれを見分ける番号があり、「トイレ」の欄には有無だけが入る、という状態が理想となる。コッド自身が晩年まで論じ続けた「欠損値をどう扱うか」という問題も、公園データを読むときにそのまま現れる。

2.3 オープンデータの理念——定義・ライセンス・5つ星・FAIR

オープンデータという言葉は、2000年代半ばに具体的な運動として形をとった。Open Knowledge Foundation が2005年に初版を出した「Open Definition（オープンの定義）」は、「誰でも、どのような目的でも、自由に使い、改変し、共有できる」ことをオープンの条件とし、その条件を満たすライセンスの例としてクリエイティブ・コモンズの表示（CC BY）ライセンスなどを挙げた。CC BY は「出典を表示すれば、複製・改変・商用利用を含めて自由に使ってよい」というライセンスであり、磐田市の「都市公園一覧」が採用しているのは、その第3版（3.0）である。当サイトが全ページに「出典：磐田市」を表示しているのは、このライセンスの条件をそのまま実装したものである。

ライセンスが「使ってよいか」の問題だとすれば、「使えるか」の問題を扱ったのが、ウェブの発明者ティム・バーナーズ＝リーが2010年に示した「5つ星オープンデータ」の段階である。星一つはオープンライセンスで公開されていること（形式は問わない。PDF でもよい）。星二つは構造化された機械可読の形式であること（表計算ソフトの形式など）。星三つは特定企業に依存しない形式であること（CSV など）。星四つは個々のデータを URI（ウェブ上の識別子）で指し示せること。星五つは他のデータと結びついていること（リンクト・データ）である。バーナーズ＝リーがヘンドラー、ラッシラとともに2001年に「セマンティック・ウェブ」として構想したのは、この星五つの世界であった。

研究データの分野では、2016年にウィルキンソンらが提唱した FAIR 原則——見つけられる（Findable）、アクセスできる（Accessible）、相互運用できる（Interoperable）、再利用できる（Reusable）——が広く参照されている。FAIR は公開の有無ではなく、公開されたものが「機械にとって」扱いやすいかを問う点で、5つ星の考え方と通じる。本稿が磐田市の一覧を評価するときの物差しも、この二つである。すなわち、ライセンスは開かれているか、形式は機械可読か、行を識別できるか、他のデータとつながるか、そして再利用する側がどれだけの手作業を強いられるか、である。

2.4 日本の政策史

日本の行政オープンデータは、2012年7月に IT 総合戦略本部（高度情報通信ネットワーク社会推進戦略本部）が決定した「電子行政オープンデータ戦略」を出発点とする。2013年6月の G8 サミットでは「オープンデータ憲章」が合意され、日本もこれに署名した。2016年12月には官民データ活用推進基本法が成立し、国と地方公共団体にデータの公開と活用の推進を求めた。2017年5月にはこれを受けて「オープンデータ基本指針」が決定され、公開データは原則として機械判読に適した形式で、二次利用を認めるライセンスのもとで公開すべきことが明記された。地方公共団体向けには、公共施設一覧・公衆トイレ一覧・子育て施設一覧など、多くの自治体が共通の項目で公開できるよう「推奨データセット」の考え方が示され、その後デジタル庁のもとで標準化が続けられている。

この流れを一言でいえば、行政の情報は「求めれば見せる」（1999年の情報公開法）から「求められなくても、機械が読める形で、自由に使える条件で出す」（2017年の基本指針）へと変わってきた。磐田市の「都市公園一覧」は、この後者の段階に属する公開物である。本稿はそれを、理念に照らして評価すると同時に、理念だけでは見えない実務上の細部——空欄・表記・座標・更新——に光を当てる。

3. 「都市公園一覧」の項目を読む——わかることとわからないこと

磐田市の「都市公園一覧」は、行が公園、列が属性という関係モデルの標準的な形をとった、94行の表である。列は14あり、順に、通し番号、種類、種別、公園名、代表地番、現況面積、区域区分、トイレ、障害者用トイレ、砂場、遊具、地区、緯度、経度である。この14列は、公園について「市が台帳として持っている骨格」を、ほぼそのまま外に出したものと読める。本節では列を三つの群に分けて、それぞれ何を伝え、何を伝えないかを検討する。

3.1 分類の列——種類・種別・区域区分

「種類」と「種別」は、都市公園法の体系に基づく分類である。種類には「住区基幹公園」のような大分類が、種別には「街区公園」「近隣公園」「地区公園」「総合公園」「運動公園」「風致公園」「都市緑地」「緑道」「墓園」「歴史公園」「広場公園」のような小分類が入る。当サイトの集計では、94行に施設ガイドのみの6園を加えた100園のうち、街区公園51、近隣公園14、都市緑地10、地区公園4、総合公園3、運動公園3、風致公園3、広場公園2、緑道2、墓園1、歴史公園1、法対象外6となる。「区域区分」は都市計画法上の市街化区域か否かを示す列で、公園そのものの属性というより、公園がある土地の属性である。これらの列の価値は、公園を「法制度上の位置」で読める点にある。街区公園は国の標準で0.25ヘクタール・誘致距離250メートルの近所の公園、近隣公園は2ヘクタール・500メートル、というように、種別がわかれば規模と役割の目安が立つ。

3.2 位置と規模の列——公園名・代表地番・面積・地区・緯度経度

「公園名」「代表地番」「地区」「緯度」「経度」は公園の位置を、「現況面積」は規模を表す。緯度経度が数値で入っていることは、5つ星の観点から見て重要である。地図に落とす、家からの距離を測る、近い順に並べる、といった操作がすべて機械的に可能になるからである。面積も同様で、最大の竜洋海洋公園（221,722平方メートル）から最小の二之宮東第２緑地（17平方メートル）まで、100園を一列に並べて比べることができる。ただし「地区」の列は旧市町単位の区分であって、当サイトが磐田物語・ATAWI TEMPLE と共通で用いる9地区（見付・中泉・御厨・豊田・南部・向陽・竜洋・福田・豊岡）とは粒度が異なる。この違いをどう埋めたかは第5節で述べる。

3.3 設備の列——トイレ・障害者用トイレ・砂場・遊具

設備を表す列は四つで、いずれも「○」か空欄かの二値である。当サイトが94行を集計したところ、トイレ有は69園、車いす対応トイレ（障害者用トイレ）有は34園、砂場有は43園、遊具有は64園であった。この四列は、子連れの利用者にとって最も関心の高い列であると同時に、情報学的には最も注意を要する列でもある。第一に、それが「有無」しか語らないこと。「遊具有」は、ブランコが一台あることも、大型の複合遊具があることも、同じ「○」で表す。第二に、空欄が「無い」なのか「記入されていない」なのかが、表そのものからは判別できないこと（第4節）。第三に、その「○」がいつの時点の状態を写したものかが、表の中には書かれていないこと（第6節）である。

二値のフラグには、しかし固有の強みもある。有無だけに絞られているからこそ、集計と比較が明快になる。トイレ有69園という数字は、市全体の水準を一目で示し、地区別・種別別に切り直すこともできる。もし各園のトイレが自由記述で書かれていたら、69という数字を得るためにはまず記述を読んで有無に符号化する作業が要る。粗い列は情報を捨てているのではなく、集計可能性のために詳細を交換しているのだと読むべきである。問題は粗さそのものではなく、粗い列しかないこと、つまり詳細を受け取る場所が表のどこにもないことである。

3.4 5つ星と FAIR に照らして

この一覧を第2節の物差しに当ててみる。ライセンスは CC BY 3.0 であるから、星一つの条件は満たす。形式は表であり、CSV としても取得できるから、星三つまでは満たすと見てよい。さらに、公開に用いられている LinkData という基盤は、表を RDF（ウェブ上でデータ同士を結びつけるための形式）としても提供する仕組みを備えており、行ごとに URI が与えられるという意味では星四つの要素も持つ。ただし、その URI が他の公開データ——たとえば国土交通省の公園データや、市の施設ガイドのページ——と明示的に結びつけられているわけではないため、星五つ（リンクト・データ）には届いていない、というのが本稿の評価である。FAIR の観点でいえば、見つけられ、アクセスでき、再利用できるが、「相互運用」の面で人手の作業を残している。

つまりこの表は、オープンデータの理念の中では十分に上位に位置する公開物でありながら、公園の「一覧性」の提供にとどまり、その先の「詳細」と「つながり」は使う側に委ねている。これは欠陥というより、自治体が台帳として持っている情報の範囲がそこまでだ、ということの正直な反映であろう。行政が公園について把握しているのは、まず「どこに・どの種別の・どれくらいの広さの公園があるか」であって、「その公園にどんな遊具があり、日陰がどれくらいあり、駐車場が何台分あるか」は、別の文書（施設ガイド）や、現場の管理の中に分散して存在している。表が語らないことは、表が悪いのではなく、表の外にある。

註：本節の項目名と集計値は、当サイトが取得したオープンデータ原本（94行）と、それをもとに集計したファクトシートによる。行数・列名・件数はデータの改訂により変わりうる。

4. 空欄は何を語るか——欠けている項目と欠損値の情報学

表を読むとき、書かれている値よりも難しいのが、書かれていない部分の読み方である。情報学ではこれを欠損値（missing value）の問題と呼ぶ。関係モデルの提唱者コッドは、1970年の最初の論文ののちも長くこの問題を論じ、1990年の著書では欠損を二種類に分けた。一つは「値はあるはずだが今はわからない」という欠損（適用可能だが未知）、もう一つは「そもそも当てはまらない」という欠損（適用不能）である。たとえば「駐車場の台数」は、駐車場がある園にとっては未知でありうるが、駐車場がない園にとっては適用不能である。この区別を表の中に持たない限り、空欄はつねに二つの読み方のあいだで揺れる。

4.1 三つの「無い」——行・列・値

公園オープンデータにおける「無い」は、少なくとも三つの水準で起きる。第一は行の欠如である。「都市公園一覧」は都市公園法上の都市公園を対象とするため、市の施設ガイドに公園として掲載されていても、法の対象外である園は表に現れない。当サイトが施設ガイドから補った6園（クリーンセンター公園・浜部農村公園・はまぼう公園・獅子ヶ鼻公園・新平山工業団地1号公園・天竜川ラブリバー公園）がそれにあたり、これらは面積も不明である。利用者にとっては公園でも、台帳の定義では公園でない、というずれがここに現れる。

第二は列の欠如である。表には、遊具の種類、対象年齢、トイレの様式（洋式か和式か）、おむつ替え台、駐車場、ベンチ、日陰や東屋、水道、水遊び場、道路との柵、見通し、といった列がそもそも存在しない。これらは子連れの利用者が行く前に知りたいことの大半を占めるが、表の設計上、記入する場所がない。列がない以上、そこに空欄すらなく、「わからない」ということ自体が表からは見えない。第三は値の欠如、すなわち存在する列の中の空欄である。トイレ・障害者用トイレ・砂場・遊具の四列は「○」か空欄かであり、空欄が「無」を意味するという慣行は自然に推測できるものの、表の中に凡例として書かれているわけではない。

4.2 施設ガイドに見る「なし」と「記載なし」

この区別が実務の中でどう扱われているかは、市の施設ガイド（公園）を見るとよくわかる。当サイトが77園分の個別ページを突合したところ、駐車場の欄には「有り」「あり」「なし」「3台」といった記載がある園と、記載そのものがない園がある。当サイトはこれを「駐車場:なし」（市が無いと書いている）と「駐車場:記載なし」（市が何も書いていない）として区別して保持している。たとえば福田第1公園と新平山工業団地1号公園は前者、多くの街区公園は後者である。園内施設についても、御殿遺跡公園や竜洋昆虫自然観察公園のように「記載なし」となる園がある。これは、施設ガイドの側にも「無い」と「書いていない」を分ける明示的な仕組みがなく、読む側が文脈から補っている、ということを示している。

コッドの区別に沿って言い直せば、「なし」は値であり、「記載なし」は欠損である。この二つを混同すると、二つの逆向きの誤りが生じる。一つは、書かれていないものを無いと決めつける誤り（記載のない園にも実は駐車スペースがあるかもしれない）。もう一つは、書かれていないものをあるかもしれないと期待し続ける誤り（記載のない園の多くは実際に無いのかもしれない）。どちらの誤りも、現地を見ないでは解消できない。データ設計にできるのは、少なくともこの二つを取り違えないよう、値と欠損を別の記号で保持しておくことである。

4.3 「有」の粒度——同じ○が指すもの

欠損とは別に、値があってもその粒度が粗い、という問題がある。「遊具有」の「○」は、只来下公園（458平方メートル。施設ガイドにはブランコ・滑り台・ジャングルジム・シーソーとある）にも、兎山公園（56,193平方メートル。施設ガイドにはローラー滑り台・ターザンロープ・ザイルクライムほか多数の遊具の記載がある）にも、同じ一つの記号で付く。ベイトソンの言い方を借りれば、「遊具有」の列は「遊具がある園とない園」の差異は伝えるが、「どんな遊具があるか」の差異は伝えない。伝えないことは列の設計上の選択であって、誤りではない。ただし使う側は、その列を「遊具の情報がある」と読んではならず、「遊具の有無だけがある」と読まなければならない。

当サイトのデータ設計は、この節で述べた区別を実装している。オープンデータ由来の四つのフラグは、有を真、空欄を偽として保持する（つまり慣行にしたがって空欄を「無」と読む）が、その読み替えを行ったことを出所の記録として残す。一方、表に列のない項目——洋式トイレの有無、おむつ替え台、ベビーカーで入れるか、日陰、水道など——は、値が入るまですべて「未確認（現地調査待ち）」という欠損の状態で保持し、「無」とは書かない。第7節で改めて論じるが、この「偽」と「未確認」の分離こそが、公園データを一次ソースから二次的に組み立てる者が守るべき最低限の規律であると本稿は考える。

5. 表記ゆれ・識別子・座標——二つの資料を突き合わせる

オープンデータの一覧と市の施設ガイドは、同じ公園について別々に作られた二つの資料である。前者は94行の表、後者は園ごとの説明ページであり、両者を結びつけてはじめて「この園は街区公園で、面積はこれだけで、施設ガイドによればブランコと砂場とトイレがある」という一つの記述ができあがる。情報学ではこの作業を突合、名寄せ、あるいはレコードリンケージと呼ぶ。統計学者フェレギとサンターが1969年に定式化した理論が古典であり、共通の鍵がない二つの記録集合を、名前や住所などの項目の一致度から確率的に結びつける枠組みを与えた。公園の突合はその小規模な実例である。

5.1 共通の鍵がないということ

関係モデルの理想は、二つの表が共通の鍵で結ばれていることである。しかし「都市公園一覧」の通し番号は表の中で行を見分けるための番号であり、施設ガイドの各ページが持つ番号とは対応していない。両者に共通するのは公園名だけである。したがって突合は名前によって行うほかなく、名前は人間が書いた文字列であるから、ゆれる。当サイトが突合できたのは、94行のうち施設ガイドに個別ページのある77園であり、残りの園と、施設ガイドにしかない6園を含めて、100園の台帳ができあがった。この77という数字は、名前だけを頼りにした突合の到達点であって、二つの資料が本来どれだけ重なっているかを示すものではない。

5.2 表記ゆれの実例——全角と半角、ヶ、公園という語

表記ゆれは抽象的な話ではない。当サイトのファクトシートに載る園名の中にも、その痕跡がある。「福田第1公園」の「1」は半角数字であり、「豊田第１緑地」「二之宮東第２緑地」「県営磐田団地第１緑地」の数字は全角である。人間の目にはどちらも「第一」だが、機械にとっては別の文字である。同様に「旭ヶ丘公園」「緑ヶ丘霊園」「獅子ヶ鼻公園」の「ヶ」は、資料によって「が」「ケ」と書かれうる。「城山球場」「磐田スポーツ交流の里ゆめりあ」のように名称に「公園」を含まない園もあり、「公園」の有無で機械的に絞り込むと漏れる。代表地番の欄も「見付（加茂川通り）５９８１」のように全角数字と括弧書きの小字を含み、住所として機械処理するには正規化（文字種をそろえ、括弧を分解する処理）が要る。

表記ゆれは、書き手の不注意の産物というより、複数の人間が長い時間をかけて別々の文書を書いてきたことの自然な帰結である。台帳を作った担当者と、施設ガイドのページを書いた担当者と、地図に注記を入れた担当者は、同じ園を別の機会に別の指の癖で入力する。ゆれを根絶する唯一の方法は入力の時点で機械に強制させることだが、既に存在する資料に対してそれはできない。できるのは、受け取る側でゆれを吸収する層を一枚はさむことである。

当サイトはこれらのゆれを、別名（エイリアス）の辞書と、推定した読み、URL 用の識別子の上書きを一つのファイルにまとめて処理している。読みについては、施設ガイドに個別ページのない園の読みは推定にとどまるため、その旨を「推定」という状態として保持し、検証スクリプトが警告を出すようにしている。表記ゆれの処理で重要なのは、ゆれを消してしまうことではなく、「元の表記」と「そろえた表記」と「そろえた理由」を別々に持っておくことである。元の表記を捨てると、次に一次資料が改訂されたときに、どこが変わったのかを機械的に見つけられなくなる。

5.3 識別子の設計——名前で識別しない

名前がゆれる以上、二次的なデータベースは名前とは別の識別子を持たなければならない。当サイトでは、各園に「IWT-P-001」のような固定の識別子を与え、公園ページの URL には「ichinotani-park」のような読みやすい別の識別子（スラッグ）を用いている。前者は一度与えたら変えない番号、後者は人間のための名前であり、両者を分けるのは、バーナーズ＝リーが1998年に「よい URI は変わらない」と述べた原則の応用である。園名が改称されても、施設ガイドの表記が変わっても、番号は変わらない。写真の保管フォルダも、踏査記録も、この番号に紐づける。識別子を名前から切り離すことは、地味だが、データベースが長く生きるための最も基本的な設計判断である。

5.4 座標と地区——一点で園を表すこと

「緯度」「経度」の列は、園を地図上の一点で表す。これは距離の計算や地図表示に不可欠だが、二つの限界がある。一つは、その一点が園のどこ（中心か、入口か、代表地番の位置か）を指すのかが表に書かれていないこと。面積372平方メートルの見付本通広場公園ではどこでも大差ないが、221,722平方メートルの竜洋海洋公園では、一点では「どの入口から入るか」を表せない。もう一つは、座標の基準（測地系）が表に明記されていないことである。子連れで公園を探す用途では誤差は問題にならないが、他の地理データと厳密に重ねる用途では確認が要る。

「地区」の列は、合併前の旧市町を単位とした区分であり、当サイトが用いる9地区より粗い。当サイトは、住所の大字を9地区に対応させる辞書を用い、括弧内の小字、丁目、前方一致、手動の辞書という順で判定して各園を9地区に割り当てた。この結果、見付21・中泉14・御厨13・豊田28・南部2・向陽2・竜洋13・福田4・豊岡3という園数になる。ただし住所の文字列から機械的に判定した割り当てには、目視での確認が残る園がある。中央公園と遠江国分寺史跡公園はいずれも中泉に割り当てられているが、その判定は住所の括弧内表記を優先する規則によるもので、当サイトはこれを確認事項として記録している。地区への読み替えは、オープンデータには存在しない「当サイトの解釈」であり、その旨を明示して保持するのが情報学的に正しい態度である。

6. データの鮮度——更新頻度と現地との乖離

データ品質を論じる国際規格（ISO/IEC 25012）は、正確性・完全性・一貫性と並んで「現在性（currentness）」をデータ品質の一側面に数える。データが正しかったとしても、それが「いつの時点で」正しかったのかがわからなければ、使う側は判断できない。公園オープンデータは、この時間の次元をほとんど持たない。「都市公園一覧」の14列のなかに、その行がいつ更新されたかを示す列はない。表全体としての公開日や更新日は公開基盤の側に記録されているが、行ごとの「この○はいつ確認されたか」は表からは読めない。表は一枚の写真であり、写真には撮影日が写っていない。

6.1 変化の速さが違う三種類の情報

公園について記録される情報は、変化の速さによって三つに分けられる。第一はほとんど変わらない情報で、種別・面積・位置がこれにあたる。街区公園が近隣公園に変わることはまずなく、面積は拡張や区域変更がない限り動かない。第二は年単位で変わる情報で、遊具や設備がこれにあたる。国土交通省の「都市公園における遊具の安全確保に関する指針」は定期的な点検と、必要に応じた修繕・撤去・更新を求めており、ある年に「遊具有」だった園が、翌年には遊具が撤去されて広場だけになっている、ということは制度上ふつうに起きる。第三は季節や日で変わる情報で、噴水や流れの稼働、工事、点検中の使用禁止、草刈りの状態などである。

この三種類は、記録の更新頻度が本来違うはずのものである。第一の情報は台帳の改訂で足り、第二の情報は年に一度の確認が要り、第三の情報は表に書くこと自体に無理がある。しかし一枚の表は、この三種類を同じ列の並びに、同じ「○」で並べてしまう。使う側が「面積の列は信じてよいが、遊具の列は現地で確かめる」と読み分けるためには、列ごとの変化の速さについての知識が要る。その知識は表の中にはなく、公園というものについての一般的な理解として、使う側が持ち込むしかない。

6.2 施設ガイドに現れる時間

市の施設ガイド（公園）は、オープンデータより多くの時間の情報を含んでいる。各ページには更新日が示され、当サイトはそれを園ごとに保持している。備考の欄には、時期を限った案内が書かれることがある。たとえば今之浦公園のページには、市の施設ガイドに「噴水についてのお知らせ 令和8年7月17日（金曜）から令和8年9月23日（祝日・水曜）まで、噴水を運転します」とある。これは第三の種類の情報であり、期間を過ぎれば古くなる。一方、豊田香りの公園のページには「カスケード（滝）※5月から10月までの9時～17時に稼働」とあり、こちらは毎年繰り返す周期的な情報である。同じ「時間に依存する記述」でも、一回限りの案内と周期的な運用とでは、データとしての扱いが異なる。前者は期限つきの注記であり、後者は施設の属性に近い。

施設ガイドの記述をデータベースに取り込む側は、この違いに敏感でなければならない。期限つきの案内をそのまま「設備」として保持すれば、期間を過ぎたあとも「噴水が動いている」と読まれる。当サイトは施設ガイドの本文を「原文の抜粋」として出所つきで保持し、それを自分の解釈と混ぜないことで、この問題に対処している。原文が古くなれば古くなったことがわかる形で残すのであって、原文を勝手に書き換えて「最新」にはしない。これは第5節で述べた「元の表記を捨てない」原則の、時間軸への拡張である。

6.3 乖離をどう扱うか——データは過去、現地は現在

データと現地の乖離は、避けるべき事故ではなく、記録というものの本性である。記録はつねに過去のある時点の状態を写しており、現地はつねに現在である。したがって問うべきは「乖離があるか」ではなく「乖離をどのように見えるようにするか」である。当サイトは、各園に「机上（L1）」と「踏査済（L2）」という段階を設け、オープンデータと施設ガイドだけで組み立てた状態を L1、現地で確認して日付つきで記録した状態を L2 と呼んでいる。2026年8月16日の時点で L2 の園は0であり、100園すべてが L1 である。写真を追加する場合は撮影日をファイル名と画像の記録の両方に残す。つまり当サイトの設計は、「いつ確かめたか」をすべての観測に付けることを前提としている。

利用者への含意は明確である。表やサイトに「遊具有」「トイレ有」とあっても、それは記録時点の状態であり、当日の状態を保証するものではない。点検中の使用禁止や工事は、現地の表示と市の都市整備課（電話 0538-37-4806）への確認によってしか知りえない。安全に関わる判断は、データではなく現地の表示と関係機関の案内に基づいて行うべきである、と本稿は述べておく。データの役割は、行く前に「候補を絞る」ことであって、行った先で「確かめる」ことの代わりにはならない。

鮮度の問題は、データの公開者と利用者のあいだの分業の問題でもある。行の一つひとつに確認日を付けることは、公開者にとっては台帳運用の変更を意味し、相応の手間がかかる。他方、利用者の側が全園を定期的に見て回ることも現実的ではない。考えられる中間は、変化の速い列（設備）についてだけ確認日を持ち、変化の遅い列（種別・面積・位置）は台帳の改訂日で代表させる、という列ごとの扱い分けである。鮮度はデータ全体の属性ではなく、列ごとの属性として管理するのが、公園のような施設データには適している、というのが本節の実務的な結論である。

7. 一次ソースの一本化——ATAWI PARK のデータ設計とその批判的検討

ここまで、オープンデータの理念（第2節）、一覧の項目（第3節）、欠損（第4節）、突合（第5節）、鮮度（第6節）を検討してきた。本節では、それらの問題に対する一つの実装として、当サイト（ATAWI PARK）のデータ設計を検討する。当サイトは磐田市の公園100園のデータベースであり、運営は富士ヶ丘サービス株式会社（不動産・介護事業を営む磐田市の会社）である。ここで当サイトの設計を取り上げるのは自己宣伝のためではなく、第2節から第6節で述べた抽象的な原則が、具体的な設計判断としてどう現れるかを示す、手の届く事例だからである。設計は公開されており、読者は同じ原則で他の設計を批判することもできる。

7.1 設計の三原則

当サイトのデータ設計は三つの原則に要約できる。第一に、一次ソースの一本化。公園に関するすべての事実は parks.json という一つのファイルに集約され、公開される各ページはこのファイルから機械的に生成される。生成物である HTML を手で直すことは禁じられ、修正はつねに一次ソースを直して再生成する。第二に、出所の分離。一つの園の記述の中でも、オープンデータ由来の値（種別・面積・フラグ）、施設ガイド由来の値（駐車場・園内施設の原文抜粋・更新日）、当サイトの踏査で得る値（遊具の詳細・トイレの様式・日陰など）は、別々の場所に別々の出所として保持される。第三に、欠損の明示。踏査で得るはずの項目は、値が入るまで「未確認」であり、無いとも有るとも書かない。

この三原則は、ソフトウェア工学で「信頼できる唯一の情報源（single source of truth）」と呼ばれる考え方の応用である。同じ事実を二か所に書けば、いつか二つは食い違う。食い違ったとき、どちらが正しいかを決める規則がなければ、データベース全体の信頼が損なわれる。一本化とは、食い違いが起きる場所をあらかじめ一つに限定しておく設計であり、原本と写しの区別を機械に強制させる仕組みである。加えて当サイトでは、件数・重複・必須項目・地区・座標・型の混在を検査するスクリプトが用意され、一次ソースの改変は検証を通ってから公開される。人が規律を守るのではなく、規律を道具に埋め込むのである。

7.2 想定される批判と応答

この設計にはいくつかの批判がありうる。第一の批判は、一本化は改変の集中でもある、というものである。一つのファイルにすべてを集めれば、そのファイルの誤りはすべてのページに複製される。分散していれば一部で済んだ誤りが、全体に及ぶ。この批判は正しい。応答は、誤りの「検出」と「訂正」の費用で考えることである。誤りが100ページに手書きで散らばっていれば、見つけることも直すことも100回の作業になる。一本化されていれば、誤りは一か所を直せば全ページから消える。一本化は誤りを防がないが、誤りの訂正費用を最小にする。検証スクリプトと組み合わせることで、検出の費用も下げられる。

第二の批判は、二次データベースは一次データの誤りを増幅する、というものである。オープンデータの面積が誤っていれば、当サイトの面積も誤る。しかも当サイトは読みやすく整形して見せるから、誤りはより信じられやすくなる。この批判も正しい。応答は二つある。一つは、出所を園ごとに明示し、原本（オープンデータの原文と施設ガイドの抜粋）にさかのぼれる形を保つこと。もう一つは、CC BY の条件である出典表示（出典：磐田市）を全ページで行い、当サイトの記述と市の記述の責任の所在を分けることである。増幅を完全には防げないが、検証の経路を開いておくことはできる。

第三の批判は、踏査を前提とした設計は、踏査が進まなければ空欄だらけの表にすぎない、というものである。現時点で踏査済の園は0であり、親目線の項目はすべて「現地調査待ち」である。この批判はもっともであり、本稿はこれを認める。ただし、空欄だらけであることと、空欄が見えることは違う。何がわかっていて何がわかっていないかが一覧できる状態は、何がわかっていないかすら見えない状態よりも、利用者にとって誠実である。第4節の言葉でいえば、当サイトの現状は「欠損の明示」を大規模に実演している段階であり、踏査はその欠損を一つずつ値に置き換えていく過程として設計されている。

7.3 オープンデータへの還流という論点

最後に、二次利用者が得た情報は一次データに還流しうるか、という論点に触れる。オープンデータ論では、公開されたデータを市民や事業者が使い、その成果や誤りの指摘が行政に戻ることで、データの品質が循環的に高まるという理想が語られてきた。公園でいえば、踏査で見つかった表記の誤りや設備の変化が市に伝えられ、次の改訂に反映される、という循環である。この循環が成り立つためには、二次利用者の側が「どの行の・どの列が・いつの観測と食い違ったか」を特定できる形で記録している必要がある。出所を分離して保持する設計は、この還流の前提条件でもある。当サイトがこの循環に実際に寄与できるかは、踏査の進み方と市側の受け入れ体制に依存し、現時点では可能性の指摘にとどまる。

8. 磐田市の公園への示唆

本節では、ここまでの検討を磐田市の公園の具体的な姿に引き寄せて、データを読む市民・行政・地域関係者それぞれへの示唆を述べる。用いる数値はすべて、磐田市オープンデータ「都市公園一覧」（94行・CC BY 3.0・出典：磐田市）と市の施設ガイドをもとに当サイトが集計した範囲のものである。

8.1 データだけでここまで言える——一覧性の実演

オープンデータの一覧性は、たとえば次のような文を、現地に一度も行かずに書けるという形で現れる。磐田市の公園100園のうち半数を超える51園が街区公園、すなわち住宅地の中の小さな公園であり、近隣公園14、都市緑地10がそれに続く。面積の幅は大きく、最大の竜洋海洋公園221,722平方メートルから最小の二之宮東第２緑地17平方メートルまで、一万倍を超える開きがある。9地区への読み替えでは豊田28園・見付21園が多く、南部と向陽は各2園である。オープンデータのフラグでは、94行のうちトイレ有69・車いす対応トイレ有34・砂場有43・遊具有64。施設ガイドとの突合では、駐車場について「有り」等の記載がある園が33にのぼる。

この骨格は、行き先の候補を絞るには十分に役立つ。家の近くの街区公園で砂場のある園を探す、車で行ける駐車場つきの大きな園を探す、といった問いは、データだけで答えられる。第3節で述べたとおり、これがオープンデータの約束する価値の中心であり、磐田市の一覧はその価値を実際に提供している。CC BY 3.0 という条件のおかげで、当サイトのような第三者が出典を示して自由に再構成できることも、理念どおりの運用である。

8.2 データでは言えないこと——踏査の課題一覧

他方、第4節から第6節の検討は、データで言えないことの一覧を与える。遊具の対象年齢と状態、トイレの様式（洋式か和式か）とおむつ替え台の有無、ベビーカーで入れるか、日陰とベンチの配置、水道の位置、道路との柵と見通し、駐車場から遊び場までの動線——これらは表に列がないか、あっても粒度が粗い。施設ガイドの園内施設の記述は貴重な補いだが、77園にとどまり、記述の詳しさも園によって差がある。たとえば安久路公園には複合遊具のインクルーシブエリアやインクルーシブアイテムつきのブランコの記載があるが、こうした記述の細かさがすべての園で保証されているわけではない。当サイトはこれらをすべて「現地調査待ち」の欠損として保持しており、今後の踏査で一つずつ値に置き換えていく。踏査はまだ始まっていない。この論文の続きは、机上ではなく現地で書かれることになる。

8.3 行政への示唆——小さな改良の大きな効果

本稿の検討からは、公園オープンデータの再利用性を大きく高める、費用の小さい改良をいくつか挙げることができる。第一に、空欄の意味の明示である。フラグ列の空欄が「無」を意味するのか「未記入」を意味するのかを、データの説明に一行書くだけで、第4節で論じた曖昧さの多くは解消する。第二に、行ごとの確認日である。「この行の設備欄を最後に確認した日」の列が一つあれば、鮮度の判断（第6節)が使う側に可能になる。第三に、施設ガイドのページ番号など、他の市の公開資料と結びつく鍵の列である。これがあれば第5節で述べた名前による突合は不要になり、5つ星でいう四つ星から五つ星への一歩となる。第四に、名称の文字種（全角・半角）の統一である。いずれも新しい調査を要さず、台帳の出し方の工夫で足りる。

これらは磐田市に限らない、自治体の公共施設データ一般への示唆でもある。国の推奨データセットの考え方が示すとおり、項目とコードの標準化が進めば、市境をまたいだ比較——隣接する市の公園と磐田市の公園を同じ表で見る——も機械的に可能になる。公園のように市民の生活圏が行政界と一致しない施設では、標準化の利益はとりわけ大きい。

8.4 市民と地域関係者への示唆——データを読む力

子育て世代の読者への示唆は、実践的に言えば次の三つである。第一に、一覧やサイトの情報は「候補を絞る」ために使い、当日の状態は現地で確かめること。設備の使用可否や工事の情報は、現地の表示と市の都市整備課（電話 0538-37-4806）が最も確かである。第二に、「情報がない」ことを「無い」と読まないこと。駐車場の記載がない園にも、トイレの記載が簡素な園にも、現地には現地の事実がある。第三に、逆に「有」の一文字を過度に信頼しないこと。「遊具有」の中身は園によってまったく違う。データを読む力とは、値を読む力である以上に、値の限界を読む力である。

地域の関係者——自治会、子育て支援の団体、学校——への示唆としては、オープンデータが「地域について語るための共有の土台」になりうることを挙げたい。どの地区に公園が少ないか、どの園にトイレがないかといった議論は、印象ではなくデータを起点にできる。そしてデータに欠けている現地の実情は、日々公園を使っている住民こそが最もよく知っている。オープンデータと住民の知識が突き合わされる場所に、第7節で述べた「還流」の芽がある。当サイトの踏査も、その一つの試みとして位置づけられる。

9. 結論と今後の課題

9.1 結論——四つの命題

本稿は、情報学の立場から磐田市オープンデータ「都市公園一覧」を読み、公園オープンデータの可能性と限界を検討してきた。得られた結論は次の四つの命題に要約できる。第一に、オープンデータの価値の中心は一覧性と再利用可能性にある。磐田市の一覧は、CC BY 3.0 という開かれたライセンスと機械可読な形式によって、100園のデータベースという二次的な構築物を第三者が作ることを現に可能にしており、オープンデータの理念が約束する価値を提供している（第2節・第3節・第8節）。骨格としての一覧がなければ、当サイトの試みは公園の名前を集めるところから始めなければならなかった。

第二に、その限界は粒度と鮮度にある。表は有無しか語らず（粒度）、いつの状態かを語らない（鮮度）。空欄は「無」と「未記入」のあいだで揺れ、列がない項目は「わからない」ことすら見えない（第4節・第6節）。第三に、二つの資料を突き合わせて一つの記述を作る作業は、共通の鍵の不在と表記ゆれのために手作業を残し、名前ではなく識別子で園を指すという設計上の規律を要求する（第5節）。第四に、これらの限界に対する実装上の応答として、一次ソースの一本化・出所の分離・欠損の明示という三原則が有効であり、当サイトの設計はその一例である。ただしこの設計は、誤りの増幅や踏査の遅れという批判に対して、完全な防御ではなく、検証可能性の確保という部分的な応答を与えるにとどまる（第7節）。

四つの命題を貫くのは、データは現実の代わりではなく、現実への索引である、という一つの見方である。索引は本文を読む手間を省くためにあるのではなく、本文のどこを読むべきかを教えるためにある。94行の表は、磐田市の公園という「本文」のどこを見に行くべきかを教える索引として読まれるとき、最もよく働く。索引を本文と取り違えたとき——表に書いていないから無いと断じ、表に書いてあるから今もそうだと信じたとき——データは使う者を誤らせる。誤らせるのはデータではなく、読み方である。

9.2 本稿の限界

本稿の限界を三つ挙げる。第一に、本稿は一つの自治体の一つのデータセットの検討であり、ここでの観察がどこまで一般化できるかは、他の自治体・他の施設種別のデータとの比較を待たなければならない。空欄の意味の曖昧さや確認日の欠如は多くの自治体データに共通すると推測されるが、それは推測であって、本稿はそれを示していない。第二に、本稿はデータの側からの検討に終始しており、データと現地の乖離の実際の大きさを測定していない。踏査済の園が0である現状では、これは原理的に不可能であった。第三に、データを公開し維持する行政側の実務——台帳の管理体制、更新の手順、公開の費用——を、本稿は外側からしか見ていない。第8節で「費用の小さい改良」と述べた提案も、市の実務を内側から知れば別の評価になりうる。行政学や公共経営の観点からの検討は、関連する他稿に委ねる。

9.3 今後の課題

今後の課題は、この限界の裏返しである。第一に、踏査の遂行と、踏査結果とデータの突合の記録である。100園を歩き、表の「○」と現地の実物を突き合わせたとき、乖離はどの列に、どの程度現れるか。遊具の列は面積の列より乖離が大きいはずだという第6節の見通しは、踏査によって検証可能な予測である。その結果は、公園オープンデータの品質についての、小さいが実測に基づく知見になる。第二に、確認日つきの観測を蓄積する運用が、個人サイトの規模で持続可能かの検証である。データベースは作ることより保つことが難しい。100園の情報を、季節が変わり遊具が更新されるなかで、どの周期でどの項目を見直すのか。この運用の設計自体が、情報学の実践的な課題である。

第三に、得られた指摘を市のデータ改訂に還流させる経路の模索である。第7節で述べたとおり、還流には、どの行のどの列がいつの観測と食い違ったかを特定できる記録が要る。当サイトの設計はその前提を満たすように作られているが、経路そのものは市側の受け入れ体制に依存し、現時点では開かれていない。オープンデータは公開して終わりではなく、使われ、確かめられ、直されて循環するときに最も価値を持つ。本稿がその循環の、磐田市における最初の一巡の記録となることを期して、結びとする。