3 ポイント 投稿者 GN⁺ 2026-03-07 | 1件のコメント | WhatsAppで共有
  • 企業コラボレーションの中核ツールである Slackの閉鎖的なデータポリシー が、企業知識へのアクセスを妨げている
  • Claude は優れたAIツールだが、グループ会話機能がなく、実際の業務コラボレーションには限界がある
  • Slackは データアクセス制限と高額な価格設定 により、企業顧客にとって不合理な構造を提供している
  • Anthropicがオープンなデータアクセスと相互運用性を保証した「NewSlack」 を作れば、Slackの代替になり得る
  • これは 企業データエコシステム全体の開放性とイノベーション を促進できる決定的な契機である

Slackの限界と新たな必要性

  • Slackはメールや会話を置き換える 主要なコラボレーションプラットフォーム であり、企業の質問、議論、意思決定はすべてここで行われる
    • このメッセージ記録は、会社の 集合知(tribal knowledge) を蓄積した形である
    • しかし、この知識は 閉鎖的なデータアクセス方針 のために閉じ込められている
  • このような状況において 新しいSlackが必要 であり、その適任者として Anthropic が挙げられている

Claudeの限界:グループ会話の欠如

  • Claude は現在 1:1の会話のみ対応 しており、実際の業務のように複数人が参加するグループコラボレーションには不向きである
    • Slackスレッドの文脈をClaudeに伝えるには、コピー&ペースト を繰り返さなければならず非効率が生じる
  • Claudeと Claude Code はSlack内で 対等な会話参加者 として動作すべきである
    • しかし、Slackの データアクセス制限 によって統合は不可能な状態である

Slackのデータポリシーの問題

  • 多くの企業の 中核的なテキストデータ保存先 がSlackにあり、これは会社運営のリアルタイム記録である
  • Slackのデータアクセスポリシーは事実上 「不許可(No)」 に近く、AIエージェントが活用できない構造 になっている
  • 企業向けソフトウェアが オープンAPI を提供する理由は顧客要望と競争にあり、
    競争こそがSlackの閉鎖性を変える唯一の方法 として示されている

Slackの脆弱性と価格の問題

  • Slackが ネットワーク効果によって盤石である という認識は誤りだと指摘されている
    • Slack Connectチャンネルは一部パートナーとの接続にすぎず、代替可能性 がある
  • Claudeが統合された新しいSlack は、既存のSlackのネットワーク効果を相殺するほどの利点になり得る
  • Slackは Enterprise+プラン が必要で 過度に高額 であり、
    FivetranはSlackのコストが G Suite全体のコストと同程度 だと明かしている

NewSlackとClaudeの結合可能性

  • NewSlack + Claude のバンドルは、全従業員に提供する価値のある組み合わせとして提示されている
    • AI利用頻度が低い従業員も 標準シート料金プラン で含めることができる
  • AI懐疑派 も、グループチャット内で同僚がClaudeを活用する様子を見ながら自然に参加できる
  • Anthropicが オープンなデータアクセスと相互運用性 を保証するなら、
    Slackの閉鎖的なエコシステムを転換させる潜在力 を持つ

オープンなデータエコシステムへの転換

  • NewSlackは過去の失敗を繰り返さず、公開されたデータアクセスの約束 を行うべきである
  • Anthropicは 原則を守る企業としての信頼 をすでに確立している
  • Anthropicが成功するSlack代替を構築できれば、
    企業データエコシステム全体の開放性とイノベーション を促進できる
  • 結論として、「Slackは閉鎖的データのワーテルローになるだろう」 とされ、
    Anthropicが新しいSlackを作るべきだという要求 で文章は締めくくられている

