451 実装データモデル_行政

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

実装データモデル（行政）

申請・届出

2026年（令和8年）10月06日

デジタル庁

目次

背景と課題

背景

デジタル手続法が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票の申請内容を、届出や報告の内容にします。定期報告では、表などのデータのみになる場合もあります。

個人用データモデル

データモデルの全体概要図（クラス図）

申請（個人）の実装データモデルの全体概要図は以下のとおりです。

概要

個人から行政機関等に提出される申請データモデルです。本申請のデータモデルは、以下の2書式で構成されます。

※委任情報データが付く場合があります

A票：個人申請基本情報

B票：個人申請内容

法人用データモデル

データモデルの全体概要図（クラス図）

概要

法人から、行政機関等に提出される申請データモデルです。本申請データモデルは、以下の6書式で構成されます。

※委任情報データが付く場合があります

A票：法人申請基本情報

B票：法人申請内容

C票：財務情報（今後、決算公告データ標準化に合わせて変更予定）

D票：法人役員一覧

E票：主要株主

F票：事業所一覧

士業法人用データモデル

データモデルの全体概要図（クラス図）

概要

士業法人は、資格保有者の一覧が必要になるなど、一般的な法人とデータ項目が異なります。法人用データの役員一覧である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票は、これまでの申請で税務申告書のコピーを添付する場合が多かったことから、税務申告データをベースに項目を選定し、経営分析が可能なように、中小企業庁ローカルベンチマークのデータ項目を付加しています。税務申告データを活用することにより、納税証明書データとの突合で、財務情報の真正性を確認することが可能になります。

付録

変更履歴

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

実装データモデル（行政）

証明・通知

2026年（令和8年）10月06日

デジタル庁

目次

背景と課題

背景

資格や納税等に関する証明情報は各種申請の際に添付書類として求められることが多くあります。その証明内容は多岐にわたり、資格証明、納税額等だけではなく、契約の請書、表彰、通知等も一種の証明情報といえます。

証明情報はその申請から廃棄まで、発行者、申請者と受理者が関与するライフサイクルを形成します。これまで、証明情報は主に紙によって発行されてきましたが、「デジタルファースト」、「ワンスオンリー」、「ワンストップ」サービスの実現の観点から、デジタル情報の活用を前提に、ライフサイクル全体を考慮した業務を検討していく必要があります。

証明情報を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グローバルによるオープン・バッジがあります。

付録

変更履歴

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

実装データモデル（行政） 事例

2026年（令和8年）10月06日

デジタル庁

目次

背景と課題

背景

行政機関では取り組んだ事業の内容等を事例集として公開しています。事例集には成功や失敗等の経験が記録されており、個人や法人がサービスや各種活動を行う上で参考になります。しかし、行政機関の各部局で制度毎に独自に作成されていることが多く、それを組織全体の知識として活用することができていませんでした。

また、類似の事例集を地方公共団体などが作成していた場合にも、書式が異なることもあり、一緒に活用することが難しい状況でした。そのため、複数の事例集のデータを組合せて使用したり、AI等で分析したりすることが難しく、十分に管理・活用されていない状況にありました。

課題

これまで事例集の書式は統一されておらず、複数の事例集を集めても比較や検索などが行いにくいという課題がありました。また、記述欄を項目立てず自由記述とした場合には、取り組みのポイントなど分析に必要な事例内容が明確に記載されないことがあり、ノウハウとしての価値が十分に発揮できていない場合がありました。

• 事例作成者にとっての課題

  • 取り組み内容の記述欄に何を書いてよいのかわからない

• 事例集編集者にとっての課題

  • 各事例の記述レベルが異なる

  • 重要なポイントが書かれていないことがある

• 事例集の利用者にとっての課題

  • 目的に合わせて事例を検索しにくい

  • 事例によって記述が異なり、知りたいポイントがわかりにくい

  • 知りたいポイントが書かれていない

投資対効果

事例集を作成するには企画、作成、編集、印刷・配布等のコストがかかります。単に事例集を作るだけではなく、検索性を高め、見てもらい、使いこなしてもらうことで、事例集の価値をより高めることができます。

