はじめに
これはシリーズ3本目の記事です。
AI疲れ、コストの壁、と書いてきましたが、今回は「やけどした話」です。
「それっぽさ」の罠
生成AIのやっかいなところは、間違いを自信満々に答えることです。
ハルシネーション——AIが事実ではないことを、さも正しいかのように出力する現象——は、使い始めた頃から知識としては知っていました。でも「知っている」と「実感する」は別物でした。
ある日、ライブラリの使い方について調べていたとき、AIが返してきたコードをほぼそのままコピーして動かそうとしました。動かない。エラーメッセージを貼り付けて修正してもらう。また動かない。しばらく格闘したあと、公式ドキュメントを開いてみると——そもそもそのメソッドが存在しませんでした。
AIは存在しないメソッドを、実在するかのように説明し、サンプルコードまで書いていたのです。
やけどのパターンはだいたい同じ
その後も似たような経験を何度かしました。振り返ると、やけどのパターンはだいたい決まっています。
①新しい・マイナーな技術を聞いたとき
学習データが少ない領域ほど、AIは「それっぽい嘘」をつきやすいです。最新バージョンの仕様、マイナーなライブラリのAPI、リリースされたばかりのサービスの仕様——こういった情報は特に注意が必要です。
②自分の理解が浅い領域で頼ったとき
知識がある分野なら「あ、これおかしいな」と気づけます。でも不慣れな領域だと、間違った回答を疑えません。「わからないからAIに聞く」という使い方が、実は一番危ういのです。
③急いでいるとき
確認が甘くなります。「とりあえず動かしてみよう」が積み重なって、後で大きく詰まります。
付き合い方を変えたきっかけ
やけどを繰り返すうちに、AIへの向き合い方が変わりました。きっかけは小さなことでしたが、ある日「自分はAIを信頼しすぎている」と気づいた瞬間がありました。
コードレビューで「このメソッド、どこで確認しましたか？」と聞かれたとき、「AIが言ってたので」と答えかけて、口をつぐんだのです。
プロとして、それは通らない。ドキュメントも読まず、動作確認もせず、AIの出力をそのまま信じている——それは思考の放棄だと気づきました。
それ以来、AIとの付き合い方にいくつかのルールを設けています。
- 公式ドキュメントが存在するものは、必ずそちらで裏取りする
- 自分が理解できないコードは、採用しない
- 「本当に？」と一度疑う習慣をつける
当たり前のことに見えますが、AIの「自信満々な語り口」に慣れると、この当たり前が崩れていきます。
AIは「思考の出発点」であって「答え」ではない
今は、AIの出力を「たたき台」として扱うようにしています。
完成品を求めるのではなく、方向性のヒントをもらう。コードを丸ごとコピーするのではなく、ロジックのアイデアを参考にして自分で書く。
そうすると、自分の理解が深まるし、間違いにも気づきやすくなります。何より、「自分が作ったもの」という感覚が戻ってきます。
AIは思考を加速させるツールですが、思考そのものを渡してはいけない。
やけどして初めて、そのことをちゃんと理解できた気がしています。
おわりに
ハルシネーションはなくなりません。AIが進化しても、完全になくなることはないでしょう。
であれば、受け取る側がリテラシーを持つしかありません。「疑う力」「確認する習慣」「自分で理解しようとする姿勢」——生成AI時代に求められるスキルは、意外とアナログなものかもしれません。
この記事は個人の経験と意見に基づいています。