NASとZenbookでローカルAI基盤を作ろうとして、頑張ったけど断念した話
OpenClaw・Ollama・Caddy HTTPSまで通したが、軽量ローカルLLMがエージェント実行に耐えなかった
結論だけ先に言うと、接続までは作れた。でも、軽量ローカルモデルでは“実運用の文脈量”に耐えられなかった。
はじめに
今回は、NASとZenbookを組み合わせて、自分用のローカルAI基盤を作ろうとした記録です。
構成としては、NAS側にOpenClaw Gatewayを置き、Zenbook側でOllamaを動かし、NASからZenbookのOllama APIを叩く形を目指しました。
やりたかったのは、単にローカルLLMを一問一答で動かすことではありません。
NASを記憶と制御の場所にする。
Zenbookを推論ホストにする。
OpenClawでエージェント実行する。
Control UIやObsidianから普段使いできる形にする。
つまり、NASが記憶、Zenbookが頭脳になるようなローカルAIエージェント基盤です。
結論から言うと、接続・HTTPS・pairing・trusted proxyまでは越えられました。
ただし、軽量ローカルLLMでは、OpenClawのエージェント実行に必要な文脈量、応答形式、timeout条件に耐えられず、今回は断念しました。
NASとZenbookで目指したローカルAI基盤の構成
まず、目指していたのはこんな構成です。
図1. 目指した全体像
発想としては、かなり気に入っていました。
NAS は記憶と制御
Zenbook は推論
入口は Control UI や Obsidian
という役割分担です。
いわば、
「NASが記憶、Zenbookが頭脳」
という構成を作りたかったわけです。
OpenClaw・Ollama・CaddyでローカルAI基盤を作る手順
机上では、手順もかなり素直でした。
図2. 想定した構築ステップ
この流れ自体は、今でも間違っていなかったと思っています。
実際、途中まではかなり順調でした。
OpenClaw Gateway・Ollama API・HTTPS接続までは成功した
全部ダメだったわけではありません。
むしろ、接続や構成の土台はかなり作れました。
NAS上でOpenClaw Gatewayを起動し、Control UIから見えるところまで進んだ
Gateway 自体は動き、Control UI から見えるところまでは到達しました。
Zenbook上でOllamaは動き、ローカルLLM実行機として使えた
これは大きな発見でした。
Zenbook 単体で Ollama を動かし、モデルに応答させること自体はできました。
つまり、
「Zenbook がローカルLLM実行機として全く使えない」
わけではありません。
NASからZenbookのOllama APIを叩く構成は成功した
NAS から api/generate を叩いて応答を返すところまでは確認できました。
ここは重要で、少なくとも
Zenbook 単体では動く
NAS から API としても呼べる
ことは事実として確認できています。
Caddy internal TLSでOpenClawをHTTPS化できた
ここはかなりハマりましたが、最終的には
Caddy を使う
internal TLS を使う
Windows に root 証明書を入れる
openclaw.home.arpa のようなローカル名で開く
ところまで進みました。
OpenClawのpairing・origin not allowed・trusted proxy問題を解消した
途中で順番にぶつかったのがこのあたりです。
origin not allowed
secure context 問題
pairing required
trusted proxy 問題
このあたりを一つずつ潰していって、
最終的には HTTPS経由で Control UI が OpenClaw に接続するところまでは到達しました。
OpenClawとOllamaの構成は、どこで崩れたのか
問題の核心はここです。
モデルが“動く”ことと、エージェントの中で“耐えられる”ことは別だった。
これです。
Zenbook 上で Ollama が単体で応答することは確認できました。
でも OpenClaw の中では、単なる一問一答ではなく、
セッション
文脈保持
応答形式
エージェント処理
timeout 制御
UIとの往復
が乗ってきます。
その結果、
単体では動く軽量モデルでも、OpenClaw の実行条件では耐えられなかった
というのが今回の本質でした。
ローカルLLMがエージェント実行に耐えられなかった理由
図3. 実際に起きたこと
qwen系モデル・timeout・reasoning・format相性を調査した
かなりいろいろ試しました。
モデルの切り替え
主に Qwen 系を試しました。
qwen2.5 系
qwen3.5 系
0.8b / 2b / 9b など
やってみると、問題の出方がモデルごとに違いました。
thinking 非対応
format 相性
idle timeout
最終 timeout
単純に「軽いモデルにすれば解決」ではなかったです。
timeout の延長
OpenClaw 側の idle timeout も伸ばしました。
最初は、時間が短すぎるだけかと思ったからです。
でも結果は、
長く待つようになっただけで、成功するわけではなかった
というものでした。
つまり、秒数の問題だけではありませんでした。
reasoning / format まわりの調整
モデル定義の reasoning を変えたり、OpenClaw 側のモデル認識との整合も取りにいきました。
ここで分かったのは、
Ollama で返るかどうか
と
OpenClaw が正しく扱えるかどうか
は全然別だ、ということです。
HTTPS / secure context / pairing / proxy の解消
接続まわりも相当ハマりました。
図4. 接続系の問題を潰した流れ
このあたりを越えたことで、逆に
最後に残ったのが本当にモデル問題だ
と切り分けられました。
ローカルでモデルが動くことと、エージェント実行で実用になることは違う
今回いちばん大きかった発見は、これです。
Zenbook で Ollama は動く
これは事実です。
単体で見ると、Zenbook はローカルLLM実行機としてちゃんと動きます。
でも OpenClaw の要求水準では別問題になる
ここが重要でした。
OpenClaw の実行は、単なる API 呼び出しではなく、
文脈を抱えたエージェント実行です。
その中で軽量モデルは、
応答が不安定
timeout しやすい
形式相性に引っかかる
という問題を起こしました。
図5. 今回の本当のボトルネック
「ローカルでモデルが動く」 ≠ 「エージェント実行で実用になる」
この差は、実際にやってみないと分からなかったです。
OpenClaw・Ollama・NAS・Zenbook構成はいったん断念
結論として、今回はこの構成をいったん断念します。
少なくとも今回の
NAS が制御と記憶を持つ
Zenbook が推論を担当する
OpenClaw でエージェント実行する
それを軽量ローカルモデルで日常利用する
という形は、今の手元環境では厳しかったです。
無理やり完成と言い張ることもできます。
でも、それは違うと思いました。
今回は、
「ここまではできた。でも、この前提では先に進めない」
と整理して、一度引くことにします。
次は推論だけ外部APIに逃がし、小さなローカルAI用途から始める
次は少し方向を変えようと思っています。
1. 推論だけ外に逃がす
記憶やデータの置き場所はローカルに残しつつ、推論だけ外部APIや別の強い環境に寄せる。
2. OpenClaw に全部を背負わせない
最初から全部をエージェント化するのではなく、
Vault 管理
ノート整理
軽い自動分類
検索補助
のように、小さく確実に動くものから積み上げる。
3. 推論ホストの前提を見直す
Zenbook は単体では Ollama を動かせる。
でも、エージェント実行込みでは別の条件が必要なのかもしれません。
まとめ：OpenClawとOllamaでローカルAI基盤を作るなら、モデル単体の動作だけでは足りない
今回は、NASとZenbookを使ってローカルAI基盤を作ろうとしました。
NASを記憶と制御にする。
Zenbookを推論ホストにする。
Zenbook上でOllamaを動かす。
NAS上でOpenClaw Gatewayを動かす。
Control UIやObsidianから使える形を目指す。
構成としては、かなり気に入っていました。
実際、接続まではかなり進みました。
NAS上でOpenClaw Gatewayは起動できた。
Zenbook上でOllamaは動いた。
NASからZenbookのOllama APIを叩けた。
Caddy internal TLSでHTTPS化できた。
origin not allowed、secure context、pairing required、trusted proxy問題も越えられた。
つまり、ネットワークや接続の土台はかなり作れました。
ただし、最後に残った問題はモデルでした。
Zenbook上でOllamaが単体で返答できることと、OpenClawの中でエージェント実行に耐えられることは別でした。
OpenClawでは、単なる一問一答ではなく、セッション、文脈保持、応答形式、エージェント処理、timeout制御、UIとの往復が乗ってきます。
その中で軽量ローカルモデルは、応答の不安定さ、format相性、idle timeout、最終timeoutに引っかかりました。
今回の一番大きな発見は、ここです。
ローカルでモデルが動くことと、エージェント実行で実用になることは違う。
これは、実際にNAS、Zenbook、OpenClaw、Ollamaをつないでみないと分かりませんでした。
次にやるなら、推論だけ外部APIや強い環境に逃がす。
OpenClawに全部を背負わせず、Vault管理、ノート整理、軽い自動分類、検索補助のような小さな用途から始める。
あるいは、推論ホストの前提を見直す。
今回の構成はいったん断念しました。
でも、失敗ではなく、ローカルAI基盤を現実的に作るための前提が見えた検証だったと思います。
