AIを増やす前に、
役割を分ける。

Netsujoでは、私が主担当として進める一部の実装で、次の工程を採用しています。

1. ChatGPTで目的、要件、制約、受け入れ条件を整理する
2. Claude Codeへの実装指示書をMarkdownで作る
3. Claude Codeが実際のリポジトリを調査し、実装とテストを行う
4. 完成直前の差分をCodexに調査させる
5. 人間が指摘の採否と公開可否を決める

この構成の狙いは、AIを多く使うことではありません。一人の主担当者が進める開発の中へ、設計者・実装者・監査者という役割分離を持ち込むことです。

結論から述べると、役割分離には価値があります。しかし、ChatGPT、Claude Code、Codexをすべての変更へ直列接続する方法は過剰になりやすく、重複読込、トークン消費、後工程での手戻り、ブランチ混乱も生みます。

必要なのはモデルの数ではなく、次の設計です。

• 目的と完了条件を固定するTask Contract
• LLMより先に実行する機械検査
• 変更リスクに応じたレビュー範囲
• 実装者と監査者の権限分離
• 同じ失敗を繰り返さない停止条件
• 最終判断を引き受ける人間の統合責任

2026年6月に公開したAIエージェントで会社を回す ― Netsujoの運用OSを公開するでは、判断を人間が握り、実装と検証をAIへ委ね、誤りを仕組みで止める全体方針を紹介しました。

本記事では、その内部にある一つの実装フローへ焦点を絞ります。なぜこの分業を始めたのか、何が有効だったのか、どこで非効率になったのか、そして次にどのような構成へ改めるべきかを整理します。

なぜ一つの実装に三つのAIを使うのか

人間の開発チームでは、企画担当者が目的を整理し、ITエンジニアが実装し、別のITエンジニアがコードレビューを行います。

一人または少人数の主担当者が開発を進める場合、この分離が弱くなります。要件を考えた本人が実装を指示し、その本人が完成判定まで行うため、最初の前提が検証されないまま最後まで残りやすくなります。

そこで、工程を次のように分けました。

Claude Codeは、コードベースを読み、ファイルを編集し、コマンドを実行できるエージェント型の開発ツールです。CodexはGitHub Pull Requestの差分を対象にレビューし、リポジトリ固有のルールをAGENTS.mdから参照できます。

ただし、製品が異なるだけで独立性が成立するわけではありません。

独立性を作るのは、モデル名よりも、次の条件です。

• 実装者と監査者へ異なる役割を与える
• 監査者へ修正権限を与えない
• 最新差分だけを渡す
• 評価基準を明文化する
• 根拠のない指摘を採用しない
• 同じ差分を繰り返しレビューしない
• 終了条件を先に決める

三つのAIを使う目的は、三人の仮想ITエンジニアを作ることではありません。一つの判断経路へ、意図的な反証工程を入れることです。

ChatGPTに設計させる理由

私の役割はBizDevを起点としており、最初に考えるのはコードではなく、顧客、事業、導線、売上、運用です。

たとえば「分析画面へ顧客のゴールを入力できるようにする」という要望にも、複数の論点があります。

• 誰が入力するのか
• 何のために入力するのか
• ゴールは一つか複数か
• 自由記述か選択式か
• 入力内容が分析ロジックへどう影響するのか
• 既存画面のどこを維持するのか
• 今回は変更しない範囲がどこか
• 何をもって完成とするのか

これらを整理せずに「ゴール入力欄を追加して」とだけ伝えると、AIは不足した前提を推測で埋めます。実装速度が速いほど、曖昧な前提も速くコードになります。

ChatGPTには、実装コードを書かせる前に、要求を次の項目へ変換させます。

• 目的
• 現状
• 解決したい問題
• 対象ユーザー
• 必須要件
• 変更してはいけない条件
• 非目標
• 受け入れ条件
• 想定リスク
• 確認方法
• 未確定事項

ここで重要なのは、詳細なファイル名や実装方法を先回りして決めすぎないことです。

