第1回 LLMは性能だけで選べない — APIと提供経路をビジネス判断につなげる

連載:LLMのAPIと提供経路を選ぶ・第1回 | 連載のまとめ

「同じ機能がある」だけでは選べない

LLMの選定では、ベンチマークの点数やトークン単価が目を引きます。しかし、業務アプリを作る立場で知りたいのは、必要な仕事を、許容できる費用と責任の範囲で継続して実行できるかです。

たとえば2つのモデルが、どちらも「ツール呼び出し」に対応しているとします。一方では特定ツールの選択をAPIで指定でき、もう一方ではモデルの判断に委ねる必要があるなら、必ず社内規程を検索してから回答するアプリの作り方は変わります。検索をアプリ側の必須ステップにする工数は、性能表には現れません。

提供元の直接APIでは使える機能が、Microsoft Foundry(以下、Foundry)では使えない場合もあります。認証や請求をAzureにまとめられるメリットと、その機能を自前で実装する負担を比べて初めて、提供経路を選べます。

比較対象を3つに分ける

層 問うこと 選定に与える影響
モデルの能力 自社の問題を正しく解けるか 正答率、根拠の質、人手修正の量
APIの契約 どの入力・制御・状態・終了条件を受け付けるか 実装方式、異常処理、会話の保存方法
提供経路の条件 どこで実行し、何が使え、誰が運用するか 調達、認証、所在地、容量、サポート

このように比較対象を分けると、「OpenAIとClaudeのどちらがよいか」という大きな質問を、個別に評価できる質問に変えられます。モデルの不得意を別のSDKで補えることもありますが、モデル自身が受け付けないパラメーターをSDKが有効にすることはできません。

直接APIの比較ではGPT-5.6 SolとClaude Opus 5.5を扱います。両者は長いコンテキストや大きな出力枠を備えていますが、同じ上限値から回答品質が同等だとは判断できません。長い資料から必要な根拠を見つける精度は別の評価項目です。[1][2]

必須条件を先に決める

選定は、必要条件で候補を絞ってから、その中で比較する順序が合理的です。国内での推論処理が必須の業務に、所在地条件を満たさない高性能モデルを加点方式で残しても採用できません。

条件の種類 例 扱い
必須条件 許可された処理地域、必要API、契約条件 未達なら候補から外す
品質の条件 根拠付き回答、誤答率、業務ルール遵守 同じ評価セットで合否を決める
運用の条件 障害対応、退役への対応、ピーク容量 担当者と手順を具体化する
比較する条件 遅延、総費用、機能追加の速さ 合格候補の間で優先順位を付ける

採点する場合の重みは筆者の提案であり、万能な配点はありません。顧客向けチャットでは待ち時間と回答品質、夜間処理では単価と処理容量、社内機密を扱う用途ではデータの扱いが強い制約になります。

仕様の差を事業の言葉に変える

「バッチAPIがない」は機能一覧の記述です。事業の判断では「夜間の大量処理を通常のAPIで実行すると、割引がなく、キュー管理と再試行を自社で運用する」と読み替えます。

「会話状態を提供元に預けられる」は、開発が簡単になる可能性を表します。同時に、保存期間、削除、途中復旧、他サービスへの移行をその仕組みに合わせる必要があります。「自前で持つ」場合は自由度が増す一方、履歴の完全性や削除の責任が増えます。

仕様差 実装上の対応 ビジネス判断
必須ツールをAPIで強制できない アプリで検索などを先に実行する 業務統制に必要な開発費を受け入れるか
サーバー側の状態を利用する 保存・削除・移行を設計する 工数削減と依存の増加を比較する
提供経路で機能が減る 別サービスまたは自前処理で補う Azure運用の統一効果が補完費を上回るか
モデル更新で既定値が変わる 再評価と切り戻しを準備する 継続的な評価予算を確保できるか

この表は設計上の解釈です。実際の費用を断定するものではありません。

選定会議に持ち込む比較単位

モデル名だけで比較せず、モデルとバージョン、API、提供経路、デプロイ種別、状態管理方式を1組の候補として記録します。さらに必須機能の一般提供・ベータ・未検証の区分を付けます。

たとえば「ClaudeをFoundryで使う」だけでは不十分です。Hosted on AzureかHosted on Anthropicかで、利用できる機能と処理場所が変わります。この条件を省いた比較は、後から見積もりや審査をやり直す原因になります。[3]

参考資料

参考資料の仕様確認日:2026年10月8日。

  1. OpenAIのモデル仕様
  2. Claudeのモデル仕様
  3. FoundryでのClaude提供条件