430 コアデータモデル
デジタル社会推進実践ガイドブック DS-430
コアデータモデル全体概要
2026年(令和8年)3月17日
デジタル庁
[キーワード] データ標準、相互運用性、データ連携、データモデル、データ形式 [概要] 行政機関で個人や法人に関するマスターデータや各種手続きに関するシステムを開発するときに参照すべき実践的なデータモデルについて紹介。このガイドに従いデータ構造の設計を行うことで、他機関とのデータ交換が容易、かつ正確に行えるようになり、データ設計を行うコストも削減することができる。 |
|---|
はじめに
背景
行政機関では多くのデータを管理していますが、そのデータは独自の形式である場合が多く、標準化されていません。そのため、データの再利用が困難であったり、外部とのデータ連携においても大きな障害になっています。また、データ形式が標準化されていないと、データ連携ができないだけでなく、データの整形に多くのリソースを割くことになり、分析にも支障をきたします。AIやビッグデータの活用が注目されていますが、そのインプットとなるデータが十分に整備されていなければ、目的の結果にたどり着くのが困難になります。
欧州や米国では、行政データの標準化を進めることで、社会全体のデータ標準化につながっていくものと考え、欧州委員会(EC)は、各国の個人、法人、場所情報等が活用できるようにSEMICという行政データ標準化のプロジェクトが、米国ではNIEMというプロジェクトが進められています。
日本においても行政データの標準化を図るため、これまで標準ガイドライン群の一部として、行政基本情報データ連携モデル、行政サービス・データ連携モデル(β版)、推奨データセット、共通語彙基盤などを設計、公開してきました。これら既存の標準群はデータを相互に連携する際の共通規格のように使われることを想定しており、世の中の基礎的な要素について統一した表現方法を採用することで、データの相互運用性を確保することを目的としています。
解決したい課題
データ標準を実際に使いたいユーザーの目線から見た時、大きく分けて以下のような課題があります。
-
標準が普及しておらず、存在を認識できていない
-
標準がたくさんあって、どれを見ればいいのかわからない
1つめの課題は標準の普及についてです。デジタル庁サイトに掲載はしているものの、その認知度や可読性には課題があります。
-
掲載されていることを知らなかった
-
そもそもデータの相互運用性の課題に対して、標準というアプローチがあることを知らなかった
などの理由により、標準が広く普及しているとは言い難い状況にあります。
2つめの課題は標準の統一についてです。既存の標準群はそれぞれ異なったタイミングで整備・発表されたものなので、内容であるデータ項目には重複や定義の差異が存在しており、データの構造も異なっています。ドキュメント自体の体系もそれぞれ異なっているため、ユーザーは複数の異なるドキュメントからユースケースにあった標準を見つけねばならず、標準を採用するまでの負荷が増大しています。
既存の標準群を統合・再整理し、利活用の側面からデータ項目の取捨選択、定義の見直しを行った上でGIF(Government Interoperability Framework
)として一つにまとめています。統合したデータ標準は、基礎編であるコアデータモデルと、応用編である実装データモデルに分けて整理しています。基礎編では社会の様々な場面で登場する個人や法人、住所や連絡先などの基礎的なデータをコアデータモデルとして本書で取りまとめています。応用編ではコアデータモデルの組み合わせやカスタマイズによって表現される実装データモデルを、行政、教育、スマートシティなど分野ごとに分けて整備しています。
検討のプロセス
標準の再整理は以下のプロセスで検討を行いました。
既存の標準群のデータ項目について対応表を作成
既存の標準のうち、行政データ・サービス連携モデル(β版)をベースに、推奨データセットやIMI共通語彙基盤など、その他の標準をデータ項目ごとに紐づける形で対応表を作成しました。これにより、データ項目の重複や差異、欠落を洗い出し、項目レベルでの統合を行いました。標準間の細かい定義の揺れもこのプロセスで吸収しています。
個々のデータ項目について必要性や定義を再検討
作成した対応表をもとに、データ項目一つ一つについて、民間のデータ有識者を含むデジタル庁内で検討を行い、定義の見直しや項目自体の取捨選択を行いました。項目の必須・任意の分類もこのプロセスで行なっています。必須項目を定義することで、最低限の相互運用性を確保しつつ、任意項目の選択や利用者独自の項目追加により、カスタマイズの余地を残すことを目的としています。
実装の容易さや利便性を加味して全体を構造化
最後に、確定したデータ項目を正規化し、全体の構造の見直しを行いました。既存の標準の中ではIMI共通語彙基盤が最も構造化されています。逆にオープンデータの普及を目的とした推奨データセットは構造化が最小限に留められています。構造の見直しにおいては、これら2つの既存標準の中間となるような、ある程度は構造化されていてシステム実装とメンテナンスが行いやすく、かつフラットな構造を一部残すことでデータ利用者にとって扱いやすいことを念頭に置いて再構成しています。この過程において「ID情報型」や「コード情報型」など、項目に対応する新しいデータの型を追加しました。
再構成した新しい標準体系は実際の利用場面を想定した実装データモデルとして位置付けています。それに対して、既存の標準であるIMI共通語彙基盤はデータの概念辞書のように使われることを想定しています。
全体像
ドキュメントの構成
再整理したデータ標準のことを以下、コアデータモデルと呼称します。コアデータモデルのドキュメント構成は図1のとおりです。

図1 ドキュメント構成
全体を説明する本書とは別に3つの大きなドキュメント群で構成されます。
コアデータモデル解説書
様々な場面で参照される以下の要素について、標準となる基本的なデータ構造を定義しています。
-
個人
-
法人
-
連絡先
-
住所
-
施設
-
アクセシビリティ
-
子供預かり情報
-
土地
-
建物
-
設備
-
イベント
これらについてデータ項目と使い方の解説を記載したものがコアデータモデル解説書です。行政が保有するデータだけでなく、民間事業者が保有するデータにも活用されることを想定しています。
例えば、民間事業者が「個人」のデータモデルを参考に自社サービスのユーザー情報をデータ化したり、「法人」のデータモデルを参考に取引先の情報をデータ化し、設計コストを下げるとともに他社や行政との相互運用性を高めることなどが想定されます。
DMD (Data Model Description)
データ項目の解説書としてDMD (Data Model Description) を作成し、表形式ファイルにまとめています。行政または民間事業者がデータを設計するにあたって、DMDを参考に任意項目の取捨選択や、項目のカスタマイズの検討、システム実装の際のスキーマ決定の参考として活用されることを想定しています。
DMDの詳細は添付の「438_コアデータモデル_DMD.xlsx」を参照してください。
コード一覧
データ項目の形式で利用するコードの一覧として、コード一覧を作成し、表形式ファイルにまとめています。
コード一覧の詳細は添付の「438-1_コアデータモデル_コード一覧.xlsx」を参照してください。
コアデータパーツ
日付や電話番号、住所など、様々なデータモデルで登場する以下のデータ項目に関しては、共通形式を定めています。
-
日付時刻
-
住所・所在地(アドレス)
-
郵便番号
-
地理情報
-
電話番号
共通形式でデータを記述しておくことで、連携の際に変換処理を省くことができ、円滑なデータ連携が可能になります。コアデータモデルにおいては、行政基本情報データ連携モデルをベースに内容を更新したものを「コアデータパーツ」としてまとめています。これらデータ項目の形式の詳細については別紙「コアデータパーツ」を参照してください。
コアデータモデルの全体構造
コアデータモデル全体の構造をクラス図として表現すると以下のようになります。(大きなサイズのものはPDF資料の「430-1_DMD_クラス図_.pdf」も併せて参照してください。)