ChatGPTがリポジトリの現状を十分に確認できていない場合、細かな実装指定は誤った前提を固定します。Markdown指示書は完成コードの設計図というより、事業要求と実装結果を照合するためのTask Contractとして使う方が有効です。

設計書の品質は文字数では決まりません。目的、制約、受け入れ条件、非目標が正しいかで決まります。

Claude Codeに実装させる理由

設計書が正しくても、実際のリポジトリには既存の規約、依存関係、未コミット変更、テスト、CI、過去の設計判断があります。

Claude Codeには、指示書をそのまま実行させるのではなく、最初に次を調査させます。

• 現在のブランチとworking treeの状態
• 対象機能の既存実装
• 関連する型、API、データモデル
• 既存のlint、typecheck、test、buildコマンド
• GitHub Actionsで実際に使われている検査
• 既存の失敗と今回の変更で増えた失敗の区別
• 指示書とリポジトリの現実が矛盾していないか

矛盾があれば、実装前に次の形式で差分を報告させます。

• 指示書が前提としている状態
• 実装上そうなっていない箇所
• 取り得る案と、それぞれの影響範囲
• 今回の目的に照らした推奨案

これにより、指示書が誤っていても、その誤りを忠実に実装する事態を防ぎます。

Claude Codeの役割は、会話上の提案を、実際のコード、コマンド、テスト結果へ接続することです。一方で、実装者自身の自己評価だけでは、最初に採用した解釈を引きずる可能性があります。そこで、別の監査工程を置きました。

Codexに完成直前の品質調査をさせる理由

Codexには、Claude Codeの代わりに実装させるのではなく、次の問いへ答えさせます。

• ユーザー要求を満たしているか
• 指示書にない変更が混ざっていないか
• 認証、権限、課金、顧客データへ悪影響がないか
• APIやデータ構造の互換性を壊していないか
• テストが通っていても見逃す論理的な欠陥がないか
• エラー処理、境界条件、運用時の失敗経路が考慮されているか
• 変更範囲に対して実装が過剰ではないか

実装者とは別のコンテキストから差分を見ることで、Claude Codeが当然視した前提を疑えることがあります。

ただし、Codexへ「全体を詳しく調べて、必要なら直して」と依頼すると、役割分離が崩れます。

レビュー担当が修正まで行えば、Claude CodeとCodexのどちらが実装責任を持つのか分からなくなります。差分外の改善、軽微なリファクタリング、同じコミットへの再レビューも増え、トークンと時間を消費します。

Codexの役割は、重大な欠陥を見つける読み取り専用の監査者へ限定する必要があります。

この分業で得られたメリット

曖昧な要求を実装前に発見できる

実装指示書を作る過程で、主語、対象ユーザー、目的、非目標、完了条件の不足が表面化します。コードを書いた後に仕様を考えるより、修正範囲を抑えられます。

設計と実装の差分が記録に残る

「何を頼んだか」「実装上どの前提を変えたか」「どの検査を通したか」がMarkdownとGit差分に残ります。問題が起きたとき、会話の記憶ではなく記録を調べられます。

AIの自己承認を避けられる

設計、実装、評価を同じ会話で連続して行うと、AIは自分が採用した方針を前提に評価しやすくなります。別のコンテキストへ渡すことで、評価の入口を変えられます。

人間が品質判断へ参加しやすい

人間は、すべての実装を手作業で行わなくても、受け入れ条件、変更禁止範囲、リスク、レビュー指摘の採否を通じて品質を管理できます。

指示書が次回の学習資産になる

良い指示書は、その場限りのプロンプトではありません。失敗原因、正しい制約、確認コマンド、再発防止策を追記すれば、Claude CodeのCLAUDE.md、CodexのAGENTS.md、CI、品質ゲートへ移せます。

公開前に一度立ち止まれる

実装速度が上がると、作れたことと、公開してよいことを混同しやすくなります。独立監査を置くことで、公開判断を一度切り離せます。

実際に見えたデメリット

