Codex、Claude Code、CursorをひとつのCLIチームとして動かす

Codex、Claude Code、Cursorは、設定された能力と権限の範囲で、リポジトリの編集、コマンドの実行、プロジェクト指示の遵守ができます。この記事が検証するのはファイルベースの運用契約です。すべてのチームに3つのエージェントが必要だとも、この契約がツール固有の挙動を取り除くとも主張しません。

この記事では、すでに手元にあるファイルとCLIだけでそれを実現する方法を示します。

• AGENTS.md による共有プロジェクト指示
• CLAUDE.md で @AGENTS.md を取り込むClaude向けブリッジ
• Cursorのベースライン指示と任意の .cursor/rules
• 役割間で受け渡す型付きハンドオフmarkdown
• 設計・レビュー・実装向けの非対話CLI実行

ここでは、独自のプロジェクト管理基盤は必要ありません。あとからエージェントをまたぐ共有バックログが必要になったら、Linearのマルチエージェントプロジェクト管理と組み合わせてください。この記事では、調整の媒体はgitとmarkdownです。

製品ドキュメントは2026-08-04に、AGENTS.md、OpenAI CodexのAGENTS.mdガイダンス、Codexの非対話モード、Claude Codeのメモリドキュメント、Claude Code CLIリファレンス、Cursor CLIドキュメントと照合して再確認しました。このレビューでは、3クライアントの完全なハンドオフをエンドツーエンドでは実行していません。ワークフローに依拠する前に、固定したクライアントバージョンでコマンドと権限を検証してください。

チームの形

最初の役割分担としては、次の形が堅実です。

これらの役割は慣習であって、ベンダーによる制限ではありません。どのツールも設計・レビュー・実装ができます。それでも専門を分けることが有効なのは、成果物の境界を強制できるからです。一つのエージェントが計画を書き、別のエージェントがそれを攻撃し、三つ目が、レビューを生き延びたものだけを実装します。

共有指示：信頼できる唯一の情報源

AGENTS.md を移植可能なベースラインにする

AGENTS.md は、Agentic AI Foundationのもとで管理されるクロスツール指示フォーマットです。Codexはこれをそのまま読み取ります。Cursorも、ルートのAGENTS.mdを共有のプロジェクトガイダンスとしてサポートしています（.cursor/rulesと併用できます）。内容は短く、運用に直結するものに保ってください。

# AGENTS.md

## Commands
- Install: `pnpm install`
- Test: `pnpm test`
- Typecheck: `pnpm typecheck`
- Lint: `pnpm lint`

## Patch rules
- One behavior change per branch
- Prefer existing helpers over new dependencies
- Do not edit secrets or `.env*` files
- Do not merge to main

## Multi-agent protocol
- Read `docs/handoffs/` before starting
- Write status back into the active handoff file
- Designer, reviewer, and implementer must be different runs
- Stop for auth, payments, production infra, or data deletion

OpenAIのCodexドキュメントによれば、プロジェクトルートから作業ディレクトリまでを探索し、より近いファイルが優先され、任意でAGENTS.override.mdが使え、結合後のサイズには既定の上限があります（明示的に引き上げない限り32 KiB）。ルートのファイルは引き締めておき、パッケージ固有の規則は入れ子のAGENTS.mdに置いてください。

CLAUDE.md でClaude Codeをブリッジする

Claude Codeが読むのはCLAUDE.mdであり、AGENTS.mdではありません。公式の案内は、共有ファイルを取り込む方法です。

@AGENTS.md

## Claude Code
- Prefer plan mode before edits on `src/billing/` and auth code
- For review jobs, do not implement unless the handoff status is `implement` or `fixes`

Claude固有の追記が不要なら、シンボリックリンク（ln -s AGENTS.md CLAUDE.md）も使えます。Windowsでは@AGENTS.mdによる取り込みのほうを選んでください。

読み込まれているかどうかは、Claudeの/contextでMemory filesを見て確認してください。

Cursor固有のルールは狭く保つ

