Slack AIエージェントは承認設計から

SlackにAIエージェントを入れると、最初はだいたい楽しい。

「このスレッドを要約して」「この資料を作って」「この問い合わせに返す文面を考えて」と頼めるだけで、仕事が前に進んだ感じがする。

だが、運用に入るとすぐ別の問題が出る。

誰の権限で読んだのか。外部送信してよいのか。生成したファイルは誰が確認するのか。失敗した依頼はどこに残るのか。

Slack AI エージェントで最初に設計するべきなのは、会話の賢さではない。承認の流れだ。

チャットで頼めるようにするだけなら早い。業務として毎日使えるようにするには、依頼、判定、承認、実行、記録の順番を閉じる必要がある。

Slack Developer Docs の AI in Slack は、Slack上でエージェントを構築し、Slackの文脈やツールと接続する考え方を示している。Bolt for JavaScript も、イベント、インタラクション、認可、アプリUIを扱う土台になる。つまり、入口は用意されている。問題は、その入口から何をどこまで動かすかだ。

Slack AI エージェントで最初に見るべき論点

Slackは仕事の入口として強い。通知、相談、承認、障害対応、雑談まで同じ場所に集まる。だからAIエージェントの入口にも向いている。

ただし、入口が自然すぎるほど、境界は曖昧になる。

たとえば、営業担当がSlackでこう頼む。

> 昨日の商談メモを見て、お礼メールを作っておいて

この依頼には、少なくとも5つの判断が隠れている。

ここを決めないままAIに渡すと、返答はそれらしくなる。だが、実務では危ない。

「下書きのつもりだった」「送信までしてよいと思った」「この顧客情報は見せないつもりだった」が後から出る。

Slack AI エージェントは、質問応答Botではなく業務の入口だ。だから、入口の次に承認を置く。ここを飛ばすと、便利なデモはできても、毎日使う運用には届きにくい。

Botと業務AIエージェントは承認の重さが違う

Botは、決まった入力に決まった返答を返すことが多い。天気、勤怠、FAQ、通知のような用途なら、処理の範囲は比較的読みやすい。

AIエージェントは違う。依頼を解釈し、必要な情報を探し、ツールを呼び、成果物を作る。場合によっては、Google Drive、Gmail、Calendar、CRM、GitHubまで横断する。

SlackのAI機能ページ でも、Slackbot、ワークフロー、アプリ連携、AIが仕事の流れに入る前提が並んでいる。Slack上で自然に動くほど、裏側の権限と承認は重くなる。

ここで大事なのは、AIを信用しないことではない。

信用するために、止める場所を先に決めることだ。

たとえば、次のように分ける。

• 読むだけなら自動でよい
• 要約と論点抽出も自動でよい
• 下書き作成は自動でよい
• 外部送信は人間承認が必要
• CRM更新は対象案件を確認してから
• 請求、契約、個人情報、採用評価はさらに強い確認を入れる

この段差があると、AIエージェントは怖くなくなる。

逆に「便利だから全部やって」とすると、どこかで必ず止まる。チームの誰かが怖くなって、利用が広がらない。

依頼から記録までを5段で設計する

Slack AIエージェントの承認設計は、重い業務フロー図から始めなくていい。最初は5段で十分だ。

1. 依頼を受ける
2. 意図と対象を判定する
3. 必要なら承認を取る
4. 実行する
5. 結果と根拠を記録する

この5段を、Slackのメッセージ単位で書く。

これだけで議論がかなり実務になる。

「Slack AIエージェントを作りたい」ではなく、「Slackから受けた依頼を、どこで止めるか」に変わる。

この変化が大きい。機能の話から、業務の安全性の話に移れる。

SIerや情シスの現場なら、この5段はそのまま要件定義の表になる。

Slack上の確認メッセージには、対象データ、実行内容、承認者、戻し方、記録先を出す。人間はボタンや返信で判断する。AIはその判断を受けて、次の処理だけを進める。

こうしておくと、承認は口頭の空気ではなく仕様になる。顧客データ更新、契約文面レビュー、本番反映のように事故が重い操作ほど、この「確認メッセージの型」が効く。

既存記事の Slack AIエージェント基盤の全体設計 では、Slackを業務OSとして見る考え方を整理した。今回の承認設計は、その次に置くべき実務の線引きだ。

承認が必要な操作を先に棚卸しする

承認設計でよくある失敗は、AIが何をできるかから考えることだ。

