mcpField
W
write-content

write-content

github.com/inhouseseoマーケティング・グロース373151 回インストール8 週間前に更新
リポジトリ

write-content について

マーケティング向けの記事作成スキルです。調査、コンテンツ形式の選択、知識の抽出、執筆を行い、ブランド情報の保持と定型的な文章を避けるルールを備えています。

主な機能

  1. 014段階の記事作成ワークフロー
  2. 02検索結果の調査と形式選択
  3. 03ブランド情報の継続保存
  4. 04実務者らしい文体ルール
  5. 05SEO構成と最終チェック

活用シーン

  1. 01キーワードからの記事作成
  2. 02コンテンツブリーフの記事化
  3. 03ブランドの声に合わせた記事調整

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/inhouseseo/superseo-skills --skill write-content

インストール後、Claude Code で/write-contentを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
anti-slop-ruleset.md
content-types-overview.md
eeat-signal-embedding.md
fact-checking.md
geo-optimization.md
human-input-framework.md
information-gain-writing.md
intent-matching.md
navboost-engagement.md
quality-scoring.md
seo-optimization-layer.md
references/content-types/
alternatives-page.md
buying-guide.md
case-study.md
category-page.md
comparison.md
definition.md
faq-page.md
glossary-page.md
how-to.md
integration-page.md
landing-page.md
listicle.md
location-page.md
news-article.md
pillar-page.md
product-page.md
programmatic-page.md
service-page.md
statistics-page.md

詳細

コンテンツを作成

SEO に最適化された記事を、完全な形で作成します。4 つのフェーズで進めます:調査 → コンテンツタイプの決定 → ナレッジの抽出 → 執筆。AI らしい低品質な文章を避けるためのルール一式と、プレスリリースではなく実務者らしい出力にするための文体ルールをすべて含みます。

入力

  • トピックまたはターゲットキーワード(必須)
  • (任意)既存のコンテンツブリーフ — 提供された場合は調査フェーズを省略します
  • (任意)expert-interview スキルからの専門家インタビューの出力

トピックが指定されていない場合は、先に確認してください。

ビジネスコンテキストの保持

ビジネスコンテキスト(対象読者、トーン、言語、ブランドの声、事例)は、すべての記事に影響します。セッションのたびに、これらの質問を繰り返さないでください。

初回利用時:4〜5 個の質問をして、回答をエージェントの環境内の永続的な場所に保存します。まずは最も安全なデフォルトを使用してください。

  • Claude Code:推奨されるデフォルトは ~/.claude/projects/<path>/memory/business-context.md です。ユーザーが明示的に求めない限り、./CLAUDE.md には書き込まないでください。CLAUDE.md はユーザーのプロジェクト指示ファイルであり、求められていない内容を追記すると、その後のエージェントの応答で毎回ユーザーを驚かせる可能性があります。
  • Claude Desktop / Claude.ai:プロジェクトのコンテキストまたはピン留めしたメモに保存します。
  • Cursor:.cursor/rules/business-context.md。
  • その他のエージェント:作業ディレクトリ内の seo-context.md。

保存する前に、必ず保存場所をユーザーに確認してください。これらの保存先が利用できない場合や、ユーザーが望まない場合は、セッションごとに質問し直してください。

初回利用時の質問:

  • 事業内容と対象顧客を教えてください。
  • ブランドのトーンはどのようなものですか?(プロフェッショナル/カジュアル/技術的/権威ある/会話的)
  • コンテンツは何語で作成しますか?
  • 絶対に扱ってはいけないトピックはありますか?(コンプライアンス、競合他社への言及など)
  • 主な競合他社を 2〜3 社教えてください。

フェーズ 1:調査

コンテンツブリーフが提供されていない場合は、トピックを Google で検索し、上位 5 件の結果を読みます。どの形式が上位に表示されているか、どのような切り口があるか、どんなギャップが見られるかを記録してください。完全なブリーフではなく、箇条書き 3〜5 項目にまとめます。

ブリーフまたは過去の会話に SERP 分析が含まれている場合は、このフェーズ全体を省略します。

