AIの速さに惑わされない──AIエージェント時代のレビュー設計

投稿日時：2026/01/27 08:30

株式会社primeNumber / Head of CTO Office

中根直孝

多様な開発組織のコード／PRレビューを“図鑑”のように紹介する連載「コードレビュー図鑑」。今回は、株式会社primeNumberの中根さんに、AIにほぼ全ての実装を任せる一人開発の現場で試行錯誤してきたレビュー設計の考え方を伺いました。AIの速さに流されず、品質とスピードを両立するための具体的な工夫を紹介いただいています。

はじめに

はじめまして。株式会社primeNumberでソフトウェアエンジニアをしている中根（@gtnao）と申します。2025年8月より、primeBusinessAgentという新規プロダクトの開発に取り組んでいます。

新規開発ということもあり、エンジニアは現時点で私一人。そしてコードのほぼ100%をAIエージェント（Claude Code）に書かせています。一般的なチーム開発における「人間同士のレビュー」は発生しませんが、「AIが書いたコードを採用するかどうか」という判断は常に発生します。一人開発だからこそ、この判断プロセスを意識的に設計しなければ、誰もチェックしないままコードがプロダクションに乗ってしまいます。

本記事では、AIエージェントとの協業における新しい形のコードレビューについて、試行錯誤してきた考え方を共有します。新規プロダクトを少人数でAIと立ち上げるというシチュエーションは今後増えていくはずで、そういった方々の何かしらの参考になれば幸いです。

レビューのボトルネック化が加速する時代

Claude CodeをはじめとするAIエージェントの台頭で、設計からPull Request（PR）作成（一通りの実装）までを一気通貫でAIが仕上げてくれることも珍しくなくなりました。これをレビューする行為自体は、人間がPRを上げてきた場合と本質的には変わりません。しかし、スピードの非対称性という決定的な違いがあります。

コーディングはAIが行い、レビューは人間が行う。この間には圧倒的な速度差が存在し、レビューがボトルネックになるという問題が以前より顕著に認識されるようになったのが2025年でした。AIの進歩は目覚ましく、レビュー自体もAIがよしなにやってくれないかとつい期待してしまいますが、実プロダクトで人間による確認を一切なくすことはまだハードルが高いでしょう。

では、どうすればいいのか。いくつかの段階に分けて整理してみます。

リアルタイムレビュー（ペアプロ型）

まず考えられるアプローチは、私たちがAIエージェントを初めて触ったときから自然と行っていた方法です。AIが出力したコードを逐一確認し、取り込むか取り込まないかを承認するという極めてシンプルなものです。これは、AIと人間によるペアプログラミングと解釈できます。

従来の人間同士のペアプロには、教育的観点に加えて「実装の方向性をリアルタイムでレビューできる」という利点がありました。これにより、最終的なPRレビューの段階での大きな指摘事項が減り、手戻りを防ぐことができました。AIと人間によるペアプロでは、すべてのコードを見て承認しているわけですから、一連の実装が済んだタイミングで、極論、すべてのレビューが完了していると言えます。ただしこのやり方では、AIがコーディングしている間ずっと張り付いている必要があり、「もっとAIに一気に任せてしまいたい」という心理が働いてくるかもしれません。実際、auto approve的なモードにして、実装がひと段落したものをまとめてレビューするという方式を取っている方も多いでしょう。

一方で、PRあたりの粒度が大きくなると、全体像の把握に時間を要し、手戻り発生時のコストも膨らみます。任せたい気持ちを抑え、あえて確認頻度を上げる方が結果的に早くなることもある点は、意識しておきたいポイントです。

AIの出力を安定させる

前述のアプローチでも、従来に比べれば飛躍的な効率化が実現できているはずです。ただし、AIは何も対策しないと毎回記憶がリセットされるため、何度も同じ指摘を繰り返すことになる、といった課題が生まれます。これを補うためのアプローチがいくつか考えられます。

AIに守ってほしいルールを自然言語でまとめる
Linterなどで静的にチェックする
実装パターンを統一する

自然言語でルールをまとめる

繰り返しAIに指摘している事柄が出てきたら、手っ取り早い方法として、守ってほしいルールを自然言語でまとめることが考えられます。自然な発想ですが、典型的な課題が2つあります。

ドキュメントが古くなりがち
AIが読んでくれる・守ってくれる保証がない

前者については根本的な解決は難しいですが、せめて更新しやすい状態を保つため、本プロジェクトではルートにdocsディレクトリを設け、そこに情報を集約するよう心がけています。後者については、多くの開発者やエージェント提供企業が注力しているトピックです。

Claude Codeを例に挙げると、CLAUDE.mdは起動時に必ずコンテキストに読み込まれます。しかし、すべての情報をCLAUDE.mdに書くとコンテキストを圧迫してしまいます。そこで最近は、必要な情報をダイナミックに読み込ませるアプローチが主流になりつつあります。Claude CodeのSkillsも、利用ケースと参照先だけをコンテキストに載せ、詳細は必要時に読み込ませる仕組みです。こうした機能やテクニックは日々生まれており、柔軟に対応できるよう、本プロジェクトではCLAUDE.mdをdocsから自動生成したり、.claude内からシンボリックリンクを貼ったりして、docsディレクトリをSingle Source of Truthにしています。

本プロジェクトでの具体例を紹介します。docs/配下の各ディレクトリに_index.yamlを配置し、そのディレクトリ内のドキュメントへのパスと「いつ参照すべきか」を記載しています。そして、スクリプトがこれらの_index.yamlをマージし、CLAUDE.mdを自動生成します。

