企業の GPT 調達：供給経路を選び、アカウントと導入を整える

要件と既存システム

従業員20人のシンガポールのソフトウェア企業が、二つの業務フローを導入する想定です。一つはサポート担当者が承認済みの製品資料を基に回答案を作成すること、もう一つはエンジニアが課題の履歴を要約することです。同社は既に CRM、社内 Web アプリケーション、Entra の ID 基盤を利用しています。入力には利用が認められた文書の抜粋と機密情報を除去したチケットを使い、出力は出典付きの編集可能な下書きとします。顧客に回答する前に担当者が内容を確認します。モデルが示す出典も、元の文書と照合する必要があります。

調達要件では、従業員がホスト型ワークスペースで利用する場合と、アプリケーションに API を組み込む場合を分けます。ChatGPT の利用席を購入しても、API 利用分の支払いには充当されません。両製品の請求は別です。目指す成果物は、利用経路を明記した資料と、受け入れ基準を満たした試験導入です。共用ログインの提供や、すべての GPT モデルが含まれるという無条件の約束ではありません。

想定する所在地と予算上の制約

この例では、契約主体と従業員20人全員がシンガポールに所在すると仮定します。想定する API 利用者は全員、中国本土以外に所在し、それぞれの実際の利用国が提供元の対応国に含まれるかを国ごとに確認する必要があります。

アカウントの利用資格と、処理場所やデータレジデンシーは別の確認事項です。アカウントと請求先の国、推論処理の場所、保存範囲、データに関する契約条件も、それぞれ確認します。OpenAI はシンガポールを API の対応国に掲載していますが、それだけではプロジェクトやモデルの利用権限、シンガポールでの推論処理は確定しません。現時点の GPT-6.1 Sol のモデルカードには、米国と EU のデータレジデンシーが掲載されています。Azure では選択したデプロイの種類を確認し、Global の場合は複数のデータセンターに処理が振り分けられる可能性を検討します。Bedrock では呼び出し元リージョンと推論プロファイルの送信先を確認し、以下の GPT の例でシンガポールの Runtime エンドポイントを利用できるとは仮定しません。

モデル利用料、必要なワークスペース利用席、アプリケーションのホスティング、ログ管理、サポートを合わせ、社内計画上の月額上限を US$2,000 と仮定します。これは架空の要件であり、見積もりでも、この金額ですべての処理量を賄えるという約束でもありません。発注前に、税、通貨、請求主体、超過分の取り扱いについて経理部門の承認を得ます。許可するデータの種類と保持ルールが承認されるまで、機密性の高いチケットは試験導入の対象から除外します。

認証情報より先に提供経路を選ぶ

公開されている経路	検討する理由	調達時の確認事項
OpenAI API を直接利用	API の組織とプロジェクトを直接管理できる	対応国、支払い設定、プロジェクト権限、正確なモデルと利用ティア
Microsoft Foundry の Azure OpenAI	既存の Entra と Azure の管理体制を活用し、所有者を整理しやすい場合がある	有料サブスクリプション、リソース、モデル・バージョン・デプロイの種類、リージョン、クォータ
Amazon Bedrock	既存の AWS の請求と IAM がアプリケーションに適している場合がある	AWS のモデル利用権限、対応エンドポイント・API、呼び出し元リージョン、推論プロファイル、クォータ

この想定企業では既に Entra を利用しているため、Azure を最初の候補とします。ただし、希望するモデル、所在地の条件、機能、商取引条件に合致した場合にのみ選定します。OpenAI の直接利用と Bedrock は、それぞれ別の選択肢として評価します。ある経路に希望モデルがない場合も、購入者の承認なしに似た名前のモデルへ置き換えません。

統合 API は、技術面でも契約面でも別の取り決めです。上流の提供元、対応モデル一覧、モデルの対応付け、手数料、ログ記録、レート制限、障害時の処理を書面で明らかにする必要があります。リクエストの構文が OpenAI 互換でも、対応範囲や機能が同じとは限りません。モデル提供元が一般公開していることは、Corebyte の供給権限、提供可能枠、合意済みの価格、SLA を裏付けるものではありません。

アカウント、デプロイ、モデルを明確に対応付ける

購入者がアカウントを所有し、請求契約の当事者となります。管理者は、法人名、請求アカウント、プロジェクトまたはリソース、実行時の ID、エンドポイント、正確なモデルとバージョン、デプロイ名または推論プロファイル、クォータ、許可する処理範囲を記録します。実装チームには必要な範囲に限定したアクセス権を付与し、認証情報は承認済みのサーバー側シークレットストアで管理します。