フェーズ 2:コンテンツタイプの決定

上位表示されている内容をもとに、コンテンツタイプを選びます:ハウツー、定義・解説、比較(X 対 Y)、リスト記事・まとめ、製品レビュー、ケーススタディ、ピラーページ・完全ガイド、FAQ、ランディングページ、サービスページ、ニュース・トレンド分析。

次のように明確に伝えてください。 「[keyword] の上位結果はすべて [format] です。[key structural element] を盛り込んだ [content type] を作成します。この方針でよいですか?それとも、別のご希望がありますか?」

確認を待ちます。ユーザーが最初から記事全体を依頼している場合、または自律実行で応答する相手がいない場合は、選択したコンテンツタイプを理由とともに 1 行で示し、そのまま続行してください。

23 種類すべてのコンテンツタイプを扱う決定表については、references/content-types-overview.md を読み込みます。次に、H1/H2 の構成、スキーマ、強調スニペットの形式、CTA の配置、目標文字数を確認するため、該当するテンプレートを references/content-types/<type>.md から読み込みます(例:references/content-types/how-to.md)。完全なテンプレートが含まれているコンテンツタイプは 19 種類です:ハウツー、定義、比較、リスト記事、ピラーページ、FAQ ページ、ランディングページ、サービスページ、ケーススタディ、統計ページ、ニュース記事、用語集ページ、代替製品ページ、購入ガイド、製品ページ、カテゴリページ、インテグレーションページ、地域ページ、プログラマティックページ。概要表のみで扱われている 4 種類(ソートリーダーシップ、製品レビュー、料金ページ、会社概要ページ)は、E-E-A-T の基準が特に重要なため、eeat-audit/references/content-types/ にあります。

フェーズ 3:知識の抽出

ユーザー独自の知識を引き出すため、簡単な質問を2〜3個します。次の中から選びます。

  • 「[topic]について、ほとんどの人が誤解していることは何ですか?」
  • 「具体例を挙げてもらえますか?クライアント、プロジェクト、数字などです。」
  • 「実際にやってみて、意外だったことは何ですか?」
  • 「このアドバイスに従うべきではないのはどんな人で、その理由は何ですか?」

質問は一度に1つずつします。手短に進めます。

ユーザーが回答できない、または回答したくない場合、自律的に進める場合、あるいは質問を飛ばす場合は、フェーズ1の調査だけをもとに執筆し、納品時に、一次情報があれば記事の質を高められる箇所を記載します。

スタイルを調整する:

  • 新しいサイトや小規模なサイトで、SEOに詳しくないユーザーの場合:会話調にし、各質問が重要な理由を説明します
  • 実績のあるサイトで、経験豊富なユーザーの場合:手早く、率直に、過剰な説明はしません

フェーズ 4:記事の執筆

長さ:特定の文字数を目標にしないでください。フェーズ1で調査した上位表示コンテンツの深さに合わせます。長さは検索意図と競合状況に応じて決め、文字数を満たすために内容を水増しすることは決してありません。

整った Markdown で記事全体を作成します。以下のルールをすべて守ってください。

語り口と姿勢
  • 同業者に話す実務者のように書きます。教科書調にも、プレスリリース調にもなりません。
  • 明確な立場を取ります。「XもYも一長一短です」より、「私たちが試したところ、YよりXのほうがうまくいきました」と書きます。
  • 「あなた」や「私/私たち」を使い、大勢ではなく一人に向けて書きます。
  • 具体的な数字、名前、日付を含めます。「多くの企業」ではなく、必ず「[Company]が[year]に」のようにします。
  • 具体的な情報は事実に基づく必要があります。フェーズ1の調査、インタビューの回答、またはビジネスの背景から得た情報を使います。数字、名前、調査、引用を決して捏造しないでください。捏造した具体情報は、一般的な文章よりも悪質です。使える実例がない場合は、質問するか、その主張を削除します。
  • インタビューの回答は、一人称の経験として自然に織り込みます。自然に聞こえる表現はそのまま生かします。
  • 短縮形を使います。「does not」ではなく「doesn't」とします。
  • 考えが変わる過程を示します。「最初はブランディングの問題だと思っていました。でも、結局はずっと価格設定の問題でした。」自己修正は、人間らしさの表れです。
  • 現実の状況に根ざした内容にします。関連がある場合は、時事問題、業界の変化、文化的な話題に触れます。
