こんにちは、AIチームの戸田です。
2026年6月29日（月）、AI Shift 主催の「AI Shift Local LLM Meetup #2 〜クラウドLLMに頼りきらない開発体験をつくる〜」を、渋谷の Abema Towers で開催しました。
第2回となる今回は、Local LLM を開発の相棒として使ってみる、1時間集中の個人参加型ハッカソンという形式です。
開催の動機のひとつに、直近の Fable / Mythos のアクセス停止騒動があります。商用クラウドLLMは便利な一方で、提供側の仕様変更・制限・ポリシー変更・エクスポート規制などによって、昨日まで使えていたモデルが急に使えなくなることが、現実に起こり得ます。従量課金の高騰も同様です。同じように使っているつもりでも、挙動やコストが自分の意思とは無関係に変わる。そうしたリスクをあらためて感じたタイミングだったので、「クラウドに完全依存しない開発体験をどこまで作れるか」を手を動かして確かめる会にしました。
事前準備として、Mac で動く Local LLM 開発環境のセットアップ手順は別記事にまとめています。当日参加された方はこちらで環境を整えてから来ていただきました。
タイムテーブルはおおむね次の通りです。
| 時刻 | 内容 |
|---|---|
| 19:10 - 20:10 | 個人ハッカソン（1時間集中） |
| 20:10 - 20:40 | 成果共有（2分 × 15人） |
| 20:45 | 懇親会 |
GPU 搭載は必須とせず、Ollama / LM Studio / llama.cpp / MLX など各自の環境で、CPU で動く小型モデルでもOKという前提でした。完成度は問わず、「ここまで試した」「ここで詰まった」「このモデルが意外と良かった」という発見も歓迎、という方針です。
当日の成果物と発表の様子は以下にまとまっています。
- 成果物リポジトリ：https://github.com/trtd56/AIShiftLocalLLMMeetup2
- 当日の動画：https://www.youtube.com/watch?v=kDQMuE3l3gU
(※ 収録ミスで最後の発表だけ音声が入っておりません)
本記事では、印象に残った作品と自分の作ったものを紹介したうえで、複数の発表をまたいで見えてきた実践的な知見をまとめます。
自分が作ったもの：音声入力寿司（VoiceSushiDa）
私が作ったのは、音声入力でのコーディング（バイブコーディング）の練習を、タイピングゲーム「寿司打」のように行えるツールです。
環境は llama.cpp + Pi + Gemma（26B）+ M3 Macで、生成速度はかなり遅かったものの、0 → 1 の生成は意外と得意で、短時間でも形にはなりました。一方で UI の作成は苦手な印象で、見た目を整える部分は手作業の比率が高くなりました。後述する知見の「サイズと指示追従性」「UI は苦手」という傾向を、自分の手でも体感した格好です。
実際に遊べるデモを公開しています。
印象に残った作品
当日作られた作品の中から、特に印象に残ったものを2つほどご紹介します。
軽量モデルでのテトリス検証
9B サイズ前後の軽量モデルで、テトリスの開発と自己修復がどこまでできるかを検証した発表です。環境は Qwen / Gemma と比較のためのClaudeです。
Qwen はバグを「直したふり」をして同じコードを返す旧世代LLMのような挙動を示し苦戦した一方、Gemma は2ターンで実装・自己修復ができ、軽量版のアプリであれば十分使える見込みが立ったとのこと。「パラメータ数が多いほど良い」とは限らない、というローカル開発の勘所がよく出ていました。
真逆の現象を生成するチャットボット
「田中さんが眠っている」と入力すると、LLM がプロンプトを真逆の意味（起きている、など）に変換し、その内容で画像生成を行うアプリです。環境は Python（Gradio）+ OpenAI API。アイデア自体も LLM に出させて採用したそうです。
デモ程度のアプリならすぐ作れる手軽さを評価しつつ、環境構築（uv）まではやってくれない点や、CSS 直書き・関数がバラバラのスパゲッティコードになりがちな点に課題を感じた、という振り返りでした。
ハッカソンで見えた5つの知見
ここからは、複数の発表をまたいで浮かび上がってきた実践的な知見をまとめます。
知見1：修正させるより「1から作り直させる」ほうが早い
テトリスのようなシンプルなアプリでも真っ先に当たるのが、コンテキストウィンドウの限界です。普段はあまり意識しないような機能開発でも、コードのやり取りを数回重ねればすぐに埋まります。
ここで効いてくるのが「既存コードの修正より、1からスクラップ＆ビルドさせる方が効率的」という逆説です。過去のコードを文脈に含め続けると、トークン消費とレイテンシが増えるうえ、モデルの判断も鈍ります。ローカル環境という制約下では、細かいデバッグを依頼するより、仕様を再提示して「初速の速い0からの生成」を繰り返す方がゴールへの最短距離になりやすい、という実感がありました。
知見2：LLMが陥る「直したふり」という罠
多くの参加者が頭を抱えたのが「直したふり」です。バグを指摘すると「修正しました」と返ってくるのに、実際には以前と全く同じ、あるいは肝心の箇所が手付かずのコードが返ってくる現象です。
Qwen 2.5 の 14B / 27B といった中規模モデルでもこの「自己修復の限界」は顕著で、特定のバグを巡って5ターンほど重ねたあたりでモデルが論理的に崩壊し、改善が見えなくなるケースが目立ちました。ローカルモデルに完璧な自己修正を期待しすぎないこと。「直したふり」の兆候が見えたら、すぐ人間が介入するか、知見1の「作り直し」フェーズへ移る判断が要ります。
知見3：小さなモデルの躍進
「パラメータが多いほど賢い」という認識を裏切られた面白い結果です。今回、27B クラスがテトリスのロジックに苦戦する一方、より軽量な Gemma 系（4B / 9B クラス）が粘り強く正確だった場面がありました。
モデルの性能は規模だけでなく、タスクへの指示追従性やアーキテクチャの洗練度に左右されます。巨大モデルを無理に動かすより、軽量でキレのある小規模モデルを使いこなす方が、開発体験を大きく改善する鍵になりそうです。
知見4：ナレッジカットオフによる環境構築の詰まり
uv のような新しめのツールを使った環境構築を LLM に任せても、学習データのカットオフによって自律的に解決できない場面が多々ありました。
最近は権限さえ渡せば環境構築までAI Agentが行ってくれますが、Local LLMの場合はまだ人間が担保する必要がありそうです。
知見5：ハードウェアの現実
M4 MacBook Proを積んだマシンでも、推論が始まるとファンが強く回り、PCが熱を持ち始めました。
並列でLLMを回したり、他の作業をしながらなどは、一般的なノートPCだとまだ厳しいかもしれません。
おわりに
コードのスパゲッティ化や応答の遅延など、ローカル環境ゆえの課題はたしかにあります。それでも、データが外に出ない安心感や、自分で観測・評価・コントロールできる自由は、クラウド依存にはないものです。Fable / Mythos のようにモデルが急に使えなくなる事態を踏まえると、「ローカルでも一通り回せる」という引き出しを持っておく価値は、これからさらに増していくと考えています。
Local LLM Meetup は今後も継続していく予定です。興味のある方は、次回の開催でお会いしましょう。
最後までお読みいただきありがとうございました！
Discussion