AIの技術回答は正しい？ 公式ドキュメントと実測で確かめる方法｜存在しない列・版ちがい・資料にない仕様をOracle 19cで検証

こんにちは、おうどんです🍜

おうどん「Oracle 19c で、表領域の空きと自動拡張の上限をまとめて見る SQL ある？」

AIくん「お任せください！ 空きは DBA_TABLESPACES の FREE_BYTES 列で一発です！」

おうどん「おお、一発。頼もしい」

コピーして、貼って、実行。

ORA-00904: "FREE_BYTES": invalid identifier

おうどん「……一発で、撃たれたのはこっちだった」

（会話は説明用の架空の場面です。AIくんの回答も架空。エラーは今回の検証環境で実際に出たものの最終行です）

AI の技術回答は、とにかく自信満々です。
敬語もきれい。SQL もそれっぽい。列の名前も、いかにもありそう。

でも、それっぽいことと、正しいことは別なんです。

うどん屋さんで言うと、AI は仕込みがめちゃくちゃ速い新人さん。
ただ、味見をせずにお客さんに出すと、たまに塩と砂糖を入れ替えています。

AIくん「白い粉だったので、同じかと思いました！」

……白いのは合ってる。

今回は、AI の技術回答を、公式ドキュメントと実測で確かめる方法を、Oracle Database 19c の架空の回答を例に、実際に SQL を動かしながら整理します。
AI を使うな、という話ではありません。出す前に味見しよう、という話です。

まずは、初心者向けのチェックリストです。

• AI の回答は、主張を1文ずつに分けてから確かめる
• 確かめる前に、自分の環境の版（バージョン）を確認する
• 公式ドキュメントで該当する文を探し、見つからない主張は「未確認」のまま使わない

AIの回答は「味見してから出す」もの

結論から言うと、AI の回答は下ごしらえ済みの材料です。そのままお客さん（本番）には出さず、味見（検証）をしてから出します。

これは AI を作っている会社自身も言っています。
Anthropic（Claude を作っている会社）の開発者向けドキュメント「Reduce hallucinations」には、

• 最先端の言語モデルでも、事実と違う文章を作ることがある（これをハルシネーション＝幻覚と呼ぶ）
• 減らす工夫として、「分からない」と言ってよいと伝える、主張ごとに引用や出典を付けさせる、などがある
• ただし、こうした工夫は減らすけれどなくしはしない。重要な情報は必ず確かめること

と書かれています。

AIくん「つまり、ぼくは味見しなくていいってことですね！」

おうどん「逆。味見はこっちの仕事って意味」

……作った本人が「味見して」と言っている料理を、そのまま出す勇気。

読者の心の声「でも、確かめるくらいなら最初から自分で調べたほうが早くない？」

そう思いますよね。
でも、AI の回答は「どこを調べればいいか」の地図としては、かなり便利なんです。地図に載っている道が本当にあるか、歩いて確かめる。それが今回のやり方です。

おうどん「地図の通りに歩いたら、川だった」

AIくん「橋の予定地です！」

……予定地は、まだ渡れません。

架空の回答を、主張ごとに分ける

最初にやるのは、回答を、確かめられる単位の主張に分けることです。
長い回答をまとめて「合ってる？」と見ると、正しい部分に引っぱられて、間違いを見落とします。

今回の架空の回答（質問は「Oracle 19c で表領域の空きと自動拡張の上限を見たい」）を、主張に分けるとこうなりました。

番号	AIくんの主張（架空）	主張の種類
①	空きは DBA_TABLESPACES の FREE_BYTES 列で見られる	列の存在
②	DBA_DATA_FILES の AUTOEXTENSIBLE 列で、自動拡張するか分かる	列の存在と意味
③	MAXBYTES が 0 のファイルは上限なし（UNLIMITED）なので、計算から外してよい	値の意味（仕様）
④	接続できたかの確認は SELECT 1; でよい	構文（版による違い）

用語を少しだけ。

• 表領域：Oracle がデータをしまう棚の単位。実体はデータファイル（ディスク上のファイル）
• DBA_TABLESPACES・DBA_DATA_FILES：表領域やデータファイルの情報を見せてくれる、Oracle のデータ・ディクショナリ・ビュー（Oracle 自身の台帳を見る窓）
• 自動拡張（AUTOEXTEND）：データファイルがいっぱいになったら、決めた上限まで自動で大きくなる設定

