デジタル庁が公開した行政手続データのMCPサーバーを読む

2026年8月13日、デジタル庁の公式noteに「行政手続等調査データ（約75,000件）をMCPで自然言語分析可能に」という記事が公開されました（デジタル庁note）。国の行政手続 約7.5万件分の調査データを、Claude DesktopやChatGPTのようなAIチャットから話しかけるだけで検索・集計できるようにする実装で、ソースコードは digital-go-jp/administrative-procedures-mcp にMITライセンスで公開されています。

読んでいて手が止まったのは、dataset.yaml という定義ファイルです。CSVをそのまま渡すと、AIは列の空欄をゼロと読んだり、コード値の一部だけで絞り込んだりします。この実装は、そうした誤読を防ぐための説明書きを、データと一緒に配っています。公共データをAIへ開く事例はこの1年で一気に増えましたが、そこまで同梱したものはあまり見かけません。

Table of contents

何が公開されたのか

公開されたのは、デジタル庁が毎年公表している行政手続等の棚卸調査結果を分析するための、MCPサーバーの実装一式です。中身はこれだけです。

READMEには、これが「技術検証を目的としたサンプルコード」であり、動作の安定性も継続的な保守も、搭載データの正確性や最新性も保証しないと書いてあります。動かして考えるための実験台です。

調査結果データそのものはリポジトリに入っていません。公表後に修正や更新が入ることがあるからです。apcli fetch がデジタル庁の 行政手続等の悉皆調査結果等 から最新版を取り、Parquetへ変換します。取得日も記録されて、ツールの応答に出典として付きます。

質問はチャットからサーバーへ渡り、サーバーの中で集計されてから戻ってきます。

そもそもMCPとは何か

MCP（Model Context Protocol、モデルコンテキストプロトコル）は、AIアプリケーションと外部のツールやデータソースを安全につなぐためのオープンな標準です。Anthropicが2024年に提唱し、いまは仕様がWebサイトで公開されています（MCP仕様）。

MCPは、AIアプリにとっての共通の差込口です。差込口の形が決まっていれば、つなぐ側（AIアプリ）とつながれる側（データやツール）を別々の人が作れます。仕様書にも、プログラミング言語ごとのエディタ支援を共通化したLSP（Language Server Protocol）から着想を得た、と書いてあります。

登場人物は3種類です。

サーバーがホストへ差し出せるものは3つです。リソース はAIや利用者が読むデータ、プロンプト は定型の指示や作業手順、ツール はAIが実行できる関数。今回の実装が出しているのは、このうちツール（4つ）とMCP Apps用のUIリソースです。

クライアントはホストの内側にいるので、外から見えるのはホストとサーバーの2つです。

2025年末からの動き

2025年12月9日、AnthropicはMCPを Agentic AI Foundation（AAIF） へ寄贈しました。Linux Foundation傘下に新設された財団で、Blockの goose、OpenAIの AGENTS.md と並ぶ創設プロジェクトという位置づけです。これでMCPは、財団が中立に管理する標準になりました。発表時点で月間9,700万件のSDKダウンロードと1万件の稼働サーバーがあったそうです。

仕様も動いています。2026年7月28日公開版で、策定側は基盤プロトコルを「ステートレスで自己完結したリクエスト」と「リクエストごとの機能ネゴシエーション」を基本とする形へ整理しました。あわせて、中核仕様の外側へ 拡張（extensions） という枠組みを置いています。拡張は必ず任意（オプトイン）で、クライアントとサーバーの双方が対応を宣言したときだけ有効になります。

今回の実装は、このうちMCP Appsを実際に使っています。

元になったデータ：行政手続等の棚卸調査

分析対象は、デジタル庁が公表する「行政手続等の棚卸調査結果（令和6年度悉皆調査）」です。悉皆（しっかい）調査とは、対象を抜き取りではなく全部調べる調査のことです。

