ハーネスエンジニアリング：エージェントで実際に自分が作る部分

エージェントとは、ある仕掛けの中に置かれたモデルのことです。モデルを呼ぶループ、モデルが呼び返せるツール、文脈に何を入れるかの判断、確認なしで触れてよい範囲の取り決め、そして生成されたコードが動く場所の境界。この仕掛け全体がハーネスであり、モデルと違ってここは完全に自分の領分です。

フレームワークとは分けて考える価値があります。フレームワークは自分が上に乗せて作るライブラリで、LangGraphやPydantic AI、OpenAI Agents SDKがそれにあたり、選び方は耐久性や言語、保守状況をめぐる5つの質問になります。ハーネスは動いている仕掛けそのもので、名前を付けたかどうかに関係なく必ず存在します。多くのチームは自分のハーネスを設計ではなく事故で発見します。ツールを1つ足し、バグを1つ踏むたびに、少しずつ輪郭が見えてくるという順序です。

呼び名が定まったのは最近です。Anthropicは2025年11月にharnessという語をタイトルに掲げ、複数の文脈ウィンドウをまたいでエージェントを働かせる仕掛けとして説明しました。LangChainは2026年3月にこれを「Agent = Model + Harness」という式に縮め、ハーネスとは「モデルそのもの以外のコード・設定・実行ロジックのすべて」だと定義しています。martinfowler.comに2026年4月に寄稿したBirgitta Böckelerは、進め方を伝える「ガイド」と、仕事の出来を伝える「センサー」の2つに分けて捉えています。

2026年の良いところは、この判断がもう口伝ではなくなったことです。真面目なプロジェクトは判断を設定項目として公開し、理由を文書に書き、そして何より読む価値があるのは、自分たちの仕組みがどこで効かなくなるかまで明記している点です。以下では判断を5つに分けます。いずれも本カタログのプロジェクトからそのまま読み取れるもので、最後に「それはモデルを差し替えるより効くのか」という厄介な問いを扱います。

判断1：モデルに何個のツールを見せるか

つい全部つなぎたくなります。エージェントと長く付き合ってきたプロジェクトほど、逆方向へ進んでいます。

GitHub公式のMCPサーバーは、ツールを23のツールセットに分け、既定で有効にするのは5つだけです（context、issues、pull requests、repositories、users）。ドキュメントは理由を一文で書いています。必要なツールセットだけを有効にすることは「モデルのツール選択を助け、文脈のサイズを減らす」。この二点は両方とも重要です。ツールの定義は無料ではなく、本来の作業に使うはずの文脈を食います。そして90個超から選ぶモデルは、十数個から選ぶモデルより下手に選びます。

Chrome DevToolsチームはさらに徹底しています。彼らのMCPサーバーは11分類・57個のツールを持ちながら、メモリ解析や拡張機能まわりは指定するまで無効のままにし、さらに全体を3つ（移動・実行・スクリーンショット）へ畳むslimモードを用意しています。57個のツールを持つ製品の作者自身が3個版を同梱している事実は、ツール数が実際にどう効くかを何より雄弁に語っています。

AWSのサーバー群は反対方向から同じ場所に着きます。1つのサーバーに全機能を持たせるのではなく60超の小さなサーバーに割り、その日の仕事に必要な2〜3個だけを動かす使い方を想定しています。

ここから出る原則：ツール一覧は在庫ではなく予算として扱ってください。連携先ごとではなく、仕事ごとに決めるということです。

判断2：モデルに何を、いつ見せるか

文脈はもう1つの予算で、しかもエージェントを有用にしている当のものが消費します。ファイルの中身、ツールの出力、検索結果、そこまでの経緯です。

カタログには真似する価値のある型が3つあります。Context7が狙うのは量ではなく鮮度で、ライブラリ名を識別子に解決してバージョンを固定し、実際に使っている版のドキュメントを返します。モデルは学習時に覚えたAPIに向けてコードを書かなくなります。claude-memが狙うのは取り出しのコストで、検索は安価な索引行を返し、タイムラインで位置づけ、開いた記録だけが本来の分量を払う段階式です。Scraplingは入口で入力量を絞ります。MCPサーバーはページをセレクタで狭めてからモデルへ渡し、指示文を仕込みうる隠しDOMの中身は取り除きます。

