マーケ業務のAI自動化にmarketingskillsが選ばれる理由

AI エージェントにマーケティング業務を任せたい、という相談は増えています。ところが着手してみると、LP の改善提案を頼むたびに長いプロンプトを書き直し、出力の粒度は依頼した人とその日の書き方に左右される、という状態に行き着きがちです。

エンジニアリングであれば「テスト駆動で進める」「まず設計を書く」といった手順がある程度は共有知になっていますが、マーケティングの「型」は担当者の頭の中にある暗黙知になりやすく、エージェントに渡せる形式が定まりません。渡す素材がないので、結局は毎回ゼロから指示を書くことになります。

この課題に対して、CRO（コンバージョン率最適化）・コピーライティング・SEO・アナリティクス・グロースエンジニアリングといった領域の手順を、Agent Skills 仕様に沿った 50 本のスキルとしてパッケージしているのが、Corey Haines 氏の OSS である Marketing Skills（coreyhaines31/marketingskills）です。GitHub のスター数は 50,034、ライセンスは MIT で、Claude Code のほか OpenAI Codex・Cursor・Windsurf など Agent Skills 仕様に対応したエージェントで共通利用できると README に記載されています。

一方で、Agent Skills 形式のスキル集は公式のリファレンス集を含めて複数公開されており、初見では「これを選ぶ理由がどこにあるのか」が見えにくいのも事実です。日本語の解説記事はスキル数が 25 本だった v1.x 時点の情報で止まっているものが多く、現行の v2 系とは名称も構成も変わっています。

本記事では、リポジトリのメタデータと公開ドキュメント（README・AGENTS.md・tools/REGISTRY.md・各 SKILL.md・公式サイト・Agent Skills 仕様）だけを情報源として、marketingskills の構造・SKILL.md の設計・外部ツール連携・類似リポジトリとの違い・導入時の注意点を整理します。なお本記事はインストールや実行による動作検証は行わず、公開ドキュメントから読み取れる範囲に限って記述しています。コマンドや設定例はすべて公式ドキュメントからの引用として提示します。

marketingskillsとはどんなOSSか｜基本情報と50スキルの全体像

基本情報

まず、採用判断の入口になるリポジトリの基本情報を整理します。以下は 2026 年 9 月 14 日時点で gh api /repos/coreyhaines31/marketingskills から取得した値です。

ライセンスが MIT である点は、商用プロジェクトへの組み込み可否を判断する上で重要です。README の末尾にも「MIT - Use these however you want.」と明記されています。また archived / fork がいずれも false であるため、アーカイブ済みリポジトリや派生フォークにありがちな「本家との差分を追う必要がある」という前提は不要です。

誰向けのリポジトリかについては、README 冒頭が端的です。「Built for technical marketers and founders who want AI coding agents to help with conversion optimization, copywriting, SEO, analytics, and growth engineering.」とあり、コーディングエージェントを日常的に使う技術寄りのマーケター・創業者を想定読者に置いています。逆に言えば、ターミナルとエージェントの運用が前提にあるチーム向けであり、GUI 完結のマーケティングツールを期待する層とは想定がずれます。

50 スキルのカテゴリ俯瞰

skills/ 配下のディレクトリ数を数えると 50 あり、README の「Skill Categories」では以下の 9 カテゴリに整理されています。

注目したいのは ai-seo（AEO / GEO / LLMO と説明されている AI 検索向け最適化）や programmatic-seo のように、直近数年で輪郭が固まってきた領域まで含まれている点です。カバー範囲が「LP 改善とコピー」に閉じておらず、計測（analytics）・実験設計（ab-testing）・レベニューオペレーション（revops）まで広がっているため、マーケティング組織のワークフローの大半に対応づけられる構成になっています。

product-marketing を基盤にしたスキル間の依存関係

50 本がフラットに並んでいるわけではなく、README の「How Skills Work Together」に依存関係の図が掲載されています。要点は、product-marketing スキルがすべての基盤であり、他のスキルは作業を始める前にまずここを参照する、という設計です。README には「The product-marketing skill is the foundation — every other skill checks it first to understand your product, audience, and positioning before doing anything.」と書かれています。

