前のページへ

微信 AI 助手

誰も否定しないだろう。難題にぶつかったときやプロジェクトを仕上げるときには、LLMのページで尋ねたり、Coding Agentで解決したりすればいい。けれど、ただ会話をしている最中に、ふと小さな疑問が浮かんだとしたら? Appを切り替え、質問を入力し、結果を待つ。その煩わしい手順そのものが、私たちの好奇心をすり減らし、面白いかもしれない一つのひらめきを失わせてしまう。

そこで、もっと直接的なものを作りたいと思った。

AIそのものが、WeChatの連絡先の一人だったら?

別のソフトを開く必要も、いつもの会話習慣を変える必要もない。個人チャットで話しかけるか、グループで@すれば、質問を理解し、必要なモデルとツールを呼び出し、答えをWeChatへ送り返す。

微信 AI 助手は、この発想から作ったWindows版WeChat向けの個人用AIアシスタントだ。

どんなものか

微信 AI 助手はWindows版WeChatクライアントの隣で動き、デスクトップのUI Automationを通じて新着メッセージを監視する。

現在は主に二つの方法で起動する。

  • ボットのアカウントへ個人チャットを送る
  • グループでボットを明示的に@する

条件に合う新着メッセージを受け取ると、まず送信者と安全性を確認し、質問の種類に応じて使うモデルと外部ツールの要否を決める。

生成した回答はWeChatの入力欄へ書き戻し、そのまま送信する。

利用者から見れば、普通のWeChat連絡先と大きな違いはない。

メッセージを送る → 数秒待つ → AIの返信を受け取る。

モデル呼び出し、ツール検索、WeChat操作はすべて裏側で進む。

一つの大規模モデルAPIだけではない理由

このプロジェクトは、次第に二つのモデルが協働する構成へ育った。

すべての質問を一つのモデルへ固定せず、内容に応じて自動で振り分けている。

OpenAI ChatGPT 5.6 Luna

OpenAI ChatGPT 5.6 Lunaは既定のモデルで、主に次を担当する。

  • 日常会話
  • 仕事と学習
  • 文章作成と翻訳
  • プログラミング
  • 一般的な専門質問
  • 天気、ニュース、Web情報

DeepSeek V4 Pro Thinking

より強い推論や専門判断が必要な分野は、自動でDeepSeek V4 Pro Thinkingへ切り替える。現在の対象は主に次のとおり。

  • 金融
  • 医療と健康
  • フィットネス、栄養、運動
  • そのほか、詳しい助言が必要な分野

たとえば通常の会話はそのままLunaへ入り、株式分析は自動でDeepSeek Proへ送られる。

WeChatユーザーはどのモデルで回答するかを自ら選び、プログラムは質問に応じて対応するモデルを自動で選択する。

Tools

モデルは、自身がすでに持つ知識だけで答えるわけではない。

その上に、統一されたSkill / Tool層も作った。

  • リアルタイム市場価格
  • 過去のローソク足データ
  • ファンダメンタルデータ
  • Web Search

WeChatである銘柄の直近の値動きを尋ねると、システムはまず証券コードを認識し、実際の相場データを取得してから、そのデータをDeepSeekへ渡して分析できる。

利用者の質問 → Agentが必要なデータを判断 → ツールを呼ぶ → 結果を取得 → モデルが分析 → WeChatへ返信

単に一文をモデルへ転送するだけではない。

WeChatデスクトップ自動化

このプロジェクトで難しかったのは、モデルよりもWeChatそのものだった。

使っているのはボット専用のメッセージAPIではなく、通常のWindows版WeChatクライアントだ。

そのため、プログラムは実際のデスクトップUIを扱う必要がある。

  1. 認識

    1. 現在のWeChat会話を識別する
    2. 新着メッセージと履歴を区別する
    3. グループ内の@SELFを認識する
    4. ボット自身のメッセージへ返信しない
  2. 特定と書き込み

    1. 正しい会話へ切り替える
    2. 入力領域を見つける
    3. 回答を書き込む
  3. 送信と検証

    1. 送信ボタンを見つける
    2. 送信する
    3. 本当に送信できたかを再確認する

開発中には、UI Automationらしい典型的な問題にも遭遇した。

WeChatの送信ボタン内部にある文字の子コントロールが本来のクリック判定領域を覆い、回答の生成も入力欄への書き込みも終わっているのに、送信ボタンの安全なクリック面を確定できなかった。

最後は送信ボタンのhit-testとtransaction機構を組み直し、実際の送信経路を最後まで通した。

この種の問題こそ、このプロジェクトが普通の「LLM APIを一度呼ぶだけ」のDemoと異なる点だ。

SEND_VERIFIED

