TITLE

秘密をエージェントに渡さない設計「inject-not-expose」— 1Password for Claudeに学ぶ

投稿日：2026.07.19

秘密をエージェントに渡さない設計「inject-not-expose」— 1Password for Claudeに学ぶ

1Passwordは2026年7月16日、AnthropicのClaudeと連携する「1Password for Claude」を発表しました。ログインが必要なブラウザ操作をClaudeに任せる際、パスワードなどの認証情報をClaudeに一切見せずにアクセスを可能にする統合です。この仕組みの本質は新機能の追加ではなく、AIエージェントに秘密を扱わせる設計の型そのものにあります。私たちはこれを「inject-not-expose(注入し、晒さない)」と呼んでいます。AIエージェント導入を検討している担当者にとって、この型は1Passwordというツール固有の話にとどまらず、自社のエージェント運用にそのまま持ち帰れる原則です。

1Password for Claudeが実際にしていること

1Password公式ブログによると、1Password for Claudeは「Claude in Chrome」拡張と1Passwordのブラウザ拡張が協働する形で動作します。Claudeがログインを要するタスクを実行する際、認証情報はランタイムでページに直接注入され、Claudeのメモリや会話のコンテキストには一切入りません。認証情報が必要になるたびに、1Passwordが使用理由を画面に表示し、Touch IDなどの生体認証でユーザーが承認します。認証情報は現在のタスクにのみ有効で、タスクが完了すると失効し、送信に失敗した場合は入力値がクリアされます。

さらに「Agentic Mode」では、AIエージェントがブラウザを操作している間、1Password拡張機能そのものが自動的にロックされ、承認済みの認証情報だけにアクセスが限定されます。保管庫(ボルト)全体は隔離された状態を保ちます。現時点ではMac版のみの提供で、1Passwordのデスクトップアプリとブラウザ拡張、Claudeのデスクトップアプリと「Claude in Chrome」拡張がすべて揃って初めて動作します(Chromeブラウザ内のタスクに限定)。

核心はinject-not-expose ― 「盗む対象がコンテキストにない」状態をつくる

inject-not-expose概念図: NG(秘密がコンテキストに流入する経路)とOK(実行時注入・都度承認・タスク失効する経路)の対比

AIエージェントにプロンプトインジェクション攻撃を仕掛け、エージェントが保持している認証情報を盗み出そうとする攻撃は、既に広く知られたリスクです。この対策として真っ先に思いつくのは、エージェントの権限を絞ることや、怪しい入力を検知することかもしれません。しかし1Password for Claudeが示しているのは、もう一段手前の発想です。秘密をエージェントのコンテキスト(会話やメモリ)に一度も入れず、実行時に外部から注入し、使用のたびに人間が承認し、タスクの完了とともに失効させる。この形をとれば、そもそも「盗む対象がコンテキストの中に存在しない」状態をつくれます。検知や権限制御が「侵入されても被害を抑える」発想だとすれば、inject-not-exposeは「侵入されても盗めるものがない」発想です。これは1Passwordという特定製品の機能ではなく、AIエージェントに認証付きタスクを任せる時の設計原則として、どのベンダーの統合を選ぶ場合にも当てはめて評価できる基準だと私たちは考えています。

同じ「1Password×AI」でも経路の性質は逆になる

ここで注意が必要なのは、「1PasswordとAIを組み合わせている」という見た目が同じでも、経路の性質が正反対になる実装があるという点です。1Passwordは開発者向けにService Accountsという仕組みも提供しています。1Password公式ドキュメントによると、これは専用のトークン(環境変数OP_SERVICE_ACCOUNT_TOKEN)を使ってCLI経由でアイテムを取得する仕組みで、Linuxなど標準的なCLI環境で動作します。この方式では、AIエージェントが必要になった時点で秘密を取得しにいく形になり、取得した認証情報がエージェントの処理過程(コンテキスト)に流入する余地が生まれます。

どちらが優れているという話ではありません。ランタイム注入型はブラウザ操作の自動化に向き、取得型はCLIやスクリプトからの利用に向いています。大事なのは、自社でAIエージェントに秘密を扱わせる設計を選ぶ時に「エージェントは秘密を見るのか、見ないのか」を先に決めておくことです。この判断は一方向のドアに似ています。一度「エージェントが秘密を取得できる経路」を開いてしまうと、その経路を前提にしたスクリプトや自動化が積み上がっていきます。後から「渡さない設計」に切り替えようとすると、それらを一つひとつ洗い出して作り直す必要があり、経路を先に決めておく場合に比べて作り直しのコストは大きくなりがちです。開ける前に決める、という順番が重要です。

本当のリスクはログイン後にある

パスワードをエージェントに見せないことは重要な一歩ですが、それだけでリスクが消えるわけではありません。ログインに成功したエージェントは、その先で送金・削除・設定変更といった、取り消しのきかない操作を実行できる立場に立ちます。認証情報を保護する設計と、ログイン後の操作権限を設計することは、別の問題です。前者は1Password for Claudeのようなツールが担えますが、後者――どこまでの操作を自動承認してよいか、承認の粒度をどう刻むか、実行内容をどう監査するか、暴走をどう止めるか――は、ツール任せにできず、導入する側が自分で設計する必要があります。認証情報の可視性だけを見て「これで安全」と判断すると、この後段のリスクを見落とすことになります。

私たちも導入評価をしてみて、見送った

私たちも1Password for Claudeの発表を受けて、複数のAIモデルによる相互レビューという形で導入評価を行いました。結論は「今回は導入しない」です。理由は単純で、この統合はMacとChrome拡張の組み合わせを前提にしており、私たちの開発環境はLinuxとCLIが主体だからです。合わないツールを無理に組み込むより、合わないと分かった時点で見送る方が、後々の運用コストを考えると健全な判断だと考えています。こうした統合は環境が噛み合って初めて意味を持ちます。導入を検討する際は、自社のOS・ブラウザ・ワークフローの前提と噛み合っているかを、機能そのものより先に確認する価値があります。

まとめ

1Password for Claudeという1つの発表から、私たちが持ち帰れる原則は4つあります。核になるのは、秘密をエージェントに見せず実行時に注入し、都度承認して使い捨てる「inject-not-expose」という設計の型です。同じ「1Password×AI」でも注入型と取得型では秘密の流入経路が正反対になるため、どちらを選ぶかは導入前に決めておく必要があります。しかもこの判断は一方向のドアに似ていて、開けてから戻そうとすると作り直しのコストが大きくなりがちです。そしてもう一つ、認証情報の保護とログイン後の操作権限の設計は別問題であり、後者は自社で設計する必要があります。私たちが導入評価で環境不一致に気づいて見送ったように、AIエージェントに何かを任せる前にこの4点を自社の導入計画に照らして確認しておくことが、事故を未然に防ぐ最も安い保険になると私たちは考えています。