国会会議録検索APIの使い方：発言検索・会議録取得・ページングをcurlで実測（キー不要）

国会会議録検索システムのAPIは、APIキーも利用申請も不要で、発言1件単位まで JSON で取得できます。 一方で、1回の上限が100件（会議単位は10件）、既定の応答がXML、無効なパラメータ値が黙って無視されるなど、AIエージェントに渡す前に知っておくべき癖があります。

この記事は、公式の仕様ページを読んだうえで、2026年9月14日に実際にリクエストを投げた結果をもとに書いています。日本の公共データAPI 5選では他の公共APIとの比較にとどめていたので、ここでは国会会議録APIだけを深掘りします。MCPサーバーにする手順は続編の国会会議録APIをMCPサーバー化するにまとめました。

先に押さえること

3つのエンドポイントと上限

公式ページに記載されているエンドポイントと上限は次のとおりです。いずれも GET で、検索条件はクエリ文字列（UTF-8 で URL エンコード）で渡します。

使い分けは「本文がどの粒度で欲しいか」で決まります。

meeting_list は meeting から本文を抜いた軽量版で、speechRecord には speechID・speechOrder・speaker・speechURL だけが入ります。会議の一覧を出してから、必要な会議だけ meeting で全文を引く、という2段構えに向いています。

まず1件取ってみる

any に検索語、maximumRecords に件数、recordPacking=json を付けます。recordPacking を省略すると XML が返るので、JSON で扱うなら毎回付けます。

curl -s "https://kokkai.ndl.go.jp/api/speech?any=%E7%94%9F%E6%88%90AI&maximumRecords=1&recordPacking=json"

実際の応答（本文は省略）です。

{
  "numberOfRecords": 1161,
  "numberOfReturn": 1,
  "startRecord": 1,
  "nextRecordPosition": 2,
  "speechRecord": [
    {
      "speechID": "122115391X00120260723_026",
      "issueID": "122115391X00120260723",
      "imageKind": "会議録",
      "searchObject": 26,
      "session": 221,
      "nameOfHouse": "参議院",
      "nameOfMeeting": "沖縄・北方問題及び地方に関する特別委員会、総務委員会連合審査会",
      "issue": "第1号",
      "date": "2026-07-23",
      "closing": null,
      "speechOrder": 26,
      "speaker": "岸真紀子",
      "speakerYomi": "きしまきこ",
      "speakerGroup": "立憲民主・無所属",
      "speakerPosition": null,
      "speakerRole": null,
      "speech": "○岸真紀子君　今法律の議論をしているので、…",
      "startPage": 0,
      "speechURL": "https://kokkai.ndl.go.jp/txt/122115391X00120260723/26",
      "meetingURL": "https://kokkai.ndl.go.jp/txt/122115391X00120260723",
      "pdfURL": null
    }
  ]
}

覚えておく項目は4つです。

• speechID は 会議録ID_発言番号（3桁） の形式で、後から speechID= で完全一致検索できます
• issueID は21桁の会議録IDで、meeting の issueID= に渡すとその会議の全発言が取れます
• speechURL は発言番号付きの公式ページ、meetingURL は会議録全体のページです
• speech 本文は ○発言者名　 で始まり、改行は \r\n です

nextRecordPosition は次ページがあるときだけ入ります。最終ページでは JSON からキーごと消えました（後述）。

主要パラメータ

公式ページのパラメータのうち、実務で使う頻度が高いものを整理します。全体で2,000バイトの上限があり、検索条件が1つもないと400エラーになります。

同じ検索語 生成AI に条件を足していったときの件数です（2026-09-14 実測、いずれも speech）。

他に確認した組み合わせは、speaker=片山さつき で4件、sessionFrom=221&sessionTo=221 で283件、speakerRole=参考人 で61件でした。

実測で分かった検索の癖

全角・半角は同じ扱い

any=生成AI と any=生成ＡＩ はどちらも1,161件、単独の AI と ＡＩ はどちらも12,590件でした。会議録本文は英字が全角（生成ＡＩ）で書かれていますが、検索側で正規化されているので、クライアントで変換する必要はありません。

一方、生成 AI のようにスペースを入れると 生成 AND AI の2語検索になり、1,324件と増えます。「生成AI」という語を引きたいならスペースを入れない、が正解です。

部分一致なので短い語は広く当たる

speaker=岸田 と speaker=岸田文雄 は同じ7件でした。部分一致は便利ですが、AI のような短い語は ＡＩＤＳ のような別語にも当たりうるので、件数が多いときは会議名や日付で絞ります。

無効な院名はエラーにならない

ここが一番の落とし穴でした。nameOfHouse=衆院 を渡すと エラーにならず、条件なしと同じ1,161件 が返ります。仕様上の許容値は 衆議院 参議院 両院 両院協議会 だけで、それ以外は黙って無視されるようです。

nameOfHouse=衆議院 -> 637件
nameOfHouse=参議院 -> 524件
nameOfHouse=衆院   -> 1161件（条件なしと同じ）

対照的に speakerRole=大臣 は400で止まります。

{"message":"(19011)検索条件の入力に誤りがあります。","details":["(0) (19028)speakerRole:発言者役割を証人/参考人/公述人で入力してください。"]}

