451 実装データモデル_行政
デジタル社会推進実践ガイドブック DS-451-1
実装データモデル(行政)
申請・届出
2025年(令和7年)3月25日
デジタル庁
目次
背景と課題
背景
デジタル手続法が2019年5月に制定され、「デジタルファースト」「ワンスオンリー」「ワンストップ」サービスの実現を強力に推し進めることとなりました。
ワンスオンリーとワンストップを実現するためには、組織間で円滑なデータ連携ができるよう、データ項目の標準化が必要となります。過去の情報やベース・レジストリを参照するとき、他の機関に情報を転送するときには、データを連携するための標準的なデータモデルが必要です。
また、申請時に申請内容を証明するために、住民票や印鑑証明書などに代表される証明情報を添付することが多くありますが、これまでは申請情報と証明情報を目視で照合してきました。こうした照合方法では個人差による照合結果に違いが生じることがあり、また、処理できる件数にも課題があります。デジタルファーストの推進のためには、申請情報の標準化に合わせて、証明情報についてもデータの標準化を行うことが必要です。これにより、申請情報と証明情報の照合・審査を機械的に処理できるようになり、より人がすべき業務に人的リソースを再配置することが可能になります。
課題
デジタル技術の発展によりオンライン申請が可能になったにもかかわらず、行政においては、現在も多くの業務で紙による申請が行われています。編集可能な申請書式ファイルの提供やフォームでのオンライン申請等が徐々に実装されつつありますが、オンライン申請にした場合にも、従来の個人・法人が行う申請には以下の課題があり、時間と手間がかかっていました。
-
利用者にとっての課題
-
申請毎に同じ内容の入力を求められる
-
申請毎に書式や項目が異なっている
-
後援名義使用許可のように複数部署に同じ内容の書類を出すのに、書式や提出内容が違うことがある
-
多くの添付書類を求められる
-
入力間違いなどにより差戻しが発生する
-
申請処理時間が長く、処理状況がわからない
-
-
行政職員にとっての課題
-
入力内容の間違いや書類不備による差戻しがあった
-
既に行政が保有する情報と提出した情報が一致せず差戻しが起こる
-
部署を移動すると、類似の申請であっても書式や申請項目が異なることが多い
-
申請内容を添付書類で目視確認する必要があり、負担感がある
-
申請や証明データの活用が十分にできていなかった
-
オンラインで申請するときには、本人確認と申請料等の支払が課題になる場合があります。本人確認と支払は専門性が高いことから、別途、内閣官房のデジタル・ガバメント推進標準ガイドライン群で提供又は今後提供されるガイド等を参照してください。
投資対効果
申請者はこれまで、申請書に手書き、又は、ワープロなどを使用して申請書を作成していました。申請の手続毎に申請内容は異なるものの、法人名や所在地等の共通的な情報の記入を繰り返し求められることがあり、申請書の送付などにも時間を要していました。
一度提出された情報を再利用するワンスオンリーを適用すれば、こうしたことを効率化できます。
例えば、1枚の申請書類を作成するのに毎回ほとんど変わらない基本情報の記入に30分かかっていたとして、過去データの再利用が可能になれば、表示された過去データを確認するだけで済むため2-3分で済み、約1/10に業務時間を削減することができます。
ワンスオンリーは申請を受領する側にとってもメリットがあります。データ項目を細分化して登録しておくことで、単純な入力間違いなどを機械的に修正できるようになります。また、データ項目を細分化しておくことで、地域や産業、人口等といった様々な観点でデータを分析できるようになり、エビデンスに基づく政策立案(EBPM)の実現や、新たな価値を生み出すことが期待できます。
目的と概要
目的
各種申請・届出に必要な情報のデータ形式を標準化し、マスタデータとして蓄積します。それを活用することで申請者の手間の大幅な削減や、審査の自動化等を通じて審査時間の短縮等の内部業務を効率化・高度化するとともに、申請データと資格等の証明データを機械的に照合できるようにし、職員の作業時間を抜本的に短縮させ、データの分析による政策立案の高度化を目指します。
これらを通じて、申請者の利便性の向上と、職員の生産性の向上、審査の高度化を実現します。
概要
個人の場合
申請情報を2つの書式に分け、書式を定義しています。
A票は定型フォーム化することで、情報の再利用性を高めています。また、別途ガイド化されている資格証明データモデルとリンクすることにより資格の確認も容易に行うことができます。
このように定型審査を容易にすることで、職員はB票にある申請内容の確認に集中して取り組むことができます。申請内容に関するB票は、事業目的に応じて各部門が独自に設定可能です。タイトル、概要等の基本情報だけが設定されており、事業の審査内容等に応じて自由に設定可能になっています。
申請終了後、A票のデータは、次回以降のワンスオンリーサービスで活用可能なように、申請システム等に保存されます。
法人の場合
申請情報を6つの書式に分け、書式を定義しています。
A票及びC-F票は定型フォーム化することで、情報の再利用性を高めています。財務情報や社員数による分析などは自動化、半自動化が可能になります。
このため 、職員はB票にある申請内容の確認に集中して取り組むことができます。申請内容に関するB票は、事業目的に応じて各部門が独自に設定可能で、タイトル、概要等の基本情報だけが設定されており、事業の審査内容等に応じて自由に設定することが可能になっています。
申請終了後、A票及びC-F票のデータは、次回以降のワンスオンリーサービスで活用可能なように、申請システム等に保存されます。
また、月次等の定期的な計測データ報告の場合にも、B票に表を含む、又はデータを添付することで報告を効率的に行うことができます。
申請システム等が既存のシステムであり、再利用のために保全できない場合にも、申請者が手元に申請データの複写を保存し、次回の申請時に再利用することも可能です。
法人の申請・届出において、士業法人から申請・届出がされる場合があります。その場合には、役員情報に資格情報が必要になり、さらに資格保有者一覧の添付が求められるため、7書式のデータが必要になります。基本的には一般の法人と同じ申請・届出データで追加項目があるため、法人の申請・届出情報を拡張して申請・届出のデータモデルを定義します。
委任する場合
委任をする場合は、A票の最後に委任情報を付加します。委任先は個人の場合と法人の場合があるため、役割と連絡先情報を組み合わせて表現します。
個人への委任
| 役割 | 委任先の役割や本人との関係性 |
|---|---|
| 委任内容 | 委任する内容 |
| 委任先個人 | 委任先個人に関する情報(コアデータモデル個人型) |
| 委任先個人連絡先 | 委任先個人の連絡先情報(コアデータモデル個人連絡先型) |
法人への委任
| 役割 | 連絡先の役割 |
|---|---|
| 委任内容 | 委任する内容 |
| 委任先法人 | 委任先法人に関する情報(コアデータモデル法人型) |
| 委任先法人連絡先 | 委任先法人の連絡先情報(コアデータモデル法人連絡先型) |
申請データの再利用
A票及びC-F票のデータは、提出時に次回以降も再利用を希望するかを利用者に確認すること(オプトイン)により、次回以降ワンスオンリーサービスで使用するかの選択を可能にします。
以下のイメージとなります。
申請者に、再利用するときのメリット等を明記することが重要です。
届出・報告での活用
行政の手続には届出や報告もあります。その場合にもこのデータモデルが活用可能です。B票の申請内容を、届出や報告の内容にします。定期報告では、表などのデータのみになる場合もあります。
個人用データモデル
データモデルの全体概要図(クラス図)
申請(個人)の実装データモデルの全体概要図は以下のとおりです。
図7 申請(個人)データモデルの全体概要図(クラス図)
概要
個人から行政機関等に提出される申請データモデルです。本申請のデータモデルは、以下の2書式で構成されます。

