Contents
M4 Air 24GBで Aider と Qwen2.5-Coder-14B を使ってわかったこと
「ローカルLLMでオフラインでも開発できる環境がほしい」
そう思って LM Studio と Aider をインストールしたのが2日前。Qwen2.5-Coder-14B（MLX版）を動かして、自分の電車サービス（tenssho-portal）の開発を始めました。
結論から言うと、Phase 1〜3 まですべて完成しました。
ただし、その過程は決して順調ではありませんでした。
そして気づいたのは、ローカルLLMには 「向いている使い方」と「向いていない使い方」がはっきりある ということ。
この記事では、個人開発初学者の自分が2日間ハマったことと、その答えを正直に共有します。
同じように M4 Air 24GB クラスの環境でローカルLLMを始めようとしている方の、参考になれば嬉しいです。
ぶつかった壁、すべて
壁①：Aider が違うフォルダで動いていた
最初の事件は、ファイルを作っても画面に反映されないことから始まりました。
調べてみると、Aider が ~/Documents/tenssho-portal/ ではなく、ホームディレクトリの ~/src/ にファイルを作っていた のです。
原因は単純で、Aider を起動した時のターミナルのカレントディレクトリがホームディレクトリだったから。
教訓：Aider は必ずプロジェクトフォルダで起動する。
cd ~/Documents/tenssho-portal # 必須
aider --openai-api-base http://localhost:1234/v1 \
--openai-api-key lm-studio \
--model openai/qwen2.5-coder-14b-instruct
壁②：古い書き方でコードを生成された
「Next.jsでビル詳細画面を作って」と指示したら、出てきたコードに import { useRouter } from 'next/router' が含まれていました。
これは Pages Router 時代の書き方 で、Next.js 13以降の App Router では next/navigation を使うのが正解です。
14B モデルの学習データに古い情報が混ざっていて、最新のベストプラクティスを正確に把握していなかったわけです。
何度修正を指示しても、別のところで似たようなミスを繰り返しました。
教訓：モデルの知識を信用しすぎない。プロジェクト固有のルールは事前に渡す。
壁③：メモリ（Swap）が指示のたびに増えていく
Aider は会話履歴を毎回モデルに全部送るため、指示を重ねるほどコンテキストが膨らみます。
24GB の M4 Air で 14B モデルを動かしている状態だと、これがどんどん Swap に書き出されてシステムが重くなっていきました。
教訓：1ファイル作ったら /exit で再起動する。それかタスクの区切りで /clear。
壁④：何度指示してもループする
createClient を supabase に書き換えてほしいだけの簡単な修正で、Aider が同じコードを何度も再生成し続けるループに入りました。
これは Aider が違うフォルダで動いていて、編集対象のファイルが見えていなかったのが原因でした。
教訓：ループしたら一度立ち止まる。ツールの問題か、自分の指示の問題か、環境の問題かを切り分ける。
答え：使い分けが全て
2日間でわかったのは、今の環境（M4 Air 24GB + 14Bモデル）でローカルLLMは「全部を任せる相棒」にはまだなれない ということです。
ただし、「向いている仕事」を渡せば確実に役に立つ こともわかりました。
向いている仕事
- 同じパターンの繰り返し作業
- 既存ファイルを参考にして似たファイルを作る
- 軽い修正、リファクタリング
- ボイラープレートの生成
向いていない仕事
- 最新フレームワークの新規実装（古い知識で書く）
- 複雑なアーキテクチャ判断
- 複数ファイルにまたがる大きな変更
- 微妙なロジックの設計
そして気づいたのは、「Claude（クラウド）に直接書いてもらって、ターミナルから cat で貼り付ける」方が速い場面が想像以上に多い こと。
ローカルLLMがクラウドに完全に置き換わるのはまだ先の話で、現時点では 両者の役割分担を決めることが、開発効率の鍵 でした。
今日からできる5つの工夫
このまま 7月のMac mini M4 Pro 48GB 到着を待つだけではもったいないので、現環境でローカルLLMをもっと活かす工夫をまとめました。
① CLAUDE.md にプロジェクト前提を書き込む
これだけで今回のミスの7割は防げます。
# プロジェクト前提
## 技術スタック
- Next.js 16系（App Router を使用、Pages Routerではない）
- TypeScript
- Tailwind CSS v4
- Supabase
## 必ず守るルール
- 'use client' は必要な箇所のみ最小限に使う
- useRouter は next/navigation から import する
- supabaseクライアントは @/lib/supabase から `supabase` を import する
- params は Promise<{ id: string }> 型で受け取る
モデルサイズを上げるより、こちらの方が費用対効果は高いです。
② 1指示 = 1ファイル を徹底する
複数ファイルを同時に作らせない。終わったら /exit で再起動。
③ 既存ファイルを /add で先に読ませる
/add src/app/page.tsx
/add src/lib/supabase.ts
プロジェクトの書き方を「学習」させてから新規ファイルを書かせると、命中率が上がります。
④ /ask で設計 → /code で実装の二段階
/ask この要件を実装するためのファイル構成を提案して
（モデルが提案）
/code 提案通りに src/app/buildings/[id]/page.tsx を作って
設計と実装を分けるだけで、的外れな実装が激減します。
⑤ プロンプトに正しい例を含める
src/app/page.tsx と同じ書き方で、buildings/[id]/page.tsx を作って
「同じ書き方で」は魔法のフレーズでした。
開発サイクルの結論
2日間の試行錯誤で辿り着いた、自分なりの開発サイクルです。
オフライン（ローカルLLMで実装）
↓
オンライン（Claude でレビュー・複雑な部分を依頼）
↓
オフライン（フィードバックを反映・次の実装）
- ローカル：集中したいとき、コストゼロで動かしたいとき、繰り返し作業
- クラウド：複雑な設計、最新フレームワークの新規実装、エラーの深掘り
特に大事なのは、「無理にローカルだけで完結させようとしない」 こと。
これが現時点の自分にとっての最適解でした。
7月以降の展望
Mac mini M4 Pro 48GB が到着すれば、Qwen2.5-Coder-32B（MLX版）が快適に動くようになります。
32B モデルは 14B とは別次元のコード品質を持っているので、今回ハマったような「古いimport」「謎のループ」は大きく減るはずです。
それまでに CLAUDE.md を完成度の高いものに育てておく のが、今やるべき準備です。
まとめ
ローカルLLM個人開発、2日目の気づき:
1. ツールの問題か、環境の問題か、知識の問題かを切り分ける
2. 今の14Bモデルは「相棒」ではなく「アシスタント」
3. CLAUDE.md がモデルサイズより重要
4. クラウドLLMと使い分ける勇気
5. 7月の機材到着までに準備できることは山ほどある
ローカルLLMは、いきなり「全部できる相棒」を期待すると裏切られます。
でも、自分の開発サイクルに合わせて「適切な仕事を渡せる相棒」として育てれば、確実に開発が変わっていく —— それが今日の正直な感想です。
完成した tenssho-portal は、社員と入居者がビルの状態を共有し、AI が次の事象を予測してくれるWebアプリになりました。Phase 1 から Phase 3 まで、すべて動くものができています。
2日前に「ローカルLLMで何ができるんだろう」と思っていた自分に、これを見せたい。
2026年5月17日 更新 環境：MacBook Air M4 24GB / LM Studio / Aider / Qwen2.5-Coder-14B（MLX）
