worktrunkとは｜git worktree管理CLIの使い方【2026年9月】

夕方、Claude Code に「認証まわりの修正」「ページングのバグ取り」「APIテスト追加」の3つを投げた直後に、同僚から「さっきのブランチ、ちょっと動かして見せて」と言われる。手元のリポジトリは1つしかないので、エージェントが書き換えている最中のファイルを避けて git stash を打つか、いったんエージェントを止めるかの二択になります。この「1つの作業ディレクトリを全員で取り合う」状態を畳むために生まれたのが、git worktree 管理 CLI の worktrunk です。

worktrunk が引き受けているのは「ブランチ切り替え」ではなく「同時進行」

git の worktree は、1つのリポジトリに複数の作業ディレクトリをぶら下げる機能です。履歴とリモート情報は共有したまま、チェックアウトされたファイルと index だけを分離するので、エージェントA が feature-a を書き換えている横でエージェントB が feature-b を触っても衝突しません。README はこの前提を出発点に置き、「Claude Code や Codex は監督なしで長いタスクを回せるようになり、5〜10個以上を並列で管理できる」と書いています。

ただ、機能があることと、毎日使えることは別です。README が挙げている不満は具体的で、「新しい worktree を1つ作るだけでも、ブランチ名を3回打たされる」。実際、素の git では次のようになります。

# プレーンな git worktree の一周（公式 FAQ の記載例）
git worktree add -b feature-auth ../myproject.feature-auth main
cd ../myproject.feature-auth
# ...作業してコミットしてプッシュ...
cd ../myproject
git merge feature-auth
git worktree remove ../myproject.feature-auth
git branch -d feature-auth

worktrunk 側では、同じ一周がこうなります。

# worktrunk の一周
wt switch --create feature-auth   # ブランチ＋worktree を作り、セットアップフックを走らせて移動
# ...作業...
wt merge                          # 既定ブランチへ取り込み、worktree とブランチを片付ける

ポイントは cd が消えていることです。worktree はパスではなくブランチ名で呼ぶ設計で、実際のパスは設定テンプレートから機械的に決まります。wt merge は作業中の worktree から実行して既定ブランチへ入れる——GitHub の「Merge pull request」ボタンをローカルで押すイメージです。ブランチ名を取る引数は worktree のパスも受け付けるので、detached な worktree や同一ブランチの二重チェックアウトも指せます。

3コマンドの対応関係

やりたいこと	worktrunk	素の git
worktree を移動する	wt switch feat	cd ../repo.feat
作成して Claude Code を起動する	wt switch -c -x claude feat	git worktree add -b feat ../repo.feat → cd → claude
一覧を状態つきで見る	wt list	git worktree list（パスのみ）
片付ける	wt remove	cd → git worktree remove → git branch -d

公式 FAQ は、素の git worktree に足りないものを「命名とクリーンアップの検証」「プロジェクト固有の自動化」「全 worktree を横断した状態表示」の3点と整理しています。worktrunk が足しているのは、まさにこの3点です。

インストールと初期設定：シェル統合まで入れて完了

配布は主要なパッケージマネージャに一通り出ています。どの経路でも、直後に wt config shell install を実行するのが定型です。飛ばすと wt switch を打ってもシェルのカレントディレクトリが動きません（コマンドは成功し、移動できない旨の警告が出ます）。

環境	コマンド	注意点
macOS / Linux（Homebrew）	brew install worktrunk && wt config shell install	いちばん短い経路
Rust 環境（Cargo）	cargo install worktrunk && wt config shell install	既定フィーチャーは bash 構文ハイライト用に C99 コンパイラが必要
Windows（winget）	winget install max-sixty.worktrunk → git-wt config shell install	wt は Windows Terminal のコマンドと衝突するため git-wt として入る
Arch Linux	sudo pacman -S worktrunk && wt config shell install	—
Conda / Pixi	conda install -c conda-forge worktrunk && wt config shell install	feedstock はコミュニティ管理

Cargo 経由で tree-sitter の C コンパイルに失敗する場合は、公式 FAQ が回避策を示しています（構文ハイライトが消えるだけで中核機能は残ります）。

# C99 コンパイルが通らない環境向け（bash構文ハイライトを外す）
cargo install worktrunk --no-default-features --features cli

シェル統合は bash / zsh / fish / nushell / PowerShell に対応。現状確認は wt config show、ユーザー設定ファイル（~/.config/worktrunk/config.toml）の作成は wt config create です。動作要件は Git 2.43 以上なので、古い LTS 環境では先に git --version を見ておくと早いです。

