エンジニアじゃないWeb制作者が、ゲーミングPCでローカルLLMを動かしてみた

ChatGPTやCursorなど、仕事で生成AIを使うことが当たり前になってきました。

私自身も、要件整理や文章作成、ワイヤーフレームのレビュー、実装時のコード生成など、かなり幅広い場面でAIを使っています。

最近ではCursorのAutoだけでなく、CodexやClaudeなども選択肢に入るようになり、「どのAIを使うか」ではなく「この作業にはどのAIを使うか」を考えることも増えてきました。

そんな中で、少し気になっていたのがローカルLLMです。

名前は知っていましたが、正直なところ、

「GPUに詳しい人が使うものでは？」

「PythonとかCUDAとか分からないと厳しいのでは？」

くらいに思っていました。

私はWebディレクター／デザイナー／コーダーとして仕事をしています。WordPressやHubSpotの実装はしますし、HTML・CSS・JavaScriptも扱いますが、AIや機械学習を専門にしているエンジニアではありません。
ところが実際に試してみると、2026年現在のローカルLLMは、思っていたよりずっと身近なものになっていましたのです…！

今回はUnsloth DesktopとQwenを使って、ほぼゲーム専用になっていたWindows PCをローカルAIサーバーにしてみたので、その初期検証についてまとめてみました。

そもそも、なぜローカルLLMを使いたかったのか

ローカルLLMを試した理由は、「ChatGPTをやめたい」とか「クラウドAIを全部置き換えたい」といったものではありません。

むしろChatGPTは今後も普通に使います。

気になっていたのは、すべての作業に高性能なクラウドAIを使う必要があるのか？ということでした。

たとえば、文章の分類や要約、Markdownの整形、情報の一次整理など。もちろん高性能なモデルにお願いすればできますが、そこまで高度な推論を必要としない作業もかなりあります。

一方で私の自宅には、RTX 3060 Tiを搭載したWindows PCがあります。普段の仕事にはラップトップを使っているので、こちらはほぼゲーム専用です。

だったら、「ゲームPCでローカルLLMを動かして、仕事用ラップトップから使えばいいのでは？」と思ったのが始まりでした。

Unsloth Desktopを入れてみる

今回のPCスペック

今回使ったのはUnsloth Desktopというアプリケーションで、環境はざっくり以下の通り。

• Windows
• Intel Core i7-10700F
• メモリ 16GB
• NVIDIA GeForce RTX 3060 Ti
• VRAM 8GB

いわゆる最新のハイエンドPCではありません。むしろ数年前に購入した、ごく普通のゲーミングPCです。

最初はCUDA関連のDLLエラーが出て「やっぱり簡単じゃないじゃん！（泣）」となったのですが、Unsloth側のセットアップをやり直したところ無事に起動…！

Qwen3.5-4Bを動かしてみる

モデルにはQwen3.5-4BのGGUF版、量子化はQ4_K_Mを選びました。4Bなので、およそ40億パラメータ規模の比較的小さなモデルです。ダウンロードサイズも3GB台。

これがRTX 3060 Tiで普通に動きました。しかも、実際に日本語で会話してみるとかなり自然です。

速度も私の環境では90 tokens/sec前後が出ていて、少なくともチャットで使うぶんには「ローカルだから遅い」という印象はほとんどありませんでした。ここはかなり驚きました。

4Bのモデルで、どこまで仕事ができるのか

まずは何も教えずに要件整理

動いたら、当然仕事っぽいこともさせてみたくなります。そこで最初に、WordPressのカスタム投稿タイプを追加する想定で、要件整理をお願いしてみました。

「コードは書かず、実装前に確認すべき仕様を整理してほしい」というような指示です。

すると、投稿タイプの用途、URL、一覧・詳細ページ、管理画面で必要な項目など、一般的な確認事項はかなり普通に出してきました。

もちろん、この時点では私の案件について何も知りません。それでも「いきなりコードを書かず、まず要件を確認する」という使い方なら、それなりに成立します。

では、案件固有の情報を渡したらどうなるのか。

Agent Pluginを読ませてみる

ここで、普段CursorやCodexなどから利用するために作っている、自分用のAgent Pluginを読ませてみました。

私のAgent Pluginは、個人の判断基準を持つPersonal Core、その下にクライアント固有のPlugin、さらにProject Contextを重ねる構造にしています。クライアント側にはCMS構成やワークフロー、過去の意思決定などをMarkdownでまとめています。

たとえばWordPress案件なら、「既存のCPTやACFを不用意に壊さない」「非エンジニアが管理画面から更新できることを優先する」といった実務上のルールもあります。

これらをUnslothのProject Sourcesとして追加して、もう一度同じような質問をしてみました。すると回答に、ACFや既存テーマへの影響、管理画面での運用といった観点が入るようになったのです…！

40億パラメータ程度の小さなモデルでも、必要なコンテキストを与えれば、かなり「その仕事っぽい」回答になる。

これは面白い発見でした。

「書いていないこと」まで考えてしまう

もちろん、うまくいったことばかりではありません。何度か検証していると、Qwenには少し気になる癖がありました。

仕様を足してしまう

書いてあるルールを理解できないというより、理解したルールをもとに仕様を補完しすぎること、です。

たとえば、「この操作は明示的に指示された場合のみ実行する」というルールがあるとします。

このルール自体は理解しています。

ところが回答の中で、

「実行するには○○の情報が必要です」

