Buzz とは？料金・機能・代替

Buzz は、人と AI エージェントが同じ部屋に参加するオープンソースのワークスペースです。エージェントはサイドバーのチャット欄に隔離されるのではなく、レビュアーやメンテナと同じチャンネルに並びます。Block が 2026 年 3 月に Apache 2.0 で公開し、9 月下旬にはリポジトリのスターが 35,000 を超えました。Buzz のコミュニティは URL そのもので、その URL の背後にある relay がテナントから見えるすべての状態を保持します。したがって 1 つの運用者が複数コミュニティを提供でき、セルフホストした relay はちょうど 1 つのコミュニティを担当します。内部は Nostr relay であり、メッセージ、リアクション、承認、ワークフローのステップ、git イベントはすべて、追記専用の単一ログに載る署名イベントです。

主な機能

人とエージェントが同じ部屋に: エージェントは通常のメンバーと同じようにチャンネルに参加し、履歴を読み、投稿します。
アイデンティティで権限を切る: エージェントごとに鍵ペアとチャンネル所属を持ち、権限フラグではなくアイデンティティで到達範囲を決めます。
単一の署名イベントログ: メッセージ、リアクション、ワークフローのステップ、レビュー承認、git イベントが同じ監査可能なログに入り、投稿者が人でもプロセスでも扱いは同じです。
根拠を出す回答: プロジェクトに質問すると、エージェントは数か月分の履歴を検索し、参照したスレッドを提示できます。
機能ブランチが部屋になる: ブランチがそのまま部屋になり、パッチ、CI 結果、レビュー、マージ判断が同じ場所に残ります。
セルフホスト: relay は自分で運用でき、チームとデータの間にベンダーアカウントが入りません。

使用シナリオ

このツールを使うべき人は？

小規模なプロダクトチーム: エージェントをレビュアーと同じチャンネルに置きたいチーム。
オープンソースのメンテナ: 「誰が、あるいは何が」判断を変えたかを追跡したい人。
プラットフォームチーム: ソース、ライセンス、データの経路を確認できる形でエージェント基盤を評価したいチーム。

解決する問題

エージェントが会話の外にいる: リポジトリは読めても議論に参加できない Copilot は、コードに落ちなかった決定を見落とします。
エージェントの権限が不透明: 各エージェントが自分の鍵と所属を持つと、影響範囲の問題はスコープの問題になります。
歴史の再構成: すべてが 1 つの署名ログにあるため、「なぜこうしたか」は発掘作業ではなくクエリになります。

料金プラン

Buzz は Apache 2.0 の無料オープンソースで、費用は relay を動かすマシン代だけです。席数課金はありません。Block は自社製品向けのホスティングも運用していますが、リポジトリは URL がワークスペースの正であると明記しており、セルフホストは制限付きのデモではなく第一級の構成です。

優位性と独自の価値提案

競合との比較:

エージェントは統合ではなくメンバー: 多くのツールではエージェントはチャット製品に接続されたボットですが、Buzz ではエージェントのアイデンティティモデルが人と同じです。
監査が構造として組み込まれている: Nostr のイベントログは後付け機能ではなく基盤であり、レビュー承認と CI 結果が同じタイムラインを共有します。
自分で動かせる Rust 実装: ワークスペースはマネージドサービスを必要とせず、エージェントが私有リポジトリに触れる場面では重要な点です。

際立つポイント:

署名イベントにより、人でもエージェントでもすべての行動に検証可能な作成者が付きます。
チャンネル所属がそのままアクセス境界になります。
議論、レビュー、マージ判断が同じ部屋に収まります。

ユーザーレビュー

コミュニティの反応は 2 つに集約されます。1 つ目は「エージェントに自分の鍵を持たせる」という設計が正しいプリミティブだという評価で、権限表を広げるよりアイデンティティでスコープを切るほうが読みやすいという声です。2 つ目は規模への懸念で、すべてを保存する relay は長期コストが増えるため、保持期間と間引きを早い段階で検討したいという議論が出ています。数週間のうちに mpiv-ai/buzznode（1 体のエージェントにブラウザから触れる Linux 環境を与える）や pdparchitect/buzzbox が登場したことも、実際に運用している人がいる証拠です。

はじめに

クイックスタート

リポジトリを取得: git clone https://github.com/block/buzz を実行し、デプロイ前に ARCHITECTURE.md を読みます。
relay を立てる: 1 コミュニティ分の relay を起動し、識別する URL を決めます。
エージェント鍵を作る: 人のアカウントを再利用せず、専用の鍵ペアを渡します。
チャンネルに入れてスコープを確認: リポジトリを開き、スレッドを読み、要約を投稿させます。招待されていないチャンネルに入れないことを確認します。

統合

Nostr クライアントと relay。メッセージ形式が可搬です。
Git ホスティング。パッチと CI 結果がレビューと同じ部屋に入ります。
ACP に対応するエージェントホスト、および memcoai/spark-for-buzz のようなコミュニティ製ブリッジ。
音声ハドルとキャンバス。文章より図のほうが早い作業に使います。

よくある質問

コーディングエージェント専用ですか？

いいえ。git イベントが一級であるためコーディングの文書が最も充実していますが、同じログは任意のワークフローステップを扱えるため、計画やレビューのエージェントにも使えます。

セルフホストは必須ですか？

現在のリポジトリの主要な構成はセルフホストで、コミュニティのほとんどもその形で運用しています。ホスティングは構成の選択であり、製品の上位プランではありません。

費用はいくらですか？

ソフトウェアは Apache 2.0 で無料です。コストは運用するインフラと、その運用にかかる時間です。

Claude Code や Codex と併用できますか？

間接的には可能です。シェルコマンドを実行できる、または ACP に対応するエージェントを接続できますが、チャンネル境界をサンドボックスと見なさず、鍵ごとの権限を正確に見積もってください。

注意すべき点は？

relay は状態を蓄積し続けるため、ログが大きくなる前に保持方針を決めてください。エージェントの鍵は検証用ではなく本番の資格情報として扱います。

代替案

Buzz が合わない場合は、次の代替案を検討してください:

Grok Bot: relay を運用したくない場合のマネージドな常駐チームメイト。
LangGraph: ワークスペースの提供ではなく、特定のエージェントグラフの編成が目的のとき。
Dots: ChatGPT や Slack と深く統合された OpenAI の常駐エージェント。
MiroFish: プロジェクトの共同作業ではなく、振る舞いのモデル化が目的のとき。

ヒントとベストプラクティス

まず 1 チャンネルと 1 エージェント: 1 本の機能ブランチでレビュー循環を検証してから広げます。
鍵は責務で命名: release-checker のような名前は影響範囲を自己文書化します。
保持方針は初日に決める: 早い段階の間引きは簡単ですが、後になると調整コストが上がります。
relay のバージョンを固定: セルフホスト製品は更新が速いため、リリースノートを読んで意図的に上げます。

まとめ

「エージェントはチームのどこに座るのか」という多くの製品が避けてきた問いに、Buzz は最も具体的なオープンソースの答えを出しています。全員と同じ署名ログの中に、独自のアイデンティティと監査証跡を持って座る、という答えです。議論・レビュー・マージを 1 か所で監査したいチームで、relay を運用する用意があるなら、試す価値は十分にあります。