つまり、自社のプロダクト・顧客・ポジショニングを 1 か所に書いておけば、CRO でもコピーライティングでも SEO でも同じ前提から出発します。エージェントに毎回「うちのサービスは〜」と説明し直す必要がなくなる、という意味で、暗黙知をファイルに落とす受け皿そのものがスキル集に組み込まれていると読めます。

さらに、スキル同士も相互参照します。README では copywriting ↔ cro ↔ ab-testing、revops ↔ sales-enablement ↔ cold-email、seo-audit ↔ schema ↔ ai-seo といった組み合わせが例示されています。単体のプロンプトを並べたものではなく、責務を分けた上で相互に呼び合う構造になっている点が、後述する SKILL.md の書き方にも表れています。

SKILL.mdはどう書かれているか｜プロンプト集との違い

「マーケのスキル集」と聞いて多くの人が想像するのは、コピペ用プロンプトを並べたリポジトリでしょう。marketingskills がそれと何が違うのかは、SKILL.md の中身を見るのが最短です。

Agent Skills 仕様に準拠している

marketingskills のスキルは Agent Skills 仕様に準拠しています。仕様上、スキルとは最低限 SKILL.md を含むディレクトリであり、任意で scripts/ references/ assets/ を持ちます。frontmatter では name（1〜64 文字、小文字英数字とハイフンのみ、親ディレクトリ名と一致）と description（1〜1024 文字、「何をするか」と「いつ使うか」を書く）が必須で、license / compatibility / metadata / allowed-tools が任意項目として定義されています。

仕様の中核にあるのが progressive disclosure（段階的開示）という考え方です。エージェント起動時には全スキルの name + description（約 100 トークン）だけを読み込み、スキルが発動したときに SKILL.md 本文（5000 トークン未満が推奨）を読み、references/ などはさらに必要になったときだけ読む、という 3 段階でコンテキストを節約します。

この仕様を理解しておくと、marketingskills の SKILL.md がなぜ独特な書き方をしているのかが見えてきます。

cro スキルの frontmatter から読み取れる設計

以下は skills/cro/SKILL.md の frontmatter です（改変なしの抜粋）。

---
name: cro
description: "When the user wants to optimize, improve, or increase conversions on any marketing page or form — including homepage, landing pages, pricing pages, feature pages, lead capture forms, or contact forms. Also use when the user says 'CRO,' 'conversion rate optimization,' 'this page isn't converting,' 'improve conversions,' 'why isn't this page working,' 'my landing page sucks,' 'form abandonment,' 'nobody's converting,' 'low conversion rate,' or 'this page needs work.' Use this even if the user just shares a URL and asks for feedback. For signup/registration flows, see signup. For post-signup activation, see onboarding. For popups/modals, see popups."
metadata:
  version: 2.0.0
---

出典: skills/cro/SKILL.md

ここから読み取れる設計上の判断は 3 つあります。

1 つ目は、description にトリガーフレーズを口語込みで大量に列挙していることです。「CRO」「conversion rate optimization」といった正式な用語だけでなく、「this page isn't converting」「my landing page sucks」「nobody's converting」のように、ユーザーが苛立ち混じりに打ちそうな表現まで含めています。progressive disclosure の設計上、起動時にロードされるのは description だけなので、スキルが発動するかどうかはこの 1,024 文字以内の記述に懸かっています。発動条件を語彙の網羅性で担保する、という割り切りが見て取れます。

2 つ目は、description の末尾に他スキルへのルーティング指示を書いていることです。「For signup/registration flows, see signup. For post-signup activation, see onboarding. For popups/modals, see popups.」という 3 文により、隣接領域の依頼が来たときに別スキルへ引き渡すよう促しています。責務分離をコードではなく description レベルで表現している形です。50 本規模のスキル集で誤発動を減らすための現実的な工夫といえます。

