BlogでたどるSelect AI入門：多言語からAI Ready Data、SQL＋RAGまで整理してみてみた

Last updated at 2026-10-14Posted at 2026-10-13

Select AIを使うと、日本語などの自然言語からSQLを生成し、Oracle Databaseのデータを調べることができます。

ただ、実際に使ってみると、いろいろ気になってきます。

「日本語以外でも問い合わせできるのか？」
「AIは、どのテーブルを使うか、どの列でJOINするかをどうやって知るのでしょ？」
「業務で使っているコード値の意味は、どこに書けばよいのかしら？」
「表の数値と、手順書や障害報告書を一緒に調べられる？」

Select AIのBlogは、こうした疑問から少しずつ増えてきました。一方で、検証内容を詳しく書くほど記事も長くなり、「専門的で、どこから読めばよいか分かりにくい」という声もいただきました。

そこで先日、これまでのBlogをたどりながら、Select AIの基礎から具体的な活用例までを紹介する勉強会を開催しました。

今回の記事は、その勉強会でお話しした内容を、初めて読む方にもつながりが分かるようにまとめたものです。各テーマでは「何が気になったのか」「何を試したのか」「何が分かったのか」を整理し、詳しい手順がある元Blogへリンクしています。

ということで、これまでの疑問から生まれたSelect AIの検証を、勉強会の流れに沿って整理してみてみます。

勉強会で使った資料もSpeaker Deckで公開しています。スライドと見比べながら読んでいただいても、気になったところから元Blogへ進んでいただいても大丈夫です。

■ Agenda

勉強会では、次の6つの疑問を順番にたどりました。

順番	疑問	紹介する内容
1	自分が読めない言語でも問い合わせできる？	日本語・タイ語・アラビア語でSelect AI
2	AIは、何を見てSQLを作っている？	NL2SQL、メタデータ、AI Profile、生成SQLの確認
3	業務の意味やテーブルの関係を、どう伝える？	PK・FK、COMMENT、ANNOTATIONS、Domain、View
4	データがAI向けに整っているか、どう確かめる？	AI Ready評価の第1回・第2回・第3回
5	接続に必要な鍵を、どう管理する？	Resource PrincipalとOCI Vault
6	これらを組み合わせると、何ができる？	音楽フェスのSQL＋RAG分析と承認付きAction

SQLやテーブルを少し触ったことがあれば、最初から順番に読める構成です。実際に環境を構築するときは、各節の元Blogで前提条件と手順を確認してください。

■ 1. きっかけは「タイ語やアラビア語でもできるのか？」

● 世界中のDatabaseをつなぐ

以前、Oracle Databaseを世界中に配置し、Networkでつなぐ仕事をしていました。その中で、世界各国に配置したOracle DatabaseをData Guardでつなぎ、それぞれの地域の言葉で挨拶する検証をしました。
クリスマスにはDatabaseを直列につないで世界を一周し、お正月には各地のActive Data Guardから新年の挨拶を送っています。

Active Data Guardでは、Primary Databaseで業務処理を行いながら、Standby Databaseで分析やレポート処理を実行できます。私もStandby側をDWHのような用途で活用していました。

その経験から、AIをDatabaseで使えるようになったときに、「Standby DatabaseでもAI処理を利用できるようになったら、世界各国の言語での入力や、回答の表示はどうなるのか？」に興味が湧きました。各国の言葉が格納されたデータに対して、その言語のままで質問したら、AIは正しく回答してくれるのかを試してみてみたくなりました。

今回のSelect AIの検証はAutonomous Databaseで行っていますが、こうしたStandby Databaseの活用経験が、多言語で試してみようと思ったきっかけになっています。

Select AIを初めて試したときも、日本語で動くことに加えて、自分では読めないタイ語やアラビア語、ヘブライ語でどうなるかが楽しみでした。

● 同じ売上データへ、違う言語で質問してみる

元Blogでは、SHサンプルスキーマの商品・売上データに対して、「最も売れた商品と、その販売数」を質問しています。

タイ語での実行例です。接続とAI Profileの設定を済ませた環境で実行しています。掲載する質問文は、元Blogの文字間の空白を整えています。

SQL> SELECT AI NARRATE สินค้าอะไรขายดีที่สุด และขายได้กี่ชิ้น;

    RESPONSE
    ______________________________________
    สินค้า Mouse Pad ขายได้ 29,282 ชิ้น

