自分のWeChatアカウント自動化で、最初に整理すべき3つの層

更新日こうしんび：2026-03-19 JST

まず境界きょうかいを明確めいかくにしておきます。この文章ぶんしょうで議論ぎろんするのは、「自分じぶんのアカウント、自分じぶんのデバイス、自分じぶんのワークフローの自動化じどうか」です。最初さいしょにこの境界きょうかいをはっきりさせておかないと、その後あとの技術的ぎじゅつてきな判断はんだんの多くがずれてしまいます。なぜなら、個人こじんアカウントの自動化じどうかと、第三者だいさんしゃに向むけたメッセージ取得しゅとくや一括制御いっかつせいぎょは、根本的こんぽんてきに別べつの問題もんだいだからです。

多くの人ひとは最初に2つの質問しつもんをします。メッセージを監視かんしできるのか。メッセージを自動送信じどうそうしんできるのか。この2つの質問しつもん自体は間違まちがっていません。ただ、ここから直接始めると、たいていすぐに実装じっそうの詳細しょうさいに沈み込みます。たとえば、ローカルデータベースを逆向ぎゃくむき解析かいせきすべきか、クライアントを hook すべきか、システム通知つうちを見るべきか、UI 自動化じどうかをすべきか、といったことです。本当に先に切り分けるべきなのは、機能きのうではなく、3つの層そうです。監視層かんしそう、実行層じっこうそう、保存層ほぞんそうです。

1. まず目標を3つの層に分ける。「できるか」から入らない

いわゆる監視層かんしそうは、「何が起きたか」に答える役割を持ちます。たとえば、新着しんちゃくメッセージがあるか、どの会話かいわに変化があったか、現在のウィンドウ内で本文を読めるか、といったことです。実行層じっこうそうは、「自分に何の操作ができるか」に答えます。たとえば、会話かいわを切り替える、文字を入力する、送信をクリックする、画像やファイルを送る、などです。保存層ほぞんそうはさらに下の能力のうりょくで、前面の UI に依存しない状態で、会話かいわ、メッセージ、カーソル、未読状態みどくじょうたいといった構造化こうぞうかデータを安定して取得できるかを決めます。

この3つの層そうを分けると、多くの判断はんだんが一気に明確になります。たとえば、「自動返信じどうへんしんできるか」は、初日からローカルデータベースを完全に解読することを必要としません。同じように、「メッセージを監視かんしできるか」も、必ずしも暗号化あんごうかライブラリの逆向ぎゃくむき解析かいせきだけに頼る必要はありません。UI で先に通した方がよいこともあれば、ローカル保存ほぞんでしか解決できないこともあります。ただし、この2つは二者択一の関係ではありません。

2. 監視層には少なくとも3つのルートがあるが、安定性は大きく違う

1つ目のルートはシステム通知つうちです。この方法の利点は、実装が速く、侵入性が低く、WeChat 本体やローカルデータベースにほとんど触れなくてよいことです。macOS では、WeChat が通知を通知センターに配信できるなら、タイトル、本文の一部、グループチャット情報などを取得できる可能性があります。PoC にとっては、これはほぼ最速のルートです。

ただし、このルートの問題も明確です。会話かいわで通知が無効なら、何も見えません。メッセージが長いと本文は切り捨てられます。そもそも一部のメッセージ種別は、システム通知つうちに完全な形で出てきません。つまり、通知センターはむしろ fallback に近く、軽量なイベントソースには向いていますが、最終的なメッセージ監視方式としては向いていません。

2つ目のルートは UI 自動化じどうか、つまり前面の WeChat ウィンドウのアクセシビリティツリーを読む方法です。その価値は、ローカルデータベースを先に解読しなくても、会話かいわ一覧、現在のチャットウィンドウ内の可視メッセージ、さらに入力欄、送信ボタン、添付ボタンといった操作可能な要素を直接読める可能性があることです。「自分じぶんのアカウント自動化」にとって、このルートは現実的な意味が大きいです。なぜなら、監視と実行の両方を同時にカバーできるからです。

