AIアカウントをパスキーで守る：高権限ユーザーから始める乗っ取り対策

先に結論：AIアカウントのMFAは「有効か」ではなく「方式」で見る

この記事では、ChatGPTなどのAIサービス、開発者向けコンソール、AIエージェントの管理画面を乗っ取りから守るために、次のことが分かります。

SMSや認証アプリを設定しただけでは防げないフィッシングがある
パスキーと物理的なセキュリティキーは、何が同じで何が違うのか
全社員へ一斉導入する前に、どのアカウントから強化すべきか
鍵や端末の紛失で業務を止めないために、何を準備すべきか
認証を強化した後も、なぜ既存セッションやAPIキーの確認が必要なのか

結論は、AIサービスの管理者、請求管理者、APIキーを発行できる人、外部サービスを接続できる人から、フィッシング耐性のある認証へ移行することです。ただし、パスキーを1個登録して終わりではありません。予備の認証手段、復旧手順、既存セッションの棚卸し、退職・異動時の無効化までを一つの運用として設計する必要があります。

ここでいう「フィッシング耐性」は、利用者が偽サイトを見抜けることではありません。偽サイトへ誘導されても、そのサイトでは正規サービス用の認証情報を原理的に使いにくくする性質を指します。

なぜ今、AIアカウントの認証を見直すのか

OpenAIは2026年8月10日、高度なサイバー防御能力を提供するDaybreakについて、個人アカウントへ2026年9月1日からハードウェアセキュリティキーを必須化すると発表しました。OpenAIの発表で対象になっているのはDaybreakの個人アカウントであり、すべてのChatGPT利用者に対する一律の義務化ではありません。

それでも、この変更は一般企業にも重要な示唆を与えます。AIの能力が高くなり、コード、社内文書、クラウドサービス、顧客対応システムなどと接続されるほど、「AIへのログイン」は単にチャット履歴を見るための入口ではなくなります。侵害されたアカウントが持つ権限によっては、機密情報の閲覧、API利用、設定変更、外部連携の悪用につながるからです。

同じ時期の2026年8月3日には、IPAが企業組織を狙う攻撃メールの手口とその対策を公開しました。この資料は、偽サイトへID、パスワード、ワンタイムパスワードを順番に入力させ、その場で正規サイトへ中継する「リアルタイムフィッシング」を説明しています。また、攻撃者が利用者と正規サイトの間に入るAiTM攻撃では、認証後のセッションクッキーが窃取され、不正ログインにつながる可能性も示されています。

つまり、現在の論点は「MFAを設定しているか」だけではありません。

どのMFA方式を使っているか
弱い方式へ迂回できないか
認証後のセッションを管理できているか
紛失時の復旧経路が新しい弱点になっていないか

この4点をまとめて確認する必要があります。

SMSやワンタイムパスワードでは足りない場面

MFAには複数の方式がありますが、攻撃への強さは同じではありません。

方式	利用者の操作	フィッシング耐性	主な注意点
SMS・メールのコード	届いた数字を入力	低い	偽サイトへの入力、通信経路やメールアカウントの侵害に注意
認証アプリのワンタイムコード	アプリの数字を入力	低い	リアルタイムで偽サイトから正規サイトへ転送され得る
プッシュ承認	通知を承認	方式による	内容を見ずに承認する「MFA疲労」や誤承認に注意
同期型パスキー	端末のPINや生体認証で解除	高い	個人端末、共有端末、同期先アカウントの管理が必要
端末固定型パスキー	登録端末上で解除	高い	端末故障や交換に備えた復旧手段が必要
ハードウェアセキュリティキー	USB、NFCなどで鍵を使用	高い	紛失、携帯忘れ、予備鍵の保管方法を決める必要

NIST SP 800-63B-4は、利用者が認証コードを手入力するOTP方式をフィッシング耐性のある認証とは見なしていません。偽サイトが入力されたコードを正規サイトへ中継できるためです。

一方、WebAuthnを使う認証では、公開鍵資格情報が登録先のサービス、より正確にはRP IDと呼ばれる識別子へ結び付けられます。偽サイトは正規サイト用の資格情報をそのまま要求して利用できません。NISTは、FIDO2で使われるWebAuthnを、認証先の名前との結び付けによってフィッシング耐性を実現する例として挙げています。

重要なのは、「利用者がURLを注意深く見るから安全」なのではない点です。注意力だけに依存せず、認証プロトコル側で利用先を制限することに価値があります。

パスキーとハードウェアセキュリティキーを混同しない

パスキーは、WebAuthnなどに基づく公開鍵資格情報を使いやすくした認証方式です。秘密鍵は利用者側の認証器に保持され、サービス側は対応する公開鍵を使って認証を検証します。