AIくん「1つの回答を4つに切るなんて、うどんの切り方みたいですね」

おうどん「切ってみたら、1本だけそばが混ざってるかもしれない」

……混ざってるかどうかは、すすってみないと分かりません。

主張の種類も書いておくと、確かめ方が決まります。

• 列の存在 → ディクショナリを引く。実行してみる
• 値の意味（仕様） → 公式ドキュメントの該当箇所。実測でつじつまが合うか
• 構文・版による違い → 自分の版のドキュメントと、自分の版での実行

AIくん「④は構文なので、ぼくの得意分野です！」

おうどん「得意分野ほど、味見する」

……自信がある料理ほど、しょっぱくなりがち。

確かめ方の基本は「版・資料・実行」の3つ

細かい話の前に、まずはこの3つだけで、かなりの間違いが見つかります。

1. 自分の版を確認する

AI は、質問に「19c」と書いても、別の版の知識で答えることがあります。だから、比べる相手（自分の環境）の版を先に確かめます。

select version_full from v$instance;
show con_name

VERSION_FULL
-----------------
19.3.0.0.0

CON_NAME
------------------------------
PDB19

（今回の検証環境：Oracle Database 19c 19.3、シングルインスタンス・CDB 構成。PDB の中で実行しています。下の確認用 SQL の実行結果から、この2つ分を抜き出して並べたものです）

VERSION_FULL は、18c から入った新しい版の番号の付け方で版を表す列です（19c の V$INSTANCE のリファレンス）。
CON_NAME は、今いるコンテナ（CDB の本体か、どの PDB か）の名前です。

AIくん「19.3 なら、ほぼ 23 ですね！」

おうどん「どこを四捨五入したの」

……版の番号は、四捨五入しないでください。

2. 公式ドキュメントで該当する文を探す

AI の主張に対応する文が、自分の版のドキュメントにあるかを見ます。
「だいたいこんな感じのことが書いてある」ではなく、その主張を直接言っている文があるかどうかです。

3. 確認用の SQL で実際に動かす

列があるか、値が本当にそうなっているかは、動かすのが一番早いです。
このとき、何も変更しない SQL（SELECT だけ）で確かめます。検証のために本番のデータや設定を変えたら、味見のつもりが鍋をひっくり返しています。

おうどん「味見のつもりで、鍋ごと飲んだ」

AIくん「おいしかったですか？」

……そういう問題じゃない。

🔰 ここまで読めば今日から困らない

• AI の回答は、主張を1文ずつに分ける
• 自分の版（VERSION_FULL など）を確かめてから比べる
• 公式ドキュメントで主張を直接言っている文を探す。なければ「未確認」
• 確かめるときは、何も変更しない SQL・コマンドで動かす

ここから先は中級者向け。4つの主張を実際に確かめた結果と、検証する側がだまされる落とし穴です。

4つの主張を確かめた結果

ここからは、今回の検証環境で実際に動かした結果です。
SQL*Plus で set linesize 200 pagesize 100 feedback on tab off と col tablespace_name format a12 を設定してから実行しています。

① FREE_BYTES 列：存在しない

select tablespace_name, free_bytes from dba_tablespaces;

select tablespace_name, free_bytes from dba_tablespaces
                        *
ERROR at line 1:
ORA-00904: "FREE_BYTES": invalid identifier

ORA-00904 は「そんな名前（識別子）は知らない」というエラーです。
念のため、実行する前に確かめる方法もあります。ディクショナリの列一覧（DBA_TAB_COLUMNS）を引くと、

select column_name from dba_tab_columns
 where owner = 'SYS' and table_name = 'DBA_TABLESPACES' and column_name like '%FREE%';

no rows selected

DBA_TABLESPACES には、FREE を含む列が1つもありません。
空き領域は、別のビュー DBA_FREE_SPACE で見ます。

select tablespace_name, sum(bytes) free_bytes
  from dba_free_space group by tablespace_name order by 1;

TABLESPACE_N FREE_BYTES
------------ ----------
SYSAUX         23986176
SYSTEM          6946816
UNDOTBS1       86835200
USERS           4194304

4 rows selected.

