BLOG

生成AIは、資料作成や情報整理だけでなく、問い合わせ対応や書類の確認などさまざまな業務で活用されるようになっています。

活用する業務が増える中で、注目されている選択肢の一つがローカルLLMです。ローカルLLMは、外部の生成AIサービスに処理を任せるのではなく、自社が管理する環境でAIモデルを動かす利用形態です。入力した情報を外部サービスへ送らずに利用できるため、機密情報や社内データを扱う業務で導入が検討されています。

一方で、ローカルLLMの価値は、情報を外部へ送らずに済むことだけではありません。クラウド上のAIをAPI経由で利用する場合、利用回数や入出力する文章量に応じて費用が発生します。また、自社独自のルールや判断方法を長い指示文として毎回与える場合、その文章も利用料金に影響します。処理件数が多い業務では、1回ごとの差が小さくても年間では大きな費用差になる可能性があります。

海外では、小規模なオープンモデルを特定の業務へ適応させることでその業務の評価において高性能な汎用モデルを上回り、低い処理費用も実現した事例が報告されています。これは、対象業務を絞って自社独自のルールや判断基準を学習させることで、比較的小さなモデルでも必要な性能を実現できる可能性を示しています。

本記事では、こうした検証事例を確認したうえで、小規模なモデルが高い性能を発揮できた理由をファインチューニングや強化学習の仕組みから解説します。あわせて、推論費用を抑えられた理由と、クラウドAPIとローカルLLMをどのように使い分けるべきかを整理します。

Fermisenseが公開した業務特化モデルの検証事例

今回参考にするのは、Fermisenseが公開した記事「The Rise of Intelligence Ownership」です。同記事では、特定の業務に合わせて学習させた小規模なAIモデルが高性能な汎用モデルと比べてどの程度の性能と費用を実現できるかを検証しています。

検証の対象となったのは、オンライン通販サイトに掲載される商品情報を確認する業務です。通販サイトには、商品の画像、商品名、説明文、ブランドなどの情報が登録されます。これらを確認し、適切な商品カテゴリを選ぶことや、必要な商品情報を取り出すこと、規約に違反していないかを判断することが主な作業です。

Fermisenseは、この商品審査業務を仮想的な環境として再現し、約90億個のパラメータを持つ9Bのオープンモデルに繰り返し審査を行わせました。モデルが出した判断を採点し、その結果をもとにモデルを改善する強化学習を行っています。

学習後の性能は、GPTやClaudeなど幅広い用途に対応する最先端の汎用モデルと比較されました。このような高い性能を持つ最先端のモデルは、「フロンティアモデル」と呼ばれます。

同社の検証では、学習前の9Bモデルは設定された評価上限に対して64.2％のスコアでした。GPTやClaudeなどを含む高性能な汎用モデルのうち、最も高かった構成は76.9％でしたが、学習後の9Bモデルは87.3％に到達しています。これは、モデルの規模が比較的小さくても、対象業務に合わせて学習させることで、その業務の評価では大規模な汎用モデルを上回る場合があることを示しています。

費用面でも大きな差が報告されています。学習後の9Bモデルによる処理費用は商品1,000件当たり約0.50ドルでした。一方、比較対象のうち最も高い性能を示した汎用モデルは、同じ1,000件当たり約34ドルでした。Fermisenseの検証条件では、特化モデルが約68分の1の費用で処理したことになります。

ただし、この結果は9Bモデルがあらゆる用途で高性能な汎用モデルを上回ったことを意味するものではありません。商品審査という限定された業務を再現し、判断基準や評価方法を用意したうえで追加学習した結果です。

なぜ9Bモデルがフロンティアモデルを上回ったのか

Fermisenseの検証では、商品審査業務に合わせて追加学習した9Bモデルが同社の評価環境においてフロンティアモデルを上回りました。

9Bとは、モデルが約90億個のパラメータを持つことを表します。パラメータは、モデルが文章や情報の関係を処理するために内部で調整する値です。一般的に、モデルの規模が大きくなるほど推論に必要な計算量やメモリも大きくなります。

比較的小規模な9Bモデルがなぜフロンティアモデルを上回る結果を出せたのでしょうか。

