結論: Slackの連絡は、宛先ごとにAIの動きを決めて任せます
「あの資料はどこですか」「これを確認してもらえますか」。社内のこうした確認や連絡は、気づくと代表に集まります。1つずつは短い仕事でも、会話を探して調べて返事をしていると、進めたい仕事がそのたびに止まります。
弊社では、連絡が誰に向けたものかで、AIの動きを変えています。 代表宛ての質問には、調べて回答案を作ります。スタッフからAIへの依頼には、許可した範囲で作業して結果を返します。編集者の提出の連絡には、進行管理表の更新で応えます。
この記事では、3つの動きと、それぞれの止める線、AIが質問を返してきた実例、明日試せる一歩を順に書きます。
代表宛ての質問には、AIは何をするのか？
答えを先に言うと、調べれば答えられる質問だけを調べ、回答案を代表に渡します。資料の場所や、提出が済んだかどうか。人が判断しなくても、保存したファイルや予定、管理表を見れば分かる質問があります。
弊社のAIは、午前10時から夜8時まで1時間ごとにSlackを確認します。代表宛てのメンションで、こうした質問を見つけたら、調査と返信案づくりに進みます。分かった事実と返信案は、代表向けのチャンネルに届きます。質問した人へ送るかどうかは、代表が決めます。 何かの許可を求める質問は、代表が判断するため、対象に入れていません。
仮の材料で試しました。渡したのは、研修の案内と旅費のルールだけです。この資料だけを根拠に短い返信案を作り、見た資料を添え、書かれていないことは確認事項に残すよう頼みました。返ってきた案には、集合時刻、場所、持ち物が出典付きで並びました。前日に移動する場合の宿泊費を会社が負担してよいかという質問も入れてあり、こちらは「社長の事前承認が必要」と書かれたルールに沿って、確認事項に残りました。
調べて分かることと、新しく判断することは、同じ質問の中でも分けられます。
スタッフからAIへの依頼は、どこまで任せるのか？
答えを先に言うと、許可した種類の作業だけを、承認を待たずに進めさせます。AIを使うのが代表だけだと、スタッフに頼まれたことを代表がAIに伝え直すことになります。それを避けるため、スタッフがSlackでAIを呼び出して、直接頼める形にしました。
発送に使う納品書とラベルを頼んで、同じ会話にPDFが返った例があります。追加の依頼にも、その場で応えていました。
動くのは、AI宛てのメンションがあり、調べる・集計する・書類を作るといった具体的な依頼で、許可した作業に当てはまるときだけです。AIの名前が会話に出ただけでは動きません。お金の支払いと、外部への公開は、自動で進めない設定です。
個人情報を使わず、研修の申し込み一覧の集計で試しました。頼んだのは、研修日ごとの集計です。キャンセルは除き、同じ申し込みIDの重複は1件と数え、日別の人数と合計、除いた理由を返してもらいます。渡した一覧は5行で、結果は1日目が2件、2日目が1件の合計3件でした。重複とキャンセルを除いた理由も返ってきました。
進行管理表の更新は、どこまで任せるのか？
答えを先に言うと、提出の連絡で止めず、その後の返事まで読ませたうえで、工程を動かさせます。誰が何を出して、いまどの確認待ちなのか。連絡はSlackにあるのに、管理表が古いままになりがちです。
弊社のAIは、編集チームのSlackを午前10時ごろと夕方6時ごろの2回確認します。編集者の提出、確認担当の修正依頼や確認完了といった新しい連絡を見つけると、Notion（資料や一覧をまとめて置けるツール）の進行管理表を更新します。同じ「提出」でも、その後の返信や、誰が確認したかまで見て、次の工程を決めます。
仮の会話で試しました。修正を頼まれた案件は「編集・修正中」に、確認担当から修正なしと返事が来た案件は「次の設定待ち」に分かれました。
ここで弊社の渡し方の不足も見つかりました。もう1件、編集者が「修正しました。確認お願いします」と送った案件です。渡したルールには、最初の提出の扱いしか書いていませんでした。AIは勝手に決めず、「修正後の再提出も、確認待ちにしてよいか」と質問を返してきました。 そこで「修正後の再提出も確認待ちにする」とルールに足して、もう一度試しました。今度は、その案件も確認待ちの更新案になりました。
人なら分かるだろうと省いたことは、AIには伝わっていません。質問が戻ってきたら、次から同じ場面で迷わないように、ルールを足しています。成果物が良いか、公開してよいかは、人が確認します。その判断がSlackに書かれたあとの、案件を探して管理表を書き換える作業を、AIに任せています。
動かす条件は、どう決めているのか？
答えを先に言うと、「決めた時間に確認を始め、誰に向けたどんな連絡かで次の動きを分ける」と決めています。仕事を始める条件を、トリガーと呼びます。
押さえている線が3つあります。1つ目は、連絡が届いた瞬間には動かないことです。次の定期確認で見つけてから処理するので、確認する時間と作業が終わる時間は同じではありません。2つ目は、Slackにつなぐだけでは、ここまでの流れは動かないことです。依頼を受け取る仕組み、使える資料、結果を返す場所まで組み合わせています。3つ目は、承認です。AIが用意した案と、承認後にやることがSlackに届き、代表が内容を見て、良ければ👍を付けます。承認を確認できたら、決めた処理に進みます。記事や投稿文の案を👍で承認したあとに、Notionの管理表の状態を「承認済み」へ進める運用が、その例です。自動にしているのは、承認の反映だけです。
もう1つ、毎日12時の照合があります。昨日までのイベントの予定と、収支の入力記録を並べ、予定があるのに入力がない日を、経理用のチャンネルに知らせます。練習のように報告が要らない予定は、AIが予定の中身を読んで外します。仮の材料では、報告のないイベント1件だけが通知案に残りました。入力済みの記録を足して試すと「通知不要」になりました。AIに売上を想像して埋めさせるのではなく、何の入力が残っているかを知らせさせる使い方です。
明日から試せる一歩
最初に、仕事を1つだけ選びます。毎回自分で探したり、確認したりしている仕事が向いています。弊社の最初の例は、対応が残っている仕事の確認でした。
社内の機密情報は使わず、練習用の短い会話を3つ、いま使っているAIに貼ります。次の文で頼んでみてください。
「次の会話から、私の対応が残っている仕事と期限を一覧にしてください。最新の返信まで読んで、終わった仕事は外してください。期限が書かれていないものは「未定」と書いてください。」
結果が合っていたら、読む会話と、結果を返す場所を決めます。そのうえで、毎日何時に動かすかを決めて、定期実行に登録します。登録したあとに見るのは、次の実行時刻に、自分から頼まなくても結果が届いたかどうかです。同じ依頼を二重に処理していないか、いらない通知が増えていないかも、あわせて見てください。
Slackの未読を先に読むAIの置き方は読む役と作業する役を分ける記事にあります。
