Mac mini を待つ間に、Aider と Qwen2.5-Coder でサービスを完成させた話

Contents

個人開発初学者がローカルLLM 1日でPhase 1〜3まで走り切った記録


7月のMac mini M4 Pro 48GB到着まで、あと2か月。

前回の記事「ローカルLLM環境を作るまで、AIと20回対話して気づいたこと」を書き終えたあと、自分の中で一つ決めたことがありました。

「Mac mini到着までの2か月、ただ待つだけにはしない」

手元には MacBook Air M4 24GB がある。LM Studio もインストール済み。Aider もすでに動く状態。

ならば、今あるもので 自分のサービス(社内ビル管理ポータル)を完成させてみよう —— そう思って、休日の朝にターミナルを開きました。

結論から書きます。

1日で Phase 1〜3 まで、すべて完成しました。

ビル一覧画面、ビル詳細画面、ステータス更新機能、変化履歴一覧、そして AI予測エージェント。社員向け画面と入居者向け画面の両方が、ローカルで動く状態になっています。

ただし、その過程は決して順調ではありませんでした。

そして、ローカルLLMには 「今できること」と「まだ無理なこと」がはっきりある ことを、身をもって体感しました。

この記事はその記録です。

同じように Mac mini や M5 Pro の到着を待ちながら、「今ある機材で何ができるか」を模索している方の参考になればと思います。


第1章:再開地点を確認する

朝、ターミナルを開いて最初に思ったのは「あれ、どこまで進んでたっけ?」でした。

前回の作業から少し時間が空いていたため、自分でも記憶が曖昧になっていました。

そこで、Claude(クラウド)にプロジェクトのスタートポイントを貼り付けて、現在地を整理してもらうことから始めました。

~/Documents/xxx-portal/
├── src/app/page.tsx          # ビル一覧(完成済み)
├── src/app/layout.tsx
├── src/lib/supabase.ts       # Supabase接続(完成済み)
├── src/types/index.ts        # 型定義(完成済み)
└── supabase/schema.sql       # DBスキーマ(投入済み)

ビル一覧画面とSupabase接続まではすでに動く状態。

次にやるべきは ビル詳細画面 (/buildings/[id]) の実装でした。

「よし、ここからが本番だ」

LM Studio で Qwen2.5-Coder-14B(MLX版)を起動し、Aiderに繋いで、最初の指示を出しました。


第2章:壁① Aider が違うフォルダで動いていた

最初の事件はすぐに起きました。

Aiderに「ビル詳細画面を作って」と指示すると、コードは生成されました。Aider自身も「ファイルを作成しました」と報告してきます。

しかしブラウザでビル詳細にアクセスすると、404エラー

ファイルを探してみたら衝撃の事実。

$ find ~/Documents/xxx-portal/src/app -type f
(buildings/[id]/page.tsx が存在しない)

$ find ~/src -type f
/Users/systemi/src/app/buildings/[id]/page.tsx  ← ここにあった!

Aiderが、プロジェクトフォルダではなくホームディレクトリで動いていた のです。

原因はシンプルで、ターミナルでAiderを起動した時のカレントディレクトリがホームディレクトリだったから。

# 正しい起動手順
cd ~/Documents/xxx-portal  # ← これを忘れていた
aider --openai-api-base http://localhost:1234/v1 \
      --openai-api-key lm-studio \
      --model openai/qwen2.5-coder-14b-instruct

たったそれだけ。でもこれに気づかず、何度同じ指示を出してもファイルが正しい場所に作られない悪夢を味わいました。

教訓1:Aider は必ずプロジェクトフォルダで起動する。pwd で確認する習慣をつける。


第3章:壁② 古い書き方でコードを生成された

ファイルを正しい場所に移動して、いよいよブラウザで確認 —— と思ったら、今度は別のエラー。

Export createClient doesn't exist in target module
import { createClient } from '@/lib/supabase';

Aiderが生成したコードは、@/lib/supabase から createClient を import しようとしていました。でも実際には supabase という名前で export されている。

さらに別のファイルでは import { useRouter } from 'next/router' という記述も。

これは Next.js Pages Router 時代の書き方 で、現在の App Router では next/navigation を使うのが正解です。

14Bモデルの学習データには古い情報が多く混ざっていて、Next.js 13以降の最新ベストプラクティスを正確に把握していなかったわけです。

何度修正を指示しても、別のところで似たようなミスを繰り返しました。