図2 コアデータモデルの全体像
住所や連絡先など、その他のモデルでも頻繁に登場するデータに関しては個別に切り出して定義しています。個人、法人、住所の基礎的な項目に関しては、データの利用シーンに合わせた必須項目をパターン化しています。
DMD (Data Model Description) の構造
DMDの構造は以下のとおりです。
基礎項目と拡張項目
データモデルの基本的な情報を基礎項目として、基礎項目以外の情報として拡張項目をそれぞれ用意しています。用途に応じてカスタマイズする際に拡張項目を利用することを想定しています。
項目名、項目名(英語)
データ項目の名称を日本語と英語で記載しています。英語名はIMI共通語彙基盤およびSchema.orgで既に定義済みのものを引用する他、未定義のものは新たに定義しています。
必須項目
基礎項目は必須項目と任意項目を分類しています。必須項目はデータモデルを設計する際、必ず含めておくべき項目です。例えば「個人」であればID、氏、名、氏(カナ)、名(カナ)、性別、連絡先が必須項目となっています。任意項目はデータモデルの設計の中で省略することができます。
最大数
最大回数はデータ項目の繰り返しが可能な回数を指定しています。例えば「個人」であればIDの最大回数がNとなっています。これはIDという項目の中に複数のID情報を含めることが可能ということを示しています。個人がもつIDはマイナンバーなど公的な番号以外に、社員番号、教員番号のように組織から付与される番号が存在します。これらの番号を一つのデータモデルの中で複数個扱えるようにするため、IDの最大回数はNとなっています。
説明
データ項目の説明文を記載しています。
形式
文字列、数値、日付など、データ項目の形式を指定しています。一部のデータ項目は構造化された型や他のコアデータモデルを形式として指定しています。なお、データ長は目的により異なる場合があるので定めていません。
記入例
「2022-03-31」や「山田 太郎」などの具体的なデータの例を記載しています。
その他項目
本書でまとめたコアデータモデルは別定義のデータ標準と区別するために、プレフィックスとして「pd」(Public Data)を付与しています。
以下にプレフィックスを一覧にまとめます。
| プレフィックス | 説明 |
|---|---|
| pd | コアデータモデル |
| ad | 実装データモデル(行政) |
| fn | 実装データモデル(金融) |
| ed | 実装データモデル(教育) |
| be | 実装データモデル(防災) |
コアデータモデルで定義した型
コアデータモデルでは以下の四つ(ID、コード、役割、関連組織)について、情報を構造化された形で持てるようにしています。例えば、個人に紐付くIDの情報は「マイナンバー」、「社員番号」などの種別と、「12345-6789」、「22-0123」などの値が一対の組となっています。こういった組になっている情報をデータで表現可能にするため、以下の四つの型を定義しています。
ID情報型
事物に対して採番されたIDを記述するための型がID情報型です。「ID」と「ID種別」の組で構成されます。IDには「12345-6789」など実際の値が入力され、ID種別には「個人番号」などのID体系を特定するための情報が入力されます。JSON形式でID情報型を記述する場合、例えば以下のようになります。
例)JSON形式で表現する場合
{ "ID種別": "個人番号", "ID": "12345-6789" }
コード情報型
コードを記述するための型がコード情報型です。参照するコードの「コード種別」と、コードの値が入る「コード」の組で構成されます。コードにはコードの値の他、コードが示す値そのものを入力することもできます。
例)JSON形式で表現する場合
{ "コード種別": "公共測量標準図コード", "コード": "1110" }
役割関与情報型
続柄、保護者など、個人と個人、または法人と個人の関係性を記述するための型が役割関与情報型です。種別を表す「役割」と、その役割を担う個人を示す「関与者」の組で構成されます。役割にはコード情報型の参照が入力され、関与者には個人データモデルへの参照が入力されます。
関連組織情報型
子会社など、法人と法人の関係性を記述するための型が役割関与情報型です。種別を表す「役割」と、その役割を担う法人を示す「法人番号」の組で構成されます。役割にはコード情報型の参照が入力されます。
コアデータモデルの利用方法
データの設計時にコアデータモデルを参照する
コアデータモデルでは社会の基本要素となるいくつかの概念について、相互運用性を加味したデータの設計を行っています。行政または民間事業者で新しくデータを設計したり、既存のデータを他のデータと連携しやすい形に組み替えたりする場合に、これらコアデータモデルを参照することで以下のメリットを得られます。
-
データを設計するコストが低減できる
-
他のシステムやデータと連携しやすい形に設計できる
-
データが構造化され、メンテナンスしやすい状態を保てる
また、コアデータモデルに足りない項目や余分な項目は独自にカスタマイズすることができます。カスタマイズにあたって、相互運用性の観点から削るべきではない項目は必須項目として位置付けています。それ以外の項目は任意項目となるため、利用場面に応じて省略することが可能です。
例えば、ある行政のシステムで、登録した国民の情報を管理する必要がある場合、個人のコアデータモデルを参考にすることができます。個人のコアデータモデルではIDの他、氏名と氏名のカナ表記、性別、連絡先を必須項目としています。氏名をカナ表記込みでデータ化することで、後にアルファベット表記への変換が容易になります。また、連絡先を構造化したデータとして切り出すことで、連絡先の変更に対応しやすくなります。このように、相互運用性を確保した設計を行う上で、コアデータモデルは便利な参考情報として使うことができます。
データ項目の記述形式にコアデータパーツを参照する
コアデータパーツでは様々なデータ設計の際に登場する日付、住所、
電話番号などの項目について、具体的に推奨する記述形式を記載しています。これらを記述ルールとして採用することで、形式の揺れや誤記を防ぐことができます。また、同じルールを採用する他のシステムやデータとの連携が容易になります。
既存データの記述形式がコアデータパーツと異なる場合であっても、コンバーター等を介してコアデータパーツの記述形式と揃えることで、相互運用性を高めることができます。
GIFへの準拠とは
GIFの準拠のレベル規定
GIFの準拠の目的は、データ標準の準拠による相互運用性を指します。GIFのコアデータモデルは、データ標準として、項目のまとまりと項目の階層構造を定義し、コアデータパーツは、代表的な形式を共通形式として定義しています。データ標準の準拠による相互運用性を高めるためには、共通形式、項目の形式、項目のまとまり、項目の階層構造の観点でデータ標準に準拠する必要があります。
GIFでは、3つの観点でレベルを規定しています。
・GIF準拠LV1
コアデータパーツの共通形式を採用。
・GIF準拠LV2
コアデータモデルの項目の形式と項目のまとまりとコアデータパーツの共通形式を採用。
項目のまとまりとは、項目の階層構造が異なっていても、基礎項目の必須項目があることを指します。
・GIF準拠LV2s
GIF準拠LV2に項目の階層構造の観点が追加されたもの。
GIFのスキーマによる準拠の判断が可能となります。
相互運用性をデータ標準への準拠によって確保するためには、GIF準拠LV2以上推奨しています。
全体に関わる留意事項
氏名、法人名の漢字表記の扱い
氏名、法人名は、一般の情報機器では扱うことができないJIS X 0213で定められた範囲外の文字(いわゆる外字)で戸籍や登記に登録されていることがあります。これらは政府に登録された正規の表記ですが、既に社会保障・税番号制度の導入に伴い、マイナンバーカードに個人氏名の外字に対応する代替文字が導入されたり、法人番号公表サイトで法人名の代替文字が提供されたりしています。また、マイナンバーカードでは券面入力補助アプリにも代替文字が記録されています。従来の手続と同等の利便性を確保するために、行政サービスや他システム連携データでは、氏名、法人名に代替文字が活用されることがあります。
戸籍や商業登記に基づき登録された文字が法令等に基づき必要な場合には、既存のデータ項目に外字を入力するのではなく、一般の手続に使われる「氏名」の項目とは別項目の「戸籍氏名」を設けたり、商業登記名が必要なときには「法人名」と別項目の「登記名」を設けたりするなど、円滑な連携ができるように工夫が必要です。
氏名、法人名のヨミガナの扱い
氏名や法人名については、ヨミガナが存在しないことがあります。しかし、名簿等でのデータのソートは名称の五十音順に行われることが多く、ヨミガナがないと、データのソートや検索に不都合が生じます。
よって、手続では、固有名詞のデータにヨミガナを付与することを基本とします。ヨミガナを付与することでローマ字表記にすることも容易になります。
氏名、法人名、住所などのローマ字表記の扱い
氏名、法人名、住所などのローマ字表記については、パスポート等でヘボン式表記が定められているのと同じく、日本語を知らない英語話者にとって実際の発音を推測しやすいメリットがあるため、ヘボン式での記述を原則とします。
本社住所の扱い
本社住所は、商業登記した住所が正式なものです。一方で、変更登記が行われていない法人も多く、自治体による住居表示変更等も反映されていない場合があります。
ワンスオンリー実現の観点から、商業登記した住所を、その後の申請などで使うことが求められていますが、正確な連絡先として使用できない場合があるため、「登記住所」というデータ項目とは別に事業所名は「本社」、事業所住所は「本社住所」と記録できるようにするなどの工夫が必要です。登記変更を促すため申請のデータ項目に本社住所を追加することで、「登記住所」と「本社住所」が異なる場合に注意を促す運用も可能になります。
外字の扱い
氏名、法人名、地名等で外字の表示が必須である場合には、コンピュータで処理するデータ項目以外に、外字をイメージで保有する場合があります。その場合にも、データ項目は、JIS X 0213の範囲で運用することが望ましいです。範囲外の文字をデータとして使う場合には、連携システムや再利用時の影響評価を実施した上で判断する必要があります。
データやデータ項目名の表記に関する留意点
本書では、システム連携のためのデータモデルを示しています。画面や帳票等などユーザーインターフェイス部分ではデータ形式を変換して表示することがあります。
例えば、日付データはシステムには「2019-04-01」で格納し、入出力画面や帳票上では「2019年4月1日」に変換して表示する等、様式や手続等の要件に応じて変換を行います。
データ項目名も必要に応じて異なる表示をすることがあります。例えば、データ項目名として「氏名」がよく使われますが、入出力画面や帳票等では「お名前」と表示する場合などです。
国の名称とコードの扱い
個人や住所のデータモデルでは国の名称や国を表すコードを扱う項目が存在します。これらについては国際標準であるISO 3166-1およびJISX0304に従って管理します。コードで表す必要がある場合はアルファベット3文字(日本ならば「JPN」)で表すISO 3166-1 alpha-3での管理を標準とします。
性別のコードの扱い
個人のデータモデル等で性別をコードで管理する場合は、国際標準であるISO 5218に従って管理します。すなわち「0:不明」「1:男性」「2:女性」「9:その他」となります。ここでいう性別とは生物学的性差(sex)を差し、文化的社会的性差(gender)は別項目として管理します。
日時の扱い
日時の管理については国際標準であるISO 8601に従い、2022年3月31日であれば「2022-03-31」と管理します。時間と組み合わせて管理する場合は「2022-03-31T12:34:56」のように「T」で日付と時刻を接続します。日時の管理についてはコアモデルパーツ日付および時刻も参照してください。
付録
「2.2 コアデータモデルの全体構造」に記載したコアデータモデルのクラス図について、大きなサイズのものは別添の「430-1_DMD_クラス図_.pdf」を参照してください。
変更履歴
| 日付 | 変更位置 | 変更内容 |
|---|---|---|
| 2026年3月17日 | 全体 | プレフィックスの説明を追加 軽微な文章修正 |
| 2025年3月25日 | 全体 | データ項目の基礎項目と拡張項目の再定義 子育て支援情報、住所(アドレス) コード一覧、関連組織情報型の追加 GIFの準拠の追加 |
| 2022年9月12日 | P9 図2コアデータモデルの全体像 | 多目的トイレの呼称を国土交通省のガイドライン(建築物におけるバリアフリーについて)に従いバリアフリートイレに変更 |
| 2022年6月30日 | P7-9 | コアデータモデルにイベントを追加 |
| 2022年5月9日 | P7 | コアデータモデルに土地、建物、設備を追加 |
| 2022年3月31日 | - | 初版決定 |
https://joinup.ec.europa.eu/collection/semantic-interoperability-community-semic
デジタル社会推進実践ガイドブック DS-431
コアデータモデル解説書 個人
2026年(令和8年)10月06日
デジタル庁
[キーワード] 個人、データモデル、住民、社員、生徒 [概要] 個人の情報をシステム実装する際に参照すべきデータモデルについて解説するガイドブックです。このガイドに従いデータ設計を行うことで、同じ設計規則に従うシステム間、分野間でのデータ連携を容易かつ正確に行えるようになります。また、データ設計を実施するコストも削減することができます。 |
|---|
個人のデータモデル
個人の情報を記述する際のデータモデルです。行政組織が住民のデータを整備する場合の他、民間事業者や学校法人が社員や生徒、教員の情報を整備する場合などに活用されることを想定しています。氏名や連絡先などの基本的な情報は基礎項目とし、データの利用シーンに合わせた必須項目をパターン化しています。また、基礎項目以外の情報として拡張項目を用意しています。
必須項目以外は任意項目なので、用途に応じて基礎項目や拡張項目を選択、あるいは独自項目を追加するなどのカスタマイズを行って利用してください。
個人データモデルの項目
個人データモデルの基礎項目は表1、拡張項目は表2の通りです。基礎項目に対する必須項目のパターンについては「1.2必須項目パターン」を、英語名や記入例などを含む詳細については、別添の「438_コアデータモデル_DMD.xlsx」を参照してください。
表1 個人データモデルの基礎項目一覧
| 項目名 | 説明 |
|---|---|
| ID群 | 個人番号、教員番号など(①ID、②コード情報型でID種別とIDを格納、のいずれかを原則とする) |
| 氏 | 氏 |
| 名 | 名(ミドルネームを有している場合は、区切り文字として半角空白を使用した上でミドルネームを記載してもよい。例:ミドルネーム+区切り文字+名) |
| 氏(カナ) | 氏のカナ表記 |
| 名(カナ) | 名のカナ表記 |
| 氏(英字) | 氏のローマ字表記 |
| 名(英字) | 名のローマ字表記 |
| 氏名 | 氏名(氏、名のセット)、区切り文字は半角空白とする |
| 氏名(カナ) | 氏名(氏、名のセット)のカナ表記、区切り文字は半角空白とする |
| 氏名(英字) | 氏名(氏、名のセット)のローマ字表記 |
| 国籍 | 国籍名(①国コード、②国名、③コード情報型で国コードと国名を格納、のいずれかを原則とする) |
| 性別 | 性別名(性別については、①性別コード、②性別、③コード情報型で性別コードと性別を格納、のいずれかを原則とする) |
| 生年月日 | 生年月日 |
| 死亡年月日 | 死亡している場合、死亡年月日 |
| 備考 | その他特筆事項 |
| 住所 | 居住住所情報 |
| 連絡先情報 | 連絡先住所の情報 |
表2 個人データモデルの拡張項目一覧
| 項目名 | 説明 |
|---|---|
| ミドルネーム | ミドルネーム |
| ミドルネーム(カナ) | ミドルネームなどのカナ表記 |
| ミドルネーム(英字) | ミドルネームなどのローマ字表記 |
| 旧氏 | 旧氏 |
| 旧氏(カナ) | 旧氏のカナ表記 |
| 旧氏(英字) | 旧氏のローマ字表記 |
| 通称名 | 通称名 |
| 通称名(カナ) | 通称名のカナ表記 |
| 通称名(英字) | 通称名のローマ字表記 |
| 戸籍氏名 | 戸籍上の氏名表記 |
| 戸籍氏 | 戸籍上の氏 |
| 戸籍名 | 戸籍上の名 |
| 秘匿情報 | 秘匿事項(DV等) |
| 役割関与情報 | 委任先、保護者、続柄など |
| 住民登録住所 | 住民登録の住所 |
| 出生国 | 出生国名 |
| 年齢 | 記録時点の年齢 |
| 身長(cm) | 記録時点の身長(単位:cm) |
| 体重(kg) | 記録時点の体重(単位:kg) |
| 機能支援の要否 | 身体障碍や車椅子など、何らかの補助が必要かどうか |
| 機能支援の種別 | 視覚支援、聴覚支援、移動支援など |
| 世帯主 | 世帯主の情報 |
| 既婚・未婚 | 既婚か未婚の種別 |
| 配偶者の有無 | 配偶者の有無 |
| 子の有無 | 子の情報(子の有無) |
| 学生 | 学生かどうか |
| 収入の有無 | 記録時点の収入の有無 |
役割関与情報について
教育機関における保護者など、個人に紐づく別の個人についての情報は「役割関与情報」に記述します。ここで個人と個人の関係性と、指し示す個人(保護者であれば両親など)の情報を記述します。記述のフォーマットの詳細はDMDの役割関与情報型を参照してください。
国の名称とコードの扱い
個人や住所のデータモデルでは国の名称や国を表すコードを扱う項目が存在します。これらについては国際標準であるISO 3166-1及びJISX0304に従って管理します。コードで表す必要がある場合はアルファベット3文字(日本ならば「JPN」)で表すISO 3166-1 alpha-3での管理を標準とします。
性別のコードの扱い
個人のデータモデル等で性別をコードで管理する場合は、国際標準であるISO 5218に従って管理します。すなわち「0:不明」「1:男性」「2:女性」「9:その他」となります。ここでいう性別とは生物学的性差(sex)を指し、文化的社会的性差(gender)は別項目として管理します。
必須項目のパターン
基礎項目のうち、必須とする項目のパターンは表3の通りです。データの利用目的に合わせてパターンを選択して利用してください。
表3 個人データモデルの必須項目のパターン
| 項目名 | 必須 パターン1 推奨:高 |
必須 パターン2 推奨:中 |
必須 パターン3 推奨:中 |
|---|---|---|---|
| ID群 | 必 | 必 | |
| 氏 | 必 | 必 | 必 |
| 名 | 必 | 必 | 必 |
| 氏(カナ) | 必 | 必 | 必 |
| 名(カナ) | 必 | 必 | 必 |
| 氏(英字) | 必 | ||
| 名(英字) | 必 | ||
| 氏名 | |||
| 氏名(カナ) | |||
| 氏名(英字) | |||
| 国籍 | |||
| 性別 | 必 | ||
| 生年月日 | 必 | ||
| 死亡年月日 | |||
| 備考 | |||
| 住所 | 必 | ||
| 連絡先情報 |
変更履歴
改定年月日 |
改定箇所 |
改定内容 |
|---|---|---|
2026年10月06日 |
表1 |
個人データモデルのID群、国籍、性別の記載パターンを追加 |
2026年3月17日 |
全体 |
軽微な文章修正 |
2025年3月25日 |
全体 |
データ項目を基礎項目と拡張項目として再定義 個人連絡先の削除 |
2023年1月12日 |
P3 |
個人データモデルの項目に戸籍氏、戸籍名を追加 |
2022年3月31日 |
- |
初版決定 |
デジタル社会推進実践ガイドブック DS-432
コアデータモデル解説書 連絡先
2025年(令和7年)3月25日
デジタル庁
[キーワード] 連絡先、データモデル、電話番号、WEBフォーム、SNS [概要] 連絡先の情報をシステム実装する際に参照すべきデータモデルについて解説するガイドブックです。このガイドに従いデータ設計を行うことで、同じ設計規則に従うシステム間、分野間でのデータ連携を容易かつ正確に行えるようになります。また、データ設計を実施するコストも削減することができます。 |
|---|
連絡先のデータモデル
個人や法人、施設の連絡先を記述する際のデータモデルです。
連絡先名称や連絡先住所などの基本的な情報を基礎項目として用意しています。用途に応じて基礎項目を選択し独自項目に連絡先部署等を追加するなどのカスタマイズを行って利用してください。
連絡先データモデルの項目
連絡先データモデルの基礎項目は表1の通りです。英語名や記入例などを含む詳細については、別添の「438_コアデータモデル_DMD.xlsx」を参照してください。
表1 連絡先データモデルの基礎項目一覧
| 必須項目 | 項目名 | 説明 |
|---|---|---|
| 連絡先名称 | 連絡先名称 | |
| 連絡先用途 | 連絡先の目的・地域情報等の用途を記載 | |
| 連絡先電話番号 | 電話番号、携帯電話番号、内線番号 | |
| 連絡先メールアドレス | 連絡先メールアドレス | |
| 連絡先URL | 連絡先がWebの場合のURL | |
| 連絡先SNS | SNSなどの連絡手段がある場合に「サービス名称:(コロン) ユニークID」を記載 | |
| 連絡先住所 | 連絡先住所の情報 | |
| 連絡先備考 | 連絡先に関する備考を記載 |
変更履歴
| 改定年月日 | 改定箇所 | 改定内容 |
|---|---|---|
| 2025年3月25日 | 全体 | データ項目を基礎項目と拡張項目として再定義 連絡先を拡張したデータモデルについて削除 |
| 2022年3月31日 | - | 初版決定 |
デジタル社会推進実践ガイドブック DS-433
コアデータモデル解説書 住所
2026年(令和8年)3月17日
デジタル庁
[キーワード] 住所、都道府県、市区町村、町字、アドレス・ベース・レジストリ、データモデル [概要] 住所の情報をシステム実装する際に参照すべきデータモデルについて解説するガイドブックです。このガイドに従いデータ設計を行うことで、同じ設計規則に従うシステム間、分野間でのデータ連携を容易かつ正確に行えるようになります。また、データ設計を実施するコストも削減することができます。 |
|---|
住所のデータモデル
国内の住所を記述する場合のデータモデルです。
住所については令和4年より一元的な住所情報の管理を目的としたアドレス・ベース・レジストリがデジタル庁によって整備され、令和5年度(2023年度)末から公開を開始しています。この取り組みにより住所情報の町字レベルでの統一・整備が行われることから、住所のデータモデルもアドレス・ベース・レジストリとの相互運用性の観点に基づいた検討を行っており、アドレス・ベース・レジストリと紐づけることのできる町字IDを必須項目とすることで、定義や表記揺れがなく、全国で統一された住所情報との連携を可能とします。そのため、住所の情報を新たに設計する場合は、アドレス・ベース・レジストリと相互運用できる町字IDの採用を強く推奨します。全国地方公共団体コードと町字IDを組み合わせることで都道府県、市区町村、町字までを特定することができ、残りの番地以下の情報および建物名等を組み合わせて住所情報を構造的に保存することができます。
既に住所のデータを持っている場合、連結表記に既存のデータを保存した上で、それとは別に住所データを分解して保存することを推奨します。都道府県、市区町村、町字など、住所情報を分解して保存することで相互運用性を確保し、後々にアドレス・ベース・レジストリとのマッチングを行いやすくします。住所情報を個々の項目に分割するツール(コンバーター)については、デジタル庁にてARBジオコーダーが提供されております。
(https://lp.geocoder.address-br.digital.go.jp/)
住所情報の構造の詳細については「442_コアデータパーツ_住所・所在地(アドレス)」の解説もあわせて参照してください。
これらのことを踏まえ、本データモデルでは全国地方公共団体コードや町字IDなどの基本的な情報を基礎項目とし、データの利用シーンに合わせた必須項目をパターン化しています。また、基礎項目以外の情報として拡張項目を用意しています。
必須項目以外は任意項目なので、用途に応じて基礎項目や拡張項目を選択、あるいは独自項目を追加するなどのカスタマイズを行って利用してください。
住所データモデルの項目
住所データモデルの基礎項目は表1、拡張項目は表2の通りです。基礎項目に対する必須項目のパターンについては「1.2必須項目パターン」を、英語名や記入例などを含む詳細については、別添の「438_コアデータモデル_DMD.xlsx」を参照してください。
表1 住所データモデルの基礎項目一覧
| 項目名 | 説明 |
|---|---|
| 全国地方公共団体コード | 全国地方公共団体コード(6桁、都道府県と市区町村まで含む)を記載。 |
| 町字ID | アドレスベースレジストリの町字IDを記載。 |
| 都道府県 | 都道府県を記載。 |
| 市区町村(郡) | 市区町村(郡名および政令市区名を含む)記載。 |
| 町字 | 町字を記載。 |
| 番地以下 | 番地以下(街区符号、住居番号または地番)を記載。 |
| 建物名等(方書) | 建物名、部屋番号、フロア名などを記載。 |
| 連結表記 | 都道府県から建物名まで連結して記載。 |
| 郵便番号 | 郵便番号 |
| 国 | 国の情報を記載。 |
| 町字以下 | 町字以下(町字、街区符号、住居番号または地番)を記載。 |
表2 住所データモデルの拡張項目
| 項目名 | 説明 |
|---|---|
| 都道府県(カナ) | 都道府県の読み仮名を記載。 |
| 市区町村(郡)(カナ) | 市区町村(郡名および政令市区名を含む)の読み仮名を記載。 |
| 町字(カナ) | 町字の読み仮名を記載。 |
| 番地以下(カナ) | 番地以下(街区符号、住居番号または地番)の読み仮名を記載。 |
| 建物名等(方書)(カナ) | 建物名、部屋番号、フロア名などの読み仮名を記載。 |
| 連結表記(カナ) | 都道府県(カナ)から建物名等(方書)(カナ)まで連結して記載。 |
| 都道府県(英字) | 都道府県の英語表記を記載。 |
| 市区町村(郡)(英字) | 市区町村(郡名および政令市区名を含む)の英語表記を記載。 |
| 町字(英字) | 町字の英語表記を記載。 |
| 番地以下(英字) | 番地以下(街区符号、住居番号または地番)の英語表記を記載。 |
| 建物名等(方書)(英字) | 建物名、部屋番号、フロア名などの英語表記を記載。 |
| 連結表記(英字) | 都道府県(英字)から建物名等(方書)(英字)まで基本形の順で連結して記載。 |
| 代表点の緯度 | 代表点の緯度を記載。 |
| 代表点の経度 | 代表点の経度を記載。 |
| 座標参照系 | 座標参照系(旧日本測地系、世界測地系などの種別)を記載。 |
| 座標参照系コード | 座標参照系コード |
| 郡 | 郡名を記載。 |
| 市区町村 | 市区町村名を記載。 |
| 政令市区 | 政令市区名を記載。 |
| 大字・町 | 大字および町を記載。 |
| 丁目 | 丁目を記載。 |
| 小字 | 小字および番地補足(イ・甲・北など)を記載。 |
| 住居表示フラグ | 住居表示フラグを記載。 |
| 街区符号 | 街区符号を記載。 |
| 住居番号 | 住居番号を記載。 |
| 地番 | 地番を記載。 |
| 建物名 | 建物名を記載。 |
必須項目のパターン
基礎項目のうち、必須とする項目のパターンは表3の通りです。データの利用目的に合わせてパターンを選択して利用してください。
表3 住所データモデルの必須項目のパターン
| 項目名 | 必須 パターン1 推奨:高 |
必須 パターン2 推奨:高 |
必須 パターン3 推奨:中 |
必須 パターン4 推奨:中 |
必須 パターン5 推奨:低 |
必須 パターン6 推奨:低 |
必須 パターン7 推奨:国外 |
|---|---|---|---|---|---|---|---|
| 全国地方公共団体コード | 必 | 必 | 必 | 必 | 必 | ||
| 町字ID | 必 | 必 | 必 | ||||
| 都道府県 | 必 | 必 | 必 | 必 | |||
| 市区町村(郡) | 必 | 必 | 必 | 必 | |||
| 町字 | 必 | 必 | 必 | 必 | |||
| 番地以下 | 必 | 必 | 必 | 必 | |||
| 建物名等(方書) | 必 | 必 | 必 | 必 | 必 | 必 | |
| 連結表記 | 必 | 必 | 必 | 必 | 必 | 必 | 必 |
| 郵便番号 | 必 | ||||||
| 国 | 必 | ||||||
| 町字以下 | 必 |
住所文字列の分解と連結表記
住所文字列は以下の5つの要素に分解して記述します。
-
都道府県
-
市区町村
-
町字
-
番地以下
-
建物名等(方書)
実際の住所を分解した例は以下のようになります。
-
都道府県 ........ 東京都
-
市区町村 ........ 千代田区
-
町字 ............ 紀尾井町
-
番地以下......... 1番2号
-
建物名等(方書) .. ガーデンテラス紀尾井町19F
一方で既存の住所データは一つの文字列として格納されていることが多いため、「連結表記」項目に元の文字列を併記することを推奨しています。
住所のデータ形式については「442_コアデータパーツ_住所・所在地(アドレス)」もあわせて参照してください。
座標情報を用いた位置情報中心のデータ構成
位置情報サービスやIoTデバイス、災害情報管理など、地理的な位置の特定が主目的となるアプリケーションにおいては、連結表記と位置情報(座標情報)を中心としたシンプルなデータ構成も検討できます。
この構成は、位置情報(座標情報)を主軸とするシステムに適しています。全国地方公共団体コードや町字IDは推奨項目としていますが、座標情報から行政ポリゴンを用いた空間検索により全国地方公共団体コードや町字IDを導出することが可能となります。
使用例を以下に記載します。
・連結表記:人が場所を特定、理解、伝達するために使用する情報
・位置情報:システムが位置を特定、処理するために使用する情報
| 項目名 | 必須 | 推奨 | 任意 | 備考 |
|---|---|---|---|---|
| 全国地方公共団体コード | ● | |||
| 町字ID | ● | |||
| 都道府県 | ● | |||
| 市区町村(郡) | ● | |||
| 町字 | ● | |||
| 番地以下 | ● | |||
| 建物名等(方書) | ● | |||
| 連結表記 | ● | |||
| 位置情報 | ● | 緯度経度、(座標参照系or座標参照系コード) |
改訂履歴
| 改定年月日 | 改定箇所 | 改定内容 |
|---|---|---|
| 2026年3月17日 | 1. 1.4 |
1.ジオコーダーの記載事項を変更 1.4 座標情報を用いた位置情報中心のデータ構成を追加 |
| 2025年3月25日 | 全体 | データ項目を基礎項目と拡張項目として再定義 必須項目のパターン化を追加 住所文字列の分解と連結表記の変更 |
| 2023年3月31日 | P3 表1住所データモデルの項目一覧 | 座標参照系コードの説明、「座標参照系コードの記載」ほかと表現を統一 |
| 2022年3月31日 | - | 初版決定 |
デジタル社会推進実践ガイドブック DS-434
コアデータモデル解説書 法人
2025年(令和7年)3月25日
デジタル庁
[キーワード] 法人、データモデル、事業所、法人番号 [概要] 法人の情報をシステム実装する際に参照すべきデータモデルについて解説するガイドブックです。このガイドに従いデータ設計を行うことで、同じ設計規則に従うシステム間、分野間でのデータ連携を容易かつ正確に行えるようになります。また、データ設計を実施するコストも削減することができます。 |
|---|
法人のデータモデル
事業者などの法人の情報を記述するためのデータモデルです。行政で法人の情報を扱う場合の他、民間事業者が取引先などの情報を扱う場合に活用されることを想定しています。国税庁が指定する法人番号や名称などの基本的な情報は基礎項目とし、データの利用シーンに合わせた必須項目をパターン化しています。また、基礎項目以外の情報として拡張項目を用意しています。
必須項目以外は任意項目なので、用途に応じて基礎項目や拡張項目を選択、あるいは独自項目を追加するなどのカスタマイズを行って利用してください。
法人データモデルの項目
法人データモデルの基礎項目は表1、拡張項目は表2の通りです。基礎項目に対する必須項目のパターンについては「1.2必須項目パターン」を、英語名や記入例などを含む詳細については、別添の「438_コアデータモデル_DMD.xlsx」を参照してください。
表1 法人データモデルの基礎項目一覧
| 項目名 | 説明 |
|---|---|
| 法人番号 | 法人番号(13桁)を記載。法人番号が指定されている場合は必須。 |
| ID群 | 法人に付与した一意のIDを記載。インボイス登録番号(登録番号)が指定されている場合は必須。 |
| 商号または名称 | 商号または名称を記載。英字は全角英字とする。 |
| 商号または名称(カナ) | 名称をカナで記載。 |
| 商号または名称(英字) | 名称を英語で記載。 |
| 組織種別 | 組織種別(株式会社、有限会社、合名会社、合資会社、合同会社等)を記載。 |
| 通称 | 通称や略称アルファベットを記載。 |
| 事業活動状況 | 活動状況(倒産、破産、休眠、休業、廃業等)を記載。 |
| 説明 | 説明を記載 |
| WebサイトURL | 法人に関する情報源を示すWebサイトURLを記載。 |
| 社員数 | 社員数(役員数を含む)を記載。 |
| 代表者 | 代表者の情報を記載。 |
| 代表者役職名 | 代表者役職名を記載。 |
| 設立年月日 | 設立日を記載。 |
| 事業種目 | 事業種目(日本標準産業分類)を記載。 |
| 登記住所 | 登記住所を記載。 |
| 事業所情報 | 事業所情報を記載。 |
| 連絡先情報 | 連絡先情報を記載。 |
表2 法人データモデルの拡張項目一覧
| 項目名 | 説明 |
|---|---|
| 組織種別位置(前株、後株) | 組織種別(株式会社等)を法人名の前後のどちらに付与するかを記載。 |
| 関連組織 | 関連組織(子会社、提携先等)を記載。 |
| 正社員数 | 正社員数を記載。 |
| 従業員数 | 従業員数を記載。 |
| 地物(関連施設) | 法人に関連する地物(関連施設)を記載。 |
| 創業年 | 創業年を記載。 |
| 事業年度開始日 | 事業年度の開始日を記載。 |
| 資本金(円) | 資本金(単位:円)を記載。 |
必須項目のパターン
基礎項目のうち、必須とする項目のパターンは表3の通りです。データの利用目的に合わせて選択して利用してください。
表3 法人データモデルの必須項目のパターン
| 項目名 | 必須 パターン1 推奨:高 |
必須 パターン2 推奨:中 |
必須 パターン3 推奨:中 |
|---|---|---|---|
| 法人番号 | 必 | 必 | |
| ID群 | 必 | 必 | |
| 商号または名称 | 必 | 必 | 必 |
| 商号または名称(カナ) | 必 | 必 | 必 |
| 商号または名称(英字) | |||
| 組織種別 | 必 | 必 | 必 |
| 通称 | |||
| 事業活動状況 | |||
| 説明 | |||
| WebサイトURL | |||
| 社員数 | |||
| 代表者 | |||
| 代表者役職名 | |||
| 設立年月日 | |||
| 事業種目 | |||
| 登記住所 | |||
| 事業所情報 | |||
| 連絡先情報 | 必 | 必 | 必 |
事業所データモデルの項目
法人に紐付く施設としての事業所情報を記述するためのデータモデルです。
法人内で利用される管理のためのIDや名称などの基本的な情報は基礎項目としています。また、基礎項目以外の情報として拡張項目を用意しています。
事業所データモデルの基礎項目は表4、拡張項目は表5の通りです。事業所データモデルには必須項目はないため、用途に応じて基礎項目や拡張項目を選択、あるいは独自項目を追加するなどのカスタマイズを行って利用してください。
表4 事業所データモデルの基礎項目一覧
| 必須項目 | 項目名 | 説明 |
|---|---|---|
| ID | 事業所のIDを記載。 | |
| 必 | 名称 | 事業所の名称を記載。 |
| 事業所住所 | 事業所の住所を記載。 | |
| 説明 | 事業所の説明を記載。 |
表5 事業所データモデルの拡張項目一覧
| 項目名 | 説明 |
|---|---|
| 関連法人番号 | 関連する法人番号を記載。 |
変更履歴
| 2025年3月25日 | 全体 | データ項目を基礎項目と拡張項目として再定義 法人連絡先の削除 |
|---|---|---|
| 2022年3月31日 | - | 初版決定 |
デジタル社会推進実践ガイドブック DS-435
コアデータモデル解説書 施設
2025年(令和7年)3月25日
デジタル庁
[キーワード] 施設、データモデル、観光、教育、防災 [概要] 施設の情報をシステム実装する際に参照すべきデータモデルについて解説するガイドブックです。このガイドに従いデータ設計を行うことで、同じ設計規則に従うシステム間、分野間でのデータ連携を容易かつ正確に行えるようになります。また、データ設計を実施するコストも削減することができます。 |
|---|
施設のデータモデル
行政が管理する施設の情報を記述するためのデータモデルです。カスタマイズすることで民間事業者のサービス施設や教育施設、防災施設、観光施設などにも転用することができるため、幅広い分野で施設の情報を扱う場合に活用されることを想定しています。施設の名称や住所などの基本的な情報は基礎項目とし、データの利用シーンに合わせた必須項目をパターン化しています。また、基礎項目以外の情報として拡張項目を用意しています。
必須項目以外は任意項目なので、用途に応じて基礎項目や拡張項目を選択、あるいは独自項目を追加するなどのカスタマイズを行って利用してください。
施設データモデルの項目
施設データモデルの基礎項目は表1、拡張項目は表2の通りです。英語名や記入例などを含む詳細については、別添の「438_コアデータモデル_DMD.xlsx」を参照してください。
表1 施設データモデルの基礎項目一覧
| 必須項目 | 項目名 | 説明 |
|---|---|---|
| 必 | ID | 機械的に採番された施設を一意に識別するID。施設単位ごとに付番する |
| 種別情報 | 地理的目標物分類コード等の種別情報 | |
| 必 | 名称 | 施設の名称 |
| 必 | 名称(カナ) | 施設のカナ表記 |
| 名称(英字) | 施設の英語名またはローマ字表記 | |
| 通称 | 施設に通称がある場合に記入 | |
| 説明 | 施設情報として公開可能な詳細情報 | |
| 必 | 施設住所 | 住所情報 |
| アクセス方法 | 公共交通や車でのアクセス方法を記載 | |
| 駐車場有無 | 駐車場の有無 | |
| 連絡先情報 | 連絡先の情報 |
表2 施設データモデルの拡張項目一覧
| 項目名 | 説明 |
|---|---|
| 概要 | 施設情報として公開可能なリード文。概要情報 |
| 関連施設 | 提携している他施設の情報など |
| 状態 | 「閉館中」、「営業中」などのステータス |
| 防災情報 | 災害発生時の主な用途 |
| 設備情報 | 施設内に併設されている設備の情報 |
| 利用可能曜日 | 施設を利用できる曜日 |
| 開始時刻 | 施設を利用開始できる時間 |
| 終了時刻 | 施設の利用終了時間 |
| 利用可能日時説明 | 定型で表せない施設の利用日時情報 |
| 利用可能日時式 | 「441_コアデータパーツ_日付時刻」の表記で日時を表現 |
| 一般利用可否 | 一般利用者が利用出来るかどうかの可否 |
| 料金有無 | 「有料」、「無料」の区分 |
| 基準料金 | 施設利用に必要な各種料金の基準となる日本円で記載(1円単位) |
| 料金説明 | 料金の備考。例: 1グループ1000円など |
| 決済種別 | 現金、クレジットカード、電子マネーなど |
| 収容人数 | 収容人数 |
| 駐車場情報 | 駐車スペースについて記入 |
| 駐車場料金 | 駐車場の料金の有料/無料種別 |
| サービス担当区域の都道府県コード | サービス担当区域の都道府県コード(今後構造化検討予定) |
| サービス担当区域の市区町村コード | サービス担当区域の市区町村コード(今後構造化検討予定) |
| サービス担当区域の町丁字 | サービス担当区域の町丁字(今後構造化検討予定) |
| サービス担当区域のポリゴン | サービス担当区域を表すポリゴン情報へのリンク(今後構造化検討予定) |
| サービス担当区域の備考 | サービス担当区域の備考(今後構造化検討予定) |
| アクセシビリティ情報 | アクセシビリティ情報 |
| 子供預かり情報 | 子供預かり情報 |
種別情報(地理的目標物分類コード:POIコード)について
種別情報にはPOIコード等を設定します。POIコードは観光施設、公共施設など地理的目標物に対する分類コードです。無意コード 4 桁のコード体系となっています。
分類対象の選択
分類にあたっては以下を参照して作成されています。
-
国土地理院 電子国土基本図 地物種別コード
-
国土交通省 都市計画 GIS 地物一覧
-
国土交通省 国土数値情報
-
国土地理院 公共測量標準図式 数値地形図データ取得分類コード表
-
観光庁 観光入込客統計に関する共通基準 観光地点等分類コード
-
観光庁 観光立国実現に向けた多言語対応の改善・強化のためのガイドライン
-
文部科学省 体育・スポーツ施設現況調査 施設種別の定義
-
東京都 国内外旅行者のためのわかりやすい案内サイン標準化指針【東京都版対訳表】
-
OpenStreetMap Wiki, JA:Map Features(2017-11-28)
-
schema.org(2017-11-28)
-
日本標準産業分類
分類項目名
各項目の分類項目名は、既存の分類項目における定義等を踏まえ、一般的な
呼称を選定しています。商業施設に関しては、店の呼称は「-屋」「-店」が混在しています。これは、一意に分類項目を決めるため一般的な呼称を使用しているだけであり、「-屋」「-店」との呼称自体が区別やレベル感を表すものではありません。また、グローバルな互換性をとるため、日本には存在しない施設等にもコードを付与しています。
複合施設等の扱い
複合施設は、その他を選択するか最も近いコードを使用することを推奨します。その他の選択肢として、内部施設について別途項目を立てて記述する方法、コードを列挙する方法等があります。
地点ではないエリアや点ではない対象物に対する考え方
地形に関しては、特定の位置を示すものではなく、範囲を示す対象物であることがありますが、広域な目標物とする場合があるため、コード表に含まれています。
また、遊漁船、ロープウェイ等の場合、位置は出発点を示している場合があります。
サービス担当区域について
サービス担当区域の情報はハローワークなど、その公共施設が所管する地理的範囲が定められている場合に使用します。住所情報だけで地理的範囲を定められない場合は、地図上に重ねられる境界ポリゴン情報を参照するURLを「ポリゴン」項目に記述します。
変更履歴
| 改定年月日 | 改定箇所 | 改定内容 |
|---|---|---|
| 2025年3月25日 | 全体 | データ項目を基礎項目と拡張項目として再定義 POIコードの説明を種別情報の説明として変更 |
| 2022年3月31日 | - | 初版決定 |
デジタル社会推進実践ガイドブック DS-436
コアデータモデル解説書 アクセシビリティ
2026年(令和8年)3月17日
デジタル庁
[キーワード] アクセシビリティ、データモデル、バリアフリー、介助 [概要] 施設やイベント等に付随するアクセシビリティに関する情報をシステム実装する際に参照すべきデータモデルについて解説するガイドブックです。このガイドに従いデータ設計を行うことで、同じ設計規則に従うシステム間、分野間でのデータ連携を容易かつ正確に行えるようになります。また、データ設計を実施するコストも削減することができます。 |
|---|
アクセシビリティのデータモデル
施設やイベント開催時に、利用者にバリアフリーの状況や対応可能な介助の種類など、要配慮者に関するアクセシビリティや、子育て支援に関するアクセシビリティ情報を伝えるときのデータモデルです。車椅子貸出やバリアフリートイレなどの有無情報を基礎項目として用意しており、アクセシビリティ情報を付加したい他のデータモデルとあわせて利用することを想定しています。
各項目は基本的に有無コードの値をとります。文書で詳細を伝えたい場合は備考にその内容を記述することを想定しています。
すべて任意項目なので、用途に応じて項目を選択、あるいは独自項目を追加するなどのカスタマイズを行って利用してください。
アクセシビリティデータモデルの項目
アクセシビリティデータモデルの基礎項目は表1の通りです。英語名や記入例などを含む詳細については、別添の「438_コアデータモデル_DMD.xlsx」を参照してください。
表1 アクセシビリティデータモデルの基礎項目一覧
| 必須項目 | 項目名 | 説明 |
|---|---|---|
| 車椅子可 | 車椅子の使用可否を記載。 | |
| 車椅子貸出 | 車椅子貸出の有無を記載。 | |
| ツエ貸出 | ツエ貸出の有無を記載。 | |
| バリアフリートイレ | バリアフリートイレの有無を記載。 | |
| スロープ、エレベータ、エスカレータ | スロープ、エレベータ、エスカレータの有無を記載。 | |
| 点字ブロック等の移動支援 | 点字ブロック等の移動支援の有無を記載。 | |
| 点字や読上による支援 | 点字や読上による支援の有無を記載。 | |
| 盲導犬・介助犬・聴導犬同伴 | 盲導犬・介助犬・聴導犬などの同伴可の有無を記載。 | |
| 字幕 | 字幕の有無を記載。 | |
| 筆談対応 | 筆談対応の有無を記載。 | |
| 優先駐車場 | 優先駐車場の有無を記載。 | |
| オストメイト対応トイレ | オストメイト対応トイレの有無を記載。 | |
| 子供トイレ | 子供トイレの有無を記載。 | |
| 授乳室 | 授乳室の有無を記載。 | |
| おむつ替えコーナー | おむつ替えコーナーの有無を記載。 | |
| 飲食可否 | 乳幼児や要介護者等に飲食させることができるかどうかの情報を記載。 | |
| ベビーカー貸出 | ベビーカーの貸し出しの有無を記載。 | |
| ベビーカー利用可 | ベビーカーの利用可の有無を記載。 | |
| 備考 | その他アクセシビリティ事項を記載。 |
変更履歴
| 改定年月日 | 改定箇所 | 改定内容 |
|---|---|---|
| 2026年3月17日 | 全体 | 軽微な文章修正 |
| 2025年3月25日 | 全体 | データ項目を基礎項目として再定義 |
| 2023年9月12日 | P2 1.1 アクセシビリティデータモデルの項目 | 多目的トイレの呼称を国土交通省のガイドライン(建築物におけるバリアフリーについて)に従いバリアフリートイレに変更 |
| 2022年3月31日 | - | 初版決定 |
デジタル社会推進実践ガイドブック DS-437
コアデータモデル解説書 子供預かり情報
2026年(令和8年)3月17日
デジタル庁
[キーワード] 子供預かり情報、データモデル、子供預かり [概要] 施設やイベント等に付随する子供預かりに関する情報をシステム実装する際に参照すべきデータモデルについて解説するガイドブックです。このガイドに従いデータ設計を行うことで、同じ設計規則に従うシステム間、分野間でのデータ連携を容易かつ正確に行えるようになります。また、データ設計を実施するコストも削減することができます。 |
|---|
子供預かり情報のデータモデル
施設やイベント開催時に、利用者に子供預かり施設の情報を伝えるときのデータモデルです。情報を付加したい他のデータモデルとあわせて利用することを想定しています。料金有無や最小年齢、最大年齢などの基本的な情報は基礎項目とし、基礎項目の中で必ず選択していただく項目を必須項目としています。また、基礎項目以外の情報として拡張項目を用意しています。
必須項目以外は任意項目なので、用途に応じて基礎項目や拡張項目を選択、あるいは独自項目を追加するなどのカスタマイズを行って利用してください。
子供預かり情報データモデルの項目
子供預かり情報データモデルの基礎項目は表1の通りです。英語名や記入例などを含む詳細については、別添の「438_コアデータモデル_DMD.xlsx」を参照してください。
表1 子供預かり情報データモデルの基礎項目一覧
| 必須項目 | 項目名 | 説明 |
|---|---|---|
| 必 | 料金有無 | 料金の種別 |
| 料金説明 | 料金の説明 | |
| 最小年齢 | 参加可能年齢(下限) | |
| 最小月齢 | 参加可能月齢 | |
| 最大年齢 | 参加可能年齢(上限) | |
| 開所時間 | 対応時間 | |
| 閉所時間 | 対応時間 | |
| 備考 | その他子育て支援系項目 |
表2 子供預かり情報データモデルの拡張項目一覧
| 項目名 | 説明 |
|---|---|
| 料金情報 | 有料の場合の料金 |
変更履歴
| 改定年月日 | 改定箇所 | 改定内容 |
|---|---|---|
| 2026年3月17日 | 全体 | 軽微な文章修正 |
| 2025年3月25日 | 全体 | タイトルを「子供預かり情報」に変更 データ項目を基礎項目と拡張項目として再定義 |
| 2022年3月31日 | - | 初版決定 |
デジタル社会推進実践ガイドブック DS-438-2
データ項目辞書(β版)
2026年(令和8年)3月17日
デジタル庁
〔キーワード〕 データ項目辞書、データ連携、相互運用性、データモデル、概念定義 〔概要〕 行政のデジタル化に伴いデータ相互利活用が増加する中、同一概念でも異なる用語や基準が用いられることで、データ連携に支障が生じています。本書は、データ項目の名前と意味を定義する「データ項目辞書」を提供し、組織間の共通理解を実現します。これにより意味のずれを防ぎ、データ連携やシステム開発の効率化を図ります。GIFコアデータモデルに対応したデータ項目辞書を提供します。 |
|---|
目次
概要
背景
行政のデジタル化が進展する中、府省庁や地方公共団体の間でデータを相互に利活用する機会が増加しています。しかし、作成者が異なるデータは、同一の意味(概念)を持つ情報であっても、個々のデータの中で用いられる用語や項目名として違う言葉(ラベル)が割り当てられていることがあります。例えば、「電力」に関連する概念を表す際に、「定格出力」「消費電力」「電力量」など様々な用語が使用され、それぞれが異なる意味を持つのか同じ意味を持つのかが判別できません。また、「社員数」のカウント基準においても、役員やパート・アルバイトを含めるのか等、データ作成者ごとに異なる基準が用いられ、データを活用した分析や利活用に対して問題を引き起こすことがあります。このような不整合を解決するには、もともとのデータがもつ意味を判別するための仕組みが必要です。
政府相互運用性フレームワーク(GIF: Government Interoperability Framework)は、データモデル等を提供していますが、個々のデータ項目の意味を体系的に整理する枠組みが十分に整備されていない状況にあります。
課題
データ項目の意味(概念)と、その項目が取り得る具体的な値の範囲が明確に区別されていないため、同じ用語でも異なる基準で運用されていることが見過ごされています。また、データ項目の定義が各システムの設計書に散在しており、体系的に検索・参照できる仕組みが不足しているため、既存の定義を発見して再利用することが難しく、類似したデータ項目が重複して定義される非効率が生じています。さらに、人が理解できる用語定義と、機械が処理できる形式的な記述を統合的に管理する仕組みが整備されていないため、データ項目の意味を人と機械の双方が正しく解釈し、自動的に連携処理を行うことができません。
これらの課題により、データ項目の意味の不整合が解消されず、データ連携のコストが増大し、データを活用した分析や利活用に支障をきたしています。
目的
本書は、データ連携として、データ項目の意味を明確かつ一貫性のある形で定義する「データ項目辞書」を提供することを目的としています。組織内外で再利用するデータ項目について、その名前と意味を人が読んで理解できる形で定めたデータ項目辞書を提供します。データ項目が「何を意味するのか」という概念と、「どのような値を取るのか」という具体的な値の範囲を分けて定義することで、意味の理解と実際の使い方を別々に考えられるようにします。
これにより、組織間でデータ項目の意味を共通に理解できるようになり、データを交換する際の意味のずれを防ぐことができます。また、既に定義された標準を再利用することで、システム開発やデータ設計の手間を減らし、効率を高めることができます。
概要
本書は、GIFのコアデータモデルで定義している項目に対して「データ項目辞書(コアデータモデル)」を提供します。
本書について
対象範囲と前提
本書が対象とするデータ項目は、行政機関が広く利用する基本的なもの(コアデータモデル)であり、具体的には個人、法人、住所、連絡先、施設、建物、設備、土地、イベント、子供預かり情報等のエンティティに関するデータ項目を定義します。業務固有のデータ項目については、本書の定義を参考に、各組織が独自に定義することを想定しています。
なお、本書のデータ項目定義は関連する法令・制度を参照していますが、法令解釈や制度運用を規定するものではありません。法的な解釈や具体的な運用については、各法令の所管府省庁の定める規則・通達等に従うものとします。
本書では、コアデータモデルの構成のうち基礎項目のみ記載しています。また、記載項目は、「項目名」、「定義」、「概念定義域」「補足」としており、説明の中で実装時に定義すべき事項(値域、表記規則等)についてガイドを示しています。具体的な「値域(許容値、データ型、形式等)」は、実装環境や業務要件に依存するため、各組織で個別に定義してください。
用語の説明
本書に利用している用語の説明を以下に記載します。
| 用語 | 説明 |
|---|---|
| コアデータモデル | GIFで定義されているコアデータモデルを指す。 |
概念データ要素 (DEC) |
Data Element Concept:データの意味を表す概念。 本書では項目名として記載している。 |
| 定義 | Definition:概念データ要素の意味を記述したもの。 |
| 概念定義域 | Conceptual Domain:取り得る値の意味の範囲。 |
| 値域 | Value Domain:実際に使用できる値の具体的な範囲。 |
特殊コード (日付の不明等) |
日付項目において、不明・不詳・設定なし等の特殊な状態を表現するために用いられる符号。公的制度(住民基本台帳、公的個人認証等)で使用される場合がある(例:月日不詳を9999等で表現)。 |
データ項目辞書(コアデータモデル)
個人
ID群
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
氏
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
名
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
氏(カナ)
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
名(カナ)
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
氏(英字)
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
名(英字)
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
氏名
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
氏名(カナ)
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
氏名(英字)
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
国籍
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
性別
|
|
|---|---|
|
|
|
|
|
|
|
|
|
【参照:法令】
|
生年月日
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
死亡年月日
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
備考
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
住所
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
連絡先情報
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
連絡先
連絡先名称
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
連絡先用途
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
連絡先電話番号
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
連絡先メールアドレス
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
連絡先URL
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
連絡先SNS
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
連絡先住所
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
連絡先備考
|
|
|---|---|
|
|
|
|
|
|
|
|
|
【表記】
|
住所
全国地方公共団体コード
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
町字ID
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
都道府県
|
|
|---|---|
|
|
|
|
|
|
|
|
|
【参照:法令】
|
市区町村(郡)
|
|
|---|---|
|
|
|
|
|
|
|
|
|
【参照:法令】
|
町字
|
|
|---|---|
|
|
|
|
|
|
|
|
|
【参照:法令】
|
番地以下
|
|
|---|---|
|
|
|
|
|
|
|
|
|
【参照:法令】
|
建物名等(方書)
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
連結表記
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
郵便番号
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
国
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
町字以下
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
法人
法人番号
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
ID群
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
商号または名称
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
商号または名称(カナ)
|
|
|---|---|
|
|
|
|
|
|
|
|
|
・カナは片仮名(ISO 15924: Kana)を標準とする。
|
商号または名称(英字)
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
組織種別
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
通称
|
|
|---|---|
|
|
|
|
|
|
|
|
|
・通称に用いる具体的な種類(略称、愛称、別名、通名など)の採用可否・選択基準は値域で定義する。 |
事業活動状況
|
|
|---|---|
|
|
|
|
|
|
|
|
|
【補足】
【表記】
|
説明
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
WebサイトURL
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
社員数
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
代表者
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
代表者役職名
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
設立年月日
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
事業種目
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
登記住所
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
事業所情報
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
連絡先情報
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
施設
ID
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
種別情報
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
名称
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
名称(カナ)
|
|
|---|---|
|
|
|
|
|
|
|
|
|
・カナは片仮名(ISO 15924: Kana)を標準とする。
|
名称(英字)
|
|
|---|---|
|
|
|
|
|
|
|
|
|
【表記】 ・英字はラテン文字(ISO 15924: Latn)を指す。
|
通称
|
|
|---|---|
|
|
|
|
|
|
|
|
|
【補足】
|
説明
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
施設住所
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
アクセス方法
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
駐車場有無
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
連絡先情報
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
子供預かり情報
料金有無
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
料金説明
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
最小年齢
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
最小月齢
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
最大年齢
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
開所時間
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
閉所時間
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
備考
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
土地
ID群
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
用途
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
名称
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
名称(カナ)
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
名称(英字)
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
通称
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
説明
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
土地住所
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
土地面積
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
土地形状イメージURL
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
土地形状
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
備考
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
連絡先情報
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
建物
ID
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
種別情報
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
名称
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
名称(カナ)
|
|
|---|---|
|
|
|
|
|
|
|
|
|
・カナは片仮名(ISO 15924: Kana)を標準とする。
|
名称(英字)
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
通称
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
説明
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
建物住所
|
|
|---|---|
|
|
|
|
|
|
|
|
|
【参照:法令】 ・住居表示に関する法律 ・不動産登記法 |
備考
|
|
|---|---|
|
|
|
|
|
|
|
|
|
【補足】
|
設備
ID
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
種別情報
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
名称
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
名称(カナ)
|
|
|---|---|
|
|
|
|
|
|
|
|
|
・カナは片仮名(ISO 15924: Kana)を標準とする。
|
名称(英字)
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
説明
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
状態
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
設備住所
|
|
|---|---|
|
|
|
|
|
|
|
|
|
【参照:法令】
|
イベント
ID
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
イベント名
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
イベント名(カナ)
|
|
|---|---|
|
|
|
|
|
|
|
|
|
・カナは片仮名(ISO 15924: Kana)を標準とする。
|
イベント名(英字)
|
|
|---|---|
|
|
|
|
|
|
|
|
|
・英字はラテン文字(ISO 15924: Latn)を指す。
|
通称
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
サブタイトル
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
説明
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
サブイベント
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
イベント種類
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
イベントURL
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
状態
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
キーワード
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
タグ
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
開催パターン
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
開始日
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
終了日
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
開始時刻
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
終了時刻
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
日時説明
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
開催場所
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
開催場所住所
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
開催施設
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
アクセス方法
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
Web開催
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
主催団体
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
共催団体
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
関連団体
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
対象者
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
定員
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
料金有無
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
駐車場有無
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
連絡先情報
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
変更履歴
| 改定年月日 | 改定箇所 | 改定内容 |
|---|---|---|
| 2026年3月17日 | 全体 | β版決定 |
デジタル社会推進実践ガイドブック DS-439
コアデータモデル解説書 土地
2025年(令和7年)3月25日
デジタル庁
[キーワード] 土地、不動産、データモデル [概要] 土地の情報をシステム実装する際に参照すべきデータモデルについて解説するガイドブックです。このガイドに従いデータ設計を行うことで、同じ設計規則に従うシステム間、分野間でのデータ連携を容易かつ正確に行えるようになります。また、データ設計を実施するコストも削減することができます。 |
|---|
土地のデータモデル
土地の情報を記述するためのデータモデルです。
名称や土地住所などの基本的な情報を基礎項目として用意しています。用途に応じて基礎項目を選択し独自項目を追加するなどのカスタマイズを行って利用してください。
土地データモデルの項目
土地データモデルの基礎項目は表1の通りです。英語名や記入例などを含む詳細については、別添の「438_コアデータモデル_DMD.xlsx」を参照してください。
表1 土地データモデルの基礎項目一覧
| 必須項目 | 項目名 | 説明 |
|---|---|---|
| ID群 | 機械的に採番された土地を一意に識別するID。土地単位に付番する | |
| 必 | 用途 | 土地の主要な用途 |
| 名称 | 土地の名称 | |
| 名称(カナ) | 土地のカナ表記 | |
| 名称(英字) | 土地の英語名またはローマ字表記 | |
| 通称 | 土地に通称がある場合に記入 | |
| 説明 | 土地情報として公開可能な詳細情報 | |
| 必 | 土地住所 | 住所情報(住所の型) |
| 土地面積 | 土地の面積(m2) | |
| 土地形状イメージURL | 土地の形状を表す情報(イメージURL) | |
| 土地形状 | 土地の形状を表す記述 | |
| 備考 | 土地の備考、データ取得の日付等 | |
| 連絡先情報 | 連絡先の情報(連絡先の型) |
関連データ定義
コントロールド・ボキャブラリ(統制語彙)
土地の用途
都市計画基礎調査実施要領(令和5年6月国土交通省都市局)の土地コードの区分を使用する。
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
変更履歴
| 改定年月日 | 改定箇所 | 改定内容 |
|---|---|---|
| 2025年3月25日 | 全体 | データ項目を基礎項目として再定義 データモデルの関係性を削除 |
| 2022年5月9日 | - | 初版決定 |
デジタル社会推進実践ガイドブック DS-43A
コアデータモデル解説書 建物
2025年(令和7年)3月25日
デジタル庁
[キーワード] 建物、不動産、データモデル [概要] 建物の情報をシステム実装する際に参照すべきデータモデルについて解説するガイドブックです。このガイドに従いデータ設計を行うことで、同じ設計規則に従うシステム間、分野間でのデータ連携を容易かつ正確に行えるようになります。また、データ設計を実施するコストも削減することができます。 |
|---|
建物のデータモデル
建物の情報を記述するためのデータモデルです。
名称や建物住所などの基本的な情報は基礎項目とし、基礎項目の中で必ず選択していただく項目を必須項目としています。また、基礎項目以外の情報として拡張項目を用意しています。
必須項目以外は任意項目なので、用途に応じて基礎項目や拡張項目を選択、あるいは独自項目を追加するなどのカスタマイズを行って利用してください。
建物データモデルの項目
建物データモデルの基礎項目は表1、拡張項目は表2の通りです。英語名や記入例などを含む詳細については、別添の「438_コアデータモデル_DMD.xlsx」を参照してください。
表1 建物データモデルの基礎項目一覧
| 必須項目 | 項目名 | 説明 |
|---|---|---|
| ID | 機械的に採番された建物を一意に識別するID。建物単位に付番する | |
| 種別情報 | 建物の種別 | |
| 名称 | 建物の名称 | |
| 名称(カナ) | 建物のカナ表記 | |
| 名称(英字) | 建物の英語名またはローマ字表記 | |
| 通称 | 建物に通称がある場合に記入 | |
| 説明 | 建物情報として公開可能な詳細情報 | |
| 必 | 建物住所 | 住所・所在地情報(住所の型) |
| 備考 | 建物の備考 |
表2 建物データモデルの拡張項目一覧
| 項目名 | 説明 |
|---|---|
| 概要 | 建物情報として公開可能な概要情報 |
| 関連建物 | 提携している他建物の情報など(建物の型) |
| 状態 | 「建築」、「稼働中」、「閉鎖中」などのステータス |
| 設備情報 | 建物内に併設されている設備の情報 |
| 敷地 | 建物の敷地の情報(敷地面積等) |
| 性能 | 建物の性能(耐震性能、防火性能等) |
| 用途 | 建物の主要用途の表記 |
| 建築面積 | 建物の建築面積(m2) |
| 延べ面積 | 建物の延べ床面積(m2) |
| 最高の高さ | 建物の最高点の高さ(m) |
| 地上階数 | 建物の地上階数 |
| 地下階数 | 建物の地下階数 |
| 構造 | 建物の構造の表記 |
| 竣工日 | 建物の竣工日 |
| 連絡先情報 | 連絡先の情報(連絡先の型) |
| アクセシビリティ情報 | アクセシビリティ情報(アクセシビリティの型) |
その他構造物のデータモデル
農業用のビニールハウスや橋、史跡など建物としての管理が適切でないような構造物を記述するためのデータモデルとして、その他構造物のデータモデルを用意しています。その他構造物のデータモデルの項目は建物データモデルの項目と同じです。
関連データ定義
コントロールド・ボキャブラリ(統制語彙)
種別情報
一戸建ての住宅、工場等、建築基準法施行規則(別記様式)に定める建築物用途区分コードを使用できる。
https://www.mlit.go.jp/report/press/joho04_hh_001256.html
構造
不動産登記規則の「構造」区分を使用できる。
○構成材料による区分
「木造」、「土蔵」、「石」、「れんが」、「コンクリートブロック」、「鉄骨」、
「鉄筋コンクリート」、「鉄骨鉄筋コンクリート」
○屋根の種類による区分
「かわらぶき」、「スレートぶき」、「亜鉛メッキ鋼板ぶき」、「草ぶき」、
「陸屋根」
○階数による区分
「平家建」、
「二階建(三階建以上の建物にあっては、これに準ずるものとする。)」
これらの区分に該当しない建物については、これに準じて定める
用途
都市計画基礎調査実施要領に準拠する。
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
変更履歴
| 改定年月日 | 改定箇所 | 改定内容 |
|---|---|---|
| 2025年3月25日 | 全体 | データ項目を基礎項目と拡張項目として再定義 データモデルの関連性を削除 |
| 2022年5月9日 | - | 初版決定 |
デジタル社会推進実践ガイドブック DS-43B
コアデータモデル解説書 設備
2025年(令和7年)3月25日
デジタル庁
[キーワード] 設備、データモデル [概要] 設備の情報をシステム実装する際に参照すべきデータモデルについて解説するガイドブックです。このガイドに従いデータ設計を行うことで、同じ設計規則に従うシステム間、分野間でのデータ連携を容易かつ正確に行えるようになります。また、データ設計を実施するコストも削減することができます。 |
|---|
設備のデータモデル
設備の情報を記述するためのデータモデルです。
名称や設備住所などの基本的な情報は基礎項目とし、基礎項目の中で必ず選択していただく項目を必須項目としています。また、基礎項目以外の情報として拡張項目を用意しています。
必須項目以外は任意項目なので、用途に応じて基礎項目や拡張項目を選択、あるいは独自項目を追加するなどのカスタマイズを行って利用してください。
設備データモデルの項目
設備データモデルの基礎項目は表1、拡張項目は表2の通りです。英語名や記入例などを含む詳細については、別添の「438_コアデータモデル_DMD.xlsx」を参照してください。
表1 設備データモデルの基礎項目一覧
| 必須項目 | 項目名 | 説明 |
|---|---|---|
| ID | 機械的に採番された設備を一意に識別するID。設備単位に付番する | |
| 種別情報 | 設備の種類(CityGML2.0 AnnexC.4や公共測量標準図式コード等の種別情報)や区分 | |
| 必 | 名称 | 設備の名称 |
| 必 | 名称(カナ) | 設備のカナ表記 |
| 名称(英字) | 設備の英語名またはローマ字表記 | |
| 説明 | 設備情報として公開可能な詳細情報 | |
| 状態 | 「稼働中」などのステータス | |
| 設備住所 | 住所情報(住所の型) |
表2 設備データモデルの拡張項目一覧
|
|
|---|---|
| 利用可能曜日 | 施設を利用できる曜日 |
| 開始時刻 | 施設を利用開始できる時間 |
| 終了時刻 | 施設の利用終了時間 |
| 利用可能日時説明 | 定型で表せない施設の利用日時情報 |
| 利用可能日時式 | 「441_コアデータパーツ_日付時刻」の表記で日時を表現 |
| 一般利用可否 | 一般利用者が利用出来るかどうかの可否 |
| URL | AEDの設置場所写真のURLなど |
| 備考 | 設備の備考(非推奨) |
| 連絡先情報 | 連絡先の情報(連絡先の型) |
| 関連施設 | 関連する施設の情報(施設の型) |
| 関連建物 | 関連する建物の情報(建物の型) |
関連データ定義
コントロールド・ボキャブラリ(統制語彙)
種別情報
CityGML 2.0 Annex C.4のコード等を使用する。
|
|
|---|---|
|
|
|
|
|
|
|
|
変更履歴
| 改定年月日 | 改定箇所 | 改定内容 |
|---|---|---|
| 2025年3月25日 | 全体 | データ項目を基礎項目と拡張項目として再定義 データモデルの関連性を削除 |
| 2022年5月9日 | - | 初版決定 |
https://metanorma.github.io/ogc-citygml2/documents/document.html#toc89
デジタル社会推進実践ガイドブック DS-43C
コアデータモデル解説書 イベント
2025年(令和7年)3月25日
デジタル庁
[キーワード] イベント、データモデル [概要] イベントの情報をシステム実装する際に参照すべきデータモデルについて解説するガイドブックです。このガイドに従いデータ設計を行うことで、同じ設計規則に従うシステム間、分野間でのデータ連携を容易かつ正確に行えるようになります。また、データ設計を実施するコストも削減することができます。 |
|---|
イベントのデータモデル
イベントの情報を記述するためのデータモデルです。
イベント名や開催場所などの基本的な情報は基礎項目とし、基礎項目の中で必ず選択していただく項目を必須項目としています。また、基礎項目以外の情報として拡張項目を用意しています。
必須項目以外は任意項目なので、用途に応じて基礎項目や拡張項目を選択、あるいは独自項目を追加するなどのカスタマイズを行って利用してください。
イベントデータモデルの項目
イベントデータモデルの基礎項目は表1、拡張項目は表2の通りです。英語名や記入例などを含む詳細については、別添の「438_コアデータモデル_DMD.xlsx」を参照してください。
表1 イベントデータモデルの項目一覧
| 必須項目 | 項目名 | 説明 |
|---|---|---|
| 必 | ID | イベントに付与した一意のIDを記載。 |
| 必 | イベント名 | 名称を記載。 |
| イベント名(カナ) | 名称をカナで記載。 | |
| イベント名(英字) | 名称を英語で記載。 | |
| 通称 | 通称を記載。 | |
| サブタイトル | サブタイトルを記載。 | |
| 必 | 説明 | 説明を記載。 |
| サブイベント | サブイベントのIDを記載。 | |
| 必 | イベント種類 | イベントの種類を記載。 |
| 必 | イベントURL | イベントの詳細が掲載されているWebサイトのURLを記載。 |
| 状態 | 状態を記載。 | |
| キーワード | 検索用キーワードを記載(セミコロン区切りで列挙)。 | |
| タグ | 分類用のタグを記載(セミコロン区切りで列挙)。 | |
| 開催パターン | 開催パターン(定期開催、通年開催など)を記載。 | |
| 開始日 | 開始日を記載。 | |
| 終了日 | 終了日を記載。 | |
| 開始時刻 | 開始時刻を記載。 | |
| 終了時刻 | 終了時刻を記載。 | |
| 日時説明 | 日時に関する説明(最終日は早く終わることなど)を記載。 | |
| 開催場所 | 開催場所の名称を記載。 | |
| 開催場所住所 | 開催場所の住所を記載。 | |
| 開催施設 | 開催する施設情報を記載。 | |
| アクセス方法 | イベント会場へのアクセス方法を記載。 | |
| 必 | Web開催 | Web開催の開催形式(現地開催のみ、オンライン、ハイブリッド)を記載。 |
| 必 | 主催団体 | 主催団体名を記載。 |
| 共催団体 | 共催団体名を記載。 | |
| 関連団体 | 協賛、協力などの開催に関連する団体名を記載。 | |
| 必 | 対象者 | 対象者を記載。 |
| 定員 | 定員を記載。 | |
| 必 | 料金有無 | 「有料」、「無料」の区分を記載。 |
| 駐車場有無 | 駐車場の有無 | |
| 必 | 連絡先情報 | 連絡先情報を記載。 |
表2 イベントデータモデルの拡張項目一覧
| 項目名 | 説明 |
|---|---|
| 言語コード | イベント情報の記述言語コード(JA、EN、CNなど)を記載。 |
| 概要 | 概要を記載。 |
| コンテンツURL | イベントのコンテンツが掲載されているURLを記載。 |
| 対象となる産業 | イベントの対象となる産業(標準産業分類から選択)を記載。 |
| 所要時間 | 所要時間を記載。 |
| 掲載開始日 | イベント情報の掲載開始日を記載。 |
| 掲載終了日 | イベント情報の掲載終了日を記載。 |
| 受付場所 | 受付場所(or 集合場所)を記載。 |
| Web開催URL | Web開催のURLを記載。 |
| ツール・環境 | Web開催時の使用ツールを記載(セミコロン区切りで列挙)。 |
| 対象者備考 | 対象者に関する備考(カップル限定など)を記載。 |
| 定員備考 | 定員に関する備考(3グループまでなど)を記載。 |
| 料金 | イベントの参加費用(単位:円)で記載。 |
| 料金説明 | 料金に関する備考(1グループ1000円など)を記載。 |
| 決済種別 | 決済種別(現金、クレジットカード、電子マネーなど)を記載(セミコロン区切りで列挙)。 |
| 外国語対応 | 外国語の対応言語を記載(セミコロン区切りで列挙)。 |
| 外国語対応備考 | 外国語対応に関する備考(英語は案内ありなど)を記載。 |
| 開催条件 | 開催条件(雨天決行など)を記載。 |
| 申込期限日 | 申込期限日を記載。 |
| 申込期限時刻 | 申込期限時刻を記載。 |
| 申込開始日 | 申込開始日を記載。 |
| 申込開始時刻 | 申込開始時刻を記載。 |
| 申込URL | Web申し込む場合のURLを記載。 |
| 申込方法 | 申込方法(当日参加可、要事前申込みなど)を記載。 |
| 駐車場情報 | イベント会場で指定されている駐車場情報を記載。 |
| 駐車場料金 | 駐車場料金の「有料」、「無料」の区分を記載。 |
| 駐輪場情報 | イベント会場で指定されている駐輪場情報を記載。 |
| アクセシビリティ情報 | アクセシビリティ情報を記載。 |
| 子供預かり情報 | 子供預かり情報を記載。 |
コアデータモデル「イベント」の活用
イベントのデータモデルの活用にあたっては、地域のレクリエーションや定期イベント(自治体主催の花火大会など)等にそのまま適用できます。特に行政イベントでの利用にあたっては「451-5_実装データモデル_イベント」を参照してください。
その他、災害時などの緊急時には、炊き出しや救援物資の配布をイベントと捉えることで、コアデータモデルをカスタマイズして利用することができます。
変更履歴
| 改定年月日 | 改定箇所 | 改定内容 |
|---|---|---|
| 2025年3月25日 | 全体 | データ項目を基礎項目と拡張項目として再定義 |
| 2022年6月30日 | - | 初版決定 |