本文へスキップ
Edition · Tokyo

その条文は「現在」のものです|e-Gov法令API v2の時点指定(asof)と通称検索を実測

e-Gov法令API v2はasofパラメータで過去時点の条文を返し、法令名検索が通称(abbrev)にもマッチします。v1しか叩いていないegov-law-mcp 0.1.0では何が引けないのかを、下請法の改題を題材に実測ログで確認します。

codeagent.jp編集部 情報確認 約5分
Tags
情報確認
参考リンク
5件
更新性
定期更新
読了目安
約5分
更新管理

仕様・料金・提供範囲が変わりやすいテーマは、公開日・更新日・情報確認日を分けて管理します。 導入前には必ず記事末尾の一次情報と公式ドキュメントで最新状況を確認してください。

検証メモ
@codeagentjp/egov-law-mcp 0.1.0 e-Gov 法令API v1 / v2 curl 実行日 2026-07-27
その条文は「現在」のものです|e-Gov法令API v2の時点指定(asof)と通称検索を実測 の16:9共有用サマリー画像。 v2はasofで過去時点の条文を返し、法令名検索が通称にもマッチする。v1実装のMCPはそのどちらも使えない 1. 何が引けないか: v1には時点指定がなく、返るのは常に現行条文、改題・改正前の条文をMCP経由では取得できない、エラーにならず現行が返るため誤りに気づきにくい 2. v2で確認できたこと: asof=2025-06-01で改題前リビジョンが返った、法令名検索がabbrev(通称)にマッチし労基法は9件、law_revisionsで改題履歴と施行日を追える 3. 当面の運用: 過去時点が要る調査はMCPに任せずv2を直接叩く、取得した条文には必ずリビジョンIDを併記する、通称はv2でも万能ではなく電帳法は0件のまま
その条文は「現在」のものです|e-Gov法令API v2の時点指定(asof)と通称検索を実測 資料 26-GGQX 2026.07.27 運用Tips・トラブルシュート

前回、「下請法」で法令検索すると0件になるで、法令は改題されるのでlawIdで追うべきだと書きました。そこで次の疑問が出ます。改題される前の条文そのものは、どうやって引くのか。

2025年6月に締結した契約をいま点検するなら、参照すべきは当時の条文です。ところが@codeagentjp/egov-law-mcp 0.1.0 に過去の日付を伝えても、返ってくるのは現行条文です。エラーは出ません。黙って「今」が返ります。

この記事は、e-Gov法令API v1とv2に実際にリクエストを投げて、その差を確認した記録です。

まず結論

  1. v1には時点指定がない。 MCP 0.1.0が叩いているのは /api/1/ 系のみで、返るのは常に現行条文です。
  2. v2には asof がある。 asof=2025-06-01 を付けると、改題前のリビジョンが返りました。
  3. v2は通称も持っている。 法令名検索が abbrev にマッチし、v1で0件だった労基法・景表法・個人情報保護法が引けます。
  4. ただし黙って現行が返るのが一番危ない。 過去を指定したつもりで現行を読んでいても、出力は正常に見えます。

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

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

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

Terminal window
# 現行(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 で一覧できます。

Terminal window
curl -s "https://laws.e-gov.go.jp/api/2/law_revisions/331AC0000000120"
  1. 1956-06-01
    公布
    昭和三十一年法律第百二十号。以後lawId 331AC0000000120は不変
  2. 2025-05-23
    改正法が公布
    令和七年法律第四十一号。この時点の題名はまだ「下請代金支払遅延等防止法」
  3. 2026-01-01
    改題が施行
    「製造委託等に係る中小受託事業者に対する代金の支払の遅延等の防止に関する法律」へ。current_revision_status は CurrentEnforced
law_revisions/331AC0000000120 のレスポンスより(2026-07-27取得)

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

v2は通称を知っている

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

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

4 / 6
v2でヒットした通称
v1経由では0 / 6だった同じ6語
9件
「労基法」の結果
労働基準法・同施行規則ほか
0件
「電帳法」の結果
abbrevに登録がなく v2 でも引けない
4項目
v1法令一覧のフィールド
LawId / LawName / LawNo / PromulgationDate のみ
https://laws.e-gov.go.jp/api/2/laws?law_title=<通称> を実行(2026-07-27)

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

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

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

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

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

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

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

v1とv2で何が違うのか

法令API v1(MCP 0.1.0が使用)
法令API v2
時点指定
なし。常に現行条文
asof=YYYY-MM-DD で過去時点を取得
改正履歴
専用の取得手段なし
law_revisions でリビジョン一覧
通称での検索
不可(一覧にabbrevがない)
法令名検索がabbrevにマッチ
法令一覧の項目
LawId / LawName / LawNo / PromulgationDate
abbrev・施行日・廃止状態などを含む
レスポンス形式
XML
JSON
2026-07-27時点で実際にリクエストして確認した範囲

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は黙って嘘をつきます。その条文が「いつのものか」を出力に残す——時点が効く調査で最初に決めるべきはそこでした。

Primary sources

一次情報・参考リンク

About the author
codeagent.jp編集部

Claude Code / Codex / MCP を個人開発サイト運用と公開MCPサーバー開発で試し、一次情報・検証ログ・失敗例をもとに整理します。

関連して読む