SNS運用が中の人に依存する原因｜引き継げる体制をつくる

「あの人がいないと投稿が止まるんです」「トンマナが担当者の感覚頼みで、他の人が書くと雰囲気が変わってしまう」——SNS運用の引き継ぎ相談で最初に出てくるのは、たいていこうした声です。担当者が優秀であるほど、アカウントはその人の判断に最適化されていきます。ところが異動や退職でその人が抜けた瞬間、投稿は止まり、数字は静かに落ちていきます。SNS運用支援を手がけるSALの解説記事は、担当者の退職で失われるものとしてKPIの設定・文章のトーン・画像の選定基準といった「文書化しにくい意思決定」を挙げ、判断基準の習得には数か月のOJTが必要だと指摘しています。つまり属人化の本体は作業手順ではなく判断です。引き継ぎ書をタスクリストとして書いても、判断基準そのものは渡らない——ここが多くの引き継ぎがうまくいかない理由です。本記事では、属人化が起きる構造を3層に分解し、引き継ぎドキュメントに書くべき項目、アカウント権限と認証情報の移行、複数人運用の承認フロー、体制の選択肢の比較、そして生成AIでトンマナを言語化して再現する手順までを順に整理します。

「中の人が辞めると止まる」構造を3層に分解する

属人化を「担当者が有能すぎたから」で片づけてしまうと、打つ手が見つかりません。分解すると、SNS運用の属人化は3つの層に整理できます。1つ目が表現の層——文体・語尾・絵文字の使い方・画像の選び方といった、見た目に現れる部分です。2つ目が判断の層——何を投稿しないか、批判的なコメントに返すか黙るか、数字が落ちたときに施策を変えるか待つか、という意思決定です。3つ目が権限の層——ログイン情報、2段階認証の受け取り先、管理者権限を誰が持っているかという鍵の所在です。

引き継ぎ書に書かれるのは、ほとんどの場合1つ目の表現の層だけです。判断の層は担当者本人も言語化していないため書かれず、権限の層は「後でやる」と言われたまま退職日を迎えます。ガイアックスのSNS運用マニュアル解説も、属人化の原因を「この時間帯の投稿はエンゲージメントが高い」といった経験則が暗黙知として個人に蓄積され、言語化されないことに置いています。経験則が本人の中で完結している状態が、属人化の正体です。

手当ての順番も、この3層で決まります。権限が渡っていなければ投稿自体ができず、その日から運用が止まります。判断が渡っていなければ運用は続きますが、数か月かけて数字が落ちます。表現が渡っていなければ、読者が「なんとなく違う」と感じる違和感が残ります。止まると即座に困るのは権限、じわじわ効くのは判断、最後に表情が変わるのが表現——優先度はこの順に置くのが実務的です。

属人化の正体①：トンマナが担当者の頭の中にある

トンマナ（トーン＆マナー）が「なんとなく」で共有されている状態は、驚くほど広く見られます。敬体か常体か、一人称は「私たち」か「弊社」か、絵文字を使うか使わないか、感嘆符を許すか、改行はどこで入れるか、読者への呼びかけを「皆さん」にするか。これらは全部が判断で、しかもどれも明文化されていないのが普通です。ガイアックスが挙げるマニュアル項目にも、文体・絵文字・敬称の統一とNG表現リストが並んでいます。

言語化のコツは、形容詞ではなく実例で示すことです。「親しみやすく、でも軽すぎない」と書いても後任には伝わりません。過去投稿から「この書き出しはOK」「この言い回しは避けた」という具体例を10本ずつ抜き出して並べるほうが、はるかに速く伝わります。トンマナは定義文より判例集で伝わると考えて、良い例と避けた例をセットで残してください。

あわせて決めておきたいのが、迷ったときの優先順位です。たとえば「正確さ＞親しみやすさ」と1行決めておけば、専門用語をかみ砕くか正確に書くかで迷ったときの答えが出ます。この優先順位の1行があるかどうかで、後任が自分で判断できる範囲が大きく変わります。禁止語リストと優先順位、この2つはトンマナ資料の中でも最初に用意すべき部分です。

属人化の正体②：過去の判断基準が記録に残らない

投稿された内容は記録に残りますが、投稿されなかった案は消えます。途中で差し替えた表現、公開直前に落とした企画、あえて返信しなかったコメント——基準が最も濃く宿っているのは、この「やらなかったこと」の側です。ところが引き継ぎ資料には成功した投稿だけが並び、なぜ他の案を捨てたのかは残りません。後任は同じ地雷を踏み直すことになります。

