見出し画像

ローカルで動くAIが、ここまで来た——Gemma 4とOllamaで作るゼロコストのコーディング環境なぜ今、ローカルLLMなのか

スネドラ

AIを使ったコーディング支援は、もはや特別な話ではありません。多くのエンジニアが日常的にClaude CodeやGitHub Copilotを活用し、コードの生成・レビュー・デバッグを行っています。しかし、クラウドAPIへの依存には見えにくいコストがあります。トークン消費課金、社内コードを外部サービスに送ることへのセキュリティ上の懸念、ネットワーク遅延——これらは小さなストレスの積み重ねであり、場合によっては組織的な制約にもなり得ます。

2026年4月、その状況が変わりました。Googleが公開したGemma 4は、オープンウェイトモデルとして初めて「ローカル実行でも実用的なコーディング支援ができる」レベルに達したと言われています。そしてそれを手元で動かすツールがOllamaです。

この記事では、George LiuがSubstackで公開した実践ガイド「Running Google Gemma 4 With Ollama, Claude Code, OpenCode, Codex: Complete Local Setup」をもとに、Gemma 4とOllamaのセットアップから、Claude Code・OpenCode・Codex CLIとの連携まで、IT中級者が再現できる形で解説します。

クラウドへのデータ送信なし。APIキーも課金も不要。今日から使えるゼロコストのローカルAI開発環境を、一緒に構築してみましょう。

Gemma 4とは何か——なぜ今回が違うのか

Googleが公開したオープンウェイトモデルの最新版

Gemma 4は、2026年4月2日にGoogleが公開したオープンウェイトLLMシリーズの第4世代です。「オープンウェイト」とは、モデルの重みファイル（パラメータ）が公開されており、手元のPCやサーバーで自由に実行できることを意味します。ChatGPTやClaudeのようなクローズドモデルとは異なり、インターネット接続なしでも動作します。

Gemma 4のラインナップは複数あります。パラメータ数の観点では、**2B・4B（軽量版）と26B・31B（高性能版）**に大別されます。ここで注目すべきは、26Bモデルのアーキテクチャです。

Mixture-of-Expertsが生む「コスパの逆転」

Gemma 4の26Bモデルは、**Mixture-of-Experts（MoE）**と呼ばれるアーキテクチャを採用しています。MoEとは、モデル全体のパラメータのうち、実際に推論時に活性化するのは一部だけという設計です。

Gemma 4の26B-A4Bモデルの場合、総パラメータ数は25.2Bですが、1トークンを生成する際に実際に使われるのはわずか3.8B相当です。つまり、見かけ上は26Bのモデルでありながら、実行コストは4B級という「コストパフォーマンスの逆転」が起きています。

George Liuのガイドでは、この26B-A4BモデルがMacBook Pro M4 Pro（48GBメモリ）において約10〜15トークン/秒で動作すると報告されています。応答速度としては「少し待つ」感覚ですが、タイピングを読んでいる程度のラグで、実際のコーディング支援としては十分実用的です。

よくある失敗パターン：モデル選択のミス

ここで多くの人が最初につまずくのが、「とにかく大きいモデルを選べばいい」という思い込みです。

31Bモデルを選んだ場合、量子化（モデルの圧縮）の程度によっては16GB程度のメモリで動くこともありますが、速度が著しく低下します。また、メモリ不足になるとOSがディスクへのスワップを始め、推論速度が数トークン/秒以下に落ちることもあります。George Liuの実験でも、48GBマシンで26Bの64Kコンテキスト設定を使ったところ、ディスクスワップが発生したと記録されています。

推奨の判断基準：

  • メモリ8〜16GB → gemma4:4b（量子化版）を使用

  • メモリ24〜32GB → gemma4:12bが現実的な上限

  • メモリ48GB以上 → gemma4:26bがスイートスポット

Ollamaとは——ローカルLLM実行の標準ツール

CLIで始める、最もシンプルな構成

Ollamaは、ローカル環境でLLMを実行するためのオープンソースツールです。Mac・Windows・Linuxのすべてに対応しており、インストールは公式サイト（ollama.com）からダウンロードするだけです。

インストール後、ターミナルで以下のコマンドを実行するだけでGemma 4が起動します。

ollama run gemma4

初回実行時はモデルのダウンロードが自動で行われます。デフォルトでは最もサイズの小さいバリアントが取得されます。特定のサイズを指定したい場合は以下のようにします。

ollama pull gemma4:26b

モデルの保存場所を変更する

MacBookのような内蔵SSDが限られたマシンでは、モデルファイルの保存先を外部ドライブや容量の大きいパスに変更したいケースがあります。Ollamaは環境変数`OLLAMA_MODELS`でこれを制御できます。

export OLLAMA_MODELS=/Volumes/ExternalDrive/ollama-models

`.zshrc`や`.bashrc`に追記しておくと、次回以降も有効になります。

Modelfileでカスタムモデルを作る

Ollamaの強力な機能のひとつがModelfileです。これはDockerfileに似た設定ファイルで、ベースモデルにパラメータをオーバーライドして新しいモデルを定義できます。

