Claude Code×git worktree並列開発ガイド【2026年9月】

正直、Claude Code を1枚のターミナルで使っていると、すぐにこの壁にぶつかる。「機能Aを実装させてる最中に、本番でバグが見つかった。でも今のブランチには中途半端な差分が乗っていて、切り替えるには git stash するしかない。戻ってきたら、どこまでやってたか分からなくなる」——この「作業の取り違え」と「ブランチ切替コスト」を構造的に消すのが git worktree だ。

本記事は2026年6月の初版以降に Claude Code 側の worktree 機能が大きく動いた（隔離チェックの全セッション統一 v2.1.222、/fork の worktree 化 v2.1.221、GitLab MR 対応 v2.1.233 など）ため、2026年9月3日時点の git 公式リファレンスと Claude Code 公式ドキュメント（worktrees / cli-reference / settings-reference / sub-agents / hooks / agent-view / changelog）を根拠に全面的に書き直した。

なぜブランチ切替ではなく worktree なのか

多くの人が「並行作業＝ブランチを切り替える」と考えている。だが git checkout（あるいは git switch）は、1つの作業ディレクトリの中身を丸ごと別ブランチの状態に書き換える操作だ。ここに3つの痛みがある。

• 未コミット差分の退避が必須：作業途中で別ブランチに移るには git stash かコミットしかない。stash は積み上がると「どれが何の作業だったか」が分からなくなる。
• 作業の取り違え：同じディレクトリで2つのタスクを切り替えると、ビルド成果物や node_modules が混ざる。Claude Code は今いるディレクトリのファイルを見て編集するので、切替直後の中途半端な状態を前提に動いてしまう。
• 並行作業の衝突：2つの Claude Code セッションを同じディレクトリで動かすと、片方の編集がもう片方のファイルを上書きする。これは事故そのものだ。

git worktree はこの発想を変える。1つのリポジトリ（共有された履歴・remote）に対して、独立した作業ディレクトリを複数ぶら下げる。各ディレクトリは別のブランチをチェックアウトし、自分のファイルを物理的に別の場所に持つ。だから「切り替える」必要がない。Claude Code 公式ドキュメントも「各セッションを自分の worktree で動かせば、片方の編集がもう片方のファイルに触れることはない」と明記している。

worktree が共有するもの・しないもの

worktree は履歴（.git のオブジェクト DB）と remote を共有し、作業ファイル・チェックアウト中のブランチ・ビルド成果物は各ツリー独立だ。git は同じブランチを2つの worktree で同時にチェックアウトすることを既定で拒否する（--force でのみ上書き可能）。「1ツリー＝1ブランチ」で運用すべき理由でもある。

Claude Code 側では、--worktree・git worktree add・デスクトップアプリのどれで作った worktree でも、次の3つがメインチェックアウトと共有される。

• リポジトリの .git：worktree 内の git コマンドはメインの共有 .git に書き込む。サンドボックス有効時も許可され、worktree の中で git commit が通る。
• プロジェクトスコープのプラグイン：メインで入れたプラグインは同じリポジトリの worktree でも読み込まれる（v2.1.200 以降）。
• 権限の承認：worktree セッションで Bash コマンドに「Yes, and don’t ask again」を選ぶと、ルールはメインチェックアウトの .claude/settings.local.json に保存され、他の worktree でも効き、worktree を消しても残る（v2.1.211 以降）。

逆に共有されないのは、gitignore されたローカルファイル（.env など）と依存ディレクトリ（node_modules など）だ。ここは後述の .worktreeinclude と worktree.symlinkDirectories で埋める。

git worktree の基本コマンド

まずは素の git でやってみる。Claude Code の native 機能は内部的にこれを実行しているので、挙動を理解しておくと運用が楽になる。

1. 新しいブランチで worktree を作る。リポジトリのルートで実行する。../ に置くことで、メインのチェックアウトの外に作業ディレクトリができる。

   git worktree add ../project-feature-a -b feature-a

   -b も <commit-ish> も付けなければ、パス末尾の名前と同名のブランチが自動生成される。

2. 既存ブランチで worktree を作る。

   git worktree add ../project-bugfix bugfix-123

   そのブランチが別の worktree でチェックアウト済みなら git は作成を拒否する（--force で強行できるが非推奨）。