教訓2:モデルの知識を信用しすぎない。プロジェクト固有のルールは事前に渡す。


第4章:壁③ メモリが指示のたびに増えていく

修正のラリーが続くと、もう一つの問題が表面化しました。

Aiderは会話履歴を毎回モデルに全部送るため、指示を重ねるほどコンテキストが膨らみます。

M4 Air 24GB で14Bモデルを動かしている状態だと、これがどんどんSwapに書き出されてシステムが重くなる。応答も遅くなる。

何より、メモリ圧迫でAiderが同じコードを何度も再生成するループに入ってしまいました。

教訓3:1ファイル作ったら /exit で再起動。タスクの区切りで /clear


第5章:判断 — Aider から直接書き込みへ

3つの壁にぶつかった後、自分の中で一つ決断しました。

「Aiderだけにこだわるのは、もうやめよう」

Claude(クラウド)にコードを正しく書いてもらい、ターミナルから cat コマンドで直接プロジェクトに書き込む方式に切り替えました。

cat > ~/Documents/tenssho-portal/src/app/buildings/\[id\]/page.tsx << 'EOF'
import { redirect } from 'next/navigation'
import Link from 'next/link'
import { supabase } from '@/lib/supabase'
(以下、コード)
EOF

これが想像以上に効果的でした。

  • Claude が最初から正しいコードを書く
  • 中間の検証ステップがない
  • メモリの心配がない
  • ファイルが100%確実に正しい場所に作られる

Aiderを使わずに進めた結果、その日の午前中だけで /buildings/[id]/page.tsx が完成し、ブラウザで動作確認まで終わりました。


第6章:ローカルとクラウドの「役割分担」

ここで、自分の中で大きな気づきがありました。

ローカルLLMには 「向いている仕事」と「向いていない仕事」 がはっきりある。

向いている仕事

  • 同じパターンの繰り返し作業
  • 既存ファイルを参考にして似たファイルを作る
  • 軽い修正、リファクタリング
  • ボイラープレートの生成

向いていない仕事

  • 最新フレームワークの新規実装(古い知識で書く)
  • 複雑なアーキテクチャ判断
  • 複数ファイルにまたがる大きな変更
  • 微妙なロジックの設計

そして、これらを混在させようとすると、すべてが中途半端になる。

「ローカルLLMがクラウドを完全に置き換える」 のはまだ先の話。 今は 役割分担を決めることが、開発効率の鍵 になる。

これは前回の記事で書いた「機材の役割分担」と全く同じ構造でした。1台に全部やらせようとせず、適切に分けることで初めて全体が最適化される。


第7章:勢いに乗って Phase 1〜3 を完走

判断を切り替えたあとは、驚くほど速く進みました。

午後の3〜4時間で、Phase 2(変化履歴一覧UI)と Phase 3(AI予測エージェント)まで一気に実装。

Phase 2:変化履歴一覧

Supabase の status_history テーブルから直近20件を取得し、テーブル形式で表示する画面。

ビル詳細画面の下部に追加することで、「現在の状態」と「過去の経緯」が一画面で確認できるようになりました。

Phase 3:AI予測エージェント

これが今回のクライマックスでした。

Anthropic API キーを取得し(このとき1度漏洩事件があり、削除して再作成する一幕も)、Next.js の API ルートを作成。

「予測を見る」ボタンを押すと、過去の履歴と現在の状態を Claude(claude-sonnet-4-5)に送り、次に起こりうる事象と対応アドバイスを生成して画面に表示する仕組みです。

実際に動かしてみた結果が、これでした。

【予測される事象】

  • エレベーター長期停止による入居者の不満拡大
  • 高層階への階段利用による高齢者・障害者の入館困難
  • 騒音クレームとエレベーター停止の複合的な不満増加

【推奨対応】

  1. エレベーター復旧見込み時刻を全入居者へ速やかに告知
  2. 高層階入居者への個別フォローと代替手段の提案
  3. 騒音問題は作業時間帯の明確化と終了予定の共有

これを見たときの感動は、今も覚えています。

過去の履歴とメモから、ビル管理の専門家が出すような的確な予測がちゃんと返ってきた。

「動いた」を超えて「使えるものになった」 瞬間でした。


第8章:その日に得た 5つの学び

夕方、http://localhost:3000 を開いて、3棟のビル全部で予測ボタンを押してみました。

