AIを組み込むサービスのAPI費用を見積もる方法

AIを組み込むサービスのAPI費用は、一回の生成だけでなく、入力と出力の量、再実行、追加機能、需要が増えた場合を分けて見積もります。公式料金の単位と実際の処理量を対応させ、通常時と負荷が高い場合を試算してください。予算の通知だけに頼らず、サービス側でも受付量と再実行の上限を決めます。

最初に一件の処理を分解する

顧客から一件の依頼が来ても、APIを一回呼ぶとは限りません。入力資料を読み、分類し、文章を作り、確認用に再処理する構成なら、複数の呼出しがあります。会話形式では過去の文脈を再送する場合もあります。一件の料金を決める前に、どの工程で何を送るかを一覧にします。

料金単位はサービスや機能で違うため、入力、出力、保存、検索などを現在の公式案内で確認します。トークンを用いるサービスでは、文字数とトークン数が常に一定の比率になるとは扱いません。実際の資料を、入力可能な条件で試し、使用量の記録を取ります。

顧客の支払う料金とAPIの費用は別です。API費用に開発、監視、確認、問い合わせ対応などを加えなければ、提供商品の原価にはなりません。受託全体の考え方は生成以外を含める価格の下限へ渡せます。

見積表へ入れる六つの数字

少ない件数、標準の件数、多い件数を用意します。標準だけで料金を作ると、一部の顧客が長い入力を繰り返した際に原価が増える場合があります。単純な平均に加えて、最大の入力や再生成が多い例を確認します。

費用の単位と通貨も揃えます。外貨建ての料金を使う場合、社内の試算へ用いる換算条件を明記し、実際の請求と同じになる保証はしません。請求条件、税や支払手数料など必要な項目は取引に応じて確認します。

仮定の単価で、計算の形を確かめる

以下は実在商品の料金ではなく、計算方法を説明する仮定です。入力百万単位あたり二百円、出力百万単位あたり八百円と置きます。一件の合計入力を一万単位、合計出力を二千単位とすると、入力は二円、出力は一・六円で、合計三・六円です。

月千件なら三千六百円、同じ量で二割の追加処理があるなら四千三百二十円です。ただし再実行が常に同じ量とは限りません。長い入力の再送や、確認用の追加工程がある場合は別に計算します。仮の単価を実在モデルの相場として紹介しないでください。

この例では保存、検索、連携基盤、人の確認を含んでいません。一件のAPI費用が小さく見えても、サービスの利益が大きいと判断するには不十分です。どの項目を計算へ入れ、どの項目が未確認かを見積書とは別に管理します。

失敗時の再実行を無制限にしない

出力が使えない場合、同じ条件で繰り返せば必ず直るとは限りません。入力不足、対象外の依頼、接続の問題などを分類し、再実行する条件と人へ渡す条件を決めます。利用者が何度も押せる再生成にも、回数や使用量の管理が必要です。

一時的な接続の問題と、出力内容の問題を同じ扱いにしないようにします。再送してよいか、前の処理が完了していないかを確認します。特に外部送信や登録を含む工程では、再実行により処理が重なる可能性も考えます。詳細は停止後の再開と重複防止で扱います。

APIの使用制限は、費用の上限と同じではありません。単位時間あたりの呼出しなどの制約がある場合、月の費用が小さくても一時的な集中へ対応できない可能性があります。現在の公式仕様を確認し、顧客へ即時処理を約束できる条件を判断します。

見積もりを実処理で更新する

最初は公開可能な仮資料で試し、入力量、出力量、呼出し、再実行を記録します。実顧客の資料を使う場合は、入力条件を確認してから行います。長さだけでなく、形式や必要な確認が違う資料も試し、標準処理の偏りを減らします。

確認項目はAIサービスの契約と入力情報へ渡せます。公開情報での試作が成功しても、秘密情報や個人情報を同じ環境で扱えるとは限りません。利用条件に合う環境を選ぶことで費用が変わる場合もあります。

記録は案件番号や処理番号と対応させ、費用が増えた原因を追えるようにします。資料の内容そのものをログへ保存する必要があるかは別に考えます。顧客情報を含む記録を、原価管理のためという理由で無制限に残さないことも重要です。

受付の上限と停止の手順を作る

一日の件数、入力量、出力の長さ、再生成、同時処理に上限を置く案があります。上限の数字は商品の用途と顧客の需要から決めます。使うほどよい成果が出るとは限らないため、無制限の生成を販売上の魅力として約束する前に、費用と確認能力を試します。

上限へ近づいたときは、利用者への案内、待ち列、翌日以降の処理、人への確認などの対応を決めます。料金に影響するなら、追加利用の条件を先に説明します。費用が増えたことを後から一方的に請求する設計にはしません。

予算の通知は異常を知る材料ですが、それだけで処理が止まるとは限りません。採用したサービスの実際の機能を確認し、サービス側でも停止や制限の処理を設計します。誰が通知を受け、いつ確認し、何を止めるかまで担当を決めてください。

共通費と案件費を分ける

一つの契約や基盤を複数顧客で使う場合、実支出を案件へどう配分するか決めます。基本費、追加使用、顧客専用の環境を分ける考え方は共用ツール代の配分へ渡せます。配分額と請求する料金を同じものとして扱わないようにします。

費用と契約の記録は支出を確認できる記録を参考にできます。予定額、請求額、実際の利用量を対応させれば、単価の変更と使用量の増加を分けて確認しやすくなります。

顧客への見積もりへ反映する

入力へ毎回同じ説明を付ける設計では、共通部分の量も費用へ含めます。資料本文だけを測ると、実際に送る指示や会話の履歴が計算から抜ける場合があります。保存済みの内容を再利用する機能を選ぶなら、その機能の使用条件と保存に関わる支出を確認します。単に入力を短くするだけで、必要な情報が落ちて品質が変わらないかも点検してください。

出力の上限を設けるときは、顧客が必要とする納品物を完成できるか確認します。短い上限で費用を下げても、途中で文章が切れ、再処理が増えれば原価を減らせない場合があります。生成量と完成条件を一緒に試し、途中の出力を最終結果として使わない設計にします。

料金やモデルを変更する場合は、過去の使用量を新しい条件へ当てはめるだけでなく、同じ資料の処理量が変わらないかを試します。別の出力形式や確認工程が必要になれば、呼出し数も変わります。古い見積もりと新しい実績を混ぜず、条件ごとの版を残します。

利用範囲、含む処理、上限、追加利用、停止時の対応を示します。料金が一定のサービスなら、内部で費用が増える条件を把握し、提供範囲が料金に合うか判断します。従量制の提案なら、顧客が使用量を理解できる単位と確認方法を用意します。

納品物と別料金の説明は見積書の確認項目へ渡せます。見積もり時点では分からない費用があるなら、試作で確認する条件を示し、本格利用の前に料金を合意します。

API費用の見積もりに向く資料は、公式の料金と仕様、実処理の使用量、再実行の記録、需要別の試算です。安い一回の処理だけで採算を判断せず、顧客が使い続ける場合と負荷が増える場合を含めて検討してください。