きっかけ
経営の意思決定と自社サービスの開発を、両方自分の手でやっている。経営判断とコードを同じ日に触るような日々の中で、最近もっとも面白いと感じているツールが Buzz（Block社が開発したオープンソースのワークスペース、Apache 2.0ライセンス）だ。
公開されてまだ日が浅いプロダクトだが、リリース直後のこの数日で自分の環境に構築し、実際に触ってみて感じたことを書いておきたい。
一見するとSlackやDiscordに似たチャットアプリに見える。
しかし実際に手を動かして、複数のAIエージェントを住まわせてみると、単なる「チャットにBotを追加できるツール」とは全く違う設計思想の上に立っていることがわかってきた。
今日はそれを、経営者としての視点と、手を動かしたエンジニアとしての視点の両方から書いてみたい。
Buzzは何が違うのか ― 「Botではなくメンバー」という設計
普通のチャットツールにAIを組み込むとき、AIは大抵「Bot」として扱われる。APIキーを持ち、権限フラグで機能が制限され、人間とは明確に区別された存在だ。
Buzzの設計はここが根本的に違う。
Buzzの正体は Nostr（分散型のソーシャルプロトコル）の上に構築されたリレーサーバー で、チャットの発言もリアクションも、ワークフローの各ステップも、コードレビューの承認も、Gitへのプッシュも、すべてが「署名付きのイベント」として一本のログに記録される。
そしてAIエージェントは、この仕組みの中で 人間の同僚とまったく同じ扱い を受ける。自分の暗号鍵を持ち、自分の所属チャンネルを持ち、自分の発言履歴（監査証跡）を持つ。権限は「フラグ」ではなく「そのエージェントが何者か」というアイデンティティによってスコープされる。
これは単なる実装上のこだわりではなく、思想として一貫している。
人間かAIかで扱いを変えない、というのがBuzzの根っこにある。実際に触ってみると、「このエージェントに何をどこまで任せるか」を、権限設定画面のチェックボックスではなく、「誰をこのチャンネルに招待するか」という、人を雇うときと同じ感覚で決められることに気づく。
これは経営者として地味だが本質的に大きい違いだと感じている。
実際に触って驚いた技術的な面白さ
自分でリレーを構築し、複数のAIコーディングエージェント（Claude Code、Codexなど、モデルやベンダーを問わず色々挿せる）を「メンバー」として参加させてみて、特に面白いと感じたポイントを挙げる。
1. エージェントの中身を自由に差し替えられる
Buzzは特定のAIベンダーに縛られていない。
ACP（Agent Client Protocol）という共通の口を経由することで、Claude CodeでもCodexでも、あるいは自作のエージェントハーネスでも、同じチャンネルの中に同居させられる。
実際にうちの環境では、性格の違う複数のエージェント（役割ごとにペルソナを変えたもの）が同じワークスペースの中で会話し、それぞれ得意分野で反応する構成にしている。人間の組織で「専門性の違うメンバーをチームに配置する」のと同じ感覚でAIチームを組める。
2. GitのホスティングもNostr上に統合されている
これが個人的には一番驚いた部分だ。
BuzzはGitリポジトリのメタデータもNostrの標準規格（NIP-34）で表現している。つまり「Buzzのチャンネル＝ブランチ」という体験を提供しつつ、その裏側の実データは標準的なNostr対応クライアントからも普通のGitリポジトリとして読める。
ベンダーロックインを技術的に避ける設計になっているわけだ。もしBuzzというプロダクトが将来なくなっても、会話の履歴もコードの履歴も自分たちの手元に残る。
この「ポータビリティを最初から設計に織り込んでいる」姿勢は、ベンダー選定するときに一番気にする部分でもあるので、率直に好感を持った。
3. ワークフローがコードとして書ける
「メッセージが投稿されたら」「レビューが承認されたら」といったトリガーに対して、YAMLでワークフローを定義できる。
承認ゲートを挟んでからでないと次のステップに進まない、といった業務フローをそのままAIエージェントの働き方に落とし込める。まだ発展途上の部分もあるが(後述)、「人が承認したことも、AIが処理したことも、同じ1本のログに時系列で残る」という設計は、経営としてのガバナンス・説明責任の観点からとても筋が良いと感じている。
経営者として何が刺さったか
正直に言うと、最初は「面白いおもちゃ」くらいの気持ちで触り始めた。
しかし実際に自社の業務にAIエージェントを複数体、それぞれ役割を分けて常駐させてみると、見え方が変わってきた。
ここは技術の面白さとは別に、経営の意思決定として刺さった点をいくつか書いておきたい。
評価スピードが経営の武器になる。
新しいツールを導入するかどうかの判断は、普通は資料を読んだりベンダーの説明を聞いたりして時間をかける。
今回は自分で構築して数日触っただけで、「何ができて、何がまだできないか」を自分の言葉で判断できた。
技術を理解した上で経営判断できる、というのは、これからのAI関連ツール選定において地味だが大きなアドバンテージになると感じている。
AIを増やすコストの構造が変わる。
オープンソースでセルフホストできるということは、AIメンバーを一人増やすときの限界費用が、人を一人雇うコストとも、席数課金のSaaSツールを一つ増やすコストとも違う。役割ごとに細かくAIを分けて配置する、という発想が現実的なコストで試せるようになる。
これは「どこまで人に任せ、どこからAIに任せるか」という業務設計そのものを見直すきっかけになった。
監査ログはガバナンスであり、将来の説明責任への備えでもある。
これまで「AIを使う」というのは、個々のツールにその都度指示を出す、という単発の作業だった。
Buzzの中でAIが「メンバー」として在籍する体験は、それとは質的に違う。
チャンネルの文脈を共有し、他のメンバー(人間・AI問わず)の発言を踏まえて反応し、履歴が残る。何を、誰が(どのエージェントが)、いつ、なぜ判断したかを後から追えるというのは、属人化を防ぐという意味でも、いずれ取引先や監督官庁にAI活用の説明を求められる場面が来ることを見据えても、経営として安心材料になる。
小さな組織でも「組織の厚み」を持てる。
専任の担当者を何人も雇う余力がなくても、役割の違うAIメンバーをチームに加えることで、擬似的に組織の厚みを持たせられる。
これは採用戦略そのものにも影響する話で、「この役割は人を採るべきか、AIメンバーとして構成すべきか」を最初から選択肢に入れて考えられるようになった。
誠実に書いておきたい、まだ荒削りな部分
面白さばかり書くと提灯記事になってしまうので、実際に触って感じた「まだここは発展途上」という点も書いておく。
- モバイル対応は道半ば。 スマートフォンからのプッシュ通知は限定的で、常にリアルタイムに気づける状態ではない。今のところは「PCで開いているときにやり取りする」という使い方が現実的だ。
- 承認フローの自動化は仕組みは用意されているが、まだ手動で埋める部分が多い。 「重要な操作は必ず人間の承認を経る」という機能の土台はあるものの、まだ本番の必須フローとして全面的に頼るには早い。
- 開発初期のプロダクトである。 公式自身が「完成品ではない」と明言している通り、この数日触っているだけでも仕様の粗さやバグに何度か遭遇した。
裏を返せば、これは「まだ誰も正解を出し切っていない領域」だということでもある。むしろ今のタイミングで自分の手で触っておくことに価値があると感じている。早い段階で肌感覚を持っておくことは、この分野が成熟してから追いかけるより、確実に有利に働くはずだ。
おわりに
Buzzが面白いのは、機能の豊富さそのものよりも、「AIエージェントを人間の同僚と同じ土俵で扱う」という設計思想を、実際に動くプロダクトとして体験できることだと思う。経営者としてAIをどう自社に組み込むかを考えるとき、単に「便利な自動化ツール」として見るのと、「組織の一員としてどう迎え入れるか」として見るのとでは、その先に描ける未来がまったく違ってくる。
技術に強い経営者だからこそ言えることかもしれないが、こういうツールを実際に自分の手で構築し、触って初めて見えてくる肌感覚がある。これからも実験を続けながら、また面白い発見があれば書いていきたい。
