行政データは「公開する」から「AIが正しく使える」へ――デジタル庁のMCP実証をどう読むか

本記事は、2026年8月15日時点で公開されている資料に基づき、株式会社civichubが独自に解説・考察したものです。デジタル庁その他の機関による監修・承認を受けたものではなく、各機関の公式見解を代弁するものではありません。

2026年8月13日、デジタル庁Techブログにおいて、行政手続等の調査データ約75,000件を、MCP（Model Context Protocol）を通じて自然言語で検索・集計できる技術検証が紹介されました。

対象となっているのは、デジタル庁が公表する「行政手続等の悉皆調査結果」です。配布ページでは「令和6年度調査（令和6年3月31日時点）」として掲載され、最終更新日は2025年7月29日となっています。今回の実装では、この公開データを取得し、行政手続の所管府省庁、手続類型、根拠法令、オンライン化状況、関連するライフイベントなどを自然言語から検索・集計できるようにしています。

最初に明確にしておくべきなのは、今回公開されたものは、行政手続を案内する新しい政府サービスではないという点です。

公開されたGitHubリポジトリには、技術検証を目的とするサンプルコードであり、基本的にローカル環境または単一利用者による試用を想定していることが記載されています。複数利用者が利用する本番サービスとしての運用、継続的な保守、データの正確性や最新性は保証されておらず、出力も政府の公式見解ではありません。

この前提を踏まえた上で、今回の実証には、今後の公共データと生成AIの関係を考える上で重要な示唆が含まれています。

今回公開された仕組みは何が新しいのか

約75,000件のデータをAIに読み込ませると聞くと、巨大なCSVファイルをLLMへ直接渡し、回答を生成させる仕組みを想像するかもしれません。

しかし、今回の実装はそのような構成ではありません。

処理の流れを簡略化すると、次のようになります。

利用者の質問
→ LLMが検索・集計条件を組み立てる
→ MCPサーバーがデータを検索・計算する
→ 出典、注意事項、品質情報とともに結果を返す

LLMが担うのは、利用者の自然言語を理解し、「どの項目を検索するか」「何を条件に絞り込むか」「どの単位で集計するか」を指定する部分です。

実際の検索や集計はMCPサーバー側で実行されます。公開された実装では、データセットを発見するlist_datasets、構造や品質を確認するinspect_dataset、レコードを検索するquery_records、集計するsummarize_recordsという4つのツールが用意されています。

つまり、この実装におけるLLMは、約75,000件のデータを暗算する「計算機」ではなく、利用者の要求を構造化された処理へ変換する「操作役」に近い位置付けです。

計算処理をLLMの自由回答に委ねず、サーバー側に定義されたロジックで実行することで、算術ミスや集計条件の誤用を抑え、同じ条件に対して再現性のある結果を返しやすくなります。

ただし、これによって誤りが完全になくなるわけではありません。元データ、項目定義、集計ロジック、LLMによる条件指定のいずれかに問題があれば、結果にも影響します。正確には、誤りを「なくす仕組み」ではなく、誤りが生じる範囲を限定し、検証しやすくする仕組みと捉えるべきでしょう。

本質はMCPへの接続ではなく、データの意味をAIに伝えたこと

今回の実証で特に重要なのは、MCPを利用したことだけではありません。

公開データに含まれる項目の意味、使用可能な値、欠損値の扱い、計算方法などを、AIが理解できる形で別途定義している点です。

例えば、ある項目が分析上の分類軸なのか、数値として集計する項目なのか、どのようなコード値を取り得るのかをdataset.yamlに記載しています。また、欠損値が単なるゼロではなく「件数不明」を意味する場合には、その注意事項も結果へ付与します。

オンライン化率のような指標についても、LLMが回答のたびに独自の方法で計算するのではなく、サーバー側に計算方法を定義しています。さらに、各項目の充填率や数値分布などの品質情報も取得できるようにしています。

これは、企業のデータ基盤でいう「セマンティックレイヤー」や「データ可観測性」に近い考え方です。

データを公開していても、次のような情報がなければ、AIは適切に利用できません。

