AIで同じ内容をX・Threads・LinkedIn向けに書き分ける方法

複数のSNSへ同じ内容を届けるときは、まず変えてはいけないCore Factと主結論を一枚にまとめ、そのうえで読者、前提知識、投稿の目的に合わせてContextと表現を組み直します。投稿を同時に作るため、語尾だけを変えるのではなく、Xでは要点を短く伝えるか必要な説明をつなぎ、Threadsでは会話の入口や補足を選び、LinkedInでは仕事上の意味や根拠を示す、といった違いを検討します。媒体の仕様や提供機能は変わるため、文字数や機能だけで固定ルールを作らず、公開時に公式情報で確かめます。

媒体へ書き分ける目的は、同じ文章をどこにでも貼ることではありません。同じ事実から出発しても、そこで読む人が持っている前提や、投稿から次にしたいことは異なります。反対に、対象読者もReader Jobも同じで、必要なContextにも差がなければ、無理に三つの投稿を作らず、一つの文章を選ぶ方が自然です。

Cross-Platform Brief

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

固定する情報	各媒体で決める情報	横断QA
Core Fact / 主結論	投稿のReader Job	数字・条件・主体が一致する
Evidenceと確認日	Audienceと前提知識	Sourceが外れていない
Unknownと対象外	Openingと説明深度	Claimの強さが変わらない
禁止表現・権利条件	FormatとCTA	未確認の経験を追加しない

最初にBriefのCore Factを一文で書き、出典・確認日・適用条件を添えます。事実と意見、過去の経験と期待、確認済みと未確認を混ぜないでください。元となる発表や記事が古くなる可能性がある場合、媒体向けの文章に変える前に一次情報へ戻ります。プラットフォームにリンクを投稿する方法や長文形式を使う条件も変わることがあるので、必要な機能を現在の公式ヘルプで確認します。

一つのSourceから三つの案を作る架空例

次は変換手順を説明する仮例です。実在の製品やユーザー調査の結果ではありません。

固定Fact（架空）：チームの予定表に、投稿予定日と担当者を並べて表示できる。

Reader Job：公開前に誰が何を確認するかを把握する。

Boundary：確認漏れ防止の効果や作業時間の短縮は未測定。

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

媒体の案	投稿の焦点	仮文
X	先に判断軸を短く出す	「投稿予定日と担当者を同じ表で確認できるか。公開前の確認役も決めておくと、担当が見えない状態を減らせます。まずは予定表の表示項目を確認。」
Threads	読者が自分の運用を話せる入口	「投稿の予定日は決めたのに、公開前の確認者が見えなくなることはありませんか。予定日と担当者を並べて管理できるか、一件の投稿で確認してみる方法があります。」
LinkedIn	業務設計の意味と条件を説明	「SNS運用で確認が滞るとき、投稿案の質だけでなく担当者と公開予定の記録方法も見直します。予定日・担当を同じ表で確認できる機能があるなら、公開前の役割分担と合わせて小さく検証します。」

この仮文は文字数、反応率、製品の効果を示していません。投稿先の媒体を変えていますがFactは同じで、「確認漏れがなくなる」と断定していません。実際の製品や社内投稿で使う場合は、予定表に担当者が表示されることが現在も対象プランで利用できるかを確認します。担当者表示だけで承認フローや権限が満たされるとは言えません。

書き分けを進める順番

1. 元Sourceを固定する。 発表、記事、調査のURLと該当箇所を記録し、一次情報か二次説明かを区別します。

2. FactとBoundaryを抜き出す。 主体、日付、数値、条件、例外、未確認を共通表にします。媒体の違いを理由に省略しません。

3. 媒体ごとのReader Jobを決める。 読者に何を理解・判断・実行してほしいか一文で書きます。媒体の慣習だけで読者像を断定しません。

4. 必要なContextを決める。 省いても意味が変わらない説明、逆にないと誤解する説明を分けます。

5. Formatを選ぶ。 一つの要点で足りるか、複数段落や連投が必要かを決め、現行の公式仕様と利用条件を確認します。

6. 投稿案を媒体ごとに作る。 同じFact Sheetを渡し、Hook、説明深度、例、CTAをReader Jobに合わせます。

7. Evidenceを本文へ対応させる。 Claimごとに出典と境界を確認します。引きの強い表現でFactを広げないでください。

8. 三案を横に並べる。 数字、時点、主語、否定、可能性、CTAの意味が異なっていないか読み比べます。

9. 公開画面で確認する。 Link、改行、添付、Previewの見え方を投稿前に確認し、URLや画像が正しいかを点検します。

各媒体で何を変えるか

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

