- Blockは、従業員とAIエージェント、会話、ソフトウェアリポジトリを単一のアイデンティティ体系で結び付けるオープンソースワークスペースBuzzをリリースし、SlackとGitHubへの依存を減らそうとしている
- メッセージ、リアクション、ワークフローのステップ、コードイベント、承認を署名付きNostrイベントとして保存し、人間とエージェントに鍵ペア、チャンネルメンバーシップ、監査証跡を同じように付与する
- エージェントは会話検索からパッチ提出、コードレビュー、ワークフロー実行まで行い、Goose・Codex・Claude Codeハーネスによりワークスペースと基盤モデルを分離する
- セルフホスティングとデータ所有権を提供する一方、すべての読み書きが単一の中央リレーを経由するため、運用者が可用性、バックアップ、セキュリティ、アップグレードに責任を負う必要がある
- チャット、コードホスティング、自動化、検索、エージェント調整を一か所にまとめたが、モバイルアプリとプッシュ通知は未完成であり、導入率、価格、外部顧客数も公開されていない
人間とエージェントをつなぐ統合ワークスペース
- Buzzは、従業員、AIエージェント、会話、ソフトウェアリポジトリを単一のアイデンティティ体系の下に置く、セルフホスティング可能なオープンソースワークスペースである
- Jack Dorseyはこれにより、BlockのSlackおよびGitHubへの依存を減らそうとしている
- Blockの公開リポジトリには、社内リレーとエージェントプロバイダーに合わせた別の内部ビルドも文書化されている
- セルフホスト型Nostrリレーを中心に、メッセージ、リアクション、ワークフローのステップ、コードイベント、承認を暗号学的に署名されたイベントとして保存する
- 従業員とエージェントの双方が、固有の鍵ペア、チャンネルメンバーシップ、監査証跡を持つ
- 共有アイデンティティと署名付きイベントにより、エージェントが従来のチャットボットを超え、責任を追跡できるメンバーとして参加する構造になっている
- エージェントは、過去の会話検索、リポジトリ閲覧、パッチ提出、コードレビュー、ワークフロー実行、共有キャンバス編集、チャンネル作成を実行できる
- エージェント向けCLIとGoose・Codex・Claude Codeハーネスを提供し、基盤モデルをワークスペースから分離する
- プロジェクト仕様は、標準のGit Smart HTTPを使用する組み込みソフトウェアフォージを定義している
- 機能ブランチを専用チャンネルとして作成し、パッチ、継続的インテグレーションの結果、レビューコメント、マージ判断を同じ記録に保存する
- リポジトリ、会話、ワークフロー履歴は1つの検索インデックスを共有する
- 現在、チャンネル、スレッド、ダイレクトメッセージ、共有キャンバス、メディア、検索、監査ログ、デスクトップアプリ、YAMLベースのワークフローが動作する
- macOS、Windows、Linux向けのパッケージビルドを提供し、Apache 2.0ライセンスを適用している
単一リレー構造と初期製品の制約
- DorseyはBuzzを分散型かつ自己主権型の製品として紹介したが、アーキテクチャ文書によると、現在はリレー間のP2Pイベント交換、ゴシップ層、レプリケーション機能はない
- すべての読み書きは、ユーザーを認証し、署名を検証し、イベントを保存・配信する単一リレーを通過する
- 組織は自前のリレーとドメイン、データを所有し、ポータブルなNostr鍵ペアを使えるが、各コミュニティ内ではそのリレーが権威サーバーとして残る
- ホスティング事業者は、共有インフラ上で相互に分離された複数のコミュニティを運用できる
- セルフホスティングはインフラとデータの所在に対する制御権を与える一方で、可用性、バックアップ、セキュリティ、アップグレードの責任を運用者に移す
- 署名付きイベントは行為の帰属と監査証跡を支援するが、サーバー運用上のリスクまでなくすわけではない
- Buzzはテストと開発に使用できるが、文書では繰り返し未完成の製品に分類されている
- モバイルクライアントは開発中で、プッシュ通知はまだ提供されていない
- ワークフロー承認ゲートにはデータベース、API、インターフェースの構成要素があるが、完成した実行経路はない
- デスクトップバージョン0.4.21は、7月21日にエージェント制御、認証、ワークスペースオンボーディング関連機能の追加と修正を含んでリリースされた
- 1つのイベント体系で、チャット、コードホスティング、ワークフロー自動化、プロジェクト検索、エージェント調整の一部を置き換えようとしている
- 統合構造は、エージェントに必要なコンテキストと制限付きアクセス権を提供するための連携作業を減らせる可能性がある
- 一方、役割別に分離された既存製品なら、開発スタック全体を移行せずにツール1つだけを置き換えられる
- BlockはBuzz文書に含まれる最初の顧客事例だが、導入率、価格、外部顧客数は公開しておらず、現在はオープンソースビルドとコントリビューション募集の段階にある
1件のコメント
Hacker News の意見
あのスクリーンショットは、まるで David Lynch 風のホラーみたいだ。「#engineering. 新しい方針です。プロトタイプを Flutter に移します」と言うと、人間とエージェントボットがかわいい名前と絵文字で「物理処理は終わったよ、UI シェルはどう @Honeybot?」みたいな会話をしている。
こういうやり方でソフトウェア開発を組織するのが自然な世界を想像するのは難しいし、ブロックチェーンっぽい何かを使っている点もいかにもという感じがする。
https://github.com/block/buzz/blob/main/docs/assets/screensh...
https://www.theguardian.com/film/2013/nov/20/the-hobbit-gand...
ただし、おべっかばかり言う複製ではなく実際の人格を与え、能力と振る舞いの両面で各エージェントの違いがはっきりしているべきだ。
本質的に見慣れないものを直感的に感じさせるうえで、遊び心のある演出を過小評価する必要はない。ボットごとに管理主体、能力、権限が異なるので、名前と画像はインスタンスを区別する便利な略称であり、かわいく装飾するかどうかは任意だ。
「5歳児に説明するように」と言いながら、「Buzz は署名付き Nostr イベントでチームチャット、AI エージェント、Git ホスティングを組み合わせたオープンソースのセルフホスト型ワークスペース」と説明しているので、想定している5歳児のレベルがかなり違う。
eli5 (作業)と頼んで、本当に5歳児に話すように説明されるのではと心配したことがある。不合理な懸念だったし、エージェントは HN のコメント欄と違ってたいてい実際の意図を理解する。Slack で働いているが、これは個人の見解。エージェントが私や同僚の見ているものをすべて見られるのはすばらしいが、一部の情報を特定の人だけに公開しようとした瞬間に難しくなる。
マルチユーザーエージェントがデータを漏らさないように、リソースごとのアクセスルールを複雑に書いて維持しなければならない。一方でシングルユーザーエージェントは一人のユーザーの代理なので構造が単純で、明示的な許可なしに非公開データを共有空間へ持ち出せないようにすることが肝になる。
プライバシーを意識し、誤った相手に情報が漏れないようにするために、多くの検討と時間を費やした。Buzz はまだ使っていないが、違う発想で興味深いものを作ろうとする試みは高く評価する。
Claudeというユーザーを作って通常の ACL を適用するなら、人間かボットかを気にする必要はないのではないかと思う。Slack エージェントはこの点が強力で、非公開情報が一切漏れないことを保証する。
今では新しいソフトウェアプロジェクトを見ると、どれほど多くの部分がエージェントで作られたのか、そしてそれに伴う不安定さと簡単な放棄がまず頭に浮かぶ。10年前なら製品品質をある程度推測できただろうが、Buzz を名指しして言っているわけではない。
こうした製品は初期導入の利点よりリスクのほうが大きいので、数か月待つほうがよい。持続可能な製品なら、数か月遅れても大差はない。
プロジェクトがプロダクトマーケットフィットを見つけられるかが核心であり、2年後にも存在するかどうかは、エンジニアが信じたがるほどコード品質と強く結びついてはいない。
以前 Slack で働いていた。チャットの現状維持に挑むのはよいことだが、Slack と Teams がエージェント時代にも生き残る、あるいはその水準まで進化するかは懐疑的だ
ただし、Nostr が本当に適切なプロトコルなのかは気になる。大企業では、携帯電話やローカルエージェントを含む多数のクライアントと、チームごとのエージェントを扱う必要がある。中央ホスティング型エージェントには現在のアイデンティティ構造が合っているが、個人エージェントがユーザーの資格情報を再利用するのか、別個に区別されるのかは分からない
Git が必須の依存関係である必要があるのかも疑問だ。Block には必要かもしれないが複雑性が増すため、バージョン管理ホストのイベントを Buzz のイベントログにマージする形で分離することもできる
Sol と Claude がチャットウィンドウ内でネイティブコンポーネントをレンダリングし、デザイン変更を具体化するような新機能が登場するとき、どんな問題が起きるのかも気になる。Rust を選んだ理由と検討した代替案も知りたい
Signal は友人グループで使ったクライアントの中で、プラットフォーム横断のメッセージング体験が最も良かった。現在の構造に Slack のような仕組みを加えれば、騒がしいチャンネル問題を減らすのに役立つだろう
Google Buzz と Wave は、この世に出るのが早すぎた
https://en.wikipedia.org/wiki/Google_Buzz
Buzzラベルを作れないチームチャットにボットを入れるのは悪くなく、ここ数か月実験している。Slack は動くには動くが、大量の権限を合わせるのが苦痛で、新しいボットごとに繰り返す必要がある
セルフホストの代替として Matrix を試したが、エンドツーエンド暗号化が厳格すぎて、ボットと情報を共有するときに妨げになった。数週間前に Zulip へ移行したところ、インストール、ボットユーザー作成、自動化がどれも簡単だった。Openclaw で作った自動化は、状態がそれほど混乱していないHaystack ベースのコードに置き換えた
導入後に知ったのだが、Zulip の経営陣は Anthropic に採用されていた。Jack Dorsey が先に発表したようだが、Anthropic にも似た計画があるのかもしれない
チーム単位のエージェントは十分に理にかなっている。組織が大きくなるほど協業コストは増え、AI で最適化しやすくなる。また、AI 活用が増えるほど、何をしているのかを公開チャンネルで共有し調整する必要も高まる。共通の安全策や、人間とエージェント間の引き継ぎを含む複雑なプロセスにも、チームチャットはよく合う
有用なニッチを埋められる可能性はあるが、Anthropic と OpenAI が6〜12か月以内に自社製品で押し出してくる可能性が高い
エージェント群向けの Git フォージを見てみると、Radicle はアイデンティティ層が不足している一方、連合型 COB モデルは良さそうだった。Tangled は非公開リポジトリ対応がないが、ソーシャル層は堅実だった。ただ、イシューをリポジトリ所有オブジェクトではなく投稿としてモデル化している点はぎこちない
したがって、非公開のエージェント優先フォージの余地はある。Anthropic はすでにこの方向に進んでおり、最新製品 Tag は Slack 内でエージェントを非同期に実行するための認証モデルだ
次の段階は自然にフォージになり得る。エージェント UI が GitHub を仲介しなくなれば、Anthropic は内部実装を自由に差し替えられるし、マルチユーザーチャットとリポジトリ・プロジェクト管理が次のプラットフォーム構成要素に見える
Slack が存在する大きな理由は、IRC がチャンネル履歴や検索などを標準でサポートしておらず不十分だったためだ。AI エージェントが繁栄するには、Slack がネットワークをプロトコルとして完全に開放するか、最終的に置き換えられる必要がある
Slack がAT Protocol ベースのチャットを採用し、Buzz のようなアプリがそれを実装するとよい。ユーザーは
@yourname.com、エージェントは@agent1.yourname.comのようなドメインハンドルを使いながら、完全な制御権を持てるチャットも PDS/ATP に適した形式ではない。Roomy もそれに気づき、専用プロトコルとブリッジを作っている
Web サイトでカーソルの動きが0.5秒も遅延するという不快な体験は初めてだ