全法令をGitの履歴にしたhouritsu、改正をコマンドで追える

「この法律、前はどう書いてあったんだっけ」。条文を読み比べたくてe-Gov法令検索を開いたことがある人は多いはずだ。だが法律の改正は、今の条文をまるごと置き換えるのではなく、「第三条中『A』を『B』に改める」という書き換え指示の形で公布される。今の条文を眺めるだけでは、どこがどう変わったのか分からない。

2026年11月5日、はてなブックマークのテクノロジー人気エントリーで見つけたOSS「houritsu」は、この悩みに答える。日本の全法令をバージョン管理ソフトGitの履歴として扱えるように変換し、改正のたびに記録を1件積む仕組みだ。ソフトウェア開発で使い慣れたコマンドのまま、法律の改正履歴を追えるようになった。

改正点は条文を読むだけでは分からない

法律の改正が分かりにくいのは、なぜか。

日本の法律は、改正のたびに本体を書き直すのではなく「○○法の一部を改正する法律」という別の法律を新しく作る。その中身は「第三条中『A』を『B』に改める」のような、条文への書き換え指示だ。houritsuの作者は、プロジェクトを作ったきっかけとして、この点をZenn記事に書いている。元の条文と改正後の条文を自分で並べて、どこが変わったかを目で探すしかない。

ソフトウェアのソースコードなら、変更を1つずつ記録するGitが当たり前にある。houritsuは、この発想を法令にそのまま持ち込んだ。

houritsuは何をするツールか

houritsuは、法令ごとに1つのMarkdownファイルを作り、改正が施行されるたびにコミットを1つ積むGitリポジトリだ。

元になるデータは、デジタル庁が運営するe-Gov法令検索のAPI。変換プログラム「houritsu-builder」(Rust製、MITライセンス)が毎朝自動でe-Govとの差分を取り込み、新しいコミットを足していく。GitHub公式リポジトリによれば、収録法令は約9,000件、mainブランチのコミット数は2万3千件を超える(2026-11-05時点)。法令データ自体はCC BY 4.0で提供される。

公布はされたがまだ施行されていない改正は、mainとは別のupcomingブランチに置かれる。mainに積まれるのは、施行が確定した改正だけだ。

ここまでは仕組みの説明だ。実際に1つの法律を開くと、何が見えるのか。

個人情報保護法で見える改正の履歴

個人情報保護法のファイルを実際に開いてみた。

frontmatter(ファイル冒頭のメタデータ)には、直近の改正が記録されている。「防災庁設置法の施行に伴う関係法律の整備等に関する法律」が2026年7月17日に公布され、2026年11月2日に施行されたという内容だ。調査した2026年11月5日からわずか3日前の施行だ。法令のGit化というと過去の整理に見えるが、houritsuは今も毎日動き続けている現役のリポジトリだった。

このファイルのコミット履歴をさかのぼると、次のように改正が積み重なっているのが分かる。

houritsuは、コミットの日付を改正法の施行日にそろえる設計になっている。frontmatterの施行日(2026-11-02)とGitHub画面上のコミット日付(2026-11-01)には1日のずれがある。原因は確認できていないが、自分はタイムゾーンの表示差によるものとみている。コミットの中身自体は、確かにその改正を記録している。

条文の変遷を追いたいときに使うコマンドは、次の2つだ。

• git log <ファイルパス>: その法令全体の改正履歴を一覧する
• git log -L <条文の範囲>:<ファイルパス>: 特定の条文だけに絞って変遷を追う

houritsuの作者は、個人情報保護法第十六条を対象にしたgit log -Lのコマンド例をZenn記事に示している。このコマンドを使えば、ある1つの条文が過去にどう書き換えられてきたかを、改正法の名前と一緒にたどれる。

ここまでは順調に見える仕組みだが、全法令に適用しようとした途中で、作者は想定外の壁にぶつかっている。

全法令化の途中で見つかったGitの弱点

houritsuが収録する最古の法令は、1872年(明治5年)11月9日施行の「改暦ノ布告」。日本が太陽暦を採用したときの布告だ。

ここで問題が起きる。Gitはコミットの日時を、1970年1月1日からの経過秒数(Unix時間)で記録する。だがUnix時間は仕様上、1970年より前の日付を負の値として表現できない。改正法の施行日をそのままコミットの日時にする設計は、明治まで遡った時点で動かなくなる。

houritsuの作者自身、この制約には「作成中に気づいた」とZenn記事で振り返っている。普段ソースコードをGitで管理していても意識することのない制約だが、明治の法律という古い対象に当てはめた途端、現実の壁として立ちはだかった。

houritsuでは、1970年より前に施行された317件のコミットについて、Gitが記録する日時だけを1970年1月2日にそろえている。本当の施行日は、別のメタデータ(Enforcedというコミットの行とfrontmatter)に残した。コミットの日付表示は1970年1月2日に見えても、ファイルを開けば本当の施行日は正確に分かる。

この設計上の無理を知ると、houritsuのデータをどこまで信用してよいのかが気になってくる。

このデータはどこまで信用できるか

houritsuのREADMEは、データの位置づけについて次の点を明記している。

• 法令の正本は官報であり、houritsuのデータは公式なものでも法的助言でもない
• 改正履歴はe-Govが提供する範囲に限られ、2015年ごろ以降が中心。それより古い改正の経緯は含まれない
• git blameが示す日付は、条文の文言が作られた日ではなく、e-Gov側がその版を収録した時期を示すにとどまる
• houritsuはまだv1.0に達しておらず、履歴の再構築やforce-pushでコミットのハッシュが変わる可能性がある。特定の版を参照する際は、コミットのハッシュではなくfrontmatterのlaw_id・revision_idを使うべきとされている

つまりhouritsuは、実務の最終判断に使う資料ではなく、改正の経緯を調べる手がかりとして使うツールだ。本当にその条文で合っているかを確認するときは、e-Gov法令検索か官報に戻る必要がある。

まとめ

houritsuは、日本の全法令をGitの履歴として扱えるように変換したOSSだ。改正1回を1コミットとする設計により、git logやgit log -Lといった使い慣れたコマンドのまま、条文の改正履歴をたどれるようになった。個人情報保護法では、調査時点からわずか3日前の改正まで反映されている現役のリポジトリであることも確認できた。

一方で、明治の法律まで収録しようとしたことで、Gitが1970年より前の日付を扱えないという制約にぶつかった。回避できたのは、コミットの日時とメタデータを使い分けたからだ。法令の正本はあくまで官報であり、houritsuは条文の変遷を自分の手で確かめるための手がかりとして使うとよい。