要素	変えてよいもの	変更しないもの
Opening	問い、状況、判断軸の順	Factの意味・確度
説明	Reader Jobに必要な前提	条件・例外
会話	質問や次Action	体験談や感想の捏造
Format	単独投稿、複数投稿、添付	引用・権利の範囲
CTA	媒体で実行できる次の一歩	遷移先の約束

Xの通常投稿、長い投稿、threadは同じ条件ではありません。X公式Helpは通常投稿と長文機能を別に案内しています。ThreadsもMetaがテキスト添付を含む投稿機能を案内しています。これらの機能がアカウントや時点ごとにどう見えるかは、実際のComposerと現在のヘルプで確認してください。LinkedInでは通常投稿とは別に記事を公開する機能もありますが、全投稿を職業的な教訓にする必要はありません。媒体の機能が使えるかと、その形式が読者の理解に役立つかは別の判断です。

AIへ渡すPrompt

次の確認済みSourceを、X、Threads、LinkedIn向けの投稿候補へ変換してください。Source URLと該当箇所は［Source］、変更しないFactは［Fact Sheet］、適用条件は［Boundary］、未確認は［Unknown］、各媒体のReader Jobは［Job］です。各案では変えてよい表現と変えてはいけないFactを分け、根拠を各Claimへ対応させてください。現在の媒体仕様や投稿機能を知らない場合は推測せず確認が必要と示してください。本人の経験、成果、数字、引用許可を創作せず、CTAは実際の行動と遷移先に合うものにしてください。最後に三案のFact差分を一覧化してください。

AIが返した内容はDraft候補です。実際の仕様やSourceを見ずに作られた媒体別の一般論を、そのプラットフォームの規則として掲載しないでください。LinkedInのAI支援投稿については、公式Helpが投稿者の見直し・編集と本人の視点を勧めています。投稿者が用意した経験や意見がない場合は、AIに一人称の体験談を書かせず、Factに基づく説明として扱います。Threadsの長文添付やXの長文・連投も、使えるアカウント条件を確認してから選びます。

よくある失敗と修正

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

失敗	読者への影響	修正
文字数だけを変える	読者の疑問が同じまま	Reader Jobと必要Contextを決め直す
媒体のイメージで口調を決める	根拠のないステレオタイプになる	実際の読者質問を使う
Xは必ずthreadと決める	不要な分割や条件漏れが起きる	1投稿で足りるか現行仕様と内容で判断
Threadsは必ず会話型にする	内容より問いかけが目立つ	問いに読者価値がある時だけ使う
LinkedIn用に業務成果を追加	事実でない成果を約束	Sourceで説明できる範囲へ戻す
各案でCTAを変えすぎる	Fact以外の差まで混ざる	投稿の目的と遷移先を横断確認

次に行うこと

一つの公開可能なSourceを選び、Fact、Boundary、Reader JobをBriefへ記録します。三媒体へ出す必要があるかを先に判断し、必要な案だけ作って、EvidenceとCTAを横断比較します。仕様が変わっていれば公開時に公式Helpを読み、古い文字数や投稿機能を固定ルールとして使わないでください。

AIものさしの判断

AIものさしの判断は、Source→Core Fact→Reader Job→Format→Cross-platform Readbackです。媒体の名前に文章を合わせるのではなく、同じ根拠を保ちながら、各読者に必要な文脈と次Actionを渡します。

公開後に見る数字と読み方

書き分けの結果を見るときは、まず投稿の目的と観測期間を記録します。認知を目的にした投稿と、資料請求や相談へ進んでもらう投稿では、同じ指標を成功条件にはできません。表示回数が違う投稿同士を単純に比べても、媒体の配信、投稿時刻、Audience、形式の差が残ります。比較の前に、分母、期間、対象投稿、CTA、他の施策の有無をメモします。

例えば保存数が増えても、それだけで説明が分かりやすくなったとは言えません。リンククリックが増えても、投稿の約束と遷移先が一致したか、読者が次の行動を終えたかは別に確認します。量が少なく結論を出せない場合は「勝者なし」と記録し、次回は一つだけ条件を変えます。投稿を作った人の印象と数値の観測も別欄に残すと、解釈がFactに置き換わりません。

運用チームへの引き渡し

Briefには投稿案だけでなく、確認担当、公開可能な時間、更新時の連絡先を記載します。Sourceが差し替わったとき、すでに予約された投稿や画像を誰が止めるかが曖昧なら、公開前に担当を決めます。投稿先ごとに担当が異なる場合でも、Core Factの正本は一つに保ち、各担当が別々の表現で事実を再入力しないようにします。公開後の訂正が必要になったときも、同じBriefから影響する案を探せます。