e-Gov法令API v1からv2への移行ガイド：エンドポイント対応表と労基法での応答比較

e-Gov法令API v1からv2へ移るときは、lawlists を laws、lawdata を law_data、articles を law_data の elm 指定へ置き換えるのが基本線です。 v1の updatelawlists（更新法令一覧）だけは、日付を1つ渡す同じ形のエンドポイントがv2にありません。応答はXMLからJSONが既定になり、成否の判定も Result/Code からHTTPステータスと code に変わります。

2026年9月14日時点で、v1の提供終了や非推奨化の公式告知は確認できませんでした。 2025年3月のv2リリースのお知らせにも「法令API Version1も当面の間ご利用可能です」とあります。移行を急ぐかどうかは、v1が止まるかではなく、時点指定・改正履歴・全文検索といったv1にない機能が要るかで決まります。

この記事では、v1とv2の両方で労働基準法（法令ID 322AC0000000049）を取得し、応答の違いを実測で並べます。v2の6本の全体像はエンドポイント逆引きリファレンスにまとめています。

v1の提供終了は告知されているか

確認したのは、e-Gov法令検索のお知らせ一覧、法令API Version1の案内ページ、v1の概要ページ、v1仕様書1.4版、v2のOpenAPI定義の冒頭説明です。どこにもv1の提供終了日や非推奨化の記載はありませんでした。v2のOpenAPI定義も、v2をv1の改良版と位置づける説明にとどまります。

e-Gov法令検索の利用規約は、サイトの全部または一部を休廃止するときは原則90日前までに公表または通知すると定めています。v1を使い続ける場合も、お知らせ一覧を定期的に確認しておけば、止まる前に気づける可能性が高いと考えられます。

エンドポイント対応表

v1は4本、v2は6本です。v1の articles はURLのパスに ; 区切りでパラメータを埋め込む形でしたが、v2はすべて通常のクエリ文字列です。

lawlists の種別コードは law_type に読み替えます。v1の一覧は「公布済み現行法令」（仕様書）なので、v2では repeal_status=None を足すと件数が近づきます。

v1の lawlists/1 は1回で全件が返り、2,794,325バイトありました。v2の laws は limit の既定値が100で、next_offset を追ってページングします。全法令を毎回集める用途なら、APIを繰り返し呼ぶより公式のXML一括ダウンロードが向いています。laws の絞り込みとページングの詳細はlawsで法令一覧を絞り込む記事に分けました。

パラメータの読み替え

条・項・別表は elm で書く

同じ労働基準法第32条第2項を、v1とv2で取得しました。

# v1
curl -s "https://laws.e-gov.go.jp/api/1/articles;lawId=322AC0000000049;article=32;paragraph=2"

# v2
curl -s "https://laws.e-gov.go.jp/api/2/law_data/322AC0000000049?elm=MainProvision-Article_32-Paragraph_2&json_format=light"

どちらも「使用者は、一週間の各日については、労働者に、休憩時間を除き一日について八時間を超えて、労働させてはならない。」の1文が返りました。v1は687バイトのXML、v2は法令のメタ情報を含む1,335バイトのJSONです。

別表の指定は考え方が変わります。v1は別表名の前方一致で、候補が複数あると300 Multiple Choicesと候補リストが返る仕様でした。v2は AppdxTable[1] のように位置で指定し、角括弧は %5B1%5D にエンコードしないと400になります（逆引きリファレンスの実測）。

日付・法令番号・種別の書き方

• 日付：v1は yyyyMMdd（一覧の PromulgationDate が 19461103、updatelawlists/20260901）。v2は YYYY-MM-DD（promulgation_date、asof）です。
• 法令番号：v1は文字列だけでした。v2は law_num に加えて law_num_era（Showa など）、law_num_year、law_num_type、law_num_num に分けた値も返し、同じ名前で検索にも使えます。
• 法令種別：v1は一覧取得の数字コード1〜4だけでした。v2は Act CabinetOrder など7種類の英字を、law_type にカンマ区切りで複数指定します。

労働基準法で応答を比べる

全文を両方で取得しました。

