法律改正の追跡は、法律の専門家でさえ負担が大きい。弁護士や企業のコンプライアンス担当者が特定の条文の改正履歴を調べようとすれば、有料の法律データベース契約か、複数世代の官報PDFを手元で突き合わせるかしか選択肢がない。「2019年から2023年の間に第35条はどう変わったか」という問いに即答できる環境は、ほぼ存在しない。スペインのITコンサルタントEnrique Lopez氏は2026年3月、その問いをGitのコマンド1つで答えられるようにした。legalize-esというOSS（オープンソースソフトウェア）プロジェクトで、連邦法8,646件と17の自治州法律を含む合計12,235件のスペイン法律をGitリポジトリで管理可能にした。「各法律=1ファイル、各改正=1コミット」という設計で、開発にかかった時間は約4時間だった。
法律改正をGitで追跡する仕組み
legalize-esでは、スペインの各法律が1つのMarkdownファイルとして存在する。法改正が施行されるたびにそのファイルが更新され、Gitのコミットとして記録される。コミットの日時には実際の施行日が使われており、コミット履歴がそのまま法律の改正年表になる。
git diffコマンドで2つのコミットを比較すると、変更前後の条文が赤と緑で並ぶ。2023年3月に施行されたコミットと2022年の版を比較すれば、「第12条の文言が具体的にどう書き変わったか」が即座にわかる。法学部の学生がテキストエディタで差分ファイルを手動で作っていたような作業が、Gitの差分表示コマンド1つで完結する。
データの元になっているのはBOE（Boletín Oficial del Estado：スペイン官報）が提供するオープンデータAPIで、1960年以降の全改正履歴にアクセスできる。Lopez氏はこのAPIからデータを取得してMarkdownに変換し、各改正をコミットとして積み重ねるパイプラインを実装した。Lopez氏はHacker Newsのスレッドで、「Claude Codeを使って約4時間でパイプラインを構築した」と述べている。
1万2000件の法律がどのようにリポジトリに格納されているか
リポジトリ（legalize-dev/legalize-es）のディレクトリ構造はスペインの行政区分に対応している。es/ディレクトリが連邦法8,646件を収め、各自治州はそれぞれ独立したディレクトリを持つ。アンダルシアはes-an/、カタルーニャはes-ct/といった具合で、17の自治州分が揃う。これらを合算した合計が12,235件のファイルだ。
各Markdownファイルの冒頭にはYAMLフロントマター（構造化されたメタデータブロック）が付いており、法律のタイトル・公布日・所管省庁・ELI識別子などが記録されている。ELIはEuropean Legislation Identifier（欧州法律識別子）の略で、EU加盟国の法令に一意のIDを付与するための標準規格だ。このELIをキーとして使うことで、同じ法律を指す複数の参照先を名寄せしたり、EU横断での法令比較を将来的に行ったりする基盤になる。
コミット数は43,820件、スターは1,600を超えた。過去数十年分の法改正をGitに落とし込んだ結果として積み上がった数字で、リポジトリをgit cloneした時点でスペイン法律の1960年以降の全改正履歴がローカルに揃う。
「git diffで法改正が見える」は誰にとって使えるか
BOEは条文の掲載はしているが、改正前後の比較は読者が自力でやらなければならない。企業のコンプライアンス担当者なら、自分が管理する規制領域のファイルをGitのwatch機能で監視できる。調査報道の記者であれば、特定の法律のコミット履歴を時系列で並べて「誰が政権のときにどの条文が書き変わったか」を可視化できる。
開発者にとっての意味は別の角度でも大きい。法律文書は質が高く構造が安定しており、LLM（大規模言語モデル）の学習データやRAG（検索で取得した外部知識をAIの回答生成に組み込む技術）の知識ベースとして扱いやすい。「法改正前と改正後の条文ペア」はファインチューニング用の対比データとして機能する。改正差分を自動サマリーするツール、変更通知を送るサービス、特定の法律分野の変遷をタイムラインで可視化するアプリなど、Gitを接続点として構築できるものは少なくない。
現時点ではプロジェクト自体が"early stage"とされており、ファイル構造やコミット履歴の形式が今後変わる可能性がある。本格的なシステム連携に組み込む前にはこの点を確認しておく必要がある。
legaltech・AI開発への応用可能性
既存の法律データベースはほぼ有料で、構造化されていないPDFや独自フォーマットが主流だ。MarkdownとGitというオープンな標準で法律を管理することは、その上にサービスを構築するコストを大幅に下げる。
Lopez氏はプロジェクトの将来として「Legalize API」の整備を計画している。検索、フィルタリング、バージョン比較、変更通知といった機能を提供する予定で、これが実現すると法律をデータとして扱うサービスの共通インフラになりうる。「legaltech」と呼ばれる法律テクノロジー分野ではドキュメントレビューや契約書作成にAIが使われ始めているが、そのAIが参照できる構造化された法律データの整備は十分ではない。legalize-esが提供するアーキテクチャはその欠けた部分を埋める設計になっている。
Legalize APIが整備された場合、ハルシネーション（誤情報の生成）対策としても機能しうる。検索可能な法律データベースをRAGのバックエンドにつなぐことで、AIが生成した回答を条文レベルで検証するシステムを組める。条文のバージョン管理ができているなら、「この回答は2024年時点の法律に基づく」と出典のスナップショットを示すことも可能になる。ほとんどの法律チャットボットが抱えるバージョン管理問題への一つの解答になりえる。
スペイン発が31カ国に拡大するまで：legalize.devの現在地
Lopez氏が4時間でスペイン向けパイプラインを作れた理由は、設計の時点から「多カ国対応」を前提にしていたからだ。各国の官報に対して4つのPythonインターフェースを実装すれば新しい国を追加できる構造になっており、Lopez氏は「フランスがすでに2カ国目として動いており、新しい国を追加するには各国の官報向けに4つのPythonインターフェースを実装するだけだ」と述べている。
この設計の汎用性は数字で示されている。親プロジェクトlegalize.devは2026年4月時点で31カ国、659,425件の法律を管理するまでに成長した。スペイン1カ国の12,235件から始まったプロジェクトが、国際的なオープン法律インフラとしての輪郭を持ち始めている。
今後の課題として、Lopez氏は「法律はデータ量が膨大で、多カ国に拡大するには本格的なインフラが必要だ。ホスティングと開発の資金調達にOpen Collectiveを立ち上げる」と述べている。OSSの実験から公共インフラの試みへと移行しつつある段階だ。
日本でもgitlaw-jp（aluqas/gitlaw-jp）という同様のプロジェクトが登場した。Hacker Newsへの投稿をきっかけに、「法律をテキストではなくバージョン管理されたデータとして扱う」という発想が各国の開発者に広がっている。Legalize APIが整備され、RAGや変更通知サービスに接続できる構造が確立された時点で、法律情報へのアクセスの前提が変わる可能性がある。法律をコードと同じように管理し、diffで読み、APIで配信する——その基盤が今、各国の官報データとGitを接続する形で静かに積み上がっている。