このシリーズは第1回から、そのとき作ったもの・そのとき壊れたものを一話ずつ書いてきた。気づけば53回ぶんの記事が積み上がっている。
その一方で、「で、結局これは何なのか」を一度も書いていないことに気づいた。新しく読みに来た人からすると、53個の技術的な断片がいきなり目の前にある状態である。
そこで今回は、2026年8月時点の全体像を1枚にまとめる。以後の回はここから枝分かれする、地図としての記事にしたい。
1. これは何か ── 自宅のPCを「1つのAI」として使う基盤
一言でいうと、自宅にある複数のPC・ローカルLLM・Web検索・自分のドキュメント・サーバ管理を、まとめて1つのAIとして使うための基盤である。
使う側は、どのPCでどのモデルを動かすかを意識しない。チャット画面に日本語で書くだけだ。裏側で何が起きるかは、質問のほうが決める。
| こう聞くと | 裏側はこうなる |
|---|---|
| 「PythonでCSVを処理するコードを書いて」 | コードが得意なモデルを選び、そのモデルを持っていて空いているマシンで実行する |
| 「昨日の○○のニュースを教えて」 | 最新情報が要ると判定し、自前のWeb検索エンジンで調べてから答える |
| 「以前決めたサーバ構成を教えて」 | 自分のブログ記事と運用ドキュメントをベクトル検索して、そこから答える |
| 「marsのディスク空きを見て」 | LLMに想像させず、実際にそのサーバを見に行って結果を返す |
つまり、毎回同じAIに聞いているのではない。質問に合った処理のしかたを、その場で選んでいる。
質問
│
▼
┌────────────────┐
│ Coordinator │ ← 何をどこで処理するか決める（自作）
└───────┬────────┘
│
┌─────────┬───────┼────────┬──────────────┐
▼ ▼ ▼ ▼ ▼
ローカルLLM Web検索 RAG サーバ管理 Claude Code
│ （読み取り／承認制）
├──────┬─────────┐
▼ ▼ ▼
GPU機 M1 Mac 予備機ここで一番大事なのは、「一番強いAIに常に投げる」設計ではないことだ。設計思想を一行にするとこうなる。
「最強モデル固定」ではなく、「タスク特性 × 実績 × 現在負荷」で最適モデルを選択する。
コードなのか日本語要約なのか。過去にどのモデルがどの分野で速くて良い答えを返したか。いま各マシンはどれくらい混んでいて、そもそも電源が入っているか。それらを見て、中心にいる Coordinator（自作のルータ兼スケジューラ）が振り分ける。
前提: これはChatGPTを超えるAIを作るプロジェクトではない
先に限界を書いておく。ClaudeやChatGPTのようなフロンティアモデルそのものを作る話ではないし、素の賢さで張り合うのも目的ではない。金額的にもサーバ規模的にも勝てないし、追いつこうとした瞬間に設計判断が全部おかしくなる。
作っているのはモデルそのものではなく、モデルを部品として使う実行基盤のほうだ。前提はこうである。
- 「最強のAI環境」ではなく「自分で理解・制御できる実用的なAI環境」を目指す
- 小〜中モデル（8Bクラス）が得意な領域 ── 要約・分類・翻訳・定型コード・簡単なQA ── で実用性を最大化する
- RAG／Web検索／サーバ管理のように、素のモデル性能とは別軸の価値を足す
- 完全ローカルであること自体が価値（プライバシー・従量課金なし・全部いじれる）
そしてここは個人の実験・学習の場だ。利用者は私1人、頻度も低い。だから「コストのために」「スループットのために」という理由で複雑にするのは、大抵やりすぎになる。「作っていて面白いから作る」が正当な判断基準として認められている場所である。
2. できること
いま実際にできるのは、この6つだ。
① 普通に質問する
ローカルLLMが答える。どのモデルをどのマシンで動かすかは基盤が決める。クラウドに何も出て行かない。
② 最新情報を聞く
自前のWeb検索エンジン（SearXNG）で検索してから答える。「これは最新情報が要る質問だ」の判定は自動で、こちらから「検索して」と言う必要がない。
③ 自分の資料について聞く
これまで書いたブログ全記事と、自分の運用ドキュメントをベクトル化してある。「あのとき何を決めたんだっけ」に、出典つきで答えが返る。
④ サーバの状態を調べる
「marsのディスク空きを見て」と書くと、実際にそのサーバでコマンドが動いて、その出力が返ってくる。LLMが想像で答えることはない。実行できるのは、あらかじめ登録した定型コマンドだけである。
⑤ サーバを変更する（承認制）
サービス再起動やパッケージ更新のような書き込みは、AIの判断だけでは絶対に走らない。提案として積まれ、スマホに通知が飛び、私が承認して初めて実行される。
⑥ 長い仕事を投げておく
質問を分解して並列処理し、統合して返すパイプラインがある。処理は非同期なので、投げてブラウザを閉じてもよく、終わったらスマホのチャットに通知が来る。
3. どこから使うのか
上の6つは、3つの窓口から利用できる（＋開発用に直接叩く口）。
窓口①: OpenWebUI のモデルセレクタ（メイン）
普段はブラウザのチャット画面から使う。モデルセレクタには、Ollamaの生モデルとは別に「擬似モデル」が6つ並んでいて、選ぶだけで裏の経路が丸ごと切り替わる。
| 書き方 | 行き先 |
|---|---|
質問 明日の天気を教えて |
通常のAI推論（Web検索やRAGの自動判定込み） |
管理 marsのディスク空きを見て |
サーバ管理（読み取り専用） |
クロード この構成の問題点は |
Claude Code ワーカーを指名 |
推論もサーバ管理も投げてから数十秒かかるので、投げた瞬間に受付だけ返し、終わったら改めて結果を書き込む2段階の作りにしてある。判定は「先頭の語が一致するか」だけで、「これはAIへの質問か」をLLMに判断させてはいない。決定論で足りるところにLLMを置かないのは、この基盤の一貫した方針だ。
この口は差出人の許可リストを通った人しか使えない（未設定なら誰も使えない側に倒してある）。許可外の人が何を書いても一切反応しない ── コマンドを受け付けるルームであること自体を教えないためである。
窓口③: 承認
書き込み操作の通知はスマホに飛んでくる。承認の書き方はこうだ。
承認 plan_xxxxxxxxxxxxこのIDの転記が必須で、「さっきのやつを承認したいんだな」とLLMに推論させない。正規表現の完全一致だけが承認として通る。
（開発用）HTTP API
# いまどのマシンが登録されているか
curl http://ai-core:8000/workers
# この質問をどこへ振るつもりか（実行せずに見るだけ）
curl -sG http://ai-core:8000/route/preview --data-urlencode "prompt=Pythonでソートを実装して"地味だが重要なのが /route/preview で、「なぜそのマシンを選んだのか」の内訳（速度・ドメイン適性・混雑度・品質の4項）を返す。総合点しか見ていなかった時期に2ヶ月ぶんの事故を見逃したので、外から内訳を覗けるようにした（第53回）。
4. 裏で何が起きているか
あなた（OpenWebUI / Nextcloud Talk）
↓ POST /route
【Coordinator API（ai-core）】
├─ ドメイン分類（キーワード → 軽量LLM で code / general / japanese）
├─ Web検索判定（最新情報が要るか）
├─ 会話メモリ検索（過去の文脈があれば差し込む）
├─ スコアリング（速度 0.25 + ドメイン適性 0.15 + 混雑度 0.25 + 品質 0.35）
├─ 能力フィルタ（そのマシンがそのモデルを持っているか）
└─ 自己修復スレッド（応答しないマシンのタスクを別へ戻す）
↓ タスクをキューへ
【Redis】
↓ 各ワーカーが自分宛のキューから取る
【ワーカー（M1 Mac / GPU機 / …）】
↓ 二重実行防止のクレーム → Ollama で推論
【PostgreSQL】（結果・実績・統計）
↓
チャット画面に表示要点は3つ。
① 非同期である。 チャット画面とワーカーは直接つながっていない。タスクはRedisのキュー、結果はPostgreSQL。だから途中でブラウザを閉じても処理は続くし、完了はスマホに通知できる。
② 実績が貯まって、選び方が変わる。 処理のたびに「どのモデルが、どのドメインで、何ミリ秒で、どんな品質だったか」がPostgreSQLに残る。品質のほうは毎晩バッチが別のLLMに採点させている（LLM-as-judge）。その統計が翌日のルーティングを変える。
念のため書いておくと、これはモデル自体を学習させているのではない。賢くなっているのはモデルではなく「どれを選ぶか」の判断材料のほうで、中身は運用実績の集計である。
③ 壊れても止まらないようにしてある。 ワーカーが死ぬ、応答しなくなる、登録は残っているのに実は仕事を取っていない（これが一番タチが悪い）── いずれも検出して別のマシンへ投げ直す。Web検索が0件だったときはローカルLLMの直答＋注記に落とす。「回答ゼロ」で終わらせないことを最優先している。
5. 実体 ── 動いている8台
ここまでが概念で、これが実物である。役割を分けて、それぞれが得意なことだけをやっている。
全記事まとめにある。
ルーティングと分散
- 実績ベースの動的ルーティング（速度・ドメイン適性・混雑度・品質の4項スコア）（第3回・第12回）
- ドメイン自動分類（キーワード → 軽量LLM で code / general / japanese を判定）（第4回）
- マシン別キューと能力ベース振り分け（GPU必須のモデルはGPU枠へ。GPU機が落ちていればCPU枠へ動的に落とす）（第7回・第21回）
- 共有キューによる引き取り型の分散（速いマシンが自然に多く引き受ける）（第53回）
- 全モデル一括ベンチと夜間の品質採点で実績を貯める（第12回・第33回）
止めない仕組み
- 自己修復: 死亡・ゾンビ・「登録はあるが仕事を取っていない」の3パターンを検出して別マシンへ再投入（第10回・第14回・第17回）
- Wake-on-LAN 指名起動: 寝ているマシンを指名すると起こして、起動を待ってから処理（第11回）
- アイドル自動停止: 使い終わって一定時間経ったマシンは自分で登録を消して落ちる（第11回）
- 日次バックアップと復元検証: PostgreSQLを毎晩marsへ7世代。本番に触らず、実際に復元できるかまで試す（第30回）
- ノード死活通知: 8台全部を60秒間隔で見て、落ちたらスマホへ
素のLLMにできないことを足す
- Web検索: 自前のSearXNGで検索してLLMが要約。「最新情報が要る質問」は自動でこちらへ回る（第8回・第9回）
- RAG: ブログ全記事と運用ドキュメントをベクトル化して検索。見出し境界を尊重した意味チャンク分割まで作り込んである（第15回・第22回・第23回）
- 会話メモリ: 会話から「覚える価値のあること」だけを抽出して蓄積し、次の質問のときに関連するものだけ差し込む（第25回〜第29回）
- 処理分割パイプライン: 大きな質問を分解 → 並列実行 → 統合（第32回）
サーバ管理をAIにやらせる
- 自然文でのサーバ診断: 計画を組む → カタログに載っている定型コマンドだけを実行 → 結果を報告（第40回・第41回・第43回）
- 三重の防壁: AIにシェルを渡さない（許可リストにあるコマンドしか世界に存在しない）／既定は全部拒否／計画を立てるのは一度だけ（第40回）
- 書き込みは承認制（第42回）
- 定期実行: 「毎週月曜の深夜1時に」のような予約ができる。ただし予約時に立てた計画を保存し、実行時にはLLMを呼ばない（第50回）
- 監視の監視: 実行役が無音で止まる事故が実際に3回あったので、それを検出する見張りを別に立てた（第46回・第47回）
Claude Code をワーカーにする
- 基盤の一員としての Claude Code: ローカルLLMと同じキューを見て、指名されたら答える（第51回）
- 読み取り専用の診断レーン: シェルもSSH鍵も渡さず、カタログ経由でしかサーバに触れない
- 書き込み提案レーン: 実行はせず、承認待ちとして積むだけ。人向けに緩めた設定が、無人の経路へ波及しないことを実機で確認済み
- 長期記憶RAG: セッションをまたいで「決まったこと」を引ける（第52回）
基盤自体の管理
- 設定とソースのGitLab集約: 各ノードの実体ファイルを自己ホストGitLabへ引き上げる。秘密情報のスキャン付き（第48回）
- 設計書と決定記録による開発: 引き継ぎ資料が1.36MBまで肥大化して機能しなくなった反省から、いまの形になっている（第49回）
7. 数字で見る現在地
このシリーズは「計測してから信じる」を規律にしているので、現状も数字で置いておく。
| 項目 | 実測値 |
|---|---|
| ノード数 | 8台（うち常時稼働7台・GPU機は不定期） |
| 汎用推論の土台 | 8Bモデル 2種 |
| 同じモデル（qwen3:8b）の速度差 | GPU機 0.77秒（83 tok/s）／M1 5.61秒（11.4 tok/s）＝7.3倍 |
| RAGコレクション | ブログ記事 163点／運用ドキュメント 90点 |
| ルーティングの重み | 速度 0.25／ドメイン適性 0.15／混雑度 0.25／品質 0.35 |
| Claude Code の診断1回 | 12アクション・2ノード横断・88秒・$0.234 |
| 並列パイプラインの実測 | 子3本が GPU機2本・M1 1本へ自然分散（17.3秒／29.8秒／35.4秒） |
8. できないこと・割り切っていること
ここを書かない紹介記事は信用しないことにしているので、自分の基盤についても書く。
- モデルは8Bまで。 12B・14Bも動くが実用速度に乗らない。難しい質問はフロンティアモデルの仕事で、そこは張り合わない
- 並列の上限は実質2。 汎用推論を実際に消費しているマシンが2台しかないからだ。「4本並列にならない」と2ヶ月言い続けながら、並列の分母を一度も数えていなかったという間抜けな発見が先週あった（第53回）
- Web検索とRAGは単一障害点。 各1台ずつで、自己修復の対象外。そのマシンが落ちるとその機能は止まる
- スマホからの問い合わせは1問1答。 会話の文脈を持たない。「さっきの件だけど」は通じない
- スマホからのサーバ管理は読み取り専用。 書き込みをやりたければ、承認フローに乗せる設計が別途要る
- 範囲の広い指示は弱い。 「サーバの状況を教えて」だと計画が長くなりすぎて却下されることがある。「marsのディスク空きを見て」のようにノードを指定するほうが速いし通る
- 設計書と実機は恒常的にズレる。 1セッションで4件ズレが出た日もある。しかもズレる方向は一定しない（記録が古いこともあれば、記録のほうが悲観的なこともある）。だから「設計書の前提に依存する実装を始める前に、その前提を実機で1回確かめる」という規律で運用している
- cronがGitの管理外。 これが原因で、統計更新のバッチが2ヶ月凍っていたのに誰も気づかなかった。バッチの健全性は「動いているか」ではなく「出力が新しいか」で見るべきという教訓つきの、未解決の宿題である
9. これから
- 速さと信頼度の折り合い。 統計にマシン単位の次元を足したら、集計の粒度が細かくなったぶんサンプル数がリセットされ、最速のマシンが即座に勝つわけではなくなった。ここの調整が残っている
- バッチの「無言の死」を検知する。 稼働ではなく出力の鮮度を見て通知へ流す。承認待ちリマインドと同じ形で足せるはずだ
- レトロPCから使う。 Windows 95、漢字Talk、PC-98からこの基盤へ問い合わせられるようにしたい。古いHTTPしか喋れない機械のためのプロキシを間に立てる構想で、スマホの「質問」レーンはその第一歩 ── というのは後付けで、実際は面白そうだから作った
最後の項目が、この基盤の性格をよく表していると思う。コスト最適でも高可用でもなく、自分で理解して制御できる範囲を広げていくのが目的だ。53回ぶんの失敗のほとんどは、そうやって広げた先で踏んだものだった。
次回からはまた個別の話に戻る。この記事は、状態が大きく変わったら書き直すつもりでいる。