Agent = Model + Harness：自分の仕事の位置付けを変えたフレームワーク

最近、LangChain チームによる「The Anatomy of an Agent Harness」という記事を読みました。閲覧数は 55 万、いいねは 1,500 を超えています。読み終えて最も強く感じたのは、新しい技術を一つ学んだことではありません。ここ数か月で断片的に学んできたことが、一本の線で突然つながったことでした。

この記事では、読んだ過程と、そこから生まれた考えを記録します。

心に刺さった一文

Agent = Model + Harness. If you’re not the model, you’re the harness.

Harness とはモデルの外側にあるすべて、つまりコード、設定、実行ロジックです。裸のモデルは agent ではありません。テキストを受け取り、テキストを返すだけです。harness が状態、tool の実行、feedback loop、実行可能な制約を与えることで、初めて agent になります。

AI application engineering は harness engineering と呼ぶこともできます。 モデルを訓練する仕事でも、アルゴリズム研究でもありません。モデルの知能を取り囲むシステムを構築し、その知能を利用可能で、信頼でき、制御可能なものにする仕事です。

最も美しい点：望む振る舞いから設計を逆算する

記事は「harness にはこれらの機能が必要だ」という一覧を提示しません。方法論はその逆です。

agent にどんな振る舞いを求めるか → それを実現するために harness は何を提供すべきか

推論の流れは次のようになります。

  • agent が実データを操作し、変更を永続化できるようにする → ファイルシステムと Git を提供する
  • 人間がすべての tool を事前定義しなくても agent が自律的に問題を解けるようにする → Bash とコード実行 を提供する
  • agent が安全に実行し、自ら確認できるようにする → sandbox と検証 tool を提供する
  • agent が経験を記憶し、新しい知識へアクセスできるようにする → Memory ファイル、Web Search、MCP を提供する
  • 長い対話でも品質を落とさないようにする → Compaction、Tool Offloading、Skills を提供する
  • 複数の context window にまたがる長期作業を完了できるようにする → Ralph Loop、Planning、Self-verification を提供する

各コンポーネントが存在する理由は「ほかの製品にもあるから」ではなく、「モデルがその振る舞いを本来は実現できないから」です。この逆算方法そのものが、システム設計の思考法として学ぶ価値を持っています。

harness engineering が既存の agent 技術をつなぐ

Context Engineering — 記事には「Harnesses today are largely delivery mechanisms for good context engineering.」という非常に的確な一文があります。私は Anthropic の Contextual Retrieval、Compaction 戦略、Structured Note-taking などを長い時間をかけて学んできました。いまでは、そのすべてが harness の context 管理レイヤーに属すると分かります。Compaction は context rot を抑え、tool call offloading は大きな出力が context を占有するのを防ぎ、skills の progressive disclosure は初期ロード量を制御します。いずれも、希少な資源である context を守る技術です。

ReAct と Agent Loop — 記事は ReAct loop を主流の agent 実行モデルと位置付けたうえで、harness が事前定義された tool しか実行できないという限界を指摘します。そこで Bash と code execution を汎用 tool として与え、モデル自身に tool を作らせます。これは、hey!stalker のアーキテクチャを学んだときに考えた ReAct + Mem0 の設計とちょうど対応しています。

AGENTS.md と Memory — 一例は、Codex の振る舞いを導くグローバルな AGENTS.md です。記事は AGENTS.md を memory file standard の例として明示しています。harness は agent の起動時にこのファイルを注入し、agent は発見したことを書き戻して session をまたいだ継続学習を実現できます。Context Hub（chub）の annotation も同じ発想です。agent が文書の問題を見つけて記録すれば、次回はその注意事項が自動的に添えられます。

MCP Server 開発 — 記事は Tools、Skills、MCPs を harness の中核要素として挙げています。MCP は本質的に、harness が外部へ能力境界を広げるための標準化されたインターフェースです。

最も考えさせられた点：Model と Harness の共進化

記事の最後では、これまで考えたことのなかった現象が説明されています。現在の Claude Code や Codex のような製品では、モデルが harness と一緒に post-train されています。

そこには循環が生まれます。有用な harness primitive を発見する → 製品内で標準化する → 新しい harness を使って次世代モデルを訓練する → モデルがその harness 内でさらに強くなる、という循環です。

一方で、モデルが特定の harness に overfit する副作用もあります。記事は Terminal Bench 2.0 の例を挙げています。同じ Opus 4.6 でも、Claude Code の harness では、ほかの harness より大幅に低いスコアになります。

ここから、何度も考えた問いが生まれました。モデルが強くなるほど、harness engineering は不要になるのでしょうか。

私の結論は、消えることはないが、重心は上へ移り続ける というものです。

過去二年を振り返ると、2024 年初頭には、会話履歴を保持する while loop をモデルの外側に置くだけでも価値ある harness engineering でした。いまではすべての製品に組み込まれています。それでも harness engineering が減ったわけではなく、扱うレイヤーが上がりました。現在の主戦場は compaction、multi-agent orchestration、Ralph Loop です。さらに先では、数百の agent を並列に編成すること、agent が自分の trace を分析して harness 層の失敗を修復すること、タスクごとに tool と context を動的に組み立てることが課題になるでしょう。

これは Java Web 開発の進化に似ています。15 年前は servlet を手書きし、thread pool を手動設定していましたが、Spring が吸収しました。次に Spring XML とデプロイを手作業で管理していましたが、Spring Boot が吸収しました。その後は container orchestration を手動管理し、Kubernetes が吸収しました。インフラエンジニアリングは消えたでしょうか。消えていません。現在のエンジニアは service mesh、GitOps、platform engineering を考えています。抽象度は上がりましたが、「中核能力を囲むシステムを構築する」という需要は残り続けます。

もう一つ、直感に反する点があります。モデルが強いほど、harness 最適化の限界効果はむしろ大きくなります。 弱いモデルは、どれほど良い harness を与えても複雑な仕事を完了できません。しかし強いモデルでは、良い harness と悪い harness の差が非常に大きくなります。初級者と上級者に同じ開発環境を与えると、上級者の方が良い環境から得る生産性の増幅効果が大きいことに似ています。同じモデルが harness の変更だけで Top 30 から Top 5 に上がるという事実が、すべてを物語っています。

得られた示唆

system prompt の設計、context engineering の学習、MCP server の開発、AGENTS.md の構築、RAG pipeline の研究は、すべて harness engineering という枠組みに入ります。

重要なのは、現在の実装を暗記することではなく、望む振る舞いからシステムを逆算するという harness engineering の 思考法 です。具体的な compaction アルゴリズムは変わっても、「context は希少な資源であり管理が必要だ」という認識は変わりません。現在の Ralph Loop がモデル本体に吸収されることはあっても、長期タスクを context window 間で引き継ぐ問題は、今後も長い間 harness 層で解く必要があります。

「AI agent のアーキテクチャをどう理解しているか」と聞かれたなら、Agent = Model + Harness という式と、六つの主要コンポーネントを振る舞いから逆算する考え方が、私の最も明快な答えです。

原文：The Anatomy of an Agent Harness、LangChain チームより。