メインコンテンツまでスキップ

ChatGPTでサインイン

中級

2026年8月2日、OpenAIはChatGPTをアイデンティティプロバイダーに変えた。「Sign in with ChatGPT」は現在パブリックベータで、Google、Apple、Microsoftでのサインインと同じボタンラックに並び、B2B認証の多くが今後どこに住むかを静かに再描画している。このページは2種類の読者を同時に対象としている:ボタンをクリックしたときに実際に何が境界を越えるのかを知りたい ユーザー と、自分のアプリに追加するかどうか(追加するならOpenAIを積載依存にせずにどう追加するか)を決めなければならない 開発者 。

What you'll learn
  • ユーザーがChatGPTでサインインしたときにパートナーアプリが何を受け取るのか — そして何を受け取らないのかを理解する
  • 6つのローンチ日パートナーとその選定理由を知る(偶然ではなくシグナルである)
  • ChatGPTがサーバー上で期待する正確なOAuth 2.1 + PKCE + OIDCフローを歩む
  • 既に出荷されているエンタープライズ管理者コントロール — と、人を驚かせるデフォルトを見る
  • ログイン画面にボタンを置く前に設計すべき失敗モードを知る

60秒版​

  • 何がローンチしたか。 クロスプラットフォームのアイデンティティシステム:ユーザーはChatGPT認証情報を使って、GoogleやAppleを使うのと同じ方法でパートナーサイトでアカウントを作成したりリンクしたりできる。2026年8月2日にベータとして発表。
  • サインイン時に境界を越えるもの。 3つのクレーム:名前、メール、プロフィール画像。 それ以外は何もなく、ユーザーのチャット履歴について何もない。
  • 最初にステージに立つのは誰か。 6つの開発者ツールのローンチパートナー:Airtable、GitLab、HubSpot、Notion、Supabase、Vercel。 それはランダムなリストではない — ChatGPTセッションがソフトウェアをエンドツーエンドで構築してデプロイできるようにする筋肉群である。
  • 開発者が構築しなければならないもの。 PKCE(S256)とOIDCディスカバリーを使った標準のOAuth 2.1認可コードフロー — ChatGPTは自身をDynamic Client Registration経由で registration_endpoint に登録し、他のクライアントと同じように authorization_endpoint / token_endpoint を呼び出す。既にOIDCを出荷しているなら、80%は完成している。
  • 人を躓かせるエンタープライズデフォルト。 明示的なポリシーを設定していない組織は デフォルトでオプトイン されている。管理者は組織全体でSign in with ChatGPTをオフにするか、パートナーアプリの許可リストに制限することができる。

なぜこれが「もう一つのログインボタン」より大きな話なのか​

ログインボタンは、アイデンティティプロバイダーが誰になるかに気づくまでは互換に見える。Google Sign-inは、生産性ベンダーがアイデンティティも所有するというパターンを正常化した。Sign in with ChatGPTは同じトリックをするが、メールボックス側ではなく、ワークフローのアシスタント側から。

そこから2つのことが従い、名前を付ける価値がある:

  1. アイデンティティプロバイダーは今、ユーザーが既にエージェントとアクティブなセッションを持っている場所である。 そのエージェントは、ユーザーの代わりに、ユーザーが今承認したトークンでパートナーサイト(Notion、Vercel、Supabase、...)のApps SDKコネクタを呼び出すことができる。ボタンは「ログインさせて」だけではなく、「このアシスタントに私の代わりにそのツールに手を伸ばさせて」でもある。
  2. ローンチパートナーは、自律的なコーディングエージェントが必要とするツールである。 モデル + DB(Supabase)+ バックエンド(GitLab / Vercel)+ ドキュメント(Notion)+ 記録スプレッドシート(Airtable)+ CRM(HubSpot)。それはChatGPTで始まって何かを出荷して終わるセッションの形である。OpenAIがApps SDKセッションがどこに住むかを期待している場所のプレビューである。

Claudeで構築していてこれを読みながら「これは私に影響しない」と思っているなら — 間接的に影響する。ユーザーが偶然にも使う他のアシスタントは、同じログイン層を使って同じB2Bツールに手を伸ばしたいと思うだろう。このパターンを早く理解することが、それを受け入れるか、鏡像化するか(Sign in with Claudeは今日はパブリック製品ではない)、独自のOIDCで迂回するかを決める方法である。

実際に境界を越えるもの​

サインイン時のクレーム境界は意図的に狭い。ユーザーがフローを完了したとき、パートナーは以下を受け取る:

クレーム含まれるか?注意
name✅ChatGPTアカウントのユーザーの表示名
email✅ChatGPTアカウントに関連付けられたメール
picture✅プロフィール画像URL
チャット履歴❌パートナーと共有されない
メモリー / カスタム指示❌共有されない
プランティア(Free / Plus / Pro / Enterprise)❌サインイン時のクレームとして公開されない
支払い情報❌このフローの範囲外

