数年前の自分に、15のソフトウェアプロジェクトを同時に本気でレビューしていると話したら、かなり非現実的だと思ったはずです。15個のリポジトリを開いて軽く眺めるという意味ではありません。実際に運用しているプロジェクトを、バグ、誤った前提、SEOの問題、翻訳ミス、ローカライズの不整合、テスト不足、回帰、そしてシステム全体と合わなくなった古いコードまで含めて継続的に確認するという意味です。
ボトルネックはタイピング速度ではありませんでした。注意力です。どのプロジェクトにも独自の歴史、規約、edge caseがあり、一見おかしく見えても意図的に残されているコードがあります。丁寧なレビューには、読む、検索する、比較する、チェックを実行する、そして最後に「本当に変えるべきか」を判断する工程が必要です。
Codexは、この反復作業のコスト構造を大きく変えました。リポジトリを最初に走査し、参照関係を追い、関連ファイルを確認し、不審なパターンを見つけ、テスト案を出し、以前なら自分で一つずつ開いて確認していた箇所の調査を手伝ってくれます。最終判断が自動化されたわけではありません。判断に至るまでの高コストな調査部分が大幅に速くなったのです。
私が一番重要だと思っているルールは単純です。Codexを使って自分をレビュー工程から外すのではなく、自分のレビュー範囲を広げる。
本当のボトルネックはコーディングではなく反復作業
1つのプロジェクトだけを保守していると、驚くほど多くの文脈を頭の中に保持できます。しかしプロジェクト数が増えると、その方法は急にスケールしなくなります。同じ種類の作業が何度も現れます。
- 複数コンポーネントに似たバグがないか探す。
- リファクタリング後に古いcall siteが残っていないか確認する。
- 挙動変更後にテストが追従しているか確認する。
- metadata、言語別設定、見出し、内部リンクの不整合を探す。
- localization keyや翻訳内容を比較する。
- エラーハンドリング不足やedge caseを探す。
- 「小さな変更」が想定以上のファイルに波及していないか確認する。
- 1つずつは単純でも、合計すると非常に時間のかかるdiffを読む。
どれも派手な作業ではありません。しかし全部重要です。同じ種類のレビューを複数のコードベースで繰り返すと、そのコストは一気に大きくなります。
私にとってAIコーディングエージェントの価値が最も大きいのはここです。探索空間の反復部分を高速に処理し、私は判断が必要な部分に注意力を残せます。
最初から「全部直して」とは頼まない
エージェントから悪い結果を得る一番簡単な方法の一つは、「プロジェクト全体をレビューして全部直して」のような巨大な指示を渡すことです。効率的に見えますが、発見、優先順位付け、アーキテクチャ判断、実装、検証を1つの制御されていないタスクに混ぜてしまいます。
私は工程を分離したほうがずっと良い結果を得られます。
inspect → explain findings → prioritize → change → validate → review diffまず、関連領域を理解して何を見つけたのか説明してほしい。具体的なファイルパス、影響するコード、なぜ問題に見えるのか、どんな影響が考えられるのかが必要です。変更を依頼するのはその後です。
これはAIが自信満々に間違えることがあるからです。不要に見えるコードが、古いブラウザ、特殊な決済ケース、移行経路、あるいは1ファイルからは分からないビジネスルールのために存在していることがあります。先に調査させることで、誤った前提が巨大なdiffになる前に止められます。
AIの指摘は「結論」ではなく「調査候補」として扱う
良いCodexレビューは「17件の問題を見つけました」で終わりません。件数自体にはほとんど意味がありません。私が欲しいのは根拠です。
実際に対応する価値のある指摘なら、次のことを知りたいです。
- 問題がどこにあるのか。
- なぜ問題なのか。
- どんな挙動が壊れる可能性があるのか。
- その結論にどの程度の確信を持つべきか。
- 何を確認すれば証明または否定できるのか。
- 最小で安全な修正は何か。
特にsecurity、SEO、ビジネスロジックでは重要です。エージェントが調べる価値のある箇所を示しても、securityっぽい説明だけで脆弱性が確定するわけではありません。SEO警告がそのまま順位問題を意味するわけでもありません。変な条件分岐が自動的にdead codeになるわけでもありません。
AIは「候補を見つけるコスト」を下げます。現実の問題かどうかを決めるのは、依然として検証です。
信頼性を作るのはvalidation loop
AI開発で目立つのはコード生成ですが、本番開発で本当に重要なのは検証です。
変更後は、コードベース側から必ずフィードバックを返してほしい。プロジェクトによっては次のような確認を使います。
- TypeScriptやその他のcompiler/type checker。
- lint。
- unit test、integration test。
- build。
- 古い名前やcall siteの検索。
- 最終diffの確認。
- ユーザーに見える挙動の手動確認。
どのコマンドを使うかより、ループ自体が重要です。エージェントが仮説を出し、リポジトリが証拠を返し、その証拠を使って次の判断をする。
そのため、私はAI支援開発では型の強いプロジェクトを特に扱いやすいと感じています。別の記事では、なぜTypeScriptとCodexの相性が本番開発で良いのかを書きました。型は多くの誤った前提を、すぐに機械が読めるエラーへ変えてくれます。
AIレビューと特に相性が良い領域
複数プロジェクトを扱う中で、特に効果を感じるレビュー領域がいくつかあります。
バグと回帰
値が複数ファイルをどう流れるか追い、callersを確認し、似た実装を比較し、分岐間の不整合を探すのはAIが得意です。症状の出どころを絞るのに役立ちます。ただし結論を採用する前に、私は実際の挙動を再現するか、別の方法で検証します。
テスト
挙動が変わったのにtest coverageが追従していない場所を探したり、edge caseを提案したり、既存テストが何を守っているのか説明させるのは非常に有効です。また、ユーザーの挙動ではなく実装詳細だけをテストしているケースも見つけやすいです。
SEO
テクニカルSEOには大量の整合性チェックがあります。metadata、言語別alternate、indexability、internal link、ページテンプレート、sitemap生成、redirect、各ページのルールなどです。エージェントなら、大きなコードベース全体でルールを比較する作業を、私が全routeを手で開くよりずっと速くできます。ただし、技術的に正しいことと、そのコンテンツが検索順位に値するかどうかは完全に別問題として扱います。
ローカライズと翻訳
多言語プロダクトでは非常に反復が多い領域です。AIはkeyの比較、欠落値の検出、明らかな言語違い、placeholderの確認、locale間の構造差の発見に向いています。巨大な翻訳オブジェクトを手作業で読むより圧倒的に速いですが、重要なコピーには人間の判断が必要です。
リファクタリング後の整合性
大規模リファクタリングは、とても地味な理由で壊れます。古いimportが1つ残る、1つのrouteだけ旧フィールド名を使う、1つのtest fixtureだけ古いshapeのまま残る。リポジトリ全体検索と、変更意図を理解したエージェントの組み合わせはこの確認にかなり強いです。
並列化は、タスクが独立しているときだけ強い
たくさんのエージェントを起動して、全部に同時に変更させるのは魅力的です。throughputは上がりますが、衝突や矛盾した前提も同じだけ増やせます。
私は並列化を「コーディング速度」ではなく「調整問題」として考えています。独立した監査は並列化しやすいです。あるプロジェクトのローカライズを確認している間に別プロジェクトのテストをレビューする、あるいは別々のrepositoryを同時に調査する、といった形です。一方、共有プランなしで2つのエージェントが同じアーキテクチャを書き換えるのは別の話です。
並列度が高くなるほど、境界が重要になります。明確なproject、明確なtask、明確なdefinition of done、そして独立してレビューできるresult。
目的は、動いているエージェント数を最大化することではありません。検証可能で有用な進捗を最大化することです。
AIに盲目的に任せない領域
AIの支援は欲しいけれど、最終権限までは渡したくない領域があります。
- アーキテクチャ判断: モデルは候補を出せますが、長期的なtrade-offはrepository外の文脈に依存することがあります。
- Security判断: 指摘には検証、threat context、場合によって専用ツールが必要です。
- ビジネスルール: コードが内部的に一貫していても、プロダクトとして間違った挙動を実装することがあります。
- 巨大な破壊的リファクタリング: diffが大きいほど理解しにくく、雑に承認しやすくなります。
- Production deployment: testが通っただけで運用リスクが消えるわけではありません。
- 最終レビュー: 自分の名前で出す前に、何が変わったのかを自分で理解したい。
これらの領域でAIが役に立たないからではありません。むしろ、もっともらしい間違いが高くつく領域だからです。
AIレビューは静的解析の代わりではない
Codexをcompiler、linter、test、scanner、monitoringの代替だとは考えていません。これらのツールにはAIにない強みがあります。狭い範囲で、決定論的で、同じ入力に対して繰り返し同じ確認ができます。
一番強いのは組み合わせです。Codexは広い文脈から「どこを見るべきか」を考えられる。静的ツールは正確なルールを強制できる。テストは挙動を検証する。ログやmonitoringは現実のシステムで何が起きているか示す。そして人間のレビューが、それらをプロダクトの意図と結びつけます。
こうしたfeedback systemがないなら、AIへの信頼は上がるどころか下がります。
最大の生産性向上は「注意力の配分」が変わること
「Codexで時間を節約できる」と言うのは簡単ですが、私にとって変化の本質はそれ以上です。
ソフトウェア開発で希少なのはキーストロークではありません。質の高い注意力です。AI coding agent以前は、その多くが反復的な探索に消えていました。同じパターンを探す、似たファイルを読む、referenceを追う、変更が全部に伝播したか確認する、そして別repositoryで同じ監査を繰り返す。
今は、そのfirst passをより多くエージェントに任せ、自分の注意力を自動化しにくい判断へ残せます。その指摘は本当に重要か。fixはアーキテクチャに合うか。UXは良くなるか。リスクは許容できるか。本当にshipしたい変更か。
だから複数プロジェクトの保守とレビューの感覚が変わりました。レビューを減らしているわけではありません。機械的な作業が全予算を使わなくなったから、むしろレビューできる範囲が広がっています。
私が信頼しているworkflow
- レビュー目的を狭く定義する。 バグ、テスト、SEO、ローカライズ、リファクタリングなど、具体的なテーマを決める。
- 編集より先に調査させる。 まず根拠と影響箇所が欲しい。
- 指摘を優先順位付けする。 理論上の問題すべてがコード変更に値するわけではない。
- 変更範囲を小さく保つ。 小さく一貫したdiffほど検証しやすい。
- 機械的なチェックを実行する。 typecheck、lint、test、build、search、その他プロジェクト固有の検証。
- diffを自分で読む。 不要な書き換え、誤った前提、見落としたedge case、scope外の変更を確認する。
- 重要な挙動を検証する。 特にユーザー、決済、security、SEO、production infrastructureに関係するもの。
- 確認が終わってから次へ進む。 並列化は便利ですが、未解決の不確実性を別タスクへ持ち越さない。
15プロジェクトが「15倍のレビュー作業」には感じなくなった
Codexが15プロジェクトを簡単にしたわけではありません。責任を消したわけでもありません。変えたのは、規模と反復作業量の関係です。
より深いfirst pass、より広い整合性確認、より多くのテスト案、より体系的なauditを、自分で全ファイルを毎回探し回らずに実行できます。その分、自分の注意力を、まだ開発者にしかできない判断へ使えます。
私にとって価値のあるAI-assisted developmentはこういう形です。autopilotでも、盲目的な信頼でも、「何かが通るまでコードを生成し続ける」ことでもありません。機械規模の探索と、人間規模の判断をより短いループで結ぶことです。
これが私にとってCodexの本当のレバレッジです。レビューをなくすのではなく、以前なら維持がずっと難しかったスケールでも、真面目なレビューを可能にしてくれます。