3. そのツリーで Claude Code を起動する。

   cd ../project-feature-a && claude

   別ターミナルで ../project-bugfix でも claude を起動すれば、2つのタスクが別ファイル・別ブランチで同時進行する。

4. worktree の一覧を確認する。

   git worktree list

   各ツリーのパス・現在のコミット・ブランチが並ぶ。スクリプトで扱うなら --porcelain。

5. 使い終わったら削除する。

   git worktree remove ../project-feature-a

   未コミット変更や未追跡ファイルが残っているとデフォルトでは消さない（--force が必要。ロック中なら --force を2回）。手動で rm してしまったら git worktree prune で $GIT_DIR/worktrees 配下の管理情報を掃除する。

各 worktree のルートには .git というファイル（ディレクトリではない）が置かれ、本体リポジトリの $GIT_COMMON_DIR を参照している。履歴やリモートは1か所に集約される。ただし worktree は新規チェックアウトなので、依存インストールや仮想環境のセットアップは各ツリーで個別に必要になる。

Claude Code の native worktree 機能（–worktree フラグ）

--worktree（短縮形 -w）は v2.1.49（2026年2月19日）で入ったフラグで、git worktree add を手打ちしなくても、隔離された worktree を作ってその中でセッションを起動してくれる。2026年9月時点の cli-reference では、名前・#<番号>・GitHub の PR URL・GitLab の MR URL のいずれかを受け付ける。

1. 名前を付けて起動する。

   claude --worktree feature-auth

   既定では、リポジトリルートの .claude/worktrees/<名前>/ に worktree を作り、worktree-<名前> という新ブランチをチェックアウトしてその中で起動する。上の例なら .claude/worktrees/feature-auth/、ブランチは worktree-feature-auth。

2. 別ターミナルで2本目を起動する。

   claude --worktree bugfix-123

   「片方は機能実装、もう片方はバグ修正」が、別ブランチ・別ファイル・干渉ゼロで並走する。

3. 名前を省略すると自動命名される。

   claude --worktree

   bright-running-fox のような名前を Claude が生成する。

4. PR / MR から分岐する。番号を # 付きで渡すと、origin からその変更の head コミットを fetch し、.claude/worktrees/pr-<番号> に worktree を作る。シェルが # をコメント扱いしないよう必ずクォートする。

   claude --worktree "#1234"

   fetch 先は origin のホストで決まり、github.com なら pull/<番号>/head、gitlab.com なら merge-requests/<番号>/head、それ以外は前者→後者の順に試す。GitLab の MR URL を渡せるのは v2.1.233（2026年8月14日）以降で、URL を渡しても Claude Code が読むのは番号だけだ。

5. tmux ペインを一緒に開く。--tmux を付けると worktree 用の tmux セッションを作る（--worktree 必須）。iTerm2 が使える環境ではそのネイティブペインを使い、従来型の tmux にしたければ --tmux=classic。

   claude -w feature-auth --tmux

起動前の注意点が3つある。第1に、対話実行は workspace trust が前提で、そのディレクトリで一度も claude を起動していなければ --worktree はエラーで終了し、「先にそのディレクトリで claude を実行せよ」と促す。ただし -p の非対話実行は trust チェックを飛ばすので、claude -p --worktree は承認なしで進む（初版の「-p でも同じエラー」は現行ドキュメントと食い違うため訂正した）。第2に、worktree は既存コミットから作られるので、コミットが1つもないリポジトリでは Failed to resolve base branch "HEAD": git rev-parse failed で失敗する。第3に、.gitignore に .claude/worktrees/ を追加しておくのが公式推奨だ。

初版になかった挙動が同名再利用時のリセットだ。既存の名前で --worktree を叩くとその worktree を開くが、既定の "fresh" ベースでは「未コミット変更・未追跡ファイルがない」「Claude Code が作ったブランチのまま」「独自コミットがない、または PR/MR がマージ済みでリモートブランチも削除済み」をすべて満たすとデフォルトブランチへリセットされて開く（v2.1.208 以降）。それ以外は古い先端のまま。「マージ済みの worktree を同名で再利用したら最新 main から始まった」は仕様である。

ベースブランチと .env の引き継ぎ

