コーディングエージェント統合：Grok Build向けVercel AI SDKアダプター解説

2026年8月13日、VercelはGrok BuildをAI SDK 7のHarnessAgentへ正式に接続する手段を提供しました。これにより、製品側ではハーネスごとにオーケストレーション層を作り直すことなく、Vercelが現在サポートする9種類のコーディングエージェント用ハーネスと同じアプリケーションインターフェースからGrok Buildを実行できます。

Vercelが実際に公開したもの

今回リリースされたのはアダプターであり、新しいGrokモデルではありません。

仕組みを理解するには、各レイヤーを切り分けるのが近道です。モデルは応答を生成します。コーディングハーネスはファイル、ツール、セッション、権限、そしてタスクを継続させるループを管理し、モデルを実際に作業するワーカーへ変えます。Agent Client Protocol（ACP）は、クライアントと互換性のあるハーネスの間で使う共通言語です。アダプターは、そのプロトコルをアプリケーションがすでに理解できるインターフェースへ変換します。

Vercelの新しいパッケージは@ai-sdk/harness-grok-buildです。内部では下位レイヤーの@ai-sdk/harness-acpパッケージを使い、ACP経由でHarnessAgentとGrok Build CLIを接続します。

処理の流れは次のようになります。

アプリケーション → HarnessAgent → Grok Buildアダプター → サンドボックス内のGrok Build CLI

汎用ACPレイヤーが配管に当たるのに対し、Grok Buildアダプターはパッケージ、実行ファイル、認証マッピング、起動コマンド、ツールマッピングまで定義済みの完成したコネクターです。プロトコルの仕組みを詳しく知りたい場合は、AI SDKのACPハーネスアダプター解説を参照してください。この記事では、実際に利用できるGrok Buildの経路に絞って説明します。

このリリース以前は、ACPランタイムを追加するたびに、そのランタイムプロファイルを自分で定義する必要がありました。8月13日のGrok Build対応によって公式アダプターが用意され、Claude Code、Codex、Deep Agents、OpenCode、Piと同じHarnessAgentのセッションフローで扱えるようになりました。この時点で対応ハーネスは6種類でした。

2026年8月31日以降は、Vercelによるfxの追加でサポート対象が9種類に増えています。内訳はClaude Code、Cline、Codex、Cursor、Deep Agents、fx、Grok Build、OpenCode、Piです。fxアダプターは選択肢を増やしたものであり、Grok Buildアダプターの動作を変えるものではありません。

重要なのは「同じエージェント」ではなく「同じインターフェース」で扱える点です。アプリケーション側の契約は維持できますが、対応する9種類のハーネスでツールの挙動、権限、可観測性、モデル出力まで同一になるわけではありません。

このコーディングエージェント統合が重要な理由

変わったのは、統合に必要な作業量です。

HarnessAgent.generate()とHarnessAgent.stream()は、AI SDK互換の結果を返します。製品にAI SDKベースのチャット画面やタスク画面がすでにあれば、その既存の結果フローの背後でGrok Buildを動かせます。サーバー側のハーネスを変更しても、ワーカーが変わったという理由だけでユーザーインターフェースに新しい応答形式を追加する必要はありません。

プラットフォームチームにとっては、ランタイムの比較やジョブの振り分けが整理しやすくなります。共通のセッションライフサイクルとストリーム形式を維持しながら、タスクに合うハーネスを選べます。

ただし、Grok Buildが高速、低コスト、あるいは高精度になるわけではありません。今回加わったのは、公式にサポートされた接続手段です。Grok Buildを専用CLIから使うだけの人にも影響はありません。対象となるのは、コーディングエージェントを組み込んだ製品や社内システムを構築する人です。

すぐに活用できるのはどのチームか

ランタイムを追加したい開発者向けツールの創業者

AI SDK上にAIコードレビュー製品やリポジトリ修復製品を構築しているなら、Grok Build専用のセッションAPIやストリーミング契約を別途作ることなく、サーバー側ハーネスの選択肢として追加できます。

