AI時代のSEO実装戦略: カスタマー、検索クローラー、AIエージェントの三方良しを目指して

published

author

authorDisplayName

Shirahama Yasutomo

はじめに：AI時代のSEOの取り組みを再定義する

ブラウザからChatへ、私たちの検索体験はこの数年で確実に変化しました。ブラウザを使う頻度が減った昨今、SEO対策はもう時代遅れのように思われます。

しかし、AIエージェントがカスタマーに代わって情報を探索し、回答を生成するようになった今、これまで以上の厳密で高いレベルのSEO対策が必要になっています。AIエージェントに正確に情報を拾ってもらい、参照元として引用してもらうためには、曖昧さを排除し、構造化されたデータと機械が読みやすい土台が不可欠だからです。

令和トラベルのSEOチームが目指すのは、以下の「三方良し」の状態です

💡

カスタマー（人間）：快適でリッチなUI/UX体験、カスタマーファーストなコンテンツ

検索クローラー（Bot）：正確なインデックス

AIエージェント（LLM）：コンテキストの即時理解とハルシネーションの回避

このゴールを達成するために、旅行アプリ『NEWT（ニュート）』で実践している、「泥臭い」技術的アプローチを紹介します。

1. AIはJSを実行しない？CSRとプリレンダリングのハイブリッド

リッチなUXを実現するにはCSR（クライアントサイドレンダリング）が有利ですが、AIに選ばれるためにはサーバー側であらかじめ生成された「完成されたHTML」を提供するプリレンダリング（Next.jsではSSR, SSG, ISR等）の採用が不可避です。

例えば、CSRのページをChatGPTに読み込むように依頼すると、件数が0件と判断されてしまいます。

これは、GPTBot/OAI-SearchBot（OpenAI）やClaudeBot（Anthropic）などの主要なAIエージェントが、リソース効率とコストの観点から JavaScriptを実行せず、生のHTMLのみを解析しているためです。　

CSRではなく、事前にページをレンダリングすること=プリレンダリングが、AIエージェント対策では必要になります。

戦略：デザインが同一のプリレンダリングページを用いた三方良し

カスタマーのUXを毀損することなく「三方良し」を実現するために、私たちは既存の検索ページ（CSR）とデザインがほぼ同一のプリレンダリングページを、CSRの手前の段階に用意しました。

すなわち、プリレンダリングページをindexさせ（検索クローラー対策）、プリレンダリングでコンテンツの完全性を保ち（AIエージェント対策）、同一デザインでスムーズにCSRページに遷移させることで、従来のUXを維持しています。

ほぼ同一のデザインにすることで、絞り込み時にシームレスにCSRページに遷移が可能。

実装ポイント：CSRページでも構造化データ・canonical等はサーバーサイドでレンダリングを行う

AI時代では、CSRページであってもタイトル/h1/h2/構造化データ/canonicalなどの重要な情報はサーバーサイドでレンダリングすることが推奨されています。

NEWTの場合、CSRページにはNext.jsのISRを活かすためにPages RouterのgetStaticPropsを使用していますが、この getStaticProps ではメタ情報に必要なURLクエリが使えないため、 proxy（v15以前ではmiddleware）でURLのパス変換を行っています。


/** proxy.ts **/
if (currentPath === "/tour/search") {
  const destinationId = req.nextUrl.searchParams.get("destinationId");
  const url = req.nextUrl.clone();

  // /tour/search/destinationId__XX/airportId__XX に変換
  url.pathname = appendQueryToPath({destinationId});  
  
  return NextResponse.rewrite(url);
}

/** getStaticProps **/
export async function getStaticProps({ params }) {

  // pathからdestinationIdを取り出す
  const { destinationId } = getQueryFromPath(params);
  const destination = await fetchDestinationById(destinationId);
  
  // canonical・構造化データはサーバーサイドで生成する
  const canonical = `https://newt.net/tour/${destination.code}`;
  const breadcrumbs = generateBreadcrumbs(destination);
  
  return {
    props: { canonical, breadcrumbs },
    revalidate: 60, 
  };
}

getStaticPropsではURLクエリを取得できないため、パスに変換。フレームワークの制約をフレームワークを使いこなして乗り越えています。

2. プロンプトとしてのURL設計とリライト

