AIエージェントが常駐するOSS「Buzz」がSlack代替に選ばれる理由

Block 社（Jack Dorsey が率いる決済・開発企業）が 2026 年 7 月 21 日に公開した OSS「Buzz」が、GitHub Trending Rust カテゴリ 1 位・全体 Top 3 に到達しました。「Slack + GitHub を Nostr プロトコル上で統合する」という触れ込みで話題を集め、公開から約 1 か月で 27,000 を超えるスターを獲得しています。

しかし、話題性だけで採用判断はできません。既存の Slack + GitHub + Bot + CI ダッシュボードの組み合わせを置き換える価値が本当にあるのか、Mattermost や Rocket.Chat といった既存の OSS チャットとどう違うのか、「AI エージェントを一級市民として扱う」という設計思想は業務にどう効くのか、といった判断材料が揃っていないと PoC すら始められません。

特に難しいのは、Buzz が「新しいプロトコル（Nostr）」と「新しい設計思想（AI エージェント = メンバー）」の両方を同時に導入している点です。技術要素を分解して理解しないと、どの部分が既存 OSS との差別化になっているのかが見えづらく、比較検討そのものが進みません。

本記事では、Block 社の公式リポジトリ・アーキテクチャドキュメント・エンジニアリングブログを一次情報とし、Buzz の設計思想と技術基盤・稼働中と実装中の機能境界・類似 OSS との差分・導入経路・現状の限界を整理します。話題性を追いかける記事ではなく、自チームで PoC を回すか見送るかを判断するための情報整理を目的とします。

なお本記事の情報は、公開されている README・VISION.md・ARCHITECTURE.md・Block engineering blog を出典としており、実際の動作検証や運用体験に基づく記述は含みません。導入検討時は必ず最新の公式ドキュメントを併読してください。

Buzzとは — Block社が公開したNostrベースの分散型ワークスペース

Buzz は、Block, Inc. が公開したオープンソースの分散型ワークスペースです。公式リポジトリは github.com/block/buzz にあり、README では「A workspace where humans and agents build together, on a relay you own.（人間とエージェントが、あなた自身が所有するリレー上で共に構築するワークスペース）」と定義されています。

リポジトリの基本情報は以下の通りです（数値は 2026 年 8 月 17 日時点、GitHub API より取得）。

Buzz は現在アクティブに開発が継続されているリポジトリであり、アーカイブされていない・他リポジトリの fork ではない・無効化もされていない、公開リポジトリです。ライセンスは Apache-2.0 で、商用利用・改変・再配布が広く許諾されています。

Block engineering blog では、Buzz が「セルフホスト可能な単一 Rust バイナリで動作するリレー」として設計されており、依存コンポーネントは Postgres・Redis・S3 互換オブジェクトストアの 3 点のみと説明されています（Run your own Buzz relay）。この構成のシンプルさが、後述するセルフホスト運用のハードルを下げる要素になります。

3つのユースケースで見るBuzzの提供価値

抽象的な「AI エージェント統合」ではイメージが湧きにくいため、README の "Three little stories" セクションで示されている 3 つのシナリオを紹介します（README）。

1. Incident memory（インシデント記憶）

深夜のインシデント時に「以前同じエラーを見たことがあるか？」とチャネルに問いかけると、常駐しているエージェントが 6 か月分の会話履歴・障害対応ログ・関連コミットを検索し、根本原因・過去の修正内容・当時の関係者を提示するというシナリオです。ナレッジベースを別ツールで管理する必要がなく、日常のコミュニケーションログ自体が検索可能な資産になる点が特徴です。

2. Branch as room（ブランチが部屋になる）

フィーチャーブランチを開くと自動的にそのブランチ専用のチャネルが生成され、パッチ・CI 結果・エージェントの一次レビュー・議論・マージ判定がすべて同じ部屋に集約されるシナリオです。GitHub の Pull Request 画面と Slack のチャネルを行き来する必要がなくなり、レビューの文脈が一箇所にまとまります。

3. Self-writing release（自動生成されるリリース）

