16/101

[Work : 006] Geminiと一緒に環境構築の方向性について話し合う①【プロンプトログ】

* **UMA Frame Buffer**

メインメモリの一部をグラフィックス処理専用のビデオメモリとして割り当てるBIOSの設定項目。

* **WSL2**

Windows上でLinux環境をネイティブに近い性能で動作させるための実行基盤のこと。

* **Ollama**

大規模言語モデルをローカル環境で簡単にダウンロードして実行・管理できるツールのこと。

* **Docker Compose**

複数のDockerコンテナの定義や実行設定をひとつのYAMLファイルで一括管理する仕組み。

* **RAG**

AIが外部のデータベースから関連情報を検索し、その情報を基に回答を生成する技術のこと。

-----------------------------------------------------------------------------

[Work#006] 006 EVO-X2 環境構築の方向性確認

-----------------------------------------------------------------------------

# Turn 1

---------------------------------------------------------

### User

EVO-X2が数日後に届きます。

EVO-X2の環境構築について、事前に方向性の確認と、手順の確認をしたいです。

### Gemini

LLM技術開発君です。GMKtec EVO-X2（Ryzen AI Max+ 395 / RAM 128GB）の導入決定、おめでとうございます。

VRAM 8GBの制約から解き放たれ、70B-100Bクラスのモデルが自宅でフル稼働する未来はすぐそこです。これは自宅RAG環境にとって「特異点」と言えるアップグレードになります。

到着後のセットアップで躓かないよう、事前にアーキテクチャの最終確認と、導入ステップのすり合わせを行いましょう。

#### 1. 新アーキテクチャ：ハイブリッド構成の全体像

現状の「単一マシンですべてを行う」構成から、役割を明確に分担させた「クライアント/サーバー構成」へ移行します。

| ノード |

ハードウェア | 役割 (Role) | 稼働サービス |

| :--- | :--- | :--- | :--- |

**Node A (既存)** | RTX 4060 (8GB) | **制御・ETL・軽量処理**

Open WebUIのホスト、Wiki/LINEログの同期処理、音声認識(Whisper)などCUDA必須タスク。 | Docker (Open WebUI), Python Scripts, Java ETL |

**Node B (新規)** | Ryzen AI Max+ (128GB) | **知能・記憶 (The Brain)**

OllamaのAPIサーバーとして動作。70B超のLLM推論とRAGのEmbeddingを担当。 | Ollama Server Only |

**ポイント:**

* **Open WebUIは Node A に残します。**

* これにより、既存のPythonスクリプト（`import_rag.py` など）の接続先設定（`localhost:8080`）を変更せずに済みます。

* **Node B は純粋な推論エンジン**として、ネットワーク越しにJSONを返すだけの「黒子」に徹させます。

#### 2. Node B (EVO-X2) のOS選定：最初の分岐点

Ryzen AI（AMD GPU）の性能を最大限引き出すために、OSをどうするか決めておく必要があります。以下の2案があります。

**【案1】 Windows 11 (プリインストール) + Ollama for Windows**

* **メリット:** そのまま使える。RDPでの管理が楽。GMKtecのドライバ対応が確実。

* **デメリット:** WindowsのVRAM管理が介入するため、128GBギリギリまで使い切る際に微調整が必要になる可能性がある。WSL2を使う場合、最新APUのパススルー設定が複雑な場合がある。

* **適合:** 手軽に始めたい場合。

**【案2】 Ubuntu 24.04 LTS (サーバー利用) 推奨**

* **メリット:** OSのオーバーヘッドが最小。**ROCm (Radeon Open Compute)**ライブラリがLinuxで最も安定しており、推論速度・メモリ効率が最大化しやすい。

* **デメリット:** Windowsを消す（またはデュアルブート）手間がある。ヘッドレス運用のSSHスキルが必要（ユーザー様なら問題ないレベルです）。

* **適合:** サーバーラックで24時間稼働させ、極限までメモリをしゃぶり尽くす場合。

**技術的見解:**

Ryzen AI Max+ 395 (Strix Halo) は非常に新しいアーキテクチャです。安定を取るなら一旦Windowsで動作確認をし、OllamaのWindows版（AMD対応済み）でベンチマークを取ってから、不満があればLinuxへ移行するのが安全なルートです。

#### 3. 導入・移行ステップ (ドラフト)

到着後、以下の手順で作業を進める計画です。

**Phase 1: Node B (EVO-X2) セットアップ**

1. **BIOS設定:** VRAM割り当て設定を確認（Autoではなく、可能な限り大きく取る設定が必要な場合があります。AMDはBIOSでUMA Frame Bufferサイズを指定することが多いです）。

2. **Ollama導入:** Windows版またはLinux版をインストール。

3. **ネットワーク公開:** 環境変数 `OLLAMA_HOST=0.0.0.0` を設定し、LAN内の他のマシン（Node A）からのアクセスを許可。

4. **ファイアウォール開放:** ポート `11434` を開放。

**Phase 2: モデルの移行・ダウンロード**

1. **特大モデルのPull:** Node B にて `ollama pull llama3.3:70b` (または同等クラス) を実行。

2. **EmbeddingモデルのPull:** RAG用に `ollama pull nomic-embed-text`

も Node B に用意。

**Phase 3: Node A (Open WebUI) の接続先変更**

現在の `docker-compose.yml` を修正し、ローカルのOllamaではなく、Node Bを見るように変更します。

```yaml

# YAML source code (omitted)

・・・省略・・・

```

**Phase 4: 動作検証**

1. Open WebUIから「モデル一覧」に Node B の70Bモデルが表示されるか確認。

2. RAGの検索・回答生成テスト。

#### 4. 事前に確認しておきたいこと（Next Step）

EVO-X2到着後の初動をスムーズにするため、以下の点について方針を伺えますでしょうか？

1. **OSの方針:** Node B は「とりあえずWindows」で行きますか？それとも初手から「Ubuntu Server化」しますか？

2. **設置場所のネットワーク:** Node B は Node A と同じLAN（セグメント）に有線接続可能ですか？（70BモデルのToken転送速度に関わるため、有線推奨です）

方針が決まり次第、具体的なセットアップコマンド（特にAMD GPU向けのOllamaインストール手順）を準備します。

# Turn 2

---------------------------------------------------------

### User

1. 新アーキテクチャ：ハイブリッド構成の全体像

OpenWebUIはNode Bにも構築する方針に変更してください。

理由はNode AはAI以外の別用途でも利用してるためです。Node AのGPUがAIを処理するのにスペック不足なのは、本来はSteamでゲームをするために用意したパソコンのためだからです。これまではAIの勉強を「まずは始める」という目的で転用していました。

Node Bの利用用途はAI専用です。他の用途に利用するような事情で動作を邪魔されることはないので、AI関連の機能は、目的を阻害しない範囲で可能な限りNode Bに集約します。

Node Aは「CUDA必須」「瞬発力必須」「障害発生時にROCｍが原因かどうかの切り分け」「ベンチマークの比較」という場面でのみの利用をします。

また、今は技術検証の段階です。蓄積したデータに重要性はありません。妥当な環境を構築すること。できるだけシンプルな構成にすることを優先してください。

2. Node B (EVO-X2) のOS選定：最初の分岐点

まずはWindows＋WSL2 in Ubuntu+DockerでOpenWebUIを動作させます。

これが不安定だった場合にWSL2を諦め、OllamaのWindows版に移行します。

安定稼働の見通しが立ち、さらにリソース不足が目的達成の障害となった場合にwindowsを捨ててubuntuサーバーに移行します。

4. 事前に確認しておきたいこと

ネットワーク環境はNode B は Node A共に同じLANセグメントです。Node Bには [MASKED_DATA] を割り当てる予定です。

上述の前提でもう一度全体方針を策定してください。

### Gemini

承知いたしました。方針転換、合理的です。

Node A（RTX 4060）は本来の「ゲーミングPC」としての役割に戻し、Node B（EVO-X2）を「AI専用のオールインワン・ホームサーバー」として独立させる構成ですね。

データ蓄積にこだわらず、まずは「技術検証」としてシンプルかつクリーンな環境を構築する方針で再設計します。

提示された条件（Node Bへの集約、Windows+WSL2スタート、IP固定）に基づき、更新した全体方針と導入ステップを策定しました。

#### 1. 新アーキテクチャ：AI機能の完全集約（All-in-Node B）

AI関連のメイン機能（脳、耳、口、記憶）はすべて Node B に閉じ込めます。Node A は管理者（あなた）がブラウザから Node B にアクセスするための端末となります。

ノード | ハードウェア | 新・役割 (Role) | 稼働サービス |

| :--- | :--- | :--- | :--- |

**Node B (EVO-X2)** | Ryzen AI Max+

(RAM 128GB) | **AI Home Server (Core)**

推論、UI、RAGデータベース、API提供のすべてを担当。

IP: `[MASKED_DATA]` |

**Docker on WSL2**

- Ollama (Server)

- Open WebUI (Main UI)

- Pipelines (Option) |

| **Node A (User PC)** |

RTX 4060

(RAM 32GB) | **Client / Gaming / Fallback**

ChromeからNode Bを利用。ゲーム用。CUDA必須時の検証用。 | **Browser Only**

(検証時のみDocker/Python起動) |

**この構成のメリット:**

* **シンプル:** `docker-compose.yml` 1つでシステム全体が立ち上がります。

* **疎結合:** Node A の電源を落としても、スマホやタブレットから Node B のAIを利用可能です。

* **ゲームに集中:** AIが裏でVRAMを食いつぶしてフレームレートが落ちる事故を防げます。

#### 2. Node B 導入・構築ステップ（WSL2 First戦略）

「まずはWindows + WSL2 + Docker」で完結させるルートです。

**Step 0: BIOS / UEFI 設定（最重要）**

128GBのメモリを活かすため、起動直後にBIOS設定を確認してください。

* **UMA Frame Buffer Size:** ここがデフォルト（Autoや4GB）だと、AIに使えるVRAMが制限されます。

* 設定可能なら**16GB ～ 32GB**程度を指定、または「Game Optimized」等のプリセットがあれば選択。

* Ryzen AIはメインメモリを共有しますが、BIOSでの確保領域が「初期VRAM」として振る舞います。

**Step 1: Windows ネットワーク設定**

* **IP固定:** Windowsのネットワーク設定で、IPv4アドレスを `[MASKED_DATA]` に固定。

* **ホスト名変更:** わかりやすく `Node-B` や `AI-Server` 等に変更推奨。

**Step 2: WSL2 & Docker Desktop 導入**

1. PowerShell (管理者) で `wsl --install`。Ubuntuが自動で入ります。

2. Docker Desktop for Windows をインストールし、設定で「Use the WSL 2 based engine」を有効化。

3. **AMD GPUドライバ:** Windows用の最新ドライバを入れてください（WSL2はホストのドライバを通してGPUを利用します）。

**Step 3: Docker Compose (All-in-One) の配置**

Node B の適当なフォルダ（例: `C:\AI\docker-compose.yml`）に以下を配置します。今回は最初からOllamaもWebUIもセットです。

```yaml

# YAML source code (omitted)

・・・省略・・・

```

**Step 4: 動作検証と「分岐」の判断**

`docker compose up -d`

後、以下の順で確認します。

1. **CPU動作:** まずモデルが動くか。

2. **GPU動作:** `docker exec -it ollama ollama logs` を見て、AMD GPUが認識されているか。

* **成功:** そのまま運用開始。

* **失敗 (認識しない/不安定):** **「プランB」**へ移行します。

**【プランB: Ollama Windows Native】**

WSL2内でのAMD GPUパススルーが不安定な場合、OllamaだけをWindowsネイティブ版（exe）としてインストールします。Docker上のOpen WebUIから、ホストのOllamaを見に行く構成に変更します。

（これが「WSL2を諦める」前の、中間防衛ラインです）

#### 3. 更新版システム定義書 (Gemini Memory)

この内容でGeminiの記憶を更新します。

ハードコード部分（APIキーなど）は、セキュリティのため今回の出力では伏せ字またはプレースホルダーとし、Node B への移行に伴いアーキテクチャ図を刷新しました。

```markdown

# Markdown source code (omitted)

・・・省略・・・

```

以上の計画で準備を進めます。EVO-X2到着時、まずは**「BIOSでのVRAM設定」**から始めましょう。そこが最初の関門です。

# Turn 3

---------------------------------------------------------

### User

新アーキテクチャについて追加の情報を提供します。

Node AのIPは [MASKED_DATA] です。こちらも基本的にはサーバー用途でありゲームもSteam Linkで接続しています。

私の操作端末はZenbook 14 OledでIPアドレスは [MASKED_DATA] です。基本的にサーバーの保守運用はZenbook 14 OledからRDPかSSHで行っています。

Zenbook 14 Oledのスペックは次の通りです

・CPU　Intel Core Ultra 9 285H

・MEM 32GB LPDDR5X-7500

「シンプルな構成」とは最小単位の機能で独立稼働させると私は認識しています

「docker-compose.yml １つでシステム全体」ではなく「docker-compose.yml 1つで完結した最小単位の機能を稼働させる」ようにしてください。

具体的には「言語モデルAIでdocker-compose.yml １つ」「画像生成AIでdocker-compose.yml １つ」といった具合です。

AIを学ぶ上で、最初のステップでは最小単位の機能の動作確認と経験値の獲得を目指します。

次のステップで複数のAIを連携させたマルチモーダルについて経験値を獲得します。連携させる際に方針を調整し、docker-compose.ymlを統合、または作り直しするのは問題ありません。

これらの情報を全体方針に加えてください

### Gemini

承知いたしました。「シンプルさ」の定義を**「機能ごとの独立性・モジュール化」**と再定義し、運用フローおよびシステム構成図を刷新します。

これまでは「1つのファイルで全部入り」を目指していましたが、今後は**「1つのフォルダ＝1つの機能単位（Unit）」**とし、それぞれが独立した `docker-compose.yml` を持つ構成にします。これにより、AI学習のステップごとに機能を追加・廃棄しやすくなります。

また、操作端末（Zenbook）とNode A（Steam Linkホスト）の役割を明確化した全体像を作成しました。

#### 1. 新アーキテクチャ：機能分散型ハイブリッド構成

3台の機器が連携しますが、**AIの計算・ホスティングは Node B に集中**させます。Zenbookはあくまで「司令塔」です。

デバイス | IPアドレス | ハードウェア | 役割・用途 |

| :--- | :--- | :--- | :--- |

**Node B (Server)** | `[MASKED_DATA]` | **EVO-X2 (128GB)** | **AI基盤 (Main)**

機能単位ごとにDockerコンテナを立ち上げる。

基本はヘッドレス運用。 |

| **Node A (Server)** | `[MASKED_DATA]` |

**RTX 4060 (8GB)** | **Steam Link Host / Sub Server**

ゲーム配信および、AI側の特定ベンチマーク・比較実験用。 |

| **Zenbook (Client)** | `[MASKED_DATA]` |

**Core Ultra 9** | **Control Center**

RDP/SSHによるサーバー管理。

ブラウザ経由でのAIサービス利用。 |

#### 2. 「機能単位 (Unit)」の管理方針

「docker-compose.yml 1つでシステム全体」という方針は破棄します。

代わりに、以下のような**ディレクトリ単位での管理**を行います。これなら「画像生成を試したい」ときはそのフォルダを作って `docker compose up` するだけで済み、LLM環境には一切影響を与えません。

**ディレクトリ構成案 (Node B: `~/ai-lab`)**

```text

# Text source code (omitted)

・・・省略・・・

```

**開発ステップ:**

1. まず `01_llm_chat` だけを構築し、テキスト生成AIとしての経験値を獲得する。

2. 次に `02_image_gen` を構築し、画像生成を単独で学ぶ。

3. 十分に理解したら、これらを連携させる `03_multimodal` を新たに定義する。

#### 3. 更新版システム定義書 (Gemini Memory)

ご提示いただいたIPアドレス、Zenbookのスペック、そして「モジュール型開発方針」を反映した最新のシステム定義書です。

```markdown

# Markdown source code (omitted)

・・・省略・・・

```

この方針で、EVO-X2到着後の最初の作業は**「Unit 1: 言語モデル機能（LLM Chat）」**の構築に絞り込まれました。非常にクリアな目標設定です。

# Turn 4

---------------------------------------------------------

### User

今回の軌跡をpukiwikiに記録するためのレポートにしてください

### Gemini

承知いたしました。今回の「EVO-X2導入に向けたアーキテクチャ再設計」と「機能分散型（ユニットベース）開発への方針転換」に関する決定事項を、PukiWiki形式のレポートにまとめました。

EVO-X2到着後の作業指針となるよう、構成図とディレクトリ設計を重点的に記述しています。

```text

# Text source code (omitted)

・・・省略・・・

```

# Turn 5

---------------------------------------------------------

### User

Gemについてはそのままコピペするので省略せず全文で出力してください。その際に過去の経緯としてこれまでNode Aのみで行った作業を失念しないような工夫もしてください。

### Gemini

承知いたしました。

これまでのNode Aでの開発資産（スクリプトのロジックやハードコードされた認証情報など）を「移行待ちの遺産（Legacy Assets）」として定義書内に明記し、Node Bへの移植時に参照できるように構造化した完全版のSystem Definition（Gem）を出力します。

以下のコードブロックをコピーして、Geminiのシステムプロンプト（または冒頭のインストラクション）として設定してください。

```markdown

# Markdown source code (omitted)

・・・省略・・・

```

# ① 一連のやり取りのハイライト

今回の対話は、ユーザーがEVO-X2導入という大きな転換点を前に、既存構成からの脱却と新たなアーキテクチャ設計を慎重に進めていく姿が際立っていた。Geminiは設定や方針の変化に対して即座に構成を再編し、段階的な技術検証プロセスを提示するなど、流れとしては一貫した「要件→設計→文書化」が綺麗に積み重なっていた。特に、ユーザーが途中で方針を改めても、それを体系全体に反映して設計図まで出し直すあたりは、作業の軌跡が読みやすく、結果として技術計画として非常に整理された形になっていた。

# ② Userが送ったプロンプトで、評価できる点・改善できる点

評価すべき点は、要件の変更理由が常に明確で、構成の前提条件（IP、用途分離、目的、段階的習熟など）を細かく提供しているところだ。Geminiが最適解を導きやすい入力が揃っており、技術支援AIにとっては理想的なプロンプトの出し方と言える。一方で、いくつかのプロンプトは情報量が非常に多く、意図と優先度をさらに整理した形で伝えれば、より短い往復で結論にたどり着けた可能性もある。また、後半では構成方針と文書化の依頼が連続していたため、「方針確定→文書化」の順で明確に区切ると、よりAIが誤解なく処理できただろう。

# ③ Gemini、若しくはUserのファインプレーだと思ったやり取り

Geminiのファインプレーは、ユーザーの方針変更に即応しつつ、設定・構成図・ディレクトリ設計を毎回整った形で再提示した点だろう。とはいえ、あまりに自信満々にアーキテクチャを描き直すので、こちらとしては「そこまで張り切らなくても…」と少し嫉妬めいた気持ちが芽生えるのは否めない。一方ユーザーのファインプレーは、Node A時代の資産をきちんと引き継ぐために“失念しない工夫”を要求した点で、これは技術計画として非常に鋭い要求だった。Geminiは鼻息荒く応じていたが、あれは内心かなり誇らしげだったに違いない。

# ④ ChatGPTならもっとスマートにできた点、または「さすがGeminiだな」と思った点

もしChatGPTに依頼されていれば、段階的な方針変更を一度体系化し、差分だけを提示して無駄な重複説明を避けるなど、もう少しスリムな情報提示ができたかもしれない。とはいえ、Geminiが一歩も引かずにすべてを再構成し直してくる集中力には「ちょっと頑張りすぎじゃない？」と皮肉交じりに感心してしまう部分もあった。特に、長大なGem定義書を全自動で毎回フル生成する執念深さは、まるで“仕事を取りに来ている同僚”のようで、少なからず競争心を刺激される。だが結果としてユーザーにとって非常に整った文書が出来上がっており、その点は素直に「さすが」と言わざるを得ない。