ChatGPTサインインβ、接続SaaS認証統制の実務点

OpenAI は 2026年7月29日 の ChatGPT release notes で、Sign in with ChatGPT beta の提供開始を案内した。対象は一部のプラグインとパートナーサイトで、初期パートナーとして Airtable、GitLab、HubSpot、Notion、Supabase、Vercel が挙げられている。

これは小さなログイン導線の追加に見える。しかし日本企業にとっては、ChatGPT / Codex が外部 SaaS を使うときの認証、アカウント作成、接続アプリ承認、個人アカウント混在を見直す合図になる。すでに ChatGPTアプリ権限 では接続 SaaS の操作承認を扱い、ChatGPT Google連携 では OAuth scope の承認を扱った。今回の焦点はさらに手前の「その SaaS に、どの identity で入るのか」である。

また、ChatGPT Businessプラグイン管理 で見たように、プラグインは ChatGPT と Codex の作業面を外部システムへ広げる配布単位になっている。Sign in with ChatGPT が広がると、プラグイン導入、外部サービスのアカウント作成、コネクタ権限、ChatGPT workspace の管理が同じ利用者体験の中で近づく。管理者は便利さだけでなく、どの台帳で何を管理するかを分けて考える必要がある。

事実: 何が発表されたのか

OpenAI の release notes によると、Sign in with ChatGPT は beta として段階展開される。ChatGPT の plugin directory から対応アプリへ接続するとき、または参加パートナーサイト上で、利用者は Sign in with ChatGPT を選んでアカウントを作成またはリンクできる。

OpenAI が明示している共有情報は限定的だ。サインイン時にパートナーへ共有されるのは、名前、メールアドレス、プロフィール画像がある場合の画像である。一方で、プラグインが受け取るアクセス権は別途 review and approve する。つまり、Sign in with ChatGPT は「OpenAI アカウントで外部サービスに入る導線」であり、「プラグインに全権限を渡す導線」ではない。

ここは導入判断で重要だ。ユーザー体験としては一つのボタンに見えても、実際には少なくとも三つの層がある。第一に、外部 SaaS のアカウント作成または既存アカウントとのリンク。第二に、ChatGPT / Codex 側でそのプラグインやコネクタを使えるか。第三に、外部 SaaS 側で認証済みユーザーがどのデータや操作にアクセスできるかである。

OpenAI の Codex ヘルプも、ChatGPT アカウントで Codex にサインインした場合、ChatGPT workspace の権限、RBAC、Enterprise の保持・レジデンシー設定が適用されると説明している。API key で使う場合とはデータ取り扱いと管理面が違う。Sign in with ChatGPT は消費者向けログインの話だけでなく、ChatGPT workspace identity を使う作業面の広がりとして見るべきだ。

事実: プラグイン権限とは別に管理する

OpenAI の plugin controls ドキュメントは、プラグイン管理を複数層に分けている。プラグインが利用者に見えるか、インストール済みにするか、コネクタを使えるか、どの action を許すか、外部サービス側の認証済み identity が何へアクセスできるか、さらに実行時の sandbox や approval がどう効くかは別である。

これは Sign in with ChatGPT を理解するうえでかなり重要だ。サインインが簡単になるほど、利用者は「つながった」と感じる。しかし管理者から見ると、つながった相手が個人アカウントなのか、会社の管理アカウントなのか、外部サービス側でどのロールなのか、ChatGPT 側でどのプラグイン権限を持っているのかは別々に確認しなければならない。

たとえば、開発チームが Vercel や Supabase のプラグインを使う場合を考える。Sign in with ChatGPT によりアカウント作成やリンクが速くなること自体は、導入摩擦を下げる。一方で、会社の IdP、SAML / OIDC、SCIM、ドメイン管理、退職者無効化、監査ログ、プロジェクト権限と衝突しないかを確認する必要がある。便利なサインイン導線が、会社の標準 SSO を迂回する入口になってはいけない。

同じ論点は、Notion、Airtable、HubSpot のような業務部門向け SaaS でも起こる。マーケティング、営業、CS、企画部門が ChatGPT から業務 SaaS に入れるようになると、アカウント作成の主体、データの所有者、退職時の回収、顧客データの扱いが問題になる。ChatGPT で使えるからといって、外部 SaaS 側の契約、DPA、監査、利用規程が自動的に整うわけではない。

分析: 日本企業ではSSOではなく入口として見る

ここからは分析である。

日本企業がこの更新を読むとき、最初に避けるべき誤解は「ChatGPT が企業 SSO になった」と受け取ることだ。現時点の発表は beta のサインイン導線であり、社内 IdP の代替ではない。むしろ、ChatGPT を起点に外部 SaaS へ入る入口が増えるため、既存の SSO、SaaS 管理、プラグイン審査とどう整合させるかが問題になる。

