Web検査ツールを8個から12個に増やした設計判断 — 「もう十分」から「プロレベル」へ

はじめに — 「基本的なSEO検査」はできていた

ZERONOVA LAB MCP Serverは、URLを渡すだけでSEO検査を実行するツール群です。MCP Server開発記で書いたとおり、82個の無料ツールから「AIエージェントが自力でできないこと」だけを厳選し、npmパッケージとして公開しています。

Phase 3（v0.4.0）までに、Tier 1の個別検査ツールは8個ありました。OGPチェック、alt属性チェック、リンク切れチェック、ページ速度チェック、見出し抽出、セキュリティヘッダーチェック、サイト設定チェック、X Cardバリデーション。基本的なSEO検査は一通りカバーしており、Tier 2のワークフロー run_seo_audit で連鎖実行すればスコア付きレポートも出ます。SEO監査の手動チェック項目をゼロにした話で書いたとおり、手動確認項目もゼロにしました。

「もう十分ではないか？」——正直、そう思っていました。

ギャップ分析 — 足りないものが見えた瞬間

Phase 3.5の企画は、既存ツールの精査から始まりました。8つのTier 1ツールがカバーしている領域を洗い出し、SEOの観点で「カバー済み」「部分的」「完全に不足」の3段階で分類したのです。

既存ツールは OGP・見出し・リンク・速度・alt 属性・robots/sitemap・セキュリティヘッダーをカバーしているが、キャッシュ戦略・構造化データの完全性・リダイレクト・画像最適化が抜けていた。これらは Google の Core Web Vitals やインデックス品質に直結する

2月21日の開発日記にこう書きました。「基本的なSEO検査」と「プロフェッショナルレベルのSEO検査」の間には、明確な溝がありました。

キャッシュヘッダーを見ていない。JSON-LDの存在確認はできても、各スキーマタイプの必須プロパティを検証していない。リダイレクトチェーンを追跡できない。画像のファイルサイズや次世代フォーマットの使用率を測定していない。

どれも、SEOコンサルタントが手動でチェックする項目です。MCP Serverが「プロレベルの検査ツール」を名乗るなら、ここを埋めなければなりません。

4つの新ツール — 何を、なぜ選んだか

ギャップ分析で5つの不足領域を特定しました。そのうち4つをPhase 3.5で実装し、残り1つ（サイト横断チェック）は将来Phaseに送る判断をしました。

1. check_cache_headers — キャッシュ戦略の可視化

Cache-Control、ETag、Last-Modified、CDN Cache Status、Age、Vary、Expiresの7項目を検査します。

「ページ速度が遅い」と言われたとき、原因がキャッシュ設定にあるケースは多いのに、既存ツールではキャッシュの状態を確認する手段がありませんでした。ページ速度チェッカーはLighthouseのスコアを返しますが、「なぜ遅いのか」の原因の一つであるキャッシュ戦略までは踏み込みません。

2. check_schema_completeness — 構造化データの「完全性」検証

JSON-LD構造化データを抽出し、18スキーマタイプ別に必須プロパティと推奨プロパティの充足率を検証します。

Phase 2.5でOGPチェッカーにJSON-LDの存在確認を追加していましたが、「JSON-LDがある」と「JSON-LDが正しい」は別の問題です。BlogPosting にauthorがない、Product にpriceがない——こうした不備はリッチリザルトに表示されない原因になりますが、存在確認だけでは検出できません。

3. check_redirect_chain — リダイレクトの追跡

リダイレクトチェーンを最大10ホップまで追跡し、各ホップのステータスコード、Location ヘッダー、レスポンスタイムを記録します。ループ検知とHTTPS→HTTPダウングレード検知も実装しました。

サイト移行時や旧URLの整理時に、リダイレクトが何段重なっているかは重要な情報です。Googleは長いリダイレクトチェーンをクロールバジェットの無駄遣いとみなします。

4. check_image_optimization — 画像最適化の測定

ページ内の <img> タグを解析し、ファイルサイズ、次世代フォーマット（WebP/AVIF）使用率、lazy loading属性、srcset属性、width/height属性をスコアリングします。

画像はWebページの転送量の大半を占めます。にもかかわらず、既存ツールでは画像の最適化状態を検査する手段がありませんでした。

