社内の匿名投稿、削除の判断は誰がすべきか——「運営に任せる」がB2Bで危ういわけ

「運営がまとめて対応します」の落とし穴

匿名投稿サービスの多くは、通報対応や削除をベンダー側で引き受けます。導入企業から見れば手間が減って楽です。

ですが、これは裏を返すと「ベンダーの担当者が、御社の投稿を日常的に読んでいる」ということです。削除の是非を判断するには、中身を読まなければなりません。

社員の生々しい業務の話、組織の内情、人間関係の相談。それを、契約先とはいえ社外の人間が恒常的に閲覧している。B2Bのサービスとして、これはなかなか受け入れがたい構図です。

運営は「読まない」に徹する

Furattoは、この点で設計思想を変えています。モデレーション（通報対応・削除・非表示）は、導入企業の管理者／モデレーターが担います。運営は関与しません。

運営はインフラの提供に徹し、通常の運用で投稿本文を閲覧しません。技術的にはデータにアクセスし得ますが、障害対応などでやむを得ず投稿データを見るときは、組織ごとに理由を宣言して記録が残る専用の経路を使います。その記録は開示のご依頼に応じて提供します。運営が運営用のロールでデータベースへ直接つなぐ読み取り・書き込みも、ログに残します（記録の対象外の範囲は、セキュリティ方針に書いています）。「運営だから何でも見られる」という状態を、意図的に避けています。

管理者は「消せる」が「特定できない」

では管理者に権限を渡すと、匿名性が崩れるのでは——という懸念が出ます。ここが設計の肝です。

• 管理者は、投稿を削除・非表示にできます。危険な投稿に自社の判断で対処するために必要な権限です
• しかし管理者の画面には、投稿者が誰かは表示されません。投稿と投稿者の紐付けは分離テーブルに隔離されており、管理者が読める設定にしていないためです
• 他人の投稿本文を管理者が書き換えることもしません。改変で匿名者の主張がねじ曲がるためで、画面から編集できるのは本人だけです

「消す権限」と「特定する権限」を切り離す。これによって、危険な投稿には対処できるのに、報復のために書き手を割り出すことはできない、という状態を作っています。

削除は最終手段、原則は修正と対話

削除ありきの運用も避けています。基本の流れはこうです。

• 通報が入っただけでは、表示は変えず、投稿者にも通知しません（サイレントに管理者のキューへ入るだけ）
• 管理者が実際に非表示・削除した時、または正式対応に進めた時に、投稿者へ理由つきで通知が届きます
• 投稿者は「修正する／削除する／異議あり」から選べます。原則は削除ではなく修正です

「通報中」といったラベルは表示しません。通報されている事実が見えるだけで書き手への圧力になり、通報が攻撃の手段に転じるからです。

正直な注意点

この設計は「運営が守ってくれる」モデルではありません。削除の判断は自社で行う必要があります。その分、判断のたびに理由を記録する運用が求められますが、その記録がそのまま自社のモデレーション方針の原案になります。

また、組ませないルールと同じで、削除が多発する状況は、ツールではなく職場側の課題を示しているかもしれません。件数を全社に公開しているのは、その健全性を組織自身が見られるようにするためでもあります。