📚 GPT-6 Astra × Harness シリーズ

1. 基礎編
GPT-6 Astra、ARC-AGI-3で99.9%──なぜこれから「プロンプト」より「エージェントアーキテクチャ」が重要になるのか

2. 概念編
GPT-6 Astra、ARC-AGI-3で62.7%→99.9%のその先──Harnessの1階上「Loop Engineering」を対話で理解する

3. 実装編 ← いまここ
GPT-6 Astra、ARC-AGI-3で99.9%を記録した「Provider Adapter harness」を、自分で作るとしたら？

「前回の記事で紹介した『GPT-6 AstraのStandard harness 62.7%とProvider Adapter harness 99.9%の比較』って、自分でも作れるんですか？」

「作れる。ただし、“何を作れるのか”を最初に正確にしておこう」

「というと？」

「ARC PrizeがGPT-6 Astraの評価に使ったProvider Adapter harnessと完全に同一のものを再現した、とは簡単には言えない」

「では、何が作れるんですか？」

「Providerが用意したConversation State、Reasoning State、Compactionなどを使って、同じ設計思想を持つProvider Adapter型のHarnessを作ることはできる」

「それには？」

「GPT-6 Astraで実際に試すなら、OpenAI APIを使う」

この記事の要点

ARC Prizeの99.95%は「Provider Adapter harness × High Reasoning」の組み合わせで得られたVerified Result
Provider Adapter harnessは、Provider-nativeなConversation / Reasoning State / Compactionを利用するHarness Mode
Provider内部の機能そのものは作れないが、それを利用するHarnessは自分で作れる
OpenAIなら previous_response_id / conversation / reasoning.encrypted_content / /responses/compact が入口になる
ただし、自作Harnessで99.95%が再現できるという話ではない

まず、この記事で「作る」と言っているもの

最初に境界を明確にしておきたい。

この記事は、

ARC PrizeがGPT-6 Astraで99.9%を記録したProvider Adapter harnessを完全コピーして、同じ99.9%を再現する

という記事ではない。

この記事で考えるのは、

Provider固有のContext管理機能を使って、Agentが複数のRequestをまたいで仕事を継続できるHarnessを、自分のアプリケーション側で作る

というものだ。

ARC PrizeはProvider Adapter harnessを、Providerが設計したContext Management機能を使用する評価条件として定義している。

Standard harnessがProvider-neutralなInterfaceを使うのに対し、Provider Adapter harnessでは、opaque reasoning stateの保持や長いConversationでのCompactionといったProvider-nativeな機能を利用する。

📖 ARC Prize公式「Verified Testing Policy」でStandard harnessとProvider Adapter harnessの定義を確認する

そもそも「99.9%」とは何だったのか

「その前に、前回の62.7%→99.9%をもう一度整理していいですか？」

「ここは重要だ」

ARC Prizeが公開しているGPT-6 AstraのVerified Resultsでは、ARC-AGI-3 Semi-Privateについて次の結果が掲載されている。

Reasoning Level	Standard harness	Provider Adapter harness
Max	62.71%	98.55%
XHigh	59.34%	98.44%
High	54.82%	99.95%
Medium	38.59%	98.44%
Low	17.45%	98.03%
None	35.18%	96.72%

📖 ARC Prize公式「GPT-6 Astra - ARC-AGI Results」でHarness別のVerified Scoresを確認する

「99.95%はHighなんですね」

「そう」

ここは誤解しやすい。

Standard harnessのbest observed resultである62.71%は Max。

Provider Adapter harnessのbest observed resultである99.95%は High。

したがって、62.71% → 99.95% という並べ方は、Harnessだけを変えた完全なA/Bテストではない。

同じ Max 同士で比較すると、こうなる。

条件	Reasoning Level	Score
Standard harness	Max	62.71%
Provider Adapter harness	Max	98.55%

それでも非常に大きな差である。

ARC Prize自身も、Provider Adapter harnessのbest observed scoreについて62.7%から99.9%へ上昇した、と整理している。

ただし記事として書くときは、Reasoning Levelも一緒に示した方が誤解が少ない。

だからこの記事のタイトルも、「99.9%まで引き上げた」ではなく「99.9%を記録した」としている。Harnessだけに因果を帰属させないためだ。

Provider Adapter harnessは、何を変えたのか

「では、本題です」

「Standard harnessと何が違うと思う？」

「プロンプト？」

「もっと外側だ」

ARC-AGI-3は、一問一答で終わるBenchmarkではない。

未知の環境を観察し、Actionを実行し、その結果を見て、また次のActionを考える。

