1Password for Claudeとは──AIエージェントに「パスワードを見せずに」ログインさせるゼロ露出設計¶
対象 / ポイント
対象: ブラウザー操作型AIを業務利用する中級のインフラ/セキュリティ担当者
ポイント:
- パスワードとワンタイムコードはモデルやAnthropicのシステムへ渡らない
- 解放は要求ごとの人間承認で、資格情報はセッション単位の鍵により保護される
- 保護範囲はログインまでであり、ログイン後の誤操作や侵害端末は別に対策が要る
2026年7月16日、1PasswordはAnthropicとの提携による「1Password for Claude」を公開した。1 Claudeがログインページに到達すると、1Passwordが資格情報をページへ直接入力する。 パスワードもワンタイムコードも、モデルのコンテキストやメモリ、Anthropicのシステムには入らない。
この記事の問いは1つだ。「パスワードを見せない」は、ブラウザー操作型AIのどこまでを安全にするのか。 公開された技術設計を追うと、秘密値の受け渡しは厳密に分離されている。 一方、ログイン後のエージェント行動まで安全になるわけではない。
「渡すか、自分で入力するか」の二択を崩す¶
1Password for Claudeの価値は、エージェントに資格情報の値ではなく、利用権だけを渡す点にある。
従来、エージェントがログインページに着いた後は、秘密値を会話へ貼り付けるか、作業を引き取る必要があった。 前者はモデルが秘密値を読める状態を作り、後者は自動化を中断する。 1Passwordは「使わせるが、見せない」という第三の経路を追加した。1
1PasswordのCTOであるNancy Wang氏は、Claudeに必要なのはログインを使ったという事実であり、 パスワードやワンタイムコードそのものではないと説明している。1 これはパスワード保管機能の追加というより、秘密の保有と権限の行使を分ける設計だ。
では、秘密値がページに入る瞬間はどう守られるのか。
動作フロー──秘密値が存在する間はClaudeを止める¶
最大の特徴は、資格情報がページ上に存在する間、Claudeがページを読まないことだ。
Claudeがログイン用アイテムを要求
→ 1Passwordアプリケーションで対象と理由を確認し、承認または拒否
→ 承認したアイテムを暗号化チャネルで拡張機能へ送信
→ Claudeを停止し、1Passwordが入力・送信・成否確認
→ 成功後に再開/失敗時は入力値を消去してから再開
承認画面では、提案されたアイテムを別のログインへ差し替えることも、要求を拒否することもできる。 接続時の認可にはTouch IDまたは1Passwordのアカウントパスワードを使う。2 常設承認はなく、新しいエージェントセッションでは新しいプロンプトが表示される。3
入力中、Claudeはページの読み取りと追跡を停止する。 送信に成功すれば、秘密値がページを離れた後に制御を戻す。 失敗すれば、1Passwordが入力した値をすべて消してから失敗を通知する。3
Claudeが受け取るのは、承認済みアイテムのタイトル、ユーザー名またはメールアドレス、保存済みサイトと成否だけだ。 秘密値がエージェントへ返されるAPIはない。3
4原則を実装するコード署名・セッション鍵・暗号化¶
公開されたセキュリティモデルは、エージェントから秘密値を隔離する4原則で構成される。3
- 秘密値を扱わせない: 復号と入力は1Passwordのソフトウェアだけが実行する
- 毎回、人間が承認する: 資格情報の要求ごとに承認画面を出し、常設承認を作らない
- 短命かつスコープ付きにする: 解放したアイテムを1つのエージェントセッションへ束縛する
- 機微な経路をE2E暗号化する: デスクトップアプリケーションと拡張機能を相互認証付きで接続する
最初の防壁はアプリケーションのなりすまし対策だ。 ペアリング要求を受けると、1PasswordはOSのコード署名機構でClaudeデスクトップアプリケーションを検証する。 有効な署名、1Passwordの信頼済みアプリケーション許可リスト、Anthropicの検証済みApple Developerチームという 3条件を満たさないプロセスは拒否される。3
次に、Claudeが作るエージェントセッションごとに暗号学的な資格情報を発行する。 1PasswordはこれをOpenID Connect(OIDC)に似たローカル連合モデルと説明している。 あるセッションへ解放したアイテムは、別セッションから参照できない。3
拡張機能は承認済み資格情報をAES-256-GCMで暗号化し、メモリ上だけに保持する。 ディスクには書き込まず、タスク完了またはブラウザー終了時に破棄する。 どちらも起きない場合は9時間で強制破棄され、解放履歴はアイテム使用履歴へ記録される。3
通信もMac内で完結する。 1Passwordアプリケーションと拡張機能は、Noiseベースのプロトコルを使う相互認証付きE2E暗号化チャネルで接続される。 中継するループバックリレーはペイロードを読めず、ClaudeアプリケーションとのローカルIPCには公開ライブラリが使われる。37
ここまでが「秘密を渡さない」を支える境界だ。次は、ブラウザー内の別経路をどう塞ぐかを見る。
Agentic Mode──統合しなくても拡張機能を隠す¶
Agentic Modeは、対応エージェントがタブを操作している間、1Password拡張機能のUIをページから除く防御層だ。
インライン候補、保存プロンプト、通知が非表示になるため、エージェントは通常の自動入力UIをクリックできない。 利用できるのは、人間が承認したフローだけである。 適用範囲はエージェントが制御するタブで、セッション終了またはタブを閉じると解除される。3
この防御は1Password for Claudeを接続していなくても自動で発動し、Claude以外の対応エージェントにも拡張できる設計だ。12 ただし、Agentic Modeが自動であることと、Claudeに資格情報を使わせる統合の許可は別である。 1Password Businessでは、管理者がAgentic Autofillポリシーを有効にする必要がある。2
セットアップ要件と現在の制約¶
現時点の利用環境はMacと有料Claudeプランに限られる。24
| 項目 | 要件 |
|---|---|
| OS | Mac |
| 1Password | Macアプリケーションとブラウザー拡張機能、いずれも8.12.28以降 |
| Claude | デスクトップアプリケーションとClaude in Chrome拡張機能 |
| Claudeプラン | Pro、Max、Team、Enterprise |
| 1Password Business | 管理者が「Allow AI agents to autofill for users」を有効化 |
| Claude組織 | 1Password統合は組織で既定無効。OwnerまたはPrimary Ownerが有効化 |
接続はClaudeデスクトップアプリケーションの「Customize > Connectors」から1Passwordを選び、 Touch IDまたはアカウントパスワードで認可する。2 Claude in Chrome自体の既定値はTeamで有効、Enterpriseで無効であり、1Password統合の設定とは別だ。5
対応するのはLoginアイテムのユーザー名、パスワード、ワンタイムコードである。 パスキーは未対応で、ソーシャルログインは意図どおり動かない場合がある。2
防げないリスク──秘密値保護とエージェント安全性は別問題¶
ゼロ露出設計が守るのは資格情報の保管・承認・配送・入力であり、ログイン後の操作ではない。3
1Passwordは設計文書で、受容されたリスクを4つ明示している。
- 侵害されたMac: 管理者権限や同一ユーザー権限を持つ攻撃者は防御範囲外
- ペアリング後のClaude: アプリケーションが申告するセッション識別子を信頼するが、解放には人間の承認が残る
- 宛先サイト: 送信後の資格情報はサイトとページ上のスクリプトが扱う
- ログイン後の行動: データの閲覧・変更・送信はClaude側の安全策に依存する
さらにAnthropicは、ブラウザー操作型AIに残る最大のリスクとしてプロンプトインジェクションを挙げる。 ページ内の悪意ある指示が意図しない操作を誘発し得るため、金融、医療、法務、機密性の高い業務アカウントでの 利用を避け、別ブラウザープロファイルや許可リストを使うよう推奨している。6
ここには重要な境界がある。1Passwordはパスワードをモデルから隠せるが、認証済みセッションの権限までは縮小しない。 導入判断では「秘密値が漏れないか」と「ログイン後に何を実行できるか」を別々に評価する必要がある。
まとめ──評価すべきは「ゼロリスク」ではなく境界の明確さ¶
1Password for Claudeは、資格情報を「使わせるが見せない」形でブラウザー操作型AIへ渡す。 コード署名、セッション鍵、9時間の上限、入力中のエージェント停止まで設計が公開されており、 秘密値の経路は具体的に検証できる。
- パスワードとワンタイムコードはモデルやAnthropicのシステムへ渡らない
- Agentic Modeは通常の拡張機能UIを隠し、未承認アイテムへの別経路を塞ぐ
- 侵害端末、宛先サイト、プロンプトインジェクション、ログイン後の行動は保護範囲外である
新しい示唆は、パスワードマネージャーが保管庫からエージェント向けのローカル認可ブローカーへ変わり始めたことだ。 自前のエージェント基盤でも、秘密値を渡さず、要求単位で人間が承認し、短命な権限だけを発行するという4原則は使える。 ただし、最小権限のアカウントとログイン後の操作制御を組み合わせて初めて、全体の境界が閉じる。