AingDesk レビュー：Electron 製ローカル AI アシスタントを Docker で動かすまで

AingDesk が埋めようとしている溝

ローカル LLM を試すとき、多くの人は Ollama を入れて CLI から叩き、別の用途では OpenAI 互換 API を Python スクリプトから呼ぶ、という分断した状態になりがちである。会話ログはターミナルのスクロールバックに消え、参照させたい社内文書は毎回プロンプトに貼り付けることになる。AingDesk はこの分断を 1 つのデスクトップアプリに畳み込むことを狙っている。README の一文目は「簡単好用的AI助手」、英語版では easy-to-use AI assistant と書かれており、対象読者は AI に詳しくない入門者だと明示されている。機能一覧にはローカルモデルと主要 API のワンクリック配備、ローカル知識ベース、エージェント作成、オンライン共有、ウェブ検索、サーバー配備、MCP クライアントが並ぶ。つまり単なるチャット UI ではなく、モデルの接続設定、文書の取り込み、外部ツール呼び出しを同じアプリの設定画面に集める設計である。

Electron クライアントとサーバー版が同じリポジトリに同居する構成

リポジトリの主要言語は TypeScript、トピックには electron、nodejs、ollama、localai、deepseek が付いている。ビルド手順は frontend ディレクトリで yarn を実行した後、リポジトリ直下でも yarn を実行し、最後に yarn dev で起動する。frontend と本体が別々の依存関係を持つ構成であり、Electron のメインプロセス側と画面側が分離されていることがこの手順から読み取れる。配布形態は 2 つある。公式サイト、CNB、GitHub Releases から取得する macOS / Windows のクライアント版と、Docker イメージ aingdesk/aingdesk を使うサーバー版である。サーバー版は 7071 番ポートで待ち受け、data、uploads、logs、bin、sys_data の 5 つのパスをボリュームとして外に出す。data と sys_data が分かれている点は注目に値する。前者は利用者が投入した会話や知識ベース、後者はアプリ自身の状態と推測できるが、README に各ボリュームの役割説明はない。バックアップ対象を決める際はこの区別を自分で確認する必要がある。

Docker で起動するまでに実際に打つコマンド

サーバー版の最短経路は README に載っている 1 行の docker run である。docker run -d --name node -v $(pwd)/data:/data -v $(pwd)/uploads:/uploads -v $(pwd)/logs:/logs -v $(pwd)/bin:/aingdesk/bin -v $(pwd)/sys_data:/sys_data -p 7071:7071 -w /aingdesk aingdesk/aingdesk を実行すると、カレントディレクトリ配下に 5 つのディレクトリが作られ、7071 番でアクセスできる状態になる。コンテナ名が node 固定なので、複数インスタンスを同じホストで動かす場合は --name を変える必要がある。Compose を使う場合は mkdir -p aingdesk で作業ディレクトリを作り、その中で wget https://cnb.cool/aingdesk/AingDesk/-/git/raw/server/docker-compose.yml を取得して docker compose up -d を実行する。compose ファイルの取得元が GitHub ではなく CNB の server ブランチである点は覚えておきたい。ネットワーク制限のある環境ではこの URL が最初の障壁になる。ソースから動かす場合は git clone の後、macOS 利用者であれば package.json から @rollup/rollup-win32-x64-msvc の依存を削除するよう README が指示している。プラットフォーム固有の依存を手で外す手順が残っていることは、ビルド周りが完全には自動化されていないことを示す。

知識ベースと MCP クライアントが想定する使い方