この公表は、情報通信技術を活用した行政の推進等に関する法律（平成14年法律第151号）第25条に基づいて行われています。調査の骨格は次のとおりです（調査結果概要（令和7年7月22日））。

• 調査対象機関は国の行政機関26府省等
• 調査対象は各府省が所管する法令に規定された全手続
• フェーズ1（基本項目）は令和6年10月〜12月、フェーズ2（実態項目）は令和6年12月〜令和7年6月
• 令和6年度調査では生成AIを用いて法令データを精査し、令和3年度比で約1万件の手続を追加検出

結果として、手続種類数は令和3年度調査の61,390から 75,085 へ増え、オンライン化率は31.9%から 51.6% へ上がりました。ここでいうオンライン化率は、手続の種類数のうち「実施済（一部実施済含む）」が占める割合です。一部実施済とは、府省共通の手続で一部の実施府省庁だけがオンライン化を済ませている状態を指します。この分子の取り方が後で効いてくるので、覚えておいてください。オンライン化されている手続のうち実際にオンラインで申請された件数の割合（オンライン利用率）も、約6割から約8割へ伸びています。

4年で手続の数が1万件以上増え、オンライン化率は2割近く上がりました。

公表物はExcel形式の調査結果本体（約14MB）と概要PDF、調査項目の解説PDFで、令和7年7月29日が最終更新です。38列 × 約7.5万行。Excelで開くには重く、人が全部読むには多すぎます。

生データを渡したときに起きること

7.5万行のCSVをAIに丸ごと渡すと、2つの問題にぶつかります。

1つ目は物量です。文脈長にもコストにも無理があります。しかも大規模言語モデルは足し算や割り算を確実にこなす道具ではないので、大量の数値を渡して集計させると誤りが混ざります。

2つ目のほうが厄介です。意味が伝わらない という問題があります。このデータの「オンライン手続件数」という列を例にします。この列の空欄は件数が不明という意味で、ゼロはオンライン手続がなかったという意味です。両者は別物です。ところが列の中身だけを見たAIは、空欄をゼロと同じように扱って平均を出すかもしれません。分母が水増しされ、実態より低い数字がそのまま答えとして返ってきます。

同じことは分類のコード値でも起きます。「手続類型」という列には 1 申請等 や 2-1 申請等に基づく処分通知等 といった値が入りますが、AIが「申請」という語だけで絞り込むと、意図と違う集合を数えてしまいます。

つまりAIには、2種類の情報が必要です。

同じ整理を英国政府もしています。Government Digital ServiceとDSITが2026年1月19日に公開した Guidelines and best practices for making government datasets ready for AI は、AI-readyなデータの土台を4本の柱へ整理しています。技術的最適化（効率的なデータ構造とAPIと形式）、データとメタデータの品質（正確で完全で一貫したデータと豊富なメタデータ）、組織と基盤の文脈（ガバナンス、リソース、働き方）、法務とセキュリティと倫理の遵守。付帯情報の質と、品質を継続的に監視することを重く見ています。

意味定義が欠けたときと品質情報が欠けたときでは、AIの間違え方が変わります。

デジタル庁の実装が扱っているのは、このうち意味定義と品質情報の提供という一部分です。出典・来歴の体系的な管理、バージョン管理、ライセンス、ガバナンスといった基盤全体は範囲外だと、note記事自身が明記しています。

意味を伝える dataset.yaml

意味定義を担うのは、データセットごとに置く dataset.yaml という1枚のファイルです。実装者は、統計データ交換の国際標準である SDMX（Statistical Data and Metadata eXchange、ISO 17369）のDSD（Data Structure Definition、データ構造定義）の考え方を参考に、軽い記述形式を作りました。

ファイルの骨格はこうです。

