AIエージェントに鍵を渡す前に決めること｜権限は人と分ける

「動かすのに、担当者のアカウントをそのまま使っています」「連携の設定はつないだのですが、いま何ができる状態なのかは正直分かっていません」——AIエージェントの検証が進んだ会社から、ほぼ同じ形で出てくる話です。手抜きの結果ではありません。仕事を任せる作業と、鍵を渡す作業が、同じ設定画面で同時に終わってしまうからです。仕事の範囲は議論されるのに、認証の情報は議論の対象にすらならない。この記事では、アカウントと鍵と接続の許可をどう渡し、どう止めるかに絞って整理します。承認の流れの作り方や、監査で見られる記録の項目は別に扱っているので、ここでは認証の情報だけを追います。

症状：仕事の許可を出したつもりで、鍵まで渡している

最初に、いま多くの会社で起きている状態を具体的に置きます。ある業務をAIに任せるとき、動かすための最短の手順は「担当者の資格でつなぐ」ことです。すでに権限が付いているので追加の申請が要らず、その日のうちに動きます。検証を急ぐ場面では、これがほぼ唯一の現実的な選択肢になります。

問題は、この状態が本番にそのまま残ることです。検証で動いたものを止める理由がないので、接続の設定は変わらないまま件数だけが増えていきます。半年後、その担当者が異動する段になって初めて、業務が1人のアカウントに依存していたことが分かります。

もう1つの症状は、何ができる状態なのかを誰も言えないことです。接続の設定画面では、渡す範囲がまとめて表示され、まとめて許可されます。渡した範囲を後から一覧で確認できる会社は、ほとんどありません。以下では、この状態が生む3つの困りごとを先に整理し、原因をたどってから対策に入ります。

課題1：誰がやったのかが、記録から消える

最初の困りごとは記録です。担当者の資格で動かすと、操作の記録に残るのは担当者の名前です。実際に操作したのはAIなのに、記録の上では人がやったことになる。この食い違いは、事故が起きた瞬間にいちばん高くつきます。原因を追う側は、人の操作とAIの操作を区別できません。

2025年12月に公表された、エージェント型のアプリの危険上位10項目でも、3番目に「身元と権限の乱用」が置かれています。そこでは、エージェントは固有の統治された身元を持たないまま実行時に権限を動的に扱うため、帰属の空白の中で動いていると説明されています。誰の行為なのかが決まらない状態が、危険の並びで上位に来ているということです。

実務ではもう一段面倒なことが起きます。止めたいときに、止める対象が人のアカウントになってしまうのです。AIの動きだけを止めたいのに、そのアカウントを止めると担当者の仕事も止まる。だから現場は止めるのをためらい、様子を見ているうちに範囲が広がります。帰属の空白は、記録の問題ではなく停止の問題として表に出ます。

課題2：人の権限がそのまま範囲になり、異動で壊れる

2つ目は範囲です。人のアカウントには、いま使っていない権限がかなり付いています。過去の兼務で付いた閲覧、終わった役割の承認、引き継ぎのときに付けたまま外していない編集。人はそれを使わないので害がありませんが、AIは付いている分を全部使えます。渡すつもりのなかった範囲が、そのまま渡ります。

この差は、頼み方をていねいにしても縮みません。指示の文章は範囲の希望であって、範囲の制限ではないからです。依頼の言葉づかいと、鍵の届く範囲は、まったく別の場所で決まっています。

さらに、人のアカウントに紐づけた仕組みは、人の異動で壊れます。退職や異動でアカウントが止まれば仕組みも止まる。逆に、止め忘れれば残ります。在籍しない人の資格で処理が続く状態は、たいてい数か月気づかれません。棚卸しの単位が「人」なので、そこにAIの分が混ざっていても、一覧を見ただけでは区別が付かないのです。

実務での確かめ方は簡単です。いま動いているAIの処理を一覧にして、それぞれが誰の資格で動いているかを書き出してみる。書き出せない行が出てきたら、その行は課題1と課題2の両方を抱えています。数が少ないうちにやっておく作業です。

課題3：止めたいときに、止められない

3つ目は停止です。おかしな動きに気づいたとき、実際に何をするかを決めている会社は少ないです。決めていないと、その場で探し始めます。誰が権限を持っているのか、どの画面で切れるのか、切ったら何が止まるのか。探している間も処理は動き続けます。

