nexu レビュー：OpenClaw を WeChat・Feishu・Slack に接続するデスクトップクライアント

nexu が埋めようとしている穴はどこにあるか

OpenClaw はエージェントを動かす側の仕組みだが、README の比較表によれば公式実装は CLI ベースで、各 IM チャネルへの接続は DIY とされている。nexu が狙うのはこの接続部分だ。エージェント本体を置き換えるのではなく、WeChat、Feishu、Slack、Discord という既存のチャット画面をエージェントのフロントエンドに変える。

対象として README が繰り返し挙げるのは One Person Company と小規模チームである。一人で EC を回す人、コンテンツを複数プラットフォームに展開する人、深夜にスタックトレースを Discord に貼る個人開発者。共通するのは、専用のチャット UI を新しく覚える気がなく、すでに開いているチャットアプリで済ませたいという動機だ。法人向けの統合基盤ではなく、個人の作業面をそのまま拡張する位置づけだと読める。

接続の実体：プラグイン、OAuth、ローカル保存という3層

README から読み取れるアーキテクチャは3つの層に分かれる。1つ目は IM 側の接続で、WeChat については WeChat 8.0.7 の OpenClaw プラグインを使うと明記されている。接続操作は「Click connect, scan with WeChat」と説明され、QR スキャンで紐付ける方式だ。Feishu、Slack、Discord も built-in と表現されているが、それぞれの認証手順の詳細は README には書かれていない。

2つ目はモデルプロバイダの認証である。MiniMax、OpenAI Codex、GLM (Z.AI Coding Plan) は OAuth ログインに対応し、API キーのコピペが不要だとされる。加えて BYOK の経路があり、アカウント作成やログインなしで自分の API キーを追加できる。つまり認証は「nexu アカウント経由」と「自前キー」の二本立てで、後者を選べばアカウントを持たずに使える。

3つ目はデータの置き場所で、README は「All data stays on your machine」と述べ、比較表でも「Local-first; we don't host your business data」と主張する。ただし、この記述が指すのは保存場所の話であり、モデル API への送信そのものを止めるという意味ではない。ローカルファーストという語が何を保証し、何を保証しないのかは README からは確定できない。

セットアップで実際に触るもの

導入は配布バイナリを起点にする。README が示す対応プラットフォームは macOS (Apple Silicon)、macOS (Intel)、Windows の3つで、ダウンロード先は nexu.io と記載されている。ソースからビルドする手順は README には見当たらず、TypeScript で書かれたリポジトリではあるが、利用者向けの導線はバイナリ配布が前提だ。

起動後の操作は GUI で完結するとされ、環境変数の設定や依存関係の解決は不要と明記されている。モデルを切り替えるときは GUI 上の操作で完結し、OAuth 対応プロバイダなら認証画面を経由する。自前キーを使う場合は API キーを入力するだけで、アカウント作成を求められない。

注意点として、README には設定ファイルのパスや config キー、CLI フラグの類が一切出てきていない。つまりヘッドレス環境や自動化パイプラインに組み込む手段は、少なくとも README の範囲では提示されていない。設定をコードで管理したいチームにとって、これは明確な制約になる。

README が答えていないこと

このプロジェクトの評価で最も難しいのは、主張と実装の間に検証可能な記述が少ない点だ。比較表では「Typical hosted Feishu + agent stacks」がデータをベンダーサーバー経由にすると批判されているが、nexu 自身が IM 接続時にどのようなメッセージフローをたどるのかは説明されていない。WeChat のプラグインがメッセージをどう取得し、どこでエージェントに渡すのかは不明のままだ。

もう一つ気になるのは、README に並ぶ利用事例がすべて一人称の体験談の引用で、動作の裏付けになる記述が伴っていないことだ。EC の出品を3言語で生成した、契約書40ページのリスク要約を10分で得た、といった話は機能の説明ではなく期待値の提示である。エージェントの出力品質はどのモデルを選ぶかに強く依存するはずで、クライアント側の価値は接続の手軽さに限定して読むのが妥当だ。

