OpenAI新セキュリティ設定でChatGPTとCodex運用はどう変わるか
#OpenAI Akira 公開: 更新: 9分で読める

OpenAI新セキュリティ設定でChatGPTとCodex運用はどう変わるか

解説レベル

目次

OpenAIが 2026年4月30日 に公開した Advanced Account Security は、派手な新モデルではない。しかし、日本の開発組織や情報システム部門にとっては、むしろこういう更新のほうが実務に効く。理由は単純で、ChatGPTやCodexの利用が広がるほど、会社として正式導入したSSO付き環境だけでなく、個人アカウント起点の利用 が残りやすいからだ。

今回の更新は、その個人アカウント利用に対して、OpenAIが一段強い保護をまとめて提供し始めたという意味を持つ。公式発表によれば、Advanced Account Securityを有効にすると、パスワード型ログインを止め、passkeysや物理セキュリティキー中心へ切り替え、標準のメール/SMS復旧も無効化 する。しかも、この保護は ChatGPT だけでなく Codex にも適用 される。

日本企業で重要なのは、これが単なる「便利なセキュリティ設定」ではなく、復旧責任と運用責任を利用者側へ寄せる設計 だという点だ。サポートへ頼る前提の運用から、事前に復旧鍵と複数の認証手段を管理する運用へ変わる。以下では、まず事実を整理し、そのうえで日本の開発チームと情シスがどう見るべきかを考える。

事実: 4月30日に何が公開されたのか

OpenAIの公式発表によると、Advanced Account Securityは ChatGPTアカウント向けの任意設定 として提供が始まった。公開日は 2026年4月30日。対象はデジタル攻撃リスクが高い利用者や、より強い保護を求める利用者で、OpenAIはジャーナリスト、研究者、政治関係者、セキュリティ意識の高いユーザーを代表例として挙げている。

ただし、実務的に見ると対象はそれだけではない。ChatGPTの会話履歴、接続済みツール、Codexで扱うコードや端末操作文脈は、企業にとって十分に高感度だ。日本でも、業務の一部を個人アカウント上のChatGPTやCodexで先に試し、その後に正式導入へ進む流れは珍しくない。そのため今回の更新は、個人利用者だけでなく、企業の周辺で先にAIを使い始める開発者層 にも関係がある。

公式発表で明記された主な変更は4つある。

  • passkeys か physical security keys を必須化し、パスワード型ログインを止める
  • 標準のメール/SMSアカウント復旧を止め、より強い回復手段へ寄せる
  • セッションを短くし、ログイン通知とセッション可視化を強める
  • 会話のモデル学習利用を自動で除外する

さらにOpenAIは、この保護が Codex にも及ぶ と説明している。つまり、ChatGPTだけ堅くしてCodexは従来どおり、という分離ではない。同じログインを使う範囲全体の防御を上げる設計だ。

事実: 何が変わるのか

一番大きい変化は、認証方式の前提が変わる ことだ。OpenAIはAdvanced Account Securityで、phishing-resistant authentication を標準に近づけると説明している。ログインは passkeys か FIDO準拠のセキュリティキーが中心になり、パスワード単体へ戻る逃げ道が狭くなる。

Help Centerの案内では、登録時に 少なくとも2つの強いサインイン手段 が必要で、そのうち1つはデバイスをまたいで使える必要がある。たとえば、passkey とハードウェアキーの組み合わせ、あるいは複数の互換passkeyの組み合わせが想定されている。ここで重要なのは、単に「passkeyを1つ追加すれば終わり」ではないことだ。冗長化された認証手段を前提にしている

復旧についても変化が大きい。公式説明では、標準の email / SMS based recovery を止め、代わりに backup passkeys、security keys、recovery keys を使う。Help Centerでは、セットアップ時に recovery keys を保存する必要があり、それを失うと恒久的にアカウントへ戻れないリスクがあると明示されている。さらに、Advanced Account Security有効中は、OpenAI Supportが通常のメール復旧、パスワードリセット、ログイン手段の付け替えで救済しない

運用面では、セッション時間が短くなり、ログイン通知が有効になり、アクティブセッションを確認しやすくなる。OpenAIは、アカウント侵害時の露出時間を短くする狙いを明示している。個人利用では少し面倒に見えるが、企業運用では「共有端末に残ったセッション」「自宅PCに残った旧セッション」「退職・異動時の消し残し」への効き目がある。

