押し入れや引き出しの奥に、かつてメインマシンとして活躍したノートPCが眠っていませんか？
数年前に購入したモバイルノート**「Dell Inspiron 13 7300」**。
第11世代 Intel Core i7-1165G7、メモリ16GB。普段使いには十分なスペックですが、持ち歩きに便利な軽いノートPCを購入したため、出番がなくなっていました。
このまま眠らせるのはもったいないので、自分の物理基盤の理解とサーバ構築の勉強に当てよう！
そう思い立って帰りに静電気防止手袋を購入し、スタートしました。
結果として、ディスプレイを閉じたまま棚の隅で静かに稼働し、同一Wi-Fi内のPCやスマホから「Open WebUI」で最新LLM（Gemma 4）と思考プロセス付きで対話でき、さらに「FastSD CPU (OpenVINO)」によってGPUなしでも数秒で美麗なイラストを生成できるプライベートAIサーバが完成しました！
構成はこんな感じです：
※ 普段の技術検証メモや文書管理にNotebookLMを活用しており、今回のシステム構成図もNotebookLM上で整理・出力したもの（右下にGemini Notebookのロゴが入っています）を使用しています。
本記事では、ハードウェアの分解観察から、Ubuntuインストーラーの洗礼、OllamaとDockerの連携トラブル、そしてFastSD CPUで初回の画像生成に成功するまでの全工程とリアルな試行錯誤を余すところなくお届けします！
目次
- マシン紹介とハードウェア分解・基板探検
- Ubuntu Server 24.04 LTS導入とインストーラーの洗礼
- クラムシェルモード化：蓋を閉じても眠らない常時稼働サーバへ
- Ollama導入：Tiger LakeのAVX-512で最新「Gemma 4」が唸る
- DockerでOpen WebUI構築：ホスト接続の壁を越えて私設ChatGPT化
- 画像生成への挑戦①：Open WebUI連携の壁、num_ctx調整、そしてCPU単体「7秒のcat.png」
- 画像生成への挑戦②：FastSD CPU (OpenVINO) 導入と未来都市の初生成
- まとめ：分解からAIサーバ化までやり切って見えたもの
1. マシン紹介とハードウェア分解・基板探検
今回ベースにしたマシンは、Dellの薄型モバイルノート「Inspiron 13 7300」です。
- CPU: Intel Core i7-1165G7 (4コア/8スレッド, 最大4.7GHz, AVX-512対応)
- RAM: 16GB LPDDR4X
- GPU: Intel Iris Xe Graphics + NVIDIA GeForce MX350 (2GB)
- SSD: NVMe M.2 SSD
スペック的には、NVIDIA MX350のVRAMが2GBしかないため「GPU推論」には向きませんが、第11世代Core i7のCPUパワー（AVX-512）とIris Xe内蔵GPUを活用すれば、CPU/OpenVINOベースのローカルAI環境として十分なポテンシャルを秘めています。
精密ドライバーで裏蓋を開け、内部を観察する
まずは安全第一で作業を進めます。
[分解・基板観察のハイライト]
1. バッテリーコネクタの切り離し: ショート事故防止のため、最初にバッテリーの配線を抜く。
2. オンボードメモリの確認: メモリチップがマザーボードに直付け（BGA）。増設不可のモバイル設計。
3. SSDスロットの柔軟性: 装着されていたのは短いM.2 2230サイズだが、金属ブラケットを外せば一般的な2280サイズにも換装可能。
4. 電源回路（VRM）の観察: CPU周辺に「R15」「R22」「1R5」と刻印されたパワーインダクタやMOSFETが整然と並び、19Vのアダプタ電圧をCPU用の約1Vへ降圧する仕組みを実感。
5. 冷却機構: 1基のシロッコファンと、CPU・dGPUを跨ぐ1本の銅製ヒートパイプ。
初めてちゃんと見ました…！
ヒートシンク周りのホコリをエアダスターで慎重に吹き飛ばし、ファンを清掃。
どれがどれかわからないので、AIに聞きながら理解を進め、SSDの増強は可能だが、メモリはオンボードのため、増設できないことを知ることができました。
CPUはグリスを買っていなかったので、今回は確認することは見送りました。
組み戻した後は、Dell純正のハードウェア診断機能**「SupportAssist On-board Diagnostics」**を走らせ、メモリ（WCMchテスト）やファン、SSDがすべてPass（正常）であることを確認しました。
自分の手で中身を確認し、構造を理解したマシンは、それだけで愛着が何倍にも湧いてきます。
2. Ubuntu Server 24.04 LTS導入とインストーラーの洗礼
GUI（デスクトップ画面）があると貴重な16GBメモリを無駄に食ってしまうため、OSは画面のない軽量な Ubuntu Server 24.04 LTS を選択しました。
Windows機でRufusを使ってUbuntuインストーラーUSBを作成し、いざノートPCへ挿して起動！……したのですが、さっそく2つの壁にぶつかりました。
ハマりどころ①：F12ブートメニューが反応しない？
電源を入れてF12を連打しても起動メニューが出ず、診断ツールやWindowsが立ち上がってしまいます。Fn キーを押しながら F12 を連打することも試しましたが、なぜかうまくいかず……（原因不明）。
解決策: F2 キーでBIOS Setup画面には遷移できることが確認できていたため、BIOS内の「Boot Configuration（起動順序）」でUSBメモリを一番上に変更し、強制的にインストーラーから起動させました。
ハマりどころ②：インストーラーでWi-Fiが繋がらない！からのNetplan手動設定
本体にLANポートがないため、インストーラー画面で内蔵Wi-Fi（Intel AX201）を設定しようとしました。しかし、SSIDを選んでパスワードを入れても DHCPv4 が「-」のままでIPが取得できず、しまいにはスキャンエラー（error triggering scan failed）で固まってしまう事態に。スマホのUSBテザリングもインストーラー上ではうまくIPを掴んでくれません。
画面の前で粘るのをやめ、「一旦ネットワーク設定をスキップ（Continue without network）して、OSインストールを先に終わらせる」 という判断をしました。まずはOSを立ち上げ、後から設定ファイルを手動で修正して繋ぐ作戦です。
無事にインストールが完了し、PC本体のキーボードからCUIへログイン！
ここからネットワークを手動で開通させるための戦いが始まりました。
1. インストーラーの残骸との競合（match: エラー）
手動で /etc/netplan/50-network.yaml を作成して適用しようとしたところ、networkd backend does not support wifi with match: というエラーが発生。
調べてみると、OSインストール時に中途半端にWi-Fiを設定しようとしたせいで、自動生成された 00-installer-config.yaml が裏に残っていました。その中に書かれていた match: macaddress（MACアドレス指定構文）をUbuntu 24.04の標準バックエンドが拒否し、Netplan全体の適用をストップさせていたのです。
不要になったインストーラー側の設定ファイルを削除（または拡張子を変えて退避）することで競合を解消しました。
2. Netplan設定ファイルの作成
/etc/netplan/50-network.yaml を以下のように新規作成しました：
network:
version: 2
renderer: networkd
wifis:
wlp0s20f3: # ip a で確認したWi-Fiインターフェース名
dhcp4: true
access-points:
"Buffalo-5G-5BC0":
password: "Wi-Fiパスワード"
3. 魔の1文字「5Bc0」vs「5BC0」
構文エラーは消えたのに、まだIPを取得しない。ログを見ても「接続要求すら出していない」状態。
設定を穴が空くほど見つめ直した結果、ルーター本体のシールに書かれていた実際のSSIDは Buffalo-5G-5BC0（Cが大文字）なのに、設定ファイル側で 5Bc0（小文字のc）と打ち間違えていたことを発見！
LinuxのWi-Fi規格はSSIDの大文字・小文字を厳密に区別するため、「そんな電波は周囲に飛んでいない」と判定されてスルーされていたのでした。
大文字の C に直して sudo netplan apply を叩いた瞬間、画面に IPアドレスが…！
無事にネットが開通し、コードエラー修正を久々に思い出しました。
3. クラムシェルモード化：蓋を閉じても眠らない常時稼働サーバへ
Ubuntu Serverがインストールできたら、まずはノートPC特有の設定を行います。
部屋の棚の隅に「画面を閉じたまま（クラムシェル状態）」で静かに置いておきたいのですが、デフォルトでは**天板を閉じるとスリープ（サスペンド）**してSSHが切断されてしまいます。
/etc/systemd/logind.conf を編集し、蓋閉じ時の動作を無視（ignore）させます：
sudo sed -i 's/^#\?HandleLidSwitch=.*/HandleLidSwitch=ignore/; s/^#\?HandleLidSwitchExternalPower=.*/HandleLidSwitchExternalPower=ignore/' /etc/systemd/logind.conf
sudo systemctl restart systemd-logind
さらに ip a で割り当てられたIPアドレスを確認。
手元のWindows PCからPowerShellを開き、SSH接続テストを行います：
ssh nicqo@192.168.2.xxx
パスワードを入力してEnter……繋がった！！
これでノートPCの画面やキーボードを開く必要はもうありません。完全にヘッドレスな省スペースサーバの誕生です。
4. Ollama導入：Tiger LakeのAVX-512で最新「Gemma 4」が唸る
いよいよローカルLLMの導入です。軽量・手軽にLLMを動かせるデファクトスタンダード、Ollama をインストールします。
curl -fsSL https://ollama.com/install.sh | sh
最新モデル「Gemma 4」を動かしてみる
Googleが公開した最新推論モデル Gemma 4（ノートPCに最適な e4b バリアント）を起動します：
ollama run gemma4:e4b
モデルのダウンロードが完了すると、ターミナルに >>> プロンプトが出現。日本語で質問を投げかけてみます。
画面には done thinking. と表示され、AIが思考プロセスを巡らせた後、非常に滑らかで自然な日本語が返ってきました！
第11世代Core i7-1165G7は AVX-512 命令に対応しているため、GPUなしのCPU推論とは思えないほどキビキビと文字が生成されます。 もちろん普通のGeminiやClaudeなどに比べては時間はかかります。ローカル環境で収まるただのロマンです。
5. DockerでOpen WebUI構築：ホスト接続の壁を越えて私設ChatGPT化
CLIの黒い画面だけでなく、ブラウザからChatGPTのように使えるリッチなUI環境 Open WebUI をDockerコンテナで立ち上げます。
# Docker のインストール
curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker $USER
newgrp docker
# Open WebUI コンテナの起動
docker run -d -p 3000:8080 \
--add-host=host.docker.internal:host-gateway \
-v open-webui:/app/backend/data \
--name open-webui \
--restart always \
ghcr.io/open-webui/open-webui:main
ハマりどころ：DockerからホストのOllamaが見えない！
コンテナ起動後、ブラウザから http://192.168.2.xxx:3000 を開いてアカウントを作成。
しかし、管理画面の「Ollama API」接続設定で http://host.docker.internal:11434 を指定しても、以下のエラーで弾かれてしまいます。
Ollama: Cannot connect to host host.docker.internal:11434 [Connect call failed ('172.17.0.1', 11434)]
原因: Ollamaはセキュリティのため、デフォルトでは 127.0.0.1（ローカルホスト自身）からのアクセスしか受け付けません。Dockerのブリッジネットワーク（172.17.0.1）からの通信をOllama自身が拒否していたのです。
解決策: systemdのoverride設定を作成し、全インターフェース（0.0.0.0）からの接続を許可します。
sudo mkdir -p /etc/systemd/system/ollama.service.d
echo -e '[Service]\nEnvironment="OLLAMA_HOST=0.0.0.0"' | sudo tee /etc/systemd/system/ollama.service.d/override.conf
sudo systemctl daemon-reload
sudo systemctl restart ollama
Open WebUI側で接続テストを再実行すると、見事に緑色のチェックマークが点灯！
モデル選択に先ほどの gemma4:e4b が自動で現れ、PCやスマホからもブラウザ1つで利用できる完全ローカル・プライベートなChatGPT環境が手に入りました。
6. 画像生成への挑戦①：Open WebUI連携の壁、num_ctx調整、そしてCPU単体「7秒のcat.png」
テキスト対話ができるようになったら、次は「画像生成」もこのサーバにやらせてみたくなります。
最初の試み：Open WebUIの画像生成機能との連携
Open WebUIにはAUTOMATIC1111等のAPIと連携して画像を生成する機能があります。
そこで、Pythonの diffusers と FastAPI を使い、超軽量な高速モデル SD-Turbo を動かすAUTOMATIC1111互換のAPIサーバ（ポート7860）を自作して連携を試みました。
しかしここで壁にぶつかります。Open WebUIとAPIサーバの接続（200 OK）は成功したものの、チャット欄で「画像を描いて」と頼むと、Gemma 4が「私は文章用AIなので画像を生成できません」と断ってしまい、画像が一切出力されません。
ハマりどころ①：「画像プロンプト生成」の罠と、立ちはだかるWebUI連携の壁
原因を調べると、Open WebUIの**「画像プロンプト生成（Image Prompt Generation）」**が原因の一つでした。
デフォルトでは、ユーザーが入力した文章をまずLLM（Gemma 4）に渡して画像用の英語プロンプトに変換させようとする仕様になっています。しかしGemma 4のセーフティガードレールが「自分は画像生成モデルではない」と過剰に反応し、リクエスト自体をキャンセルしてしまっていたのです。
そこで、管理者パネルの「設定」→「画像」を開き、「画像プロンプト生成」のトグルスイッチのチェックを外してOFFに変更！
これで直接画像APIにリクエストが飛ぶはず……と期待したのですが、それでもチャット画面から画像は出力されませんでした。
思考ログをよく見ると、Open WebUI側は画像サーバを認識しているものの、Gemma 4自身が「自分にはタスクやカレンダーのツールしか与えられておらず、画像を生成するツールは使えない」と判断してしまっており、チャット内でのツール連携（Function Calling）の壁に阻まれてしまったのです。
なぜOpen WebUIで画像生成ができなかったのか？
LLM（Gemma 4）側の仕様が主な原因です。
Gemma 4はテキストおよびマルチモーダル（画像や動画の入力・理解）には対応していますが、画像を新しく生成・出力する機能はありません。そのため、モデル自身が「画像を生成できない」と判断し、テキストでその旨を返答してしまいます。
また、Open WebUIの仕様として、チャット画面から画像を出力させるには、LLMとは別に画像生成AI（Stable Diffusion、ComfyUI、DALL-Eなど）のバックエンド連携をOpen WebUI側で設定する必要があります。単にLLMのAPIサーバと接続（200 OK）しただけでは、テキストのやり取りしか行えません。
ハマりどころ②：会話肥大による4096トークン制限と num_ctx の拡張
さらにプロンプトの調整や対話を重ねていると、今度は別のエラーが発生しました：
{"error":{"code":400,"message":"request (6611 tokens) exceeds the available context size (4096 tokens), try increasing it"}}
原因: Ollamaのデフォルトコンテキスト長（num_ctx）が省メモリのために4096トークンに制限されており、試行錯誤のチャット履歴が積み重なって上限を突破してしまったのです。
解決策: Open WebUIの「ワークスペース」→「モデル」から gemma4:latest の設定を開き、高度なパラメータにある num_ctx (Ollama) を 8192 に拡張！
これで会話上限エラーは綺麗に解消されましたが、肝心の「Open WebUIチャット内での画像生成」は依然として成功しないままでした。
原点回帰：このノートPCは実際に何秒で絵を描けるのか？
「Open WebUIの複雑なツール連携でこれ以上悩むより、そもそもこのノートPCのCore i7だけで、実際に何秒で画像が作れるのか？ を直接確かめよう！」
そう思い直し、UIを介さずにPythonのワンライナーで直接生成テストを走らせてみました：
import torch
from diffusers import AutoPipelineForText2Image
pipe = AutoPipelineForText2Image.from_pretrained("stabilityai/sd-turbo", torch_dtype=torch.float32).to("cpu")
image = pipe("a cute cat wearing sunglasses on a beach", num_inference_steps=2, guidance_scale=0.0).images[0]
image.save("cat.png")
コマンドを叩くと、ターミナルのプログレスバーが勢いよく進みます。
100%|████████████████████████████████████████| 2/2 [00:07<00:00, 3.76s/it]
生成完了！ cat.png に保存されました！
「えっ！？ たった7秒！？」
python3 -m http.server 8000 で簡易Webサーバを立て、ブラウザから http://192.168.2.xxx:8000/cat.png を開くと、そこにはサングラスをかけてビーチでくつろぐ鮮明で可愛い猫の姿がありました。
GPUを積んでいない薄型ノートPCが、自力で画像生成AIを走らせ切った瞬間でした。
7. 画像生成への挑戦②：FastSD CPU (OpenVINO) 導入と未来都市の初生成
Open WebUIチャット内でのツール連携（Gemma 4を介した画像生成）で悩み続けるよりも、「テキスト対話用（Open WebUI）」と「画像生成専用（FastSD CPU）」でWebUIを分けて運用した方が、メモリ管理もしやすく圧倒的にトラブルが少ないという結論に至りました。
CPU単体でも7秒で絵が出せるポテンシャルが確認できたので、Intel CPUおよび内蔵GPUに最適化された画像生成ツール FastSD CPU を導入することにしました。
cd ~
git clone https://github.com/rupeshs/fastsdcpu.git
cd fastsdcpu
chmod +x install.sh
./install.sh
ここでもLinuxサーバ構築ならではのリアルなエラーが待ち受けていました。
トラブル①：uv command not found
FastSD CPUの最新インストーラーは高速なパッケージマネージャー uv を前提としていました。
→ 公式スクリプト curl -LsSf https://astral.sh/uv/install.sh | sh で uv を導入して解決。
トラブル②：ImportError: libGL.so.1: cannot open shared object file
OpenCVなどの画像処理ライブラリがGUI用グラフィックライブラリを求めてクラッシュ。ヘッドレスなUbuntu Server環境では初期状態で入っていません。
→ sudo apt install -y libgl1 libglib2.0-0 を追加インストールして解決。
トラブル③：127.0.0.1 待ち受けで手元のPCから開けない
起動スクリプトのデフォルトがローカルホスト（127.0.0.1）のため、外部ブラウザからアクセス不可。
→ 起動引数に --listen を付けるか、ui.py の server_name="0.0.0.0" に書き換えて再起動。
ついに開いた専用スタジオ！運命の初生成
ブラウザから http://192.168.2.xxx:7860 を叩くと、画面上部に誇らしげに以下の文字が表示された専用UIがパッと立ち上がりました！
Processor : CPU , 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz
モード選択で、Intel公式の最適化エンジン LCM-OpenVINO を選択。
プロンプトに以下を入力し、期待を込めて [Generate] をクリックします：
a beautiful futuristic city with flying cars, neon lights, highly detailed
数十秒も待たされることなく、あっという間にプログレスバーが駆け抜け、画面中央にネオンの光が反射する繊細で美しいサイバーパンク未来都市のイラストがドカンと表示されました！
思わずPCの前で小さくガッツポーズが出ました。
分解して埃を払い、ファンや吸排気口を綺麗に清掃したあのInspiron 13が、自前のローカルAI工場として完璧に覚醒した瞬間でした。
8. まとめ：分解からAIサーバ化までやり切って見えたもの
古いノートPCの分解から始まった今回の取り組み。
一見すると「ただの型落ちモバイルノート」ですが、実際に中身を理解して適切なソフトウェアを組み合わせることで、驚くほど実用的なプライベートAI母艦に生まれ変わりました。
やってみて分かったこと
- モバイルノートは最高の自宅サーバ素材: 画面・キーボード・バッテリー（停電時のUPS代わり）が全部入りで、消費電力もわずか数W〜30W程度。
- CPU推論（AVX-512 & OpenVINO）の実力: 「AIには高価なNVIDIA GPUが必須」という固定観念を覆すほど、近年の軽量モデル（Gemma 4、LCM、SD-Turbo）と最適化技術は成熟している。
- エラーこそ最高の教材: Fnキーの挙動、WPA3とWi-Fiの相性、Dockerのネットワーク隔離、ヘッドレス環境の共有ライブラリ不足など、実際に手を動かしてぶつかった壁を一つずつ乗り越える過程にこそ技術の面白さがある。
もしあなたの手元にも、使わなくなったノートPCが眠っているなら、ぜひドライバーを手に取って裏蓋を開けてみてください。
自分だけのプライベートAIサーバを育てる最高の冒険が待っています！