役所の手続は多い。それは誰もが体感で知っています。では、具体的に何件あって、そのうち何割がオンラインでできるのか。この問いに数字で答えられる人は、たぶんほとんどいません。
答えを持っているデータ自体は、実は数年前から公開されていました。デジタル庁が毎年公表している「行政手続等の棚卸調査結果」です。国の法令に基づく手続を悉皆（しっかい＝もれなく全部）調べ上げたもので、その数約75,000件。ただし、公開されている形はExcelファイル1本。14MBあり、開くだけでも身構えます。
2026年8月13日、デジタル庁がそのExcelをAIに話しかけて分析できる形にしたものをオープンソースで公開しました。MCP（Model Context Protocol）サーバーとして実装されており、Claude や ChatGPT のようなAIチャットにつなぐと、「相続に関係する手続を府省庁ごとに集計して」と日本語で頼めるようになります。
今回は実際に手元へ入れて、動かしてみました。結論から言うと、いちばん時間を使ったのは集計そのものではなく、自分が出した数字を疑い直す工程でした。その話は記事の中ほどに出てきます。
そもそも、何のデータなのか
「行政手続等の棚卸調査」は、国の法令等に基づく行政手続について、オンライン化の状況などを網羅的に調べたものです。今回対象になっているのは令和6年度調査（基準時点は令和6年3月31日、公表は令和7年7月）。
1レコードが1つの手続に対応し、38項目が記録されています。所管府省庁、根拠法令、手続類型といった基本情報に加えて、オンライン化の実施状況、未実施ならその懸念点、本人確認の手法、手数料の納付方法、年間の手続件数、さらには「その手続がどんなライフイベントで発生するか」「代理できる士業は何か」まで入っています。
つまり、これは単なる手続の一覧ではなく、日本の行政手続のカルテのようなものです。
導入は3コマンド
セットアップは驚くほど簡単でした。必要なのは Python 3.10 以上だけです。
git clone https://github.com/digital-go-jp/administrative-procedures-mcp.git
cd administrative-procedures-mcp
./setup.shsetup.sh が依存インストール・データ取得・接続方法の案内までまとめて面倒を見てくれます。手動でやる場合は次の2つです。
uv sync --extra excel # 依存パッケージの導入
apcli fetch procedures-survey-r6 # 調査データを配布元から取得ここで設計上のこだわりが1つあります。調査データはリポジトリに同梱されていません。公表後に修正が入ることがあるため、apcli fetch が実行時にデジタル庁の配布ページから最新版を取りに行く方式です。
[fetch] Dataset: procedures-survey-r6
Page: https://www.digital.go.jp/resources/procedures-survey-results
Asset: 20250729_procedures-survey-results_outline_02.xlsx
Saved: source-data/20250729_procedures-survey-results_outline_02.xlsx (14.0 MB)
[convert] Dataset: procedures-survey-r6
Records: 75071
CSV: 14317 KB → Parquet: 3203 KB
Ratio: 77.6% smaller75,071件。14MBのExcelが3MBのParquet（列指向の圧縮形式）に変換されました。git clone から集計を打てる状態になるまで、コマンドは本当に3つだけです。同梱のテストは205件あり、手元でもすべてパスしました。
取得日はきちんと記録されます。以降の集計結果には、必ずこの出典情報が付いてきます。
"provenance": {
"dataset_title": "行政手続等の棚卸調査結果",
"published_at": "2025-07-24",
"fetched_at": "2026-08-17",
"source_url": "https://www.digital.go.jp/resources/procedures-survey-results",
"publisher": "デジタル庁 (Digital Agency of Japan)"
}なお、外部ダウンロードが制限された環境（社内プロキシ配下など）では自動取得に失敗します。実は今回、最初に試したサンドボックス環境がまさにそれでした。その場合の逃げ道もちゃんと用意されていて、配布ページから手でExcelを保存して、こう打つだけです。
apcli add procedures-survey-r6 --csv 20250729_procedures-survey-results_outline_02.xlsxまずデータの「素性」を見る
このMCPサーバーが持つツールは4つだけです。データセットを探す list_datasets、構造と品質を調べる inspect_dataset。この2つが「発見層」。そして実際に検索する query_records、集計する summarize_records が「データ層」です。
面白いのは、AIにいきなり検索させず、まず inspect_dataset を呼ばせる構成になっていること。試しに実行すると、こんな画面が出ます。
▲ apcli inspect procedures-survey-r6 -o report.html の出力。レコード75,071件・フィールド39（38項目＋計算メトリクス1）。上部に「高カバレッジ8 / 中9 / 低21」と充填率の内訳が並び、各フィールドが「識別子・分析軸・数値項目・属性」に分類されて表示される。
注目したいのは充填率（fill_rate）の表示です。たとえば「経由機関」の充填率は3.4%。つまりこの項目はほとんど空欄で、これで集計しても意味のある結果にはなりません。低カバレッジのフィールドが38項目中21項目（55%）ある、という事実がひと目で分かります。
AIに生データを渡すと、こういう「そもそも集計に耐えない項目」でも平気で集計して、それらしい数字を返してきます。先に品質情報を見せることで、その手のハルシネーションを構造的に減らす。これがこの実装の思想の中心にあります。
聞いてみる：オンライン化はどこまで進んだのか
では本題です。約75,000件のうち、オンラインでできる手続はどれくらいあるのでしょうか。
▲ apcli summarize procedures-survey-r6 -g オンライン化の実施状況 -m count の結果。円グラフ・棒グラフ・ツリーマップ・テーブルを切り替えられ、下部に出典と注意書きが自動で付く。
| オンライン化の実施状況 | 件数 | 割合 |
|---|---|---|
| 1 実施済 | 36,315 | 48.4% |
| 2 未実施 | 22,695 | 30.2% |
| 4 その他 | 13,235 | 17.6% |
| 5 一部実施済 | 2,416 | 3.2% |
| 3 適用除外 | 407 | 0.5% |
「実施済」がほぼ半分。ただし手続の種類の数と実際に使われる回数はまったく別の話です。年間の手続件数（令和5年度）を足し上げると、実施済の手続で約36.8億件、未実施の手続で約2.3億件。件数ベースで見れば、実務のボリュームゾーンはすでにオンライン側にある、という景色になります。
ここで感心したのは、この集計を実行すると応答に注意書きが自動で付いてくることです。
"notes": {
"総手続件数": [
"件数は有効数字2桁以上の概数であり、一部試算値を含む。",
"地方等が実施する手続はサンプル自治体からの試算値を含む。"
]
}さらに、合計値と一緒に「集計から除外した欠損レコード数」も返ってきます。36.8億件という数字を、注釈なしで一人歩きさせないための仕掛けです。AIに答えさせるとき、この注記がそのまま回答に乗ることになります。
府省庁ごとに見ると、差がはっきり出る
次は所管府省庁別です。件数と、あわせて「オンライン率」も出してみます。
▲ apcli summarize procedures-survey-r6 -g 所管府省庁 -m count -m avg:オンライン率 の結果。中央に総数75,071が表示される。国土交通省が18.18%で最多。
| 所管府省庁 | 手続数 | オンライン率 |
|---|---|---|
| 国土交通省 | 13,645 | 37.8% |
| 厚生労働省 | 10,504 | 40.8% |
| 経済産業省 | 8,577 | 65.8% |
| 農林水産省 | 8,526 | 56.2% |
| 財務省 | 7,003 | 49.9% |
| 金融庁 | 6,112 | 74.1% |
| 総務省 | 6,023 | 43.1% |
| 環境省 | 4,054 | 51.0% |
| 国家公安委員会・警察庁 | 2,010 | 9.8% |
| 内閣府 | 1,755 | 53.7% |
手続数の上位2つ（国土交通省・厚生労働省）が、いずれもオンライン率は4割前後。一方で金融庁は74.1%、経済産業省は65.8%と高い。逆に警察庁は9.8%と極端に低い。
「オンライン率」は元データにある項目ではなく、サーバー側で定義された計算メトリクスです。定義ファイルにこう書かれています。
computed_measures:
- name: オンライン率
mode: count_where
condition_field: オンライン化の実施状況
condition_values: ["1 実施済"]
desc: オンライン化実施済の手続種類数 / 全手続種類数AIに「オンライン率を計算して」と頼むと、普通なら生データを読ませて自分で割り算させることになります。それをやめて、割り算の定義自体をサーバーに置いた。分母を何にするかという解釈のブレも、計算間違いも、これで消えます。
……と、ここまでは順調でした。この表を記事に載せるつもりで、念のためもう一段掘ったところで、話がおかしくなります。
掘り下げたら、自分の集計が間違っていた
「省庁ごとの差は、手続の性質の違いで説明できるのでは」と考えました。警察や国交省には、対面や現物確認が前提の手続が多いはずです。それなら手続類型を「申請等」だけに絞れば、条件が揃って比較できる。そう思って、フィルタを足しました。
apcli summarize procedures-survey-r6 -g 所管府省庁 -m count -m avg:オンライン率 \
-w '{"手続類型":"1 申請等"}'国土交通省 8,629件。……多い。全13,645件のうち6割以上が「申請等」ということになります。
念のため、フィルタを使わずに軸を2つ重ねるクロス集計でも同じものを出してみました。このサーバーは -g を並べるだけで多軸集計ができます。
apcli summarize procedures-survey-r6 -g 所管府省庁 -g 手続類型 -m countこちらでは国土交通省 × 「1 申請等」は 6,512件。2,117件も食い違います。
原因はすぐ分かりました。この2,117件は、国土交通省の「2-1 申請等に基づく処分通知等」の件数とぴったり一致します。つまりフィルタの "1 申請等" が、"2-1 申請等に基づく処分通知等" という別のコードにも引っかかっていたわけです。「2-1 申請等に基づく〜」という文字列の中に、探している文字列がそのまま含まれているからです。
これは不具合ではありません。READMEにもツール定義にも「文字列＝部分一致」と明記された仕様です。完全一致させたいなら演算子を明示します。
-w '{"手続類型":{"$eq":"1 申請等"}}'やり直したら国土交通省 6,512件。クロス集計と一致しました。
厄介なのは、エラーが1つも出ないことです。フィルタは正常に動き、それらしい表が返ってくる。クロス集計という別ルートで検算しなければ、そのまま記事に載せていました。しかもこの罠は、コードリストの値が「1 申請等」「2-1 申請等に基づく処分通知等」のように入れ子になっているデータでだけ発火します。人間がやっても、AIに任せても、同じように踏みます。
念のため、この記事で使った他の絞り込み（"2 未実施"、"死亡・相続"）も同じやり方で検算しました。こちらは他のコードと文字列が重ならないため、結果は変わっていません。
便利な省略記法があるデータ分析ツールでは、絞り込んだ後の件数を必ず別ルートで検算する。 今回いちばん高くついた教訓がこれでした。
で、揃えて比べたらどうだったのか
正しい値で並べ直します。同じ府省庁を、全手続で見た場合と、「申請等」だけに揃えた場合で比較したものです。
| 所管府省庁 | 全手続のオンライン率 | 「申請等」のみ | 差 |
|---|---|---|---|
| 経済産業省 | 65.8% | 85.0% | +19.2 |
| 財務省 | 49.9% | 66.6% | +16.7 |
| 金融庁 | 74.1% | 90.2% | +16.1 |
| 総務省 | 43.1% | 58.3% | +15.2 |
| 厚生労働省 | 40.8% | 55.0% | +14.2 |
| 農林水産省 | 56.2% | 69.6% | +13.4 |
| 環境省 | 51.0% | 63.6% | +12.6 |
| 国土交通省 | 37.8% | 48.0% | +10.2 |
| 国家公安委員会・警察庁 | 9.8% | 10.1% | +0.3 |
条件を揃えると、ほとんどの省庁でオンライン率が10〜19ポイント上がります。これは類型別の集計を見ると理由がはっきりします。
| 手続類型 | 手続数 | オンライン率 |
|---|---|---|
| 1 申請等 | 36,480 | 62.3% |
| 2-1 申請等に基づく処分通知等 | 12,607 | 39.4% |
| 2-2 申請等に基づかない処分通知等 | 15,533 | 30.9% |
| 3 縦覧等 | 3,194 | 44.7% |
| 4 作成・保存等 | 5,028 | 36.1% |
| 2-3 交付等（民間手続） | 2,227 | 25.5% |
国民が窓口に出す「申請等」は6割超がオンライン化されている一方、役所から出す通知や交付の側が3割前後で止まっています。府省庁別のオンライン率の差には、抱えている手続の構成比の違いがかなり混ざっているということです。省庁の熱心さの順位表として読むのは、そもそも無理があります。
そのうえで面白いのは、この補正をかけても警察庁だけがほとんど動かない（9.8% → 10.1%）ことです。他省庁が10ポイント以上動く補正が効かない。つまりここは手続の構成の問題ではなく、申請等そのものがオンライン化されていない。免許や許可の対面確認が効いていると考えるのが自然ですが、いずれにせよ「構成比のせいではない」ところまでは数字で言えます。
なお、この記事で扱っている集計はすべて手続の種類の数です。1件あたりの利用回数は反映されていません。
ライフイベントで横断してみる
このデータセットで個人的にいちばん面白かったのが、「その手続がどのライフイベントで発生するか」という項目です。集計するとこうなりました。
| ライフイベント（個人） | 手続数 |
|---|---|
| 税金 | 2,540 |
| 死亡・相続 | 1,460 |
| 医療・健康 | 1,449 |
| 引越し | 785 |
| 就職・転職 | 754 |
| 介護 | 522 |
| 結婚・離婚 | 517 |
| 出生・こども | 509 |
| 年金の受給 | 451 |
| 住宅の購入・保有 | 343 |
（この項目は複数選択できるため、1つの手続が複数のイベントに数えられます。また上位には「その他(個人にも法人にもあてはまらない)」21,962件と「その他イベント(個人)」8,328件が入りますが、中身が分からないため表からは外しました。）
死亡・相続に1,460件。これを府省庁別に割ると、関わる省庁は18にまたがります。厚生労働省341件、財務省252件、国土交通省180件……。相続の手続が大変だという実感には、ちゃんと構造的な裏付けがあったわけです。しかも法務省所管分のオンライン率は18.6%、警察庁所管分は7.4%と、よりによって低い。
引越しなら785件・18府省庁。「窓口をひとつに」という話が簡単に進まない理由が、数字で見えてきます。
代理を頼める士業の分布も出ます。弁護士3,614件、行政書士3,342件、税理士1,594件、社会保険労務士911件。一方で「士業が介在しない」が26,669件と圧倒的多数で、大半の手続は自分でやるものだ、という当たり前の事実も確認できます。
未実施の理由を聞いてみる
「オンライン化していない22,695件は、なぜやらないのか」も聞けます。
| 懸念点 | 件数 |
|---|---|
| 6 オンライン化の費用対効果が小さい又は不明 | 10,360 |
| 0 オンライン化実施予定 | 3,879 |
| 5 性質上、電子化すべきでない | 2,800 |
| 7 上記に該当しない | 2,661 |
| 3 電子化に必要なシステムが省庁内に備わっていない | 1,181 |
| 4 一部の必要書類の原本が紙であり、電子化してもオンライン処理が完結しない | 1,068 |
| 1 制度改正が必要であり、時間確保が困難 | 433 |
| 2 制度改正が必要であり、優先順位が高くない | 342 |
圧倒的な1位が「費用対効果が小さい又は不明」の10,360件。制度改正の壁（合計775件）より、費用対効果の壁のほうが一桁大きい。年に数件しか使われない手続を個別にシステム化しても割に合わない、という現場判断が透けて見えます。裏を返せば、共通基盤で一括して面倒を見る方向に効き目がありそうだ、という示唆にもなります。
支払い方法の内訳も見られます。ただしこの項目は充填率4.9%、つまり回答があるのは全体の5%弱しかありません。母数の小ささを承知のうえで並べると、オフラインでは「行政機関の窓口」1,794件が突出し、オンライン側はペイジー（ネットバンキング）805件、クレジットカード払い477件、二次元コード決済92件。先ほどの inspect_dataset を見ていなければ、これを「日本の行政手数料の決済手段の分布」として書いてしまうところでした。
申請書に何を書かせるかの集計も、示唆があります。「商号又は名称」15,179件、「本店又は主たる事務所の所在地」13,218件に対して、「法人番号」は2,093件。名称と住所は書かせるのに、それらを一意に引ける番号を求める手続は1割強しかない、という構図です（マイナンバーは1,159件）。
AIに優しい、とはどういうことか
ここまで触って、「AI-ready なデータとはこういうことか」と腑に落ちた点が3つありました。
1. 間違えたときの返し方がうまい。 存在しないフィールド名を投げてみます。
apcli summarize procedures-survey-r6 -g 府省庁 -m count返ってきたのはこれです。
{
"error": "不明なfield: '府省庁'",
"maybe_fields": ["所管府省庁", "実施府省庁"],
"available_fields_total": 38,
"hint_detail": "inspect_dataset を呼び出すと、フィールド定義や利用方法を確認できます。"
}単に「エラー」で突き放さず、候補と次の一手を返す。集計後フィルタ（having）で演算子を書き間違えたときも同じでした。使える演算子の一覧に加えて、「having のキーには返却列名をそのまま使う」という説明と、いま指定可能な列名（count と avg:オンライン率）まで返ってきます。エラーメッセージが仕様書を兼ねているので、ドキュメントを読み直さずに直せます。
2. 軽い表記ゆれは黙って吸収する。 オンライン化実施状況（「の」が抜けている）で叩くと、ちゃんと オンライン化の実施状況 として処理され、応答に補正の記録が付きます。
"resolved_fields": {"オンライン化実施状況": "オンライン化の実施状況"}直せるものは直し、直せないものは候補を出して止まる。 この線引きが明確です。ただし前述のとおり、値の側の部分一致だけは黙って通るので、そこは使う側が気をつけることになります。
3. 応答がトークンを食わない。 検索結果は {"columns": [...], "rows": [[...], [...]]} という列指向で返ります。同じ50件を辞書の配列にした場合と比べてみました。全31列を取ると 70,616バイト → 27,519バイトで61.0%減。5列に絞った場合は43.2%減でした。フィールド名が毎行繰り返されないぶんの差なので、列が多いほど効きます。LLMに渡す前提の設計だと分かります。
ブラウザだけで、AIサービスなしで動かす
Claude Desktop への登録はワンコマンド（apcli install desktop）、Claude Code はリポジトリに .mcp.json が入っているのでそのディレクトリで作業を始めれば設定なしでつながります。ChatGPT はHTTPモードで起動してコネクタ登録する形です。
ただ、いちばん驚いたのはチャットツールを一切使わないモードでした。
apcli preview --port 8765これは Chrome に内蔵されたAI（Prompt API / Gemini Nano）を使って、外部のAIサービスを一切使わずローカルだけで対話するプレビューホストです。最初にサンドボックスのヘッドレスChromiumで試したときは内蔵AIが無く、動きませんでした。そのときの案内画面がこれです。
▲ 内蔵AIが使えない環境で出る案内。「Chrome 138以降」「このフラグをEnabledに」「空きストレージ22GB / VRAM 4GB超が目安」と、条件と手順が具体的に並ぶ。
そこで改めて、手元のMac（Chrome 151）の実ブラウザで開き直しました。フラグ設定もモデルの手動ダウンロードもなしで、そのまま動きました。（LanguageModel.availability() が "available" を返す状態でした。この機能はChromeのバージョンとマシン要件に依存するので、環境によっては上の案内画面が出ます。）
「所管府省庁ごとの手続件数を多い順に教えてください」と日本語で入力すると、まず inspect_dataset が走り、続いて summarize_records が呼ばれ、グラフが描かれました。
▲ ブラウザ内蔵AIが自分でツールを選び、集計まで到達したところ。中央に総数75,071。表示形式は円グラフ・棒グラフ・ツリーマップ・テーブルを切り替えられる。
途中が面白かったので書いておきます。内蔵AIは小型モデルなので、summarize_records を呼ぶときに必須の dataset_id を落としました。当然エラーになります。ところが画面には「エラーのため引数の修正を促しました」と出て、そのまま自力で引数を組み直し、2回目で成功しました。前の章で書いた「エラーメッセージが仕様書を兼ねている」設計が、そのまま自己修復として効いている場面です。
出てきた答えがこれです。
▲ 集計結果の下に出典・公表者・原典URL・注意書きが自動で付く。その下が内蔵AIの日本語回答。
所管府省庁ごとの件数が多い順は、国土交通省 (13,645件)、厚生労働省 (10,504件)、経済産業省 (8,577件)、農林水産省 (8,526件)、財務省 (7,003件)、金融庁 (6,112件)、総務省 (6,023件) です。
コマンドラインで実行した値と完全に一致しています。数字を作っているのはサーバー側で、AIは日本語に直しているだけなので当然ではあるのですが、この「当然」を成立させることこそが設計の狙いです。回答の下には「次の一手」として「所管府省庁と手続類型のクロス集計をして」といった候補まで並びます。
外部にデータを送らず、APIキーも要らず、ブラウザだけで行政データの自然言語分析が完結する。役所や自治体の中で「試すこと自体の稟議が要る」場面を考えると、この構成の価値は小さくないと感じました。
なおグラフ表示には Apache ECharts、配色にはデジタル庁デザインシステムのデザイントークンが使われています。集計結果の画面がやたら整って見えるのは、そのおかげです。
注意しておきたいこと
良いことを多く書いてきましたが、公式に明記されている注意点は押さえておく必要があります。
これは技術検証目的のサンプルコードであり、動作の安定性も継続的な保守も保証されていません。搭載データの正確性・最新性についても同様です。出力は政府の公式見解ではなく、データはあくまで調査時点（令和6年3月31日）の各府省庁の回答にもとづく集計です。業務や対外資料で数字を使うなら、原典資料の確認が必須になります。
もう一点、これはツールの限界ではなくデータの性質ですが、38項目のうち21項目は充填率が低めです。「集計はできたが母数が小さすぎて意味がない」というケースは普通に起こります。手数料の納付方法（充填率4.9%）がまさにそれでした。だからこそ inspect_dataset を先に見る設計になっている、とも言えます。
セキュリティ面では、外部に公開して運用する場合はリバースプロキシで認証とレート制限をかけること、dataset.yaml は信頼できるものだけを使うこと、が案内されています。
まとめ──「公開した」と「使える」の間にあるもの
このリポジトリの意味は、行政データの分析ツールが1つ増えたこと以上に、「オープンデータをAI時代にどう出すか」の実例を示したところにあると思います。
Excelで公開する、はデータを出したことにはなります。でも、それだけでは使われません。今回の実装が足したのは、こういう層です。
- 意味を書く（
dataset.yamlに各項目の説明とコードリストを定義する） - 品質を先に見せる（充填率を返し、使えない項目を分からせる）
- 計算はサーバーでやる（LLMに数え上げをさせない）
- 出典を必ず付ける（回答の根拠を追える形で返す）
- 間違いには道を示す（候補と次の一手を返す）
どれも派手ではありません。しかし「AIに読ませる前提でデータを公開する」というのが具体的に何を指すのかを、これほど分かりやすく実物で示した例は、日本の行政まわりではまだ少ないはずです。しかもライセンスはMIT、dataset.yaml を1枚足すだけで別のデータセットにも拡張できる作りになっています。手元のCSVを apcli add で取り込めば、同じ仕組みが自社データにもそのまま使えます。
そのうえで、今回いちばん持ち帰りたくなったのは道具の話ではありませんでした。これだけ丁寧に作られた道具を使っても、集計を間違えるときは静かに間違える。部分一致のフィルタは、エラーも警告も出さずに1割増しの母数を返してきました。気づけたのは、たまたま別ルートで同じ数字を出したからです。
AIに分析させる時代に本当に必要なのは、たぶん「聞けば答えてくれること」ではなく、答えを別ルートで検算する癖のほうです。良い道具は、その検算を安く済ませてくれます。今回でいえば、クロス集計のコマンドを1本足すだけで済みました。
「うちのデータもAIで分析できるようにしたい」と考えている組織にとって、これはそのまま真似できる教科書として読めるのではないでしょうか。
本記事は、デジタル庁Techブログの記事「⾏政⼿続等調査データ（約75,000件）をMCPで⾃然⾔語分析可能に」（2026年8月13日、土岐竜一氏）、GitHubリポジトリ digital-go-jp/administrative-procedures-mcp（検証時のコミット 8d10433）のREADMEおよび dataset.yaml、ならびにデジタル庁「行政手続等の棚卸調査結果」（令和6年度調査、令和7年7月29日公表）をもとに、実際に環境を構築して検証した内容を整理したものです。記事中の集計値はすべて筆者が同ツールで実行した結果ですが、元データは調査時点の回答にもとづく概数であり、一部試算値を含みます。正確な情報は原典資料をご確認ください。本実装は技術検証目的のサンプルコードであり、出力は政府の公式見解ではありません。
