規制動向調査のやり方｜確定度で分ける一次ソースと、条項を落とさないAIの使い方

この記事の要点

規制動向調査で本当に痛い失敗は、情報を取り逃したときではなく、取ってきた条文を読み違えたときに起きます。禁止事項は目立つ位置にまとまって置かれるのに、例外や適用除外はサブ条項（条文の中の枝分かれした細かい項目）に散らばるからです。

一次ソース（規制を出している側が直接公開している元の文書）を、ひとまとめに追いかけてはいけません。「決まった条文」「まだ決まっていない案」「運用の解釈」の3つに分け、それぞれ見る頻度もAIの使い方も変えてください。3つは更新の速さも、間違えたときの損害の大きさも違います。

追いかける日付は公布日ではなく施行日です。EU AI法（Regulation (EU) 2024/1689）は、同じ1本の規則なのに条項ごとに効き始める日が4つに分かれています。しかも2026年7月27日発効の改正規則で、そのうちの1つが2027年8月2日から2028年8月2日へ動きました。2024年に作った一覧表をそのまま使うと間違えます。

AIに規制文書を読ませるときは、「該当箇所を抜き出して」と頼まないでください。「この節のサブ条項を全部列挙して」と頼みます。法律分野の推論力を測るLegalBenchという評価セットでは、GPT-4は結論を出すタスクで89.9%の正答率を出す一方、どの条文が当てはまるかを想起するタスクでは59.2%まで落ちています。得意なところと苦手なところが、同じモデルの中ではっきり分かれています。

日本語の解説記事だけで判断すると、条項の適用範囲を取り違えます。e-Gov法令API、EUR-LexのCELEX番号、Federal Register APIは、いずれも登録なしで一次条文そのものを取れます。解説を読むのは構いませんが、判定の根拠は原文に置いてください。

つまずくのは情報が見つからないときではなく、読み違えたときです

規制動向調査の話をすると、たいてい最初に出てくるのは「量が多すぎて追いきれない」という悩みです。数字で見ると確かにそのとおりで、Thomson Reutersが2023年に出したCost of Complianceレポートによれば、同社が2022年に監視した規制関連の出来事は61,228件ありました。190の国と1,374の規制当局が対象で、1営業日あたりに直すと平均234件です。

PwCが2025年に63の国と地域の経営層1,802名に聞いたGlobal Compliance Surveyでは、85%が「過去3年でコンプライアンス要件が複雑になった」と答えています。63%は「組織内のデータが複雑で分散していることが障害だ」と答えました。

でも、私が実務で本当に痛い目にあったのは、量が多くて取り逃したときではありませんでした。取ってきた文書を読み違えたときです。

1つのサブ条項を読み飛ばして、結論が180度ひっくり返った話

以前、あるソフトウェアのライセンス条項を読んで「この使い方は許されていない」と判定したことがあります。禁止事項の節を読み、作者が公開の場で述べていた説明も確認したうえでの結論でした。

その判定は間違っていました。権利を与える側の節に、条件つきで許可するサブ条項が1つあり、それを読んでいませんでした。禁止事項の節は目立つ位置にまとまっていたので目に入ったのに、許可の例外は枝分かれした細かい項目の中に埋もれていて、そこまで開かなかったのです。

厄介だったのは、間違いが静かに広がったことです。誤った結論だけが独り歩きして、社内の説明資料とドキュメント数本、それから対外的な説明にまで乗ってから発覚しました。読めていなかった分量は全体の1割にも満たないのに、結論は正反対でした。

規制文書には、読み落としを誘う構造のクセがあります

あとから考えると、この失敗は私の不注意というだけではなく、条項で構成された文書に共通する構造から来ていた気がします。

禁止事項や義務は、読み手に伝わらないと困るので、まとまった位置に置かれます。一方で例外・適用除外・経過措置は、原則を述べたあとに枝分かれしてぶら下がる形になります。原則だけを読んで判定すると、その枝を全部見落とします。

AIに読ませても、この構造の問題は自動では解けるわけではありません。スタンフォード大学の研究チームが2024年に発表したHallucination-Free?（Journal of Empirical Legal Studies 22巻2号に掲載）では、法務専門の検索AIツールを202件の事前登録した質問で試したところ、ツールによって17%から33%の割合で誤った内容を生成しました。汎用の生成AIではなく、法律文書に特化して作られたツールでの数字です。