ただし、「パスキー」という表示だけでは、鍵がどこに保存され、どの範囲へ同期されるかまでは分かりません。

同期型パスキー

スマートフォンやパソコンの資格情報管理機能を通じ、複数端末で利用できるタイプです。端末交換時の復旧がしやすく、一般社員への展開にも向いています。その一方で、個人所有端末へ業務用パスキーを保存してよいか、同期先アカウントを組織が管理できるか、退職時に確実に利用を止められるかを確認する必要があります。

端末固定型パスキー

特定のパソコンやスマートフォン内の認証器に保持されるタイプです。同期範囲を狭くできますが、その端末を紛失、故障、初期化した場合の復旧経路が欠かせません。

ハードウェアセキュリティキー

USBやNFCなどで接続する独立した物理デバイスへ鍵を保持します。端末と資格情報を分離でき、管理者や高権限利用者に向いています。NISTは、同期可能な認証器の鍵をエクスポート可能として扱う一方、専用デバイスや保護されたハードウェア環境から秘密鍵を取り出せない構成を、より高い保証に使える非エクスポート型として区別しています。

ただし、「物理キーだから無条件に安全」という意味ではありません。登録時に偽の管理画面を使っていた、端末がマルウェアに感染している、既存セッションがすでに奪われている、復旧窓口が弱い本人確認だけで鍵を解除する、といった問題は別に残ります。

W3CのWeb Authentication Level 3も、安全性を得る前提として、登録を安全に完了すること、秘密鍵が認証器で保護されること、サービス側がオリジンを正しく検証することなどを挙げています。認証器だけでなく、サービス側の実装と登録手順を含めた安全性だと理解する必要があります。

AIアカウントを4段階に分けて導入順を決める

全員へ同じ日に物理キーを配ると、登録ミスや問い合わせが集中し、業務を止める可能性があります。AI活用ナビでは、まずアカウントが持つ権限で4段階に分けることを勧めます。これは公的基準の引用ではなく、一次情報を実務へ落とし込むための編集部による判断基準です。

優先度	アカウントの例	推奨する対応
最優先	組織管理者、請求管理者、SSO管理者、APIキー発行者	ハードウェアキーまたは組織管理可能な端末固定型パスキーを優先。予備手段も登録
高	コード実行、外部サービス接続、機密データ参照が可能な利用者	フィッシング耐性のある認証を必須化し、接続先とセッションを定期確認
中	社内資料を扱う一般利用者	組織管理された同期型パスキーを含め、利用環境に合う方式へ段階移行
低	機密情報や外部連携を持たない検証専用アカウント	少なくともMFAを有効化し、共有や使い回しを避ける

「最優先」の判定は、役職ではなく操作可能範囲で行います。現場担当者でもAPIキーの作成、コネクター追加、データのエクスポート、ユーザー招待ができるなら、高権限アカウントです。

また、AIサービスそのものだけを見てはいけません。Google、Microsoft、AppleなどのアカウントでAIサービスへログインしている場合、実際の認証境界はそのIDプロバイダー側にあります。SSOを使っている組織では、AIサービス側のMFA画面ではなく、SSO側の条件付きアクセスや認証ポリシーを確認します。

導入手順：設定前の棚卸しから復旧テストまで

1. 対象アカウントを列挙する

最低限、次を一覧にします。

AIサービス名とワークスペース名
所有者と実際の利用者
ログイン方式（直接、Google、Microsoft、Apple、SAML、OIDCなど）
管理者権限、請求権限、APIキー発行権限
接続済みアプリ、コード実行、データ参照の有無
現在のMFA方式
退職・休職・異動時の停止担当者

個人が作ったアカウントを組織の正式運用へ流用している場合は、個人メールアドレス、個人端末、個人の同期アカウントへ依存していないかも確認します。

2. 認証を実際に処理する場所を確認する

AIサービスへメールアドレスとパスワードで直接ログインしているのか、外部IDでログインしているのかを区別します。MFAは認証を処理する側で強制しなければなりません。

「AIサービス側でMFAを設定したつもりだが、SSO経由では別のポリシーが適用される」「一部ユーザーだけ従来の直接ログインが残っている」といった迂回経路がないか確認します。

3. 管理者からパスキーまたは物理キーを登録する

いきなり既存MFAを削除せず、新しい方式を追加してログインを試します。登録はメールやチャットに届いたリンクからではなく、保存済みブックマーク、正式な管理ポータル、公式アプリから開始します。

