AIエージェント入門

AG-UIとGenerative UIでエージェントUIを作る【2026】

この記事の結論

エージェントのUIはチャットの往復だけでは足りない。AG-UIのイベント標準と、ツール結果をUIにするGenerative UIで、途中経過・人の承認・動的UIを実装する考え方を開発者向けに解説します。

結論: エージェントのUIは「チャットの往復」だけでは足りない。途中経過の表示・人の承認・動的なフォーム生成までを扱うには、AG-UI(Agent-User Interaction Protocol)のようなイベント標準と、ツール結果をUIコンポーネントに変換するGenerative UIの組み合わせが現実的な解になる。

この記事の要点:

  • 要点1: AG-UIは2026年6月時点で約20のフレームワーク統合を持つイベントベースのプロトコルで、ライフサイクル・テキスト・ツール呼び出し・状態管理など複数カテゴリのイベントをSSE/WebSocket/HTTPで往復させる。
  • 要点2: Generative UI(Vercel AI SDK等)は「ツール呼び出しの結果をReactコンポーネントに接続する」仕組みで、テキスト一辺倒のチャットから脱却できる。
  • 要点3: Human-in-the-loopの承認UIやツール実行の可視化は、自前実装とCopilotKitのようなライブラリ利用の2択。標準化は途上で、実装ごとに差がある。

対象読者: チャット以上のエージェントUIを作りたいフロントエンド/フルスタック開発者
難易度: 中級
読了時間: 約12分

「エージェントは動いているのに、画面はずっと『考え中…』のままで何が起きているか分からない」——AIエージェントのUIを作り始めると、多くの開発者がこの壁にぶつかります。

原因はシンプルで、エージェントは従来のREST/GraphQLが前提とする「リクエスト1回→レスポンス1回」のモデルに収まらないからです。長時間動き続け、途中でツールを呼び、ときには人間の承認を待ち、出力に応じてUIそのものを変えたくなる。テキストの往復だけで表現しようとすると、どうしても情報量が足りません。

この記事では、エージェントとフロントエンドUIを連携させるための考え方を、①UIの課題 ②AG-UIプロトコル ③Generative UI ④Human-in-the-loopとツール実行の可視化 ⑤実装の選択肢、の順で解説します。なお本記事はエージェントの「途中経過のリアルタイム表示」全般を扱うため、トークン単位の逐次描画に絞ったストリーミング応答 実装ガイド|SSE・トークン逐次表示とは別軸の内容です。あわせて読むと、低レイヤのSSEから高レイヤのUIプロトコルまでが地続きで理解できるはずです。

なぜエージェントUIは「チャットの往復」だけでは足りないのか

まず、エージェントUIが普通のWeb APIと何が違うのかを整理します。AG-UIの公式ドキュメントは、従来のリクエスト・レスポンス型がエージェントに合わない理由として、おおむね次の4点を挙げています。

  • 長時間の処理: 複数ターンにまたがって中間的な作業をストリーミングし続ける。
  • 非決定的な振る舞い: エージェントが動的にアプリのUIを制御する。
  • 入出力の混在: ツール呼び出しや状態更新といった構造化データと、テキスト・音声などの非構造化データが混ざる。
  • 合成(composition)の必要性: サブエージェントへの再帰的な委譲が発生する。

これを「画面側の課題」に翻訳すると、エージェントUIが扱うべき表示は次のように広がります。

UIで見せたいもの チャットだけだと 本来必要な扱い
途中経過(どのステップを実行中か) 「考え中…」のスピナーのみ ステップ単位のイベント表示
ツール実行(検索・DB照会など) 結果テキストだけ後から出る 実行開始→引数→結果の可視化
人の承認(送信・決済など) 表現できない 処理を中断して確認UIを出す
動的なUI(表・カード・フォーム) Markdownで近似 出力に応じてコンポーネント生成
共有状態(カート・ドラフト等) 都度全文を再送 差分だけ送って同期

率直に言うと、これらを自前で素朴に実装すると、サーバーが送るデータ形式とフロントの受け取り方が記事(機能)ごとにバラバラになりがちです。そこで「エージェントとUIの間でやり取りするイベントの形」を標準化しよう、という発想が出てきます。それがAG-UIです。