つまり、1つのTaskの中でModel Callが何度も発生する。

そこで問題になる。

前のRequestで分かったことを、次のRequestへどう持ち越すのか？

ARC PrizeのOpen Source Benchmarking Repositoryでは、Standard harnessとProvider Adapter harnessの違いをかなり明確に説明している。

Harness	Mode	状態の持ち方
Standard harness	`manual_rolling`	Provider-neutralなText History。Model自身が残したい発見をvisible notesとして保持
Provider Adapter harness	`continuous_conversation`	ProviderのNativeなConversation / Reasoning State / Compactionを利用

📖 ARC Prize公式GitHub「arc-agi-3-benchmarking」でStandard / Provider Adapter harnessの実装方針を確認する

「つまり、“履歴を持つ”こと自体は両方やっている？」

「そう。違うのは誰が、どの形式で状態を管理するかだ」

Standard harnessを人間に例えると「攻略ノート」

Standard harnessでは、Modelが次のような重要な発見をTextとして残す。

このスイッチを押すと扉が開く
赤いマスは危険
右上の数字は残りAction数

概念的には、こうなる。

「ゲームを攻略しながら、自分で攻略ノートを書く？」

「大まかにはそう」

Providerに依存しないので、複数Modelを同じ条件で比較しやすい。

これはBenchmarkとして非常に重要な性質だ。

Provider Adapter harnessでは「Provider側の記憶装置」も使う

一方、ARC PrizeはGPT-6 AstraのProvider Adapter harnessについて、

opaque reasoning stateをRequest間で保持し、長いConversationではCompactionを利用する

と説明している。

ここで重要なのが opaque だ。

「Reasoning Stateを保存するなら、AIの思考過程を全部こちらで読めるんですか？」

「違う」

opaque reasoning stateは、開発者がModelの内部思考をText Fileとして読み書きする、という意味ではない。

ARC Prize自身も “which we don't see” と説明している。

つまりイメージは、こうなる。

Harness側がModel内部のReasoningを直接管理するのではない。

Providerが用意した状態継続機能を、Harnessから利用する。

これが重要なポイントだ。

では、自分でも作れるのか

「ここまで聞くとProviderしか作れないようにも聞こえます」

「Providerの内部機能そのものは作れない。でも、それを利用するHarnessは作れる」

ARC PrizeのBenchmarking Repository自体もOpen Sourceで公開されており、MIT Licenseで利用できる。さらに、Repositoryを実際に動かす場合は各Model ProviderのAPI Keyを設定する構成になっている。

例えばOpenAIなら OPENAI_API_KEY を設定してModelを呼び出す。

📖 ARC Prize公式のOpen Source Benchmarking Repositoryを見る

つまり「Provider Adapter harness ＝ Provider内部のModelを改造する」ではない。

より正確には、次のような接続層を作る。

GPT-6 AstraならResponses APIが入口になる

「OpenAIの場合、具体的には何を使うんですか？」

「Responses APIだ」

OpenAI公式はGPT-6 Astraを使う場合、model = "gpt-6-astra" としてResponses APIを使用できることを案内している。

またGPT-6 Astraは、persisted reasoningやCompactionなど、長時間Workflowに関係する機能をサポートしている。

📖 OpenAI公式「Using GPT-6 Astra」でResponses APIと対応機能を確認する

最小の呼び出しは、例えばこうなる。

minimal_call.py

from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-6-astra",
    input="この問題を分析してください。",
)

print(response.output_text)

「でも、これは1回呼んで終わりですよね？」

「そう。ここからHarnessになる」

最初の重要部品：`previous_response_id`

Responses APIには previous_response_id がある。

OpenAI公式では、前回のResponse IDを指定してMulti-turn Conversationを作るための機能として定義されている。

chain_responses.py

from openai import OpenAI

client = OpenAI()

first = client.responses.create(
    model="gpt-6-astra",
    input="この問題を調査してください。",
)

second = client.responses.create(
    model="gpt-6-astra",
    previous_response_id=first.id,
    input="今わかったことを使って、次の一手を考えてください。",
)

print(second.output_text)

こうすると、Chainを作れる。

📖 OpenAI公式Responses APIで「previous_response_id」の仕様を確認する

「つまり、過去のConversation全文を毎回自分で連結し直さなくてもいい？」

「そういうServer-managed continuationを選べる」

`conversation`という別のState管理方法もある

Responses APIにはもう一つ、conversation という方法もある。

Conversation Objectを作成し、そのConversation IDに対してRequestを紐づける。