OpenAIアカウントでは、利用できる方式が端末、国、契約、アカウント作成方法によって異なると公式MFAヘルプに記載されています。認証アプリ、プッシュ通知、SMSまたはWhatsApp、パスキーなどが候補として案内されていますが、すべての利用者に同じ選択肢が表示されるとは限りません。

4. 主認証器と予備手段を分ける

高権限アカウントでは、主認証器だけでなく、紛失や故障に備えた予備を準備します。例えば、日常携帯する物理キーと、施錠された場所に保管する予備キーを分けます。

予備キーを机の同じ引き出しへ入れると、盗難や災害で同時に失う可能性があります。反対に、誰も取り出せない場所へ保管すると緊急時に使えません。保管責任者、持ち出し条件、利用記録、返却確認まで決めます。

5. 復旧手段を先に検証する

復旧コードや復旧キーが発行される場合は、通常のパスワード管理領域とは分けて保管します。画面のスクリーンショットを個人の写真クラウドへ置いたり、自分宛てのメールへ送ったりすると、認証器とは別の弱い経路が生まれます。

OpenAIの公式ヘルプでは、Advanced Account Securityを利用し、パスキーやセキュリティキーへアクセスできなくなった場合、復旧キーを使う手順が案内されています。利用中のサービスで同様の仕組みがあるか、復旧操作の権限者は誰か、サポート窓口による解除条件は何かを確認してください。

登録後は、普段使っていないブラウザーや別端末からテストログインします。主認証器、予備認証器、復旧手段をそれぞれ試し、「登録できた」ではなく「業務を再開できる」ことを確認します。

6. 弱い代替経路を減らす

パスキーを登録しても、SMSだけでログインや復旧ができるなら、攻撃者は弱い経路を狙います。ただし、代替手段を一度に削除するとロックアウトの危険があります。

次の順序が安全です。

新しい認証器を複数登録する
別端末から成功を確認する
復旧手順をテストする
管理者またはヘルプデスクが対応できることを確認する
不要なSMS、OTP、古い端末を削除する

契約やサービスの仕様上、弱い方式を無効化できない場合は、その事実をリスク台帳へ残し、重要操作時の再承認、アクセス元制限、セッション時間の短縮など別の統制で補います。

7. 既存セッションと接続を確認する

認証方式を強化しても、すでに作成済みのセッションが自動的にすべて無効になるとは限りません。設定変更後は、ログイン中の端末、接続済みアプリ、発行済みAPIキー、個人アクセストークンなどを別々に点検します。

ChatGPTでは、設定のSecurityからActive sessionsを開き、ブラウザーや公式アプリのセッション、端末情報、概算位置、サインイン日時などを確認できます。ただし、OpenAIのセッション管理ヘルプによると、第三者アプリ、接続済みアプリ、「Sign in with ChatGPT」だけを使った第三者サービス、Codex CLIのセッションはこの一覧に表示されません。SSO連携アカウントではActive sessions自体が利用できない場合もあります。

したがって、「セッション一覧に不審な端末がない」ことは、すべての接続が安全である証明にはなりません。AIサービス、SSO、API管理画面、接続先アプリを分けて確認します。

8. 強制適用と例外管理へ進む

少人数で登録、ログイン、紛失、端末交換、退職処理を試した後、対象グループを広げます。例外を認める場合は、対象者、理由、代替対策、承認者、終了日を記録します。「設定できなかったので無期限でSMSを許可する」という状態を残さないことが重要です。

よくある失敗と対策

パスキーを共有端末へ作成する

共有パソコンにパスキーを登録すると、その端末を解除できる別の利用者がアカウントへ入れる可能性があります。個人へ割り当てられ、画面ロックと端末管理が適切な機器へ登録します。

物理キーを1本だけ配る

安全性は上がっても、紛失や故障で管理者が業務から締め出されます。予備キーまたは同等に管理された復旧手段を用意し、実際に使えるかテストします。

管理者アカウントを複数人で共有する

共有すると、誰が登録した認証器か、誰が設定を変えたか、退職者がアクセスできるかを追跡しにくくなります。利用者ごとのアカウントと権限付与を基本にします。

MFAを有効にしたのでセッションを放置する

セッションクッキーや端末がすでに侵害されている場合、新しい認証方式だけでは追い出せません。不審時は全セッションの失効、パスワード変更、APIキーの再発行、接続アプリの解除を組み合わせます。

利用者教育だけで防ごうとする

「怪しいURLを見抜く」教育は必要ですが、IPAが説明するリアルタイムフィッシングやAiTMは、本物に近い画面と自然な手順で認証を中継します。注意力を補助する技術的対策として、フィッシング耐性のある認証を導入します。

復旧窓口が本人のメールだけを確認する