• 項目が何を意味するのか
• どの時点のデータなのか
• どのような条件で収集されたのか
• 欠損値は「ゼロ」なのか「不明」なのか
• 数値は単純平均すべきか、加重平均すべきか
• どの組織が作成し、誰が管理しているのか
• どのような利用条件が適用されるのか

英国政府が2026年に公開した政府データのAI-ready化に関するガイドラインでも、AIに適したデータは、単に機械判読可能な形式であるだけでは不十分とされています。同ガイドラインは、技術的な最適化、データとメタデータの品質、組織・インフラ上の管理体制、法務・セキュリティ・倫理という4つの観点を示しています。データの来歴、更新履歴、品質上の問題、ライセンス、責任主体などを含めて管理する必要があるという考え方です。

元のデジタル庁Techブログも、今回の実装がAI-readyなデータ基盤全体を完成させるものではなく、意味定義と品質情報の提供という一要素を扱ったものであると明記しています。出典・来歴、バージョン管理、ライセンス、ガバナンスなどは、別途整備が必要です。

この点は非常に重要です。

MCPサーバーを用意することと、信頼できるAI向けデータ基盤を構築することは同義ではありません。

MCPはデータや機能への接続方法を標準化しますが、その中で提供されるデータの正しさや、組織としての責任体制まで自動的に保証するものではないからです。

Web、APIに続く「AIのための入口」

これまで公共データには、主に二つの入口がありました。

一つは、人がブラウザから閲覧するWebサイトやダッシュボードです。もう一つは、システムやアプリケーションが利用するAPIやファイルです。

MCPは、これらに代わるものというより、AIやAIエージェントが利用する第三の入口として位置付けると分かりやすいでしょう。

米国政府出版局のGovInfoは、2026年1月にMCPサーバーのパブリックプレビューを発表した際、同一の基礎データに対して、Web UIは人間、APIはプログラム、MCPはLLMやAIがアクセスするインターフェースであると整理しています。

この整理からも分かるように、MCPが普及したとしても、Webサイトや従来のAPIが不要になるわけではありません。

人が確認するためのWebページ、アプリケーションが安定的に利用するAPI、自然言語で探索や操作を行うAI向けインターフェースは、それぞれ異なる役割を持ちます。

MCPの意義は、既存のデータやAPIを廃止することではなく、それらの上にAI向けの接続層を追加しやすくすることにあります。

MCPは、AIアプリケーションと外部のデータ、ツール、業務フローを接続するオープンな仕様です。2025年12月にはLinux Foundation傘下のAgentic AI Foundationへプロジェクトとして提供され、2026年7月28日版の仕様では、通常のHTTP基盤で運用しやすくするステートレス化や拡張仕様の整理なども進められました。特定のAI事業者だけが使用する独自機能ではなく、複数のAIサービスや開発環境から利用できる共通の接続層を目指す動きが進んでいます。

自然言語で検索できても、それだけで行政案内にはならない

今回の仕組みによって、専門的なデータ項目や検索式を知らない人でも、行政手続データを探索しやすくなります。

一方で、自然言語で結果が返ってくると、その回答を個人に対する正式な行政案内や法的判断として受け取ってしまう危険があります。

元記事では、「結婚・離婚」に関係する手続を横断的に検索する例が紹介されています。しかし、表示例には、一般的な婚姻届や氏名変更だけでなく、特定の資格者証、許可証、業務上の届出なども含まれています。これはデータ上、「結婚・離婚」というライフイベントに関連付けられている手続を検索した結果であり、すべての人に必要な手続の一覧ではありません。

したがって、実際に住民向けの手続案内へ展開する場合には、少なくとも次の段階が必要です。

1. データから関連する手続の候補を検索する
2. 居住地、年齢、世帯、職業、保有資格などの条件で絞り込む
3. 最新の公式手続ページや根拠法令を確認する
4. 必要に応じて自治体や所管機関の担当窓口へ確認する
5. AIによる推定と、公式に確認された事実を画面上で区別する

