法人向けLLM・AIツール選定 (情シス視点)

カタログスペックに惑わされないLLM比較・選定の実践アプローチ：APIとスプレッドシートで構築する評価基準

この記事は急速に進化する技術について解説しています。最新情報は公式ドキュメントをご確認ください。

約16分で読めます
文字サイズ:
カタログスペックに惑わされないLLM比較・選定の実践アプローチ：APIとスプレッドシートで構築する評価基準
目次

この記事の要点

  • 情シス視点でのセキュリティ・コスト・統制を重視したLLM選定基準
  • カタログスペックに惑わされない、実効的な評価フレームワークの構築
  • 導入後の現場定着と持続可能な運用ガバナンスの設計

このチュートリアルのゴール：根拠あるLLM選定を実現する

AIツールの導入プロジェクトにおいて、最も頭を悩ませる課題の一つが「どのモデルを採用すべきか」という選定プロセスではないでしょうか。日々新しいモデルが発表され、各社がベンチマークスコアの優位性を大々的にアピールしています。上層部から「一番賢いAIを入れてくれ」と言われ、客観的な説明材料の用意に苦慮した経験を持つIT推進担当者やDXエンジニアの方も多いはずです。

しかし、一般的な指標がそのまま自社のビジネス価値に直結するでしょうか。

既存の比較記事にある一般的な性能差ではなく、自社の実業務（メール作成、要約、コード生成、社内文書検索など）において、どのモデルが最も高いROI（投資対効果）を出すかを判定するための「評価シート」を作成することが、本チュートリアルの目標です。

なぜ比較表だけでは不十分なのか

「MMLU（大規模マルチタスク言語理解）スコアが90%を超えた」といったカタログスペックは、モデルの基礎能力を示す指標としては確かに有用です。しかし、実際のビジネス現場で求められるのは、「自社特有の専門用語を正しく理解できるか」「指定したフォーマット（JSONや特定の表形式など）を厳格に守って出力できるか」といった、極めてドメインに特化したタスクの遂行能力に他なりません。

汎用的なベンチマークテストでは優秀な成績を収めるモデルであっても、自社の過去の営業日報を要約させると、重要なニュアンスを欠落させてしまうケースは珍しくありません。また、「ネットの評判は良かったのに、うちの業務フローには全く合わなかった」という失敗談もよく耳にします。

だからこそ、自社固有のタスクと実データを用いて、定量的・定性的な評価軸で計測することが不可欠なのです。専門家の視点から言えば、自社データを入力した際の実測値こそが、唯一信頼できる選定基準となります。

作成する「LLM評価スコアカード」の全体像

このチュートリアルでは、Googleスプレッドシートをベースとした「LLM評価スコアカード」を構築します。大掛かりなシステム開発は必要ありません。このスコアカードには、以下の3つの機能を持たせます。

  1. プロンプトの一括実行: 複数のLLMのAPIに対して、同一のプロンプトを同時に送信する。
  2. 出力結果の横並び比較: 各モデルからの回答を同じ行に並べて表示し、目視または自動での採点を容易にする。
  3. コストと速度の自動計算: 消費されたトークン数に基づく推定コストと、APIの応答時間（レイテンシ）を記録し、パフォーマンスを可視化する。

この仕組みを構築すれば、上層部への説明時に「なんとなく精度が良かったから」ではなく、「自社の頻出タスク100件でテストした結果、モデルAは精度スコア4.5、1リクエストあたりのコストは〇〇円、応答速度は〇〇秒であったため最適と判断した」という、強固なロジックを提示できるようになります。

環境構築と準備：評価用テストデータの作成

このチュートリアルのゴール：根拠あるLLM選定を実現する - Section Image

では、具体的にどのように進めればよいのでしょうか。まずは基盤となるツールとデータを用意しましょう。使い慣れた表計算ソフトと簡単なスクリプトを組み合わせるだけで、十分に強力な評価エンジンを構築できます。一緒に手を動かしてみましょう。

必要なツール（Google Sheets / APIキー）

