e-Gov法令API v2のエラーコードと制限：404・400の実測一覧と504の切り分け、Base64、巨大法令のサイズ

e-Gov法令API v2のエラーは、API本体が返す code と message のJSON、フレームワークが返す timestamp 付きJSON、サーバー手前が返すHTMLの3系統に分かれます。 どの形で返ってきたかを見れば、パラメータの値が悪いのか、リクエストの組み立てが壊れているのかを一段目で切り分けられます。

この記事は、存在しないID・不正な日付・不正なパラメータを2026年9月14日に実際に叩いて、ステータスコードと本文を記録したものです。あわせてBase64と文字コード、Accept と response_format の優先順位、民法・会社法・所得税法の取得サイズと所要時間も実測しました。エンドポイントごとの正常系は逆引きリファレンスを参照してください。

504 Gateway Time-out はこの3系統とは別のエラーです。急ぐ場合は504が返ったときの切り分けから読んでください。

エラーの3系統を見分ける

同じ400でも本文の形が違います。実際に返ってきた3つを並べます。

# 1. API本体（application/json）: パラメータの値が不正
{"code":"400004","message":"日付（asof等）が誤っています。"}

# 2. フレームワーク既定（application/json）: 必須パラメータ欠落・未知パス
{"timestamp":"2026-09-14T04:29:20.884+00:00","status":400,"error":"Bad Request","path":"/api/2/keyword"}

# 3. サーバー手前（text/html）: URLに角括弧をそのまま含めた
<!doctype html><html lang="en"><head><title>HTTP Status 400 – Bad Request</title>...

1はOpenAPI定義の error_info スキーマどおりで、code の先頭3桁がHTTPステータスに対応します。2は keyword を付けずに /keyword を呼んだときと、存在しないパス /api/2/nope（404）で返りました。3は elm=LawTitle[1] のように角括弧をエンコードせずに送ったときで、レスポンスヘッダは Server: CloudFront、X-Cache: Error from cloudfront でした。3が出たらパラメータの値ではなくURLの組み立てを疑います。

なお POST /laws は405で本文が Method Not Allowed の18バイト、Accept: text/html は406で Not Acceptable でした。

504 Gateway Time-out が返ったときの切り分け

504 は、上の3系統とは別のエラーです。HTTPの仕様（RFC 9110 の 15.6.5）では、中継役のサーバーが、上流のサーバーから時間内に応答を受け取れなかったことを表します。API本体が code を付けて返すエラーではないので、パラメータの値を直せば解消するとは限りません。

この記事に記録したリクエスト（law_data、laws、law_revisions、law_file など）に、504 が返ったものはありません。16.4MBある所得税法の全文も1.61秒で届いています。筆者が504を確認したのは、同じ2026年9月14日に keyword でワイルドカードと AND を組み合わせた1例だけです。キーワード検索の記事の記録から、検索式と結果を再掲します。

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

このときの応答本文とヘッダーは保存していません。504 を返したのがどの層か、本文がHTMLかJSONかは、この記録からは分かりません。2026年10月5日の加筆ではAPIを呼び出しておらず、504 を再現するための負荷もかけていません。

504 が返ったら、次の順で切り分けます。実測で確かめたことと、確かめていない一般的な対処を分けて書きます。

1. 検索式を確認する（実測あり）。 keyword でワイルドカード（*、?）を AND・OR・NOT と組み合わせていないかを見ます。ヘルプとOpenAPI定義はこの組み合わせを不可としており、実際に60秒で504になりました。ワイルドカードを外すか、単独で使います。
2. 軽いリクエストを1回送る（正常時の実測のみ）。 laws?law_id=322AC0000000049&limit=1 は、9月14日の実測で200を返しました。これが返るなら、API全体が止まっているのではなく、504になったリクエストが重いと考えられます。
3. 条件を絞る（効果は未確認）。 ワイルドカードは単独でも17秒以上かかりました。語を具体的にして、ヒットする文を減らします。絞り込みで504が解消するかどうかは確かめていません。
4. 時間を空けて、1回だけ再試行する（未確認の一般的な対処）。 すぐに同じリクエストを繰り返すと、重い処理を重ねるだけになります。504になった検索は切断まで60秒かかったので、自動で再試行するなら回数の上限を決め、間隔を広げます。待ち時間の目安は公式資料に見当たらず、再試行で解消するかどうかも確かめていません。
5. 公式の告知を確認する。 軽いリクエストも失敗するなら、e-Gov側の障害やメンテナンスを疑い、e-Gov法令検索のお知らせ一覧を見ます。v1からv2への移行ガイドで2026年9月14日に確認した時点の掲載は2件でした。障害やメンテナンスの告知がこの一覧に載るかどうかは確認できていません。

ここで扱っているのは法令API（laws.e-gov.go.jp/api/2/）だけです。e-Gov電子申請など、ほかのe-Govのサービスで表示される504は対象外です。エージェントに任せる場合は、504を「条件を変えて試し続ける合図」にしないよう、再試行の回数と間隔を呼び出し側で固定してください。

実測したエラー一覧

未知のパラメータ（foo=bar）は無視されて200でした。タイプミスしたパラメータ名はエラーにならず、絞り込みが効かないまま結果が返るので、件数が想定より多いときはパラメータ名を確認してください。

asof の下限2017-04-01は、ヘルプにある「平成29年4月1日時点以降の法令データ整備を実施」という記述と一致します。それ以前の条文はこのAPIでは取れません。

0件の返り方はエンドポイントで違う

law_data の404004は「本文ファイルが無い」の意味で、存在しない法令IDでも、存在するIDに存在しない履歴IDを付けたときでも同じコードでした。law_revisions の404001は「一覧が0件」です。エージェントに渡すときは、この2つのコードを「止まるべきエラー」ではなく「検索条件を見直す合図」として扱うよう指示しておくと、無理に別の法令で埋める挙動を防げます。

