こんにちは。Legalscape でエンジニアをしている kazukitash です。すでにバイブコーディングというワードが死語になりつつあるのを感じています。そして、年明け頃からハーネスエンジニアリングという新しいワードが登場してAIエージェントとの協調開発のステップが一つ進んだ感覚があります。
Michael Truell (Cursor CEO) が投稿した記事によると 2025年時点ではCursor上でTabによるコード補完を使うユーザーの方がAIエージェントを使ってコードを書くユーザーよりも2.5倍多かったのに対し、2026年2月時点ではAIエージェントを使ってコードを書くユーザーの方が2倍多くなったとのことです。もはや、AIエージェントを使ってコードを書くことが当たり前になってきているのではないでしょうか。
生産性は上がりました。実際に当社でも、AIエージェントを開発プロセスの中に組み込むことで短期的には5倍以上のコード生成量のプロダクトリリースが可能になった事例もあります。一方で、課題も生じています。 レビューのやり方が追いついていない です。
今回はAI エージェント時代のコード品質をどう設計するか、という問いに対してどう変わるべきかを整理・妄想してみたいと思います。
従来のレビューが破綻しつつある
2025年末、プロダクトのアーキテクチャ刷新を進めていたとき、AI エージェントにリファクタリングを任せたところ、1つの PR で +7,285 / -1,726行の差分が出ました。型チェックもテストも通っています。でも PR を開いた瞬間、「あれ？ これはどこから読めばいいんだ？」となりました。
これは自分たちだけの課題ではないと感じています。 ある記事では、GitHub の統計によると2026年3月時点でコミットされるコードの 51% が AI 生成または AI 支援コードであるのに対して、AI 導入が進んだチームでは PR 審査時間が 91% 増加したという話もありました。 Pair Programming vs AI Pair Programming
コードの生成速度は上がったのに、レビューは人間の認知能力に依存したままです。人間のコード作成量に最適化されたレビューのやり方が、AI エージェントによるコード生成の速度に追いつかなくなったのです。「全行を人間が読む」という前提が物理的に崩壊しつつあるのは目に見えています。でも「読まない」のは難しいですよね。だってApproveに足る信頼の根拠がありませんから。
レビューの目的を「コードを読むこと」から切り離せないのでしょうか？
ハーネスエンジニアリングという枠組み
2026年4月、Thoughtworks の Birgitta Böckeler が Martin Fowler のサイトで「Harness engineering for coding agent users」を公開しました。AI エージェント時代のコード品質をどう設計するか、という問いに対する体系的な整理です。引用をしながら、ハーネスエンジニアリングの枠組みを紹介したいと思います。
核となる定義はシンプルです。
Agent = Model + Harness
ハーネス とは、AI エージェント（モデル）以外の全てを指します。テスト、リンター、型チェッカー、ルールファイル、アーキテクチャガード——これらを設計的に組み合わせて AI の出力を制御する仕組みがハーネスエンジニアリングです。勘違いしそうになりますが、ハーネスはAI を監視する仕組みではないです。AI の出力が自動的に品質基準を満たすように、 コードベース側を設計する ことです。主題はコードベースになります。
2つの制御方式
ハーネスは2つの方向から AI を制御します。
| 方式 | タイミング | 役割 | 例 |
|---|---|---|---|
| フィードフォワード（予防的） | コード生成の前 | AI の行動を事前にガイドする | ルールファイル、アーキテクチャドキュメント、成功例のテンプレート |
| フィードバック（矯正的） | コード生成の後 | AI の出力を検知し修正させる | テスト失敗 → 再生成、リンター警告 → 修正 |
著者の Böckeler は2つの制御方式について以下のようなコメントをしています。
"Feedback-only produces an agent that repeats mistakes; feedforward-only encodes rules but never validates their effectiveness"
フィードバックだけでは同じ間違いを繰り返す。フィードフォワードだけではルールが本当に効いているか検証できない。両者の統合が必要です。ただし、フィードフォワードの必要性を示すのは、正直難しいです。フィードバックの効果はテストの失敗率やリトライ回数で定量化できます。一方、フィードフォワードの効果は定量的には出ないので測りにくいです。AIの性能も日々変わっているうえ、「ルールファイルがあったから AI が最初から正しい方向に書けた」ことは、起きなかった失敗を数えなければいけないからです。
コンピュテーショナルとインフェレンシャル
もう1つの軸は、ハーネスの実行方式です。
| 種別 | 特徴 | 例 |
|---|---|---|
| コンピュテーショナル | 確定的・高速・低コスト | テスト、リンター、型チェッカー |
| インフェレンシャル | 非確定的・セマンティック理解が可能・高コスト | AI コードレビュー、セマンティック分析 |
コンピュテーショナルなハーネスは全ての変更に対して毎回実行できます。インフェレンシャルなハーネスはコストが高いぶん、機械的処理では難しい「意味的な判断」ができます。人間に近い部分はインフェレンシャルなAI駆動の処理を実行しつつ、可能な限りコストの低い再現性の高いコンピュテーショナルな実行方式に落とし込んでいくのが理想になってきます。
レビューはどう変わるか
ここまでハーネスエンジニアリングの枠組みの紹介をしてきましたが、では実際のレビューはどう変わるのでしょうか。以下のようにレビューの責任分担が整理できると思います。
| 番号 | レイヤー | 担い手 | 根拠 |
|---|---|---|---|
| 1 | フォーマット・構文 | 自動ツール | 議論の余地なし |
| 2 | 型安全性・lint 違反 | 自動ツール | コンピュテーショナルに検証可能 |
| 3 | バグ・セキュリティ | AI レビュー + 自動テスト | インフェレンシャルだが自動化可能 |
| 4 | アーキテクチャ適合 | 人間 + ハーネス支援 | ハーネスがガードレールを敷き、人間が判断 |
| 5 | 要件・ビジネス判断 | 人間 | 文脈依存。自動化困難 |
数字の低いレイヤーほど自動化しやすく、高いレイヤーほど人間の判断が必要です。今までの開発では3より高いレイヤーは人間が行なっていました（自動テスト除く）。ハーネスを厚くすることで、 人間がレビューすべき範囲をさらに高いレイヤーに集中させる ことができると考えています。
「コードを読む」から「ハーネスを育てる」へ
従来のレビューは、レビュアーがコードを読んで問題を指摘する行為でした。ハーネスが厚い環境では、多くの問題は自動で検出されるので、レビュアーの仕事は 仕組みが捕捉できない領域に集中すること に変わります。例えば、ビジネスの成長に合わせてシステムがどのように進化するべきかなどはAIには判断が難しい領域です。ある記事でも AI は周囲のコードパターンを模倣するため、レビューは「コードの正しさを確認する場」から「コードベースがどのように成長してほしいか、生成されるコードの分布を編集する場」に変わりつつあるという話をしているものがあります。人間のコードレビューに残された仕事は、どんな未来に進みたいかを編集すること
AI レビューがレビューをどう助けるべきか
ここまではコードベース側の設計 - ハーネスエンジニアリング - の話でした。もう1つ、レビュー体験を変えうるのが AI レビューエージェント自体の進化です。
現状の多くの AI レビューツールは「差分に対してコメントを列挙する」方式です。CodeRabbit のようなツールは便利ですが、指摘が多すぎてノイズになることがあります。AI レビューがオオカミ少年になってしまうと、誰も読まない意味のないものになってしまいます。
Devin Review は、この問題に対して面白いUXを提供してくれていると思います。指摘を列挙するのではなく、PR の差分を 論理的にグループ化・並べ替え て提示しているのです。
- GitHub のアルファベット順ファイル表示ではなく、関連する変更をまとめる
- コードの移動・コピーを検出し、無意味な差分表示を抑制する
- レビュアーが「上から順に読めば理解できる」ように差分を構造化する
AI エージェントはこのように「問題を見つける」だけではなく 「理解を助けてくれる」 ようになっていって欲しいです。 Approve の根拠を説明してくれるような AI レビューエージェントが出てきたら、レビュアーは「信頼できる根拠があるから approve する」という判断ができるようになると思います。現状の AI レビューは「ここがダメ」を伝えるものになっていますが、本当に欲しいのは「ここは大丈夫、なぜなら〜」を伝えるものではないでしょうか。
- この PR はアーキテクチャに適合している（型チェック・依存方向の検証結果）
- テストカバレッジはこの範囲をカバーしている（フィードバックゲートの通過結果）
- フィードフォワードのルールに従って生成されている（ルール適合の確認）
- 人間が判断すべき点はここ（要件適合性・ビジネス判断）
上記のようなハーネスの検証結果を統合した判断材料を使い、approve する根拠を適切に順序立てて説明する。それができれば、レビュアーは「信頼できる根拠があるから approve する」という判断ができます。ハーネスの検証結果を人間が読める形に翻訳する - それが AI レビューエージェントの次の役割ではないかと考えています。
おわりに
ハーネスエンジニアリングの発想で「コードベース側を設計する」ことと、AI レビューエージェントが「approve の根拠を構造化して伝える」ことは、同じ方向を向いています。どちらも、人間がコード行を1行ずつ読むことから解放し、 判断に集中できるようにする 取り組みです。
レビューの仕事は「指摘」から「信頼の設計」へ変わりつつあると思います。コードの正しさは仕組みが担保し、人間は方向性を判断する。そのために必要なのは、ハーネスを育てることと、AI レビューエージェントが「なぜこのコードを信頼できるか」を説明できるようになること。
Legalscape ではこの方向で実践を進めています。まだ途中ですが、レビューの体験は変わってきました。
Legalscape では、この記事で紹介したような最新の技術動向を継続的に追いかけ、実際のプロダクトに取り入れる試みを続けています。AI エージェントとの協働を楽しめるエンジニアと一緒に働きたいと考えています。もしこの記事を読んで興味を持っていただけたなら、ぜひ Legalscape で一緒に挑戦してみませんか。