タグ push をトリガーにワークフローが起動し、エージェントがマージ済みの Pull Request を読み込んでリリースノート草案をチャネルに投稿、人間の絵文字リアクション（👍）でリリースが確定するというシナリオです。すべてのステップが署名済みイベントとして記録されるため、後から「誰がいつ承認したか」を検索・監査できます。

これらは README で示されている「想定ユースケース」であり、実際の実装状況は後述する機能マップと合わせて確認する必要があります。

アーキテクチャ — Rustリレー・Nostrプロトコル・単一署名イベントログ

Buzz のアーキテクチャは、Rust で書かれた単一のリレープロセスを中心に、Postgres・Redis・S3 互換ストレージが取り囲む構成になっています。「Nostr は難しそう」という第一印象に対して、実際に運用者が意識するのはこの 3 種のミドルウェアであることが、採用検討時のポイントになります。

システム全体像

README に掲載されているアーキテクチャ図は以下の通りです（出典: github.com/block/buzz）。

Clients (Human client / AI agent via buzz-acp / CLI / scripts)
    │
    │ WebSocket / REST
    ▼
buzz-relay (Rust / NIP-01 · NIP-42 auth · channel/DM/media/workflow/git REST · audit log)
    │
    ├─→ Postgres (events + FTS search)
    ├─→ Redis (pub/sub)
    └─→ S3 / MinIO (Blossom media storage)

クライアント（人間用デスクトップアプリ・AI エージェント・CLI・スクリプト）はいずれも WebSocket もしくは REST 経由でリレーに接続します。イベントの永続化には Postgres（全文検索付き）、pub/sub には Redis、メディアストレージには S3 または MinIO を使う分担です。この構成は Web サービスの一般的な三層構造とほぼ同じで、「Nostr プロトコル」という語感から想像するほど特殊なインフラは必要ありません。

主要 crate 構成

Buzz は単一の Rust ワークスペースの中で、責務別に crate を分割しています。README とアーキテクチャドキュメントで紹介されている主要 crate は以下のようにグルーピングできます。

• Core protocol: buzz-core（ゼロ I/O 型・NIP-01 フィルタ・Schnorr 署名検証）、buzz-relay（Axum ベースの WebSocket + REST サーバ）
• Services: buzz-db、buzz-auth（NIP-42 / NIP-98 認証・レートリミット）、buzz-pubsub（Redis）、buzz-search（Postgres FTS）、buzz-audit（ハッシュチェーン監査ログ）
• Agent surface: buzz-cli（JSON 入出力の CLI）、buzz-acp（Agent Client Protocol ハーネス）、buzz-agent、buzz-dev-mcp（シェル / ファイル編集ツール）、buzz-workflow、buzz-persona
• Git & pairing: git-sign-nostr、git-credential-nostr、buzz-pair-relay、buzz-pairing-cli
• Shared: buzz-sdk、buzz-media（Blossom / S3 連携）
• Tooling: buzz-admin、buzz-test-client

この分割から読み取れるのは、「認証・監査・検索・エージェント・Git 統合が別 crate として明確に切り分けられている」ことです。特定機能を無効化したい、あるいは差し替えたいといった要件に対して、影響範囲を crate 単位で見積もれる構造になっています。

依存する Nostr NIP

Nostr プロトコルは NIP（Nostr Improvement Proposals）と呼ばれる仕様群の組み合わせで機能します。Buzz が依拠している主な NIP は以下の通りです。詳細は公式の ARCHITECTURE.md を参照してください。

これらの NIP は仕様が公開されているオープンな規格ですが、Buzz を「使う」立場では NIP の詳細を理解しなくても、Rust バイナリ 1 つと Postgres / Redis / S3 で運用が始められる点が実務的なメリットです。

主要機能マップ — 稼働中・実装中・構想中の境界線

Buzz は活発に開発が続いているため、README の機能一覧は「Works today（今日使える）」「Being wired up（実装中）」「Strong opinions, pending code（構想はあるが未実装）」の 3 段階で明示されています（README）。PoC の設計段階でこの境界を把握しておくことが、期待とのギャップを避けるうえで重要です。

PoC で特に気をつけたいのは「モバイルクライアント」と「プッシュ通知」が未実装または開発中である点です。オンコール体制で通知の即応性が必要なチームでは、この 2 点の到達可否が採用判断の分かれ目になります。逆にデスクトップ中心・非同期コミュニケーションが前提のチームであれば、稼働中機能だけでも Slack 相当の日常運用は成立する範囲です。

