---
title: 4クエリ×49URLをPythonで解析してわかったこと・わからなかったこと
description: Perplexityの引用元49URLをPythonで構造解析。コードブロック・表・著者情報・更新頻度などを数値化し、「GEOで引用されやすいページ構造」の仮説を検証した。SEOとGEOは本当に別物なのか──その問いに向き合った解析編。
---

[AI実務設計ログ](https://content.ma-marketing-support.com/ai実務設計ログ)

# [4クエリ×49URLをPythonで解析してわかったこと・わからなかったこと](https://content.ma-marketing-support.com/ai実務設計ログ/4クエリ49urlをpythonで解析してわかったこと-わからなかったこと)

 作成者: [椎名真弓](https://content.ma-marketing-support.com/ai実務設計ログ/author/椎名真弓)｜May 1, 2026 3:38:33 AM

「AIはなぜそのページを引用するのか」という問いを持ったまま、前回の実験を終えた。Perplexityに4種類のクエリを投げて引用元を目視で分類したが、「なぜそのドメインが選ばれるのか」の理由まではわからなかった。

今回はその問いを深めるために、PythonでHTMLの構造を数値化することにした。文字数・見出し数・著者情報・画像数・コードブロック数——49URLを機械的に計測すれば、目視では見えなかった傾向が見えてくるはずだった。

結果として、いくつかの傾向は確かに見えた。しかし解析を進めるほど、別の問いが浮かび上がってきた。「取得しやすい指標を取得しているだけで、GEO固有の指標を測れていないのではないか」という問いだ。

この記事は「答えが出た記録」ではなく「次の問いが見えた記録」だ。

 

 

## なぜ目視観察だけでは不十分なのか

前回の実験では、Perplexityに4種類のクエリを投げて引用元を目視で分類した。クエリの種類によって引用元ドメインの構成比が変わることは確認できた。しかし「なぜ変わるのか」という問いには答えられなかった。

### 手動観察の限界：主観と偶然の区別がつかない

目視でサイトを見て「文字数が多い」「見出しが細かい」と感じても、それが再現性のある傾向なのか、たまたまそうだったのかを区別できない。各パターン1回ずつの観察では、統計的な裏付けにはならない。

### 構造をデータとして取り出す必要性

「コードブロックの数」「表の数」「著者情報の有無」といったページの構造的特徴は、目視では正確にカウントできない。これらを数値として取り出すために、PythonでHTMLの構造を定量化することにした。

## ChatGPTにPythonスクリプトを作ってもらった

プログラミングの経験はほぼない。それでもChatGPTをパートナーにすれば、解析ツールを手に入れられることがわかった。

### なぜ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件となった。

## 発見(1)：クエリ意図×ドメイン分布

第2回の目視観察で得た分布を、今回のPython解析データで確認した。この指標は目視とPythonで取得方法が変わらないため、今回のデータでも信頼性が高い。

### 4パターンのドメイン構成比

| クエリパターン | 企業メディア | 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%という構成は、目視観察と一致している。

この一致から、「キーワードではなく問いの性質が引用先を決める」という仮説は、今回のデータでも棄却されなかった。ただし同一テーマ・同一時期のデータであるため、独立した検証とはなっていない点に注意が必要だ。

## 発見(2)：技術系クエリの構造的特徴

技術・保守性クエリ（パターン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技術領域限定のデータである点は留保が必要だ。

## 発見(3)：著者情報と情報鮮度

著者情報（byline）と公開・更新日のデータから、いくつかの傾向が見えた。

### 企業メディアの60%で著者情報が明記

解析結果として、企業メディアの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（経験・専門性・権威性・信頼性）の観点から引用判断に影響している可能性が考えられる。

### 情報鮮度：企業メディアは平均57〜159日以内に更新

取得できた企業メディアの更新日データを見ると、パターンA（直接比較）の平均経過日数は約70日、パターンD（技術・保守性）は約57日だった。一方、パターンB（ペイン解決）は約159日と相対的に長かった。

この数値から、比較・技術系クエリで引用される企業メディアは、ペイン解決系より更新が新しい傾向が見られた。ただし日付データが取得できた件数はパターンAで3件・Dで1件と少なく、統計的な裏付けとしては弱い。

## 引用されるページの3タイプ分類

今回のデータ全体を見渡すと、Perplexityが引用するページには大きく3つのタイプがあることが見えてきた。

### ①実務解説型・②権威一次情報型

**①実務解説型（パターンAに多い）**  
h2/h3がある・画像や表もある・ある程度の文字数がある・著者情報あり。企業メディアが中心で、自分たちが再現しやすいタイプ。

**②権威・一次情報型（パターンDに多い）**  
公式ドキュメント・公式ブログ・技術者ブログ・PDF資料など。構造だけでなく「情報源としての信頼性」が引用に効いている可能性が高い。

### ③大規模ページ型とその注意点

**③大規模ページ型（パターンCに混在）**  
文字数が極端に多く・画像・リンクが多い・QAペアが多数検出される。ただしこのタイプは「記事」ではなく一覧ページ・サービスページが混入している可能性が高い。GEO記事設計の参考にするには注意が必要なタイプだ。

## 今回のデータの限界と正直な告白

今回の解析結果には、無視できない問題が複数含まれている。数値を読む前に、この限界を整理しておく必要がある。

### このデータの信頼性マップ

| 信頼度 | 指標 | 理由 |
| --- | --- | --- |
| ◎ 信頼できる | クエリ意図×ドメイン分布 | 複数回観察・外れ値なし |
| ◎ 信頼できる | 技術系のコードブロック・表の多さ | パターン間の差が明確 |
| △ 方向性は参考 | 著者情報の比率 | 他ドメインのサンプルが2〜11件 |
| △ 方向性は参考 | 情報鮮度 | 日付取得できた件数が少ない |
| △ 方向性は参考 | 画像数・外部リンク数 | HTML全体カウントのノイズあり |
| × 判断保留 | SNS系の構造 | 取得不可 |
| × 判断保留 | パターンCの平均値 | 一覧ページ混入 |
| × 判断保留 | パターンDの文字数 | PDF混入 |

### PDF・一覧ページ混入とHTMLカウントのノイズ

データセットにPDFファイルと一覧ページが混入しており、特にパターンDの文字数平均が歪んでいる可能性がある。また画像数・外部リンク数はHTML全体をカウントしているため、ヘッダー・フッター・サイドバーの要素が混入している。個人ブログの外部リンク数が平均221件という数値は、この問題の典型例だ（note：333件・はてなブログ：109件）。

### 今回の指標はSEOの延長ではないのか

もう一つの限界を正直に書く。

今回取得した指標のほとんどは、従来のSEO評価でも使われてきた指標と重複している。文字数・見出し数・更新日・著者情報・画像数・外部リンク数。これらはHTMLから機械的に取得できる要素だ。

問題は「取得しやすいものを取得した」という設計になってしまったことにある。「GEOで引用されやすいサイトの何を測るべきか」という問いから逆算して指標を設計していれば、別の指標が浮かび上がったはずだ。

GEO固有の可能性がある指標として、現時点で考えられるのは以下だ。

- 見出し直後への結論配置（Answer-First構造の有無）
- Listicle形式の有無（「Top N」「比較リスト」という構造）
- 選択支援性（比較表・推奨リスト・「vs」構造の有無）
- QA構造の密度（明示的なQ&A形式が何箇所あるか）

しかしこれらは、HTMLタグを数えるだけでは測定できない。コンテンツの意味的な特性であり、テキスト解析が必要になる。

そして、より根本的な問いが自分の中に残っている。

「SEOとGEOの指標は本当に別物なのか」

SEO的に評価されるサイトがGEO的にも評価されるのか、それとも別の法則が働いているのか。今回の解析だけでは、その答えは出なかった。これが第4回以降の実験テーマになる。

### 次のスクリプト（v4）で改善すること

ChatGPTと合意した次回改善項目は以下の通り。

- PDFと一覧ページの除外処理
- ページ本文領域（mainまたはarticleタグ内）のみのカウントに絞り込む
- 文字数あたりの密度指標への正規化（h3数/1万字・画像数/1万字など）
- 外れ値の除外基準の設定

## GEOルール候補：現時点での暫定まとめ

第2回の目視観察と今回のPython解析を合わせた時点での暫定GEOルール候補を整理する。「候補」であり「確定ルール」ではない点に注意。

### 前回から引き継ぐR1〜R6

| ルール | 内容 | 根拠 |
| --- | --- | --- |
| R1 | クエリ意図に合わせたドメインとフォーマットの選択 | 全パターンのドメイン分布 |
| R2 | 比較・事例コンテンツにおけるh3の深い階層化 | パターンA・C企業メディアの平均h3数 |
| R3 | ブログ記事における冒頭200文字での結論提示 | lead\_200\_has\_conclusion |
| R4 | 10,000〜15,000文字の適度な網羅性 | 引用元の文字数中央値 |
| R5 | 技術系トピックにおけるフラットな見出し構造 | パターンD公式ドキュメントのh3数 |
| R6 | 疑問文・結論文を見出しに組み込む | heading\_opener分析 |

### 今回新規追加のR7〜R9

| ルール | 内容 | 確信度 | 注意 |
| --- | --- | --- | --- |
| R7 | ペイン・事例系への視覚表現導入 | 中 | 画像数にノイズあり |
| R8 | 比較・技術系への表・コードブロック配置 | 高 | 技術者ブログで顕著 |
| R9 | 企業メディアにおける著者情報明記と更新日の維持 | 中 | 日付取得件数が限定的 |

## 次の実験へ：見えたことと、見えなかったこと

今回の解析で見えたことと見えなかったことを正直に分けると、こうなる。

見えたこととして、技術系クエリにはコードブロックと表が多いという構造的な差は確認できた。企業メディアの6割で著者情報が明記されているという傾向も見えた。クエリの意図がドメインの選択を決めるという仮説も、データで棄却されなかった。

### 実験を止めない理由

完璧なデータが出るまで公開しない、という選択肢もある。しかし「今見えていること」と「今見えていないこと」を正直に分けて公開することの方が、同じ実験をしようとしている人には価値があると考えている。

不完全な解析を公開することへの迷いは正直あった。それでも公開する理由は、「外れ値が混入した状態でも傾向は観測できた」という事実と、「次に何を改善すべきか」がこの解析を通じて見えたからだ。試行錯誤ごと記録することが、AI Alchemy Labの設計思想だ。

[完全な記事を表示](https://content.ma-marketing-support.com/ai実務設計ログ/4クエリ49urlをpythonで解析してわかったこと-わからなかったこと)

```json
{
  "@context" : "http://schema.org",
  "@type" : "BlogPosting",
  "author" : {
    "@type" : "Person",
    "name" : "椎名真弓"
  },
  "dateModified" : "2026-05-05T11:27:14.596Z",
  "datePublished" : "2026-05-01T03:38:33Z",
  "headline" : "4クエリ×49URLをPythonで解析してわかったこと・わからなかったこと",
  "image" : {
    "@type" : "ImageObject",
    "height" : 1260,
    "url" : "https://9341131.fs1.hubspotusercontent-na1.net/hubfs/9341131/AI%20Alchemy%20Lab%E8%A7%A3%E6%9E%90.png",
    "width" : 2240
  },
  "mainEntityOfPage" : "https://content.ma-marketing-support.com/ai実務設計ログ/4クエリ49urlをpythonで解析してわかったこと-わからなかったこと",
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject",
      "height" : 60,
      "url" : "/hs/hsstatic/content_shared_assets/static-1.4092/img/default-amp-logo.png",
      "width" : 60
    },
    "name" : "AI practical design"
  }
}
```