目視観察だけでは見えなかったものが、Pythonで数値化することで輪郭を持ち始めた。4パターンのクエリ×49URLを解析した結果、技術系クエリではコードブロックと表が突出して多く、企業メディアの6割で著者情報が明記されていた。ただしデータには外れ値・ノイズが混在しており、これは「完成された答え」ではなく「次の実験への足がかり」だ。
前回の実験では、Perplexityに4種類のクエリを投げて引用元を目視で分類した。クエリの種類によって引用元ドメインの構成比が変わることは確認できた。しかし「なぜ変わるのか」という問いには答えられなかった。
目視でサイトを見て「文字数が多い」「見出しが細かい」と感じても、それが再現性のある傾向なのか、たまたまそうだったのかを区別できない。各パターン1回ずつの観察では、統計的な裏付けにはならない。
「コードブロックの数」「表の数」「著者情報の有無」といったページの構造的特徴は、目視では正確にカウントできない。これらを数値として取り出すために、PythonでHTMLの構造を定量化することにした。
プログラミングの経験はほぼない。それでもChatGPTをパートナーにすれば、解析ツールを手に入れられることがわかった。
「こういうものを作りたい」という曖昧な要件からコードを生成する対話の流れと、「ここを直して」「こう変えたい」と会話しながらコードを育てていける感覚が、非エンジニアの自分には合っていた。
Claudeはコードの構造を整理したり精度を上げる場面では強みを発揮するが、「ゼロから動くものを作る」という用途では、今回の用途ではChatGPTの対話型生成の方が使いやすかった。これ自体も一つの観察記録だ。
ChatGPTに「URLのリストからHTMLを取得して構造的な指標をCSVに出力するスクリプトを作って」と依頼した。使用ライブラリはrequestsとBeautifulSoup4。実行環境はJupyter Notebook。エラーが出るたびにエラー文をそのまま貼り付けて修正を繰り返す「対話による開発」で完成させた。
今回のスクリプト（v3）で取得した指標は以下の通り。
| 指標 | 内容 |
|---|---|
| total_chars | 本文文字数 |
| h3_count | h3見出し数 |
| lead_200_has_conclusion | 冒頭200字以内の結論有無 |
| heading_opener | 見出しの文体分類 |
| qa_pairs_total | QAペア数 |
| published_time | 公開日 |
| modified_time | 更新日 |
| has_byline | 著者情報の有無 |
| img_count | 画像数 |
| table_count | 表数 |
| code_block_count | コードブロック数 |
| external_link_count | 外部リンク数 |
SNS系URL（LinkedIn・X・YouTube等）はサイト仕様上取得できないためスキップ。有効データは49URLのうち47件となった。
第2回の目視観察で得た分布を、今回のPython解析データで確認した。この指標は目視とPythonで取得方法が変わらないため、今回のデータでも信頼性が高い。
| クエリパターン | 企業メディア | SNS | 公式ドキュメント | 技術者ブログ | 個人ブログ |
|---|---|---|---|---|---|
| A（直接比較） | 70% | 10% | 10% | 0% | 10% |
| B（ペイン解決） | 58.3% | 41.7% | 0% | 0% | 0% |
| C（トレンド・事例） | 92.3% | 0% | 0% | 0% | 7.7% |
| D（技術・保守性） | 21.4% | 0% | 50% | 28.6% | 0% |
※BパターンのSNSはHTML構造上取得不可のため構造分析の対象外
今回のPython解析でも、第2回と同様のドメイン分布が確認された。A（直接比較）では企業メディア70%、D（技術・保守性）では公式ドキュメント50%と技術者ブログ28.6%という構成は、目視観察と一致している。
この一致から、「キーワードではなく問いの性質が引用先を決める」という仮説は、今回のデータでも棄却されなかった。ただし同一テーマ・同一時期のデータであるため、独立した検証とはなっていない点に注意が必要だ。
技術・保守性クエリ（パターンD）で引用されたサイトの構造を見ると、他のパターンと明確に異なる特徴が出た。
| ドメイン種別 | コードブロック数（平均） | 表数（平均） |
|---|---|---|
| 企業メディア（全体） | 0.9 | 1.8 |
| 公式ドキュメント | 1.2 | 0.0 |
| 技術者ブログ | 25.3 | 10.3 |
| パターンD全体 | 6.7 | 2.9 |
技術者ブログのコードブロック数（平均25.3）と表数（平均10.3）は、他のドメインと比べて突出している。企業メディア全体の平均がコードブロック0.9・表1.8であることと比較すると、その差は明確だ。
この結果から、技術的な実装を問うクエリに対して、Perplexityはコードや比較表で情報を示すサイトを優先的に選んでいる可能性が考えられる。ただし今回のサンプル数（技術者ブログ4件）は少なく、傾向として参考にとどめる必要がある。
今回の観察から「技術的なクエリに引用されたい場合、コードブロックと表形式の情報整理が重要な要素になりうる」という仮説が立てられる。確信度はR8として「高」と分類しているが、BtoB技術領域限定のデータである点は留保が必要だ。
著者情報（byline）と公開・更新日のデータから、いくつかの傾向が見えた。
解析結果として、企業メディアの60%（30件中18件）で著者名が明記されていた。公式ドキュメントは11件中0件と、著者情報の明記率はゼロだった。
| ドメイン種別 | 有効記事数 | 著者情報あり | 比率 |
|---|---|---|---|
| 企業メディア | 30件 | 18件 | 60.0% |
| 技術者ブログ | 4件 | 2件 | 50.0% |
| 個人ブログ | 2件 | 1件 | 50.0% |
| 公式ドキュメント | 11件 | 0件 | 0.0% |
この差について考察すると、公式ドキュメントは「ドメイン自体が信頼性のシグナル」として機能しているため、個人の著者情報を必要としていない可能性がある。一方、企業メディアでは「誰が書いたか」がE-E-A-T（経験・専門性・権威性・信頼性）の観点から引用判断に影響している可能性が考えられる。
取得できた企業メディアの更新日データを見ると、パターンA（直接比較）の平均経過日数は約70日、パターンD（技術・保守性）は約57日だった。一方、パターンB（ペイン解決）は約159日と相対的に長かった。
この数値から、比較・技術系クエリで引用される企業メディアは、ペイン解決系より更新が新しい傾向が見られた。ただし日付データが取得できた件数はパターンAで3件・Dで1件と少なく、統計的な裏付けとしては弱い。
今回のデータ全体を見渡すと、Perplexityが引用するページには大きく3つのタイプがあることが見えてきた。
①実務解説型（パターンAに多い）
h2/h3がある・画像や表もある・ある程度の文字数がある・著者情報あり。企業メディアが中心で、自分たちが再現しやすいタイプ。
②権威・一次情報型（パターンDに多い）
公式ドキュメント・公式ブログ・技術者ブログ・PDF資料など。構造だけでなく「情報源としての信頼性」が引用に効いている可能性が高い。
③大規模ページ型（パターンCに混在）
文字数が極端に多く・画像・リンクが多い・QAペアが多数検出される。ただしこのタイプは「記事」ではなく一覧ページ・サービスページが混入している可能性が高い。GEO記事設計の参考にするには注意が必要なタイプだ。
今回の解析結果には、無視できない問題が複数含まれている。数値を読む前に、この限界を整理しておく必要がある。
| 信頼度 | 指標 | 理由 |
|---|---|---|
| ◎ 信頼できる | クエリ意図×ドメイン分布 | 複数回観察・外れ値なし |
| ◎ 信頼できる | 技術系のコードブロック・表の多さ | パターン間の差が明確 |
| △ 方向性は参考 | 著者情報の比率 | 他ドメインのサンプルが2〜11件 |
| △ 方向性は参考 | 情報鮮度 | 日付取得できた件数が少ない |
| △ 方向性は参考 | 画像数・外部リンク数 | HTML全体カウントのノイズあり |
| × 判断保留 | SNS系の構造 | 取得不可 |
| × 判断保留 | パターンCの平均値 | 一覧ページ混入 |
| × 判断保留 | パターンDの文字数 | PDF混入 |
データセットにPDFファイルと一覧ページが混入しており、特にパターンDの文字数平均が歪んでいる可能性がある。また画像数・外部リンク数はHTML全体をカウントしているため、ヘッダー・フッター・サイドバーの要素が混入している。個人ブログの外部リンク数が平均221件という数値は、この問題の典型例だ（note：333件・はてなブログ：109件）。
もう一つの限界を正直に書く。
今回取得した指標のほとんどは、従来のSEO評価でも使われてきた指標と重複している。文字数・見出し数・更新日・著者情報・画像数・外部リンク数。これらはHTMLから機械的に取得できる要素だ。
問題は「取得しやすいものを取得した」という設計になってしまったことにある。「GEOで引用されやすいサイトの何を測るべきか」という問いから逆算して指標を設計していれば、別の指標が浮かび上がったはずだ。
GEO固有の可能性がある指標として、現時点で考えられるのは以下だ。
しかしこれらは、HTMLタグを数えるだけでは測定できない。コンテンツの意味的な特性であり、テキスト解析が必要になる。
そして、より根本的な問いが自分の中に残っている。
「SEOとGEOの指標は本当に別物なのか」
SEO的に評価されるサイトがGEO的にも評価されるのか、それとも別の法則が働いているのか。今回の解析だけでは、その答えは出なかった。これが第4回以降の実験テーマになる。
ChatGPTと合意した次回改善項目は以下の通り。
第2回の目視観察と今回のPython解析を合わせた時点での暫定GEOルール候補を整理する。「候補」であり「確定ルール」ではない点に注意。
| ルール | 内容 | 根拠 |
|---|---|---|
| R1 | クエリ意図に合わせたドメインとフォーマットの選択 | 全パターンのドメイン分布 |
| R2 | 比較・事例コンテンツにおけるh3の深い階層化 | パターンA・C企業メディアの平均h3数 |
| R3 | ブログ記事における冒頭200文字での結論提示 | lead_200_has_conclusion |
| R4 | 10,000〜15,000文字の適度な網羅性 | 引用元の文字数中央値 |
| R5 | 技術系トピックにおけるフラットな見出し構造 | パターンD公式ドキュメントのh3数 |
| R6 | 疑問文・結論文を見出しに組み込む | heading_opener分析 |
| ルール | 内容 | 確信度 | 注意 |
|---|---|---|---|
| R7 | ペイン・事例系への視覚表現導入 | 中 | 画像数にノイズあり |
| R8 | 比較・技術系への表・コードブロック配置 | 高 | 技術者ブログで顕著 |
| R9 | 企業メディアにおける著者情報明記と更新日の維持 | 中 | 日付取得件数が限定的 |
今回の解析は「答え」ではなく「問い直し」だった。データに外れ値が混在していることがわかった。指標の設計自体に改善の余地があることもわかった。
次回はv4スクリプトでPDF・一覧ページを除外し、本文領域に絞ったカウントで再解析を行う。今回見えた「方向性」がノイズを除いた後も維持されるのか。それ自体が次の実験になる。
加えて、GEO固有の指標（Answer-First構造・Listicle形式・選択支援性）をどう数値化するかも、次回以降の設計テーマだ。
完璧なデータが出るまで公開しない、という選択肢もある。しかし「今見えていること」と「今見えていないこと」を正直に分けて公開することの方が、同じ実験をしようとしている人には価値があると考えている。
不完全な解析を公開することへの迷いは正直あった。それでも公開する理由は、「外れ値が混入した状態でも傾向は観測できた」という事実と、「次に何を改善すべきか」がこの解析を通じて見えたからだ。試行錯誤ごと記録することが、AI Alchemy Labの設計思想だ。