430 コアデータモデル

デジタル社会推進実践ガイドブック DS-430

コアデータモデル全体概要

2026年（令和8年）3月17日

デジタル庁

はじめに

背景

行政機関では多くのデータを管理していますが、そのデータは独自の形式である場合が多く、標準化されていません。そのため、データの再利用が困難であったり、外部とのデータ連携においても大きな障害になっています。また、データ形式が標準化されていないと、データ連携ができないだけでなく、データの整形に多くのリソースを割くことになり、分析にも支障をきたします。AIやビッグデータの活用が注目されていますが、そのインプットとなるデータが十分に整備されていなければ、目的の結果にたどり着くのが困難になります。

欧州や米国では、行政データの標準化を進めることで、社会全体のデータ標準化につながっていくものと考え、欧州委員会（EC）は、各国の個人、法人、場所情報等が活用できるようにSEMICという行政データ標準化のプロジェクトが、米国ではNIEMというプロジェクトが進められています。

日本においても行政データの標準化を図るため、これまで標準ガイドライン群の一部として、行政基本情報データ連携モデル、行政サービス・データ連携モデル（β版）、推奨データセット、共通語彙基盤などを設計、公開してきました。これら既存の標準群はデータを相互に連携する際の共通規格のように使われることを想定しており、世の中の基礎的な要素について統一した表現方法を採用することで、データの相互運用性を確保することを目的としています。

解決したい課題

データ標準を実際に使いたいユーザーの目線から見た時、大きく分けて以下のような課題があります。

1. 標準が普及しておらず、存在を認識できていない

2. 標準がたくさんあって、どれを見ればいいのかわからない

１つめの課題は標準の普及についてです。デジタル庁サイトに掲載はしているものの、その認知度や可読性には課題があります。

• 掲載されていることを知らなかった

• そもそもデータの相互運用性の課題に対して、標準というアプローチがあることを知らなかった

などの理由により、標準が広く普及しているとは言い難い状況にあります。

２つめの課題は標準の統一についてです。既存の標準群はそれぞれ異なったタイミングで整備・発表されたものなので、内容であるデータ項目には重複や定義の差異が存在しており、データの構造も異なっています。ドキュメント自体の体系もそれぞれ異なっているため、ユーザーは複数の異なるドキュメントからユースケースにあった標準を見つけねばならず、標準を採用するまでの負荷が増大しています。

既存の標準群を統合・再整理し、利活用の側面からデータ項目の取捨選択、定義の見直しを行った上でGIF（Government Interoperability Framework

)として一つにまとめています。統合したデータ標準は、基礎編であるコアデータモデルと、応用編である実装データモデルに分けて整理しています。基礎編では社会の様々な場面で登場する個人や法人、住所や連絡先などの基礎的なデータをコアデータモデルとして本書で取りまとめています。応用編ではコアデータモデルの組み合わせやカスタマイズによって表現される実装データモデルを、行政、教育、スマートシティなど分野ごとに分けて整備しています。

検討のプロセス

標準の再整理は以下のプロセスで検討を行いました。

既存の標準群のデータ項目について対応表を作成

既存の標準のうち、行政データ・サービス連携モデル（β版）をベースに、推奨データセットやIMI共通語彙基盤など、その他の標準をデータ項目ごとに紐づける形で対応表を作成しました。これにより、データ項目の重複や差異、欠落を洗い出し、項目レベルでの統合を行いました。標準間の細かい定義の揺れもこのプロセスで吸収しています。

個々のデータ項目について必要性や定義を再検討

作成した対応表をもとに、データ項目一つ一つについて、民間のデータ有識者を含むデジタル庁内で検討を行い、定義の見直しや項目自体の取捨選択を行いました。項目の必須・任意の分類もこのプロセスで行なっています。必須項目を定義することで、最低限の相互運用性を確保しつつ、任意項目の選択や利用者独自の項目追加により、カスタマイズの余地を残すことを目的としています。

実装の容易さや利便性を加味して全体を構造化

