同じツールで結果が変わる二人の開発者

研究者が同じコーディングベンチマークで同じAIモデルを2回テストした。1回目は42%のスコア。2回目は78%のスコア。同じモデル。同じテスト。何もかも同じ。変わったのはハーネスだけだった。プロンプトでも、モデルでも、温度設定でもない。ハーネス——AIを包み、どう振る舞うかを指示するルール、ツール、スキル、メモリファイル、フィードバックループのシステムだ。これが今のAI支援開発で最も重要な発見だ。そして少数のエンジニアリングチーム以外では、ほとんど誰も話していない。 LangChainが独自に同じことを証明した。彼らのコーディングエージェントは、モデルについては何も変えずに、Terminal Bench 2.0でトップ30外からトップ5に躍進した。ハーネスだけを変えた。OpenAIも証明した。彼らのCodexチームは、人間の手で書かれた行がゼロのコードで100万行以上の本番アプリケーションを構築した。エンジニアはコードを書かなかった。ハーネスを設計した。これらのハーネスを設計するスキルには今や名前がある：ハーネスエンジニアリング。数週間前に造られた言葉だ。YouTubeやエンジニアリングブログでの注目は増えている。しかし主流のカバレッジはほぼゼロだ。ほとんどの開発者はその用語を聞いたことがない。それは変わろうとしている。そして最初に学んだ開発者は、非常に複製しにくいキャリアアドバンテージを持つことになる。これが完全ガイドだ。ハーネスエンジニアリングとは何か。なぜ使うモデルより重要なのか。今日から始める方法。なぜそれがあなたをかけがえのない存在にする0ドルのスキルなのか。ハーネスエンジニアリングが実際に何を意味するかできるだけシンプルにしよう。 Claude Code、Cursor、Codexなどのコーディングエージェントを使うとき、AIモデルはシステムの一部に過ぎない。モデルはブレインだ。しかしブレインには指示が必要だ。ツールが必要だ。ルールが必要だ。メモリが必要だ。出荷前にミスを捕まえるフィードバックループが必要だ。モデルの周りにあるすべてのそれ？それがハーネスだ。乗馬を考えてみよう。馬は強力だ。しかし手綱、鞍、ビットがなければ、馬は行きたいところに行く。ハーネスは、その力を必要な方向に向けるものだ。 AIコーディングエージェントも同じだ。モデルは強力だ。しかし適切に設計されたハーネスなしでは、推測し、漂流し、同じミスを何度も繰り返し、印象的に見えるが本番でバグになるコードを生成する。ハーネスエンジニアリングは、AIコーディングエージェントが同じミスを二度としないよう、そのハーネスを設計・設定する実践だ。 TerraformのクリエイターでThe最も尊敬されるエンジニアの一人、Mitchell Hashimotoはこう定義した：「エージェントがミスをするたびに、エージェントが二度とそのミスをしないような解決策をエンジニアリングする時間を取る。」それが1文に凝縮された全哲学だ。より良いモデルを祈るな。モデルの周りのシステムを直せ。コーディングエージェントハーネスの5つのレバーすべてのコーディングエージェントには5つの設定ポイントがある。これがレバーだ。正しいものを引けば、同じモデルが劇的に良いコードを生成する。 1. システムプロンプト（CLAUDE.md / AGENTS.md）リポジトリのトップにあるマークダウンファイルで、すべてのセッションの開始時にエージェントのコンテキストに注入される。コードベースが何についてのものか、どの規約に従うか、何を避けるかをエージェントに伝える。ほとんどの人はこのファイルを完全にスキップするか、AIに生成させる。どちらもミスだ。ETH Zurichの研究は異なるリポジトリの138のエージェントファイルをテストして、AI生成のものは実際に20%多くトークンをコストしながらパフォーマンスを傷つけることを発見した。人間が書いたものは助けになったが、簡潔で具体的な場合だけだ。ルール：60行以内に収める。すべてのタスクに適用される普遍的な指示だけを含める。ディレクトリリスト不要（エージェントは自分で構造を発見できる）。条件付きルール不要（「Xをするなら、Y」は混乱を生む）。必要なものだけ：テックスタック、テストコマンド、コーディング規約、ハードルール。 2. スキル（知識のプログレッシブな開示）スキルはタスクがマッチしたときだけエージェントがロードする指示ファイルだ。システムプロンプトにすべてを詰め込む代わりに、知識を集中したモジュールに分割して、エージェントが必要に応じて発見する。例えば、データベースマイグレーションのスキル、APIエンドポイント作成のスキル、フロントエンドコンポーネントパターンのスキルを持つかもしれない。エージェントがマイグレーションタスクに遭遇すると、マイグレーションスキルを自動的にロードする。残りはコンテキストウィンドウの外にある。これをプログレッシブな開示と呼ぶ。エージェントは最小限のコンテキストから始め、必要に応じてより多くを引き込む。コンテキストウィンドウをクリーンに保ち、関係のない指示でエージェントが混乱するのを防ぐ。 3. MCPサーバー（ツールと機能） Model Context Protocolサーバーはエージェントがファイルを読んでコマンドを実行すること以上のことを拡張する。イシュー追跡のためのLinear、エラーモニタリングのためのSentry、ライブクエリのためのデータベース、または任意の外部システムにエージェントを接続できる。ただし警告：接続するすべてのMCPツールはエージェントのシステムプロンプトに追加される。ツールが多すぎると、HumanLayerチームが「ツールスラッシュ」と呼ぶものが起きる——エージェントはどのツールを使うか決めることに時間を無駄にして、実際の作業をしない。2〜3つから始める。本当の制限にぶつかったときだけ追加する。 4. サブエージェント（コンテキストファイアウォール）これがほとんどの人が誤解しているレバーだ。サブエージェントは「フロントエンドエンジニア」エージェントと「バックエンドエンジニア」エージェントを持つことではない。それは機能しない。HumanLayerチームが試して諦めた。サブエージェントはコンテキストファイアウォールとして機能する。メインエージェントがコンテキストウィンドウを中間ノイズで埋めてしまうタスクに遭遇したとき、そのタスクをサブエージェントに委任する。サブエージェントは独立したコンテキストで実行し、作業をして、結果だけを返す。中間ステップはどれも親スレッドを汚染しない。これがメインエージェントを「スマートゾーン」に保つ方法だ。Chromaの研究は、AIモデルがより長いコンテキスト長でパフォーマンスが測定可能なほど悪化することを示している。サブエージェントは大きな問題を小さな、集中したセッションに分割し、モデルがシャープな状態を保てる。 5. フック（自動チェックポイント）フックはエージェントのワークフローの特定の点で自動的に実行されるスクリプトだ。非決定論的なシステムに決定論的なコントロールを追加する。例えば、pre-commitフックはエージェントがコードをコミットする前にリンターを実行できる。pre-completionフックはエージェントがタスクを完了と宣言する前にテストを実行するよう強制できる。ループ検出フックは同じ編集を何度も繰り返し始めたエージェントを捕まえられる。 LangChainは「PreCompletionChecklistMiddleware」を構築した。タスクを完了する前にエージェントを傍受し、元の要件に対する検証パスを強制する。その単一のフックが彼らのハーネス全体で最大のパフォーマンス向上の一つだった。なぜハーネスはモデルより重要なのかこれがほとんどの開発者が間違える部分だ。ClaudeとGPTとGeminiの議論に何時間も費やす。すべての新しいモデルリリースを追いかける。次のバージョンがすべてを直すと信じる。データは違うことを言っている。研究者が2026年3月に同じAIモデルが周囲のハーネスだけで42%から78%の精度にスイングできることを実証した。それはほぼ2倍のパフォーマンスだ。歴史上2倍の改善をもたらしたモデルのアップグレードはない。しかしよく設計されたハーネスはそれを日常的にやる。 LangChainは業界標準のTerminal Bench 2.0ベンチマークで同じことを証明した。同じモデル。異なるハーネス。トップ30外からトップ5へ。 OpenAI自身のCodexチームが直接言った：「エージェントが苦労するとき、それをシグナルとして扱う。何が欠けているか——ツール、ガードレール、ドキュメント——を特定して、リポジトリにフィードバックする。」モデルを切り替えない。ハーネスを直す。モデルはエンジンだ。ハーネスはステアリング、ブレーキ、道だ。世界で最も強力なエンジンを持てる。ステアリングなしではクラッシュする。今日からハーネスエンジニアリングを始める（0ドル）新しいツールは必要ない。コースも必要ない。AIコーディングエージェントを変える必要もない。失敗したときの反応を変える必要がある。ステップ1：失敗の反射を変える古い反射：エージェントがミスをして、手動で直して先に進む。新しい反射：エージェントがミスをして、「二度とこのミスをしないようにするにはどうすればいいか？」と問う。そして修正をハーネスにエンコードする。それがマインドセットの変化の全てだ。すべての失敗はハーネスに何かが欠けているシグナルだ。欠けているものを見つける。追加する。先に進む。エージェントはその方法では二度と失敗しない。ステップ2：簡潔なCLAUDE.md / AGENTS.mdを書くリポジトリのルートにマークダウンファイルを作る。60行以内に収める。テックスタック、テストコマンド、ハードルール（「マイグレーションファイルは絶対に削除しない」「コミット前に必ずテストを実行する」「TypeScript strictモードを使う」）を含める。ディレクトリマップなし。条件ロジックなし。AI生成のコンテンツなし。ステップ3：最初のスキルを構築するコードベースの繰り返しパターンを特定する。APIエンドポイントの作成。データベースマイグレーション。コンポーネントスキャフォールディング。エッジケースと一般的なミスを含めて正しくやる方法を説明する集中した指示ファイルを書く。スキルとして保存する。パターンがマッチしたとき、エージェントが自動的にロードする。ステップ4：1つのフックを追加するリンターとテストスイートを実行するpre-commitフックから始める。エージェントがどちらのチェックも失敗するコードをコミットしようとしたら、フックがリポジトリに到達する前に捕まえる。1つのフック。巨大な影響。ステップ5：コンテキストが多いタスクにサブエージェントを使う長いタスクでエージェントがコヒーレンシーを失っていることに気づいたら、サブタスクに分割する。各サブタスクをサブエージェントに委任する。サブエージェントに独立して作業させ、結果だけを返させる。メインスレッドをクリーンに保つ。ステップ6：毎週反復する毎金曜日、その週の失敗をレビューする。それぞれについて、ルール、スキル、またはフックをハーネスに1つ追加する。失敗ごとに5分のハーネスエンジニアリング。時間をかけてハーネスに修正が積み重なる。エージェントは毎週より信頼できるものになる。モデルが改善されたからではない。システムが改善されたからだ。誰も見えていないキャリアの堀なぜこれがキャリアに重要か。 AIモデルはコモディティ化されつつある。すべての会社が同じフロンティアモデルにアクセスできる。Claude、GPT、Gemini——みんなに利用可能だ。モデルはもはや競争優位ではない。しかしよく設計されたハーネスはそうだ。コードベースに固有だ。チームのパターンに固有だ。ドメインのエッジケースに固有だ。モデルをダウンロードしても複製できない。実際の世界の失敗をシステムにエンコードする週と月をかけて構築される。これらのハーネスを設計できる開発者は、会社が置き換えられない人だ。最良のコードを書くからではない。AIが最良のコードを書けるようにするシステムを設計するからだ。 OpenAIが明示的に言った：エンジニアの仕事はもはやコードを書くことではない。環境を設計し、インテントを指定し、エージェントが確実な作業をできるフィードバックループを構築することだ。それがハーネスエンジニアリングだ。そして今それを学ぶ開発者、用語がまだ新しく、規律がまだ形成されている間に、待っているすべての人より2年先行することになる。プロンプトエンジニアリングは2023年のスキルだった。コンテキストエンジニアリングは2025年のスキルだった。ハーネスエンジニアリングは2026年のスキルだ。学ぶのに0ドルかかる。新しいツールは必要ない。コーディングエージェントへのアクセスがある開発者全員に利用可能だ。唯一の質問は、今日ハーネスをエンジニアリングし始めるか、次のモデルリリースがすべてを直すのを祈り続けるかだ。データはすでにその質問に答えた。

同じツールで結果が変わる二人の開発者

AIFCC — AI Fluent CxO Club