業務に使うLLMの選び方：精度・費用・データ取り扱いの比較軸

業務に使うLLM（大規模言語モデル）を選ぶときは、公開されているベンチマークの順位や話題性ではなく、自社の業務が求める「精度」「応答速度」「費用」「データの取り扱い」の四つの条件から選ぶのが確実です。一般的な試験で高い点を取るモデルが、自社の業務文書の要約や、社内規程に基づく回答で最もよい結果を出すとは限りません。また、最も高性能なモデルが、費用や応答速度の面で業務に合うとも限りません。

結論から言うと、選び方の手順は次のとおりです。まず業務ごとに必要な条件を書き出し、データの取り扱いの条件で候補を絞ります。次に、自社の実際の業務データに近い評価用の入力で、候補のモデルを比較します。そのうえで、精度が十分な中から費用と応答速度が合うものを選び、後からモデルを切り替えられる設計にしておきます。モデルは毎年のように新しいものが出るため、「一度選んで終わり」ではなく「定期的に選び直せる」状態を作ることが大切です。

この記事は、生成AIを組み込んだ社内ツールやサービスの導入・開発を担当する方に向けています。要件の整理方法、比較軸ごとの判断基準、自社データでの比較検証の手順、切り替えやすい設計の考え方を解説します。特定のモデルを推薦するのではなく、自社で判断するための枠組みをまとめています。

LLMを性能ランキングで選んではいけない理由

各社のモデルは、一般的な知識や推論、プログラミングなどの試験での成績を公表しています。こうした情報は大まかな能力の目安にはなりますが、業務でのモデル選びにそのまま使うと、次のようなずれが生じます。

• 業務の内容が試験と違う：社内の専門用語を含む文書の要約、決まった形式での情報抽出、丁寧な日本語での顧客対応など、業務で求められる能力は試験の問題とは異なります。
• 必要な水準が業務ごとに違う：問い合わせの分類のように単純な処理なら、軽量なモデルで十分な精度が出ることがあります。高性能なモデルを使っても、結果がほとんど変わらないなら費用の無駄になります。
• 精度以外の条件が効いてくる：応答に時間がかかりすぎて利用者が待てない、利用量に対して費用が合わない、データを外部に出せない、といった条件で、候補から外れるモデルもあります。

つまり、モデル選びは「最も賢いモデルを探す」ことではなく、「業務の条件を満たすモデルの中から、最もバランスのよいものを選ぶ」ことです。

まず業務ごとの要件を書き出す

モデルを比較する前に、AIに任せる業務ごとに、次の項目を書き出します。

この表を作るだけで、必要なモデルの条件がかなり絞られます。たとえば、夜間の一括処理で速度を問わず、出力が決まった形式なら、軽量で安価なモデルから試す価値があります。一方、顧客と対話しながら複雑な相談に答えるなら、精度と応答速度の両方が重要になります。

比較軸ごとの判断基準

精度

精度は、自社の業務に近い入力で実際に試して判断します。一般的な評判は参考程度にとどめます。確認するのは、正しい答えを出せるかだけでなく、次のような点です。

• 指示した出力の形式を守れるか
• 分からないときに「分からない」と答えられるか、もっともらしい誤りを作らないか
• 日本語の文章として自然で、業務にふさわしい言葉遣いか
• 長い文書の後半の情報も正しく扱えるか

精度の測り方は、生成AIの出力品質をどう評価するか で詳しく解説しています。

応答速度

応答速度は、最初の文字が出るまでの時間と、回答全体が出終わるまでの時間に分けて考えます。対話型の画面では、文字が順に表示される仕組みを使えば、全体の時間が長くても利用者の待ち時間の感覚は短くなります。一方、回答を受け取ってから次の処理に進む仕組みでは、全体の時間がそのまま待ち時間になります。応答速度の考え方は レイテンシ の用語ページでも説明しています。

一般に、高性能なモデルほど応答に時間がかかり、軽量なモデルほど速い傾向があります。また、考える過程を経てから回答する種類のモデルは、精度が上がる代わりに時間がかかることがあります。

費用

API経由で使う場合の費用は、多くの場合、入力と出力の文章量（トークン数）に応じた従量課金です。同じ提供元でもモデルによって単価が大きく異なるため、利用量の想定と組み合わせて月額を試算して比べます。試算の手順は 生成AIを組み込んだシステム開発の費用 で紹介しています。単価は改定されることがあるため、比較の時点で提供元の最新の料金表を確認してください。

データの取り扱い

業務での利用では、精度以上に重要になることがある条件です。

• 入力したデータが、モデルの学習に使われない契約・設定になっているか
• データがどの国・地域のサーバーで処理され、どれだけの期間保存されるか
• 自社が使っているクラウドの中でモデルを利用できるか
• 取引先との契約や社内規程で、外部への送信が制限されていないか

データを外部に出せない事情がある場合は、自社の環境でモデルを動かす選択肢も検討します。ローカルLLM と呼ばれる方法で、データの管理はしやすくなる一方、サーバーの用意と運用、性能の面での制約が加わります。

その他の確認点