native worktree は既定でリポジトリのデフォルトブランチのリモート最新（origin/<default-branch>、通常は main）から分岐する。直近24時間 fetch していなければデフォルトブランチを fetch し（上限5秒）、失敗すればローカルのキャッシュ ref、remote が無ければローカル HEAD にフォールバックする（v2.1.208 以降）。「手元の未 push コミットを引き継ぎたい」場合は、settings.json で worktree.baseRef（v2.1.133 追加）を "head" にする。

{
  "worktree": {
    "baseRef": "head"
  }
}

値は "fresh"（既定）か "head" のみで、ブランチ名は指定できない（特定の既存ブランチから始めたいなら git worktree add で作る）。"head" は --worktree・EnterWorktree・サブエージェント隔離のすべてに効き、linked worktree の中からならその worktree の HEAD に解決される。

実務で重要なのが gitignore されたローカル設定ファイルの引き継ぎだ。worktree は新規チェックアウトなので .env のような未追跡ファイルは持ち込まれない。プロジェクトルートに .worktreeinclude（書式は .gitignore と同じ）を置くと、パターンに一致しかつ gitignore されているファイルだけが新しい worktree にコピーされる（追跡済みファイルは二重コピーされない）。

.env
.env.local
config/secrets.json

--worktree・サブエージェント・デスクトップアプリの worktree すべてに効く。**/ 始まりのパターンはディレクトリごと gitignore された中のファイルを拾えないことがあるので、空振りするなら vendor/**/config.json と名指しする。WorktreeCreate フックで作成を置き換えている場合は処理されない。

大規模リポジトリ向け——sparsePaths と symlinkDirectories

モノレポで worktree を切ると、毎回フルツリーがチェックアウトされて遅い。worktree.sparsePaths（v2.1.76 追加）は git sparse-checkout で、列挙したディレクトリとルート直下のファイルだけをディスクに書く。worktree.symlinkDirectories は node_modules のような巨大ディレクトリを複製せず、メインリポジトリのものへ symlink で繋ぐ。

{
  "worktree": {
    "sparsePaths": [
      ".claude",
      "packages/api",
      "packages/shared"
    ],
    "symlinkDirectories": [
      "node_modules"
    ]
  }
}

公式ドキュメント（large-codebases）の注意点は3つ。（1）sparsePaths にはディレクトリを書く。ルート直下のファイルは常にチェックアウトされるが、ルート直下のディレクトリは対象外なので、.claude/settings.json を worktree 内で使うなら .claude を含める。（2）チーム共通は .claude/settings.json にコミットし、個人の追加は .claude/settings.local.json へ（リストはマージされ、ローカルは追加のみ）。（3）作成後は worktree ルートの .claude/settings.json が読まれるので、権限ルールやフックはリポジトリルートの設定に置く。モノレポ運用全般はモノレポを扱う実践ガイドを参照。

セッション中に worktree へ入る——EnterWorktree / ExitWorktree

起動し直さなくても、会話の途中で「worktree で作業して」と頼めば、Claude Code は EnterWorktree ツールで worktree を作ってそこへ移る。ExitWorktree（v2.1.72 追加）で元のディレクトリへ戻れる。tools-reference の記述を整理する。

• 既存 worktree への切替：EnterWorktree に path を渡すと既存の worktree へ切り替わる（v2.1.105 追加）。すでに worktree の中にいるセッションや、isolation: worktree のように作業ディレクトリが固定されたサブエージェントからは path 形式しか使えず、対象はそのリポジトリの .claude/worktrees/ 配下に限られる。切替前の worktree はディスクに残る。
• .claude/worktrees/ の外へ入るときは承認が要る：v2.1.206 以降、その外のパスへ入ろうとすると Claude Code はユーザーに承認を求める（作業ディレクトリ・書き込み権限・CLAUDE.md がそこへ移るため）。permission rule では抑止できず、bypassPermissions モードだけがスキップする。
• ExitWorktree はサブエージェントには無い：自分の作業ディレクトリで動くサブエージェントは使えない。

再開まわりも変わった。worktree の中にいたセッションを再開すると、対話の /resume でも -p --continue / --resume でも Agent SDK でも、Claude Code はそのセッションを worktree へ戻す（非対話は v2.1.212 以降）。worktree が消えていれば起動ディレクトリで続けて紐付けを解除する。/resume ピッカーの Ctrl+W で同じリポジトリの全 worktree のセッションを表示できる。再開の考え方はcontinue/resumeの使い分けを参照。

