ソートリーダー

エージェント型AIとデータベース開発：AIが実際にクエリを実行できるようになると何が変わるのか

mm
公開日
Unite.AI を Google の優先ソースに追加

ここ数年、AIを活用したデータベース開発は、比較的安心できるモデルに沿って進められてきました。開発者が要件を説明し、AIがSQLを生成します。開発者はそれを読み、問題がありそうな箇所を修正したうえで、実行するかどうかを判断します。

このワークフローでは、重要な境界線が保たれてきました。AIはアクションを提案できますが、それをデータベースに反映させるかどうかは、依然として人間が判断します。

しかし、エージェント型AIの登場により、その境界線は崩れ始めています。現在、AIシステムはスキーマを調べ、クエリを実行し、結果を解釈して、次に取るべきアクションを判断できます。最近の調査によると、すでに組織の62%がAIエージェントの実験を行っており、23%は企業内のいずれかの領域でエージェント型システムを拡大していると回答しました。

そのため、データベースチームは早急に答えを出すべきアーキテクチャ上の問いを抱えています。AIがSQLを実行できるかどうか、ではありません。実行できます。本当に問うべきなのは、アシスタントがコードを提案するだけの存在から、データベースに対して実際に操作を行う存在へと変わったとき、何が変わるのか、そしてその自律性をどこまで厳しく制御すべきかです。

提案から実行へ

インデックスに関する単純な判断を一つ取り上げると、この変化が重要な理由がよく分かります。

エージェントは遅いクエリを見つけ、スキーマを調べ、インデックスが役立つ可能性に気づき、それを作成してから、ワークロードを再実行し、結果を確認します。

たとえば、次のようなごく一般的な処理を実行する場合があります。

CREATE INDEX IX_Orders_CustomerId
ON Orders(CustomerId);

このSQL文に特別なところはありません。AIアシスタントがまったく同じ内容を提案することもあるでしょう。違いは、最終判断を誰が下すかです。

アシスタントの場合、開発者が提案を確認し、テストしたうえで、実行するかどうかを判断します。AIは助言しますが、実行するのは人間です。一方、実行権限を持つエージェントなら、システム自身が判断を下し、承認を待たずに処理を進められます。

その判断が正しければ、ワークフローは速くなります。しかし、エージェントが全体像を把握しているとは限りません。アプリケーションの依存関係、ビジネスルール、ワークロードのパターン、メンテナンス時間帯など、システムを運用する人には明らかな情報や背景を見落とす可能性があります。

そのためエージェントは、技術的には妥当に見える判断を下しても、実際に動作する環境固有の制約や要件を踏まえると、誤った判断をしていることがあります。

不適切な SELECT クエリは実行が遅くなるだけかもしれません。不適切な UPDATE 処理はテーブル全体をロックしたり、意図した範囲を大幅に超える行に影響を及ぼしたりする可能性があります。あるクエリで使われるインデックスが、ほかのクエリにオーバーヘッドを加えるだけで、不要な場合もあります。エージェントは完全な運用状況を把握できず、あらゆるユースケースをテストできないことがあるため、エージェントが依存関係を把握していなかったものを、スキーマ変更によって壊してしまう可能性もあります。

つまり、問題はエージェントが適切なデータベース判断を下せないことではありません。実際には、適切な判断を下せることも少なくありません。問題なのは、そうした判断に基づいてエージェントが行動できるようにするなら、その権限がどこまで及ぶのか、エージェントがどのような情報を参照できるのか、人間がどの時点で介入する必要があるのか、そして結果に対する責任を誰が負うのかを、チームがより明確にする必要があることです。

Gartnerは、リスク管理が不十分であることなどを理由に、エージェント型AIプロジェクトの40%超が2027年末までに中止されると予測しています。データベースチームが得るべき教訓は明快です。実行権限を与えるのは、管理策を整えた後であり、その前ではありません。

安全に委任できるのはどの作業か？

データベース関連の作業には、ほかの作業よりもはるかに安全に任せられるものがあります。

クエリ分析はその好例です。エージェントはクエリの統計情報を調べ、実行計画を取得し、インデックスやテーブル構造を確認して、本番データを変更せずに有効そうな修正を提案できます。

