LobsterAI を採用すべきか: Electron デスクトップAgentと OpenClaw ランタイムの分離を読む

LobsterAI が埋めようとしている穴は「実行環境」ではなく「作業環境」

多くのAgentはサンドボックスかクラウドのコンテナ内で動く。LobsterAI の README は、対象を「実際の作業環境」と明記している。ローカルファイル、端末コマンド、ブラウザ操作、文書、表計算、スライド、IM チャネル、スケジュール実行、プロジェクトワークスペースがその範囲だ。つまり抽象化されたツール呼び出しではなく、ユーザーのマシンにある実ファイルと実アプリが操作対象になる。

想定読者は、Excel で在庫と売上を管理しているような非エンジニアか、あるいは日常業務の反復部分を手元の環境で自動化したい開発者である。README のプロンプト例はこの性質をよく表している。「product-growth.xlsx を使って可視化ダッシュボードを作り、成長要因を要約して」という指示は、クラウド上のAgentでは成立しない。ファイルがローカルにあるからだ。

ここで注意したいのは、LobsterAI 自体がモデルを提供するわけではないという点である。README にはモデル選択が Agent ごとの設定項目として挙がっているが、どのプロバイダを使うかの記述は与えられた材料にはない。モデルの調達は利用者の側の前提条件になる。

Cowork と OpenClaw の分離が意味するもの

アーキテクチャの要点は、製品層と実行層を分けていることだ。README は「Cowork は LobsterAI の製品/セッション層であり、OpenClaw はその下のランタイムとゲートウェイである」と説明している。この分担により、ローカル永続化、権限、UI 状態、成果物、Agent、メモリ、IM バインディングはデスクトップアプリ側に残り、Agent の実行は OpenClaw が担う。

プロセス構成は三層に見える。Renderer は React、Redux Toolkit、Tailwind で、成果物レンダラ、設定、Agent/セッション UI、スキル、MCP、スケジュールタスク、IM 設定を持つ。Main プロセスは Electron のライフサイクル、IPC、SQLite 永続化、認証、ログ、OpenClaw の起動、ランタイム修復、スキル同期、IM ゲートウェイ、成果物サービスを担当する。両者をつなぐのが `openclawEngineManager`、`openclawConfigSync`、`openclawRuntimeAdapter`、`coworkEngineRouter` という四つのモジュールで、LobsterAI 側の状態を OpenClaw の実行時の振る舞いに変換する。

この設計の実利は、UI と権限管理を Electron 側で完結させられる点にある。反面、OpenClaw のバージョンに引きずられる結合点でもある。`openclawConfigSync` がどの設定キーを同期するかは README からは分からない。MCP サーバーの同期もこの経路を通ると読める。

28 個の組み込みスキルと Expert Kits の選び方

スキルは `SKILLs/skills.config.json` で設定される 28 個の組み込み群からなる。README が挙げるのは web 検索、Word、表計算、PowerPoint、PDF 処理、Remotion による動画生成、ブラウザ自動化、画像/動画生成、株式リサーチ、コンテンツ執筆、メール、天気、スキル作成である。

ここで混同しやすいのが Expert Kits との関係だ。README は「Kits は直接的なスキルとは独立に選択される」と述べており、シナリオ志向の Kit と個別ツールを組み合わせられる。つまり Kit はスキルの束ではなく、能力選択と参照資料をまとめたプリセットとして扱われている。

スキル作成用のスキルが含まれている点は見落とせない。組み込みの 28 個で足りない場合、設定ファイルを直接編集するのではなく、Agent にスキルを作らせる経路が用意されていることになる。ただし生成されたスキルが `skills.config.json` にどう反映されるかは、この材料からは確認できない。

動かすまでの手順と、初回だけ重い依存

配布バイナリは公式サイトか GitHub Releases から取得する。macOS と Windows のインストーラが用意されている。ソースから動かす場合の要件は Node.js `>=24.15.0 <25`、npm、そして git と pnpm である。pnpm が初回のみ必要になる理由は、固定された OpenClaw ランタイムを兄弟ディレクトリの `../openclaw` チェックアウトからビルドするためだ。

手順は次のとおり。

git clone https://github.com/netease-youdao/LobsterAI.git cd LobsterAI npm install

初回の開発実行は `npm run electron:dev:openclaw`。固定ランタイムが既に存在する日常の開発では `npm run electron:dev` を使う。レンダラの開発サーバーは `http://localhost:5175` で動く。

ビルド関連のコマンドも README に揃っている。`npm run build` は本番用レンダラバンドル、`npm run compile:electron` は Electron の main/preload の TypeScript ビルド、`npm test` は CI が使う Vitest のエントリ、`npm run lint` は src 全体の ESLint で「既存の負債を露出する可能性がある」と README 自身が断っている。変更ファイルだけを見るなら `npx eslint --ext` を使う。

Node.js の範囲指定が狭い点は実務上の摩擦になる。24.15.0 以上 25 未満という指定は、他のプロジェクトとバージョン管理を共有している開発者にとって切り替えの手間を生む。

IM 遠隔操作は便利だが、到達経路が増えるほど設定面も増える

