AIエージェント開発は、モデル選びに加えて「どのエージェント基盤を使うか」でも実装が縛られがちです。VercelがAI SDK 7向けにHarnessAgentを公開し、この制約をほどく一手が出ました。
この記事では、HarnessAgentが何を解決するのか、どのエージェントに対応するのか、既存のAI SDKコードとどうつながるのかを整理します。
この記事でわかること
– HarnessAgentが提供する抽象化レイヤーの役割
– 初期対応するClaude Code・Codex・Piの位置づけ
– プロバイダー抽象化との違いと使い分け
– アプリへの組み込み手順の概要
HarnessAgentとは何か
2026年6月12日、Vercel CEOのGuillermo Rauch氏がXでHarnessAgentの出荷を告知しました。任意のエージェントの「brain」をアプリへ統合するための統一抽象化であると説明されています(参考)。
同日のVercel公式changelogでも、AI SDK 7にHarnessAgentが加わったことが発表されています。Claude Code、Codex、Piといった確立済みのエージェントハーネスを、単一のAPIで動かせるようになります。
HarnessAgentは、ハーネスアダプターで接続したエージェントランタイムを、AI SDK互換のgenerate()とstream()で扱うクラスです。返り値はGenerateTextResultやStreamTextResultとして、既存のAI SDK UIプリミティブとそのまま接続できます。
なぜエージェント抽象化が必要か
AI SDKはもともと、モデルプロバイダーを差し替えてもアプリを書き直さなくて済む設計でした。一方、コーディングエージェントのような高度なランタイムは、単一のモデル呼び出しより大きな責務を持ちます。
公式ドキュメントが挙げるハーネスの領域は、ワークスペース操作、組み込みツール、ネイティブなセッション状態、権限フロー、コンパクション、ランタイム設定です。これらを自前のツールループで再実装すると、Claude CodeからCodexへ切り替えるたびにアプリ構造ごと変える必要が出ます。
HarnessAgentは、ハーネスアダプターとサンドボックスプロバイダーを組み合わせることで、エージェント基盤の差し替えを設定変更のレベルに下げます。Rauch氏も「モデルとエージェントの両方からロックインを解放する」と述べています。
対応ハーネスと今後の拡張
初期リリースで利用できるハーネスアダプターは次の3つです。
- Claude Code(
@ai-sdk/harness-claude-code) - Codex(
@ai-sdk/harness-codex) - Pi(
@ai-sdk/harness-pi)
いずれもHarnessAgentの設定でharnessプロパティに渡し、サンドボックス上で実行します。Claude CodeとCodexはサンドボックス内ブリッジ経由、Piはホストプロセス上で動く構成です。
公式ドキュメントでは、Amp、DeepAgents、Goose、Mastra、OpenCode向けアダプターも「Coming Soon」として掲載されています。ハーネスパッケージは実験的(canary)提供のため、リリース間で破壊的変更が入る前提で扱う必要があります。
基本的な使い方
HarnessAgentはモジュールスコープで定義し、設定を保持します。実際の会話状態はHarnessAgentSessionが担います。
import { HarnessAgent } from '@ai-sdk/harness/agent';
import { claudeCode } from '@ai-sdk/harness-claude-code';
import { createVercelSandbox } from '@ai-sdk/sandbox-vercel';
const agent = new HarnessAgent({
harness: claudeCode,
sandbox: createVercelSandbox({
runtime: 'node24',
ports: [4000],
}),
instructions:
'You are a careful coding assistant. Prefer small changes and explain tradeoffs.',
});
セッションを作成し、generate()またはstream()でプロンプトを送ります。Claude Code用のブリッジ型ハーネスでは、@ai-sdk/sandbox-vercelのようなネットワークサンドボックスが必要です。Piのようにポート公開が不要なハーネスは、@ai-sdk/sandbox-just-bashでも動作します。
claudeCodeをcodexやpiに差し替えても、HarnessAgent側のフローは維持できます。これが「エージェントのbrainをアプリに統合しつつ、基盤を選び直せる」という設計の核心です。
セッション管理の違い
HarnessAgentを使うとき、モデル呼び出しとは会話履歴の扱いが異なります。ハーネスセッションがネイティブな会話状態を保持するため、messagesを渡しても最新のユーザー入力だけがそのターンの入力になります。
HTTPルートで複数ターンを継続する場合は、メッセージ配列の再送ではなく、安定したsessionIdとdetach()やstop()が返す再開状態を永続化する設計が推奨されます。session.destroy()でランタイムを止め、再開が不要なワンショット処理に向きます。
カスタムのinstructions、tools、skills、権限モード、onSandboxSessionフックも指定できます。アダプター固有の設定は、createCodex({ reasoningEffort: 'high' })のようにファクトリー関数側に渡します。
プロバイダー抽象化との関係
HarnessAgentは、プロバイダー/モデル抽象化とは別レイヤーです。generateTextやstreamTextがモデルを、HarnessAgentがエージェントランタイムを露出します。
ただし出力はAI SDKのストリーム型へ射影されるため、toUIMessageStream経由でuseChatに渡せます。UIコードを変えずにHarnessAgentへ切り替えられる点は、既存のAI SDKアプリにとって大きな移行メリットです。
自前のツールループや構造化出力を細かく制御したい場合は、従来どおりプロバイダーとモデルを直接使う選択肢が残ります。既存のコーディングエージェントの振る舞いをそのまま活かしたい場合にHarnessAgentが向きます。
開発者が得る実用メリット
HarnessAgentは、エージェント基盤のベンダーロックイン回避だけでなく、開発体験の統一にも効きます。サンドボックス上でエージェントを動かすため、ホスト環境へのファイル改変リスクを抑えられます。ハーネス固有のイベントは、テキストやツール呼び出しなどAI SDK互換のストリームパーツへ翻訳されます。
canaryチャネルでの提供である点は留意が必要ですが、AIアプリ開発者にとって「モデルもエージェントも設定で差し替える」という方針は、今後のエージェント基盤の入れ替えコストを大きく下げる動きです。公式ドキュメントとVercel changelogの手順に沿って、まずはClaude CodeかCodexのいずれかで試すのが現実的です。