URLを入れるだけでSEOとGEOを実測診断する自作GASアプリはClaude Fableと一緒に作りました、想像以上の出来でした

今回は「URLを入れるだけで、SEOスコアとGEOスコア（AI検索への最適化度）を実測データで診断してくれるGASアプリ」を自作した開発記です。Google AI Studioでの試作から始まり、GASへの移植、WAFとの格闘、GA4・サーチコンソール連携まで、つまずきポイントも含めて包み隠さず紹介します。
今回の相棒に選んだのはAnthropicの最新モデルClaude Fable 5です。汎用AIのコードでは越えられなかった壁を、原因究明から対策までワンストップで越えてくれました。

分析アプリは「持っておく」だけで経営の武器になる

先に結論です。中小企業のWEB担当者こそ、自社専用の分析アプリをGoogle Apps Script（GAS）で1本持っておくことをおすすめします。理由は3つあります。

1つめ、無料で動くこと
GASはGoogleアカウントがあれば追加費用なしで使えます。今回のアプリもサーバー代はゼロ円、AI解説に使うGemini APIも無料枠の範囲で収まる程度の消費です。

2つめ、実データで判断できること
世の中のSEO診断ツールは便利ですが、自社のGoogleアナリティクス（GA4）やサーチコンソール（GSC）の生データと突き合わせて診断してくれるものは、有料ツールでもなかなかありません。自作なら、自社のデータに直結できます。

3つめ、「いつでも気軽に」測れること
ツールが手元にあると、施策の前後でスコアを測る習慣ができます。今回のアプリで当ブログ（dm2.co.jp）を診断したところ、ChatGPTやPerplexityなどAI経由の流入が前年同期の537セッションから今期1,339セッションへ、約2.5倍に増えていることが実測できました。感覚ではなく数字で「AI検索対策（GEO）が効いている」と確認できたのは大きな収穫でした。

そもそもGEOとは？──SEOの次に来る「AI検索への最適化」

GEO（Generative Engine Optimization）は、ChatGPT・Perplexity・GoogleのAIによる概要（AI Overviews）といった生成AI検索に、自社サイトの情報を「引用してもらう」ための最適化です。AEO（Answer Engine Optimization）と呼ばれることもあります。

従来のSEOがGoogleの検索結果で上位表示を狙うのに対し、GEOはAIが回答を組み立てるときの「参照元」に選ばれることを狙います。具体的には次のような要素が効くとされています。

• JSON-LDなどの構造化データ（AIがページ内容を正確に理解する土台）
• robots.txtでAIクローラー（GPTBot、ClaudeBot、PerplexityBotなど）を許可していること
• llms.txtの設置（サイト概要と主要ページをAI向けに宣言する新しい標準）
• 数値・データの密度が高いこと（AIは具体的な事実を引用したがる）
• 著者・更新日などのE-E-A-Tシグナル

問題は、これらが「できているかどうか」を確認する手軽な方法がなかったこと。そこで、URLを入れるだけでSEOとGEOの両方を採点するアプリを作ることにしました。

試作はGoogle AI Studioで10分──でも実務には使えなかった

最初の試作はGoogle AI Studioで行いました。

Google AI Studio

The fastest path from prompt to production with Gemini

aistudio.google.com

「URLを入れるだけで主要なSEOやGEOスコアを表示するアプリを作成してください」とプロンプトを入れると、約6分でReact製のダッシュボードアプリが生成されました。見た目は文句なしにかっこいい。ここまでは感動です。

しかし、触っているうちに実務では使えないことがわかってきました。致命的だったのはスコアの信憑性です。

AI Studio版は、Gemini自身が「それらしいスコア」を生成する仕組みでした。同じサイトを測っても実行のたびに点数が変わりますし、根拠を聞かれても答えられません。お客様に「あなたのサイトは62点です」と言うからには、なぜ62点なのかを説明できなければ診断とは呼べません。

さらにAPIのクォータ制限（無料枠の上限）に達すると分析が止まり、AIが代替のダミーデータを「それらしく」表示する修正が入ってしまう始末。デモとしては面白いのですが、これは分析アプリではなく「分析アプリ風の映像」です。

設計方針の大転換：「AIにスコアを作らせない」

そこで、普段から業務アプリの基盤にしているGASで独立アプリとして作り直すことにしました。このとき決めた設計方針が、今回の開発でいちばん重要なポイントです。

スコアはルールベースで決定論的に算出し、AIには「解釈」だけをさせる。