Accept と response_format の優先順位

response_format を付けない場合は Accept ヘッダで形式が決まり、判断できなければJSONです。組み合わせを変えて laws?law_id=322AC0000000049&limit=1 を呼びました。

Accept なし                                    -> 200 application/json
Accept: application/json                       -> 200 application/json
Accept: application/xml                        -> 200 application/xml  <laws_response>...
Accept: application/xml + response_format=json -> 200 application/json（response_format が優先）
Accept: text/html                              -> 406 "Not Acceptable"
Accept: application/xml + law_type=Foo         -> 400 application/xml  <ErrorInfo><code>400001</code>...

エラー本文も形式に追従し、XMLでは <ErrorInfo> 要素で返ります。JSONの Content-Type は application/json だけで charset の指定がありません。中身はUTF-8で、XML（law_file/xml）は <?xml version="1.0" encoding="UTF-8" standalone="no"?> の宣言付きでした。Shift_JISで返ることはなかったので、受け側はUTF-8固定で問題ありません。

Base64 になる条件と確認方法

law_data は外側の response_format（既定 json）と本文の law_full_text_format を別々に指定でき、2つが食い違うときだけ law_full_text がBase64になります。 労働基準法で確認しました。

curl -s "https://laws.e-gov.go.jp/api/2/law_data/322AC0000000049?law_full_text_format=xml" \
  | python -c "import json,sys,base64; t=json.load(sys.stdin)['law_full_text']; print(len(t), t[:24]); print(base64.b64decode(t)[:60])"

531044 PExhdyBFcmE9IlNob3dhIiBM
b'<Law Era="Showa" Lang="ja" LawType="Act" Num="049" PromulgateDay="07"'

law_full_text が PExhdy... で始まっていたらBase64です（<Law をBase64にした先頭がこの並びになります）。復号すると398,281バイトのXMLで、同じ法令を response_format=xml で取ったときの本文とサイズが一致しました。復号の実装はPython実装の記事に、XMLをMCP用JSONに変換する設計はXML→JSONの記事にあります。

Base64を避けたいだけなら、JSONが欲しいときは law_full_text_format を付けない、XMLが欲しいときは response_format=xml にする、の二択で済みます。

巨大法令のサイズと所要時間

大きな法令をどの形式で取ると何バイトになるか、5本で測りました。json_full は law_data の既定、json_light は json_format=light、xml は response_format=xml、b64 はJSON応答に law_full_text_format=xml を付けたもの、file_xml は law_file/xml、gz は json_full を curl --compressed で受けたときの転送量です。

読み取れることを3つ挙げます。

• Base64は素の1.33倍。 所得税法では16.4MBが21.9MBに膨らみます。JSONとXMLを混ぜないだけで転送量が減ります。
• gzipが最も効く。 law_data は Accept-Encoding: gzip に応じて所得税法を662KB（4%）まで圧縮しました。law_file は --compressed を付けても16.4MBのままで、圧縮されません。
• json_format=light は所得税法で約4割減。 速度目的というより、構造を簡素にする目的のオプションです。

所要時間はすべて2秒以内で、curlでは所得税法（16.4MB）でも問題なく取れました。30回連続で law_data を呼んでもすべて200で、レート制限には当たりませんでしたが、公式資料に制限値の記載は見当たらず、応答ヘッダは Cache-Control: max-age=0, no-cache, no-store で毎回オリジンまで届きます。定期実行では自分で間隔を空け、本文の一括取得が目的なら公式が案内しているXML一括ダウンロードを使う方が向いています。

Windows で日本語パラメータが化ける

Windowsで検証していて、law_title=民法 が0件になる現象に当たりました。原因はcurlに渡る日本語のバイト列です。-w '%{url_effective}' で実際に送ったURLを表示すると分かります。

Git Bash（MSYS）から curl.exe   -> law_title=%96%af%96%40           （Shift_JIS）→ 0件
PowerShell 7.6 から curl.exe    -> law_title=%E6%B0%91%E6%B3%95     （UTF-8）   → 11件

同じ --data-urlencode "law_title=民法" でも、呼び出す殻によってUTF-8で渡るかShift_JISで渡るかが変わりました。原因が分からない0件は、まず url_effective を見てください。回避策は、あらかじめパーセントエンコードした文字列を渡すか、URL オブジェクトにエンコードを任せられるNode.jsやPythonで呼ぶことです（TypeScript実装の記事では URL.searchParams に任せています）。

まとめ

• エラーは3系統。code と message のJSONならパラメータの値、timestamp 付きなら必須パラメータやパス、HTMLならURLの組み立て（角括弧など）を疑う
• 504 Gateway Time-out は3系統の外。確認できたのは keyword でワイルドカードと演算子を併用した1例（60秒）だけで、検索式、軽いリクエスト、公式の告知の順に切り分ける
• 0件は laws が200の空配列、keyword と law_revisions が404（404001）。law_data の存在しないIDは404004
• asof は2017-04-01以降のみ（400044）。未来日付は未施行の版が返る
• response_format は Accept より優先。text/html は406。JSONとXMLを混ぜたときだけBase64
• 所得税法の全文JSONは16.4MB、gzipなら662KB。law_file は圧縮されない。30連続でもレート制限には当たらなかった

エラーを「失敗」で一括りにせず、コードごとに「条件を見直す」「IDを確定し直す」「URLを直す」と対応を分けておくと、エージェントに任せたときにも黙って別の法令で埋める挙動を防げます。その線引きは法令をAIで扱うときの安全境界の考え方と同じです。