要約

  • OECDは、施行中の法律を機械実行可能な形で共有するための枠組みを協議している。法的に拘束力を持つのは従来どおり権威ある法律文書であり、解釈や裁量、個別判断をソフトウェアが引き受けるわけではない。
  • ルールを再利用すれば各機関の重複作業を減らせる可能性がある。しかし、法令へのリンクだけでは、実際の判定に使った条文の版、例外、解釈、承認者、稼働中のプログラムを特定できない。

改正日とリリース日のずれ

法令が改正された日に、関連する全ての行政システムが同じ状態になるとは限らない。旧版のルールを残した申請窓口、新版に切り替わった資格判定、まだ影響を受ける個人に通知していないサービスが並行して動くかもしれない。これは実際に確認された事故の説明ではなく、共有ルールの維持に必要な管理を考えるためのシナリオだ。

OECDは2026年、施行中の権威ある法律を機械実行可能な表示へ変換し、元のテキストとの結び付きを保ちながら共有する「Law as Code」の参照枠を協議し始めた。ここでの重要な前提は、コードが法律を置き換えないことだ。法律文書は引き続き拘束力を持つ。コードは解釈を変えず、機関の責任を移さず、個々の事案を決定しない。裁量や評価を固定条件に見せかけず、存在するものとして示すべきだとOECDは述べている。

この前提は法的な境界を守る一方、運用上の記録を必要にする。誰かがサービスの結果に異議を申し立てたとき、その機関は当時有効だった法律、対象条文、例外の扱い、ソフトウェアのリリースを再現できるだろうか。法令だけを示せても、実行した版が分からなければ説明責任は完結しない。

法律情報の識別と、ルールの実行

欧州連合のEuropean Legislation Identifierは、法律を識別する安定したURI、構造化メタデータ、データ交換の形式を整備している。法令を見つけ、版や関連情報を同期する基盤として有用だ。しかし、識別子が条文の意味を条件式に変換したり、その条件が法的に正しいと証明したりするわけではない。機械可読な参照情報と、機械が実行する解釈は別の仕事である。

OECDが2020年に示したRules as Codeの議論は、政府が機械で扱える公式のルールを作り、第三者が利用できるようにする広い発想だった。2026年のLaw as Codeはその中でも、既に成立した法令をデジタルに提供する範囲へ絞っている。新しい法律の起草や政策形成そのものは対象にしていない。幅の違いを曖昧にすると、法案づくりの支援、行政向け計算ツール、法令の実行表現を同じものとして扱ってしまう。

オーストラリア政府のGovCMSは2026年8月、自らのプラットフォームにRules as Code機能を導入したと発表した。最初の本番例は、政府機関がGovCMSを利用できるかを確認する資格判定ツールで、ルールセットは公開されている。これは限定された対象のサービス例であり、国民向けに法令を権威的に実行している証拠ではない。GovCMSの案内も、ツールは法律相談や拘束的な決定を提供せず、人の判断が必要な場面を置き換えないと明記する。

カナダのデジタルサービスが紹介した鉱業申請の試作では、規則が更新されてもツールが古い情報を残す可能性が課題として挙げられた。これは本番環境での誤判定を報告するものではない。ルールの維持者、法令改正を検知する手順、公開後にどのサービスが切り替わったかを記録する必要を示す。

判定を再現するための記録

有用な記録には、管轄、正式な法令名、対象条項、本文の版と施行期間、適用範囲、例外を含める必要がある。機械用の条件へ変換する際に行った解釈も残すべきだ。さらに、法務レビューと公開承認を行った人、実行可能なルールの版、各サービスが実際に読み込んだリリースを結び付ける。

それぞれの記録が答える問いは違う。法令の参照は出所を示す。版と日付はどの規則が効力を持つかを示す。適用条件と例外は、その人の事案が対象かを示す。解釈記録は法的文章を条件へ置き換えた判断を説明する。承認記録は利用を許可した責任者を特定し、配備記録は承認された版がどこで動いたかを示す。

一連の記録だけで争いを解決できるわけではない。法廷が最終的に条文を解釈することもあれば、行政機関が裁量を行使することもある。だからこそ、サービスは自動で決められない状況を示し、人による判断へ切り替える条件、理由の開示、訂正の申し立て先を説明すべきだ。手順がなければ、法律上の権限は明確なまま、事実上の支配だけが見えにくいソフトウェアへ移り得る。

検証にも二つの軸が要る。技術テストは同じ入力から同じ出力が得られるかを確かめる。法的レビューは条件式が条文、例外、改正日、裁量の範囲を正しく反映しているかを問う。安定して動くことは適法な解釈の証明ではない。逆に、法的に正確な意図があっても、稼働版が違えば結果は一致しない。

共通枠組みが決めるのは役割の境界

OECDの協議は特定のプラットフォームや制度を指定しない。実施には法務、技術、行政、政治、学術、経済、市民社会の協力と、各国の憲法に沿った責任分担が必要だとしている。共通の考え方をまとめても、どの機関が法的解釈を承認するかは管轄ごとに異なる。

現況を集める第一段階は2026年10月16日に締め切られる。その後、原則と要件を集める段階を経て、2027年1月から4月に共同で枠組みを作る計画だ。最終文書は2027年末か2028年初頭の見込みである。10月14日時点で、後続段階は全て予定であり、採択済みの標準や実績ではない。

各機関が独自にルールを作れば直接管理しやすいが、重複費用と更新作業も重なる。中央の公共機関が共通部品を管理すれば再利用しやすくなる一方、誰が公開や撤回を決めるのかが重要になる。連合型なら各管轄の解釈を保てるが、異なる実装を比較する負担が増す。OECDはまだ選択していない。

いずれのモデルでも、法律が変わったときに誰がコードを更新し、誰が公開を承認し、どの機関が下流サービスと利用者へ知らせるかを決めなければならない。公共サービスがコードを使うこと自体より、使った版と責任者を後から確認できるかが信頼を左右する。法令リンクは系譜の入口にすぎない。何を変換し、誰が認め、どこで実行し、どう修正できるかまで追えて初めて、その表現は説明可能な公共インフラとなる。

出典