ChatGPT

Sign in with ChatGPTとは？OAuth実装とプラン利用の仕組み・制約【2026年11月】

Sign in with ChatGPTとは？OAuth実装とプラン利用の仕組み・制約【2026年11月】

Sign in with ChatGPTは、ChatGPTのアカウントで他社のアプリやサイトにサインインできる仕組みで、OpenAIが2026年9月29日のDevDay 2026で発表しました。利用者が許可すれば、ChatGPT PlusやProのプラン枠でアプリ内のAI処理をまかなえる点が、GoogleやAppleのソーシャルログインとの違いです。この記事では、提供範囲と対応アプリ、Webサイトへの組み込み（PKCEとIDトークン検証）、OSSアプリでプランを推論に使う登録フロー、プレビュー版の制約とエラー別の復旧までを、公式ドキュメントのコード付きで整理します。仕様は2026年11月4日時点の公式情報です。

まとめ：Sign in with ChatGPTの2つの権限と開発者が今使える範囲

Sign in with ChatGPTには、本人確認だけを受け取る「ID連携」と、利用者のChatGPTプランでAI処理を行う「プラン利用」の2つの権限があります。利用者は2つを別々に許可し、アプリに会話履歴やメモリーは渡りません。

開発者が今すぐ自分で始められるのは、利用者の手元で動くOSSアプリにプラン利用を組み込む経路だけです。クライアントIDは初回サインイン時に自動で発行され、APIキーもクライアントシークレットも要りません。商用のWebサイトやSaaSでのID連携とプラン利用は、限定トライアルと待機リストの段階です。有料の自社サービスに組み込む計画は、申請が通るまで既存の認証とAPI課金を残したまま進めるのが安全です。

Sign in with ChatGPTの仕組みとDevDay 2026の提供範囲・対応先

最初に、何を許可する仕組みなのかと、誰が使えるのかを分けて押さえます。

ID連携とChatGPTプラン利用を別々に許可する2層の権限設計

公式のクイックスタートによると、ID連携で要求するスコープは openid profile email の3つです。アプリは安定したアカウント識別子、名前、メールアドレス、プロフィール画像を受け取れます。ChatGPTの会話やOpenAI APIの資源には届きません。

プラン利用は、これとは別のスコープ offline_access resource.invoke chatgpt.tokens.use.direct を利用者が許可したときだけ有効になります。Responses APIを呼べるアクセストークンの発行は、このプラン利用の許可を受けた後です。利用者側の同意画面にも「Use your ChatGPT plan」が独立した項目として表示されます。つまり「ログインは許すがプランは使わせない」という選択が利用者に残る設計です。

商用は限定トライアル・OSSは開放というDevDay 2026時点の提供状況

DevDay 2026の発表一覧は、商用のサインインを「選ばれたパートナーとの限定トライアル」、プラン利用を「OSSパートナーと一部の非公開クライアント向け」と書いています。統合の型ごとに整理すると次のとおりです。

統合の型 主な用途 始め方
Webサイト 既存のログイン画面にChatGPTを追加 クライアントIDの申請（待機リスト）
ChatGPTプラグイン プラグインの接続認可を簡単にする クライアントIDの申請（待機リスト）
OSS・ローカルアプリ 利用者のプランでAI処理を行う 初回サインインで動的に登録

クライアントIDの申請ページは、現時点で一部の商用パートナーに限って提供しており、参加希望は関心フォームから登録するよう案内しています。プラン利用の対象はPlusとProで、FreeやGoの利用者は使えません。

プラン利用対応12件とID連携のみ5社・OSS統合4件の公式一覧

利用者向けの公式ページが掲げる対応アプリは、2026年11月4日時点で次の3区分です。

  • プラン利用に対応：Amp Code、Conductor、Dactyl、Devin、Hermes Agent、Hyperagent、Kilo Code、Lovable（近日）、Notion、Vercel、Vorflux、Warp
  • ID連携のみ：Airtable、Canva、GitLab、HubSpot、Supabase
  • OSS統合：OpenClaw、OpenCode、Pi、T3

