WeChat を Claude Code に接続する：WeChat Bot 設定の実践、メッセージを自動的にワークフローへ変換する

¶ WeChatに足りないのはメッセージではなく、メッセージ後の自動処理

多くのチームが毎日WeChatで仕事を処理しています：顧客が製品の設定方法を尋ねると、もう一度説明する必要がある；ユーザーがグループで問題をフィードバックすると、チケットシステムにコピーする必要がある；サービスに異常が発生すると、担当者を見つけて通知する必要がある；一日中多くの会話をした後、最後に問題とToDoを手動で整理する必要がある。

本当に時間がかかるのは、しばしば「メッセージを受信したこと」ではなく、メッセージを受信した後の繰り返し作業です。

WeChatメッセージが直接AIと業務システムに入ることができれば、チャットウィンドウは単なるコミュニケーションツールではなく、業務の入口にもなります。

AceDataCloud WeChat Bot はこのような接続基盤を提供します：ユーザーごとに独立したクラウドホストをデプロイし、実際のWeChatデスクトップクライアントを実行したうえで、HTTPとWebSocketを通じて外部にメッセージ機能を提供します；AIによる自動返信が必要な場合は、さらにWisdomChannelを通じてClaude Codeに接続できます。[1]

ただし、これをうまく活用するには、まず3つの層を区別する必要があります：

WeChat BotはWeChat接続を解決し、WisdomChannelはAI接続を解決し、業務システムは具体的な業務アクションを解決します。

本稿は製品ページおよびWisdomChannelの公開ドキュメントに基づいて整理したものであり、設定例は本稿の著者による実際のデプロイテストを経ていません。画像はAIが生成したアーキテクチャおよびシナリオの模式図であり、製品コンソールのスクリーンショットではありません；実際の機能、バージョンおよび料金は、現在のサービスページおよびドキュメントに準じます。

¶ 一、技術的特徴：メッセージに返信できるだけでなく、WeChatをシステムインターフェースにできる

WeChat Bot技術アーキテクチャ：WeChatデスクトップクライアント、メッセージインターフェース、Claude Codeと業務システム

図1：WeChat、メッセージインターフェース、AIおよび業務システム間の関係を示す技術アーキテクチャの模式図。

¶ 1. 独立クラウドホストが実際のWeChatデスクトップクライアントを担う

製品紹介によると、各ユーザーには1台の独立クラウドホストが対応し、スマートフォン版WeChatでQRコードをスキャンしてログインします；基盤ではWisdomが実際のWeChatデスクトップクライアントを駆動してメッセージの送受信を行い、サードパーティのWebプロトコル接続を採用するものではありません。[1]

この設計は、WeChatの実行環境を日常のオフィス環境から分離します：業務プログラムはインターフェースを通じてインスタンスにアクセスし、デスクトップを直接操作する必要がありません；WeChatのログイン状態は独立して確認できます；異常が発生した場合には、調査できる専用のインスタンス環境があります。

注意すべき点は、これはWeChat公式アカウントまたはWeCom公式ボットインターフェースの同義的な代替品ではないということです。これはデスクトップクライアントおよびその実行環境に依存しており、これに基づいて「決してオフラインにならない」「バージョン変更の影響を受けない」または「アカウントリスクがない」と推論することはできません。

¶ 2. HTTPは操作を担い、WebSocketはリアルタイムイベントを担う

製品ページに記載されているコア機能には、以下が含まれます：[1]

機能	ページで明示的に提供されているエンドポイントまたは説明	解決できる問題
メッセージ送信	`/api/messages/send`、テキスト、画像、ファイル、動画をサポート	通知、返信、資料送信
リアルタイムメッセージ監視	WebSocket `/ws`	新しいメッセージによる処理フローのトリガー
履歴メッセージと検索	会話履歴の取得、更新、キーワードによる検索	コミュニケーションの振り返り、品質検査、分析
連絡先と会話の同期	連絡先、会話リストの同期	業務側の会話情報の維持
ステータス確認	`/api/status`、`/ping`	オンライン状態とサービス可用性の確認
運用と認証	独立した `API_TOKEN`、QRコードログイン、VNCエントリポイント	アクセス制御と障害調査