作成から片付けまで、1本の流れとして通してみる

ここからは実際のコマンド列です。動作環境は macOS / Linux、Git 2.43 以上、worktrunk v0.79.0 を前提にしています（本番リポジトリで試す前に、必ず使い捨てのクローンで挙動を確かめてください）。

# 1) 新しいブランチと worktree を作って移動する
wt switch --create feature-auth
# ✓ Created branch feature-auth from main and worktree @ ~/repo.feature-auth

# 2) 既定ブランチ以外から生やす
wt switch --create hotfix --base production

# 3) いま開いている PR のブランチへ飛ぶ
wt switch pr:123
wt switch 
PH_0_   # URL 貼り付けでも同じ

# 4) 直前の worktree に戻る（cd - と同じ感覚）
wt switch -

--create なしなら既存ブランチが対象で、ローカルに無く origin/feature だけある場合は追跡ブランチを作ります。ショートカットは ^（既定ブランチ）、@（現在）、-（直前）、pr:{N} / mr:{N}。--base にも使えるので wt switch --create fix --base=@ でスタック運用も1行です。PR/MR 参照には gh や glab などの認証済み CLI が必要で、fork の PR では refs/pull/N/head を取得して push 先を fork に向けてくれます。

引数なしで wt switch を叩くと対話ピッカーが開きます。diff・working・committed・log・remote・summary・pr・comments の8つのプレビュータブを Alt-1〜Alt-8 で切り替えながら戻る先を選べ、Alt-c で新規作成、Alt-x で削除、Alt-o で PR をブラウザに開けます。--branches / --remotes / --prs を足せば、worktree を持たないブランチやオープン中の PR も候補に入ります。

片付け：wt merge と wt remove

wt merge は単なるマージではなく、8段のパイプラインです。公式ドキュメントの順序は、コミット → スカッシュ → リベース → pre-merge フック → 早送りマージ → pre-remove フック → worktree とブランチの削除 → post-remove / post-merge フック（バックグラウンド）。既定はスカッシュ＋リベース＋ fast-forward なので、履歴は直線に保たれます。

wt merge                 # 既定ブランチへ
wt merge develop         # 取り込み先を指定
wt merge --no-squash     # 個々のコミットを残す
wt merge --no-ff         # マージコミットを作る
wt merge --no-remove     # マージ後も worktree を残す
wt merge --no-commit --no-rebase   # 手で整えたコミットグラフをそのまま渡す

注意点は、wt merge がローカルの取り込み先ブランチにマージし、fetch はしないことです。リモートの main が進んでいるなら先に自分で fetch します。リベース中にコンフリクトが出るとマージは止まり、リベースが開いたまま worktree に残るので、そこで解決するか abort します。

wt remove は既定で「取り込み先に何も足さないブランチ」だけを消します。判定は6条件（同一コミット／祖先／三点diff が空／ツリー SHA 一致／マージしても差分なし／patch-id 一致）で、スカッシュやリベースで履歴が違っても内容が同じなら消せる設計です。強制フラグは2種類あり、用途が違うので取り違えないでください。

フラグ	対象	使う場面
--force / -f	worktree	未コミットの変更が残っている worktree を消す
--force-delete / -D	ブランチ	未マージのコミットを持つブランチを消す
--no-delete-branch	ブランチ	worktree だけ消してブランチは残す

消されたくない worktree（ローカル DB を置いている等）は git worktree lock でロックできます。ロックされた worktree は wt remove でも wt merge でも、--force を付けても削除されません。削除処理は既定でバックグラウンド実行され、ログは .git/wt/logs/{branch}/internal/remove.log に出ます。待ちたいときは --foreground です。

wt list の読み方と、エージェント稼働マーカー

並列で走らせ始めると「どの worktree がいま何をしているか」が最大の関心事になります。wt list はブランチ名・パス・コミットハッシュを即座に描画し、状態や乖離の列は裏の git 処理が終わり次第で埋まります。

wt list                 # 通常表示
wt list --full          # CI ステータスと LLM 生成のブランチ要約を追加
wt list --branches      # worktree を持たないブランチも含める
wt list --format=json   # スクリプト用

行頭の @ が現在の worktree、^ が既定ブランチ。ステータス列の + はステージ済みの変更、↑1 は既定ブランチより1コミット先行、⇡ は未プッシュのコミットです。ブランチ削除の判定に使う _（同一コミット）や ⊂（取り込み済み）もここに出るため、「消していい行」が目で分かります。ネットワークに出る CI 列と LLM 要約列は --full のときだけ加わります。