問題も同じく明確です。UI 自動化じどうかは本質的に、WeChat の現在バージョンの画面構造に依存し、システムのアクセシビリティ権限にも依存し、さらにデスクトップ上のウィンドウが本当にアクセス可能な状態であることにも依存します。これはバックグラウンドサービス型の監視ではなく、「今このデスクトップ上にあるクライアントウィンドウ」の監視です。したがって、実用的なツールには向いていますが、安定した API と誤認してはいけません。

3つ目のルートはローカルデータベースと関連するサイドカーファイルです。理論上、これが最も「本当の監視」に近い方法です。なぜなら、会話かいわデータベースとメッセージデータベースを安定して読めるなら、多くの問題が一気に整理されるからです。新着しんちゃくメッセージがあるか、どの会話かいわに属するか、未読数みどくすうがどう変わったか、メッセージ種別は何か、といったことを、すべて構造化こうぞうかデータとして扱えるようになります。

しかし現実には、これが最も敷居しきいの高いルートでもあります。理由は、データベースが暗号化あんごうかされているからだけではありません。多くのクライアントは、「復号ふくごう処理しょり」を、簡単に横取りできる標準インターフェースとしてそのまま公開してはいません。ファイルがデータベースのように見えるからといって、それが plain SQLite とは限りません。key_info.db を読めたからといって、その中の blob がそのまま使える鍵だとも限りません。多くの場合、本当に価値のある手がかりは、ファイルの静的構造ではなく、実行時の初期化経路の中にあります。

3. 目標が「まず作ること」なら、「体系を先に解き明かすこと」より実行層を先に着地させるべき

これは過小評価されやすい判断です。多くの人は自然に、「監視が最重要だ」と考えます。監視できなければ自動化できないからです。しかし、エンジニアリングを前に進める観点では、むしろ実行層じっこうそうを先に通すべきことが多いです。理由は単純で、先に「指定チャットに切り替える、文字を入力する、送信をクリックする」という一連の能力を持てば、自動化の閉ループに出口ができます。

いったん送信経路が使えるようになれば、その前段の監視は、しばらく不完全でも受け入れられます。たとえば、初期段階では通知センターを軽量イベントソースとして使い、UI 自動化じどうかで会話かいわや本文を補うことができます。あるいは、まずは「現在の会話かいわに1件自動送信する」だけを支援し、「全会話ぜんかいわを安定監視する」ことは急がなくてもよいのです。これは十分に美しい設計には見えないかもしれませんが、非常に実務的です。優先して検証しているのが、自動化の閉ループそのものであり、研究の深さではないからです。

だからこそ、私は「送信」を、より早い段階で着地させるべきモジュールだと考えます。見た目は完璧でなくてもかまいません。しかし、それによってあなたが「クライアントを観察する段階」から「クライアントを制御する段階」へ進めているかどうかが決まります。

4. 保存層は本当の天井だが、最初からここに自分を閉じ込めるべきではない

最終的にあなたが作りたいものが、長期稼働し、できるだけデスクトップウィンドウに依存せず、できるだけ構造化こうぞうかされた WeChat 自動化じどうかシステムであるなら、ローカル保存層ほぞんそうには遅かれ早かれ向き合うことになります。とくに、要件が次のような問題に及び始めたときです。

どの会話かいわに新着しんちゃくメッセージが来たのかを知りたい。
通知が有効かどうかに依存したくない。
WeChat ウィンドウが常に前面にあることを要求したくない。
異なるメッセージ種別をすべて構造化こうぞうかして処理したい。

この段階では、通知や UI の層にとどまり続けるのは、ますます苦しくなります。なぜなら、それらはどちらも画面依存と状態依存が非常に強いからです。いっぽう、保存層ほぞんそうが通れば、もともと脆弱だった多くの判断を、確定的なものに変えられます。