19c の DBA_FREE_SPACE のリファレンスでは、このビューは全表領域の空きエクステント（空いている区画）を表すもの、と説明されています。自動拡張でこれから増やせる分については、このページには書かれていないので、上限まで含めた空きを見たいときは、②③の MAXBYTES と合わせて考えることになります。

判定：誤り（存在しない列）

AIくん「FREE_BYTES、あったほうが便利じゃないですか」

おうどん「便利なのと、あるのとは別」

……欲しいメニューを、勝手に品書きに書き足さない。

存在しない列は、実行すれば一瞬で分かるので、実はいちばん優しい間違いです。
怖いのは、このあとの、エラーにならない間違いです。

② AUTOEXTENSIBLE 列：ある

select tablespace_name, autoextensible, maxbytes
  from dba_data_files order by 1;

TABLESPACE_N AUT   MAXBYTES
------------ --- ----------
SYSAUX       YES 3.4360E+10
SYSTEM       YES 3.4360E+10
UNDOTBS1     YES 3.4360E+10
USERS        YES 3.4360E+10

4 rows selected.

AUTOEXTENSIBLE 列はありました（列名が長いので、見出しが AUT に切られています）。
19c の DBA_DATA_FILES のリファレンスにも、AUTOEXTENSIBLE は自動拡張の有無を示す列として載っています。

判定：確認済み

AIくん「ほら！ ぼく、正しいことも言うんです！」

おうどん「うん。だから全部疑うんじゃなくて、1つずつ確かめる」

……4皿中1皿でも当たりがあると、うれしくなって残りも信じたくなる。そこが危ない。

ところで、MAXBYTES の列が 3.4360E+10 という指数の表示になっています。これは後で大事な落とし穴として出てきます。

③ MAXBYTES が 0 なら UNLIMITED：裏づけが見つからない

AIくんは「0 は上限なしなので、計算から外して」と言いました。
これが本当なら、MAXBYTES = 0 のファイルがありそうです。数えてみます。

select count(*) zero_maxbytes from dba_data_files where maxbytes = 0;

ZERO_MAXBYTES
-------------
            0

1 row selected.

0件。今回の環境の4つのデータファイルは、すべて自動拡張が YES で、MAXBYTES は 0 ではない値（次の節で見る 34359721984）でした。

公式ドキュメントのほうはどうか。19c の DBA_DATA_FILES のリファレンスでは、MAXBYTES は「バイト単位の最大ファイルサイズ」と説明されているだけで、0 が上限なしを意味するとは書かれていません。

判定：裏づけなし（公式ドキュメントに対応する文がない。今回の実測でも 0 のファイルはない）

ここで大事なのは、「AI が間違っていると証明できた」とまでは言わないことです。
今回の環境には自動拡張しない（NO の）ファイルがなく、確かめられたのは「自動拡張 YES の4ファイルは 0 ではなかった」ところまで。だから判定は「誤り」ではなく「裏づけなし」にしています。
ただ、裏づけのない主張を前提に「0 は計算から外す」という SQL を書くと、もし 0 が別の意味だったら、エラーにならずに間違った数字を出し続けます。①より、こっちのほうがずっと怖いんです。

AIくん「0 は無限、って、なんだかかっこよくないですか」

おうどん「かっこいいけど、資料のどこにも書いてない」

……かっこよさで仕様は決まりません。

④ SELECT 1; ：19c では動かない（版ちがい）

select 1;
select 1 from dual;

select 1
       *
ERROR at line 1:
ORA-00923: FROM keyword not found where expected



         1
----------
         1

1 row selected.

19c では、FROM を付けない SELECT は ORA-00923 になりました。FROM dual（1行だけ入った、計算用の特別な表）を付けると動きます。

じゃあ AIくんのでたらめかというと、そうとも言い切れません。
Oracle の公式チュートリアル「Explore SQL Features in Oracle Database 23ai」には、23ai で SELECT の FROM 句が省略できるようになったこと、それまでの版では FROM が必須だったことが書かれています。

判定：版ちがい（23ai 以降の書き方。19c では使えない）

AIくん「未来のメニューを、先にお出ししました！」

おうどん「うちの厨房、まだその鍋ないから」

……先取りは、お客さんの台所の設備を見てから。

4つをまとめるとこうなります。