フックを書いている人はパスの渡り方に注意する。Claude が worktree に入っても、フックの ${CLAUDE_PROJECT_DIR} はセッション開始時のプロジェクトルートのまま動かず、${CLAUDE_PROJECT_DIR}/.claude/hooks/check-style.sh は引き続きメインチェックアウト側のスクリプトを実行する。worktree のパスは入力 JSON の cwd に入る（worktree に入れば worktree ルート、cd すればその先）。フックの実装はHooks実践ガイドを参照。

Claude Code が隔離を強制する4つのチェック

初版の時点では「worktree はファイルを物理的に分ける」だけの話だったが、いまの Claude Code はworktree の中にいる間、メインチェックアウトに触るツール呼び出しを自分で拒否する。v2.1.222（2026年8月4日）で「ファイル編集と Bash の両方に、全セッション種別で適用」に統一され、公式ドキュメントは次の4つを挙げている。--worktree で起動しても、EnterWorktree で入っても、再開で戻っても同じルールが効く。

1. ファイル編集：メインチェックアウト内のパスを対象にした Edit / Write / NotebookEdit を拒否する。
2. コマンドの作業ディレクトリ：作業ディレクトリがメインチェックアウトに解決する Bash / PowerShell / Monitor コマンド、または「外に出ないと検証できない」コマンドを拒否する。
3. git のリダイレクト：git -C、--git-dir、GIT_DIR / GIT_WORK_TREE、cd してから git——のどれかでメインチェックアウトへ git を向ける Bash / Monitor コマンドを拒否する（v2.1.216 で塞がれた経路）。
4. コマンドの形：git を呼ばないコマンドでも、「worktree に留まる」と実行せずに検証できない形——ブレース展開、区切り文字をクォートしていない heredoc など——は拒否する。拒否時は「単純なコマンドに分割せよ」といった書き直し方が Claude に伝わる。このチェックはオフにできない。

対象は起動したリポジトリ全体で、linked worktree から起動した場合はリンク元のメインチェックアウトも含む（v2.1.210 以降）。隔離されたセッションが生むサブエージェントにも同じチェックがかかる。v2.1.257 / v2.1.259 まで、git に触れないループや xargs、$VAR 参照が「複雑すぎて検証できない」と誤拒否される不具合があったので、「普通のシェル芸が弾かれる」と感じたらまずバージョンを上げる。この隔離はサンドボックスとは別レイヤーの仕組みで、両者の関係はサンドボックスで安全に自動実行を参照。

サブエージェント・バックグラウンドセッションとの組み合わせ

worktree は「自分で起動するセッション」だけの機能ではない。Claude Code が内部で動かすエージェントも、次の3経路で worktree を使う。

（1）サブエージェントの isolation: worktree。.claude/agents/ のフロントマターに1行足すと、そのサブエージェントは常に一時 worktree の中で動く（v2.1.49 / v2.1.50 で追加）。

---
name: refactorer
description: Applies mechanical refactors across many files
isolation: worktree
---

Apply the requested refactor across every affected file, then run the tests
and report the results.

フロントマターに書かなくても、「エージェントに worktree を使わせて」と頼めば Claude が Agent ツールに isolation: "worktree" を付けて起動する。worktree は変更が無ければ終了時に自動削除され、変更があれば後述の定期スイープまで残る。ベースは --worktree と同じで、worktree.baseRef が "head" でない限りデフォルトブランチから分岐する。基本はサブエージェント並列開発入門、フォーク既定化はClaude Code v2.1.232フォーク既定化ガイドを参照。

（2）バックグラウンドセッションの自動 worktree 化。claude agents（agent view）・/bg・claude --bg で起動したバックグラウンドセッションは、起動時は作業ディレクトリにいるが、ファイルを編集する前に .claude/worktrees/ 配下の worktree へ自分で移る。入る前は共有チェックアウトへの書き込みがブロックされる（すでに linked worktree の中にいる、git リポジトリでなく WorktreeCreate フックも無い、書き込み先が作業ディレクトリの外、などは対象外）。worktree が現実的でないリポジトリでは、プロジェクトの .claude/settings.json に worktree.bgIsolation: "none"（v2.1.143 追加）を書くと作業コピーを直接編集する。