識別子は提供経路によって異なります。OpenAI を直接利用する場合は、選択した API プロジェクトで公開モデル ID を使用します。Azure のリクエストの model には、カタログ名を推測して指定するのではなく、プレースホルダー YOUR-GPT-DEPLOYMENT のように実際のデプロイ名を指定します。選択した認証方式も確認します。Entra ID で Azure OpenAI を認証する場合は、Cognitive Services OpenAI User などの適用可能な推論用ロール、または同等の権限を確認します。API Key は別の認証方式です。Bedrock では、AWS 認証情報または Bedrock API キーは AWS アカウントに属し、OpenAI API アカウントのものではありません。

確認日時点の例として、公式文書では gpt-6.1-sol が直接利用できるモデルとして、また Azure のカタログにも掲載されています。Bedrock のモデルカードでは、openai.gpt-6.1-sol が us-east-1 の Mantle に掲載されています。Runtime では、対象となる us.openai.gpt-6.1-sol または global.openai.gpt-6.1-sol の推論プロファイルを使用し、ルーティングが異なります。これらは必要な確認事項を示す例であり、標準的な購入推奨ではありません。プロプライエタリな GPT モデルと gpt-oss は別の製品です。購入する正確なモデル、API 機能、許可されるリージョンを、選択した経路で確認する必要があります。

実装と引き継ぎの手順

ユースケース、データの区分、選択した提供経路、希望モデル、所在地に関する条件、予算責任者、受け入れ基準を記載した要件書を承認します。
購入者側の管理者が請求設定と、最小権限に基づく実行時アクセスを整備します。リソースの所有者と、クォータやモデル利用権限の申請を担当する当事者を記録します。
確認済みのエンドポイントと識別子に合わせて、サーバー側のアダプターを設定します。開発用と本番用の利用を分け、文書の検索前にアクセス権を適用し、ログの機密情報を除去します。
正常、根拠不足、アクセス拒否、タイムアウト、レート制限を含む合意済みのケースで、承認を受けた試験導入を実施します。モデルとバージョン、機密情報を除去したリクエスト ID、利用量、人による修正内容を記録します。
設定記録、請求の配賦方法、運用手順書、エスカレーション先、新規リクエストを停止する方法を引き継ぎます。モデル、リージョン、提供元を変更する場合は、承認と回帰確認が必要です。

費用を配賦し、支出を管理する

ワークスペースの利用席と API の従量利用を分けます。アプリケーションからのリクエストは、プロジェクト、チーム、コストセンターのいずれかに配賦し、請求書との照合に必要な利用量と通貨の情報を保持します。キャッシュされていない入力、キャッシュの読み書き、出力、ツール、ストレージは、実際の提供元の料金体系で試算します。クラウド費用と連携費用は別に含めます。再試行や人による修正が増えるなら、トークン単価が低くても、受け入れ可能な回答一件当たりの費用が下がるとは限りません。

OpenAI を直接利用する場合、現在の文書では支出アラートと、任意で設定する組織・プロジェクトの強制的な支出上限が案内されています。アラートだけでは通信は継続します。強制的な上限を適用すると、支出上限による 429 エラーが返される場合があります。制限の反映は即時ではないため、少額の超過が起こる可能性があります。選択したクラウドや統合 API でも同じように動くと考えず、実際の制御を確認します。クォータ、残高、強制的な上限でリクエストが止まった場合に、担当者が業務を続ける方法を計画します。モデル変更を請求上の問題の解決策として扱ってはいけません。

受け入れ、リスク、納品範囲

受け入れには、承認済みのモデルと提供経路、正しいプロジェクトアクセス、期待する出力形式、文書単位のアクセス権テスト、途中で途切れたストリームの処理、経理部門が照合できる請求書と利用量のサンプルが必要です。ツールが非対応である場合、モデルが回答を拒否する場合、根拠がない場合は、それぞれ別の結果として扱います。試験導入の前に品質目標とテストセットの管理者を定めます。

以下の公開情報は、これらの提供経路が存在することを示しています。購入者のアカウント利用資格、リージョンの供給余力、交渉済みの価格、Corebyte の再販権限、統合 API の対応範囲を確認するものではありません。これらは明示的な調達確認事項として残します。

公式情報と確認日

確認日：2026-10-17。購入前に、提供状況、契約条件、アカウント権限を再確認する必要があります。