この検証では、商品名Mouse Pad、販売数29282が返りました。

今回はNARRATEを指定し、SQLの実行結果をタイ語の文章で回答してもらいました。同じ質問をアラビア語でも試しています。

SQL> SELECT AI NARRATE ما هو المنتج الأكثر مبيعاً وكم عدد المنتجات التي تم بيعها؟;

    RESPONSE
    ________________________________________________________________
    المنتج الأكثر مبيعًا هو لوحة الفأرة، وقد بيع منه 29,282 قطعة.

元Blogでは、タイ語とアラビア語のどちらでも、Mouse Padが29,282個売れたという内容の回答を確認できました。

勉強会の当日も、その場で別の言語ビコール語等に変えて試してみました。返ってきた文章を日本語へ翻訳して、「ちゃんと同じ商品のことを答えている」と確認するのは、やはり面白いところです。

ここで見ているのは、異なる言語の質問から、同じDatabaseのデータへたどり着けるかです。言語の対応や回答品質は利用するモデルにも依存するので、実際に使う言語・業務用語で確認することが大切です。

・実践Blog：OpenAI APIを使用して自然言語でSelect AIしてみてみた

■ 2. AIは、何を見てSQLを作っているのか

● SQLを作るのはLLM、実行するのはDatabase

自然言語からSQLへ変換することを、NL2SQL（Natural Language to SQL） と呼びます。

LLM（Large Language Model：大規模言語モデル） は、文章を理解・生成するAIモデルです。Select AIでは、質問とメタデータを基にSQLを生成する役割を担います。

Select AIの通常のNL2SQLでは、Oracle Databaseが質問にスキーマのメタデータを追加したプロンプトを作り、LLMへSQLの生成を依頼します。LLMが返したSQLを実行するのは、Oracle Databaseです。

ここでいうメタデータは、データを説明する情報です。表名、列名、データ型、主キー・外部キー、コメントなどが該当します。

図の出典：Select AIがMetadataからSQLを生成する仕組みを整理したBlog

例えば、STAT_CDという列名とCHAR(1)という型があれば、「1文字のコードを持つ列」だとは分かります。しかし、そのコードのAが「有効」を意味することまでは、列名と型だけでは分かりません。

人には分かっていても、AIにはまだ伝わっていない。そこで、この「Aは有効」といった業務の意味も、AIへ渡せるようにしていきます。

● AI Profileは、接続先と使う情報の設定

AI Profileは、Select AIがどのAIサービス・モデル・認証情報を使い、どのオブジェクトのメタデータを参照するかなどを定義する設定です。

設定項目	主に決めること
`provider` / `model`	利用するAIサービスとモデル
`credential_name`	AIサービスへ接続するための認証情報
`object_list`	SQL生成に使うメタデータの対象となる表・Viewなど
`comments` / `annotations` / `constraints`	コメント・Annotation・制約をプロンプトへ含めるか

ここは少し気を付けたいところです。Databaseに説明を書いても、Profileの設定によってはLLMへ渡りません。「書いたから大丈夫」と思わず、実際のプロンプトにも入っているか確認します。

また、object_listで対象を指定することと、Databaseのアクセス権限を設定することは別です。対象の制限にはenforce_object_listなどの設定も確認し、Databaseユーザーには必要な権限を付与します。

● SHOWPROMPT・SHOWSQL・RUNSQL・NARRATEを使い分ける

勉強会では、結果を見るだけでなく、「AIへ何を伝え、どのSQLを作ったか」を確認する流れも紹介しました。

Action	確認できること
`SHOWPROMPT`	SQL生成のために組み立てたプロンプト
`SHOWSQL`	LLMが生成したSQL
`EXPLAINSQL`	生成SQLの処理内容を自然言語で説明する
`RUNSQL`	生成SQLをDatabaseで実行した結果
`NARRATE`	SQL実行結果を使ってLLMが作成する自然言語の説明
`CHAT`	質問をLLMへ渡し、文章で回答を得る

CHATは、Databaseの表をSQLで検索するActionではありません。実際の表の件数や売上を調べる場合はRUNSQLやNARRATEを使います。以下の図は、通常のNL2SQLの流れを示しています。