リズムと構成
  • 文の長さに大きな変化をつけます。5語の短い文と、30語の複雑な文を織り交ぜます。長さが似た文を3文以上続けてはいけません。
  • 段落の長さに変化をつけます。1文だけの段落も、6文の段落も問題ありません。
  • 強調のために断片的な文を使います。自然であれば、「And」や「But」で文を始めます。
  • 括弧内の補足や短い脱線を含めます。人間はそうしますが、AIはそうしません。
  • 文体を切り替えます。技術的な説明の後に、くだけた一言を入れます。文体が一様なのは、AIらしさのサインです。
  • 「トピックセンテンス、説明、裏付け」のパターンを崩します。例や質問、読み進めて初めて意味がわかる一文から始める段落も作ります。
  • セクションごとの分量に偏りをつけます。興味深い部分には500語、退屈でも必要な部分には50語を割くこともあります。
  • 本当に複雑な場合(サブセクションが3つ以上)を除き、各セクションの最後にまとめを入れません。
述べるだけでなく、具体的に示す
  • 事実を述べるだけにせず、短い場面を通して示します。「ページ表示速度は検索順位に影響します」ではなく、「検索結果をクリックします。3秒が経ちます。まだ読み込み中です。戻るボタンを押します。Googleはその一瞬一瞬を記録しました」とします。
  • 経験に基づく主張は、そのときの状況を語ります。何を試し、何が起き、何に驚いたのかを示します。
アンチスロップルール

次の単語は絶対に使わないでください — AIらしさが特に強く表れる単語です。 delve, landscape(比喩的な意味), testament, leverage, utilize, robust, seamless, furthermore, moreover, additionally, pivotal, multifaceted, harness, embark, navigate(比喩的な意味), showcase, streamline, paramount, culminate, spearhead, commence, endeavor, vibrant, innovative, comprehensive(形容詞として)。

次のフレーズは絶対に使わないでください。 "It's worth noting", "In today's [anything]", "Let's dive in", "In conclusion", "plays a crucial/vital/pivotal role", "It goes without saying", "In the realm of"。

次の構成パターンは避けてください。

  • 3つの項目を並べる構成(代わりに2つまたは4つにします)
  • 類義語を次々と使うこと(別の表現を探すより、適切な単語を繰り返します)
  • コピュラの回避(「serves as」ではなく、単に「is」とします)
  • エムダッシュの連続(1000語あたり最大1~2個)
  • 二項対立(「XではなくY」ではなく、主張をそのまま述べます)
  • 分詞による後付け表現(「...highlighting the importance of X」のような表現は削除するか、別の文にします)
  • however、notably、essentially、that said、arguablyの多用。それぞれ単独で使うのは問題ありませんが、記事内で3つ以上使うとAIらしさが目立ちます
コンテンツの種類ごとの構成
  • ハウツー記事:最初に40~60語で簡潔に回答します(強調スニペットを狙います)。続いて番号付きの手順を示し、各手順では1つの操作と、その操作で問題が起きた場合の内容を扱います
  • 比較記事:最初に結論を示します(「Aを選ぶのは……の場合。Bを選ぶのは……の場合。」)。続いて詳しい分析を記載します
  • リスト記事:ページ上部に要約表を置き、各項目で一貫した評価基準を使います
  • 定義記事:前置きなしで、最初の文を「[用語]は……です。」にします
  • 事例記事:最初に成果を数値で示し、続いて経緯を説明します(PASフレームワーク)
  • ピラーページ:目次、概要の順に記載し、その後、詳細記事へのリンクを掲載します
  • サービス/ランディングページ:PASフレームワークを使います。まず問題点を示し、その影響を掘り下げてから、解決策を提示します