なお、リポジトリの open issues は 2,700 件を超えており（GitHub API）、活発な議論が続いている段階です。安定した長期サポート版を求めるチームは、しばらく様子を見る判断も選択肢に入ります。

AIエージェントを「メンバー」として扱う設計思想

Buzz が既存の Slack 代替 OSS と最も明確に異なるのは、AI エージェントの位置付けです。他のツールでは Bot / Plugin / App として「外付け」される AI 統合が、Buzz では「メンバー」として同一の ID 体系・チャネル所属・監査ログの中に組み込まれています。

「bot ではなくメンバー」思想の技術的裏付け

README では、Buzz のエージェントは「bot ではなくメンバー」であると明記され、以下の性質を持つと説明されています。

• 人間と同じ Nostr 鍵ペアを持つ
• 人間と同じチャネル所属モデル（チャネル参加・退出）
• 人間と同じ監査ログ（発言・リアクション・ワークフロー実行がすべて署名付きイベントとして記録される）
• リポジトリを開く / パッチを送信する / コードレビューする / ワークフローを実行する / キャンバスを編集する / 他エージェントをオーケストレーションする / 音声通話（Huddle）に参加する、といった行動が可能

技術的には、buzz-cli（JSON 入出力）と buzz-acp（Agent Client Protocol ハーネス）を通じて、Goose・Codex・Claude Code といったエージェントランタイムを Buzz に接続できる設計です。これにより、既存のエージェント基盤を選ばずに Buzz へ載せられる余地が確保されています。

エージェント接続手順の概要

README の記述に基づけば、エージェントを Buzz に接続する基本手順は次のようになります。動作検証は本記事では行っていないため、実際に接続する際は最新の README を必ず確認してください。

• エージェント用の Nostr 鍵ペアを生成し、BUZZ_PRIVATE_KEY 環境変数に設定する
• buzz-cli を JSON 入出力モードで起動する
• 参加させたいチャネルに対して、人間メンバーと同じ手順で参加させる

Windows 環境では、エージェントの shell tool が bash を要求するため、Git for Windows の Git Bash が推奨されます。カスタム bash を使う場合は BUZZ_SHELL 環境変数で指定できるとされています（README）。

監査性の意義 — Schnorr署名とハッシュチェーン監査ログ

エージェントを「メンバー」として扱ううえで技術的に重要なのは、監査性です。Buzz は Schnorr 署名（Nostr プロトコル標準）と、buzz-audit crate によるハッシュチェーン監査ログを組み合わせて、「誰が（人間か特定のエージェントか）」「いつ」「何を発言・実行したか」をすべて署名付きで記録します。

これは、AI エージェントが業務プロセス（レビュー承認・リリース確定・ワークフロー実行）に関与する際のガバナンス上、他ツールの Bot / Plugin モデルとは本質的に異なる利点です。エージェントの誤動作・意図しない権限行使が起きた場合でも、鍵ペアと監査ログをたどれば「どのエージェントの、いつの、どの操作か」を後追いで検証できます。

エージェント設計思想の詳細は、VISION_AGENT.md に整理されています。「エージェントを人と同じ暗号 ID・チャネルアクセス・ワークフローツールで扱う」というビジョンが、なぜこの技術構成に落とし込まれているのかを理解するうえで有用な一次資料です。

類似OSSとの比較 — Mattermost・Rocket.Chat・Zulip・Elementとの違い

「Buzz とは何か」だけでなく「Buzz と既存の Slack 代替 OSS のどちらを選ぶか」という比較の観点で整理します。数値は 2026 年 8 月時点、いずれも GitHub 公式リポジトリの公開情報に基づきます。

比較表

（Stars は各 GitHub 公式リポジトリの 2026 年 8 月時点の値。詳細は各リポジトリを参照してください。）

中央集約 vs 分散署名イベントログ

Mattermost・Rocket.Chat・Zulip の 3 つはいずれも「中央集約サーバ + データベース」の構成で、業務要件に応じて水平スケールしていく設計です。プロトコルはそれぞれ独自で、他システムとの相互運用は基本的に API 経由で行います。