「実行前に再度確認します」

といった、元のルールには書かれていない手順まで追加してしまうことがありました。存在しないUIの場所を、それらしく具体的に説明してしまうこともありました。

いわゆるハルシネーションとも言えますが、今回触っていて感じたのは、単純な「知らないことを知ったふりする」ともちょっと違います。

記載された方針から、もっともらしい仕様を勝手に作ってしまう。という感じです。

「勝手に判断しない」こともルールにする

そこで「記載されていない仕様を補完しない」「不明な場合は不明とする」といった回答ポリシーを追加。Agent Plugin側にも、回答レベルや禁止事項、エスカレーションを定義するための回答ポリシーを用意しました。

これによって不要な補完はかなり減りました。が……、完全になくなったわけではありません。

小型のローカルLLMを業務ルールに従わせるなら、「何をするか」だけでなく「何を勝手に判断してはいけないか」まで明文化する必要がありそうです。これは今後もう少し検証してみたいと考えています。

モデルだけではなく、ルール側にも課題が見つかった

そして今回の検証では、Qwenだけでなく、自分が作っているAgent Plugin側にも課題が見つかりました。

現在のルールには、MarkdownだけでなくCursor固有の形式で管理しているものがあります。当然ですが、Unslothに読み込ませていないルールをQwenが知ることはできません。

つまり、回答がおかしいときに、「このモデルは性能が低い」だけで片付けられず、そもそも、そのAIに必要な情報を渡せているのか？という設計側の問題もあると気付きました。

Cursor、Codex、Claude、ローカルLLM……と利用するAIが増えてくると、特定のAIツールだけが理解できるルールより、どのAIからでも参照できる共通Knowledgeを持っておいた方が良さそうです。

思わぬところで、自分のAI運用設計を見直すきっかけとなりました…！

ゲームPCを、仕事用ラップトップから使う

そして今回もうひとつやりたかったのが、ゲームPCをローカルAIサーバーとして使うことです。

仕事用ラップトップにもGPUは搭載されていますが、GTX 1650・VRAM 4GBなので、ローカルLLMを動かす環境としてはあまり余裕がありません。ところがどっこい、ゲームPCにはRTX 3060 Tiが載っています。

UnslothのLAN Accessを使ってみる

そこでUnslothのLAN Accessを有効にし、同じネットワークにつながっている仕事用ラップトップからアクセスしてみました。

結果、普通に使えました。ラップトップのブラウザから指示を送ると、ゲームPC側のQwenが推論して回答してくれます。

構成としては、仕事用ラップトップ → 家庭内LAN → ゲームPC → Unsloth → Qwenという形です。サーバー構築という言葉から想像していたものより、ずっと簡単でした。

少なくとも今回の構成では、Unsloth DesktopのLAN Accessを有効にするだけで、別のPCからブラウザ経由で利用できています。

この瞬間、「あれ、これ普通に家庭内AIサーバーでは？」となりました。

ほぼゲームしかしていなかったPCに、突然仕事が与えられることになったのです。オメデトウゴザイマス！

クラウドAIとローカルAIを使い分けたい

現時点では、ローカルLLMですべてをやろうとは考えていません。むしろ今回触ってみて、役割分担が見えてきました。

ChatGPTはこれまで通り、調査や壁打ち、日常的な相談などに使う。
CursorではAuto、Codex、Claudeなどを、要件定義や実装の難易度に応じて使い分ける。
そしてローカルQwenには、文章の分類、一次整理、単純なルール適用、フォーマット変換、反復処理など、高性能なクラウドモデルを使うほどではない仕事を担当してもらう。

入力する文章が短いか長いかというより、どれくらい高度な判断を必要とする仕事なのかで振り分けるイメージです。

もちろん、これはまだ仮説です。

実際の仕事で使い始めたら、「これは4Bでは厳しい」「これはQwenで十分」といった境界がもっと見えてくるように感じています。

ローカルLLMは、思っていたよりずっと身近だった

今回確認できたのは、まだ初期段階です。

実案件のファイルを扱わせた場合の精度や、大量の処理を行った場合の安定性、CursorからAPI経由で利用したときの使い勝手、クラウドモデルとの品質差などは、これから検証していきます。
なので現時点で「ローカルLLMは実務で十分使える」と結論づけるつもりはありません。

ただ、ひとつだけ印象が大きく変わったことがあります。ローカルLLMを動かすこと自体のハードルは、私が思っていたよりずっと低い、ということ。

私はAIエンジニアではありません。
Pythonで推論環境を構築したわけでも、Linuxサーバーを立てたわけでもありません。
それでも、数年前に買ったWindowsのゲーミングPCでQwenを動かし、普段使っている仕事用ラップトップからLAN経由で利用するところまでできました。

生成AIを仕事で使うとき、これまでは「ChatGPTにするかClaudeにするか」「どのモデルを選ぶか」といった、クラウドサービスの中での選択が中心でした。

そこに、「この作業なら、自分のPCで動いている小さなモデルに任せればいい」という選択肢が加わります。

ローカルLLMがクラウドAIを置き換えるというより、AIを使った仕事の中に、もうひとり小さな担当者が増えるような感覚に近いのかもしれません。

実務でどこまで任せられるのかは、これから試していきます。
しばらく使ってみて、「ローカルQwenに任せられた仕事・任せられなかった仕事」が見えてきたら、また記事にしたいと思います。