Gemma 4 × OpenCode で「とりあえず動いた」という状態から、「実務で本当に使える」状態に持っていくには、いくつかの壁があります。
コンテキストウィンドウの扱い、プロンプトの設計、どのタスクをローカルに任せてどのタスクをクラウドに任せるか、という判断基準。これらを整備しないと、「ローカルLLMって使えない」という結論に早まって到達してしまいます。
このガイドでは、Gemma 4 × OpenCode を実務レベルで活用するための具体的な方法を、私が実際に試した経験をもとにお伝えします。
Gemma 4 モデル選定：4バリアントをどう使い分けるか
Gemma 4 には4つのモデルサイズがあり、用途と環境に応じた選び方があります。
E2B（〜4GB RAM）
最小モデル。スマートフォンへの組み込みや、IoTデバイス向けです。開発用途での使用はほぼ現実的ではありません。コードタスクへの対応は限定的です。
E4B（〜8GB RAM）
エッジ向けの中型モデル。Apple Silicon Mac（M1以降）や RAM 16GB 以上の Windows PCで快適に動きます。
小〜中規模の関数実装、コードレビューのコメント生成、ドキュメント作成であれば十分な精度が出ます。API費用ゼロで使える「開発のサブエンジン」として活用するのが現実的です。
26B MoE（〜20GB VRAM/統合メモリ）
Mixture-of-Experts アーキテクチャを採用したモデルで、パラメータ数の割に高い精度を発揮します。Apple Silicon の M2 Ultra 以降や、VRAM 24GB 以上のGPUを搭載したマシンであれば動作します。
複数ファイルにまたがるリファクタリングや、設計レビューのような複雑なタスクで力を発揮します。
31B Dense（〜35GB RAM）
最高精度モデル。個人環境での運用はかなりハードルが高く、サーバーでの運用を前提にした構成です。
個人開発での推奨: E4B からスタートして、処理速度と精度のバランスを確認してから 26B MoE へ移行します。
コンテキストウィンドウの実践的な管理
ローカルLLMを使ったコーディングエージェントで最もつまずくのが「コンテキスト切れ」です。
Ollama のデフォルト設定（4,096トークン）では大型コードベースを扱うとすぐに限界に達します。以下の設定が実用的です。
# E4B 向け（RAM 16GB）
cat > Modelfile-e4b << 'EOF'
FROM gemma4:e4b
PARAMETER num_ctx 32768
PARAMETER num_gpu 99
EOF
ollama create gemma4-e4b-coder -f Modelfile-e4b
# 26B MoE 向け（RAM 32GB以上）
cat > Modelfile-26b << 'EOF'
FROM gemma4:26b
PARAMETER num_ctx 65536
PARAMETER num_gpu 99
EOF
ollama create gemma4-26b-coder -f Modelfile-26bnum_gpu 99 はGPUレイヤーをできるだけ多く使用する設定です（Apple Silicon ではほぼ全レイヤーがGPUに乗ります）。
コンテキストを節約するディレクトリ戦略
大きなプロジェクトでは、作業対象を絞り込んでからOpenCodeを起動することがコンテキスト効率の鍵になります。
# プロジェクト全体ではなく、作業するモジュールのディレクトリで起動
cd src/modules/payment
opencode
# または .opencodeignore でコンテキストに含めないファイルを指定
cat > .opencodeignore << 'EOF'
node_modules/
.next/
dist/
*.test.ts
*.spec.ts
*.log
EOFテストファイルやビルド成果物はコンテキストから除外するだけで、有効なウィンドウが大幅に広がります。
ローカルLLMに向いたプロンプト設計
クラウドLLMと同じプロンプトをローカルLLMに使っても、期待通りの精度は出ません。ローカルモデルでうまく動くプロンプトには特徴があります。
原則1：タスクをできるだけ小さく分割する
❌ 「このモジュール全体をリファクタリングして、型安全性を高め、テストも書いて」
✅ 「fetchUser 関数の戻り値の型を User | null から Result<User, ApiError> に変更してください。
変更するのはこのファイルだけです。」
ローカルモデルは大きなタスクで散漫になりやすいです。1回のプロンプトで1つの明確なタスクに絞ることで精度が安定します。
原則2：出力形式を明示する
以下の関数に JSDoc コメントを追加してください。
出力形式: 元のコードに JSDoc コメントを追加した完全なコードのみ。説明文不要。
[コード]
「説明文不要」と明示することで、モデルが回りくどい説明を生成する傾向を抑えられます。
原則3：参照するファイルを明示する
OpenCode では @ファイル名 でファイルを参照できます。
@src/types/user.ts @src/api/fetchUser.ts を参照して、
fetchUser の戻り値の型エラーを修正してください。
「コードベース全体を見て」ではなく、具体的なファイルを指定することで処理が安定します。
クラウドとローカルのハイブリッド運用
実務で最もバランスが取れるのは、タスクの重要度と機密性に応じてモデルを使い分けるハイブリッド構成です。
ローカル（Gemma 4）に任せるタスク
- コメント・ドキュメント生成
- 小規模な関数実装（50行以内）
- 変数名・関数名のリネーム提案
- 単純なバグ修正（エラーメッセージが明確なもの）
- ボイラープレートコードの生成
クラウド（Claude / Gemini）に任せるタスク
- 設計判断が必要な実装
- 複数ファイルにまたがるリファクタリング
- セキュリティ関連のコードレビュー
- 複雑なアルゴリズムの実装
- 公開コードや機密性の低いプロジェクト全般
この判断基準を CODING_POLICY.md としてプロジェクトルートに置いておくと、チームでも個人でも判断の一貫性が保てます。
OpenCode の設定を複数プロファイルで管理する
複数のプロバイダーを使い分ける場合、プロファイルで設定を管理するのが便利です。
// ~/.config/opencode/config.json
{
"profiles": {
"local-fast": {
"provider": "ollama",
"model": "gemma4-e4b-coder",
"baseUrl": "http://localhost:11434"
},
"local-quality": {
"provider": "ollama",
"model": "gemma4-26b-coder",
"baseUrl": "http://localhost:11434"
},
"cloud": {
"provider": "anthropic",
"model": "claude-sonnet-4-6"
}
},
"defaultProfile": "local-fast"
}プロファイルの切り替えは次のコマンドで行います。
opencode --profile cloudGemma 4 の日本語コード対応について
Gemma 4 は日本語対応が大幅に改善されており、コメントやドキュメントを日本語で生成させても自然な文章が出てきます。
ただし、コード変数名を日本語で混在させるような指示では精度が落ちます。「コメントは日本語で、変数名は英語で」という明示的な指定を入れると安定します。
以下のコードに日本語コメントを追加してください。
変数名・関数名は変更しないでください。
[コード]
全体を振り返って：ローカルLLMは「制約の中のツール」として活用する
Gemma 4 × OpenCode を実務で使う上で大切なのは「クラウドモデルの代替」として見ないことです。「特定の条件下でコスト0で動くサブエンジン」として位置づけることで、その価値が明確になります。
モデル選定・コンテキスト管理・プロンプト設計の3点を整えると、ローカル環境でも想定以上に使える体験になります。まずは E4B で動かしてみて、自分の開発フローのどこに組み込めるかを探してみてください。