AIでSNS投稿を読者タイプ別に書き分ける方法

SNS投稿を読者タイプ別に書き分けるときは、年齢や職種のラベルを文章へ置き換えるだけでなく、各読者が何を知り、どの作業に困り、何を決めたいかを明らかにします。同じ確認済みFactを保ち、説明の深さ、用語、具体例、次Actionを変えます。読者の知識や事情を推測で決めつけず、本文を出す前にFactがずれていないか横に並べて確認してください。

「初心者向け」「管理職向け」と指定しても、必要な情報が自動的に決まるわけではありません。初心者でもすでに問題の用語を知っている場合があり、管理職でも操作手順を知りたいことがあります。属性は仮説の整理に使い、読者の実際の質問、業務条件、インタビュー、問い合わせなどで確かめます。

Audience Adaptation Brief

表は横にスクロールできます

観点	初稿に書くこと	分からない場合
読者の前提知識	知っている用語・経験	年齢や肩書から推測しない
Reader Job	知りたい、実行したい、判断したいこと	具体的な質問を集める
困っている箇所	作業のどこで止まるか	例を仮説として明記
必要な深さ	概要、手順、比較、リスク	言い切らず複数案を検討
CTA / 次Action	読後に取る一歩	目的と無関係なら置かない

書き分けの中心は、同じ人を三つの属性に分けることではありません。同一のTopicについて、異なるReader Jobを持つ読者がいるかを調べ、記事の短い版をそれぞれ作ることでもありません。もし読者全員に同じ答えが必要なら、表現だけを無理に変えず、一つの投稿にする選択もあります。反対に、同じ事実から出発しても、判断に必要な手順や証拠が異なるなら、情報を補って別案を作ります。

3つのReader Jobを並べる仮例

以下は書き分け方を示す架空例です。実際の調査、製品仕様、読者の発言ではありません。

前提Fact（架空）：社内ツールには、予約済み投稿と担当者を一覧で表示する機能がある。作業時間の短縮や成果への影響は未確認。

表は横にスクロールできます

仮の読者	Reader Job	必要な答え	次Action
SNS運用を始めた担当者	投稿をどう準備し、誰が確認するか知る	用語、最初の手順、確認者	1件の投稿で小さく試す
複数案件を持つ実務担当	担当と公開日を見落とさず管理する	一覧の使い方、例外、運用手順	既存予定表と照合する
運用を承認する責任者	誰が何を公開するか確認する	権限、確認の流れ、未解決リスク	管理条件を担当者と確認

仮例の投稿案

• 初めて担当する人向け：「公開予定と担当者を一覧で確認できる機能があります。まずテスト投稿一件で、登録から公開前確認までの担当を決めてみましょう。」

• 実務担当向け：「複数案件の予約投稿を扱うなら、一覧の担当者と公開予定日を既存の運用表と照合します。担当変更や未確定の投稿をどう記録するかも決めておきます。」

• 承認者向け：「予約済み投稿の担当と公開予定を確認できるか、管理者権限と公開前の承認フローを確認してください。機能の有無だけで社内統制を満たすとは判断しません。」

この例は、読者への説明を増やしたり、CTAの役割を変えたりしていますが、製品について言えるFactは同じです。実際の製品へ適用する前に、該当する機能が対象プランにあるか、表示範囲、権限、手順を公式資料や管理者の設定で確かめます。架空例を実在製品の広告文や導入事例に流用しないでください。

書き分け前にCore Fact Sheetを作る

Audienceごとに文章を作り始めると、数字、利用条件、提供範囲が別々に変わりやすくなります。まず全案共通のFact欄を作ります。各FactにSourceと確認日をつけ、未確認は空欄やUnknownのまま残します。主張と意見は分け、誰が確認したかも残します。価格、制限、連携など変わる情報が含まれる場合は、投稿時点でSourceを再確認します。

Core Fact Sheetには、少なくとも次の情報を含めます。

表は横にスクロールできます

Fact	Source / checkedAt	Allowed wording	Boundary
機能として確認できたこと	公式ヘルプ等	その事実を過不足なく説明	対象プラン・利用条件
実測した結果	手順・入力・環境・日時	測定範囲のみ	一般利用者へ拡張しない
投稿者のOpinion	発信者本人が確認	Opinionとして表示	Factのように断定しない
未確認	調査先・未確認の理由	断定しない	次に確認する担当

同じ情報を言い換えただけでも、数字の丸め、条件の省略、主語の入替えが起きることがあります。案を並べた後に、固有名詞、単位、否定、比較語、結果表現を一つずつ照合してください。公式ページが読む人に見せる説明と、実際に自分の環境で使える範囲が違う場合は、Fact Sheetに条件を併記します。

書き分けの工程

1. 対象読者の根拠を確認する。 Personaが仮説か、既存の問い合わせ・調査に基づくかを記します。根拠がない属性は仮説として扱い、事実として一般化しません。

2. Reader Jobを動詞で書く。 「SNSに興味がある」ではなく「公開前に担当・予定・内容を確認する」のように、完了状態を描きます。

3. 判断に必要な情報を選ぶ。 用語説明、手順、比較条件、リスクなどから、読者が用事を済ませるために必要なものを選びます。

4. Core FactとBoundaryを固定する。 変えない事実、未確認の主張、例外、適用条件を一枚の表にします。

5. 各版の情報深度を決める。 初めて使う人へは前提語や初手、実務者へは手戻りや例外、責任者へは権限・承認・リスクを含めるなど、Jobの違いから決めます。

6. 投稿案を別々に作る。 同一のFact Sheetと禁止条件を渡しても、各案の根拠は必ず後で検証します。先に一案だけを整えて複製すると、読者のJobの違いが残りにくくなります。

