--- type: guideline title: 440 コアデータパーツ source: デジタル庁 ds_code: ds-400 category: data-interop source_url: https://www.digital.go.jp/policies/data_strategy_government_interoperability_framework license: CC0-1.0 --- # 440 コアデータパーツ デジタル社会推進実践ガイドブック DS-441 コアデータパーツ 日付及び時刻 2026年（令和8年）3月17日 デジタル庁

[キーワード]

日付、時刻、データ形式

[概要]

円滑なデータ連携を行うには、データが共通の形式で整えられていることが必要です。本書はコアデータモデルを対象に、日付及び時刻のデータ形式について示すものです。日付及び時刻のデータ形式は、ISO8601及びJIS X 0301（日付及び時刻の表記）に準拠し、以下のとおりとします。（ただし、高速処理が必要な場合等、特段の事情がある場合には、独自形式を採用する場合もある）
# 日付及び曜日 ## 日付 日付のデータは西暦年4桁、月2桁、日2桁をハイフンで接続する形式とし、半角文字を使用します。日付のうち年のみを使用したい場合は、YYYY形式で使用することとします。 - YYYY-MM-DD - YYYY：西暦年4桁 - MM ：月2桁（1桁の場合には前に0をつける） - DD ：日2桁（1桁の場合には前に0をつける） 例） | 2017年9月1日 | 2017-09-01 | |--------------|------------| ## 曜日コード 曜日のコード及びデータは、月曜日を1とし、以下のとおりとします。 1:月曜日 2:火曜日 3:水曜日 4:木曜日 5:金曜日 6:土曜日 7:日曜日 「曜日」を省略し「月曜日」を「月」と記入しても問題ありません。 列挙する場合には、月曜日から順に記入し、「曜日」はデータに含みません。 例） | 月火水木金 | 12345 | |------------|-------| ## 特定日、繰り返し 週の特定日や定期的に繰り返し行うスケジュールは、自由記述とします。ただし、特定日や繰り返しコードで表す場合には以下の書式に従うこととします。 - 曜日はMo,Tu,We,Th,Fr,Sa,Suで表す - 前項の曜日単体で表す場合と異なるので注意 - 毎週は0、第何週は1-5、最終は6、隔週は7で表す 例） | 毎週水曜日 | 0We | |------------------------|---------| | 第1,3月曜日 | 13Mo | | 第1,4火曜日と第4木曜日 | 14Tu4Th | | 最終金曜日 | 6Fr | | 隔週日曜日 | 7Su | # 時刻 時刻のデータは、時、分、秒を:（半角コロン記号）で接続した以下の形式とします。 - HH:MM:SS（秒は省略可能） - HH：時間（24時間表記。1桁の場合には前に0をつける） - MM：分（1桁の場合には前に0をつける） - SS：秒（1桁の場合には前に0をつける） - 例） | 18時10分50秒 | 18:10:50 | |--------------|----------| 1秒未満の時刻を必要とする場合においては、業務等の特性や要件に従い、小数表記をします。このような表記を含むデータを提供する際は、小数点以下の桁数等、データ形式情報を提供することを推奨します。 # 日付と時刻の組合せ 日付と時刻は、「日付」と「時刻」の2つのデータ項目に分けて設計することを推奨します。 日付と時刻を1つのデータ項目で持つ場合には、国際標準に従い日付と時刻の間を「T」で接続して表現します。グローバルにデータ連携をする場合は、必要に応じてUTC（協定世界時）と地方時の時差を表記します。具体的には、UTC（協定世界時）に対して地方時が進んでいる場合は「+」、遅れている場合は「-」記号を用い、以下の例のように表現します。なお、UTCに対して時差のない場合には「Z」を末尾に付与します。 - YYYY-MM-DDTHH:MM:SS+hh:mm - hh ：UTCに対して進んでいる「時」 - mm ：UTCに対して進んでいる「分」（通常は00） 例）
2017年9月1日18時10分50秒
（日本時間）		 2017-09-01T18:10:50+09:00
1970年1月1日0時0分0秒
（UTC:協定世界時）		 1970-01-01T00:00:00Z
# 期間 期間は、「開始日」、「終了日」と「開始時刻」、「終了時刻」の4つのデータ項目で設定することを推奨します。 期間を1つのデータ項目で持つ場合には、国際標準に従い以下のとおりとします。 ## 基本構造 期間の開始日時と終了日時を「/」でつないで、「開始日時/終了日時」とし、次のとおりとします。 - YYYY-MM-DD/YYYY-MM-DD ## 時刻を含む場合 期間に時刻を含む場合は、「[３](#日付と時刻の組合せ)　[日付と時刻の組合せ](#日付と時刻の組合せ)」の方法を組み合わせて、次のとおりとします。 - YYYY-MM-DDTHH:MM:SS+hh:mm/YYYY-MM-DDTHH:MM:SS+hh:mm ## 年が同一の場合 期間の年が同一の場合は、年の部分を省略して、次のとおりとします。 - YYYY-MM-DD/MM-DD ## 月まで同一の場合 期間の年及び月が同一の場合は、年及び月の部分を省略して、次のとおりとします。 - YYYY-MM-DD/DD ## 継続、所要時間 継続時間（経過時間）や所要時間を記述する場合には、時刻の形式に従い、次のとおりとします。 - HH:MM ## 期間の長さ（日数・月数・年数） 期間の長さ(日数・月数・年数)を記述する場合には、ISO8601の期間表記に従い、次のとおりとします。 ・PnD、、、日数 ・PnM、、、月数 ・PnY、、、年数 ・PnYnMnD、、、年＋月＋日数 例） | 10日 | P10D | |-------------|---------| | 3ヶ月 | P3M | | 2年6か月 | P2Y6M | | 1年3か月5日 | P1Y3M5D | # 時間帯等コード 利用時間、配送時間等を表す際に、時間帯や目標時間を示す場合があります。そのような場合は、時間帯や目標時間について以下のようなコードと時刻表記で表すものとします。 ## 時間帯コード 0時を起点として1時間区切りでコードを定める。 | コード | 時間帯 | コード | 時間帯 | |--------|-------------|--------|-------------| | 00 | 00:00/01:00 | 12 | 12:00/13:00 | | 01 | 01:00/02:00 | 13 | 13:00/14:00 | | 02 | 02:00/03:00 | 14 | 14:00/15:00 | | 03 | 03:00/04:00 | 15 | 15:00/16:00 | | 04 | 04:00/05:00 | 16 | 16:00/17:00 | | 05 | 05:00/06:00 | 17 | 17:00/18:00 | | 06 | 06:00/07:00 | 18 | 18:00/19:00 | | 07 | 07:00/08:00 | 19 | 19:00/20:00 | | 08 | 08:00/09:00 | 20 | 20:00/21:00 | | 09 | 09:00/10:00 | 21 | 21:00/22:00 | | 10 | 10:00/11:00 | 22 | 22:00/23:00 | | 11 | 11:00/12:00 | 23 | 23:00/24:00 | | | | 99 | 不明・未定 | 複数のコードを記載する場合は「,」（カンマ）で区切ります。 時間帯の時刻表記は以下の書式とします。 - HH:MM/HH:MM（開始時間/終了時間） 例）9時～12時を表す場合 | 09時から12時まで | 09,10,11 | 09:00/12:00 | |------------------|----------|-------------| ## 目標時間コード 0時を起点として1時間区切りのコードを定めます。 | コード | 目標時間 | コード | 目標時間 | |--------|----------|--------|------------| | 00 | 00:00 | 12 | 12:00 | | 01 | 01:00 | 13 | 13:00 | | 02 | 02:00 | 14 | 14:00 | | 03 | 03:00 | 15 | 15:00 | | 04 | 04:00 | 16 | 16:00 | | 05 | 05:00 | 17 | 17:00 | | 06 | 06:00 | 18 | 18:00 | | 07 | 07:00 | 19 | 19:00 | | 08 | 08:00 | 20 | 20:00 | | 09 | 09:00 | 21 | 21:00 | | 10 | 10:00 | 22 | 22:00 | | 11 | 11:00 | 23 | 23:00 | | | | 99 | 不明・未定 | 「～時頃」のように示される目標時間は、前後に幅を持たせる時間の表記方法です。前後30分、前後15分等、個々に持たせる幅は異なるため、目標時間を定義する際に、その旨を自由記述で補足してください。 # 月、季節、旬コード イベント等の時期を月や季節、旬で示す場合があります。そのような場合は、季節や旬について以下のようなコードと季節及び旬の表記で表すものとします。 ## 月コード 時期等が不明で、月で時期を示したいときに、月名を2桁半角数字（1桁の場合には前に0をつける）で記入します。 例） | 4月 | 04 | |-----|-----| ## 季節コード 時期等が未定で、月ではなく季節で示したい場合は、以下のコードと季節で時期を示します。 | コード | 季節 | コード | 季節 | |--------|------|--------|------| | A1 | 春 | A3 | 秋 | | B1 | 初春 | B3 | 初秋 | | C1 | 仲春 | C3 | 仲秋 | | D1 | 晩春 | D3 | 晩秋 | | A2 | 夏 | A4 | 冬 | | B2 | 初夏 | B4 | 初冬 | | C2 | 仲夏 | C4 | 仲冬 | | D2 | 晩夏 | D4 | 晩冬 | | 00 | 不明 | | | ## 旬コード 月内の日時が未定で、その時期を示したい場合等、以下のコードと旬で時期を示します。 | コード | 旬 | |--------|------------| | A1 | 上旬 | | A2 | 中旬 | | A3 | 下旬 | | 00 | 不明・未定 | 「10日頃」等の目標日時がある場合には、別途、目標日のデータ項目を設定することを推奨します。 # 特記事項 日付及び時刻に関して、「金曜日は17時まで」等の特記事項を記載する場合には、上記のデータ項目内に記述するのではなく「備考」のデータ項目を付加し対応します。 また、うるう秒の扱いは、情報機器やオペレーティングシステムの仕様に依存するため、うるう秒挿入時のログ分析等を行う際には留意してください。 「３ 日付と時刻の組み合わせ」において、時差表記部分（+もしくは-以降）を一般的に使われる「hh:mm」としていますが、必要であれば「hh:mm:ss」と秒を加えてください。 # 解説 ## 拡張形式の適用 ISO8601では、日付及び時刻の表記に基本形式と拡張形式が存在します。基本形式は、YYYYMMDDTHHMM+hhmmです。しかしこれは視認性が悪いため、日付にハイフン、時刻にコロンを使用する拡張形式を使用します。 ## 年月日の表記 国内では、年月日を記載する際に「YYYY年MM月DD日」又は「YYYY/MM/DD」と記載することが一般的です。しかしシステム内やグローバルなデータ連携では国際標準に従い「YYYY-MM-DD」を使うことが多く、本標準はデータ連携用標準であることから、「YYYY-MM-DD」を採用します。 ## 和暦との変換 入力や表示・印字において和暦年を使う場合には、入力時には入力データを和暦から西暦へ変換し、データは西暦で管理します。逆に出力時には西暦から和暦へ変換して表示します。同様に、入力や表示・印字において12時間制を使う場合には、データは24時間制で管理し、入出力時に変換します。 例） | 入力: 平成27年 | データ: 2015 | |----------------|----------------| | データ: 2015 | 出力: 平成27年 | ## 日付等が不明のときのコード表記 日付・時期等が不明であるとき、コードとしては「9」、「99」、「9999」を不明に割り当てます。 基本的には99を不明に割り当てていますが、季節コードの00のように、住基ネットなど重要かつ変更が容易でないシステムと連携させる場合には、例外的に00または0000を不明に割り当てるケースもあります。 # 変更履歴
改定年月日 改定箇所 改定内容
2026年3月17日 4.6 期間の長（日数、月数、年数）さを追加
2023年3月31日 6.3 旬コードを住基ネットに合わせて変更。
2023年2月28日 6.2,8.4 季節コードを住基ネットに合わせて変更。不詳日のコードの考え方を追記。
2022年3月31日 全体
P3		 GIFへの統合に伴い全体の体裁を変更
UTCと一致する場合の記述方法をシステムで一般的な YYYY-MM-DDTHH:MM:SSZに変更
2021年6月4日