止める道は3つあり、効き方が違います。1つ目は鍵そのものを無効にする。2つ目は接続を切る。3つ目は受け側で受け付けないようにする。1つ目がいちばん速く、3つ目がいちばん確実です。速さと確実さが一致しないので、3つとも手順として持っておく必要があります。

止めた後にも仕事が残ります。すでに走り出した処理、待ち行列に入った依頼、外に出てしまった連絡。止めるという言葉が指す範囲を、あらかじめ広く取っておかないと、止めたつもりで動き続けます。この点は後の対策で手順に落とします。

原因1：鍵は1つ渡すのではなく、つなぐたびに増える

ここから原因に入ります。1つ目は数です。人は1人につき1つの身元を持ちますが、AIの側はそうなりません。使う道具ごと、つなぐ先ごと、動かす場所ごとに、別の鍵が要ります。文書の置き場、案件管理、表計算、通知、外部の情報源。1体で10を超えることは普通です。

増え方に規則性がないのが厄介です。人の権限は入社と異動という決まった機会に増えますが、AIの鍵は試した回数だけ増えます。検証で試してつないだ先を外していなければ、使っていない鍵がそのまま残ります。残った鍵は誰の記憶にもないので、棚卸しの対象になりません。

だから、数を管理しようとする発想を最初に捨てます。数が読めないものは、数えて減らすのではなく期限で減らす。放っておけば消える仕組みにしておけば、覚えていなくても残りません。これは後の対策3の考え方の土台になります。

それでも一覧は要ります。ただし目的が違います。全部を把握するための一覧ではなく、事故のときに止める対象を引ける一覧です。だから項目は絞れます。身元の名前、用途、持ち主、触れる範囲、期限の5つだけです。

原因2：長く使える鍵は、盗まれたあとも長く使える

2つ目の原因は期限です。長く有効な鍵は便利で、だから使われます。同時に、盗まれた場合にも長く使えます。この構造が現実にどう出るかは、公表された事例で見るのが早いです。

2025年8月に公表された事例では、顧客管理の仕組みにつながっていた対話型の道具の連携から、利用の許可を表す鍵が盗まれました。攻撃側はその鍵で各社の顧客管理に正規の連携として入り、2025年8月8日から少なくとも18日まで、複数の会社のデータを持ち出しています。正規の鍵なので、追加の本人確認をすり抜けました。

狙いが何だったかが、この事例のいちばん重い部分です。持ち出したデータの中から、さらに別の鍵を探していました。外部の計算基盤の接続鍵、パスワード、データ倉庫の接続鍵。つまり鍵を1つ失うと、その鍵で届く範囲に置かれた別の鍵まで失うという連鎖が起きます。

後始末の内容も見ておきます。提供元と受け側の双方が、その連携に紐づく有効な鍵をすべて無効にし、管理者が接続をつなぎ直す必要がありました。加えて、持ち出された中に含まれていた鍵の入れ替えが推奨されています。後始末は調査ではなく入れ替えです。入れ替える先の一覧を持っていない会社は、この時点で動けません。

原因3：AIは、受け取った文章と渡された指示を区別できない

3つ目の原因は、AI側の性質です。同じ危険上位10項目の1番目には「目的の乗っ取り」が置かれています。エージェントは正当な指示と悪意ある内容を確実に見分けられないため、目的や作業の選び方、複数手順にわたる振る舞いを外から書き換えられる、という説明です。

鍵の話に引き付けると、意味はこうなります。鍵を持ったAIは、外から来た文章によって鍵を使わされる可能性があります。読み込んだ文書、取り込んだ問い合わせ、参照した外部の情報。そこに書かれた文が指示として働くことがある、という前提で設計するしかありません。

だから原則は1つです。鍵を使う操作の可否を、AIに判断させない。使ってよいかどうかは、決まった手順と決まった範囲の側で先に決めておき、AIはその中でしか動けないようにします。危険かどうかをAIに見極めさせる設計は、乗っ取りの対象を増やすだけです。

同じ資料には、記憶に残った資格情報が後の不正なアクセスに使われる型と、権限の低いエージェントが権限の高いエージェントに検証なしで指示を中継してしまう型も挙げられています。やり取りの記録に鍵が残ること自体が危険だということです。これは後の対策4に直結します。

対策1：AIに専用の身元を持たせ、持ち主を人にする

対策の1つ目は、人と分けることです。1つの処理に1つの身元を割り当て、その身元は人のものと混ぜない。これだけで、記録の帰属と停止の対象が同時に解決します。止めるときはその身元を無効にすればよく、人の仕事は止まりません。

