---
title: "公共サービスメッシュとは？二つの枠組みと自治体・ベンダーのシステム要件"
url: "https://www.issoh.co.jp/column/details/18822/"
published: 2026-10-23
updated: 2026-10-23
categories: ["DX"]
publisher: "株式会社一創"
---

# 公共サービスメッシュとは？二つの枠組みと自治体・ベンダーのシステム要件

公共サービスメッシュは、デジタル庁が整備を進める行政データの連携基盤です。中身は「自治体内の情報利用」と「行政機関間の情報連携」という二つの枠組みに分かれ、後者は2026年1月から府省庁等に向けた共通サービスの提供が計画されています。この記事では、デジタル庁の概要資料と工程表をもとに、二つの枠組みの仕組み、整備時期、標準準拠システムを持つ自治体とベンダーが備えるデータ要件、そして今のうちに進めるべき作業と待つべき作業の線引きを整理しました。

## まとめ：公共サービスメッシュで自治体と事業者が先に押さえる時期と要件

公共サービスメッシュは一つのシステムではなく、性格の違う二つの基盤の総称です。自治体内の情報利用は、標準準拠システムの住民データを庁内の別システムやマイナポータル、民間SaaSへ渡すための基盤。行政機関間の情報連携は、マイナンバー制度に基づく機関同士のやり取りで、現行の中間サーバ等を共通サービスに置き換える基盤です。

時期はどちらも「計画」の段階にあります。機関間は2026年1月に共通サービスの提供開始、自治体内は2025年度以降に希望する自治体へ機能を提供し、2026年度以降に機能拡充という工程が示されています。全国一律の切替期限は公表資料に見当たりません。

自治体とベンダーが今やるべきことは一つに絞れます。標準準拠システムのデータが「同じ項目名で、同じ意味を持っているか」の確認です。項目名がそろっていても、履歴の持ち方は事業者ごとに違うことがデジタル庁の資料で示されています。基盤の完成を待たずに手を付けられるのは、この意味の整理です。

## 公共サービスメッシュとは何かをデジタル庁の定義と二つの枠組みで整理

用語の出どころはデジタル庁の政策ページと、それに付いた2本の概要資料です。まず定義と枠組みの分担から押さえます。

### 行政が持つデータの連携基盤という定義と住民・職員の双方に向けた狙い

