PostgreSQL×Rails×SEO分析｜JSONBとSearch Console自動収集で「考えるDB」を作る方法【2026年版】

生成AI時代において、単にWebサイトを作るだけでは差別化が難しく
なっています。これから重要になるのは、「どのようにデータを蓄積し、
分析し、改善に結びつけるか」です。特にSEO領域では、
Google Search Console（通称サチコ）のデータを継続的に収集し、
CTRや検索意図の変化を追跡できる環境を持つことが、
サイト運営の競争力そのものになりつつあります。

そこで注目したいのが、PostgreSQLです。MySQLが「Webアプリ標準DB」
として長年使われてきた一方で、PostgreSQLはJSONB・GINインデックス・
高度なSQL分析機能を武器に、「考えるDB」として進化しています。
私も週末ごとに本記事と実際作ったシステムを見比べています。

本記事では、Rails＋PostgreSQLを前提に、Search Console自動収集、
JSONB活用、SEO分析スキーマ設計、CTR改善AIへの発展可能性まで、
生成AIとの対話過程を含めて整理します。

第1章 PostgreSQLはなぜ注目されるのか｜MySQLとの思想的な違い

まず重要なのは、PostgreSQLとMySQLは「どちらが優れているか」という単純な話ではないという点です。両者は設計思想そのものが異なります。MySQLは「Webアプリを素早く動かすDB」として成功しました。一方PostgreSQLは、「分析・拡張・複雑なデータ構造」に強いDBとして進化しています。SEO分析やAI活用を前提にすると、この差が非常に大きくなります。

MySQLが“Webアプリ標準DB”になった理由

MySQLが普及した背景には、いわゆる「LAMPスタック」があります。

• Linux
• Apache
• MySQL
• PHP

この構成で世界中のWebサイトが構築されました。特に
WordPressの巨大な普及が、MySQLの「標準DB」
としての地位を決定づけました。つまりMySQLは、

「とりあえず動くWebシステムを素早く作る」

という方向に最適化されてきたDBです。実際、
DB-Enginesランキングでも長年上位を維持しています。

PostgreSQLはなぜ開発者人気が高いのか

一方で、近年はPostgreSQLを選ぶ開発者が急増しています。
Stack Overflow Developer SurveyでもPostgreSQL人気は非常に高く、

• PostgreSQL：55.6%
• MySQL：40.5%

という結果が出ています。これは単なる流行ではありません。
理由は明確です。

• 分析機能が強い
• JSONを扱いやすい
• 設計自由度が高い
• 型や制約が強い
• AI・データ分析用途と相性が良い

つまりPostgreSQLは、

「データを保存するDB」ではなく 「データを考えるDB」

へ進化しているのです。

第2章 Rails＋PostgreSQLでSEO分析基盤を作る

SEO分析を本格化すると、単純なページ管理では足りなくなります。
必要になるのは、「検索クエリ」「CTR」「掲載順位」「デバイス」
「国別傾向」などを時系列で分析できる構造です。この時、
Rails＋PostgreSQLは非常に強力な組み合わせになります。

SEO分析スキーマ設計の基本構造

まず基本となるテーブル設計です。

 create_table :pages do |t| t.string :url, null: false t.string :title t.timestamps end 

 create_table :queries do |t| t.string :query, null: false t.timestamps end 

 create_table :search_metrics do |t| t.references :page t.references :query t.date :date t.integer :clicks t.integer :impressions t.float :ctr t.float :position t.jsonb :raw_data t.timestamps end 

ここで重要なのが、

JSONBカラム

です。

JSONBがSEO分析を劇的に変える理由

通常のDB設計では、

• device列
• country列
• browser列

のようにカラムを増やしていきます。

しかしSearch Console APIは将来的に仕様変更される可能性があります。
また分析したい軸も変化します。そこでJSONBです。

 { "device": "mobile", "country": "JP", "query": "postgres jsonb" } 

このように柔軟に保存できます。さらにPostgreSQLでは、

 SELECT * FROM search_metrics WHERE raw_data->>'device' = 'mobile'; 

のようにJSON内部を直接検索できます。これが非常に強力です。
そして真価を発揮するのがGINインデックスです。

 CREATE INDEX idx_jsonb ON search_metrics USING GIN (raw_data); 

通常JSON検索は遅くなります。しかしGINインデックスを使うと、

• JSON内部キー
• 値
• 構造

まで高速検索可能になります。つまり、

「列がなくても高速分析できる」

という、従来DBとは別世界の設計が可能になるのです。

第３章．RailsでJSONBを実装する具体例

ここまで見てきたように、PostgreSQLがAI時代やSEO分析基盤で評価される理由の一つがJSONBです。
しかし実際の開発現場では、
「JSONBが便利なのは分かったが、Railsではどう実装するのか？」
という疑問を持つ方も多いでしょう。

本章では、Search Console APIやPlausible APIから取得したデータを例に、
RailsとPostgreSQLでJSONBを扱う具体的な方法を紹介します。

JSONBカラムを作成する

まずはJSONBを格納するためのテーブルを作成します。
通常のRDB設計であれば、

• query
• device
• country
• clicks
• impressions

といったカラムを個別に定義します。

しかしSearch Console APIの返却内容は将来的に増減する可能性があります。
そのため、まずは取得したデータをJSON形式のまま保存する設計が有効です。

rails g model SearchMetric raw_data:jsonb

生成されたMigrationを確認すると以下のようになります。

class CreateSearchMetrics < ActiveRecord::Migration[8.0]
  def change
    create_table :search_metrics do |t|
      t.jsonb :raw_data
      t.timestamps
    end
  end