報道で「初期16社」とされた数は、プラン利用の12件とOSS統合の4件を足したものです。AIコーディングエージェントが大半を占めており、OSSのAIコーディングエージェントOpenCodeや常駐型エージェントのOpenClawの利用者は、APIキーを用意せずに手持ちのPlusやProで動かせるようになりました。

Webサイトへの組み込み手順：PKCE付き認可コードとIDトークン検証の実装

ここからは、クライアントIDを受け取った後の実装です。手順は公式の「On your website」ガイドに沿っています。

oaiapp_で始まるクライアントIDとdiscovery文書の4つのエンドポイント

申請が通ると、oaiapp_ で始まるクライアントIDと、環境ごとに登録したコールバックURLが確定します。発行者とエンドポイントはOpenAIのdiscovery文書から読み込みます。

curl -s https://auth.openai.com/.well-known/openid-configuration \
  | jq '{issuer, authorization_endpoint, token_endpoint, jwks_uri}'

本番の値は、発行者が https://auth.openai.com、認可が /api/accounts/authorize、トークンが /api/accounts/oauth/token、公開鍵が /.well-known/jwks.json です。公開クライアントと秘密鍵を持つ機密クライアントの両方に対応し、機密クライアントでもPKCEは外しません。

openid profile emailで認可URLを組み立てるNode.jsの実装例

サインインのたびに state、PKCEの検証子、nonce を新しく作り、サーバー側に10分の期限付きで保存します。PKCEの役割はPKCEによる認可コード横取り対策で詳しく扱いました。

import crypto from "node:crypto";

const authorizationEndpoint = "https://auth.openai.com/api/accounts/authorize";
const clientId = process.env.OPENAI_CLIENT_ID; // oaiapp_ で始まる値
const redirectUri = "https://example.com/auth/openai/callback";
const rand = (n = 32) => crypto.randomBytes(n).toString("base64url");

export function buildAuthorizationUrl(store, browserSessionId) {
  const state = rand();
  const codeVerifier = rand(64);
  const codeChallenge = crypto.createHash("sha256").update(codeVerifier).digest("base64url");
  const nonce = rand();
  // 検証子はブラウザに返さずサーバー側に保存する
  store.set(browserSessionId, { state, codeVerifier, nonce, expiresAt: Date.now() + 10 * 60 * 1000 });

  const url = new URL(authorizationEndpoint);
  url.search = new URLSearchParams({
    client_id: clientId,
    redirect_uri: redirectUri,
    response_type: "code",
    scope: "openid profile email",
    state,
    code_challenge: codeChallenge,
    code_challenge_method: "S256",
    nonce,
  }).toString();
  return url.toString();
}

ボタンのリンクには属性 data-oai-siwc-button を付けます。OpenAIが組み込みを確認し、不具合を調べるための目印です。ボタンの文言は「Continue with ChatGPT」か「Sign in with ChatGPT」で、他のログイン手段と同じ大きさで並べるよう求められています。

joseでIDトークンを検証しsub・発行者・クライアントIDで会員を紐づける規則

コールバックでは state を照合してから認可コードを交換し、返ってきたIDトークンの署名を公開鍵で検証します。JWTの構造と検証の考え方はJWTの署名検証の仕組み、IDトークン全般はOIDCのIDトークン検証手順が下敷きになります。

import { createRemoteJWKSet, jwtVerify } from "jose";

const issuer = "https://auth.openai.com";
const jwks = createRemoteJWKSet(new URL("https://auth.openai.com/.well-known/jwks.json"));

export async function verifyOpenAiIdentity(idToken, expectedNonce, clientId) {
  const { payload } = await jwtVerify(idToken, jwks, {
    issuer,
    audience: clientId,
    requiredClaims: ["sub", "exp", "iat"],
    clockTolerance: 5, // 時刻ずれの許容は数秒に留める
  });
  if (payload.nonce !== expectedNonce) throw new Error("nonce mismatch");
  // 会員の外部IDは issuer・clientId・sub の3つ組で持つ
  return { issuer, clientId, subject: payload.sub, sid: payload.sid ?? null };
}

