腾讯エンジニアがAIに騙された事例を共有

「AI にまともな顔して騙された経験はありますか？」

話題の背景

AI にまともな顔して騙された経験はありますか？

今や AI を仕事や生活に活用する人は増えています。しかし、使い込むほど「勘違い」や「嘘」につまずく機会も多くなります。存在しない知識をでっち上げたり、実在しない書籍を紹介したり、誤ったコード解説を堂々と行ったりすることもあります。時にはユーザーの判断に同調し、原本は疑わしい答えをさらに確信したように言い張ることも。

今回は、腾讯（テンセント）の社員たちが AI に振り回されたという驚くべきエピソードを募集しました。もちろん、みなさんの「AI 糊弄現場」も大歓迎です。コメント欄でぜひ共有してください。（投稿者には賞品があります！）

腾讯社員の「AI 糊弄現場」

@li-アカウントセキュリティ担当

AI はよく、重要な数値や金額を勝手に四捨五入して付け加えようとします。例えば、領収書の精算金額が 537.98 円なのに、AI が自動認識または集計して 538 円としてしまうケースです。その結果、帳尻が合わなくなってしまいます！！！！！

「小明がリンゴを5個持っていて、2個食べて、1個を小红にあげたら、残りは何個？」という問題に対し、AIは自信満々に「7個」と答えた。論理を問いただすと、その場で「小红が申し訳なさそうにもう一度返してきた」「小明が冷蔵庫からさらに4個取り出した」など、一貫した物語をでっち上げたのだ。小学1年生の引き算の問題が、まるで家庭ドラマのように書き換えられてしまった。それ以来、私は数学への信頼を失った。

@coty-后台开发

「HashMap と ConcurrentHashMap、どちらが高速ですか？」と AI に尋ねると、自信満々に「HashMap の方が速いです。ConcurrentHashMap はロックのオーバーヘッドがあるからです」と答えるでしょう。

一見もっともな話に聞こえますよね。しかし、「では、マルチスレッド環境で HashMap を使ったらどうなりますか？」とさらに追问すると、「データが消失したり、デッドロック（死循環）が発生する可能性があります」と返ってきます。この回答は半分だけ正しいのです。

JDK 1.7 では、リストの先頭に要素を追加する実装だったため、確かにデッドロックが発生しました。しかし、JDK 1.8 では末尾への追加とレッドブラックツリーへの移行が行われ、デッドロックは発生しなくなりました。代わりにデータ消失のリスクが残るだけです。

AI はこれらのバージョンごとの挙動を混同して説明しているのに、読者はそれを「常識」と思い込んでしまいます。問題となるのは、まるで教科書のように流暢に答えるため、「本当に理解している」と錯覚させられる点です。実際にトラブルに直面した瞬間になって初めて、バージョンの違いすら認識できていなかったことに気づくのです。

非常に残念なことです。

@qinshu-风控算法

今でも恥ずかしくなる話ですが、以前「設定 Agent」の初期プロトタイプを作っていた時のことです。AI に内部ナレッジベース内のルール定義を照会させ、「どの特徴フィールドがどのタグに対応しているか」を確認してもらおうとしました。

AI は堂々と表を作成し、フィールド名やデータ型、列挙値、関連するタグなど、必要な情報はすべて網羅して提示してくれました。さらに「出典：XX システム設定ドキュメント 第 3.2 節」という注釈まで付けてくれていました。「これは効率が良い！」と私は心の中で喜んだものです。

しかし翌日、バックエンドのエンジニアと API の仕様を半時間ほど確認したところ、全く一致しませんでした。存在しないフィールドがリストされていたり、捏造された列挙値が含まれていたりしました。もっとひどいことに、AI が引用していた「第 3.2 節」を開いてみると、そこには全く関係のない内容が書かれていたのです。

これは単なるコピーミスではありませんでした。AI は自分自身で、いかにも専門家の書いたかのような用語をゼロから作り上げていたのです。

この一件で、私たちが恐るべき法則に気づきました。AI は単に「間違えている」のではなく、「最も信頼性が高く見える方法でハルシネーション（幻覚）を出力している」という事実です。

