ClaudeでSNS投稿前の炎上リスクをチェックする手順

SNSの投稿は、送信した瞬間に手を離れます。炎上の芽を投稿前に見つけたいなら、Claudeを「第一読者」として使うのが現実的です。ただし、Claudeが自力で炎上を予測できるわけではありません。自社の基準と過去の事例を渡し、その物差しで文案を点検させる形にすると、確認作業が安定します。

この記事では、ClaudeのProjectsを使ってチェック専用の作業場を作る手順を説明します。最後に、Claudeに任せない判断と、人が残す確認の線引きも示します。

Claudeに炎上チェックを頼むと何が変わるか

炎上リスクの点検は、担当者の経験に頼りがちです。「なんとなく引っかかる」という感覚は、担当が替わると引き継げません。

Claudeに点検を頼む利点は、観点を毎回同じ順で当てられることです。投稿者が気づきにくい読み方を、複数の立場から並べさせることもできます。

一方で、Claudeが扱えるのは渡された文面と資料の範囲です。次のことは、資料を渡さない限り判断の材料がありません。

• 今この瞬間、投稿先で何が話題になっているかの把握
• 自社アカウントのフォロワーが過去にどう反応したか
• 違法かどうかの確定判断

この線引きは後の節で扱います。先に、点検の土台になるProjectsを作ります。

手順1: チェック専用のプロジェクトを作る

Projectsは、独自のチャット履歴とナレッジベースを持つ、自己完結した作業場です。文書をアップロードして文脈を与え、その文脈を前提にClaudeと会話できます。無料アカウントを含む全ユーザーが使えます。無料アカウントで作れるプロジェクトは最大5つです。

作り方は次のとおりです。

1. 左側のメニューから「Projects」を開き、右上の「+ New Project」を押す
2. 名前と説明を入力する(この名前と説明はClaudeには渡らない)
3. TeamまたはEnterpriseプランなら、公開範囲を選ぶ。「Keep it private」は自分と招待したメンバーだけが使える設定。「Share with your broader organization」は組織の全員が使える設定(管理者の許可が前提)

名前や説明にチェックの基準を書いても、Claudeは読みません。基準は次の手順で、指示とナレッジに入れます。

Projectsにはベータの新バージョンもあり、Claude Codeを使う一部のPro・Maxから順次提供されています。チャットやCoworkにある既存のプロジェクトは、これまでどおり動きます。この記事の手順は既存のプロジェクトを前提にしています。

手順2: ナレッジに基準と過去事例を入れる

ナレッジベースに置いた資料は、そのプロジェクト内のすべてのチャットで使われます。炎上チェックでは、次の3種類を入れると点検の精度が上がります。

過去事例は、投稿文と反応の要旨を1事例につき数行にまとめておくのが扱いやすい形です。実名や個人を特定する情報は、資料に入れる前に伏せてください。

有料プランでは、ナレッジがコンテキストの上限に近づくと、RAGモードが自動で有効になります。容量は最大10倍まで広がります。RAGによる拡張は有料プランだけの仕組みです。無料プランで事例を増やすときは、1事例を数行に絞った資料にします。

覚えておきたい前提が1つあります。プロジェクト内でも、チャット間の文脈は共有されません。あるチャットで「この表現はOK」と結論を出しても、別のチャットには伝わりません。承認済みの判断を次回以降に使いたいなら、ナレッジに追記します。

メモリは別の仕組みで、プロジェクトごとに分かれており、プロジェクト外のチャットとも混ざりません(Team・Enterpriseでは、オーナーがメモリを有効にしている場合)。投稿前の試し打ちを記憶に残したくないときは、最初のメッセージを送る前に「+」メニューで「Memory」をオフにします。この方法で始めたチャットは、プロジェクトのメモリを使わず、書き込みもしません。

手順3: プロジェクト指示にチェック項目を書く

「Set project instructions」から、プロジェクト指示を保存します。指示はプロジェクト内のすべてのチャットに適用されます。

ここに、点検の観点と出力の形を固定します。例えば次のような形です。

あなたはSNS投稿の公開前チェック担当です。
ナレッジのブランドガイドラインと過去事例だけを基準に、
投稿文案を次の5項目で点検してください。
 
1. 誤解を招く表現(断定、省略、数字の見せ方)
2. 差別的・攻撃的と受け取られうる表現
3. 競合や他社を比較・言及している箇所
4. 時事・災害・社会問題と重なって見える箇所
5. 過去事例と構造が似ている箇所
 
各項目について「懸念あり / 懸念なし / 判断材料不足」のいずれかを付け、
懸念ありの場合は該当する文言を原文のまま引用してください。
ナレッジに根拠がない判断は「判断材料不足」としてください。
最後に、人が確認すべき点を1〜3個挙げてください。

この指示には、点検精度を支える3つの仕掛けが入っています。

手順4: 投稿文案を貼って点検させる

指示を保存したら、プロジェクト内で新しいチャットを開き、文案を貼ります。

次の投稿文案を点検してください。
投稿先: X(旧Twitter)
想定読者: 20〜30代の既存顧客
文案:
[ここに投稿文案を貼る]

投稿先と想定読者を添える点が大切です。同じ文面でも、媒体や読者が変われば受け取られ方が変わります。

Claudeの出力は、あくまで点検メモです。修正案をそのまま採用せず、投稿者が言葉を選び直す前提で使います。点検の物差しになる組織のルール自体を文書にする手順は、ClaudeでSNS運用ガイドラインを作るで扱っています。

点検結果の出力例

架空の文案「今夜だけ、全商品が最安値。他社より確実にお得です」を点検させると、たとえば次の形で返ってきます。

