【考察】Blockの「Buzz」「Builderlab」「Dessa」が描く、知能時代のビジネスモデル解体新書

• 1. 3つのピースの役割分担
• 2. ソースコードから読み解く「Builderlab」の正体
• 3. Dessaは「Macで動く」のになぜBuilderlabが必要なのか？
  • ① 「PCを閉じても動く」常時稼働（Always-on）の壁
  • ② クライアント端末のスペック格差の吸収
  • ③ 音声モデル単体では仕事にならない（オーケストレーションの需要）
• 4. デスクレスワーカー（店舗・現場）へのTAM（市場規模）拡大
• 5. マネタイズの5層ピラミッド
• 6. なぜオープンソース×ローカル完結を捨象しないのか？
• おわりに

§1. 3つのピースの役割分担

まず、3つのプロダクトがエコシステムの中でどのような役割を担っているのかを整理する。

┌────────────────────────────────────────────────────────┐
│  Dessa（音声対音声・フルデュプレックスモデル）         │
│  摩擦ゼロの自然なインターフェース（Huddle / 音声通話） │
├────────────────────────────────────────────────────────┤
│  Buzz（オープンソース・Nostrワークスペース）           │
│  人とAIエージェントが同等に共存する分散型OS           │
├────────────────────────────────────────────────────────┤
│  Builderlab（商用マネージドクラウド）                  │
│  インフラ運用・常時稼働・ガバナンスの課金エンジン      │
└────────────────────────────────────────────────────────┘

1. Buzz（共有空間・プロトコル）
   • Apache-2.0ライセンスの自前ホスト可能なワークスペース。
   • Nostrプロトコルを採用し、人間だけでなくAIエージェント（Goose、Codex、Claude等）にも固有の暗号鍵を持たせ、チャット、Gitコード管理、タスクを同一平面で協調動作させる。
2. Builderlab（コントロールプレーン・収益化エンジン）
   • Buzzを自前運用する手間を省き、企業規模でスケールさせるためのマネージドサービス（SaaS/PaaS）。
   • ホステッドリレー、24時間稼働するクラウドエージェント、権限管理、モデルルーティングなどを提供する。
3. Dessa（究極のインターフェース）
   • テキストを介さず、人間の会話音声のみから学習された純粋な音声対音声（Speech-to-Speech）モデル。
   • 人間の会話と同じように相槌（backchanneling）を打ち、割り込み（interruption）を認識するフルデュプレックス対話を実現する。

§2. ソースコードから読み解く「Builderlab」の正体

Buzzのデスクトップクライアント内にある src/bundled/builderlab プラグインの実装を覗くと、Blockが「何を無料でオープンにし、どこを有料サービスにするか」の境界線が明確に見えてくる。

• Hosted Communities（Relay as a Service）
  自前でPostgreSQL、Redis、S3互換ストレージ（Blossom）を運用することなく、Blockのクラウド上にワンクリックでコミュニティ（リレー）を作成できる。API上にはコミュニティ作成クォータ（上限管理）や所有権移転の仕組みが実装されている。
• Remote Agents（Agent as a Service）
  ローカルPCのアプリを閉じても、24時間クラウド上で自律稼働し続けるエージェントのホスティング環境。
• Managed Identity & Auth
  Nostrの公開鍵（Buzzのアイデンティティ）と企業のBuilderlabアカウントを暗号署名（kind:24243 チャレンジ）でバインドし、企業のSSO/フェデレーテッドIDと統合する。
• Decisions API & Model Catalog
  LLMのモデルルーティングやAPI呼び出しを一元管理するゲートウェイ。

つまりBuzzは「誰でも自由に使える分散型クライアント」であり、Builderlabは**「Buzzを閉じた後もチームとエージェントが動き続けるための基盤」を提供する課金ゲートウェイ**として設計されている。

§3. Dessaは「Macで動く」のになぜBuilderlabが必要なのか？

