法令のGit履歴houritsuとは。差分をAIに読ませる当てはめを整理

家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくん（@passion_tanaka）です。今回は、Impressの窓の杜 やじうまの杜の記事『日本の全法令が「Git」の履歴に』を紹介します。GitHubのhouritsuは、改正の施行1つが1コミットになっていて、変わった所がgit diffでそのまま見えます。

この記事は、私が保存したブックマークです。「AIに頼んで指示書の変更履歴を調べてもらった」「テキストで持っていればどんなAIにもすぐ渡せる」「事実は消さずに、その差分こそを判断軸として育てていく」という私の過去記事の向きと、同じ方向の話だと読みました。

読み方の筋は、経緯、仕組み、差分を見る、限界、AIと作った話、テキストで持つ、差分をAIに読ませる、の順です。あなたの仕事の文書にも当てはめられるか、一緒に整理します。

Impress（窓の杜 やじうまの杜）の記事『日本の全法令が「Git」の履歴に』（樽井 秀人さん・2026年11月5日・改正法の読みにくさの部分）より

改正法を読んでも、結局どこがどう変わったのかはわかりにくいものです。

改正法は、読んでも分かりにくい。どこが変わったのか、見えないからです。ここが、この話の入口です。

Impress（窓の杜 やじうまの杜）で2026年11月5日に樽井 秀人さんが紹介したのは、GitHubのリポジトリ houritsu（Kohei-Wada/houritsu）です。

日本の法令を、Git（ファイルの変更履歴を残す道具）の履歴にしたものです。

法律の改正は、「〇〇法の一部を改正する法律」という別の法律で行われます。中身は「第三条中〈A〉を〈B〉に改める」のような書き換えの指示です。

だから、改正法を読んでも、結局どこがどう変わったのかは分かりにくいんですよね。

そこで、法令の本文をファイルにして、改正を1つのコミット（変更を1回分として記録するひとまとまり）にします。

すると git diff（2つの版の違いを並べて見せる機能）で、変わったところがそのまま見えます。これがhouritsuの発想です。Impressの記事は、そう書いています。

制作者のZenn記事（2026年11月1日）によると、きっかけは「ただの思いつきです」とのこと。国会会議録のAPIを眺めていたときに、法律をgitで管理したら面白いのでは、と思いついたそうです。

調べると、ドイツには連邦法をgitで管理している bundestag/gesetze がありました。

日本には、e-Gov（デジタル庁の法令検索のサービス）の全法令を毎日スナップショットしている elaws-history があります。

ただ、こちらはXMLをそのまま貯めているので、改正ごとの履歴としては読めない。それなら作ってみよう、となったそうです。

私の読みです。改正を書き換えの指示で受け取ると、頭の中で適用してはじめて新しい姿が見えます。差分で受け取れば、結果が先に見える。この違いが、この話の入口だと思いました。

Impress（窓の杜 やじうまの杜）の記事『日本の全法令が「Git」の履歴に』（樽井 秀人さん・2026年11月5日・発想の部分）より

法律は「Git」で管理したらいいんじゃ？

「法律はGitで管理したらいいんじゃ？」という発想を、実際に形にした仕組みを順に見ていきます。

収録されているのは、デジタル庁のe-Gov法令検索で提供されている、法律・政令・省令などの全法令です。

制作者の11月1日の記事の数字では、法令ファイルが8,982個、mainブランチ（履歴の枝分かれのうち本流）のコミットが23,338個です。

制作者のZenn記事によると、1つの法令が、1つのMarkdown（飾りのない文章の書き方）ファイルです。メタデータは、フロントマター（ファイルの先頭に書く管理用の項目）に入っています。

制作者によると、1つのコミットは「1本の改正法が施行されたこと」に対応していて、コミットの日付は施行日です。公布済みでまだ施行されていない改正は、upcomingというブランチで管理されています。

毎朝、自動でe-Govから差分を取得して、コミットを足しているそうです。

制作者の説明では、データ元はe-Gov法令API v2で、変換プログラムのhouritsu-builderはRustで書かれています。データはCC BY 4.0です。

builderはMITライセンスです。どちらも公開されています。

コミットメッセージには、改正法の番号、公布日、施行日、同時に書き換わった他の法令が入ります。国会で成立した法律には、リンクも付きます。衆議院の議案へのものです。

私の読みです。「1コミット＝1改正の施行」「日付＝施行日」という約束事を先に決めたから、履歴がそのまま読めるんだと思います。ここは、仕組みを作る側の工夫ですね。

制作者のZenn記事『日本の全法令を git の履歴にしてみた』（2026年11月1日・diffの部分）より

改正法の条文から読み取るのは大変ですが、diff なら一目で分かります。

条文から読むのは大変です。でも、差分なら一目で分かる。Zenn記事の例で確かめます。

個人情報保護法のファイルに git log をかけると、この法律に手を入れた改正法が並びます。

