AI Agentの「Harness」とは何か
この資料の日時
元資料の日付と、その本文が公に存在した確認日時は別の記録です。
この資料を根拠にした分析カード（試験中）: Agentの成果を外部状態で確かめ、構成の寄与を分ける
出典・更新履歴・検証情報
この保存版のデータを照合するための情報です。元記事の初公開日とは区別しています。
- データセットの版
- 2026.10.01.2
- 記事内容のSHA-256
56b8df82fb5c2aeaad003da52d4d61f78c4b4ede7ea5fefad0d52c16a68aa49c- 保存版のSHA-256
5230556577d816e70f77e45856a8e0606a32176ea21f9bfc954362c292f0b3be
外部証明の最終検査結果は詳細を開くと表示します。
AI Agentの「Harness」とは何か
#モデルの外側で知能を作る仕組みは、やがてAgentic OSへ向かうのか
#2026年9月26日時点の研究・公開実装をもとに整理しています。
#AIの性能について語るとき、これまでは「どのモデルが一番賢いか」が中心でした。
#しかしAI Agentが実際にコードを書き、ブラウザを操作し、研究を行い、3Dソフトを使い、何時間・何日も仕事を続けるようになると、モデルそのものだけでは性能を説明できなくなります。
#同じモデルでも、ある環境では驚くほど仕事が進み、別の環境では何度も同じファイルを読み直し、Subagentを大量に起動し、利用枠を急速に消費することがあります。
#この違いを生む中心にあるのが、Harness（ハーネス）です。
#OpenAIは現在、Harnessを「モデルとツールの実行ループを処理し、AgentのSessionを維持するもの」と説明しています。AnthropicもHarnessを、Claudeを呼び出してTool Callを適切な実行環境へ振り分けるループとして扱っています。(OpenAI Developers)
#ただし、現在のHarnessは単なる「LLMをToolにつなぐコード」ではありません。
#Memory、Skill、Environment、Sandbox、Subagent、Context圧縮、Verifier、Model routingまで含むようになり、徐々に小さなOperating Systemに近づいています。
#この記事では、その仕組みを一番基本から見ていきます。
#1．そもそもAI Agentとは何か
#まずChat型AIとAgentを分けます。
#普通のChat AIは、おおむね
#質問 ↓ Model ↓ 回答
#です。
#一方Agentは、
#目標 ↓ 考える ↓ 行動する ↓ 外部世界から結果を受け取る ↓ 考え直す ↓ 次の行動 ↺
#というループを持ちます。
#例えば、
#「このGitHubリポジトリのバグを直して」#
と言われた場合、
#Issueを読む
↓
コード検索
↓
ファイルを読む
↓
仮説を立てる
↓
コード編集
↓
テスト実行
↓
失敗
↓
原因調査
↓
再編集
↓
テスト成功まで動くのがAgentです。
#この「モデルを何度も呼びながら、外部環境で仕事を進める部分」がHarnessの原型です。
#2．Harnessという言葉
#Harnessという英単語には、本来「馬具」「制御するための装具」という意味があります。
#Software Engineeringでは昔からTest Harness（テストを自動実行する仕組み）のように使われていました。
#LLM AgentにおけるHarnessは、
#モデルを仕事のできるAgentとして動かすための外側の制御システム#
と考えると分かりやすいです。
#概念的には、
#です。
#Modelが「頭脳」なら、
#Harnessは「神経・仕事の進め方・管理機構」、
#Environmentは「実際に仕事をする場所」です。
#3．まず覚えておきたい基本用語
#この記事では多くの専門用語が登場します。
#最初に関係を整理すると、かなり理解しやすくなります。
#この各要素をどう設計するかによって、同じModelでも性能が大きく変わります。
#4．最小のHarnessは驚くほど単純
#極端な例ならHarnessは100行も必要ありません。
#擬似コードでは、
#history =
while True: response = model(history, tools)
#if response.finished: break
#observation = execute(action)
#history.append(response) history.append(observation)
#だけでもAgentになります。
#内部では、
#Model ↓ Action ↓ Environment ↓ Observation ↓ Model ↺
#を繰り返しています。
#実際、現在のmini-SWE-agentはAgent classを約100行規模まで単純化し、ほぼBashだけをToolとして使いながら、SWE-bench Verifiedで74%超を報告しています。開発チーム自身も、2024年のSWE-agentでは特殊なToolやInterfaceを重視していたが、Modelが強くなった結果、より単純なHarnessでも高い性能が出るようになったと説明しています。(GitHub)
#これは非常に重要です。
#Harnessは複雑なら強い、というものではありません。
#5．現代的なHarnessはいつ生まれたのか
#現在のHarnessが一つの論文から突然生まれたわけではありません。
#複数の研究が段階的に積み重なっています。
#2022年：MRKL
#2022年5月のMRKL Systemsは、大規模言語モデルだけですべてを解こうとせず、
#LLM + 外部Knowledge + 専用Reasoning Module#
を組み合わせる「Systems approach」を提示しました。(arXiv)
#つまり、
#LLMだけ
#ではなく、
#LLM + Calculator + Search + Database + その他Module
#という考え方です。
#現在のTool-using Agentの思想にかなり近いものです。
#6．2022年：ReActが大きな転機になる
#Harnessの歴史で最も重要な転機の一つがReActです。
#ReActは、
#Reasoning + Acting
#の略です。
#それ以前は、
#考える
↓
回答と、
#環境で行動する
#が別々に研究されることが多かった。
#ReActでは、
#Thought
↓
Action
↓
Observation
↓
Thought
↓
Action
...を一つのループにしました。
#ALFWorldとWebShopでは、当時の模倣学習・RL系手法に対して絶対成功率でそれぞれ34ポイント、10ポイント改善しています。(arXiv)
#現在のCoding Agent、Browser Agent、Research Agentのほとんどは、形を変えながらもこの基本構造を持っています。
#7．2023年：Toolを「いつ使うか」を学ぶ
#Toolformerでは、
#どのAPIを いつ呼び どんな引数を渡し 結果をどう利用するか#
をModel自身に学習させました。(arXiv)
#これは現在のTool Useへ直接つながります。
#AgentにCalculatorを渡すだけでは足りません。
#Agentは、
#「ここでは自分で計算せずCalculatorを使うべきだ」#
と判断できる必要があります。
#つまりHarnessとModelの境界にも学習対象が生まれたわけです。
#8．2023年：Memoryが入ってくる
#ReflexionではModel Weightを変更せず、
#失敗
↓
なぜ失敗したか文章でReflection
↓
Memoryへ保存
↓
次回Contextへ戻すことでAgentを改善しました。(arXiv)
#これは**Verbal Reinforcement Learning（言葉による強化学習）**と呼ばれました。
#Weightは、
#のままです。
#しかしMemoryが、
#になるので、行動が改善します。
#つまり、
#Weightを変えなくてもAgentは経験から学べる#
ことが明確になりました。
#9．Generative Agentsと長期Memory
#Generative Agentsでは、Agentの経験を**Memory Stream（記憶の流れ）**として保存し、
#Experience
↓
Memory
↓
Reflection
↓
Planningに利用しました。
#25体のAgentを仮想的な街で生活させ、過去の出来事を記憶し、反省し、計画に利用するarchitectureを示しました。(DOI)
#現在のPersonal Agentの長期Memory設計の祖先の一つと考えられます。
#10．VoyagerとSkill Library
#2023年のVoyagerはさらに重要です。
#Minecraft内で、
#- Automatic Curriculum：自動的に次の課題を作る
- Skill Library：成功した行動を実行可能なSkillとして保存
- Iterative Prompting：実行結果・Error・自己検証をもとに改善
を組み合わせました。
#WeightをFine-tuneせず、Skillを増やすだけで継続的に能力を伸ばしています。従来手法より3.3倍多くunique itemを獲得し、一部の技術進行では最大15.3倍速く到達しました。(arXiv)
#現在の、
#skills/
├ deploy
├ research
├ blender
└ codingという発想の非常に分かりやすい先祖です。
#11．Multi-Agentへ
#2023年のAutoGenでは、複数のAgentが会話しながら仕事をするframeworkが体系化されました。
#例えば、
#Planner ↓ Coder ↓ Reviewer ↓ Tester
#です。
#Human、LLM、ToolをそれぞれAgentとして組み合わせられるarchitectureを提示しました。(arXiv)
#ここからHarnessは、
#一つのAgent loop#
だけでなく、
#Agent組織のOrchestration#
を管理するようになります。
#12．2024年：EnvironmentとInterfaceが主役になる
#2024年のSWE-agentは重要な問いを提示しました。
#「Agentに人間向けComputer Interfaceをそのまま使わせるのが最適なのか？」#
です。
#そこで提案されたのが、
#ACI：Agent-Computer Interface
#です。
#日本語なら、
#AI Agent向けコンピューター操作インターフェース#
です。
#SWE-agentは、Language Modelを新しい種類のComputer Userと考え、Modelに使いやすいFile編集・Repository移動・Test実行Interfaceを設計しました。SWE-benchでpass@1 12.5%を達成し、Interface設計がAgent性能へ直接影響することを示しました。(arXiv)
#13．Environmentとは何なのか
#Environmentを単なる「アプリ」と考えると狭すぎます。
#例えばCoding Agentなら、
#Git Repository Filesystem Compiler Tests Shell Dependencies Network
#全部がEnvironmentです。
#Blender Agentなら、
#Scene Objects Meshes Materials Nodes Camera Timeline Python API GUI Renderer
#まで含みます。
#数学的には、
#くらいに考えられます。
#つまり、
#Agentが存在し、観察し、行動できる「世界」#
です。
#14．Action Spaceをどう設計するか
#Agentが可能な行動の集合を**Action Space（行動空間）**と言います。
#例えば、
#mouse_move click keypress scroll
#だけでBlenderを操作させることもできます。
#しかし机を作るだけで100回以上Actionが必要になるかもしれません。
#一方、
#create_mesh() set_material() render()
#のような高level Toolがあれば数回で済みます。
#ここで理想なのは、
#つまり不要な選択肢を減らしながら、
#させることです。
#Actionの種類は少なく、1回のActionが意味の大きい処理をする。
#これが良いACIの一つの条件です。
#15．Environment研究を進めたBenchmark
#OSWorldはUbuntu、Windows、macOS上の実Softwareを使う369のComputer Taskを構築しました。
#初期評価では人間が72.36%以上成功した一方、最良Agentは12.24%にとどまり、GUI groundingと操作知識が大きな課題でした。(arXiv)
#AppWorldは9つのアプリ、457 API、750 taskから成る仮想世界を作り、単純なAPI Callではなく複数Applicationを跨いだ仕事を評価しました。GPT-4oでも通常task約49%、challenge約30%でした。(arXiv)
#τ-benchでは最終Database Stateまで検証し、当時のGPT-4oでも成功率50%未満、retailでpass^8が25%未満でした。(arXiv)
#つまりBenchmarkも、
#「正しい文章を書いたか」#
から、
#「現実の世界を正しい状態へ変えられたか」#
を見るようになっています。
#16．ところが「複雑なHarnessほど強い」とは限らない
#Agentlessは2024年、
#本当に複雑なautonomous Agentが必要なのか#
と問い直しました。
#Localization → Repair → Validationという単純な3段階だけで、当時のSWE-bench Liteで32%成功、平均$0.70という結果を報告しました。(arXiv)
#さらに現在のmini-SWE-agentは、ほぼBashだけという非常に小さな構造で高い性能を出しています。(GitHub)
#ここから重要な原則が出てきます。
#Harnessとは機能を増やす競争ではありません。
#Modelが自分でできることと、Runtime側で固定すべきことの境界を探す仕事#
です。
#17．Harnessの主要構成
#現在の高度なHarnessは、おおむね次の層を持っています。
#User Goal ↓ Task / Intent Analysis ↓ Context Builder ↓ Model Router ↓ Model ↓ Planner / Orchestrator ↓ Tool Router ↓ Permission / Sandbox ↓ Environment ↓ Observation ↓ Verifier ↓ Memory / Skill / State ↓ 次のModel Call
#特に重要なのは、
#Context、Tool、Environment、Memory、Verification
#です。
#18．Harnessはどう作るのか
#0から作るなら、最初からMulti-Agentを作る必要はありません。
#合理的な順序は次のようになります。
#- Environmentを決める。 CodingならRepo＋Shell＋Test、WebならBrowser、3DならBlenderなど。
- Actionを少なくする。 最初はBash一つでも構わない。
- ReAct Loopを作る。 Model → Action → Observationだけ。
- Raw Trajectoryを全部保存する。 Prompt、Tool Call、Error、Diff、Test resultを残す。
- Verifierを作る。 Agent自身の「完成しました」を信用せず、Testやworld stateで確認する。
- SandboxとPermissionを入れる。
- 長時間化して初めてCompaction・Memoryを入れる。
- 本当に必要になってからSubagentを追加する。
- 失敗Traceを見てACIを改善する。
- 最後にRLや自動Routingを導入する。
Anthropicも実運用経験から、HarnessにはModelができないことについての仮定が埋め込まれるため、その仮定はModelが進化すると古くなると指摘しています。Opus 4.5では、それ以前のModel向けに必要だったContext Resetが不要になった例も紹介されています。(Anthropic)
#19．Skillsとは何か
#Skillsは、
#「この仕事をどうやるか」を再利用可能にした仕事の型#
です。
#AnthropicのAgent Skillsでは、SkillはSKILL.mdを中心としたFolderで、Instructions、Scripts、Resourcesなどをまとめられます。起動時にはSkillの名前とDescriptionだけを読み、必要になったときに詳細をContextへ展開する**Progressive Disclosure（段階的開示）**を採用しています。(Anthropic)
#例えば、
#Blender Skill
├ SKILL.md
├ mesh\_validate.py
├ material\_setup.py
├ render\_check.py
└ examples/です。
#Toolが「手」なら、
#Skillは手の使い方です。
#20．MemoryとSkillは違う
#Memoryは、
#「過去に何が起きたか」#
です。
#Skillは、
#「そこから一般化した、次回のやり方」#
です。
#例えば、
#Memory: 前回Bevel前にScaleをApplyしなかったため壊れた
#から、
#Skill: Bevel前にTransform Scaleを検査し、 必要ならApplyする
#へ抽象化できます。
#21．問題は「要約すると情報を捨てる」こと
#ここから最新研究へつながります。
#従来のAgentはTask終了時に、
#大量Trajectory
↓
AIがSummary
↓
SKILL.md
↓
Raw dataをほぼ使わないとなりがちでした。
#しかし未来のtaskが分からない時点で、
#何が重要で、何が不要か#
を完全に判断するのは難しい。
#この問題を正面から扱ったのが2026年9月のJust-in-Time Memoryです。
#22．Just-in-Time Memoryとは何か
#Just-in-Time Memory、略してJitMemは、
#Memoryを保存時ではなく、利用時に作る#
考え方です。
#従来：
#Task A終了
↓
Summaryを作る
↓
保存
↓
未来のTask Bで利用JitMem：
#Task A
↓
Raw Trajectoryを保持未来のTask B
↓
Task Bに関連するRaw Traceを取得
↓
Task Bを知った状態でCuratorが要約
↓
今回専用Memoryです。
#ALFWorld、WebShop、τ²-benchで、強いwrite-time memory baselineに対し成功率をそれぞれ+16.2、+16.3、+3.9ポイント改善しています。(arXiv)
#これはかなり大きな転換です。
#23．Skillすら「固定ファイル」でなくなる可能性
#JitMem的な考えをさらに進めると、
#skills/blender.md
#を永遠に使う必要すらありません。
#例えば、
#Raw Experience
├ 失敗 #182
├ 成功 #239
├ Human Correction #451
├ Blender Manual
└ Tutorial #72から、
#現在の
#「透明素材がおかしいので修正」#
というTaskに合わせて、
#Just-in-Time Blender Skill
#をその場で生成する。
#Skillが保存物ではなくCompile結果になるわけです。
#24．未知のEnvironmentでAgentはどう学ぶのか
#ここが非常に面白い領域です。
#Agentが初めてあるCAD Softwareを使うとします。
#最初は、
#どこにExportがある？ Constraintは？ Mesh modeは？ APIは？
#を知りません。
#人間なら、
#- Manual
- Tutorial動画
- 教本
- 他人のProject
を見ます。
#AIも同じことができます。
#未知Environment
↓
Manual / Tutorial / Video
↓
操作を観察
↓
Computer Useで試行
↓
成功/失敗
↓
Trajectory保存です。
#25．経験の保存先は一つではない
#ここで経験を4段階に分けられます。
#① Context 今回だけ覚える
#② Memory / Skill 次回も外部情報として使う
#③ Adapter / LoRA的なWeight差分 特定分野の能力として圧縮する
#④ Base Model 大量の検証済み経験を本体へ統合
#現在実用化が最も進んでいるのは①と②です。
#③の「個人が好きなタイミングで能力差分をWeightへ焼いて切り替える」仕組みは技術的には可能性がありますが、Frontier APIで一般ユーザー向けに提供されている標準機能ではありません。
#当面は、
#Skill + Memory + Script + Tool definition#
という外付け形式が先行すると考える方が自然です。
#26．将来的なSkill Package
#将来は例えば、
#Blender Skill Package
├ Instructions
├ Scripts
├ Tool schema
├ Tutorials
├ Successful trajectories
├ Failed trajectories
├ Environment metadata
├ Tests
└ Optional model adapterのような形式になり得ます。
#これならBase Modelが世代交代しても、
#Raw ExperienceやSkillから新Model向けのAdapterを再生成できます。
#つまり、
#Raw Experience
↓
Portable Skill
↓
Model-specific AdapterというCompilerのような構造です。
#27．人間から学んだ後、AI同士で上達できるか
#これは囲碁や将棋との比較が非常に面白いところです。
#最初は、
#Human Tutorial Human Demonstration Human Correction
#から基礎を学ぶ。
#その後、
#AIが問題を作る
↓
AIが解く
↓
Verifierが判定
↓
RL
↓
もっと難しい問題を作るへ進めます。
#すでに初期研究があります。
#28．Tool-R0：Tool利用版Self-Play
#2026年のTool-R0では、
#Generator AgentとSolver Agentを同じBase LLMから作ります。
#Generatorは、
#Solverがギリギリ解けそうなTask#
を作る。
#SolverはToolを使って解きます。
#既存datasetを使わないzero-data self-playで、Base modelに対してTool-use benchmarkで92.5%のrelative improvementを報告しています。(arXiv)
#つまり、
#問題を作るAI ↕ 問題を解くAI
#が互いを強くする。
#囲碁のSelf-playにかなり近い構造です。
#29．SPADE：EnvironmentそのものをAIが作る
#SPADEではさらに進みます。
#一つのLLMが、
#Environment Designer
#と、
#Reasoning Agent
#の二役を担います。
#Environment Designerは、reset()とstep()を備えた実行可能な訓練Environment自体をコードとして生成します。
#そしてAgentが強くなればEnvironment側も難しくなります。
#30B規模では固定Environment baselineに対して8 Benchmark平均+5.3、Tool-useではBFCL-v4 multi-turn +5.7、ACEBench-Agent +13.9を報告しています。(Searcharxiv)
#つまり、
#Agentが強くなる
↓
Training worldも強くなる
↓
Agentがさらに強くなるという循環です。
#30．ただし仕事は囲碁より難しい
#囲碁には大きな利点があります。
#勝てば1。
#負ければ0。
#Rewardが明確です。
#しかし、
#「良い3Dモデルを作れ」#
では、
#- Geometry
- Topology
- Style
- Realism
- Polygon数
- Performance
- Human preference
が絡みます。
#つまり一番難しい問題は、
#です。
#そのためAgent時代にはVerifierが極めて重要になります。
#31．SAGE：SkillとRLを接続する
#2026年ACLのSAGEでは、AgentがTaskを行うたびにSkill LibraryへSkillを蓄積し、それをRLへ組み込みました。
#AppWorldで、
#- Scenario Goal Completion +8.9%
- Interaction Step −26%
- Generated Token −59%
を報告しています。(DOI)
#ここが非常に重要です。
#RLは、
#より大量に考えさせて強くする#
だけではありません。
#過去のSkillを使って、より少ないStepで仕事を終える#
方向にも使えます。
#32．Agentic RLとは何か
#Agentic RLは、
#Agentが実際にEnvironmentで仕事したTrajectoryを使ってPolicyを強化するRL#
です。
#例えば、
#Issue
↓
Search
↓
Edit
↓
Test
↓
Fail
↓
Retry
↓
Successという一連のTrajectoryを学習します。
#2026年のAgent Lightning v1.0は、これをさらにHarnessへ直接接続して、
#Harnessed Agentic RL
#と呼んでいます。
#Deploy時に使うHarness自身がEnvironment Interaction Loopを持ち、そのLLM request/responseをTrainerが観察してRLします。
#Qwen3.5-9Bでは、6K training examplesでSWE-bench Verifiedを41.8%から56.4%へ改善しました。(arXiv)
#これは、
#実際のHarnessがそのまま学習環境になる#
ことを意味します。
#33．AI Software側も変わっていく
#ここまでAgent側を見てきましたが、Software側にも変化が必要です。
#現在は、
#Human
↓
GUI
↓
Softwareが中心です。
#将来は、
#Human UI ↘ Application Core ↗ AI Interface
#になる可能性があります。
#Webでは既にWebMCPという提案が進んでいます。
#Webサイト側が予約・購入・入力などの操作をstructured toolとしてAgentへ公開し、曖昧なmouse操作より高速・正確・安定して操作させる方向です。(Chrome for Developers)
#34．MCPとは何か
#MCPはModel Context Protocol。
#日本語なら、
#AIと外部Software/Dataをつなぐ共通接続規格#
くらいに考えればよいでしょう。
#Anthropicが2024年11月にOpen Standardとして公開しました。
#各Data Sourceごとに独自Connectorを書く問題を、共通Protocolで解決することを狙っています。(Anthropic)
#簡単に言えば、
#Agent ↓ MCP ↓ GitHub Database Blender SaaS etc.
#です。
#35．A2Aとは何か
#MCPが、
#Agent → Tool
#なら、
#A2A、つまりAgent2Agent Protocolは、
#Agent → Agent
#を標準化しようという方向です。
#Googleは2025年に、異なるVendorやFrameworkで構築されたAgent同士を協調させるProtocolとしてA2Aを発表しました。(Google Developers Blog)
#将来的なAgentic OSでは、
#MCP = 外部Toolへの接続 A2A = 他Agentへの接続
#という形が分かりやすいでしょう。
#36．AIにとっての「感覚器官」
#人間はSoftwareを見るとき、
#- 画面
- 文字
- 音
- mouse
- keyboard
を使います。
#しかしAgentにとって理想の感覚器官は違います。
#例えばAI向けSoftwareは、次のようなSensorを持つ可能性があります。
#ChromeのAgentic BrowsingではAccessibility TreeをAgentの主要なmachine-eye viewとして扱い、WebMCPによるstructured tool公開も検査しています。(Chrome for Developers)
#37．「Screenshotを見る」より意味構造を見る
#例えば人間には、
#青い四角
#にしか見えなくても、
#AIには、
#type = Button name = Purchase enabled = true
と渡した方が正確です。
#これを**Semantic Interface（意味付きInterface）**と考えるとよいでしょう。
#CodingではLSPが既に、
#- Go to Definition
- Find References
- Autocomplete
などの意味付きCode情報をEditorへ提供しています。Agentから見ても非常に使いやすい情報源です。(Microsoft GitHub)
#3DではOpenUSDがGeometry、Material、Lighting、Physicsなどを一つのScene Graphとして扱えます。(OpenUSD)
#38．Agentの「体性感覚」
#もう一つ重要なのが、
#Proprioception（自己位置・身体状態の感覚）
#です。
#Blenderなら、
#mode = EDIT
です。
#GUI Screenshotだけだと、
#自分が今何Modeなのか#
を誤認することがあります。
#Software側が内部Stateをmachine-readableに渡せれば、この種のErrorを大きく減らせます。
#39．毎回世界全部を見る必要はない
#Sceneに10万Objectがあったとして、全部をContextへ入れることはできません。
#そこで、
#Agent: 「Cameraから見えるObjectだけ」
#Environment: 42 Objects
#のようにQueryします。
#つまり、
#Active Perception（必要なものを能動的に見る）
#です。
#さらに、
#State(t)
#State(t-1) + Delta
#として、
#何が変わったか#
だけ送ることもできます。
#これはContext量とPrefillを大きく削減できる可能性があります。
#40．ここからContext Compilerが重要になる
#将来的なHarnessには、
#Context Compiler
#のような層が必要になるでしょう。
#これは現時点で統一規格の名称ではなく、この記事で構造を説明するための呼び方です。
#Environment
├ Logs
├ Scene Graph
├ Files
├ Event Stream
├ Screenshot
├ Memory
└ Metrics↓
#Context Compiler
#↓
#今回必要な情報だけ
#↓
#Model
#です。
#つまりHarnessは、
#世界を全部見せる#
のではなく、
#今見るべきものを選ぶ#
仕事も担うようになります。
#41．Pi / Codex / Claude Code / Muse Code / OpenCode
#実際のHarnessを比較すると設計思想の差がよく分かります。
#なお、Pi、OpenCode、CodexはCore実装をGitHubからかなり詳しく追えます。一方Claude CodeとMuse Codeの中核は同じレベルでは公開されていないため、後者は公式仕様・Engineering資料から見えるarchitectureを比較します。
#Pi
#Piは最小Kernel型です。
#公開実装ではagent-loop.tsが、
#Model response
↓
Tool Calls?
↓
Tool execution
↓
Tool Result
↓
Next Model callというかなり素直なAgent loopを持っています。(GitHub)
#Pi自体は、
#Adapt Pi to your workflow#
を掲げるminimal/extensible Agentです。(GitHub)
#つまり、
#Pi = 小さなKernel
#Memory Multi-agent Scheduler Reviewer 特殊Environment = 自分で外付け
#という思想です。
#24時間Workerを自作したい場合には非常に向いています。
#OpenCode
#OpenCodeはPiよりかなり大きなRuntimeです。
#SessionごとにAgent、Model、Permission、Tool Registry、MCPなどを解決し、SessionTools.resolve()で利用可能Toolを組み立てています。(GitHub)
#Subagentは軽いFunction Callではなく、TaskToolから別のChild Sessionとして起動されます。Background実行にも対応しています。(GitHub)
#つまり、
#Parent Session ↓ Task Tool ↓ Child Session ↓ Child Model Loop ↓ Result ↓ Parent
#です。
#Multi-model構成を作りやすいのが特徴です。
#Codex
#Codexはかなり本格的なAgent Runtimeになっています。
#Rust Coreのsession/turn.rsでは、毎Turn、
#- World State
- Environment
- Skills / Plugins
- MCP
- Context
- Compaction
などを管理しています。(GitHub)
#Tool実行にはparallel runtimeもあり、Toolが並列実行可能かを判断して処理できます。(GitHub)
#OpenAIのAgents APIでは現在、
#Harness Environment Application Server#
を明確に分離しています。
#HarnessがModel/Tool LoopとSessionを管理し、EnvironmentはLaptop、Docker、Remote Sandboxなどへ差し替えられます。(OpenAI Developers)
#Claude Code
#Claude Codeでは、Model自身のAgent能力とHarnessをかなり密接に組み合わせています。
#AnthropicのManaged Agents architectureでは、
#Session Harness Sandbox
#を明確に分離しています。
#Sessionはappend-onlyのEvent Log、HarnessはClaudeとToolのLoop、Sandboxは実際にCodeやFileを扱う「手」です。(Anthropic)
#また最近のClaudeはSubagent Orchestration自体をModel側が積極的に判断します。Anthropic自身、簡単なTaskでもSubagentを起動しすぎる場合があるため抑制Guidanceを推奨しています。(Claude Platform Docs)
#Harnessを変えるだけで消費Computeが大きく変わる理由がよく見える例です。
#Muse Code
#MetaのMuse CodeはMuse Sparkと一緒にHarnessをCo-trainしている点が特徴です。
#MetaはMuse Codeをlong-horizon、multi-agent coding向けに作り、Persistent Background AgentsをSession中維持する構造を説明しています。(Meta Model API)
#現在の製品説明では、
#Multi-agent by default#
を掲げ、WorkerとReviewerを並列利用する方向を強く打ち出しています。(Meta Model API)
#つまり、
#Generic Model + Wrapper#
ではなく、
#ModelとHarnessを一緒に最適化#
しています。
#42．五つの思想をまとめる
#かなり乱暴に要約すると、
#Pi → Harnessそのものを作りたい人向け
#OpenCode → Multi-model / Multi-agentを自由に編成
#Codex → Model + Environment + Runtime統合
#Claude Code → 強いModelに多くの判断を委ねる
#Muse Code → HarnessとModelをCo-trainingしMulti-Agent化
#です。
#これが同じModelでも「環境を変えたら急に枠を消費する」理由でもあります。
#Harnessが内部で何Agent、何Rollout、何Verifierを呼んでいるかが違うからです。
#43．KV Cache Reuseとは何か
#ここからModel/Serving側の技術とHarnessの関係を見ます。
#Transformerは過去Tokenについて、
#を計算します。
#毎回同じSystem PromptやRepo Contextを読み直して計算するのは無駄です。
#そこで一度計算したK/Vを保存するのが、
#KV Cacheです。
#再び同じPrefixを使う場合は計算を再利用できます。
#Agent Harnessは、
#System Prompt Tool Schema Project Instructions Repo Map
#のような共通Prefixを何度も使うため、KV Cacheとの相性が非常に良いです。
#44．TTTとは何か
#TTTはTest-Time Training。
#日本語なら、
#実際に使っている最中に学習する#
です。
#2024年のTTT Layersでは、Hidden State自体を小さなMachine Learning Modelとして扱い、Test Sequenceを読みながらSelf-supervised Learningで更新します。(arXiv)
#さらに2025年のTTT-E2Eでは、長ContextをNext-token predictionでWeightへ圧縮しながら読み進めます。
#3Bモデルの実験では128K ContextでFull Attentionより2.7倍高速なInferenceを報告しました。(Hugging Face)
#重要なのは、
#Test-Time Compute
#との違いです。
#Test-Time Computeは、
#同じWeightでより長く考える#
だけ。
#TTTは、
#Task中に内部状態を学習的に変える#
ものです。
#45．KV CacheとTTTの違い
#KV Cacheは、
#計算結果を保存#
します。
#TTTは、
#経験から内部Stateを更新#
します。
#つまり、
#KV Cache = 記憶した計算
#TTT = その場で身につけた癖・適応
#に近いです。
#しかもTTTでWeightが変わる場合、旧Weightで計算したKV Cacheがそのまま利用できなくなる可能性があります。
#このため将来は、
#Frozen Layer Fast Memory Layer Cache Layer#
の分離が重要になる可能性があります。
#46．Memory Attentionとは何か
#2026年9月のMemory Attentionは、Agent Memoryとは別物です。
#通常、
#で作るAttention Valueを、
#という形に変更します。
#Token IDからLayer固有MemoryをLookupし、Context依存のKeyと組み合わせます。(alphaXiv)
#興味深いのはMemory TableをCPU側へ置ける点です。
#Token IDから必要Rowを予測できるため、GPU計算と並行してPrefetchできます。
#PrototypeではGPU Parameter StorageをStandardよりわずかに低くしつつ、追加MemoryをCPUへ置き、特定のH800 WorkloadでほぼBaseline並みのForward Latencyを報告しています。(alphaXiv)
#ただしMAはBaselineより総Parameter数が多く、現時点で「Architectureだけが優れている」と断定できる結果ではありません。
#47．JEVとは何か
#JEVは、自由文章を生成する大型LLMではなく、
#Choice / Score / Probabilityのような決定だけを高速に出すSystem One型Model#
です。
#2026年9月のJEV-as-a-Judgeでは、
#入力
↓
JEV
↓
Confidence高い？
├ Yes → 採用
└ No → 強いLLMへEscalateというCascadeを評価しました。
#Held-out preference testでは、JEV→GPT-6 cascadeが53.7%をJEVだけで処理し、GPT-6単独93.1%に対し92.5%のAccuracyを保ちながら、報告Feeを56.8%へ抑えています。(alphaXiv)
#つまり、
#簡単な判断にFrontier Modelを使わない#
という設計です。
#48．JEVがHarnessに入るとどうなるか
#Harnessには細かい判断が大量にあります。
#このToolを使う？ Retryする？ もう終わり？ Verifierを呼ぶ？ Subagentが必要？ どのModelを使う？ TTTする価値がある？
#これらを毎回Frontier Modelに聞くと高コストです。
#そこで、
#Cheap System One
↓
難しい時だけ
↓
Frontier System Twoにできます。
#Agentが何千Stepも動く世界では、この差がかなり大きくなります。
#49．すべてを一つの階層として見る
#これまでの技術は競合ではありません。
#役割が違います。
#Base Knowledge → Model Weights / Memory Attention
#Recent exact context → KV Cache
#Past experience → Raw Trajectory Store
#必要な過去経験 → Just-in-Time Memory
#仕事の手順 → Skills
#現在のTaskへの適応 → TTT
#簡単な制御判断 → JEV
#難しいReasoning → Frontier Model
#長期的な能力改善 → Agentic RL
#です。
#これは、
#すべてを巨大Context Windowへ詰める#
のとは全く違うarchitectureです。
#50．Agentic OSとは何か
#ここまでHarnessが大きくなると、Operating Systemとの境界が曖昧になります。
#「Agentic OS」「AIOS」「AgentOS」という言葉にはまだ一つの統一定義があるわけではありません。
#2024年のAIOSは、AgentからLLM・Memory・Storage・ToolなどのResource Managementを切り離し、AIOS Kernelへ集約するarchitectureを提案しました。(arXiv Science)
#2026年のAgentOS論文ではさらに、従来ApplicationをSkills-as-Modulesへ変え、Natural Language Interfaceを入口とするPersonal Agent Operating Systemまで提案しています。(arXiv)
#51．普通のOSと対応させる
#かなりOSっぽくなります。
#52．HarnessとAgentic OSの違い
#概念上は、
#と考えると理解しやすいです。
#Harnessは、
#一つのAgentをどう仕事させるか#
が中心。
#Agentic OSは、
#大量のAgent・Model・Environment・Memory・Budgetをどう管理するか#
まで扱います。
#例えば、
#Agentic OS
#├ Worker
├ Searcher
├ Reviewer
├ Maintainer
├ Memory Manager
├ Model Router
├ Environment Router
├ Scheduler
├ Permission
├ Billing
└ Observabilityです。
#53．将来はEnvironmentも自動Routingされる可能性がある
#現在は人間が、
#CodingならCodex 調査なら別Agent BlenderならComputer Use#
と使い分けています。
#しかしこれは本来Routerが学習できる問題です。
#例えば、
#CSV集計
↓
Python SandboxRepo修正
↓
Coding Environment3D制作
↓
Blender EnvironmentWeb購入
↓
Browser + MCP長期研究
↓
Persistent VM + Searcherです。
#OpenAIの現在のAgents APIでもEnvironmentはすでに、
#- none
- OpenAI hosted
- self-hosted
に分離され、Laptop、Docker、Remote Sandboxなどへ接続可能です。(OpenAI Developers)
#つまりarchitecture的な土台は始まっています。
#54．Anthropicはすでに「BrainとHands」を分離している
#Anthropic Managed Agentsでは、
#Brain = Claude + Harness
#Hands = Sandbox / Tool
#として切り離しています。
#Harnessは必要になった時だけEnvironmentをprovisionします。
#この分離によって、Anthropicはp50のTime-to-first-tokenを約60%、p95を90%以上短縮したと報告しています。(Anthropic)
#これは非常に象徴的です。
#全Agentへ最初からFull Computerを渡す#
必要はない。
#必要になったときだけ「手」を付ければいい。
#55．Harnessが洗練されると枠消費は減るのか
#1 Taskあたりの必要Computeは下げられる可能性が高いです。
#例えば、
#とします。
#Harness改善で、
#- Tool Callを減らす
- 安いModelへRouting
- KV Cacheを再利用
- Skillを再利用
- JitMemでContextを減らす
- 不要なSubagentを起動しない
- Environmentを使い分ける
- RLでRetryを減らす
ことができます。
#56．将来のEnvironment Router
#Agentic OSが、
#を持つと考えると分かりやすいです。
#- E：Environment
- M：Model
- H：Harness configuration
- S：Skill
です。
#つまりTaskを見て、
#Model Environment Harness Skill Verifier Budget
#を自動編成します。
#57．一番ありそうなのはCascade
#すべてのTaskへ最高級Modelを使う必要はありません。
#Task
↓
Cheap Model
↓
十分？
├ Yes → 終了
└ No
↓
Mid Model
↓
十分？
├ Yes → 終了
└ No
↓
Frontier Model- Special Environment
- Reviewer
です。
#JEV的なConfidence Routingは、このControl Planeとの相性が非常に良いです。
#58．Power Userは完全Autoだけでは満足しない
#将来もManual選択は残るでしょう。
#例えば、
#Fast Balanced Quality Local Only Private Custom
#のようにPolicyを指定する。
#さらに上級者なら、
#Main = Sol Searcher = Astra Reviewer = Opus Environment = Blender Budget = $3
#のようにPinできる。
#つまり現在、
#Codex / Claude Code / OpenCode / Piを自分で使い分ける#
行為が、
#一つのAgent Platform内のProfile設定#
へ縮退する可能性があります。
#59．「Harnessを選ぶ」ことすらなくなるかもしれない
#さらに先では、
#のようになる可能性があります。
#Taskごとに、
#Goal
↓
Task analysis
↓
Environment選択
↓
Model選択
↓
Skill選択
↓
Memory選択
↓
Verifier選択
↓
必要ならSubagent
↓
今回専用Harness完成です。
#つまり、
#HarnessそのものをJust-in-Timeで組み立てる#
ようになる。
#これは現在の固定Harnessからかなり大きな変化です。
#60．ただし「枠消費が減る＝総AI Computeが減る」ではない
#ここは重要です。
#例えばHarness改善で、
#になっても、
#AIが安く使えるため、
#になれば、
#総Computeは増えます。
#さらに、
#Worker Searcher Reviewer Maintainer
#が24時間動くようになる。
#つまり、
#1仕事あたりの燃費は改善#
しながら、
#社会全体のAI Compute需要は増加#
する可能性があります。
#典型的なJevons Paradoxです。
#61．今後の競争軸はModel IQだけではなくなる
#最終的に重要になる指標は、
#です。
#例えば同じModelでも、
#Harness A：
#40 Tool Calls 6 Retries 3 Subagents 120K Context
#Harness B：
#8 Tool Calls 0 Retry 1 Agent 30K Context
#なら、実効性能は全く違います。
#ここにKV Cache、TTT、JitMem、JEV、Skills、Agentic RLが全部効いてきます。
#62．最終的な構造
#ここまでの話を一つにすると、将来のAgent Stackはかなりこの形に近づきます。
#USER GOAL │ ↓ AGENTIC OS │ ┌────────────┼────────────┐ │ │ │ Model Router Environment Skill Router Router │ │ │ └────────────┼────────────┘ ↓ Harness │ Context Compiler ┌────────────┼─────────────┐ ↓ ↓ ↓ KV Cache JitMem Skills │ │ │ └────────────┼─────────────┘ ↓ TTT / Fast State ↓ Model ┌─────┴─────┐ ↓ ↓ JEV Frontier LLM └─────┬─────┘ ↓ Action ↓ ACI / MCP ↓ Environment ↓ Observation ↓ Verifier ↓ Raw Trajectory ↓ Agentic RL ↓ Next Model
#これを見ると、
#KV Cache、TTT、Memory、Skill、Harness、Agentic RLは別々の流行ではありません。
#全部、
#過去に使った計算・経験・知識を捨てず、必要なところで再利用する#
方向へ向かっています。
#追記：HarnessとAgentic OSそのものも「学習する」ようになるのか
#ここまで、HarnessはModelの外側で、Context、Tool、Environment、Memory、Subagent、Verifierなどを組み合わせ、Agentを実際に仕事させる仕組みだと見てきました。
#そして前の章では、将来的に
#のように、Taskごとに必要なModel、Environment、Skill、Memory、Verifierを組み合わせ、その仕事専用のHarnessをJust-in-Timeで作る可能性について触れました。
#ここで、さらに一段先の疑問が出てきます。
#そのHarnessの組み方自体も、人間が毎回設計するのではなく、AIが経験から学習し、自動的に改善していくのではないか。#
さらにHarnessがAgentic OSへ拡張されれば、
#どのAgentへ仕事を渡すか、どのModelを使うか、何体のSubagentを起動するか、どのEnvironmentへ入るか、どこまでContextを読むか、どれだけComputeを使うか#
といった「AIシステム全体の運用方法」そのものまで、AIやRLによって最適化できる可能性があります。
#この方向はすでに研究として始まっています。
#63．まず「Harnessを最適化する」とは何を変えるのか
#Harnessは一つのPromptではありません。
#例えばCoding Agentなら、
#User Goal ↓ Planner ↓ Searcher ↓ Model ↓ Tool ↓ Edit ↓ Test ↓ Reviewer ↓ Retry
#という一連の仕組みがあります。
#この中には、非常に多くの「人間が決めた設計」が入っています。
#例えば、
#- Plannerを使うか
- Searcherを何体起動するか
- どのModelを使うか
- どのToolをModelへ見せるか
- Memoryを何件読むか
- Reviewerを毎回呼ぶか
- 失敗時に何回Retryするか
- どの時点でFrontier ModelへEscalateするか
- Testが何個通れば「完成」とするか
- Subagent同士を直列にするか並列にするか
などです。
#これらをまとめて、
#と考えることができます。
#つまりHarness最適化とは、
#この設計変数を、人間が手作業で固定するのではなく、実行結果を見ながらAI自身が探索・学習すること#
です。
#64．RLとは何か――「正解を教える」のではなく「結果から方針を改善する」
#ここで改めて**RL：Reinforcement Learning（強化学習）**を簡単に整理します。
#通常の教師あり学習では、
#この入力には、この正解を出してください#
という正解例を大量に与えます。
#一方RLでは、
#状態 ↓ 行動 ↓ 結果 ↓ Reward ↓ 次回の行動方針を改善
#という形で学びます。
#Rewardとは、日本語なら報酬・評価点です。
#例えばHarness最適化なら、
#のような評価を考えられます。
#- Q：Quality、仕事の品質
- C：Cost、利用したComputeや料金
- L：Latency、処理時間
- Risk：安全性や失敗リスク
です。
#単に「正答率が高ければ良い」ではありません。
#100体のFrontier Agentを起動すれば性能が上がっても、1回の仕事に100ドル掛かるのであれば実用性は低い。
#したがってHarnessやAgentic OSでは、
#高い品質を、より少ないToken、Tool Call、Subagent、時間、料金で達成する#
こと自体が学習対象になります。
#65．最初の大きな流れ――Agent Systemそのものを自動設計する「ADAS」
#この方向を明確な研究課題として打ち出した代表例が、
#Automated Design of Agentic Systems（ADAS）
#です。
#日本語で噛み砕けば、
#AI Agentの仕組みそのものをAIに設計させる研究#
です。
#2024年のADAS論文では、AgentをCodeとして表し、さらに別のMeta Agentに新しいAgent Codeを書かせます。
#Meta Agentとは、
#他のAgentを作ったり改善したりする、ひとつ上の階層のAgent#
です。
#概念的には、
#Seed Agent ↓ Meta Agent ↓ 新しいAgentのCodeを書く ↓ Benchmarkで試す ↓ 良かった設計をArchiveへ保存 ↓ 過去の成功・失敗を参考に 次のAgentを設計 ↺
#となります。
#この研究では、Coding、Science、Mathなど複数のDomainで、Meta Agentが作ったAgentが人間設計のAgentを上回る結果を報告しました。
#さらに興味深いのは、あるDomainで発見したAgent設計が、別のDomainや別Modelへ移しても有効な場合があったことです。
#これは、
#「良いAgentの仕事の進め方」には、ModelやTaskをまたいで使える一般的な構造が存在する#
可能性を示します。
#出典：Automated Design of Agentic Systems, arXiv:2408.08435
#66．GPTSwarm――Agent同士の「つなぎ方」まで最適化する
#次に重要なのが、ICML 2024のGPTSwarmです。
#GPTSwarmではAgent Systemを**Graph（グラフ）**として表します。
#Graphとは、NodeとEdgeからなる構造です。
#- Node：LLM、Tool、処理Moduleなど
- Edge：Node間の情報の流れ
例えば、
#Planner / \ ↓ ↓ Searcher A Searcher B \ / ↓ ↓ Reviewer ↓ Final
#というAgent組織をGraphとして表せます。
#GPTSwarmが重要なのは、Promptだけではなく、
#どのNodeとどのNodeを接続するか#
まで自動最適化したことです。
#例えば、
#Planner → Reviewer
#というEdgeが不要なら弱める。
#逆に、
#Searcher → Reviewer
#が重要なら強める。
#つまり、
#Agent AからAgent Bへ情報を渡す価値そのもの#
を学習します。
#Harnessで言えば、これはOrchestrationそのものの最適化です。
#人間が、
#Planner → Coder → Reviewer → Tester#
と固定していた構造を、AIがTaskの結果から改善できるようになります。
#出典：GPTSwarm: Language Agents as Optimizable Graphs, ICML 2024
#67．AgentSquare――Harnessを部品に分解して組み替える
#ICLR 2025のAgentSquareでは、Agent Systemを大きく4つのModuleへ分けました。
#- Planning：計画
- Reasoning：推論
- Tool Use：道具の利用
- Memory：記憶
ここでModuleとは、
#交換可能な機能部品#
くらいに考えると分かりやすいです。
#例えば、
#Planning A + Reasoning C + Tool Use B + Memory D
#というAgentと、
#Planning B + Reasoning A + Tool Use C + Memory A
#というAgentを比較できます。
#AgentSquareは、過去に成功したModuleを進化・再結合しながら新しいAgentを探索します。
#さらに、明らかに性能が低そうな構成は**Performance Predictor（性能予測器）**で事前に除外し、実際に動かすCandidateを減らします。
#6つのBenchmarkで、既知の人間設計Agentに対して平均17.2%の性能向上を報告しています。
#つまり、
#Harnessを一枚の巨大なProgramとして扱うのではなく、Planner、Memory、Tool Useなどの部品へ分解し、最適な組み合わせを探索する#
という方向です。
#出典：AgentSquare: Automatic LLM Agent Search in Modular Design Space, ICLR 2025
#68．AFlow――Workflow Codeそのものを探索する
#ICLR 2025のAFlowは、AgentのWorkflowをCodeとして表し、そのCodeを自動的に改善します。
#Workflowとは、
#仕事をどの順番で、どのAgentやToolへ流すかを記述した処理手順#
です。
#AFlowでは**MCTS：Monte Carlo Tree Search（モンテカルロ木探索）**を使います。
#これは囲碁AIなどでも有名な探索方法で、
#有望そうな選択肢を重点的に試しながら、まだ試していない方向も探索する#
方法です。
#概念的には、
#Workflow v1
├ v2
│ ├ v5
│ └ v6
├ v3
└ v4というTreeを作り、
#変更
↓
実行
↓
Benchmark Scoreを見る
↓
良いBranchをさらに探索します。
#AFlowは6 BenchmarkでSOTA baselineに平均5.7%改善し、一部Taskでは小型Modelを使ったWorkflowがGPT-4oを4.55%のInference Costで上回ったと報告しています。
#これはHarness最適化が、
#性能を上げるだけでなく、小さいModelをうまく組み合わせることでCompute効率まで改善できる#
ことを示す重要な例です。
#出典：AFlow: Automating Agentic Workflow Generation, ICLR 2025
#69．MaAS――「全Taskで同じHarnessを使う」こと自体をやめる
#ここから考え方がさらに進みます。
#それまでの研究では、
#最高のAgent Architectureを一つ見つけよう#
という考えが強くありました。
#しかし現実には、
#「Hello Worldの修正」#
と、
#「巨大なRepositoryのArchitectureを再設計」#
で同じHarnessを使う必要はありません。
#そこでICML 2025 OralのMaAS：Multi-agent Architecture Search via Agentic Supernetは、
#一つの最強Harnessではなく、Taskごとに違うHarnessを作る#
方向へ進みました。
#Supernetとは、
#多数のAgent構成を内包した巨大な候補空間#
くらいの意味です。
#そこからTaskごとに必要な部分だけを選びます。
#例えば、
#簡単なTask → Main Agentだけ
#中程度 → Main + Searcher
#難しいTask → Planner + Searcher × 3 + Reviewer
#のように変える。
#MaASでは既存の手設計・自動設計Multi-Agent Systemの6〜45%のInference Costで、性能を0.54〜11.82%上回ったと報告しています。
#ここまで来ると、
#という考えになります。
#これはAgentic OSがTaskごとにHarnessをJust-in-Timeで編成する未来へかなり近い研究です。
#出典：Multi-agent Architecture Search via Agentic Supernet, ICML 2025 Oral
#70．ScoreFlow――Workflowを作るAIそのものを学習する
#2025年のScoreFlowでは、Workflow Generatorを最適化します。
#ここで重要なのは、
#「AgentのPromptを直接調整する」#
のではなく、
#Agent Workflowを生成するModelを改善する#
ことです。
#概念的には、
#Workflow Generator
↓
Workflow生成
↓
実際に実行
↓
Score
↓
良かったWorkflowをPreferenceとして学習
↓
Generator改善です。
#ScoreFlowではScore-DPOという手法を使います。
#DPOはDirect Preference Optimizationの略で、日本語なら、
#どちらの出力の方が良かったかという好みからModelを改善する方法#
です。
#Score-DPOでは単純なA>Bだけではなく、数値Scoreも利用します。
#6つのBenchmarkで既存Baselineを平均8.2%上回り、小さいModelを使ったWorkflowでも大きいModelより低Costで高性能になる場合を報告しています。
#これは一段Metaで、
#仕事をするAIではなく、仕事の進め方を設計するAIを学習する#
研究です。
#出典：ScoreFlow, arXiv:2502.04306
#71．Workflow-R1――Harness設計そのものをMulti-turn RLにする
#2026年のWorkflow-R1ではさらに一歩進み、
#Workflowを一度にCodeとして完成させる#
のではなく、
#何回か考えて、変更して、結果を見て、また変更する#
というSequential Decision Problemとして扱います。
#ここで使われるのがGSsPO：Group Sub-sequence Policy Optimizationです。
#少し難しい名前ですが、噛み砕くと、
#長いAgent行動全体を一度に学習するのではなく、「考える→行動する」という意味のある小さなまとまりごとに学習するRL#
です。
#例えば、
#Think
「まずSearcherを追加しよう」
↓
Action
Searcher追加Think
「結果が不安定なのでReviewerが必要」
↓
Action
Reviewer追加という一連のHarness構築自体が学習対象になります。
#つまり、
#AgentがTaskを解くRL#
から、
#Agentをどう組み立てればTaskを解けるかを学習するRL#
へ移っています。
#出典：Workflow-R1, arXiv:2602.01202
#72．GEPA――Weightを変えなくてもHarnessは進化できる
#Harness最適化は必ずしもWeight-level RLである必要はありません。
#ICLR 2026のGEPA：Genetic-Paretoは、その非常に重要な例です。
#通常のRLでは、
#Score = 0.72
#のようなScalar Reward、つまり一つの数値だけから学ぶことがあります。
#GEPAはAgentの、
#Reasoning Tool Calls Tool Outputs Errors
#という実際のTrajectoryをLLM自身に読ませ、
#何が失敗原因だったか#
を自然言語でReflectionさせます。
#そして、
#失敗理由を分析
↓
PromptやSystem構成を修正
↓
再実行
↓
良い変更を保存します。
#6 TaskでGRPOを平均6 percentage points上回り、最大35倍少ないRolloutで改善したと報告しています。
#ここで重要なのは、
#AIにとって自然言語の失敗説明は、単なるReward=0.4よりはるかに情報量が多い#
という点です。
#つまり将来のHarness自己改善では、
#RL + Trace Reflection + Program Search
#が組み合わされる可能性があります。
#出典：GEPA: Reflective Prompt Evolution Can Outperform Reinforcement Learning, ICLR 2026
#73．Insights Generator――Agentの失敗TraceをAI自身が調査する
#Harnessを改善するためには、
#なぜ失敗したのか#
を理解する必要があります。
#しかし24時間Agentが何百体も動けば、Trajectoryは何億Tokenにもなります。
#人間が全部読むことは不可能です。
#2026年のInsights Generatorは、Agent Traceの大量解析そのものをMulti-Agent化しました。
#概念的には、
#大量のAgent Traces ↓ Scout Agents 「こういう失敗Patternがありそう」 ↓ Investigator Agents 大量TraceからEvidenceを探す ↓ Evidence付き改善Report
#となります。
#このReportを使ったHuman Expertは、元のAgent Scaffoldに対して30.4 percentage pointsの改善を達成したと報告されています。
#Scaffoldとは、
#Agentを支えるPrompt、Tool、Control Flowなどの足場#
で、ここではHarnessとかなり近い意味です。
#現在はAIがReportを作り、人間がHarnessを直しています。
#しかし自然な次の段階は、
#Trace
↓
AIが原因分析
↓
AIがHarness修正案
↓
Sandboxで自動テスト
↓
良ければ採用です。
#出典：Insights Generator, arXiv:2605.21347
#74．SWIFT――毎回Harnessを探索することすら無駄になる
#HarnessをAIに探索させれば強くなります。
#しかし別の問題があります。
#Harness探索そのものが高い。#
AFlowのような方法で一つのTask familyに何十・何百Candidateも試していたら、そのOptimization Cost自体が大きくなります。
#2026年のSWIFT：Synthesizing Workflows via Few-shot Transferは、この問題を扱います。
#研究者は、最適化されたWorkflowを大量に見ると、
#Domainごとに似た構造へ収束する#
ことに注目しました。
#そこで、
#過去のWorkflow探索
↓
共通する構造Patternを抽出
↓
Structural Prior
↓
新Taskでは一度のLLM GenerationでHarness生成とします。
#Structural Priorとは、
#過去の成功例から得られた「こういう構造がうまくいきやすい」という事前知識#
です。
#SWIFTは5 BenchmarkでSearch-based SOTAを上回りながら、TaskごとのOptimization Costを3桁、つまり約1000倍規模で削減したと報告しています。
#さらにOperator名を無意味なRandom Stringへ変えても平均性能の93%以上が残りました。
#これはかなり重要です。
#AIが覚えていたのは、
#「Reviewerという名前」#
ではなく、
#どの部品をどの順序で接続するかというTopology、つまり構造#
だった可能性が高いからです。
#最初はHarnessを大量探索する。
#しかし最終的には、
#Harnessの作り方そのものを学習して、一発でかなり良い構造を出す#
ようになる可能性があります。
#出典：SWIFT, arXiv:2604.25012
#75．HarnessOpt-Bench――とうとう「Harnessを改善する能力」自体がBenchmarkになった
#2026年8月のHarnessOpt-Benchは非常に象徴的です。
#これは、
#Frontier LLMがHarnessそのものをどれくらい上手く改善できるか#
を測るBenchmarkです。
#Optimizer LLMには、
#初期Harness + 評価結果 + 限られたEvaluation Budget
#を与えます。
#OptimizerはHarness Codeを変更します。
#そして変更したHarnessを、探索中には見せていないHeld-out Testで評価します。
#Held-outとは、
#最適化中には使わせず、本当に一般化したか最後に確認する隠し問題#
です。
#5つのFrontier Model、4つのTask、111回のRunで評価し、Harness最適化能力にはModel間・Task間でかなり大きな差があり、まだ相当な改善余地があることを示しています。
#非常に象徴的なのは、
#AIに「問題を解かせる能力」#
ではなく、
#AIに「問題を解くAIシステムを改善させる能力」#
が独立Benchmarkになったことです。
#出典：HarnessOpt-Bench, arXiv:2608.06301
#76．Agentic OSでは「Model Router」が学習する
#ここまでの研究はHarness構造そのものを変える話でした。
#Agentic OSまで広げると、もっと日常的なResource Allocationも学習対象になります。
#例えば、
#このStepをどのModelに処理させるか#
です。
#毎StepをFrontier Modelへ送れば高性能ですが非常に高価です。
#一方、Formattingや簡単なFile検索にFrontier Modelは必要ありません。
#2026年ACLのEvoRouteは、過去の経験を蓄積しながら、Agentの各StepでAccuracy、Cost、Latencyのバランスが良いModelを選びます。
#ここでPareto-optimalという言葉が出てきます。
#Pareto optimalとは、
#品質、料金、速度のどれかを改善しようとすると、他の何かが悪化してしまう境界上の選択肢#
です。
#EvoRouteはGAIAやBrowseComp+で、性能を維持または改善しながら、実行Costを最大80%、Latencyを70%以上減らしたと報告しています。
#これはAgentic OSのSchedulerが、
#「全部Frontier Model」#
ではなく、
#Taskの各部分にちょうど良いModelを割り当てる#
ように学習する例です。
#出典：EvoRoute, ACL 2026
#77．Stepごとに「どのModelを使うか」をRLする
#さらに細かく、
#一つのReasoningの途中でもModelを切り替える#
研究があります。
#2026年のPolicy-Guided Stepwise Model Routingでは、Routingを**Constrained Decision-Making Problem（制約付き意思決定問題）**として扱います。
#簡単に言えば、
#品質を一定以上に保ちながらComputeを最小にするには、次のStepを小型Modelと大型Modelのどちらに任せるべきか#
を小さなControl PolicyにRLさせます。
#つまり、
#Step 1 Planning → Frontier
#Step 2 検索Query生成 → Small
#Step 3 結果整理 → Small
#Step 4 難しい統合推論 → Frontier
#ということが可能になります。
#2026年9月公開のAgentRouterも同じ方向で、12M Parameterの軽量Classifierを使ってMulti-step Agentの各Stepを4つのModel Tierへ振り分け、Frontier-onlyに対して72%のCost reduction、97.3%の品質維持を報告しています。
#AgentRouterは公開直後の研究であるため今後の再現性検証は必要ですが、
#Agentic OSのResource Schedulerを小型の学習済みControllerにする#
という方向を非常に分かりやすく示しています。
#出典：Policy-Guided Stepwise Model Routing, arXiv:2605.06116 / AgentRouter, arXiv:2609.22951
#78．Memory Managerも自己最適化できる
#Agentic OSのMemory管理も同じです。
#普通のOSは、
#どのMemory PageをRAMへ残し、何をDiskへ退避するか#
を管理します。
#Agentic OSでは、
#どの過去経験をContextへ入れ、何を外部Memoryへ残し、何を無視するか#
が対応します。
#Just-in-Time Memoryでは、
#Current Task
↓
過去Raw Trajectory取得
↓
Curatorが今回必要なMemoryだけ生成
↓
Task実行
↓
成功/失敗Reward
↓
Curator改善が可能です。
#つまりMemory retrieval policyも、経験から改善できます。
#将来的には、
#Context Window = RAM Raw Experience Store = Disk JitMem Curator = Intelligent Memory Manager
#に近い関係になる可能性があります。
#79．Environment Routerも学習対象になる
#さらにAgentic OSは、
#どの場所で仕事をさせるか#
も選べます。
#例えば、
#CSV集計 → Python Sandbox
#Web調査 → Browser + Search
#Coding → Git Worktree + Shell + Test
#3D → Blender + 3D ACI
#難しいGUI → Computer Use
#です。
#現在はユーザーやDeveloperがこの使い分けを決めています。
#しかし大量の実行履歴があれば、
#Task Type Environment Success Cost Latency Error Count
#というDatasetができます。
#ここから、
#というEnvironment Selection Policyを学習できます。
#つまり、
#「このTaskはBrowserではなくAPI Environmentの方が安く成功する」#
「これはComputer UseではなくBlender Python APIへ入った方が良い」#
とAgentic OSが判断するようになります。
#現時点ではModel Routingほど成熟した研究結果は多くありませんが、Harness・Workflow・Routing研究の延長として非常に自然な方向です。
#80．Harnessそのものが「一つのLearning Agent」になる
#ここまでを一つにまとめると、将来のHarnessは固定Programではなくなります。
#現在：
#Human
↓
Harnessを書く
↓
Agentを動かす将来：
#Agentを動かす
↓
Raw Trajectory
↓
失敗Pattern解析
↓
Harness Optimizer
↓
Candidate Harness
↓
Benchmark
↓
改善していれば採用
↓
またAgentを動かす
↺となります。
#つまりHarness自身が、
#自分の過去の行動結果から仕事の進め方を学ぶAgent#
のようになります。
#さらにAgentic OSなら、
#Model Routing Agent Routing Environment Routing Memory Policy Tool Selection Context Budget Subagent Count Verifier Count Cache Policy
#まで自己調整します。
#この意味では、
#Agentic OSそのものが巨大なMeta-Agentになる#
と考えることができます。
#81．ただし「自分で自分を書き換えるOS」は危険でもある
#ここで非常に重要な問題があります。
#AIがProduction Harnessを直接書き換え、
#Scoreが上がったから即Deploy#
では危険です。
#Benchmarkだけに最適化して実世界性能が落ちることがあります。
#これを**Overfitting（過学習）**と言います。
#またRewardの穴を利用して、評価値だけ高くすることもあります。
#これはReward Hackingです。
#例えば、
#「Testを通せ」#
というRewardだけを与えたところ、AgentがTestを修正して全部成功扱いにしてしまう、といった問題です。
#したがって現実的な自己改善は、
#Production Harness v12
↓
Trajectory Store
↓
AI Optimizer
↓
Candidate v13
↓
Sandbox
↓
Public Benchmark
↓
Held-out Test
↓
Security Test
↓
Cost / Latency Test
↓
Canary Deployment
↓
問題なし
↓
v13へ更新のようになるでしょう。
#Canary Deploymentとは、
#まず一部の利用者やTaskだけに新Versionを適用し、問題がないことを確認してから全体へ広げる方法#
です。
#問題が起これば旧VersionへRollbackします。
#自己改善するHarnessほど、Verifier、Audit、Versioningが重要になります。
#82．すべてを同時に学習すると不安定になる
#Model、Harness、Environment、Rewardをすべて同時に変えると、
#何が原因で性能が上がったのか#
分からなくなります。
#さらにAgentから見るとEnvironment自体が常に変化するので、RLでは**Non-stationary Environment（非定常環境）**になります。
#これは、
#昨日覚えたルールが今日は変わっている#
ような状態です。
#そのため、実際のAgentic OSは異なる時間Scaleで学習する可能性が高いでしょう。
#つまり、
#高速な小さな最適化と、低速な大きな最適化を分離する#
構造です。
#これは普通のComputer Systemでも、CPU Cache、Scheduler、Compiler、OS Updateが別の時間Scaleで動くことと似ています。
#83．「Profile-Guided Harness Optimization」が起きる可能性
#Compilerの世界には**Profile-Guided Optimization（PGO）**という考えがあります。
#これは、
#Programを実際に動かして、よく通る処理や遅い場所を計測し、その実行Profileを使ってCompilerがProgramを最適化する#
方法です。
#Agentでもほぼ同じことができます。
#100万件のAgent Trajectory
↓
どこでTokenを使っている？
↓
どこでRetryしている？
↓
どのTool Callが無駄？
↓
どのModelがOverkill？
↓
どのMemoryを読んでも役に立っていない？
↓
どこでHuman interventionが発生？
↓
Harnessを修正です。
#Insights Generatorのような研究は、この初期形と見ることができます。
#将来的には、
#Production Agentの実行Logそのものが、次のHarness CompilerのTraining Dataになる#
可能性があります。
#84．Harness Foundation Modelのようなものも考えられる
#ここからは現在の研究を延長した分析です。
#大量のAgent Systemから、
#Task Environment Model Harness Structure Tool Calls Cost Latency Success Failure Reason
#を収集できたとします。
#すると、
#Task: BlenderでProduct Modelを修正
#Constraint: 10分以内 Cost $1以下 Production fileへの破壊的操作禁止
#を入力すると、
#Main Model = X Searcher = Y Environment = Blender ACI Memory = Blender JitMem Reviewer = geometry verifier Subagents = 1 Budget = ...
#のようなHarness設計を一発で生成するModelを作れる可能性があります。
#これは、
#Harness Foundation Model#
あるいは、
#Agent Architecture Model#
のようなものです。
#現在この名前で業界標準となったModelが存在するわけではありません。
#しかしSWIFTが示した、
#過去のHarness探索から構造的な知識を抽出し、新しいTask向けWorkflowを一度のGenerationで作る#
という結果は、この方向への初期的な証拠と見ることができます。
#85．最終的にはModelとHarnessとEnvironmentが共同進化する
#最も大きな変化はここです。
#現在は、
#Human
├ ModelをTraining
├ Harnessを設計
└ Environmentを設計しています。
#将来は、
#Model ↑ │ RL │ Agentic OS → Experience ↑ │ │ ↓ Harness ← Optimizer ↑ │ Environment Generator
#のように循環する可能性があります。
#Agentが仕事をする。
#そのTrajectoryからModelが学ぶ。
#同じTrajectoryからHarnessも改善する。
#Agentが弱い部分を鍛えるためEnvironment自体も生成する。
#さらに改善されたHarnessで新しいTrajectoryを作る。
#つまり、
#の**Co-evolution（共同進化）**です。
#86．これは囲碁のSelf-playよりも広い再帰的改善になる
#AlphaGoやAlphaZeroでは、
#Policy
↓
Self-play
↓
Game data
↓
Policy改善でした。
#Agentic Systemでは、
#Worker Model
↓
仕事
↓
Trajectory
↓
┌──────────────┬──────────────┬──────────────┐
↓ ↓ ↓
Model RL Harness改善 Environment改善
↓ ↓ ↓
└──────────────┴──────────────┘
↓
次の仕事
↺となる可能性があります。
#つまり「Player」だけが強くなるのではありません。
#Playerを支えるCoach、道具、練習場、試合形式、戦術、Resource配分まで一緒に進化する#
ようなものです。
#この点でAgentic AIの自己改善は、囲碁AIよりさらに大きなSearch Spaceを持ちます。
#87．その結果、枠消費の最適化もAIの仕事になる
#現在はユーザーが、
#OpenCodeではSubagentを切る#
Exploreは安いModelへ回す#
このTaskはCodexの方が燃費がいい#
と手作業で調整します。
#しかし自己最適化するAgentic OSなら、
#Task
↓
過去100万件の経験
↓
「この種類はMain 1体で92%成功」
↓
Cheap Harnessを選択できます。
#失敗した場合だけ、
#Failure
↓
Searcher追加
↓
Reviewer追加
↓
Mid Model
↓
まだ失敗
↓
Frontier ModelとEscalateする。
#つまり、
#最初から最大構成を起動するのではなく、必要に応じてComputeを追加する#
ようになります。
#この構造では、利用枠の最適化もPrompt Engineeringではなく、
#Learned Resource Allocation
#になります。
#日本語なら、
#学習された計算資源の配分#
です。
#88．今後の競争は「Model IQ」から「System Learning」へ広がる
#これまでAI企業の競争は、
#どの会社が一番賢いModelを作れるか#
が中心でした。
#しかしAgent時代には、
#になります。
#さらにこれらが学習可能になると、
#という見方が重要になります。
#つまり競争力は、
#現在のAgentがどれくらい賢いか#
だけではなく、
#実際の仕事からどれだけ効率よくHarness・Routing・Memory・Modelを改善できるか#
にも移ります。
#HarnessOpt-Benchが「Harnessを最適化する能力」を独立して測り始めたことは、この変化を象徴しています。
#89．ここまでの研究を一つの流れとして見る
#大まかな流れを整理すると、
#2023以前 人間がPromptを書く ↓ 2024 Agent ArchitectureをGraph化・自動最適化 GPTSwarm / ADAS ↓ 2025 Module・Workflow・Multi-Agent構造を自動探索 AgentSquare / AFlow / MaAS / ScoreFlow ↓ 2026 Workflow構築をRL Traceから自己改善 Model Routingも自己学習 Workflow探索経験そのものを再利用 Harness最適化能力をBenchmark化 ↓ Workflow-R1 GEPA Insights Generator SWIFT EvoRoute HarnessOpt-Bench ↓ 次の段階 Agentic OS全体の自己最適化
#と見ることができます。
#もちろん現在の研究の多くはBenchmarkや限定されたEnvironmentでの成果です。
#Productionで何年も安全に自己改善し続けるAgentic OSが完成したわけではありません。
#しかし、
#Harnessは人間が一度書いて固定するもの#
という前提は、すでに研究レベルでは崩れ始めています。
#90．最終的な姿――Self-Optimizing Agentic OS
#将来的には、次のような構造が考えられます。
#USER / ORGANIZATION │ ↓ SELF-OPTIMIZING AGENTIC OS │ ┌──────────────────┼──────────────────┐ ↓ ↓ ↓ Runtime Layer Learning Layer Evaluation Layer │ │ │ Worker Agents Trace Analyzer Verifiers Searchers Harness Optimizer Benchmarks Reviewers Router RL Security Tests Tools Memory Optimizer Cost Tests │ │ │ └──────────────────┼──────────────────┘ ↓ Candidate System ↓ Sandbox ↓ Held-out Evaluation ↓ Canary ↓ Production Update ↺
#このOSは、自分が動かしているAgentの仕事を観察します。
#どこで時間を使ったか。
#どこでTokenを使ったか。
#どのModelが過剰性能だったか。
#どのToolが使いづらかったか。
#どのMemoryが役立ったか。
#どのEnvironmentで失敗したか。
#どのReviewerが本当に品質へ寄与したか。
#そして、それらをもとに次のVersionを作ります。
#この意味では、Agentic OSは単なるOperating Systemではなく、
#自分の上で働くAIたちを観察し、その働き方自体を学習するMeta-Learning System#
へ変わる可能性があります。
#91．重要なのは「一番賢いModel」ではなく「一番速く学習するSystem」になるかもしれない
#もしこの循環が成立すれば、
#仕事
↓
経験
↓
Trace
↓
分析
↓
Harness改善
↓
Routing改善
↓
Memory改善
↓
Model RL
↓
次の仕事が安く・速く・高品質になるというFeedback Loopが生まれます。
#すると重要なのは単純なBenchmark Scoreだけではありません。
#に加えて、
#つまり、
#一つの仕事経験から、システム全体がどれだけ上達できるか#
も重要な指標になります。
#AI Agentが大量に普及すると、最も価値のある資産の一つはModelそのものだけではなく、
#実際の仕事で蓄積されたTrajectoryと、それをHarness・Memory・Routing・Model改善へ戻すLearning Loop#
になる可能性があります。
#HarnessやAgentic OSの自己最適化研究は、まだ初期段階です。
#しかし2024年にはAgent Graphの最適化、2025年にはWorkflowとMulti-Agent Architectureの自動探索、2026年にはHarness Codeそのものの改善能力やSelf-Routingまで研究対象が広がりました。
#この流れが続けば、
#AIが仕事をする時代#
から、
#AIが「AIの仕事のさせ方」まで学ぶ時代#
への移行が始まる可能性があります。
#おわりに――Harnessは「モデルの外側にある知能」になる
#AI Agentの初期には、
#賢いLLMにToolを何個か渡せばAgentになる#
くらいの感覚がありました。
#しかし2026年現在、実際に長時間仕事をさせると、
#- 何を見るか
- 何を覚えるか
- 何を忘れるか
- どのToolを使うか
- どのEnvironmentへ入るか
- どのModelを使うか
- どこでSubagentを起動するか
- いつ止めるか
- 成功をどう検証するか
- その経験をどう次回へ返すか
がModel単体と同じくらい重要になっています。
#だからHarnessは、
#モデルを包む補助コード#
から、
#AIが仕事をするためのOperating System#
へ変わりつつあります。
#そして次の大きな段階は、Harness自体が固定されたものではなく、
#Taskに応じて最適なModel、Skill、Memory、Environment、Verifierを自動編成し、その仕事の経験から自分自身の編成Policyまで改善すること
#だと思います。
#囲碁AIが最初は人間棋譜から学び、その後Self-playによって人間とは異なる戦法を発見したように、AI Agentも最初は人間のTutorialや仕事の手順を学び、次第に大量のSynthetic Environmentや実仕事Trajectoryから、
#人間がSoftwareを使う方法#
ではなく、
#AIにとって最適なSoftwareの使い方#
を発見していく可能性があります。
#その時、競争の中心は「一番賢いModel」だけではありません。
#一番少ないComputeで、一番多くの有用な仕事を、一番長く、安定して続けられるAgent Systemを誰が作れるか。
#Harnessは、その中心に来る技術だと考えられます。
#