エージェントハーネスとは何か？：LLMの限界を超越する力

AIエージェントの「脳」を解き放つ：ハーネスエンジニアリングが拓く未来のソフトウェア開発

現代のテクノロジーの世界において、人工知能、特に大規模言語モデル（LLM）の進化は目覚ましいものがあります。しかし、単に高性能なLLMを手にすることだけが、私たちの課題を解決する究極の答えではありません。真に自律的で、私たちの意図を理解し、複雑なタスクを遂行できるAIエージェントを実現するためには、LLMを取り巻く「環境」と「能力」を設計する、より洗練されたアプローチが不可欠です。それが、今、業界で最も注目されている概念の一つ、「エージェントハーネス」であり、それを構築する「ハーネスエンジニアリング」です。

本記事では、AIエージェントの可能性を最大限に引き出すエージェントハーネスの深層に迫ります。その定義から始まり、Google Anti-gravityやCloud Code、Cursorといった具体的なツールの背後にある思想、そしてハーネスエンジニアリングがどのようにしてソフトウェア開発の未来を再構築しているのかを詳細に解説していきます。私たちは、この新しいパラダイムがもたらすビジネスへの影響、具体的な機能、そしてその将来性を深く掘り下げ、専門性と分かりやすさを両立させた形で、読者の皆様に包括的な洞察を提供することを目指します。

まず、エージェントハーネスとは一体何なのでしょうか？最も簡潔に言えば、「AIエージェントとは、大規模言語モデル（LLM）にエージェントハーネスを組み合わせたものである」と定義できます。つまり、ハーネスは、そのAIエージェントの中で、LLMそのものではない「全て」を指します。例えば、GoogleのAIエージェントにおいては、Gemini FlashがLLMであり、Google Antigravityがそのハーネスに当たるとされています。

LLMは、その名の通り「言語モデル」であり、テキスト入力を受け取り、テキスト出力を生成することに特化しています。しかし、その知識は事前学習データに限定され、現実世界の動的な情報にアクセスしたり、特定のツールを実行したりする能力は持ち合わせていません。ここにエージェントハーネスの真価があります。

具体的な例を挙げてみましょう。もしあなたがLLMに「空はなぜ青いのですか？」や「面白いジョークを教えてください」と尋ねれば、モデルは既に学習データとして持っている情報に基づいて即座に回答を生成できます。これはLLM単体で完結するタスクです。

しかし、「レインコートを着るべきですか？」という質問はどうでしょうか？ LLMは、この質問に直接答えるための情報を持ち合わせていません。なぜなら、レインコートを着るべきかどうかは、今日の「天気」という外部情報に依存するからです。ここでエージェントハーネスが介入します。

質問の解釈: あなたがエージェントに「レインコートを着るべきですか？」と尋ねると、エージェントはあなたの言葉をLLMに渡します。
情報収集の指示: LLMは質問を理解しますが、答えがないため、「天気を調べてください」という指示を（テキストで）出力します。
ハーネスによる実行: エージェントハーネスは、このLLMからの指示を受け取り、天気情報を取得するための外部ツール（例：天気予報API）を実行します。仮に「晴天で気温は98度（華氏）」という情報が得られたとしましょう。
コンテキストの提供: ハーネスは、あなたの元の質問「レインコートを着るべきですか？」と、新しく取得した天気情報「晴天で気温は98度」を結合し、それら全てを再びLLMに提供します。
最終回答の生成: 新しいコンテキストを得たLLMは、その情報に基づいて「いいえ、98度で晴天なのでレインコートは必要ありません」と、適切かつ具体的な回答を生成します。

このように、エージェントハーネスは、LLMに単なるテキスト処理を超えた「能力」を与える「ラッパー」として機能します。それは、外部ツールへのアクセス、情報の検索と統合、さらには複雑な意思決定プロセスのオーケストレーションを可能にする、AIエージェントの「行動エンジン」であり「知覚器官」と言えるでしょう。私たちがAIとやり取りするほとんど全ての場面で、実はこのエージェントハーネスが裏側で機能しているのです。

ハーネスエンジニアリングの核心：自律性の追求と「怠惰なプロンプター」の理想

