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 vs. MCP：違いを理解する
よくある混乱の原因は、AG-UIとAnthropicのModel Context Protocol（MCP）の関係です。
| 次元 | MCP | AG-UI |
|---|---|---|
| 目的 | エージェント ↔ ツール通信 | エージェント ↔ 人間/フロントエンド通信 |
| 方向 | エージェントがツールを呼び出し、結果を受け取る | エージェントがイベントをストリーミング；人間がメッセージを送信 |
| 対象者 | ツール/サーバー開発者 | フロントエンドおよびエージェントフレームワーク開発者 |
| フォーカス | エージェントが使用できる機能 | エージェントが状態と進捗をどのように通信するか |
| 関係 | エージェントの「ツール」側を担当 | エージェントの「ユーザーインターフェース」側を担当 |
これらは補完的です。本番環境で動作するエージェントは、通常、ツールアクセス（ウェブ検索、画像生成、コード実行）にMCPを使用し、進捗の通信と人間の入力の要求に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. フロントエンドがRunAgentInputを含むInitialRunリクエストをエージェントバックエンドに送信
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統合：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対応のエージェントがウェブ検索、画像生成、ファイルストレージなどの実世界の機能を必要とする場合、AnyCap はオーケストレーションの下のツール層として統合されます。エージェントは実行ループ中にAnyCap ツールを呼び出し、対応するTOOL_CALL_*イベントを発行して、フロントエンドに何が起きているかを表示します：
ユーザー：「上位5つのAIフレームワークを調査してサマリー画像を作成して」
エージェントが発行：TOOL_CALL_START (tool: "anycap_search", args: {...})
エージェントが発行：TOOL_CALL_END (result: 検索結果)
エージェントが発行：TOOL_CALL_START (tool: "anycap_image_generate", args: {...})
エージェントが発行：TOOL_CALL_END (result: 画像URL)
エージェントが発行：TEXT_MESSAGE (画像が埋め込まれたストリーミングサマリー)
この完全な透明性——AG-UIイベントを通じて提供される——が、信頼できる人間エージェントインターフェースとブラックボックスを区別するものです。
AG-UIが本番エージェントアプリケーションに重要な理由
エージェント駆動の製品を構築するなら、AG-UIは以下を提供します：
コンポーネントの再利用性。 AG-UI仕様に従って構築されたフロントエンドコンポーネントは、準拠するあらゆるバックエンドで動作します。ストリーミングチャットUIを一度構築すれば、変更なしにLangGraph、CrewAI、AutoGenで使用できます。
一貫したユーザー体験。 イベントタイプが標準化されているため、ユーザーは異なるエージェントワークフロー全体で同じ操作パターンを体験します。
デバッグ。 AG-UIの状態スナップショットとイベントストリームにより、エージェント実行の完全な記録が得られます。イベントストリームを再生することで、各ステップでエージェントが何を見て、何をしたかを正確に確認できます。
人間による監視。 タスク実行中の人間介入のためのAgentInputメカニズムはプロトコルに組み込まれており——後から追加されたものではありません。
まとめ
AG-UIはエージェント型AIインフラスタックの真のギャップを埋めます。エージェントがより高性能になり、よりユーザー向けになるにつれ、状態を通信し、人間の入力を受け取るプロトコルは、アクセスできるツールと同じくらい重要になります。
2026年にエージェント駆動の製品を構築する開発者にとって、AG-UIを早期に採用することは、エコシステムが収束しつつある基盤の上に構築することを意味します——製品が成長するにつれて負債となるカスタム通信レイヤーを維持するのではなく。
関連記事：