1Password for Agentsは、AIエージェントがWebサイトのログイン画面に着いたとき、利用者の承認を挟んで1Passwordがパスワードやワンタイムコードを直接入力し、エージェント自身には認証情報を見せない仕組みです。2026年10月22日に1Passwordが発表しました。この記事では、承認から自動入力までの流れ、対応エージェントと対象プラン、自社でエージェントを開発する場合にop runやSDKで秘密情報を渡す方法、そして業務で採用するかどうかの判断基準を、公式ドキュメントとコード例で整理します。記載内容は2026年10月24日時点の公式情報に基づきます。
まとめ:個人向けの代行ログイン機能、業務のエージェントは別経路で設計
1Password for Agentsは、エージェントがパスワードを受け取らずにサインインできる、個人向けプランの連携機能です。対象は1Password.comのIndividualとFamilyアカウントで、追加費用はかかりません。1Password.euと1Password.caのアカウントは対象外です。
発表時点で連携が配信され始めたのはMetaのMuseとSpaceXSIのGrok Botの2つで、AnthropicのClaude DuetやOpenAIのChatGPT Workは「近日対応」の段階です。
自社で業務用のAIエージェントを作る場合、この機能は使えません。1Passwordの開発者向け機能(op runとEnvironments、SDKとサービスアカウント)で秘密情報を渡し、生のパスワードをモデルの文脈に入れない構成を選びます。
1Password for Agentsの仕組み:承認・自動入力・パスワード非開示の流れ
公式の発表ブログは、エージェントがログイン画面で止まったときの選択肢を2つ挙げています。人が操作を引き取って手入力するか、プロンプトにパスワードを貼るかです。前者は遅く、後者はタスクの範囲を超えて認証情報をエージェントに渡してしまいます。1Password for Agentsは、この2つの間に承認と自動入力を挟む設計です。
ログイン画面に着いたエージェントが承認を得て入力されるまでの3段階
製品ページは、流れを次の3段階で説明しています。
- エージェントがサインインフォームに着くと、固有のデジタルキーで自分の身元を1Passwordに証明し、必要なログイン情報を要求する
- 利用者は、どの認証情報がなぜ必要かを確認し、自分の端末上で承認または拒否する。条件に合うログインが複数あれば、使う1件を選べる
- 1Passwordがパスワードまたはワンタイムコードをサインインフォームへ直接入力し、エージェントには「アクセスが許可された」ことだけが伝わる
承認が利用者の端末で行われるため、許可が本人から出たことを1Password側で確かめられます。承認を求められる頻度は連携先ごとに異なると明記されており、毎回聞かれるかどうかはエージェント次第です。
エージェントに渡らないもの:パスワード・ワンタイムコード・保管庫全体
エージェントが受け取らないのは、パスワード、ワンタイムコード、そして要求したログイン以外の保管庫の中身です。製品ページのFAQは「エージェントを接続しても保管庫全体へのアクセスは与えない」と答えており、残りの項目はエンドツーエンド暗号化で守られたままです。
運用面の利点もあります。パスワードを変えたとき、保管庫で1回更新すれば、接続済みのエージェントは新しいログイン情報を使い続けます。エージェントごとに認証情報を配り直す必要はありません。
注意点は、安全策と制御の範囲が連携先ごとに違うと公式が書いていることです。「どのエージェントでも同じ保護が効く」とは読めません。使う前に、連携先ごとの説明を確認してください。
対応エージェントと提供条件:2026年10月時点の連携先・対象プラン・地域
連携は1Passwordと各エージェントの開発元が共同で作る方式で、利用者が任意のエージェントに後付けできるものではありません。どこまで使えるかは、連携先の一覧で決まります。
配信中・近日対応・今後対応に分かれる連携先エージェントの一覧
発表ブログの記載を、提供段階ごとに分けると次のとおりです(2026年10月22日発表時点)。
| 提供段階 | エージェント(開発元) | 補足 |
|---|---|---|
| 数日かけて配信 | Muse(Meta) | 全プラットフォームで順次 |
| 数日かけて配信 | Grok Bot(SpaceXSI) | 全プラットフォームで順次 |
| 近日対応 | Claude Duet(Anthropic) | 時期の記載なし |
| 近日対応 | ChatGPT Work(OpenAI) | 時期の記載なし |
| 近日対応 | dots(OpenAI) | 時期の記載なし |
| 近日対応 | Townie(Town) | Web版とiOS版 |
| 今後追加 | Instinct | 一覧への掲載のみ |
| 今後追加 | Browserbase | 一覧への掲載のみ |
| 今後追加 | Browser Use | 一覧への掲載のみ |
| 今後追加 | Dana | 一覧への掲載のみ |
| 今後追加 | KERNEL | 一覧への掲載のみ |
| 今後追加 | Perplexity | 一覧への掲載のみ |
| 今後追加 | Ramp | 一覧への掲載のみ |
| 今後追加 | Tomo | 一覧への掲載のみ |
| 今後追加 | Wajo | 一覧への掲載のみ |
実際に使える連携は、発表時点で2つにとどまります。社内で使っているエージェントが「近日対応」側にあるなら、提供開始の告知を待つ段階です。一覧に無いエージェントは、製品ページの待機リストから要望を出す仕組みになっています。
Individual・Family限定の対象プランと.eu・.caの地域制限
発表ブログは「1Password.comのIndividualとFamilyアカウントで追加費用なしで利用できる」と書き、1Password.euと1Password.caのアカウントは現在対象外としています。BusinessやTeamsのプランについての記載はありません。
ここが業務利用での最大の制約です。会社の共有保管庫にある業務システムのログインを、1Password for Agents経由で社内のエージェントに使わせる、という構成は発表内容の範囲外になります。
エージェントを作る側については、ブログ末尾に「個人向けエージェントを作っているならパートナー窓口へ」という案内があるだけです。連携用のSDKやAPI仕様は、開発者ドキュメントに公開されていません。
自社で作るAIエージェントに1Passwordから秘密情報を渡す3つの実装
自社開発のエージェントでは、1Passwordの開発者向け機能を組み合わせます。公式のAIエージェント向けの秘密情報保護ガイドは、平文の認証情報をエージェントのプロンプトに貼ると、LLMの文脈に漏れると警告しています。ここで示すのは、そのガイドとSDKドキュメントに沿った、秘密情報を渡すための3つの実装手段です。
MCP設定ファイルの平文トークンをop runとEnvironmentsで外す手順
MCPサーバーの設定ファイル(mcp.json)は、APIトークンをenvブロックに平文で書きがちです。公式ガイドは、秘密情報を1PasswordのEnvironmentに移し、起動コマンドをop run --environmentで包む書き方を示しています。
{
"mcpServers": {
"unleash": {
"command": "op",
"args": [
"run", "--environment", "<EnvironmentのID>", "--",
"npx", "-y", "@unleash/mcp@latest", "--log-level", "error"
]
}
}
}
MCPホストがサーバーを起動すると、1Password CLIが認証してEnvironmentの変数を解決し、子プロセスの環境変数として渡してからnpxに処理を引き継ぎます。設定ファイルからトークンが消えるため、リポジトリへの誤コミットによる漏えい経路を断てる構成です。macOSのClaude DesktopのようにGUIから起動するホストはシェルのPATHを引き継がないことがあり、その場合はopをフルパスで書きます。
op runの基本形やシークレット参照の書き方は1Password CLIのop runとサービスアカウント運用の解説にまとめています。MCPサーバー側の作り方はMCPサーバーの作り方とAIエージェントへの接続手順が前提になります。
Python SDKとサービスアカウントで読み取り専用の保管庫だけを参照
エージェントのツール実装(APIを呼ぶ関数)の中で秘密情報が要るなら、1Password SDKとサービスアカウントで実行時に取得します。PyPIのonepassword-sdkは2026年10月22日公開の0.4.2系(Python 3.9以上)です。
import asyncio
import os
from onepassword.client import Client
async def main():
# 対象の保管庫だけに読み取り権限を付けたサービスアカウントのトークン
token = os.getenv("OP_SERVICE_ACCOUNT_TOKEN")
client = await Client.authenticate(
auth=token,
integration_name="expense-agent",
integration_version="v1.0.0",
)
# シークレット参照から値を解決する(モデルには渡さず、ツール内で使う)
api_key = await client.secrets.resolve("op://agent-vault/ramp-api/credential")
# ここで api_key を使って外部APIを呼び、結果だけをエージェントに返す
asyncio.run(main())
要点は2つあります。サービスアカウントには、エージェントのタスクに必要な項目だけを入れた専用の保管庫への読み取り権限だけを付けること。取得した値をツール関数の中で消費し、LLMへの入出力に載せないことです。
SDKは公式ドキュメントで「バージョン0」と位置づけられ、0.1系から0.2系のようなマイナー番号の更新で破壊的変更が入りうると明記されています。requirements.txtで版を固定してから組み込みます。
ログイン項目の自動入力範囲をExactDomainに絞るSDKの書き方
エージェントに代行ログインをさせる前提で保管庫を整えるなら、ログイン項目ごとの自動入力の範囲も見直します。SDKの概念ドキュメントによると、既定値のAnywhereOnWebsiteはサブドメインを含むサイト全体で入力し、ExactDomainはホスト名とポートが一致したときだけ入力します。
from onepassword import AutofillBehavior, Website
item = await client.items.get("<保管庫ID>", "<項目ID>")
# サブドメインでの入力を止め、ログイン画面のホストに限定する
item.websites = [
Website(
label="sign-in",
url="https://app.example.com/login",
autofill_behavior=AutofillBehavior.EXACTDOMAIN,
)
]
updated = await client.items.put(item)
print(updated.title, [w.autofill_behavior for w in updated.websites])
この設定は1Passwordの自動入力全般に効く項目設定で、管理画面からも入力される場所の変更として操作できます。1Password for Agentsの代行入力がこの設定をどう扱うかは、10月24日時点の公式説明に記載がありません。効くかどうかは、連携先ごとに実機で確かめる必要があります。
1Password for Agentsを使う場面と使わない場面:採否の判断基準
判断は「誰の保管庫の、どのログインを、誰が作ったエージェントに使わせるか」で決まります。個人の保管庫と配信済みの連携先という条件がそろう場面は、現時点では限られます。
個人の保管庫と配信済みエージェントがそろう代行ログインは採用
個人のIndividualまたはFamilyプランを使っていて、MuseかGrok Botで予約や買い物の代行をさせるなら、採用してよい場面です。追加費用がなく、プロンプトにパスワードを貼る運用よりも漏えいの経路が明確に減ります。
承認のたびに、要求されたログインが作業内容と合っているかを見るのが利用者側の責任です。旅行の予約を頼んだエージェントが無関係なサイトのログインを求めたら、拒否します。承認は機械的に押すものではありません。
社内業務のエージェントは1Password for Agentsを待たずにSDKで構築
社内の業務システムにログインして作業するエージェントを作る場合は、1Password for Agentsを待たずに設計を始めます。対象プランに業務向けが含まれず、連携先も他社製のエージェントに限られるためです。
この場合の構成は、前章のop runとEnvironments、またはSDKとサービスアカウントが基本になります。業務APIにトークンで接続できるならブラウザ操作より先にAPI連携を選び、ログイン画面の自動操作は最後の手段にします。どの業務をエージェントに任せ、どこをAPIや既存の自動化で済ませるかの切り分けは、RPA・iPaaS・AIエージェントの選び分けが出発点です。
秘密情報の渡し方まで含めてエージェントを設計・実装したい場合は、AIエージェント開発としてご相談いただけます。
生の認証情報をAIモデルの文脈に渡す構成を見送るべき3つの条件
1PasswordのSDKとAIエージェントの連携チュートリアルは、冒頭で「これは推奨する連携方法ではない」と警告しています。生の認証情報をAIモデルに直接見せる構成には大きなリスクがある、というのが公式の立場です。
次のどれかに当てはまるなら、パスワードやAPIキーをプロンプトやツールの戻り値に載せる設計は採りません。
- エージェントが外部のWebページやメールを読む(プロンプトインジェクションで値を外へ送らせる経路がある)
- 会話ログや推論トレースを外部の監視基盤に保存している(値がログに残る)
- その認証情報に送金・発注・個人情報の閲覧など取り消せない操作の権限がある
代替は、値をツール関数の中だけで使う実装か、サンドボックスの外で置き換える方式です。1Passwordはベータ版としてNVIDIA OpenShellとの連携を公開しており、エージェントはプレースホルダーだけを扱い、承認済みのホストへの通信時にゲートウェイが本物の値へ置き換えます。
よくある質問
1Password for Agentsについて、導入前によく出る疑問をまとめます。
1Password for Agentsは無料で使えますか?
1Password.comのIndividualまたはFamilyプランの契約者なら、追加費用なしで使えます。製品ページでの説明は「すべてのIndividualとFamilyプランに含まれる」という内容です。1Password自体の契約は有料で、14日間の無料体験が用意されています。1Password.euと1Password.caのアカウントは2026年10月時点で対象外です。
Claudeで1Password for Agentsはもう使えますか?
発表ブログでは、AnthropicのClaude Duetとの連携は「近日対応」で、2026年10月22日時点では提供開始日が示されていません。同時点で配信が始まったのはMetaのMuseとSpaceXSIのGrok Botです。Claude Codeで開発中のAPIキーを守りたい場合は、別機能の1Password plugin for Claude Codeがあり、ローカルの.envファイルの検証フックとEnvironmentsのMCP設定を入れられます。
エージェントは保管庫のパスワードを読めるようになりますか?
読めません。製品ページのFAQによると、1Passwordは認証情報をエージェントへ送らず、サインインフォームへ直接入力します。エージェントが要求できるのはタスクに必要なログインだけで、保管庫全体へのアクセスは与えられません。承認しなかったログインや他の項目は、エンドツーエンド暗号化で守られたままです。
会社のBusinessプランで1Password for Agentsを使えますか?
2026年10月24日時点の発表では、対象はIndividualとFamilyのアカウントで、BusinessとTeamsへの言及はありません。業務でエージェントに秘密情報を渡すなら、サービスアカウントで権限を絞ったSDK経由の取得や、op runとEnvironmentsでの注入を使います。サービスアカウントの使用状況レポートで、エージェントがどの項目にアクセスしたかを追えます。
自社製のAIエージェントを1Password for Agentsに対応させられますか?
発表ブログは、個人向けエージェントを作っている事業者に対し、パートナー窓口への問い合わせを案内しています。連携用のSDKやAPI仕様は開発者ドキュメントに公開されておらず、自社だけで対応させる手段は見当たりません。社内向けのエージェントなら、パートナー連携を待つより1Password SDKで秘密情報を扱う実装が現実的です。
関連記事
- 1Password CLIの使い方:op runでの秘密情報注入とCIのサービスアカウント運用:本記事で触れたop runとサービスアカウントの手順を詳しく解説しています。
- AIエージェントフレームワークとは?主要8種の比較・実装コード・選定:秘密情報を扱うツール関数をどのフレームワークで実装するかの比較です。
- Cloudflare OSとは:社内AIエージェント基盤の仕組みとローカル起動・デプロイ手順:社内エージェントを動かす基盤側の選択肢です。
- Credential Exchange Protocol(CXP)とは?パスキー移行の仕組みとRP側の確認点:パスワード管理ツール間で認証情報を移す標準仕様です。
- パスキー移行の実装手順:パスワード併存期からSignal API・CXPでの鍵移行まで:エージェントの代行ログイン先となるサービス側の認証設計です。