もう1つ実務的に重要なのが、学習利用の自動除外 だ。OpenAIは、高感度情報を扱う人向けに、Advanced Account Security有効時は会話がモデル学習に使われない設定になると説明している。これは日本企業にとって、データ取り扱い説明のしやすさに直結する。

事実: 誰が今すぐ影響を受けるのか

ここで見落としやすいのが、利用者区分による差だ。Help Centerでは、Advanced Account Securityは eligible personal ChatGPT accounts 向けであり、ChatGPT Enterprise、enterprise-managed accounts、enterprise-managed domain に関連付くアカウントでは使えない とされている。つまり、企業の正式管理下にあるアカウントの統制機能を直接置き換えるものではない。

一方で、公式発表にはもう1つ重要な記述がある。Trusted Access for Cyber の個人メンバーは 2026年6月1日 から Advanced Account Security を必須化 される。組織単位では、SSO側で phishing-resistant authentication を備えていると証明できれば代替可能だが、個人ベースではより厳しくなる。これは、OpenAIが高権限・高能力モデルへのアクセス管理を、本人確認と認証強度まで含めて見始めたことを示している。

OpenAIのGPT-5.4-Cyber関連記事で見たように、防御用途向けの高能力モデルは価値が高い一方で、アカウント奪取時の影響も大きい。今回の更新は、その入口側の統制を強める一手として自然につながる。

分析: 日本企業で残りやすいのは「SSO外の先行利用」

ここからは分析だ。

日本企業でChatGPTやCodexの統制が難しくなるのは、正式導入済みのEnterprise環境だけではない。実際には、PoC、試作、検証、少人数チームの改善活動の中で、個人契約や個人アカウント利用が先に走る ことが多い。しかも、そこではコード、障害ログ、顧客問い合わせ要約、議事メモのような高感度情報が扱われやすい。

この構図は、OpenAIのPrivacy Filter関連記事が示した「クラウドへ送る前の前処理」問題とつながっている。前処理を整えても、入口のアカウントが弱ければ十分ではない。さらに、OpenAIの証明書更新関連記事で見たように、AIツール周辺はソフトウェア供給網や端末認証の問題と切り離せない。今回のAASは、その中でも アカウント乗っ取り に正面から手を入れた更新だと言える。

特に日本の情シスが気にすべきなのは、「導入していないつもりでも、もう使われている」パターンだ。セキュリティレビュー前の個人利用は完全には止めにくい。ならば少なくとも、どの利用者にAASを勧めるか、復旧鍵をどう保管するか、退職・異動時にどの端末セッションを確認するか を先に決めておくほうが現実的だ。

分析: 開発チームは利便性より復旧設計を先に決めるべき

開発チーム目線での争点は、「強い認証を入れるか」より 復旧をどう回すか だろう。AASでは、メールやSMSで気軽に戻す前提がなくなる。つまり、強化した瞬間に、認証強度だけでなく 鍵管理の失敗コスト も上がる。

日本の開発組織で実務的に決めるべき点は少なくとも4つある。

  • passkeyをどの端末系に保存するか
  • 物理キーを誰が何本持つか
  • recovery key をどこに保管するか
  • 退職・異動・端末紛失時の復旧手順をどう定義するか

ここを曖昧にしたままAASだけ有効化すると、「安全になったが誰も戻れない」事故が起きる。特に、個人アカウントでCodexを業務利用しているケースでは、担当者の端末紛失と同時に作業履歴や連携ワークフローへアクセス不能になる可能性がある。

逆に言えば、AASは 本気で使う利用者を炙り出す仕組み としても見られる。物理キーと復旧鍵まで管理する意思があるユーザーだけが高感度用途へ進む、という境界線を引きやすいからだ。

まとめ

OpenAIのAdvanced Account Securityは、2026年4月30日に公開された ChatGPTとCodex向けの強化認証・強化復旧設定 だ。passkeysやセキュリティキーを前提にし、メール/SMS復旧を止め、セッション管理を強化し、会話の学習利用も自動除外する。見た目以上に、アカウント防御の思想を変える更新と言える。

日本企業にとってのポイントは、Enterprise統制の外に残る個人アカウント利用をどう扱うかだろう。AASは、その領域のリスクを下げる有力な選択肢だが、同時に 復旧責任を利用者側へ寄せる。導入判断は「便利かどうか」ではなく、誰に適用し、鍵をどう持たせ、事故時にどう戻すかまで含めて考えるべきだ。

出典