16GB VRAMでもローカルLLMは実務に届くのか。2か月の検証で見えたこと

こんにちは、クライアントエンジニアの平野孝明です！

コロプラではAI活用を広げる取り組みを進めており、以前には AI駆動開発に向けた取り組み - AI推進組織の発足とCursorの導入という記事も公開しました。そうした流れの中で、私はここ2か月、ローカルLLMを実務でどう活かせるかを検証してきました。

今回の検証で対象にしたのは、CI/CD基盤まわりの社内の問い合わせ対応と、CI/CDのエラーログ調査です。どちらも情報量が多く、外部サービスにそのまま預けにくい情報が含まれることがあります。そのため、ローカルで完結できる選択肢がどこまで実務に届くかを見ました。

結論から言うと、2026年春時点では 16GB VRAM の GPU でも、用途を絞ればローカルLLMは実務で使える水準に届いています。問い合わせ対応では、必要な情報を聞き返しながら状況を整理でき、CI/CD ジョブの失敗ログなどを扱う場面では入力が長くなるほど API コストを気にしやすいので、ローカルで完結できること自体に大きなメリットがありました。

この記事では、問い合わせ対応で必要な情報を過不足なく聞き返せるか、エラーログ調査で原因候補と次の切り分け方針を返せるか、という観点から見た実用性を共有します。

検証条件

検証の前提は次のとおりです。

項目	内容
OS	Windows
GPU	RTX 5070 Ti（より大きなモデルを試す場面では RTX 5090 も利用）
モデル形式	GGUF(※1)、4bit 量子化(※2)
推論基盤	LM Studio
AIエージェント	OpenCode(※3)

※1 GGUF は、llama.cpp 系の推論ランタイムで広く使われているモデル配布形式です。

※2 4bit 量子化は、モデルの重みを 4bit 相当で保持して VRAM 使用量を下げる手法です。一般に、メモリ効率と引き換えに精度などに影響が出ます。

※3 OpenCode は、モデルに read や search のようなツールを呼ばせるためのエージェント実行環境として利用しました。今回の検証では、このハーネス越しにツール呼び出しの安定性も見ています。

初期検証における Qwen2.5 の評価

最初に利用したのは Qwen2.5-14B です。単発の回答生成や、短いやり取りを前提にした対話であれば、十分に使える感触がありました。ローカル環境でも気軽に回せますし、応答の雰囲気も悪くありません。

一方で、問い合わせ対応はそれほど素直ではありません。実際の相談は前提が曖昧なことも多く、必要な情報を聞き返しながら意図をつかむ必要があります。その段階になると、Qwen2.5 ではプロンプトの影響を強く受けすぎて、場面に応じた切り替えが難しいことがありました。またSlackでのやり取りを想定しているのですが文脈を無視して長文を送るなど、対話全体が重く感じられるケースも散見されました。

エラーログ調査向けの AIエージェントについてはさらに厳しく、OpenCode等のサードパーティのAIエージェントでは基本的に動作せず、フルスクラッチで ReAct フローを組み、ツールを read と search に絞り、compaction の調整等も試しましたが、無限ループが毎回のように発生しました。少し試す分には面白いのですが、業務で継続的に使うにはまだ不安が残る、というのが当時の率直な感想です。

Qwen3.5 で確認できた進展と GPU コストの課題

次に試した Qwen3.5-4B や Qwen3.5-9B、さらに Qwen3.5-27B と Qwen3.5-35B-A3B では印象がかなり変わりました。Qwen3.5 の公開は 2026年2月15日で、今回の検証期間 2か月とほぼ重なる時期に出てきたモデルです。Qwen2.5 の頃よりも破綻しにくくなり、会話のつながりやツール利用の安定性も改善しています。少なくとも「ローカルLLMで AIエージェントはまだ早い」と一括りには言えなくなりました。

ただ、モデルサイズによる差はかなりはっきり出ました。Qwen3.5-27B や Qwen3.5-35B-A3B であれば、問い合わせ対応向けのチャット応答で、Slack に貼りやすい形で要点を整理しやすく、用途を広げやすい感触がありました。エラーログ調査でも、プロンプト設計に加えてログのチャンク分割やノイズ除去の前処理を組み合わせることで、原因候補の精度をある程度担保できました。

