Anthropic 社内対談：Harness という外殻の手順、いま解体が進んでいる
- モデルの外側を包むコード（harness）が薄くなりつつあります。そこに書き込まれているのは「モデルには何ができないか」という前提で、モデルが強くなるほど期限切れになります
- 薄くなった上に「どの戦法を使うか」を決める層が生えてきました。Anthropic 自身のブログではこれをメタ harness と呼んでいます
- Agent の権限モデルも変わります。「このユーザーに何ができるか」から「この Agent はこの区画で何ができるか」へ
- 企業が投資対効果を測る順番は、個人 → チーム → 部門横断プロセス。いきなり一番難しい層から手をつけないこと
- 最も踏みやすい落とし穴は、全員が単独で動けるようになった結果、かえって方向が揃わなくなること
- プラットフォーム側の着地点は outcome。渡すのは手順ではなく、合格基準です
まず外側のフレームを解体する
Anthropic が公開した対談動画『Building the future of agentic infrastructure』、約 16 分。登壇は 2 名。Angela は顧客側で見えている使われ方と harness の変遷を、Caitlin は Managed Agents という製品ラインの担当として Agent の身元、エンジニアリングチーム、プラットフォームの方向性を語ります。
半年前の Claude プラットフォームは、主に推論インターフェースでした。テキストを投げ込み、結果を取り出す。この半年で、そこに 2 層の面倒が乗りました。インフラと、harness エンジニアリングです。
モデル自身にできるのは 1 つだけ。テキストを読み、テキストを吐くことです。自分でファイルを開くことも、コマンドを走らせることも、データベースを引くこともできません。harness とは、モデルの外側に被せる一式すべてです。吐き出された言葉を「あるツールを使いたがっている」と解釈し、実際にツールを走らせ、結果を戻してまた考えさせる。コンテキストが一杯になれば圧縮し、途中で落ちればチェックポイントから再開させる。
モデルがエンジンなら、harness はエンジン以外の車体すべて。ハンドル、トランスミッション、燃料計、シートベルトです。
ただし harness は大雑把な呼び方で、中身の性質はまるで違います。分解すると 4 種類です。
前の 3 つはモデルが本質的にできないこと。モデルがどれだけ強くなろうと関係なく、10 年後も誰かがやります。4 つ目だけが違います。モデルの代わりに判断する層であり、それが存在した唯一の理由は、モデル自身がうまく判断できなかったことだからです。
数か月前の定石は、まさにこの 4 つ目を分厚く積むことでした。業務を箱に切り分けて連結し、必ず A を通し、A が条件を満たして初めて B へ。最後には非常に複雑な網になります。当時はそれで理由がありました。モデルの不確実性は今よりずっと厄介で、標準作業手順で縛る必要があったのです。
代償は脆さです。しかも向きが逆でした。欲しかったのはモデルの知能なのに、オーケストレーションがそれを枠にはめ、Agent は期待した力を出せません。
具体例：死荷重に変わったパッチ
Anthropic のエンジニアリングブログに、抽象論より直感的な事例が残っています。Sonnet 4.5 には癖がありました。タスクの途中でコンテキスト上限が近づくと、雑にまとめに入ってしまう。エンジニアチームはこれを「コンテキスト不安」と呼びました。そこで harness にパッチを足し、コンテキストのリセットで対処したのです。
その後 Opus 4.5 に切り替えると、この癖は自然に消えました。パッチは彼らの原文どおり dead weight、死荷重になりました。
これが「harness が薄くなる」の意味のすべてです。あの層には当時なりの理屈がありました。モデルが進歩すれば、その尻拭い部分は保険から足手まといへ変わります。Anthropic 自身の説明では、harness に書き込まれているのは「モデルには何ができないか」という前提であり、前提はモデルの進化とともに期限切れになる。だから繰り返し疑い直す必要があります。