Responses APIではConversation内のItemが次のResponseのContextへ追加され、Responseで発生したInput / OutputもConversationへ追加される。

概念的には、こうなる。

Conversation ID
      │
      ├─ User Turn 1
      ├─ Assistant Turn 1
      ├─ Tool Result
      ├─ User Turn 2
      └─ Assistant Turn 2

previous_response_id と conversation は同時には使えない。OpenAI公式API Referenceにも明記されている。

「どっちを使えばいい？」

「それがHarness設計になる」

方式	性質
`previous_response_id`	前Responseから軽量にChainをつなぐ
`conversation`	名前を持ったConversation ResourceとしてServer側で管理する

重要なのは、Stateの所有者を決めることだ。

ここで一つ、名前が似ているので注意

ARC PrizeのRepositoryには continuous_conversation という名前が出てくる。

OpenAI Responses APIには conversation というParameterがある。

「同じものですよね？」

「同じ名称の機能だと決めつけない方がいい」

用語の混同に注意

ARC Prizeの continuous_conversation は、Benchmarking Harness側でProvider-nativeなConversation / Reasoning State / Compactionを利用するHarness Modeの名称
OpenAIの conversation は、Responses APIが提供する具体的なAPI Parameter / Resource

この2つをそのまま同一視するのは避けた方がいい。

本記事では、

Provider-nativeな状態継続を利用する考え方

というレベルで接続している。

次の重要部品：Reasoning State

OpenAIのResponses APIでは、reasoning.encrypted_content をResponseに含めることもできる。

公式API Referenceでは、これはEncryptedなReasoning TokenをReasoning Itemに含めるもので、store=false やZero Data Retention環境など、StatelessなResponses API利用時でもMulti-turn ConversationへReasoning Itemを引き継げるようにするための機能と説明されている。

ここでも「AIの思考過程を開発者が読む」のではない。

Encrypted / opaqueなStateを、次の推論へ継続利用するという位置づけになる。

ARC Prizeが説明する opaque reasoning state という考え方と接続する部分だ。

ARC PrizeのAstra Provider Adapter harnessが、公開Responses APIのどのParameterをどの組み合わせで使って99.95%を出したかは、内部実装のすべてが公開資料だけから確定できるわけではない。

したがって本記事では、OpenAI APIで公開されている実装可能な構成要素として紹介している。

そして重要なのがCompaction

「Conversationをずっとつなげれば、それでいいのでは？」

「長時間動かすと別の問題が出る」

Contextは無限ではない。

何百Turn、何千Turnと仕事を続ければ、保持する情報は増える。

そこで必要になるのが Compaction だ。

OpenAIは現在、POST /responses/compact を公開している。

このEndpointは長いConversationをCompactし、Compacted Response Objectを返す。

📖 OpenAI公式「Compact a response」でCompaction APIの仕様を確認する

Python SDKにも client.responses.compact(...) が用意されている。

概念的には、こう書ける。

compaction.py

compacted = client.responses.compact(
    model="gpt-6-astra",
    previous_response_id=response.id,
)

継続してきたResponse ChainをCompactする、というイメージだ。

Compactionは「会話を日本語で要約する」ことではない

「それなら、LLMに『ここまでを1000文字で要約して』と頼めばいいのでは？」

「そこが違う」

OpenAIのCompactionは、単純に人間が読むSummary Textを生成する仕組みではない。

Compacted ResponseのOutputには、次のようなOpaqueなCompaction Itemが含まれる。

type = "compaction"
encrypted_content = "..."

つまり、こういうものではない。

100ターンのConversation
        ↓
「1000文字に要約して」
        ↓
summary.txt

イメージとしては、こうなる。

OpenAIもCompactionについて、Continuationのために使い、内部構造を解析するものではないという方針を示している。

ここまで来るとProvider Adapter型Harnessが見えてくる

「部品は分かりました」

「では、つなげてみよう」

自分で作る最小のProvider Adapter型Harnessは、概念的にはこうなる。

「APIを呼ぶ部分だけじゃないんですね」

「そう。その周囲の制御ロジックがHarnessだ」

自分で作るのは、主に「外側」

Providerが担当する部分と、自分が担当する部分を分けると分かりやすい。

レイヤー	主な責任
GPT-6 Astra	推論・Action選択
OpenAI	Model、opaque reasoning state、Responses API、Compactionなど
自分のProvider Adapter / Harness	State接続、Tool実行、Retry、終了判定、永続化、Compaction Policyなど
Application	実際の業務・UI・Workflow

