株式会社TIMEWELLの濱本 隆太です。
デジタル庁が、行政手続等の棚卸調査結果（約75,000件）を自然言語で検索・集計できるMCPサーバーを公開しました1。Claude Desktop や ChatGPT などのチャットから接続すると、「所管府省庁ごとの手続件数ランキングを教えて」といった聞き方でデータを触れます。
ニュースとしては「行政データがAIで分析できるようになった」という話ですが、私が面白いと思ったのは公開したこと自体ではなく、その設計のほうでした。
AIに生データを渡して計算させていません。 AIには「何をどう集計するか」だけを決めさせ、実際の計算はサーバー側で完結させています。これは、社内データをAIに触らせようとしている企業にとって、そのまま参考になる設計だと思います。
MCPを知らない方にも読めるように、前提から書きます。
この記事の要点
- 対象は行政手続等の棚卸調査結果（令和6年度悉皆調査）、約75,000件
- GitHubで公開、ライセンスはMIT。ただし技術検証目的のサンプルコードと明記されている
- Claude Code なら設定不要。 リポジトリに
.mcp.jsonが同梱されている - 設計の核心はAIに計算させないこと。集計はサーバー側で完結させる
dataset.yamlで項目の意味・コード値・注意事項を定義し、AIの誤った推測を減らす- 応答に出典・注意事項・データの充填率が付いてくる
- **LLMを使わないCLI（
apcli）**も同梱。AI抜きでも同じデータを触れる - デジタル庁のMCP公開はこれが最初ではない。補助金の
jgrants-mcp-serverが先にある
前提：MCPとは何か
まずここからです。
何を解決する規格か
AIに社内の売上データを分析させたい、としましょう。従来はAIとデータベースをつなぐ接続プログラムを個別に書く必要がありました。AIを別のものに乗り換えたら、その接続は作り直しです。 データソースが10個、AIクライアントが3つあれば、理屈のうえでは30通りの組み合わせを面倒みることになります。
MCP（Model Context Protocol）は、この接続部分を共通の規格にしたものです。 データソース側に「MCPサーバー」を1つ用意すれば、MCPに対応したどのAIクライアントからでも同じように使えます。
規格が決まっているだけ、という言い方もできます。ただ、その「だけ」が効きます。
何ができるようになるのか
MCPサーバーは、AIに対して**「使える道具の一覧」**を提示します。AIはその道具の説明を読んで、必要なものを選んで呼び出します。
今回のデジタル庁のサーバーが提示している道具は4つです1。
| ツール | できること |
|---|---|
list_datasets |
使えるデータセットの一覧を返す |
inspect_dataset |
データの構造と品質の概要を取得する |
query_records |
条件を指定してデータを取り出す（絞り込み、全文検索、並べ替え、ページ送り） |
summarize_records |
グループ別に集計する（件数、合計、平均、最小、最大） |
利用者は、この4つを意識する必要はありません。「厚生労働省の手続を5件見せて」と書けば、AIが query_records を選んで条件を組み立てます。
AI駆動開発を、実務で使えるところまで
トレンドを追うだけで終わらせないための実践プログラムがWARPです。元大手DX・データ戦略の専門家が、現場で動かすところまで伴走します。
何が使えるようになったのか
データの中身
対象は行政手続等の棚卸調査結果（令和6年度悉皆調査）、データセットIDは procedures-survey-r6 です1。
行政手続がどれだけあって、どの府省庁の所管で、オンライン化されているのかどうか。約75,000件分が、そのまま調べられる状態になります。
ひとつ実務的な注意があります。データ本体はリポジトリに入っていません。 公表後に修正や更新が入ることがあるため、apcli fetch というコマンドがデジタル庁の配布ページ2から取得して、Parquet形式に変換する仕組みです。
「同梱したデータが古くなる」問題を、そもそも同梱しないことで避けているわけです。地味ですが、真似する価値のある判断だと思います。
実際にどう聞くのか
READMEに例示されているプロンプトを引きます1。
所管府省庁ごとの手続件数ランキング（上位）を教えてください。 先にデータセット構造を確認した上で、出典と品質情報も含めてください。
オンライン未実施の手続にはどんな傾向があるか知りたい。 まず全体を集計して、そのあと具体例を数件見せて。
優先的に見直し候補になりそうな行政手続を探してください。 申請等の手続に絞り、オンライン未実施のものから改善候補を抽出してください。 事実と提案は分けて書いてください。
3つ目のプロンプトに注目してください。「事実と提案は分けて書いてください」と指示しています。 データ分析をAIにやらせるときの実務的なコツが、公式のサンプルに入っている。ここは細かいですが、よくできていると思いました。
接続方法
Claude Code はいちばん簡単です。 リポジトリに .mcp.json が同梱されているので、クローンしたディレクトリで起動するだけで接続されます1。追加設定は要りません。
Claude Desktop は設定ファイルへの追記が必要ですが、apcli install desktop というコマンドで登録できます。ChatGPT からつなぐ場合は、サーバーをHTTPモードで起動してHTTPSでアクセスできる場所に置き、コネクタとして登録する形になります。
AIを使わない選択肢もある
個人的に好感を持ったのがここです。
apcli というLLM不要のコマンドラインツールが同梱されています1。
apcli list # データセット一覧
apcli inspect procedures-survey-r6 # 構造・品質検査
apcli query procedures-survey-r6 -q 相続 --limit 5 # データ検索
apcli summarize procedures-survey-r6 -g 所管府省庁 -m count # 集計
「AIで分析できます」と言いながら、AI抜きでも同じことができる道を残している。 集計結果が正しいかを確かめたいとき、AIを介さずに直接叩ける手段があるのは重要です。
--html フラグで自己完結型のHTMLレポートも出せます。
設計の核心：AIに計算させない
ここが本題です。
何が問題なのか
生成AIにデータ分析をさせたことがある方なら、経験があると思います。表を渡して「合計を出して」と頼むと、それらしい数字が返ってくるけれど、検算すると合っていない。
LLMは言語のモデルであって、電卓ではありません。桁数が多い、行数が多い、条件が複雑になるほど、計算の信頼性は落ちます。 しかも困ったことに、間違っていても自信ありげに答えます。
7万5千件のデータをそのままAIに読ませて集計させたら、まず信用できません。
どう解いているか
デジタル庁の実装は、役割を分けています1。
サーバー側で集計を完結 — group-by・メトリクス・computed measures の計算をサーバー側で行い、AI に生データを渡して計算させることによる誤りを防ぎます
AIがやるのは「何をどう集計するか」を決めるところまで。 「所管府省庁でグループ化して、件数を数える」という条件の組み立てがAIの仕事で、実際の数え上げはサーバー側のプログラムが行います。
これは自然言語をクエリに翻訳させているだけとも言えます。翻訳ならLLMの得意分野です。計算は苦手分野なので、そこは従来型のプログラムに任せる。役割分担として、まっとうです。
データの「意味」を先に教えておく
もうひとつの工夫が dataset.yaml です。
データ定義（dataset.yaml）による意味の明示 — フィールドの役割・コードリスト・注意事項をサーバー側で定義し、AI が誤った補完・推測をしにくい構造にしています
たとえば「手続類型」という列に 1 2 3 という値が入っているとき、AIはそれが何を意味するのか知りません。 知らないまま、それらしく推測して答えることがあります。これがいわゆるハルシネーションの温床です。
dataset.yaml に「この列はこういう意味で、1は申請、2は届出」と書いておけば、推測する余地がなくなります。
**「AIが賢くなるのを待つ」のではなく、「AIが間違えようのない構造にする」**というアプローチです。
答えに出典と品質がついてくる
3つ目です。ツールの応答には次が付与されます1。
provenance（出典情報）notes（フィールドごとの注意事項）quality_summary（充填率などの品質情報）
「その数字はどこから来たのか」「その列には欠損がどれくらいあるのか」が、答えと一緒に返ってくる。
これが効くのは、データに穴があるときです。 ある列の充填率が3割しかないのに、その列で集計した結果を「事実」として提示されたら誤解します。品質情報が一緒に返れば、AIはそれを踏まえた説明ができます。
さらに、入力したフィールド名の表記揺れを自動補正した場合、補正内容を resolved_fields として応答に明示する仕組みもあります。「勝手に直したこと」を隠さない設計です。
何が嬉しいのか
整理します。
1. 前処理が要らない。 これまで行政データを分析するには、CSVをダウンロードして、Excelか何かで開いて、列の意味を調べて、集計する、という手順が必要でした。その全部が「聞くだけ」になります。
2. 探索が速い。 分析でいちばん時間がかかるのは、最初の「どこを見ればいいか分からない」段階です。思いついた切り口をすぐ試せるのは、単なる時短以上の意味があります。
3. 専門家でなくても触れる。 SQLもPythonも書けない人が、7万5千件のデータを自分で調べられる。行政データの利用者層が広がります。
4. 検算できる。 apcli があるので、AIの答えが怪しいと思ったら直接確認できます。
AIエージェントとの連携で何が変わるか
ここが、これからの話です。
単発の質問から、手順のある作業へ
チャットで1問1答するだけなら、正直、便利なだけです。面白くなるのは、AIエージェントに手順のある仕事を任せられるようになったときです。
たとえば Claude Code のようなエージェントは、複数のステップを自分で組み立てて実行できます。
- まずデータ構造を確認する
- 所管府省庁ごとに集計する
- オンライン未実施の割合が高い府省庁を特定する
- その中から具体的な手続を抽出する
- 結果をレポートにまとめてファイルに書き出す
これを一度の依頼でやらせられる、というのが従来との違いです。人間が各ステップでコピー&ペーストする必要がありません。
複数のデータソースをまたぐ
デジタル庁のMCP公開は、これが最初ではありません。 補助金電子申請システム「Jグランツ」のAPIをMCP化した jgrants-mcp-server が、先に公開されています3。
MCPが規格である意味は、ここで出てきます。 複数のMCPサーバーを同時につないでおけば、エージェントは横断して使えます。
- 行政手続のデータから、ある分野の手続の状況を調べる
- 同じ分野の補助金情報を別のサーバーから取る
- 法令データを別のサーバーから取る
個別に見ていたら気づかないことが、つなぐと見えてくる可能性があります。 政府のオープンデータが次々とMCP化されていけば、この方向は現実的になります。
ただし、過度な期待はしないほうがいい
冷静な部分も書いておきます。
現時点でMCP化されている政府データは、まだ限られています。そして今回のものは技術検証を目的としたサンプルであって、常時稼働するサービスではありません。自分のパソコンで動かす前提のものです。
READMEにも明記されています1。
このリポジトリは、公開データを使って MCP による検索・集計と MCP Apps の表示を試すための、ローカルまたは単一利用者向けの実験用サンプルです。複数利用者を収容する本番サービスや、基盤としての運用は対象としていません。
HTTPモードで外部公開する場合、利用者認証・認可・レート制限・監査ログは実装されていないため、認証と通信制限を備えたリバースプロキシを前段に置く必要があるとされています。そのまま社外に出せるものではありません。
免責事項も明確です。
本実装の出力は政府の公式見解ではありません
分析結果をそのまま資料に貼るのではなく、原典資料と突き合わせるという使い方が前提です。
企業が真似できること
この実装から学べることは、行政データを使うかどうかとは関係なく、けっこうあります。
社内データをAIに触らせようとしている企業は多いと思いますが、うまくいかない理由はだいたい共通しています。AIが列の意味を知らない、計算を間違える、根拠が示せない。今回の実装は、その3つに正面から答えています。
1. データの意味を、機械が読める形で書いておく。 dataset.yaml にあたるものです。列名だけ渡しても、AIは意味を推測するしかありません。「売上」が税抜なのか税込なのか、どの時点の数字なのか。人間なら暗黙に知っていることを、明文化しておく。 これがいちばん効きます。
2. 計算はAIにさせない。 AIには条件の組み立てまでをやらせて、集計は既存の仕組みで行う。「AIに全部やらせる」より確実で、しかも実装も楽です。
3. 答えに出典と品質を添える。 どのデータのどの時点か、欠損はどれくらいか。これがないと、答えを信じてよいのか判断できません。
私たちも社内データとAIをつなぐ相談を受けることがありますが、うまくいかないケースの多くは1番が抜けています。 データベースをそのままつないで「あとはAIがよしなに」と期待してしまう。AIは、書かれていないことは推測するしかありません。 推測させないための定義を先に作るほうが、結果的に早い。
使ってみるには
試すだけなら、それほど手間はかかりません1。
git clone https://github.com/digital-go-jp/administrative-procedures-mcp.git
cd administrative-procedures-mcp
./setup.sh
setup.sh が依存関係のインストールからデータ取得、接続方法の案内までを行います。Claude Code を使っているなら、このディレクトリで起動すればそのまま接続されます。
AIを使わずに中身だけ見たい場合は、apcli inspect procedures-survey-r6 から始めるのが分かりやすいと思います。
なおデータ取得については、READMEに注意書きがあります。 apcli fetch は同梱または内容を確認済みの dataset.yaml に対してのみ実行すること、出所不明のYAMLに対して実行しないこと。設定ファイルを信頼済みとして扱う設計なので、ここは守ってください。
まとめ
- デジタル庁が、行政手続等の棚卸調査結果約75,000件を自然言語で分析できるMCPサーバーを公開した
- ライセンスはMIT。ただし技術検証目的のサンプルコードで、保守や出力の正確性は保証されない
- Claude Code なら
.mcp.json同梱で設定不要 - 提供される道具は4つ。データセット一覧、構造検査、データ取得、グループ集計
- 設計の核心はAIに計算させないこと。AIは条件を組み立て、集計はサーバー側で完結する
dataset.yamlで項目の意味・コード値・注意事項を定義し、AIが推測する余地を減らしている- 応答に出典・注意事項・充填率が付き、根拠を示せる
- **LLM不要のCLI（
apcli）**も同梱され、検算ができる - エージェント連携では、手順のある作業の自動化と複数データソースの横断が現実味を持つ
- ただしローカル・単一利用者向けの実験用サンプルであり、本番運用の基盤ではない
「行政データがAIで分析できるようになりました」という見出しより、「AIに計算させない設計で公開された」ことのほうが、私には大きなニュースに見えました。
生成AIの実務利用でいちばん困るのは、それらしいが間違っている答えです。それを「AIの精度を上げる」ではなく「間違えようのない構造を用意する」で解こうとしている。この考え方は、行政データに限らず使えます。
自社のデータをAIに触らせようとして止まっている方は、このリポジトリの dataset.yaml を一度読んでみることをおすすめします。何を書いておけばAIが迷わないのかが、具体的に分かると思います。
Footnotes
-
デジタル庁「行政手続データ分析 MCP Server」（
digital-go-jp/administrative-procedures-mcp、MITライセンス）. https://github.com/digital-go-jp/administrative-procedures-mcp ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 -
デジタル庁「行政手続等の棚卸調査結果」（データ配布ページ）. https://www.digital.go.jp/resources/procedures-survey-results ↩
-
デジタル庁「jgrants-mcp-server」. https://github.com/digital-go-jp/jgrants-mcp-server ↩
