ChatGPT-On-CS を自前運用できるか：AGPL-3.0 のSaaS型AI客服とその境界

このプロジェクトが埋めようとしているのは、店舗ごとに分断された客服の画面である

淘宝、拼多多、抖店、京東、京麦、千牛、微信、小紅書、抖音、B站、微博、知乎。中国のEC事業者が日常的に開く管理画面は、プラットフォームごとに別々のドメインと別々のログインを持っている。問い合わせが1日数十件なら人が切り替えれば済むが、複数店舗を運営すると、返信の遅れと取りこぼしがそのまま評価に響く。ChatGPT-On-CS が狙うのはこの切り替えコストで、README の製品デモでは「聚合聊天」として、淘宝・拼多多・抖店・京東の相談が同じ列に流れ込む画面が示されている。対象は開発者ではなく、店舗運営の実務者と、その運用をOEMで製品化したい事業者である。リポジトリのトピックに autohotkey が入っている点は示唆的で、純粋なAPI連携ではなく、デスクトップ上の操作を介した自動化が設計に含まれている。

対応プラットフォームの広さは、そのまま検証の難しさになる

READMEの「主要特性」には全プラットフォームとして微信、千牛、哔哩哔哩、抖音企業号、抖音、抖店、拼多多、微博聊天、小紅書専業号運営、小紅書、知乎が列挙されている。テキストだけでなく音声と画像も扱い、知識庫として自社ファイルをアップロードして回答をカスタマイズできると書かれている。モデル側は GPT3.5/GPT4.0、通義千問、文心一言、DeepSeek に対応するとの記述があり、トピックには dify も含まれる。ただし、これだけの数のプラットフォームを1つのコードベースで面倒を見るということは、各社のDOMや画面遷移が変わればどこかが壊れるということで、壊れた箇所の特定は利用者側の作業になる。READMEは各プラットフォームの接続方式の違いには触れていない。

READMEが「使い方」をリポジトリの外に置いている理由

このリポジトリのREADMEを読んで最初に戸惑うのは、インストール手順も設定キーも書かれていないことだ。「使用指南」の節は、機能の使い方は上部の製品デモ6本を見よ、製品能力と各アプリの説明は jinxiaoai.com/apps を見よ、という2文で終わっている。npm や pnpm のコマンド、環境変数、設定ファイルのパスは本文中に一切登場しない。これは書き忘れではなく、配布チャネルがGitHubではなくホステッドサービスであることを示している。したがって、リポジトリをcloneしてローカルで動かす前提の読者は、READMEだけでは出発点に立てない。ソースを読み解くか、公式サイトのドキュメントを辿るか、いずれかの経路を自分で確保する必要がある。READMEにコマンドがないという事実自体を、採用判断の材料として扱うべきだ。

AGPL-3.0 と「商業使用は要連絡」の二重構造

ライセンスは AGPL-3.0 で、READMEの「使用協議」は要点を4項目に整理している。個人使用は完全無料で制限なし、商業使用は連絡して商業授権を得る必要がある、コード改変は商業授権がない限り改変部分をオープンソース化して著作権表示を保持する必要がある、詳細は LICENSE を参照せよ、という内容だ。ここで注意したいのは、AGPL-3.0 はネットワーク越しにサービスとして提供する場合にもソース開示を求める条項を含む点で、READMEの「商業使用には連絡」という運用ルールはその上に重ねられた追加の条件になる。自社ECの社内ツールとして使うのか、顧客にSaaSとして売るのかで、この2つの条件の効き方が変わる。ライセンス解釈はここで断定できないので、実際の利用形態を LICENSE 本文と突き合わせる作業は省略できない。

リリースの刻印とコミットの刻印がずれている

供給されている情報の中で最も気になるのは日付のずれだ。最新リリースは v1.4.5 で 2024-09-07、その前が v1.4.4 で 2024-09-01、v1.4.3 が 2024-08-28 と、2024年8月末から9月上旬に3本が集中している。一方で last push は 2026-08-27 を示している。約2年の空白のあいだにリリースタグが打たれていないことになる。READMEのロードマップには「開発中」として抖音直播平台自動回復、多平台内容自動発布、本地大模型支持の3項目が未チェックで残っており、ローカルLLM対応が完了していないことは本文から確認できる。タグとコードのどちらが現在の姿を反映しているかは、コミット履歴を見ない限り判断できない。

