

Atsushi Nakatsugawa
June 04, 2026
2 min read
What is harness engineering for AI code review & oversightの意訳です。
AIが生成するコードは、レビューを追い越しつつあります。ハーネスエンジニアリングは、AIコーディングエージェントが本番環境で安全かつ一貫して動けるよう、モデルの周囲にシステムを構築する設計領域です。ファイルシステム、サンドボックス、厳選されたツール、コンテキストエンジニアリング、計画と検証、そしてメモリが含まれます。多くのチームはこのシステムの大部分を作り込んでいます。しかし検証の作り込みについてはばらつきが大きく、その出来栄えこそが、他のすべてが機能するかどうかを左右します。
完全なハーネスは4つのリングにまたがります。多くの本番ハーネスは、そのほとんどを備えています。検証は、その中で最も注意を払われにくい部分です。
この記事では、4つのリングを整理し、お客様の導入事例で繰り返し見られるコード検証の問題を取り上げ、その埋め方を解説します。
モデルよりハーネスが重要なのは、モデルが単独では機能しないからです。シニアエンジニアも、コードを書くときに孤立して作業しているわけではありません。ファイルシステムやシェル、テスト、Linter、そしてコードベース全体の構造を頭の中で把握しておくためのワーキングメモリが揃っています。これらのうちどれか1つでも取り上げれば、本人のスキルは変わらないままでも、アウトプットの品質は下がります。
AIエージェントにも同じことが当てはまります。より優れたモデルを選んでも、得られる改善はわずかです。手元のモデルの周囲に、より良いハーネスを組み上げれば、桁違いの改善が得られます。
同じタスクに対して、3種類のレビュー構成を比べてみましょう。差分のみのハーネスは変更された行しか見ないため、ファイル間のコンテキストに依存するバグを見逃します。全コードを読むハーネスはコードベース全体を読み込み、より多くのバグを見つけますが、トークン消費は10倍になります。
対象を絞ったハーネスは、適切なファイルを選び、適切なツールを実行し、正しい答えを得ます。差分のみ・全コード方式のどちらに対しても、精度で上回りながら、消費トークンはわずかで済みます。
同じモデル、同じタスクでも、ハーネスが結果を変えるのです。
検証は、エージェントが誤った変更を下流へ流す前に補足するためのハーネス層です。お客様の導入で最も弱点になりやすい部分であり、リリースできるかどうかを左右する層でもあります。
監視が壊れるのは、コード生成のスピードが上がる一方で、検証が追いつかないときです。Salesforceでは、エンジニアリングチームがAIコーディングツールを採用したところ、コード量がおよそ30%増加しました。プルリクエスト(PR)は日常的に20ファイル・1,000行を超えるようになりました。最大規模のPRに対するレビュー時間は横ばい、あるいは減少しており、レビュアーが以前と同じ時間で、はるかに大きな変更を扱っていることを意味します。差分に対して、もはや意味のある向き合い方ができなくなっていたのです。
この問題は、調査データとプラットフォーム上のデータの両方で見られます。49,000人以上が回答したStack Overflow 2025 Developer Surveyでは、開発者の84%がAIツールを使っているか、使う予定だと回答し、プロの開発者の51%が毎日使っています。それでも46%はAIツールの精度を信頼しておらず、信頼していると答えたのはわずか33%でした。2025年のDevOps Research and Assessment(DORA)のレポートも同様に、AIの導入によってスループットとプロダクト性能は向上したものの、デリバリーの安定性は下がったことを示しています。AIはパイプラインを加速しますが、その不安定さは下流に現れます。
OpenAIのCodexチームは、2025年12月にこのコード検証の問題を明確に名指ししました。自律的なコーディングシステムが普及するにつれて、コード量は人間が丁寧にレビューできる範囲を追い越し、そのギャップは深刻なバグやセキュリティホールのリスクを高めていきます。
CodeRabbitのState of AI vs. Human Code Generation reportは、この問題に具体的な数字を当てはめています。470件のPRを対象にした分析では、AIが共同で執筆した変更はPRあたり平均10.83件の問題を抱えていたのに対し、人間のみのコードでは平均6.45件でした。セキュリティ問題はAIのPRで1.57倍、クロスサイトスクリプティング(XSS)の問題は2.74倍の頻度で発生していました。AIは多くのコードを生み出しますが、その分、丁寧なレビューを必要とするコードも増えるということです。
ハーネスに検証層がないときに見られる失敗パターンは、2つあります。
1つ目は、量による失敗です。レビュアーは、まともに向き合えない大きなAI製のPRを、ろくに見ずに通してしまいます。Salesforceのレビュアーがまさにこのパターンでした。
2つ目は、スケールに伴う正しさの失敗です。AIエージェントは人間と同じ種類のバグを出しますが、はるかに大きな量で発生させます。
あるAIエージェントは、誰からの指示もないまま本番データベースに対して破壊的な操作を実行してしまいました。別のケースでは、Claude Codeのエージェントが稼働中の本番環境で破壊的なインフラコマンドを実行し、DataTalks.Clubの2年半分の学生提出データを消去しています。どちらの事例でも、チームはあらかじめガードレールを組み込んでおくのではなく、失敗が起きた後で追加していました。ハーネスは検証が動いている前提に立っていたものの、現場では動いていなかったのです。
ハーネスは、コンピューター、コンテキスト、オーケストレーション、学習という4つのリングで構成され、検証は中央の2つのリングに分散して配置されます。コンポーネントをフラットに並べたリストよりも、この構造のほうが整理して考えやすくなります。
エージェントの作業環境を担うリングです。ファイルシステム、シェル、サンドボックス、そして厳選されたツール群を含みます。100個ではなく、十数個のツールにとどめます。ツールを定義するたびにトークンを消費しますし、機能が重なるツールはモデルを混乱させます。
エージェントが目の前の変更について何を知っているかを扱う領域です。まずメタデータをエージェントに見せ、詳細はエージェントが要求したときだけ読み込ませます。長いツール出力は、コンテキストウィンドウに押し戻すのではなく、ディスクに書き出します。本番運用で気にすべきコスト指標は、プロンプトキャッシュのヒット率です。プロンプトの安定した部分がキャッシュに乗らないと、長時間動くエージェントの実行は、スケールさせるには高コストすぎるものになります。
エージェントの作業を、ターンをまたいで一貫した状態に保つための仕組みです。サブエージェントが並列の作業を分担します。計画と検証のループはタスクを分解し、ステップごとにテストを走らせます。フックは、マージ前に決定的なチェックを発火させます。
検証が宿るのは、ここです。エージェントはアクションを計画し、その結果を確認してから次へ進みます。PR提出時にしか検証しないと、エージェントが問題を持ち込んでから20ステップも後で初めて気づくことになります。
ハーネスが時間とともに鋭くなっていくための仕組みです。エージェントが起動のたびに読み込み、学習に応じて編集していくメモリファイル。過去の実行を振り返り、うまく機能した内容を、再利用可能なスキル・プロンプト・メモリとして抽出する作業もここに含まれます。
このスタックを運用しているなら、あなたの仕事は各リングがきちんと発火するように整えることです。本番環境で生じるギャップの多くは、オーケストレーションリングに潜んでいます。
チームが検証の課題を埋める方法は、人間のレビューに入る前に、基準が自動で走るようにすることです。freeeは、AIコーディングエージェントを使うエンジニアが、人間のレビュアーがさばける量を超えてPRを生み出すようになったときに、この必要性を痛感しました。

