PR

ローカルLLMは実務に使えるの？　肥大化するAIコストの対抗策になるか　デルが4つの領域で徹底検証

クラウド型の生成AIサービスを利用する企業が増えている。それに伴い、トークン消費量の増加によるコスト管理といった新たな課題も生まれている。そんな状況の解決に一役買うのが「ローカルLLM」だ。デル・テクノロジーズは6月、個人業務支援からワークフロー自動化、マルチエージェント、ファインチューニングまでの4つの領域で、ローカルLLMがどこまで使えるのかをデモを通して伝えるウェビナーを開催した。

　企業の生成AI活用への取り組みが拡大する一方、クラウド型生成AIサービスならではの課題も浮き彫りになってきた。AIエージェントとして使い込むほど、トークンの消費が増えて費用予測が難しくなる。またモデルの提供終了や仕様変更の影響も利用者側で制御できない。機密情報の取り扱いやオフライン稼働・自社データによるドメイン特化といったニーズも重なり、自社の環境でAIモデルを動かす「ローカルLLM」への関心が高まっている。

　多くのIT部門の担当者が注視するのは「結局、どのくらい実務で使えるのか」だろう。この疑問にデモで答えたのが、デル・テクノロジーズが6月26日に開いたウェビナー「デモでわかる！ローカルLLMはどこまで使えるのか」だ。

　講師を務めたデル・テクノロジーズの若松信康氏は、ローカルLLMの得意なことだけではなく、苦手なことやモデルサイズによる差、クラウドのフロンティアモデルとの差まで検証した結果を示した。

ローカルLLMは業務に使える？　4つの領域で検証

　今回は「個人業務支援・RAG活用」（日常業務の前処理を1つのモデルに任せられるか）と「定型ワークフロー」（決まった段取りを自走させられるか）、「専門業務（マルチエージェント）」（契約書レビューや開発を複数エージェントの分業で成立させられるか）、「ファインチューニング」（自社データで学習させ、業務適応を底上げできるか）の4つの領域で検証した。共通する狙いは「ローカル環境でどこまで成立するか」の見極めだ。

　検証機には「Dell Pro Max with GB10」（以下、GB10）を使った。NVIDIAのBlackwellアーキテクチャと128GBのユニファイドメモリを搭載している。ハイスペックなPCで動かせるのは100億パラメーター前後のAIモデルまでだが、GB10では約2000億パラメーター級まで動かせる。

検証1：営業提案を支援する10のタスクを実践

　まず検証したのは「個人業務支援・RAG活用」だ。1つの営業案件を共通シナリオとして、議事録や前回提案書、価格表、類似事例、企業情報の「社内ナレッジ」を参照して実務さながらに計10のタスクを実施した。それらのタスクは3つの目的に基づいて設計されている。

1. 「要約・変換・分類」（要約、英日・日英翻訳、JSON形式での構造化抽出、ToDo分類）は資料を"読んで形にする"素の言語力を測る。
2. 「抽出・集約・整理（RAG）」は、単一ファイル指定、複数資料を1問ずつ、複数資料に複合質問を一括で……と負荷を段階的に上げて根拠資料を引いて答え、条件指示を守れるかを測る。
3. 「文書作成」（お礼メール案、提案骨子）は人が出す成果物の下書き品質を見る。

　例えば、JSON抽出は「出力を後工程のシステムにそのまま渡せる出力規律」、複数ソースRAGは「資料の判別と、社名を伏せるといった条件指示の順守」、複合質問は「条件が重なっても破綻しない耐性」、提案骨子は「最も誤れない金額の正確さ」を測る設計だ。採点は正確性や網羅性、根拠提示、日本語、混同回避、指示追従の6軸を各5点、30点満点で行った。

　比較したのは、ローカルで動かす「Gemma 4 E4B」（有効約45億パラメーター）と、「Qwen3.5-9B」（約90億パラメーター）、「gpt-oss-120b」（約1170億パラメーター。ただし推論時に動くのは約51億トークン）、クラウドの「Claude Opus 4.8」の4モデル。ローカルの3モデルはGB10上の同じ環境でテストした。

　結果、要約と翻訳は4モデルが28〜30点に密集し、日英翻訳は最小のGemmaが満点でOpusと並んだ。RAGも単一ソースの参照や1問ずつの質問であれば、小型モデルがOpusとほぼ同等の品質を示し、事実の捏造（ねつぞう）は全モデルでゼロだった。文書作成も小型モデルは27〜30点と、人の目を通して出す前提のタスクにおいて十分なドラフト品質だった。若松氏は「日常の整理や翻訳にクラウドは不要だ」と説明している。

　一方、出力の正確さや指示への忠実さでは差が出た。JSON抽出ではgpt-oss-120bが指定していない備考や出典を自発的に追加し、そのままでは後工程に渡せなかったが、QwenやOpusはクリーンにJSONを出力した。複数のデータソースを参照・比較させる3つの質問と条件を1回のプロンプトに詰め込むと、個別質問では正答できた回答が崩れて「社名を伏せて」という条件も、GemmaとQwenは守れなかった。

　これはコンテキストが増えると指示順守が崩れる典型例で、「問いを1つずつに分ければ小型でもOpus並み」という回避策も同時に示した。

　これらの結果を、若松氏は3層に整理した。要約・翻訳・単一RAG・定型メールは「そのまま使える」領域として、全モデルが必要十分であり機密情報を手元で処理可能、コストとセキュリティの両面でクラウドより有利になる。

　JSON抽出・ToDo分類・提案ドラフトは「人の確認付きで使える」領域として、下書き役としては十分であり、整形・検算を挟めば実務で利用できる。守秘・複合質問・正確な見積もりは「設計で守る」領域として、モデル任せにはせず、仕組み側で担保する必要があるとまとめた。

検証2：定型業務のワークフロー化は小型モデルほど影響あり

　2つ目の検証は定型ワークフローの自動化だ。AIにチャットで個別に質問する使い方は、プロンプトの精度によって品質がばらついて属人化しやすい。手順を固定して人の入力を最小化すれば、誰が実行しても同じ結果を得やすくなる。

　デモではAIアプリ開発プラットフォーム「Dify」上で、営業業務に使える資料作成のワークフローを組んだ。会社名を入力すると企業情報の検索や議事録からの要望整理、過去提案の参照を経て提案資料の骨子を生成する。

　ローカルでLLMを動かすソフトウェア「Ollama」上のモデル名とローカルホストのポート番号を指定するだけで接続でき、デモでは1分40秒ほどでワークフロー化された7つのタスクを順番に実行して骨子を書き出した。CSVで会社名の一覧を渡して一括実行も可能だ。

　興味深いのは、同じ提案骨子タスクを「単体チャット」と「ワークフロー」の両方式で実行し、比較したスコアだ。Opusは30点→30点と変わらず、gpt-oss-120bは27点→28点と微増。一方、Gemmaは28点→25点、Qwenは30点→23点と、パラメーター数の小さいモデルほど下げ幅が大きかった。

　原因は、検索→整形→再構成を繰り返すことによるコンテキストの抜け落ちだ。若松氏は対処法として「全文検索とベクトル検索のハイブリッドで検索精度を高める（ノイズを削る）」や「整形ノードで要点を削らせず漏れなく列挙させる（欠落を防ぐ）」「今回の要望と過去提案を混同しないようプロンプトで明示的に区別する（変質を防ぐ）」「コンテキストウィンドウ（num_ctx）を調整してメモリと速度を管理する（処理の破綻を防ぐ）」などの工夫を挙げた。

検証3：コーディングやアプリ開発、契約書レビューなどの専門業務は？

　3つ目は、マルチエージェントの検証だ。コーディングでは、Qwen 3.6-35BとOpus 4.8に対して「コードを正しく読み説明できるか」「仕様通りの小さな機能を書けるか」「バグを自力診断して直せるか」「既存機能を壊さず別技術へ移行できるか」など7カテゴリー×2問の計14タスクを与え、「出力が使えないレベル」（L0）から「無監督で実用品質に達するレベル」（L4）までの自律度レベルで判定した。

　結果、Opusは全14タスクでL4・最高品質を達成し、Qwenも13タスクで「最後にレビューすれば実用」のL3以上に達して12タスクはそのまま使える品質だった。既存テストを壊した回数と事実の捏造は両モデルともゼロであり、「単体テストの生成」（指定3ケース中2ケースのみ実装）と「Typerへの移行」（挙動を退行させたまま「同一挙動」と過剰申告）の2項目で差が生じた。

　「日常開発の大半は、人のレビューを前提とすればローカルで実用レベルだ。フロンティアモデルの優位は、設計の洗練や規律といった『成熟度』に集約され、ローカルの弱点であるブレや過剰申告はレビューで人が検出できる」

　「まとまったアプリを一本作り切れるか」というタスクも検証した。同一の構築指示書と同一のツール（Claude Code）で、モデルだけをQwenとOpusで切り替え、付箋ボードアプリを作らせた。

　外部APIを一切呼ばない自己完結の単一HTMLアプリは、両者とも仕様をほぼ満たした。注目すべきは、アプリのウィンドウ幅を縮めた際の挙動でローカルが上回った点だ。Opus版は縮小時に付箋の座標を破壊的に上書きし、幅を戻しても重なったままになる不具合を抱えた。対してQwen版は配置を保ったまま縮小し、戻せば原寸に復帰する可逆設計となり、クラウドも万能ではないことを示す結果となった。

　差が大きく開いたのは、アプリ自体がLLMを呼ぶ二重構造のアプリだ。付箋をLLMが自動でカテゴリー化する「AI付箋ボード」を作成した際、構築時の総合力は42点満点でOpusが39点（達成率93％）、Qwenが14点（同33％）となった。

