互いに独立して進められるタスクなら、Claude Code と Codex を Paneflow の別々のチェックアウトで実行できます。担当ファイルを決め、それぞれの変更をレビューしてから、両方のブランチを統合してテストします。ターミナルを分割するだけでは、編集対象のファイルは分離されません。

## 独立したタスクを二つ選ぶ

最初は Claude Code に `docs/setup.md` の更新、Codex に既存のパーサー向けの `tests/parser.test.js` の追加を依頼します。同じコミット済みの状態から開始できます。パーサーの現在の仕様を先に確認してください。まだ存在しない実装がテストの前提になるなら、順番に進めます。

Paneflow 0.17.4、コミット済みの基点がある Git リポジトリ、インストールと認証が済んだエージェントを用意します。コマンド構文は 2026 年 10 月 1 日に Windows x64 上の Claude Code 2.1.286 と Codex CLI 0.159.2 で確認しました。認証、モデルへのアクセス、利用料金は各エージェントのプロバイダーが管理します。

## 起動前にチェックアウトを選ぶ

1. [worktree リファレンス](/ja/docs/worktrees)に従い、**Worktree** を有効にして同じ基点から `docs/setup-guide` と `test/parser-cases` を作成します。既存ブランチでは既存のチェックアウトを再利用する場合があるため、パスを確認します。
2. 各チェックアウトでターミナルを開き、次のコマンドでディレクトリとブランチが異なることを確認します。

```sh
git rev-parse --show-toplevel
git branch --show-current
git status --short
```

3. 必要なチェックアウトに依存関係をインストールします。開発サーバーのポートは、プロジェクトのコマンドで 3001 と 3002 など別々に設定します。
4. ドキュメント側で `claude`、テスト側で `codex` を起動し、範囲を絞ったタスクを自分で入力します。相手の担当ファイルの編集やブランチの自動統合は依頼しません。

対話型の起動方法は [Claude Code](https://code.claude.com/docs/en/cli-reference) と [Codex](https://developers.openai.com/codex/cli/reference/) のリファレンスにあります。コマンドが見つからない場合は、そのシェルでのインストールや PATH を `claude --version` または `codex --version` で確認します。

## 稼働状況を見て、成果を確認する

Paneflow の稼働表示はエージェントごとの連携に依存します。待機中の表示はテスト成功の証明ではありません。ターミナルを読み、権限要求を確認して応答し、**Changes** でアクティブなチェックアウトを調べます。比較対象はその `HEAD` で、ステージ済み・未ステージの変更と未追跡ファイルを含みます。ブランチ全体のレビューではありません。

レビュー前にエディターバッファを保存します。テスト側で必要なテストを実行し、ドキュメントを別途レビューして、確認済みの作業をコミットに残します。統合用チェックアウトでチームの Git 手順に沿って統合し、競合を解決して全体のテストを実行します。[Changes](/ja/blog/diff-viewer) に加えてブランチ全体の diff も確認してください。確認できる成果は、レビュー済みの二つの変更とテスト済みの統合状態です。エージェントの完了報告だけでは足りません。

## 検証した範囲

このガイドの技術的な予行演習では、Windows x64 のシェルだけを使い、二つの Git worktree、独立したファイル変更、各チェックアウトの確認、統合を検証しています。エージェントのバージョンとヘルプも確認しました。Paneflow による worktree の作成と再利用は前回のコンテンツレビューでメンテナーが確認しており、[0.17.4 の実装](https://github.com/arthjean/paneflow/blob/v0.17.4/src-app/src/workspace/worktree.rs)がリリースの動作を示します。有料モデルへのタスク実行や速度比較を行ったという意味ではありません。

## 並列実行を減らす判断

共有チェックアウトで同じファイルを二つのエージェントが編集すると、上書きや競合が起こり得ます。worktree は作業ファイルを分離しますが、コミットの統合時には競合が残ります。担当を分けるか、依存するタスクを後で実行します。

ポート、データベース、CPU、メモリ、プロバイダーの制限は共有されます。ポート競合はペインを追加しても解消せず、設定を分ける必要があります。ビルドがメモリを奪い合う、リクエスト制限に達する、一方が相手の未完成の成果を待ち続ける場合は、一つを止めて順番に進めます。worktree はセキュリティサンドボックスではなく、ローカルの秘密情報やネットワーク権限には別の管理が必要です。

統合結果を確認するときは、チェックアウト管理に [worktree リファレンス](/ja/docs/worktrees)、保存の競合に [Files ガイド](/ja/blog/files-sidebar)を参照してください。