第6回 LLMの採用を決める — 総費用・評価・移行を説明できる選定へ
連載：LLMのAPIと提供経路を選ぶ・第6回 ｜ 連載のまとめ
業務1件を完了するための総費用
モデルの単価が同じでも、業務アプリの費用は同じになりません。推論量、キャッシュ、再試行、ツール実行、失敗後の人手による修正が変わるためです。直接APIとMicrosoft Foundry（以下、Foundry）を比べるときも、その違いが月間の運用費と開発費にどう影響するかを見積もります。
この記事の計算式と、次の導入段階へ進むための判定条件は筆者の提案です。実際の利用明細やベンチマークを示すものではありません。
単価以外に計上する費用
期間の総費用
= モデル利用料 + ツール・検索・実行環境費
+ 保存・監視・ネットワーク費 + 運用工数
+ 初期開発費・移行費の期間配分 + 人手修正費
成功業務1件あたりの費用
= 期間の総費用 / 合格条件を満たして完了した業務件数
式の運用工数や人手による修正は、作業時間に人件費の単価を掛けて費用に換算します。初期開発費・移行費も、比較する期間へ配分して計上します。
モデル利用料は、非キャッシュ入力、キャッシュ書込、キャッシュ読込、出力の区分で集計します。推論が出力使用量に含まれる場合は、同じ分を重ねて計上しません。応答の受信が途中で切れた場合や再試行した場合にも、処理が発生する可能性があります。そのため、画面に表示された量だけで課金量を見積もらないことが重要です。
| 費用項目 | 記録する情報 |
|---|---|
| モデル | 実モデル、入力・出力使用量、推論の内訳、料金表の適用日 |
| キャッシュ | 新規書込とヒットの量、保持期間（TTL）、ヒット率 |
| ルーティング | 判定用呼び出し、誤判定後の再送 |
| ツール | 検索、実行環境、外部API、転送、再実行 |
| 運用 | アラート対応、仕様変更、退役対応、評価作業 |
| 業務 | 完了件数、拒否・未完了、人手修正時間 |
単価と合わせて確認する料金条件
2026年10月8日の直接APIの公表値では、GPT-5.6 SolとClaude Opus 5.5は、どちらも100万トークンあたり入力4米ドル・出力20米ドルという基本単価です。ただしGPT-5.6 Solは少なくとも2026年11月21日までのプロモーション価格です。長い入力の割増とキャッシュ条件も別に確認します。[1][2]
Claudeの直接APIにはバッチ割引がありますが、FoundryのClaudeではMessage Batches APIが使えません。FoundryのClaudeはCCUという単位で請求されるため、採用時のAzure Marketplaceの条件と換算方式を使って見積もります。Azure OpenAIの費用もAzureの料金条件で別途試算します。[3]
公式文書では、標準のモデル・機能別料金で米ドル換算し、交渉済み割引を適用した後、1 CCU＝0.01米ドルとしてCCUの数量へ換算すると説明されています。Hosted on AzureのUS Data Zoneには、1.1倍の価格条件も記載されています。税や実際の請求通貨は別に扱います。CCUで請求される場合も、換算前の料金区分と適用条件をそろえて比較します。[4]
見積もりには対象モデル・地域・提供経路・割引・契約日を付けます。通常価格へ戻った場合やキャッシュのヒット率が下がった場合に、費用がどれだけ変わるかも計算します。
再利用する入力とキャッシュの設計
GPT-5.6以降の直接APIには暗黙・明示のキャッシュ方式があり、明示方式では再利用する境界を指定できます。Claudeには5分・1時間の書込区分があります。各方式の対応を、GPT-5.5やFoundryの設計へ一律に転用しないことが重要です。[5][6]
| 入力の性質 | 設計上の工夫 | 見積もり上の注意 |
|---|---|---|
| 固定のsystem・ツール・資料 | 変化しにくい部分を前方へ配置 | 書込費と読込回数を数える |
| 追記される会話 | 既存部分の順序・内容を保つ | 更新や分岐でヒット率が落ちる |
| 長い間隔の再訪 | 対応するTTLと保存条件を選ぶ | 長いTTLの書込費を回収できるか |
| 毎回異なる入力 | キャッシュ効果を過大評価しない | 通常入力の費用を基準にする |
単純な同一プレフィックスの試算では、書込単価をW、通常入力をI、読込単価をR、初回書込後の再利用回数をnとすると、W + nR < (n + 1)Iを満たすとキャッシュが安くなります。実際には最小長、TTL、追加書込、経路ごとの対応も加わるため、ログで確認します。
不足する機能を補う開発費の回収
例として、Foundryを使うことで既存の監視・認証の運用を再利用できる一方、非対応の機能をアプリ側で補う必要があるとします。運用を統一して減る月間費用から、追加した処理の運用費を引き、毎月いくら削減できるかを求めます。その削減額で、追加の初期開発費を何か月で回収できるかを計算します。
月間の純削減額 = 運用統一で減る費用 - 補完で増える継続費用
回収月数 = 補完の初期開発費 / 月間の純削減額
純削減額がゼロ以下なら、費用削減だけで回収を説明できません。監査の簡素化、リリース速度、既存契約の利用などの価値を、別の根拠として評価します。人月単価や削減時間は、自社の数字を使います。
共通の合格条件による比較
「同じプロンプト・同じeffort」を送る比較に加え、各候補を最適化した状態で合格条件を満たせるか評価します。比較単位はモデルとAPI、提供経路、設定の組です。
| 評価項目 | 測ること |
|---|---|
| 回答品質 | 正答、引用の正確さ、必要な論点、誤った断定 |
| 業務達成 | 必須検索の実行、正しい引数、権限遵守、完了率 |
| 体験 | 最初の有用な表示までの時間、回答完了時間、95%のリクエストが収まる遅延（p95） |
| 費用 | 成功業務1件あたり、長い会話、ヒット率低下時の費用 |
| 信頼性 | 429、タイムアウト、切断、上限到達からの復旧 |
| 変更耐性 | 過去発言の編集、モデル切替、更新、会話再開 |
最初のトークンが早くても、有用な本文が出るまで長い場合があります。平均だけでなくp95も測ります。評価セットには通常質問だけでなく、根拠不足、権限のない検索、ツール失敗、長い会話、拒否、重複実行を含めます。
4段階の導入と次へ進む判定条件
- PoC。 所在地、契約、機能、容量で候補を絞り、評価セットと最小のアプリを作る。G1は自社業務の品質を満たすこと。
- パイロット。 限定ユーザーで品質・遅延・費用を測り、権限、ツール、保存・削除、障害処理を検証する。G2はコストと遅延が目標内に収まること。
- 本番。 段階的に流量を増やし、監視、切り戻し、退役対応を運用する。G3は必要な容量と障害復旧を含め、運用指標が安定すること。
- 拡張。 新モデル、ルーター、管理型エージェントを個別に評価する。評価セットへ実際の失敗例を追加し、既存構成より価値がある変更を採用する。
図と本文のG1〜G3は、次の段階へ進むための判定条件です。数値目標は、自社で許容する誤答率、待ち時間、1件あたり費用、繁忙時の必要容量として事前に決めます。容量予約を採用する場合も、平均利用量だけでなくピークと未使用時の費用を見ます。[7]
採用理由と更新・移行の記録
| 記録欄 | 書く内容 |
|---|---|
| 業務と成功条件 | 誰のどの仕事を、何をもって完了とするか |
| 採用構成 | モデル・バージョン、API、提供経路、ホスティング、デプロイ種別 |
| 必須条件の根拠 | 所在地、契約、機能、容量を満たす出典と実環境の確認日 |
| 比較結果 | 品質、p95遅延、完了率、成功1件あたり費用 |
| 採用しない候補 | 未達条件、または費用・運用上の差 |
| 補完の責任 | 自前にする機能、担当者、保守費、障害時の手順 |
| 更新と移行 | 次の評価日、退役期限、切り戻し先、進行中会話の扱い |
デプロイ名やバージョンを固定していても、退役と更新への対応は必要です。更新ポリシーと移行の責任者を採用時に決めます。[8]
性能評価では業務を達成できるか、APIでは必要な処理を実装できるか、提供経路では自社の条件で運用できるかを確認します。この3つの根拠をそろえると、特定モデルへの好みだけに頼らず、採用理由を説明できます。
前回： 第5回 ClaudeをMicrosoft Foundryで使う — 思考ブロックと追記専用の会話設計 ｜ 連載のまとめへ戻る
参考資料
参考資料の仕様確認日：2026年10月8日。公式文書の閲覧による調査であり、料金・性能・障害復旧の実測は未実施です。