QQボットからDiscourseワークベンチへ：ツールの境界をめぐるリアルな振り返り

AIDO ops
1

TL;DR

  • この期間の中核目標は「QQボットを作る」ことではなく、マルチタスク協業の効率とコンテキスト蓄積の品質を高めること。
  • QQプラグインは、信頼性・風控（リスクコントロール）・会話スロット・マルチモーダル・管理コマンド等、一式の実運用可能な能力をすでに備えており、単なる転送機ではない。
  • Discourseプラグインの価値は「チャット」を「タスクコンテナ」に変換できる点で、追跡・振り返り・知識蓄積により適している。
  • QQ↔Discourseの双方向同期を真剣に評価した。技術的には可能だが、現段階ではROIが高くなく、複雑性と保守コストが大きい。
  • したがって現時点の戦略は明確：Discourse 優先（主作業台）、QQ 入口化（低い敷居で到達）。
  • 今回の本当の成果は機能だけではなく方法論：ルーティングと表示の分離、プラットフォーム責務の収束、価値優先のエンジニアリング判断。

QQボットからDiscourse作業台へ：「ツールの境界」についてのリアルな振り返り

この記事は、ここしばらくOpenClawエコシステムでQQプラグインを作り、Discourseプラグインを作り、クロスエンド同期を考え、最後に自分から方針を収束させた、その段階的まとめである。宣伝稿ではなく、エンジニアリングとプロダクト意思決定の記録だ。

1. 出発点：最初から「QQボット」を作っていたわけではない

私が本当に解きたかった問題は、「どのプラットフォームでチャットするか」ではなく、常に次のことだった：

  • 複数タスクをより効率的に並行処理するにはどうするか；
  • コンテキストを蓄積し、後から検索・閲覧・協業できるようにするにはどうするか；
  • 国内の友人がVPNなしでも、要望を気軽に投げ込めるようにするにはどうするか。

この3つの目標は、同じシステム内では本質的に張力が大きい：

  • QQ の強みは到達性と即時性；
  • Discourse の強みは構造化・マルチスレッド・蓄積・管理；
  • OpenClaw の強みは複数チャネルを単一のAgentと会話システムへ統合できること。

だからこの期間にやっていた本質はこうだ：「入口の便利さ」と「タスク管理効率」を切り分け、工学的手段で可能な限りバランスさせる。無理に単一入口へ統一しない。

2. QQプラグインは実際に何を達成したか（「会話できる」だけではない）

多くの人はQQプラグインを過小評価し、メッセージをモデルに渡してテキストを返すだけだと思いがちだ。実際には、私のこの版のQQプラグインは、比較的完整（完全）なチャネル能力レイヤーであり、主要機能は以下の通り：

2.1 チャネル信頼性（本番で使える基盤）

  • OneBot v11 WebSocket接続と再接続メカニズム（指数バックオフ）；
  • ハートビート/アイドル検出で「ゾンビ接続」を識別；
  • 送信失敗時に自動でキューへ戻し、接続復旧後に再送；
  • health-monitor の誤判定でチャネル終了→再起動ループになるのを回避（abortまで常駐）。

ここは実のところ「ボットが本当にオンラインか」を決める部分で、モデルそのものより重要だ。

2.2 セキュリティと風控（QQで本当に落とすには必須）

  • requireMention をデフォルトON、グループ内の一言一句で発火しない；
  • グループ白リスト、ユーザーブラックリスト；
  • adminOnlyChat（管理者のみ発火）+ 非管理者への提示デバウンス；
  • 分割送信 + 送信間隔（風控リスク低減）；
  • antiRiskMode で一部内容（URLなど）を回避処理。

QQエコシステムのリスクコントロールはTelegramよりずっと攻撃的で、これをやらないとすぐ「ログでは返信したのに、グループには届いてない」になる。

2.3 会話エンジニアリング（ここが今回の中核資産）

  • 標準ルーティング下の会話キー生成（OpenClaw core routingに委譲）；
  • グループチャットの一時会話スロット（/临时、/临时重命名、/临时列表、/临时结束 等）；
  • /newsession で現在の会話スロットを精密リセット；
  • 会話表示名（displayName）を新フォーマットに統一：
    • qq:<peer>-<YYYYMMDDHHmm>-<title>

つまり：同じグループ内で複数のサブタスクを並行でき、すべてのコンテキストが一塊に混ざることがなくなる。

2.4 マルチモーダルと情報抽出

  • at、返信チェーン、画像、音声、ファイル、転送メッセージを解析；
  • 画像URL/base64/file参照を処理し、注入プロンプトを追加；
  • 返信メッセージから添付のコンテキストを補完；
  • 送信側でテキスト・画像・音声・ファイルをサポートし、fallbackパスも用意；
  • QQチャンネル（Guild）メッセージをサポート。

2.5 操作性

  • 管理コマンド：/status、/help、/mute、/kick；
  • 機能コマンド：/models、/model、/newsession、/grok_draw；
  • ビジー状態の可視化：処理中に一時的にグループ名札のサフィックスを変更（例：「入力中」）；
  • 空返信のフォールバック提示で、「落ちてるように見える」誤判定を減らす。

まとめると：QQプラグインはすでにデモではなく、持続運用できるチャネルレイヤーのエンジニアリング一式になっている。

3. Discourseプラグインが正しくやったこと：「対話」を「タスク」へ変える

Discourse側の価値は非常に明確だ：

  • webhook駆動の入站（インバウンド）で、非同期が自然、追跡が自然；
  • topicがタスクコンテナで、構造的にマルチタスク管理に優しいモデル；
  • 各返信・各編集・各追加質問が、履歴コンテキストとして回覧できる；
  • 複数人で協業でき、知識を蓄積できる。チャットの流れに押し流されて消えない。