会員との紐づけに使うのは、メールアドレスではなく、IDトークンで確認した sub です。公式ガイドも「メールアドレスの一致だけでは本人の証明にならない」と明記しており、既存会員と同じメールでも確認の手順を挟んでからつなぎます。アプリのセッションは自前で発行し、sid を残しておくと、OpenAIからのアカウント保護の通知で該当セッションだけを切れます。

OSSでChatGPTプランを推論に使う登録手順とResponses APIの呼び出し

次は、利用者の手元で動くツールにプラン利用を入れる流れです。公式の概要では、この経路を「ChatGPT plan usage」と呼んでいます。

OSSの初回登録とext_agent_host_idを事前に固定する理由

OSSの経路では、事前の申請なしに初回サインインでクライアントが登録されます。初回のクライアントID欄に指定する値は dynamic_agent_client です。登録とサインインのガイドが定める主なパラメータは次のとおりです。

パラメータ 初回 2回目以降
client_id dynamic_agent_client 発行済みのクライアントID
agent_name_hint アプリの正式名 送らない
ext_agent_host_id 端末ごとの固定値 同じ端末なら同じ値
redirect_uri 127.0.0.1の待ち受け ポート番号だけ変えてよい
resource Responses APIのURL 同じ

端末の識別子 ext_agent_host_id は、最初のサインインより前に作って保存しておきます。1つのクライアントIDの利用枠を、ノートPCと自前のVMなど複数の端末で共有するための値だからです。形式は公開鍵から作る RFC 9278 のURIが推奨で、urn:uuid: 付きのUUIDも使えます。メールアドレスなど個人を特定できる値は入れません。リダイレクト先に localhost を書くと一致しないので、127.0.0.1 を使います。

chatgpt.tokens.use.directの付与を確認して推論に進む条件

認可コードは、発行されたクライアントID、PKCEの検証子、同じ redirect_uri と resource を添えてトークンエンドポイントへ送ります。クライアントシークレットは要りません。

見落としやすいのが、許可されたスコープの確認です。利用者は同意画面でプラン利用だけを外せるため、IDトークンが正しくても推論の権限が無いことがあります。トークン応答の scope に chatgpt.tokens.use.direct が無ければ、サインインは保ったままプラン利用を「無効」と表示し、自分のAPIキーを使うなど別の支払い方法を選んでもらいます。OpenAIが黙って別の課金へ切り替えることはありません。

store false・stream trueを守るPython推論と完了イベント

推論は通常のResponses APIの窓口 https://api.openai.com/v1/responses に、アクセストークンをBearerとして送ります。公式の推論ガイドの例を、日本語の注記付きで示します。

pip install openai
export ACCESS_TOKEN="（保存したアクセストークンを読み込む）"
import os

from openai import OpenAI

client = OpenAI(
    api_key=os.environ["ACCESS_TOKEN"],  # APIキーの欄にOAuthのアクセストークンを渡す
    base_url="https://api.openai.com/v1",
    max_retries=0,
)

completed = False
with client.responses.create(
    model="gpt-6.1-sol",  # 実際は /v1/models で利用者のアカウントに出るモデルから選ぶ
    input=[{"role": "user", "content": "Say exactly: Hello, world!"}],
    store=False,  # この経路では必須
    stream=True,  # この経路では必須
) as stream:
    for event in stream:
        if event.type == "response.output_text.delta":
            print(event.delta, end="", flush=True)
        elif event.type == "response.failed":
            error = event.response.error
            raise RuntimeError(f"Response failed: {error.code if error else 'unknown_error'}")
        elif event.type == "response.completed":
            completed = True

if not completed:
    raise RuntimeError("response.completed を受け取る前にストリームが切れた")

