ClaudeでSNS投稿前の炎上リスクをチェックする手順
Projectsに自社のブランドガイドラインと過去の炎上事例を登録し、投稿文案を項目別に点検させる手順です。Claudeに任せる範囲と、人が最終判断する線引きも示します。
SNSの投稿は、送信した瞬間に手を離れます。炎上の芽を投稿前に見つけたいなら、Claudeを「第一読者」として使うのが現実的です。ただし、Claudeが自力で炎上を予測できるわけではありません。自社の基準と過去の事例を渡し、その物差しで文案を点検させる形にすると、確認作業が安定します。
この記事では、ClaudeのProjectsを使ってチェック専用の作業場を作る手順を説明します。最後に、Claudeに任せない判断と、人が残す確認の線引きも示します。
Claudeに炎上チェックを頼むと何が変わるか
炎上リスクの点検は、担当者の経験に頼りがちです。「なんとなく引っかかる」という感覚は、担当が替わると引き継げません。
Claudeに点検を頼む利点は、観点を毎回同じ順で当てられることです。投稿者が気づきにくい読み方を、複数の立場から並べさせることもできます。
一方で、Claudeが扱えるのは渡された文面と資料の範囲です。次のことは、資料を渡さない限り判断の材料がありません。
- 今この瞬間、投稿先で何が話題になっているかの把握
- 自社アカウントのフォロワーが過去にどう反応したか
- 違法かどうかの確定判断
この線引きは後の節で扱います。先に、点検の土台になるProjectsを作ります。
手順1: チェック専用のプロジェクトを作る
Projectsは、独自のチャット履歴とナレッジベースを持つ、自己完結した作業場です。文書をアップロードして文脈を与え、その文脈を前提にClaudeと会話できます。無料アカウントを含む全ユーザーが使えます。無料アカウントで作れるプロジェクトは最大5つです。
作り方は次のとおりです。
- 左側のメニューから「Projects」を開き、右上の「+ New Project」を押す
- 名前と説明を入力する(この名前と説明はClaudeには渡らない)
- TeamまたはEnterpriseプランなら、公開範囲を「自分だけ」か「組織全体」から選ぶ
名前や説明にチェックの基準を書いても、Claudeは読みません。基準は次の手順で、指示とナレッジに入れます。
手順2: ナレッジに基準と過去事例を入れる
ナレッジベースに置いた資料は、そのプロジェクト内のすべてのチャットで使われます。炎上チェックでは、次の3種類を入れると点検の精度が上がります。
| 資料 | 入れる中身 | 何に効くか |
|---|---|---|
| ブランドガイドライン | 入れる中身口調、禁止表現、扱わない話題 | 何に効くか自社らしさと社内ルールの照合 |
| 過去の炎上・クレーム事例 | 入れる中身自社や同業で起きた事例と、何が問題視されたか | 何に効くか似た構造の文案の検出 |
| 投稿の承認フロー | 入れる中身誰が何を確認して公開するか | 何に効くか最終判断の担当を明示 |
過去事例は、投稿文と反応の要旨を1事例につき数行にまとめておくのが扱いやすい形です。実名や個人を特定する情報は、資料に入れる前に伏せてください。
有料プランでは、ナレッジがコンテキストの上限に近づくと、RAGモードが自動で有効になります。容量は最大10倍まで広がります。事例が増えても、資料を厳選し直す必要は当面ありません。
覚えておきたい前提が1つあります。プロジェクト内でも、チャット間の文脈は共有されません。あるチャットで「この表現はOK」と結論を出しても、別のチャットには伝わりません。承認済みの判断を次回以降に使いたいなら、ナレッジに追記します。
手順3: プロジェクト指示にチェック項目を書く
「Set project instructions」から、プロジェクト指示を保存します。指示はプロジェクト内のすべてのチャットに適用されます。
ここに、点検の観点と出力の形を固定します。例えば次のような形です。
あなたはSNS投稿の公開前チェック担当です。
ナレッジのブランドガイドラインと過去事例だけを基準に、
投稿文案を次の5項目で点検してください。
1. 誤解を招く表現(断定、省略、数字の見せ方)
2. 差別的・攻撃的と受け取られうる表現
3. 競合や他社を比較・言及している箇所
4. 時事・災害・社会問題と重なって見える箇所
5. 過去事例と構造が似ている箇所
各項目について「懸念あり / 懸念なし / 判断材料不足」のいずれかを付け、
懸念ありの場合は該当する文言を原文のまま引用してください。
ナレッジに根拠がない判断は「判断材料不足」としてください。
最後に、人が確認すべき点を1〜3個挙げてください。この指示には、点検精度を支える3つの仕掛けが入っています。
- 判断材料不足を選べる: Claudeに「分からない」と答える許可を明示すると、誤情報が大きく減ります。Anthropicの資料も、この方法を基本策に挙げています
- 原文を引用させる: 根拠の文言を抜き出させると、指摘の当否を投稿者が目視で確かめられます
- ナレッジだけを基準にさせる: 一般知識ではなく、提供した資料に判断を限定する指示です。基準がぶれにくくなります
手順4: 投稿文案を貼って点検させる
指示を保存したら、プロジェクト内で新しいチャットを開き、文案を貼ります。
次の投稿文案を点検してください。
投稿先: X(旧Twitter)
想定読者: 20〜30代の既存顧客
文案:
[ここに投稿文案を貼る]投稿先と想定読者を添える点が大切です。同じ文面でも、媒体や読者が変われば受け取られ方が変わります。
返ってきた点検結果は、次の順で読みます。
- 「懸念あり」の項目と、引用された原文を確かめる
- 「判断材料不足」の項目を、人が判断する宿題にする
- 修正案が出たら、意図が変わっていないかを元の企画と照らす
Claudeの出力は、あくまで点検メモです。修正案をそのまま採用せず、投稿者が言葉を選び直す前提で使います。
点検結果の出力例
架空の文案「今夜だけ、全商品が最安値。他社より確実にお得です」を点検させると、たとえば次の形で返ってきます。
1. 誤解を招く表現: 懸念あり
「全商品が最安値」「確実にお得」
2. 差別的・攻撃的と受け取られうる表現: 懸念なし
3. 競合や他社への言及: 懸念あり
「他社より」
4. 時事・災害・社会問題との重なり: 判断材料不足
ナレッジに今日の話題を判断できる資料がありません
5. 過去事例と構造が似ている箇所: 懸念なし
人が確認すべき点: 最安値の根拠資料、他社比較の可否、投稿日の話題読み方の要点は3つあります。「懸念あり」の下に原文が引用されているので、指摘が的外れかどうかはその引用を見れば判断できます。項目4のように「判断材料不足」が付いた箇所は、Claudeが分からないと答えた場所で、人が投稿先を見て決める宿題です。最後の「人が確認すべき点」は、そのまま承認フローの確認項目に転記できます。
この例のように、項目1と3の指摘は文案の書き換えを促しますが、書き換え後の文面が事実と合うかどうかまでは、Claudeの点検では確定しません。
指摘の信頼度を上げる3つの追加テクニック
点検結果が「それらしいだけ」になるのを避けるには、Claude向けの公式資料にある幻覚(ハルシネーション)対策が使えます。次の3つを、点検の後に足します。
指摘ごとに根拠を探させる
懸念ありと判断した項目について、ナレッジの中から支える文言を見つけさせます。見つからない指摘は取り下げさせます。この方法は主張を検証する手段として紹介されています。
先ほどの「懸念あり」の各項目について、
ナレッジ内でその判断を支える文言を引用してください。
引用できない項目は、指摘を取り下げてください。同じ文案を複数回点検して比べる
同じ指示で繰り返し点検させ、結果が食い違う項目に印を付けます。回答が安定しない項目は、Claudeの判断が揺らいでいる場所です。人が重点的に読む対象になります。
段階的に理由を書かせる
最終判定の前に、理由を順に説明させると、論理のおかしな点が見つかりやすくなります。
これらの技法は幻覚を大きく減らしますが、なくすものではありません。重要な判断は、人が確かめる運用が前提になります。
人が判断を残すべき線引き
炎上チェックで最も避けたいのは、Claudeの「懸念なし」を承認と取り違えることです。役割を次のように分けると運用が安定します。
| 判断の種類 | Claudeの役割 | 最終判断 |
|---|---|---|
| 表現のトーン、言い回し | Claudeの役割案の提示と指摘 | 最終判断投稿者・担当 |
| ブランドガイドラインとの整合 | Claudeの役割基準に照らした点検 | 最終判断担当・承認者 |
| 事実関係(数字、日付、固有名詞) | Claudeの役割疑わしい箇所の列挙 | 最終判断人が一次資料で確認 |
| 景品表示法などの法的判断 | Claudeの役割論点の整理まで | 最終判断法務・専門家 |
| 今の話題や空気との重なり | Claudeの役割判断材料不足として返す | 最終判断人が投稿先を目で確認 |
法的な判断が絡む投稿は、法務の確認を経てから公開する運用が安全です。ステマ規制についてはClaudeでステマ規制のPR表記漏れをチェックする方法、優良誤認や比較広告については景品表示法の表示チェックはClaudeでどこまでできるかで、論点と限界を整理しています。
最終承認者は、フローの中で名前を決めておきます。「Claudeが問題なしと言った」を理由にした公開は、責任の所在が曖昧になります。
チームで使うときの共有と権限
TeamとEnterpriseプランでは、プロジェクトを組織内で共有できます。権限は2段階です。
- Can view: 内容、ナレッジ、指示を見て、プロジェクト内でチャットできる。編集はできない
- Can edit: 指示やナレッジを変更でき、メンバー設定の更新もできる
炎上チェックのように基準を統一したい用途では、基準を管理する少数の担当にCan editを渡し、投稿担当者にはCan viewを渡す構成が向いています。投稿担当が基準を書き換えられない形にすると、「点検が通るようにルールを緩める」事態を防げます。
なお、管理者が共有を無効にしている組織では、プロジェクトを共有できません。Ownerがパブリックなプロジェクトを無効にすると、組織全体への共有も使えなくなります。
よくあるつまずき
基準を書かずに「炎上しそうか」だけを聞く
物差しがないと、Claudeの回答は一般論に寄ります。ナレッジと指示に自社の基準を置いてから使います。
過去事例に個人情報が残っている
炎上事例の資料に、当事者の実名やアカウント名が入っていないか確認します。資料はプロジェクトの共有相手全員から見えます。
「懸念なし」が続いて安心する
観点が5項目に絞られていると、範囲外の問題は見落とされます。新しい種類のクレームが出たら、その事例をナレッジに追記して観点を更新します。
チャットごとに結論がばらつく
チャット間の文脈は共有されないので、承認した言い回しはナレッジに残します。
投稿文の作成と点検を同じチャットで行う
作った本人に点検させると、自己弁護に寄りやすくなります。文案づくりはキャプション用の作業場に分け、点検は別のプロジェクトで行うと切り分けやすくなります。文案の出し方はClaudeにSNS投稿文とキャプションを考えてもらう手順、月単位の運用はClaudeのProjectsでSNS投稿カレンダーを月単位で管理するにまとめています。
まとめ
炎上チェックの核は、自社の基準と過去事例をProjectsに置き、投稿文案を毎回同じ観点で点検させることです。指示で「判断材料不足」を選べるようにし、原文を引用させると、指摘の当否を確かめやすくなります。
ただし、Claudeの点検は最終判断の代わりになりません。事実関係、法的判断、今の空気との重なりは、人が一次資料と投稿先を見て確かめます。Claudeは、その確認作業の前に論点を並べる第一読者です。