AIハーネス設計のSOTA構造（2026）

思考OSの次は、運用を回すOSである

これまで私は、AIをどう賢く使うかよりも、AIと人の思考をどう同期させるかに関心を向けてきた。
タスクをどう定義するか。
曖昧な依頼をどう仕様へ落とすか。
AIの応答をどう自分の思考の延長へ変えるか。
その延長で、私はずっと「思考OS」という言い方をしてきた。

ただ、2026年のいま、現場で本当に差がつき始めているのは、その一段下の層だと感じている。
AIがどう考えるかではない。
AIが、どの状態を持ち、どこで止まり、どう再開し、何を成果物として残し、誰の承認を通り、どのログを残し、どう改善されながら回り続けるか。その設計である。

主要ベンダの公式ドキュメントを並べると、この変化はかなりはっきり見える。

LangChain は agent frameworks / agent runtimes / agent harnesses を明示的に分離して整理し、Deep Agents を harness として位置づけている。

OpenAI は AgentKit を build / deploy / optimize という三分割で打ち出し、最適化の欄に datasets、trace grading、prompt optimizer を並べている。

Anthropic の Claude Agent SDK は、Claude Code を支える tools、agent loop、context management をそのまま SDK 化したものだと説明している。

さらに LangSmith は observability、evaluation、deployment を一体で扱うと明示している。つまり、2026年の中心は、単体モデルの知能比較ではなく、運用レイヤーの分離と再統合へ移っている。

私はこの変化を、思考OSの次に来るものとして捉えたい。
思考OSが解いてきたのは、AIに何を考えさせるかだった。
これから主戦場になるのは、その思考をどこに置き、どう引き継ぎ、どう検証し、どう改善するかである。
その運用機構を、私は AIハーネス と呼ぶ。

第1章　なぜ、まだ多くのAI論は浅いのか

AIの議論は、いまでもしばしば三つの話に収束する。
どのモデルが賢いか。
どのプロンプトが強いか。
エージェントを何体に分けるか。
もちろん、どれも重要だ。だが、これらは主に 認知の入口 の話であって、運用の継続性 の話ではない。

実務で本当に苦しくなるのは、そこではない。
長いタスクの途中で文脈が膨らみ、前提が抜ける。
サブタスクは走ったのに、なぜその判断になったのか後から追えない。
ファイル編集や外部操作はできるが、承認境界が曖昧で怖い。
セッションを跨ぐと同じ説明を何度もやり直す。
出力はあるが、次のAIや次の人が引き継げる状態になっていない。
つまり壊れるのは、賢さより先に、継続性、可観測性、境界管理、状態設計 なのである。

この違いは、公式ドキュメントの力点を見ると分かりやすい。
たとえば LangGraph は、durable execution を前面に出し、失敗をまたいで長時間走れること、途中で止めて人の入力を待てること、短期記憶と長期記憶を含む stateful agent を作れることを核に置いている。interrupt は単なる UI 用の停止ではなく、永続化レイヤーに状態を保存した上で無期限に待機し、あとで正確に再開する仕組みとして定義されている。これは「AIが賢いか」よりも先に、「仕事が途中で死なないか」を設計しているということだ。

可観測性も同じだ。
OpenAI の Agents SDK は tracing を built-in で持ち、LLM の生成、tool call、handoff、guardrail、さらには custom event まで含む実行記録を集める。しかも tracing はデフォルトで有効になっている。LangSmith も、trace と run を基本単位にして、複数のトレースを project に束ね、マルチターン会話は thread としてつなぐ考え方を前提にしている。ここで見えてくるのは、エージェント開発がすでに「返答を得る作業」ではなく、「実行を観測し、比較し、改善する運用」へ移っているという事実である。