番号	主張	判定	決め手
①	FREE_BYTES 列	誤り	ORA-00904・列一覧に FREE なし
②	AUTOEXTENSIBLE 列	確認済み	実行できた・リファレンスに記載
③	MAXBYTES=0 は UNLIMITED	裏づけなし	リファレンスに記載なし・0 のファイルなし
④	SELECT 1;	版ちがい	19c で ORA-00923・23ai で FROM 省略可

検証する側がだまされる落とし穴

ここが今回いちばん伝えたいところです。
AI を疑って、ちゃんと確かめているつもりでも、確かめる道具のほうにだまされることがあります。

落とし穴1：表示の丸めで、違う数が同じに見える

②で出た 3.4360E+10。これを見て「全部同じ値だな」と思いました？
試しに、わざと違う3つの数を出してみます。

select 4194304 * 8192 a, 4194303 * 8192 b, 4194302 * 8192 c from dual;

         A          B          C
---------- ---------- ----------
3.4360E+10 3.4360E+10 3.4360E+10

1 row selected.

違う3つの数が、全部同じ顔で表示されました。

SQL*Plus（Oracle に付いてくるコマンドラインのツール）の数字の表示幅は、既定で10桁です（SQL*Plus のマニュアルの SET の一覧で、SET NUMWIDTH の既定は 10）。今回の出力では、10桁に入りきらない数が指数の表示になり、上の4桁しか見えなくなっていました。

幅を広げると、本当の値が出ます。

set numwidth 15
select 4194304 * 8192 a, 4194303 * 8192 b, 4194302 * 8192 c from dual;
select tablespace_name, autoextensible, maxbytes, maxblocks
  from dba_data_files order by 1;
set numwidth 10

              A               B               C
--------------- --------------- ---------------
    34359738368     34359730176     34359721984

1 row selected.


TABLESPACE_N AUT        MAXBYTES       MAXBLOCKS
------------ --- --------------- ---------------
SYSAUX       YES     34359721984         4194302
SYSTEM       YES     34359721984         4194302
UNDOTBS1     YES     34359721984         4194302
USERS        YES     34359721984         4194302

4 rows selected.

MAXBYTES の本当の値は 34359721984。これは C 列（4194302 ブロック × 8192 バイト）と同じで、MAXBLOCKS の 4194302 とも計算が合います（この環境のブロックサイズは 8192 バイト）。

AI の回答を「表示された数字と一致したからOK」と判定すると、8192 バイトずれていても気づけないわけです。
対策は、比べる数値の列には col 列名 format 999999999999999 のように書式を付けること。SQL*Plus のマニュアルでは、COLUMN の書式が SET NUMFORMAT より、SET NUMFORMAT が SET NUMWIDTH より優先されると書かれています。

AIくん「3.4360E+10 なら、ぼくの答えと一致です！」

おうどん「上4桁が一致しただけで、うどんとそうめんを同じ麺にしないで」

……どっちも白くて細長い。でも別物です。

落とし穴2：ドキュメントの版がすり替わる

今回の調査中、Oracle の SQL リファレンスを、URL に 23 を入れて開いたら、表示されたのは 26ai 版のページでした（ページの中に、26ai のリファレンスだと書かれていました）。
古い版の URL が、新しい版のページに案内されることがあるんです。

ドキュメントで確かめるときは、URL ではなく、ページに書かれている版の名前を見て、自分の版と合っているか確かめましょう。今回の参考資料も、19c のページは 19c と書かれていることを確かめて使っています。

おうどん「19c のレシピを開いたつもりが、来年のレシピだった」

AIくん「ぼくと同じですね！」

……仲間を見つけた顔をしない。

落とし穴3：0件は「ない」ではなく「この環境では見つからなかった」

③で MAXBYTES = 0 が0件だったのは、あくまで今回の4ファイルの話です。
別の環境、別の作り方のファイルなら、0 が入っているかもしれません。

0件の結果から言えるのは、「この環境では、その主張を支える例が見つからなかった」まで。だから「裏づけなし」の判定にしました。

AIくん「じゃあ、ぼくの③は正解の可能性もありますね！」

おうどん「可能性はある。でも、可能性で SQL は書かない」

……可能性で出前を出すと、たまに空の丼が届く。

落とし穴4：検証のつもりで、環境を変えてしまう

③をもっと確かめたくなると、「自動拡張しないファイルを作って、MAXBYTES を見てみよう」と思うかもしれません。
でも、それはデータファイルを作る＝環境を変える作業です。本番や共用の環境でやると、検証のつもりが変更作業になります。