つまり役割分担を逆転させました。整理すると次の3層構造です。

• スコア層：対象ページを実際にクロールし、titleタグ・見出し階層・JSON-LD・robots.txtのAIクローラー許可状況・llms.txtの有無などをチェックリスト方式で採点（SEO14項目・GEO11項目、各100点満点）。同じ状態のサイトなら何度測っても同じ点数
• 裏付け層：GA4 APIから自然検索セッションの前年比較とAI経由流入の実数、GSC APIから検索クエリ・平均掲載順位・CTRを取得してスコアに反映
• 解釈層：Gemini APIには実測結果だけを渡し、コメントと改善提案のみを生成させる。プロンプトで「スコアの数値は変更・再計算しないこと」と明示的に禁止

Geminiに渡すプロンプトの核心部分はこうなっています。

【重要ルール】
・スコアの数値は変更・再計算しないこと（実測によるルールベース採点のため）。
・事実データに無いことを推測で断定しない。
　仮説の場合は「〜の可能性があります」と表現する。
・改善提案は中小企業のWEB担当者が自力で実行できる具体性で書く。

生成AIは便利ですが、数字を任せると「もっともらしい嘘」をつきます。数字は機械的に測り、言葉はAIに任せる。この線引きが、AI活用ツールの信頼性を分ける分水嶺だと考えています。

コード解説①：robots.txtからAIクローラーの許可状況を判定する

GEO診断の根幹が、robots.txtの解析です。GPTBot（ChatGPT）、ClaudeBot（Claude）、Google-Extended（Gemini学習）、PerplexityBot、CCBot（Common Crawl）の5種類について、ブロックされていないかを実測判定します。

const aiBots = [
  { name: 'GPTBot', label: 'ChatGPT (OpenAI)' },
  { name: 'ClaudeBot', label: 'Claude (Anthropic)' },
  { name: 'Google-Extended', label: 'Gemini学習 (Google)' },
  { name: 'PerplexityBot', label: 'Perplexity' },
  { name: 'CCBot', label: 'Common Crawl' }
];

