BlogでたどるSelectAI

「タイ語やアラビア語でもDatabaseに質問できるのか？」

そんな好奇心から始まったSelect AIの検証を、QiitaのBlogをたどりながら紹介する勉強会資料です。

自然言語からSQLを生成する仕組みから、AIへ業務の意味を伝える方法、SQLとRAGを組み合わせた活用まで、実際の質問・実行結果・図を交えて整理しました。

主な内容：

・日本語・タイ語・アラビア語でSelect AI
・AIは何を見てSQLを作る？ メタデータとAI Profile
・COMMENT・ANNOTATIONS・Domain・PK/FK・Gold Viewの使いどころ
・AI Ready評価の第1回〜第3回：スキーマ評価、改善、意味情報の可視化
・Resource PrincipalとOCI Vaultによる認証・APIキー管理
・音楽フェスの運営分析：SQLで実績、RAGで原因と手順を確認し、人の承認後に改善タスクを登録

SQLやDatabaseを少し触ったことがあり、Select AIをこれから試したい方や、AI Ready Dataを具体的に理解したい方に向けた内容です。

各テーマの詳しい手順は、資料内の元Blogへのリンクから確認できます。気になった検証から、ぜひ試してみてください！

Blog：https://qiita.com/shirok

Transcript

1. Blogでたどる Select AI 入門 疑問から始めた、実装と検証の記録 shirok Blogで、仕組みを理解して自分でも試してみる
2. 自己紹介 shirok 試して、書いて、伝える 疑問から始めた実装と検証を発信 shirok Qiita の ペ ージへのリ ンク 技術Blog Shiro Kobayashi qiita.com/shirok Engineer / Musician sペ X hirok の ージへのリ ンク Oracleが好き。 気になったら、試してみる。 発信・交流 @shirok_oracle shirok YouTube の ペ ージへのリ ンク 動画 YouTubeチャンネルを開く shirok Medium の ペ ージへのリ ンク 英語の技術記事 Blog はこちら Blogはこちら medium.com/@sync2you qiita.com/shirok qiita.com/shirok shirok Spotify の ペ ージへのリ ンク 音声・Podcast Podcastを開く ※発信内容は個人の見解です。 ロゴ・リンク文字から各ページへ 2
3. BlogでたどるSelect AI 本日のAgenda ゴール：用語と実例を理解して、興味のあるBlogを自分で試せるようになる パート 内容 導入 イントロ：世界につないで遊んでいた話 体験 日本語・タイ語・アラビア語でSelect AI 仕組み SQL生成の仕組み・基本用語・ER図の実例 意味情報 COMMENT・ANNOTATIONS・Domain・View／Gold／定義書 評価・改善 AI Ready 第1回・第2回・第3回 接続・認証 Resource PrincipalとAPIキーの管理 運営分析 音楽フェスのSelect AI＋RAG まとめ・質疑 次に試すBlog／質疑 3
4. 全体マップ 今日の道のり：6つの問いでBlogをたどる ひとつ試すと、次の疑問が生まれる。その順番で進みます 1 2 3 4 5 6 質問する 仕組みを知る 意味を付ける 評価・改善する 安全につなぐ Agentで使う 「日本語以外の 言葉でも、DBに 聞ける？」 「AIは、どの表 ・列を使うかを どう分かった？ 」 「コード値の意 味は、どう伝え る？」 「自分のスキー マは、どれくら い準備できてい る？」 「AIへの鍵は、 どう持たせる？ 」 「表と文書を、 どう組み合わせ る？」 Resource Principal・ Vault 音楽フェス SQL＋RAG 多言語でSelect AI MetadataからSQL生成 COMMENT・ ANNOTATIONS・ Domain・View AI Ready 第1〜3回 見方｜右上の「Blog」から、各スライドの元記事を開けます 4
5. イントロ Blog：世界一周するData Guard ／ 新年の挨拶の記事 「できるかな？」を、世界中で試してみた 多言語でInsert [謹賀新年] 世界中に配置した Oracle Active Data Guard から新年のご挨拶 [Xmas] 世界中に配置した Oracle Database を Data Guard で直列に繋ぎ世界一周してみてみた 世界中の人々で実行 INSERT INTO world (val,region) SELECT 'あけまして おめでとうございます', DB_UNIQUE_NAME from v$database; 挨拶には、ヘブライ語やタイ語など SQL> select * from WORLD; VAL REGION ---------------------------- ---------------------あけまして おめでとうございます CDB_TOKYO Happy New Year CDB_PHOENIX ‫שנה טובה‬CDB_ASHBURN Ein gutes neues Jahr CDB_FRANKFURT नया साल मुबारक हो CDB_MUMBAI 새해 복 많이 받으세요 CDB_SEOUL 新年快乐 CDB_OSAKA สวัสดีปีใหม่ ค่ะ CDB_SHIBUYA 5
6. 多言語でSelect AI Blog：OpenAI APIで自然言語のSelect AI まずは日本語で、Databaseへ質問する Select AI：自然言語の質問からSQLを作り、DBへ問い合わせる機能 SELECT AI 最も売れた商品はどれだけ売れましたかしら？; 実行結果 Product Name Total Quantity Sold ---------------------------------- ------------------Mouse Pad 29282 質問は自然な言い方でも、結果はDBに格納されたデータを集計して得る。 6
7. Blog：タイ語・アラビア語で実行 多言語でSelect AI タイ語でも、アラビア語でも聞いてみた 新年の挨拶でも使ったタイ語、そして初めて触るアラビア語で、同じ内容を質問 SELECT AI NARRATE -- タイ語 SELECT AI NARRATE -- アラビア語 สินค้าอะไรขายดีทสี่ ุด และขายได้กชี่ นิ้ ?; ‫الت تم بيعها؟‬ ‫األكث مبيعار وكم عدد المنتجات ر‬ ‫ر‬ ‫ما هو المنتج‬ ; Blogの実行結果：どちらも日本語と同じ答え RESPONSE ___________________________ สินค้า Mouse Pad ขายได้ 29,282 ชิน้ RESPONSE ___________________________ ‫ وقد بيع منه‬،‫المنتج األكثر مبي ًعا هو لوحة الفأرة‬29,282 ‫قطعة‬. 次の問い → では、AIは「どの表・列を使うか」を、どうやって分かったのだろう？ 7
8. Select AIの仕組み Blog：MetadataからSQLを生成する仕組み SQLを作るのはLLM、実行するのはDatabase 質問にメタデータを添えてSQLを生成し、Database側で実行する 通常のSQL生成にはメタデータを使用。NARRATEでは、実行結果もLLMへ送る。 8
9. Blog：Select AIとMetadataの基礎 Select AIの仕組み LLM・NL2SQL・プロンプトの意味 まずは、質問がSQLになる場面に絞って用語を整理する 用語 この勉強会での意味 LLM 文章を扱うAIモデル。質問と説明を読んでSQLを生成する NL2SQL Natural Language to SQL。自然言語をSQLに変換すること プロンプト LLMへ渡す質問・指示・必要な説明 「顧客は全部で何人ですか？」に対する生成例 SELECT COUNT(*) AS "TOTAL_CUSTOMERS" FROM "SH"."CUSTOMERS"; 9
10. Blog：AI ProfileとSchema Metadata Select AIの仕組み AI Profileは「使うAI」と「見せる情報」の設定 メタデータは、表・列の構造、意味、関係を説明する情報 AI Profileの設定例（抜粋） Profile属性 決めること provider / model どのAIを使うか credential_name 接続時に使う認証情報 object_list 候補となる表・View comments / annotations 意味の説明を添えるか object_listはSQL生成の候補。 参照できる範囲はDatabaseの権限でも管理する。 BEGIN DBMS_CLOUD_AI.CREATE_PROFILE( profile_name => 'SALES_AI', attributes => q'~{ "provider": "oci", "credential_name": "OCI_GENAI_CRED", "region": "<approved-oci-genai-region>", "model": "<supported-model-name>", "oci_compartment_id": "<compartment-ocid>", "object_list": [ {"owner": "<schema-name>", "name": "CUST_MST"}, {"owner": "<schema-name>", "name": "ORD_TXN"} ], "enforce_object_list": true, "comments": true, "annotations": true, "constraints": true, … 10
11. Select AIの仕組み Blog：生成SQLを確認 SHOWSQLで、AIが作ったSQLを確認する 表・JOIN・集計・並び順が、質問に合っているかを見る SELECT AI SHOWSQL 最も売れた商品はどれだけ売れましたかしら？; SELECT P."PROD_NAME" AS "Product Name", SUM(S."QUANTITY_SOLD") AS "Total Quantity Sold" FROM "SH"."SALES" S JOIN "SH"."PRODUCTS" P ON S."PROD_ID" = P."PROD_ID" GROUP BY P."PROD_NAME" ORDER BY SUM(S."QUANTITY_SOLD") DESC FETCH FIRST ROW ONLY AIへ渡した説明はSHOWPROMPT、生成したSQLはSHOWSQLで確認できる。 11
12. メタデータ活用の実例 Blog：ClaudeでER図（Mac）／ClineでER図（Windows） メタデータから、HRとOEをつなぐER図を作成 SQLcl MCP Server経由で、Claude／Clineが列・制約情報を確認 依頼：「HRスキーマとOEスキーマのER図を作成してください」 スキーマをまたぐ3本の外部キー 注文の営業担当 OE.ORDERS.SALES_REP_ID 参照先：HR.EMPLOYEES.EMPLOYEE_ID 顧客の担当者 OE.CUSTOMERS.ACCOUNT_MGR_ID 参照先：HR.EMPLOYEES.EMPLOYEE_ID 倉庫の所在地 OE.WAREHOUSES.LOCATION_ID 参照先：HR.LOCATIONS.LOCATION_ID Blogの実例：Cline＋SQLcl MCP Server（PlantUML） PK・FKは「つながり」、COMMENTなどは「意味」をAIへ伝える 12
13. COMMENT・ANNOTATIONS・Domain・View Blog：COMMENT・ANNOTATIONS・Domainの比較検証 データの意味を伝える、四つの手段 基本説明、名前付きの意味情報、共通定義、問い合わせ用の形を整える View JOIN・条件・集計を DB側にまとめる AIには、用途が分かる 表形式の窓口を見せる。 各機能の設定例を、 次の4枚で確認します。 13
14. データの意味を伝える Blog：COMMENTで有効顧客の意味を追加 COMMENT：コードの意味を1行で説明する 「有効顧客」の有効とは、STAT_CDがどの値であること？ COMMENT ON COLUMN cust_mst.stat_cd IS 'Customer status code. A means active and I means inactive.'; 「有効顧客は何人？」 生成された条件（要点） 結果 説明を追加する前 STAT_CD = '1' 0人 COMMENTを追加した後 STAT_CD = 'A' 3人 Profileの comments: true で説明を利用。上記はBlogで観測した各1回の結果。 14
15. データの意味を伝える Blog：列へのAnnotations設定 ANNOTATIONS：意味を名前と値で整理する 説明・別名・コード値を分けて、業務用語との対応を示す ALTER TABLE cust_mst MODIFY stat_cd ANNOTATIONS ( "DESCRIPTION" 'Customer status code.', "ALIASES" 'customer status, active customer, 顧客状態, 有効顧客', "VALUES" 'A = active (有効); I = inactive (休眠).' ); DESCRIPTION：説明 ALIASES：別名 VALUES：コードの意味 Profileの annotations: true で利用。VALUESの文章は、値を強制するCHECK制約とは別。 15
16. データの意味を伝える Blog：Domain由来のAnnotationsを利用 Domain：顧客IDの型と意味を共通化する 一度定義した意味を、顧客表と注文表の列へ関連付ける CREATE DOMAIN customer_id_d AS NUMBER(10) STRICT ANNOTATIONS ( "DESCRIPTION" 'Unique identifier for a customer.', "ALIASES" 'customer id, customer number, 顧客ID, 顧客番号' ); ALTER TABLE cust_mst MODIFY (cust_id) ADD DOMAIN customer_id_d; ALTER TABLE ord_txn MODIFY (cust_id) ADD DOMAIN customer_id_d; 列へ継承したAnnotationsを、Select AIが利用する Profileは annotations: true。共通の型・意味をそろえて管理できる。 16
17. データの意味を伝える Blog：AI問い合わせ用Viewの実装 View：JOINや業務条件をDB側にまとめる 「関東の有効顧客の、確定済み売上を顧客別に」という質問を簡単にする View定義のSELECT部分 SELECT c.cust_id, c.cust_nm, c.area_cd, SUM(o.amt) AS confirmed_sales_amt FROM cust_mst c JOIN ord_txn o ON o.cust_id = c.cust_id WHERE c.stat_cd = 'A' AND o.stat_cd = 'C' GROUP BY c.cust_id, c.cust_nm, c.area_cd; AIが指定する条件は地域に CUST_CONFIRMED_SALES_V を参照し、AREA_CD = '01' で絞り込む。 顧客 売上 Green Store 10,000円 Purple Data 7,000円 結合・有効顧客・確定済みの条件を、View側で一元管理する。 17
18. データの意味を伝える Blog：Oracle Autonomous AI Lakehouseでバラバラなデータをつなぐ GoldレイヤーのViewを、Select AIの入口にする Goldは業務向けに整えたデータの役割。Viewで定義を共通化する レイヤー 整えること Oracleでの例 Bronze 原本を保持する Object Storage・CSV・JSON・PDF Silver 型・重複・品質を整える Table・External Table・Iceberg Table Gold 業務の条件・指標・集計をそろえる Table・View・Materialized View・Analytic View AI-ready AIの用途に合わせて意味や形式を整える NL2SQL：メタデータ RAG：Chunk・Embedding など この勉強会のGold View Select AIで使うために CUST_CONFIRMED_SALES_V COMMENTで粒度・指標・コードの意味を説明 有効顧客 × 確定済み注文を、顧客別に集計 Profileに登録し、SHOWSQLと回答で確認 Blogのレイヤー整理にSelect AIの観点を補足。通常のViewはSQL定義を保存します。 18
19. データの意味を伝える Blog：AI Readyなテーブル定義書 AI Readyなテーブル定義書で、意味を管理する 物理定義とSemanticな定義を1冊にまとめ、COMMENT・Annotationsなどへ反映する 1列の定義に、物理とSemanticを並べる 物理定義 SALARY 例：HR.EMPLOYEES.SALARY NUMBER(8,2) NULL許可：Y 定義書 → Database → AIで確認 1 定義書で決める 1行の粒度・業務定義・コード値・機密区分 Constraint／ Domain CHECK：SALARY > 0 2 DDLで反映する COMMENT・Annotations・Domain・Constraint・View COMMENT／ ANNOTATIONS AI Ready COMMENT：従業員の月額給与です。 ALIASES：月額給与 UNITS：Monthly currency amount Semantic Role：MEASURE 集計Rule：SUM／AVG 機密区分：CONFIDENTIAL_COMPENSATION 3 USER_COL_COMMENTS／USER_ANNOTATIONS_USAGE 4 生成DDL COMMENT ON COLUMN … ／ ANNOTATIONS DDL → 列の値から数式で生成 サンプル：HR＋OE 15 Table／28 Sheet（1 Table＝1 Sheet） Data Dictionaryで確かめる Select AIで確かめる SHOWPROMPT → SHOWSQL → 正解Result Set GitHub｜サンプル定義書（日本語版・英語版） Excelの定義書は、そのままPromptへ入らない。反映先と確認方法まで、1冊で管理する。 19
20. Blog：AI Ready SkillでHRスキーマを評価 AI Readyなデータへ改善してみた 第1回：AI Readyを、まず測ってみた 表・列の説明や関係が整っているかを、Skillで点検する oracle-ai-ready-data Skill 1 SQLclでメタデータを収集 2 Pythonで評価 3 レポートと改善SQLを確認 この勉強会では、Select AIが意味・関係を理解しやすい状態に注目する。 20
21. AI Ready 第1回 Blog：HRスキーマの評価結果 HRは、もともとNL2SQLの土台が整っていた 評価対象は7表・35列。説明と表同士の関係が、すでに定義されていた 評価項目 カバー率 表のCOMMENT 100% 列のCOMMENT 100% 主キーのある表 100% COMMENT必須ゲート pass 0.67 scanスコア 「意味」と「関係」は ほぼ準備できていた。 統計・鮮度などには改善余地。AI Readyのスコアは、このSkillの評価基準による。 21
22. AI Ready 第2回 Blog：BAD_AI_READYの改善前評価 第2回：AI Readyでないスキーマを用意した BAD_AI_READY：説明や関係を意図的に欠落させた、8表の検証環境 0.22 不足していたもの AIに伝わらないこと 表・列COMMENT 何のデータか、コード値の意味 主キー・外部キー どの列で表を結び付けるか 鮮度・出所 いつの、どこから来たデータか 改善前のscanスコア COMMENT必須ゲート：fail 評価レポートと改善SQLの候補を読み、実際の業務定義で不足を埋める。 22
23. AI Ready 第2回 Blog：COMMENT文・ALTER文で改善 レポートの改善案を、メタデータへ反映する COMMENTで意味を説明し、ALTER文でキー・鮮度・出所などを整備した コード値や型の意味を説明する COMMENT ON COLUMN "BAD_AI_READY"."RAW_ORDERS"."ORDER_TIME_TXT" IS '注文日をYYYY-MM-DD形式の文字列で保持する。日付比較時はTO_DATEで変換する。'; 主キーで、行を識別する列を定義する ALTER TABLE "BAD_AI_READY"."RAW_CUSTOMERS" ADD CONSTRAINT "PK_RAW_CUSTOMERS" PRIMARY KEY ("CUSTOMER_ID") ENABLE VALIDATE; 鮮度・出所列、FK、統計、権限も整備。SQLの候補は、内容と影響を確認して実行した。 23
24. AI Ready 第2回 Blog：スコア改善とSelect AIのテスト 0.22から0.97へ改善し、Select AIでも確認 メタデータの整備状況と、実際の質問に答えられるかを別々に確かめる 0.22 → 0.97 Blog実測／gpt-3.5-turbo Select AIの確認 結果 想定回答との一致 9 / 10問 SQL品質の内訳 7 PASS／2 条件付き／1 FAIL 0.97はメタデータの整備指標。回答の正答率が97%という意味ではない。 24
25. AI Ready 第3回 Blog：Skill v0.4の意味情報レポート 第3回：意味情報を、レポートにも出力する 23aiからのANNOTATIONS・Domainに対応し、Skillをv0.4へ拡張した 既存の採点方法は維持し、「どこに、どんな意味情報があるか」を追加で見えるようにした。 25
26. AI Ready 第3回 Blog：直接付与・Domain継承とOn/Off比較 登録した意味が、SQLに使われたかも確認する Q7＝有効、X9＝取消。レポートの登録情報と、Select AIの利用結果をつなげる レポートの列 意味情報の由来 Domain AIRD_T02.C03 直接付与 なし AIRD_T03.C03 Domainから継承 AIRD_D01 SELECT SUM("t"."C02") AS "total_c02" FROM "BAD_AI_READY"."AIRD_T02" "t" WHERE "t"."C03" = 'Q7'; 2,000 annotations: true 2表のラボでは、直接付与・Domain継承ともOff＝0/3、On＝3/3で期待結果と一致。 COMMENT整備済みの8表ではOff／Onとも6/6。意味の説明がすでに足りている場合もある。 26
27. 接続とAPIキーの管理 Blog：Resource PrincipalでSelect AI Resource Principalは、ADB自身のID ADB自身に与えた権限で、OCI Generative AIを呼び出す Dynamic Group：対象のADB IAM Policy：許可する操作 27
28. Blog：IAMとResource Principalの設定 Resource Principalの実装例 OCIの権限設定と、Profileの認証設定 対象ADBをDynamic Groupへ登録し、生成AIの利用を許可する ADMINで利用ユーザーに有効化 BEGIN DBMS_CLOUD_ADMIN.ENABLE_PRINCIPAL_AUTH ( provider => 'OCI', username => 'ADB_USER' ); END; / Profile属性の抜粋 "provider": "oci", "credential_name": "OCI$RESOURCE_PRINCIPAL", "region": "ap-osaka-1" object_list・modelなども Blogの手順に沿って設定する。 IAM Policyの例：Dynamic Groupに generative-ai-chat の利用権限を付与する。 28
29. Blog：OpenAI APIキーをOCI Vaultで管理 APIキーを安全に管理する 外部AIのAPIキーは、OCI Vaultで管理する Vaultへの認証と、OpenAIへの認証は役割が異なる Credentialの設定抜粋 params => JSON_OBJECT( 'username' VALUE 'OPENAI', 'secret_id' VALUE '<SecretのOCID>' ) ADBからVault：Resource Principal ADBからOpenAI：APIキー キーをSQLへ直接書かず、Secretを参照するCredentialをProfileに設定する。 29
30. マルチクラウドのシークレット管理 Blog：Vault管理の考え方と発展 APIキーの保管先は、各クラウドへ広げられる 利用するAIサービスと、キーを管理する場所を分けて考える クラウド シークレット管理サービス アクセスに使う仕組み OCI OCI Vault OCI Resource Principal AWS AWS Secrets Manager AWS IAM Role（ARNで指定） Azure Azure Key Vault Azure Service Principal Google Cloud Secret Manager Google Service Account 今回のBlogで検証：OCI Vault AWS・Azure・Google CloudはOracle公式で対応を確認した発展例。各クラウド側の設定が必要。 30
31. 具体的な利用例 Blog：音楽フェス運営分析AI Agent 音楽フェスの運営を、SQLとRAGで調べる Lakehouse Sound Festival 2026：Blogの架空デモ 1つのAI Agentで行う フェス運営分析システムを作成 ① 何が起きた？ ↓ SQL 数値・実績を確認 ② なぜ起きた？ ↓ RAG 根本原因・正式手順を確認 ③ どう改善する？ ↓ Human Approval + Action 改善タスクを登録（人の承認後） 31
32. 具体的な利用例 Blog：音楽フェス運営分析AI Agent AI Readyな表と文書で、フェス運営を分析する 表は意味・関係を定義。文書はID・版を付けて、Chunk・Embedding化する 運営のテーマ テーブルデータ（SQL） RAG文書 調べられること 公演・機器の障害 公演実績、温度・ロス率 ファン回転数、保守履歴 遅延報告、音響運用手順 冷却ファンの通知 遅延の影響、故障の原因 切替手順・再発防止 入場ゲートの混雑 QR読取結果、待ち時間 現場対応の時刻 ゲート障害報告 入場ゲート対応手順 失敗率・待ち時間 切替までにかかった時間 物販の在庫切れ 売上、在庫、需要予測 来場者Feedback 在庫計画会議の議事録 完売時刻・予測との差 予測を採用しなかった経緯 悪天候・払戻 気象、入場、公演状態 チケット・払戻申請 悪天候対応計画 チケット払戻ポリシー 中止基準・払戻対象 承認件数・金額 今日たどる例 今日は1行目「公演・機器の障害」を、次のP33〜36でたどる 残りの3テーマも、同じデータセットに表と文書を用意している（Blog参照） 32
33. Blog：テーブル・ViewとRAG文書 Select AI＋RAG｜今日たどる事件 今日たどる事件：Waveform Arenaの公演遅延 INC-2026-081｜2026年8月8日｜架空デモ。手がかりは、表と文書の両方にある 表・View（数値・実績） SQL Tool Select AI（NL2SQL） 運営者の質問 「なぜ遅れた？」 「どう対応する？」 V_STAGE_DELAY_ANALYSIS 公演の遅延 V_EQUIPMENT_HEALTH_SUMMARY 機器の状態 EXT_EQUIPMENT_MAINTENANCE 保守の予定 Main Agent 質問に合う Toolを選び、 回答を1つにまとめる RAG Tool Select AI（RAG） Vector Indexで検索 この事件を、3つの聞き方でたどる → ① SQLだけ ② RAGだけ PDF文書（原因・手順） IR-2026-081 障害報告書（原因） OPS-NET-2.1 運用手順書 v2.1（閾値・切替手順） ③ SQL＋RAG （P34〜36） 33
34. Select AI＋RAG 実際のチャット① Blog：SQL Toolへの質問と回答 SQLで調べる：どの公演が、何分遅れた？ まずは表の数値から。SQL Toolが、遅延の実績を集計する ① SQLだけ｜何が起きた？ ② RAGだけ｜正式な手順は？ 質問（AI Agentへ） Waveform Arenaの公演から、公演ID、アーティスト名、遅延 時間を取得してください。遅延時間の降順に並べ、上位3件だ けを表示してください。 SQL Toolが生成したSQL（表示用の列別名は省略） SELECT "PERFORMANCE_ID", "ARTIST_NAME", "DELAY_MINUTES" FROM "ADB_USER"."V_STAGE_DELAY_ANALYSIS" WHERE UPPER("STAGE_NAME") = UPPER('Waveform Arena') ORDER BY "DELAY_MINUTES" DESC FETCH FIRST 3 ROWS ONLY; ③ SQL＋RAG｜なぜ？どうする？ 回答（実行結果） 公演ID アーティスト 遅延 PERF-0033 Circuit Bloom 29分 PERF-0034 Fader Ghost 24分 PERF-0035 Spectrum Taxi 16分 表でわかること どの公演が、何分遅れたか （最大29分） 表だけではわからないこと なぜ遅れたか。正式な対応は何か 次の問い → なぜ遅れた？どう対応する？ その答えは、表ではなく文書にある 34
35. Select AI＋RAG 実際のチャット② Blog：RAG Toolへの質問と回答 RAGで調べる：正式な対応手順は？ 表にない「手順」は文書にある。RAG Toolが運用手順書を検索して答える ① SQLだけ｜何が起きた？ ② RAGだけ｜正式な手順は？ 質問（AI Agentへ） DJリンクネットワークでパケットロスが5%を超えた場合の、 正式な対応手順を教えてください。 ③ SQL＋RAG｜なぜ？どうする？ 回答（Blogのチャットを要約） 1 2 監視と確認 監視画面で、パケットロス・温度・ファン回転数を確認 リンク状態の確認 DJプレイヤーを再起動する前に、スイッチとリンク状態を確認 RAG Toolが参照した文書 予備スイッチへ切替 音響ネットワーク運用手順書 v2.1 3 OPS-NET-2.1｜LSF2026_stage_audio_network_operations_v2.1.pdf パケットロスの監視閾値 Warning：2%超が3分 ／ Critical：5%超が2分 Critical時の対応：主系を隔離し、予備系へ切替 4 5 → LLMの一般知識ではなく、この手順書の条件で答える Critical条件（5%超が2分継続）なら、5分以内に予備スイッチへDJリンクVLANを 切り替える 同期と再生の確認 2台以上のDJプレイヤーで、同期・波形更新・音声再生を確認 対象機器の隔離 復旧後も再利用せず、隔離してベンダー解析へ 次の問い → 表の数値（症状）と文書（原因・手順）を合わせると、何が言える？ 35
36. Select AI＋RAG 実際のチャット③ Blog：SQLとRAGを組み合わせた回答 SQL＋RAGで、数値と文書を照らし合わせる Main Agentが両方のToolを使い、症状（数値）と原因・手順（文書）を1つの回答にまとめる ① SQLだけ｜何が起きた？ ② RAGだけ｜正式な手順は？ 質問 「INC-2026-081の遅延原因と対応を、実績・機器・保守履歴・文書から分析して」 SQL｜表の数値（症状） 照合 ③ SQL＋RAG｜なぜ？どうする？ Blogの依頼を短縮・回答を要約 RAG｜文書の記載（原因・手順） 温度 最大91.8℃・ファン 最低120 RPM 直接原因：製造ロットNW-2603の冷却ファン回転数低下 V_EQUIPMENT_HEALTH_SUMMARY IR-2026-081 障害報告書 保守予定日から14日超過 寄与要因：7/25予定のファン交換が未完了 EXT_EQUIPMENT_MAINTENANCE IR-2026-081 障害報告書 パケットロス 最大19.2% 復旧手順：Critical（5%超が2分）で予備スイッチへ切替 V_EQUIPMENT_HEALTH_SUMMARY OPS-NET-2.1 運用手順書 v2.1 ポイント → 数値だけでは原因を断定しない。報告書で確かめ、改善タスクは人の承認後に登録（Blog） 36
37. まとめ 次は、どのBlogを試してみてみましょう 記事名をクリックすると、実装手順・コマンド・図を確認できます ① まず自然言語で質問する 日本語・タイ語・アラビア語でSelect AI ② 生成の仕組みを理解する MetadataからSQLを生成する仕組み ③ 意味を設定する COMMENT・ANNOTATIONS・Domain・View ④ データを評価・改善する AI Ready 第1回 第2回 ⑤ 認証・キー管理を整える Resource Principal OCI Vault ⑥ SQLと文書を組み合わせる 音楽フェスのSelect AI＋RAG 第3回 各記事の実行条件を確認し、まずはSHOWSQLで生成されたSQLを見てみる。 37
38. Appendix 今回使用したBlog一覧 記事名をクリックして、実装手順・コマンド・図を確認できます きっかけ・多言語 AI Ready 第1回〜第3回 世界各国の言葉で新年のご挨拶 第1回：HRスキーマを評価 Data Guardで世界へ「愛・平和」を届ける 第2回：スコアを0.22から0.97へ改善 日本語・タイ語・アラビア語でSelect AI 第3回：意味情報をレポートへ追加 仕組み・意味・関係 認証・活用 メタデータからSQLを生成する仕組み Resource PrincipalでSelect AI COMMENT・ANNOTATIONS・Domain・View OpenAI APIキーをOCI Vaultで管理 LakehouseとGoldレイヤーのView 音楽フェスのSelect AI＋RAG Claude＋SQLcl MCPでHR・OEのER図 Cline＋SQLcl MCPでHR・OEのER図 全14記事／記事名は短縮表記 著者：shirok 38