SELECT AI SHOWPROMPT 有効顧客は何人ですか？;

SELECT AI SHOWSQL 有効顧客は何人ですか？;

通常のNL2SQLのSQL生成用プロンプトには、表・Viewの行データを自動的に追加するのではなく、スキーマのメタデータを使います。一方、NARRATEではSQLの実行結果をLLMへ渡して文章を作ります。RAGでも、検索で得た文書内容を回答の材料としてLLMへ渡します。

どのActionを使うかによって、LLMへ渡る情報が変わるという点を押さえておくと、動作とデータの流れを理解しやすくなります。

なお、SHOWSQLの後にRUNSQLを呼ぶことは、確認済みのSQLをそのまま承認・実行する仕組みではありません。同じSQLの結果を厳密に確かめたいときは、表示されたSQL自体を確認し、通常のSQLとして実行します。

・実践Blog ：NL2SQL: Select AIがMetadataからSQLを生成する仕組みとAI Ready Dataを整理してみてみた

■ 3. 業務の意味とテーブルの関係を伝える

● COMMENTで「Aは有効」を伝える

「有効顧客は何人ですか？」と質問しても、AIが「有効」に対応するコード値を知らなければ、誤った条件を作る可能性があります。

仕組みを確認したBlogでは、顧客表の状態コードへ次のCOMMENTを追加しました。

COMMENT ON COLUMN cust_mst.stat_cd
IS 'Customer status code. A means active and I means inactive.';

AI Profileのcommentsも有効にして、意味がプロンプトへ含まれることを確認しています。

この検証での条件	生成された絞り込み条件	SQL実行結果
コードの意味を渡さない	`STAT_CD = '1'`	0件
COMMENTで`A`と`I`の意味を渡す	`STAT_CD = 'A'`	3件

COMMENTを追加すればすべての質問に必ず正答するという意味ではありませんが、「Aは有効」と伝えることで、SQLの条件も変わる。何をAIへ伝えるかが結果につながる、分かりやすい例になりました。

● COMMENT・ANNOTATIONS・Domainは、どう使い分ける？

意味を記載する方法はCOMMENTだけではありません。勉強会では、ANNOTATIONSとDomainも比較しました。

仕組み	何を持たせるか	使いどころの例
COMMENT	表・列の説明を文章で記載する	「この列のAは有効顧客」を手軽に説明する
ANNOTATIONS	キーと値などでメタデータを付ける	説明、別名、値の意味などを項目に分けて管理する
Domain	共通のデータ型・制約・意味などを再利用する	複数の表に登場する顧客IDや状態コードの定義をそろえる
View	JOIN・絞り込み・集計などをSQLで定義する	「有効顧客の確定済み売上」のような業務上の対象を作る

COMMENTは、人が読む説明としてだけでなく、Select AIへ意味を伝えるためにも使えます。ANNOTATIONSもAI専用の機能というわけではなく、利用するアプリケーションなどが解釈できる形でメタデータを持たせる仕組みです。

Domainは、同じ説明を各列へ個別に書き続ける場面で便利です。共通の定義を作り、対応する列へ関連付けることで、意味をまとめて管理できます。ANNOTATIONSとDomainは23aiから導入された機能なので、利用するDatabaseのバージョンも確認します。

どれが一番賢いかを競うというよりも、その業務の意味を、どこへ置けば管理・再利用しやすいかを考えると使い分けやすくなります。

・実践Blog ：NL2SQL: COMMENT・ANNOTATIONS・Domainの違いを整理してSelect AIで動作検証してみてみた

● PK・FKは、AIへ関係を伝える情報にもなる

PK（主キー） は行を識別するためのキー、FK（外部キー） は参照先のキーとの関係を表す制約です。

Oracle Databaseを使っているとおなじみの情報ですが、AIがテーブル間の関係を理解する手がかりにもなります。

この点が分かりやすかったのが、SQLcl MCPサーバーを通じて、ClaudeへHR・OEスキーマのER図作成を依頼した検証です。

MCP（Model Context Protocol） は、AIアプリケーションから外部ツールやデータへアクセスするための共通の仕組みです。ここでは、SQLcl MCPサーバーを通してClaudeがDatabaseのメタデータを取得します。

Databaseへ接続して、HRスキーマとOEスキーマのER図を作成してください。

