Claude Code と Codex を並行して使う：Git worktree の小さな実験

Claude Code に文言を直してもらいながら Codex にエクスポートの不具合を修正してもらうなら、まずタスクごとの作業ディレクトリを用意しましょう。

二つの会話が同じディレクトリを参照すると、一方が変更したファイルをもう一方が読みます。「テスト成功」と表示されても、その結果がどちらの変更を検証したものなのか分からなくなりかねません。

設定の説明文を直す作業と、空の日付のエクスポートを修正する作業は、並行して進め、個別に確認できます。この再現可能な実験では、ディレクトリの準備、担当の分け方、統合後の検証までを示します。実験はスクリプトで行い、プロンプトは自分のプロジェクト向けに調整できる例として掲載しています。

作業範囲と完了条件を先に決める

サンプルプロジェクトには、設定文言のファイルと、タイムスタンプをエクスポート用の日付に変換する関数があります。

文言のタスクでは settings.zh-CN.json だけを変更し、「管理设备」の説明を「查看已登录设备，并撤销不再使用的设备访问」にします。日付のタスクは欠損値の扱いだけを修正し、有効なタイムスタンプを UTC の日付で出力するルールは維持します。

再現性を保つため、テストデータの簡体字中国語はそのままにしています。前者は「デバイスの管理」、新しい説明は「ログイン済みデバイスを確認し、使わなくなったデバイスのアクセスを取り消す」という意味です。

元の関数は次のとおりです。

export function exportDate(value) {
  return new Date(value).toISOString().slice(0, 10);
}

null には 1970-01-01 を返し、空文字列には例外を投げます。いずれも「日付がなければ空欄にする」という要件に合いません。

最初に四つのテストを実行します。欠損値の二つは失敗し、UTC タイムスタンプとタイムゾーン付きタイムスタンプの二つは成功します。この基準があれば、前半を直し、後半の動作を保つという目的が明確になります。

同じコミットから二つの作業ディレクトリを作る

既存の main ブランチがあるリポジトリで、起点のコミットを確認します。以下は、新しいブランチ名と作成先ディレクトリが未使用であることを前提とします。

git worktree add -b feature/settings-copy ../project-settings-copy main
git worktree add -b fix/export-dates ../project-export-dates main
git worktree list

各 worktree は独自のチェックアウト先とインデックス（ステージング領域）を持ち、別のブランチの変更を保持できます。ただし、所属する Git リポジトリは同じです。新しいディレクトリは指定コミットから始まり、元のディレクトリの未コミット変更は自動では移りません。依存関係やローカル設定は、プロジェクトの要件に合わせて準備してください。詳細は Git worktree の公式ドキュメントにあります。

作成後のディレクトリとブランチは次のようになります。

一つのタスクに一つのディレクトリを割り当てることで、両方の作業コピーを同時に保持できます。同じディレクトリでブランチを切り替えるだけでは、この分離にはなりません。

Tactic Remote で会話ごとに正しいディレクトリを選ぶ

開発用パソコンへ接続し、**新しい会話（New Conversation）のプロジェクト選択を開きます。必要なら別のフォルダを選択（Choose another folder）**で worktree の実際のパスを選び、そのあとにエージェントを選択します。

すでに worktree がある場合は、そのディレクトリを直接選んでください。**独立したワークスペース（Independent Workspace）**を作っても、対象リポジトリやブランチとの関係が自動で含まれるわけではありません。

Claude Code への最初の依頼は、例えば次のように書けます。

settings.zh-CN.json のデバイス説明だけを変更してください。ログイン済みデバイスを確認し、アクセスを取り消せることが分かる文言にします。最初に現在のディレクトリとブランチを確認し、日付エクスポートの処理は変更しないでください。最後に文言の差分を示し、JSON が有効か検証してください。

Codex には次のように依頼できます。

export-date.mjs を修正してください。null と空文字列は空文字列を返し、有効なタイムスタンプは従来どおり UTC の日付で出力します。最初にディレクトリとブランチを確認し、既存の四つのテストを実行してください。不具合を再現して最小限の修正を加え、設定文言は変更しないでください。修正前後の結果を報告してください。

プロンプトでファイル範囲を指定するとレビューしやすくなりますが、セキュリティ上のサンドボックスになるわけではありません。実際に読み書きできるファイルは、接続先でのエージェントの権限によって決まります。

「両方成功」の中身を、個別に確かめる

この例の最小修正は、日付の変換前に欠損入力を調べることです。

export function exportDate(value) {
  if (value === null || value === undefined || value === '') return '';
  return new Date(value).toISOString().slice(0, 10);
}

扱うのは、合意した欠損値だけです。それ以外の無効な日付文字列の動作は、別途定義する必要があります。有効なタイムスタンプは引き続き UTC の日付として出力します。

各ディレクトリで次を実行します。

git status --short
git diff --name-only
git diff

実験では、文言のディレクトリで変更されたのは settings.zh-CN.json だけで、日付のディレクトリでは export-date.mjs だけでした。ファイルの内容も直接読み、文言側に元の日付関数が残り、日付側に元の文言が残ることを確認しました。

実際の検証結果は次のとおりです。

文言ブランチは JSON の検証に成功しても、既知の日付テスト二件の失敗は残ったままです。基準となるテスト状態と、各検証の範囲を一緒に記録し、結果が何を示すか分かるようにします。

最後に明確な統合先ブランチへまとめる

各変更をレビューし、コミットしたあと、サンプルリポジトリの元のディレクトリで統合用ブランチを作ります。

git switch -c review/combine main
git merge --ff-only feature/settings-copy
git merge fix/export-dates
node --test export-date.test.mjs

これは、元のディレクトリに未処理の変更がなく、二つのタスクブランチがコミット済みであることを前提としています。実際のプロジェクトでは、既存の PR とマージの手順に従ってください。競合が起きたら両方の意図を理解し、そのあとで統合結果を検証します。

各ブランチで検証に成功していても、変更同士が影響し合うことがあります。マージ後のテストも必要です。作業ディレクトリを分けても、共有する設定、依存関係、データベース、サーバーポートは調整しなければなりません。

変更が保持され、作業ツリーがクリーンで、ディレクトリが使われていないことを確認したら、通常の git worktree remove で削除します。変更が残っているため Git が削除を拒んだ場合は、メッセージに示された未コミットの内容を先に処理してください。

スマートフォンでは、タスクと検証結果を先に確認する

並行タスクをスマートフォンで確認するときは、接続先、プロジェクト、会話を確かめます。そのあとに最新の結果を読み、自分の判断が必要な箇所を探してください。

文言のタスクなら一つの用語の確認で済むかもしれません。日付のタスクなら UTC かローカル時刻かを決める必要があるかもしれません。判断は対応する会話に残し、あとから理由を追えるようにします。

二つのタスクから始められる方法です。それぞれにディレクトリ、明確な依頼、検証結果を用意し、最後に組み合わせた動作を確認します。タスクが増えても、どのディレクトリ、依頼、テスト結果なのか分かる状態を保ちましょう。

この実験は一時的なローカル Git リポジトリで、エージェントを呼び出さずに行いました。再現スクリプトと元の結果で各段階を確認できます。