前回、朝のまとめの自動投稿、常駐AIとの一問一答、外出先からの「GO」「NO-GO」の一往復まで作りきって、「次にこの箱で何をするかは、まだ決めていない」と書いて終わった。あれから2か月半が経った。
静かに動き続けていた2か月半
その間、ラボは大きくは変わっていない。7月にHomepageとBeszel（ダッシュボードと計器盤）を足して以降、目立ったことはしていない。見張り番は淡々と生死を確認し、Discordの窓口も普段通りに答え続け、気づけば連続稼働78日になっていた。壊れず、詰まらず、ただ動き続ける。それだけの、静かな日々だった。
それ自体はありがたいことなのだが、しばらくすると「何か新しいことをしたい」という気持ちが出てきた。安定というのは、ある意味で退屈と隣り合わせなのかもしれない。今のままでは見張り番と窓口という「道具」しか住んでいない。もう一段階、何かを足したくなっていた。
Jevというものを知る
そんなときにたまたま読んだ記事で、TypeSafe社の「Jev」というAIを知った。文章をほとんど書かず、「はい」か「いいえ」か、あるいはいくつかの選択肢のうち、それぞれがどれくらいありそうか、という確率だけを、恐ろしく速く返してくるAIだという。判断だけを大量・瞬時に返すことに特化したタイプらしい。見張り番が拾ってきた異常を、文章で説明させるのではなく「これは深刻か、そうでないか」とだけ一瞬で判定させる。そんな使い方ができたら面白そうだ、と想像を膨らませた。
調べて、見送った
面白がって調べているうちに、一つ大事なことが分かった。JevはクラウドのAPI専用で、提供元のサーバーに質問を送って答えを受け取る形でしか使えない。ファイルとして配られているわけではないので、自宅のサーバーに持ってきて自分の箱の中で動かす、ということができない。
「自宅サーバーに載せられるかどうか」は、そのAIが賢いかどうかとは関係がない。どういう形で世に出ているかで決まるのだと、ここで初めてはっきり理解した。ファイルとして配られているものは自分の箱に置ける。APIとしてしか出ていないものは、いくら興味を持っても、呼び出す側にしかなれない。
Jevは見送ることにした。そして見送った理由を考えているうちに、自分が本当にやりたかったことに気づいた。Jevそのものが欲しかったわけではない。ラボそのものにAIを住まわせたい、というのが本当の欲求だった。これまで常駐させていたAIアシスタントは、遠くのクラウドに置かれた頭脳を、ラボの箱を経由して呼び出しているだけだった。窓口はラボにあっても、考えている場所はよそにある。それを、箱の中に閉じた頭脳に変えてみたくなった。
候補を洗い直す
ラボのミニPCはメモリ8GB、GPU（描画専用チップ）は載っていない。CPUだけで動かせる小型のAIという条件で、候補を洗い直した。日本語で会話できること、8GBの中に収まることが絶対条件だった。
たどり着いたのが、Liquid AI社の LFM2.5-2.6B というモデルだった。2026年8月に公開されたばかりの小型モデルで、2.5GB未満のメモリで動くとうたわれている。日本語にも対応していて、答えを出す前に必ず「考える」部分を文章として出してくれる作りになっているらしい。調べた候補のうち、AIの頭脳そのものと言えるものはこれ一つだった。
選ぶ基準になったのは、モデルの賢さそのものより「軽くする加工」がどれだけ効いているかだった。AIの本体ファイルは、そのままではとても大きく重い。中身を粗く丸めて軽くする「量子化」という加工を施すことで、GPUなしのCPUでも動く大きさまで縮められる。今回使うファイルも、この加工を経たものだった。
手順書は書かせて、検証は使い捨ての場所でやらせる
やることが決まったら、手順書をAIアシスタントに書かせた。ただ今回は、その手順を自分がいきなり打つのではなく、同じミニPCの中に使い捨ての作業場所を作り、別のAIに最初から最後まで実行させて通ることを確かめてから、終わったらその場所ごと跡形もなく消す、という一段階を挟んだ。
これが早速効いた。1回目の検証で1か所落ちたのだ。モデルの本体ファイルはHugging Faceというモデル配布サイトに置かれている。Ollama（ローカルAIの管理ソフト）には配布サイトから直接モデルを取ってくる機能があるのだが、いま使っている最新版（0.34.2）でこれを試すと、「転送先が別のホストに切り替わる」という理由で遮断されて失敗する。安全のための仕組みが働きすぎているらしく、直す作業が進んでいるところだという。
回避策は単純だった。モデルファイル(1.67GB)をcurlで普通にダウンロードしてきて、それをOllamaに登録し直す。この1か所さえ避ければ、あとの手順は素直に通ることが、検証で先に分かっていた。自分が実際に打つときには、この落とし穴はもう存在しなかった。
思えば前回、無人のAIが確認画面の前で永久に止まってしまったことがあった。あのときの教訓は「判断を後回しにする猶予を残さない」だった。今回の「先に別のAIに通させておく」というやり方も、根っこは同じだと思う。自分が現場に立つ前に、迷いどころを先回りしてつぶしておく。
建てたもの、そして実際にやった夜
構成はシンプルにした。Ollamaをひとつの箱としてDockerで動かす。守ることは三つ。外に出さない（待ち受けるドアはミニPC自身からしか触れない設定にした）。既存に触らない（仕事用のテスト環境や、いま動いている8つのサービスには一切触らない）。消せる形で建てる(全部を~/ollama/という専用フォルダに収めた)。
作業をやったのは9月19日の夜だった。ダウンロードに数分、全体でも30分ほどで終わった。手順書にはステップが6つあって、すべて順番に通過した。今回は検証を一度挟んでいるせいか、詰まって引き返す場面はなかった。
最後、対話を試せる場面がきて、日本語で最初の質問を打ってみた。
> 自宅サーバーを持つ利点を日本語で3つ、短い箇条書きで。
しばらく待つと、答えが返ってきた。「コスト削減：クラウドストレージや通信費を節約できる。／プライバシー保護：個人データを自家用で管理し、外部サービスへの依存を減らせる。／高速通信：インターネット遅延がなく、ダウンロードやゲームがスムーズに利用できる。」1つ目と2つ目はまったくその通りだと思えたが、3つ目は自宅サーバーの利点としては正直ちょっとずれている。自宅にサーバーを置いたからといって、自分の家のインターネット回線自体が速くなるわけではない。ここに、小型モデルの限界がそのまま出ていた。
それでも、うれしかったのは事実だ。自分の家に置いた、8GBしかない小さな箱が、日本語で、意味の通る文章を返してきた。
数字で見た様子
速さは13.7トークン/秒。ChatGPTのようにサラサラと流れてくる感じではなく、少し待ちながら読む、という速さだった。答えている最中のメモリ使用量は約1.8GB、空きは3.6GB残っていた。同居している仕事用のテスト環境への影響は見られなかった。箱を作り直しても、モデルはちゃんと元通りに立ち上がってきた。
メモリの見方をひとつ覚えた
作業中、一度ちょっと焦った場面があった。freeコマンドを打つと、「free」という項目の数字がやけに少なく見えたのだ。調べると、見るべきは「free」ではなく「available」という別の項目だった。Linuxは空いているメモリをキャッシュとして裏で溜め込んでおく性質があるらしい。必要になればすぐに手放されて使える分に戻る。「free」が少ないのは危険信号ではなく、ただ有効活用されているだけ、ということだった。
分かったこと
今回、大きく分けて三つのことが分かった。一つは、「載せられるかどうか」はAIの賢さではなく提供形態で決まるということ。もう一つは、手順書を「書くAI」と「検証するAI」に分けることの効果。自分がキーボードを打つ前に、別のAIが同じ手順を一度最後まで通してくれていたおかげで、詰まる場所がなかった。三つ目は、答えの質そのものについて。小さなモデルは、速さやメモリのやさしさと引き換えに、時々ずれた答えを返す。完璧な答えを求めるものではなく、「自分の家の中だけで完結する、多少粗くても構わない頭脳」として付き合っていくものらしい。
次に繋がる話
この箱にはまだ、やれることが残っている。以前作った、Discordの窓口の応答役をこのローカルなAIに任せてみること。自分の資料を読ませて、それをもとに答えさせる仕組み（ローカルRAGと呼ぶらしい）を作ってみること。そして、メインの作業用パソコンで動いているAIアシスタントから、この箱の頭脳を道具として呼び出せるようにすること。
どれから手をつけるかは、まだ決めていない。ただ、これまでは「窓口はラボにあるが、考えている場所はよそにある」状態だったのが、今回で初めて「考える場所そのものがラボの中にある」状態になった。次回は、このどれかを実際に動かしてみた話になると思う。