curl -s -o v1.xml "https://laws.e-gov.go.jp/api/1/lawdata/322AC0000000049"
curl -s -o v2.json "https://laws.e-gov.go.jp/api/2/law_data/322AC0000000049"

v1は DataRoot の下に処理結果の Result と本体の ApplData が並ぶXMLです（先頭を抜粋）。

<?xml version="1.0" encoding="UTF-8"?>
<DataRoot>
  <Result>
    <Code>0</Code>
    <Message/>
  </Result>
  <ApplData>
    <LawId>322AC0000000049</LawId>
    <LawNum/>
    <LawFullText>
      <Law Lang="ja" Era="Showa" Year="22" Num="049" PromulgateMonth="04" PromulgateDay="07" LawType="Act">
        <LawNum>昭和二十二年法律第四十九号</LawNum>
        <LawBody>
          <LawTitle Kana="ろうどうきじゅんほう" Abbrev="労基法" AbbrevKana="ろ">労働基準法</LawTitle>

v2のトップレベルは attached_files_info law_info revision_info law_full_text の4つでした。本文の law_full_text は、XMLの要素名を tag、属性を attr、子要素と文字列を children に入れた木構造です（抜粋して整形）。

law_info.law_id            322AC0000000049
law_info.law_num           昭和二十二年法律第四十九号
law_info.promulgation_date 1947-04-07
revision_info.law_revision_id  322AC0000000049_20260717_508AC0000000060
revision_info.law_title    労働基準法
revision_info.abbrev       労基法

