GA4のDirect急増はAIに読まれているサインかもしれない
本記事について
この記事は、ENVY DESIGNが自社で観測したGA4の実データをもとに、AIアシスタントのサポートを受けながら執筆しています。AIクローラの技術的な詳細領域には、私自身の知識を超える部分が多く含まれます。一次データの観測と仮説の起点はENVY DESIGN、専門解説と構成のサポートはAIアシスタント、という協働で執筆しました。AI活用時代の象徴的な実例として、執筆方法そのものを開示しています（詳細は記事末尾にて）。
ある朝、GA4からこんな通知が届きました。
「Directチャネルのユーザー予測は6〜47だったのに、実際は55」
数字の正確さよりも、「予測の223%を超えた」という一文が気になって、調べ始めることにしました。結論からお伝えすると、これはAIクローラ、またはヘッドレスブラウザ型の自動アクセスが関与している可能性がある現象でした。そして、過去6ヶ月のデータを振り返ったところ、約1〜2週間に1回のペースで、同じような挙動が観測され続けていたこともわかりました。
この記事では、ENVY DESIGNが運営するサイトのGA4データを6ヶ月分洗い直してわかったことを共有します。「AIに引用候補として調査されているか」をどう観測すべきかを考えている方の参考になれば幸いです。
この記事の結論
時間がない方のために、3行でまとめます。
- 特定時間に集中し、地理分布がクラウド拠点に偏るDirect急増は、AIクローラを含む自動アクセスが関与している可能性がある
- 約1〜2週間に1回のペースで観測されており、自動化された取得対象になっているシグナルとして読める可能性がある
- 従来SEOの「index → rank → click」とは別の、AIO時代のKPI（fetch → reasoning → synthesis → citation）を観測する起点になり得る
1. ある日、GA4から届いた「異常検知通知」
GA4には「上位のハイライト」というBETA機能があり、機械学習が日々のデータを監視して、予測モデルの幅から外れる動きを検知すると通知してくれます。
ENVY DESIGNが運営するサイトに届いた通知は、こんな内容でした。
2026年5月8日（金）
ユーザーの最初のデフォルトチャネルグループ「Direct」のユーザー予測は 6〜47 だったが、実際は 55 で予測を上回った（予測比 +223%）
最初は「広告も打っていないのに、なぜDirectがこんなに増えたんだろう」と素朴に疑問を持った程度でした。営業活動でも、メルマガでも、リアルイベントでも心当たりがありません。
そこで、5月8日のDirect流入を時間別・地理別に分解してみることにしました。
2. 5月8日を分解してみる
時間別に見ると、深夜に異常な集中
| 時刻 | セッション |
|---|---|
| AM 4時 | 30 ← ここに集中 |
| PM 16時 | 6 |
| AM 11時、PM 17時 | 各3 |
| その他の時間帯 | 各1〜2 |
55セッション中、30セッションがAM 4時の1時間に集中していました。これは人間の自然な行動では説明がつきにくい分布です。普通の業務時間や、SNSでバズって深夜に拡散したというパターンでもなさそうでした。
地理別に見ると、クラウドDC集積地が並ぶ
| 国 / 都市 | セッション |
|---|---|
| Japan / 港区 | 33 |
| China / 不明 | 6 |
| 不明 / 不明 | 3 |
| Japan / Fukuoka | 3 |
| Japan / Shibuya | 3 |
| United States / Reston | 2 |
| Singapore | 1 |
港区・Reston・China・Singapore。いずれも大手クラウドプロバイダーのデータセンターやインターネットエクスチェンジが立地することで知られる場所が並んでいる構成でした。
IPジオロケーションの一般原則
「港区が33セッションで最多」と聞いて、「なぜ港区なのか？」と疑問に思われた方もいらっしゃるかもしれません。ここでひとつ、押さえておきたい前提があります。
港区として記録されているからといって、必ずしも港区在住・勤務のユーザーとは限りません。IPジオロケーションは、企業ネットワーク・クラウドサービス・ISP・VPN等の出口所在地として表示されることがあります。GA4の地理レポートに表示されるのは、ユーザーが物理的にいる場所そのものではなく、IPアドレスを引いたときに対応づけられる場所だ、というのが正確な理解です。
このことを踏まえると、5月8日のスパイクの地理分布は次のように読めます。
- 港区・Shibuyaなどは、データセンターや大手キャリアの拠点が集中する都内エリアと重なる
- Reston（バージニア州）は、米国の大手クラウド拠点が立地することで知られる地域
- Singapore・Chinaは、アジア圏のクラウドサーバ出口として観測されやすい
「東京の港区にいる33人」ではなく、「何らかの企業・クラウドネットワークを経由したアクセス33件」と読むのが実態に近い、ということになります。Reston・Singapore・China等の海外クラウド拠点と一緒に並んでいる時点で、純粋な個人ユーザーの自然な分布というよりは、自動化されたアクセスや、クラウド経由のアクセスが一定割合含まれている可能性が高まる構成だと考えられます。
推定される正体：AIクローラの一斉fetch(最有力候補)
ここまでの分析を踏まえると、5月8日 AM 4時の30セッションについては、AIエンジンがリアルタイムにWebをfetchする「AIライブ調査クローラ」の一斉スキャンが最有力候補として浮かびます。
理由は3つです。
- 深夜JSTは米国の昼間時間帯にあたり、米国のAIエンジン稼働ピークと時間帯が重なる
- ヘッドレスChrome実装のクローラは、JavaScriptを実行するためGA4タグが発火し、Directセッションとして記録されやすい
- 港区＋Reston＋海外DCの地理分布は、AWS/GCP/Azure等を経由したアクセスと整合的
ただし、これは断定ではなく最有力候補にすぎません。理論上は、VPN経由の人間アクセス・セキュリティスキャナ・CDNのprefetch・uptime監視ツール・社内ツールの自動巡回など、他にも可能性が残ります。確証を得るには、サーバアクセスログでUser-Agentを直接確認する必要があります。
3. 過去6ヶ月を振り返ったら、25回観測されていた
「これって、5月8日だけの特別な出来事なんだろうか？」
そう疑問に思って、過去6ヶ月分のDirect時間別データを全件洗い直してみました。
結果は、約25回。単一時間に10セッション以上の急増スパイクが、6ヶ月で約25回観測されていました。平均すると7〜8日に1回のペースです。
主なスパイク日のリスト
| 日付 | 時刻 | セッション |
|---|---|---|
| 2025-11-06 | AM 0時 | 89 |
| 2025-11-09 | PM 20時 | 28 |
| 2025-12-05 | AM 6時 | 30 |
| 2025-12-06 | PM 17時 | 28 |
| 2025-12-11 | AM 9時 | 15 |
| 2026-01-07 | PM 20時 | 31 |
| 2026-01-17 | AM 6時 | 38 |
| 2026-01-29 | AM 1時 | 89 |
| 2026-02-06 | PM 16時 | 30 |
| 2026-02-08 | PM 13時 | 30 |
| 2026-02-13 | PM 22時 | 30 |
| 2026-03-08 | AM 4時 | 29 |
| 2026-03-09 | AM 7時 | 21 |
| 2026-04-07 | PM 16〜19時 | 19+14+13 |
| 2026-04-09 | PM 16〜17時 | 13+18 |
| 2026-05-08 | AM 4時 | 30 ← GA4通知の日 |
最大級のスパイクは 11月6日のAM 0時に89セッション、そして1月29日のAM 1時に89セッションでした。30セッション級が6回、10〜25セッション級が17回ほど観測されています。
観察できる3つのパターン
データを並べてみると、いくつかの傾向が浮かび上がってきました。
パターン1：時刻の二峰性
スパイク発生時刻を集計すると、はっきり2つの山ができます。
- 深夜AM 0〜7時帯：12回（48%）
- 夕方PM 16〜20時帯：10回（40%）
- その他：3回（12%）
深夜帯は米国のAIエンジン稼働時間と、夕方帯はユーザーが業務終了後に質問を投げる時間帯と、それぞれ重なりがありそうです。
パターン2：頻度はおよそ週1
完全に定期的ではないものの、長く沈黙する期間がなく、平均すると7〜8日に1回のリズムで観測されていました。
パターン3：曜日にはほぼ偏りなし
火・水・木が比較的多めではありますが、土日にも普通に観測されています。「毎週月曜AM 4時に必ず」といった機械的なスケジュールではなく、複数の自動アクセスが独立した周期で重なっていると考えるのが自然そうです。
4. AI系クローラとSEO系クローラは、別物です
「AIクローラ」と一括りに語られがちですが、実際には目的も挙動もまったく異なる複数のカテゴリが存在しています。整理してみますね。
AI系クローラの3カテゴリ
| カテゴリ | 代表例 | 主な目的 | GA4記録 |
|---|---|---|---|
| AI訓練用 | GPTBot（OpenAI）／ClaudeBot（Anthropic）／CCBot（Common Crawl）／Google-Extended | LLMの学習データ収集 | 乗りにくい |
| AI検索インデックス用 | OAI-SearchBot（ChatGPT Search）／PerplexityBot／Applebot-Extended | AI検索エンジンのインデックス構築 | 限定的 |
| AIライブ調査用 | ChatGPT-User／Perplexity-User／Claude-User | ユーザー質問への回答時のリアルタイムfetch | 乗りやすい |
ここでひとつ、押さえておきたい前提があります。OpenAIは用途別のクローラ／User-Agentを公式に公開しており、GPTBot（AI訓練用）、OAI-SearchBot（AI検索インデックス用）、ChatGPT-User（ChatGPT本体からの fetch）などのUAについて、OpenAI公式のクローラドキュメントに情報が整備されています。Perplexity・Anthropic も同様に、それぞれのbotポリシーを公式に公開しています。
ただし、GA4上で観測されるDirectスパイクと、これらの個別UAを直接対応づけるためには、サーバアクセスログでUAを確認する必要があります。GA4側のレポートデータからは、「どのカテゴリのクローラが、どのくらい寄与しているか」を正確に切り分けることは難しい、というのが実情です。この記事で展開している「AIライブ調査クローラが最有力候補」という見立ても、あくまで地理・時刻分布からの推論であって、UA単位での確定情報ではない点をご留意ください。
SEO系クローラの3カテゴリ
| カテゴリ | 代表例 | 主な目的 |
|---|---|---|
| 検索エンジン | Googlebot／Bingbot | 検索インデックス構築 |
| SEO分析ツール | AhrefsBot／SemrushBot／MJ12bot | 被リンク・キーワード分析 |
| SEO監視ツール | Sitebulb／ScreamingFrogSEOSpider | サイト診断 |
SEO系のほとんどはJavaScriptを実行しない設計になっており、GA4のタグも発火しません。つまり、サーバアクセスログには記録されるが、GA4のセッションとしては計上されないのが一般的な挙動です。
5. なぜ「AIライブ調査クローラ」だけがGA4に乗りやすいのか
GA4に記録されるかどうかは、単純な二値ではなく、複数の要因が絡んでいます。
- ヘッドレスブラウザ実装の有無：JavaScript完全実行できるか
- Cookie受け入れ挙動：GA4のクライアントIDが付与できるか
- GA4側のbot除外フィルタ：自動的にbotとして弾かれていないか
- Consent Modeの状態：ユーザー同意が必要な設定になっていないか
- CDN/WAFのリクエスト処理：Cloudflare等で前段でブロックされていないか
これらの条件を比較的満たしやすいのが、AIライブ調査用とされるクローラ群だと考えられます。ヘッドレスChromeベースで動作するため、通常のブラウザと同じようにJavaScriptを実行し、結果としてGA4のJSタグが発火する、というメカニズムです。
なぜ「Direct」に分類されるのか
ここでもう一歩踏み込んでおきたいのが、「なぜReferralではなくDirectに分類されるのか？」という疑問です。
GA4では、参照元やキャンペーン情報を判定できない流入がDirectに分類されやすいため、ヘッドレスブラウザ型の自動アクセスがDirectとして記録される可能性があります。検索エンジンから来た流入であれば google / organic、SNSから来れば facebook / referral のようにメディアと参照元がセットで記録されますが、AIクローラのfetchはこの情報が空のままサーバに到達するケースが多いんですね。
結果として、ヘッドレスブラウザによるアクセス＋参照元情報の欠落＝Direct計上という構図が成立する、というのが今のところ最も整合的な説明になります。
なお、Directチャネルの増加要因はAIクローラだけではありません。UTMパラメータの欠損・アプリ内ブラウザからの遷移・リダイレクト・Referrer Policyの設定変更などでも、Directは増えます。「Directが急増した = AIクローラだ」と短絡的に解釈するのではなく、今回のように時間帯と地理分布の偏りという複数の傍証が揃って初めて、AIクローラ仮説の有力度が上がる、という構造をご理解いただければと思います。
GA4のbot除外フィルタは万能ではない
「GA4には既知botを除外する機能があるはずだから、AIクローラのアクセスは自動で弾かれるのでは？」という疑問も、もっともです。
実際、GA4にはIAB Spiders & Bots Listベースの既知bot除外機能が標準装備されており、GooglebotやBingbot等の主要な検索エンジンクローラは自動的に除外されるようになっています。Google公式のGA4ドキュメントでも明記されている通り、除外量を確認することも、除外機能をオフにすることもできない仕様になっています。つまり、運用者からは「どれくらいのbotアクセスが、いつ、どのように除外されているか」が見えない仕様になっているわけです。
ただし、ヘッドレスブラウザ型のfetchは「通常のブラウザに極めて近い挙動」を取るため、既知botリストでは完全には除外しきれない可能性があります。User-Agent文字列を通常Chromeに偽装したり、navigatorプロパティを書き換えたり、JavaScript実行のタイミング特性を人間に近づけたりと、検知を避ける方向に技術が進化している領域でもあります。
つまり、GA4で観測されるDirectスパイクには、bot除外を通過してきたヘッドレスブラウザ系のアクセスが一定数含まれている可能性があるということになります。これは「GA4が壊れている」のではなく、そもそもAIクローラ側が通常ブラウザに近づいてきているという時代の変化を反映した現象、と捉えるのが正確かもしれません。
6. AIO時代のKPIは「fetch → reasoning → synthesis → citation」
ここがこの記事で一番お伝えしたいパートかもしれません。
従来SEOの世界では、コンテンツが評価されるプロセスは次のように整理できました。
index → rank → click検索エンジンにインデックスされ、ランキングが付き、ユーザーがクリックする。この3段階それぞれをKPIとして観測するのが、SEO担当者の仕事でした。GoogleサーチコンソールのImpression / Position / Clickは、まさにこの3段階を反映しています。
一方、AI検索（AIO）の世界では、評価プロセスが構造的に変わります。
fetch → reasoning → synthesis → citation- fetch：AIエンジンがサイトを取得しに来る
- reasoning：取得した内容を推論材料として評価する
- synthesis：他の情報源と組み合わせて回答を合成する
- citation：回答の出典として引用される
従来のKPIでは、最初の「fetch」段階を観測する手段がほとんどありませんでした。GoogleサーチコンソールのImpressionは「検索結果に表示された回数」であって、「AIに調査材料として読み込まれた回数」ではありません。
GA4のDirectスパイクは、不完全ながらもこの「fetch」段階のシグナルとして読み解ける可能性があります。「AIに引用候補として調査されているか」を、間接的にではあっても観測する起点になり得る。これがこの現象に注目している理由です。
7. ENVY DESIGNが採っている観測の考え方
ENVY DESIGNが運営するサイトでこの現象を追いかけるにあたって、次のような視点でデータを見ています。
観測すべき4つの軸
(1) Direct時間別の急増スパイク
GA4のレポートで、Directチャネルを時間別に見て、単一時間に10セッション以上が集中していないかをチェックします。
(2) 地理分布の偏り
スパイク発生時の地理分布が、港区・Reston・海外DC等のクラウドプロバイダー集積地に偏っていないかを見ます。一般ユーザーの自然な分布とは明確に異なる傾向が出ます。
(3) ChatGPT/Perplexity からの参照流入
GA4の参照元レポートで、chatgpt.com perplexity.ai などからの流入を継続観測します。これがfetch → citationまで到達した結果として、最終的なKPIになります。
(4) サーバアクセスログのUser-Agent
本格的に確証を取りたい場合は、サーバ側のアクセスログを直接見て、ChatGPT-User PerplexityBot ClaudeBot などのUAが実際に来ているかを確認します。ここまで踏み込んで初めて、「AIクローラ仮説」が確定情報になります。
より高度な分析（AI fetch intelligence）
サーバログだけでなく、複数シグナルを組み合わせると、識別精度が大きく上がります。実務的に高度な観測をするなら、次のような分析軸が考えられます。
- ASN分析：IPから所属ASNを引いて、本当にOpenAI/AWS/GCP由来かを検証
- JA4 / TLS fingerprint：TLS handshakeの指紋からヘッドレスChromeを識別
- fetch depth：1セッションで何ページ取得したかの分布
- render timing：レンダリング完了までの所要時間特徴
- headless browser特徴：
navigator.webdriver等のシグナル - sec-ch-ua / Accept-Language / viewport：ヘッダ・画面情報の組み合わせ
ここまで揃えると、「ENVY DESIGNが運営するサイトがどのAIエンジンに、どの頻度で、どの深さで読まれているか」を実データで観測できる、いわばAI fetch intelligenceと呼べる領域になっていきます。日本国内ではまだ言語化が進んでいない観測領域です。
8. 観測されていることをどう捉えるか
「クローラに巡回されまくっているのって、サーバ負荷的に大丈夫なのか？」と心配される方もいらっしゃるかもしれません。ENVY DESIGNの観測では、少なくとも、自動化された取得対象になっている可能性があるという観測シグナルとして、前向きに扱える現象だと捉えています。
理由を整理します。AIエンジンが回答生成時にWebをfetchする際、無作為に全ドメインを見に行くわけではなく、何らかの基準で「回答材料として有用かもしれない」と判断したサイトを優先的に取得する設計になっていると考えられます。つまり、定期的に何らかの自動アクセスを受けている事実は、運営しているサイトが自動取得の対象リストに含まれている可能性があるという間接的なヒントになり得る、ということです。
ただし、注意点もあります。
- 観測されている = 引用候補に入っている、とまでは断定できない
- fetchされたコンテンツが推論材料として評価され、合成回答に組み込まれ、最後に出典として引用されて、ようやくサイクルが完結する
- それでも、最初のfetch段階で観測されていない状態よりは、観測されている状態の方が一歩前に進んでいる可能性が高い、という相対比較は成立しそう
「観測されている＝引用される」ではなく、「観測されている = 引用への入口に到達している可能性」と読むのが、現時点では最も妥当な解釈だと考えています。
AIに引用される可能性を高めるサイト構築をご検討の方へ
ENVY DESIGNでは、AIO・GEO・LLMOの観点を組み込んだコーポレートサイト制作・採用サイトのリニューアルを支援しています。「自社サイトはAIに観測されているのか」「どう改善すれば引用候補に入りやすくなるのか」といったご相談も歓迎しています。お気軽にお問い合わせください。
9. 自社サイトで、まず何を見るべきか
最後に、ご自身のサイトでこの現象を観測してみたい方に向けて、最小限のアクション手順をまとめます。
ステップ1：GA4で過去30日のDirect時間別を見る
GA4の「探索」→自由形式レポートで、ディメンションに「時間」、指標に「セッション数」、フィルタに「最初のユーザーのデフォルトチャネルグループ＝Direct」を設定します。
ステップ2：10セッション以上の集中があるか確認
単一の時間（1時間枠）で10セッション以上が集中している日があれば、それがスパイク候補です。深夜帯（AM 0〜7時）と夕方帯（PM 16〜20時）に偏っていれば、自動アクセスの可能性が高まります。
ステップ3：地理分布をチェック
スパイクが起きた日の地理レポートを見て、港区・国外データセンター系の地名（Reston / Ashburn / Singapore / China等）が混ざっていないかを確認します。
ステップ4：参照流入を継続観測
ChatGPT・Perplexity からの参照流入が、スパイクの数日後に増えていないかを観測します。fetch → citationの因果系列の仮説検証になります。
ステップ5：サーバログでUA確認（任意・確証取りたい場合）
本気で確証を取りたい場合は、サーバアクセスログで ChatGPT-User PerplexityBot などのUAを直接確認します。レンタルサーバの管理画面からダウンロードできることが多いです。ここまで踏み込んで初めて、AIクローラ仮説は確定情報になります。
まとめ
GA4の異常検知通知をきっかけに、ENVY DESIGNが運営するサイトで観測した内容を共有してきました。
- 特定時間に集中し、地理分布がクラウド拠点に偏るDirect急増は、AIクローラを含む自動アクセスが関与している可能性がある
- 約1〜2週間に1回という頻度で観測されており、自動化された取得対象になっているシグナルとして読める可能性がある
- 従来SEOの「index → rank → click」だけでなく、AIO時代の 「fetch → reasoning → synthesis → citation」 という新しいKPI構造を意識する必要がある
- 最初の 「fetch」段階を観測する手段として、GA4のDirectスパイク分析は実用的な手がかりになり得る（ただし確証にはサーバログ確認が必要）
派手な施策ではありませんが、自社サイトがAI検索エコシステムの中でどう扱われている可能性があるかを観測することは、AIO戦略を組み立てる上での重要な起点になります。AI Overviews・ChatGPT・Perplexityからの引用獲得を本気で狙うなら、まずは「今、自社サイトはAIに観測されている可能性があるのか？」というシンプルな問いから始めてみてはいかがでしょうか。
本記事の執筆について
本記事は、ENVY DESIGNが運営するサイトで実際に観測したGA4データをもとに、AIアシスタントとの協働で執筆しました。
- 一次データ（GA4の6ヶ月実測値・地理分布・時間別分布）の観測と検証：ENVY DESIGNが実施
- 「これはAIクローラかもしれない」という仮説の起点：GA4の異常検知通知を受けてENVY DESIGNが着想
- クローラ技術の専門解説（ChatGPT-User / ヘッドレスChrome / ASN分析等）と記事構成のサポート：AIアシスタントを活用
正直にお伝えすると、AIクローラの技術的な詳細領域は、私自身の理解と知識を超えるところがありました。一次データを観測している立場として、その意味を正しく言語化するには、AIのサポートを得ることが最も適切な選択だと判断しました。
これからのAIO時代、「AIをどう活用するか」だけでなく「AI活用そのものをどう開示するか」も、企業の透明性として問われていく領域だと考えています。本記事の構成自体が、ひとつの実例になれば幸いです。
よくあるご質問（FAQ）
Q. GA4の「上位のハイライト」通知は、毎回チェックすべきですか？
A. Directチャネルの急増通知については、基本的にスルーで問題ないケースが多いと考えています。多くの場合、自動化されたアクセスが関与している可能性があるため、サイト運営上のアクションが必要なケースはほとんどありません。ただし、89セッション級の極端なスパイクが出た場合は、その日のサーバログを確認しておく価値はあります。
Q. AIクローラのアクセスは、サーバ負荷的に問題になりませんか？
A. 通常のCMS（WordPress等）でレンタルサーバを利用している前提では、月数十回程度の自動アクセスでサーバ負荷が問題になることは、ほぼないと考えてよいです。気になる場合は、robots.txtで個別のクローラを拒否することも技術的には可能です。ただし、対象クローラから取得されにくくなるため、AI検索・引用候補として扱われる機会が減る可能性があります。
Q. ChatGPTやPerplexityからの参照流入は、どう観測すればよいですか？
A. GA4の「集客」→「ユーザー獲得」→「セッションの参照元 / メディア」で、chatgpt.com / referral や perplexity.ai / referral を継続観測するのが基本です。実数はまだ少ない傾向にありますが、1ヶ月単位の推移を見ていくと、コンテンツ施策の影響が見えてきます。
Q. AI訓練クローラ（GPTBot等）は拒否すべきですか？
A. 「自社コンテンツをLLMの学習に使われたくない」というポリシーがあれば、robots.txt で GPTBot ClaudeBot CCBot を拒否することは技術的に可能です。一方で、長期的にはAIエコシステムへの組み込みが認知獲得につながる可能性もありますので、戦略次第の判断になります。OAI-SearchBot PerplexityBot などのAI検索インデックス用クローラは、引用候補に入る可能性を残すために許可するケースが多いです。
Q. AIに引用される回数を、もっと直接的に観測する方法はありませんか？
A. 現時点では、AIエンジン側が「どのサイトを何回引用したか」を公開する仕組みは整っていません。間接的な観測手段としては、(1) GA4のDirectスパイク、(2) ChatGPT/Perplexityからの参照流入、(3) 自社サイトを実際にAIに質問してみて引用されるか確認、の3つを組み合わせるのが現実的です。継続観測することで、コンテンツ施策の効果を読み解いていけます。
ENVY DESIGNでは、AIO・GEO・LLMO の観点を組み込んだコーポレートサイト制作・採用サイト制作をご支援しています。「AIに引用候補として認識される可能性を高めるサイト構築」にご関心のある方は、お問い合わせフォームからお気軽にご相談ください。
AIO・GEO対策の全体像はAI検索最適化（AIO・GEO）サービスのページで整理しています。あわせて、以下の記事もご用意しています。
AI検索からの流入を実際に計測する手順は、AI検索（ChatGPT等）からの流入はどうやって確認できますか？で簡潔にまとめています。
出典
- Schema.org（構造化データの公式仕様）
- Google Search Central（検索・構造化データの公式情報）
- Web Vitals（Core Web Vitalsの公式定義）
- Google検索公式ブログ（AI Overview等の発表情報）
関連記事