コンテキストエンジンが実際にもたらすもの:22のAIコードレビュアーを5つの異なる方法で実行した結果

AI Agents Context Engineering MCP Agentic Workflows

同じコードレビュータスクを22のAIエージェントに与えました。同じプルリクエスト、同じピン留めされたコミット、同じプロンプト、同じモデル — 唯一の変数は、各エージェントがプロジェクトのルールを読み込む方法でした。最も安価な設定は最も徹底的なものであることが判明し、その理由はコンテキストエンジニアリングについて何か一般的なことを示唆しています。

TL;DR: コンテキストエンジンダイジェストと機械可読ポリシーファイルの1つの直接読み込みがすべての他の戦略を上回りました:レビューあたり$1.56で検証済み発見9.6/13 — ドキュメント読み込みより安い($2.30、8.6/13)そしてダイジェストのみより良い($1.77、7.8/13)。すべてを読む(7.4/13)は最悪のスコアを得ました。すべての22のエージェントはClaude Opus 4.8で実行され、22中21は同じ判定に達しました。

何:ハーネス、コンテキストエンジン、そして1つのプルリクエスト

「ハーネス」とは何ですか?

AIエージェントが本番リポジトリで作業するための真摯な試みはすべて、ガバナンスの2つのレイヤーを成長させます。

