「GitHub で使える？」「なぜこの名前？」 Jujutsu の気になる 7 つの疑問

Q1. 既存の Git リポジトリがそのまま使える？

Jujutsu は Git と高い互換性を持っており、既存の Git リポジトリも jj git init コマンドで初期化することで Jujutsu で扱えるようになります。試してみるにあたって失うものは何もなく、Git を捨てる必要はありません。

Jujutsu はストレージ層が差し替え可能な設計で、デフォルトでは Git がそのバックエンドになっています¹。Git バックエンドは commit を Git リポジトリに保存するため、Jujutsu で履歴を管理していても、Git インターフェースからはその履歴を Git の履歴として参照することができます。

Jujutsu リポジトリと Git リポジトリの共存は colocated という言葉で表現されます。リポジトリを colocated にするには、以前は初期化の jj git init やリモートリポジトリをローカルにコピーする jj git clone コマンドに --colocate オプションを渡さなくてはならなかったのですが、2025 年 10 月リリースの v0.34.0 からは colocated がデフォルトになり、その必要がなくなりました。古い記事などで逐一 --colocate オプションを指定している例を見かけますが、今となっては不要な記述なのでスルーしてください。

colocated なリポジトリのルートには、.git/ に加えて .jj/ ディレクトリが共存しています。.jj/ 配下の .gitignore に /* が記述されているため、ルートの .gitignore を汚すことなく Jujutsu を導入できます。先述したように Jujutsu を使っていても Git の commit 履歴は変わらず更新され続け、それを GitHub などのリモートリポジトリに push できます。署名付き commit にも対応しているため、署名を必須とするリポジトリでも利用できます。ですので、その気になれば Git を使っているチームで自分ひとりだけ Jujutsu を使うことが可能です。

また colocated なリポジトリでは、これまで通り Git コマンドも普通に使えます。もし Jujutsu を使うのをやめたくなったら、リポジトリルートの .jj/ ディレクトリを削除するだけです。このように Jujutsu は既存の Git の環境をそのままに、試してみるコストが非常に低いツールになっています。

Q2. Git にできて Jujutsu にできないことはある？

Git と高い互換性を持つ Jujutsu ですが、2026 年 10 月現在の最新 v0.46.0 でも未対応の Git の機能がいくつかあります。中でも実際の開発で問題になりやすいものとして、以下の 3 つが挙げられます。

• submodules の管理
• LFS（Large File Storage）の取り扱い
• Git hooks 相当の機能

このうちもっとも深刻なのが submodules をサポートしていないことでしょう。Git の submodules はリポジトリの中に別の独立した Git リポジトリをサブディレクトリとして組み込む機能であり、主にプロジェクト間でコードを共通化したい場合などに用いられます。

非対応といっても submodule の内容が失われるわけではないのですが、問題なのは履歴を移動しても submodule の内容が自動的に同期されないこと。Jujutsu では jj edit コマンドで、タイムマシンのように任意の履歴ポイントに移動してファイルを参照したり編集したりできますが、そのとき submodules のディレクトリの内容は追随してくれません。毎回手動で git submodule update --recursive を実行する必要があります。

またリポジトリで submodule の内容を変更しても、Jujutsu からは無視されてしまいます。そのため submodule における変更を履歴に載せるには、Git コマンドで add して commit する必要があります。このように Jujutsu で submodule を含むリポジトリをまったく運用できないわけではないのですが、何ができないかを正確に把握したうえで、毎回手動でフォローする手間が生じてしまいます。

また開発側の事情として submodules は Jujutsu のデータモデルと相性が悪く、対応には大きな設計変更が求められるのも対応が遅れている大きな原因です。ロードマップには挙がっていますが、設計ドキュメントの多くは未完成のままで、実装の見通しは立っていません²。なお近年は同じ目的でも submodules ではなく、モノレポや GitHub Packages などを利用したプライベートなパッケージ管理を選択することが増えているようです。もし技術選定ができる立場にいるのであれば、新規プロジェクトでは submodules を避けてそちらを検討したほうが良いでしょう。

Git LFS は動画や音声、大きなバイナリファイルなどを扱うための Git の拡張機能です。大容量データをリポジトリの外で管理し、Git 内にはそのポインタのみを保持するというしくみになっています。GitHub で 100MB を超えるファイルをリポジトリで直接管理するには、現状はこの Git LFS 一択となっています³。

ゲーム開発などでは必須とも言える機能ですが、これも現状で未対応です。開発自体は進んでいて PR がいくつも出ていますが⁴、他の機能も巻き込んでの設計判断が追いついていないようで、リリース時期はまだ見えません。

最後に Git hooks。Git の特定アクションに連動して独自のスクリプトを実行させるしくみであり、これは他の 2 つよりも導入している現場はずっと多いでしょう。commit の前にフォーマッターやリンターを実行させたり、push の前にテストやセキュリティの監査を実行させるといった用途に用いられます。併用されるツールとしては Husky + lint-staged や Lefthook がメジャーです。

しかし Jujutsu のコマンド実行によって Git hooks がトリガーされることはありません。たとえば jj git push は内部で git push コマンドを呼び出していますが、その際に --no-verify オプションを付けて hooks の実行を意図的に止めています⁵。そして公式からは、Git hooks を任意のタイミングでトリガーする機能も、それに相当する Jujutsu 独自の hooks 機能も提供されていないのです。

その理由は、hooks はそのしくみが Jujutsu のコアとなる設計思想やデータモデルとマッチしないことにあります。具体的には以下のような要因が挙げられるでしょう。

• Jujutsu は随時ファイルの変更を検出して自動的に commit を行うため、Git のように儀式として commit を行うタイミングがない
• squash や過去の履歴を編集すると子孫に適用される自動 rebase など、Jujutsu では作業ディレクトリを経由せずにコードが書き換えられるため、最初の commit 時にテストなどをパスしていても、後々までそれを保証できない

ただ Git hooks の機能をすべてカバーできるわけではありませんが、Jujutsu のモデルに適合したソリューションは公式からいくつか提供されています。たとえば jj fix は設定でフォーマッターを登録しておくと、実行時に編集可能な履歴を遡って、そこで変更されたファイルにフォーマットを適用してくれます。jj run は指定した履歴のポイントもしくは範囲に対して外部コマンドを実行するためのコマンドです。ビルドチェックやテストを巡回して実行するのに使える他、実行によって変更されたファイルを対象の履歴に反映できるため、修正を伴う静的解析などにも使えます。

しかし Git を前提に hooks 環境を作り込んでいるチームで自分だけ Jujutsu を使いたい場合はどうしたらいいのでしょう？　それには状況に応じたいくつかの対処方法があり、それだけで記事が 1〜2 本書けるほどのテーマなので、ここでは割愛させていただきます。なお拙著『じゅじゅちゅ！  jj new で始める Jujutsu × AI ワークフロー』の「4-3. Git Hooks の代替戦術」にその説明があるので、興味のある方はそちらを参照してください。

Q3. GitHub とも連携できるの？

Jujutsu は Git をバックエンドとして使えるため、リモートリポジトリが GitHub にあろうが GitLab にあろうが Bitbucket にあろうが、問題なく連携できます。しかし共有の単位に branch ではなく bookmark という異なる概念を用いるため、それを理解できるかどうかが障壁になるかもしれません。

Jujutsu では Git の名前付き branch に相当するものがなく、基本的に匿名 branch で作業を行い、共有時に任意の履歴ポイントに bookmark を付けるというワークフローになります。bookmark の付いた履歴をリモートリポジトリに push すると、Git からはそれが branch に見えるというしくみです。GitHub 上では branch として扱われるのに branch とは別の概念であり、その挙動も異なるのがややこしいところです。Jujutsu 初心者にとっては、以下の点に違和感を覚えるかもしれません。

• 自動で最新の履歴に移動せず、自分で動かす必要がある
• ローカルとリモートでその位置や削除を同期させる tracking というしくみがある
• tracking が前提のため、bookmark はリモートとローカルで同じ名前でなくてはならない
• bookmark がない状態からでも push 時に -c/--change や --named オプションを指定することで、その場で bookmark を作りながら push できる

なぜ Jujutsu には branch がなく bookmark があるのか、bookmark による共有は何が嬉しいのかについては、前の記事の『「ブランチを切る」が Jujutsu にないと知って、初めてブランチを理解した話』でくわしく説明しているので、そちらを参照してください。

push した後のフローで Jujutsu の挙動が Git と異なる点に、push 済みの履歴を書き換えて再度 push すると、何もしなくても force push になってしまうことがあります。Jujutsu からの push は常に --force-with-lease オプションを指定しているのに近い挙動なのですが、履歴が意図せず書き換えられるリスクからはその commit が mutable（書き換え可能）か immutable（書き換え不可）かという判断によってローカルの段階から守られています。そのデフォルトの基準では trunk 以外では push 済みの commit でも mutable とされるため書き換えることができ、その結果を再度 push すると結果的に force push となってしまうのです。

これが feature branch を複数のメンバーで共有して開発する運用になっているチームのポリシーと競合することがあります。その場合は、たとえば以下のような設定で commit を immutable と判断する範囲を変更してあげるといいでしょう⁶。

[revset-aliases]
'immutable_heads()' = 'builtin_immutable_heads() | remote_bookmarks("feature/*", "origin")'

その他 PR 作成やその承認とマージ、GitHub Actions などの CI/CD 周りについては Jujutsu を使っているからといってほとんど何も変わりません。ちがうのは PR マージ後にページからリモートの branch を削除すると、jj git fetch を実行したときに連動しているローカルの bookmark が削除されるくらいでしょうか。

Q4. けっきょく Jujutsu は Git と比べて何がうれしいの？

Git と比較したときの、Jujutsu を導入するメリットとしては以下のものが挙げられるでしょう。

• インデックス（ステージングエリア）がない。git add に相当する操作が不要
• commit が自動的に行われる。何らかの jj コマンドを実行した際、直近の commit からファイルが変更されていれば、新しくスナップショットを取って commit を更新するしくみ
• 上記 2 つの特徴により working copy（作業ディレクトリ）が commit そのものとして扱われる。それゆえ Git のように未 commit の変更やインデックスとの整合性を気にせず、タイムマシンのように自由に履歴上を移動できる
• 任意の履歴を書き換えると、その子孫の履歴が自動的に rebase される
• rebase の途中で conflict がいくつ発生しても、対話モードにならずいったん conflict を抱えた状態で正常終了する。すべての conflict を含んだ状態が履歴に残るため、解消のやり直しやツールに解消を任せるのが容易
• リモートリポジトリに影響するものを除き、 jj undo でほとんどの操作を取り消せる
• リポジトリに更新があった各種 jj コマンドの実行や自動スナップショットの動作がすべて operation log に記録されている。後からファイルの状態をその操作直後の状態に戻したり、その操作だけを打ち消したりできる
• 実験や試行錯誤のために、いちいち作業の名前を考えて branch を作る必要がない。jj new で作業を始め、気に入らなければ jj abandon で破棄してやり直せる
• コマンド体系が素直でおぼえやすい。たとえば squash は jj squash --from A --into B。操作対象や移動先を指定するオプションも -f/--from、 -t/--into、-o/--onto、-A/--insert-after、-B/--insert-before など関連するコマンドで一貫している

Q5. 学習コストは高い？

最初におぼえるべきコマンドは、さほど多くありません。少なくとも以下のものを押さえておけば、一通りのワークフローはこなせるはずです。

これだけでも自動 commit や undo 機能の恩恵は受けられるので、そこに価値を見出せれば第一関門は突破です。ただし問題はその先にあります。Git 経験者ほど Git のメンタルモデルのまま、コマンド対応表⁷を見ながら Jujutsu を使いがちです。しかしそれだと、ただ Git における操作を逐一翻訳しているだけのため Jujutsu の便利さを享受できないいっぽうで、面倒な翻訳プロセスが加わるだけになってしまいます。

Jujutsu は Git の使いづらさを解消するために、Git との互換性を保ちながらも、そのメンタルモデル自体を問い直して設計されています。Jujutsu のパワーを引き出すには、マスター・ヨーダの「You must unlearn what you have learned.（今まで学んだことを手放さねばならん）」という教えのようにする必要があるのです。

ですので、次の段階を超えるためのハードルは高くなります。しかしそれは Jujutsu が複雑だからというわけではなく、Git で長年培ってきたバージョン管理の習慣を見直し、当然だと考えてきた概念を捨て去ることを求められるためです。その必要性を認識できないまま、Git のワークフローをそのまま Jujutsu に置き換えて使い続けた結果、メリットを感じられず Git に戻ってしまう人をときどき見かけます。

Jujutsu のメンタルモデルを身につけるための近道として、個人的には以下の 3 つが肝要だと考えます。

1. Jujutsu の通常の履歴単位である change とは何かを理解する
   • change は名前と不変の ID を持ったコンテナであり、commit（revision ともいう）はそこに格納される複数バージョンの書類と考えると、技術的には正確でなくとも初心者はイメージしやすい
2. commit は作業が完成してから作るものという固定観念を捨てる
   • Jujutsu ではコードを変更したり description（≒ commit メッセージ）を変更するたびに、自動的かつ瞬時に git commit --amend --no-edit が走るようなイメージ。change は未完成が常態であり、作業に区切りがついたら別の change に移動するだけ
   • Git ワークフロー互換のために用意された jj desc → jj new をまとめて行う jj commit コマンドを使わない
3. 作業中に「現在の branch」という概念がないことに慣れる
   • 匿名 branch で作業して、共有したくなったらそこで bookmark をセットするというフローをひたすら守る
   • 現在位置を branch 名ではなく、jj log で表示されるツリーグラフで確認する習慣を身につける

一度 Git のワークフローを手放して Jujutsu のやり方を続けていると、Jujutsu の設計の合理性が実感できるようになります。そのころにはもう Jujutsu はあなたの手足として、なくてはならないものになっているでしょう。

Q6. まだ v1.0 に達してないのに、業務で使って大丈夫？

先に結論をいうと、Q2 の問題がクリアできるのであれば、実用上の問題はほぼありません。ただし CLI や設定方法は今後も変わり続けるので、それが許容できるかどうかが採用にあたっての焦点になるでしょう。

GitHub 公式リポジトリの README には以下のように書かれています。

Jujutsu is an experimental version control system. While Git compatibility is stable, and most developers use it daily for all their needs, there may still be work-in-progress features, suboptimal UX, and workflow gaps that make it unusable for your particular use.
（Jujutsu は実験的なバージョン管理システム です。Git との互換性については安定しており、利用者の多くは日々の開発に必要な作業を Jujutsu でこなしています。しかし、まだ開発途中の機能や改善の余地がある UX、ワークフロー上の不足が残っており、用途によっては使用に耐えない可能性があります）

そしてバージョン 1.0 のリリース前に、ワークフローの変更や後方互換性のないディスクフォーマットの変更があるかもしれないとも言っています。ただしフォーマット変更がある際には、透過的なアップグレードを用意するとのこと。

これだけ読むと少し不安になりますが、近年はさほど大きな破壊的変更はありません。破壊的変更の多くは非推奨だった設定やコマンドオプションの削除、動作環境の要件変更といったものです。2026 年 2 月リリースの v0.38.0 では、リポジトリ用設定ファイルの保存場所が変更されましたが、それもセキュリティ上の理由によるものであり、ユーザーを悪意ある攻撃から守るためにやむを得ないものでした。

Jujutsu は元 Google のエンジニアだった Martin von Zweigbergk 氏が 2019 年末からサイドプロジェクトとして開発を始め、GitHub で最初のバージョン v0.3.0 がリリースされたのが 2022 年 3 月のこと。そこからすでに 4 年半が経過していることになります。また 2023 年 9 月の v0.9.0 以降は、ほぼ毎月新バージョンをリリースしています。v1.0 に達してはいなくても、歴史的な積み重ねは十分にあると言っていいでしょう。

ちなみに GitHub の公式リポジトリのスター数は、2026 年 10 月現在で約 32,000 となっています。プロジェクトには現在 9 人のメンテナがいて、毎リリース 30 人前後のコントリビュータが名を連ねています。Google をはじめ、複数の企業に所属するエンジニアが継続的に開発に参加しています。公式ドキュメントには、Jujutsu の開発に業務として関わっている企業やその所属コントリビュータが公開されています⁸。

実績や採用事例はどうでしょうか？　先に作者は Google 出身と言いましたが、彼によると 2025 年 9 月の時点で Google 社内にはすでに 900 人ほどの Jujutsu ユーザーがいたそうです⁹。さらに彼は 2026 年 7 月に ERSC というホスティングプラットフォーム企業の CTO に就任しましたが、ERSC は独自ストレージの設計が Jujutsu のモデルに沿ったものとなっており、将来的には Jujutsu クライアントのネイティブプロトコルにも対応する構想です。Jujutsu をサービスに組み込んでビジネスを展開している企業が存在するのは、信頼性のひとつの目安となるでしょう。

また PR を親子関係を持った小さな単位に分割できる GitHub Stacked Pull Requests が先日から一般提供されるようになりましたが、そのドキュメントには Jujutsu を使ったフローを紹介したページがあります¹⁰。これは GitHub が Jujutsu を無視できない数のユーザーが使っている互換クライアントとして認識しており、サポートする必要性を感じていることの表れと見ていいでしょう。

Jujutsu がまだ v1.0 に達していないのは、品質や信頼性に問題があるからというよりも、まだ進化の途中にあり、仕様を変更する自由を残しておきたいという意味合いが強いのではないかと私は考えています。すでに多くの開発者による日常的な利用実績があり、企業による開発支援も続いています。少なくとも、v1.0 未満という理由だけで業務利用を避ける必要はないでしょう。

Q7. なんで「Jujutsu」という名前なの？

SNS などでよく「Jujutsu という名前が厨二病っぽい」という感想を目にします。おそらく漫画の『呪術廻戦』の影響でこの名前がつけられたと考えてのことなのでしょうが、Jujutsu は『呪術廻戦』とは関係がありません。

では Jujutsu という名前はどこから来たか。GitHub の公式 README からは、jj というコマンド名が先に決まっていたことが伺えます。

The command-line tool is called jj for now because it’s easy to type and easy to replace (rare in English). The project is called “Jujutsu” because it matches “jj”.

ホームポジションの右手人差し指で 2 回押すだけなので、確かにタイプしやすいですね。そしてそこから jj にマッチする Jujutsu がプロジェクト名としてつけられたように読めますが、実のところ初期のプロジェクト名は別のものでした。crates.io という Rust の公式なパッケージレジストリのサイトに、Jujubeという名前の VCS があります。作者は Martin von Zweigbergk 氏で、2021 年 1 月にリリースされた 0.1.0 と 0.1.1 のバージョンが登録されています。そう、これは Jujutsu の前身のプロジェクトなのです。ページには名前の由来について、以下のように書かれています。

The command-line tool is called jj for now because it’s easy to type and easy to replace (rare in English). The project is called “Jujube” (a fruit) because that’s the first word I could think of that matched “jj”.

jujube とは果物のナツメのことで、やはり jj にマッチする名前だから付けたのだとあります。しかしこのわずか 4 ヶ月後に名前が変えられました。そのときの commit メッセージが残っています。

project: rename project from Jujube to Jujutsu “Jujutsu” is probably much more familiar and relatable to most people. Also, I’m still not sure how “jujube” is supposed to be pronounced :P

どうやら作者として Jujube という名前には特に思い入れがなかったようで、より馴染みがあり親しみやすいという理由で Jujutsu にしたとのこと。後にこの名前はどこから来ているのかと質問された際¹¹、Wikipedia の jujutsu のページを示しているので、これは武道の「柔術」のことでしょう。ちなみに英語では日本の古流柔術を「jujutsu」、ブラジリアン柔術を「jiu-jitsu」と表記することが多いようです。Wikipedia にはブラジリアン柔術（Brazilian jiu-jitsu）のページもあるのですが、「jiu-jitsu」や「jiujitsu」で検索すると jujutsu のページにリダイレクトされます。もしこの仕様がなかったら、今ごろは Jujutsu ではなく Jiu-jitsu になっていたかもしれません。

じゃあ Jujutsu は「柔術」が名前の由来ということで決定なのか。しかし彼はこの名前に特別な意味を持たせてないと言います。Jujutsu を Jojo に改名したいという提案があったときも¹²、やはり Jujutsu という名前にもさして執着がないのか、投票で決めたらいいというようなことを言っています。公式のミーニングや発音として「呪術」を採用してはどうかという提案があったときも¹³、作者自身は当初その案に好意的でした。しかし議論の結果、特定の意味や発音を公式に定義することは見送られました。

さらに 2025 年から使われている Jujutsu の公式ロゴからも、プロジェクト名に特別な意味を持たせていないという公式の姿勢が読み取れます。

青い鳥が 2 羽、背中合わせになっています。これはカラスの仲間のカケスという鳥です。英語では jay と言います。そう、2 つ並べると「jay-jay」。名前だけでなく、ロゴまで jj に引っかけたダジャレになっているのです。もし柔術が公式のミーニングであれば、それにまつわるものをロゴにしたはずですが、実際はそうなっていません。

結局のところ、すべては短くてタイプしやすい jj というコマンド名から始まったわけです。そこから武道の「柔術」にちなんで Jujutsu と名付けられたものの、公式には「柔術」とも「呪術」とも定義されていません。Jujutsu は Jujutsu でしかない。それが、この名前の由来に対する答えなのでしょう。

まだまだ疑問が解消されない方へ

以上、主に Git ユーザーが Jujutsu を試してみようかというときに気になるだろう 7 つの疑問をピックアップして回答しました。なお、この内のいくつかは拙著 『じゅじゅちゅ！  jj new で始める Jujutsu × AI ワークフロー』 の「第 5 章  Jujutsu 問題解決ガイド」に掲載されている一問一答を再構成した形になっています。

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

本書ではさらに Jujutsu 初心者が抱きがちな疑問や、いざ始めてみたときにぶつかりやすい問題への対処法などを豊富に掲載しています。Jujutsu を始める際に非常に役に立つ本になっていますので、ぜひチェックしてみてください。