実装順序の設計 — コスト対効果で並べる

4つのツールを「どの順番で実装するか」は、PMとして重要な判断でした。

実装順序の最適化: コスト対効果で ①キャッシュ（既存パターン流用、低コスト）→ ②スキーマ（SEO 差別化大）→ ③リダイレクト（低コスト）→ ④画像（影響大）→ ⑤サイト横断（最高コストだが最高価値）の順に設計

キャッシュヘッダーを最初に持ってきた理由: 既存ツール（セキュリティヘッダーチェッカー等）と同じ「HTTPヘッダーを取得して解析」パターンを踏襲できます。実装コストが最も低く、最初に成功体験を作れます。

構造化データを2番目にした理由: SEOツールとしての差別化効果が最も高い領域です。JSON-LDの「存在確認」しかできない競合ツールに対して、「プロパティ単位の検証」は明確なアドバンテージになります。

サイト横断チェックを将来に送った理由: 複数URLをクロールする設計はレスポンスタイムやリソース消費の制約が厳しく、Phase 3.5のスコープに入れると全体の品質が下がるリスクがありました。

設計判断のポイント — 3つのトレードオフ

スキーマタイプ: 9から18へ拡張

Zeronova

構造化データチェッカーの対応スキーマ数を検討したい。企画段階では9タイプ（Article、BlogPosting、Product、LocalBusiness、FAQPage、Organization、Person、WebSite、SoftwareApplication）に限定する設計だった。実装段階でどう判断するか。

Zeronova

データ定義のコストだけなら18タイプに広げよう。実用的な範囲で網羅性を高めた方が、競合ツールとの差別化になる。「基本的な9タイプだけ」と「実務で使う18タイプ全部」では、ユーザーの信頼感がまったく違う。

この判断は「プロレベル」というPhase 3.5のテーマそのものでした。9タイプでも「動く」し「使える」。しかし18タイプにすることで、「このツールは実務レベルで網羅している」という信頼感が生まれます。

リダイレクトチェーン: 最大5ホップ vs 10ホップ

リダイレクトチェッカーの設計で最も悩んだのが、最大ホップ数です。

ZERONOVA LABの開発ガイドライン（tools-dev-guidelines.md）では、SSRF対策としてリダイレクトの追従を最大5回と規定しています。Next.js APIルートのSSRF対策で解説したとおり、redirect: "manual" + ホップ毎検証はすべての外部フェッチ系ツールに適用しているルールです。

しかし、リダイレクトチェッカーはリダイレクトチェーンを追跡すること自体が目的のツールです。5ホップで打ち切ってしまうと、6段以上のリダイレクトチェーンを検出できず、ツールの存在意義が薄れます。

最終的に、10ホップまで許可する設計にしました。ただし、各ホップで isValidUrl() によるSSRF検証を実施し、内部IPへのアクセスはホップ毎に防御しています。ガイドラインの精神（SSRF防止）は守りつつ、ツールの本来の目的を優先する判断です。

画像チェッカー: デュアルAbortController

画像最適化チェッカーには、2つの異なるタイムアウト戦略が必要でした。

まずメインのHTML取得には10秒のAbortControllerを設定します。HTMLが取得できなければ何もできないため、ここでのタイムアウトはツール全体の失敗を意味します。

一方、HTML内の画像のファイルサイズを取得するためのHEADリクエストには、8秒の別のAbortControllerを使います。ここでタイムアウトしても、HTML解析で得られた情報（フォーマット、lazy loading、width/height等）は返せます。

ページ内に画像が100枚あっても、サイズ取得は最大30枚に制限しました。全画像にHEADリクエストを送ると、対象サイトへの負荷が問題になるからです。

Tier 2チェックリストの拡張

4つの新ツールを追加するだけでは終わりません。Tier 2のワークフロー——run_seo_audit、run_web_launch_audit、run_freelance_delivery_audit——のチェックリストも拡張する必要があります。

新ツールの検査結果をチェックリストの評価関数に組み込み、スコア計算に反映させました。キャッシュヘッダーの適切性、構造化データの充足率、リダイレクトチェーンの長さ、画像最適化のスコア——すべてが自動チェック項目としてワークフローに組み込まれています。

v0.5.0のリリース — 公開前チェックで3つの不整合を発見