※委任情報データが付く場合があります
A票:個人申請基本情報
B票:個人申請内容
| 必須項目 | 項目名 | 説明 |
|---|---|---|
| 必 | 名称 | 申請内容のタイトル |
| 必 | 内容 | 申請内容 |
| 更新年月日 | 申請内容の更新日(西暦年月日で、半角数字をハイフンでつなぐ)初回の場合は申請日 |
法人用データモデル
データモデルの全体概要図(クラス図)
申請(法人)の実装データモデルの全体概要図は以下のとおりです。
概要
法人から、行政機関等に提出される申請データモデルです。本申請データモデルは、以下の6書式で構成されます。
※委任情報データが付く場合があります
A票:法人申請基本情報
B票:法人申請内容
| 必須項目 | 項目名 | 説明 |
|---|---|---|
| 必 | 名称 | 申請内容のタイトル |
| 必 | 概要 | 申請内容の概要 |
| 内容 | 申請内容 | |
| 更新年月日 | 申請内容の更新日(西暦年月日とし、半角数字をハイフンでつなぐ) |
C票:財務情報(今後、決算公告データ標準化に合わせて変更予定)
| 必須項目 | 項目名 | 説明 |
|---|---|---|
| 決算年月日 | 決算日(西暦年月日とし、半角数字をハイフンでつなぐ) | |
| 事業期間開始日 | 決算を行った事業期間の開始日(西暦年月日とし、半角数字をハイフンでつなぐ) | |
| 事業期間終了日 | 決算を行った事業期間の終了日(西暦年月日とし、半角数字をハイフンでつなぐ) | |
| 期末従業員数 | 常時雇用する従業員の期末における人数 | |
| 資産合計 | 流動資産、固定資産、繰延資産の合計 | |
| 流動資産合計 | 流動資産の合計 | |
| 現金及び預金 | 現金と預金(当座、定期)の合計 | |
| 受取手形 | 売上債権のうち手形として保有している額 | |
| 売掛金 | 売上債権のうち手形として保有していない額 | |
| 有価証券 | 有価証券の合計 | |
| 棚卸資産 | 販売目的で一時的に保有する商品・製品・原材料・仕掛品の合計 | |
| その他流動資産合計 | 前払金、短期貸付金、貸倒引当金などの流動資産の合計 | |
| 前払金 | 商品を受け取る前に代金を先払いした額 | |
| 短期貸付金 | 決算日の翌日から起算して1年以内に回収される貸付金の合計 | |
| 貸倒引当金 | 貸倒損失になるかもしれない額 | |
| 固定資産合計 | 固定資産の合計 | |
| 有形固定資産合計 | 建物、機械装置、土地などの有形固定資産の合計 | |
| 土地 | 土地の合計 | |
| 無形固定資産合計 | ソフトウェア、のれんなどの無形固定資産の合計 | |
| その他固定資産合計 | 投資、長期貸付金、長期前払費用、関係会社株式などの固定資産の合計 | |
| 貸付金合計 | 長期貸付金と短期貸付金の合計 | |
| 負債合計 | 流動負債、固定負債の合計 | |
| 流動負債合計 | 流動負債の合計 | |
| 支払手形 | 営業取引によって生じた手形債務 | |
| 買掛金 | 営業取引によって生じた未払金 | |
| 短期借入金 | 借入金で1年以内に期限の到来するもの | |
| その他流動負債合計 | 未払金、前受金、預り金などの合計 | |
| 未払金 | 通常の取引に関連して発生した未払金 | |
| 前受金 | 営業収益の前受額 | |
| 預り金 | 後日預かった者又は第三者対して支払うべきもの | |
| 固定負債合計 | 固定負債の合計 | |
| 長期借入金 | 到来期限が1年以上の借入金 | |
| 純資産合計 | 資産から負債を引いた額 | |
| 資本準備金 | 資本準備金 | |
| 売上高 | 製品・商品等の売上高 | |
| 売上原価 | 製品・商品等の原価 | |
| 売上原価内減価償却費 | 製品・商品の製造に関わる減価償却実施額 | |
| 労務費 | 製造に関わる人件費・労務費 | |
| 売上総利益 | 売上高から売上原価を引いた額 | |
| 販売費及び一般管理費 | 販売費及び一般管理費計 | |
| 販管費内減価償却費 | 営業に関わる減価償却実施額 | |
| 人件費 | 従業員給料、役員報酬などの合計 | |
| 営業利益 | 売上総利益から販売費及び一般管理費を引いた額 | |
| 営業外収益 | 主に金融活動に伴う収益 | |
| 営業外費用 | 主に金融活動に伴う費用 | |
| 経常利益 | 本業と本業以外の損益の合計 | |
| 特別利益 | 資産売却益、為替差益等 | |
| 特別損失 | 資産評価損・処分損、為替差損等 | |
| 税引前当期純利益 | 税引前の当期利益額 | |
| 当期純利益 | 税引前当期純利益から法人税等を引いた額 |
D票:法人役員一覧
E票:主要株主
F票:事業所一覧
士業法人用データモデル
データモデルの全体概要図(クラス図)
申請(士業法人)の実装データモデルの全体概要図は以下のとおりです。

図9 申請(士業法人)データモデルの全体概要図(クラス図)
概要
士業法人は、資格保有者の一覧が必要になるなど、一般的な法人とデータ項目が異なります。法人用データの役員一覧であるD票を拡張するとともに、資格保有者情報のG票を追加し、以下の7書式でデータモデルは構成されます。

