AIモデルは単体で選ばない――私がClaudeで実装し、Codexでレビューする理由

ccf代表
2 日前
読了時間: 21分

生成AIを開発に利用するとき、「どのAIモデルが最も優秀か」という比較に目が向きがちです。しかし、実際の開発では、AIモデル単体の性能だけで開発効率や品質が決まるわけではありません。

重要なのは、 どの開発ツールから、どのAIエージェントを使い、どのモデルに何の役割を担当させるか という組み合わせです。

現在、私の開発環境は、次の2系統で構成しています。

メイン環境： Ghostty＋Herdr＋Claude Code CLI
予備・バックアップ・事前調査環境： Zed＋Z.ai、またはZed＋Sakana AIのFugu Ultra

メイン環境では、Claude CodeのOpus 4.8を実装担当として利用し、 Codexを独立したレビュー担当として組み合わせています。

この記事では、私がこの構成を選んでいる理由と、 AIモデル、AIエージェント、開発ツール、レビュー規約をどのように組み合わせているかを紹介します。

１．AIモデル、AIエージェント、開発ツールは別物

まず、混同されやすい用語を整理します。

分類	役割	私の環境での例
開発インターフェース	人間がコードやAIを操作する画面	Ghostty、Zed
エージェント管理	複数のターミナルやAIエージェントのセッションを管理する	Herdr
AIエージェント	コードを読み、ファイルを変更し、コマンドやテストを実行する	Claude Code、Codex
AIモデル	推論、設計、コード生成、レビューを行う知能部分	Opus 4.8、Z.aiで利用するモデルなど
モデル・オーケストレーター	複数のモデルや専門エージェントを組み合わせて問題を解く	Sakana AI Fugu Ultra
レビュー規約	AIエージェントが確認すべき観点、出力形式、完了条件を定義する	rules/codex_review.md

GhosttyやZedは、AIモデルではありません。人間がコードやAIエージェントを操作するためのインターフェースです。

Claude CodeやCodexは、AIモデルを利用しながら、リポジトリの調査、ファイル編集、コマンド実行、テスト、レビューなどを行うAIエージェントです。

さらに、AIエージェントを実務で安定して利用するには、モデルとツールを接続するだけでは不十分です。

何を確認するのか、どの形式で報告するのか、どこまで対応すれば作業完了とするのか という運用ルールも必要になります。

この違いを理解すると、単純な「モデルAとモデルBの比較」ではなく、 開発プロセス全体をどのように設計するか という視点を持てるようになります。

２．私のメイン開発環境

開発者
  ↓
Ghostty
  ↓
Herdr
  ├─ Claude Code CLI
  │    └─ Opus 4.8：調査・設計・実装・テスト
  │
  └─ Codex
       └─ rules/codex_review.mdに基づくコードレビュー

Ghostty：開発作業の入口

メイン環境の入口にはGhosttyを使用しています。

ターミナルを中心に開発することで、 AIエージェントが実行したコマンド、テスト結果、ログ、Gitの差分を、通常の開発作業と同じ流れで確認できます。

GUI上のチャットだけでAIを利用するのではなく、 AIエージェントを開発端末の中で動かす ことが、この構成の基本です。

AIがどのコマンドを実行し、どのファイルを変更し、どのテストが成功または失敗したのかを確認できるため、作業内容の透明性も高くなります。

Herdr：複数エージェントを管理する層

Herdrは、複数のターミナルセッションやコーディングエージェントをまとめて管理するために使用しています。

例えば、次のように役割ごとに作業画面を分けられます。

Claude Codeで実装する画面
Codexでレビューする画面
テストやビルドを実行する画面
ログやGit差分を確認する画面

AIエージェントを1つだけ利用する場合は、通常のターミナルでも十分です。

しかし、実装担当、レビュー担当、調査担当などを並行して動かすようになると、どのエージェントが何をしているのかを管理する仕組みが必要になります。

Herdrは、AIモデルそのものではなく、 複数のAIエージェントを開発チームのように扱うための管理レイヤー として位置付けています。

Claude Code＋Opus 4.8：実装担当

メインのコーディングには、 Claude Code CLIからOpus 4.8を使用しています。

主な担当範囲は次のとおりです。

既存コードと関連仕様の調査
実装方針の作成
複数ファイルにまたがる変更
データベースやAPIを含む実装
コマンドの実行
テストやビルドの実行
エラー発生時の原因調査と修正