AIによる検索結果は、利用者が確認すべき情報へ到達するための補助としては有効です。しかし、検索結果だけを根拠に、個人の法的義務や申請要否を断定する設計は避ける必要があります。

データが古ければ、AIの回答も古くなる

今回使用されている行政手続等の悉皆調査は、調査時点の行政手続やオンライン化状況を整理したものです。

公開された実装には、データの取得日時と、データ自体の基準時点を区別して記録する仕組みがあります。これは、「今日取得したファイル」と「今日時点の情報」が同じではないためです。GitHubリポジトリでも、データは調査時点の情報であり、現在の状況と異なる可能性があること、利用時には原典資料も確認する必要があることが明記されています。

AIが検索できるようになっても、元データの更新頻度が上がるわけではありません。

今後、AIから公共データを利用する機会が増えるほど、次の情報を明示する必要性が高まります。

• データの基準日
• 最終更新日時
• 次回更新予定
• 管理主体
• 更新履歴
• 項目定義の変更履歴
• 既知の欠損や品質上の問題
• 原典へのリンク

AIが流暢な文章で回答すると、利用者はデータの古さや不確実性を見落としやすくなります。だからこそ、回答の文章だけでなく、回答の根拠となったデータの状態を同時に表示する設計が重要になります。

MCPはセキュリティを自動的に解決するものではない

公開データをローカル環境で検索するだけであれば、扱うリスクは比較的限定されます。

しかし、庁内データ、個人情報、申請情報、事業者情報などへ接続する場合、MCPサーバーは重要なセキュリティ境界になります。

今回のサンプル実装も、本番環境で外部公開する場合には、認証、認可、レート制限、監査ログなどを前段で実装する必要があると説明しています。

MCPの公式仕様でも、保護されたMCPサーバーについてOAuthを用いた認可、アクセストークンの検証、HTTPSによる通信、権限の制限などが定められています。特に、別のサービス向けに発行されたトークンをMCPサーバーがそのまま受け入れる「トークンの使い回し」は避けなければなりません。

行政や地域データへ展開する場合には、少なくとも次の区分が必要です。

• 誰でも利用できる公開・参照専用データ
• 組織内だけで利用する非公開データ
• 利用者本人の同意に基づいて参照する個人データ
• 職員や事業者が更新できるデータ
• 申請、予約、通知など、外部へ影響を与える操作

「データを検索する権限」と「データを変更する権限」を分けることも不可欠です。AIが利用できることを理由に、すべての機能やデータを一つのMCPサーバーへまとめるべきではありません。

自治体のオープンデータにも応用できる可能性

ここからは、デジタル庁が発表した計画ではなく、今回の技術検証を踏まえた株式会社civichubとしての考察です。

日本ではすでに、データの相互運用性を高めるための基盤整備が進められています。

デジタル庁の政府相互運用性フレームワーク（GIF）は、住所、施設、法人、連絡先などの共通的なデータについて、組織や分野を越えて連携しやすくするための参照データモデルを提供しています。

自治体標準オープンデータセットでは、公共施設、避難場所、医療機関、観光施設、イベント、公営駐車場、支援制度など、地方公共団体が公開するデータの項目やフォーマットが整理されています。

こうした既存の標準データへ、今回の実証と同様に次の情報を付加できれば、自治体データをAIから安全かつ正確に利用するための基盤に近づきます。

• 項目ごとの意味
• 使用可能な値
• 欠損値の意味
• 更新日時と管理主体
• 地理的・制度的な適用範囲
• 利用条件とライセンス
• 品質上の注意事項
• 推奨される検索・集計方法

重要なのは、自治体ごとに独自のチャットボットを作ることではありません。

既存のオープンデータや業務データを、Webサイト、地図、ダッシュボード、チャット、API、AIエージェントなどから共通して利用できる「地域のデータプロダクト」として整備することです。

今後は三つの段階で進むと考えられる

第一段階：既存データにAI向けの入口を追加する

当面は、すでにCSV、Excel、データベース、APIとして存在するデータに対し、検索や集計に限定したMCPツールを追加する取り組みが増えると考えられます。