デジタル庁の[公共サービスメッシュの政策ページ](https://www.digital.go.jp/policies/public%5Fservice%5Fmesh)（最終更新2024年7月11日）は、これを行政が持つデータの利用と連携を迅速にするための情報連携基盤と説明しています。狙いは二方向にあり、住民側ではオンライン申請やプッシュ型のお知らせといった体験の向上、職員側では業務の効率化と負担軽減が挙げられました。

「メッシュ」という語が示すとおり、特定の業務システム同士を1対1でつなぐのではなく、複数のシステムが共通の経路を通じてデータをやり取りする構造を目指しています。発注側から見ると、システムごとに個別のインターフェースを作り込む従来の連携から、共通基盤の仕様に合わせる連携へ移ることを意味します。

### 自治体内の情報利用と行政機関間の情報連携という二つの枠組みの分担

二つの枠組みは、データが動く範囲で分けると理解しやすくなります。

| 観点       | 自治体内の情報利用       | 行政機関間の情報連携      |
| -------- | --------------- | --------------- |
| データが動く範囲 | 同一自治体の中         | 府省庁・自治体等の機関の間   |
| 根拠となる仕組み | 標準準拠システムの標準仕様   | マイナンバー制度        |
| 置き換える対象  | 用途ごとの抽出・加工と個別調整 | 各機関が整備する中間サーバ等  |
| 公表された時期  | 2025年度より順次・実証的に | 2026年1月から共通サービス |

同じ名前の下にあっても、自治体の情報システム部門が直接向き合うのは主に前者です。後者は府省庁向けの共通サービスとして説明されており、自治体側の情報連携の扱いは、中間サーバを所管する側の案内を個別に確認する必要があります。

### 名前の似たIT用語のサービスメッシュとは別物であることの見分け方

検索すると、IstioやLinkerdといったマイクロサービス間通信の仕組みとしての「サービスメッシュ」も並びます。こちらはアプリケーションの通信をサイドカーで制御する技術で、行政の施策名である公共サービスメッシュとは別の概念です。

見分け方は単純で、文脈にマイナンバー・標準準拠システム・中間サーバ・デジタル庁が出てくれば施策名、Kubernetes・プロキシ・mTLSが出てくれば技術用語です。技術用語の側は[サイドカー方式の仕組みとAPIゲートウェイとの違い](https://www.issoh.co.jp/tech/details/13224/)で解説しています。

## 自治体内の情報利用で住民データが標準準拠システムから流れる仕組み

自治体の情報システム部門と、標準準拠システムを納めるベンダーに直接関わるのがこの枠組みです。デジタル庁の概要資料1枚に、変わる前と変わった後の構図がまとめられています。

### 標準化前にデータの用途ごとの抽出・加工と個別調整が発生していた構造

[自治体内の情報利用の概要資料](https://www.digital.go.jp/assets/contents/node/basic%5Fpage/field%5Fref%5Fresources/5c217fc7-a74b-4df0-8624-2fc940ccc34e/c5d3c9ae/20240711%5Fpolicies%5Fpublic%5Fservice%5Fmesh%5F01.pdf)は、標準化前の状態を「システム／用途ごとに住民データを抽出・加工している」と書いています。給付金の対象者抽出、窓口システムへの住民情報の受け渡し、統計用のデータ作成など、用途が一つ増えるたびに基幹システムからの出力を作り、受け取る側のシステムと個別に調整していた構造です。

この方式では、連携の数だけ出力プログラムと調整コストが積み上がります。給付金のように短期間で対象者データが必要になる場面では、出力形式の調整そのものが律速になります。

### 基本データリストへの適合が連携の前提になるデータ要件の位置づけ

同じ資料は今後の姿として、標準準拠システムのデータを用途に応じて業務・システム横断的に抽出・加工でき、住民データを様々なシステムへ円滑に渡せる状態を描きました。その前提として置かれているのが、標準準拠システムが「データ要件に関する標準仕様（基本データリスト）に適合すること」です。

つまり自治体内の情報利用は、標準化の成果物をそのまま土台にしています。データ要件・連携要件標準仕様書は令和4年（2022年）8月に初版が公開されたもので、20業務の標準化と同じ枠組みの中にあります。移行の全体像は[自治体システムの標準化と20業務の移行状況](https://www.issoh.co.jp/column/details/16009/)で整理しました。標準準拠システムへの移行が済んでいない業務は、この基盤に乗せられません。

### マイナポータルや給付支援サービス・民間SaaSがつながるフロントの範囲

政策ページの図では、自治体内の情報利用の先に「フロントサービス」が置かれています。挙げられているのはマイナポータルとその共通API基盤、デジタル認証アプリ、給付支援サービスなどの共通SaaS、そして民間企業のSaaSです。

民間SaaSが接続先に含まれている点は、自治体が独自に調達する窓口システムや通知サービスにも関わります。2026年5月には民間のデジタル郵便サービス事業者が、先行利用自治体と連携した実証を発表しました。来庁者の申請書作成を支える窓口システムでも、デジタル庁は他サービスとのAPI等の連携を必須要件に挙げており、その接続先の例として公共サービスメッシュが明記されています。窓口側の要件は[書かない窓口の導入条件と基幹システム連携](https://www.issoh.co.jp/column/details/17735/)にまとめています。

## 行政機関間の情報連携で中間サーバ等を共通サービスへ置き換える計画

もう一つの枠組みは、マイナンバー制度に基づく機関同士の情報照会・提供の基盤を作り替える計画です。

### 情報提供ネットワークシステムと各機関の中間サーバ等による現行の連携

デジタル庁の[行政機関間の情報連携の概要資料](https://www.digital.go.jp/assets/contents/node/basic%5Fpage/field%5Fref%5Fresources/5c217fc7-a74b-4df0-8624-2fc940ccc34e/dcf0afb5/20240711%5Fpolicies%5Fpublic%5Fservice%5Fmesh%5F02.pdf)によると、現在の機関間連携は情報提供ネットワークシステムと、各機関が個別に整備している中間サーバ等のシステムで実施されています。中間サーバは、保有情報の副本を持ち、情報の授受を仲介する役割を担う仕組みです。

機関ごとに中間サーバを構築・運用する構造のため、新たに連携を始める機関はその都度サーバを用意する必要がありました。資料はこの基盤を「高い性能、低コスト、安全」に更新することを目的に掲げています。

### 2026年1月提供開始の機関間情報連携サービスで新規連携が変わる点

同資料は、2026年1月から現行の中間サーバ等に相当する共通サービス（機関間情報連携サービス）の提供を開始するとしました。共通機能はガバメントクラウド上で提供され、情報の管理主体は引き続き各機関です。

最も大きな変化は新規連携の扱いです。2026年1月以降に新たに連携を始める府省庁は共通サービスを使えるようになり、資料の言葉では「中間サーバ個別構築が不要に」なります。新しい制度で機関間の情報照会が必要になった場合、サーバ構築の予算と期間を見込まずに済む見通しです。ガバメントクラウドの調達と費用負担の考え方は[ガバメントクラウドの仕組みと費用負担](https://www.issoh.co.jp/column/details/16150/)で確認できます。

### 連携を実施中の府省庁はシステム更改の時期に移行を検討する扱い

すでに連携している府省庁については、資料は「システム更改などのタイミングでの現行インフラからの移行を検討する」と書くにとどめています。一斉切替の期限は示されていません。

この書き方は、受託側の見積にも影響します。更改案件の要件に「機関間情報連携サービスへの移行」が入るかどうかは、発注機関の判断次第です。提案時には、更改の範囲に移行を含めるのか、現行の中間サーバを維持したまま更改するのかを最初に確認してください。

## 公共サービスメッシュの整備時期を一次資料の計画で年度ごとに確認

時期の情報は資料ごとに書かれた時点が違います。古い資料の予定を現在の事実として読まないよう、出典の日付と並べて確認します。

### 2021年10月の構想から2023年12月の二本立て整理までの経緯

公共サービスメッシュの名前が公的資料に現れるのは、2021年10月22日の[トータルデザイン実現に向けた公共サービスメッシュ等の検討資料](https://www.soumu.go.jp/main%5Fcontent/000778962.pdf)です。ここでは公共サービスメッシュを中心に、官民APIゲートウェイ、ベースレジストリ、WebAPIによるサービス群を配置した全体像が描かれ、既存のWebシステムから段階的に移行する方針が示されました。

その後、2023年12月のデジタル庁資料（[北海道庁サイト掲載の資料2](https://www.pref.hokkaido.lg.jp/fs/9/5/9/0/2/1/4/%5F/%E8%B3%87%E6%96%992%5F%E5%85%AC%E5%85%B1%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%83%A1%E3%83%83%E3%82%B7%E3%83%A5%28%E6%83%85%E5%A0%B1%E9%80%A3%E6%90%BA%E3%81%AE%E5%9F%BA%E7%9B%A4%29%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6.pdf)）で、住民情報の扱いが「機関間連携の基盤刷新」と「自治体内情報利用のモジュール整備」の両面に整理されます。自治体内側の狙いは、住民情報を使ったサービスを「最小限のシステム対応で実現する」ことと書かれました。構想段階の全体像は広く、実装段階で二つに絞り込まれた経緯です。

### 2025年度以降の提供と2026年度以降の全国運用という工程表の読み方

最も新しい工程表は、2025年6月13日の[国民向け行政サービスロードマップ](https://www.digital.go.jp/assets/contents/node/basic%5Fpage/field%5Fref%5Fresources/5ecac8cc-50f1-4168-b989-2bcaabffe870/9a4ec8e7/20250613%5Fpolicies%5Fpriority%5Foutline%5F09.pdf)です。「データ連携基盤（公共サービスメッシュ）」の行には、2025年度以降に希望する自治体が住民データを使える機能を提供し、その後に機能拡充・非機能増強を進める線が引かれています。

同じ妊娠・出生・こども分野の頁には、2026年度末以降に一部の出生・子育て関連手続をオンラインで一括申請できること、本人の申請や確認を待たずにお知らせを送付できることが並びます。基盤の整備時期と、住民が変化を実感する時期には1年以上の幅があると読むのが妥当でしょう。いずれも2025年6月時点の計画値であり、2026年10月時点の稼働状況を示すものではありません。

## 自治体とベンダーが標準準拠システム側で備えるデータとシステム要件

基盤そのものはデジタル庁が整備します。自治体と事業者に残るのは、そこへ渡すデータの品質と、周辺システムをつなぐ設計です。

### 標準準拠でも履歴の積み上げ方は事業者ごとに異なるという落とし穴

デジタル庁の[データ要件・連携要件の対応についての資料](https://www.digital.go.jp/assets/contents/node/basic%5Fpage/field%5Fref%5Fresources/c58162cb-92e5-4a43-9ad5-095b7c45100c/985d29ba/20240904%5Fpolicies%5Flocal%5Fgovernments%5Fspecification%5Foutline%5F01.pdf)は、標準化前に同じ意味のデータでも事業者ごとに項目名や持ち方が違っていたことを示したうえで、標準化後にも残る課題を挙げました。具体例は国民健康保険の資格情報で、取得・喪失の遡及申請があった場合に、A社は異動日順に履歴番号を積み上げ、B社は資格取得日順に積み上げます。同じ5件の異動でも、最新フラグが立つ履歴はA社で5件目、B社で3件目です。

項目名と型がそろっていても、「最新」が指す行が違えば、受け取る側のシステムは別の資格状態を表示します。公共サービスメッシュ経由で住民データを他システムへ渡すとき、この差はそのまま表示や判定の誤りになります。デジタル庁は2024年6月26日と8月28日に共通機能等課題検討会を開き、リファレンスや確認項目リストの提供を検討するとしました。

### 独自施策システムや窓口システムを後からつなぐために設計で残す余地

20業務の標準準拠システム以外にも、自治体には独自施策のシステムや窓口システム、子育て支援アプリが動いています。データ要件・連携要件標準仕様書には独自施策システム等連携仕様があり、標準準拠システムとの接続はこの仕様に沿うのが基本です。

周辺システムを今調達するなら、連携部分を差し替えられる構造にしておくことを契約条件に入れてください。具体的には、基幹システムからのデータ取得をファイル連携・API連携・将来の公共サービスメッシュ経由のいずれでも受けられるよう、取得処理を業務ロジックから切り離す設計です。API連携とファイル連携の違いは[API連携の仕組みとデータ連携との違い](https://www.issoh.co.jp/column/details/15354/)で整理しています。

### 連携アダプタ製品と民間SaaSの実証から見える事業者側の準備

事業者側の動きも出始めています。大手ベンダーは、各機関で共通化できる連携機能をまとめた公共サービスメッシュ向けの連携アダプタ製品を公開しました。民間SaaS側では、先に触れたデジタル郵便サービスの実証のように、ガバメントクラウド上の基幹システムのデータを公共サービスメッシュ経由で受け取る試みが発表されています。

受託開発の立場で言えば、新たに求められるのは基盤そのものの開発ではなく、基盤と既存システムの間に入る変換と検証の工程です。基本データリストのコード値への変換、履歴の意味の突き合わせ、連携テストの設計がそれにあたります。

## 公共サービスメッシュを待つ判断と今の連携投資を進める判断の分かれ目

「基盤ができるまで連携の改修は止めるべきか」という問いには、条件付きで答えが出ます。

### 待つべき場面：機関間連携の新規構築と全国運用前の専用出力の作り込み

待つべきなのは二つの場面です。第一に、マイナンバー制度に基づく機関間連携を新たに始める府省庁や機関が、中間サーバを個別に構築しようとしている場合。2026年1月以降は共通サービスで連携できるとされているため、個別構築の予算は計上しません。第二に、自治体内の住民データ連携のために、基幹システム側へ用途専用の出力プログラムを大きく作り込む場合です。全国運用の前に作り込んだ専用出力は、基盤が使えるようになった時点で二重投資になります。

### 待たずに進める場面：既存データの意味の整理と連携仕様の棚卸し

逆に、待つ理由がない作業もはっきりしています。標準準拠システムのデータが基本データリストに沿って出力されているかの確認、履歴やフラグの意味が事業者間で一致しているかの突き合わせ、庁内の周辺システムがどの項目をどの頻度で受け取っているかの棚卸しです。これらは基盤の完成時期に関係なく必要で、整理が終わっていない自治体ほど基盤への接続時に手戻りが出ます。

庁内にこの作業を担う要員がいない場合は、基幹側とフロント側の双方の仕様を読める事業者を早めに入れるのが現実的です。標準準拠システムと周辺システムの連携設計から相談できる[公共システム開発の支援](https://www.issoh.co.jp/service/business%5Fsystem/public/)のような窓口を使い、棚卸しと変換仕様の作成を先行させてください。推進体制の組み方は[自治体DX推進計画の重点項目と進め方](https://www.issoh.co.jp/column/details/16152/)が参考になります。

## よくある質問

公共サービスメッシュについて、自治体と事業者の双方から出やすい質問に答えます。

### 公共サービスメッシュは自治体に導入義務がありますか？

公表資料に一律の導入義務や期限は示されていません。自治体内の情報利用は、2025年度以降に希望する自治体へ機能を提供する計画として工程表に載っています。ただし前提として標準準拠システムへの移行が必要なため、標準化の進み具合が実質的な利用開始時期を左右します。

### 公共サービスメッシュとマイナポータルはどう違いますか？

マイナポータルは住民が手続や自己情報の確認に使う窓口で、公共サービスメッシュはその裏側でデータを渡す基盤です。デジタル庁の図では、マイナポータルとその共通API基盤は「フロントサービス」の一つとして、公共サービスメッシュの接続先に位置づけられています。

### 公共サービスメッシュは情報提供ネットワークシステムの後継ですか？

行政機関間の情報連携の部分については、情報提供ネットワークシステムや中間サーバ等の現行インフラを新たな手法に転換すると2023年12月の資料に書かれています。2026年1月からは中間サーバ等に相当する共通サービスの提供が計画されており、連携中の府省庁はシステム更改時に移行を検討する扱いです。

### 標準準拠システムを使っていれば追加の改修は不要ですか？

基本データリストに適合していることが連携の前提ですが、それだけで十分とは限りません。デジタル庁の資料が示すとおり、国保資格の履歴の積み上げ方のように、項目がそろっていても意味が事業者で異なる部分があります。連携先で正しく表示されるかの検証は別途必要です。

### 民間企業のサービスも公共サービスメッシュとつながりますか？

デジタル庁の政策ページでは、民間企業のSaaSもフロントサービスの一つとして図に含まれています。2026年5月には民間のデジタル郵便サービス事業者が、先行利用自治体と連携した実証を発表しました。本格的な接続条件や手続は今後の公表を確認する必要があります。

## 関連記事

- [自治体システムの標準化とは？20業務・経過措置と特定移行支援システムの内訳](https://www.issoh.co.jp/column/details/16009/)：公共サービスメッシュの前提になる標準準拠システムへの移行状況を確認できます
- [ガバメントクラウドとは？自治体が使う仕組み・対象サービス・費用負担を解説【2026年版】](https://www.issoh.co.jp/column/details/16150/)：共通機能が載るクラウド基盤の仕組みと費用負担を扱っています
- [書かない窓口とは？導入条件と費用・基幹システム連携を実例で解説](https://www.issoh.co.jp/column/details/17735/)：公共サービスメッシュとの連携を必須要件に含む窓口システムの調達判断をまとめています
- [API連携とは？仕組み・データ連携との違い・導入判断までわかりやすく解説](https://www.issoh.co.jp/column/details/15354/)：周辺システムの連携方式を選ぶ前提知識を整理しています
- [サービスメッシュとは？サイドカー方式の仕組みとAPIゲートウェイとの違い・導入判断を解説](https://www.issoh.co.jp/tech/details/13224/)：名前の似た技術用語のサービスメッシュを実装者向けに解説しています

---

出典: [公共サービスメッシュとは？二つの枠組みと自治体・ベンダーのシステム要件](<https://www.issoh.co.jp/column/details/18822/>)（株式会社一創）
