mcpField
P
publish-article

publish-article

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

publish-article について

記事公開の準備を支援するスキルです。キーワード、著者表記、画像、外部リンク、公開前チェックを扱い、オリジナル記事、バックリンク、支給原稿の各モードを区別します。

主な機能

  1. 01公開モードと工程チェック
  2. 02キーワードとタイトルの計画
  3. 03バックリンクのアンカーテキスト計画
  4. 04独自調査とデータ提示の要件
  5. 05画像、出典リンク、語数の確認
  6. 06支給原稿の意図の保持

活用シーン

  1. 01検索需要に沿った記事タイトルの計画
  2. 02対象ページへのリンクを含む記事の準備
  3. 03オリジナル記事の出典とデータ提示の確認
  4. 04支給原稿の内容を変えずに公開準備

インストール

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

$npx skills add https://github.com/openclaudia/openclaudia-skills --skill publish-article

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

詳細

記事を公開する

記事を書くのは簡単なほうです。このスキルでは、公開したページがトラフィック、引用、リンク価値を獲得できるかどうかを左右する要素を扱います。タイトルの付け方、著者の表記、掲載する画像、外部リンクの内容、そして意図したとおりに表示されているかどうかです。

以下の各ルールには、公開前に実行できるチェック項目があります。チェック項目のないルールは見落とされるため、必ずチェックしてください。

モード

  • コンテンツモード(デフォルト) — オリジナルの記事を公開します。バックリンクはありません。
  • バックリンクモード — 同様に公開しますが、ターゲットページへの、計画されたキーワードリンクを1つ追加します。
  • 提供原稿モード — ユーザーから完成した公開用原稿を受け取ります。以下の「提供された原稿は変更不可」を参照してください。このモードでは執筆ガイダンスは適用されませんが、検証は必須です。

ゲート1 — 執筆前にタイトルキーワードを測定する

これは、ページを公開する価値があるかどうかを最も大きく左右する判断であり、通常は執筆中に直感で決められています。最初の一語を書く前に、次の表を出力してください。

候補となる主要フレーズ月間検索数難易度ターゲットトピックの関連グループに属しているか

検索数は必ず測定し、推測してはいけません。 記事独自の発見から作ったフレーズ(「1.3%のナレーションの差」「配信の問題」など)は、作られた時点で検索数がゼロです。まだ読んだことのない造語を検索する人はいません。巧妙なタイトルは、たまに起こる失敗ではなく、ここでの典型的な失敗パターンです。

勝者となるフレーズは、実際に競争するトピックの関連グループに属していなければなりません。 これはより見抜きにくい失敗で、検索数のチェックを問題なく通過してしまいます。スライド作成製品へのリンクであれば、ai training video generator(月間250回)はai training slides(月間0回)を検索数で上回りますが、それでも間違った選択です。記事が動画を求める人向けに上位表示される一方、ターゲットが販売しているのはスライドであり、選択が最適に見えるまさにその瞬間に、トピックとの関連性を示すシグナルが弱まります。隣接する別のグループの大きな数字ではなく、適切なグループ内で最も根拠のあるフレーズを選んでください。

キーワードツールはAI関連やロングテールの検索数を大幅に過小評価します。「0」を「需要なし」と解釈しないでください。 ツールが検索数を0と報告していても、自分のSearch Consoleでは検索順位1位でクリックを獲得しているフレーズがあります。Search Consoleのデータとキーワードツールの結果が異なる場合は、Search Consoleを優先してください。ツールは候補同士の比較にのみ使います。

古いスラッグからのリダイレクトを保持するCMSであれば、公開後の修正にほとんど手間はかかりません。そのままにせず、修正してください。URLがインデックス登録されるか、引用されると、変更できる期間は終わります。

ゲート2 — アンカーとトピックを計画する(バックリンクモード、執筆前)

バックリンクの価値は、アンカーテキストと、周囲の記事がターゲットページと同じ内容を扱っているかどうかによって決まります。どちらもあらかじめ決めて明示し、執筆中にその場で考えてはいけません。

サイト記事の切り口アンカーアンカーの種類