対策はシンプルで、判断ログを1行で残すことです。形式は「日付／対象／取った選択／理由1行／結果」で足ります。たとえば「7/12／新機能の投稿／リリース日を明記せず『近日』にした／開発の確定前だったため／反応は平常」。この粒度で3か月分たまれば、後任は基準を推測できます。判断の理由を1行で残す習慣が、そのまま引き継ぎ資料になるという発想に切り替えてください。

• 判断ログは完璧を目指さず、1件1行・30秒で書ける形式にする（重くすると続かない）
• 「やらなかった判断」を優先して記録する。実行した投稿は結果が残るが、見送りは記憶からしか辿れない
• 月末にログを読み返し、繰り返し出てくる理由をトンマナ資料やNG表現リストに昇格させる

属人化の正体③：アカウント権限と認証が個人に紐づく

最も事故になりやすいのが権限の層です。SNSアカウントが担当者の個人メールアドレスで作られていたり、2段階認証のコードが個人のスマートフォンに届く設定になっていたりするケースは珍しくありません。SALの解説記事も、退職前に企業アドレス・企業デバイスへ切り替えておくことを必須のチェックポイントに挙げ、これを忘れると退職後にログインできない・認証コードが届かないという事故が起きると指摘しています。

そしてパスワードそのものを共有して運用するのも、事故の温床です。Metaのビジネス向け管理では、アカウントの認証情報を直接渡すのではなく、ビジネスポートフォリオ（Meta Business Suite）を通じて人ごとに役割を割り当てる方式が基本になっています。役割には管理者・編集者・アナリストといった段階があり、必要な範囲だけを渡せます。パスワードの共有はセキュリティ上のリスクに加え、退任時の権限剥奪が難しくなるという実務上の問題も抱えます。

設計の原則は最小権限です。分析だけ見る人にはアナリスト、投稿を作る人には編集者、鍵を持つ管理者は2名以上かつ社内の恒久的なアカウントに限定する。管理者を1人にすると、その人が使えなくなった瞬間に誰も入れなくなるので、必ず複数にしておきます。あわせて、退任時に権限を外す作業を入退社フローに組み込んでおくと、外し忘れを防げます。

自社の属人化度をはかる7つの質問

手を打つ前に、いま自社がどれだけ属人化しているかを把握します。以下の質問に「はい」と答えられない項目が、そのまま優先課題になります。特に権限に関する項目に「いいえ」が付く場合は、他を後回しにしてでも先に手当てしてください。

• SNSアカウントは会社所有のメールアドレスで登録されているか
• 2段階認証のコードは会社が管理する端末・アカウントで受け取れるか
• 管理者権限を持つ人が社内に2名以上いるか
• 投稿のトンマナが、良い例と避けた例の実例つきで文書化されているか
• 投稿を見送った判断の理由が、どこかに記録として残っているか
• 担当者以外の人が、明日から1本投稿を作って公開できる状態か
• 月次の数字の見方（どの指標をどう解釈するか）が共有されているか

7つのうち5つ以上に「はい」と答えられれば、引き継ぎは1か月程度の並行運用で回せます。3つ以下なら、引き継ぎ以前に運用の可視化から始める必要がある状態です。この診断は担当者本人にやらせるより、担当者以外が担当者に聞き取る形で実施すると、思い込みが混じりにくくなります。

引き継ぎドキュメントに書くべき項目

引き継ぎドキュメントは、章立てを先に固めてしまうのが早道です。ガイアックスのマニュアル解説が挙げる項目を軸に、判断の層を足したのが次の構成です。重要なのは「抜けたときに何が起きるか」を意識して優先度を付けることで、全項目を同じ熱量で書こうとすると必ず途中で力尽きます。

項目	書く中身	抜けたときに起きること
アカウント情報	登録メール、管理者一覧、権限の割り当て、2段階認証の受け取り先	退職後にログインできず運用が完全停止する
トンマナ	文体・一人称・絵文字・NG表現、良い例と避けた例の実例	読者が違和感を持ち、ブランドの一貫性が崩れる
投稿フロー	企画から公開までの手順、使用ツール、承認者、ダブルチェックの担当	公開前チェックが機能せず誤投稿のリスクが上がる
判断基準	見送りの理由、コメント対応の方針、炎上時の連絡経路	後任が同じ失敗を踏み直し、対応が遅れる
指標の見方	追う指標、目安値、月次レポートの型と報告先	数字を見ても打ち手が決まらず、施策が止まる
関係者	社内の確認先、外部の制作・代行先、素材の保管場所	素材や履歴が辿れず、制作をゼロからやり直す