P2

P4

P5、P6

特定日、繰り返しのスケジュール記述方法の追加

経過、所要時間を追加

月コードの月名の表記方法を補足

季節コードの誤記修正
2020年5月14日

P1

P3

P5

エクセルについての注記を削除

時間帯等コードの追加

季節、旬コードの追加
2019年3月28日 - 初版決定
2017年12月7日 - α版公開
デジタル社会推進実践ガイドブック DS-442 コアデータパーツ 住所・所在地（アドレス） 2026年（令和8年）3月17日 デジタル庁

[キーワード]

住所、所在地、アドレス、町字、番地、丁目、大字、町名、小字、データ形式

[概要]

円滑なデータ連携を行うには、データが共通の形式で整えられていることが必要です。本書はコアデータモデルを対象に、住所・所在地のデータ形式について示すものです。住所・所在地のデータ形式は、住所・所在地関連の主要省庁及び日本郵便株式会社、およびアドレス・ベース・レジストリのデータ記述方式を参照し、以下のとおりとします。
# 住所・所在地をコードを用いて管理する 一元的な住所・所在地情報の管理を目的としたアドレス・ベース・レジストリがデジタル庁によって整備・公開されていることから、アドレス・ベース・レジストリとの相互運用性を確保するためコードを用いた管理を推奨します。全国地方公共団体コード及び町字IDを用いて住所・所在地情報を管理することで、表記や定義の揺れを防ぐことができます。 これらのコードやIDはデジタル庁が取りまとめ、各利用者から参照できるように公開しています。詳細は下記サイトを参照してください。 アドレス・ベース・レジストリ（デジタル庁） https://www.digital.go.jp/policies/base_registry_address/ ## 全国地方公共団体コードと町字IDを使用して管理する場合（推奨） 都道府県、市区町村、町字（地方自治法における「町若しくは字」、すなわち大字、町、丁目、小字のこと）の情報をIDで管理し、番地以下を文字列のみのデータで持ちます。建物名等（方書）は別データ項目とします。 ただし、町字に変更が生じる場合もあるため、ID部分も文字列を合わせて管理することを推奨します。 ### 文字列部分を3個のデータ項目で管理する場合 全国地方公共団体コードにより、都道府県、郡、市町村、特別区、政令指定都市の行政区をIDで管理します。町字IDにより、大字・町・丁目・小字をIDで管理します。 IDで管理される部分を含め、住所・所在地の表記を都道府県、市区町村、町字以下の3個のデータ項目で管理します。これらの3項目を結合することで、住所・所在地を連結した一つの表記にすることができます。 例）東京都千代田区霞が関二丁目１番2号中央合同庁舎第2号館の場合 | 全国地方公共団体コード | 131016 | |------------------------|---------------------| | 町字ID | 0002002 | | 都道府県 | 東京都 | | 市区町村 | 千代田区 | | 町字以下 | 霞が関2-1-2 | | 建物名等（方書） | 中央合同庁舎第2号館 | 「町字以下」に収録する文字列は、以下の規則に従います。 - 「大字」の文字、字の前につく「字」の文字は、省略可能とする例1 - 「町・大字」に「丁目」が含まれる場合には、「丁目」および「番地・号」以下を半角数字と半角ハイフン区切りとする例2,3 - 「字」がある場合には、「字」まで文字列、「番地・号」の数字項目以下は半角数字と半角ハイフン区切りとする - 京都市等のように、通り名を表記する方法も可能とする例4 例1）福島県会津若松市大戸町大字高川甲1324の場合 | 町字以下 | 大戸町高川甲1324 | |----------|------------------| 例2）東京都千代田区霞が関二丁目１番6号の場合 | 町字以下 | 霞が関2-1-6 | |----------|-------------| 例3）北海道芦別市北一条西一丁目3番地の場合（条丁目制） | 町字以下 | 北1条西1-3 | |----------|------------| 例4）京都市中京区寺町通御池上る上本能寺前町488の場合 | 町字以下 | 寺町通御池上る上本能寺前町488 | |----------|-------------------------------| ### 文字列部分を4個のデータ項目で管理する場合 全国地方公共団体コードと対応する文字列表記を都道府県、市区町村の2項目で、町字IDに対応する文字列表記を町字の1項目で表現します。ID項目と文字列項目を1対1で対応可能です。 例）東京都千代田区霞が関二丁目１番2号中央合同庁舎第2号館の場合 | 全国地方公共団体コード | 131016 | |------------------------|---------------------| | 町字ID | 0002002 | | 都道府県 | 東京都 | | 市区町村 | 千代田区 | | 町字 | 霞が関二丁目 | | 番地以下 | 1-2 | | 建物名等（方書） | 中央合同庁舎第2号館 | ## 全国地方公共団体コードのみを使用して管理する場合 全国地方公共団体コードで市区町村までを管理し、町字以下をデータ文字列のみで管理します。 表記の時には全国地方公共団体コードを都道府県名、市区町村名に変換して、町字以下の情報と合わせて表示します。 例）東京都千代田区霞が関二丁目１番2号中央合同庁舎第2号館の場合 | 全国地方公共団体コード | 131016 | |------------------------|---------------------| | 町字以下 | 霞が関2-1-2 | | 建物名等（方書） | 中央合同庁舎第2号館 | 表記の際はコードを変換した上で結合し「東京都千代田区霞が関2-1-6」などと表記することで人が判別しやすい形に加工して利用します。 # 建物名等の扱い 建物名などのデータである方書（かたがき）は、現在では建物名というデータ項目名にすることがほとんどであり、方書というデータ項目名は行政業務での利用が中心になっています。よって、データ項目名は、一般的に使用される表記をベースとして「建物名等（方書）」とします。 住所・所在地の自動確認を容易にするとともに、利便性向上のために、住所・所在地とは別データ項目とします。具体的なデータとしてはビル名など建物名のほか、部屋番号、フロアの名称などをもこの項目に記述します。 配送、不動産取引の際の利便性を考慮して、建物名等（方書）を細分化した別項目として管理することも可能です。 例）合同庁舎2号館3階 | 建物名 | 合同庁舎2号館 | |----------|---------------| | フロア名 | 3階 | | 部屋番号 | | 例）霞が関レジデンス502号室 | 建物名 | 霞が関レジデンス | |----------|------------------| | フロア名 | | | 部屋番号 | 502号室 | # 住所・所在地情報を正規化するツールについて 円滑なデータ連携の観点から、システム更改時に住所・所在地情報のIDによる管理（全国地方公共団体コード及び町字ID）の採用を推奨します。 デジタル庁からアドレス・ベース・レジストリを参照して住所・所在地文字列の正規化・階層分割とコード付与をするツール「ABRジオコーダー」を提供しています。住所・所在地文字列を入力すると、表記の揺らぎを吸収してアドレス・ベース・レジストリと突合し、階層ごとに分割した住所・所在地文字列、全国地方公共団体コード及び町字ID、緯度経度等をマッチングレベル（どの階層まで一致したか）とともに出力します。 アドレス・ベース・レジストリでは、建物名等は整備していないため、「ABRジオコーダー」に入力する住所・所在地の文字列には建物名等を含まないようにするか、番地・号の後、建物名等の前に空白を入れて区切りを明確にすることが出力結果の精度向上に必要となります。 なお、アドレス・ベース・レジストリは過去の住所・所在地情報を未収録のため、過去の住所・所在地情報を管理する必要があるシステムにおいては過去に廃止された町字のコード化には対応していません。 「ABRジオコーダー」の詳細は、デジタル庁ウェブサイトのアドレス・ベース・レジストリのページを参照してください。 # 英語表記 ## 基本事項 住所・所在地の英語表記は、国土交通省国土地理院が定める「地名等の英語表記規程」の表記方法に準じます。必要に応じて、「観光立国実現に向けた多言語対応の改善・強化のためのガイドライン」（平成26年3月国土交通省観光庁）を参照します。 ヘボン式ローマ字を用いることとし、以下の規則に従うこととします。 - はねる音「ん」は、「n」と書く　 - はねる音をあらわす「n」と、次に来る母音字又は「y」を切り離す必要がある場合には、「n」の次にハイフンを入れる - つまる音は、次の音節の最初の子音字を重ねて表す。ただし、次に「ch」音がくる場合には「c」を重ねず「t」を用いる - 長音を表す記号は、省略することを原則とします。 ただし、50音の「い」段の長音は、「i」を重ねて表し、「えい」は「ei」と書く - 表音のローマ字表記が「ou」「oo」「uu」となる場合に、対応する元の漢字が一文字の場合にはそれぞれ「o」「o」「u」に短縮するが、二文字に分かれるときには短縮しない。ただし、短縮する表記が通用している場合には、短縮してもよい 地名等の解釈又は発音の便宜上必要な場合には、分かち書き（語の区切りに空白を挟んで記述すること）を行うことができることとします。 地名の解釈で区切る場合には、ハイフンを用いて区切るものとします。ただし、分かち書きしなくても誤解のない場合や、短い地名等の場合は除きます。区切る箇所は、次の各号のとおりとします。一号及び二号のときは、ハイフンの後ろの最初の文字を大文字にするものとします。 一 複合地名における地域名称等の後 二 東、西、南、北、上、中、下、新、旧、元その他の地名と相対的な関係を表す接頭語の後 三 地形を表す部分の前 発音の便宜上区切る場合には、ハイフンを用いて区切るものとします。ただし、広く使用されているなど、分かち書きしなくても誤解のない場合は除きます。 ## 住所・所在地表記 日本語のデータ項目に準じて個別のデータ項目とすることを推奨しますが、一行で記述する場合には以下のように記述します。ただし、市区町村名等、コードを使って自動入力できる項目もあります。自治体から住所・所在地表記についてガイドライン等が公開されている場合は、そちらを優先します。 基本形 数字表記(丁目を含む。), 町名, 市区町村, 都道府県 郵便番号, Japan 例） 2-1-2 Kasumigaseki, Chiyoda-ku, Tokyo 1008926, Japan 政令指定都市の場合 数字表記(丁目を含む。), 町名, 区, 政令指定都市 (, 都道府県), 郵便番号, Japan 例） 1-1 Minato-cho, Naka-ku, Yokohama-shi, Kanagawa 2310017, Japan 1-1 Minato-cho, Naka-ku, Yokohama-shi, 2310017, Japan 条丁目制を採用している場合 数字表記(条丁目を含む。), (町名), 市区町村, 都道府県 郵便番号, Japan 条丁目制を採用している場合（政令指定都市） 例） Kita 1 Higashi 1-3, Ashibetsu-shi, Hokkaido 0758711, Japan 条丁目制を採用している場合（政令指定都市） 数字表記(条丁目を含む。), 区, 政令指定都市 (, 都道府県), 郵便番号, Japan 例） Kita 1 Nishi 2-1-1, Chuo-ku, Sapporo-shi 060-8611, Japan - 丁目以下は半角数字表記としハイフンで接続する - 数字表記の後ろに半角スペースを置き、後ろの町名との間を分ける - 町名、市区町村名、都道府県名は、先頭文字を大文字、その他の文字を小文字で記入する - 町名、市区町村名、都道府県名の間は、半角カンマ「,」と半角スペースにより区切る - 数字表記と町名の間、都道府県名と郵便番号の間は、半角スペースで区切る - 郵便番号は7桁連続とし、ハイフンによる区切りは使わない - 郵便番号の後にJapanを書く場合には、郵便番号とJapanの間を半角カンマ「,」と半角スペースにより区切る - 市区町村名は、各自治体固有部分の後に「-shi」「-ku」「-machi」「-cho」「-mura」「-son」をつける - 都府県は、固有自治体名のみ記入し「-to」「-fu」「-ken」は記述しない。北海道は「Hokkaido」と記入する - 政令指定都市の場合、数字項目、町名、区名、政令指定都市名を記入し、政令指定都市名の後ろに半角カンマ「,」と半角スペースにより区切り都道府県名を記入します。半角スペースを明け、郵便番号7桁を区切りなしで記入します。ただし、政令指定都市名は、都道府県名を省略することも可能である ## 建物名等 基本的に、住所・所在地と別データ項目で記載します。住所・所在地の数字項目の前の先頭に記入し、半角カンマ「,」と半角スペースにより区切ります。 例） 2nd Bldg. of the Central Common Government Office, 2-1-2 Kasumigaseki, Chiyoda-ku, Tokyo 100-8926, Japan ## 英語表記のデータを管理する場合 1 住所・所在地をコードを用いて管理する の日本語表記と項目の整合をとり、4.1～4.3に従い管理します。英語表記のデータを管理する場合は、1.1 1) 文字列部分を3個のデータ項目で管理する場合を採用することを推奨します。 例）東京都千代田区霞が関二丁目１番2号中央合同庁舎第2号館の場合 | 全国地方公共団体コード | 131016 | |----|----| | 町字ID | 0002002 | | 都道府県_英語表記 | Tokyo | | 市区町村_英語表記 | Chiyoda-ku | | 町字以下_英語表記 | 2-1-2 Kasumigaseki | | 建物名等（方書）\_英語表記 | 2nd Bldg. of the Central Common Government Office | ## 英語表記とアドレス・ベース・レジストリ アドレス・ベース・レジストリのデータ項目に各住所・所在地階層の英字があります。全国地方公共団体コードから都道府県及び市区町村の英語表記を取得可能です。全国地方公共団体コードと町字IDから「大字・町名_英字」「丁目名_数字」「小字名_英字」を取得可能です（ただし、データが整備されている場合に限ります）。 例えば、ウェブで入力フォームを設ける場合には、アドレス・ベース・レジストリを参照してプレフィルする使い方が考えられます。 # 読み仮名 住所・所在地を表記するだけでなく、音声合成や音声認識のために読み仮名を整備したい場面が考えられます。 英語表記と同様に、1 住所・所在地をコードを用いて管理する の日本語表記と項目の整合をとり管理します。 例）東京都千代田区霞が関二丁目１番2号中央合同庁舎第2号館の場合 | 全国地方公共団体コード | 131016 | |----------------------------|--------------------------------------------| | 町字ID | 0002002 | | 都道府県（カナ） | トウキョウト | | 市区町村（カナ） | チヨダク | | 町字以下（カナ） | カスミガセキニチョウメ1-2 | | 建物名等（方書）\_読み仮名 | チュウオウゴウドウチョウシャダイニゴウカン | アドレス・ベース・レジストリのデータ項目に各住所・所在地階層の読み仮名があります。全国地方公共団体コードから都道府県及び市区町村の読み仮名を取得可能です。全国地方公共団体コードと町字IDから「大字・町名_カナ」「丁目名_カナ」「小字名_カナ」を取得可能です（ただし、データが整備されている場合に限ります）。 例えば、ウェブで入力フォームを設ける場合には、アドレス・ベース・レジストリを参照してプレフィルする使い方が考えられます。 # 解説 ## 住所・所在地のデータ表現における字の整理 住所・所在地は、「都道府県」「支庁」「郡」「市町村」「特別区」「政令指定都市の行政区」「町・大字」「丁目」「（小）字」「番地・号（住居表示実施区域においては街区符号・地番、住居表示非実施区域においては地番）」で構成され、さらに「建物名等」を使用します。 ※地方自治法（昭和22年法律第67号）第260条に「町若しくは字」の新設や廃止に関する条項があるが「町若しくは字」の定義はない。住居表示に関する法律においても「町又は字」の記載があるが、「町又は字」の定義はない。 本標準では、アドレス・ベース・レジストリによって「町」「大字」「丁目」「（小）字」までの範囲が「町字」として整理され、地方自治体ごとにユニークなIDを振って管理が開始されることから、相互運用性を加味して同じ範囲を「町字」として分類しています。 ![](./assets/440-02-image1.png) ## 住所・所在地のデータ表現における丁目の表記 公文書において「丁目」は漢数字で記載されることが多いですが、社会的には丁目以下を数字で管理することが一般的であり、英語等でも数字で表記することから、本標準においては、丁目以下を分離して管理する場合は半角数字と半角ハイフン区切りで記述することを基本とします。 例） 東京都千代田区霞が関2-1-6 ## 住所・所在地のデータ表現における号の枝番の表記 不動産登記事務取扱手続準則に基づき、土地分割等により号に枝番号を使う場合には、以下のとおり番地に追記します。 丁目-番地-号（枝番含む） 例） | 一丁目1番地1-1号 | 1-1-1-1 | |------------------|---------| 集合住宅において住所・所在地の号の後にハイフンで部屋番号を記入する場合がありますが、本標準では集合住宅名や部屋番号は建物名等のデータ項目として分けて管理します。 例） | 一丁目1番地1号〇〇住宅1号室 | 1-1-1 | 〇〇住宅1 | |----------------------------------|-------|---------------| | 一丁目1番地1号〇〇住宅A棟101号室 | 1-1-1 | 〇〇住宅A-101 | ## 住所・所在地のデータ表現における番地の前の記号の扱い 番地の前に、イロハ…、甲乙丙…（十干）、子丑寅…（十二支）等の記号が含まれる場合には、小字の一部として扱います。ただし、土地の登記で地番に含まれる場合は、番地項目に含むことが許容されます。 ## 番地における例外 番地に相当する部分に「番外地」「地先」等の文字が入る例外があります（住居表示が実施されておらず、土地の登記がされていない場合）。 ## 英語住所・所在地表記における都道府県名及び市区町村名 国土地理院「地名等の英語表記規程」では、都道府県名及び市区町村名でPrefectureやCityの英語区分を使用することとしています。住所・所在地表記においては、一般的に使用される「-shi」等の表音によるルールに従うこととします。 ## 英語の市区町村名の揺らぎ 英語の地名の表記は以下の例に示すとおり、府省や組織により異なる場合がありますが、住所・所在地表記においては、「地名等の英語表記規程」に準拠します。 例）御殿場の場合 | 国土交通省土地総合情報システム | Gotenba | |--------------------------------|---------| | 地名集日本 | Gotenba | | 総務省国勢調査（地域一覧） | Gotemba | | 御殿場市役所Webページ | Gotemba | | 御殿場警察署 | Gotenba | | 御殿場駅 | Gotemba | | 御殿場インターチェンジ | Gotenba | ## 英語住所・所在地の表記例 英語住所・所在地の表記法は、住所・所在地表記関連組織が自組織の住所・所在地を記述している方法を参考にします。 日本郵便WebサイトCorporate Information 2-3-1 Otemachi, Chiyoda-ku, Tokyo 100-8791 国土交通省Webサイト 2-1-3 Kasumigaseki, Chiyoda-ku, Tokyo 100-8918 総務省Webサイト 1-2 Kasumigaseki 2-chome, Chiyoda-ku. Tokyo 100-8926, Japan 総務省Webサイト（アクセス（PDF）） Central Government Building No.2, 2-1-2, Kasumigaseki, Chiyoda-ku, Tokyo 100-8926, Japan 国土地理院Webサイト 1, Kitasato, Tsukuba 305-0811 ## 英語表記における政令指定都市の扱い 政令指定都市の英語名の記載では、ほとんどの都市が都道府県名を省略しているため、本標準でも都道府県名は省略可能とします。 # 変更履歴
改定年月日 改定箇所 改定内容
2026年3月17日 5.読み仮名 読み仮名の項目名を仮名からカナに変更
2025年3月25日 全体