実際の変更は小規模です。アダプターをインストールし、同種のサンドボックスを接続して、顧客やタスクに応じてGrok Buildを選びます。保守すべき製品画面を増やさずに、利用可能なランタイムを増やせることが利点です。

9種類のハーネスを比較するプラットフォームエンジニア

範囲を限定した同じリポジトリタスクをGrok Buildと別の対応ハーネスに実行させ、共通のアプリケーションフロー上で完了品質や失敗時の挙動を比較できます。

ただし、比較条件には注意が必要です。ACP version 1ではステップ単位の使用量が常に取得できるとは限りません。Grokが合計値を返さない場合、このアダプターではトークン単位の正確なコスト比較はできません。成果とエンドツーエンドの挙動は比べられますが、可観測性の全フィールドが同じ粒度で揃うとは限りません。

リポジトリを修復する社内ツールチーム

失敗したテストを修復するタスクを隔離ワークスペースへ送り、エージェントのテキストを担当者へストリーミングし、ジョブ終了時にセッションを破棄できます。サンドボックス境界がホストを保護し、明示的なライフサイクル管理によって一時セッションが放置されたインフラになるのを防ぎます。

得られるのは運用上の制御です。コードを変更するワーカーは範囲を限定した環境で動き、その環境をいつ開始し、いつ終了するかはアプリケーションが管理します。

導入を審査するセキュリティ／信頼性責任者

この担当者には、実際に判断すべき認証経路があります。直接認証ではXAI_API_KEYを使用し、AI Gateway認証ではGatewayの認証情報を使用します。デフォルトのautoモードは、AI Gatewayの認証情報があればAI Gatewayを、なければxAIの直接認証を選びます。

さらに、実際のツール境界で権限を検証する必要があります。Grok BuildはACPのセッションモードを公開しておらず、安全な組み込み処理の一部はACPの権限リクエストなしで行われる可能性があります。別のハーネス向けに作ったポリシーが、Grok Buildでも同じように機能する保証はありません。

公式ドキュメントどおりに実行する

最短の完全な構成では、Vercel Sandboxとアダプターのデフォルト設定を使います。

1. 1

   パッケージをインストールする

   共通ハーネスAPI、Grok Buildアダプター、Vercel Sandbox実装を追加します。

   pnpm add @ai-sdk/harness @ai-sdk/harness-grok-build @ai-sdk/sandbox-vercel

2. 2

   サンドボックスとモデルの認証情報を設定する

   ドキュメントに記載されたVercel Sandboxの経路では、VERCEL_OIDC_TOKENを利用できる状態にします。Grokの直接認証にはXAI_API_KEYを指定します。Gateway経由では対応するAI Gatewayの認証情報を設定し、ベースURLの上書きが必要な場合はAI_GATEWAY_BASE_URLを使用できます。アダプターのデフォルト設定であるauth: 'auto'が、利用可能な経路を選びます。

3. 3

   セッションを作成し、実行後に破棄する

   現在のGrok Buildハーネスのサンプルは次のとおりです。

   import { HarnessAgent } from '@ai-sdk/harness/agent';
   import { grokBuild } from '@ai-sdk/harness-grok-build';
   import { createVercelSandbox } from '@ai-sdk/sandbox-vercel';
   
   const agent = new HarnessAgent({
     harness: grokBuild,
     model: 'grok-build-0.1',
     sandbox: createVercelSandbox({
       runtime: 'node24',
       ports: [4000],
     }),
   });
   
   const session = await agent.createSession();
   
   let exitCode = 0;
   try {
     const result = await agent.stream({
       session,
       prompt: 'Check the test failures and fix the production code.',
     });
   
     for await (const part of result.stream) {
       if (part.type === 'text-delta') {
         process.stdout.write(part.text);
       }
     }
   } catch (err) {
     exitCode = 1;
     console.error(err);
   } finally {
     await session.destroy();
     process.exit(exitCode);
   }