プラグインを入れていると、この一覧に 🤖（作業中） と 💬（入力待ち・アイドル） が並びます。セッション終了時に消えますが、プロセスを強制終了すると残ることがあり、その場合は wt config state marker clear で手動クリア。マーカーの実体は git config なので、プラグインが無いツールでもセッション開始・ターン終了・終了の3イベントで wt config state marker set "🤖" を呼べば同じ表示になります。

並列運用を支える3つの仕掛け：フック・ビルドキャッシュ・ポート採番

フック（10種類）で worktree を「使える状態」で生む

worktree を作った直後に依存が入っていない、環境変数ファイルが無い——という状態だと、エージェントは最初の数分を環境構築で溶かします。フックは switch / create / commit / merge / remove の5イベント × pre / post の10種類。pre-* はブロッキング（失敗すると操作を中断）、post-* はバックグラウンド実行です。

# .config/wt.toml（プロジェクト設定・git管理下）
# 依存インストールが終わってから、ビルドと dev サーバーを同時に走らせる
[[post-start]]
install = "npm ci"

[[post-start]]
build = "npm run build"
server = "npm run dev"

# マージ前にテストとlintを通す（失敗したらマージを止める）
[[pre-merge]]
test = "npm test"
lint = "npm run lint"

文字列なら単一コマンド、テーブルなら同時実行、[[...]] の配列なら順番待ちのパイプライン、という3つの書き分けです。公式ドキュメントは「後の工程が完了を必要としない限り pre-start より post-start を優先せよ」と明記しています——ブロッキングフックに重いビルドを置くと、worktree を作るたびに数分待たされるためです。確認は wt hook show --expanded と wt hook <type> --dry-run で行えます。

プロジェクト設定のコマンドは初回実行時に必ず承認プロンプトが出ます。.config/wt.toml はクローン先に含まれる任意のシェルコードなので、承認前は何も実行されません。承認は ~/.config/worktrunk/approvals.toml にプロジェクト単位で保存され、コマンド文字列が変わると再承認が必要——承認済みのフックを別コマンドにすり替える経路が塞がれています。

ビルドキャッシュを「コピーせずに」共有する

worktree を10個作ると、node_modules/ や target/ を10回ビルドし直すことになります。wt step copy-ignored は gitignore 対象のファイルを別 worktree から持ち込むコマンドで、APFS・btrfs・XFS ではコピーオンライトが効きます。

# .config/wt.toml
[post-start]
copy = "wt step copy-ignored"

# .worktreeinclude（gitignore と同じ記法で「持ち込む対象」を絞る）
.env
node_modules/
target/

既定では gitignore 対象がすべて運ばれ、VCS メタデータやツール状態のディレクトリだけ除外されます。.worktreeinclude を置くと「gitignore 対象かつこのファイルに書かれたもの」に絞られます。コピー先に既にあるファイルはスキップされるので再実行は安全（上書きは --force）、--require-include を付ければ .worktreeinclude が無いリポジトリでは何もしません。

worktree ごとに dev サーバーのポートを固定する

並列作業で地味に困るのが dev サーバーのポート衝突です。hash_port フィルターはブランチ名から 10000〜19999 の範囲で決定的にポートを割り当て、同じブランチならどのマシンでも同じ番号になります。

# .config/wt.toml
[post-start]
server = "wt step tether -- npm run dev -- --port {{ branch | hash_port }}"

[list]
url = "http://localhost:{{ branch | hash_port }}"

wt step tether はプロセスグループごとサーバーを起動し、worktree が削除されるときにグループ全体を落とします。pre-remove フックで後始末を書かなくても、消したら止まる。[list] url を設定しておくと wt list に URL 列が出て、サーバーが動いていない行は淡色になります。

もう1つ、wt remove --reap（実験的機能）は worktree 配下をカレントディレクトリにしているプロセス（dev サーバー、ファイル監視、言語サーバー）を SIGTERM → SIGKILL の順で落としてから削除します。実験的な位置づけなので、まずは tether で設計しておくほうが安全です。

Claude Code / Codex との接続は「プラグインを入れる」だけ

worktrunk はエージェント CLI ごとにプラグインを配っていますが、提供機能はホスト側が公開しているフックに依存して差があります。