2026-10-01の日本学術会議法の施行、2026-07-17の防災庁設置法の施行に伴う関係法律の整備等に関する法律の施行、同じ日の個人情報の保護に関する法律等の一部を改正する法律の施行、といった具合です。

個人情報保護法を直接いじる改正だけでなく、学術会議や防災庁の法律に巻き込まれて書き換わっていることも分かります。

2026-10-01の日本学術会議法のコミットを見ると、個人情報保護法の別表に1行足されていました。

制作者は「日本学術会議が国の機関から法人になったので、法人として個人情報保護法の対象に並んだ、ということのようです」と書いています。

2026-07-17の個人情報保護法の改正では、令和2年改正の附則にある見直しの規定が、「三年ごとに」から「三年を目途として」に変わっていました。ここは、まさに差分で見える所ですよね。

git log -L を使えば、特定の条文だけの変遷も追えます。Impressの記事は、GitHubの画面（Blame画面や、法令ごとのコミット履歴）を散策するだけでも面白い、と紹介しています。

1本の改正法が十数本の法令をまとめて書き換えていることも、コミットメッセージで分かるそうです。

AI氣道『GPT-6 Astraに合わせた指示書の見直し方を、いまにゅさんが解説』の見直しの材料の部分より

「8回の変化も、見直しの材料です。変わった所を、判断軸と、器に向けた書き方に分けておく。」

変わった所を分けて見直す考えを、私は『GPT-6 Astraに合わせた指示書の見直し方を、いまにゅさんが解説』で書いています。

差分を見たあとは、変わった所を「中身が変わった所」と「書き方が変わっただけの所」に分けておく。私の記事の言葉で言えば、変わった所を判断軸と、器に向けた書き方に分ける考えです。

私の読みです。差分のよさは、何が変わったかと、どの改正で変わったかが、同じ場所に並んで残ること。ここが大きいと思います。

制作者のZenn記事『日本の全法令を git の履歴にしてみた』（2026年11月1日・履歴の範囲の部分）より

履歴は 2015 年ごろからです。

履歴は2015年ごろから。制作者がまず挙げている限界です。

e-Govの改正データがそのあたりから揃っているので、それより前の改正は入っていません。Impressの記事も、改正履歴はe-Govが提供する範囲に限られ、おおむね2015年ごろ以降が中心、と書いています。

2つ目は git blame（各行がいつの変更で入ったかを見る機能）です。制作者の説明では、これは文言ができた日を示しません。2015年以前からある文は、最初のコミットに全部まとめて入っているためです。

3つ目は正本のこと。正本は官報です。条文の文字は変えていませんが、これは公式のものではなく、法的な助言でもない、と制作者は書いています。

おまけの話も面白いんです。制作者は、Gitは1970年より前の日付ではコミットできない、と説明しています。

コミットの日時をUnix時間（1970年1月1日を起点にした秒数）で持っていて、マイナスの値を受け付けないためです。

日本時間の1970年1月1日の始まりも、UTCでは1969年の大晦日になるので、弾かれます。

ところが日本の法令には、明治から施行されているものがあります。houritsuで一番古いコミットは、1872年11月9日施行の改暦ノ布告（太陽暦に切り替えた布告）。

1970年より前のコミットは317個あります。これらはコミットの日付を1970-01-02に寄せ、本当の施行日はEnforcedトレーラーとフロントマターに書く形にした、とのことです。これは古い法令のコミットの日付の置き方の話で、改正履歴の収録範囲は、先に書いた2015年ごろからのままです。

樽井 秀人さんも、これは知らなかったと書いています。

私の読みです。確かめられるのは、その履歴の範囲の中だけ。大事な確認は、原本に戻ります。ここでは官報です。あなたが文書の差分を見るときも、その範囲を先に確かめておきたいところです。

制作者のZenn記事『日本の全法令を git の履歴にしてみた』（2026年11月1日・制作者の自己紹介の部分）より

私は法律のことを全然知りません。ただ、最近は AI のおかげで、知らない分野の調べものがとても速くなりました。

法律を知らなくても、AIのおかげで、知らない分野の調べものが速くなった。制作者は、そう書いています。

Impressの記事によると、制作者の方は法律についてはまったく詳しくないそうです。それでも、AIの助けを借りながら、houritsuを作り上げたとのことです。

Zennの記事では、国会会議録のAPIを眺めていたときに、ふと「法律をgitで管理したら面白いのでは」と思いついたと語られています。

知らない分野でも、AIと一緒ならどこまでできるのか、試してみたくなったそうです。

次の構想は、houritsuと国会会議録のAPIを組み合わせた kokkai-cli のような道具だそうです。

コミットから、その改正を通した法案と国会での議論までたどれるもので、暇なときにやってみよう、と書いています。

私の読みです。速く調べることと、正しいと確かめることは、別の仕事です。制作者が限界の節で「正本は官報です」と書き添えているのは、その線を引いているんだな、と読みました。

制作者のZenn記事『日本の全法令を git の履歴にしてみた』（2026年11月1日・頻繁に変わる部分）より

