AI における「ハーネス (harness）」とは？

最近 OpenCraw が「ハーネス（harness）」と表現されているのを目にしました。私は「それは興味深いな。OpenClaw はハーネスではなく、エージェントランタイムであり、エージェントのループを駆動するものだ」と考えました。そもそも「ハーネス」という言葉にはどのような意味があるのでしょうか？

これまでの経緯

この概念の構造的なベースラインは、Birgitta Böckeler 氏が 2026 年 4 月に発表した記事に由来しており、この記事ではエージェントが model + harness = agent として明確に定義されています。彼女はスタックを、「ビルダー・ハーネス」（ツールに同梱される内部ランタイム）と「ユーザー・ハーネス」（開発者によるカスタム・コンテキスト）の 2 つに分類しました。この定義は、2026 年 2 月からの一連の議論に基づいて構築されました。この定義には、 Mitchell Hashimoto 氏の AGENTS.md コンテキストのエンジニアリングに対する実用的アプローチや、OpenAI による自動デプロイのための内部ハーネス・エンジニアリングの概要、Böckeler 氏の当初の要約メモが含まれていました。

外側から内側へ：5 つの層

エージェントには「モデル ＋ ハーネス」以上の要素があると私は考えています。その出発点となるのは、「エージェントランタイムをそのまま信頼することはできない」という認識です。エージェントファクトリーが作成するコードのソフトウェア・サプライチェーンのセキュリティの確実性を確保するには、出所情報を取得してエージェントが外部に与える影響を制限するために使用できる、個別のサンドボックス・レイヤーが必要です。この層を利用して、コードの出自情報を記録し、エージェントが暴走した際の影響範囲を制限できるようにします。

私は、このセキュアなエージェントランタイム・アーキテクチャを、外側から内側に人形が次々と収まる仕組みのマトリョーシカ人形のようなものだと捉えています。

インフラストラクチャ → サンドボックス → エージェントのハーネス → ランタイム → モデル

それぞれのレイヤーはそれぞれ異なる所有者、異なる障害モード、異なる設計原則を備えています。詳細を見てみましょう。

レイヤー 1：インフラストラクチャ

インフラストラクチャは、エージェントが物理的に実行される場所です。それは、GitHub Actions Runner、Kubernetes Pod、または仮想マシン (VM) などです。このレイヤーはコンピューティング、ネットワーク、リソース管理に関するものであり、その重要性は一般に想像される以上です。

1 つのエージェントから数十の並列実行エージェントに拡張するとどうなるか、考えてみましょう。 Roy Belio は、GPU のスケジューリングやジョブ・オーケストレーションなど、人手を介さずに 198 の自律的な実験を OpenShift AI の自動研究システムで実行しました。これはハーネスの問題ではなく、サンドボックスの問題でもなく、インフラストラクチャの問題です。貴社のプラットフォームは、競合するリソース要求を管理し、複数のエージェントが同時に実行されないようにし、GPU ワークロードをスケジューリングできますか。

GPU のスケジューリング自体が、ファーストクラスのインフラストラクチャの規範になりつつあります。Red Hat OpenShift 4.21 では動的リソース割り当て機能が付属しています。これは Kubernetes API であり、ワークロードが生のカウントではなく属性 (モデル、メモリー、コンピューティング能力) で GPU をリクエストできるようにします。また、コンテナ間で GPU を共有できるため、軽量の推論サイドカーがデバイス全体を浪費することがありません。これは純粋なインフラストラクチャであり、サンドボックスポリシーも、AGENTS.md のエントリーも、モデルの選択もありません。プラットフォームがジョブを実行するだけです。

レイヤー 2：サンドボックス

サンドボックスにより、エージェントが実行できることが制限され、何らかの問題が発生した場合に潜在的な影響が制限されます。つまり、ここでは分離が行われます。私の同僚である Marta Anon Ruiz は、このレイヤーを「エージェントの意図を形成する」ものであると説明しています。NVIDIA の OpenShell などのプロジェクトは、このレイヤーで動作します。ソフトウェア・サプライチェーンのセキュリティの観点から見ると、これは主要な信頼境界であり、rm -rf / を実行できるエージェントと実行できないエージェント、または GitHub の全 Issue に対して gh issue delete を実行できるエージェント (あるいは同様の操作を行うスクリプトを自ら作成し、実行できる) エージェントと実行できないエージェントの違いといった点に関わります。　

インフラストラクチャが「エージェントはどこで実行されるのか？」と問うのに対し、サンドボックスは「エージェントは何を操作できるのか？」と尋ねます。これらは異なる質問であり、それぞれ異なる答えが求められます。

Red Hat は、Kubernetes 上での AI エージェント向けの堅牢なガードレールの構築に関する詳細ガイドを公開しました。これには、制限付きの v2 SCC (Security Context Constraing)、デフォルト拒否の egress NetworkPolicies、エージェントごとのロールベースのアクセス制御 (RBAC) が含まれます。これらの制御は、エージェントが実行できるすべての機能から始め、必要な機能だけを残すまで段階的に削除していく減算制御です。

サンドボックスレイヤーは、ネットワークポリシーよりもさらに深いレベルで機能します。 Red Hat OpenShift Sandboxed Container (Kata Container とピア Pod ベース)は、このレイヤーにおける重要なテクノロジーであり、エージェントのプロセスをホストから分離するための追加の手順を実行します。また、エージェントのスキルとセキュリティ脅威に関する記事をご確認ください。この記事では、実行前に出所を確認できるエージェントスキルの暗号署名など、脅威とソリューションについて説明しています。ソフトウェア・サプライチェーン攻撃では、エージェントのツールチェーンに未署名のスキルを注入します。サンドボックスレイヤーはこれに対応するのに役立ちます。

このレイヤーでは、NVIDIA の OpenShell などのプロジェクトは、一般的なコンテナランタイムに組み込まれた基本的な最小限のセキュリティ機能と同様に関連性があります。これらはいずれも、Hashimoto 氏が提唱する意味での「ハーネス」ではありません。つまり、エージェントにより良い作業をさせるよう教えるのではなく、エージェントに危険な作業や予期せぬ作業をさせないようにするものです。

レイヤー 3：エージェントのハーネス

これは Hashimoto 氏が言及し、Birgitta Böckeler 氏が「ユーザーハーネス」と呼んでいる層のことです。これは「イネーブルメント (機能実現)」の層であり、AGENTS.md ファイル、スキル、カスタムツール、手製のリンター、システムプロンプト、優れたテストスイートなどが含まれます。これらは、エージェントが正しくタスクを遂行できる可能性を高めるために、反復的にエンジニアリングしていく要素です。

Marco Rizza 氏の構造化ワークフローによるハーネス・エンジニアリング についての記事では、「structure in, structure out (構造を入力し、構造を出力する)」という原則を明確に示しています。この記事では、LSP と MCP を使用してプロジェクト構造をスキャンし、コンテキスト認識型のプロンプトを生成する方法について説明しています。エージェントに何をすべきかを伝えるだけでなく、それを適切に実行するために必要な構造情報をエージェントに提供する方法について説明しています。これは、Biirgitta 氏がフィードフォワード制御と定義する方法です。

ツールの利用はハーネスの重要な部分であり、Birgitta Böckeler 氏が「コンピュテーショナル・ガイド（計算による指針）」と呼ぶものを可能にします。ツールの利用や、その標準的な足掛かりとなる MCP の登場により、有意義なエージェントの構築が可能になり、エージェントのランタイムが目標を達成できる可能性が高まりました。 MCP を使った効果的な AI エージェントの構築では、MCP について掘り下げ、ハーネスに企業のリソースに動的にアクセスする手段を提供することでエージェントを有効にする方法を紹介します。

ハーネスが機能しているかどうかをどう判断するのでしょうか。それは評価によって行います。Michael Dawson 氏は評価駆動型の開発について記述し、DeepEval および LLM-as-Judge パターンを使用した 8 段階の評価フレームワークを提示しています。評価はフィードバックループの役割を果たし、ハーネスへの変更がエージェントを改善したのか、または悪化させたのかを示すものとなります。これがなければ、ハードウェア・エンジニアリングは当て推量に過ぎません。評価ハブなどのツールは、こうした評価を大規模に管理するのに役立ちます。

ハーネスの成果物には管理上の課題があります。AGENTS.md が肥大化し、カスタムツールが増え、システムプロンプトが進化していく中で、それらをどのようにバージョン管理すればよいのでしょうか？プロジェクト間でどのように共有しますか？ Lola (AI コンテキスト・パッケージ・マネージャー)の記事では、AI コンテキストをバージョン管理されたパッケージとして扱っています。この捉え方は理にかなっています。ハーネスの成果物がエンジニアリングの成果物であるならば、それらをエンジニアリングの成果物として管理すべきなのです。

レイヤー 4：エージェントランタイム

エージェントランタイムは、エージェントループを駆動するエンジンです。Claude Code、OpenCode、Goose、またはカスタムビルドされたものなどが例として挙げられます。これは、ツールのディスパッチ、コンテキストウィンドウ、会話の管理を担います。

Anthropic は先のメールでこれをハーネスと呼んでいましたが、これは不正確であり、少なくとも厳密さを欠いていると思います。ランタイムは、独自のものを構築しない限り、エンジニアリングによって改良できるようなものではありません。プロンプトを送信し、応答を受信し、ツール呼び出しをディスパッチし、結果をフィードバックするというループを実行します。このレイヤーの重要性を軽視することはできません。ランタイムは進化を続けており、私たちは皆その恩恵を受けています。

しかし、独自のランタイムを構築する組織もあるでしょう。主権に関する要件がある場合、既存のランタイムでは提供されない機能が必要な場合、あるいはユースケース上ランタイムの挙動を極めて詳細に制御する必要がある場合には、独自のランタイムを構築する必要があり、そのための API が必要となります。ここで重要になるのが Llama Stack などのプロジェクトであり、応答、ファイル処理、検索、そして将来的にはメモリー機能のためのオープン API を公開します。オープンな API 上に構築されたソブリンランタイムは、プロプライエタリーなサービスに縛られたものとは異なります。Red Hat のプラットフォームは、その両方の道筋をサポートしています。つまり、既存のランタイムを採用しその周囲にユーザー向けのハーネスを構築するチームと、状況に応じてオープンな API を利用して独自のランタイムを構築するチームの双方を支援しているのです。

レイヤー 5：モデルと推論のエンドポイント

提供側については、OpenShift 上の Red Hat AI Inference Server と Claude Code の統合に関する Red Hat のガイドでは、Red Hat AI 上でオンプレミス推論用に vLLM を使用する方法を説明しています。そこでは、独自のモデル、クラスタ、データを使用できます。独自のハードウェアで推論を実行することは、エージェントスタック全体の信頼モデルに大きな影響を与えます。

出所に関しては、先進的なソフトウェア・サプライチェーンのセキュリティに関する Red Hat の取り組み、とくに Red Hat Trusted Artifact Signer と暗号モデル署名がここでは重要になります。実行しているモデルの出自を検証し、管理できなければ、その上位にあるスタック全体が、検証されていない基盤の上に構築されることになります。モデル署名はモデルレイヤーにとって、スキル署名がハーネスレイヤーにとってそうであるように、意図した通りのものを実行しているという暗号学的な保証を提供するものです。

「引き算」か「足し算」か

サンドボックスとハーネスは、対照的な設計思想に基づいています。サンドボックスは「引き算」のアプローチであり、リスクを低減するために機能を制限します。一方、ハーネスは「足し算」のアプローチであり、能力を高めるために知識やツールを積み重ねていきます。す。これらを混同してしまうと、それぞれの指針となるべき設計原則が曖昧になってしまいま

また、これらは障害モードも異なります。サンドボックスにおける障害とは、エージェントが本来実行できないはずの動作を行ったことを意味します。これに対してハーネスにおける障害とは、エージェントが本来うまく実行すべき動作を、不適切に行うことを意味します。これらは異なる問題であり、それぞれ異なる対応が求められます。

サンドボックスには、エージェントのアクティビティを記録する中立な観察者としての二次的な役割を果たす機会があり、エージェントランタイムの自己証明よりも信頼できる方法で、実行内容を証明できます。

サンドボックスは制約および監視を行います。ハーネスは機能の有効化を行い、改良を加えることが可能です。ランタイムが実行されます。どうしても必要な場合を除き、独自に構築する必要はありません。エージェントの安全性と信頼性は、その下にあるスタックの品質に依存します。Red Hat は、そのスタックを、GPU スケジューリングから暗号技術を用いたモデル署名まで、あらゆるレイヤーにおいてオープンソースに基づいたそのスタックを構築しています。本番環境でエージェントを運用するにあたり、単なる期待ではなく、検証可能な基盤を求めているのであれば、それこそが Red Hat の目指す方向性なのです。