p4ni.

比較

デジタル庁が行政手続データを MCP で公開。他の国はどうしているのか

· 読了まで約18分

目次

デジタル庁が 2026年8月13日、Tech ブログ(note)に「行政手続等調査データ(約 75,000 件)を MCP で自然言語分析可能に」という記事を公開しました。書いたのはプロダクトマネージャーの土岐竜一氏です。国の行政手続のオンライン化状況を調べた悉皆調査の結果データ約 75,000 件を、Claude Desktop や ChatGPT から対話形式で分析できるようにする MCP サーバーの技術検証で、コードは GitHub で公開されています。

読んで面白かったのは「政府が MCP サーバーを出した」というニュース性の部分ではありません。生データを LLM に読ませない集計設計、データの意味と品質をどう機械可読にして AI に渡すかという設計判断が、YAML の抜粋やハマりどころ込みで具体的に書かれている部分です。政府のデータに興味がなくても、MCP サーバーを作る人なら持ち帰れるものがあります。

この記事では前半でデジタル庁の実装を読み解き、後半で米国・インド・英国の政府データ × MCP の動きを調べて並べます。先に結論を言うと、各国のツール構成は驚くほど同じ形に収斂していて、差が出ているのは提供形態と、データの「意味」をどこまで渡すかの踏み込みでした。

題材は行政手続のオンライン化調査、約 75,000 件

まず対象データです。行政手続等調査は、国の法令等に基づく行政手続のオンライン化状況などを調べるもので、デジタル庁が法律(情報通信技術を活用した行政の推進等に関する法律 第25条第2項)に基づいて結果を公表しています。現在公開されているのは令和6年度のデータで、形式は 38 列 × 約 75,000 行の CSV と、項目の意味を説明する PDF 資料です。

つまり出発点は、どの府省庁のどの手続がオンライン化されているか(いないか)を網羅した巨大な表と、その読み方を書いた人間向けの文書という、行政データの典型的な姿です。これを「結婚に伴う手続を府省庁横断で一覧して」「所管府省庁別のオンライン化率をグラフで」のような自然言語の質問に答えられる状態にするのが今回の検証です。

LLM に計算させない。条件の指定だけをさせる

実装の最も重要な設計判断は、約 75,000 件のデータを LLM のコンテキストに読み込ませないことです。LLM が担当するのは検索・集計条件の指定までで、実際の絞り込みや加重平均などの計算はすべて MCP サーバー側で実行します。

ツールは 4 つだけです。データセットの存在と構造を把握する Discovery 層に list_datasets と inspect_dataset、実データを触る Data 層に query_records と summarize_records。エージェントはまず一覧と構造を確認してから検索・集計に進む、という流れが型として決まっています。

データ本体は CSV ではなく Apache Parquet で持ちます。列指向の圧縮形式なので約 75,000 行が約 3MB に収まり、さらにフッターにスキーマと行数のメタデータを持つため、サーバー起動時はメタデータだけを読んでデータセット一覧を返し、実データは最初のクエリが来た時点で初めてロードする遅延読み込みができます。新しいデータセットの追加は Parquet ファイルと後述の dataset.yaml を置くだけで、サーバー側のコード変更は不要という作りです。

この構成の狙いは記事中で明確に述べられています。集計の算術処理がサーバー側で完結するため、LLM の算術ミスやコード値の誤用を抑えられ、結果を検証しやすくなる。裏を返せば「生データをそのまま AI に渡すだけでは誤りは防げない」という認識が出発点にあります。この認識が正しいことを示す海外の実測が後半に出てきます。

dataset.yaml と inspect_dataset:データの意味と品質を機械可読で渡す

では、生データに何を添えれば AI はデータを正しく扱えるのか。この実装の答えは、項目の意味や許容値を記述した意味定義と、充填率や数値分布といった品質情報の 2 つです。

