1Passwordは「1Password for Claude」の利用手順を2026年7月16日に公開し、Claude CoworkがWebサイトへログインする場面で、保存済みのパスワードやワンタイムコードをモデルに見せずに使えるようにする変更を実施した。Claudeが必要なログインを要求し、人が1Passwordの画面で許可すると、1Passwordのブラウザ拡張が入力から送信までを引き受ける。
これまでブラウザを操るAIエージェントに認証させるには、ユーザーが途中で操作を引き取るか、秘密値がエージェントのコンテキストへ入る危険を受け入れる必要があった。今回の統合は認証処理をLLMの推論経路から外し、Claudeには「どのログインを使ったか」と処理結果だけを返す。ただし、提供範囲はMac上のClaude Coworkから始まり、ログイン後の操作まで1Passwordが安全を保証するわけではない。
Mac版CoworkでつながったAnthropic連携
利用にはMac、バージョン8.12.28以降の1Passwordデスクトップアプリとブラウザ拡張、Claude Desktop、Claudeブラウザ拡張が要る。Claude Desktopの「Customize」から「Connectors」を開いて1Passwordを選び、Touch IDか1Passwordのアカウントパスワードで接続を承認する。その後はCoworkへWebサイトを使う作業を頼むと、1Passwordが候補のログイン項目を示す。人が使う項目を選んで承認すれば、1Passwordのブラウザ拡張が入力と送信を代行する。
1Passwordにとって、AIエージェント向け自動入力そのものが初めてというわけではない。同社の開発者向け文書は、Browserbase Directorを使うAgentic Autofillを早期アクセスとして案内してきた。今回はClaude Desktopの設定画面から接続できるため、開発者が独自のエージェントを組み立てなくてもCoworkのブラウザ作業へ持ち込める。
発表の射程と現時点の実装には差もある。1Passwordは2026年3月、AnthropicがClaudeブラウザ拡張、Cowork、Claude Codeへ1Passwordを統合する計画を明らかにした。7月の公式手順が説明しているのはMac版Claude Coworkでの利用であり、Claude Code向けの導入方法はまだ示されていない。広い提携構想のうち、一般的なWebログインが先に製品へ入った段階である。
9時間上限の暗号キャッシュと三つのローカル経路
仕組みは初回のアプリ確認から始まる。1PasswordはmacOSのコード署名機能を使い、接続してきたClaude Desktopが正しく署名されているか、その署名IDが許可リストにあるか、Anthropicの検証済みApple Developer Teamから公開されたものかを確かめる。条件を満たさないプロセスからの接続は拒否される。
ペアリング後もClaudeへ一括の権限は渡さない。新しいエージェントセッションが始まるたびに、1Passwordはその識別子へ結びつけた暗号資格情報を発行する。以後の要求はセッション鍵を持つことを暗号学的に証明する必要があり、別のセッションに許可された項目は参照できない。
連携の通信は、Mac内にある三つの経路で成り立つ。Claude Desktopと1PasswordデスクトップアプリはローカルIPCで接続する。1Passwordアプリと同社のブラウザ拡張の間では、Noiseプロトコルを使った相互認証付きのエンドツーエンド暗号化チャネルが動く。Claude側と1Password側の拡張機能は標準のブラウザ拡張メッセージングで要求、メタデータ、成否だけを交換し、各呼び出しを登録済みセッションの鍵で検証する。秘密値を運ぶのは、1Passwordアプリから同社の拡張へ至る暗号化チャネルである。
承認されたログイン項目は、1Passwordブラウザ拡張のメモリ内でAES-256-GCMにより暗号化され、ディスクには書かれない。タスクが終わるかブラウザを閉じると消去され、残り続けても9時間が上限だ。Claudeが受け取るのは項目名、ユーザー名またはメールアドレス、保存されたWebサイト、処理の成功・失敗であり、パスワードやワンタイムコードではない。秘密値を完全に取り込ませる方式から、必要なメタデータだけを見せる方式へ露出を絞っている。
入力の瞬間にも境界を置く。1Passwordがフォームへ入力して送信する間、Claudeはページの読み取りと追跡を止める。保存されたWebサイトと一致するページにしか入力せず、送信に失敗すれば値を消してから失敗を通知する。モデルがパスワード欄を観察できる時間を作らない設計である。
なぜMCPではなく、専用の認可経路なのか
今回の実装は、1Passwordが以前から示してきた「認可をLLMに判断させない」という方針を具体化したものだ。同社は2025年、Model Context Protocol（MCP）をアプリ情報やツールへ接続する仕組みとして評価する一方、生の資格情報をMCPのデータ経路へ流さないと表明した。モデルが扱う非決定的な通信と、誰に何を許すかを決める認可処理は分離すべきだという考えである。
Claudeから届く資格情報の要求文も、1Passwordは信頼済みの命令として扱わない。要求理由や対象サイトは検索候補を出すための平文にすぎず、それ自体では保管庫を開けない。人が1Password固有の画面で対象項目を確認し、差し替えるか拒否するかを決める。チャット上の文言から秘密値が直接解放されないため、認可判断は1Passwordの決定論的な画面に残る。
エージェントがブラウザタブを操作すると、1Password拡張はAgentic Modeへ切り替わる。インライン候補や保存通知などのUIをページから消し、承認済みフローの外側からClaudeが別の項目へ触れられないようにする。Agentic Mode中は人も通常の自動入力UIを使えず、Claudeのタブグループを閉じるまで解除されない。利便性よりセッション境界を優先した動作だ。
企業利用では、管理者が「Allow AI agents to autofill for users」ポリシーを有効にしなければ接続できない。各許可は1Password項目の利用履歴に記録される。ただし、2026年3月のUnified Access発表で「coming soon」とされた、人とAIの活動を横断する広い監査機能が今回すべて完成したわけではない。現状で残るのは資格情報を許可した記録であり、ログイン後にClaudeが実行した操作の監査とは別である。
ログイン前を守っても、ログイン後はClaude側の責任
1Passwordが示す保護範囲は、資格情報を保管し、人に承認を求め、安全な経路でフォームへ入力するところまでだ。ログインに成功した後、Claudeがサイト内で何を読むか、どのボタンを押すかはClaude側の安全機能とユーザーの指示に委ねられる。認証の秘密を隠せても、認証済みセッションの権限までは無害化できない。
宛先サイトも境界の外にある。フォームが送信されれば、資格情報はサイトとページ上のスクリプトへ渡る。1Passwordは保存済みURLと一致するページへ入力先を絞り、失敗時には値を消すが、正規サイト側での保存や処理は制御できない。端末が管理者権限や同一ユーザー権限で完全に侵害された場合も、このローカル分離では防げない。
パートナーアプリへの信頼も残る。初回接続時にClaude Desktopの署名を確認した後、1Passwordは同アプリが各エージェントセッションを正しく名乗ることを前提にする。Claude Desktopが侵害されれば資格情報の要求を発行し得るが、その場合も1Passwordの画面に要求元と対象項目が表示され、人の承認が必要になる。
機能面では、現在扱えるのはLogin項目のユーザー名、パスワード、ワンタイムパスワードである。「Googleでログイン」のようなソーシャルログインは正常に動かない場合があり、パスキーは未対応だ。1Passwordが3月に掲げたClaude Codeとの統合や他の環境への展開も、今回の手順には含まれていない。
企業が採用を広げる前に確認すべきなのは、資格情報の利用履歴とClaudeの操作記録を同じセッション単位で突き合わせられるかどうかだ。Mac以外への展開、パスキー対応、ログイン後の操作監査が揃えば、この設計はブラウザエージェントを業務アカウントへ接続するための実用的な管理層になる。今はまず、秘密値をモデルの外へ出したという大きな一歩を、限定された初期実装として評価する段階にある。