law_full_text:
{"tag": "Law", "attr": {"Lang": "ja", "Era": "Showa", "Year": "22", "Num": "049", ...},
 "children": [
   {"tag": "LawNum", "attr": {}, "children": ["昭和二十二年法律第四十九号"]},
   {"tag": "LawBody", "attr": {}, "children": [
     {"tag": "LawTitle", "attr": {"Kana": "ろうどうきじゅんほう", "Abbrev": "労基法", "AbbrevKana": "ろ"}, "children": ["労働基準法"]},
     ...

要素名はv1のXMLと同じなので、v1で Article や Paragraph を名前でたどっていた処理は、tag で同じ木をたどる形に書き換えられます。json_format=light を付けると {"Article": {"ArticleTitle": …}} のような読みやすい形になります。ただしOpenAPI定義は、法令本文取得APIが返すJSON形式のデータを試行版で仕様変更がありうると注記しています。

v2でXMLのまま受け取る2つの方法

XMLのパーサーを残したい場合、v2には2つの道があります。

1. response_format=xml：ルート要素が law_data_response になり、その下に law_info revision_info law_full_text がXML要素で並びます。v1の DataRoot や Result/Code はありません。
2. law_file/xml/{法令ID}：労働基準法で398,337バイト、Content-Typeは application/octet-stream でした。先頭は <?xml version="1.0" encoding="UTF-8" standalone="no"?> の直後に Law 要素が来るので、v1の LawFullText の下の Law から読んでいた処理を流用しやすい形です。

外側の response_format と本文の law_full_text_format を食い違わせると本文がBase64になります。条件と見分け方はエラーコードと制限の記事にあります。

エラーと0件の返り方

存在しない法令ID（322AC9999999999）を両方に投げました。どちらもHTTP 404です。

<?xml version="1.0" encoding="UTF-8"?>
<DataRoot>
  <Result>
    <Code>1</Code>
    <Message>取得結果が０件でした。取得条件に誤りがないかご確認ください。</Message>
  </Result>
  <ApplData>
    <LawId>322AC9999999999</LawId>
    <LawNum/>
    <LawFullText/>
  </ApplData>
</DataRoot>

{"code":"404004","message":"指定のパラメータで取得できる法令本文ファイルは存在しません。"}

v1で Code だけを見て分岐していたコードは、v2ではHTTPステータスで分岐し、404のときに code を見て「0件」（404001）と「本文が無い」（404004）を分ける形に直します。

法令ID・法令番号の扱い

v1もv2も、本文取得のパスには法令IDと法令番号のどちらでも置けます。違いは応答側に出ます。

• v1は受け取った方しか返しません。 法令番号で lawdata を呼ぶと応答の LawId は空、法令IDで呼ぶと LawNum が空でした。応答から法令IDを読んでいた処理は、番号で呼んだときに壊れます。
• v2は law_info にまとめて返します。 law_id law_num law_num_era law_num_year law_num_type law_num_num promulgation_date が並びます。
• 法令名は revision_info に移りました。 改正で題名が変わることがあるためで、同じ法令IDでも版ごとに law_title が変わります（asof指定の記事で改題前後を確認しています）。
• 版を固定するなら履歴ID。 322AC0000000049_20260717_508AC0000000060 は「法令ID_施行日_改正法令ID」の形で、新規制定のままの版は末尾が 000000000000000 になります。

v1の仕様書には、法令番号が重複する法令は articles で法令番号を指定しても取得できず、法令IDで指定するよう書かれています。v2でも法令IDでの指定を基本にしておくのが安全です。

v1でできて、v2では書き方が変わる操作

• 一覧の一括取得：v1は1回で全件。v2は limit と offset でページングします。
• 図の画像：v1は画像を pict フォルダのZIPにしてBase64で ImageData に入れる仕様でした。v2は attachment/{履歴ID} で個別ファイルを取るか、law_data に include_attached_file_content=true を付けます。
• 更新法令一覧：v1の updatelawlists/20260901 は39件・38,161バイトのXMLで、法令ごとに改正法令名・施行日・LawUrl などが返りました（先頭は道路交通法施行令、施行日20260901）。v2に同じ形はありません。法令ごとなら law_revisions の updated_from / updated_to、まとめてならOpenAPI定義が案内する一括ダウンロードの file_section=3&update_date=YYYYMMDD（取得範囲は過去3か月）が候補です。一括ダウンロードは本記事では試していません。
• MCPサーバー：@codeagentjp/egov-law-mcp 0.1.0は /api/1/ 系だけを呼んでいました（2026年7月27日時点、asof指定の記事）。通称で0件になる問題は通称と法令名のズレの記事で扱っています。

移行チェックリスト

• コード内の /api/1/lawlists/ /api/1/lawdata/ /api/1/articles; /api/1/updatelawlists/ を洗い出した
• 旧ホスト elaws.e-gov.go.jp を使っていないか確認した（v1仕様書1.4版でホスト名が変更されている）
• 一覧取得を laws?law_type=…&repeal_status=None に置き換え、next_offset のキーが無くなるまでページングする
• articles の条・項を elm=MainProvision-Article_N-Paragraph_M に置き換え、枝番は Article_N_M にした
• 日付の読み書きを yyyyMMdd から YYYY-MM-DD に直した
• 成否判定を Result/Code からHTTPステータスと code（404001 / 404004 / 400系）に直した
• 応答の法令IDは law_info.law_id、法令名は revision_info.law_title から読むようにした
• 本文をJSONで受けるか、response_format=xml か law_file/xml でXMLのまま受けるか決めた（JSONは試行版の注記あり）
• response_format と law_full_text_format を食い違わせていない（Base64になる）
• 図は attachment に、更新法令一覧は law_revisions か一括ダウンロードに置き換える方針を決めた
• 取得結果に law_revision_id を保存するようにした
• 公開する成果物に出典を記載した（利用規約はコンテンツに公共データ利用規約 PDL1.0 を適用し、出典の記載と、編集・加工した場合はその旨の記載を求めている）

まとめ

• 2026年9月14日時点で、e-Gov法令API v1の提供終了・非推奨化の公式告知は確認できなかった。v2リリース時のお知らせはv1も当面利用可能としている
• v1の lawlists は laws、lawdata は law_data、articles は law_data の elm に置き換える。updatelawlists には直接の後継がない
• 憲法・法律の一覧はv1とv2で2,104件が一致した。v2は limit 既定100のページング
• 応答はXMLの Result/Code から、JSONとHTTPステータス・code へ。日付形式と、法令名の位置（revision_info）も変わる
• v2の本文JSONは試行版。XMLで受けたいなら response_format=xml か law_file/xml

パラメータを組み立てながらv2のURLを試すならe-Gov法令APIリクエストビルダー、Claude Codeから条文を引く運用全体はe-Gov法令API活用ガイドから辿れます。