ローカル AI モデルの活用と実験レポート：インターネット不要で、あなたの Mac で動く研究・計画・コーディングアシスタントへようこそ

少しの間、ローカルで動作するモデルの実験を断続的に行ってきました。そしてついに、「まあまあの性能で機能する」設定を見出しました。もちろん、現在の最先端（SOTA: State of the Art）モデルの出力には及びません。しかし、「インターネット接続なしに、ローカルでの基本的なタスク実行、調査、計画を行うことができる」というワクワク感が、その性能差を十分に補って余りあるものです！特に重要なのは、インターネット接続不要という点。加えて、大規模な米国のテクノロジー企業への依存度を、たとえ僅かでも減らせるという意味でも価値があります。

ただし正直に申せば、この仕組みを設定するのは容易ではありませんでした。まずモデルを実行するプラットフォームを選択する必要があります：Ollama、llama.cpp、そして LM Studio のいずれかです。それぞれ独自の癖や制限があり、かつ提供されるモデルの種類も異なります。さらに当然のように、モデルの選択へと突き進みます。

ここでは、「メモリ内に収まりつつ、通常の Electron アプリなどの多様なタスクを同時に実行できる余裕（ヘッドルーム）があり、最低でも 64K のコンテキストウィンドウを持ち、理想を言えば 128K またはそれ以上」という条件を満たすモデルを選ぶ必要があります。最近では Qwen 3.6 Q3、GPT-OSS 20B、Devstral Small 24B などを実際に試しましたが、理論上はメモリに収まりますが、実際には使い物にならなかったという結果でした。一方、Gemma 4B は動作しますが、ツールの活用においては苦戦していました。

加えて、微調整すべき設定オプションの数々は膨大です。Temperature という比較的名なものから、K Cache Quantization Type のようなやや難解なオプションまであります。多くのツールには基本的な推奨設定セットが付属していますが、最適な設定は「思考（Reasoning）機能を有効にするか否か」など、状況によって大きく異なります！

以下に、私が最終的に動作させ、比較的良好な結果を得た Qwen 3.5-9B (4bit 量化版) の例を紹介します。

Qwen 3.5-9B (4b quant)：LM Studio を使用した場合の成果

HuggingFace リンクで入手可能な

qwen3.5-9b@q4_k_s

• 推論速度: 約 40 トークン/秒
• 思考機能 (Thinking): 有効化済み
• ツール活用: 成功裏に動作
• コンテキストウィンドウ: 128K
• 実行環境: LM Studio

SOTA モデルと比較すると、些細なことに注意を逸しやすく、場合によってはループに陥ったり、指示の意味を誤解したりすることがあります。しかし、24GB RAM の MacBook Pro を使用しながらも、他の多くのアプリやタスクと同時進行で稼働できるという点において、その実用性は驚くほど高いものです！

思考モードおよびコーディング作業向けの推奨設定

以下のパラメータが、「思考モード」启用およびコーディングタスク（例：WebDev）に対して最適です。

• temperature=0.6

• top_p=0.95

• top_k=20

• min_p=0.0

• presence_penalty=0.0

• repetition_penalty=1.0

思考機能を有効にするには、モデルを選択した後、「設定（Configuration）」タブの底部にある「Inference」セクションへスクロールし、プロンプトテンプレートに以下の行を追加してください。

{%- set enable_thinking = true %}

私はこのモデルを Pi と OpenCode の両方の環境で利用してきましたが、どちらが優れているか結論を出すには至っていません。Pi は反応が少し速く感じられますが、「ハネス（ツールセット）自体が構築され、高度なカスタマイズが可能である」というコンセプトに敬意を表しつつも、「合理的なデフォルト設定」が付属していないことには正直不満を感じています。結局のところ、Pi の環境設定を完璧にするのに費やす時間の方が、実際にプロジェクトを進めることに割く時間よりも多くなる可能性があります！

Pi 環境の設定例 (

~/.pi/agent/models.json

)

思考プロセスを可視化させずに使用する場合は、

~/.pi/agent/settings.json

hideThinkingBlock: true

{
  "providers": {
    "lmstudio": {
      "baseUrl": "http://localhost:1234/v1",
      "api": "openai-completions",
      "apiKey": "lm-studio",
      "models": [
        {
          "id": "qwen3.5-9b@q4_k_s",
          "reasoning": true,
          "compat": { "thinkingFormat": "qwen-chat-template" }
        }
      ]
    }
  }
}

OpenCode 環境の設定例 (

~/.config/opencode/opencode.json

)

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "lmstudio": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "LM Studio (local)",
      "options": {
        "baseURL": "http://127.0.0.1:1234/v1"
      },
      "models": {
        "qwen3.5-9b@q4_k_s": {
          "name": "Qwen 3.5 9B Q4_K_S",
          "tools": true,
          "context_length": 131072,
          "max_tokens": 32768
        }
      }
    }
  },
  "model": "lmstudio/qwen3.5-9b@q4_k_s"
}

SOTA モデルとの比較

Qwen 3.5 9B (Q4) といったモデルは、SOTA モデルのように長期間にわたって複雑な問題を独立して解決できる能力には及びません。一度に整個アプリケーションを構築させるような依頼を出すのは非効率的であり、徒労（太ももを燃やす）に終わる可能性が高いです。

