Jujutsu と出会い、15 年使った Git にもう戻れなくなった理由

2026 年、初めて自分の意思で VCS を選択した

ふりかえると私にとって VCS（バージョン管理システム）は、会社に指定されたものを使ってきただけでした。それまでの会社では社内にサーバを立てて Subversion を使うことが多かった中、2011 年から働き出した会社では GitHub が導入されており、そのため個々のエンジニアは Git を使うことを求められました。Git / GitHub を本格的に使い始めたのはそのときからです。

しかし Subversion と比べると Git は非直感的で、かなり使いにくく感じました。また GitHub 導入に伴い、コードレビューのために履歴をきれいにするということが開発者に求められるように。でもそれに必要な Git の手続きはコマンドに一貫性がなくて憶えにくく、かつ失敗が許されない緊張を強いられる、非常にストレスの溜まる作業でした。

ただ使い続けるうちにその感覚も麻痺し、こういうものだと受け入れるようになりました。しかし相変わらずコマンドはなかなか憶えられず、ちょっと複雑なことをやろうとすると毎回 Google で検索、conflict が起きそうな操作はなるべく避けるというやり方で、5 年が過ぎ 10 年が過ぎました。このまま 15 年が同じように過ぎそうだった矢先、突如その状況が変わりました。Claude Code に代表される AI コーディングエージェントが登場し、あれよあれよという間に人間より AI がコードを書くことのほうが多いという、数年前なら信じられない状況が現実になったのです。

AI は指示を受けるとあっという間にコードを書き上げます。ワークフローの速度が格段に上がる中で、Git のいちいち add して commit してのわずらわしさが足を引っ張ります。また生成されたコードは自分が書いたものではないので、理解がそこそこでも動くならとりあえず commit する。すると後から色々変更したいことが出てきます。そのため rebase の無限地獄の中でまちがって重要な変更を消してしまったり、断念して修正 commit を上に重ねて履歴が汚くなったりということが日常的に起こるようになりました。

Jujutsu と出会ったのはそんなときです。日本では 2026 年 1 月ごろに次々と紹介記事が話題になり、一般の開発者にも認識されるようになりました。私もそれらをいくつか読む中で、これは AI コーディングと相性がよさそうと考え、試しに作業中のプロジェクトに導入してみました。しかし設計思想もコマンド体系も Git とかなり異なるため、最初はまったく使いこなせませんでした。でもインデックスが存在しない手軽さと、どんな操作も undo で元に戻せる安心感が挫折しそうになる心を支えてくれ、1 ヶ月ほどでどうにかそれなりに扱えるようになりました。

それ以降はすべてのリポジトリを Jujutsu で管理し、さらに原稿の執筆も（もちろんこの記事も） Jujutsu の環境で行っています。思えば Git → Jujutsu への移行は、初めて VCS を自分で選んだ経験でした。そして気づけば、もう Git には戻れなくなっていた。ここからは、Jujutsu のどんなところが優れていて、Git には戻りたくない気持ちにさせているか、個人的に思いつく理由を挙げていきます。

戻れない理由 1： 作業が履歴に保存されているかを気にしなくていい

Git は working tree（作業ディレクトリ）→ インデックス → ローカルリポジトリの 3 ステートモデルを採用しています。ファイルの変更を履歴に保存するには、まず git add でステージングし、さらに git commit する必要がある。いっぽう Jujutsu では working copy（作業ディレクトリ）の状態がそのまま commit になります。Jujutsu から見ると、作業ディレクトリの状態と現在の commit との間に乖離がありません。これには以下のようなメリットがあります。

• ユーザーが履歴への保存のタイミングを考えなくていい
• 切り替え時に git stash に相当する退避・復元の操作が不要
• 作業中のコードが消失する危険がほぼない

どのファイルがまだステージングされてない、commit に含まれていないなどという認知にかかるコストは、本来の開発作業とはまったく関係がありません。イレギュラーな作業が発生した場合などの切り替え時に stash を積んだり戻したりといったことも、余計な認知負荷です。Jujutsu はそれらのコストを限りなくゼロにしてくれます。

また AI コーディングの文脈なら適切な設定を用意すれば、「〇〇の機能を作って」と依頼するだけでタスクを実行しつつ成果をそのまま「feat: 〇〇」のようなメッセージでひとつの commit にしてくれます。ゆえに通常フローでは履歴管理にまつわる作業が不要になります。

さらに嬉しいのが git reset や git clean、シェルからのファイル操作でまちがってファイルを消して復元できなくなるアクシデントがほぼなくなること。AI エージェントにファイルを消されて戻せなくなった経験は私もありますし、モデルが当初よりずっと進化したはずの現在でもそういった報告をときどき目にします。Jujutsu では working copy が随時 commit される¹ため、まちがって消されたデータもほとんどの場合で履歴から復元可能です。

もし Git に戻ることを余儀なくされたら、また履歴の保存をいちいち考える必要に迫られ、作業中のコードを失うリスクとも隣り合わせになると思うと気が重い。Jujutsu はバージョン管理作業の認知負荷を減らし、心理的安全性を高めてくれていると感じています。

