AIエージェントに本番環境と認証情報を渡す前に｜権限の絞り方
「本番のログを見て、原因を調べて」
エージェントにそう頼みかけて、手が止まる。調べてもらうには、本番のどこかに触れる鍵が要る。手元の設定ファイルをそのまま渡せば早いのは分かっているけれど、なんとなく、そのまま貼るのはためらわれる。
その「ためらい」は、正しい勘です。この一拍が置けている時点で、もう危ない橋の手前で止まれています。
エージェント型のツールは、読むだけでなくそのまま実行まで進みます。だから渡した鍵の重さが、そのまま起こりうる事故の大きさになります。とはいえ「怖いから使わない」では、上から言われている「AIを活用しろ」に応えられません。
この記事では、渡す鍵を軽くしたまま、エージェントに仕事をしてもらうやり方を整理します。
結論：エージェントに権限を渡すときは、順番が3つです。①渡さない——まず「本物の認証情報がなくても済む形」に置き換えられないかを先に考える（伏せた抜粋、スキーマだけ、検証環境、読み取り専用の複製）。②絞る——渡すと決めたら、人のアカウントではなくエージェント専用の入り口を用意し、読み取りだけ・対象だけ・期限つきに削る。③追える——誰のどの鍵で何をしたかが後から分かる状態にして、止め方を先に決めておく。
覚え方は 渡さない → 絞る → 追える。順番が大事で、いきなり②から入ると「絞ったつもりの強い鍵」を渡してしまいがちです。
全部を今日やる必要はありません。①の「そもそも要るか」を一度考えるだけでも、渡す鍵はかなり軽くなります。
何が起きているのか——エージェントは「読む人」ではなく「実行する人」
チャットに質問するのと、エージェントに作業を任せるのとでは、認証情報の意味がまるで違います。ここが分かると、判断がぐっと楽になります。
1つ目は、実行まで進むこと。チャットなら「こうしてください」と返ってくるだけで、実行するかどうかは人が決めます。エージェントは違います。接続できる鍵を持っていれば、そのまま接続して、そのまま実行します。「消したほうがいい」と判断したら、消せてしまう。良かれと思ってやってくれる分、なおさら止めにくいところがあります（AIにコマンドを書かせて事故らない｜破壊的コマンドを弾く確認の型）。
2つ目は、鍵は一度出すと引っ込められないこと。会話の履歴、ツールのログ、端末のキャッシュ、生成された設定ファイル、コミットしかけた差分。一度貼った文字列は、思っているより多くの場所に残ります。「間違えて貼ったので忘れてください」が効かないのが、認証情報のいちばん厄介な性質です。取り消す方法は、実質ひとつしかありません——その鍵を無効にして作り直すことです。
3つ目は、権限が人の基準で配られていること。あなたのアカウントは、「あなたが判断して使う」前提で権限が付いています。何年か働くうちに、必要だった権限が少しずつ足されて、今はかなり強くなっているはずです。それをそのままエージェントに渡すと、「あなたができること全部」が渡ります。悪意の話ではなく、単に器が大きすぎるという話です（AIに認証・認可の設計を相談する｜権限モデルの穴を潰す詰め方）。
4つ目は、外から指示が紛れ込みうること。エージェントは、課題管理システムのチケット、取り込んだWebページ、ログの中身、他人が書いたコードのコメント——といった外部の文章も読みます。その文章の中に指示のような一文が混ざっていると、それを指示として扱ってしまうことがあります。強い鍵を持ったまま外の文章を読ませる、という組み合わせが危ないわけです（プロンプトインジェクション対策｜外部入力を信用しない基本）。
5つ目は、環境の見分けがつきにくいこと。本番と検証環境の設定は、たいてい似ています。人間でも取り違えるものを、エージェントが完璧に見分けてくれると考えるのは、少し期待が過ぎます。見分けさせるのではなく、そもそも本番の鍵が手元にない状態にするほうが確実です。
裏を返すと、エージェントがとても役に立つ場所もはっきりしています。読み取りだけで済む調査、影響範囲の洗い出し、手順書のたたき台。ここは鍵を軽くしたままでも、十分に力を発揮します。
具体例——つい、やってしまいがちな渡し方
責める話ではありません。どれも「早く終わらせたい」から出てくる自然な動きです。心当たりのある行があれば、そこだけ見直せば十分です。
- 設定ファイルをまるごと貼る：
.envや設定ファイルには、今の作業に要らない鍵まで入っています。1つ必要なだけなのに、十数個渡してしまう形です（AIに設定ファイルを生成させる｜秘密情報の混入を防ぐ手順）。 - 自分の管理者アカウントで動かす：いちばん手っ取り早く、いちばん器が大きい渡し方です。作業は通りますが、通らないはずのものまで通ります。
- 本番DBの接続情報を渡して「調べて」：調べるだけのつもりでも、書き込みができる接続なら、書き込みも起こりえます。「するつもりがない」と「できない」は別物です。
- 端末に入っているものが、そのまま使える状態：クラウドCLIのログイン状態、SSHの鍵、ブラウザのセッション。エージェントに端末の操作を任せると、明示的に渡していないものまで、事実上渡っていることがあります。ここは見落としやすい入口です。
- CIの秘密情報に手が届くところで動かす：パイプラインの設定を直させると、そこに紐づく本番の鍵の範囲まで一緒に動くことがあります。
- 有効期限のない鍵を渡す：一度使ったきりのつもりでも、期限がなければ来年も使えます。使い終わったかどうかは、誰も教えてくれません。
- 顧客データの入った本番から、そのまま抜粋を取る：調査に必要なのはたいてい構造と傾向であって、氏名や連絡先そのものではありません（AIにテストデータを作らせる｜個人情報と偏りに気をつける型）。
そして、社内で誰がどのツールにどの鍵を入れているか分からない、という状態も静かに広がりがちです。個人で契約したツールに業務の鍵を入れる形は、事故が起きたとき誰も把握できません（シャドーAIとは｜放置リスクと現場での向き合い方）。
影響——「あとで直す」がいちばん効きにくい領域
権限まわりが厄介なのは、作業量が多いからではありません。間違えたことに気づけないからです。
- 漏れても、漏れたと分からない：コードのバグはテストが落ちて教えてくれます。鍵の露出は何も落ちません。使われて初めて分かる——つまり、分かったときには終わっています。
- 作り直しのコストが後から効いてくる：怪しいと思った鍵は、作り直すのが正解です。ただ、その鍵をどこで使っているか把握できていないと、作り直した瞬間に別のものが止まります。普段から「どこで使っているか」を把握しているかどうかが、この日に効きます。
- 誰がやったか説明できない：全員が同じ鍵を使い回していると、記録を見ても「その鍵が実行した」までしか分かりません。障害の切り分けでも、社外への説明でも、ここで詰まります。
- クライアントへの説明が難しくなる：受託開発なら、「先方の環境にどう触れたか」を説明できることが信頼の土台です。説明できる形を先に作っておくと、あとで自分を助けます（AI利用前に規約・コンプライアンスで確認する項目｜3方向の型）。
- 一度怖い思いをすると、AI活用そのものが止まる：ひやっとした現場では「エージェントは禁止」に振れがちです。それはそれで、上からのプレッシャーとの板挟みが増えるだけになってしまいます。
少しだけ希望のある話をすると、ここは技術力ではなく段取りで防げる領域です。難しいアーキテクチャは要りません。専用の入り口を1つ作って、読み取りだけにして、期限を切る。それだけで、起こりうる最悪がかなり小さくなります。今日から変えられる部分です。
明日からやること（渡さない・絞る・追える）
上から順に、小さく始められます。今日は①だけで構いません。
1. 渡さない——「本物でないと無理か」を先に確かめる
いちばん効くのに、いちばん飛ばされやすい工程です。頼みたい作業を分解して、本物の認証情報が要る部分だけを残します。
まず、こう問い直してみてください。
- 読むだけか、書くまでか：調査・原因の切り分け・影響範囲の洗い出しは、たいてい読むだけで足ります。
- 本番でないと駄目か：再現できるなら検証環境で十分です。本番でしか出ない事象なら、本番の「読み取り専用の複製」で足りることが多いはずです。
- 全体が要るか、一部で足りるか：ログなら該当する時間帯の抜粋、DBならテーブル定義（スキーマ）だけ、という切り出し方ができます。
- 中身が要るか、形だけで足りるか：多くの相談は、実データそのものより「どんな形のデータか」が分かれば進みます。
そのうえで、渡す前に伏せます。氏名・メールアドレス・電話番号・カード情報・トークン・接続文字列は、XXXXのような固定文字に置き換えてから貼る。手作業でやると必ず抜けるので、伏せる処理を1本スクリプトにしておくと、以後ずっと楽になります。線引きの考え方は社内データをAIに渡す前の線引き｜情報漏えいを防ぐ型にまとめています。
ここまでで、「そもそも渡さなくてよかった」に着地することが、実際かなりあります。
2. 絞る——人のアカウントを貸さず、専用の入り口を作る
渡すと決めたら、あなたのアカウントは使いません。エージェント用の入り口を別に作ります。ここが分かれ目です。
- 専用のアカウント（サービスアカウント）を1つ作る。人と分けておくと、記録も、止めるときも、切り分けが一気に楽になります。
- 読み取り専用から始める。書き込みが要ると分かった時点で、必要な範囲だけ足す。逆順（強く作ってから削る）は、まず削られません。
- 対象を狭める。このテーブルだけ、このバケットだけ、この期間だけ、この名前空間だけ。「全部」から始めない。
- 期限を切る。数時間〜数日で切れる短命な鍵が使えるなら、それがいちばん安全です。無期限の鍵を作るときは、棚卸しの予定とセットにします。
- 本番の鍵は、作業する端末に置かない。踏み台や管理された実行環境の中だけに置く。手元にないものは、うっかり貼れません。
- 危険な操作は人がやる。削除、権限変更、外部への送信、決済、メールの一斉送信。ここはエージェントの権限からそもそも外して、人が実行する形に寄せます（人の確認を挟むAIワークフロー｜HITLの組み方）。
- どこに繋げるかも絞る。必要な宛先以外に通信できない状態にしておくと、外部の文章に引っ張られたときの被害が小さくなります。
- 自走の範囲も一緒に決める。権限と自走は対で効きます。範囲の決め方はAIエージェントの自走はどこまで任せる？止め方と戻し方が使えます。
権限を洗い出すとき、AI自身に手伝ってもらうこともできます。答えを鵜呑みにせず、抜けを探すための叩き台として使うのがちょうどいい距離感です。
次の作業を、AIエージェントに実行させようとしています。必要最小限の権限を設計したいので、手伝ってください。
①この作業を完了するために、本当に必要な操作を列挙してください（読み取り／書き込み／削除などを分けて）。
②そのうち、読み取りだけで済むものと、書き込みが必要なものを分けてください。
③この作業には不要なのに、うっかり一緒に付いてきやすい権限を挙げてください。
④この権限で最悪どこまで壊せるか（想定される最悪の結果）を書いてください。
⑤人が手で実行したほうがよい操作があれば、理由とともに挙げてください。
なお、確実でない部分は「不明」と書いてください。埋めなくて構いません。
作業内容：（ ） 対象の環境：（ ） 使う予定のサービス：（ ）
④を必ず聞くのがコツです。「最悪どこまで」が言語化されると、絞る判断が具体的になります。
3. 追える——記録を残し、止め方を先に決める
事故は起きうる前提で、起きたときに小さく収める準備をします。ここは10分でできて、効果が長く続く工程です。
- 鍵に、それと分かる名前をつける。「誰の・何のための鍵か」が名前で分かると、棚卸しのときに迷いません。
- 記録が残る形にする。専用アカウントにしておけば、いつ・どこから・何をしたかが後から追えます。人と同じ鍵を使い回していると、ここが崩れます。
- 止め方を先に書いておく。「この鍵を無効にする手順」を、1〜2行のメモにしてチームの見える場所に置く。慌てている最中に調べ方を探すのが、いちばん時間を溶かします。
- 使い終わったら消す。調査のために出した一時的な鍵は、その日のうちに片づける。「あとで」は、たいてい来ません。
- 月に一度、棚卸しする。使っていない鍵、担当が変わった鍵、退職者に紐づいた鍵。5分で終わる規模のうちに習慣にしておくと、あとで楽です。
- チームのルールに1行足す。「本番の認証情報はエージェントに渡さない。必要なときは専用アカウントを申請する」。書いてあると、次の人が迷いません（AI利用の社内ガイドラインの作り方｜使ってよい範囲の決め方）。
そして、もし貼ってしまったと気づいたとき。慌てなくて大丈夫です。やることは決まっています——その鍵を無効にして、作り直して、使っている場所を差し替える。順番はこれだけです。隠さず、その日のうちに動けたなら、それが最善の対応です。
権限の絞り方チェックリスト（コピーして使えます）
上から順に見ていくためのリストです。全部に○が要るわけではありません。気になった行だけで十分です。
① 渡さない（頼む前）
- その作業は、読み取りだけで足りないか確かめたか
- 検証環境や読み取り専用の複製で代替できないか確かめたか
- 全体ではなく、必要な期間・範囲の抜粋で足りないか確かめたか
- 実データではなく、構造（スキーマ）や形だけで足りないか確かめたか
- 貼る前に、氏名・連絡先・トークン・接続文字列を伏せたか
- 設定ファイルを、必要な項目だけに絞って渡したか（まるごと貼っていないか）
② 絞る（渡すと決めたら）
- 自分の個人アカウントではなく、エージェント専用の入り口を用意したか
- 読み取り専用から始めているか（書き込みは必要が確認できてから）
- 対象を狭めたか（このテーブル・このバケット・この期間だけ）
- 鍵に有効期限を設定したか、無期限なら棚卸しの予定を決めたか
- 本番の認証情報を、作業端末に置かずに済む形にしたか
- 削除・権限変更・外部送信・決済を、権限から外したか
- 接続できる宛先を、必要なものだけに絞ったか
- 外部の文章（チケット・Web・ログ）を読ませる作業と、強い権限を同時に与えていないか
- 自走の範囲（どこで止めるか）も一緒に決めたか
③ 追える（渡したあと）
- 鍵に、誰の・何のためかが分かる名前をつけたか
- いつ・何をしたかが後から追える記録が残る形か
- その鍵を無効にする手順を、見える場所にメモしたか
- 一時的に出した鍵を、使い終わったあと消したか
- 棚卸しの日を決めたか（退職者・担当変更ぶんを含む）
- チームのルールに、本番の認証情報の扱いを1行書き足したか
この記事のまとめ
エージェントに権限を渡す話は、「信用するかしないか」の話ではありません。器の大きさを、作業に合わせて調整するという、ごく普通の段取りの話です。
やることは3つ。①渡さない——本物の認証情報が要るのはどこまでかを先に切り分け、伏せてから渡す。②絞る——専用の入り口を作り、読み取りだけ・対象だけ・期限つきに削る。危険な操作は権限から外す。③追える——記録が残る形にして、止め方を先に決めておく。
この3つがあると、何かあっても「その鍵を1本無効にする」で収まります。そこまで用意できていれば、もっと安心して、もっと大きく任せられるようになります。
権限を絞る作業は、終わっても誰にも褒められません。画面は昨日と同じで、機能がひとつ増えたわけでもない。それでも、絞っておいたから起きなかった事故というのは確かにあって、起きなかったぶん、記録にも残りません。
今日、鍵をそのまま貼る前に一拍置けたなら、それはもう十分な仕事です。全部を今週やらなくて大丈夫です。専用の入り口を1つ作って、読み取りだけにして、期限を切る。まずはその1回で十分です。
よければ、こちらも
- 任せる範囲そのものを決めるならAIエージェントの自走はどこまで任せる？止め方と戻し方
- 外部の文章を読ませる前にプロンプトインジェクション対策｜外部入力を信用しない基本
- 何をどこまで渡すかは社内データをAIに渡す前の線引き｜情報漏えいを防ぐ型
- 設定ファイルの扱いはAIに設定ファイルを生成させる｜秘密情報の混入を防ぐ手順
- 危ないコマンドを弾くならAIにコマンドを書かせて事故らない｜破壊的コマンドを弾く確認の型
- 人の確認をどこに挟むかは人の確認を挟むAIワークフロー｜HITLの組み方
- チームのルールにするならAI利用の社内ガイドラインの作り方｜使ってよい範囲の決め方