エージェンティック・
ハーネスとは？

「ハーネス（harness）」は、もともと馬具や安全帯を指す言葉です。力そのものではなく、力を目的の方向に働かせるための装具を意味します。AIの文脈でも同じで、推論能力そのものはモデルが持っており、ハーネスはそれを「仕事」に変換する装具を指します。

モデルは、与えられた文脈から次の一手を出力するだけの存在です。ファイルを読むことも、システムを呼ぶことも、前回の続きを覚えていることも、それ自体ではできません。それらを与えるのがハーネスです。

重要なのは、この体はモデルとは独立して設計・改善できるということです。モデルを新しいものに差し替えても体は残りますし、逆に同じモデルを使っていても、体の設計次第で完遂率・安全性・運用コストは大きく変わります。「どのモデルを使うか」より「どんな体を与えるか」のほうが、業務での結果を左右する場面は少なくありません。

実装は製品ごとに違いますが、層の分け方はおおむね共通です。この7つは、どの製品・どのフレームワークを評価するときにも比較の軸になります。

• <b>L1 実行環境</b> — サンドボックス、通信制御、資格情報。ここが弱いと、そもそも止められない。
• <b>L2 メモリ・状態</b> — 作業ファイル、短期／長期の記憶、書き込みの統制。覚え違いがここで定着する。
• <b>L3 ツールとスキル</b> — ツール設計、段階的開示、エラー設計。選べない・直せないはここ。
• <b>L4 コンテキスト管理</b> — 予算配分、圧縮とリセット、不変条件の再注入。長い作業が崩れるのはここ。
• <b>L5 制御ループ</b> — 停止条件、予算、チェックポイント。終わらない・落ちたら消えるはここ。
• <b>L6 検証・可観測性</b> — 成果の採点、トレース、CI ゲート。「できたつもり」が通るのはここ。
• <b>L7 統制・監査</b> — 台帳、権限、監査ログ。誰が何をしたか説明できないのはここ。

このうち対話型AIですでに揃っているのは L3 の一部と L4 の一部だけです。残りは、自律化にあたって新たに設計・実装する対象になります。

ハーネス設計でいま最も重要な構造が、制御プレーン（脳）・実行プレーン（手）・永続層（セッション）の三層分離です。Anthropicが自社のマネージド・エージェントの設計として公表しており、耐久実行の分野（DBOSやTemporalなど）が別ルートで到達していた結論とも一致します。

この分離が効くのは、失敗の「層」を保ったままモデルに返せるようになるからです。実行環境のコンテナが落ちたとき、それを「生成の失敗」として扱うと、エージェントは自分の出力が悪かったと解釈して同じ生成をやり直します。正しくは「ツール呼び出しが失敗した＝回復可能な失敗」として返すべきで、そのためには手が脳の外にある必要があります。

状態を外のイベントログに置くことの効果はさらに大きく、脳のインスタンスが死んでも、ログを再生すれば別のインスタンスが同じ続きから再開できます。実行環境は「ペット」から「家畜」になり、位置を指定して過去を取り出せるため、「戻せない要約」を強いられる場面も減ります。

長い作業をさせると、必ずコンテキストの上限に当たります。ここで反射的に「要約して畳む」を選ぶ実装が多いのですが、推奨される順序は逆です。安い手・損失の少ない手から順に使い、要約は最後に置きます。

要約を行う場合も、何を逐語で残すかを指定することが重要です。残すべきは、文脈付きの数値、タスクの状態（どこまで終わり、どこが未着手か）、未解決の論点。捨ててよいのは、付録的な表、逐語引用、低レベルな推論過程です。

さらに長時間の作業では、要約して続けるよりも引き継ぎ書をファイルに書き、文脈は完全に捨てて新しいセッションで入り直すほうが結果が良い場合があります。残量を意識したエージェントが仕事を早仕舞いしてしまう挙動を避けられるためです。エージェント間の受け渡しは、会話の連続ではなくファイルで行う——これが長時間タスクの定石になりつつあります。

並行して動くサブエージェントについても同じ原則が適用されます。探索の生ログを親に返さず、凝縮した結果だけを返す。親のコンテキストは、子の作業量に比例して膨らんではいけません。

接続先が増えるほど、エージェントはツールを選べなくなります。原因はモデルの能力ではなく、全件を常に提示している設計にあることがほとんどです。人間のエンジニアが選択肢を見て迷うなら、モデルも迷います。

• ツールのエラーは、不透明なコードではなく「具体的で実行可能な次の一手」を伝える。切り詰めやページングも、「結果が限られていること」と「次はクエリを絞れ」を本文で伝える。
• 簡潔版と詳細版を引数で選べるようにし、後続の呼び出しにIDが必要なときだけ詳細を取らせる。
• 名前空間で境界を作る。曖昧な名前は、そのまま選択の失敗になる。
• 返す識別子は、意味の読み取れるものにする。ランダムなIDだけでは、モデルは文脈を復元できない。

繰り返す手順を「スキル」として持たせる場合も、同じ発想が使われます。全部を最初から読ませるのではなく、必要になった分だけ開く——段階的開示（progressive disclosure）です。

もうひとつの原則は、決定性が必要な処理は、指示ではなくスクリプトとして同梱することです。毎回モデルに考えさせると結果が揺れます。手順が確定しているなら、コードとして書いて実行させたほうが、速く・安く・確実です。

エージェントの挙動は、モデル単体ではなくモデル・ハーネス・ツール・実行環境・ポリシーの組み合わせで決まります。したがって検証も、その単位で設計する必要があります。応答文の妥当性ではなく、実行後の環境の状態で合否を判定する——結果で採点する層を持つことが要点です。

このとき、生成する側と評価する側を分けることが強いレバーになります。自己評価は甘くなります。評価は静的なレビューではなく、実際に動かして触って採点するほうが機能します。実装前に「何をもって成功とするか」を検証可能な形で先に合意しておくと、評価の基準がぶれません。

最後に、しばしば見落とされる論点があります。ハーネスの各部品は、その時点のモデルの弱さを前提に置いた回避策を含んでいるということです。モデルが改善されると、その回避策は不要になり、ときには足を引っ張ります。モデル更新のたびに部品を外して再テストし、四半期程度の頻度で構成そのものを見直す——ハーネスには賞味期限がある、という前提で運用するのが現実的です。