何が変わったか

変更点は一言で言えば「判定の単位」です。従来のClaude Tagは、軽量な分類器がSlackの各メッセージを個別に評価し、返答するかしないかを二値で決めていました。Anthropicはこの分類器を丸ごと取り除き、Claude自身がチャンネルの全体文脈に加えて、自らのメモリと事前に与えられた常設指示を読んだうえで判断する方式に変えています。

選択肢も二値から4つに広がりました。その場で返信する、スレッドを立てて踏み込んだ作業を始める、既存のワークストリームにメッセージを振り分ける、そして何も言わない——の4つです。同社が挙げる例がこの設計思想をよく表しています。2人のエンジニアが同じバグを別々の角度から追っていて、どちらもClaudeに話しかけていない。1件ずつ読めばどちらも返答に値しないが、2つを重ねて読むと片方は仮説を持ち、もう片方は証拠を持っている。ここでClaudeは調査を走らせた状態でスレッドを開く、というわけです。

「黙る」を機能として実装した意味

注目すべきは、Anthropicが抑制を明示的に組み込んだ点です。何度試しても付け加える価値がないチャンネルでは、Claudeは休眠状態に入ります。同社は発表で「うるさいエージェントは、役に立たないエージェントより悪い」と述べています。

これは技術的な謙遜ではなく、プロダクト上の必然です。全社のSlackに常駐するAIが的外れな介入を繰り返せば、導入は数週間でミュートされて終わります。約30%という改善幅が「入るべき時」だけでなく「入るべきでない時」の判断も含む数字として示されているのは、そのためでしょう。

3つの前提が揃った、という主張

White氏はここ2年で3つの技術的な柱が揃ったと整理します。第一に接続性——Anthropicが2024年後半にオープン標準として公開したModel Context Protocol(MCP)で、2025年にはOpenAIとGoogleも採用しました。同氏はこれを「AIコネクタにおけるUSB-C」と表現します。第二にモデルの知能水準。複数のデータソースから点と点をつなぎ、「問題を見つけたので直せます」と自発的に言えるだけの水準に「ごく最近ようやく到達した」との認識です。第三にフォームファクタ——協働が既に起きている場所にClaudeを置くこと。Slack連携を「新種のパートナーシップ」と呼び、Claudeに独自の権限を持つフェデレーテッドなエージェントIDと、チャンネル認識、MCP経由の文脈を与えたと説明しています。

「タスク」から「ゴール」へ

White氏はAIの進化を3段階で捉えます。IDEでの1行補完やチャットボットへの回答といった「タスクの一部」、次に関数を書き切る・調査レポートを出すといった「タスク全体」、そして今は「プロジェクトやゴール」だと。「製品をバグのない状態に保つ」「NDAレビューを速くする」といった抽象度の高い目標を、バックグラウンドで各種データソースをつなぎながらエージェント的にループして追う段階だという主張です。

ここで同氏が引く線が重要です。ゴールは本質的に複数人を巻き込む。ところがナレッジワークには、ソフトウェア開発におけるGitやプルリクエストのような協働の足場が存在しない。しかもコードと違い、成果物の良し悪しがテストで自動判定できず、品質基準を満たしたかどうかの判断に人間が要る——だからこそ「散らかっている」と同氏は言います。Claude Tagの設計は、この足場を後付けする試みとして読めます。

数字が示す落差

もっとも、市場の実態は熱狂とは距離があります。McKinseyの最新調査では、88%の組織が何らかの業務でAIを使っていると回答し、62%がAIエージェントを少なくとも試験導入している一方、収益への影響があると答えたのは39%、大きな価値を得ている「ハイパフォーマー」に該当するのはわずか6%です。Deloitteは生成AI利用企業の25%が2025年にエージェントを導入し、2027年には50%に倍増すると予測しています。導入率と成果率のこの落差こそが、「単発のチャットボット」から「協働するエージェント」へ移る動機になっているとも言えます。