最後に、確定したデータ項目を正規化し、全体の構造の見直しを行いました。既存の標準の中ではIMI共通語彙基盤が最も構造化されています。逆にオープンデータの普及を目的とした推奨データセットは構造化が最小限に留められています。構造の見直しにおいては、これら２つの既存標準の中間となるような、ある程度は構造化されていてシステム実装とメンテナンスが行いやすく、かつフラットな構造を一部残すことでデータ利用者にとって扱いやすいことを念頭に置いて再構成しています。この過程において「ID情報型」や「コード情報型」など、項目に対応する新しいデータの型を追加しました。

再構成した新しい標準体系は実際の利用場面を想定した実装データモデルとして位置付けています。それに対して、既存の標準であるIMI共通語彙基盤はデータの概念辞書のように使われることを想定しています。

全体像

ドキュメントの構成

再整理したデータ標準のことを以下、コアデータモデルと呼称します。コアデータモデルのドキュメント構成は図1のとおりです。

図1 ドキュメント構成

全体を説明する本書とは別に３つの大きなドキュメント群で構成されます。

コアデータモデル解説書

様々な場面で参照される以下の要素について、標準となる基本的なデータ構造を定義しています。

1. 個人

2. 法人

3. 連絡先

4. 住所

5. 施設

6. アクセシビリティ

7. 子供預かり情報

8. 土地

9. 建物

10. 設備

11. イベント

これらについてデータ項目と使い方の解説を記載したものがコアデータモデル解説書です。行政が保有するデータだけでなく、民間事業者が保有するデータにも活用されることを想定しています。

例えば、民間事業者が「個人」のデータモデルを参考に自社サービスのユーザー情報をデータ化したり、「法人」のデータモデルを参考に取引先の情報をデータ化し、設計コストを下げるとともに他社や行政との相互運用性を高めることなどが想定されます。

DMD (Data Model Description)

データ項目の解説書としてDMD (Data Model Description) を作成し、表形式ファイルにまとめています。行政または民間事業者がデータを設計するにあたって、DMDを参考に任意項目の取捨選択や、項目のカスタマイズの検討、システム実装の際のスキーマ決定の参考として活用されることを想定しています。

DMDの詳細は添付の「438_コアデータモデル_DMD.xlsx」を参照してください。

コード一覧

データ項目の形式で利用するコードの一覧として、コード一覧を作成し、表形式ファイルにまとめています。

コード一覧の詳細は添付の「438-1_コアデータモデル_コード一覧.xlsx」を参照してください。

コアデータパーツ

日付や電話番号、住所など、様々なデータモデルで登場する以下のデータ項目に関しては、共通形式を定めています。

1. 日付時刻

2. 住所・所在地（アドレス）

3. 郵便番号

4. 地理情報

5. 電話番号

共通形式でデータを記述しておくことで、連携の際に変換処理を省くことができ、円滑なデータ連携が可能になります。コアデータモデルにおいては、行政基本情報データ連携モデルをベースに内容を更新したものを「コアデータパーツ」としてまとめています。これらデータ項目の形式の詳細については別紙「コアデータパーツ」を参照してください。

コアデータモデルの全体構造

コアデータモデル全体の構造をクラス図として表現すると以下のようになります。（大きなサイズのものは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）を付与しています。

以下にプレフィックスを一覧にまとめます。

コアデータモデルで定義した型

コアデータモデルでは以下の四つ（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」を参照してください。

変更履歴

https://joinup.ec.europa.eu/collection/semantic-interoperability-community-semic

https://www.niem.gov/

デジタル社会推進実践ガイドブック DS-431

コアデータモデル解説書 個人

2026年（令和8年）3月17日

デジタル庁

個人のデータモデル

個人の情報を記述する際のデータモデルです。行政組織が住民のデータを整備する場合の他、民間事業者や学校法人が社員や生徒、教員の情報を整備する場合などに活用されることを想定しています。氏名や連絡先などの基本的な情報は基礎項目とし、データの利用シーンに合わせた必須項目をパターン化しています。また、基礎項目以外の情報として拡張項目を用意しています。

必須項目以外は任意項目なので、用途に応じて基礎項目や拡張項目を選択、あるいは独自項目を追加するなどのカスタマイズを行って利用してください。

個人データモデルの項目