HRは人事系、OEは受注系のサンプルスキーマです。元Blogでは、スキーマをまたぐ外部キーの関係(Cross-Schema Join)も、生成したER図に表現されていることを確認しました。

ここでは少しSelect AIから寄り道して、Claude＋SQLcl MCPでメタデータを読み、ER図を作成した実験 を説明しました。使っている仕組みは違いますが、「Databaseに書いておいた関係が、AIにも伝わる」という話につながります。

PK・FKがなくてもAIが関係を推測することはあります。ただ、業務上の正しい関係を明示しておけば、推測に頼る部分を減らせます。

● GoldレイヤーのViewで、問い合わせる対象を整える

業務で使うデータは、1つの表だけで完結するとは限りません。顧客、受注、明細、商品などをJOINし、「有効」「確定済み」といった条件を付けて、ようやく業務で使う数字になることがあります。

こうした定義をViewへまとめると、AIが問い合わせる対象も整理できます。

レイヤー	データの状態	Oracleでの実装例
Bronze	取り込んだままのデータ	Object Storage上のCSV・Parquet・JSONなど
Silver	型や重複、関連付けなどを整えたデータ	Table、External Tableなど
Gold	業務の質問や分析に使える形へ整理したデータ	Table、View、Materialized View、Analytic View

例えば、「公演予定」「公演実績」「ステージ名」をJOINしたViewを用意すると、利用者は「そのステージで何分遅れたか」を1つの対象に問い合わせられます。後半の音楽フェスでも、この考え方を使っています。

Viewという種類のオブジェクトなら何でもGoldになるわけではありません。業務で使える粒度とルールに整理されていることがポイントです。さらに、列の意味、権限、鮮度などを整えて、AIからも使いやすくします。

通常のViewはSQLの定義を保持するため、Viewを作るだけで集計結果が保存されたり、処理が必ず速くなったりするわけではありません。結果の保存や更新方法も含めて考える場合は、Materialized Viewなども検討します。

ここまでのCOMMENT・ANNOTATIONS・Domain・PK/FK・Viewで、業務用語と実際のデータの対応をDatabase側へ持たせます。このような意味の層を、今回の勉強会ではセマンティックレイヤーとして説明しました。

■ 4. AI Ready評価では、第1回・第2回・第3回で何をしたのか

意味や関係を整える必要があることは分かりました。次に気になったのは、「自分のスキーマは、どこまで整っているのか？」です。

そこで作成したのが、oracle-ai-ready-data Skillです。

SQLclでメタデータを収集し、Pythonで評価レポートや改善SQLを生成します。メタデータの収集・採点そのものにはLLMを呼び出しません。

ここでいうAI Readyは、データが存在するだけでなく、その意味・関係・鮮度などが分かり、AIから利用しやすい状態を目指す考え方です。このSkillのスコアは、その整備状況を確認するために使っています。

● 第1回：HRは、もともと意味と関係がよく整っていた

最初に、OracleのHRサンプルスキーマを評価しました。

HRでは、表・列のコメントと主キーの整備率が100%で、意味や関係を評価するContextualのスコアも1.00でした。NL2SQLで利用する説明や関係は、もともとよく整っていたと分かります。

一方、統計情報や鮮度の指標には不足があり、スキーマ全体を点検するscanの総合スコアは0.67でした。「意味と関係が整っていること」と「総合評価の全項目が整っていること」を分けて見ると、HRの良い点と改善余地が分かります。

勉強会で伝えたかったのは、昔から丁寧に設計されたスキーマには、AIが利用できる情報もすでにあるという点です。今回のHRを、そのまますべてのAI用途・本番運用に十分と評価したわけではありません。

・実践Blog ：第1回：HRスキーマをAI Ready評価してみてみた

● 第2回：不足を作り、改善SQLで整えてみた

次は、意図的にメタデータが不足するBAD_AI_READYスキーマを用意しました。

コメントや主キー・外部キー、鮮度・出所を確認する情報などが不足した状態を評価し、レポートの指摘と改善SQLを使って整備しています。COMMENTや制約の追加だけでなく、必要な列の追加や統計情報の整備も含めた検証です。

確認内容	改善前	改善後
SkillのAI Readyスコア	0.22	0.97
意味・関係などの情報	意図的に不足させた状態	コメント、PK/FK、鮮度・出所などを整備

