第5回 導入を判断する：待ち時間・費用・運用条件
連載：Decision-1をRAGに組み込む：設計・検証・運用の実践・第5回 ｜ 連載のまとめ
回答品質が上がっても、利用者が長く待つ構成では、そのまま業務へ採用できません。Microsoft-Decision-1（以下、Decision-1）の今回の検証でも、判定API自体の応答に加え、呼び出し制限による待ち時間が導入判断を左右しました。
この記事では、2026年10月16日から20日に行った検索拡張生成（RAG）の比較から、時間、費用、運用条件を整理します。表の費用は当時の設定に基づく推定で、現在の料金表ではありません。請求に反映されたAzure使用額は別に扱います。[1]
1. 利用者の待ち時間と、APIの処理時間を分ける
主評価の生成モデルはgpt-6-lunaです。比較した構成A〜Eを再掲します。
| 構成 | 検索候補 | 生成前の処理 | 生成へ渡す根拠 |
|---|---|---|---|
| A：基準 | 5件 | 判定なし | 検索上位5件 |
| B：関連性フィルター | 10件 | Decision-1で1件ずつ関連性を判定 | 確率0.8以上を確率順に最大5件 |
| C：フィルター＋ゲート | 10件 | Bに加え、根拠全体の十分性を判定 | 最大5件。0件または不十分なら生成しない |
| D：リランク | 20件 | Decision-1で有用性を4段階評価して並べ替え | 評価上位5件 |
| E：汎用モデルのフィルター | 10件 | gpt-6-lunaで関連の有無を判定 | 関連ありを検索順に最大5件 |
次の表では、APIの呼び出し制限による順番待ちを除いた推定値と、待ちを含めた実測値を分けています。
| 構成 | 待ちを除く推定p50 | 待ちを含む実測p95 | 1問あたり推定費用 |
|---|---|---|---|
| A：基準 | 1.7秒 | 2.4秒 | 0.0002USD |
| B：関連性フィルター | 2.6秒 | 13.0秒 | 0.0002USD |
| C：フィルター＋ゲート | 2.9秒 | 14.3秒 | 0.0002USD |
| D：リランク | 2.7秒 | 24.0秒 | 0.0004USD |
| E：汎用モデルのフィルター | 3.5秒 | 14.3秒 | 0.0006USD |
p50は中央値、p95は95パーセンタイルです。「待ちを除く」値は、判定段の時間を並列API呼び出しの最大応答時間へ置き換えて計算した推定です。実際に利用者へその時間で返せた測定値ではありません。p50とp95の単純な差を待ち時間と解釈することもできません。
主評価で回答スコアが上がったDは、待ちを除く推定ではAより約1秒長い一方、実測p95では24秒でした。「1秒の追加で品質が上がる」という説明だけでは、今回の運用上の制約を伝えきれません。[1]
2. 1問で何回呼ぶかが処理量を決める
今回使ったDecision-1のデプロイでは、毎分60リクエストの枠を確認し、クライアントを毎分55リクエストに抑えました。これは検証時のデプロイとクォータの観測であり、全利用者に共通する恒久的な製品上限という意味ではありません。[2]
Dは候補20件を1件ずつ判定します。この枠をDだけで使う単純な計算なら、毎分55回÷1問20回＝毎分2.75問が判定段の処理量の目安です。再試行、他の処理との共有、生成や検索に要する時間は、この計算に含めていません。
同時実行数を増やしても、毎分の呼び出し枠そのものは増えません。利用者が集中すれば、短い推論処理でも順番待ちが長くなります。オンラインの会話では許容しにくい待ちでも、夜間にまとめて評価する処理なら受け入れられる場合があります。
対策の候補は、クォータ変更、判定対象の削減、複数候補をまとめて判定する方式です。まとめた入力で品質や速度が保たれるかは今回未検証なので、実装だけを変えて同じ結果になるとは見込まず、比較し直します。
3. 回答1件の費用と、検証全体の費用を分ける
表の1問あたり費用は、使用トークン数に当時の設定単価を掛けた推定値です。モデル呼び出しの比較に使う値であり、採点、作業用AI、手元PC、人のレビュー時間などを含む総費用ではありません。キャッシュ課金もこの推定には含まれていません。
表示は丸めているため、AとBが同じ0.0002USDでも、追加判定が無料という意味ではありません。AとDの表示値の差は約0.0002USDですが、見積もりには丸め前のトークン数と単価を使います。
追加評価では、gpt-5-nanoのDが回答スコア0.870、約0.0004USD／問でした。一方、gpt-6-lunaのAは0.906、約0.0002USD／問です。この条件では、生成モデルを替えて判定を追加する構成が、より低い費用で高品質になるとはいえません。[3]
運用費を考えるなら、モデル料金に検索・保存・監視の費用、再試行や人による修正にかかる費用、待ち時間の業務への影響を加えます。検証費を集計するときは、質問作成と採点にかかった費用も分けて記録します。採点モデルへ長い根拠を渡すため、回答を作る費用より、評価する費用が大きくなることがあります。
4. 請求への反映を待って照合する
リソースグループの2026年10月16日〜21日を対象とした費用記録では、請求に反映された額が1,664.8JPY、未反映分の見積もりが3.3JPYで、合計は約1,668JPYでした。日付はUTC、金額は記録取得時点の値です。最終請求書で再確認した総額とは区別します。[4]
同じ記録のデプロイ別表では、質問生成と採点に使ったjudgeの反映済み額は89.3JPYと1,407.0JPY、計約1,496.3JPYです。反映済み総額の約90%を占めます。途中の作業記録にある「judge約1,592円」とは一致しないため、この記事では同じ時点の費用表に基づく値を採用しました。
この約1,668JPYに、Claude Codeの利用料、人の作業時間、PCの費用は含まれません。検証全体をその金額だけで行えるという意味ではありません。
今回の観測では、使用直後のCost Managementへの反映が不完全で、時間を置くと増えました。費用の取得結果を時刻付きで残すことで、使用量の急変と反映の遅れを区別できました。予算通知だけで短時間の大量実行を止められるとは見込まず、実行側にも件数やトークン数の上限を設ける設計が考えられます。
5. 失敗の原因に合わせて採用する
| 自社のRAGで起きている問題 | 試す構成 | 採用前に見る指標 |
|---|---|---|
| 必要な根拠が検索上位にそろわない | 候補を広げて選ぶDのような構成 | 回答スコア、複数根拠の質問、待ち時間 |
| 不要な根拠に引きずられる | Bのようなフィルター | 忠実さ、根拠の取りこぼし、過剰拒否 |
| 根拠がなくても回答を作る | Cのような停止処理 | 回答不能時の断定、回答可能時の拒否 |
| 汎用モデルで判定している | 判定専用モデルとの比較 | 判定品質、並べ方の差、総費用 |
これは今回の観測から導く検証の出発点です。すでに生成モデルが正しい根拠を選び、回答を適切に控えているなら、フィルターやゲートの追加が改善に結び付かないことがあります。
品質の差が業務にとって意味を持つかも確認します。回答スコアの平均が上がっても、契約条件や数値の誤りが残れば、採用できない用途があります。許容する失敗を決めてから、平均値と失敗例を評価します。
6. 本番前に追加で確かめる
最初に補うべきものは、採点結果の人手確認です。質問のレビューとは別に、生成回答と根拠を人が読み、採点モデルが正しく判断したかを確かめます。
次に、検索候補数をそろえて、別の選び方や既存のリランカーと比べます。今回のAとDの差には、候補数の違いが含まれているためです。さらに、自社の文書・質問、実際の同時利用数、利用するリージョンとクォータで再測定します。
Decision-1を採用する理由は、呼び出し単価の安さだけでは決まりません。自社の失敗を減らし、待ち時間と総費用が許容範囲に入り、処理が止まったときにも対応できることを、まとめて採用の条件として判断します。
参考資料
資料の確認日：2026年10月23日。時間と1問あたり費用は検証資料の値、Azure使用額は費用記録の取得時点の値です。
- Decision-1 RAG評価検証・資料リリース（筆者、2026年10月22日版）。「04_PoC報告と考察」「05_検証手法」「07_作業レポート」を参照。
- 検証時のモデル設定（筆者、確認時のコミット）。容量と当時の単価を参照。
- 生成モデルの差し替え比較（筆者、確認時のコミット）。
- Azureの使用料：2026年10月16日〜21日（筆者、確認時のコミット）。反映済み額と未反映見積もりの区別、judgeの内訳を参照。