AI開発2026-05-31

【第1部】Slack AIエージェントを業務OSに変える設計

株式会社Atsumell|8分で読めます

# 【第1部】Slack AIエージェントを業務OSに変える設計

> 連載「Slack AIエージェント基盤を作る」全8部の第1部。

ここから8本かけて、Slackの一言がサーバー上のCLIを動かし、複数のAIエージェントが並行して実装し、記憶と定期実行まで持つ業務基盤になるまでを追う。第1部では、まず全体像を押さえる。なぜSlackなのか。Botと業務OSは何が違うのか。この見取り図があると、第2部以降の実装論が一気に読みやすくなる。

前後で読む

次回: 第2部 CLIをサーバーに上げる
最初に全体像をつかんだら、第2部 CLIをサーバーに上げるへ進むと実装の入口が見える。

SlackにAIを入れる話は、たいてい「質問に答えるBot」から始まる。

でも、現場で本当に欲しいのは返答だけではない。調査して、コードを書き、資料を作り、確認を取り、次の担当者へ渡すところまで進めてほしい。Slack AIエージェントの価値は、チャット画面の中で会話することではなく、Slackを業務の操作盤に変えるところにある。

私たちが今回のSlack AIエージェント基盤で作っているのも、単体のBotではない。Slackのメッセージを入口にして、サーバー上のCLIエージェント、ワーカープール、記憶、定期実行、成果物管理までをつなぐ業務OSだ。人間はSlackで指示し、AIエージェントは裏側の実行基盤で仕事を進める。

Slack Bolt for JavaScriptのような公式SDKは、イベント受信や返信の土台を提供してくれる。ただし、業務OSとして使うには、その上に「誰の依頼か」「何を任せるか」「どの権限で動かすか」「完了をどう知らせるか」という層を重ねる必要がある。

Slack AIエージェントは会話UIではなく業務の入口

Slackはすでに多くの会社で業務通知、相談、承認、雑談、障害対応の中心にある。ここにAIエージェントを置くと、別アプリを開かなくても自然に仕事を渡せる。

「この仕様を読んで差分をまとめて」「このPRの懸念点を洗って」「明日の会議の準備をして」といった依頼を、普段の会話と同じ場所で投げられる。

ただし、チャット欄をそのまま実行命令にするだけでは危ない。Slack AIエージェントは、入力を次のように分解する必要がある。

ユーザーの意図
対象プロジェクト
必要なツール
実行してよい範囲
返信すべき場所
保存すべき成果物

この分解があるから、AIエージェントは「返事をする人」から「業務を進める実行者」へ変わる。逆にこの層がないと、便利なデモは作れても、社内の継続運用には耐えにくい。

業務OSに必要な4つの層

Slackを業務OSにするには、少なくとも4つの層が必要になる。

1つ目はSlackイベント層だ。メンション、スレッド返信、リアクション、ショートカットを受け取り、同じSlack上へ進捗を返す。Slackが提供するエージェント機能追加の概念も参考になる。重要なのは、SlackのUIを派手に作ることではなく、会話の文脈を失わずに実行基盤へ渡すことだ。

2つ目は意図理解層だ。自然文の依頼を読み、「コード調査」「資料作成」「Slack返信」「定期確認」「記憶更新」のような作業種別に分ける。ここでは単純なキーワード分岐だけでは足りない。たとえば「先週の件、進めておいて」は、チャンネル、スレッド、過去のやり取り、ユーザーの役割を見ないと意味が決まらない。

3つ目は実行層だ。サーバー上でCLIエージェントを起動し、プロジェクトごとの作業環境で安全に処理する。人間がローカルで使っていたCLIを、そのまま社内の共通実行基盤へ載せる発想に近い。OpenAI Codexのようにコード作業へ強いエージェントが普及すると、Slackから開発タスクを渡す設計はより現実的になる。

4つ目は記録層だ。依頼、判断、成果物、失敗理由、次回に引き継ぐ情報を保存する。AIエージェントは毎回ゼロから考えるより、過去の決定やチームのルールを参照できるほうが安定する。

Botと業務OSの違いは責任線に出る

普通のBotは、入力に対して返答する。業務OSとしてのSlack AIエージェントは、入力からジョブを作り、ジョブの責任線を管理する。

たとえば「競合サービスの調査をして」と頼まれたとき、Botなら要約を返して終わる。業務OSなら、調査範囲を確認し、実行ログを残し、成果物のURLを返し、必要なら翌週の再調査を予約する。担当者が不在でも処理状態を追える。途中で失敗した場合も「どのツールで」「どの権限で」「どこまで進んだか」を確認できる。

この責任線を作るには、UIよりも状態管理が大きな役割を持つ。Slackのスレッドは会話の見た目であり、システム側にはジョブID、セッションID、ワーカーID、成果物IDが必要になる。運用ログや共有ドキュメントでは、実IDや実パスをそのまま出さず、追跡できる概念名に置き換えるのが安全だ。

