日本の公共データMCPガイド：法令・国会・統計・法人・開示情報の選び方

結論：まず「どの公的事実を答えるか」で1つ選ぶ

日本の公共データをMCPから使うなら、最初にデータ源を束ねるのではなく、法令、国会発言、統計値、法人情報、法定開示書類のどれを答えるかを決めます。各APIは識別子、検索単位、認証、更新の意味が違います。1つの巨大な search_public_data より、検索と原資料取得を分けた小さなツールの方が、AIの誤引用を追跡しやすくなります。

この記事が扱うのは、公式APIを調査支援用MCPへ接続する設計です。データから法的・投資・信用判断を自動決定する方法ではありません。重要な判断は、原資料、基準日、担当機関の説明、必要に応じた専門家確認へ戻してください。

対象読者

日本のオープンデータをClaude Codeなどから検索したい人
MCPサーバーの題材を探しているTypeScript開発者
複数の公共APIを同じ出典形式で扱いたい人
AI調査の根拠URLと取得日時を監査できるようにしたい人

5つのAPIを用途で比較する

データ源	最も向く問い	主な識別子	認証	取得単位
e-Gov法令API	「基準日時点の条文は何か」	法令ID、リビジョンID	最新仕様を確認	法令一覧、改正履歴、本文、ファイル
国会会議録API	「誰が、いつ、どの会議で発言したか」	会議録ID、発言ID	利用手続不要	会議一覧、会議録、発言
e-Stat API	「公的統計の値と分類は何か」	統計表ID、分類コード	アプリケーションID	統計表、メタ情報、統計値
GビズインフォAPI	「法人に紐づく行政保有情報は何か」	法人番号	APIトークン	法人基本、認定、調達、補助金等
EDINET API	「提出された開示書類は何か」	書類管理番号	APIキー	書類一覧、XBRL等、PDF、CSV

この表の「向く問い」から外れるほど、複数データ源の照合が必要になります。たとえば、企業名から有価証券報告書を探す前段には法人番号や提出者情報の照合が要りますが、同名企業をAIの文字列一致だけで結び付けてはいけません。

e-Gov法令API：条文と改正履歴を扱う

法令API v2には、法令一覧、改正履歴、法令本文、法令ファイルなどのエンドポイントがあります（e-Gov法令API v2仕様）。law_data の asof で基準日以前の改正状態を選べるため、現行だけでなく時点を伴う条文調査に向きます（法令本文取得の仕様）。

MCPでは次の2段階に分けます。

search_laws(query) で候補の法令ID、正式名、法令番号だけを返す。
get_law_article(lawId, article, asOf) で指定条とリビジョン情報を返す。

法令名は改題や通称があるため、確定後は法令IDで引きます。e-Gov法令MCPで法令名が見つからない理由と、XMLをMCP向けJSONへ変換する設計を合わせて読むと、検索と本文取得の境界を決めやすくなります。

国会会議録API：発言者・会議・発言本文を扱う

国立国会図書館の検索用APIは、会議単位簡易出力、会議単位、発言単位の3種類を提供し、XMLまたはJSONで取得できます。利用手続は不要です（国会会議録検索システム検索用API）。

一方、1回の最大取得件数は発言単位・会議一覧が100件、会議単位が10件です。公式ページは過大な負荷や複数リクエストの同時実行を避け、取得後に数秒空けるよう求めています（同API「利用上のお願い」）。

MCP設計では次を守ります。

issueID と speechID を出典オブジェクトに残す
検索結果のスニペットと発言全文を別ツールにする
maximumRecords と次ページ位置をモデル任せにしない
サーバー側で直列化、待機、キャッシュを行う
発言本文の利用前に公式ページ記載の著作権上の注意を確認する

「何を決めたか」と「誰が何を発言したか」は同じではありません。会議録から政策の法的効力を推測せず、必要なら法令・告示・公式発表へ接続します。

e-Stat API：値とメタデータをセットで扱う

e-Stat APIの現行仕様ページはバージョン3.0を案内し、XML、JSON、CSVの出力形式を示しています（e-Stat API仕様）。利用にはユーザー登録で取得するアプリケーションIDが必要です（e-Stat API仕様3.0）。

統計MCPで最も危険なのは、値だけを返すことです。公式の開発ガイドに沿い、次の3段階をツールとして分けます（e-Stat API機能と利用の流れ）。

search_stat_tables で統計表を探す。
get_stat_metadata で地域、時間、表章項目、単位、分類コードを確認する。
get_stat_values で必要な条件だけを指定して値を取得する。

レスポンスには statsDataId、分類コード、単位、時間軸、注釈、取得条件を残します。「空欄」「ゼロ」「秘匿」「該当なし」を同じ 0 に正規化してはいけません。自然言語ラベルは表示用、コードは照合用として併存させます。

GビズインフォAPI：法人番号を軸に行政保有情報を扱う

GビズインフォAPIはv2.0として案内され、利用登録後にAPIトークンを使います。法人番号や法人名から、法人基本情報、認定、表彰、財務、特許、調達、補助金、職場情報などを取得できます（Gビズインフォ API）。

法人MCPの入口は名前ではなく法人番号です。

search_corporations(name, address?)
  -> 候補一覧（法人番号・所在地・名称）

get_corporate_profile(corporateNumber)
  -> 選択済み法人の情報と各データの出典メタデータ

