DeepSeek HarnessにBuzzを連携：自律型Nostrメッセージゲートウェイ構築実践ガイド
DeepSeek HarnessをNostrプロトコル経由でBlockのAI協働ワークスペースBuzzに接続する詳細手順を解説。NIP-42認証やWebSocket接続、kind 40003による逐次編集ストリーミング、チャンネル単位の自律型エージェント管理、ローカル作業環境コマンド連携までを完全網羅。
目次
DeepSeek Harness（DSH）の公式プラグインである**dsh-message-gatewayは、Discord、Telegram、WeChatなどの多様なメッセージングプラットフォームへDeepSeek Harnessアシスタントを拡張します。本プラグインリポジトリがフォークおよび拡張され、対応プラットフォーム一覧にBlock製Buzzを自己ホスト：人とAIエージェントが自律的に協働する次世代共有ワークスペースの構築**が追加されました。フォークされたオープンソースリポジトリはGitHub（ https://github.com/Tech-Voyage-Dev/dsh-message-gateway ）にて公開されています。
事前準備ガイド
Block製Buzzを自己ホスト：人とAIエージェントが自律的に協働する次世代共有ワークスペースの構築
Blockが開発したAI協働スペース「Buzz」のNostrリレーを、Cloudflare DNSを介してUbuntu VPS上に自己ホストする方法を解説します。暗号鍵による安全な認証のもと、人間と各種AIエージェントがチャンネルやプロジェクトの履歴を共有し、自律的に連携するセキュアな作業環境を構築しましょう。
12分で読める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ステップです：
- ブリッジクラスの作成：
wecom-bridge.tsをベースに、start/stop/statusメソッドおよびonText(text, frame)コールバックを実装。 - bridge-managerへの配線：既存のチャット別処理パイプライン（
ensureAgentForKey+pendingMap）を再利用し、プラットフォーム固有の返信用シンクに接続。 - ストレージおよびルーティング設定：
/gateway/saveおよび/gateway/delete内において、認証情報の保存でブリッジを開始し、削除で停止するよう制御。さらにdsh web起動時に自動再接続するためのautoStartXxxフラグを構成。
Buzzブリッジの実装：Nostrプロトコルとイベントライフサイクル
Buzzブリッジの実装にはDeepSeek Harness本体が活用されました。本実装は以下のNostrプロトコル仕様に厳密に準拠しています：
| 項目 | 仕様・動作詳細 |
|---|---|
| トランスポート | NIP-42認証付きWebSocket接続（単一接続）；デフォルトはws://localhost:3000；http(s)://は自動的にws(s)://へ正規化 |
| 認証 | AUTHイベント kind 22242、タグ [["relay", url], ["challenge", challenge]]、空のコンテンツ、エージェント秘密鍵で署名 |
| 購読（Subscription） | チャンネルスコープ：REQ {"kinds":[9], "#h":[<uuid>]}（チャンネルごとに1つのREQ）。広域なkinds:[9]はEOSEを受け取りますがイベントは配信されず、複数値の#hフィルターは無効 |
| チャンネル検出 | チャンネルメタデータ取得用の過去ログ問い合わせ REQ {kinds:[39000]}（type == "dm"でダイレクトメッセージを判別） |
| メンバーシップ管理 | リアルタイム購読 REQ {kinds:[44100,44101], "#p":[自公開鍵], since: now-60s} — 44100=追加、44101=離脱（p+hタグを含む）。メンバー変更時は再接続なしで購読状態を即時更新 |
| チャットイベント | kind 9（タグ ["h", channel]、任意指定で ["e", replyTo], ["p", mention]） |
| インプレース編集 | kind 40003（h + e→対象ID）；コンテンツを全置換；リレーの上限64 KBに基づきペイロードは≤ 60,000 Bに制御；長文応答は分割（チャンク0は置換編集、超過分はスレッド形式のkind 9で追加） |
| CLOSEDフレーム制御 | AUTH前のauth-requiredは正常な初期化動作（AUTH完了後に購読再開）；AUTH後は制限付き再試行（最大3回、0/1/2秒バックオフ）；再接続時は全ステートを再構築 |
| リレー取得上限 | 購読あたり最大2000件の履歴イベント（since指定時も含め、常に最新順で取得） |
| メンション判定 | 受信したkind 9の処理条件：(a) pタグに自公開鍵が含まれる、(b) チャンネルがDM、(c) e参照が自身のイベント（スレッド追跡）。自公開鍵の発信は無視（無限ループ防止） |
| 送信メンション | 送信テキストはそのまま発行（リレー側での@構文検証はなし）；pタグには入力送信者＋言及された他の公開鍵を最大7件まで格納（合計最大8件） |
| ダイレクトメッセージ | リレーローカルの平文チャンネル（type: "dm"メタデータ）として処理 — 本ブリッジではNIP-04/44暗号化は非使用 |
| 添付ファイル（受信） | NIP-92 imeta（url, sha256, m）→ 標準HTTP(S)でダウンロードしSHA-256検証、20 MB上限、1メッセージあたり最大4点；送信画像の公開は現行未サポート |
Buzzブリッジのブートストラップ接続フローは以下の通りです：
Nostrインプレース編集（Kind 40003）によるリアルタイムストリーミング
Nostrプロトコルにはネイティブな入力中インジケーターが存在せず、イベントは追記専用です。応答の体感速度とインタラクティブ性を高めるため、Buzzブリッジはインプレース編集を用いた疑似ストリーミングを実現しています：
- Buzzブリッジはまずプレースホルダーとなる
kind 9イベントを発行し、エージェントの思考出力に伴ってレートリミットされたkind 40003インプレース編集イベントで段階的にメッセージを書き換えます。そしてエージェントの推論完了時に最終版を確定します。これはTelegramやDiscordブリッジで採用されている実績ある設計パターンです。
チャットコマンドを通じたDeepSeek Harnessワークスペースの連動
DSH Web UIにおける「ワークスペース」機能は、内部のworkspaceRegistryサービス（@deepseek-ai/dsh-workspace）によって制御されています：
const existing = await ctx.workspaceRegistry.resolveByPath(request.path);
Buzzブリッジはチャットコマンド/workspace <フォルダパス>を提供し、ローカルに実在するディレクトリをDSHへ登録できます。ゲートウェイ経由で作成された新規セッションはすべてこのフォルダに関連付けられ、Web UI上にも即座に反映されます。
設計上の3つの重要ポイント：
- フォルダ切り替え＝新規セッション開始：作業ディレクトリ（
cwd）はセッション作成時にヘッダーへ固定記録されるため、途中で動的に変更することはできません。 - フォルダの実在が必須：
create処理は存在しないパスの指定を即時エラーとして拒否します。 - セキュリティ配慮：すべてのセッションはauto-approve（自動承認）ポリシーで稼働するため、指定フォルダ配下のファイルに対して完全なアクセス権が付与されます。
インストールと詳細設定のステップバイステップ手順
- ターミナルで以下のコマンドを実行します：
dsh plugin --profile web add https://github.com/Tech-Voyage-Dev/dsh-message-gateway.git
# Start DSH web
dsh web
- ブラウザでDSH Web UIが開いたら、左側メニューの「Message platforms」アイコンをクリックします：
- 左側リストから「Buzz」を選択します：
- 「Generate keypair」をクリックしてNostrキーペアを生成します。表示された公開鍵（
npub）を安全な場所にコピーしてください。 - 「Relay URL」および購読対象のチャンネルUUIDを指定する「Channels」を入力します。
- 「Save」ボタンをクリックします。
保存を実行すると認証情報が記録され、ブリッジが即時起動します。秘密鍵（nsec）は最重要機密として扱われ、ローカルの~/.dsh/gateway.json内にのみ安全に保存されます。
Buzz Nostrリレーへのエージェント公開鍵登録
DSHアシスタントをリレーの正規メンバーとして追加します。 先ほど生成した公開鍵（npub）を指定して実行します：
docker compose exec relay buzz-admin add-member --pubkey npub123123123
アシスタントを特定のチャンネルへ招待します。 リレーへ追加した段階では、まだ各チャンネル内での検索や発言はできません。buzz-cliを使用してチャンネルへ追加する際、--pubkey引数にはnpubではなくHEX形式の公開鍵を指定する必要があります（buzz-admin add-memberの実行結果にHEX値が出力されます）：
buzz channels add-member --channel <CHANNEL_UUID> --pubkey <AGENT_HEX> --role member
CLIガイド
buzz-cliのインストールと使用方法
Nostrチャンネル、メンバーキー、AIエージェントの権限を管理するためのbuzz-cliのインストールと設定手順を解説します。
5分で読めるbuzz-cliを使用して、Nostrリレー上のDSHアシスタントの表示名を分かりやすい名前に更新します：
DSHアシスタントへWave（BuzzのDM挨拶アクション）を送信します。アシスタントから応答が返れば接続成功です：
DSHアシスタントへDMとしてWaveを送信 — ブリッジが正常に応答している様子。
/workspaceによるローカルフォルダ連携の有効化
デフォルトではセキュリティ保護のためallowWorkspace設定がfalseになっているため、初回実行時の/workspaceコマンドは拒絶されます：
~/.dsh/profiles/web/cordis.patch.ymlを編集して機能を有効化し、dsh webを再起動します：
- id: ui-message-gateway
config:
allowWorkspace: true
再起動後の画面：
重要な注意点：この指定は、ワークスペースフォルダ（スクリーンショット内のTechVoyage）がデフォルトのユーザーホーム配下に存在することを前提としています。それ以外の階層を指定する場合はフルパスで入力してください。Buzz経由で登録されたセッションは、DeepSeek Harness Web UI上にも連動して表示されます。
Buzz上で利用可能なコマンド一覧
他プラットフォームで利用可能な主要コマンドは、Buzz環境でも完全に対応しています：
| コマンド | 機能概要 |
|---|---|
/workspace <folder> | 既存のフォルダをチャットの作業スペースとして登録（設定ファイルでの事前有効化が必要） |
/help | 利用可能なコマンド一覧を表示 |
/time | 現在のサーバー時刻を表示 |
/new | 新しいクリーンなセッションを開始 |
/clear | 現在の会話履歴をクリア |
/status | 現在のブリッジ接続ステータスを表示 |
/stats | チャット数および全プラットフォームのブリッジ稼働状態を表示（Buzzを含む） |
/commands | 全コマンドの詳細な説明を表示 |
@path/to/file | Webの@メンションと同様に機能：モデルがワークスペース相対パスでファイルを読み込み。単体の@、@prefix、または/files <prefix>で一致する候補を一覧表示 |
/model | [provider model effort] — 稼働中のLLMカタログと検証の上、モデルおよび推論レベルを変更。/model単体で選択肢一覧、/model resetで初期設定にリセット |
/effort | <id> モデルの推論エフォート値のみを調整。/effort resetでデフォルト値に戻す |
セキュリティ設計の要点
- nsec（秘密鍵）の厳格管理：
~/.dsh/gateway.json内でのみ保管（パーミッション0600、アトミック書き込み）。/gateway/listなどのAPIやログに出力されることは一切ありません。 - 暗号検証の徹底：受信したすべてのイベントは、エージェントへ渡る前に署名検証（
verifyEvent）、重複排除、自己発信フィルター、メンション検証を通過します。 - ワークスペース登録の二重防御：ゲートウェイセッションが自動承認で動作するため、誤ったフォルダ公開を防ぐ目的で明示的な設定有効化（
allowWorkspace: true）を必須としています。
まとめ：Buzzによる分散型AIコラボレーションの実現
dsh-message-gatewayにBuzzを追加する上での最大の技術的挑戦は、Nostrプロトコルが要求する規約の厳密なハンドリングにありました。既存のプラグイン設計がセッション管理やコマンドルーティングを美しく抽象化していたため、イベントの送受信と逐次編集ストリーミングが確立されてからは、極めてスムーズかつ堅牢に稼働させることができました。
参考リンク：
- dsh-message-gateway architecture guide — アーキテクチャガイド、拡張レシピ、セキュリティノート
- nostr-tools — 内部で使用されている主要Nostrライブラリ
- deer-flow IM channel connections — インスタントメッセージング接続パターンの設計資料
関連記事
コラボレーション
Block製Buzzを自己ホスト：人とAIエージェントが自律的に協働する次世代共有ワークスペースの構築
Blockが開発したAI協働スペース「Buzz」のNostrリレーを、Cloudflare DNSを介してUbuntu VPS上に自己ホストする方法を解説します。暗号鍵による安全な認証のもと、人間と各種AIエージェントがチャンネルやプロジェクトの履歴を共有し、自律的に連携するセキュアな作業環境を構築しましょう。
9分で読める
AIとエージェント
AIエージェントのスキルとは？その基本概念から作成方法、再利用可能なワークフローの構築までを徹底解説
AIエージェントのスキルとは何か、また状況に応じて詳細なシステム手順を効率的にロードする「段階的開示（Progressive Disclosure）」の仕組みを詳しく解説。開発者向けに再利用可能で強力なカスタムスキルを一から自作し、実開発に適用するための実践的な手順と手法を余すところなく紹介します。
2分で読める
AIとエージェント
Cloudflare WARPでHermes Agentをプライベートネットワークに公開する方法
ファイアウォールのインバウンドポートを開くことなく、Cloudflare WARPとZero Trustを使用してグローバルかつ安全にHermes Agentへアクセスし、プライベートネットワークに公開する方法を詳しく解説します。
5分で読める