【新発表】1Password for Agentsをやさしく解説：AIにパスワードを渡さずログインを任せる

執筆している2026年10月24日時点の情報です。1Password for Agents は発表直後のため、最新情報は必ず公開情報（本記事末尾の参考リンク）もあわせてご確認ください。

本稿は、1Passwordの公式発表・製品ページ・公開ドキュメントをもとに整理したものです。実機検証は行っていません。依頼文や利用シーンは、説明のために作成した架空の例です。

1. AIに仕事を頼みたい。でも、パスワードは教えたくない

AIに、こんな仕事を頼めたら便利ですよね。

• 旅行の予約内容を確認し、予定を整理してほしい。
• イベントの準備に必要なサービスを操作してほしい。
• ログインが必要なサイトから、必要な情報を集めてほしい。

ところが、AIがログイン画面にたどり着き、必要な認証ができなければ、そこで作業が止まることがあります。

「ここから先は自分のアカウントが必要。でも、チャット欄にパスワードを貼って大丈夫なのだろうか」

毎回、自分で操作を引き継いでログインするのは手間です。一方、パスワードをそのまま渡すと、秘密情報のコピーをAI側に持たせることになります。

この困りごとに対応するため、2026年10月22日に発表されたのが、1Password for Agentsです。

一言でいうと、**「対応するAIエージェントに、パスワードを見せずに、利用者が承認したログインを行わせる仕組み」**です。

ここでいうAIエージェントとは、質問に答えるだけでなく、サイトやツールを操作して作業を進めるAIのことです。1Password自身が新しい汎用AIアシスタントになった、という発表ではありません。

参考情報

• Introducing 1Password for Agents
• 1Password for Agents Launches as the Trust Layer for Personal AI Agents

2. この記事で分かること

• 1Password for Agentsで、何が変わるのか
• パスワードをAIに見せずにログインする流れ
• 対応するエージェントと、利用できるアカウント
• 使い始める前に確認すること
• 「ログインを許可する」と「何でも任せる」が違う理由

主な読者は、AIエージェントを使い始めた方、1Passwordの利用者、業務での活用を検討するIT担当者です。専門的な内部実装ではなく、利用者が理解しておきたい仕組みと判断ポイントを中心に説明します。

3. 何が発表されたのか

まず押さえたい基本情報

項目	公式情報で確認できた内容
製品名	1Password for Agents
発表日	2026年10月22日。公式プレスリリースの日付
できること	対応するAIエージェントのサインインを、パスワードなどの秘密情報をエージェントへ見せずに仲介する
対象アカウント	1Password.com上の個人・家族向けアカウント。公式ブログではIndividual・Familyと表記
追加料金	上記の対象アカウントでは追加料金なしと案内
現時点の制限	1Password.eu・1Password.caのアカウントは未対応
提供範囲	利用できる端末・機能・開始時期は、連携先によって異なる

「追加料金なし」は、対象プランでの1Password for Agentsについての説明です。1Passwordの基本契約や、連携先AIサービスまで、すべて無料になるという意味ではありません。

また、.com・.eu・.caはアカウントのホスト先に関する条件です。日本に住んでいるかどうかだけで判断せず、自分のアカウントのサインイン先を確認します。

どのAIエージェントと連携するのか

公式ブログに記載された主な連携先を整理すると、次のとおりです。これは10月22日の発表内容であり、すべての利用者がすでに使えるという意味ではありません。

連携先	発表時点の案内
MetaのMuse	数日かけて全プラットフォームへ展開
Grok Bot	数日かけて全プラットフォームへ展開
AnthropicのClaude Duet	今後提供予定
OpenAIのChatGPT Work・dots	今後提供予定
TownのTownie	Web・iOS向けに今後提供予定

ほかに、Instinct、Browserbase、Browser Use、Dana、KERNEL、Perplexity、Ramp、Tomo、Wajoとの連携も、今後提供予定として挙げられています。

大切なのは、「連携先として発表された」と「手元の環境で今すぐ利用できる」を分けることです。製品ページには、対応を待つエージェントについて通知登録・waitlistの案内もあります。利用したい連携のカードと、エージェント側の最新案内を確認してください。

なお、本稿で参照した発表資料では、Microsoft 365 Copilot、Copilot Cowork、GitHub Copilotとの連携は確認できませんでした。「AIエージェント向けだから、どのCopilotでも使える」という意味ではありません。

参考情報

• Introducing 1Password for Agents
• 1Password for Agents Launches as the Trust Layer for Personal AI Agents
• 1Password for Agents: Secure AI Password Manager | 1Password

4. 仕組みをやさしく説明すると、「鍵を渡す」より「扉を開ける許可を出す」

三つの役割で考える