エージェントハーネスという概念の提唱者であり、GoogleのRyan Lopopolo氏が語るハーネスエンジニアリングの核心は、エージェントに「自律性」を与えることにあります。彼は「どれだけ未来の曖昧さを剥ぎ取り、エージェントにタスクに対する自律性を与えることができるか」と問いかけます。これは、単に「プロンプトに明示された指示」に従うだけでなく、エージェントが「操作しているコンテキストと環境から、より多くの手がかりを読み取り」、自ら判断し、行動できる能力を意味します。

Ryan氏は、自身が「信じられないほど怠惰なプロンプター」になることを目指していると語ります。これは、モデルが自身をグラウンディング（基礎付け）するために必要なツールとコンテキストを一度与えれば、その後のプロンプトでいちいち詳細な指示を繰り返す必要がなくなるという思想に基づいています。モデルがより賢く、指示に従うようになるにつれて、私たちが望む「良い状態」を明確にグラウンディングすればするほど、エージェントはより複雑なタスクを自律的にこなせるようになるのです。

Ryan氏は、2026年2月に公開された自身の論文で、Codexを活用したエージェントファーストな世界について論じており、その中で「コードを手動で書かない」という強力な提言をしています。彼自身、昨年5月以降、エディタを開いていないと語るその実践は、多くのエンジニアにとって驚きと同時に、未来の可能性を示唆するものです。彼がこの実践を通じて最も驚いたのは、モデルがどれだけ賢くなっても「私が何を望んでいるか」をデフォルトで理解するわけではないという点でした。だからこそ、ハーネスエンジニアリングの全アイデアは、モデルの周りの「コンテキストと環境のキュレーション」を行い、モデルが起動するたびに、より自然に「私が望むもの」を理解できるようにすることにあるのです。

この思想は、AIが単なるツールではなく、私たちと共に思考し、行動するパートナーへと進化するための基盤を築きます。開発者は、低レベルのコーディングから解放され、より高レベルの「仕様設計」や「エージェントの教育」に集中できるようになるでしょう。

ソフトウェア開発のベストプラクティスをエージェントへ：シフトレフトと新しいループ

ハーネスエンジニアリングは、既存のソフトウェアエンジニアリングのベストプラクティスをAIエージェントのワークフローに適用することを強く推奨しています。Ryan氏は、大規模プロジェクトで採用されるようなリンター、明確に定義されたコーディング規約、テストといった実践が、エージェントファーストなワークフローにおいても「全て」有効であると断言します。

彼の言葉から導き出される重要な概念の一つが「シフトレフト（Shift Left）」です。これは、ソフトウェア開発プロセスにおいて、問題をできるだけ早期に、そして安価に解決するための介入を行うという考え方です。エージェントがテキストを渇望し、テキスト上で動作するという性質を考慮すると、「より洗練された、自動化された方法で、より多くのテキストをエージェントに提供すること」がシフトレフトに当たります。

例えば、プロンプトの末尾にテキストを追加する（これは最も「右」寄り、つまり後工程での介入）ことから、モデルにツールを与え、そのツール自身のドキュメントコーパスを通じて推論する能力を与える（これはより「左」寄り、つまり前工程での介入）ことまで、様々なレベルの介入が存在します。モデルが自らコンテキストを発見する手段を与えることで、開発者は「より安価に」モデルに指示を与えることができるようになるのです。

新しいベストプラクティス：自己修復とオブザーバビリティ

技術の進化に伴い、エージェントファーストなワークフローでは、以前は不可能だった新しいベストプラクティスも生まれています。

自己修復（Self-healing）: エージェントが自身の失敗を検知し、自律的に問題を診断し、解決策を適用する能力。
オブザーバビリティ（Observability）: エージェントの内部状態と挙動を深く理解するための監視と分析。
エージェントループ（Agentic loops）: 連続的なフィードバックループを通じて、エージェントが目標達成に向けて反復的に行動し、学習する仕組み。

これらの実践は、既存のソフトウェアエンジニアリングのベストプラクティスツールと組み合わせることで、さらに強力になります。例えば、PromQLのようなオンラインオブザーバビリティ技術は、モデルのトレーニングデータに豊富に存在するため、エージェントはこれらを活用して観測性に関する問題をうまく解決できます。CLIツールと組み合わせることで、推論を決定論的なものに変換し、コンテキストへのアクセスを容易にするのです。「コードは非常に安価に生成できる」という現在の状況が、これらの新しい実践を可能にしています。