リリースは v0.1.10 から v0.1.12 までが2026年4月に集中しており、バージョン番号も 0.1 系である。API や設定の互換性が今後動く前提で接続することになる。

向かないケース：監査と自動化

nexu が明確に不向きなのは、通信経路を自分で証明する必要がある場面だ。README はローカル完結をうたうが、モデル呼び出しは外部プロバイダに飛ぶ。OAuth で nexu アカウントを使う構成を選べば、認証の主体が nexu 側に移る。規制産業や、データの流れを図にして説明する必要がある組織では、この構成は説明コストに見合わない可能性が高い。BYOK と自前キー運用に寄せればアカウント依存は薄まるが、それでもクライアント自体の挙動をソースで確認する作業は残る。MIT ライセンスなので fork して監査することは可能で、README もそれを利点として挙げている。ただしそれは、監査する人手がある組織に限った話だ。

自動化の観点も弱い。GUI 前提で CLI や設定ファイルの導線が README にないため、CI に組み込む、複数台に同一設定を配る、といった運用は想定されていない。サーバー上で常時動かす使い方よりも、手元のデスクトップで動かし続ける使い方に向く。

代替としての公式 OpenClaw と自前スタック

比較対象として README 自身が挙げるのは OpenClaw 公式実装である。違いは明白で、公式は CLI 操作と手動のモデル設定を前提とし、チャネル接続も自分で組む。nexu はその工程を GUI と内蔵スキルに置き換える。つまり両者は競合というより層が違う。すでに OpenClaw をスクリプトで運用し、設定を Git で管理している人にとって、GUI 化は後退になり得る。逆に、ターミナルを開かずに済ませたい人にとっては公式実装の CLI が障壁になる。

もう一方の比較対象は、ホスティング型の Feishu エージェント基盤だ。README はこれらを、モデルが固定され、データがベンダー経由になり、ソースが閉じていると整理する。対して nexu はモデル選択の自由とローカル保存、MIT ライセンスを差別化点に置く。ただしホスティング型には、運用を丸ごと委ねられるという利点がある。nexu を選ぶということは、その運用責任を自分で持つという判断でもある。

ライセンスと維持コストの読み方

ライセンスは MIT で、リポジトリの LICENSE に準拠する。fork、改変、再配布が許される条件の下で提供されるという意味であり、具体的な義務の解釈は利用者側の法務判断に委ねられる。ここで実務上効いてくるのは、MIT であるがゆえに、上流が開発を止めても fork して自走できるという点だ。デスクトップクライアントという性質上、OS のアップデートや IM 側の仕様変更に追随し続ける必要があり、その追随を誰が担うかが導入判断の中心になる。

維持コストの見積もりに使える材料は限られている。README には設定ファイルも移行手順も記載がなく、バージョン間の互換性ポリシーも示されていない。v0.1.10 から v0.1.12 までの3リリースが2026年4月の3週間に収まっていることから、更新頻度は高いと推測できるが、これは推測であって保証ではない。アップグレードのたびに接続をやり直す必要があるかどうかは、実際に試すまで分からない。

編集部の結論

導入を検討すべきなのは、OpenClaw エージェントをすでに動かしていて、CLI でのチャネル接続作業を GUI に置き換えたい個人や小規模チームだ。逆に、データ経路や認証フローを自前で監査する必要がある組織、WeChat 以外のチャネルを主軸に据えたいチームには現時点で勧めにくい。最初に確認すべきは、README が明示する WeChat 8.0.7 のプラグイン要件を自分の環境が満たすか、そして接続後にどのデータがどこへ送られるかを実際の設定画面とログで追えるか、この2点である。

公式情報源

1. License: MIT
2. nexu-io/nexu on GitHub
3. Project website
4. README
5. Releases