登場するもの	役割
利用者	どのアカウントへのログインを許可するか判断する
AIエージェント	依頼された作業を進め、必要になったログインを要求する
1Password	ログイン情報を保管し、承認されたサインインを仲介する

従来の「パスワードをチャットに貼る」方法では、AI側へ秘密の値を渡していました。

今回の連携では、AIへ鍵のコピーを渡すのではなく、必要な扉を開けてよいか、自分が判断するイメージです。

ログインまでの流れ

公式発表と製品ページでは、次のように説明されています。

1. AIが、ログイン画面に到達する。
   作業を続けるために必要なログインを、1Passwordへ要求します。
2. 1Passwordが、要求元のエージェントを確認する。
   公式プレスリリースでは、エージェントが固有のデジタルキーで身元を示すと説明されています。
3. 利用者が、自分の端末で要求を確認する。
   どのログイン情報が必要で、なぜ必要なのかを見て、承認するか拒否するかを選びます。候補が複数ある場合は、使うログインを選べます。
4. 1Passwordが、ログイン先のフォームへ直接入力する。
   パスワードやワンタイムコードを自動入力し、エージェントには秘密の値を見せないと説明されています。
5. ログイン後、AIが作業を続ける。
   AIがパスワードそのものを受け取るのではなく、サインインした状態で依頼された作業を進めます。

製品ページでは、このように対応エージェントがブラウザーでサインインする仕組みを、Agentic Autofillという名称でも説明しています。

なお、「デジタルキーで身元を示す」という説明は、利用者が1PasswordのSecret Keyをチャットへ貼る手順ではありません。アカウントパスワードやSecret Keyを、AIへの依頼文に含めないようにします。

1Passwordの保管庫を、丸ごと見せるわけではない

公式FAQでは、エージェントを接続しても、保管庫全体へのアクセスを与えるわけではないと説明されています。

エージェントは作業に必要なログインを要求し、利用者がその要求を承認するか判断します。ほかの保存済みパスワードは、引き続き保護されます。

また、接続は任意です。エージェントを接続しなければ、従来どおり1Passwordを使い続けられます。

ただし、承認を求められる頻度は連携によって異なります。「毎回必ず同じ画面が出る」「一度許可すれば永久に無確認」といった共通仕様を、ここから推測しないことが大切です。

参考情報

• Introducing 1Password for Agents
• 1Password for Agents Launches as the Trust Layer for Personal AI Agents
• 1Password for Agents: Secure AI Password Manager | 1Password

5. どんな場面で便利なのか

以下は、仕組みを理解するための架空の利用シーンです。特定サイトでの対応や、実行結果を保証するものではありません。

場面	まず任せたいこと	最初は任せないこと
旅行の準備	予約内容を確認し、予定を整理する	予約変更、キャンセル、追加購入
イベントの準備	案内文や備品候補をまとめる	招待状の送信、商品の注文
業務利用の検証	テストサイトのダミー請求情報を要約する	本番データの更新、外部送信、支払い

期待できるのは、ログインで止まるたびにパスワードを渡したり、別の場所にコピーしたりする必要を減らせることです。ただし、作業が中断しなくなることや、すべてのサイトで動くことを保証するものではありません。

依頼するときは、「してよいこと」と「しないこと」を書く

たとえば、イベントの準備なら、次のように依頼することが考えられます。これは筆者が作成した依頼例です。

週末の交流会に向けて、招待ページの構成案と備品の候補をまとめてください。
ログインが必要になったら、対応している1Password連携で確認を求めてください。
私が選んだ検証用アカウントだけを使ってください。
招待状の送信、参加者情報の登録、商品の注文は行わないでください。
結果は、この会話に案としてまとめてください。

ポイントは、ログインの許可と、送信・購入の許可を分けていることです。

ただし、依頼文は権限制御そのものではありません。可能であれば、サイト側でも閲覧専用など、必要最小限の権限に絞ります。

業務で試す場合は、組織が利用を認めたサービスとアカウント構成かを先に確認します。個人・家族向けの案内を、企業向けプランの利用条件へそのまま読み替えたり、会社の認証情報を未承認の個人向け保管庫へ移したりしないようにします。

6. 使い始める前に確認したい六つのこと

ここでは、公開情報に基づく共通の流れと、筆者が提案する確認事項をまとめます。具体的なボタン名や画面配置は、連携ごとの公式手順で確認してください。

1. アカウントが対象になっているか

個人・家族向けの対象アカウントであることと、ホスト先が1Password.comであることを確認します。

1Password.eu・1Password.caは、執筆時点では未対応です。利用のために安易に移行するのではなく、契約やデータの扱い、組織の方針を確認します。

2. 使いたいエージェントが、すでに対応しているか

製品ページの連携カードを確認し、展開中なのか、今後提供予定なのかを見ます。必要な端末、アプリ、地域、サインイン方法、AIサービス側の利用条件も、個別の案内で確認します。