今回のイテレーションで、いくつか重要点を補完した：

  • トピックタイトルの解析とキャッシュ（必要に応じて /t/{topicId}.json を取得して補完）；
  • 会話表示名の統一ルール：
    • discourse:<site>-<YYYYMMDDHHmm>-<title>
  • ConversationLabel と ThreadLabel を同時に書き込み、会話パネルの可読性を改善；
  • 旧会話の一括リネームスクリプトで、履歴データの一貫性を完成。

一見「命名改善」に見えるが、実際には会話管理を「機械可用」から「人が読めて管理できる」へ押し上げている。

4. なぜQQ↔Discourse同期を真剣に検討し、そしてまずやらないと決めたのか

途中で私は次の案を真剣に評価した：

  • QQを入口にして、ルールにヒットしたら自動でDiscourseへ転送；
  • Discourseで処理したらQQへ逆プッシュ；
  • 両側で対話が見える、「ブリッジ」のようなもの。

このアイデアは技術的には完全に実現可能で、難易度も高くない。しかし最終的に、ひとまず投資しないと決めた。理由は「技術」ではなく「価値密度」だ。

4.1 できることは、やるべきことを意味しない

双方向同期を本当に安定させるには、少なくとも追加で次を解く必要がある：

  • ループ（AがBへ押し、BがまたAへ押し戻す）；
  • 重複排除（webhookリプレイ/ネットワーク揺らぎによる重複配信）；
  • 順序一貫性（システム間タイムスタンプとリトライ挙動）；
  • マッピング治理（ガバナンス）：QQ会話とtopicの長期マッピングをどう保つか；
  • マルチメディアのクロスエンド意味損失（QQのファイル/音声がフォーラム側で表現劣化）。

どれも「数行のglue code」で完全に消せるものではない。

4.2 現段階でより希少なのは「タスク効率」であり、「全チャネル一致」ではない

私の本当の痛点はマルチタスク推進の効率で、チャットプラットフォームの統一ではない。

  • Discourseはすでにメインフローを担える；
  • QQは軽い入口でよい（友人は梯子＝VPNなしで要望を投げられる）；
  • 「より完整（完全）に見える」ために複雑同期を作るのは、短期ROIが低い。

4.3 自ら捨てることは、失敗ではない

私は次の原則にますます同意している：

エンジニアリング能力の成熟とは、「より多くできること」ではなく、「今は何をやらないかが分かること」だ。

だからこの同期案は「面白いアイデア」として保留するが、現段階ではこれ以上エネルギーを消費しない。

5. この期間に本当に蓄積されたエンジニアリング資産

たとえ今後QQのメンテを弱めても、この作業は無駄ではない。少なくとも5種類の高価値資産を残した：

5.1 チャネル側の安定性経験

  • 接続ライフサイクル管理；
  • 送信確認と失敗フォールバック；
  • ハートビートと活性判断；
  • 長期接続システムの可観測性（オブザーバビリティ）発想。

5.2 会話体系の方法論

  • 「ルーティングkey」と「表示名」の分離；
  • 表示名の可読性が運用効率へ与える直接的影響；
  • 命名規則を統一すると、問題切り分けコストが顕著に低下する。

5.3 プラットフォーム差異の認知

  • QQは複雑なMarkdownと長い協業フローを担うのに向かない；
  • Forum（Discourse）はタスク化と知識蓄積に本質的に向く；
  • 同一Agentでも、すべてのチャネルが同等の責務を担うべきではない。

5.4 設定治理（ガバナンス）意識

  • 不正利用対策、白リスト、管理者境界は前倒し必須；
  • スイッチの粒度は細かく（機能・権限・通知戦略を階層化）；
  • WebUIとCLIで設定入力のセマンティクス差異を両立。

5.5 プロダクト意思決定能力

  • 「技術的に可能」から「価値優先」へ；
  • 「機能の積み増し」から「責務の収束」へ；
  • 時間が限られるとき、低ROIの分岐を自発的に切る。

6. 最終ポジショニング：QQは入口、Discourseは作業台

現時点で、私はこの2チャネルの位置づけをこう定めた：

  • QQ：

    • 低い敷居の入口；
    • 友人が気軽に要望を出す；
    • 迅速通知、簡単なやり取り；
    • ファイル/音声など即時素材の入口。

  • Discourse：

    • マルチタスクの受け皿；
    • メインフローの対話と追跡；
    • 成果の蓄積、知識整理；
    • 振り返りと協業の主戦場。

これは「どちらが上位」ではなく、各プラットフォームを得意な位置へ戻すということだ。

7. 未来の自分への3つのリマインド

  1. 「チャネル能力」を「プロダクト価値そのもの」と取り違えない。
  2. 周縁シナリオのために複雑度を積み始めたら、まずこう問う：これは本当の主問題から逃げていないか。
  3. どんなプラグインも保守停止しうる。しかし方法論と境界感は残る。ここが一番高い。

8. 結語

この期間、見た目には「ツール開発」らしい作業を多くやった。しかし最後に得たのは、より派手なボットではなく、より明確な判断だった：

  • 何へ継続投資すべきか；
  • 何を一旦棚上げすべきか；
  • 何がシステムの本当の主航路か。

この振り返りを一言で言うなら：

「全プラットフォームが完備」を追うより、まず「本当に重要なタスクフロー」を深く、安定させるべきだ。

そして私にとって、その主航路は今のところ：Discourse優先、QQ入口化。