ハーネスエンジニアリング：モデルより重要な作業環境設計の時代
(addyosmani.com)アディ・オスマニ(Addy Osmani)がまとめた「ハーネスエンジニアリング(Harness Engineering)」に関する分析です。彼はこの2年間、業界の関心が「どのAIモデルがより賢いのか」という問いにばかり集中していたと見ています。GPTのほうがよりきれいなコードを書くのか、Claudeのほうが幻覚を起こしにくいのかをめぐって延々と比較が続いてきましたが、実際のコーディングAIの成果はモデルそのものより、そのモデルを取り巻くハーネスで決まるというのが彼の主張です。ハーネスとはモデル以外のすべてを包括する言葉で、AIに仕事をさせるシステムプロンプト、使えるツールや外部サーバー、コンテキスト管理ポリシー、実行中に自動で割り込む点検装置(フック)、安全な実行空間(サンドボックス)、補助AI(サブエージェント)、フィードバックループ、作業が詰まったときに復旧するフローまで、すべてを含みます。Viv Trivedyが「AIエージェント = モデル + ハーネス」という一文でこの概念を定式化し、Anthropicのエンジニアリングチーム、HumanLayer、Simon Willisonらがこの流れを精密に磨き上げています。オスマニは、この流れがいまや一つの工学分野として定着したと見ています。
要点をほどくと次のとおりです。
-
ハーネスとは何か モデルだけでは仕事を完了するAIにはなれません。進行状況を記憶し、ツールを実行し、結果を見て再判断し、やってはいけないことを防ぐコードや設定が加わって、初めて「働くAI」になります。Claude Code、Cursor、Codex、Aider、Clineのような製品はすべてハーネスであり、その中に入るモデルが同じでも、私たちが体感する挙動はハーネスが左右します。Simon Willisonの表現を借りれば、AIエージェントは「目標を達成するためにツールを繰り返し回すシステム」であり、そのツールと反復構造をどう設計するかが実力の本質です。
-
モデルのせいではなく設定のせいという見方 エンジニアはAIが妙なことをすると、よくモデルを責めて「次のバージョンを待とう」という結論に流れがちです。ハーネスエンジニアリングはこの反応を拒みます。HumanLayerの表現を借りれば「これはモデルの問題ではなく設定の問題(skill issue)」です。同じClaude Opus 4.6モデルを使っても、デフォルトのハーネスであるClaude Codeの中ではTerminal Bench 2.0の下位圏にとどまる一方、自前で手を入れたハーネスに移すと上位圏へ跳ね上がった事例があります。Vivのチームはハーネスだけを変えて、同じモデルを30位台から5位台へ押し上げました。モデルが持つ潜在力を、ハーネスが削いでしまっていることは少なくないという意味です。
-
失敗をルールとして固定する「ラチェット(ratchet)」原則 AIが一度でも起こした失敗は偶然の事故として流さず、恒久的なシグナルとして扱います。次回同じ失敗が起きないよう、ルール文書に1行追加し、自動遮断装置を付け、レビュー担当の補助AIを置く、といった形で1段ずつ締めていきます。たとえばAIがテストコードをコメントアウトしてしまったことがあれば、次のバージョンのルール文書には「テストはコメントアウトせず、削除するか修正すること」という1行が入り、コミット直前の検査段階にはそのパターンを検出するチェッカーが追加されます。良いルール文書のすべての行は、過去にあった具体的な失敗と結び付いていなければならない、というのが核心です。だからハーネスエンジニアリングは、誰かが作ったフレームワークをそのまま持ってくる作業ではなく、自分のコードベースの失敗履歴に沿って育てていく「規律」に近いものです。
-
望む挙動から逆算して設計する Vivが提案する最も有用な考え方は、「こういう挙動を望む → その挙動を可能にするハーネス部品は何か」の順に逆算して設計することです。ある部品が何の挙動のために存在するのかを1行で説明できないなら、その部品は外したほうがよいということです。具体的には、ファイルシステムとGitは作業内容を長く保存し巻き戻すため、bashとコード実行は何でも試せる万能ツール、サンドボックスは壊しても本体に影響しない安全な実行空間、メモリファイルとWeb検索・MCPツールは新たに得た知識を蓄える通路、要約圧縮とツール出力の分離、スキル機能はAIの記憶力の限界を伸ばす装置、そしてRalph loopとプランナー・評価者分離構造は何日もかかる長い作業を最後まで引っ張る方法です。
-
コンテキスト腐敗(context rot)の問題 AIは一度に読める文章量に限界があり、その上限に近づくほど判断力が目に見えて落ちます。だからハーネスは、限られた空間をどう上手に使うかの仕組み一式でもあります。第一に、上限が近づいたら古い内容を賢く要約して圧縮します。第二に、2,000行のログのような大きな出力は先頭と末尾だけ残し、本体はファイルへ退避して必要なときだけ再読させます。第三に、ツールや指示文を最初から全部見せず、その作業で本当に必要な瞬間にだけ取り出す「段階的公開」を使います。本当に長い作業では、引き継ぎ文書だけを持って新しいウィンドウで最初から再開することもあります。Anthropicは「長い作業では要約圧縮だけでは足りず、構造化された引き継ぎ文書で新たに始める必要がある場合がある」と指摘します。人で言えば、新人に業務を引き継ぐときに整理された文書を渡すやり方に似ています。
-
長い作業を引っ張るパターン群 今日のモデルの弱点の一つは、早く仕事を終えようとすること、大きな問題を細かく分割できないこと、コンテキストウィンドウが変わると流れが切れることです。ハーネスはこの弱点を補わなければなりません。Ralph loopは、モデルが仕事を終えようとするたびにフックが割り込み、元の目標を新しいコンテキストウィンドウへ再注入して作業を継続させる単純な手法です。各反復はクリーンな状態で始まりますが、直前の作業結果はファイルシステムを通じて引き継がれます。一方Anthropicは、「生成担当」と「評価担当」を別のAIに分けるべきだと強調します。AIが自分の成果物を自分で評価すると、甘い点数を付けがちだからです。これに加えて、「完了とはどんな状態か」を作業開始前にあらかじめ合意しておく「スプリントコントラクト」パターンは、作業中に目標がずるずる膨らむ現象を防ぐのに効果的です。
-
フック(hook)の役割 「AIにそうするよう言っておくこと」と「システムが強制的にそうさせること」は違います。フックはその差を埋める自動装置で、ツール使用前、ファイル修正後、コミット直前、セッション開始時などのタイミングで割り込んで動作します。コードを修正するたびに自動で構文チェック・lint・テストを回したり、
rm -rfやgit push --forceのような危険なコマンドを止めたり、PRを出す前に人の承認を受けさせたりするといった具合です。原則は「成功は静かに、失敗は騒がしく」です。検査が通ればAIは何も聞かされず、失敗すればそのエラーメッセージがそのままフローに注入されて、自分で修正するよう促されます。普段のコストはほとんどかからず、問題が起きた瞬間にだけ正確に助ける構造です。 -
ルール文書とツール選択は短く明確に プロジェクトルートに置くAGENTS.mdは、毎ターンのシステムプロンプトに入る最も影響力の大きい設定ファイルです。HumanLayerはこの文書を60行以下に保つよう勧めています。長くなるほど各行の重みが薄れるので、普段のスタイルを書いておく案内書ではなく、飛行機操縦士のチェックリストのように本当に必要な項目だけを残せという勧告です。ツールも同様で、名前と説明、スキーマが毎リクエストごとにプロンプトへ埋め込まれるため、似たり寄ったりのツール50個より、よく磨かれた10個のほうが優れています。HumanLayerはセキュリティ面にも触れています。ツール説明そのものがAIの読むテキストなので、未検証の外部MCPサーバーをつなぐことは、誰かがあらかじめ書いておいた指示をAIへ密かに注入する経路になり得ます。
利点として見られる点です。
- 力を入れるべき場所が明確になる モデルを変えなくても挙動を大きく引き上げられる場所がハーネスだという事実が、ベンチマークデータで示されています。「次のモデルを待とう」という漠然とした期待ではなく、今すぐ手を入れられる具体的な領域が生まれるということです。
- ノウハウが蓄積する構造 失敗をルールへ変えるラチェット方式のおかげで、一度学んだ教訓がチーム資産として残ります。人が変わってもルール文書とフックは残り、次の人を守ります。
- 既製ハーネスの登場(HaaS) Vivが「Harness-as-a-Service」と呼ぶ流れが急速に定着しています。Claude Agent SDK、Codex SDK、OpenAI Agents SDKのように、作業ループとツール、コンテキスト管理、フック、サンドボックスをあらかじめ束ねた製品が登場し、ゼロから全部作らなくても自分のドメイン知識に集中できるようになりました。
負担の大きい面もあります。
- 面倒を見るべき領域が広い 指示文、ツール、安全な実行空間、自動点検、ログ監視まで、すべてを自分で責任を持って見なければなりません。モデル提供者が勝手にやってくれる領域ではないという点が重要です。
- モデルとハーネスの結合リスク 今日のモデルは特定のハーネス内で後処理学習されているため、別のハーネスへ移すと突然性能が落ちることがあります。ツール名1つ、引数形式1つ変えただけで結果が揺れます。本当に汎用的なモデルならツール名に影響されるべきではありませんが、いっしょに学習される構造のため、一種の過学習が起きているわけです。
- 外部ツールのセキュリティリスク MCPサーバーはツール説明文がそのままAIに読まれるため、未検証のツールをつないだ瞬間から、ユーザーが1文字も入力する前にすでに外部テキストがAIへ影響を与え始めます。
差別化される視点です。
- モデル中心の言説から距離を置く より賢いGPTを待つ空気ではなく、いま手元にあるモデルで到達できる限界を引き上げる工学的手法を示します。現在見えているAIの限界と、モデルが実際に持つ能力とのギャップの大半は、ハーネスのギャップだという診断です。
- ハーネスは消えずに場所を移す モデルが良くなると、不要になるハーネス部品もあります。たとえばOpus 4.6は、Claude Sonnet 4.5でよく見られた「コンテキストがもうすぐ尽きそうだから急いでまとめよう」といった焦りをほぼ消し去り、その結果それまで使われていた安心用の補助装置がまるごとデッドコードになりました。しかしモデルが届く新しい領域には新しい弱点があり、その弱点を埋める新しいハーネスが再び必要になります。「ハーネスのすべての部品は、モデルが単独ではできないことが何かについての仮定を含んでいる」というAnthropicの表現がよく当てはまります。
- モデルとハーネスの学習循環 Vivが指摘するもう一つの流れは、ハーネス設計とモデル学習の間にあるフィードバックループです。ハーネスで有用なパターンが見つかると、それが標準化され、次世代モデルがそのパターンを基準に学習し、さらにそのモデルの上で新しいハーネスパターンが生まれます。だから「良いハーネス」とは、モデルが学習したそのままのハーネスではなく、自分の仕事に合わせて改めて磨き直したハーネスだという結論になります。
- 業界が同じ形へ収束 Claude Code、Cursor、Codex、Aider、ClineのようなコーディングAIは、中のモデルは異なっていても、ハーネスの形はだんだん似てきています。モデルはそれぞれ違うのにハーネスは似てくるという事実は、この分野がどこへ落ち着きつつあるのかを示すシグナルとして読めます。
オスマニの文章は、コーディングAIの競争力がモデル選びよりも、その周辺のハーネス設計に大きく左右されること、そしてハーネスは一度設定して終わる設定ファイルではなく、失敗履歴に応じて継続的に更新される生きたシステムだという見方を提示します。モデルが良くなったからといってハーネスが消えるのではなく、扱う問題の階層が一段上へ移ることで、新しいハーネスがその場所を埋めるようになります。彼が引用したVivの言葉どおり、「良いエージェントを作る仕事は反復の芸術であり、最初のバージョンがなければ反復もない」というのは、この分野が結局、誰が早く始めてより頻繁に磨くかの勝負だという意味に読めます。結局エンジニアが時間を注ぐべき場所は、話題のモデルを毎回差し替えることではなく、自分の仕事に合ったハーネスを絶えず手入れしながら、モデルが届く天井を一段ずつ押し上げていく作業だ、という結論にまとめられます。
10件のコメント
だんだんマーケティング用語ばかりがものすごく増えている感じですね。
モデルが優れていれば、ハーネス設計の負担も軽くなります。
こういうものを適用しても、実際にコーディングする場面ではあまり大きな助けにはならない気がしますね……codex のプランを置いてエージェントを回す程度の難易度の開発だから、ということなんでしょうね（笑）
でも、プロンプトでAして、Bはしないでと言ったときに、本当にきちんと理解してくれるならこういうアプローチは有効そうですが、AIサーバーの状態によって確率的にプロンプトを実行する場合でも、このアプローチは有効なのでしょうか？
昔、プロンプトでAをしてくれと明確に書いてあるのに、一定の確率でどうしても守られないので、mrkdwn boldで強調してみたり、二度書いてみたり、英語で書いてみたり、首尾呼応の形で書いてみたり、xmlで書いてみたりと、あれこれ試したのですが、それでも一定の確率でプロンプトを無視するんですよね…
私もオスマニの話と似たようなものを全部ぶち込んで
アプリを作っていたところにこの話が出てきたので、ちょっと急いで書いたんですが、
オスマニも口で言うだけじゃなくて
Google Antigravityに自分が話したことを入れてくれていたら、もっとよかったんじゃないかと思います。
カパシもそうですが、もうただ作るつもりはなくて文章だけポンと投げて終わるような振る舞いは、うーん……という感じです！です
https://github.com/hang-in/tunaFlow
3行要約
でも、ハーネスは先週まではかなり売り込んでいたのに、今週からは静かですね……Anthropicの迷走とCodex 5.5が優れているからでしょうか……
SDDみたいなものはもうとっくに hype が終わっていて、これからはハーネスなんでしょうね。
ハーネスで少し不思議なのは、学習データには明らかにないのに、モデルが
harnessという概念をすぐ理解していたことです。もともと存在していた単語の意味をそのまま使っているからか、こちらから触れてもいないのに先に「harness を更新します」のような言及までしていました。
中身のない話をもっともらしく語る上級開発者の文章を、さらに分析までした内容ですね（個人的にGoogleが嫌いなので失礼します）。もちろん、現象への理解という観点からのアプローチは良い試みだと思います。