schema_version: "1"
title: 行政手続等の棚卸調査結果
publisher: デジタル庁 (Digital Agency of Japan)
id_field: 手続ID
data_file: data.parquet
source:
  url: https://www.digital.go.jp/resources/procedures-survey-results
  asset_pattern: _procedures-survey-results_outline_02\.(xlsx|csv)$
  csv_header_rows: 2
published_at: '2025-07-24'
fields: ...
computed_measures: ...

source.url には配布ページのURLだけを書き、実際のファイルは asset_pattern という正規表現で探します。なぜ直リンクを書かないのか、リポジトリのコメントに理由があります。改訂のたびに日付とパス中のハッシュが変わってリンクが腐るから、だそうです。何度か踏んだ人が書いた注意書きだと思います。

項目の役割（role）

各項目には4種類の役割のいずれかを与えます。この役割が、AIにできる操作を決めます。

たとえば「所管府省庁」は dim なので府省庁別の集計に使えますが、「手続名」は attr なので集計軸になりません。AIが何でも足し合わせないよう、実装者が先に枠を決めています。

取りうる値（codelist）

分類軸には、取りうる値の一覧を明示します。値だけを並べることも、値と説明をセットで書くこともできます。

- role: dim
  name: 手続類型
  codelist:
  - 1 申請等: 申請、届出その他の法令の規定に基づき行政機関等に対して行われる通知
  - 2-1 申請等に基づく処分通知等: 上記1の申請等に基づき、処分の通知その他の法令の規定により行政機関等が行う通知
  - 3 縦覧等: 書面等又は電磁的記録を、縦覧若しくは閲覧に供すること又は謄写させること
  - 4 作成・保存等: 書面等若しくは電磁的記録を作成、記載、記録、調製又は保存すること

値の種類が多く手で書ききれない項目（府省庁名や法令名など）には auto を指定して、実データから自動収集させられます。セミコロン区切りで複数の値が入る項目には auto_split を使います。

解釈上の注意（notes）

先ほどの「空欄とゼロは別物」という話は、notes としてファイルに書かれています。

- role: measure
  name: オンライン手続件数
  data_type: integer
  notes:
  - null（欠損）は「件数不明」を意味する。0 は基本的に「オンライン手続なし」だが、地方等で件数集計が困難な一部の手続では 0 と記録されている場合がある。
  - 件数は有効数字1〜2桁程度の概数であり、一部試算値を含む。

この置き場所が効いています。notes はツール応答の data_caveats という欄に載り、AIへ毎回送られます。実装者は注意書きを、AIが答えを組み立てる瞬間に必ず届く場所へ置きました。CSVからParquetへ変換するときも、数値列の空セルはゼロにせず null のまま保ち、集計では自動的に除外します。

この2行があるかないかで、同じ列の読み方が変わります。

計算式をサーバー側に置く（computed_measures）

「オンライン率」のような比率は、定義ファイル側に書いておきます。

computed_measures:
- name: オンライン率
  mode: count_where
  condition_field: オンライン化の実施状況
  condition_values:
  - 1 実施済
  desc: オンライン化実施済の手続種類数 / 全手続種類数

count_where は条件に当てはまるレコードの割合を出すモードです。件数どうしの比を取る sum_ratio モードもあります。どちらも分子と分母の決め方が定義ファイルに固定されるので、AIが独自の分母を持ち出す余地がなくなります。

ここで注意がひとつあります。この condition_values は 1 実施済 だけで、5 一部実施済 を含んでいません。一方、調査結果概要が51.6%として出しているオンライン化率は「実施済（一部実施済含む）」です。つまり実装の「オンライン率」と公式の「オンライン化率」は、名前が似ているだけの別指標で、数字も一致しません。5 一部実施済 を condition_values へ足せば公式の定義に揃います。

定義をファイルに固定するとAIの独走は止まりますが、その定義が公式資料と揃っているかどうかは別の話です。サーバーが返した数字を公式のオンライン化率として引用しないでください。ここは、機械可読にしたことでかえって見えにくくなった部分だと思います。

