Slack AI エージェントは権限設計から
目次
SlackにAIエージェントを置くと、体験は一気に自然になる。いつものチャンネルで依頼できる。スレッドの文脈も渡せる。ファイルや会話の流れも近い。Slack AI エージェントへの期待が強い理由は、仕事の入口がすでにSlackに集まっているからだ。
ところが、便利さが先に立つほど危ない論点がある。誰の権限で情報を読むのか。どのチャンネルへ返してよいのか。外部サービスへ書き込む前に、誰が止めるのか。
SlackのAIエージェントは、単なるチャットBotではない。Slack公式ドキュメントでも、エージェントは会話の文脈を持ち、ツールを使い、外部システムを呼び出しながら処理を進める存在として説明されている。参考: AI in Slack overview
だから導入時に見るべき中心は、モデルの賢さだけではない。権限、出力先、承認、停止条件を先に設計する。ここを曖昧にしたまま「とりあえずSlackにAIを入れる」と、社内の便利ツールがそのまま情報漏えい装置になり得る。
Slack AI エージェントで最初に見るべき論点
現場でよく起きるズレは、AIエージェン トを「質問に答える係」として始めることだ。最初は要約や検索だけなので問題が小さく見える。少し使われ始めると、すぐに依頼は変わる。
「この議事録からタスクを作って」
「この問い合わせに返信案を出して」
「このGoogle Driveの資料を読んで、Slackに要点を書いて」
「CRMを見て次アクションを提案して」
ここまで来ると、AIエージェントは読む、考える、書く、通知する、下書きする、という複数の操作をまたぐ。SlackのDeveloping an agentでも、エージェントの処理は入力を受け、判断し、ツールを呼び、出力する流れとして整理されている。
この流れの中で危ないのは、読み取り時の権限と出力時の閲覧者が一致しないことだ。たとえば、代表や管理職の権限で取得した情報を、参加者の多いチャンネルへそのまま返す。本人は見られる情報でも、チャンネル全員が見てよいとは限らない。
SlackのAIエージェントを検討するときは、最初に次の4つを分ける。
- 誰の依頼として扱うか
- どの情報源を読んでよいか
- どの場所へ出力してよいか
- どの操作で人間承認を挟むか
この4つを決めずにプロンプトだけ整えても、業務導入では長く持たない。返答がうまいAIではなく、事故らず仕事を進めるAIにする必要がある。
普通のBot設計だけでは足りない
従来のSlack Botなら、イベントを受けて返信するだけでも価値があった。通知、FAQ、簡単なワークフローであれば、入力と出力の範囲が狭い。
AIエージェントは違う。文脈を読み、次の作業を推測し、複数のツールを呼ぶ。SlackはAgentforceやエンタープライズ検索との連携も打ち出しており、会話データや接続アプリの情報を使う体験が広がり始めている。参考: Slack AI Agents
Google CloudとSalesforceの発表でも、SlackやGoogle Workspaceをまたいで文脈を使い、資料作成や営業支援などの作業につなぐ方向が示されている。参考: Salesforce and Google Cloud Enable AI Agents to Act Across Both Platforms
こうなると、従来の「OAuthで許可したからOK」という考え方だけでは弱い。Oktaは、AIエージェントが共有ワークスペースへ出力するとき、取得時の権限だけでなく 、出力を見る相手の権限まで考えるべきだと指摘している。参考: AI security: authorization must follow the audience
実務では、次のような事故パターンが起きやすい。
- DMで読むべき内容をパブリックチャンネルへ要約してしまう
- 管理者だけが見られるファイルを、チャンネル参加者向けに説明してしまう
- 外部送信前の下書きと、実送信の境界が曖昧になる
- 「削除して」「反映して」「送って」のような短い依頼を、そのまま実行してしまう
- 参照した情報源と判断理由が残らず、後から検証できない
これはモデル性能の問題ではない。要件定義の問題だ。SlackのAIエージェントに何を任せるかを決める前に、どの操作を任せないかを決める必要がある。
実務で使える設計手順
導入設計は、機能一覧から始めないほうがよい。業務フローを、入力、判断、出力、権限、停止条件に分ける。これだけで、かなりの事故を前もって潰せる。
1. 入力を分ける
入力は「ユーザーの投稿」だけではない。Slackスレッド、添付ファイル、チャンネル名、ユーザー属性、Google Drive、CRM、GitHub 、カレンダーなどが入る。
ここで決めるのは、AIに何を見せるかではなく、どの条件なら見せないかだ。プライベートチャンネル、DM、顧客情報、契約情報、採用情報、認証情報らしき文字列は、最初から別扱いにする。読めることと、使ってよいことは違う。
2. 判断を記録する
AIエージェントは判断をする。どのスキルを使うか。どのファイルを読むか。どの操作を下書きに留めるか。ここがブラックボックスになると、業務では怖くて任せにくい。
最低限、依頼、選んだ処理経路、参照した情報源、外部書き込みの有無、承認待ちの理由を残す。Slack上の返答は短くてよいが、裏側ではジョブ単位で追えるようにする。
既存連載のSlackの1発言をAIエージェントの実行ジョブに変えるでも触れた通り、Slackの1投稿をそのまま実行命令にせず、依頼ライフサイクルへ変換する設計が効く。
3. 出力先を制限する
SlackのAIエージェントで特に見落とされやすいのが出力先だ。取得した情報が正しくても、返す場所が間違えば事故になる。
出力先は、DM、元スレッド、限定チャンネル、共有チャンネル、外部サービスで分ける。機密度が高い情報は、要約してもパブリックチャンネルへ出さない。ファイル名や会社名だけで機密が推測されることもあるため、出力前にマスキングを挟む。
4. 権限を実行主体ごとに分ける
人間の権限をそのままAIへ渡すと、便利だが危ない。おすすめは、実行主体を分けることだ。
- 読み取り専用のAI
- 下書きだけ作るAI
- 社内ファイルを扱うAI
- GitHubやCRMを触るAI
- 外部送信や公開反映はできないAI
このように分けると、失敗時の影響範囲を絞れる。Slackの画面では同じAIエージェントに見えても、裏側の実行権限は作業種別ごとに切り替える。
Slack AIエージェントを業務OSに変える設計で書いた通り、Slackは入口に留め、実行責任はサーバー側で管理する。ここを分けると、あとから承認、ログ、停止を足しやすい。
5. 停止条件を先に置く
AIエージェントに任せる業務ほど、止める条件が大事になる。判断不能、権限不足、送信先不明、金銭影響、外部公開、個人情報、契約・請求・採用に関わる操作は、自動実行しない。
Slack上では「承認待ちです」と短く返せばよい。大事なのは、止まった理由が人間に分かることだ。止まり方が丁寧だと、ユーザーは次の指示を出しやすい。
導入前のチェックリスト
SlackのAIエージェントを入れる前に、次の表を埋めるだけでも設計の粗さが見える。
| 論点 | 決めること | 未定のまま始めるリスク |
|---|---|---|
| 利用者 | 誰が依頼できるか | 想定外の部署から機密依頼が来る |
| 読み取り | どの情報源を読めるか | 権限過多のAIになる |
| 出力 | どこへ返してよいか | 見せてはいけない相手へ届く |
| 書き込み | どの操作を下書き止まりにするか | 外部送信や公開反映が走る |
| 承認 | 誰が何を承認するか | 判断が個人任せになる |
| ログ | 何を証跡として残すか | 失敗時に原因を追えない |
| 記憶 | 何を長期保存してよいか | Slack会話が不要に残る |
| 評価 | 何を成功とするか | 便利だが成果が測れない |
SIerや情シスが設計書へ落とすなら、ここからもう一段だけ具体化する。成果物は「AIエージェント利用ルール」ではなく、権限マトリクス、出力先ポリシー、承認フロー、監査ログ項目、例外時の運用手順に分ける。
たとえば権限マトリクスでは、営業チャンネル、開発チャンネル、経営チャンネル、DMで読める情報源を分ける。出力先ポリシーでは、パブリックチャンネルに出せる情報、限定チャンネルだけに返す情報、DMに閉じる情報を分ける。承認フローでは、外部送信、CRM更新、GitHubの本番反映、請求・契約・採用に関わる操作を別の承認線にする。
ここまで書くと、Slack上のAIエージェントは「便利なBot」ではなく、運用設計された業務システムとして扱える。開発会社に依頼するときも、機能要件だけでなく、権限と出力先の設計単位で見積もりやレビューをしやすくなる。
ここで全部を完璧に決める必要はない。ただし、未定の欄を「AIがうまく判断するはず」で埋めてはいけない。AIが判断してよい範囲を、人間が先に決める。
小さく始めるなら、読み取り専用、下書き作成、社内要約から始める。外部送信、削除、公開反映、契約、請求、広告、CRM更新は承認付きにする。この順番なら、現場の便利さを出しながら、戻せない操作を抑えられる。
Atsumellの視点
Atsumellでは、AIエージェントの導入を「チャットツールにAIを置く話」として扱わない。業務フローをAIが読める仕様に分解し、権限、例外、停止条件、承認線まで含めて設計する。
Kakusillで扱っている要件定義・設計ドキュメントの構造化も、同じ思想に近い。AIに任せる前に、AIが読める形で業務の境界を決める。SlackのAIエージェントも、ここを飛ばすとPoCは動いても本番運用で止まりやすい。
「SlackでAIに頼める」は分かりやすい価値だ。けれど、社内で本当に効くのは、その裏側にある権限設計、ログ、承認、成果物管理である。
AIエージェントをSlackに置きたいなら、最初の問いは「どのモデルを使うか」ではない。「誰の権限で何を読み、誰に何を返し、どこで止めるか」だ。この問いに答えられると、AIエージェントは面白いデモから、安心して任せられる業務基盤へ近づく。
Atsumellは、業務フローの可視化、AIが読める仕様への整理、Slack連携、権限設計、AIエージェントの構築までまとめて支援できます。最初の一歩は、任せる業務、読ませる情報、返してよい場所、承認が必要な操作を棚卸しすることです。自社のSlackにAIエージェントを入れる前に、この4点を一緒に整理できます。