特定業務の性能はモデルの規模だけでは決まらない

フロンティアモデルは、文章作成、翻訳、プログラミング、情報整理など、幅広い用途に対応できるように作られています。特定の業務だけではなく、さまざまな質問や依頼に対応できる汎用性が大きな強みです。

一方で、利用する企業の商品分類や社内規則、判断の優先順位まで事前に理解しているわけではありません。企業独自のルールに沿った判断を行わせるには、必要な情報をプロンプトとして与える必要があります。

今回の検証で求められたのは、幅広い質問に答える能力ではなく、オンライン通販サイトの商品情報を確認し、決められた分類や規約に沿って判断する能力です。このように対象が明確な業務では、一般的な能力の幅広さよりも、その業務に必要な判断をどれだけ正確に行えるかが重要になります。

つまり、今回の9Bモデルは総合的な能力でフロンティアモデルを上回ったのではなく、商品審査という限定された業務に必要な能力へ特化することで高い評価を得たと考えられます。

汎用モデルはプロンプトから業務ルールを読み取る

フロンティアモデルに商品審査を行わせる場合、商品分類のルール、確認すべき項目、利用できる検索機能、規約違反の判断方法などをプロンプトで説明する必要があります。

Fermisenseの検証でも、業務ルールや具体例を含む約2,800文字のプロンプトが用意されました。フロンティアモデルは商品を処理するたびにこの指示を読み取り、業務に沿った判断を行います。

しかし、業務で発生するすべての例外や判断が難しい事例を一つのプロンプトに記載することは困難です。そこで今回の事例では、業務に必要な判断方法を追加学習によってモデルへ反映しています。

ファインチューニングでモデルを業務に適応させる

すでに学習済みのモデルへ追加の学習を行い、特定の用途に適応させることをファインチューニングと呼びます。例えば、商品審査に関するデータを使って追加学習を行うことで、商品情報と適切なカテゴリの関係、確認するべき属性、ブランド情報の扱い方、規約違反を判断する際の傾向などをモデルへ反映できます。業務に必要な判断方法をモデル側へ反映できれば、すべてのルールや具体例を毎回長いプロンプトとして与える必要を減らせる可能性があります。

今回のFermisenseの事例では、モデルを商品審査業務へ適応させる方法として、強化学習が使われています。

強化学習で判断の進め方を改善する

強化学習とは、モデルに実際のタスクを行わせ、その結果に応じて報酬やペナルティを与える学習方法です。モデルはより高い評価を得られるように判断方法を改善していきます。

商品審査では、入力された商品情報を見てすぐに回答を出せばよいとは限りません。必要に応じて商品カテゴリを検索し、ブランドの登録状況を確認し、そのカテゴリで必要となる情報を調べたうえで最終的な判定を行います。そのため、今回の検証では最終回答の正しさだけでなく、ツールの利用を含む一連の行動も評価され、不要なツール呼び出しにはペナルティが与えられました。

また、規約違反を見逃した場合には、正常な商品を誤って違反と判断した場合の7倍のペナルティが設定されています。これは、規約違反を見逃す方が事業に与える影響が大きいという優先順位を、評価方法へ反映したものです。このように、人間が報酬とペナルティを設計することで、正解を出すことだけでなく、業務上重視すべき判断や効率的な確認手順も学習させています。

Fermisenseが公開した学習曲線からも、強化学習によって9Bモデルの性能が向上していったことが確認できます。下図の横軸は学習ステップ数、縦軸は商品審査タスクで得られた評価を表しています。学習開始時にはフロンティアモデルの評価水準を下回っていましたが、学習を進めるにつれて評価が上昇し、250ステップより前にその水準を上回っています。

強化学習の進行に伴う9Bモデルの性能変化
引用元：Fermisense, “The Rise of Intelligence Ownership” July 27, 2026.

この学習曲線から、今回の9Bモデルが最初からフロンティアモデルを上回っていたのではなく、商品審査業務を繰り返し経験し、その結果に応じてモデルを更新することで性能を向上させたことが分かります。

デジタルツインを学習環境として利用する