ですから、規制動向調査の設計で最初に決めるべきは「どうやって取り逃さないか」ではありません。「取ってきた条文をどう読むか」です。以降では、そのための手順を3つに分けて書いていきます。

一次ソースは「どこまで決まっているか」で3つに分けます

一次ソースというのは、規制を出している側が直接公開している元の文書のことです。新聞記事やコンサルティング会社の解説は、そこから作られた二次情報にあたります。

規制情報をひとまとめにして追いかけると、更新の速さも重要度もバラバラなものが混ざって、すぐに手に負えなくなります。いろいろ試したすえに私が落ち着いたのは、確定度、言い換えると「どこまで決まっているか」で3つに分ける方法でした。3つは更新頻度が違い、間違えたときの損害の大きさも違うので、見る頻度もAIの使い方も変えます。

層	中身	日本の入口	海外の入口	見る頻度の目安
決まった条文	公布・掲載された法令の本文	e-Gov法令検索、官報	EUR-Lex（EUの法令データベース）のOfficial Journal（EUの官報）L系列、govinfo（米国政府の公式出版物サイト）	月1回。ただし自社に効く条項は施行日の前に必ず
まだ決まっていない案	意見公募中の案、審議会資料、規則案	e-Govパブリック・コメント、各省庁の審議会	Federal Register（米国の官報）のProposed Rules（規則案）、Unified Agenda（各省庁が今後出す予定の規制の一覧）	週1回
運用の解釈	ガイドライン、質疑応答集、告示、処分事例	各省庁サイト、官報	各当局サイト	月1回。該当分野で動きがあれば都度

層1｜決まった条文は、正本がどこにあるかを押さえます

日本で法令の本文を読む入口はe-Gov法令検索です。デジタル庁が運営しています。

収録されている法令は、2025年4月1日時点で9,354件です。内訳は憲法1件、法律2,143件、政令2,383件、勅令71件、府省令4,313件、規則443件とデジタル庁の資料に書かれています。同じ資料によれば、2022年10月から原則として公布日と同じ日に法令データを更新するフローが動いています。公布のニュースを見た日に本文を確認できる、という意味です。

正本、つまり法的に正式な原本がどこにあるかも押さえてください。日本では2025年4月1日に「官報の発行に関する法律」（令和5年法律第85号）が施行され、官報発行サイトに掲載される電子データが正本になりました。同法第6条により、公布はサイトに掲載する措置がとられた時点で行われたことになります。発行から90日間は無料で閲覧できますが、このサイトに検索機能はありません。過去分をキーワードで探すには国立印刷局の有料サービスを使うか、e-Gov法令検索を併用します。

米国では、読みやすいfederalregister.govと、法的な効力を持つgovinfo.govが別物です。federalregister.gov 自身が「公式版ではない」とページ下部に明記しています。日々の把握には前者、根拠として引くときは後者、と使い分けます。

EUでは、Official Journal（EUの官報）の電子版だけが正本です。Council Regulation (EU) No 216/2013 の第1条第2項がそう定めていて、2013年7月1日から効いています。

層2｜まだ決まっていない案は、意見を言える期間が決まっています

日本で規制の案が出るとき、政令や府省令などについては意見公募手続（パブリックコメント）が行政手続法で義務づけられています。同法第39条第3項は、意見の提出期間を「公示の日から起算して30日以上」と定めています。第40条第1項にはやむを得ない場合に30日を下回れる例外がありますが、その場合は理由を明らかにしなければなりません。

この層で見落とされやすいのが、第43条第1項です。行政機関は、命令等を公布するのと同じ時期に、提出された意見と、それを考慮した結果（案と実際に定めた内容の差を含む）を公示しなければなりません。ここを読むと、条文がどこでどう変わったかと、その理由が並んでいます。案の段階と確定版の差分を人力で取る必要はありません。入口はe-Govパブリック・コメントです。

米国では、規則案（Proposed Rule）が Federal Register に載り、regulations.gov でコメントを受け付けます。私たちが2026年8月3日にFederal RegisterのAPIで数えたところ、2025年に公示された Proposed Rule は1,498件、Final Rule は2,441件でした。さらに先を読むなら、年2回（春と秋）公表されるUnified Agendaに、各省庁がこれから出す予定の規則が並びます。

