行政手続75,071件をMCPに載せた。意味定義が効く場所と、効かない場所

デジタル庁が2026年8月13日に、行政手続等の棚卸調査データ約75,000件をMCPで自然言語分析できるようにした技術検証の記事を公開した。生データをそのままLLMに渡すのではなく、項目の意味と品質情報をサーバ側に持たせ、集計もサーバ側で完結させる。誤読を減らす設計として、まっとうな筋だと思う。

同じデータを政策DBのホスト型MCPにも載せた。https://seisakudb.jp/mcpにつなげば、ClaudeやChatGPTから直接引ける。デジタル庁の実装はローカル・単一利用者向けのサンプルとして配布されているので、こちらは公開ホスト型としての別の到達経路にあたる。先行実装の代わりではない。

取り込み自体は半日で終わった。書くに値するのはそこではなく、途中で踏んだ落とし穴のほうだ。「意味定義をサーバ側に置く」という設計がどこで効いて、どこで足りなくなるかがはっきりした。実測値と一緒に記録しておく。

載せたデータ

行政手続等の棚卸調査結果(令和6年度悉皆調査)。国の法令に基づく行政手続を全数調べたもので、75,071件×38列。所管府省庁、手続類型、オンライン化の実施状況、年間件数、ライフイベント、代理できる士業、添付書類、処理期間などが入っている。調査時点は令和6年3月31日で、件数は令和5年度の実績。配布形式は14.7MBのExcelで、ヘッダが2行ある。

これは手続の棚卸調査であって、個別の申請記録でも予算でもない。ここを取り違えると全部おかしくなるので、MCPのツール説明にも最初に書いた。

意味定義が効いた3か所

1. 区切り文字を間違えると1つの値が2つに割れる

複数値を持つ列が11ある。区切りはセミコロンだ。読点で割ってはいけない。

「3 一部電子、一部原紙での提出」
「1 制度改正が必要であり、制度改正のための時間確保が困難」

これらはコードリスト上の1つの値で、読点は値の内側にある。読点で分割すると「3 一部電子」「一部原紙での提出」という存在しない2値が生まれ、集計すると母数が水増しされる。しかも壊れ方が静かで、エラーは1つも出ない。

デジタル庁の定義ファイルにはコードリストが値の完全形で書いてあるので、突合すれば気づける。手元で目視して「たぶん読点区切りだろう」と決めていたら踏んでいた。

2. 0とnullは別物で、しかもnullのほうが多い

年間件数の列は3つある。ここで空文字を0に変換すると、「件数が不明」が「ゼロ件」に化ける。定義ファイルにはこう書かれている。

null(欠損)は「件数不明」を意味する。0は基本的に「オンライン手続なし」だが、地方等で件数集計が困難な一部の手続では0と記録されている場合がある。

実測すると、これは注意書きの域を超えている。

過半が不明で、その次に多いのが0だ。ここを潰すと、データの86%が「オンライン手続ゼロ件」という嘘の姿になる。ETL側で空文字を0にすることを禁止し、テストで固定した。

3. コードだけ見るとラベルの入れ替わりを検知できない

分類列は「1 実施済」「2 未実施」のようにコードとラベルが連結されている。先頭のコードだけ切り出して検証すると、将来の改訂で「1 未実施」のような入れ替わりが起きても素通りする。コードの集合は変わらないからだ。ラベル込みの完全な値でコードリストと突合するようにした。

意味定義があっても決まらないもの

ここからが本題になる。率の分母は、列の意味定義には書けない。

このデータで「オンライン率」を出すとき、少なくとも2つの計算があり得る。

• 種類数ベース: オンライン化実施済の手続種類数÷全手続種類数。実測48.4%(36,315÷75,071)
• 件数ベース: オンライン手続件数÷総手続件数

デジタル庁の定義ファイルは種類数ベースで定義している。妥当な判断だと思う。件数ベースは、そもそも計算できないからだ。上で見たとおり件数の56.1%が欠測で、しかも欠測の偏りが府省庁ごとにまるで違う。

件数の判明率が28.6%の役所と82.5%の役所を、件数ベースの率で並べても比較にならない。それでも数字は出てしまう。出てしまうから、誰かが並べる。

だから政策DBの集計ツールでは、件数ベースの率を返さないことにした。件数の合計は返す。種類数ベースの率も返す。しかし両者を割った値は、引数を用意していない。APIが出せる形にしておくと必ず誰かが割るし、割った瞬間に数字は静かに間違う。応答には毎回metric_basisを入れて、その数字が何を数えているのかを明示している。

