この記事は、ツールからではなく非対称性から話を始める。著者のチームがおよそ 6 か月前に Cursor、Claude Code、Codex を導入したあと、コミット数はおよそ 2 倍になった——しかし記事が言うように、エンジニアがレビューに費やす時間をそれに見合うだけ 2 倍にするのは難しい。放置すれば、その差はコード品質の低下となって表れる。そのため レビューのボトルネック が、エージェントがもたらすはずだった生産性を縛る制約になる。
記事が論じるのは、答えはより懸命にレビューすることではなく、冒頭で示される 2 つの狙いを軸にフローを再設計することだ、という点である。1 つは、プルリクエストの品質をレビューに届く前に高めて人間がすべきことを減らすこと、もう 1 つは、レビューそのものを速くすることである。責任の分担自体は固定されたままである——著者は、レビュイー（適切に実装し、自分のコードを説明でき、その品質を保証する）とレビュアー（マージの基準が満たされていることを保証し、承認か却下かを決める）の区分は、AI 時代でも以前と同じだと述べている。
記事で説明される施策は具体的で、大部分は構造的なものである。AI がまだ知らないことだけを載せるように書かれた統一的なモノレポのガイドライン、テスティング・スカイスクレイパー という名前で採用したテスト戦略（その下でバックエンドチームのテストコードと本番コードの行数比は 100% を超えた）、定型的なエージェント作業のための標準化されたスキルとスラッシュコマンド、並行して動く 3 つの AI レビューツール、そして記事が説明する施策の最後として、最終ゲートを人間から AI に移すことである。
要点
- 枠組みとなる主張：レビューの負荷こそ、エージェント駆動による生産性向上が失われる場所である。実装の速度はエージェントとともにスケールするが、人間のレビュー能力はスケールせず、しかも AI が生成したコードは人間にとって欠陥を見つけにくいからである。
- ガイドラインについての記事のルールは、チーム固有のことだけを書くというものである。AI はすでに一般的な知識を持っているので、ガイドラインにはチームの規約、選択したアプローチ、ビジネスドメインの知識を載せるべきだとする。記事が示す対比では、「エラーを適切に処理する」は一般的すぎて書く価値がない一方、DynamoDB の操作に
ConditionExpressionと楽観的ロックを必須とするルールや、コンテキストからユーザー ID を直接読むのではなくauth.GetUserID()を使うよう求めるルールはそうではない。 - モノレポでは、共通のガイドラインを
docs/guidelines/に、領域ごとのガイドラインを{backend|frontend|native}/docs/guidelines/以下に置き、それらを信頼できる唯一の情報源として扱う。エージェントによってガイダンスの読み込み方が異なるため、各エージェント自身の設定はそれらのファイルを繰り返し書くのではなく参照する。 - チームは通常のテストピラミッドの比率（ユニット 70〜80%、インテグレーション 15〜25%、E2E 5〜15%）を脇に置き、どの層も良いものであり、必要なところではどれを多く書いてもよいという立場をとった。変化の速い時代には、インテグレーションと E2E のカバレッジは減らすのではなく増やす必要があるという論拠による。バックエンドチームのテストコードと本番コードの行数比は、2025 年 6 月の 78.6% から 9 月には 95.2%、12 月までに 112.6% へ上昇したと報告されている。
- テストを増やすことへの保守面の反論は大部分が解消したと記事は論じる。コードを変更したらテストも更新するようエージェントに指示するガイドラインがあれば、エージェントがほとんどそれを行うからである。実行時間の反論は解消しておらず、チームの答えはスケジューリングである——GitHub Merge Queue により、PR 作成時には軽量なテストだけを実行し、重い E2E の実行はレビュー承認後まで遅らせる。
- 定型的なエージェント作業は 4 つのスキル——
creating-pull-requests、fixing-ci-failures、handling-review-comments、reviewing-pull-requests——に標準化されている。記事によれば、執筆時点では Cursor にスキル機能がなかったため、これらはスキルとスラッシュコマンドの両方として提供されている。 - 3 つの AI レビュアー（GitHub Copilot、Greptile、Claude Code Action）が同時に動いており、記事はこれを意図的なものとして擁護している。分野が過渡期にあるため、当面は複数のモデルに異なる角度から見てほしいとし、いずれ評価を行ってどのサービスを残すかを選ぶかもしれないと述べている。著者の説明では、チームのフィードバックは Greptile と Claude Code Action を高く評価しており、著者自身は、レビューコメントから学習してカスタムルールを自動生成できる点で Greptile を好んでいる。
- カスタムの Claude Code Action によるレビューフローは、関心ごとにサブエージェントを用いる 4 つのフェーズに分かれている。PR のメタデータと適用されるガイドラインの収集、それに照らした観点ごとのレビュー、各 AI コメントが妥当で捏造されていないかを判定する重大度評価サブエージェント、そして重大度の高い指摘だけをインラインコメントし、他のエージェントがすでに述べたことの重複を避ける投稿フェーズである。
- 記事は、このようにフローをカスタマイズすることで、単にガイドラインを渡してレビューを頼むよりも明らかに良いレビュー品質が得られたと報告している——ただしこれはチーム自身の経験からの評価であり、測定値は示されていない。
- AI を最終ゲートにすることについて、述べられている動機は、人間が介在するプロセスには見落としや運用ミスの可能性が避けがたく伴うということである。その結果——レビュアーとレビュイーが今では自信を持ってマージできる——についての説明も同様に、測定された成果ではなく著者自身の判断である。
背景
これは 1 社のエンジニアリングブログの記事で、CyberAgent のハノイ開発センターのバックエンドエンジニアが 2025 年のアドベントカレンダー向けに書いたものであり、一般的な指針というよりは 1 つのチームの内側からの報告として読める。記事は冒頭で、CyberAgent が AI エージェントの費用としてエンジニア 1 人あたり 200 ドルの全社的な支援を展開したこと、そして著者のチームが執筆のおよそ 6 か月前に Cursor、Claude Code、Codex を導入したことに触れている。
その証拠としての性格は、念頭に置いておく価値があるほどに不均一である。テスト比率の数値とコミット数の倍増はチーム自身の測定値である一方、3 つのレビューツールの比較評価、カスタマイズしたフローのほうがうまくレビューできるという主張、そして最終ゲートキーパーとしての AI についての評価は、チームの印象として述べられている。著者は、これらすべてを結論ではなく一つの段階として位置づけて締めくくっており、技術の変化に合わせてフローを見直し続けると述べている。