AI開発2026-05-31

（まとめ）Slack AIエージェント基盤の全体設計

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

# （まとめ）Slack AIエージェント基盤の全体設計

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

8本を通して見てきたのは、SlackにAIチャットを置く話ではない。Slackの一言を安全な実行単位へ変換し、サーバー上のCLI、ワーカープール、記憶、定期実行、成果物管理までつなぐ業務基盤の作り方だ。

Slackは入口にすぎない。実行責任はサーバー側へ寄せる。記憶は便利さではなくデータ管理として扱う。定期実行は通知量ではなく判断品質で見る。成果物はファイルではなく、誰が何を作り、どこで検査し、どこで承認したかを追える成果物レコードとして扱う。

この全体像が見えると、各回の実装論がつながる。第2部のCLI実行基盤は、第3部のworker分離へつながる。第4部の1ターン処理は、第5部の意図振り分けへつながる。第6部の記憶領域は、第7部の定期実行で使われる。第8部の成果物レコードと安全ゲートは、すべての実行結果を社内で扱える形に閉じる。

Slack AIエージェント基盤は実行単位を作る

普通のBotは、メッセージを受けて返答する。Slack AIエージェント基盤は、メッセージを受けて実行単位を作る。

ここが大きな違いだ。実行単位には、依頼者、Slackのチャンネル、スレッド、対象プロジェクト、実行モード、ワーカー、成果物、失敗時の扱いが紐づく。人間から見るとSlackの1投稿でも、裏側ではジョブ、セッション、ワーカー、成果物レコード、記憶更新が動く。

Slack Bolt for JavaScriptはイベント受信の土台になる。ただし、Boltだけでは業務基盤にはならない。Slackイベントを受けた後に、重複排除、権限確認、意図理解、ジョブ化、進捗返信、キャンセル、復旧を持つ必要がある。

この設計にすると、Slackは薄いUIになる。ユーザーはいつものSlackで依頼し、実行基盤は裏側で長時間タスクを進める。完了時には短い要約と成果物リンクだけを返す。詳細ログや中間生成物は成果物レコードへ寄せる。

全体アーキテクチャは5層で見る

全8部を1枚にすると、構成は5層で整理できる。

1つ目はSlackイベント層。メンション、スレッド返信、リアクション、キャンセルを受け取る層だ。

2つ目はターン処理と振り分け層。依頼の文脈を作り、意図振り分けルーターで処理経路を決める。

3つ目は実行層。CLI互換ラッパ、ワーカープール、ロック、出力変換が入る。

4つ目は状態管理層。記憶領域、スレッド単位の継続実行、依頼台帳、復旧用ストアを扱う。

5つ目は統制層。成果物、品質確認、承認、観測イベント、安全ゲートを持つ。

この図で見ると、LLMは全体の一部でしかない。AIが賢いかどうかより、どの状態をどの層で固定するかが運用品質を決める。

OpenAI Codexのようなコード作業向けエージェントを使う場合でも、Slackから直接投げるだけでは足りない。CLIをサーバーで動かすなら、プロセス起動、逐次出力、キャンセル、タイムアウト、成果物、承認を同じ実行単位に閉じ込める必要がある。

実装で効く設計判断

連載全体で繰り返し出てきた判断は、モデル選定より手前にある。

Slack側では、1イベントを必ず重複排除する。Slack retryやネットワーク遅延で同じイベントが来ても、同じ依頼キーなら二重実行しない。長時間処理では状態更新を返し、キャンセル要求が来たらLLMではなくOSプロセスを止める。

CLI実行側では、ワーカーごとにhomeを分ける。認証状態、設定、セッションキャッシュ、ロックを共有しない。同じSlackスレッドの継続実行では、前回と同じワーカーを優先し、再開セッションを別ワーカーへ安易に移さない。新規実行の再試行と、継続実行の再試行は別物として扱う。

意図理解側では、スコアだけで振り分けない。専用処理、手続き型スキル、指示型スキル、通常のCLIエージェントを分け、破壊的操作や外部副作用は承認待ちにする。判断結果をSlackに短く返すと、ユーザーは誤解に気づける。

記憶側では、Slackスレッド全文を保存しない。保存するのは、次回も使う判断だけだ。記憶領域、適用範囲、有効期限、出典、信頼度、マスキング状態を持たせる。個人profileと会社profileでは、読める記憶領域を一方向にする。

