プロンプトと背景
これはプロダクトに関する判断力を問う質問です。開発者向けAPIは、不明瞭な429レスポンスによって正当な連携処理を失敗させることなく、共有リソースを保護しなければなりません。何を制限すべきか、どの識別子が制限を保持するか、ティア間でどう差別化するか、クライアントが早期に境界を把握する方法、そして価値ある処理をブロックせずに信頼性を向上させていることをどう証明するかを決定してください。
free、professional、enterpriseの各ティアが存在し、リクエストコストはリクエスト数、同時実行数、入力サイズ、ダウンストリームの計算量によって変動し、バーストアクセスが共有依存リソースを枯渇させてはならず、ポリシーのロールアウトおよびロールバックが可能であると仮定します。60 RPM、月間10,000回、80%到達時の警告などの例示値は実際のデータに置き換えるためのプレースホルダーであり、業界標準ではありません。
面接官が見ているポイント
面接官は、技術的制約に結びついたプロダクト戦略を評価しようとしています：
- レート、利用クォータ、同時実行数、コスト予算を異なる約束（プロミス）として定義しているか；
- プランの価格からのみではなく、開発者の達成すべき課題（Job to be done）から出発しているか；
- 組織、プロジェクト、APIキー、ユーザー、IPアドレスの単位で制限をかける際の公平性と不正利用（アビュース）のトレードオフを説明できるか；
- 予測可能なエラー、ヘッダー、ダッシュボード、アラート、および容量追加リクエストの手段を提供しているか；
- ガードレールとして、成功率、リトライ増幅、リソースコスト、リテンション、サポート負荷を測定しているか；
- カナリアリリース、例外処理、異議申し立て、ロールバック、およびポリシー変更の周知計画を策定しているか。
「無料プランは低く、エンタープライズは高く設定する」とだけ答えるのは不十分です。優れた回答では、各制限が何を保護し、開発者がどのような体験をし、副作用をどのように検証するかを明確に述べます。
確認すべき明確化の質問
ポリシーに影響を与える制約事項を確認します：
- どのリソースを保護するのか？ ゲートウェイのCPU、データベース接続、モデルのトークン数、サードパーティの請求額、あるいは特定テナントによる占有を防ぐ公平性か？それぞれ異なるディメンションが必要になる場合があります。
- ワークロードのパターンはどのようなものか？ 定常的なリクエスト、短時間のバースト、バッチジョブ、長時間持続する接続に対して、単一の「1分あたりの数値」を共通で適用することはできません。
- 境界はハードリミットかソフトバジェットか？ ハードリミットは安全性を保護します。ソフトバジェットはキューイング、グレースフルデグラデーション、追加課金などの柔軟性を持たせることができますが、明確なフィードバックが必要です。
- 課金とスロットリングは同じ単位で測定されているか？ トークン、APIコール数、同時接続数は別々のカウンターが必要になる場合があり、それらを混ぜた単一の指標は予測が困難です。
- 成功の定義は何か？ 依存関係の過負荷の削減、初回呼び出し成功率の向上、売上総利益率の改善、あるいは高価値な開発者のリテンション向上か？優先順位によってポリシーが変わります。
30秒で答える回答フレームワーク
まずは以下のように切り出します：
「私は4つの約束を分離して考えます。短時間のウィンドウによるレート制限で瞬間的なキャパシティを保護し、請求サイクルのクォータで予算を管理し、同時実行数の上限で占有される実行スロットを保護し、コスト予算で想定外の高額請求を防ぎます。組織またはプロジェクトを主識別子として使用し、リクエストとリソースのディメンションをエンドポイントのコストにマッピングします。ティア設計では、単にRPMを引き上げるのではなく、予算、バースト容量、同時実行数、サポート対応を追加します。ドキュメント、ダッシュボード、レスポンスヘッダーに残容量、リセット時刻、Retry-Afterを表示します。まずはシャドウ評価を実施し、少数のテナントにカナリア展開し、成功率、リトライ増幅、コスト、アップグレード、リテンションを監視した上で、展開拡大またはロールバックを行います。」
これにより、技術的またはビジネス的な追加の質問に入る前に、単位、開発者体験、測定ループが網羅されます。
ステップごとの詳細解説
境界をプロダクトの契約（コントラクト）にする。 レート制限は短い時間枠内に収まるリクエスト数を問うものです。利用クォータは請求期間内に収まるリソース量を問うものです。同時実行数の上限は、一度に占有できる実行スロットの数を問うものです。これらを分けて管理することで、顧客は429エラーがバーストによるものか、期間予算の枯渇か、同時実行数の上限到達かを判別できます。長時間のジョブには、最大実行時間やキューの予算も必要になる場合があります。
プラン名ではなくワークロードから単位を導き出す。 低負荷な読み取りにはリクエスト数を使用できます。高負荷な処理には、入力バイト数、出力トークン数、コンピュート秒数、またはデータベースのスキャンユニットが必要になる場合があります。まず重要な顧客ワークフローをマッピングし、エンドポイント固有の単位を選択します。すべてのエンドポイントのコストを一律に表すような単一のRPMを約束してはなりません。
識別子と公平性の選択。 有料APIの識別子としては、通常IPよりも組織やプロジェクトの方が適しています。NATによって複数の顧客がまとめられてしまうことがあり、キーのみの制限はキーをローテーションすることで回避される可能性があるためです。組織レベルの予算とプロジェクトレベルの同時実行数を組み合わせ、IPは不正利用防止のガードレールとして使用します。エンタープライズの例外措置は監査可能でなければならず、営業上の約束によってプラットフォームのポリシーが無効化されてはなりません。
ティアごとの差別化の設計。 freeティアは、小規模なエンドツーエンドの試行を完了できる必要があります。professionalティアでは、期間予算、バースト容量、同時実行数を追加します。enterpriseでは、予約容量、コンプライアンス管理、専用サポートを追加できます。すべてのティアで、制限を超えた場合の動作（拒否、キューイング、デグラデーション、従量課金）を明記する必要があります。予測可能性を向上させずに単に数値を引き上げると、通常はサポート負荷が増加します。
クライアントの挙動を予測可能にする。 ドキュメント、ダッシュボード、レスポンスヘッダーに残容量、リセット時刻、リクエストIDを表示します。429が発生した際、クライアントはRetry-Afterに従うことができます。上限付きのエクスポネンシャルバックオフを用いることで、リトライストームを防ぎます。リトライ不可能なビジネスエラーに対してリトライを促してはなりません。単に「Too Many Requests」と返すのではなく、固定のエラーコードと次にとるべきアクションを返します。
ローンチ指標とガードレール指標の定義。 主要指標には、初回呼び出し成功率、正当なリクエストの429発生率、期間予算の80%に達した顧客の割合、ユニットリクエストあたりのマージン、サポートへの問い合わせ件数、アップグレード率、30日リテンションなどが含まれます。ガードレール指標には、リトライ増幅、ダウンストリームのp99レイテンシ、不正利用イベント、テナント間のリソース競合が含まれます。平均値によって問題が隠れてしまわないよう、すべての指標をティア、エンドポイント、ワークロードパターンごとにセグメント化します。
カナリアリリース、例外処理、ロールバック。 まず、レスポンスを変更せずに社内プロジェクトや一部の顧客向けにシャドウモードで新しいポリシーを計算します。強制適用する前に、以前のポリシーと比較します。移行期間、予算アラート、一時的なキャパシティ申請プロセスを提供します。正当な呼び出しの成功率やリトライ増幅がしきい値を超えた場合は、データベースのレコードを手動で書き換えるのではなく、ポリシーのバージョンをロールバックします。
明確な仮定に基づいたテスト。 例えば、あるprofessionalプロジェクトが毎分40件の定常リクエストを送信し、バースト時に120件になるとします。60 RPMの制限は定常状態には対応できますが、バースト時には429が多発します。サンプルポリシーとしては、バースト容量120を許容する60 RPMを設定し、月間予算は別途カウントするような形が考えられます（これは例示です）。負荷テストでは、バースト、同時実行数、組織予算を共有する複数プロジェクト、時間の境界（クロックバウンダリ）、リトライを行うクライアント、アップグレード後のポリシー伝播をカバーする必要があります。
質の高い回答例
「私は保護対象リソースと開発者への約束を分離して設計します。レート制限は短時間の容量を保護し、期間クォータは予算を管理し、同時実行数の上限は占有実行スロットを保護します。高負荷なエンドポイントには入力サイズやコンピュート単位を追加します。NATによって正当な顧客が同一視されないよう、主に組織、副次的にプロジェクト単位で測定し、IPは不正利用防止のガードレールとしてのみ使用します。freeティアは小規模なエンドツーエンドの検証を完結でき、professionalティアは期間予算、バースト、同時実行数を追加し、enterpriseは予約容量、コンプライアンス制御、監査可能な一時的増枠を追加します。各ティアは、制限超過時の処理が拒否、キューイング、機能制限、従量課金のいずれであるかを明記します。
クライアントは、ドキュメント、ダッシュボード、ヘッダーを通じて残容量、リセット時刻、リクエストIDを確認できます。429レスポンスはRetry-Afterに従い、SDKは上限付きのエクスポネンシャルバックオフを使用して重複リクエストの増幅を防ぎます。新しいポリシーはシャドウ評価を行い、その後少数のプロジェクトにカナリア展開します。主要指標は初回呼び出し成功率、正当なコールの429率、リクエスト単価あたりのコスト、アップグレード率とし、ガードレール指標はリトライ増幅、ダウンストリームのp99、サポート問い合わせ、30日リテンションとします。正当なコールの失敗率がしきい値を超えた場合は、1社のために監査不能な例外を作るのではなく、ポリシーバージョンをロールバックして移行期間を延長します。」
重要なのは、プロダクトの単位、予測可能性、技術的挙動、そして実験に基づく意思決定の間の連携です。すべての数値は実際のベースラインに置き換えてください。例示されたクォータはデフォルト値ではありません。
よくある間違い
- 「freeティアは低く、enterpriseティアは高く」とだけ述べる。 保護対象のリソースや制限超過時の挙動が抜けています。すべての制限をリソース、顧客のユースケース、フィードバック経路に結びつけてください。
- RPMを総コストとして扱う。 ペイロードが大きいリクエストや長時間のジョブは、より多くのダウンストリームキャパシティを消費します。リソースや同時実行数のディメンションを追加してください。
- IPを唯一の顧客識別子として使用する。 NAT、プロキシ、キーのローテーションにより、公平性と監査性が損なわれます。プライマリキーとして組織またはプロジェクトを使用し、IPはガードレールとして扱ってください。
- クライアントに無計画なリトライをさせる。 即時リトライは輻輳を悪化させます。
Retry-Afterを遵守し、エクスポネンシャルバックオフを使用し、試行回数に上限を設けてください。 - 収益または429発生率のみを監視する。 収益の増加と成功率の低下が同時に起きる場合があり、また429率の低さは過剰なリソース予約を意味している場合があります。体験、コスト、信頼性を総合的に追跡してください。
- ポリシーを営業上の例外措置で置き換えてしまう。 ドキュメント化されていないバックドアは取り消しが難しく、不公平を生みます。期限付きで監査可能、かつ元に戻せるキャパシティプロセスを使用してください。
フォローアップの質問と回答
バースト時に月間クォータが十分に残っているにもかかわらず、顧客に429エラーが発生しています。どう対応しますか？
期間クォータと瞬間的なレートは異なる約束であることを説明します。エンドポイントのコストと顧客のワークフローを調査し、妥当性のあるバースト許容量を追加するか、一時的なバースト申請ルートを設けます。ヘッダー、ドキュメント、ダッシュボードでリセットと待機の仕様を明確化します。根拠なしに全顧客のRPMを引き上げてはなりません。
大口顧客からレート制限を完全に解除してほしいと要望がありました。同意しますか？
ワークロード、依存リソースのコスト、信頼性の目標についてヒアリングします。システム全体の安全ガードレールを維持しつつ、予約容量、専用キュー、または期限付きの増枠を提案します。承認内容、価格、有効期限、ロールバック条件を記録します。無制限の約束は、他の顧客やダウンストリームサービスにリスクを転嫁することになります。
429の発生率は低下したものの、リテンションも低下しています。ポリシーが失敗したかどうかをどう判断しますか？
エンドポイント、ティア、ワークロード、移行フェーズごとにデータを分析します。制限を緩和したことでコストやレイテンシの悪化が隠れていないか確認し、初回呼び出し成功率、サポート問い合わせ、予算アラート、解約インタビューを総合的に検証します。重要なワークフローのみに悪影響が出ている場合は、すべてのガードレールを撤廃する前に、単位、ドキュメント、またはバーストポリシーを修正します。
顧客が複数のプロジェクト間で予算を共有しています。ある1つのプロジェクトが組織全体の利用枠を使い果たしてしまうのをどう防ぎますか？
2つの階層を使用します。組織全体の予算に加え、プロジェクト単位の同時実行数または予約枠を設定します。高コストまたはリスクの高いエンドポイントには、プロジェクトごとの予約枠を必須とすることもできます。ダッシュボードに両方の残量を表示し、エラーがプロジェクトレベルか組織レベルかを識別できるようにすることで、管理者が予算や優先順位を調整できるようにします。