系論 — ユーザーが見逃しがちな部分 — は、OpenAIが パートナー側から学ぶ ことである:どのアプリにサインインしたか、いつか。それは連合アイデンティティの形である:IdPはあなたのログインを見る、RPはあなたのアイデンティティを見る。GoogleやAppleとする同じ取引だ。ただ、存在する理由が異なる新しい相手方と行われているだけである。

Watch out
  • Sign in with ChatGPTはログイン連合であり、データ共有トンネルではない。パートナーはアイデンティティクレームを受け取り、あなたのチャットを受け取らない — しかしOpenAIはどのパートナーにサインインするかを見る。
  • エンタープライズのデフォルトはオプトインである。EnterpriseまたはTeam組織を運営していて設定に触れていない場合、ユーザーは今日6つのパートナーアプリのいずれでもすでに使用できる。

6つのローンチパートナー — 形として読む​

ローンチ名簿がここでの物語である。セッションが達成できることでグループ化:

  • データ / スプレッドシート — Airtable
  • ドキュメント / 知識 — Notion
  • コードベース / SCM — GitLab
  • データベース / バックエンド — Supabase
  • デプロイ / ホスティング — Vercel
  • CRM / GTMデータ — HubSpot

これは「ランダムな6つの早期採用者」ではない。ChatGPT駆動のビルダーセッションの運用スタックである:HubSpotからリードを引っ張り、Airtableでレコードを検索し、Notionに変更を書き、GitLabでコードを出荷し、SupabaseでDBを移行し、Vercelでデプロイする。そのすべてのステップが、OpenAIのApps SDKコネクタが既にいたい場所である。

あなたの製品がこれらのいずれかに隣接している場合(課題トラッカー、CRM、ローコード、ベクトルストア、分析)、Sign in with ChatGPTサポートが次の2四半期にわたってエンタープライズバイヤーからテーブルステークスの質問になると仮定せよ。

開発者が構築しなければならないもの​

朗報:プレーンなOAuth 2.1 + OIDCである。OIDCディスカバリーとDynamic Client Registrationを話す認可サーバーを既に持っているなら、主に構成であり、コーディングではない。ChatGPTが期待する形は以下の通り。

ChatGPTが呼び出すエンドポイント​

Guided walkthrough1 of 6
  1. /.well-known/openid-configuration を公開する(これがMCPリソースサーバーの場合は、それを指す /.well-known/oauth-protected-resource も)。ChatGPTはこれを読んで authorization_endpoint、token_endpoint、registration_endpoint、jwks_uri を見つける。

明白でない要件​

これを間違えるほとんどのチームは、以下のいずれかで1日を失う:

  • PKCEは必須で S256 でなければならない。 ディスカバリードキュメントで "code_challenge_methods_supported": ["S256"] を広告する。plain は受け入れられない。
  • アクセストークンをリソースにバインドしなければならない。 resource パラメータを使い、その値をトークンの aud クレームにコピーする。そうしないと、オーディエンス混同攻撃があなたのトップ脆弱性になる。
  • パブリッククライアント、シークレットなし。 ChatGPTは token_endpoint_auth_method: none(または好みで、ChatGPTの公開JWKSに対する private_key_jwt)を使う。トークン交換で client_secret を要求すると、フローが失敗する。
  • すべてのリフレッシュでローテーションする。 リフレッシュトークンをワンタイム使用として扱い、すべての交換でローテーションする。これは標準のOAuth 2.1ガイダンスであり、盗まれたリフレッシュトークンが迷惑であることと壊滅的であることの差である。
  • 中央取り消しを処理する。 エンタープライズ管理者はいつでも組織全体でSign in with ChatGPTを取り消すことができる。あなたのアプリは優雅に劣化しなければならない — トークンリフレッシュでの401はページするバグではない。ユーザーに再リンクを促すか、独自のログインにフォールバックするシグナルである。

最小限のディスカバリードキュメント​

ChatGPTがあなたと話すのに十分(発行者とパスを埋めてください):

Minimum /.well-known/openid-configuration for Sign in with ChatGPT

{
"issuer": "https://auth.example.com",
"authorization_endpoint": "https://auth.example.com/oauth/authorize",
"token_endpoint": "https://auth.example.com/oauth/token",
"registration_endpoint": "https://auth.example.com/oauth/register",
"jwks_uri": "https://auth.example.com/.well-known/jwks.json",
"response_types_supported": ["code"],
"grant_types_supported": ["authorization_code", "refresh_token"],
"code_challenge_methods_supported": ["S256"],
"token_endpoint_auth_methods_supported": ["none", "private_key_jwt"],
"subject_types_supported": ["public"],
"id_token_signing_alg_values_supported": ["RS256"],
"scopes_supported": ["openid", "email", "profile"]
}

おそらく欲しいスコープ​

