TITLE

「エージェント = モデル + ハーネス」――2026年に名付けられた新しい設計規律「ハーネスエンジニアリング」とは

投稿日：2026.07.02

エージェント = モデル + ハーネス

この議論の出発点にあるのが「Agent = Model + Harness」という定式化です。AI モデル単体を、本番環境で信頼して任せられる自律エージェントに変えるには、モデルを取り巻く環境・制約・フィードバックループを設計する必要がある、という考え方です。ここでいう「ハーネス」とは、モデルに何をさせ、何をさせないかを規定し、行動の結果を検証し、逸脱を防ぐための周辺の仕組み全体を指します。

この概念は、HashiCorp の共同創業者である Mitchell Hashimoto 氏が2026年2月初旬に提唱したとされ、その後 OpenAI の Ryan Lopopolo 氏が2026年2月11日に正式な定義を与えたと、複数の情報源が伝えています。用語自体はまだ生まれて間もないものの、「モデルの性能が上がるだけでは本番運用の信頼性は担保できない」という認識が、独立した立場の実務者から相次いで言葉になった点は見過ごせません。ベンチマークの数字が並ぶ裏で、運用側の設計論が追いついていなかった空白を埋める言葉として求められた、というのが私の見立てです。

ハーネスを構成する5つのレイヤー

ハーネスとは具体的に何を指すのか。AI 開発の知見を発信する Faros AI は、ハーネスを次の5つのレイヤーに整理しています。

ツールオーケストレーション――エージェントがどのツールを、どの順序で、どう連鎖させ、エラーが起きたときにどう回復するかの制御
検証ループ――自動テストや自己批評など、出力の品質を確かめる仕組み
コンテキストと記憶――コードベースをインデックス化し、セッションの履歴を永続化する仕組み
ガードレール――ハードコードされた制限、セキュリティサンドボックス、予算上限、人間の承認フローなど、エージェントの行動範囲を機械的に区切る仕組み
可観測性――テレメトリ、実行トレース、監査ログなど、エージェントが何をしたかを後から追跡できる仕組み

ハーネスを構成する5つのレイヤーの図解

一言で言うと、この5層は「エージェントに何を任せ、どこで人間や仕組みが介入するか」を段階的に設計するための地図です。モデルの選定はこの地図の一部でしかありません。

別の切り口――制約・フィードバックループ・品質ゲート

同じ発想を、別の角度から整理しているのが、AI コーディング支援ツールを提供する Augment Code のガイドです。こちらはハーネスを3層でまとめています。

制約――リンタや型システムによって、エージェントが取りうる解の範囲をあらかじめ絞り込む
フィードバックループ――発生したエラーを、エージェント自身が読める自己修正用のプロンプトに変換する
品質ゲート――CI(継続的インテグレーション)のレベルで、基準を満たさない出力を機械的に弾く

Faros AI の5層モデルと Augment Code の3層モデルは、切り口こそ違いますが「エージェントの周りに何を作り込むか」という同じ発想の異なる表現だと捉えると理解しやすくなります。

具体的な例として、Augment Code のガイドは OpenAI の本番システムの取り組みを紹介しています。それによると、OpenAI は "taste invariants"(小さなルール集合をエンジニアリング標準として定義し、CI 上で強制的に失敗させる仕組み)と呼ばれる運用を行っているとされています。

中核原則――同じミスを二度と起こさせない

ハーネスエンジニアリングを貫く中核原則は、シンプルに言うとこうです。エージェントがミスをするたびに、そのミスを二度と起こさないための仕組みを作り込む。

ハーネス最適化の効果を示す例として、Faros AI のブログは、AI エージェント開発フレームワークを手がける LangChain のエンジニアリングチームの事例を紹介しています。それによると、2026年3月、同チームはモデル自体を変えることなくハーネスを最適化しただけで、コーディングエージェントの Terminal-Bench 2.0(ターミナル操作タスクにおけるエージェントの実行能力を測るベンチマーク)のランキングを30位から5位に引き上げたと報告されています。

ここまでをまとめると、モデルを差し替えるより、周辺の設計(ツールの与え方、検証の入れ方、失敗からの学習の仕組み化)を見直す方が、結果に効く場合があるという一つの実例です。

まとめ――モデル選定の前に、ハーネスを図面に描く

あなたの会社で AI コーディングエージェントの導入を検討する際、Faros AI の5層モデルにせよ Augment Code の3層モデルにせよ、共通しているのは「エージェントの周りに何を作り込むか」を先に図面として描くという発想です。

モデルの性能比較は重要な検討材料です。ただし、それだけでは本番運用における信頼性は決まりません。ツールをどう制御するか、出力をどう検証するか、失敗からどう学習させるか、行動範囲をどう区切るか、何をしたかをどう記録するか――これらの設計を後回しにしたまま高性能なモデルを載せても、運用の安定性は自動的には手に入りません。

「ハーネスエンジニアリング」という言葉は、まだ生まれて数か月の新しい規律です。どこから手をつけるか迷うなら、私はまず行動範囲の区切り(ガードレール)と、何をしたかの記録(可観測性)から検討します。エージェントに何を任せてよいかの境界が曖昧なままでは、検証やツール制御を先に作り込んでも土台が定まらないからです。