1. 誤解を招く表現: 懸念あり
   「全商品が最安値」「確実にお得」
2. 差別的・攻撃的と受け取られうる表現: 懸念なし
3. 競合や他社への言及: 懸念あり
   「他社より」
4. 時事・災害・社会問題との重なり: 判断材料不足
   ナレッジに今日の話題を判断できる資料がありません
5. 過去事例と構造が似ている箇所: 懸念なし
人が確認すべき点: 最安値の根拠資料、他社比較の可否、投稿日の話題

項目4が「判断材料不足」になったのは、ナレッジに今日の話題を判断できる資料が入っていないためです。最後の「人が確認すべき点」は、そのまま承認フローの確認項目に転記できます。

この例のように、項目1と3の指摘は文案の書き換えを促しますが、書き換え後の文面が事実と合うかどうかまでは、Claudeの点検では確定しません。

指摘の信頼度を上げる3つの追加テクニック

点検結果が「それらしいだけ」になるのを避けるには、Claude向けの公式資料にある幻覚(ハルシネーション)対策が使えます。次の3つを、点検の後に足します。

指摘ごとに根拠を探させる

懸念ありと判断した項目について、ナレッジの中から支える文言を見つけさせます。見つからない指摘は取り下げさせます。この方法は主張を検証する手段として紹介されています。

先ほどの「懸念あり」の各項目について、
ナレッジ内でその判断を支える文言を引用してください。
引用できない項目は、指摘を取り下げてください。

同じ文案を複数回点検して比べる

同じ指示で繰り返し点検させ、結果が食い違う項目に印を付けます。回答が安定しない項目は、Claudeの判断が揺らいでいる場所です。人が重点的に読む対象になります。

判定に至る理由を読む

公式資料では、答えがおかしいと感じたときに、thinkingの要約(display: "summarized")を読んで論理や前提の誤りを探す方法が紹介されています。これはAPIで使う手法です。チャットで使うなら、判定の前に理由を順に書かせる形に置き換えます。

これらの技法は幻覚を大きく減らしますが、なくすものではありません。重要な判断は、人が確かめる運用が前提になります。

人が判断を残すべき線引き

炎上チェックで最も避けたいのは、Claudeの「懸念なし」を承認と取り違えることです。役割を次のように分けると運用が安定します。

法的な判断が絡む投稿は、法務の確認を経てから公開する運用が安全です。ステマ規制についてはClaudeでステマ規制のPR表記漏れをチェックする方法、優良誤認や比較広告については景品表示法の表示チェックはClaudeでどこまでできるかで、論点と限界を整理しています。

最終承認者は、フローの中で名前を決めておきます。「Claudeが問題なしと言った」を理由にした公開は、責任の所在が曖昧になります。すでに起きた不祥事への初動声明を書く場面は、Claudeでお詫び文と謝罪リリースの初動声明を下書きする手順で扱っています。

チームで使うときの共有と権限

TeamとEnterpriseプランでは、プロジェクトを組織内で共有できます。権限は2段階です。

共有するには、プロジェクトを開いて名前の右にある「Share project」を押し、メンバーの名前かメールアドレスを入れて権限を選びます。メールアドレスの一覧を貼れば、まとめて追加できます。共有されたプロジェクトは、Projectsページの「Your projects」「Organization」「Shared with you」の3タブのどれかに並びます。

炎上チェックのように基準を統一したい用途では、少数の管理担当にCan editを渡し、投稿担当者にはCan viewを渡す構成が向いています。投稿担当が基準を書き換えられない形にすると、「点検が通るようにルールを緩める」事態を防げます。

なお、管理者が共有を無効にしている組織では、プロジェクトを共有できません。Ownerがパブリックなプロジェクトを無効にすると、組織全体への共有も使えなくなります。共有をオフにしても、すでにある共有は残ります。

事例資料を片付けるとき

プロジェクトはアーカイブできますが、共有権限もメンバーもナレッジもそのまま残ります。過去事例を特定のメンバーに見せたくなくなったときは、共有設定でそのメンバーを外します。アーカイブしたプロジェクトは、元に戻すまで削除できません。事例資料ごと消すなら、アーカイブを解除してから削除します。

よくあるつまずき

基準を書かずに「炎上しそうか」だけを聞く

物差しがないと、Claudeの回答は一般論に寄ります。ナレッジと指示に自社の基準を置いてから使います。

過去事例に個人情報が残っている

炎上事例の資料に、当事者の実名やアカウント名が入っていないか確認します。資料はプロジェクトの共有相手全員から見えます。

「懸念なし」が続いて安心する

観点が5項目に絞られていると、範囲外の問題は見落とされます。新しい種類のクレームが出たら、その事例をナレッジに追記して観点を更新します。

チャットごとに結論がばらつく

チャット間の文脈は共有されないので、承認した言い回しはナレッジに残します。

投稿文の作成と点検を同じチャットで行う

作った本人に点検させると、自己弁護に寄りやすくなります。文案づくりはキャプション用の作業場に分け、点検は別のプロジェクトで行うと切り分けやすくなります。文案の出し方はClaudeにSNS投稿文とキャプションを考えてもらう手順、月単位の運用はClaudeのProjectsでSNS投稿カレンダーを月単位で管理するにまとめています。

まとめ

Claudeの「懸念なし」は、承認の代わりになりません。次の工程に渡すのは「懸念なし」の数ではなく、「人が確認すべき点」に残った項目です。

投稿フローには、承認者の名前と承認した言い回しの追記先を先に書いておきます。点検結果が溜まるほどナレッジが厚くなり、判断材料不足の項目も減っていきます。