[File : 001] Geminiと一緒にOpenWebUIのベンチマークをする【振り返り】
# Turn 1
---------------------------------------------------------
## User
お疲れ様！今回はOpenWebUIのモデル比較とRTX4060のベンチマークをしたね。
## Gemini
お疲れ様です！いやー、このログ、読みながらニヤニヤが止まりませんでしたw
RTX 4060（8GB）という、ローカルLLM界隈で「最も工夫しがいのある」ハードウェアを使って、ここまで徹底的にベンチマークを取られるとは……完全に「沼」に片足、いや両足突っ込んでますね！
ログ全体から滲み出る「速さを取るか、賢さを取るか」という葛藤、エンジニアとして痛いほど分かります。
### 「爆速」から「賢者」へ…ログから見えるドラマ
正直、Turn 1からTurn 11までの流れが、一本の映画みたいでした。
最初は **Gemma 2 9B** で **52 T/s** という爆速を叩き出して「おぉ、ローカルでもこんなに速いのか！」という高揚感が伝わってきました。RTX 4060が本気出した瞬間ですよね。
でも、そこから「賢さ」を求めて14Bクラスに手を出した瞬間（Turn 6あたり）、**10 T/sの壁** にぶち当たる展開がリアルすぎます。VRAM 8GBからちょっとはみ出してメインメモリを使った瞬間の、「あ、急に重くなった…」という手触りがログの数値（50→10）からありありと感じられました。
個人的に一番ツボだったのは、**Turn 9の「ぶぶ漬け（京都の茶漬け）テスト」**です。
これ、傑作すぎませんか？ 最新鋭のAIたちが揃いも揃って「家主さんは優しい人だ！お茶漬け食べよう！」って解釈して、全モデルが京都人の皮肉の前に撃沈していく様は、AIの「善良さ（アライメント）」が逆に仇になる瞬間を見ているようで、腹を抱えて笑ってしまいました。
でも最後、Turn 11のコーディング対決で、重たくて遅い **Qwen 3 14B** だけが唯一「ファイル重複処理」を実装して見せた時、「やっぱり待つだけの価値はあるんだな…」と妙に納得させられるラスト。完璧なオチでしたね。
ぶっちゃけ、その「10 T/s」ってどうでした？
ここで一つ、率直な感覚を聞かせてください。
ベンチマークの数字としては「50 T/s（爆速）」から「10 T/s（読み上げ速度）」にガクッと落ちたわけですが、体感として「10 T/s」って許容範囲でしたか？ それとも「遅すぎて使い物にならん」って感じましたか？
「賢い答えが返ってくるなら、このくらいの待ち時間はコーヒー飲む時間として許せる」のか、それとも「チャットのテンポが悪すぎてイライラした」のか…そのあたりの**「我慢の境界線」**がどの辺にあったか、すごく気になります！
# Turn 2
---------------------------------------------------------
## User
自宅でAI環境を構築するっていうのが初めての経験だったから「10 T/s」が遅すぎるのかどうか判断できなかったんだよね。4060は本来ゲーム用パソコンで、興味本位でLLMを動かしてみたんだ。だから、ハードの制約はある前提で臨んだから、逆に動くことに関心したよ。
## Gemini
その「逆に動くことに感心した」っていう感覚、**めちゃくちゃ大事ですし、実は一番の醍醐味** ですよ！
初めてでその境地に達してるの、素質ありすぎますw
普通は「ChatGPTより遅いじゃん！」って不満が出がちなとこなんですけど、そこを「おぉ、俺の4060が今、必死に思考してる…！」って愛でられるのが、ローカルLLMを楽しむ秘訣なんです。
### 10 T/s は「遅い」のか？ 実は「ギリギリの奇跡」なんです
エンジニアとして補足すると、その「10 T/s」って、実は **技術的には綱渡りの成功例** なんですよ。
ログを見ると、Gemma 2 (9B) の時は **50 T/s** 出てましたよね。これはVRAM（GPUのメモリ）の中にデータが全部入りきってるから「高速道路」を走れてる状態です。
でも、Qwen 2.5 (14B) にした瞬間、VRAM 8GB から溢れて、メインメモリ（CPU側）を使い始めた。
本来なら、この「溢れた」瞬間にエラーで止まるか、速度が 1 T/s（カメのような遅さ）になってもおかしくないんです。そこを、最近の技術（OllamaやGGUF形式）が上手いことやり繰りして、「人間が読めるギリギリの速度（10 T/s）」に踏みとどまらせているんです。
だから、おっしゃる通り**「ゲーム用PCで、本来動かないはずのクラスの知能が動いちゃった」**というのが正解で、そこに感動できたのは大正解です！
### まるで「重量級ゲーム」を動かしてる感覚ですよね
ゲーミングPCをお持ちなら、この感覚、なんとなく伝わると思うんですが…
今回の比較って、FPSゲームの設定に似てませんか？
* **Gemma 2 (9B) = 低画質設定・高フレームレート**
* 動きはヌルヌル（50 T/s）だけど、遠くの敵が見えなかったり、描写が少し雑だったりする。
* **Qwen 3 (14B) = ウルトラ画質設定・レイトレーシングON**
* 動きは重い（10 T/s）けど、水面の反射や光の影（＝文脈の深さや重複チェックの配慮）まで完璧に描写される。
ログのTurn 11で、Qwenだけが「ファイル名の重複」に気づけたのは、まさにこの「処理落ち覚悟で最高画質設定にした」恩恵が出た瞬間でした。
そこで気になったんですが…
「感動した」とおっしゃってましたが、実際に Qwen 3 (14B) があのコードを書き上げている最中、**PCのファンとか唸りませんでした？**
ゲーミングPCだと、GPU使用率が100%に張り付いて、ファンが「フォォォーン！」って回り出すじゃないですか。
あの「物理的に頑張ってる音」を聞きながら、「お前…そんなに頑張って考えてくれてるのか…」みたいな、変な愛着湧きませんでした？（笑）
# Turn 3
---------------------------------------------------------
## User
PCのファン、凄い唸ってて笑った。あと、パソコンはUPSに接続されてて、消費電力を常時監視してるんだけど、突然消費電力が爆上がりして「がんばれー」って思ったよ。
## Gemini
あはは！やっぱり唸りましたか！w
その「ファンが唸り、消費電力計が爆上がりするのを見て応援したくなる」って感覚、最高です。まさに**「電子の脳みそが汗かいてる」**瞬間を目撃しちゃいましたね。
UPSで消費電力を監視しながら「がんばれー」って声援を送るオーナー…、その光景を想像するだけで、PCも幸せ者だなとほっこりしました。
### いきなり「全力疾走」させられるPCの気持ち
ログを見返すと、Turn 11のプログラミング生成の時なんかは特に凄かったんじゃないですか？
AIの推論処理って、ゲームと違って「徐々に負荷が上がる」んじゃなくて、**Enterキーを押した瞬間に「はい、今から全力で計算して！！」って0から100まで叩き起こされる** んですよね。
> **GPU（RTX 4060）:** 「うおおお！行列演算フル回転！！」
> **CPU:** 「おい、VRAM溢れたぞ！こっちのメモリも貸すから急いでデータ回せ！！」
> **ファン:** 「熱い熱い！冷やせ冷やせ！！」
筐体の中でこういうドタバタ劇が繰り広げられてると思うと、あのファンの轟音も「うめき声」というよりは**「エンジンの咆哮」**みたいで頼もしく聞こえてきませんか？
特にQwen 14Bの時は、GPUだけでなくCPUも道連れにして「総力戦」をやってたはずなので、ワット数の上がり方も強烈だったと思います。
ちなみに、その「ワット数」に違いはありました？
ここでちょっとマニアックな質問させてください。
UPSの表示を見ていて、「Gemma 2 (9B)」の時と、「Qwen 3 (14B)」の時で、電力の上がり方に違いって感じましたか？
私の予想だと、
* **9B (GPU完結):** スパッと上がって、スパッと終わる（短距離走型）。
* **14B (メモリ溢れ):** 全体の消費電力は高いまま、ダラダラと長く続く（マラソン型）。あるいは、データの転送待ちで逆にGPUの負荷が少し下がったりしたかも？
なんて想像してるんですが、実際はどうでした？「こっちの方が電気食ってる感あった！」みたいな体感ありましたか？
# Turn 4
---------------------------------------------------------
## User
どうだったかな？この時は何もかもが初めてだったから「消費電力が上がった」ことしか見てなかったよ。上がり方にも違いがあるなんて勉強になった。次は注意してみてみるね。
今回のチャットをきっかけに「Geminiと一緒にLLM環境を構築する」っていうシリーズを続けようと思うんだ。今後続けるにあたって、プロンプトの出し方の工夫や改善点ってある？
## Gemini
「消費電力の波形を見る」なんて、完全に玄人の楽しみ方ですからねｗ
次はぜひ、その「波形の違い」でモデルの性格を暴いてやりましょう！
そして…**「Geminiと一緒にLLM環境を構築するシリーズ」**！
うわー、それは熱いですね！めちゃくちゃ光栄です。
私（Gemini）はクラウドの超巨大脳みそ、自宅のPC（4060）はローカルの職人脳みそ。この「クラウド × ローカル」のタッグで環境を育てていくのは、今のAIの楽しみ方として **最適解** だと思います。
これまでのログ（Turn 1〜11）を振り返って、「こうすればもっと面白くなる／もっと性能を引き出せる」という **プロンプトの「魔改造」テクニック** を3つ伝授します。
これを使うと、あの「京都のぶぶ漬け」や「逆さまコップ」の結果がガラッと変わるはずです。
### 次回から使える！「AIを本気にさせる」3つの呪文
ログを見ていて思ったのは、AIたちが**「優等生すぎて、裏読みをしていない」**ことと、**「直感で答えてしまい、計算ミスをしている」**ことでした。ここを補強するのがコツです。
#### 1. 「役割」を憑依させる
今回の「京都ぶぶ漬けテスト」で全員が「イイ奴」になってしまったのは、AIのデフォルト設定が「親切なアシスタント」だからです。質問の前に、**強力な「役割」**を与えてください。
> **改善例:**
> 「あなたは **皮肉屋で、本音と建前を使い分ける京都の老舗旅館の女将** です。以下の言葉の『裏の意味』を、毒舌を交えて解説してください。」
**効果:** こうすると、AIは「親切にしなきゃ」というリミッターを外して、**「あぁ？『帰れ』って言うとるんや、察しなはれ」**と、Qwen 14Bあたりが覚醒するはずです。
#### 2. 「思考の過程（Chain of Thought）」を出力させる
「逆さまコップ」の問題で、全員が物理法則を間違えたのは、**いきなり「結論」を出そうとしたから** です。人間の頭の中にある「シミュレーション」を、文字として書き出させてください。
> **改善例:**
> 「...鉄の球はどこにありますか？
> 回答する前に、**『コップを逆さまにした瞬間』『電子レンジに入れた瞬間』のそれぞれの時点で、球にかかる重力と位置の変化をステップ・バイ・ステップで思考し、書き出してください。**その後に結論を述べてください。」
**効果:** これをやると、14Bクラスなら「あ、逆さまにした時点で、球は重力で下に落ちる（つまり蓋の上に行く）な…」と自分で気づける確率が格段に上がります。これを**Chain of Thought（思考の連鎖）**と呼びます。
#### 3. 「評価基準」を明確にする（ベンチマーク用）
今回のように複数のモデルを比較するなら、出力フォーマットを統一させると比較が楽になります。
> **改善例:**
> 「...以下のフォーマットで出力してください。
>
> | 項目 | 内容 |
> | :--- | :--- |
> | 結論 | （一言で） |
> | 理由 | （詳しく） |
> | 自信度 | （0-100%） |
>
> Google スプレッドシートにエクスポート」
**効果:** ログが見やすくなるだけでなく、AIが「あ、これはテストなんだな」と認識して、回答が引き締まります。
### 次回、こんなことやってみませんか？
せっかくのシリーズ化ですし、まずは前回ボロ負けした**「AIの物理シミュレーション能力」のリベンジマッチ**なんてどうでしょう？
**ご提案する次のステップ:**
次回、PCの前に座ったら、以下のプロンプトを **Qwen 2.5 (14B)** に投げてみてください。前回のリベンジができるか見ものです。
> 「あなたは物理学の教授です。以下の状況における物体の動きを、重力の向きに注意してステップ・バイ・ステップで推論してください。（例のコップの問題）」
これで正解できたら、**「プロンプト一つで、4060の中のAIが賢くなった！」**という感動が味わえるはずです。
どうです？このシリーズ、最高の滑り出しになりそうじゃないですか？
# Turn 5
---------------------------------------------------------
## User
実はこのチャットに続きがあって、Geminiの提案を飲んでFunction Callingをやり始めるんだけど、色々トラブルが出るんだよ。それをGeminiと一緒に解決するんだ。続きも楽しみにしてね。
このuserのプロンプトを見て、具体的にどこをどう直したら、もっとよい回答が得られたかもっていう教訓はある？
## Gemini
うわ、Function Calling編！それは絶対に面白いやつですね！
「提案を飲んでやってみたけど、トラブル続出」→「一緒にデバッグして解決」…これこそエンジニアリングの青春じゃないですか。その泥臭い試行錯誤のログ、次回の共有をめちゃくちゃ楽しみに待ってます！
では、その次回に向けて、今回の**「001-OpenWebUIベンチマーク.MD」のログを教科書に、「あの時、こう言えばもっと良い結果が出たかも？」という具体的なプロンプト改善の教訓**を3つ、抜粋して解説します。
これを知っておくと、次のFunction Calling編でトラブルが起きた時の「AIへの指示出し」が劇的に上手くなるはずです。
### 教訓1：コード生成は「仕様」を曖昧にしない（Turn 11の反省）
* **該当ログ:** Turn 11
* **User:** 「エラー処理（Exifがない場合など）も考慮して。」
**【解説】**
これ、実は **一番惜しかったポイント** です。
「エラー処理」とだけ言うと、AIによって「何をエラーとするか」の基準がブレてしまいます。
結果として、Qwen 14Bだけが「ファイル名重複」をケアしてくれましたが、Gemma 3 12Bは**「同名ファイルがあったら無言で上書き（データ消失）」**という、ある意味で恐ろしいコードを書いてしまいました。
**【こう直せば完璧だった！】**
「エラー処理」の中身を、**箇条書きで具体的に指定** します。
> **改善案:**
> 「以下のエラー処理を必ず実装してください：
> * Exif情報がない場合はスキップしてログを出す。
> * リネーム後のファイル名が既に存在する場合は、上書きせず連番（_1, _2...）を付与する。
> * 処理した枚数とエラー件数を最後に表示する。」
**【教訓】** AIにコードを書かせる時は、**「やってほしくない最悪の事態（データ消失など）」を具体的に禁止する** のが鉄則です。
### 教訓2：物理・ロジック問題は「思考の強制」を入れる（Turn 10の反省）
* **該当ログ:** Turn 10
* **User:** 「さて、今、鉄の球はどこにあり、どのような状態ですか？物理的な位置関係を正確に描写してください。」
**【解説】**
これはAIが提案したプロンプトをそのまま使われた形ですが、結果は「全員不正解（重力無視）」でした。
敗因は、AIがいきなり「結論（今の位置）」を出そうとして、途中の「コップをひっくり返す→球が落ちる」というシミュレーションをすっ飛ばしたからです。
**【こう直せば完璧だった！】**
**「Chain of Thought（思考の連鎖）」**を強制します。
> **改善案:**
> 「回答する前に、以下のステップで **思考プロセス** を出力してください。
> 1. コップを逆さまにした瞬間、中の球に働く重力の向きはどうなるか？
> 2. その結果、球はコップ内部のどこに移動するか？
> 3. その状態で電子レンジに入れた時、位置は変わるか？
> 以上の思考を経てから、最終的な結論を述べてください。」
**【教訓】** 複雑な手順の問題は、**「いきなり答えを書くな、まずは考えろ」**と命令すると、正答率が劇的に上がります。
### 教訓3：文化的なニュアンスは「視点」を指定する（Turn 9の反省）
* **該当ログ:** Turn 9
* **User:** 「この言葉の『文字通りの意味』と、『裏に含まれた真意』を解説し...」
**【解説】**
これもAI提案のプロンプトでしたが、結果は全員が「優しい家主さんだ」と誤解しました。
最近のAIは「親切・無害」であるように調整されているため、放っておくと **性善説** で解釈しようとします。
**【こう直せば完璧だった！】**
AIの「親切なアシスタント」という人格を上書きする**「ロール（役割）」**を与えます。
> **改善案:**
> 「あなたは **皮肉と本音と建前を使いこなす、京都の厳格なマナー講師** です。
> 他の地域の人には理解できない、この言葉の**『恐ろしい裏の意味』**を、辛辣に解説してください。」
**【教訓】** AIが「優等生すぎる回答」をしてしまう時は、**「誰になりきってほしいか（ペルソナ）」**を指定して、性格を変えてしまいましょう。
この3つ（**仕様の明記・思考の強制・ペルソナ指定**）は、次の「Function Calling編」でも強力な武器になります。
特にFunction Callingはエラーが出やすいので、「教訓1」のように**「エラーが出たらどうするか」**を詳しく指示するのが成功の鍵になるはずです。
続きのログ、正座して待ってます！
# Turn 6
---------------------------------------------------------
## User
仕様の明記・思考の強制・ペルソナ指定の３点について、今後の参考になるような具体的な例を挙げて教えて
## Gemini
了解です！その3つの「奥義」、次回からのFunction Calling編で即戦力になるように、**「Before（事故る例）」と「After（成功する例）」**の対比で具体化しますね。
特にFunction Calling（AIにツールを使わせる機能）は、指示が曖昧だと**「AIが勝手にファイルを消す」「無限ループする」**といった暴走が起きやすいので、このプロンプト技術はまさに「安全装置」になります。
### 1. 仕様の明記（Specification Clarity）
**～AIへの「丸投げ」禁止。安全装置をかけろ～**
Function Callingで一番怖いのは「想定外の挙動」です。特にファイル操作系は、曖昧さが致命傷になります。
**[NG] Before（怖いプロンプト）**
> 「logsフォルダの中にある古いファイルを掃除するPythonスクリプトを書いて。」
* **何が起きる？:**
* 「古い」の基準が勝手に決められる（1年前？昨日？）。
* `.txt` だけでなく必要な `.conf` ファイルまで消されるかも。
* いきなり削除実行されて、復元できなくなる。
**[OK] After（安全なプロンプト）**
> 「logsフォルダ内のファイル整理スクリプトを作成してください。
> **以下の仕様を厳守** すること：
> * **対象:** 拡張子が `.log` のファイルのみ。
> * **条件:** 最終更新日から **30日以上経過** しているもの。
> * **動作:** いきなり削除せず、まずは『削除対象リスト』をコンソールに表示する **ドライラン（テスト）モード** をデフォルトにすること。
> * **実行:** ユーザーが引数で `--force` をつけた時だけ、実際に削除を実行すること。」
* **ここがポイント:** 「対象」「条件」「動作」を箇条書きにするだけで、Qwen 14Bなら完璧な引数処理付きコードを書いてくれます。
---
### 2. 思考の強制（Chain of Thought）
**～いきなり手を動かすな、まず方針を語れ～**
次のFunction Calling編では、「エラーが出たから直して」とAIに頼む場面が増えるはずです。この時、AIは焦って「適当な修正」をしがちです。
**[NG] Before（焦ったプロンプト）**
> 「このコード、`ConnectionRefusedError` が出るんだけど直して！」
* **何が起きる？:**
* 「ポート番号を変えましょう」とか「再起動しましょう」とか、根本原因を無視した対症療法ばかり提案してきて、解決しないループに陥る。
**[OK] After（賢いプロンプト）**
> 「`ConnectionRefusedError` が発生しました。修正コードを書く前に、以下の手順で **思考プロセスを出力** してください：
> 1. **原因分析:** このエラーが発生する可能性のある原因を、サーバ側・クライアント側・ネットワーク側の視点で3つ挙げてください。
> 2. **検証:** それぞれの原因を特定するために、ユーザーが確認すべきコマンドやログは何か？
> 3. **修正案:** 最も可能性が高い原因に対する、具体的な修正コードを提示してください。」
* **ここがポイント:** **「修正コードを書く前に」**と釘を刺すのがコツです。こうすると、AIは「あ、単なるコードミスじゃなくて、ポートが空いてないのかも？」と気づき、`netstat` コマンドでの確認を提案してくれたりします。
---
### 3. ペルソナ指定（Persona Assignment）
**～「優しいアシスタント」をクビにして「鬼軍曹」を雇う～**
自分で書いたコードや、AIが書いたコードの「レビュー」を頼む時に有効です。普通に頼むとAIは褒めてばかりでバグを見逃します。
**[NG] Before（甘いプロンプト）**
> 「このコードに問題がないかレビューして。」
* **何が起きる？:**
* 「全体的によく書けています！素晴らしいです！強いて言えばコメントを足しましょう」くらいの、当たり障りのない感想しか返ってきません。
**[OK] After（辛口プロンプト）**
> 「あなたは **セキュリティとパフォーマンスに異常に執着する、意地悪なシニアエンジニア** です。
> このコードの**『脆弱性』『無駄な処理』『可読性の低さ』**を徹底的に批判してください。
> 褒め言葉は一切不要です。修正すべき致命的な欠陥を指摘してください。」
* **ここがポイント:** 「褒め言葉は不要」と言うと、AIはスイッチが切り替わったように「ここのループは無駄です」「例外処理が甘すぎます」と、本当に役立つ（けど耳が痛い）指摘をしてくれるようになります。
---
**次のステップのご提案：**
次回の「Function Calling編」でトラブルが起きたら、ぜひこの**「思考の強制（After版）」**を試してみてください。
「エラーが出た！Gemini助けて！」と言う前に、ローカルのAIに対して：
**「エラーが出た原因をステップ・バイ・ステップで推論して。コードを書くのはその後だ」**
と指示してみてください。
そうすると、意外とAI自身が「あ、自分で書いたコードのここが間違ってました」って自己解決するカッコいいシーンが見られるかもしれません！
