エージェントハーネスとは？AIエージェントがツール・メモリ・制御を得る仕組み

この発想自体は新しいものではありません。開発者は何年も前から、モデルの周りにラッパー、スキャフォールド、実行環境を構築してきました。用語が広まったのは、HashiCorp共同創業者のMitchell Hashimoto氏が2026年2月のブログ投稿で自身のAIワークフローについて「ハーネスエンジニアリング」という言葉を使ってからです。主張はシンプルでした。エージェントがミスをしたら、そのミスが二度と起きないように環境を変えるべきだ、と。OpenAIは同じ週にCodexの取り組みにこの用語を採用し、LangChainも同様の枠組みで追随しました。

本記事では、エージェントハーネスとは何か、なぜAIエージェントに必要なのか、フレームワークやランタイムとどう違うのか、そして開発者がハーネス的なシステムを構築する際に使うツールについて解説します。

エージェントハーネスとは？

LangChainの定義のひとつに「モデル以外はすべてハーネス」というものがあります。実際には、エージェントハーネスとは大規模言語モデルの周辺にあるソフトウェアのことです。具体的には、ツール、メモリ、状態、実行、ガードレール、可観測性が含まれます。

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

モデルは推論します。ハーネスは、その推論が行動し、記憶し、結果を検証し、ルールに従える場を与えます。

動作中のエージェントハーネス内のモデル。画像：筆者作成。

この公式は便利ですが、あくまで思考の枠組みであり、業界標準ではありません。いまでも一部のベンダーは「ハーネス」「フレームワーク」「スキャフォールド」をほぼ同義で使っています。

AIエージェントにハーネスが必要な理由

生の言語モデルには、多段の作業を任せる際の限界があります。モデル単体では永続的な状態を保持せず、自力でツールを実行せず、拡大するコンテキストウィンドウを管理せず、失敗したツール呼び出しからの復旧もできません。

失敗しているテストをPythonプロジェクトで修正するよう求められたエージェントを想像してください。ハーネスがなければ、モデルは見かけ上の修正を書けるかもしれませんが、実際のテストファイルを読み、pytestを実行し、現実のエラーを確認し、失敗している関数を編集し、修正が通ったことを確かめることはできません。ハーネスがあれば、その一連のループはエージェントが自力で数分で行える作業になり、各ステップは人間が点検できる場所に記録されます。

ただしAnthropicの指針は今も有効です。可能な限りシンプルなアプローチから始め、必要になったときにだけ可動部分を追加してください。

エージェントハーネスの構成要素

構成はさまざまですが、多くは共通のビルディングブロックを共有しています。厳密な製品仕様ではなくチェックリストだと考えてください。小規模なエージェントにはこのうちの一部しか要らないかもしれませんが、プロダクションのエージェントにはより多くが必要になります。

システムプロンプトと行動規範

ハーネスは通常、モデルの基本指示を制御します。これはシステムプロンプトを含みますが、プロジェクトの規約、コーディング標準、ロール制約、安全ポリシーなども含み得ます。たとえばLangChainのDeep Agentsでは、AGENTS.md ファイルでタスク開始前の基本ルールを設定できます。

2026年の一部ハーネスは、指示に段階的開示（プログレッシブ・ディスクロージャー）を用います。起動時にすべてのツール説明をコンテキストへ読み込むのではなく、利用可能なものの要約だけを追加し、モデルがそのツールを必要としたときに初めて完全な説明を読み込みます。

ツール：エージェントが世界とやり取りする手段

ツールにより、エージェントはテキスト生成を超えた行動が可能になります。代表例は、ウェブ検索、ファイルの読み書き、データベースクエリ、API呼び出し、ブラウザ操作、コード実行、ターミナルコマンドなどです。ハーネスは、どのツールを利用可能にするか、いつモデルがそれらを呼び出せるか、結果をどのように整形してエージェントのコンテキストへ返すかを制御します。

Model Context Protocol (MCP)は2026年時点で、この領域の標準インターフェースとなりました。Anthropic Agent SDK、LangChain Deep Agents、OpenAI Agents SDKを含む多くのハーネスが、外部のツールサーバーへ個別の統合コードを書かずに接続するためにMCPを利用しています。

