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を停止するのではなく、機械検査では判定しにくい重大な欠陥の検出へ限定する方針へ切り替えます。

「比較しない」が一部の分析へ伝わっていなかった

Netsujo SIGNALの顧客向け分析画面では、対象期間と比較条件を指定できます。その中に「比較しない」という選択があります。期待する挙動は明確で、「比較しない」を選んだ場合はすべての分析セクションで前期間データを使わないことです。

Claude Codeの実装後、Task Contractと差分をCodexへ渡して照合したところ、次の状態が指摘されました。

• 一部のセクションでは「比較しない」が反映されていた
• 別のセクションには前期間の指定が渡り続けていた
• 画面は表示できた
• 型検査は通った
• 既存テストも通った
• buildも成功した

コードは壊れていません。利用者が選んだ条件と、一部の分析結果の意味が一致していませんでした。

この種の欠陥は型検査では見つけにくいものです。前期間を表す値の型が正しく、関数の引数として受け取れるなら、TypeScript上は問題になりません。既存テストが「データを取得できること」だけを確認していれば、「比較しない場合は全セクションで前期間を渡さない」という契約違反も通過します。

差分レビューで確認する対象は、構文ではなくデータの流れです。利用者の選択、比較条件の正規化、各分析セクションへの引き渡し、表示と集計という経路のどこかで適用が抜ければ、画面が動いても結果の意味が変わります。

この対応では、漏れていた適用箇所を直すだけで終わらせず、次を実装しました。

• 「比較しない」を選んだ場合の回帰テスト（src/lib/signal-portal/analysis-filters.test.ts）
• 分析条件の適用漏れを検査するスクリプト（scripts/check-portal-gating.mjs）
• 上記をpackage.jsonとGitHub ActionsのCIへ接続

重要なのは、Codexが一度問題を指摘したことではありません。指摘を、次回から機械的に止められる検査へ変えたことです。

AIレビューのコメントだけを直して終えると、同じ欠陥が別のセクションで再発します。良い品質検査は、発見した欠陥をテスト、CI、プロジェクトルールへ移し、同じ問題で再び高価な推論を使わない状態を作ります。

検査へ移しても、その検査自体に穴が残る

ただし、検査へ移せば終わりではありません。上の検査スクリプトを追加したあと、別の差分レビューで、検査そのものの欠陥を指摘されました。

コメントを取り除く処理が、文字列リテラルの中にあるURLの//もコメントの開始として扱い、その行の以降を読み飛ばすという内容です。検査は問題なく動いているように見えても、特定の書き方をした行だけを黙って見逃します。見逃したことは、検査の実行結果には現れません。

検査を書いた本人は、その検査が拾えない範囲を想像しにくい状態にあります。テストも検査スクリプトも自分で書いている以上、穴のある場所にはそもそも検査が書かれていません。このため、実装だけでなく、検査スクリプト自体もレビュー対象に含めています。

CIが緑であることは、検査が意図したとおりに効いた証拠にはなりません。検査を足すたびに、その検査が何を拾えないかを別の目で確かめる必要があります。

割り当ては、ツール名ではなく権限・作業単位・受入条件で決める

ここまでツール名で工程を説明してきましたが、運用を続けるとこの書き方は扱いにくくなります。ツールは入れ替わりますし、同じツールでも与える権限によってできることが変わるからです。ツール名で役割を固定すると、ツールを変えた瞬間に運用の説明が全部書き直しになります。

現在は、次の3つで割り当てを決めています。

この3つで書くと、割り当て表からツール名を外せます。

ツール名を書かなくても、この表だけで役割は成立します。実際にどのツールを当てるかは、その時点で権限と作業単位を満たせるものを選べばよく、この記事の前半で挙げた3つの組み合わせも、その一例にすぎません。

独立レビューを担当する人には、そのレビュー対象を変更する権限を持たせないことが要点です。 実装担当が原因を調査し、変更し、自分の変更をテストすることは必要です。ただし、その自己確認を独立レビューとして数えると、実装時の前提が誤っていても同じ前提のまま見逃すおそれがあります。

この表はNetsujoの現在の運用です。組織の規模、扱うデータ、リリース頻度によって適切な区切りは変わるため、すべての開発で有効な配分として書いているものではありません。

三つの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リスクの変更では第三者レビューを呼ばず、Mediumは条件に該当したときだけ差分レビューを行う運用にしていました。推論資源をリスクに応じて配分する、という考え方です。

この運用には穴がありました。分類そのものが外れたとき、何も検出されません。 実際に、Lowとして分類された差分がレビューを経ずに統合され、あとから顧客へ事実と違う状態を出す欠陥が見つかりました。分類の精度を上げるという対処もありますが、分類が外れる可能性は残ります。外れたときに検出がゼロになる設計は、分類の改善では埋められません。

そこで、機械検査がPASSした差分は、内容にも大きさにもよらず第三者レビューを1回通す運用へ戻しました。大きい差分ほどレビューされない、という逆転を作らないためでもあります。

現在、レビューを呼ばないのは次の3つだけです。

• レビュー対象のテキスト差分が0件（画像だけの差し替えなど）
• 機械検査がFAIL、または未実施（先に直す。未実施はPASSではない）
• 自動レビューの回数上限を使い切った（以降は人間が判断する）

リスク分類は推論強度の選択に使う

ルールに一致しないファイルは、下の区分へ落とさず上の扱いにします。判断できないことを、安全だと読み替えないためです。

この構成では、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が見つけた重大欠陥数
• そのうち回帰テストやCIへ移行できた欠陥数
• Codexの指摘が誤っていた件数
• 機械検査で先に検出できた問題数
• 公開後に発覚した不具合数
• rollback回数
• 人間が統合判断に使った時間

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

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

外部の事例も参考になります。OpenAIが2026年1月に公開したDatadogの事例では、過去にインシデントへつながったPull Requestを再現してCodexへレビューさせ、当該インシデントを担当したITエンジニアが「当時その指摘があれば違いがあった」と判断したケースが10件超、調査対象のおよそ22%だったと報告されています。これはOpenAIが公開した個別企業の事例であり、一般的な検出率を示すものではありません。一方、決定的なルールでは拾いにくいシステム全体の相互作用を追加のレビューで見るという使い方の妥当性は示しています。

測定しなければ、複数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
• OpenAI Datadog uses Codex for system-level code review

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