成功と見なすのは response.completed を受け取ったときだけです。利用上限のエラーは、ストリームが始まった後に response.failed として届くことがあります。選べるモデルは利用者のプランで変わるため、モデル選択の画面は /v1/models の結果から作ります。例のモデルの位置づけはGPT-6 Solと6.1 Solの使い分けを参照してください。

1時間のアクセストークンと30日で回るリフレッシュトークンの保管方法

トークンの仕様では、アクセストークンの有効期限は1時間（expires_in: 3600）、リフレッシュトークンは30日です。更新のたびに新しいリフレッシュトークンが30日の期限付きで返り、古いものは使えなくなります。更新に成功したら、アクセストークン、期限、スコープ、リフレッシュトークンをまとめて書き換えます。

保存先はアプリ専用のディレクトリで、Unixなら所有者だけが読める 0600 にし、ログやリポジトリに出さないことが求められています。refresh_token_reused などで更新に失敗したら、保存済みのクライアントIDで再度サインインしてもらいます。公式のSign in with ChatGPT DevKitはOSの暗号化ストレージに保存する実装を含みますが、ライセンスは非商用です。

プレビュー版で使えない機能とエラーコード別の復旧・API課金との境界

プラン利用の経路は、通常のAPIキーで呼ぶResponses APIと同じ窓口でも、受け付ける内容が絞られています。

プレビューで使えない推論パラメータ・会話の引き継ぎ・ファイル検索

プレビューの制約として、2026年11月4日時点で次の項目が使えません。

  • リクエストの項目：temperature、top_p、max_output_tokens、metadata、background、user など15項目
  • 会話の引き継ぎ：HTTPでの previous_response_id（履歴は毎回 input に入れて送る）
  • ホスト型ツール：画像生成、ファイル検索、Code Interpreter、コンピューター操作、ホスト型MCP
  • 入力：音声と動画、ファイルのアップロードAPI、文字起こしAPI
  • メッセージ：role が system の項目（指示は instructions で渡す）

既存のコードを流用すると、ここで弾かれる例が多いはずです。とくに temperature を固定で送る実装と、previous_response_id で会話をつなぐ実装は書き換えが要ります。Chat CompletionsからResponses APIへの移行がまだなら、Responses APIとChat Completions APIの違いを先に済ませておくと手戻りが減ります。

subscription_sharing系エラーの429・403・503で分ける復旧処理

エラーと復旧のガイドから、処理を分けるべきコードを抜き出しました。表のコードはすべて先頭に subscription_sharing_ が付きます。

コードの後半 HTTP アプリ側の処理
usage_limit_exceeded 429 新規の推論を止め、使用量設定へ案内
user_not_eligible 403 対象外と伝え、再認可を繰り返さない
unsupported_capability 400 error.param の項目を外して再送
usage_unavailable 503 資格情報を残し、間隔を空けて再試行
invalid_user 401 要求IDを記録し、失効確定で再サインイン

429は「プラン全体を使い切った」とは限りません。利用者はChatGPTの設定でアプリごとに週の上限を総枠の何割と決められるため、アプリ単位の上限に当たっただけのこともあります。利用者がChatGPT側で連携を切っても、アプリには通知が来ません。一時的な通信エラーで資格情報を消さず、更新か推論で切断が確定したときだけ再サインインを求めます。

Sign in with ChatGPTの採否判断：APIキー課金と自前認証を残す条件

ここまでの仕様から、組み込んでよい場面と見送る場面を言い切ります。

利用者の手元で動くOSSのAIツールは今すぐ採用してよい条件

採用してよいのは、利用者のPCや自前のVMで動くOSSのAIツールで、推論がテキスト中心のものです。配布したツールを試してもらうたびにAPIキーの発行と課金設定を頼む手間が消え、推論費用も開発者に積み上がりません。temperature を使わない、ホスト型ツールに頼らない、という制約を受け入れられることが条件です。APIキー方式は残し、プラン利用が無効なときの代替として設定画面に並べておきます。

