§ Village GazetteWeb・アプリ開発

LLMO/AEO対策の実例｜個人開発サイトがAI検索のためにやったこと全部

ChatGPTやPerplexityが「検索の入口」になる時代に、個人開発のWebサイトは何をすべきか。AIクローラー20種の明示許可、llms.txt/llms-full.txtの動的生成、構造化データ5種、AIに引用されやすいFAQ設計まで — このサイトで実装済みの施策を、コードと考え方ごと公開します。

公開: 2026/8/12書いた人: ゆーき

#SEO#LLMO#AI検索#Next.js

「調べ物はChatGPTに聞いて終わり」— 自分自身の行動がそう変わってきたなら、サイト運営者としては無視できない変化です。検索の入口がGoogleからAIチャットに移るほど、AIの回答に引用されないサイトは存在しないのと同じになっていきます。

この記事では、いわゆるLLMO(Large Language Model Optimization)/AEO(Answer Engine Optimization)と呼ばれる領域の施策を、このサイト(AppVillage)で実装済みのものだけ、コードと考え方ごと公開します。効果がまだ検証しきれない部分は、正直にそう書きます。

この記事で分かること

AIクローラー20種を明示許可したrobots.txtの実物と、その分類
llms.txt / llms-full.txt(AI向け全文データ)の実装方法
構造化データ5種と、AIに引用されやすいFAQの書き方
「効果測定はどうするのか」への現時点の正直な答え

結論: LLMOはSEOの延長。ただし「AIに全文を渡す」発想が加わる

LLMOの土台は普通のSEOです。クロールできる・構造が明確・一次情報がある — ここができていないのにLLMO専用施策をしても意味がない
その上で加わるのが「AIが読みやすい形でデータを差し出す」発想。robots.txtでのクローラー許可、llms.txt、構造化データ、一問一答のFAQがそれにあたる
施策のコストはどれも低い。効果の実証はまだ業界全体で途上なので、「安い先行投資」と割り切って整備するのが現実的な温度感です

施策1: AIクローラーを明示的に許可する(robots.txt)

まず入口です。AIクローラーはデフォルトではUser-agent: *のルールに従いますが、うちは主要20種を名指しで許可しています。Next.jsのrobots.tsから抜粋:

// AI クローラーを明示的に許可（デフォルト許可だが明記しておく方が安全）
{ userAgent: 'GPTBot', allow: '/', disallow },           // OpenAI 学習用
{ userAgent: 'OAI-SearchBot', allow: '/', disallow },    // ChatGPT Search
{ userAgent: 'ChatGPT-User', allow: '/', disallow },     // ChatGPT Agent
{ userAgent: 'ClaudeBot', allow: '/', disallow },        // Anthropic 学習用
{ userAgent: 'Claude-SearchBot', allow: '/', disallow }, // Claude Search
{ userAgent: 'PerplexityBot', allow: '/', disallow },    // Perplexity
{ userAgent: 'Google-Extended', allow: '/', disallow },  // Gemini 学習用
{ userAgent: 'Applebot-Extended', allow: '/', disallow },// Apple Intelligence
// ...ほか Meta / Amazon / Cohere / CCBot / Bytespider など計20種

ポイントはAIクローラーに3つの役割があることです。

学習用(GPTBot, ClaudeBot, Google-Extended…) — モデルの学習データ収集
AI検索用(OAI-SearchBot, Claude-SearchBot, PerplexityBot…) — 回答の引用元探し
エージェント用(ChatGPT-User…) — ユーザーの指示でその場でページを読みに来る

「学習は拒否、検索は許可」のような使い分けもできます。うちは見つけてもらうこと自体が価値のプラットフォームなので全許可ですが、ここはサイトの性質で判断してください(認証が要るページ等は従来どおりdisallowしています)。

施策2: llms.txt と llms-full.txt — AIに「全文データ」を差し出す

LLMO文脈で一番特徴的な施策がこれです。うちは2枚置いています。

/llms.txt — サイトの構造と主要ページを案内する静的な「AI向けサイトマップ」
/llms-full.txt — 掲載中の全アプリ66件+全記事のメタデータをMarkdown 1ファイル(約270KB)にまとめた全文データ。Next.jsのRoute Handlerで動的生成しています

llms-full.txtの実装は素朴で、DBから全データを引いてMarkdownの行を組み立てるだけです:

// src/app/llms-full.txt/route.ts（抜粋）
export const revalidate = 3600  // 1時間キャッシュ

export async function GET() {
  const { data: apps } = await supabase
    .from('apps')
    .select(`id, title, description, tags, os_support, store_links, ...`)
    .order('created_at', { ascending: false })

  const lines: string[] = []
  lines.push('# AppVillage（アプリ村） — 全アプリ一覧')
  lines.push('> このファイルは LLM / AI クローラー向けに、掲載されている全アプリの')
  lines.push('> メタデータを Markdown 形式でまとめた全文データです。')
  // …アプリごと・記事ごとにMarkdownセクションを生成
  return new Response(lines.join('\n'), {
    headers: { 'Content-Type': 'text/plain; charset=utf-8' },
  })
}

