---
title: "DeepSeek HarnessにBuzzを連携：自律型Nostrメッセージゲートウェイ構築実践ガイド"
description: "DeepSeek HarnessをNostrプロトコル経由でBlockのAI協働ワークスペースBuzzに接続する詳細手順を解説。NIP-42認証やWebSocket接続、kind 40003による逐次編集ストリーミング、チャンネル単位の自律型エージェント管理、ローカル作業環境コマンド連携までを完全網羅。"
canonical_url: "https://techvoyage.dev/ja/article/bringing-buzz-to-deepseek-harness"
last_updated: "2026-10-20T09:53:48.285Z"
---

![Block Buzzチャンネルに接続されたDeepSeek Harnessメッセージゲートウェイの概要](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-buzz-nostr-gateway-overview.webp)

DeepSeek Harness（DSH）の公式プラグインである**[dsh-message-gateway](https://github.com/a792883583/dsh-message-gateway)**は、Discord、Telegram、WeChatなどの多様なメッセージングプラットフォームへDeepSeek Harnessアシスタントを拡張します。本プラグインリポジトリがフォークおよび拡張され、対応プラットフォーム一覧に**[Block製Buzzを自己ホスト：人とAIエージェントが自律的に協働する次世代共有ワークスペースの構築](/article/self-hosting-buzz-as-the-workspace-where-ai-agents-become-colleagues)**が追加されました。フォークされたオープンソースリポジトリはGitHub（ [https://github.com/Tech-Voyage-Dev/dsh-message-gateway](https://github.com/Tech-Voyage-Dev/dsh-message-gateway) ）にて公開されています。

<article-card description="Blockが開発したAI協働スペース「Buzz」のNostrリレーを、Cloudflare DNSを介してUbuntu VPS上に自己ホストする方法を解説します。暗号鍵による安全な認証のもと、人間と各種AIエージェントがチャンネルやプロジェクトの履歴を共有し、自律的に連携するセキュアな作業環境を構築しましょう。" image="https://inimages.techvoyage.dev/articles/Self-Hosting%20Buzz%20As%20The%20Workspace%20Where%20AI%20Agents%20Become%20Colleagues/JA-Self-Hosting-Buzz-As-The-Workspace-Where-AI-Agents-Become-Colleagues.webp" image-alt="深みのあるブルーとオレンジのアクセントが効いたプレミアムな16:9のテックカード。Ubuntu VPS上にBlockのBuzzリレーを自己ホストする方法を表現し、すっきりとしたガラスモーフ調のパネルの中央にタイポグラフィを配置。" label="事前準備ガイド" min-read="12" title="Block製Buzzを自己ホスト：人とAIエージェントが自律的に協働する次世代共有ワークスペースの構築" to="/article/self-hosting-buzz-as-the-workspace-where-ai-agents-become-colleagues">



</article-card>

DSHアシスタントは正式なメンバーとしてBuzzリレーに参加し、ダイレクトメッセージ（DM）や自身が@メンションされたチャンネルメッセージを受信し、Web UIと全く同一のチャット単位のエージェント実行パイプラインを通じて応答します。

## dsh-message-gatewayプラグインの内部アーキテクチャ

**dsh-message-gateway**プラグインのアーキテクチャは、大きく2つの領域に分かれています：

- **ホスト側**（Node環境）：`gateway-store`（認証情報管理、`~/.dsh/gateway.json`）、`platforms.ts`（プラットフォーム定義と接続テスト）、`routes.ts`（`/gateway/*`エンドポイント）、および`bridge-manager.ts`（常駐ブリッジ：チャットごとの独立エージェントセッションおよびストリーミング応答管理）。
- **クライアント側**（ブラウザ）：サイドバーの「**Message platforms**」設定ページ（認証情報の登録、接続確認、ステータス監視を担当）。

新しいプラットフォームを追加する際の実装手順は以下の3ステップです：

1. **ブリッジクラスの作成**：`wecom-bridge.ts`をベースに、`start/stop/status`メソッドおよび`onText(text, frame)`コールバックを実装。
2. **bridge-managerへの配線**：既存のチャット別処理パイプライン（`ensureAgentForKey` + `pendingMap`）を再利用し、プラットフォーム固有の返信用シンクに接続。
3. **ストレージおよびルーティング設定**：`/gateway/save`および`/gateway/delete`内において、**認証情報の保存でブリッジを開始し、削除で停止**するよう制御。さらに`dsh web`起動時に自動再接続するための`autoStartXxx`フラグを構成。

## Buzzブリッジの実装：Nostrプロトコルとイベントライフサイクル

Buzzブリッジの実装には**DeepSeek Harness**本体が活用されました。本実装は以下のNostrプロトコル仕様に厳密に準拠しています：

<table>
<thead>
  <tr>
    <th>
      <strong>
        項目
      </strong>
    </th>
    
    <th>
      仕様・動作詳細
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <strong>
        トランスポート
      </strong>
    </td>
    
    <td>
      NIP-42認証付きWebSocket接続（単一接続）；デフォルトは<code>
        ws://localhost:3000
      </code>
      
      ；<code>
        http(s)://
      </code>
      
      は自動的に<code>
        ws(s)://
      </code>
      
      へ正規化
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        認証
      </strong>
    </td>
    
    <td>
      AUTHイベント <code>
        kind 22242
      </code>
      
      、タグ <code>
        [["relay", url], ["challenge", challenge]]
      </code>
      
      、空のコンテンツ、エージェント秘密鍵で署名
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        購読（Subscription）
      </strong>
    </td>
    
    <td>
      <strong>
        チャンネルスコープ
      </strong>
      
      ：<code>
        REQ {"kinds":[9], "#h":[<uuid>]}
      </code>
      
      （チャンネルごとに1つのREQ）。広域な<code>
        kinds:[9]
      </code>
      
      はEOSEを受け取りますがイベントは配信されず、複数値の<code>
        #h
      </code>
      
      フィルターは<strong>
        無効
      </strong>
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        チャンネル検出
      </strong>
    </td>
    
    <td>
      チャンネルメタデータ取得用の過去ログ問い合わせ <code>
        REQ {kinds:[39000]}
      </code>
      
      （<code>
        type == "dm"
      </code>
      
      でダイレクトメッセージを判別）
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        メンバーシップ管理
      </strong>
    </td>
    
    <td>
      リアルタイム購読 <code>
        REQ {kinds:[44100,44101], "#p":[自公開鍵], since: now-60s}
      </code>
      
       — 44100=追加、44101=離脱（<code>
        p
      </code>
      
      +<code>
        h
      </code>
      
      タグを含む）。メンバー変更時は<strong>
        再接続なし
      </strong>
      
      で購読状態を即時更新
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        チャットイベント
      </strong>
    </td>
    
    <td>
      <code>
        kind 9
      </code>
      
      （タグ <code>
        ["h", channel]
      </code>
      
      、任意指定で <code>
        ["e", replyTo]
      </code>
      
      , <code>
        ["p", mention]
      </code>
      
      ）
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        インプレース編集
      </strong>
    </td>
    
    <td>
      <code>
        kind 40003
      </code>
      
      （<code>
        h
      </code>
      
       + <code>
        e
      </code>
      
      →対象ID）；コンテンツを全置換；リレーの上限64 KBに基づきペイロードは≤ 60,000 Bに制御；長文応答は分割（チャンク0は置換編集、超過分はスレッド形式の<code>
        kind 9
      </code>
      
      で追加）
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        CLOSEDフレーム制御
      </strong>
    </td>
    
    <td>
      AUTH前の<code>
        auth-required
      </code>
      
      は正常な初期化動作（AUTH完了後に購読再開）；AUTH後は制限付き再試行（最大3回、0/1/2秒バックオフ）；再接続時は全ステートを再構築
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        リレー取得上限
      </strong>
    </td>
    
    <td>
      購読あたり最大2000件の履歴イベント（<code>
        since
      </code>
      
      指定時も含め、常に最新順で取得）
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        メンション判定
      </strong>
    </td>
    
    <td>
      受信した<code>
        kind 9
      </code>
      
      の処理条件：(a) <code>
        p
      </code>
      
      タグに自公開鍵が含まれる、(b) チャンネルがDM、(c) <code>
        e
      </code>
      
      参照が自身のイベント（スレッド追跡）。自公開鍵の発信は無視（無限ループ防止）
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        送信メンション
      </strong>
    </td>
    
    <td>
      送信テキストはそのまま発行（リレー側での<code>
        @
      </code>
      
      構文検証はなし）；<code>
        p
      </code>
      
      タグには入力送信者＋言及された他の公開鍵を最大7件まで格納（合計最大8件）
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        ダイレクトメッセージ
      </strong>
    </td>
    
    <td>
      リレーローカルの平文チャンネル（<code>
        type: "dm"
      </code>
      
      メタデータ）として処理 — 本ブリッジではNIP-04/44暗号化は非使用
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        添付ファイル（受信）
      </strong>
    </td>
    
    <td>
      NIP-92 <code>
        imeta
      </code>
      
      （<code>
        url
      </code>
      
      , <code>
        sha256
      </code>
      
      , <code>
        m
      </code>
      
      ）→ 標準HTTP(S)でダウンロードしSHA-256検証、20 MB上限、1メッセージあたり最大4点；送信画像の公開は現行未サポート
    </td>
  </tr>
</tbody>
</table>

Buzzブリッジのブートストラップ接続フローは以下の通りです：

![Buzzブリッジのブートストラップ接続とNIP-42認証プロセスを示すシーケンス図](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-buzz-bootstrap.webp)### Nostrインプレース編集（Kind 40003）によるリアルタイムストリーミング

Nostrプロトコルにはネイティブな入力中インジケーターが存在せず、イベントは追記専用です。応答の体感速度とインタラクティブ性を高めるため、Buzzブリッジは**インプレース編集を用いた疑似ストリーミング**を実現しています：

![kind 40003イベントによる逐次インプレース編集でストリーミング応答を再現するフロー図](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-buzz-reply.webp)- *Buzzブリッジはまずプレースホルダーとなるkind 9イベントを発行し、エージェントの思考出力に伴ってレートリミットされたkind 40003インプレース編集イベントで段階的にメッセージを書き換えます。そしてエージェントの推論完了時に最終版を確定します。これはTelegramやDiscordブリッジで採用されている実績ある設計パターンです。*

### チャットコマンドを通じたDeepSeek Harnessワークスペースの連動

DSH Web UIにおける「ワークスペース」機能は、内部の`workspaceRegistry`サービス（`@deepseek-ai/dsh-workspace`）によって制御されています：

```typescript
const existing = await ctx.workspaceRegistry.resolveByPath(request.path);
```

Buzzブリッジはチャットコマンド`/workspace <フォルダパス>`を提供し、ローカルに実在するディレクトリをDSHへ登録できます。ゲートウェイ経由で作成された新規セッションはすべてこのフォルダに関連付けられ、Web UI上にも即座に反映されます。

![ゲートウェイ経由のチャットコマンドからDeepSeek Harnessワークスペースを登録する連携アーキテクチャ図](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-buzz-workspace.webp)設計上の3つの重要ポイント：

- **フォルダ切り替え＝新規セッション開始**：作業ディレクトリ（`cwd`）はセッション作成時にヘッダーへ固定記録されるため、途中で動的に変更することはできません。
- **フォルダの実在が必須**：`create`処理は存在しないパスの指定を即時エラーとして拒否します。
- **セキュリティ配慮**：すべてのセッションは**auto-approve**（自動承認）ポリシーで稼働するため、指定フォルダ配下のファイルに対して完全なアクセス権が付与されます。

## インストールと詳細設定のステップバイステップ手順

1. ターミナルで以下のコマンドを実行します：

```bash
dsh plugin --profile web add https://github.com/Tech-Voyage-Dev/dsh-message-gateway.git

# Start DSH web
dsh web
```

1. ブラウザでDSH Web UIが開いたら、左側メニューの「**Message platforms**」アイコンをクリックします：

![DeepSeek Harness Web UIのサイドバーに表示されたMessage platforms設定アイコン](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-web-ui-message-platforms-sidebar-icon.webp)

1. 左側リストから「**Buzz**」を選択します：

![DeepSeek HarnessメッセージゲートウェイにおけるBuzzブリッジの設定管理画面](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-message-gateway-buzz-config-panel.webp)

1. 「**Generate keypair**」をクリックしてNostrキーペアを生成します。表示された公開鍵（`npub`）を安全な場所にコピーしてください。
2. 「**Relay URL**」および購読対象のチャンネルUUIDを指定する「**Channels**」を入力します。
3. 「**Save**」ボタンをクリックします。

保存を実行すると認証情報が記録され、**ブリッジが即時起動**します。秘密鍵（`nsec`）は最重要機密として扱われ、ローカルの`~/.dsh/gateway.json`内にのみ安全に保存されます。

### Buzz Nostrリレーへのエージェント公開鍵登録

**DSHアシスタントをリレーの正規メンバーとして追加します。** 先ほど生成した公開鍵（`npub`）を指定して実行します：

```bash
docker compose exec relay buzz-admin add-member --pubkey npub123123123
```

**アシスタントを特定のチャンネルへ招待します。** リレーへ追加した段階では、まだ各チャンネル内での検索や発言はできません。`buzz-cli`を使用してチャンネルへ追加する際、`--pubkey`引数には`npub`ではなく**HEX形式**の公開鍵を指定する必要があります（`buzz-admin add-member`の実行結果にHEX値が出力されます）：

```bash
buzz channels add-member --channel <CHANNEL_UUID> --pubkey <AGENT_HEX> --role member
```

<article-card description="Nostrチャンネル、メンバーキー、AIエージェントの権限を管理するためのbuzz-cliのインストールと設定手順を解説します。" image="https://inimages.techvoyage.dev/articles/Self-Hosting%20Buzz%20As%20The%20Workspace%20Where%20AI%20Agents%20Become%20Colleagues/JA-Self-Hosting-Buzz-As-The-Workspace-Where-AI-Agents-Become-Colleagues.webp" image-alt="深みのあるブルーとオレンジのアクセントが効いたプレミアムな16:9のテックカード。Ubuntu VPS上にBlockのBuzzリレーを自己ホストする方法を表現し、すっきりとしたガラスモーフ調のパネルの中央にタイポグラフィを配置。" label="CLIガイド" min-read="5" title="buzz-cliのインストールと使用方法" to="/article/self-hosting-buzz-as-the-workspace-where-ai-agents-become-colleagues#install-buzz-cli">



</article-card>

`buzz-cli`を使用して、Nostrリレー上のDSHアシスタントの表示名を分かりやすい名前に更新します：

![buzz-cliを使用してNostrリレー上のDSHアシスタント表示名を更新する様子](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-assistant-buzz-cli-profile-update.webp)

DSHアシスタントへ**Wave**（BuzzのDM挨拶アクション）を送信します。アシスタントから応答が返れば接続成功です：

![Buzz内でDSHアシスタントにWaveメッセージをDM送信して接続テストを行う様子](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-buzz-dm-wave-greeting-reply.webp)

*DSHアシスタントへDMとしてWaveを送信 — ブリッジが正常に応答している様子。*

### `/workspace`によるローカルフォルダ連携の有効化

デフォルトではセキュリティ保護のため`allowWorkspace`設定が`false`になっているため、初回実行時の`/workspace`コマンドは拒絶されます：

![allowWorkspaceが無効な状態で/workspaceコマンドを実行した際のエラー通知画面](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-buzz-workspace-command-rejected-error.webp)

`~/.dsh/profiles/web/cordis.patch.yml`を編集して機能を有効化し、`dsh web`を再起動します：

```yml
- id: ui-message-gateway
  config:
    allowWorkspace: true
```

再起動後の画面：

![Buzz内で/workspaceコマンドを実行しワークスペース登録が成功した確認画面](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-buzz-workspace-command-success-confirmation.webp)

重要な注意点：この指定は、ワークスペースフォルダ（スクリーンショット内の`TechVoyage`）がデフォルトのユーザーホーム配下に存在することを前提としています。それ以外の階層を指定する場合はフルパスで入力してください。Buzz経由で登録されたセッションは、DeepSeek Harness Web UI上にも連動して表示されます。

![Buzzから自動同期されDeepSeek Harness Web UI上に表示された作業セッション](https://inimages.techvoyage.dev/articles/Bringing%20Buzz%20to%20DeepSeek%20Harness/dsh-web-ui-synced-workspace-session.webp)

### Buzz上で利用可能なコマンド一覧

他プラットフォームで利用可能な主要コマンドは、Buzz環境でも完全に対応しています：

<table>
<thead>
  <tr>
    <th>
      コマンド
    </th>
    
    <th>
      機能概要
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <code>
        /workspace <folder>
      </code>
    </td>
    
    <td>
      既存のフォルダをチャットの作業スペースとして登録（設定ファイルでの事前有効化が必要）
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        /help
      </code>
    </td>
    
    <td>
      利用可能なコマンド一覧を表示
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        /time
      </code>
    </td>
    
    <td>
      現在のサーバー時刻を表示
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        /new
      </code>
    </td>
    
    <td>
      新しいクリーンなセッションを開始
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        /clear
      </code>
    </td>
    
    <td>
      現在の会話履歴をクリア
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        /status
      </code>
    </td>
    
    <td>
      現在のブリッジ接続ステータスを表示
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        /stats
      </code>
    </td>
    
    <td>
      チャット数および全プラットフォームのブリッジ稼働状態を表示（Buzzを含む）
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        /commands
      </code>
    </td>
    
    <td>
      全コマンドの詳細な説明を表示
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        @path/to/file
      </code>
    </td>
    
    <td>
      Webの@メンションと同様に機能：モデルがワークスペース相対パスでファイルを読み込み。単体の<code>
        @
      </code>
      
      、<code>
        @prefix
      </code>
      
      、または<code>
        /files <prefix>
      </code>
      
      で一致する候補を一覧表示
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        /model
      </code>
    </td>
    
    <td>
      <code>
        [provider model effort]
      </code>
      
       — 稼働中のLLMカタログと検証の上、モデルおよび推論レベルを変更。<code>
        /model
      </code>
      
      単体で選択肢一覧、<code>
        /model reset
      </code>
      
      で初期設定にリセット
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        /effort
      </code>
    </td>
    
    <td>
      <code>
        <id>
      </code>
      
       モデルの推論エフォート値のみを調整。<code>
        /effort reset
      </code>
      
      でデフォルト値に戻す
    </td>
  </tr>
</tbody>
</table>

### セキュリティ設計の要点

- **nsec（秘密鍵）の厳格管理**：`~/.dsh/gateway.json`内でのみ保管（パーミッション0600、アトミック書き込み）。`/gateway/list`などのAPIやログに出力されることは一切ありません。
- **暗号検証の徹底**：受信したすべてのイベントは、エージェントへ渡る前に**署名検証**（`verifyEvent`）、重複排除、自己発信フィルター、メンション検証を通過します。
- **ワークスペース登録の二重防御**：ゲートウェイセッションが自動承認で動作するため、誤ったフォルダ公開を防ぐ目的で明示的な設定有効化（`allowWorkspace: true`）を必須としています。

## まとめ：Buzzによる分散型AIコラボレーションの実現

`dsh-message-gateway`にBuzzを追加する上での最大の技術的挑戦は、Nostrプロトコルが要求する規約の厳密なハンドリングにありました。既存のプラグイン設計がセッション管理やコマンドルーティングを美しく抽象化していたため、イベントの送受信と逐次編集ストリーミングが確立されてからは、極めてスムーズかつ堅牢に稼働させることができました。

## 参考リンク：

- [dsh-message-gateway architecture guide](https://github.com/a792883583/dsh-message-gateway/blob/main/docs/architecture.md) — アーキテクチャガイド、拡張レシピ、セキュリティノート
- [nostr-tools](https://github.com/nbd-wtf/nostr-tools) — 内部で使用されている主要Nostrライブラリ
- [deer-flow IM channel connections](https://github.com/bytedance/deer-flow/blob/main/backend/docs/IM_CHANNEL_CONNECTIONS.md) — インスタントメッセージング接続パターンの設計資料