自社に合うLLMを選定する方法

なぜ「LLM選定」でつまずくのか：機能比較より先に決めるべきこと

「どのLLMが一番性能が高いですか？」は、情シスや管理部門の方からよく出る質問です。しかし、業務で成果を出す観点では、性能ランキングよりも先に決めるべきことがあります。理由は単純で、LLMは“万能の文章生成ツール”ではなく、業務の制約の中で使う部品だからです。例えば、同じ要約でも「社外秘の会議録を要約したい」のか「公開済みの記事を短くしたい」のかで、必要なセキュリティ、コスト、運用体制が大きく変わります。

つまずきポイントは主に3つです。1つ目は、目的が「生成AIを導入する」になってしまい、業務課題が曖昧なままPoC（試験導入）を始めること。2つ目は、比較軸が「回答が賢いか」だけになり、実務で重要なデータの取り扱い、権限、監査、費用の見積もりが抜け落ちること。3つ目は、現場が使う画面や手順（ワークフロー）を設計せず、チャット画面だけ渡して「使ってください」で終わることです。

特に中小企業や、予算はあるが詳しくない大企業の情シスでは、社内の合意形成（法務・セキュリティ・現場）のために説明可能な判断基準が必要になります。本記事では、ベンダー名や流行に左右されず、自社に合うLLM（大規模言語モデル）を選び、失敗しにくい形で導入するための実務手順を整理します。

まず定義する：LLMにやらせる業務を「作業単位」まで分解する

LLM選定の最短ルートは、比較表を作ることではなく「LLMに任せる作業」を具体化することです。おすすめは、業務を「入力→処理→出力→確認→保存」の形に分解するやり方です。例えば「問い合わせ対応を効率化したい」なら、入力はメール本文・顧客情報、処理は分類・回答案作成、出力は返信文、確認は担当者の承認、保存はCRM登録、といった具合です。ここまで分解すると、必要な機能や制約が自然に見えてきます。

次に、対象業務を2種類に分類します。1つは「文章作成・要約・整形」のように正解が1つでない作業。もう1つは「規程に沿って回答する」「製品仕様から抜け漏れなく案内する」など、正確性や再現性が重要な作業です。前者は汎用のLLMチャットでも効果が出やすい一方、後者は社内文書やナレッジを参照する仕組み（RAG：検索拡張生成）や、出力チェックのルールが不可欠になります。

この時点で、選ぶべきLLMの方向性が見えてきます。例えば、個人情報を扱うならデータ保持ポリシーや学習への利用有無、国内リージョンの可否が重要になります。逆に公開情報だけなら、性能とコストのバランスを優先しやすいでしょう。つまり、業務の形を先に決めるほど、LLM選定は“自然に”絞り込まれるのです。

LLMの選択肢を整理する：クラウドAPI・閉域/専用環境・オンプレ/ローカル

LLMの導入形態は、大きく「クラウドのAPIを使う」「クラウドだが専用/閉域の環境で使う」「オンプレやローカルで動かす」に分かれます。専門用語に見えますが、要は「どこで動かし、どこにデータが流れるか」の違いです。ここがセキュリティ・運用・コストに直結します。

まずクラウドAPI型は、最も早く始められます。Webサービスや社内ツールからAPIで呼び出し、文章生成・要約・分類などを行います。メリットは初期構築が軽く、最新モデルをすぐ試せること。デメリットは、データの取り扱いポリシー、リージョン、ログ保存、社内規程との整合を確認する必要がある点です。

次に閉域/専用環境型は、クラウドの利便性を維持しつつ、ネットワークや保存領域を分離したり、企業向けの管理機能（監査ログ、権限、SSO）を強化したりする形です。情シスが求める「誰がいつ何を使ったか」「データがどこに残るか」を満たしやすく、大企業の標準要件に合わせやすいのが特徴です。

最後にオンプレ/ローカル型は、社内サーバーやローカル環境でLLMを動かします。メリットはデータを外に出しにくい点ですが、モデル運用（GPU、更新、監視、性能調整）が必要になり、初期費用と運用難易度が上がりやすいのが現実です。とはいえ、機密度が極めて高い業務や、ネット接続が制限される環境では有力な選択肢です。

ここで重要なのは「オンプレ＝安全、クラウド＝危険」と単純化しないことです。実務では、クラウドでも権限・暗号化・データ保持・監査が整っているケースが多く、逆にオンプレでも運用が甘いと漏えいリスクが上がります。自社の統制レベルと運用体制に合う形を選ぶことが、LLM選定の第一関門です。

選定基準は「性能」だけではない：比較すべき8つの観点

LLM比較でよくある失敗は、デモでの“賢さ”だけで決めてしまうことです。もちろん品質は重要ですが、業務で使うなら運用・統制・費用が同じくらい重要です。以下の観点で、候補をスコアリングすると意思決定が進みます。

• 品質（業務適合度）：自社の文章・用語・業務ルールに合うか。要約、分類、抽出、翻訳などタスク別に評価する。
• 再現性：同じ入力に対して出力がブレすぎないか。温度（ランダム性）設定や指示の型化で安定するか。
• セキュリティとデータ取り扱い：入力データが学習に使われるか、ログ保持期間、暗号化、アクセス制御、リージョン。
• 管理機能：SSO、権限、監査ログ、利用制限、プロンプトやテンプレの共有・承認フロー。
• 拡張性：RAG（社内文書検索）、ツール連携（メール、Slack/Teams、CRM、kintone、SharePoint等）、APIの使いやすさ。
• コスト：トークン課金、固定費、ピーク時の料金、ログ・検索基盤・ベクトルDBなど周辺費用も含める。
• 速度と制限：応答時間、同時実行数、レート制限、長文入力の上限。業務フローに耐えるか。
• ベンダーリスク：モデル更新で品質が変わる、提供停止、価格改定。複数LLMの切替余地を設計できるか。