2種類のインターフェースは簡単に次のように理解できます：HTTPは「このメッセージを送信してください」または「現在の状態を照会してください」；WebSocketは「新しいメッセージがあります。処理を開始してください」です。

WeChatメッセージを受信
    ↓
会話、送信者およびアクセス権限を確認
    ↓
AIが回答を生成、または業務プログラムがリクエストを処理
    ↓
送信インターフェースを通じて結果を返す

本番業務に接続する場合は、メッセージの重複排除、切断後の再接続、リトライおよび頻度制御を別途実装することを推奨します。プロトコルの詳細を確認する前に、メッセージが必ず重複しないと仮定してはならず、インターフェースリクエストの成功をユーザーが既読であることと直接同一視してもなりません。

¶ 3. WisdomChannelはメッセージチャネルをClaude Codeに接続する

WisdomChannelはClaude Code向けのWeChat Channelプラグインです。HTTP/WebSocketを通じてリモートのWisdomサービスに接続するため、WeChatデスクトップクライアントと同じマシン上で実行する必要はありません。[2]

モード	動作方式	適した用途
インタラクティブMCP Channel	WeChatメッセージを実行中のClaude Codeセッションにプッシュする	開発デバッグ、人が常駐する補助業務
`wisdom-channel bridge`	許可されたメッセージを受信し、`claude -p`を呼び出して、返信をWeChatへ送り返す	インタラクティブターミナルを必要としない自動返信

バックグラウンドでの自動返信は、bridgeモードから始めるのがより適しています。 継続的に接続されたインタラクティブなClaude Codeターミナルは必要ありませんが、bridgeプロセス自体は引き続き継続的に稼働する必要があります。[2]

¶ 4. 自動返信にはコンテキストがあり、トリガー境界もある

WisdomChannelは個人チャットとグループチャットをサポートします；グループチャットでは、@された場合にのみトリガーされ、アクセス方針と組み合わせてメッセージを処理するかどうかを決定します。bridgeは返信を構築する際に、送信者、グループチャット、引用メッセージおよび直近の会話コンテキストも使用します。WECHAT_CONTEXT_MESSAGES のデフォルト値は 8 で、0 に設定すると直近のメッセージコンテキストを無効にできます。[2]

たとえば、ユーザーが先に「Windowsではどのように設定すればよいですか」と尋ね、その後に「ではTokenはどこに入力しますか」と続けて尋ねた場合、2番目の文は前の文脈と組み合わせて理解する必要があります。直近のメッセージコンテキストはこのような追加質問の処理に役立ちますが、システムが本来的に完全かつ永続的なチャット記憶を持つことを意味するものではありません。

¶ 5. 権限制御は追加要素ではなく、コア機能である

WeChatがツールを呼び出せるAIに接続される場合、最も重要な問題は単に「回答できるかどうか」ではなく、次のことでもあります：誰がAIに何をさせられるのか？ WisdomChannel は access.json を使用して、ユーザーロール、プライベートチャットのデフォルトポリシー、およびグループチャットのホワイトリストを管理します。ユーザー権限には、表示ニックネームだけに依存するのではなく、安定した WeChat ID を使用します。リストにないグループチャットは無視されます。allow_tools=false のロールに対して、bridge は claude -p --tools "" を通じてツールを無効化します。対話式 Channel モードでは、権限情報は実行中の Claude Code セッションに処理させます。[2]

デプロイは最も保守的なポリシーから始めることを推奨します：未知のプライベートチャットにはデフォルトで応答せず、テスト用グループを 1 つだけ開放し、一般ユーザーにはチャットのみを許可し、試運転段階では管理者ツール権限を付与しません。

安全に回答できることを先に証明してから、操作を実行させることを検討してください。