人間とエージェントのための効率的な情報構造

Ryan氏はまた、人間とエージェントの両方にとって効率的な情報構造の重要性も指摘しています。彼はMarkdownにリンクを埋め込む際、散文の流れの中に直接埋め込むのではなく、アンカーとして近くに保持するという工夫をしています。これにより、エージェントはドキュメント内の散文テキストを効率的に読み取ることができ、リンク自体はテストとしてテキストの近くに配置されます。この「工夫されたコード」は、コンテキストを効率的に保ちながら、人間にとってもレビューしやすい可読性を維持します。

これは「中間での損失問題（loss in the middle problem）」と「人間による可読性」を同時に解決する試みです。エージェントが生成したコードやドキュメント（Google Docs、Google Sheetsなど）が「妥当か」を判断する際、人間がその「エンドアーティファクト」をレビューし、もし妥当でなければ、「なぜこのような不合理な結果になったのか」を遡って理解できる手段が必要だからです。エージェントの実行の「中身を覗き見る」能力は、エージェントを効果的に監督するために不可欠であり、これが「エージェントの頭を叩いて、同じ間違いを二度としないようにする」という比喩で表現されています。

長期的なコヒーレンスとエージェントの進化：自律性の「ループ」を拡大する

エージェントが単発のタスクだけでなく、長期的なプロジェクトにおいて一貫性（コヒーレンス）を保ちながら貢献できるか、これはハーネスエンジニアリングが解決しようとしている最大の課題の一つです。人間組織での仕事が「非常に反復的なプロセス」であることを考えると、エージェントをその仕事の「本格的な参加者」にするためには、エージェントが生成するものを組織が「良い」と考える「ゴールデンスレッド（Golden thread）」に継続的に再調整する必要があります。ハーネスエンジニアリングは、この「ゴールデンスレッド」からエージェントが逸脱しないようにする、ますます洗練された「トリック」の集合体なのです。

「ループの拡大」：自律性の段階的向上

この考え方の中心にあるのが、「ループの拡大（Increasing the size of the loop）」という概念です。

小さな変更から始める: 最初に、エージェントに小さな変更を任せ、その結果が妥当であるという自信を築きます。例えば、レビューしやすい小さなプルリクエスト（PR）の生成などです。
積み重ねと信頼: これらの小さな変更を積み重ねることで、より長いスパンで妥当な結果が得られるかどうかを検証します。小さなPRがレビューしやすければ、エージェントにそのレビューの一部を自動化させることも可能になり、人間の介入を減らしながら、より長い時間軸で作業を進めることができます。
より大きなループへ: 信頼が確立されれば、監督者である人間は、より野心的なタスクや、より大きな「ループ」をエージェントに任せることができます。最終的には、大規模な言語移行のような包括的な変更でさえ、十分にガードレールが整備されていれば、エージェントに実行させることが可能になります。生成されるコードに信頼がおければ、その信頼と自律性を新しい方向に適用できるのです。

多様性と専門性を持つエージェントチームの構築

Ryan氏は、複数の開発者がエージェントの能力向上に貢献する様子を、RPGのキャラクターのステータスを上げることに例えています。例えば、Reactアーキテクトがチームに加われば、エージェントのフロントエンドアーキテクチャやパフォーマンスに関する「ステータス」が向上します。このように多様な専門知識を持つチームをキュレーションし、それぞれが中心となる「作業生産者（エージェント）」に貢献することで、全員の最高の能力を集約した、非常にバランスの取れたエージェントを育成することが可能になります。

これは、従来の「チーム採用」の考え方を覆すものです。必要なスキルセットを正確に指定するだけで、エージェントがそのスキルを「テーブルに持ち込む」ことができるようになるからです。エージェントはバックエンドアーキテクトでもあり、フロントエンドパフォーマンスのエキスパートでもある必要があります。なぜなら、次にどんなタスクが来るか分からないからです。スプリントプランニングで専門知識に応じて仕事を割り振る代わりに、エージェント自身が「どの専門知識を活性化する必要があるか」を判断するのです。エージェントに実行する作業を分類させ、それに基づいて必要なコンテキストを動的に発見させることは、「高い自律性」を持つことの重要な要素となります。