これはツールを作る側の判断であって、列の意味定義には書けない層だ。「この列はこういう意味です」を100%正しく書いても、「この列とこの列を割ってよいか」は決まらない。

列単位の意味定義では届かない層

行政手続のデータは、幸いなことに1列1意味で足りている。列にコードリストと注意書きを付ければ、意味定義としてはほぼ完成する。

政策のお金のデータになると、そこが崩れる。

政策DBの本体は、国の補助金や公共調達が「どの法人にいくら渡ったか」を扱っている。ここには交付額という列がある。値は金額だ。単位も定義も1つしかない。ところが同じ列の同じ金額でも、行によって意味が違う。

• その企業が事業主体として受け取った額
• その企業が事務局として通過させただけの額(給付金の事務局を請け負い、最終的な受給者に配るもの)

列にコードリストを書いても、この区別は表現できない。行ごとに違うからだ。政策DBではfunding_roleという分類を1行ずつ持たせ、判定の確からしさと根拠も一緒に保持している。

これが実務上どれくらい効くか。上場企業に名寄せした明細31,144件(2015年3月〜2026年5月)で実測すると、こうなる。

残り38件は分類保留。金額が入っていないため金額比には影響しない。

件数の1割強が、金額の54.0%を占めている。この分類を持たずに企業ごとに素直に合計すると、集計そのものは正しいのに「その企業が受け取った額」として一桁近く違う像が出る。SQLは1行も間違っていない。間違うのは結論だけだ。

列に書けない意味は、行に持たせるしかない。データの種類が変われば、意味定義に必要な粒度も変わる。

権利処理は2系統ある

実務メモとして書いておく。公的データを再配信するとき、権利処理はデータ本体と意味定義で別々に要る。混ぜると片方が抜ける。

データ本体は公共データ利用規約(第1.0版)が適用される。要件は3つで、①出典を書く ②編集・加工した場合は、出典とは別に「加工したこと」と「加工した主体」を書く ③加工した情報を、国や府省が作った未加工のものであるかのように見せない。②を落としている再配信をよく見かける。

意味定義のほうは、デジタル庁の実装リポジトリがMITで公開しているものを参照している。MITは著作権表示と許諾表示の同梱が条件だ。項目説明や注意書きをAPI応答で返すこと自体がその文言の再配布にあたるので、応答側にも出所とライセンスを載せ、第三者ライセンス表示から全文に到達できるようにした。

この2つを、文章としてページに書くだけでなく機械可読なフィールドとして応答に埋めている。人間が読むページにしか書いていないと、APIを使う側が再配信するときに落ちる。落ちた責任はこちらにも回ってくる。

使い方

MCPツールを2本追加した。

• search_admin_procedures: 府省庁、手続類型、オンライン化状況、ライフイベント、士業、法令名、手続名で検索する
• get_admin_procedure_stats: 同じ条件でサーバ側集計する。集計はBigQuery側で完結させ、LLMには条件の指定だけを担わせる

接続すると、たとえばこういう質問が通る。

• 「死亡・相続に関する手続のうち、オンライン未実施のものを所管府省庁別に出して」
• 「行政書士が代理できる手続はどの省庁に多い?」
• 「府省庁別のオンライン化率を、種類数ベースで」

接続方法はClaude・ChatGPTで政策DBを使う(MCP接続)に書いた。APIキーはseisakudb.jp/developersから無料で発行できる。

次にやること

今回は繋がなかったが、価値がありそうな組み合わせが2つある。

1つは法令名から政策DBの法令データ(9,514件)への名寄せ。手続の根拠法令と、その法令の改正履歴や国会での議論を繋げられる。もう1つは所管府省庁と行政事業レビュー予算のクロス。手続のオンライン化状況と、その省庁がデジタル化に使っている予算を並べて見られる。

どちらも名寄せの精度検証が別途要るので、今回は入れていない。精度を確かめずに繋ぐと、上に書いた「SQLは正しいのに結論が間違う」を自分でやることになる。

出典:「行政手続等の棚卸調査結果(令和6年度悉皆調査)」(デジタル庁)(https://www.digital.go.jp/resources/procedures-survey-results)を加工して作成。加工者: カボシア株式会社(政策DB)。加工内容は列の型付け、コード値の切り出し、複数値列の配列化、品質指標の付与で、数値そのものの改変・補完・推計はしていない。意味定義はdigital-go-jp/administrative-procedures-mcp(MIT, Copyright (c) 2026 Digital Agency, Government of Japan)を参照している。政策DBはカボシア株式会社が独立して提供するサービスであり、デジタル庁その他の政府機関の公式サービスではない。政府・省庁による推奨・監修・提携を示すものでもない。本文中の数値は2026年8月15日時点の実測値。