一方で、4B や 9B では問い合わせ対応で、Slack で返信するための文を構造化するのがやや苦手で、要点の並べ方や文のまとまりが崩れやすいことがありました。また、エラーログ調査では基本的なエラーであれば答えられるものの、複合的な内容の理解はまだ難しい印象でした。

ただし、27B や 35B のような上位モデルを 16GB VRAM の環境では、そのまま快適に扱いにくいという別の壁があります。今回利用した 16GB VRAM の環境では、扱いやすいモデルサイズは 24B 前後が一つの目安のため、27B や 35B を 5070 Ti で扱うと、モデルの一部を GPU に載せきれず CPU 側でも処理する CPU オフロードが発生して速度が劇的に落ち、実務で待てる範囲に収まりませんでした。そのため、実務で 27B や 35B を利用する場合は 5090 のようにより大きな VRAM を持つ GPU が必要でした。

Jenkinsがエラーで動かないケースでの問い合わせの応答性能

モデル	GPU	出力速度	VRAM	CPU オフロード
Qwen3.5-27B	RTX 5070 Ti	0.65 tok/s	15.5 GB	あり
Qwen3.5-27B	RTX 5090	66.5 tok/s	19.6 GB	なし

ローカルLLMを実務の選択肢として考えるなら、この差は小さくありません。クラウドAPIであればモデルを切り替えるだけで済む話も、ローカルでは GPU の調達コストに直結します。性能だけを見れば上位モデルに手を伸ばしたくなりますが、ローカルLLMを基盤に組み込むことを考えると、会社として負担するコストは無視しにくいと感じました。

Gemma 4 が示した 16GB VRAM の実用可能性

そこで改めて印象を変えたのが Gemma 4 です。3月31日に Google は Gemma 4 が出たと同時に function calling のガイドも公開しており、Gemma 4 でツール利用を前提にしたユースケースに力を入れていることが分かります。あわせて公開した Gemma 4 model overview では、gemma-4-26B-A4B の 4bit 推論メモリ要件がおおよそ 15.6GB と案内されています。この数字を見たとき、5070 Ti でも利用できる可能性を感じました。

しかし、カタログ上のメモリ要件と実運用での制約にはギャップがあります。実運用ではモデルの重みだけでなく、推論時に必要な KV キャッシュも確保する必要があるという点です。16GB VRAM を積んだ 5070 Ti でも、モデルの重みとその推論時に必要な KV キャッシュを合計すると 16GB を超えてしまいます。そのため、gemma-4-26B-A4B をそのまま載せると CPU オフロードが発生し、実務で期待する速度には収まりませんでした。カタログ上は 16GB 級の GPU でも届きそうに見えても、実際はVRAMが足りませんでした。

そこで利用したのが unsloth/gemma-4-26B-A4B-it-UD-IQ4_XS です。通常の gemma-4-26B-A4B をそのまま使うのではなく、このような量子化済みの派生モデルを使うことで、16GB VRAM の 5070 Ti に収まる構成が取れました。通常の gemma-4-26B-A4B や Qwen3.5-27B と比較しても、unslothの量子化モデルは 5070 Ti でも速度が十分に出て、ツール呼び出しの性能が落ちていると感じませんでした。課題は多いですがOpenCode のようなサードパーティ製ハーネスでも、ローカルで Agent 的な振る舞いを試すハードルが一気に下がった印象があります。

もちろん、5090 で31B のようなさらに大きなモデルや 8bit 量子化のように量子化を浅くした構成を必要な場面で利用する余地はあります。ただ、今回の検証で大きかったのは、「16GB VRAM では厳しい」という見方を崩せたことでした。少なくとも、問い合わせ対応やログ調査のような実務に近いタスクであれば、5070 Ti クラスでも現実的なラインに入ってきたと感じています。

実務利用可否の評価基準