既存の事例集フォーマットを本事例データモデルに合わせることで、従来とほぼ同じ投資で、より多くの政策効果をあげることができるようになります。

目的と概要

目的

行政機関をはじめ多くの組織でノウハウ継承や活動促進のために事例集を作成しています。本データモデルに沿って記述内容を整えることで、事例作成者の作成作業における時間と手間を大幅に削減するとともに、必要な情報を抜け漏れなく入力できるようになります。

また、本データモデルを使うことで必要な事例を正しく素早く検索できるようになります。これらを通じて、事例の活用を広げ、効率化の促進や社会全体の活性化を図ることを目的としています。

概要

具体的には、事例集に含まれる定型的な部分を共通書式化するとともに、事例の内容を細分化して、項目毎に事例を記述できるようにしています。以下に従来書式との変更点の概要を記載します。

上記では、内容の記述欄が細分化されたため記述項目が増えて入力の手間が増えたように見えますが、実際には各データ項目の内容毎に対話形式で記述していくことができるため、入力は容易になり、読み手にもわかりやすくなるといった利点があります。

また、収集しようとしている事例がこの書式にあるデータ項目に該当しない場合には、データ項目を追加して事例データモデルを拡張することもできます。

逆に、データ項目が事例にそぐわない場合には、項目自体を省略したり空欄にしたりすることができます。事例集や事例データベースで空欄の事項は、UI上ではデータ項目の表示を項目も含めて非表示にすることですっきりと表示させることができます。

事例の紹介を記事化したり、中見出しをつけたりする事例集もあります。そのような読み物形式の事例集は、このような定型的なデータ定義では表現が難しいです。

例えば、データベースに基本事項を入れた上で、注目事例だけ別途記事型の詳細経緯等も含んだ事例を作る等、組合せて使用することで、検索も可能、かつ、目的に合った伝え方ができるようになります。

データモデル

データモデルの全体概要図（クラス図）

事例集の実装データモデルの全体概要図は以下のとおりです。

事例集データモデル（カタログ情報）

事例を集めて事例集や事例データベースにする時の、事例集や事例データベースに対する解説（カタログ）情報のデータモデルは以下のとおりです。

表1 事例集をカタログ情報として表した場合のデータ項目

事例データモデル

個々の事例を記述するデータモデルです。個人の事例の場合には、対象組織を「居住地」「年代」等、事例集に適した項目に変更します。また連絡先情報も個人の場合は不要です。

活用場面イメージ

事例集を作成する場合の流れは以下のようになっています。事例データモデルを使うことで、事例作成者は質問に答える形式で事例を書いていくことができます。

機能イメージ

事例記述

事例作成者は、事例を記述する場合に、自由に作文をしていくのではなく、背景、目的、挑戦したこと、その結果と、ヒアリングを受けているように順次記述していくことができます。

事例確認・修正

事例作成者は、事例の各項目を確認することで、事例利用者に示唆があるかどうかの確認をすることが容易になります。また、事例集編集者は、修正のポイントを示しやすくなります。

事例集の編集

事例のデータ項目の形式が決まっているため、事例集編集者は、書式やスタイルを決めるだけで簡単に事例集を作成することができます。

サービス例

中小企業向け支援制度の提供を行う「ミラサポplus　事例ナビ」では、本データモデルのサブセット化をしてサービスを提供しています。本モデルのすべてのデータモデルを適用しようとしても、既存の事例情報の元データは十分にデータ細分化ができていないことから、まずは、現在のデータ粒度を基に、データ項目を最小化してサービスを実現しています。

解説

データ標準

このデータモデルは、政府が整備するデータ標準である共通語彙基盤、インターネット上のデータカタログの標準であるDCATやインターネット上のデータ項目標準であるschema.orgのCreativeWorkを参考に整備しています。

また、内容の詳細項目の設定は、国連公共サービス省のデータモデル、OECDのOPSI（Observatory of Public Sector Innovation）のデータモデルを参考に設定しており、事例を翻訳することで国際的にも活用が可能です。