3 つ目は、本文が共有コンテキストファイルを先に読む前提になっていることです。SKILL.md 本文の冒頭には「Check for product marketing context first:」という見出しがあり、.agents/product-marketing.md が存在すれば質問する前にそれを読み、既に書かれている情報は聞き直さない、という指示が置かれています（旧パスの .claude/product-marketing.md と旧名 product-marketing-context.md もフォールバックとして参照する記述があります）。先ほど触れた product-marketing を基盤にする設計が、各スキルの本文レベルで徹底されているわけです。

evals によるアサーション検証

プロンプト集との最大の差分は、スキルの出力品質を検証するための evals/evals.json が同梱されている点です。prompt / expected_output / assertions[] の 3 要素からなる配列で、skills/cro/evals/evals.json の 1 件目は以下のようになっています（改変なしの抜粋）。

      "assertions": [
        "Checks for product-marketing.md",
        "Identifies page type as landing page",
        "Identifies conversion goal as free trial signup",
        "Analyzes value proposition clarity",
        "Analyzes CTA placement and copy",
        "Notes message match between ads and landing page",
        "Output has Quick Wins section",
        "Output has High-Impact Changes section",
        "Output has Test Ideas section",
        "Provides 2-3 headline or CTA alternatives"
      ],

出典: skills/cro/evals/evals.json

対応する prompt は「月間 5,000 訪問の広告流入があるが無料トライアル登録は 1.2% しか転換しない」という具体的なシナリオで、expected_output には「まず product-marketing.md を確認すべき」「ページ種別とコンバージョン目標を特定すべき」「Quick Wins / High-Impact Changes / Test Ideas に分けて提案すべき」といった期待挙動が文章で記述されています。

スキルを改変したときに何が壊れたかを言語化できる形になっているため、フォークして自社向けに手を入れる場合も、元の品質基準を参照しながら改変できます。自前でスキルを書き起こす場合と比較したとき、この検証データの存在は見落とされがちですが実質的な差分です。

references への分割と段階的読み込み

skills/cro/references/ には experiments.md と form.md が置かれています。SKILL.md 本体を 500 行未満に保ちつつ、詳細なフレームワークは別ファイルへ逃がすという Agent Skills 仕様の推奨に沿った分割です。実験設計やフォーム最適化の詳細が必要になった局面でのみ読み込まれるため、常時のコンテキスト消費を抑えられます。

50スキルを支える外部ツール連携レイヤ｜GA4・Search Consoleを引ける仕組み

marketingskills がスキル集の枠にとどまらないのは、tools/ 配下に外部 SaaS との連携レイヤを同梱しているためです。スキルが「こう分析しましょう」と指示を出すだけでなく、実データを取りに行ける構造になっています。

REGISTRY.md の索引構造

中心にあるのが tools/REGISTRY.md です。冒頭に「Quick reference for AI agents to discover tool capabilities and integration methods.」とあるとおり、人間が読むドキュメントである以上に、エージェントが「このツールはどの手段で叩けるか」を引くための索引として設計されています。

索引は Tool | Category | API | MCP | CLI | SDK | Guide という表形式で、各ツールについて利用可能な連携手段にチェックが入ります。カテゴリは以下のように広く取られています。

tools/integrations/ 配下のツール別連携ガイドは 90 本を超え、tools/clis/ の Node.js スクリプトも 60 本を超えます（いずれもリポジトリのファイル数を数えた値です）。GA4 と Search Console、さらに Ahrefs や Semrush まで引けるということは、CRO や SEO の判断材料になる実数値をエージェントの手元に持ち込めるという意味になります。「スキルを入れても結局データ収集は人が手でやる」という状態を避けるための層が用意されている、と整理できます。

依存ゼロの Node.js CLI と --dry-run