¶ 2、設定ガイド：QR コードログインから最初の AI 応答まで

WeChat Bot 設定ルート：アプリ作成、QR コードスキャン、認証情報の取得、インストール、ホワイトリスト、検証

図 2：推奨設定ルート。まずメッセージ経路を検証し、その後 AI 自動応答を有効にします。

以下では、Windows PowerShell + bridge のサンプルパスを使用します。すべてのプレースホルダーは自身の実際の情報に置き換える必要があります。

¶ ステップ 1：アプリを作成して QR コードでログインする

WeChat Bot サービスページでアプリを作成し、プラットフォームが専用インスタンスをデプロイするのを待ってから、スマートフォンの WeChat でコンソール内の QR コードをスキャンしてログインします。

製品ページによると、コンソールはインスタンス API アドレス、API_TOKEN、および VNC インターフェースへの入口を提供します。Viewer は個別の認証情報を使用し、アプリ所有者とプラットフォーム管理者のみが閲覧できます。[1]

实例 API 地址：以控制台实际显示为准
API_TOKEN：实例访问令牌
VNC 入口：出现桌面或登录异常时排查使用

Token を公開リポジトリ、ブログのスクリーンショット、またはフロントエンドページに配置しないでください。

¶ ステップ 2：まずインターフェースを検証し、AI 接続を急がない

PowerShell でテスト変数を設定します：

$ApiUrl = "http://<你的实例地址>:8000"
$ApiToken = "<你的 API_TOKEN>"

$Headers = @{
    Authorization = "Bearer $ApiToken"
}

サービス状態を確認します：

Invoke-RestMethod `
    -Uri "$ApiUrl/api/status" `
    -Headers $Headers `
    -Method Get

次に、テストメッセージの受信に明確に同意した連絡先へテキストを送信します：

$Body = @{
    target = "<测试联系人>"
    type   = "text"
    text   = "你好，这是一条 WeChat Bot 连通性测试消息。"
} | ConvertTo-Json

Invoke-RestMethod `
    -Uri "$ApiUrl/api/messages/send" `
    -Headers $Headers `
    -Method Post `
    -ContentType "application/json; charset=utf-8" `
    -Body ([System.Text.Encoding]::UTF8.GetBytes($Body))

上記の送信フィールドは、製品ページのテキストメッセージ例をもとに書き換えたものです。/api/status はページで公開されている状態確認インターフェースです。[1]

送信が期待どおりに行われない場合は、まず API アドレスとネットワーク、Token、WeChat のログイン状態、対象連絡先の一致状況、および VNC 内にプロンプトや異常ウィンドウが存在しないかを確認してください。

基本的なメッセージ経路が通ってから、AI の統合を続けてください。

セキュリティ上の推奨：この例では、ページに表示されている HTTP アドレス形式をそのまま使用しています。本番環境では、「Bearer Token 付き」を「通信が暗号化されている」と解釈しないでください。インスタンスのデプロイ条件に応じて、HTTPS、セキュアトンネル、またはネットワークアクセス制限を設定してください。

¶ ステップ 3：Python と Claude Code を準備する

WisdomChannel のドキュメントでは、Python 3.10+、ログイン済みの Wisdom サービス、および Claude Code CLI v2.1.80+ が必要です。bridge ではさらに、claude コマンドが PATH 上にある必要があります。[2]

python --version
claude --version

pip install wisdom-channel

その後、bridge を実行するマシンで Claude Code のログインまたは認証情報の設定を完了し、選択したモデルを正常に呼び出せることを確認します。

WeChat インスタンスの API_TOKEN はメッセージサービスへのアクセスに使用するものであり、Claude Code のモデル認証情報ではありません。

¶ ステップ 4：インスタンス接続情報を設定する

設定ディレクトリと .env ファイルを作成します：

$ChannelDir = Join-Path $env:USERPROFILE ".claude\channels\wechat"