個人データモデルの基礎項目は表1、拡張項目は表2の通りです。基礎項目に対する必須項目のパターンについては「1.2必須項目パターン」を、英語名や記入例などを含む詳細については、別添の「438_コアデータモデル_DMD.xlsx」を参照してください。

表1 個人データモデルの基礎項目一覧

表2 個人データモデルの拡張項目一覧

役割関与情報について

教育機関における保護者など、個人に紐づく別の個人についての情報は「役割関与情報」に記述します。ここで個人と個人の関係性と、指し示す個人（保護者であれば両親など）の情報を記述します。記述のフォーマットの詳細はDMDの役割関与情報型を参照してください。

国の名称とコードの扱い

個人や住所のデータモデルでは国の名称や国を表すコードを扱う項目が存在します。これらについては国際標準であるISO 3166-1及びJISX0304に従って管理します。コードで表す必要がある場合はアルファベット3文字（日本ならば「JPN」）で表すISO 3166-1 alpha-3での管理を標準とします。

性別のコードの扱い

個人のデータモデル等で性別をコードで管理する場合は、国際標準であるISO 5218に従って管理します。すなわち「0:不明」「1:男性」「2:女性」「9:その他」となります。ここでいう性別とは生物学的性差（sex）を指し、文化的社会的性差（gender）は別項目として管理します。

必須項目のパターン

基礎項目のうち、必須とする項目のパターンは表3の通りです。データの利用目的に合わせてパターンを選択して利用してください。

表3 個人データモデルの必須項目のパターン

変更履歴

デジタル社会推進実践ガイドブック DS-432

コアデータモデル解説書 連絡先

2025年（令和7年）3月25日

デジタル庁

連絡先のデータモデル

個人や法人、施設の連絡先を記述する際のデータモデルです。

連絡先名称や連絡先住所などの基本的な情報を基礎項目として用意しています。用途に応じて基礎項目を選択し独自項目に連絡先部署等を追加するなどのカスタマイズを行って利用してください。

連絡先データモデルの項目

連絡先データモデルの基礎項目は表1の通りです。英語名や記入例などを含む詳細については、別添の「438_コアデータモデル_DMD.xlsx」を参照してください。

表1 連絡先データモデルの基礎項目一覧

変更履歴

デジタル社会推進実践ガイドブック DS-433

コアデータモデル解説書 住所

2026年（令和8年）3月17日

デジタル庁

住所のデータモデル

国内の住所を記述する場合のデータモデルです。

住所については令和４年より一元的な住所情報の管理を目的としたアドレス・ベース・レジストリがデジタル庁によって整備され、令和5年度（2023年度）末から公開を開始しています。この取り組みにより住所情報の町字レベルでの統一・整備が行われることから、住所のデータモデルもアドレス・ベース・レジストリとの相互運用性の観点に基づいた検討を行っており、アドレス・ベース・レジストリと紐づけることのできる町字IDを必須項目とすることで、定義や表記揺れがなく、全国で統一された住所情報との連携を可能とします。そのため、住所の情報を新たに設計する場合は、アドレス・ベース・レジストリと相互運用できる町字IDの採用を強く推奨します。全国地方公共団体コードと町字IDを組み合わせることで都道府県、市区町村、町字までを特定することができ、残りの番地以下の情報および建物名等を組み合わせて住所情報を構造的に保存することができます。

既に住所のデータを持っている場合、連結表記に既存のデータを保存した上で、それとは別に住所データを分解して保存することを推奨します。都道府県、市区町村、町字など、住所情報を分解して保存することで相互運用性を確保し、後々にアドレス・ベース・レジストリとのマッチングを行いやすくします。住所情報を個々の項目に分割するツール（コンバーター）については、デジタル庁にてARBジオコーダーが提供されております。