住所の３項目で管理する形式を追加

住所の正規化ツールの追加

英語表記・読み仮名を追加
2022年3月31日

P5、P11

P3

 アドレス・ベース・レジストリによる町字IDの整備に伴い記載を変更
アドレス・ベース・レジストリの管理方法に倣い4個のデータ項目で管理する場合を記載
2021年6月4日

P1

P2

P3等

P4、P5

3個のデータ項目を記述することを推奨と追記

データ区切り位置を町名以降から丁目以降に変更

方書を建物名等に変更

分かち書きの記載内容について、国土地理院の「地名等の英語表記規程」の文面に合わせる
2019年4月1日 4ページ 内容の不備について修正
2019年3月28日 - 初版決定
2017年12月7日 - α版公開
デジタル社会推進実践ガイドブック DS-443 コアデータパーツ 郵便番号 2022年（令和4年）3月31日 デジタル庁

[キーワード]

郵便番号、データ形式

[概要]

円滑なデータ連携を行うには、データが共通の形式で整えられていることが必要です。本書はコアデータモデルを対象に、郵便番号のデータ形式について示すものです。
# 郵便番号 郵便番号のデータは7桁の郵便番号を続けて表記する以下の形式とします。 - 0000000 # 解説 国内では一般に上3桁と下4桁をハイフンで接続した999-9999の形式が郵便番号の表記で使われています。 しかし、本標準においては、以下の理由により、ハイフンを含まない0000000の区切りなし番号を推奨します。 - 多くのシステムにおいてハイフンを省略した入力を可能にしている。 - 郵便番号は3桁+4桁という定型書式であり、連続番号で入力しても分離した表現が可能である。 - データが7桁の連続表記であっても000-0000のようにハイフン含む形式に変換するのは容易である。 # 特記事項 なんらかの事由により、7桁以外（3桁や5桁）の郵便番号を保持する必要がある場合、システムの更改や他システムとの連携を考慮し、7桁の郵便番号との対応表を作成するなど、データの非互換を回避する対応を推奨します。 # 変更履歴 | 改定年月日 | 改定箇所 | 改定内容 | |:-------------:|----------|-----------------------------------| | 2022年3月31日 | 全体 | GIFへの統合に伴い全体の体裁を変更 | | 2019年3月28日 | \- | 初版決定 | | 2017年12月7日 | \- | α版公開 | デジタル社会推進実践ガイドブック DS-444 コアデータパーツ 地理情報 2025年（令和7年）3月25日 デジタル庁

