これまでのAEO記事では、「AIに引用される（読まれる）側」から「AIに直接叩かれる（一次データソースになる）側」へと設計を進めてきました。MCPサーバーや構造化フィードを公開し、アシスタント内アプリとして配置し、比較テーブルに載り、売上まで計測する——ここまでで「AIから直接アクセスされる器」は整います。ですが、公開しただけでは呼ばれません。 AIエージェントは、同じ用途のツール・データソース・APIが複数あるとき、その中からどれを起動するかを毎回“選択”しています。引用される（被引用）の次に来る新しい主戦場は、選ばれて呼ばれる（被起動／invoked）の最適化です。本記事は、そのための設計と「被起動シェア（Invocation Share）」の測り方に集中します。
- この記事のポイント
- 1. はじめに——「載る・見つかる・売れる」の次に欠けていたピース
- 2. 前提——「被引用」「被アクセス」「被起動」を分けて整理する
- 3. なぜ今か——「呼ばれない公開MCP」が量産され始めた
- 4. AIエージェントはどうやってツールを選ぶのか
- 5. 最適化①——ツール説明文（description）の書き方
- 6. 最適化②——引数スキーマ（parameter schema）の明快さ
- 7. 最適化③——信頼シグナルと成功率（失敗率がルーティングに与える影響）
- 8. 「被起動シェア（Invocation Share）」の測り方
- 9. 実装チェックリスト
- 10. よくある質問（Q&A）
- 11. まとめ
- 12. 参考リンク（内部）
この記事のポイント
- AEOは「読まれる最適化」から「呼ばれる最適化（Agent Invocation Optimization）」へと拡張フェーズに入っている。
- AIエージェントはツール説明文・引数スキーマ・過去の成功率・信頼シグナル・コスト／レイテンシを見て、複数候補から起動先を選ぶ。
- 勝ち筋は「良いツールを公開する」ことではなく「LLMのツール選択に効く記述」と「失敗しない引数設計」で選択確率を上げること。
- 成果は感覚ではなく被起動シェア（自社エンドポイントが起動された割合）という指標で計測・改善する。
1. はじめに——「載る・見つかる・売れる」の次に欠けていたピース
AEO（Answer Engine Optimization）まわりの施策は、ここ半年で急速に具体化しました。振り返ると、それぞれが「AIの導線のどこに自社を置くか」という別々のレイヤーを埋めてきたことがわかります。
- エージェント検索対応：AIに「見つけてもらう」。
- 商品データフィード：AIの比較テーブルに「載る」。
- MCP／構造化フィードで直接叩かれる：自社を「一次データソース化」する。
- アシスタント内アプリ参入：AIの内側に自社を「配置」する。
- エージェンティックコマース計測：AI経由の「売上をアトリビューションする」。
これらはすべて「載る・見つかる・売れる」に関する施策です。しかし、間に一つ大きなピースが欠けていました。それが本記事のテーマ、「複数候補の中から、実際に選択され・起動される」という最適化です。器を用意し、見つけてもらい、載っても、“いざ実行する瞬間”に競合エンドポイントが選ばれてしまえば、被引用も被アクセスもゼロに帰します。呼ばれて初めて、これまでの投資が回収されます。
2. 前提——「被引用」「被アクセス」「被起動」を分けて整理する
まず言葉を整理します。AIから見た自社の“扱われ方”は、次の3段階に分けると設計しやすくなります。似ているようで、効くレバー（最適化の打ち手）と計測すべき指標がそれぞれ異なります。
| 段階 | 状態 | 効くレバー | 測る指標 |
|---|---|---|---|
| 被引用（Cited） | AIの回答文に読まれ・引用される | コンテンツの網羅性・構造化・鮮度 | 被引用回数／引用シェア |
| 被アクセス（Accessed） | MCP／API／フィードとして直接叩かれる器がある | エンドポイント公開・スキーマ整備・認証 | API呼び出し数／可用性 |
| 被起動（Invoked） | 複数候補の中から“選ばれて”実行される | ツール説明文・引数設計・成功率・信頼シグナル | 被起動シェア（Invocation Share） |
従来のSEO／AEOの主戦場は上2段（読まれる・叩ける状態を作る）でした。エージェントが自律的に道具を選ぶ時代に新しく立ち上がってきたのが、いちばん下の「被起動」です。ここは「④コスト記事」で触れた「AIがコストや成功率を見てツールを選ぶ」という話の、マーケティング側からの裏返しでもあります。コストを下げたい実行者側の関心と、選ばれたい提供者側の関心が、同じ“ツール選択”というテーブルで交差します。
3. なぜ今か——「呼ばれない公開MCP」が量産され始めた
直前のAEO記事（「引用される次は直接叩かれる」＝MCP／構造化フィードによる一次データソース化）と、アシスタント内アプリ参入の流れによって、企業は競ってMCPサーバーやツールAPIを公開し始めました。結果として、同じカテゴリ（在庫照会、価格取得、予約、ナレッジ検索など）に機能がほぼ同じツールが複数並ぶ状況が生まれています。
AIエージェントは、同種のツールが複数あるとき、すべてを叩くわけではありません。タスクに対して最も適切で・確実で・安価に見える一つ（または少数）を選んで起動します。つまり、公開した時点では“候補入り”しただけで、実際に呼ばれるかどうかは別問題。「作れば呼ばれる」時代は終わり、「選ばれるように作る・書く・測る」時代に入りました。これが「今」被起動最適化に取り組むべき理由です。
4. AIエージェントはどうやってツールを選ぶのか
被起動を最適化するには、まず選択の内部ロジックを理解する必要があります。LLMベースのエージェント（オーケストレーター）が複数のツール候補から一つを選ぶとき、判断材料になるのは概ね次の5つです。
4-1. ツール説明文（tool description）との意味的一致
LLMは、ユーザーの意図（タスク）と、各ツールに付与された説明文・名前・引数名との意味的な一致度を見て候補を絞ります。ここが被起動における「タイトルタグ＋メタディスクリプション」に相当する、最重要のレバーです。曖昧・冗長・専門用語だらけの説明文は、意図とマッチせず候補から外れます。
4-2. 引数スキーマ（argument schema）の充足しやすさ
LLMは「そのツールを今持っている情報で正しく呼べるか」も評価します。必須引数が多い、型が曖昧、何を入れるべきか説明がない——といったスキーマは、モデルが「呼んでも失敗しそう」と判断して回避します。呼びやすさ＝選ばれやすさです。
4-3. 過去の成功率・失敗率（ルーティングへの影響）
オーケストレーターやルーターの多くは、過去の実行結果を学習・参照します。エラー率が高い、タイムアウトする、空レスポンスを返す——こうした履歴を持つツールはルーティングで後回しにされます。一度「失敗するツール」と学習されると、被起動シェアは継続的に削られます。
4-4. 信頼シグナル（trust signals）
提供元の明示、認証・権限スコープの明快さ、レート制限やSLAの記載、公式性を示すメタデータ、監査可能なログの有無——こうした「安全に任せられる」根拠は、特に決済・書き込み・個人情報を伴うツールで選択に強く効きます。
4-5. コスト／レイテンシ
実行側は速さと安さも見ています。同等の結果なら速く・安いエンドポイントが選ばれやすい。ここは「④コスト記事」の実行者視点と表裏一体です。
| 選択要因 | 被起動への効き方 | 提供側の打ち手 |
|---|---|---|
| 説明文の意味的一致 | 候補入り・上位化の主因 | 意図語で書き直す（後述5章） |
| 引数スキーマの明快さ | 「呼べる／呼べない」の判定 | 必須を絞り型と例を明示（6章） |
| 成功率・失敗率 | ルーティングの重み付け | 失敗を減らし冪等化（7章） |
| 信頼シグナル | 高リスク操作での分岐点 | 提供元・権限・SLAを明記（7章） |
| コスト／レイテンシ | 同等時のタイブレーカー | 応答時間短縮・軽量応答 |
5. 最適化①——ツール説明文（description）の書き方
ツール説明文は、人間の読み手ではなく「ツールを選ぶLLM」に向けて書くマイクロコピーです。SEOのキーワードではなく、ユーザーがそのツールを必要とする“意図の言葉”で最適化します。
効く説明文の3原則
- 用途を冒頭で一文断言する。 「〜のとき、〜を返します」といういつ・何をの形。抽象的な機能名の羅列は避ける。
- 境界（使う／使わない条件）を書く。 「在庫の“現在庫数”を返す。価格改定履歴には使わない」のように適用範囲と非適用範囲を示すと、誤選択が減り“ちょうど良いとき”に選ばれる。
- ユーザーの語彙で書く。 内部用語ではなく、エンドユーザーが発話する言葉（意図語）に寄せる。名前・引数名も同様。
| 選ばれにくい例 | 選ばれやすい例 | |
|---|---|---|
| 説明文 | 「商品マスタ照会インターフェース。各種属性を取得。」 | 「商品名またはJANコードから、今この瞬間の在庫数と入荷予定日を返す。価格や過去履歴には使わない。」 |
| ツール名 | get_pm_data | check_stock_availability |
ポイント： 説明文は一度書いて終わりではありません。実際にどんなタスクで呼ばれた／外されたかをログで見て、意図語を継続的に反映していく“運用対象”として扱います（これはAEOで本文を鮮度更新する発想と同じです）。
6. 最適化②——引数スキーマ（parameter schema）の明快さ
どれだけ説明文が良くても、「呼びにくい」ツールは避けられます。LLMは、今持っている文脈で必須引数を埋められないと判断すると、そのツールを選択肢から落とします。スキーマ設計は被起動の“隠れた足切りライン”です。
呼ばれるスキーマの要件
- 必須引数は最小限に。 省略可能なものはデフォルトを持たせ、必須から外す。必須が多いほど「埋められず失敗する」リスクが上がり、回避される。
- 各引数に説明と例を付ける。 「date: 取得基準日（例: 2026-08-26、省略時は当日）」のように、意味・形式・例・省略時挙動を書く。
- 型と列挙を明確化する。 自由文字列よりenum（列挙）のほうが、モデルは正しい値を選びやすく、失敗が減る。
- エラーは“次の一手”を返す。 失敗時に「どの引数がどう不正か・どう直せばよいか」を機械可読で返すと、モデルがリトライで成功し、結果として成功率＝被起動シェアが上がる。
スキーマの明快さは、単なる開発品質ではなく「選ばれるためのマーケティング要素」だと捉え直すのが本記事の主張です。
7. 最適化③——信頼シグナルと成功率（失敗率がルーティングに与える影響）
説明文と引数で「候補入り」しても、高リスクな操作（書き込み・決済・個人情報）や、繰り返し使われる定番タスクでは、最後に信頼と実績で選ばれます。
7-1. 信頼シグナルを“メタデータとして”明記する
- 提供元の公式性（誰が運営し、どのドメインの一次情報か）。
- 権限スコープの明快さ（読み取り専用か、書き込みを伴うか）。
- レート制限・SLA・可用性の記載。
- 監査可能性（呼び出しがログに残り追跡できる）。
7-2. 失敗率は“複利で”被起動シェアを削る
ルーターが過去実績を参照する以上、失敗は一度きりの損失では終わりません。一度「失敗するツール」と学習されると、以後の候補評価で継続的に減点され、被起動シェアがじわじわ下がります。逆に、冪等性（同じ呼び出しを繰り返しても安全）・タイムアウトの短さ・空でない有用な応答を徹底すると、実績が積み上がって選ばれ続ける“正の複利”が働きます。
| 失敗パターン | ルーティングへの影響 | 対策 |
|---|---|---|
| タイムアウト多発 | レイテンシ評価で恒常的に後回し | 応答上限を設け部分結果を返す |
| 空／無効レスポンス | 「使えないツール」と学習 | 該当なしも構造化して明示的に返す |
| 引数エラーで頓挫 | 成功率低下→重み減 | 修正指示付きエラー＋リトライ設計 |
| 権限・認証で失敗 | 信頼シグナル毀損 | 必要スコープを事前に明記 |
8. 「被起動シェア（Invocation Share）」の測り方
被起動最適化は、感覚ではなく指標で回します。中心となるのが被起動シェア——同種タスクにおける全起動のうち、自社エンドポイントが起動された割合です。
被起動シェア ＝ 自社エンドポイントの起動回数 ÷ 同カテゴリの推定総起動回数（分母は自社観測＋業界推定で近似）
8-1. 取るべきログ（被起動ログの設計）
- 起動イベント：どのツールが・いつ・どのタスク文脈で呼ばれたか。
- 結果：成功／失敗、失敗理由、レイテンシ、応答サイズ。
- 選ばれなかった記録（可能なら）：候補に入ったが起動されなかったケース（説明文・引数改善の宝庫）。
- 呼び出し元：どのエージェント／アシスタント経由か（アトリビューションのため）。
8-2. 追う指標
| 指標 | 意味 | 改善が効くレバー |
|---|---|---|
| 被起動シェア | 選ばれている度合い | 説明文・引数・信頼シグナル総合 |
| 起動成功率 | 呼ばれて正しく返せた割合 | 引数スキーマ・冪等性 |
| 候補入り率 | 選択肢に載った割合 | 説明文の意味的一致 |
| 平均レイテンシ | 速さ（タイブレーカー） | 実装・応答軽量化 |
| 被起動→成果転換 | 起動が売上等につながった割合 | エージェンティックコマース計測と接続 |
計測基盤は、既存記事でも触れたOpenTelemetryなどの分散トレーシングと相性が良く、起動〜結果〜成果を一連のトレースとして追えると、施策の因果が見えやすくなります。
9. 実装チェックリスト
- ☐ ツール説明文を「いつ・何を返すか」の一文断言＋使う／使わない条件で書き直した。
- ☐ ツール名・引数名をユーザーの意図語に寄せた。
- ☐ 必須引数を最小化し、各引数に意味・形式・例・省略時挙動を記載した。
- ☐ 自由文字列を可能な限りenum化した。
- ☐ 失敗時に「修正の一手」を機械可読で返すようにした。
- ☐ 冪等性・タイムアウト上限・「該当なし」の構造化応答を実装した。
- ☐ 提供元・権限スコープ・SLA・監査可能性を信頼シグナルとして明記した。
- ☐ 被起動ログ（起動・結果・呼び出し元・可能なら非選択）を収集している。
- ☐ 被起動シェア／成功率／候補入り率をダッシュボードで定点観測している。
- ☐ 被起動を売上アトリビューション（エージェンティックコマース計測）と接続した。
10. よくある質問（Q&A）
Q1. SEOやAEO（被引用）対策がまだ途中でも、被起動最適化に着手すべき？
まずは「読まれる・叩ける器」（被引用・被アクセス）が前提です。ただしMCPやツールAPIをすでに公開しているなら、被起動最適化は今すぐ効果が出ます。公開済みなのに呼ばれていない場合、多くはコンテンツではなく説明文と引数スキーマが原因です。
Q2. 「被起動シェア」の分母（総起動回数）は正確に取れないのでは？
正確な全数は取れません。自社観測値を軸に、業界推定やサンプリングで近似します。重要なのは絶対値より時系列の変化——施策前後で自社シェアが上がったかを見れば、改善の当否は判断できます。
Q3. ツール説明文を“LLM向けに最適化”するのは、いわゆるプロンプトインジェクションと何が違う？
まったく別物です。被起動最適化は正確な用途と境界を明快に書くこと。モデルを騙して不適切に選ばせる記述（誇大・虚偽・命令の埋め込み）は信頼シグナルを毀損し、長期的にルーティングで不利になります。正直さが最も効くSEOだと考えてください。
Q4. 説明文を変えたら、本当に選ばれ方が変わる？
変わります。LLMのツール選択は説明文・引数名との意味的一致に強く依存するため、意図語への書き換えは候補入り率に直結します。A/Bで説明文を変えて被起動シェアを比較する運用が有効です。
Q5. 小規模事業者でも取り組む価値はある？
あります。大手が汎用ツールを並べる中、ニッチな用途を“ちょうど良く”言語化した説明文は、その用途では大手を上回って選ばれ得ます。被起動は総合力より用途適合で決まる場面が多く、専門特化ほど有利になり得ます。
11. まとめ
AEOは「読まれる最適化（被引用）」から「叩ける器づくり（被アクセス）」を経て、いま「呼ばれる最適化（被起動）」へと拡張しています。MCPサーバーやツールAPIが乱立する中、公開はスタート地点にすぎず、勝敗は“複数候補の中で選ばれ・起動されるか”で決まります。
効くレバーは、意図語で書いたツール説明文・呼びやすい引数スキーマ・高い成功率・明快な信頼シグナル。そして成果は被起動シェアという指標で計測し、ログを回して改善していく。「載る・見つかる・売れる」の間に欠けていた“選ばれて呼ばれる”を設計できたとき、これまでのAEO投資が初めてフルに回収されます。まずは公開済みツールの説明文と引数を、本記事のチェックリストで見直すところから始めてみてください。
12. 参考リンク（内部）
※以下は関連する自サイト記事です。公開URLに差し替えてご利用ください。
- 【関連】AEO：引用される次は“直接叩かれる”——MCP／構造化フィードで一次データソース化（URLを挿入）
- 【関連】アシスタント内アプリ参入——AIの内側への配置戦略（URLを挿入）
- 【関連】エージェント検索対応——AIに見つけてもらう設計（URLを挿入）
- 【関連】商品データフィード——AIの比較テーブルに載る（URLを挿入）
- 【関連】エージェンティックコマース計測——AI経由売上のアトリビューション（URLを挿入）
- 【関連】AIエージェントのコスト最適化——AIがツールを選ぶ仕組み（URLを挿入）
コメント