まず、そのターゲットページにすでに向けられているアンカーを確認してください。 新しいアンカーは単独で決めるのではなく、既存の分布を踏まえて選びます。

  • すべてのアンカーに、ターゲットキーワードまたは明らかな類語を含めてください。 ブランド名や一般的なアンカー(こちら、このツール、ブランド名のみ)では、狙っているキーワードへの評価はほとんど伝わりません。キーワードを含むアンカーを用意してから、こうしたアンカーを1つだけ使ってください。
  • 表記に変化をつけてください — 完全一致、複数形、ブランド名+完全一致、一部一致。どの掲載先でも同一のアンカーを繰り返すのは、リンク購入を示す最も明白な痕跡です。
  • 記事のトピックはターゲットページのトピックと一致していなければなりません。 電動自転車の記事から教育動画のページにリンクしても、アンカーがどれほど優れていても価値はほとんどありません。
  • 1記事につき、ターゲットへのリンクは1つにしてください。 2つ目を追加しても価値はなく、不自然に見えます。
  • ゲート1の2つのルールをアンカーにも適用してください。AI training presentation makerはキーワードらしく見えますが、実際に検索する人はいません。実際に需要があるフレーズはAI training presentationです。

独自調査(独自の内容のみ)

プレスリリース、企業ブログの投稿、通信社の記事は、記事の出発点であって記事そのものではありません。情報源を開くだけでは読者が得られない何かを加えてください。

  • 発信元の情報源に加え、異なる事実を提供する独立した一次情報源を少なくとも2つ確認してください。転載や配信記事は1つの情報源として数えます。
  • 計算、比較、順位付け、または経時的な変化の追跡によって、少なくとも1つの独自の発見を示してください。結果の横に、再現できるよう分母、期間、手法を明記してください。
  • データを含む記事には、表を1つ、グラフを1つ含めてください。表には正確な値を示し、グラフには傾向を示します。比較可能なカテゴリーには棒グラフ、実際の時系列データに限り折れ線グラフを使用してください。2つのデータポイントを無理に装飾的なグラフにしたり、このルールを満たすために数値を捏造したりしないでください。比較可能なデータが実際に存在しないテーマでは、構造化した比較表を掲載し、グラフが誤解を招く理由を説明してください。
  • グラフは補足的な編集用メディアとして、説明的な代替テキストと、出典・手法を示す明記された行を添えて本文に埋め込んでください。カバー画像にはしないでください。

公開前に、使用した情報源、独自の発見、表の行数、グラフの種類、単語数を記載してください。原稿の大半が発表内容の言い換えである場合は、公開せず、さらに調査してください。

提供された原稿は、デフォルトで変更不可です

ユーザーが記事、草稿、タイトル、または文章を提供し、それを公開するよう求めた場合、その文章は概要ではなく、承認済みの原稿です。明示的な許可なしに書き換えてはいけません。

  • 提供されたタイトル、主張、切り口、例、結論、トーン、順序、確実性の度合いを維持してください。ユーザーの主張を、より無難なものや一般的なものに置き換えてはいけません。
  • 編集の指示で許可されるのは、依頼された方向性に限られます。「より断定的にする」とは、提供された主張を強めるという意味であり、その主張自体を変更する許可ではありません。
  • 事実確認は引き続き必要です。確認によって、提供された主張を実質的に変える修正が必要な問題が見つかった場合は、その問題と修正案を正確に示し、公開前に許可を得てください。別の主張に黙って差し替えてはいけません。
  • 書き換えの許可がない場合、変更は文章を維持する公開上の体裁に限ってください。Markdown の書式、エスケープ処理、プラットフォームの構文、依頼された画像の配置が対象です。
  • 公開前に、最終原稿と提供された原稿を差分比較してください。実質的な変更はすべて、現在の依頼に明示された指示に対応していなければなりません。対応していない変更があれば、作業を止めて確認してください。

品質基準 — 公開する記事はすべて、以下を満たす必要があります