審議会・部会の資料も、この層に入ります。日本では平成11年4月27日の閣議決定で「会議または議事録を速やかに公開する」と決まっていますが、何日以内という基準はありません。実際、厚生労働省の薬事審議会のページを2026年8月3日に見ると、開催案内だけが載っている回、資料まで載っている回、議事録まで揃った回が混在しています。掲載は「開催案内、資料、議事録」の順に埋まっていくので、資料が出た時点で拾えば議事録を待たずに動けます。

層3｜運用の解釈は、条文検索では出てきません

ガイドラインや質疑応答集は、条文そのものではないのに実務を左右します。しかも探しにくい層です。

わかりやすい例が告示です。告示は e-Gov法令検索に収載されていません。デジタル庁は前掲の資料で、2026年度中を目途に告示のデータ提供を始めることを目指すとしています。裏を返すと、それまでは省庁のサイトか官報を直接見るしかありません。「e-Gov法令検索で見つからなかったので存在しない」と結論を出すと、この層をまるごと落とします。

追いかけるのは公布日ではなく施行日です

規制のニュースは「◯◯法が成立しました」「△△規則が公布されました」と流れてきます。ところが、この日付を追いかけても自社の準備には使えません。準備の締め切りを決めるのは施行日のほうだからです。

公布は「こういう法令ができましたと世の中に知らせること」、施行は「その法令が実際に効き始めること」です。日本では国会法第66条により、法律は奏上の日から30日以内に公布しなければなりません。そして施行日は、通常その法律の附則（本文のうしろに付く補足の条文）で定められます。公布から施行まで1年以上空くことも珍しくありません。

e-Gov法令検索は、この施行日を機械で読める形で持っています。2025年3月に提供が始まった法令API Version 2は登録もAPIキーも不要で、改正の公布日、施行日、施行予定日をフィールドとして返します。私たちが2026年8月3日に「官報の発行に関する法律」の改正履歴を取得したところ、施行予定日2026年12月31日の未施行版が入っていて、「防災庁設置法（令和八年法律第六十一号）の施行の日」という条件つきの注記も一緒に返ってきました。

同じ規則でも、条項ごとに効き始める日が違います

ここまでは「1本の法令に施行日が1つ」という前提で書きました。実際にはそうならないことがあります。

EU AI法（Regulation (EU) 2024/1689）が典型例です。この規則のArticle 113は、次のように枝分かれしています。

日付	根拠	対象
2024年8月1日	Article 113 第1段落	発効。官報掲載（2024年7月12日）の20日後
2025年2月2日	第3段落 (a)	Chapter I（総則）と Chapter II（禁止されるAI慣行）
2025年8月2日	第3段落 (b)	Chapter V（汎用AIモデル）ほか。ただしArticle 101は除外
2026年8月2日	第2段落	一般適用。上の例外に当てはまらないすべての規定
2027年8月2日	第3段落 (c)	Article 6(1)、製品に組み込まれる高リスクAI

Article 113は、まず第1段落で発効日を、第2段落で一般適用日を決めて、そのあと第3段落の(a)(b)(c)で例外を並べる構造になっています。ここを見ずに「EU AI法は2026年8月2日から」という一文だけを覚えると、2025年2月にすでに効いていた禁止規定を1年半見落とします。

もう1つ細かい点があります。(b)は汎用AIモデルの規定を2025年8月2日から適用すると書きながら、その違反に対する制裁金の条文であるArticle 101だけを明示的に除いています。義務は先に立ち上がり、罰則は一般適用日まで待つ、という時間差がサブ条項の中で作られています。

そして、確定した日付があとから動きます

ここからが、この記事でいちばん伝えたい部分です。

2026年7月8日に署名され、7月24日に官報に掲載され、7月27日に発効した Regulation (EU) 2026/1744（Digital Omnibus on AI、AI関連ルールの簡素化をまとめた改正規則）が、このArticle 113を書き換えました。元になった提案はCOM(2025) 836 final（2025年11月19日）で、そこから半年あまりで確定しています。

改正後はこうなりました。

• (c)が丸ごと差し替えられ、高リスクAIに関するChapter III Sections 1〜3は、Annex III型（生体認証、重要インフラ、教育、雇用など単独で動くもの）が2027年12月2日、Annex I型（医療機器や機械など製品に組み込まれるもの）が2028年8月2日になりました
• (a)に但書が付き、新しく追加された禁止行為は2026年12月2日からになりました
• (d)が新設され、他のEU法令を改正する条文（Articles 102から110）は2026年7月27日から効いています
• 一方で(b)は改正されていません。汎用AIモデルの2025年8月2日は動いていません
• 第2段落の一般適用日2026年8月2日も動いていません

