ChatWiki 評価：WeChat 公式アカウントを RAG エージェント化する Vue + Go + Python 構成のワークフロー基盤
ChatWiki 微信公众号的AI知识库工作流Agent平台，RAG大模型AI客服机器人，致力于成为垂直领域的coze、n8n。
ひと目でわかる
- これは何？
- ChatWiki は WeChat 公式アカウントの私信・コメント・メニュー操作をトリガーに、RAG 知識ベースとワークフローを組み合わせて自動応答させるセルフホスト型プラットフォーム。Docker Compose で立ち上がる一方、ライセンス表記は NOASSERTION のままで、採用判断には確認事項が残る。
- 誰に向いている？
- WeChat 公式アカウントを運用していて、私信・コメント・メニュークリックを起点にした自動応答と、公式アカウント記事を知識ベースへ取り込む導線を自前のサーバーで持ちたいチームに向く。逆に WeChat 以外のチャネルが主軸の企業、マルチテナントの SaaS として外部提供したい事業者、ライセンス条件を法務が確定できない組織は採用を見送るべきだ。
- 商用利用できる？
- まず確認が必要です。このリポジトリのライセンスは自動分類の対象外なので、商用利用の前に LICENSE ファイルを読んでください。
- 今もメンテナンスされている？
- されています。最後のコミットは 12 日前です。
- 何の言語で書かれている？
- 主に Vue です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
WeChat 公式アカウント運用のどこを置き換えるのか
ChatWiki が埋めるのは、公式アカウントの運用担当者が手作業で行っている一次対応の隙間だ。README は「Automatic reply to private messages for unverified official accounts」を挙げ、未認証の公式アカウントでも私信への自動応答ができるとしている。テキストだけでなく音声、画像、ミニプログラムカード、動画メッセージが対象に含まれる。トリガーとして README が列挙するのは、ユーザーの私信、コメント、フォロー、フォロー解除、メニュークリックで、処理ステップ側には私信への返信、ファンへのタグ付け、下書き記事の生成、記事の公開が並ぶ。つまり投稿のたびに人手で書き直し、コメントに個別返信し、問い合わせを担当者へ回していた作業を、イベント駆動のフローに移す発想である。対象読者は WeChat 公式アカウントを接客や販促の窓口にしている運用チームで、開発者でなくてもドラッグ＆ドロップで組み立てられることを README は想定している。
Vue フロントと Go + Python バックエンド、PostgreSQL16 という構成
技術スタックは README の記載どおり、フロントが vue.js、バックエンドが golang + python、データベースが PostgreSQL16 + pgvector + zhparser である。pgvector は埋め込みベクトルの格納と類似検索、zhparser は中国語テキストの分かち書きに使われる PostgreSQL 拡張で、この 3 点セットは中国語文書を対象にした RAG の標準的な組み合わせと言える。知識ベース側の機能として README が挙げるのは URL 読み込み、文書の一括インポート、API 連携、AI 分割、QA 分割、親子分割、ナレッジグラフ、ハイブリッドベクトル検索、グラフの可視化探索だ。QA 知識ベースはアップロード文書から QA を自動抽出し、未知の質問を自動クラスタリングし、人対人の会話からよくある質問を要約する。検索方式が単一のベクトル検索ではなくハイブリッド検索と親子分割を選べる点は、長い公式アカウント記事をそのまま分割すると文脈が切れる問題への対処として読める。ただし分割品質や検索精度の実測値は README に記載がなく、導入時に自前の文書で確かめるしかない。
Docker Compose で起動するまでの実際の手順
README が示す導入手順は短い。Docker を入れたうえでリポジトリを clone し、docker ディレクトリへ移動して compose を起動する。コマンドは sudo curl -sSL https://get.docker.com/ | CHANNEL=stable sh、git clone https://github.com/zhimaAi/chatwiki.git、cd chatwiki/docker、docker compose up -d の 4 段階である。起動後は IP:port でアクセスし、ポートは ${CHAT_SERVICE_PORT} で既定値が 18080、このポートが開いている必要があると README は注記している。初期の管理者アカウントはユーザー名 admin、パスワード chatwiki.com@123 と明記されている。Docker を使わない導入手順、オフライン導入、宝塔（Baota）Linux パネルや 1Panel 経由の導入、ローカルモデルの配備、モデルプロバイダと対応モデルの設定、プッシュ通知用の外部サービスとドメイン設定が、いずれもヘルプドキュメントへのリンクとして用意されている。対応モデルは DeepSeek R1、doubao pro、qwen max、OpenAI、Claude など 20 以上と README は述べるが、個々のモデル名と API キー取得手順はドキュメント側の確認が必要だ。
MCP と OpenAPI を軸にした外部連携の設計
ChatWiki は自前のワークフローだけで閉じず、外部の MCP サービスを取り込む方向と、逆に自前のワークフローを MCP サービスとして公開する方向の両方を README で謳っている。双方向の MCP 対応と表現されている箇所がこれにあたる。加えて既存業務システムと接続するための OpenAPI インターフェースが用意されている。ワークフローの種類は会話型とプラグイン型に分かれ、ノードとして基本ワークフローノード、双方向 MCP、Agent モード、ユーザーとの対話が挙げられている。配信先も多様で、デスクトップクライアント、WebApp としての公開、Web サイトへの埋め込み、公式アカウント／サービスアカウント、WeCom のスタッフ、WeChat 店舗のスタッフが列挙される。権限は管理者・編集者・閲覧者の 3 階層でデータ分離を行い、IP ホワイトリストと恒久的なログインログを備えるとしている。ここで注意したいのは、README が機能の存在を示すだけで、MCP のプロトコルバージョンや OpenAPI のエンドポイント一覧までは本文に書いていない点だ。連携設計は実際の API 定義を読んでから決めることになる。
ライセンス表記 NOASSERTION が残す判断の空白
このリポジトリのライセンスは NOASSERTION と表示されており、これは GitHub がライセンスファイルを既知の SPDX 識別子として認識できなかった状態を意味する。MIT や Apache-2.0 のような標準ライセンスが確定しているわけではない。README にはライセンス条項の説明も、商用利用や再配布の条件も見当たらない。コミュニティ版という呼称が使われていることから、有償の上位版が別に存在する構成が推測されるが、README の範囲ではその境界は示されていない。したがって、社内利用なのか顧客向けサービスへの組み込みなのか、ソース改変の有無によって条件が変わる可能性があり、法務確認を経ずに本番採用するのは避けたい。ここで断っておくと、本稿は法的助言ではなく、リポジトリの表記から読み取れる事実の整理にすぎない。ライセンスファイルの実体と配布元への問い合わせが採用の前提条件になる。
n8n や Coze と何が違うのか
README 自身が「垂直领域的 coze、n8n」という位置づけを掲げている。汎用のワークフロー自動化である n8n との差は、ノードの抽象度ではなくトリガーの所在にある。n8n は Webhook やスケジュール、各種 SaaS のイベントを起点にする汎用ツールで、WeChat 公式アカウントの私信やコメント、フォロー解除といったイベントは自分でブリッジを書かない限りノードとして現れない。ChatWiki はそこを最初からトリガーとして用意し、返信・タグ付け・下書き生成・記事公開という公式アカウント固有の操作を処理ステップとして並べている。Coze との差は配備の場所で、Coze はホスト型のエージェント構築環境であるのに対し、ChatWiki は Docker Compose で自前のサーバーに置く前提になっている。中国語文書の検索に zhparser を前提とする点も、英語圏向けに設計された汎用ツールとの実務上の分かれ目になる。逆に、WeChat 以外のチャネルが主戦場なら、この特化は制約にしかならない。
向かないケースと運用コストの見積もり
最初に断っておくと、当方でこのソフトウェアを導入して動かしたわけではない。以下は README とリポジトリのメタデータから読み取れる範囲の話である。向かないケースとしてまず挙げられるのは、WeChat 公式アカウントを接客の主チャネルにしていない組織だ。トリガーも処理ステップも WeChat 固有の操作に寄っており、Slack やメールの一次対応を自動化したいなら別の道具を選ぶ理由が強い。次に、複数の顧客企業へ SaaS として提供する形態。3 階層の権限とデータ分離は用意されているが、テナント分離の粒度や課金単位は README に記述がない。三つ目は、モデルの推論コストを固定費として見積もりたい場合で、20 以上のモデルを切り替えられる自由度は、そのまま従量課金の変動要因になる。更新頻度は高く、リリースは v2.9.1 から v2.9.3 まで約 1 か月で 3 回、更新履歴には QA 知識ベースのゴミ箱一括削除、外部サービスの PC と H5 のページ改修、機密語上限の 20,000 件への引き上げ、一部埋め込みシナリオで Context が渡らない不具合の修正が並ぶ。コミュニティ版を追従させるには、この頻度のアップグレードを前提とした検証環境が必要になる。
編集部の結論
WeChat 公式アカウントを運用していて、私信・コメント・メニュークリックを起点にした自動応答と、公式アカウント記事を知識ベースへ取り込む導線を自前のサーバーで持ちたいチームに向く。逆に WeChat 以外のチャネルが主軸の企業、マルチテナントの SaaS として外部提供したい事業者、ライセンス条件を法務が確定できない組織は採用を見送るべきだ。導入前に確認すべきは 3 点で、第一にリポジトリのライセンス表記が NOASSERTION のままであり商用利用条件が README から読み取れないこと、第二に docker compose up -d 後の既定管理者パスワードが chatwiki.com@123 であるため公開前に必ず変更すること、第三に CHAT_SERVICE_PORT（既定 18080）とモデルプロバイダの API キー設定を本番ネットワークで通すことだ。
コミュニティノート