リサーチ
このスキルは、発信に値する内容を見つけ、それが真実であることを証明します。2つの役割を担います。オーディエンスが実際に求めているトピックと角度を選ぶこと、そして作品に含まれるすべての事実に出典を付けることです。出力は、writing と video-scripting スキルが消費する リサーチブリーフ であり、ワークスペースの信頼できるソースリスト brand/sources.md を適切に維持します。完成した投稿を書いたり（writing）、動画のスクリプトを作成したり（video-scripting）、最終作品をチェックしたり（review-loop）は行いません。
権限の優先順位: brand/brand-profile.md はブランド定数、境界、コンプライアンス表現に関して優先されます。このスキルはリサーチ手法を所有します。
開始前に
マーケティングワークスペース（デフォルトは marketing/）から以下を読んでください。
brand/brand-profile.md:## Audience、## Content pillars、## Boundaries、## Compliance、## Platforms。オーディエンスとピラーは何を探すべきかを示し、境界とコンプライアンスは絶対に持ち帰ってはいけないものを示します。brand/sources.md: このビジネスが信頼するソースの階層化されたリスト。存在しない場合は、references/source-tiering.mdのテンプレートから作成し、進めながら記入します。brand/performance-learnings.md（存在する場合）: どのトピックとフォーマットが効果的だったか。リサーチは実証済みの鉱脈に傾け、未検証のものはテストとしてフラグ付けする必要があります。- 最近の
content/フォルダ: 何がすでに作成されているかを確認し、重複ではなくギャップを見つけます。
ワークスペースがない場合は、1行でその旨を伝え、brand-setup を実行するよう提案します。それでも続行したい場合は、オーディエンス、業界、ロケーション（ローカルの場合）のみを尋ね、進めてください。
基本原則: 捏造禁止、すべてに日付
このスキル全体が保護するためのルールです。少しドラマチックでも真実の作品は、センセーショナルでも捏造された作品よりも常に優れています。なぜなら、信頼こそが資産であり、たった一つの捏造された詳細がそれをすべて無駄にする可能性があるからです。
- 数字、引用、レビュー、証言、ストーリー、名前付きの詳細を決して捏造しないこと。 でっち上げの統計、価格、平均、「10人中9人」といった主張は禁止です。実際のものとして提示される架空の顧客の逸話も禁止です。事実として述べられる、架空の製品、人物、場所、出来事も禁止です。
- ストーリーは実際の素材からのみ作成すること。 本人が文書化した経験（本人に確認すること。「かつて私の顧客が...」というのは本人だけが唯一の情報源です）または、名前付きソースからの公開されたケーススタディを使用します。実際のケースを匿名化した形に要約し、実際に起こったことに留めてください。ドラマチックにするために具体的な詳細を追加しないでください。理由: 捏造された「実際の顧客ストーリー」は、あなたを信頼するオーディエンスを失う最短の道であり、規制産業では法令違反にもなり得ます。
- すべての主張に出典と日付を付けること。 出典は具体的に名前を挙げ（出版社、タイトルまたはリリース、可能であればURL）、日付は公開日と確認日の両方を記載します。出典のない主張はブリーフに含めず、未解決の質問として記載します。
- 変動する数字には
VERIFY BEFORE PUBLISHフラグを付けること。 変動しうる数字（価格、レート、平均、カウント、ランキング、ポリシーの閾値、プラットフォームの制限など）は、公開時に再確認するようフラグを付けます。 - データを示唆する曖昧な数量詞は使用しないこと。 「ほとんどの人々」「統計的に」「研究によると」「ほぼ全員」といった表現は、引用されたソースで裏付けるか、書き換えます。
- 不明な場合は推測しないこと。 その部分は省略して一般的に説明するか、一旦停止して本人に尋ねます。検証できなかったことを明確に伝えます。
エバーグリーンかライブか: まず決定する
すべての作品は3つの種類のいずれかであり、ブリーフにはそれが明記されます。なぜなら、それによってブリーフに何を含めることができるかが変わるからです。
- エバーグリーン: 数ヶ月間有効。バッチ処理、事前録画、数週間先のスケジュールに安全。ライブの数字は一切含まないこと。原則、プロセス、説明用と明確にラベル付けされた実例を使用します。
- ライブ: 現在の何か（数字、リリース、ルール変更、今日のニュース）を中心に構築。すべての現在の数字には
VERIFY BEFORE PUBLISHフラグが付き、ブリーフには有効期限が記録され、それを過ぎると未修正のまま公開してはなりません。 - 日付指定: 形状はエバーグリーンだが、既知の日付（締切、シーズン、制度開始）に結びついている。「使用期限」を記録し、配置されずに期限切れになったり、古いまま公開されたりしないようにします。
理由: 先月の数字を引用した事前録画動画は、放送された日に間違っています。視聴者が気付くまで誰も気づきません。
方法
-
依頼を明確にする。 相手は調査するトピックを渡しているのか、それとも何を作るべきか尋ねているのか？トピックの場合はステップ3へ。「何を投稿すべきか」の場合はステップ2から始めます。プラットフォームと作品が公開される日付を記録します。これがエバーグリーンかライブかを決定します。
-
需要を見つける。 何を言うかを決める前に、オーディエンスが実際に何を尋ねているかを、彼らの言葉で把握します。
references/audience-demand.mdを開き、検索候補と「他の人はこちらも検索」、本人のSearch Consoleクエリ、プラットフォームの検索インサイト、フォーラムやコミュニティスレッド、そして本人のコメントやDMに眠っている質問などの方法を確認します。ピラーは投稿の種類を設定し、需要は角度と正確な言葉を設定します。以下のようなトピックを優先します。- ほとんどの人が気づくまで知らない具体的な問題（警告や「実はこう」という形状）
- 人々が心配する瞬間の「実際に何が起こるか」のウォークスルー
- 視聴者が直面している明確な二者択一の決断
- 検索バーにすでに入力されている質問で、タイトルにほぼそのまま使用できるもの
各候補を
brand/performance-learnings.mdおよび既に作成された作品と照らし合わせます。未検証の鉱脈は、確実ではなくテストとしてマークします。
-
階層化されたソースから収集する。
brand/sources.mdとreferences/source-tiering.mdの階層化方法を使用します。数字を伴うものについては一次ソース（統計機関、規制当局、元の研究）にアクセスし、業界紙、ブログ、コメンテーターはそれを指し示すレーダーとして扱います。各ソースの背後に誰がいるか、彼らが何を望んでいるかをメモします。党派的なソースや商業的なソースにも良いデータはありますが、偏向が伴います。 -
検証する。 すべての主張について:
- 見出しの数字を一次ソースまで遡って確認し、そこで読む
- 公開日を確認し、後続の情報に取って代わられていないか確認する（公式ガイドページは最新に見えても、何年も前の情報である可能性がある）
- サンプルを確認する: 誰が調査されたか、何人か、パネルに偏りがないか（ある企業の自社顧客のみの調査は「すべての顧客」を意味しない）
- その数字が見出しの意味する通りの意味か確認する。文脈を剥奪されると誤解を招く数字もあり、それらは除外する
- ページが正しく読み込めない場合（クライアントサイドレンダリングのサイトは空で返ることが多い）、サイトのRSSフィード、サイトマップ、または直接のドキュメントリンクを試してから諦める。記憶で埋め合わせない 検証できない場合は、事実として含めない。
-
角度を見つける。 事実を、視聴者にとって何を意味するかに変換します。ニュースやデータの場合、 stakes（利害）と新鮮さにフックし、数字は一度だけ示し、すぐに「これがあなたにとって何を意味するか」に移り、オーディエンスの2〜3のタイプに分けます。緊張感は事実自体に保ち、約束された結果には決して依存しない（「この条項はあなたにコストがかかる可能性がある」は真実なら問題ないが、「あなたは節約できる」はダメ）。2〜3のフックシードを提供します。
writingとvideo-scriptingスキルが選択し、磨き上げます。 -
ブリーフを書く。
references/research-brief-template.mdを使用し、content/<yyyy-mm-dd>-<slug>/research-brief.mdに保存します。クレームテーブルが核心です: クレームごとに1行、出典、日付、フラグを含めます。相手が簡単な事実確認だけを望んだ場合は、チャットで出典と日付とともに答えを返し、ブリーフを提出することを提案します。 -
brand/sources.mdを更新する。 依存した新しいソースがあれば、その階層、得意分野、偏向や注意点、フェッチノートを追加します。古くなったり信頼できなくなったソースは格下げし、その理由を一行で述べます。
ニュースと予定されたリリースへのリアクション
業界で何かが起こった場合、または既知のデータリリースが予定されている場合、references/reactive-content.md を開きます。簡単に言うと、このオーディエンスに関連する予定されたリリースやアナウンスのカレンダーを維持し、それらの日に計画に意図的にギャップを残し、事前に角度を準備し、実際の数字を当日に検証して迅速に成果物にします。単純な数値リリースはスピードが報われますが、複雑なポリシー変更は最初に一次文書を読むことが報われます。「最初だが間違っている」は「数時間後だが正しい」よりも悪いからです。
規制産業
## Compliance がビジネスが規制されていることを示す場合、ソーシングの基準はより高くなり、いくつかのクレームはどんなに適切にソースがあっても許可されません。ブランドプロファイルのコンプライアンスラインに従ってください。references/regulated-industries-example.md は、ある産業（英国の金融サービス）での動作例を示しており、デフォルトではありません。
出荷前のチェック
ブリーフを引き渡す前に、以下を確認します:
- クレームテーブルのすべての行に、名前付きソース、公開日、確認日がある
- すべてのライブ数字に
VERIFY BEFORE PUBLISHフラグが付いており、ブリーフがエバーグリーン、ライブ、または日付指定（有効期限付き）を明記している - 本人が提供していない、または名前付きソースが公開していないストーリー、引用、レビューが含まれていない
## Boundariesのトピックに触れていない- 最後のソースリストが、他の誰かがすべてのクレームを確認できるほど完全である
完成した作品は review-loop スキルを通過し、このブリーフに対してクレームを再確認します。ブリーフはコンテンツとともに保管し、確認できるようにします。
適応方法
- あなたのソース: 階層は方法論であり、
brand/sources.mdにあなたの業界の名前が入ります。カフェのティア1は地元の自治体と食品基準機関かもしれません。コーチの場合は、査読付き研究と専門団体かもしれません。 - あなたのリリースカレンダー: オーディエンスを動かす日付（業界レポート、公式統計、季節的なピーク、展示会、ポリシーの締切）を
brand/sources.mdのカレンダーヘッダーの下にリストします。 - あなたの需要ツール: 無料のもの（検索候補、あなた自身のコメント、Search Console）から始めます。有料のキーワードツールはオプションです。1つの実例が
references/audience-demand.mdにあります。 - リアクティブな作業への意欲: 当日の撮影が現実的でない場合は、リアクティブなレーンをクイック投稿に限定し、週次のまとめで残りをカバーします。
詳細情報
例を含む詳細ガイドは https://builtnotboosted.com/skills/research にあります。