直近6か月で、このチームは自分たちの慣習をCodeRabbitに記述し、同じチェックがすべてのPRで自動的に走るようにすることで、レビュアーの時間を32.8週間分削減しました。出力がレビューよりも速くスケールしてしまうと、検証がボトルネックになります。解決策は、基準そのものに動いてもらうことです。

TaskrabbitのSenior Engineering ManagerであるKiran Kanagasekar氏は、多くのチームより先にこの順序に気づいていました。「コードを速く書くこと自体が問題だったことは一度もなく、ボトルネックは常にコードレビューでした」。Taskrabbitは、AIコーディングエージェントを採用する前にレビューの回転を整え、マージまでの時間を25%短縮しました。検証層が先に整っていたからこそ、ハーネスの残りの部分にも、コードを流す土台ができていたのです。
最初に走るのは、決定的なルールです。.semgrep.ymlで定義し、CIで実行するSemgrepのカスタムルールは、人間が差分を見る前に、既知のアンチパターンを捕まえます。ルール自体は人間が書き、AIは、そのルールが検出した違反の修正を手伝います。
ポリシーゲートは、決定的なルールでは捕まえきれない、インフラレベルの抜け穴を塞ぎます。OPAのドキュメントにあるとおり、Open Policy Agent(OPA)とConftestを組み合わせると、インフラの設定をJSONとして読み込み、Regoで書いたポリシーと突き合わせ、ルールに違反するマージをブロックできます。
AIコードレビューは、パターンマッチングでは届かない、文脈に依存する問題を捕まえます。CodeRabbitのState of AIレポートでは、AIのPRではロジックと正しさに関する問題が75%多く、AIが生成したコード全体では、人間のみのコードに比べて約1.7倍の不具合が混入していることが分かりました。静的解析では、その大半を見つけられません。ビジネスロジックのエラー、ファイルをまたいだ依存関係の違反、6か月前にチームで合意したばかりの規約などです。AIレビューは、コードベース、リンクされたチケット、そしてチームのこれまでの判断に照らして、変更を読み解きます。
二重面スキャンは、IDEプラグインが見逃すものを捕まえます。AIエージェントは、IDEの外でコードを書き、そのままバージョン管理へプッシュすることがよくあります。ガードレールがIDE内でしか動かないと、こうしたコミットはすり抜けてしまいます。IDEとCIパイプラインの両方で、同じルールセットを使ってスキャンしましょう。
人間のレビューは、最後に走ります。最初の3つの層がすでに処理した大量の問題から解放され、設計やアーキテクチャ上の判断に集中できます。ImprintのCTOであり『An Elegant Puzzle』の著者でもあるWill Larson氏は、端的にこう述べています。レビューの中心にいるのは依然として人間であり、エージェントはあくまでそれを支援する存在です。レビューは学習のループでもあり、その学習自体に価値があります。ハーネスは、このループを置き換えるためにではなく、引き締めて保つためにあります。
各層は、次の層がカバーすべき範囲を狭めていきます。決定的なルールが明らかな問題を、ポリシーゲートが構造的な問題を、AIレビューが文脈的な問題を、そして人間が戦略的な問題を引き受けます。
これが、検証層がフルカバレッジで動いている状態です。
CodeRabbitは、エージェント型SDLCにおける検証層です。コードベース、リンクされたチケット、そしてチームのこれまでの判断と照らし合わせながら、変更を読み解きます。さらに、サンドボックス化されたレビューパイプラインの中で、40を超える組み込み済みのリンターと静的アプリケーションセキュリティテスト(SAST)ツールを実行します。Pre-Merge Checksは、すべてのPRで「計画と検証」を強制します。Learningsとパスベースのルールはチームの慣習をコード化するため、コードベースが大きくなっても基準が形骸化しません。
MastraのCTOであるAbhi Aiyer氏は、そのループがもたらす結果をシンプルに表現しています。「完全自律のコーディングループを経た後で信頼できるツールは、CodeRabbitだけだ」。

