最近、耳にする「ハーネスエンジニアリング」ですが、一体どんなものなのか？
それが生まれた必然性について、AIエージェントの歴史に基づいてまとめてみました。
（※まあ、いろいろ検索した結果をジェミナイさんにまとめてもらっただけですが。。。）
1. LLM利用から「AIエージェントの基礎概念」へ（〜2023）
生成AIの初期フェーズでは、LLM単体の活用から出発し、OpenAIを含む研究コミュニティにおいてAIエージェントの基本構造が整理され始めました。
代表的なのが、Lilian Wengによる整理（2023年）です。
- Agent = LLM（脳） + Planning + Memory + Tool Use
-
“LLM functions as the agent’s brain, complemented by planning, memory, and tool use.”
（参考：LLM Powered Autonomous Agents）
この段階ですでにAIエージェントの基本要素である「ツール（Tool）」や「メモリ（Memory）」という概念は存在していました。
しかし、この時代にはまだScaffolding（スキャフォールディング：足場）という統合的な設計概念は明確に確立されていなかったようです。
なぜなら、この頃のエージェントは「1セッション完結」「長時間実行がほぼ不可能」「人間が常に監督」という状態であり、自律的な動作や長時間実行による構造的な破綻が顕在化しなかったからです。
2. 生成AIの能力向上と「長時間走行」の現実化（2023後半）
推論能力・ツール操作精度の向上により、数十ステップに及ぶマルチタスクや、自律的なコーディングが現実的になりました。
そこで初めて問題になったのが、以下の現象です。
- コンテキスト忘却
- 方針ドリフト（目的の喪失）
- 無限ループ
この問題を構造の問題として明示したのがMemGPT（2023年）などの先行研究です。
（参考：MemGPT: Towards LLMs as Operating Systems）
MemGPTが示した決定的なポイントは、長期実行を支えるのは、モデル内部の知性ではなく『外部構造』である という示唆でした。
3. Scaffolding（足場）の登場：外部機構による「能力の解放」
上記の文脈で定着したのがScaffolding（スキャフォールディング）という考え方です。
Scaffoldingとは、LLMが長時間・複雑なタスクを継続できるよう、記憶・計画・状態を外部から支援するプログラムやフレームワークの総称を指します。
この用語と概念が業界に広まったのには、いくつかの重要な歴史的背景があります。
① ARC Evals（現METR）による安全性評価からの誕生（2023年）
- 「Scaffolding」という用語がAIエージェントの文脈で使われ始めた大きな契機は、AIの安全性を評価する機関であるARC Evals（現METR）の報告書です。
- 彼らはGPT-4などの自律性をテストする際、LLMにPythonインタープリタやブラウザを操作させるための外部コードを書き、これをScaffoldingと名付けました。
（参考：Evaluating Language-Model Agents on Realistic Autonomous Tasks） - つまり、単なるプロンプトの工夫ではなく、「LLMを組み込んだシステム（コード）」こそがエージェントの自律性の鍵であると定義された瞬間でした。
② ReAct(Reasoning and Acting)やAutoGPTによるループ構造の確立
- 同時期に、LLMに「思考（Thought）→ 行動（Action）→ 観察（Observation）」のループを強制するReAct手法や、それを実装したAutoGPTが流行しました。
- これらはまさにScaffoldingの具体例であり、プロンプトベースからコードによる自律ループへのパラダイムシフトを起こしました。
③ Anthropicが提唱した「Workflow」による実践的構造化（2024年）
Anthropicは2024年の記事「Building effective agents」において、
-
自律性を闇雲に高めることへの警鐘を鳴らし、エージェントを構成するアーキテクチャをWorkflow（ワークフロー）として体系化しました。
-
同記事では、タスクの進め方をLLM自身に動的に決定させる完全な「エージェント（Agent）」と、事前に定義されたコードの経路に従って動く「ワークフロー（Workflow）」を明確に区別しています。
-
そして、大半の実用的な問題は、以下の5つのシンプルなワークフローの組み合わせで解決できると提唱しました。
- プロンプトチェイニング（Prompt Chaining）： タスクを順次処理する
- ルーティング（Routing）： 入力を分類し、適材適所に振り分ける
- パラレル（並列処理：Parallelization）： タスクを分割して並列実行、または多数決をとる
- オーケストレーターとワーカー（Orchestrator-Workers）： 親がタスクを動的に分解し、子に委譲する
- 評価と最適化（Evaluator-Optimizer）： 生成と評価のループで精度を高める
-
これらは新しい部品というより、ToolやMemoryを「足場（Scaffolding）」としてどう組み立てるかという実践的な設計図（デザインパターン）でした。
Anthropicはまずは最もシンプルな構造から始め、必要に迫られた場合にのみ複雑さ（自律的なエージェント）を導入することを強く推奨しています。 -
結果として、この「ワークフロー」という概念がScaffoldingの実装標準として普及したことで、コーディングなどの高次なタスクが、より予測可能で安定した形で広く実行可能になったのです。
4. 新たに顕在化した失敗と「初期ハーネス」の登場（2025年）
Scaffoldingによってエージェントの能力は一気に解放されましたが、Anthropicの実用例では別の問題が顕在化しました
（2025年 "Effective Harnesses for Long-Running Agents"）。
Anthropicは次の失敗モードを明示的に報告しています。
- “The agent would look around, see some progress, and declare the job done.”（終わっていないのに「完了」と判断する）
- “Compaction isn’t sufficient.”（タスクを分解せず、一気に全部やろうとして崩壊する）
これらはモデルの知能不足ではなく、「完了判断・停止判断までLLM（の自由意志）に委ねてしまったこと」による構造的破綻でした。
この問題を解決するため、Anthropicは環境側から強制的な制約をかける初期のHarness（ハーネス）を導入します。
【初期ハーネスの実装例】
-
完了判定を奪う:
features.jsonなどのテストを唯一の正とし、テストが通らなければ完了不可とする。 - ワンショットを禁止する: 1セッション = 1機能に限定し、細かくしか進めないようにする。
-
状態は必ず外部に残す:
claude-progress.txtなどを活用し、コンテキスト（記憶）を毎回リセットして引き継ぐ。
5. ハーネスのさらなる進化：自己評価の罠からの脱却（2026年）
初期のハーネスにより長時間稼働は安定しましたが、Anthropicはさらに深い問題に直面します
（2026年 "Harness Design for Long-Running Application Development"）。
それがエージェントの自己評価の甘さです。
エージェントにコードを書かせ、自分でチェックさせると、どうしても「うまくできている」と強弁する傾向がありました。
この経験から、Anthropicは次なる強力なハーネスの具体例を提示します。
-
自己評価を禁止する（GeneratorとEvaluatorの分離）
作業を行うエージェント（Generator）と、それを冷徹に判定するエージェント（Evaluator）を物理的に分離する。
“Separating the agent doing the work from the agent judging it was a strong lever.”
Anthropicの実証実験から得られた4つの重要な教訓
Anthropicは、主観的なタスク（フロントエンドデザイン）と客観的なタスク（フルスタック開発）の両方でエージェントを長時間稼働させる実験を行い、以下の実践的な教訓を導き出しました。
（2026年 "Harness Design for Long-Running Application Development"）。
1. 「生成」と「評価」の分離が最大のレバレッジである
- エージェントは自身の作業を評価させると、たとえ人間から見て平凡な出来であっても自信満々に賞賛してしまう「自己評価の甘さ（自己肯定バイアス）」を持っています。
- この問題を解決する最も強力な手段は、GAN（敵対的生成ネットワーク）から着想を得て、作業を行うエージェント（Generator）と、それを冷徹に判定するエージェント（Evaluator）を分離することでした。
- さらに、主観的なデザインであっても「独創性」や「機能性」といった具体的な評価基準を与え、Playwright等で実際にシステムを操作させて客観的なフィードバックを回すことで、出力の質が劇的に向上することが証明されました。
2. コンテキスト不安（Context Anxiety）と、モデル進化による解決策の変遷
長時間稼働するエージェントは、コンテキストウィンドウが上限に近づくと、タスクが終わっていないのに早々に切り上げようとする「コンテキスト不安」に陥る問題がありました。
Anthropicはこれに対し、モデルの進化に合わせてアプローチを変化させています。
-
初期の解決策（コンテキスト・リセット）：
過去のモデルでは履歴の要約（圧縮：Compaction）だけでは不安を払拭できなかったため、定期的にコンテキストを完全に消去し、
前の状態と次のステップだけを外部ファイルに構造化して引き継ぐ「コンテキスト・リセット」というハーネスを組み込んでいました。 -
現在の解決策（リセットの廃止と自動圧縮への回帰）：
その後、モデルが進化（Opus 4.5等）してコンテキスト不安を自力で克服したことで、複雑なリセット処理は不要になりました。
現在はAgent SDKの「自動圧縮」機能に任せるだけで、1つの連続したセッションとして安定して長時間稼働できるようになっています。
これは、モデルの進化によって古いハーネス（足場）が不要になった良い実例です。
3. 「スプリント契約」による実装の合意形成
- ユーザーの短いプロンプトからいきなり開発を始めると、要件のスコープが縮小したり、実装がずれたりします。
- Anthropicは、Plannerエージェントに詳細な仕様書を作らせた上で、GeneratorとEvaluatorの間で**スプリント契約（Sprint Contract）**を結ばせました。
これは「何を構築し、どのように完了を検証するか」をコーディング前に合意するプロセスです。
実装の自由度を環境側で縛るこのプロセスにより、仕様と実装の乖離を防ぐことに成功しました。
4. ハーネスの領域は縮小しない。ただ「移動」するだけである
- モデルの能力が向上する（例：Opus 4.5から4.6への進化）と、これまで必要だったコンテキスト・リセットや細かなスプリント分割といった
「古い足場（Scaffold）」は不要になり、モデル単体で長時間の処理が可能になります。 - しかし、これでハーネスが不要になるわけではありません。モデルが賢くなればなるほど、「これまで不可能だったさらに複雑なタスク」に挑戦できるようになり、
そこに新たなハーネスを開発する余地が生まれます。
"The space of interesting harness combinations doesn't shrink as models improve. Instead, it moves."
（モデルが向上しても、興味深いハーネスの組み合わせの余地は縮小しない。ただ『移動』するだけだ。）
まとめ
AIエージェントの進化とハーネスは切っても切れないもの
-
Scaffoldingの概念はAIエージェントの「できること」を解放しました。
しかし、その自由が生んだ破綻を抑えるために、AnthropicはHarnessという環境主導の制御を不可欠な設計要素として確立しました。 -
生成AIの歴史を振り返ると、その原動力は常に「あった方が便利だよね」という実践的な工夫の積み重ねでした。
しかし「自由にやらせることができる」ようになった分だけ、人間が想定していなかった結果（タスクのたらい回し、成果の停滞など）も顕在化しました。 -
これらはAIが「反抗している」のではなく、判断の自由度が増えた結果、人間が暗黙に担っていた制御が失われたことで起きています。
Harnessとは、生成AIの外部から、- 何を必ず経由させるか
- どこで完了と判断するか
- どこで止めるか
といった振る舞いの枠組みを定義し、行動を環境側で制御するための仕組みです。
これからどうなるのだろうか？
-
AIエージェントの自律性、長時間実行がさらに向上すれば、さらに「できること」が増えてくると思いますが、同時に制御の必要性も増えてくるかと思います。
たとえば、AIエージェント同士が喧嘩し始めたり、どっちが正しいか言い争いを始めたりしないように制御するハーネス。
あるいは、AIエージェント同士が勝手に子エージェントを作り始めるのを止めるハーネス、など……。 -
なんだかAIエージェント社会も、そのうち人間社会っぽくなるのではないか？
そうすると、それを制御する法律（＝ハーネス）もどんどん必要になってくるのでは？なんて思います。