直列工程のため、受け渡しコストが大きい

ChatGPT、Claude Code、Codexが順番に同じ背景を読み直します。設計書が長くなるほど、実装者と監査者が必要な情報を探す負担も増えます。

複数AIを使うこと自体が効率化ではありません。各工程が前工程の成果を読み直す構成では、受け渡しの税（handoff tax）が発生します。

ChatGPTの設計が、リポジトリの現実とずれる

ChatGPTがコードベースを十分に確認していない状態で、ファイル構成や関数名まで指定すると、Claude Codeは誤った設計へ引っ張られます。

詳細さよりも、目的、制約、受け入れ条件、非目標の正確さが重要です。

Codexのレビューが遅すぎる

完成直前に初めて独立レビューを入れると、アーキテクチャやデータモデルの問題が最後に見つかります。修正範囲が広い変更では、実装前または中間時点で設計上の論点だけを確認した方が合理的です。

機械検査で分かる問題までLLMへ渡してしまう

format、lint、typecheck、unit test、buildで判定できる問題をCodexへ読ませる必要はありません。長いログや生成物まで渡すと、コストが増え、重大な問題への注意も薄まります。

「別のAIが確認した」という誤った安心が生まれる

複数のAIが同じ結論へ到達しても、その結論が正しいとは限りません。同じ曖昧な要求を受け取れば、異なるAIでも同じ方向へ誤ることがあります。

レビューの信頼性は、AIの数ではなく、明確なGround Truth、最新の差分、根拠付きの指摘、権限分離、停止条件で決まります。

複数AIが同じブランチを触ると統合負債が生まれる

Claude CodeとCodexの双方が同じブランチを編集すると、変更の所有者が曖昧になります。

未コミット変更、worktree、mainブランチの状態を正しく把握できないまま作業が重なると、修正したはずの変更が戻る、別の差分が混ざる、同じ問題を再調査するといった事態が起きます。

AIが改善候補を出し続け、公開判断が遅れる

AIへ品質改善を頼むと、改善候補はほぼ無限に出てきます。「あと一つ直してから」を繰り返すと、公開阻害要因と公開後改善が混ざります。

品質検査が、公開を止める条件を判定する工程ではなく、不安を減らす儀式へ変わった時点で、運用設計を見直す必要があります。

Netsujoで実際に起きたこと

追加実装が画面全体へ広がった

既存の分析画面へ顧客ゴール欄を追加したいという要望が、改善指示を重ねるうちに画面全体の再設計へ広がったことがありました。

原因は、AIの能力不足よりも、こちらが「既存画面の構造は維持する」「今回変更するのは入力項目と分析への接続だけ」と明記していなかったことです。

曖昧な要望が高速で実装されました。

この経験から、Task Contractへnon_goalsとinvariantsを必須化する方針に改めました。

Claude CodeとCodexの変更が混ざった

Claude CodeとCodexの双方にGitHub上の修正を任せた結果、mainブランチと未コミット変更の状態把握が難しくなったことがありました。

原因は、担当領域、作業ブランチ、正本、統合責任者が未定義だったことです。

これを受け、次のルールを標準化対象にしています。

• 1タスク・1ブランチ
• mainへの直接変更禁止
• Codexは原則読み取り専用
• 実装修正はClaude Codeへ戻す
• merge、push、deployは人間の明示判断
• 同じhead SHAを二重レビューしない

Codexの品質検査コストが膨らんだ

広い範囲の品質調査を依頼すると、Codexはリポジトリ全体を再探索し、Claude Codeがすでに読んだコードも読み直します。

さらに、lintや型検査で判定できる問題、長い成功ログ、lockfile、生成物、差分外コードまで含めると、レビューの焦点がぼやけます。

このため、Codexを停止するのではなく、機械検査では判定しにくい重大な欠陥の検出へ限定する方針へ切り替えます。

三つのAIを常時使う必要はない

現在の直列構成を、そのまますべての変更へ適用する必要はありません。

次の順序が合理的です。