特に、単純なコード補完ではなく、 既存システムを理解したうえで変更を加える作業 を担当させています。

実装前には関連ファイルを調査させ、変更対象、影響範囲、既存の実装パターンを確認したうえで作業を開始させます。

これにより、単に動くコードを生成するのではなく、既存リポジトリの設計や規約に合わせた実装を行いやすくなります。

Codex：独立したレビュー担当

Claude Codeが実装した結果は、そのまま採用せず、 Codexにレビューさせています。

ここで重要なのは、同じAIに「自分が書いたコードを自己レビューさせる」のではなく、 別のモデル、別のエージェント、別の視点で確認する ことです。

実装担当のAIは、一度決めた設計方針を正しいものとして作業を進める傾向があります。

そのため、実装自体は整っていても、次のような問題を見落とす可能性があります。

前提条件の誤り
既存機能への副作用
例外処理の不足
権限チェックの不足
セキュリティ上の問題
パフォーマンスの悪化
テストケースの不足

Codexには、単なるコードの説明ではなく、実装担当とは異なる立場から問題点を探させます。

AIによるコードレビューで重要なのは、別のAIにも同じコードを書かせることではありません。実装を担当していないAIに、異なる評価基準で問題点を探させることです。

３．Codexレビューはモデル任せにしない

Codexによるレビューでは、単に「このコードをレビューしてください」と依頼しているわけではありません。

リポジトリ内の rules/codex_review.md にレビュー基準を定義し、 Codexが毎回同じ基準で確認できるようにしています。

これは、AIモデルの性能だけに品質を依存させず、 人間が定義したルールに沿ってAIエージェントを動かす ための仕組みです。

AIモデルとAIエージェントを組み合わせる際には、どのモデルを選ぶかだけでなく、次の項目をセットで考える必要があります。

AIエージェントにどの役割を持たせるか
どのルールに基づいて判断させるか
どの形式で結果を報告させるか
指摘をどの工程で修正するか
どの条件を満たせば完了とするか

全改修に共通する基本レビュー観点

変更内容にかかわらず、Codexには最低限、次の4つの観点を確認させています。

機能的な副作用や新しいバグを導入していないか
パフォーマンスに悪影響を与えていないか
セキュリティ上の懸念がないか
既存動作を意図せず変更するリグレッションがないか

これらは、すべての変更に共通する基本チェックです。

コードが一見正しく動いていても、既存機能を壊していたり、特定条件で処理が遅くなったり、認証や認可の抜けが発生したりする可能性があります。

そのため、実装内容だけでなく、 変更によってシステム全体にどのような影響が出るか を確認させています。

レビュー結果はP1・P2・P3で分類する

Codexのレビュー結果は、重要度に応じて次の3段階に分類します。

優先度	意味	対応方針
P1	重大な問題	原則として必ず修正する
P2	中程度の問題	原則として修正する
P3	軽微な問題や改善提案	影響、工数、将来性を判断して対応する

このように出力形式まで決めておくことで、レビュー結果を単なる感想として扱うのではなく、修正の優先順位を判断しやすくなります。

P1とP2は原則対応し、 P3については、修正コストや影響範囲を人間が判断します。

４．変更内容に応じてレビュー項目を切り替える

すべてのコード変更を同じ観点だけでレビューしても、システム固有の重要な問題を見落とす可能性があります。

そのため、 rules/codex_review.md では、変更されたコードの種類に応じた必須チェックも定義しています。

生SQLを追加・変更した場合

マルチテナント環境における生SQLの変更では、特にテナント分離が破壊されていないかを確認します。

Codexが確認する主な項目は次のとおりです。

テーブル名が固定されているか
テーブル名を動的に組み立てていないか
テーブル名やSQL文を文字列連結していないか
値の埋め込みにはバインド変数を使用しているか
SQLへ値を直接文字列連結していないか
SET search_pathなどによるスキーマ切り替えがないか
他スキーマを明示した参照がないか
接続中のテナントスキーマ内だけを参照しているか

これらはCodexによる確認だけでなく、 CI上の scripts/check-raw-sql.mjs でも機械的に検知します。

例外として // allow-raw-sql: を付与している箇所についても、単にコメントが存在するかだけではなく、 例外を許可する理由が妥当か までレビュー対象にします。

AIレビューでは、コードの文脈や例外理由の妥当性を確認し、 CIでは禁止パターンを確実に検知します。

新しいAPIルートを追加した場合

