見出し画像

【第1回】UGREEN NASでAIエージェントは動く？ DXP2800にDockerとOllamaを入れて試した話

じぶん更新中 | AIを使える人になるnote

UGREEN DXP2800を買った。写真のバックアップとか、TimeMachineとか、ファイル共有とか、まぁNASとしては普通に使ってたんだけど、ある日ふと思った。

【第1回】UGREEN NASにAIボットを住まわせたら想像以上に大変だった話

NAS、ストレージだけに使うのもったいなくない？

「このNAS、Intel N100載ってるんだよな…… Dockerも動くし、AIでも動かしてみるか」

きっかけはDiscordだった。仲間うちのサーバーで「AI botがいたら便利じゃない？」という話になり、じゃあNASに住まわせたら24時間動くし電気代も安いし最高じゃん、と。軽いノリで始めたこのプロジェクトが、まさかここまで沼にハマることになるとは、この時点では想像もしていなかった。

ちなみにDXP2800のスペックはこんな感じ。

  • CPU: Intel N100（4コア、最大3.4GHz）

  • RAM: 8GB DDR5

  • ストレージ: HDD 2ベイ + M.2 SSD スロット

  • OS: UGOS（Debian ベース、Docker対応）

N100はPassMarkで5000点超え。ちょっとしたデスクトップPC並みの性能がある。「LLMくらい動くやろ」と軽く考えていた。この楽観が後々の苦労の始まりだったわけだが。

OpenClawとの出会い

DiscordとAIを繋ぐ方法を調べ始めた。Discord.jsで自作ボットを書くか、既存のフレームワークを使うか。自作だとDiscord APIのゲートウェイ接続やメッセージハンドリング、会話のセッション管理など、けっこうやることが多い。

そんなとき見つけたのがOpenClawだ。AI エージェントのメッセージルーターとして、Discordのチャットを受け取ってLLMに投げて、返答をDiscordに返してくれる。要するに橋渡し役。

構成はシンプルで：

Discordメッセージ → OpenClaw → LLM → OpenClaw → Discord返答

Node.js製で、`npm install` して設定ファイル（`openclaw.config.json`）をいじれば動く。Discordボットのトークンと、LLMのAPIキーを設定に書くだけ。「これならいける」と思った。

設定で特に便利だと感じたのは、Discordのチャンネルごとにボットの振る舞いを変えられること。メンションで反応するか、特定のプレフィックス（`!claw` など）で反応するか。DMでの1対1チャットも対応している。DM認証にはペアリングコードが必要で、セキュリティ面もちゃんと考えられていた。

まずはOllamaでローカルLLM

最初はお金をかけたくなかったので、OllamaでローカルLLMを動かすことにした。OllamaはDockerイメージが公式で提供されているので、Docker Composeで OpenClaw と一緒に立ち上げる構成にした。

NASにSSHで入って、Dockerファイルを配置する。

sudo mkdir -p /volume1/docker/ai-stack
cd /volume1/docker/ai-stack

`docker-compose.yml` を書いて、Ollama と OpenClaw のコンテナを定義。ネットワークを共有して、OpenClaw から `http://ollama:11434` でアクセスできるようにする。

sudo docker compose up -d

コンテナが起動したら、Ollamaにモデルをダウンロードする。

sudo docker exec ollama ollama pull llama3.2:3b

DXP2800のRAMは8GB。llama3.2:3bなら約2〜3GBで収まるから、ギリギリいける計算。ダウンロードが終わったら、ちゃんとモデルが入ったか確認。

curl http://localhost:11434/api/tags

よし、入ってる。Discordから話しかけてみる。

返事が来た。

いや、正直ちょっと感動した。自分のNASの中で動いてるAIがDiscordで喋ってる。クラウドのAPIを叩いているわけじゃない。このNASの中のCPUで推論が走って、その結果がDiscordに返ってきている。すごくないか。しかも電気代はNAS全体で月数百円。24時間動かしっぱなしでもほぼコストゼロだ。

……でも、精度がちょっと

感動も束の間、すぐに現実に直面する。

llama3.2:3bは軽量モデルだ。パラメータ数30億。ChatGPTやClaudeが数千億パラメータと言われている中で、3bは本当に小さい。簡単な質問——「東京の天気は？」「Pythonでリストのソートは？」くらいなら答えてくれる。

でも、ちょっと複雑なことを聞くと途端に怪しくなる。

というか返答が遅い、遅すぎる。
返答待ちの時間、NASのCPU温度はどんどん上昇していく・・・。

「NAS上で24時間動くAI」というロマンは達成したものの、実用性を考えるとローカルLLMには限界があると感じ始めた。

3bモデルの限界一覧（体感）：

  • 長い文脈を覚えていられない — 5往復もすると最初の話題を忘れる

  • 日本語の敬語や自然な表現が苦手 — 翻訳調の日本語になりがち

  • コード生成の精度が低い — 構文エラーが頻発、ライブラリの使い方も古い

  • 複数ステップのタスクが壊滅的 — 「これ調べて、まとめて、表にして」みたいな指示がまず通らない

  • ハルシネーション（嘘）が多い — 自信満々に間違った情報を返す

「もうちょっと賢いモデル入れたら？」と思うかもしれない。7bモデル（llama3.2:7b）なら多少マシになるはず。でも試してみたら、8GBのRAMではスワップが大量に発生して、1つの返答に30秒以上かかるようになった。その間NAS全体がモッサリして、ファイル共有にまで影響が出始めた。NAS本来の仕事ができなくなっては本末転倒だ。

1bモデル（llama3.2:1b）に落とすことも考えたが、3bですら実用に耐えないのに1bにしたらさらに精度が下がる。それはもう「AIと会話している」というより「おみくじを引いている」に近い体験になりそうだった。

ローカルLLMの夢は一旦ここで諦めることにした。じゃあどうするか？答えは一つ。クラウドのAPIを使う——つまり、Claude APIへの切り替えだ。

次回：Claude APIに切り替えて精度は爆上がり。でもそこから本当の地獄が始まった——

次の記事 → 【第2回】ローカルLLMに限界を感じてClaude APIに切り替えたら、エラーとの戦いが始まった

いいなと思ったら応援しよう！