ここでの0.97は、SQLの正解率97%という意味ではありません。整備後のデータを使い、代表的な業務質問で生成SQLと結果を検証しました。

元Blogのベースラインでは、10問に対してPASSが7問、条件付きPASSが2問、FAILが1問でした。失敗した設問にはモデルを変更した追加確認も行っており、データ側の整備とモデル側の能力の両方を見る必要があると分かります。

また、改善SQLは、業務の正しい意味まで自動で決定するものではありません。「このコードは何を意味するのか」「どの列が正しいJOINキーか」は、業務を知る人と確認して反映します。

・実践Blog ：第2回：AI Readyスコアを0.22から0.97へ改善し、Select AIで確認してみてみた

● 第3回：ANNOTATIONSとDomainの意味情報も見えるようにした

第3回では、Skillをv0.4.0へ拡張しました。

列へ直接付けたAnnotationだけでなく、Domainから継承したAnnotationも収集し、内容、登録先、継承元、対象列の割合をレポートで確認できるようにしています。

例えば、状態コードがQ7とX9だった場合、列名だけで「どちらが有効か」を推測するのは難しいです。そこで「Q7は有効、X9は取消」という意味を登録し、Select AIが利用できるかを確認しました。

最小ラボでは、直接Annotation・Domain継承のどちらも、annotationsをOffにした条件では期待結果との一致が0/3、Onでは3/3となり、有効な注文の合計金額が期待値の2000になることを確認できました。

一方、COMMENTですでに意味を整備した別の比較では、Off・Onともに6/6で一致しました。Annotationを追加すれば必ず改善するというより、必要な意味が、どの情報からAIへ届いているかを確認することが大切です。

なお、第3回で追加した意味情報のレポートは、既存のAI Readyスコアへ加点する機能ではありません。スコアでは見えにくい意味情報を、詳しく確認するための拡張です。

・実践Blog ：第3回：ANNOTATIONSとDomainの意味情報を可視化し、Select AIで確認してみてみた

■ 5. 接続の鍵は、どこで管理するのか

Select AIを動かせるようになると、次は接続に使う認証情報の管理が気になります。

ここでは、OCI Generative AIへ接続する場合と、OpenAI APIキーを管理する場合を紹介しました。

● OCI Generative AIへはResource Principalで接続

Resource Principalは、Autonomous AI Databaseなどのリソース自身を、OCI上の認証主体として扱う仕組みです。

対象のDatabaseをDynamic Groupへ含め、IAM PolicyでOCI Generative AIへのアクセスを許可します。Database側でResource Principalを有効にし、AI Profileのcredential_nameにはOCI$RESOURCE_PRINCIPALを指定します。

この構成では、利用者がOCIユーザーのAPI署名秘密鍵をDatabaseへ登録・管理する方式を使わずに接続できます。

鍵の管理が全部なくなるというより、「自分でOCIユーザーの秘密鍵を持たせる」部分を、DatabaseのIDとIAMの仕組みに任せるイメージです。

・実践Blog ：Autonomous AI DatabaseのResource Principalで、API署名鍵を使わずにSelect AIしてみてみた

● OpenAI などの持ち込みAPIキーは OCI Vaultで管理

OpenAI APIを使う検証では、OpenAIが発行するAPIキーをOCI VaultのSecretとして管理しました。

Autonomous AI DatabaseはResource PrincipalでOCI Vaultへアクセスし、Vault Secret Credentialを通してキーを利用します。AI Profileには、そのCredentialを指定します。

今回の接続先	Resource Principalの役割	管理するもの
OCI Generative AI	Database自身としてOCI Generative AIへアクセス	Dynamic Group、IAM Policyなど
OpenAI API	OCI VaultからSecretを利用するためのアクセス	OCI Vault内のOpenAI APIキーとCredential

どちらもResource Principalが出てくるので、少しややこしいところです。OpenAIなどの持ち込み AIの場合、Resource Principalでアクセスする先はOCI Vaultです。OpenAIへの接続には、Vaultで管理しているAPIキーを引き続き使います。

元Blogでは、キーのローテーション後にSelect AIが動作するところまで確認しています。ほかのクラウドにもSecret管理サービスがありますが、この勉強会で紹介した実機検証はOCI Vaultを使った構成です。

