Claude Code SEO というキーワードで検索すると、上位はほぼSEO代理店のブログと公式リポジトリで占められている。その中心にあるのが claude-seo ——25個のスキルと18個のサブエージェントでサイト監査を回すOSSで、2026-08-27時点で★15,489・MITライセンスだ。だが「25スキル」「並列15エージェント」という数字は、日本語のサイトに向けたときに何が本当に動くのかを何も教えてくれない。そこで実際にインストールし、当サイトの実記事に対して走らせ、言語をまたいだ対照実験までやってみた。
この記事のポイント（30秒でわかる claude-seo）
・正体：Claude Code に25スキル＋18サブエージェントを足すSEO監査スキル集。MIT・★15,489・Python製
・入れると：~/.claude/skills/ に31個のスキルディレクトリ、~/.claude/agents/ に18個のエージェント定義。実測1.3GB（うちPlaywright 569MB＋隔離venv 723MB）
・日本語で効くもの：構造化データ検出・検証、canonical/hreflang/sitemap、画像alt、リンク構造、レンダリング差分
・日本語で効かないもの：コンテンツ品質スコア。トークナイザが [A-Za-z] 専用で、日本語本文は採点対象にすら入らない
・APIキー：無料枠は不要。53スクリプト中17本だけが外部APIを参照する
Claude Code そのものの導入や設定から確認したい場合は、Claude Code｜2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引きを先に読むと、本記事のスキル配置の話が繋がりやすい。
claude-seoとは｜Claude Code SEO監査を25スキル＋18サブエージェントで回すOSS
claude-seo は、Claude Code のスキル（Agent Skills）とサブエージェントとして動くSEO監査パッケージだ。テクニカルSEOからGEOまでを1つの束で扱う点が売りになっている。作者は AgriciDaniel 氏で、同じ作者は Obsidian 向けの claude-obsidian も公開している（当サイトでも2026-08-24に取り上げた）。「1つのCLIツール」ではなく、Markdownで書かれた手順書の束＋それを支えるPythonスクリプト群という構成である点が、従来のSEOツールと最も違う。
リポジトリの実数を数えると、READMEの主張と一致した。
READMEの主張 vs 実数（2026-08-27・ls で計測）
・skills/ 配下のディレクトリ＝25（READMEの「25 sub-skills」と一致）
・agents/ 配下の .md＝18（READMEの「18 specialist agents」と一致）
・scripts/ 配下の .py＝53（うち17本がAPIキー・認証情報を参照）
・テスト＝441件収集・440件成功・1件失敗（失敗はGitHub APIのレート制限によるネットワーク起因）
ls と pytest で数えた実数。READMEの記載と一致したが、テストバッジの「410」だけは実数441と乖離していた数字が合っていること自体は褒めるところではないが、この種のスキル集は「READMEの数字が実装から乖離している」ことが珍しくないので、まず一致を確認した。ただしテストバッジだけは例外で、READMEの tests 410 passing バッジは shields.io の固定文字列であり、現在の実数441とは一致していない。これはCIから生成されるバッジではないので、更新漏れが起きやすい箇所だ。
スキルはコマンドではなく「手順書」
25スキルの中身を開くと、実行ファイルはほぼ入っていない。たとえば GEO（AI検索最適化）を担当する seo-geo の中身は SKILL.md と references/ だけで、Pythonスクリプトを1本も持たない。これは欠陥ではなく設計で、判断そのものはClaudeにやらせ、決定的な計算だけをスクリプトへ逃がすという分担になっている。
この分担は後述する日本語の話に直結する。判断をLLMがやる部分は日本語でも問題なく動く。決定的な計算をPythonがやる部分は、その実装が英語前提かどうかで結果が変わる。
2つの配布版がある（片方は有料コミュニティ向け）
READMEの冒頭に明記されているとおり、claude-seo には2系統ある。
| 版 | リポジトリ | 入手条件 | ライセンス |
|---|---|---|---|
| 公開OSS版 | AgriciDaniel/claude-seo |
誰でも。会員登録不要 | MIT |
| コミュニティ版 | AI-Marketing-Hub/claude-seo |
Skool の有料コミュニティ「AI Marketing Hub Pro」会員 | 非公開（要org権限） |
本記事が検証したのは公開OSS版のみである。コミュニティ版は「今後の機能への早期アクセス」と説明されているが、org権限がないと /plugin marketplace add が404を返すため、外から差分を検証する手段がない。オープンコアというより、OSS版が有料コミュニティへの導線を兼ねている構造だと理解しておくのが正確だ。Codex 向けの移植版 AgriciDaniel/codex-seo も別途公開されている。
インストールで何がどこに置かれるか — 実測1.3GBの内訳
インストール方法は2通りある。Claude Code 1.0.33以降のプラグイン経由と、シェルスクリプト経由だ。
# 方法1: プラグイン経由（Claude Code 内で実行）
/plugin marketplace add AgriciDaniel/claude-seo
/plugin install claude-seo@agricidaniel-claude-seo
/seo setup
# 方法2: 手動インストール（中身を読んでから実行できる）
git clone --depth 1 https://github.com/AgriciDaniel/claude-seo.git
bash claude-seo/install.sh
READMEは Windows 版について「なぜ irm ... | iex を使わないか」をわざわざ説明している。Claude Code 自身のセキュリティガードがリモートコード直接実行をサプライチェーンリスクとして検知するため、あえて git clone してから実行させる、という理由だ。インストーラを読ませてから走らせる姿勢は評価できる。
実際に走らせて、どこに何が置かれたかを数えた
自分の ~/.claude を汚さないため、HOME を差し替えたサンドボックスで実行した。結果、終了コード0で完了し、以下が生成された。
インストール前に知っておくべき3点（すべて実測）
1. スキルディレクトリは25個ではなく31個できる。 リポジトリの skills/ は25個だが、インストーラは extensions/ 配下の連携スキル6個（seo-ahrefs / seo-bing / seo-firecrawl / seo-profound / seo-seranking / seo-unlighthouse）も同時に配置する。READMEの「25」はリポジトリ内の数であって、インストール後の数ではない。
2. サブエージェント18個は ~/.claude/agents/ に置かれる＝全プロジェクト共通。 プロジェクト単位ではなくユーザー単位のディレクトリなので、SEOと無関係なリポジトリで Claude Code を起動しても18個のエージェント定義が読み込み対象に入る。
3. 合計1.3GB・28,630ファイル。 内訳は隔離venvが723MB、Playwrightの Chromium が569MB。ただしChromiumはスキルディレクトリの中に閉じ込められている（skills/seo/ms-playwright/）ので、システム共通の Playwright キャッシュを汚さない点は良い設計だ。
インストール状態は doctor で確認できる。手元では以下が返った。
$ "$HOME/.claude/skills/seo/bin/claude-seo" doctor
Runtime: ready
Install mode: manual
Python: 3.14
Chromium: ready
なお install.sh が既定で取得するのは main ではなくタグ v2.2.5 である（CLAUDE_SEO_TAG=main で上書き可能）。開発版ではなくリリース版が入る設計なので、README の記述と手元の挙動がずれた場合はまずこのタグ差を疑うとよい。
日本語サイトで走らせた：対照実験で分かった「静かな合格」
ここからが本題だ。当サイトの実記事1本（日本語・可視テキスト41,821文字）に対して、claude-seo の解析スクリプトを順に走らせた。
# ページ取得 → 構造解析 → 品質採点
claude-seo run fetch_page.py https://ai-heartland.com/tool/... -o page.html
claude-seo run parse_html.py page.html --url https://ai-heartland.com/tool/... --json
claude-seo run content_quality.py page.html --json
fetch_page.py は0.32秒で200を返し、251KBのHTMLを保存した。parse_html.py は以下を正しく抜き出した。
| 項目 | 抽出結果 | 判定 |
|---|---|---|
| title / canonical / meta description | 正常取得（descriptionは163文字） | ✅ 効く |
| H1 / H2 / H3 | H1×1・H2×25・H3×26 | ✅ 効く |
| 構造化データ | Article / BreadcrumbList / FAQPage / SoftwareApplication の4種 |
✅ 効く |
| 内部・外部リンク | 内部100本 / 外部31本 | ✅ 効く |
| 画像 | 9枚・alt欠落1枚を検出 | ✅ 効く |
word_count |
3,501 | ⚠️ 日本語で無意味 |
構造の抽出はほぼ完璧だ。特に構造化データの4種検出と、alt欠落の指摘は日本語サイトでもそのまま使える。descriptionが163文字という指摘も正しく、当サイトの内規（120〜160文字）を3文字超えていた——自分のサイトの粗を他人のツールに見つけてもらった格好である。
問題は word_count の3,501という値だ。この記事の可視テキストは41,821文字ある。実装を読むと re.findall(r"\b\w+\b", text) で数えており、Python の \w はUnicode対応なので日本語の連続した文字列がまるごと1語として数えられる。手元で確かめると、「これはテストです。単語は空白で区切られていません、しかし正規表現はどう数えるのか。」という41文字の日本語は 3語（句読点で切れた塊の数）と数えられた。同じ式で英語の53文字は9語になる。
つまり word_count は日本語では語数でも文字数でもなく、句読点で区切られた塊の数である。「本文が薄いか」の判断にこの値を使うと大きく外す。
決定的だったのは content_quality.py
content_quality.py は「QRG（品質評価ガイドライン）準拠のコンテンツ品質スコアラー」と自称しており、フィラー表現・AI特有の言い回し・情報密度・反復率から0〜100点を出す。当サイトの記事を採点させると、overall_quality 97点・フラグなしという結果になった。
一見すると褒められている。だが実装を読むと、この97点は日本語本文をほとんど見ていない。
# scripts/content_quality.py より
_TOKEN_RE = re.compile(r"[A-Za-z][A-Za-z'\-]*")
_NUMBER_RE = re.compile(r"\b\d+(?:[.,]\d+)?(?:%|st|nd|rd|th)?\b")
_ENTITY_RE = re.compile(r"\b(?:[A-Z][a-z]+(?:\s+[A-Z][a-z]+)+)\b")
トークナイザは [A-Za-z] で始まる語しか拾わない。エンティティ検出は「大文字始まりの英単語が2語以上連続する」パターンのみ。フィラー判定に使う27個のフレーズ（in today's fast-paced world、when it comes to など）もAIパターン判定のフレーズ（delve into、rich tapestry など）もすべて英語である。
つまり日本語のページを渡すと、フィラーもAIパターンも構造上ヒットしない。ヒットしなければ減点されない。減点されなければ高得点になる。日本語コンテンツは「良いから高得点」なのではなく「検査対象に入っていないから高得点」なのだ。
対照実験：同じ文章を英語と日本語で採点させる
推測で終わらせないために、対照実験をした。フィラーとAIパターンを意図的に詰め込んだ「AIスロップ」の文章を1本書き、それを英語版と日本語版で用意して、同じスクリプトに同じ方法で渡す。
claude-seo run content_quality.py）をそのまま使った実測。トークン数が113対1という差がすべてを説明している結果は記事冒頭のGIFのとおりだ。英語版は overall_quality 15・フィラー100・AIパターン100で、フラグに filler と ai-patterns が立ち、--threshold 60 を付けると終了コード1（不合格）になる。日本語版は overall_quality 65・フィラー0・AIパターン0で、終了コード0（合格）。決定的なのはトークン数で、英語113に対し日本語は1だった（「SEO」というASCII表記だけが拾われた）。
これは「日本語だと少し精度が落ちる」という程度の話ではない。品質ゲートとして使うと、日本語のスロップだけが素通りするという性質の問題だ。CIに組み込んで終了コードで合否を判定していたら、日本語記事はどれだけ酷い内容でも通る。
この挙動はドキュメントに書かれていない
公平を期すために、リポジトリ側が言語制約を明示していないか確認した。READMEの Limitations 節は「2つの本当の境界」として、①クライアントサイド・ハイドレーションのタイミング問題、②APIキーなしでは実データが取れないこと——の2点を挙げている。非英語コンテンツについての言及はない。 skills/ scripts/ docs/ README.md を japanese / cjk / multilingual / non-english で横断検索しても、該当する注意書きは見つからなかった。
むしろ逆で、多言語サイトを扱う seo-hreflang スキルの参照ドキュメント machine-translation-qa.md は、翻訳ページの検査について次のように指示している——「本文のAIパターン検出など、より広いスケールドコンテンツの採点は seo-content に委ね、claude-seo run content_quality.py を使え」。非英語ページを検査する唯一の導線が、非英語で機能しないスクリプトを指している。これはドキュメントの不備というより、英語圏で作られたツールが日本語に触れる典型的な断層だ。
併せて注意：content_quality.py はHTMLタグを剥がさない
同じ記事を「HTMLファイルのまま」渡した場合と「可視テキストだけ抽出して」渡した場合で、トークン数が20,498対2,035と10倍違った。スクリプト内にタグ除去処理が無いため、HTMLを直接渡すとCSSクラス名やJavaScriptの識別子まで採点対象に入る。使うなら本文テキストを自分で抽出してから渡すこと。
Claude Code SEO で効く部分と効かない部分の切り分け
ここまでの実測を、そのまま使い分けの指針にできる。判定軸はシンプルで、その検査が「決定的なPythonスクリプト」に載っているか、「Claudeの判断」に載っているかである。
| 機能領域 | 実装の性質 | 日本語での実効性 |
|---|---|---|
| 構造化データの検出・検証 | JSON-LDのパースと @type 照合 |
✅ そのまま使える |
| canonical / robots / hreflang | HTMLとヘッダの機械的検査 | ✅ そのまま使える |
| sitemap 生成・検査 | URL集合の操作 | ✅ そのまま使える |
| 画像alt欠落・遅延読み込み | 属性の有無 | ✅ そのまま使える |
| リンク構造（内部/外部） | href の分類 | ✅ そのまま使える |
| レンダリング差分（Playwright） | 実ブラウザでの描画比較 | ✅ そのまま使える |
| GEO / E-E-A-T の評価 | SKILL.md によるClaudeの判断 | ✅ 使える（LLMが日本語を読む） |
| コンテンツ品質スコア | [A-Za-z] 専用トークナイザ |
❌ 機能しない |
word_count |
\b\w+\b（日本語では句読点区切りの塊） |
❌ 実数と乖離する |
| エンティティ密度 | 大文字始まり英単語の連続 | ❌ ほぼ0になる |
処理の流れで見ると、日本語の壁がどこに立っているかがはっきりする。
HTTP取得 / Playwright描画"] B --> C["parse_html.py
title・見出し・JSON-LD・リンク・alt"] C --> D{"検査の種類"} D -->|"機械的な構造検査"| E["構造化データ / canonical
hreflang / sitemap / alt"] D -->|"決定的スコアリング"| F["content_quality.py
正規表現 [A-Za-z] に依存"] D -->|"読解と判断"| G["SKILL.md に沿って
Claude が評価（GEO・E-E-A-T）"] E --> H["日本語でも有効"] G --> H F --> I["日本語は採点対象外
= 減点されず高得点"]
要点は、日本語サイトで claude-seo を使うなら「構造とテクニカル」に用途を絞るということだ。逆にコンテンツ品質の判断は、スクリプトの点数ではなくClaude自身の読解（seo-content や seo-geo のSKILL.mdに沿った出力）を見るべきで、content_quality.py の数値をレポートに載せてはいけない。
同じ罠は自作のパイプラインでも起きる。単語をスペースで区切らない日本語では、number_of_words 系の実装がほぼ例外なく壊れる。当サイトでも読了時間の算出が同じ理由で長期間おかしくなっていたことがあり、これは claude-seo 固有の欠陥というより英語圏製ツールを日本語で使うときの構造的な注意点として扱うのが正しい。
APIキーなしでどこまで動くか（無料範囲の実測）
「結局いくらかかるのか」は導入判断で一番大きい。claude-seo の公式Limitations節は「無料枠は既定で第三者APIを呼ばない（監査対象URLの取得は行う）」と明記しており、実測でもそのとおりだった。
scripts/ 配下53本のうち、APIキーや認証情報を参照するのは17本。逆に言えば36本はキーなしで動く。
キーなしで動いたもの（実測）
・fetch_page.py（Googlebot UA での取得・SPAレンダリング切替を含む）
・parse_html.py（title/meta/見出し/構造化データ/リンク/画像）
・content_quality.py（※日本語では前述の制約あり）
・schema_generate.py / schema_ecommerce_validate.py 系の構造化データ処理
・Playwright による実描画（Chromium同梱のため追加DL不要）
キーが要るもの
・Google 系（Search Console / GA4 / PageSpeed / Natural Language API）
・DataForSEO・Ahrefs・SE Ranking・Firecrawl・Profound などのMCP拡張
・Bing Webmaster / Moz
つまり「サイトの構造を機械的に洗い出す」だけなら追加費用はゼロで完結する。一方で順位・検索ボリューム・被リンクといった外部データは、どのSEOツールでも有料であることに変わりはない。claude-seo はそれらを自前で持たず、拡張の口だけを開けておく方式を採っている。ここを誤解して「Semrushが無料になる」と読むと期待外れになる。
なお、実際に消費されるのはClaudeのトークンでもある。フルサイト監査は最大15エージェントを並列に立ち上げる設計なので、APIキーは不要でもトークンは相応に使う。小さく試すなら /seo page <URL> の単一ページ解析から始めるのが安い。
似たOSSとの比較 — seo-geo-claude-skills / Toprank / claude-rank
Claude Code 向けのSEOスキル集は claude-seo だけではない。当サイトで既に検証した3本と並べると、狙っている層がはっきり分かれる。
| OSS | ★ | 構成 | 主眼 | 日本語での注意 |
|---|---|---|---|---|
| claude-seo | 15,489 | 25スキル＋18エージェント＋53スクリプト | 網羅的なサイト監査（技術・E-E-A-T・GEO・ローカル・EC・多言語） | 品質スコアが英語専用 |
| seo-geo-claude-skills | 171 | 20スキル＋5コマンド | GEO（AI検索での引用獲得）に特化した120項目採点 | 採点基準が英語圏のSERP前提 |
| Toprank | — | プラグイン | SEOと Google/Meta 広告運用の接続 | 広告側は日本語アカウントでも動く |
| claude-rank | 95 | 10スキャナ・170項目 | AI検索に「発見・引用される」準備の診断と自動修正 | robots/llms.txt/JSON-LD中心で言語依存が小さい |
★の規模で言えば claude-seo が突出しているが、規模＝日本語での実用性ではないというのが本記事の実測の結論だ。むしろ claude-rank のように「robots.txt・sitemap・llms.txt・JSON-LD」といった機械可読な部分に絞ったツールのほうが、言語の影響を受けにくい。
claude-seo を選ぶ理由があるとすれば、1つのスキル束でテクニカルからGEOまで通しで見られることと、サブエージェントを並列に立てて大規模サイトを短時間で舐められることだ。逆に「日本語記事の品質を採点したい」が主目的なら、このツールの数値は使えない。
導入判断とアンインストール
実測を踏まえた推奨は次のとおり。
入れる価値が高いケース
・日本語サイトでも、構造化データ・hreflang・canonical・sitemap・画像altを機械的に棚卸ししたい
・複数サイトを扱っていて、監査手順をMarkdownとして共有・改変したい
・GEO（AI検索での引用）の観点を、Claude自身の読解として日本語で出させたい
入れても期待外れになるケース
・日本語記事の文章品質をスコアで判定したい（数値が機能しない）
・順位・検索ボリューム・被リンクを無料で取りたい（外部APIが必要）
・ディスクを1.3GB使えない、または全プロジェクト共通の ~/.claude/agents/ に18個のエージェントを常駐させたくない
アンインストールはスクリプトが用意されている。手動インストールした場合は、リポジトリ同梱の uninstall.sh を使うのが確実だ。
# 同梱スクリプトでアンインストール（推奨）
bash claude-seo/uninstall.sh
# 何が消えるか事前に確認したい場合
ls ~/.claude/skills | grep '^seo' # 31個のスキルディレクトリ
ls ~/.claude/agents | grep '^seo-' # 18個のエージェント定義
du -sh ~/.claude/skills/seo # 1.3GB の本体
31個のスキルディレクトリと18個のエージェント定義が別々の場所に置かれるので、~/.claude/skills/seo だけを消しても取り残しが出る。容量を戻したいだけなら ~/.claude/skills/seo/.venv と ~/.claude/skills/seo/ms-playwright の2つが1.29GBを占めているので、そこを消せば再セットアップで復元できる。
この記事で検証していないこと
正確を期すために、確認できなかった範囲を明示しておく。
・コミュニティ版（AI-Marketing-Hub/claude-seo）は未検証。 org権限がないため差分を取得できない
・Claude Code 内でのフルサイト監査（/seo audit）は未実施。 最大15エージェントの並列実行はトークン消費が大きく、本記事ではスクリプト層の決定的な挙動の検証を優先した。並列エージェントの出力品質は未検証である
・Google API連携（Tier 0〜3）は未検証。 実フィールドデータとインデックス状況の精度は評価していない
・READMEの「Real results」に掲載されたGSCグラフは第三者検証不能。 サイト名が明かされていないため、成長が本ツールに帰属するかは判断できない
参照ソース
- AgriciDaniel/claude-seo — 公式リポジトリ（README・skills/・scripts/・tests/）（2026-08-27 確認・v2.2.5 / ★15,489 / MIT）
- Google 検索セントラル｜AI 機能向けにウェブサイトを最適化する（2026-08-27 確認。claude-seo が GEO 判定の根拠として参照している一次資料）
- Claude Code Plugins — 公式ドキュメント（2026-08-27 確認。
/plugin marketplace addの仕様）