※ OPSIの項目にある「Innovation status」は、日本の事例集は基本的に導入「Implementation」フェーズなので省略。

※ ＋で表した項目は、本ガイドの複数項目を合わせることでOPSIに対応

法人種別

組織の種別項目に記述する法人の種別は、法人番号を付番する国税庁が法人番号公表サイトで使用する以下の種別を使います。

• 国の機関

• 地方公共団体

• 株式会社

• 有限会社

• 合名会社

• 合資会社

• 合同会社

• その他の設立登記法人

• 外国会社等

• その他

付録

変更履歴

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

実装データモデル（行政）

行政サービス・制度

2026年（令和8年）10月06日

デジタル庁

目次

背景と課題

背景

国、都道府県、市区町村は、多くの行政サービス、支援制度、補助金（以降、行政サービスと表記）を個人や法人に対して提供しており、その数は数千種類ともいわれています。これらの説明は紙で行われることが多く、国、都道府県、市区町村がそれぞれガイドブックやリーフレットなどを発行しています。これらのガイドブックは記述項目や分類が異なり、行政サービス間の比較検討が難しくなっています。

国際的には、行政サービスの分類方法（サービスカタログ）や記述方式（行政サービス情報）の統一が進められており、広域での情報提供を行いやすい環境を整備しています。

課題

どのような行政サービスや支援制度があるのか知りたい、自分が活用できる行政サービスや支援制度は何か知りたいという意見は、行政サービスに関する調査を行うと常に上位にあげられています。利用者のために作った制度にもかかわらず、そのサービスや支援制度の存在が知られておらず、その行政サービスの利用率が低いと指摘されることもあります。

特に、大規模災害後には緊急で支援制度などが数多く提供されますが、これらの情報は、各組織で紙冊子が作られ、検索性が低い状況で配布がされています。

また、地方公共団体等、様々な機関が支援制度情報の冊子などを作っており、利用者がわかりやすいように行政サービスのタイトルや説明を書き直したり、自治体独自の加算金を加えた派生形の行政サービスを作ったりすることがあります。このように情報内容に様々なバリエーションがあることにより、行政サービスの全体像がわかりにくくなっている場合もあります。

利用者にとっての課題

・行政サービスや支援制度を知らない、見つけられない

・各支援制度情報の記述内容が不統一で分かりにくい

・類似の支援制度が複数組織から公表されていてわかりにくい

・同じ支援制度が複数個所から違う表現で情報提供され、複数の支援制度に見える

・支援制度を知った時には申込みが終わっていることがある

行政職員にとっての課題

・情報が利用者に届かないため、利用（政策の普及）が進まない

・支援制度広報に予算が必要だが、十分にない

・周辺自治体などの支援制度情報を調べたくても調べられない

・国の支援制度を探すのが大変

・災害時に大量の追加の支援制度が出るが、手作業で対応している

投資対効果

行政サービスに関する情報の提供は情報利用者の視点ではなく情報提供者の視点で行われることが多いため、行政サービスの利用者は、活用できるサービスを探すために多くの時間をかけたり、支援制度活用の機会を逃していたりすることさえあります。これまで、サービスや制度を探す際には、市区町村、都道府県、国、支援機関の情報を収集し、利用できそうなサービスや支援制度を比較検討し、更に、支援機関に相談することもあります。これら様々な支援機関から提供される支援制度を一元的に検索できるようにすることで、全ての利用者の時間節約になるとともに、早期の行政支援の活用によりその効果を享受することが可能になります。

行政サービスや支援制度の提供部門にとってもメリットがあります。定型データモデルに制度情報を記入する事務コストは従来の業務とほとんど変わりませんが、定型のデータモデルに支援制度を記入することにより、政策の広報が効率的にできるだけでなく、内容が分かりやすくなるため問い合わせが減るという効果もあります。

利用者が相談に訪れる相談機関や支援機関は、利用者に合わせた制度が探しやすくなり、的確な支援をアドバイスしやすくなります。支援対象者の業種に特化したガイドブックの作成等をすることもできるようになります。

特に災害時には、日々追加される支援制度を効果的に情報提供・収集できる必要があることから、このように定型データモデルによる情報提供は非常に大きな価値を生み出すと考えられます。