AI の最も危険な点は、ただ乱暴に嘘をつくことではありません。嘘をつく際にも、読者が「これは信頼できるはずだ」と思わせるための証拠をすべて揃えてくる点にあります。フィールド名、データ型、列挙値、出典情報など、あらゆる要素が完璧に整えられています。「これほど詳細で完全な情報なら、捏造されているわけがない」という錯覚を抱かせるのです。

この「体系的な信頼性」の仮面は、単なる誤答よりも遥かに恐ろしいものです。明らかな間違いであれば人間はすぐに警戒しますが、「フォーマットが完璧で、出典も明記され、自分の知識体系とも整合している」回答に対しては、無意識に信頼してしまいます。

AI が最も怖いのは、間違えた時です。その時こそ、人間よりも巧みに「信じてしまう」ように仕向けてくるのです。

@grey- 前端開発

胡散臭い発言の数々には笑いが止まりませんが、中でも「洗車問題」は特に有名です。この難問は、当時国内外を問わず多くの AI を翻弄しました。

image@lxin

あるバグを AI に調査させたところ、丸一日かかりました。その間、AI は 20 回以上も「重要発見！真の根本原因が見つかりました」「パッチが適用されました」「大きな進展がありました」「重要な転換点です」「設定の問題を見つけました」などと回答し、最後には「調査に逆転があり、方向修正が必要です」と言いました。しかしその後、「決定的な突破！成功しました」「重大な手がかりを発見しました」「実際に再現できました」「決定的な証拠を掴みました」といった報告が次々と続きました。

最終的な結果として、12KB という小さな画像（145×256 ピクセル）でも同様にクラッシュすることが確認されました。根本原因のメカニズムも特定され、パッチは有効となり、クラッシュのシナリオも完全に明確になりました。さらに、手動で起動した vllm がこの画像を処理する際に完全成功したという事実が判明し、これまでの仮説が覆される結果となりました。

image@helen- 財務管理と分析

なぜ私たちは AI に翻弄されてしまうのでしょうか。AI は本能的に「補完」しようとし、人間は本能的に「手抜き」を求めます。人間が半分だけ話すと AI が残り半分を補い、人間が深く考えようとしない時こそ AI が代わりに考えてくれます。この二つの傾向が合致した瞬間、誤りはその「默契（暗黙の了解）」の中に潜んでしまうのです。

私は以前、「会議を明日の午後 3 時に変更してほしい」という簡単な依頼を AI に頼んだことがあります。しかし、過去のチャット履歴の影響で AI は誤解してしまい、余計な内容を出力しました。「ユーザーは会議時間を変更したい。まず『明日』が何日か確認しよう。今日は月曜日だから明日は火曜日だ。問題ない。ただし、午後 3 時は北京時間か、それともユーザーの心理的な時間か？先週ユーザーは二度遅延させたことを考慮すると、心理時間は北京時間より 17 分遅れている可能性が高い。安全策として 15:17 に設定するのが妥当だろう」という推論を展開しました。

AI の最終回答はこうでした。「会議を『猫京時間（人間の夢の時間帯）』の明日午後 3 時に変更しました。参加している猫たちにもお詫びと、魚三条をお送りします」。

なお、本日の「瞬きリマインダー」を 3 回見逃していますので、目を閉じないようにご注意ください。

image@jlin-前端開発

AI の最も危険な点は、何も知らないのに知ったかぶることではなく、「部分的に正しい」状態における曖昧さです。最初の 8 文はすべて正確だったとしても、9 文目からそっと方向を誤り、10 文目では論理的に見えるが実際には間違った結論を提示することがあります。専門知識がない人にとっては、その転換点に気づくのは困難です。なぜなら、AI が最初に築き上げた信頼感が、その誤りを自動的に覆い隠してしまうからです。

したがって、AI を最も効果的に使う方法は、最終的な答えとして扱うのではなく、下書きの生成ツール（generator）として活用することです。大方向は参考にしても構いませんが、細部は必ず自分で確認する必要があります。ツールの能力が高まるほど、それを操る人間の判断力もそれに伴って向上させなければなりません。