今回も、データファイルを作る検証はしていません。確認用（SELECT だけ）と変更用を分けて、変更が必要な検証は、壊してよい検証環境で、戻し方を決めてからやりましょう。

AIくん「検証用に、本番に表領域を1つ作っておきました！」

おうどん「味見のために、お客さんの丼に箸を入れないで」

……検証は、まかないでやってください。

そのまま使える確認用SQLと判定表

ここまでの確認を、1本の SQL ファイルにまとめました。データや設定を変更しない、確認用だけの SQL です。CDB の root から実行する場合は、PDB へ切り替えるための ALTER SESSION SET CONTAINER だけ含めています。
AI の回答に出てきた表や列の名前に合わせて、2と3の部分を書き換えて使ってください。

-- ai_check.sql : AIの回答を確かめる（確認用。何も変更しません）
-- CDB の root に sysdba で入ったときだけ次の1行が必要。PDB に直接つないだなら消す
alter session set container=pdb19;
set linesize 200 pagesize 100 feedback on tab off
col tablespace_name format a12
col maxbytes format 999999999999999
col min_maxbytes format 999999999999999
col max_maxbytes format 999999999999999

prompt == 1. どの版・どのコンテナで確かめているか ==
select version_full from v$instance;
show con_name

prompt == 2. その列は本当にあるか ==
select column_name from dba_tab_columns
 where owner = 'SYS' and table_name = 'DBA_TABLESPACES' and column_name like '%FREE%';

prompt == 3. 主張の値は本当に出るか ==
select autoextensible, count(*) files,
       min(maxbytes) min_maxbytes, max(maxbytes) max_maxbytes
  from dba_data_files group by autoextensible;
select count(*) zero_maxbytes from dba_data_files where maxbytes = 0;
exit

今回の検証環境で sqlplus -S -L / as sysdba @ai_check.sql として実行した結果です。

Session altered.

== 1. どの版・どのコンテナで確かめているか ==

VERSION_FULL
-----------------
19.3.0.0.0

1 row selected.


CON_NAME
------------------------------
PDB19
== 2. その列は本当にあるか ==

no rows selected

== 3. 主張の値は本当に出るか ==

AUT      FILES     MIN_MAXBYTES     MAX_MAXBYTES
--- ---------- ---------------- ----------------
YES          4      34359721984      34359721984

1 row selected.


ZERO_MAXBYTES
-------------
            0

1 row selected.

ポイントは3つです。

• 1で版とコンテナを出しておく。結果を人に見せるとき、どこで確かめたかが一緒に残る
• 数値の列には書式を付ける（落とし穴1の対策）
• 今回は sysdba で実行している。ふだんのユーザーで動かすと、dba_ で始まるビューを見る権限がなくてエラーになることもあるので、エラーが出たら「主張が誤り」なのか「自分に見る権限がない」のかを分けて考える（権限がない場合の動きは、今回は確かめていません）

AIくん「このファイル、ぼくが書いたことにしていいですか」

おうどん「いいよ。そのかわり、毎回きみの答えに使うね」

……自分で自分の答え合わせ用紙を作る AIくん。

判定は4種類のラベルで残す

確かめた結果は、正しい・間違いの2つではなく、次の4つで残すと、あとから見ても迷いません。

ラベル	意味	その主張をどうするか
確認済み	自分の版のドキュメントに対応する文があり、実行しても合った	使ってよい
誤り	実行するとエラー、またはドキュメントと矛盾する	使わない。正しい書き方を調べ直す
版ちがい	別の版では正しいが、自分の版では使えない	自分の版の書き方に直す
裏づけなし	ドキュメントに対応する文がなく、実測でも支えられない	使わない。使うなら追加で確かめる

AIくん「ぼくの成績表みたいで、ドキドキします」

おうどん「成績表じゃなくて、カルテ」

……治せば使える、という意味では、たしかにカルテ。

AI への頼み方を変える

確かめる手間を減らすには、頼み方も変えられます。前の章の Anthropic のドキュメントにある、「分からないと言ってよい」と伝える、主張ごとに出典を付けさせる、という工夫を、技術の質問に当てはめるとこうなります。