3. 公式の連携手順を使っているか

対応エージェントと1Passwordの正式な案内に沿って接続します。

任意のブラウザー拡張やMCPサーバー、自作スクリプトを追加すれば、今回と同じ保護が得られる、という話ではありません。公開資料で確認できない共通メニュー名や接続用コマンドも、本稿では補って紹介しません。

4. 承認する前に、要求内容を確認できるか

画面や連携先の案内から、次を確認します。

• 自分が依頼したエージェントからの要求か。
• 予定しているサイト・サービスへのログインか。
• 選ぶアカウントは正しいか。
• その作業に、本当にログインが必要か。

必要な情報が分からない場合や、不自然な要求の場合は、承認せず確認します。

5. 低リスクな環境で、承認と拒否を試したか

最初は、機密情報や決済権限を持たない検証用アカウントを使うことを提案します。

試すこと	確認したい結果
意図したログインを選んで承認する	正しいアカウントで作業が続く
不要な要求を拒否する	拒否した要求による新規ログインが成立しない
会話と取得可能な実行記録を見る	パスワードやワンタイムコードが平文で出力されていない
作業後にサイト側を確認する	依頼していない送信・注文・更新がない

拒否の試験では、以前のログイン状態が残っていないかも確認します。すでにあるセッションで操作できた結果を、新しいログインが許可された結果と混同しないためです。

6. 使い終わった後の解除方法が分かるか

公式ブログでは、連携をいつでも切断できると説明されています。

ただし、連携の解除と、ログイン先サービスに残るログイン状態の終了は、分けて確認する項目です。解除操作が既存のセッションへいつ、どう反映されるかは、本稿では検証していません。

連携の解除方法に加えて、ログイン先のセッション管理も確認しておくと、試行を終えるところまで整理できます。

参考情報

• Introducing 1Password for Agents
• 1Password for Agents: Secure AI Password Manager | 1Password

7. いちばん大切：「ログインしてよい」と「何をしてもよい」は違う

たとえば、AIに旅行サイトへのログインを許可したとしても、それだけで予約の変更やキャンセルまで許可したつもりにはならないはずです。

ここでは、三つの判断を分けて考えます。

判断すること	例	主に確認する仕組み
どこへログインしてよいか	この旅行サイトの、このアカウントを使ってよい	1Passwordと対応エージェントの連携
どの情報を見てよいか	予約履歴や個人情報を、どこまで見られるか	サイト側のアカウント権限
何を実行してよいか	予約変更、キャンセル、購入をしてよいか	エージェント側の制御とサイト側の権限・承認

「AIにパスワードを見せない」と「AIにアカウント内の情報を見せない」は、同じではありません。

ログイン後の作業でAIがページを読むなら、その情報がAIサービスでどのように処理・保存されるのかも確認が必要です。

また、1Passwordでログインを承認する仕組みがあっても、送信や購入の直前に必ず追加承認が入る、と今回の資料から結論づけることはできません。必要な操作承認は、エージェントと利用先サービスで別に確認します。

開発者向け：CLIやService Accountsと同じものなのか

既存の1Password機能と混同しないよう、用途も整理しておきます。

仕組み	主な用途
1Password for Agents	対応エージェントのサインインを、秘密の値を見せずに仲介する
1Password CLI	ターミナルから項目を操作し、アプリや設定へシークレットを注入する
1Password Service Accounts	個人ユーザーにひも付かない認証で、許可された保管庫やEnvironmentをアプリ・インフラ・CI/CDなどから利用する

CLIで取得した秘密の値を、そのままAIの入力へ渡してしまえば、「1Passwordに保存していた」というだけで、AIから隠されるわけではありません。

これはCLIやService Accountsが危険という意味ではなく、目的と実装が違うという話です。自作エージェントにCLIを使わせることと、今回発表された正式な連携を使うことは、同じではありません。

業務導入では、認証情報の保護だけでなく、利用するAIサービスの許可、アカウント権限、情報の扱い、操作承認、履歴、解除方法を一緒に確認することを提案します。

参考情報

• Introducing 1Password for Agents
• 1Password for Agents: Secure AI Password Manager | 1Password
• 1Password CLI
• 1Password Service Accounts

8. よくある疑問と、発表直後の注意点

Q. どのAIツールでも使えるのか

いいえ。公式FAQでは、対応する個人向け・コーディングエージェントとの連携で動作し、すべてのAIツールに対応するわけではないと説明されています。

同じ会社の製品でも、すべてのプランや実行モードが対象とは限りません。連携ごとの要件を確認します。

Q. 多要素認証やパスキーにも、すべて対応するのか

パスワードやワンタイムコードをエージェントに見せずに扱う説明はあります。

