生成AIモデルの選び方｜精度・コスト・速度を比較する評価軸

生成AIモデルの選び方は、一覧の順位やベンチマークの総合点ではなく、業務の重大な失敗、実データ品質、総費用、契約、切り替え条件で決めます。同じモデルでも、入力の長さ、出力形式、地域、固定版の有無、再試行、レビュー工程によって結果は変わります。本稿では、候補名を並べる前に要件を数値化し、採択と撤退を再現できる手順を示します。

モデル名を調べる前に選定票を一枚作る

最初に決めるのはモデルではなく、どの仕事の、どの工程を任せ、何ができれば採用するかです。議事録、契約書レビュー、問い合わせ分類、コード生成では、誤りの影響も人が直せる範囲も異なります。「高精度」「低コスト」といった形容詞を、評価可能な入出力と合格条件へ変えます。

表の数値は組織ごとの想定です。たとえば95%を4秒以内と置いたなら、測定式は「4秒以内に完了した要求数 ÷ 正常に受け付けた要求数 × 100」です。ネットワーク障害や入力不正を分母から除くかを先に決めないと、候補ごとの数字を比較できません。実測前の値は目標案と表示し、調達資料で実績へ言い換えないようにします。

選定の問いは「最も賢いモデルは何か」ではなく、「この業務の失敗を許容範囲に保ち、継続運用できる候補はどれか」です。

機密区分と利用地域を後回しにすると、精度試験に通った候補を法務条件で外し、評価をやり直すことになります。データの送信、保存、学習利用、委託先、国外移転、削除、監査証跡を選定票の入口へ置きます。判断できない項目がある場合は、匿名化した検証データだけで技術評価を進め、本番データの接続は止めます。

候補は公式一覧から取得し、確認日と版を残す

生成AIのモデル名、提供状態、入力上限、機能は変わります。比較サイトの表を候補台帳へ転記するのではなく、利用予定プロバイダーの公式モデル一覧とAPIの列挙結果を確認します。OpenAIの公式モデルページは用途別モデルを案内し、Models APIは利用可能なモデルIDを返します。アカウントや地域によって利用可否が異なるため、文書と実環境の両方を証跡にします^[1][2]。

必要機能も候補台帳で実機確認します。構造化出力、画像入力、ツール呼び出し、ストリーミング、バッチ、キャッシュが文書にあっても、同じモデル、リージョン、API版で併用できるとは限りません。最小の疎通コードを機能ごとに実行し、成功した要求と応答ヘッダーを保存します。管理画面で選べることだけをAPI対応の証拠にしません。

レート制限と割当は、モデルの速度とは別の選定条件です。評価用アカウントで十分な上限があっても、本番組織やリージョンで同じとは限りません。要求/分、token/分、同時実行、日次上限、増枠の申請期間を確認し、月末ピークを処理できない候補は容量対策を含めて比較します。

# OpenAI: 実際の利用環境でモデルIDを列挙する
curl https://api.openai.com/v1/models   -H "Authorization: Bearer $OPENAI_API_KEY"
# Google Gemini: 利用可能モデルと対応メソッドを列挙する
curl "https://generativelanguage.googleapis.com/v1beta/models?key=$GEMINI_API_KEY"

コマンドの結果を記事や提案書へそのまま貼る場合は、キー、組織ID、内部メモを除去します。共有端末でコマンドラインへ秘密を直接書くと履歴へ残るため、組織のシークレット管理と実行基準に従います。候補台帳にはモデルID、確認日、API版、利用リージョン、固定版か可変別名か、必要機能の対応状況を記録します。

Googleの公式モデル文書は、stable、preview、latest、experimentalなどの命名を説明しています。安定版は本番用途の基準になり、latestの別名は新しい版へ差し替わり得ます。評価で使った名前が可変か固定かを区別しなければ、同じテストを翌月に再実行したとき、実体が違う可能性があります^[3]。

プレビュー版しか満たせない要件がある場合は、通常候補と同じ本番前提で採点しません。終了や互換性変更を受け入れられる期間限定の検証として扱い、代替候補と撤退日を決めます。候補の新しさを優先するのではなく、変更を吸収できる運用能力と組み合わせて判断します。

実案件の分布と重大な失敗を評価セットへ入れる

公開ベンチマークは基礎能力を比較する手掛かりですが、自社の略語、文書構造、判断基準、長い入力、曖昧な依頼を代表しません。候補比較では、実案件から匿名化したケースと、見逃すと損失が大きい反例を組み合わせます。正解が一つでない文章生成は、観点別ルーブリックと人の判定手順を用意します。