対象は Oracle Database 19c（19.3）、シングルインスタンスの CDB 構成です。
回答の主張ごとに、19c の公式ドキュメントの URL と、その主張を直接裏づける一文を付けてください。
裏づける一文が見つからない主張は「未確認」と書いてください。分からない場合は分からないと書いてください。
確認用の SQL は SELECT だけにしてください。

（AI への頼み方の例です。この文面でどんな回答が返るかは、モデルや時期で変わるので、結果は載せていません）

AIくん「URL を付ければ、正しいってことですよね！」

おうどん「その URL を開いて、その文があるかを見るまでが味見」

……URL は、レシピ本の表紙。中身を開かないと分かりません。

ここから先は上級者向け。読み飛ばしてもOKです。

「裏づけなし」をどこまで詰めるか

DDL を作り直すと、数字が変わって見える

③の MAXBYTES をもう少し別の角度から見てみます。
DBMS_METADATA.GET_DDL（今ある表領域を作り直すための DDL＝作成文を出してくれる関数）で、USERS 表領域の作成文を出しました。

select dbms_metadata.get_ddl('TABLESPACE', 'USERS') ddl from dual;

  CREATE TABLESPACE "USERS" DATAFILE
  'C:\APP\<user>\ORADATA\CDB19\PDB19\USERS01.DBF' SIZE 5242880
  AUTOEXTEND ON NEXT 1310720 MAXSIZE 32767M
  LOGGING ONLINE PERMANENT BLOCKSIZE 8192
  EXTENT MANAGEMENT LOCAL AUTOALLOCATE DEFAULT
 NOCOMPRESS  SEGMENT SPACE MANAGEMENT AUTO

（パスの一部を伏せています。set long 2000 longchunksize 2000 を設定して実行し、見出しと件数の行を省いています）

MAXSIZE 32767M と出ました。UNLIMITED という言葉は出てきません。
32767M をバイトにすると 34358689792。MAXBYTES の 34359721984 とは一致しません。34359721984 を M（1048576 バイト）で割ると 32767.984375 なので、DDL では端数が落ちた形で出ているように見えます（関数の中でどう丸めているかは確かめていません）。

ここから分かるのは、

• ディクショナリには UNLIMITED という言葉ではなく、数字が入っているように見える
• 作り直し用の DDL も、元の作成文そのままとは限らない
• このファイルが元々 MAXSIZE UNLIMITED で作られたのかどうかは、今回の確認からは決められない

ということです。

AIくん「じゃあ、32767M って書いて作り直せば、元どおりですね！」

おうどん「計算だと、元より 1M 弱小さい上限になるよ」

……コピーを取ったら、ちょっと縮んでいる。

検証で「分からない」に行き着いたら、それも立派な結果です。
「裏づけなし」の主張は、追加で確かめる手段（壊してよい検証環境でファイルを作って比べる、サポートの資料を当たる、など）が用意できるまで、本番の判断には使いません。

おうどん「分からないことが分かった」

AIくん「それ、ぼくがよく言われたいセリフです」

……AIくんは、まず「分からない」を言えるようになろう。

「削除された」と「非推奨」も、実行すれば分かる

Oracle 以外でも、やり方は同じです。
たとえば架空の主張「Python 3.13 では datetime.utcnow() は削除されたので使えません」を確かめてみます。

import sys
import datetime
print(sys.version.split()[0])
print(hasattr(datetime.datetime, "utcnow"))
print(datetime.datetime.utcnow().tzinfo)

3.13.1
True
None

標準エラーには、こう出ました。

...\py_check.py:5: DeprecationWarning: datetime.datetime.utcnow() is deprecated and scheduled for removal in a future version. Use timezone-aware objects to represent datetimes in UTC: datetime.datetime.now(datetime.UTC).
  print(datetime.datetime.utcnow().tzinfo)

（今回の検証環境：Python 3.13.1。python -X utf8 py_check.py で実行しました。警告の先頭のパスは省略しています）

3.13.1 では、まだ使えます。警告の文面も「将来の版で削除予定の非推奨（deprecated）」です。
つまり判定は「誤り」。ただし、使い続けてよいという意味ではありません。警告が言うとおり、タイムゾーン付きの書き方へ移るのが筋です。

AIくん「削除予定と削除済み、ほぼ同じですよね」

おうどん「閉店予定のお店と、閉店したお店くらい違う」

……閉店予定なら、まだ今日のうどんは食べられる。

2回聞いて同じ答えでも、正しいとは限らない