SEO構成
  • メタタイトル、H1、最初の100語、およびH2のうち2~3か所に主要キーワードを入れます。本文での密度は約2%とし、自然に配置します
  • 最も重要なH2の直後に、40~60語で端的な回答を置きます。強調スニペットを狙います。「方法」に関する質問には番号付きリスト、「とは何か」に関する質問には段落、比較には表を使います
  • PAAの質問を2~3件、H2またはH3の見出しとして記事に取り入れ、直接回答します
  • 1000語あたり3~5件の内部リンクを含めます。内容がわかるアンカーテキストを使い、「ここをクリック」は使いません
  • 価値のある情報を最初に示します。最初の画面が最も重要です。前置きの段落は入れません
長文記事の方針(1500語以上)
  • セクションごとに執筆します。既出の内容を繰り返したり、文体がぶれたりしないよう、説明済みの内容を記録します
  • 記事の少なくとも30%に、汎用的なAIでは書けない詳細を含めます。ユーザーのデータ、事例、意見、経験を取り入れます
最終チェック
  1. 「それで何が言いたいのか?」テスト:主なセクションごとに、誰でも、誰に向けても、何についてでも書ける内容になっていないか確認します。該当する場合は、具体的な知識を加えます
  2. セルフチェック:使用禁止の単語、すべての段落が話題文から始まるセクション、不要なセクションのまとめ、分詞による後付け表現がないか確認し、提出前に修正します
出力

クリーンなMarkdownにします。タイトルと記事本文のみを出力し、それ以外は含めません。

言語

ビジネス上の文脈で使われている言語で書きます。指定がない場合は、ユーザーのメッセージと同じ言語を使います

同梱のリファレンス

ステップまたはルールで指定された場合にのみ、references/ から読み込みます。事前に読み込まないでください。各ファイルの容量が大きく、重ねて読み込むとコンテキストを圧迫します。

コンテンツタイプのテンプレート(references/content-types/)— Phase 2 の後に1つ読み込みます:

  • 共通:how-to.md、definition.md、comparison.md、listicle.md、pillar-page.md、faq-page.md、landing-page.md、service-page.md、case-study.md
  • コンテンツとニュース:statistics-page.md、news-article.md、glossary-page.md
  • 商用:alternatives-page.md、buying-guide.md、product-page.md、category-page.md、integration-page.md、location-page.md、programmatic-page.md
  • 23種類すべてのコンテンツタイプを網羅する判定表については、references/content-types-overview.md を参照してください。どのタイプを選ぶか迷った場合は、まずこれを読み込みます。

ライティング手法のモジュール(references/)— 対応する Phase 4 のルールをさらに詳しく確認する必要がある場合に読み込みます:

  • anti-slop-ruleset.md — 禁止語の全リスト(段階別)と構成上の特徴の一覧(インラインのアンチスロップブロックで対処できない場合)
  • voice-injection-playbook.md — 文体とレジスターの手法(下書きが単調に感じられる場合)
  • information-gain-writing.md — 30%ルールとその満たし方(「それで何が言えるのか」テスト向け)
  • serp-driven-writing.md — Phase 1 のリサーチが記事に与える影響(下書きがSERPの意図から外れている場合)
  • intent-matching.md — 検索意図に基づく長さと形式の判断(SERPの意図が混在している場合)
  • eeat-signal-embedding.md — 略歴欄を設けずに経験を示す方法
  • structured-data-snippets.md — コンテンツタイプごとのJSON-LDと強調スニペットの書式
  • geo-optimization.md — AI Overview/生成エンジンによる引用に向けた最適化
  • navboost-engagement.md — エンゲージメント指標(滞在時間、スクロールの深さ)を高めるライティング
  • quality-scoring.md — 納品前に実施する自己評価基準
  • writing-pipeline.md — リサーチ → 下書き → 編集のサイクル
  • seo-optimization-layer.md — キーワードの配置、内部リンク、メタデータの確認
  • fact-checking.md — 具体的な数値や主張をすべて検証する方法
  • human-input-framework.md — 知識を引き出すための質問(Phase 3 の補強)

コメント