「前回の記事、覚えていますか？」
「GPT-6 AstraがARC-AGI-3で99.9%を出した話ですよね」
「そう」
「しかも、同じGPT-6 Astraなのに62.7%という結果もあった」
「そうだ」
「違ったのは、モデルではなくharnessだった」
「そこまで覚えているなら話が早い」
前回の記事では、GPT-6 AstraのARC-AGI-3評価を入口に、
「どのモデルを使うか」だけでは、AIシステムの実効性能は決まらない
という話をした。
「でも、ひとつ気になっていることがあります」
「何？」
「前回出てきたProvider Adapter harnessって、最近聞く"Harness Engineering"そのものなんですか？」
「いや。そこは分けて考えた方がいい」
「違うんですか？」
「そして、さらにその上にもう一つ面白い考え方がある」
「上？」
「Loop Engineeringだ」
この記事の要点
先に結論を整理しておく。
- Provider Adapter harness は、ARC PrizeがARC-AGI-3評価で使っている具体的な評価harness
- Harness Engineering は、モデルの周囲にTools、Skills、Hooks、Context管理、Sandbox、Subagentsなどを設計する、より広い考え方
- Loop Engineering はAddy Osmaniの整理では、そのHarnessの「1階上」に位置する
- Loop Engineeringでは、人間が毎回Agentへ指示するのではなく、Agentへ指示する仕組みそのものを設計する
「Prompt → Context → Harness → Loop」という並びは、業界で正式に標準化された成熟度モデルではありません。
本記事では、これらの概念を理解しやすくするための 整理図 として使用します。
前回のおさらい──同じGPT-6 Astraで62.7%と99.9%
「まず、62.7%と99.9%の話をもう一度確認していいですか？」
「もちろん」
2026年9月、ARC PrizeはGPT-6 AstraのARC-AGI-3評価結果を公開した。
ARC PrizeのVerified Resultsでは、GPT-6 Astraについて次のbest observed resultが掲載されている。
| 評価条件 | Reasoning | ARC-AGI-3 Semi-Private |
|---|---|---|
| Standard harness | Max | 62.7% |
| Provider Adapter harness | High | 99.9% |
ARC Prize公式「GPT-6 Astra - ARC-AGI Results」──各Reasoning LevelとHarness別の検証済み結果
「同じモデルなのに約37ポイントも違う」
「そう。ただし、一つ注意が必要だ」
「何ですか？」
「62.7%と99.9%ではReasoning Levelも違う」
Standard harnessの62.7%はMax、Provider Adapter harnessの99.9%はHighです。
したがって 「Harnessだけを変えた完全なA/Bテストで62.7%→99.9%になった」 と表現するのは正確ではありません。
ただし、同じMax同士でも、
- Standard harness：62.7%
- Provider Adapter harness：98.6%
という大きな差が確認されている。
ARC Prize自身も、Provider Adapter harnessによってAstraのbest observed scoreが62.7%から99.9%へ上昇したと説明している。
「なるほど。99.9%だけを見るより、Harnessによって結果が大きく変わることを見るべきなんですね」
「そう。それが前回の記事の出発点だった」
では、Provider Adapter harnessとは何なのか
「名前だけ見ると、ものすごく大きな仕組みに見えます」
「でもARC Prizeが指しているものは、かなり具体的だ」
ARC PrizeはARC-AGI-3で、2種類の評価条件を区別している。
Standard harness
Providerに依存しない、共通の最小インターフェースを使う。
モデルは必要だと判断した情報を visible notes として残し、それを環境内で持ち越す。
visible notes
モデル自身が書くテキストのメモ。
人間も読めるし、harness側も中身を扱える。
ただし、何を書き残すかはモデルの判断に委ねられる。
重要な気づきを書き忘れれば、次のリクエストにその情報は届かない。
Provider Adapter harness
各AI Providerが設計したContext管理機能を利用する。
GPT-6 Astraの場合、ARC Prizeは具体的に、
- リクエスト間で opaque reasoning state を保持する
- 長いConversationでは compaction を利用する
と説明している。
opaque reasoning state
テキストのメモではない。
モデルが考えた過程そのものをProvider側が保持し、次のリクエストへ引き継ぐ。
opaque（不透明）と呼ばれるとおり中身は読めないが、モデルは「何をメモに残すか」を選ぶ必要がない。
visible notesが「モデルが選んで書いた結果」なのに対し、reasoning stateは「モデルが考えた過程そのもの」だ。
compaction
会話が長くなったときの仕組み。
古い部分を要約された形へ置き換え、必要な状態を保ったままContextの量を抑える。
単純に古い発言を捨てるのではなく、要約して残す点が重要になる。
長い試行錯誤が必要な課題ほど、この差が効いてくる。
ARC Prize公式「OpenAI's GPT-6 Astra on ARC-AGI-3」──Standard harnessとProvider Adapter harnessの違い
両者の差は、リクエストをまたいで何を持ち越すか に現れる。
同じモデルが同じ課題を解いていても、次のリクエストへ渡る情報の質と量が違う。
違いは2点。中身が読めるかどうか、そして 何を残すかをモデルが選ぶ必要があるかどうか だ。
さらにARC PrizeのTesting Policyでも、Provider Adapter harnessは provider-designed context-management featuresを利用する評価条件 として明確に区別されている。
ARC Prize Verified Testing Policy──ARC-AGI-3における2種類のHarness定義
「つまりProvider Adapter harnessは、ARC-AGI-3用の具体的な評価Harness？」
「そう考えるのが正確だ」
「では、"Harness Engineering"とは違う？」
「ここから話のスケールが一段大きくなる」
Harness Engineeringは、もっと広い
Addy Osmaniは2026年4月の記事「Agent Harness Engineering」で、Coding Agentを AI Model + その周囲に構築された仕組み として捉えている。
Addy Osmani「Agent Harness Engineering」──Agent Harnessを構成する要素の整理
「周囲の仕組み？」
「例えばこういうものだ」
Addyの整理ではHarnessには、
- System Prompt
-
CLAUDE.md/AGENTS.md - Skills
- Tools
- MCP servers
- Filesystem
- Sandbox
- Browser
- Subagent orchestration
- Hooks
- Middleware
- Compaction
- Observability
- Feedback loops
- Recovery paths
などが含まれる。
つまり、かなり広い。
概念的には、こういうイメージになる。
「Provider Adapter harnessにもcompactionがありましたよね？」
「そう」
「じゃあHarness Engineeringの一種では？」
「関連はある。ただし、同義語として扱わない方がいい」
ここがこの記事で一番誤解してほしくないところです。
- ARC Prizeの Provider Adapter harness は、ARC-AGI-3における具体的な評価条件の名称
- Harness Engineering は、Agentが能力を発揮するための周辺システム全体を設計・改善する、もっと広い考え方
ARC Prizeが「Provider Adapter harness = Harness Engineering」と定義しているわけではありません。
したがって本記事では、次のような 具体例から一般的な設計概念への橋渡し として扱う。
そして出てくる「Loop Engineering」
「Harness Engineeringまでなら分かりました」
「では質問だ」
「はい」
「そのHarnessを使うAgentに、毎朝人間が同じ指示を出していたら？」
「……結局、人間が毎回起動しないと仕事が始まりません」
「そこだ」
2026年6月、Addy Osmaniは「Loop Engineering」という記事を公開した。
冒頭で、Loop Engineeringをかなり端的に説明している。要するに、
AgentにPromptする人間自身を、仕組みに置き換えていく
という発想だ。
Addy Osmani「Loop Engineering」──AgentをPromptする仕組み自体を設計する考え方
「人間がPromptを書かない？」
「完全に書かなくなる、という意味ではない」
「では？」
「毎回人間が"次はこれをやって"と操作するのではなく、次に何をさせるのかを決めるシステムを作る」
Addyは、その仕組みを例えばこう説明している。
そして決定的なのが、この位置づけだ。
Addy OsmaniはLoop Engineeringについて、Harnessの「1階上」に位置する と明確に説明している。
「1階上？」
「そう」
HarnessとLoopの違いを会社に例えてみる
「まだ少し抽象的です」
「では、AI Agentを一人のエンジニアだと考えてみよう」
Model
そのエンジニアの 頭脳。どれだけ考えられるか。
Context
今、机の上に置いてある 資料や前提知識。仕様書、Issue、過去の会話、コードなど。
Harness
エンジニアが仕事をするための 仕事環境。
IDE
Git
テスト環境
ブラウザ
社内ルール
チェックリスト
作業手順
レビュー担当
ログ
権限制御
などを含む。
Loop
そして、誰が、いつ、何の仕事を始め、誰が確認し、その結果をどう次の仕事につなげるか という 業務プロセスそのもの。
「つまり……」
「Harnessは"Agentが働く環境"」
「Loopは？」
「そのAgentをどう働かせ続けるかだ」
Addy Osmaniが挙げるLoopの構成要素
AddyはLoopを作るための主要な要素として、次を挙げている。
1. Automations
一定のタイミングや条件で仕事を開始する。
人間が毎回、
「調査して」
「CIを確認して」
「Issueを見て」
と指示しなくても、Loop側が仕事を発見する。
2. Worktrees
複数のAgentが並列で作業するとき、Gitの作業領域を分離する。
Agent AとAgent Bが同じファイルを同時に書き換えて衝突する、といった問題を抑える。
3. Skills
プロジェクト固有の知識や作業方法を毎回説明するのではなく、再利用可能な形で外部化する。
4. Plugins / Connectors
Issue Tracker、Database、Slack、APIなど、実際の業務システムへ接続する。
5. Sub-agents
作るAgentと、確認するAgentを分ける。
のように責務を分離する。
6. State / Memory
何をやったのか。
何が終わったのか。
何が失敗したのか。
次に何をするのか。
これらをConversationの外に残す。
Addyの整理では、MarkdownやLinearなどの外部Stateが、長時間動くLoopの記憶になる。
具体例で見ると、一気に分かりやすい
「普通のCoding Agentとの違いを見せてもらえますか？」
「例えばバグ修正なら、これまで人間はこうしていた」
「ずっと人間がAgentをPromptしていますね」
「そう」
Loop Engineeringでは、この Promptを送る側の仕事 も設計対象になる。
「人間が一つひとつ指示していない」
「そこが重要だ」
人間が設計する対象が、
AgentへのPrompt
から、
AgentへPromptを送り
結果を評価し
次のAgentへつなぐ仕組み
へ広がっている。
では「Provider Adapter harness = Loop Engineering」なのか？
「ここまで聞くと、Provider Adapter harnessもContextを継続しているので、Loopに見えます」
「似ている部分はある。でも同じではない」
Provider Adapter harnessは、Astraが1つの環境内で仕事を続けるために、
- reasoning stateを保持する
- compactionする
- それまでの作業を再利用する
といったContext管理機能を利用する。
一方、Loop Engineeringではさらに外側で、
まで設計する。
したがって、この記事ではこう整理する。
これは各組織が定めた公式アーキテクチャ図ではなく、本記事で概念の違いを理解しやすくするために整理した図 です。
Prompt Engineeringは終わるのか？
「では、いよいよPrompt Engineeringは不要になりますか？」
「ならない」
「やっぱり」
PromptはLoopの中にも存在する。
Skillにも指示がある。
Sub-agentにも役割Promptがある。
Evaluatorにも評価基準がある。
だから、Prompt Engineeringが不要になる のではない。設計対象が広がる。
例えば従来は、
を中心に考えていた。
しかしAgent時代には、
まで考える必要が出てくる。
Prompt → Context → Harness → Loop
「ここまでを一枚で整理できませんか？」
「できる。ただし、これは正式な業界標準ではない」
この記事では理解のため、設計対象の広がりを次のように整理してみる。
| 考え方 | 主な問い |
|---|---|
| Prompt Engineering | AIに 何と指示するか |
| Context Engineering | AIに 何を知らせるか |
| Harness Engineering | AIを どんな環境・仕組みで働かせるか |
| Loop Engineering | AIを どう継続的に働かせ、次の仕事へつなぐか |
図にすると、
となる。
繰り返しますが、これはPrompt EngineeringからLoop Engineeringへ進化するという公式な成熟度モデルではありません。
複数の概念を理解しやすくするための、本記事での整理です。
実際にはこれらは重なり合う。
Harnessの中にもContext Engineeringは存在する。
Harnessの中にもLoopは存在する。
Addy OsmaniのHarness Engineeringの記事でも、feedback loopsやlong-horizon executionはHarnessの構成要素として扱われている。
そのうえでLoop Engineeringでは、さらに視点を外側へ移し、Harnessを持つAgent自体を、継続的な業務システムの部品として扱う と考えると理解しやすい。
実は、前回の記事の最後にすでに入口があった
「そういえば前回の記事、最後は何て終わっていましたっけ？」
「こんな問いを置いていた」
Which model?
だけではなく、
How is the agent designed?
そして将来的には、
How is the agent organization designed?
まで広がるかもしれない。
前回の記事では、ここまでだった。
今回のLoop Engineeringを知ると、How is the agent organization designed? という問いが、かなり具体的に見えてくる。
どのAgentが仕事を見つける？
誰が実装する？
誰がレビューする？
誰が「完了」を判定する？
失敗したら誰へ戻す？
状態をどこへ保存する？
次の実行は何をトリガーにする？
つまり、設計対象が 一体のAI Agent から、複数のAgentとWorkflowからなるAIシステム へ広がっている。
ただし、Loopを作れば人間が不要になるわけではない
「ここまで自動化できるなら、人間はもう見なくていい？」
「それはAddy自身が否定している」
Loop Engineeringの記事の後半では、むしろ自律化によって新しい問題が大きくなると指摘している。特に、
- Verification
- Comprehension debt
- Cognitive surrender
だ。
Agentが自動でコードを書く。
別Agentが自動でレビューする。
自動でPRを作る。
自動でIssueを閉じる。
便利だ。
しかし、Loopが間違えば、間違ったことも自動で高速に繰り返します。
だからLoop Engineeringとは、人間を消す技術 ではない。
むしろ、人間が毎回操作しなくても安全に仕事が進むよう、責任境界・検証・停止条件まで設計する技術 と考えた方がいい。
62.7% → 99.9%の「その先」
「ようやく前回の記事とつながりました」
「どうつながった？」
「GPT-6 Astraの結果から、モデルそのものだけを見てはいけないと分かった」
「うん」
「Provider Adapter harnessで、Contextの持たせ方や継続の仕組みが結果に大きく影響することが見えた」
「うん」
「そこから視野を広げると、Harness Engineeringがある」
「そう」
「さらに、そのHarnessを持ったAgentを、仕事の発見から検証、次の仕事まで自律的に回すのがLoop Engineering」
「その理解でいい」
整理すると、
Provider Adapter harnessからHarness Engineering、Loop Engineeringへ直接「進化した」という意味ではありません。異なる文脈の概念を、本記事の理解の流れとして接続しています。
これから問うべきこと
これまでは、
どのAIモデルが一番賢い？
という問いが中心だった。
次に、
どういうPromptを書けば能力を引き出せる？
となった。
そして、
どんなContextを与えるべきか？
どんなHarnessで動かすべきか？
へ広がっている。
さらにLoop Engineeringまで進むと、問いは、
そのAIが継続的に正しい方向へ進む仕組みを、どう設計するか？
になる。
「モデル選びの話ではなくなってきましたね」
「モデルはもちろん重要だ」
「でも、それだけではない」
「そう」
おわりに
前回の記事で見るべき数字は、
62.7% → 99.9%
だと書いた。
同じGPT-6 Astraでも、Harnessによって実効性能は大きく変わる。
今回、その話をもう一段外側から見ると、
という構造が見えてきた。
Provider Adapter harnessは、ARC-AGI-3における具体的な評価harness。
Harness Engineeringは、Agentを働かせる周辺環境全体を設計する考え方。
そしてAddy OsmaniのLoop Engineeringは、そのHarnessの「1階上」から、AgentをPromptする仕組みそのもの を設計する。
だから、これからAI Agentを考えるとき、
Which model?
だけでは足りない。
How is the agent designed?
さらに、
How is the loop designed?
まで考える必要が出てくる。
良いPromptを書く。
良いContextを与える。
良いHarnessを作る。
そして、AIが観察し、行動し、検証され、状態を残し、次の仕事へ進めるLoopを設計する。
AI開発の設計対象は、少しずつモデルの外側へ広がっている。
GPT-6 Astraの99.9%は、その変化を考える入口だったのかもしれない。
参考資料
前回記事
GPT-6 Astra、ARC-AGI-3で99.9%──なぜこれから「プロンプト」より「エージェントアーキテクチャ」が重要になるのか
GPT-6 AstraのStandard harness 62.7%とProvider Adapter harness 99.9%を入口に、「モデル性能」と「システム全体の実効性能」を分けて考えた前回記事。
ARC Prize — GPT-6 Astra評価
OpenAI's GPT-6 Astra on ARC-AGI-3
Standard harnessとProvider Adapter harnessの目的・仕組み・評価結果を説明したARC Prize公式記事。
ARC Prize — Verified Results
GPT-6 Astraについて、Reasoning Level別・Harness別の検証済みスコアを確認できる公式結果ページ。
ARC Prize — Testing Policy
ARC Prize Verified Testing Policy
Standard harnessとProvider Adapter harnessをどのような評価条件として扱っているかを説明した公式ポリシー。
Addy Osmani — Agent Harness Engineering
Modelの周囲にあるPrompt、Tools、Skills、Hooks、Sandbox、Subagents、Compaction、Feedback LoopなどをHarnessとして捉え、その設計を論じた記事。
Addy Osmani — Loop Engineering
Agentを人間が毎回Promptするのではなく、そのAgentをPromptするシステム自体を設計する考え方を説明した記事。Harness Engineeringとの関係について「Harnessの1階上」と位置づけている。