有料SaaS・サーバー常駐・SSO必須の業務システムは見送る場面

見送るのは3つの場面です。1つめは、自社の有料SaaSやサーバー側でプラン利用を使う計画で、待機リストの承認が無い限り対象外になります。2つめは、企業のシングルサインオンが前提の業務システムで、公式ガイドも既存のSSOへ誘導するよう求めています。3つめは、画像生成や音声入力、ファイル検索が機能の中心にあるアプリです。

この場合は、従来どおり自社のAPIキーで推論し、APIキーの発行・保管・失効の設計を固めるほうが確実です。ChatGPTのID連携をログインの選択肢に加える計画や、プラン利用とAPI課金を併用する設計を自社だけで判断しにくい場合は、生成AI導入支援で、認証基盤の現状確認から一緒に整理できます。

Sign in with ChatGPTの導入と利用でよくある質問と公式情報による回答

検討の段階でよく出る疑問に、2026年11月4日時点の公式情報で答えます。

ChatGPTの無料プランでもSign in with ChatGPTは使えますか？

サインインそのものはChatGPTのアカウントで行えます。ただし、プランの枠でアプリのAI処理を行う「プラン利用」の対象はPlusとProの利用者です。無料プランの利用者がプラン利用に対応したアプリを使う場合、AI処理はアプリ側の課金や、利用者自身のAPIキーなど別の方法でまかなうことになります。

アプリにChatGPTの会話履歴やメモリーは渡りますか？

渡りません。ID連携で渡るのは安定した識別子、名前、メールアドレス、プロフィール画像までです。プラン利用を許可しても、アプリが得るのはResponses APIを呼ぶ権限だけで、会話履歴やメモリーには届かないと公式に明記されています。

連携の解除やアプリごとの利用上限はどこで設定しますか？

設定の入口は、ChatGPTのアカウントにある「Settings」です。使用量は「Usage」で確認でき、「App limits」でアプリごとの週の上限を全体枠の割合で決められます。連携の解除は「Security and login」の「Sign in with ChatGPT」でアプリを選び、「Disconnect」を押します。上限は枠の確保ではなく上限値です。

自社の商用サービスに今すぐ導入できますか？

2026年11月4日時点では、申請が通った一部の商用パートナーだけが対象です。公式の関心フォームから待機リストに登録し、承認後にクライアントIDを受け取ります。有料のアプリや遠隔でホストするアプリでプラン利用を提供する場合も、同じく事前の承認が要ります。

APIキー方式と比べて開発者が負担する費用はどう変わりますか？

プラン利用で処理した分は利用者のChatGPTプランの使用量に数えられ、開発者のAPI請求には載りません。その代わり、上限に達すると推論は止まり、OpenAIが自動でAPI課金へ切り替えることもありません。アプリ独自の料金は別に設定でき、対応するプランを料金ページで明示するよう求められています。

関連記事

お気に入りに入れた記事の一覧

一創の公式 SNS

X では毎朝の新着記事と IT ニュースの速報を、YouTube・TikTok・Instagram・LinkedIn・Facebook では記事の解説動画を配信しています。

この記事に関連するサービス

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.11.03　テックブログ ノジマ不正アクセスで約700万件漏えい：対象確認・窓口と乗っ取り注文を止める実装
  2. 2026.10.29　テックブログ ソニー生命の情報漏洩38.5万件｜ログインできない理由、再開状況と窓口の電話番号
  3. 2026.11.03　テックブログ クラブツーリズム不正アクセス：約432万件の対象確認と偽メールの見分け方・流出検知の設計
  4. 2026.11.02　テックブログ アララの不正アクセス：メール約7,700万件の持ち出しと契約企業が行うAPIキー再設定・代替送信・連名報告
  5. 2026.11.02　テックブログ サントリーの不正アクセスで約10万人分漏えい｜M365のファイル大量ダウンロードを監査ログで調べる手順

RELATED POSTS 関連記事

一覧へ戻る

目次