このガイドでは、プロトタイプを本番環境に移行するためのベストプラクティスを幅広く紹介します。経験豊富な機械学習エンジニアから、最近機械学習に取り組み始めた方まで、本番環境で OpenAI のプラットフォームを活用するために必要な手法を学べます。API へのアクセスを保護する方法から、大量のトラフィックに耐えられる堅牢なアーキテクチャの設計までを取り上げます。アプリケーションを円滑かつ効果的にデプロイするための計画にお役立てください。
本番移行のベストプラクティスについてさらに詳しく知りたい方は、Developer Day の講演をご覧ください。
組織の設定
OpenAI アカウントにログインすると、組織設定で組織名と組織 ID を確認できます。組織名はユーザーインターフェースに表示される名称です。組織 ID は組織を一意に識別する値で、API リクエストで使用できます。
複数の組織に所属しているユーザーは、ヘッダーを渡して API リクエストに使用する組織を指定できます。そのリクエストの使用量は、指定した組織の利用枠に計上されます。ヘッダーを指定しない場合は、デフォルトの組織に請求されます。デフォルトの組織はユーザー設定で変更できます。
チームページから組織に新しいメンバーを招待できます。メンバーには閲覧者またはオーナーのロールを割り当てられます。
閲覧者の権限
- API リクエストを送信できます。
- 組織の基本情報を閲覧できます。
- 特に記載がない限り、組織内のリソース（Assistants など）を作成、更新、削除できます。
オーナーの権限
- 閲覧者の権限をすべて持ちます。
- 請求情報を変更できます。
- 組織のメンバーを管理できます。
利用上限の管理
請求情報を入力すると、OpenAI が組織に認める利用上限を設定します。プラットフォームの使用量が増えて利用ティアが上がると、利用上限も自動的に引き上げられます。現在の利用上限は、アカウント設定の上限ページで確認できます。
利用額が指定した金額（ドル）を超えたときに通知を受け取るには、上限ページで支出アラートを設定します。月ごとの支出に上限を設け、それを超える利用を防ぐには、支出のハードリミットを設定します。計測された利用額がこの上限に達すると、対象の API トラフィックが停止します。本番環境で有効にする前に、支出上限のガイドを確認してください。
API キー
OpenAI API は認証に API キーを使用します。API キーのページで、リクエストに使用する API キーを取得してください。
アプリケーションの認証には、開発者個人のキーに依存せず、プロジェクトのサービスアカウントを使用してください。認証情報の選び方や、プロジェクトと API キーの管理を自動化する方法については、API キーとサービスアカウントをご覧ください。
API キーを使えば比較的簡単にアクセスを制御できますが、キーの保護には十分な注意が必要です。コードや公開リポジトリに API キーを含めず、安全な場所に保管してください。コードベースにキーを直接書き込まずに済むよう、環境変数またはシークレット管理サービスを通じてアプリケーションに渡してください。詳しくは、API キーを安全に扱うためのベストプラクティスをご覧ください。
プロジェクトの API キーを作成する際は、有効期限を設定し、キーを定期的に交換する手順を定めることを強く推奨します。期限が切れる前に新しいキーを作成し、そのキーを使うようにアプリケーションを更新してください。新しいキーで動作することを確認してから、古いキーを失効させます。
管理者はプラットフォーム設定で、組織またはプロジェクト単位で API キーの有効期間に上限を設けることができます。新しいキーには設定した期間内の有効期限が必須となり、無期限に使えるキーの発行を防げます。プロジェクトの上限は組織の上限を超えることはできません。
プラットフォーム設定の API キーのガバナンスセクションでは、組織およびプロジェクトの管理者が、作成できる API キーの種類を制限できます。サービスアカウントのキーのみを許可する、ユーザーが所有するプロジェクトキーのみを許可する、またはすべての API キーの新規作成を無効にする、という選択肢があります。組織レベルの制限が常に優先されます。プロジェクト設定で制限を追加することはできますが、組織レベルの制限を緩和することはできません。これらの設定はキーの新規作成にのみ適用され、既存の API キーには影響しません。
トラッキングを有効にすると、使用量ページで API キーの使用量を確認できます。2023 年 12 月 20 日より前に生成した API キーでは、デフォルトでトラッキングが無効になっています。API キー管理ダッシュボードで有効にすると、その時点から使用量を追跡できます。2023 年 12 月 20 日より後に生成した API キーでは、すべてトラッキングが有効になっています。過去に追跡されなかった使用量は、ダッシュボードに Untracked と表示されます。
ステージング用プロジェクト
規模が大きくなったら、ステージング環境と本番環境でプロジェクトを分けることを検討してください。ダッシュボードでそれぞれのプロジェクトを作成すると、開発やテストを本番環境から切り離し、稼働中のアプリケーションに誤って影響を与えるのを防げます。本番プロジェクトにアクセスできるユーザーを制限したり、プロジェクトごとにレート制限や支出上限を設定したりすることもできます。
トラフィックの増加に対応するアーキテクチャ
OpenAI API を利用する本番用のアプリケーションやサービスを設計する際は、トラフィックの増加にどう対応するかを検討することが重要です。どのクラウドサービスプロバイダーを選ぶ場合でも、次の点を考慮してください。
- 水平スケーリング：複数の送信元からアプリケーションに届くリクエストに対応するために、水平スケーリングを検討できます。たとえば、サーバーやコンテナを追加して負荷を分散します。この方法を選ぶ場合は、複数のノードで動作するアーキテクチャを設計し、ノード間で負荷を分散する仕組みを用意してください。
- 垂直スケーリング：単一のノードで使えるリソースを増やす方法もあります。この場合は、負荷の増加に対応できるようにサーバーの性能を引き上げます。追加したリソースを活用できるようにアプリケーションを設計してください。
- キャッシュ：頻繁にアクセスするデータを保存しておくと、API を繰り返し呼び出さずに済み、応答時間を短縮できます。可能な限りキャッシュしたデータを使い、新しい情報が追加されたらキャッシュを無効化するようにアプリケーションを設計してください。データの保存先には、アプリケーションの特性に応じてデータベース、ファイルシステム、インメモリキャッシュなどを利用できます。
- 負荷分散：利用可能なサーバーにリクエストを均等に振り分ける方法も検討してください。たとえば、サーバーの手前にロードバランサーを配置する方法や、DNS ラウンドロビンを利用する方法があります。負荷を分散すると、パフォーマンスが向上し、ボトルネックを減らせます。
リクエストボディの圧縮
アップロードするデータ量を減らすには、JSON リクエストボディを zstd で圧縮してから POST /v1/responses を呼び出します。Content-Encoding: zstd を設定し、Content-Type: application/json はそのまま使用します。
zstd -3 -c request.json > request.json.zst
curl https://api.openai.com/v1/responses \
-H "Authorization: Bearer $OPENAI_API_KEY" \
-H "Content-Type: application/json" \
-H "Content-Encoding: zstd" \
--data-binary @request.json.zstAPI はリクエストを処理する前にボディを展開します。圧縮によってネットワーク経由で送信するバイト数は減りますが、トークン使用量やモデルのコンテキスト上限は変わりません。
圧縮したボディと展開後のボディは、どちらも 128 MiB 以下である必要があります。また、展開後のサイズは圧縮時のサイズの 100 倍以下でなければなりません。いずれかの上限を超えた場合、API は HTTP 413 を返します。HTTP 400 は、zstd データが無効または不完全な場合に返されます。その他のリクエスト制限も引き続き適用されます。
WebSocket メッセージの圧縮
Responses API の WebSocket モードは、圧縮拡張 permessage-deflate を wss://api.openai.com/v1/responses でサポートしています。この WebSocket 拡張は DEFLATE を使ってメッセージサイズを小さくします。接続する前に、WebSocket クライアントの圧縮設定で有効にしてください。
レート制限の管理
OpenAI API を使用する際は、レート制限を把握し、それを考慮して利用計画を立てることが重要です。
レイテンシの短縮
レイテンシ最適化の最新ガイドをご覧ください。
レイテンシとは、リクエストを処理してレスポンスを返すまでにかかる時間です。ここでは、OpenAI のテキスト生成モデルのレイテンシに影響する要因と、レイテンシを短縮する方法を説明します。
補完リクエストのレイテンシを左右する主な要因は、使用するモデルと生成するトークン数の 2 つです。補完リクエストは次の流れで処理されます。
通常、レイテンシの大半はトークンの生成にかかる時間です。
考え方：プロンプトのトークンが補完リクエストのレイテンシに与える影響はわずかです。一方、補完のトークンは 1 つずつ生成されるため、生成にははるかに長い時間がかかります。出力が長いほど、各トークンの生成時間が積み重なり、レイテンシが大きくなります。
レイテンシに影響する主な要因と対策
ここからは、レイテンシに影響する要因を、おおむね影響が大きい順に見ていきます。
モデル
OpenAI API では、複雑さや汎用性の異なる複数のモデルを利用できます。gpt-6-astra などの最も高性能なモデルは、より複雑で多様な補完を生成できますが、クエリの処理に時間がかかります。
gpt-5.6-terra や gpt-5.6-luna などのモデルなら、より高速かつ低コストでレスポンスを生成できます。複雑なタスクにも余裕を持って対応したい場合は、gpt-6-astra を標準のモデルとして選ぶとよいでしょう。用途に応じて、速度、コスト、品質のバランスが最もよいモデルを選んでください。
補完のトークン数
多くのトークンを生成する補完をリクエストすると、レイテンシが大きくなることがあります。
- 最大トークン数を減らす：実際に生成されるトークン数が同程度のリクエストでは、
max_tokensの値が小さい方がレイテンシも小さくなります。 - 停止シーケンスを指定する：不要なトークンの生成を防ぐには、停止シーケンスを追加します。たとえば、項目数を指定してリストを生成できます。
11.を停止シーケンスに指定すると、項目が 10 個だけのリストを生成できます。11.に達した時点で補完が停止するためです。使い方について詳しくは、停止シーケンスに関するヘルプ記事をご覧ください。 - 生成する補完の数を減らす：可能であれば、
nとbest_ofの値を小さくしてください。nはプロンプトごとに生成して返す補完の数です。best_ofは複数の候補を生成し、トークンあたりの対数確率が最も高い結果を選ぶために使います。
n と best_of がどちらもデフォルト値の 1 の場合、生成されるトークン数は最大で max_tokens です。
n（返す補完の数）または best_of（候補として生成する補完の数）を > 1 に設定すると、リクエストごとに複数の出力が生成されます。この場合、生成されるトークン数の上限は [ max_tokens * max (n, best_of) ] と考えることができます。
ストリーミング
リクエストに stream: true を設定すると、モデルはすべてのトークンの生成が終わるのを待たずに、生成できたトークンから順に返し始めます。すべてのトークンを受け取るまでの時間は変わりませんが、最初のトークンを受け取るまでの時間は短くなります。生成途中の内容を表示したい場合や、途中で生成を停止する場合に役立ちます。ユーザー体験の改善につながるため、ストリーミングを試してみてください。
バッチ処理
用途によっては、バッチ処理が有効な場合があります。同じエンドポイントに複数のリクエストを送信している場合は、プロンプトをまとめて 1 回のリクエストで送信できます。これにより、必要なリクエスト数を減らせます。プロンプトパラメータには、異なるプロンプトを最大 20 個指定できます。実際に試して効果を確かめてください。生成されるトークン数が増え、かえって応答が遅くなる場合もあります。
コスト管理
コストを把握するには、アカウントに通知しきい値を設定します。使用量が設定値を超えると、メールでアラートが届きます。使用量ダッシュボードでは、現在および過去の請求期間のトークン使用量を確認できます。
テキスト生成
プロトタイプを本番環境に移行する際の課題の 1 つは、アプリケーションの運用コストを見積もり、予算を立てることです。OpenAI は従量課金制を採用しており、料金は 1,000 トークン（約 750 語）単位で示されています。コストを見積もるには、トークン使用量の予測が必要です。トラフィック量、ユーザーがアプリケーションを利用する頻度、処理するデータ量などを考慮してください。
コスト削減を検討する際は、コストをトークン数とトークン単価に分けて考えると効果的です。 この考え方に沿って、2 つの方法でコストを削減できます。1 つ目は、一部のタスクを小規模なモデルに切り替え、トークン単価を下げる方法です。2 つ目は、必要なトークン数を減らす方法です。たとえば、プロンプトを短くする、モデルをファインチューニングする、ユーザーからよく寄せられるクエリをキャッシュして繰り返し処理しないようにする、といった方法があります。
対話型のトークナイザーツールでテキストを試すと、コストの見積もりに役立ちます。API と Playground では、レスポンスにもトークン数が含まれます。最も高性能なモデルで期待どおりに動作することを確認したら、ほかのモデルでもレイテンシとコストを抑えながら同じ結果を得られるか試してみてください。詳しくは、トークン使用量に関するヘルプ記事をご覧ください。
MLOps 戦略
プロトタイプを本番環境に移行する際は、MLOps 戦略の策定を検討してください。MLOps（機械学習の運用）とは、機械学習モデルのライフサイクル全体を管理するプロセスです。OpenAI API を使ってファインチューニングするモデルも対象に含まれます。MLOps 戦略を策定する際は、次の点を検討してください。
- データとモデルの管理：モデルの学習やファインチューニングに使うデータを管理し、バージョンと変更履歴を追跡します。
- モデルの監視：モデルの性能を継続的に監視し、問題の兆候や性能の低下を検知します。
- モデルの再学習：データや要件の変化にモデルが対応できるよう、必要に応じて再学習やファインチューニングを行います。
- モデルのデプロイ：モデルと関連する成果物を本番環境にデプロイする手順を自動化します。
アプリケーションの設計時にこうした点を検討しておくと、長期にわたって用途に適したモデルを維持し、良好な性能を保ちやすくなります。
セキュリティとコンプライアンス
プロトタイプを本番環境に移行する際は、アプリケーションに適用されるセキュリティとコンプライアンスの要件を確認し、対応する必要があります。そのためには、取り扱うデータを確認し、OpenAI API がそのデータをどのように処理するかを把握したうえで、遵守すべき規制を特定します。セキュリティへの取り組みと信頼性とコンプライアンスに関するポータルでは、OpenAI の最新情報を網羅した資料を公開しています。プライバシーポリシーと利用規約もあわせてご覧ください。
一般に検討が必要な項目には、データの保存、転送、保持期間があります。また、可能な範囲で暗号化や匿名化を行うなど、データのプライバシーを保護する対策が必要になる場合もあります。さらに、入力のサニタイズや適切なエラー処理など、セキュアコーディングのベストプラクティスに従ってください。
安全性に関するベストプラクティス
OpenAI API でアプリケーションを開発する際は、安全かつ効果的に運用できるよう、安全性に関するベストプラクティスを参考にしてください。製品を幅広くテストすること、潜在的な問題に先回りして対処すること、不正利用の余地を減らすことが重要です。
ビジネス上の検討事項
AI プロジェクトをプロトタイプから本番環境に移行する際は、AI を活用して優れた製品をどう作るか、そしてその製品を自社の中核事業にどう結び付けるかを考えることが重要です。OpenAI にすべての答えがあるわけではありませんが、検討の出発点として、Developer Day の講演をご覧ください。OpenAI のお客様とともに、このテーマを掘り下げています。