技術説明で最初に伝えるべき責任境界

この基盤を開発者へ説明するとき、最初に押さえるべきなのは「どこまでAIが判断し、どこから実行基盤が責任を持つか」だ。Slackの投稿、意図理解、スキル選択、CLI実行、成果物保存、記憶更新を同じ箱に入れると、便利そうに見えても後から追えない。

だから、記事の中でも責任境界を明確にする。Slackは会話と承認のUI。semantic routerは実行経路の選択。CLI runnerはプロセスと成果物の管理。memory layerは残すべき判断だけを扱う。境界を分けて語ると、読者は自社に持ち込むときの置き換えポイントを見つけやすい。

実装を外部へ説明するときも、実IDや実パスをそのまま出す必要はない。重要なのは具体値ではなく、request key、worker id、artifact id、memory bankのような追跡単位を設計していることだ。

導入時に最初に決めるべきこと

SlackをAI業務OSにするなら、最初に画面ではなく運用境界を決めるべきだ。

どのチャンネルから依頼できるか
どのユーザーが実行を許可できるか
AIエージェントが触ってよいリポジトリやファイルはどこか
成果物はどこに保存するか
失敗時に誰へ通知するか
記憶として残してよい情報と残してはいけない情報は何か

ここを曖昧にしたまま作ると、Slack連携はすぐに便利な実験で止まる。逆に境界を先に決めると、後からCLI、ワーカー、定期実行、記憶の仕組みを足しても全体が崩れにくい。

Slack AIエージェントは、SlackにAIを貼り付けるだけでは成立しない。チャットを入口に、実行・記録・確認・再実行まで含めた業務OSとして設計する。そこまで作って初めて、社内AIは「聞く道具」から「仕事を進める同僚」に近づく。

実装の全体像: Slackを薄いUIにして、実行はランタイムに寄せる

エンタープライズ向けに見ると、この設計の肝は「Slack Botを賢くする」ことではない。Slackはあくまで薄いUIにして、実行責任をサーバー側のランタイムへ逃がす。Slackイベント、意図理解、スキル選択、CLI実行、記憶、定期実行、成果物管理を分けているから、後から運用を変えられる。

たとえば依頼が来たとき、すぐLLMへ投げるのではなく、まずターン単位のコンテキストを作る。そこにユーザー、チャンネル、スレッド、添付ファイル、返信先、許可された操作、過去の実行状態を集める。その後、direct route、script skill、instruction skill、通常CLI agentのどれで処理するかを決める。

ここで重要なのは、LLMの自由裁量を最初から最大化しないことだ。PPT生成、画像生成、成果物再添付、既存データ検索のように経路が明確なものは専用routeへ渡す。曖昧な調査や実装はCLI agentへ渡す。こうして「LLMが全部判断する」範囲を狭めると、誤爆や副作用をかなり抑えられる。

Profileとmemory bankを分ける

社内AIで厄介なのは、便利にするほど記憶が増えることだ。個人秘書的なAIと会社用AIを同じ基盤で動かすなら、読み書きできる記憶の範囲を明確に分ける必要がある。

この基盤では、profileごとにSlack app、人格、読み込む静的ファイル、memory bankを切り替える設計にしている。個人profileは個人用の記憶へ書き込み、必要に応じて会社側の公開ナレッジを参照できる。一方、会社profileは会社用bankだけを読む。個人側から会社側を読めても、会社側から個人側へ読めない一方向の境界を置く。

この設計は地味だが、実運用ではかなり効く。AIエージェントは「覚えている」ほど便利になるが、どの文脈をどのBotへ渡すかを間違えると、情報漏えいに直結する。Slackを業務OSにするなら、UIより先に記憶の境界を決める必要がある。

起動時に組み立てるコンポーネント

この構成を実装として見ると、起動時にかなり多くの部品を組み合わせている。Slack appだけを起動するのではなく、profile、Slack helper、skill registry、memory service、LLM session、request handler、heartbeatを順に束ねる。

コンポーネント	実装上の役割
profile config	使うSlack app、人格、読み込みファイル、memory bankを決める
skill registry	利用できる業務スキルと公開範囲を読み込む
LLM session	CLI agentをspawnし、streamと成果物を扱う
request lifecycle	dedupe、cancel、status、recoveryを管理する
heartbeat	定期タスク、watchdog、self-checkを起動する

この分け方にしておくと、Slack UIの変更と実行基盤の変更を独立して進められる。たとえば新しい資料生成スキルを足すとき、Slack handler全体を書き換える必要はない。skill registryへ追加し、semantic routerの候補に載せ、必要ならdirect routeを足すだけで済む。

地味だが、ここがBot実装との大きな差だ。Botはイベントハンドラに処理が集まりやすい。業務OSは、イベントハンドラを入口に留め、実行責任を小さなランタイム部品へ分散させる。