本記事は元々 blog.logto.io に掲載されたものです。
想像してみてください：あなたが AI エージェントにフライトを予約したり、メールをチェックしたり、CRM を更新するよう依頼します。そのためには、あなたのオンラインアカウントへアクセスする必要があります。しかし、どうすれば毎回パスワードを聞かれずに安全にログインできるでしょうか？
エージェントはユーザーに代わって多くのタスクを処理できます。それには、ウェブサイトやデータベース、外部APIなど、サードパーティのサービスへアクセスするケースが多くなります。エージェントがこれらのサービスにプログラム的に接続する場合もありますが、多くの場合、従来のログイン方法やユーザー操作が必要なタスクが残っています。
前回の記事では、特にブラウザがユーザー認証情報を管理する際に生じるセキュリティリスクについて議論しましたが、これには新たな脆弱性が生じる場合があります。 https://blog.logto.io/agent-auth#chatgpt-operator-agent-auth-experience
この流れはセキュリティの懸念を引き起こしますが、その一方でユーザーにとっての利便性も無視できません。利便性とセキュリティの間のこのジレンマは、さらなる技術的な探究に値するテーマとなっています。
この記事では、私が「ブラウザベースのログインと認証」と呼ぶ課題に対し、いくつかのエージェントが既にどのように取り組んでいるのかを探っていきます。
Manus がこの問題にどのようにアプローチしているのか、どんなリスクが残っているのか、そして今後エージェントが活躍する環境における認証の未来について詳しく見ていきましょう。
Manusのアプローチ：「一度ログインして、そのまま維持」
Manus は クラウドブラウザ という機能を設計しました。これは、完全にクラウド上で動作するリモートのサンドボックス型コンピューターです。あなたのエージェント専用のウェブブラウザだと考えてください。一番の特徴は、デバイスやタスクをまたいでもログイン状態を保持できる点です。
仕組みは以下の通りです：
- クラウドブラウザ内のウェブサイトに手動でログインします。各サイトごとに一度だけ必要です。
- Manus がセッションデータ（Cookieやローカルストレージなど、ログインを維持するための情報）をキャプチャします。
- **そのデータはローカル→クラウドの2段階で暗号化されます。**何も平文のまま保存されません。
- **エージェントが再びそのサイトにアクセスする時、Manus がセッションを新しいサンドボックスに自動注入します。**そのウェブサイトはあなたがまだログインしていると認識します。
- デバイス間で同期でき、設定からいつでも手動でセッションデータを消去可能です。
これは、あなたのエージェントに「どこでも使えるが、自分の密室でしか効かない」セキュアなキーを渡しているようなものです。
ローカルブラウザ（例：Chrome）とエージェント駆動のクラウドブラウザ
疑問が浮かぶかもしれません：「これって Chrome を使う場合と同じでは？なぜエージェント駆動型のクラウドブラウザはリスクが高いように聞こえるのか？」
- なぜ Chrome に認証情報を預けるのは一般的に安全なのか
- なぜエージェント駆動型ブラウザに預けるのはリスクにつながるのか
- それぞれの文脈で「ファーストパーティー（第一者）」と「サードパーティー（第三者）」は誰なのか
本質的な違い：ローカルブラウザ vs エージェント・クラウドブラウザ
| 観点 | ローカルブラウザ（例：Chrome） | 一般的なエージェントクラウドブラウザ |
|---|---|---|
| 場所 | あなたの端末上で動作 | クラウド上でリモート実行 |
| コントロール | 完全にあなたのコントロール下 | コードやAIエージェントが制御 |
| UI フィードバック | 直接操作（フォームやオートフィルのプロンプトなどが明示的） | 一部UIはあるが、多くの操作はエージェントが自動で実行 |
| ストレージ | OSレベルの暗号化（例：macOS キーチェーン）で安全に保存 | 認証情報やCookieがメモリ/ログに保存されリスク高 |
| セキュリティ境界 | OS＋ブラウザのサンドボックスで保護 | 独自の分離が必要、エージェントが悪用・リークした場合脆弱 |
| 信頼モデル | Chrome を信頼＝あなた自身で直接使う前提 | エージェントの開発者が正しく対策するかどうかに頼る |
Chrome にユーザー名とパスワードを渡す方が安全な理由
-
あなたがオペレーター
Chrome は ファーストパーティインターフェース で、あなたが直接制御し、何をしているか可視化されており、端末環境の一部です。パスワード入力の意図も明確で、オートフィルのプロンプトも監査可能です。 -
強固な統合型セキュリティ
Chrome などのブラウザはパスワードを OS のセキュアストレージ（例：生体認証や端末ログインが必要）に保存します。オートフィルも予期した範囲（ドメイン一致等）でのみ動作します。 -
最小限の委譲
Chrome に「ずっと」パスワードを預けるわけではありません。あなたが明示的に許可した入力内容を 記憶 するだけで、主体はあなた自身です。
エージェントクラウドブラウザが抱えるリスク
-
ユーザーの視界外で代理操作
クラウドブラウザはプログラムで制御されます。認証情報を渡すと、UIや直接のフィードバックなしに あなたに代わって ログイン操作を実行します。可視性・アカウンタビリティのギャップが生じます。 -
保存リスク
プレーンテキストでエージェントに渡した場合、ログやキャッシュ、メモリ上に残る可能性あり。厳格なアクセス制御がなければ重大な脆弱性に。 -
不明確な信頼境界
サービスプロバイダーを信頼する必要がありますが、Chrome とは異なり OS レベルや物理的なプロテクションはありません。サーバー侵害・実装ミスで流出のリスクがあります。
ファーストパーティー vs サードパーティー
「ファーストパーティ」と「サードパーティ」は何か、なぜ Chrome はファーストパーティとして扱われ、エージェント型クラウドブラウザはそうでないのかを分解してみましょう。
| 役割 | Chrome | エージェントクラウドブラウザ |
|---|---|---|
| あなた（ユーザー） | ファーストパーティーオペレーター | 認証情報の持ち主 |
| ブラウザ/アプリ | ファーストパーティー（直接操作） | サードパーティー代理人（あなたの代理） |
| 認証情報管理者 | OS＋Chrome（緊密なローカルトラストチェーン） | 外部エージェントサービス（緩い信頼境界） |
| 保管場所 | OSレベル保護によるローカル保存 | クラウドサーバーやバックエンドでのリモート保存 |
Chrome にパスワードを渡しても安心できるのは、「あなた が あなた自身 で入力し、あなた の端末・OSの重層防御下で実行されるから」。Google もサーバーにパスワードを保存しません。
一方、Manus は次のように説明しています：
ログイン情報は暗号化済みファイル群として弊社ストレージサーバへ安全にアップロードされます。これには以下が含まれます：
- Cookie
- ローカルストレージ
つまり、ログイン情報は Manus のバックエンドサーバーに保管されます。ユーザーとして、エージェント開発者を信頼する必要があり、それは標準的なセキュリティベストプラクティスに完全には一致しません。
認証情報をエージェント制御のクラウドブラウザに渡すのは、権限の委譲です。たとえ手動利用でも、サービス側から見ればサードパーティです。他人のインフラ、セキュリティ対策、倫理基準に依存するため、信頼・安全リスクが発生します。
このような場合、プログラム的なプロトコルによるセキュリティ施策が必須であり、ブランドや会社の約束だけに頼るべきではありません。
Manus の強み（と潜在的な問題）
上手く機能している点：
- 本当にシームレスなセッション：デバイスが変わっても毎回ログインし直す必要なし。
- ユーザーファーストなセキュリティ：全工程エンドツーエンド暗号化、ユーザーが保管内容を完全コントロール可能。
- 透明性・リスペクト重視：Manus はログインデータを学習や分析目的で使用しません。
まだ注意が必要な点：
- リプレイ攻撃：もし誰かがセッションファイルを盗んだ場合、なりすましが可能になる。
- フィンガープリント不一致：一部サイトは高度な指紋認証でログイン端末と紐付けており、サンドボックスでのリプレイが破綻するケース。
- CAPTCHA 回避不可：セキュリティの厳しいサードパーティサイトでは、Cloud Browser からのユーザー操作が bot と見なされ、CAPTCHA を通過できないことも。
- データコンプライアンス：セッションが国境やデバイスをまたいで移動すると、プライバシーや規制上の懸念点が。
- システムへの信頼：データ保護の暗号鍵は極めて堅牢かつ厳重に管理される必要。
その他のエージェントによるログイン手法
Manus は賢いアプローチを提供していますが、それが唯一の方法ではありません。他にもエージェントがユーザー代理でログインする一般的な方法を見ていきましょう：
認証情報を「入力」する
一番シンプルなのは、エージェントが人間と同じようにユーザー名・パスワードを入力する方式です。実装は容易ですが、認証情報が漏洩した場合、誰でもアカウントにアクセスできてしまうため非常に危険です。そのため大半の開発者はこの手法を回避します。
この方式では、ボールトやシークレットマネージャのようなツールで Cookie や認証情報を安全に扱うことで追加の保護層を設ける場合が多いです。
OAuth トークン
委譲アクセスのゴールドスタンダードです。OAuth フローでユーザーがエージェントを認可し、限定的かついつでも無効にできるトークンを付与。セキュアで細かい権限設定・即時取り消しが可能。ただし対応サイト限定です。
その他のプログラム的手法（例：APIキー）
一部サービスは API キーなどプログラム利用向けの認証情報を発行しています。パスワード入力より安全ですが、広範な権限を持つ場合が多く、キー管理の厳格化が必要です。
どの手法も利便性と安全性のトレードオフです。Manus のセッションリプレイは、多くのケースで OAuth より柔軟ですが、本質的な安全性では劣ります。
理想的には、Manus が特定サイト（例：番号付きリストとしてサイト追加）と事前統合しておき、ユーザーの事前同意で OAuth トークンを利用できる仕様になれば、認証情報保存やセッションリプレイ不要で安全運用が実現します。
この先の展望：エージェントは「信頼できる専門職」へ
エージェントの高度化に伴い、「人間のふり」をやめて、より巧妙な認証方式が求められていきます。
今後目指す方向は：
- APIファーストアクセス：クリック操作ではなく、トークン付き API 呼び出し中心へ。
- 短期間・限定的な権限付与：「神モード」トークン撤廃、必要最小限・短期間のみ使用。
- ハードウェアベースのセキュリティ：セッションデータはソフトウェアボールトだけでなくセキュアエンクレーブにも保存。
- ユーザー所有の認証情報ボールト：トークン/鍵/セッションの「ウォレット」をユーザーが管理し、信頼したエージェントだけに共有。
要は：「便利な bot」から「認可されたオペレーター」へと進化し、それに見合った認証基盤が求められる時代になります。
ボールト（Vault）とは？なぜ重要か？
もしここまでの管理が煩雑に思えたなら...私は、「ブラウザ自動化の普及に伴い、専門で安全な認証情報・セッション管理ツールの併用が不可欠」だと考えます。
それが Vault や 暗号鍵管理（EKM） のようなツールの役目です。
Vault は シークレットマネジメントソリューション であり、チームに次の機能を提供します：
- トークン、APIキー、認証情報を安全に保管
- 必要に応じて短期間・動的な認証情報を発行
- アクセス権の細分化・完全な監査記録
- シークレットの自動ローテーション・瞬時のアクセス取り消し
- CI/CD やクラウドアプリとの統合
エージェント社会において、Vault は認証情報セキュリティの「頭脳」となります。エージェントは Vault からリクエストし、パスワード自体は決して保持しません。仮に何かが漏洩しても、トークンはすぐ失効し本当の鍵は守られます。
最後に
Manus は「ユーザー主導・安全なセッションリプレイ」を実装し、エージェントログインの新しい地平を切り開いています。素晴らしい一歩ですが、ログインフローは依然として繊細です。リプレイ攻撃やサンドボックスの仕様、鍵管理といった懸念事項は引き続き注視が必要です。
未来は明確です：エージェントの活躍範囲は拡大しますが、安全に機能するには認証基盤が必須です。Vault のようなツールは、秘密情報管理だけでなく、信頼確立にも要となるでしょう。
あなたの AI があなたのデジタルライフの「鍵」を持つとき、その「鍵を誰が何のために、どれだけの間渡したのか」まで、きちんと分かる必要があります。
Logto は、サードパーティ API トークンを安全に保管できる Vault 機能を導入しています。 これにより、Google 等のソーシャルアカウントやリモート MCP サーバーなど外部サービスへのエージェントの安全なアクセスが可能です。将来的には ユーザー認証情報や鍵・パスワード等さらに広範なデータも保管対応予定です。
さらに、Logto は 完全な 認証・認可・アイデンティティ管理プラットフォーム です。もし AI エージェントをゼロから開発するなら、Logto は AI 開発者のための認証基盤 として、セキュリティ・柔軟性・インフラをワンストップで提供します。