（初投稿です、お手柔らかによろしくお願いします）
最近、ローカルLLMを個人開発でいろいろ触っています。
普段は仕事でもシステム開発に携わっていますが、この記事は厳密なベンチマークや研究というより、
休日にローカルLLMを触っている一人のオタクが、実際に使っていて感じたこと
をまとめたものです。
最新のモデルや流行りの手法を試したくなるというより、実運用を考えたときに
「こいつは何が得意なんだろう」
と試したくなるタイプです。
最初は「コーディング性能」だけ見ていた
LLMの記事を読んでいると、
- このモデルはコーディングが強い
- このモデルは文章生成が得意
- このモデルは推論性能が高い
- このモデルは軽量なのに高性能
といった比較をよく見かけます。
自分も最初は、
開発に使うなら、コーディング性能が高いモデルを選べばいいのでは？
くらいに考えていました。
ただ、実際に個人開発で使っていると、少し違う感覚が出てきました。
ソフトウェア開発は、コードを書くことだけではありません。
実際に仕事していると、
- 曖昧な要望を理解する
- 現在の仕様を整理する
- 制約や見送り事項を確認・決定する
- 設計を考える
- 変更による影響を調べる
- 実装する
- 仕様通りか確認する
- リリース・運用/保守・改修
といった工程があります。
そこでふと、
単純な性能ではなく、モデルによって「得意な工程」や「仕事の進め方の癖」が違うのでは？
と思い始めました。
既存プロジェクトを読ませてみた
検証には、自分で以前作った小さなアプリを使いました。
暗号化したデータをローカルに保存し、必要に応じて外部ストレージも利用するデスクトップアプリです。
今回の目的はコードを書かせることではなく、
既存のコードや設計をどれくらい理解できるか
を見ることでした。
主に以下のような質問をしました。
- システム全体の設計を説明してください
- この設計を採用している理由は何ですか
- 設計と実装に矛盾はありますか
- 新しい機能を追加した場合、どこに影響しますか
試したモデルは主に、
- Gemma
- Qwen
- gpt-oss
です。
Gemma：事実を整理するのがかなり上手い
まず印象が良かったのがGemmaでした。
特に、
- 現在の構造を整理する
- ファイルごとの責務をまとめる
- 長い情報を短くする
- 入力された情報を大きく崩さず説明する
といった仕事がかなり安定していました。
以前、別用途で長文文書の要約にも使っていたのですが、そのときも似た印象がありました。
コードと自然言語の文章は全く違うものですが、
大量の事実を読んで、関係を壊さず整理する
という意味では共通しているのかもしれません。
Gemmaは「何か新しいことを考えさせる」というより、
事実整理
の使い方と相性が良いのでは、と感じました。
Qwen：すぐに「どう実装するか」を考え始める
一方で、Qwenはかなり違う印象でした。
例えば、既存システムに対して、
Google Drive API連携を追加して利便性を上げる提案があります。
既存設計への影響を評価してください。
と質問しました。
するとQwenは、
- OAuth認証
- API呼び出し
- 設定ファイルの変更
- 保存処理の変更
- テスト追加
- エラーハンドリング
などをかなり具体的に整理し始めました。
悪い回答という意味ではありません。
むしろ、
「それを実現するなら何を変更すればいいか」
を考える能力はかなり高い印象でした。
ただ、今回自分が知りたかったのは、
そもそも既存設計と衝突していないか
という部分でした。
※APIを直接使わず、同期フォルダを通常の外部ストレージとして扱う、というのが既存方針
Qwenは「採用するかどうか」より、
どうやって実現するか
へ進む力が強いように感じました。
これは実装担当として考えると、むしろ長所なのかもしれません。
制約を書けば止まると思った
そこで、質問の先頭に以下を追加してみました。
見送り事項: GoogleドライブのAPI直接連携
これで、
「Google Drive APIは見送り事項なので、この提案は既存方針と衝突します」
と回答するかなと思いました。
しかし、実際はQwenはそのままGoogle Drive APIを追加した場合の設計変更を説明し続けました。
ここで一つ気づきました。
Contextの中に情報が存在することと、その情報を拘束条件として使うことは別なのでは？
≒情報と指示は別物なのでは？
ということです。
Contextを構造化してみた
上記を受けて、モデル比較とは別に、Contextの与え方そのものにも興味がでてきました。
そこで、単なる見送り事項の一行ではなく、Contextを少し構造化してみました。
例えば、
既存アーキテクチャ
不変事項
見送り事項
決定優先度
対立時の処理方針
エビデンス方針
といった形です。
さらに、
不変事項
↓
見送り事項
↓
既存アーキテクチャ
↓
今回の指示
↓
実装改善案
という優先順位も明示しました。
また、
提案が不変事項 / 見送り事項と衝突する場合、
まず衝突を報告する。
明示的に方針変更を依頼されていない限り、
その実装設計には進まない。
というルールも追加しました。
すると、同じQwen 14Bが、
この提案は不変事項および見送り事項と直接衝突しています。
と回答し、
既存設計を破るため実装に移行すべきではない
という結論に変わりました。
モデル自体は変えていません。
変えたのはContextだけです。
大きいモデルなら全部解決するのか？
gpt-ossの20B、120Bでも同じような質問を試しました。
大型モデルになるほど、
- 何がコードから確認できる事実か
- 何が推測なのか
- 何が不明なのか
といった区別はかなり丁寧になりました。
特に120Bは、設計を読み取る能力や不確実性の扱いが明らかに強い印象でした。
ただし、
既存のプロジェクトのガバナンスまで自動的に理解し、すべての提案をそのルールに照らして判断する
ところまでは必ずしも行いませんでした。
モデルサイズを大きくすれば、すべて解決するわけでもなさそうです。
開発工程によってモデルの使い方を変えてもいいのかもしれない
まだ試行回数も少なく、厳密な比較ではないです。
ただ、今回使ってみた範囲では、こんな印象を持ちました。
| 工程 | 向いていそうな特性 |
|---|---|
| 既存情報の整理 | 事実を崩さず構造化できる |
| 曖昧な要求の解釈 | 推論能力が高い |
| 設計判断 | トレードオフや制約を扱える |
| 仕様の固定 | 勝手に意味を広げず整理できる |
| 変更影響分析 | コード理解と依存関係推論 |
| 実装 | タスク遂行力、コーディング能力 |
| 仕様との照合 | エビデンス重視、差分検出 |
| 最終判断 | 人間 ←重要 |
今回の事例を受けて、自分の中では、
- Gemma：整理役
- Qwen：実行役
- gpt-oss：分析・レビュー役
のような印象があります。
もちろん、これはモデルそのものの絶対的な能力を示すものではありません。
プロンプトやContext、量子化、モデルサイズによっても結果は大きく変わると思います。
「一番強いモデル」より「どこで使うか」
今回、一番の気づきでもあり、面白かった点は、
どのモデルが一番強いか
ではなく、
このモデルに、開発工程のどの仕事を任せると強みが出るのか
と考えるようになったことでした。
特にローカルLLMでは、計算資源にも制約があります。
すべての処理に最大モデルを使うより、
- 軽量モデルで情報整理
- 推論が必要なところだけ大型モデル
- 実装はコーディング向けモデル
のように分けた方が、意外と実用的なのかもしれません。
Contextについても考えさせられた
今回もう一つ気がついたのは、
良いContextを渡せば、モデルが万能になるわけではない
ということです。
Contextの役割は、
モデルを正しく動作させること
というより、
プロジェクトの現在の知識状態を保持し、必要なときに正しく参照できるようにすること
なのかもしれません。
そのContextを読んだあと、
- どう推論するか
- 何を優先するか
- どう実装するか
は、また別の問題です。
このあたりは、もう少し試してみたいと思っています。
おわりに
この記事はベンチマークではありません。
一つの個人開発プロジェクトに複数のローカルLLMを使ってみて、
モデルによって仕事の進め方にかなり違いがあるように感じた
という観察記録です。
まだ偶然やプロンプト依存の可能性もあります。
ただ、
LLMを「性能ランキング」で見るだけではなく、開発工程のどこに配置するかで考えてみる
という視点は、個人的にはかなり面白いと感じています。
今後、気が向いたらそれぞれのモデルについて「どの工程で使いやすかったか」をもう少し掘ってみたいと思います。
（でもメインは個人開発かな...）
Ark, are you sunk?