
AIエージェントが実際のワークフローを処理できるほど高機能になるにつれて、新たなインフラ上の課題が浮上しています。人間とエージェントは実行中にどうやってやり取りするのか。開始時と終了時だけでなく、処理の途中全体を通してどう通信するのか、という問題です。
AG-UIプロトコルは、まさにこの課題を解決するために設計されたオープン仕様です。AIエージェントがどのようにイベントをストリーミングし、入力を要求し、状態をフロントエンドアプリケーションや人間のオペレーターにリアルタイムで提示するかについて、標準を定義します。MCP(Model Context Protocol)がエージェントのツールアクセス方法を標準化したのだとすれば、AG-UIはエージェントがユーザーとどう対話するかを標準化するものです。
このガイドでは、AG-UIとは何か、なぜ重要なのか、どう動くのか、そしてエージェントスタックでどう使い始めるかを解説します。
AG-UIが解決する問題
AG-UI以前は、人間向けのAIエージェントアプリケーションを構築するすべてのチームが、独自の通信プロトコルを考案する必要がありました。エージェントが考え中であることをフロントエンドにどう伝えるのか。人間の判断が必要なときにどう要求するのか。タスクの途中でユーザーがどう修正を送るのか。進捗はどう表示するのか。
その答えはチームごとに異なり、多くの場合、場当たり的で、文書化も不十分で、再利用しにくいものでした。その結果、次のような分断されたエコシステムが生まれました。
- エージェントフレームワーク間でフロントエンドコンポーネントを共有できない
- 開発者がプロジェクトごとにストリーミングUI基盤をゼロから作り直さなければならない
- エージェント搭載プロダクトごとにユーザー体験が一貫しない
- エージェントの挙動をデバッグするたびに、実装ごとの独自ログが必要になる
AG-UIは、共通の語彙とイベント構造を定義することで、どのエージェントフレームワークでもイベントを生成でき、どのAG-UI互換フロントエンドでもそれを描画できるようにします。カスタムの統合コードは不要です。
AG-UIとは何か
AG-UIは、AIエージェントとユーザー向けインターフェースの間でやり取りされるメッセージの形式と意味を定義する、オープンなストリーミングイベントプロトコルです。
その特徴は次のとおりです。
- トランスポート非依存: HTTP(Server-Sent Events)、WebSocket、その他あらゆるストリーミング通信で利用可能
- フレームワーク非依存: どの言語、どのエージェントフレームワークでも実装可能
- 双方向: エージェントはフロントエンドにイベントを送り、ユーザーはメッセージや割り込みをエージェントに送る
- ステートフル: 状態のスナップショットが含まれるため、フロントエンドは任意の時点で完全なエージェントコンテキストを再構築できる
一方で、次のものではありません。
- ツールプロトコルではない。それはMCPの役割
- エージェントフレームワークそのものではない
- UIコンポーネントライブラリではない。ただしリファレンス実装は存在する
AG-UIとMCPの違いを理解する
よく混同されるのが、AG-UIとAnthropicのModel Context Protocol(MCP)の関係です。
| 観点 | MCP | AG-UI |
|---|---|---|
| 目的 | エージェント ↔ ツール間の通信 | エージェント ↔ 人間/フロントエンド間の通信 |
| 方向 | エージェントがツールを呼び出し、結果を受け取る | エージェントがイベントをストリーミングし、人間がメッセージを送る |
| 対象読者 | ツール/サーバー開発者 | フロントエンド開発者、エージェントフレームワーク開発者 |
| 焦点 | エージェントが利用できる能力は何か | エージェントが状態と進捗をどう伝えるか |
| 関係性 | エージェントのツール側を扱う | エージェントのユーザーインターフェース側を扱う |
両者は補完関係にあります。本番環境で動くエージェントは通常、MCPでツール、たとえばWeb検索、画像生成、コード実行にアクセスし、AG-UIで進捗を伝えたり、人間の入力を求めたりします。
AG-UIのコア概念
イベントタイプ
AG-UIは、エージェントが発行する標準的なイベントタイプのセットを定義しています。
ライフサイクルイベント:
RUN_STARTED/RUN_FINISHED— エージェントが実行を開始または完了したSTEP_STARTED/STEP_FINISHED— ワークフロー内の個別ステップが開始または終了したRUN_ERROR— エージェントが回復不能なエラーに遭遇した
メッセージイベント:
TEXT_MESSAGE_START/TEXT_MESSAGE_CONTENT/TEXT_MESSAGE_END— エージェントからのテキスト出力をストリーミングするTOOL_CALL_START/TOOL_CALL_ARGS/TOOL_CALL_END— エージェントがツールを呼び出している
状態イベント:
STATE_SNAPSHOT— 現在のエージェント状態の完全なスナップショットSTATE_DELTA— 状態への増分更新MESSAGES_SNAPSHOT— ある時点での会話履歴全体
カスタムイベント:
CUSTOM— 標準セットでは扱わないアプリケーション固有のイベント用
人間の介入ターン
AG-UIは、実行中のエージェントに人間がどう関与するかも標準化しています。フロントエンドは AgentInput を送信し、実行の途中でエージェントを中断したり、方向転換させたり、情報を与えたりできます。これは新しい会話ターンとは異なります。エージェントはすでに動作中であり、人間はその現在のタスクに影響を与えているのです。
スレッドベースのアーキテクチャ
AG-UIはエージェント実行を スレッド に整理します。これは複数回の実行にまたがって状態を保持する永続的な会話コンテキストです。AG-UIにおけるスレッドは、他のフレームワークでいうセッションや会話におおむね相当しますが、再開、分岐、リプレイを明示的にプロトコルでサポートしている点が異なります。
AG-UIの仕組み: 典型的なフロー
1. ユーザーがフロントエンド経由でタスクを送信する
2. フロントエンドが InitialRun リクエストと RunAgentInput をエージェントバックエンドに送る
3. エージェントが実行を開始し、RUN_STARTED イベントを発行する
4. エージェントが各計画ステップごとに STEP_STARTED を発行する
5. エージェントがツールを呼び出す → TOOL_CALL_START、TOOL_CALL_ARGS、TOOL_CALL_END を発行する
6. エージェントがテキストを生成する → TEXT_MESSAGE_START、TEXT_MESSAGE_CONTENT(ストリーミング)、TEXT_MESSAGE_END を発行する
7. エージェントが STATE_DELTA を発行し、フロントエンドの状態をリアルタイムで更新する
8. ユーザーがエージェントの方向を変えると決める → 修正内容を含む AgentInput を送る
9. エージェントが修正を取り込み、処理を継続する
10. エージェントが RUN_FINISHED を発行する
フロントエンドはこれらのイベントをストリームとして受け取り、段階的に描画します。ツール呼び出しをその場で表示し、テキストをリアルタイムで流し、ステップイベントに基づいて進捗インジケーターを更新します。
AG-UIを実装する
フレームワークの対応状況
AG-UIは主要なエージェントフレームワークでのサポートが広がっています。
- LangGraph: AG-UI Python SDKを使って、グラフノードからAG-UIイベントを発行できる
- AG-UI CopilotKit integration: CopilotKit、AI向けのReactフロントエンドフレームワークはAG-UIをネイティブサポートしている
- カスタム実装: AG-UI仕様はオープンなので、イベントタイプ定義に基づいてどのフレームワークでも実装できる
クイックスタート(Python)
from ag_ui.core import (
RunAgentInput, EventType,
RunStartedEvent, TextMessageStartEvent,
TextMessageContentEvent, TextMessageEndEvent,
RunFinishedEvent,
)
import uuid
async def run_agent(input: RunAgentInput):
run_id = str(uuid.uuid4())
yield RunStartedEvent(
type=EventType.RUN_STARTED,
thread_id=input.thread_id,
run_id=run_id,
)
msg_id = str(uuid.uuid4())
yield TextMessageStartEvent(type=EventType.TEXT_MESSAGE_START, message_id=msg_id, role="assistant")
for chunk in agent.stream(input.messages):
yield TextMessageContentEvent(
type=EventType.TEXT_MESSAGE_CONTENT,
message_id=msg_id,
delta=chunk
)
yield TextMessageEndEvent(type=EventType.TEXT_MESSAGE_END, message_id=msg_id)
yield RunFinishedEvent(type=EventType.RUN_FINISHED, thread_id=input.thread_id, run_id=run_id)
AnyCapとの接続
AG-UI対応エージェントが、Web検索、画像生成、ファイル保存といった現実世界の機能を必要とする場合、AnyCapはオーケストレーションの下層にあるツールレイヤーとして統合されます。エージェントは実行ループ中にAnyCapのツールを呼び出し、対応する TOOL_CALL_* イベントを発行することで、フロントエンドに何が起きているかを表示させます。
User: "主要なAIフレームワーク上位5つを調査して、要約画像を作成して"
Agent emits: TOOL_CALL_START (tool: "anycap_search", args: {...})
Agent emits: TOOL_CALL_END (result: search results)
Agent emits: TOOL_CALL_START (tool: "anycap_image_generate", args: {...})
Agent emits: TOOL_CALL_END (result: image URL)
Agent emits: TEXT_MESSAGE (streaming summary with embedded image)
AG-UIイベントによって可視化されるこの完全な透明性こそが、信頼できる人間とエージェントのインターフェースを、ブラックボックスと分けるポイントです。
なぜ本番のエージェントアプリケーションでAG-UIが重要なのか
エージェント搭載プロダクトを構築するなら、AG-UIは次の価値を提供します。
コンポーネントの再利用性。 AG-UI仕様に準拠して作られたフロントエンドコンポーネントは、互換性のあるどのバックエンドでも動作します。ストリーミング対応チャットUIを一度作れば、LangGraph、CrewAI、AutoGenで変更なく使えます。
一貫したユーザー体験。 イベントタイプが標準化されているため、異なるエージェントワークフローでもユーザーは同じような操作パターンを体験できます。
デバッグ性。 AG-UIの状態スナップショットとイベントストリームは、エージェント実行の完全な記録を提供します。イベントストリームをリプレイすれば、各ステップでエージェントが何を見て何をしたのかを正確に確認できます。
人間による監督。 タスク途中で人間が介入するための AgentInput の仕組みは、後付けではなく、プロトコルに組み込まれています。
まとめ
AG-UIは、エージェント型AIのインフラスタックに存在していた実際のギャップを埋めます。エージェントがより高機能になり、よりユーザーに近い存在になるほど、状態をどう伝え、人間の入力をどう受け取るかという通信プロトコルは、アクセスできるツールと同じくらい重要になります。
2026年にエージェント搭載プロダクトを構築する開発者にとって、AG-UIを早期に採用することは、エコシステム全体が収束しつつある基盤の上に構築することを意味します。プロダクトの成長とともに負債になりうる独自通信レイヤーを維持する必要はありません。
関連リンク:
- AIオーケストレーションフレームワーク比較
- MCP vs. Skills: どちらを使うべきか?
- AnyCapの機能
- AG-UI GitHubリポジトリ
- 自動化オーケストレーションツールガイド 2026 — Zapier vs n8n vs Temporal vs LangGraph: 選び方
- データオーケストレーションツール 2026 — AirflowからAIネイティブなオーケストレーションまで、エージェントパイプラインでの比較