「探す」から「問いかける」へ。アシストが考えるOracle AI Database 26ai「Select AI」の最適な導入アプローチ

生成AIブームの今、Oracle AI Database 26aiで提供される新機能であるSelect AIを使うことで、専門的なSQLスキルがなくても自然言語でDBに問い合わせて、即座にデータ分析ができるようになりました。本記事ではSelect AIの仕組みと具体的な活用シーンを分かりやすい例とともにご紹介します。

Select AIは便利で革新的な機能である一方で、その核となる生成AI（LLM：Large Language Models、大規模言語モデル）の特性上、「データの意味や文脈を理解できず、期待した回答が得られない」という課題もあります。既存システムのデータを活かしながら、Select AIの精度を引き出すにはどうすればいいのか。Oracle Autonomous AI Databaseを「Sidecar（ローカルおよび外部のデータ・ソースのAIプロキシ・データベース）」として活用する、アシストが考える最適な導入アプローチをお伝えします。

「Select AI」を一言で言えば、「普段使っている言葉（自然言語）だけでデータべースに問い合わせができる機能」です。

これまでのDBは、人間が「SQL」という専用の言語を使って命令しなければ答えてくれませんでした。しかし、Select AIは裏側に大規模言語モデル（LLM）を連携させることで、私たちが普段使っている日本語の指示を、リアルタイムで正確なSQLに変換して実行してくれます。

問い合わせがあるとSelect AIは以下のように動きます。

ここで重要なのは「1.」の問い合わせの拡張です。

Select AIはユーザーの問い合わせをそのままLLMに送信するのではなく、メタデータを付与してLLMが理解しやすい形に変換してから送信します。

以下に、メタデータによって拡張された問い合わせのイメージを載せます。

LLMはこの「メタデータという名の文脈」を受け取って初めて、「なるほど、HR_EMP_MASTERテーブルのSTATUSが1のデータを探せばいいんだな」と理解し、正しいSQLを生成できるのです。

（※アノテーションについては後ほど詳しく解説します。これこそがAIが文脈を理解できないという課題に対する解決策の一つになります）

SQLでの問い合わせと自然言語の問い合わせ、この二つにどれくらいの差があるのか、今回も具体例を用いて比較してみましょう。ここではシステム管理者の立場で、セキュリティ監査の一環として「退職予定の社員を含む特定の条件での深夜アクセス状況」を確認する、という想定をしてみます。

今回知りたい情報は、

「退職予定者によるシステムへの深夜アクセス情報」です。

これをSQLで記述しようとすると、テーブル定義を確認しながら複雑なJOINや抽出条件を組み立てる必要があります

SQL> SELECT e.EMP_ID, e.EMP_NAME , e.DEPT_NAME ,c.LOG_ID , c.ACCESS_TIME, c.ACTION, c.LOCATION
　
FROM HR_EMP_MASTER e INNER JOIN CORE_SYSTEM_LOGS c ON e.EMP_ID = c.EMP_ID
　
WHERE e.STATUS = 1 AND EXTRACT(HOUR FROM c.ACCESS_TIME) >= 22

（人事表とアクセスログ表の二つを結合し、退職予定かつアクセス時間が22時以降という条件で行を絞っている）

Select AIを使えば、日本語で直接聞くだけです。

SQL> SELECT AI 退職予定者によるシステムへの深夜アクセス情報をリストアップして;

SQLのスキルがある人しかできなかった分析を、問いを持っているすべての人が実行できる。これがSelect AIがもたらす最大のメリットです。

Select AIの革新的な機能を理解した人はこのように思うでしょう。

「わが社には数十年分のデータが蓄積されている。これをAIに読み込ませれば、誰でもすぐに魔法のようなインサイトが得られるはずだ！」

…残念ながら、現実はそれほど甘くありません。なぜ、最新のAIをもってしても、既存のDBを使いこなすのは難しいのでしょうか？