George LiuのガイドでとくにハイライトされているのがContext Window（コンテキストウィンドウ）の拡張です。OllamaのデフォルトはわずかなContext Windowしか持ちませんが、Modelfileで64Kトークンに拡張することができます。

printf 'FROM gemma4:26b\nPARAMETER num_ctx 65536' > /tmp/Modelfile-64k
ollama create gemma4-26b-64k -f /tmp/Modelfile-64k

このコマンドでは、`gemma4:26b`をベースに`num_ctx 65536`（64,000トークンのコンテキストウィンドウ）を設定した新しいモデル`gemma4-26b-64k`を作成しています。

なぜContext Windowが重要なのか：コーディング支援の場面では、長いコードファイルや複数ファイルの内容をまとめてモデルに渡すことになります。Context Windowが短いと、ファイルの後半が切り捨てられたり、過去の会話を「忘れて」しまったりします。64Kトークンは、中規模のコードベースでも十分カバーできるサイズです。

3つのコーディングエージェントとの連携

構造を理解する：Ollamaが提供するAPIエンドポイント

Ollamaを起動すると、ローカルにOpenAI互換のAPIエンドポイントが立ち上がります（デフォルトは`http://localhost:11434/v1`）。つまり、OpenAI APIに対応しているツールであれば、エンドポイントURLを書き換えるだけでOllamaのモデルが使えるようになります。この仕組みがClaude Code・OpenCode・Codex CLIとの連携を可能にしています。

第1の連携——Claude Code

Claude Codeは、Anthropicが提供するCLIベースのコーディングアシスタントです。デフォルトではAnthropicのクラウドAPIを使用しますが、以下の環境変数を設定することでOllamaのエンドポイントに切り替えられます。

export ANTHROPIC_BASE_URL=http://localhost:11434/v1
export ANTHROPIC_API_KEY=ollama

`ANTHROPIC_API_KEY`の値は実際のキーである必要はなく、`ollama`のような任意の文字列で構いません（ローカルのOllamaサーバーはキーの検証を行わないためです）。

v0.15以降のOllamaでは、`launch`コマンドによってより簡単に起動できます。

ollama launch claude --model gemma4-26b-64k

このコマンドはClaude Codeを起動しつつ、モデルとして`gemma4-26b-64k`を使用するよう自動設定します。

注意点：Claude Codeはモデルのレスポンスが特定のフォーマットに従うことを期待しています。Gemma 4との相性は概ね良好ですが、ツール呼び出し（tool_use）の部分でときどき応答フォーマットのズレが生じる場合があります。こうした問題が起きた場合は、Modelfileにシステムプロンプトを追加してモデルの挙動を調整することが有効です。

第2の連携——OpenCode

OpenCodeは、Claude CodeのオープンソースAlternativeとして注目を集めているCLIエージェントです。Ollamaとの相性が良く、設定ファイル（`~/.config/opencode/config.json`）にプロバイダーとして追加するだけで使えます。

{
  "providers": {
    "ollama": {
      "baseUrl": "http://localhost:11434/v1",
      "models": ["gemma4:26b"]
    }
  },
  "defaultProvider": "ollama",
  "defaultModel": "gemma4:26b"
}

OpenCodeはツール呼び出しのフォーマット要件がClaude Codeほど厳密でないため、Gemma 4との組み合わせでより安定した動作が期待できます。George Liuのガイドでも、OpenCodeはGemma 4との連携においてスムーズに機能したと記録されています。

第3の連携——Codex CLI

Codex CLIは、OpenAIが公開したCLIベースのコーディングエージェントです。OpenAI互換APIをサポートしているため、環境変数でOllamaに向け直すことができます。

export OPENAI_BASE_URL=http://localhost:11434/v1
export OPENAI_API_KEY=ollama
codex --model gemma4:26b

3つのエージェントの中では最もシンプルな設定で済みます。ただし、Codex CLIはOpenAIのモデルを前提に設計されているため、一部の高度なツール呼び出し機能がGemma 4では動作しないケースがあります。基本的なコード生成や説明のタスクには十分使えるレベルです。

エージェント選択のポイント

どのエージェントを選ぶかは、目的と許容できる設定の複雑さによります。以下の観点で整理すると判断しやすくなります。

Claude Codeを選ぶ場合：すでにClaude Codeのワークフローに慣れており、同じUXでローカルモデルに切り替えたいとき。

OpenCodeを選ぶ場合：オープンソースのツールを優先したい、またはGemma 4との安定性を重視するとき。

Codex CLIを選ぶ場合：シンプルな設定で試してみたい、またはOpenAIのエコシステムとの親和性を重視するとき。

実際に使ってみると——Before/Afterで見る変化

Before：クラウドAPIへの依存と見えないコスト

クラウドAPIを使ったコーディング支援には、慣れてしまうと気づきにくい問題があります。

ひとつはコストです。日常的に使えば月に数千〜数万円のAPI料金が発生することもあります。プロジェクトが増えるにつれてトークン消費量は線形に伸び、チームで使えばさらに倍増します。