このレイヤの位置づけを整理するために、エージェント関連プロトコルの3層構造を押さえておくと見通しが良くなります。

レイヤ プロトコル 役割
エージェント ↔ ユーザー(UI) AG-UI エージェントとユーザー向けアプリをつなぐ
エージェント ↔ ツール/データ MCP 外部システムへの接続(Anthropic発)
エージェント ↔ エージェント A2A 分散エージェント間の連携(Google発)

つまりAG-UIは「MCPやA2Aと競合する」のではなく、それらの一つ上、ユーザーの画面に最も近いレイヤを担う位置づけです。MCPの全体像はAIエージェント実装ロードマップ|RAG・実行・運用の必須技術でも触れているので、スタック全体を俯瞰したい場合はそちらも参考になります。

エージェントUIの3要素。①途中経過の可視化(AG-UIイベントでツール実行や進捗を表示)②人の承認 Human-in-the-loop(実行前に止めて確認)③動的UI生成 Generative UI(モデル出力に応じてボタンやフォームを出す)。AG-UIのイベント標準+SSEストリーミング。標準化途上。
エージェントUIの3要素(途中経過の可視化・人の承認HITL・動的UI生成)

AG-UIプロトコルの考え方|イベントで往復する

AG-UI(Agent-User Interaction Protocol)は、AIエージェントのバックエンドとフロントエンドの間を、軽量・イベントベースで双方向に結ぶオープンな標準です。フロントとエージェントが、メッセージ・ツール呼び出し・状態更新・ライフサイクル信号といったJSONイベントの流れを、WebSocket・SSE・HTTPの上でやり取りします。

重要なのは「1つの大きなレスポンス」ではなく「細かいイベントの連続」として設計されている点です。公式ドキュメントの分類に沿うと、イベントはおおまかに次のカテゴリに分かれます。

カテゴリ 主なイベント例 UIでの使い道
ライフサイクル RunStarted / RunFinished / RunError / StepStarted / StepFinished 実行の開始・終了・ステップ進捗の表示
テキストメッセージ TextMessageStart / TextMessageContent / TextMessageEnd 回答テキストの逐次表示
ツール呼び出し ToolCallStart / ToolCallArgs / ToolCallEnd / ToolCallResult ツール実行の可視化
状態管理 StateSnapshot / StateDelta / MessagesSnapshot 共有状態の同期
推論 ReasoningStart / ReasoningEnd など 思考ステップの可視化
特殊 Raw / Custom 外部イベントの通過・独自拡張

イベントの粒度を見ると、UIで何ができるかが具体的に見えてきます。たとえばツール呼び出しは「開始(Start)→引数(Args)→終了(End)→結果(Result)」と段階的に流れてくるため、UI側は「いま◯◯を検索しています」というカード表示や、結果が返ったら展開する、といった表現が自然に書けます。

状態管理で押さえておきたいのが StateDelta です。AG-UIの仕様では、StateDelta はJSON Patch(RFC 6902)に基づく差分操作で状態を更新します。毎回フルの状態を送らず、変わった部分だけを送るため帯域効率が良い、という設計です。チャットUIに「ドラフト」「カート」「進捗ボード」のような共有状態を持たせるとき、この差分同期が効いてきます。

受信側のイベント処理は、概念的には次のような分岐になります(擬似コード)。

// AG-UI のイベントストリームを受け取る側の概念例(擬似コード)
for await (const event of agentEventStream) {
  switch (event.type) {
    case "TextMessageContent":
      // 回答テキストを逐次追記
      appendAssistantText(event.delta);
      break;
    case "ToolCallStart":
      // 「◯◯を実行中」のカードを表示
      showToolCard(event.toolName, { status: "running" });
      break;
    case "ToolCallResult":
      // 結果が返ったらカードを更新
      updateToolCard(event.toolCallId, { status: "done", result: event.result });
      break;
    case "StateDelta":
      // JSON Patch (RFC 6902) を適用して共有状態を更新
      applyJsonPatch(sharedState, event.delta);
      break;
    // RunStarted / RunFinished / Custom など…
  }
}