戻れない理由 2： 実験のコストが格段に低い

AI エージェントが指示したものをあっという間に作ってくれるようになったので、とりあえず作ってみて良ければ採用、いまいちなら捨ててやり直すといったトライ＆エラーをすることが増えました。しかし Git でそれをやろうとすると、色々な支障が生じます。working tree で履歴に保存しないままやれば、一度は捨てたけどやっぱり戻したくなったときに対応できません。保存しながらやろうとすると branch を利用することになり、今度はその作成・切り替え・マージ・削除の作業が面倒で、一気にハードルが上がります。

Jujutsu ではどうやるか。Git の commit に相当する Jujutsu の履歴の基本単位は change ですが、working copy におけるファイルの変更が検出されると自動的に改訂され、以前の版もちゃんと残ります。実験はこの change の中でやればいい。jj new コマンドで新しく change を作り、試したい実験を行い、採用なら description（≒ commit メッセージ）をつける。不採用なら jj abandon でその change を削除する。後から復元したくなったら jj operation revert <operation ID> で削除をなかったことにできるし²、削除の直後ならば jj undo 一発で復元可能。

また Jujutsu では名前をつけることなく、任意の地点から歴史の分岐を作ることができます。やり方は jj new に親となる change の ID を渡すだけ。同じ作業を別のアプローチで実装して比較したい場合、この分岐した change を複数作ります。change 間の移動は jj edit <change ID>。採用したい change はそのまま description をつけて残し、不採用の change は jj abandon で削除。これだけです。

Jujutsu の基本的な履歴の単位である change がそのまま実験場となるため、Jujutsu では実験も通常の操作の範囲に収まってしまいます。マージも不要。採用するかどうかその時点ではわからない実験なので、名前をつけるのも後回しにできます。

もし Git に戻ることを余儀なくされたら、今より明らかに実験の腰が重くなるでしょう。branch を作るのが面倒だからと working tree で実験して、捨てたけど後で戻したくなって後悔する自分が目に見えます。

戻れない理由 3： 履歴の書き換えが直感的でシンプル

自分で書いたコードであれば内容をきっちり把握しているので、commit も確度が高く手戻りは少なかった。しかし AI が生成したコードをすべて読み、手書きと同じ精度で把握してから commit する人は今やほとんどいないでしょう。そのため確定したはずの commit を後から変更したくなるシーンが格段に増えました。

では、たとえば「src/styles/global.css の変更を 3 つ前の commit に入れたい」というとき、Git と Jujutsu それぞれでどういう手順になるのでしょうか。アプローチとしては「該当の commit を直接編集する」方法と「手元で変更してそれを該当の commit に混ぜ込む」方法があるのですが、今回は前者で比較してみます。

まずは Git からですが、前提として未 commit のファイルがあると作業できないので、その場合は git stash -u で退避させないといけません。そこからは以下のようになります。

git rebase -i HEAD~4

上記のコマンドを実行後、開いたエディタで該当 commit の行の先頭を edit に変更して保存します。

pick bbbbbbb B のコミットメッセージ
edit bbbbbbb B のコミットメッセージ
pick ccccccc C のコミットメッセージ
pick ddddddd D のコミットメッセージ
pick eeeeeee E のコミットメッセージ

これで working tree が commit B 時点の状態になります。そして目当ての src/styles/global.css を編集してから、履歴に保存します。

git add src/styles/global.css
git commit --amend --no-edit

しかしこれで終わりではなく、後続の commit にこの変更を載せ直す必要があります。git rebase --continue を実行、conflict が起きないことを天に祈ります。もし conflict が起きたらそこで止まるので、ファイルを修正して git add → git rebase --continue を繰り返す。途中でわけがわからなくなったら、git rebase --abort を実行して一番最初からやり直しです。気が滅入りますね。

Jujutsu で同じことをする場合はどうなるか。jj edit @--- で working copy を 3 つ前の change に移動させ、src/styles/global.css を編集。すると後続の change にそれを反映させるための rebase が自動的に走るので、conflict が起きなければそれで終わりです。もし途中で conflict が起きても止まることなく自動 rebase は終了します。その場合は conflict が発生している change に jj edit で移動して修正すれば、また自動 rebase が走ります。

手順の少なさもさることながら、履歴の書き換えとして Jujutsu のほうがだんぜん直感的です。履歴の目当ての地点に移動してファイルを書き換えるだけ。必要な rebase は Jujutsu が勝手にやってくれて、ユーザーに rebase が走っていることを意識させません。しかし Git ではなぜか rebase が主役。git rebase で始まり git rebase で終わる。直感に反しますし、途中の手続きも煩雑で私はとうとう最後までおぼえられませんでした。

もし Git に戻ることを余儀なくされたら、おそらく履歴の書き換え自体を面倒くさがって極力避けるようになるでしょう。そして修正 commit が積み上がるか、趣旨と関係ない変更が commit の中に詰め込まれ、履歴がずっと読みづらくなるにちがいありません。