メモリと状態

エージェントは、タスクのこれまでの経緯を把握する必要があります。ハーネスは、短期状態をアクティブな会話内に、長期状態をファイル、ログ、要約、保存された設定などに保持できます。長い履歴を短い要約に圧縮し、モデルがすべての詳細をコンテキストに持ち続けなくてもよいようにするハーネスもあります。

実行環境：エージェントが動作・行動する場所

有用なエージェントの多くは、実際に作業できる場所を必要とします。ファイルシステム、コンテナ、サンドボックス化されたターミナル、ブラウザインスタンス、クラウドランタイムなどが該当します。ハーネスが管理する実行環境がなければ、ツール呼び出しの受け皿がありません。

現在、多くのハーネスは分離されたサンドボックスコンテナを用います。単一セッションにスコープされた短命の環境で、タスク終了時にクリーンアップされるため、あるエージェントタスクのファイル書き込み、パッケージインストール、ネットワーク呼び出しが別のタスクに波及することを防ぎます。

オーケストレーションと計画

単一の直線的手順には収まらないタスクもあります。ハーネスは、目標をサブタスクに分解し、その進捗を追跡する計画ツールを提供できます。また、作業の一部を担当するサブエージェントを立ち上げ、要約のみをメインエージェントに返すこともできます。

たとえばLangChain Deep Agentsは、計画ステップをファイルシステム上のファイルで追跡し、タスクの進行に合わせて各ステップを未完了から完了へ更新します。

ガードレールと権限

ルールを置く場所がハーネスです。人間の承認、ブロックされたツール呼び出し、ロールベースの権限、出力チェックなど。OpenAI Agents SDK、LangChain Deep Agents、Microsoft Agent Frameworkはいずれもこの種の制御をサポートします。より安全なパターンは、入力、出力、ツール権限を別々に検査することです。

可観測性とトレーシング

50ステップのエージェントタスクが37番目で失敗したとき、トレースが何が起きたかを示します。トレーシングは、モデル呼び出し、ツール呼び出し、ハンドオフ、エラー、レイテンシ、コストを実行全体で記録します。OpenAI Agents SDKはデフォルトでトレーシングを有効にします。LangSmithはその上にデバッグと評価のダッシュボードを追加します。OpenTelemetryはベンダーロックインを避けるベンダー中立のエクスポート標準として定着しており、特定の可観測性ツールに縛られません。

エージェントハーネス vs. フレームワーク vs. ランタイム：何が違う？

この問いはよく挙がりますが、多くの解説が示すほど単純ではありません。分類は有用ですが、固定的ではありません。

下から抽象度が高くなる3層。画像：筆者作成。

多くの開発者が既に使ったことのあるフレームワークから始めましょう。

エージェントフレームワークとは？

エージェントフレームワークは、エージェントを作るためのビルディングブロックを開発者に提供します。モデル呼び出し、ツール定義、メモリパターン、エージェントループの構造をカバーします。代表例は初期のLangChain、CrewAI、Google ADKです。フレームワークはエージェントの構成方法を示しますが、必ずしも本番で信頼性高く動かす方法までは示しません。

エージェントランタイムとは？

エージェントランタイムは、エージェントが時間をかけて安定して動作するのを支える層です。永続的な実行、状態の保存、リトライ、人間の介在、ストリーミングを扱います。LangGraph、Temporal、Inngestが例です。Harrison Chaseは次のたとえを示しました。Node.jsがランタイム、Expressがフレームワークだとすると、ハーネスはNext.jsのような存在です。

ハーネスは何が違うのか？

ハーネスはフレームワークより高レベルです。フレームワークが部品を提供するのに対し、ハーネスは通常、ツール、計画、ファイルシステムアクセス、コンテキスト管理など、多くの意思決定があらかじめ組み込まれています。

エージェントハーネスのユースケース：コーディング、リサーチ、データ、エンタープライズ