ただし、それだけで、すべての多要素認証、パスキー、セキュリティキー、SSO、追加の本人確認画面へ対応するとまでは言えません。公式FAQも、サインイン方法によって要件が変わるとしています。

必要な認証方式で動くかは、個別の連携で確認が必要です。

Q. パスワードを見せないなら、完全に安全なのか

秘密情報をAIへ直接渡すリスクを減らす設計ですが、それだけですべての問題が解決するわけではありません。

• ログイン先で何を操作できるか。
• AIに読ませてよい情報か。
• 依頼していない送信や更新を防げるか。
• 不適切なページ上の指示に、どう対応するか。

こうした点は、別に評価します。また、「AIにパスワードを見せない」という説明を、「すべての処理が自分のPC内だけで完結する」と読み替えないようにします。

Q. 一度承認すれば、あとはすべて無人実行できるのか

承認を求められる頻度は連携によって異なります。

承認の有効期間、再利用の条件、セッションの寿命、再認証の条件について、本稿で参照した資料だけでは、全連携に共通する具体的な仕様を確認できませんでした。

Q. 会社のアカウントでも、そのまま導入できるのか

本稿で確認した利用条件は、1Password.com上の個人・家族向けアカウントについての案内です。Teams・Businessアカウントの具体的な提供条件や、組織向け管理機能までは確認できませんでした。

業務で検討する場合は、契約、管理設定、利用先の規約、社内ルールを確認してください。1Passwordがログインを仲介することだけを理由に、AIの全操作が一つの監査ログへ記録されると推測することも避けます。

なお、実際の接続・承認・拒否・解除、日本語表示、端末・地域別の詳細な提供状況、本稿の架空の依頼文による実行結果は未検証です。未確認であることと、必ず利用できないことは区別しています。

参考情報

• Introducing 1Password for Agents
• 1Password for Agents: Secure AI Password Manager | 1Password

9. まとめ：AIへパスワードを教えるのではなく、必要なログインを許可する

1Password for Agentsは、AIが実際のサービスで作業するときの「ログインをどう任せるか」に対応する、新しいプラットフォームです。

覚えておきたいのは、次の四つです。

1. パスワードをチャットに貼らない。 対応する連携では、1Passwordが秘密の値を見せずにサインインを仲介する。
2. 使える条件を確認する。 対象アカウント、ホスト先、エージェント、提供時期は一律ではない。
3. ログインと操作を分ける。 ログインを許可したからといって、送信・購入・更新まで任せてよいわけではない。
4. 最初は小さく試す。 低リスクなアカウントとダミーデータで、承認から解除まで確認する。

AIに任せられる仕事が増えるほど、**「どのアカウントを、誰の判断で、どこまで使わせるか」**が大切になります。

今回の発表は、その判断をパスワードの受け渡しに頼らず行うための、一つの選択肢として捉えると分かりやすいと思います。

参考リンク

以下はすべて1Passwordが公開している一次資料です。確認日は2026年10月24日です。資料の公開日と、各エージェントへの提供開始日・展開完了日は区別しています。

• Introducing 1Password for Agents
  提供元：1Password Blog。公開・更新日：2026年10月22日（ページの公開日時・更新日時のメタデータで確認）。第1・3・4・6・7・8章で、発表内容、連携別の提供予定、対象アカウント、追加料金、ホスト先の制限、保護の考え方と解除を確認。
• 1Password for Agents Launches as the Trust Layer for Personal AI Agents
  提供元：1Password公式プレスリリース。公開日：2026年10月22日午前9時、米国東部夏時間。第1・3・4章で、発表日、製品の位置づけ、要求元の身元確認、本人の端末での承認とサインインの流れを確認。
• 1Password for Agents: Secure AI Password Manager | 1Password
  提供元：1Password製品ページ。公開・更新日は確認できず。第3・4・6・7・8章で、Agentic Autofill、連携カード、通知登録、対象プラン、保管庫全体を公開しないこと、承認頻度と対応条件が連携ごとに異なることを確認。
• 1Password CLI
  提供元：1Password開発者向けドキュメント。公開・更新日は確認できず。第7章で、ターミナルからの利用、項目操作、シークレット注入などの用途を確認。
• 1Password Service Accounts
  提供元：1Password開発者向けドキュメント。公開・更新日は確認できず。第7章で、個人にひも付かない認証、保管庫・Environmentと操作の制御、アプリ・インフラ・CI/CDでの用途を確認。

本記事について

本記事は、公開情報をもとに内容を整理し、できるだけ分かりやすく解説することを目的として作成しています。記載内容は個人の見解であり、所属組織の公式見解を示すものではありません。少しでもお役に立てればうれしいです。

ご質問・追記要望は本ページのコメント欄までお寄せください。