Slack AIエージェントの導入｜PoCで選ぶ5業務
目次
はじめに
「SlackにAIを入れた。せっかくだから、問い合わせ対応を全部任せよう」
この始め方は、勢いがあって魅力的に見える。ところが、問い合わせには単純な質問もあれば、契約や個人情報に触れる相談も混ざる。ひとつの窓口として扱うと、AIが判断してよい境界がすぐに曖昧になる。
SlackでAIエージェントを導入する方法を考えるとき、最初に決めたいのはモデルや接続方式ではない。どの業務なら、小さな権限で、間違いを見つけながら価値を測れるかである。
Slack公式のエージェント概要は、エージェントを「定められた境界の中で自律的に動く存在」と説明している。読み取り、書き込み、外部処理では影響が違う。メール送信やレコード更新など、業務上の結果を確 定させる操作には明示的な人の確認が必要だとも示している。
だからPoCでは、Slackを依頼と成果確認の入口にする。裏側のエージェントには必要最小限のツールだけを渡す。この分離ができると、「便利そうなデモ」から「運用できる仕組み」へ進みやすい。全体像はSlack AIエージェント基盤の全体設計でも整理している。
PoC候補を選ぶ5つの採点軸
候補業務を感覚で決めると、声の大きい部署の要望が残りやすい。そこで、各項目を0〜2点で採点する。ここで紹介する配点は、候補を比較するための初期仮説の例だ。誤りの影響が大きい業務では可逆性と権限を2倍にするなど、自社の条件に合わせて重みを変える。
10点満点なら、たとえば7点以上を検証候補にする。ただし、合計点だけで採用しない。可逆性か権限が0点なら、読み取りと下書きだけに業務を分割して採点し直す。この例外ルールを先に置く。
1. 発生頻度
PoC期間中に、通常例と例外例を含む十分なケースを集められるなら2点、一部だけなら1点、ほとんど発生しないなら0点とする。固定の件数より、評価に必要な種類が揃うかを見る。
ここで見るのは担当者の忙しさではなく、同じ判断を繰り返す回数だ。月末だけ大量に発生する作業なら、PoC期間を月末に合わせる。カレンダーと切り離して考えない。
2. 失敗の可逆性
下書きを捨てれば戻せるなら2点、履歴から復元できるなら1点、送金・削除・外部公開のように戻せないなら0点だ。PoCでは2点の業務を優先する。
Slack公式のAgent designでも、作成・送信・削除などの操作は、実行前に内容を見せて確認を求める設計が推奨されている。確認ボタンを付けただけで安全になるわけではない。承認者が判断できるよう、対象、差分、根拠、実行後の影響を同じ画面に出す必要がある。
3. 正解を確認できるか
既存の手順書や正答例と比較できるなら2点、担当者なら判断できるなら1点、結果が数か月後まで分からないなら0点とする。
AIの回答が自然でも、正しいとは限らない。たとえば社内規程への質問なら、回答文ではなく参照した規程の版と該当箇所を確認する。評価単位を「文章の上手さ」から「根拠まで合っているか」へ変える。
4. 必要な権限
公開チャンネルや検証用データの読み取りだけなら2点、限定された社内データへの読み取りなら1点、全社データの閲覧や更新が必要なら0点だ。
Slackは、呼び出した人が見られない情報をエージェントも使うべきではないとしている。PoC用のBotに管理者権限を渡すのは近道ではない。検証対象のチャンネル、参照先、実行できる操作を個別に許可する。詳しい分け方はSlack AIエージェントの権限設計をあわせて確認してほしい。
5. 効果を数字で測れるか
作業時間、一次回答までの時間、提案採用率などを取れるなら2点、アンケートだけなら1点、成功の定義がないなら0点とする。
「便利だった」は悪い感想ではない。だが、継続投資の判断には弱い。導入前後で同じテストケースを使い、1件当たりの作業時間は中央値で比べる。削減時間だけでなく、人が修正した割合と重大な誤りも残す。
PoCに向く5つの業務
採点軸を使うと、SlackのAIエージェントに向く仕事を同じ物差しで比べられる。次は、社内規程を参照できる検証チャンネルがあり、外部送信をしないという前提での記入例だ。点数はそのまま転用せず、 自社の権限とデータで付け直してほしい。
1. 問い合わせの分類と担当候補の提示
質問を分類し、担当候補と根拠を元スレッドへ返す。転送は人が行う。頻度2、可逆性2、正解確認2、権限2、効果測定2の10点という例になる。人事・法務・セキュリティの投稿は対象外にする。
2. 社内情報を探した回答下書き
現行の規程とFAQだけを検索し、回答案と参照箇所を返す。送信は担当者が行う。版管理ができていれば8点、文書の新旧が混在するなら正解確認を0点に下げ、先に情報を整理する。
3. 会議スレッドのアクション整理
担当者、期限、作業、未決事項を抽出する。タスク登録はしない。担当が書かれていない場合は「未定」と返せることを受入条件にする。測るのは抽出漏れと修正時間だ。
4. 定型レポートの下書き
障害件数や期限超過を読み取り、元データへのリンク付きで整える。取得件数と時刻も表示する。集計値の一致率を確認できる一方、参照先が多いほど権限の点は下がる。
5. 申請内容の事前点検
必須項目、添付、記載矛盾を確認する。決裁は人が行う。可逆性は高いが、個人情報を含むなら権限を0点にして、マスキング済みの検証データへ切り替える。差し戻し率と確認往復回数で効果を測る。
より広い候補例はAIエージェントを小さく始める選び方に譲る。ここでの狙いは、候補を増やすことではない。同じ採点軸から、検収できる仕様を作ることだ。
PoCで避けたい3つの業務
1. 会社や個人への影響が大きい判断
送金、契約締結、採用可否などが該当する。AIは資料整理や論点抽出までに留める。
2. 元に戻せない更新
データ削除、外部公開、顧客への自動送信が該当する。検証環境とダミーデータを使い、実データへの書き込みは次段階へ送る。
3. 正解を説明できない評価
「良い提案を作る」のような依頼は評価がぶれる。対象顧客、守る条件、含める項目、採用基準へ分解してから試す。
Slackのガバナンス指針は、人による関与、操作の可視化、取り消しやすさ、段階的な信頼を重視している。PoCの段階で大きな権限を渡すのではなく、結果を確かめながら読み取りから下書き、承認付き実行へ広げる考え方が合う。
2週間で価値を測るPoC設計
期間を2週間に区切るなら、初日に次の6点を一枚にする。2週間は、日次で対象業務が発生する場合の例だ。月次業務なら締め日をまたぐ期間へ延ばす。
- 対象業務と対象外の業務
- 読み取れるチャンネルとデータ
- 出力形式と、出力を確認する担当者
- 通常、境界、例外を含むテストケース
- 成功指標と許容できない誤り
- 即時停止する条件
3日目には通常例、境界例、例外例を少なくとも1件ずつ通す。ここで精度を上げるより、権限外の情報を読まないか、根拠がないときに止まれるかを見る。中間日は結果を確認し、入力データや業務ルールの不足を直す。最終日は同一条件のテスト結果を集計し、継続、対象縮小、停止のどれかを決める。
重大な誤りは平均点に埋めない。個人情報の露出、誤送信、権限外データの参照が1件でも起きたら停止する。一方、表現の修正は提案採用率や修正時間として扱う。異なる重さの失敗を分けると、意思決定がぶれにくい。
書き込みを試す段階では、承認依頼に実行内容と差分を表示する。Slack AIエージェントの承認設計で扱ったように、承認の有効期限、再実行時の再承認、代理承認の範囲も仕様にする。単なるリアクションを承認として扱うのは避けたい。
採点結果を5つの検収成果物へ変える
PoCが終わっても、採点表だけでは開発や運用へ引き渡せない。発注者、SIer、運用担当が同じ結果を確認できるよう、次の5つを残す。
1. 対象業務定義書
開始条件、入力、判断、出力、終了条件、対象外を1ページで書く。「問い合わせ対応」では広すぎる。「製品FAQチャンネルで、既存4分類の担当候補を提示する」まで絞る。発注者は対象範囲を承認し、SIerは実装可能性を確認する。
2. 権限表
Slackのチャンネル、参照文書、外部システム、操作を行に並べ、読み取り、下書き、書き込みを分ける。運用担当は付与と剥奪を担い、SIerはエージェントが表の外へ出ないことをテストする。
3. テストケース一覧
通常例 だけでなく、情報不足、権限外、古い文書、矛盾した指示を含める。各ケースに期待する出力と「止まるべき条件」を書く。発注者が期待結果を決め、SIerが実行ログとひも付ける。
4. 重大度別の受入基準
表現の修正は軽微、担当候補の誤りは中程度、個人情報の露出や誤送信は重大と分ける。平均正答率だけで合格にしない。重大な誤りは1件で停止、軽微な修正は中央値で比較する、といった判定規則を合意する。
5. Go／No-Go判定書
対象ケース数、提案採用率、1件当たりの修正時間、重大度別の誤り、未解決課題を記録する。権限を広げる場合は、追加する操作と新しい停止条件も書く。意思決定者が継続可否を承認し、運用担当が次回レビュー日を持つ。
この5成果物があれば、仕様と証跡で判断できる。No-Goでも、版管理不足や責任者不在が見えたなら、次に直す課題は特定できている。
SlackでAIエージェントを導入するなら、派手な自動化から始めなくてよい。候補業務を同じ軸で採点し、読み取りと下書きから試す。結果を5つの検収成果物へ変えれば、次に広げる権限を説明できる。
Atsumellでは、AI業務整理ツール「Kakusill」を使い、 対象業務の整理から、入力・判断・出力・権限・停止条件の仕様化、実行基盤の設計まで支援している。Slack上のPoCを「動いた」で終わらせず、運用できる形へ進めたいときは、お問い合わせから相談してほしい。