制定時に「2027年8月2日」と書かれていた製品組み込み型の高リスクAIは、いま調べると2028年8月2日です。2024年に作った一覧表をそのまま社内で配っていたら、1年ずれた期限で準備を進めることになります。

米国にも似た構造があります。連邦行政手続法（5 U.S.C. § 553）の(d)は「実質的な規則は施行日の30日以上前に公布する」と定めていますが、これに加えて、議会審査法（Congressional Review Act、5 U.S.C. § 801(a)(3)）が経済的影響の大きい規則（major rule）について、議会が報告を受けた日かFederal Register掲載日の遅いほうから60日という別の待機期間を課しています。30日の条文だけを見て準備すると、実際の施行日を1か月間違えます。

施行日から逆算して、見る対象を絞ります

日付が条項ごとに違い、あとから動くのなら、やることは決まります。

1. 自社の製品・サービスに効く条項を特定する。規則1本ではなく条項単位で書き出します
2. その条項の適用開始日を、条文の施行規定（EU AI法ならArticle 113）から直接読む。解説記事の一覧表を写さない
3. 経過措置があれば、その終わりの日も一緒に控える
4. 適用開始日そのものを監視対象にする。EUならCELEX番号で条文の日付情報を定期取得できますし、日本なら法令APIの施行予定日フィールドが同じ役割を果たします

4番目が抜けやすいところです。条文の中身が変わったかどうかだけを見ていると、中身は同じで日付だけが動いた改正を検知できません。

条項は、サブ条項を全部並べてから判定します

ここがこの記事の芯です。要点を先に書くと、AIへの指示を「該当箇所を抜き出して」から「この節のサブ条項を全部列挙して」に変えてください。LegalBenchという評価セットの測定では、GPT-4は結論を導くタスクで89.9%、どの条文が当てはまるかを想起するタスクで59.2%と、30ポイントの差が出ています。苦手なほうを人間の指示で補う形にします。

規制文書を読んで「自社は該当するか」を判定するとき、該当しそうな条項だけを開いて読むと、かなりの確率で間違えます。原則を述べる本文は見つけやすいのに、例外はそのうしろに枝分かれしてぶら下がるからです。

米国の条文で、枝分かれの実物を見てみます

連邦行政手続法 5 U.S.C. § 553(d) の本文はこうなっています。米国政府出版局（GPO）の公式版から引くと、実質的な規則の公布は施行日の30日以上前に行わなければならない、と書かれています。

ここで読むのをやめると「米国の規則は必ず公布の30日後以降に施行される」と理解します。でも、この一文のうしろには例外が3つぶら下がっています。

• (d)(1) 免除を与える、または制限を緩和する規則
• (d)(2) 解釈規則および政策声明
• (d)(3) 行政機関がgood cause（相当の理由）を認定し、規則とともに公表したもの

(d)(1)は「規制を緩める方向の規則」です。緩める規則は即日効いてよい、という非対称がここに書かれています。(d)(3)にいたっては、省庁側が理由を書けば30日ルールを外せます。3つとも、原則の直後に並んでいるだけで、見出しも付いていません。

同じ条文の中で、採番のしかたが変わる点も引っかけになります。(b)の例外は(A)(B)というアルファベット、(d)の例外は(1)(2)(3)という数字です。「553(b)(1)」と書くと、それは例外ではなく、規則案に書くべき記載事項の1番目を指します。条項番号を写すときに、どの階層の記号かを確認しないと参照先がずれます。

なお、パブリックコメントの期間についてもここで補足しておきます。5 U.S.C. § 553は日数を定めていません。「60日以上が望ましい」と書いているのは大統領令12866の第6条(a)(1)です。しかも原文の言い回しは「望ましい」にあたる語で、義務ではなく努力目標です。「米国のコメント期間は法律で60日と決まっている」という説明を見たら、条文にあたって確かめてください。

AIへの指示は「抜き出して」ではなく「全部列挙して」に変えます

この構造がわかると、AIへの頼み方も変わります。

やりがちなのは、次のような指示です。

この規制文書のうち、当社の製品に該当する部分を抜き出して要約してください。

これは、いちばん間違えやすい形です。AIが「該当しそうにない」と判断した枝は、要約に出てきません。しかも出てこなかったことは、こちらからは見えません。

代わりに、次のように頼みます。

以下の節について、次の2ステップで作業してください。判定は必ずステップ2で行ってください。

