OpenClaw 汉化发行版を採用する前に読む、同期方式とライセンス表記の実際

漢化版が埋めるのは、機能の欠落ではなく操作語彙の欠落である

OpenClaw 本体は、WhatsApp、Telegram、Discord といったチャットアプリ越しに個人用 AI アシスタントを操作するプラットフォームだと README は説明している。メールやカレンダー、ファイル操作を任せる使い方を想定している。この配布物が変えるのは、その操作面の言語である。CLI と Dashboard の表示を中国語に置き換えた版を、リリースと npm パッケージとして配っている。

対象読者は、中国語で日常業務を回している個人や小規模チームで、設定ファイルやエラーメッセージを英語のまま読む負担を減らしたい層になる。README の冒頭には、上流リポジトリの更新を毎時同期し、遅延を 1 時間未満に抑えると書かれている。翻訳の品質そのものより、上流への追従速度を売りにした配布物だという性格がここに出ている。

注意したいのは、これが上流の fork なのか翻訳リソースの重ね当てなのかが README からは判別できない点である。リポジトリの主要言語は JavaScript とだけ示され、翻訳対象のファイル構成は docs/CONTRIBUTING.md の「项目结构」節に委ねられている。採用判断の前に、その節で翻訳がどの階層に入るのかを確認したほうがよい。

毎時同期は CI の nightly ワークフローが担う

README のバッジ欄には Nightly Build のワークフローが並び、リリース一覧にも nightly タグが 2026-09-09 付で存在する。安定版の v2026.9.3-zh.1 が同日、その二日前に v2026.9.2-zh.1 が切られている。上流の更新を取り込み、翻訳を当て直し、タグを打つ流れが短い間隔で回っていることが、この並びから読み取れる。

仕組みとして確認できるのはここまでである。差分をどう抽出し、どのファイルを翻訳辞書に突き合わせ、衝突をどう解消しているかは README に記述がない。翻訳規範は docs/TRANSLATION_GUIDE.md に用語表と原則、スタイルガイドとして分離されており、用語の揺れを抑える運用を意図しているらしいことは伺える。ただし、上流が文字列を変更したときに翻訳が外れて英語に戻るのか、ビルドが失敗して nightly が落ちるのかは、この資料からは判断できない。

同期を売りにする配布物では、失敗の見え方が重要になる。nightly が数日空いたときに、それが上流の変更によるものか翻訳側の破損かを利用者が切り分けられるかどうかは、実際に nightly のワークフロー履歴を開いて確かめるしかない。

導入は npm パッケージとリリース成果物の二経路

README が示す入口は複数ある。npm のバッジは @qingchencloud/openclaw-zh を指しており、Node.js を前提条件として挙げている。インストール手順の詳細は docs/INSTALL_GUIDE.md に分割され、前提条件、インストール、初期化設定、動作検証、応用設定、モデル設定、デーモンという段階に分かれている。

もう一つの経路は GitHub Releases で、Windows、macOS、Linux の三平台向けの成果物が並ぶ。Docker を使う場合は docs/DOCKER_GUIDE.md に、一括デプロイ、ローカル起動、リモートデプロイ、Token 認証、Nginx 逆プロキシ、Docker Compose、エラー排查という節が用意されている。リモート公開を想定するなら、この Token 認証の節を飛ばしてはいけない。

モデルの接続は初期化時に選ぶ。README の協賛枠の説明では、OpenAI Compatible を選び、Base URL に https://ciyapi.79tian.com/v1 を入れて Key を貼る手順が例示されている。これは第三者の API サービスであり、README 自身が「第三方赞助推广，具体规则以词元 API 页面为准」と断っている。同じ初期化画面から Claude や ChatGPT 系のプロバイダを選ぶこともできるので、この例はあくまで一例として読むべきである。

Gateway 再起動とアンインストールが独立した節になっている理由

目次を眺めると、常用命令、网关重启、卸载教程、更新升级がそれぞれ独立した見出しになっている。通常のツール紹介ならコマンド一覧に吸収されそうな項目が、単独の節として立っている。

これは、常駐プロセスとして動くアシスタントを扱う配布物の性格によるものだと考えられる。設定や翻訳リソースを差し替えても、稼働中の Gateway が古い状態を掴んだままだと変更が反映されない。だから再起動の手順が、更新手順とは別に切り出されている。同じ理由で、アンインストールも「消したつもりで残る」問題を避けるために独立している。