Gビズインフォのメタデータには、データの概要、品質、出典、更新頻度を理解するための情報があります（Gビズインフォ「メタデータとは」）。取得日だけでなく、可能ならデータ基準日と元データ機関を返します。掲載なしを「実績なし」と断定しないことも重要です。

EDINET API：提出書類と訂正関係を扱う

EDINET API Version 2は、書類一覧APIと書類取得APIを提供します。利用にはAPIキーが必要で、リクエストURLのクエリパラメーター Subscription-Key に指定します（金融庁 EDINET API仕様書 Version 2）。ログへURLを残す場合は、この値を必ずマスクします。

書類取得では、XBRL等を含むZIP、PDF、代替書面・添付文書、英文ファイル、CSVなどを取得種別で選べます。書類一覧には訂正、取下げ、開示状態に関わる項目もあるため、最新版らしい1件だけを名前で選ばず、書類管理番号と関係項目を確認します（同仕様書）。

MCPは巨大なZIPをそのままモデルへ渡さず、次の層に分けます。

list_edinet_documents(date, filters)：提出書類の候補と状態を返す
get_edinet_document_metadata(docId)：提出者、期間、訂正関係を返す
extract_edinet_facts(docId, concepts)：許可したXBRL項目を抽出する
get_edinet_source(docId, type)：人間確認用の原資料を取得する

数値比較では連結・個別、期間、単位、会計基準、訂正前後を同じ軸に揃えます。抽出できた数値は投資判断そのものではありません。

選定の判断表

作りたい機能	第一候補	最初のMCPツール	人間確認ポイント
現行・過去時点の条文引用	e-Gov法令	`get_law_article`	基準日、改正履歴、適用関係
議員・政府参考人の発言検索	国会会議録	`search_speeches`	会議、発言者、前後の文脈
都道府県別の公式統計比較	e-Stat	`get_stat_values`	表ID、分類、単位、注釈
法人の行政保有情報調査	Gビズインフォ	`get_corporate_profile`	法人番号、出典、基準日
有価証券報告書の項目抽出	EDINET	`extract_edinet_facts`	書類ID、訂正、期間、単位

複数APIが必要なら、まず各データ源の安定IDを確定し、後段のルーターがID付き結果を束ねます。AIに「名前が似ているから同一」と結合させません。

共通の出典オブジェクト

5つのAPIを横断する前に、結果の外側だけ共通化します。

type PublicDataSource = {
  provider:
    | "e-Gov Laws"
    | "NDL Diet Records"
    | "e-Stat"
    | "G Biz INFO"
    | "EDINET";
  recordId: string;
  sourceUrl: string;
  retrievedAt: string;
  dataAsOf: string | null;
  query: Record<string, string | number | boolean>;
  notes: string[];
};

type PublicDataResult<T> = {
  data: T;
  source: PublicDataSource;
  warnings: string[];
  nextPage: string | null;
};

query は再現に必要な非機密パラメータだけを残します。アプリケーションID、APIキー、トークンはログやMCPレスポンスへ含めません。

実装する順番

問いを1文にする。 例：「指定法令の指定日時点の条文を、原文URL付きで返す」。
安定IDを決める。 名前検索の結果を確定IDへ変換する段階を置く。
検索と本文取得を分離する。 候補一覧に巨大本文を混ぜない。
出典形式を共通化する。 ID、URL、取得日時、基準日、検索条件を返す。
上限をサーバー側で固定する。 件数、ページ数、本文サイズ、タイムアウトをAIから変更できないようにする。
キャッシュ方針をデータ源別にする。 法令の改正、日次の提出書類、統計表の更新を同じTTLにしない。
代表失敗をテストする。 0件、同名、欠測、訂正、ページング、429、タイムアウトを確認する。

MCP自体が初めてなら、先にMCP入門ガイドでツール・リソース・権限の境界を確認してください。運用開始後の接続問題はMCPサーバー接続トラブルシューティングで切り分けられます。

公開前チェックリスト

よくある質問

日本の公共データを横断するMCPは、最初から1サーバーにまとめるべきですか？

最初は一つの問いと一つの公式APIに絞る方が安全です。識別子、更新頻度、認証、ページング、引用単位がデータ源ごとに異なるためです。共通の出典形式を固めた後に、ルーター層で横断させます。

紹介している行政機関が公式MCPサーバーを提供しているのですか？

この記事が確認・比較しているのは各機関の公式Web APIです。公式APIがあることと、公式MCPサーバーが提供されていることは別です。MCP化する場合は、実装者、配布元、バージョン、利用条件を個別に確認してください。

APIキーなしで試しやすいデータ源はどれですか？

国会会議録検索システムAPIは利用手続不要と公式ページに記載されています。e-Stat、Gビズインフォ、EDINETはそれぞれアプリケーションIDやトークン、APIキーが必要です。e-Gov法令APIは実装前に最新仕様と利用上の注意を確認してください。

まとめ

公共データMCPの選び方は明快です。

法令原文と改正履歴はe-Gov法令API
国会での発言は国会会議録検索システムAPI
公式統計の値と分類はe-Stat API
法人番号に紐づく行政保有情報はGビズインフォAPI
提出された法定開示書類はEDINET API

最初の完成形は、横断検索ではありません。一つの問いに対して、安定ID・基準日・出典URL付きで原資料を返せることです。その境界が固まれば、データ源を増やしても回答の根拠を追跡できます。