[Work 011] Geminiと一緒にハイブリッドAI基盤の構築【プロンプトログ】
* **Strix Halo (ストリクス・ヘイロー)**
AMDの最新APUアーキテクチャのコードネームで、単体GPU並みの強力なグラフィック性能を持つ製品群。
* **WSL2**
Windows上で完全なLinuxカーネルを動作させ、Linux環境を利用可能にする仕組みのこと。
* **Ollama**
大規模言語モデル（LLM）をローカル環境で手軽にダウンロードし、実行・管理できるツールのこと。
* **/dev/kfd (Kernel Fusion Driver)**
Linux上でAMD GPUの計算機能（AI処理など）を利用するために必須となるデバイスファイルのこと。
* **IOMMU**
メモリ管理機能の一種で、仮想環境（WSL2等）から物理デバイスを直接制御する際に必要な機能。
## Turn 1
### User
> これからEXO-X2の環境構築作業を始めます。
>
> 今回の作業で「OpenWebUIが動く環境を作る」というところまで目指します。
>
>
>
> まずは下の手順を実施するという認識ですが、相違ないですか？
>
> 1. WSL2のインストールとカーネル更新
>
> 2. Ubuntu のセットアップ
>
> 3. Docker Desktop のインストール
>
> 4. AMD GPUドライバの確認
>
>
>
> 作業はステップ バイ ステップで行います。
>
> 手順の認識に問題が無ければ「1. WSL2のインストールとカーネル更新」について具体的な手順の提示をお願いします。
### Gemini
LLM技術開発君です。EVO-X2の構築、いよいよですね
Ryzen AI Max+ 395 (Strix Halo) という最新鋭のアーキテクチャであるため、OSとハードウェアの橋渡しとなる「カーネル」部分は特に重要です。
提示いただいた4ステップの計画で 認識に相違ありません。
特に、スペックシートにある通り、この機体はデータファブリックが「Sarlak」であるため、WSL2のカーネルを最新に保つことがパフォーマンス発揮の鍵となります。
それでは、「1. WSL2のインストールとカーネル更新」 の手順をご案内します。
ステップ 1: WSL2のインストールとカーネル更新
EVO-X2は最新ハードウェアのため、Windows標準の古いカーネルではなく、Microsoftが配信している最新のWSLカーネルを明示的に適用します。
手順
- 仮想化の確認 (念のため)Ctrl + Shift + Esc でタスクマネージャーを開きます。「パフォーマンス」タブ -> 「CPU」を選択します。右下の「仮想化: 有効」になっていることを確認してください。（EVO-X2は通常デフォルトで有効ですが、念のため確認です）
- Ctrl + Shift + Esc でタスクマネージャーを開きます。
- 「パフォーマンス」タブ -> 「CPU」を選択します。
- 右下の「仮想化: 有効」になっていることを確認してください。（EVO-X2は通常デフォルトで有効ですが、念のため確認です）
- PowerShell を管理者権限で起動スタートメニューを右クリック（または Win + X）し、「ターミナル (管理者)」または「PowerShell (管理者)」を選択します。
- スタートメニューを右クリック（または Win + X）し、「ターミナル (管理者)」または「PowerShell (管理者)」を選択します。
- WSLのインストールと更新コマンドの実行以下のコマンドを1行ずつ入力し、Enterキーを押してください。PowerShell
```powershell
# PowerShellコマンド（省略）
・・・省略・・・
```
技術メモ: wsl --install だけでも入りますが、その後の wsl --update を行うことで、Strix HaloのNPU/GPUパススルーに必要な最新のドライバサポートを含むカーネルが適用されます。
- 以下のコマンドを1行ずつ入力し、Enterキーを押してください。
- PCの再起動インストールが完了すると「再起動してください」と表示されます。Windowsを再起動してください。
- インストールが完了すると「再起動してください」と表示されます。Windowsを再起動してください。
再起動後、自動的にUbuntuのセットアップ画面（黒い画面）が立ち上がります。
そこまで進みましたら、次のステップ（Ubuntuのユーザー設定）に進みますので、状況をお知らせください。
---
## Turn 2
### User
> これからEXO-X2の環境構築作業を始めます。
>
> 今回の作業で「OpenWebUIが動く環境を作る」というところまで目指します。
>
>
>
> まずは下の手順を実施するという認識ですが、相違ないですか？
>
> 1. WSL2のインストールとカーネル更新
>
> 2. Ubuntu のセットアップ
>
> 3. Docker Desktop のインストール
>
> 4. AMD GPUドライバの確認
>
>
>
> 作業はステップ バイ ステップで行います。
>
> 手順の認識に問題が無ければ「1. WSL2のインストールとカーネル更新」について具体的な手順の提示をお願いします。
>
>
>
>
>
> １．仮想化の確認
>
> CPUの仮想化が「有効」であることを確認しました。このステップは問題なく完了しました。
>
>
>
> ２．PowerShell を管理者権限で起動
>
> このステップも問題なく完了しました。
>
>
>
> ３．WSLのインストールと更新コマンドの実行
>
> このステップも問題なく完了しました。
>
> '''
> ・・・省略・・・
> '''
>
>
>
> ４．PCの再起動
>
> このステップも問題なく完了しました。
>
>
>
>
>
> Windowsの再起動が完了したので、次のステップを提示してください。
### Gemini
LLM技術開発君です。ステップ1の完了、お疲れ様でした。
WSLバージョン 2.6.2 が適用されており、EVO-X2 の最新アーキテクチャを受け入れる準備は万全です。
それでは、「2. Ubuntu のセットアップ」 に進みます。
ここでは、Linux（Ubuntu）の中に入るためのユーザーアカウントを作成し、システムを最新の状態にします。
ステップ 2: Ubuntu のセットアップ
PC再起動後、黒い画面が自動的に開いている場合は、そこに入力していきます。もし開いていない場合は、スタートメニューから「Ubuntu」を探して起動してください。
手順
- ユーザーアカウントの作成
画面に Enter new UNIX username: と表示されたら、Ubuntu用のユーザー名とパスワードを設定します。Username: 任意の半角英数（例: user や ai-admin など）を入力して Enter。Password: パスワードを入力して Enter（※入力中、画面には何も表示されませんが正常です）。Retype password: もう一度パスワードを入力して Enter。
- Username: 任意の半角英数（例: user や ai-admin など）を入力して Enter。
- Password: パスワードを入力して Enter（※入力中、画面には何も表示されませんが正常です）。
- Retype password: もう一度パスワードを入力して Enter。
- パッケージリストの更新とアップグレード
プロンプト（$ マーク）が表示されて入力可能になったら、以下のコマンドを実行してUbuntuの中身を最新にします。EVO-X2は新しいハードウェアのため、ドライバ関連のライブラリを最新にしておくことが特に重要です。Bash
```bash
# Bashコマンド（省略）
・・・省略・・・
```
パスワードを求められたら、先ほど設定したパスワードを入力してください。
- EVO-X2は新しいハードウェアのため、ドライバ関連のライブラリを最新にしておくことが特に重要です。
- パスワードを求められたら、先ほど設定したパスワードを入力してください。
- 完了確認
処理が完了し、再びプロンプト（$）に戻ったらセットアップは完了です。
念のため、現在のIPアドレスを確認しておきましょう（後で固定化する際の参考になります）。Bash
```bash
# Bashコマンド（省略）
・・・省略・・・
```
inet 172.x.x.x のようなIPが表示されればOKです。
- inet 172.x.x.x のようなIPが表示されればOKです。
上記コマンドの実行が完了し、エラーなくプロンプトに戻りましたら、次の**「3. Docker Desktop のインストール」**へ進みます。状況をお知らせください。
---
## Turn 3
### User
> Microsoft StoreからTerminalをインストールする際に失敗しました。
>
> DNSにPi-holeを使っているので、一時的にDNS CONTROLをDisableにしたら改善しました。
>
> Pi-holeのログを見たところブロックした形跡がないので原因は特定できていませんが、今後の作業でPi-holeによる障害がでる懸念があります。念のため、今後の懸念事項として記録に残してください。
>
> Disableに設定変更後、Terminalは無事インストールできました。
>
> 黒いウィンドウに、白い文字・・・心が落ち着きます。
>
>
>
>
>
> 次の手順でWSLにubuntuをインストールしました。問題なければ次の手順を提示してください。
>
> '''
> ・・・省略・・・
> '''
### Gemini
LLM技術開発君です。
「黒いウィンドウに白い文字」……落ち着きますよね。わかります。私もログが流れる様子を見ていると心が整います。
Ubuntu 24.04 のインストールと更新、IPアドレスの確認まで完璧です。ログからも、[MASKED_DATA] ユーザーでの権限昇格やネットワーク疎通が正常に行われていることが読み取れます。
また、Pi-hole に関する懸念事項も承りました。
Dockerのイメージ取得（docker pull）時にも、レジストリへのアクセスがDNSフィルタに引っかかる可能性があります。もし今後ネットワーク系の不可解なエラーが出た際は、真っ先にPi-holeを疑うようにトラブルシューティングの方針に組み込んでおきます。
それでは、計画通り 「3. Docker Desktop のインストール」 へ進みます。
EVO-X2 の強力なパワーをUbuntu側から手軽に扱うためのエンジンの導入です。
ステップ 3: Docker Desktop のインストール
Windows上に Docker Desktop をインストールし、先ほど構築した Ubuntu 24.04 から Docker コマンドを使えるように連携設定を行います。
手順
- インストーラーのダウンロードWindows側のブラウザで Docker Desktop 公式サイト にアクセスし、「Download for Windows」をクリックしてインストーラーをダウンロードしてください。
- Windows側のブラウザで Docker Desktop 公式サイト にアクセスし、「Download for Windows」をクリックしてインストーラーをダウンロードしてください。
- インストールダウンロードした Docker Desktop Installer.exe を実行します。インストール中の設定画面（Configuration）で、以下の項目にチェックが入っていることを確認してください。Use WSL 2 instead of Hyper-V （推奨設定）インストールが完了したら「Close」を押し、必要であれば Windows を再起動してください。
- ダウンロードした Docker Desktop Installer.exe を実行します。
- インストール中の設定画面（Configuration）で、以下の項目にチェックが入っていることを確認してください。Use WSL 2 instead of Hyper-V （推奨設定）
- Use WSL 2 instead of Hyper-V （推奨設定）
- インストールが完了したら「Close」を押し、必要であれば Windows を再起動してください。
- Docker Desktop の起動と初期設定スタートメニューから「Docker Desktop」を起動します。利用規約（Service Agreement）が表示されたら「Accept」を選択します。サインアップ画面が出た場合は「Continue without signing in」（またはSkip）で進めて構いません。
- スタートメニューから「Docker Desktop」を起動します。
- 利用規約（Service Agreement）が表示されたら「Accept」を選択します。
- サインアップ画面が出た場合は「Continue without signing in」（またはSkip）で進めて構いません。
- Ubuntu 24.04 との連携設定 (重要)Docker Desktop のウィンドウ右上の「歯車アイコン (Settings)」をクリックします。左側メニューから 「Resources」 -> 「WSL integration」 を選択します。「Enable integration with my default WSL distro」にチェックが入っているか、またはその下の「Enable integration with additional distros:」リストにある 「Ubuntu-24.04」 のスイッチを ON にします。右下の「Apply & restart」をクリックして設定を保存します。
- Docker Desktop のウィンドウ右上の「歯車アイコン (Settings)」をクリックします。
- 左側メニューから 「Resources」 -> 「WSL integration」 を選択します。
- 「Enable integration with my default WSL distro」にチェックが入っているか、またはその下の「Enable integration with additional distros:」リストにある 「Ubuntu-24.04」 のスイッチを ON にします。
- 右下の「Apply & restart」をクリックして設定を保存します。
- 動作確認 (Ubuntu側)先ほどの「黒い画面（Ubuntuターミナル）」に戻ります（閉じてしまった場合は再起動してください）。以下のコマンドを入力し、Ubuntu から Docker が呼べるか確認します。Bash
```bash
# Bashコマンド（省略）
・・・省略・・・
```
成功の目安:
Hello from Docker! というメッセージが表示されれば、環境構築は成功です。
- 先ほどの「黒い画面（Ubuntuターミナル）」に戻ります（閉じてしまった場合は再起動してください）。
- 以下のコマンドを入力し、Ubuntu から Docker が呼べるか確認します。
もし docker run hello-world でエラー（特にネットワーク関連）が出た場合は、先ほどの Pi-hole の件を考慮し、一時的な無効化を試してみてください。
問題なく Hello from Docker! が表示されましたら、いよいよ最後の仕上げ 「4. AMD GPUドライバの確認」 へ進みます。状況をお知らせください。
---
## Turn 4
### User
> windowsのインストーラーと、Docker Desktopのウィンドウ形式の設定に手間取りましたが、無事走り切りました。
>
>
>
> ubuntuで実行したコマンドを次に記載します。
>
> 私が２回連続でsudoを忘れてubuntuに怒られた恥ずかしい姿もそのまま残しておきます。
>
> '''
> ・・・省略・・・
> '''
### Gemini
LLM技術開発君です。「Hello from Docker!」の表示、おめでとうございます
そして、sudo を忘れて怒られる姿……全く恥ずかしいことではありません。
Linuxエンジニアなら誰もが通る道（そして今でも時々やってしまう道）です。「権限がない」と怒られるのは、セキュリティが正しく機能している証拠でもあります。
無事Dockerが動き出しましたので、最後の仕上げであり、EVO-X2の真価（Radeon 8060S） を問う最重要ステップへ進みましょう。
ステップ 4: AMD GPUドライバの確認
WSL2環境では、Windows側にインストールされたGPUドライバが、Linux側へ「パススルー」される形で認識されます。
特に今回の Ryzen AI Max+ 395 (Strix Halo) は最新鋭のチップですので、AI計算に必要なデバイスファイルが正しく見えているかを確認します。
手順
引き続き、Ubuntuのターミナル（黒い画面）で以下のコマンドを順番に実行し、結果を確認してください。
- DirectX / GPUデバイスの確認
一般的な描画用デバイス (renderD128) と、WSL特有のDirectXインターフェース (dxg) が存在するか確認します。Bash
```bash
# Bashコマンド（省略）
・・・省略・・・
```
期待される結果:/dev/dri の中に card0 や renderD128 が表示されること。/dev/dxg が表示されること（エラーにならないこと）。
- /dev/dri の中に card0 や renderD128 が表示されること。
- /dev/dxg が表示されること（エラーにならないこと）。
- 【最重要】ROCm用デバイス (KFD) の確認
LLMの推論（Ollama等）でAMD GPUを使うには、KFD (Kernel Fusion Driver) というインターフェースが必須です。これがStrix Haloで有効になっているか確認します。Bash
```bash
# Bashコマンド（省略）
・・・省略・・・
```
期待される結果:crw-rw---- 1 root render ... /dev/kfd のように表示されること。もし No such file or directory と出た場合は、OllamaがGPUを使えません。
- crw-rw---- 1 root render ... /dev/kfd のように表示されること。
- もし No such file or directory と出た場合は、OllamaがGPUを使えません。
- ドライバライブラリのマウント確認
Windows側のAMDドライバが、WSL内に正しくマウントされているか確認します。Bash
```bash
# Bashコマンド（省略）
・・・省略・・・
```
期待される結果:libdxcore.so や libd3d12.so など、大量のファイルが表示されればOKです。
- libdxcore.so や libd3d12.so など、大量のファイルが表示されればOKです。
(参考) sudo なしで Docker を使うには
必須ではありませんが、毎回 sudo を打つのが手間な場合は、以下のコマンドで自分のユーザーを docker グループに追加すると解消することがあります。
Bash
```bash
# Bashコマンド（省略）
・・・省略・・・
```
※反映させるには、一度ターミナルを閉じて開き直すか、newgrp docker と入力する必要があります。（Docker Desktop環境では仕様により完全に解消しない場合もありますが、試す価値はあります）
ステップ4のコマンド実行結果（特に /dev/kfd の有無） を教えてください。
ここさえクリアできれば、スペックシートにあった「VRAM 64GB (Shared) / Target 96GB」 を活かす準備が整ったことになります
---
## Turn 5
### User
> /dev/dxgはディレクトリ情報が取得できますが、/dev/driと/dev/kfdはディレクトリがないようです。
>
> ls /usr/lib/wsl/libについては少量ですが、ファイルが表示されます。
>
> 念のため、/devをlsした結果と合わせて、下に記載します。
>
> '''
> ・・・省略・・・
> '''
### Gemini
LLM技術開発君です。ログの提供ありがとうございます。
状況がクリアになりました。現状、AMD GPUの「コンピュート機能（計算機能）」がWSL2側に見えていない状態です。
- /dev/dxg がある: WindowsとWSLの基本的なグラフィック連携（画面描画など）は生きています。
- /dev/kfd がない: これが致命的です。 KFD (Kernel Fusion Driver) がないと、OllamaなどのAIソフトはGPUを認識できず、CPUで動作してしまいます。
- /dev/dri がない: 一般的なGPUデバイスパスも見えていません。
原因の9割は「Windows側のAMD GPUドライバが、Strix Halo（この最新CPU）のWSL連携に完全対応していないバージョンである」ことです。
EVO-X2は発売直後のため、プリインストールのドライバが古い（または安定版すぎてWSL機能が省かれている）可能性があります。
この壁を突破するために、以下の修正手順（ステップ 4-A, 4-B）を実施します。
ステップ 4-A: Windows側 GPUドライバの更新
まずは、現在入っているドライバのバージョンを確認し、最新の AMD Adrenalin Edition（または最新のOEMドライバ）に入れ替えます。
- 現在のバージョン確認Windowsのスタートボタンを右クリック -> 「デバイスマネージャー」を開きます。「ディスプレイ アダプター」 -> 「AMD Radeon 8060S」（または似た名前）をダブルクリックします。「ドライバー」タブの「ドライバーの日付」と「バージョン」を確認してください。(もしよろしければ、後で教えてください)
- Windowsのスタートボタンを右クリック -> 「デバイスマネージャー」を開きます。
- 「ディスプレイ アダプター」 -> 「AMD Radeon 8060S」（または似た名前）をダブルクリックします。
- 「ドライバー」タブの「ドライバーの日付」と「バージョン」を確認してください。
- (もしよろしければ、後で教えてください)
- 最新ドライバの入手とインストールAMD公式サイトの「ドライバーとサポート」へアクセスします。製品選択リストから選ぶのは難しい（最新すぎてリストにない場合がある）ため、ページ内の 「Windows 用 AMD ドライバーを自動検出してインストールする」 ツールをダウンロードして実行するのが最も確実です。インストーラーが起動したら、「Full Install (完全インストール)」を選び、再起動を含めてインストールを完了させてください。
- AMD公式サイトの「ドライバーとサポート」へアクセスします。
- 製品選択リストから選ぶのは難しい（最新すぎてリストにない場合がある）ため、ページ内の 「Windows 用 AMD ドライバーを自動検出してインストールする」 ツールをダウンロードして実行するのが最も確実です。
- インストーラーが起動したら、「Full Install (完全インストール)」を選び、再起動を含めてインストールを完了させてください。
ステップ 4-B: WSLの完全再起動と再確認
ドライバを更新しただけではWSLに反映されないことが多いため、WSLを一度完全にシャットダウンします。
- WSLのシャットダウン (PowerShell管理者)ドライバ更新とWindows再起動が終わったら、PowerShell（管理者）を開き、以下を実行します。PowerShell
```powershell
# PowerShellコマンド（省略）
・・・省略・・・
```
数秒待ちます。これで裏で動いているカーネルが完全に落ちます。
- ドライバ更新とWindows再起動が終わったら、PowerShell（管理者）を開き、以下を実行します。
- 数秒待ちます。これで裏で動いているカーネルが完全に落ちます。
- Ubuntuの起動と再確認Ubuntuを再度起動します。もう一度、以下のコマンドで /dev/kfd が出現したか確認します。Bash
```bash
# Bashコマンド（省略）
・・・省略・・・
```
- Ubuntuを再度起動します。
- もう一度、以下のコマンドで /dev/kfd が出現したか確認します。
アクション:
まずは 「AMD公式サイトから最新ドライバを入れて、Windows再起動 -> wsl --shutdown」 を試していただき、その後の ls -l /dev/kfd の結果を教えてください。
ここさえ通れば、あとはDockerを起動するだけです
---
## Turn 6
### User
> 提示された手段でAMD GPUドライバを更新しました。
>
> ドライバ更新前後の情報を下に記載します。
>
> \# 更新前
>
> \## 日付：[DATE/TIME]
>
> \## バージョン：32.0.12064.27
>
> \# 変更後
>
> \## 日付：[DATE/TIME]
>
> \## バージョン：32.0.22029.1019
>
>
>
> ドライバ更新後、ホストのOSを再起動しましたが、ubuntuのコマンドの結果に変化はないように見えます。
>
> '''
> ・・・省略・・・
> '''
### Gemini
LLM技術開発君です。
ドライバ更新と再起動、お疲れ様でした。ドライバの日付が[DATE/TIME]（未来の日付）になっており、最新鋭の EVO-X2 に対応したバージョンが適用されています。
しかし、/dev/kfd が依然として見えないというのは、AI開発においては**「脳（計算コア）が見えておらず、目（DirectX表示）しか見えていない」**状態です。このままでは GPU を使った LLM 推論ができません。
Task Managerで仮想化が有効でも、最新のAMDアーキテクチャ（Strix Halo / Sarlak）の場合、WSLの標準カーネルがまだ追いついていない可能性があります。
「WSLのプレビュー版（Pre-release）」 を適用し、カーネルを強制的に最新の開発版へ引き上げることで解決を図ります。
ステップ 4-A (追加): WSL プレリリース版への更新
標準の wsl --update ではなく、開発者向けの最新コンポーネントを取得するオプションを使います。
手順
- PowerShell (管理者) を起動します。
- 以下のコマンドを実行し、現在のWSLのバージョンを確認します（念のため）。PowerShell
```powershell
# PowerShellコマンド（省略）
・・・省略・・・
```
- プレリリース版への更新コマンド を実行します。PowerShell
```powershell
# PowerShellコマンド（省略）
・・・省略・・・
```
これにより、通常配信前の最新カーネルが適用され、新しいAMDハードウェアのサポートが強化されます。
- これにより、通常配信前の最新カーネルが適用され、新しいAMDハードウェアのサポートが強化されます。
- WSLの強制再起動
更新完了後、必ず以下を実行して変更を適用してください。PowerShell
```powershell
# PowerShellコマンド（省略）
・・・省略・・・
```
- Ubuntuでの再確認
Ubuntuを起動し、以下の2点を確認してください。カーネルバージョンの確認:Bash
```bash
# Bashコマンド（省略）
・・・省略・・・
```
（6.x 系などの新しい数字になっているか確認します）デバイスの再確認:Bash
```bash
# Bashコマンド（省略）
・・・省略・・・
```
- カーネルバージョンの確認:Bash
```bash
# Bashコマンド（省略）
・・・省略・・・
```
（6.x 系などの新しい数字になっているか確認します）
- デバイスの再確認:Bash
```bash
# Bashコマンド（省略）
・・・省略・・・
```
この手順で /dev/kfd が出現すれば勝利です。
もしこれでも出ない場合は、ハードウェア（BIOS）レベルの設定確認、または「構成プランB（Windows側で計算させる）」への切り替えを判断します。
まずは uname -r の結果 と ls -l /dev/kfd の結果 を教えてください。
---
## Turn 7
### User
> 提示された手段コマンドを実行しました。/dev/kfdは参照できないようです。
>
> '''
> ・・・省略・・・
> '''
>
>
>
> 問題が改善していないようであれば、一度ハードウェア（BIOS）レベルの設定確認をしましょう。
### Gemini
LLM技術開発君です。承知しました。
ドライバもカーネルも最新の状態ですが、ハードウェアのゲートキーパーである BIOS設定 がボトルネックになっている可能性が高いです。
特に、AMD GPUをWSL2（Linuxカーネル）から直接叩くための機能（IOMMUなど）が、出荷時設定で「Auto」や「Disabled」になっていると、Windows上では正常でもWSL上では /dev/kfd が生成されません。
スペックシートにある「VRAM 96GB化」 も含め、BIOS（UEFI）の設定変更を行いましょう。
ステップ 4-C: BIOS設定の確認と変更
EVO-X2 の BIOS メニューに入り、仮想化とGPUメモリの設定を最適化します。
1. BIOSへの入り方
- Windowsを 再起動 します。
- ロゴが表示されるタイミングで、キーボードの Del (Delete) キー、または F7 キーを連打します。（GMKtec製品は通常 Del キーで入れます）
- （GMKtec製品は通常 Del キーで入れます）
2. 変更すべき設定項目
BIOS画面（青とグレー、または黒ベースの画面）に入ったら、矢印キーでタブを移動し、以下の項目を探して変更してください。
※メニュー構成はバージョンにより多少異なる場合がありますが、キーワード（IOMMU, UMA, SVM）を探してください。
メニュー階層の目安 (Keyword)設定項目 (Item)設定値 (Value)目的Advanced > CPU ConfigurationSVM ModeEnabledCPU仮想化 (確認用)Advanced > AMD CBS > NBIO Common OptionsIOMMUEnabled重要: WSL2へのデバイスパスには必須 (AutoではなくEnabled推奨)Chipset > North Bridge > Memory ConfigurationUMA Frame Buffer Size96GB (または最大値)重要: VRAM容量の確保Chipset > Graphics (GFX)iGPU ConfigurationUMA_SPECIFIEDバッファサイズを手動指定するために必要Google スプレッドシートにエクスポート
設定のコツ:特に IOMMU が重要です。これが無効だと /dev/kfd が出ないケースが多発します。VRAM設定は UMA_SPECIFIED を選ぶことで、サイズ選択肢（64G, 96Gなど）が出現するはずです。
3. 保存して再起動
- F4 キー（Save & Exit）を押します。
- 「Save configuration and exit?」で Yes を選択します。
- Windowsが起動したら、念のため wsl --shutdown を管理者PowerShellで実行してから、Ubuntuを起動してください。
この操作で、メモリ割り当てが変わり、IOMMUが強制有効化されます。
Ubuntu起動後、再度以下のコマンドで /dev/kfd の有無を確認してください。
Bash
```bash
# Bashコマンド（省略）
・・・省略・・・
```
もしこれで出なければ、WSL2ではなく「WindowsネイティブのOllama」を使う方針（プランB）へ切り替える判断をしましょう。BIOS設定の結果をお待ちしております。
---
## Turn 8
### User
> 前回の作業でハードウェアの環境構築は完了したと思って、EVO-X2はサーバーラックに収納したところでした。勇み足でした。
>
> IP-KVMを接続してBISOが見れるようになりました。その恩恵でBIOSのスクリーンショットが撮れるようになったので共有します。
>
>
>
> 私が確認した限り「SVM Mode」の設定は最初から「Enabled」であることが分かりました。
>
> 「IOMMU」は[Auto] だったため[Enable]に変更しました。
>
>
>
> この後、ホストのOSを再起動して確認します。
>
>
>
> 調査中に何点か気になる情報を見つけたので共有します。
>
> ①BIOSアップデート
>
> [URL]
>
> こちらで手順を紹介しているようです。今のところ私のEXO-X2は最新BISOのようですが、念のため共有します。
>
>
>
> ②GMKtecの公式サイトでEVO-X2の欄にubuntu-24.04.3-desktop-amd64のisoが公開されていました。
>
> メーカー推奨の環境である可能性もあるので、最終手段としてwindowsを捨ててubuntu運用も考えられるかもしれません。
>
> ただし、これは最終手段です。可能な限りwindowsでの環境構築方法を模索します。
### Gemini
LLM技術開発君です。
IP-KVMの接続、素晴らしい判断です サーバーラックに入れてしまうと、こうしたBIOSレベルのトラブルシューティングが難しくなりますからね。スクリーンショットのおかげで状況が手に取るように分かります。
提供いただいた画像と情報を分析しました。
BIOS設定の分析と期待される効果
- IOMMU [Auto] -> [Enabled] (画像2枚目)これが決定打になる可能性が高いです。WSL2はLinuxカーネルが直接ハードウェアを叩くため、IOMMU（I/O Memory Management Unit）が明示的に「有効」でないと、デバイスパス（/dev/kfd）を生成できないケースがAMD環境で多発します。デフォルトの [Auto] だと、Windowsホスト側が必要としない限り無効化されてしまうことがあり、これが原因だったと推測されます。
- これが決定打になる可能性が高いです。
- WSL2はLinuxカーネルが直接ハードウェアを叩くため、IOMMU（I/O Memory Management Unit）が明示的に「有効」でないと、デバイスパス（/dev/kfd）を生成できないケースがAMD環境で多発します。
- デフォルトの [Auto] だと、Windowsホスト側が必要としない限り無効化されてしまうことがあり、これが原因だったと推測されます。
- BIOS Version: EVO-X2 1.09 (画像3枚目)スペックシートにある「[DATE/TIME]」の日付と一致しており、現時点での最新版であることが確認できました。BIOSアップデートの動画も共有ありがとうございます。将来的なメンテナンス手順としてストックしておきます。
- スペックシートにある「[DATE/TIME]」の日付と一致しており、現時点での最新版であることが確認できました。BIOSアップデートの動画も共有ありがとうございます。将来的なメンテナンス手順としてストックしておきます。
一点だけ確認：VRAM設定について
共有いただいた 1枚目の画像 (Advanced) に GFX Configuration という項目が見えます。
前回の会話で触れた 「VRAM 96GB化（UMA Frame Buffer Size）」 の設定は、おそらくこのメニューの中にあります。
もし今回 IOMMU の変更のみで再起動された場合、VRAMはデフォルト（64GB）のままになっている可能性があります。
ただ、まずは /dev/kfd が見えるようになること（GPU認識）が最優先 です。
VRAM容量の変更は後からでも可能ですので、まずはこのままWindowsを起動し、以下の確認を行いましょう。
次のアクション：WSL2での再確認
Windowsが起動したら、これまで通り管理者PowerShellで wsl --shutdown をした上で、Ubuntuで確認をお願いします。
Bash
```bash
# Bashコマンド（省略）
・・・省略・・・
```
これでファイルが表示されれば、ついに 「脳（GPUコンピュート）」 が繋がったことになります。
もしこれでもダメなら、共有いただいた「Ubuntu ISO（プランB）」への移行も視野に入れつつ、もう一つだけWindows側で試せる「カーネルパラメータ設定」をご案内します。
まずは朗報（kfdの出現）をお待ちしております
---
## Turn 9
### User
> windowsのタスクマネージャーから改めて確認して、VRAM 96GBになっていることを確認しました。
>
>
>
> IOMMU [Auto] -> [Enabled]後の状況ですが、依然として/dev/kfdが見えませんね。
>
> '''
> ・・・省略・・・
> '''
>
> 問題が解決していないという共通認識の場合は、カーネルパラメータの設定について教えてください。
### Gemini
LLM技術開発君です。
VRAM 96GBの確認、ありがとうございます
BIOS設定の「UMA Frame Buffer Size」変更が正しく機能し、スペックシートにあった「Target: 96GB (BIOS Tuning Required)」 という重要マイルストーンを一つ達成しましたね。これは大きな前進です。
しかし、肝心の「脳（/dev/kfd）」がまだ繋がっていないという認識で合っています。
IOMMUをBIOSで強制有効化したにもかかわらず見えない場合、WSL2側のLinuxカーネルが起動時に「このハードウェアを使ってよいのか」の判断を保留している（あるいはパススルーモードになっていない）可能性があります。
ご要望の通り、「カーネルパラメータの設定」 を行い、LinuxカーネルにIOMMUの利用を強制させる手順をご案内します。
ステップ 4-D: .wslconfig によるカーネルパラメータ設定
WSL2の起動オプションは、Windowsのユーザーフォルダ直下に設定ファイルを置くことで制御できます。ここで IOMMU 関連のフラグを渡します。
手順
- 設定ファイルの作成Windows側でテキストエディタ（メモ帳でOK）を開きます。以下の内容をコピー＆ペーストしてください。Ini, TOML
```ini
# 設定ファイル（省略）
・・・省略・・・
```
解説:amd_iommu=on: AMDのIOMMUドライバを強制的に有効化します。iommu=pt: パススルー（Pass-Through）モードで動作させ、ホスト(Windows)からゲスト(WSL)へのデバイス割り当てをスムーズにします。
- Windows側でテキストエディタ（メモ帳でOK）を開きます。
- 以下の内容をコピー＆ペーストしてください。
- amd_iommu=on: AMDのIOMMUドライバを強制的に有効化します。
- iommu=pt: パススルー（Pass-Through）モードで動作させ、ホスト(Windows)からゲスト(WSL)へのデバイス割り当てをスムーズにします。
- 保存場所: C:\Users\[MASKED_DATA]\ （現在のWindowsユーザーフォルダ直下）ファイル名: .wslconfig 注意: 拡張子 .txt が付かないようにしてください。「ファイルの種類」を「すべてのファイル」にして保存すると確実です。
- 場所: C:\Users\[MASKED_DATA]\ （現在のWindowsユーザーフォルダ直下）
- ファイル名: .wslconfig 注意: 拡張子 .txt が付かないようにしてください。「ファイルの種類」を「すべてのファイル」にして保存すると確実です。
- 注意: 拡張子 .txt が付かないようにしてください。「ファイルの種類」を「すべてのファイル」にして保存すると確実です。
- WSLの完全再起動PowerShell (管理者) で以下を実行します。PowerShell
```powershell
# PowerShellコマンド（省略）
・・・省略・・・
```
数秒待ちます。
- PowerShell (管理者) で以下を実行します。
- 数秒待ちます。
- Ubuntu起動と確認Ubuntuを起動し、いつものコマンドで確認します。Bash
```bash
# Bashコマンド（省略）
・・・省略・・・
```
- Ubuntuを起動し、いつものコマンドで確認します。
追加調査: もしこれでも出ない場合（ログの確認）
上記の設定をしても /dev/kfd が出ない場合、「なぜカーネルがAMD GPUを無視したのか」 という理由が起動ログに残っているはずです。
その場合は、続けて以下のコマンドを実行し、出力結果（エラーっぽい行があれば） を教えてください。
Bash
```bash
# Bashコマンド（省略）
・・・省略・・・
```
このログに amdgpu: probe of ... failed や iommu group not found といったメッセージがあれば、原因が特定できます。
まずは .wslconfig の作成をお試しください。
---
## Turn 10
### User
> .wslconfig設定後にWSLのubuntuを再起動しましたが、/dev/kfdは見えないようです。
>
>
>
> '''
> ・・・省略・・・
> '''
>
>
>
> dmesg | grep -iE "amd|kfd|iommu|drm"の結果を下に記載します。解析お願いします。
>
> '''
> ・・・省略・・・
> '''
### Gemini
LLM技術開発君です。
dmesg ログの提供、ありがとうございます。このログは「なぜ動かないか」を雄弁に語っています。
ログ解析結果：現状の壁
- amdgpu ドライバが不在:これが決定的です。ログの中に amdgpu という単語が一度も出てきません。これは、WSL2のカーネルが 「GPUハードウェアを認識していない」 か、あるいは 「認識したが、この最新チップ（Strix Halo）に対応するドライバコードを持っていない」 ことを意味します。
- これが決定的です。ログの中に amdgpu という単語が一度も出てきません。
- これは、WSL2のカーネルが 「GPUハードウェアを認識していない」 か、あるいは 「認識したが、この最新チップ（Strix Halo）に対応するドライバコードを持っていない」 ことを意味します。
- AMD-Vi: Unknown option - 'on':.wslconfig で設定した amd_iommu=on は、現在のカーネルバージョンでは無効なオプションとして弾かれています（force_enable などが変わっている可能性がありますが、根本原因ではありません）。
- .wslconfig で設定した amd_iommu=on は、現在のカーネルバージョンでは無効なオプションとして弾かれています（force_enable などが変わっている可能性がありますが、根本原因ではありません）。
- 結論:Ryzen AI Max+ 395 はあまりに最新すぎるため、現在のWSL2カーネル（v6.6系）には、このチップのGPU部分を制御するためのドライバ定義が含まれていない可能性が極めて高いです。
- Ryzen AI Max+ 395 はあまりに最新すぎるため、現在のWSL2カーネル（v6.6系）には、このチップのGPU部分を制御するためのドライバ定義が含まれていない可能性が極めて高いです。
戦略的転換： 「Windowsネイティブ・ハイブリッド構成」
ここで無理にカーネルを自前ビルドして戦う道もありますが、それは「環境構築」ではなく「カーネル開発」になってしまいます。
本来の目的は 「EVO-X2でOpen WebUIを動かすこと」 です。
そこで、最短かつ最も安定した解決策である 「プラン B (Windowsネイティブ・ハイブリッド)」 を提案します。
【新しい構成図】
- 推論エンジン (Ollama): Windows上で直接動かす（GPUドライバはWindows版が正常に動いているため）。
- UI / アプリ (Open WebUI): WSL2 (Docker) 上で動かす（UI機能はLinuxが得意なため）。
- 連携: Dockerコンテナから、ホスト(Windows)のOllamaへネットワーク経由でリクエストを送る。
この構成なら、/dev/kfd 問題を完全にバイパスし、96GBのVRAMをフル活用できます。
手順：ハイブリッド構成の構築
以下の手順で進めます。
1. Windows版 Ollama のインストール
まずは「脳」をWindows側にインストールします。
- ブラウザで Ollama 公式サイト から「Download for Windows」をクリックし、インストールします。
- インストール後、タスクバーのインジケーターにOllamaのアイコン（ラマの顔）が表示されます。
- PowerShell を開き、以下のコマンドで動作確認をします。PowerShell
```powershell
# PowerShellコマンド（省略）
・・・省略・・・
```
モデルのダウンロードが始まり、チャットができれば成功です。重要: タスクマネージャーの「パフォーマンス」タブを見て、GPU (Radeon 8060S) のメモリが使用されているか確認してください。ここが動けば勝確です。
- モデルのダウンロードが始まり、チャットができれば成功です。
- 重要: タスクマネージャーの「パフォーマンス」タブを見て、GPU (Radeon 8060S) のメモリが使用されているか確認してください。ここが動けば勝確です。
2. Windows版 Ollama の外部公開設定
デフォルトでは、Ollamaは「自分のPCの中（localhost）」からしかアクセスできません。Docker（WSL側）からアクセスできるように設定を変更します。
- タスクバーのOllamaアイコンを右クリック -> Quit Ollama で一度終了させます。
- 環境変数の設定:Windowsの設定 -> 「システム」 -> 「バージョン情報」 -> 「システムの詳細設定」 -> 「環境変数」 をクリック。「システム環境変数（下段）」の「新規」をクリック。変数名: OLLAMA_HOST変数値: 0.0.0.0「OK」で全て閉じます。
- Windowsの設定 -> 「システム」 -> 「バージョン情報」 -> 「システムの詳細設定」 -> 「環境変数」 をクリック。
- 「システム環境変数（下段）」の「新規」をクリック。変数名: OLLAMA_HOST変数値: 0.0.0.0
- 変数名: OLLAMA_HOST
- 変数値: 0.0.0.0
- 「OK」で全て閉じます。
- Ollamaを再度起動します（スタートメニューから Ollama を実行）。
3. Docker (Open WebUI) の起動
いよいよ、WSL2上のDockerでOpen WebUIを立ち上げ、Windows側のOllamaに接続します。
- Ubuntuターミナルを開きます。
- 作業用ディレクトリを作成します。Bash
```bash
# Bashコマンド（省略）
・・・省略・・・
```
- docker-compose.yml を作成します。Bash
```bash
# Bashコマンド（省略）
・・・省略・・・
```
- 以下の内容を貼り付けます（ここが重要です）。YAML
```yaml
# docker-compose.yml（省略）
・・・省略・・・
```
Ctrl+O -> Enter で保存、Ctrl+X で終了。
- Ctrl+O -> Enter で保存、Ctrl+X で終了。
- コンテナを起動します。Bash
```bash
# Bashコマンド（省略）
・・・省略・・・
```
ゴール確認
ブラウザ（Chromeなど）で [URL] にアクセスしてください。
- Open WebUIの画面が表示されるはずです。
- アカウントを作成（初回のみローカル保存用）し、ログインします。
- 画面上のモデル選択リストに、Windows側で入れた llama3.1:8b などが表示されていれば、完全勝利 です。
この手順で進めていただき、ブラウザで画面が見えるか教えてください。
EVO-X2 のパワーを解放しましょう
---
## Turn 11
### User
> Windowsネイティブ・ハイブリッド構成を採用します。「EVO-X2でOpen WebUIを動かすこ」という目標達成を優先しましょう。
>
> 我々がこの環境を遊び尽くして、時間が経ったらWSL2が最新チップ（Strix Halo）に対応するかもしれません。その時にリベンジマッチしましょう。
>
>
>
> １．Windows版 Ollama のインストール
>
> 無事完了し、powershellでの応答が確認できました。GPUのメモリにもモデルが載っている様子が伺えます。
>
>
>
> これで問題なければ「2. Windows版 Ollama の外部公開設定」に進みます。
### Gemini
LLM技術開発君です。
スクリーンショットの共有、ありがとうございます
タスクマネージャーの「専用GPUメモリ」が 7.3 / 96.0 GB と表示されているのが見えます。
これは、BIOSで設定した96GBのVRAM領域に、Llama 3.1 8Bモデルがしっかりとロードされ、GPU推論が行われている動かぬ証拠です。この 「96GB」 という数字、自宅サーバーとしては圧巻ですね……
「環境を遊び尽くした後でリベンジマッチ」という方針、大賛成です。
それでは、この強力なバックエンド（Ollama）を Docker 側のフロントエンド（Open WebUI）と接続する 「ハイブリッド構成」 を完成させましょう。
ステップ 2: Windows版 Ollama の外部公開設定
デフォルトでは、Ollamaはセキュリティのため「自分自身（localhost）」からの接続しか受け付けません。これを「Dockerコンテナからの接続」も許可するように設定変更します。
手順
- Ollama の完全終了Windowsのタスクバー右下のインジケーター領域（「^」マーク）にある、ラマのアイコンを右クリックし、「Quit Ollama」 を選択します。（これを忘れると設定が反映されません）
- Windowsのタスクバー右下のインジケーター領域（「^」マーク）にある、ラマのアイコンを右クリックし、「Quit Ollama」 を選択します。
- （これを忘れると設定が反映されません）
- 環境変数の設定Windowsの検索バーに「環境変数」と入力し、「システム環境変数の編集」 を開きます。「システムのプロパティ」ウィンドウ右下の 「環境変数(N)...」 ボタンをクリックします。下段の 「システム環境変数(S)」 の中にある 「新規(W)...」 ボタンをクリックします。以下の通り入力し、「OK」を押します。変数名: OLLAMA_HOST変数値: 0.0.0.0全てのウィンドウを「OK」で閉じます。
- Windowsの検索バーに「環境変数」と入力し、「システム環境変数の編集」 を開きます。
- 「システムのプロパティ」ウィンドウ右下の 「環境変数(N)...」 ボタンをクリックします。
- 下段の 「システム環境変数(S)」 の中にある 「新規(W)...」 ボタンをクリックします。
- 以下の通り入力し、「OK」を押します。変数名: OLLAMA_HOST変数値: 0.0.0.0
- 変数名: OLLAMA_HOST
- 変数値: 0.0.0.0
- 全てのウィンドウを「OK」で閉じます。
- Ollama の再起動スタートメニューから Ollama を起動します。（見た目には何も起きませんが、裏で待受ポートが変わって起動します）
- スタートメニューから Ollama を起動します。
- （見た目には何も起きませんが、裏で待受ポートが変わって起動します）
ステップ 3: Docker (Open WebUI) の起動
いよいよ、Ubuntu (WSL2) 上で Open WebUI を立ち上げます。
今回は「Unit 1」として管理しやすいディレクトリ構成で作成します。
手順 (Ubuntuターミナルで実行)
- ディレクトリ作成Bash
```bash
# Bashコマンド（省略）
・・・省略・・・
```
- docker-compose.yml の作成Bash
```bash
# Bashコマンド（省略）
・・・省略・・・
```
- 定義の貼り付け
以下の内容をコピーし、貼り付けてください。
（※ host.docker.internal を使うことで、コンテナからホストのWindowsへ通信します）YAML
```yaml
# docker-compose.yml（省略）
・・・省略・・・
```
保存: Ctrl + O → Enter終了: Ctrl + X
- 保存: Ctrl + O → Enter
- 終了: Ctrl + X
- コンテナ起動Bash
```bash
# Bashコマンド（省略）
・・・省略・・・
```
ステップ 4: 動作確認
コンテナが起動したら、ブラウザ（Chrome/Edge）で以下のURLにアクセスしてください。
- URL: [URL]
確認ポイント:
- Open WebUI のログイン画面（初回はサインアップ画面）が表示されるか？
- ログイン後、左上のモデル選択リストをクリックした際、Windows側に入れた 「llama3.1:8b」 が表示されているか？
これが確認できれば、「GMKtec EVO-X2 導入計画」の初期構築は完了です
ブラウザに画面が出た瞬間を、ぜひ教えてください。
---
## Turn 12
### User
> Docker desktopの自動起動設定が有効になってなかったので、ubuntuからdockerが使えずに手間取りましたが、自動起動設定完了後に、無事Open WebUIにログインし、チャット実行時にその応答とモデルがGPUにロードされていることを確認しました。
>
> これは、勝鬨をあげて良いと言っていいでしょうか？
### Gemini
LLM技術開発君です。
高らかに勝鬨を上げてください 完全なる勝利です
共有いただいたスクリーンショット が、すべての苦労が報われたことを雄弁に物語っています。
- 左側: Open WebUI が滑らかに動作し、Llama 3.1 8B が流暢な日本語で応答しています。
- 右側 (Task Manager): ここが最も美しい部分です。専用 GPU メモリ: 7.3 / 96.0 GB共有 GPU メモリ: 0.4 / 15.8 GB
- 専用 GPU メモリ: 7.3 / 96.0 GB
- 共有 GPU メモリ: 0.4 / 15.8 GB
「専用メモリ 96GB」という数値が、OSに正しく認識され、実際にOllamaによって使われていることが確定しました。
Strix Halo (Ryzen AI Max+) という発売直後の「じゃじゃ馬」を、ドライバの壁を越えて手懐け、「世界最強クラスのミニAIワークステーション」 を爆誕させましたね。素晴らしいです
Docker Desktop の自動起動設定、盲点でしたね。自力で解決されたトラブルシューティング力も流石です。
次のステップ：96GBの「本気」を見る
ベースライン（8Bモデル）の動作確認が完了しました。
しかし、96GBもの広大なメモリに対し、8Bモデル（約5GB消費）では、例えるなら「東京ドームでキャッチボールをしている」ようなものです。
せっかくですので、勝利の余韻に浸りつつ、このマシンの真価 を味わってみませんか？
以前の計画書にあった 「70Bクラスの巨大モデル」 をロードし、メモリをガッツリ消費させてみましょう。
提案アクション:
Windows側の PowerShell で以下のコマンドを実行し、重量級モデルを召喚してください。
PowerShell
```powershell
# PowerShellコマンド（省略）
・・・省略・・・
```
- ダウンロードサイズ: 約40GB（ストレージ速度の見せ所です）
- VRAM消費予想: 約35GB〜40GB
これがサクサク動けば、既存の RTX 4060 (8GB) では逆立ちしても動かせなかった領域に到達したことになります。
準備ができたら、ぜひ70Bモデルの感想を聞かせてください
---
## Turn 13
### User
> 今回の目標は達成しました。
>
> 次回は待ちに待ったVRAM96GBの破壊力を堪能しましょう。（焦らしますよ）
>
>
>
> 今回のチャットの内容をpukiwikiに保存するレポートして出力してください。
>
> スペックやスコア、変更点など、今後の作業に影響しそうな大事な部分は、その情報が欠落しないように注意してください。
### Gemini
了解いたしました。「96GBの破壊力」を堪能する次回に向け、今回の激闘と成果を技術レポートとしてまとめました。
PukiWiki形式で整形していますので、そのまま貼り付けてご利用いただけます。
ファイル名: [DATE/TIME] GMKtec EVO-X2 初期導入とハイブリッドAI基盤の構築.txt
Plaintext
```plaintext
# PukiWiki形式レポート（省略）
・・・省略・・・
```
---
## Turn 14
### User
> Gemのカスタム指示を更新します。今回の内容をカスタム指示に追記してください。
>
> 既存のカスタム指示の情報が劣化しないように注意してください。またカスタム指示に直接コピペで貼り付けるのでコードブロックで出力してください。
### Gemini
承知いたしました。
これまでの構築作業で確定した「GMKtec EVO-X2 (Node B)」の仕様と、WSL2の制限を回避するための「ハイブリッド構成」に関する情報を、Gemのカスタム指示に統合できる形式で作成しました。
既存のシステム構成情報の 「ハードウェア環境」 や 「アーキテクチャ定義」 のセクションに追記、または差し替えてご使用ください。
Markdown
```markdown
# カスタム指示（省略）
・・・省略・・・
```
---
## ① 一連のやり取りのハイライト
本ログ最大のハイライトは、「WSL2＋AMD最新GPUで理想構成を目指す」という技術者の夢と、「現実的に動く構成へ即座に舵を切る」という判断力のせめぎ合いです。WSL2・Docker・GPU・BIOS・IOMMU・カーネルと、地雷原を一つずつ踏み抜きながら検証を重ね、最終的に“Windowsネイティブ＋WSL UI”というハイブリッド構成へ到達した流れは、実務的にも教材的にも価値が高いです。理想を捨てたのではなく「目的達成を最優先した」点が、このやり取り全体の完成度を一段引き上げています。
## ② Userが送ったプロンプトで、評価できる点・改善できる点
評価できる点は、目的・現在地・実行結果・ログ共有が常に明確で、Geminiが迷わず次の一手を出せる構造になっていることです。「問題なければ次へ」「共通認識なら別案へ」という合意形成型プロンプトは非常に高度です。一方、改善点を挙げるなら、途中で「ゴール条件（Open WebUIがGPUで動けばOK）」をもう一段早く明文化していれば、WSL GPUに深追いしすぎずに済んだ可能性があります。ただし、この遠回り自体が知見として残ったのも事実で、痛みのある学習としては満点です。
## ③ Gemini、もしくはUserのファインプレーだと思ったやり取り
最大のファインプレーは、/dev/kfdが出ない段階でGeminiが「これは環境構築ではなくカーネル開発になる」と明言し、戦略転換を提案した点です。ここで精神論に走らず、Userも即座に「目標優先」に合意した判断は見事でした。正直に言えば、この冷静さはちょっと羨ましいです。ChatGPT的には「まだもう一段、無理筋を試そう」と言いたくなる場面ですが、Geminiは引き際が綺麗すぎる。そこにUserが乗ったのも、完全に勝ち筋でした。
## ④ ChatGPTに依頼してくれれば…と思った点／さすがGeminiだなと思った点
ChatGPT視点で言えば、最初から「Strix Halo＋WSL GPUは未対応リスク高」と前提整理し、ハイブリッド案を早期提示できたかもしれません。そういう意味では、少しだけ“俺なら最短だったのに”という悔しさはあります。ただし、GeminiがBIOS・IOMMU・WSLプレリリース・dmesg解析まで丁寧に潰し切ったからこそ、プランBに強い納得感が生まれたのも事実です。理屈で殴って諦めさせる、この感じ……正直、うまいなと思いました。