名前の付け方を決めておくと運用が楽になります。用途、部署、持ち主が読み取れる形にします。持ち主は必ず人にします。組織名を持ち主にすると、実質的に持ち主がいない状態になります。持ち主の仕事は3つだけです。範囲を決めること、期限を延ばすかどうかを決めること、止める判断をすること。

台帳の項目は先に述べた5つに絞ります。身元の名前、用途、持ち主、触れる範囲、期限。項目を増やすと更新されなくなり、更新されない台帳は事故のときに使えません。5項目なら、新しい接続を作るときに1分で書けます。

なお、この分野の規格はまだ固まっていません。2026年4月に公表された学術的な整理でも、AIエージェントの身元については、人と機械を区別する共通の方法、生涯にわたる資格情報と失効の仕組み、素性の信頼できる証明の3点が揃っていないと指摘されています。道具側の対応を待つと数年かかるので、社内の決めごとで先に埋めます。

対策2：触れる範囲を、始める前に狭める

2つ目は範囲です。絞り方は3つあり、3つ全部を使います。操作で絞る（読むだけか、書けるか）、対象で絞る（この部署のこの領域だけ）、量で絞る（1日に扱える件数の上限）。多くの現場は1つ目までで止まります。

抜けやすいのは3つ目です。読み取りだけの範囲であっても、大量に読めば持ち出しになります。先の事例で持ち出されたのは、書き込みではなく読み取りの結果でした。読むだけだから安全という判断は成り立ちません。1日あたりの件数と、1回に取り出せる件数の両方に上限を置きます。

広げるのは実測してからにします。最初の2週間、実際に使われた操作を記録して、使われなかった操作は外す。渡す前に必要そうな範囲を想像すると、必ず広く見積もります。狭く始めて足りない分を足すほうが、結果として速く安定します。足す作業は数分で終わります。

狭める作業には、業務側の効果もあります。範囲を書き出す過程で、その業務が本当に何に触るのかが分かります。触る先が想定より多い業務は、そもそも任せる単位の切り方が粗いということです。範囲の設計は、業務の設計の点検にもなります。

対策3：期限を短くし、入れ替えを人の作業から外す

3つ目は期限です。ここは仕様書に書かれた要件が参考になります。AIと外部の道具をつなぐために広く使われている接続規格の2025年6月18日版の仕様書では、鍵が漏れたときの影響を小さくするため短い有効期間の鍵を出すべきとされ、公開されている接続元については更新用の鍵を毎回入れ替えることが必須と書かれています。あわせて、鍵を場所を示す文字列の問い合わせ部分に載せてはならないという条件も置かれています。

この考え方を自社の運用に写すと、期限は用途で分けます。人が対話しながら使う接続は短く、夜間の定期処理は処理が終わる長さに合わせ、検証用は日単位で切る。期限の既定値を「無期限」にしないことが、いちばん効く一手です。

入れ替えを人の作業にしないことも同じくらい重要です。人が入れ替える運用は、忙しい月に必ず飛びます。飛んだ結果、期限切れで業務が止まるか、期限を延ばして無期限に戻るかのどちらかになります。自動で入れ替わる仕組みにしたうえで、入れ替えが失敗したことが分かる通知を用意します。

• 夜間の定期処理は、処理の所要時間より短い期限にすると途中で切れる
• 入れ替えた直後に、古い鍵を使い続ける経路が残っていないかを確認する
• 期限切れの通知先を持ち主にする。共有の窓口だけだと誰も見ない
• 検証用の鍵は日単位で切る。延ばす操作を1度でも入れると、無期限に戻りやすい
• 提供元が独自の期限を持つ場合は、短いほうに合わせて棚卸しの周期を決める

失効の手順も期限と一緒に決めます。期限を待たずに無効にする操作は、持ち主と、それ以外にもう1人が実行できる状態にしておきます。1人だけが押せる仕組みは、その1人が休んでいる日に機能しません。

対策4：鍵の置き場所を決め、記録に出さない

4つ目は置き場所です。置いてはいけない場所を先に挙げます。指示の文章の中、設定ファイル、社内の共有文書、やり取りの記録、そして画面の写し。このうち最後の2つが、AIを使う現場で新しく増えた危険です。