ここまで読んで気づくのは、desc や notes を埋めるのが人間の仕事だということです。開発ガイドは、項目説明資料を生成AIに読ませて下書きさせる手順を勧めていますが、そのあとで人が確認すべき点を5つ挙げています。コード値が実データと一致しているか、数値項目の注意を書いたか、0と欠損を区別できているか、算出項目の分子と分母のフィールド名が正しいか、利用者に不要な管理項目を外したか。つまりAIの誤読を減らすために、人がデータを読み込む工程が先に来ます。ここを飛ばすと、間違った意味定義を機械可読な形で配ることになるので、生CSVを置いておくより厄介です。

品質を伝える inspect_dataset

意味定義はファイルに書かれた静的な情報です。品質情報のほうは、実データから毎回計算されます。inspect_dataset というツールが返すのは次の3つです。

• 充填率（fill_rate）：その項目に値がどれだけ入っているか
• 数値統計（numeric_stats）：数値項目の分布
• 品質要約（quality_summary）：充填率を高中低に区分した全体像

note記事に掲載された procedures-survey-r6 の実行結果は次のようなものでした。

低カバレッジが半分以上と聞くと品質が悪そうに見えますが、この調査には、条件に当てはまる手続だけが答える項目が多く含まれています。たとえば「手数料等の納付方法」は、手続類型が 1 申請等 で、かつ手数料等が有りの手続だけが対象です。母数が限られる項目の充填率が低いのは当然で、危ないのは その事情を知らないAIが、回答率の低い項目として扱ってしまうほう です。充填率を数字で返しておけば、AIは答えに確信の度合いを添えられます。

低カバレッジの21項目は、多くがこの種の条件付き項目です。

ひとつ気をつけたい点があります。note記事の実行結果に出るレコード数（75,071件）と、概要資料の手続種類数（75,085）が合いません。データが更新版に差し替わったか、集計単位が違うかだと思いますが、確かめられませんでした。この数字を引用するときは、どの版を見たのかを一緒に書いてください。

発見から集計までを担う4つのツール

MCPツールは4つだけです。ツールが増えるほどAIは選択を誤りやすくなるので、責務を分けた最小構成にした、と開発ガイドにあります。

エージェントは上の層から下の層へ、一方向に進みます。

集計の算術はすべてサーバー側で終わります。AIが決めるのは何をどの軸でどう集めるかという条件だけで、足し算や割り算には触れません。桁の取り違えやコード値の誤用が入り込む隙を、これで減らしています。

実際のやり取りでは、まず発見の層で地図を手に入れ、それからデータの層へ降ります。

応答には集計結果に加えて、出典（provenance）、項目の注意事項（notes）、品質サマリ（quality_summary）が付きます。AIが数字の出どころを答えられるようにするためです。

入力制限も置いてあります。query_records の取得件数は既定50件で上限5,000件、summarize_records の返却グループ数は既定200で上限10,000。制限を超えた入力は、はっきりエラーとして跳ね返します。

MCP Appsでチャットの中にグラフを描く

MCP Appsは、サーバーが対話型のHTML画面を返し、ホストがチャットの中に描画できるようにする拡張です。ツールの説明に ui:// で始まるUIリソースへの参照を持たせておくと、ホストがそれを取得してサンドボックス化されたiframeの中で表示します。画面とホストのやり取りは postMessage を経由するので、画面から親ページのDOMやCookieには触れません。

今回の実装では、summarize_records の集計軸の数に応じて表示形式が切り替わります。

軸の数がそのまま分岐になっています。

描画用のApache ECharts 6.1.0はリポジトリに同梱し、HTMLへインラインで注入します。外部CDNへ取りに行かないので、閉じた環境でも動きます。UIを描画しないクライアント向けには、環境変数 MCP_NO_UI でUIを切り、テキストだけで使う道も残してあります。

