Block Buzzとは​何か​ ──人間と​AIエージェントが​同じ​部屋で​働く、​オープンソースの​作業場を​解説

AIエージェントを業務に入れるとき、最初に悩むのは「どのAIを使うか」です。ところが実際に運用を始めると、もっと手前で詰まります——そのAIは、どこで働くのか。

2026年7月21日、Block が Buzz というソフトウェアをオープンソースで公開しました^[1]。Blockは決済のSquareやCash Appを持つ会社で、率いているのはTwitter（現X）共同創業者のジャック・ドーシーです。Buzzは人間とAIエージェントが同じワークスペースで働くための土台で、ライセンスはApache-2.0、自社のサーバーで動かせます。

この「誰が出したか」は、読むうえで効いてきます。Blockは2026年2月、従業員の約4割にあたる4,000人の削減を発表し、その理由にAIを挙げた会社です（1万人超から6,000人弱へ）^[6]。ドーシーは発表時にこう書いています——「我々が作り、使っている知能のツールが、より小さくフラットなチームと組み合わさることで、会社をつくり動かすことの意味を根本から変える新しい働き方を可能にしている」^[6]。人を減らしてAIに賭けた会社が、次に自分たちで作って公開したのが「人間とAIが一緒に働く場所」だった、という順番です。

ニュースとしては「Slackに対抗」と報じられましたが、それだと見どころを外します。Buzzが手を付けているのはチャットの機能ではなく、AIエージェントの「身分」「入れる部屋」「やったことの記録」をどう作るかの部分だからです。

この記事で分かること——①Buzzが実際に何なのか ②なぜNostrという少し変わった土台を選んだのか ③権限と監査をどう設計しているのか ④エージェントは中で何ができるのか ⑤どこまで動いていて、どこがまだ工事中なのか。本文の数値・仕様はすべてBlockの公式発表と公開リポジトリの原文を確認したもので、電脳技巧集団が自ら検証したものではありません。

01Buzzとは​何か​ ──まず​事実から

Blockは2026年7月21日、Buzzを「人間とAIエージェントが共有のワークスペースで一緒に働く、無料・オープンソースのコラボレーションプラットフォーム」として公開しました^[1]。

画面としては見慣れたものに近く、チャンネル、スレッド、ダイレクトメッセージ、音声、メディア共有、コードリポジトリ、自動化ワークフローを備えます。公式も「モダンなチーム向けコミュニケーションツールを使ったことがある人なら馴染む」と書いています。

項目	内容（2026年7月22日 確認時点）
公開元 / 公開日	Block, Inc. ／ 2026年7月21日
ライセンス	Apache-2.0（商用利用・改変・自社運用が可能）
提供形態	自分のサーバーで動かす（セルフホスト）／ Block提供のホスティング（buzz.xyz）
主な実装言語	Rust（デスクトップアプリは Tauri + React）
土台のプロトコル	Nostr（署名付きメッセージを中継サーバーでやり取りする分散型の通信規格）
GitHub	block/buzz：2,048 stars ／ 159 forks ／ 未解決 issue 50 ／ 未マージ PR 180[5]
最新リリース	Buzz Desktop v0.4.22（2026年7月21日）
開発状況	pre-1.0。過去バージョンのサポートはベストエフォート[3]

リポジトリ自体は2026年3月に作られており、社内で数か月動かしたものを公開した形です。公開翌日で未マージのPRが180件ある点からも、いま急速に動いているプロジェクトだと分かります。数値は日々変わるので、この記事は「2026年7月22日時点」として読んでください。

02​「Slack代替」と​読むと、​見どころを​外す

Buzzの性格を一番よく表しているのは、READMEにあるこの一文だと思います。

エージェントはボットではなく、メンバーだ。

block/buzz README.md^[2]