以下の環境を準備してください。

  • Google スプレッドシート: 評価データの蓄積とインターフェースとして使用します。非エンジニアの担当者でも直感的に操作でき、社内共有が容易な点が最大のメリットです。
  • Google Apps Script (GAS): スプレッドシートの裏側で動き、各LLMのAPIを呼び出すための簡単なプログラムを記述します。
  • APIキーの取得: 比較対象となるLLMプロバイダーのアカウントを作成し、APIキーを発行します。
    • Anthropic API: Claudeファミリーを利用するため。
    • Google AI Studio: 長大なコンテキストを扱えるGeminiファミリーなどを利用するため。

スプレッドシートの列構成は、以下のように設計することをおすすめします。

  • A列：タスクID
  • B列：タスクカテゴリ（例：要約、翻訳、情報抽出）
  • C列：システムプロンプト（役割定義）
  • D列：ユーザープロンプト（具体的な指示と入力データ）
  • E列：期待する出力（Ground Truth）
  • F列以降：各モデルの出力結果、応答時間、消費トークン数

良質なテストデータセットの作り方

評価の信頼性は、入力する「テストデータ」の質に完全に依存します。ネット上のサンプル文章ではなく、必ず自社の実業務で発生するデータを使用してください。ここを妥協してしまうと、評価エンジン自体の意味がなくなってしまいます。

テストデータセット（プロンプトの集合）を作成する際のポイントは以下の通りです。

  1. バリエーションの確保: 長文の要約、短文の分類、複雑な条件分岐を含む論理的推論など、業務で想定されるタスクを網羅的に含めます。統計的な有意性を担保するため、最低でも30〜50件程度のデータを用意することが望ましいでしょう。
  2. エッジケースの包含: 意図的にノイズの多いデータや、情報が不足しているプロンプトを含めます。例えば、カスタマーサポートのFAQ検索において、あえて社内マニュアルに載っていない質問を投げかけてみてください。優秀なモデルは「情報が不足していて回答できません」と正しくギブアップできますが、そうでないモデルはハルシネーション（もっともらしい嘘）を引き起こします。実稼働時のリスクを測る上で、このテストは非常に有効です。
  3. Ground Truth（正解データ）の定義: 定量評価を行うためには、「何が正解か」を事前に定義しておく必要があります。例えば、法務部門における「NDA（秘密保持契約書）の条項チェック」であれば、「必ず抽出・指摘すべきリスク条項」を正解条件として定義します。クリエイティブなタスクの場合は、「遵守すべきフォーマット（例：マークダウンの箇条書きであること）」を正解条件とします。

Part 1：精度評価の実装（プロンプト等価テスト）

環境とデータが整ったら、実際に各LLMへリクエストを送信し、精度を評価するフェーズに入ります。ここからが本格的な検証のスタートです。

同一条件での出力比較手順

各モデルの純粋な推論能力を比較するためには、全く同じプロンプト（システムプロンプトとユーザープロンプトの組み合わせ）を送信する「プロンプト等価テスト」が基本となります。モデルごとにプロンプトの書き方を微調整（プロンプトエンジニアリング）してしまうと、モデル自体の性能差なのか、プロンプトの書き方の差なのかが切り分けられなくなるためです。

以下は、GASを使用してAPIを呼び出すための概念的なコード構造の例です。これをコピー＆ペーストし、ご自身の環境に合わせて微調整してみてください。

// GASでのAPI呼び出し関数の基本構造
function callLLM(systemPrompt, userPrompt, modelName) {
  const startTime = new Date().getTime();
  let apiUrl, headers, payload;

  // モデル名に応じてエンドポイントとペイロードを切り替え
  // ※エンドポイントやモデル名は必ず公式ドキュメントの最新情報を参照してください
  if (modelName === 'claude') {
    // Anthropic公式ドキュメント（https://docs.anthropic.com）を参照
    apiUrl = 'https://api.anthropic.com/v1/messages';
    headers = {
      'x-api-key': 'YOUR_ANTHROPIC_API_KEY',
      最新の 'anthropic-version' を公式ドキュメント（https://docs.anthropic.com）で確認の上使用してください。
      'Content-Type': 'application/json'
    };
    payload = {
      最新のClaudeモデル（例: claude-sonnet-4-6など）を公式ドキュメント（https://docs.anthropic.com）で確認の上指定してください。
      max_tokens: 1024,
      system: systemPrompt,
      messages: [{ role: 'user', content: userPrompt }]
    };
  } else if (modelName === 'gemini') {
    // Google AI for Developers（https://ai.google.dev/gemini-api/docs/models/gemini）を参照
    // 例として Gemini 2.5 Flash を指定
    apiUrl = 'https://generativelanguage.googleapis.com/v1beta/models/gemini-2.5-flash:generateContent?key=YOUR_GEMINI_API_KEY';
    headers = {
      'Content-Type': 'application/json'
    };
    payload = {
      contents: [{ role: 'user', parts: [{ text: systemPrompt + "\n\n" + userPrompt }] }]
    };
  }

  const options = {
    method: 'post',
    headers: headers,
    payload: JSON.stringify(payload),
    muteHttpExceptions: true
  };

  const response = UrlFetchApp.fetch(apiUrl, options);
  const endTime = new Date().getTime();
  const latency = (endTime - startTime) / 1000; // 秒に変換

  // 実際の運用ではここでJSONをパースし、テキストとトークン数を抽出します
  // return { text: parsedText, latency: latency, tokens: tokenCount };
}