「メールも送れる」「CRMも更新できる」「ファイルも作れる」と機能を足していくと、最後に怖くなる。

順番を逆にする。

先に、承認が必要な操作を棚卸しする。

• 社外に送る
• 顧客データを書き換える
• 契約、請求、採用、広告、権限に触る
• 個人情報を含むファイルを共有する
• 本番環境や公開サイトを変更する
• 会社としての判断に見える文面を作る

ここに当たるものは、Slack上で一度止める。

止め方は難しくない。AIエージェントが「実行前の確認」として、対象、変更内容、影響、戻し方を短く出す。人間はそれを見て承認する。

この形にすると、Slackはただのチャットではなく承認画面になる。

しかも、会話の文脈が残る。なぜ実行したのか、誰が確認したのか、どのメッセージから始まったのかを追いやすい。

Slackのワークフロー機能 のように、定型の依頼や承認をSlack内に置く考え方はすでに一般化している。AIエージェントでも同じだ。違いは、AIが依頼の曖昧さを読む分、承認前に要約と影響整理を出させる点にある。

記録は「あとで説明できる形」にする

Slack AIエージェントの実行ログは、機械用のログだけでは足りない。

あとで人間が説明できる形にする必要がある。

最低限、次の5つを残す。

• 依頼した人
• 元メッセージ
• AIが解釈した意図
• 実行した操作
• 成果物と保存先

さらに、承認が入った場合は「承認した人」と「承認前の要約」も残す。

ここまであれば、後から見ても業務として追える。

ログが弱いAIエージェントは、最初の数回は便利に見える。だが、運用が増えるほど不安になる。

「あのファイルはどこに作った？」「この返信案は何を根拠にした？」「誰がCRM更新を許可した？」に答えられないからだ。

AIエージェントを社内に置くなら、記録はおまけではない。成果物の一部だ。

この観点は 社内のAIエージェントは権限設計から ともつながる。読める範囲、動かせる範囲、記録する範囲を分けるだけで、運用の安心感はかなり変わる。

導入前のチェックリスト

SlackのAIエージェントを入れる前に、次の質問へ答えられるか見てほしい。

• どのチャンネルで依頼を受けるか
• 誰の権限でデータを読むか
• どの操作は自動でよいか
• どの操作は人間承認が必要か
• 承認前にAIが何を要約するか
• 成果物をどこに保存するか
• 実行結果をどこへ記録するか
• 失敗時に誰へ戻すか

この8問に答えられないなら、まだ実装より前の段階だ。

機能を減らす必要はない。順番を直せばいい。

読む、整理する、下書きする。ここまでは小さく始めやすい。

外部送信、顧客データ更新、本番変更。ここは承認を挟む。

この段差を作るだけで、SlackのAIエージェントはかなり現場に入れやすくなる。

最初に作るものは3つでいい。

• 承認が必要な操作リスト
• Slackに出す確認メッセージのテンプレート
• 実行後に記録する場所の対応表

この3つがあれば、いきなり大きな実装に入らなくても、運用の骨格をレビューできる。

Atsumellの視点

AtsumellでAIエージェントを設計するときも、最初から「何でもできるAI」を目指さない。

最初に見るのは、業務の入口と停止条件だ。

Slackで頼めるようにする。

AIが調べる。

下書きや成果物を作る。

人間が確認する。

承認された範囲だけ実行する。

結果をSlack、CRM、Driveなどに残す。

この順番なら、AIエージェントは現場の仕事に入りやすい。反対に、承認と記録を後回しにすると、便利な試作のまま止まりやすい。

Kakusillが要件定義や設計ドキュメントをAIが読める構造に整えるのも、同じ理由だ。AIに任せる前に、入力、判断、権限、停止条件を言葉にする。Slack AIエージェントでも、その構造があるほど運用は強くなる。

要件をどの粒度で構造化するか迷う場合は、AI要件定義ツールの選び方 で整理した観点も近い。ツール選定より前に、AIが読む仕様の形を決める。Slackから動くAIでも、ここは同じだ。

社内のAIエージェントをSlackから動かしたいなら、最初の設計テーマは会話の賢さではない。

承認の流れだ。ここから決めると、AIはやっと業務の一員になる。

関連記事

• Slack AIエージェント基盤の全体設計
• 社内のAIエージェントは権限設計から
• AI社員とは？導入前に見る3つの違い