Slackの会話がそのまま業務画面に、Surfacesはライブ更新が10月

Salesforceは2026年9月11日、Slackの会話や接続済みシステムのデータから業務画面を生成する「Slackforce Surfaces」を日本向けに発表した。米国では前日の9月10日に発表されており、Salesforceの日本向け公式発表 は、Slackbotへの自然言語の指示からダッシュボード、レポート、プレゼンテーション、計算ツールなどを作成できるとしている。

Slackforce Surfacesは、AIとの会話を回答で終わらせず、チームが閲覧、絞り込み、コメント、判断に使える対話型画面へ変える機能だ。Slackbotを有効にしたEnterprise+、Business+、Pro、Legacy、Free Teamsが対象で、生成機能は発表時点から利用可能。一方、基データの変更を自動反映するリアルタイムデータ連携は2026年10月から順次提供予定であり、現在の画面をライブ更新済みとみなすことはできない。

会話から共同作業用の画面を作る

Surfacesの成果物は、メッセージの要約ではなく、Slack内で操作できる共有インターフェースだ。Slackbotに必要な情報と目的を伝えると、Slackの会話、Salesforceのデータ、そのワークスペースに接続されたシステムを基に、用途に合った画面を生成する。未接続のシステムや、利用者に閲覧権限がない情報を自由に取得する機能ではない。

生成したSurfaceはチャンネルにピン留めでき、参加者は同じ画面を絞り込み、詳細を確認し、コメントを加えられる。別のBIツールや資料へ情報を転記する工程を減らし、会話が行われた場所に判断材料を残せることが、従来のチャット回答との違いになる。

作成時には「何を表示するか」だけでなく、誰が何を判断する画面なのかを指定する必要がある。たとえば営業会議向けなら、案件一覧の要約よりも、停滞案件、現在のステージ、最終活動日を確認できる画面の方が目的を明確にできる。承認用途では、申請内容、根拠となるデータ、判断項目を一つのSurfaceにまとめられる。

現在の生成画面と10月のライブ更新は別

発表時点で利用できる画面生成と、10月に始まるライブデータ対応は区別しなければならない。独立系媒体の AI Chat Dailyの報道 も、無料プランを含むSlackbot有効ユーザーが対象である一方、元システムの変更に追随するライブデータ対応は2026年10月に提供されると伝えている。

ライブ対応前のSurfaceは、作成時に参照した情報を画面として整理できても、その後にCRMの商談やサポートケースが更新されたことまで自動で保証するものではない。業務判断に使う場合は、参照した期間、画面の作成時刻、手動で再生成した時刻を表示し、「いつの数字か」が分かる状態にする必要がある。

10月以降も、「ライブ」がすべての接続先で無条件の即時同期を意味するとは限らない。具体的な提供日、地域別の開始時期、接続先ごとの更新間隔、更新に失敗した場合の表示は、発表資料では明らかにされていない。提供開始後に、元データの更新時刻とSurfaceへの反映時刻を接続先ごとに確認する必要がある。

四部門では入力、公開範囲、更新、承認者が異なる

Slackの製品紹介 は、営業パイプライン、AI利用コスト、サポートキュー、財務予測を部門別の利用例として挙げている。実際に導入する際は、その例をそのまま複製するのではなく、入力データ、表示範囲、更新頻度、承認者の四項目を業務ごとに定義する必要がある。

• 営業：入力候補は商談金額、ステージ、最終活動日などのCRMデータ。表示先は担当チームと営業管理者を基本とし、ライブ対応後は案件変更に合わせて更新する。優先順位やリスク判定の定義は営業責任者が承認する。
• IT：入力候補はAIの利用量、トークン消費、コスト、ROI。管理者と予算責任者に公開範囲を絞り、費用監視に必要な周期で更新する。異常とみなす基準や部門別表示の可否はIT管理者と予算責任者が確認する。
• サポート：入力候補はケースの緊急度、SLA、顧客区分、担当状況。顧客情報を扱うため担当チームの限定チャンネルに表示し、ケースの変化に追随させる。キューの並び順と優先条件はサポート責任者が承認する。
• 財務：入力候補は予算、実績、予実差、見通し。経営会議など必要な範囲だけに公開し、締め処理や修正仕訳との時間差を明記する。速報値と確定値の区分、増減要因の分類は財務責任者が確認する。

これは製品に組み込まれた承認フローではなく、発表された利用例を安全に運用するための設計案である。営業やサポートでは短い更新間隔が価値になりやすいが、財務では未確定の数値が自動表示されると誤解を招く。部門ごとに「速報」「確認済み」「確定」を分け、誰が業務判断に使える数字なのかを明示する必要がある。

共有時は参照権限と公開範囲を分けて確認

Salesforceは、Surfacesにも既存のアクセス権限が適用され、許可された情報だけを扱うとしている。ただし、作成者が元データを閲覧できることと、その内容から作った画面を特定のチャンネルで共有してよいことは別の判断になる。部門横断チャンネルや社外関係者を含むSlack Connectでは、入力元の権限と生成後の公開範囲を分けて確認する必要がある。

権限事故や誤った可視化を避けるための導入手順は、次のように整理できる。

1. 対象業務を一つに絞り、Slackの会話、Salesforce、Google Driveなど、入力元ごとの所有者と機密区分を記録する。
2. 限定チャンネルでSurfaceを生成し、顧客名、個人情報、未確定数値など、公開対象外の情報が含まれていないか確認する。
3. 共有先の参加者を確認し、社外ゲストや閲覧する必要のない部門が含まれる場合は公開先を変更する。
4. 業務責任者を承認者に定め、指標の定義、参照時刻、欠損値、AIによる分類や要約を確認してからピン留めする。
5. ライブ対応後は、元データの削除、利用者の権限変更、接続解除が既存のSurfaceへどう反映されるかを再確認する。

この手順はSalesforceが追加の承認機能として発表したものではなく、共有前に人が行う運用上の確認である。既存権限の適用は重要な前提だが、AIが作った分類や指標の妥当性、表示先の業務上の必要性まで自動的に保証するとは発表されていない。

未確定なのはライブ連携の実装条件

確認できているのは、Slackforce Surfacesの画面生成がSlackbotを有効にした全プランで利用でき、リアルタイムデータ連携が2026年10月から順次提供される予定だという範囲までだ。公式発表には、未提供の機能が予定通り、または最終的に提供されない可能性があるとの注意書きもあるため、現段階の導入判断は現在利用できる生成機能と将来のライブ機能を分けて行う必要がある。

次に確認すべき点は、接続可能なシステムの範囲、実際の更新間隔、地域やプランごとの開始時期、監査履歴、共有後に権限が変わった場合の挙動だ。会話から共同作業用の業務画面を作れることは確認できたが、その画面を継続的な業務記録として扱えるかどうかは、10月以降の提供条件と実際の更新動作が明らかになってから判断することになる。