この段階では、AIに任意のSQLやプログラムを生成させるのではなく、「一覧取得」「条件検索」「集計」「詳細取得」といった限定的な操作を提供する方が、権限管理や監査の面でも現実的です。

第二段階：AI向けデータカタログが整備される

次に、どの組織がどのようなデータを持ち、どの時点の情報で、誰が利用できるのかをAIが発見できる仕組みが必要になります。

単にMCPサーバーのURLを並べるだけではなく、データセットの定義、品質、ライセンス、更新頻度、責任主体、利用可能なツールなどを機械判読可能な形で管理する、AI向けデータカタログが求められるでしょう。

自治体がそれぞれ個別に運用基盤を構築するのではなく、都道府県、地域、共同利用組織などが共通基盤を提供する形も考えられます。

第三段階：検索から手続支援・実行へ進む

将来的には、AIが関連情報を検索するだけでなく、利用者の同意を得ながら、申請フォームへの入力、必要書類の確認、予約、通知などを支援する方向へ進む可能性があります。

ただし、参照専用の公開データを検索する仕組みと、本人情報を利用して行政手続を実行する仕組みでは、必要な本人確認、同意取得、認可、監査、責任分担が大きく異なります。

検索から実行へ進むほど、AIの自律性を高めることよりも、操作前の確認、取り消し可能性、記録保存、人による審査を組み込むことが重要になります。

まとめ

今回の実証の意義は、「AIが約75,000件のデータを読めるようになった」という点だけではありません。

重要なのは、LLMにすべてを任せるのではなく、LLMには自然言語の理解と処理条件の指定を担わせ、検索・集計はサーバー側で実行し、データの意味、品質、出典、注意事項まで一緒に返す構成を示したことです。

公共データの次の課題は、データを公開することから、AIが誤解しにくく、検証可能な形で利用できるようにすることへ移りつつあります。

Webサイトは人のために、APIはシステムのために、MCPはAIやAIエージェントのために。それぞれの入口を、信頼できる一つのデータ基盤へ接続することが重要になります。

今回公開されたものは、本番サービスではなく、小規模な技術検証です。しかし、公共データを「AIが利用することを前提としたデータプロダクト」へ発展させる上で、非常に参考になる実装例であると考えます。

参考資料

1. 行政手続等調査データ（約75,000件）をMCPで自然言語分析可能に｜デジタル庁Techブログ
   2026年8月13日公開。今回取り上げた技術検証の解説記事です。
2. 行政手続等の悉皆調査結果等｜デジタル庁
   技術検証で使用されている行政手続データの配布元です。
3. 行政手続データ分析 MCP Server｜GitHub
   デジタル庁が公開しているサンプル実装、設定方法、免責事項を確認できます。
4. What is the Model Context Protocol?｜MCP公式ドキュメント
   MCPの目的と基本的な位置付けを確認できます。
5. Guidelines and best practices for making government datasets ready for AI｜英国政府
   公共データのAI-ready化について、技術、品質、ガバナンス、法務・セキュリティの観点を整理したガイドラインです。
6. AI Agents Meet Federal Data: Public Preview for the GovInfo MCP Server｜GovInfo
   Web、API、MCPを異なる利用者向けのインターフェースとして整理した米国政府出版局の事例です。
7. 政府相互運用性フレームワーク（GIF）｜デジタル庁
   組織や分野を越えたデータ連携のための参照データモデルです。
8. 自治体標準オープンデータセット｜デジタル庁
   公共施設、イベント、観光施設、駐車場、支援制度などの標準的なデータ項目が公開されています。
9. コピーライトポリシー｜デジタル庁
   デジタル庁Webサイトおよび公式ソーシャルメディアのコンテンツ利用条件を確認できます。
10. Authorization Security Considerations｜MCP公式仕様
    MCPサーバーの認証・認可、トークン検証、通信保護などの要件が示されています。

最終確認日：2026年8月15日
MCPの仕様、各実装の提供状況、公開データの内容は今後変更される可能性があります。