White氏自身が挙げる効果の例は、自分の業務です。以前はデータサイエンティストに依頼して1〜2日かかっていた分析が、今はClaudeで完結する。データサイエンティストは代わりに、Claudeの分析が常に正しくなるための基盤を作るようになった——役割が置き換わったのではなく上流に移った、という説明です。外部の実例としてはSRE(サイト信頼性エンジニアリング)を挙げ、エラーログを集め、直近のコード変更と関連するSlackの議論に結びつけ、統合した見立てを出し、必要な人を引き込む動きを説明しています。

セキュリティと課金の未確定領域

プロンプトインジ��クションについては多層防御を掲げます。分類器を組み込んだモデル側の訓練、企業が自社のリスク許容度を定義できるコンプライアンス・アナリティクスAPI、フックやDLP連携による third-party セキュリティベンダーとの協業です。Chrome拡張を一般提供せずウェイトリスト運用にしたのも、ブラウザ上のインジェクションリスクを理解するためで、そこで得たデータセットから新たな分類器訓練を行ったと述べています。権限については、エージェントが見えるものと要求したユーザーが見えるものの「最も制限的な交差」に収束し、あるチャンネルの文脈が別のチャンネルに漏れることはないとしています。

課金は未確定です。拡張されたチャンネル文脈は現時点でどのプランでも利用量・支出上限にカウントされませんが、White氏は将来課金対象になるかの言明を避け、顧客との共同設計を進める実験段階だと述べるにとどめました。代わりに強調されているのは制御です。エージェントIDやロールベースのアクセスグループに紐づく予算上限、チームごとに異なるコスト・性能プロファイルを選べるモデル権限といった仕組みが挙げられています。

競合構図

Slackを所有するのはSalesforceであり、MicrosoftはTeams全体にエージェントを埋め込みマルチエージェントのオーケストレーションを進め、GoogleもWorkspaceで同じ方向に動いています。この構図に対するWhite氏の反論は「価値はシステムとシステムの間にある」というものです。製品を改善するにはSalesforceの商談記録、Slackの社内議論、プロダクトツールの利用分析、開発環境のコードが要る——その全体像を単独で所有するベンダーはいない、と。オーケストレーターの座を狙う、という立ち位置の表明です。

💼 事業会社視点:これは自社にどう効くか

日本企業にとって、この動きは「AI導入」ではなく「Slack/Teamsのどちらを社内の協働基盤の中心に据えるか」という選択の問題に変わります。Claude TagはSlackに常駐し、MCPで他システムをつなぐ設計です。Slack中心のSaaS・スタートアップは今日から実験可能ですが、Teams中心の大手企業はMicrosoftのエージェント戦略との二者択一に直面します。まず決めるべきは、AIの常駐先をどのツールに置くかです。

受託開発・SIerには構造的な影響があります。White氏が語る「データサイエンティストが分析をやめ、Claudeの分析が常に正しくなる基盤を作る側に回った」という変化は、そのまま受託の商材転換を示唆します。分析代行や資料作成の人月は縮み、代わりにMCPサーバー構築、権限設計、社内データの整備といった「エージェントが正しく動く土台」が売り物になる。単価表の書き換えを今期中に始めるべき領域です。

ECや事業会社の役員が見るべき数字はMcKinseyの6%です。88%が使い、62%がエージェントを試すのに、収益影響を認めるのは39%、価値を出せているのは6%。差を生むのは導入の有無ではなく、Claudeが読む文脈の質——つまり社内Slackにどれだけ判断材料が書かれているかです。会議と口頭で決めている組織ほど、エージェントに与えられる文脈が薄い。導入前に「意思決定をテキストに残す」運用へ寄せることが、投資対効果を左右します。

加えて、拡張されたチャンネル文脈は現時点で利用量にカウントされないものの、将来の課金についてAnthropicは明言していません。PoCの予算計画は、現在の無償分が有償化される前提で組んでおくのが安全です。

関連リンク