AIは嘘をつく（こともある）─AIに設計を任せたら、AI自身の嘘に4回気づけた話─
1. 前回までのおさらい（読んでない人向け）
前回、コードが書けない40代事務員が、AIとの対話だけで特許出願レベルのシステム 「Prime Source」を作った話を書きました。その過程で生まれた手法を「CGP （Core Growth Prompting）」と名付けたところまでが前回です。
Prime Sourceは現在も出願準備中なので、中身の話は今回できません。 代わりに、今回は別の個人アプリ（3行日記＋ヘルスケア連携アプリ）を CGPで設計している中で起きた話をします。
このアプリを作りながら、私は4回、AIが「嘘」をつくところに立ち会いました。 正確には、嘘というより「もっともらしいが検証されていないもの」を、 気づかないまま先に進めそうになった、という話です。しかも厄介なことに、 その4回のうち何回かは、AI自身も気づいていませんでした。
2. 「AIに設計を任せる」の正体
AIと壁打ちをしていると、驚くほど一貫性のある答えが返ってきます。 矛盾なく、筋道立っていて、読んでいて「なるほど」と思わせる説明が すらすら出てくる。
でも、この「一貫性がある」という感触と、「実際に正しい」ということは、 別物です。これを痛感させられた4つの出来事を、時系列で紹介します。
3. 嘘その1：自分で決めたルールを、自分で破っていた
このアプリには「カウンセラーAI」という、ユーザーと対話する唯一のAIがいます。 その裏側では複数の分析AIが働いていて、その一つが「ユーザーの気持ちの中で、 今日どれを話題にすべきか」を決めるロジックでした。
このロジックは、AIに判断させず、プログラムが機械的に決める設計にしていました。 理由は単純で、AIに「今日はこれを話題にしよう」と自由に選ばせると、 選定基準がブラックボックスになり、暴走のリスクがあるからです。
ところが、しばらく経ってから見返すと、カウンセラーAI自身への指示書に、 「複数の候補から、重要なものを一つ選んでください」という文言が そのまま残っていました。 つまり、時間をかけて設計した「プログラムが 機械的に選ぶ」というルールを、カウンセラーAI側の指示書がまるごと 無視できる状態になっていたのです。
しかもこれは、AIが嘘をついたというより、設計している私たち（人間とAI） 両方が、全体のつじつまを見落としていたという話です。個別のパーツは 正しくても、パーツ同士の受け渡しが正しいかは、また別に確認しないと 分からない。これが1回目の気づきでした。
4. 嘘その2：動詞ひとつで、検知がすり抜ける
このアプリには、「もう〜したくない」のような、かなり追い詰められた 表現を検出する仕組みがあります。文章でその仕組みを説明している分には、 何の問題もないように見えました。
ところが、実際にコードを書いて動かしてみたところ、「もう介護なんて やりたくない」という文章が、検知をすり抜けました。 原因を調べると、 検出の条件式が「したくない」という特定の言い回し（動詞が「する」の 場合）に固定されていて、「やりたくない」のように動詞が変わると 反応しない作りになっていたのです。
これは、文章で議論していた間は誰も気づきませんでした。実際にコードを 実行して、テストデータを流し込んで、初めて発覚したバグです。 もっともらしい 説明と、実際に動くロジックの間には、思っていた以上の距離がある。 これが2回目の気づきでした。
5. 嘘その3：何度読んでも気づけなかった抜け番号
これはAIというより、人間側（私）の話です。設計書の章立てを何度か 組み替えるうちに、「8章」という番号がまるごと抜け落ちて、7章の次が いきなり9章になっていました。
何度も読み返したはずなのに、私もAIも気づきませんでした。理由は単純で、 「読んで確認する」というやり方自体に限界があるからです。人間の目も、 AIの"目"も、文章を読むときは意味の流れを追うことに気を取られて、 機械的な整合性（番号が連番になっているか等）のチェックは、実は かなり疎かになりやすい。
これはgrepで章番号を検索する、という機械的な確認をして初めて 見つかりました。「読む」と「検索する」は、似ているようで全然違う 確認方法だったのです。
6. 嘘その4：私の「検証済み」判定が、実は自分自身を見ていただけだった
これが一番自分でも笑ってしまった話です。
このアプリの設計過程を振り返る「デザインヒストリー」という記録を、 別のAIサービスに作ってもらったことがありました。出てきた記録には、 「これは実際の会話のこの発言が根拠です」という引用が、いくつも 添えられていました。
念のため、その引用が本当に元の会話ログに存在するか、私は自分で 検証用のプログラムを書いて確認しました。結果は「全部、根拠あり」。 一瞬、安心しました。
でも、何かがおかしいと思い、確認方法を見直しました。すると、 その検証プログラムがログ全文を確認範囲にしていたせいで、 「AIが生成した記録そのもの（＝引用文を含む文書）」も、 確認対象に紛れ込んでいたことが分かりました。つまり、 引用文が「元の発言に存在するか」ではなく、「引用文が自分自身の 中に存在するか」を確認していただけだったのです。
確認範囲を「記録が作られる前の、本当の会話部分だけ」に絞り直すと、 結果は一変しました。引用として提示されていた発言は、実際の会話の どこにも存在しませんでした。
AIの生成物を、AIで検証したつもりが、検証方法自体に見落としがあった。 これは、AIの嘘を暴いたつもりが、自分の検証プロセスの甘さを 暴かれた、という話でもあります。
7. 4つに共通していたこと
振り返ると、この4つの「嘘」に共通していたのは、こういうことでした。
文章として読んだときの一貫性は、実際の正しさを保証しない
「もっともらしい」に気づく唯一の方法は、実際に動かしてみることだった
しかもそれは、AIの出力だけでなく、人間が書いた確認手順そのものにも 当てはまる
AIが嘘をつく、という言い方をしましたが、正確には、AIも人間も、 検証していないものを「たぶん大丈夫」で通してしまう瞬間がある、 というだけの話だと思います。AIの方がそれを、もっともらしい文章力で 覆い隠すのが上手い、というだけで。
8. これからどうするか
この経験を踏まえて、以前作った「CGP」という手法に、いくつかプロセス のルールを追加しました。
疑似コードは、書いた瞬間に実際に動かして確認する
複数のファイルに同じ情報を手で書き写さない。一箇所にまとめる
テストケースは資産として蓄積し、変更のたびに全部流し直す
「まだ検証されていない仮説」と「実際に確認できたこと」を、 文章の書きぶりだけに頼らず、はっきり分けて記録する
抽象的に見えるかもしれませんが、どれも上の4つの実例から、 直接生まれたルールです。詳しく知りたい方は、GitHubに置いてある CGPプライマーを覗いてみてください。
9. おわりに
技術や知識の壁が低くなったことで、私のような人間でもシステムを 作れる時代になりました。ただ、壁が低くなった分、「もっともらしいが 検証されていないもの」を、そのまま信じてしまう危険も、同じだけ 身近になったのだと思います。
AIと一緒に何かを作っている人には、この話が少しでも参考になれば 嬉しいです。
次回はまた、Prime Sourceの話に戻る予定です。出願の進捗が ありましたら、そちらでお伝えします。