この表のうち、最初の1行だけはドキュメントに書かずに別管理するのが安全です。認証情報を平文でドキュメントに書き込むと、そのファイルが共有された範囲すべてに鍵が広がります。アカウント情報は「どこに保管されているか」だけをドキュメントに書き、実体はパスワード管理ツールなどで権限を絞って保管する形にしてください。

トンマナを生成AIで言語化して再現する手順

暗黙知の言語化は、生成AIが最も役に立つ領域のひとつです。担当者に「トンマナを説明してください」と頼んでも出てこないものが、過去投稿という実データから逆算すると輪郭を持ちます。手順は4段階です。

抽出のプロンプトは、出力形式まで指定すると使いやすくなります。次のような依頼にすると、そのまま資料の骨組みになります。

あなたはBtoB企業のSNS運用ディレクターです。
以下は当社アカウントの過去投稿です（反応の良否をラベル付けしています）。
1. 文体・語尾・一人称・呼称・絵文字・改行の共通パターンを、評価を交えず事実として列挙してください。
2. 反応が良い投稿群と伸びなかった投稿群で、表現上の差異を比較してください。
3. 上記から「守るべきルール候補」と「意図か偶然か判断がつかない点」を分けて出力してください。
4. 3の判断がつかない点は、担当者に確認する質問文の形で書いてください。
---
（ここに投稿本文を貼り付け）

注意点は、AIの出力をそのままルールにしないことです。AIは過去投稿の統計的な傾向を読んでいるだけで、事業上どの表現を守るべきかは分かりません。意図と偶然の仕分けは、必ず担当者本人に確認する——この一手間を省くと、たまたま続いていた癖がルールとして固定され、後任がそれに縛られます。

アカウント権限の設計：最小権限で役割を割る

権限設計の出発点は、運用に関わる人を役割で分けることです。実務では「鍵を持つ人」「投稿を作る人」「投稿を承認する人」「数字を見る人」「外部の制作パートナー」の5種類に整理すると、多くの体制に当てはまります。プラットフォーム側の権限区分（管理者・編集者・アナリストなど）をこの役割にマッピングし、それ以上は渡しません。

• 鍵を持つ管理者は社内の恒久アカウントで2名以上。個人名だけに紐づけない
• 投稿作成担当には編集権限まで。アカウント設定や権限付与はできない状態にする
• 外部パートナーには期間と範囲を限定した権限を付与し、契約終了時に外す手順を決めておく
• 数字だけ見たい関係者には閲覧・分析権限のみを渡す

役割を割る作業は、実際にやってみると想像より細かい判断を伴います。たとえば「投稿は作るが公開はしない人」に編集権限を渡すと、設定上は公開もできてしまうプラットフォームがあります。この場合は権限で止めるのではなく、予約投稿ツール側の承認機能や運用ルールで止めるという二段構えになります。逆に、分析だけ見たい上位者に管理者権限を渡してしまうケースも多いのですが、これは権限の棚卸しを難しくする典型例です。権限は年に一度でよいので一覧を出して、いま実際に使っている人だけが残っている状態か確認してください。

運用委託をしている場合は、アカウントの所有と管理を分離しておく意識が重要です。玉川法律事務所は、SNS運用業者と委託者の間でアカウントの管理権限の帰属が争われた事例を紹介しています。委託先がアカウントを作成・管理していると、契約終了時に権限の引き渡しでもめる余地が生まれます。アカウントは自社で開設し、権限を貸す形にするのが、後々のトラブルを避ける基本形です。

認証情報の移行：退職前に終わらせる作業

権限設計が決まったら、実際の移行作業に落とします。ここは退職日直前になると必ず慌てるので、退職の申し出があった時点で着手するタスクとして扱ってください。順番を間違えるとログインできなくなる作業もあるため、1つずつ確認しながら進めます。

1. 登録メールアドレスを個人アドレスから会社の共有アドレスに変更する
2. 2段階認証の受け取り先を、会社が管理する端末や認証アプリに切り替える
3. バックアップコード・リカバリーコードを発行し、権限を絞った場所に保管する
4. 管理者権限を後任および恒久アカウントに付与し、2名以上の体制にする
5. 退職者の権限を削除し、削除後に実際にログインできないことを確認する
6. 外部ツール（予約投稿・分析・画像編集など）の契約者とログインも同様に移す
7. 素材ライブラリ・過去投稿データ・外部連絡先の保管場所を共有ドライブへ移す

