Codex x ClaudeCodeを連携したエージェント開発チームを作って動かしてみた

開発のAI駆動に向けての試行錯誤第一弾としての記録です。

この記事でわかること

OpenAI CodexとClaude Codeを組み合わせた「設計→実装→レビュー」の自動化フローの作り方
各エージェントの役割分担と実際の動き
ダミータスクで試した結果と所感

背景: なぜエージェントチーム？

最近、AIコーディングエージェントがどんどん進化しています。ClaudeやCodex, Geminiなど

様々なAIがあり、この記事を読む皆さんならご存知かと思われますが彼らも得手不得手があります。

そこで考えたのが、人間の開発チームと同じように役割を分けるというアプローチです。設計者、エンジニア、レビュアーをそれぞれ別のAIエージェントに担当させる。しかもCodexとClaudeという異なるモデルを得意分野に応じて使い分ける。巷で見かけた構成をチームにした感じですね。

チーム構成: 5エージェントの役割

目指すチームはこんな感じ。簡単な実装を任せられるような最小限の構成です。

※NotionAgentに関しては、以前の記事をご覧ください！

#役割モデル担当

1.Codex設計者 OpenAI Codex (model GPT5.4)
- コードベースを読み設計ドキュメントを作成
2. Claudeエンジニア Claude Opus 4.6
- 設計をもとに実装
3. Codexレビュアー OpenAI Codex(model GPT5.4)
- 実装をレビューしAPPROVE/REQUEST_CHANGES
4. Notionタスク管理 Claude Sonnet 4.6
- タスク完了後にセッションからタスク生成
5. Notion記事役 Claude Opus 4.6
- タスク管理と並行で記事2本作成

エージェント構造

各エージェントは agents/ 配下に独立したディレクトリを持ち、CLAUDE.md（役割定義）と skills/SKILL.md（フロー手順）の2ファイルで構成されています。

agents/
├── codex-architect/
│   ├── CLAUDE.md          # 役割・境界・知的誠実性ルール
│   └── skills/
│       └── SKILL.md       # 設計ドキュメント作成フロー
├── claude-engineer/
│   ├── CLAUDE.md
│   └── skills/
│       └── SKILL.md       # 実装フロー
├── codex-reviewer/
│   ├── CLAUDE.md
│   └── skills/
│       └── SKILL.md       # レビューフロー・観点チェックリスト
├── notion-task-manager/
│   ├── CLAUDE.md
│   └── skills/
│       └── SKILL.md       # タスク生成フロー
└── notion-writer/
    ├── CLAUDE.md
    └── skills/
        └── SKILL.md       # 記事作成フロー（分割方針・品質基準）

CLAUDE.md に役割・担当範囲・フロー上の位置を書いておくと、エージェント起動時に自分で読んで自律的に動いてくれます。

フロー図

Codex設計者 → Claudeエンジニア → Codexレビュアー
                                    ├─ APPROVE → 完了トリガー
                                    └─ REQUEST_CHANGES → エンジニアに差し戻し

完了後（並行実行）:
  → Notionタスク管理: セッションからタスク生成
  → Notion記事役: 記事を2本作成

ClaudeからCodexを呼び出す仕組み

このチームの構成を考えるにあたり、こちらの記事を参考にしました。Claude CodeからCodexを呼び出す方法として、当初はMCPを使う選択肢もあったのですが、Skillベースの実装に落ち着いています。確かにこちらの方がログが出るので色々と便利ですね。

基本コマンド

Codexエージェントの SKILL.md には以下のコマンドパターンを定義しています。

codex exec --full-auto --sandbox read-only --cd <プロジェクトディレクトリ> "<依頼内容>"

オプション役割

--full-auto

確認なしで自動実行

--sandbox read-only

読み取り専用。ファイル書き換え不可

--cd <dir>

対象リポジトリを指定

--sandbox read-only がポイントで、これによって Codexはコードを読むだけで書き換えられないという安全性が担保されています。実際にファイルを変更するのはClaude Codeだけ、という役割分担が明確になります。

SKILL.md でフローを定義する

各Codexエージェントの SKILL.md に「どのコマンドを、どのタイミングで、どんな指示で実行するか」を記述しておきます。Claude Codeはこれを読んでBashツールでcodex CLIを叩く、という流れです。

設計フェーズの例（codex-architect の SKILL.md より抜粋イメージ）:

# 1. コードベースを読み込んで設計ドキュメントを出力させる
codex exec --full-auto --sandbox read-only --cd /path/to/project \\
  "以下のタスクに対する設計ドキュメントを作成してください: {task}
   トレードオフや懸念点も明示すること。
   確認や質問は不要です。具体的な設計案まで自主的に出力してください。"

レビューフェーズ（codex-reviewer）も同様の構造で、実装差分を渡してAPPROVE/REQUEST_CHANGESの判断を出力させています。

実際に動かしてみた

テストタスクとして「鳥ドメインモデルをTypeScript+DDDで実装」を流しました。今回は Claude Code Agent Teams の TeamCreate + Agent ツールを使い、5エージェントを正式起動しています。

チーム起動の流れ

TeamCreate → Agent × 5（並行スポーン）→ 各エージェントがチェックイン

各エージェントは agents/ 配下の CLAUDE.md を読んで役割・境界を自律的に把握し、チームリードにチェックインメッセージを送ってきます。これが意外と気持ちいい。

Step 1: Codex設計者（codex-architect）

チームリードからタスクを受け取ったcodex-architectが設計ドキュメントを作成。Bird エンティティ、ValueObject（Species / Habitat / BirdCall）、BirdRepository インターフェース、BirdSearchService の構成を定義しました。

設計ドキュメントにはトレードオフを6項目明示していて（BirdOrderの網羅性、filterByCallの全件取得問題、ID生成戦略など）、「問題なし」と言わずに弱点を自ら出してくれる設計になっています。

Step 2: Claudeエンジニア（claude-engineer）

設計ドキュメントを受け取り、TypeScript strict モードで7ファイルを実装。

domain/bird/
  ├─ entities/         ← Bird（private constructor + static create）
  ├─ value-objects/    ← Species, Habitat, BirdCall
  ├─ repositories/     ← BirdRepository（インターフェース）
  ├─ services/         ← BirdSearchService（DI注入）
  └─ index.ts          ← barrel export

ValueObjectはすべて private constructor + static create パターンで不変性を保証。ReadonlyArray + Object.freeze で配列の改ざんも防いでいます。

Step 3: Codexレビュアー（codex-reviewer）

ここが今回も一番おもしろかったです。3件のMUST FIXで REQUEST_CHANGES が返ってきました。

hasCall("") 空文字バグ — String.includes("") は常に true を返すため、空文字入力で全件マッチしてしまう。データ漏洩＆パフォーマンスリスク
Bird エンティティに equals がない — 全ValueObjectにequalsがあるのに集約ルートにないのはDDD的に不整合
集約ルートの振る舞い不足 — イミュータブル設計なのに addHabitat / removeHabitat 等がなく、貧血ドメインモデルになっている