2026年8月25日現在、Sign in with ChatGPTは6社の初期パートナーへ展開され、外部アプリに渡るプロフィール情報は3項目です。ただし、「公開OAuth仕様が出て、どの開発者でもすぐ実装できるようになった」という理解は正しくありません。OpenAIの公式情報で確認できるのは、IDプロバイダーとしての機能、対象パートナー、共有データ、管理者向け制御までです。クライアント登録、認可・トークンエンドポイント、スコープ、トークン仕様などの公開実装資料は確認できていません。
- 確認済み：Airtable、GitLab、HubSpot、Notion、Supabase、Vercelから展開が始まっています。
- 確認済み：外部アプリが受け取るのは氏名、メールアドレス、プロフィール画像（設定している場合）の3項目です。
- 未確認：一般開発者向けの申請方法、OAuthフロー、スコープ、エンドポイント、SDK、料金、SLAは公式公開資料で確認できません。
もう一つの誤解は、これをMCPサーバーの認可と同じものだと考えることです。Sign in with ChatGPTはユーザーが外部アプリへ入るための「入口」であり、MCPのOAuthはエージェントが保護されたMCPサーバーへアクセスするための「権限経路」です。MCP側の仕様はMCP認可のOAuth 2.1実装ガイドで分けて確認してください。
「ChatGPTの会話やメモリまでアプリに渡るのでは？」という不安もよく見かけます。OpenAIのHelp Centerによれば、Sign in with ChatGPT単体で会話、メモリ、ファイル、トークン、請求情報が外部アプリへ共有されることはありません。追加のアクセスが必要な場合は、ログインとは別の権限承認が必要です。
重要なのは、ChatGPTやCodexから開発基盤へ移る導線が短くなり、AIエージェントの利用開始点とアカウント作成が近づくことです。一方、公開仕様がない段階で非公式コードを本番へ持ち込むのは危険です。以降は確定した事実と未確認情報を分けます。
まず直すべき誤解：これはMCP認可でも公開APIでもない
同じ「Sign in with ChatGPT」でも用途が違う
OpenAIはSign in with ChatGPTを「ChatGPTアカウントのID情報を使い、対応する外部アプリのアカウントを作成、連携、または利用するためのIDプロバイダー型サインイン」と説明しています。ここで認証される主体は人間のユーザーです。外部アプリは、その人を自社サービスのアカウントへ結び付けます。
一方、Codexアプリ、CLI、IDE拡張にも「Sign in with ChatGPT」という表示があります。こちらはOpenAIのCodexをChatGPTプランで使うためのログインです。さらにMCP認可では、AIエージェントやMCPクライアントが外部のリソースへ何をしに行けるかを制御します。同じ言葉が画面に出ても、対象となるクライアント、データの流れ、権限の意味は別です。
「OAuth」という検索語だけで実装仕様を補完しない
検索結果にはOAuth 2.0、OpenID Connect、PKCE、具体的なURLやスコープを断定する非公式記事があります。しかし、2026年8月25日にOpenAI Help Center、OpenAI Developers、Platformドキュメントを検索した範囲では、外部アプリ向けSign in with ChatGPTの公開技術仕様を確認できませんでした。公式Help Centerが使っている表現は「identity-provider sign-in option」です。
一般的なOAuth実装の安全策はIETFのRFC 9700（OAuth 2.0 Security Best Current Practice、2025年1月）で確認できます。ただし、これはSign in with ChatGPTの具体的なフローを証明する資料ではありません。OpenAIから開発者資料を受け取った後に、その仕様を最新のセキュリティ推奨と照合するための基準です。
一次情報で確定した現在地
| 論点 | 2026年8月25日時点の確認結果 | 開発者への意味 |
|---|---|---|
| 機能の位置付け | ChatGPTのID情報で外部アプリのアカウントを作成、連携、利用するIDプロバイダー型サインイン | OpenAI APIの利用権やMCPツール権限とは分けて設計する |
| 初期パートナー | Airtable、GitLab、HubSpot、Notion、Supabase、Vercelの6社 | 開発者・知識労働者が日常的に使う業務基盤から展開が始まった |
| 利用可能性 | 認証済みChatGPTユーザー向けにグローバル提供。組織ユーザーは管理者設定にも依存 | ユーザー属性だけでなく、テナントポリシーによる利用不可を想定する |
| 外部アプリへの共有 | 氏名、メールアドレス、プロフィール画像（存在する場合）の3項目 | ログイン時の受領データを最小限として扱い、用途と保持方針を説明する |
| 単体では共有されない情報 | ChatGPTの会話・メモリ、ファイル・トークン、請求情報など | 「ChatGPTアカウントで入る」と「ChatGPTデータを読む」を同一視しない |
| 追加アクセス | ログインとは別に、ユーザーまたは組織管理者の承認が必要 | サインイン同意とツール接続同意を別画面・別ログで管理する |
上表はOpenAI公式Help Center「Sign in with ChatGPT」を基準にしています。公式ページはOpenAI AcademyとCodex Sitesで利用でき、選定されたプラグインとパートナーサイトへ展開中とも説明しています。「すべてのアプリで利用可能」という発表ではありません。
発表日が7月29日、8月2日、8月3日に分かれて見える理由
OpenAIのChatGPT Release Notesでは、Sign in with ChatGPTの項目は2026年7月29日付です。同日、Supabaseもベータ提供を公式ブログで発表しました。二次情報のTechTimesは2026年8月3日公開の記事で、8月2日にライブベータが始まったと報じています。
現在のOpenAI Help Center本文には「8月2日ローンチ」という日付がありません。そのため、この記事では7月29日を公式記録、8月2日をTechTimesの報道として区別します。日付を一つに丸めるより、情報源の主体を保つほうが安全です。
6社の顔ぶれが示す「開発者導線」
初期パートナーは、単なる消費者向けアプリの寄せ集めではありません。コード、デプロイ、バックエンド、ドキュメント、業務データ、顧客管理という、プロダクト開発の周辺を広く覆っています。ここから先は公式発表された製品仕様ではなく、パートナー構成に基づくAIgent Lab編集部の分析です。
| パートナー | 代表的な開発・業務接点 | Sign in with ChatGPTが短くする可能性のある導線 |
|---|---|---|
| Airtable | 構造化された業務データとワークフロー | ChatGPTから業務データ基盤へ移る際のアカウント作成・連携 |
| GitLab | ソースコード、レビュー、開発運用 | コーディング支援から開発プロジェクトへ入る際の本人確認 |
| HubSpot | CRM、営業、マーケティング | エージェントが関わる顧客業務ツールへの初期オンボーディング |
| Notion | ドキュメントとチーム知識 | 会話からナレッジ作成・共同作業へ移る際のアカウント連携 |
| Supabase | データベース、認証、バックエンド | プロンプトで始めたアプリ開発からバックエンド作成へ進む導線 |
| Vercel | Webアプリ開発とデプロイ | 生成したアプリを動かす環境へ移る際のアカウント作成・利用 |
Supabaseのベータが見せた実際のアカウント動作
6社のうち、Supabaseは2026年7月29日の公式ブログで具体的な利用像を公開しています。新規ユーザーはChatGPTアカウントでSupabaseアカウントを作成できます。既存ユーザーはChatGPT側と同じメールアドレスであれば既存アカウントへ自動リンクされ、SSOアカウントは例外として分離されます。
さらに重要なのが、サインインとプラグインへのアクセス許可が分離されている点です。ユーザーはログイン後も、プラグインが何へアクセスできるかを確認して承認します。これは「人間のIDを確認する工程」と「エージェントやプラグインへ権限を渡す工程」を混ぜない設計の実例です。
ChatGPTとCodexが利用開始地点になる
Supabaseは、ChatGPT WorkやCodexで作業する開発者が、そのままバックエンド側のアカウント作成・連携へ進めることを利点として挙げています。従来は「AIに実装相談をする」「別タブでサービス登録する」「再びAIへ戻る」という分断がありました。Sign in with ChatGPTは、その分断の一部をID連携で埋めます。
ここに戦略的な意味があります。ChatGPTは回答画面だけでなく、外部アプリを発見し、接続し、利用開始する入口へ広がりつつあります。Google、Apple、Microsoftに続く新しいログイン選択肢になり得ますが、2026年8月時点では6社から始まった展開です。既存のログイン基盤と同等の普及や可用性を前提にする段階ではありません。
「共有は3項目だけ」で安心しきらない
外部アプリが受け取るデータ
OpenAIが明示する外部アプリへの共有データは、氏名、メールアドレス、プロフィール画像の3項目です。プロフィール画像が設定されていなければ、その項目はありません。ChatGPTの会話・メモリ、ファイル・トークン、請求情報などはSign in with ChatGPT単体では渡りません。
ただし、メールアドレスは個人を識別し得る情報です。「3項目だから軽い」と考えず、利用目的、保存期間、削除方法、アカウント連携解除時の扱いをプライバシーポリシーと画面上で説明する必要があります。OpenAIもChatGPT Sitesの公式Helpで、Sign in with ChatGPTを使うサイトは、受け取る情報と利用方法を説明するよう求めています。
OpenAIが認証運用のために処理するデータは別枠
外部アプリが受け取る3項目と、OpenAIが認証フローを運用するために処理する情報は別です。公式Help Centerは、OpenAI側でアカウント識別子、メールアドレス、認証プロバイダー、選択したワークスペースや組織、外部アプリの識別子、要求・承認された権限、認可結果などを処理する場合があると説明しています。
さらに、リクエストやセッションの識別子、IPアドレス、推定位置、ブラウザやアプリのバージョン、ユーザーエージェント、端末識別子、セキュリティシグナルも含まれ得ます。この区別は、外部アプリがChatGPTの会話を読めるという意味ではありません。認証基盤を運営するOpenAIと、ログイン先のアプリで、見える情報と責任範囲が異なるということです。
同意画面を一枚にまとめない
ログインに必要なプロフィール共有と、プラグイン、MCPサーバー、SaaS APIへの追加アクセスを同じ説明へ押し込むと、ユーザーは何に同意したのか分からなくなります。画面、監査ログ、解除操作を分け、権限追加時には対象リソースと実行可能な操作を再表示する設計が必要です。
開発者がまだ書けないコード、先に決められる設計
| 項目 | 公式公開情報での確認 | 現時点の扱い |
|---|---|---|
| 一般開発者向けクライアント登録 | 確認できず | 申請URLや審査条件を推測しない |
| 認可・トークンエンドポイント | 確認できず | ブログ由来のURLを本番コードへ入れない |
| 対応フローとPKCE要件 | 確認できず | OAuthの一般論と製品仕様を分ける |
| スコープ、クレーム、安定ID | 確認できず | メールアドレスだけを不変の主キーと決め打ちしない |
| トークン寿命、失効、鍵ローテーション | 確認できず | 運用要件を満たせるか資料受領後に審査する |
| 料金、SLA、一般提供時期 | 確認できず | 事業計画へ確定値として入れない |
この表の「確認できず」は、仕様が存在しないという断定ではありません。一般公開されたOpenAI公式資料から確認できない、という意味です。初期パートナーは個別資料や契約条件を受け取っている可能性がありますが、その内容を外部の開発者が推測して使うことはできません。
非公式SDKと似た名称のプロジェクトに注意する
検索すると「Login with ChatGPT」「OpenAI OAuth」などを名乗る第三者SDKやサンプルが見つかります。中にはChatGPTプランでモデル利用を中継することを目的としたものもあり、今回の外部アプリ向けIDプロバイダー機能とは目的が異なります。OpenAI公式ドメインの資料、提供主体、利用規約、認証先を確認できないパッケージを、公式SDKとして扱わないでください。
実装開始のゲートを先に決める
- 自社が正式な対象パートナー、または利用可能な開発者であることを確認できる
- クライアント登録とリダイレクトURI登録の正式手順を入手している
- エンドポイント、フロー、スコープ、戻り値を公式資料で照合できる
- 署名検証、CSRF対策、トークン保護、失効の要件をセキュリティレビューできる
- アカウントリンク、解除、削除、復旧、重複時の処理をテストできる
- ChatGPT以外のログイン経路を維持できる
この6条件がそろう前に作れるのは、認証プロバイダーを差し替え可能にする抽象化、アカウント連携の状態遷移、同意画面、監査ログ、テストケースです。OpenAI固有のネットワーク呼び出しは、公式仕様が確認できてから実装します。
AIエージェントの認証設計は二層で考える
第1層：人間が誰かを確認する
Sign in with ChatGPTが担当するのは、外部アプリの入口にいるユーザーのアカウント作成・リンク・アクセスです。ここで必要なのは、本人が意図したアカウントへ入ったか、既存アカウントと安全に結び付いたか、組織ポリシーに反していないかの確認です。
第2層：エージェントが何を実行できるかを決める
ログイン後、AIエージェントがGitLabのリポジトリを読む、Notionのページを更新する、Supabaseのプロジェクトを操作するといった処理には、別の認可が必要です。Sign in with ChatGPTだけでその権限が付与されるわけではありません。OpenAIの公式説明も、追加アクセスは別承認だと明記しています。
MCPアプリ側の構造はOpenAI Apps SDKとChatGPT向けMCPアプリのガイドを参照してください。人間のサインインと、ツール呼び出しに必要なOAuth認可を一つのトークンや一つの同意で代用しないことが要点です。
四つの主体を認証モデルへ置く
| 主体 | 確認する問い | 必要な制御 |
|---|---|---|
| 人間のユーザー | 誰がアプリへ入ろうとしているか | ログイン、アカウントリンク、復旧、退会 |
| 組織・テナント | そのユーザーに利用を許可してよいか | 承認済みアプリ、SSO例外、ロール、ポリシー |
| エージェント実行環境 | どのエージェントが処理しているか | 実行ID、短命な資格情報、監査ログ、停止 |
| 接続先ツール | 何を読み、何を変更できるか | 最小権限、追加同意、操作別承認、失効 |
AIエージェントのIDと権限をより広く整理したい場合は、AIエージェントのアイデンティティ設計もあわせて確認してください。人間のログインが便利になっても、非人間ID、ツール権限、監査可能性の設計は残ります。
採用判断を左右する6つの設計論点
1．ユーザー層とChatGPT利用の重なり
開発者向け、AI活用者向け、ChatGPTから発見されるアプリであれば、登録摩擦を減らせる可能性があります。反対に、ChatGPTを使わない顧客が中心なら、ボタンを増やすだけで選択負荷が上がります。まず自社の登録経路別コンバージョンと、対象ユーザーが使う認証手段を計測してください。
2．代替ログインとアカウント復旧
OpenAIは、組織管理者がSign in with ChatGPTを無効化したり、承認済みアプリだけに制限したりできると説明しています。昨日使えたユーザーが、会社のポリシー変更後に使えなくなるケースを設計に入れる必要があります。既存SSO、パスキー、メールなど、自社のリスク評価に合う代替経路と二つ目のログイン手段を用意します。
3．既存アカウントとの安全なリンク
Supabaseの例では、同じメールアドレスの既存アカウントが自動リンクされ、SSOアカウントは分離されます。しかし、これが全パートナー共通の必須仕様だとは発表されていません。メール一致だけで重要アカウントを結び付ける前に、再認証、管理者承認、通知、リンク解除、重複解消の手順を定めます。
4．Enterprise管理者ポリシー
OpenAI公式Helpによれば、明示的なポリシーがない組織ではSign in with ChatGPTが既定で有効です。既存の許可・拒否ポリシーや承認済みアプリ一覧は上書きされません。Global Admin Consoleでは、組織全体での無効化、承認済みアプリのみの許可、アプリ単位の承認・無効化ができます。
B2Bアプリでは「ChatGPTユーザーなら入れる」ではなく、「そのユーザーの所属組織が自社アプリを許可しているか」をエラー文、サポート手順、営業オンボーディングまで含めて扱う必要があります。
5．ログインとデータアクセスの分離
プロフィール3項目だけでアカウントを作る処理と、業務データへアクセスする処理を分離します。後者では、対象データ、操作、保持、第三者提供、エージェントの自動実行範囲を改めて示します。社内ルールを設計する際はAIエージェントのガバナンスと権限設計も参考になります。
6．セッション終了と監査
OpenAIのActive sessionsに関する公式Helpは、第三者アプリのセッション、接続済みアプリ、第三者サービスだけに使われるSign in with ChatGPTセッションを表示・管理しないと説明しています。したがって、ChatGPTのセキュリティ画面だけにログアウトや失効を依存できません。
自社アプリ側に、全端末ログアウト、アカウント連携解除、疑わしいログインの検知、管理者によるセッション停止、監査ログを用意します。OpenAI側のログアウトと、自社アプリのセッション終了が同じ結果になると決め付けず、公式仕様に基づいて個別に検証してください。
【要注意】先走ると起きる5つの失敗
失敗1：二次情報のエンドポイントをそのまま使う
避けたい状態：検索上位の記事に載った認可URL、トークンURL、スコープを公式仕様としてコピーする。
回避策：OpenAI公式の開発者資料または正式に提供されたパートナー資料で、URL、発行者、対応フロー、署名鍵、失効方法を一つずつ照合します。確認できなければコードへ入れません。
失敗2：唯一のログイン手段にする
避けたい状態：組織管理者の制限や段階的ロールアウトを考慮せず、Sign in with ChatGPTだけでアカウントへ入れるようにする。
回避策：利用不可、管理者拒否、アカウント削除、障害時でも復旧できる代替ログインを維持します。ログインプロバイダーの状態と自社アカウントの所有権を分離してください。
失敗3：メールアドレスを不変IDと決め付ける
避けたい状態：メール一致だけで既存アカウントを自動統合し、誤リンクを戻せない。
回避策：公式仕様で安定した識別子が確認できるまでは、リンク前の再認証、通知、競合検知、管理者レビューを設計します。特にSSO管理アカウントは個人アカウントと別に扱います。
失敗4：ログイン同意でツール権限まで取ったことにする
避けたい状態：「ChatGPTで続行」を押したユーザーが、リポジトリ更新やCRM書き込みまで許可したと解釈する。
回避策：OpenAIの説明どおり、追加アクセスは別の承認へ分けます。AIエージェントの自動実行は、操作別の最小権限、重要操作の人間承認、取り消し可能性を持たせます。
失敗5：解除をChatGPT側だけに任せる
避けたい状態：ユーザーがChatGPTからログアウトすれば、第三者アプリのセッションも連動して終了すると考える。
回避策：自社側のセッション、接続、トークン、監査ログを独立して管理し、ユーザーと管理者が明示的に失効できるようにします。実際の連動範囲は公開仕様またはパートナー資料で確認します。
仕様公開を待ちながら進められる実装準備
認証プロバイダーを交換可能にする
アプリ内部では「ChatGPT固有のユーザー」を直接ドメインモデルにせず、外部IDプロバイダーとのリンクとして扱います。ユーザー本体、外部ID、組織所属、ログイン方法、接続状態を分離すれば、ChatGPT、既存SSO、パスキーなどを追加・解除しやすくなります。
ログイン選択と追加権限を設定上も分離する
次のTypeScriptはOpenAIへ接続する実装ではありません。エンドポイント、スコープ、トークンを一切含めず、Sign in with ChatGPTを任意のログイン候補として扱い、エージェントのツール権限同意と分離するための設定例です。
動作環境：TypeScript。外部パッケージとネットワーク呼び出しはありません。
type ConsentKind = "identity" | "tool_access";
const authPolicy = {
primaryLoginMethods: ["existing_sso", "passkey"],
optionalProviders: {
chatgpt: { enabled: false, required: false },
},
consent: {
signIn: "identity" as ConsentKind,
agentTool: "tool_access" as ConsentKind,
},
} as const;- 公式仕様と利用資格を確認するまでは、ChatGPTプロバイダーを無効のままにする
- 既存SSOやパスキーを主経路として残し、ChatGPTを必須にしない
- ログイン同意とエージェントのツールアクセス同意を別の種類として記録する
注意：本番環境で使用する前に、必ずテスト環境で動作確認してください。この例は認証通信を実装するものではないため、公式技術仕様の代わりにはなりません。
アカウント状態を先に定義する
- 新規作成、既存リンク、リンク競合、組織管理アカウント、利用拒否を別状態にする
- プロフィール更新とアカウント所有権の変更を別イベントにする
- 外部ID解除後も、ユーザーが自社データへ復旧できる手段を設ける
- 退会、データ削除、再登録で古いリンクが復活しないことを確認する
権限同意と監査ログの雛形を作る
ログインイベントには、プロバイダー、組織、結果、失敗理由、アカウントリンクの有無を記録します。ツール認可イベントには、対象サービス、権限、承認者、有効期限、失効理由を別に記録します。プロフィールやトークンそのものを不要にログへ残さず、秘密情報はマスキングしてください。
公開仕様を監視する場所を固定する
確認先はOpenAI Help Center、ChatGPT Release Notes、OpenAI Developers、Platformドキュメントに固定します。公開時には、一般開発者向け登録、対応地域・プラン、管理者制御、セキュリティ要件、データ処理、失効、料金を再照合します。二次記事は発見には使えても、実装値の正本にはしません。
よくある質問
Sign in with ChatGPTとは何ですか？
ChatGPTアカウントのID情報を使い、対応する外部アプリのアカウントを作成、リンク、または利用するためのIDプロバイダー型サインインです。2026年8月25日時点では、Airtable、GitLab、HubSpot、Notion、Supabase、Vercelが初期パートナーとして公式に挙げられています。
誰でも自社アプリに追加できますか？
一般開発者向けの登録手順や公開実装ドキュメントは、2026年8月25日に確認したOpenAI公式資料では見つけられませんでした。パートナー向けに提供されている可能性はありますが、公開された申請方法、審査条件、一般提供時期は確認できません。
OAuth 2.0やOpenID Connectを使っていますか？
OpenAIの現行Help CenterはIDプロバイダー型サインインと説明していますが、外部アプリ向けの対応プロトコル、フロー、スコープ、エンドポイントを公開していません。二次情報だけでOAuth 2.0やOpenID Connectの具体的実装を確定しないでください。詳細は公式開発者ドキュメントの公開または正式なパートナー資料を待つ必要があります。
外部アプリに共有される情報は何ですか？
氏名、メールアドレス、プロフィール画像（設定している場合）の3項目です。追加のデータアクセスはサインインとは別に承認されます。アプリ側は受け取る情報、利用目的、保持、削除の方法を説明する必要があります。
ChatGPTの会話やメモリも共有されますか？
Sign in with ChatGPT単体では共有されません。OpenAIは会話・メモリ、ファイル・トークン、請求情報などを独立して共有しないと説明しています。別のプラグインやアプリ接続で追加権限を求められた場合は、その同意画面を個別に確認してください。
MCPサーバーのOAuth認可とは何が違いますか？
Sign in with ChatGPTは人間が外部アプリへログインするためのID連携です。MCPのOAuth認可は、MCPクライアントやAIエージェントが保護されたMCPサーバーへアクセスする権限を扱います。前者だけで後者のツール権限が付与されるわけではありません。
Codex CLIのSign in with ChatGPTと同じですか？
表示名は同じでも、ユースケースを分けて考える必要があります。CodexのサインインはCodexクライアントをChatGPTアカウントで利用するための認証です。今回扱う機能は、対応する外部アプリのアカウントを作成・リンク・利用するためのIDプロバイダー機能です。
Enterpriseユーザーも使えますか？
OpenAIは認証済みChatGPTユーザーにグローバル提供し、Enterprise組織のユーザーも含むと説明しています。ただし、実際の利用可否は組織管理者の設定に依存します。管理者は組織全体で無効化したり、承認済みアプリだけに制限したりできます。
結論と次の一歩
Sign in with ChatGPTの登場は、ChatGPTが「会話する場所」から、外部アプリを発見し、アカウントを作り、利用を始める入口へ広がっていることを示します。6社の初期パートナーが開発・業務基盤に集中しているため、AIエージェントを作る開発者には無視できない動きです。
ただし、現時点で実装を急ぐべき対象はログインAPIではありません。認証プロバイダーの抽象化、アカウントリンク、代替ログイン、組織ポリシー、同意分離、失効、監査を先に整えます。OpenAIが公式の開発者仕様を公開した時点で、クライアント登録、フロー、スコープ、トークン検証を一次情報と照合して接続してください。
この記事を読んで導入イメージが固まってきた方へ
UravationではAIエージェント導入の研修・コンサルを行っています。
この記事はAIgent Lab編集部がお届けしました。
参考・出典
- Sign in with ChatGPT — OpenAI Help Center（参照日: 2026年8月25日）
- ChatGPT Release Notes — OpenAI、Sign in with ChatGPT項目は2026年7月29日付（参照日: 2026年8月25日）
- Sign in with ChatGPT is in beta on Supabase — Supabase、2026年7月29日（参照日: 2026年8月25日）
- Global Admin Console — OpenAI Help Center（参照日: 2026年8月25日）
- Managing active sessions in ChatGPT — OpenAI Help Center（参照日: 2026年8月25日）
- Creating and managing ChatGPT Sites — OpenAI Help Center（参照日: 2026年8月25日）
- RFC 9700: Best Current Practice for OAuth 2.0 Security — IETF、2025年1月（参照日: 2026年8月25日）
- Sign in with ChatGPT Launches: What OpenAI Retains Is Not What Gets Shared — TechTimes、2026年8月3日（参照日: 2026年8月25日）