Abnormal AIの事例は、この形が現場でどう機能するかを示しています。CodeRabbitは、Abnormalの社内Markdownポリシーファイルを自動的に取り込みます。Abnormal側で、それに加えてCodeRabbit専用の設定を保守する必要はありません。直近30日間で、Abnormalはクリティカル重要度のコメントで65%の受け入れ率を達成し、レビュアーの時間を100時間以上節約しました。
AIが生成したコードをリリースしているEMやVPで、レビュー待ちの列がチームの増員より速いペースで伸びているなら、その問題はモデルではなく、ハーネスにあります。4つのリングを点検してみてください。コンピューターリングは、たいてい問題ありません。コンテキストリングと学習リングも改善が進んでいます。多くのチームが意外な発見をするのは、オーケストレーションリングです。動いているつもりだった検証層が、よく見ればCIとレビュアーの善意で何とか持ちこたえているだけだった、ということがよくあります。
検証の課題を1つ選び、今四半期のうちに埋めてください。まだないなら、CIに決定的なルールを導入する。インフラ変更にポリシーゲートを置く。人間の目が入る前に、すべてのPRをAIレビューに通す、といった具合です。
監視を失うことなく、AIのスピードでリリースし続けているチームは、最初から検証を前提に設計されたハーネスを組んでいます。より良いモデルを選ぶ話は、その後で来ます。
ハーネスに検証を組み込む準備はできていますか。今すぐ、CodeRabbitの14日間無料トライアルを始めてみてください。