これは、ジュニアエンジニアがキャリアを通じてシニアエンジニアに成長するように、エージェントにますます曖昧な問題を解決する自律性を与えることと似ています。スタッフエンジニアが組織のために6ヶ月先の課題を解決するように、エージェントもまた、その自律的なチームの障害をどれだけ先まで取り除けるかを考える必要があります。

実践的ハーネス構築の選択肢と設計思想：モデルを使いこなし、未来に投資する

では、一般のエンジニアはハーネスエンジニアリングについてどれくらい知るべきなのでしょうか？そして、自分でハーネスを構築する必要があるのでしょうか？ Ryan氏の経験は非常に示唆に富んでいます。「私はハーネスを一度も構築したことがありません」と彼は語ります。彼がハーネスエンジニアリングと呼ぶものは、エージェントシステム内の「Anti-gravityのようなもの」を固定し、常に最新の最高のモデルを採用し、それに対する高い目標を持つことです。

彼の中心的なアドバイスは、「エージェントがうまく機能しないときにそれを観察し、なぜうまくいかなかったのかを自問し、そしてコードや散文（プロンプト）の生成が非常に安価であることを利用して、エージェントを取り巻く環境を洗練し、良い振る舞いからの逸脱を許さないように努める」というものです。エージェントにツールを増やし、より豊かなドキュメントを提供し、そのドキュメントをリアルタイムでナビゲートする手助けをすればするほど、エージェントはより複雑なタスクをこなし、私たちの手綱を握る必要が少なくなります。

「Capability Overhang」の活用とGoogle Cloudの未来

この思想の背後には、「Capability Overhang（能力の過剰供給）」という概念があります。これは、現在のモデルの能力が、私たちが実際にそれらから引き出せる有用な仕事のレベルをはるかに超えている状態を指します。Ryan氏のモチベーションは、この能力の過剰供給を「貪欲に食い尽くすこと」にあります。そのためには、モデルの展開に対する「野心」を高め、これまで存在しなかった領域に投入する必要があります。

彼がGoogle Cloudでエージェント構築に取り組んでいるのは、この理由からです。Google Cloudは、非常に複雑なシステムが広大かつ深く存在する「非常に大きなコンピューター」です。エージェントが成功するためには、コンピューターを与える必要があります。Ryan氏は、Google Cloudをエージェントが「この上なくうまく操作できる最高のコンピューター」にすることを目指しています。これは、お客様が自らそのプロセスを実行できるようにすることにも繋がります。つまり、「Cloudなどない、それは誰かのコンピューターにすぎない」という言葉通り、エージェントにとって最適な「誰かの大きなコンピューター」を提供しようとしているのです。

エージェントは常に「コンテキスト」を必要とします。このコンテキストとツールを中心とした「拡張可能なインターフェース」に注力することが、AIの急速な進歩に対応し、私たちの専門知識を陳腐化させない唯一の方法です。ツールとコンテキストの品質向上に努力を集中すれば、新しいモデルがリリースされるたびに自由にそれらを採用でき、決して陳腐化しないシステムの部分に継続的にレバレッジを蓄積できるからです。これは、エージェントを過剰に足場付けしてしまい、モデルが進化するにつれて不必要に制約したり、サンクコストの誤謬に陥ったりする大きな課題を回避します。

Billyによる実践的ハーネス設計のガイド

デベロッパーのBillyは、ハーネスのカスタマイズを通じてモデルの性能を最大限に引き出す方法について、より具体的な視点を提供しています。彼が強調するのは、「一つの最高のハーネスは存在しない」という事実です。各ハーネスは、特定のタスクや問題空間に合わせて、以下の3つの主要な決定要素に基づいて設計されます。

ルーピング（Looping）: ハーネスが何回繰り返されるか。
ツール（Tools）: どのようなツールを使用すべきか、いつ使用すべきか、どのように使用すべきか。
メモリ（Memory）: ワークフローにとってメモリがどれほど重要か、いつメモリを検索すべきか。

Billyは、これらの要素に基づいた3つの異なるハーネスパターンを紹介しています。