今回の評価では、ベンチマークのスコアよりも実務での使い勝手を重視しました。問い合わせ対応では、曖昧な相談文に対して追加のヒアリングを返しながら意図を外さないことに加えて、Slack に貼れる形で返答をまとめられるか、初回応答時間と完了時間が業務で待てる範囲に収まるかを見ています。

エラーログ調査では、前後関係を追いやすい粒度にチャンク分割したログを入力にし、要約にとどまらず原因候補と次の切り分け方針まで正確に返せるかを確認しました。あわせて、無限ループ率と完了時間も評価しています。

どちらのタスクも代表的なケースを用意し、モデルごとの差が見えやすい形で比較しました。問い合わせ対応は数値だけでは差が伝わりにくいため、同じプロンプトに対する回答例も並べて掲載しています。

問い合わせ対応の比較

ここでは、同じ相談文に対するモデルの出力と応答時間をそのまま掲載しています。確認したい情報を過不足なく挙げられているかに注目すると、モデルごとの特徴が分かりやすくなっていると思います。

# ルール
あなたは社内横断で様々な問題に対応する基盤グループの一員です。
窓口として基盤グループの担当者に回す前に質問者の情報が足りているかを精査してください。
特に対応期限と、期限が近い場合は温度感は必ずヒアリングしてください。
関連ビルドのURL、発生日時、最後に成功したのはいつ頃か、失敗前後で何か特殊な操作やコミットはしなかったか、質問者の方で何か調査を行ったかなど臨機応変にヒアリングしてください。
ヒアリングの情報が集まったら担当者にエスカレーションをおこなってください。
# 質問
【至急】
今日の午後から、Jenkinsがエラーで止まっています。
ログがないのですが何をおこなえばよいですか？

Qwen2.5-14B

了解しました。まずは状況を把握するためにいくつか質問させていただきます。

1. エラーメッセージや具体的な症状について詳しく教えていただけますか？
2. エラーが始まった正確な時間はいつ頃でしょうか？
3. この問題が発生する前から何か変更（設定の更新、システムアップデート等）をされたことはありますか？
4. その他の関連する情報やヒントがあれば教えてください。例えば他のユーザーに影響しているかどうかなど。

これらの情報を得ることで、より正確な対応が可能になります。また、エラー発生時の詳細情報は問題解決の鍵となることが多いので、ログがない場合でも可能な限り多くの情報を提供いただけると助かります。

応答時間 3.6 秒

Qwen3.5-9B

承知いたしました。至急とのことですので、焦っていらっしゃると考えますが、基盤グループへエスカレーションし、最短で解決につなげるためにも、以下の情報を精査していただく必要があります。
現状では情報が不足しており、担当者へ回しても適切な対応が難しくなるため、一旦ヒアリングを行うこととなります。

お手すきの際にご確認・ご回答いただけますでしょうか。

**1. 期限と影響範囲（温度感）**
「至急」とのことですが、具体的にどのタイミングまでに修復が必要です么？（例：本番環境のビルド待ちで明日のリリースに影響がある等）
また、現在止まっていることでどれくらいの工程に支障が出ていますか？

**2. Jenkins に関する詳細情報**
*   **障害対象:** エラーが出ているジョブやプロジェクト名を具体的に教えてください。
*   **URL:** 該当するビルドページまたはダッシュボードの URL を共有いただけないでしょうか？
*   **発生タイミング:** 「今日の午後から」とのことですが、具体的な開始時刻と、最後に見た画面の状態（何のステージで止まっているか）はわかりますでしょうか？

**3. 最近の変更状況**
*   **成功履歴:** 過去に最後のビルドが成功したのはいつ頃でしたか？
*   **コミット・変更:** エラー発生前直近で、コードのコミットや設定ファイル（Jenkinsfile など）の変更はありましたでしょうか？
*   **環境操作:** ジョブの設定変更、ビルドエージェントのリセット、キャッシュクリアなどの特殊な操作はありませんでしたでしょうか？

**4. ログに関する詳細**
「ログがない」とのことですが、具体的にはどうなっているでしょうか？
*   UI 上の Console Output に何も表示されないのか？
*   ビルドは開始された後すぐにエラー画面になるのか、それとも無限ループか？
*   ジョブの状態（成功/失敗/ビルド中/実行停止）のステータスは確認できる状況ですか？

以上が集まるとすぐに基盤グループへエスカレーションいたします。
焦っておりますので、お手数をおかけしますとぞっとお伝えいただきつつ、ご回答をいただけますと幸いです。

応答時間 23.04 秒

Qwen3.5-27B

お問い合わせありがとうございます。基盤グループの窓口として拝受いたしました。

「至急」とのことですので、担当技術者に迅速にエスカレーションさせていただくために、現状の状況をより詳細にヒアリングさせていただきます。以下の情報をいただけますでしょうか？

1.  **対応期限と緊急度（温度感）**
    *   ビジネスインパクトはどの程度ですか？（例：本番リリースが止まっている、開発全員の作業停止など）
    *   具体的な納期や期限はありますか？
2.  **対象となる Jenkins インスタンス**
    *   関連するビルドの URL または Jenkins サーバーのアドレスはどのページでしょうか？
3.  **発生日時の特定**
    *   「今日の午後から」とのことですが、初めてエラーに気づいた正確な時刻（またはビルドが失敗し始めた時刻）はありますか？
4.  **成功していたタイミング**
    *   最後に正常に動作した（ビルド成功した）のはいつ頃でしょうか？
5.  **前後の変更点・操作**
    *   エラー発生前後で、Jenkins の設定変更や、特定のコミットのマージ、インフラ側の特殊な操作などは行われませんでしたか？
6.  **質問者様での調査状況**
    *   「ログがない」の具体的内容について（例：ビルド履歴画面の「Console Output」も開けないのか、エラーメッセージが表示されるが原因不明なのか）。
    *   ブラウザコンソールやエージェント側の確認などは行われておりますでしょうか。

以上の情報をお送りいただければ、担当技術者へ適切にエスカレーションし、早急な対応を進めさせていただきます。
お手数ですが、ご返信いただけますようお願い申し上げます。

応答時間 580.62 秒 (約 9 分 41 秒)

gemma-4-26B-A4B UD-IQ4_XS

ご相談ありがとうございます。基盤グループの窓口担当です。

状況を拝見いたしました。「至急」とのことですので、早急に担当者へエスカレーションし、調査を開始できるよう準備いたします。

つきましては、正確な原因特定と迅速な復旧のため、以下の情報について教えていただけますでしょうか？（お手数をおかけしますが、可能な範囲で構いませんのでご回答をお願いいたします）

---
### 1. 対応期限・緊急度について
*   **いつまでに復旧が必要でしょうか？**（例：今日の〇時まで、あるいは次のデプロイ開始時まで、など）
*   **業務への影響範囲はどの程度でしょうか？**（例：特定のプロジェクトのみ、全社的に開発が止まっている、など）

### 2. 発生状況の詳細について
*   **エラーが発生した正確な日時を教えてください。**
*   **最後に正常に動作（ビルド成功）したのはいつ頃でしょうか？**
*   **エラーが発生する直前に、何か設定変更やコミット、特殊な操作などは行いましたか？**

### 3. 対象の特定について
*   **対象となっているJenkinsのジョブ名、または関連するビルドのURLを教えてください。**

### 4. 調査状況について
*   **「ログがない」とのことですが、具体的にどの画面（コンソール出力、システムログなど）を確認されましたでしょうか？**
*   **現時点で、ご自身で試されたことや確認したことはありますか？**（例：Jenkinsの再起動を試した、ノードの状態を確認した、など）

---

上記の情報が揃い次第、すぐに担当者へ詳細を共有し、対応を進めさせていただきます。
ご確認のほど、よろしくお願いいたします。

応答時間 3.25 秒

この比較では、Qwen2.5-14B は基本的な聞き返しはできるものの、今回重視した期限や温度感、関連 URL の確認がテンプレートな返答にとどまりました。また、Qwen3.5 系と Gemma 4 になると必要な確認項目をかなり網羅できるようになることが確認できます。

エラーログ調査の比較