{
  "worktree": {
    "bgIsolation": "none"
  }
}

バックグラウンドセッションが生むサブエージェントはその worktree を継承し、別に欲しければ isolation: worktree を付ける。claude agents から投げたエージェントは、コード作業を終えるとコミット・push・ドラフト PR 作成まで自分で行う（v2.1.198 以降）。/fork で会話を別のバックグラウンドセッションに複製した場合も、v2.1.221 以降は自分の worktree を作る。詳しくはClaude Codeバックグラウンドセッション完全ガイドを参照。

（3）/batch とデスクトップアプリ。同梱スキル /batch <instruction> は、大規模変更を5〜30個の独立ユニットに分解し、承認後にユニットごとのバックグラウンドサブエージェントをそれぞれ隔離 worktree で起動して実装・テスト・PR 作成までやらせる（git リポジトリ必須）。デスクトップアプリでは新規セッションごとに worktree が自動で切られる。worktree をまたいで「あっちで何が入ったか」を Claude 同士に伝えさせたいなら複数セッション連携（cross-session messaging）が受け皿になる。

並列運用のコツ——命名・共有設定・後片付け

• 命名は「目的」で揃える：--worktree feature-auth --worktree bugfix-login-500 のように、「何のための作業か」が分かる名前にする。git worktree list がそのまま「いま走っている作業の地図」になる。
• 1ツリー1ブランチを守る：git は同一ブランチの二重チェックアウトを拒否する。--force で無理に通さない。
• 共有設定は .worktreeinclude と symlinkDirectories に集約：新メンバーが --worktree を叩いても .env 不足や依存の再インストールで詰まらない。
• マージは通常のブランチ運用そのまま：push して PR を出し main にマージし、終わったら消す。

後片付けの自動・手動の境界

対話の --worktree セッションを終えると、Claude は「消したら失われる作業」（変更・未追跡ファイル・新規コミット）があるかを確認する。無ければ名前なしセッションは worktree とブランチを自動削除し、名前付きセッションは残すか確認する。作業が残っていれば keep / remove を尋ねる。-p の非対話実行は終了プロンプトが無いので掃除されず、作成時に取ったロックも残る。git worktree remove が拒否されたら先に git worktree unlock を打つ。

サブエージェントとバックグラウンドセッションの worktree は、cleanupPeriodDays（既定30日）を超えたものを定期スイープが削除する。ただし「変更・未追跡・未 push コミットが残っている」「バックグラウンド化していない --worktree セッションのもの」「git worktree add で自分が作ったもの」は残す（v2.1.246 以降）。実行中のエージェントは git worktree lock を保持し、kill されたセッションのロックはスイープが解放する。v2.1.143 以降、git worktree remove が失敗しても rm -rf にフォールバックしない。

【要注意】よくある失敗パターンと回避策

失敗1：trust 未承認のまま --worktree
❌ 初めてのディレクトリでいきなり claude --worktree x → エラー終了。
⭕ 先に素の claude を一度起動して trust を承認する。CI など -p 経由なら不要。

失敗2：「メインでは動くのに worktree で動かない」
❌ .env が無い、node_modules が無い、DB マイグレーションが当たっていない。
⭕ .worktreeinclude に .env 系、worktree.symlinkDirectories に node_modules を書き、残りは「依存を入れて」と Claude に頼む。

失敗3：隔離チェックで Bash が弾かれる
❌ git -C ../main log、クォートなし heredoc、ブレース展開を1行に詰めた長いコマンド。
⭕ メインチェックアウトを触る操作は worktree 内で行わない。複雑なコマンドはプレーンな複数コマンドに分割する。

失敗4：worktree が作れない・戻れない
❌ Refusing to use <path> as an isolation worktree、LFS のファイルがポインタのまま、.claude/worktrees が symlink。
⭕ 拒否メッセージの末尾に従う（「parent checkout から起動せよ」ならメインから起動）。LFS は git lfs install --local のフィルタが作成時に無効化される仕様（v2.1.247 以降）なので worktree 内で git lfs pull。symlink は外して再試行。

サブエージェント並列との違いと使い分け

公式の「Run agents in parallel」は、並列化の手段をサブエージェント・agent view・エージェントチーム・動的ワークフローの4つに分け、worktree はそれらを支える「ファイル編集の隔離」の道具と位置づけている。仕事の分割は別のレイヤーだ。

