Guide

エージェント UX と人間参加型の設計: インターフェイスの作成。

明確な承認、プレビュー、可逆性、およびステータスのフィードバックを備えたエージェントの UX を設計して、ユーザーがアクションを監視できるようにします。

Updated April 12, 2026

エージェント応答設計により、インターフェイスは 2 つのユーザー (視覚的にナビゲートする人間のユーザーと構造的に分析する AI エージェント) に対して同時に機能します。最良の実装には、個別のインターフェイスは必要ありません。彼らは、クリーンなアーキテクチャを通じて両方に対応するシステムを構築しています。

ダブルオーディエンスの挑戦#

製品ページは、視覚的なデザイン、ブランドのストーリーテリング、感情的なトリガーによって人間の購入者を説得する必要があります。同じページで、構造化された仕様、正確な価格、明示的な在庫状況を AI エージェントに通知する必要があります。

これらは矛盾する目的ではなく、異なる目的です。間違いは、一方の視聴者に合わせて最適化し、もう一方の視聴者が満足していると仮定することです。

美しい画像と説得力のあるナラティブを備えたページでも、構造化データがなければ、人間にサービスを提供し、エージェントを排除します。プレーンな JSON エンドポイントを備え、視覚的なデザインがないページは、エージェントにサービスを提供し、人間を排除します。目標は、両方のレイヤーを含む統合されたページです。

ベースとしてのセマンティック HTML#

ほとんどの場合、エージェントは JavaScript でレンダリングされたコンテンツを無視します。これらは生の HTML を解析します。セマンティック要素 (ヘッダー階層、テーブル要素、リスト要素、フォーム要素、ボタン要素) は、エージェントが必要とする構造情報を提供します。

スタイル付き div の代わりにネイティブ HTML 要素を使用します。ボタン要素は、クリック可能なアクションが存在することをエージェントに伝えます。ボタンのように見えるように設計された div は、エージェントに何も伝えません。

要素の目的が内容から明らかでない場合は、aria-label 属性を追加します。ページを分析するエージェントは、スクリーン リーダーが使用するのと同じアクセシビリティの実践から恩恵を受けます。

サーバー上のすべての重要なコンテンツを処理します。製品名、価格、在庫状況に JavaScript を表示する必要がある場合、エージェントはそれらを表示できません。 エージェント Web サイト プログラミング ガイド には技術要件が記載されています。

##人間参加型の承認フロー

すべてのエージェントのアクションを自律的に完了する必要があるわけではありません。リスクの高い決定に関して人間による確認のために停止する承認フローを設計します。

承認フローには 3 つのコンポーネントがあります。エージェントがアクションを提案し (明確かつ構造化された言葉で人間に示されます)、人間が検討して承認または拒否し、システムが人間の決定に基づいて実行またはキャンセルします。

サイトのエンドポイントにとって、これは非同期ワークフローをサポートすることを意味します。エージェントが予約リクエストを送信します。システムはタスク ID を含む保留ステータスを返します。人間のレビュー。システムはステータスを確認済みまたは拒否に更新します。エージェントはタスク ID をポーリングし、最終ステータスを受け取ります。このパターンは、支出しきい値を超える購入の承認、法的文書の提出、アカウントの変更、および人間の判断の恩恵を受けるあらゆるアクションに機能します。

構造化されたフィードバック インターフェイス#

人間とエージェントの両方が問題を報告する必要があります。しかし、彼らは異なる報告をしています。

人間によるフィードバック: コメント ボックス、星による評価、サポート チケット。構造化されておらず、文脈が豊富なので解釈が必要です。

エージェント フィードバック: ページの URL、予期されるデータ、見つかった実際のデータ、およびエラー分類を受け入れる構造化されたエンドポイント。解釈は必要ありません。両方を構築します。ページ上の人間によるフィードバック フォームが表示されます。エージェントのフィードバック エンドポイントは、llms.txt とエージェント カードに文書化されています。どちらも、フィードバック ループ を通じて同じ改善プロセスを提供します。

ライブセッション用の WebSocket エンドポイント#

標準 REST API はステートレスな対話に機能します。マルチステップのエージェント ワークフローは、セッション状態を維持する WebSocket 接続の恩恵を受けます。

/ws/agent-session の WebSocket エンドポイントにより、エージェントは一連のアクション (製品の参照、選択の絞り込み、最適なオプションの入手可能性の確認、購入の完了) を通じてコン​​テキストを維持できます。各ステップは、共有状態の同じ接続上で発生します。

人間の場合: 同じ基盤となるセッション ロジックにより、異なるインターフェイスを介して同じビジネス ロジックを使用して、ブラウザー UI でガイド付きチェックアウト フローを駆動できます。

エレガントな劣化を実現するデザイン#

インターフェイスは、人間の完全なブラウザ エクスペリエンス (JavaScript、CSS、画像、インタラクション)、短縮されたブラウザ エクスペリエンス (接続が遅い、JavaScript なし)、エージェント エクスペリエンス (プレーン HTML、構造化データ、エンドポイント)、および基本的なエージェント エクスペリエンス (HTML テキスト コンテンツのみ) のすべての機能レベルで動作する必要があります。

各層は異なる顧客にサービスを提供します。 1 つのレイヤーを削除しても、その下のレイヤーが破壊されないように設計します。 JavaScript が失敗した場合でも、HTML には重要な情報が含まれているはずです。エンドポイントが機能しない場合でも、HTML は読み取れるはずです。

AEO 実装ガイド では、コンテンツ レイヤーの構造について説明しています。


よくある質問#

エージェントレスポンシブデザインとは何ですか? 単一のアーキテクチャを通じて人間のユーザーと AI エージェントの両方にサービスを提供するインターフェイス設計アプローチ。セマンティック HTML は、エージェントが読み取り可能なレイヤーを提供します。ビジュアルデザインは人間のレイヤーを提供します。どちらも同じ基礎データを共有します。

エージェント用に別のインターフェイスが必要ですか? 通常はそうではありません。セマンティック HTML、スキーマ マークアップ、文書化されたエンドポイントを備えた適切に構造化されたページは、両方の視聴者にサービスを提供します。個別のインターフェイスは、複雑なトランザクション ワークフローにのみ関連します。AEO のループにおける人間の役割は何ですか? 高リスクエージェントによる行為に対するセーフティネットを提供します。エージェントが提案し、人間が承認し、システムが実行されます。これにより信頼が構築され、完全自律システムにおけるコストのかかるミスが防止されます。

WebSocket エンドポイントはエージェントにどのように役立ちますか? これらは、複数ステップのワークフローでセッション状態を維持し、連続する REST 呼び出し間のコンテキストの損失を防ぎます。これは、購入フローや複雑なサービスのやり取りに特に役立ちます。

人間の UX とエージェントの UX のどちらを優先すべきですか? 両方です。出発点を選択する必要がある場合は、セマンティック HTML を使用した Human UX が両方の対象者を提供します。エージェント固有のエンドポイント (MCP、WebSocket) は段階的に追加できます。

主な参考文献#