ほとんどの Three.js サイトは、最初のユーザーが訪れる前に SEO 競争で負けています。canvas にはクローラーが読めるテキストがなく、バンドルサイズは Core Web Vitals の予算を大幅に超え、ヒーローアニメーションは初回ペイント時にデバイスをフリーズさせます。本ガイドは、Utsubo が実案件で使う本番運用プレイブックです。視覚的にインパクトのある 3D サイトを構築しながら、検索順位もしっかり確保する方法を解説します。実例として、生成エンジン最適化（GEO）プラットフォームである AthenaHQ の事例も紹介します。GEO 企業として、彼ら自身の First Contentful Paint は業界最速レベルである必要がありました。
対象読者： Three.js、React Three Fiber、WebGPU を使ったサイトを公開・運用しているファウンダー、マーケティング責任者、クリエイティブ Web エンジニア。Google 検索だけでなく、AI クローラー（ChatGPT、Perplexity、Gemini）からの可視性も確保したい方。
本記事の要点
<canvas>要素にはインデックス可能なテキストが一切存在しない。SSR/SSG によるフォールバックコンテンツがなければ、Googlebot は空のページしか見ない。- ボトルネックはネットワークではなく、メインスレッドにある。シェーダーコンパイル、ジオメトリ解析、テクスチャデコード — これらはデフォルトで入力と描画をブロックする。
- 3D バンドルは初回ペイント後に遅延読み込みし、
OffscreenCanvasと Web Worker でコンパイル処理をオフロードする。 - モバイルでは静止画を出す。アニメーションを諦めるトレードオフは、Core Web Vitals のあらゆる指標で正解。
- AI 検索エンジン（ChatGPT、Perplexity、Gemini）は速度と構造化コンテンツを重視する。SEO を無視した WebGL サイトは GEO でも沈む。
1. なぜ Three.js サイトはデフォルトで SEO に弱いのか
1-1. canvas はクローラーから見えない
<canvas> 要素はピクセルを描画するだけです。DOM テキストも見出しもアンカーリンクも含まれません。Googlebot は HTML を読み込み、ヘッドレス Chromium で JavaScript を実行し、その時点で DOM に残っているものをインデックスします。サイトの価値が canvas の中にある場合（プロダクト演出、スクロール連動の体験、没入型イントロなど）、その価値は一切インデックスされません。
解決策は「JavaScript をもっと増やす」ことではなく、HTML ファースト設計です。意味のあるすべてのページ状態は、レンダラーが起動する前にクロール可能なマークアップとして存在する必要があります。
1-2. バンドルサイズが Core Web Vitals を破壊する
Three.js のコアだけで minified 後に約 600 KB。シーンコード、モデル、テクスチャを足す前のサイズです。drei、ポストプロセッシング、.glb ファイルを加えると、スタイリング前で 3 MB を超えます。結果は、LCP 超過、INP 悪化、Lighthouse パフォーマンススコア 30 点台。
1-3. AI エンジンは Google よりも厳格
生成エンジン最適化（GEO）— ChatGPT、Perplexity、Claude、Gemini の回答内での可視性 — は SEO の基本に加えて、追加要件があります。AI クローラーは遅いページにより不寛容で、構造化データをより重く評価し、インデックス可能な HTML から逐語的に抽出できる回答を好みます。デザイン賞を受賞した美しい Three.js サイトが、AI 検索からは完全に消える可能性があります。
2. クロール可能性：まずインデックスを修正する
2-1. ページを HTML として配信し、canvas は後でハイドレートする
最も重要なパターンです。コンテンツをサーバーサイドでレンダリングし、プログレッシブに 3D を強化していきます。Astro、Next.js、Remix、SvelteKit — どれも SSG/SSR をサポートしています。一つ選んで、すべてのルートで使ってください。
ページ内で canvas はインデックス可能なコンテンツの上に乗るレイヤーとして配置します。3D が読み込まれなくても、ヒーローコピー、H1、プロダクト説明、CTA ボタンはすべて DOM に存在します。
2-2. <noscript> と可視フォールバックテキストを使う
JavaScript を無効にしたユーザー（少数）と、低予算モードで動くクローラー（多数）のために、canvas ラッパー内に <noscript> フォールバックを配置し、3D 版と同じ見出し、要約、CTA を含めます。これはアクセシビリティの最低ラインでもあります。
2-3. 動的な状態はプリレンダリングする
3D をプロダクトコンフィギュレーターやインタラクティブマップとして使う場合、意味のある各状態に対してインデックス可能な URL を生成します。SSR されたメタデータ付きの /product/x-pro?color=black URL は、クライアント専用の JavaScript ルーターより常に勝ちます。
2-4. URL Inspection ツールで監査する
Google Search Console を開き、URL Inspection → Test Live URL → View Tested Page → HTML を確認します。H1、プロダクトコピー、リンクがそこに表示されていなければ、canvas をどれだけ磨いても無駄です。
3. 2026 年版：3D サイト向け Core Web Vitals
3 つの Vital が重要で、3D サイトはデフォルトで全てに失敗します。
Largest Contentful Paint（LCP）：目標は 2.5 秒未満。Three.js のヒーローでは LCP 要素は通常 canvas です。canvas が最初の 3 秒間空であれば、LCP は 3 秒になります。(a) LCP 要素を 3D 前にレンダリングされる実画像や見出しにするか、(b) canvas が高速に最初のフレームを描画する必要があります。
Interaction to Next Paint（INP）：目標は 200ms 未満。INP はメインスレッドが素早く処理できない入力を罰します。メインスレッドで動く Three.js のレンダーループ、メインスレッドでのシェーダーコンパイル、メインスレッドでの大きな .glb 解析 — どれも INP を悪化させます。
Cumulative Layout Shift（CLS）：目標は 0.1 未満。canvas の寸法を明示的な width、height、aspect-ratio CSS で予約しないと、レンダラー初期化時に半秒のジャンプが発生します。
4. 事例：AthenaHQ — FCP を犠牲にせずブランドアニメーションを残す
4-1. ブリーフ
AthenaHQ は生成エンジン最適化（GEO）プラットフォームです。ChatGPT、Perplexity、Gemini など主要な AI 検索エンジン上でブランドがどう表示されているかをトラッキングし、SaaS 企業に対して、どこで勝っていて、どこで負けていて、何を直すべきかを正確に伝えます。プロダクトの前提自体が「AI 検索における可視性は速度とシグナル品質に依存する」というものなので、彼ら自身のサイトもあらゆる速度指標で業界最速レベルである必要がありました。遅い GEO プラットフォームは、即座に信頼性の問題になります。
制約条件：Utsubo がブランドのために制作した 3D イントロアニメーションは残したい。これは視覚的な握手 — プラットフォームを「もう一つの SaaS ランディングページ」ではなく「本物のプロダクト」に見せる要素でした。
4-2. ステップ 1 — 3D バンドルを初回ペイント後に遅延ロード
最初の一手は構造的な変更でした。HTML とクリティカル CSS は、3D バンドルが要求される前にレンダリング・ペイントされます。ヒーローコピー、サブヘッドライン、メイン CTA、価値訴求の箇条書きは、最初のバイトから DOM テキストとして存在します。canvas のスロットは aspect-ratio コンテナで予約され、レンダラーが到着してもレイアウトはシフトしません。
その後、ブラウザの load イベント発火後に 3D バンドルを遅延ロードします。First Contentful Paint と Largest Contentful Paint は、canvas ではなく見出しと CTA にロックされます。
4-3. ステップ 2 — フリーズ問題
遅延ロードだけでは不十分でした。3D バンドルがついに読み込まれると、アニメーションが始まる前にデバイスが数百ミリ秒フリーズしました。原因は私たちが「3D のコンパイル」と呼んでいる現象です。多くのチームがこのコストを過小評価しているため、平易な言葉で説明する価値があります。
3D シーンが起動するとき、メインスレッド上で 3 つの高コスト処理が走ります：
- シェーダーコンパイル：シーン内のすべてのマテリアルは GLSL（WebGPU では WGSL）シェーダープログラムを持ちます。GPU ドライバーは人間が読めるシェーダーコードを、実際に GPU で動作するマシン命令に翻訳しなければなりません。このコンパイルステップは同期的で、シェーダー 1 つあたり 50〜300ms、複雑さとデバイスによって変動します。
- ジオメトリ解析：
.glbや.gltfファイルはパックされたバイナリです。GPU が使える型付き配列に変換するには、ファイルを走査し、バッファビューをデコードし、頂点・インデックス配列を構築し、GPU メモリにアップロードする必要があります。 - テクスチャデコード：PNG、JPEG、KTX2 ファイルはそのままでは使えません。生のピクセルデータに展開し、ミップマップを生成し、アップロードしなければなりません。大きなテクスチャ 1 枚あたり 50〜200ms の処理時間がかかります。
3 つすべてがデフォルトでメインスレッド上で実行されます。これらが動いている間、ページはクリックに反応できず、スクロールできず、新しいフレームを描画できません。見出しのレンダリングが終わった直後、最悪のタイミングでフリーズしたタブをユーザーは目にします。
4-4. ステップ 3 — コンパイル処理を Web Worker に移す
解決策は、重い処理をメインスレッドから完全に外すことでした。OffscreenCanvas を使って canvas を Web Worker に転送し、レンダラー、ジオメトリ解析、テクスチャデコードのすべてを Worker 内で実行しました。メインスレッドは入力、スクロール、描画のために空けたままにします。
具体的には：Worker は transferControlToOffscreen() で canvas を受け取り、その後 3D パイプライン全体 — モデルロード、シェーダー設定、アニメーションティック — をメインスレッドに一切触れずに実行します。ユーザーは見出しを即座に見て、スクロールやクリックがすぐに反応し、Worker がコンパイルを終えるとアニメーションがフェードインします。
これが AthenaHQ にとって両立を可能にしたパターンです：インパクトのあるブランドアニメーションかつ、GEO 企業として擁護できる Core Web Vitals スコア。ロードシーケンス全体を通じて INP は 100ms 以下を維持しました。メインスレッドがボトルネックではなくなったからです。
4-5. ステップ 4 — モバイル：アニメーションではなく画像を出す
モバイルでは Worker 最適化された 3D ですら間違いでした。モバイル GPU はシェーダーコンパイルが遅く、モバイル RAM は厳しく、モバイルユーザーは読み込み速度に敏感です。アニメーションは依然としてページが使えるようになるまでの体感遅延を生んでいました。
モバイルブレークポイントではアニメーションを静止画に置き換えました — デスクトップアニメーションの 1 フレームをキャプチャした高品質な WebP です。瞬時の LCP、ゼロ JavaScript コスト、同じブランド体験。教訓：AthenaHQ のオーディエンスにとってアニメーションはデスクトップの追加価値であり、速度は全プラットフォーム共通の価値です。デザインシステムにヒーローが 1 種類しかないからといって、同じものをどこにでも出してはいけません。
5. 視覚主導サイトのための構造化データ
スキーママークアップは、視覚レイヤーが伝えないコンテキストをクローラーと AI エンジンに渡す手段です。3D 中心のマーケティングサイトでは、3 つのスキーマが効きます：
- Organization — 名前、ロゴ、ソーシャルプロフィール、連絡先。すべてのサイトに必要なベースレイヤー。
- Product または SoftwareApplication — SaaS や EC では、プロダクトスキーマが AI エンジンに「何を売っているのか」を伝えます。
- FAQPage — プロダクトについて上位 5〜8 つの質問に DOM 内で答え、
FAQPageJSON-LD でミラーリング。これが 2026 年最大の GEO レバーです。
ビジュアルストーリーは人間のため、スキーマはそれ以外のすべてのため。両方が必要です。
6. ポートフォリオサイトの内部リンクとハブ＆スポーク
スタジオやプロダクトサイトの多くは、最も価値あるコンテンツを 1 クリック深く埋めています。ポートフォリオ型サイトで順位を動かす 3 つのルール：
- 主要トピックごとに 1 つのハブ。トップナビに存在し、関連するすべてのケーススタディにリンクするピラーページ。
- ケーススタディ同士をクロスリンク。プロジェクトページは、インデックスに戻るだけでなく、関連する他の 2〜3 プロジェクトにもリンクします。
- インサイト記事を浮上させる。記事を書いているなら（この記事のように）、トピックが該当するプロジェクトページからリンクします。3 か月前に書いた Three.js パフォーマンス記事は、すべての 3D プロジェクトページからリンクされるべきです。
7. 3D サイト SEO のためのツールスタック
Utsubo の案件で実際に使っているツール：
- Lighthouse — Core Web Vitals のベースライン + 診断パフォーマンス監査。デスクトップではなくモバイルエミュレーションで実行。
- Search Console URL Inspection — Googlebot が実際に何をレンダリングしたかを確認。
- WebPageTest — ペイントイベントのフィルムストリップビュー。「canvas が LCP をブロック」パターンを発見する最良のツール。
- Chrome DevTools Performance パネル（Memory + Frames レーン） — シェーダーコンパイルが落ちる正確なミリ秒を特定。
- Spector.js — WebGL/WebGPU 呼び出しのフレーム単位インスペクター。フレーム時間を 3 倍にしているドローコールを見つけられる。
- カスタム 3D パフォーマンス予算 JSON — プロジェクトにチェックインし、ルートごとの最大バンドルサイズ、最大テクスチャ数、最大ドローコール数を定義。CI が回帰でビルドを失敗させる。
8. 多言語 3D サイト：hreflang とローカライズ
サイトを 2 言語以上で展開する場合、3 つのポイントがあります。フランス語、ドイツ語、日本語、スペイン語、その他どの言語にも等しく当てはまります：
hreflangペア：すべてのページは他言語のカウンターパートを宣言し、その逆も同様。HTML ヘッドとサイトマップの両方で必要です。不一致または片方向のhreflangタグは、Google が誤ったロケールを誤ったオーディエンスに表示したり、どちらも表示しなかったりする一般的な原因です。- 翻訳ではなくローカライズ：英語マーケティングコピーの直訳が他言語市場で順位が伸びることは稀です。各ロケールにはネイティブな表現、現地通貨での価格、現地の事例、現地の検索意図に合った言い回しが必要。オリジナル言語ページは翻訳ページを上回ります。
- 3D は同じように動く：最適化スタック（遅延、Worker、モバイルフォールバック）はロケール間で変更なく移植可能。一つの言語で速いサイトは他の言語でも速い。パフォーマンスは普遍的、コピーはそうではありません。
9. 始め方
すでに公開済みの 3D サイトが順位が伸びていない場合、優先順位は以下のとおり：
- ホームページに対して Search Console URL Inspection を実行。レンダリング後の HTML に見出し、サブヘッドライン、CTA が表示されることを確認。まずインデックスを修正する。
- モバイルで Lighthouse を実行。LCP、INP、CLS を記録。LCP が 4 秒を超えていれば、今日のうちに 3D バンドルを遅延化する。
- ロード中に Chrome DevTools Performance パネルを開く。3D バンドルのパース直後に 200ms 以上の「Compile Script」または「Recalculate Style」ブロックがあれば、それがシェーダー・ジオメトリのコンパイル。Worker への移行を計画する。
- モバイル体験を監査する。3D が体感遅延を 1 秒以上追加しているなら、静止画に置き換える。
- 実際の質問 5〜8 個と DOM 上の回答を使って
FAQPageスキーマを追加。 - 市場が対象とするすべてのロケールに
hreflangペア付きの翻訳を追加する。
10. Utsubo について
Utsubo はインタラクティブインスタレーションと没入型ウェブ体験を専門とするクリエイティブスタジオです。AI スタートアップ、プレミアムブランド、文化機関のために Three.js、WebGPU、WebGL サイトを構築しています — パフォーマンス予算をブリーフの段階で組み込み、後付けにしません。3D サイトを見つけてもらうための SEO と GEO 対応もワンストップで提供します。
提供サービス：
- Three.js、WebGPU、React Three Fiber 開発
- パフォーマンスファーストの Web アーキテクチャ（Astro、Next.js、SvelteKit）
- 3D サイト向け SEO・生成エンジン最適化（GEO）
- エンドツーエンドのデザイン・実装・ローンチ
11. 3D サイトを検索上位に表示させる準備はできていますか？
順位が必要な Three.js サイトがある、あるいはこれから企画していてフリーズトラップを避けたい — どちらの状況でも、Utsubo がお手伝いします。
チェックリスト：WebGL サイトをランキングに乗せる
- 見出し、サブヘッドライン、CTA は canvas 内ではなく DOM テキストとしてレンダリング
- 3D バンドルは
loadイベント後にロード、クリティカルパスに含めない - OffscreenCanvas + Web Worker でシェーダーコンパイル、ジオメトリ解析、テクスチャデコードを処理
- モバイルブレークポイントで静止画フォールバック
- モバイルで LCP 2.5 秒以下、INP 200ms 以下、CLS 0.1 以下
FAQPageJSON-LD に 5〜8 件の質問と DOM 上の回答を一致させて追加- すべての翻訳ルートに
hreflangペア - Search Console URL Inspection で H1 がレンダリング後 HTML に存在することを確認
- すべての canvas ラッパー内に
<noscript>フォールバック - 3D パフォーマンス予算をリポジトリにチェックインし CI で強制
よくある質問
Three.js サイトに置き換えてから、以前の静的ページより順位が下がったのはなぜですか？
最も可能性が高い理由は、Googlebot がほぼ空の DOM をインデックスしているからです。canvas のコンテンツはテキストではなく、サイトがヒーローのメッセージングを canvas に依存していれば、クローラーは空白のページを見ます。見出し、サブヘッドライン、CTA を、JavaScript が動く前にレンダリングされる実 HTML に移してください。
3D アニメーションを遅延ロードすると、ユーザーエンゲージメントが下がりませんか？
最初に正しいヒーローを出していれば、下がりません。ユーザーは最初の 800ms でサイトを判断します。その 800ms に明確な見出しと CTA が表示されていれば、体感速度はアニメーションのインパクトに勝ちます。AthenaHQ はアニメーションをレイヤード強化として残し、最適化後もエンゲージメントの低下は見られませんでした。
OffscreenCanvas とは何ですか？どのブラウザがサポートしていますか？
OffscreenCanvas は、canvas をメインスレッドから Web Worker に転送できる Web API です。レンダリング、シェーダーコンパイル、アセット処理がメインスレッドの外で動作します。2026 年時点で、Chrome、Edge、Firefox、Safari（16.4+）がサポートしています。それ以前の Safari には静止画フォールバックを自動的に出してください。
WebGPU を使っても順位はとれますか？
はい。WebGPU は起動後の動作は WebGL より速いですが、シェーダーコンパイルは初回ロード時にはむしろ遅くなることがあります。遅延 + Worker のパターンは変わらず適用でき、効果はより大きくなります。WebGPU はコンピュート対応も優れているため、重い解析処理のオフロードに役立ちます。
AI 検索（ChatGPT、Perplexity、Gemini）は WebGL ページを異なる方法でクロールしますか？
はい。AI クローラーは従来の検索より速度と構造化データに厳格です。リッチメディアよりも抽出可能な HTML 回答を好む傾向があります。SSR フォールバックコンテンツや FAQ スキーマがない WebGL サイトは、AI 検索からほぼ完全に見えなくなることが多いです。
Three.js サイトを SEO 最適化するにはどれくらい時間がかかりますか？
既存サイトの場合：遅延 + Worker + モバイルフォールバック + スキーマの完全対応で 2〜4 週間。ゼロから構築する場合：初日からパフォーマンスをブリーフに含めていれば追加時間はゼロ。後付けは常に最初から正しく作るより高くつきます。
3D サイトの SEO と GEO の違いは何ですか？
SEO は従来の検索エンジン（Google、Bing）が対象。GEO は生成 AI エンジン（ChatGPT、Perplexity、Gemini、Claude）が対象。技術的な基礎は重なります — 速い、クロール可能、構造化された情報 — が、GEO は構造化データと権威ある回答をより重く評価します。SEO 最適化された 3D サイトは GEO の 80% は達成済み。残り 20% は FAQPage スキーマ、直接回答コピー、引用しやすいリファレンスです。
すべての 3D サイトにモバイル画像フォールバックを用意すべきですか？
常にではありませんが、ほとんどの場合は「はい」です。例外は 3D 自体がプロダクトであるケース（コンフィギュレーター、3D ビューワーなど）。3D が装飾であるブランドサイトやマーケティングサイトでは、モバイル静止画がほぼ常に Core Web Vitals、コンバージョン、直帰率で勝ちます。
大阪・心斎橋発。記憶に残るWeb体験を。
