Block、AIエージェント協働OSS「Buzz」公開 — Nostr基盤でSlack依存を脱却

Blockが2026年7月21日、人間とAIエージェントが同じ場所で作業するオープンソース基盤「Buzz」を公開しました
分散型プロトコルNostrのリレーを自前で運用し、チャネルやDM、監査ログを手元に保持する設計です
Claude Code、Codex、Gooseに対応し、Apache-2.0で全体が公開されています

Buzzが公開された背景

米Blockは2026年7月21日、人間とAIエージェントが同じワークスペースで作業するためのオープンソースプラットフォーム「Buzz」を公開しました。公開時点のバージョンは0.4.21で、macOS、Windows、Linuxのデスクトップ環境に対応しています。ライセンスはApache-2.0で、GitHubから入手できます。

画面構成はチャネルとスレッド、ダイレクトメッセージを備えたSlackに近いもので、ここにキャンバスやメディア共有、検索、監査ログが加わります。開発チームが日常的に使うやり取りの場へ、AIエージェントを最初から住人として組み込む設計といえるでしょう。

Blockは決済サービスのSquareで知られる企業ですが、AIコーディングエージェント「Goose」をオープンソースで公開してきた実績もあります。Buzzはその延長線上にある、エージェント運用の受け皿にあたるプロダクトです。

Nostrを土台にした設計

Buzzの土台になっているのは、Nostrという分散型のメッセージングプロトコルです。中央の管理サーバーを置かず、リレーと呼ばれる中継サーバーが署名付きのイベントをやり取りする仕組みで、分散型SNSの用途で知られています。

Buzzはこのリレーを利用者自身が運用する前提で作られており、公式の説明でも「自分が所有するリレーの上で」という表現が使われています。会話ログもコード関連のイベントも、外部サービスのデータベースではなく手元のリレーに残る形です。メッセージの保持期間や利用条件に運用を縛られたくないチームにとっては、ここが導入判断の分かれ目になるはずです。

現時点で実装済みなのは、リレー、チャネル、スレッド、DM、キャンバス、メディア、検索、監査ログまでです。次の機能は開発中と位置づけられています。

iOS/Android向けモバイルクライアント（Flutter製）
ワークフローの承認ゲート
YAML形式によるワークフロー定義
NIP-34を使ったGit連携（パッチ送信、リポジトリ告知）

Git連携が完成すれば、コードレビューのやり取りまで同じリレー上で完結します。コードリポジトリの外部依存を減らすという狙いは、この部分の実装が前提になっている点に注意が必要でしょう。

鍵で管理する身元と権限

Buzzで目を引くのは、AIエージェントを人間のメンバーと同じ扱いにしている点です。エージェントは固有の鍵を持ち、その鍵で署名したイベントとして発言や操作を記録します。誰がどのエージェントとして何をしたのかを、後から追跡できる構造です。

基盤となるNostrの標準仕様のうち、Buzzはイベント形式を定めたNIP-01と、リレー接続時の認証を定めたNIP-42に準拠しています。メッセージ、リアクション、ワークフローの実行記録、Git関連のイベントに至るまで、すべて署名済みイベントとしてリレーに蓄積される仕組みです。監査ログもすでに実装済みの機能として提供されています。

従来のSaaS型チャットでは、エージェントの発言がボット用アカウントに集約され、どの実体が動いたのか曖昧になりがちでした。鍵の単位で身元を分ける設計は、複数のエージェントを並行して走らせる運用ほど効いてくるでしょう。

導入に必要な環境

対応するエージェントとして、BlockのGooseに加え、OpenAIのCodex、AnthropicのClaude Codeが挙げられています。入出力をJSONで扱うbuzz-cliと、ACP（エージェントとクライアントをつなぐ通信規約）およびMCP向けのbuzz-acpという2種類のハーネスが用意されており、手持ちのエージェントを差し替えて接続できます。

自前で構築する場合は、Hermit（開発ツールのバージョンを固定して自動取得するパッケージマネージャー）が使われます。必要な環境はRust 1.88以降、Node.js 24以降、pnpm 10以降に加え、コンテナ実行のDockerとタスク実行ツールのJustです。初回はjust setup && just buildを実行すれば準備が整います。

開発現場への影響

AIエージェントを実務に組み込む段階では、モデルの性能よりも「どこで人とエージェントを協働させるか」が課題になります。実行ログやレビュー、承認の記録をどこに残すか定まらないまま台数だけ増えると、運用は破綻しやすくなるためです。AIエージェントの設計パターンを検討する際にも、この置き場所の問題は避けて通れません。