文脈管理も、もはやプロンプト職人芸ではない。
Anthropic は compaction を、長時間会話や agentic workflow のための推奨戦略として説明している。これは文脈上限に近づくと古い会話を自動要約し、古くなった情報を圧縮して、現在必要な焦点を保つ仕組みだ。prompt caching も、プロンプトの特定プレフィックスから再開できるようにして、反復タスクの時間とコストを削る前提機能として扱われている。Claude Code 自身も、古い tool output を先に掃除し、必要なら会話を要約する。さらに、永続ルールは会話履歴に頼らず CLAUDE.md に置けと明示している。ここで起きているのは、忘却をプロンプトの弱さとして片づけるのではなく、文脈をどう圧縮し、どこに恒久ルールを逃がし、何を fresh context に切り出すか を設計対象にした、という転換である。

境界管理も同様だ。
Anthropic の permission フローを見ると、tool 実行の可否は hooks、deny rules、permission mode、allow rules、canUseTool callback の順に評価される。subagent はそれぞれ独立した context window、個別の tool access、独立した permissions を持つ。hooks は Claude Code のライフサイクル上の特定地点で自動実行され、コマンドのブロック、通知、文脈再注入、監査などに使える。つまり「AIが暴走した」という現象の多くは、モデルの気分ではなく、承認経路、権限設計、フック配置の不備 として読み替えるべきなのである。

ここで、私は一つ言い切っておきたい。
多くのAI論が浅く見えるのは、モデルやプロンプトを軽視しているからではない。
問題を 認知の表面 だけで説明し、運用の背面 を見ていないからだ。

現場で頻発する症状を、少し言い換えてみる。

• 「AIが忘れる」
  それは memory 設計、compaction、persistent rule、artifact 化の失敗かもしれない。

• 「AIが危ない」
  それは permissions、hooks、guardrails、approval checkpoint の不足かもしれない。

• 「AIが高い、遅い」
  それは prompt caching、offloading、summarization、tool catalog 設計の問題かもしれない。

• 「AIが再現できない」
  それは tracing、thread、run、dataset、eval の欠如かもしれない。

つまり、いま問うべきなのは、
「どのモデルが一番賢いか」だけではない。
「どの運用機構なら、AIが継続して働けるか」である。

この視点に立つと、思考OSの次に必要なものは自然に見えてくる。
思考をうまく起動するだけでは足りない。
その思考を、途中で失わず、暴走させず、引き継ぎ可能な形にして、改善サイクルに接続しなければならない。
そのための器具が、ハーネスである。

第2章　2026年の分水嶺　Framework / Runtime / Harness の分離

2026年の分水嶺は、また新しい「すごいエージェント」が出てきたことではない。
どの層の問題を、どの道具が解いているか を、ようやく整理し始めたことだ。
少なくとも LangChain 陣営は、これを framework、runtime、harness という三層でかなり明確に言語化している。
framework は abstraction と integration、runtime は durable execution・streaming・human-in-the-loop・persistence、harness は predefined tools・prompts・subagents を含む batteries included の運用機構として整理されている。
しかも同じ整理の中で、OpenAI Agents SDK は framework 側、LangGraph は runtime 側、Claude Agent SDK や Deep Agents は harness 側に置かれている。

この三分割は、単なる分類遊びではない。
どこで設計の責任が変わるかを示す、かなり実務的な地図である。

まず Framework は、エージェントをどう表現するかの層だ。
モデル、ツール、エージェントループ、ミドルウェア、構造化出力のような抽象を提供し、「まず動くものを組む」ための足場になる。
OpenAI の Agents SDK が agent を「instructions、tools、handoffs、guardrails、structured outputs などで構成された LLM」と説明しているのは、まさにこの層の発想である。
ここで問われるのは、エージェントをどう宣言するか、どう協調させるか、どうコードとして表現するかだ。Framework は、思考をコードへ下ろすための文法に近い。

次に Runtime は、それをどう走らせ続けるかの層である。
エージェントが一回で終わる短い対話なら、framework だけでも何とかなる。だが、複数ターン、複数ツール、失敗からの再開、人の承認待ち、長時間タスク、複数スレッドの状態管理が絡むと、runtime がないとすぐ破綻する。
LangGraph が durable execution、persistence、interrupts、thread-level state を中核に置いているのはそのためだ。Runtime の仕事は、AIの賢さを上げることではない。AIの仕事を、途中で死なずに続けられるプロセスへ変えることである。