目的と概要

目的

行政サービス情報を正確かつ効率的に利用者に届け、活用の促進を図ることを目的とします。

利用者の業務を効率化するだけではなく、提供する行政機関の問い合わせ対応業務の削減等も実現します。

概要

行政サービスを紙の冊子でもインターネット経由でも活用しやすいデータとして整備します。そのために、タイトルや連絡先等のデータ項目の統一化と記述方式の統一を行います。

行政サービスは、社会変化に合わせて日々追加されますが、行政サービス情報に付加されたタグ等により、利用者の要望に応じて追加配信をすることも可能になります。

デジタルデータでの整備

行政サービスの検索性を高めるためには、データ化が欠かせません。検索性を高めるために、従来の記述内容のうち、特定の情報については別項目でデータを登録する場合もあります。

データ表記の簡素化

単にデータ項目を統一するだけではなく、利用者にわかりやすくするためにデータ表記の簡素化を行います。日付の表記項目を統一するのをはじめとして、補助率は、1/3補助や5/12補助などのわかりにくい分数表現ではなく、小数点以下1桁表示にするなどの工夫が必要です。制度によっては、条件により補助率を複数持つ場合がありますが、最大補助率とそれを補足する自由記述を組み合わせることで、検索性を高めつつ詳細情報も伝える工夫をする必要があります。

データ基準の簡素化

データの記述項目に曖昧性がある項目を明確化します。これまで、補助金などの説明が、補助の対象購入額なのか、補助金として最大支給額なのかが行政サービス毎に異なる記述をされていました。また、金額や人数の記載では、「以下」と「未満」が混在しています。いき値の扱いに関する情報を内容説明の中で明確にする必要があります。

行政サービスIDによる管理

制度間の関連性を明確にするために制度IDを付与します。元の制度の内容を変えずにわかりやすい文書に書き下す場合や加算などを行う場合には、親の制度IDを記述することで、その関連性がわかるように管理します。

行政サービスIDは、制度所管組織が付与する必要があります。制度所管組織は、制度名の変更や制度内容の軽微な変更をした時にも、同じ制度IDを使う必要がありますが、制度の大幅な変更がある時には新しい制度IDを付与することも検討する必要があります。

地方公共団体は、国の制度の派生の制度を作る時には、IDの連携によりその関係性を明確にすることで住民にわかりやすく情報提供することができるようになります。また、地方公共団体が独自に制度を制定する時には、地方公共団体コードと組み合わせた制度IDを独自に発行することとなります。

データモデル

データモデルの全体概要図（クラス図）

行政サービス・制度の全体概要図は以下のとおりです。

データモデルの項目定義

事例

ミラサポplus　制度ナビ

中小企業向け支援制度の提供を行う「ミラサポplus　制度ナビ」では、本データモデルのサブセット化と中小企業向けの拡張を行ってサービスを提供しています。本モデルのすべてのデータモデルを適用しようとしても、現在の支援制度情報の元データが十分にデータの細分化ができていないことから、まずは、現在のデータ粒度を基に、データ項目を最小化してサービスを実現しています。また、独自項目をいくつか付与しています。

表2 ミラサポplus 制度ナビで追加された独自項目

個人の制度情報の場合は、「事業ステージ」「お困りごと」「サービス種別」の部分が個人向けのステージ情報等になります。

解説

データ標準項目について

欧州の行政サービス情報のデータ標準であるCPSVと東日本大震災後に復旧・復興支援制度データベースとして運用してきたデータ項目、中小企業施策利用ガイドブックの情報内容を基に作成しています。

サービスカタログモデルに基づくタグ

情報の検索性を向上させるためサービスカタログモデルに基づくタグを付与しています。詳細については「491-1_コード_サービスカタログ.docx」を参照してください。

付録

変更履歴

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

実装データモデル（行政） イベント

2026年（令和8年）10月06日

デジタル庁

目次

背景と課題

背景

行政機関は政策を推進するため様々なイベントを主催したり、関連する民間イベントを後援したりしています。しかしその広報範囲は限定されており、十分に政策効果を上げているとは言えません。

