同じ頭脳を載せた二台の探査車が、同じ迷路へ入る。

片方は、角を曲がるたびに直前までの地図を捨てる。もう片方は、試した道、外れだった仮説、次に確かめる場所を持ったまま進む。

車体も、頭脳も同じだ。

それでも出口へ着く確率は、大きく変わる。

AI Agentにも、いま同じことが起きている。モデルの比較表だけを見ていると、仕事の成否は「どのモデルを選んだか」で決まるように思える。けれど長い仕事では、モデルが何を覚え、どんな道具を渡され、失敗後にどこから戻り、何をもって完了と判定されるかが、結果を変える。

AI Agentの賢さは、モデルの中だけにはない。モデルが働く仕組み全体に宿る。

同じモデルが、13.3%から38.3%になった

INTELLIGENCE LIVES IN THE SYSTEMmodelの外側に、四つの仕事設備がある。

context、tool contract、checkpoint、evaluation。どれかが切れると、強いmodelも同じ失敗へ戻る。

  1. 01CONTEXT学びを持ち越す
  2. 02TOOLS道具の契約
  3. 03RECOVERY戻れる地点
  4. 04EVALUATION完了を証明

2026年8月13日、OpenAIはGPT-5.6のbuilder向けguideを公開した。

そこで紹介された数字は、かなり目を引く。

未知の2Dゲームを探索し、ruleもgoalも自分で見つけるARC-AGI-3の公開taskで、GPT-5.6 Solは標準harnessだと13.3%。過去のreasoningを引き継ぎ、長くなったcontextをcompactionするharnessでは38.3%。しかも出力tokenは、およそ6分の1になったとOpenAIは報告している。

38.3を13.3で割れば、約2.88倍。見出しにするなら「ほぼ3倍」だ。

ただし、ここで「設定を二つ変えたら、モデルの知能が3倍になった」と読んではいけない。

model weightsは変わっていない。変わったのは、同じmodelへ過去をどう渡し、contextが満杯になる前にどう整理するかという実行環境だ。

そして38.3%は、OpenAIが公開task上で行ったharness実験の報告である。ARC Prizeの公式result pageに掲載されるGPT-5.6 Sol Maxのverified scoreは、public 13.33%、semi-private 7.78%だ。38.3%を、そのまま未知taskでも検証済みのmodel scoreとして扱うことはできない。

それでも、この比較には大きな意味がある。

benchmarkが測っているのは、model単体ではなく、modelとharnessを組み合わせたsystemだからだ。

「毎回、初見に戻る」Agentは賢く見えない

OpenAIのARC-AGI-3調査によると、標準harnessには二つの特徴があった。

一つは、ゲーム内でactionするたび、直前までのprivate reasoningが捨てられていたこと。行動履歴と短いnoteは残っても、なぜその仮説へ至り、何を試し、どこが外れたかという思考のつながりは失われた。

もう一つはrolling truncationだ。履歴が一定量を超えると、古いactionから見えなくなる。

これでは、長く考えているように見えても、内側では何度も「初めまして」へ戻る。

たとえば、鍵のような物体を三つ見つけ、そのうち赤だけが扉へ反応したとする。次のturnで「赤が条件かもしれない」という発見が抜ければ、Agentは青と緑をまた試す。tokenを使い、actionを重ね、同じ失敗へ戻る。

OpenAIのResponses APIで使えるpersisted reasoningは、rawな思考文を利用者へ公開する機能ではない。公式docsでは、opaqueなreasoning itemのcontinuityを次のsampleへ渡す仕組みだと説明されている。compactionも、会話を乱暴に古い順から捨てるのではなく、次に必要なstateを小さなcontextへ持ち越すためのものだ。

つまり今回の差は、頭を巨大化したというより、学んだことを次の一歩へ持っていけるようにした差と見る方が近い。

Agentをつくるのは、modelだけではない

AI Agentの実務成果は、model名一つでは表せない。

実務成果 = model × context continuity × tool contract × state recovery × evaluation

どこか一つがゼロに近づけば、強いmodelを載せても仕事は崩れる。

1.Context continuity──前の自分から受け取れるか

長いtaskでは、正解だけでなく「すでに否定した案」が資産になる。

前のturnで何を調べ、どのfileを変更し、何を失敗と判定したか。これを引き継げなければ、Agentは同じ穴を何度も掘る。

ただし、何もかもcontextへ詰めればよいわけではない。古いlog、巨大なtool output、捨てた案が増えるほど、現在の判断へ必要なsignalは埋もれる。