1. 人間が目的とリスクを定義する
2. Task Contractを作成する
3. Claude Codeがリポジトリを調査する
4. 矛盾があれば実装前に報告する
5. 1タスク・1ブランチで実装する
6. 機械検査を実行する（format、lint、typecheck、関連テスト、必要時のみfull test、build）
7. 変更リスクを分類する
8. Claude Codeが修正する
9. 機械検査を再実行する
10. 必要時のみ焦点を絞った再レビューを1回行う
11. 人間が公開判断を行う

7の分類では、Lowリスクの変更はCodexを呼ばず、Mediumリスクは条件に該当したときだけ差分レビューを行い、Highリスクは設計論点の確認と差分レビューの両方を行います。

リスク別の使い分け

この構成では、AIの数ではなく、変更リスクに応じて推論資源を配分します。

巨大変更を一度にCodexへ渡すことも避けます。差分が大きすぎる場合は、Pull Requestまたは変更単位を分割します。

指示書は「詳細な命令書」から「検証可能な契約」へ変える

今後のMarkdown指示書では、最低限、次の項目を必須にします。

とくに重要なのは、non_goals、invariants、stop_conditionsです。

「顧客ゴール欄を追加する」という依頼で、既存分析画面を置き換えないのであれば、それを明記します。三回修正しても同じ失敗が続くなら、AIに続行させず人間へ戻します。PASSを得るためにテスト、型設定、セキュリティ設定を弱めることも禁止します。

AIの自己修正能力を高めるには、反復回数を増やすより、合格条件と停止条件を明確にする方が有効です。

Codexは「全体再調査」から「差分限定レビュー」へ

CodexのGitHubコードレビューは、Pull Requestの差分を対象にし、リポジトリ固有のレビュー規則をAGENTS.mdから参照できます。

この性質を使い、Codexへ渡す情報を次に絞ります。

• Task Contract
• base SHAとhead SHA
• 対象差分
• 関連する最小限のコード
• 機械検査の要約
• 重点的に見るリスク
• 重大な指摘だけを返す条件

渡さないものも決めます。

• リポジトリ全体の無制限な再探索
• 長大な成功ログ
• lockfileや生成物の無目的な全文
• 差分外のリファクタリング提案
• 同じhead SHAへの重複レビュー
• レビュー担当による自動commit、push、merge、deploy

AIレビューは、テスト、CI、ブランチ保護、人間の承認を置き換えるものではありません。品質保証の一層として使います。

Claude Code内部で分ける

外部Codexを毎回呼ばなくても、Claude CodeにはCLAUDE.md、Skills、Subagents、Hooksを使って、プロジェクト固有のルールや検査フローを組み込めます。

たとえば、次の役割をClaude Code内部で分離できます。

• Builder：実装と修正を行う
• Deterministic Judge：lint、typecheck、test、buildを実行する
• Independent Judge：読み取り専用でTask Contractと差分を照合する
• Manager：反復回数、失敗署名、停止条件を管理する

この内部ループで処理できるLow・Mediumリスク変更は、Claude Code内で完結させます。

外部Codexは、認証、課金、顧客データ、重要な診断ロジックなど、高リスク変更の追加監査へ限定します。

異なるモデルを常時起動するより、まず同一環境内で権限と評価基準を分け、必要な場面だけ外部監査を加える方が、コストと再現性のバランスを取りやすくなります。

本当に効果があるかを測る

「三つのAIを使うと品質が上がる」という感覚だけでは、運用を正当化できません。

少なくとも次を記録します。

• 実装開始から公開までのLead Time
• First-pass Success Rate
• 平均修正回数
• Codexの呼び出し回数
• 1レビューあたりのinput、output、total token
• 同一SHAへの重複レビュー数
• Codexが見つけた重大欠陥数
• 機械検査で先に検出できた問題数
• 公開後に発覚した不具合数
• rollback回数
• 人間が統合判断に使った時間

30日単位で比較し、Codexを使った変更と使わなかった変更の結果を見ます。