機能	Claude Code	Codex	OpenCode	Pi / oh-my-pi	Gemini CLI
設定スキル（/worktrunk）	○	○	—	—	○
稼働トラッキング（🤖/💬）	○	○	○	○	○
worktree 隔離の差し替え	○	—	—	—	—
/wt-switch-create スキル	○	△（ディレクトリ変更ができず実質無効）	—	—	△（同左）

# Claude Code
wt config plugins claude install
# 手動で同じことをする場合
claude plugin marketplace add max-sixty/worktrunk
claude plugin install worktrunk@worktrunk

# Codex
wt config plugins codex install

# OpenCode / Pi / oh-my-pi
wt config plugins opencode install
wt config plugins pi install
wt config plugins omp install

# Gemini CLI（wt のラッパーは無く、拡張として直接入る）
gemini extensions install 
PH_1_

隔離の差し替えが Claude Code 限定なのは、worktree ライフサイクルのフック（WorktreeCreate / WorktreeRemove）を公開しているのが Claude Code だけだからです。プラグインを入れると、git worktree add で作られていた隔離 worktree が wt switch --create と wt remove を通り、命名規約もフックも worktrunk 側に揃います。サブエージェント隔離まわりの前提はClaude Codeが塞いだサブエージェントの権限の穴とはでも触れています。

ステータスラインも用意されています。~/.claude/settings.json に次を足すと、現在の worktree・変更行数・先行コミット数・PR 番号などが1行で出ます（Claude Code がバックグラウンド実行するため、CI 取得の1〜2秒は体感に出ないと説明されています）。

{
  "statusLine": {
    "type": "command",
    "command": "wt list statusline --format=claude-code"
  }
}

並列エージェントの起動パターン

README が例に挙げているのは、-x（switch 後に実行するプログラム）と -- 以降の引数受け渡しを使う形です。

wt switch -x claude -c feature-a -- 'ユーザー認証を追加して'
wt switch -x claude -c feature-b -- 'ページングのバグを直して'
wt switch -x claude -c feature-c -- 'APIのテストを書いて'

# エイリアスにしておくと1語で済む
alias wsc='wt switch --create --execute=claude'
wsc feature-auth -- 'GH #322 を直して'

バックグラウンドに逃がすなら tmux や Zellij と組み合わせます（公式 tips には tmux new-session -d -s <name> "wt switch --create <branch> -x claude -- '<task>'" の形が載っています）。エージェント側にこのパターンを使わせたい場合は CLAUDE.md / AGENTS.md に明記する、というのが公式の案内です。裏返せば、明示しない限りエージェントが勝手にセッションを増やすことはありません。

1つの Claude Code セッションからサブエージェントを撒く場合は、親側で wt switch --create <branch> --no-cd し、そのパスをプロンプトで渡す形が推奨されています。worktrunk のスキルは Agent ツールの isolation: "worktree" をこの用途に使わないよう明記しています——Claude Code が内部のエージェント ID を worktree 名に渡すため myproject.agent-<id> のような非正規パスと使い捨てブランチができ、その上で機能ブランチを切ると孤児ブランチや誤ったフック対象が残るためです。

つまずきやすい5点と、その回避

ドキュメントと CHANGELOG から、実務で刺さりやすいものを抜き出しました。

❌ エージェントに wt merge を実行させたら「Cannot prompt for approval in non-interactive environment」で止まった → --yes を付けさせる
⭕ 人間が wt config approvals add を対話で通す。worktrunk のスキル自身が「承認はエージェントではなくユーザーの判断」と明記しています。--yes はその場のゲートを飛ばすだけ、wt config approvals add --yes は誰も読まないまま全コマンドを承認済みにします。どちらも CI / コンテナ向けで、対話エージェントが承認プロンプトを黙らせる近道ではありません。

❌ Windows で wt switch を叩いたら Windows Terminal が開いた
⭕ winget 版は git-wt という名前で入るので git-wt config shell install から始めます。wt を使いたい場合は Windows の「アプリ実行エイリアス」で Terminal 側を無効化します。Git Bash / MSYS2 から実行すると SHELL が設定されている関係で PowerShell プロファイル作成がスキップされるため、wt config shell install powershell を明示します。

❌ wt list が 120 秒でタイムアウトする
⭕ 多くは git fsmonitor--daemon のハングが原因だと公式トラブルシュートが説明しています。core.fsmonitor=true の worktree でデーモンが詰まると git status が IPC 待ちでブロックし、先に 120 秒の期限が来ます。該当 worktree で git --no-optional-locks status --porcelain を叩いて確認を。消えた worktree のデーモンは wt remove が掃除するので、手動で落とすのは生きている worktree の分だけです。