この関数をスプレッドシートの各行に対してループ処理で実行し、結果をセルに書き込んでいきます。プログラミングの知識が少しあれば、すぐに実装できるはずです。

評価指標（ハルシネーション率・指示追従性）の設定

出力結果が揃ったら、採点を行います。単なる「良し悪し」の感想ではなく、ビジネス要件に基づいた客観的な評価軸を設定することが重要です。システム開発の観点から、以下の指標は特に注視すべきです。

  • 指示追従性（Instruction Following）: 指定した文字数制限、出力フォーマット（JSONや特定のCSV形式等）、トーン＆マナーを厳格に守っているか。後続のシステムでデータをプログラム処理する際、JSONの構造が少しでも崩れているとシステムエラーに直結します。そのため、この指標は3段階評価（完全に遵守＝3、一部逸脱＝2、完全無視＝1）などで厳格に採点します。
  • 事実正確性・ハルシネーション率: 提供したコンテキスト（入力データ）に存在しない情報を捏造していないか。特に社内規程の検索やRAG（検索拡張生成）の文脈では、この指標が最も重要になります。嘘をつくくらいなら「わからない」と答えるモデルの方が、ビジネスでの信頼性は高くなります。
  • 推論能力: 複雑な計算や、複数の条件が絡み合う論理的な問いに対して、正しいプロセスを経て結論を導き出せているか。

初期段階では、担当者が目視で採点（Human-in-the-loop）することをおすすめします。評価基準が明確になれば、別の強力なLLMを「評価者」として用い、自動採点させる手法（LLM-as-a-Judge）を導入することで、何百件ものテストを数分で完了させることも可能になります。

Part 2：コスト・パフォーマンスの計測

Part 1：精度評価の実装（プロンプト等価テスト） - Section Image

精度が要件を満たしていても、コストが見合わなければビジネス実装は不可能です。「精度は最高だが、予算を大幅にオーバーしてしまう」という事態は避けなければなりません。ここでは、運用時のランニングコストと、ユーザー体験に直結するレスポンス速度を計測するアプローチを解説します。

トークン単価の算出方法

LLMのAPI利用料金は、基本的に「入力トークン数」と「出力トークン数」の従量課金制です。トークンとは、AIがテキストを処理する際の最小単位であり、英語と日本語では1文字あたりの消費トークン数が異なる点に注意が必要です。一般的に、日本語は英語に比べてトークン数が多くなる傾向があり、想定以上のコストがかかるケースが報告されています。

各プロバイダーの公式サイトで最新の料金体系を確認し、スプレッドシートに計算式を組み込みます。

Anthropic公式ドキュメントやGoogle AI for Developersの公式サイトによると、モデルのグレード（例：Pro、Flash、Sonnetなど）や入力・出力のトークン数に応じて細かく単価が設定されています。

【重要】 APIの料金体系や提供モデルのバージョンは頻繁にアップデートされます。過去の比較記事の数値を鵜呑みにせず、導入検討時には必ず各プロバイダーの公式ドキュメント（本記事末尾の参考リンク参照）で最新の料金と現行の推奨モデルをご確認ください。

評価シートでは、APIのレスポンスに含まれる「usage（トークン使用量）」のデータを取得し、以下の式で1リクエストあたりの推定コストを算出します。

推定コスト = (入力トークン数 × 入力単価) + (出力トークン数 × 出力単価)

