e-Gov法令API v2のキーワード検索：検索式・ページング・ヒットしない語の実例

e-Gov法令API v2の keyword エンドポイントは、法令本文を対象にした全文検索です。数えているのは法令ではなく「文」で、0件はHTTP 404で返り、検索式は「スペース＝AND、|＝OR、!＝NOT」です。 この3点を押さえないと、ヒットしているのに件数を読み違えたり、ヒットするはずの語で0件になったりします。

この記事では、2026年9月14日にcurlで実行した結果をもとに、検索式の書き方、応答の読み方、ページング、そしてヒットしない語の実例を整理します。エンドポイント全体の位置づけは逆引きリファレンス、エラーコードの一覧はエラーと制限の記事を参照してください。

基本の呼び方と応答の形

最小の呼び方は keyword だけです。実務では law_type=Act で法律に絞り、sentence_text_size で抜粋の長さを決めることが多くなります。

curl -s -G "https://laws.e-gov.go.jp/api/2/keyword" \
  --data-urlencode "keyword=電子計算機" \
  --data-urlencode "law_type=Act" \
  --data-urlencode "limit=5" \
  --data-urlencode "sentence_text_size=40"

total_count=1183  sentence_count=5  next_offset=5  items=4
129AC0000000089  民法        rev 129AC0000000089_20260624_508AC0000000045
    mainprovision  ...ることができない方式で作られる記録であって、<span>電子計算機</span>
131AC0000000011  民法施行法  rev 131AC0000000011_20251001_505AC0000000053
    mainprovision  ...下電磁的方式ト称ス）ニ依リ作ラルル記録ニシテ<span>電子計算機</span>
132AC0000000048  商法        rev 132AC0000000048_20260624_508AC0000000046
    mainprovision  ...

応答のトップレベルは total_count sentence_count next_offset items の4つです。items の各要素は law_info（法令ID・法令番号）、revision_info（法令名・履歴ID・施行日）、sentences（ヒットした文の配列）で、sentences の要素は position と text の2つだけです。

見落としやすいのが数え方です。limit=5 で sentence_count=5 なのに items は4件でした。limit も total_count も文の数で、1つの法令に複数の文がヒットすればそこにまとまります。労働基準法1本に絞って「労働時間」を検索すると、はっきりします。

curl -s -G "https://laws.e-gov.go.jp/api/2/keyword" \
  --data-urlencode "keyword=労働時間" \
  --data-urlencode "law_num=昭和二十二年法律第四十九号" \
  --data-urlencode "limit=1000"

total_count=89  sentence_count=89  items=1
position の内訳: mainprovision 58 / amendsupplprovision 15 / caption 8 / supplprovision 6 / toc 1 / mainprovisiontoc 1

法令は1本、文は89。position は「本則」「改正附則」「見出し」「附則」「目次」といった区分で、OpenAPI定義の例にある MainProvision-Article_21-Paragraph_3 のような条番号付きのパスではありませんでした。どの条にヒットしたかは keyword だけでは分からないので、条を特定したい場合は text の抜粋を手がかりに law_data の elm で本文を引き直します。

検索式の書き方：公式仕様と実測

検索式の仕様はe-Gov法令検索のヘルプ「検索式の書き方」にあります。要点は次のとおりです。

AND   : 用語の間に半角スペース          例  情報 公開
OR    : 用語の間に半角パイプ |          例  情報公開|個人情報
NOT   : 用語の前に感嘆符 !              例  情報 !個人情報
組合せ: 丸括弧で AND をまとめて | でつなぐ   例  (情報 公開)|個人
ワイルドカード: * は0文字以上、? は1文字   例  であって*として*定める
制約  : ワイルドカードは AND/OR/NOT と組み合わせられない

同じ「電子計算機」を軸に、law_type=Act で書き方を変えて投げた結果です。

電子計算機                     -> 1183 文
電子計算機 不正                -> 63 文   （AND）
電子計算機|電子情報処理組織    -> 1966 文 （OR）
電子計算機 !不正               -> 1120 文 （NOT。1183 - 63 と一致）
(電子計算機 不正)|電磁的記録   -> 3307 文 （AND のまとまりを OR）

一方、通りそうで通らなかった書き方も多くありました。

電子計算機 AND 不正            -> 404 0件（AND が検索語扱い）
電子計算機&不正                -> 404 0件
電子計算機 -不正               -> 404 0件（マイナスは NOT ではない）
"電子計算機"                   -> 404 0件（引用符は検索語扱い）
電子計算機　不正               -> 404 0件（全角スペースは AND にならない）
(電子計算機|電磁的記録) 不正   -> 400 コード400019「検索ワード（keyword）が未設定又は誤っています。」
（電子計算機 不正）|電磁的記録 -> 400 コード400019（全角括弧）