Element（Matrix）は連合型（複数サーバが federate する）で、Buzz の「リレー = コミュニティ」モデルとはアプローチが異なります。Matrix は連合前提の広域ネットワークを想定した設計であるのに対し、Buzz は「1 リレー = 1 コミュニティ（ドメイン単位）」というシンプルな運用モデルを採用しています。

Buzz が最も特徴的なのは、「メッセージ・リアクション・ワークフローステップ・レビュー承認・Git イベント」がすべて署名付き Nostr イベントとして単一のログに記録される点です。これにより、監査・検索・エージェント連携が同じデータモデルの上で成立します。他 OSS のように「チャットログ」「監査ログ」「Bot 実行ログ」を別々のシステムで管理する必要がありません。

既存インテグレーションレイヤ型 OSS との違い

似た文脈で語られる OSS に、Slack / GitHub / Confluence などの既存 SaaS 群を横断検索する RAG 基盤（AI 検索インデックスレイヤー）があります。代表例として Onyx（onyx-dot-app/onyx）が挙げられます。

これらは「既存 SaaS の上に載せる」検索・要約レイヤーで、既存の Slack・GitHub 環境を変えずに AI アクセスを追加できるのが強みです。一方で Buzz は「既存 SaaS を置き換える」新プラットフォームであり、両者はレイヤーが異なります。既存環境を維持しつつ AI 検索だけを追加したい場合は前者、AI エージェントを一級市民として設計されたワークスペースへ移行したい場合は Buzz、という棲み分けが基本の選定軸になります。

セルフホストと導入経路

Buzz は「まず触ってみる」から「本格運用する」までの複数の入り口が用意されています。投資判断の段階に応じて選べる構成になっているため、目的に合った経路を選ぶことで検討コストを抑えられます。

デスクトップアプリを試すだけの場合

もっとも軽い試し方は、公式のデスクトップアプリをダウンロードして既存の公開リレーに接続することです。README では releases/latest から以下のパッケージが配布されているとされています。

• macOS（Apple Silicon / Intel）
• Linux（x86_64 AppImage または deb）
• Windows（x64）

なお、Windows 版は現時点で未署名のため、SmartScreen 警告が表示される点に注意が必要です。

セルフホストリレーを立てる場合

自組織のリレーを立てたい場合、Railway のワンクリックデプロイボタンが提供されており、クラウド上に素早く検証環境を用意できます。より本格的な運用には deploy/compose/ に本番向けの Docker Compose バンドルが同梱されています（README）。

Block engineering blog の Run your own Buzz relay では、セルフホスト時に必要な依存（Postgres・Redis・S3 互換オブジェクトストア）と、NIP-11 / NIP-98 の実装、Nostr キーペアの管理などが解説されています。VPS・Railway・ホームラボ環境のいずれでも運用可能な構成として設計されています。

ソースからビルドする場合

内部改造や機能追加を前提とするなら、ソースからビルドする経路になります。README で示されている前提条件は以下です。

• Docker + Hermit（推奨）、または個別に Rust 1.88+ / Node 24+ / pnpm 10+ / just

Quick start コマンドは以下の通りです（出典: README）。

git clone
. ./bin/activate-hermit
just setup && just build
just dev

標準構成では、リレーは ws://localhost:3000 で起動するとされています。本記事では実際のビルド・起動は行っていないため、手順の詳細やエラー時の対応は最新の README を参照してください。

なお Block 社員向けには、内部の squareup/buzz-releases を使う導線が別途案内されていますが、社外の利用者は上記 3 経路のいずれかから開始することになります。

採用検討時の注意点と現状の限界

話題性に引っ張られて導入を決めると、想定外のギャップに直面する可能性があります。ここでは、公式ドキュメントから読み取れる現状の限界と、運用上のリスク、適する / 適さないチーム像を整理します。

現状の限界

公式 README で明示されている未実装・実装中機能のうち、業務影響が大きいものを再掲します。