機能するのは、むしろより対話的なワークフローです。モデルと段階を追って明確にコミュニケーションを取り、十分なガイダンスを与えることで成果を出せます。多くの人が「わざわざ監視しながら作業させるのが pointless (無駄)」だと感じるかもしれませんが、私はそれが逆に私の関与度を高めるのに役立ったと感じています。SOTA モデルの欠点は、認知努力をすべて外部化する行為があまりにも容易にできてしまうことです。あなたがそれを防ごうと努めてもなお、その傾向は強く残ります。

ローカルモデルを使用する場合は、私自身が思考や計画の大部分を引き受ける必要がありますし、指示もより具体的になる必要があります。しかしながら、それは依然として優秀な研究アシスタントであり、議論の相棒であるラバードルック（Rubber Duck）であり、プログラミング言語の詳細やコマンドライン操作に関する知識を瞬時に記憶するサヴァントとして機能します。

大手 AI 企業たちが謳うような「10 倍もの生産性向上」は期待できませんが、何事かはあり、非常に興味深いものです。以下に、何がうまく機能し、何がダメかを理解するためのいくつかの基本的な例を示します。

エピソード 1：Elixir のリンター Credo のバージョン更新

Credo を最新版にアップデートすると、コード中に警告が出力されました。実験目的として Qwen に確認を依頼しました。

私：

mix credo --strict

を実行し、警告を解消する方法を提案してください。ただしコードそのものは編集しないでください。

Qwen の回答:

Credo Warnings
テストファイルに 4 つの警告が見つかりました。問題点は、リストが空でないかどうかを確認するために length/1 を使用している点です。Credo は、代わりに空リストと比較することを推奨しています。
【警告箇所】
1. test/jola_dev_web/controllers/blog_controller_test.exs:11
   - assert length(conn.assigns.posts) > 0
2. ...
3. ...
4. ...
【修正方法】
各 "length(list) > 0" を "list != []" に置き換えてください：

blog_controller_test.exs:
# Line 11
assert conn.assigns.posts != []
# Line 22
assert conn.assigns.posts != []
blog_test.exs:
# Line 10
assert posts != []
# Line 23
assert tags != []
これは Elixir の慣例に合致し、リストの長さを実際に計算するオーバーヘッドを回避できます。

Qwen に編集処理を依頼すると、4 つのパラレルな修正を非常にクリーンに行ってくれました。全体として見れば、ターミナルとエディタを行き来して行番号を確認し、手動で修正することも可能だった極めて単純なタスクでした。努力の差は大きくありませんが、利便性は確かにありました。

エピソード 2：Dependabot の Git メージ解決支援

いくつかのパッケージ依存関係を更新した結果、Dependabot から生じた PR に Git コンフリクトが発生しました。しかし Dependabot が再ベース（rebase）を拒否していました。私はそれをプルして、手動で再ベースを実行し、Qwen に確認を依頼しました。これは非常にシンプルなコンフリクトでした：それぞれの新しいバージョンを採用すればよいだけですが、モデルもその認識を示してくれました。

「私はコンフリクトを確認しています。状況は以下の通りです： HEAD（現在のブランチ）: sentry 13.0.1, tailwind 0.3.1 他の側（再ベースしようとするコミット）: sentry 12.0.3, tailwind 0.4.1 依存関係のアップデートが分岐しています。以下のいずれかの選択肢をご利用ください： オプション 1: 双方の更新を採用する（推奨）

• HEAD から sentry 13.0.1 を保持
• 他の側から tailwind 0.4.1 を保持
• これにより、両方の依存関係の最新バージョンが入手できます。 オプション 2: sentry の更新のみを採用
• sentry 13.0.1 を保持
• tailwind 0.3.1 を保持 オプション 3: tailwind の更新のみを採用
• sentry 12.0.3 を保持
• tailwind 0.4.1 を保持 どういったアプローチを選択しますか？」

しかし、実際に変更を行うように依頼すると、編集自体を行わず、単に変更を追記して再ベースを続行しようとし、コンフリクトマーカーがそのまま残ったままです。

「思考中：ユーザーは両方の更新（sentry 13.0.1 と tailwind 0.4.1）を採用したいとのこと。HEAD のバージョン（sentry）と他の側バージョン（tailwind）を保持してコンフリクトを解決し、git add を使用してファイルをステージングします。」

そして、

git rebase --continue

結論

いかがでしたでしょうか。LLM（大規模言語モデル）は極めてフレキシブルであり、ローカルで動作するモデルですらもはや「100万件の使い方」が可能です。あなたの想像力が限界です。ローカルモデルには確かに大きなトレードオフがありますが、それ以上に魅力的なメリットをもたらします：

• インターネット接続不要: 飛行機の中でも作業可能です！
• コストは電力のみ: コンピュータ購入予定であれば追加投資は必要ありません。サブスクリプション也不需要です。
• 環境負荷について: モデル学習には確かに深刻な環境コストがかかりますが、オープンソースモデルを提供する企業はまだトップクラスではありません。また、ご自身ハードウェアを使用することでデータセンターへの負荷を減らせます。
• ファニーであること: 触り甲斐があります。

LLM は私たちの世界に大きな影響を与えてきました。その影響の多くは決して良くありませんでしたが、彼らが去っていくことはないのは明らかなことです。ローカルモデルとの実験を通じて、この技術とより持続可能で前向きな形で対話できる方法を見つけることができました。正直に申せば、正しく動いてくれるかどうかにかかわらず、非常に楽しい活動なのです！