--- title: "Jujutsu（jj）とは？Git互換VCSのインストール・使い方とGitとの違い" url: "https://www.issoh.co.jp/tech/details/10763/" published: 2026-01-28 updated: 2026-10-24 categories: ["GitHub"] publisher: "株式会社一創" --- # Jujutsu（jj）とは？Git互換VCSのインストール・使い方とGitとの違い Jujutsu（ジュジュツ、コマンド名は `jj`）は、Gitのリポジトリをそのまま読み書きできるバージョン管理システムです。アニメ「呪術廻戦（Jujutsu Kaisen）」とは関係なく、由来は柔術です。作業中のファイルが常に1つのコミットとして記録されるため `git add` もstashも要らず、手元の操作は `jj undo` で戻せます。2026年10月時点の最新版は0.46.0（10月7日公開）で、1.0前のため毎月のリリースで破壊的変更が入ることがあります。この記事では0.46.0を実際に動かし、Windows・Mac・Linuxのインストール、既存のGitリポジトリで変更を記録してGitHubへpushするまで、履歴の直し方、VS Code拡張とGUI、古い解説が動かない理由を確認した結果をまとめます。 ## まとめ：Jujutsu（jj）の要点（v0.46.0時点） - **何者か**：Martin von Zweigbergk氏が2019年に趣味で始め、現在はGoogleで本人の専任プロジェクトになっているGit互換VCS。Googleの公式サポート製品ではない。ライセンスはApache-2.0。 - **インストール**：Windowsは `winget install jj-vcs.jj`、macOSは `brew install jj`、Arch Linuxは `pacman -S jujutsu`。0.46.0から実行時にGit 2.42.0以上が必要で、Ubuntu 22.04とDebian 12の標準のGitでは足りない。 - **Gitとの違い**：作業コピー自体がコミット（`@`）で、ステージングが無い。ブランチに当たるブックマークは自動で進まない。コンフリクトがあってもrebaseは止まらない。 - **始め方**：既存のGitリポジトリで `jj git init` を打つだけ。`.git` と同居する「colocate」が既定で、Gitコマンドも並行して使える。やめるときは `.jj` を消せば戻る。 - **VS Code**：MIT ライセンスの「Jujutsu Kaizen」（`jjk.jjk`）か、プロプライエタリで個人は無料の「VisualJJ」。マーケットプレイスで「jujutsu」と検索すると呪術廻戦のテーマ拡張が混ざるので拡張IDで探す。 - **注意**：`jj git push --allow-new` は0.42で削除、`jj rebase -d` は0.36で `-o` に改名。submodule・Git LFS・Gitフックは非対応。 ## Jujutsu（jj）の開発元と安定度 公式リポジトリは [github.com/jj-vcs/jj](https://github.com/jj-vcs/jj) です（2024年に個人アカウントの martinvonz/jj から移転）。READMEの「Mandatory Google Disclaimer」では、作者が2019年末に趣味で始め、現在はGoogleで本人の専任プロジェクトになっており、複数のGoogle社員が開発に加わっていると説明しています。同じ箇所に「Googleのサポート対象製品ではない」とも明記されており、サポートはコミュニティが担います。 READMEは jj を「実験的なバージョン管理システム」と位置付け、1.0.0までにワークフローやディスク上の形式の後方互換を破る変更が入ると予告しています（Git互換の部分は安定しており、コア開発者は jj で jj 自体を開発しています）。リリースはほぼ毎月第1水曜日前後で、[GitHubのリリース一覧](https://github.com/jj-vcs/jj/releases)では2026年に0.37.0（1月8日）から0.46.0（10月7日）まで毎月1本出ています（9月は0.45.0と同日の修正版0.45.1）。 ## Jujutsuのインストール手順：OS別のコマンドと初期設定 公式の手順書（[Installation and setup](https://docs.jj-vcs.dev/latest/install-and-setup/)）に載っている方法を中心に挙げます。どの方法で入れても、実行時にGit 2.42.0以上が要ります。0.46.0の [CHANGELOG](https://github.com/jj-vcs/jj/releases/tag/v0.46.0) で2.41.0から引き上げられました（`jj workspace add` が `git worktree add --orphan` を使うため）。cargoでソースからビルドする場合はRust 1.97.1以上が必要です。 ### Windows：wingetかscoop ``` winget install jj-vcs.jj # または scoop install main/jj ``` 2026年10月24日時点で、wingetの `jj-vcs.jj` とScoop Mainの `jj` はどちらも0.46.0を収録しています。Gitが古いと動かないので、先に `git --version` で2.42以上かを見ておきます。Windows版Gitの更新手順は[Git for Windowsの最新版は2.56.0｜ダウンロード・インストール手順と更新方法](/tech/details/11868/)にまとめています。WSL上で使う場合はWSL側でLinuxの手順により別途入れ、設定ファイルもWindows側とは別になります。 Windowsで `jj git fetch` や `jj git push` が無言で止まる場合、`ssh` の鍵のパスフレーズ入力などで固まる不具合（issue #6745）の可能性があり、0.46.0で直っています。 ### macOS：Homebrew ``` brew install jj jj --version ``` Homebrewの `jj` formulaは2026年10月24日時点で0.46.0です（別名 `jujutsu`）。MacPortsなら `sudo port install jujutsu` です。手元のXcode Command Line ToolsのGitは2.50.1（Apple Git-155）で、要件を満たしていました。 ### Linux：pacman・cargo-binstall・cargo ``` # Arch Linux sudo pacman -S jujutsu # ビルド済みバイナリを ~/.cargo/bin に置く（cargo-binstall導入済みの場合） cargo binstall --strategies crate-meta-data jj-cli # ソースからビルド（Rust 1.97.1以上。Ubuntu等は先に build-essential が必要） cargo install --locked --bin jj jj-cli ``` Fedoraは公式手順に非公式のCOPRリポジトリ（`aldantanneo/jj-vcs`）が載っています。Ubuntu・Debianの公式リポジトリ向けの手順は無いため、cargoを使わないならGitHubリリースのビルド済みバイナリ（`jj-v0.46.0-x86_64-unknown-linux-musl.tar.gz` 等）を展開してPATHに置きます。 見落としやすいのがGitの版です。標準パッケージのGitは、Ubuntu 22.04が2.34.1、Debian 12が2.39.5で、どちらも0.46.0の要件（2.42.0以上）を満たしません。Ubuntu 24.04（2.43.0）とDebian 13（2.47.3）なら標準のままで動きます。 ### 初期設定：名前とメールアドレス コミットの作成者情報はGitの設定を読みません。最初に次の2行を実行します。 ``` jj config set --user user.name "Taro Yamada" jj config set --user user.email "taro@example.com" jj config path --user # 書き込まれたファイルの場所を確認 ``` 0.45.0から、ユーザー設定ファイルが複数あるときの `--user` の書き込み先が変わりました。以前は対話的に選ばせていましたが、現在は最初に読み込まれるファイル（旧来の `~/.jjconfig.toml` があればそれ、無ければ `~/.config/jj/config.toml` または `conf.d/` の先頭ファイル）へ黙って書き込みます。書き込み先を指定したいときは、`--user` の代わりに `--file ` を指定します。 ## Gitとの違い：作業コピーがコミットになる操作モデル jj はGitのオブジェクト形式でデータを保存するので、リモートやCIから見れば普通のGitリポジトリです。チームの他のメンバーはGitのままで構いません。変わるのは手元の操作モデルで、Gitに慣れた人がつまずくのはほぼ次の3点です。 ### ステージングが無く、作業コピーそのものがコミット jj では作業中のファイル群が常に `@`（working-copy commit）というコミットになっています。`jj` コマンドを実行するたびにファイルの状態が自動でスナップショットされ、`@` に取り込まれます。そのため `git add` に当たる操作が無く、stashも要りません。別の作業に移りたければ `jj new` で新しい空のコミットを作るだけで、それまでの変更は親コミットに残ります。逆に、コミットしたくないファイルは `.gitignore` に書いておかないと自動で取り込まれます。 ### change IDとcommit IDの2つのID `jj log` の各行には2つのIDが出ます。先頭の英字（例 `xxmknrqv`）がchange IDで、コミットを書き換えても変わりません。後ろの16進（例 `3995efba`）がGitのcommit IDで、書き換えるたびに変わります。0.46.0で `jj describe` によりメッセージを付けると、change IDはそのままでcommit IDだけが `0a4ee739` から `3995efba` に変わりました。ただし `jj squash` で中身を全部移して空になった移動元のコミットは破棄され、そのchange IDは使えなくなります。 ### ブックマークとGitブランチの更新タイミングの違い Gitのブランチに当たるものは、0.22で「bookmark」に改名されました。改名の理由は、Gitのブランチと挙動が違うため、とCHANGELOGに書かれています。一番の違いは、新しいコミットを作ってもブックマークが自動では付いてこない点です。pushする前に `jj bookmark set <名前> -r @-` のように位置を合わせる必要があります。ブックマークが無くても作業はでき、名前の無い変更をいくつも並行して持てます。ブランチの基本は[ブランチとは？バージョン管理で開発を分岐させる仕組み](/tech/details/13782/)を参照してください。 ### GitとJujutsuのコマンド対応表 | やりたいこと | Git | jj（0.46.0） | | ------------- | -------------------------------- | ------------------------------ | | 既存リポジトリで使い始める | – | `jj git init` | | クローン | `git clone URL` | `jj git clone URL` | | 状態を見る | `git status` | `jj st` | | メッセージを付けて確定 | `git commit -a -m` | `jj commit -m` | | 直前のコミットに追加 | `git commit --amend` | `jj squash` | | メッセージだけ直す | `git commit --amend -m` | `jj describe -m` | | 作業を一時退避 | `git stash` | `jj new @-` | | 付け替え | `git rebase` | `jj rebase -o` | | cherry-pick | `git cherry-pick` | `jj duplicate -o` | | fixup の自動振り分け | `git commit --fixup`＋`rebase -i` | `jj absorb` | | 変更を捨てる | `git reset --hard` | `jj abandon` | | 取得・送信 | `git fetch` ／ `git push` | `jj git fetch` ／ `jj git push` | | 操作の取り消し | `git reflog`＋`reset` | `jj undo` | Gitコマンド側の詳しい意味は[Gitコマンド一覧](/tech/details/2787/)にまとめています。 ## jjの基本的な使い方：既存リポジトリで変更を記録してpushするまで ### 既存のGitリポジトリへの導入 ``` cd my-project # 既に .git があるリポジトリ jj git init # .jj が作られ、.git と同居する jj log ``` 0.34以降は同居（colocate）が既定のため、昔の解説にある `--colocate` は付けても付けなくても同じです。同居状態では `git log` や `git diff` もそのまま使えます。ただし `git status` は jj の操作後に「Not currently on any branch.」（detached HEAD）と表示します。jj がHEADを `@` の親に置くためで、故障ではありません。リモートに `main` がある場合、初回は「`jj bookmark track main@origin` を実行すると今後のfetchでローカル側も更新される」というヒントが出るので、従っておきます。新規にクローンするなら `jj git clone ` を使います。 `jj log` が全履歴を出さないのも仕様です。既定の表示範囲は `present(@) | ancestors(immutable_heads().., 2) | trunk()` で、今の作業コミット（`@`）、書き換え可能な（不変扱いでない）コミットとその近くの祖先、trunkだけを出します。全部見たいときは `jj log -r ::` です。 ### 変更の記録：describe・new・commit ``` echo "b" > b.txt jj st # A b.txt が @ に取り込まれている jj describe -m "add b" # @ にメッセージを付ける jj new # 次の作業用に空のコミットを作る # 上の2行は jj commit -m "add b" 1回と同じ結果になる ``` `jj new -m "add b"` のように先にメッセージを書いてから編集しても構いません。旧来の解説に出てくる `jj amend` と `jj init` は現行版にはありません。 ### 過去のコミットを直す：edit・squash・split・absorb Gitでは `rebase -i` で行う履歴の手直しを、jj は目的別のコマンドで行います。どれも書き換えたコミットの子孫を自動で付け替えるため、途中で止まって続きを指示する必要がありません。 ``` jj squash # @ の変更を親（@-）へ移す jj squash --into # @ の変更を任意の祖先へ移す jj split -r b.txt # 指定したファイルだけを別コミットに分ける jj absorb # @ の変更を、その行を最後に変えた祖先へ振り分ける jj edit # 過去のコミットを直接作業コピーにする ``` 0.46.0で試した結果は次のとおりです。「add a and b」「add c」の2コミットの上で、`a.txt` の2行目と `c.txt` を同時に直して `jj absorb` を打つと、「Absorbed changes into 2 revisions」と表示され、`a.txt` の修正は「add a and b」へ、`c.txt` の修正は「add c」へ、それぞれ自動で入りました。どの祖先に入れるか一意に決まらない変更は `@` に残ります。 `jj split -r b.txt` では、指定した `b.txt` 側が元のchange IDを引き継ぎ、残りが新しいchange IDのコミットになりました。0.46.0から `jj split` は2つのコミットの説明を1回のエディタでまとめて編集する形に変わっています。`jj edit` は過去のコミットを直接書き換えるため、意図しない変更まで混ざりやすい操作です。`jj new ` で上に作業用コミットを作り、終わったら `jj squash` で戻すほうが、混ざった変更を切り分けやすく安全です。 ### GitHubへのpush：ブックマークの作り方で3通り ``` jj git remote add origin git@github.com:you/repo.git # origin が未登録の場合だけ実行 # 1) 名前を付けて push（-b を付けると追跡も自動で始まる） jj bookmark create feature-a -r @- jj git push -b feature-a # 2) 名前を考えずに push（push- という名前が自動で付く） jj git push -c @- # 3) 引数なしは、revsets.git-push の範囲にある追跡中のブックマークを push jj git push ``` 0.46.0では、引数なしの `jj git push` が送る範囲を設定 `revsets.git-push` で変えられるようになりました。既定値は `remote_bookmarks(remote=exact:remote)..@` で、リモートにある位置から `@` までの範囲です。送るものが無いときは「No bookmarks/tags found in revsets.git-push」と警告して終わります。 履歴を書き換えたあとのpushに `--force` は要りません。jj は最後にfetchしたリモートの状態と一致するときだけ上書きするので、動作は `git push --force-with-lease` 相当です。Git側での同じ操作は[git rebaseとは？使い方・mergeとの違い](/tech/details/8926/)で解説しています。 ### pushが拒否される3つの条件 0.46.0で手元のリモートに対して試すと、次の3つの場合にpushが止まりました。 | 状況 | 表示 | 終了コード | 対処 | | ----------------------- | ----------------------------------------------- | ----- | ------------- | | 新しいブックマークを `-b` なしでpush | Refusing to create new remote bookmark | 0 | `-b` を付ける | | 説明の無いコミットを含む | Won’t push commit … since it has no description | 1 | `jj describe` | | コンフリクトを含む | Won’t push commit … since it has conflicts | 1 | 解消してから | 1つ目だけは終了コードが0なので、スクリプトやCIでは失敗に気付けません。以前はここで `--allow-new` を付けましたが、このフラグは0.36で非推奨、0.42で削除され、0.46.0で付けると「unexpected argument」エラーになります。毎回の追跡を省きたいなら、設定に `[remotes.origin]` と `auto-track-bookmarks = "*"` を書きます。2つ目は、説明を付け忘れた空のコミットが間に挟まっているときにも起きます。2つ目と3つ目は `--allow-empty-description`・`--allow-conflicts` を付ければ送れますが、Gitで受け取る側が困るので通常は使いません。 ## コンフリクトの扱い：rebaseが途中で止まらない仕組み Gitのrebaseはコンフリクトに当たるとその場で止まり、解消するか `--abort` するまで次に進めません。jj はコンフリクトをコミットの中身として記録し、rebase自体は最後まで完了させます。同じファイルの同じ行を別々に変えた2つのコミットで試すと、0.46.0では次のように表示されました。 ``` $ jj rebase -s uuwvkplt -o ltnvruxs Rebased 1 commits to destination. New conflicts appeared in 1 commits: uuwvkplt 9d67dcc9 (conflict) left Hint: To resolve the conflicts, start by creating a commit on top of the conflicted commit: jj new uuwvkplt Then use `jj resolve`, or edit the conflict markers in the file directly. Once the conflicts are resolved, you can inspect the result with `jj diff`. Then run `jj squash` to move the resolution into the conflicted commit. ``` `jj log` ではそのコミットに `×` と `(conflict)` が付き、ファイルには次の形のマーカーが書かれます。Gitの `<<<<<<<` と違い、片側を「差分」として示すので、どちらの変更を残すか判断しやすくなっています。 ``` <<<<<<< conflict 1 of 1 +++++++ ltnvruxs 2e8a0b45 "right" (rebase destination) right %%%%%%% diff from: uxstllpr 356a2073 "base" (parents of rebased revision) \\\\\\\ to: uuwvkplt 0493e548 "left" (rebased revision) -line1 +left >>>>>>> conflict 1 of 1 ends ``` 解消の手順はヒントのとおりで、`jj new <衝突したコミット>` で上に作業用コミットを作り、ファイルを直すか `jj resolve` でマージツールを開き、`jj squash` で解消結果を衝突したコミットへ戻します。解消するまで他の作業を続けても構いません。未解消のコミットは `jj log -r 'conflicts()'` で一覧できます。コンフリクト自体の仕組みは[コンフリクトとは？Gitで変更が衝突する仕組みと解消手順](/tech/details/13562/)で説明しています。 コンフリクトは標準のGitの形式では表せないため、jj はGitのコミット内に `.jjconflict-base-*` などの内部用ディレクトリとして保存します（[公式のGit互換性資料](https://docs.jj-vcs.dev/latest/git-compatibility/)による）。jj から操作する限り見えませんが、`git switch` で直接取り出すとこのディレクトリが作業コピーに現れます。「rebaseが常に成功する」は「解消しなくてよい」という意味ではなく、前の章のとおり通常のpushは拒否されます。 ## 操作ログとjj undo：連続取り消しとワークスペースの制限 jj はリポジトリへの操作を1回ずつ操作ログ（operation log）に記録します。`jj op log` で一覧でき、各行に実行したコマンドそのもの（例 `args: jj git push -c @-`）が残ります。 ``` jj undo # 直前の操作を取り消す（続けて打つとさらに1つ前へ） jj redo # 取り消しをやり直す jj op log --limit 5 # 操作ログを見る jj op restore <操作ID> # 任意の時点のリポジトリ状態へ戻す ``` 0.33.0で `jj undo` は「連続」型になり、打つたびに1つずつさかのぼります。戻しすぎたら `jj redo` で進めます。古い記事の「undoは1回しか効かない」という説明は現行版には当てはまりません。操作ログはGitのreflogと違ってブックマークやリモート追跡の状態も含むため、ブックマークの付け間違いもまとめて戻せます。 リモートに送った内容は戻せません。push直後に `jj undo` を打つと「Undoing a push operation often leads to conflicted bookmarks.」と警告され、`jj redo` を促されました。 0.46.0からは、別のワークスペースで実行された操作を `jj undo` で取り消そうとすると「Refusing to undo operation … because it was performed in workspace proj-ws2」と拒否されます。並行して作業している別のワークスペースの変更を誤って戻さないための変更で、意図して戻すときは `--allow-cross-workspace` を付けるか、`jj op revert` で特定の操作だけを打ち消します。 ## jj workspaceで並行作業：0.46からGit worktreeとして作成 1つのリポジトリから作業コピーを複数作る機能が `jj workspace` です。Gitの `git worktree` に当たり、複数のAIコーディングエージェントに別々の変更を同時に進めさせる用途に向きます。0.46.0からは、同居（colocate）リポジトリで `jj workspace add` すると対応するGit worktreeも自動で作られます。 ``` jj workspace add ../proj-ws2 # 作業コピーを追加（Git worktreeも作られる） git worktree list # Git側からも2つ見える jj workspace list jj workspace remove proj-ws2 # 0.46.0の新コマンド。ディレクトリごと消す ``` 実行すると「Created Git worktree for the new workspace.」と表示され、`git worktree list` に元のディレクトリと `proj-ws2` の2行が並びました。追加した側にも `.git` があるため、Gitしか知らないエディタやツールも追加した作業コピーをGitリポジトリとして扱えます。0.45以前は、同居になるのは最初の作業コピーだけでした。Git worktreeを作りたくない場合は `--no-colocate` を付けます。 後片付けは0.46.0で追加された `jj workspace remove` で、作業コピーの状態をコミットに記録してからGit worktreeとディレクトリを削除しました。`jj workspace forget` は作業ディレクトリと作業ファイルを残して追跡をやめます。ただし0.46.0の同居ワークスペースでは、対応するGit worktreeの登録と `.git` ファイルも取り除きます。 なお、公式のGit互換性一覧は今も「git-worktree: No」です。これは、Gitで作った既存のworktreeの中で jj を使う形を指しています。jj の作業コピーを増やすときは `git worktree add` ではなく `jj workspace add` から作るのが前提です。Git側の仕組みは[Git Worktree（ワークツリー）とは](/tech/details/7018/)、エージェントを並列で動かす道具の例は[herdrとは？AIコーディングエージェントを並列で動かす使い方](/tech/details/13284/)で扱っています。 ## 古い解説が動かない理由：版ごとの破壊的変更 jj の日本語解説は2024〜2026年前半に書かれたものが多く、そのまま打つとエラーになったり、意味の無いフラグを付けたりすることになります。CHANGELOGから、入門者が踏みやすい変更だけを抜き出しました。 | 版（公開日） | 変更 | 古い記事の書き方 | | ------------- | ------------------------ | ------------------------- | | 0.22（2024-10） | branch を bookmark に改名 | `jj branch create` | | 0.33（2025-09） | undo が連続型に・redo 追加 | undo は1回だけ | | 0.34（2025-10） | colocate が既定に | `jj git init --colocate` | | 0.36（2025-12） | rebase の `-d` を `-o` に改名 | `jj rebase -d` | | 0.36（2025-12） | `--allow-new` 非推奨 | `jj git push --allow-new` | | 0.42（2026-06） | `--allow-new` を削除 | 同上（エラーになる） | | 0.45（2026-09） | `config --user` の書き込み先 | 対話で選ぶ前提 | | 0.46（2026-10） | Git 2.42.0以上が必須 | Git 2.41で動く | | 0.46（2026-10） | 他ワークスペースの操作は undo 不可 | どこからでも undo | `-d` は旧名として当面は残されており、CHANGELOGは「異例に長い非推奨期間」を置くと書いています。一方 `--allow-new` は既に削除済みです。調べ物で見つけたコマンドが動かないときは、まず記事の日付と `jj --version` を突き合わせ、公式ドキュメントの `docs.jj-vcs.dev/latest` で確認するのが確実です。[STORES Product Blog「Gitの代わりにJujutsuを使い始めて1ヶ月」](https://product.st.inc/entry/2025/12/09/191758)でも、生成AIに聞いたrebaseの `-r` と `-s` の説明が誤っていて1時間ほど失ったと報告されています。 ## Jujutsuを採用すべきでない場面：submodule・LFS・フック 公式ドキュメントのGit互換性一覧で「No」とされている機能を日常的に使うリポジトリでは、jj を主に使う運用は勧めません。 - **Gitフック**：非対応（issue #405）。pre-commitでlinterや[gitleaks](/tech/details/10403/)のような秘密情報の検知を走らせている場合、jj からのコミットではそれが動きません。CI側で同じ検査を必ず通す構成になっていないなら導入を見送るべきです。 - **Git LFS**：非対応（issue #80）。LFSで大きな画像やモデルを管理しているリポジトリでは、LFSの取得・更新をGitで行う運用が残ります。 - **submodule**：作業コピーに現れません（データが失われることはない）。submoduleを更新するリポジトリでは、その操作だけGitに戻ることになります。 - **.gitattributes**：非対応（issue #53）。改行コードの変換やマージドライバの指定に頼っているリポジトリでは差分が変わります。 逆に、小さな変更を積み重ねて1つずつレビューに出す使い方（スタックしたプルリクエスト）には向いています。下のコミットを直すと上に積んだコミットが自動で付け替えられるため、Gitのように `rebase -i` を何度もやり直す必要がありません。チームで導入するなら、フックで行っていた検査をCIへ移すのが先です。CIの整備は弊社の[DevOps・CI/CD導入支援](/service/system/devops/)でも扱っています。試すだけなら既存リポジトリで `jj git init` し、やめたくなったら `.jj` ディレクトリを消して `git switch main` で元のブランチに戻れます。 ## jjのVS Code拡張・GUI・TUI `jj tui` や `jj gui` というコマンドは存在しません。画面で操作したい場合は、いずれもコミュニティ製の次のツールを入れます（版と更新日は2026年10月24日時点）。 | ツール | 種類 | 最新版（公開日） | ライセンス | | -------------- | ------------- | ------------------- | ------------------ | | Jujutsu Kaizen | VS Code拡張 | 0.11.0（2026-05-29） | MIT | | VisualJJ | VS Code拡張 | 0.36.1（2026-10-18） | プロプライエタリ | | Jujutsu X | VS Code拡張 | 1.16.2（2026-10-03） | AGPL-3.0（継承部分はMIT） | | GG | デスクトップGUI | 0.46.0（2026-10-20） | Apache-2.0 | | jjui | TUI | 0.10.12（2026-10-17） | MIT | | lazyjj | TUI（Lazygit風） | 0.6.1（2025-09-10） | Apache-2.0 | | jj-fzf | TUI（fzfベース） | 0.42.0（2026-08-11） | MPL-2.0 | ### VS Code拡張：Jujutsu KaizenとVisualJJ VS Codeのマーケットプレイスで「jujutsu」と検索すると、呪術廻戦のテーマ拡張が上位に混ざります。拡張機能ビューで拡張IDを指定して探すのが確実です。インストール数は2026年10月24日時点で、Jujutsu Kaizenが約1万、VisualJJが約1.2万です。 - **Jujutsu Kaizen**（`jjk.jjk`）：[ソースはGitHubで公開](https://github.com/keanemind/jjk)されているMITライセンスの拡張です。作業コピーと親の変更の差分表示、行単位のblame、作業コピーから親への特定行の移動、`jj undo` と以前の状態への復元に対応します。jj本体は別に入れておく必要があり、PATHに無いときは設定 `jjk.jjPath` で場所を指定します。 - **VisualJJ**（`visualjj.visualjj`）：変更のツリーを専用ビューに出し、split・squash・ドラッグ＆ドロップでの並べ替え・revert・duplicateと、GitHubのプルリクエスト作成までを画面から行えます。jj は内蔵されているため別途のインストールは不要で、Local・WSL・SSH・Dev Containersに対応します。ライセンスはプロプライエタリで、個人の開発者は業務利用でも無料、日常的に使うチーム向けに有料のProがあります。 OSSで揃えたいならJujutsu Kaizen、スタックしたプルリクエストを画面で組みたいならVisualJJです。ただしJujutsu Kaizenは2026年5月以降リリースがありません。VS Code標準のGit表示も同居リポジトリなら動きますが、detached HEADとして出るだけなので、変更の単位で見るには専用の拡張が要ります。 ### デスクトップGUI：GG GG（`gulbanana/gg`）はmacOS・Windows・Linuxで動くデスクトップアプリで、`gg web` でブラウザ版としても起動できます。版番号を jj 本体に合わせており、0.46.0（10月20日）が最新です。 ``` brew install --cask gg # macOS winget install --id gulbanana.gg # Windows cargo install --locked gg-cli # どのOSでも ``` リリースページには `.dmg`・`.msi`・`.AppImage`・`.deb`・`.rpm` が並びますが、READMEはLinux向けの配布物を「Windows・macOSほど検証されていない」と書いています。GG自体はjj本体が無くても動きますが、GGが扱わない操作のためにjjも入れておくことを勧めています。 ### TUI：jjui・lazyjj・jj-fzf 端末向けのjjuiは、2026年10月17日に0.10.12を公開しています。GitHubのスター数は約2,200です。`brew install jjui`、`winget install IbrahimDursun.jjui`、Scoopのextrasバケットで入ります。Gitで[Lazygit](/tech/details/9393/)に慣れている人にはlazyjj（`cargo install lazyjj --locked`）の画面構成が近いものの、最後のリリースが2025年9月の0.6.1で止まっている点は考慮に入れてください。 ## よくある質問 ### Jujutsuの読み方は？Googleの製品ですか？ 「ジュジュツ」と読み、コマンド名は `jj` です。作者はGoogle社員で、Googleでの本人の専任プロジェクトですが、READMEに「Googleのサポート対象製品ではない」と明記されたコミュニティ主導のOSSです。 ### jjでgit cherry-pickに当たるコマンドは？ `jj duplicate <コピー元> -o <コピー先>` です。0.46.0で試すと「Duplicated 3995efba19d0 as lvlmxoso a4ae0d7c add b」と表示され、同じ内容・同じメッセージで新しいchange IDのコミットが作られました。コミットを「移動」したいだけなら `jj rebase -r <対象> -o <移動先>` を使います。 ### jj logに全部の履歴が表示されないのはなぜ？ 既定の表示範囲（`revsets.log`）が、今の作業コミット、書き換え可能なコミットとその近くの祖先、trunkだけを選ぶ式になっているためです。`jj log -r ::` で全履歴、`jj log -r 'trunk()..@'` でメインブランチから今の作業までが出ます。 ### jjの設定ファイルはどこにありますか？ Linux・macOSは `~/.config/jj/config.toml`、Windowsは `%APPDATA%\jj\config.toml` です。`jj config path --user` で実際の場所を、`jj config edit --user` でエディタを開けます。環境変数 `JJ_CONFIG` を設定するとこれらの場所は読まれなくなります。 ### Jujutsuをやめて普通のGitに戻せますか？ 同居（colocate）で使っていれば戻せます。リポジトリ直下の `.jj` ディレクトリを削除し、`git switch main` などでブランチに戻るだけです。jj で作ったコミットは既に `.git` に書かれているため消えませんが、ブックマークを付けていないコミットはGitからはブランチの無いコミットに見えるので、削除前に `jj bookmark create` で名前を付けておきます。 ## 関連記事 - [git rebaseとは？使い方・mergeとの違い・コンフリクト解決とやり直しを解説](/tech/details/8926/) - [コンフリクトとは？Gitで変更が衝突する仕組みと解消手順・予防設計を実装視点で解説](/tech/details/13562/) - [Git Worktree（ワークツリー）とは｜使い方・削除(remove/prune)とsubmodule併用の注意点](/tech/details/7018/) - [Lazygitの使い方｜Windowsのインストール（winget・Scoop）とショートカット【v0.66対応】](/tech/details/9393/) - [Git for Windowsの最新版は2.56.0｜ダウンロード・インストール手順と更新方法【2026年10月】](/tech/details/11868/) --- 出典: [Jujutsu（jj）とは？Git互換VCSのインストール・使い方とGitとの違い]()（株式会社一創）