AIエージェントを束ねる「ハーネス」とは何か

AIに仕事をさせようとするとき、多くの人がまず「どのモデルを使うか」「プロンプトをどう書くか」に集中する。しかし、Googleのソフトウェアエンジニア・Ryan Lopopolo氏がAgent Factoryで提唱した「エージェントハーネス」という概念は、その視点を根本から揺さぶる。

「エージェントハーネス」とは、LLM本体以外のすべて——ツール、実行環境、文脈情報、外部APIとの接続、ユーザーの介入タイミングの設計——を指す言葉だ。日本でいうなら「モデルを動かすための足場全体」に近い。GoogleのGeminiを例に取ると、Gemini本体がLLMであり、それを包むGoogle Antigravityという実行環境がハーネスにあたる。

モデル単体では「空が青いのはなぜ？」には答えられても、「今日レインコートが必要か？」には答えられない。天気APIを呼び、カレンダーを参照し、ユーザーの現在地を把握する——そうした「外側の仕組み」があって初めて、AIは自律的に動ける。つまり、エージェントの自律度を決めるのはモデルの賢さだけでなく、ハーネスの設計品質だということだ。AIエージェントに「道具箱」を持たせる時代へでも触れたように、エージェントに何を持たせるかという設計の問いは、今や使う側全員に関係している。

ハーネスの設計で特に注目したいのが、「シフトレフト（shifting left）」という考え方だ。これはソフトウェア開発の文脈では「問題発見を工程の前半に引き寄せる」という意味で使われるが、エージェント設計においても同じ原理が働く。

エージェントが間違った方向に走り始めてから修正しようとすると、コストも手戻りも大きくなる。それより、エージェントが動き出す前の段階——文脈の与え方、ゴールの明示、使えるツールの定義——を丁寧に設計しておくことで、途中の介入を最小化できる。これがLopopolo氏の言う「左にずらす」介入戦略だ。

実用面でいうと、「プロンプトが長ければいい」わけでも、「ツールをたくさん持たせればいい」わけでもない。エージェントが迷わないための情報密度と、迷ったときに人間が介入しやすい設計の両立が求められる。AIが並列で数千件調査する時代が来たのような大規模エージェント活用においても、この「どこで人間が判断を挟むか」という設計の問いは変わらない。

ハーネスという言葉はエンジニア向けに聞こえるが、考え方そのものはコードを書かない人にも即座に使える。

たとえば、ChatGPTやClaudeで複雑なタスクをやらせているのに「なんかずれた答えが返ってくる」と感じるとき、多くの場合モデルが悪いのではなく、ハーネス的な要素——文脈の与え方、ゴールの明示、使えるツールの指定——が足りていない。「もっと賢いモデルに変えよう」より先に、「エージェントに渡す情報と道具を見直す」ほうが改善につながるケースは多い。

Cursor、Cline、Difyのような最近のAIツールが「エージェントモード」をこぞって押し出しているのも、モデル単体の限界をハーネス側で超えようとしているからだ。壊れないブラウザ自動化、AIが自己修復するで取り上げた自己修復型の自動化も、ハーネス設計の一形態として読むと理解が深まる。使う側として意識すべきは、「どのモデルか」の一歩先にある「どう動かすか」の設計眼だ。