必要なのは、無限の記憶ではなく、次の判断へ必要な状態を残し、不要な荷物を降ろす設計だ。

2.Tool contract──道具の形が曖昧なら、賢さが漏れる

「検索toolがあります」だけでは足りない。

入力は何か。結果はどんなschemaで返るか。失敗時のstatusは何か。再試行してよいか。同じcallを二度実行しても安全か。外部へ書き込む前に誰の承認が必要か。

この境界が曖昧だと、modelは本題を考える前に、toolの癖を推測することへ力を使う。返ってきた長文からIDを探し、欠損fieldを想像し、同じ処理を重複実行する。

OpenAIのProgrammatic Tool Callingは、複数toolのfilter、join、deduplicate、aggregateのような予測可能な処理をJavaScriptへ移せる。大量の中間結果をmodelのcontextへ流し込まず、判断に必要な小さなevidence packetへして返す。

ここで大切なのは、何でもcodeへ移すことではない。公式docsも、semantic judgment、approval-sensitive action、最終citation確認のような工程はdirect tool callを勧めている。

機械的に運べるものはcodeへ。意味を決めるところはmodelへ。責任が動くところは人間へ。

分業の線を引くこと自体が、Agentの知能を無駄にしない設計になる。

3.Checkpoint──会話だけ戻しても、現場は戻らない

Agentがfileを書き換え、databaseを更新し、外部serviceへactionした後に失敗したとする。

会話履歴だけ一つ前へ戻しても、現実側はすでに変わっている。Agentの記憶と作業環境が別の時刻を指せば、そこからの再実行は危険だ。

だからapplication側には、git commit、file hash、transaction、job ID、公開URL、timestampのようなcheckpointとreceiptが要る。

これはGPT-5.6のnative機能だという話ではない。実務へAgentを置く側が用意する設備だ。

「さっきまで覚えている」と「さっきの状態へ安全に戻れる」は、別の能力なのだ。

4.Evaluation──完了の定義がなければ、賢く見せることはできる

Agentが「完了しました」と言った。それだけで仕事は終わっただろうか。

記事なら出典へ到達できるか。開発ならtestが通るか。調査なら反証も拾ったか。公開ならcanonical URL、RSS、sitemapまで正しいか。

成功条件がないtaskでは、流暢な終了報告と本当の完成を区別できない。

AgentBenchは、複数のinteractive environmentでAgentを評価し、長期のreasoning、decision-making、instruction followingを主要な障害として報告した。GAIAも、reasoning、web、file、tool useを組み合わせた実世界寄りのtaskを、短い一意の正解で採点できるよう設計した。

GAIAの初期評価では、同じGPT-4を背後に使う構成でも、AutoGPTがplugins構成より一部levelで悪い結果を出した。論文はAPI、prompt、generation parameterの影響を可能性として挙げている。

同じmodel familyを使えば、同じ成果になるわけではない。これは2026年に突然生まれた話ではなく、Agent評価が長く抱えてきた問題だ。

Multi-agentとcacheは、「足せば賢くなる薬」ではない

OpenAIのbuilder guideには、native multi-agentとprompt cachingも登場する。

multi-agentは、独立した調査や実装を並行させ、それぞれへ小さく集中したcontextを渡せる。一方、前工程の答えがなければ次へ進めないtaskや、同じfileを複数Agentが同時に触るtaskでは、調整costと競合が増える。OpenAIのdocsも、subagent追加はtokenを増やし得ると明記している。

cacheはさらに誤解しやすい。

GPT-5.6のprompt cachingは、安定したprefixをbreakpointまで再利用し、costとlatencyを抑える仕組みだ。default TTLは30分。けれど公式docsは、cacheがoutput tokenの生成方法を変えるものではないと説明している。

cacheはAgentを賢くするというより、同じ賢さを何度も払える価格で運ぶ設備だ。

品質、速度、costは、同じ箱へ雑に入れず、別々に測った方がいい。

高得点harnessにも、別の落とし穴がある

SAME-MODEL A/Bmodelを固定すると、仕組みの差が見える。

同じtask、同じbudget、同じdataで、harnessだけを一層ずつ変える。

01BASELINE現行の走路
02ADD ONE LAYER一つだけ変更
03HOLDOUT初見taskで再測定

では、benchmarkへ合わせてharnessを作り込めばよいのか。

ここには強い留保がある。

