エージェンティック・エンジン最適化（AEO）

• AIコーディングエージェントのドキュメント消費方法は人間と根本的に異なるため、人間中心の最適化だけでは、ますます多くのAIトラフィックが分析ツールに捕捉されないまま消えていく
• エージェントはドキュメントを単一のHTTPリクエストで取得し、トークン数を数え、コンテキストウィンドウに収まらなければ静かに破棄するため、スクロール深度・滞在時間・クリックといった従来の分析指標はまったく記録されない
• これに対応するため、ドキュメントをエージェントが実際に使えるよう構造化・フォーマット・提供する**Agentic Engine Optimization（AEO）**という概念が提示されている
• AEOの中核は発見可能性、パースのしやすさ、トークン効率、機能シグナリング、アクセス制御であり、このうち1つでも失敗するとエージェントはコンテンツをスキップするか誤った出力を生成する
• 早期に対応するチームは自社APIがエージェントによって推奨・統合される優位性を確保でき、エージェント向けのドキュメント整備は結果として人間の読者にとってもより良い文書を生み出す

---

AEOとは何か

• **Agentic Engine Optimization（AEO）**は、AIコーディングエージェントが実際に活用できるように技術コンテンツを構造化・フォーマット・提供する実践手法
• SEOが検索クローラーと人間のクリックパターンに合わせた最適化だったとすれば、AEOは自律的にコンテンツを取得し、パースし、推論するAIエージェントという新たな消費者を対象にしている
• 主な考慮要素
  • Discoverability – JavaScriptレンダリングなしでエージェントがドキュメントを見つけられるか
  • Parsability – 視覚的なレイアウト解釈なしで機械可読か
  • Token efficiency – 一般的なエージェントのコンテキストウィンドウに切り詰めなしで収まるか
  • Capability signaling – APIが「どう呼び出すか」ではなく「何をするか」を伝えているか
  • Access control – robots.txtがAIトラフィックを実際に許可しているか

エージェントがドキュメントを読む方法

• 人間のパターン: ドキュメントのホームに到着し、セクションを移動し、見出しを流し読みし、コードサンプルを実行し、内部リンクを2〜3個たどり、セッションごとに4〜8分滞在 → 分析ツールがすべて記録
• エージェントのパターン: Claude Code、Cursor、Cline、Aider、VS Code、Junieなど9つの主要コーディングエージェントのHTTPトラフィックを分析した論文によると、複数ページの探索が1〜2件のHTTPリクエストに圧縮される
  • 単一のGETリクエストでページ全体を受信して移動し、「user journey」の概念がサーバーサイドの単一イベントへと崩壊する
  • スクロール深度、滞在時間、ボタンクリック、チュートリアル完了、リンク遷移、フォーム操作などクライアントサイドのイベント全体が不可視化される

AIトラフィックのフィンガープリント

• サーバーログでエージェントトラフィックを識別できる固有シグネチャが存在する
  • Aider: Headless Chromium（Playwright）、On-demand GET、Mozilla/Safariフルuser-agent
  • Claude Code: Node.js/Axios、On-demand GET、axios/1.8.4
  • Cline: curl、GET + OpenAPI/Swaggerスイープ、curl/8.4.0
  • Cursor: Node.js/got、HEAD probe → GET、got (sindresorhus/got)
  • Junie: curl、順次マルチページGET、curl/8.4.0
  • OpenCode: Headless Chromium（Playwright）、On-demand GET
  • VS Code: Electron/Chromium、Electronマーカーを含むChromiumスタイル
  • Windsurf: Go/Colly、colly
• コーディングエージェント以外にも、ChatGPT、Claude、Google Gemini、PerplexityのようなAIアシスタントWebサービスも、ユーザーがURLを共有するとサーバーサイドfetchを発生させ、固有のフィンガープリントを生成する

トークン問題: ドキュメントがエージェントに見えない可能性がある

• エージェントの多くは実質的に100K〜200Kトークンの上限を持ち、コンテキスト管理はあらゆる作業で有効な制約となる
• 論文の事例: Cisco Secure Firewall Management Center REST API Quick Start Guide（Version 10.0）は193,217トークン、約718,000文字で、単一ドキュメントだけで大半のエージェントの利用可能なコンテキストウィンドウを使い切るか超過する
• ドキュメントが長すぎる場合に起こり得ること
  • 静かな切り詰めによる重要情報の損失
  • より短いドキュメントを優先して当該ドキュメントをスキップする
  • チャンク化の試行で遅延やエラーの発生面が増える
  • パラメトリック知識へのフォールバック — つまり幻覚の生成
• 結論: トークン数は今やドキュメントの第一級の指標であり、ページ単位でのトークン追跡が必須

実用的なトークン目標

• Quick start / getting startedページ: 15,000トークン未満
• 個別のAPIリファレンスページ: 25,000トークン未満
• APIリファレンス全体: 製品単位ではなくリソース/エンドポイント単位でチャンク化
• 概念ガイド: 20,000トークン未満、詳細は埋め込みではなくリンクで接続

AEOスタック: 実際に構築すべきもの

• AEOは単一の手法ではなく、基礎から表層まで層をなすシグナルと標準の集合