意味定義は dataset.yaml という独自形式の軽量な YAML に書きます。参考にしているのは統計データ交換の国際標準 SDMX の DSD(Data Structure Definition)で、分析軸(Dimension)・数値項目(Measure)・属性(Attribute)と、値の語彙を定義する Codelist の考え方を借りています。記事に載っている抜粋がわかりやすいので引きます。

# 分析軸: 許容値を明示 → 不正な値での絞り込みを防止
- role: dim
  name: 手続類型
  codelist:
    - 1 申請等: 申請、届出その他の...
    - 2-1 申請等に基づく処分通知等: ...

# 数値項目: 解釈上の注意を付与
- role: measure
  name: オンライン手続件数
  notes:
    - null(欠損)は「件数不明」を意味する。

# 算出数値項目: サーバー側で計算
computed_measures:
  - name: オンライン率
    condition_field: オンライン化の実施状況
    condition_values: ["1 実施済"]

3 つの仕掛けがそれぞれ別の誤りを潰しています。codelist は存在しない値での絞り込みを防ぎ、notes は「null は 0 ではなく不明」のような解釈の注意をクエリ結果に自動で付けて、概数が精密値として引用されるのを防ぎます。computed_measures は「オンライン率」のような指標の計算式をサーバー側に持たせ、LLM が加重平均を自前で(たいてい間違って)計算するのを防ぎます。

品質情報のほうは inspect_dataset ツールが実データから動的に算出します。項目ごとの充填率(fill_rate)、数値の統計量、品質の要約。SDMX が品質や方法論の情報を Reference Metadata として扱う考え方が下敷きです。AI はデータを触る前に「この列はどのくらい埋まっているか」を知れるので、欠損だらけの列で平均を出すような集計を避けられます。

このあたりの発想は、Web サイトの構造を AI 向けに機械可読で渡す llms.txt と同じ系譜です。人間向けの説明文書(今回なら項目説明 PDF)を、AI が参照できる形式に翻訳して本体データに添える。データセットの世界では SDMX という既存の標準があるぶん、車輪を再発明せずに済んでいます。

LLM の入力揺れ対策は、政府に限らず全 MCP サーバー実装者に効く

記事の後半には、LLM にツールを呼ばせて実際に発生した問題と対処が列挙されています。ここは政府データと関係なく、MCP サーバーを書く人全員に刺さる内容です。

  • パラメータの型揺れ。docstring で型を指定していても、LLM は引数を dict で送ったり JSON 文字列で送ったりし、単一値を "field" と ["field"] のどちらで送るかも安定しない。サーバー側で複数形式を受けて正規化する
  • 項目名のあいまい照合。LLM が似た漢字を混同する事例(「懸」→「憸」)が実際に起きたため、完全一致 → Unicode NFKC 正規化 → difflib による近似一致の 3 段階で照合する。ただし近似一致はフィールド名という閉じた語彙に限定し、データ値には適用しない。補正した事実はレスポンスに明示する
  • エラー応答での候補提示。項目名を間違えたら、類似候補と使用例をエラーに含めて LLM が自力で直せるようにする
  • 列指向レスポンス。list[dict] 形式はレコードごとにキー名が繰り返されてトークンが膨らむため、応答を {"columns": [...], "rows": [[...]]} に変換する

どれも地味ですが、「LLM は仕様どおりに呼んでこない」前提でサーバー側が受けを広くし、直した事実は隠さず返す、という一貫した態度が読み取れます。似た漢字の混同のような CJK 特有の揺れへの対処は、英語圏の実装ではまず出てこない知見です。

UI 面では MCP Apps(MCP サーバーがチャット UI 内にグラフや表を直接表示できる公式拡張)を試作していて、集計軸が 1 つなら円グラフや棒グラフ、2 軸なら積み上げ棒やヒートマップ、3 軸以上ならツリーマップやサンキーダイアグラムをタブで切り替えられます。さらに apcli preview を使うと、Chrome の内蔵 AI(Prompt API)をモデルにして、MCP 対応チャットのアカウントも API キーも無しにブラウザ単体で一連の流れを試せます。Python 3.10 以上の環境で setup.sh を実行すれば数分で動くとのことです。