イベントの種類にも様々なものがあり、主催・後援イベント以外にも、工場見学のような常設イベントを一覧で提供している場合もあります。

また、審議会の案内、施設公開等もイベントであり、災害時の活動も一種のイベント情報として効率的な配信をすることが可能です。

課題

主催イベントや後援イベント等、それぞれの行政機関が個別に情報を発信しているため、情報の公開場所が統一されておらず、イベント対象者に対して的確に情報が届いていません。

• 利用者にとっての課題

  • イベント情報を知らなかった

  • イベント情報の提供方法がバラバラで収集するのが難しい

  • メール等で自らに関係のないイベント情報が案内される

  • イベント事後に記事などを見るが、事前に情報を提供してほしい

• 行政職員にとっての課題

  • 広報しているのに十分集客できていない

  • 後援情報は、ポスター等に記載するだけで効果が十分ではない

投資対効果

行政機関主催のイベントに関する広報は、Webサイトに載せているだけの場合が多く、イベント情報のデータを様々な媒体で活用できるようにして、体系的に広報することにより、手間と費用を抑えつつ、より大きな広報効果を上げることが可能になります。また、後援イベントを統一したサイト等から情報を提供することで、効果的に周知し政策効果を上げることができます。

目的と概要

目的

個人や法人に関連したイベント情報を必要な利用者が容易に発見・入手できるように、イベントデータを構造化してタグをつける等の標準化を行います。イベント情報を標準化することで、情報流通をしやすくしてイベントの活用を促進します。

イベント情報の発信方法を改善することにより、政策を必要な人に的確に伝えることを目的とします。

概要

イベント情報では、いつ、どこで、誰が、どのようなテーマでイベントを行うかということが重要な情報項目になります。イベントには広域で行うイベントがあったり、情報化月間などという上位のイベントがあったり、イベント内で行うサブイベントがあったりと様々な条件があり、標準的なデータを作るのが難しいと言われてきました。

一般的なイベントは以下のように表すことができます。また、定期開催イベントと単独開催のイベントでも記述方法が変わってきます。

このようなイベントのデータモデルを使うことで、イベント主催者は、様々な関係者へのデータ公開を効率化することができます。また、詳細な必要情報を公開することができるため、問い合わせを減らすことができます。

海外の政府機関では、府省主催のイベント以外に、府省が後援をしている民間イベントも府省のWebサイトのトップページで案内しているところもあります。

また、多くのイベントを公表する場合には、画面で見やすいように一覧化することが重要になります。主要データを抜粋して簡易的に一覧表示させ、別途整理した詳細情報に誘導する等の工夫をしていきます。

データモデル

データモデルの全体概要図（クラス図）

イベントの実装データモデルの全体概要図は以下のとおりです。

データモデルの項目定義

項目定義はコアデータモデルのイベントと同一となっています。内容の詳細は、「43C_コアデータモデル解説書_イベント.docx」を、また項目の記入例や形式などの詳細は「438_コアデータモデル_DMD.xlsx」をあわせて参照してください。

活用場面イメージ

イベント情報収集時のイメージ

各行政機関では、イベントを自ら主催する場合と、第三者が行うイベントを後援する場合があります。

主催イベント

主催イベントは、本データモデルのイベント情報に従い記入します。府省でのイベント案内ページ等に掲載、若しくは、APIで公開することで、広範囲へのイベント情報の公開が期待されます。

後援名義イベント

後援名義の依頼者に、申請データの一部として提出をしてもらいます。府省でのイベント案内ページ等に掲載、若しくは、APIで公開することで、広範囲へのイベント情報の公開が期待されます。

各種会議への適用イメージ

審議会などの会議開催は、現在、各府省のWebページに掲載されていますが、イベント情報提供モデルを使って提供することで、会議内容を広く広報することが可能になります。以下の表は会議をイベントの一種と捉え、イベントのデータモデルをベースにカスタマイズした会議のデータモデルの例です。

表1 イベントをベースにした会議のデータモデルの例

災害時支援活動への活用イメージ