新規APIルートでは、IDOR対策を重点的に確認します。

IDORとは、リクエスト内のIDを変更することで、本来アクセスできない他ユーザーや他テナントのリソースを参照または変更できてしまう問題です。

Codexには、次の項目を確認させます。

認証処理

ハンドラの冒頭で requireAuth()、 getCurrentUser()、 requireTenantAdmin() などを実行しているか
未認証の場合にHTTP 401を返すか
認証処理より前に機密処理を実行していないか

ユーザーIDの取得元

ユーザーIDを認証結果から取得しているか
リクエストボディの自己申告ユーザーIDを信用していないか
クエリパラメータの自己申告ユーザーIDを信用していないか

親IDの解決

親リソースのIDをデータベース上の情報から解決しているか
クライアントが申告した親IDをそのまま信用していないか

所有権と権限の確認

checkProcedureAccess() を適切に使用しているか
checkProcedureExecutor() を適切に使用しているか
checkProcedureCreator() を適切に使用しているか
操作内容に応じて所有権チェックを使い分けているか

親子関係の整合性

URL上の親IDと、取得したリソースの親IDが一致しているか
子リソースが指定された親リソースに属しているか
異なる親リソース配下のデータを操作できないか

認証されていることと、対象リソースへのアクセス権があることは別問題です。

そのため、Codexには認証処理の有無だけでなく、 対象リソースに対する所有権や操作権限まで確認 させています。

middleware matcherの除外パスを変更した場合

middlewareのmatcherから除外されたパスは、共通の認証処理を通過しない可能性があります。

そのため、除外パス配下のコードを変更した場合は、次の点を確認します。

対象パスがmiddlewareの除外対象か
除外対象の場合、各APIルートで個別認証が実装されているか
@auth-exemptが不適切に使用されていないか

@auth-exempt を認めるのは、次のパスに限定しています。

