先に要点
AIエージェントに障害調査や運用補助を任せると、最後に必ず出てくるのが 本番DBを見せてもいいのか という問題です。
ログだけでは原因が分からない。管理画面の表示とDBの値が合わない。問い合わせ対応で顧客の状態を確認したい。
そういう場面では、本番DBを読めると確かに便利です。
ただし、本番DBはアプリの中心です。
会員情報、注文、契約、決済状態、権限、監査ログ、問い合わせ履歴など、間違って見せても、間違って更新しても、影響が大きいデータが入っています。
この記事では、本番DBをAIエージェントに触らせてよいかを、読み取り専用から始める という現実的な判断基準で整理します。
AIエージェント全体の権限設計は AIエージェントの権限設計とは？読み取り・書き込み・承認を分ける実務チェック、停止条件は AIエージェントの停止条件とは？自動実行を安全に止める設計ポイント もあわせて読むとつながりやすいです。
まず結論：いきなり更新権限は渡さない
本番DBをAIエージェントに触らせるか迷ったら、まず次の順番で考えます。
| 段階 | AIに許可すること | 判断 |
|---|---|---|
| 1. ダミーデータ | 検証用DBや匿名化データを読む | 最初に試しやすい |
| 2. 本番DBの限定読み取り | 読み取り専用ユーザーで一部テーブルやビューを見る | 用途とログ管理を決めれば現実的 |
| 3. SQL案の作成 | 更新SQLや調査SQLの下書きを作る | 人間レビュー前提なら使いやすい |
| 4. 承認付き実行 | 承認済みSQLだけ限定実行する | 対象件数、バックアップ、戻し方が必須 |
| 5. 自動更新 | AI判断で本番DBを更新する | かなり慎重に扱う。多くの現場では避ける |
つまり、答えは 触らせてよいか ではなく、どの権限で、どの範囲を、何のために触らせるか です。
最初から SELECT / INSERT / UPDATE / DELETE をまとめて渡すのは危険です。
読み取り専用でも安全とは限らない
読み取り専用なら更新はできません。
それだけでも事故の種類はかなり減ります。
ただし、読み取り専用でも次のリスクは残ります。
- 個人情報や顧客情報をAIに渡してしまう
- 認証情報やトークンの断片を読ませてしまう
- 社内の売上、契約、障害、セキュリティ情報が会話ログに残る
- AIが出した要約に機密情報が混ざる
- 読み取り結果を外部サービスへ送信してよい契約か曖昧
- 読める範囲が広すぎて、実質的に全DBをコピーできる
OWASPのSQL Injection Prevention Cheat Sheetでも、読み取りだけ必要なアカウントには必要なテーブルへの読み取りだけを付与し、必要ならビューでアクセス範囲を制限する考え方が説明されています。
つまり、読み取り専用は出発点であって、全テーブルSELECT可 が安全という意味ではありません。
AIに読ませやすいDB情報
AIエージェントに読ませやすいのは、業務影響が小さく、機密性が低く、調査に必要な範囲が限定されている情報です。
たとえば次のようなものです。
- マスキング済みのエラーログテーブル
- ステータス集計用のビュー
- 日別件数、処理件数、キュー滞留数
- 公開済みコンテンツのメタ情報
- 検証環境のデータ
- 個人を特定できない統計値
- 対象顧客を特定しないサンプルデータ
逆に、AIにそのまま読ませる前にかなり慎重に見るべきものもあります。
- 氏名、住所、電話番号、メールアドレス
- 決済情報、請求情報、契約情報
- 認証情報、APIキー、セッション、リセットトークン
- 権限テーブル、管理者情報
- 未公開の障害情報、脆弱性情報
- 顧客ごとの問い合わせ履歴
- 監査ログや操作履歴
PII や顧客情報を扱う場合は、先にマスキング、集計、項目削除、ビュー化で目的を達成できないか考えます。
読み取り専用ユーザーを作る
本番DBをAIエージェントから参照させるなら、アプリ本体のDBユーザーを流用しない方がよいです。
AIエージェント用に、読み取り専用のDBユーザーを別に作ります。
考え方としては次です。
- アプリ本体のDBユーザーを使い回さない
- AIエージェント用のDBユーザーを分ける
SELECTだけにする- 必要なDB、テーブル、ビューだけに絞る
INSERT、UPDATE、DELETE、DROP、ALTER、GRANTは付けない- 接続元IPやネットワークを制限する
- 長期利用しないなら期限を決める
MySQLでは CREATE USER や GRANT によりユーザーと権限を分けられます。
たとえば、必要なビューだけに SELECT を付けるような構成にすると、AIエージェントが見られる範囲を狭くできます。
CREATE USER 'ai_readonly'@'10.0.0.%' IDENTIFIED BY 'strong-password';
GRANT SELECT ON app_db.ai_safe_order_summary TO 'ai_readonly'@'10.0.0.%';
GRANT SELECT ON app_db.ai_safe_error_summary TO 'ai_readonly'@'10.0.0.%';
これは例です。実際にはパスワード管理、接続元、ローテーション、監査ログ、運用手順まで含めて設計します。
大事なのは、AIへの指示で 更新しないで と言うより、DB権限として更新できない状態を作ることです。
ビューで見せる範囲を絞る
読み取り専用ユーザーでも、元テーブルをそのまま見せると情報が多すぎることがあります。
その場合は、AIエージェント向けのビューを作る方法があります。
ビューでは、次を制限できます。
- 必要な列だけ見せる
- 個人情報を除外する
- 顧客IDをハッシュ化または別IDにする
- 対象期間を絞る
- ステータスや件数だけ見せる
- 調査に不要な本文や備考を隠す
たとえば問い合わせ調査でも、最初から問い合わせ本文を全文見せる必要がない場合があります。
ステータス、受付日時、カテゴリ、処理時間、担当キューだけで十分なら、本文やメールアドレスを見せないビューを作る方が安全です。
SQL案は作らせても、実行は分ける
AIエージェントはSQL案の作成が得意です。
ただし、作れることと実行してよいことは別です。
本番DBでは、次のように分けると安全です。
| 作業 | AIに任せる範囲 | 人間が見るポイント |
|---|---|---|
| 調査SQL | SELECT文の案を作る | 対象テーブル、条件、件数、負荷 |
| 更新SQL | UPDATE文の下書きを作る | WHERE条件、対象件数、戻し方 |
| 削除SQL | 原則は削除候補の抽出まで | 復元可否、代替案、バックアップ |
| マイグレーション | 案と影響説明を作る | ロック、ダウンタイム、ロールバック |
AIが作ったSQLをそのまま本番で実行するのは避けます。
特に UPDATE、DELETE、ALTER TABLE、DROP、大量JOIN、全件スキャンしそうな集計は、人間レビューと検証環境での確認を挟むべきです。
承認付き実行にするなら何を出すか
どうしてもAIエージェントに本番DB操作を実行させるなら、承認付きにします。
OpenAI Agents SDK の Human-in-the-loop でも、承認が必要なツール呼び出しで実行を中断し、承認または拒否後に再開できる流れが説明されています。
承認画面や承認通知には、少なくとも次を出します。
- 実行するSQL
- 実行対象のDBと環境
- 対象テーブル
- 事前SELECTの結果件数
- 変更前後の差分
- 想定される影響
- バックアップやスナップショットの有無
- ロールバックSQLまたは戻し手順
- AIがその操作を提案した理由
- 実行者、承認者、時刻
このSQLを実行します。承認しますか？ だけでは足りません。
承認者が判断できる材料を出さないと、承認は形だけになります。
更新・削除を許可する前のチェック
AIエージェントに本番DBの更新や削除を任せる前に、次を確認します。
- 検証環境で同じSQLを試した
- 対象件数を事前に確認した
WHERE条件が明確- 更新前の値を保存している
- バックアップまたはスナップショットがある
- ロールバック手順がある
- 実行時間とロック影響を見た
- 承認者がDB影響を理解できる
- 監査ログにSQL、対象件数、結果が残る
- 失敗時の停止条件がある
このチェックを通せないなら、AIには更新SQLの下書きまでを任せる方が安全です。
本番DBを触らせない方がよいケース
次のような場合は、AIエージェントに本番DBを直接触らせない方がよいです。
- DB権限を細かく分けられていない
- アプリ本体のDBユーザーを使い回すしかない
- 監査ログが残らない
- 個人情報や認証情報をマスキングできない
- バックアップや復旧確認ができていない
- 承認者がSQLを読めない
- 対象件数を事前確認できない
- AIの会話ログやトレースの保存方針が曖昧
- 外部AIサービスへ本番データを送る契約確認ができていない
この状態で本番DBを触らせると、便利さよりリスクが勝ちやすいです。
まずはログ、メトリクス、匿名化データ、検証DBから始める方が現実的です。
実務でのおすすめ導入順
本番DBをAIエージェントに関わらせるなら、次の順番がおすすめです。
1. ダミーデータ
検証環境や匿名化データで、AIがどの程度役に立つかを確認します。
2. 限定ビュー
本番DBの元テーブルではなく、AI向けに絞った読み取り専用ビューを使います。
3. SQL下書き
調査SQLや更新SQLの案を作らせ、人間がレビューして実行します。
4. 承認付き実行
対象件数、バックアップ、戻し方を確認したうえで、承認済みSQLだけを限定実行します。
いきなり本番DB更新を自動化する必要はありません。
読み取り専用でも、障害調査、問い合わせ一次確認、件数集計、設定確認には十分役立ちます。
監査ログに残すこと
本番DBをAIエージェントが参照または操作するなら、監査ログを残します。
最低限、次を記録します。
- 依頼者
- AIエージェントの実行ID
- 実行日時
- 接続先環境
- 実行したSQLまたはSQLテンプレート
- 対象テーブル
- 返却件数
- 更新件数
- 承認者
- 承認または拒否の結果
- エラー内容
- ロールバック有無
ただし、SQL結果の全文をログに残すと、ログ自体が機密情報の塊になります。
必要に応じて、結果本文ではなく件数、ハッシュ、要約、マスキング済みサンプルだけを残します。
まとめ
本番DBをAIエージェントに触らせるなら、最初は読み取り専用から始めるのが基本です。
ただし、読み取り専用でも、読めるデータの機密性、ログ保存、契約、マスキング、アクセス範囲を確認する必要があります。
更新、削除、マイグレーション、権限変更をAIに自動実行させるのはかなり慎重に扱います。
使うとしても、SQL案の作成、検証環境での確認、対象件数確認、人間承認、監査ログ、ロールバック手順をセットにするべきです。
本番DBは、AIエージェントにとって強力な情報源ですが、同時に事故の影響が大きい場所です。
AIに触らせるか ではなく、読ませる範囲をどう絞るか 書き込みをどこで止めるか 後から説明できるか で判断すると、現実的に進めやすくなります。
参考
- OWASP: Least Privilege Principle
- OWASP Cheat Sheet Series: SQL Injection Prevention Cheat Sheet
- OWASP Cheat Sheet Series: Database Security Cheat Sheet
- Oracle MySQL Documentation: Get a User Account and Required Privileges
- OpenAI Agents SDK: Human-in-the-loop