Column

🧩 ActionCardから始まった悩み

個人ポートフォリオサイトを制作する中で、私はまず ActionCard という概念を定義しました。
チャットボットベースのUIを構成していくうちに、自然と次のような疑問が生まれたからです。

会話がある程度進んだ後も、
ユーザーに対してただ「何でも入力してください」と委ね続けるよりも、
その時点で必要な行動を明確に示すUIが必要なのではないかと感じました。

特に、連絡するかどうかの判断のように、

選択肢が明確で
その結果が以降の流れを左右する場面では

自由入力がかえってUXを曖昧にしてしまうと考えました。

そこで、そのタイミングから Guided UX へ切り替え、
入力欄の代わりに、ボタンや明示的なアクションを含むActionCardを表示する設計にしました。

💡 ActionCardは「ボタンUI」ではなく状態の表現でした

ActionCardは、単にボタンを並べたコンポーネントではありません。
私が意図していたのは、次のような状態の可視化でした。

「今この会話は、ユーザーの明示的な行動を必要としている状態である」

そのため、ActionCardは常に：

会話フローの 特定のタイミングでのみ表示 され
通常のメッセージと 明確に区別されたUI であり
ユーザーの選択が その後のAIの応答フローに直接影響する構造 を持っていました。

この考え方は個人的に、
Apple Siriの対話型UX から多くの影響を受けています。
自然に会話を進めつつ、重要な瞬間には選択肢を明確に提示するアプローチです。

当時は、これを体系的な概念として整理していたわけではありません。
UXに違和感を覚え、早急に解決する必要があったために選択した、
実務的な実装に近いものでした。

🤖 そして知ったA2UI

その後、Googleが提唱した A2UI（Agent-to-UI） という概念に触れ、
自分が作ってきたフローと構造的に共通する点が多いことに気づきました。

A2UIを一文で表すと、次のように説明できます。

Agent（LLM）が現在の状態や必要なアクションを宣言し、
UIはその宣言を解釈せず、そのまま表現する。

この概念の本質は、
UIがもはや「判断の主体」ではなく、「表現の主体」へと役割が移る点 にあります。

🤖 A2UIとは？

A2UIは単に「AIがUIを作ってくれる」という意味ではありません。
本質は 役割分担 にあります。

役割	責任
Agent（LLM）	状態判断、次のアクション決定
UI	宣言された状態をそのままレンダリング
Server	権限検証、実行制御

従来のUIと比較すると、その違いは明確です。

区分	従来のUI	A2UI
状態判断	フロントエンドロジック	Agent
UI分岐	if / switch	宣言（JSON）
UIの責務	表示 + 判断	表示のみ
拡張方法	コンポーネント追加	スキーマ拡張

振り返ってみると、
ActionCardも意図したわけではありませんが、
この構造に近い方向で実装されていました。

🔁 ActionCardとA2UIが似ていた点

1️⃣ UIが判断しない構造

if (answerType === "promptTextMessage") {
  return <ActionCard />
}

フロントエンドは
「なぜこのUIが必要なのか」を知りません。
Agentが渡した状態を そのまま表現 するだけです。

これはA2UIの中核となる原則と一致します。

判断はAgentが行い、UIは表現に徹する。

2️⃣ ActionCardはコンポーネントではなく「状態」

ActionCardは、
ユーザーの行動が必要な状態を可視化した結果 でした。

そのため：

常に特定のタイミングでのみ表示され
その状態が終われば再び表示されることはありません

この考え方は、A2UIの State-driven UI と通じています。

3️⃣ ユーザーの行動が再びAgentへ戻る構造

metaMessage = {
  type: "ACTION_RESULT",
  action: "SEND_MESSAGE",
  result: "CONFIRMED",
};

ユーザーの選択は再びLLMのコンテキストに渡され、
次のUI状態を決定する入力として利用されます。

この流れが Agent-driven feedback loop です。

🔐 宣言的UIとNext.js RSCのセキュリティ脆弱性が示す考慮点

A2UIは本質的に 宣言的UI パターンの上に成り立っています。
この構造はUIを単純化する一方で、
状態判断・アクション決定・権限検証といった責任を
サーバーやAgentといった、ユーザーから見えない領域へ移動させます。
その結果、バックグラウンドで処理されるロジックが増えるほど、Attack Surfaceも拡大します。

この点を理解する上で、
最近の Next.js RSC（React Server Components）のセキュリティ脆弱性問題 は良い参考例です。
RSCも宣言的にサーバー側でUIを構成する仕組みであり、
その過程でサーバー実行経路の露出や、
ユーザー入力がサーバーロジックへ影響を与えるリスクが実際に顕在化しました。

重要なのは、これは特定のフレームワークの欠陥ではなく、
宣言的UI＋サーバー中心実行構造が共通して抱えるリスク を示している点です。
A2UIもまた、Agentが宣言したUI状態やアクションを信頼して処理する構造である以上、
検証を怠れば同様のセキュリティリスクを内包します。

そのためA2UIは、
「少しセキュリティに気をつければよい技術」ではなく、
セキュリティを設計前提にしなければ成立しにくい構造 と言えます。
UXを単純化する分、
どの宣言を信頼するのか、どの実行をサーバーが制御するのかを、
最初から明確に分離して設計する必要があります。

1️⃣ UI宣言は必ずホワイトリストで検証する

const ALLOWED_TYPES = [
  "plainMarkdown",
  "promptTextMessage",
  "confirmSendTextMessage",
] as const;

function validate(type: string) {
  if (!ALLOWED_TYPES.includes(type as any)) {
    throw new Error("Invalid UI schema");
  }
}

👉 LLMの出力は 常に疑い、検証する 必要があります。

2️⃣ アクションの実行権限はサーバーが持つべき

// UIはリクエストのみ
POST /api/action

// サーバー側で状態と権限を検証
if (!session.user || !isValidState(ctx)) {
  return res.status(403).end();
}

👉 ボタンはトリガーに過ぎず、最終的な判断はサーバー が行います。

3️⃣ LLMコンテキストに渡す情報は構造化する

metaMessage = {
  type: "ACTION_RESULT",
  action: "CONFIRM",
  result: true,
};

👉 文字列よりも 構造化されたメタ情報 の方が安全です。

4️⃣ A2UIは宣言的SSRであることを認識する

const COMPONENT_MAP = {
  ActionCard,
  MarkdownView,
} as const;

const Component = COMPONENT_MAP[schema.type];

👉 動的実行は避け、明示的なマッピングのみを許可 します。

🚀 最終的な主張の整理

1️⃣ ユーザーインタラクションを必要とするUIの未来は、A2UIに近づいていく可能性が高い。
テキスト入力中心のUIを超え、音声や環境ベースのインタラクションへと拡張していきます。

2️⃣ 開発者は画面を設計する際、
A2UIが導入される可能性を前提に構造を設計すべきです。
今は使わなくても、将来的に導入できない構造は避ける必要があります。

3️⃣ A2UIは生産性を大きく高めますが、
セキュリティを設計に含めなければ、その分リスクも増大します。

🧾 一文でまとめると

A2UIはユーザーインタラクションの未来になり得る一方で、
開発者にはその可能性を前提とした構造設計とセキュリティへの配慮が同時に求められます。

A2UIが描くUXの未来と、Next.jsが示したセキュリティの現実