AIエージェントの権限を開発でどう決める？本番とデータの線引き
開発AIエージェントに権限を与えるときは、「何をさせたいか」より先に「何に触れさせないか」を決めておくと、事故を防ぎやすくなります。この記事では、操作の種類・環境・データ・秘密情報という4つの視点で、権限の線引きを整理します。あわせて、最初は狭く始めて段階的に広げる決め方と、人が承認を挟む場面も紹介します。
開発AIエージェントに権限の設計が必要な理由
AIエージェントとは、指示を受けたあとに、ファイルの読み書き、コマンドの実行、外部サービスの操作といった作業を、自分で順番に判断しながら進めるAIのことです。質問に文章で答えるだけのチャットとは違い、実際に環境へ変更を加えられる点が大きな違いです。
この「実行できる」という性質が、便利さと危うさの両方を生みます。コードを書いてテストを回し、不具合を直すところまで任せられる一方で、与えた権限の範囲なら、設定ファイルの書き換えやデータの削除も技術的にはできてしまいます。
情報セキュリティには「最小権限の原則」という基本的な考え方があります。作業に必要な範囲の権限だけを渡し、それ以上は渡さないというものです。人間の担当者に対しても使われる原則ですが、AIエージェントには特に当てはめたい理由があります。
- 作業が速く、誤った操作も短時間で積み重なる
- 指示の解釈が人の意図とずれることがある
- 人が見ていない間にも作業が進む
AIが想定外の操作をした例は、実際に報告されています。たとえばClaudeが実サイトで想定外の操作、Anthropicが報告で取り上げています。AIの能力が上がっても、「間違えたときに被害がどこまで広がるか」は、与えた権限の範囲で決まります。だからこそ、AIの賢さを信じることとは別に、権限の設計を先に考えておきたいところです。
権限を決める前に整理したい4つの対象
権限の線引きは、触れる対象ごとに考えると整理しやすくなります。開発AIエージェントが関わる対象は、大きく次の4つです。
1. コード（リポジトリ）
ソースコードを読む、書く、履歴に反映する操作です。コードは変更しても履歴から戻せることが多く、比較的リスクを管理しやすい対象です。ただし、レビューを通さずに本流へ反映できる状態にしてしまうと、不具合や脆弱性がそのまま混ざります。この点はAI生成コードのセキュリティ｜確認点と人の役割でも触れています。
2. 実行環境
開発用、検証用、本番用といった、プログラムが動く環境です。どの環境に接続できるかによって、起こりうる被害の大きさがまるで変わります。
3. データ
テスト用のダミーデータ、検証用のデータ、実際の利用者の情報が入った本番データなど、扱うデータの種類です。個人情報や取引先の情報が含まれるかどうかが、最大の分かれ目になります。
4. 秘密情報
APIキー、パスワード、サーバーへの接続情報、クラウドの認証情報などです。これが渡ってしまうと、AIが触れる範囲は、与えたつもりの権限を超えて広がります。
この4つを分けて考えると、「コードは書かせるが、本番データには触れさせない」「検証環境は触らせるが、秘密情報は渡さない」といった、細かな線引きができるようになります。
操作の種類で分ける：読む・書く・実行する・消す・公開する
同じ対象でも、操作の種類によってリスクは異なります。次のように分けて、種類ごとに許可の基準を決めておくと判断が早くなります。
| 操作の種類 | 具体例 | 基本の考え方 |
|---|---|---|
| 読む | コードの閲覧、ログの確認 | 範囲を絞ったうえで許可しやすい |
| 書く | ファイルの作成・編集 | 作業用の場所に限り許可し、本流への反映は人が確認する |
| 実行する | テストの実行、コマンドの実行 | 隔離された環境の中に限る |
| 消す | ファイルやデータの削除 | 原則として人の承認を挟む |
| 公開・送信する | 本番への反映、外部への送信 | 人が実行するか、明示的に承認する |
特に気をつけたいのは、「消す」と「公開・送信する」の2つです。どちらも、あとから元に戻すのが難しい操作だからです。削除したデータは復元できない場合があり、外部へ送った情報は取り戻せません。
反対に、「読む」は比較的許可しやすい操作ですが、ここにも落とし穴があります。読んだ内容がAIサービスの外部に送られる仕組みになっている場合、機密情報の取り扱いが問題になります。読むことと外部に送ることは、別の線として考えておきたいところです。この観点は生成AI開発の情報漏洩を防ぐ確認点｜機密と事業アイデアで詳しく整理しています。
環境ごとの線引き：開発・検証・本番
本番環境は、直接触らせないところから始める
新規事業のシステムでも、環境は少なくとも「開発」「検証」「本番」に分けて考えるのが基本です。そのうえで、開発AIエージェントの権限は次のように考えると整理しやすくなります。
- 開発環境：コードの編集、テストの実行まで任せる範囲。失敗しても影響が外に出ない
- 検証環境：本番に近い状態で動作を確認する場所。ダミーデータを使う前提で、反映は人の承認を挟む
- 本番環境：原則としてAIには直接触らせない。変更は人がレビューしたうえで反映する
本番への接続情報は、そもそもAIに渡さないのがいちばん確実です。接続できない環境は、操作を間違えようがありません。指示で「本番には触らないで」と伝えるより、触れない状態にしておくほうが確実です。
検証環境にはダミーデータを使う
検証環境で本物のデータを使うと、検証のつもりで個人情報が扱われてしまいます。実物に近い動きを確かめたいときは、本物に似せたダミーデータを用意する方法があります。作り方はプロトタイプのダミーデータの用意のしかた｜実物に近づけるで紹介しています。
環境のアカウントは誰のものか
もう1点、見落とされやすいのが、環境そのもののアカウントの名義です。サーバーやクラウドのアカウントを誰が持ち、誰が管理者権限を握るのかは、AIに渡す権限以前の問題です。外注先を含めて開発する場合は、システム開発のサーバー名義は誰にする？外注前の決め方も合わせて確認しておくと安心です。
データの線引き：個人情報と事業の機密をどう扱うか
データについては、次の3段階で考える方法があります。
- 渡してよいデータ：公開情報、ダミーデータ、匿名化したデータ
- 条件つきで渡すデータ：氏名などを伏せた加工済みのデータ、社内向けの資料の一部
- 渡さないデータ：個人が特定できる本番データ、取引先との契約情報、公開前の事業アイデアの核心部分
新規事業では、事業のアイデアそのものが機密になる場面があります。AIに資料を読ませる際、その内容がAIサービス側でどう扱われるのかは、利用する製品の規約や設定によって異なります。学習に使われるかどうか、保存される期間、管理者側で設定できる範囲などは、使う前に公式の資料で確認しておきたい項目です。
個人情報については、そもそも何を集め、どこに置くのかというシステム設計の段階で考えておく必要があります。設計前の確認点は新規事業の個人情報とシステム設計｜設計前に確認する点にまとめています。
見落としやすいのが、ログへの出力です。エラー内容や処理の記録に個人情報が混ざり、それをAIが読んだり、外部のツールへ送ったりする経路ができてしまうことがあります。「データを渡さない」だけでなく、「データが流れ込む経路がないか」まで見ておきたいところです。
秘密情報の扱い：渡さない、渡しても絞る
APIキーや認証情報は、権限の設計のなかでも特に慎重に扱いたい対象です。基本の考え方は次のとおりです。
- コードに直接書かせない：キーを書いたコードは、履歴に残り、共有されやすい
- 環境変数や専用の管理の仕組みに置く：コードとは別の場所で管理する
- AIが読めるファイルの範囲から外す：設定ファイルや秘密情報のファイルは読み取り対象に含めない
- 渡す場合は、AI専用の認証情報を発行する：人の管理者アカウントを共用せず、必要な操作だけ許可したものを使う
- 期限と範囲を決める：一定期間で無効になるようにし、不要になったらすぐ失効させる
AI専用の認証情報にしておくと、問題が起きたときにそれだけを無効にでき、被害の範囲を狭められます。人の管理者アカウントをAIに使わせると、何をしたのかの区別もつきにくくなります。
最初は狭く始めて、実績を見て広げる
権限は、一度に決め切る必要はありません。最初に狭く設定して、様子を見ながら広げる進め方のほうが現実的です。たとえば次のような段階が考えられます。
段階1：読み取りと提案だけ
コードを読み、修正案や設計案を文章で出させる段階です。環境への変更は一切せず、AIの理解の精度や判断の癖を確かめます。
段階2：作業用の場所への書き込みとテスト実行
本流とは別の作業用ブランチ（変更を試すための枝分かれした場所）でコードを書かせ、テストも実行させます。本流への反映は、人がレビューしてから行います。レビューの観点はAIコードレビューで指摘される点と人が判断する点が参考になります。
段階3：検証環境への反映
検証環境への反映までを許可します。ただし、反映の前には人の承認を挟みます。
段階4：本番への反映は人が実行
本番への反映は、人が内容を確認したうえで実行します。AIが準備と確認を支援しても、最後のスイッチは人が押す形を保ちます。
次の段階へ広げる条件は、事前に決めておくと判断がぶれません。たとえば「一定期間、操作の記録に想定外の動きがなかった」「レビューで見つかる問題の傾向が把握できた」といった条件です。広げるのは、問題がなかった範囲に限ります。
指示だけに頼らず、仕組みでも制限する
「この操作はしないでください」とAIに指示しておくことは大切ですが、それだけでは十分とは言えません。指示は守られるとは限らず、AIが長い作業のなかで見落としたり、別の解釈をしたりする可能性があるからです。権限は、指示と仕組みの両方で守る考え方が現実的です。
仕組みで制限する
- 隔離された環境で動かす：AIの作業場所を、本番や他のデータから切り離す
- 権限の絞られたアカウントを使う：技術的にできない操作は、間違っても実行されない
- 接続先を限定する：外部への通信は、許可した宛先だけに絞る
こうした仕組みについては、関連する動きが出ています。MXCが正式版に、AIエージェントの権限をOSで制限では、AIエージェントの権限をOSの側で制限する話題を扱っています。また、Perplexity、エージェント隔離環境SPACEをOSS公開は、エージェントを隔離した環境で動かす仕組みの公開を取り上げた記事です。許可した依頼だけ動く開発AI、DeepSeekが試作版をMIT公開も、許可の範囲という観点で参考になります。
なお、ツール自体に脆弱性が見つかることもあります。Pwn2OwnでCodexとLiteLLMの脆弱性を実演のように、AIまわりのツールも攻撃の対象になりうる事例が出ています。AIに渡した権限を守る仕組みは、ツールを使い始める時点で一度確認し、その後も更新情報を追っておきたいところです。
人の承認を挟む操作を決めておく
仕組みで制限しきれない部分は、運用のルールで補います。次のような操作は、実行の前に人の承認を必須にしておくと安心です。
- ファイルやデータの削除
- 本番環境への反映
- 外部サービスへの情報の送信
- 費用が発生する操作（クラウドの資源の追加など）
- ライブラリなど、外部の部品の追加や更新
- 認証や権限の設定の変更
外部の部品の追加も見落とされがちです。AIが便利なライブラリを提案して追加すると、そこに脆弱性や、利用条件の制約が含まれる可能性があります。ライセンスや著作権の観点はAI生成コードの著作権｜事業で使う前の確認点で整理しています。
操作の記録を残す
AIが何を実行したのかを、あとから追える状態にしておくことも重要です。記録があれば、問題が起きたときに原因を特定でき、権限の見直しの材料にもなります。「どの操作を、いつ、どの権限で行ったか」が残る設定にしておきたいところです。
外注で開発AIを使うとき、発注側が確認したいこと
開発会社に依頼する場合、AIエージェントの権限は発注側から見えにくくなります。だからこそ、契約や相談の段階で、次の点を確認しておくと安心です。
- AIにどの環境まで接続させるのか。本番環境に触れる設計になっていないか
- 発注側のデータや資料を、AIにどう渡すのか。外部のAIサービスに送られる範囲はどこか
- 認証情報の管理は誰が行い、AI専用の認証情報を使っているか
- AIが書いたコードを、誰がどの観点で確認しているか
- 操作の記録は残されているか。問題が起きたときの対応の流れはあるか
これらの確認は、疑うためではなく、同じ前提に立って進めるためのものです。質問に具体的に答えてもらえるかどうかは、開発会社を見極める手がかりにもなります。確認項目の全体像はAI受託開発に依頼する前に確かめたい6つのことにまとめています。AIが関わる開発でも、品質の最終的な確認に人が関わる意味は変わりません。この点はAI開発でも品質には人の確認が必要な理由で述べています。
まとめ
開発AIエージェントの権限は、能力への期待ではなく、「間違えても被害が広がらない範囲」を基準に決めるのが基本です。この記事の要点は次のとおりです。
- 権限は「コード・実行環境・データ・秘密情報」の4つの対象と、「読む・書く・実行する・消す・公開する」の操作の種類で分けて考える
- 本番環境と本番データは、原則としてAIに直接触らせない。接続情報を渡さないことが最も確実な線引きになる
- 認証情報はコードに書かせず、渡す場合はAI専用のものを、範囲と期限を絞って使う
- 権限は読み取りと提案から始め、記録を見ながら段階的に広げる
- 指示だけでなく、隔離環境や権限の絞られたアカウントなど、仕組みでも制限する。削除・本番反映・外部送信は人の承認を挟む
- 外注の場合は、AIの接続範囲、データの渡し方、認証情報の管理、操作の記録を事前に確認する
線引きの詳しさは、扱うデータや事業の性質によって変わります。唯一の正解があるわけではないため、最初は狭く設定して、運用のなかで見直していく姿勢が現実的です。
JustFitは、AIを活用した独自の開発基盤「LAF」を使い、要件定義・設計・DB設計・実装・テスト・レビューという工程ごとに役割を与えた複数の専門AIが、チームとして開発を進めます。人の役割は、何を作るかを決めることと、品質の最終判断です。新規事業のシステムをAIと一緒に作るなかで、権限や情報の扱いに不安がある段階でも相談できます。進め方の全体像はJustFitのサービス紹介でご覧いただけます。