これを自社の月間想定リクエスト数（例：月間10万回の社内問い合わせ）に掛け合わせれば、現実的な月額ランニングコストのシミュレーションが可能になります。

レスポンス速度の測定

コストと同様に重要なのが「生成速度（レイテンシ）」です。チャットボットのようにリアルタイム性が求められるユースケースでは、回答に10秒以上かかるモデルは、いくら精度が高くてもユーザーの離脱を招きます。あなたも、返答が遅いAIツールにイライラした経験があるのではないでしょうか。

Part 1のスクリプトで記録したAPI呼び出しの開始時間と終了時間の差分（秒数）を、出力トークン数で割ることで、「1秒あたりに生成できるトークン数（Tokens Per Second）」を算出します。これにより、単純な応答時間だけでなく、モデル固有の生成スピードのポテンシャルを横並びで客観的に比較できます。

Part 3：総合判定と意思決定フレームワーク

Part 3：総合判定と意思決定フレームワーク - Section Image 3

精度、コスト、速度のデータが出揃ったら、最終的なスコアリングと意思決定を行います。ここで重要なのは、単なる平均点ではなく「ビジネス要件に基づいた重み付け」を行うことです。

重要度に応じた重み付け計算

すべての指標が等しく重要視されるわけではありません。自社のユースケースに合わせて、各指標に「重み（ウェイト）」を設定します。

例えば、社内の技術ドキュメントを夜間に高精度で翻訳する非同期バッチ処理のタスクであれば、「精度：70%、コスト：20%、速度：10%」といった重み付けになります。一方、カスタマーサポート向けのリアルタイムチャットボットであれば、ユーザーを待たせないことが至上命題となるため「速度：40%、精度：40%、コスト：20%」といったバランスになるでしょう。

スプレッドシート上で、各モデルのスコアを正規化（0〜1の範囲に変換）し、重みを掛け合わせて「総合スコア」を算出します。この定量化された総合スコアこそが、カタログスペックに惑わされない「自社にとっての最適解」となります。

選定理由（ロジック）のドキュメント化

総合スコアが算出されたら、上層部やステークホルダー向けに選定理由をドキュメント化します。ここでは、単にスコアが高いモデルを推すだけでなく、トレードオフの関係を明示することが重要です。

例えば、以下のようなロジックを組み立ててみてください。

「最高精度のモデルAは、要件を100%満たしますが、月額想定コストが予算を大きくオーバーします。一方、軽量モデルBは複雑な推論タスクでわずかな精度低下が見られましたが、コストはモデルAの数分の一であり、速度も圧倒的です。今回のユースケースにおいては、モデルBを採用し、精度低下分はプロンプトの改善とRAGの検索精度向上でカバーする方針を提案します。」

システム開発の現場では、最初から完璧な1つのモデルに絞り込もうとしてプロジェクトが停滞するケースが珍しくありません。専門家の視点から言えば、まずは要件を満たす軽量モデルで迅速にプロトタイプを作り、精度が不足するタスクだけを上位モデルに切り替える設計思想を持つ方が、結果的にROIが高くなります。経営陣が求めているのは「どのAIが一番賢いか」ではなく「どのAIがビジネスに最も貢献するか」なのです。

トラブルシューティングと運用上の注意点

独自の評価環境を構築・運用する上で、実務担当者が直面しやすい技術的・コンプライアンス上の課題とその解決策を解説します。事前にリスクを把握しておくことで、スムーズな検証が可能になります。

APIのレートリミット対策

GASを使って数十件のプロンプトを連続でAPIに送信すると、高確率で「レートリミット（Rate Limit）エラー」に遭遇します。各プロバイダーは、サーバー負荷を防ぐために1分あたりのリクエスト数（RPM）やトークン数（TPM）に上限を設けているためです。

この問題を回避するには、スクリプト内に適切なエラーハンドリングと遅延処理（スリープ）を実装する必要があります。

// レートリミット対策の疑似コード例
let success = false;
let retryCount = 0;
const maxRetries = 3;

while (!success && retryCount < maxRetries) {
  try {
    // API呼び出し処理
    response = UrlFetchApp.fetch(apiUrl, options);
    success = true;
  } catch (e) {
    if (e.message.includes("429")) { // HTTP 429 Too Many Requests
      // 指数バックオフ：リトライのたびに待機時間を倍増させる
      Utilities.sleep(5000 * Math.pow(2, retryCount)); 
      retryCount++;
    } else {
      throw e; // その他のエラーはスローして処理を中断
    }
  }
}