ここで極めて興味深いのが、音声モデル Dessa の位置づけだ。

Jack Dorsey氏はX（旧Twitter）でDessaについて「MacBookで動くほど小さい」と投稿しており、Blockの公式ページでもMacBook Pro M4 Max以上であればリアルタイムより高速にローカル推論できると明記されている。

「クラウド必須の巨大モデル」ではなく、ローカルで完結して動作するという点は、分散型で自己主権（Self-sovereign）を重んじるBlockの哲学とも完全に一致している。

では、Dessaが手元のMacBookで軽快に動くのであれば、なぜBlockは商用クラウドの「Builderlab」を展開するのか？ ここに、Blockのビジネスモデルの巧みな設計がある。

§① 「PCを閉じても動く」常時稼働（Always-on）の壁

手元のMacBookでDessaが動くとしても、作業者がノートPCを閉じたりスリープさせたりすれば、そのエージェントは停止する。
チームのチャンネルや音声ハドルに「常に同僚として常駐し、夜間もコード監視や顧客対応を行うエージェント」を実現するには、クラウド上の常時稼働インスタンス（Builderlab Remote Agents）が必要になる。

§② クライアント端末のスペック格差の吸収

M4 MaxクラスのハイエンドMacを全社員・全スタッフに配給できる企業は一握りだ。
現場のSquareレジ端末、Square Kiosk、一般スタッフの安価なノートPCやスマートフォンからDessaの音声対話を利用する場合、推論処理をオフロードする先としてBuilderlabのホステッド環境が不可欠になる。

§③ 音声モデル単体では仕事にならない（オーケストレーションの需要）

Dessaの凄さは「流暢に人間のニュアンスで会話できること」だが、実際のビジネスの現場では、会話の裏で「社内リポジトリを検索する」「GitHubのPRを作成する」「Squareの売上データを集計する」といった実務処理が走らなければ意味がない。

• Dessa（フロントの耳と口） ＝ 音声で人間の意図を把握し、即座に相槌を打つ
• Goose / Codex / Claude（バックエンドの脳） ＝ 重いコード推論やタスク実行を行う
• Builderlab（接続ハブ） ＝ 企業の社内ツール（MCPサーバー）へのアクセス権限やAPIキーを安全に仲介・ルーティングする

この「耳と口（Dessa）」と「脳（フロンティアモデル）」と「手足（社内ツール）」をセキュアに束ねるインフラこそが、Builderlabの本体である。

§4. デスクレスワーカー（店舗・現場）へのTAM（市場規模）拡大

従来のSlackやGitHubは、PCに向き合ってキーボードを叩く「ホワイトカラー／開発者」のためのツールだった。しかし、Dessaの登場によって、Buzzは**キーボードを叩けない現場（店舗・倉庫・接客）**へと一気に市場を広げる。

Blockは2026年Q3の株主レターで、店舗向けAI「Squaremates」がBuzzの基盤上で動いていることを明かしている。また、音声対応のSquare Kioskも展開中だ。

レストランの厨房スタッフや小売店の店員が、インカムや小型端末を通じてDessa経由でBuzzのチャンネルに話しかけ、発注や在庫確認を指示する。オフィスにいる開発者はPCのBuzzでコードを書き、店舗スタッフは音声で同じBuzzのチャンネルに参加する。

「オフィスワーカー」から「現場スタッフ」まで全社を包括するインテリジェンスOSとして位置づけられることで、従来の企業向けチャットツールを遥かに超える巨大なエンタープライズ市場を狙うことが可能になる。

§5. マネタイズの5層ピラミッド

以上の要素を統合すると、BlockがBuzz / Builderlab / Dessaで狙うビジネスモデルは、以下のような多層構造として整理できる。

