Claude Code は大規模なコードベースを読み込み、多数のファイルにまたがる計画を維持するのが得意です。Codex は範囲を絞ったテスト駆動の変更が得意です。多くのエンジニアは、同じリポジトリで両方を使いたいと考えます。一方がリファクタリングの下書きを進め、もう一方が不安定なテストスイートを堅牢化する、という具合です。ところが実際に試した途端、同じ作業ディレクトリであること自体が問題になります。異なるツール、異なる CLI、そして両方が書き込む一つのフォルダ。
このガイドでは、セットアップを手順ごとに解説し、各ステップで起こりうる失敗の型を明示し、二つのターミナルがどこでスケールしなくなるかを示します。分離の側面は git worktree で解決済みの問題です。協調の側面、つまりどのツールが何を担当しているかを把握し、すべての変更をレビュー可能に保つことは、Sharkly のようなランタイム中立のレイヤーが引き継ぐ領域です。
Sharkly は Claude Code や Codex の代替ではありません。すでに実行している実行ツールの周囲に、共有された Task、Computer、コンテキスト、レビューのレイヤーを追加します。これにより、Claude Code のセッションと Codex のセッションは、あなたが面倒を見る二つのターミナルではなく、一つのワークフロー内の二つのアサインになるのです。
なぜ同じリポジトリで Claude Code と Codex を動かすのか
理由は繰り返し現れる三つで、それぞれ別の問題です。
タスクごとに異なる強み。 広いコンテキストを要する作業（モジュール全体にまたがるバグの追跡、マイグレーションの計画など）は一方のエージェントに、狭く検証可能な作業（テストをパスさせる、関数を引き締めるなど）はもう一方に任せます。ツールとタスクのマッチングはそれ自体が一つのテーマです。詳しくはどのコーディングタスクにどのモデルを使うかをご覧ください。
実務での直接対決。 唯一誠実なベンチマークはリーダーボードではなく、あなた自身のコードベースです。同じチケットで両方を動かし、diff を比較すれば、どんな公開スコアよりも多くのことが分かります。その手法については自分のコードベースでコーディングエージェントを比較する方法で扱っています。
すでに両方に料金を払っている。 多くのチームは Claude のサブスクリプションと、Codex または API のシートをすでに持っています。プロバイダー中立性が要点です。ワークフローは、次に最高のモデルを出したのがどちらのツールであっても、作り直しなしで生き残るべきです。
理由が何であれ、失敗の形は同じです。一つのフォルダに二人のエージェントを置くのは、ロックなしで一つの文書を編集する二人の書き手と同じです。一方がもう一方の足元でブランチを切り替えたり、編集中のファイルを再フォーマットしたりして、意味の通らない中途半端な diff が生まれます。
ステップ1：各エージェントに専用の worktree を与える
git worktree は、この衝突を根本から解決します。一つのリポジトリに複数の作業ディレクトリを同時にチェックアウトでき、それぞれが独自のブランチ上にあり、単一の .git データベースを共有します。両方のツールが奪い合う一つのフォルダの代わりに、タスクごとに一つずつ得られます。
# One checkout per task, each on its own branch
git worktree add ../app-refactor -b agent/refactor
git worktree add ../app-tests -b agent/tests
git worktree list
各ディレクトリに別のツールを向けます：
cd ../app-refactor && claude # Claude Code on the refactor
cd ../app-tests && codex # Codex on the test suite
これを省いた場合の失敗の型： 両方のツールが同じリポジトリへ cd し、同じファイルを奪い合い、一方がもう一方の未コミットの作業を気づかないうちに上書きします。worktree を使えば、それは物理的に不可能になります。その後のクリーンアップには独自の厄介な点があります。クリーンアップの苦労なしにコーディングエージェントの worktree を管理するでは git worktree remove と古いブランチの問題を扱っています。
ステップ2：各ツールを適切な指示に向ける
Claude Code と Codex は異なるプロジェクトファイルを読み込みます。Claude Code は CLAUDE.md を探し、Codex は AGENTS.md を読みます。リポジトリにどちらか一方しかなければ、片方のエージェントはあなたの規約を見ないまま作業します。
両方を維持し、一貫させておきましょう。信頼できるパターンは、共有ルールを一度だけ書き、各エントリポイントからそれを参照させることです：
<!-- CLAUDE.md and AGENTS.md both start with -->
See ./docs/agent-conventions.md for build, test, and style rules.
# Verify each tool actually loads its file before you turn it loose
claude --version # Claude Code reads CLAUDE.md from the worktree root
codex --version # Codex reads AGENTS.md from the worktree root
これを省いた場合の失敗の型： Codex はある lint 設定に従い、Claude Code は別の設定に従い、マージのたびに誰も書き留めていないスタイル闘争になります。ここで個人的な注意点を一つ。インストールトークンはあなたの規約を運びませんし、.gitignore されたローカルファイルは worktree へ引き継がれません。共有ルールは追跡対象のファイルに置きましょう。そうしなければ、新しい worktree はどれも空の状態から始まります。
ステップ3：起動して、協調のギャップが開くのを見る
二つの worktree と二つの設定ファイルがあれば、仕組みは動きます。Claude Code が一方のブランチに、Codex がもう一方にいて、どちらも相手のファイルに触れません。二つのエージェントで午後を過ごすなら、これで持ちこたえられます。
ギャップが開くのは、キーボードから顔を上げたときです。各セッションはそれぞれの履歴をそれぞれのタブに保持し、相手からは見えません。Codex の実行が Claude Code の実行がすでに何を変えたかを知る必要があるとき、参照できる共有メモリはないので、あなたが統合レイヤーになります。エージェントはそれぞれ違うタイミングで終わり、黙って入力を待ちます。だから「両方を並行して実行する」は、静かに「それぞれを順番に確認する」へと劣化します。
これを二つより先へスケールさせてみましょう。自然な次の一手は、worktree を立ち上げ、それぞれに適切なツールを起動し、出力を名前付きの tmux ペインに流し込むラッパースクリプトです。数回の実行なら役立ちます。しかし、そこから肥大化します。ブランチ命名、クリーンアップ、どのツールがどのタスクを担当しているかを知る手段、クラッシュしたものへのリトライ。やがて、bash で継ぎ接ぎされた脆いオーケストレーションフレームワークを保守することになり、状態の半分はシェル履歴に、もう半分は頭の中に住むことになります。多数を同時に動かすときは、複数の Claude Code エージェントを実行するのようにエージェントがすべて Claude Code であっても、混成であっても、同じ壁にぶつかります。
二つのターミナルがスケールしなくなる地点
DIY セットアップを超えたかどうかを判断する、誠実なテストです：
- チームメイトは、あなたがターミナルを読み上げなくても、エージェントが今何をしているかを確認できますか？
- Codex が午後2時に終わって入力を必要としたとき、何かがあなたに知らせますか？
- 両方のエージェントが同時に終わったとき、その作業をレビューするキューがありますか、それともあなたと二つのブランチだけですか？
答えが「いいえ」なら、足りないものは別のシェルスクリプトではありません。どちらのツールにも作業を割り当て、ライブのステータスを表示し、マージ前にすべての変更をレビュー可能に保つレイヤーです。それが、生のターミナルに対してタスクボードが加えるものです。
ここは明確に述べておく価値のある境界です。Claude Code と Codex は実行を担います。コマンドレイヤーは、両者にまたがる割り当て、接続された Computer、タスクのコンテキスト、進捗、ブロッカー、結果、人間によるレビューを管理します。Sharkly では、一つの Task を Claude Code ランタイムに、もう一つを Codex ランタイムに割り当てます。それぞれが接続された Computer 上の独自の隔離された worktree で実行され、実行、ブロッカー、結果はプライベートなターミナルに消える代わりに Task のタイムラインへ戻ってきます。
分業は綺麗に保たれます。エージェントは調査し、実行し、テストし、報告します。人は方向性を定め、権限を与え、結果を受け入れます。自動化はあなたの判断が必要なところで止まり、検証の証拠を添えた diff を返します。すでに料金を払っているツールを使い続け、モデルの利用はそれぞれに設定されたサブスクリプションや API キーを通じて行われ、誰が何を担当しているかを見る一つの場所が手に入ります。
手動セットアップは、午後だけ一、二個のエージェントを動かし、状態を頭の中に保持できるときに使いましょう。共有レイヤーに手を伸ばすのは、二人目の人物が可視性を必要とするとき、数が一つのターミナルウィンドウに収まる量を超えたとき、あるいはツールを比較する頻度が高く「どの実行がこのブランチを生んだのか」が自明でなくなったときです。
今日から実行できるチェックリスト
次に両方のツールを一つのリポジトリに置くときは、上から下までこれを実行してください：
- [ ] タスクごとに一つの
git worktreeを作り、それぞれを独自のブランチに置く。二つのツールを同じディレクトリに向けてはいけない。 - [ ]
CLAUDE.mdとAGENTS.mdの両方をコミットし、それぞれが追跡対象のソース内にある一つの共有規約ファイルを参照するようにする。 - [ ] 作業を割り当てる前に、各ツールが worktree のルートからその設定を読み込むことを確認する。
- [ ] エージェントごとにスコープを絞った一つの Task を割り当てる。広いコンテキストを要する作業は一方に、狭いテスト駆動の作業はもう一方に。
- [ ] レビューゲートを前もって決める。人が diff とテスト結果を読むまで、どのブランチもマージしない。
- [ ] 同時実行が二つか三つを超えたら、bash でのスケールをやめ、割り当て、ステータス、レビューを一つのレイヤーへ移す。
一つのエコシステムにコミットするのではなく、Claude Code と Codex の両方を使い続けたいなら、それがまさに Sharkly が解決しようと設計された問題です。Sharkly をダウンロードし、Computer を一つ接続して、最初の Task をその作業に合ったエージェントに割り当ててみてください。
FAQ
Claude Code と Codex は同じファイルを安全に編集できますか？ 同じディレクトリではできません。各ツールに独自の git worktree を与えて別々のブランチで作業させ、レビューを通してマージしましょう。同じディレクトリでの並行作業は、未コミットの作業が失われる場所です。
サブスクリプションは二つ必要ですか？ 各ツールが必要とするものは必要です。モデルの利用は Claude Code と Codex に設定されたサブスクリプションまたは API キーを通じて続きます。協調レイヤーはそのアクセスを変更したり再販したりしません。
二つのエージェントにタスクボードは過剰ですか？ 一度に自分で制御する二つのエージェントなら、素の worktree と二つのターミナルで十分です。ボードがその価値を発揮するのは、チームメイトが可視性を必要とするときや実行数が増えたときです。並列 AI コーディングエージェントを管理するためのベストツールをご覧ください。
