はじめに：検索エンジンの次に来るもの
私はデベロッパーではない。10年以上金融機関のUX/UIデザインをしてきたデザイナーだ。3ヶ月前、ClaudeをコーディングパートナーとしてバニラPHPでブログをゼロから構築した。フレームワークなし、WordPress なし。
その過程で気づいたことがある。GoogleのクローラーとAIエージェントでは、ウェブサイトに求めるものが根本的に違う。
Googleはリンク構造とキーワードを分析する。AIエージェントはコンテンツを直接読み、回答に引用するかどうかを判断する。つまり、SEOだけでは足りない時代が来ている。
Cloudflareのテストで現実を知った
CloudflareがIs It Agent Readyというツールを公開した。10の規格をチェックしてスコアを出す。
自分のブログを試した結果：50/100。
最初は低いと思った。しかし調べてみると、10の規格のうち6つはSaaSプラットフォーム向け（OAuth、MCP、API Catalog等）で、コンテンツサイトには関係ない。ブログの理論最大値は約40点で、Markdownネゴシエーションのサブテストでボーナスが付いて50点になった。
つまり、自分のサイトタイプにとっては満点に近い。
実装した4つの規格とコード
規格1：llms.txt
LLM向けの自己紹介ファイル。robots.txtがGoogleに「何をクロールするか」を伝えるように、llms.txtはAIモデルに「自分は誰で、何を書いていて、どのページが重要か」を伝える。
ドメインルートに配置するMarkdownファイルだ。
# サイト名
> サイトの説明文（AIモデル向け）
## Author
- Role: UX/UI Designer
- Experience: 10+ years in fintech
## Key Pages
- [About](https://yoursite.com/about)
- [Best Article](https://yoursite.com/best-article)
PHPルーターがリクエストを横取りしないようにApacheで設定する：
RewriteRule ^llms\.txt$ - [L]
robots.txtにも参照を追加：
LLMs-Txt: https://yoursite.com/llms.txt
自分で書くのが面倒な人向けに無料ジェネレーターも作った。URLを入力するだけでllms.txtが生成される。
規格2：Content Signals
robots.txtに1行追加するだけ。実装コスト30秒。
Content-Signal: ai-train=no, search=yes, ai-input=yes
この1行の意味：
-
ai-train=no→ コンテンツでモデルを訓練するな -
search=yes→ 検索結果には表示しろ -
ai-input=yes→ AI回答のインプットには使え
「無料でコンテンツを使わせる」のと「引用のルールを決める」のは全く違う。この1行がその境界線になる。
規格3：Markdown for Agents
これが最も技術的な実装だった。AIエージェントがAccept: text/markdownヘッダーでリクエストしたとき、HTMLではなくクリーンなMarkdownを返す仕組みだ。
なぜこれが重要か。AIエージェントにとって、ナビゲーションバー、Cookieバナー、JavaScriptバンドルはすべてノイズだ。記事本文だけが欲しい。Markdownならトークン消費も大幅に減る。
.htaccessでルーティング：
RewriteCond %{HTTP_ACCEPT} text/markdown
RewriteRule ^(.*)$ markdown-negotiator.php [L,QSA]
Header always append Vary "Accept"
PHP側の変換ロジック（主要部分）：
// HTMLからMarkdownへの変換
$md = preg_replace('/<h2[^>]*>(.*?)<\/h2>/s', "\n## $1\n", $md);
$md = preg_replace('/<a\s+href="([^"]*)"[^>]*>(.*?)<\/a>/s', '[$2]($1)', $md);
$md = preg_replace('/<strong>(.*?)<\/strong>/s', '**$1**', $md);
$md = preg_replace('/<p>(.*?)<\/p>/s', "$1\n\n", $md);
$md = strip_tags($md);
header('Content-Type: text/markdown; charset=utf-8');
header('Vary: Accept');
Vary: Acceptヘッダーを忘れると、CDNやプロキシが間違ったバージョンをキャッシュする可能性がある。
規格4：Agent Skills discovery
/.well-known/agent-skills/index.jsonに配置するJSONファイル。サイトで利用可能なツールをエージェントに伝える。
{
"skills": [
{
"name": "llms.txt Generator",
"url": "https://shinobis.com/tools/llmstxt-generator",
"description": "Generate a valid llms.txt file for your website"
},
{
"name": "GEO Tarot",
"url": "https://shinobis.com/tools/geo-tarot",
"description": "22 interactive cards explaining Generative Engine Optimization"
}
]
}
これにより、エージェントはサイトのすべてのページをクロールしなくても、利用可能なリソースを発見できる。
実装しなかった6つの規格
OAuth/OIDC → ブログにログイン機能なし。認証不要。
OAuth Protected Resource → 保護するAPIエンドポイントなし。
API Catalog (RFC 9727) → REST APIを公開していない。
MCP Server Card → ドラフト段階で未確定。明日変わるかもしれない仕様を実装するのは技術的負債。
WebMCP → Chrome実験機能。普及率ほぼゼロ。
Link headers (RFC 8288) → コンテンツサイトへの影響が測定不能。
自転車にエアバッグをつけるようなものだ。技術的に可能でも、意味がない。
これはSEOの延長線にある
この4つの規格は単独で機能するものではない。JSON-LD、Schema.org、llms.txt、Content Signals、内部リンク構造、マルチ言語対応。これらが組み合わさって初めて「AIモデルが信頼できるソース」として認識される。
私はこの全体像を22枚のインタラクティブカードにまとめた。GEO（Generative Engine Optimization）と呼ばれる概念で、SEOの次に来る最適化戦略だ。タロットカードのメタファーで各概念を説明している。
デザイナーだからこそ見えたこと
面白いのは、AIエージェント対応の本質がUXデザインと同じだということだ。
人間のユーザーにはレスポンシブデザインで最適な表示を提供する。モバイルとデスクトップで同じHTMLを送るのではなく、ビューポートに合わせて調整する。
AIエージェントも同じだ。ブラウザ向けのHTMLをそのまま送るのではなく、エージェントが処理しやすいMarkdownを返す。「ユーザーに合わせてコンテンツの形を変える」という原則は同じだ。
デベロッパーの視点だと「技術的に正しい実装」に目が行く。デザイナーの視点だと「受け手にとって最適な形」に目が行く。どちらも必要だが、後者の視点がAIエージェント対応では特に重要だと感じている。
テストしてみてほしい
isitagentready.comでスコアを確認できる。アカウント不要、URLを入力するだけ。
特に知りたいのは、PHP以外のスタックでの結果だ。Next.js、Rails、Laravel、WordPress。フレームワークが自動で対応している規格はあるのか、それとも手動実装が必要なのか。
皆さんのスコアと使っているスタックをコメントで教えてほしい。AIエージェント対応のベンチマークを一緒に作りたい。