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