たとえば、次のように大規模な Orders テーブルを繰り返しスキャンするクエリを見つけることがあります。

SELECT OrderId, OrderDate, Total
FROM Orders
WHERE CustomerId = @CustomerId
ORDER BY OrderDate DESC;

そこから、スキャンの原因を説明し、インデックスを提案して、DDLを生成できます。役に立つために、それを CREATE INDEX 実行する権限まで必要なわけではありません。

同じことは、次のような作業にも当てはまります。

  • 実行計画の説明。
  • 不足している、または不要なインデックスの特定。
  • 検出する SELECT * クエリやSARG不能な述語へのフラグ付け。
  • 結合やフィルターのプッシュダウンの確認。
  • 依存関係とスキーマの確認。
  • SQLエラーのトラブルシューティング。
  • SQLスクリプトの最適化。

実務上の線引きは単純です。問題を理解するのに十分なアクセス権をエージェントに与えつつ、データベースを変更する権限まで自動的に与えないことです。広範な閲覧権限は役立つ場合がありますが、広範な実行権限を与えるかどうかは別の判断です。

人間による制御がなお重要な場面

データベースに関する判断のなかには、依然として人間の関与が必要なものがあります。たとえば、エージェントが AuditLog 数億行を含むテーブルを見つけ、古いレコードを削除すべきだと判断したとします。

DELETE FROM AuditLog
WHERE CreatedAt < DATEADD(year, -2, GETDATE());

SQLとして完全に正しくても、その判断がひどく不適切なことはあります。

規制上の方針により、7年間の保存が求められる場合もあります。アプリケーションがこれらの記録に依存しているかもしれません。トランザクションログの肥大化を避けるため、削除は複数回に分けて行う必要があるかもしれません。削除前に記録をアーカイブしなければならない場合もあります。

こうした要件は、いずれも必ずしもスキーマに存在するとは限りません。

データベースの作業をコード生成の問題として扱うことには、こうした限界があります。データベースには技術的な構造がありますが、それらをめぐる判断は、技術的な操作を通じて表現されるビジネス上の判断であることが少なくありません。同じ慎重さが求められる操作には、次のようなものがあります。

  • DROP および破壊的な ALTER ステートメント；
  • 本番環境 UPDATE および DELETE 運用；
  • 大規模なデータ移行；
  • ロールと権限の変更；
  • 制約の変更；
  • レプリケーションや可用性に影響する変更；
  • ビジネスロジックを含むストアドプロシージャのデプロイ。

技術的に正しい操作が、必ずしも適切な操作とは限りません。したがって、人間による承認を、エージェント型AIにとって不便な制約と見なすべきではありません。影響の大きいデータベース操作では、承認はアーキテクチャの一部です。

AIエージェントにも最小権限の原則を適用する

データベースチームが避けるべき安易な方法の一つは、エージェントに開発者の既存の認証情報を使わせることです。手軽ではありますが、そうするとエージェントには、その開発者がすでに持っている権限がすべて与えられてしまいます。

より安全なのは、ユーザーやサービスに適用するのと同じ方法、つまり最小権限の原則です。Microsoftは、タスクに必要な権限だけを付与し、特権を伴うアクティビティを監視することを推奨しています。

たとえば、パフォーマンス分析エージェントに必要なのは、次のような権限かもしれません。

CONNECT
SELECT
VIEW DATABASE STATE
VIEW DEFINITION

おそらく必要ないのは、次のような権限です。

ALTER ANY TABLE
CONTROL DATABASE
db_owner
sysadmin

エージェントごとに異なるIDを割り当てることもできます。レポート作成エージェントには、 SELECT いくつかのスキーマへのアクセス権を与えることができます。移行エージェントの作業対象を開発環境またはステージング環境だけに限定することもできます。本番環境用エージェントには範囲を厳密に限定した権限を与えたうえで、実行前に承認を必須にすることもできます。

OWASPは、AIエージェントにも同じ基本方針を推奨しています。読み取り権限と書き込み権限を分け、ツールとリソースを制限し、機密性の高い操作には明示的な承認を求めます。

