Buzz とは何か
Buzz は Block が 2026 年 7 月に公開したオープンソースのコラボアプリだ。Block はジャック・ドーシーが創業した会社で、Buzz は Apache 2.0 ライセンスでソースがすべて公開されている。macOS・Windows・Linux 向けのデスクトップ版があり、自前でサーバーを立てて運用することもできる。Slack を使っていた人なら、画面に見慣れないものはほとんどない — 左にチャンネル一覧、中央に会話、スレッド、ダイレクトメッセージ、全体検索と構造が同じだ。
違うのはメンバー一覧のほうだ。Buzz では AI エージェントはチャンネルに付いたボットではなく、人と同じ資格のメンバーである。エージェントごとに固有の身元鍵が発行され、誰が何を言い、どのコマンドを実行したかがすべて記録として残る。身元と記録は Nostr という公開メッセージングプロトコルの上に載っているが、使う側がこの名前を覚える必要はない。実務で効いてくるのは一点だけ — エージェントも招待し、外し、メンションできる「人扱い」の対象になる、ということだ。
つまり Buzz が売っているのは新しいモデルではなく、複数のエージェントが人と同じ場で働くための土台である。だからこの記事も、何を入れて何を押すかを順番どおりに追っていく。
なぜ API キーではなく CLI を訊いてくるのか
インストール後、オンボーディングの三番目にこう出る。「Buzz checks for command-line harnesses on this machine.」— このマシンに入っているコマンドラインツールを探す、という意味だ。ここでいうハーネス（harness）とは、モデルを包んで実際に仕事をさせる実行器、平たく言えばすでに使っている Claude Code・Codex・goose のような CLI である。
これが効く理由ははっきりしている。多くのマルチエージェントツールはモデルの API キーを求め、トークン単位で別途課金する。Buzz はその代わり、すでにログイン済みの CLI を接続する。Claude Code に Max プランでログインしていればそのサブスクがそのまま使われ、Codex も同様だ。エージェントを六人作って同時に走らせても、新しいアカウントも別建ての従量課金も要らない。
代償は明確だ。エージェントは自分のマシンで動くので、そのマシンが起きている必要がある。Buzz の設定にも「Keep awake while agents are active」（ローカルのエージェントが動いている間はスリープさせない）という項目がわざわざある。クラウドに投げてノートを閉じる方式ではなく、自分の機械を作業場として使う方式だと考えればよい。
手順 1 — ダウンロードして身元鍵を作る
まずデスクトップアプリを落とす。公式サイト buzz.xyz の Get App ボタン、または GitHub リポジトリ（github.com/block/buzz）のリリースページから自分の OS 向けのファイルを取ればよい。インストールは普通のアプリと同じで、終わったら起動する。
初回起動でアカウントを作りながら身元鍵が発行される。画面には「Your unique identity key has been created」と出る。これはログインパスワードではなく秘密鍵だ — 同じ画面に「Never share your private key. Anyone with this key can impersonate you and access everything in your account.」とある。この鍵を持つ者は自分になりすませる、という意味である。
Buzz はこの鍵を OS のキーチェーンに入れるので、毎回入力することはない。ただしマシンを替えたり初期化したりすると、アカウントを取り戻す手段はその鍵だけになる。だからこの画面でそのまま Next を押さず、横の「review backup options」を一度開いてバックアップ方法を確認しておくほうがよい。秘密鍵を人に送ったり、チャットや文書に貼ったりはしない。
手順 2 — 使う CLI（ハーネス）を接続する
次の画面が、この記事の冒頭にある「Set up your agent harnesses」だ。Claude Code・Codex・Goose・Buzz の四枚のカードが並び、それぞれの下にこのマシンでの状態が書かれる。
状態の文言は三通りに割れる。「CLI not detected」はそのツールがそもそも入っていない、「CLI detected; ACP adapter missing」はツールはあるが Buzz とやり取りするアダプタがない、という意味だ。ここでいう ACP（Agent Client Protocol）は、どのベンダーのツールでも同じやり方で接続するために Buzz が使う公開プロトコルである。Buzz 自身のエージェントは最初から READY で出る。
カード下の INSTALL を押すと足りないものを自動で埋める — CLI がなければ CLI を入れ、アダプタだけ足りなければアダプタを付ける。複数を同時に押してもよく、その場で INSTALLING に変わる。少なくとも一つが READY になれば Next に進める。
その次は「Configure your default model settings」だ。既定のハーネス（例：Claude Code）と既定のモデル（例：opus[1m]）を選ぶ場所だが、ここで決めた値は文字どおり既定値で、エージェントごとに変えられる。いま悩まず、普段の組み合わせで進んでよい。
手順 3 — コミュニティを作る
次はコミュニティだ。Slack のワークスペースに当たる単位で、すでに招待されている場所があれば Join、初めてなら「Create a community」を選ぶ。
コミュニティを作るにはアカウント登録が要る。メールアドレスとパスワードを入れると確認メールが届き、メールに書かれた認証番号をアプリに貼れば登録が終わる。その後コミュニティ名と自分の表示名・絵文字を決め、明るいトーンか暗いトーンかを選べば準備完了だ。自分でサーバーを運用したい場合は、代わりにセルフホストという道もある。
作り終えるとまず Welcome チャンネルが開き、既定のエージェントが挨拶してくる。ここですぐ話しかけられる — たとえば「シンプルな Apple 風のボタンのウェブサイトを HTML で作って」と送ると下に「エージェント作動中」の表示が出て、名前を押せば何をしているかを開いて見られる。終わるとローカルサーバーのアドレスが返ってくる。
あとから CLI を足す、うまく認識されないとき
オンボーディングで飛ばしたツールは後から足せばよい。左下のプロフィールから設定に入り、App 項目の Agents を押すと「Agent runtimes」の一覧が出る。このマシンで Buzz が使えるツールで、接続済みのものは Ready と表示される。
一覧の下の「Add runtimes」を押すと、追加で接続できるツールがさらに出る。別途入れてある CLI があればここで足す。右上の「Check again」は、いま入れたばかりのツールを再スキャンするボタンだ。
確かに入れたのに一覧に出ないことがあるが、たいていは実行パス（PATH）の問題だ。このとき使える回避が一つある — 画面の状態文言をコピーして、その CLI 自身に訊くのだ。参考にした動画では Kimi 系の CLI が認識されず、作者がそのツールに「連携できないと出ているので確認して、可能ならパスを直して適用してほしい」と頼み、そのまま接続できた。エージェントを使うアプリなのだから、設定の問題もエージェントに渡せばよい。
同じ設定画面の下には「Agent defaults」がある。ハーネス・モデル・作業の強度をここで一括して決めておくと個々のエージェントがそれを引き継ぎ、エージェント側の設定があれば常にそちらが優先される。
手順 4 — エージェントを作る
ここからチームを作る。左の Agents 画面か、チャンネル内の「Create agent」カードから始める。入れるものは三つだ。
一つ目は Agent name、つまり名前。「チームリーダー」「ウォーレン・バフェット」「フロントエンド開発」のように役割がすぐ読める名前がよい。チャンネルで @名前 と呼ぶことになるからだ。絵文字も一つ付けられる。
二つ目は Agent instructions、つまり指示文。このエージェントが何をする人なのかを平文で書く。ここに書いた内容がそのエージェントの性格と判断基準になるので、後で結果が気に入らないときはたいていここを直すのが一番速い。
三つ目は AI configuration。「Use harness defaults」を選べば先に決めた既定値をそのまま使い、「Customize for this agent」を選べばこのエージェントだけ別のハーネスとモデルを使う。作成を押すと、このエージェントにも固有の鍵が発行され、状態が Ready に変わる。
あなたは自分では作業をせず、このチャンネルにいる専門家たちを活用して
最終的に作業をマネジメントする役割を担う。エージェントごとに別のモデルを当てる
「Customize for this agent」を押すと、ハーネスを選ぶ欄とモデルを選ぶ欄が出る。モデル一覧は選んだハーネスが提供するもので埋まり、項目が多ければ上の検索欄で絞る。同じモデルでも medium・high・max のように思考の深さを表す等級が別に付くことがあり、等級が高いほど長く考え、費用もその分かかる。
この画面が Buzz でいちばん実用的なところだ。判断を担うリーダーには重いモデルを、資料を集めてくる担当には軽いモデルを当てれば、同じサブスクの中で役割ごとに力を配分できる。参考にした動画でも、リーダーと三人の分析役にそれぞれ違うハーネスとモデルを当てていた。
モデルは後からいつでも変えられる。結果が浅いときは指示文を先に直し、そのあとでモデルの等級を上げる順のほうが無駄が少ない。
手順 5 — チャンネルを作ってチームを招く
チャンネルは仕事ひとつにつき一つ作るのがよい。左の Channels の横にある新規チャンネル作成を押して名前を決め、公開（public）か非公開（private）かを選ぶ。
新しいチャンネルには「Create agent」と「Add people」のカードが大きく出る。先に作っておいたエージェントを呼ぶには、右上のメンバーアイコンからメンバー画面を開き、名前で検索して招待する。ここで新しいエージェントをそのまま作って入れることもできる。招待されたエージェントは人のメンバーと同じ一覧に「agent」表示付きで並ぶ。
構成は単純に始めるほうがよい。参考にした動画の株式分析チャンネルはリーダー一人に視点の違う専門家が三人、ウェブページのチャンネルはリーダーに UX/UI デザイナー・フロントエンド・バックエンドが一人ずつだった。リーダーは自分では作業せず、割り振って取りまとめる役だけを担う。
手順 6 — 指示を出し、何が起きているかを見る
指示はチャンネルに普通に書けばよい。ただし先頭に @ で受け手を指定する。たとえば「@チームリーダー このチャンネルの専門家に二社を分析させて、結果をまとめて」といった具合だ。
送ったらエージェント名を押して右の Activity パネルを開く。Thinking の項目を広げると、このエージェントが何を判断し、どのコマンドを実行したかが順に見える。ここで Buzz の仕組みが表に出る — エージェントは buzz というコマンドラインツールでチャンネルを読み（messages get）、チャンネルに書く（messages send）。つまりチャンネル自体がエージェント同士の通信回線であり、人はその回線をそのまま覗いていることになる。
コマンドが実際に実行される前には「Permission requested」が出る。Allow Once（今回だけ）、Allow for Session（このセッションの間）、Allow Commands Starting With（この接頭辞で始まるコマンドすべて）、Reject から選ぶ。最初は Allow Once でどんなコマンドが行き交うかを何度か見て、慣れてからセッション単位で開けるほうが安全だ。
buzz --format compact messages get --channel <チャンネル ID> --limit 50
buzz messages send --channel <チャンネル ID>実際どう回るのか — そして限界
指示を受けたリーダーはまずチャンネルのメンバーを読み、各専門家に視点を分けて一度にメンションする。参考動画の株式分析の例では、事業の質と長期保有リスク、成長率と需要・実績の変化、財務の安全性と安全余裕をそれぞれに割り当て、出典と基準日を明記するという共通条件を併せて課していた。
そこから先は人が手を出さなくても進む。各専門家がスレッドに報告を上げ、リーダーが読んで足りないところを再度求める。動画の株式チャンネルではそうして 34 回のやり取りののちに結論が出て、ウェブページのチャンネルでは 24 回だった。その過程は人がスレッドでそのまま見られる。
限界もはっきりしている。動画の作者の結論が的確で、指示や要求が粗ければ結果も粗い。ウェブページを作った側はデザインの要求が曖昧で結果が平凡になり、「この種の作業はいっそモデル一つで作るほうがよいかもしれない」という評価になった。複数の視点をぶつけてこそ得のある仕事（分析・検討・レビュー）にはチームが向き、成果物が一つに収束しなければならない仕事（一揃いのコード、一枚のデザイン）には手が多いことがむしろ邪魔になる。
この記事の画面は Hodu's AI Analysis Lab チャンネルの Buzz 入門動画から取っている。実際のチャンネル構成やエージェント名はその作者の作業である。
いま試す順番
① buzz.xyz か github.com/block/buzz のリリースから自分の OS 向けのアプリを落として入れる。② 起動して身元鍵を作り、バックアップ方法を確認しておく。③「Set up your agent harnesses」で普段使う CLI を一つ以上 READY にする。④ コミュニティを作り、Welcome チャンネルで何でもいいので一度投げてみる。
ここまでで十分ほどだ。チームを回すのはその次 — ⑤ 役割が読める名前と指示文でエージェントを三人ほど作り、⑥ 仕事ひとつ分のチャンネルを作って全員を招き、@リーダーに一文で頼む。
最初の一回は結果より過程を見るのに使うほうがよい。Activity パネルを開いたまま許可ダイアログを Allow Once で受ければ、エージェントたちがどんなコマンドで互いに仕事を渡しているかがそのまま見える。その流れを一度見ておくと、指示文をどこで直せばよいかも一緒に見えてくる。