強化学習を行うには、モデルがタスクを実行し、その結果を採点できる環境が必要です。今回の検証では、商品審査業務を再現したデジタルツインが用意されました。デジタルツインとは、現実の設備や業務をコンピュータ上に再現した仮想環境です。

Fermisenseが公開している下図では、今回構築された商品審査環境の全体像が示されています。商品情報がモデルへ入力され、モデルは商品カテゴリやブランドなどを確認するためのツールを利用しながら判断を進めます。その結果はあらかじめ用意された評価基準によって採点され、得られた評価がモデルの学習へ利用されます。

Fermisenseが構築した商品審査業務のデジタルツイン
引用元：Fermisense, “The Rise of Intelligence Ownership” July 27, 2026.

今回の事例では、商品情報、商品カテゴリの検索機能、ブランド情報、規約、正解データ、採点方法などを含む商品審査業務が仮想環境として再現されています。

図に示されているように、モデルは単に商品情報から回答を出すだけではありません。必要に応じてツールを利用しながら情報を確認して最終的な判断を行い、その結果が評価されます。この評価をモデルへ返して学習を繰り返すことで、モデルを商品審査業務へ適応させています。

今回の仕組みは、商品審査業務を再現したデジタルツインの中で強化学習を行い、9Bモデルを業務へ適応させたものと整理できます。

なぜ推論費用を抑えられたのか

Fermisenseの検証では、商品審査に特化した9Bモデルがフロンティアモデルを上回る評価を得ただけでなく、処理費用も大幅に抑えられました。

同社の報告では、学習後の9Bモデルによる処理費用は、商品1,000件当たり約0.50ドルでした。一方、比較対象の中で最も高い性能を示したフロンティアモデルは、同じ1,000件当たり約34ドルでした。Fermisenseの検証条件では、特化モデルが約68分の1の費用で処理したことになります。

この費用差には、小規模なモデルで必要な性能を実現できたことに加えて、APIとは異なる料金体系で大量の処理を行えたことや、プロンプトとツール利用を効率化できたことが関係しています。

小規模モデルで計算資源を抑える

フロンティアモデルは、文章作成、翻訳、プログラミング、情報整理など、幅広い用途に対応するために大規模なモデルとして開発されています。一般的に、モデルのパラメータ数が多いほど推論時に必要となるGPUメモリや演算量も大きくなります。そのため、大規模なモデルを動かすには高性能なGPUや大容量のメモリを備えた計算環境が必要です。

今回の事例では、対象を商品審査という限定された業務に絞り、追加学習によって必要な判断方法を9Bモデルへ反映しています。その結果、フロンティアモデルほど大規模なモデルを使わなくても業務に必要な性能を実現できました。

比較的小規模なモデルであれば1回の推論に必要なGPUメモリや演算量を抑えやすく、同じ計算環境でもより多くの処理を行える可能性があります。

大量処理で自社運用の費用を分散する

GPTやClaudeなどのクラウドサービスをAPI経由で利用する場合、一般的には利用するモデル、入力する文章量、出力される文章量などに応じて料金が発生します。

APIはサーバーやGPUを自社で準備せずに利用を始められる点が大きな利点です。利用量が少ない段階では必要な分だけ料金を支払えるため、自社で設備を用意するより合理的な場合もあります。一方で、同じ形式の業務を毎日大量に処理する場合には、利用回数や入出力する文章量に応じて料金が積み上がります。商品を数件処理する場合と、数十万件や数百万件処理する場合とでは、APIの利用料金に大きな差が生じます。

自社でモデルを運用する場合は、GPUやサーバーの導入費、電力費、保守費などが主な費用になります。APIのように処理するたびに外部サービスの利用料金が発生する形から、用意した計算環境を使って処理する形へ、費用の構造が変わります。この構造では、処理件数が多いほど、設備や追加学習にかかった費用を多くの処理へ分散できます。例えば、同じ設備を使う場合、1万件しか処理しない場合より、100万件を処理する場合の方が、1件当たりに割り当てられる設備費は小さくなります。また、大量の処理が継続的に発生する業務であれば、GPUが何も処理していない時間を減らし、導入した計算資源を有効に使えます。これも、1件当たりの費用を抑えるうえで重要です。