線形ハーネス（Linear Harness） - ループなし: これは最もシンプルなパターンで、常に同じフローをたどります。例えば、ファイルを一度検査し、推奨事項を出力して終了するか、ファイルを見る必要がなければ直接回答を出力します。このハーネスは、ある程度の決定論が必要な場合、つまり毎回同じことを確実に行わせたい場合に最適です。例えば、設定ファイルを読み込み、その内容に基づいて一度だけ診断結果を報告するようなタスクに適しています。
閉ループハーネス（Closed Loop Harness）: このパターンは、コード編集などのタスクで非常に一般的です。特定のエラー状態や終了条件が満たされるまで、継続的に何度も実行されます。例えば、コードの変更を適用し、テストを実行し、その失敗出力（エラーメッセージ）を記憶にフィードバックし、テストが合格するまでループを繰り返すような場合です。これは、問題を解決するために反復的な試行錯誤が必要な場合に強力なアプローチとなります。
安全ガードレール付きハーネス（Harness with Safety Guardrails）: ゼロから構築するが、全ての機能を一つずつ実装したくない場合、GoogleのAgent Development Kit（ADK）のようなツールが役立ちます。これにより、メモリ圧縮機能や、破壊的なコマンド（ファイルの削除、データベースのドロップ、GitHubへのプッシュなど）をブロックする機能といった、より高度なガードレールを備えたハーネスを構築できます。これは、より多くのカスタマイズを可能にしつつ、安全性と信頼性を高めるためのものです。

これらのハーネスは、Google Antigravity、Cloud Code、Cursorといった今日の人気ツールの中核を成しています。これらのツールは、特定のコンピューターの使用方法、メモリの使用方法、問題解決の方法において、それぞれに「意見」を持っているがゆえに強力なのです。モデルそのものが賢いだけでなく、モデルの周りに構築された「ハーネスエンジニアリング」と、適切なエンジニアリング原則、適切なツールが、それらを効果的なソフトウェア開発ツールにしているのです。

エージェント開発スタックの三層構造：最適化されたAIワークフローの実現

エージェントが壁にぶつかったとき、多くの開発者はまず「より強力な基盤モデル」に飛びつきます。しかし、AIワークフローを日々扱うようになると、モデルはパズルの一部に過ぎないことに気づかされます。真に高性能なエージェント開発スタックは、以下の3つの連携する層によって成り立っています。

モデル（The Model）
ハーネス（The Harness）
ナレッジ（The Knowledge）

これら全てが適切に機能したとき、あらゆるものが劇的に変化します。

第1層：モデル層 - なぜFlashモデルがエージェントに適しているのか

今週、筆者が日常的に愛用しているのは「Gemini 3.8 Flash」です。なぜ、最も推論能力が高いとされる重いモデルではなく、Flashを選ぶのでしょうか？ここにエージェントワークフローの秘密があります。

エージェントは、従来のシングルターンプロンプトボックスのように機能しません。彼らは「連続的なループ」で動作します。エージェントはディレクトリを検査し、関数を更新し、単体テストを実行し、そしてこの一連のシーケンスを1つのタスクを完了するために20回、40回、あるいは60回も繰り返すことがあります。これほど多くの「連続的なホップ」を使用する場合、その「速度」と「コスト」は劇的に複合されます。

したがって、高速でコスト効率の高いモデルは「格下げ」ではなく、「リアルタイムのエージェントループを実用的かつ応答性の高いものにする」ために必要不可欠な要素となります。Flashモデルは非常に軽量であるため、数十回のイテレーションを難なくこなすことができます。これにより、開発者は高額な請求書に悩まされることなく、完全なループの中に留まることができるのです。

第2層：ハーネス層 - Anti-gravityの「Boost」コマンド

高速なモデルを手に入れたら、次にそれをオーケストレーションするための動的な構造が必要です。ここで登場するのが、ハーネス層を代表するツール、Anti-gravityの「Boost」コマンドです。

Boostコマンドは一言で言えば、「単一のモデルを、調整されたチームに変える」機能です。一つのエージェントが全てを順番に処理するのではなく、Boostは「オーケストレーター」を起動し、専門化されたサブエージェントを「並行して」委任します。そして、コードベースに触れる前に、作業を徹底的に監査する「独立した検証パス」で完了します。

