ChatGPT Work — New Enterprise Tier
OpenAIは、法人課金を
三層構造に組み替えた。
これまで「Business」と「Enterprise」の二段だったOpenAIの法人プランに、上位層 ChatGPT Work が加わりました。OpenAI公式アナウンスでは「監査・SSO・部門課金・専用容量」を束ねた層と説明されています。IPO準備が本格化する裏で、稟議シートに新しい行がひとつ増えた——その構造変化を、購買・情シス・PdMの目線で読み解きます。
What Changed
「Business の上に、もう 1 段」の意味
プラン増設ではなく、購買プロセスの分離。
これまで OpenAI の法人課金は、シートベースで気軽に始められる Business と、監査ログや SSO を含む全社導入向けの Enterprise の 二段構成でした。今回追加された ChatGPT Work は、その上に重ねられた第三層です。OpenAI が明かしたスコープは「部門ごとの分割請求」「専用推論容量（Reserved Capacity）」「監査・DLP・SSO をワンパッケージ化」「導入支援 SLA」の 4 点セットで、実質的には Enterprise の「フルスイート版」に相当します。
ポイントは プラン名の増設ではなく、購買プロセスそのものの分離にあります。Business は各チームがカード決済で入れ、Enterprise は本社契約で入れ、Work は「部門単位で稟議を切って、部門予算で買う」設計です。IT 部門を通さず現場が導入できる Business と、全社統制下に置く Enterprise の間に、「部門単位の統制」レイヤを差し込んだ、と読むのが正確です。
The Numbers
三層をひとつの表で並べる
| Business / Enterprise（従来） | ChatGPT Work（新層） |
|---|---|
| 全社一括契約が前提 | 部門単位で予算・請求を分離 |
| 推論は共用プール | 部門ごとに Reserved Capacity を割当 |
| 監査・SSO は個別オプション | 監査ログ・SSO・DLP を最初から同梱 |
| 導入は情シスの仕事 | 導入 SLA 付きで部門主導が可能 |
Why It Matters
IPO 準備の裏で、収益の「厚み」を作りに来た
単体機能の追加ではありません。「同じ企業の中に、Business と Enterprise と Work を並存させる」ことを OpenAI は初めて明示しました。これまで法人販売の営業トークは「小さく始めて全社契約に育てる」の一本道でしたが、Work は「Enterprise の上に、部門ごとの深い契約を積み重ねる」というアップセルの二本目のレーンを新設した格好です。
IPO 前の投資家開示では、粗利率とネットリテンション（既存顧客からの拡張売上）が重要指標として問われます。ChatGPT Work は、既存 Enterprise 顧客からの「上乗せ売上」を作りに行く布石として理解するのが素直です。価格ページで Work が Enterprise と併記されているのも、置き換えではなく上乗せを前提としている裏付けです。
Who It Hits
誰の稟議に、どう効くか
情シス・購買・PdM・現場ユーザーで、影響の出方が真逆に分かれます。
情シス・購買
稟議項目が 1 段増えます。Business と Enterprise の運用を続けたまま、部門起点で入ってくる Work の申請ルートを、承認フローと SSO 統制に組み込む作業が発生します。
部門長・PdM
「情シス承認待ち」を経由せず自部門予算で AI 導入を回せるのが最大の利点。反面、統制設計を自分で背負う必要があり、DLP・監査の運用が部門側の責任範囲になります。
現場・個人利用
個人の Plus/Free には影響ゼロ。UI もモデルも変わりません。手元の使い勝手には無関係で、変化は「請求書と管理画面の階層」だけで完結します。
Work は、機能ではなく
購買動線を売っている。
What's Next
次に何が起きるか / 何をすべきか
棚卸し
既存の Business / Enterprise の契約を洗い、部門単位で分割請求が要る部署（法務・R&D・海外拠点など）を特定します。Work は「そこにだけ」ぶつけるべき層です。
統制の再設計
Work は SSO・監査・DLP を同梱しますが、既存の Enterprise 統制と重複するとポリシー矛盾が起きます。ログの流し先とアクセス基盤を先に決めます。
「Enterprise を延長すべきか、Work を上乗せか」
更新期の Enterprise 顧客は、Work への移行提案が OpenAI 側から必ず来ます。上乗せか置換かは、部門予算の独立性で判断するのが素直です。
The Counterpoint
反対視点：この構造にはコストがある
手放しに歓迎できる話ではありません。プラン層が増えるほど、ライセンス最適化の難度は上がります。同じ社内で Business・Enterprise・Work が並走した場合、部門をまたぐユーザーがどの層で課金されるかは重複しやすく、監査で「同一人物が三重にカウントされていた」ような事故は既に他 SaaS で報告されています。
また、Work の「専用容量（Reserved Capacity）」は魅力的な一方で、実際の利用が想定より少なければ純粋な余剰になります。Reserved を根拠に稟議を通すなら、レートリミットの実測を 1〜2 か月取ってから乗り換えるのが安全です。「上位層＝上位機能」ではなく「上位層＝上位の運用責任」であることを、購買側は先に共有しておく必要があります。