特に非エンジニアの方に見落とされがちなのが「周辺費用」です。例えば社内文書を参照するRAGを作ると、文書の取り込み、アクセス権連動、検索用データベース、監視などが必要になります。LLMの料金だけ見ていると、後から予算が膨らんで驚くことになります。

また、品質評価も「雑談させて賢い」で終わらせず、実務の入出力で測る必要があります。例えば「請求書の問い合わせメールから、顧客名・請求月・要件を抽出して表にする」「議事録から決定事項とToDoを担当者付きで出す」など、業務の“定型”に寄せたテストが効果的です。ここまでやると、LLMの向き不向きが驚くほどはっきりします。

失敗しない評価手順：小さく試して、数字で比べる（PoCの作り方）

LLM選定のPoC（試験導入）は、期間よりも「設計」が重要です。おすすめは、いきなり全社展開を狙わず、2〜4週間で終わる小さなPoCを複数回回すことです。1回目は“できる/できない”の確認、2回目は品質を上げる工夫、3回目で運用に載せる、という段階が現実的です。

PoCで用意するものは次の3点です。1つ目は、評価対象の業務シナリオ（5〜10個程度）。2つ目は、正解（もしくは望ましい出力の基準）です。例えば要約なら「200文字以内」「結論を先に」「固有名詞は落とさない」といった合否基準を決めます。3つ目は、評価指標です。非エンジニアでも扱える指標としては、業務時間削減、手戻り回数、レビュー工数、誤り件数、担当者の満足度が使いやすいです。

ここで重要なのが、評価対象を「モデル」だけにしないことです。多くの場合、品質はLLMの性能差より、プロンプト（指示文）と入力整形、参照データの作り方で大きく変わります。つまり「AのLLMはダメだった」という結論の前に、「指示を型化したら改善するか」「社内用語集を参照させたらどうか」を試す価値があります。

また、モデル更新で挙動が変わることがあるため、運用を見据えるなら「複数のLLMを同じインターフェースで差し替えできる」設計が安心です。具体的には、社内システム側でLLM呼び出しを抽象化し、設定でモデルを切り替えられるようにします。選定＝固定ではなく、選定＝切替可能性の確保と捉えると、長期運用が安定します。

導入時の設計ポイント：RAG、権限、ガードレール、運用体制

LLMを業務で安全に使うには、「賢い回答」よりも「事故を起こしにくい仕組み」が大切です。特に重要なのが、RAG（社内文書などから検索して根拠を与える）、権限管理、出力のガードレール（制限）、そして運用体制です。

RAGは、LLMが“それっぽく”回答してしまう問題（いわゆる幻覚）を減らす現実的な方法です。社内規程、製品FAQ、契約雛形などを検索して、該当箇所をLLMに渡した上で回答させます。ここでのコツは、文書を闇雲に入れないこと。更新頻度が高い情報、参照すべき正本（最新版）が明確な情報、部署ごとに違うルールがある情報は、文書管理とセットで設計しないと逆効果になります。

次に権限です。RAGで参照できる文書は、ユーザーの閲覧権限と連動させるのが基本です。例えば人事情報を含むファイルが、営業担当の検索結果に出てしまう設計は避けなければなりません。情シスが関与するなら、SSOとグループ権限を前提に、検索インデックスにもアクセス制御を反映させます。LLMそのものより、周辺のデータ基盤がセキュリティの要になります。

さらにガードレールとして、出力の禁止事項や確認フローを入れます。例としては「個人情報を含む可能性がある場合は伏字にする」「社外送信文は必ず人が承認する」「根拠文書が提示できない場合は断定しない」などです。これらは技術だけでなく運用ルールでも実現できます。大事なのは、“人のチェックが必要な場面”を先に決めておくことです。

運用体制も避けて通れません。最低限、以下の役割を決めておくと回り始めます。業務側オーナー（成果責任）、情シス（権限・監査・運用）、法務/セキュリティ（データ取り扱い）、そして現場の代表ユーザー（改善フィードバック）です。LLMの価値は導入時より、運用でプロンプトやナレッジを改善していくことで増えます。改善の窓口がない導入は、ほぼ確実に使われなくなります。

まとめ

LLM選定で最も大切なのは、「どのモデルが最強か」ではなく「自社の業務・データ・運用に合う形で使えるか」です。まずは業務を作業単位まで分解し、機密区分と失敗時の影響を明確にしましょう。その上で、クラウドAPI・閉域/専用環境・オンプレ/ローカルのどれが自社の統制に合うかを決めると、候補は自然に絞れます。

比較は品質だけでなく、セキュリティ、管理機能、拡張性、周辺費用、速度、ベンダーリスクまで含めて評価するのが実務的です。PoCは小さく回し、業務シナリオと合否基準を作って数字で比べると、社内の合意形成が進みます。導入時はRAG、権限、ガードレール、運用体制をセットで設計し、“使える状態を維持する”ことに投資するのが成功の近道です。

もし「自社のケースだとどの選択肢が妥当か」「PoCの設計や評価が難しい」「社内文書を安全に参照させたい」といったお悩みがあれば、業務整理から導入・運用まで伴走できるパートナーに相談するとスムーズです。