同じビルディングブロックが全く異なる仕事にも現れますが、変わるのは配分です。コーディングエージェントとエンタープライズのワークフローエージェントはいずれもハーネスを必要としますが、重視する部分が異なります。これらの区分は正式な標準ではありません。目の前の仕事に合わせて同じ概念がどう変化するかを捉える実用的な見方です。

コーディングエージェントのハーネス

コーディングエージェントは、ハーネスが可視化されやすい良い例です。有用なコーディング作業には、ファイルアクセス、Gitコンテキスト、ターミナル実行、テスト実行、依存関係のインストール、プロジェクト規約が必要です。Claude CodeやCodexはこのパターンの例で、いずれも生のモデルAPIではなく多量のハーネスコードの上で動いています。

優れたコーディングハーネスと凡庸なものの違いは、たいてい細部に表れます。失敗したテストからどう復旧するか、悪い編集をロールバックできるか、Git履歴をどれほどクリーンにモデルへ提示できるか。実際、エンジニアリングの大半の労力はその細部に注がれます。

リサーチエージェントのハーネス

リサーチエージェントには別のツールセットが必要です。ウェブ検索、出典追跡、ノート取り、文献管理、要約など。ハーネスは、検索結果の保存方法、出典の帰属方法、長文ドキュメントを分割してコンテキストウィンドウを食いつぶさないようにオフロードする方法を管理します。

データ分析エージェントのハーネス

データエージェントには、データセット、SQLデータベース、Python実行環境、そしてクエリ記述前にどのテーブルやカラムが利用可能かを把握するためのスキーマコンテキストへのアクセスが必要です。ハーネスは権限境界も強制します。本番データに触れ得る場合、これは重要です。

エンタープライズワークフローハーネス

エンタープライズ導入では、さらに別の要件層が加わります。認証、監査ログ、承認フロー、ロールベースのアクセス制御、社内システムとの連携などです。AWS AgentCoreは、このカテゴリのマネージドな例で、アイデンティティ、VPCネットワーキング、可観測性が含まれます。Microsoft Agent Frameworkは、Azureや.NET環境のチームに対して同様の領域をカバーします。

2026年にエージェントハーネスを構築するためのツール

2026年半ばによく名前が挙がる製品がいくつかあります。フレームワーク—ランタイム—ハーネスのスペクトラム上で位置づけはさまざまで、その境界は今も動いています。

LangChain Deep Agents

LangChain Deep Agentsは、ランタイムにLangGraphを用いたLangChainのオープンソースハーネスです。計画ツール、仮想ファイルシステム、サブエージェントの生成、自動コンテキスト圧縮、ヒューマン・イン・ザ・ループの承認やPII検出のためのミドルウェアを備えます。モデル非依存で、OpenAI互換エンドポイントをサポートし、コード実行のためにModal、Runloop、Daytonaなどのサンドボックスプロバイダに接続できます。

Anthropic Agent SDK

Anthropic Agent SDK（パッケージ名：claude-agent-sdk）はClaude Codeから切り出され、スタンドアロンの選択肢として公開されました。ビルトインのエージェントループ、bash実行、ファイル読み書き、ウェブ検索、MCP連携、コンテキスト圧縮のツールを含みます。AnthropicのAPI、Amazon Bedrock、Vertex AI、Azureを通じて、Claudeモデル専用で動作します。

OpenAI Agents SDK

前述のとおり、OpenAI Agents SDKは機能拡張に伴い、フレームワーク領域からハーネス領域へと跨るようになりました。2026年4月のリリースでは、ネイティブのサンドボックス実行、メモリ圧縮、ファイルシステムツールが追加されました。PythonとTypeScriptで利用可能で、ツール使用、エージェント間ハンドオフ、ガードレールをサポートします。

Google Agent Development Kit

Google ADKは、逐次・並列・ループ型のエージェント構造のための組み込みクラスにより、マルチエージェントのオーケストレーションをサポートします。評価ツールを含み、Vertex AIによるマネージドデプロイに対応し、ツール接続のためにMCPをサポートします。Python、Java、TypeScript、Goで利用可能で、Geminiモデル向けに調整されていますが、モデル非依存と説明されています。