サーバー側でグラフまで作る利点は地味です。AIに描画コードを書かせると、そのコードの正しさを毎回人が確認することになります。集計結果とグラフをサーバーが対で返せば、確認する場所はサーバーの実装1か所で済みます。

Parquetと遅延ロードという選択

データ本体の形式は Apache Parquet です。Parquetは列指向の圧縮バイナリ形式で、列ごとにまとめて格納します。同じ列には似た値が並ぶので圧縮が効きやすく、必要な列だけを読めます。

圧縮はよく効きました。約7.5万行 × 39列が 約3MB です。元のExcelは約14MBでした。

Parquetはファイルの末尾（フッター）にメタデータを持ちます。実装者はこの性質を使って、読み込みを2段階に分けました。

起動が軽くなりますし、データセットを何本登録しても、使われないものはメモリを食いません。検索と集計そのものは polars のLazyFrameが担当します。

14MBが3MBになり、そのうえ起動時にはほとんど読みません。

おかげでデータセットの追加が軽くなりました。datasets/ の下に dataset.yaml と Parquetファイルを置けば、Pythonのコードを1行も触らずに認識されます。CSVから雛形のYAMLとParquetを作る prepare_dataset.py も同梱されているので、他の公共データにも使えそうです。

LLMとの対話を成り立たせる実装の工夫

実際にLLMとつないでみないと気づきにくい工夫が、いくつも入っています。

MCPに依存しないロジック層

検索と集計、応答生成のロジックは、MCPやFastMCPに依存しないモジュールへ分けてあります。MCP固有の変換（ToolResult の生成など）を担当するのは server.py という薄いアダプターだけです。

この分離のおかげで、同じロジックをCLIからもHTTPからもstdioからも使い回せますし、ユニットテストもMCPサーバーを立てずに走ります。テストではさらに、約100MBの実データを落とさず、4件のサンプルレコードを一時ディレクトリへ作る方式にしています。CIの実行時間と外部ネットワーク依存を避けるためです。

パラメータの型揺れを吸収する

LLMはツールの引数を、辞書（dict）で送ってくることもJSON文字列で送ってくることもあります。値が1つのときに "field" と送るか ["field"] と送るかも一定しません。実装はこれらの形式をサーバー側で受け入れ、内部形式へ正規化します。CLIでも、繰り返しフラグとJSON配列の両方を受け付けます。

apcli summarize procedures-survey-r6 -g 所管府省庁 -m count
apcli summarize procedures-survey-r6 \
  --group-by '["所管府省庁"]' --metrics '["count"]'

サーバー側で受け止めてしまうので、プロンプトで型を守らせる必要がありません。

項目名のあいまい照合

LLMは、漢字の似た文字を取り違えることがあります。note記事は「懸」を「憸」と書いてしまう例を挙げています。実装は3段階で照合します。

1. 完全一致
2. Unicode NFKC正規化（全角・半角などの表記揺れをそろえる）後の一致
3. difflib による近似一致

ただし近似一致は危険と隣り合わせなので、ガードを4つ掛けています。適用対象は項目名だけに限る、類似度のしきい値を設ける、difflib から受け取る候補を1件に制限する、そして 補正した事実を resolved_fields として応答に明示する。それでも救えない入力には、エラーとして候補と使用例を返します。

3つ目は「候補が一意だと検証している」わけではありません。しきい値を超えた最上位の候補を1件だけ採る作りなので、2位が僅差で並んでいても気づけません。だから4つ目が効いてきます。黙って直すと、AIも人も自分の入力は正しかったと思い込みます。直したことを書き添えるかどうかは、小さいようで大きな違いです。

列指向でトークンを減らす

レコードの配列をそのままJSONにすると、1件ごとにキー名が繰り返されてトークンを浪費します。実装は列指向の形へ変換して返します。

{
  "columns": ["所管府省庁", "手続名", "オンライン化の実施状況"],
  "rows": [
    ["国土交通省", "（手続名の例）", "1 実施済"],
    ["厚生労働省", "（手続名の例）", "2 未実施"]
  ]
}