❌ v0.79.0 に上げたら --no-cd -x <program> の挙動が変わった
⭕ 破壊的変更として CHANGELOG に明記されています。従来は呼び出し元のディレクトリでプログラムが起動していたため {{ worktree_path }} を渡す必要がありましたが、0.79.0 からは --no-cd が「自分のシェルだけ動かさない」という意味になり、プログラム自体は新しい worktree で起動します。呼び出し元ディレクトリで動かしたいスクリプトは、明示的に cd を入れて直します。同じリリースでは wt step rebase / wt merge が --no-update-refs を渡すようになり、rebase.updateRefs で他のローカルブランチが動かなくなった点も破壊的変更として挙がっています。

❌ 残ってほしい worktree が消えた／消えないはずのブランチが消えた
⭕ 削除の境界を先に決める。消えてほしくない worktree は git worktree lock --reason "..." でロックします（ロック済みはあらゆる削除経路で守られます）。逆に、履歴が違っても内容が同じなら消える設計なので「未マージだから残るはず」で運用しないこと。スカッシュで作業ツリーの変更が巻き込まれる場合は、事前に refs/wt-backup/<branch> へバックアップが取られます。

プレーンな git worktree、GUI 系ツールとの住み分け

worktrunk が常に最適とは限りません。公開情報から、正直に線を引いておきます。

プレーンな git worktree が勝つ場面：worktree を作るのが週1〜2回、同時に走るのが1本なら、ツールを1つ増やすコストのほうが大きいです。worktrunk は Git 2.43 以上を要求し、シェル統合を rc ファイルに書き、承認ファイルや .git/wt/ 配下のメタデータを作ります。公式 FAQ が作成ファイルと削除され得る対象を明示しているので、そこを読んでから入れる種類のツールです。使い捨ての CI コンテナでは素の git のほうが読みやすいこともあります。

GUI / デスクトップ型が勝つ場面：diff レビューを画面で回したい、非エンジニアも触る、という前提なら、各ワークスペースに worktree を割り当てるデスクトップ型オーケストレーターのほうが摩擦は少ないはずです。worktrunk は純粋な CLI で、ピッカーのプレビューはあってもレビュー体験そのものを置き換える設計ではありません。

git-machete / git-town、lazygit などの TUI：公式 FAQ はスコープ違いとして整理しています。前者2つは「1ディレクトリ内のブランチスタック・ワークフロー管理」、TUI は「1リポジトリの操作」、worktrunk は「複数 worktree の管理・自動化・横断ステータス」。併用が前提で、各 worktree の中で machete や lazygit を動かす形になります。

エージェント CLI 側のネイティブ機能：worktree の扱いはエージェント側にも実装が進んでいます。GitHub Copilot CLI の worktree 対応の流れはGitHub Copilot CLI worktree対応｜v1.0.78を検証で追っていますし、並列エージェント専用の統合環境という方向もあります（Orca(Stably)とは｜並列エージェントADEの使い方）。1つのエージェントしか使わず、そのエージェントが worktree を面倒見てくれるなら、それで足ります。worktrunk が効くのは、複数のエージェント CLI と人間の手作業が同じリポジトリに同居していて、片付けのルールを1か所に置きたいときです。

ホスティング側との連携は、Claude Code GitLab連携完全ガイドやCodex GitHub Action入門｜PR自動レビューのような PR 起点の自動化と組み合わせると全体像が見えます。pre-merge フックに検証を置き、リモート CI は最終確認に回す二段構えが、公式ドキュメントの言う「ローカル CI」の発想です。

よくある質問

git worktree とは何ですか？

1つの git リポジトリに複数の作業ディレクトリを同時に持てる機能です。履歴やリモート設定は共有したまま、チェックアウトされたファイルと index だけを分離します。ブランチを切り替えるのではなく、ブランチごとにディレクトリがある状態になるため、片方で作業中でも別ブランチをビルド・実行できます。

worktrunk と素の git worktree コマンドの違いは？

範囲が違います。素の git は worktree の作成・一覧・削除までで、命名規約もセットアップ自動化も横断ステータスも自前です。worktrunk はそこを引き受け、ブランチ名で worktree を指す前提に統一したうえでフック・ビルドキャッシュ共有・CI 表示を足しています。

Claude Code や Codex と一緒に使えますか？

