［ビジネスマン向け］Slackの会話を組織知に変える——人間とAIの協働を根づかせる6つの実践

2026-08-21

はじめに

　Anthropicが 2026年8月19日、SlackのChief Product OfficerであるJaime DeLanghe氏へのインタビューを公開しました。本稿では、会話を組織知へ変え、人とAIエージェントが同じチームで働くための6つの実践策を整理します。

参考記事

メイン記事:

タイトル: Turning conversation into knowledge: how Slack builds human-agent teams
著者: Anthropic（Jaime DeLanghe氏へのインタビュー）
発行元: Claude by Anthropic
発行日: 2026年8月19日
URL: https://claude.com/blog/turning-conversation-into-knowledge-how-slack-builds-human-agent-teams

要点

公開チャンネルの会話は、エージェントが決定理由と文脈の変化を再構成するための組織知になる
エージェントが作成・要約・監視・準備を担い、人間がレビュー・判断・方向修正を行う引き継ぎの循環が基本である
各エージェントには、人間の同僚と同様に明確な役割、目標、利用可能な情報と道具が必要である
非機密の通常業務は社内公開を既定にし、機密情報は意図的な境界で隔離する運用が推奨される
メッセージ数やトークン数ではなく、手戻り、判断、処理時間、事業成果を含む指標で評価する必要がある

詳細解説

会話履歴を検索対象から知識基盤へ変える

　Slackは長年、職場の会話を組織知として蓄積する構想を持っていました。しかし、会話量が増えるだけでは、人が決定の理由や経緯を継続的に整理できません。DeLanghe氏は、過去の研究でも「会話は自動的には知識にならず、人が同じ説明を繰り返していた」と振り返っています。現在はエージェントが大量の会話を読み、何を決めたかだけでなく、なぜ決めたか、前提がどう変わったかを再構成できます。

　実践の第一歩は、通常業務を公開チャンネルへ置くことです。DMや非公開スレッドで決まった内容はエージェントから見えず、組織の検索可能な履歴にも残りません。Slackだけでなく、会議記録、メール、カレンダー、文書リポジトリを接続すれば、同じ背景説明を繰り返す負担を減らせる可能性があります。

　ただし、公開範囲を増やすことと、無制限に情報を見せることは同じではありません。Claude Tagの公開時にも整理されたように、エージェント用の資格情報、役割、情報アクセスの境界を先に定義し、機密区分に応じてワークスペースを分ける必要があります。

人とエージェントの引き継ぎを業務の単位にする

　人間とエージェントの協働は、AIが最後まで自動処理する形だけではありません。エージェントが下書き、要約、監視、準備を行い、人がレビュー、判断、優先順位付け、方向修正を行って、次の作業を戻す循環が中心です。DeLanghe氏の週初めには、日次ブリーフィング、前週の製品ワークショップ要約とエスカレーション、ウェブ上のAI動向、当日の会議準備、プロフィール文の改訂案が並びます。

　実務では、エージェントの成果物を共有チャンネルへ置き、人とAIが同じ場所で仕分けできるようにします。絵文字リアクションなどの軽い合図をタスク登録へ変える仕組みも有効です。重要なのは、自動化率ではなく、どこで人が確認し、何を決めたら次の処理へ進むかを明示することです。

エージェントの役割を同僚のように定義する

　複数の専用エージェントは、一対一のチャットボットとは異なる管理が必要です。DeLanghe氏は、エージェントを同僚のように捉え、役割と責任を明確にする方法を勧めています。一般エージェントにはヘルプデスク登録や週次指標の取得など、定型で説明しやすい仕事を任せます。専門エージェントには、対象業務、利用する情報、使える道具、判断を人へ戻す条件を定義します。

　Anthropicの関連発表では、人とエージェントが同じ作業空間、成果物、チーム名簿を共有し、エージェントごとに固有の資格情報、記憶、スキル、道具を持つ考え方が示されています。利用者が「このエージェントは何のためにいるか」を説明できない場合、役割を見直すか終了する判断も必要です。利用を義務化するより、具体的な業務価値を実感できる設計が採用を支えます。

公開を既定にし、非公開を意図的に選ぶ

　通常のプロジェクト、告知、Q&Aを社内公開にすると、新しい社員もエージェントも過去の経緯から学べます。非公開チャンネルは、その情報を参照するすべてのエージェントの盲点になります。Slackの考え方では、非機密の仕事を公開し、機密性のある内容だけを明確な理由で隔離します。

　ここでは心理的安全性も欠かせません。完成前の案や不確かな質問を公開できなければ、重要な検討過程はDMへ戻ります。DeLanghe氏は、公開範囲の拡大を単なる設定変更ではなく、途中の考えを互いに善意で受け止める文化の問題として扱っています。情報管理規程、権限設計、チームの対話規範を同時に整える必要があります。

使い方を公開し、再利用できる形へ変える

　Salesforceには「How I Slackbot」という全社チャンネルがあり、DeLanghe氏によれば数千人規模でスキル、デバッグ方法、作業の工夫を共有しています。営業の工夫が開発へ応用されるように、部門を越えて使い方が伝わります。Slack社内では、あるプロダクトマネージャーがClaudeの設定方法をCanvasへまとめ、他の担当者が形式をコピーし、ワークショップやGitリポジトリの作成へ広がりました。

　全社向けの共有チャンネルを用意し、「何を、どの情報で、どう実行し、どこを人が確認したか」を短く残すと、個人の成功例をチームのテンプレートやスキルへ変えられます。完成した成果物だけでなく、設定と判断基準を共有することが再現性につながります。

活動量ではなく成果を測る

　メッセージ数が増えても、必要な情報を見つけられず再質問が増えただけかもしれません。トークン使用量も、AIが使われていることは示しますが、事業価値の証明にはなりません。DeLanghe氏は、利用量を導入状況の確認には使えても、仕事が良くなったかを示す単純なダッシュボードはないと述べています。

　導入初期は、利用者数や実行回数を「動いているか」の指標として残しつつ、回答までの時間、手戻り、会議準備時間、エスカレーションの見落とし、意思決定後の実行速度などを業務ごとに定める方法が現実的だと考えられます。たとえばClaude TagによるCI障害対応の事例では、初動時間という業務指標で効果を確認できます。

　最後に、導入は少人数の共有チャンネルから始めます。同じ資料を人とClaudeへ与え、成果物と判断を公開し、良い使い方を他のチームがコピーできる形にします。AIで同じ作業を速くするだけでなく、引き継ぎ、情報公開、役割、評価の設計をチームで変えることが中心になります。