DUNQR Lab
Codexの利用制限が気になったので、ローカルLLM開発環境を作ってみた
CodexやChatGPTの利用制限を意識しながら、VS Code、Git、WordPress Studio、Ollama、Continueを使ってローカルLLM開発環境を作った実験ログです。DUNQRのWordPressテーマをローカルLLMに読ませるところまで試しました。
DUNQR Labでは、DUNQR本体の制作過程や、AIを使った個人開発、WordPress構築、創作、運用まわりの実験を記録しています。
今回は、DUNQRのWordPressサイト制作や、日々のWordPress開発にも使えそうなローカルLLM環境を作ってみた記録です。
ローカルのデスクトップPCに、VS Code、Git、WordPress Studio、Ollama、Continueを入れて、DUNQRのWordPressテーマをローカルLLMに読ませるところまで試しました。
最終的には、VS Code上で開いている front-page.php をローカルLLMに読み込ませ、日本語で要約してもらうところまで成功しました。
ローカルLLM環境を作ろうと思った理由
DUNQRのサイト制作では、AIに手伝ってもらいたい作業がかなり多くあります。
WordPressテーマの修正、ACFの設定、記事原稿の作成、インポート用データの作成、資料構成、ちょっとしたコードレビュー。こういう作業を進めていると、CodexやChatGPTはかなり頼りになります。
ただ、実際に使い込んでいくと、利用制限や週間上限が気になるようになってきました。
自分の場合は、朝いちばんにCodexへ作業指示を出して、できるだけ早い時間から制限枠を動かし始めるようにしています。うまくいくと、最初の枠を使い切るころには次の枠が始まります。
この回し方なら、業務時間中はなんとか耐えられます。それでも、週単位の利用上限は別で気にしなければいけません。作業に集中していると、残りゲージのことを考えながら進めるのが地味にストレスでした。
Proプランに上げれば、もっと余裕を持って使えることは分かっています。かなり魅力はありますが、個人でDUNQRを育てている段階では、毎月の固定費としてはまだ少し重く感じます。
そこで考えたのが、全部をCodexに任せるのではなく、軽い作業や下準備はローカルLLMに逃がす使い方でした。
Codexは、設計判断、大きめの修正、複雑な不具合調査に残しておく。一方で、コードの要約、部分的なレビュー、SCSSやPHPの小さな相談、記事や資料のたたき台作成は、ローカルで回せるようにする。
そうすれば、Codexの利用枠をもう少し大事に使えるのではないかと思いました。
もうひとつ、AIツールの料金や制限がこれからも今のままとは限らない、という感覚もあります。クラウドAIはこれからも使っていくと思いますが、選択肢がそれだけになっていると、料金や制限が変わったときに困ります。
ローカルLLMだけで全部を解決するつもりはありません。でも、手元のPCでどこまでできるのかを知っておくことには意味がある気がします。
使用したPCスペック
今回使ったのは、普段使っているノートPCではなく、プライベートのゲーミングデスクトップPCです。
CPU：Core Ultra 7
GPU：RTX 5070 Ti
メモリ：32GB
VRAM：16GB普段の業務ではノートPCを使っています。そのノートPCにもVS CodeやCursorは入っていて、日常的なコーディングやAI補助には使っています。
ただ、ノートPC側はGPUが内蔵グラフィックスなので、ローカルLLMを本格的に動かすには少し厳しそうでした。そこで今回は、RTX 5070 Tiを積んでいるデスクトップPCをローカルLLMの母艦にすることにしました。
ローカルLLMでは、GPUのVRAMがかなり重要になります。この構成なら、巨大なモデルを快適に動かすのは難しそうですが、7Bから14Bクラスのモデルを使ったコード補助や文章生成には十分使えそうです。
想定している用途は、DUNQRの制作と、WordPressまわりの業務補助です。
WordPressテーマの確認
PHP、SCSS、JSの部分修正
ACF設定の相談
インポート用データの作成
記事原稿のたたき台作成
資料構成の作成
Figmaデザインからの実装補助Codexと同じことを全部ローカルでやりたい、というよりは、日常的な小さめの作業をローカルで回せるようにしたい、という考え方です。
ローカルLLMでVRAMが重要になる理由
ローカルLLMを調べ始めると、かなり早い段階で「VRAM」という言葉にぶつかります。
VRAMは、ざっくり言うとグラフィックボード側のメモリです。ゲームや3D制作でも大事ですが、ローカルLLMでは特に重要になります。
モデルをGPU上に載せて動かす場合、そのモデルを置く場所としてVRAMを使います。モデルがVRAMに収まると比較的快適に動きます。逆に、VRAMに収まりきらない場合は、システムメモリ側に逃がしたり、CPU側の処理が増えたりして、かなり遅くなることがあります。
このあたりで、ローカルLLM界隈の人たちがグラボのVRAM量を気にしている理由が分かってきました。
NVIDIA公式スペックでは、RTX 5070 Tiは16GB GDDR7、RTX 4090は24GB GDDR6X、RTX 6000 Ada Generationは48GB GDDR6 ECCとされています。VRAMが増えるほど扱えるモデルの幅は広がりますが、当然価格も一気に上がります。
ざっくりした感覚ですが、VRAMの目安はこんな感じで見ています。
8GB前後
軽いモデルを試す入口。
3Bから7Bくらいの小さめモデル向け。
12GB前後
7Bクラスがかなり扱いやすくなる。
軽めのコード相談や文章生成なら現実的。
16GB前後
7Bから14Bクラスが実用ラインに入りやすい。
今回のDUNQR用途なら、このあたりで十分使える。
24GB前後
量子化モデルなら、30Bクラスも試しやすくなる。
RTX 4090がよく話題に出る理由もこのあたり。
48GB以上
かなり本格的。
大きめのモデルをローカルで動かしたい人向け。もちろん、これはかなりざっくりした目安です。実際には、モデルの種類、量子化の形式、コンテキスト長、GPUへのオフロード設定、使うツールによって変わります。
ただ、自分のようにWordPress開発や記事制作の補助として使うなら、まずは16GBでもかなり現実的だと感じました。
AI需要とPCパーツ価格の変化
ローカルLLMを触り始めると、自然とPCパーツの価格も気になります。特にGPU、メモリ、SSDまわりです。
最近はAI需要がかなり大きく、データセンター向けGPUやHBMと呼ばれる高帯域メモリの需要が急増しています。
生成AIを動かす巨大なサーバー群では、GPUだけでなく、そのGPUに積まれる高速なメモリも大量に必要になります。この流れは、一般的なPCパーツの価格にもじわじわ影響しているように見えます。
たとえば、SK HynixはAI需要に対応するため、今後5年でウェハー生産能力を倍増させる計画を示しています。また、AI向けメモリ需要の強さから、供給ボトルネックが2030年ごろまで続く可能性にも触れられています。
高性能なGPUが高い。メモリも以前より安く買いにくい。SSDも構成によってはじわじわ高い。
このあたりは、単に「ゲーミングPCが人気だから」というより、AIインフラ全体の需要に引っ張られている面があるようです。
ローカルLLMは、始めようと思えば無料ツールだけでも始められます。でも、快適に動かそうとすると、最終的にはハードウェアの話になります。このあたりが、面白くもあり、少し沼っぽいところです。
VS CodeとGitで開発環境の土台を作る
最初に、デスクトップPCへVS Codeを入れました。
業務用ノートPCでは、VS CodeとCursorを日常的に使っています。Cursorは試用期間が終わったあと、無料版として軽めに使っている状態です。
使い慣れていることもあり、今回のローカルLLM環境でも、まずはVS Codeを軸にすることにしました。
VS CodeはMicrosoft Store版ではなく、公式サイトから通常版をインストールしています。Store版でも動くとは思いますが、今回はGit、ターミナル、拡張機能、PATHまわりで余計な差異を作りたくありませんでした。
そのあとGit for Windowsを入れ、GitHubで管理しているDUNQRのリポジトリをデスクトップ側にもcloneしました。
記事上では、作業フォルダを仮に以下のような場所としておきます。
C:\Projects\DUNQR実際には、自分の環境に合わせた任意の場所で問題ありません。今後、別プロジェクトを増やす場合も、同じように作業用フォルダの直下へ並べていく予定です。
C:\Projects
├─ DUNQR
├─ project-a
└─ project-bこの段階で行ったことは以下です。
VS Codeを公式サイトからインストール
Git for Windowsをインストール
Gitのユーザー名、メールアドレスを設定
GitHubからDUNQRリポジトリをclone
保存先は任意の作業フォルダ
VS CodeでDUNQRフォルダを開く
VS Codeのソース管理タブでGit連携を確認Gitの設定確認では、以下のようなコマンドを使いました。
git --version
git config --global --listWordPress StudioでDUNQR環境を復元する
次に、WordPressを動かすローカル環境を作りました。
DUNQRではWordPress Studioを使っています。ノートPC側で作っていた環境を、Studioのエクスポート、インポート機能でデスクトップ側へ移しました。
このあたりはかなり便利でした。通常のWordPress移行だと、DB接続情報や wp-config.php、URL置換などでハマることがあります。今回はStudioのインポートで、フロント側も管理画面側も表示できるようになりました。
ただ、途中で一度エラーが出ました。内容としては、Yoast SEOのプラグインファイルが一部見つからない、というものでした。
wp-content/plugins/wordpress-seo/...
Failed to open stream: No such file or directory最初はACFが原因かと思いましたが、実際にはYoast SEO側のファイル欠損っぽい状態でした。Yoast SEOを入れ直したところ、エラーは解消しました。
この段階で行ったことは以下です。
WordPress StudioをデスクトップPCにインストール
ノートPC側のDUNQR環境をStudioからエクスポート
デスクトップ側のStudioでインポート
フロント画面の表示を確認
管理画面へのログインを確認
Yoast SEOのエラー発生
Yoast SEOを再インストールして復旧Ollamaをインストールする
次に、ローカルLLMを動かすためにOllamaをインストールしました。
Ollamaは、ローカルLLMのモデルをダウンロードしたり、起動したり、複数モデルを管理したりするためのツールです。
インストール後、VS CodeのターミナルからOllamaが使えるか確認しました。最初はVS Code側で ollama コマンドが認識されませんでした。
原因は、Ollamaを入れる前からVS Codeを開いていたため、PATHが反映されていなかったことでした。VS Codeを再起動したら、ちゃんと認識されました。
確認に使ったコマンドです。
ollama --version実際には以下のように表示されました。
ollama version is 0.30.2OllamaでローカルLLMモデルを追加する
最初に入れたのは、コード向けの軽めのモデルです。
ollama run qwen2.5-coder:7b日本語で質問すると、日本語で返ってきました。この時点で、ローカルLLMが手元のPC上で動いていることが確認できました。
その後、DUNQR制作やWordPress開発用に、追加でモデルを入れました。
ollama pull qwen2.5-coder:14b
ollama pull qwen3:14b現在のモデル構成は以下です。
qwen2.5-coder:7b
qwen2.5-coder:14b
qwen3:14b使い分けは、今のところこう考えています。
qwen2.5-coder:7b
軽いコード確認用
qwen2.5-coder:14b
WordPress、PHP、SCSS、ACF JSONなどの開発補助用
qwen3:14b
日本語原稿、資料構成、記事作成用モデルはDUNQRのプロジェクトフォルダ内ではなく、Ollama側の共通領域に保存されます。Windowsでは、通常はユーザーフォルダ配下の .ollama ディレクトリに保存されるようです。
モデル一覧の確認には、以下のコマンドを使いました。
ollama list実際には、以下のように表示されました。
NAME SIZE
qwen3:14b 9.3 GB
qwen2.5-coder:14b 9.0 GB
qwen2.5-coder:7b 4.7 GBContinueをVS Codeに入れる
Ollama単体でもチャットはできます。ただ、DUNQRのコードを見ながら使いたかったので、VS Codeの拡張機能としてContinueを入れました。
Continueは、VS Code上からローカルLLMやクラウドLLMを呼び出せるAIコードアシスタントです。
最初は設定画面が少し分かりにくかったです。Continueの画面に、以下のような項目が出ていました。
Models
Chat
Setup Chat model
Autocomplete
Setup Autocomplete model
Edit
Setup Edit modelまずはChat modelだけ設定することにしました。ProviderでOllamaを選び、Connectを押すと、以下の設定ファイルが作成されました。
C:\Users\ユーザー名\.continue\config.yaml最初は中身がAutodetectになっていました。
name: Local Config
version: 1.0.0
schema: v1
models:
- name: Autodetect
provider: ollama
model: AUTODETECTこのままだと少し分かりにくかったので、明示的にモデル名を書く形に変更しました。
name: Local Config
version: 1.0.0
schema: v1
models:
- name: Qwen Coder 14B
provider: ollama
model: qwen2.5-coder:14b
- name: Qwen 3 14B
provider: ollama
model: qwen3:14b
- name: Qwen Coder 7B
provider: ollama
model: qwen2.5-coder:7b設定後、VS Codeをリロードしました。これで、Continueのモデル選択からローカルLLMを選べるようになりました。
VS Codeのリロードには、コマンドパレットから以下を使いました。
Developer: Reload Window最初は現在のファイルをうまく読めなかった
ContinueからローカルLLMに質問すると、最初は普通に返ってきました。
はい、私は現在ローカルのLLMとして動作しており、Ollama経由で起動されています。ここまでは成功です。
ただ、次に「現在開いているファイルを読んで」と頼んだところ、こんな返答が来ました。
{
"name": "read_currently_open_file",
"arguments": {}
}これは、ファイルを読めているのではなく、モデルがツール呼び出しのようなJSONをそのまま返してしまっている状態でした。
おそらく、Agent系の挙動やツール呼び出しに、ローカルLLM側がうまく対応できていなかったのだと思います。
そこで、ContinueのモードをChatに変更し、@Current_File を使って、現在開いているファイルを明示的に指定しました。
DUNQRのfront-page.phpを読ませてみる
試したのは、DUNQRテーマの front-page.php です。
Continueで qwen2.5-coder:14b を選び、Chatモードにして、以下のように聞きました。
@Current_File
現在開いているファイルを日本語で要約してください。
このファイルがWordPressテーマ内でどんな役割を持っているかも説明してください。すると、front-page.php がDUNQRテーマのトップページテンプレートであることや、各セクションの役割を日本語で要約してくれました。
ヘッダー、トップページコンテンツ、最新記事、ホビー系の導線、ストーリーのティーザー、Labの導線、SNSセクションなどを認識していました。
一部、「ヒーローセクション」を変な表記にしたり、「Lab」を「ラブ」と読んだりする粗さはありました。ただ、ファイル構造をざっくり把握して日本語で説明する用途としては、十分使えそうです。
コードレビューで使うときの聞き方
次に、front-page.php の改善点を聞いてみました。
すると、レスポンシブ対応、パフォーマンス、アクセシビリティ、保守性、ローカライゼーション、セキュリティ、SEOなどの改善点を挙げてくれました。
内容自体は大きく外れてはいませんでした。ただ、少し一般論が多い印象もありました。
たとえば、「画像が最適化されていない可能性があります」「ARIA属性が不足している可能性があります」のような言い方です。このあたりは、実際のコードを細かく見ているというより、よくある改善ポイントを並べている感じもありました。
ローカルLLMをコードレビューに使う場合は、聞き方が大事そうです。たとえば、こういう制約を入れると良さそうです。
推測で断定しないでください。
このファイル内で確認できる事実だけを根拠にしてください。
根拠がない項目は「このファイルだけでは判断不可」と書いてください。
まだコードは変更しないでください。最初から広く「改善点を教えて」と聞くより、観点を絞った方が実用的だと思いました。
エスケープ処理に漏れがないか
テンプレートパーツに分割した方がよい箇所
画像パスやリンクの書き方
WordPressテンプレートとして責務が重すぎる箇所見てほしいポイントを指定した方が、より使える返答になりそうです。
ローカルLLMを使ってみた感想
今回の環境で分かったのは、ローカルLLMはCodexの完全代替ではなく、日常的な補助役としてかなり使えそうだということです。
特に、以下の作業には向いていそうです。
WordPressテーマファイルの要約
PHP、SCSS、JSの部分的な確認
ACF JSONの構造チェック
テンプレート分割の相談
コード改善案の洗い出し
記事原稿のたたき台作成
資料構成の作成一方で、大きな設計判断や、複数ファイルをまたぐ実装変更、セキュリティに関わる修正は、まだCodexやChatGPT側に相談した方が安心です。
ローカルLLMは、少し雑な返答をすることもあります。なので、自動でどんどん直してもらうというより、まずは以下のような流れで使うのが安全そうです。
相談する
方針を確認する
必要な範囲だけ修正する
Git差分を見る
問題なければコミットする特に、ContinueのAgentモードでいきなりファイルを書き換えさせるのは、まだ怖いです。最初はChatモードで相談し、必要なら選択範囲だけEditする、くらいから始めるのが良さそうです。
OllamaやContinueを使い終わったらどうするか
気になったのが、OllamaやContinueを使い終わったあとにどうするかです。
OllamaはローカルLLMの実行基盤なので、常駐していても基本的には問題なさそうです。ただ、モデルを使った後は、しばらくメモリやVRAMに残ることがあります。
今動いているモデルは、以下のコマンドで確認できます。
ollama psモデルを止めたい場合は、以下のようにします。
ollama stop qwen2.5-coder:14b
ollama stop qwen3:14bOllama自体を終了したい場合は、WindowsのタスクトレイからQuitできます。ゲームや画像生成など、GPUをしっかり使いたい作業の前は、Ollamaを終了しておくと安心です。
ContinueはVS Codeの拡張機能なので、VS Codeを閉じれば基本的には止まります。
今後試したいこと
今回で、デスクトップPC上に以下の環境ができました。
VS Code
Git
WordPress Studio
DUNQRローカル環境
Ollama
Continue
ローカルLLMモデル次に試したいのは、以下です。
ContinueのEdit機能で選択範囲だけ修正する
Git差分確認を前提に、軽いコード修正をローカルLLMに任せる
qwen3:14bでDUNQR Labの記事原稿を作る
資料構成やスライド原稿をローカルLLMで作る
ノートPCからデスクトップPCのローカルLLMを呼び出す
Figma MCP連携をローカルLLM側でも試すFigma MCP連携については、すでに業務用ノートPC側のVS Code内で動かしているCodexでは少し試しています。
Codexから指示して、Figma側にモックアップを作成したり、そのFigma上で作ったデザインをもとにCodex側で実装する、という実験は一度成功しています。
かなり面白かったです。ただ、今のところはCodex側の強いモデルに頼っている部分が大きいです。
次に試したいのは、その一部をローカルLLM環境でもどこまでできるかです。もちろん、Figma連携やデザインからの実装は、ローカルLLMだけで高精度にやるにはまだ難しそうです。
ただ、簡単な構造把握や、HTML、SCSSのたたき台くらいなら、試す価値はありそうです。
特に、ノートPCからデスクトップPCのローカルLLMを呼び出せるようにできれば、かなり便利そうです。
ノートPC：操作端末
デスクトップPC：DUNQRのローカルWordPress環境とローカルLLMの母艦そういう構成にできれば、普段の作業もしやすくなりそうです。
まとめ
今回の目的は、CodexやChatGPTを使わずに全部をローカルで完結させることではありません。むしろ、役割を分けるための実験です。
CodexやChatGPTは、設計判断、大きな修正、複雑な不具合調査に使う。ローカルLLMは、日々の確認、整理、下書き、部分修正に使う。
この使い分けが、今のところ一番現実的そうです。
そして、もうひとつ大事だと思ったのは、AIツールの使い方をひとつに固定しすぎないことです。
今は、ChatGPT、Codex、Claude Codeのようなツールをかなり便利に使えています。ただ、今の価格や利用制限が、このままずっと続くとは限りません。
だからこそ、ローカルLLMのような選択肢を少しずつ触っておくことには意味があると思います。すぐに完璧な代替にはならなくても、できることとできないことを知っておくだけで、かなり違います。
DUNQRは、サイト自体も、記事も、制作フローも、少しずつ育てていくプロジェクトです。その制作環境にローカルLLMを組み込めたことで、少しだけ作業の自由度が上がった気がします。
まだ試したばかりですが、これはしばらく使ってみる価値がありそうです。