1Password for Agentsとは何か──AIエージェントにパスワードを渡さずログインさせる仕組みと限界
1Passwordは2026年10月22日（現地時間）、AIエージェントにパスワードを見せずにWebサイトへサインインさせる「1Password for Agents」を発表しました。エージェントが保管庫（Vault）の認証情報の利用をリクエストし、本人が自分の端末で承認すると、1Password自身がログインフォームへパスワードやワンタイムコードを直接入力します。エージェントが受け取るのは「ログインできた」という結果だけです。
ただし、この仕組みが守るのは「パスワードそのもの」であって「ログイン後の操作」ではありません。何が解決され、何が残るのかを先に押さえたうえで、どのアカウントから試すかを決めるのが現実的な使い方です。
発表内容の要点
提供元はカナダのAgileBits（事業名: 1Password）です。公式ブログによると、現時点の対象は1Password.com上のIndividualおよびFamilyアカウントで、追加料金はかかりません。1Password.euおよび1Password.caでホストされているアカウントは現時点では対象外です。
連携先は段階的な展開です。公式ブログの記載では、MetaのMuseとSpaceXSIのGrok Botが「数日のうちに全プラットフォームへ展開」、AnthropicのClaude Duet、OpenAIのChatGPT Workとdots、Town Townie（WebとiOS）が「近日提供」とされています。さらにInstinct、Browserbase、Browser Use、Dana、KERNEL、Perplexity、Ramp、Tomo、Wajoとの連携も予定されています。利用できる端末・機能・提供時期は連携先ごとに異なると明記されているため、「発表された＝今すぐ使える」ではない点に注意が必要です。
パスワードを渡さずにログインできる理由
この機能は「Agentic Autofill」と呼ばれる仕組みに基づいています。公式の製品ページのFAQによると、流れは次のとおりです。
- エージェントがサインインフォームに到達し、固有のデジタルキーで自分の身元を1Passwordに示す
- 本人の端末に、どの認証情報が何のために必要かを示した承認画面が出る
- 承認すると、1Passwordがパスワードやワンタイムコードをログインフォームへ直接入力する
- エージェントは認証済みのセッションの中で作業を続ける
従来、エージェントにログインを任せる方法は「途中で人が代わって手入力する」か「プロンプトにパスワードを貼る」かの二択でした。後者はモデルのコンテキストや会話履歴、ログに認証情報の写しが残り、依頼した作業の範囲を超えて使われうる状態になります。Agentic Autofillはこの経路を断つための設計です。公式FAQは、エージェントを連携しても保管庫全体にアクセスできるわけではなく、他の保存済み項目はエンドツーエンド暗号化で保護されたままだとしています。連携は任意で、いつでも解除できます。
守られるもの、守られないもの
重要なのは、保護対象が「再利用可能な秘密情報」に限られることです。1Password自身のFAQも、サインイン後はエージェントがそのアカウント内で情報を閲覧したり操作したりしうると説明しています。航空会社のアカウントへのログインを承認すれば、そのアカウントでできることは原則としてエージェントにもできます。
ここから導かれる注意点は三つあります。第一に、承認の単位は「エージェントに1Passwordを使わせるか」ではなく「このエージェントに、このログインを、この作業のために使わせるか」であるべきです。第二に、承認が求められる頻度は連携先によって異なるため、承認画面が習慣化して内容を読まずにタップする「承認疲れ」が起きやすくなります。第三に、Webページの内容を通じてエージェントの挙動を誘導するプロンプトインジェクションは、パスワードを知らなくてもログイン後の操作に影響しうる問題として残ります。
つまり、この機能は認証情報の漏えい対策としては明確な前進ですが、権限設計の代わりにはなりません。決済手段が登録されたアカウント、管理者権限を持つアカウント、パスワード再設定の起点になるメールアカウントは、仕組みに慣れるまで対象から外す判断が妥当です。
仕事で使う場合に確認すべきこと
今回のプラットフォームは個人向けアカウントが対象です。業務アカウントで同種の仕組みを使う場合は、別の確認が要ります。1Passwordの開発者向けドキュメントでは、1Password Businessアカウントの利用者がAgentic Autofillを使うには、管理者が「Allow AI Agents to autofill for users」というポリシーを有効にする必要があるとされています。クラウドブラウザ上で動くエージェント向けには、Browserbaseとの統合が文書化されており、1Passwordデスクトップアプリとの間にエンドツーエンド暗号化されたチャネルを確立し、自動入力のたびに承認プロンプトを出す設計になっています。
一方、ブラウザのログイン画面を経由しない用途、たとえばCIやサーバー上で動くエージェントがAPIキーを使うケースは、この仕組みの守備範囲ではありません。そこでは短命のトークン、ワークロード単位の識別、スコープを絞ったシークレット管理といった別の手段が適切です。1Passwordも開発者向けに、シークレットを平文で渡さずにエージェントへ供給する手段を別建てで用意しています。
選択肢は1Passwordだけではありません。Bitwardenは2026年3月、エージェントがパスワードマネージャーから認証情報を取得するためのオープンプロトコル「Agent Access SDK」をApache 2.0で公開しています。ジャストインタイムのアクセス、エンドツーエンド暗号化、人による承認という考え方は共通ですが、公式には早期アルファ段階で、本番の認証情報運用には推奨しないと明示されています。評価目的で触るには向きますが、業務導入の前提にはできません。
試す前に決めておく四つのこと
実際に使い始めるなら、次の順で判断すると迷いが減ります。
- 前提の確認: 自分のアカウントが1Password.com上のIndividualまたはFamilyか。1password.euや1password.caのアカウントは現時点で対象外です
- 連携先の確認: 使いたいエージェントの連携が「提供中」か「近日」か。公式の連携一覧で状態を確認し、未提供なら通知登録にとどめる
- 最初のアカウント選び: 閲覧や下調べが中心で、失敗しても取り返しがつくアカウントから始める。二要素認証は切らず、ワンタイムコードも1Password側に入力させる
- 終わらせ方の確認: 連携解除の手順に加え、サービス側のセッション管理やサインアウト機能で、作業後にアクセスが残っていないかを確かめる
承認画面に出る「どのアカウントを、何のために使うのか」を毎回読むこと自体が、この仕組みの価値を支えています。逆に言えば、読まずに通す運用になった時点で、パスワードをプロンプトに貼るのと変わらないリスクに近づきます。
1Password for Agentsは、AIエージェントへの認証情報の渡し方を「秘密を共有する」から「ログインを都度許可する」へ変える試みです。まずは自分のアカウント種別と使いたいエージェントの提供状況を公式ページで確認し、影響の小さいアカウント一つで承認の流れを体験してみるところから始めてください。