50件、100件と返すときに効いてきます。受け手であるLLMのトークン量を基準に、返す形を決めた例です。

4つに共通するのは、LLMの出力が揺れる前提で受け皿を作っている点です。

手元で動かしてみる

必要なのはPython 3.10以上です。

git clone https://github.com/digital-go-jp/administrative-procedures-mcp.git
cd administrative-procedures-mcp
./setup.sh

setup.sh が依存パッケージのインストール、調査結果データの取得、接続方法の案内までを行います。

AIを介さずCLIから触るのがいちばん手早い確認方法です。

apcli list                                   # データセット一覧
apcli inspect procedures-survey-r6           # 構造と品質の確認
apcli query procedures-survey-r6 -q 相続 --limit 5
apcli summarize procedures-survey-r6 -g 所管府省庁 -m count

--html または -o を付けると、データを埋め込んだ自己完結型のHTMLを出力できるので、ブラウザで開くだけでグラフを確認できます。

MCP Appsの動きを一通り見たいなら、プレビューがあります。

apcli preview --port 8765

ブラウザで http://127.0.0.1:8765/ を開くと、ブラウザ内蔵のAI をモデルとして、質問→ツール選択→チャート描画という流れをAPIキーなしで確認できます。Chrome 138以降ではGemini Nano、Microsoft EdgeではPhi-miniが使われます（いずれも初回はモデルのダウンロードが必要で、事前にブラウザのフラグを有効化します）。ツールの実行はlocalhostの中で完結します。ただし内蔵AIは小型モデルなので、複数条件の組み合わせや複雑な絞り込みは期待どおりに動かないことがあると注意書きがあります。

Claude Desktopから使う場合は設定ファイルへサーバーを登録しますが、apcli install desktop が代行してくれます。Claude Codeについては .mcp.json が同梱されているため、クローンしたディレクトリで起動するだけで接続されます。

MCP仕様のバージョンについては、既定のインストール（FastMCP 3系）が 2025-11-25 で動作し、FastMCP 4系のプレリリースを追加すると 2026-07-28 で動作します。HTTPモードで起動していれば、/health の mcp_protocol_version を見られます。ただしこの値は、導入したMCP SDKが対応する最新版を返しているだけで、個々のクライアントと実際にネゴシエートした版ではありません。2026-07-28版はリクエストごとに版を渡す形なので、両系列に対応するサーバーでは通信ごとに違う版で話している可能性もあります。手元の構成がどちらの系列で動いているかを確かめる用途に留めてください。

外部公開についての注意もはっきり書いてあります。HTTPモードは既定で 127.0.0.1 にだけバインドされ、実装自体は利用者認証や認可、レート制限、監査ログを持ちません。外から届くようにするなら、認証と通信制限を備えたリバースプロキシを前段に置け、とのことです。ローカルか単一利用者向けの実験用サンプルという位置づけです。

4番目まで行かなくても、2番目のCLIまでで中身はだいたい掴めます。

公共データをAIへ開く動きの広がり

公共データをMCPサーバーとして公開する動きは、2025年後半から各国で広がっています。

面白いのは、センサス局の実装もデータセットの一覧、地理階層の取得、集計データの取得という具合に、発見と取得を分けている点です。統計データをAIへ開こうとすると、似た構造に落ち着くのかもしれません。

半年のあいだに3つ並んだことになります。

調べた範囲では、デジタル庁の実装だけが 意味定義と品質情報を最初から組み込んで います。経路を作ったうえで、届いた先で誤読されないための手当てを同じパッケージへ入れました。

引き受けている範囲と、外している範囲

検証できたこと