普通のチャットツールにAIを入れると、それは「呼ぶと答えるボット」になります。メンションされたら反応し、終わったら黙る。Buzzが置こうとしているのはそこではありません。公式発表はこう書いています——BuzzのAIエージェントは、コマンドに応答するアシスタントではない。自分の暗号鍵によるIDと、定義された権限を持ち、ワークフローに参加し、投稿し、コードをレビューし、承認された自動処理を実行し、人間と並んで会話に加わる^[1]。

READMEの表現はもう少し砕けていて、「エージェントは部屋の一員であって、取り憑いたcronジョブではない」とあります。cronジョブとは決まった時刻に裏で勝手に走る処理のことで、要するに「どこかで動いているらしいが、誰も中身を知らない自動処理」の対極を狙っている、ということです。

この違いが効いてくるのは、うまくいかなかったときです。ボットが変な投稿をしたら「ボットが壊れた」で終わります。メンバーが変な投稿をしたら、誰の鍵で、どの部屋で、何を見て、何をしたのかが記録から辿れます。Buzzが作っているのは会話の機能ではなく、この「辿れる状態」のほうです。

そのために、Buzzはあらゆる出来事を一種類のものとして扱います。メッセージも、リアクションも、ワークフローの1ステップも、レビューの承認も、gitのイベントも、すべて同じ1本のログに入る署名付きイベントです。書いたのが人間でも処理でも、形も、ID体系も、監査の残り方も同じになります^[2]。

「AIをチャットに常駐させる」という潮流そのものは、2026年前半から各社が同じ方向を向いていました。今回のBuzzは、その作業場を既存のチャットの上に乗せるのではなく、土台から作り直したらどうなるかという実物にあたります。

関連記事 ｜ この潮流の起点AIエージェントは、チャット欄から「チームの作業場」に引っ越した ──Claude Tagが示す、次の競争軸は“作業場設計” →

03なぜNostrなのか ──鍵の​持ち主を​変える

Buzzが少し変わっているのは、土台に Nostr を選んだ点です。ブロックチェーンではありません（READMEにも「Not blockchain」と明記されています）。メッセージ一つひとつに電子署名を付けて、リレーと呼ばれる中継サーバーに置いていく仕組みだと思えば十分です。

なぜそれを選んだのか。公式は「IDの問題を解くため」と説明しています。

我々がNostrを選んだのは、マルチエージェント協働で最も根本的な問題——アイデンティティ——を解決するからだ。参加者は人間であれエージェントであれ、その参加者自身のものである暗号鍵のペアを持つ。たまたま使っているプラットフォームのものではない。

Block「Introducing Buzz」^[1]

普通のSaaSでは、AIエージェントの身分は「ベンダーが発行したアカウント」か「APIキー」になります。そのプラットフォームをやめれば、身分も履歴も消えます。Nostrの鍵は本人（あるいはそのエージェント）が持つので、IDも履歴も評判も、道具を乗り換えても一緒に移動する。Blockはこれを「ロックインされない」と表現しています。

BlockのAI Capabilities責任者 Bradley Axen のコメントも、同じ線を引いています。

どの会社にも、人間とエージェントが一緒に働く場所が必要になる。問題は、その場所が特定企業のものになるのか、オープンなものになるのかだ。

Bradley Axen（Head of AI Capabilities, Block）^[1]

ここは好みが分かれるところです。鍵を自分で持つということは、鍵を失くしたら自分で困るということでもあります。Googleアカウントでログインするより運用は重くなる。導入を考えるなら、この一点は最初に社内で握っておいたほうがいいでしょう。

04権限の​設計が、​驚く​ほど​単純

セキュリティ設計で面白いのはここです。SECURITY.mdにはこう書かれています。

チャンネルのメンバーシップが唯一のアクセス制御機構である。別途のACLリストも、権限の分類体系も存在しない。

block/buzz SECURITY.md^[3]

つまり「その部屋に入っているかどうか」だけ。入っていれば読み書きでき、入っていなければ、認証を通っていてもリレーが拒否します。プライベートチャンネルは非メンバーからは一覧にすら出ません。