エラーになるパラメータと無視されるパラメータが混在しているので、エージェントに使わせるなら院名は列挙型で固定し、API に任せないほうが安全です。

ページングと最終ページの判定

生成AI の1,161件を100件ずつ取ると、応答ヘッダ部分はこう動きました。

startRecord=1    -> numberOfReturn=100, nextRecordPosition=101
startRecord=101  -> numberOfReturn=100, nextRecordPosition=201
...
startRecord=1101 -> numberOfReturn=61,  nextRecordPosition なし（キーが消える）
startRecord=5000 -> 400 (19004) startRecordには 1から検索件数までの値を指定してください。

つまり「nextRecordPosition が返ってきたらその値を次の startRecord に入れる、返ってこなければ終わり」です。numberOfRecords を超える位置を指定すると400になるので、総件数から回数を先に計算するより、nextRecordPosition の有無で回すほうが壊れにくいです。

会議単位で全発言を取る

会議一覧から会議録IDを取り、meeting で全文を引く流れです。

# 2026年4月の衆議院内閣委員会を一覧
curl -s "https://kokkai.ndl.go.jp/api/meeting_list?nameOfMeeting=%E5%86%85%E9%96%A3%E5%A7%94%E5%93%A1%E4%BC%9A&nameOfHouse=%E8%A1%86%E8%AD%B0%E9%99%A2&from=2026-04-01&until=2026-04-30&maximumRecords=3&recordPacking=json"

# 会議録IDを指定して全発言を取得
curl -s "https://kokkai.ndl.go.jp/api/meeting?issueID=122104889X00820260424&recordPacking=json"

一覧は9件ヒットし、先頭は4月24日の第8号（issueID=122104889X00820260424）でした。meeting で引くと speechRecord が208件、応答は約160KBです。先頭の発言は speechOrder: 0、speaker: "会議録情報" で、本文は出席委員の名簿です。

{
  "speechID": "122104889X00820260424_000",
  "speechOrder": 0,
  "speaker": "会議録情報",
  "speech": "令和八年四月二十四日（金曜日）\r\n　　　　午前九時開議\r\n　出席委員\r\n…",
  "startPage": 1,
  "createTime": "2026-09-10 00:06:32",
  "updateTime": "2026-09-10 10:55:03",
  "speechURL": "https://kokkai.ndl.go.jp/txt/122104889X00820260424/0"
}

2点注意です。speechOrder: 0 は発言ではなく会議録の冒頭情報なので、発言者集計から外します。もう1つ、createTime が 2026-09-10 になっているとおり、4月24日の会議が API で取れるようになったのは9月に入ってからです。会議録の掲載には時間差があり、「直近の会議は未収録」を前提に設計します。

エラー応答の形

JSON 指定時のエラーは message（と入力誤りなら details）を持つ JSON で、HTTP 400 で返ります。実測した3つです。

検索条件なし          -> {"message":"(19007)検索条件を指定してください。"}
maximumRecords=101    -> (19011) + details "(19005)maximumRecordsには1～100の値を指定してください。"
from=2026/04/01       -> (19011) + details "(19012)from:開会日付をYYYY-MM-DD形式で入力してください。"

コード番号は公式ページの一覧と一致しています。混雑時は 19001 が返るとされていますが、今回は遭遇しませんでした。

AIエージェントから使うときの前提

公式ページの「利用上のお願い」には、短時間の大量アクセスを遠慮すること、機械的アクセスでは多重リクエストを避け数秒の間隔を空けることが書かれています。加えて、発言の著作権は発言者に帰属し、利用は原則として著作権者の許諾が必要（権利制限規定の適用等を除く）とされています。エージェントに使わせるときの最低限の約束は次の4つです。

1. 院名・役割は列挙型で固定する。 無効値が黙殺されるので、モデルの自由入力を API に直接渡さない
2. maximumRecords の上限をサーバー側で小さく固定する。 100件×本文は1回で136KBになり、コンテキストを圧迫する
3. リクエストは直列化し、間隔を空ける。 数秒の間隔は公式の依頼事項
4. speechID と speechURL を必ず残す。 要約が正しいかを人間が原文で確認できる状態を保つ

この4点をそのままコードに落としたのが国会会議録APIをMCPサーバー化する記事です。すでに公開されている @codeagentjp/houan-mcp の使いどころはhouan-mcpの7つのユースケースにまとめてあります。

まとめ

• 国会会議録検索APIは手続不要。speech（発言）、meeting（会議）、meeting_list（会議一覧）の3エンドポイント
• 上限は発言・一覧が100件、会議が10件。nextRecordPosition がなくなるまで startRecord を進める
• 全角・半角は正規化済み。スペースは AND（any）と OR（nameOfMeeting・speaker）で意味が違う
• nameOfHouse の無効値はエラーにならず無視される。speakerRole の無効値は400。エージェントには列挙型で渡す
• 会議録の掲載には時間差がある。speechOrder: 0 は冒頭情報で発言ではない

API 自体は素直ですが、「失敗が失敗の形をしていない」ケースが1つあることだけは、e-Gov法令API v2の時点指定で見た現行条文の黙殺と同じ種類の落とし穴です。院名の固定と出典IDの保持を、最初から設計に入れてください。