Contents
- はじめに
- 結論（先に言う）
- なぜこの説明を「今」しているか — 個人開発初学者へ
- 原因①: LLMは「ファイルシステム」にアクセスできない
- 原因②: Aiderの「ファイル追加」が明示的でないと無効
- 原因③: モデルが「テンプレ応答」に固着する
- 原因④: 「会話履歴を覚えている」≠「ファイルを読んだ」
- 原因⑤: 推論パラメータが未調整
- 解決の手順 — 安いものから順に試す
- 結論（先に言う）
- なぜ今この説明をするか
- Aider 特有の動き ①: リポマップ（Repo-map）の罠
- Aider 特有の動き ②: 編集フォーマットの強制
- Aider 特有の動き ③: 勝手にGitコミットする
- Aider 特有の動き ④: コマンド体系を知らないと操作不能
- Aider 特有の動き ⑤: コンテキスト管理が手動
- Aider 特有の動き ⑥: チャット言語の指定
- Aider 特有の動き ⑦: 設定の優先順位
- 結論（先に言う）
- なぜ今この区別が大事か
- Aider の設計が「節約優先」である根拠
- ローカルLLM で「節約」が決定的に重要な理由
- ただし「節約しすぎ」の罠
- MacBook Air M4（24GB）× Aider の「節約バランス」推奨値
- 「節約最高」を運用に落とし込む具体策
- 一段深い学び — 「節約」と「ケチ」は違う
- 今日学んだ3つのこと
- 個人開発者へのメッセージ
はじめに
MacBook Air M4（24GB）でローカルLLM（qwen2.5-coder:14b）+ Aider を使って個人開発を始めたところ、何を聞いても同じテンプレ応答が返ってくる という壁にぶつかりました。
この記事では、その原因を5項目に分解し、さらに Aider 特有の落とし穴と、ローカルLLM運用での「節約思想」 を、個人開発初学者向けにまとめます。Cursor / Cline / Continue / Claude Code に乗り換えても、同じ原理が9割使い回せる内容です。
第1部: なぜローカルLLMは同じ回答しか返さないのか
結論（先に言う）
ローカルLLM（qwen2.5-coder:14b）が同じ回答を繰り返した最大の原因は、「LLMにファイルの中身が渡っていなかった」こと。 そして「同じ回答に逃げた」のは、LLM側が情報不足のときに 安全策としてテンプレ応答に固着する性質 を持っているからです。原因はひとつではなく、5つの層が重なってこの症状を作ります。
なぜこの説明を「今」しているか — 個人開発初学者へ
個人開発でローカルLLMを触り始めた最初の段階で、「LLMが何を見ていて、何を見ていないか」 の構造を理解しておかないと、この先 Aider / Cursor / Cline / Continue / Claude Code を使うたびに同じ壁にぶつかります。
逆に、ここで仕組みを押さえれば どのツールでも同じ原理で動いている ので、トラブルシューティングの「型」が一生使えるものになります。
原因①: LLMは「ファイルシステム」にアクセスできない
何が起きていたか
ターミナルで /Users/systemi/aider-test/docs のようなパスを打っても、LLMから見ればそれは ただの文字列 です。その先に何のファイルがあるのか、中身に何が書かれているのかは 知る術がありません。
なぜそうなるのか
LLMにできるのは「渡されたテキストを元に、次のテキストを生成する」だけ。ファイルを開く・ディレクトリを読む・コマンドを実行する、といった行為は LLM本体の機能ではなく、周辺アプリ（Aider・Cursor等）が肩代わりしている ものです。
| ツール | ファイルを読む主体 |
|---|---|
| ChatGPT Web | ブラウザ＋OpenAIのバックエンド |
| Claude（Web版） | Anthropic側のツール実行環境 |
| Aider | Aiderというアプリ本体 |
| ローカルLLM単体 | 誰もファイルを読まない |
ローカルLLMを「裸で」動かしている場合、ファイルを読む人がそもそも存在しないわけです。
原因②: Aiderの「ファイル追加」が明示的でないと無効
何が起きていたか
Aider の起動画面に Git repo: .git with 8 files / Repo-map: using 1024 tokens と出ていたはずです。これを見て「Aider がファイルを読んでくれている」と勘違いしがちですが、Repo-map は要約のみ。各ファイルの中身は渡っていません。
正しい使い方
中身を読ませるには、明示的にコマンドで追加 する必要があります。
/add docs/要件定義.md
/add docs/README.md
または起動時にファイル名を直接指定：
aider docs/要件定義.md
追加後に画面下に Added: ファイル名 と表示されれば成功。/files で現在追加済みのファイル一覧を確認できます。
個人開発者向けの教訓
Aider・Cursor・Cline 系のツールはすべて 「LLMに何を見せるか」を人間が指示する 設計思想です。LLMを賢くするのではなく、LLMに正しい材料を渡す技術 がアプリ運用の本質です。
原因③: モデルが「テンプレ応答」に固着する
何が起きていたか
了解しました。今後、ファイルの変更を提案する際には指定された
フォーマットに従います。どのような変更が必要か具体的にお知らせ
いただければ、適切なファイルをリストアップし、その内容を提供
いたします。
何を聞いても、このような 内容のない定型応答 が返ってくる状態。
なぜそうなるのか（2つの理由が重なっている）
(1) Aider のシステムプロンプトが強い
Aider は裏側で「ファイル変更を提案する時はこのフォーマットで」と非常に強く指示しています。LLMは状況が掴めない時、その指示の「最大公約数」に逃げます。
(2) 14Bという小型モデルの性質
14B クラスのモデルは、情報が不足したときに 学習済みの一番無難なテンプレ に固着しやすい傾向があります。一度このパターンに入ると抜け出しにくい。これはモデルサイズの限界そのものです。
Qwen 系特有の癖
Qwen 系は「指示追従が真面目すぎる」ため、システムプロンプトの定型に 過剰適合 しやすいです。Llama 系や Gemma 系では同じ症状でもパターンが違います。
原因④: 「会話履歴を覚えている」≠「ファイルを読んだ」
何が起きていたか
トークン数を見ると 1.0k → 1.8k と増えていたはずです。これを見て「履歴は覚えているのに、なぜ？」と感じます。
本当のところ
- 増えたトークンの正体は 過去のやり取り（あなたの質問とLLMの回答） だけ
- ファイルの実体は一切含まれていない
- だからLLMは「情報がない」状態のまま会話を続けている
個人開発者向けの教訓
LLMアプリのトラブルシューティングでは、「履歴があるか」と「実体があるか」を分けて考える クセが重要です。トークン数の増加は前者の証拠にしかなりません。
原因⑤: 推論パラメータが未調整
何が起きていたか
LM Studio / Ollama のデフォルト設定のまま使うと、繰り返しを抑制する仕組みが弱く、テンプレ固着が起きやすい状態です。
押さえるべきパラメータ4つ
| パラメータ | 役割 | 推奨値（コード用途） |
|---|---|---|
| Temperature | 応答のランダム性 | 0.2〜0.3 |
| Top P | 確率上位の候補のみ採用 | 0.9 |
| Repeat Penalty | 繰り返し抑制（今回の症状の特効薬） | 1.15〜1.20 |
| Context Length | 一度に扱える文字数 | 8192〜16384 |
特に Repeat Penalty を 1.15 に上げる だけで、テンプレ固着の症状はかなり改善します。LM Studio なら右パネル、Ollama なら Modelfile の PARAMETER repeat_penalty 1.15 で設定できます。
解決の手順 — 安いものから順に試す
個人開発の鉄則は 「コストの低い対処から順番に」 です。
| 順番 | やること | コスト | 効果 |
|---|---|---|---|
| 1 | /add docs/要件定義.md でファイルを明示追加 | 30秒 | ★★★★★ |
| 2 | /reset で履歴をクリアして再挑戦 | 1分 | ★★★★ |
| 3 | repeat_penalty を 1.15 に設定 | 5分 | ★★★ |
| 4 | System Prompt に「テンプレ禁止」を明文化 | 10分 | ★★★ |
| 5 | 汎用版モデル（qwen2.5:14b）に切り替え | 30分 | ★★ |
| 6 | サイズアップは最後の手段 | 1時間〜 | ★★ |
いきなり 6 番（モデルを大きくする）に飛ぶのが、初学者の典型的な失敗パターン です。多くの場合は 1〜3 番で解決します。MacBook Air M4（24GB）では、そもそも14Bを超えるサイズは現実的ではありません。
第2部: Aider 特有の動きと注意すべきポイント
結論（先に言う）
Aider 特有の最大の落とし穴は「ファイルを /add していないのに、リポマップだけで全部見えていると錯覚させる UI」です。 さらに Aider は 編集フォーマットを強制する設計 なので、小型ローカルLLM（14B以下）と組み合わせると、第1部のような「テンプレ応答地獄」に陥りやすい。Aider は本来クラウドの強力なモデル（Claude / GPT-4）前提に作られており、ローカルLLM で使うには 意図的な”弱体化設定”が必要 です。
なぜ今この説明をするか
ローカルLLM × Aider という組み合わせは、ネット上の記事だと「動きました！」で終わっているものが多く、実運用で詰まる落とし穴が共有されていません。Cursor や Cline に乗り換えても 同じ知識が9割使い回せる ので、ここで型を作る価値が高いです。
Aider 特有の動き ①: リポマップ（Repo-map）の罠
どんな動きか
Aider を起動すると、勝手にこう表示されます。
Git repo: .git with 8 files
Repo-map: using 1024 tokens
これは「リポジトリ全体を要約してLLMに渡している」という意味です。各ファイルの関数名・クラス名・シグネチャだけを抜き出した一覧表のようなもの。
何が罠か
UI だけ見ると「全ファイル把握済み」に見えるのに、中身は1文字も渡っていません。「内容を確認して」と聞いた時、LLM には「ファイル名と関数名」しか見えていない状態でした。
注意点
- リポマップは ナビゲーション用の地図 であって、本文ではない
- 中身を読ませたいファイルは 必ず
/addする /mapでリポマップの現状を確認できる--map-tokens 0でリポマップを完全に切ることもできる（小型モデルで混乱する場合は有効）
Aider 特有の動き ②: 編集フォーマットの強制
どんな動きか
Aider は LLM に「ファイル変更を提案するときは、必ず決まった書式で書け」と命令しています。主な書式は次の3種類。
| フォーマット | 中身 | 向いているモデル |
|---|---|---|
| diff | 差分（パッチ）形式 | GPT-4 / Claude（大型） |
| udiff | unified diff 形式 | 大型モデル |
| whole | ファイル全文を再出力 | 小型ローカルLLM向け |
何が罠か
デフォルトは diff ですが、14B 程度のローカルLLMは diff を正確に出せません。形式エラーで弾かれ、LLM は「無難なテンプレ応答」に逃げます。これが第1部の症状の隠れた一因です。
注意点
ローカルLLM を使うときは、起動時に必ず指定：
aider --edit-format whole --model ollama/qwen2.5-coder:14b
または .aider.conf.yml に固定：
edit-format: whole
whole は冗長ですが確実 です。小型モデルでは精度より確実性を優先します。
Aider 特有の動き ③: 勝手にGitコミットする
どんな動きか
Aider はデフォルトで、ファイルを編集するたびに 自動で git commit します。コミットメッセージもLLMが書きます。
何が罠か
- LLM が誤った変更をしても、即コミットされる
- 14B モデルが生成するコミットメッセージは品質が低い
- ブランチ戦略を考えていない状態で履歴が汚れる
- 「あれ、勝手にコミットされてる！？」と慌てる
注意点
ローカルLLM 運用では 無効化推奨：
# ~/.aider.conf.yml
auto-commits: false
dirty-commits: false
または起動時に --no-auto-commits --no-dirty-commits。
変更内容を自分の目で確認してから手動コミットする運用が、初学者には安全です。
Aider 特有の動き ④: コマンド体系を知らないと操作不能
最低限覚えるべきコマンド
| コマンド | 用途 | 使用頻度 |
|---|---|---|
/add <file> | ファイルを文脈に追加 | ★★★★★ |
/drop <file> | ファイルを文脈から外す | ★★★ |
/files または /ls | 追加済みファイル一覧 | ★★★★ |
/reset | 会話履歴をクリア | ★★★★ |
/clear | 全部リセット | ★★★ |
/tokens | 現在のトークン使用量 | ★★★ |
/map | リポマップ確認 | ★★ |
/undo | 直前の変更を取り消し | ★★★★ |
/diff | 直前の変更を確認 | ★★★★ |
/help | コマンド一覧 | ★★★ |
/exit | 終了 | ★★★★★ |
注意点
- 通常の文章を打つと「LLMへの質問」として送られる
/から始めると「Aider への命令」- この区別を忘れると、コマンドのつもりが質問として送られて混乱します
Aider 特有の動き ⑤: コンテキスト管理が手動
どんな動きか
Cursor や Claude Code は、関連ファイルを 自動で文脈に入れてくれる 仕組みを持っています。Aider は すべて手動。あなたが /add しない限り、LLM には何も見えません。
注意点
- 「依存しているファイルも自動で読んでくれる」は 期待しない
- 編集対象だけでなく、参照する型定義・設定ファイル・ドキュメントも
/addする - ただし入れすぎるとトークンを食ってローカルLLM の精度が落ちる（5〜10ファイルが目安）
Aider 特有の動き ⑥: チャット言語の指定
どんな動きか
Aider はデフォルトで英語応答になりがちです。Qwen は日本語が得意なのに、Aider 経由だと英語で返ってくる、という現象が起きます。
注意点
設定ファイルで日本語を強制：
chat-language: ja
これで応答が日本語に固定されます。地味ですが効きます。
Aider 特有の動き ⑦: 設定の優先順位
Aider の設定は 複数の場所 に書けて、優先順位があります。
コマンドライン引数 > 環境変数 > .aider.conf.yml（プロジェクト） > ~/.aider.conf.yml（ホーム）
注意点
- ホームに置いた設定がプロジェクトで上書きされていて「あれ効かない」となるパターンが多い
- 困ったら
aider --verboseで実際に使われている設定を確認
第3部: Aider の「節約思想」はローカルLLM運用の最適解か
結論（先に言う）
Aider の「リポマップだけ送る・手動で /add する」設計は、ローカルLLM のメモリ節約には構造的に最適化されています。 ただし「メモリ節約」と「ローカルLLM で快適に動く」は 別の話。節約しすぎると第1部のような「何も見えてない」症状になります。節約の本質は”必要最小限を正確に渡す” であって、”渡さない”ことではありません。
なぜ今この区別が大事か
個人開発初学者がローカルLLM で挫折する典型パターンは2つあります。
- 入れすぎてメモリ不足 → モデルが遅くなる・落ちる
- 入れなさすぎて文脈不足 → 第1部の症状（テンプレ応答地獄）
Aider の設計思想を「節約最高！」と理解すると 2番に振り切る ので、ここで「節約の正しい意味」を押さえておくと、明日からの作業の質が変わります。
Aider の設計が「節約優先」である根拠
① リポマップ方式そのものが節約思想
普通の発想なら「リポジトリ全ファイルを送る」になります。Aider はあえて 関数名とシグネチャの要約だけ を送る。これで トークンを 1/10 以下 に圧縮しています。
② デフォルトのリポマップ上限が1024トークン
Cursor などは数万トークン使うのが普通ですが、Aider は 1024トークン がデフォルト。これは「文庫本0.5ページ分」程度。徹底的にケチっています。
③ 手動 /add の思想
「人間が必要なファイルだけ選んで追加しろ」という UI 設計自体が、LLMにゴミを渡さない=トークンを浪費しない という哲学の表れです。
④ 履歴の自動圧縮機能
Aider は会話が長くなると、古い履歴を 自動で要約圧縮 します。これも節約のため。
ローカルLLM で「節約」が決定的に重要な理由
コンテキスト長 = メモリ消費 だから
ローカルLLM は、渡すトークン数が増えるほど物理メモリを食います。
| コンテキスト長 | 必要メモリ増加（14Bモデル目安） |
|---|---|
| 2,048 トークン | +0.5 GB |
| 8,192 トークン | +2 GB |
| 32,768 トークン | +8 GB |
| 128,000 トークン | +30 GB |
MacBook Air M4（24GB ユニファイドメモリ）で 14B モデルを動かす場合、コンテキストを大きく取ると一気にメモリが枯渇 します。
24GB のうち、OS と他アプリで常時 6〜8GB は埋まっているので、LLM が使えるのは実質 16GB 前後。14B モデル本体（Q4量子化）で 8〜9GB を占めるため、コンテキストに回せるのは数GB しかありません。Aider の節約設計は、この物理制約に 構造的にハマっている わけです。
速度にも直結する
トークンが多いほど推論が遅くなります。ローカルLLM は元々遅いので、節約はそのまま体感速度 になります。Air M4 で 8k トークンと 32k トークンでは、応答時間が 2〜3倍違う ことも珍しくありません。
ファンレス機の発熱問題
Air M4 は ファンレス 設計です。大きなコンテキストで長時間推論すると、サーマルスロットリング（熱で性能を自動的に落とす機能）が発動し、さらに遅くなります。節約は発熱対策でもある わけです。
ただし「節約しすぎ」の罠
第1部の症状がまさにそれ
リポマップ（1024トークン）だけで LLM に「内容を確認して」と聞いた状態は、極限まで節約した結果、情報が足りなくて答えられない、という典型例です。これは「節約の失敗」と言えます。
節約の正しい姿
✕ 何も渡さない（情報不足で機能停止）
✕ 全部渡す（メモリ・速度が破綻）
◯ タスクに必要な最小セットを正確に渡す
たとえば「要件定義.md をレビューして」というタスクなら、そのファイル1個だけ /add すればいい。リポマップは切ってもいい（--map-tokens 0）。これが本当の節約です。
MacBook Air M4（24GB）× Aider の「節約バランス」推奨値
| 項目 | 推奨値 | 理由 |
|---|---|---|
| モデルサイズ | 7B〜14B（Q4量子化） | 24GBの物理制約 |
| コンテキスト長（num_ctx） | 4,096〜8,192 | 14Bならこのあたりが現実的 |
| リポマップ（map-tokens） | 0〜1,024 | 小型モデルは混乱しやすいので少なめ |
同時 /add するファイル数 | 1〜3個 | 多いと精度が落ちる |
| 1ファイルあたりサイズ | 〜300行程度 | 長すぎるなら分割 |
| 履歴の最大ターン数 | 8〜10往復 | それを超えたら /reset |
.aider.conf.yml 節約特化版（Air M4 24GB用）
model: ollama/qwen2.5-coder:14b
edit-format: whole
# 節約設定
map-tokens: 0 # リポマップ完全オフ
max-chat-history-tokens: 2048 # 履歴も圧縮
restore-chat-history: false # 前回履歴を読み込まない
# 確実性のため
auto-commits: false
dirty-commits: false
chat-language: ja
show-diffs: true
これで 「裸の LLM に、自分が選んだファイルだけ渡す」最小構成 になります。
「節約最高」を運用に落とし込む具体策
① タスクを始める前に “必要ファイル” を列挙する
タスク：要件定義ファイルのレビュー
必要：docs/要件定義.md（1個だけ）
不要：README.md、コードファイル、リポマップ
この習慣を持つだけで、Aider 起動時に何を /add するか即決できます。
② タスク終了ごとに /drop で掃除する
ファイルを追加しっぱなしにすると、無関係なファイルが文脈を圧迫します。タスクが終わったら：
/drop docs/要件定義.md
/reset
で クリーンな状態に戻す。Cursor が自動でやることを、Aider は手動でやります。
③ 大きなファイルは分割して渡す
300行を超えるファイルは、LLM の注意力が散るので、必要な箇所だけを切り出して別ファイルにする。これも節約と精度の両立になります。
一段深い学び — 「節約」と「ケチ」は違う
Aider の設計思想は、コンピュータサイエンスで言う “You only need what you need”（必要なものだけを必要なだけ）です。これは：
- 節約 = 必要なものを最小限の形で渡す
- ケチ = 必要なものまで渡さない
今回のケースは、Aider の「節約志向」を 誤って「ケチ志向」で運用した 結果と言えます。設計思想は正しい、運用が惜しかった、という構図です。
ローカルLLM 運用では、この 「必要最小限を正確に」 という発想がすべての基本になります。これを身につけると：
- メモリ不足にならない
- 応答が速い
- 精度も維持される
- Air M4（24GB）でも実用レベルの開発が回る
という 個人開発者にとって最高の運用 が成立します。
全体まとめ
今日学んだ3つのこと
| 部 | 学び |
|---|---|
| 第1部 | ローカルLLM が同じ回答を繰り返す根本原因は「ファイルが見えていない＋テンプレ固着＋パラメータ未調整」の複合 |
| 第2部 | Aider はクラウドLLM 前提のツール。ローカルLLM では edit-format: whole / auto-commits: false など意図的な調整が必要 |
| 第3部 | Aider の節約思想はローカルLLM と相性が良いが、「節約」と「ケチ」を混同しない運用が重要 |
個人開発者へのメッセージ
ローカルLLM × Aider の組み合わせは、「ツールを使いこなす」のではなく「ツールを自分の環境に合わせて作り直す」 くらいの気持ちが必要です。MacBook Air M4 のような メモリ制約のあるマシン ではなおさら、設定とプロンプトと運用ルールを 自分で育てる ことが、実用化への唯一の道になります。
LLM 本体を賢くしようとするのではなく、LLM に渡す材料を整える技術 に意識を向ける。これが、個人開発でローカルLLM を本気で使う人と、挫折する人の分岐点です。
今日詰まったこの体験は、その分岐点を越えるための 最高の教材 でした。