狙いはシンプルで、AIがサイトを何十ページもクロールしなくても、1リクエストで全体像を正確に把握できるようにすることです。「日本の個人開発アプリを紹介して」という質問に対して、AIの手元に66アプリ分の正確なメタデータがある状態と、断片的なページ情報しかない状態 — 引用のされやすさが変わる、という理屈です。

正直な注記: llms.txtは提案段階の仕様で、全AIが読む保証はまだありません。ただ実装は数時間、維持コストはほぼゼロ(記事やアプリの追加に自動追従)なので、先行投資として置いています。

施策3: 構造化データ(JSON-LD)を5種類

AIと検索エンジンの両方に「このページが何なのか」を機械可読で伝える層です。うちで使っているのは:

スキーマ	使う場所
`Organization`	サイト全体(運営者情報)
`Article`	村だよりの各記事(著者・日付・画像)
`FAQPage`	記事のFAQと、トップのよくある質問
`BreadcrumbList`	全ページのパンくず
`SoftwareApplication`	各アプリの詳細ページ(名前・OS・カテゴリ)

特に効くと考えているのがFAQPageとSoftwareApplicationです。どちらも「一問一答」「属性の明確なエンティティ」という、AIが回答を組み立てるときにそのまま使える形をしています。

施策4: コンテンツ自体を「引用されやすい形」で書く

技術実装より、実はここが本丸だと思っています。この村だよりの記事は全部、次のルールで書いています。

結論を記事の先頭に置く — AIは長文の途中から要点を拾うのも得意ですが、明示された結論はより安全に引用できます
全記事にFAQを2〜3個付ける — frontmatterに一問一答で書き、可視のFAQ+FAQPage構造化データの両方に自動展開されます。「〜とは?」「〜すべき?」というAIへの質問文と同じ形の見出しが、そのまま引用候補になります
一次情報の実数を出す — 「DL12件・収益$5」「TTFB 3秒→0.3秒」のような固有の実数は、他のどこにもないデータです。AIは一般論の要約は得意ですが、固有の一次情報は原典を引用するしかない。これが個人サイト最大の武器です

効果測定は? — 正直な現在地

ここは誇張なしで書きます。LLMOの効果測定は、まだ確立していません。

現状うちで見ているのは:

GA4の参照元 — chatgpt.comやperplexity.aiからの流入(AIの回答内リンク経由)が付き始めたら、それが一番直接的なシグナルです
Search Console — AI Overviewを含むGoogle側の表示は、従来の検索パフォーマンスにある程度混ざって出ます
llms-full.txtへのアクセス — AI系User-Agentが読みに来ているかどうか

数字で「LLMOでこれだけ伸びた」と言える段階にはまだありません。言えるのは、施策コストが低く、SEOと共通の土台整備がそのまま活きるので、やらない理由も特にない、ということです。効果の実数が溜まったら、続編で正直に公開します。

LLMO/AEOチェックリスト

robots.txtでAIクローラーの扱いを明示したか(許可でも拒否でも、意図を持って)
/llms.txtでサイトの構造をAIに案内しているか
主要データを1ファイルで渡せる/llms-full.txtがあるか(動的生成+キャッシュ)
Article / FAQPage / パンくず等の構造化データを入れたか
記事は結論先出し+FAQ付きの構成か
他所にない一次情報(実数・実体験)が入っているか

まとめ

LLMO/AEOはSEOの延長線。クロール可能・明確な構造・一次情報という土台の上に、「AIへデータを差し出す」施策を足す
実装したのは4層: AIクローラー20種の明示許可 → llms.txt/llms-full.txt → 構造化データ5種 → 引用されやすいコンテンツ設計
どれも実装コストは低い。効果の実証は業界全体でこれからなので、安い先行投資と割り切る
そして最強のLLMO対策は、技術ではなく「AIが引用するしかない一次情報を持つこと」です

このサイトの実装はすべて本番で動いています。https://www.app-village.jp/llms-full.txtをブラウザで開くと、AIが受け取っているのと同じデータを見られますよ。

§ Sources

参考情報・出典

§ FAQ

よくある質問

SEOが「検索結果で上位に表示される」ための最適化なのに対し、LLMO/AEOは「AIの回答の中で引用・言及される」ための最適化です。ただし土台は共通で、クロールできる・構造が明確・一次情報がある、というSEOの基本がそのままLLMOの前提になります。対立ではなく延長線です。

正直に言うと、効果の保証はまだありません。llms.txtは標準化の途上で、全AIが読む確約はない段階です。ただし実装コストは非常に低く(静的ファイル1枚+自動生成1ルート)、AIに正しく理解される可能性を上げる先行投資としては割に合う、というのが筆者の判断です。

サイトの性質によります。コンテンツ販売が主なら学習用クローラーの拒否は合理的です。一方、このサイトのような「見つけてもらうこと自体が価値」のプラットフォームでは、AIの回答に引用されることが新しい流入経路になるため、明示的に許可しています。robots.txtで学習用・検索用を個別に制御できるので、ゼロイチではなく使い分けが可能です。

§ Share

Xでシェア

§ Read Next