「harness-starter-kit」が隠しオラクルA/Bテストで成功：コーディングエージェントの行動を規定する価値を証明
本記事は、韓国出身のジュニア開発者による、AIコーディングエージェント（Codexなど）の性能向上に関する技術的な考察をまとめたものです。筆者はこれまで「harness」がエージェントを強化したと断言することを控えてきましたが、今回、「hidden-oracle A/Bテスト」を実施し、その有効性を明確に示しました。
**【Who, What】**：コーディングエージェントの作業環境（リポジトリ）に「harness-starter-kit」を導入することが、エージェントの行動と成果に決定的な影響を与えることを証明しました。具体的には、特定のプロジェクト規約（repo-local convention）を守る必要があるタスクにおいて、harnessが極めて有効であることが判明しました。
**【Where, When】**：テストは2つのFlaskリポジトリ（`flask-no-harness`と`flask-yes-harness`）を用いて行われました。検証方法として「hidden oracle」を採用し、エージェントが最終的な採点ロジックを見ることなく作業する状況を再現しました。
**【How, Why】**：テストでは4つのAPIタスク（stock risk report APIなど）を合計24回実行し、結果を比較しました。その結果、harnessを適用した`flask-yes-harness`は12回中11回の成功率を記録したのに対し、harnessがない`flask-no-harness`は0/12という著しい差が出ました。この成功の鍵は、単に機能の実装能力ではなく、「ファイル境界（forbidden-file edits）」や「プロジェクト固有の規約」を守る「コンテキスト理解力」にあると筆者は指摘しています。
visible oracleテストではエージェントが検証コードから推測できてしまう問題がありましたが、hidden oracle方式を採用することで、エージェントはプロンプト、既存コード、ドキュメントといった限定された情報のみに頼らざるを得なくなりました。これにより、harnessが提供する「明確な作業環境」の価値（例：API命名規則、ドメイン用語の解釈、変更禁止ファイルの明記）が最大限に引き出されました。
筆者は結論として、harness-starter-kitはエージェントの「一般的なコーディング能力」を向上させるものではなく、「プロジェクト固有の規約遵守」「ファイル境界の維持」「検証プロセスへの参加」といった、実際の開発現場で最も重要となる**コンテキスト依存的な作業能力（repo-local convention）**を高めるための環境整備ツールであると結論づけています。これは「なんとなく便利」な段階を超え、レビュー可能な明確な証拠に基づいた価値を持つものとなりました。
背景
AIコーディングエージェント（例：Codex）が実務レベルで利用される際、単にコードを生成するだけでなく、「既存のプロジェクト規約」や「ファイル構造のルール」を守ることが極めて重要です。従来のテストではこの環境的な制約が不明確でしたが、本記事は『harness』という仕組みを導入することで、エージェントが従うべき明確なガイドライン（コンテキスト）を提供し、その有効性を科学的に証明した経緯があります。
重要用語解説
- hidden-oracle A/Bテスト: 検証コードや採点ロジックをエージェントから隠蔽するA/Bテスト形式。これにより、エージェントが外部のヒントに頼らず、純粋にリポジトリ内の情報と規約のみに基づいて作業することを強制し、真の能力を測定します。
- harness-starter-kit: コーディングエージェントが作業するリポジトリ（repo）内に、プロジェクト固有のルール、命名規則、チェックコマンドなどを体系的に記述・配置するための初期キット。エージェントに明確な「作業環境」を提供する役割を果たします。
- visible oracle: 検証コードやテスト仕様がターゲットリポジトリ内にあり、エージェントから見える状態でのテスト方法。構造的な確認には有効ですが、harnessの真価を測る上では情報漏洩のリスクがあります。
今後の影響
本技術は、AIコーディングエージェントの実用化における大きなブレイクスルーを示唆しています。今後は、単なるコード生成能力だけでなく、「プロジェクトへの適応力」や「規約遵守能力」が評価軸となり、開発プロセス全体に組み込まれることが予想されます。これにより、大規模なチーム開発におけるAIの役割定義がより明確になります。