モデルの賢さを競う時代は、終わりを告げようとしている。
2026年現在、AI業界の焦点は「モデルの知能（Intelligence）」から「システムの耐久性（Durability）」へと完全にシフトした。静的なリーダーボード上でModel AがModel Bを0.5%上回ったところで、実務においてそれが何を意味するだろうか？数百ステップに及ぶ複雑なタスクを、エラーなく、指示を逸脱せずに完遂できなければ、その知能はただの「賢い役立たず」に過ぎない。
これまで我々は、モデル単体のベンチマークスコアに一喜一憂してきた。しかし、トップティアのモデル間の差が誤差範囲に縮小した今、真の差別化要因として浮上してきたのが「Agent Harness」である。今回は、Google DeepMindのPhillipp Schmid氏の論考をベースに、このAgent HarnessがなぜAI開発のOS（オペレーティングシステム）となり得るのか、そしてRich Suttonが提唱した「Bitter Lesson（苦い教訓）」がどのように現在のエージェント開発に突き刺さるのかを分析する。
Agent Harnessとは何か：FrameworkからOSへ
まず言葉の定義を明確にしておく必要がある。Agent Harnessとは、AIモデルを取り囲み、長時間実行されるタスクを管理するためのインフラストラクチャである。LangChainやLlamaIndexといったAgent Frameworkが「ツールを作るためのビルディングブロック」を提供するものだとすれば、Agent Harnessはそれらを統括する「オペレーティングシステム（OS）」に近い。
この概念をコンピュータ・アーキテクチャに例えると非常に分かりやすい。
- Model: CPU（純粋な演算処理能力）
- Context Window: RAM（限られた揮発性の作業メモリ）
- Agent Harness: OS（コンテキストやツールを管理し、標準ドライバを提供する基盤）
- Agent: Application（OS上で動作する固有のユーザーロジック）
開発者が個別に実装していたプロンプト管理、ツール呼び出しのハンドリング、ライフサイクル管理といった「面倒だが必須な機能」は、すべてHarnessが引き受ける。これにより、開発者はOSを一から作るという苦行から解放され、アプリケーション（Agent）独自のロジック構築に専念できるというわけだ。
H&Mのバーチャルアシスタントが自律的に70%のクエリを解決したり、シンガポール政府の「Ask Jamie」がコールセンター業務を半減させたりといった成功事例の裏側には、単に賢いモデルがあるだけではない。長期的な文脈を維持し、確実にツールを行使させるための堅牢なHarnessが存在している。
Context Engineeringという名のメモリ管理
Agent Harnessの最大の役割の一つは「Context Engineering」である。どれだけContext Windowが拡大しようとも、エージェントが生成する膨大なログやツール出力ですぐに溢れかえってしまう。無尽蔵にメモリがあるという幻想は捨て去るべきだ。
ここでHarnessは、熟練のOSのようにメモリ管理を行う。
- Offloading & Filesystem: すべての会話履歴をContextに乗せるのではなく、ファイルシステムに逃がす。
- Compaction & Summarization: 冗長なログを圧縮し、重要な決定事項だけを要約して残す。
- Isolation: サブエージェントにタスクを切り出し、親エージェントのコンテキスト汚染を防ぐ。
これらの戦略は、いわば現代版のガベージコレクションや仮想メモリ管理だ。Claude Codeのような汎用Harnessが登場しつつあるが、特定の垂直領域においては、高度に最適化されたCLIツール自体がHarness化していく流れは不可避だろう。
ベンチマークの崩壊と「Bitter Lesson」
従来のベンチマーク（SWE-Benchなど）は、短距離走のタイムを計測するには適していたが、マラソンの完走能力を測るには無力だった。50回目のツール呼び出しの後に、モデルが当初の指示を覚えているか？論理的な整合性を保てているか？今のリーダーボードは、この「信頼性（Reliability）」をスコアリングできていない。
ここで、AI研究者Rich Suttonの「Bitter Lesson（苦い教訓）」が重くのしかかる。「計算能力を活用する一般的な手法は、長期的には人間が手作りした知識やルールを常に凌駕する」という教訓だ。
エージェント開発の現場では、まさにこのBitter Lessonが繰り返されている。 LangChainは1年で3回もアーキテクチャを再構築し、Vercelはエージェントツールの80%を削除することで逆に性能を向上させた。これは何を意味するか？モデルが賢くなるたびに、我々が苦労して作り込んだ複雑な制御フロー（Human-coded knowledge）は不要になり、むしろ邪魔になるということだ。
2024年に複雑なパイプラインが必要だったタスクも、2026年にはシンプルなプロンプト一つで解決できるかもしれない。故に、Harnessに求められるのは「重厚長大さ」ではなく、昨日のロジックを今日捨てられる「可動性」である。
開発者へのアドバイスは明確だ。 “Build to Delete”（捨てるために作れ）。
Harnessが「学習データ」になる未来
今後の展望として、推論環境（Harness）と学習環境の融合が進むだろう。Harnessは単なる実行環境ではなく、最強のデータ収集装置となる。
モデルが長時間のタスク中にいつ指示から逸脱したか（Model Drift）、どこで推論を誤ったか。Harnessはこの「失敗の軌跡」を詳細に記録できる。このデータを次のモデルのトレーニングにフィードバックすることで、より「疲れない」「飽きない」モデルを作ることが可能になる。
つまり、今後の競争優位性は、どれだけ巧みなプロンプトを書けるかではなく、Harnessを通じてどれだけ質の高い「実世界の実行ログ」を蓄積できるかにかかっている。GoogleやOpenAIといった巨大プレイヤーだけでなく、独自のHarnessを持つ企業だけが、このデータ・フライホイールを回すことができるのだ。
開発者は、複雑なコントロールフロー構築という「小細工」に囚われるべきではない。堅牢なAtomicなツールを用意し、あとはモデルとHarnessに計画を委ねる。そして、新しいモデルが出たら、古いコードを躊躇なく削除する。その潔さこそが、2026年のAI開発における生存戦略となるだろう。