jinxiaoai.com というSaaSが本体である可能性

READMEの構成は、オープンソースプロジェクトのそれというより製品サイトのそれに近い。冒頭のロゴは jinxiaoai.com へのUTM付きリンクで、ナビゲーション、製品デモ、OEM合作伙伴招募、微信客服のQRコード、フッターの「立即体験」まで、すべてが同じドメインへ向かう。OEMの節では、技術方案、ブランド定制、合作分成、技術支持、培訓と文档を提供すると書かれており、これはコードの提供ではなくパートナーシップの募集である。つまりこのリポジトリは、SaaSの認知獲得とOEMチャネル開拓の入口として機能している。ソースが公開されていることと、それが単独で完結する製品であることは別の話だ。自前でホストしたいチームは、この構造を理解したうえで README の外にある情報を探すことになる。

代替として何を比べるか：Dify とブラウザ自動化の違い

READMEのトピックには dify が含まれている。Dify はLLMアプリケーションを組み立てるための基盤で、プロンプト、ナレッジベース、ワークフローを自分の環境に置き、外部のチャット画面やAPIから呼び出す形を取る。ChatGPT-On-CS は逆で、既に存在するECプラットフォームの管理画面に接続し、そこでの会話を成立させることを主目的にしている。前者はアプリの土台を提供し、後者は既存の業務画面にAIを差し込む。どちらが優れているという話ではなく、自社に必要なのが「客服の応答を自動化する層」なのか「LLMアプリを内製する土台」なのかで選ぶ場所が変わる。もう一つの比較軸はブラウザ自動化で、Playwright などで自前のスクリプトを書けば接続先を自由に選べるが、プラットフォーム側の画面変更に追随する保守はすべて自社の負担になる。ChatGPT-On-CS はその追随を誰かがやってくれる前提で使うものだ。

導入前に潰しておくべき確認項目

最初に確認すべきは、リポジトリ内にセットアップ手順が存在するかどうかだ。READMEにはコマンドも設定キーもないため、docs ディレクトリの構成と、jinxiaoai.com/apps に何が置かれているかを並べて見る必要がある。次に、v1.4.5（2024-09-07）以降のコミットで何が変わったのかを追う。タグが2年近く打たれていない以上、リリースノートだけを根拠に現在の挙動を語ることはできない。3点目は、AGPL-3.0 の下で自社の利用形態がどこに位置するかで、社内利用か再販かによって条件が変わる。4点目は、READMEが「開発中」としているローカル大模型支持が未完了である以上、モデルを外部APIに依存する構成を前提にコストとデータの扱いを試算することになる。これらはどれもREADMEを読むだけでは埋まらない。

編集部の結論

導入を検討すべきなのは、淘宝・拼多多・抖店・京東など複数店舗の問い合わせを1画面に集約したい運用担当者と、OEM前提で自社ブランドの客服製品を立ち上げたい事業者である。逆に、ソースを読んで挙動を検証したいエンジニア、AGPL-3.0 のソース開示義務を避けたい商用利用者、SaaSに顧客データを預けたくない組織には向かない。着手前に確認するのは3点。READMEの「使用指南」が動画と jinxiaoai.com/apps に委ねられている以上、リポジトリ内にセットアップ手順が存在するかを自分の目で確かめること。次に、v1.4.5 のリリース日が 2024-09-07 である一方 final push が 2026-08-27 であるため、この約2年間に何がコードとして入ったのかをコミット履歴で追うこと。最後に、README の「商业使用：需要联系我们获得商业授权」という一文が自社の利用形態に当たるかを、法務ではなくまず自分で条文と突き合わせること。

公式情報源

1. cs-lazy-tools/ChatGPT-On-CS on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases