ローカルLLMを使ったエージェント開発の現在地 〜社内PR自動レビューに「ローカルLLM」は使えるか？コスト×精度で検証してみた〜

「AIエージェント時代のローカルLLM活用」登壇資料
https://engineercafe.connpass.com/event/396774/

1. ©Fusic Co., Ltd. 0 ローカルLLMを使ったエージェント開発 の現在地 2026.06.23 AIエージェント時代のローカルLLM活用 浦田 大貴 / Fusic 社内PR自動レビューに「ローカルLLM」は使えるか？ コスト×精度で検証してみた
2. ©Fusic Co., Ltd. 1 自己紹介 はじめに 浦 田 大 貴 D A I K I U R ATA 株式会社Fusic エンジニア 社内AI活用推進を担当。 業務ではAI活用の勉強会開催、基盤整備や実プロジェクトでの相談役とし て活動中。 個人開発が趣味。最近はローカルで動くリアルタイム文字起こし/翻訳ア プリ（macのライブキャプションやWhisper Transcriptionのようなも の）を開発中（挫折中） X: @daiki7nohe GitHub: @7nohe
3. ©Fusic Co., Ltd. 2 CONTENTS 1. なぜローカルLLMを試したか 2. 何をどう検証したか 3. 結果 4. 結論と、これからの話
4. ©Fusic Co., Ltd. 3 なぜローカルLLMを試したか 01
5. ©Fusic Co., Ltd. 4 きっかけはコスト削減 ▪ 社内でもAI利用料が無視できない額 になってきた ▪ Devin Reviewの場合は約$2/review https://cognition.com/blog/new-self-serve-plans-for-devin
6. ©Fusic Co., Ltd. 5 全部ローカルは無理。でもPRレビューなら任せられそう、という仮説から始めた PRレビューは非同期。即答が要らないの で多少遅くても運用に乗せられる 遅くてもOK 1次レビュー用途なら、人間が最終確認 する前提で精度を多少妥協できる 精度は妥協できる 従量課金が乗らないので、push毎に何度 でも気兼ねなく回せる 気兼ねなく使える コーディングタスクはGPT5.5/Opusなどのフロンティアモデルに は勝てない。 レビューならローカルでもいけるのでは？
7. ©Fusic Co., Ltd. 6 何をどう検証したのか？ 02
8. ©Fusic Co., Ltd. 7 社内にあったGPUサーバーで検証 RTX3090(24GB)に載る 24GB 1枚でQ4量子化が載る20〜32Bク ラスに限定。これを超える大型モデルは 対象外 商用OKなライセンス Apache 2.0等の商用利用可ライセンスの み採用。非商用ライセンスのモデルは除 外した コード系ベンチがHaiku級 コード系ベンチでクラウド小型(Haiku級) に近い数字を出すこと。 以下モデルを選定 ▪ Qwen3-Coder 30B (MoE・本命) ▪ Qwen2.5-Coder 32B (dense・比較用) ▪ Gemma4 31B (最近出てよさそう)
9. ©Fusic Co., Ltd. 8 Fusicの実PRで測定 評価データ18件 実PR9件 注入バグ3件 クリーンPR6件 01 PR-Agentで ローカル(Gemma4/Qwen-Coder)と クラウド(Haiku/Sonnet)のレビューを生成 5モデルで共通生成 02 2モデルで採点 Opus＋GPT-5.5のクロス採点で recall(見逃しの少なさ)と precision(誤検知の少なさ)を採点 03
10. ©Fusic Co., Ltd. 9 結果 03
11. ©Fusic Co., Ltd. 10 評価結果 モデル recall全体 単純バグ precision Sonnet（クラウド） 0.70 0.85 0.62 Haiku（クラウド） 0.71 0.83 0.48 Gemma4（ローカル） 0.67 0.83 0.57 Qwen3-Coder（ローカル） 0.54 0.67 0.30 Qwen2.5（ローカル） 0.48 0.46 0.46 Recall（見逃しの少なさ）: バグをAIレビューが拾えたか。高いほど見逃しが少ない。 Precision（誤検知の少なさ）: AI の指摘がdiff に本当に存在するか（＝幻覚をしてい ないか）。高いほどノイズが少ない Diffで分かるバグはGemma4はHaiku並み。 仕様依存と誤検知抑制はSonnetの勝ち。
12. ©Fusic Co., Ltd. 11 ローカルは大型PRで崩壊・タイムアウトも Haiku / Sonnet（クラウド） 約9秒 / 約20秒。大型PRも安定して完走 Gemma4（ローカル） 5分くらいかかる。大型PRで生成が崩壊することあり Qwen-Coder系（ローカル） さらに遅く、生成失敗が多発 前提 古い社内GPUでの参考値。業務利用には実用的なGPUが必要 コンテキスト16k固定、Ollama、小サンプル、マシンスペックな ど環境の制約があり、ローカルに不利な傾向あり
13. ©Fusic Co., Ltd. 12 Haikuの方がまだコスパがよさそう 0 20000 40000 60000 80000 100000 120000 140000 100件 500件 1,000件 3,000件 5,000件 月間コスト比較（円/月） Haiku 直API AWS 業務時間固定 AWS オンデマンド起動 Haiku直APIは固定費ほぼゼロ。約3,700件/月まではHaikuが最安で、それ以上はAWS業務時間固定が下回る。オンデマンド起動はHaikuが常に安く交差点なし AWS想定（東京・Spot概算）: 業務時間固定＝g6.xlarge（L4 24GB）約220h/月で約1.1万円、オンデマンド起動＝g6e.xlarge（L40S 48GB）従量。Haiku直API≒3円/件 月数百〜数千件の現実的な規模では、自前GPUは損益分岐に届かない
14. ©Fusic Co., Ltd. 13 結論と、これからの話 04
15. ©Fusic Co., Ltd. 14 自前GPU・Bedrock・専用AWSのレビュー基盤は、現時点ではまだ要らない ◼ 速度・大型PR・運用の安 定性でクラウドが明らかに 有利 クラウドが楽な理由 ◼ クラウド直APIが現状もっ ともコスパが良い ただし限定条件つき ◼ これはFusicのPRレビュー に限った話 ◼ 機密データ処理など別用途 でローカルが要る場面は否 定しない
16. ©Fusic Co., Ltd. 15 じゃあどうする？ Qwen・Gemma・Kimiがこの1〜2年で躍 進。性能の伸びに期待 モデル進化が速い DGX Spark等の登場でローカル実行が現 実味 ハードも進化 社内ガイドライン＋評価データセットを 整備 来たる日に向けて https://x.com/satyanadella/article/2066182223213293753 「重要なのは最良のモデルを選ぶことではなく、モ デルの上に学習ループを築くこと」 評価も "not just external benchmarks" （外部ベンチだけでなく自社にとって意味のある成 果で測る private eval）が必要 「汎用モデルを差し替えても自社に蓄積した知見を 失わないこと」がこれからの主権の試金石だ
17. ©Fusic Co., Ltd. 16 まとめ 単純バグのレビューならローカルも健闘。「ローカル＝使えない」ではない コスパ的には現状クラウドが優位 自社データで評価する基盤づくりが採用判断の鍵なのでは！？ ローカルも健闘 現状はクラウド優位 今は基盤準備
18. ©Fusic Co., Ltd. 17 Thank You We are Hiring! https://recruit.fusic.co.jp/ ご清聴ありがとうございました
19. ©Fusic Co., Ltd. 18 パネルディスカッション 今ローカルLLMを開発業務でつかうとしたらどこですか？ 論点1 ローカルLLMのセキュリティ、ガバナンスどうすれば良いですか？ 論点2 今社内でやっておくべきことってなんですか？（評価基盤など） 論点3 論点4 あと何が揃えばローカルLLMが実用的になりますか？