A票:法人申請基本情報
法人用データモデルを使用します。
B票:申請内容
法人用データモデルを使用します。
C票:財務情報(今後、決算公告データ標準化に合わせて変更予定)
法人用データモデルを使用します。
D票:士業法人役員一覧
E票:主要株主
法人用データモデルを使用します。
F票:事業所一覧
法人用データモデルを使用します。
G票:資格保有者(従業員)一覧
データモデルの活用イメージ
データモデルを活用した申請のライフサイクルは、以下の流れになります。この中核になるのが申請データで、他の様々なデータとともに活用されます。
標準化されたデータモデルを活用することで、メリットとして以下のシナリオが考えられます。
機能イメージ
自動入力
A社が電子申請を行う際、ログイン後に以前使用した自社の法人情報が自動的にサイト上に表示され、再度入力する手間をかけずにスムーズに次のステップに進むことができます。
ワンストップ
B社が複数の手続の申請を行う際、わかりやすい共通フォームを使って最低限の入力操作を一か所で行うだけでワンストップ手続が行われるため、多くの時間を費やすことなく全ての申請を完了させることができます。
自動照合
C社が申請書B票の中に資格情報を記入します。受付システムが、当該資格情報サイトにAPIで自動照合を行うことで確認が行われ、自動的に次の審査に移行することができるようになります。
サービスイメージ
個人向け
児童手当の場合は、A-B票及び所得の要件など資格情報の組合せで申請が行われています。
次回申請時は、A-B票の内容を確認・修正の上で再提出することが可能になります。また、小児医療証など他の申請を行う場合、A票及び重複する資格情報の提出は不要になります。(ワンスオンリー)
法人向け
法人が行うイベントの後援名義申請の場合は、A-C票及び添付のイベント情報、イベント収支計画の組合せで申請が行われています。(前回のイベントがある場合は、その報告も添付)
同様のイベントを次回申請する場合には、A-C票の内容を確認・修正の上で、新規のイベント情報、収支計画を添付し再提出することが可能になります。前回のイベント終了時に報告済みの場合は報告書の提出は不要になります(ワンスオンリー)。
解説
個人向けデータ標準
申請データに参照する標準がないため、自治体の様々な申請書の様式を参考に作成しています。
法人向けデータ標準
申請データに参照する標準がないため、A票及びC-F票のデータは、経済産業省における従来の申請データフォーマットを複数分析し標準化しています。
財務情報を示すC票は、これまでの申請で税務申告書のコピーを添付する場合が多かったことから、税務申告データをベースに項目を選定し、経営分析が可能なように、中小企業庁ローカルベンチマークのデータ項目を付加しています。税務申告データを活用することにより、納税証明書データとの突合で、財務情報の真正性を確認することが可能になります。
付録
-
451-1-1_申請(個人)データモデル_クラス図.pdf
-
451-1-2_申請(法人)データモデル_クラス図.pdf
-
451-1-3_申請(士業法人)データモデル_クラス図.pdf
変更履歴
デジタル社会推進実践ガイドブック DS-451-2
実装データモデル(行政)
証明・通知
2025年(令和7年)3月25日
デジタル庁
目次
背景と課題
背景
資格や納税等に関する証明情報は各種申請の際に添付書類として求められることが多くあります。その証明内容は多岐にわたり、資格証明、納税額等だけではなく、契約の請書、表彰、通知等も一種の証明情報といえます。
証明情報はその申請から廃棄まで、発行者、申請者と受理者が関与するライフサイクルを形成します。これまで、証明情報は主に紙によって発行されてきましたが、「デジタルファースト」、「ワンスオンリー」、「ワンストップ」サービスの実現の観点から、デジタル情報の活用を前提に、ライフサイクル全体を考慮した業務を検討して行く必要があります。
証明情報をPDFで添付することもあるため、AI-OCRやRPAのような、コンピュータが文字認識し、その処理を自動化する技術が注目されています。しかしこれらは文字や図表等の認識精度の面からデータの品質低下を招く要因になっており、コストも余計にかかっています。そのため、添付書類自体をデータ化し、API等を通じて自動処理する仕組みが求められています。
課題
添付情報は、紙で提出するのが主流であったため、データの標準化がされてきませんでした。納税証明のようにデジタルデータで提出できる証明書もありましたが、PDFである等の理由で再利用が困難でした。また、住民票のように証明内容に外字を含むため、PDF化しコンビニエンスストアでしか印刷できないといった制約をかけているものもありました。こうしたことから、証明には以下のような課題があります。
-
証明での利用者にとっての課題
-
証明取得に窓口に行くか郵送する必要があり手間がかかる
-
申請先の数だけ証明情報を取得する必要がある
-
添付に手間がかかる
-
-
証明での行政職員にとっての課題
-
添付書類不備による差戻しがある
-
申請内容を添付書類で目視確認する必要がある
-
証明データの活用が十分にできていない
-
デジタルデータ化すると改ざん等のセキュリティ上の課題があるのではないかという指摘がありますが、認証や電子証明書の技術を活用することで、紙での認証以上のセキュリティを確保することができます。また、課題解決にあたってはWebサイト等で正しい情報を確認できる仕組みにして行くことも重要です。
投資対効果
申請者はこれまで、証明書を取得する作業コストと、送付するための作業コストをかけていました。さらに、200円の証明書を5か所に提出するときには5通の証明書を取得する必要があり合計1,000円の費用がかかっていました。これが証明情報をデータ化することで、インターネットがあればどこからでも取得可能で複製も可能なことから、取得に関する人件費はもちろんのこと、証明書費用、送料等の直接費用も削減することができます。
申請を受領する側にとってもメリットがあります。証明情報のデータ項目が細分化されることで、申請書の該当項目と自動照合することができるようになります。さらに、証明内容によっては申請を評価するための評価点の算出が自動化できる場合もあります。
図 3 証明データの自動照合の例
目的と概要
目的
証明、通知データの標準化を通じて、審査の自動化、迅速化、正確性の向上の実現を目指します。申請者の利便性の向上のみならず、行政職員の生産性の向上、行政の透明性の向上も実現できます。
大幅な効果を上げるためには、証明、通知データの標準化だけではなく申請データと一緒に活用することが重要です。申請の流れ全体の中で効率化を目指します。
概要
証明、通知情報は「宛先」「証明内容」「発行情報」の3ブロックで構成されます。
申請を行うときに、申請情報とともに証明情報を送信することも可能ですが、申請受理者が資格番号などをキーに、証明機関のサーバーにAPIで検索することで証明情報を取得し、自動照合をすることが可能になります。こうすることで紙の証明書を廃止でき、申請者、審査者の双方の効率化を図ることができます。
証明内容のデータ項目は業務に応じて自由に設定可能です。宛名と発行者、発行日に加えて、資格の証明では、資格の種類、クラス、有効期限等が証明項目であり、領収書では、適用項目や金額が証明項目になります。
証明、通知データの再利用について
証明、通知情報は、申請者の希望(オプトイン)により、次回申請用に再利用(ワンスオンリー)できるようにするか検討し、再利用可能にする場合は、証明情報を提供するAPI等を提供し最新の証明情報が確認できるようにします。こうすることで申請者、審査者の双方の業務効率が向上します。
データモデル
データモデルの全体概要図(クラス図)
証明・通知の実装データモデルの全体概要図は以下のとおりです。
概要
証明、通知のデータモデルは、以下になります。
活用場面イメージ
申請のライフサイクルの中で送金データに関する証明、手続完了などの通知、申請された証明内容等、いくつかの場面で証明情報が活用されます。
機能イメージ
自動照合
申請データと送金データの照合は、申請データと領収書や印紙の金額を目視で照合するのではなく、法人番号や法人名の確認、手数料と送金データの送金額とが一致するかの確認が自動で行われます。
また、申請データとともに資格証明データが送付されてきた場合には、個人氏名や法人名、資格種別等の自動照合を行います。資格データは、データで送付される場合と、資格証明サーバーに証明書番号などを基に確認しに行く方式があります。
通知
通知は、証明、通知のデータモデルに従ったデータが送られてきます。法人等では、承認が下りたときに自社システムでその通知データを自動判別することで、社内の発注プロセスに自動的に進む等の処理の効率化、迅速化を図ることができます。
サービスイメージ
個人向け
例えば資格証明申請の場合、申請が行われ承認が行われると、通知として資格証明を自動交付することが可能になります。また、このデータを行政機関で活用することが可能となります。
法人向け
後援名義申請の場合、申請が行われ承認が行われると、後援名義承認の通知を自動交付することが可能になります。
解説
データ標準
基準・証明データ
証明データは、欧州の証明データの標準であるCCCEV(Core Criterion and Core Evidence Vocabulary Version 1.0.0)との整合性を確保しています。
CCCEVでは、単に証明できるだけではなく、その根拠についても詳細に記述できるようになっています。
資格証明データ
資格証明のデータ標準にはIMSグローバルによるオープン・バッジがあります。
付録
全体概要図として掲載したクラス図について、大きなサイズのものは別添の「451-2-1_証明・通知データモデル_クラス図.pdf」を参照してください。
変更履歴
| 改定年月日 | 改定箇所 | 改定内容 |
|---|---|---|
| 2025年3月25日 | 3. データモデル | コアデータモデル改訂に伴う修正 |
| 2022年3月31日 | 全体 | 正式版決定 |
| 2021年6月4日 | - | β版公開 |
デジタル社会推進実践ガイドブック DS-451-3
実装データモデル(行政) 事例
2025年(令和7年)3月25日
デジタル庁
目次
背景と課題
背景
行政機関では取り組んだ事業の内容等を事例集として公開しています。事例集には成功や失敗等の経験が記録されており、個人や法人がサービスや各種活動を行う上で参考になります。しかし、行政機関の各部局で制度毎に独自に作成されていることが多く、それを組織全体の知識として活用することができていませんでした。
また、類似の事例集を地方公共団体などが作成していた場合にも、書式が異なることもあり、一緒に活用することが難しい状況でした。そのため、複数の事例集のデータを組合せて使用したり、AI等で分析したりすることが難しく、十分に管理・活用されていない状況にありました。
課題
これまで事例集の書式は統一されておらず、複数の事例集を集めても比較や検索などが行いにくいという課題がありました。また、記述欄を項目立てず自由記述とした場合には、取り組みのポイントなど分析に必要な事例内容が明確に記載されないことがあり、ノウハウとしての価値が十分に発揮できていない場合がありました。
-
事例作成者にとっての課題
- 取り組み内容の記述欄に何を書いてよいのかわからない
-
事例集編集者にとっての課題
-
各事例の記述レベルが異なる
-
重要なポイントが書かれていないことがある
-
-
事例集の利用者にとっての課題
-
目的に合わせて事例を検索しにくい
-
事例によって記述が異なり、知りたいポイントがわかりにくい
-
知りたいポイントが書かれていない
-
投資対効果
事例集を作成するには企画、作成、編集、印刷・配布等のコストがかかります。単に事例集を作るだけではなく、検索性を高め、見てもらい、使いこなしてもらうことで、事例集の価値をより高めることができます。
既存の事例集フォーマットを本事例データモデルに合わせることで、従来とほぼ同じ投資で、より多くの政策効果をあげることができるようになります。
目的と概要
目的
行政機関をはじめ多くの組織でノウハウ継承や活動促進のために事例集を作成しています。本データモデルに沿って記述内容を整えることで、事例作成者の作成作業における時間と手間を大幅に削減するとともに、必要な情報を抜け漏れなく入力できるようになります。
また、本データモデルを使うことで必要な事例を正しく素早く検索できるようになります。これらを通じて、事例の活用を広げ、効率化の促進や社会全体の活性化を図ることを目的としています。
概要
具体的には、事例集に含まれる定型的な部分を共通書式化するとともに、事例の内容を細分化して、項目毎に事例を記述できるようにしています。以下に従来書式との変更点の概要を記載します。
上記では、内容の記述欄が細分化したため記述項目が増えて入力の手間が増えたように見えますが、実際には各データ項目の内容毎に対話形式で記述していくことができるため、入力は容易になり、読み手にもわかりやすくなるといった利点があります。
また、収集しようとしている事例がこの書式にあるデータ項目に該当しない場合には、データ項目を追加して事例データモデルを拡張することもできます。
逆に、データ項目が事例にそぐわない場合には、項目自体を省略したり空欄にしたりすることができます。事例集や事例データベースで空欄の事項は、UI上ではデータ項目の表示を項目も含めて非表示にすることですっきりと表示させることができます。
事例の紹介を記事化したり、中見出しをつけたりする事例集もあります。そのような読み物形式の事例集は、このような定型的なデータ定義では表現が難しいです。
例えば、データベースに基本事項を入れた上で、注目事例だけ別途記事型の詳細経緯等も含んだ事例を作る等、組合せて使用することで、検索も可能、かつ、目的に合った伝え方ができるようになります。
データモデル
データモデルの全体概要図(クラス図)
事例集の実装データモデルの全体概要図は以下のとおりです。
事例集データモデル(カタログ情報)
事例を集めて事例集や事例データベースにする時の、事例集や事例データベースに対する解説(カタログ)情報のデータモデルは以下の通りです。
| 項目名 | 説明 |
|---|---|
| データカタログ名 | 事例集等の冊子、データセット名 |
| データカタログ説明 | 事例集等の概要(300文字以内で記入) |
| データカタログ作成者 | 事例集等の作成者名 |
| 発行年 | 事例集等の発行年(西暦の半角数字4桁で記入) |
| ライセンス | 事例集のライセンス(CCライセンス等の情報を記入) |
| 言語 | 事例集の言語を英字3文字コードで記入。JPNは省略可能。 |
表1 事例集をカタログ情報として表した場合のデータ項目
事例データモデル
個々の事例を記述するデータモデルです。個人の事例の場合には、対象組織を「居住地」「年代」等、事例集にあった項目に変更します。また連絡先情報も個人の場合は不要です。
活用場面イメージ
事例集を作成する場合の流れは以下のようになっています。事例データモデルを使うことで、事例作成者は質問に答える形式で事例を書いていくことができます。
機能イメージ
事例記述
事例作成者は、事例を記述する場合に、自由に作文をしていくのではなく、背景、目的、挑戦したこと、その結果と、ヒアリングを受けているように順次記述していくことができます。
事例確認・修正
事例作成者は、事例の各項目を確認することで、事例利用者に示唆があるかどうかの確認をすることが容易になります。また、事例集編集者は、修正のポイントを示しやすくなります。
事例集の編集
事例のデータ項目の形式が決まっているため、事例集編集者は、書式やスタイルを決めるだけで簡単に事例集を作成することができます。
サービス例
中小企業向け支援制度の提供を行う「ミラサポplus 事例ナビ」では、本データモデルのサブセット化をしてサービスを提供しています。本モデルのすべてのデータモデルを適用しようとしても、既存の事例情報の元データは十分にデータ細分化ができていないことから、まずは、現在のデータ粒度を基に、データ項目を最小化してサービスを実現しています。
| 項目名 | 説明 |
|---|---|
| ID | 事例IDを記入 |
| タイトル | 事例のタイトル |
| 事例実施年 | 事例を実施した年(制度利用年) |
| 事例の場所 | 事例を実施した場所の都道府県名。全国で実施した場合には、「全国」と記入 |
| 組織名 | 法人名。事業所の事例の場合は法人名に加えて事業所名も記入 |
| 法人番号 | 法人に割り当てられた一意の番号(13桁) |
| 組織種別 | 法人の種別を入力する(「5 解説」で示す国税庁の組織種別を選択して記入) |
| 正社員数 | 決算期の正社員数 |
| 従業員数 | 決算期の従業員数(常時雇用) |
| 売上高 | 決算期の法人の売上高(数字) |
| 事業内容 | 事例を提供する組織の概要(300文字以内) |
| 本社所在地 | 本社所在地の都道府県名。外国会社等の場合は、国名等を記入 |
| 資本金 | 決算期の資本金(数字) |
| 設立年月日 | 登記の日(西暦年月日とし、半角数字をハイフンでつなぐ) |
| 日本標準産業分類 | 大分類。可能な場合には中分類を記入 |
| 行政サービス分類 | 補助金、税制等の行政サービス分類(「5 解説」で示す行政サービス分類を選択して記入) |
| お困りごと分類 | 事例の取り組みの元となるお困りごと(事例ナビでの追加事項) |
| テーマ | 「エネルギー」等、事例集内に分類したテーマがある場合に記入 |
| キーワード | 事例にキーワードがある場合に記入。複数ある場合には半角セミコロン「;」区切りで列挙。 |
| 取り組み理由 | 事例の取り組みに着手した理由やきっかけ |
| 取り組み内容 | 取り組み内容の詳細 |
| 成果 | 事例の取り組みで達成された成果 |
| 普及 | この取り組みを普及させるために活動していることがあれば記入 |
| 利用した制度 | 利用した制度 |
| 協力者 | 協力者や共同研究者がいる場合に記入 |
| イメージタイトル | 事例の写真や図のタイトル |
| イメージファイル | 事例の写真や図のイメージファイル名 |
| ビデオタイトル | 事例の動画のタイトル |
| ビデオURL | 事例の動画のリンク先のURL |
| 関連URL | 取り組みに関する組織の関連ページのURL |
| 担当部署 | 担当部署名 |
| 電話番号 | 担当部署の電話番号(市外局番にカッコをつけ、以降の番号はハイフンで接続。半角) |
| メールアドレス | 連絡先のメールアドレス |
| 住所 | 連絡先の住所を記入 |
| Webフォーム | 連絡先のWebフォームを記入 |
| 公開状態 | Webサイトへの公開、非公開を記入 |
| 公開日 | 本事例の初公開日を記入。YYYY-MM-DDの形式で記入 |
| 公開終了日 | 本事例の公開終了日を記入。YYYY-MM-DDの形式で記入 |
| 最終更新日 | 本事例の最終更新日を記入。YYYY-MM-DDの形式で記入 |
| 管理グループ | この事例データの管理者の情報を記入 |
| 事例集 | この事例が掲載されている事例集名を記入 |
表3 ミラサポplus 事例ナビでのデータ項目
解説
データ標準
このデータモデルは、政府が整備するデータ標準である共通語彙基盤、インターネット上のデータカタログの標準であるDCATやインターネット上のデータ項目標準であるschema.orgのCreativeWorkを参考に整備しています。
また、内容の詳細項目の設定は、国連公共サービス賞のデータモデル、OECDのOPSI(Observatory of Public Sector Innovation)のデータモデルを参考に設定しており、事例を翻訳することで国際的にも活用が可能です。
※ OPSIの項目にある「Innovation status」は、日本の事例集は基本的に導入「Implementation」フェーズなので省略。
※ +で表した項目は、本ガイドの複数項目を合わせることでOPSIに対応
法人種別
組織の種別項目に記述する法人の種別は、法人番号を付番する国税庁が法人番号公表サイトで使用する以下の種別を使います。
-
国の機関
-
地方公共団体
-
株式会社
-
有限会社
-
合名会社
-
合資会社
-
合同会社
-
その他の設立登記法人
-
外国会社等
-
その他
付録
全体概要図として掲載したクラス図について、大きなサイズのものは別添の「451-3-1_事例データモデル_クラス図.pdf」を参照してください。
変更履歴
| 改定年月日 | 改定箇所 | 改定内容 |
|---|---|---|
| 2025年3月25日 | 3. データモデル | コアデータモデル改訂に伴う修正 |
| 2022年3月31日 | 全体 | 正式版決定 |
| 2021年6月4日 | - | β版公開 |
デジタル社会推進実践ガイドブック DS-451-4
実装データモデル(行政)
行政サービス・制度
2025年(令和7年)3月25日
デジタル庁
目次
背景と課題
背景
国、都道府県、市区町村は、多くの行政サービス、支援制度、補助金(以降、行政サービスと表記)を個人や法人に対して提供しており、その数は数千種類ともいわれています。これらの説明は紙で行われることが多く、国、都道府県、市区町村がそれぞれガイドブックやリーフレットなどを発行しています。これらのガイドブックは記述項目や分類が異なり、行政サービス間の比較検討が難しくなっています。
国際的には、行政サービスの分類方法(サービスカタログ)や記述方式(行政サービス情報)の統一が進められており、広域での情報提供を行いやすい環境を整備しています。
課題
どのような行政サービスや支援制度があるのか知りたい、自分が活用できる行政サービスや支援制度は何か知りたいという意見は、行政サービスに関する調査を行うと常に上位にあげられています。利用者のために作った制度にもかかわらず、そのサービスや支援制度の存在が知られておらず、その行政サービスの利用率が低いと指摘されることもあります。
特に、大規模災害後には緊急で支援制度などが数多く提供されますが、これらの情報は、各組織で紙冊子が作られ、検索性が低い状況で配布がされています。
また、地方公共団体等、様々な機関が支援制度情報の冊子などを作っており、利用者がわかりやすいように行政サービスのタイトルや説明を書き直したり、自治体独自の加算金を加えた派生形の行政サービスを作ったりすることがあります。このように情報内容に様々なバリエーションがあることにより、行政サービスの全体像がわかりにくくなっている場合もあります。
利用者にとっての課題
・行政サービスや支援制度を知らない、見つけられない
・各支援制度情報の記述内容が不統一で分かりにくい
・類似の支援制度が複数組織から公表されていてわかりにくい
・同じ支援制度が複数個所から違う表現で情報提供され、複数の支援制度に見える
・支援制度を知った時には申込みが終わっていることがある
行政職員にとっての課題
・情報が利用者に届かないため、利用(政策の普及)が進まない
・支援制度広報に予算が必要だが、十分にない
・周辺自治体などの支援制度情報を調べたくても調べられない
・国の支援制度を探すのが大変
・災害時に大量の追加の支援制度が出るが、手作業で対応している
投資対効果
行政サービスに関する情報の提供は情報利用者の視点ではなく情報提供者の視点で行われることが多いため、行政サービスの利用者は、活用できるサービスを探すために多くの時間をかけたり、支援制度活用の機会を逃していたりすることさえあります。これまで、サービスや制度を探す際には、市区町村、都道府県、国、支援機関の情報を収集し、利用できそうなサービスや支援制度を比較検討し、更に、支援機関に相談することもあります。これら様々な支援機関から提供される支援制度を一元的に検索できるようにすることで、全ての利用者の時間節約になるとともに、早期の行政支援の活用によりその効果を享受することが可能になります。
行政サービスや支援制度の提供部門にとってもメリットがあります。定型データモデルに制度情報を記入する事務コストは従来の業務とほとんど変わりませんが、定型のデータモデルに支援制度を記入することにより、政策の広報が効率的にできるだけでなく、内容が分かりやすくなるため問い合わせが減るという効果もあります。
利用者が相談に訪れる相談機関や支援機関は、利用者に合わせた制度が探しやすくなり、的確な支援をアドバイスしやすくなります。支援対象者の業種に特化したガイドブックの作成等をすることもできるようになります。
特に災害時には、日々追加される支援制度を効果的に情報提供・収集できる必要があることから、このように定型データモデルによる情報提供は非常に大きな価値を生み出すと考えられます。
目的と概要
目的
行政サービス情報を正確かつ効率的に利用者に届け、活用の促進を図ることを目的とします。
利用者の業務を効率化するだけではなく、提供する行政機関の問い合わせ対応業務の削減等も実現します。
概要
行政サービスを紙の冊子でもインターネット経由でも活用しやすいデータとして整備します。そのために、タイトルや連絡先等のデータ項目の統一化と記述方式の統一を行います。
行政サービスは、社会変化に合わせて日々追加されますが、行政サービス情報に付加されたタグ等により、利用者の要望に応じて追加配信をすることも可能になります。
デジタルデータでの整備
行政サービスの検索性を高めるためには、データ化が欠かせません。検索性を高めるために、従来の記述内容のうち、特定の情報については別項目でデータを登録する場合もあります。
データ表記の簡素化
単にデータ項目を統一するだけではなく、利用者にわかりやすくするためにデータ表記の簡素化を行います。日付の表記項目を統一するのをはじめとして、補助率は、1/3補助や5/12補助などのわかりにくい分数表現ではなく、小数点以下1桁表示にするなどの工夫が必要です。制度によっては、条件により補助率を複数持つ場合がありますが、最大補助率とそれを補足する自由記述を組み合わせることで、検索性を高めつつ詳細情報も伝える工夫をする必要があります。
データ基準の簡素化
データの記述項目に曖昧性がある項目を明確化します。これまで、補助金などの説明が、補助の対象購入額なのか、補助金として最大支給額なのかが行政サービス毎に異なる記述をされていました。また、金額や人数の記載では、「以下」と「未満」が混在しています。いき値の扱いに関する情報を内容説明の中で明確にする必要があります。
行政サービスIDによる管理
制度間の関連性を明確にするために制度IDを付与します。元の制度の内容を変えずにわかりやすい文書に書き下す場合や加算などを行う場合には、親の制度IDを記述することで、その関連性がわかるように管理します。
行政サービスIDは、制度所管組織が付与する必要があります。制度所管組織は、制度名の変更や制度内容の軽微な変更をした時にも、同じ制度IDを使う必要がありますが、制度の大幅な変更がある時には新しい制度IDを付与することも検討する必要があります。
地方公共団体は、国の制度の派生の制度を作る時には、IDの連携によりその関係性を明確にすることで住民にわかりやすく情報提供することができるようになります。また、地方公共団体が独自に制度を制定する時には、地方公共団体コードと組み合わせた制度IDを独自に発行することとなります。
データモデル
データモデルの全体概要図(クラス図)
行政サービス・制度の全体概要図は以下のとおりです。
データモデルの項目定義
事例
ミラサポplus 制度ナビ
中小企業向け支援制度の提供を行う「ミラサポplus 制度ナビ」では、本データモデルのサブセット化と中小企業向けの拡張を行ってサービスを提供しています。本モデルのすべてのデータモデルを適用しようとしても、現在の支援制度情報の元データが十分にデータの細分化ができていないことから、まずは、現在のデータ粒度を基に、データ項目を最小化してサービスを実現しています。また、独自項目をいくつか付与しています。
| 項目名 | 説明 |
|---|---|
| 制度集 | 情報源の制度集がある時、または、制度集としてグループ管理したい時に記入 |
| 中小企業施策利用ガイドブックページNo | 中小企業施策利用ガイドブックに掲載されている制度の場合、そのページ番号を記入 |
| 特定施策区分 | 中小企業庁の特定施策の場合に施策名を記入 |
| 関連制度 | 関連する制度 |
| 企業規模 | 対象企業の企業規模 |
表2 ミラサポplus 制度ナビで追加された独自項目
個人の制度情報の場合は、「事業ステージ」「お困りごと」「サービス種別」の部分が個人向けのステージ情報等になります。
解説
データ標準項目について
欧州の行政サービス情報のデータ標準であるCPSVと東日本大震災後に復旧・復興支援制度データベースとして運用してきたデータ項目、中小企業施策利用ガイドブックの情報内容を基に作成しています。
サービスカタログモデルに基づくタグ
情報の検索性を向上させるためサービスカタログモデルに基づくタグを付与しています。詳細については「491-1_コード_サービスカタログ.docx」を参照してください。
付録
全体概要図として掲載したクラス図について、大きなサイズのものは別添の「451-4-1_制度データモデル_クラス図.pdf」を参照してください。
変更履歴
| 改定年月日 | 改定箇所 | 改定内容 |
|---|---|---|
| 2025年3月25日 | 3. データモデル | コアデータモデル改訂に伴う修正 |
| 2022年3月31日 | 全体 | 正式版決定 |
| 2021年6月4日 | - | β版公開 |
デジタル社会推進実践ガイドブック DS-451-5
実装データモデル(行政) イベント
2025年(令和7年)3月25日
デジタル庁
目次
背景と課題
背景
行政機関は政策を推進するため様々なイベントを主催したり、関連する民間イベントを後援したりしています。しかしその広報範囲は限定されており、十分に政策効果を上げているとは言えません。
イベントの種類にも様々なものがあり、主催・後援イベント以外にも、工場見学のような常設イベントを一覧で提供している場合もあります。
また、審議会の案内、施設公開等もイベントであり、災害時の活動も一種のイベント情報として効率的な配信をすることが可能です。
課題
主催イベントや後援イベント等、それぞれの行政機関が個別に情報を発信しているため、情報の公開場所が統一されておらず、イベント対象者に対して的確に情報が届いていません。
-
利用者にとっての課題
-
イベント情報を知らなかった
-
イベント情報の提供方法がバラバラで収集するのが難しい
-
メール等で自らに関係のないイベント情報が案内される
-
イベント事後に記事などを見るが、事前に情報を提供してほしい
-
-
行政職員にとっての課題
-
広報しているのに十分集客できていない
-
後援情報は、ポスター等に記載するだけで効果が十分ではない
-
投資対効果
行政機関主催のイベントに関する広報は、Webサイトに載せているだけの場合が多く、イベント情報のデータを様々な媒体で活用できるようにして、体系的に広報することにより、手間と費用を抑えつつ、より大きな広報効果を上げることが可能になります。また、後援イベントを統一したサイト等から情報を提供することで、効果的に周知し政策効果を上げることができます。
目的と概要
目的
個人や法人に関連したイベント情報を必要な利用者が容易に発見・入手できるように、イベントデータを構造化してタグをつける等の標準化を行います。イベント情報を標準化することで、情報流通をしやすくしてイベントの活用を促進します。
イベント情報の発信方法を改善することより、政策を必要な人に的確に伝えることを目的とします。
概要
イベント情報では、いつ、どこで、誰が、どのようなテーマでイベントを行うかということが重要な情報項目になります。イベントには広域で行うイベントがあったり、情報化月間などという上位のイベントがあったり、イベント内で行うサブイベントがあったりと様々な条件があり、標準的なデータを作るのが難しいと言われてきました。
一般的なイベントは以下のように表すことができます。また、定期開催イベントと単独開催のイベントでも記述方法が変わってきます。
このようなイベントのデータモデルを使うことで、イベント主催者は、様々な関係者へのデータ公開を効率化することができます。また、詳細な必要情報を公開することができるため、問い合わせを減らすことができます。
海外の政府機関では、府省主催のイベント以外に、府省が後援をしている民間イベントも府省のWebサイトのトップページで案内しているところもあります。
また、多くのイベントを公表する場合には、画面で見やすいように一覧化することが重要になります。主要データを抜粋して簡易的に一覧表示させ、別途整理した詳細情報に誘導する等の工夫をしていきます。
データモデル
データモデルの全体概要図(クラス図)
イベントの実装データモデルの全体概要図は以下のとおりです。
データモデルの項目定義
項目定義はコアデータモデルのイベントと同一となっています。内容の詳細は、「43C_コアデータモデル解説書_イベント.doc」を、また項目の記入例や形式などの詳細は「438_コアデータモデル_DMD.xlsx」をあわせて参照してください。
活用場面イメージ
イベント情報収集時のイメージ
各行政機関では、イベントを自ら主催する場合と、第三者が行うイベントを後援する場合があります。
主催イベント
主催イベントは、本データモデルのイベント情報に従い記入します。府省でのイベント案内ページ等に掲載、若しくは、APIで公開することで、広範囲へのイベント情報の公開が期待されます。
後援名義イベント
後援名義の依頼者に、申請データの一部として提出をしてもらいます。府省でのイベント案内ページ等に掲載、若しくは、APIで公開することで、広範囲へのイベント情報の公開が期待されます。
各種会議への適用イメージ
審議会などの会議開催は、現在、各府省のWebページに掲載されていますが、イベント情報提供モデルを使って提供することで、会議内容を広く広報することが可能になります。以下の表は会議をイベントの一種と捉え、イベントのデータモデルをベースにカスタマイズした会議のデータモデルの例です。
| 項目 | 説明 |
|---|---|
| ID | 会議を識別するユニークなID |
| 会議名 | 会議の名称 |
| 概要 | 会議情報として公開可能な情報(70文字以内) |
| 説明 | 会議情報の詳細 |
| イベント種類 | 「委員会」「検討会議」など、会議の種類を記載 |
| 対象者 | 会議に関連する人の情報 |
| 詳細URL | 会議情報を公開しているURLを記載 |
| Web開催 | Web開催の開催形式(現地開催のみ、オンライン、ハイブリッド)など |
| 開催日 | 会議の開催日 |
| 開始時刻 | 会議の開始時刻 |
| 終了時刻 | 会議の終了時刻 |
| 日時説明 | 定型で表せない条件を記入 |
| 場所名称 | 会議室名 |
| 主催団体 | 会議主催者 |
| 申込方法 | 当日参加可、要事前申込み等の申込み情報 |
| 開催場所住所 | 開催場所住所の情報(コアデータモデル住所) |
| 連絡先 | 主催や申込の連絡先(コアデータモデル連絡先) |
| 備考 | 特記事項があれば記入 |
表1 イベントをベースにした会議のデータモデルの例
災害時支援活動への活用イメージ
災害時の各種支援活動は、データ構造がイベントのデータ構造と同じです。イベント情報と同じ構造で情報発信することで、災害時に効率的で正確な情報発信が可能になり、その情報を広域で集約するなどの活用が可能になります。また、平時用のイベント情報配信の仕組みを使って被災者に情報を配信することができます。
| 項目 | 説明 |
|---|---|
| ID | 活動を識別するユニークなID |
| 名称 | 支援活動の名称 |
| 概要 | 支援活動情報として公開可能な情報 |
| 説明 | 支援活動の詳細情報 |
| イベント種類 | 「炊出」、「給水」、「風呂」、「医療」、「ガソリン」、「給電」、「その他」等から選択 |
| 開催日 | 支援活動の開催日 |
| 開始時刻 | 支援活動の開始時刻(24時間表記とし、時・分の半角数字を半角コロンでつなぐHH:MM形式) |
| 終了時刻 | 支援活動の終了時刻(24時間表記とし、時・分の半角数字を半角コロンでつなぐHH:MM形式) |
| 場所名称 | 支援活動の会場名がある場合に記入 |
| 場所住所 | 支援活動の会場住所(コアデータモデル住所) |
| 対象者 | 支援活動の対象となる人の情報 |
| 集合(受付)場所 | 集合場所や受付場所があれば記載 |
| 提供者(主催者) | 支援活動の提供者 |
| 連絡先 | 当日の連絡先情報(コアデータモデル連絡先) |
| 詳細URL | 概要等を掲載したURLがあれば記載 |
| 料金有無 | 支援活動に必要な費用の有無 |
| 備考 | 特記事項があれば記入 |
表3 イベントをベースにした災害時支援活動のデータモデル
体験イベントでのカスタマイズ例
体験イベントは、学校の課外活動、体験型旅行等の大きなニーズがあります。イベントのデータモデルに加えて以下の情報をカスタマイズ項目として付加することで、情報発信を充実させることができます。
| 項目 | 説明 |
|---|---|
| 対象年齢 | 年齢。学年を記入する場合もある |
| 体験種類 | 「学ぶ」、「ふれる・感じる」、「体を動かす」、「奏でる」、「乗る」、「見る」、「作る・描く」、「収穫・採集する」、「その他」から選択する |
| 体験対象 | 体験対象 |
| 体験内容 | 体験内容 |
| その他条件 | 身長120cm以上などの諸条件を記入 |
表4 体験イベントで付与するカスタマイズ項目の例
付録
全体概要図として掲載したクラス図について、大きなサイズのものは別添の「451-5-1_イベントデータモデル_クラス図.pdf」を参照してください。
変更履歴
デジタル社会推進実践ガイドブック DS-451-6
実装データモデル(行政) 報告書・会議資料等
2025年(令和7年)3月25日
デジタル庁
目次
背景と課題
背景
行政機関では審議会や調査研究など多くの報告書が作成されています。これらの報告書は世界の最先端を調査したもの、国の基本的な展望を示すものなど、社会的に価値の高いものが数多くあります。また、審議会、研究会などの会議で使用されている資料も最新動向などが整理されている資料や、政策生成過程の資料が公開される等、社会的に非常に価値の高い情報があります。
一方、報告書や会議資料の中にはその存在を見つけることが難しいものもあり、有益な情報があるにもかかわらず活用できていない状況でした。また、報告書を見つけた場合にもタイトルがわかりにくかったり、概要や目次が公開されていなかったりするために、必要な情報にたどり着けないこともあります。
更に、最近のWebサイトはパーマリンクを活用していることが多く、検索で当該資料を見つけても、その資料がどの会議で提示されたのかわからない事例も増えています。
課題
例えば、国会図書館に納本されている報告書等はデータベースで検索可能ですが、概要情報等がないため必要な報告書等にたどり着けないことがあります。また、会議資料は、会議開催情報のWebサイトを見に行くか、検索サイトで検索するのが主な入手手段でした。
- 利用者にとっての課題
・有益な報告書や資料があれば活用したいが、どんなものがあるかわからない
・概要情報がないため、中を見ないと必要な情報かどうかわからない
・報告書がPDFで再利用ができない(特にデータ)
- 行政職員にとっての課題
・担当部局内でも報告書が周知されず活用されていない場合がある
投資対効果
先進技術調査や海外事例調査を各企業でも費用をかけて行っていますが、類似の報告書から必要な情報を得ることで調査コストを削減することや、より高度な調査を行うことが可能になり社会全体のコストを軽減することができます。
目的と概要
目的
報告書や会議資料の書誌情報を一定のデータ形式で公開し、再利用しやすくすることで、報告書の活用を促進し、政策の普及や先進情報の共有を図ることを目指します。また、重複調査の防止を図る等、社会全体でのコスト削減と調査予算の有効活用を目指します。
概要
各省庁の報告書情報は、国会図書館と政府のデータカタログサイトに登録することとなっていますが、二重の作業にならないように配慮する必要があります。
報告書の書誌情報を収集した部署が一括して登録する等の工夫が必要です。担当部門が個別に登録する場合にも本データモデルの書式を使うことで容易に登録できるようになります。
会議資料は、当該会議開催情報のトップページに会議資料一覧として掲載するとともに、本データモデルに沿ったデータを政府のデータカタログサイトに載せることで、多くの人に利用してもらえるようになります。
報告書のデータ構造
報告書のデータの構造は、データを収録しているカタログ情報とデータ本体、それに配布方法の情報により構成されます。データ構造についてはメタデータ導入実践ガイドブックも併せて参照してください。
また、カタログの上位に更にカタログ情報が付く場合があります。
このようにデータを構造化することで、例えば以下のような情報管理ができるようになります。
例)国勢調査
例)会議資料
例)辞典
データモデル
データモデルの全体概要図(クラス図)
報告書の実装データモデルの全体概要図は以下のとおりです。
データモデルの項目定義
報告書のデータモデルは会議体系、資料体系を表すカタログのデータと、カタログに紐付く資料等を表すデータセットに分かれます。
カタログ情報
| 必須項目 | 項目名 | 説明 |
|---|---|---|
| 必 | カタログ名 | 報告書や資料が収納されているカタログの名前(会議の名前) |
| カタログ内容 | カタログの内容 | |
| カタログの主要トピック | カタログ内の主要トピックスを箇条書で記入 | |
| カタログテーマ | カタログにテーマがある場合にテーマをタグとして記録 | |
| 親カタログ名 | 上位のカタログがあるときに記入 | |
| 子カタログ名 | 下位のカタログがあるときに記入 | |
| カタログ発行者 | カタログ全体の発行者 | |
| カタログ更新日 | カタログの更新日 | |
| カタログ言語 | 英字3文字コードで記入。JPNは省略可能 |
データセット
事例
資料
資料集を作成する場合には、カタログ情報として資料集の情報を登録し、データセットで、カタログに含まれる個々のデータの内容を記述します。実際の記入例は以下のとおりです。
カタログ
| 項目名 | 説明 |
|---|---|
| カタログ名 | コンポーネント集 |
| カタログ内容 | 行政で簡単に使えるコンポーネントを掲載 |
| カタログの主要トピック | コンポーネント |
| カタログテーマ | デジタル・トランスフォーメーション |
| 親カタログ名 | デジタル・トランスフォーメーションガイド |
| 子カタログ名 | 主要連絡先リスト |
| カタログ発行者 | ○○室 |
| カタログ更新日 | 2020-08-10 |
| カタログ言語 | JPN |
データセット
| 項目名 | 説明 |
|---|---|
| ID | 0812 d3456 |
| タイトル | 検索コンポーネント |
| サブタイトル | あいまい検索エンジン |
| バージョン | 1.2 |
| 説明 | 検索コンポ―ネントの使用方法をガイドする |
| タイプ | テキスト |
| テーマ | |
| キーワード/タグ | 検索 |
| 対象地域 | |
| 対象期間 | |
| 更新頻度 | その他(バージョンアップ時) |
| フォーマット | DOC |
| 作成者 | ○○室 |
| 関係者 | ○○プランニング |
| 連絡先名称 | ○○係 |
| 説明ページURL | https:// |
| ダウンロードURL | https:// |
| データサービスの可否 | 可 |
| エンドポイントURL | https:// |
| エンドポイント説明 | ユーザーIDが必要 |
| サイズ | 218KB |
| ライセンス | CC0 |
| 権利 | |
| 発行日 | 2020-08-10 |
| 更新日 | 2020-08-10 |
| 状況 | 利用可 |
| 言語 | JPN |
会議資料
会議資料の場合は、カタログ情報に会議情報を登録し、会議内の各資料についてデータセットに記録します。
カタログ
| 項目名 | 項目の説明 |
|---|---|
| カタログ名 | ○○本部第○○分科会第○会 |
| カタログ内容 | ○○についての会議 |
| カタログの主要トピック | ○○ |
| カタログテーマ | デジタル・トランスフォーメーション |
| 親カタログ名 | ○○本部○○分科会 |
| 子カタログ名 | なし |
| カタログ発行者 | ○○室 |
| カタログ更新日 | 2020-08-10 |
| カタログ言語 | JPN |
データセット
| 項目名 | 項目の説明 |
|---|---|
| ID | 0812 M3456 |
| タイトル | ○○先進事例 |
| サブタイトル | 資料2 |
| バージョン | |
| 説明 | 先進事例に関する発表資料 |
| タイプ | テキスト |
| テーマ | |
| キーワード/タグ | ○○ |
| 対象地域 | |
| 対象期間 | |
| 更新頻度 | |
| フォーマット | PPT |
| 作成者 | ○○委員 |
| 関係者 | ○○連合会 |
| 連絡先名称 | ○○係 |
| 説明ページURL | https:// |
| ダウンロードURL | https:// |
| データサービスの可否 | |
| エンドポイントURL | |
| エンドポイント説明 | |
| サイズ | 218KB |
| ライセンス | |
| 権利 | 資料の権利は資料作成者に帰属します |
| 発行日 | 2020-08-10 |
| 更新日 | 2020-08-10 |
| 状況 | |
| 言語 | JPN |
解説
データ標準
報告書・会議資料のデータ構造は、欧州の推進するADMSとW3Cの推進するDCAT2.0、schema.org(CreativeWorks)との互換性を持ちつつ簡易なモデルとしています。詳細についてはメタデータ導入実践ガイドブックを参照してください。
付録
全体概要図として掲載したクラス図について、大きなサイズのものは別添の「451-6-1_報告書データモデル_クラス図.pdf」を参照してください。
変更履歴
デジタル社会推進実践ガイドブック DS-451-7
実装データモデル(行政)
行政サービス拠点・支援機関等
2025年(令和7年)3月25日
デジタル庁
目次
背景と課題
背景
行政機関は、サービスを的確かつ効率的に行うために、サービス提供の対象地域を支所等毎に定めている場合があります。この情報が様々な機関で独自の形態で管理されているため、行政サービスを受けるときや、届出をするときに、どこに行けばよいかわからないことがあります。
行政サービスガイドや支援制度ガイド等を作成するときにも、参照しているサービスの問い合わせ先に、「お近くの○○事務所にお問い合わせください」という案内がされている場合があり、個人や法人向けにカスタマイズした情報を提供する妨げになっていました。
課題
行政サービス範囲は組織毎に異なり、市区町村などの行政境界と違う場合もあるため、行政サービス情報を提供する情報データベースなどを作成しても的確に連絡先を案内することができませんでした。
行政サービス範囲は、地方公共団体の境界だけでなく、法務局のように広範な地域を対象にする場合もありますし、学区のように小地域を対象にしている場合もありますが、いずれにしてもワンストップサービスなどを行うために範囲の明確化が求められています。
-
利用者にとっての課題
-
どこに相談に行けばよいかわからない
-
管轄外のサービス拠点に行くと、出直さなければならない
-
-
行政職員にとっての課題
-
管轄外の利用者が来訪すると、その利用者に適した管轄の拠点を案内しなければならない
-
一覧表で案内しているが、管轄区域外の問い合わせがくる
-
投資対効果
申請者はこれまで、届出等を行うときに担当の窓口を検索する必要があり、別表を見る等、手間がかかっていました。
検索性を向上するためには、検索に適したデータ形式で情報を提供する必要があります。行政サービス範囲は各府省庁が従来から保有している情報となるため、データ標準化の対応に初期コストがかかりますが、その後はコストがかかりません。
利用者は、データが標準化されることで、担当している窓口や行政サービス拠点を迅速に探すことができ、時間とコストの節約になります。
目的と概要
目的
行政サービスの利用者に的確に相談や手続の窓口を案内し、行政サービスや支援を迅速に提供することで、利用者の利便性の向上を図ることを目的にします。
概要
行政サービス拠点の情報は、一般の行政施設情報にサービス・担当区域を追加したものになります。
行政施設情報は、訪問に必要な名称、場所、利用可能時間で構成されます。
サービス・担当区域の記述方法にはいくつかの方法があります。
行政境界
都道府県、市区町村、町丁字を列挙することで行政サービス範囲を記述します。この方法はデータ作成が容易ですが、「霞が関1丁目(一部)」のような範囲設定があるときには正確に範囲を特定することができません。このような部分的な地域を含むときには、その地域名を記入し、備考で「一部」であることを明記します。
ポリゴン
担当区域を地図上の範囲で示す方法です。自由に地域を書くことが可能で詳細に範囲を記述できますが、ポリゴン作成の手間がかかります。
連絡先は、行政施設の代表を記述するのではなく、相談が迅速にできるように担当課の連絡先を記入することが望まれます。
データ
データモデルの全体概要図(クラス図)
行政サービス拠点・支援機関等の実装データモデルの全体概要図は以下のとおりです。
データモデルの項目定義
行政サービス拠点・支援機関等は、コアデータモデルを組み合わせることでシンプルにデータで表現することができます。
事例
武蔵野税務署を例にデータの事例を以下に示します。
施設情報(コアデータモデル施設)
| 項目名 | 説明 |
|---|---|
| ID | 行政施設に一意のID |
| 種別情報 | POIコード等 |
| 名称 | 武蔵野税務署 |
| 名称(カナ) | ムサシノゼイムショ |
| 名称(英字) | Musashino Tax Office |
| 概要 | |
| 説明 | |
| 施設住所 | 東京都武蔵野市吉祥寺本町3-27-1(コアデータモデルの住所型:連結表記) |
| 利用可能曜日 | 月火水木金 |
| 開始時刻 | 08:30 |
| 終了時刻 | 17:00 |
| 利用可能日時説明 | 土曜日、日曜日、祝日及び年末年始(12月29日から1月3日)は執務を行っておりません |
| 料金有無 | 無料 |
| 連絡先情報 | 省略(コアデータモデル連絡先) |
サービス・担当区域情報(コアデータモデル住所)
| 項目名 | 説明 |
|---|---|
| 全国地方公共団体コード | 130001 |
| 都道府県 | 東京都 |
| 市区町村(郡) | 武蔵野市,三鷹市,小金井市 |
連絡先(コアデータモデル連絡先)
| 項目名 | 説明 |
|---|---|
| 連絡先名称 | (本資料では省略) |
| 連絡先電話番号 | 0422-53-1311 |
| 連絡先内線番号 | |
| 連絡先メールアドレス | (本資料では省略) |
| 連絡先URL | (本資料では省略) |
| 連絡先備考(その他、SNSなど) | https://www.nta.go.jp/about/organization/tokyo/location/tokyo/musashino/ |
解説
データ標準
デジタル庁が公開するGIF(Government Interoperability Framework)コアデータモデルの住所、施設、連絡先を参照して作成しています。
行政サービス拠点種別
行政サービス拠点の種別には、観光施設、公共施設など地理的目標物(Point Of Interest)に対する分類コードである行政基本情報データ連携モデルのPOIコードを使用します。POIコードの詳細についてはコアデータモデル施設もあわせて参照してください。以下に、国の機関のPOIコードを示します。
| 1201 | 官公署 | 官公署 |
|---|---|---|
| 1202 | 合同庁舎 | 合同庁舎 |
| 1203 | 検察庁 | 検察庁 |
| 1204 | 裁判所 | 裁判所 |
| 1205 | 法務局 | 法務局 |
| 1206 | 法テラス | 法テラス |
| 1207 | 公証役場 | 公証役場 |
| 1208 | 出入国管理局 | 出入国管理局 |
| 1209 | 税関 | 税関 |
| 1210 | 税務署 | 税務署 |
| 1211 | 警察署 | 警視庁、道府県警察本部及び警察法による警察署 |
| 1212 | 交番 | 警察法による交番その他の派出所及び駐在所 |
| 1213 | 運転免許試験場 | 運転免許試験場 |
| 1214 | 消防署 | 消防組織法による消防署をいう |
| 1215 | 消防署分署 | 支署、出張所及び分遣所 |
| 1216 | 郵便局 | 普通郵便局、特定郵便局及び簡易郵便局。分室及び常設の出張所 |
| 1217 | 森林管理署 | 森林管理署 |
| 1218 | 気象台 | 気象台 |
| 1219 | 職業安定所 | 職業安定所 |
| 1220 | 労働基準監督署 | 労働基準監督署 |
| 1221 | 社会保険事務所 | 社会保険事務所 |
| 1222 | 矯正施設 | 刑務所、少年院 等 |
| 1223 | 自衛隊・米軍 | 自衛隊・米軍 |
| 1224 | 外国公館 | 外国が日本に設置している大使館、公使館及び領事館 |
| 1299 | その他国の機関 |
中小企業向けの支援機関にはPOIコードが設定されていないため、以下の分類を使用してください。
| C0001 | 金融機関 | |
|---|---|---|
| C0002 | 中小企業支援センター |
以下に、地方行政に関するPOIコードを示します。
| 1301 | 県庁 | 県庁 |
|---|---|---|
| 1302 | 市役所・東京都の区役所 | 市役所及び東京都の区役所 |
| 1303 | 町村役場・政令指定都市の区役所 | 町村役場及び政令指定都市の区役所 |
| 1304 | 役場支所及び出張所 | 市・特別区・町・村・指定都市の区の役場支所及び出張所 |
| 1305 | 市民活動施設 | 市民活動施設 |
| 1306 | 産業支援施設 | 産業支援施設 |
| 1307 | 公民館 | 公民館 |
| 1308 | 公会堂 | 公会堂 |
| 1309 | 集会施設 | 集会施設 |
| 1399 | その他行政サービス施設 |
以下に、対象者に地域性のある代表的な機関に関するPOIコードを示します。
| 1402 | 保育園 | 保育園、保育所、託児所。日日保護者の委託を受けて,乳児又は幼児を保育する福祉事業を行う施設 |
|---|---|---|
| 1403 | 児童館(児童センター) | 児童館(児童センター) |
| 1404 | 学童保育クラブ | 学童保育クラブ |
| 1405 | 認定こども園 | 認定こども園 |
| 1406 | 児童相談所 | 児童相談所 |
| 1407 | 福祉事務所 | 都道府県、市町村及び特別区が設置する福祉に関する事務所 |
| 1408 | 老人ホーム | 特別養護老人ホーム、介護老人福祉施設、有料老人ホーム 等 |
| 1409 | 老人通所・短期入所介護施設 | 老人デイサービスセンター、老人短期入所施設、小規模多機能型居宅介護事業所 等。要介護者等を通所又は短期入所させ、介護等の日常生活上の世話や機能訓練を行う事業所 |
| 1499 | その他の社会福祉施設 | |
| 1501 | 幼稚園 | 幼稚園 |
| 1502 | 学校 | 学校の総称 |
| 1503 | 小学校 | 小学校 |
| 1504 | 中学校 | 中学校 |
| 1505 | 高等学校・中等教育学校 | 高等学校・中等教育学校 |
| 1514 | 職業・教育支援施設 | 大学校、研修センター 等。官公庁、企業若しくは事業所が業務遂行のため所属職員等を対象として教育・研修を行う事業所又は官公庁、企業若しくは事業所からの委託を受けて業務遂行のため所属職員等の教育・研修を行う施設 |
| 1606 | 保健所 | 地域保健法による保健所。支所、出張所等は含まない |
| 2004 | 廃棄物処理施設 | 廃棄物処理施設 |
| 2005 | 資源回収所 | 資源回収所 |
| 2006 | ごみ焼却場 | ごみ焼却場 |
| 2009 | 火葬場 | 火葬場 |
| 2010 | 墓地 | 墓地 |
| 2201 | 避難施設 | 避難施設 |
| 2202 | 避難場所 | 避難場所 |
| 2203 | 津波避難施設 | 津波避難施設 |
| 2205 | 給水所 | 給水所 |
上記以外のPOIコードは、別添の「491-3-1_POIコード表.xlsx」、および解説書として「491-3_コード_POIコード.docx」を参照してください。
付録
全体概要図として掲載したクラス図について、大きなサイズのものは別添の「451-7-1_行政サービス拠点・支援機関等データモデル_クラス図.pdf」を参照してください。
また、本文書に掲載していないPOIコードの全体については、別添の「491-3-1_POIコード表.xlsx」を参照してください。
変更履歴
デジタル社会推進実践ガイドブック DS-451-8
実装データモデル(行政) 調達
2025年(令和7年)3月25日
デジタル庁
目次
背景と課題
背景
行政機関は国内最大の調達機関であり、その調達情報は国内外から広く公開が求められています。そのため、政府の調達情報は官報に公示され、地方自治体の調達情報は公報に公示されます。
調達情報電子化は長年取り組まれており、1994年に調達に関する官報に掲載される主要事項の様式が政府調達関連省庁の事務連絡で決められるとともに、1997年に行政情報化推進基本計画で調達の電子化の推進が決められました。さらに、1998年10月に「高度情報通信社会推進に向けた基本方針」で公共工事の調達システムの推進が決められ、同年12月に内閣総理大臣直轄タスクフォースであるバーチャルエージェンシーを設置して物品・役務の政府調達手続きの電子化を集中的に検討しました。
2002年には電子入札コアシステム 開発コンソーシアムによる電子入札コアシステムが開発され、日本主導でUN/CEFACTに調達データの標準化を提案してきました。また、国の工事に関しては入札情報サービス(i-ppi)や電子調達システム(政府電子調達(GEPS))が提供され、独立行政法人や地方公共団体の調達情報を集める仕組みとして、2009年に官公需情報ポータルサイトが開設されています。
しかし、国の情報は工事と物品・役務に分かれ、地方公共団体とも統一されていないなど収集、集約することが困難でした。また、調達システムとは別に官報への入稿を別途行う必要があるなど行政内の手続きも見直されてきませんでした。
課題
各機関や複数の集約サイトで調達情報を公開しているため、事業者からは、調達情報を一元的に公開してほしいとの要望が多く寄せられています。
-
国の調達実施者にとっての課題
-
多くの調達参加者に参加してもらいたい
-
調達事務を簡単にしたい
-
-
自治体の調達実施者にとっての課題
- 多くの調達参加者に参加してもらいたい
-
調達システム担当者にとっての課題
- 現行システムの維持でていっぱい
-
官報担当者にとっての課題
- デジタル時代に合った見直しが必要
-
調達情報の利用者にとっての課題
-
調達情報が様々なところにあり探しにくい
-
ビジネスチャンスがつかめない
-
民間の集約サービスが有料である
-
-
海外の調達情報の利用者にとっての課題
- 調達情報が見つからない
投資対効果
調達データを統一することで、国内の調達案件を一元的に探すことができ、ビジネスチャンスが広がります。調達実施者は業務の効率化ができます。様々な調達システムでの重複投資が削減されます。
目的と概要
目的
国内最大の調達機関である行政機関の調達情報を利用しやすくすることは、多様な参加者が調達に参加しやすくなり競争が促進されるとともに、優良な企業が調達を通じて成長できる機会を提供することができます。
本データモデルを使うことで調達情報を正しく素早く検索できるようにすることを目的としています。
概要
調達データにはいくつかのデータモデルがあります。また、物品・役務と工事ではデータの一部に差異があることがあります。また、公告は日本語だけでなく英語での公告が求められる場合もあります。
入札公告
行政機関が調達を行うときに入札の公告をします。
調達予定の公告
今後の調達予定に関して公告をします。
落札公告
調達の落札者に関して、法人名や落札金額などを公告します。
訂正公告
公告内容に変更があった場合に公告します。
関連参加資格等の公告
関連資格を取得した法人などに関して公告します。
調達データの構造
調達データは、調達公告に関する公告管理情報と調達内容、公告目的別情報により構成されます。
図 1 調達データの構造
データ
公告管理情報
全ての公告に共通で使用される管理情報です。この項目の後ろに調達内容、公告目的別情報が付加されます。
入札公告
入札の公告の場合、公告管理情報に付加する調達情報です。
調達予定の公告
調達予定の公告の場合、公告管理情報に付加する調達情報です。
落札公告
落札の公告の場合、公告管理情報に付加する調達情報です。
訂正公告
訂正の公告の場合、公告管理情報に付加する調達情報です。
関連参加資格等の公告
関連参加資格等の公告の場合、公告管理情報に付加する調達情報です。
事例
行政機関の調達情報は既に様々な形式、流通経路で提供が行われています。それぞれのデータ項目は別表「451-9-2_別表各種調達標準の比較.xlsx」に示します。
官報 (国立印刷局)
官報で政府の調達情報の提供を行っています。
https://kanpou.npb.go.jp/index.html
調達ポータル (総務省)
政府の物品調達や役務の提供などの調達情報を一元的に提供しています。APIによる情報提供も行っています。
https://www.p-portal.go.jp/pps-web-biz/UZA01/OZA0101
官公需情報ポータルサイト (中小企業庁)
政府と自治体の調達情報を各組織のWebサイトなどから収集し、一元的に提供しています。APIによる情報提供も行っています。
入札情報サービス(統合PPI) (JACIC)
自治体にパッケージでサービスを提供することにより、自治体による調達情報の提供を支援しています。
https://www.i-ppi.jp/Search/Web/Index.htm
解説
データ標準(参考とした情報)
別表「451-9-2_別表各種調達標準の比較.xlsx」の右表が参考にした手続等の情報、左表が参考情報を元に新たに定義した様式・語彙であり、参考元との対応を示しています。
・平成7年「「政府調達に関する協定」等に基づく入札公告等の官報掲載方法
・官報 (国立印刷局)
・調達総合情報システム (総務省)
・官公需サイト (中小企業庁)
・入札情報サービス(統合PPI) (JACIC)
・CEN BII(EESPA)
・UN/CEFACT BRS (UNECE)
・政府公共調達データベース (JETRO)
・GSA (米国)
・TED (EU)
コード
品目コード
全省庁統一資格の営業品目のコードと政府調達の品目分類のコードがある。法人関係情報を一元的に提供している gBizInfoでは以下のように日本標準産業分類とマッピングして使用している。
産業分類参考情報 情報源
総務省 日本標準産業分類 2017年1月19日
http://www.soumu.go.jp/toukei_toukatsu/index/seido/sangyo/
総務省 全省庁統一資格 営業品目 2017年1月19日
https://www.chotatujoho.go.jp/va/com/eigyo_hinmoku.html
内閣府 政府調達 品目分類 2017年1月19日
http://www.kantei.go.jp/jp/kanbou/20tyoutatu/dai4/dai4siryo1.pdf
調達機関コード
国や独立行政法人の調達機関コードが毎年、官邸から提供されている。
https://www.kantei.go.jp/jp/kanbou/r01tyoutatu/dai4/dai4shiryou3.pdf
変更履歴
| 改定年月日 | 改定箇所 | 改定内容 |
|---|---|---|
| 2025年3月25日 | 変更履歴 | 掲載位置を末尾に変更 |
| 2022年3月31日 | - | 行政サービス・データ連携モデル「調達」の書式を変更し、解説を加えた。 |