パートナーアプリを構築していて、Sign in with ChatGPTを純粋にアイデンティティシグナルとして受け入れたい場合 — ユーザーのChatGPTアカウントへのデータプレーンアクセスなし — OIDCスコープのみを要求する:

Identity-only authorization request (no data-plane access)

GET /oauth/authorize?
response_type=code
&client_id={registered_client_id}
&redirect_uri=https://chatgpt.com/connector/oauth/{callback_id}
&scope=openid+email+profile
&code_challenge={base64url(sha256(verifier))}
&code_challenge_method=S256
&state={csrf_nonce}
&resource=https://api.example.com

リダイレクトURIの形状(https://chatgpt.com/connector/oauth/{callback_id})は重要である — それはChatGPT自身がルーティングして戻るもので、あなたの側で設定するものではない。

エンタープライズコントロール(そしてあなたを噛むデフォルト)​

Team / Enterpriseプランの組織では、管理者は今日2つのコントロールを得る:

  • Sign in with ChatGPTを組織全体で無効化。 組織の全員のためにボタンをオフにする。
  • 承認されたパートナーアプリのリストに制限。 ユーザーは許可リスト上のパートナーへのフローのみを完了できる。

ニュアンス:明示的なポリシーのない組織はデフォルトでオプトインされている — 6つのローンチパートナーの場合、すべてのユーザーが今すぐボタンを使える。セキュリティ姿勢が任意のサードパーティへの連合アイデンティティを許可しない場合、デフォルトを明示的に変更しなければならない。これは今月の実際のエンタープライズデプロイメントに最も影響する一文である。

Google / Apple / Microsoftサインインとの比較​

次元Sign in with ChatGPTGoogleAppleMicrosoft
サインイン時のアイデンティティクレームname、email、picture幅広い(name、email、picture、データ用のオプションスコープ)Name、プライベートリレーメールオプションName、email、テナント情報
同じ認証経由のデータプレーンアクセスYes — Apps SDKコネクタは同じセッションで独自のスコープを付与できるYes — スコープ付きOAuth経由のGoogle APILimited(Sign in with Appleは主にアイデンティティ)Yes — スコープ付きOAuth経由のGraph API
匿名化メールオプションNo(今日)NoYes — プライベートリレーメールNo
エンタープライズ管理者コントロール組織全体の無効化 + パートナー許可リスト完全なWorkspace管理コンソールMDM管理完全なEntra IDコンソール
パブリッククライアント + PKCE必須Yes、S256必須オプション(推奨)YesYes
エージェントとのクロスアプリセッションYes — これがポイントNoNoNo(Copilotは別の話)

注目すべき2行:プライベートリレーメールなし (Appleと違って、ユーザーは実際のアドレスを隠せない)、エージェントとのクロスアプリセッション (これが最初に存在する理由を説明する行)。

追加するタイミング — と迂回するタイミング​

Pro tip
  • バイヤーがAI志向で、製品が6つのパートナー隣接カテゴリ(開発ツール、データ、ドキュメント、CRM、デプロイ)内にある場合は追加せよ。既にOIDCを出荷しているなら、ボタンは追加が安価なシグナルである。
  • アプリをApps SDKコネクタとしてChatGPTセッションから到達可能にしたい場合は追加せよ。Sign in with ChatGPTはそのための自然な玄関である。
  • ユーザーが規制業界(健康、金融、政府)で、OpenAIが承認されたサブプロセッサーリストにいない場合は迂回せよ — 連合アイデンティティはデータ処理の信頼を意味する。
  • 製品の差別化がAI中立であることの場合は迂回せよ。1つのアシスタントのボタンを追加して他を追加しないことは、意図したかどうかに関わらずポジショニング声明である。

ほとんどのチームが着地する実用的なパターン:Google、Apple、Microsoftと並べて出荷し(いずれの代わりでもなく)、アイデンティティ専用クレームにスコープし、エンタープライズ管理者トグルを既存のSSOコントロールに配線する。

設計すべき失敗モード​

ボタンをライブにする前に、4つの失敗パスを配線せよ:

Guided walkthrough1 of 4
  1. エンタープライズ管理者がユーザーがライブセッションを持っている間にSign in with ChatGPTを無効化する。次のトークンリフレッシュは401を返す。ユーザーを静かにログアウトさせるな — 明確な「アカウントを再リンク」プロンプトとネイティブログインへのフォールバックを表面化せよ。

クイックチェック​

Check yourself

0/4
  1. ユーザーがSign in with ChatGPTでアプリにサインインする。デフォルトで、あなたのアプリは以下のどれを受け取るか?
  2. トークンエンドポイントを実装している。ChatGPTが認可コードの交換に失敗している。最も可能性の高い原因はどれか?
  3. エンタープライズ管理者がSign in with ChatGPT設定に触れていない。今日のユーザーの実効ポリシーは何か?
  4. Sign in with ChatGPTのためにサポートしなければならないPKCEコードチャレンジ方式はどれか?

AILmanac関連​

ソースと参考文献​