AIは非常に賢いですが、自社の「独自のルール」までは知りません。AIがDBを理解して正しいSQLを書くためには、データそのものだけでなく、そのデータが何を意味するのかという「文脈（コンテキスト）」が不可欠です。

DBに付与する追加の文脈のことを「アノテーション」と呼びます。

今回の例では、人事表に STATUSという列があり、値に0または1が入っています。

　AIの視点： 「STATUS という列に 1 という数字がある・・？」
　必要な文脈：「この 1 は退職願提出済みを意味する」

この文脈がない限り、AIに「退職予定の人を教えて」と頼んでも、AIはどのテーブルのどの列をみればいいのか分かりません。AIにとってDBは、適切な文脈がないと「ラベルのない情報の山」に過ぎないということです。

つまり、AIを実務で使いこなすためには、アノテーション等を用いた「適切なコンテキスト設計」が必要不可欠ということです。

「それなら、DBのテーブルやカラムにアノテーションを付与すればいいじゃないか」と思われるかもしれません。しかし、エンタープライズの現場では、これが非常に高いハードルとなります。

つまり、「AIのために既存DBを書き換える」というアプローチは、リスク的にもコスト的にも現実的ではないのです。

では既存DBには触れず、最新のAI機能をどうやって手に入れるのか。その答えが、「Sidecar（サイドカー）」構成です。

バイクの横に取り付ける「サイドカー」のように、既存システムに並走する形でOracle Autonomous AI Database（以下、ADB）を外付けすることが、Select AIの最適な導入アプローチです。

Sidecar構成の最大の特徴は、「既存DBの構造やデータを変更せずに済む」という点です。

具体的には、ADBから既存DBに対して必要なデータだけを同期させることで、ADBを参照DBとして機能させます。

　既存DB（バイク本体）： これまでどおり、基幹業務を止めることなく動き続ける
　ADB（Sidecar）： Select AIを搭載し、既存DBのデータを参照して分析を行う

既存DB側から見れば、単に「新しいユーザーがデータを読み取りに来た」だけに過ぎません。システムへの負荷を最小限に抑えつつ、安全にAI化のメリットを受けられるのです。

今回挙げた具体例は、バージョンが古い既存DBからSelect AIを用いてデータ活用するというアプローチでした。しかし、私がSelect AIに感じている魅力は単なる古いDBのデータ活用に留まりません。

ADBを使えば、社内のあらゆるデータソース（Salesforce、SnowflakeなどのSaaS製品や、他社クラウド）を統合して、Select AIを使って自然言語で操ることができるという可能性があります。

現代の企業では、データはさまざまな場所に分散しています。

これらを組み合わせて分析しようとすると、従来はETLを伴う膨大なデータ移行やそれぞれの製品に対しての専門知識が必要でした。しかし、ADBには外部のデータソースと接続するための機能が備わっています。

ADBをハブとしてSnowflakeなどのSaaS製品や他クラウドと連携できれば、ユーザーは「今、どこの製品のデータを触っているか」を意識することなく、一つの窓口から問いかけるだけで済みます。

繰り返しになりますが、Select AIを使うことで、SQLではなく「自然言語」で問いかけることができます。そのおかげで、これまでは手間がかかりすぎて諦めていたような分析も、誰でも「数秒の会話」で行えるようになります。

そして、どんなに高度な問いかけをする際も、背後にたくさん散らばっているデータソースには一切の変更を加えずに済みます。

今回は、Select AIがもたらす革新的なユーザー体験とその土台となるSidecar構成のメリットについて解説しました。本記事を含めてこれから全3回にわたり、今回解説したSelect AI × Sidecarのコンセプトのもと、最適なAIデータ活用基盤の構築プロセスを徹底解説していきます。

基幹システムのデータをAI活用するのは、決して高いハードルではありません。既存の資産を大切に守りながら、その横に強力な「知能」を添える。このSidecar構成こそが、エンタープライズにおけるAI活用の最短ルートです。

次回は、いよいよADBの環境構築を行います。実際にデータを流し込み、自然言語でDBに問い合わせるところまで行っていきます。お楽しみに！