成果物側では、生成ファイルだけを成功扱いにしない。レンダリング確認、リンク確認、セキュリティ確認、承認状態を成果物レコードへ紐づける。記事、PPT、画像、PR、外部SaaS下書きで品質ゲートを変える。

8部を1本の実装線として読む

各回は独立して読めるが、実装順としてはかなり素直につながっている。

回	設計で決めること	失敗すると起きること
第1部	SlackをUIに留め、実行責任を分ける	Botの返答だけで終わる
第2部	CLIをサーバー上の実行単位にする	個人端末や手元認証に依存する
第3部	ワーカーのhome、ロック、スレッド継続先を分ける	認証、セッション、成果物が混ざる
第4部	Slackの1発言を依頼ライフサイクルへ変換する	二重実行、キャンセル不能、復旧不能になる
第5部	意図振り分けルーターとスキル定義で経路を選ぶ	曖昧な依頼を危険な処理へ流す
第6部	記憶を短期文脈、長期ナレッジ、ユーザー設定へ分ける	便利さと情報漏えいが混ざる
第7部	定期実行、低優先度キュー、停止検知を分ける	通知過多か、停止に気づけない運用になる
第8部	成果物、承認、観測イベントを持たせる	社内導入時に監査線が切れる

この順番で読むと、AIエージェントの導入は「LLMを呼ぶ」ことではなく、業務の状態遷移を設計する話だと分かる。Slack、CLI、記憶、定期実行、成果物は別々の機能ではない。1つの依頼を安全に進めるための部品だ。

エンタープライズで先に決める境界

社内に入れる前に決めるべき境界は、少なくとも6つある。

誰がどのチャンネルから依頼できるか
どのプロジェクトやファイルへ触れてよいか
どのCLI homeと認証状態を使うか
どの失敗なら再試行してよいか
どの情報を記憶へ残してよいか
どの操作で人間承認を挟むか

公開できる設計資料では、実環境のトークン名、volume path、社内URL、seed名をそのまま出す必要はない。代わりに、独立認証、ワーカー分離、承認ゲート、成果物レコード、記憶領域の分離という構造を書く。攻撃に使える具体値を伏せても、設計判断は十分に伝えられる。

OpenAIのコード生成ガイドでも、コード作業ではコンテキストと評価の渡し方が結果を左右する。社内AIでは、そこに権限、監査、復旧、承認が重なる。モデルの出力だけでなく、実行基盤がどこで止めるかを設計する。

小さく始めるならどこから作るか

いきなり全層を作る必要はない。小さく始めるなら、Slackの1スレッドを1requestとして扱うところから始めるとよい。

最初の段階では、重複排除、依頼台帳、短い状態返信、完了返信だけでよい。次に、サーバー上のCLI実行役をつなぎ、タイムアウトとキャンセルを入れる。その後、ワーカープール、スレッド単位の継続実行、成果物レコードを足す。記憶と定期実行は、実行基盤の責任線が見えてから入れるほうが安全だ。

最初から「何でもできるAI」にしない。読み取り、下書き、要約、コード調査のような低リスク領域から始める。外部送信、削除、公開反映、契約、請求、PR mergeは承認待ちにする。この順番なら、現場の便利さを出しながら、事故につながる副作用を抑えられる。

この連載から持ち帰る設計原則

最後に残る判断基準はシンプルだ。AIに何をさせるかより先に、誰が承認し、どのログを残し、どの既存システムと接続し、どこで止めるかを決める。

承認者は操作種別ごとに変える。読み取りや下書きは自動でよい。外部送信、削除、公開反映、費用発生、PR mergeは人間へ渡す。ログは最終回答だけでなく、依頼、選ばれた経路、実行ワーカー、成果物、失敗分類、承認結果を残す。既存システム連携は、Slack、GitHub、ファイルストレージ、CRM、Google Driveのどれを読むか、どれへ書くかを分ける。

Slack AIエージェント基盤の面白さは、チャット体験ではなく運用設計にある。Slackで頼める。サーバーで動く。並行して進む。文脈を覚える。定期的に見に行く。成果物を検査して返す。ここまでつなげると、AIエージェントは単発の便利ツールではなく、業務を進めるインフラになる。

こうしたAIエージェントを自社で作るなら、Atsumellは最初の業務フロー可視化から、実行基盤、権限設計、記憶設計、Slack連携、AIエージェントの構築まで支援できます。まずは「どの業務を任せるべきか」を図にするところから、一緒に整理できます。