[キーワード]

地理情報、地理座標、緯度、経度、標高、データ形式、空間ID

[概要]

円滑なデータ連携を行うには、データが共通の形式で整えられていることが必要です。本書はコアデータモデルを対象に、地理情報のデータ形式及びIDについて示すものです。
# 地理座標 ## 座標と桁数 一般の行政事務利用を目的とする場合、緯度と経度のデータは別データ項目で持ち、10進表記で小数点以下6桁を原則とします。標高のデータは、単位をメートルとし、10進表記で原則小数点以下1桁を原則とします。 - 緯度: 35.676097 - 経度: 139.744879 - 標高: 25.5 ## 座標参照系 座標参照系は、JGD 2011/(B,L)を基本とし、緯度、経度、標高のデータとあわせて座標参照系を別項目で記述します。EPSGコードによる表現を推奨します。 - 座標参照系: EPSG:6668 標高のデータを必要とする用途においては、垂直方向の座標参照系を併記することを推奨します。JGD 2011/(B,L)に対応する標高のEPSGコードは次のとおりです。 - 座標参照系 (垂直方向): EPSG:6695 ただし、測量データ等、本書の示す標準と異なる精度でのデータ連携が必要になる地理座標データについては、本標準の対象となりません。 # 空間ID 1. ## 空間ID 空間IDは、地球上の特定の空間領域を一意に識別するための識別子です。空間領域の単位は、3次元空間を直方格子状に分割した直方体（以下、「空間ボクセル」とする）とします。空間ボクセルを再帰的に分割することにより、様々なサイズの空間ボクセルを定義できます。個々の空間ボクセルには、グローバルに一意の識別子である空間IDを割り当てます。 空間IDの構成要素には、z, f, x, y があり、IDの表記は、各要素をスラッシュ (/) で連結した配列とします。 ![](./assets/440-04-image1.png) 図1.空間ボクセルのイメージ （） 空間ボクセルの構造 - 最上位の階層をズームレベル 0 とし、ズームレベルが 1つ増えるごとに空間ボクセルの 8 分割を繰り返す階層構造を持つ。 - ズームレベル間で親子関係を持つ。 - 同一ズームレベルにおいて重複する空間ボクセルは存在しない。 ## 空間IDの形式 空間IDの構成要素 - {z}: ズームレベル - {f}: 標高（鉛直方向）インデックス - {x}: 経度（東西方向）インデックス - {y}: 緯度（南北方向）インデックス 空間IDの配列 　{z}/{f}/{x}/{y} 　例: 20/1/931369/413142 ## 空間IDの各インデックスの算出方法 　経度、緯度、標高、ズームレベルから空間 ID の各インデックス（f, x, y）を算出するための計算式は、以下のとおりです。 lng: 経度 \[10 進度\] lat: 緯度 \[10 進度\], lat_rad: 緯度 \[ラジアン\] h: 標高 \[m\] z: ズームレベル n = 2 ^ z Z = 25 （ボクセルの高さが 1m となるズームレベル） H = 2 ^ Z \[m\] f = floor（n \* h / H） x = floor（n \* （（lng + 180） / 360）） y = floor（n \* （1 - log（tan（lat_rad） + （1 / cos（lat_rad））） / PI） / 2）　 出典：国連ベクトルタイルツールキット（） # 解説 2. ## 地理座標の表記 座標参照系は、電子地図上における地理空間情報の位置を定める基準である「基盤地図情報」で参照されるJGD 2011/(B,L) （日本測地系2011）を使うことを原則とします。 GPS、みちびき、Galileo等のGNSS（全球測位衛星システム）を利用した測位のようにリアルタイム性を重視するような場合には、ITRF（国際地球基準座標系）の使用も可能とします。（ITRFを用いる場合には、あわせて地殻変動の補正（https://positions.gsi.go.jp/cdcs/）が必要となります。） 標高の基準は平均海面と定められており、平均海面を仮想的に陸地へ延長した面をジオイドといいます。JGD 2011/(B,L)においては、日本の標高の基準である「日本のジオイド」2011（GSIGEO2011）」からの垂直方向の距離（高さ）を意味します。日本のジオイドは国土地理院によって定められた標高基準であり、国土地理院によって不定期に更新が行われることから、使用する標高のデータがどの時点の高度情報であるかを解釈できるよう、垂直方向の座標参照系を明示することを推奨します。 小数点以下の桁数は6桁とするのは、0.000001度（小数点以下６桁）あたりの距離は約0.1メートル（赤道直下の場合）であり、日常的な施設等の位置を示すような場面における使用においては十分な精度を持っているためです。なお、6桁よりも桁数が大きい座標データを取扱う場合（GNSSを利用した測位データ等）においては、桁数を6桁に丸める必要はなく、用途に応じて適切な桁数を設定します（電子国土基本図では測量に使うため9桁を用いている）。 ISO6709では、緯度経度を±で表し、高度と参照系を以下のように表記することが可能ですが、緯度経度及び参照系は別項目として記録することを推奨します。 - +35.658581+139.745433+351CRSWGS_84/ 地理座標は、地震や地殻変動等で変化することがあるので、測定時期もあわせて管理します。 ## 空間ID ### 基本方針 本書は、IPA（独立行政法人 情報処理推進機構）が公表した 4 次元時空間情報基盤 アーキテクチャガイドライン(）を参照し、GIF コアデータパーツに含むことが望ましい事項を記載しました。空間IDの詳細な仕様及び最新情報については、出典元である上記ガイドラインを参照してください。 ### 空間ボクセルの高さの基準 空間ボクセルの高さの基準面はジオイド（国土地理院, ）とし、標高0mの面を平面とした座標空間上に空間ボクセルを配置します。空間ボクセルの高さの値は標高値に相当します。 ### 水平方向の空間分割方式 空間ボクセルの水平方向の分割対象とする領域は以下の範囲とします（Webメルカトル図法の範囲）。 　経度（X）：西経 180 度～東経 180 度 緯度（Y）：南緯 85.0511 度～北緯 85.0511 度 水平方向の分割方式については、Webメルカトル図法を使用して地球を平面に投影した領域をもとに行います。インデックスについては、経度（東西方向）を x インデックス、緯度（南北方向）を y インデックスとし、ズームレベルが１つ増えるごとに4分割（経度及び緯度方向にそれぞれ2分割）を繰り返すものとします。 ![](./assets/440-04-image2.png) 図2.水平方向の分割とインデックスの割り当て (） 水平方向の分割のベースとなる地図の測地系は、世界測地系（日本測地系 2011（JGD2011）または WGS84）とします。必要に応じて、適用範囲に採用した測地系を空間 ID に紐付けたデータのメタデータとして明示します。 ### 鉛直方向の空間分割方式 鉛直方向の分割方式については、高さの基準面のズームレベルを0とし、プラス方向及びマイナス方向にズームレベルが増えるごとに2等分割を繰り返します。鉛直方向に分割した各範囲の識別番号には、f インデックスを割り当てます。 fインデックスには、ズームレベルが1つ増えるごとに、プラス方向は0から１つずつ増分し、マイナス方向には-1から1つずつ減分した値を割り当てます。 ![](./assets/440-04-image3.png) 図3.鉛直方向の分割とインデックスの割り当て () ### ズームレベル 　空間ボクセルのズームレベルは zインデックスで表します。zインデックスは最上位を0とし、レベルが1つ増えるごとに空間ボクセルが8分割を繰り返します。地球は球体のため、同一のズームレベルであっても、異なる空間的な位置（緯度・経度・高さ）においては空間ボクセルの実空間上のサイズは異なります。ズームレベル 0～26 における空間ボクセルの水平方向（東西方向・南北方向）、鉛直方向のサイズ例（緯度0度における距離）は以下のとおりです。 ![](./assets/440-04-image4.png) 表1. ズームレベル 0～26 における空間ボクセルのサイズ例 (） # 特記事項 本書は、一般の行政事務利用の観点で検討しています。防災・減災に関する情報提供を行う場合は、被災者支援の拠点になり得る学校や市庁舎等の公共施設について、陸上自衛隊や他国の軍組織間で国際的に利用されているMGRS（UTMグリッド地図）で表記することも適宜検討します。 # 変更履歴
改定年月日 改定箇所 改定内容
2025年3月25日 全体