戻れない理由 4： 履歴を 2 次元のグラフで認識するようになる

まずは Git と Jujutsu、両者のログコマンドの出力結果を見てみましょう。前者が git log、後者が jj log の結果のサンプルです。なお Jujutsu はデフォルトで編集不可の change 周りは省略される仕様になっているため、-r :: オプションを渡してその制限を外しています。

Git のログは今いる branch において、何がどの順で起きたかが歴史年表のように直線的に表示されています。それに対し Jujutsu のログは、歴史全体を俯瞰してその分岐が ASCII アートによって表現されており、かつ情報密度が高い。一見して得られる情報量が段違いです。

また履歴上の過去の地点に移動したときのデフォルトの挙動も異なります。Git で git checkout <commit-id> を実行すると、git log からその時点以降の履歴は表示されなくなります。Jujutsu で jj edit <change-id> を実行すると、ログはそのままに working-copy commit を意味する @ のマークがその change のノードに移動するだけです。

このログの見た目と挙動の差は、Git と Jujutsu の設計思想のちがいを如実に表しています。Git では原則として作業時にはどこかの名前付き branch にいる必要があり、かつその世界線の先端に常に押し出されます。だからログでは、今いる地点が履歴全体のどこにあるのかや、その世界線の外の出来事は重要とは見なされず、表示されないのでしょう³。

いっぽう Jujutsu では Git の名前付き branch に相当するものがありません⁴。歴史上の編集可能なノードなら、分岐に関係なくどこでも自由に移動できます。だから全体を俯瞰したツリーグラフが非常に役立つのです。

Jujutsu で履歴の書き換えが簡単なのは、この情報密度が高く見やすいログに負うところも大きいです。まるで PC の動画編集ソフトで複数トラックのタイムラインを見ながら操作する感じ。これと比べると Git による編集は、アナログのフィルムテープをハサミで切って糊で貼ってつなぐようなものに感じられてしまいます。

ちなみに git log も --graph オプションを指定すれば、Jujutsu ほど見やすくはありませんが ASCII アートによるツリーグラフを表示してくれます。しかしそれを見たところで Jujutsu のように分岐をまたいで直感的かつ安全に編集できるわけではないため、もし Git に戻ったとしてもほぼ使うことはないでしょう。

移行後の Git との距離感

Git から Jujutsu に完全移行して半年以上経ちますが、Git を使うのをやめたわけではありません。Jujutsu はストレージ層がプラガブルな設計になっており、Git リポジトリをバックエンドのストレージとして使うことができます。Jujutsu でリポジトリを初期化すると、デフォルトの挙動としてプロジェクトルートに .git/ と .jj/ ディレクトリが共存する colocated workspace となります。Jujutsu で管理していても、Git のインターフェースを使っていないだけで、Git リポジトリ自体は変わらず使い続けているわけです。やろうと思えば git コマンドも普通に動作します。

ちなみにその高い互換性ゆえに、言わなければ周りに Jujutsu を使っていることはわかりません。GitHub や GitLab を利用しているチームで、知らなかったけど実は Jujutsu ユーザーがいたということも普通にありえます。Jujutsu を使っていてふだん Git を意識するのは最初にリポジトリを準備するために jj git init もしくは jj git clone を実行するとき、それ以降はリモートリポジトリと連携するための jj git fetch や jj git push を実行するときくらいでしょうか。

個人的には GitHub を利用するために使い始めた Git でしたが、AI コーディングの本格導入を機に Jujutsu に乗り換え、もう戻れない体になってしまいました。Git に長年慣らされてきたため最初は Jujutsu の流儀に違和感を覚えることもありましたが、VCS の歴史を踏まえると実は Git のほうが特殊だったということも多く、今は多くの場面で Jujutsu のほうが素直に感じられます。

しかしまだまだ Jujutsu はマイナーです。こんなに優れたツールなのに、その魅力が一般に十分知られてないのが歯痒い。Git と互換性がありながら、そのメンタルモデルが大きく異なるため、Git 脳のままコマンド比較表を見ながらちょっと試しただけでは、ほとんどメリットが実感できないのがネックです。そこでメンタルモデルの切り替えを重視した、「挫折しない Jujutsu 入門書」を書きました。

じゅじゅちゅ！　jj new で始める Jujutsu × AI ワークフローJujutsu（jj）を Claude Code など用いた AI コーディングに活用するための実践ガイド。自動スナップショット、いつでも取り消せる操作、安全な履歴の書き換えで、AI が生んだ大量の変更をレビューできる履歴に変えます。juju-chu.com

『じゅじゅちゅ！　jj new で始める Jujutsu × AI ワークフロー』というタイトルで表紙もライトノベル調と見た目はポップな本ですが、中身はけっこう本格的。Jujutsu 初心者が使いこなせるようになるまでを、順を追って解説しています。この記事を読んで Jujutsu が気になった方は、ぜひチェックしてみてください。上記リンクのページには、ブラウザでそのまま読めるサンプルもあります。