こんにちは。umagic3104です。
これまでクラウド、AI、BtoB事業開発、法人営業、パートナー戦略などの仕事に携わってきました。現在は、大規模言語モデルを提供する企業で、企業向けAPIの商業化を担当しています。
私は、モデルを開発するエンジニアではありません。
その代わり、日々見ているのは、
- 評価の高かったモデルが、なぜ契約されないのか
- PoCを通過したのに、なぜ本番導入で止まるのか
- 契約されたAPIが、なぜ実際の利用量につながらないのか
- モデルの性能以外に、企業は何を見ているのか
という、技術とビジネスの間にある問題です。
このQiitaでは、正解をきれいに説明するというよりも、私が実際の仕事の中で感じた違和感や、失敗から学んだことを書いていきたいと思っています。
最初の記事では、大規模言語モデルAPIが、なぜ「性能が高い」という理由だけでは売れないのかについて書きます。
本記事は、個人の経験に基づく見解です。所属組織の公式見解ではありません。また、事例は守秘義務に配慮し、複数の経験をもとに抽象化しています。
「モデルは悪くない。でも、切り替える理由がない」
ある企業にモデルAPIを提案したときのことです。
事前の評価結果は、決して悪いものではありませんでした。
いくつかのタスクでは既存モデルより良い回答が出ていましたし、技術担当者からも、一定の評価を得ていました。
しかし、商談は思ったようには進みませんでした。
顧客の反応を要約すると、こういうことでした。
モデルが悪いとは思わない。
ただ、今使っているモデルから切り替えるほどの理由が、まだ見えない。
この言葉は、大規模言語モデルAPIの商業化を考える上で、とても重要だと思っています。
モデルの性能が高いことと、顧客がそのモデルを採用することは、同じではありません。
顧客がモデルを切り替えるためには、評価テストで少し良い回答が出るだけでは不十分です。
切り替えには、開発作業が発生します。再評価も必要です。社内説明、セキュリティ確認、法務審査、予算承認も必要になります。
つまり、顧客から見ると、モデルを変更すること自体にコストがあります。
そのコストを上回る価値が見えなければ、性能が少し高いだけでは動きません。
私が現場で感じているのは、モデル性能は、商談に参加するための入場券ではあっても、購入の決定理由ではないということです。
顧客が欲しいのは「賢いモデル」ではなく、「業務で使えるモデル」
モデルを提供する側は、どうしてもベンチマークを説明したくなります。
例えば、
- 推論能力が高い
- コーディングに強い
- 長い文章を処理できる
- マルチモーダルに対応している
- 他社モデルよりスコアが高い
といった説明です。
もちろん、これらは重要です。
しかし、企業が実際に確認したいことは、もう少し具体的です。
自社の業務で、本当に使えるのか。
例えば、カスタマーサービスの会社であれば、一般的な質問に答えられるだけでは十分ではありません。
- 自社の商品名、社内用語、返品ルール、例外条件を理解し、指定された形式で、安定して回答する必要があります
- 契約書の確認で使うのであれば、「文章を要約できる」だけでは足りません
- 重要条項を落とさず、リスクのある表現を抽出し、決められたフォーマットで返す必要があります
- エージェントサービスで使うのであれば、会話が自然なだけでは不十分です
- 正しいタイミングでツールを呼び出し、正しいパラメーターを渡し、失敗した場合には適切にやり直す必要があります
- 公開ベンチマークで高いスコアを出すことと、顧客の特定業務を正しく完了させることは、別の問題です
そのため、私はモデルを評価するとき、「このモデルは強いですか」と聞くよりも、次のように確認した方がよいと思っています。
どの業務を、どの条件で、どの程度の成功率で完了できるのか
「平均応答時間が速い」だけでは、顧客は安心できない
モデルAPIの提案では、「平均応答時間」という数字がよく使われます。
平均1.8秒、平均2秒、といった数字です。
数字だけを見ると、十分に速く見えます。
しかし、実際のサービスで問題になるのは、平均的な速さだけではありません。
ほとんどのリクエストは速いのに、ときどき極端に遅くなる。
アクセスが集中すると、急に回答が始まらなくなる。
チャット画面が止まったように見える。
音声対話では、返事が遅いため、ユーザーが会話をやめてしまう。
現場では、この「ときどき遅い」が問題になります。
そこで確認するのが、P50やP95です。
- P50：50％のリクエストが、この時間以内に処理される
- P95：95％のリクエストが、この時間以内に処理される
例えば、次のような結果だったとします。
P50：1.2秒
P95：8秒
この場合、半数のリクエストは1.2秒以内に処理されています。
しかし、一部のユーザーは8秒近く待つ可能性があります。残りの5％は、さらに長く待つことになります。
つまり、普段は速くても、体験が安定しているとは限りません。
大規模言語モデルの場合は、さらに次の2つを分けて確認する必要があります。
- 最初のトークンが返るまでの時間
- 回答全体の生成が完了するまでの時間
チャットやコーディング支援では、回答全体が完成するまでの時間よりも、最初の文字が表示されるまでの時間が、ユーザー体験に強く影響します。
PoCで動くことと、本番で動くことは違う
PoCでは、モデルがきれいに動くことがあります。
テストデータは限定されています。リクエスト数も多くありません。問題が起きれば、エンジニアがその場で確認できます。
しかし、本番環境に入ると状況は変わります。
利用者が自由に入力するため、想定外の質問が増えます。
アクセスが同時に集中します。
長い文章が送られてきます。
同じ処理が何度も実行されます。
タイムアウト、再試行、レート制限、API障害も発生します。
その段階になると、モデルの回答品質だけではなく、次のような問題が重要になります。
- RPMやTPMの上限
- 同時実行数
- エラー率
- タイムアウト率
- APIの可用性
- 障害発生時の通知
- モデルのバージョン変更
- 古いモデルの提供終了ルール
- 利用量の監視と予算管理
RPMは、1分間に呼び出せるリクエスト数です。
TPMは、1分間に処理できるトークン数です。
例えば、PoCでは1人の担当者が数十回試すだけなので、問題が見えないことがあります。
しかし、本番で100人が同時に利用すると、レート制限に到達し、サービス全体が止まる可能性があります。
そのため、「PoCに通った」という言葉は、慎重に扱う必要があります。
PoCで確認できたのは、多くの場合、
限定された条件では、このモデルが一定の品質を出した
ということです。
本番環境で、安定して、継続的に、予算内で利用できることまで証明されたわけではありません。
一番安いモデルが、一番安いとは限らない
価格の話になると、最初に比較されるのはトークン単価です。
入力100万トークンでいくら、出力100万トークンでいくら、という比較です。
もちろん、トークン単価は重要です。
ただし、企業が実際に負担するコストは、API料金だけではありません。
例えば、安いモデルを選んだものの、指定した形式を守らないため、何度も再実行する必要がある。
回答の間違いが多いため、人が確認しなければならない。
品質を上げるために、プロンプトが長くなり、入力トークンが増える。
別のモデルに切り替えるためのルーティング基盤や評価システムが必要になる。
こうしたコストも含めて考える必要があります。
私は、実際のコストを次のように見た方がよいと思っています。
実質的な処理コスト
= API料金 + 再実行コスト + システム運用コスト + 人による確認コスト + 失敗によって生じる業務コスト
API単価が安くても、同じ処理を3回やり直すのであれば、本当に安いとは言えません。
反対に、単価が少し高くても、一度で正しい回答を返し、人の確認作業を減らせるのであれば、全体としては安くなる可能性があります。
企業が購入するのは、トークンそのものではありません。
ある業務を完了させる能力に対して、お金を払っています。
APIがつながらなければ、モデルの性能は存在しないのと同じ
モデルの評価が高くても、開発者がAPIをうまく接続できないことがあります。
- ドキュメントが不足している
- エラーコードの意味が分からない
- サンプルコードが古い
- 認証方法が複雑
- 構造化出力が安定しない
- 利用量や料金を確認する画面がない
- 営業担当者が説明している間は使えるものの、顧客の開発者が自力で実装しようとすると止まってしまう
こうしたことは、決して小さな問題ではありません。
私が現場で感じるのは、開発者が自力で接続できないAPIは、営業だけでは広がらないということです。
営業が毎回個別に説明しなければ使えない場合、顧客数を増やすことは難しくなります。
特にモデル性能の差が小さい場合、次のような使いやすさが採用を左右します。
- API仕様が分かりやすい
- ドキュメントが充実している
- サンプルコードがそのまま動く
- OpenAI互換APIに対応している
- JSONなどの構造化出力が安定している
- Tool Callingが使いやすい
- エラー原因を確認しやすい
- 利用量と料金を管理できる
モデル性能が商品力だとすれば、ドキュメント、SDK、管理画面、請求、ログ、サポートも、すべて商品の一部です。
技術評価を通過しても、契約で止まる
モデルの品質テストに通った後、セキュリティや法務の確認で商談が止まることもあります。
企業からは、次のような質問が出ます。
- 入力データはモデル学習に利用されるのか
- データは保存されるのか
- 何日間保存されるのか
- データはどの国や地域に置かれるのか
- 個人情報や機密情報を入力できるのか
- アクセス権限を管理できるのか
- 監査ログを取得できるのか
- 専有環境やオンプレミスに対応できるのか
- 障害時の責任範囲はどこまでか
モデルを提供する側からすると、これらは性能とは直接関係のない話に見えるかもしれません。
しかし、顧客からすると、導入できるかどうかを決める重要な条件です。
技術担当者が「このモデルを使いたい」と思っても、セキュリティ部門、法務部門、購買部門が承認しなければ契約にはなりません。
BtoBのモデルAPIでは、技術評価で勝つだけでは不十分です。
顧客企業の意思決定プロセスを最後まで通過して、初めて「売れた」と言えます。
企業が買っているのは、APIキーだけではない
大規模言語モデルは、一般的なソフトウェアよりも、出力の変化が大きい製品です。
モデルが更新された結果、以前とは回答が変わることがあります。
同じプロンプトでも、特定のケースだけ精度が下がることがあります。
利用量が急増すると、これまで問題のなかった制限に到達することがあります。
そのため、導入後には必ず問題が発生します。
- 回答品質が突然変わった
- 特定の入力だけ正しく処理できない
- プロンプトをどう修正すればよいか分からない
- レート制限に到達した
- 新しいモデルへ移行する必要がある
- 障害原因が顧客側かモデル側が判断できない
このとき重要になるのが、モデル提供会社の対応です。
- 誰に連絡すればよいのか
- どの程度の時間で回答が返ってくるのか
- 技術的な原因を説明できるのか
- 一時的な回避策を提示できるのか
- モデルの今後の方針を共有できるのか
企業が購入しているのは、APIキーだけではありません。
実際には、
- 安定した供給
- 問題発生時の対応
- バージョン変更への支援
- 将来のロードマップ
- 提供会社への信頼
まで含めて購入しています。
私がモデルAPIを見るときの7つの質問
モデルAPIを評価するとき、私は少なくとも次の7つを確認したいと考えています。
| 確認すること | 主な質問 |
|---|---|
| 業務適合性 | どの業務で、何をもって成功とするのか |
| 品質 | 実際の業務データで、どの程度の成功率が出るのか |
| 速度 | TTFT、P50、P95はどの程度か |
| 安定性 | 同時アクセス時の制限、エラー率、可用性はどうか |
| 実質コスト | 再実行や人の確認を含め、1件当たりいくらかかるのか |
| 導入条件 | API、セキュリティ、契約、請求を含めて導入できるか |
| 運用支援 | 問題発生時に、誰がどのように対応するのか |
重要なのは、モデルを触った印象だけで判断しないことです。
同じテストケースを使い、品質、速度、安定性、コストを記録する必要があります。
例えば、最低限、次のような情報を残します。
"case_id": "customer-service-001",
"model": "model-a",
"prompt_tokens": 1250,
"completion_tokens": 320,
"time_to_first_token_ms": 620,
"total_latency_ms": 1840,
"success": true,
"format_valid": true,
"quality_score": 4,
"review_comment": "回答は正確だが、社内用語の説明が不足"
モデルごとの違いを説明するには、「なんとなく良かった」ではなく、記録が必要です。
性能は必要条件だが、採用理由ではない
ここまで書いてきたことを、私は次のように整理しています。
モデルAPIの実用価値
= タスク成功率
× 安定性
× 導入しやすさ
× 継続運用のしやすさ
÷ 総コスト
これは厳密な数式ではありません。
ただ、モデルの性能が高いのに売れない理由や、PoCを通過したのに本番導入されない理由を考えるときには、役に立ちます。
モデル性能は、もちろん極めて重要です。
性能が低ければ、そもそも評価の対象に入りません。
しかし、性能が高いだけでは、顧客が既存モデルから切り替える理由にはなりません。
顧客が実際に判断しているのは、
このモデルに切り替えることで、どの業務が良くなり、どのコストが下がり、どのリスクが減るのか。
ということです。
大規模言語モデルAPIの売上は、ベンチマークの順位表から直接生まれるわけではありません。
顧客の業務の中で、
- 何を改善できるのか
- 何を減らせるのか
- 誰の負担を軽くできるのか
- どのリスクを引き受けられるのか
を示せたときに、初めて契約や継続利用につながります。
モデルの商業化は、モデルを説明する仕事ではありません。
モデルの能力を、顧客の業務、予算、契約、運用に変換する仕事です。
私は、そこに技術と経営の間をつなぐ面白さがあると思っています。
今後もこのQiitaでは、モデルAPIの販売や企業導入の現場で感じたことを、成功した話だけでなく、進まなかった案件や違和感も含めて書いていきます。
次回は、次のテーマを予定しています。
大規模言語モデルAPIの「安い」とは何か
トークン単価だけでは分からない本当のコスト
よろしくお願いします。