最近、海外のエンジニアコミュニティを中心に Jujutsu という新しいバージョン管理システム（VCS）が密かに注目を集めています。
「Gitの代替」と紹介されることもありますが、正確にはGitをバックエンドに利用しており
Gitの設計上の課題を、現代的なモデルで再設計したVCS
と言えると思います。
Jujutsuとは？
Jujutsu は、分散型バージョン管理システム（DVCS）です。
設計思想としては Git と同じ分散型ですが、操作モデルと内部設計が大きく異なります。
最大の特徴は次の点です。
-
既存のGitリポジトリ上でそのまま使える
-
GitHub / GitLab / CI/CD を変更せず利用可能
-
内部モデルはGitとは別設計
つまり、JujutsuはGitを置き換えるというより、
Gitの上に安全で柔軟な操作レイヤーを載せるツール
という位置づけです。
実際、jj git init --colocate を使えば、既存の .git ディレクトリと共存する形で利用できます。
Gitユーザーが段階的に試せる点は、導入の現実性という意味で非常に重要です。
Macの場合、Jujutsuの導入は brew install jj
これだけでできます。
Jujutsuの基本コマンドは jj です。
また設定は、
jj config set --user user.name "ユーザー名"
jj config set --user user.email "メールアドレス"
で行います。
なぜJujutsuが注目されているのか
Gitは極めて優れたツールですが、実務では次のような「つらさ」を感じた経験がある人も少なくないと思います。
-
rebaseで意図せず履歴を壊して絶望した
-
stash・index・detached HEAD など概念が複雑で難しい
-
並行作業でブランチが乱立し管理不能になった
-
コンフリクト解消がすごくストレスになった
これらはGitが 「履歴の不変性」 を強く前提とした設計であることに起因しています。
Jujutsuはこの前提を見直し、
履歴は編集される前提の作業ツリーであり、確定するのは最後でよい
という設計です。
その結果、
-
履歴の編集が安全
-
並行作業が自然
-
コンフリクトが作業状態として保持される
といった、現代的な開発スタイルに合った操作感が実現されています。
Gitと何が違うのか
1. ステージングエリアが存在しない
Gitでは変更をコミットするのに、
git add
git commit
という2段階の操作が必要です。
一方、Jujutsuには ステージング（index）という概念がありません。
常にワーキングコピーの内容がそのまま変更対象になります。
jj describe -m "Fix login bug"
これで「コミット相当」の操作が完了します。
※差分を確認したい場合はjj diffが使えます
これにより、
-
add忘れ
-
indexの状態が分からなくなる
などがなくなります。
2. 「コミット」ではなく「変更（Change）」が基本単位
Gitではコミットが原則です。
修正するには rebase や fixup などの履歴編集が必要になります。
Jujutsuでは Change（変更） という概念が基本単位で、
-
メッセージ修正
-
差分の分割
-
他Changeとの統合
-
並び替え
といった操作により安全に操作できるよう設計されています。
「履歴編集は例外」ではなく「履歴編集が通常」
という思想で作られています。
Gitでも同じことはできますが、Jujutsuではそれが操作モデルの前提になっている点が本質的な違いです。
3. コンフリクトが「状態」として保存される
Gitではコンフリクトが発生すると、
すぐにすべて解決しないと次に進めない
という制約があります。
Jujutsuでは、コンフリクトは
-
作業途中の状態として保持される
-
解決せずに別作業へ進める
-
後から何度でも再解決できる
という扱いになります。
つまり、コンフリクトも 中断可能な作業単位 として管理されます。
複数タスクを並行で進める実務環境では、非常にありがたい設計です。
以下記事でも紹介されているように、最近ではAIエージェントによる並行開発も主流になってきており、コンフリクトの扱いという面でJujutsuは非常に有効な手段の一つになります。
4. ブランチレスに近い並行作業モデル
Jujutsuでは、次のように同一ベースから複数作業を簡単に作れます。
jj new main -m "Experiment A"
jj new main -m "Experiment B"
これらはGitのブランチというより、「まだ統合されていない作業ツリー」として扱われます。
実際の開発フローはどう変わるか
# 既存GitリポジトリでJujutsuを有効化
jj git init --colocate
# 差分確認
jj diff
# 変更に説明をつける（commit相当）
jj describe -m "Add signup validation"
# 別作業を並行で開始
jj new main -m "Refactor auth middleware"
# 不要な変更を破棄
jj abandon
# 変更をまとめる
jj squash
Gitに慣れている人ほど最初は戸惑いますが、
-
ブランチを切る意識
-
rebaseのミスできない緊張感
などがなくなり、
「とりあえず試してから整理する」という開発スタイルに非常に向いています。
Git互換性と導入の現実性
Jujutsuの最大の実用的メリットは Git互換を前提に設計されている点 です。
-
.gitをそのまま利用 -
GitHub / GitLab / CI そのまま利用
-
チームの一部だけ Jujutsu を使うことも可能
全面移行が必須ではなく、個人単位・段階導入が可能、というのが大きな強みです。
そのため、まずは個人のローカル操作改善として導入し、慣れてきたらチーム展開、という流れも可能です。
現時点での留意点（2026年1月）
1. エコシステムはまだ発展途上
CLIはかなり成熟していますが、
-
GUIクライアント
-
IDE統合
-
社内ツール連携
はまだGitほど充実していません。
ターミナル中心の開発スタイルの方が導入しやすいのが現状です。
ただ、このあたりは機能も徐々に増えていくのでエコシステムの成熟も時間の問題だと思います。
2. 学習コストが存在する
コマンドは少ないですが、Gitと考え方が根本的に異なります。
-
ブランチ中心思考から作業ツリー中心思考へ
-
履歴＝確定過去 という感覚からの脱却
この切り替えに少し時間がかかると思います。
が、これも慣れの問題かと。
3. 超大規模組織での導入実績はまだ限定的
超大規模での全社導入実績は現時点では限定的です。
今後、どのようにシェアが拡大していくか注目です。
どんな人・チームに向いているか
向いているケース
-
Gitのrebase・stash・index周りにストレスを感じている
-
履歴整理を後からまとめて行う文化がある
-
並行作業が多く、ブランチ管理が煩雑
-
ローカルで安全に試行錯誤したい
向いていない可能性があるケース
-
GUIクライアントを絶対使わないといけない
-
Gitのワークフローに完全に慣れている
-
大規模組織での導入実績がないと使うのが不安
この場合は、もう少し成熟を待つ判断も合理的です。
まとめ
Jujutsuは「Gitの代替」というより、
Gitの設計思想を現代的にアップデートした次世代VCS。
-
ステージング廃止による操作単純化
-
履歴編集を前提とした安全設計
-
コンフリクトと並行作業の柔軟性
は、現代の開発スタイルと非常に相性が良い特徴です。
Gitに違和感を覚えたことがある人ほど、
一度は触ってみる価値のあるVCSと言えるでしょう。
参考
-
Jujutsu GitHub Repository
https://github.com/jj-vcs/jj -
公式ドキュメント
https://jj-vcs.github.io/jj/latest/ -
Jujutsu入門
https://zenn.dev/wartemeinnicht/articles/3059bcf2cd186d -
Gitの代替Jujutsuを試してみた
https://qiita.com/gony/items/635cc40b0de5f37c2280 -
複数のGemini CLIが同時開発する狂気 - Jujutsuが実現するAIエージェント協調の新世界
https://speakerdeck.com/gunta/fu-shu-nogemini-cligatong-shi-kai-fa-surukuang-qi-jujutsugashi-xian-suruaiezientoxie-diao-noxin-shi-jie
採用拡大中！
アシストエンジニアリングでは一緒に働くフロントエンド、バックエンドのエンジニアを募集しています！
少しでも興味ある方は、カジュアル面談からでもぜひお気軽にお話ししましょう！
お問い合わせはこちらから↓
https://official.assisteng.co.jp/contact/