はじめに
AIエージェントを本番環境にデプロイして実際に使ってみると、「性能の良いLLMがあるだけでは足りない」ことに気づきます。
LLMは基本的にステートレスです。新しいセッションを始めると、それまでの会話や作業内容を何も覚えておらず、ゼロからのスタートになります。
こうした「記憶もコンテキストも持たないモデル」を、現場で使えるエージェントに変えるソフトウェア基盤が Agent Harness です。
一言でいえば、モデルの推論（Reasoning）以外のすべて ― ツール実行、メモリ、コンテキスト管理、状態の永続化 ― を裏側で担う仕組みです。
Harnessがないと何が起きるか
Harnessを持たずにエージェントを組むと、次のような失敗パターン（Failure Modes）に陥りがちです。
-
Context Rot（コンテキストの劣化）
コンテキストウィンドウが長くなるほど、モデルが最初に与えられた重要な指示を忘れたり、無視したりしやすくなります。 -
Hallucinated Tool Calls（ツール呼び出しの幻覚）
誤ったパラメータで関数を呼んだり、存在しないAPIを使おうとしたりします。 -
Lost State on Failure（障害時の状態消失）
ネットワークのタイムアウトやサーバーの再起動が起きると、それまでの進捗がすべて失われ、最初からやり直しになります。
Agent Harnessの主要コンポーネント
Harnessがきちんと機能するには、次の4つのレイヤーが必要です。
| レイヤー | 役割 |
|---|---|
| Tool Integration Layer | ファイルの読み書き、コード実行、DBクエリ、API呼び出しなどのアクションを、検証（Validate）・サニタイズしてから実行する |
| Memory & State Management | Working context / Session state / Long-term memory の3層に分けて、エージェントの記憶を管理する |
| Context Engineering & Compression | 不要な履歴を圧縮（Compaction）し、現在のタスクに本当に必要なコンテキストだけを選んで渡す |
| Verification & Guardrails | タスクを「完了」とする前にテスト・検証する。重要な操作には人間の確認（Human-in-the-loop）を挟む |
最小構成のイメージ
4つのレイヤーがエージェントのループのどこに入るのかを、TypeScript風の疑似コードで書くと次のようになります。
async function runAgent(task: string, harness: Harness) {
// 状態の永続化：途中で落ちても続きから再開できる
const state = await harness.state.loadOrInit(task);
while (!state.done) {
// Context Engineering：必要なコンテキストだけを選択・圧縮
const context = harness.context.build(state);
// 推論はモデルの仕事
const action = await llm.decide(context);
if (action.type === "tool") {
// Tool Integration：存在しないツールや不正な引数はここで弾く
const call = harness.tools.validate(action);
// Guardrails：重要な操作は人間が承認
if (harness.guardrails.needsApproval(call)) {
await harness.guardrails.askHuman(call);
}
const result = await harness.tools.execute(call);
state.history.push({ call, result });
}
if (action.type === "finish") {
// Verification：「完了」と言う前に検証
state.done = await harness.verify(state);
}
await harness.state.save(state);
}
}
3つのアーキテクチャパターン
用途に応じて、Agent Harnessは主に次の3つの形で構築されます。
-
Single-agent Supervisor
1つのモデルが、ツール・メモリ・検証を1つのループの中で最初から最後まで担当するパターン。 -
Initializer-executor Split
最初に一度だけプロジェクトをセットアップし、その後はセッションごとに少しずつ（インクリメンタルに）作業を進めるパターン。 -
Multi-agent Coordination
専門分野の異なる複数のエージェント間の受け渡し（Handoff）を、Harnessが仲介・管理するパターン。
Harness・Framework・Orchestratorの違い
似た言葉が多いので整理しておきます。
| 役割 | 例 | |
|---|---|---|
| Agent Framework | エージェントを作るための部品（Building Blocks）を提供する | LangChain, LlamaIndex |
| Agent Harness | ツール・メモリ・状態とともに、エージェントを実際に動かすランタイム | 自前で構築したインフラ |
| Orchestrator | いつ・どのようにモデルを呼ぶかという制御フローを決める | ワークフローエンジン、ルーター |
Harness Engineeringは本当に重要なのか
Harness Engineeringの核となる考え方は、エージェントがエラーを起こしたときに「もう一度試せばいい」で済ませず、「これは環境の問題なので、二度と起きないよう恒久的に直す（Permanent Fix）」 と捉えて、Harnessを堅牢にしていくことです。
この考え方は、OpenAIが2026年2月に公開した記事「Harness engineering」でも示されています。Codexチームは空のリポジトリから始め、約5か月で約100万行のプロダクションコードを、人間が手で一行も書かずに生み出しました。チームは3人から7人に増え、エンジニア1人あたり1日平均3.5件のPull Requestを出せたのは、堅牢なHarness Engineeringがあったからだとされています。
まとめ
AIプロジェクトやエージェントを作るとき、モデルの性能だけに頼ることはできません。Agent Harnessという堅牢な基盤があって初めて、AIはその力を十分に発揮できます。
これからAI分野に入るエンジニアの方には、モデルだけでなく、それを「動かす」インフラ側もぜひ学んでほしいと思います。
本記事は、私がこれまで学んだことや読んだ書籍をもとに、AIの助けを借りて執筆したものです。誤りやご意見があれば、ぜひコメントで教えてください。