このレッスンでできるようになること
APIを動かせたら、次は失敗や利用量の増加を管理します。正常な一回の応答だけで本番へ進むと、入力が大きい日や接続障害のときに費用や待ち時間が増える可能性があります。このレッスンでは、費用の見積もり、利用上限、エラー分類、再試行の方針を整理します。目標は、失敗しても利用者へ状況を伝え、無制限に処理を繰り返さない設計を作ることです。
1．料金を入力と出力に分ける
モデルの料金は公式一覧で、対象モデル、単位、条件を確認します。テキストの入力と出力では単価が異なる場合があり、検索や画像などの追加処理は別の費用になることがあります。料金表の一つの数字だけで、すべての要求の費用を説明しないでください。
練習用の仮定として、入力100万トークン当たり2ドル、出力100万トークン当たり6ドルとします。入力が2,000、出力が500トークンなら、入力0.004ドルと出力0.003ドルで合計0.007ドルです。これは計算方法を示す仮定であり、すべてのモデルや長文条件に適用する料金の保証ではありません。
同じ処理を1,000回行えば、この仮定では7ドルです。ただし、再試行、推論や追加ツールの課金対象、入力の増加などを別に確認する必要があります。円に換算する場合は、為替や税の条件を含めて扱い、ドルの計算結果と混同しないようにします。
公式のトークナイザー画面で、文章がどのような単位に分かれるか確認できます。文字数とトークン数は同じではありません。
2．見積もりと実測を比べる
少量の代表的な入力で、応答の使用量情報や管理画面を確認します。入力の文字数とトークン数は同じではないので、日本語の文字数をそのまま課金単位に使わないでください。長い資料を送る仕事では、資料の大きさがどの程度変わるかも記録します。
記録するのは、要求の種類、モデル、入力と出力の量、実行時間、成功か失敗かです。本文や認証情報まで全部ログへ保存する必要はありません。個人情報が含まれる入力は、調査に必要な識別情報や集計値へ置き換えられないか検討します。
想定より使用量が多い場合は、同じ資料を何度も送っていないか、出力が必要以上に長くないか、失敗を繰り返していないかを調べます。料金だけを見てモデルを変更する前に、アプリの処理の重複を確認しましょう。
3．回数、時間、費用の上限を分ける
一回の要求の待ち時間、一人が短時間に送れる回数、一日の処理件数、月の予算は別の制御です。API側のRate Limitがあることを、自分の予算上限が保証されることと混同しないでください。アプリ側でも必要な制限と、制限に達したときの表示を設計します。
入力文字数やファイル数を事前に確認し、大きすぎる要求は分割や要約の選択肢を示します。利用者に何も伝えず切り捨てると、結果に必要な条件が消える可能性があります。上限の理由と、次にできる操作を説明できるようにします。
練習では、一回の要求だけを送る構成を保ちます。本番で並列処理を使う場合は、同時実行数を決め、待ち行列やキャンセルを考えます。利用者がボタンを連打したときにも、同じ仕事が無制限に始まらないようにします。
4．エラーを分類して対応する
認証に関するエラーは、キー、権限、接続先を確認します。入力形式のエラーは、必須項目や型を直します。これらを同じ内容のまま再送しても、通常は解決につながりません。エラーの説明を読み、どの設定や入力を修正すべきかを先に判断します。
429など頻度の制限に関する応答では、送信量を減らし、待ち時間を設ける方法を検討します。一時的な通信失敗でも、回数と待ち時間に上限を設けます。無限の再試行や、即時の連続送信を標準の復旧方法にしないでください。
タイムアウトは、相手側で処理が一切行われていない証拠ではありません。特に外部更新を伴う場合、再実行前に結果を確認する必要があります。文章生成でも、同じ要求を再送すれば追加利用が発生する可能性があるため、回数を記録します。
API Consoleの監査ログと絞り込み画面です。対象のキーや期間を限定すると、問題が起きた操作を探しやすくなります。
5．失敗を模擬して確認する
本番の制限に実際に達するまで大量に要求を送る必要はありません。通信部分を模擬応答へ置き換え、成功、認証失敗、頻度制限、タイムアウトを返して画面と処理を確認します。予定した回数で止まるか、利用者へ重複した通知を出さないかを点検します。
模擬テストで分かるのは、自分のアプリの分岐や表示です。実際のアカウント権限や外部サービスの動作を確認したことにはなりません。少量の実接続を行う場合も、別の検証として記録し、使ったモデルと日時を残します。
費用の監視は、請求が大きくなってから調べるだけでなく、通常の利用量と比べられる形にします。増加が新しい利用者によるものか、入力の大型化か、再試行の問題かが分かると、対策を絞れます。
実践課題と完了チェック
仮の単価で一回と一か月の費用を計算し、追加費用の項目を別に挙げてください。エラー分類表を作り、再試行の上限と利用者への案内を決めます。単位が合う、見積もりの前提が書かれている、無限再試行がない、秘密情報をログへ出さない、という四点が完了基準です。