Fermisenseは、今回のモデル学習にかかったGPU利用費を約500ドルと報告しています。この学習費を一度支払った後、同じモデルを多数の商品審査に利用できれば、処理件数が増えるほど1件当たりに含まれる学習費は小さくなります。

プロンプトとツール利用を効率化する

商品審査にかかる費用は、モデル本体を動かすための計算資源だけで決まるわけではありません。モデルへ入力するプロンプトの長さや、検索機能などのツールを何回利用するかも、処理全体の費用に影響します。

フロンティアモデルに企業独自の業務を行わせる場合、商品分類のルール、確認すべき項目、規約違反の判断方法、出力形式などを、プロンプトとして詳しく説明する必要があります。Fermisenseの検証では、フロンティアモデルに対して業務ルールや具体例を含む約2,800文字のプロンプトが用意されました。APIを利用する場合、この指示は商品を処理するたびに入力され、その文章量も料金に影響します。

これに対して、業務特化モデルでは追加学習によって判断方法の一部をモデルへ反映できます。そのため、すべてのルールや具体例を毎回プロンプトへ記載する必要を減らし、入力する文章量を抑えられる可能性があります。

また、今回のモデルは商品情報を確認するだけでなく、商品カテゴリの検索やブランド情報の確認など、複数のツールを利用していました。ツールの利用回数が増えると、モデルが処理する情報量や待ち時間が増えます。外部の検索サービスや有料の機能を利用する場合には、ツールの呼び出し自体に料金が発生することもあります。

Fermisenseの強化学習では、不要なツール利用にもペナルティが設定されました。これにより、モデルは必要な情報を確認しながら、無駄な検索や同じ情報の繰り返し確認を減らすように学習しています。つまり、今回の費用削減には、小規模なモデルを使ったことだけでなく、1件の商品を処理する際に入力する文章量と、判断を終えるまでの作業量を抑えたことも関係しています。

今回の事例から、ローカルLLMの費用面での利点が生まれやすいのは、小規模なモデルで必要な性能を実現でき、同じ形式の処理が大量かつ継続的に発生する業務だと考えられます。

APIとローカルLLMをどう使い分けるか

ここまで、特定の業務に合わせて小規模なモデルを学習させることで、性能と推論費用の両方を改善できる可能性を見てきました。

ただし、生成AIを導入する際に最初からすべての処理をローカルLLMで行う必要はありません。クラウドAPIとローカルLLMにはそれぞれ異なる利点があるため、業務の段階や内容に応じて使い分けることが重要です。

APIは設備や学習環境を準備しなくても高性能なモデルをすぐに利用できます。一方、ローカルLLMは対象業務がある程度固まり、大量の処理が継続的に発生する場面で性能や費用を調整しやすいという特徴があります。

そのため、まずAPIを使って業務への適用可能性を確認し、その過程で得られたデータをもとに、ローカルLLMへ移す部分を選ぶ方法が現実的です。

まずはAPIで業務を試す

新しい業務に生成AIを導入する段階では、どの程度の精度を実現できるのか、どのような指示が必要なのか、どのような場面で失敗するのかが分からない場合があります。

この段階では、GPTやClaudeなどのフロンティアモデルをAPI経由で利用する方法が適しています。自社でGPUやサーバーを用意しなくても利用を始められ、モデルの追加学習を行わなくても一定の性能を期待できるためです。

まずAPIを使って対象業務を試すことで、生成AIに任せられる範囲や人間による確認が必要な部分を把握できます。また、複数のモデルを同じ条件で比較し、業務に必要な性能の基準を決めることもできます。

この段階のAPIは単に業務を処理するための手段ではなく、将来の特化モデルと比較するための基準を作る役割も持ちます。

APIの利用を通じて学習データを蓄積する

APIを使って業務を試す過程では、モデルへ入力した情報と出力結果を保存できます。例えば、モデルに与えた入力、使用したプロンプト、モデルが出した回答、人間が行った修正、最終的に正しいと判断された結果、モデルが失敗した事例などです。これらの情報を蓄積することで、どのような入力で誤りが起きやすいか、どのルールをプロンプトだけでは正しく扱えないかを分析できます。

