AEO のエージェント ボタン、API、およびアクション スキーム。
エージェント ボタン、API、アクション スキーマが AI エージェントが完了するための安全な次のステップをどのように公開するかを学びます。
Updated April 12, 2026
エージェントが読めるコンテンツのページは役に立ちます。エージェントが操作できるコンテンツ ページは便利です。文書化されたエージェント ボタン、アクション スキーマ、および API エンドポイントが違いを生みます。これらは、静的なパブリッシング サーフェスを、自律システムが在庫状況を確認し、見積もりを要求し、予約を取り、購入を完了できるトランザクション インターフェイスに変換します。
エージェント ボタンとは実際には何ですか?#
エージェント ボタンは、人間がクリックするために設計された視覚的なボタンではありません。これは、エージェントに、この特定のタスクはここで実行でき、これらは必須の入力であり、これが呼び出すエンドポイントであることを伝える、明確に文書化されたアクションのパスです。
ページ上の視覚的なボタンは、人間の訪問者に役立ちます。基礎となるスキーマとエンドポイントのドキュメントはエージェントに役立ちます。どちらも同じビジネス プロセスを対象としていますが、異なるインターフェイスを使用します。
PotentialAction を使用したアクション スキームの実装#
Schema.org は、特にページ上で利用可能なアクションを記述するための PotentialAction タイプを提供します。これを使用して、エージェントに何ができるかを伝えます。
予約予約を含むサービス ページの場合、スキーマ構造には、アクション タイプ (ReserveAction または ScheduleAction)、宛先 URL (予約エンドポイント)、必須の入力プロパティ (日付、時刻、サービス タイプ、連絡先情報)、および結果タイプ (確認番号付きの予約) が含まれます。
ショッピング可能な商品ページの場合は、カートまたはチェックアウト エンドポイントを指すリンク先 URL を指定して BuyAction を使用し、数量とバリエーションの選択のプロパティ、および注文確認を説明する結果の種類を入力します。
見積もりリクエストの場合は、QuoteAction (またはわかりやすい名前の汎用アクション) を使用し、宛先 URL が見積もりのエンドポイントを指し、見積もりに必要な仕様のプロパティを入力します。
重要な原則: 各アクション スキームは、実際の機能的なエンドポイントに対応している必要があります。まだ存在しない機能のアクション スキームを追加しないでください。アクションを試みて失敗したエージェントは、サイトでの優先順位を失います。
API エンドポイントの構築#
アクション エンドポイントは、最初からエンタープライズ グレードの REST API である必要はありません。構造化された情報を受け入れ、ビジネス アクションを実行し、構造化された応答を返す必要があります。
最小限のエンドポイントは、必須フィールドを含む JSON ペイロードを受け入れ、入力を検証し、ビジネス プロセスをトリガーし (電子メールの送信、レコードの作成、外部 API の呼び出し)、ステータス、コミット ID、および次のステップを含む JSON 応答を返します。バックエンド開発リソースのないチームの場合は、n8n または Make.com Webhook エンドポイントがこのパターンを適切に処理します。 JSON を受け入れる Webhook を作成し、検証ステップを追加し、ビジネス ツール (カレンダー、CRM、電子メール) に接続し、構造化された応答を返します。
エージェント側のエンドポイントのセキュリティ要件: 予期されるタイプと範囲を持つすべての入力を検証します。乱用を防ぐための料金上限リクエスト。状態を変更するエンドポイントには認証が必要です。監査目的ですべてのリクエストをログに記録します。エージェントが何が問題だったのかを理解できるように、明確なエラー メッセージを返します。
ボタンをエンドポイントに接続する#
アクションが利用可能な各ページには、次の 3 つの内容を含めます。人間の訪問者に表示される行動喚起 (「在庫状況を確認する」や「見積もりを依頼する」などのクリア テキストのボタンまたはリンク)。
エンドポイント、入力、および予期される出力を説明するページ マークアップ内のアクション スキーマ。
正確な要求形式、必要なヘッダー、および応答構造を指定するエンドポイント ドキュメント (インラインまたはリンク)。
この 3 層により、人間とエージェントの両方がそれぞれのインターフェイスを通じてアクションを見つけて使用できるようになります。
セキュリティのベスト プラクティス#
認証なしで書き込み可能なエンドポイントを決して公開しないでください。単純な Webhook エンドポイントでも、リクエスト ヘッダーに API キーまたはトークンが必要です。
不正なリクエストがビジネス ロジックに到達する前に拒否する入力検証を実装します。無効な日付形式を送信したエージェントは、システム クラッシュではなく、明確なエラーを受け取る必要があります。
状態を作成または変更するアクションには冪等キーを使用します。同じリクエストが 2 回到着した場合 (エージェントの再試行でよくあること)、2 番目のリクエストは重複した予約や注文を作成せずに同じ結果を返す必要があります。
エージェントとのやり取りをすべて記録します。タイムスタンプ、リクエスト ペイロード、レスポンス ペイロード、およびソース エージェント識別子。これは、時間の経過とともに精度を向上させる フィードバック ループ にとって不可欠です。
ユニバーサル コントロール プレーンの記事 では、エージェント側エンドポイントの完全なガバナンス アーキテクチャについて説明しています。
##エージェントのトランザクションをテストする
運用を開始する前に、次のチェックを使用して各エンドポイントをテストします。
ページ上のアクション概要からエンドポイントを検出できますか?エージェントと同じようにページを分析し、スキーマが機能する URL を指していることを確認します。
エンドポイントは文書化された入力形式を受け入れ、文書化された出力形式を返しますか?有効なリクエストを送信し、レスポンスがスキーマの説明と一致することを確認します。エンドポイントは無効な入力を正しく処理しますか?不正な形式のリクエストを送信し、エラー応答が構造化されており、有益であることを確認します。
エンドポイントは重複したリクエストを安全に処理しますか?同じ有効なリクエストを 2 回送信し、重複したアクションが作成されないことを確認します。
エンドポイントは許容可能な遅延内で応答していますか?通常、エージェントは 10 ～ 30 秒後に期限切れになります。エンドポイントはそのウィンドウ内で適切に応答するはずです。
よくある質問#
エージェントのボタンは人間の顔のボタンに代わるものですか? いいえ、それらは共存しています。視覚的なボタンは人間の訪問者に対応します。アクション スキームとエンドポイントはエージェントにサービスを提供します。どちらも同じビジネス プロセスをトリガーします。
Schema.org の PotentialAction とは何ですか? ページ上で利用可能なアクションを説明するアウトラインの一種。これには、アクションのタイプ、宛先 URL、必要な入力、および予期される結果が含まれます。エージェントはこれを使用して、サイトで何ができるかを調べます。
エージェント側のエンドポイントを保護するにはどうすればよいですか? 認証 (API キーまたはトークン) を要求し、すべての入力を検証し、レート制限を実装し、状態変更アクションに冪等キーを使用し、すべてのリクエストをログに記録します。エージェント エンドポイントにノーコード ツールを使用できますか? はい。 n8n と Make.com は、構造化された JSON を受け入れ、ビジネス ロジックを実行し、構造化された応答を返す Webhook エンドポイントをサポートします。これらは、最も基本的なエージェントのトランザクション パターンを処理します。
私のアクション概要に一時的に利用できない機能が記載されている場合はどうなりますか? サービスが利用できないことと、サービスがいつ再開される予定かを説明する、明確で構造化されたエラー応答を返します。機能が存在しなくなったページに壊れたアクション スキームを残さないでください。