1. タイトル
  • <title> が SERP に収まるよう、最大約60文字にしてください。ダッシュで補足をつなぐ複数節の見出しは避け、中心となるフック1つに絞ってください。
  • **検索される対象をタイトルに入れてください。気の利いた切り口より固有名詞を優先します。**人は概念ではなく、人名、製品名、企業名で検索します。Demis Hassabis steps down, Jeff Dean leaves Google は、両方の人名と企業名がそのまま検索語になるため、Who runs Google AI now? より優れています。
  • **基準は「誰かがこのタイトルを検索窓に入力するか」であって、「固有名詞が含まれているか」ではありません。**誤った固有名詞は、固有名詞がないのと同じくらい役に立ちません。読者が実際に検索する語句を2~3個書き出し、タイトルにその語句が含まれているか確認してください。実際には、次の2つのパターンで失敗します。
    • 主題ではなく情報源の名前を入れる。The Information Drew Dario Amodei as a Prophet には固有名詞が2つ含まれていますが、検索語である Anthropic IPO が抜けています。報道した媒体名は署名欄に記載し、タイトルには入れないでください。
    • **文字数をトーンに費やす。**皮肉めいた一言を加えることで、statue、cast、review、price、specs のいずれかが入らなくなるなら、最も検索ボリュームの大きい語を失うことになります。一言を削り、名詞を残してください。
  • H1 は必ず1つだけにしてください。タイトルがページの H1 になるため、本文を独自の # 見出しで始めたり、タイトルを繰り返したりしてはいけません(本文の見出しは H2 以降にしてください)。
2. 著者

実際の著者を明記してください。CMS のデフォルト、「Staff」、null の場合の代替値は使わないでください。著者レコードには名前と自己紹介を含め、可能であればアバターも設定してください。代替値のまま公開するのではなく、必要なら作成してください。資格や専門知識を捏造してはいけません。

3. 画像
  • 選定順:まずパブリックドメインの写真、次に AI 生成画像。 何かを生成する前に、実際の被写体を Wikimedia Commons で検索し、ライセンスが Public domain または CC0 のファイルだけを使用してください。技術的には帰属表示で条件を満たせる場合でも、CC BY、CC BY-SA、そのほか誰かが定めた条件を伴うものは決して使用しないでください。Commons API(list=search&srnamespace=6、続いて prop=imageinfo&iiprop=extmetadata)を使用し、LicenseShortName で絞り込んでください。また、実際の User-Agent を送信してください。送信しないと 403 が返されます。パブリックドメインのカバー画像には、記事の末尾にイタリック体でクレジットを記載してください。
  • 被写体が実在する特定の物や場所なら、実物の写真を優先してください。 実在する物の AI 生成画像は、その見た目を捏造することになり、画像で覆い隠した捏造にほかなりません。被写体の無料写真がない場合は、被写体を捏造した写真よりも、舞台となる場所のパブリックドメイン写真を優先してください。
  • 横長で、画像内に文字を埋め込まないでください。OG 画像ならおよそ 1200x630 が目安です。タイトルは画像ではなくページに表示します。比率が合わない場合は、トリミングするか再生成してください。
  • リアルな画像にし、「AI っぽさ」を避けてください。 編集用写真のような見た目にし、光沢のある過剰な描写や、複数の物体を融合させるような比喩の詰め込みは避けてください。概念的な画像は純粋な科学の話題に限定し、ビジネス、政策、製品の記事には現実的な場面を使ってください。
  • OG 画像の URL が解決されることを確認してください。curl -I が 200 を返し、プレースホルダーではなく、絶対 URL の https:// である必要があります。
  • 記事ごとに異なる画像を使ってください。 まとめて作成する場合は、distinct(images) == count(articles) を確認してください。重複画像を公開するより、フィールドを省略してプラットフォームに生成させるほうが適切です。
4. 外部の出典リンク — 本文中に最低 2 件
  • 文章中で出典に言及するだけでは不十分です。リンクしてください。 主張を確認したい読者がワンクリックで出典にたどり着ける必要があります。リンクのない出典は評価されません。
  • 一次資料がある場合はそれ(届出書類、データセット、リリース、事件記録、裁判所命令)に、ない場合はそれを伝えた報道記事にリンクしてください。アンカーテキストは内容がわかるものにし、「ここ」は使わないでください。
  • 公開前に確認してください:grep -c '](http' <body> が 2 以上であること。公開直後の記事を 10 件監査した際、6 件は文章中で出典に言及していたものの、リンクは一つもなく、クローラーは正しく外部リンクをゼロ件と報告しました。