• 項目の意味と品質情報をAIへ渡すと、AIの誤った補完や推測をどこまで抑えて分析できるのかを、動くコードで確かめられること
• 集計の算術をサーバー側へ寄せ、AIには条件の指定だけを任せる分担が成り立つこと
• dataset.yaml とParquetという2ファイルの構成なら、行政手続データ以外の公共データセットにも同じ枠組みを当てはめられること
• MCP Appsで、チャットの中に表とグラフまで出せること

手をつけていないこと

• 出典と来歴の管理、バージョン管理、ライセンス、ガバナンスといったAI-ready化の基盤全体
• 複数の利用者を収容する本番運用に必要な認証や認可、レート制限、監査ログ
• データそのものの正確性や最新性の保証（各府省庁が公表した調査時点の情報です）

もうひとつ、共有基盤へ持っていくなら先に手当てが要ると思った点があります。dataset.yaml は信頼済みの設定ファイルとして扱われていて、このファイルには取得先URLもローカルファイルの位置も書けます。だから出所不明のYAMLに apcli fetch や apcli add を実行するな、と開発ガイドにはっきり書いてあります。コードを触らずデータセットを足せるという長所は、誰でもYAMLを置けるという短所と裏表です。ローカルで1人が使うぶんには問題ありませんが、部署で1台立てて共有するような使い方をするなら、最初に考えることになります。

note記事も、複数ユーザーによる大規模運用ではデータ基盤の整備が別途必要になる可能性に触れています。それでも、公開済みのCSVに dataset.yaml を1枚足すと何がどこまで変わるのかは、このリポジトリを動かせば手元で測れます。自分が公共データを扱う側なら、まず自分のデータセットで同じYAMLを書いてみると思います。書けない項目が出てきたら、それはAI以前に人間にとっても曖昧な項目だった、ということなので。

要点

• デジタル庁が、行政手続等の棚卸調査結果 約7.5万件をMCPで自然言語分析できるサーバー実装を、技術検証目的のサンプルとしてMITライセンスで公開した
• 約7.5万件をLLMに直接読ませず、LLMは検索と集計の条件を指定するだけ。算術はサーバー側で終わらせる
• dataset.yaml がSDMXのDSDを参考に、項目の役割、コード値、解釈上の注意を機械可読な形で定義し、inspect_dataset が充填率などの品質情報を実データから毎回返す
• ツールは発見の層（list_datasets、inspect_dataset）とデータの層（query_records、summarize_records）の4つだけ。MCP Appsが集計軸の数に応じたグラフをチャットの中へ描く
• 公共データをMCPで開く動きはインドや米国でも進んでいるが、意味定義と品質情報まで同梱した例は調べた範囲では見つからなかった。ただし desc や notes を書くのは人の仕事で、AIの誤読を減らす作業は人がデータを読み込むところから始まる

参考資料

• デジタル庁note「行政手続等調査データ（約75,000件）をMCPで自然言語分析可能に」（2026年8月13日公開）
• GitHub「digital-go-jp/administrative-procedures-mcp」README、開発ガイド、dataset.yaml記述ガイド、datasets/procedures-survey-r6/dataset.yaml（2026年8月17日参照）
• デジタル庁「行政手続等の悉皆調査結果等について」（令和7年7月29日更新）
• デジタル庁「行政手続等の調査結果概要」（令和7年7月22日、PDF）
• Model Context Protocol「Specification 2026-07-28」
• Model Context Protocol「MCP Apps」
• MCP Blog「MCP joins the Agentic AI Foundation」（2025年12月9日）
• GOV.UK「Guidelines and best practices for making government datasets ready for AI」（Government Digital Service および DSIT、2026年1月19日公開）
• SDMX（Statistical Data and Metadata eXchange、ISO 17369）
• Apache Parquet
• GitHub「nso-india/esankhyiki-mcp」／GovInfo「AI Agents Meet Federal Data: Public Preview for the GovInfo MCP Server」／GitHub「uscensusbureau/us-census-bureau-data-api-mcp」（いずれも2026年8月17日参照）