注意したいのは、AG-UI自体はまだ発展途上の領域だということです。公式ドキュメント上でも一部のフレームワーク統合やSDKが「In Progress」と明記されており、対応範囲や成熟度はフレームワークによって差があります。本記事の各イベント名・カテゴリも2026年6月時点の公式情報に基づくもので、今後の改訂で増減する可能性があります。

Generative UI|モデルの出力をコンポーネントに変える

AG-UIが「イベントの運び方」の標準だとすると、Generative UIは「運ばれてきた結果を、テキストではなくUIコンポーネントとして描く」アプローチです。両者は対立するものではなく、組み合わせて使えます。

分かりやすいのがVercel AI SDKの定義で、ドキュメントは Generative UI を「ツール呼び出しの結果をReactコンポーネントに接続するプロセス」と説明しています。仕組みを噛み砕くと次の流れです。

  1. ツール定義: 入力スキーマ(Zod等)と実行関数を持つツールを定義する。実行関数は構造化データを返す。
  2. モデル処理: API側で streamText() にツールを渡す。モデルが文脈に応じてツールを呼ぶか判断する。
  3. ツール実行: ツールが実行され、データを返す。
  4. コンポーネント描画: クライアントの useChat() がツール結果パートを含むメッセージを受け取り、対応するReactコンポーネントを描く。

クライアント側は、メッセージの「パート」を見て分岐します。Vercel AI SDKでは、ツール結果は tool-${toolName} という型で識別され、input-available / output-available / output-error といった状態を持ちます。状態を見ながら「実行中はスケルトン、結果が来たら本番コンポーネント、エラーはエラーカード」と描き分けられるわけです。

// Vercel AI SDK 風: ツール結果パートを見てコンポーネントを出し分ける概念例
{message.parts.map((part) => {
  // 天気ツールの結果なら WeatherCard を描画
  if (part.type === "tool-getWeather") {
    if (part.state === "output-available") {
      return <WeatherCard data={part.output} />;
    }
    if (part.state === "input-available") {
      return <WeatherCardSkeleton />; // 実行中はスケルトン
    }
    if (part.state === "output-error") {
      return <ErrorCard message={part.errorText} />;
    }
  }
  // 通常テキストはそのまま表示
  if (part.type === "text") return <p>{part.text}</p>;
})}

このパターンの良いところは、「モデルに自由文でHTMLを書かせる」のではなく、アプリ側が用意した安全なコンポーネントを、モデルの判断で呼び出させる点です。表示の見た目・バリデーション・スタイルはこちらが握れるため、デザインの一貫性とセキュリティを保ちやすくなります。なお、AG-UIの機能一覧にも「Generative UI(静的・宣言的の両方)」が含まれており、プロトコル側でもこの概念が想定されています。

Human-in-the-loopの承認UIとツール実行の可視化

エージェントUIで最も「チャットの限界」が出るのが、人間の承認(Human-in-the-loop, HITL)です。メール送信・決済・本番への書き込みのように、取り消せない操作の前で一度止まって確認したい場面は多いはずです。

AG-UIはこれを「割り込み(interrupts)」として扱います。ドキュメントによれば、RunFinished はオプションの outcome フィールドを持ち、{ type: "interrupt", interrupts: [...] } のような形で割り込みを表現できます。クライアントは、開いている割り込みに応える resume 配列を含む新しいrunを発行して、実行を再開させます。つまり「止める→人が判断→再開する」という往復が、プロトコルのレベルで想定されています。

承認UIを設計するときの考え方は、HITL全般の設計論と地続きです。承認の粒度(どの操作で止めるか)、タイムアウト時の挙動、却下時のフォールバックなどは、AIエージェントのHuman-in-the-loop設計ガイドで扱っている観点がそのまま使えます。本記事はそれを「UIレイヤでどう表現するか」に寄せた内容だと考えてください。

ツール実行の可視化は、前述のツール呼び出しイベント(Start/Args/End/Result)をそのまま使えます。可視化の典型的な状態遷移を表にすると次の通りです。

状態 トリガーとなるイベント UI表現の例
実行前/承認待ち interrupt(承認要求) 確認ダイアログ・許可/却下ボタン
実行中 ToolCallStart / ToolCallArgs 「◯◯を実行中」スピナー付きカード
完了 ToolCallResult 結果を展開表示・成功バッジ
失敗 RunError / output-error エラーカード・再試行ボタン