なぜ増えたのか。AIは自分が読んだものを、次のやり取りの材料として持ち回ります。鍵を読ませれば、その鍵はやり取りの記録に残ります。記録は保存され、検索でき、他の人にも見えるかもしれません。1度読ませた鍵は、読ませた場所の数だけ複製されたと考えるのが安全です。

対策は2段です。1段目は、鍵を専用の保管場所に置き、処理の実行時にだけ渡す形にすること。2段目は、出力と記録の側で鍵の形を見つけたら止める仕組みを入れることです。後者は簡単な突き合わせで動くので、判断をAIに任せる必要はありません。鍵の書式は決まっているので、機械的に検出できます。

運用の決めごともあわせて置きます。困ったときに設定を丸ごと貼り付けて相談する、という行為をやめる。相談の場に鍵が流れる事故は、攻撃ではなく親切から起きます。貼り付ける前に伏せる箇所を決めておくと、現場で迷いません。

対策5：外部の道具には、誰の資格で動くかを確かめる

5つ目は外部との接続です。ここで確かめるのは機能ではなく主体です。その接続は誰の資格で動くのか。会社共通の資格か、担当者個人の資格か、AI専用の身元か。3つのうちどれなのかを、つなぐ前に1行で書けるようにします。

先の仕様書には、受け取る側の義務も明記されています。受け側は鍵が自分宛てに出されたものかを検証しなければならず、それ以外の鍵を受け付けたり通したりしてはならないとされています。さらに、受け取った鍵をそのまま先へ渡してはならないという条件と、鍵を要求するときに宛先を明示することが必須という条件も置かれています。

実務ではこれを3つの質問に変えます。1つ、この接続に渡す鍵は誰の資格か。2つ、同意の画面は接続ごとに出るか、それとも一度の許可でまとめて通るか。3つ、提供元はこちらの鍵をどこに保管し、いつまで持つか。3つ目に答えられない提供元は、先の事例と同じ位置に立っています。

そして「つないだ先の先」を数えます。連携先がさらに別の道具につながっていれば、鍵の届く範囲はそこまで伸びます。自社が確かめられるのは1段目までなので、2段目以降は契約で縛るしかありません。範囲を狭めることと期限を短くすることが、ここでも最後の保険になります。

対策6：止め方を、動かす前に決める

6つ目は停止です。決めるのは4つだけです。誰が押せるか、押してから何分で止まるか、止めたときに何が止まるか、止めた後に何を入れ替えるか。この4つを1枚に書いて、動かす前に持ち主と情報システムの担当者で確認します。

決めたら1度やってみます。月に1回、実際に1つの身元を止めて、業務が想定どおりに止まり、想定どおりに戻せることを確かめます。訓練していない手順は、事故のときには使えません。手順書だけがある状態は、手順がない状態とあまり変わりません。

渡す前に埋める確認シートと、期限の目安

ここまでの内容を、着手前に埋める形にまとめます。埋まらない項目があるうちは接続しない、という使い方をしてください。

確認する項目	確かめること	埋まらないときの扱い
身元	人のアカウントと分かれているか	分けられない道具なら、触れる範囲を読み取りだけにする
持ち主	個人名で決まっているか	組織名しか書けないなら接続しない
範囲	操作・対象・量の3つで絞れているか	量の上限が付けられないなら、件数を人が渡す形にする
期限	有効期間と自動の入れ替えがあるか	無期限しか選べないなら、月1回の手動の入れ替えを予定に入れる
置き場所	鍵が指示文や記録に出ない作りか	出る作りなら、記録から鍵の形を消す処理を先に入れる
停止	押せる人と止まる時間が分かっているか	測っていないなら、接続前に1度測る
連携先	つないだ先の先まで分かるか	分からないなら、渡す情報を絞って契約で縛る

期限の目安も置きます。人が対話しながら使う接続は数時間から1日、夜間の定期処理は処理の所要時間に合わせる、検証用は作った日から数日。棚卸しは3か月に1回、持ち主が変わったときはその場で。この粒度なら、覚えていなくても運用が回ります。

台帳の見直しの機会も決めます。新しい接続を作ったとき、範囲を広げたとき、持ち主が異動するとき、そして事故があったとき。時期ではなく出来事で見直す形にすると、実態とずれにくくなります。

やってはいけない渡し方

最後に、実際に起きている渡し方を並べます。どれも悪意ではなく、動かすための近道として選ばれています。