最後の項目を見落としがちですが、SALの解説記事も情報資産の散失を退職時のリスクに挙げています。ツールのログイン情報、外部協力者との連絡履歴、撮影素材が個人の端末やアカウントに残っていると、後任は制作をゼロからやり直すことになります。移行が終わったら、退職者のアカウントで実際にログインできないことを確認する——この最終確認まで含めて1つのタスクです。

複数人運用の投稿承認フローをどう組むか

属人化を防ぐ最も確実な方法は、日常の運用を2人以上で回すことです。ただし承認者を増やすほど公開までの時間は伸びます。実務では投稿の種類ごとに承認の重さを変える設計が現実的です。定常的な告知や記事紹介は作成者と1名のチェックで公開、社会情勢に触れる内容や数字を含む発表は責任者の承認を必須にする、といった段階を作ります。

チェックする観点も先に決めておきます。事実関係（数字・日付・固有名詞）、権利（画像の出典、引用の範囲）、表現（NG表現、誤解を招く言い回し）、リンク（遷移先の確認）の4点を必ず見る、という形です。誰が見るかではなく、何を見るかを固定するほうが、チェックの質が人に依存しません。ガイアックスのマニュアル解説も、企画立案者と承認者を明記し、投稿前のダブルチェック体制を整えることを項目に挙げています。

承認フローが重くなりすぎて形骸化するのは、よくある失敗です。目安として、定常投稿の公開までが1営業日以内に収まる設計にしてください。それより時間がかかるなら、承認の段数を減らすか、事前に承認済みのテンプレートを用意して個別承認を省く方向に組み替えます。時間がかかるフローは、必ず「急ぎなので今回だけ」という抜け道を生みます。

体制の選択肢を比較する：後任採用・運用代行・常駐支援

担当者が抜けたあとの体制には、いくつかの選択肢があります。SALの解説記事は、後任採用・運用代行・常駐支援の3つを軸に、立ち上がりまでの期間と費用感を整理しています。以下は同記事で示された目安を要約したもので、市場相場は時期や地域で動くため、あくまで検討の出発点として扱ってください。

選択肢	立ち上がりの目安	費用感の目安	向くケース
後任を採用する	採用に3〜6か月	年収550〜800万円の水準	SNSを主要チャネルと位置づけ、採用力がある企業
運用代行に出す	即時から対応可能	月10万円〜数十万円	SNSが補助的な役割で、社内リソースが薄い企業
常駐・支援型	1〜2か月で立ち上げ	月40万円〜（最低契約期間あり）	複数事業・複数アカウントを抱える中堅以上の企業

どれを選んでも、判断の層を社内に残す仕組みは必要です。運用代行に出せば作業は回りますが、事業のKPIとSNSをどう接続するか、炎上リスクをどこで止めるかという判断は社内に残ります。SALの解説記事も、AIや外部に任せられる領域と、事業KPIとの接続・社内の合意形成・炎上の未然防止といった人が握るべき領域を分けて示しています。成果の見え方についても、投稿運用の安定とKPI改善が見え始めるのは3〜4か月目という目安が示されており、体制を変えた直後の数字だけで判断しない姿勢が必要です。

引き継ぎのスケジュール設計：並行運用の1か月

引き継ぎの成否を分けるのは、資料の完成度よりもスケジュールです。SALの解説記事は、退職予定日の1か月前から新体制と並行運用する期間を設けることを推奨しています。文書だけを渡す引き継ぎと違い、在籍中に判断基準を見せながら渡せる点が大きな違いです。

並行運用期間の使い方には型があります。1週目は後任が見学し、担当者の判断を実況してもらう。2週目は後任が作り、担当者が添削する。3週目は後任が作って公開まで進め、担当者は事後に講評する。4週目は後任が単独で回し、担当者は質問対応だけに徹する。この4段階で権限と責任を移すと、切り替えの日にいきなり止まる事態を避けられます。

• 並行運用の1か月は、担当者の通常業務を減らして時間を確保する。片手間では引き継ぎに時間が回らない
• 後任が単独で回す週に、あえて判断が必要な場面（否定的なコメント対応など）を経験させておく
• 退職後1か月は元担当者に質問できる経路を残せるとよいが、契約上難しい場合は質問想定集を先に作っておく

よくある失敗：引き継いだ直後に数字が落ちる