　このタスクでは、中継サーバの構築や不安定な応答の吸収、JSONの解析などローカルLLMの弱点を突く要素が重なった。結果、Qwenでは応答の取り違えや出力切れなどが起きて、人力で一手ずつ解決する必要があった。なお修正の進め方が両者で異なるため、点差は能力差そのものではないという。

　ただし完成後には逆転もあった。崩れたJSONと格闘しながら作られたQwen版アプリは幅を持たせた解析処理を備え、整理エンジンをローカルLLMに切り替えても動作した。一方、きれいな出力を前提に設計されたOpus版アプリは、ローカルLLM接続時にJSON解析で失敗した。実行時のAIによる整理はローカルでも3～4秒程度で完了し、実用域にあることも確認された。

　「LLMを呼ばない自己完結アプリなら、ローカルはOpusとほぼ同等の完成度を出せる。LLMを内部で呼ぶ複雑なアプリの構築は、自己診断と自走力に勝るクラウドに分がある」

　契約書レビューエージェントの性能も比較した。条項抽出や自社基準（プレイブック）との照合、事業リスク分析、修正文案作成まで6つのエージェントを編成し、あらかじめClaude Codeで作ったLangGraphベースのマルチエージェントアプリ上で実行、ダッシュボードで結果を確認した。

　同一の契約書を「gpt-oss-120b単体」「gpt-oss-120b＋RAG（社内データ参照）」「Opus 4.8」の3方式でレビューさせたところ、事業リスクの検出数は単体20件、RAG併用25件、Opus23件と、RAG併用のローカルが最多になった。セキュリティ・個人情報の指摘も12件で最多かつ最も具体的で、情報セキュリティの国際規格「ISO 27001」への準拠や著作者人格権といった専門論点まで踏み込んだ。

　一方、ローカルはリスクを全て「違反」と一律に列挙したのに対し、Opusは「違反」と「要確認」を使い分けて濃淡を付け、最終要約も6項目に絞り込んだ。若松氏は「法務の判断はOpusでも担えないが、自社基準に照らした下調べはローカルでもこなせる。RAGで社内知識を取り込むことが具体性と深さを底上げする」とまとめた。

検証4：ファインチューニング ──「振る舞い」をPCで変える

　最初の検証で、小型モデルでJSON形式の出力が崩れたのを思い出してほしい。その弱点を補強し、特化型にすることで小さなモデルでも正しく機能させることができるのがファインチューニングだ。RAGがモデルの外側に知識を置いて「何を知っているか」を増やすのに対し、ファインチューニングはモデルを再学習させて「どう振る舞うか」を変える。

　業界用語や文体、出力フォーマットなどの型・規約の固定はファインチューニングが得意で、固有名詞や仕様値などの事実はRAGで参照する。実務ではどちらかではなく、併用が基本という。

　全パラメーターを更新するフル・ファインチューニングは大量のGPUリソースを要するが、元の重みを凍結して差分だけを学習する「LoRA／QLoRA」なら必要リソースを大幅に削減可能で手元の1台のPC（GPU必須）で現実的に実行できる。デモではノーコードツール「Unsloth Studio」で、「Llama 3.2-3B」に問い合わせをJSON形式で分類・要約させる学習を実施したところ、約80行のデータの学習に要した時間は1分47秒だった。

　カテゴリーや重要度、要約が崩れずに出力され、対応優先度などの選別が自動化できる他、ファインチューニング前のモデルと組み合わせたマルチエージェントで、回答案も加えてトリアージする動作を1台のPC上で披露。AIによる業務支援領域を底上げできる可能性を示した。

役割分担すればローカルLLMは戦力になる

　4つの検証の結果、情報収集・整理・検討といった日常業務の前工程は、ローカルLLMで十分に実用ラインに乗ると判断できる。コーディングの基本タスクも人のレビューを前提にローカルで回せる。自己完結型のWebアプリ開発はローカルで十分だ。

　一方、推論を重ねるワークフローは小型モデルほどコンテキストの影響を受けやすく、複雑なアプリの構築や判断の質は、クラウドのフロンティアモデルに頼りたい領域となる。ただし、自社固有のプロセスなどに特化したモデルとしてファインチューニングすることで、モデル単体では揺れがあった振る舞いも実用レベルに向上できた。

　定型・軽量な処理と自社特化タスクはローカル、複雑な構築と高度な判断はクラウド……と役割を分ければ、ローカルLLMは戦力になる。

　受講後、ウェビナーの参加者からは「自社製品の広告で終わりがちなところ、リアルな動作を見せていただき、神回でした」「ファインチューニングがPCでできると知ったので試してみたい」などの前向きな意見が上がった。

　パラメーター数の小さい最新モデルが、パラメーター数の大きい過去モデルの性能を上回るケースが増えている今、自社に合う選択肢を見つけられる検証環境が重要になる。Dell Pro Max with GB10なら、クラウドのトークン従量課金と違って、予測可能な固定費でオープンウエイトモデルを使って十分な検証とモデルの改善が可能で、PoC止まりの解消にもつながる。生成AI活用に取り組む企業の強い味方になるだろう。