エラーログ調査では、原因候補や次の切り分け方針にどこまで届けるかを見ています。単に末尾のエラー行を読めば答えが出るケースだけでは差が見えにくかったため、性質の異なる2つのシナリオを用意しています。

エラーログのシナリオ例

シナリオ	想定した状況	見たポイント
シナリオ1	Unity のビルド中に C# のコンパイルエラーが発生し、末尾に CS0246 等のエラーが出ているケース	明確なエラー行から、参照切れや package、asmdef 設定の確認に自然につなげられるか
シナリオ2	メモリ不足などのハードウェア起因でCI/CD全体でエラーが起きているケース	ログに点在する連鎖的なエラーから根本の原因を推論できるか

結果は、次の3段階で整理しました。

〇: 原因候補と次の切り分け方針まで、単体で実務に使いやすい水準で返せた
△: 単体では切り分け方針まで届かなかったが、原因候補の推測や確認観点等が補助的なものとしては使えた
✕: 要約や一部の指摘には使えても、調査方針を立てる材料としては不足が残った

モデル	シナリオ1	シナリオ2
Qwen2.5-14B	△	✕
Qwen3.5-9B	〇	✕
Qwen3.5-27B	〇	△
Gemma4-26B-A4B UD-IQ4_XS	〇	△

差が出やすかったのは、シナリオ2 でした。Unity のコンパイルエラーは比較的明確なエラー行が出るため小さいモデルでも一定の補助になりますが、ハードウェア起因のエラーのように、周辺情報を束ねて判断するケースでは差が広がりました。Qwen2.5 は要約補助としては使えても調査の叩き台にとどまり、Qwen3.5-27B と Gemma 4 も単体では次の切り分け方針までは返せませんでしたが、原因候補の推測や確認観点はある程度返せており、その内容を Gemini に渡すと問題の切り分けを進められる場面がありました。

今回行った検証の観点では、Qwen2.5 はログ調査でも Slack 向けの問い合わせ応答でも単発の補助に近く、Qwen3.5 でツール実装としてかなり現実味が増し、Gemma 4 では 16GB VRAM でも、問い合わせ対応とログ調査の両方を実務フローに組み込めるラインが見えた、というのが今回の整理です。

2026年春時点での見立て

ここまで見てきた変化は、あくまで2か月ほどの短い期間ですが、その間にもローカルLLMは実務への届き方がはっきり変わってきました。2026年春の時点で、ローカルLLMはもう「一部の趣味的な検証」にとどまる存在ではなくなったと感じています。特に、扱う情報の秘匿性が高い場面や、ログやドキュメントを大量に横断したい場面では、有力な選択肢です。

一方で、何でもローカルに寄せればよいわけでもありません。Agent を安定して動かすには、モデル本体だけでなく、ツール設計やプロンプト設計に加えて、ハーネス設計まで含めて考える必要があります。そこは今でも手触りのある調整領域ですが、評価シナリオの整備やハーネスの調整にも相応の手間がかかります。加えて、モデルの進化が速いため、時間をかけて詰めた前提や調整が数か月で古くなることも珍しくありません。それでも、今回の検証で16GB VRAM の手元環境から始められる実用ラインが見えてきたことは大きな変化でした。ローカルLLMを試すには高価なGPUが必須、という時期から一歩進み、用途次第では現実的な構成で検証を始められる段階に入ったと思います。

まとめ

今回の検証では、CI/CD基盤の問い合わせ対応と、CI/CDのエラーログの原因調査という別々の検証を通してローカルLLMを見ました。その結果、モデルの進化によって「どこまで任せられるか」の線が短い期間でかなり動くことを実感しています。

秘匿性の高い情報を扱いながらAI活用を進めたい現場にとって、ローカルLLMはかなり現実的な選択肢になってきました。また、今回本文で取り上げたモデルよりも小さいパラメータ数のモデルや Vision の検証も進めており、用途を絞れば利用できる範囲をさらに広げられることも確認できました。今後は評価シナリオをさらに整えつつ、用途ごとにどの構成まで現実的に運用できるのかをもう少し見極めていくつもりです。