ステップ1: この節に含まれるサブ条項を、(a)(b)(c)... または (1)(2)(3)... の
記号のとおりに1つ残らず列挙してください。省略・統合・要約はしないでください。
サブ条項がさらに枝分かれしている場合は、その階層も展開してください。

ステップ2: ステップ1で列挙した各サブ条項について、次の3つを表にしてください。
  - 当社（事業内容: ○○）に適用されるか（適用される / 適用されない / 判断できない）
  - そう判断した理由を、条文の文言を引用しながら1〜2行で
  - 判断に必要な情報が条文にない場合は「判断できない」とし、何が足りないかを書く

条文に書かれていないことは推測しないでください。

違うのは「抜き出す」と「列挙する」の1語だけですが、返ってくるものの性質が変わります。前者だと、AIが取捨選択した結果しか手元に残りません。後者だと、まず全部の枝が目に見える形で並び、そのあとで判定が付きます。判定が怪しいサブ条項があっても、こちらが気づけます。指示を1語変えるだけでここまで変わるのかと、私も試して驚いた部分です。

なぜこの頼み方が効くのか、測定された数字で確認します

「気分の問題ではないのか」と思われるかもしれないので、実測を3つ挙げます。

1つ目はLegalBenchです。法律専門家40名が162個のタスクを作った評価セットで、GPT-4のスコアはタスクの種類でこれだけ差が出ました。

タスクの種類	GPT-4のスコア
結論を導く	89.9%
争点を見つける	82.9%
規範を当てはめる	82.2%
法文を解釈する	75.2%
どの規範が当てはまるかを想起する	59.2%

いちばん下の「どの規範が当てはまるかを想起する」が、他から30ポイント離れて低いところが要点です。結論を出すのは得意なのに、根拠になる条文を正しく引くのは苦手、という非対称が同じモデルの中にあります。だからこそ、条文の列挙という苦手な部分を人間が指示で強制し、結論はモデルに任せる分業が効きます。

2つ目はLost in the Middle（計算言語学の学術誌TACLの2024年掲載論文）です。複数の文書を渡して質問に答えさせる実験で、正解が入っている文書を置く位置を変えたときの正答率を測っています。GPT-3.5-Turboの結果は次のとおりでした。

設定	先頭に置いたとき	中間に置いたとき	末尾に置いたとき
20文書	75.8%	53.8%	63.2%
30文書	73.4%	50.9%	63.7%

同じ論文で、文書を1つも渡さずに答えさせたときの正答率が56.1%、正解の文書1つだけを渡したときが88.3%でした。20文書と30文書の中間位置は、どちらも「文書を渡さないほうがマシ」だった水準を下回っています。長い規制文書の真ん中に埋まったサブ条項は、ちょうどこの位置にあります。

3つ目はFABLESという評価データセットを使った研究です。本を最後まで読んだ人間が、AIの作った要約を1文ずつ検証したもので、Claude-3-Opusは主張の90.89%が原文に忠実という最良の成績でした。ところが同じ研究で、何らかの欠落があった要約の割合は、モデルによって52.0%から84.6%でした。いちばん成績の良いモデルでも、要約の半分以上で何かが落ちています。「嘘を書かない」ことと「条件や例外を落とさない」ことは別の性能です。

検索で条文を取ってくる仕組みにも、同じ落とし穴があります

社内文書とAIをつないで質問できるようにする仕組み（RAG、検索した文書を読ませてから答えさせる方式）を規制文書に使う場合、もう1段の注意が要ります。

2025年に発表されたこの研究は、法令や契約のように「似た構造の文書が大量にある」コーパスで起きる失敗を測りました。秘密保持契約のデータセットでは、検索上位に出てきたチャンク（文書を細切れにした断片）のうち、正解が入っている文書とは別の文書から取ってきたものの割合が95%を超えました。各チャンクの先頭に、その文書の要約を150字ほど付け足すだけでこの割合が約半分になり、正解を拾える率が18から20ポイント改善しています。

チャンクの切り方そのものも効きます。2026年3月に出た36通りの分割方法を比較した研究では、段落のまとまりを保って切る方式が上位1件の的中率で約24%だったのに対し、決まった文字数で機械的に切る方式は約2から3%でした。条文の途中で切ると、原則と例外が別のチャンクに分かれます。片方だけが検索に引っかかれば、当然読み落とします。

実務のチェック手順にすると4つです

以上をまとめると、規制文書を読む手順はこうなります。