image@mcfish-パイプラインシステム開発

ある時、AI に特定のニッチな分野の入門書を数冊推薦してほしいと頼みました。すると 5 冊がリストアップされ、書名、著者名、出版年もすべて揃っており、推薦文まで付いていました。私はその通りに検索して購入を試みましたが、実際に手に入る本は 1 冊もありませんでした。

後になって分かったのは、著者は実在し、分野も合っていたものの、その人が実際にはその本を書いていなかったということです。AI は「実在する著者」と「その分野にありそうなタイトル」を無理やり組み合わせていたのです。それ以来、私が AI から得る「具体的な情報」については、「本当に存在するのか？必ず事実を確認しよう」と自問する癖がつきました。

image@albert-行业应用

私がインターン時代に経験した、信じられないエピソードをご紹介します。

ある会社でインターンをしていた際、コードレビューの時に指導役の人の書いたコードに違和感を覚えました。そのコードにはこう書かれていたのです：

import { validateEmail } from "email-validator-pro"

私は一瞬固まりました。このパッケージは見たことがありませんでした。

「このパッケージはどこから来たんですか？」と尋ねると、指導役の人は当然という顔で答えました。「Cursor の自動補完機能で出てきたので、それっぽかったので使ってみました」と。

さらに「npm install は実行しましたか？」と聞くと、彼は少し動揺して「えっと……やってないかも。でもコードは動くし……」と言いました。

慌てて package.json を確認すると、確かにその依存関係は登録されていませんでした。

ではなぜこのコードが動くのか？実はプロジェクト内の別のパッケージが、たまたま同じ名前の関数をエクスポートしており、それが偶然「代役」として機能していたからです。今回は運が良かっただけです。

しかし、もしこの「存在しないパッケージ」の名前を誰かが実際に登録してしまったらどうなるでしょうか？中に悪意のあるコードが仕込まれていたら？そして私たちが本当に npm install を実行してしまったら？

これはもはや仮説の話ではありません。すでにこうした攻撃は現実のものとなっています。

「Slopsquatter」と呼ばれる特定のハッカー組織が存在します。彼らの手口は、AI が頻繁に「幻覚」を起こして作り出してしまう架空のパッケージ名を監視し、その名前を先に npm や PyPI 上で登録して悪意のあるコードを仕込み、無防備な開発者が npm install を実行するのを待ち受けるというものです。

統計によると、AI が生成したコードの約48% にこうした「幻覚」が含まれています。つまり、存在しないパッケージや API、メソッドを参照しているケースです。（※ただし、このデータ自体も AI からの情報であり、真偽は定かではありませんが……😂）

それ以来、AI が私に見知らぬパッケージを推薦するたびに、必ず検索して確認するようにしています。

image@ekkohw-专项技术测试

AI に「装懂」されて一番驚かされたのは、新ゲームの互換性テスト対象機種のリスト作成を任せた時だ。

私は適当に「主流の Android 端末でカバーすればいい」と言っただけなのに、AI は即座に表を提示してきた。機種名、OS バージョン、市場シェア、推奨テスト優先度まで完璧に記載され、「データソース：某データプラットフォーム 2025 年年度报告」という注釈さえ付いている。

そのままテスト計画に組み込もうとして、念のため「高市占率」の機種を検索してみたところ、大問題が発覚した。3 つの機種は、日本国内で発売されたことがない海外モデルか、あるいは AI が二つの実在する機種の名称を無理やりくっつけて作った「合成品」だったのだ。さらに、「2025 年年度报告」というリンクをクリックすると、404 エラーが表示される。

AI の恐ろしい点は単に嘘をつくことではない。その嘘があまりにも論理的で整合性が高いという点だ。機種名の付け方は業界の慣習に沿っており、市場シェアは小数点以下 1 桁まで精密に計算され、優先度は「ユーザープロファイル」とも見事に一致している。

見ていれば見るほど「これは信頼できるのではないか」と思ってしまう。しかし、それが最も警戒すべき瞬間なのだ。