評価データの漏えいにも注意します。公開されたベンチマークやプロンプト例に正解が含まれていると、実運用への一般化より既知問題への適合を測る可能性があります。自社ケースはアクセスを制限し、候補調整に使う開発集合、最終比較に使う評価集合、採択後の監視集合へ分けます。最終集合を見ながらプロンプトを直し続けないようにします。

サンプルが少ない分類では、正解率の小差を過大評価しません。重大ケース20件で一件の差は5ポイントです。候補を順位付けする前に、誤った事例を業務責任者が読み、同種ケースが母集団にどれほどあるかを確認します。必要なら評価件数を増やし、信頼区間やブートストラップなどを使える分析担当へ相談します。

NISTのAI Test, Evaluation, Validation and Verificationは、AIの特性とリスクを測定し、開発・展開を支えるTEVVの考え方を示しています。AI RMFのMeasureでは、テストセット、指標、ツールを文書化し、配備に近い条件で評価し、運用中も監視することが求められています。これは特定モデルの順位表ではなく、選定試験を再現可能にする枠組みとして利用できます^[4]。

件数は説明用の想定例です。母集団の偏りや重要分類の数に合わせて設計します。全体正解率だけでは、件数が少ない重大分類の見逃しを隠します。重大分類の再現率は「正しく重大分類と判定した件数 ÷ 実際の重大分類件数」、適合率は「正しく重大分類だった件数 ÷ 重大分類と予測した件数」です。誤警報と見逃しのどちらが業務へ重いかを明示します。

採点者には候補名を隠せる範囲で隠し、同じ出力順が評価に影響しないよう無作為化します。採点の不一致は多数決だけで潰さず、ルーブリックが曖昧なのか業務判断が割れているのかを調べます。正解データが安定しない仕事は、モデル選定の前に業務ルールを整える必要があります。

同じ実行条件で品質と安定性を比べる

候補ごとに別のプロンプトを最適化しすぎると、モデル能力ではなく担当者の調整量を比較する試験になります。第一段階は共通のタスク定義、出力契約、評価セット、試行回数で測ります。第二段階で各候補に許される調整を等しい工数枠で行い、改善幅と保守性を比較します。

JSON出力を評価する場合は、構文解析できる割合だけでなく、必須キー、型、列挙値、追加キー、値の意味を確認します。スキーマに適合しても、解約メールを通常分類へ入れれば業務上は失敗です。形式適合率と意味品質を別々に集計し、再試行で形式を直した回数も費用と待ち時間へ加えます。

モデルを審判として使う自動評価は、大量比較を補助できますが、採点モデルの偏りや自己選好を受けます。人が判定した基準集合と一致率を確認し、重大ケースの最終判定を置き換えません。採点モデル、指示、版を実行記録へ含め、候補モデルの更新と同時に評価器まで無断で変えないようにします。

実行記録にはモデルID、API版、日時、リージョン、主要パラメーター、システム指示の版、入力ケースID、応答、エラー、待ち時間を残します。プロバイダーが固定スナップショットを提供する場合でも、周辺APIや安全設定が変わる可能性を考慮します。OpenAIの後方互換性文書も、モデルの出力挙動がスナップショット間で変わり得るため、固定版と評価の併用を案内しています^[5]。

{
  "run_id": "eval-20260730-03",
  "case_id": "critical-017",
  "provider": "candidate-b",
  "model_id": "exact-id-from-api",
  "prompt_commit": "9f14c2a",
  "temperature": 0,
  "started_at": "2026-07-30T02:10:33Z",
  "latency_ms": 1840,
  "result_schema_valid": true,
  "review_status": "pass"
}

temperatureを0にしても、すべての環境で完全に同じ出力になる保証はありません。重要ケースは複数回実行し、合格率と失敗の種類を記録します。想定例として各ケースを3回試すなら、ケース安定率を「期待判定だった回数 ÷ 3 × 100」で表せます。ただし3回は統計的な万能値ではなく、候補を絞るための初期設計です。

文章生成では、一つの総合点へ早く集約しない方が判断しやすくなります。事実性、要件充足、読みやすさ、根拠提示、禁止内容、安全な保留を別々に採点し、必須項目に足切りを置きます。読みやすさが高くても事実誤認がある出力は合格させません。採点例と反例をルーブリックに添え、担当交代後も判定を再現できるようにします。

単価ではなく業務一件当たりの総費用を計算する

価格表の入力・出力単価だけを比べると、再試行、長い推論、キャッシュ、検索、監視、人のレビューを落とします。候補ごとに同じ評価セットを実行し、実際のトークン量、呼び出し回数、失敗率、待ち時間を測ります。価格は変動するため、通貨、確認日、契約割引の有無を試算表へ残します。

