Claude Codeと一緒にSEO分析ツールを作ってみる — Google Search Console × Analytics連携【開発記録 Part 2】
Part 1で作ったMVPを本格リニューアル。Analytics・Search・SEOの3ページ構成に再設計し、日付範囲検索とAIアドバイス機能を追加。Google無料プランでのデータ取得の壁と、その乗り越え方も記録します。
この記事について
Part 1では、Claude Codeと一緒にGSC Rank Checkerの企画からMVP完成までを記録しました。
Part 2では、MVPを実用レベルに引き上げるためのリニューアルを行います。ページ構造の再設計、日付範囲検索、SEOアドバイス機能の追加——そして、Google無料プランで開発していて実際にハマったポイントについても正直に書きます。
Part 1からの変化
Part 1の時点では、こんな構成でした。
| ページ | 内容 |
|---|---|
| ダッシュボード | GSC概要 + GA連携 |
| キーワード | キーワード一覧 + ウォッチリスト |
| ページ | ページ一覧 |
使ってみると、いくつかの不満が出てきました。
- 日付範囲が28日固定。「先週の順位変動を見たい」「半年の推移を確認したい」ができない
- ページの役割が曖昧。ダッシュボードにGSCとGAが混在していて、何を見ればいいかわかりにくい
- データを見ても、次に何をすればいいかわからない。数字は見えるけど、アクションにつながらない
新しい3ページ構成
Claude Codeに相談して、ページ構造を根本から見直しました。
自分: 「ページ構造を Analytics / Search / SEO の3つに分けたい。
日付範囲検索とアドバイス機能も追加したい」新しい構成はこうです。
| ページ | 役割 | 主な機能 |
|---|---|---|
| Analytics | トラフィック全体を俯瞰 | GSCサマリー + GAサマリー + 日別トレンド + トップKW/ページ |
| Search | キーワードを深掘り | キーワード一覧 + ウォッチリスト + 順位推移グラフ |
| SEO | ページ単位で改善 | ページ一覧 + SEOアドバイス + ページ別キーワード |
Analyticsは「サイト全体の調子はどう？」を確認する場所。 Searchは「このキーワード、順位どうなってる？」を追跡する場所。 SEOは「どのページを改善すべき？」を判断する場所。
役割が明確になったことで、「今日やるべきこと」がダッシュボードを開いただけでわかるようになりました。
日付範囲検索を追加
MVPでは全ページが「過去28日間」固定でした。これをプリセットボタンで切り替えられるようにします。
設計
Claude Codeが提案した方式は、URLクエリパラメータとの同期です。
/dashboard/analytics?period=90dこうすることで、ブラウザの「戻る」ボタンで前の期間に戻れます。ブックマークにも期間が保存される。地味だけど、使い勝手に効きます。
実装
プリセットは5種類。
| ボタン | 期間 |
|---|---|
| 7日 | 直近1週間 |
| 28日 | GSCのデフォルト |
| 3ヶ月 | 中期トレンド確認 |
| 6ヶ月 | 半年推移 |
| 1年 | 年間トレンド |
ここで助かったのが、バックエンドのAPIは最初から期間パラメータに対応していたこと。Part 1でClaude Codeが設計したAPIは、?period=7d のようなクエリパラメータを受け取れる仕様になっていました。フロントエンド側が28日をハードコードしていただけ。
つまり、バックエンドは一切変更なし。フロントエンドにピッカーUIとカスタムフックを追加するだけで完了しました。
先を見据えた設計の恩恵を、ここで受けました。 Claude Codeが初期設計時に「将来の拡張を考えて」APIにperiodパラメータを入れていたのが効いています。
SEOアドバイス機能
ここが今回の目玉です。
課題: データを見ても動けない
GSCのデータを眺めていても、何をすべきかわからない。SEOの知識がある人なら「CTR低いな、タイトル変えよう」と判断できますが、初心者にはハードルが高い。
解決: ルールベースのアドバイスエンジン
Claude Codeと議論して、クライアントサイドで動くルールベースのアドバイスエンジンを実装しました。
自分: 「AIアドバイス機能って、Claude APIを使うべき？」
Claude Code: 「まずはルールベースで十分です。
GSCのデータには明確なパターンがあるので、
ルールで拾える改善ポイントがたくさんあります。
API呼び出しのコストもゼロで済みます。」これは正しい判断でした。API課金なしで、即座にアドバイスが表示される。
実装したルール
| アドバイス | 条件 | 重要度 |
|---|---|---|
| CTRが低いキーワード | CTR 2%未満 & 表示100回以上 | 🔴 重要 |
| 順位が大幅下落 | 前期比で3位以上ダウン | 🔴 重要 |
| 上位表示なのにCTR低い | 10位以内 & CTR 3%未満 | 🟡 注意 |
| 上位なのにクリック少ない | 5位以内 & クリック5未満 | 🟡 注意 |
| 全体クリック減少 | 前期比10%以上減 | 🟡 注意 |
| 表示されないページ | インプレッション0 | 🔵 情報 |
各アドバイスには該当キーワードやページへのリンクが付いていて、クリックすると詳細ページに飛べます。「何が問題か → どこを見るか → 何をすべきか」がワンクリックでつながる。
問題がなければ「問題は検出されませんでした」の緑バッジが出ます。これも大事。「問題なし」がわかることで安心できる。
Google無料プランの壁
ここからは、開発中に実際にハマった話です。
OAuth テストモードの7日問題
Google Cloud Consoleで OAuth を設定すると、最初は「テストモード」になります。テストモードには大きな制約があります。
リフレッシュトークンの有効期限が7日間しかない。
つまり、1週間放置するとトークンが無効になり、ログインし直す必要がある。個人で使う分にはまだ許容範囲ですが、毎日自動でデータを取得するCronジョブには致命的です。
解決策: 本番公開審査を通す
Googleの本番公開審査を通過すれば、リフレッシュトークンの期限制限がなくなります。ただし、審査には以下が必要です。
- プライバシーポリシーページ
- OAuth同意画面の適切な設定
- アプリの説明と使用目的
- テスト動画（場合による）
審査は数日〜数週間かかることがあります。開発中はテストモードで進めて、デプロイ前に審査に出す——というスケジュール感です。
GSC APIのデータ遅延
GSC APIのデータは2〜3日遅れです。「今日のデータを今日見る」はできません。
これは仕様なので回避不可能。ツール側では「3日前を最新データとして扱う」ロジックにしています。ユーザーには日付表示で暗黙的にわかるようにしました。
D1のバルクINSERT制限
Cloudflare D1には、1回のクエリでINSERTできる行数に制限があります。GSCのデータは数千〜数万行になるので、500行ずつバッチに分割する処理が必要でした。
// 500行ずつバッチ処理
for (let i = 0; i < rows.length; i += 500) {
const batch = rows.slice(i, i + 500);
await bulkInsert(db, siteId, batch);
}Claude Codeが最初からこのパターンで実装してくれていたので、問題にはなりませんでした。ただ、知らずに全行一括INSERTしていたらエラーで詰まっていたはず。
GA4 APIの期間計算
GA4 APIとGSC APIでは、データの鮮度が異なります。
- GSC: 3日遅れ
- GA4: 1日遅れ
最初、両方同じ日付計算を使っていて、GA4側のデータが欠けるバグが出ました。修正後は、APIごとに適切なラグ日数を設定するようにしています。
リニューアルの技術的なポイント
parsePeriodの共通化
期間パラメータを日数に変換する関数が、performanceルートとGAルートで別々に実装されていました。GAルート側は 6m と 1y に対応していない不完全な実装。
これを共通ユーティリティに抽出して、両方のルートから参照するように修正。こうした「似ているけど微妙に違う実装」の統一は、機能追加のタイミングで一緒にやるのが効率的です。
URLクエリパラメータとの同期
usePeriod() カスタムフックは、useSearchParams と useRouter を組み合わせてURLと期間状態を同期します。
// ブラウザの戻る/進むに追従
const period = searchParams.get("period") ?? "28d";
// URL更新（ヒストリを汚さないreplace）
router.replace(`${pathname}?period=${newPeriod}`);router.push ではなく router.replace を使うのがポイント。期間切り替えのたびにヒストリが積まれると、「戻る」ボタンが期間切り替えで埋まってしまいます。
アドバイスエンジンの設計判断
アドバイス機能をサーバーサイドにするかクライアントサイドにするか、迷いました。
| 方式 | メリット | デメリット |
|---|---|---|
| サーバーサイド | DBの全データにアクセス可能 | APIエンドポイント追加が必要 |
| クライアントサイド | API変更ゼロ、即時反応 | フロントに表示されているデータの範囲内 |
今回はクライアントサイドを選択。理由は3つ。
- 既存APIのレスポンスデータだけで十分なアドバイスが出せる
- API変更がゼロなので、バックエンドに影響しない
- 期間切り替えに即座に反応する（API呼び出し不要）
将来、もっと高度な分析（例: ページ間の内部リンク解析）が必要になったら、サーバーサイドに移行する選択肢も残しています。
現時点でできること
Part 1からの追加分を含めた全機能リスト:
- ✅ Googleアカウントでワンクリックログイン
- ✅ Search Consoleのサイトを選択して自動連携
- ✅ Google Analytics連携（PV・セッション推移グラフ）
- ✅ Analytics / Search / SEO の3ページ構成
- ✅ 日付範囲検索（7日 / 28日 / 3ヶ月 / 6ヶ月 / 1年）
- ✅ SEOアドバイス機能（6種類のルールベース分析）
- ✅ キーワード詳細（順位推移グラフ）
- ✅ キーワードウォッチリスト（ピン留め追跡）
- ✅ ページ別キーワード逆引き
- ✅ ダーク / ライトテーマ切り替え
Claude Codeとのリニューアル作業
今回のリニューアルは、Claude Codeに「Analytics / Search / SEOの3ページ構成にしたい、日付範囲検索とアドバイス機能もつけたい」と伝えるだけで、設計からコーディングまで一気に進みました。
やったことを分解すると:
- 共通基盤の構築 — 日付範囲フック、ピッカーUI、期間ユーティリティの共通化
- ナビゲーション変更 — サイドバーの3ページ構成化、リダイレクト設定
- 3ページの新規作成 — 既存コンポーネントを最大限再利用
- アドバイスエンジン — ルール定義 + 表示カード
- リンク修正 + 旧ページ削除 — 参照切れをゼロに
全6フェーズ、ビルドエラーゼロで完了。既存のAPIやコンポーネントを活かしながら、ページ構造だけをきれいに入れ替える——Claude Codeがコードベース全体を把握しているからこそできる芸当です。Claude Codeの外部ツール連携に興味がある方は「Claude Code MCP設定ガイド」も参考にしてください。
これからやること（Part 3 以降）
- 🔲
rank.toolcraftlab.devにデプロイして本番公開 - 🔲 Cron Triggersで毎日自動データ更新
- 🔲 Google OAuth 本番審査の通過
- 🔲 マルチユーザー対応
- 🔲 アドバイス機能の拡張（AIベースの改善提案）
- 🔲 アラート通知（順位変動をメール or Slack通知）
まとめ
Part 1のMVPと比べて、ツールとしての実用性が格段に上がりました。
- データの切り口が3つに整理された
- 日付を自由に切り替えられるようになった
- 「次に何をすべきか」がアドバイスで表示される
Google無料プランの制約（トークン7日問題、データ遅延）は確かにありますが、個人ブログの順位チェックには十分に使えるレベルです。
Claude Codeとの開発で改めて感じるのは、**「最初に拡張性のある設計をしておくと、後の追加が楽」**ということ。Part 1でAPIに期間パラメータが入っていたおかげで、Part 2のフロントエンド改修だけで日付範囲検索が実現できました。
次回（Part 3）では、いよいよCloudflareへのデプロイと、実データでの動作確認をお届けします。
この記事で紹介しているツールは開発中です。公開時にはURLを追記します。