ハーネスエンジニアリング：モデルより重要な作業環境設計の時代
(addyosmani.com)アディ・オスマニ（Addy Osmani）がまとめた「ハーネスエンジニアリング（Harness Engineering）」に関する分析です。彼は、この2年間にわたって業界の関心が「どのAIモデルがより賢いのか」という問いにばかり集中してきたと指摘します。GPTのほうがより整ったコードを書くのか、Claudeのほうが幻覚を起こしにくいのかを延々と比較してきた一方で、実際のコーディングAIの成果はモデルそのものより、そのモデルを取り巻くハーネスによって決まるというのが彼の主張です。ハーネスとは、モデル以外のすべてを含む言葉で、AIに仕事をさせるシステムプロンプト、利用できるツールと外部サーバー、コンテキスト管理ポリシー、実行中に自動で割り込むチェック装置（フック）、安全な実行空間（サンドボックス）、補助AI（サブエージェント）、フィードバックループ、作業が行き詰まったときの復旧フローまでをすべて含みます。Viv Trivedyが「AIエージェント = モデル + ハーネス」という一文でこの概念を定式化し、Anthropicのエンジニアリングチーム、HumanLayer、Simon Willisonらがこの流れを洗練させています。オスマニは、この流れがいまや1つの工学分野として定着したと見ています。
要点を整理すると次のとおりです。
-
ハーネスとは何か モデルだけでは仕事を完遂する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を置くといった形で、一段ずつ締めていきます。たとえばAIがテストコードをコメントアウトしてしまったことがあるなら、次のバージョンのルール文書には「テストはコメントアウトせず、削除するか修正すること」という1行が入り、コミット直前の検査段階にはそのパターンを検出するチェッカーが追加されます。良いルール文書の各行は、過去に起きた具体的な失敗と結び付いていなければならない、というのが核心です。だからハーネスエンジニアリングは、誰かが作ったフレームワークをそのまま持ってくることではなく、自分のコードベースの失敗履歴に沿って育てていく「規律」に近いものです。
-
望む振る舞いから逆算して設計する Vivが提案する最も有用な思考法は、「こういう振る舞いをさせたい → その振る舞いを可能にするハーネス部品は何か」という順序で逆向きに設計することです。ある部品が何の振る舞いのために存在するのかを1行で説明できないなら、その部品は外したほうがよいとされます。具体的には、ファイルシステムとGitは作業内容を長く保持し巻き戻すため、bashとコード実行は何でも試せる万能ツール、サンドボックスは壊しても本体へ影響が及ばない安全な実行空間、メモリファイルとWeb検索・MCPツールは新たに得た知識を蓄積する経路、要約圧縮とツール出力の分離、スキル機能はAIの記憶力の限界を伸ばす装置、そしてRalph loopとプランナー・評価者分離構造は数日単位の長い作業を最後まで引っ張る方法です。
-
コンテキスト劣化（context rot）の問題 AIには一度に読める文章量の限界があり、その限度に近づくほど判断力が目に見えて落ちます。したがってハーネスは、限られた空間をどううまく使うかのための装置群でもあります。第一に、上限が近づいたら古い内容を賢く要約して圧縮します。第二に、2,000行のログのような大きな出力は先頭と末尾だけ残し、本体はファイルに退避して必要なときだけ再読させます。第三に、ツールや指示文を最初からすべて見せず、その作業で本当に必要な瞬間にだけ取り出す「段階的公開」方式を使います。非常に長い作業では、新しいウィンドウで引き継ぎ文書だけを持って最初からやり直すこともあります。Anthropicは「長い作業では要約圧縮だけでは不十分で、構造化された引き継ぎ文書で新しく始める必要がある場合がある」と指摘しています。人間でいえば、新人に業務を引き継ぐ際に整理された文書を渡すやり方に近いものです。
-
長い作業を引っ張るパターン 今日のモデルの弱点の1つは、早く仕事を終わらせたがること、大きな問題を細かく分解できないこと、コンテキストウィンドウが変わると流れが途切れることです。ハーネスはこの弱点を補わなければなりません。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が指摘するもう1つの流れは、ハーネス設計とモデル学習のあいだのフィードバックループです。ハーネスの中で有用なパターンが見つかると、それが標準化され、次世代モデルがそのパターンを基準に学習し、さらにそのモデルの上で新たなハーネスパターンが生まれます。だから「良いハーネス」とは、モデルが学習したそのままのハーネスではなく、自分の作業に合わせて磨き直したハーネスだという結論になります。
- 業界が同じ形へ収束している Claude Code、Cursor、Codex、Aider、ClineといったコーディングAIは、中身のモデルは異なっていても、ハーネスの形は次第に似通ってきています。モデルは違うのにハーネスは似てくるという事実は、この分野がどこへ落ち着きつつあるのかを示すシグナルと読めます。
オスマニの文章は、コーディングAIの競争力がモデル選択よりも、その周囲のハーネス設計に大きく左右されること、そしてハーネスとは一度設定して終わる設定ファイルではなく、失敗履歴に応じて更新され続ける生きたシステムであるという見方を提示しています。モデルが良くなったからといってハーネスが消えるのではなく、扱う問題のレイヤーが一段上へ移ることで、新しいハーネスがその場所を埋めていくことになります。彼が引用したVivの言葉どおり、「良いエージェントを作ることは反復の芸術であり、最初のバージョンがなければ反復もない」というのは、この分野が結局、誰が早く始めてより頻繁に磨き込むかの勝負だという意味に読めます。結局のところ、エンジニアが時間を注ぐべき場所は、話題のモデルを毎回差し替えることではなく、自分の仕事に合ったハーネスを絶えず手入れしながら、モデルが届く天井を一段ずつ引き上げていく作業だ、という結論にまとまります。
11件のコメント
だんだんマーケティング用語ばかりがものすごく増えている感じですね。
でも、プロンプトでAして、Bはしないでと言ったときに、本当にきちんと理解してくれるならこういうアプローチは有効そうですが、AIサーバーの状態によって確率的にプロンプトを実行する場合でも、このアプローチは有効なのでしょうか？
昔、プロンプトでAをしてくれと明確に書いてあるのに、一定の確率でどうしても守られないので、mrkdwn boldで強調してみたり、二度書いてみたり、英語で書いてみたり、首尾呼応の形で書いてみたり、xmlで書いてみたりと、あれこれ試したのですが、それでも一定の確率でプロンプトを無視するんですよね…
私もオスマニの話と似たようなものを全部ぶち込んで
アプリを作っていたところにこの話が出てきたので、ちょっと急いで書いたんですが、
オスマニも口で言うだけじゃなくて
Google Antigravityに自分が話したことを入れてくれていたら、もっとよかったんじゃないかと思います。
カパシもそうですが、もうただ作るつもりはなくて文章だけポンと投げて終わるような振る舞いは、うーん……という感じです！です
https://github.com/hang-in/tunaFlow
モデルとハーネスは、どちらが良いかという観点から一歩引いて、どのモデルにどのハーネスを使うのがより適しているかと考えてみてはどうでしょうか。
モデルが優れていれば、ハーネス設計の負担も軽くなります。
こういうものを適用しても、実際にコーディングする場面ではあまり大きな助けにはならない気がしますね……codex のプランを置いてエージェントを回す程度の難易度の開発だから、ということなんでしょうね（笑）
3行要約
でも、ハーネスは先週まではかなり売り込んでいたのに、今週からは静かですね……Anthropicの迷走とCodex 5.5が優れているからでしょうか……
SDDみたいなものはもうとっくに hype が終わっていて、これからはハーネスなんでしょうね。
ハーネスで少し不思議なのは、学習データには明らかにないのに、モデルが
harnessという概念をすぐ理解していたことです。もともと存在していた単語の意味をそのまま使っているからか、こちらから触れてもいないのに先に「harness を更新します」のような言及までしていました。
中身のない話をもっともらしく語る上級開発者の文章を、さらに分析までした内容ですね（個人的にGoogleが嫌いなので失礼します）。もちろん、現象への理解という観点からのアプローチは良い試みだと思います。