end

マイグレーション実行後、PostgreSQL側にはJSONBカラムが作成されます。

Search Consoleデータを保存する

例えばSearch Console APIから取得したデータが以下のような内容だったとします。

{
  "query": "rails postgresql",
  "device": "mobile",
  "country": "JP",
  "clicks": 125,
  "impressions": 2400
}

Railsでは非常に簡単に保存できます。

SearchMetric.create!(
  raw_data: {
    query: "rails postgresql",
    device: "mobile",
    country: "JP",
    clicks: 125,
    impressions: 2400
  }
)

ここで重要なのは、事前に

• queryカラム
• deviceカラム
• countryカラム

を定義していない点です。

JSONBなら後から分析項目が増えても柔軟に対応できます。
この性質はSEO分析との相性が非常に良いです。

GINインデックスで高速検索する

JSONBの欠点は、データ量が増えると検索速度が低下することです。

そこで利用するのがGINインデックスです。

add_index :search_metrics,
          :raw_data,
          using: :gin

これによりPostgreSQLはJSON内部を索引化できます。

例えばスマホユーザーだけを抽出したい場合、

SearchMetric.where(
"raw_data ->> 'device' = ?",
"mobile"
)

といった検索が可能になります。

データ量が数十万件、数百万件へ増えた場合でも、
GINインデックスによって実用的な速度を維持できます。

SEO分析では、

• モバイル検索だけ分析
• 国別比較
• 検索クエリ分類
• AIによる特徴量抽出

といった処理が頻繁に発生します。

そのためJSONBとGINインデックスの組み合わせは、
単なる保存技術ではなく「分析基盤そのもの」と考える方が実態に近いでしょう。

なぜSEO分析基盤と相性が良いのか

Search ConsoleやPlausibleから取得するデータは、
最初から完全な構造が決まっているわけではありません。

将来的には、

• 検索意図分類
• AIによるタグ付け
• 記事ジャンル判定
• CTR改善スコア
• LLM分析結果

などを追加したくなる可能性があります。

通常のRDB設計では、そのたびにカラム追加やマイグレーションが必要になります。

しかしJSONBなら柔軟に拡張できます。

つまりPostgreSQLは、
単なるデータ保存先ではなく、
SEOデータやAI分析結果を継続的に蓄積する「知識ベース」として機能できるのです。

第4章 Search Console自動収集とRails自動化

SEO分析を継続的に行うには、Search Consoleデータを自動収集する
仕組みが重要です。ここを手作業にすると、結局運用が止まります。
Linux＋Rails＋cronを組み合わせることで、
「PCを立ち上げるだけでSEOデータが蓄積される環境」を作ることができます。

Linux起動時にSearch Console収集を自動化する

例えばcronを使えば、起動時自動実行が可能です。

 @reboot cd /home/koji/app && bundle exec rails runner 'Job.run' 

また、定期実行もできます。

 0 6 * * * bundle exec rake fetch_search_console 

これにより、

• 毎朝データ収集
• 自動DB保存
• 分析準備完了

という流れができます。

Googleアカウント管理の鬼門をどう超えるか

Search Console APIで多くの人が詰まるのが認証です。
おすすめは「サービスアカウント方式」です。流れは以下です。

1. Google Cloudでサービスアカウント作成
2. Search Console API有効化
3. JSONキー取得
4. Search Consoleにサービスアカウントを追加

ここで重要なのは、

Search Console側にも権限追加が必要

という点です。これを忘れるとAPIは通ってもデータ取得できません。
Rails側では以下のように扱えます。

 service = Google::Apis::WebmastersV3::SearchConsoleService.new 

これにより完全自動化が可能になります。

第5章 PostgreSQL＋AIが変える未来｜CTR改善AIへの発展

ここまでの構成を作ると、単なるSEO管理ツールでは終わりません。
PostgreSQLに蓄積されたデータをAI分析へ接続することで、
「自己改善するSEOシステム」へ発展できます。
ここが非常に面白いポイントです。

CTR改善AIは何を提案するのか

例えば以下の分析ができます。

• 表示回数は多いがCTRが低い
• モバイルだけCTRが低い
• 順位は高いのにクリックされない
• 特定キーワードだけ急落している

ここからAIは、

• タイトル改善
• 検索意図修正
• モバイルUI改善
• 競合比較

などを提案できます。例えば：

「順位は高いがCTRが低いため、タイトルの訴求不足が疑われます」

のような提案です。

“考えるDB”としてのPostgreSQL

重要なのは、PostgreSQLが単なる保存先ではなく、

分析エンジン

として機能している点です。

JSONB・GIN・ウィンドウ関数・CTEを組み合わせると、

• 時系列分析
• 異常検知
• 検索意図分類
• AI用データ生成

までDB内部で処理可能になります。これはMySQL時代の、

「DBは保存、分析は外部」

という思想から大きく変化しています。PostgreSQLはまさに、

「思考するデータ基盤」

へ進化しているのです。

まとめ

MySQLは現在でも優秀なDBです。しかし、

• SEO分析
• JSON活用
• AI連携
• Search Console自動収集
• CTR改善分析

といった現代的用途を考えると、PostgreSQLは非常に強力です。

特にRailsとの組み合わせでは、

• JSONB
• GINインデックス
• 分析SQL
• AI分析

が極めて自然に統合できます。そして本質的には、

「データをどう保存するか」

ではなく、

「データからどう思考するか」

の時代に入っているのかもしれません。

参考資料