CLI の性格は AGENTS.md に記載があります。tools/clis/*.js は依存ゼロの Node.js スクリプト（Node 18 以上）で、検証手順として以下が示されています（改変なしの抜粋）。

node --check tools/clis/<name>.js   # Syntax check
node tools/clis/<name>.js           # Show usage (no args = help)
node tools/clis/<name>.js <cmd> --dry-run  # Preview request without sending

出典: AGENTS.md

外部 SaaS に書き込む可能性のある操作について、送信前にリクエスト内容をプレビューできる --dry-run が用意されている点は、エージェントに実行権限を渡す際の安全弁として評価できる材料になります。依存ゼロで Node.js 18 以上という前提も、導入時の環境要件が軽いことを示しています。

類似リポジトリとの違いと選び分け｜Agent Skills集をどう比較するか

Agent Skills 形式のリポジトリは他にも公開されており、スター数だけを見ると marketingskills より大きいものもあります。ただし、比較すべきなのはスター数ではなく「何を対象にしているか」です。以下は 2026 年 9 月 14 日時点の実測値です。

この表を踏まえると、選定の判断軸は次の 3 つに整理できます。

1. 解きたい課題がマーケティング職能か、開発プロセスか。 obra/superpowers は「どう開発を進めるか」の型を提供します。エージェントの出力品質を上げたい対象が実装作業であれば、そもそも marketingskills は対象領域が違います。逆に LP の改善提案や広告コピー、SEO 監査の品質を上げたいのであれば、開発方法論のスキルを入れても解決しません。

2. 欲しいのが役割定義か、手順書か。 wshobson/agents は「CRO 専門のサブエージェント」のように役割を増やす設計です。marketingskills は既存のエージェントに知識と手順を注入する設計で、役割は増えません。マルチエージェント構成を前提に組織を作りたいのか、単一のエージェントに型を持たせたいのかで選択が分かれます。

3. 外部 SaaS のデータ連携まで必要か。 公式の anthropics/skills はスキルの書き方と汎用処理のリファレンスとしては最も信頼できますが、GA4 や Search Console を叩くための連携ガイドや CLI は含まれません。計測データを取りに行くところまでエージェントにやらせたい場合、先ほど触れたツール連携レイヤの有無が実務上の差になります。

なお vercel-labs/skills（スター 31,565 / MIT）は、これらと並ぶ選択肢ではありません。marketingskills の README が推奨するインストール手段そのもの（npx skills）であり、競合ではなく前提ツールとして扱うのが適切です。

スター数の大小は「どちらが優れているか」を示しません。公式リファレンス集と職能特化のスキル集は併用もでき、README は Agent Skills 仕様準拠を明言しているため、同じ skills/ ディレクトリに共存させられます。

導入方法と、入れる前に確認しておきたいこと

6 通りの導入経路

README の「Installation」には 6 通りの方法が並んでいます。CLI インストール（推奨）、Claude Code プラグイン、clone してコピー、git submodule、fork してカスタマイズ、SkillKit（マルチエージェント向け）です。

推奨されている CLI 経由のコマンドは以下のとおりです（改変なしの抜粋）。

# Install all skills
npx skills add coreyhaines31/marketingskills

# Install specific skills
npx skills add coreyhaines31/marketingskills --skill cro copywriting

# List available skills
npx skills add coreyhaines31/marketingskills --list

出典: README.md

Claude Code のプラグインとして入れる場合は以下です（改変なしの抜粋）。

# Add the marketplace
/plugin marketplace add coreyhaines31/marketingskills

# Install all marketing skills
/plugin install marketing-skills

出典: README.md

--skill による個別指定が用意されている点は、導入判断において重要です。Agent Skills の progressive disclosure では全スキルのメタデータが起動時に読み込まれるため、50 本すべてを入れると常時のコンテキスト消費がそのぶん増えます。まず cro と copywriting だけ、といった形で絞って評価する経路が公式に用意されています。

インストール先ディレクトリの落とし穴

README には CLI の挙動について注意書きが置かれています。CLI はインストール済みのエージェントを検出してどこに入れるか尋ね、Claude Code 向けには .claude/skills/、汎用エージェント向けには共有の .agents/skills/ に配置されます。

ここで問題になるのが、エージェントのセッション内部からインストールコマンドを走らせるケースです。README の TIP には、エージェントセッション内部から実行すると CLI が非対話モードで動き、Claude Code が読まない汎用の .agents/skills/ にしかインストールされない場合がある、と明記されています。回避策として以下のようにエージェントを明示する方法が示されています（改変なしの抜粋）。

npx skills add coreyhaines31/marketingskills -a claude-code

出典: README.md

「入れたはずなのにスキルが発動しない」という状況になりやすい箇所なので、導入時に確認しておく価値があります。

v1.x から移行する場合に発生する手作業

既に v1.x を導入している環境からの移行には、ドキュメントに明記された手作業が伴います。README の「Upgrading from v1.x to v2.0」によれば、v2.0 で 17 スキルがリネームされ、page-cro と form-cro は cro に統合されました。

問題は、新しいスキルが古いスキルと並んでインストールされるため、インストール先に旧名のフォルダが残留する点です。README は「you'll have stale old-name folders in your install directory after upgrading」と説明し、rm -rf による削除対象を具体的に列挙した上で、その後に v2.0 のスキルを再インストールする手順を案内しています。旧名が残ったままだと、同じ役割のスキルが二重に存在することになります。

加えて、共有コンテキストファイルの場所も変わりました。v2.0 では .claude/product-marketing-context.md が .agents/product-marketing.md に移動・改名されています。README には旧パスと旧名をフォールバックとして参照する旨も書かれているため、移行しなくても壊れはしませんが、新規に構成を組むなら新しいパスに寄せておくほうが素直です。

日本語の解説記事の多くが v1.x 時点の名称（page-cro / analytics-tracking / schema-markup など）で書かれているため、既存記事を参考に構成を組むと現行版と食い違います。README の「Full rename map」で旧名と新名の対応を確認しておくと混乱を避けられます。

メンテナンス状況と、スポンサードOSSの中立性をどう見るか

業務に組み込むかどうかを判断するとき、機能と同じくらい重要なのが「この先も更新されるか」「推奨内容が特定ベンダーに寄っていないか」です。marketingskills はこの 2 点について、ドキュメント上で確認できる材料を持っています。

リリース頻度と 2 層バージョニング

リポジトリの作成は 2026 年 1 月 15 日で、最新リリースは 2026 年 9 月 5 日の v2.11.1 です。8 か月弱で v2.11 系に到達しており、v2.9.0 から v2.11.1 までの間にもパッチリリースが短期間で連続しています。最終 push も 2026 年 9 月 5 日と直近です。

更新を追える設計になっているかどうかは、AGENTS.md の「Versioning」に記述があります。バージョンは 2 層で管理されます。

1 層目はリポジトリのリリース版で、.claude-plugin/plugin.json と .claude-plugin/marketplace.json、VERSIONS.md の見出しが同一の x.y.z を共有します。x はリポジトリ全体の再構成や破壊的変更、y は新規スキルの追加、z は既存スキルの更新に対応します。既存スキルへの追記はどれだけ大規模でも y を上げない、と明示されています。

2 層目はスキル個別のバージョンで、各 SKILL.md の metadata.version が VERSIONS.md の表に反映されます。ここで重要なのは、更新チェックが VERSIONS.md と利用者のローカルスキルのメタデータを比較する仕組みだという点です。AGENTS.md には「an unbumped change is invisible to installed users」と書かれており、bump 漏れが利用者から見えなくなることを運用ルールとして自覚した上で、あらゆる出荷変更でのバージョン更新を義務づけています。

「入れたら入れっぱなしになり、いつの間にか古い型で運用し続ける」という状態を避ける仕組みが設計に含まれているかどうかは、スキル集を継続運用するうえでの判断材料になります。

一方で、open issues は 112 件あります。更新が活発である裏返しとして未処理の issue も積み上がっている状態で、これを許容できるかは導入側の判断になります。件数そのものは、コントリビューションが集まるリポジトリでは珍しい水準ではありません。

Verified Partners 制度と中立性の担保ルール

marketingskills は MIT の無料ライブラリでありながら、スポンサー（Verified Partners）が資金提供する形で運営されています。2026 年 9 月時点では Converly（コンバージョン計測・アトリビューション）と Ploy（AI ウェブサイト／グロース基盤）の 2 社が掲載されています。

推奨内容がスポンサーに寄るのではないか、という懸念は当然出てきます。この点について tools/REGISTRY.md は、境界線を明文化しています。

• 開示: 各連携ガイドに disclosure ヘッダを置き、索引では ◆ 印で識別します
• Additive, never biasing: パートナーは同じ用途の中立的な選択肢と並べて掲載され、置き換えはしません。パートナーであることが他ツールを削除・降格させることはありません
• 推奨内容に影響しない: 「never changes what any skill recommends — if a non-partner is the right answer, that's the answer」と明記されています
• バッジの意味: ◆ 印は「paid, disclosed, vetted for fit」であって「best in category」ではない、と限定しています

さらに、ツールに言及するコンテンツの採否基準は CONTRIBUTING.md の integrity rubric（選択肢を示すこと・開示すること・swap test を通ること）に委ねられています。パートナー表と索引は partners.json から node scripts/sync-partners.mjs で生成される運用で、手編集を前提にしていません。

これらのルールが守られているかを外部から完全に検証することはできませんが、ガバナンス文書が独立して存在し、開示マーカーと生成スクリプトで機械的に運用されていること自体は、スポンサード OSS を業務に組み込む際の判断材料になります。少なくとも「どこまでが広告でどこからが中立の推奨か」の線引きが明文で示されている状態です。

marketingskillsの採用を判断するためのチェックポイント

ここまでの内容を、冒頭に置いた 3 つの問い（採用すべきか／何が違うか／メンテナンスは健全か）に対応づけて整理します。

向いているケース

• マーケティング施策の型を組織で共有したいものの、社内にドキュメント化された手順がありません。product-marketing を基盤にした構造は、共有コンテキストを 1 か所に集約する受け皿になります
• Claude Code 以外のエージェント（Codex・Cursor・Windsurf など）でも同じスキルを使いたい。Agent Skills 仕様準拠のため、エージェントを乗り換えても資産が残ります
• GA4・Search Console・Ahrefs などの実データ連携まで含めてエージェントに任せたい。連携ガイドと CLI が同梱されており、--dry-run で送信前の確認もできます
• 商用プロジェクトに組み込みたい。MIT ライセンスのため、利用条件の制約が軽いという利点があります
• スキルをフォークして自社向けに改変したい。evals/evals.json が品質基準の参照点になります

慎重に判断すべきケース

• スキルの内容は英語で書かれており、想定している商習慣も英語圏のものです。日本語圏のマーケティング慣行（商談プロセス・広告媒体の構成など）と噛み合わない箇所は、フォークして手を入れる前提で見積もる必要があります
• v1.x から移行する場合、旧名フォルダの削除とコンテキストファイルの移動という手作業が発生します。README に手順は明記されていますが、自動では解決しません
• 50 スキルすべてを入れると、起動時に読み込まれるメタデータがそのぶん増えます。--skill による選択インストールから始めて、必要なものだけ追加する運用も検討対象です
• open issues が 112 件ある状態をどう評価するかは、導入側のリスク許容度によります

次に取れる行動

判断材料をさらに集めるなら、リポジトリの README でスキル一覧と依存関係の図を確認し、自チームが最も困っている領域のスキル（たとえば skills/cro/SKILL.md）を 1 本だけ読んで、記述の粒度が自社の期待に合うかを見るのが効率的です。パートナー制度の詳細まで確認したい場合は tools/REGISTRY.md と PARTNERS.md、仕様そのものを押さえたい場合は Agent Skills の仕様書が一次情報になります。

本記事はすべて公開ドキュメントとリポジトリメタデータに基づく整理であり、インストールや実行による検証は含みません。導入を決める前に、自チームの環境で --skill を使った小さい範囲から評価する経路が用意されている点を、判断のしやすさとして数えてよいでしょう。

関連情報

AI エージェントの業務組み込みや、社内ナレッジをエージェントが扱える形に整備する取り組みをご検討中の方は、お問い合わせフォーム からご相談ください。要件の整理段階からご相談いただけます。