1. 判定の対象になる節を決めたら、まずサブ条項を全部並べる。AIに頼むなら「列挙」を明示し、「省略しない」と書き添える
2. 並べた各サブ条項について、適用の有無と理由を1行ずつ書く。ここでAIの下書きを使ってよいが、「判断できない」を返す余地を必ず残す
3. 判定表の各行に、根拠の条項番号を階層まで書く。「553(d)(3)」のように、どの枝かがわかる形で残す
4. 読んだ条項の一覧を、判定表とは別に残す。どこを読んで、どこを読んでいないかが後から見えるようにする

4番目は地味ですが、私が失敗したあとに足した手順です。判定表だけを残すと「読んだうえで該当しないと判断した」のか「そもそも読んでいない」のかが区別できません。カバレッジが見えていれば、間違いは1つの条項で止まります。

日本語の解説だけを読むと、適用範囲を取り違えます

海外の規制を追うとき、日本語のニュースや解説記事から入るのは自然です。私もそうします。ただし、そこで判定まで済ませると危ないことがあります。

解説記事は、条文がまだ存在しない時点で書かれることがあります

JETRO（日本貿易振興機構）がEU AI法を報じたビジネス短信は、2024年5月27日付です。EU理事会の採択が5月21日なので、6日後の記事ということになります。ニュースとしては十分に速いです。

問題は速さではなく、その時点で何が確定していたかです。この記事は官報掲載について「今後、EU官報への掲載から20日後に施行され」と書いています。掲載日も発効日も、確定した日付では書かれていません。実際に官報に載ったのは46日後の2024年7月12日、発効は66日後の8月1日でした。

JETROは、その後もこの記事をEU AI法の参照先として使い続けています。1年半後の2025年12月1日付の記事でも、AI法を初めて出すところで「2024年5月27日記事参照」と書かれています。日本語だけで追うと、官報掲載前に書かれた記事にたどり着くことになります。

日本の法令を英語で読む側にも、同じ構造があります。法務省の日本法令外国語訳データベースは、サイト上に「正文ではなく、最終改正版でない法令も含まれています」と明記しています。翻訳が悪いのではなく、翻訳という工程には必ず時間差が入る、というだけの話です。

EUでは、全部の言語版が等しく正本です

「英語版が原文で、日本語版が翻訳」という感覚は、EU法には当てはまりません。

EUの公用語は24言語で、Regulation No 1/1958 の第4条と第5条により、法令はその全部の言語で起草され、官報に掲載されます。欧州司法裁判所は1982年のCILFIT判決（Case 283/81）の第18段落で、複数の言語版がすべて等しく正本であり、したがって条文の解釈には言語版どうしの比較が伴う、と述べています。

実務上の意味は単純です。日本語の解説を1本読んで「この条項の対象はこう」と決めるのは、24ある正本のどれも読んでいない状態で判定していることになります。

一次条文は、登録なしでそのまま取れます

では原文にあたるのは手間なのかというと、どうやらそうでもなくなってきました。日本、EU、米国のいずれも、条文そのものを機械で取れる窓口を無料で公開しています。

地域	窓口	登録・キー	取れるもの
日本	e-Gov法令API Version 2	不要	条項単位の本文、改正履歴、施行日・施行予定日、指定した時点の過去条文、キーワード検索
EU	CELEX番号で publications.europa.eu/resource/celex/{番号}	不要	規則・指令・判例・提案文書の原本。24言語から選べる
米国	Federal Register API v1	不要	1994年以降の全文書。公示前の縦覧文書も含む

EUのCELEX番号は、文書を1つに特定するための識別子です。言語に依存しないので、「どの文書か」と「どの言語版を見ているか」を切り離せます。EU AI法は32024R1689、それを改正したDigital Omnibus on AIは32026R1744、AI法の元になった欧州委員会の提案は52021PC0206です。先頭の数字が文書の種類（3は法令、5は準備文書）、次が年、そのあとのRが規則、Lが指令を表します。

米国のFederal Register APIには、公示前の文書を読める窓口（公開縦覧、public inspection）があります。毎営業日の東部時間8時45分に、翌日掲載される文書が置かれます。1日分の先読みですが、締め切りが詰まっている案件では効きます。

現実的な運用は、日本語で気づいて原文で判定する

原文を全部読めという話ではありません。分業にします。