LangChainのLance Martinは、ここで打てる手を3つに整理しています。古いツール呼び出しを要約して減らす（reduce）、必要になるまでプロンプトの外に置く（offload）、トークンを食う作業は専用のエージェントに分けて綺麗な文脈で処理させる（isolate）。上の3プロジェクトは、それぞれこの3手のどれかを製品にしたものです。

3つに共通する形は、モデルに賢く処理させる前に、ハーネス側が意図をもって文脈を絞っていることです。反対に全部を流し込んで期待する進め方は、動くデモが高価で物覚えの悪い本番システムに変わる、いちばんありふれた道筋です。

判断3：確認なしで何をしてよいか

ここは誠実なプロジェクトほど言葉が率直で、並べて読む価値のある引用が2つあります。

GitHubのMCPサーバーには読み取り専用モードがあり、これは「他のどの設定よりも優先される厳格なセキュリティフィルター」として、設定で明示的に要求されていても書き込み系ツールを無効化します。さらに公開リポジトリ向けのロックダウンモードがあり、push権限を持つ利用者の書いた内容だけを見せます。見知らぬ第三者がIssueに仕込んだ指示への防御です。そのうえでドキュメントはこう書いています。「ロックダウンモードはベストエフォートのコンテンツフィルターであり、セキュリティ境界ではありません」。

DeerFlowもスキルの権限について同じことを自分の言葉で述べています。「これはベストエフォートの挙動上の限定であって、堅牢なセキュリティ境界ではありません」。別のツール経由で読み込まれた指示は捕捉できない、と理由も添えてあります。

規模の大きい慎重なプロジェクトが2つ、それぞれ独立に、モデルの前に置いたフィルターは安全を担保するものではないと述べています。いまのエージェント開発でもっとも有用な一文で、示している先も具体的です。境界は、モデルが交渉できない場所に置くしかありません。つまり認証情報と、マシンです。

認証情報の側は具体的です。AWSのサーバー群は実際の変更を --allow-write と --allow-sensitive-data-access という明示的な指定の後ろに置き、しかもサーバーごとに分けています。アカウントを報告するだけのエージェントと、変更できるエージェントは別のデプロイになるということです。GitHubのサーバーにはリポジトリを絞る設定自体がなく、届く範囲を決めるのは渡したトークンです。agentgatewayはこれを組織単位で行う版で、認証・アクセス制御・トレースをMCPやモデルへの通信の手前に一度だけ置き、各エージェントが同じものを作り直さずに済むようにします。

判断4：コードが実際に動く場所

エージェントがコードを書き、それを何かが実行した瞬間に、ハーネスの問題はインフラの問題になります。

E2Bはまさにこのために存在します。1秒を大きく下回る時間で起動する隔離されたマイクロVMがあるから、タスクごとのサンドボックスが理想論ではなく実務になります。OpenHandsはその差がそのまま見えます。公開コンテナイメージから動かせばエージェントが触れるのはマウントしたプロジェクトディレクトリですが、npmやソースからの起動では「エージェントサーバーはファイルシステム全体にアクセスできる」という警告がプロジェクト自身から示されます。DeerFlowはデプロイ時に選択を明示させ、ローカルプロセス・Docker・Kubernetes・E2Bから選ばせます。「エージェントにコードを実行させてよいか」が、信頼の問題ではなく設定1行の問題になります。

反例も、断罪するためではなく学ぶために有用です。OpenClawは単独の利用者が自分の端末で動かす前提で作られていて、サンドボックスを設定しない限りツールはホスト上でそのまま実行される、とREADMEが明記しています。1人のノートPCとしては筋の通った設計で、共有環境としては悪い設計です。そのこともプロジェクト自身が書いています。機能一覧より先にサンドボックスの既定値を読むと、そのプロジェクトがどちらなのかが分かります。

判断5：ループが自分の仕事を検算するか

誰も検算していない成果物を出すハーネスは、「もっともらしいもの」を出します。もっともらしさはこの技術に固有の失敗の形で、いちばん安上がりな対策は、ループの中に「駄目だ」と言える工程を1つ置くことです。

Aiderはその素直な実装です。変更のたびに手元のリンターとテストを走らせ、報告された問題を自分で直します。賢い検査ではありませんが、そこが肝心です。コードについての意見ではなく、コードについての事実だからです。Clineは別の場所に別の検査を置きます。まず調べて方針を出すPlanモードがあり、実行するActモードに移ると、ファイルの編集もコマンドも承認を挟み、巻き戻せる差分として記録されます。

