社内の情報を扱うAIで最初に詰まるのは、モデルの賢さではなく権限です。誰が何を見てよいのかを守れないまま検索や要約を載せると、便利さと引き換えに事故が起きます。Slackは、この順番を先に決めたうえで自社の製品にAIを組み込みました。Anthropicが公開している導入事例と、Slack公式サイトの機能ページに、何を作ったのかが書かれています。
自社サービスへのAI組み込みを検討している側にとって、この事例が参考になるのは、公表されている数値の大きさではありません。公表されているのは週あたり97分という1つの値だけです。参考になるのは、何を選定の観点に置いたのかと、機能をどの順番で積んだのかのほうです。
何を作ったのか
導入事例では、SlackはSalesforce傘下のソフトウェア企業で、自らを「the agentic work operating system」（エージェント時代の仕事の基盤）と位置づけているとされています。
作られた機能として挙げられているのは4つです。自然言語で会話・スレッド・ファイルを横断して探せるAI検索。要点と決まったこと、次にやることを抜き出すチャンネルとスレッドの要約。未読の中から重要なものを優先して並べる振り返り。そして、ワークフローの組み立てやハドル（音声通話）からの議事メモ作成といった補助機能です。
Slack公式サイトの機能ページには、これらがどう並んでいるかが載っています。優先すべきことを示す「Today」ビュー、個人向けのAIエージェントとしてのSlackbot、チャンネル要約・スレッド要約・日次ダイジェスト、会話だけでなくPDF・画像・Google ドライブのファイル・資料・サポートの問い合わせ・Salesforceのレコードまで横断するエンタープライズ検索、ワークフローの自動化、メッセージの翻訳、会議メモの自動生成、そしてSlackの中で動くSalesforceのエージェントであるAgentforceです。
積み上がり方を図にしておきます。
この順序が重要です。いちばん下にあるのは権限とデータの扱いで、その上に検索、その上に要約、いちばん上に提案と自動化が乗っています。逆に積むと、要約が見せてはいけない内容を含みます。
何を見て選んだのか
導入事例には、Claudeを選んだ理由として4つの観点が挙げられています。
1つ目は、人間らしい理解と、含みのある会話の解釈です。社内のやり取りは、要件だけが整然と書かれた文書ではありません。冗談、途中で立ち消えた議論、前提の共有された省略が混ざります。要約の質は、ここを読み違えないかで決まります。
2つ目は、長い文脈を扱えることです。導入事例では、業界でも広い部類のコンテキストウィンドウが挙げられています。長いスレッドを途中で切らずに扱えるかどうかは、要約では致命的な差になります。
3つ目は、規模です。導入事例には、Slack全体で毎日膨大な量のメッセージとファイルが行き交うことが前提として書かれています。試作で動くことと、その規模で動き続けることは別の問題です。
4つ目が、安全性と法令順守の要件です。導入事例には、企業向けのセキュリティ要件を満たすこと、そして内容とチャンネルの権限を尊重することが明記されています。Slack公式サイトの機能ページには、顧客データを大規模言語モデルの学習には使わないこと、処理はSlackの安全な基盤の中で行われることが書かれています。
導入事例には、社内での使い方についての言及もあります。Site Reliability Engineerとして名前の挙がっているRobert Anselさんについて、チームがClaude Codeを不具合の修正に使い、開発の速度を上げていると書かれています。製品に載せるだけでなく、作る側でも使っているという形です。
公表されている数値は1つだけ
導入事例に記載されている数値は、要約と振り返りの機能によって、平均的な利用者が週あたり97分を節約している、というものです。同じ値はSlack公式サイトの機能ページにも載っています。チャンネル要約・スレッド要約・AI検索といった機能によるものだと説明されています。
この値の読み方には注意が要ります。測り方は公開されていません。「平均的な利用者」がどの範囲を指すのか、比較の対象が何だったのかも書かれていません。時間の節約という指標は、もともと推定を含みます。したがってこの値は、自社の見積もりの根拠にはできません。Slackがそう公表している、という事実として扱うのが正確です。
一方で、この値の「小ささ」には意味があります。週あたり97分は、業務時間の全体から見れば大きな比率ではありません。AIの導入事例では倍率の大きい数値が並びがちですが、日常業務に薄く広く効く機能の効果は、この程度の刻みで現れます。大きな数字が出ないことを失敗と判定しないための目安として使えます。
引用された言葉
導入事例には、3人の名前が挙がっています。
ソフトウェアエンジニアリング担当VPのAnanya Helmichさんは、AIの仕組みを作るうえでAnthropicが重要な役割を果たしてきたとしたうえで、Claudeのモデルの品質と性能が、顧客にとって本当に意味のあるものを作ることを可能にしていると述べています。
検索とAI担当のエンジニアリングVPであるSamuel Messingさんは、Anthropicとの緊密な協働が、エンジニアリングとプロダクトのチームによる試作とモデルの検証を速めたと述べています。ここで語られているのは完成品の性能ではなく、試す速さです。
3人目のRobert Anselさんについては、前述のとおり社内での開発への活用が書かれています。
日本の実務者が持ち帰れる点
3つあります。
1つ目は、権限を最下層に置くことです。この事例で明記されているのは、内容とチャンネルの権限を尊重するという設計です。社内文書の検索や要約を作るとき、まず決めるべきは「誰がどれを見てよいか」であって、どのモデルを使うかではありません。ここが決まっていないと、精度を上げるほど危なくなります。
2つ目は、選定の観点に「長い文脈を切らずに扱えるか」を入れることです。要約や検索の品質は、モデルの一般的な賢さより、対象を丸ごと渡せるかどうかで決まる場面が多くあります。試すときは、いちばん長い実物で試すのが確実です。
3つ目は、効果の見積もりを控えめに置くことです。公表されている値が週97分だという事実は、期待値の置き方の参考になります。導入の説得材料として大きな倍率を掲げると、実測が届かなかったときに取り組み自体が止まります。
書かれていないこと
導入事例にもSlack公式サイトの機能ページにも、機能ごとの提供開始時期、費用、収益への影響、システム構成や連携の詳細、他のモデルとの比較の内容、利用率や利用者の評価は書かれていません。週97分という値の測定方法も公開されていません。
したがって、この事例から確認できるのは、選定の観点と機能の並べ方、そして公表された1つの値だけです。導入の費用対効果を判断する材料としては足りません。自社で同じことを検討する場合は、この事例を設計の参考にしたうえで、効果は自社の実物で測る必要があります。
この分野の実務を相談したい方へ
記事で扱っている内容は、当社が実務として支援している領域です。 自社で進めるか外部に任せるかの判断からご相談いただけます。