もうひとつはデータのプライバシーです。クライアントのコードや社内の独自ロジックを外部サービスに送ることは、利用規約上は問題なくても、組織のポリシーや顧客との契約によっては制約がある場合があります。「確認してから使う」手間がストレスになることも少なくありません。

さらに、ネットワーク依存という問題もあります。オフライン環境や通信状態が不安定な場所では、クラウドAPIは使えません。新幹線の中や地下での作業、海外出張中の不安定なWi-Fi——こうしたシーンでAI支援が使えなくなるのは、一度体験すると意外とストレスになります。

After：ローカル実行で変わること

Gemma 4とOllamaの組み合わせでこれらの課題がどう変わるか、具体的なシナリオで見てみましょう。

【シナリオ1：社内ツールの開発】

社内の決済システムに接続するAPIラッパーを書いているとします。コード中には接続先のURLや認証フローが含まれており、外部サービスに送ることに躊躇していました。ローカルLLMなら、そのコードをそのままコンテキストに渡せます。「この認証フローにリフレッシュトークンの処理を追加して」という依頼が、セキュリティの懸念なしに実行できます。

【シナリオ2：移動中のコーディング】

新幹線での移動中、急に思いついた実装を試したくなりました。オフラインでもOllamaは動作します。`ollama run gemma4:4b`で軽量モデルを起動し、OpenCodeと組み合わせればCLI上で対話しながらコードを書けます。ネットワークがなくても、AIとのペアプログラミングが続けられます。

【シナリオ3：コスト管理】

個人開発のサイドプロジェクトを持つエンジニアにとって、月額API費用は小さくない負担です。ローカルLLMに切り替えることで、試行錯誤のコストがゼロになります。プロトタイプ段階ではローカルで開発し、品質が求められる最終確認だけクラウドAPIを使う——という使い分けが現実的な選択肢になります。

実践に向けて——システム全体の整理と次のステップ

環境構築のまとめ

ここまでの内容を整理すると、Gemma 4 × Ollamaのローカル環境は以下のような構成で成り立っています。

基盤レイヤー（Ollama）：LLMの実行エンジン。モデルの管理・ダウンロード・APIサーバーの提供を担当します。

モデルレイヤー（Gemma 4）：推論を行うモデル本体。ハードウェアに合わせてバリアントを選択します。Modelfileでコンテキストウィンドウなどのパラメータを調整します。

エージェントレイヤー（Claude Code / OpenCode / Codex CLI）：ユーザーとのインタラクションを担当するCLIツール。OllamaのAPIエンドポイントを向き先として設定するだけで利用できます。

よくある疑問

Q. Gemma 4はコーディング以外にも使えますか？

はい。Gemma 4は汎用LLMですので、コーディング支援に限らず、文書の要約・翻訳・質問応答など幅広いタスクに使えます。ただし、コーディング支援の品質については、最新のクラウドモデル（Claude Opus、GPT-4oなど）と比較するとまだ差があります。「課金なしで使える実用レベルのAI」として位置づけるのが適切です。

Q. GemmaとGeminiは違うものですか？

はい、別物です。Geminiは、GoogleのクラウドサービスとしてAPI経由で提供されるモデルです（課金が発生します）。Gemmaは、重みファイルが公開されているオープンウェイトモデルで、手元のマシンで無料で動かせます。名前が似ていて混同しやすいので注意が必要です。

Q. どのくらいのメモリがあれば実用的に使えますか？

実用的な下限は8GBです。この場合、gemma4:4bの量子化版（Q4_K_Mなど）を使います。16GBあれば快適に動作します。24GB以上なら12Bモデルも視野に入ります。

次のステップ

環境を構築したら、まず簡単なタスクから試してみることをおすすめします。既存のコードにテストを追加してもらう、コメントを書いてもらう、短いスクリプトをリファクタリングしてもらう——こうした小さなタスクで感触をつかんだ上で、より複雑な用途に広げていくのが確実です。

また、Ollamaには活発なコミュニティがあり、最適なModelfile設定や量子化バリアントの選び方についての情報が日々更新されています。公式ライブラリ（ollama.com/library/gemma4）も参照しながら、自分の環境に合った設定を探してみてください。

まとめ——ローカルAIが「選択肢」になる時代

Gemma 4とOllamaの組み合わせは、ローカルLLMをはじめて「現実的な選択肢」として提示してくれました。すべてのタスクをローカルで完結させる必要はありません。重要なのは、「クラウドしか使えない」という制約がなくなったことです。

コスト・プライバシー・オフライン対応——それぞれの理由でクラウドAPIに不満を持っていたエンジニアにとって、今がローカルLLMを試す最良のタイミングです。

George Liuのガイドは、単なるセットアップ手順に留まらず、各エージェントとの接続方法やハードウェアごとの現実的なパフォーマンスまで丁寧にカバーされています。英語での原文に興味がある方は、ぜひ元記事もあわせて参照してみてください。

まずは`ollama pull gemma4:4b`の一行から、あなたのローカルAI環境が始まります。

参考記事：Running Google Gemma 4 With Ollama, Claude Code, OpenCode, Codex: Complete Local Setup by George Liu

いいなと思ったら応援しよう！