つまり、自分が作るのは主に次の制御だ。

いつModelを呼ぶ？
何を渡す？
どのResponseへつなぐ？
どのToolを実行する？
失敗したらどうする？
いつCompactする？
どこまで進んだら完了？
途中状態をどこへ保存する？

Provider Adapterという名前の意味も見えてくる

「なぜ“Adapter”なんですか？」

「Providerごとに状態管理の方法が違うからだ」

例えば自分のAgentからは、次のような共通Interfaceで扱いたい。

provider_interface.py

send()
continue_task()
execute_tool()
compact()
save_state()

しかし、その下ではProviderによってAPIが違う。

概念的には、こうなる。

「Agent側はProviderの違いをなるべく意識しない？」

「そう。その差を吸収する層がAdapterになる」

実際には「State Ownership」を決める必要がある

ここは実装するときにかなり重要だ。

Stateを管理する方法は一つではない。

方法	Stateの正本を持つ場所
Applicationが全履歴を保持	自分のApplication
`previous_response_id` で継続	OpenAI側（Response Chain）
`conversation` で管理	OpenAI側（Server-side Conversation）

これらを無計画に全部同時に使うと、同じContextを二重に渡すなどの問題が起こり得る。

OpenAI Agents SDKの設計資料でも、Conversation Stateの所有者を一つ選ぶことが重要だと整理されている。

概念的には「誰がConversation Stateの正本を持つのか？」を最初に決める。

これはHarness Engineeringそのものだ。

Toolを組み合わせると「Agent」になる

例えばソフトウェア開発なら、単にConversationを続けるだけでは足りない。

Agentは外部世界へActionする必要がある。

Responses APIはCustom Function CallingやBuilt-in Toolsを利用できるため、Harness側でTool Execution Loopを組める。

Provider Adapter型Harnessにすると、次の要素をまとめて次のActionへつなげられる。

Response State
Tool Result
Reasoning State
Compaction

「Compactionをいつするか」もHarnessの仕事

「Contextが長くなったら毎回Compactすればいいですか？」

「それも設計次第だ」

OpenAIはCompactionについて、長時間Sessionで繰り返し利用できる一方、Context Usageを監視し、大きなMilestoneやTool-heavyなPhaseの後など、計画的に行うことを案内している。

つまり、この判断ロジックそのものもHarnessになる。

compaction_policy.py

if context_is_large:
    compact()

Responses APIには現在、context_management というRequest設定もあり、Context Management Configurationを指定できる。

Providerが機能を用意していても、どのPolicyで利用するかはApplication / Harness側の設計問題として残る。

APIが必要な部分と、APIなしでも作れる部分

「つまり、勉強だけならAPIはいらない？」

「そう」

整理するとこうなる。

やりたいこと	OpenAI API
Provider Adapter harnessの概念を理解する	不要
State Machineを設計する	不要
Mock ModelでLoopを作る	不要
Adapter Interfaceを設計する	不要
GPT-6 Astraを実際に呼ぶ	必要
`previous_response_id` を使う	必要
OpenAI Conversations APIを使う	必要
OpenAIのReasoning State継続機能を使う	必要
`/responses/compact` を使う	必要

ARC Prizeの公式Repositoryを実際のProvider Modelで動かす場合も、Provider API Keyを設定する手順になっている。

したがって、

Provider Adapter型Harnessそのものは自分で設計できる。GPT-6 Astra固有のProvider-native機能を実際に利用する段階でOpenAI APIが必要になる。

という整理が正確だ。

では、99.9%も再現できるのか？

「ここまで作れば、ARC-AGI-3で99.9%も出せますか？」

「そこは言えない」

ここは明確に区別する必要がある。

ARC Prizeの99.95%は、次の組み合わせで得られたVerified Resultだ。

GPT-6 Astra
ARC-AGI-3の評価環境
Provider Adapter harness
High Reasoning
ARC Prizeの指定Action Space
指定された評価条件

自分のApplicationで previous_response_id と Compaction を使ったからといって、99.95%を再現できる保証はない。

さらに、ARC Prizeが使用したProvider Adapter harnessの内部挙動を、公開APIだけから完全に同一だと証明できるわけでもない。

だから、この記事で作ろうとしているものを正確に表現すると、

ARC Prizeが説明しているProvider Adapter harnessと同じ方向性――Provider-nativeなContext Managementを活用するHarness

となる。

それでも「自作できる」という事実は重要

「完全再現ではないなら、作る意味はありますか？」

「むしろ、ここからが実務では重要だ」