api/health/*
api/auth/*

それ以外のパスで使用されていた場合は、認証回避につながる可能性があるためP1として扱います。

この条件も、CI上の scripts/check-middleware-exempt-auth.mjs で機械的に検知します。

adminコードを変更した場合

管理者向け機能は、一般ユーザー向け機能よりも強い権限を持ちます。

そのため、入力値、外部通信、OSコマンド、認証、秘密情報の取り扱いを重点的に確認します。

入力検証

zodなどを使用した入力検証があるか
想定外の型や値を拒否しているか
長さ、形式、列挙値などの制約があるか

SSRF対策

ユーザー入力のURLへ無制限にアクセスしていないか
localhostや内部ネットワークへのアクセスを防止しているか
許可するプロトコルや接続先を制限しているか

Command Injection対策

OSコマンドにユーザー入力を文字列連結していないか
execFileまたはspawnを使用しているか
shell:falseが指定されているか
引数を配列として安全に渡しているか

Prototype Pollution対策

任意のキーをオブジェクトへ無制限にマージしていないか
protoなどの危険なキーを許可していないか
外部入力を深いオブジェクトへ安全確認なしで反映していないか

安全でないデシリアライズの防止

evalを使用していないか
Function()を使用していないか
外部入力をコードとして評価していないか
信頼できないデータを危険な形式で復元していないか

認証と認可

requireAdmin()を適切に使用しているか
authenticateTenant()を適切に使用しているか
管理者権限を持たないユーザーが実行できないか
対象テナントの境界を越えて操作できないか

秘密情報のログ出力防止

パスワードをログへ出力していないか
APIトークンやアクセストークンをログへ出力していないか
接続文字列や秘密鍵をログへ出力していないか
エラーオブジェクトに秘密情報が含まれていないか

５．AIレビューとCIを組み合わせる

Codexによるレビューは、コードの文脈や設計意図を考慮できる一方で、毎回必ず同じ問題を検知できるとは限りません。

一方、CIによる検査は、あらかじめ定義された条件を確実に確認できますが、コードの背景や例外理由までは十分に判断できません。

そのため、私の環境では、 AIレビューとCIを次のように役割分担させています。

確認方法	主な役割
Codexレビュー	文脈、影響範囲、設計上の問題、例外理由の妥当性を確認する
CIスクリプト	禁止パターンや必須条件を機械的かつ継続的に検知する
人間	最終的なリスク判断、例外承認、P3を含む対応方針を決定する

AIレビューか静的検査のどちらか一方に依存するのではなく、 AI、CI、人間の3層で確認する ことが重要です。

AIは文脈を読み、 CIは決められたルールを確実に適用し、人間はビジネス上のリスクと修正コストを判断します。

６．Codexはフォアグラウンドで直接起動する

Codexレビューの実行方法についてもルールを決めています。

Agent toolから、 subagent_type: "codex:codex-rescue" を指定し、フォアグラウンドで直接起動します。

Agent tool
  └─ subagent_type: "codex:codex-rescue"
       └─ foregroundで実行

次の実行方法は禁止しています。

Skillの/codex:rescueを経由すること
run_in_background: trueでバックグラウンド実行すること

フォアグラウンドで実行する理由は、レビュー結果をその場で取得し、後続の修正工程へ確実につなげるためです。

バックグラウンド実行にすると、レビューの完了前に次の作業へ進んだり、結果を確認しないままPRを作成したりする可能性があります。

AIエージェントを複数組み合わせる場合は、単に並列化すればよいわけではありません。

後続工程が前工程の結果に依存する場合は、意図的に直列化する ことも重要です。

７．レビューは一度で終わらせない

CodexからP1やP2の指摘を受けた場合は、 Claude Codeまたは人間がコードを修正します。

ただし、修正した時点でレビュー完了とはしません。

修正によって新しい問題が発生していないかを確認するため、 Codexを再度起動して再レビューを行います。

Claude Codeで調査・実装
  ↓
テスト・CI実行
  ↓
Codexレビュー
  ↓
P1・P2を修正
  ↓
テスト・CI再実行
  ↓
Codex再レビュー
  ↓
重大な指摘が解消されたことを確認
  ↓
PR作成

PRを作成するのは、再レビューによって重要な指摘が解消されたことを確認した後です。

AIレビューの価値は、指摘を出させることではありません。指摘を修正し、再レビューで解消を確認するところまでを開発フローとして固定することにあります。

８．メイン構成のメリット

1．実装とレビューを分離できる

Claude Codeが実装し、Codexがレビューすることで、一つのモデルに設計、実装、検証のすべてを依存する状態を避けられます。

これは、人間の開発チームで開発者とレビュアーを分けるのと同じ考え方です。

実装担当は変更を完成させることに集中し、レビュー担当は問題を見つけることに集中します。

2．異なるモデルの得意分野を利用できる

モデルによって、長い作業を継続する能力、コードの読み方、問題点の見つけ方、説明の仕方には違いがあります。

すべての作業を一つのモデルに任せるよりも、実装に向いたモデルとレビューに向いたモデルを組み合わせたほうが、開発プロセス全体の品質を高めやすくなります。

3．レビュー品質をルールで標準化できる

Codexへ毎回自由形式でレビューを依頼すると、確認項目や出力形式が変わる可能性があります。

rules/codex_review.md にレビュー観点を定義することで、担当するAIモデルが変わっても、一定の確認基準を維持しやすくなります。

特に、テナント分離、IDOR、middlewareの認証除外、 admin機能など、リポジトリ固有のリスクを明文化できる点が重要です。

4．特定ベンダーへの依存を減らせる

複数ベンダーのモデルを使用していれば、利用制限、障害、モデル変更、料金体系の変更が発生した場合にも、開発作業を継続しやすくなります。

AIモデルの性能だけでなく、 サービスを利用できなくなった場合の代替経路 も開発環境の一部として考える必要があります。

5．ターミナル上で作業履歴を確認できる

AIが実行したコマンドやテスト結果をターミナル上で確認できるため、「AIが何をしたのか分からない」という状態を減らせます。

Gitの差分、テスト結果、実行ログを人間が確認できることは、 AIエージェントを安全に利用するうえで重要です。

6．AI、CI、人間の役割を分けられる

すべての確認をAIだけに任せるのではなく、コードの意味はAI、禁止パターンはCI、最終判断は人間というように、役割を分担できます。

これにより、AIモデルの見落としや判断の揺れを開発プロセス全体で補完できます。

９．メイン構成のデメリット

1．構成が複雑になる

Ghostty、Herdr、Claude Code、Codex、CIスクリプトを組み合わせるため、単一のIDEに統合されたAI機能と比べると、環境の理解や管理が必要です。

どのエージェントがどのファイルを変更しているか、どのブランチやワークツリーで作業しているかも意識しなければなりません。

2．モデル間でコンテキストが自動共有されない

Claude Codeが理解している背景情報を、 Codexが自動的にすべて理解するわけではありません。

レビュー時には、少なくとも次の情報を渡す必要があります。

変更の目的
満たすべき要件
Gitの差分
実行したテスト
既知の制約
適用すべきレビュー規約

ただし、実装担当AIの説明をそのままレビュー担当AIへ渡しすぎると、レビュー担当も同じ前提に引っ張られる可能性があります。

そのため、説明文よりも、 要件、実際の差分、テスト結果、レビュー規約 を中心に確認させるようにしています。

3．利用量とコストが増える

実装とレビューで別々のモデルを使用するため、単一モデルだけで完結させる場合より利用量は増えます。

さらに、修正後の再レビューまで実施するため、小規模な変更でも一定のコストが発生します。

すべての変更を同じ深さでレビューするのではなく、影響範囲が大きい変更や、認証、権限、データ更新、インフラ設定などの重要な変更を中心に重点的に使用する方法が現実的です。

4．ルールの保守が必要になる

レビュー規約を一度作成すれば終わりではありません。

新しいAPI、権限モデル、データベース構成、CIルールが追加された場合は、 rules/codex_review.md も更新する必要があります。

古いルールを使い続けると、現在のシステム構成に合わない指摘をしたり、新しいリスクを見落としたりする可能性があります。

１０．予備環境：Zed＋Z.ai

開発者
  ↓
Zed
  ↓
Z.ai
  ├─ 事前調査
  ├─ 別の実装案の作成
  ├─ エラー原因の仮説作成
  └─ メイン環境が使えない場合の代替

Zed＋Z.aiの構成は、主に予備環境、簡易的な調査、別案の作成に使用しています。

メイン環境とは異なるモデルに質問することで、 Claudeが提示した設計とは違う実装方法や、別の原因仮説を得られることがあります。

この構成の主な用途は次のとおりです。

実装前の簡易調査
複数の実装案の比較
エラー原因の仮説出し
Claude Codeの回答に対するセカンドオピニオン
メインモデルの利用制限時における代替作業

ZedはエディターとAIの距離が近いため、コードを見ながら短い質問を繰り返す作業に向いています。

メイン環境で本格的な変更を開始する前に、 Zed＋Z.aiで関連技術や実装案を調べておくことで、 Claude Codeへ渡す指示を明確にできる場合もあります。

１１．事前調査・難問向け：Zed＋Sakana AI Fugu Ultra

開発者
  ↓
Zed
  ↓
Sakana AI Fugu Ultra
  ↓
複数のモデルや専門エージェントを組み合わせて調査・推論

Fugu Ultraは、単純に一つの大規模言語モデルへ質問する構成とは少し異なります。

複数のモデルや専門エージェントを組み合わせ、問題に応じて役割分担させるオーケストレーション型の仕組みです。

そのため、日常的な小さなコード修正よりも、次のような難易度の高い作業に向いていると考えています。

複数の原因が考えられる障害調査
アーキテクチャの比較検討
既存システムの大規模な分析
セキュリティ上の問題点の調査
実装前の技術調査
複数の技術要素をまたぐ問題

一方で、複数のエージェントを利用する処理は、単一モデルへ問い合わせる場合より、時間やコストが増える可能性があります。

そのため、Fugu Ultraを常時のコーディング担当にするのではなく、 難しい問題を分解し、調査方針や解決策の候補を作る役割 として使用しています。

Fugu Ultraで得られた調査結果を、そのまま実装結果として採用するのではなく、 Claude Codeへ渡す設計材料や、 Codexレビュー時の追加観点として利用する使い方が適しています。

１２．作業内容による使い分け

作業	主に使用する構成	役割
小規模なコード確認や調査	Zed＋Z.ai	素早い確認、実装案、セカンドオピニオン
複数ファイルにまたがる実装	Claude Code＋Opus 4.8	調査、設計、実装、テスト
実装後の確認	Codex＋rules/codex_review.md	独立したコードレビュー
生SQLの変更	Codex＋check-raw-sql.mjs	テナント分離とSQL安全性の確認
新規APIルート	Codex＋認証・所有権ルール	IDOR、認証、認可、親子関係の確認
middleware除外パスの変更	Codex＋check-middleware-exempt-auth.mjs	認証回避の防止
adminコードの変更	Claude Code＋Codex	入力検証、SSRF、Command Injection、認証・認可の確認
原因が分からない複雑な障害	Zed＋Fugu Ultra	原因仮説、調査手順、解決案の作成
重要機能の変更	Claude Code＋Codex＋必要に応じてFugu Ultra	実装、レビュー、第三の視点による検証
利用制限やサービス障害	Zed＋Z.aiまたはFugu Ultra	バックアップ経路として作業を継続

１３．AIエージェントを開発チームとして設計する

この構成では、AIを一つの万能な存在として扱っていません。

人間の開発チームと同じように、それぞれのエージェントへ異なる役割を割り当てています。

役割	担当
実装担当	Claude Code＋Opus 4.8
コードレビュー担当	Codex
レビュー基準	rules/codex_review.md
定型的な安全確認	CIスクリプト
事前調査と簡易相談	Zed＋Z.ai
難問の分解と多角的調査	Zed＋Fugu Ultra
最終判断	人間

このように見ると、重要なのはモデルのランキングではなく、 チームとしてどのように役割分担させるか だと分かります。

１４．複数のAIが同意しても、正しいとは限らない

複数のAIモデルを利用すると、回答の信頼性が自動的に保証されるわけではありません。

異なるモデルであっても、同じ公開情報、似たコード、似た設計パターンを学習しているため、同じ間違いをする可能性があります。

また、実装担当AIの説明をレビュー担当AIへ渡すことで、誤った前提まで共有される可能性もあります。

最終的に必要なのは、人間による確認と、実際に動作するテストです。

Gitの差分を確認する
テストを実行する
CIの結果を確認する
ログを確認する
本番環境と同等の条件で検証する
認証、認可、機密情報の扱いを確認する
AIが実行するコマンドの権限を制限する
P1・P2が解消されたことを再レビューで確認する

AIレビューは、人間のレビューやテストを不要にするものではありません。

人間が確認すべき範囲を絞り込み、見落としを減らすための補助として利用するべきです。

１５．モデルの組み合わせより、運用ルールが品質を決める

Claude CodeとCodexを組み合わせただけでは、高品質な開発フローが自動的に完成するわけではありません。

同じモデルの組み合わせでも、次の項目が定義されているかによって結果は大きく変わります。

実装担当とレビュー担当の役割
レビュー基準
指摘の優先度
変更種別ごとの必須チェック
AIエージェントの実行方法
CIによる機械検査
再レビューの条件
PR作成の条件

私の環境におけるCodexは、自由に感想を述べるチャットAIではありません。

リポジトリ固有のセキュリティ要件と開発規約に基づいて、変更差分を検査する専門レビュアー として位置付けています。

AIを開発チームの一員として利用するのであれば、人間のメンバーと同じように、役割、確認項目、報告形式、実行方法、完了条件を明確にする必要があります。

まとめ：最強のモデルより、役割分担された開発環境

私の現在の構成は、次のような役割分担になっています。

Claude Code＋Opus 4.8： メインの調査、設計、実装、テスト担当
Codex： 実装結果を確認する独立レビュアー
rules/codex_review.md： Codexが従うレビュー基準
CIスクリプト： 禁止パターンや認証漏れを機械的に検知
Zed＋Z.ai：軽量な調査、別案、セカンドオピニオン、バックアップ
Zed＋Fugu Ultra： 複雑な問題の事前調査と多角的な推論
Ghostty＋Herdr： これらのエージェントを操作・管理する基盤
人間： 最終的なリスク判断とPR作成の判断

AI開発環境を考えるときは、「一番性能が高いモデルはどれか」だけで決めるべきではありません。

重要なのは、次の点です。

誰に調査と実装を担当させるか
誰にレビューさせるか
どのレビュー規約を適用するか
どの項目をCIで機械検査するか
複雑な問題を誰に調査させるか
修正後にどのように再確認するか
どの条件を満たしたらPRを作成するか
メインのAIが利用できないとき、どの経路で作業を継続するか

AIモデルを単体の製品として比較するのではなく、 開発チームのメンバーのように役割を割り当てて組み合わせる ことが重要です。

さらに、それぞれのAIエージェントに対して、人間がレビュー基準、実行方法、報告形式、完了条件を定義することで、 AIを単なるコード生成ツールから、実際の開発プロセスを構成するメンバーへ近づけられます。

最強のモデルを一つ選ぶのではなく、 モデル、エージェント、ツール、ルール、CI、人間を組み合わせて、開発工程全体を設計する。

これが、現在の私が考える AIを活用した開発環境の形です。