ClaudeでSNS運用ガイドラインを作る — 公式アカウントと社員の私的投稿を分ける
社内のSNS運用ガイドライン(ソーシャルメディアポリシー)を、ClaudeのProjectsで作る手順です。既存の規程と過去事例を材料に、投稿前チェック・承認者・炎上時の連絡経路の3部構成へ落とします。
SNS運用のルールが就業規則の一条と、広報担当の頭の中にしかない会社は少なくありません。炎上が起きてから「誰に連絡するのか」を探すことになります。
ClaudeのProjectsに既存の規程と過去事例を置けば、ばらばらのルールを1本のガイドラインに組み直せます。この記事では、公式アカウントの運用と社員の私的な投稿を分け、投稿前チェック・承認者・エスカレーション先の3部構成にする手順を説明します。
ガイドラインに書く内容を先に3つの部に分ける
ソーシャルメディアポリシーが読まれない原因の多くは、対象の違う話が1枚に混ざっていることです。最初に、誰の何を決める文書なのかを分けます。
| 対象 | 会社が決めること | 書き方の要点 |
|---|---|---|
| 公式アカウント | 会社が決めること投稿前チェック、承認者、運用担当 | 書き方の要点手順と責任者を具体的に書く |
| 社員の私的な投稿 | 会社が決めること守ってほしい線(機密、取引先、会社名の使い方) | 書き方の要点禁止の理由を添え、範囲を絞る |
| 炎上・誤投稿が起きたとき | 会社が決めること連絡経路、初動の判断者、公表の可否 | 書き方の要点連絡先を役職と部署で書く |
公式アカウントは会社の発信なので、チェックと承認を手順にできます。社員の私的な投稿は個人の生活の領域に入るため、手順ではなく「守ってほしい線」として書きます。私的な投稿をどこまで縛れるかは、人事・法務の判断が要る部分です。Claudeには線の候補を出させ、確定は人が行います。
3つ目の連絡経路は、前の2つの部が破れたときの受け皿です。投稿前チェックをすり抜けた誤投稿も、社員の私的投稿が会社の問題に発展した場合も、同じ経路に流れ込みます。
個別の投稿の点検はClaudeでSNS投稿前の炎上リスクをチェックする手順が扱っています。ここで作るのは、その点検が前提にする組織のルールそのものです。
手順1: 規程と事例を置くプロジェクトを作る
ガイドライン専用のプロジェクトを作ります。Projectsは、独自のチャット履歴とナレッジベースを持つ作業場です。文書をアップロードすると、そのプロジェクト内のチャットで文脈として使われます。無料アカウントでも使え、作れるプロジェクトは最大5つです。
プロジェクトの準備
- 1
プロジェクトを作る
「Projects」から「+ New Project」を押し、名前を付けます。名前と説明はClaudeには渡りません。基準は名前ではなく、次のナレッジと指示に書きます。
- 2
公開範囲を決める
TeamまたはEnterpriseプランでは、「Keep it private」か「Share with your broader organization」を選べます。ガイドラインの下書き中は非公開にし、確定してから共有する運用が扱いやすい形です。管理者が共有を止めている組織では、全社共有を選べません。
- 3
資料をナレッジに入れる
右側のナレッジに資料をアップロードします。入れる資料は次の表のとおりです。
- 4
指示を保存する
「Set project instructions」から指示を保存します。指示はプロジェクト内のすべてのチャットに適用されます。
ナレッジに入れる資料は、ガイドラインの3つの部に対応させて選びます。
| 資料 | 主に効く部 | 入れるときの注意 |
|---|---|---|
| 就業規則のSNS関連条項、情報管理規程 | 主に効く部社員の私的な投稿 | 入れるときの注意条文は原文のまま入れる |
| 現行の広報ルール、投稿の承認メモ | 主に効く部投稿前チェック・承認者 | 入れるときの注意実際の運用と違う点を注記する |
| 過去の炎上・クレーム事例の要約 | 主に効く部投稿前チェック・連絡経路 | 入れるときの注意実名や個人を特定する情報は伏せる |
| 社内の緊急連絡網、役職一覧 | 主に効く部連絡経路 | 入れるときの注意氏名ではなく役職で整理する |
プロジェクトの中でも、チャット間で文脈は共有されません。あるチャットで決めた方針は、ナレッジに追記しない限り別のチャットには届きません。ガイドラインを何度かに分けて作るなら、決定事項を1枚の「確定事項メモ」としてナレッジに足していきます。
メモリはプロジェクトごとに分かれています。下書きの試行錯誤を残したくないチャットでは、最初のメッセージを送る前に「+」メニューで「Memory」をオフにします。
有料プランでは、ナレッジが上限に近づくとRAGモードが自動で有効になり、容量が最大10倍まで広がります。過去事例が多い会社は、有料プランのほうが資料を絞らずに済みます。
なお、Projectsにはベータの新バージョンがあり、Claude Codeを使う一部のPro・Maxに順次提供されています。チャットやCoworkにある既存のプロジェクトは当面そのまま動くため、この記事は既存のプロジェクトを前提にしています。
手順2: 指示文で3部構成と空欄のルールを固定する
指示には、出力の形と、分からないことの扱いを書きます。連絡先や承認者の氏名は、Claudeが知り得ない情報です。作らせずに空欄で返させます。
あなたは社内SNS運用ガイドラインの起案担当です。
ナレッジの規程・広報ルール・過去事例だけを根拠に、
次の3部構成で条文案を作ってください。
第1部 公式アカウントの投稿前チェック
第2部 承認者と運用担当、社員の私的な投稿で守る線
第3部 炎上・誤投稿が起きたときの連絡経路
守ること:
- 各条文の末尾に、根拠にした資料名を括弧で付ける
- ナレッジに根拠がない内容は条文にせず「要確認」として別に列挙する
- 氏名・電話番号・メールアドレスは作らず「【記入】」と書く
- 就業規則の条文と矛盾しそうな箇所は、条文を引用して指摘する
- 法律の適否は判断せず、法務に確認する論点として挙げる「要確認」の列挙を指示に入れる点が肝心です。ナレッジに根拠がない内容を条文に混ぜられると、読む側は何が資料の裏付けのある内容かを区別できません。
手順3: 3部の条文案を作らせて、人が埋める
指示を保存したら、新しいチャットで起案を頼みます。最初から全文を求めず、部ごとに分けると確認しやすくなります。
第1部を起案してください。
公式アカウントはX、Instagram、LINE公式アカウントの3つです。
投稿の種類は、お知らせ、キャンペーン、採用広報、一般向けの情報です。
種類ごとに投稿前に確認する項目を表にしてください。出てくる条文案は、たとえば次のような骨格になります(形の例であり、Claudeの出力そのままではありません)。
第1部 公式アカウントの投稿前チェック
1. 投稿前に次を確認する(根拠:広報ルール_2024.pdf)
- 数字・日付・価格が社内資料と一致している
- 他社・個人を特定できる表現がない
- 画像・引用の権利を確認した
2. キャンペーンや懸賞の投稿は法務の確認を経る(根拠:要確認)
第2部 承認者と運用担当
3. 承認者は【記入】部【記入】職とする
第3部 連絡経路
4. 誤投稿に気づいた者は直ちに運用担当へ連絡する骨格のうち「【記入】」の箇所は、人が埋める場所です。承認者の肩書や連絡先を埋めるのは、広報や総務の責任者の仕事になります。
炎上時の連絡経路は段階に分けて書く
第3部は、事案の大きさで経路が変わることを条文に表します。次の表は段階分けの例です。段階の数や基準は会社ごとに決めます。
| 段階 | 状況の例 | 最初の連絡先 | 判断者 |
|---|---|---|---|
| 軽微 | 状況の例誤字、リンク切れの投稿 | 最初の連絡先運用担当 | 判断者運用担当 |
| 中程度 | 状況の例表現への批判が複数寄せられた | 最初の連絡先広報責任者 | 判断者広報責任者 |
| 重大 | 状況の例取引先や個人への言及、報道への波及 | 最初の連絡先経営層・法務 | 判断者経営層 |
Claudeには、この表の「状況の例」を過去事例の要約から拾わせると具体的になります。連絡先と判断者の欄は、役職までをClaudeに案として出させ、実在の担当者との対応は人が確かめます。
投稿を削除するか、謝罪を出すかといった初動の判断を、段階ごとにどの役職が持つのかも決めます。ここが曖昧だと、誰も判断せずに時間だけが過ぎます。初動を誰が決めるかを書く条文は、第3部の中核です。障害時の対外文の作り方はClaudeで障害のお知らせ文とサポート想定問答を作るに、同じ枠組みの考え方があります。
手順4: 想定シナリオで条文の穴を探す
条文案ができたら、ガイドラインを運用する側に立たせて穴探しをします。ナレッジに確定版の条文を追記したうえで、実際にありそうな場面を渡します。
ナレッジのガイドライン案だけを根拠に、次の場面で
誰が何をするかを時系列で答えてください。
条文から答えが出せない箇所は「条文に定めなし」と書いてください。
場面1: 運用担当が誤った価格を投稿し、10分後に気づいた
場面2: 社員が私的アカウントで取引先の社名を挙げて愚痴を書いた
場面3: 公式投稿への批判が増え、報道機関から問い合わせが来た「条文に定めなし」と返ってきた場面が、ガイドラインの穴です。穴を条文に足し、確定事項メモを更新して、もう一度同じ場面を試します。この往復で、机上では気づきにくい抜けが見つかります。
シナリオは過去事例の要約から作ると、現実に近づきます。事例を入れている強みは、この段階で出ます。
社員に投稿を頼む場面の表示ルールを入れる
公式アカウントと私的投稿の境目で見落としやすいのが、会社が社員に投稿を頼むケースです。たとえば新商品について、社員の私的アカウントでも発信してほしいと依頼する場面が考えられます。
消費者庁は、令和5年10月1日からステルスマーケティングが景品表示法違反となったと案内しています。規制されるのは、広告であって、一般消費者が広告であることを分からないものです。広告には、企業が第三者に依頼・指示するものも含まれます。規制の対象は広告主である事業者で、依頼を受けた側ではありません。
社員の投稿が広告にあたるかは、依頼の内容や投稿の見え方で個別に判断されます。Claudeに適否を決めさせず、ガイドラインには次の欄を設けておきます。
- 会社が社員に投稿を依頼・指示する場合は、事前に広報と法務へ連絡する
- 依頼した投稿には、広告・宣伝であることが分かる表示を付けるかを決める
- 社員が自発的に書く感想と、依頼した投稿を区別して扱う
落とし穴
Claudeが書いた条文がそのまま規程になってしまう
起案した条文には、就業規則や法令との整合を確かめていないものが混じります。「要確認」の列挙を飛ばして条文だけ配布すると、根拠のないルールが社内に出回ります。確定版は、人事・法務・広報の責任者が目を通してから公開します。
確定したら共有し、改訂の入口を一つにする
TeamまたはEnterpriseプランでは、確定したプロジェクトを組織に共有できます。共有の権限には「Can view」と「Can edit」があります。「Can view」は内容を見てチャットもできますが、編集はできません。「Can edit」は指示やナレッジの変更に加え、メンバーの追加・削除もできます。
役割の割り当て方の一例です。
- 広報責任者・総務の責任者: Can edit
- 一般の社員: Can view
「Can view」のメンバーは、プロジェクトの中でガイドラインを根拠に質問できます。「この投稿は承認が必要か」といった問い合わせを、広報への個別連絡から減らせます。
共有をオフにしている組織では、プロジェクトを使った共有そのものができません。その場合は、確定版の条文をPDFなどの文書にして配り、Projectsは起案と改訂の作業場に使います。
ガイドラインは作って終わりではなく、事例が増えるたびに見直す文書です。改訂は、ナレッジの確定事項メモを更新し、同じ手順で条文案を作り直す流れに一本化できます。月次の投稿計画との連動はClaudeのProjectsでSNS投稿カレンダーを月単位で管理するが受けています。
規程と対応づけて管理する発想は、情報セキュリティの文書でも使われます。たとえばISMSの適用宣言書(SoA)をClaudeで下書きするは、社内規程との対応表を作る手順です。
まとめ
ガイドラインの品質を決めるのは、Claudeの文章力より、置く資料と「要確認」を切り出す指示です。ナレッジに根拠のない内容を条文に混ぜず、連絡先は空欄で返させ、確定は人事・法務・広報の責任者が行います。3つの部のうち、最初に手を付けると効果が出やすいのは第3部の連絡経路です。誤投稿が起きたときに初動の判断者が決まっているだけで、動き出しの速さが変わります。