ARC Prizeのtechnical reportは、公開environmentを知った上で作ったtask-specific harnessが、seen taskで大幅にscoreを伸ばしても、unseen environmentへ一般化しない危険を説明している。同じmodelで、ある公開environmentは0%から97.1%へ上がった一方、別のenvironmentでは0%のままだった例も示した。

だからOpenAIの38.3%を無価値だと言うのではない。

OpenAIが使ったretained reasoningとcompactionは、特定gameの攻略ruleではなく、同社製品でも使う一般的なcontext機構だと説明されている。ただし、公開taskで得た上昇が、未知taskや自社業務へ同じ率で移ることまでは証明していない。

良いharnessとは、benchmarkだけに勝つ仕掛けではない。仕事が変わっても、失敗を減らせる仕組みだ。

モデルを替える前にやる、same-model A/B test

この話を、自社のAgentへ持ち帰る方法はシンプルだ。

modelを固定して、harnessだけを変える。

Step 1.比較条件を凍結する

同じmodel ID、reasoning effort、tool version、data snapshot、permission、budgetを使う。実務から20〜50件ほどの代表taskを選び、何が揃えば成功かを先に決める。

Agentには揺らぎがある。重要なtaskは複数回走らせ、一度だけ出たbest runを実力と呼ばない。

Step 2.現行harnessをbaselineにする

task successだけでなく、evidence coverage、token、latency、cost、tool call、retry、人間が救助した回数、許可されていないactionを記録する。

「回答が良かった」だけでは、どこが改善したか分からない。

Step 3.一層ずつ変える

persisted reasoningを入れる。次にcompaction。次にtool schemaとerror contract。次にcheckpointとsuccess receipt。

filterや集計が大量なら、その区間だけprogrammatic tool callingへ移す。独立したworkstreamならmulti-agentを試す。cacheは最後に、品質ではなくcostとlatencyの列で測る。

全部同時に入れると、どれが効き、どれが壊したか分からなくなる。

Step 4.失敗の名前を残す

平均点だけでなく、失敗を分類する。

目的を忘れた。証拠を落とした。toolを誤用した。同じ処理を繰り返した。timeoutから戻れなかった。終わっていないのに完了と言った。

名前がつけば、modelを替えずに直せる失敗が見えてくる。

Step 5.初見のtaskでもう一度測る

改善に使っていないholdout taskで再測定する。task familyも変える。tool timeout、permission error、long context、partial resultを意図的に入れ、戻れるかを見る。

METRは、Agent能力を「人間の専門家ならどれくらい時間がかかるtaskを、50%の確率で完了できるか」というtime horizonで測っている。同団体は、Agentがsingle stepの知識より、長いaction sequenceをつなぐところで苦戦しやすいと説明する一方、測定値はtaskの分布や方法論に依存するとも留保している。

自社Agentでも同じだ。

公開benchmarkは健康診断になる。けれど、実際に任せたい仕事でのA/B testが、最後の診断書になる。

次に買うべきものは、新しい頭脳とは限らない

NAME THE FAILURE平均点より、失敗の名前が改善点を教える。

忘却、tool誤用、重複実行、復旧不能、未完了の完了報告をreceiptとして残す。

  1. 01忘れた
  2. 02誤用した
  3. 03繰り返した
  4. 04戻れない
  5. 05終わっていない

Agentが失敗すると、私たちはすぐ上位modelを探す。

もちろん、本当にmodel能力が足りないことはある。理解できない。推論できない。必要なmodalityを扱えない。そこはmodel upgradeが効く。

でも、同じ調査を繰り返す。古い指示へ戻る。tool outputに埋もれる。途中の成功を失う。完了条件を満たさず止まる。

それは、頭脳より先に、働く環境を疑うべき症状かもしれない。

OpenAIの13.3%から38.3%という数字が教えるのは、「GPT-5.6は3倍賢い」ということではない。

同じ知能でも、記憶の渡し方、道具の契約、復旧地点、採点方法によって、現実へ届く力は変わる。

次のmodelを待つ前に、同じmodelで二本の走路をつくってみる。

一方は今のまま。もう一方には、continuity、compaction、明確なtool contract、checkpoint、receiptを置く。

そして同じ仕事を走らせる。

その差を見た時、AI Agentの「賢さ」が、これまでよりずっと広い場所に見えてくるはずだ。


本稿は2026年8月20日時点の公開情報に基づく。ARC-AGI-3の38.3%はOpenAIが公開task上の独自harness実験として報告した値であり、ARC Prizeのsemi-private setにおける独立verified scoreではない。機能効果はtask、tool、prompt、budget、評価方法によって変わる。