# docs/coding-standards/_index.yaml
- path: docs/coding-standards/prisma.md
  description: DBスキーマを変更するとき
- path: docs/coding-standards/jobs.md
  description: バックグラウンドジョブを追加するとき

CLAUDE.mdには「最初に必ず読むべき最小限のルール」と「ドキュメントリンク集」だけが含まれ、詳細は必要に応じてリンク先を読ませる構成です。これにより、初回のコンテキスト消費を抑えつつ、情報へのアクセスは担保できます。

# CLAUDE.md

## 致命的な禁止事項
（最小限のルール）

---

## 参考ドキュメント

- path: docs/coding-standards/prisma.md
  description: DBスキーマを変更するとき
...

さらに、Claude Codeのhook機能を活用し、_index.yamlを編集するとCLAUDE.mdが自動で再生成されます。また、コミット時にはlefthookで_index.yamlに漏れがないかチェックし、ドキュメントを追加したのに_index.yamlを更新し忘れるミスを防いでいます。最適解かは分かりませんが、ドキュメントを足すたびに、手間なく自動的にAIが参照できる情報も増える仕組みなので採用しています。

静的にチェックする

自然言語で書かれたルールには、どうしても曖昧さがあり、AIが処理するにも時間がかかるという欠点があります。Linterなどで静的に確認・修正できる事柄であれば、できる限りそちらに寄せていくのは真っ当なアプローチです。既存プラグインでカバーできる部分は良いのですが、カスタムルールを作ってしまうのも有効です。従来であればLintツールのキャッチアップが必要でしたが、今やAIが一瞬で望み通りのルールを実装してくれます。プロダクションコードではない周辺ツールだからこそ、Vibe Coding的に気軽に拡充できます。

具体例を挙げると、レイヤー間の依存関係を制限するルールです。例えば、DBアクセス用の関数は特定のディレクトリからのみ呼び出せる、といった制約を静的にチェックしています。もちろん、静的に表現できるルールには限界があるため、前述の自然言語ドキュメントとの併用が必要となります。

実装パターンの統一

最後に、少し毛色の違うアプローチとして、プロジェクト内の実装パターンをできる限り統一することが挙げられます。人間がコーディングする場合と異なり、AIは参考実装がなくても仕様・要件さえあれば強引にでも実装できてしまいます。しかし、周囲のコードを一切参考にさせずに実装させると、類似の機能でも千差万別な実装パターンが生まれてしまいます。これはいくつかの点で問題を生みます。まず、人間がレビューする際に、毎回まったく新しい実装を理解しなければならない点です。もし既存の類似実装を参考にしていれば、差分だけに注目して「今回の要件固有の部分が正しく反映されているか」という視点でチェックすれば済みます。レビュアーの認知負荷は大幅に減るでしょう。また、実装パターンの乖離は、一度発生すると次の実装がさらにバラつく悪循環に陥ります。統一性を意識的に保つ努力が求められます。

適切な粒度で作業を分解する

さて、AIの出力を望む形に（＝指摘が発生しにくいように）安定させていけると、逐一コード変更を承認するペアプロ型アプローチよりも、もう少し大きな粒度の作業をAIに任せられるようになるかもしれません。

ここで1つ、個人的に感じていることがあります。我々はAIの青天井な能力に圧倒され、その力を極限まで引き出したいと思うあまり、一度に任せる作業単位がつい大きくなりすぎているケースが多いのではないか、という疑問です。人間同士であれば、「差分が多すぎるのでもう少し細かい粒度でPRを分割してくれませんか」とお願いするような規模でも、AIは強引にでも一気に作業を進めることができます。巨大なFeatureを完璧に設計したつもりのドキュメントを渡せば、AIが数十分で最後まで仕上げてくる。この体験には、今まで味わったことのない快感があり、つい繰り返したくなる誘惑があります。

しかしながら、生成されたコードをレビューしなければならないという前提があるとしたら、これは悪手です。自分が一度に認知できる単位で作業を進める。当たり前のようですが、AIの速さに流されず意識し続けたいポイントです。

レビューエージェント

世間的には、レビュー専用のAIエージェントを用意し、実装エージェントと相互に自律して動いていくようなアプローチへの期待が高まっています。2026年はこの話題がさらに活発になることが予測されます。AIのたゆみない発展を考えると、近い将来（というか現時点でも）工夫次第でかなり信頼できるアウトプットを出せるようになるでしょう。本プロジェクトでも、docsを参照させたClaude CodeのcommandsやSkillsなどを活用し、実験的にレビューエージェントを動かし始めています。

一方で、人間がどこまで確認すべきかは、プロダクトの性質、ビジネスのフェーズ、リスク許容度など、さまざまな要因によって異なります。こうした状況を踏まえ、レビューエージェントはあくまで一つの道具として、前述のアプローチと併用していくのが現実的でしょう。必要に応じて人間が適切な粒度で確認を行い、コードの質とスピードを両立させていくことが大切だと考えています。

おわりに

本記事では、人間とAIの間で発生するレビューについて、試行錯誤し結果得られた知見を共有しました。本プロジェクトでも今後開発メンバーが増える予定があり、レビューエージェントの活用や複数人でのレビュー体制をどう設計するかが次のチャレンジとなります。

ただし、人間がコードを理解し判断するという構造が残る限り、本記事で述べた考え方は有効であり続けるはずです。この記事が、同じような状況にいる方々の参考になれば幸いです。