5. 長さ — 公開前に語数で測定
  • サービス記事または解説記事は最低約 1,000 語とし、対象の検索クエリについて実際の SERP を確認してください。上位の結果が 1,500 語以上なら、それに合わせてください。1,500 語の記事と競合する 500 語のページは、どれほどよく書かれていても上位に表示されません。
  • len(body) ではなく、必ず len(body.split()) で確認してください。 文字数を数えても、語数のしきい値は満たせません。
  • 内容のある長さにしてください。実際の疑問に答えるセクション、具体的な事例、数値、固有名詞、失敗モードを盛り込んでください。水増しは、短い記事よりも悪い結果になります。
  • 記事ごとの語数を出力し、薄い記事が平均に埋もれず確認できるようにしてください。

X の投稿を埋め込む

記事の出典や画像が X の投稿である場合は、画像をコピーせずに投稿を埋め込みます。画像は投稿者のプラットフォームライセンスのもとで配信され、クレジットも自動で表示されるため、著作権侵害のリスクはありません。

埋め込む前に、次の4つすべてを満たしている必要があります。

  1. 投稿が公開されている。
  2. 投稿者が実際の権利者である。別の人の画像を誰かがリポストした投稿は、決して埋め込まないでください。これはパブリッシャーが訴えられる原因となる典型的なパターンです。
  3. 公式の埋め込みマークアップを使用する。スクリーンショットやダウンロードしたコピーは決して使用しないでください。
  4. その投稿が記事の出典または主題であり、飾りではない。
<blockquote class="twitter-tweet" data-dnt="true"><p lang="en" dir="ltr">FULL TWEET TEXT
HERE</p>&mdash; Author Name (@handle) <a
href="https://twitter.com/handle/status/TWEET_ID">Month D, YYYY</a></blockquote>
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
  • 実際のツイート本文を必ず含めてください。投稿が削除された場合でも、空のボックスではなく、リンク付きの読みやすい引用が代わりに表示されます。
  • 背景が暗いサイトでは、data-theme="dark" を追加してください。 デフォルトの埋め込みは白いカードで表示されるため、暗いページではまぶしく見えます。
  • 投稿について説明している段落の直後に配置してください。カバー画像や OG 画像として使うことはできません。

返信も読み、その意見を解説に活用してください。 返信から探すのはエンゲージメント数ではなく、解釈です。投稿が何を意味するかについての説、懐疑的な別解釈、背景を補足する分野の専門家の見解などを見つけます。返信者を明記したうえで、2つか3つを反応を扱うセクションに盛り込み、印象的な短いフレーズを引用し、投稿自体の主張と照らし合わせてその説を検討してください。冗談の返信を使うのは彩りとして1回だけにし、分析には使いません。返信が冗談だけなら、その旨を1行で述べてください。その空虚さ自体が発見です。

引用される記事を書く

獲得した被リンクだけが、積み重なっていく被リンクです。これは、十数の出版物を対象としたネットワーク全体の被リンク監査から導き出された結論です。自然に獲得したリンクはすべて、具体的で検証可能な1つの主張を参照するのに最も便利なページに向けられていました。ホームページやまとめ記事は、何も獲得しませんでした。

  1. 概念に名前が付いたその週に、解説記事を書く。 標準となるページが存在する前に書きます。その日のニュース記事では何も獲得できませんが、定義を説明するページは何カ月にもわたってリンクを獲得します。
  2. タイトルには、読者が実際に入力する文字どおりの質問を使う。 その監査で最も多くの参照元を獲得したページは what-does-yann-lecuns-world-model-mean-explained でした。そこに名前が入っているだけで、仕事の半分は終わっています。固有名詞のない質問は、誰も検索しない質問です。
  3. 記事ごとに独自の数値を1つ示し、1回だけ、引用しやすい文で述べる。 段落全体に散りばめてはいけません。引用可能な統計を探しているライターが、1つの節をそのまま抜き出せる必要があります。
  4. 記事ごとに引用可能な評価を1つ示す。 ジャーナリストが出典を明記して文全体を引用できる形で、そのカテゴリについての評価を1文で述べます。DR 82 の媒体は、*「レビューによれば、ロボット式プールスキマーのカテゴリにおける進化である」*という一文を引用しました。自社の位置づけと出典の明記の両方を含む一文です。
  5. 効果が積み重なる場所で公開する。 具体的かつ定量的な記事を公開するサイトは引用を獲得し、地域向けのありきたりな埋め草を公開するサイトは何も獲得しません。掲載先はすべて同じ基準で評価してください。
  6. URLを決して切らない。 リダイレクトなしにパスを変更すると、獲得したリンクはすべて気づかれないまま無効になります。/posts/ から /articles/ への移行では、リダイレクトが追加されるまで、DR 49 の dofollow 引用が5件、404ページに取り残されました。スラッグを変更する場合は、同じ変更でリダイレクトも設定してください。
  7. 忍耐は仕組みの一部です。 5月の記事が、促されることなく10週間後の7月に取り上げられました。ページはインデックスされ、見つけられる状態を保つことで成果を上げます。そのため、URLの安定性とインデックスの健全性は、公開当日の宣伝よりも重要です。