まず日本語の解説やニュースで「何かが動いた」ことに気づきます。ここは速さが優先なので、二次情報で構いません。次に、その解説に出てくる規則番号や条項番号を手がかりに、上の表の窓口から一次条文を取ります。機械翻訳を通して大意をつかむのは問題ありません。ただし、判定の根拠として引く文言は原文のものにします。

判定表に条項番号を書くとき、出典として原文のURLを並べておくと、この分業が壊れにくくなります。あとで見返した人が、解説記事ではなく条文にたどり着けるからです。

職種ごとに「毎週なにを見るか」を1枚にまとめます

ここまでの内容を、そのまま個人の頭の中に置いておくとうまく回りません。誰が、どの層を、どの頻度で見るのかを1枚にして共有します。

規制を追う仕事は複数の部署にまたがっていて、しかも見ている場所が微妙に違います。同じ規則を2人が別々に追っていたり、反対に誰も見ていない層があったりします。あなたの会社では、この3つの層をそれぞれ誰が見ているか、すぐに答えられるでしょうか。1枚にすると、その穴が見えます。

担当	主に見る層	一次ソースの入口	頻度	AIに任せる部分
法務	決まった条文、運用の解釈	e-Gov法令検索、EUR-Lex、govinfo	週1回。契約更新期は都度	サブ条項の列挙と、自社事業への当てはめの下書き
薬事	まだ決まっていない案	薬事審議会の資料、パブリックコメント、Federal Register	週1回。審議会の開催前後は都度	審議会資料のうち、自社製品分類に触れた箇所の抽出
品質保証	運用の解釈	各省庁のガイドライン、質疑応答集、告示	月1回	改訂版と旧版の差分の洗い出し
経営企画	まだ決まっていない案	Unified Agenda、審議会の中期的な議論、EUの提案文書	月1回	複数国の動きを1つの年表に並べる作業

見る頻度は「更新の速さ」ではなく「気づくのが遅れたときの損害」で決めます

表の頻度欄は、更新が速い層を頻繁に見る、という発想では作っていません。気づくのが1か月遅れたときにどれだけ困るか、で決めています。

決まった条文は更新が最も遅いのに、法務が週1回見ています。条文が変わってから気づくまでの遅れが、そのまま契約や表示の不備につながるからです。逆に、まだ決まっていない案は更新が速いのに、経営企画は月1回で足りています。案の段階で経営判断が動くことは少ないからです。

記録は「判定表」と「読んだ条項の一覧」を分けて残します

運用でいちばん効いたのが、記録を2枚に分けることでした。

1枚目は判定表です。条項番号、適用の有無、判断の理由、根拠にした原文のURLを並べます。2枚目は、読んだ条項の一覧です。節の中のサブ条項を全部書き出して、確認したものにチェックを付けただけの表です。

2枚目があると、次に同じ規則を見る人が「どこまで見てあるか」を引き継げます。判定表だけだと、そこに載っていない条項が「該当しないと判断された」のか「まだ読まれていない」のかがわかりません。私が1つのサブ条項を落として結論を間違えたとき、この2枚目があれば、伝播する前に気づけたはずでした。

追う対象は、これからも増えます

規制を追う量が減る見込みはありません。スタンフォード大学の人間中心AI研究所（HAI）が出しているAI Index Report 2025によれば、米国の連邦機関が2024年に導入したAI関連の規制は59件で、2023年の25件から2倍を超えました。発出した機関の数も21から42に増えています。州レベルのAI関連法の成立は、2023年の49件から2024年は131件になりました。

そのうえ、この記事で見たとおり、いったん確定した適用日があとから動きます。一度調べて表を作り、それを配って終わり、という進め方が成立しません。差分を拾い続けることが前提になります。

調べた結果が積み上がる形にしておく

差分を拾い続ける前提に立つと、道具に求めるものも変わります。毎回ゼロから検索し直して、そのつどチャットの履歴に結果が流れていく形だと、3か月後に「あのとき何を根拠にこう判定したか」が追えません。

私たちDeskrexが開発しているSnorbeは、この点に向けて作っているリサーチAIエージェントです。調べた内容を出典付きのまま構造として残し、同じテーマに戻ってきたときに前回の記憶の上から積み上げていきます。JPO・EPO・Google Patents・arXiv・PubMed・Semantic Scholarといった専門データベースを横断できて、検索式の書き方を覚えなくても、自然な日本語のまま投げられます。規制の一次ソースを追う仕事は、同じテーマに何度も戻ってくる仕事です。相性のいい使い方ができるはずです。