・実践Blog ：OpenAI APIキーをOCI VaultとResource PrincipalでセキュアにしてSelect AIしてみてみた

● 参考情報：Azure OpenAIにもAPIキーを登録せずに接続できる

Oracle公式ドキュメントでは、Azure OpenAIにもService Principalを使用し、APIキーを登録せずにSelect AIから接続する例があります。AI Profileではprovider: azure、credential_name: AZURE$PAを指定し、Azure側でアクセス権限を設定します。

こちらは本記事での実機検証結果ではなく、公式ドキュメントの対応情報として紹介しています。

・ Oracle公式：Examples of Using Select AIの「Example: Select AI with Azure OpenAI Service Principal」を参照してください。

■ 6. 音楽フェスの運営を、SQLとRAGで調べる

ここまでで、質問の意味を伝え、データを整え、接続するための要素を見てきました。最後は、それらを使って何を調べられるのかを、具体的な例で紹介します。

題材は、架空の音楽フェス「Lakehouse Sound Festival 2026」です。Autonomous AI LakehouseとPrivate Agent Factory（PAF）を組み合わせ、1つのAI Agentから運営状況を分析するデモを作成しました。

PAFは、SQLや文書検索などのToolを組み合わせて、業務用のAI Agentを構成する仕組みです。ここでのToolは、Agentから呼び出す処理のことです。

図の出典：音楽フェス運営分析AI Agentを作成したBlog。以下では、ステージ遅延の1件に絞って説明します。

● 実際には、どのような質問をしたのか

元Blogの複合分析では、対象を明示したうえで、確認する項目を列挙しました。以下は、実際の質問を読みやすく短縮したものです。

2026年8月8日、Waveform Arenaで発生した
INC-2026-081の公演遅延を分析してください。
対象機器はEQ-NET-WA-01です。

SQLで、影響公演数、最大遅延と対象公演、最大温度、
最大パケットロス、最低ファン回転数、保守期限超過日数を確認してください。

RAGで、根本原因、寄与要因、正式な復旧手順、
再発防止策と、その根拠文書を確認してください。

「何かおかしい？」だけでなく、対象と確認項目を具体的にすると、回答で何が確認できたかを確かめやすくなります。

回答では、3公演に影響し、最大で29分遅延していた ことが分かりました。さらに、障害報告書から冷却ファンの回転数低下や交換未完了の情報を、運用手順書から予備系への切替手順を確認しています。

「何分遅れた？」から、「原因は何だった？」「どう対応する？」まで、表の数値と文書の説明をつなげて調べる例です。ここから、その回答に使ったデータを見ていきます。

● SQLとRAGは、確認する材料が違う

RAG（Retrieval-Augmented Generation） は、関連する文書などを検索し、その内容を材料に回答を作る仕組みです。

今回のフェスでは、SQLとRAGを次のように組み合わせます。

知りたいこと	使用する機能	確認する材料
何が起きた？	SQL	公演の遅延時間、センサー値、保守履歴などの数値・実績
なぜ起きた？どう対応する？	RAG	障害報告書に記載された原因、運用手順書の正式な対応
どう改善する？	Human Approval＋Action	改善タスク案を確認し、人の承認後に登録

表データは、Object Storage上のParquetやCSVを外部表から参照し、分析用のViewなどを通して利用します。RAGではPDFの障害報告書や運用手順書を検索します。

外部表は、Database外にあるファイルを表として参照するための仕組みです。ファイルのデータでも、表として扱えるようにすることでSQL分析につなげられます。

● 今回使った表・Viewと業務文書

分析対象は、2026年8月8日にWaveform Arenaで発生した公演遅延です。

障害ID：INC-2026-081
対象機器：EQ-NET-WA-01（DJ用ネットワークの主系スイッチ）

参照元	入っている内容	この障害で確認すること
`V_STAGE_DELAY_ANALYSIS`	公演予定と実績、アーティスト、遅延時間、障害ID	影響した公演数と最大遅延
`V_EQUIPMENT_HEALTH_SUMMARY`	日付・機器・指標ごとのセンサー集計	温度、パケットロス、ファン回転数
`EXT_EQUIPMENT_MAINTENANCE`	機器の保守予定日と実施状態	交換予定が過ぎていないか、作業が完了しているか
障害報告書 `IR-2026-081`	対象障害・機器の調査結果	確定した根本原因、寄与要因、再発防止策
ステージ音響ネットワーク運用手順 v2.1	主系・予備系の構成、監視閾値、復旧手順	いつ切り替え、何を確認するべきか