// robots.txt から特定ボットがブロックされているか判定
function isBotBlocked_(robotsTxt, botName) {
  const lines = robotsTxt.split(/\r?\n/);
  let currentAgents = [];
  let inRelevantGroup = false;
  let blocked = false;
  for (let i = 0; i < lines.length; i++) {
    const line = lines[i].replace(/#.*$/, '').trim();
    if (!line) continue;
    const uaMatch = line.match(/^user-agent:\s*(.+)$/i);
    if (uaMatch) {
      // User-agent行のグループを識別して対象ボットか判定
      currentAgents.push(uaMatch[1].trim().toLowerCase());
      inRelevantGroup =
        currentAgents.indexOf(botName.toLowerCase()) !== -1;
      continue;
    }
    if (inRelevantGroup) {
      if (/^disallow:\s*\/$/i.test(line)) blocked = true;
      if (/^allow:\s*\/$/i.test(line)) blocked = false;
    }
  }
  return blocked;
}

ポイントは、robots.txtの「User-agentのグループ構造」を正しく解釈していることです。robots.txtは複数のUser-agent行が1つのルールグループを共有できる仕様なので、単純な文字列検索では誤判定します。せっかく良質なコンテンツを持っていても、robots.txtでAIクローラーを締め出していたらGEOは始まりません。まずここを実測で確認できるのは大きいです。

コード解説②：GA4からAI経由の流入を前年比較で取り出す

GEO施策の効果測定でいちばん説得力があるのは「AI経由で実際に何人来たか」です。GA4のsessionSourceディメンションから、AI系サービスの参照元を正規表現で拾い上げます。しかも1回のAPIコールで今期と前年同期を同時に取得できるのがGA4 Data APIの便利なところ。

const aiReq = {
  dateRanges: [
    { startDate: curStartStr, endDate: curEndStr },   // 今期1年
    { startDate: prevStartStr, endDate: prevEndStr }  // 前年同期
  ],
  dimensions: [{ name: 'sessionSource' }],
  metrics: [{ name: 'sessions' }],
  limit: 1000
};
const aiResp = AnalyticsData.Properties.runReport(
  aiReq, 'properties/' + propertyId);

// AI系サービスの参照元を正規表現で判定
const aiPatterns =
  /(chatgpt|openai|perplexity|gemini\.google|claude|copilot)/i;

dateRangesを2つ渡すと、結果の各行に「どちらの期間か」を示す値が付いて返ってきます。これを振り分けることで「openai：今期531（前年0）」「chatgpt.com：今期392（前年227）」のような参照元別の前年比較テーブルが作れます。当サイトの実測では、AI経由流入の合計が前年同期537→今期1,339セッション。前年比249%という数字は、GEOという言葉がバズワードではなく実体を持ち始めた証拠だと感じます。

コード解説③：WAFに勝つ「4段階フォールバック」クロール

ここからが、汎用AIのコード生成では越えられなかった壁の話です。

アプリを最初にデプロイして自社サイトを診断したら、いきなり「HTTP 501」エラー。他のサイト（isico.or.jpなど）は正常に診断できるのに、肝心の自社サイトだけ取得できません。

原因は、レンタルサーバー（当サイトはエックスサーバー）のWAF（Web Application Firewall）でした。GASのUrlFetchAppはGoogleの米国データセンターから発信され、しかもUser-Agentヘッダーの上書きが効かないという既知の制約があり、サーバー側からは「Google-Apps-Script」という機械的なアクセスに見えます。

日本のレンタルサーバーのWAFはこれをbotと判定して501や403で弾くことがあるのです。エックスサーバーやさくらインターネットの利用者なら、同じ壁に当たる可能性が高い、いわば「日本のGAS開発あるある」です。

対策として実装したのが、4段階のフォールバック戦略です。

const strategies = [
  { label: '①ブラウザ風ヘッダー', url: url,
    options: { headers: browserHeaders } },
  { label: '②最小ヘッダー', url: url, options: baseOpts },
  { label: '③www切替', url: toggled,
    options: { headers: browserHeaders } },
  { label: '④プロキシ経由', url: 'https://r.jina.ai/' + url,
    options: { headers: { 'X-Return-Format': 'html' } } }
];

for (let i = 0; i < strategies.length; i++) {
  const st = strategies[i];
  const response = UrlFetchApp.fetch(st.url, st.options);
  const code = response.getResponseCode();
  Logger.log('[crawl] ' + st.label + ' → HTTP ' + code);
  if (code >= 200 && code < 400) {
    // 取得成功。HTMLの解析処理へ
    return parseHtml_(url, response.getContentText(), ...);
  }
}

直接アクセス→ヘッダー変更→www有無の切替→それでもダメならプロキシサービス（Jina Reader）を経由してブラウザとして取得、という順に粘ります。プロキシ経由になった場合は応答速度の採点を「参考値」に切り替える処理も入れました。取れないデータをでっち上げるのではなく、取り方を変えて実測を貫く。この設計思想は、AI Studio版が「エラー時はダミーデータを表示」で誤魔化したのと対照的です。

robots.txtとllms.txtの取得は、さらに強化して5段階（AllOriginsプロキシを追加）にしました。実行ログにはこう出ます。

[textfile] ①ブラウザ風 → HTTP 501 スキップ（HTTPエラー）
[textfile] ②最小ヘッダー → HTTP 501 スキップ（HTTPエラー）
[textfile] ③www切替 → HTTP 501 スキップ（HTTPエラー）
[textfile] ④AllOriginsプロキシ → HTTP 200 取得成功（3349文字）

直接アクセスは3連敗でも、4番手のプロキシが仕事をしてllms.txt（3,349文字）を取得できています。野球でいえば、先発が打たれても中継ぎ・抑えで勝ち切る継投策です。

汎用AIとClaude Fableの違いは「不具合対応」に出る

正直に言うと、「動くコード」を書くだけなら今どきのAIはどれもそこそこできます。差が出るのは不具合が起きたときです。今回の開発では、コード生成以外にこんなトラブルシューティングがありました。

• HTTP 501エラーから「WAFがGASのUser-Agentに反応している」と原因を推定し、User-Agent上書きが効かないというGASの既知の制約まで踏まえてフォールバック戦略を設計
• サーチコンソール連携の403エラーで、エラーJSONの「SERVICE_DISABLED」という記述から「スコープ不足ではなくGoogle Cloud側でAPIが無効」と切り分け。GASのデフォルトGCPプロジェクトはユーザーが操作できない仕様なので、標準プロジェクトへの付け替え手順まで提示
• llms.txtを設置したのに0点のままだった件では、「GA4に登録されたURL（www無し）と実サイトの正規URL（www有り）のホスト名ミスマッチ」を特定し、クロールで検出したcanonicalのホストを優先する修正
• AI解説のキャッシュが古い診断結果を表示し続ける問題には、キャッシュキーに監査結果のフィンガープリント（スコア＋全項目の判定）を含めて、結果が変わったら自動で再生成される設計に変更

どれも、エラーメッセージの表面ではなく仕組みの理解が要る問題です。切り分け用のデバッグ関数（testCrawl、testGsc、testTextFiles）を先に用意して、実行ログから原因を一発特定できる体制を組んでくれたのも実務的でした。

「エラーが出ました」とログを貼るだけで、原因の解説と修正コードが返ってくる。この往復の速さと精度が、Claude Fable 5を選んだ理由であり、期待以上だった点です。

診断してわかった自社サイトの現在地

さて、実際に完成した「SEO＆GEO分析」アプリを実施に使いました。自分が管理しているGA4のプロパティを使えばGoogleAnalyticsのデータも分析に使います。また、管理していないサイトでもURLを直接入力すると分析可能なように作ってあります。

まずは、自社サイト「dm2.co.jp」の分析です。

完成したアプリで当サイトを診断した結果は、総合90点（SEO:79点・GEO:100点）でした。GEOが100点満点なのはちょっとした驚きでした。

GEO側はJSON-LD・ファクト密度（本文1,000文字あたり約120個の数値表現）・E-E-A-Tシグナルなどが満点評価。一方でSEO側は、画像130枚中altが設定されているのは30枚（23%）で0点、titleタグが57文字で長すぎ、見出し階層の飛びが1箇所と、基礎的な部分に宿題が残りました。

面白いのは、AI経由流入2.5倍という「攻めのGEO」が好調な一方で、alt属性という「守りの基本」が抜けていたこと。診断ツールの価値は、こういう自分では気づかない凸凹を数字で突きつけてくれるところにあります。

改善アクションは優先度付きで7項目がリストアップされ、レポートはそのままPDFで出力できます。レポート下部にはAIチャット欄も付けたので、「altはどこから直すべき？」と聞けば実測データを根拠に答えてくれます。

このGASアプリは、GoogleAnalyticsGA4のデータもGoogleSearchConsoleのデータも読み込んでいますので、数字的には曖昧さがありません。グラフも表示できます。

中小企業がこの手のアプリを持つ意味

中小企業診断士としての視点でまとめると、この取り組みの本質は「分析の内製化」です。

SEO診断を外注すれば1回数万円から数十万円。有料の分析ツールは月額1万円前後が相場です。それが、GAS＋Gemini APIならほぼゼロ円で、しかも自社のGA4・GSCの生データに直結した診断が何度でも回せます。施策のたびに気軽に測れるから、PDCAの回転が速くなる。これが最大の効能です。

そして開発のハードルは、AIの進化で劇的に下がりました。今回のアプリはコード約1,200行の本格的なものですが、私自身は一行も手書きしていません。やったことは「何を測りたいか」「なぜその数字が信頼できる必要があるか」を言葉で伝え、エラーが出たらログを貼ることだけ。

人間が方針と判断基準を示し、AIが実装と原因究明を担う。この役割分担ができれば、専任のエンジニアがいない中小企業でも、自社専用の業務アプリは十分に内製できます。

ただし相棒選びは重要です。試作の速さなら汎用AIで十分ですが、実務投入するアプリの品質——エラー処理、フォールバック、デバッグのしやすさ——まで求めるなら、コードに強い最上位モデルを使う価値があります。今回それがClaude Fable 5だった、というのが本記事の種明かしです。

AIを使えば自分専用のアプリが簡単に作れる時代

URLを入れるだけでSEOとGEOを実測診断するGASアプリを、Claude Fable 5と二人三脚で作りました。AI Studioでの試作は10分、実務に耐えるGASアプリへの昇華と不具合対応で正味1日。その過程で、WAFの壁、APIの承認の壁、キャッシュ設計の壁をすべて越え、副産物として「AI経由流入が前年比2.5倍」という自社のGEO成果まで実測できました。

分析は、道具が手元にあるほど習慣になります。まずは自社のGA4を眺めることから、そして次の一歩として「自社専用の分析アプリを1本持つ」ことを、ぜひ検討してみてください。作る過程そのものが、AI活用の最高の実地研修になります。

※この記事はGASコードを開発した流れで「Claude Fable 5」を使い記述しました。その後、遠田幹雄本人が目視で文章をチェックしてから公開しています。