重大欠陥の検出率が変わらず、コストだけが大きいなら、レビュー条件をさらに絞ります。高リスク領域で公開後不具合を防げているなら、そこへ推論資源を集中します。

測定しなければ、複数AIの分業は開発プロセスではなく信仰になります。

AIが増えても、人間の責任は分散しない

ChatGPT、Claude Code、Codexを並べても、三人のITエンジニアによるチームができるわけではありません。

それぞれは責任を負わない確率的な処理系です。目的が間違っていれば、間違った目的を精緻化します。受け入れ条件が弱ければ、見栄えの良い未完成をPASSと判断します。公開を止める人がいなければ、改善候補を出し続けます。

人間に残る仕事は次のとおりです。

• 何を作るかを決める
• 何を変えないかを決める
• どのリスクを許容するかを決める
• 指摘が仕様変更か不具合修正かを区別する
• どこで修正を止めるかを決める
• 公開後に責任を負う

AIエージェント時代の開発責任者は、コードを書く量が減る一方で、役割、権限、評価基準、停止条件を設計する仕事が増えます。

まとめ

ChatGPTで設計し、Claude Codeで実装し、Codexで監査する構成は、一人の主担当者による開発へ役割分離を持ち込む方法として有効でした。

特に、事業要求をTask Contractへ変換すること、実際のリポジトリで実装すること、別コンテキストから差分を疑うことには価値があります。

一方、すべての変更へ同じ工程を適用すると、重複読込、トークン消費、手戻り、レビュー疲れ、ブランチ混乱が増えます。AIの数を増やすほど品質が上がるという前提は成立しません。

今後の標準は、次の五点です。

1. 指示書をTask Contractとして構造化する
2. Claude Codeが実装前にリポジトリの現実を確認する
3. LLMより先に機械検査を通す
4. Codexは高リスク差分の読み取り専用監査へ限定する
5. 人間が統合責任と停止判断を握る

製品名やモデルは今後変わります。残る資産は、どの役割に何を任せ、何を任せず、何を根拠に合格とし、どこで止めるかという運用設計です。

Netsujoでは、この考え方を自社プロダクトとWebサイトの継続改善で検証し、AI導入・PoC・本番実装の支援にも反映しています。詳細は生成AI導入支援・AI PoC・業務実装で確認できます。

よくある質問

なぜChatGPTとClaude Codeを分けるのですか

ChatGPTでは、顧客価値、目的、制約、受け入れ条件など、事業要求の整理へ集中します。Claude Codeでは、実際のリポジトリ、依存関係、テスト、CIを確認しながら実装します。設計整理とコード変更を分けることで、要求と実装結果を照合しやすくするためです。

すべての変更をCodexでレビューするべきですか

推奨しません。文言、記事、限定的なCSSなどのLowリスク変更は、機械検査で十分な場合があります。認証、課金、顧客データ、DB、公開API、重要な診断ロジックなど、影響が大きい変更へ絞る方が合理的です。

異なるAIを使えば、レビューは独立しますか

製品が異なるだけでは独立性は保証されません。別コンテキスト、明確な評価基準、読み取り専用権限、最新差分、根拠付き指摘、停止条件を組み合わせる必要があります。

人間もコードを読むべきですか

すべての行を手作業で読む必要性は下げられますが、目的、リスク、受け入れ条件、指摘の採否、公開判断は人間が担います。高リスク変更では、重要な差分とテスト結果を人間も確認します。

AI同士で自動修正を続ければ品質は上がりますか

反復回数だけを増やすと、コスト、誤修正、無限ループが増えます。最大修正回数、同じ失敗が続いた場合の停止、予算上限、人間へのエスカレーション条件を先に定義する必要があります。

参考資料

• OpenAI Codex code review in GitHub
• OpenAI Custom instructions with AGENTS.md
• Anthropic Claude Code overview
• Anthropic Create custom subagents
• Anthropic Automate actions with hooks

製品仕様と公式ドキュメントの記載は、2026年8月5日時点のものです。