災害時の各種支援活動は、データ構造がイベントのデータ構造と同じです。イベント情報と同じ構造で情報発信することで、災害時に効率的で正確な情報発信が可能になり、その情報を広域で集約するなどの活用が可能になります。また、平時用のイベント情報配信の仕組みを使って被災者に情報を配信することができます。

表2 イベントをベースにした災害時支援活動のデータモデル

体験イベントでのカスタマイズ例

体験イベントは、学校の課外活動、体験型旅行等の大きなニーズがあります。イベントのデータモデルに加えて以下の情報をカスタマイズ項目として付加することで、情報発信を充実させることができます。

表3 体験イベントで付与するカスタマイズ項目の例

付録

変更履歴

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

実装データモデル（行政） 報告書・会議資料等

2026年（令和8年）10月06日

デジタル庁

目次

背景と課題

背景

行政機関では審議会や調査研究など多くの報告書が作成されています。これらの報告書は世界の最先端を調査したもの、国の基本的な展望を示すものなど、社会的に価値の高いものが数多くあります。また、審議会、研究会などの会議で使用されている資料も最新動向などが整理されている資料や、政策生成過程の資料が公開される等、社会的に非常に価値の高い情報があります。

一方、報告書や会議資料の中にはその存在を見つけることが難しいものもあり、有益な情報があるにもかかわらず活用できていない状況でした。また、報告書を見つけた場合にもタイトルがわかりにくかったり、概要や目次が公開されていなかったりするために、必要な情報にたどり着けないこともあります。

更に、最近のWebサイトはパーマリンクを活用していることが多く、検索で当該資料を見つけても、その資料がどの会議で提示されたものかわからない事例も増えています。

課題

例えば、国会図書館に納本されている報告書等はデータベースで検索可能ですが、概要情報等がないため必要な報告書等にたどり着けないことがあります。また、会議資料は、会議開催情報のWebサイトを見に行くか、検索サイトで検索するのが主な入手手段でした。

• 利用者にとっての課題

・有益な報告書や資料があれば活用したいが、どんなものがあるかわからない

・概要情報がないため、中を見ないと必要な情報かどうかわからない

・報告書がPDFで再利用ができない（特にデータ）

• 行政職員にとっての課題

・担当部局内でも報告書が周知されず活用されていない場合がある

投資対効果

先進技術調査や海外事例調査を各企業でも費用をかけて行っていますが、類似の報告書から必要な情報を得ることで調査コストを削減することや、より高度な調査を行うことが可能になり社会全体のコストを軽減することができます。

目的と概要

目的

報告書や会議資料の書誌情報を一定のデータ形式で公開し、再利用しやすくすることで、報告書の活用を促進し、政策の普及や先進情報の共有を図ることを目指します。また、重複調査の防止を図る等、社会全体でのコスト削減と調査予算の有効活用を目指します。

概要

各省庁の報告書情報は、国会図書館と政府のデータカタログサイトに登録することとなっていますが、二重の作業にならないように配慮する必要があります。

報告書の書誌情報を収集した部署が一括して登録する等の工夫が必要です。担当部門が個別に登録する場合にも本データモデルの書式を使うことで容易に登録できるようになります。

会議資料は、当該会議開催情報のトップページに会議資料一覧として掲載するとともに、本データモデルに沿ったデータを政府のデータカタログサイトに載せることで、多くの人に利用してもらえるようになります。

報告書のデータ構造

報告書のデータの構造は、データを収録しているカタログ情報とデータ本体、それに配布方法の情報により構成されます。データ構造については、メタデータ導入実践ガイドブックも併せて参照してください。

また、カタログの上位に更にカタログ情報が付く場合があります。

このようにデータを構造化することで、例えば以下のような情報管理ができるようになります。

例）国勢調査

例）会議資料

例）辞典

データモデル

データモデルの全体概要図（クラス図）

報告書の実装データモデルの全体概要図は以下のとおりです。

データモデルの項目定義

報告書のデータモデルは会議体系、資料体系を表すカタログのデータと、カタログに紐付く資料等を表すデータセットに分かれます。

カタログ情報

データセット