海外はどうか:米国は機関ごとに MCP サーバーを出し始めている

ここからが後半です。デジタル庁の記事自体が「公共データの MCP 公開はインド・米国の政府機関が先行している」と書いているので、その一次情報を追いかけました。

米国でまず動いたのは統計と公文書の機関です。国勢調査局(Census Bureau)は Census Data API の MCP サーバーを GitHub で公開しています(CC0 ライセンス。利用には無料の Census API キーが必要です)。ツールは list-datasets、fetch-dataset-geography、fetch-aggregate-data、resolve-geography-fips の 4 つ。地名を FIPS コードに解決するツールが独立しているあたりに、地理階層(州・郡・市)がすべての軸になる国勢調査データらしさが出ています。技術構成は TypeScript + Docker + PostgreSQL で、ローカルの Postgres が API 情報を補完して検索を強化する作りです。

政府出版局(GPO)は 2026年1月22日に GovInfo MCP Server のパブリックプレビューを開始しました。議会文書や連邦官報を含む GovInfo のコンテンツを対象に、人間には Web UI、プログラムには API、AI エージェントには MCP という三層で同じデータを提供する位置づけです。

効果の実測もあります。報道によれば、US Digital Corps のフェローが USASpending(政府支出)と CDC PLACES(地域保健統計)のデータで検証したところ、MCP なしではほぼ 0% だった照会の正答率が MCP 経由で 95% に跳ね上がりました。MCP なしの LLM は Web 検索を試みて失敗し、MCP ありでは同じ質問に信頼区間付きの統計を即答した、という対比が紹介されています。デジタル庁の記事が前提に置いた「生データや Web 検索では誤りを防げない」を、別の国が数字で裏付けた形です。

そして米国はこれを個別機関の取り組みから制度に広げようとしています。GSA(一般調達局)は 2026年 MCP Server and AI Agent Hackathon を 2026年9〜10月に開催予定で、連邦職員・請負業者に加えて州・地方の職員も参加できます。お題は公開データの MCP サーバー化、政府サービスからの読み取り連携、書き込み連携の 3 トラック。政府データにつながる MCP サーバーのプロトタイプ群をライブラリとして積み上げる、と明言されています。

インドは公式ホスト済みの MCP サーバーを常時稼働させている

インドは提供形態で一歩先を行っています。統計・計画実施省(MoSPI)の eSankhyiki MCP Server は、労働力調査(PLFS)・消費者物価指数(CPI)・鉱工業生産指数(IIP)・国民経済計算など 31 のデータセットを対象に、mcp.mospi.gov.in で公式ホストされた公開サーバーとして稼働しています。セルフホスト用のソースコード(MIT ライセンス)も公開されていますが、基本は URL を Claude や Cursor に登録すればそのまま使えるリモートサーバーです。

ツール構成は list_datasets → get_indicators → get_metadata → get_data の 4 段階で、順に呼ぶことが前提。FastMCP で構築され、OpenTelemetry による分散トレーシングまで組み込まれています。公式ホストで不特定多数に使わせる以上、可観測性が要る、という運用側の必然が構成に表れています。

英国はサーバーより先にガイドラインを出した

英国からは動くサーバーの話が出てきません。代わりに 2026年1月19日、政府デジタルサービス(GDS)と科学・イノベーション・技術省(DSIT)が「Guidelines and best practices for making government datasets ready for AI」というガイダンスを公開しました。

内容は、技術的最適化・データとメタデータの品質・組織的コンテキスト・法とセキュリティの 4 本柱で政府データセットの AI-ready 化を定義するものです。所有者と更新頻度とライセンスを含むリッチなメタデータ、データセットをオーナー付きの「プロダクト」として扱うこと、品質の継続監視(Data Quality Action Plan)。相互運用の文脈で MCP にも言及しており、機械可読な能力記述によって AI からのデータ発見と到達を可能にする技術と位置づけています。

