6月18日、Databricksが「What is an AI agent harness?」と題した記事を公開した。「中程度のモデルと優れたハーネスの組み合わせが、強力なモデルと貧弱なハーネスの組み合わせに勝ることがある」——これがDatabricksの主張する中心的な命題だ。モデルの性能改善に注目が集まりがちな昨今、エージェントの実力を決める主因はハーネス設計にあるという逆説的な視点から、AIエージェントを本番環境で動作させるためのソフトウェア基盤「エージェントハーネス」の概念と構成要素が詳しく紹介されている。
AIエージェントの本質は「モデル＋ハーネス」
LLMにプロンプトを送ると答えが返ってくる。しかしそれだけでは、コードを実行したり、APIを呼び出したり、過去の作業を記憶したりといった「実際に仕事をこなす」動作はできない。
その差を埋めるのがAIエージェントハーネスだ。ハーネスとはLLMを包むソフトウェア基盤で、モデルが推論した結果を実際のアクションへ変換するための仕組み全体を指す。
Databricksはこの関係をシンプルな式で示している：
Agent = Model + Harness
モデルは「脳」として推論と意思決定を担い、ハーネスはその決定を安全・確実に実行する「身体と作業環境」を担当する。
なぜハーネスがパフォーマンスを左右するのか
記事では、ハーネス設計がエージェントの本番パフォーマンスに直結することを示す具体例として、ハーネスの改善前後でスコアが大幅に向上したベンチマーク結果が挙げられている。ただし、記事中で参照されているモデル名・ベンチマーク名・具体的数値については、元記事の最新情報を直接確認されたい。
Databricksの主張の骨子はこうだ。「中程度のモデル＋強いハーネスが、強力なモデル＋弱いハーネスに勝つことがある」。これはDatabricksが提示する実験的知見であり、普遍的な法則として断定されているわけではないが、モデルの性能が収束してきた現在、ハーネス設計がエージェントの実力を決める主要因になりつつあるという問題提起として読むべき主張だ。
※編集部の考察：この文脈では、LangChainやAutoGenといったエージェントフレームワークの設計思想、あるいはDatabricks自身が提供するMLflowのトレーシング機能との連携も、ハーネス設計の選択肢として念頭に置くと理解が深まる。
ハーネスの中核：ReActループ
多くのAIエージェントの動作原理として、記事ではReActループ（Reasoning and Acting）を挙げている。2022年にShunyu Yaoらが発表した論文「ReAct: Synergizing Reasoning and Acting in Language Models」が起源だ。
- Reason（推論） — モデルがタスク・記憶・過去の結果を踏まえて次のアクションを決定する
- Act（実行） — ハーネスがツール呼び出し・コード実行・API呼び出しなどを実際に行う
- Observe（観察） — ハーネスが結果を捕捉し、モデルに新たなコンテキストとして戻す
- Repeat（繰り返し） — タスクが完了するまでループする
バグ修正エージェントを例にとると、モデルがコード修正案を出す→ハーネスが隔離されたサンドボックスで実行→テスト結果をモデルに返す→失敗なら原因を推論して再試行、というサイクルになる。
本番ハーネスの8つの構成要素
記事では、本番ハーネスに必要な構成要素を8つ挙げている。特に重要な項目を中心に紹介する。
フィードバックループと自己検証は、長い・複雑なタスクへの信頼性を担保する仕組みだ。各アクションの後にテスト実行・結果確認・自己レビューを挟むことで、エラーを自動的に検出・修正するサイクルを作る。単にモデルに「行動させる」だけでなく、「検証させる」設計が品質の鍵になる。
メモリとコンテキスト管理では、会話が長くなるにつれて古い内容を要約・圧縮する「コンテキストコンパクション」という処理が行われる。ベースのLLMはコンテキストウィンドウを超えた記憶を持てないため、ハーネスが何を保持し何を要約するかを管理する。
残りの要素は以下の通りだ：
- システムプロンプト — 毎回の実行前にモデルの役割・ルールを定義する。不適切な記述が不安定な挙動の最大原因になる
- ツールとツール実行 — Web検索、DB照会、コード実行などの関数群。最近の傾向として、固定ツールの大規模なコレクションより、コードを動的に書いて実行する汎用能力をモデルに持たせる方向へシフトしている
- サンドボックス — エージェントが本番環境に影響を与えずコード実行や操作を試せる隔離環境
- ファイルシステムと永続ストレージ — セッションをまたいだ進捗の蓄積や、人間・他エージェントとのファイル共有を可能にする
- ガードレールと人間介在（HITL）制御 — ファイル削除・顧客へのメッセージ送信・購入などの不可逆アクションに承認を必須化する仕組みで、エンタープライズ環境では必須になりつつある
- オブザーバビリティとログ — 何をしたか・なぜその判断をしたかをログ・トレース・ダッシュボードで可視化する。コンプライアンス要件にも直結する
よくある本番障害パターン
記事はハーネスの失敗パターンも列挙している。Databricksによれば、エージェントの本番障害の大半はモデルではなくハーネス側に起因する。
- コンテキストロット — 会話履歴の増大に伴い推論品質が低下する
- ツール過多 — ツールを与えすぎると意思決定が遅くなる
- 脆弱なツール配線 — ツールの説明や呼び出し方のわずかな変更で誤動作が起きる
- レイテンシ — 多段階エージェントは1回の応答に10秒以上かかることがある
- ガードレール欠如 — 十分な承認なしに不可逆アクションが実行されるリスクがある
「ハーネスエンジニアリング」という新領域
記事はプロンプトエンジニアリング→コンテキストエンジニアリング→ハーネスエンジニアリングという進化の流れを整理している。
| 領域 | 焦点 | 主な適用 |
|---|---|---|
| プロンプトエンジニアリング | 入力の文言最適化 | 初期LLMアプリ |
| コンテキストエンジニアリング | モデルに見せる情報の設計 | RAGシステム |
| ハーネスエンジニアリング | ツール・ループ・ガードレールを含む全体設計 | エージェントシステム |
プロンプトとコンテキストの設計は、ハーネスエンジニアリングの一部として包含される位置づけになる。モデル選定に先立ってハーネス設計を議論する時代が来ていることを、この整理は示唆している。
詳細はWhat is an AI agent harness?を参照していただきたい。