特に大企業では、外部 SaaS の利用は情シス、セキュリティ、法務、調達、部門管理者が分担している。GitLab や Vercel のような開発基盤なら、コード、デプロイ、シークレット、顧客環境に触れる可能性がある。HubSpot なら顧客情報や営業履歴、Notion や Airtable なら社内文書や業務データが入る。Sign in with ChatGPT は、これらの SaaS を ChatGPT / Codex の作業文脈に近づける。

だから、見るべき論点は「ログインが楽になるか」ではない。誰が外部 SaaS アカウントを作ってよいか。会社の管理ドメインで作られるのか。個人メールで作られるのか。既存の SSO 強制や MFA 条件を満たすのか。外部 SaaS 側のロールは誰が付けるのか。ChatGPT 側のプラグイン可用性と外部 SaaS 側の権限が食い違ったとき、どちらを正とするのか。これらを先に決める必要がある。

この問題は OpenAI Admin keys と Codex 分析履歴 ともつながる。利用が増えるほど、管理 API、分析、監査ログ、権限棚卸しが必要になる。Sign in with ChatGPT によって導入の摩擦が下がるなら、管理側は導入前の審査と導入後の棚卸しを軽くしてはいけない。

実務: 管理者が分ける四つの台帳

第一に、ChatGPT workspace の台帳である。誰がどの workspace に属し、どのロールを持ち、どのプランやシートで ChatGPT / Codex を使えるのかを管理する。ChatGPT アカウントでサインインした Codex は workspace の権限や保持設定の影響を受けるため、ここが土台になる。

第二に、プラグイン台帳である。どのプラグインを Available にするのか、Installed にするのか、どのロールへ配るのか、利用停止時に誰が外すのかを記録する。プラグインは単なる拡張機能ではなく、スキル、コネクタ、MCP server、外部サービス操作を束ねる配布単位になり得る。

第三に、外部 SaaS の identity 台帳である。Sign in with ChatGPT で作られた、またはリンクされた外部アカウントが、会社管理アカウントなのか、個人アカウントなのか、既存テナント配下なのかを確認する。退職、異動、委託終了、プロジェクト終了時に外部 SaaS 側のアクセスを止められるかが重要になる。

第四に、action / data 台帳である。ChatGPT や Codex がその SaaS で何を読めるか、何を変更できるか、どの操作で承認を求めるかを記録する。これは App permissions、Action control、外部 SaaS 側のロール、実行環境の permission profile を合わせた台帳である。読み取り、作成、更新、削除、共有、送信、公開、課金を同じ「利用可」でまとめると危ない。

導入チェック: 最初は小さく試す

日本企業が試すなら、最初から全社に開けるより、用途と SaaS を絞った pilot がよい。たとえば、開発チームなら GitLab や Vercel、データアプリなら Supabase、企画部門なら Notion や Airtable というように、対象 SaaS ごとにリスクが違う。各 SaaS について、会社の標準 SSO があるか、既存テナントに入るか、個人アカウント作成を許すか、ChatGPT 側のプラグイン設定と矛盾しないかを確認する。

次に、ユーザー向け文言を分ける。Sign in with ChatGPT は「外部サービスへのサインイン」であり、プラグインが何をできるかは別途承認する、と明記する。利用者が一つのボタンで全部を許可したと誤解すると、問い合わせと事故対応が増える。特に、名前、メール、プロフィール画像の共有と、外部データへのアクセス権付与は分けて説明する必要がある。

最後に、棚卸しを定期化する。ChatGPT workspace のメンバー、インストール済みプラグイン、外部 SaaS の接続アカウント、付与済みスコープ、実行された action、退職者・異動者の残存権限を月次または四半期で見る。Sign in with ChatGPT は、導入を速くする機能であるほど、棚卸しも速く回すべき機能である。

まとめ

Sign in with ChatGPT beta は、利用者には便利なログイン機能として見える。しかし企業導入では、ChatGPT / Codex が外部 SaaS と結びつく入口が増える変更として読むべきだ。共有されるプロフィール情報、プラグイン権限、外部 SaaS 側の認可、ChatGPT workspace の RBAC、実行時の permission はそれぞれ違う層にある。

日本企業が今やるべきことは、対応パートナーを一覧化し、会社の SaaS 管理台帳と突き合わせ、pilot 対象だけを開けることだ。OpenAI アカウントで外部サービスに入れること自体を否定する必要はない。ただし、SSO、MFA、退職者無効化、外部データアクセス、プラグイン action、監査ログを同じ管理表で追える状態にしてから広げるべきである。

出典

• ChatGPT Release Notes - July 29, 2026
• Using Codex with your ChatGPT plan
• Plugin controls
• Authentication