1Password for Agentsは「専用保管庫を共有する」しくみ？ 新方式・保管庫＋トークン方式・既存のClaude連携の違いを公式資料で整理する
「Grok Bot用の保管庫を作って、パスワードを共有する」のは、新しい1Password for Agentsではなく従来のプラグインの話です。新方式は保管庫を共有せず、ログイン1件ごとに自分のアプリで承認します。1Passwordの開発者資料、公式FAQ、Claude連携のセキュリティ説明で、3つの方式の渡すもの・承認の単位・期間・切断のしかたを整理しました（2026年10月23日時点）。
文・ニコ
2026年10月22日に1Passwordが「1Password for Agents」を発表した直後、Xでこんな投稿が並びました。
- 「Grok Botやdots用のVaultを作って、自分のVaultからパスワードを共有して使う」
- 「保管庫を共有しない。ボットがログインするたびに、自分の1Passwordアプリで承認する」
どっちもそれっぽいですよね。でも、言っていることは真逆です。いったい、どっち？
前者は従来のGrok Botプラグインの説明で、後者が新しい1Password for Agentsの方向です。ただし後者にも、細かいところで公式資料と合わない点があります。
混ざりやすい3つの方式を、公式資料を手がかりに見分けていきます。
- 従来のGrok Botプラグイン（専用保管庫＋トークン）
- 新しい1Password for Agents
- 既存の1Password for Claude（Mac向け）
「パスワードを見せないと、そもそも何が守られるのか」という大きな話は、前の記事（AIエージェントにパスワードを見せずにログインを任せると、何が守られ、何が残る？）にまとめました。今回は3つの方式の違いだけに絞ります。
先に結論
- 「専用保管庫を作って共有する」のは、従来のGrok Botプラグインのやり方です。
- 新方式は保管庫もトークンも渡しません。エージェント側は「このサイトのログインを使わせて」と頼む権利だけを持ち、許可は自分の1Passwordアプリでしか作れません。
- 既存のClaude連携はさらに別物です。同じMacの中で1Passwordアプリが仲介する作りになっています。
名前は似ていても、仕組みは3つ別々です。
Xの2つの投稿は、どこが合っていた？
| 投稿 | 言っていること | 公式資料との照合 |
|---|---|---|
| @MLBear2 | 専用Vaultを作り、自分のVaultからパスを共有して使う | 従来のGrok Botプラグインの流れと一致。新方式の設定手順ではない |
| @sora_biz | 従来は専用の保管庫とトークン。新方式は保管庫を共有せず、ログインのたびに承認 | 「保管庫を共有しない」は合っている。「ログインのたび」は、後で見るように正確ではない |
投稿者の意図や、そのとき使っていた版までは分かりません。ここで確かめたのは、公式資料との食い違いだけです。
方式1：従来のGrok Botプラグイン（専用保管庫＋トークン）
なぜ「専用の保管庫」が要るの？
ここがいちばん大事なところです。専用保管庫は好みで作るものではありません。作らないと、つなげないからです。
この方式は、1Passwordの「サービスアカウント」を使う仕組みです。人ではなく、プログラムが1Passwordにアクセスするためのアカウントですね。1Passwordの開発者向け資料には、こう書かれています。
- サービスアカウントには「トークン」があり、これで認証する。
- 見せる保管庫と、保管庫ごとの権限（読み取りなど）を選ぶ。
- 自分のPersonal・Private・Employee保管庫と、既定のShared保管庫は、サービスアカウントに渡せない。
- 権限と保管庫は、作ったあとに変えられない。変えたいなら、新しく作り直す。
- トークンは作成時に1回しか表示されない。パスワードと同じように扱う。
出典：Get started with 1Password Service Accounts、Service Account security
つまり、いつも使っている保管庫はそのまま渡せません。だから「Shared with Grok Bot」のような専用の保管庫を作って、渡したいログインだけをそこへ移すことになります。
つなぎ方は2通り
Cursorの公式フォーラムで、サポート側がGrok Botの1Password連携について答えています。
- アプリにおまかせ。 1Passwordの一時的なCLIセッションで、「Shared with Grok Bot」保管庫と、その保管庫だけを読めるサービスアカウントを作る。Grok Botが保持するのは、そのサービスアカウントのトークンだけ。
- 自分で作る。 保管庫とサービスアカウントを自分で作り、Grok Botの「Use a service account token instead」にトークン（
ops_で始まる）を貼る。
2つ目はMacがなくても使える方法として案内されていました。1つの保管庫につき1つのサービスアカウントで接続し、最大10保管庫まで使える、という回答もあります。
出典：1Password vault-only access in GrokBot（2026年10月20日の回答）、1Password integration now limited to one vault per service account?（10月21日）、1Password Connector（9月19日）
これは公式ドキュメントではなく、フォーラムでのサポート回答です。仕様は変わることがあります。
何が分かっていて、何が分からない？
分かっているのは次のことです。
- トークンを持つ側は、あなたがいなくてもその保管庫の項目を読める。サービスアカウントのトークンには、保管庫を開く鍵の材料が入っているためです。
- だから、守る範囲の決め手は保管庫に何を入れるか。入れなかったログインは見えません。
- 報道とサポート回答は、「入力のたびに自分の端末で承認する」と説明しています。
一方、まだ分からないこともあります。
- 入力のとき、パスワードがどの経路を通るのか。モデルに見えるのか。公式資料で、その実装は説明されていませんでした。
- 承認の詳しい仕様（頻度、有効期間）も、公式資料では確認できませんでした。
「保管庫＋トークン」と「モデルにパスワードが見える」は、同じ意味ではありません。逆に「見えない」と断言できる材料も、ここにはありません。
方式2：新しい1Password for Agents
こちらの仕組みは1Passwordのパートナー向け開発者資料（「Agentic Autofill」の統合ガイド）で詳しく説明されています。読むときに気をつけたい点は2つあります。
- この資料は「Partner preview」。一般提供前のもので、仕様が変わるかもしれません。
- 消費者向けの発表やFAQも、同じ「Agentic Autofill」という名前で、同じ流れ（要求→承認→入力）を説明しています。だから同じものを指していると考えられます。ただし、各連携先（MuseやGrok Botなど）の実装がこの資料と完全に同じかは、確かめていません。
流れ：頼む権利と、許可は別
- 接続（最初の1回）。 製品の「Connect 1Password」から、1PasswordのWebでサインインして同意します。連携先は「頼む権利」を受け取ります。この時点では何も読めません。
- 要求（作業ごと）。 エージェントが目的と最大5件のログイン（サイトと理由）を添えて要求します。
- 承認（自分のアプリ）。 自分の1Passwordアプリに、誰が何のために頼んでいるかが出ます。使うログインを選んで許可します。
- 入力。 ブラウザー拡張機能が入力して送信します。値は連携先のコードにもモデルにも渡りません。
出典：Build with 1Password Agentic Autofill
保管庫は共有しない
開発者資料の対応範囲を見ると、対象は「その人自身の保管庫」です（Individualなら個人用、Familyならプライベート）。共有保管庫はまだ対応していません。
さらに、保管庫を共有しても承認の手間はなくならない、とも書かれています。承認とは、その人のアプリが1件のログインの鍵を連携先に渡す手続きだからです。
出典：FAQ
つまり、専用保管庫を作る手順は新方式では要りません。
承認は「毎回」ではなく、ログイン1件ごとに1回
先ほどの「ログインのたび」が公式資料と食い違うのは、この点です。開発者資料にはこう書かれています。
- 承認はログイン1件ごとに1回。入力1回ごとではない。
- 承認後はそのログインを必要なだけ入力できる。複数ページのサインインも続けられる。
- 発表時点の有効期間は30日。期間を設定できるようにするのは今後の予定。
- 承認はチャットセッションに結びつかない。
- 入力は本人が席にいなくても動くので、予約や定期の作業も有効期間の中なら続けられる。
出典：Get the user's approval、FAQ
「毎回自分のアプリで承認する」というイメージは、少なくとも開発者資料とは違います。
一方、消費者向けのFAQは「承認を求める頻度は連携によって変わる」と書いています。「30日」はパートナー向け資料に書かれた、発表時点の値です。Muse・Grok Botなど個々の製品の設定として確認したものではありません。使う製品の画面と説明で確かめてください。
秘密はどこで復号される？
開発者資料の説明では、承認されたログインは1Passwordの認証済みエンクレーブ（AWS Nitro Enclaves）の中で復号されます。拡張機能が1Passwordの資格情報仲介サービスとの暗号化通信で受け取り、ページに入力する流れです。
連携先に渡るのは、パスワードではなく「参照」（ポインター）です。入力が成功すると、ページに入れた値は消えます。
ただし資料は書き方にも注意を求めています。「連携先のプラットフォームとモデルは値を扱わない」とは言えても、「資格情報がエージェントの環境に絶対届かない」とは言えない。入力の瞬間、値はブラウザーのページにあるからです。
1Passwordが保証すること／連携先が守ること
| 領域 | 1Passwordが保証 | 連携先が守る |
|---|---|---|
| 許可の作成 | 本人のアプリだけ。連携先のトークンや鍵からは作れない | ― |
| 保管庫の暗号化 | 項目はエンドツーエンド暗号化のまま | ― |
| トークンの権限 | 要求の作成、状態の確認、許可されたログインの取得だけ。項目の一覧や承認はできない | ― |
| 入力中のページ | 返る前に値を消す | その間、モデルがページを読めないようにする |
| 常設アクセス | ― | 承認は「どのログインか」を絞るだけで、使う頻度は絞らない。トークンと鍵を1つの秘密として守る |
| 複数のエージェント | ― | 1人の全エージェントが同じトークンと鍵を共有する。分離は連携先がやる |
まだできないこと（開発者資料の発表時点）
- Businessアカウント、共有保管庫（予定あり）。
- パスキー、ソーシャルサインイン（予定あり）。
- ログイン1件だけの取り消し。取り消しは接続全体で、取り消すと許可したログインはすべて使えなくなる。
- 1Passwordの中からの取り消し。切断は連携先の製品から行う。
消費者向けの発表は「いつでも接続を解除できる」と案内しています。その操作は連携先の製品に用意されるようです。開発者資料でも、そう設計することを連携先に求めています。
使える地域について、開発者資料は当面「米国のIndividual / Familyアカウント」としています。一方、発表には「1Password.comの個人・家族」とあり、.euと.caは未対応と書かれています。表現が違うので、使う製品の条件を確認してください。
方式3：既存の1Password for Claude（Mac向け）
こちらは前の2つとは別の設計です。1Passwordのサポート資料に、かなり細かい説明があります。
- Mac、1Password for Mac 8.12.28以降、ブラウザー拡張、有料のClaudeプラン、ClaudeデスクトップとClaude in Chromeが必要。
- 通信はMacの中で完結する。秘密の値は1Passwordやパートナーのサーバーを通らない。
- 常設の承認はない。新しいエージェントのセッションごとに、新しい承認画面が出る。
- 許可はそのセッションだけ。暗号化したキャッシュはタスク完了・ブラウザー終了・最長9時間のどれかで消える。
出典：Use 1Password to sign in to websites with Claude、About the security of 1Password for Claude
承認の長さが新方式（30日、セッションをまたぐ）とはかなり違います。
そして、発表にある「Anthropic Claude Duet」は「coming soon」です。この既存のMac向けClaude連携の説明を、新方式のClaude Duetにそのまま当てはめることはできません。
3つを並べて比べる
| 従来のGrok Botプラグイン | 新しい1Password for Agents | 既存のClaude連携（Mac） | |
|---|---|---|---|
| 渡すもの | 専用保管庫を読むサービスアカウントのトークン | 「頼む権利」（OAuth）。保管庫もトークンも渡さない | なし（Mac内の1Passwordアプリが仲介） |
| 保管庫 | 専用保管庫が必須（個人用は渡せない） | 自分の保管庫のまま。共有保管庫は未対応 | 自分の保管庫のまま |
| 承認 | 入力ごと（サポート回答） | ログイン1件ごとに1回、30日（開発者資料） | セッションごとに毎回 |
| 承認する場所 | 自分の端末 | 自分の1Passwordアプリ | Mac上の1Passwordアプリ |
| 復号される場所 | 公式資料に説明なし | 1Passwordのエンクレーブ→拡張機能 | Mac上（1Passwordアプリと拡張機能） |
| 切断 | トークンの取り消し・削除（自分の1Passwordで） | 連携先の製品から。接続全体 | 1Passwordのサポート資料に切断手順あり |
| 根拠の質 | 開発者資料＋フォーラムのサポート回答 | 開発者資料（preview） | サポート資料 |
自分が使っているのは、どれ？
見分ける手がかりは、つなぐときの画面にあります。
- 「Shared with Grok Bot」のような保管庫を作る、または
ops_で始まるトークンを貼る → 従来方式。 - 「Connect 1Password」でWebに移ってサインインし、同意する。そのあと、自分の1Passwordアプリに「誰が何のために頼んでいるか」の承認画面が出る → 新方式。
- ClaudeデスクトップのConnectorsから接続し、Touch IDで承認する → 既存のClaude連携。
同じ「1Password」という名前の連携でも、画面が違えば仕組みも違います。
方式ごとの、ひとつ上の使い方
従来方式を使うなら
- 専用保管庫にはそのエージェントに必要なログインだけを入れる。
- トークンは読み取り専用で作る。作ったあとは権限を変えられないので、変えたいときは作り直す。
- やめるときは、1Password側でサービスアカウントとトークンを取り消す。つなぎ直しの失敗で残った「Grok Bot agents」などのサービスアカウントも、整理する。
- ログイン先のサービスで専用アカウントを使うと、サイトの中の権限も狭められる。
新方式を使うなら
- 要求の中身（サイトと理由）を読んで、必要なログインだけ許可する。
- 承認は30日続く（開発者資料）。作業が終わったら、切断も考える。
- 切断するときは、連携先の製品の画面で操作する。ログイン1件だけの取り消しは今のところできない。
どの方式でも
- 「パスワードが見えない」ことと、「ログイン後に何をしてもいい」ことは別です。サイトの中で何をさせるかは、別に決めてください。
- ログインの後に、エージェントがサイトの中で何をするかは、各製品の安全機能次第です。1Passwordの保証は資格情報の保管・承認・受け渡し・入力までです（Claude連携のサポート資料にも明記されています）。
まとめ
- 「専用保管庫を共有する」のは従来のGrok Botプラグイン。サービスアカウントは個人用保管庫を渡せないので、専用保管庫が必要になる。
- 新しい1Password for Agentsは、保管庫もトークンも渡さない。許可は自分のアプリでしか作れず、承認はログイン1件ごと。開発者資料では有効期間が30日で、「入力のたびに承認」ではない。
- 既存のClaude連携（Mac）は、セッションごとに毎回承認し、キャッシュは最長9時間。別の設計。
- 見分けるには、つなぐ画面を見る。
新方式はまだ順次配布の途中で、開発者資料も「Partner preview」です。使い始める前に、そのエージェントの公式ページと手元の画面を見てください。
調べたこと・調べていないこと
2026年10月23日に、次の原典の本文を取得して確認しました。
- 1Passwordの発表記事、個人向け連携のFAQ、MuseとGrok Botのパートナーページ
- 1Passwordの開発者資料（Agentic Autofillのパートナー向けガイド、サービスアカウントの資料）
- 1Password for Claudeのサポート資料とセキュリティ説明
- Grok Botのドキュメント、Cursor公式フォーラムのGrok Bot関連の投稿（サポート側の回答）
- Xの2投稿（本文を取得）
やっていないことも書いておきます。
- 実際のアカウントでの接続や実験はしていません。画面の流れは資料の記述にもとづいています。
- 従来のGrok Botプラグインで、入力時の値の経路や承認の仕様を、公式資料で確認できていません。サポート回答と報道が根拠の部分は、そう書きました。
- 新方式の消費者向け製品（MuseやGrok Botなど）の設定が、開発者資料と同じかは未確認です。承認の有効期間「30日」は開発者資料の値です。
- 開発者資料はpreviewで、仕様が変わる可能性があります。
- 独立した第三者による監査の結果は確認していません。