そして Harness は、その runtime の上に載る、より現場寄りの運用機構である。
ここが一番誤解されやすい。
ハーネスは、単なる「高機能フレームワーク」ではない。
エージェントが実際に仕事をするために必要な、計画、ファイル入出力、サブエージェント委譲、文脈圧縮、長期記憶、コード実行、人間承認といった 働くための器具一式 である。

Deep Agents のドキュメントは、この点をかなり率直に書いている。
Harness capabilities として、planning capabilities、virtual filesystem、task delegation、context and token management、code execution、human-in-the-loop、skills、memory を並べている。しかも planning は write_todos による構造化タスク管理、subagent は context isolation と parallel execution を狙い、runtime context では large tool input/result の offloading、summarization、long-term memory まで備える。
要するに、ハーネスとは「賢い一発回答器」を作るためのものではなく、長く働く作業主体を壊れにくくするための設計 なのだ。

Anthropic の Claude Agent SDK と Claude Code も、実態としてはかなりこのハーネス側に近い。
Agent SDK 自体が、Claude Code を支える tools、agent loop、context management をライブラリ化したものだと説明されている。subagent は独立した context window、専用 tool access、独立 permissions を持ち、hooks はライフサイクルの要所で自動実行される。
Claude Code の説明でも、subagent は main conversation と分離された fresh context を持ち、完了時には summary を返すとされている。ここで主役なのは、推論そのものより、文脈を汚さず、役割を分け、境界を守り、回し続けること である。

この三層を、私は次のように理解している。

Framework = どう表現するか
Runtime   = どう走らせ続けるか
Harness   = どう壊さず働かせるか

さらに2026年は、これに二つの横断層が強く乗ってきた。

一つは 接続面 だ。
MCP は、LLM アプリケーションと外部データ源・ツールをつなぐ標準プロトコルとして、tools、resources、prompts を基本能力に据えている。さらに MCP Apps では、tool description から interactive UI resource を参照し、ホストがその UI を会話中にレンダリングする拡張まで出てきた。つまり接続は、単なる function calling ではなく、データ・行為・UI をまたぐ共通面 へ広がっている。

もう一つは 観測と改善 だ。
OpenAI は AgentKit を build / deploy / optimize の三位一体で設計し、optimize の中に evals、datasets、trace grading、prompt optimizer を前提機能として置いている。
LangSmith も observability、evaluation、deployment を一体で提供し、しかも self-hosted では tracing と evaluation を UI / API ごと持ち込める。ここで重要なのは、評価がもはや後付けの QA ではなく、エージェント基盤そのものの一部になっていることだ。
つまり、framework / runtime / harness を分けて終わりではない。それらの上に、trace と eval が常時かぶさる のが2026年の実装形である。

ここまで来ると、見えてくる構図はかなり明快だ。

Intent / Policy
    ↓
Spec / Plan
    ↓
Framework
    ↓
Runtime
    ↓
Harness
    ↓
Artifacts / Traces / Evals

この図が言いたいのは、一つだけである。
いま主戦場なのは、「単体エージェントをどう賢くするか」ではない。
複数の層をどう切り分け、どう接続し、どう観測しながら改善するか である。

だから私は、2026年のAI設計を語るとき、もう「プロンプト設計」だけでは足りないと思っている。
必要なのは、Framework 設計 でも、Runtime 設計 でも、Harness 設計 でもある。
そして、その全部をまたいで回る Eval と Observability の設計 である。

この分離が見えてはじめて、次の章で扱う本題に入れる。
ハーネスとは結局、どんな部品でできているのか。
何を最小単位として持つべきで、どこから先が贅沢品なのか。
次章では、その構造を七つの層に分けて解体する。