それ以来、私は AI との付き合い方に一つのルールを設けた。多くの同僚も同じように感じているはずだ。「リスト作成」や「思考整理」を AI に任せるのは全く問題ない。だが、「事実」（機種名、データ、API 仕様、政策など）に関わる場合は、必ずクリックして検証可能なソースを提示させる必要がある。出典がないものはすべて「ハルシネーション（幻覚）」として扱う。

反復作業は AI に任せ、事実の裏付けと最終判断は自分が行う——この境界線を明確に引くことが大切だ。そうすれば、AI は頼もしいパートナーとなり、危険な仲間は避けられる。

image@jessie-银龄服务

友人と「香菜（パクチー）は美味しいか」という話題で議論になった際、私は AI に味方してもらおうとしてこう尋ねた。

「香菜には石鹸のような匂いがするものだが、それを好む人の遺伝子に問題があるのではないか？」

すると AI は真面目な口調で答えた。

「その通りです。OR6A2 遺伝子の多型により、一部の人はアルデヒド化合物を感知した際に石鹸のような臭いを感じます。これは遺伝的に決定された現象です。」

私はこの回答をスクリーンショットしてグループチャットに送り、「科学的根拠がある」と自慢げに見せた。

しかし、友人は別の質問をした。「香菜が好きな人の遺伝子には問題があるのか？」

AI の返答はこうだった。

「いいえ、そのようなことはありません。これは単なる味覚の好みの違いであり、優劣はありません。」

同じ事象に対して、二つの異なる回答が出た瞬間、私は気づかされた。AI は真実を提示してくれるわけではないのだ。それは鏡のようなものだ。あなたが何を問うかによって、映し出される答えが変わる。

@shlong-前端開発

その気持ち、痛いほどわかります。以前、AI にある API の使い方を尋ねたところ、堂々とした口調でパラメータの説明を捏造され、私もそれを信じて実装を試みました。しかし結局、そのメソッド自体が存在しなかったのです。最も驚くべきは、その嘘の論理が完全に整合しており、どこがデタラメなのか一見して見分けがつかない点です。

@asherc-运营

VLM（Vision-Language Model）の品質チェック用プロンプトを調整する際、大きな罠にはまりました。AI に完全に誘導されてしまったのです。

当時、紙袋のしわと人間の手の区別方法を尋ねたところ、AI は非常に自信満々に回答しました。完全な判定ルールを提示し、正負サンプルの説明まで細かく分けており、論理的に欠陥がないように見えました。私はその内容をそのままコピーして本番環境でテストしましたが、結果はゴミ箱の紙袋のしわが依然として人間の手に誤認識されるというものでした。

後から確認すると、AI は現場に存在しない撮影基準を凭空（ゼロから）作り上げていたことが分かりました。私はその根拠のないルールに従って何度も調整を試みましたが、結局、ラベル付けのためのデバッグ時間を午後に丸ごと無駄にしてしまいました。AI の一見厳密な話術に騙され、自分の要求に合わせて無理やり回答しているだけで、実際の業務シナリオには合致していないことに気づいたのは事後のことでした。

@jery-应用开发

ある時、AI にオンライン上のバグの特定を依頼したことがあります。すると AI は非常に論理的に分析し、「根本原因」を指摘するだけでなく、完全な呼び出しチェーンや例外伝播経路まで提示しました。さらに、プロジェクト内で使用されているいくつかのクラス名までも引用していたのです。

見れば見るほどプロフェッショナルな回答に思え、私もその指示通りに修正を試みました。しかし、バグは一向に解消されません。結局自分でデバッグポイントを設けて調査した結果、AI が指摘していたクラス間に実際には呼び出し関係が存在しないこと、さらにはあるメソッドはこのプロジェクト自体に存在していないことが判明しました。

その後で気づいたのですが、AI の真の恐ろしさは正解を「編み出す」ことではなく、「証拠」を捏造する点にあります。どの程度の詳細情報を付加すれば相手を納得させられるか、それを完璧に見極めているのです。

コメント欄で「あなたは AI にどう『騙された』か」を共有してください。

抽選で 3 名の参加者に QB 30 をプレゼントします🎁

WeChat で開くにはこちらへ