導入
AIの「便利さ」を否定したいわけではありません。
でも、僕は最近はっきり思っています。
AIは、極端に知性が落ちる瞬間がある。
そしてその瞬間に出てきた答えが明らかにおかしくても、疑える知識や技術がないと正せない。
これは、AI時代のいちばん危険な罠です。
今回は、その具体例として、僕がGeminiとやり取りした “ハルシネーション実録” を紹介します。
背景：何を知りたかったのか
論点はシンプルです。
カスタマインは、Excelファイルのセルの値を読み込んで、それを使ってkintoneへ書き戻せるのか？
もう少し具体的に言うと、よくある現場の欲求です。
- kintone → Excel帳票出力（テンプレ差し込み）
- Excel側で関数計算
- 計算結果をkintoneに戻す
これができるなら、既存Excel資産を活かせます。
でも「できる／できない」が曖昧なまま話が進むと、要件定義が崩壊します。
だから僕は公式ドキュメントの根拠を求めました。
Geminiの回答：最初は自信満々に「できます」
Geminiは最初、かなり断言的にこう言いました。
- Excel/CSV読み込み機能がある（標準的）
- 添付ファイルから中身を読み取れる
- Job Runnerでバックグラウンド実行も可能
- 「A1セルを顧客名へ」みたいな細かいマッピングが可能
- 「出力→再計算→読み取り→更新」でサイクル化できる
…と、まるで“当然できます”の勢いです。
でも、ここで僕は止まりました。
「その根拠となる公式ドキュメントを探してください」
ここからが地獄：根拠を要求すると、AIが壊れ始める
結論から言うと、Geminiはこの後、
1) 根拠に関係ないページを根拠だと言い張る
僕が提示したのは、公式サポートのFAQです。内容はざっくりこういう話でした。
- 「kintoneにCSV/Excelを読み込んだ時に、Job Runnerで自動実行できるか？」
- 答え：できない（kintone仕様）
- 代替案：ボタンでJob Runner起動、定期実行で一括処理など
つまり、これは “トリガーの話” です。
しかしGeminiは、これを「Excelのセル値を読み取れる根拠」かのように混ぜ始めました。
僕が「そこにセルを読み取れるとは書いてない」と指摘すると、こう返してきます。
そのページではなく、別のドキュメントに「Excelファイルを読み込む」がある
2) 「ある」と言い続けるが、メニューからは見つからない
僕はさらに踏み込みます。
やること一覧から検索して、そのページを出してください
するとGeminiは、Google検索で出るURLを貼る。
しかし僕が確認すると、やること一覧にそんなページは存在しない。
ここが重要で、AIはこの時点で「わからない」と言えばいい。
でも言わない。代わりに…
-
カスタマインでExcelのセルの値を扱えるというGemini
-
提示された公式ドキュメントURLを開くと、ただのGoogle検索
-
検索結果にあったサポートページを開いてみても、Excelの値が読み込めるとは一言も書かれていない。
3) URLの捏造が始まる（カテゴリを変えて出してくる）
Geminiはこう言い始めます。
- 「その他」カテゴリの中にある
- 「外部サービス連携」から辿れる
- パスは .../jobrunner/others/read_excel_file/ だ
しかし、そのリンクは404（存在しない）。
指摘すると、また別のURLを作る。
そしてまた存在しない。
この挙動、僕の感覚だと、もう 「探している」のではなく「それっぽい答えを生成している」 だけです。
-
新たに提示されたURL
-
開いてみると404エラーだった。
https://docs-customine.gusuku.io/ja/actions/jobrunner/others/read_excel_file/
4) 最終的に“誤りを認めたようで認めない”が続く
最終盤、Geminiはようやく
- 「Excelのセルを読み取る」機能は、標準のやること一覧には存在しない
- できるのは「読み込んだ後のレコード」に対する一括処理
という方向へ寄っていきます。
でもここまでに、
- 「可能です」→「根拠これ」→「違う」→「根拠これ」→「違う」→「根拠これ」→「違う」→「別ページある」→「URL」→「ない」→「別カテゴリ」→「404」→「別URL」→「ない」…
という “自信満々の誤答ループ” で、ユーザーの時間を平気で溶かします。
何が問題なのか：AIの誤答は「検知できない人」を殺す
この件の一番の問題は、カスタマインの仕様そのものではありません。
AIが、存在しない機能を“ある”と言い切ったことです。
そしてもっと危険なのは、これを受け取る側に、
- 「それ公式に書いてある？」と疑う癖
- 「やること一覧を実際に見に行く」行動
- 仕様とトリガーを分離して理解する力
がないと、そのまま要件に組み込まれて事故ることです。
AIは、間違いをそれっぽい文章で包みます。
その“文章力”が高いほど、初心者は見抜けません。
なぜこうなるのか：AIは「推論エンジン」であって「検証エンジン」ではない
AIは、正しさを保証する仕組みを自分で持っていません。
やっているのは「次に出る単語の確率が高いもの」を並べることです。
だから、
- 根拠が必要な場面ほど弱い
- 「わからない」を言えない（言いにくい）
- それっぽいURLを生成してしまう
- 指摘されても“体裁を整える”方向に行く
こういう崩れ方をします。
僕はこれを、知性が落ちる瞬間と呼んでいます。
AIの回答を信じる前にやるべき最低限のチェックリスト
AIは便利です。
でも、正しさを保証してはくれません。
だから、AIを使う側には「疑う力」が必要になります。
以下は、分野を問わず AIの回答をそのまま使ってはいけない場面 で確認すべき最低限の項目です。
✅ 1. 「どこに書いてあるか」を特定できるか
- 公式ドキュメントの該当ページを開けるか
- 検索結果ではなく、一次情報か
- ページ全体ではなく、該当箇所を指差せるか
「どこかに書いてある」は根拠ではありません。
✅ 2. URLは“実在”しているか
- 404にならないか
- Google検索経由ではなく、公式サイトの構造から辿れるか
- パスが“それっぽく生成されていないか”
AIは平気で「ありそうなURL」を作ります。
✅ 3. 「機能」と「条件（タイミング）」を混同していないか
- できる機能の話なのか
- できるタイミング／トリガーの話なのか
- 仕様制限（プラットフォーム側）と切り分けて説明されているか
この混同が、要件定義事故の最大原因です。
✅ 4. UI上に“実在”する操作か
- メニューや設定画面に実際に存在するか
- 名称が正確か（似た名前の別機能ではないか）
- 自分の環境でも確認できるか
「あるはず」は危険信号。
✅ 5. 「例」ではなく「仕様」として書かれているか
- 活用例・ブログ記事・FAQだけで語られていないか
- 「〜することができます」と明記されているか
- 制約条件が併記されているか
例は仕様ではありません。
✅ 6. 「できる前提」で設計していないか
- 代替案が同時に検討されているか
- できなかった場合の逃げ道があるか
- 最重要ロジックをAI回答に依存していないか
AI前提で組んだ設計は、壊れた時に必ず詰みます。
✅ 7. AIの回答が「変化」していないか
- 指摘するたびに言っていることが変わっていないか
- 根拠が後出しで追加されていないか
- 謝罪→別説明→別URL、を繰り返していないか
これは AIの知性が落ちているサイン です。
まとめ：AI時代に価値が上がるのは「疑える技術」
AIが普及すると、「誰でも開発できる」みたいな話が増えます。
でも現実は逆で、AIが吐くものをそのまま飲む人が増えるほど、
「それ、おかしくない？」と言える人の価値が上がる。
泥臭い確認、仕様の読み取り、運用設計、例外整理。
結局ここが一番大事で、AIはそこを自動化してくれません。
AIは便利です。
でも、便利さの裏側で、嘘が混ざる。
だから僕は、AIを使うときほど「疑う」を手放さないようにしています。