4. 4

   初回セッションではネットワーク経由のインストールを見込む

   ACPハーネスは、サンドボックス内にバージョン固定された@xai-official/grok@1.0.5パッケージをインストールするため、初回セッションで外向きのネットワーク接続を必要とします。外部通信を許可していないサンドボックスでは、エージェントが有用な処理を始める前に失敗します。

見落とされやすいのがポートです。Grok Buildには、ACPブリッジ用として少なくとも1つのポートを公開したネットワーク対応サンドボックスが必要です。サンプルではNode 24とポート4000を使っています。そのネットワーク経路を持たないサンドボックスオブジェクトでは、同等の構成になりません。

現在のサンプルでは、HarnessAgentにmodel: 'grok-build-0.1'を渡しています。アダプターを細かく制御する必要がある場合は、grokBuildをcreateGrokBuild()に置き換えます。認証、認証情報の転送、推論の強度、MCPサーバー、ブリッジポート、起動タイムアウト、カスタムのブリッジトークン関数を指定できます。reasoningEffortを省略すると、Grok Buildに設定されたデフォルト値が使われます。

本番導入前に知っておくべき制約

このアダプターはACP version 1の制約を引き継いでおり、本番環境では無視できません。

• 使用量は不完全です。 ACPはモデルのステップ境界やステップ単位の使用量を公開しません。アダプターは境界を推定し、Grokが合計値を返さない場合は使用量を不明として報告します。
• 実行中のターンを移植可能な形で制御できません。 ACPには、ターン途中の指示変更や手動コンパクションに使える共通APIがありません。
• 組み込みツールのフィルタリングには制限があります。 ホスト側ツールは絞り込めますが、Grokの組み込みツールを絞り込もうとすると、未対応機能を示すエラーが発生します。
• ツールカタログが古いままになる可能性があります。 ホスト側のツール一覧が変わると、Grok BuildはACP MCP一覧を更新する必要があります。古い一覧を保持したままだと、ターンは明示的に失敗します。

リリース管理にもリスクがあります。AI SDKのハーネスパッケージは実験的な位置づけのため、リリース間で破壊的変更が入ることを想定する必要があります。GrokアダプターはCLIとACPの起動コマンドを内部で固定しており、createGrokBuild()からはそれらを上書きできません。サポート対象の経路がシンプルになる一方、固定されたランタイムをいつ変更するかはアダプターパッケージ側が決めることになります。

デフォルトのブリッジ認証情報は、ランダムな32-byteトークンです。トークン関数を差し替える場合、戻り値には適切な秘匿性が必要です。これはセキュリティ制御であり、読みやすい開発用文字列を設定する場所ではありません。

最後に、これは料金に関するリリースではありません。Grokの認証経路とネットワーク対応サンドボックスには、それぞれ運用コストがかかります。アダプターが減らすのは独自の統合作業であり、その下にあるインフラが不要になるわけではありません。

今、導入すべきか

すでにAI SDK 7を運用し、Grok Buildを選択可能なコーディングランタイムに加えたいなら、今週中に着手する価値があります。まずは範囲を限定したリポジトリタスクでデフォルトのアダプターを使い、成功と失敗の両方の経路を試して、セッションが確実に破棄されることを確認してください。

複数のハーネスを製品の背後で使う必要がある場合は、本番投入前に短期間の評価を行います。タスクの結果、権限の挙動、障害からの復旧、ジョブ全体のコストを比較してください。ACPがデータを提供しない可能性があるため、ステップ単位の使用量を判断基準にしてはいけません。

手動コンパクション、ターン途中の指示変更、正確なステップ単位の計測、組み込みツールの許可リストが必須なら、導入は待つべきです。これらは設定ミスではなく、プロトコル側の不足です。

Grok Buildを直接使っている場合、コーディングハーネスを介さずにGrokモデルを呼び出している場合、またはエージェントのランタイムを切り替えるアプリケーションがない場合は影響を受けません。

チームの開発手法を変えるツールについて、さらに実践的な解説を読みたい方は、ニュースレターにご登録ください。