そのための設計です。wt config plugins claude install / wt config plugins codex install でプラグインが入り、wt list に稼働マーカーが出ます。Claude Code だけは worktree ライフサイクルのフックを公開しているため、隔離 worktree の作成自体を worktrunk 経由に差し替えられます。

worktree の削除や後片付けはどうなりますか？

wt merge はマージ後に worktree とブランチを自動で片付けます（--no-remove で保持）。単体で消すなら wt remove。未コミットの変更があれば --force、未マージのブランチには -D が必要で、git worktree lock 済みはどの経路でも削除されません。

ライセンスと動作要件は？

ライセンスは MIT OR Apache-2.0 のデュアルライセンス、実装言語は Rust です。動作要件は Git 2.43 以上。2026年9月23日（JST）時点の最新リリースは v0.79.0 です。

最後に確認すべきこと

導入を決める前に、次の3点だけは自分の環境で確かめておくと事故が減ります。

1. Git のバージョンとシェル統合：git --version が 2.43 以上か。wt config show でシェル統合が有効か。ここが抜けていると「コマンドは成功するのに移動しない」という分かりにくい状態になります。
2. 削除の境界：どの worktree が消えてよくて、どれがロック対象か。ローカル DB や生成物を抱えている worktree は先に git worktree lock をかけておく。承認は wt config approvals add を人間が通し、エージェントに --yes を託さない。
3. フックの重さ：pre-start に重いビルドを置いていないか。worktree を1つ作るたびに待たされる構造になっていないか。重い処理は post-start に逃がし、検証は pre-merge に集めるのが公式の推奨です。

worktrunk は「エージェントを賢くするツール」ではなく「何本走らせても散らからないようにするツール」です。1本しか走らせないなら不要ですし、3本以上を日常的に走らせているなら、ブランチ名を3回打つ作業と後片付けの取りこぼしが先に消えます。

運営元 Uravation よりAIエージェントを構想から本番運用まで進める順番と、体制・KPIの決め方をまとめた資料を無料で公開しています。 AIエージェント導入ロードマップを受け取る（無料）

参考・出典

• max-sixty/worktrunk — GitHub リポジトリ（README・スター数・ライセンス・実装言語） — GitHub（参照日: 2026-09-23）
• Worktrunk 公式ドキュメント（worktrunk.dev） — Worktrunk（参照日: 2026-09-23）
• wt switch — コマンドリファレンス（ショートカット・ピッカー・PR/MR・-x） — Worktrunk（参照日: 2026-09-23）
• wt merge — 8段パイプラインと各種フラグ — Worktrunk（参照日: 2026-09-23）
• wt remove — ブランチ削除の6条件・強制フラグ・バックグラウンド削除 — Worktrunk（参照日: 2026-09-23）
• wt hook — 10種類のフックと承認の仕組み — Worktrunk（参照日: 2026-09-23）
• Agent Integration — Claude Code / Codex / OpenCode / Pi / Gemini CLI 連携 — Worktrunk（参照日: 2026-09-23）
• FAQ — 他ツールとの比較・作成されるファイル・削除対象・システム要件（Git 2.43以上） — Worktrunk（参照日: 2026-09-23）
• wt step — copy-ignored・tether ほかの下位コマンド — Worktrunk（参照日: 2026-09-23）
• Release 0.79.0（2026年9月21日公開） — GitHub（参照日: 2026-09-23）
• CHANGELOG.md — 0.79.0 / 0.78.0 の破壊的変更 — GitHub（参照日: 2026-09-23）

あわせて読みたい

• Claude Codeが塞いだサブエージェントの権限の穴とは — worktree 隔離と権限の線引き
• Claude Code GitLab連携完全ガイド — ローカルの worktree 運用をリモートの PR/MR フローに接続する
• GitHub Copilot CLI worktree対応｜v1.0.78を検証 — エージェント CLI 側のネイティブ対応の動き

著者：佐藤傑（さとう・すぐる）。株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。著書『AIエージェント仕事術』。

あわせて読みたい

• ▸ DevinがmacOS対応｜できること・設定・注意点【2026年9月】
• ▸ WeKnora導入手順｜Tencent製RAG基盤をDockerで【2026年9月】
• ▸ Kevとは｜Jev風オープン判断モデルをローカルで動かす【2026年9月】
• ▸ Jev API実装パターン7つ｜Pythonコード例【2026年9月】
• ▸ Agent-Reachとは｜AIエージェントにXとRedditを読ませる