作ってみて、法律は思ったよりずっと頻繁に、思ったより他の法律に巻き込まれて変わっていると分かりました。

法律は、他の法律に巻き込まれて変わる。それが思ったより頻繁に起きる。制作者は、作ってそう分かったそうです。

続けて、「法律を知らなくても、データの形にしてしまえば眺められるのは面白かったです」とも書いています。これは制作者の言葉です。

私の読みです。法律でなくても、契約書、規約、社内の指示書、マニュアルは、改訂のたびに「結局どこが変わったのか」を確かめる仕事が生まれます。あなたの仕事にも、思い当たる文書があるかもしれません。

旧版と新版をテキストで手元に置きます。すると、差分が取れます。houritsuは、それを日本の全法令でやった例だと読みました。

AI氣道『社内の知識をAIに読ませる時代へ｜GoogleのOKFと、私がずっとやってきたこと』より

「テキストで持っていれば、どんなAIにもすぐ渡せます。」

テキストで持つ利点を、私は『社内の知識をAIに読ませる時代へ｜GoogleのOKFと、私がずっとやってきたこと』で書いています。

私の記事は、知識をMarkdownのテキストで持つと、どんなAIにもすぐ渡せる、と書いています。同じ記事には、テキストで持てばgit（変更履歴）で管理できる、という節もあります。

houritsuの「1つの法令が1つのMarkdownファイル」と、私が書いてきた「テキストで持つ」は、同じ向きの話として重なります。これは私の読みです。飾りのないテキストだからこそです。

旧版との差が、素直に取れるんですよね。

制作者のZenn記事『日本の全法令を git の履歴にしてみた』（2026年11月1日・試してみたい気持ちの部分）より

知らない分野でも、AI と一緒ならどこまでできるのか試してみたくなりました。

制作者は、知らない分野でもAIと一緒ならどこまでできるのか、試してみたくなったそうです。

推測: 元記事が見せているのは、差分という形で変更が残っていれば、人が確かめやすい、という点だと読みました。その差分だけをAIに渡せば、AIにも確かめを頼みやすいはずです。

AI氣道『GPT-6 Astraに合わせた指示書の見直し方を、いまにゅさんが解説』の変更履歴の部分より

「私はAIに頼んで、10月21日から11月3日までの CLAUDE.md と AGENTS.md の変更履歴を調べてもらいました。本文は8回変わっていて、関係するファイルは34ありました。」

指示書の変更履歴をAIに調べてもらった話を、私は『GPT-6 Astraに合わせた指示書の見直し方を、いまにゅさんが解説』で書いています。

私は自分の指示書（CLAUDE.mdとAGENTS.md）の変更履歴を、AIに頼んで調べてもらいました。本文は8回変わっていて、関係するファイルは34ありました。

元記事は、改正法を読んでもどこが変わったか分かりにくい、と言います。私は自分の指示書では、変更履歴を見て確かめています。

差分を「中身が変わった所」と「書き方が変わっただけの所」に分ける読み方は、第3章で書いたとおりです。ここでは、その仕分けをAIに頼みます。

推測: 契約書や規約の改訂版が届いたとき、旧版と新版の差分だけをAIに渡して、「中身が変わった所」と「書き方が変わっただけの所」に分けてもらう。そのうえで、判断は自分に残します。

中身が変わった所の判断です。法律の解釈のような専門の判断は、正本（公式に正しいと認められる原本）と専門家で確かめる線です。

3手に言い直すと、①旧版と新版をテキストで手元に置く、②差分を取る、③差分だけをAIに読ませて2つに分けてもらう、です。

あなたなら、自分の仕事の文書を1つ選んで旧版を残すか、次の改訂のときに差分だけをAIに渡すか、どちらから始めるかな。

Impressの記事によると、houritsuは、日本の全法令を1法令1Markdownファイルにして、改正の施行1つを1コミットで残したリポジトリです。変わった所は、git diffでそのまま見える、とのことです。

制作者によると、履歴は2015年ごろからで、git blameは文言ができた日を示さず、正本は官報です。Gitは1970年より前の日付を扱えないため、317個のコミットは日付を1970-01-02に寄せた、とのことです。改正履歴の収録範囲は2015年ごろからのままで、差分で確かめられるのは、その履歴の範囲の中だけです。

私の読みです。契約書、規約、社内の指示書、マニュアルでも、旧版と新版をテキストで手元に置きます。すると、差分が取れます。houritsuの「1つの法令が1つのMarkdownファイル」と、私が書いてきた「テキストで持つ」は、同じ向きの話でした。

推測: 旧版と新版をテキストで置く、差分を取る、差分だけをAIに読ませて「中身が変わった所」と「書き方が変わっただけの所」に分けてもらう。この3手で、改訂の確認は言えるはずです。法律の解釈は、正本と専門家で確かめる線を残します。

この記事で学んだことを誰かに教えて恩送りして学びを深めよう！