(https://lp.geocoder.address-br.digital.go.jp/)

住所情報の構造の詳細については「442_コアデータパーツ_住所・所在地（アドレス）」の解説もあわせて参照してください。

これらのことを踏まえ、本データモデルでは全国地方公共団体コードや町字IDなどの基本的な情報を基礎項目とし、データの利用シーンに合わせた必須項目をパターン化しています。また、基礎項目以外の情報として拡張項目を用意しています。

必須項目以外は任意項目なので、用途に応じて基礎項目や拡張項目を選択、あるいは独自項目を追加するなどのカスタマイズを行って利用してください。

住所データモデルの項目

住所データモデルの基礎項目は表1、拡張項目は表2の通りです。基礎項目に対する必須項目のパターンについては「1.2必須項目パターン」を、英語名や記入例などを含む詳細については、別添の「438_コアデータモデル_DMD.xlsx」を参照してください。

表1 住所データモデルの基礎項目一覧

表2 住所データモデルの拡張項目

必須項目のパターン

基礎項目のうち、必須とする項目のパターンは表3の通りです。データの利用目的に合わせてパターンを選択して利用してください。

表3 住所データモデルの必須項目のパターン

住所文字列の分解と連結表記

住所文字列は以下の５つの要素に分解して記述します。

1. 都道府県

2. 市区町村

3. 町字

4. 番地以下

5. 建物名等(方書)

実際の住所を分解した例は以下のようになります。

1. 都道府県 ........ 東京都

2. 市区町村 ........ 千代田区

3. 町字 ............ 紀尾井町

4. 番地以下......... １番２号

5. 建物名等(方書) .. ガーデンテラス紀尾井町19F

一方で既存の住所データは一つの文字列として格納されていることが多いため、「連結表記」項目に元の文字列を併記することを推奨しています。

住所のデータ形式については「442_コアデータパーツ_住所・所在地（アドレス）」もあわせて参照してください。

座標情報を用いた位置情報中心のデータ構成

位置情報サービスやIoTデバイス、災害情報管理など、地理的な位置の特定が主目的となるアプリケーションにおいては、連結表記と位置情報（座標情報）を中心としたシンプルなデータ構成も検討できます。

この構成は、位置情報（座標情報）を主軸とするシステムに適しています。全国地方公共団体コードや町字IDは推奨項目としていますが、座標情報から行政ポリゴンを用いた空間検索により全国地方公共団体コードや町字IDを導出することが可能となります。

使用例を以下に記載します。

・連結表記：人が場所を特定、理解、伝達するために使用する情報

・位置情報：システムが位置を特定、処理するために使用する情報

改訂履歴

デジタル社会推進実践ガイドブック DS-434

コアデータモデル解説書 法人

2025年（令和7年）3月25日

デジタル庁

法人のデータモデル

事業者などの法人の情報を記述するためのデータモデルです。行政で法人の情報を扱う場合の他、民間事業者が取引先などの情報を扱う場合に活用されることを想定しています。国税庁が指定する法人番号や名称などの基本的な情報は基礎項目とし、データの利用シーンに合わせた必須項目をパターン化しています。また、基礎項目以外の情報として拡張項目を用意しています。

必須項目以外は任意項目なので、用途に応じて基礎項目や拡張項目を選択、あるいは独自項目を追加するなどのカスタマイズを行って利用してください。

法人データモデルの項目

法人データモデルの基礎項目は表1、拡張項目は表2の通りです。基礎項目に対する必須項目のパターンについては「1.2必須項目パターン」を、英語名や記入例などを含む詳細については、別添の「438_コアデータモデル_DMD.xlsx」を参照してください。

表1 法人データモデルの基礎項目一覧

表2 法人データモデルの拡張項目一覧

必須項目のパターン

基礎項目のうち、必須とする項目のパターンは表3の通りです。データの利用目的に合わせて選択して利用してください。

表3　法人データモデルの必須項目のパターン

事業所データモデルの項目

法人に紐付く施設としての事業所情報を記述するためのデータモデルです。

法人内で利用される管理のためのIDや名称などの基本的な情報は基礎項目としています。また、基礎項目以外の情報として拡張項目を用意しています。

事業所データモデルの基礎項目は表4、拡張項目は表5の通りです。事業所データモデルには必須項目はないため、用途に応じて基礎項目や拡張項目を選択、あるいは独自項目を追加するなどのカスタマイズを行って利用してください。

表4 事業所データモデルの基礎項目一覧

表5 事業所データモデルの拡張項目一覧

変更履歴

デジタル社会推進実践ガイドブック DS-435

コアデータモデル解説書 施設

2025年（令和7年）3月25日

デジタル庁

施設のデータモデル

行政が管理する施設の情報を記述するためのデータモデルです。カスタマイズすることで民間事業者のサービス施設や教育施設、防災施設、観光施設などにも転用することができるため、幅広い分野で施設の情報を扱う場合に活用されることを想定しています。施設の名称や住所などの基本的な情報は基礎項目とし、データの利用シーンに合わせた必須項目をパターン化しています。また、基礎項目以外の情報として拡張項目を用意しています。

必須項目以外は任意項目なので、用途に応じて基礎項目や拡張項目を選択、あるいは独自項目を追加するなどのカスタマイズを行って利用してください。

施設データモデルの項目

施設データモデルの基礎項目は表1、拡張項目は表2の通りです。英語名や記入例などを含む詳細については、別添の「438_コアデータモデル_DMD.xlsx」を参照してください。

表1 施設データモデルの基礎項目一覧

表2　施設データモデルの拡張項目一覧

種別情報(地理的目標物分類コード:POIコード)について

種別情報にはPOIコード等を設定します。POIコードは観光施設、公共施設など地理的目標物に対する分類コードです。無意コード 4 桁のコード体系となっています。

分類対象の選択

分類にあたっては以下を参照して作成されています。

• 国土地理院 電子国土基本図 地物種別コード

• 国土交通省 都市計画 GIS 地物一覧

• 国土交通省 国土数値情報

• 国土地理院 公共測量標準図式 数値地形図データ取得分類コード表

• 観光庁 観光入込客統計に関する共通基準 観光地点等分類コード

• 観光庁 観光立国実現に向けた多言語対応の改善・強化のためのガイドライン

• 文部科学省 体育・スポーツ施設現況調査 施設種別の定義

• 東京都 国内外旅行者のためのわかりやすい案内サイン標準化指針【東京都版対訳表】

• OpenStreetMap Wiki, JA:Map Features(2017-11-28)

• schema.org(2017-11-28)

• 日本標準産業分類

分類項目名

各項目の分類項目名は、既存の分類項目における定義等を踏まえ、一般的な

呼称を選定しています。商業施設に関しては、店の呼称は「－屋」「－店」が混在しています。これは、一意に分類項目を決めるため一般的な呼称を使用しているだけであり、「－屋」「－店」との呼称自体が区別やレベル感を表すものではありません。また、グローバルな互換性をとるため、日本には存在しない施設等にもコードを付与しています。

複合施設等の扱い

複合施設は、その他を選択するか最も近いコードを使用することを推奨します。その他の選択肢として、内部施設について別途項目を立てて記述する方法、コードを列挙する方法等があります。

地点ではないエリアや点ではない対象物に対する考え方

地形に関しては、特定の位置を示すものではなく、範囲を示す対象物であることがありますが、広域な目標物とする場合があるため、コード表に含まれています。

また、遊漁船、ロープウェイ等の場合、位置は出発点を示している場合があります。

サービス担当区域について

サービス担当区域の情報はハローワークなど、その公共施設が所管する地理的範囲が定められている場合に使用します。住所情報だけで地理的範囲を定められない場合は、地図上に重ねられる境界ポリゴン情報を参照するURLを「ポリゴン」項目に記述します。

変更履歴

デジタル社会推進実践ガイドブック DS-436

コアデータモデル解説書 アクセシビリティ

2026年（令和8年）3月17日

デジタル庁

アクセシビリティのデータモデル

施設やイベント開催時に、利用者にバリアフリーの状況や対応可能な介助の種類など、要配慮者に関するアクセシビリティや、子育て支援に関するアクセシビリティ情報を伝えるときのデータモデルです。車椅子貸出やバリアフリートイレなどの有無情報を基礎項目として用意しており、アクセシビリティ情報を付加したい他のデータモデルとあわせて利用することを想定しています。

各項目は基本的に有無コードの値をとります。文書で詳細を伝えたい場合は備考にその内容を記述することを想定しています。

すべて任意項目なので、用途に応じて項目を選択、あるいは独自項目を追加するなどのカスタマイズを行って利用してください。

アクセシビリティデータモデルの項目

アクセシビリティデータモデルの基礎項目は表1の通りです。英語名や記入例などを含む詳細については、別添の「438_コアデータモデル_DMD.xlsx」を参照してください。

表1 アクセシビリティデータモデルの基礎項目一覧

変更履歴

デジタル社会推進実践ガイドブック DS-437

コアデータモデル解説書 子供預かり情報

2026年（令和8年）3月17日

デジタル庁

子供預かり情報のデータモデル

施設やイベント開催時に、利用者に子供預かり施設の情報を伝えるときのデータモデルです。情報を付加したい他のデータモデルとあわせて利用することを想定しています。料金有無や最小年齢、最大年齢などの基本的な情報は基礎項目とし、基礎項目の中で必ず選択していただく項目を必須項目としています。また、基礎項目以外の情報として拡張項目を用意しています。

必須項目以外は任意項目なので、用途に応じて基礎項目や拡張項目を選択、あるいは独自項目を追加するなどのカスタマイズを行って利用してください。

子供預かり情報データモデルの項目

子供預かり情報データモデルの基礎項目は表1の通りです。英語名や記入例などを含む詳細については、別添の「438_コアデータモデル_DMD.xlsx」を参照してください。

表1 子供預かり情報データモデルの基礎項目一覧

表2　子供預かり情報データモデルの拡張項目一覧

変更履歴

デジタル社会推進実践ガイドブック DS-438-2

データ項目辞書（β版）

2026年（令和8年）3月17日

デジタル庁

目次

概要

背景

行政のデジタル化が進展する中、府省庁や地方公共団体の間でデータを相互に利活用する機会が増加しています。しかし、作成者が異なるデータは、同一の意味（概念）を持つ情報であっても、個々のデータの中で用いられる用語や項目名として違う言葉（ラベル）が割り当てられていることがあります。例えば、「電力」に関連する概念を表す際に、「定格出力」「消費電力」「電力量」など様々な用語が使用され、それぞれが異なる意味を持つのか同じ意味を持つのかが判別できません。また、「社員数」のカウント基準においても、役員やパート・アルバイトを含めるのか等、データ作成者ごとに異なる基準が用いられ、データを活用した分析や利活用に対して問題を引き起こすことがあります。このような不整合を解決するには、もともとのデータがもつ意味を判別するための仕組みが必要です。

政府相互運用性フレームワーク(GIF: Government Interoperability Framework)は、データモデル等を提供していますが、個々のデータ項目の意味を体系的に整理する枠組みが十分に整備されていない状況にあります。

課題

データ項目の意味（概念）と、その項目が取り得る具体的な値の範囲が明確に区別されていないため、同じ用語でも異なる基準で運用されていることが見過ごされています。また、データ項目の定義が各システムの設計書に散在しており、体系的に検索・参照できる仕組みが不足しているため、既存の定義を発見して再利用することが難しく、類似したデータ項目が重複して定義される非効率が生じています。さらに、人が理解できる用語定義と、機械が処理できる形式的な記述を統合的に管理する仕組みが整備されていないため、データ項目の意味を人と機械の双方が正しく解釈し、自動的に連携処理を行うことができません。

これらの課題により、データ項目の意味の不整合が解消されず、データ連携のコストが増大し、データを活用した分析や利活用に支障をきたしています。

目的

本書は、データ連携として、データ項目の意味を明確かつ一貫性のある形で定義する「データ項目辞書」を提供することを目的としています。組織内外で再利用するデータ項目について、その名前と意味を人が読んで理解できる形で定めたデータ項目辞書を提供します。データ項目が「何を意味するのか」という概念と、「どのような値を取るのか」という具体的な値の範囲を分けて定義することで、意味の理解と実際の使い方を別々に考えられるようにします。

これにより、組織間でデータ項目の意味を共通に理解できるようになり、データを交換する際の意味のずれを防ぐことができます。また、既に定義された標準を再利用することで、システム開発やデータ設計の手間を減らし、効率を高めることができます。

概要

本書は、GIFのコアデータモデルで定義している項目に対して「データ項目辞書（コアデータモデル）」を提供します。

本書について

対象範囲と前提

本書が対象とするデータ項目は、行政機関が広く利用する基本的なもの（コアデータモデル）であり、具体的には個人、法人、住所、連絡先、施設、建物、設備、土地、イベント、子供預かり情報等のエンティティに関するデータ項目を定義します。業務固有のデータ項目については、本書の定義を参考に、各組織が独自に定義することを想定しています。

なお、本書のデータ項目定義は関連する法令・制度を参照していますが、法令解釈や制度運用を規定するものではありません。法的な解釈や具体的な運用については、各法令の所管府省庁の定める規則・通達等に従うものとします。

本書では、コアデータモデルの構成のうち基礎項目のみ記載しています。また、記載項目は、「項目名」、「定義」、「概念定義域」「補足」としており、説明の中で実装時に定義すべき事項（値域、表記規則等）についてガイドを示しています。具体的な「値域（許容値、データ型、形式等）」は、実装環境や業務要件に依存するため、各組織で個別に定義してください。

用語の説明

本書に利用している用語の説明を以下に記載します。

データ項目辞書（コアデータモデル）

個人

ID群

氏

名

氏(カナ)

名(カナ)

氏(英字）

名(英字）

氏名

氏名(カナ)

氏名(英字）

国籍

性別

生年月日

死亡年月日

備考

住所

連絡先情報

連絡先

連絡先名称

連絡先用途

連絡先電話番号

連絡先メールアドレス

連絡先URL

連絡先SNS

連絡先住所

連絡先備考

住所

全国地方公共団体コード

町字ID

都道府県

市区町村(郡）

町字

番地以下

建物名等(方書）

連結表記

郵便番号

国

町字以下

法人

法人番号

ID群

商号または名称

商号または名称(カナ)

商号または名称(英字)

組織種別

通称

事業活動状況

説明

WebサイトURL

社員数

代表者

代表者役職名

設立年月日

事業種目

登記住所

事業所情報

連絡先情報

施設

ID

種別情報

名称

名称(カナ)

名称(英字)

通称

説明

施設住所

アクセス方法

駐車場有無

連絡先情報

子供預かり情報

料金有無

料金説明

最小年齢

最小月齢

最大年齢

開所時間

閉所時間

備考

土地

ID群

用途

名称

名称(カナ)

名称(英字)

通称

説明

土地住所

土地面積

土地形状イメージURL

土地形状

備考

連絡先情報

建物

ID

種別情報

名称

名称(カナ)

名称(英字)

通称

説明

建物住所

備考

設備

ID

種別情報

名称

名称(カナ)

名称(英字)

説明

状態

設備住所

イベント

ID

イベント名

イベント名(カナ)

イベント名(英字)

通称

サブタイトル

説明

サブイベント

イベント種類

イベントURL

状態

キーワード

タグ

開催パターン

開始日

終了日

開始時刻

終了時刻

日時説明

開催場所

開催場所住所

開催施設

アクセス方法

Web開催

主催団体

共催団体

関連団体

対象者

定員

料金有無

駐車場有無

連絡先情報

変更履歴

デジタル社会推進実践ガイドブック DS-439

コアデータモデル解説書 土地

2025年（令和7年）3月25日

デジタル庁

土地のデータモデル

土地の情報を記述するためのデータモデルです。

名称や土地住所などの基本的な情報を基礎項目として用意しています。用途に応じて基礎項目を選択し独自項目を追加するなどのカスタマイズを行って利用してください。

土地データモデルの項目

土地データモデルの基礎項目は表1の通りです。英語名や記入例などを含む詳細については、別添の「438_コアデータモデル_DMD.xlsx」を参照してください。

表1 土地データモデルの基礎項目一覧

関連データ定義

コントロールド・ボキャブラリ（統制語彙）

土地の用途

都市計画基礎調査実施要領（令和5年6月国土交通省都市局）の土地コードの区分を使用する。

変更履歴

デジタル社会推進実践ガイドブック DS-43A

コアデータモデル解説書 建物

2025年（令和7年）3月25日

デジタル庁

建物のデータモデル

建物の情報を記述するためのデータモデルです。

名称や建物住所などの基本的な情報は基礎項目とし、基礎項目の中で必ず選択していただく項目を必須項目としています。また、基礎項目以外の情報として拡張項目を用意しています。

必須項目以外は任意項目なので、用途に応じて基礎項目や拡張項目を選択、あるいは独自項目を追加するなどのカスタマイズを行って利用してください。

建物データモデルの項目

建物データモデルの基礎項目は表1、拡張項目は表2の通りです。英語名や記入例などを含む詳細については、別添の「438_コアデータモデル_DMD.xlsx」を参照してください。

表1 建物データモデルの基礎項目一覧

表2 建物データモデルの拡張項目一覧

その他構造物のデータモデル

農業用のビニールハウスや橋、史跡など建物としての管理が適切でないような構造物を記述するためのデータモデルとして、その他構造物のデータモデルを用意しています。その他構造物のデータモデルの項目は建物データモデルの項目と同じです。

関連データ定義

コントロールド・ボキャブラリ（統制語彙）

種別情報

一戸建ての住宅、工場等、建築基準法施行規則（別記様式）に定める建築物用途区分コードを使用できる。

https://www.mlit.go.jp/report/press/joho04_hh_001256.html

構造

不動産登記規則の「構造」区分を使用できる。

○構成材料による区分

「木造」、「土蔵」、「石」、「れんが」、「コンクリートブロック」、「鉄骨」、

「鉄筋コンクリート」、「鉄骨鉄筋コンクリート」

○屋根の種類による区分

「かわらぶき」、「スレートぶき」、「亜鉛メッキ鋼板ぶき」、「草ぶき」、

「陸屋根」

○階数による区分

「平家建」、

「二階建（三階建以上の建物にあっては、これに準ずるものとする。）」

これらの区分に該当しない建物については、これに準じて定める

用途

都市計画基礎調査実施要領に準拠する。

変更履歴

デジタル社会推進実践ガイドブック DS-43B

コアデータモデル解説書 設備

2025年（令和7年）3月25日

デジタル庁

設備のデータモデル

設備の情報を記述するためのデータモデルです。

名称や設備住所などの基本的な情報は基礎項目とし、基礎項目の中で必ず選択していただく項目を必須項目としています。また、基礎項目以外の情報として拡張項目を用意しています。

必須項目以外は任意項目なので、用途に応じて基礎項目や拡張項目を選択、あるいは独自項目を追加するなどのカスタマイズを行って利用してください。

設備データモデルの項目

設備データモデルの基礎項目は表1、拡張項目は表2の通りです。英語名や記入例などを含む詳細については、別添の「438_コアデータモデル_DMD.xlsx」を参照してください。

表1 設備データモデルの基礎項目一覧

表2 設備データモデルの拡張項目一覧

関連データ定義

コントロールド・ボキャブラリ（統制語彙）

種別情報

CityGML 2.0　Annex C.4のコード等を使用する。

変更履歴

https://metanorma.github.io/ogc-citygml2/documents/document.html#toc89

デジタル社会推進実践ガイドブック DS-43C

コアデータモデル解説書 イベント

2025年（令和7年）3月25日

デジタル庁

イベントのデータモデル

イベントの情報を記述するためのデータモデルです。

イベント名や開催場所などの基本的な情報は基礎項目とし、基礎項目の中で必ず選択していただく項目を必須項目としています。また、基礎項目以外の情報として拡張項目を用意しています。

必須項目以外は任意項目なので、用途に応じて基礎項目や拡張項目を選択、あるいは独自項目を追加するなどのカスタマイズを行って利用してください。

イベントデータモデルの項目

イベントデータモデルの基礎項目は表1、拡張項目は表2の通りです。英語名や記入例などを含む詳細については、別添の「438_コアデータモデル_DMD.xlsx」を参照してください。

表1 イベントデータモデルの項目一覧

表2 イベントデータモデルの拡張項目一覧

コアデータモデル「イベント」の活用

イベントのデータモデルの活用にあたっては、地域のレクリエーションや定期イベント（自治体主催の花火大会など）等にそのまま適用できます。特に行政イベントでの利用にあたっては「451-5_実装データモデル_イベント」を参照してください。

その他、災害時などの緊急時には、炊き出しや救援物資の配布をイベントと捉えることで、コアデータモデルをカスタマイズして利用することができます。

変更履歴