1件のコメント

 
GN⁺ 2026-03-07
Hacker Newsのコメント
  • これは本当にとんでもないたとえに思える
    電力会社が電気を運ぶからといって、人も運べるはずだと考えるようなものだ
    もしそんなに簡単なら、とっくに Teams はまともになっていただろうし、Matrix が主流になり、Discord は別のコミュニティに置き換えられていたはずだ

    • もし彼らが**「魔法のアプリ製造機」**を売るなら、それでアプリを作ってくれと頼むのは別におかしくない気もする
    • Matrix が主流になっただなんて、Teams のレベルが地下1000フィートなら Matrix はせいぜい地上1〜2フィート程度だ
      自分も好きになりたいが、数か月おきにまた試してみても、いまだに準備不足な感じがする
    • 2001年に検索会社に対して、メールクライアント、ブラウザ、地図アプリを作れと言ったのと何が違うのかと思う
    • Slack ももともとはゲーム会社で、偶然チャット会社になったんじゃなかったっけ
    • 実際、電力会社の中には鉄道会社も兼ねていたところがあった
      私の地域の電気鉄道会社もかつて電気を販売していて、社名に “and Light” を付けていた時代があった
  • Slack の**データポリシーが「No」**であることが、むしろ企業が安心して使う理由でもある
    それを変えたら、その信頼も一緒に失われるだろう

  • なぜ Anthropic に頼むのか分からない
    むしろMatrix、Signal、Keybaseのようなオープンなシステムの上に構築した方がいいと思う
    Slack や Discord から抜け出すべきだという点には同意するが、特定企業に依存すれば同じ失敗を繰り返すことになる
    私たちが作るシステムは**ハック可能性(hackable)**を前提にしているべきだ

    • Slack 内のClaude 統合は、すでに十分強力な機能だ
      ただ、オープンであるだけではユーザーを引き付けにくいので、Anthropic がこれを計画しているならデータの開放性も含めてほしい
    • Anthropic が欲しいのはメッセンジャーではなく、マルチユーザー中心のプロンプトシステムのように見える
    • 記事を読んでみたが、結局のところ欲しいのはマルチユーザー Claude セッションという話だ
      でもその中で人々が互いに会話し始めたら、結局それは Slack になる
    • Matrix は面白くないし、そのうえ Anthropic の**稼働率(アップタイム)**もあまり良くない
  • 企業の CEO ブログにこんな記事を載せるのは妙だ
    AI があまりに簡単にコンテンツを作れてしまうせいで、**「なぜ作るのか」**を問わなくなった結果のように見える
    なぜ Fivetran が Slack がイマイチだという公開書簡を書く必要があるのか疑問だ
    LLM がなければ、書いている途中で「これは公開する価値がない」と気づいていたはずだ

    • これは以前 AI Substack で回っていた**“Why OpenAI Should Build Slack”**記事の焼き直しだ
      単に AI トレンドに便乗したいだけのコンテンツにすぎない
      元記事リンク
    • でもその記事は私が自分で書いた
    • しかもその CEO はデータ業界で顧客対応が最悪なことで有名だ
      Fivetran はユーザーから悪名高い
  • みんな Slack や Teams を嫌っているのに、いまだにより良いグループチャットを誰も作れていないという事実の方がむしろ驚きだ

    • それでも Google は諦めず、自社アプリにチャット機能を何十回も追加してきた
  • 「ダサくない Slack」なんて存在しない
    Anthropic がそれを作れると信じるのは現実が見えていない
    Slack は組織間の結び付き(lock-in)があまりに強い
    人々を移行させるには、今より
    10倍優れたコラボレーションモデル
    を作り、それがより良いと納得させなければならない
    それでも挑戦する人たちには幸運を祈る

    • Google が Messenger でもこれを実現できなかったのが理解できない
      うちの会社でも外部パートナーの大半は Gmail や Google Workspace でログインしている
    • 以前、AI ベースの Slack 代替サービスを宣伝していた人がいたが、コミュニティの反応はかなり良かった
    • 実際のところ、ソーシャル機能と生産性は相反する方向にある
      Slack や Teams が失敗するのも、この二つを無理やり混ぜようとしているからだ
  • Slack は完璧ではないが、意図された通りに動作している
    すでにボットや AI エージェントで拡張することも可能だ
    うちの会社では規定上、すべてのメッセージを保管アーカイブするツールを使っている
    大企業ならこのプロセスをもっと精緻に運用しているはずだ
    だから聞きたい――これは何の問題を解決するのか

    • Slack のAPI 制限と設計のせいで、データを外部ストレージに複製しづらく、
      AI エージェントが文脈を活用しにくい
    • 公開チャンネルのデータにしかアクセスできず、それも大規模アクセスが不可能
      Slack は Claude のような AI を深く統合することを決して許さないだろう
    • Slack はユーザー1人あたり月45ドルだが、
      まもなく完全にカスタマイズ可能な版を月2万ドル程度で自前構築できるようになるだろう
      従業員が多いなら、こちらの方が合理的だ
  • Zulipを試してみることを勧める
    Slack からの移行も簡単で、メッセージ、ファイル、ユーザーをそのまま移せる

    • でも Zulip は Slack と比べものにならないほど不安定で、しょっちゅうクラッシュする
  • Mattermostも最近はかなり良い
    公式サイト

    • 私も長いこと Mattermost インスタンスを運用していたが、
      最近のバージョンでセルフホストのメッセージ数制限を入れてしまってがっかりした
      結局、週末の間に自分で代替品を作ってしまい、オープンソースで公開しようとしてやめた
      だから今は Mattermost を勧めにくい
  • Slack のデータアクセス方針が「No」だというのはその通りだが、
    肝心のその問題を扱うブログ記事には具体的な説明がない

    • 実際、Slack はAPI によるメッセージ抽出を許可しておらず
      データを完全に**囲い込み(walled garden)**の中に閉じ込めている