SNS投稿の冒頭は、読者の注意を集めるだけでなく、その先に何が書かれているかを約束します。よいHookは、本文で根拠と条件を回収できる結論、具体的な困り場面、判断の違いなどから作ります。「必ず伸びる」「誰も知らない」のような強い言葉を付けても、SourceにないFactや効果を補ってはいけません。媒体ごとにHookの型を決め打ちせず、投稿のReader Jobから選びます。
Hookを評価する際に、表示やクリックだけを見ると、読者が期待した情報を本文から得られたか分かりません。最初の文で読者が想像した答えと実際の本文を照合し、タイトル・冒頭だけで条件や結論が誤解されないか確認します。Hookが約束する範囲が広すぎる場合は、本文を過剰に膨らませるのでなく、最初の約束を狭く正確にします。
目次
Hook Brief
表は横にスクロールできます
| 項目 | 書き出す内容 | 例 |
|---|---|---|
| Reader Job | 読後に知る、決める、実行すること | 比較案のどちらを次に確認するか決める |
| Core Answer | 本文で答える一つの結論 | 違いは条件によって分かれる |
| Evidence | Claimを支えるSourceや記録 | 公式仕様、元データ、実測条件 |
| Boundary | 結論が当てはまらない条件 | 利用プラン、対象者、調査範囲 |
| Hook type | 問い、差分、場面、判断など | 「選び方が変わる条件は何か」 |
| Next Action | 読者が次に行うこと | 条件を一つ入力して候補を絞る |
Hookの型を選ぶ前に、本文の要点を一文にします。答えがまだない時に刺激的な問いだけを作ると、開いた後に何も解決しない投稿になります。Factや条件が不確定なら、その不確定さ自体を適切に示し、断定形のキャッチコピーにしないでください。比較・料金・安全などは、本文内に必要な限定やSourceがなければ投稿自体を保留する判断もあります。
本文と約束を合わせる方法
-
Reader Jobを短くする。 投稿の読者が何を終えるのかを具体的な動詞にします。
-
答えの中心を一つ選ぶ。 本文に含まれる複数の主張から、最も重要な差分や手順を取り出します。
-
Evidenceと適用条件を確認する。 ClaimのSource、対象、時点、例外をBriefへ記録します。
-
Hookの役割を決める。 直接答える、よくある誤解を直す、具体場面を示す、判断条件を提示する等から選びます。
-
異なる角度を作る。 結論、問い、具体的な困り場面など、意味の違う案を少数作ります。類語だけの大量案にしません。
-
本文で回収できるか読む。 Hookに含まれる数字、比較、結果、期間が本文とSourceで支えられるか照合します。
-
媒体の仕様を確認する。 一つの投稿で足りるか、threadや添付が必要かを現行の公式Helpで確かめます。
-
投稿後の観測方法を決める。 目的に合う指標や読者質問を選び、クリックの差だけで内容の優劣を断定しないようにします。
具体的なHookタイプ
表は横にスクロールできます
| Hook type | 使う場面 | 読者へ約束すること | QA |
|---|---|---|---|
| Direct answer | 検索や質問へ答える | 問いへの短い答え | 本文が条件を回収 |
| Decision hinge | 選択が条件で分かれる | 判断を変える軸 | 条件の両側を説明 |
| Concrete scene | 起きている作業や失敗 | 読者が状況を想像できる | 誰にでも起きると一般化しない |
| Misconception | よくある理解を修正 | 何が違うか | 反対説を誇張しない |
| Question | 読者へ考える場を作る | 答える意味がある問い | 答えを本文で示すか対話理由を明確に |
架空の投稿文を作ってみる
以下はHookの作り方を説明する仮例です。実在の投稿や効果測定ではありません。
元Fact(架空):レポートの更新日は一覧で確認できる。更新頻度の自動変更や集計ミス防止効果は確認されていない。
本文のJob:レポートがいつ更新されたか確認し、分析対象期間を決める。
-
Direct answer:「分析前にレポートの更新日を確認し、対象期間をそろえます。」
-
Decision hinge:「過去月を比べる前に、レポートの更新日と集計期間を同じ条件で見ていますか。」
-
Concrete scene:「月次会議の直前に数値が変わったら、最初に見るのはレポートの更新日です。」
-
Bad hook:「この確認だけで、分析ミスをゼロにできます。」
最後の文は架空Factから導けず、効果を保証しています。質問案も読者の作業と接続していなければ、問いかけそのものが注意集めになります。投稿を選ぶ時は、好きな言い回しを選ぶのでなく、Reader Jobへ最短で進み、誤った期待を生まない文を選びます。
プラットフォームに合わせるときの注意
Xでは通常の投稿、長文機能、threadなど形式ごとに条件が異なり、利用条件も時点で変わることがあります。公式Helpは通常投稿の仕様と有料機能による長文投稿を分けて案内しています。ThreadsではMetaが長い文章を添付する投稿機能を紹介しています。どの形式を選ぶにしても、利用可能な機能、現在の文字数、アカウント条件を投稿時に確認し、古いガイドの数値を流用しないでください。
LinkedInの公式AI支援案内は、投稿者がAIで作った内容を見直し、編集し、自身の視点を残すよう勧めています。Hookが一般論や誇張だけになっていないか、本文に投稿者が確認できる専門知識や根拠があるか読みます。「私は試した」「多くの人が成功した」は本人の事実や調査記録がある場合だけです。
同じ投稿テーマについて反応を比較する場合、媒体、対象、投稿形式、CTA、公開時期が異なると、Hookだけの効果とは言えません。完全に条件をそろえられないなら、観測範囲を限定し、Hookの普遍的な勝者を決めないでください。投稿の目的が保存、相談、認知、導入前確認のどれかで指標も変わります。短い期間の数字はばらつくことがあるため、結果を解釈できるだけのデータがないなら次の試験条件を記録します。
AIへのHook作成Prompt
本文、Source、読者のJob、適用条件を渡して、次の投稿Hookを5案だけ作ってください。本文の中心回答は[Answer]、Reader Jobは[Job]、Evidenceは[Source]、対象外・未確認は[Boundary / Unknown]です。案はDirect answer、Decision hinge、Concrete scene等、違う役割から作り、語尾だけを変えた重複案にしないでください。各案のClaimが本文とSourceで回収できるか、追加したFactがないかを説明してください。数字・期間・結果の保証、存在しない体験談を作らず、未確認事項はHookで断定しないでください。
出力を受け取ったら、各Hookの約束を本文中の根拠箇所へ対応させます。対応先が見つからない案は、語感が良くても削除します。本文が回答を持たない質問案や、リンク先を開かなければ答えが分からない曖昧なHookは、投稿のReader Jobと目的から再検討します。
Hookの失敗と直し方
表は横にスクロールできます
| 失敗 | 何が起きるか | 修正 |
|---|---|---|
| 数字を強調するがSourceにない | 根拠のない専門性に見える | Sourceへ戻り数字を削るか確認 |
| 全員に当てはまると断定 | 対象条件が隠れる | 適用範囲を付ける |
| 問いを投げて答えない | 開いた後に用事が済まない | 本文で答えを返すか問いを外す |
| 恐怖やFOMOをあおる | 不安だけ残る | 観察可能な課題と具体策を示す |
| 結論を過剰に短縮 | 条件が消えて誤解を招く | 必要なBoundaryをHookへ戻す |
| AIの体験談で始める | 存在しない経験を装う | 書き手の確認済み事実を使う |
| クリック数だけで決める | 期待外れの読者を増やす | 本文との一致と目的指標を見る |
次に行うこと
一つの投稿本文を選び、Reader Job、Core Answer、Evidence、BoundaryをHook Briefへ書きます。異なる役割の案を少数作り、各案のClaimを本文へ戻して検証します。選定後、公開画面で本文やリンク先を確認し、公開後の評価方法と限界も一緒に記録してください。内容が回収できないHookは、強い言葉に直すのでなく、記事本文や投稿のAnswerを再設計します。
AIものさしの判断
AIものさしの判断は、Reader Job→Answer→Evidence→Hook→Expectation Readbackです。冒頭文は本文から独立した広告ではなく、読者が読む前に抱く期待の契約です。興味を引くことと誤った約束を避けることを両立させ、投稿本文がReader Jobを実際に終えられる範囲を示します。
Hookを実務で選ぶための判定手順
候補を選ぶときは、最初に「本文を読まない人がHookだけから何を期待するか」を第三者に説明してもらいます。期待される答えが本文にない、対象が広すぎる、効果の保証に見える場合は、その案を外します。次に、そのHookを見た読者が本文のどの箇所へ進むかを指し示します。対応する段落が見つからないなら、冒頭の文か本文の構成を見直します。
候補が二つ残った場合は、表現の派手さで決めず、Reader Jobへ必要な条件を最も早く伝えるものを選びます。料金や安全性のように限定が結論を変える話題なら、短くするために限定を落とすより、Hookを狭くします。読者の質問が複数ある場合、一本の投稿ですべてを約束せず、最初に解決する質問を一つに絞り、残りを次Actionとして案内します。
公開後の振り返りでは、Hookと本文の一致、読者から届いた質問、保存・クリック等の目的に対応する指標を分けて見ます。数字だけを理由に誤解を生む案を採用し続けないでください。投稿の表示が少ない場合はHookの優劣ではなく、配信条件や対象Audienceが異なる可能性を記録します。確かな比較ができないときは、結果を仮説として扱います。
引用・データ出典
公式情報を編集部が見た内容です。Hands-on未実施の記述は本文かここに分けています。
確認日:2026-10-09
X Help:How to create a thread on X(新しいタブで開く)
Meta:New Features to Celebrate 500 Million Monthly Users on Threads(新しいタブで開く)
LinkedIn Help:Best practices for content created with the help of AI(新しいタブで開く)
OpenAI Help:Prompt engineering best practices for ChatGPT(新しいタブで開く)