199件のテストが全パスし、ビルドも成功。npm audit も問題なし。あとはnpm公開するだけ——と思いきや、公開前チェックリストの実施で3つのドキュメント不整合が見つかりました。

CHANGELOG/README のチェック項目数・ツール数の不整合を3箇所修正。Web Launch Audit: 「3 new items」→「4 new items」（schema completeness の欠落）。Web Launch Audit: 「20 auto + 1 manual」→「21 auto + 1 manual」。Freelance Delivery Audit: 「chains 11 tools」→「chains 8 tools」（実際のユニークツール数）

2月22日の開発日記にこう書きました。コードは正しく動いていても、ドキュメントの数値が実態と合っていなければ、ユーザーの信頼を損ないます。npmパッケージは一度公開するとバージョンの再利用ができないため、公開前のチェックリストは特に重要です。

修正を完了し、zeronova-lab-mcp@0.5.0 をnpm公開しました。Tier 1: 12ツール、Tier 2: 3ワークフロー、Tier 3: 5ジェネレーター。合計20ツールです。

自分のサイトでチェックした結果

v0.5.0を公開した直後に、自分のサイト（zeronova-lab.com）でSEO総合チェックを実行しました。

総合スコアは84点。2月19日に初めてMCP Serverで自サイトをチェックしたときは64点スタートで、2回の改善を経て88点まで上げていました。今回は検査項目が増えた状態での84点です。

スコアが88点から84点に下がったことに一瞬「あれ？」と思いましたが、すぐに理解しました。検査が厳しくなった分スコアは下がるが、改善すべきポイントが明確に見えるのでむしろありがたい。キャッシュヘッダーの設定不足、構造化データの推奨プロパティの欠落——これまで見えなかった改善点が可視化されたのです。

そしてその改善を、Claude Code内で即座に実行できました。結果を見る、改善する、再チェックする。このループがエディタから一歩も出ずに回ります。自分のプロダクトで自分のサイトを改善できる——作って良かったと素直に思えた瞬間でした。

「もう十分」から「プロレベル」へ

振り返ると、Phase 3までの8ツールは「基本的なSEO検査」としては十分でした。OGP、alt属性、リンク切れ、ページ速度、見出し構造、セキュリティヘッダー、robots.txt/サイトマップ。これだけでも、手動確認ゼロのワンコマンドSEO監査は実現できていました。

しかし「十分」と「プロレベル」の間には、キャッシュ戦略、構造化データの完全性、リダイレクトチェーン、画像最適化という4つの溝がありました。Phase 3.5はこの溝を埋める作業でした。

SEO ツールの「完全性」は段階的に達成するもの: 一度にすべてを実装しようとすると Phase が肥大化する。Phase 3 までで「基本的な SEO 検査」を網羅し、Phase 3.5 で「プロフェッショナルレベルの SEO 検査」に引き上げるという段階設計が効果的

段階的に品質を上げていくこのアプローチは、MCP Server開発全体に通じるパターンです。Phase 2で「手動項目あり」のままリリースし、Phase 2.5で手動ゼロにした経験が、Phase 3→Phase 3.5でも活きました。

学んだこと

ギャップ分析は「作った後」にやるべき: 設計段階でのギャップ分析と、実動するツールがある状態でのギャップ分析は解像度が違います。8ツールを実際に使い込んだからこそ、「キャッシュが見えない」「構造化データの中身を検証していない」という不足が見えました。

ガイドラインは「守る」だけでなく「目的を理解する」: リダイレクトチェッカーの最大ホップ数で、ガイドラインの字面（5ホップ上限）とガイドラインの目的（SSRF防止）が衝突しました。目的を理解していれば、per-hop検証でSSRFを防御しつつツールの価値を最大化する設計ができます。

コードとドキュメントは別の品質軸: 199テストが通っても、CHANGELOGの数値が間違っていれば品質は担保されていません。公開前チェックリストがドキュメントの不整合を3件発見したことは、「動くコード」と「正確なドキュメント」が独立した品質軸であることを改めて教えてくれました。

自分がユーザーになれることの価値: 自分のサイトでSEO監査を実行し、スコアの変化を実感し、その場で改善を回す体験。自分のプロダクトが自分の仕事を改善するこのループが、次の機能追加の最も強い動機になります。