メールアカウントも同時に侵害されていれば、攻撃者が復旧を申請できます。高権限アカウントの復旧では、別経路の本人確認、管理者承認、変更通知、操作記録を組み合わせます。

パスキーだけでは防げないもの

パスキーやセキュリティキーは重要ですが、万能ではありません。次のリスクには別の対策が必要です。

ログイン済み端末に感染したマルウェア
ブラウザー拡張機能などによるセッション情報の窃取
正規アカウントへログインした利用者自身の誤操作
AIエージェントへ与えた過大な権限
APIキーやアクセストークンの漏えい
接続済みアプリや委託先サービスの侵害
弱い本人確認によるアカウント復旧
共有端末の画面ロック解除情報の共有

認証強化は「入口」の防御です。ログイン後にできる操作を減らす最小権限、重要操作の人間承認、監査ログ、セッション失効、端末保護を併用してください。

不審なログインが疑われる場合の初動

通常の導入作業ではなく、すでに侵害が疑われる場合は、次の順で対応します。

可能であれば、信頼できる別端末から管理画面へアクセスする
不審なセッションと、必要に応じて全セッションを失効する
パスワードを使っている場合は、使い回していない新しい値へ変更する
登録済みMFA、パスキー、復旧先に不審な追加がないか確認する
APIキー、個人アクセストークン、接続アプリを無効化または再発行する
管理者、請求、ユーザー招待、データ共有などの変更履歴を確認する
組織のインシデント対応担当へ連絡し、影響範囲を記録する
必要に応じてサービス提供者へ調査を依頼する

慌ててアカウントそのものを削除すると、調査に必要なログや設定を失う可能性があります。組織のインシデント対応手順がある場合は、そちらを優先してください。

導入判断チェックリスト

アカウントと権限

AIサービスとSSOの管理者を特定した
APIキー、請求、接続アプリを管理できる利用者を特定した
共有アカウントを個人別アカウントへ分けた
退職・異動時の停止担当者を決めた

認証方式

現在のMFAがSMS、OTP、パスキーのどれか確認した
管理者からフィッシング耐性のある方式へ移行した
SSOと直接ログインの両方に迂回経路がないか確認した
弱い代替方式を残す理由と終了日を記録した

紛失と復旧

主認証器とは別に予備手段を用意した
復旧キーを通常の端末やメールと分離して保管した
別端末からのログインをテストした
ヘルプデスクの本人確認と承認手順を決めた

セッションと継続運用

登録済み端末とアクティブセッションを確認した
接続済みアプリとAPIキーを別に棚卸しした
不審時に全セッションを失効できる担当者がいる
四半期ごと、または権限変更時に再確認する予定を入れた

確認できた事実と、編集部の判断を分ける

一次情報で確認できた事実は次のとおりです。

OpenAIはDaybreakの個人アカウントについて、2026年9月1日からハードウェアセキュリティキーを必須化すると発表した
OpenAIアカウントでは複数のMFA方式が案内されているが、利用可能な方式は環境やアカウントによって異なる
IPAは、ワンタイムパスワードをリアルタイムで窃取する手口と、AiTMによるセッションクッキー窃取を説明している
NISTは、手入力するOTPをフィッシング耐性のある認証とは見なしていない
WebAuthnは公開鍵資格情報を登録先へ結び付ける仕組みを持つ
ChatGPTのActive sessionsだけでは、第三者アプリやCodex CLIを含むすべての接続を確認できない

一方、「管理者から移行する」「主キーと予備キーを分ける」「4段階の優先度で展開する」「四半期ごとに棚卸しする」という手順は、これらの一次情報を基にしたAI活用ナビ独自の運用提案です。各組織の端末管理、SSO、就業規則、委託先管理に合わせて調整してください。

まとめ

AIアカウントの保護では、MFAの有無だけで安心せず、フィッシングに耐えられる方式かを確認することが重要です。まず管理者、APIキー発行者、請求管理者、外部連携を追加できる利用者からパスキーまたはハードウェアセキュリティキーへ移行します。

同時に、予備の認証器、復旧手順、既存セッション、APIキー、接続済みアプリを確認してください。認証器を強くしても、弱い復旧経路や奪われたセッションを残せば、そこが次の入口になります。

本記事の情報確認日は2026年8月21日です。主要な一次情報として、OpenAIのDaybreak発表とMFA・セッション管理ヘルプ、IPAの攻撃メール対策資料、NIST SP 800-63B-4の公式掲載ページ、W3CのWebAuthn仕様を確認しました。サービスごとの対応方式や管理画面は変更される可能性があるため、実際の設定時には各サービスの最新ヘルプも再確認してください。

PRIMARY SOURCES