この機能は日常的なタスクには必要ありません。例えば、標準的な機能開発、UIコンポーネントの追加、コードベースのナビゲートなどでは、デフォルトのエージェントが迅速かつ効率的です。しかし、Boostは「深く複雑なエンジニアリング課題」のために温存すべきです。例えば、複数のモジュールにまたがるリファクタリング、パフォーマンス最適化、大規模なシステム統合など、専門的な知識と並行処理、厳格な検証が求められるタスクにおいて、Boostは真価を発揮します。

第3層：ナレッジ層 - Google Skillsによるドメイン知識のキュレーション

高速なモデルと調整されたハーネスがあっても、エージェントが特定のドメインでどのように動作すべきかを知らなければ意味がありません。例えば、Cloudインフラストラクチャを設定する場合、エージェントはどうすればその方法を知ることができるのでしょうか？ここで「Google Skills」が登場します。

Google Skillsは、GitHubで19,000以上のスターを獲得しているリポジトリであり、エージェントに「キュレーションされたドメイン知識」をオンデマンドでロードさせるためのものです。これは単なるMVPサーバーや重いプラグインではありません。エージェントが推測するのを止め、実際に物事を行う方法を「教える」、クリーンで正確なコンテキストを提供します。

このリポジトリには、Google Cloud、Firebase、Flutter、Mapsなど、100以上の異なるスキルが含まれています。インストールは非常にシンプルで、単一のコマンドを実行するだけで全てのスキルをインストールできます。そして何よりも素晴らしいのは、これが「ハーネスに依存しない（harness agnostic）」ということです。Cloud Code、Codex、Google Anti-gravityのいずれを実行しているかに関わらず、これら全てのハーネスがこの同じリポジトリからスキルを引き出すことができます。

これにより、開発者はモデルやハーネスの選択に縛られず、専門的なドメイン知識をエージェントに効率的に注入できるようになります。エージェントは、これらのスキルを通じて、特定の環境やプラットフォームにおけるベストプラクティスや操作方法を「学び」、より正確で信頼性の高い作業を遂行できるようになるのです。

まとめと未来への提言：AI開発のパラダイムシフト

エージェントハーネスは、AIの能力を単なるテキスト生成から、真の自律的な問題解決へと押し上げる、画期的な概念です。私たちは今、AI開発における大きなパラダイムシフトの真っ只中にいます。モデルの性能向上だけを追求する時代は終わりを告げ、そのモデルをいかに効果的に取り囲み、導き、能力を付与するかに焦点を当てた「ハーネスエンジニアリング」が、これからのAI開発の鍵を握ります。

この新しいアプローチがもたらすビジネスへの影響は計り知れません。開発者は、低レベルのコーディングから解放され、より高レベルな設計、アーキテクチャ、そしてエージェントの教育といった創造的なタスクに集中できるようになります。これにより、開発サイクルは劇的に短縮され、複雑なプロジェクトもより効率的かつ高品質に推進されるでしょう。企業は、AIエージェントを多様な専門知識を持つ「デジタル従業員」として活用し、生産性の飛躍的な向上と、これまで不可能だったイノベーションを実現できるようになります。

未来のエンジニアは、もはや単なるプロンプターではなく、「ハーネスエンジニア」として、エージェントのコンテキスト、ツール、そしてナレッジ環境を最適化する役割を担うことになるでしょう。彼らは、エージェントが「怠惰なプロンプター」の理想を実現し、最小限の指示で最大限の自律性を発揮できるように、その「脳」と「身体」を設計し、育成する専門家となるのです。

AIの進歩のペースは驚異的です。私たちが今日「可能」だと考えていることは、明日にはあっという間に更新されているかもしれません。だからこそ、Ryan氏が提言するように、私たちは常に自身の既成概念を更新し続ける必要があります。エージェントとそのハーネスが進化し続ける中で、私たちの経験と専門知識が常に意味を持ち続けるためには、ツールとコンテキストという「拡張可能なインターフェース」に注力することが不可欠です。

エージェントは常にコンテキストを必要とし、私たちが考える「良い状態」への適応を最後の1マイルまで追求します。そして、私たちがその知識を「シフトレフト」させ、ますます高性能なツールとして提供し続ける限り、モデルが時間とともに、より多くの、より興味深いことを実現してくれることに、私たちは常に驚かされることでしょう。エージェントハーネスは、単なる技術的な概念に留まらず、私たちの仕事のあり方、そして創造性の限界そのものを再定義する、未来のソフトウェア開発への招待状なのです。