7. CTAはJobから導く。 用語を知りたい人には説明、作業を進めたい人には手順、承認者には確認資料というように、各案の次Actionを記事や製品の実際の内容に合わせます。

8. 案どうしを横断比較する。 Fact、数値、提供条件、責任表現に差がないか見ます。変更したのが語尾だけなら、Jobが本当に異なるのか再確認します。

9. 代表読者でReadbackする。 それぞれの版を読む人に、何ができるようになるか一文で説明できるか確認します。文章上の分かりやすさと製品Factの正しさは別に評価します。

10. 必要な版だけ公開する。 読者の違いを説明できない版や、CTAが変わらない版を無理に増やしません。

Knowledgeと属性を混同しない

「初心者」を一括りにすると、専門用語を知らない人、アカウント設定が初めての人、業務の判断経験が少ない人を一つにまとめてしまいます。どの知識が足りないのかを具体的にし、必要な言葉だけを説明します。反対に、専門職というラベルから基礎説明不要と決めつけるのも危険です。新しい製品や社内手順については、熟練者も初めてかもしれません。

年齢、性別、役職、地域から痛みや価値観を自動的に導かないでください。対象条件が調査で分かっていないなら、見出しや投稿本文に「このタイプの人は必ず」と書かず、読者が自分の状況を選べる条件を提示します。コメントやクリックの少なさを、その読者が興味を持たない証拠と決めつけず、配信量、形式、時期など別条件も確認します。

書き分け前後のCheck

次の三列を表にして、同一FactのままJobに応じた情報が追加されたかを確認します。

表は横にスクロールできます

Check	Yesの条件	Noの場合
Factの一貫性	数値、単位、対象、例外が全案で一致	Sourceから再照合
Reader Jobの違い	各案で必要な答えが具体的に違う	一つの投稿へまとめる
説明の深さ	前提や判断材料がJobに合う	読者の質問へ戻る
CTA	読後の作業に直接つながる	不要な誘導を削る
断定の範囲	Evidenceの範囲内	Claimを狭める
読者の尊重	属性や能力を決めつけない	観察可能な条件で書き直す

一つでも重要なFactが食い違ったら、そのまま投稿しません。書き分けで事実を変えないことは、語調を統一すること以上に重要です。投稿者自身の経験を入れる欄は、本人の実際の経験がある場合だけ記入します。AIが一般例を作った場合は、仮例と明記するか、実際の事例へ置き換えるまで公開しません。

AIへ渡すPrompt

以下の一つの確認済みFactから、読者のReader Job別に投稿案を作ってください。共通のFact Sheetは［内容］、出典と確認日は［Source］、未確認は［Unknown］です。読者案は［具体的な前提知識・作業・決定］で、年齢や職種から価値観を推測しないでください。各案について、読者が得る情報、必要な説明、次Actionを示してください。Fact、数値、制限、例外は全案で統一し、未確認を補わないでください。作業時間短縮や成果を保証しないでください。私の実体験として書ける部分は提供情報の範囲だけにし、例は架空と明記してください。最後に全案のFact差分と本文だけでは答えられない質問を列挙してください。

出力を受け取ったら、各案をコピーして並べるだけでなく、必ずCore Fact Sheetと照合します。AIが一案へだけ条件を足したり、説明を削って誤解を招いたりしていないかを探します。文章の自然さが違っていてもFactが変わっていないなら、読者に合わせた説明の差として検討できます。逆に、Factが変わったなら、いちばん読みやすい案でも採用を保留します。

SNSのAI支援コンテンツの扱い

LinkedInの公式案内は、AIが文章の推敲や校正を助けても、投稿者が見直し・編集・承認し、自分の視点や経験を反映することを勧めています。AIを使った投稿が一律に問題だという説明ではなく、低価値で反復的な内容、権利やプライバシーを損なう内容を避けるための案内として読みます。AIの使用を知らせる場面についても、現行の公式方針を確認し、文脈上分かりにくいほど広範に利用したときは透明性を検討します。

この案内を「属性別投稿は有効」といった成果Factへ広げたり、SNS全体に同じルールがあると一般化したりはしません。読者のJobに合う説明を作ることと、投稿の反応やconversionが上がることは別です。成果を評価するなら、投稿の目的、対象、期間、指標を決め、観測した結果だけを報告します。

Failure patterns

表は横にスクロールできます

失敗	なぜ価値が落ちるか	次の確認
年齢だけで文体を変える	読者の仕事や必要情報が不明	具体的な質問とJobを集める
初心者には内容を薄くする	基礎説明だけで作業が終わらない	Reader Jobまで手順を置く
責任者版だけ成果を保証する	Factでない効果を約束する	共有可能なEvidenceまでにする
各版で提供条件が変わる	同じFactから作った比較にならない	Fact Sheetを再照合する
CTAだけ同じで中身も同じ	属性ラベル以外の差がない	一つの投稿としてまとめる
AIの架空経験を使う	投稿者の信頼を損ねる	本人の事実へ置換するか削除

次に取る行動

一つのTopicについて、実際の読者質問を三つ集め、質問者の属性ではなく、前提知識・作業・判断に分けます。共通Factと未確認条件をSource付きで一枚にし、それぞれのReader Jobに必要な説明を決めます。案を生成したらFactを横断比較し、不要な版は統合します。公開後の効果を確かめたい場合は、配信条件と評価指標を事前に決め、投稿案の品質と結果の測定を別に記録してください。

AIものさしの判断は、Reader Job→Required Depth→Shared Fact→Next Actionです。読者向けの書き分けは属性にラベルを貼る作業ではなく、同じ事実を保ったまま、各人が必要とする判断材料を届ける作業です。読者像を説明できない場合は、無理に文章を増やすより、質問の収集やAudienceの仮説検証を先に行います。