OpenAIは2026年9月8日の発表で、ChatGPTを含む自社製品群の週間利用者数が10億人を超え、2.5万社ではなく2.5百万（250万）の企業が利用していると公表しました。これはChatGPT単体ではなく製品群全体の数字で、法人向けと個人向けの内訳は公開されていません。
この規模の話は、営業やマーケティングの話題として消費されがちです。ですがSRE（サイト信頼性エンジニアリング。システムの可用性と運用を工学的に設計する職種・手法）やインフラ担当者にとっては、もっと実務的な問いに変わります。社内でAIアシスタントを使う基盤を、誰がどう設計し、誰が可用性とコストの責任を持つのかという話です。
利用者の多くがすでにChatGPTの画面操作に慣れているという事実は、導入のハードルを下げます。一方で、それを個人のブラウザ利用のまま放置するか、社内システムに組み込んで運用するかは別の意思決定です。この記事では、その分岐点で何を基準に選べばよいかを整理します。
どんな場面でこの判断が必要になるか
典型的には、次のような状況で選定が発生します。
- 現場の複数チームがすでに個人契約のChatGPTを業務に使っており、情報統制を効かせたい
- 顧客データや社内ドキュメントを検索・要約する社内向けアシスタントを作りたい
- コードレビューや障害対応のRunbook（障害発生時の手順書）作成にAIを組み込みたい
- 開発した仕組みの可用性・コスト・監査ログを誰が管理するかを決めたい
こうした場面で選ぶ相手は、大きく分けて「ChatGPT Enterprise等のSaaS版」「OpenAI APIを自社基盤に組み込む方式」「他社LLM APIとのマルチベンダー構成」の3つです。
判断軸
軸1: SLO設計のしやすさ
SLO（Service Level Objective。サービスが満たすべき品質目標の数値基準）を自分たちで決められるかどうかは大きな分かれ目です。
SaaS版のChatGPT Enterpriseはベンダー側の可用性に依存し、自社でSLOを細かく設定する余地は限られます。API直結方式なら、レイテンシやエラー率に対して自社のSLOを定義し、それに基づいてアラート閾値を設計できます。たとえば「p95レイテンシ3秒以内」といった目標を自社のオブザーバビリティ基盤で監視する構成が可能です。
軸2: IaCでの再現性
TerraformやPulumiのようなIaC（Infrastructure as Code。インフラ構成をコードで宣言的に管理する手法）ツールで環境を再現できるかも重要です。
OpenAI APIやAzure OpenAI Serviceは、TerraformのAzureプロバイダやAWS Bedrock経由での構成管理に対応しており、APIキーの発行やモデルデプロイをコード化できます。一方、ChatGPT EnterpriseのようなSaaS契約は管理コンソールでの手動設定が中心で、IaC管理の対象になりにくい部分が残ります。
軸3: オブザーバビリティの統合度
既存のDatadogやGrafana、OpenTelemetryのトレーシング基盤に、AI呼び出しのログとメトリクスを統合できるかを確認します。
API経由であれば、リクエスト単位でトークン数・レイテンシ・エラーコードを自社のログ基盤に流し込み、既存のダッシュボードに載せられます。SaaS版は利用状況レポートが管理画面に閉じており、自社のオブザーバビリティ基盤との統合は限定的です。
軸4: コスト構造と障害対応の仕組み化
SaaS版は座席数（シート）課金が中心で、利用量が読みにくい初期段階でも予算計画が立てやすい傾向があります。API方式はトークン従量課金のため、利用が急増するとコストが跳ね上がるリスクがあります。
障害対応の面では、API方式なら自社のインシデント対応フロー（PagerDutyなどでのオンコール体制）にAI呼び出しの失敗を組み込めます。SaaS版は障害時にベンダーのステータスページを待つしかなく、自社側での代替手段（フォールバック先のモデル切り替えなど）を事前に用意しにくい構成です。
選択肢の比較
| 観点 | SaaS版(ChatGPT Enterprise等) | API直結(自社基盤組み込み) |
|---|---|---|
| SLO設計 | ベンダー依存、自社定義は困難 | 自社でレイテンシ・エラー率目標を設計可能 |
| IaC管理 | 管理コンソール中心、コード化しにくい | Terraform等でAPIキー・構成を宣言的に管理可能 |
| オブザーバビリティ | ベンダー提供のレポートに限定 | 既存のログ・メトリクス基盤に統合可能 |
| コスト予測 | 座席課金で予算化しやすい | 従量課金で利用急増時に変動大 |
ケース別の推奨
小規模チームで、まず情報漏えい対策と利用ルール整備を急ぎたいなら、SaaS版のChatGPT Enterpriseを選ぶのが妥当です。管理コンソールでのアクセス制御とログ保持機能だけでも、個人契約の乱立よりリスクは大きく下がります。
顧客データを扱う検索・要約システムを、既存のマイクロサービス構成に組み込みたいなら、API直結方式を選びます。すでにKubernetesやコンテナ基盤でサービスを運用しているなら、AI呼び出し部分も同じデプロイパイプラインとオブザーバビリティ基盤に載せられるほうが運用の一貫性が保てます。
障害時の切り替え（特定モデルが不調のとき別モデルに自動フォールバックする構成）まで作り込みたいなら、API方式を選び、Azure OpenAI ServiceとOpenAI API本体など複数の窓口を用意する構成を検討します。マルチベンダー構成にする場合は、Anthropic ClaudeやGoogle Geminiなど他社APIとの併用も視野に入ります。
あえて見送るべき条件
社内にIaCやオブザーバビリティを運用できる体制がまだ整っていない場合、API直結方式をいきなり導入するのは見送るべきです。TerraformでのAPIキー管理やアラート設計を後回しにしたまま本番投入すると、障害時に誰も原因を追えない状態になりかねません。
また、利用量がまだ月数十件程度の実験段階であれば、SLOやコスト最適化の作り込みは過剰投資です。この段階ではSaaS版で運用ルールを固めることを優先し、利用が安定してから自社基盤への移行を検討する順番が現実的です。
まとめ
ChatGPTの週間利用者数が10億人を超えたという数字は、社内でAIをどう位置づけるかの議論を後回しにできなくなったことを示しています。
判断の起点は、SLO設計・IaCでの再現性・オブザーバビリティの統合度・コストと障害対応の仕組み化の4つです。まずは自社の既存インフラ基盤（IaCツール・監視基盤・インシデント対応フロー)を棚卸しし、API方式で載せられる余地があるかを確認するところから始めてみてください。
体制が整っていない段階なら、無理にAPI直結を急がず、SaaS版で運用ルールを固めてから移行する順番を選ぶ方が、結果的に事故を減らせます。