権限設計というと、細かいフラグを何十個も並べる方向に行きがちですが、Buzzは逆に振っています。READMEの言い方だと「権限フラグではなくIDでスコープを切る。人間の同僚に対してやるのと同じやり方で」。エージェントを新しいプロジェクトに入れる操作が、人を招待する操作と同じになるわけです。記録側も含めて整理すると、次のようになります。

仕組み	内容[3]
接続時の認証	NIP-42。リレーがランダムな文字列を出し、クライアントが秘密鍵で署名して所持を証明する
REST APIの認証	NIP-98。リクエストのURLとメソッドを含めて署名する
アクセス制御	チャンネルのメンバーシップのみ。非メンバーはプライベートチャンネルの存在自体を知れない
監査ログ	buzz-audit が全イベントを追記専用で記録。各エントリをSHA-256のハッシュチェーンで前のエントリにつなぐ
検索	会話・パッチ・ワークフロー実行・承認が同じ種類のイベントなので、まとめて一箇所で検索できる

ただし注意しておきたいのは、署名があること＝安全、ではないという点です。署名は「誰がやったか」を証明しますが、「まずいことをするのを止める」わけではありません。誰をどの部屋に入れるか、何を実行させるか、どこで人間が承認するか——そこは結局、使う側が設計します。

関連記事 ｜ 権限側の考え方MCPは「便利な拡張機能」ではなく、AIに何を触らせるかの“権限レイヤー”だ ──AI導入は“統制の設計”になった →

05エージェントは、​中で​何が​できるのか

Buzzは「モデル非依存・エージェント非依存」を掲げています。中身のAIが何であるかは問わない、という立場です。公式は具体例として Claude Code、Codex、goose を挙げ、自前のものを持ち込んでも、新しく作ってもいいとしています^[1]。接続面は3つあります。

接続面	役割[2]
buzz-cli	エージェント向けのコマンドラインツール。JSON入力・JSON出力で、LLMのツール呼び出しから叩く前提で設計されている
buzz-acp	ACP（Agent Client Protocol）のハーネス。goose / Codex / Claude Code を繋ぐ受け皿
buzz-dev-mcp	MCP経由でシェル実行とファイル編集のツールを提供する

そのうえで、READMEが挙げる使い方が具体的で分かりやすいので紹介します^[2]。

• 根拠つきで答えさせる。「このエラー、前に見たことある？」と聞くと、エージェントが6か月分の履歴を検索して、該当スレッドと原因と修正を貼る。印象論ではなくスレッドそのものを出す。
• 鍵を全部渡さずに、バグの一次対応をさせる。 エージェントは自分の鍵と、自分が入っているチャンネルと、自分の監査ログを持つ。見せたい範囲だけ見せる。
• ブランチを部屋にする。 機能ブランチを切るとチャンネルができ、パッチ・CI結果・レビュー・マージの判断が同じ場所に残る。チャンネルがそのコードの存在理由の記録になる。
• YAMLでワークフローを書く。 メッセージ、リアクション、スケジュール、Webhookをきっかけに動かす。全ステップに実行の記録が残る。

もうひとつ、公式発表にもREADMEの完成度表にも出てきませんが、VISION.mdに載っている Buzz Mesh という機能が面白いところです。参加メンバーがGPUを出し合い、エージェントはローカルのOpenAI互換エンドポイント経由でその計算資源を使う——自分たちの作業場を持つという発想を、計算資源にまで伸ばしています^[4]。

06どこまで​動いていて、​どこが​まだ​工事中か

ここが一番大事なところだと思います。Buzzは自分で「Not finished（完成していない）。何が動いて何が動かないかは、こちらから伝える」と書いていて、READMEに完成度の表を置いています。原文の3列をそのまま訳します^[2]。