┌────────────────────────────────────────────────────────┐
│ 5. 自律経済・決済（L402 / Lightning / Cash App レール） │
├────────────────────────────────────────────────────────┤
│ 4. エンタープライズ・ガバナンス（SSO / 監査ログ / 認証）│
├────────────────────────────────────────────────────────┤
│ 3. ツール接続＆モデルルーティング（MCP / API ゲートウェイ）│
├────────────────────────────────────────────────────────┤
│ 2. クラウド常時稼働エージェント（Remote Agent 従量課金） │
├────────────────────────────────────────────────────────┤
│ 1. リレー・コミュニティホスティング（SaaSサブスク）    │
└────────────────────────────────────────────────────────┘
                       ▲
        【基盤】Buzz ＋ Dessa（ローカル・オープンで動作可能）

1. ホスティング課金（Relay as a Service）
   • インフラ運用をアウトソースしたいチーム向けの月額シート課金／ストレージ課金。
2. クラウド常時稼働課金（Remote Agent Runtime）
   • PCを閉じた後も自律稼働するエージェントのコンテナ実行環境に対する従量課金。
3. モデルアクセス＆ツールオーケストレーション（Model & Tool Gateway）
   • Dessaによる対話の裏で動く重いフロンティアモデルのトークンルーティングや、社内ツール接続の管理マージン。
4. エンタープライズ・ガバナンス（Security & Compliance）
   • SAML/Okta連携、アクセス権限境界、暗号署名された会話・音声・意思決定の監査ログ提供。
5. エージェント間決済・経済圏（Blockの真骨頂）
   • 将来的に自律型エージェント同士が外部APIを呼び出したりマイクロタスクを発注したりする際の、Lightning NetworkやCash Appレールを通じた決済手数料。

§6. なぜオープンソース×ローカル完結を捨象しないのか？

企業向けSaaSを作るなら、Slackのように最初からクラウド限定のクローズドサービスにした方がロックインしやすいはずだ。なぜBlockは「Nostrによるオープンプロトコル」を選び、「MacBookでローカル実行できるDessa」を作ったのか？

理由は明確だ。

1. 「全社コンテキスト」を握られる恐怖の排除
   エージェントが仕事をする時代、ワークスペースには企業のコード、チャット、財務データ、意思決定ログのすべてが蓄積される。単一のSaaSベンダーにこれらを人質に取られるロックインを企業は極度に恐れる。「いつでもローカルや自前ホストに脱出できる（イグジットの保証）」があるからこそ、企業は安心してBuzzを全社導入できる。
2. 社内基盤（ドッグフーディング）の外部化
   Block自身が「AI中心の会社になる」という方針のもと、社内で実際に使い倒して業務効率を劇的に引き上げたインフラを製品化している。自社で効果が実証されているからこそ説得力がある。
3. オープンなプロトコル上の「デフォルト・プロバイダ」の座
   Gitを誰もが無料で使えるからこそGitHubが覇権を握ったように、NostrベースのマルチプレイヤーOS（Buzz）と高精度なローカル音声対話（Dessa）を標準化し、その上で最も洗練されたマネージド環境（Builderlab）をエンタープライズに売る戦略である。

§おわりに

Buzz、Builderlab、そしてDessaの組み合わせは、単なる「オープンソース版Slack」や「単体の音声AIモデル」ではない。

• Buzz という分散型プロトコルで人とエージェントの協調空間をオープンに定義し、
• Dessa というフルデュプレックス音声モデルで現場端末やPCとの対話摩擦をゼロにし、
• Builderlab というマネージドクラウドで、常時稼働・セキュリティ・モデル連携を求める企業から対価を得る。

そして最終的には、自律型AIエージェントが経済活動を行うための金融決済レール（Blockのコア事業）へとつながっていく。

「個人にチャットボットを配る段階」から「組織全体を知能化する段階」へ。Blockが仕掛けるこの壮大な実験は、エンタープライズソフトウェアとAIエージェントの未来の標準を先取りしている。

※sakana aiによる考察