結論: AIに連絡を任せる前に決めるのは、文面ではなく「発言の名義」です
AIに社内連絡を任せるとき、最初に決めるべきなのは文面の丁寧さではありません。そのメッセージが誰の名前で届くかです。私たちはこれを「発言の名義」と呼んでいます。
私たちの失敗は、Slackの自動通知をすべて代表者本人のアカウントから投稿していたことでした。仕組みの都合でそうなっていた、というだけの理由です。人が書いた依頼と、AIが集計した報告が、同じ名前・同じ見た目で並ぶ。受け手には区別がつきません。
文面をどれだけ整えても、この1点を直さない限り誤解は消えませんでした。名義は文面の後回しにできる装飾ではなく、連絡の一番外側の設計です。
AIが人の名前で連絡すると、何が起きるのか？
答えを先に言うと、受け手が内容ではなく発信者を見て反応するようになります。理由はシンプルで、社内の連絡は「誰が言っているか」で優先順位が決まるからです。
私たちの職場で実際に起きたのは3つです。1つ目は、急ぎでない定期集計に人が反応してしまうこと。代表の名前で届いた以上、放置しにくい。2つ目は、機械の報告に対して人への返信と同じ丁寧さの返事が返ってくること。3つ目が最も重く、後から**「この判断は誰がしたのか」を追えなくなる**ことでした。AIが自動で出した確認も、人が考えて出した指示も、記録上は同じ人の発言として残ります。
名義を分けたところ、この3つは同時に消えました。文面は1文字も変えていません。
定型の通知を直したのに、なぜ同じ問題が再発したのか？
私たちは2026年6月に、20本ほどの定期通知をまとめてAI専用の名義へ移しました。これで解決したつもりでいました。
ところが7月末、AIが社内メンバーへ1件の質問を送る場面で、また本人の名義に戻っていました。経費の用途を尋ねるだけの短い連絡です。受け手からは代表本人が個別に聞いているように見えます。すぐに是正しましたが、原因を確かめると設計の抜けでした。名義を移したのは「定期通知」という経路だけで、AIがその場で人に話しかける場面が対象から漏れていたのです。
ここで分かったのは、名義は経路ではなく話し手に付くということです。決まった時刻に流れる報告も、その場の1回きりの質問も、AIが口を開いているという点では同じ。私たちは対象を「AIが送るすべてのメッセージ」に引き直しました。
名義はいくつ用意すればいいのか？
私たちが用意しているのは2つです。社内向けと、外部の協力者向け。理由は、受け手が違えば「この通知を止めたい」ときの問い合わせ先も違うからです。同じAIでも、社外の方から見れば会社からの連絡であり、社内の運用担当に直接届いてほしくない相談もあります。
もう1つ、決めたのに実施しなかったことがあります。「これは自動送信です」という説明の1行を本文に付けるかどうか。検討して、付けないことにしました。名義を見れば人か機械かは一目で分かるのに、全通知に1行増えると読まれる率が下がる——通知は短く薄いほど読まれるという設計を、ここでも優先しました。
人の名前のまま残す連絡は何か？
すべてをAI名義にするわけではありません。私たちが人の名義のまま残しているのは、次の3つです。
対外的な意思表示と承認、クライアントへの返信、そして金銭や公開が絡む実行。これらはAIが下書きまでを担当し、人が読んで自分の名前で出します。会社としての意思を、機械の名前で表明させないためです。
誤解のないように書くと、私たちも承認の入口はSlackに置いています。ただし確定の操作は人が管理画面で実行しています。絵文字だけで承認を回す仕組みを運用していても、後戻りできない操作までワンタッチにはしていません。名義を分ける目的は自動化の範囲を広げることではなく、誰の判断かを残すことだからです。
明日からできる最初の一歩
自分のSlackを開き、直近1週間で自分の名前で送信されたメッセージを上から見てみてください。その中に、自分が書いていないもの——仕組みやAIが自動で出したものが混ざっていないかを確認します。
1件でも見つかれば、まずその1本だけを専用の名義に移すところから始められます。全部を一度に移す必要はありません。私たちも定期通知から始めて、個別の質問まで手が届いたのは1ヶ月半後でした。見落としは、道具の表示ルールが作る死角と同じで、気をつけるだけでは消えません。対象の範囲を紙に書き出すところまでやって、ようやく塞がります。