共通データ仕様のカバー範囲
PPP共通データ仕様協議会で公開しているデータ仕様を「共通データ仕様」と呼んでいますが、以下の位置づけです。黄色い部分が共通データ仕様のカバー範囲です。
つまり、施設管理ドメインのドメインデータモデルであると共に、エリアデータ連携基盤や施設管理事業者間の事業引継ぎにおいては具体的な実装を示すデータモデルでもあります。ドメインデータモデルですから、CSVや表計算ソフトのデータモデルなどにも継承する事が可能です。電子データとは言いにくいですが、紙の報告書や表においても、そこにデータが記載されている以上継承する事が可能です。例えば、雨の日やその次の日に天井から雨水がポタポタしたたる「不具合現象」は「雨漏り」と呼ぶ、「雨漏れ」などと呼んではいけないなどの決まりはどの様な形式の電子データであっても紙帳票であっても継承する事が可能です。エリアデータ連携基盤のデータモデルはNGSI V2と言う名前の標準に準拠しています。NGSI V2については本ページの最後に補足しますが、建物などの複雑な構造を持つ情報を登録する事が可能な電子データの形式の標準です。共通データ仕様に準拠してNGSI V2の形式で電子データを作成すればそのままエリアデータ連携基盤に格納可能で。また、複雑な構造を表現できますから、エリアデータ連携基盤を導入していない場合ても、事業者間のデータの引継ぎなどでの活用が可能です。
データモデルとしての性格がありますので、用語とNGSI V2準拠のデータモデルに関しては、細かく仕様を定めています。用語とは、前記の「雨漏り」の様に、項目に登録しても良い文字列(言葉・単語・数字など)のリストの事です。技術的にはその様な項目を「列挙型」の項目と言い、リストに並べ並べられている一つひとつの文字列を「列挙子」と言います。例えば、株式会社は”株式会社”と記載し、”㈱”、”(株)”などと書いてはいけないというルールです。アプリのプルダウンメニューだと思えば間違いありません。用語については、CSVだろうが紙帳票だろうがディスプレイに表示する電子帳票だろうが準拠する必要があります。NGSI V2はデジタル庁が推進しているエリアデータ連携基盤の推奨モジュール(ソフトウェア)であるFiware/Orionのインタフェースで使われるデータモデルの仕様です。従って、エリアデータ連携基盤を使用するためには、それらの点について厳密に準拠する必要があります
ラストワンマイルのデータ仕様共通化
政府が主導する形でシステム間のデータ連携のための標準化活動が進んでいます。この様な活動は国内に限らず、グローバルに検討が進んでいます。下図では左に描いた「プロのためのデータ仕様」がそれです。例えば建築設計ではBIMと呼ばれるシステムの考え方がありますが、その標準としてIFCというものがあります。この様な標準は今後徐々に分野を広げると期待されています。ただ、これらの標準はかなり難しく、登録されるデータも人間にはとても読めない様な記述方法が定められています。
一般の利用者にとってはその内容をそのまま画面や報告書に記載さても意味不明ですから、各システム事業者が個々に分かりやすい表現、例えば日本語に変換して表示したり電子データとして出力しています。そうなると図中で一番右の利用者にとっては事業者やAPが変わるたびに表示の内容や電子データの形式が変わる事になりますからとても不便です。つまり、プロのためのデータ仕様は一般利用者にとっては余り都合の良いものではないのです。
そこで、PPP共通データ仕様協議会では、利用者のためのデータ仕様の共通化を推進しています。利用者とは、自治体の様な施設オーナー、施設管理事業者や再委託先の様なICT以外の分野の専門事業者などを指しています。
蛇足ですが、両方の仕様について補足します。プロのためのデータ仕様はミスコミュニケーションを避けるために「同音異義語」を極力排除します。一方、人間の言葉の原則には「経済性」というものがあり、少ない言葉数でできるだけ多くの情報を届けたいというものがあります。経済性のひとつの側面に多義性と呼ばれるものがあります。多義性という言葉は聞きなれないと思いますが、要するに同音異義語の類です。つまり、人間の言葉は同じ単語でも違う意味を持たせることで単語の数を減らしています。この多義性の副作用で会話の際に誤解が発生する事は皆さん普段からご経験の事だと思います。これに対しプロのためのデータ仕様はコンピューター間の情報伝達なので、あまり経済性は重視せず、それよりも正確性や詳細性を重視します。このため、プロのためのデータ仕様は人間にとっては理解が難しい複雑なものになっています。例えば人間が使う言葉のひとつに「お好み焼き」という言葉があります。お好み焼きには地域性があり、大阪のお好み焼きと広島のお好み焼きは違う食べ物です。大阪のお好み焼きは小麦粉や出汁などを溶いた生地に具材を混ぜ込んで焼きます。これに対し広島のお好み焼きは生地をクレープの様に薄く焼いてその上に具材を重ねる様に焼きます。因みに大阪のお好み焼きは広島でも食べられていて、混ぜ焼きなどと呼んでいます。更に、広島県内ても地域性があり、呉市付近では必ず麺を入れると共に半分に折って半月状にして食べます。
プロのためのデータ仕様では日本語は使えませんし同音異義語も無くしたいので、お好み焼きとは表現せず、例えば”JapaneseSavoryPancake.city.osaka.jp”、”JapaneseSavoryPancake.city.hiroshima.jp”、”JapaneseSavoryPancake.city.kure.jp”などとurl形式で表現する事が多いです。JapaneseSavoryPancake.はお好み焼きを無理やり英語にしてUCCという形式で単語を繋げたものです。その後ろが大阪・広島・呉を区別するurlのドメイン部分です。例えば「今日はJapaneseSavoryPancake.city.osaka.jpを食べに行こう」などと表現する訳です。これでは単語が長すぎるので、JapaneseSavoryPancake.city.osaka.jpの短縮形も定義する場合があります。例えば”OC:JapaneseSavoryPancake”と表現します。何れにせよ分かりにくいし長すぎて人間には使いにくいですよね。そこで共通データ仕様では人間用の用語を共通化する訳です。お好み焼きをもし用語として決めるのであれば、”混ぜ焼き”、”広島焼き”、”呉焼き”に統一しようなどと決める訳です。
共通データ仕様の特徴
以上の事から、共通データ仕様は以下の特徴を備えています。
- GIFはじめ、各種標準やガイドラインに準拠しています
PPP共通データ仕様協議会の役割は新たなデータ仕様を策定する事ではなく、データ仕様を共通化して普及させる事です。従って、出来る限り新たなデータ仕様は策定せず、既存のデータモデル、語彙、ガイドラインに準拠します - PPP共通データ仕様協議会で改版される事を前提としています
どの様な標準であれ全ての標準仕様は技術の進歩やニーズの変化に即応して変化していくものです。変化できない標準は新たな標準に置き換えられ、淘汰されていきます。データ仕様も同様で定常的に更新されるべきものです。例えば設備1つを見てもLED照明、太陽光パネル、蓄電設備などは少し前の施設にはありませんでした。これからもAI技術やロボット技術などでどんどん新しい設備、例えばドローン警備等が出てくるかも知れません。従って、共通データ仕様は常に未完成であり、協議会の活動との両輪で初めて意味があるものです - 公開される事が前提です
このホームページ含めて、広く公開される事を前提としています - ITエンジニア以外にも使われる事を前提としています
データ仕様にはコンピューター間でやり取りする仕様と、一般利用者に向けての仕様があります。前者の仕様には例えばBIM(Building Information Modeling)の標準であるIFCという標準があります。施設の一般利用者にとって建築物の表面は「壁」と言いますが、IFCではIfcRelSpaceBoundaryというデータで表現したりします。要するに一般人にはとても分かりにくい(でも誤解を生まない正確な)表現をします。一般利用者にとっては壁は「外壁」や「内壁」であって欲しいし、床は「床」であって欲しいわけです。そうは言っても内壁を別な人が単に「壁」と呼び始めると混乱しますから、皆で内側の壁は「内壁」と呼ぶと決めます。共通データ仕様はこの後者の仕様を決めています - 多目的データモデルを基本としています
共通データ仕様は少数の例外を除き、多目的データモデルとして策定してあります - よく使われる項目はデータパーツにしてあります
例えば「住所」と言う項目は多くのデータモデルに出て来ます。この様に多くの帳票で使われる項目の定義をそれぞれのデータモデルに個別に記載すると記載の祖語の原因となります。そこで、共通して使われる項目の定義を「データパーツ」としてくくり出して記載してあります。
共通データ仕様の公開
共通データ仕様は以下のみっつの方法で公開しています。
- ホームページによる公開
データモデルの多くはGitHubというインターネット上のサイトで公開しています。このサイトはITエンジニアにとっては常識といっても過言ではないよく知られた場所です。ただ、ITエンジニア以外には難しい世界ですので、誰でも簡単に見る事ができるこのホームページで公開しています。あとで説明するCSVの策定などではホームページを参照するのが簡単です。 - Excelファイルによる用語の公開
FMシステムの多くは利用者がイチイチ現象や原因を登録する必要が無い様にプルダウンメニューを用意しています。またこのプルダウンメニューはカスタマイズ可能となっています。そこでPPP共通データ仕様協議会ではホームページに公開している用語をひとつのExdcelファイルにまとめてダウンロード可能としてあります。FMシステムの管理者はこのexcelファイルを自分のDMシステムの仕様に合わせて加工してプルダウンメニューのデータとして利用する事ができます。 - JSON Schemaによる公開
JSON Schemaとは、JSONの形式で書かれたデータがデータモデルに合致しているかどうかをチェックするツールに入力するためのデータモデルの定義です。チェックツールでの利用以外にデータ変換ツールでも利用する事があります。2025-12-20時点で本ホームページのケーススタディ以外の利用実績は無いと思われます。不具合等あれば、他の情報同様に事務局にお知らせください。尚、JSON SchemaはNGSI V2のNormalized形式のみに対応しています。
「用語」とは
繰り返しになりますが、用語について改めて記載ます。
例えば空調の設備に関する帳票があり、その帳票の項目に「設備の種類」という項目があったとします。その項目に登録する用語はエアコンに関して考えても、「エアコン」の他に「エアーコンディショナー」「空調」「空気調和設備」など複数の候補があります。この様な場合に「皆で『空調』と記入する事にしよう!」と決めているのが「項目に登録する用語の定義」です。
データモデルは多くの場合多少の違いは相互に変換可能ですが、用語の変換は難しい場合が多いです。例えば前記ののエアコンの場合、業務用では室外機・室内機・全熱交換器などの複数の部分から構成されています。これは、エアコンに限らず、水道設備やトイレなどでも同様です。この様に、どの程度の粒度で用語を登録するのかも決めてあるのが用語の定義という事になります。
従って、本データ仕様に準拠しようとする場合には、本データ仕様の用語定義を利用するか、自社内で使用する用語の定義を本データ仕様より細かく定義しておいて変換するなどの考慮が必要となります。
現在定義してあり用語は全てを網羅している訳ではありません。前出の例のエアコンでも、新型コロナの経験で、近頃はCO2センサが付けられる場合があります。メーカによっては人感センサや床温度センサもあるようです。この様に日進月歩で用語は増えていきます。もし新たな用語が必要になったら、コメントを発信して、追加してください。
[ご参考] NGSI V2について
共通データ仕様はドメインデータモデルとしての活用を意図していますが、項目名や事例はNGSI V2に準拠したものを掲載しています。NGSI V2は既に記載した様にデジタル庁が薦めるエリアデータ連携基盤の推奨モジュールの仕様です。デジタル庁ではエリアデータ連携基盤を全国の自治体に広く普及させようと活動しいますので、近い将来どこの自治体でもNGSI V2に準拠したデータをエリアデータ連携基盤に登録し、防災、観光、健康づくり、事業振興などに活用される事が期待されます。
NGSI V2の仕様には以下の特徴があります。
- 文字はUNICODE一択です
昔はSJISなど多様な文字の表現(文字セット・符号化方式)がありましたが、現在はUNICODEが主流です。英語と日本語だけでなく、中国の漢字やハングルなども同時に表現できます。また、UNICODEでは符号化方式を複数定義していますが、NGSI V2ではUTF-8一択です。 - 3階層で情報を表現します
3階層とは例えば、ある「部屋」の「温度」が「10℃」であった時に、その10℃の測定が「机の上の寒暖計」で測定したと補足する様なイメージです。ょっと分かりにくいですね。但し、共通データ仕様では2階層しか使いません。つまり、ある部屋の「温度」が「10℃」であったと表現し、もしどの寒暖計で測定したのかを登録したいときには、別の項目に登録する事にしています。これは、CSVなどの表で情報を表現する場合、「温度」と「寒暖計」の項目を別に用意し、それぞれ「10℃」と「机の上の寒暖計」を登録するイメージです。この様に、CSV等の表形式に継承しやすくするため、共通データ仕様では3階層を使用していません。 - 項目名は米国英単語をつなげたものです
例えばalternate name(通称)」という項目の項目名は、alternateNameという項目名になります。この英単語をくっつける形式はキャメルケースと言います。単語の境目の頭文字をラクダのこぶの様に大文字にする書き方です。この書き方は日本人には分かりにくく、CSVの項目名としても使いにくいのでデータモデルでは「呼称」を付与してあります。alternateNameの呼称は「通称」です。呼称と項目名を併記したい場合は「通称(alternateName)」などと記載します。この呼称はデータモデルの定義としては意味を持ちませんが、CSVなどに向けたドメインデータモデルなどへの活用を期待しています - JSONに準拠しています
NGSI V2はJSON形式に準拠しています。従って、プログラミングなどではJSON向けのクラスなどがそのまま使用できます。ここで言うクラスとは、読み込んだり書き出したり変換する各種部品の事です。