為替を伴う価格は、採用した換算日とレートを明記し、為替が一定割合動いたシナリオも出します。無料枠や初回クレジットは継続費用から分けます。キャッシュ割引やバッチ割引を計上するなら、対象要求が条件を満たす割合を実ログから推定し、全件へ適用できる前提にしません。

品質が低い候補は、安価でも人の確認を増やします。想定例として確認時間が一件30秒から90秒へ増え、担当者の時間単価が3,000円なら、追加費用は「60秒 ÷ 3,600秒 × 3,000円 = 50円/件」です。モデル単価が数円下がる差より大きい可能性があるため、レビュー時間を実験で測ります。

合計は「モデル利用料 + 再試行費 + 周辺基盤按分 + 人の確認費 + 手戻り期待値」です。架空例として、モデル0.8円、再試行0.1円、基盤0.4円、人の確認12円、手戻り3円なら合計16.3円です。0.8円だけをモデル費として示すと、調達後に支配的な費用が人の確認だと分かる構図を隠します。

待ち時間は、最初のトークンが表示されるまでと完了までを分けます。ストリーミングで体感は改善しても、後段が完全なJSONを待つ処理なら完了時間が重要です。p95だけでなく、タイムアウト率と再試行後の総時間も測ります。モデルが速くてもレート制限で待機が増える候補は、実トラフィックを模した負荷試験で差が出ます。

大量バッチ、常時対話、月末集中では最適候補が変わる可能性があります。通常月とピーク月を分け、月間総費用と必要な同時実行数を試算します。価格差が小さい場合は、不確実なコスト予測で勝敗を決めず、重大品質、契約、移行性を優先します。

データ条件、責任分界、変更通知を契約で確認する

技術評価を通った候補について、利用規約、データ処理条件、サービス仕様、SLA、サポート、廃止通知を確認します。Web版のチャットとAPI、個人契約と法人契約では条件が同じとは限りません。営業資料の要約だけでなく、契約本文と付属文書の該当条項を法務担当と照合します。

契約交渉で得た回答は、担当営業のメールだけでなく契約へ反映されたかを確認します。ロードマップ上の機能や将来対応は、現在の合格条件として採点しません。未提供機能が必須なら、提供日と受入試験を停止条件にし、それまでは別候補または手作業を使います。

サポート評価では、実際に技術質問を一件出し、受付、本人確認、初動、技術回答、エスカレーションを記録します。応答が速くても解決に必要なログを安全に渡せない、重大障害の日本時間窓口がない場合は運用設計へ影響します。契約の優先サポートとコミュニティ掲示板を同じ支援として扱いません。

法令適合をモデル提供者へ丸投げすることはできません。自社がどのデータを何の目的で処理し、出力を誰へ提供するかに応じて、必要な通知、同意、委託管理、セキュリティ統制を判断します。高機密データの扱いを契約文書から確定できない候補は、匿名化データの試験に留めます。

SLAの数字も、自社の業務時間と照合します。月間可用性が高くても、月末締めの数時間に障害が集中すれば業務影響は大きくなります。代替処理、手作業へ戻す条件、サポートの受付時間、重大度の定義、返答と復旧の違いを確認します。

調達を止める条件：機密データの利用・保持条件が確定しない、実体が変わるモデルを変更検知なしで本番利用する、重大な誤りを人が検出できない、または代替手段を用意できない場合です。

足切りと重み付き比較を分けて採択する

すべてを点数化すると、必須条件の欠落が他項目の高得点で相殺されます。最初に、データ条件、重大品質、必要機能、利用地域、契約上の禁止事項を足切りとして判定します。一つでも満たさない候補は、総合点を計算せず不採択または限定検証へ移します。

採択後は比較表を凍結し、実運用の監視票を別に開始します。後から得た良い結果だけを選定時の表へ上書きすると、当時の判断を再現できません。再選定では新しい評価番号を発行し、旧結果、変更理由、候補の現行版を並べて承認します。

重みの感度分析も行います。費用の重みを10ポイント増やした場合、重大品質の重みを同じだけ減らすと順位が逆転するなら、結果は経営上の優先順位に強く依存しています。逆転する境界を示し、総合点だけでなくどの価値判断が採択を決めたかを承認記録へ残します。

候補ごとの未確認事項には、楽観値と悲観値を置きます。サポート点が未評価なのに中間点を与えると、不確実性が見えません。未確認を0点として足切りする方法、点数範囲で順位が変わるかを見る方法を選び、確認期限を設定します。契約前に解消できない重要項目が残る候補は、限定検証までに留めます。