実装の選択肢|ライブラリか自前か、SSEとの関係

ここまでの仕組みを、実際にどう作るか。大きく「ライブラリに乗る」「自前で組む」の2択です。

選択肢1: CopilotKitなどのライブラリに乗る

CopilotKitはAG-UIの主要な実装/推進元の一つで、AG-UIを介してエージェントバックエンドをフロントのチャット・Generative UIに接続するためのコンポーネント群を提供します。AG-UIは2026年6月時点で、CopilotKitに加えてMicrosoft Agent Framework・Google ADK・AWS Strands Agents・Mastra・Pydantic AI・LlamaIndexなど、ファーストパーティだけで多数のフレームワーク統合を持ち、LangGraphやCrewAIともパートナー統合があります。すでにこれらのフレームワークでバックエンドを書いているなら、UI側もイベント標準に乗せやすい、という利点があります。

選択肢2: 自前で実装する

軽量に始めたい、あるいは既存のUIに最小限だけ組み込みたい場合は、SSEで自前のイベントストリームを流す方法もあります。この場合でも、AG-UIのイベント分類(ライフサイクル/テキスト/ツール/状態)を「設計の地図」として借りると、自前フォーマットが整理されます。

ここでSSEとの関係を整理しておきます。SSEは「サーバーからクライアントへイベントを流すトランスポート」であり、AG-UIやGenerative UIは「その上で何をどんなイベント形式でやり取りするか」のレイヤです。トークン単位の逐次描画など、トランスポート層の具体はストリーミング応答 実装ガイドで詳しく扱っているので、自前実装を選ぶなら先にそちらを押さえると土台が安定します。

【注意】エージェントUI実装でハマりやすいポイント

発展途上の領域だけに、つまずきやすい点もはっきりしています。

  • ❌ モデルに自由文でHTMLを生成させて dangerouslySetInnerHTML で描画する
    ⭕ アプリ側が用意した安全なコンポーネントを、ツール呼び出し経由で出し分ける(Generative UIの基本)
  • ❌ 取り消せない操作(送信・決済)を承認UIなしで自動実行する
    ⭕ interrupt/承認の往復を挟み、却下・タイムアウトの分岐まで設計する
  • ❌ 状態が変わるたびに全文を再送して同期する
    StateDelta(JSON Patch / RFC 6902)で差分だけ送る前提で状態を設計する
  • ❌ 「AG-UIに対応」と書いてあれば全機能が揃っていると思い込む
    ⭕ 統合の成熟度はフレームワークごとに差がある(公式に「In Progress」表記あり)。採用前に対応イベント・機能を実機で確認する

まとめ: 今日から始める3つのアクション

  1. 今日: 自分のエージェントUIで「チャット以外に見せたいもの(途中経過・承認・動的UI)」を1つ書き出す。
  2. 今週中: AG-UIのイベント分類(ライフサイクル/テキスト/ツール/状態)に、自分のアプリのイベントを当てはめてマッピング表を作る。
  3. 今月中: CopilotKit等のライブラリか自前SSEかを決め、まずはツール実行の可視化(Start→Result)を小さく実装してみる。

AIエージェント・ツールの最新情報をキャッチアップしたい方へ
Agent Labでは、週1回のニュースレターでAIツールの最新比較・活用事例をお届けしています。

あわせて読みたい:


著者: 佐藤傑(さとう・すぐる)
株式会社Uravation代表取締役。X(@SuguruKun_ai)フォロワー約10万人。100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』(SBクリエイティブ)。

ご質問・ご相談は お問い合わせフォーム からお気軽にどうぞ。

参考・出典

Need help moving from reading to rollout?

この記事を読んで導入イメージが固まってきた方へ

Uravationでは、AIエージェントの要件整理、PoC設計、社内導入、研修まで一気通貫で支援しています。

この記事をシェア

X Facebook LINE

※ 本記事の情報は2026年6月時点のものです。サービスの料金・仕様は変更される可能性があります。最新情報は各サービスの公式サイトをご確認ください。

関連記事