LobsterAI は WeChat、WeCom、DingTalk、Feishu/Lark、QQ、Telegram、Discord、NetEase IM、NetEase Bee、POPO、メールからデスクトップの Agent に到達できる。マルチインスタンスのプラットフォームでは、異なるアカウントやチャネルを異なる Agent に紐付けられる。

これは「席を離れている間に手元のマシンへ仕事を投げる」という使い方を想定している。ただし設定対象が増えるということは、それだけ資格情報とバインディングの管理面が広がるということでもある。README は IM バインディングをデスクトップアプリ側の永続データとして扱うと述べているが、各プラットフォームの認証情報がどこにどう保存されるかの詳細は、この材料からは読み取れない。

もう一点、IM 経由の指示は承認フローと相性が悪い可能性がある。README によればファイル操作、端末コマンド、ネットワークアクセスのような機微な操作の前に承認を求める。デスクトップの前にいない状態で承認を求められたとき、その場で判断できるのか。設計上の問いとして残る。

ローカル永続化とメモリの置き場所

セッションとアプリデータはローカルの SQLite に置かれる。OpenClaw 側のワークスペースメモリは `MEMORY.md`、`USER.md`、`SOUL.md`、および日次のノートといったファイルを使う。この分離により、永続的な好みやプロジェクト文脈をセッションをまたいで持ち越せる。

ファイルベースのメモリは中身を人間が読めるという利点がある。エージェントの振る舞いがおかしいとき、SQLite の中を掘らずに Markdown を開けば前提を確認できる。同時に、これらのファイルがどのタイミングで更新され、どこまでが自動生成でどこからが手書きかを README は規定していない。手で書き換えた内容が次のセッションで上書きされるのかは、実際に動かして確かめるしかない。

成果物の扱いも見ておきたい。HTML、SVG、画像、動画、Mermaid 図、コード、Markdown、テキスト、文書、ローカルサービス成果物をアプリ内でプレビューし管理できる。生成物がアプリの外に散らばらず、レンダラ側で一覧できる構造だ。

MCP サーバーとの関係、そして向かないケース

外部ツールやデータソースは Model Context Protocol サーバー経由で接続する。ユーザーが設定したサーバーはローカルに保存され、有効なものが OpenClaw に同期される。

ここは MCP を直接使う場合との差がはっきりしている。MCP クライアントを自分で組むなら、サーバーの起動、認証、ツール一覧の取得、呼び出しのルーティングをすべて自前で書く。LobsterAI はその層を Electron アプリの設定 UI と永続化に畳み込み、実行は OpenClaw に委ねる。設定ファイルを手で書く代わりに GUI で管理できるが、その分だけ OpenClaw の設定同期という一段の間接層が入る。

向かないケースは三つある。第一に、ヘッドレスでサーバー上に常駐させたい用途。Electron のデスクトップアプリである以上、この形にはならない。第二に、Node.js のバージョンを固定できない環境。`>=24.15.0 <25` は譲れない前提として提示されている。第三に、`../openclaw` の兄弟チェックアウトを許容できないビルド環境。初回ビルドがこの外部パスに依存するため、CI やコンテナ内での再現には追加の手当てが要る。

ライセンスは MIT で、商用利用を含めて比較的制約が少ない。ただし同梱される OpenClaw ランタイムのライセンス条件は、この材料からは確認できない。配布物全体の条件を判断する前に、そちらの LICENSE を別途確認する必要がある。ここでは法的助言はできない。

メンテナンス頻度から見た採用判断

リリースは 2026.8.28、2026.9.3、2026.9.4 と、少なくとも 2026 年 8 月下旬から 9 月上旬にかけて短い間隔で出ている。最終 push は 2026-09-09 で、アーカイブはされていない。活発に動いているリポジトリを追いかける前提で使うなら、更新のたびに `npm install` と `npm run compile:electron` をやり直すコストを見込んでおくべきだ。

デスクトップアプリとして配布されている以上、多くの利用者はインストーラ経由で更新を受け取る。ソースから動かす開発者だけが、OpenClaw ランタイムの再ビルドという初回コストと、その後の同期ずれを負う。`npm run lint` が既存の負債を露出しうると README が認めている点も、フォークして手を入れる場合の前提として押さえておきたい。

採用の分かれ目は、ローカルファイルと実アプリを操作対象にしたいかどうかである。それが要件なら、クラウド型のAgentでは代替にならない。逆に、再現性の高いヘッドレス実行や、複数人での共有実行環境が要件なら、この構成は遠回りになる。

編集部の結論

ローカルファイルや表計算を扱う反復作業を、自分のデスクトップ上でエージェントに任せたい個人や小規模チームには向く。逆に、サーバー上でヘッドレスに動かしたい場合や、Node.js のバージョンを固定できない環境には向かない。導入前に確認すべきは、../openclaw の兄弟チェックアウトが初回ビルドで必要になる点と、承認を挟むファイル操作・端末コマンド・ネットワークアクセスの範囲が自分の作業ディレクトリと噛み合うかどうかである。

公式情報源

1. License: MIT
2. netease-youdao/LobsterAI on GitHub
3. Project website
4. README
5. Releases