散文レイヤー — 慣例、アーキテクチャルール、テスト標準。私たちのリポジトリではそれはCLAUDE.mddocs/**です:「バックエンドはsnake_case」、「ドメインはインフラストラクチャをインポートしない」、「すべてのルートハンドラーは非同期」。人間がそれを読みます;エージェントも読むように指示されます。

機械可読レイヤーハーネス設定。私たちのものは、リポジトリ内のすべてのパスをリスク層に分類し、各層に実行可能なゲートを付加する単一のJSONファイルです。CIがそれを読みます。マージポリシーがそれを読みます。それはアドバイスではありません — それはポリシーです:

"tier3": {
  "requiredChecks": [
    "lint", "test", "build", "review-agent",
    "harness-smoke", "manual-approval", "expanded-coverage"
  ],
  "mergePolicy": {
    "minApprovals": 2,
    "requireReviewAgent": true,
    "allowSelfMerge": false
  }
}

(用語注:「ハーネス」はまたエージェントランタイム自体にも名前を付けます — ツール、スキル、MCPサーバーのスキャフォルディング。このポストでは、ハーネス設定はそのようなランタイムとCIの両方が実行するリポジトリのポリシーファイルです。)

コードレビュアー — 人間またはエージェント — このファイルなしに「このPRはマージできるか?」を判断することはできません。review-agentチェックがスキップされたTier-3 PRは、すべてのテストが緑色であってもポリシー違反です。その例を念頭に置いてください;それが実験を決定します。

両方のレイヤーが存在するため、リポジトリは次のゲートを義務付けます:エージェントがこのコンテキストを読み込む前に作業を開始しない — そしてレビュアーがチェックする確認ブロック経由でそれを証明します。このポストが答える質問は単純です:そのゲートを満たすための最も安価な正しい方法は何ですか?

harnextとmeaninggridに会う

meaninggridharnext からのホストされたコンテキストエンジンです。QualityUnitのMITライセンス、プロバイダに依存しないコーディングエージェントハーネス(6つのツール — read、write、edit、bash、skill、mcp — npm i -g harnext)。ベンダーのコンテキストエンジンのピッチは率直です:「あなたのエージェントの脳」。ソースは継続的に更新されたインデックスにストリーミングされます — 「グリッド」 — そしてクエリあたり、エンジンはそれを*「ランク付けして、トークン効率的なコンテキストにプルーニングし、ハーネスに直接配線」*します:継続的なインデックス、関連性ランキング、重複排除とキャッシュ。harnextのヘッドラインの数字は平均でクエリあたり−89%トークンです。それはベンダーの主張です;この実験の1つの目的は、実際のタスクで独自の数字を使用して、そのような圧縮が実際に何を節約するのか — そしてそれが何を費やすのか — を測定することでした。

私たちの展開では、グリッドはリポジトリの散文ドキュメントを取り込みます;各取り込みは不変でバージョン管理されたスナップショットを生成します。エージェントはMCP(meaninggrid.harnext.dev/mcp)を通じてそれをクエリし、単一のcontext_research呼び出しを行い、snapshot_idでスタンプされた合成された、引用されたダイジェストを受け取ります。これをエージェントは確認ブロックで引用する必要があります — 監査可能なコンテキストが具体化されました。

コンテキストエンジンパイプライン:散文ドキュメントが取り込みを通じて流れ、バージョン管理されたスナップショットとコンテキストリサーチをエージェントに流し、機械可読ポリシーファイルは直接読み込まれます

ゲートが生成するもの — 確認ブロック(例;プロジェクト固有の詳細は省略):

読み込み方法:最適化されたハイブリッド(コンテキストエンジンダイジェスト+ポリシーファイルのみ)。

- context_research呼び出し#1(慣例/レイヤー/テスト/セキュリティ/
  リスク層)-> snapshot_id 9483af61cf8a40a2a0d790c7047fcf08
- context_research呼び出し#2(LLMプロバイダ統合チェックリスト+
  フローエンジン特別注意ルール)-> snapshot_id 9483af61cf8a40a2a0d790c7047fcf08
- ディスクからハーネス設定を読み込む(完全):正確なティアパターン、
  requiredChecks、mergePolicy、evidenceConfig。
  CLAUDE.mdまたはdocs/*は読み込みませんでした(ダイジェストでカバーされています)。

snapshot_idは実際です — レビュアーはエージェントが作業したルールの正確なバージョンを検証できます。

3つの仮説

実験は、事前に書き留められた3つのテスト可能な予測を解決するために設計されました:

H1 — ダイジェストは再読より安い。 散文ドキュメントを一度取り込み、すべてのエージェントにコンパクトな合成ダイジェストを提供します — すべてのエージェントが毎回すべてのドキュメントを再読することの代わりに。真の場合: レビューあたりの意味のあるコスト削減、等しい判定で。

H2 — 言い換えはポリシーを破壊する。 ダイジェストは「Tier 3は人間レビューを必要とする」を損失なく伝えることができます。それは"requireReviewAgent": trueを損失なく伝えることはできません — レビュアーが違反を主張するのに必要な正確で引用可能な詳細は要約で死にます。真の場合: ダイジェストのみのエージェントは、リテラルポリシーファイルを保持するエージェントがキャッチするゲート違反を体系的にミスするはずです。

H3 — よりリーンなコンテキストはより深く読む。 コンテキストはドルと注意力の2倍の代価があります:ウィンドウ内のすべての冗長なドキュメントはレビュー中のコードと競い合います。真の場合: すべてを読む(ダイジェスト+すべてのドキュメント)は勝つべきではありません;最もリーンで十分なコンテキストが勝つべきです。

どうテストしたか

22のエージェントが本番モノリポジトリの同じTier-3プルリクエストをレビューしました(LLMプロバイダ統合:44ファイル、+2,111行、実際の利害関係 — 請求テーブル、フローエンジンルーティング)。5つのアーム、コンテキスト読み込みステップのみが異なります:

アームコンテキスト読み込みn
meaninggridコンテキストエンジンダイジェストのみ(2×context_research5
diskディスクから7+ ドキュメントを読み込む — コンテキストエンジンなし5
hybridダイジェスト+すべてのドキュメントを読み込む5
opt-hybridダイジェスト+1つのファイルを読み込む:ハーネス設定5
coldまったくコンベンションコンテキストなし(ベースライン)2

基本ルール:1つのピン留めされたコミット、1つのプロンプト本体、1つのモデル — Claude Opus 4.8 — すべてのアームが単一の同時バッチでインターリーブされます。エージェントはPRのコメントスレッドからブロックされ、以前の実験ラウンドが漏らされることができません。すべての数字は生のエージェントトランスクリプトから来ており、トークン使用量はAPI要求ごとにデデュプされ、リスト価格で価格設定されます。品質は13の独立して検証された、実際の欠陥に対してスコア付けされ、各レビューの本体にパターンマッチングされ、偽陽性について手動で監査されます。すべてのアーム全体での判定一致:21/22が変更をリクエストしました。

では:最も安価な設定も品質で勝った

散布図:レビューあたりのコスト対検証済み発見:opt-hybridが最も安価で最も徹底的、すべてを読むハイブリッドが最悪のスコア
アームコスト/レビュー発見(13中)ゲート発見(3中)ウォールクロック
meaninggrid$1.777.80.25:34
disk$2.308.60.84:35
hybrid$1.837.40.85:40
opt-hybrid ★$1.569.61.44:55
cold$1.648.00.54:13

★ = リポジトリのデフォルトスキルとして現在提供している設定。ウォールクロックは22のエージェントを同時に実行することからの共有競合を含みます。

H1 — 確認

ダイジェストのみのアームはドキュメント読み込みの$2.30対$1.77でレビューしました(−23%)、そして勝利するダイジェスト+1ファイルアームは$1.56(−32%)— 等しい判定で。節約は複合します:ダイジェストはそれ以外その後のすべてのAPI呼び出しのコンテキストを通じて乗るドキュメントのスタックを置き換えます。

H2 — 決定的に確認

スキップされたreview-agentチェック — このPRの真のマージポリシー違反 — はリテラルポリシーファイルを保持する5/5エージェントによってキャッチされ、ダイジェストのみのエージェントによって1/5でキャッチされました。メカニズムはH2が予測したものと正確です:その発見を書くために、エージェントは正確なCI チェック名を正確な設定フィールドと一致させる必要があります — 言い換えは引用可能な証拠ではないため、ダイジェストのみのエージェントはヘッジして削除します。1つの直接読み込みがそれを復元します。

左右:review-agentチェックを要求するハーネスポリシー、そしてそのチェックがスキップされた一方ですべてが合格したCI実行

H3 — 確認

すべてを読むハイブリッドはあらゆるアームの最もコンテキストを持ち、最悪のスコア(7.4/13)を得た一方で、最もリーンで十分なアームが最高のスコア(9.6/13)を得ました — そしてあらゆるアームで最も深い発見で最高でした。3つのファイル全体で呼び出しパスをトレースする必要があるデッドコードバグ。冗長な散文は情報を追加しませんでした;それはコードと注意力を競い合いました。

時間解剖学:ダイジェストエージェント対ドキュメント読み込みエージェント:コンテキストエンジン待機は見える、ドキュメント読み込みは高速スリバー、モデル時間は両方を支配する

1つの正直な脚注:コールドベースライン(8.0/13で$1.64)は13の欠陥のほとんどが強力なモデルが慣例コンテキストなしで見つける平文コードバグであることを示しています。コールドができないことはジョブのポリシー半分 — ゲート、層、マージルール — これはアームが分離する場所です。

散文をダイジェストにキュレートします。ポリシーファイルを生で読みます。何も2回読みません。

完全な開示

  • モデル: すべてのエージェントのすべてのAPI呼び出しはclaude-opus-4-8(Claude Opus 4.8)で実行されました — 各トランスクリプト行のモデルフィールドから検証され、想定ではありません。結果は他のモデルで異なる可能性があります;より小さいモデルはキュレートされたコンテキストにより多く依存する可能性が高いです。
  • 価格: コストは執筆時点でAnthropicリスト価格を使用します;実際の請求は異なる場合があります。相対比較は影響を受けません。
  • サンプルサイズ: n=5/アーム(コールドの場合n=2)、1つのPR、1つのリポジトリ、1つのタスクタイプ。ゲート効果(5/5対1/5)は鋭い;他の場所の発見あたりのレートは±1エージェント。これを強力なパイロット、ベンチマークではなく扱ってください。
  • 品質メトリック: レビューテキスト上のパターン検出(引用を除く)、偽陽性について手動で監査。それは検証済み欠陥の言及をカウントします、全体的なレビュー雄弁さではなく。
  • タイミング: すべての22のエージェントは1つのマシンと1つのAPI割り当てを共有しました;ウォールクロック数はその競合を含みます。
  • 私たちは2回自分たちを修正しました: 初期トークンカウントは2–3×膨らんでいました(トランスクリプトでの行ごとの使用重複;要求ID重複排除で修正)、そして以前のタイムラインビジュアルはウォール時間を過小計上していました(完全な間隔属性で修正)。両方の修正はここのすべての数字に焼き込まれています。
FlowHuntロゴ

ビジネスを成長させる準備はできましたか?

今日から無料トライアルを開始し、数日で結果を確認しましょう。

では:ループを盗む

私たちが提供したもの

勝利するアームはリポジトリのデフォルトcheck-context-firstスキルです:コンテキストエンジンダイジェストを引き出す(2つの呼び出し)、次に正確に1つのファイルをディスクから読み込む — ハーネス設定 — そしてスナップショットと正確なゲートを引用する確認ブロックを発行します。1つの測定された弱点、1つの1行のポリシー修正、同じ日に再検証されました。そのループ — 測定、コンテキストポリシーを修正、再検証 — はあなたが盗むことを勧める部分です、あなたが使用するコンテキストエンジンが何であれ。

月曜日にできること

  1. エージェントコンテキストを2つに分割する: 散文(慣例、アーキテクチャ、テスト)対機械可読ポリシー(CIゲート、リスク層、マージルール)。
  2. 散文をダイジェストする;ポリシーをダイジェストしない。 散文をコンテキストエンジン — meaninggridは私たちのもの — を通じて提供し、ポリシーファイルをコンテキストゲートで必須の逐語的読み込みにしてください。
  3. コンテキストを監査可能にする。 取り込まれたコンテキストをバージョン管理します;エージェントが確認ブロックでスナップショットIDを引用するよう要求して、レビュアーが実際にチェックできるようにしてください。
  4. 信じる前に測定する — 私たちを含めて。 アームあたりのほんの数エージェントを独自のリポジトリで実行することで、パターンを見るのに十分です。検証済み発見に対してレビューをスコア付けします、バイブスではなく。

公開招待

独自のリポジトリでこの実験を実行する場合 — 同じアーム、あなたのモデル、あなたのハーネス — 私たちはあなたの数字を本当に見たいです、特に私たちのものを反論する場合。そしてあなたのチームがこのようなコンテキストゲートのセットアップを支援したい場合、またはmeaninggridとharnextスタックについて話したい場合は、FlowHuntチームに連絡するか、harnext.dev でオープンソースハーネスを見つけてください。複製、質問、修正はすべて歓迎です。

よくある質問

シュテファンはFlowHuntを開発するAIおよびソフトウェアエンジニアです。製品そのものを超えて、彼は開発コストを削減しながらコード品質を向上させる、開発者向けのエージェント的ソフトウェアエンジニアリングワークフローを設計しています。

シュテファン・モラヴィク
シュテファン・モラヴィク
AIおよびソフトウェアエンジニア

自分たちの投資を回収するエージェントワークフローを構築する

FlowHuntは、開発チームがエージェンティックワークフロー、コンテキストゲート、MCP統合を設計するのに役立ち、開発コストを削減しながらコード品質を向上させます。