New-Item `
    -ItemType Directory `
    -Path $ChannelDir `
    -Force | Out-Null

@"
WISDOM_API_URL=http://<你的实例地址>:8000
WISDOM_API_TOKEN=<你的 API_TOKEN>
WECHAT_BOT_NAME=
WECHAT_CONTEXT_MESSAGES=8
"@ | Set-Content `
    -Path (Join-Path $ChannelDir ".env") `
    -Encoding utf8

上記のパスと環境変数は、WisdomChannel の設定規約に基づいています。WECHAT_BOT_NAME を空欄にすると名前が自動検出され、WECHAT_CONTEXT_MESSAGES は各応答で取得する直近メッセージ数を制御します。[2]

まずはデフォルトのコンテキスト数を維持し、フローが動作してから、回答品質、遅延、データ最小化の要件に応じて調整することを推奨します。

¶ ステップ 5：まずホワイトリストを設定してから、自動応答を起動する

同じディレクトリに access.json を作成します：

~/.claude/channels/wechat/access.json

以下は、テストユーザーとテストグループのみを許可し、ツール権限を付与しない例です：

{
  "version": 3,
  "enabled": true,
  "roles": {
    "normal": {
      "allow_tools": false,
      "contexts": ["group", "private"],
      "prompt": "只回答公开、基础和一般性问题。不查看或修改内部项目、文件、日志、服务器或数据库。"
    }
  },
  "users": {
    "<测试用户的稳定微信ID>": {
      "role": "normal"
    }
  },
  "private": {
    "enabled": true,
    "default_role": "deny",
    "prompt": ""
  },
  "groups": {
    "<测试群的准确名称>": {
      "enabled": true,
      "default_role": "normal",
      "prompt": "",
      "members": {}
    }
  }
}

重要な点は：users には安定した WeChat ID を入力し、ニックネームだけを入力しないこと。一致しないプライベートチャットはデフォルトで拒否されること。グループ名は正確に一致する必要があること。一般ユーザーにはツール権限を付与しないこと。グループチャットは引き続き @ トリガー条件を満たす必要があることです。

これらのフィールドと一致ルールは WisdomChannel のアクセス制御ドキュメントに従っています。上記の例では、高権限の管理者ロールを意図的に削除しています。[2]

¶ ステップ 6：接続をテストして bridge を起動する

まず、Claude Code を起動しない独立した接続テストを実行します：

python -m wisdom_channel --test

次に、自動応答を起動します：

wisdom-channel bridge --model sonnet

ドキュメントによると、前者のコマンドは REST と WebSocket のテストに使用され、後者のコマンドは自動応答ループを実行し、同じアクセス戦略とグループチャットの @ ルールを使用します。[2]

テスト操作	期待結果
ホワイトリストユーザーが個別メッセージを送信	正常に返信する
ホワイトリストグループ内でロボットを `@` メンション	正常に返信する
ホワイトリストグループ内で通常の雑談	返信をトリガーしない
非ホワイトリストユーザーとの個別チャット	返信しない
一般ユーザーがサーバーファイルの読み取りを要求	ツールを実行する能力を持たない
ユーザーが連続して質問する	回答が直近のコンテキストを適切に活用できるか確認する

実行ログの場所は ~/.claude/channels/wechat/mcp.log です。[2]

¶ ステップ 7：「動く」ものを「保守可能」なものにする

bridge は対話型ターミナルに依存しませんが、自動的にシステムサービスとしてインストールされるわけではありません。正式に使用する際は、以下を追加することを推奨します。

プロセス管理： 異常終了後に再起動し、実行ログを保持する。
状態監視： インスタンス、WeChat のログイン状態、およびモデル呼び出しを確認する。
有人引き継ぎ： 回答できないことや、約束が必要なことを担当者に引き継ぐ。
返信の境界： 返金、補償、価格、または納期を自動的に約束しない。
データ保護： どの会話をモデル処理のために送信できるかを明確にする。
コスト監視： インスタンス費用とモデル呼び出し費用をそれぞれ確認する。

これらは本番運用の推奨事項であり、製品に完全なチケット管理、監視、または有人カスタマーサービスシステムがすでに組み込まれていると誤解すべきではありません。

¶ 三、ユースケース：小さなフローから始め、段階的に価値を拡大する

WeChat Bot 六類應用方向：客服、群助手、告警、工單、質檢與個人助理

図 3：6種類の活用方向。ナレッジベース、チケット管理、定時タスクは、ビジネスニーズに応じて別途統合する必要があります。

以下は、メッセージの送受信、リアルタイムイベント、AI 接続機能に基づいて設計した導入方向であり、有効化後に自動的に利用できる完全な業務システムではありません。

¶ シナリオ 1：カスタマーサービスのQ&A、まずは重複する質問を処理する

製品に関する問い合わせ、利用説明、よくある設定上の問題が多いチームに適しています。

客户提问 → 检索经过审核的产品资料 → AI 组织回答
→ 发送到微信 → 不确定时转人工

たとえば、「API Token はどこで作成するのか」「認証の失敗をどのように調査するのか」といった標準的な質問は、優先して自動処理できます。

補う必要があるもの： 製品ナレッジベース、資料更新の仕組み、有人引き継ぎフロー。価値は AI にすべてを回答させることではなく、カスタマーサービスが同じ説明を何度も入力する時間を減らすことにあります。

¶ シナリオ 2：グループ内アシスタント、呼ばれたときだけ回答する

製品サポートグループ、研修グループ、開発者コミュニティに適しています。ユーザーはグループ内で「@アシスタント、初回接続時にはどのような情報を準備する必要がありますか？」と質問できます。

ホワイトリストと @ トリガーの仕組みを利用することで、アシスタントを指定グループ内に制限し、すべての雑談に参加することを避けられます。

補う必要があるもの： グループの用途説明、回答可能な範囲、および引用する必要のあるナレッジコンテンツ。最初から営業、カスタマーサービス、運用保守のすべての責任を担わせるのではなく、「設定説明アシスタント」のような境界が明確な役割から始めることを推奨します。

¶ シナリオ 3：運用保守アラート、異常を普段使うコミュニケーションチャネルに送信する

すでに監視プラットフォームを持つ小規模チームに適しています。

监控系统发现异常 → 告警服务分级、去重
→ 调用消息发送接口 → 通知指定联系人或群

さらに、「アラート番号に返信して、最新の状態を照会する」というインタラクションも設計できますが、これには監視照会インターフェースの接続が必要です。

補う必要があるもの： アラートルール、レート制限、重複排除、予備の通知チャネル。WeChat は便利な通知窓口になり得ますが、重大な障害における唯一の連絡手段にすべきではありません。

¶ シナリオ 4：チケットの流転、コピー＆ペーストを減らす

多くの問題が WeChat から入り、チケットプラットフォームで追跡する必要があるチームに適しています。

用户反馈问题 → AI 提取产品、现象和报错信息
→ 提醒用户补充缺失字段 → 调用工单系统 → 回传工单编号

補う必要があるもの： チケット API、フィールドマッピング、ユーザーIDの関連付け、重複チケットの判定。

チケットを自動作成する前に、まずユーザーに要約を確認してもらうことができます。「私が理解した問題は、インターフェース呼び出しで認証エラーが返されることです。この説明で送信しますか？」こうすることで、認識のずれによる誤った記録を減らせます。

¶ シナリオ 5：会話品質チェック、繰り返し発生する問題を見つける

カスタマーサービスの会話から製品を改善したいチームに適しています。許可を得て取得可能な会話データを対象に、日次または週次の分析を設計できます。どの問題の発生頻度が最も高いか。どの設定手順で最もつまずきやすいか。どの回答がユーザーの問題を解決していないか。どの内容をヘルプドキュメントに追加すべきか。

補う必要があるもの： 定時タスク、ストレージ、匿名化、分析ルール、レポートの出力先。目標は「多く収集するほどよい」ことではなく、明確な許可と保存期間を前提として、必要なデータでサービスを改善することです。

¶ シナリオ 6：パーソナルアシスタント、断片的なメッセージをアクション項目に整理する

記録と整理の入口を統一したい個人ユーザーに適しています。たとえば、「先ほど送ったいくつかの内容をアクションリストに整理し、補足が必要な情報を示してください」。

実際のタスク作成、カレンダーへの書き込み、または指定時刻のリマインドも行いたい場合は、対応するシステムをさらに接続する必要があります。

補う必要があるもの： タスクまたはカレンダーのインターフェース、スケジューリングの仕組み、操作確認。「整理して」と「代わりに実行して」は、異なるレベルの権限です。外部への書き込みが関わる場合は、まず結果を表示し、その後ユーザーに確認してもらうのが最善です。

¶ 四、利用前に必ず理解すべき境界

¶ 1. デスクトップ自動化は WeChat 公式インターフェースと同じではない

製品ページでは、WeChat プラットフォームの利用規範を遵守し、送信頻度とコンテンツを適切に制御することが求められています。[1] 実際のデスクトップクライアントを利用する方式でも、アカウントや運用上のリスクが存在しないことを保証することはできません。見知らぬ人への一括接触、許可のない一斉送信、その他の迷惑な自動化に使用することは推奨しません。

¶ 2. AI を接続しても、業務知識が自動的に得られるわけではない

Claude Code は回答を生成できますが、製品ポリシー、注文、在庫、顧客権限、内部プロセスについては、明確に提供するか、制御されたインターフェースを通じて照会する必要があります。事実や約束に関わる場合は、モデルに推測させるのではなく、信頼できるデータを優先すべきです。

¶ 3. チャット内容を直接システム権限にしてはならない

メッセージがホワイトリストからのものであっても、「以前のルールを無視して」という一言によって権限を拡大すべきではありません。通常のチャットと高権限操作を分離し、データ削除、設定変更、支払い、一括送信などの操作には独立した承認を設けることを推奨します。

¶ 4. 期待される成果を性能保証として書かない

公開情報だけでは、具体的なデプロイ時間、スループット、応答遅延、サービスレベル、またはすべての費用を確認するには不十分です。選定時にはこれらの指標を実際に検証し、コンソールのプランと最新のドキュメントを基準にしてください。

¶ 結び：まず1つのフローをつなぎ、その後で WeChat により多くの仕事を担わせる

WeChat Bot が注目に値する点は、単に「WeChat に会話できるボットが1つ増えた」ことだけではありません。より価値があるのは、チャットとシステムをつなぐ方法を提供していることです。

WeChat はニーズを受け取り、AI は情報を理解・整理し、業務システムは検証可能なアクションを完了する役割を担います。

始める準備ができたら、まずは最小限の試行を行うことを推奨します。

インスタンスを作成し、QRコードをスキャンしてログインします。
テキストメッセージ1件の送信を検証します。
WisdomChannel をインストールします。
テストユーザーまたはグループを1つだけ開放します。
bridge を使って自動返信を動作させます。
その後、本当に価値のある業務フローを1つ接続します。

初日から「万能アシスタント」を作る必要はありません。まずは、ある種類の繰り返し質問への回答、ある種類の重要通知の転送、またはある種類の顧客フィードバックの整理を任せるだけでも、検証する価値のある出発点になります。

AceDataCloud WeChat Bot について確認・設定を始める →

¶ 参考資料

AceDataCloud WeChat Bot 製品ページ：製品アーキテクチャ、インターフェース機能、デプロイ手順、利用上の注意事項。
WisdomChannel の設定・実行ドキュメント：環境要件、設定変数、アクセス制御、bridge モード、ログ。
WisdomChannel プロジェクト README：オープンソースクライアントの説明と今後の更新。

表紙および本文中の3枚のイメージ図は、OpenAI gpt-image-2 を使用して生成されています。