エラー発生時に待機時間を徐々に増やしながら再試行する「指数バックオフ（Exponential Backoff）」の実装は、安定した評価システムを構築する上で不可欠なテクニックです。

セキュリティとプライバシー（データ利用の拒否設定）

自社の業務データをAPI経由で送信する際、最も懸念されるのが「送信したデータがAIモデルの再学習に利用されないか」というコンプライアンス上の問題です。機密情報が外部に漏洩するリスクは絶対に避けなければなりません。

一般的に、主要プロバイダーが提供する有料API（エンタープライズ向け含む）では、デフォルトで入力データがモデルの学習に利用されない仕様になっていることが多く見受けられます。しかし、無料枠や特定のコンシューマー向けエンドポイントを使用する場合は、学習利用のオプトアウト（拒否）設定が必要なケースが報告されています。

評価環境を構築する前に、必ず各社の公式ドキュメントで最新のデータプライバシーポリシーを確認し、社内のセキュリティ基準を満たしているか法務部門と連携して確認するプロセスを踏んでください。

完成と次のステップ：継続的な評価プロセスの構築

お疲れ様でした。スプレッドシートとAPIを活用し、自社の実業務に基づいた客観的なLLM評価フレームワークが完成しました。これで、自信を持って選定理由を語ることができるはずです。

モデルの進化に合わせた定期見直し

生成AIの領域は進化のスピードが非常に速く、数ヶ月単位で新しいモデルがリリースされたり、既存モデルの価格が劇的に改定されたりします。今回作成した評価シートは、一度きりの使い捨てではありません。新しいモデルが登場した際に、同じテストデータを流し込むだけで、即座に自社への適合度を再評価できる「継続的なベンチマーク基盤」として機能します。

定期的に評価スクリプトを実行し、よりコストパフォーマンスの高いモデルへの乗り換えを検討する体制を整えることをおすすめします。この柔軟性こそが、システムを内製化する最大のメリットです。

PoC（概念実証）への移行

APIレベルでの評価が完了し、最適なモデルの目星がついたら、次はいよいよ実際のシステムやアプリケーションに組み込むPoC（概念実証）フェーズへの移行です。

しかし、APIの生データやスプレッドシート上の数値だけでは、エンドユーザー（現場の従業員や顧客）は使い勝手を評価できません。実際のUI/UXを備えた環境で、ユーザーがどのようにプロンプトを入力し、どのような回答を得て業務効率が上がったかを検証する必要があります。

自社への適用を本格的に検討する際は、実際の操作感や業務フローへの組み込みイメージを掴むために、製品体験を通じて導入意欲を高めるプロセスが有効です。まずは、無料デモや14日間のトライアル環境などを活用して、選定したモデルの実力を現場レベルで体感し、プロジェクトを次のステップへと確実におし進めてみてはいかがでしょうか。

参考リンク

本記事で言及した各ツールの最新情報（機能詳細、料金体系、プライバシーポリシーなど）については、以下の公式情報をご確認ください。

カタログスペックに惑わされないLLM比較・選定の実践アプローチ：APIとスプレッドシートで構築する評価基準 - Conclusion Image

参考文献

  1. https://www.youtube.com/watch?v=umoAIATmPQo
  2. https://app-liv.jp/articles/155944/
  3. https://genai-ai.co.jp/ai-kanri/blog/cc-yt-claude-nikkei-business-43/
  4. https://shunkudo.com/claude%E3%81%AE%E6%9C%80%E6%96%B0%E3%82%A2%E3%83%83%E3%83%97%E3%83%87%E3%83%BC%E3%83%88%E6%83%85%E5%A0%B1-2/
  5. https://www.sbbit.jp/article/cont1/185267
  6. https://support.claude.com/ja/articles/12138966-%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%83%8E%E3%83%BC%E3%83%88
  7. https://uravation.com/media/claude-features-complete-guide/
  8. https://qiita.com/ukun3/items/9dd0716df0267719a460
  9. https://blog.serverworks.co.jp/claude-code-desktop-redesign-2026
  10. https://note.com/samuraijuku_biz/n/n620e53b881b6

コメント

コメントは1週間で消えます
0 / 150
コメントを読み込み中...