送信キーを一度押しただけで成功とみなす仕組みにはしていない。

送信は毎回、独立したtransactionとして管理する。

送信成功を確認できた場合は、

SEND_VERIFIED

としてtransactionを終了する。

送信動作を実行していないと明確にわかる場合は、安全に失敗させて次の依頼へ進める。

一方、実際のUI送信を一度実行したものの、WeChatで成功したか判断できなければ、次の状態へ入る。

SEND_AMBIGUOUS

この状態では自動再試行を行わない。

一件の送り漏れは、同じメッセージを二度送るより受け入れやすい。

そのため送信結果が不明なときは、危険を冒してWeChatを再操作せず、停止して人の確認を待つ。

単工モード

このプロジェクトは、大量の利用者を同時に処理することを目指していない。

最終出力が実際のWindows UIに依存するため、並列処理の量より安定性が重要だ。

そこで、グローバルなBUSY単工機構を追加した。

ボットが空いているときは、条件を満たす最初の新規依頼だけを受ける。

処理を始めると、

BUSY

その間に別の利用者が個人チャットを送ったり、別のグループで再び@したりしても、プログラムは新着を確認してカーソルを進めるだけで、待機列には加えない。

それらのメッセージは破棄され、前の回答後に遡って処理することもない。

現在の依頼が終わると、

BUSY → IDLE

ボットは、それ以降に現れた次の新着メッセージから仕事を再開する。

同時処理能力の一部を犠牲にする代わりに、デスクトップ自動化で起きやすい待機列、誤会話、過去メッセージへの遅延回答、UI状態変化のリスクを大きく減らした。

安全境界

プログラムは実際のWeChatクライアントを操作できるため、送信経路には厳しい境界を残した。

  1. トリガー境界

    • グループではボット自身への明示的な@が必要
    • 起動前から存在する履歴には回答しない
  2. 重複排除とエコー隔離

    • 同じメッセージを二度materializeしない
    • ボット自身の送信内容で再起動しない
  3. 会話とUIの制御

    • UI操作は直列のままにする
    • 送信前に対象会話を再確認する
  4. 送信transactionの保護

    • 送信成功が不明なときは盲目的に再試行しない
    • unresolved transactionは新たな危険な送信を止める

「どんな状況でもできるだけ返信する」便利さは少し失われる。それでも、本当のWeChatアカウントを操作するプログラムで優先したいのは、

送り先を間違えず、重複送信せず、UIの変化で制御を失わないことだ。

現在の状態

すでに実際のWeChat環境で、全経路の検証を終えている。

実際に試した内容は次のとおり。

  1. 通常会話

    WeChat → Luna → 回答生成 → WeChat送信

  2. 金融の質問

    WeChat → DeepSeek V4 Pro Thinking → 市場データSkills → 分析 → WeChat送信

  3. フィットネス / 栄養の質問

    WeChat → DeepSeek V4 Pro Thinking → WeChat送信

さらに、次の項目も確認済みだ。

  1. メッセージ入口と保護

    • グループの@SELF
    • 個人チャットへの自動返信
    • メッセージ重複排除
    • 履歴メッセージの保護
  2. モデルとツール

    • モデルの自動ルーティング
    • Tool Calling
    • Web Search
    • 市場価格データの呼び出し
  3. 送信と並行処理

    • 送信transaction
    • SEND_VERIFIED
    • 未解決transactionの保護
    • グローバルBUSY単工処理

なお解決すべきこと

  1. Skillsの拡張

    現在のSkill / Toolシステムは、よく使う機能の一部をすでにカバーしている。今後はさらに多くのSkillsを追加し、WeChat上で、質問への回答だけにとどまらない、より多様なタスクを扱えるようにしたい。

  2. 相対日付

    質問で明確な日付ではなく「今日」「明日」といった相対日付が使われると、まれに正常に回答できないことがある。現在の調査ではローカルプログラム側に該当する不具合は確認されていないが、原因がDeepSeek APIのスケジューリング、モデル側の時間文脈の処理、あるいは別の外部要因のどこにあるのかは、まだ特定できていない。引き続き調査が必要だ。

  3. 複雑な複合指示

    一度のメッセージに、相互に関連する要求が多すぎる場合にも、正常に回答できないことがある。同じタスクをいくつかの手順に分けると、多くの場合は正常に完了できる。こちらも原因はまだ正確に特定できておらず、モデル、APIのスケジューリング、あるいはより複雑な文脈とTool Callingの組み合わせのどこで起きているのかを、引き続き判断する必要がある。

現在の微信 AI 助手は、テストコードの中だけにあるDemoではない。Windows版WeChatクライアントの隣で実際に動き、質問を受け取り、本当の返信まで完了できる個人用AI Agentになっている。