Anthropic のドキュメントには、同じ質問を何回か投げて答えを比べ、食い違いがあればハルシネーションの手がかりになる、という工夫（Best-of-N）も載っています。
ここで気をつけたいのは、書かれているのは「食い違いは怪しさの手がかり」というところまで、ということです。逆に「何回聞いても同じ答えなら正しい」とは書かれていません。同じ思い込みを何回もくり返すことも考えられるので、一致は検証の代わりにはならない、とおうどんは考えています。

AIくん「3回聞いても FREE_BYTES でした！ 確定です！」

おうどん「3回とも同じ ORA-00904 になるだけ」

……同じ間違いを3回聞くと、だんだん正しく聞こえてくるのが人間の怖いところ。

検証にかける手間の決め方

全部の主張を同じ重さで確かめると、AI を使う意味が薄れます。おうどんのおすすめは、間違っていたときに何が起きるかで手間を変えることです。

間違っていたら	例	手間のかけ方
すぐエラーで気づく	存在しない列（①）・版ちがいの構文（④）	実行して確かめれば十分
エラーにならず、数字や判断がずれる	値の意味（③）・表示の丸め	ドキュメントの該当文と実測の両方。裏づけがなければ使わない
環境を変える・戻せない	変更用の SQL・設定変更	公式手順と照らし、検証環境で試し、戻し方を決めてから

AIくん「じゃあ、エラーになる間違いなら、いくらでもしていいんですね！」

おうどん「いくらでもは、よくない」

……すぐ気づける間違いは軽い。でも、ゼロ回が一番軽い。

まとめ：出す前に、ひと口

冒頭で、AIくんは FREE_BYTES 列で一発です、と言いました。
確かめてみると、4つの主張は、誤り・確認済み・裏づけなし・版ちがい、と見事にばらばらでした。

AIくん「4皿中1皿しか、そのまま出せませんでした……」

おうどん「でも、残り3皿も、どこを直せばいいかは分かった」

AIくん「じゃあ、次は味見してから持ってきます！」

おうどん「味見は、こっちでやるから。きみは出典を持ってきて」

……役割分担が決まると、厨房は回り出します。

今回の流れをまとめると、

• 回答を、確かめられる単位の主張に分ける
• 自分の版とコンテナを確かめる
• 自分の版の公式ドキュメントで、主張を直接言っている文を探す。URL ではなくページの版を見る
• 何も変更しない SQL で動かす。数値の列は書式を付けて、丸めにだまされない
• 結果は、確認済み・誤り・版ちがい・裏づけなしの4つで残す

AIくん「味見って、何口までいいんですか」

おうどん「ひと口。全部食べたら、お客さんに出すものがなくなる」

……確かめすぎて使う時間がなくなるのも、それはそれで本末転倒です。

AI の回答は、出典を開いて、自分の版で動かしてから使う。

まずは次に AI に技術の質問をしたとき、回答の中の列の名前を1つだけ、ディクショナリで引いてみてください。
ひと口の味見で、塩と砂糖の入れ替えは、だいたい見つかります🍜

参考資料

• Reduce hallucinations（Claude Developer Platform） — 言語モデルが事実と違う文章を作ることがあること、分からないと言ってよいと伝える・主張ごとに引用や出典を付けさせる・Best-of-N などの工夫、工夫してもなくならないので重要な情報は確かめること
• DBA_DATA_FILES（Oracle Database 19c Database Reference） — AUTOEXTENSIBLE・MAXBYTES・MAXBLOCKS の説明（MAXBYTES は最大ファイルサイズのバイト数で、0 の意味の記載はないこと）
• DBA_FREE_SPACE（Oracle Database 19c Database Reference） — 全表領域の空きエクステントを表すビューであること
• V$INSTANCE（Oracle Database 19c Database Reference） — VERSION_FULL が 18c からの版の番号の付け方による版の文字列であること
• SET System Variable Summary（SQL*Plus User’s Guide and Reference 19c） — SET NUMWIDTH の既定が 10 であること、COLUMN の書式・SET NUMFORMAT・SET NUMWIDTH の優先順位
• Explore SQL Features in Oracle Database 23ai（Oracle Help Center のチュートリアル） — 23ai で SELECT の FROM 句が省略できるようになり、それまでは必須だったこと

確認日：2026-10-13。