Layer 1: アクセス制御（robots.txt）

• 多くのエージェントはコンテンツ取得前にrobots.txtを先に確認するため、設定を誤るとエラーなしで静かにドキュメントアクセスが遮断される
• 実行ステップ
  • AIエージェントuser-agentに対する意図しないブロックを監査
  • Anthropic、OpenAI、Google、Perplexityクローラーなど既知のパターンへの明示的な許可を検討
  • より細かな制御が必要ならagent-permissions.json（自動インタラクションの許容範囲、rate limit、推奨APIエンドポイントなどを宣言する新興仕様）を活用

Layer 2: 発見のためのllms.txt

• yourdomain.com/llms.txtでホストされるMarkdown形式のプレーンファイルで、AIエージェント向けサイトマップの役割を持つ
• 構造化されたドキュメントディレクトリと説明を提供し、エージェントがサイト全体をクロールしなくても関連コンテンツを把握できる
• 例の構成: Getting Started（Quick Start Guide、Authentication、Core Concepts）、API Reference（REST API Overview、Users API 12Kトークン、Events API 8Kトークン）、MCP Integration（MCP Server）
• 良いllms.txtの特徴
  • ページ名ではなく何が見つかるかを伝える説明
  • 有用な場合はページごとのトークン数を含める
  • 製品階層ではなくタスク単位の構成
  • 自身のサイズを5,000トークン未満に保つ（インデックスが予算超過してはならない）

Layer 3: skill.mdによる機能シグナリング

• llms.txtが「どこにあるか」を伝えるなら、skill.mdは製品が「何ができるか」を伝える
• エージェントが散文ドキュメントから機能を推測する必要がないよう、意図（intention）をエンドポイントやリソースへ宣言的にマッピングする
• 認証サービスの例の構成
  • What I can accomplish: OAuth 2.0認証（authorization code、client credentials、PKCE）、JWTトークンの発行・検証、セッション管理・リフレッシュトークンのローテーション、SSO連携（SAML、OIDC）
  • Required inputs: Client ID/Secret、事前登録済みのRedirect URI、要求スコープ（read:user、write:data、admin）
  • Constraints: アプリケーションごとに毎分1000件のトークン要求、アクセストークン1時間・リフレッシュトークン30日、パブリッククライアントはPKCE必須
  • Key documentation: OAuth 2.0 Guide、Token Reference、Postman Collection
• エージェントはドキュメント全体を読むためのコンテキスト予算を使う前に、APIがユーザー意図を満たせるか判断できる

Layer 4: エージェントがパースしやすいコンテンツ形式

• HTMLだけでなくMarkdownも提供 — URLに.mdを追加するかクエリパラメータで元のMarkdownへアクセスできるようにし、タグ・ナビゲーション・フッターのノイズを除去してトークンオーバーヘッドを劇的に削減
• 読ませるためではなくスキャンさせるための構造化
  • 一貫した見出し階層（H1 → H2 → H3、スキップなし）
  • 各セクションは背景説明ではなく結果（outcome）から開始
  • コード例は説明の直後に配置
  • パラメータリファレンスは散文リストではなく圧縮率の高い表を使用
• サイドバー、パンくず、フッターリンクのようなナビゲーションノイズを除去
• 各ページの最初の500トークンで「これは何か、何ができるか、始めるには何が必要か」に答える

Layer 5: トークン露出

• llms.txtインデックスとページ自体（メタデータまたはページヘッダー）にトークン数を露出する
• エージェントが利用する判断例
  • 「このページは8Kトークン — コンテキストに丸ごと含められる」
  • 「このページは150Kトークン — 関連セクションだけ取得すべき」
  • 「コンテキストウィンドウ超過 — llms.txt要約を使う」
• 実装はサーバーサイドで文字数を数えて約4で割って推定し、メタタグまたはHTTPレスポンスヘッダーで露出

Layer 6: 「Copy for AI」

• 開発者がIDE内AIアシスタントにドキュメントをコンテキストとして含めようとすると、レンダリング済みHTMLのコピーにはナビゲーションやフッターノイズまで含まれてしまう
• クリーンなMarkdownをクリップボードへコピーする「Copy for AI」ボタンは、エージェントが受け取るコンテキスト品質を有意に改善する
• Anthropic、Cloudflareなどがすでに派生版を公開しており、低コスト・高シグナル

AGENTS.md: 台頭する基本標準

• README.mdが人間の開発者にとってのリポジトリ入口だったように、AGENTS.mdはAIエージェントの入口として台頭している
• コーディングエージェントはプロジェクトを開くとルートディレクトリのAGENTS.mdを探し、その後のすべての作業の指針として利用する
• 良いAGENTS.mdに含めるべき項目
  • プロジェクト構造と主要ファイルの場所
  • 関連するAPI/サービス文書への直接リンク
  • 利用可能な開発サンドボックスとテスト環境
  • エージェントが把握すべきrate limitと制約
  • コードベースで推奨されるパターンと規約
  • 利用可能であればMCPサーバーへのリンク
