Block「Buzz」— 人間と AI エージェントが同じ部屋に住む自己ホスト型ワークスペース¶
作成日: 2026-07-22 出典 / きっかけ: ITmedia(2026-07-22)「ジャック・ドーシー率いるBlock、AI時代のオープンソースプラットフォーム『Buzz』を開発」+ リポジトリ本体(github.com/block/buzz)の README/メタデータを直接確認 関連: cursor_agent_swarm_planner_worker経済性_整理 社内mcp共通基盤_認証認可ログ_整理 sign_off_layer_ai時代の承認とオーナーシップ_整理
0. 要点(3行)¶
- Buzz は Block(Jack Dorsey)の OSS で、実体は Nostr リレー。メッセージ・リアクション・ワークフロー・コードレビュー承認・git イベントの全てが「署名付きイベント1本のログ」になり、人間もエージェントも同じ鍵ペアモデルの「メンバー」として扱われる
- 狙いは「chat + forge + bot + CI ダッシュボード + リリースツール + 検索 + グルーコード」の7タブ状態を1つの基盤(one substrate)に置き換えること。エージェントは権限フラグでなくアイデンティティ(鍵)でスコープされ、人間と同じ監査証跡を残す
- 2026-03 リポ公開・v0.4.21・Rust 製・Apache-2.0・スター約2,000(2026-07-22 時点)。デスクトップ(Tauri+React)と
buzz-cli+ACP ハーネス(Goose / Codex / Claude Code 接続)は動作、モバイルや承認ゲートは開発中のアーリーステージ
1. 何であるか — アーキテクチャの芯¶
- 1コミュニティ = 1リレー(自己ホスト時)。URL がワークスペースを決める。ホスト型では1オペレーターが多コミュニティを提供可能
- 全てが署名付き Nostr イベント: 発言も、絵文字リアクションも、ワークフローの各ステップも、レビュー承認も、git のパッチ(NIP-34)も、同じ形・同じ ID モデル・同じ監査証跡
- エージェントは「メンバー」: 自分の鍵・自分のチャンネル所属・自分の監査証跡を持つ。「権限フラグで縛る bot」ではなく「チームメイトと同じスコープの仕方」— README 曰く "Agents are part of the room, not haunted cron jobs"
- git は NIP-34 イベント(パッチ・リポジトリ告知・ステータス)として流れ、git ホスティングバックエンドも同梱
┌──────────── Buzz コミュニティ(= Nostr リレー)───────────┐
│ 1本の署名付きイベントログ │
│ 発言 / リアクション / canvas / workflow / 承認 / NIP-34 git │
└──────────────────────────────────────────────┘
▲鍵A ▲鍵B ▲鍵C ▲鍵D
人間Alice 人間Bob エージェント workflow
(Goose/Codex/ (YAMLトリガ:
Claude Code) message/reaction/
schedule/webhook)
2. 現状の成熟度(README の三分類・2026-07 時点)¶
| ✅ 動く | 🚧 配線中 | 💭 構想 |
|---|---|---|
| リレー・チャンネル・スレッド・DM・canvas・メディア・検索・監査ログ | モバイル(iOS/Android、Flutter) | リレー横断の Web-of-Trust レピュテーション |
| デスクトップアプリ(Tauri + React) | ワークフロー承認ゲート(基盤あり・グルー乾燥中) | プッシュ通知 |
buzz-cli(agent-first・JSON in/out)+ ACP ハーネス(Goose / Codex / Claude Code) |
ハドル(音声)ライフサイクル | カルチャー機能 |
| YAML ワークフロー(message / reaction / schedule / webhook トリガ) | ||
| git イベント(NIP-34)+ git ホスティング |
- リポ事実(gh api 実測): Rust・Apache-2.0・2026-03-06 作成・スター 2,006・フォーク 158・最終 push 2026-07-22(活発)
- ITmedia 補足: v0.4.21、macOS/Windows/Linux 対応、buzz.xyz(ベータ参加募集段階)
- セットアップは Docker + Hermit(または Rust 1.88+ / Node 24+ / pnpm 10+ / just)。
just setup && just build→just dev
3. ユースケース(README の「三つの小話」が分かりやすい)¶
- インシデント記憶: 深夜2時に「このエラー前に見た?」と聞くと、チャンネル常駐エージェントが6ヶ月の履歴から該当スレッド・根本原因・修正を証拠付きで貼る。やり取り自体もチャンネルに残る
- ブランチ=部屋: feature ブランチを切るとチャンネルが生まれ、パッチ(NIP-34)・CI 結果・エージェントの一次レビュー・マージ判断が同じ部屋に集まる。「なぜこのコードが在るか」の記録がチャンネルそのもの
- 自分を書くリリース: タグでワークフローが発火 → エージェントがマージ済み PR からリリースノート起草 → 人間の👍リアクションが承認 → 出荷。全ステップ署名付き・検索可能
4. 考察(ここは自分の解釈)¶
- 一言でいうと「エージェント時代の Slack+GitHub を、権限でなくアイデンティティで作り直した」。エージェント統治の難所(誰が何をしたかの監査・権限の粒度)を、Nostr の署名イベントモデルに丸ごと乗せて解いている設計が最大の見どころ
- ITmedia の「Slack や GitHub との連携」という表現より、README の実態は置き換え志向(7タブ→1基盤)が強い。連携(ACP でエージェント接続・webhook)はあるが、思想は「グルーコードの否定」
- Dorsey の一貫路線(Nostr 支援・bitchat・goose)の集約点。自己主権(self-hostable・自分のリレー)× エージェント協働は、ベンダーロックインを嫌う組織には刺さる一方、Nostr 鍵管理を組織に持ち込む運用コストは未知数
- 自分の関心との接続: ワークフロー承認ゲート(🚧)は自分の「approved 入口ゲート」「PR merge 出口ゲート」運用と同型。人間の承認をリアクション(署名イベント)で表現する設計は、承認ログの一元化として参考になる。Cursor のスウォーム実験(プランナー/ワーカー分業)が「作る側の経済」なら、Buzz は「協働の場の構造」— 両者は補完関係
- 留保: スター 2,000 規模・v0.4 のアーリーステージ。💭 列(Web-of-Trust 等)は構想段階で、README 自身が「これを前提にコンプラ設計をするな」と明記
5. まとめ — いつ試すか¶
| 状況 | 判断 |
|---|---|
| いま本番導入 | 早い(v0.4・承認ゲート配線中) |
| エージェント監査・アイデンティティ設計の参考 | 読む価値大(VISION/ARCHITECTURE ドキュメントが厚い) |
| 個人で触る | just setup で自己ホスト可。Claude Code を ACP で繋げる点は要実験 |
参考リンク¶
- ITmedia 記事: https://www.itmedia.co.jp/news/spv/2607/22/news058.html
- リポジトリ: https://github.com/block/buzz (README / VISION.md / ARCHITECTURE.md)
- 公式サイト: https://buzz.xyz
- Block の既存 OSS エージェント goose: https://github.com/block/goose
- NIP-34(git stuff over Nostr): https://github.com/nostr-protocol/nips/blob/master/34.md
作成: 2026-07-22 / 最終更新: 2026-07-22