ARC-AGI-3の数字そのものを再現することが目的ではない。

実務で重要なのは「AIが一度考えて終わる」のではなく、次のWorkflowを安定して続けられることだ。

例えばCoding Agentなら、こういう長い仕事になる。

そこで、次の情報を失わない設計が重要になる。

過去に何を調べた？
何を試した？
なぜ失敗した？
今どこまで進んだ？
次に何をする？

Provider Adapter型Harnessは、その土台の一つになる。

ここで前回の記事につながる

「前回の記事で、“モデル性能≠システムの実効性能”という話がありましたよね」

「そう」

前回の記事では Which model? だけではなく How is the agent designed? を見るべきではないか、という話をした。

今回、その「Agentをどう設計するか」が少し具体的になった。

Modelを選ぶだけではない。

Modelが能力を発揮できる環境を作る。

それがHarness Engineeringだ。

さらに外側へ進むと「Loop Engineering」

「では、このHarnessを作れば完成？」

「もう一段、外側がある」

Provider Adapter型Harnessによって、一体のAgentが長時間仕事を継続できるようになったとする。

次に出てくる問いは、こうだ。

そのAgentをいつ起動する？
何のTaskを渡す？
失敗したら誰に戻す？
誰がReviewする？
次のTaskは誰が決める？

ここまで行くと、一体のAgentの内部設計ではなく「Agentをどう継続的に働かせるか」というWorkflow設計になる。

Provider Adapter harnessはLoop Engineeringそのものではない。

しかし、長時間動くAgentを成立させる重要な土台の一つとして見ることができる。

最初に自作するなら、どこまで作る？

「実際に試すなら、いきなりARC-AGI-3を再現しますか？」

「そこまでやる必要はない」

最初の検証なら、この程度でよい。

GPT-6 AstraへTaskを渡す
Response IDを保存する
次のObservationを渡す
previous_response_id で継続する
数Turn続ける
Compactionを実行する
その後もTaskを継続できるか確認する

これだけでも「毎回ゼロからPromptする」方式と「Provider-nativeなStateを使って継続する」方式の違いを体験できる。

その後、次の要素を追加していけば、実用的なHarnessへ近づいていく。

Tool Calling
Retry
Checkpoint
Persistent State
Termination Condition
Observability

Provider Adapter harnessから学べる本質

「結局、一番重要なのは何ですか？」

「API名ではない」

previous_response_id が重要なのでもない。

Compaction APIを知っていることだけでもない。

重要なのは、

Modelに毎回すべてを説明し直すのではなく、Modelが仕事を継続できるState Managementそのものを設計対象として考える

という発想だ。

従来の発想をかなり単純化すると、こうだった。

Provider Adapter型Harnessでは、こうなる。

設計対象が、回答から継続するプロセスへ変わる。

おわりに

「では、Provider Adapter harnessは自分でも作れる？」

「正確に答えるなら、こうだ」

Provider Adapter harnessと同じ設計思想を持つHarnessは、自分で実装できる。

OpenAIの場合なら、次のProvider-nativeな機能を利用できる。

Responses API
previous_response_id
Conversation
persisted reasoning
Compaction
Tool Calling

その外側に、自分で次を設計する。

State Management
Tool Execution
Retry
Checkpoint
Compaction Policy
Persistence
Termination

ただし、ARC PrizeのProvider Adapter harnessと完全に同一の実装を再現した、と安易に主張してはいけない。

そして、自作Harnessを使えばARC-AGI-3で99.95%を再現できる、とも言えない。

そこは別の話だ。

それでも、GPT-6 Astraの結果から得られる示唆は大きい。

同じModelでも、Max同士で 62.71% → 98.55% という大きな差が確認されている。

Provider Adapter harnessのbest observed resultは、High の 99.95% だった。

Modelそのものだけを見ていては、この結果を説明できない。

だから、これからAgentを作るときは Which model? だけではなく、次まで見る必要がある。

How is the state managed?
How is the context continued?
How is the harness designed?

そして、そのHarnessを継続的な仕事として回し始めると、次の問いが出てくる。

How is the loop designed?

Modelを選ぶ。

その次は、Modelが能力を発揮できるHarnessを作る。

そしてさらに、そのHarnessを持つAgentが、仕事を継続できるLoopを設計する。

GPT-6 Astraの99.9%は、単なるBenchmarkの数字ではなく、

AI開発の設計対象が「Modelの内側」から「Modelの外側」へ広がっていることを考える、非常に分かりやすい教材

なのかもしれない。

参考資料