同点ならモデルの派手なデモで決めず、変更安定性と撤退試験の証拠を優先します。品質差が評価誤差の範囲なら、固定版、廃止通知、データ削除、代替候補への移行時間が運用リスクを左右します。採択会議では、各候補の重大な失敗例を少なくとも数件読み、点数に隠れた違いを確認します。

足切りを通った候補だけを、品質、待ち時間、総費用、運用性、変更安定性、サポート、移行性で比較します。重みは合計100%にし、業務責任者が理由を承認します。想定例として重大品質35%、通常品質15%、待ち時間10%、総費用15%、運用性10%、契約・支援10%、移行性5%と置けますが、これは問い合わせ分類の例であり、創作支援やバッチ要約へ流用しません。

5段階評価なら加重点は「各軸の点数 ÷ 5 × 重み」の合計で算出します。点数の差だけでなく、測定誤差と未確認事項を併記します。候補Aが81点、候補Bが82点でも、重大ケースのサンプルが少なく差が安定しないなら、1点差を意思決定の根拠にしません。重大エラーの内容と契約上の不確実性を会議で読む方が有益です。

採択記録には、落選理由も残します。後に価格や仕様が変わったとき、どの条件が変われば再評価するかが分かります。比較時点のモデルID、評価セット版、プロンプト版、価格確認日、採点者、承認者を結び付け、後から現行候補と混同しないようにします。

限定導入と撤退試験を採用条件に含める

机上比較の一位を直ちに全社標準へせず、限定された利用者とデータでカナリア導入します。最初は提案のみを出し、人が最終処理する形にすれば、見逃し、過信、画面上の誤誘導を観察できます。本番監視では、評価セットの品質だけでなく、上書き率、保留率、重大誤り、待ち時間、再試行、問い合わせを記録します。

カナリア期間では、新旧工程を同じ案件で並行評価しても、利用者へ二重作業を無期限に求めません。対象件数と終了条件を決め、差異が出たケースだけを専門担当が裁定します。新候補が良く見えるケースだけでなく、旧工程が救済したケースを集め、全面移行後に失われる防御を確認します。

切替演習では、プロバイダー障害、モデル廃止、品質低下、契約終了の四つを分けます。障害なら一時的な代替、廃止なら評価を伴う移行、品質低下なら固定版への戻し、契約終了ならデータ削除と請求停止が必要です。シナリオごとの担当と時間を測ることで、移行性を評価表の抽象点から実証へ変えられます。

切り替えを容易にするには、業務アプリがプロバイダー固有の応答を直接扱わないよう、入出力契約と変換層を設けます。ただしすべての機能を最小公倍数にすると候補の強みを失います。共通必須機能と候補固有の追加機能を分け、固有機能を使う箇所と代替動作を台帳化します。

撤退試験では、代替モデルへ同じ評価セットを流し、必須出力を生成できるか確認します。APIキーの切り替えだけでなく、プロンプト、出力スキーマ、レート制限、監視、請求、データ削除を含む手順を演習します。切り替え時間は「代替起動から正常な代表業務が完了するまで」で測り、DNS変更だけの時間に縮めません。

ローカルモデルが候補になる場合は、API単価の代わりにGPU・電力・保守・更新・監視・人員を総費用へ入れます。データを外へ出さない利点があっても、端末へ広く複製すれば統制は弱くなります。導入形態の違いは、モデル品質とは別軸で評価します。

選定を見送るべき業務もあります。正解を定義できず、重大な誤りを検出する人もおらず、出力を自動実行するしかない仕事では、候補間比較の前提が成立しません。その場合は工程を分割し、AIの出力を提案へ限定するか、決定論的なルールと既存システムを使います。

次に取る行動は、候補モデルを増やすことではありません。直近の実案件から通常20件、境界10件、重大10件を選び、期待結果と失格条件を業務責任者が確定します。その40件を固定したモデルIDで実行し、重大失敗がゼロの候補だけを総費用と移行性の比較へ進めます。

参考文献・一次情報

1. OpenAI公式『生成AIモデル一覧・Models』（2026-07-30確認）
2. OpenAI公式APIリファレンス『モデル選定用List models』（2026-07-30確認）
3. Google AI for Developers公式『Gemini models』（2026-07-30確認）
4. NIST公式『AI Test, Evaluation, Validation and Verification』（2026-07-30確認）
5. OpenAI公式APIリファレンス『Backward compatibility』（2026-07-30確認）