よくある質問

規制動向調査を始めるときに聞かれることの多い8つを、条文と実測値を根拠にしてまとめました。

Q1. 規制動向調査は、どこから手をつければいいですか

自社の製品やサービスに効いている規則を、条項単位で書き出すところからです。規則1本ではなく条項単位にするのが大事なところで、EU AI法のように同じ規則の中で適用日が分かれることがあるからです。書き出したら、その条項の適用開始日を条文の施行規定から直接読んで、日付を控えます。ここまでできると、あとは「その条項に動きがあったか」を追うだけになるので、監視の範囲が現実的な大きさに収まります。

Q2. パブリックコメントは、いつまでに気づけばいいですか

日本の意見公募手続では、行政手続法第39条第3項により、意見の提出期間は公示の日から30日以上と決まっています。ですから週1回e-Govパブリック・コメントを見ていれば、原則として提出期間内に気づけます。ただし同法第40条第1項に、やむを得ない理由がある場合は30日を下回れる例外があります。緊急性の高い分野を担当しているなら、週1回では足りない時期があると考えてください。

Q3. 官報の電子版が正本になったと聞きましたが、何が変わりましたか

2025年4月1日に「官報の発行に関する法律」（令和5年法律第85号）が施行され、官報発行サイトに掲載される電子データが正本になりました。同法第6条により、公布はサイトに掲載する措置がとられた時点で行われたことになります。実務で影響が出るのは2点です。1つは、紙の官報が正本ではなくなったことです。もう1つは、無料で閲覧できる期間が90日と定められていることです。90日を過ぎるとプライバシー配慮が必要な記事は見られなくなるので、必要な号は期間内に保存しておいてください。

Q4. AIに規制文書を要約させても大丈夫ですか

大意をつかむ用途なら問題ありません。判定の根拠にするのは避けてください。人間が本を読んで要約の正確さを検証したFABLESという研究では、最も忠実だったモデルでも要約の52.0%に何らかの欠落がありました。要約は、書かれていることの正しさは保てても、書かれていないことに気づかせてはくれません。判定に使うなら、要約ではなくサブ条項の列挙を頼んでください。

Q5. 「サブ条項を全部列挙して」と頼むと、出力が長くなりすぎませんか

長くなりますが、それは狙いどおりです。列挙の段階で長い出力が出るのは、その節に判断すべき枝がそれだけあるという意味なので、短くまとまってきたら逆に疑ってください。ただし1回の指示で扱う範囲は節単位に絞ります。規則1本を丸ごと渡すと、Lost in the Middleの研究が示したように、中間に置かれた情報の想起精度が落ちます。この研究では、30文書のうち中間に正解を置いたときの正答率が50.9%で、文書を1つも渡さなかったとき（56.1%）を下回りました。

Q6. 社内文書とAIをつなぐ仕組みを規制文書に使うとき、注意点はありますか

文書の切り方に注意してください。決まった文字数で機械的に切ると、原則を述べる部分と例外のサブ条項が別々の断片に分かれます。片方だけが検索に引っかかると、そのまま読み落としになります。36通りの分割方法を比べた2026年の研究では、段落のまとまりを保って切る方式の上位1件的中率が約24%だったのに対し、固定文字数で切る方式は約2から3%でした。条や項の区切りを保って切ること、それから各断片の先頭にどの文書のどの節かがわかる情報を付けることが有効です。

Q7. 告示がe-Gov法令検索で見つからないのですが、探し方が悪いのでしょうか

探し方の問題ではありません。告示はe-Gov法令検索に収載されていません。デジタル庁は2026年度中を目途に告示のデータ提供を始めることを目指していますが、それまでは所管省庁のサイトか官報を直接見ることになります。処分の要件を定める告示は意見公募手続の対象なので、e-Govパブリック・コメントの結果公示から入るのも1つの手です。

Q8. 海外規制の日本語解説を読むだけでは、なぜ足りないのですか

解説記事は、条文が確定する前に書かれることがあるからです。JETROがEU AI法を報じた2024年5月27日付の記事は、官報掲載日も発効日も確定した日付では書いていません。実際の掲載はその46日後でした。この記事は、1年半後の記事からも参照先として使われています。日本語のニュースで動きに気づくのは速いので続けてよいのですが、判定の根拠として引く文言は、e-Gov法令API・CELEX番号・Federal Register APIのいずれかで取った原文にしてください。3つとも登録もAPIキーも不要です。