この2つは「検算するのは機械か人か」という同じ問いへの別の答えです。順序としては、人の検査が要る前に機械の検査を入れてください。テスト、型、リンターは、誤った仕事に対して既に異議を唱えられるようになっている資産です。エージェントはその異議をその場で受け取ってやり直せるぶん、人間のレビュアーよりも大きな恩恵を受けます。

モデルを変えるより効果があるのか

「モデルよりハーネスのほうが効く」という言い方をよく見かけます。実際の証拠はその標語より込み入っていて、しかもこの作業をやるべき理由として、別のものを指し示しています。

公表されている中で最大の改善はLangChainが2026年2月に出したものです。モデルをGPT-5.2-Codexに固定したまま、ハーネスの改良だけでTerminal-Bench 2.0のスコアが52.8から66.5へ動いています。自社製品を自社で測った数字であり、留保も同社自身が書いています。Claude Opus 4.6での試行は旧版のハーネスで59.6であり、その理由を「同じ改良ループをClaude向けには回していないから」と説明しています。つまりこの利得は一度勝ち取れば済むものではなく、モデルごとに調整して得るものだ、という自己申告です。

2026年5月の position paper はより一般的な主張をしています。「ハーネスに起因するばらつきは、モデルに起因するばらつきを大きく上回りうる。モデルの順位が入れ替わる場合すらある」。ただしこれは測定結果ではなく、ベンチマークの結果にハーネスの構成を明記させるべきだという論陣です。

いちばん慎重な測定は、もっと静かで、もっと有用なことを言っています。VatsとGolevは2026年6月、2つのモデルをGoose、OpenCode、OpenHands SDKという3つのハーネスに載せ、50問の課題集合で比較しました。正答率はほとんど動きません。差は0〜8ポイントで、最大の差を除いて信頼区間はゼロを含みます。動いたのはコストのほうで、1問解くのに使うトークン数は最大40倍の開きが出ました。失敗の型もハーネスごとに固有で、両方のモデルで同じように再現しています。

これを真に受けると、ハーネスエンジニアリングの意義は形を変えます。測定できた効果は「エージェントが賢くなる」ことではありません。同じ仕事のコストが40分の1にも40倍にもなり、失敗が見慣れた形で出るか気づけない形で出るかが変わり、事故が及ぶ範囲を自分で決めたか成り行きで引き受けたかが変わる、ということです。

この見方は、何を作り何を作らないかも説明します。懐疑論には残しておく価値のある指摘があります。Han Leeはハーネスのコードの大半が「次世代のモデルに溶けて消える」と述べ、これを仕事にしているLance Martinも、モデルが良くなるほど構造を剥がしていくのが仕事だと言っています。彼らが指しているのは、モデルの弱さを補うための足場です。凝ったプロンプトの連鎖や、手取り足取りの分解がそれにあたり、この半分については「アップグレードのたびに捨てる」が正しい構えです。もう半分、つまりどの認証情報を持たせるか、コードがどこで動くか、文脈に何を入れるか、テストが走ったかどうかは、何かを補っているわけではありません。エージェントが何に触れてよいかという問いを、モデルの更新が引退させることはありません。

次の1か月をどこに使うか

間違えたときの損害が大きい順に手を付けてください。

能力より先に境界を決める。何ができるかより先に、どの認証情報を持たせ、コードをどこで動かすかを決めます。この2つが以後のあらゆる失敗の範囲を決めます。本稿で引いた2つの引用が存在するのも、規模の大きなプロジェクトが2つとも「モデルの前に置いたフィルターはその役目を果たさない」と明言したかったからです。

次にツールを減らす。MCPサーバーをつないでツールセットを全部有効にしたままなら、使われないツールのために文脈を払い、モデルの選択を難しくしています。23個中5個というGitHubの既定は、自分のツール面を設計するときの妥当な目安になります。

次に、文脈に何を入れるかを意図的に決める。文脈は必ず誰かが絞ります。問題は、その絞り込みを自分で設計したのか、最後に呼んだツールの返り値まかせにしたのかです。

そして検算役を足す。その仕事にテストがあるなら、ループの中で走らせてください。テストが無いなら、最初にエージェントに任せるべき仕事は、そのコードにテストを付けることです。

フレームワークの乗り換えから始めない。いちばん進捗している感触があり、いちばん何も変わらない手です。フレームワークが決めるのはループの書き表し方で、安全か、費用が見合うか、正しいかを決めているのは上の4つです。それでも選ぶ必要があるなら、機能表より5つの質問のほうが早く候補を絞れます。