OpenClawを家庭用アシスタントとして使っていて、また実験的に分子シミュレーションをやらせたりしていたのですが、APIコストはどうしてもかかってきます。
そんな中でリリースされたGemma4はローカルLLMとしてかなりの性能で、OpenClaw等のAIエージェント界の救世主みたいな扱いを受けているわけですが、Gemma4のE2Bではエージェントとして力不足、E4Bも厳しい、まともに使えるのは26Bと31Bである、というのが私の結論です。
設定手順
すでにOpenClawを使用中である場合は以下の手順です。
ollama pull gemma4:26b等のコマンドでモデルをダウンロードする。openclaw configコマンドでModelとしてollamaを設定する。- OpenClawでチャットをしてみる。
- RAM不足を感じたらコンテキストウィンドウを調整する。
コンテキストウィンドウの調整方法
ローカルLLMとして動かす場合は、デフォルトのコンテキストウィンドウが大きすぎてRAMが足りなくなる場合があります。RAM不足を感じた場合は手動設定によってコンテキストウィンドウを小さくする必要があります。.openclaw/openclaw.jsonの中身のmodelsでcontextWindowを設定する例は以下の通り。
{
"id": "gemma4:e2b",
"name": "gemma4:e2b",
"reasoning": false,
"input": [
"text"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 20000,
"maxTokens": 8192
},コンテキストウィンドウには確か下限値があり、16,000 token以上の数字を入れる必要があったと思います。上記の例は20,000 tokenです。
書き換えたらシェルでopenclaw gateway restartを実行します。
OpenClawでチャットを開始するとollamaがRAMやVRAMを確保しだすので、ollama psやタスクマネージャーなどを見てRAMの量を確認しましょう。
Gemma4の小型モデルの場合
ノートPCやスマホでも動くと言われているE2BやE4Bモデルですが、これらをエージェントとして動かすのは厳しいです。
E2Bでエージェントを動かした場合
エージェントのモデルとしてGemma4:E2Bを設定してDiscordで会話を始めても、会話が成立しません。なぜかというと、パラメータ数が少ないLLMはシステムプロンプトで頭がいっぱいになって会話に集中できないからです。
OpenClawのセッションでは、多くの場合でAGENTS.mdやIDENTITY.mdといったworkspace以下にあるmdファイルをシステムプロンプトとして読み込みます。つまり、新しいセッションを始めた時点でかなりの量のコンテキストが占領されてしまいます。/newセッションを開始した時点で/statusを実行してみると、すでにコンテキストが12kくらい埋まっているのが確認できると思います。
ollama run gemma4:e2bでチャットを開始した場合はこのシステムプロンプトがほぼ無いため、そこそこ会話ができるのです。OpenClawのエージェントとして動かすと最初からコンテキストがいっぱいで、会話をスタートした時点でかなり頭が悪い感じになってしまいます。
そんな頭の悪いエージェントにexecコマンドやファイルeditを任せられますか？無理ですね。
ただ、システムプロンプトを減らすことは有効かもしれません。しかし削りすぎるとエージェントとして機能しなくなる恐れがあるので、試すなら自己責任でやってください。
E4Bでエージェントを動かした場合
こちらもE2Bと同様の問題があるのですが、上手にプロンプトを与えるとE4Bは動く場合があります。短くしたシンプルなシステムプロンプトを用意しておいて、与えるタスクもシンプルなものに限定すれば使える場合があります。用途によりけり。このモデルでOpenClawを使いこなすノウハウは需要がありそうですね。
賢いエージェントを諦めて、多数・高頻度の単純作業に特化したAIエージェントとしてならE4Bは価値があるかもしれません。
8GB・16GBのRAMで動かせるのはここまで
ollamaはVRAMに収まらない部分をRAMに載せてくれるので、RAM+VRAMが8-16GBくらいの環境の場合は、上記のコンテキストウィンドウ設定した場合はE2BやE4Bを動かすのが限界です。
「16GBのMacMiniで無料でOpenClawが使い放題！！」というのは夢のある話なんですが、エージェントとしての能力はとても低く、現実はそんなに甘くありませんでした。
本命はGemma4:26B
Gemma4:26Bはエージェントとしてしっかり働いてくれます。これですよこれ。このモデルが動く環境であればローカルの使い放題エージェントが作れるわけです。
もちろん31Bはより高性能なわけですが、高性能なだけあって推論は遅いです。26と31で数字だけ比べると差はないのですが、構造が全然違うらしいです。裏を返すと、26Bは非常に大きいパラメータ数のものを効率よく動かすように設計されています。私はこのGemma4:26Bが性能と速度を両立するエージェント用ローカルLLMだと考えています。
参考までに、openclaw.jsonは
{
"id": "gemma4:26b",
"name": "gemma4:26b",
"reasoning": false,
"input": [
"text"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 64000,
"maxTokens": 8192
},ollamaが使用しているRAMは
ollama ps
NAME ID SIZE PROCESSOR CONTEXT UNTIL
gemma4:26b 5571076f3d70 24 GB 72%/28% CPU/GPU 64000 2 hours from nowSIZE 24GBというのは、contextWindow 64000を設定した場合の値です。contextWindowを大きくすればもっとRAM使用量は増えるし、小さくすると減ります。環境や使い方によってcontextWindowは調整するといいと思います。
私のこの環境はRAM 48GB、VRAM 8GBです。プロセスが使用する24GBはVRAMに乗りきらず、RAMを併用することでCPUとGPUのハイブリッド動作になります。API利用と比べると当然遅いですが、全然使えます。
26Bのエージェントとしての性能
Gemini 2.5 FlashかProくらいの性能はあるんじゃないかなと個人的には思っています。会話も成立するし、与えた指示もこなしてくれるし、チャット履歴の記憶力もしっかりあります。たまに融通が利かないことがありますが、セッションを/newしたり与えるプロンプトを工夫してやると、一応思い通りに動いてくれます。
多段階のプロセスや高度なコーディングをやらせようとすると31Bのほうがいいのだと思いますが、やはり26Bが速度と性能を両立するベストなモデルなのではないかなと思います。
また、26Bが動く環境なら31Bも調整次第では動く場合が多いと思います。ここぞという時のために31Bも使えるようにしておくといいと思います。
結論：8GBや16GBでエージェントは動かない
E2Bはほぼ動かないと言って良く、E4Bは動きはするけどユーザをサポートしてくれる有能エージェントとは言い難い。したがってこれらを動かすのが限界である8GBや16GBくらいのRAM環境では満足のいくエージェントは動かない、というのが結論です。
一方で、RAMとVRAMを足して24GB以上余裕があればGemma4:26Bを64kbのコンテキストウィンドウで動かすことができ、このレベルだとかなりいい感じにエージェントとして使うことができます。
コメント