今動くもの	配線中	意見はあるが、コードはこれから
リレー、チャンネル、スレッド、DM、キャンバス、メディア、検索、監査ログ	モバイルアプリ（iOS / Android・Flutter）	リレーをまたいだ信用ネットワークによる評判
デスクトップアプリ（Tauri + React）	ワークフローの承認ゲート（土台はあるが、接着剤がまだ乾いていない）	プッシュ通知
buzz-cli ＋ ACPハーネス（goose / Codex / Claude Code）	音声ハドルのライフサイクルイベント	カルチャー機能
YAMLワークフロー（メッセージ / リアクション / スケジュール / Webhook）	—	—
Gitイベント（NIP-34：パッチ、リポジトリ告知、ステータス）	—	—
Gitホスティングのバックエンド	—	—

そして表の下に、こう添えてあります。「3列目（意見はあるが、コードはこれから）を前提にコンプライアンス計画を立てるのは、まだやめてください」。特に押さえておきたい点が2つあります。

① 承認ゲートは、まだ止まらない

VISION.mdが具体的に書いています——承認ゲートは部分的にしか作られておらず、スキーマ・RESTエンドポイント・MCPツール・UIは存在するが、実行エンジンが承認トークンを保存せず、実行を中断もしない。request_approval のステップに到達した実行は Failed として記録される（課題番号 WF-08）^[4]。

つまり「AIが下書きを作る → 人間が承認する → 続きが自動で走る」という、業務で一番欲しい流れが、いまはまだ完走しません。人間の承認を挟む前提で導入を検討している場合、ここは待ちになります。

② Git周りは、READMEと公式発表で温度が違う

READMEの表では「Gitホスティングのバックエンド」が「今動くもの」の列に入っています。一方で公式発表のほうは「Git統合はまだ初期段階（still early）」と書いています^[1]。どちらかが嘘というより、動くものとして存在するのと、本番でGitHubの代わりに使えるのとの間に距離がある、と読むのが妥当でしょう。置き換えの計画を今立てるのは早いということです。

そのほか、pre-1.0のため過去リリースのサポートはベストエフォート、モバイルアプリは開発中、という点も前提になります^[3]。

07まとめ ──使う​前に​決めて​おく​5項目

Buzzが提示しているのは「AIが賢くなる話」ではなく、AIをどこで働かせるかの設計です。同じ部屋に入れる、同じ署名付きの記録に残す、部屋の出入りで見える範囲を決める、何をしたかを後から辿れるようにする。この4つは、道具がBuzzでなくても、AIを業務に入れるなら遅かれ早かれ決めることになります。

そう考えると、今すぐ社内のチャットを置き換える話ではありません。先に決めておくことの一覧として読むと、いま一番役に立ちます。

AIエージェントを業務に入れる前に決めておく5項目

• 身分：そのエージェントは誰の権限で動くのか。人のアカウントを借りていないか。辞めた人のアカウントで動き続けていないか。
• 部屋：何を見せて、何を見せないのか。「全社の情報を全部読める」から始めていないか。
• 記録：何をしたかが後から辿れるか。トラブルのときに「たぶんこう動いた」で済ませない形になっているか。
• 承認：外部への送信、金額、契約など、取り返しのつかない操作の手前に人間が入るか。
• 鍵：認証情報を誰が管理し、失くしたとき・漏れたときに何をするか。

手を動かして確かめるなら、ローカルで動かすのが早いです。DockerとHermit（またはRust 1.88+ / Node 24+ / pnpm 10+ / just）を用意して、just setup && just build のあと just dev でリレーとデスクトップアプリが立ち上がります。リレーは ws://localhost:3000、エージェントから使うときは BUZZ_PRIVATE_KEY を設定して buzz-cli を叩く形です^[2]。手元に作業場をひとつ立てて、自分とエージェントを別のIDで入れてみると、この設計が何を狙っているかは短時間で分かります。

私たちがAIエージェントを実務に組み込むときも、毎回ぶつかるのはモデルの選定より「どこまで見せて、どこで人間が判断するか」の線引きのほうです。Buzzはその線引きを、仕様として読める形で公開した。今回いちばん面白いのは、そこだと思います。