公開の仕組み(CMSを問わず)

思い込みで判断せず、公開先独自のAPIドキュメントやリポジトリの規約を確認してください。ほぼ共通して起こり得る失敗が2つあるため、明示的に確認する価値があります。

  • 作成リクエストでステータスフィールドが無視され、下書きのままになることがあります。 201を信頼せず、読み戻して確認してください。下書きは公開サイトでは404として表示されます。また、ISRを使うサイトでは、公開後もその404がページの再検証期間中キャッシュされます。
  • 「メタデータがなくても許可する」という抜け道は、前述の基準を満たしません。 通常、デフォルトの著者と自動生成されたカバー画像が使われます。重要な掲載先では絶対に使わないでください。

コードベースの公開先では、リポジトリの手順を読み、既存のパターンに沿って必要最小限の編集を行い、そのリポジトリ独自のワークフローで公開してください。1ページのためだけにコンテンツシステムを追加しないでください。

検証 — ペイロードではなく、公開されたページ

  1. 公開URLが200を返すこと。
  2. レンダリングされたHTMLを取得して、次の点を確認します。タイトルがページのH1であり、本文内で重複していないこと。実際の著者名が表示されていること。カバー画像のファイル名が実際に含まれていること。カバー画像がなくても、200のまま目立った異常なく表示されることがあります。
  3. レンダリングされたタイトルをGate 1に照らして再確認します。 この確認は機械的になりがちです。つまり、表示されるか、H1が1つかを見ているだけで、何の検索順位にもつながらないタイトルをそのまま通してしまいます。対象とするクエリを明記してください。古いスラッグからリダイレクトされるCMSなら、タイトルの修正は簡単です。
  4. 被リンクモードでは、リンク先URLとアンカーが存在し、dofollowであることを確認してください。Markdownではなく、レンダリング後のrelを確認してください。 多くのCMSやサイトテンプレートは、外部リンクにデフォルトでrel="nofollow"を付与します。nofollowのまま公開すると、今回の納品物であるランキング価値がまったく生まれませんが、公開フローでは何の警告も表示されません。出典の引用リンクはnofollowのままにし、例外を適用するのは意図したリンク先だけにしてください。
  5. ISRでキャッシュされたページはすぐには更新されません。 編集直後にrelを確認すると、古いコンテンツが読み込まれ、変更に失敗したように見えます。再検証を実行するか、キャッシュ期間が過ぎるまで待ってから再確認してください。
  6. レイアウトに影響する変更では、ヘッドレスブラウザーでスクリーンショットを撮影します。デスクトップとモバイルの幅で、すべての表やグラフが読みやすく、ラベルが判読でき、横方向にはみ出していないことを確認してください。
  7. 次の情報を報告します。公開先URL、著者、カバー画像、アンカー+リンク先(被リンクモードの場合)、公開方法、リソースIDまたはコミット。

タイトル、著者、画像の基準をレンダリングされたページ上で満たした場合にのみ、完了としてください。

API要件

必須のものはありません。公開先や各ゲートの要件に応じて、次のものを任意で使用できます。

目的典型的な情報源
キーワードの検索ボリュームと難易度(Gate 1)Ahrefs、Semrush、またはDataForSEO — ahrefs-research、semrush-researchを参照
対象ページの実際の検索クエリデータGoogle Search Console — search-consoleを参照
カバー画像の生成任意の画像生成モデル — ai-image-genを参照
パブリックドメインの画像Wikimedia Commons API。APIキーは不要
公開独自のCMSまたはリポジトリの認証情報

コメント