括弧はヘルプにある「ANDのまとまりを括弧で囲み、| でつなぐ」形だけが通り、ORのまとまりを括弧で囲んでANDする形は400でした。検索式を組むときは「AND を括弧でまとめて OR で並べる」方向に寄せます。

ワイルドカードは遅く、併用できない

ワイルドカードは動きますが、所要時間が桁で変わります。

電子計算機*        -> 200  6,163 文   17.6 秒
第*条              -> 200  576,885 文 18.6 秒
電子計算* 不正     -> 504 Gateway Time-out（60 秒で切断）

通常のキーワード検索が0.5〜1.8秒で返るのに対し、ワイルドカードは17秒以上かかりました。ヘルプとOpenAPI定義の両方に「ワイルドカードは AND/OR/NOT と組み合わせられない」とあり、実際に組み合わせると60秒でゲートウェイのタイムアウトになります。定期実行や対話的な用途では、ワイルドカードは避けるか単独で使い、タイムアウトを長めに取ってください。

ページング：next_offset を追う

limit は文の数の上限で、既定100、上限1000です。1001を渡すと400（コード400005「取得件数（limit）は1件以上1000件以内を指定してください。」）でした。1,183文ある「電子計算機」（法律のみ）を limit=500 で末尾まで辿ったログです。

offset=0     -> sentence_count=500  items=175  next_offset=500
offset=500   -> sentence_count=500  items=153  next_offset=1000
offset=1000  -> sentence_count=183  items=78   next_offset （キーなし）

offset も文単位です。注意点は末尾の扱いで、OpenAPI定義では「末尾まで取得が完了した場合は null」とありますが、実際の応答では next_offset キー自体がありませんでした。 JavaScriptなら 'next_offset' in data、Pythonなら data.get('next_offset') で判定しないと、末尾で KeyError になります（筆者はなりました）。

sentences_limit は法令ごとの表示文数を絞るパラメータですが、limit=10&sentences_limit=1 では sentence_count=6、items=6、next_offset=10 となり、OpenAPI定義の注記どおり limit と実際に返る数が一致しなくなりました。ページングの基準はあくまで limit 側です。

絞り込みと表示の調整

実務で使うパラメータを、動作を確認した順に並べます。

asof を付けると検索対象の版も変わるため、過去時点で「その語が条文にあったか」を調べられます。時点指定の考え方はasof指定の記事と同じです。

ヒットしない語の実例

0件のときは200の空配列ではなく、404とエラー本文が返ります。

{"code":"404001","message":"取得結果が０件です。"}

これを「エラー」として握りつぶすと、単にヒットしなかっただけなのか、リクエストが壊れているのかが区別できなくなります。404かつコード404001なら「正常に検索して0件」と扱ってください。

法令本文の英字は全角で書かれていることが多く、半角の AI DX は0件、全角の ＡＩ ＤＸ はヒットしました。しかも ＡＩ（62文）と ａｉ（21文）は別に数えられており、大文字小文字も区別されます。一方「生成AI」「量子コンピュータ」は全角・半角のどちらでも0件で、2026年9月時点で条文にその語が無いと読むのが自然です。

エージェントに検索させるときは、0件で止まるのではなく「全角に置き換えて再検索する」「| で表記揺れを並べる」を指示に入れておくと、人が目視でやっている補正をそのまま移せます。ただし置き換えの候補を勝手に広げすぎると、別の語にヒットしたものを根拠として扱う危険があるので、最終的にヒットした表記を出力に残させてください。

まとめ

• keyword は法令本文の全文検索。total_count limit offset はすべて文の数で、items が法令単位
• 検索式はスペース＝AND、|＝OR、!＝NOT、括弧は「(A B)|C」の形のみ。AND & - 引用符・全角スペースは通らない
• ワイルドカードは17秒以上かかり、演算子と併用すると504。定期実行では避ける
• 0件は404とコード404001。半角英字は0件になりやすく、全角に置き換えると引ける。末尾では next_offset キーが消える

position が条番号まで教えてくれない以上、keyword は「どの法令のどのあたりに語があるか」を当たりづけする道具として使い、条文そのものは law_data で引き直すのが確実です。Claude Codeから条文を引く構成はe-Gov法令API活用ガイド、パラメータを組み立てて試すにはリクエストビルダーが使えます。