• 一度に扱える文章の長さ（コンテキストウィンドウ）が業務に足りるか
• 画像やPDFなど、文章以外の入力を扱えるか
• 決まった形式で出力させる機能や、外部の機能を呼び出す機能に対応しているか
• 提供元のサービスの安定性、利用量の上限、サポート体制
• モデルの提供期間と、更新・提供終了の告知の方針

提供形態の選択肢

同じ系統のモデルでも、どの経路で使うかによって、データの扱いや管理のしやすさが変わります。

社内ですでに特定のクラウドを使っている場合は、そのクラウド経由でモデルを使うと、セキュリティの審査や契約の手続きが進めやすいことがあります。

自社データで比較検証する手順

候補を絞ったら、実際の業務に近いデータで比較します。

1. 評価用の入力を集める：実際の業務から、典型的な例、難しい例、誤りやすい例を含めて数十件程度を集めます。個人情報や機密情報は、比較に使う環境の条件に合わせて加工します。
2. 望ましい出力の基準を決める：正解が一つに決まるもの（分類、抽出）は正解を用意し、文章の生成のように正解が一つでないものは、満たすべき条件（含めるべき要素、禁止する表現、長さ）を決めます。
3. プロンプトをそろえる：候補のモデルに同じ指示文で試します。ただし、モデルごとに得意な指示の書き方が違うこともあるため、各モデルで簡単な調整をしたうえで比べるのが公平です。
4. 結果を採点する：基準に沿って、人が採点します。件数が多い場合は、別のモデルに採点させる方法を組み合わせます。
5. 応答時間と費用を記録する：同じ入力に対する応答時間と、入出力のトークン数から計算した費用を記録します。
6. 総合して判断する：精度が業務に必要な水準を満たすモデルの中から、費用と応答速度、データの取り扱いの条件で選びます。

比較の結果は、表にまとめて残しておきます。新しいモデルが出たときに、同じ評価用の入力で試せば、切り替えるべきかをすぐに判断できます。

一つに決めず、使い分けと切り替えを前提にする

業務の中には、性質の違う処理が混ざっています。すべてを一つのモデルで処理するより、処理ごとに適したモデルを使い分ける方が、精度と費用のバランスを取りやすくなります。

• 問い合わせの分類や簡単な抽出は、軽量で速いモデル
• 複雑な判断や、長い文書をもとにした文章の生成は、高性能なモデル
• 機密性の高いデータを扱う処理は、自社環境やデータの扱いを管理できる経路のモデル

また、モデルの更新や提供終了、価格改定は避けられません。システムを作るときは、モデルを呼び出す部分を一か所にまとめ、設定の変更で別のモデルに切り替えられるようにしておきます。プロンプトも、特定のモデルの癖に過度に依存しない書き方を心がけます。そして、前述の評価用の入力を保存しておけば、切り替えのたびに品質を確かめられます。

社内の承認を得るための比較資料のまとめ方

モデルを選んだ後、情報システム部門やセキュリティ担当、経営層の承認を得る場面があります。比較の過程を資料にまとめておくと、承認が早く進み、後から「なぜこのモデルにしたのか」を問われたときにも説明できます。

資料には、次の内容を入れます。

1. 対象業務と要件：要件表をそのまま載せ、何を重視したかを一文で書きます。
2. 候補と除外の理由：検討したモデルと提供形態、データの取り扱いや費用で候補から外した理由を書きます。
3. 比較の方法：評価用の入力の件数と内容、採点の基準、誰が採点したかを書きます。
4. 比較の結果：精度・応答時間・月額の試算を表にまとめ、採用するモデルを示します。
5. データの取り扱いの確認結果：学習利用の有無、処理と保存の場所、保存期間、契約の条件を、確認した日付とともに記載します。
6. リスクと対策：誤回答への備え（人の確認、利用範囲の制限）、提供終了や価格改定への備え（切り替えの設計、評価用データの保存）を書きます。
7. 見直しの予定：いつ、どの条件で再比較するかを書きます。

セキュリティ担当からは、データの保存場所やアクセス制御、ログの扱いを問われることが多いため、提供元の公開資料や契約書の該当箇所を確認しておきます。外部の開発会社に依頼する場合に指定すべき項目は、外注開発のセキュリティ要件 も参考にしてください。

承認者が知りたいのは、モデルの技術的な細部よりも「業務の目的に合っているか」「リスクが管理されているか」「費用が見通せるか」の三点です。この三点に答える形で資料をまとめると、議論が短く済みます。

具体的な場面で考える（架空の例）

架空の不動産管理会社を例にします。入居者からの問い合わせメールを分類し、回答の下書きを作る仕組みを検討していました。

• 要件を整理したところ、分類は夜間ではなく受信のたびに行う必要があるが、数秒かかっても問題ないこと、回答の下書きは担当者が確認してから送ることが分かった。
• メールには入居者の氏名や部屋番号が含まれるため、入力データを学習に使わない契約で、自社が使っているクラウドの中で利用できることを条件にした。
• 過去のメールから、典型的な問い合わせ、複数の内容が混ざったもの、感情的な表現を含むものなど、50件を評価用に選び、氏名や部屋番号は仮の値に置き換えた。
• 三つの候補モデルで比較したところ、分類はどのモデルも十分な精度だったため、最も速く安価なモデルを採用した。
• 回答の下書きは、軽量なモデルでは管理規約に基づく説明が不正確になる例があったため、高性能なモデルを採用した。
• モデルの呼び出し部分をまとめて作り、評価用の50件を保存して、半年ごとに新しいモデルと比較する運用にした。

一つのシステムの中でも、処理ごとに選ぶモデルが違うことが分かります。また、分類に軽量なモデルを使ったことで、利用料の大部分は回答の下書きの処理に集中することも見えました。そこで、下書きに渡す参照資料を、分類結果に応じて関係する規約の章だけに絞る工夫を加え、高性能なモデルの利用料を抑えています。モデル選びと処理の設計は切り離せないことが、この例からも分かります。

よくある失敗と避け方

• 評判や順位だけで選ぶ：自社の業務データで試さずに選ぶと、導入後に精度不足や費用過多が分かります。数十件でも自社データで比較します。
• 最も高性能なモデルをすべての処理に使う：単純な処理まで高価なモデルを使うと、利用が増えるほど費用が膨らみます。処理ごとに必要な水準を見極めます。
• データの取り扱いを後から確認する：精度の比較を終えてから規約の問題で使えないと分かると、検証がやり直しになります。データの条件は最初に確認します。
• 比較の条件をそろえない：プロンプトや入力が違う状態で比べても、モデルの差か条件の差か分かりません。
• 試用環境と本番環境の条件の違いを見落とす：試用では快適だった応答速度が、本番の利用量では利用上限に達して遅くなることがあります。本番で想定する同時利用数と、提供元の利用上限を確認します。
• 評価用データを残さない：比較に使った入力と採点基準を残しておかないと、モデルを切り替えるたびにゼロから検証することになります。
• 特定のモデルに強く依存した作りにする：提供終了や価格改定のときに大きな改修が必要になります。呼び出し部分をまとめ、切り替えられる設計にします。

モデル選定のチェックリスト

• AIに任せる業務ごとに、タスク・入力・出力・精度・速度・利用量・機密度・言語を書き出したか
• データの取り扱い（学習利用・保存場所・保存期間）の条件で候補を絞ったか
• 提供形態（直接API・クラウド経由・自社環境・業務ツール内蔵）を比較したか
• 自社の業務に近い評価用の入力を集めたか
• 望ましい出力の基準を決めたか
• 候補のモデルで精度・応答時間・費用を同じ条件で比べたか
• 処理ごとの使い分けを検討したか
• モデルを切り替えられる設計にしたか
• 評価用データを保存し、定期的に見直す時期を決めたか

よくある質問

Q. 国内のモデルと海外のモデル、どちらを選ぶべきですか？

国内か海外かで一律に決めるのではなく、日本語の業務文書での精度、データの処理場所や保存の条件、費用、サポート体制を、自社の要件に照らして比べます。データを国内で処理する必要がある場合は、その条件を満たす提供形態があるかを確認してください。

Q. 新しいモデルが出るたびに乗り換えるべきですか？

必ずしも乗り換える必要はありません。評価用データで比べて、精度・速度・費用のいずれかで業務上意味のある改善がある場合に検討します。乗り換えにはプロンプトの調整と再評価の手間がかかるため、その手間に見合う改善かどうかで判断します。

Q. 自社専用にモデルを学習させた方がよいですか？

多くの業務では、既存のモデルに社内文書を検索して渡す方法や、プロンプトの工夫で十分な結果が得られます。追加の学習は、特殊な文体や形式を安定して出したい場合などに検討するもので、データの準備と費用、更新の手間がかかります。まずは学習なしの方法で試すのが一般的です。

Q. 比較検証にはどのくらいの件数が必要ですか？

業務の多様さによりますが、典型的な例と難しい例を含めて数十件あれば、大きな差は見えてきます。差が小さく判断に迷う場合や、誤りの影響が大きい業務では、件数を増やして確かめます。

Otsumuに相談できること

AIに任せたい業務が一つか二つで、データの取り扱いの条件もはっきりしているなら、この記事の要件表と比較手順に沿って、自社で候補を試して選ぶことは十分に可能です。まずは法人向けのサービスやクラウドの試用環境で、評価用の入力を数十件用意して比べてみることをおすすめします。

一方で、複数の業務にまたがって処理ごとにモデルを使い分けたい、機密性の高いデータを扱うため提供形態の選択が難しい、既存のシステムに組み込んで切り替えやすい設計にしたい、評価の仕組みまで含めて整えたい、といった場合は、設計の段階から専門的な判断が必要になります。

Otsumuでは、業務ごとの要件を一緒に整理し、自社データでの比較検証、処理ごとのモデルの使い分け、切り替えを前提にした設計までを、必要な範囲に絞って支援します。進め方は 生成AIシステム開発 のページで紹介しています。社内文書を参照して回答する仕組みが中心の場合は RAG開発 としてもご相談いただけます。

どのモデルから試せばよいか見当がつかない段階でも構いません。30分の無料相談 で業務の内容を伺い、比較の進め方を一緒に考えます。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01