ルールは簡単です。エージェントには、その役割に必要な権限を与え、起動した人の権限をそのまま与えないことです。

ワークフローに人間を組み込む

エージェント型AIを活用したデータベース作業には、次のような管理されたワークフローが適しています。

観察 → 分析 → 提案 → レビュー → 実行 → 検証 → 記録

エージェントが、応答の遅いAPIエンドポイントを調査しているとします。関連するSQLを特定し、実行計画とテーブル統計を確認して、インデックスが不足している可能性に気づき、移行スクリプトを作成します。

まず、そのスクリプトをステージング環境で実行できます。エージェントはワークロードを再実行して結果を確認し、本番環境への変更を準備します。

そこで、エージェントは停止します。

開発者またはDBAが移行内容を確認し、依存関係とビジネスへの影響を検討したうえで、本番環境に反映する前に承認します。

エージェントは、反復的な作業の多くを引き続き担えます。一方、影響の大きい変更に対する最終的な責任は人間が負います。

トランザクション制御を使えば、安全性をさらに高められます。たとえばPostgreSQLのセーブポイントを使うと、それ以前の処理をすべて破棄することなく、トランザクションの一部をロールバックできます。これは密接に結び付いた自動変更に役立つ場合がありますが、ロールバックは適切な権限設定や承認の代わりにはなりません。

dbForge AI Assistantのようなツールも、こうした用途に自然に適合します。スキーマのコンテキストを利用してSQLを生成・説明し、エラーのトラブルシューティングやDDLの比較、非効率なインデックスの検出、最適化スクリプトの準備を行えます。また、生成されたSQLは開発者が確認できる状態に保たれます。

目指すのは、定型作業を自動化しながら、重要な判断は人間が担うことです。

本当の目標は、自律性を適切に制御すること

エージェント型AIの導入は、「AIは提案だけを行う」か「AIがデータベースを操作する」かの二択ではありません。その中間には、さまざまな選択肢があります。

チームは、SQLの説明、スキーマのレビュー、読み取り専用の確認といった、リスクの低いタスクから始められます。その後、開発環境やステージング環境でエージェントが担う作業を段階的に増やせます。

書き込み権限を与えるのは、ずっと後にすべきです。また、影響を受ける行数、トランザクション、ロールバック、監視、承認について、明確な制限を設ける必要があります。本番環境での完全自律的な変更は、まれであるべきです。

これはDeloitteの指針にも通じます。リスクの低いワークフローと重要度の低いデータから始め、人間が状況を把握できる状態を保ち、エージェントの活用が進むにつれてガバナンスを強化します。

目指すのは、完全な自律性ではありません。エージェントが役立つだけの自由を与えつつ、必要以上のアクセス権は与えないことです。

要点：データベース開発には、今なお判断力が必要

AIエージェントは、データベースエンジニアリングにおける反復作業の多くを肩代わりできます。ワークロードを把握し、クエリを調べ、スキーマ、実行計画、エラー、パフォーマンスデータを関連付けて分析し、確認した内容に基づいて行動できます。

しかし、AIシステムがデータベースの状態を変更できるようになると、問題の性質は変わります。チームには、ID、権限、トランザクションの境界、承認、可観測性、ロールバック、監査証跡に関する明確なルールが必要です。

だからこそ、2025年にAIを利用していた組織の88%のうち、わずか7%が、組織全体への導入を完了したと回答しました。より難しいのは、AIを大規模に運用できるほど信頼性の高いものにすることです。

データベース開発も同じ方向に進んでいます。最も有用なエージェントは、最も多くのことを許可されたものではなく、その権限の範囲が明確に理解され、管理されているものです。

もはや問われているのは、AIがデータベースのタスクを実行できるかどうかではありません。どのタスクをAIに任せるべきか、そしてどのような制約の下で実行させるべきかです。

mm

ヴィクター・ホルレンコは、DevartのAIイノベーションの責任者であり、同社のデータベース管理および接続ツールのスイート全体でAI駆動の自動化、製品の最適化、顧客体験に関するイニシアチブを主導しています。