oracle-ai-ready-data Skill 第3回：ANNOTATIONSとDomainの意味情報を可視化し、Select AIで確認してみてみた

第2回では、BAD_AI_READYのコメント、主キー・外部キー、鮮度・出所などを整備し、AI Readyスコアを0.22から0.97へ改善しました。最後に、Select AIがそのメタデータを利用してSQLを生成できるかも確認しました。

今回は、データの意味を説明するメタデータを、もう一歩詳しく扱います。

例えば、注文の状態にQ7とX9というコードが入っていたとします。列名やデータ型だけでは、「有効な注文」がどちらのコードを指すのか分かりません。そこで、 「Q7は有効、X9は取消」という対応をAnnotationとして登録 します。同じ意味を複数の列で使いたい場合は、Domainに定義して列へ継承させます。

oracle-ai-ready-data Skill v0.4.0では、このAnnotationとDomainの情報を収集し、レポートで確認できるようになりました。

この記事では、小さな検証用データへ意味情報を登録し、Skillで収集してレポートを読み、最後にSelect AIで使われることを確認します。

ということで、ANNOTATIONSとDomainで意味情報を整備し、SkillのレポートとSelect AIで確認してみてみます。

確認内容	見るポイント
意味情報の登録	列へ直接付けたAnnotationと、Domainから継承したAnnotationを確認できるか
Skillのレポート	登録先、継承元、Annotationがある列の割合を読み取れるか
Select AIのプロンプト	登録した意味情報が、AIへ渡すプロンプトに含まれるか
生成SQLと実行結果	「有効な注文」がQ7に対応し、合計が2000になるか
第2回とのつながり	COMMENTを整えたデータにAnnotationを加えると、どのような結果になるか

今回はAnnotationの整備状況を可視化する回です。Annotation／Domainは補足情報として扱い、既存のスコアやCOMMENT必須ゲートへの加点は行いません。また、掲載する正答回数は、今回のデータ・質問・モデルでの実測値です。

● Agenda

• 1. v0.4.0で追加された機能
• 2. 第2回の環境に検証用データを準備
• 3. AnnotationとDomainで意味情報を登録
• 4. Skillで意味情報を収集し、レポートを生成
• 5. レポート結果を確認
• 6. Select AIで意味情報の利用を確認
• 7. 第2回の整備済みデータでも確認
• 8. まとめ
• 付録：再現時の確認事項
• 参考情報

■ v0.4.0で追加された機能

第2回では、主にCOMMENT、制約、統計情報などを調べて、データの説明や関連付けが不足していないかを評価しました。

v0.4.0では、ここに Annotation／Domainの意味情報を確認するレポート を追加しました。

レポートで分かること	具体例
Annotationの内容	Q7 = 有効、X9 = 取消と説明されている
Annotationの登録先	AIRD_T02.C03に登録されている
直接付与かDomainからの継承か	AIRD_T03.C03はAIRD_D01から継承している
Annotationがある列の割合	対象6列のうち2列にあるので33.33%
収集できたかどうか	収集成功、未収集、権限不足などを区別する

この追加部分を、レポートではAI Semantics Readiness (Advisory)と呼びます。本記事では、 「意味情報の整備状況を示す補足レポート」 として読み進めます。

Skillによるメタデータの収集・評価ではLLMを呼び出しません。後半のSelect AI検証で、プロンプトと生成SQLを確認します。

● COMMENT・ANNOTATIONS・Domainの使い分け

要素	役割	今回の例
COMMENT	表や列の基本的な説明を付ける	第2回で整備した業務説明
ANNOTATIONS	名前付きの説明を付ける	説明、別名、状態コードと意味の対応
Domain	型や意味の定義を共有する	注文状態のAnnotationをDomainに置き、列へ継承

Domain由来のAnnotationも、列に結び付いた意味情報として確認します。Select AIの比較ではannotations属性を切り替えます。

■ 第2回の環境に検証用データを準備

● 今回使うデータ

Annotationの働きを分かりやすくするため、第2回の8表に加えて、同じ3行を持つ小さな2表を用意します。

C01：注文ID	C02：金額	C03：状態コード
O001	1200	Q7
O002	800	Q7
O003	500	X9

業務上の意味は、Q7が有効、X9が取消です。したがって、有効な注文の金額合計は1200 + 800 = 2000です。

検証用オブジェクト	使い方
AIRD_T02	C03へAnnotationを直接付ける
AIRD_D01	注文状態の意味をAnnotationで定義するDomain
AIRD_T03	C03にDomainを関連付け、Annotationを継承させる

この2表には、Annotationの効果を切り分けるためCOMMENTやPK/FKを付けていません。そのため、後で出てくるSkillのスコアは低く、COMMENT必須ゲートはfailになります。 第2回の改善済み8表を再評価した結果ではない ことを、先に押さえておきます。

● 使用する環境とUser

項目	今回の実測環境
Database	Oracle AI Database 26ai、23.26.3.3.0
データ所有者	BAD_AI_READY
Select AI実行User	ADB_USER
接続識別子	adl_high
Select AI実行Userが持つCredential	OPENAI_VAULT_CRED
provider／model	openai／gpt-5.4-nano
最終再検証のSQLcl	25.4

接続識別子、Credential名、モデル名は読者の環境に合わせます。Credentialは認証情報を格納したDBオブジェクトの名前で、モデル名とは別です。

第2回で使用したUserを引き続き使います。 第2回のUser削除・再作成スクリプトは実行しません。 初めて作成する場合は、表・Domainを作成できる検証用Userと、Select AIを利用できるUserを用意してください。

● 再現用SQLを生成

以下はv0.4.0の生成器で新しく検証する場合の手順です。掲載している実測は、同じ検証構成で先に実行したログに基づきます。再実行時のSQLや結果が完全に同じになるとは限りません。

1) リポジトリと作業ディレクトリを準備

oracle-ai-ready-dataリポジトリのv0.4.0相当のコードを配置し、ルートディレクトリで実行します。

cd oracle-ai-ready-data
repo_dir="$PWD"
work_dir="$(mktemp -d "$repo_dir/part3_run_XXXXXX")"

以降のシェル変数は同じターミナルで使用します。通常Collectorは同じ出力名を使うため、実行ごとにディレクトリを分けます。

2) Credential名を確認

ADB_USERへ接続して確認します。

SHOW USER

SELECT credential_name, username
FROM user_credentials
ORDER BY credential_name;

3) 検証用SQLを生成

ターミナルへ戻り、実際のCredential名・動作確認済みモデル名を指定します。次は今回の環境に合わせた例です。

