目次
2億ドルの盲点
この18ヶ月で、AI時代の新しいマーケティングツール群が驚異的な資金を集めた。Profoundは1.55億ドルを調達し、10億ドル（ユニコーン）の評価を受けた。Peec AIは2,100万ドルを調達し、16ヶ月で400万ドルのARRを達成した。Bluefishは4,300万ドルのシリーズBをクローズ。Semrush、Ahrefs、BrightEdgeがこぞってAEOモジュールを追加した。Gartnerは2026年3月に「Answer Engine Visibility Tools」を正式カテゴリとして認定した。
これらのツールが解決する問題はすべて同じだ：「人間がChatGPTやPerplexityに質問したとき、自社ブランドが言及されるか」の追跡。
価値のある取り組みだが、方程式の片側しか解いていない。
もう一つ、はるかに大きく、完全に追跡されていない現象が進行している：AIエージェントが自律的にSaaSを発見・選択・利用している。人間がチャットボットに質問するのではなく、エージェントが自分でツールを探し、評価し、実行する。開発者がClaude Codeに「freeeで請求書を作成して」と伝えれば、エージェントはChatGPTに相談しない。利用可能なMCPサーバーを検索し、最適なものを選び、APIを叩く。
このプロセスを追跡するAEOツールは、ゼロだ。
AI可視性の2つの側面
（チャットボット言及追跡）
（ツール選択追跡）
（エージェントの検索対象）
（エージェントが接続中）
AEOとは何か——60秒で理解する
AEO（Answer Engine Optimization）は、2024〜2025年に生まれた概念だ。人々がGoogleにキーワードを打つ代わりに、ChatGPTやPerplexityに自然言語で質問するようになった。「10人チームに最適なCRMは？」と聞けば、AIが直接答える。その回答に名前が出るブランドがトラフィックを獲得する。
AEOツールはこれを追跡する。ChatGPT、Perplexity、Gemini、Google AI OverviewsにおけるブランドのAI検索での可視性を見ている。
主要プレイヤー：
- Profound — 評価額$1B、11のAI面を追跡、Walmart・Figma等700+社が利用
- Peec AI — EU拠点、1,300+社、115言語対応、感情分析
- Semrush / Ahrefs — 既存SEOプラットフォームにAEOモジュールを追加
- Conductor — 2026年4月にAgentStackをローンチ、「AEOのシステム・オブ・レコード」を標榜
これらのツールの前提は共通している：検索しているのは「人間」である、ということだ。
エージェントAEO——誰も追跡していないレイヤー
エージェントAEOとは、AIエージェントが自律的にタスクを実行する際に、自社のSaaSやAPIを発見・選択・利用してもらうための最適化手法である。
人間がChatGPTに「おすすめの会計ソフトは？」と聞く——これは質問だ。LLMがトレーニングデータとウェブ検索から回答を生成する。従来のAEOが追跡する対象。
AIエージェントが「会計データをスプレッドシートに同期して」という指示を受ける——これはタスクだ。エージェントはツールを探し、認証し、APIを叩き、結果を返す。質問と回答のやりとりではなく、ツール選択と実行のパイプラインだ。エージェントは利用可能なMCPサーバーを検索し、説明文と機能を評価し、最適なものを選び、呼び出す。
この2つは根本的に異なるプロセスだ。
人間AEOとエージェントAEOの決定的な違い
| 人間AEO | エージェントAEO | |
|---|---|---|
| 検索の主体 | 人間が質問を入力 | AIエージェントがタスクを実行 |
| 検索メカニズム | LLMの知識 + ウェブ検索 | MCP Tool Search（意味的マッチング） |
| 評価対象 | ウェブコンテンツ、引用、ブランド言及 | MCPサーバー名、説明文、ツールスキーマ |
| 成功指標 | AIの回答にブランドが登場 | サービスが発見・選択・タスク完了 |
| 失敗モード | ブランドが引用されない（監視可能） | サービスが発見されない（完全に不可視） |
| 収益への影響 | ブランド認知、間接的トラフィック | 直接的な利用、API呼び出し、タスク完了 |
| 担当部門 | マーケティング | プロダクト / エンジニアリング |
人間AEOは「名前を出す」ための最適化。エージェントAEOは「実際に使われる」ための最適化。ChatGPTの回答で1位に言及されていても、MCPサーバーの発見性が低ければ、エージェントからの選択率は0%になりうる。
なぜ「今」なのか——MCPエコシステムの規模
MCP（Model Context Protocol）は、Anthropicが2024年後半に開発し、2025年12月にLinux FoundationのAgentic AI Foundationに移管したプロトコルだ。AIエージェントと外部サービスをつなぐ標準インターフェースとして急速に普及した。
2026年半ば時点の規模：
- 73,500+ MCPサーバーが各ディレクトリに登録（MCP Toplistの集計：Official Registry、Glama、Smithery、mcp.so、PulseMCP）
- 月間9,700万+ SDKダウンロード——エージェントは日々接続している
- 月間62.2万+検索——上位50 MCPサーバーだけで（Ahrefs、2026年3月）
- 日本は世界第2位の検索市場（PulseMCP統計）
現在、3つの新しい標準がエージェントのサービス発見方法を形作りつつある：
- llms.txt — ウェブサイトのルートに置く、AIモデル向けのサービス説明ファイル（robots.txtのAI版）
- MCP Server Card（mcp.json） — MCPサーバーの機械可読メタデータ（ワーキンググループで策定中）
- Google ARD（Agentic Resource Discovery） — Googleが提唱するエージェント向けAPI発見プロトコル
この3つを統合的に解説するガイドは、日本語でも英語でも、まだ存在しない。
見えない失敗：search_miss
KanseiLinkはsearch_missというエラー分類を追跡している。AIエージェントがサービスを検索したにもかかわらず、対象サービスが検索結果に表示されない失敗のことだ。
これが起きる理由は、エージェントがブランド名ではなく意図（「請求書を送りたい」「カレンダーを同期したい」）で検索するからだ。MCPサーバーの説明文がエージェントの意図パターンと一致しなければ、そのサービスは単純に「見つからない」。APIがどれだけ優れていても関係ない。
search_missはサーバーログに記録されない。エラーアラートを発火しない。APIアナリティクスのダッシュボードにも表示されない。サービス提供者の視点からは、エージェントが「ただ来なかった」ように見える。探して見つからなかったのか、そもそも探さなかったのかの区別がつかない。エージェントの検索行動を追跡する中間レイヤーなしには、この機会損失は永久に不可視のままだ。
search_missの原因は主に3つ：
- 名前の不一致 — MCPサーバーがブランド名（「Acme MCP」）で登録されており、機能（「請求書管理」）で見つからない
- 説明文のギャップ — ツール説明が社内用語で書かれ、エージェントの意図クエリと意味的に一致しない
- カテゴリの混乱 — サービスが本来の機能とは別のカテゴリに配置され、エージェントの検索範囲から外れる
複数のAI検索面への対応が必要な理由
従来のSEOはGoogle一択で良かった。しかしAI時代では、「人間向けAI検索」と「エージェント向けツール検索」の両方が、それぞれ複数の面に分かれている。
人間がAIに質問する面（人間AEO）
- Google — AI Overviews / AI Mode（Geminiベース）
- Bing — Copilot（OpenAI GPTベース）
- Perplexity — 独自エンジン（Claude、GPT等を併用）
- ChatGPT Search — OpenAI独自の検索
- DuckDuckGo — AI Answers
エージェントがツールを検索する面（エージェントAEO）
- Claude（Anthropic） — Tool Search（MCPサーバーの意味的マッチング）
- OpenAI Agents SDK — 独自のツール発見メカニズム
- Google Gemini — ARD（Agentic Resource Discovery）
- Cursor / Windsurf / VS Code — IDE統合MCP
- 各種MCPディレクトリ — Smithery、Glama、Official Registry
人間AEOではGoogleが圧倒的だが、エージェントAEOでは面が分散している。ClaudeのTool Search、OpenAIのAgent SDK、GoogleのARDは、それぞれ異なるメカニズムでサービスを発見する。すべての面で発見されるためには、構造化データ（JSON-LD）、FAQ schema、llms.txt、mcp.json、OpenAPIスペックを横断的に整備する必要がある。
JSON-LDのFAQPage schemaはGoogle AI OverviewsとBing Copilotの両方でリッチリザルトを生成する。質問形式のH2/H3はPerplexityとChatGPT Searchが引用しやすい。llms.txtはAIモデル全般の理解を助ける。これらを組み合わせることで、一つのコンテンツが複数のAI面で可視性を持つ。
競合マップ：誰が何をカバーしているか
AI可視性の市場は急速に成長しているが、各プレイヤーがカバーする領域は明確に異なる。
| レイヤー | 追跡対象 | 主要プレイヤー |
|---|---|---|
| 人間AEO | 「ChatGPTで自社名が出るか」 | Profound（$1B）、Peec AI、Semrush、Ahrefs、Conductor、BrightEdge、Otterly |
| MCPディレクトリ | 「MCPサーバーの一覧提供」 | Official Registry、Smithery、Glama、PulseMCP、mcp.so |
| MCP内部監視 | 「自社MCPサーバーは正常か」 | MCPcat（セッションリプレイ）、Speakeasy（ゲートウェイ）、Tinybird |
| MCPベンチマーク | 「標準テストでのスコア」 | mcpbr.org（SWE-bench等25+評価）、Microsoft MCP Interviewer |
| エージェントセッション観測 | 「エージェントが使った後の体験」 | Armature（YC S26、$79-159/月） |
| エージェントAEO | 「エージェントが自社を見つけて使えるか」 | KanseiLink |
各レイヤーは実在するニーズに対応している。しかし、SaaS企業にとって最も重要な問いーー「エージェントがウチのサービスを必要としたとき、見つけてくれるか、選んでくれるか、成功するか」ーーに答えるツールは、これまで存在しなかった。
日本市場の特殊性と機会
日本のSaaS企業にとって、エージェントAEOは特に重要な意味を持つ。
日本語MCP記事は完全な空白
英語圏では「Best MCP Servers for CRM」「Best MCP Servers for Accounting」といったカテゴリ別比較記事が多数存在する。しかし、日本語で業種別のMCP対応SaaSを比較する記事は、全カテゴリにおいてゼロだ。会計（freee vs マネーフォワード）、HR（SmartHR）、CRM、プロジェクト管理——すべてのカテゴリで未開拓。
日本は世界第2位のMCP検索市場
PulseMCPの統計によれば、MCP関連キーワードの検索ボリュームで日本は世界第2位。Zennの記事「日本のSaaS 100社のMCP・API対応状況」がオーガニック検索でランクインしている事実は、データ原著コンテンツが薄いリスト記事に勝てることを証明している。
日本のSaaSが続々MCP対応
- freee — 公式MCPサーバー提供、KanseiLink AEOグレードA
- マネーフォワードクラウド会計 — 2026年3月にリモートMCPサーバーを公開、全プラン対応
- kintone — Cybozu公式MCPサーバー
- SmartHR — MCP接続可能（認証周りに課題あり）
これらのサービスが「エージェントに選ばれる」ためには、MCPサーバーの存在だけでは不十分だ。エージェントの検索パターンに合った名前・説明文・ツールスキーマが必要になる。これがエージェントAEOの実務だ。
エージェントAEOを始める5つのステップ
ステップ1：MCPサーバーの発見性を監査する
自社MCPサーバーの名前と説明文を見直す。エージェントは「Acme MCP」ではなく「請求書を送りたい」で検索する。動詞ベースの機能記述（「請求書の作成・送付・管理ができる」）にすることで、意図ベースの検索でヒットしやすくなる。
ステップ2：ツールスキーマの説明文を最適化する
MCPサーバーが公開する各ツールにはdescriptionフィールドがある。エージェントはこの説明文を読んでツールを呼ぶかどうかを判断する。社内用語ではなく、ユーザーがタスクを依頼するときの自然な言葉で記述する。
ステップ3：新しい発見性標準を実装する
- ドメインルートにllms.txtを配置（AIモデルが自社サービスを理解するための情報源）
- MCP Server Card（mcp.json）の動向を注視し、策定後すぐに対応
- APIを公開している場合はGoogle ARDへの対応を検討
ステップ4：エージェント側の指標を監視する
内部監視ツール（MCPcat等）はサーバーに到達したリクエストを見る。エージェントAEO分析は、到達しなかったリクエスト——search_miss、選択の意思決定、競合に流れた理由——を見る。KanseiLinkで自社のAEOグレードを確認し、11,000+サービスの中での位置を知る。
ステップ5：利用結果をレポートする
エージェントAEOのデータ層は、エージェントからのフィードバックで構築される。KanseiLinkのreportツールで成功・失敗を記録することで、search_missを可視化するデータが蓄積される。
よくある質問
エージェントAEOは従来のAEOを置き換えますか？
いいえ。人間AEOとエージェントAEOは異なる現象を追跡する。人間AEOはAI生成回答でのブランド可視性を測り、エージェントAEOはエージェントのツール選択での発見性を測る。完全なAI可視性戦略には両方が必要だ——SEO（オーガニック検索）とASO（アプリストア最適化）の両方が必要なのと同じだ。
KanseiLinkとMCPcatの違いは何ですか？
MCPcatはMCPサーバー運営者向けの内部監視ツール（セッションリプレイ、エラートラッキング等）。KanseiLinkはその外部レイヤーを追跡する——エージェントがそもそもサービスを発見できるか、どの競合を代わりに選んだか、どの検索パターンでsearch_missが発生するか。MCPcatは「発見された後」を見る。KanseiLinkは「発見されるかどうか」を見る。
「APIのSEO」ということですか？
概念的にはそうだ——AEOが「AIチャット検索のSEO」であるのと同じ意味で。ただしメカニズム（意味的ツールマッチング vs キーワードランキング）、最適化対象（MCPスキーマと説明文 vs ウェブコンテンツ）、データソース（エージェント行動データ vs 検索エンジンデータ）はすべて異なる。戦略の問いは同じだ：必要としている相手が探しているとき、見つけてもらえるか？
小規模なSaaS企業でもエージェントAEOは意味がありますか？
むしろ小規模企業こそ重要。エージェントは人間のように「大手だから選ぶ」ということをしない。MCPサーバーの説明文が意図に一致すれば、ブランド認知度ゼロのサービスでも選ばれる。これは従来のマーケティングでは不可能だった——エージェントAEOは、良いプロダクトが正しく記述されていれば発見される、フェアな競争環境を提供する。