• 「全く別の2タスクを同時に進めたい」→ worktree。--worktree でプロセスごと分ける。
• 「1つのタスクを手分けして速くしたい」→ サブエージェント。編集がぶつかるのが怖ければ isolation: worktree を付ける。
• 「独立タスクを投げて放置したい」→ agent view。編集前に自動で worktree に入るので、自分で切る必要はない。
• 「エージェントチームを使う」→ worktree 隔離は無い。公式は「チームメイトごとに触るファイルを分けよ」としている。

慣れたら CLAUDE.md に worktree の置き場所・命名規約・.worktreeinclude の方針を書いておくと、チーム全体で同じ並列ワークフローを再現できる（CLAUDE.md設計・運用ガイド）。大きな変更を各ツリーで安全に進めるならPlan Mode実践ガイドと組み合わせる。

よくある質問（FAQ）

Q. worktree を作るとディスクが2倍になりますか？
作業ファイルは複製されますが、git の履歴オブジェクトは1か所に集約されます。依存ディレクトリは worktree.symlinkDirectories、モノレポの不要ディレクトリは worktree.sparsePaths で削れます。

Q. 同じブランチを2つの worktree で開けますか？
既定ではできません。git が二重チェックアウトを拒否します（--force は非推奨）。

Q. --worktree はどの git でも使えますか？
git リポジトリ前提です。SVN・Perforce・Mercurial では WorktreeCreate / WorktreeRemove フックで作成・後片付けを置き換えます（コマンド型フックは作成したパスを標準出力に出し、非ゼロ終了で作成が失敗します）。

Q. -p で作った worktree は自動で消えますか？
消えません。終了プロンプトが無いので、git worktree remove（ロックされていれば先に git worktree unlock）で手動削除します。

まとめ——今日から始める3つのアクション

1. 素の git で1本作ってみる：git worktree add ../myrepo-test -b wt-test → そのディレクトリで claude を起動し、メインと干渉しないことを体感する。
2. native フラグを使う：対象リポジトリで一度 claude を起動して trust を承認したあと、claude --worktree feature-x で隔離セッションを立ち上げる。.gitignore に .claude/worktrees/ を追加する。
3. 共有設定を整える：.worktreeinclude に .env を、worktree.symlinkDirectories に node_modules を書く。慣れたらサブエージェントに isolation: worktree を付けて並列度と安全性を両取りする。

Claude Code の実践スキルを体系的に積み上げたい場合は、ClaudeCode実践テクニック完全ガイド｜12スキル学習順【2026】を学習順の地図として使うとよい。worktree は、その中でも「並列開発」の土台になるテクニックだ。

---

著者プロフィール

佐藤傑（さとう・すぐる）。株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援を手がける。著書『AIエージェント仕事術』（SBクリエイティブ）。SoftBank IT連載を7回執筆。Claude Code を中核にした開発ワークフローの設計・社内導入支援を専門とする。

参考・出典

• git-worktree Documentation — Git 公式リファレンス（2026年9月3日確認）
• Run parallel sessions with worktrees — Claude Code 公式ドキュメント（2026年9月3日確認）
• CLI reference（–worktree / –tmux）— Claude Code 公式ドキュメント（2026年9月3日確認）
• Settings reference（worktree 設定）— Claude Code 公式ドキュメント（2026年9月3日確認）
• Subagents（isolation: worktree）— Claude Code 公式ドキュメント（2026年9月3日確認）
• Agent view（How file edits are isolated）— Claude Code 公式ドキュメント（2026年9月3日確認）
• Hooks（WorktreeCreate / WorktreeRemove）— Claude Code 公式ドキュメント（2026年9月3日確認）
• Changelog（v2.1.49〜v2.1.259）— Claude Code 公式ドキュメント（2026年9月3日確認）

あわせて読みたい

• ▸ 【2026年9月】Claude Code×Figma MCP接続の実装手順
• ▸ 【2026年9月】Claude CodeにGit操作を任せる7手順
• ▸ 【2026年9月】Claude Codeトークン使用量の確認｜キャッシュ節約
• ▸ 【2026年9月】Claude Code研修・講師の依頼先6社比較と選び方
• ▸ 【2026年最新】Claude Code /compact｜長時間開発の5手順