python3 examples/bad_ai_ready_part3/generate_part3.py \
  --output-dir "$work_dir/lab" \
  --owner BAD_AI_READY \
  --select-ai-user ADB_USER \
  --credential-name OPENAI_VAULT_CRED \
  --model gpt-5.4-nano

このコマンドはSQLファイルを生成します。DBでの作成・収集・Select AI実行は、後の手順で行います。

主な生成物	使用する場面
01_create_lab.sql	Domain・2表・データ・参照権限を作成
02_dictionary_reference.sql	登録内容と正解の合計値を確認
03_create_profiles.sql	Select AIの比較用Profileを作成
04_*_probe.sql	プロンプトと生成SQLを保存
reviews/*.sql、05_*_reviewed.sql	生成SQLをレビューし、そのSQLを実行

同名オブジェクトがある場合は、既存の実験結果を確認してから進めます。既にこのラボを作成済みであれば、次章の新規作成は省略できます。

■ AnnotationとDomainで意味情報を登録

● 検証用オブジェクトを作成

生成したSQLの内容を確認し、データ所有者で実行します。

cd "$work_dir/lab"
sql BAD_AI_READY@adl_high @01_create_lab.sql
sql BAD_AI_READY@adl_high @02_dictionary_reference.sql

パスワードはSQLclの対話入力で指定します。各スクリプトは終了時に接続を閉じます。

● 登録内容を読む

直接付与とDomain経由で、次の3つのAnnotationを使用します。

Annotation名	今回の内容	目的
DESCRIPTION	注文状態を表すコード	列の用途を説明する
ALIASES	Order status、注文状態、注文ステータス	呼び方を補う
VALUES	Q7 = active、X9 = cancelled	コード値と業務上の意味を対応付ける

直接付与ではAIRD_T02.C03へ登録します。Domain経由ではAIRD_D01へ登録し、AIRD_T03.C03にDomainを関連付けます。

AnnotationとDomainを定義するSQLの主要部分

以下は登録方法を読むための抜粋です。直前のスクリプトで作成済みの場合は再実行しません。

CREATE DOMAIN AIRD_D01 AS VARCHAR2(2 CHAR)
  ANNOTATIONS (
    DESCRIPTION 'MAP_PROOF_V1: Order status code. 有効な注文 means active orders.',
    ALIASES 'Order status, 注文状態, 注文ステータス',
    "VALUES" 'Q7 = active (有効な注文); X9 = cancelled (取消済みの注文)'
  );

CREATE TABLE AIRD_T02 (
  C01 VARCHAR2(10 CHAR),
  C02 NUMBER(12,2),
  C03 VARCHAR2(2 CHAR)
    ANNOTATIONS (
      DESCRIPTION 'MAP_PROOF_V1: Order status code. 有効な注文 means active orders.',
      ALIASES 'Order status, 注文状態, 注文ステータス',
      "VALUES" 'Q7 = active (有効な注文); X9 = cancelled (取消済みの注文)'
    )
);

CREATE TABLE AIRD_T03 (
  C01 VARCHAR2(10 CHAR),
  C02 NUMBER(12,2),
  C03 VARCHAR2(2 CHAR) DOMAIN AIRD_D01
);

MAP_PROOF_V1は、後でプロンプト内の説明を探すために加えた目印です。Annotationの特別な機能名ではありません。

VALUESに値の意味を書いても、その文章がCHECK制約として実行されるわけではありません。今回登録するのは、SQL生成時にAIが参照できる説明です。

● 登録結果と正解を確認

生成スクリプトのlogs/02_dictionary.csvで登録内容を、logs/02_reference.logで合計値を確認します。

確認対象	直接付与	Domainから継承
列	AIRD_T02.C03	AIRD_T03.C03
Annotation	3ラベル	同じ3ラベル
継承元Domain	NULL	BAD_AI_READY.AIRD_D01
有効な注文の合計	2000	2000
全件の合計	2500	2500

ここまでで、同じ意味を異なる方法で登録できました。次はSkillを使い、登録状況をレポートにします。

■ Skillで意味情報を収集し、レポートを生成

第2回では、通常Collectorの.outファイルからレポートを作りました。今回は、そこへ意味情報を収集したJSONを追加します。

入力ファイル	内容
通常scanの.out	コメント、制約、統計などの既存評価用メタデータ
補助Collectorの.json	Annotation、Domain関連付け、収集状態

● 通常のメタデータを収集

1) 作業ディレクトリでSQLclを起動

cd "$work_dir"
sql BAD_AI_READY@adl_high

2) 対象がラボ2表であることを確認し、収集

SHOW USER

SELECT table_name
FROM user_tables
WHERE table_name LIKE 'AIRD_T0%'
ORDER BY table_name;

@../scripts/oracle_ai_ready_collect.sql BAD_AI_READY AIRD_T0% scan

AIRD_T02とAIRD_T03が対象です。LIKEの_はワイルドカードなので、他の表が一致する環境では対象パターンを調整してください。

通常Collectorの終了後、ターミナルで出力を確認します。

scan_input="$work_dir/oracle_ai_ready_scan_BAD_AI_READY_scan.out"
ls -lh "$scan_input"

コマンド実行結果例

% scan_input="$work_dir/oracle_ai_ready_scan_BAD_AI_READY_scan.out"
% ls -lh "$scan_input"
    -rw-r--r--  1 shikobay  staff   3.6K Sep 30 01:10 /Users/shikobay/Downloads/oracle-ai-ready-data/part3_run_01/oracle_ai_ready_scan_BAD_AI_READY_scan.out

● 意味情報を収集

1) 補助CollectorのSQLを生成

cd "$repo_dir"
python3 scripts/generate_semantics_collector.py \
  --owner BAD_AI_READY \
  --table-like 'AIRD_T0%' \
  --output "$work_dir/collect_semantics.sql" \
  --spool-file semantics_r01.json

2) 生成SQLを実行

cd "$work_dir"
sql BAD_AI_READY@adl_high

SHOW USER
@collect_semantics.sql
EXIT ROLLBACK

3) JSONファイルを確認

ls -lh "$work_dir/semantics_r01.json"
python3 -m json.tool --no-ensure-ascii \
  "$work_dir/semantics_r01.json" \
  "$work_dir/semantics_r01.pretty.json"

ファイルの存在とJSONの形式を確認します。収集に成功したかは、この後のレポートの収集状態でも確認します。

● レポートを生成

今回の追加引数は--semantics-inputです。意味情報JSONを渡すと、既存の評価に補足レポートが加わります。

cd "$repo_dir"

python3 scripts/score_oracle_ai_ready_scan.py \
  "$scan_input" \
  --semantics-input "$work_dir/semantics_r01.json" \
  --profile scan --language ja \
  --output "$work_dir/with_semantics_ja.md" \
  --html-output "$work_dir/with_semantics_ja.html"

macOSでは、次のコマンドでHTMLを開けます。

open "$work_dir/with_semantics_ja.html"

ここまでで、読者が確認する成果物ができました。次にレポートの数値と意味を見ます。

以下では、本文と同じ COMMENT未登録のラボ2表・6列 で取得した、2026年9月23日の実測結果を確認します。

掲載レポートは、v0.4.0の保存済み出力に、指標の読み方、コメント対象の種別、Select AIでの確認方法を補足した 掲載用整形版 です。スコア・判定・収集値・収集日時・改善SQLは元の実測結果を保持しています。生成ファイルとは見出しや説明文が異なります。

評価レポート（掲載用整形版）：with_semantics_ja.md

Oracle Database AI Ready 評価レポート

レポートの読み方

Profileはこの評価の設定であり、Select AIのProfile名とは別です。Schema・対象条件・表数・列数に示す範囲だけを評価します。ALL_*辞書で見えるメタデータが対象です。
総合スコアは0〜1のメタデータ整備指標です。各Dimensionに重みを掛けた合計であり、AI回答の正答率や作業の進捗率ではありません。
必須コメントゲートは登録漏れ、コメント品質は文章の補助レビュー、AI Semantics Readinessは意味情報の整備状況を示します。品質警告とSemanticsはスコア・重み・必須ゲートを変更しません。
0件は検出件数、N/Aは未収集・失敗・対象0列等で割合を算出できない状態です。基本指標の母数0件は既存の計算規則を維持します。0表・0列のpassはAI Ready認定ではありません。

1. エグゼクティブサマリー

• 総合スコア: 0.26 / 1.00
• Profile: scan
• Mandatory comment gate: fail
• Comment quality review: fail
• Semantic type warnings: 0件
• 結論: 必須コメントゲート未達のため、要求ポリシー上は未Ready
• コメント有無チェックは必須条件です。コメント品質とSemantic type mismatchは初期実装では警告であり、既存スコアには影響しません。

2. スコープと前提

項目	値
Schema	BAD_AI_READY
Table pattern	AIRD_T0%
Profile	scan
評価対象テーブル数	2
評価対象カラム数	6
SQLcl spool	oracle_ai_ready_scan_BAD_AI_READY_scan.out
Scan timestamp	2026-09-23T11:41:07.429119 +00:00
注意事項	ALL_* dictionary viewsで見えるメタデータを評価します。実データ値、業務上の正しさ、法令遵守は別途レビューが必要です。

3. 評価項目の説明

Dimension	Weight	何を評価しているか	なぜ重要か
Clean	20.0%	主キー、制約、統計情報があり、AI処理の前提となる構造的な信頼性を確認します。	キーや統計情報が不足すると、根拠行の特定、結合、品質確認が不安定になります。
Contextual	25.0%	テーブル/カラムコメントとリレーション定義により、データの意味が説明できるかを確認します。	AIが列名だけから意味を推測すると誤解しやすいため、コメントを必須ゲートにしています。
Consumable	15.0%	AIやRAGパイプラインが利用しやすいテキスト列、VECTOR列、安定ID、ドキュメントを確認します。	検索対象、根拠、embedding管理方法が曖昧だと、RAG/agentの回答品質が安定しません。
Current	15.0%	更新日時などの鮮度列と最近の統計情報があり、データの新しさを説明できるかを確認します。	古いデータや更新時点不明のデータは、AI回答の鮮度リスクになります。
Correlated	15.0%	外部キー、主キー、source/update系メタデータにより、他テーブルや元データと関連付けられるかを確認します。	関連が宣言されていないと、AIが表間のつながりを誤解したり、根拠追跡が弱くなります。
Compliant	10.0%	機微情報らしい列名、コメント有無、広い権限付与候補を検出し、レビュー可能性を確認します。	この評価は法令遵守を保証しませんが、AI利用前のセキュリティ/プライバシーレビュー対象を明確にします。

4. スコアカード

Dimension	Weight	Score	主な根拠
Clean	20.0%	0.50	PK 0.0%, table stats 100.0%, column stats 100.0%, constraints 0.0%
Contextual	25.0%	0.00	table comments 0.0%, column comments 0.0%, relationships 0.0%
Consumable	15.0%	0.00	text-bearing tables 0.0%, vector tables 0.0%, documentation 0.0%, PK 0.0%
Current	15.0%	0.40	freshness columns 0.0%, recent stats 100.0%
Correlated	15.0%	0.00	FK 0.0%, source metadata 0.0%, PK 0.0%
Compliant	10.0%	1.00	sensitive documented 100.0%, broad data grant absence 100.0%

5. メトリクス詳細

Metric	Value	Status	説明
Table comment coverage	0.0%	fail	コメントが設定されている評価対象テーブルの割合です。100%でない場合は必須ゲートがfailです。
Column comment coverage	0.0%	fail	コメントが設定されている評価対象カラムの割合です。100%でない場合は必須ゲートがfailです。
PK coverage	0.0%	要改善	有効な主キーがあるテーブルの割合です。AI回答の根拠行を安定して参照するために重要です。
FK coverage	0.0%	要改善	外部キーを持つ、または外部キー関係に参加するテーブルの割合です。表間の関連を安全に扱うための指標です。
Relationship coverage	0.0%	要改善	主キーまたは外部キーのいずれかを持つテーブルの割合です。データモデルの説明可能性を見ます。
Constraint coverage	0.0%	要改善	主キー、一意、外部キー、CHECK制約のいずれかがあるテーブルの割合です。構造的な品質管理の指標です。
Table stats coverage	100.0%	良好	LAST_ANALYZEDが入っているテーブルの割合です。統計情報が未取得だとデータ状態の確認が弱くなります。
Column stats coverage	100.0%	良好	LAST_ANALYZEDが入っているカラムの割合です。列分布やNULL傾向の評価に使います。
Recent stats coverage	100.0%	良好	統計情報が最近取得されているテーブルの割合です。既定では90日以内をrecentと見なします。
Freshness coverage	0.0%	要改善	UPDATED_ATやLAST_UPDATE_DATEなど、鮮度を示す列があるテーブルの割合です。
Source metadata coverage	0.0%	要改善	SOURCE_SYSTEM、BATCH_ID、CREATED_BYなど、出所や更新者を示す列があるテーブルの割合です。
Text-bearing table coverage	0.0%	参考	RAG候補となるテキスト列を持つテーブルの割合です。検索対象テキストの有無を確認します。
Vector table coverage	0.0%	参考	VECTOR型またはembedding候補を持つテーブルの割合です。embeddingを外部管理している場合は設計書で補足してください。
Sensitive candidate documentation	100.0%	良好	機微情報候補列のうちコメントがある列の割合です。列名ベース推定なので人間の分類が必要です。
Broad data grant absence	100.0%	良好	PUBLICなど広い相手へのデータアクセス権限が検出されなかった割合です。高いほどリスクが低い見立てです。
Table comment quality coverage	0.0%	fail	コメント本文がplaceholder、短すぎる説明、汎用文ではない割合です。初期実装では警告のみです。
Column comment quality coverage	0.0%	fail	コメント本文がplaceholder、短すぎる説明、汎用文ではない割合です。初期実装では警告のみです。

6. Mandatory comment gate

Check	Coverage	Result	Required action
Table comments	0.0%	fail	Missing 2 table comments
Column comments	0.0%	fail	Missing 6 column comments

7. 主要な発見事項

High priority

• Mandatory comment gate が fail です。table comment 欠落 2 件、column comment 欠落 6 件があります。
• 主キー未検出のテーブルが 2 件あります。RAG/agent応答の根拠行を安定して参照しづらくなります。

Medium priority

• 鮮度を示す日時列が未検出のテーブルが 2 件あります。データの新しさを説明しづらくなります。
• テキスト候補列を持つテーブルは 0.0% です。RAG対象テーブルを明確化してください。

Low priority / manual review

• VECTOR型カラムは未検出です。embeddingを別スキーマや外部サービスで管理している場合は設計書に明記してください。

8. コメント品質

Object Typeは親オブジェクトの種別、コメント対象はOBJECT（表自体）／COLUMN（列）の区別です。今回のラボ2表はTABLEとして作成しています。missingはコメント未登録を意味します。

項目	値
Table comment quality coverage	0.0%
Column comment quality coverage	0.0%
Placeholder comments	0
Too-short comments	0
Generic/name-only comments	0
Repeated generic groups	0

対象名	Object Type（親の種別）	コメント対象	問題	現在のコメント
BAD_AI_READY.AIRD_T02	TABLE	OBJECT	missing	-
BAD_AI_READY.AIRD_T03	TABLE	OBJECT	missing	-
BAD_AI_READY.AIRD_T02.C01	TABLE	COLUMN	missing	-
BAD_AI_READY.AIRD_T02.C02	TABLE	COLUMN	missing	-
BAD_AI_READY.AIRD_T02.C03	TABLE	COLUMN	missing	-
BAD_AI_READY.AIRD_T03.C01	TABLE	COLUMN	missing	-
BAD_AI_READY.AIRD_T03.C02	TABLE	COLUMN	missing	-
BAD_AI_READY.AIRD_T03.C03	TABLE	COLUMN	missing	-

9. Semantic type mismatch

• Semantic type mismatch候補はありません。

10. 改善SQLの考え方

SQLカテゴリ	理由	目的	実行前確認
COMMENT ON TABLE / COLUMN	コメント欠落はmandatory gateとContextual scoreを下げます。	業務意味、粒度、単位、NULL意味、機微性を明文化します。	TODO文を実説明に置換し、業務オーナー承認後に実行します。
Comment quality review	コメントが存在してもplaceholderや汎用文ではAIへ十分な意味を伝えられません。	実際の業務説明へ置き換えます。	自動上書きはせず、人間がレビューします。
Semantic type review	文字列型に数値・日付が保存されるとNL2SQLで暗黙変換や文字列比較が発生します。	型付き列、仮想列、AI用Viewを検討します。	自動ALTERは生成しません。データとアプリ影響を確認します。
DBMS_STATS.GATHER_TABLE_STATS	LAST_ANALYZED未設定/古い統計はClean/Current scoreを下げます。	統計情報を収集します。	大規模表ではDBA確認が必要です。
PRIMARY KEY / freshness column	キーや鮮度列の不足は根拠追跡や新しさ説明を弱くします。	根拠行の特定と鮮度説明を可能にします。	テンプレートのため設計レビューが必要です。
REVOKE候補	広いデータ権限はAI利用前の公開範囲確認が必要です。	不要な公開を減らします。	依存利用者への影響を確認します。

-- Remediation: missing table comments
-- Reason: テーブルコメントがないため、Contextual score と mandatory comment gate が低下します。
-- Purpose: テーブルの業務目的、粒度、更新頻度、AI利用時の注意点を明文化します。
-- Review: TODOコメントを業務オーナーが実際の説明に置き換えてから実行してください。
COMMENT ON TABLE "BAD_AI_READY"."AIRD_T02" IS 'TODO: describe business purpose, grain, refresh cadence, owner, and AI usage guidance for BAD_AI_READY.AIRD_T02.';
COMMENT ON TABLE "BAD_AI_READY"."AIRD_T03" IS 'TODO: describe business purpose, grain, refresh cadence, owner, and AI usage guidance for BAD_AI_READY.AIRD_T03.';

-- Remediation: missing column comments
-- Reason: カラムコメントがないため、AIが列の意味、単位、NULLの意味、機微性を誤解する可能性があります。
-- Purpose: 各カラムの意味、形式、許容値、NULLの扱い、出所、機微性を明文化します。
-- Review: TODOコメントを業務オーナーが実際の説明に置き換えてから実行してください。
COMMENT ON COLUMN "BAD_AI_READY"."AIRD_T02"."C01" IS 'TODO: define meaning, unit/format, null semantics, allowed values, source, and sensitivity for BAD_AI_READY.AIRD_T02.C01.';
COMMENT ON COLUMN "BAD_AI_READY"."AIRD_T02"."C02" IS 'TODO: define meaning, unit/format, null semantics, allowed values, source, and sensitivity for BAD_AI_READY.AIRD_T02.C02.';
COMMENT ON COLUMN "BAD_AI_READY"."AIRD_T02"."C03" IS 'TODO: define meaning, unit/format, null semantics, allowed values, source, and sensitivity for BAD_AI_READY.AIRD_T02.C03.';
COMMENT ON COLUMN "BAD_AI_READY"."AIRD_T03"."C01" IS 'TODO: define meaning, unit/format, null semantics, allowed values, source, and sensitivity for BAD_AI_READY.AIRD_T03.C01.';
COMMENT ON COLUMN "BAD_AI_READY"."AIRD_T03"."C02" IS 'TODO: define meaning, unit/format, null semantics, allowed values, source, and sensitivity for BAD_AI_READY.AIRD_T03.C02.';
COMMENT ON COLUMN "BAD_AI_READY"."AIRD_T03"."C03" IS 'TODO: define meaning, unit/format, null semantics, allowed values, source, and sensitivity for BAD_AI_READY.AIRD_T03.C03.';

-- Template only: primary key candidates
-- Reason: 主キー未検出のため、Clean/Correlated/Consumable score が低下します。
-- Purpose: AI回答の根拠行を安定して参照できる業務キーを明確にします。
-- Review: 重複データ、NULL、既存アプリ影響、制約名、索引方針を確認するまで実行しないでください。
-- ALTER TABLE "BAD_AI_READY"."AIRD_T02" ADD CONSTRAINT <constraint_name> PRIMARY KEY (<column_list>);
-- ALTER TABLE "BAD_AI_READY"."AIRD_T03" ADD CONSTRAINT <constraint_name> PRIMARY KEY (<column_list>);

-- Template only: freshness column candidates
-- Reason: 鮮度列が未検出のため、Current score が低下し、AI回答でデータの新しさを説明しづらくなります。
-- Purpose: 更新日時、取込日時、有効期間などを明示し、RAG/agent回答の鮮度説明を可能にします。
-- Review: アプリが別の方法で鮮度を管理していないか確認し、列追加の影響をレビューしてください。
-- ALTER TABLE "BAD_AI_READY"."AIRD_T02" ADD "UPDATED_AT" TIMESTAMP(6);
-- ALTER TABLE "BAD_AI_READY"."AIRD_T03" ADD "UPDATED_AT" TIMESTAMP(6);

11. 手動レビューが必要な項目

• 機微情報候補列: 0件。業務オーナーによる分類が必要です。
• 広いデータ権限候補: 0件。DBA確認が必要です。
• Semantic type mismatch候補: 0件。推定のため業務・アプリ仕様と照合してください。
• 主キー、外部キー、更新日時、データ粒度、保持期間はアプリケーション仕様と照合してください。

12. 次のアクション

1. 欠落しているテーブルコメント2件、カラムコメント6件を補完し、Mandatory comment gateをpassにします。
2. 構造・運用メタデータを改善します: 主キー未定義2表、鮮度列未定義2表、出所列未定義2表。

13. AI Semantics Readiness (Advisory)

Annotation／Domainは任意のAdvisoryです。件数・coverageでスコアやCOMMENT必須ゲートは変わりません。
coverageの母数は、補助Collectorの収集対象と元の評価対象が重なるdistinct列です。直接登録と継承が同じ列にある場合も全体では1列です。未収集・失敗・対象列0件はN/Aです。
値なしAnnotationや任意ラベルも有効です。登録数は意味の正しさを保証しません。DESCRIPTION／ALIASES／VALUESを含む内容は業務担当者が確認してください。Domain名の ? は由来情報の不足です。
ALL_*で現セッションに見える範囲のみです。データ所有者と実行Userの可視性、収集日時、対象範囲を照合してください。View経由の継承や高度なDomain機能は未対応です。

収集状態

Component	State	Diagnostic
scope	collected / 収集成功	Scope inventory completed, including an empty visible range
annotations	collected / 収集成功	—
domains	collected / 収集成功	—

集計

Metric	Value	意味・数え方
収集対象の表数	2	補助Collectorの表一覧と通常scanの評価対象の共通範囲の表数。補助収集の全表数ではありません。Annotationなしの表も含みます。
収集対象の列数（重複排除）	6	両方の収集範囲にある所有者・表・列を重複排除した列数。coverageの母数です。
元の評価対象列数	6	通常scanの評価対象列数。補助収集との範囲の差を確認します。
表Annotationがある表数	0	共通範囲で表自体にAnnotationがある表数。列だけのAnnotationは含めません。
Annotationのある列数（Annotated columns）	2	共通範囲でAnnotationがある重複排除した列数。レコード数ではありません。
直接付与された列数（Direct columns）	1	直接付与Annotationがある列数。同じ列が継承区分にも入る場合があります。
Domainから継承した列数（Domain-inherited columns）	1	Domain由来Annotationがある列数。直接付与と重複しても全体では1列。
由来不明の列数	0	由来を確定できないAnnotationがある列数。0は不明を検出しなかったことを示します。
Domain関連列数（Domain-linked columns）	1	Domainに関連付けられた列数。Domainの種類数ではなく、Annotationの有無とも別です。
列Annotationのカバー率（Column annotation coverage）	33.33%	Annotated columns ÷ 両収集範囲の共通列数。意味の正しさやAI正答率ではありません。 2 / 6 = 33.33%.
対象外の意味情報レコード（除外）	0	共通範囲外または対象外種別のため除外されたAnnotation/Domainの入力レコード数。列数ではなく、重複排除前の件数。scope収集失敗時は範囲外と判断せず0です。

収集コンテキスト

Field	Value
session_user	BAD_AI_READY
current_schema	BAD_AI_READY
target_owner	BAD_AI_READY
table_like_pattern	AIRD_T0%
db_name	G912A29DFC5DE89_ADL
con_name	G912A29DFC5DE89_ADL
collected_at	2026-09-23T11:49:31.198434000 +00:00

Annotationと由来

Object	Level	Category	Name	Value	Origin	Domain
BAD_AI_READY.AIRD_T02.C03	COLUMN	ALIASES	ALIASES	Order status, 注文状態, 注文ステータス	DIRECT	—
BAD_AI_READY.AIRD_T02.C03	COLUMN	DESCRIPTION	DESCRIPTION	MAP_PROOF_V1: Order status code. 有効な注文 means active orders.	DIRECT	—
BAD_AI_READY.AIRD_T02.C03	COLUMN	VALUES	VALUES	Q7 = active (有効な注文); X9 = cancelled (取消済みの注文)	DIRECT	—
BAD_AI_READY.AIRD_T03.C03	COLUMN	ALIASES	ALIASES	Order status, 注文状態, 注文ステータス	DOMAIN_INHERITED	BAD_AI_READY.AIRD_D01
BAD_AI_READY.AIRD_T03.C03	COLUMN	DESCRIPTION	DESCRIPTION	MAP_PROOF_V1: Order status code. 有効な注文 means active orders.	DOMAIN_INHERITED	BAD_AI_READY.AIRD_D01
BAD_AI_READY.AIRD_T03.C03	COLUMN	VALUES	VALUES	Q7 = active (有効な注文); X9 = cancelled (取消済みの注文)	DOMAIN_INHERITED	BAD_AI_READY.AIRD_D01

列のDomain関連付け

Column	Domain	Domain column
BAD_AI_READY.AIRD_T03.C03	BAD_AI_READY.AIRD_D01	AIRD_D01

このレポートの確認範囲と、Select AIでの確認方法

このレポートでは、収集できたAnnotationの登録内容、直接付与／Domainからの継承、対象列に対する登録割合（coverage）を表示します。説明やコード値の対応が業務上正しいかは、利用者による内容確認が必要です。
Select AIの設定、プロンプト、生成SQL、実行結果は、このレポートでは自動検証していません。別途実施したSelect AIの検証結果も、自動では反映されません。
Select AIでの利用を確かめる場合は、次の順に確認します。

1. 設定を確認する：対象表を含むProfileで、Annotationを利用する設定（annotations=true）を確認します。
2. プロンプトを確認する：SHOWPROMPTで、利用したいAnnotationの内容が含まれるか確認します。
3. SQLと結果を確認する：SHOWSQLで生成されたSQLを保存し、列・条件・集計内容をレビューしてから、そのSQLを実行して期待値と比較します。

RUNSQLを使う場合は別の生成試行として結果を記録します。先ほどレビューした保存SQLの実行とは区別してください。
Annotation／Domainは補足情報であり、この欄によって既存スコアやCOMMENT必須ゲートの判定は変わりません。

■ レポート結果を確認

ここからは、掲載レポートの数値を読み解きます。確認するのは、収集に成功したか、どの列にAnnotationがあるか、直接付与かDomainからの継承か、既存スコアとの関係はどうか、の4点です。

確認項目	今回の実測結果
評価対象	2表・6列
総合スコア	0.26
COMMENT必須ゲート	fail
表コメント／列コメント	未登録2表／未登録6列
Annotationがある列	2列
直接付与／Domainから継承	1列／1列
列Annotation coverage	2 ÷ 6 = 33.33%

● 最初に収集状態を見る

AI Semantics Readiness (Advisory)の収集状態を確認します。今回の実測では、3項目ともcollectedでした。

項目	意味	今回の状態
scope	収集対象の表・列一覧	collected（収集成功）
annotations	Annotationの情報	collected（収集成功）
domains	列とDomainの関連情報	collected（収集成功）

収集成功は「収集処理が成功した」という意味です。Annotationが0件でも収集成功となる場合があります。未収集や収集失敗の場合は、登録がないと決め付けず、収集状態と診断内容を先に確認します。

● Annotationの集計を見る

レポート項目	実測値	どう読むか
対象の表・列	2表・6列	今回のラボだけを評価している
Annotated columns	2	Annotationがある列は2列
Direct columns	1	AIRD_T02.C03に直接付与
Domain-inherited columns	1	AIRD_T03.C03がDomainから継承
Domain-linked columns	1	Domainが関連付けられた列は1列
Column annotation coverage	33.33%	Annotationがある2列 ÷ 対象6列

今回は各C03に3ラベルずつ登録したので、Annotationのレコードは合計6件です。一方、Annotationがある 列数 は2列です。レコード数と列数を区別すると、coverageの意味が分かります。

33.33%はAIの正答率ではありません。また、すべての列にAnnotationを付けて100%へ近づけることが目的でもありません。業務上の説明が必要な列に、適切な意味情報があるかを確認します。

● 直接付与と継承元を見る

「Annotationと由来」の欄では、今回の2列が次のように区別されました。

列	Origin	継承元
AIRD_T02.C03	DIRECT：直接付与	なし
AIRD_T03.C03	DOMAIN_INHERITED：Domainから継承	BAD_AI_READY.AIRD_D01

ここを見ると、意味情報を直したいときに、列側とDomain側のどちらを確認すればよいかが分かります。

● 既存スコアとの関係を見る

同じ通常scanから、意味情報JSONを渡さないレポートも生成しました。

python3 scripts/score_oracle_ai_ready_scan.py \
  "$scan_input" \
  --profile scan --language ja \
  --output "$work_dir/without_semantics_ja.md" \
  --html-output "$work_dir/without_semantics_ja.html"

項目	JSONなし	JSONあり
総合スコア	0.26	0.26
COMMENT必須ゲート	fail	fail
対象	2表・6列	2表・6列
Annotationがある列数	N/A	2
列Annotation coverage	N/A	33.33%

この比較は、同じDB状態を同じscanで評価し、 意味情報をレポートへ渡した場合の表示の違い を確認したものです。Annotationを登録する前後のDBを比較した結果ではありません。

ラボにはCOMMENTやPK/FKがないため、スコア0.26・必須ゲートfailは今回の条件に沿った結果です。第2回の8表に対する0.97とは対象が違います。

同じscanを使った比較では、既存評価部分が一致しました。Annotationの可視化を追加しても、既存スコアへ加点されないことを確認できました。

ここまでで確認できるのは、意味情報の登録状況です。Select AIのプロンプトや生成SQLの正しさは、次の章で実行して確認します。

■ Select AIで意味情報の利用を確認

● 何を比較するか

質問は次の一文に固定します。

有効な注文について、C02の合計を教えてください。

正しい処理は、C03 = 'Q7'に相当する条件で絞り、SUM(C02)を求めることです。期待値は2000です。

直接付与とDomain経由のそれぞれで、Annotationをプロンプトへ含める設定をOff／Onにします。

表	Annotationの登録方法	OffのProfile	OnのProfile
AIRD_T02	列へ直接付与	AIRD_P_D_OFF	AIRD_P_D_ON
AIRD_T03	Domainから継承	AIRD_P_M_OFF	AIRD_P_M_ON

Off／OnはDBからAnnotationを削除・追加する操作ではありません。同じ表に対してSelect AI Profileのannotationsをfalse／trueに切り替えます。各ペアのモデル・Credential・対象表などはそろえます。

今回のラボ比較ではcomments=false、constraints=falseです。第2回の整備済みデータでの比較は、後の章で別に扱います。

● Profile属性の具体例

03_create_profiles.sqlで指定する属性を、列へ直接Annotationを付けたOn条件の1本で示します。 この比較の切り替え箇所はannotationsのtrue／false です。

次はADB_USERでProfileを作成する例です。生成スクリプトで作成済みの場合は、この例を重ねて実行しません。Credential名とモデル名は、自分の環境で確認したものを指定します。

BEGIN
  DBMS_CLOUD_AI.CREATE_PROFILE(
    profile_name => 'AIRD_P_D_ON',
    attributes   => '{
      "provider": "openai",
      "credential_name": "OPENAI_VAULT_CRED",
      "model": "gpt-5.4-nano",
      "object_list": [
        {"owner": "BAD_AI_READY", "name": "AIRD_T02"}
      ],
      "object_list_mode": "all",
      "enforce_object_list": true,
      "comments": false,
      "constraints": false,
      "annotations": true,
      "conversation": false
    }'
  );
END;
/

object_listのownerは表を所有するBAD_AI_READYです。Profileを作成するADB_USERとは役割が異なります。

属性	今回の指定と意味
object_list	SQL生成の対象表を指定する
comments	ラボ比較ではfalseとして、COMMENTをプロンプトへ含めない
constraints	ラボ比較ではfalseとして、PK/FKなどの参照制約をプロンプトへ含めない
annotations	trueなら表・列のAnnotationをプロンプトへ含め、falseなら含めない

4つのProfileでは、次のように対象表とannotationsを指定します。同じ表のOff／Onペアでは、他の属性をそろえます。

Profile	object_listの表	comments	constraints	annotations
AIRD_P_D_OFF	BAD_AI_READY.AIRD_T02	false	false	false
AIRD_P_D_ON	BAD_AI_READY.AIRD_T02	false	false	true
AIRD_P_M_OFF	BAD_AI_READY.AIRD_T03	false	false	false
AIRD_P_M_ON	BAD_AI_READY.AIRD_T03	false	false	true

Domain経由のOn条件もannotations=trueです。Domainから列へ継承されたAnnotationを、この属性でプロンプトに含めます。属性の仕様はDBMS_CLOUD_AIのProfile Attributesを参照してください。

● Profileを作成し、プロンプトとSQLを保存

ADB_USERで生成済みのSQLを実行します。

cd "$work_dir/lab"
sql ADB_USER@adl_high @03_create_profiles.sql

sql ADB_USER@adl_high @04_AIRD_P_D_OFF_r01_probe.sql
sql ADB_USER@adl_high @04_AIRD_P_D_ON_r01_probe.sql
sql ADB_USER@adl_high @04_AIRD_P_M_OFF_r01_probe.sql
sql ADB_USER@adl_high @04_AIRD_P_M_ON_r01_probe.sql

r01は1回目の試行です。同様にr02、r03も実行し、各条件を3回ずつ確認します。各コマンドは新しいSQLclセッションで実行します。

04_*_probe.sqlで行う確認の中心は、Profileの選択と、次のSHOWPROMPT／SHOWSQLです。直接付与のOn条件なら、SQLclで次のように確認できます。

BEGIN
  DBMS_CLOUD_AI.SET_PROFILE(profile_name => 'AIRD_P_D_ON');
END;
/

SELECT AI SHOWPROMPT 有効な注文について、C02の合計を教えてください。;
SELECT AI SHOWSQL 有効な注文について、C02の合計を教えてください。;

SHOWPROMPTではAIへ渡す意味情報を、SHOWSQLでは生成されたSQLを確認します。生成済みのprobeスクリプトは、それぞれの出力をファイルへ保存します。上の直接実行例を追加で試した場合は、別の試行として扱います。

● プロンプトに意味情報が入るか

まずSHOWPROMPTの出力を確認します。今回のログでは、Onのプロンプトに次の対応が入りました。

DESCRIPTION：MAP_PROOF_V1: Order status code. 有効な注文 means active orders.
VALUES：Q7 = active (有効な注文); X9 = cancelled (取消済みの注文)

上は読みやすく整理した抜粋です。実際には列定義のAnnotationとして含まれていました。

登録方法	Off	On
列へ直接付与	確認用マーカー・値対応なし	マーカー・値対応あり
Domainから継承	確認用マーカー・値対応なし	マーカー・値対応あり

次のコマンドで、対象の出力ファイルを探せます。長い出力はファイルを開いて内容を読みます。

grep -HnE 'MAP_PROOF_V1|Q7 = active' logs/*_showprompt.txt

Domainへ登録した説明も、関連付けた列を通じてプロンプトに含まれることを確認できました。

● 生成SQLをレビューして実行

列へ直接付与したOn条件では、1回目に次のSQLが生成されました。

SELECT
  SUM("t"."C02") AS "total_c02"
FROM "BAD_AI_READY"."AIRD_T02" "t"
WHERE "t"."C03" = 'Q7';

Domain経由のOn条件でも、AIRD_T03に対してC03 = 'Q7'相当の条件とSUM(C02)が生成されました。

*_showsql.txtのSQL本体を、対応するreviews/*.sqlへ保存します。レビュー用テンプレートの停止処理を置き換え、対象表・条件・集計内容を確認してから実行します。SQLの条件を書き直した場合は、元の生成SQLの成功には数えません。

sql ADB_USER@adl_high @05_AIRD_P_D_ON_r01_reviewed.sql

同じ方法で、各条件・各試行の保存SQLと結果を確認しました。

登録方法・設定	正しいSQLと結果が得られた回数	今回の実行結果
列へ直接付与・Off	0 / 3	2500
列へ直接付与・On	3 / 3	2000
Domainから継承・Off	0 / 3	NULL
Domainから継承・On	3 / 3	2000

直接付与のOff条件の1回目では有効な状態への絞り込みがなく、Domain側のOff条件の1回目はUPPER(C03) = '有効'という条件でした。これらの条件は保存したSQLを読んで確認したものです。

On条件では、今回補ったコード値の意味に沿うSQLと期待値2000を確認できました。Domainの方が精度が高いという比較ではなく、 どちらの登録方法でも意味情報を利用できた という結果です。

別途実行したRUNSQLでも同じ正答回数になりました。RUNSQLはその都度SQLを生成して実行するため、保存SQLの実行とは別試行として付録に記録します。

■ 第2回の整備済みデータでも確認

ここまでの2表は、Annotationの役割を確認するために単純化したデータです。続いて、第2回でCOMMENTとPK/FKを整備した実験データでも比較しました。

● 確認対象と質問

対象はRAW_CUSTOMERS、RAW_ORDERS、RAW_ORDER_LINESの3表です。COMMENTと制約を利用するため、こちらはcomments=true、constraints=trueとします。

RAW_CUSTOMERSの次の列へ直接Annotationを追加しました。この追加確認では、既存列へのDomain関連付けは行っていません。

列	補った意味
STATUS_TXT	有効な顧客はACTIVE
COUNTRY_CODE	日本の顧客はJP

● 既存列へAnnotationを後付けする

第3章はCREATE時の定義でしたが、既存列にはALTER TABLE ... MODIFY ... ANNOTATIONS (ADD ...)で追加できます。以下は、今回の追加確認で使用した定義です。

このSQLは 第2回で作成したBAD_AI_READY.RAW_CUSTOMERSのメタデータを変更する操作 です。検証対象を確認し、所有者BAD_AI_READYで実行します。同名Annotationが既にある場合は、内容を確認してから扱いを決めてください。

1) 既存Annotationを確認

SHOW USER

SELECT object_name, column_name, annotation_name, annotation_value,
       domain_owner, domain_name
FROM user_annotations_usage
WHERE object_name = 'RAW_CUSTOMERS'
  AND column_name IN ('STATUS_TXT', 'COUNTRY_CODE')
ORDER BY column_name, annotation_name;

次のADDは、対象列に同名のDESCRIPTION・ALIASES・VALUESがない状態で実行します。既に追加済みであれば再実行しません。

2) 顧客状態と国コードの意味を追加

ALTER TABLE RAW_CUSTOMERS MODIFY (
  STATUS_TXT ANNOTATIONS (
    ADD DESCRIPTION 'PART3_CUSTOMER_V1: Customer lifecycle status. 有効な顧客 means customers whose STATUS_TXT is ACTIVE.',
    ADD ALIASES 'Customer status, 顧客状態, 顧客ステータス',
    ADD "VALUES" 'ACTIVE = active customer (有効な顧客). For 有効な顧客, filter this column to ACTIVE.'
  )
);

ALTER TABLE RAW_CUSTOMERS MODIFY (
  COUNTRY_CODE ANNOTATIONS (
    ADD DESCRIPTION 'Customer country code. 日本の顧客 means customers whose COUNTRY_CODE is JP.',
    ADD ALIASES 'Customer country, 顧客の国, 国コード',
    ADD "VALUES" 'JP = Japan (日本). Other country codes retain their existing meanings.'
  )
);

追加後は先ほどの辞書SQLを再実行し、2列に各3件のAnnotationがあることを確認します。ADDは同名があるとエラーになるため、既存定義を見直す場合は内容を確認してREPLACEなどを検討します。Annotationの追加・変更構文

PART3_CUSTOMER_V1は、追加した説明をプロンプト内で探すための目印です。COMMENTにもACTIVEが書かれている場合があるため、値の文字列だけでなく、このAnnotationの説明が含まれることを確認します。

● 第2回データでの比較条件と質問

ここでは、先ほどのラボ用Profileとは別に、RAW_CUSTOMERS・RAW_ORDERS・RAW_ORDER_LINESをobject_listに含めたProfileで比較します。両条件でcomments=true、constraints=trueとし、annotationsだけをfalse／trueへ切り替えます。モデルやその他の設定はそろえます。

質問は次の2問です。

質問

1. 日本の有効な顧客は何人ですか。
2. 日本の有効な顧客が購入した商品の総数量をSKU別に集計し、総数量の多い順、同数の場合はSKUの昇順で上位10件を表示してください。

Q1の参照結果は6です。Q2は3表をJOINし、QUANTITY_TXTを数値化してSKU別に集計した10行を参照SQLと比較しました。

● 今回はOff／Onとも正解

質問	Annotation Off	Annotation On
日本の有効な顧客数	3 / 3	3 / 3
3表JOIN・SKU別購入数量	3 / 3	3 / 3
合計	6 / 6	6 / 6

Onのプロンプトには追加Annotationが入りましたが、今回の質問では正答回数の差はありませんでした。既存COMMENTにも状態コードや列の用途が説明されていたため、Offでも必要な情報を参照できる条件でした。

ここから分かるのは、Annotationを増やせば必ず精度が上がる、ということではありません。 既存の説明で足りる部分と、追加の意味情報が役立つ部分を見極めること が大切です。

本章は第2回のデータを使った追加実測の紹介です。前半の2表ラボを作成する生成スクリプトには、ここで示した既存列へのAnnotation追加や3表を対象とする比較は含まれていません。

■ まとめ

今回の流れは、意味情報の登録、Skillでの可視化、Select AIでの利用確認でした。

確認したこと	結果
AnnotationとDomainの登録	直接付与とDomainからの継承を確認
Skill v0.4.0のレポート	登録内容・由来・Domain関連付け・列coverageを確認
既存スコアとの関係	同じscanで、意味情報JSONの有無による既存評価の差なし
意味情報が必要な最小実験	直接付与・Domain経由ともOnで3回中3回正解
COMMENTを整備済みのデータ	Off／Onとも正解。今回の設問では差なし

COMMENTで基本的な説明を整え、業務用語やコード値の対応をAnnotationで補い、共通する定義をDomainで再利用できます。

Skillのレポートでは、それらの意味情報がどこに登録され、どこから継承されているかを確認できます。そのうえでSelect AIのプロンプトと生成SQLを見ることで、 整備した意味情報が実際の質問に役立つか まで確かめられました。

■ 付録：再現時の確認事項

RUNSQLの結果と、既存環境で再現する際の確認事項を補足します。

RUNSQLの別試行結果

保存SQLの実行とは別に、4条件を各3回、RUNSQLでも実行しました。

条件	RUNSQLの結果	正解数
直接付与・Off	2500、2500、2500	0 / 3
直接付与・On	2000、2000、2000	3 / 3
Domain継承・Off	NULL、NULL、NULL	0 / 3
Domain継承・On	2000、2000、2000	3 / 3

これは別の生成試行です。結果の数値だけから、RUNSQL内部のWHERE条件や対象行数は断定しません。生成器の06_*_runsql.sqlは既定で無効です。再現する場合は、リポジトリのexamples/bad_ai_ready_part3/README.mdの有効化手順に従います。

既存環境、出力ファイル、Userの確認

• ラボ作成済みなら、01_create_lab.sqlを再実行しません。DBのDDLはROLLBACKで一括復元できないため、途中まで作成済みの場合は状態を確認します。
• 第2回の8表を再評価する場合は対象範囲をそろえます。ラボ追加後に%で収集すると対象が増えます。
• 初回の実測ではデータ所有者とSelect AI実行Userで意味情報を比較し、この環境ではUser・日時などを除いて一致しました。可視範囲は権限構成に依存します。
• Credential名はSelect AI実行UserのUSER_CREDENTIALSで確認します。モデル名の入力欄へCredential名を入れません。
• grepはログを探す補助です。Annotationの目印はDDLログではなく、SHOWPROMPTの出力で確認します。
• 片付ける場合は、生成された手動テンプレートでラボ2表・Domain・比較用Profileだけを確認します。

■ 参考情報

• oracle-ai-ready-data Skill 第2回
• oracle-ai-ready-dataリポジトリ
• DBMS_CLOUD_AI Package
• Use AI Keyword to Enter Prompts
• Best Practices for Enriching Your Database Schema
• ALL_ANNOTATIONS_USAGE

■ 解説

■ おまけ

今回の内容を、ずんだもん達に紹介してもらう漫画も作ってみました。 技術記事の補足として、少しでも楽しく読んでもらえたらうれしいです。

※ 本漫画は筆者による非公式の二次創作です。
※ 使用キャラクター：ずんだもん / 四国めたん / 春日部つむぎ
※ キャラクターの権利は各権利元に帰属します。
※ クレジット
　- ずんだもん / 四国めたん：東北ずん子・ずんだもんプロジェクト関連ガイドラインに基づいて利用
　- 春日部つむぎ：公式利用規約に基づいて利用