社員向け画面では状態更新ができ、入居者向け画面では閲覧専用の画面が表示される。履歴も時系列で並び、AI予測も動く。

要件定義書に書いたすべての機能が、自分の手元のMacBook Airとブラウザの中で動いていました。

そしてこの1日で得た学びを、自分のために書き留めておきます。

学び1:ツールの問題か、環境の問題か、知識の問題かを切り分ける

ループしたら一度立ち止まる。原因の切り分けができないと、永遠に同じ場所で時間を溶かす。

学び2:14B モデルは「相棒」ではなく「アシスタント」

全部を任せる相棒ではなく、的確な仕事を渡せばちゃんとこなしてくれる「アシスタント」。期待値の設定が大事。

学び3:CLAUDE.md は機材より重要

「Next.js は App Router を使う」「supabaseは @/lib/supabase から import する」といった前提を CLAUDE.md に明記しておけば、今日のミスの7割は防げた。モデルサイズより、こちらの整備の方が費用対効果が高い。

学び4:クラウドLLMと使い分ける勇気

ローカルだけで完結させようとせず、クラウドに頼るところは頼る。これは「妥協」ではなく「戦略」。

学び5:API キーは絶対にチャットに貼らない

これは恥ずかしながら今日の失敗から。.env.local の中身を確認するつもりで cat した結果がチャットに残ってしまった。即座に削除して再作成。初学者ほど起こりやすい事故 なので、自戒も込めて記録しておきます。


第9章:Mac mini 到着までの 2か月にやること

今日でわかった「現状の14Bモデルの限界」を踏まえると、7月までにやるべきことは明確です。

① CLAUDE.md / AGENTS.md を育てる

プロジェクト前提・コーディング規約・禁止事項。これを完成させておけば、Mac mini が来て32Bモデルが動くようになったとき、そのまま使える資産になる。

② 1指示 = 1ファイル を徹底する

複数ファイルを同時に作らせない。終わったら /exit で再起動する習慣をつける。

③ /ask で設計 → /code で実装の二段階

設計と実装を分けるだけで、的外れな実装が激減する。

④ 既存ファイルを /add で先に読ませる

プロジェクトの書き方を「学習」させてから新規ファイルを書かせる。命中率が大幅に上がる。

⑤ 完成した xxxx-portal を「育てる」

機能追加(メモ入力欄、ステータス変更履歴の自動記録)、デプロイ(Vercelへ公開)、プロンプト改善(AI予測の精度向上)。Phase完成後の「育てる」作業がたくさん残っている。


おわりに — 「待つ時間」を「育てる時間」に

7月のMac mini到着まで、まだ2か月あります。

正直、この2か月は「待ち時間」だと思っていました。「Mac miniが来たら本格的に始めよう」と。

でも今日、その考えが変わりました。

待つ時間を「育てる時間」に変えると、機材到着時のスタートダッシュが全然違う。

CLAUDE.md を整え、プロンプトのコツを身につけ、xxxx-portal を育て続ける。

これらは全部、新しい機材が来たときに そのまま使える資産 になります。

そして何より、今日 Phase 1〜3 まで完成させたという事実は、これからも消えません。

「24GBのMacBook Airでも、ここまでできた」

この体験は、Mac miniが来てもっと大きなことに挑戦するときの、確かな自信になるはずです。


同じように待ち時間を持つあなたへ

もしあなたが、いま新しい機材の到着を待っていたり、「もっといい環境が整ったら本格的に始めよう」と思っていたりするなら、伝えたいことがあります。

今ある機材で、できることから始めてください。

完璧な環境を待つより、不完全な環境で進めた経験のほうが、結果的に大きな財産になります。

ローカルLLMはまだ完璧じゃない。でも、足りない部分を理解して使い分ければ、十分に「動くもの」を作れる時代になっています。

そして、その小さな完成体験の積み重ねが、次の自信を作っていく。

今日のこの記録が、あなたの「次の一歩」のきっかけになれば嬉しいです。


2026年5月17日 更新
環境:MacBook Air M4 24GB / LM Studio / Aider / Qwen2.5-Coder-14B(MLX版)
完成したもの:xxxx-portal(Next.js + Supabase + Anthropic API による状態管理ポータル)


この記事を書いた人について:
個人開発初学者。WordPress設定変更を完了し、現在は電車サービス開発を継続中。
2026年7月にMac mini M4 Pro 48GBが届く予定。それまでに「使い倒せる開発環境」と「育てたプロジェクト」を準備中。