元Blogの回答で示された参照ファイルは、次の2つです。文書の内容は、サンプルデータ・業務文書の公開リポジトリのdocuments/pdf_ascii/で確認できます。

障害報告書：IR-2026-081_waveform_arena_delay_report.pdf
運用手順書：LSF2026_stage_audio_network_operations_v2.1.pdf

公演と障害報告書は障害IDで、センサー・保守履歴・文書は対象機器のIDなどで対応を確認します。日付と会場も合わせて、別の日や別の機器の値を混ぜないようにします。

すべての表に同じ障害IDがあるのではなく、Agentが質問で指定された対象を保ちながら、必要なSQLと文書検索を組み合わせています。

例えばV_STAGE_DELAY_ANALYSISは、公演予定と公演実績を公演IDでJOINし、ステージ名も付けたViewです。「公演の遅延を調べる」という業務の目的に合わせて、Database側でデータをまとめています。

● どのような回答で、その根拠は何か

元Blogの実際の回答を、参照元との対応が分かるように整理すると次のようになります。

確認項目	回答の要点	根拠
公演への影響	3公演に影響。最大遅延は29分。対象は`PERF-0033`／Circuit Bloom	`V_STAGE_DELAY_ANALYSIS`
機器の状態	最大温度91.755℃、最大パケットロス19.167%、最低ファン回転数120 RPM	`V_EQUIPMENT_HEALTH_SUMMARY`
保守の状態	ファン交換の予定日は7月25日、状態は`OVERDUE`。8月8日時点で14日超過	`EXT_EQUIPMENT_MAINTENANCE`
根本原因・寄与要因	製造ロットNW-2603の冷却ファン回転数低下。予定していたファン交換の未完了も寄与	障害報告書`IR-2026-081`のRoot Cause
復旧手順	Critical条件で予備スイッチ／DJリンクVLANへ切替。切替後に同期・波形・音声を確認し、対象機器を隔離	`LSF2026_stage_audio_network_operations_v2.1.pdf`
再発防止	対象機器交換、保守期限超過機器の本番投入防止、事前アラート、切替訓練	障害報告書`IR-2026-081`のCorrective Actions

パケットロスは通信データの欠落率、RPMは1分間の回転数です。温度の上昇、通信の欠落、ファン回転数の低下を、同じ機器の実績として確認しています。

元Blogでは、パケットロス5%超時の正式な切替手順をRAGで確認しています。また、複合分析の回答では、予備スイッチ／DJリンクVLANへの切替と、切替後の同期・波形・音声再生確認が示されました。具体的な判定条件と対応時間は、運用手順書の原文で確認します。手順書に定められた対応と、この障害で実際に行われた対応や復旧時間は分けて読みます。

この例で大切なのは、SQLの数値だけで原因を断定していないことです。SQLで異常の実績を確認し、障害報告書で確定した原因を確認し、運用手順書で対応方法を確認しています。

PAFのMain Agentが複数のToolを呼び分け、これらを1つの回答へまとめます。Select AIによるSQL・RAGと、それらの呼出しを制御するAgentの役割を組み合わせた構成です。

なお、このフェスのSQL Profileはcomments: falseで検証しています。この結果では、Viewで分析対象を整理したことやAgentへの指示と、COMMENTの効果を区別して考えています。

● 人が承認して、改善タスクを登録する

分析結果を読んだ後は、「ネットワークスイッチ交換と予防保守改善」のようなタスク案を作成し、人が内容を確認してから登録します。

元Blogでは、承認前は登録せず、別の発言で明示的に承認した後に、許可したPL/SQL Procedureを実行してタスクを登録するところまで確認しています。

また、今回のデモにおける承認待ちの制御はAgentへの指示で実現しています。本番の仕組みでは、承認を確認してから実行する処理や権限分離も、実行経路に組み込みます。

表と文書が整うと、1つのAgentを入口にして、「何が起きたかを調べる」「根拠を確認する」「改善を進める」までをつなげられます。