README の機能一覧で具体的な画像が添えられているのはローカルモデル、知識ベース、エージェント、共有、ウェブ検索、MCP クライアントの 6 項目である。知識ベースはローカルに置くと書かれており、文書を取り込んでモデルの回答に参照させる用途が想定されている。MCP クライアントを備えるということは、AingDesk 自身がモデルに道具を渡す側に回るのではなく、外部の MCP サーバーに接続してツールを呼び出す立場になる。ここで注意したいのは、MCP サーバーは多くの場合ローカルプロセスとして起動され、ファイルシステムやネットワークへの権限を持つことである。AingDesk の README には MCP サーバーの登録方法も、接続先プロセスのサンドボックス化についても記述がない。エージェント機能と組み合わせれば、モデルの判断でローカルプロセスが呼ばれる経路ができる。利便性の代わりに、どのサーバーを登録したかを把握しておく責任が利用者側に残る設計だと言える。

README が答えていない部分

ドキュメントとして最も薄いのは、複数人利用とデータの扱いである。オンライン共有機能があり、サーバー配備もできる。しかし共有した会話に誰がアクセスできるのか、認証方式は何か、知識ベースは利用者ごとに分離されるのかについて README は何も述べていない。ログイン機構の有無すら読み取れない。同様に、リリースは v1.2.2、v1.2.3、v1.2.4 と 2025 年 4 月から 5 月にかけて続いているが、各リリースの変更内容は提供された情報に含まれていない。マイナーバージョンが短期間で上がっていることから更新頻度は高いと分かるが、データスキーマの変更や設定ファイルの非互換が過去にあったかは判断できない。知識ベースの埋め込みモデルを何にするか、切り替えた場合に再インデックスが必要か、といった運用上の論点も README の範囲外である。これらは導入を決める前に docs.aingdesk.com と実際のリリースノートで埋めるべき空白である。

Open WebUI との設計の違い

同じくローカルモデルと文書を扱う配備型の選択肢に Open WebUI がある。両者の違いは配布の重心にある。Open WebUI はブラウザで使うサーバーアプリが本体で、利用者はブラウザからアクセスし、モデルの実行は Ollama など外部に任せる。AingDesk は Electron のデスクトップアプリが本体で、サーバー版はその延長として用意されている。この差は導入の摩擦に出る。Open WebUI は Docker イメージとブラウザさえあればよく、複数人で 1 つのインスタンスを共有する前提で作られている。AingDesk はまず個人のデスクトップで完結させ、必要ならサーバーに置くという順序を想定しているように読める。逆に、MCP クライアントを内蔵し、エージェント作成を画面上で行える点は AingDesk 側の特徴である。どちらが優れているかではなく、多人数的な共有を最初から設計に含めるか、個人の作業環境を起点にするかの違いである。

MIT ライセンスと更新コストの見積もり

ライセンスは MIT で、リポジトリの LICENSE 表記もそれに一致する。商用利用を含めて制限が少ない部類だが、同梱される依存パッケージや、接続する外部 API、MCP サーバーのライセンスは別々に確認する必要がある。MIT はあくまで AingDesk 自身のコードに対する条件である。更新コストの面では、短期間にパッチリリースが続いていること、frontend と本体で依存を二重に管理していること、macOS 利用者向けに package.json を手で編集する手順が残っていることを踏まえると、ソースから追従する運用はそれなりの手間になる。Docker イメージを使う場合はイメージタグを固定し、data と sys_data を別々にバックアップしてから更新する形が現実的である。具体的には、更新前に docker compose down で停止し、data と sys_data のディレクトリをコピーしてから新しいイメージで up し直す手順を自分で用意することになる。

編集部の結論

ローカルモデルと外部 API を 1 つの UI にまとめたい個人や小規模チームには向く。一方、会話履歴や知識ベースを複数ユーザーで共有する用途や、モデルごとの厳密な権限分離が要る場面には向かない。導入前に確認すべきは、v1.2.2 から v1.2.4 までのリリースノートに破壊的変更が書かれていないこと、バインドマウントする data、uploads、sys_data の各ディレクトリが既存データと衝突しないこと、そして MCP クライアントが接続する外部プロセスの権限を誰が管理するかである。

公式情報源

1. aingdesk/AingDesk on GitHub
2. License: MIT
3. Project website
4. README
5. Releases