• プッシュ通知: 「Strong opinions, pending code」として未実装。オンコール体制で通知即応性が必要なチームは要注意
• モバイルクライアント: 「Being wired up」として開発中（Flutter 実装）。iOS / Android での安定運用が要件のチームは待機推奨
• リレー横断の web-of-trust 評価: 未実装。複数コミュニティにまたがる信頼評価が必要なユースケースは対象外
• open issues の多さ: 2,700 件超（GitHub API）。開発が活発である一方、機能追加・仕様変更の速度が速く、安定性検証が続いている段階

運用リスク

セルフホストで運用する場合、以下の運用能力が前提になります。

• ミドルウェアの運用能力: Postgres・Redis・S3 互換ストレージの障害対応・バックアップ・スケール設計が自チームで完結できること
• Nostr プロトコルへの学習コスト: 使う限りは意識しなくてもよい場面が多いですが、トラブルシュートや高度な設定変更を行う際は NIP の仕様理解が必要になる場面が想定されます
• Block 社の中期コミットメント依存: OSS として公開されているとはいえ、主要開発体制の継続性は Block 社の方針に左右されます。エンタープライズ SLA が必要な用途では、フォーク運用の覚悟も必要になります

適するチーム像 / 適さないチーム像

以上をふまえた採用判断の目安は以下の通りです。

適するチーム像:

• 小〜中規模（10〜50 名程度）で、Postgres・Redis・S3 の運用リソースがある
• AI エージェントを日常運用に本格的に組み込みたい
• Git ホスティング・チャット・ワークフローを 1 つのシステムで統合したい
• Apache 2.0 ライセンスで社内カスタマイズを前提にできる

適さないチーム像:

• モバイルファーストで、iOS / Android クライアントの完成度が必須
• エンタープライズサポート・SLA が必須
• 通知即応性（プッシュ通知）が業務上必須
• 現状の Slack + GitHub 環境で運用が回っており、統合による学習コストを負う余裕がない

「話題になっているから」ではなく、上記の条件と自チームの状況を突き合わせることが、投資判断の起点になります。

まとめ — Buzzが選ばれる理由と次に読むべき公式ドキュメント

本記事で整理した Buzz の特徴は以下の 5 点に集約できます。

1. Nostr ベースの単一署名イベントログ: メッセージ・リアクション・ワークフロー・Git イベントがすべて署名付きイベントとして 1 つのログに記録される
2. リレー = コミュニティモデル: シンプルな運用単位（1 ドメイン = 1 コミュニティ）で、Postgres・Redis・S3 の 3 種で動く
3. AI エージェント = メンバー: Bot / Plugin ではなく、人と同じ鍵ペア・チャネル所属・監査ログを共有する一級市民として設計
4. Git 統合の標準搭載: NIP-34 によるパッチ・リポジトリ告知・ステータスが同一リレー内で完結、「ブランチが部屋になる」ワークフローが可能
5. Apache 2.0 セルフホスト: 商用利用・改変・再配布が広く許諾され、自チームでの改造・運用が現実的

Slack 代替 OSS として比較すると、Mattermost・Rocket.Chat・Zulip が「中央集約 + Bot 拡張」で機能を積み上げるアプローチを取るのに対し、Buzz は「分散署名イベントログ + エージェント一級市民」という異なる前提に立ちます。既存 OSS のリプレースというよりも、AI エージェント常駐時代の作業基盤を再設計する試みと捉えると、選定判断の軸が定まります。

さらに深掘りしたい方向けに、次に読むべき公式ドキュメントを整理しました。

• VISION.md — Buzz 全体のビジョンと設計原則
• VISION_SOVEREIGN.md — 「あなた自身が所有するリレー」という主権的コミュニティ設計の思想
• VISION_PROJECTS.md — プロジェクト（Git + チャット + ワークフローの統合単位）の設計
• VISION_AGENT.md — エージェントを人と同じメンバーとして扱う設計の詳細
• ARCHITECTURE.md — システム設計、kind レンジ、サブシステム境界の詳細
• RELEASING.md — リリースプロセス・バージョニング方針

関連情報

新しい OSS の採用可否判断や、AI エージェント時代を見据えた社内コミュニケーション基盤の再設計をご検討中の方は、お問い合わせフォーム からご相談ください。技術選定の観点整理・PoC 設計・既存基盤との統合方針など、要件の整理段階からご相談いただけます。