AppleはWWDC26にて、iOS 27・iPadOS 27・macOS 27向けの「Apple Intelligence」新機能を発表した。Passwordsアプリが侵害または脆弱なパスワードを検知すると、AIエージェントが自動的に対象サイトへアクセスし、パスワードを新しい強力なものに変更・保存する——その一連の作業をユーザーに代わって完結させる。なお本稿執筆時点（2026年6月）では開発者ベータ版であり、セキュリティアーキテクチャの詳細や承認モデルは完全には公開されていない。
「警告で終わらせない」という設計思想
従来のパスワード管理ツールは「侵害を検知→警告を表示→ユーザーが対応」という流れだった。問題は最後のステップだ。パスワード変更は設定画面が深い階層に隠れていたり、追加認証が挟まったりと手間がかかる。40件の警告が並んでいれば大半は先送りされる——研究でも繰り返し確認されている事実だ。
Apple Intelligenceの新機能はこの「警告が行動につながらない問題」に正面から挑む。パスワードの変更権限をエージェントに委ねることで、侵害された認証情報が使われ続けるリスクを圧縮しようという発想だ。処理の進行状況はLive Activityとしてリアルタイムに表示される。
NISTのDigital Identity Guidelinesも、侵害の証拠がある場合にはパスワード変更を強制し、パスワードマネージャーの利用を許可することを推奨しており、Appleのアプローチはこの方向性と一致している。
AIエージェントに認証情報を委ねるリスク
セキュリティ上の懸念は複数ある。
プロンプトインジェクション攻撃が最も深刻だ。悪意を持つウェブページに埋め込まれた隠しテキストが「パスワードを攻撃者の指定した値に変更せよ」とエージェントに指示した場合、そのまま実行されるリスクを排除できない。オープンウェブはAIエージェントが動作する環境として最も信頼性が低い部類に入る。
アカウントのロックアウトも現実的なリスクだ。変更処理がネットワーク断やサイト側のレート制限、独自の二要素認証フローなどで途中失敗した場合、旧パスワードは無効化されながら新パスワードも保存されないという最悪の状態になりうる。
同意モデルと取り消し可能性の設計も問われる。処理の途中でユーザーが中止を望んだとき安全に停止できるか。自動変更後に「やっぱり戻したい」という状況への対応は用意されているか。これらはまだ公開情報では確認できない。
デバイス侵害時のリスクも見落とせない。端末そのものが侵害されている場合、AIエージェントが生成した強力なパスワードも含め、すべての認証情報が攻撃者の手に渡りうる。
実務への影響：IT管理者が今確認すべきこと
エンドユーザー向け 秋の正式リリースまでに、自分が使うサービスでこの機能がどう動作するかを把握しておきたい。特に処理失敗時のリカバリー手順と、どのサービスが自動変更に対応しているかの確認が先決だ。
企業・IT管理者向け BYODデバイスや個人所有のMacでこの機能が動作した場合、業務アカウントが影響を受ける可能性がある。MDMポリシーによる機能制御の可否、および企業SSOや多要素認証（Microsoft Entra IDやOkta等）との相互作用について、Appleからの詳細ドキュメントを待ちつつ、セルフサービスパスワードリセットポリシーとの兼ね合いも事前に整理しておくことを勧める。
筆者の見解
AIエージェントが自律的に動作して人間の作業コストを削減するという方向性には価値があると思っている。「警告を出して終わり」の設計が限界を迎えていることは明白で、パスワード変更という具体的なアクションまで完結させることには実用的な意味がある。
一方で、認証情報は「システムへの鍵」だ。このドメインにエージェントを持ち込むには、プロンプトインジェクション対策、失敗時のロールバック設計、ユーザーへの透明な権限委譲モデルが揃っていることが前提になる。エージェントに「判断する権限」を与えることと、「取り消せない変更を行う権限」を与えることは同じではない。
設計次第では本物の安全改善につながるし、穴があれば大きな事故になる。開発者ベータを経て正式リリースまでに、Appleがセキュリティアーキテクチャをどこまで公開し、外部研究者による検証を受け入れるかが焦点になる。秋のリリースまでにその透明性が確保されるかどうか、注視していきたい。
出典: この記事は Apple’s AI Can Now Change Your Passwords. What Could Possibly Go Wrong? の内容をもとに、筆者の見解を加えて独自に執筆したものです。