今回、AIに実行してもらったのは、改善タスクの登録までです。実際の機器交換やネットワークの切替は、このデモのActionには含めていません。AIの回答を人が確認・修正して、承認してから動くHuman-in-the-Loop（HITL） の形です。

ここから先を想像するのも面白いです。毎回人が承認するところから、決めた条件の範囲ではAIが処理を進め、人は見守って、おかしいときに止める Human-on-the-Loop（HOTL） へ。例えば、パケットロスが閾値を超えたら、決めておいた切替条件と運用手順に沿って予備系へ切り替える、といった構成です。
さらに、対象の処理を人の承認や介入なしで完結させる Human-out-of-the-Loop（HOOTL） まで考えると、 Autonomous System へどうつなげていくか、試してみてみたくなります。今回はタスク登録までですが、その先にも興味が広がってきました。

・実践Blog ：Autonomous AI Lakehouse × Private Agent Factoryで音楽フェス運営分析AI Agentを作ってみてみた

サンプルデータ・SQL・業務文書：Lakehouse Sound Festival 2026 PAF Demo

■ どこから試すとよいか

最初からすべてを構築する必要はありません。気になった疑問から、次の順番で試せます。

やってみたいこと	最初に読む記事	確認できたら次へ進むこと
自然言語でDatabaseへ問い合わせたい	日本語・タイ語・アラビア語でSelect AI	自分の質問に対する生成SQLを確認する
AIが間違えた理由を知りたい	メタデータからSQLを生成する仕組み	COMMENTを1つ追加し、プロンプトとSQLを比較する
業務用語をDatabase側で管理したい	COMMENT・ANNOTATIONS・Domain	共通化する意味と、Viewへまとめる業務条件を選ぶ
手元のスキーマを点検したい	AI Ready第1回	第2回で改善し、第3回で意味情報も確認する
認証情報の管理を整理したい	Resource Principal／OCI Vault	接続先に応じて認証方式と権限を確認する
SQLと文書検索を組み合わせたい	音楽フェスのAI Agent	SQLとRAGをそれぞれ確認してからAgentでまとめる

■ 勉強会を通して

最初は、「タイ語やアラビア語でも質問できるのか？」という楽しみから始まりました。

実際に動かしてみると、「何を見てSQLを作ったのか」が気になり、メタデータの話へ進みます。業務の意味を伝える方法を試すと、今度は「整っているかをどう評価するか」が気になります。そして、使えるデータと文書がそろうと、SQLとRAGを組み合わせたAgentで業務を調べるところまで広がってきました。

今回まとめてみて改めて感じたのは、AIへ何を伝えるかを整える仕事には、これまでのDatabase設計や業務理解がそのまま生きるということです。

表と列を説明すること、関係を定義すること、業務で使う条件をViewへまとめること、結果と根拠を確認すること。Select AIを使うと、こうした作業の意味が、また違った角度から見えてきます。

これからも、機能を調べるだけでなく、「これもできるのか？」と思ったことを、実際に試してみてみたいと思います。

■ 今回紹介したBlog一覧

記事名は、内容を選びやすいように一部短縮しています。

テーマ	Blog
きっかけ	世界各国のActive Data Guardから新年の挨拶
きっかけ	Data Guardを直列につないで世界一周
最初のSelect AI	日本語・タイ語・アラビア語でSelect AI
仕組み	メタデータからSQLを生成する仕組み
意味の管理	COMMENT・ANNOTATIONS・Domainの違いと検証
関係の理解	Claude＋SQLcl MCPでHR・OEのER図を作成
関係の理解	Cline＋SQLcl MCPでOracle Databaseへ自然言語で質問
Goldレイヤー	Autonomous AI Lakehouseでバラバラなデータをつなぐ
AI Ready第1回	HRスキーマを評価
AI Ready第2回	スコアを0.22から0.97へ改善し、Select AIで確認
AI Ready第3回	ANNOTATIONSとDomainの意味情報を可視化
接続・認証	Resource PrincipalでSelect AI
鍵の管理	OpenAI APIキーをOCI Vaultで管理
SQL＋RAG＋Action	音楽フェス運営分析AI Agentを作成

● Oracle公式ドキュメント

● おまけ

技術の話は、ずんだもんたちの漫画や動画でも紹介しています。文章とはまた違った雰囲気で見ていただけるとうれしいです。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up