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()で扱うクラスです。返り値はGenerateTextResultStreamTextResultとして、既存の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でも動作します。

claudeCodecodexpiに差し替えても、HarnessAgent側のフローは維持できます。これが「エージェントのbrainをアプリに統合しつつ、基盤を選び直せる」という設計の核心です。

セッション管理の違い

HarnessAgentを使うとき、モデル呼び出しとは会話履歴の扱いが異なります。ハーネスセッションがネイティブな会話状態を保持するため、messagesを渡しても最新のユーザー入力だけがそのターンの入力になります。

HTTPルートで複数ターンを継続する場合は、メッセージ配列の再送ではなく、安定したsessionIddetach()stop()が返す再開状態を永続化する設計が推奨されます。session.destroy()でランタイムを止め、再開が不要なワンショット処理に向きます。

カスタムのinstructionstoolsskills、権限モード、onSandboxSessionフックも指定できます。アダプター固有の設定は、createCodex({ reasoningEffort: 'high' })のようにファクトリー関数側に渡します。

プロバイダー抽象化との関係

HarnessAgentは、プロバイダー/モデル抽象化とは別レイヤーです。generateTextstreamTextがモデルを、HarnessAgentがエージェントランタイムを露出します。

ただし出力はAI SDKのストリーム型へ射影されるため、toUIMessageStream経由でuseChatに渡せます。UIコードを変えずにHarnessAgentへ切り替えられる点は、既存のAI SDKアプリにとって大きな移行メリットです。

自前のツールループや構造化出力を細かく制御したい場合は、従来どおりプロバイダーとモデルを直接使う選択肢が残ります。既存のコーディングエージェントの振る舞いをそのまま活かしたい場合にHarnessAgentが向きます。

開発者が得る実用メリット

HarnessAgentは、エージェント基盤のベンダーロックイン回避だけでなく、開発体験の統一にも効きます。サンドボックス上でエージェントを動かすため、ホスト環境へのファイル改変リスクを抑えられます。ハーネス固有のイベントは、テキストやツール呼び出しなどAI SDK互換のストリームパーツへ翻訳されます。

canaryチャネルでの提供である点は留意が必要ですが、AIアプリ開発者にとって「モデルもエージェントも設定で差し替える」という方針は、今後のエージェント基盤の入れ替えコストを大きく下げる動きです。公式ドキュメントとVercel changelogの手順に沿って、まずはClaude CodeかCodexのいずれかで試すのが現実的です。