デジタル庁の記事はこの英国ガイダンスを明示的に参照しています。つまり今回の日本の実装は、英国が文書で示した「付帯情報の品質確保」を、dataset.yaml と inspect_dataset という動くコードで示した実装例、という位置づけで読めます。

並べると見えること:ツールの形は収斂し、提供形態が分かれる

日・米・印の実装を表で並べます。

日本(デジタル庁)米国(Census Bureau)インド(MoSPI)
対象データ行政手続等調査 約75,000件国勢調査・人口統計統計 31 データセット
ツール構成一覧 → 構造 → 検索・集計の 4 ツール一覧 → 地理 → 集計 → コード解決の 4 ツール一覧 → 指標 → メタデータ → データの 4 ツール
提供形態サンプルコード配布(技術検証)GitHub 配布 + 要 API キー公式ホスト済みリモートサーバー
技術Python、Parquet、MCP AppsTypeScript、Docker、PostgreSQLFastMCP、OpenTelemetry
ライセンスMITCC0-1.0MIT

まず収斂の話。三者は互いに参照し合ったわけでもないのに、全員が「データセット一覧 → 構造・メタデータの確認 → 実データへのクエリ」という 3〜4 ツールの段階構成に落ち着いています。生データを丸ごと渡さず、LLM には発見と条件指定をさせ、計算と検証はサーバー側で持つ。政府データ × MCP の設計パターンは、2026 年時点でほぼこの形に固まったと言ってよさそうです。

次に差分。ひとつめは提供形態で、インドは公式ホスト済みのリモートサーバー、米国はコード配布と一部ホスト(GovInfo)の併用、日本は技術検証のサンプルコード配布です。デジタル庁の記事も、複数ユーザーによる大規模運用にはデータ基盤の整備が別途必要になると率直に書いています。「試せる」から「常時使える」への距離は、この 3 か国では日本がいちばん遠い。

ふたつめの差分は踏み込みの方向です。日本の実装が独自に厚いのは、意味定義と品質情報という AI-ready 化のレイヤーと、MCP Apps によるチャット内グラフ表示、ブラウザ内蔵 AI での動作という UI 側の実験です。MCP Apps は 2026年7月28日のプロトコル改訂で入った Extensions 枠組みに基づく公式拡張で、これを政府機関が実装して公開した例はまだほとんどありません。ホスティングでは後発でも、仕様の最前線を試す場所としては先頭集団にいます。MCP 経由で Skill(エージェントに作業手順を渡す仕組み)を配信する仕様策定が公式ワーキンググループで進んでいることにも記事は触れていて、この動きは以前書いた Agent Skills の注入面の話ともつながってきます。配信経路が標準化されれば、信頼境界の設計は今より重要になります。

技術検証と書いてあるものを、技術検証として読む

最後に位置づけの確認です。デジタル庁の記事は、これが技術検証目的のサンプルコードであり、動作の安定性や継続的な保守を保証するものではないと明記しています。インドのような公式ホスト済みサーバーと同列に「日本も政府 MCP を公開した」と読むのは正確ではありません。

それでも、この検証が公開された意味は小さくないと思います。行政データの公開は長らく「CSV と PDF を置く」が到達点でした。今回の実装は、その先にある「AI が誤読せずに使える形で置く」に必要なものを、意味定義・品質情報・サーバー側集計という具体的な部品に分解し、他の公共データセットにも流用できる形(dataset.yaml + Parquet を置くだけ)で示しました。米国の実測が示すとおり、AI がデータに MCP 経由で接続できるかどうかで、正答率はほぼ 0% と 95% ほども変わります。

CSV を置くことと AI から使えることのあいだには、思ったより長い距離があります。その距離を埋める部品が何かは、もう各国の実装でだいたい見えてきました。次に問われるのは、それを検証で終わらせず常時稼働のインフラにする体力で、ここはインドが先に答えを出しています。日本の次の一手が、ハッカソンのような裾野の拡大なのか、e-Stat や e-Gov のような既存基盤への組み込みなのかは、続報を待ちたいところです。

参考リンク