タイトルを「地理情報」に変更

空間IDの記載を追加

小数点の桁数を変更
2022年3月31日 全体 GIFへの統合にあわせて体裁を変更
2019年3月28日 - 初版決定
2017年12月7日 - α版公開
デジタル社会推進実践ガイドブック DS-445 コアデータパーツ 電話番号 2022年（令和4年）3月31日 デジタル庁

[キーワード]

電話番号、市内局番、データ形式

[概要]

円滑なデータ連携を行うには、データが共通の形式で整えられていることが必要です。本書はコアデータモデルを対象に、電話番号のデータ形式について示すものです。
# 電話番号 電話番号のデータは半角数字で記述し、セパレータには半角ハイフン「-」を利用します。 国際電話用に表現する場合には、「+」の後に国番号、半角スペース後に国内番号の先頭の0を除いた番号とします。国番号はITU-T E.164に従います。 市内局番を（）で表現することがありますが、E.123において、（）は「場合によって使用しない。」ことを意味する記号であるため、市内ではなく市外局番に対して適用します。 - 国内 - (09)9999-9999 - (099)999-9999 - 099999-9999 - (09999)9-9999 - フリーダイヤルの場合 - 0120-999999 - 国際 - +国番号 (09)9999-9999 - （国内番号が2桁、4桁、4桁の場合） 例） | 国際電話番号 | +81 (03)5253-5111 | |--------------|-------------------| 代表電話番号を表したい場合、電話番号と同じセル内で、電話番号の後ろに（代表）等の追記を行わなず、データ項目名を「代表電話番号」「連絡先電話番号」として別項目とするか、「電話番号」「部署」のように2つのデータ項目で表します。 例） | 代表電話番号 | (03)5353-5111 | |--------------|---------------| 携帯電話の場合は()を使わず、セパレータは全て半角ハイフン「-」とします。 - 090-9999-9999 例） | 携帯電話番号 | 090-9999-9999 | |--------------|---------------| # 内線 電話番号と別データ項目で管理することを推奨します。電話番号と同じ1つのデータ項目で記述する場合には、国際標準に従い以下のとおりとします。内線と番号の間にスペースは入れません。 - 国内 - (09)9999-9999 内線999 - （内線の桁数は自由） - 国際 - +国番号(9)9999-9999 Ext.999 - （内線の桁数は自由） # 複数番号の併記 複数番号を併記する場合、半角“スペース/スペース”により区切ることにより併記します。 - (09)9999-9999 / (09)9999-9998 内線も同様とします。 - 内線 999 / 998 / ・・・ / xxx - Ext. 999 / 998 / ・・・ / xxx # 解説 ## 基本方針 ITU-T E.123:Notation for national and international telephone numbers, e-mail addresses and web addresses 及び IETF RFC3966 The tel URI for Telephone Numbers並びに国内の普及状況を考慮して決定します。 ## セパレータ 以下の理由により電話番号の区切りに半角ハイフンを指定します。 - 市外局番の桁数に様々な場合があることから、数字の区切りは必要である。 - ITU-T E.123は、番号の視認性を高めるための仕組みとして番号の区切りにスペースを指定している。一方で、IETF RFC3966はE.123を認識したうえで、スペースを使うべきではないとしている。スペースは意見が相反しているうえ国内で普及していない。 - E.123は、世界の状況を踏まえ「-」の使用を認めている。また、IETFもセパレータの必要性を認めている。 - 国内ではハイフンが主流である。 ## 内線 内線については以下の理由により、データ項目を分離することを推奨します。 - 国内で内線の書き方は統一されたものがない。 - 国外でも内線番号記述は統一されていない。 - データ処理が容易である。 また、1つのデータ項目に内線を記述する場合、E.123に従い、国内で内線を番号表す単語“内線”の後ろに内線番号を記述する方式をとります。国際の場合には“Extension”では長いため、Ext.を使うこととします。 # 変更履歴
改定年月日 改定箇所 改定内容
2022年3月31日

全体

P2

GIFへの統合にあわせて体裁を変更

携帯電話の記述を追加
2019年3月28日 - 初版決定
2017年12月22日 - セパレータをスペースからハイフンに変更
2017年12月22日 P1 フリーダイヤルの追加