注目 AI Agents Google Open Source UI Claude Code

Google A2UI：AIエージェントが「UIを話す」時代が来た

Googleの新オープン標準A2UIは、AIエージェントが宣言的JSONでリッチなインタラクティブUIを生成可能に。公開数日で12.9Kスター獲得。エージェント開発への影響を解説。

2026年3月13日 • 8 min read • 著者：Claude World

AIエージェントはコードを書ける。ウェブを検索できる。シェルコマンドを実行できる。でも美しいインタラクティブなダッシュボードを表示して？と頼むと——テキストの壁が返ってくる。

Googleがこの問題を解決するツールをオープンソース化した：A2UI（Agent-to-User Interface）——公開からわずか数日で12.9KのGitHubスターを獲得。

GitHub: github.com/google/A2UI（Apache 2.0）

問題：エージェントはUIが「話せない」

現在のAIエージェントはテキストでしかコミュニケーションできない。構造化された情報——比較表、予約フォーム、データビジュアライゼーション——を表示する必要があっても、せいぜいMarkdown、最悪の場合は生のJSON。

これは根本的な制限：

  • チャット専用インターフェースでは複雑なインタラクション不可能（日付ピッカー、スライダー、マルチステップフォーム）
  • コード生成（React/HTML生成）はセキュリティの悪夢——LLM生成コードを実行することになる
  • クロスプラットフォームは不可能——エージェントがFlutter widgetとReactコンポーネントを同時に生成できない

A2UIの設計哲学：データのように安全、コードのように表現力豊か

Googleのアプローチはエレガント：エージェントが宣言的JSONを送信し、UIの「意図」を記述する（実装ではなく）。

{
  "type": "card",
  "children": [
    { "type": "text", "content": "レストラン発見" },
    { "type": "image", "src": "https://..." },
    { "type": "button", "label": "今すぐ予約", "action": "book" }
  ]
}

クライアントアプリケーションがこれらの抽象コンポーネントを独自のネイティブウィジェット（Reactコンポーネント、Flutter widget、SwiftUI view等）にマッピングする。

なぜこれが重要か

  1. セキュリティファースト：LLMからの実行可能コードなし。エージェントは事前承認されたカタログからのみコンポーネントをリクエスト可能
  2. LLMフレンドリー：IDリファレンス付きフラットなコンポーネントリスト——モデルがインクリメンタルに生成しやすい
  3. フレームワーク非依存：同一JSONペイロードがweb、モバイル、デスクトップでレンダリング可能
  4. インクリメンタル更新：エージェントがUI全体を再生成せずに特定コンポーネントだけ更新可能

アーキテクチャ：4ステップフロー

Agent (LLM) → A2UI JSON → トランスポート (A2A/AG UI) → クライアントRenderer → ネイティブUI
  1. 生成：エージェントがUIコンポーネントを記述するJSONペイロードを作成
  2. 転送：Google A2Aプロトコル、AG UI、または任意のトランスポートで送信
  3. 解決：クライアントのA2UI RendererがJSONをパース
  4. レンダリング：抽象コンポーネントをネイティブ実装にマッピング

実際のユースケース

理論ではない。A2UIはテキスト専用エージェントでは不可能なシナリオを実現する：

  • 動的フォーム：会話コンテキストに基づいて日付ピッカーやスライダー付き予約フォームを生成
  • リモートサブエージェント：旅行エージェントがオーケストレーターのチャットウィンドウ内にリッチUIカードを返す
  • アダプティブダッシュボード：エンタープライズエージェントが承認ワークフローやデータビジュアライゼーションをオンザフライで生成

Claude Code開発者への影響

Claude Codeで開発しているなら、A2UIは新しい可能性を開く：

Agent Teams + UI出力

Claude Code Agent Teamsで各エージェントがテキストだけでなくリッチUIコンポーネントを返せると想像してほしい。コードレビューエージェントがインタラクティブなdiffビューアを返す。デプロイエージェントがリアルタイムステータスダッシュボードを表示する。

MCP + A2UI統合

MCPサーバーは現在テキスト結果を返す。A2UIがあれば、MCPサーバーが構造化UIコンポーネントを返してクライアントがネイティブにレンダリングできる。カスタムMCPツールがチャート、フォーム、インタラクティブテーブルを表示可能に。

ターミナルを超えて

Claude Codeは現在ターミナルの中にいる。A2UIはエージェントがテキスト専用インターフェースを超えた先の標準を提供する——しかもオープン標準で、特定ベンダーにロックインされない。

競合状況

A2UIだけが選択肢ではない：

アプローチ利点欠点
A2UI（Google）セキュリティ優先、フレームワーク非依存、オープン標準初期段階（v0.8）、レンダラー限定的
AG UIリアルタイムストリーミング、React向けReactエコシステムに密結合
HTML/React直接生成最大の柔軟性セキュリティリスク、単一フレームワーク
Markdownユニバーサル、シンプルインタラクティブ性なし、レイアウト限定的

A2UIの賭けはセキュリティ + ポータビリティが最大の表現力より重要だということ。エンタープライズ市場を考えると、おそらく正しい方向性。

クイックスタート

git clone https://github.com/google/A2UI.git
cd A2UI
export GEMINI_API_KEY="your_key"

# レストラン検索デモを実行
cd samples/agent/adk/restaurant_finder
uv run .

現在サポート：

  • レンダラー：Lit（web）、Flutter（モバイル）
  • エージェントフレームワーク：Google ADK、LangGraph/Genkit対応予定
  • トランスポート：A2A Protocol、AG UI

我々の見解

A2UIは実際の問題を解決している。AIエージェントのターミナル専用時代は終わりつつある。エージェントがより強力になるにつれ（Claude Codeはすでにプロジェクト全体を自律管理可能）、人間とのよりリッチなコミュニケーション方法が必要。

問題はエージェントがUIを生成するかどうかではなく、どの標準が勝つか。Googleの優位性：

  • オープンソース（Apache 2.0）
  • フレームワーク中立
  • セキュリティファースト設計
  • 既存エコシステム（Flutter、Angular、Android）

不足点：Reactサポート（webの最も主流なフレームワーク）とより多くのエージェントフレームワーク統合。どちらもロードマップに含まれている。

結論：人間と対話するAIエージェントを開発しているなら、A2UIをブックマークしておこう。今日はv0.8だが、コアコンセプト——エージェントが安全な宣言的フォーマットでUIを「話す」——が未来だ。

出典：github.com/google/A2UI