Cursorは、共有の規約としてルートのAGENTS.mdを使えます。.cursor/rules/*.mdcは、globでスコープを絞るルールなど、Cursorでしか必要のないものに限ってください。食い違う百科事典を三つ並行して維持しないでください。

ハンドオフファイルがチームメイト同士の会話になる

まずディレクトリを作ります。

mkdir -p docs/handoffs

作業単位ごとに1ファイルを使います。

docs/handoffs/2026-07-29-pricing-section.md

# Handoff: pricing section

- ID: pricing-section
- Status: design
- Owner now: codex
- Next owner: claude
- Branch: codex/design-pricing-section
- Worktree: ../app-pricing-section

## Goal
Implement the marketing pricing section using existing Section/PlanCard patterns.

## Non-goals
Billing, coupons, seat math.

## Design
(Codex fills this)

## Review
(Claude fills this)

## Implementation notes
(Cursor fills this)

## Verification
- Command: `pnpm test:e2e --grep "pricing"`
- Last result:

## Decision log
- 2026-07-29 Codex: drafted component boundaries

うまく機能するステータス値は次のとおりです（一方向に進むだけでなく、ループを含みます）。

1. design
2. design-review — ブロッキング指摘は design に戻す。クリーンなレビューは implement へ進む
3. implement
4. impl-review — ブロッキング指摘は fixes へ。クリーンなレビューは done にする
5. fixes — 実装者が指摘を解消し、impl-review に戻す
6. done
7. blocked-human

すべてのタスクがfixesを経由するわけではありません。指摘のないimpl-reviewは、そのままdoneへ進めてかまいません。

CLIの実行はすべて、このファイルを読むことから始まり、ステータス・オーナー・Decision logの更新で終わります。オーケストレーション層は、それがすべてです。

例：設計 → レビューを1サイクル回したあと

Codexが設計し、Claudeがレビューしたあとの、説明用のハンドオフの抜粋です。

- Status: implement
- Owner now: cursor
- Next owner: claude

## Design
Files: `PricingSection.tsx` (new), reuse `PlanCard.tsx`
CTA must track clicks with `trackEvent()` + `getCtaClickProps()` from `src/lib/analytics.ts`
Mobile: stacked below `md`, three columns from `md` up
Plan IDs: `starter`, `pro`, `business`
Test: `pnpm test:e2e --grep "pricing"`

## Review
Blocking: none remaining (breakpoint + plan IDs resolved in Design above)
Non-blocking:
- Extract plan constants later if CMS arrives.

## Decision log
- 2026-07-29 Codex: initial component boundaries
- 2026-07-29 Claude: requested breakpoint + explicit plan IDs
- 2026-07-29 Codex: updated Design; Claude cleared blocking items → implement

Cursorが従うべきなのは、この成果物です。チャット履歴は任意ですが、ファイルは必須です。

各CLIのインストールと呼び出し

正確なインストール手順は変わります。各ベンダーの最新ドキュメントを参照してください。ここで重要なのは、非対話での呼び出しパターンです。

Codex：設計パス

Codexの非対話モードは codex exec です。既定では読み取り専用のサンドボックスで動きます。ハンドオフファイルを更新する設計ジョブには、ワークスペースへの書き込み権限が必要です。

cd ../app-pricing-section
codex exec --sandbox workspace-write "$(cat <<'EOF'
Read AGENTS.md and docs/handoffs/2026-07-29-pricing-section.md.
Status is design. Produce the Design section only:
- proposed files
- component/API boundaries
- test plan
- risks
- open questions
Do not implement application code.
Set status to design-review and next owner to claude.
Append a Decision log entry.
EOF
)"

設計をその場で舵取りしたいときだけ、対話型のcodexを使ってください。スクリプトや逐次実行ではcodex execを選んでください。

Claude Code：レビューパス

Claude Codeのprintモードは、ハンドオフファイルのレビューと更新ができます。ただし、そのworktreeへの書き込みを権限設定が許している場合に限ります。スコープは狭く保ってください。

cd ../app-pricing-section
claude -p --permission-mode acceptEdits --max-turns 30 --max-budget-usd 5 --output-format text "$(cat <<'EOF'
Read AGENTS.md / CLAUDE.md and docs/handoffs/2026-07-29-pricing-section.md.
You are the reviewer. Do not implement application code.
Challenge the Design section for missing edge cases, local-architecture mismatches, weak tests, and security issues.
Write findings into the Review section as Blocking vs Non-blocking.
If blocking findings exist, set status to design and next owner to codex.
Otherwise set status to implement and next owner to cursor.
Append a Decision log entry.
EOF
)"

Claudeの権限モードでは非対話でファイルを書けない場合、レビューは読み取り専用で実行し、Review節は人かスクリプトがハンドオフファイルへ貼り付けてください。使い捨てのworktreeでハンドオフを更新するときは、--permission-mode acceptEdits（または設定の許可リスト）を選んでください。本番相当のチェックアウトで--dangerously-skip-permissionsに手を出さないでください。

スクリプト実行に役立つClaude Codeの制御は次のとおりです（CLIリファレンスを参照）。

• -p / --print — 非対話で完了させる
• --max-turns — ループの上限
• --max-budget-usd — 支出の上限
• --output-format json|text|stream-json — 自動化向け
• --permission-mode acceptEdits — スコープを絞ったworktreeでレビューがハンドオフファイルを書く必要があるとき

本番のチェックアウトで--dangerously-skip-permissionsを安易に使わないでください。

Cursor：実装パス

Cursor CLI（agent）を使います。ハンドオフファイルに記録した専用のworktreeを使ってください。メインのチェックアウトから実装しないでください。

cd ../app-pricing-section
agent -p --trust --sandbox enabled --output-format text "$(cat <<'EOF'
Read AGENTS.md and docs/handoffs/2026-07-29-pricing-section.md.
Status must be implement or fixes.
Implement only the approved Design, respecting Review blocking resolutions.
Keep the patch small. Add or update tests from the Verification section.
Run the verification command and record the result in the handoff file.
Set status to impl-review and next owner to claude.
Do not merge.
EOF
)"

重要なCursor CLIのフラグは次のとおりです。

• -p / --print — 非対話。書き込みとシェルツールへのアクセスはすでに持つ
• --force / --yolo — 拒否されていない限りシェルコマンドを自動承認。使い捨てサンドボックスでのみ使い、コードを書く既定にはしない
• --sandbox enabled|disabled — 実行のサンドボックスモード。--trust 付きで実装するときは enabled を優先
• --trust — 自動化でワークスペースを信頼する
• -w / --worktree [name] — ~/.cursor/worktrees/<repo>/ 配下の隔離チェックアウト（手動の git worktree add とはパスが異なる。使う場合はハンドオフのBranch/Worktree欄を合わせて更新する）
• --mode plan または --mode ask — 計画または読み取り専用
• --output-format text|json|stream-json

レビュー専用でCursorを実行するときは、askまたはplanモードを使うか、明示的に「編集しない」と指示してください。ハンドオフに書いたパスと実装者のチェックアウトを一致させるため、手動のgit worktree addを使ってください。

スクリプト化されたワークフローについては、CursorのヘッドレスCLIのガイダンスも参照してください。

指示ファイルの対応表（真実の重複を避ける）

すべてのエージェントに効く規則は、移植可能な正本を1つに保ち、各ツールが必要とするブリッジだけを使ってください。ツール固有の規則はその場に留めます。方針を複製すると更新点が増え、ドリフトのリスクが上がります。各ツールが意図した規則セットを読み込んでいることを、テストで確認してください。

パイプライン全体の例

きれいなリポジトリと、まだ何もない機能を前提にします。

1. 隔離されたworktreeを作る

git fetch origin main
git worktree add -b feat/pricing-section ../app-pricing-section origin/main
cd ../app-pricing-section
mkdir -p docs/handoffs

ハンドオフファイルにGoal、Non-goals、Verificationを書き込んでください。チームがPR上で契約を見えるようにしたいなら、その雛形をコミットしてください。

2. Codexが設計する

CodexがDesign節を書きます。ファイル、インターフェース、テスト、リスクです。ステータスはdesign-reviewになります。

実際の設計出力は、次のような形になるはずです。

## Design
Files:
- `src/components/marketing/PricingSection.tsx` (new)
- `src/components/marketing/PlanCard.tsx` (reuse)
- `tests/e2e/marketing-pricing.spec.ts` (new)

Boundaries:
- PricingSection owns layout and plan list
- PlanCard remains presentational
- CTA links use existing `trackEvent()` + `getCtaClickProps()` helpers

Test plan:
- three plans visible
- CTA hrefs resolve
- analytics helper called once per click

Risks:
- hardcoding plan IDs out of sync with CMS

3. Claudeが設計をレビューする

レビューのプロンプトがBlocking／Non-blockingに分けた指摘を要求するため、曖昧な設計はブロックされて戻ってきます。例を示します。

ブロッキング：
1. 積み上げたプランカードのモバイルレイアウト方針がない。
2. Designに検証コマンドが書かれていない（DesignとVerificationの両方に追加する）。
非ブロッキング：
- プランデータの定数切り出しを検討する。

ステータスはdesignに戻ります。implementへ進むのは、ブロッキング項目がDesignに反映されて解消されたあとだけです。

4. Cursorが実装する

Cursorは、承認された設計だけを実装します。そのうえで次を実行します。

pnpm test:e2e --grep "pricing"

結果を記録し、PRを開くか、開く準備をして、ステータスをimpl-reviewにします。

5. Claudeが実装をレビューする

2回目のClaude実行では、新たに思いついた理想像ではなく、ハンドオフに照らしてdiffをレビューします。ブロッキングの指摘があれば、ステータスをfixes、オーナーをcursorにします。指摘がなければ、人がマージできるようdoneにします。

6. 人がマージする

保護ブランチのオーナーシップは、人が持ち続けてください。エージェントは速いジュニアにはなれますが、リリースマネージャーにしてはいけません。

プラットフォームなしのシェルオーケストレーション

単純なシーケンサーで十分です。

#!/usr/bin/env bash
set -euo pipefail
ROOT="${1:?worktree path}"
HANDOFF="${2:?handoff file}"
cd "$ROOT"

status() {
  # Prefer the metadata Status field near the top of the handoff file.
  awk '/^- Status:/{print $3; exit}' "$HANDOFF"
}

case "$(status)" in
  design)
    codex exec --sandbox workspace-write "Read AGENTS.md and $HANDOFF. Fill Design only, then set status=design-review and next owner=claude. Do not implement application code."
    ;;
  design-review|impl-review)
    claude -p --permission-mode acceptEdits --max-turns 30 --max-budget-usd 5 --output-format text "Review $HANDOFF per AGENTS.md. Update Review + status only. Do not implement application code."
    ;;
  implement|fixes)
    agent -p --trust --sandbox enabled --output-format text "Status must be implement or fixes. Implement or fix per $HANDOFF and AGENTS.md. Update handoff. Do not merge."
    ;;
  done|blocked-human)
    echo "No agent action for $(status)"
    ;;
  *)
    echo "Unknown status in $HANDOFF" >&2
    exit 1
    ;;
esac

これは意図的に地味に作ってあります。地味なオーケストレーションはデバッグできます。サンドボックスと権限モードは、その段階が許す限り締めてください。設計とレビューに、広いシステムアクセスは必要ないはずです。

失敗モード

編集や権限を自動承認する非対話のフラグは、サンドボックスやスコープを絞ったworktreeのための便宜的な手段です。本番のアクセス制御モデルではありません。

まだ自動化しないもの

• 保護ブランチへのマージ
• 本番デプロイ
• シークレットのローテーション
• 人による確認済み計画なしのスキーママイグレーション
• ハンドオフファイル自体が、サニタイズなしの信頼できない外部投稿者から来るワークフロー

実務の出発キット

1. コマンド、パッチ規則、マルチエージェントプロトコルを含むルートのAGENTS.mdを追加してください。
2. @AGENTS.mdを含むCLAUDE.mdを追加してください。
3. docs/handoffs/_template.mdを追加してください。
4. 小さな機能を1つ選んでください。
5. 設計 → レビュー → 実装 → レビューを、一度手で回してください。
6. そのあとで初めて、ステータス遷移をシェルのシーケンサーに包んでください。

同じエージェントに、会社の共有バックログからタスクを取らせる必要があるなら、Linear MCPと、Linearのマルチエージェントプロジェクト管理のclaim/reviewステータスモデルを足してください。markdownのハンドオフは、Issue単位の技術ノートとして引き続き役に立ちます。

標準は契約である

Codex、Claude Code、Cursorは、すでに能力が重なっています。これらがチームになるのは、「一緒に働いて」と抽象的に頼むのをやめ、目に見える契約を強制したときです。

• 共有指示
• 実行ごとの明示的な役割
• ステータス付きハンドオフmarkdown
• 隔離されたworktree
• 境界のあるCLI呼び出し
• マージとリリースの人によるオーナーシップ

これだけで、今日あるツールだけを使って、本格的なローカルのエージェントチームを動かせます。そして、そのチームがエンジニアリングではなく即興をしているとき、すぐに気づけるようになります。