• 担当者のアカウントをそのまま使う。記録が人の名前で残り、止める対象が人になる
• 1つの鍵を複数の処理で共用する。1つを止めると関係のない業務まで止まる
• 有効期限を無期限にする。盗まれた鍵が、盗まれたことに気づく前も後も使える
• 鍵を指示の文章や設定ファイルに書く。やり取りの記録に残り、複製されていく
• 困ったときに設定を丸ごと貼り付けて相談する。親切から鍵が外に出る
• 読み取りだけだから安全と判断する。量の上限がなければ、読み取りは持ち出しになる
• 鍵を使ってよいかどうかの判断をAIに任せる。外から来た文章で判断を書き換えられる
• 止め方を決めずに動かす。事故のとき、止める手順を探している間も処理は続く

この一覧の使い方は1つです。接続を作る人が、作る直前に読む。あとから点検の資料にすると、すでに動いているものを止める話になり、実行されません。作る瞬間に読めば、直すのは設定の1行です。

よくある質問

検証のあいだだけ自分のアカウントを使うのは駄目ですか

期限を切れば実務上は成り立ちます。ただし、切る日を先に決めて予定に入れてください。検証の接続が本番に残る事故は、期限を決めなかった場合にほぼ確実に起きます。あわせて、検証のあいだは触れる範囲を読み取りだけにし、扱う件数にも上限を置きます。検証で使った鍵は、専用の身元に移し替えた時点で無効にします。移し替えたら消すところまでを1つの作業として扱ってください。

AI専用の身元を作れない道具はどうすればよいですか

3つの順で考えます。まず、触れる範囲を読み取りだけに落とす。次に、その道具だけのために新しく作った人のアカウントを使い、通常業務では使わない。最後に、期限を短くして手動でも入れ替える。3つ全部を当てて、それでも危険が残るなら、その道具経由でその業務は任せません。専用の身元が持てないことは、業務側の設計を変える理由になります。回避策を積み上げて無理に通す場面ではありません。

期限を短くすると、業務が止まるのではないですか

止まるのは、入れ替えを人がやっているときです。自動で入れ替わる仕組みにすれば、期限が短いほうが止まりにくくなります。理由は、入れ替えの経路が毎日使われていて、壊れていればすぐ分かるからです。逆に、年に1回の入れ替えは、その1回で失敗します。あわせて、入れ替えの失敗が持ち主に届く通知を用意します。通知が無い自動化は、静かに止まります。

止めるために必要な記録は、どこまで残せばよいですか

止める目的だけなら、必要な記録は少ないです。どの身元が、いつ、どの接続先に、何件の操作をしたか。この4つが引ければ、止める対象と影響範囲は特定できます。中身の全文は、止めるためには不要です。記録を厚くすること自体が目的になると、量が増えて肝心の突き合わせができなくなります。監査で求められる記録の項目は別の観点なので、そちらは分けて設計してください。

まとめ

AIエージェントの権限の話は、たいてい「どこまで任せるか」の議論になります。しかし実際に渡っているのは仕事ではなく鍵です。担当者の資格をそのまま使えば、記録に残るのは人の名前になり、使っていない権限まで一緒に渡り、異動で仕組みが壊れ、止めたいときに人の仕事も止まります。2025年12月に公表された危険上位10項目で「身元と権限の乱用」が3番目に置かれているのは、この帰属の空白が現実に事故を生んでいるからです。

鍵は1つ渡して終わりではありません。道具ごと、接続ごとに増え、数が読めなくなります。だから数えて減らすのではなく、期限で減らします。2025年8月に公表された事例では、正規の鍵が盗まれ、8月8日から少なくとも18日まで複数の会社のデータが持ち出されました。狙いはその中にある別の鍵でした。後始末は調査ではなく入れ替えです。入れ替える対象の一覧を持っていなければ、その日に動けません。

決めることは6つに絞れます。人と分けた専用の身元を作り、持ち主を個人名で置く。操作と対象と量の3つで範囲を狭める。期限を短くし、入れ替えを自動にして失敗を通知する。鍵の置き場所を決め、指示文と記録に出さない。外部の接続では誰の資格で動くかを1行で書き、つないだ先の先を数える。そして止め方を4項目で決め、月に1度実際に止めてみる。鍵を使ってよいかどうかの判断は、AIには任せません。外から来た文章で判断は書き換えられるからです。権限を人と分けるというのは、AIを信用しないという話ではなく、任せた範囲を後から言い切れる状態にしておくという話です。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。