- ▶ 社員が AI に仕事を任せ始めると、AI が使う「鍵」（パスワードの仲間）が社員の手元に散らばる理由
- ▶ 今のパスワード管理や、社員のログインをまとめる仕組みで足りないところ
- ▶ 1Password が2026年3月に発表した「Unified Access」が狙っていることと、10月時点でどこまで出ているか
- ▶ 製品がそろうのを待たずに、今から会社でやっておくこと3つ
社員が業務で AI を使い始めると、AI は社員の代わりに社内外のサービスへつなぎにいくようになる。そのとき AI が使うのが、サービスに入るための「鍵」だ。この鍵は、使う社員が自分で発行し、自分の PC のファイルやメモに置いたまま使っていることが多い。会社は、誰がどの鍵を持っていて、どこにつながっているかを知らない。退職した人の鍵が止められないまま残ることもある。
2026年3月、パスワード管理ツールの 1Password が、この「AI が使う鍵」を社員のパスワードと同じ金庫で管理しようという「Unified Access」を発表した。地味に見えるが、パスワード管理の会社が「AI の鍵も、社員のパスワードと同じように会社が管理すべきだ」と言い出したという点で、IT を任されている人にとってはかなり重要なニュースだと思っている。この記事では、何が問題になるのかを整理して、会社として今から何を考えておくべきかを書く。
この記事は発表の直後（2026年3月26日）に公開したものを、10月に書き直した。発表から半年あまりで製品の形が変わったので、製品の話は「3月の発表時点」と「10月時点」を分けて書く。用語や製品の細かい話、3月の本文から直したことの詳細は、後半の「担当者向け」にまとめた。
▼何が起きるか：AI に仕事を任せると、AI が使う「鍵」が社員の手元に散らばる
今、多くの会社で社員が業務に AI を使い始めている。ChatGPT や Claude のように質問に答える AI だけでなく、社員が自分で組み立てた社内向けのチャットボットや、ブラウザの操作を代わりにやってくれる AI も、業務に入り込んできた。
こうした AI が社内のデータや外のサービスにつなぐときに要るのが、「鍵」だ。
人がサービスにログインするときはパスワードを使う。AI やプログラムがサービスにつなぐときは、パスワードの代わりに、サービスの管理画面で発行する長い文字列を使う。この記事ではこれを「鍵」と呼ぶ（担当者の間では「API キー」「シークレット」と呼ばれる。後半の対応表を参照）。
鍵を持っていれば、誰が使っても正規の利用として扱われる。漏れて他人に使われても、記録の上では正しい利用に見えるので気づきにくい。期限を付けずに発行した鍵は、誰かが止めるまで使い続けられる。
社員のパスワードなら、情シスがログインの仕組みやパスワード管理ツールでまとめて管理してきた。ところが AI 用の鍵は、使う社員が自分でサービスの管理画面から発行し、自分の PC のファイルやメモに保存していることが多い。会社の管理の外で生まれるわけだ。
退職した人の鍵が生きたまま残る、強い権限の鍵がきちんと管理されないまま使われる——そうしたリスクが静かに積み上がっていく。
起こりうる例（実際にあった事例ではなく、起こりうる形として挙げる）
マーケティング担当が、AI（Claude）の鍵を自分の個人アカウントで発行し、社内の業務に使う自動処理に組み込んでいる。その人が退職したが、鍵のことは誰も知らないので止められず、残り続ける。
エンジニアが、プログラムのコードの中に鍵をそのまま書き込み、コードの置き場（GitHub）に保存した。コードが外に漏れたとき、その鍵を使って外から社内のサービスに入られる。
AI に強い権限の鍵を渡していたため、AI が意図しない操作（大量のデータの取り出しや削除など）をしてしまう。
どれも悪意があって起きるわけではない。管理の仕組みがないまま AI の利用が広がると、自然に起きうる構造の問題だ。
▼今の仕組みで足りないところ：鍵は金庫の外で生まれ、人のログイン用の使い方では拾えない
「パスワード管理ツールに入れておけばいいのでは」と思うかもしれない。実は 1Password のようなツールには、以前から、プログラムが金庫から鍵を受け取る仕組みもある。ただそれは、エンジニアがプログラムごとに用意して使うものだ。社員が自分で発行して PC に置いた鍵は、そもそも金庫に入っていない。会社がツールを人のログイン用にしか使っていなければ、AI の鍵については次の3つが抜ける。
- ▶ AI が金庫から鍵を受け取る形になっていない：鍵は社員の PC のファイルに置かれ、AI はそこから読んでいる
- ▶ 必要なときに必要な分だけ渡せない：強い権限の鍵を、AI にずっと渡しっぱなしにすることになる
- ▶ 記録が残らない：金庫の外の鍵は、誰が（どの AI が）、いつ使ったかを後から確かめられない
社員のログインをまとめる仕組み（社員が1つの ID でいろいろなサービスに入れるようにするもの）も同じで、人のログインを前提に作られてきた。AI がどのサービスに入ってよいか、何をしてよいかを管理するための作りではなかった。
▼1Password が発表したもの：散らばった鍵を「見つける・金庫に集める・記録する」
1Password（社員のパスワードを会社でまとめて管理するツール）は2026年3月17日、「Unified Access」を発表した。人のパスワードと、AI やプログラムが使う鍵を、同じ金庫でまとめて管理しようという仕組みだ。
発表で 1Password が言っている狙いは、大きく3つある。
- ▶ 見つける：社員の PC やブラウザで使われている AI ツールと、ファイルに書かれたままになっている鍵を見つける
- ▶ 金庫に集める：見つけた鍵を、ワンクリックで金庫に移す
- ▶ 記録する：どの鍵が、いつ、誰（どの AI）によって、誰の許可で使われたかを残す
あわせて、AI に鍵を「常に持たせておく」のではなく、「必要なときに必要な分だけ渡す」形に移すことが大事になる、とも書いている。発表では、Claude や ChatGPT などの AI が、1Password に入っているログイン情報や鍵を、社員の許可を得て使えるようにする連携も挙がった（Claude を作る Anthropic、ChatGPT を作る OpenAI、AI 検索の Perplexity など）。ただし Anthropic については「これから組み込む」という予定の書き方だった。
ここまでは 1Password が発表で言っていること、つまり狙いだ。自分がこの製品を使って確かめたものではない。そのうえで、時点ごとに何が出ていたかを分けておく。
3月の発表時点：「見つける・金庫に集める」は使える、「記録」と「必要なときだけ渡す」は予定
発表の日に「今日から使える」とされたのは、「見つける」と「金庫に集める」だった。「記録する」は「近日提供」、AI やプログラムに必要なときだけ鍵を渡す仕組みは「年内に広げる」予定と書かれていた。
10月時点：製品をまとめた「基盤」の名前になり、AI に鍵を渡す部分はまだお試し段階
2026年10月29日に 1Password の公式ページで確かめると、Unified Access は1つの機能の名前ではなく、5つの製品をまとめた基盤の名前として説明されている。法人向けのパスワード管理、社員が使っているクラウドサービスの管理、AI やプログラムに鍵を渡す製品、端末の確認（会社が管理している PC から入っているかを確かめる）、管理者のような強い権限の管理、の5つで、「1つの製品から始めて広げられる」とある。
AI やプログラムに、その場で必要な鍵だけを渡す部分は、別の名前の製品（Credential Broker）になった。6月にごく一部の会社向けの試験提供で始まり、7月に、1Password の法人向けパスワード管理を契約している会社なら試せる「お試し公開」になった。最初に対応したのは、エンジニアがプログラムを自動で動かす仕組み（GitHub Actions）だ。つまり10月時点でこの部分を試せるのは、エンジニアが自動処理を組んでいる会社の、その場面だけで、社員が業務で使う AI にはまだ使えない。AI エージェント（仕事を任せられる AI）への対応は、6月の発表では「年内」とされていたが、7月の発表には「作っている」とだけあり、時期は書かれていない。仕事が終わったら鍵が切れる形も、AI 向けは「作っている途中」という書き方だ。
「記録する」については、公式ページに人と AI の利用をまとめて記録する機能の説明はあるが、提供を始めたと明記したお知らせは見つけられなかった。製品ページに料金の額は載っていない。
狙いどおりになれば、人と AI の両方について「誰が・どのシステムに・いつ入ったか」を1か所で見られるようになる。ただし10月時点では、AI に鍵を渡す部分はまだお試し公開で、AI エージェントへの対応はこれからだ。「入れれば今日から全部そろう」ものではない。
▼今から会社でやっておくこと3つ：使っている AI を知る・鍵のルールを決める・今のツールの予定を聞く
製品がそろうのを待たなくても、今からできることがある。
① 社員が業務で使っている AI を把握する
まず「社員が業務でどんな AI を使っているか」を知ることが先だ。特に、AI の鍵を自分で発行して使っている社員や、AI を組み込んだ自動処理を自分で作っている社員がいないかを確かめる。把握できていないリスクは、管理できない。
やり方は難しくない。まず社員に「仕事で使っている AI のサービス」と「自分で鍵を発行したか」を聞き、使っている AI サービスの一覧を作る。あわせて、経費精算や会社のカードの明細も手がかりになる。AI の会社（OpenAI・Anthropic など）から、使った量に応じた請求が来ていれば、誰かが鍵を発行して使っている。
② 社内の AI 利用ルールに「鍵」の扱いを入れる
社内の AI 利用ルールを作るときに、次の4つを書いておく。
- ▶ 鍵は誰の名義で発行するか（社員の個人アカウントではなく、会社のアカウントから発行する）
- ▶ 鍵をどこに保存するか
- ▶ 誰が鍵の発行を管理するか
- ▶ 退職するときに、その人の鍵をどう止めるか
これがないまま利用が広がると、後から棚卸しする手間が大きくなる。特に1つめの名義が決まっていないと、例①のように、退職した人の個人アカウントに鍵が残り、残りの3つが効かない。自分も、業務委託で支援している会社の仕事では個人の AI アカウントを使わず、その会社のアカウントを稟議で申請した（その稟議の記事）。
③ 今使っているパスワード管理ツールやログインの仕組みが、AI の鍵をどう扱う予定かを聞いておく
1Password がこの方向に動いたことで、他のパスワード管理ツールやログインの仕組みも同じ方向に動く可能性は高いと見ている。今使っているツールの今後の予定を、担当者に確かめておくといい。
3月に書いた時点では、AI に鍵を渡して使っているのは一部の技術に詳しい社員、という段階だった。そのとき、AI の広がる速さを見て「1〜2年のうちに多くの会社で同じ問題が起きる」と書いた。半年たった今も、この見立ては変えていない。早く動くほど、対応の手間は小さい。
▼まとめ：自分の会社で確かめること
AI に仕事を任せることが広がると、「誰が、どこに入ってよいか」の管理に、新しい種類の問題が生まれる。今の管理の仕組みは人のログインを前提にしているので、会社として意識して手を打っておく必要がある。
1Password の発表は、業界がこの問題に本格的に取り組み始めたサインだと思っている。ただ、10月時点でも製品はそろいきっていない。ツールの進化を待ちながら、「実態を知る」と「ルールを決める」から始めるのが現実的な第一歩だ。担当者には、次のことを聞いてみてほしい。
- ▶ AI の鍵を自分で発行して使っている社員はいるか。いるなら、どのサービスの鍵か
- ▶ その鍵はどこに保存されているか（個人の PC のファイルやメモ、プログラムのコードの中に書かれていないか）
- ▶ 退職者が発行した鍵は、退職のときに止めているか。止める手順は退職の手続きに入っているか
- ▶ AI に渡している鍵の権限は、その仕事に必要な分だけになっているか
- ▶ 社内の AI 利用ルールに、鍵の名義・保存場所・発行の管理者・退職時の止め方が書かれているか
- ▶ 今使っているパスワード管理ツールやログインの仕組みは、AI の鍵をどう扱う予定か
・3月は「まだ展開中で、すぐに全社導入できるものではない」と書いたが、発表の日から使える部分（散らばった鍵を見つける・金庫に集める）があった。
・3月は「AI が鍵を使うと記録が残る設計」と書いたが、発表の時点で記録の部分は「近日提供」で、10月時点でも提供開始のお知らせは見つからなかった。
・AI やプログラムに必要なときだけ鍵を渡す部分は、別の製品になり、10月時点でもお試し段階だ。社員が使う AI への対応は時期が出ていない。
細かい訂正（呼び方・製品名・例に挙げた製品）は、後半の「担当者向け」にまとめた。
▼担当者向け：用語と製品の詳細
ここから先は、担当者向けに、正式な名前と一次情報の中身をまとめる。出典は 1Password のプレスリリース（2026-03-17、2026-07-28）、1Password のブログ（2026-03-17、2026-06-15、2026-07-28）、Unified Access のプラットフォームページ（1password.com/platform）、Credential Broker の製品ページ（1password.com/product/credential-broker）。確認は2026年10月29日。英語の原文から要約しているので、契約や導入の判断には原文と営業の回答を確かめてほしい。
前半の言い方と、実際の名前
| 前半の言い方 | 実際の名前 |
|---|---|
| 鍵（AI やプログラムがサービスにつなぐときの文字列） | API キー・トークンなどのシークレット（認証情報、credentials）。例：Claude API のキー（sk-ant-xxxx... のような形） |
| 鍵が社員の手元に散らばる | 3月の本文での呼び方は「シークレットの野良化」「野良シークレット問題」（筆者の呼び方で、一般に定まった用語ではない。書き直しでは使っていない）。英語では secrets sprawl（シークレットの散らばり）と呼ばれることが多い |
| AI に仕事を任せる／仕事を任せられる AI | AI エージェント |
| 社員が自分で組み立てたチャットボット・自動処理 | Dify・n8n などのワークフロー系ツールで作ったもの（例①は Dify のワークフローに Claude API のキーを組み込んだ形） |
| ブラウザの操作を代わりにやってくれる AI | ブラウザエージェント（例：Claude in Chrome） |
| コードの中に鍵をそのまま書き込む | ハードコード（して GitHub のリポジトリにコミット） |
| パスワード管理ツール | パスワードマネージャー（3月の本文では 1Password・Bitwarden を例に挙げた） |
| プログラムが金庫から鍵を受け取る仕組み（以前からあるもの） | 1Password のサービスアカウント（CLI・SDK・GitHub Actions 連携などで使う。利用した項目は使用状況のレポートで確かめられる） |
| 社員のログインをまとめる仕組み | IdP・IDaaS（SSO）。3月の本文では HENNGE One・Okta を例に挙げていたが、各社の10月時点の AI エージェント対応は確かめていないので、前半からは名前を外した |
| AI が金庫から鍵を受け取る形になっていない／必要なときに必要な分だけ渡せない／記録が残らない | 3月の本文の「動的なシークレット提供ができない」「最小権限の原則が適用できない」「行動ログ（監査ログ）が取れない」。3月の本文はパスワードマネージャーの機能の話として書いていたが、1Password にはサービスアカウントがあるので、「鍵が金庫の外にあり、ツールを人のログイン用にしか使っていない場合」の話として書き直した |
| 「常に持たせる」から「必要なときに必要な分だけ渡す」へ | always-on access から just-in-time access へ。最小権限（least privilege） |
| 見つける・金庫に集める・記録する | Discover・Secure・Audit（金庫＝vault） |
| 基盤 | platform（3月の発表では agent security platform、10月の公式ページでは identity security platform） |
| AI やプログラムに、その場で必要な鍵だけを渡す製品 | 1Password Credential Broker |
| 試験提供／お試し公開 | private beta／public preview |
| 法人向けのパスワード管理 | 1Password Enterprise Password Manager |
| プログラムの自動処理の仕組み | GitHub Actions（CI/CD） |
| クラウドサービスの管理／端末の確認／管理者のような強い権限の管理 | SaaS Manager／Device Trust／Privileged Access |
3月の発表（2026-03-17）の中身
- ▶ 位置づけ：プレスリリースは「agent security platform」。人・AI エージェント・マシンの認証情報を「unified vault」で管理する、と書く。同じ日に「Unified Access Pro」が generally available とされた。Pro が何を指すか（範囲・プラン）の定義は、一次情報で見つけられなかった
- ▶ Discover（available now）：エンドポイント・ブラウザ・ローカル環境の AI ツールとエージェントの動きを見つける。暗号化されていない SSH 鍵や、平文の
.envファイルも対象に挙げている - ▶ Secure（available now）：露出したシークレットをワンクリックで vault に移す
- ▶ Audit（coming soon）：どの認証情報が、いつ、どの ID によって、誰の権限で使われたかの記録
- ▶ 実行時の発行：「later this year」に、エージェントとマシンのワークロードへ、範囲を絞った認証情報を実行時に発行するよう広げる、とした
- ▶ just-in-time：ブログは「always-on」から「just-in-time」への移行が重要になる、と書く。プレスリリースでは、AI ブラウザ側の連携先の説明に just-in-time・最小権限・監査可能性が出てくる
- ▶ 連携先：Anthropic は Claude のブラウザ拡張・Cowork・Claude Code に 1Password を「will integrate」（予定）。OpenAI はローカルの 1Password の vault の項目と開発者向け IDE での利用で協力。ほかに Cursor・GitHub・Vercel（開発の流れ）、Perplexity・Anchor Browser・Browserbase・KERNEL（ブラウザ側）
- ▶ 表記の差：同じ日のブログは Audit に「coming soon」を付けず、実行時の発行にも時期を書いていない。提供状況は、時期を明記しているプレスリリースに合わせた
10月時点の状態（2026-10-29 確認）
- ▶ プラットフォームページ：見出しは「Identity security for humans, AI agents, and machines」。製品は Enterprise Password Manager・SaaS Manager・Credential Broker・Device Trust・Privileged Access の5つ。「Organizations can start with a single product and expand from there.」。機能に「Unified audit logs」があるが、提供状況の表記はない。料金は「View platform plans」へのリンクだけで、額の記載はない。「Pro」の表記は見当たらない
- ▶ Credential Broker：2026-06-15 に private beta 開始（GA は「late 2026」目標、AI エージェント対応は「Later this year」）。2026-07-28 に public preview、対象は Enterprise Password Manager Business の契約者。最初の連携は GitHub Actions、カスタム OIDC は別の beta で順次。AI エージェントについては「additional controls for AI agents」を作っている、とだけあり時期の記載はない。タスクが終わると切れる短期のアクセスは「is being built to」（開発中）。製品ページは「public preview」で、対象を「all Enterprise Password Manager customers」と書き（7/28 のブログは「EPM Business customers」）、「Verify AI agents and machine workloads at runtime」と AI エージェントも対象に挙げる。ただし提供中と明記された連携は GitHub Actions と、beta のカスタム OIDC だけ。渡すたびに帰属つきで記録すると書く
- ▶ Privileged Access：2026-07-28 のプレスリリースで、Unified Access のプラットフォームを特権アクセス管理に広げる、と発表。GA かどうかの記載は確認できなかった
- ▶ 入れていないもの：2026-10-22 の「1Password for Agents」。個人・家族向けのアカウントで、個人の AI エージェントがサイトにログインするとき、パスワードを渡さずに 1Password が入力する仕組み。法人向けの Unified Access とは別の発表なので、この記事では扱っていない（/platform の上部にバナーが出ている）
- ▶ 確認できなかったこと：Audit が一般提供になった日、対象プランと追加料金、support.1password.com の Unified Access 専用ページ。なお、1Password Business の監査ログ（activity log）は Unified Access とは別に以前からある
3月の本文から直したこと
前半の箱の3つに加えて、次を直した。
- ▶ 3月は Unified Access を「新機能」と書いたが、発表文では「agent security platform」（基盤）と呼んでいた。10月時点では5つの製品をまとめた基盤の名前として説明されている
- ▶ 3月は「使い終わったら権限を手放す」と書いたが、3月の発表文にこの言い方はない（発表は「常に持たせる」から「必要なときだけ渡す」へ、という方向まで）。この考え方は6月の Credential Broker の発表で「タスクが終わるとトークンが切れる」として出てきたが、7月の時点でも AI 向けは「作っている途中」の書き方だ
- ▶ 3月は「足りないところ」をパスワードマネージャーの機能の話として書いていたが、1Password には以前からサービスアカウントがあるので、「鍵が金庫の外で生まれる」話として書き直した
- ▶ 3月は、社員のログインをまとめる仕組み（IdP）の例として HENNGE One・Okta を挙げていたが、各社の10月時点の AI エージェント対応は確かめていないので、前半から名前を外した
- ▶ 3月は連携先を「連携も発表されており」と書いた。発表されたこと自体は正しいが、Anthropic は「will integrate」（予定）の書き方だった
- ▶ 3月より後の変化：AI やプログラムに鍵を渡す部分は Credential Broker として 6/15 に private beta、7/28 に public preview。7/28 に Privileged Access が基盤に加わった