引き継ぎ自体は終わったのに、その後2〜3か月で数字が落ちていく——これも典型的なパターンです。原因はおおむね次のどれかに当てはまります。

• 投稿の頻度が下がる。後任が他業務と兼任になり、本業に押されて更新が止まりがちになる
• 無難な投稿ばかりになる。判断基準がないため、後任がリスクを取れず当たり障りのない内容に寄る
• コメントやDMへの反応が遅れる。誰が一次対応するかが決まっておらず、放置される
• 指標の見方が変わり、前任時代との比較ができなくなる。改善の判断材料が途切れる
• トンマナが少しずつずれ、フォロワーが「別のアカウントのよう」と感じて反応が薄くなる

最初の項目は特に注意が必要です。SALの解説記事も、後任不在のまま他部署が兼任すると本業に押されて投稿頻度が下がり、反応が静かに削れていくと指摘しています。対策は、引き継ぎと同時に投稿本数の目標を現実的な水準へ引き下げることです。前任者が週5本回していたなら、後任の稼働に合わせて週2〜3本に設計し直す。無理な本数を維持しようとして途中で完全停止するより、落ちた水準で続けるほうが回復は早くなります。

AIに任せる範囲と人が握る範囲

生成AIは属人化対策の道具として有効ですが、任せられる範囲には線があります。SALの解説記事は、投稿テキストの初稿生成・素材の調整・配信タイミングの最適化・パフォーマンス分析をAIが補完できる領域として挙げ、一方で事業KPIとSNSの接続判断・社内の合意形成・炎上の未然防止・ブランドガイドラインの最終判断は人が担う領域だと整理しています。

実務に落とすと、AIの役割は「量を作る」と「型を可視化する」の2つです。投稿の初稿を複数パターン出させて選ぶ、過去投稿からトンマナのルール候補を抽出する、月次の数字から気づきの候補を並べる。いずれも人の作業を置き換えるのではなく、人が判断する材料を増やす使い方です。AIは判断の材料を増やす道具で、判断そのものの代わりにはならないという前提を共有しておくと、期待値がずれません。

そして、AIを使うこと自体が属人化を招く場合もあります。特定の担当者だけが自分用のプロンプトを蓄積していると、その人が抜けたときにプロンプトも消えます。使っているプロンプトは共有の場所に保管し、誰が使っても同じ出力の傾向が得られる状態にする——AIの使い方まで含めて引き継ぎ対象と考えてください。

よくある質問

担当者が1人しかいない場合、どこから手を付ければよいですか？

権限の層からです。会社所有のメールアドレスへの変更、2段階認証の受け取り先の会社側への移行、管理者の複数化——この3つは担当者が1人でも実施でき、しかも実施しないと最悪の事態（アカウントに誰も入れない）を招きます。トンマナや判断ログの整備は時間がかかるため、権限を固めたあとに少しずつ進めるのが現実的です。

引き継ぎ資料はどのくらいの分量が適切ですか？

分量より更新されるかどうかが重要です。100ページの完璧な資料が半年後に古くなって誰も見ないより、10ページでも月次で更新される資料のほうが機能します。目安としては、後任が最初の1本を公開するまでに読み切れる分量にとどめ、詳細は判断ログや実例集として別に積み上げていく形をおすすめします。

運用代行に出せば属人化は解消されますか？

作業の属人化は解消されますが、判断の属人化は残ります。むしろ代行先の担当者に判断が集中すると、代行先の担当交代でも同じ問題が起きます。委託する場合も、アカウントは自社で開設して権限を貸す形にし、トンマナと判断基準を自社側の文書として持っておくことが、社外に依存しすぎない体制の条件になります。

まとめ

SNS運用の属人化は、担当者の能力の問題ではなく、判断の理由が記録されない仕組みの問題です。表現・判断・権限の3層に分けると、手当ての順番が見えます。まずは権限——会社所有のアドレスへの変更、2段階認証の会社側への移行、管理者の複数化。次に判断——見送りの理由を1行で残す習慣と、迷ったときの優先順位。最後に表現——良い例と避けた例の実例集としてのトンマナ資料です。引き継ぎは資料の完成度よりスケジュールで決まり、退職1か月前からの並行運用が効きます。生成AIは過去投稿から言語化のたたき台を作る道具として有効ですが、意図と偶然の仕分けは担当者本人にしかできません。引き継げる体制とは、誰かが抜けても判断が続く状態のことです。7つの質問で自社の現状を測るところから始めてください。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。