戦略：評価と発見性を高めるための「階層構造」

旅行サービスにおける情報の探索は構造的です。

「海外旅行」という大きな括りから、「国」、「都市」へとドリルダウンしていくことで、カスタマーは目的の情報に辿り着きます。

この階層構造は従来SEO評価を集約するという観点で重要でしたが、AI時代においてはカスタマーが求めているものをすぐに発見できるというDiscoverabilityの観点で大切になりました。

従来：評価の集約（Authority） 検索ボリュームのある「国」や「都市」の階層に評価を集め、そこから下層ページへ適切にリンクジュースを分配する。

AI時代：LLMにとっての発見性（Discoverability）: 論理的なツリー構造は、クローラーやAIエージェントがサイトの全体像を把握することに寄与。コンテンツの親子関係が明確であればあるほど、AIはコンテンツを効率よく発見し、その文脈（Context）を正しく理解する。

戦略：セマンティックなURL文字列によるコンテキスト注入

LLMは入力されたテキスト（トークン）を処理して回答を生成しますが、そのコンテキストウィンドウは有限であり、処理にはコストがかかります。ここでセマンティックURL（意味のあるURL）にすることで、URLの文字列をプロンプトとして表現することができます。

例

IDベースのURL：https://example.com/12000/222

NEWT：https://newt.net/tour/hwi/breakfast

IDベースのURLではURLから中身を予測することが困難ですが、NEWTの例では「ハワイ」の「朝食付き」の「ツアー」であることが読み込む前から予測が可能です。URLをセマンティックにすることで、URLだけでLLMにコンテキストを追加することができます。

これはURL自体の発見性を高めるだけでなく、関連性の高いクエリに対して回答ソースとして引用される確率も高めることにもつながります。

実装ポイント：リライトの積極利用

NEWTではこの理想のURL構造に近づけるために、Next.jsのリライト機能を積極的に活用しています。

例1：別プロダクトを階層構造に取り込む

NEWTではメインのプロダクトとは別に「旅行ガイド」のメディアもモノリポ内で管理していますが、basePath等でサブディレクトリに分けるのではなく、あえてURL階層構造に組み込んでいます。

△ /mag/12345

一般的なモノリポ構造のリライト設計

○ /hwi/mag-12345

旅行ガイドの該当記事がハワイに関する記事だと理解可能


module.exports = {
  async rewrites() {
    return [
      {
        source: '/:country/mag-:articleId',
        destination: `${MAGAZINE_DOMAIN}/:country/mag-:articleId`,
      },
  ...

next.config.tsでのリライト設定

このように細かく設定することで、SEO評価が/hwiに集まるだけでなく、「記事がハワイに関連する」という事実がAIに伝わりやすくなります。

例2：フラットな階層構造とルーティングの衝突の解決

特定の検索意図（ツアー ✕ ハワイ ✕ 〇〇）に対して論理的な切り分けでURLを設計すると、URLが深く冗長になり、余分なディレクトリ（airlineやairportなど）を生んでしまいます。

× 論理的な切り分けで作られたURL

/tour/hwi/airline/jl

階層が深くSEO評価が分散する上に、/airlineというページが必要になる

○ 階層がフラットで意味が通じやすいURL

/tour/hwi/airline-jl
/tour/hwi/airport-nrt
/tour/hwi/breakfast

しかし、Next.jsのファイルベースルーティングでは、/tour/hwi/[slug] という構造において、 airline-jl と airport-nrt と breakfast を区別できません。

NEWTでは、URL上はフラットに、ファイルベースでは別ファイルに遷移するように、next.config.ts内でリライト設定しています。


module.exports = {
  async rewrites() {
    return [
      // 例：/tour/hwi/airline-jl → /tour/hwi/airline/jl に内部的に振り分ける
      {
        source: '/tour/:country/airline-:airlineCode',
        destination: '/tour/:country/airline/:airlineCode',
      },
      // 例：/tour/hwi/airport-nrt → /tour/hwi/airport/nrt に内部的に振り分ける
      {
        source: '/tour/:country/airport-:airportId',
        destination: '/tour/:country/airport/:airportId',
      },
...

リライト設定の例。/tour/hwi/airline/jl のように切り分けたほうがわかりやすく、ルーティングも綺麗になるが、細かいSEO要件を地道に実現していく