しかし、エンジニアリングで最も避けるべきなのは、最初からすべての希望をこの最難関のルートに賭けることです。とくに、暗号化あんごうかデータベース、実行時の解除経路、クライアント固有の非公開ラッパーを相手にするとき、十分な検証ポイントがなければ、何日も低レベルの逆向ぎゃくむき解析かいせきの中を回り続け、しかもまだ使える結果が何もない、ということが簡単に起こります。

だから、より合理的なやり方はこうです。保存層ほぞんそうを能力の上限とみなし、第1段階の唯一の入口とはみなさないことです。

5. 本当に実務的な進め方は、「先に閉ループ、あとで純化」

もし私が「自分じぶんの WeChat アカウント自動化」に、より現実的な進行順を付けるなら、次のように分けます。

第1段階では、まず実行層じっこうそうを通します。少なくとも最低限使える送信能力が必要です。たとえば、現在の会話かいわにテキストを送る、あるいは検索で特定の連絡先に切り替えてから送信する、といったものです。この段階の目標は、企業向けレベルの安定性ではなく、自動化アクションの連鎖そのものが到達可能かを確認することです。

第2段階では、十分に安い監視層かんしそうを1つ、イベントソースとして確保します。通知センターでもよいですし、ファイル変更でも、前面 UI の変化でもかまいません。この段階の目標は、「何かが起きた」と分かることです。

第3段階では、イベントソースを徐々に弱い信号から強い信号へと引き上げます。たとえば、「通知の中でメッセージを見た」から、「UI で本文を読める」へ、さらに「ローカルデータベースが構造化こうぞうかされた会話かいわとメッセージを返せる」へと進めます。

第4段階では、監視層かんしそうと実行層じっこうそうの両方が十分使えるようになってから、ルールエンジンを考えます。たとえば、特定のキーワードを受け取ったら自動でアーカイブ、転送、通知する、あるいは特定の会話かいわでテンプレート化された内容を自動返信する、といったものです。

この順序の核心は、まず閉ループを作り、そのあとで各層を純化していくことです。最初から「最終形」を追わないでください。そうしないと、最も難しく、最も不確実な実装に、早い段階で自分を閉じ込めてしまいます。

6. 公開の議論で本当に記録する価値があるのは、「どう hack するか」ではなく「どう工学的に取捨選択するか」

私はますます、この種の自動化問題で本当に価値があるのは、「魔法のようなインターフェースがあるかどうか」ではなく、あるルートに投資し続ける価値があるかどうかを、どう判断するかだと感じています。

通知ルートの価値は、速さです。UI 自動化じどうかルートの価値は、現実に使えることです。ローカルデータベースルートの価値は、最終的な上限です。どれも間違いではありません。ただし、答えている問題がそれぞれ違います。多くのプロジェクトは、技術的に不可能だから死ぬのではなく、どのルートが結果を取りに行くためのものか、どのルートが長期能力を積み上げるためのものかを区別できないために止まります。

もし1つだけ結論を持ち帰るなら、それは次の3点です。

自分じぶんのアカウント自動化で、最初に切り分けるべきなのは、監視層かんしそう、実行層じっこうそう、保存層ほぞんそうである。
第1段階ではまず閉ループを優先し、いきなり最も深い逆向ぎゃくむき解析かいせき経路に自分を縛りつけない。
本当に安定した会話かいわ単位・メッセージ単位の構造化こうぞうかデータが必要になったときにだけ、ローカルデータベース層へ本格的に力をかける価値がある。

まとめ

「自分じぶんの WeChat アカウント自動化」は、一見すると機能の問題に見えますが、実際にはむしろ階層設計かいそうせっけいの問題です。本当に差がつくのは、誰がより速く1本のスクリプトを書けるかではなく、誰がより早く問題を正しく分解できるかです。

まず層を分け、次に実行を着地させ、そのあとで監視を補い、最後に保存層ほぞんそうへ進むかを決める。この順序はロマンがないかもしれませんが、とても有効です。個人こじん自動化にとって、エンジニアリングで最も重要なのは、決して「最も深いこと」ではなく、「まず作り上げること」なのです。