• Cisco DevNetはこれをオープンソースプロジェクトのGitHubテンプレートの標準ファイルとして採用しており、新規プロジェクト作成時にOpenAPI文書、DevNetサンドボックス、テスト環境リンクを含むプロジェクト別AGENTS.mdが事前に埋め込まれる

AIリファラルトラフィックの監視

• 今すぐできること: 分析ツールでAIリファラルトラフィックの追跡を開始する
• 注視すべきリファラルソース: labs.perplexity.ai/referral、chatgpt.com/(none)、chatgpt.com/organic、link.edgepilot.com/referral、platform.openai.com/referral、perplexity/(not set)、claude.ai/referral、copilot.microsoft.com/referral、gemini.google.com/referral
• リファラーなしで到着する直接エージェントトラフィックは、前述のHTTPフィンガープリント（axios/1.8.4、curl/8.4.0、got (sindresorhus/got)、colly）で捕捉する
• 適切なAIトラフィックセグメントを構築すれば、AEO施策の効果を判断するための先行指標が得られる

開発者体験へのより広い含意

• これまで開発者ポータルは段階的開示（progressive disclosure）、視覚的階層、インタラクティブな例、ガイド付きチュートリアルなど、人間の認知パターンを中心に設計されてきた
• エージェント中心の世界で崩れる前提
  • 視覚的階層は無意味 — エージェントはレイアウトではなくテキストを読む
  • 段階的開示は障害物 — エージェントはすべてを一度に欲しがる
  • インタラクティブな例は価値を失う — 静的/API等価物がなければ無用
  • ユーザージャーニーの崩壊 — 複数ページのチュートリアルが単一のコンテキスト読み込みになる
• 人間中心設計が消えるわけではないが、人間もますますAIアシスタントのコンテキスト内でドキュメントを読むようになる
• 今後の最高のドキュメントは、人間にとってはスキャンしやすく、よく構造化され、エージェントにとっては機械可読でトークン効率が高いものであるべき

AEO監査チェックリスト

Discovery

• ルートに構造化されたドキュメントインデックスを含むllms.txtが存在する
• robots.txtが既知のAIエージェントuser-agentを意図せずブロックしていない
• agent-permissions.jsonで自動クライアントのアクセスルールを定義している
• コードリポジトリに関連文書を結び付けるAGENTS.mdが存在する

Content structure

• レンダリング済みHTMLではなくクリーンなMarkdownでドキュメントページを提供している
• 各ページは最初の200語以内に明確な結果の記述を先頭配置している
• 見出しが一貫しており、階層的にも正しい
• コード例は散文による説明の直後に置かれている
• パラメータリファレンスは入れ子の散文ではなく表を使っている

Token economics

• ドキュメントページごとのトークン数を追跡している
• チャンク化戦略なしで30,000トークンを超える単一ページがない
• 主要ページのトークン数をllms.txtで公開している
• ページメタデータ（メタタグまたはHTTPヘッダー）でトークン数を提供している

Capability signaling

• skill.mdファイルが各サービス/APIの呼び出し方法ではなく機能を記述している
• 各skillにcapabilities、required inputs、constraints、key doc linksが含まれている
• 該当する場合は直接エージェント連携用のMCPサーバーを提供している

Analytics

• Web分析でAIリファラルソースをセグメント化している
• 既知のAIエージェントHTTPフィンガープリントに対するサーバーログ監視を行っている
• AI対人間トラフィック比率のベースラインを設定している

UX bridge

• ドキュメントページに「Copy for AI」ボタンを提供している
• URL規約（例: .mdを追加）でMarkdown原文へアクセスできる

Tooling

• **agentic-seo**という軽量監査ツールが公開されており、llms.txt、robots.txtのエージェントブロック、トークン数、Markdownの可用性などをスキャンする — エージェント対応度のためのLighthouse的な発想

どこから始めるべきか

• 推奨順序
  1. robots.txtを監査 — 10分でできる作業で、静かなエージェントロックアウトを防げる
  2. llms.txtを追加 — 数時間の作業で、即時に発見可能性が向上
  3. トークン数を測定・公開 — 週末プロジェクト向きで、レバレッジが高い
  4. 上位3つのAPI向けにskill.mdを作成 — エージェントが最も多くアクセスする対象から着手
  5. 「Copy for AI」ボタンを追加 — 低コスト・高シグナル
  6. AIトラフィック監視を設定 — そのほかの施策を正当化するデータを確保

まとめ

• SEOが「優れたコンテンツだけでは不十分で、その時代の実際のトラフィックパターンに合わせて発見可能にしなければならない」と教えたように、AEOは新たな消費者に対する同じ教訓である
• AIコーディングエージェントはすでにドキュメントトラフィックの中で相当かつ増加中の割合を占めており、人間の読者とは根本的に異なる挙動を示す
• 早期対応するチームは自社APIがエージェントによって推奨され、成功裏に統合・再利用される優位を確保できる
• 対応しないチームは、ドキュメント品質と実際のエージェント作業成功率の間のギャップが広がるデバッグしにくい静かな失敗モードに直面する
• エージェント向けに構築することは結果として人間にとってもより良いドキュメントを生み出し、両者は分岐するよりも重なり合う部分が大きい