ここから実務上の含意が一つ出る。漢化版の更新を適用したあと、Gateway を再起動せずに「翻訳が反映されない」と判断すると、原因を取り違える。逆に、再起動を挟めば直る種類の不具合と、翻訳自体が当たっていない不具合は別物である。切り分けの順序は、更新、再起動、表示確認の三段になる。

上流追従型の配布物に固有の弱点

この配布物の価値は上流への追従速度に依存している。裏返せば、上流が活発に動くほど、翻訳側が一時的に壊れる窓が生まれる。nightly タグが存在すること自体は、常に安定版と同等の品質が nightly にあることを意味しない。README は nightly の中身について何も保証していない。

二つ目の弱点は、漢化版で発生した不具合の切り分けが難しいことである。上流のバグなのか、翻訳の当て方に起因する表示崩れなのか、判断材料が README にはない。上流のリポジトリと本リポジトリの両方を見比べる必要が出る場面がある。

三つ目は、向かない用途の存在である。上流の挙動をそのまま検証したい場合、あるいは翻訳を経由せず英語のエラーメッセージをそのまま検索エンジンに投げたい場合、漢化版は邪魔になる。エラーの原文が中国語に置き換わっていれば、上流の issue を検索する際の手がかりが減る。障害対応を英語の一次情報で進める習慣があるチームには、この配布物は合わない。

ClawPanel と ClawApp という別解、そして本家をそのまま使う選択

README は同じ作者圏の道具として ClawPanel と ClawApp を並べている。ClawPanel は可视化管理面板で、AI 助手を内蔵し、環境を自動検出してターミナルなしで導入できると説明されている。ClawApp はスマートフォンのブラウザから WebSocket でストリーミング会話するクライアントで、PWA と APK の両方の形を取る。

これらと本リポジトリの違いは、置き換える対象の層にある。漢化版は OpenClaw 本体の CLI と Dashboard の文字列を中国語に置き換える。ClawPanel は導入と管理の操作を GUI に移し、ターミナル操作そのものを減らす方向で解く。中国語化と GUI 化は別の課題であり、片方だけでは足りない場合がある。ターミナルは読めるが設定項目の意味を中国語で確認したいなら漢化版、コマンド自体を触りたくないなら ClawPanel、という住み分けになる。

もう一つの比較対象は上流の OpenClaw そのものである。翻訳を挟まない分、リリースの追従も不具合の切り分けも単純になる。中国語 UI が必須でなければ、上流を直接使うほうが検証の手数は少ない。README の説明を読む限り、漢化版を選ぶ理由は操作性の言語であって、機能差ではない。

ライセンス表記の不一致と、更新コストの見積もり

README のバッジは MIT を示し、LICENSE ファイルへのリンクも張られている。しかしリポジトリのメタデータ上、ライセンスは NOASSERTION と記録されている。これは GitHub が LICENSE の文面を既知のライセンス雛形として認識できなかった状態を意味する。MIT と書かれたバッジと、機械判定が一致していない。

ここで確認すべきは、LICENSE ファイルの実際の文面である。上流 OpenClaw のライセンス条項が汉化版にも及ぶのか、翻訳部分に別の条件が付くのかは、README からは読み取れない。ライセンスの解釈は法務の領域なので、社内規程がある組織は配布前に原文を確認する必要がある。ここでは判断を述べない。

更新コストの面では、npm パッケージ名が固定されているため、導入側は @qingchencloud/openclaw-zh のバージョンを pin するか、nightly を追うかを選ぶことになる。nightly を追う運用は、翻訳の破損を自分で検出する前提の運用である。安定版のタグは v2026.9.3-zh.1 のように日付と zh の連番で振られているので、この形式を CI のチェックに使えば、上流のどの版に対応するかを追跡しやすい。

編集部の結論

中国語話者のチームで OpenClaw を社内展開し、CLI と Dashboard の英語表記を読ませたくない場合には候補になる。逆に、上流の挙動をそのまま検証したい場合や、依存パッケージの出所を厳密に管理する規程がある組織には向かない。採用前に確認すべきは三点で、npm 上の @qingchencloud/openclaw-zh がどのバージョンの上流に対応するか、nightly タグと v2026.9.3-zh.1 のどちらを固定するか、そして LICENSE ファイルの実際の文面が README の MIT バッジと一致するかである。

公式情報源

1. 1186258278/OpenClawChineseTranslation on GitHub
2. Issues
3. Project website
4. README
5. Releases