e-Gov法令API v2のasof指定：過去の条文取得と通称検索の使い方

e-Gov法令API v2で過去時点の条文を取得するには、法令IDを指定した law_data に asof=YYYY-MM-DD を付けます。 応答のリビジョンIDも保存すると、どの版を取得したかを後から確認できます。

この記事では、同じ法令IDに対して日付の有無だけを変えるcurlの例と、通称検索で目的の法令が見つからない場合の確認方法を紹介します。法令名からIDを探す段階で困った場合は、通称・改題による検索漏れの調べ方から読めます。

Pythonで実行したい場合は、法令検索からJSON・XML保存まで動かすサンプルを用意しています。この記事の時点指定を、ダウンロードしたコードでも試せます。

最初に確認すること：法令ID・基準日・リビジョン

asofで改題前後を引き分ける

題材は前回と同じ、2026年1月1日に改題された昭和三十一年法律第百二十号（旧・下請代金支払遅延等防止法）です。lawIdは 331AC0000000120 のまま変わりません。

同じlawIdに対し、asof の有無だけを変えて2回叩きます。

# 現行（asofなし）
curl -s "https://laws.e-gov.go.jp/api/2/law_data/331AC0000000120"

# 2025年6月1日時点
curl -s "https://laws.e-gov.go.jp/api/2/law_data/331AC0000000120?asof=2025-06-01"

返ってきた revision_info のリビジョンIDが、はっきり分かれました。

asofなし        -> 331AC0000000120_20260101_507AC0000000041
                   製造委託等に係る中小受託事業者に対する代金の支払の遅延等の防止に関する法律

asof=2025-06-01 -> 331AC0000000120_20250523_507AC0000000041
                   下請代金支払遅延等防止法

同じlawIdから、改題後と改題前の両方が取れています。リビジョンIDの中央8桁がそのまま適用時点で、末尾は改正法のIDです。

改正履歴は law_revisions で一覧できます。

curl -s "https://laws.e-gov.go.jp/api/2/law_revisions/331AC0000000120"

amendment_enforcement_date と amendment_promulgate_date が別々に入っているのが実務では効きます。公布日と施行日がずれる以上、「いつの条文か」は施行日で決まります。

v2は通称を知っている

もうひとつ、v1との差が大きかったのが法令名検索です。v2の法令一覧は abbrev フィールドを持っており、法令名での検索がここにもマッチします。

前回v1（正確にはv1の法令一覧をクライアント側で名前照合するMCPの実装）で0件だった通称6語を、v2の laws エンドポイントに投げ直しました。

ヒットしたものは、通称がそのまま abbrev に入っています。

景表法          -> 3件  不当景品類及び不当表示防止法        abbrev=景表法,景品表示法
労基法          -> 9件  労働基準法                          abbrev=労基法
個人情報保護法  -> 8件  個人情報の保護に関する法律          abbrev=個人情報保護法
フリーランス    -> 1件  特定受託事業者に係る取引の適正化等に関する法律
                                                            abbrev=フリーランス・事業者間取引適正化等法

前回の記事では「通称と正式名称の対応表をCLAUDE.mdに常駐させる」という運用でしのぐ、と書きました。v2に上げれば、その手作業の大半はAPI側が持っている辞書で置き換えられます。

ただし「下請法」は本法に当たらない

例外がそのまま今回の題材でした。通称「下請法」で引くと、返るのは本法ではなく政令1件です。

下請法 -> 1件
  製造委託等に係る中小受託事業者に対する代金の支払の遅延等の防止に関する法律
  第二条第八項第一号の情報成果物及び役務を定める政令   abbrev=下請法施行令

本法の abbrev は改題にあわせて 取適法,中小受託取引適正化法 へ更新済みですが、政令側は 下請法施行令 のまま残っています。通称の更新タイミングは法令ごとにばらけるわけです。結局ここでも、確実なのはlawIdでの直接指定でした。

v1とv2で何が違うのか

MCP 0.1.0 のソースを見ると、組み立てているパスは /api/1/lawlists/、/api/1/lawdata/、/api/1/articles; の3系統で、asof に相当するパラメータはどこにも渡していません。v2固有の機能が使えないのは設定の問題ではなく、実装がv1に閉じているためです。

当面どう運用するか

MCPをv2対応に上げるまでの現実的な線引きは、この3つでした。

1. 現行条文の調査はMCPのままでよい。 大半の用途は「いまどうなっているか」で足ります。
2. 時点が効く調査はv2を直接叩く。 契約締結時点、届出時点、事故発生時点をまたぐ調査はMCPに任せません。law_data/<lawId>?asof=<日付> の1本で足ります。
3. 取得結果にはリビジョンIDを残す。 331AC0000000120_20250523_507AC0000000041 の形で残っていれば、後からどの時点の条文を読んだのか検証できます。

エージェントに渡す指示としては、前回の指示文に1行足すだけです。

- 条文を引いたら law_revision_id を必ず併記する
- 過去時点の条文が必要な場合、MCPでは取得できないと明示して止まる
  （推測で現行条文を過去のものとして扱わない）

「取得できないときに止まる」を明示しておくのは、MCPが動かない時の切り分けと同じ発想です。埋めさせないことが、外部データを繋ぐ目的そのものです。

まとめ

• MCP 0.1.0 が使っているe-Gov法令API v1には時点指定がなく、返るのは常に現行条文
• v2の asof=YYYY-MM-DD で過去リビジョンを取得できる。同じlawIdから改題前後の両方が取れた
• v2は abbrev（通称）を持ち、v1で0件だった労基法・景表法・個人情報保護法が引ける。電帳法は0件のまま
• 通称の更新は法令ごとにばらつく。「下請法」では政令だけが返る。確実なのはlawId指定

過去の条文を引く必要が出た時点で、v1のままのMCPは黙って嘘をつきます。その条文が「いつのものか」を出力に残す——時点が効く調査で最初に決めるべきはそこでした。