特に重要なのは、AIの出力だけでなく、その結果が正しかったかどうかも記録することです。モデルの出力を保存するだけでは、どの判断を学習させるべきかを決められません。APIの利用段階から評価結果や人間の修正を記録しておくことで、日々の業務を行いながら特化モデルを開発するためのデータを蓄積できます。

ローカルLLMへ移す業務を選ぶ

十分なデータが集まった後は、業務全体をそのままローカルLLMへ移すのではなく、特化モデルに適した部分を選びます。

ローカルLLMへ移しやすいのは、同じ形式の処理が繰り返され、入力と出力の形がある程度決まっている業務です。また、正しい結果や評価基準を定めやすく、社内独自のルールに沿った判断が求められる業務も適しています。

今回の商品審査のように、商品情報を決められた分類へ当てはめたり、規約違反の有無を確認したりする業務は、その一例です。ほかにも、問い合わせ内容の分類、書類からの情報抽出、申請内容の確認などが考えられます。一方、幅広い知識が必要な質問への回答や、正解を一つに決めにくい文章作成などでは、フロンティアモデルの汎用性が有利になる場合があります。

ローカルLLMを導入する際には、業務全体を置き換えることを目指すのではなく、特化モデルが安定して処理できる部分を切り出すことが重要です。

APIと同じ条件で特化モデルを評価する

ローカルLLMへの移行を判断するには、APIと特化モデルを同じ条件で比較する必要があります。

確認する項目としては、判断の正確さ、見逃しや誤判定の割合、1件当たりの処理費用、処理にかかる時間などがあります。大量に処理する業務では、同時に処理できる件数や、一定時間内に完了できる件数も重要です。

性能だけを比較すると特化モデルの方がわずかに高い結果を示していても、データの準備や運用に大きな費用がかかり、移行の効果が小さくなる場合があります。反対に、性能がAPIと同程度でも、大量処理によって1件当たりの費用を大きく下げられるのであればローカルLLMへ移す価値があります。

そのため、推論費用だけでなく、モデルの追加学習、サーバー、電力、保守、更新にかかる費用も含めて比較する必要があります。

まとめ

今回紹介したFermisenseの事例では、商品審査という特定の業務に合わせて追加学習した9Bモデルが、同社の評価環境においてフロンティアモデルを上回る結果を示しました。

この結果から分かるのは、業務に必要な性能がモデルの規模だけで決まるわけではないということです。対象となる業務を明確にし、判断基準や評価方法を用意したうえで追加学習を行うことで、比較的小規模なモデルでも高い性能を実現できる可能性があります。

また、小規模なモデルで必要な性能を満たせれば、推論に必要な計算資源を抑えられます。Fermisenseの検証では、学習後の9Bモデルの処理費用は商品1,000件当たり約0.50ドルで、比較対象の中で最も高い性能を示したフロンティアモデルの約34ドルに対して、大幅に低い結果となりました。

ローカルLLMは、機密情報を外部へ送信しないための選択肢として注目されることが多いですが、業務内容によっては、性能や運用費用の面でも導入を検討する価値があります。

一方で、すべての業務をローカルLLMへ移せばよいわけではありません。同じ形式の処理が大量に発生し、結果を評価しやすく、小規模なモデルでも必要な性能を実現できる業務ほど業務特化モデルの利点を生かしやすくなります。反対に、幅広い知識や柔軟な対応が必要な業務では、フロンティアモデルをAPI経由で利用する方が適している場合もあります。

そのため、まずAPIを使って業務への適用可能性を確認し、その過程で入力や出力、人間による修正、失敗事例などを蓄積することが重要です。そのうえで、性能と費用を比較しながら適した業務を段階的にローカルLLMへ移していくことが、現実的な導入方法といえるでしょう。

ローカルLLMとクラウドAPIは、どちらか一方を選ぶものではありません。それぞれの特徴を理解し、業務の内容や処理量に応じて使い分けることが生成AIを継続的に活用していくうえで重要になります。

参考文献

Fermisense, “The Rise of Intelligence Ownership” July 27, 2026.
https://fermisense.com/when-machines-take-the-wheel/