Microsoft Agent Framework

Microsoft Agent Frameworkは、AutoGenプロジェクトの現行の移行先です。Pythonと.NETをサポートし、Azure AIサービスと連携し、ツール接続のためのMCPもサポートします。

CrewAI

CrewAIは、ロールベースのマルチエージェントアプローチを採用します。特定の役割を持つエージェントを定義し、タスクを割り当て、クルーを構成し、メモリとガードレールを宣言的に設定します。専門家チームに自然に写像できる問題に適しています。

Temporal と Inngest

これら自体はエージェントハーネスではありません。状態を失わずに数時間から数日稼働する必要があるエージェントタスクを扱う、耐久実行プラットフォームです。失敗時には、エンジンが最後に成功したチェックポイントからリプレイし、ゼロからやり直すことを避けます。

エージェントハーネスの課題とトレードオフ

ハーネスを追加するとシステムは多くのことが可能になりますが、追加されるツール、権限、エージェントのそれぞれが新たな故障経路にもなります。タスクが長くなるにつれ、ガードレール、トレーシング、永続状態は任意ではなく、長時間の実行を回復可能に保つ要の仕組みになります。

チームが見落としがちな結合リスクもあります。LangChainは、tau2-benchの一部で10〜20ポイントのジャンプが、モデル固有のハーネスプロファイルを追加した後に見られたと報告しました。Artificial AnalysisもCoding Agent Indexで同様の指摘をしています。コーディングエージェントの結果は、モデルとハーネスの組み合わせに依存し、コスト、トークン使用量、タスク当たり時間が組み合わせによって大きく変わります。モデル自体は変わっていません。周辺のプロンプト、ツール、ミドルウェアが変わったのです。まさにそのプロファイル作りがハーネスの仕事です。

本当にエージェントハーネスは必要？

必要性を考えるための、率直な見方を示します。

次のいずれかに当てはまるなら、ハーネスが必要な可能性が高いでしょう。

• 外部ツールを使う必要がある
• セッションをまたいで進捗を記憶する必要がある
• 実環境でコードを実行する必要がある
• 複数のエージェントを調整する
• 部分的な失敗から作業を失わずに復旧する必要がある
• 人間の承認が必要である

一方で、すべての手順があらかじめ決まっている予測可能なワークフローであれば、ハーネスは不要な場合が多いです。

有用な見極め方：1回のモデル呼び出し、もしくは条件分岐が数個の小さな決定的スクリプトで済むタスクなら、ハーネスはおそらく過剰です。エージェントが意思決定を行い、ツールを使い、時間をかけて結果に反応する必要が出た瞬間から、ハーネスは実質的な役割を果たし始めます。

よく見られるパターンのひとつは、チームが早すぎる段階でハーネスに手を伸ばし、本当はワンショットのテキスト生成タスクに過ぎないのにトレーシングやサンドボックス化を構築してしまうことです。逆の誤りはもっと痛いものです。モデルを直接出荷してしまい、2回目のテスト失敗、3回目のツール呼び出し、5回目の再起動の段階で、頼れる基盤がないことに気づくケースです。

まとめ

繰り返しになりますが、ベンダーごとに同じ物事に同じ言葉を使っているわけではなく、フレームワーク、ランタイム、エージェントハーネスの境界は今も動いています。

ワンショット生成には、ラッパーは過剰です。長いセッションをまたいで行動し、記憶し、復旧する必要があるエージェントでは、エージェントハーネスがシステムの主要部分になります。適切なハーネスの選択は、適切なモデルの選択とは独立した意思決定になりつつあります。OpenAIやAnthropicの動きから、この層の一部を次世代モデルがどこまで取り込むのか、境界が今後も変わり続けることが示唆されています。基本的な考え方は変わりません。エージェントとは、モデルにエージェントハーネスを加えたものです。

エージェントシステムの構築について詳しく学びたい場合は、Building Scalable Agentic Systems コースで、ツール利用、オーケストレーション、長時間稼働のエージェントワークフローに関するパターンを解説しています。