ローンチブログ記事
このスキルは、製品ローンチを告知するブログ記事の作成を支援します。優れたローンチ記事は、読者に何がリリースされたかとその重要性を伝え、検索エンジンで上位表示され、AIアンサーエンジンに引用されるという3つの役割を果たします。
記事タイプ
記事タイプは、ローンチの規模と対象読者に合わせて選択します。
発表記事
最適な用途: ティア1およびティア2のローンチ。主な読者: 既存ユーザーと見込み客。
構成: 何がローンチされたか → なぜ重要か → どのように機能するか → 使い始める方法。1,500ワード以内に収めます。読者は何が変わったかを理解し、記事を読んでから5分以内に試せるようにします。
テクニカルディープダイブ
最適な用途: 開発者向け/テクニカル製品のティア1ローンチ。主な読者: 導入を検討しているエンジニア。
構成: 問題 → アプローチ → アーキテクチャ/実装 → ベンチマーク → 使い始める方法。2,000〜3,000ワードと長めに設定できます。コードサンプル、アーキテクチャ図、パフォーマンスデータを含めてください。これはHacker Newsで共有されるタイプの記事です。
チュートリアル / 「XをYで作る」
最適な用途: 任意のティアのローンチから最初の1週間以内に公開。主な読者: あなたのことを知ったばかりで、実際に試してみたい開発者。
構成: 何を作るか → 前提条件 → ステップバイステップの実装 → 結果。15〜30分で完了できるようにします。スニペットではなく、完全な動作するコードを含めてください。
変更履歴エントリ
最適な用途: ティア3のローンチや、小さな改善をまとめて公開する場合。主な読者: 既存ユーザー。
構成: 改善項目ごとに短い段落で記述。変更内容を先に書き、理由は後述します。詳細はドキュメントへのリンクを参照。毎週または隔週でまとめて公開します。
記事の作成
メッセージングブリーフから始める
ローンチ戦略のメッセージングブリーフが存在する場合は、それを活用します。主要な価値提案が記事のテーマとなり、二次的な価値提案はセクションとして展開し、証明ポイントは記事全体に織り交ぜるエビデンスとして使用します。
ブリーフがない場合は、作成前に以下を定義します：誰に向けた記事か？読者は何ができるようになるのか？なぜ気にする必要があるのか？
価値で始め、プロセスで始めない
最初の段落では、「何がリリースされ、なぜ自分にとって重要なのか」に答える必要があります。どれだけ長く開発に取り組んだか、何人エンジニアが関わったか、そこに至るまでの経緯などで始めてはいけません。読者はあなたのプロセスには興味がなく、自分たちの問題に関心があるのです。
良い書き出しの例: 「これで、14言語のオーディオファイルを単一のAPI呼び出しで処理できるようになりました。10分までのファイルでレイテンシは200ms未満です。」
悪い書き出しの例: 「6ヶ月の開発期間を経て、私たちのチームはオーディオ処理プラットフォームの次の進化を発表できることを嬉しく思います。」
示すこと。語るだけではない。
すべての主張に対して、エビデンスを提供します：
- パフォーマンスの主張 → 方法論を含むベンチマークデータ
- 「使いやすい」 → 5〜10行の動作するコードサンプル
- 「お客様に好評」 → コンテキストを含む具体的な引用
- 「代替製品より優れている」 → 正直な比較表
動作する例を含める
テクニカル製品のローンチ記事には、読者が実行できるコードを含める必要があります。擬似コードや概念的なスニペットではなく、インストールコマンド、インポート、期待される出力を含む実際の動作するコードです。これはテクニカルブログ記事において最もコンバージョンに貢献する要素です。
明確な次のステップで締めくくる
記事の最後には、CTA（行動喚起）を1つだけ設定します。「今すぐ試す」「ドキュメントを読む」「ベータ版に参加する」— 3つの選択肢ではなく、1つに絞ります。
SEO最適化
キーワードターゲティング
記事を作成する前に、プライマリーキーワードを選びます。これは、あなたの製品が解決する問題を抱えたターゲットオーディエンスが検索するキーワードと一致する必要があります。記事タイトル、H1、最初の段落には、このキーワードを自然に含めます。
ローンチ記事の場合、キーワードは多くの場合、機能/製品名とカテゴリの組み合わせです：「[製品名] [カテゴリ]」（例：「リアルタイム文字起こしAPI」や「オープンソースフィーチャーフラグ」）。
オンページ基本要素
- タイトルタグ: プライマリーキーワードを含め、60文字以内。ブログ記事のタイトルとHTMLのタイトルタグはほぼ一致させる。
- メタディスクリプション: 150〜160文字で、読者が何を学べるか、何ができるようになるかを要約。
- URLスラッグ: 短く、キーワードを含み、日付は入れない（常に新鮮な状態を保つため）。
- 見出し（H2/H3）: 記事を論理的に構成するために使用。各H2は、誰かが検索しそうな質問やトピックにする。
- 内部リンク: ドキュメント、関連ブログ記事、ランディングページへのリンクを設置。ドキュメントからこの記事へのリンクも設置する。
- 画像のaltテキスト: 画像の内容を説明し、可能なら関連キーワードを含める。
ロングテールキーワードランキングのためのコンテンツ
メインの発表の下にあるセクション（仕組み、技術詳細、FAQ、比較など）は、ロングテールキーワードのターゲットとして機能します。これらを、読者が実際に尋ねる具体的な質問に答える形で作成します。「[機能]は[エッジケース]をどのように処理しますか？」というタイトルのセクションは、そのままのクエリでランクインする可能性があります。
AEO：アンサーエンジン最適化
AI検索エンジン（ChatGPT、Perplexity、Claude、Gemini、そして従来の検索におけるAIによる要約）は、人々が製品を発見し評価する主要な手段になりつつあります。AEOとは、AIエンジンが回答を生成する際にあなたのコンテンツを引用するように構造化する手法です。
AEOとSEOは補完的であり、競合するものではありません。AEOのベストプラクティスのほとんどはSEOにも役立ちます。しかし、コンテンツをAIに引用されやすくするための特定のテクニックが存在します。
ローンチ記事におけるAEOの重要性
誰かがAIアシスタントに「[あなたの製品が行うこと]に最適なツールは？」や「[あなたの製品が可能にするタスク]の方法は？」と尋ねたとき、あなたのローンチ記事がAIが参照するソースの一つになることを目指します。たった一つのAIによる引用が、ローンチ当日のトラフィックが落ち着いた後も、持続的な発見をもたらす可能性があります。
コンテンツをAIに引用されやすくする
自己完結型で抽出可能な文章を書く。 AIエンジンは記事全体ではなく、パッセージ（文章の一部）を引用します。記事の各セクションは、前のセクションを読んでいなくても理解できるようにする必要があります。明確な主張を述べ、それをエビデンスで裏付け、製品名を明記した段落 — これが引用可能な単位です。
セクションの先頭で直接的な回答を示す。 セクションが質問に答える場合（暗黙的であっても）、最初の文で回答を述べ、その後で詳しく説明します。AIエンジンは、迅速かつ具体的に回答するコンテンツを好みます。
例 — 以下の代わりに：
「文字起こしAPIを選ぶ際には、多くの要素を考慮する必要があります。レイテンシ、精度、言語サポート、価格設定などが重要な役割を果たします。広範なテストの結果、私たちは...」
以下のように書きます：
「[製品名]は、14言語のオーディオを200ms未満のレイテンシ、1分あたり0.006ドルで文字起こしします。ベンチマークの内訳は次の通りです...」
2つ目のバージョンは直接引用可能です。「最速の文字起こしAPIは？」という質問に答えるAIエンジンは、その文をそのまま引用できます。
具体的で定量的な主張を使用する。 AIエンジンは、具体的なデータ（数値、ベンチマーク、比較、パーセンテージ）を含むコンテンツを優先的に引用します。「高速なAPI」は引用可能ではありません。「10分のオーディオファイルに対するP99レイテンシが180ms」は引用可能です。
構造化データを含める。 比較表、機能マトリックス、ベンチマーク表は、構造化され抽出可能な情報を提供するため、非常に引用されやすいです。あなたの製品を代替製品と（正直に）比較する表は、最もAIに引用されるコンテンツ形式の一つです。
本物の質問を含むFAQセクションを書く。 各質問が実際の人がAIアシスタントに尋ねそうな内容と一致するFAQセクションは、引用を集める磁石となります。質問を自然なH3として書き、最初の文で直接回答します。
AIエンジンのためのスキーママークアップ
スキーママークアップは、AIエンジンにコンテンツに関する機械可読なコンテキストを提供します。ローンチブログ記事に以下を追加します：
- Article / BlogPosting スキーマ: これは日付のある記事であり、特定の著者とトピックがあることをAIエンジンに伝えます。
headline、datePublished、dateModified、author、descriptionを含めます。 - FAQPage スキーマ: 記事にFAQセクションがある場合、AIエンジンが質問と回答のペアを直接抽出できるようにマークアップします。
- HowTo スキーマ: 記事にチュートリアルやステップバイステップガイドが含まれている場合、ステップをマークアップします。
- Product スキーマ: 記事が価格設定のある製品を発表する場合、
name、description、offersを含む製品スキーマを含めます。
これらすべてが必要なわけではありません — 実際に書いたコンテンツに一致するものだけを使用してください。
コンテンツの鮮度シグナル
AIエンジンはRecency（新しさ）を重視します。更新されていないページは、時間の経過とともにAIからの引用を失います。ローンチ記事の場合：
- ページに「最終更新日：[日付]」を表示する
- 変更を加えるたびに、Articleスキーマの
dateModifiedを更新する - 四半期ごとにローンチ記事を見直す：ベンチマークを更新し、新機能を追加し、コードサンプルをリフレッシュする
- ローンチ記事が古くなった場合は、更新するか、新しい記事にリダイレクトする — 古いコンテンツがランキングされ続けるのを避ける
エンティティとブランドシグナル
AIエンジンはブランドや製品の内部モデルを構築します。一貫性を保つことでこれを支援します：
- 製品/機能名を正確に一貫して使用する（ニックネームを交互に使わない）
- 製品が属するカテゴリを明示的に述べる（「オープンソースのフィーチャーフラグプラットフォーム」など）
- 自社に関する信頼できるソース（ホームページ、ドキュメント、GitHub、該当する場合はWikipedia）へのリンクを設置する
- ブログ、ドキュメント、ランディングページ、ソーシャルプロファイル全体で製品の説明が一貫していることを確認する
公開後のチェックリスト
公開後：
- あらゆる場所からリンクする: ドキュメント、ランディングページ、変更履歴、関連ブログ記事、README
- ソーシャルで共有する: ソーシャルコピーの作成にはlaunch-tweetスキルを使用
- アグリゲーターに投稿する: Hacker News、関連するサブレディット、dev.to、Hashnode（テクニカル記事の場合）
- メール: ローンチメールまたは次のニュースレターに含める
- 質問を監視する: 記事のコメント、Hacker Newsのスレッド、Reddit — これらは記事のギャップを明らかにすることが多く、更新で対処すべき内容を教えてくれる
- ローンチ週後に更新する: カスタマーストーリーを追加し、ベンチマークを更新し、読者が指摘した問題を修正する
関連スキル
- launch-strategy — メッセージングブリーフとローンチ計画
- launch-tweet — 記事を宣伝するソーシャルコピー
- launch-email — この記事へのリンクを含むメール
- launch-video — 記事に埋め込むデモ動画やGIF
- launch-distribution — ブログ以外での配信場所と方法
- launch-landing-page — ブログ記事がリンクするページ
- launch-metrics — ブログ記事リンク用のUTM設定、経時的な記事パフォーマンスの追跡