🤥 AIに投稿を書かせたら架空の体験が混ざっていた——2段階で止めるまでと、厳しくしすぎた失敗

AIに投稿を任せはじめてから数か月、最初は「自分が書くより速いし、うまい」と思っていました。Lilyは今、SNSの投稿のほとんどをAIを使った自動パイプラインで生成しています。解雇から半年ほどで月商160万、広告費0円、コードほぼ0行——という状態になれた背景のひとつは、この自動化です。でも、ある日「本当にこの投稿は自分の言葉になっているか」と思い立って、過去の投稿を読み返してみたんです。

そこで見つけたのが、「実際には体験していない出来事が書かれた投稿」でした。架空の出来事が、まるで本当にあったことのように、自然な文体でするっと混ざっていた。文章自体は違和感がないから、読み返さなければ気づかなかったと思います。

これ、気づかずに公開していたら——と思ったとき、背筋が寒くなりました。架空の体験談を語るインフルエンサーになるのは、絶対に嫌でした。これは信頼の問題でもあるし、自分自身への問題でもある、と感じたんです。

この記事は、その発見から「どう止めるか」を3段階で試行錯誤した実話です。プロンプトで念押しする→それでも止まらない→機械チェックを加える→今度は誤検出が出る→チューニングする、という流れで、実際に9月16日の実走で何が起きたかも含めて書いています。SNS投稿をAIに任せている方、任せようとしている方に、少しでも参考になれば嬉しいです。

架空の出来事が「自然な文体で」混ざっていた

最初に気づいた瞬間

ある日、「投稿の質を確認しよう」と思い立って、過去に生成された投稿を10本以上まとめて読み直してみました。1本1本読んでいくと、「これ、Lilyが体験した話じゃないよ……」と首を傾げる投稿に出会いました。

たとえば、「先日カフェで作業していたら〜」という書き出しで始まる投稿があったんですが、その日はカフェに行っていませんでした。あるいは、「友人に相談されて気づいたこと」として書かれているエピソードが、そういう会話をした記憶がまったくない、ということもありました。「昨日クライアントと話していて思ったんですが」という一文が入っていたのに、その時期はクライアントとの打ち合わせが一切なかった。

文章は自然で、読んでも違和感がない。むしろ「Lilyっぽい言い回し」になっていて、一見するとちゃんと個人の声に聞こえる。だからこそ、立ち止まって読み直さなければ気づかなかったと思います。これが一番怖かったことでした。

もっと気持ち悪かったのは、「自分が書いた記憶がある気がしてくる」ことでした。文体が似ているから、読み返すと「あれ、これ実際に経験したかも？」と思いかける瞬間があって、自分の記憶まで書き換えられそうになるような感覚がありました。これは正直、けっこう怖かったです。

なぜAIは架空を書くのか

AIは、与えられたキャラクター設定や過去の投稿例をもとに、「この人が書きそうな文章」を生成します。このとき、「架空の出来事を書いてはいけない」というルールを明示しないと、AIは「それらしいエピソード」を自由に作ってしまいます。

理由は、AIが「実際に起きたこと」と「フィクション」を区別する機能を持っていないからです。AIには記憶がありません。毎回ゼロから、与えられた情報だけをもとに文章を作る。「Lilyが昨日何をしたか」は、プロンプトで教えない限りわからない。だから「共感されそうなエピソード」を想像で補ってしまうんです。

しかも、その補い方がうまい。AIは大量の文章を学習しているから、「リアルに見えるエピソード」を作ることが得意です。「先日カフェで作業していたら」という一文は、何千人もの人が実際に書いてきた文体とリズムで生成される。現実感があるから、引っかからない。

これはAIが「悪意を持って架空を書いている」わけではなくて、「架空かどうかを気にしない」んですね。AIにとっては「それらしい文章を作る」ことが仕事なので、実体験かどうかは関係ない。だから、こちらがルールを設けなければ、自然に架空が混ざります。

よく混ざるパターンを覚えておく

架空のエピソードには、よく使われるパターンがあります。「先日〜があって」「昨日〜という場面で気づいた」「友人に相談されたとき」「クライアントから言われて」「偶然見つけた記事に書いてあった」——こういった書き出しを含む文は要注意です。

場所・人物・時間の具体性が高い一文ほど、架空リスクも上がります。「一般論として言えば」という文は架空でも実体験でもなく、まだマシです。でも「先日〇〇駅近くのカフェで」のような具体性が入ると、実際にそこに行ったかどうかを検証しなければいけない。読者にとってはリアルに見えるけど、そのぶん嘘をついたときの裏切り感も大きくなります。

「実体験だけ書いて」と指示しても止まらなかった

第1段階：プロンプトで封じようとした

最初にやったのは、プロンプトへの追記でした。「投稿に書く出来事・エピソードはすべて、以下に記載した実体験のみにしてください。架空の出来事・想像した会話・一般論のエピソードは使わないでください」という一文を加えたんです。

しばらく様子を見ていたら、明らかな架空は減りました。「先日カフェで作業していたら」のような場所エピソードは出なくなった。「友人に相談された話」という架空の会話も、だいぶ減った。これで解決した、と思っていました。

でも、完全には止まらなかった

問題は、「実体験に見せかけた一般論」でした。「作業が詰まったとき、いったん深呼吸するといい」というような内容は、実体験とも一般論とも取れる。「最近、こういう場面が続いていて気づいたことがある」という書き出しで始まる文章は、架空とも実体験とも判定が難しい。明確に「これは架空」とは言えないグレーゾーンが、じわじわ混ざり続けていました。

プロンプトで「架空禁止」と書いても、AIはそのルールを自分で解釈しながら文章を作ります。「これは実体験っぽいから大丈夫」「これは一般論だから実体験ではないかな」という判断を、AIが独自にやってしまう。その判断がどこかで甘くなる。

1つのプロンプトで完全に制御しようとするのには、限界がありました。修正→また混ざる→修正、を繰り返すうちに「プロンプトだけでは無理かも」と思いはじめました。

プロンプトの書き方で結果がどう変わったか

念のため、試してみたプロンプトのパターンをざっくり紹介します（実際の内容は有料記事に詳しく書いています）。

「架空のエピソードは書かないで」という禁止形は、効果が弱かったです。「以下の実体験リストにある出来事だけを使って」という条件形のほうが、明らかに結果がよかった。AIは「禁止されたことを避けようとする」より「条件を満たそうとする」ほうが得意だからだと思います。

それに加えて、「エピソードを使うときは、必ずリスト番号（例：体験A-3）を文末に記載すること」という出典を書かせるルールを加えたら、架空エピソードがさらに減りました。出典を明記させることで、AIが「記載できない出来事」を使いにくくなるんです。ただし、それでも100%にはならなかった。

AIへの指示は「禁止」よりも「制限と出典の義務付け」のほうが効く——この感覚は、このあとの仕組みを作るときの出発点になっています。

先回りQ&A：「毎回リストを書くのが面倒では？」

「実体験リストを毎回プロンプトに書くの、大変じゃないですか？」とよく聞かれます。最初はそう思っていましたが、実際にやってみると、週に1回まとめて書いて、その週の投稿生成に使い回す形にしたら、そこまで負担ではなかったです。

月曜日に「今週使っていい体験リスト」を5〜8個書く。それを1週間のプロンプトに貼り付けて使う。更新は週1回だけ。慣れると10〜15分で書けるようになりました。

二重ガードに切り替えた——機械チェックを加えた

機械チェックとはどんな仕組みか

プロンプトだけでは不完全だとわかったので、「生成後に別の処理でチェックする」という2段階の仕組みに変えました。AIが文章を生成したあと、別のステップで「架空のエピソードが含まれていないか」を自動判定して、引っかかったものは差し戻す、というフローです。

非エンジニアの方向けに砕いて説明すると——文章の中で「怪しい表現パターン」を探して、あったらアラートを出す処理、と思っていただければ近いです。人間がルールを定めて、機械にチェックさせる。プロンプトでAIに「自分でルールを守れ」とお願いするのと違って、機械チェックは「生成された文章を外から見る」仕組みです。

たとえば、「〜ということがありました」「〜で気づきました」という一文が出てきたとき、その出来事が「事前に渡した実体験リスト」に含まれているかどうかを確認する。含まれていなければ「架空の可能性あり」としてフラグを立てる、というイメージです。

技術的に何をしているか

もう少し具体的に書くと、やっていることはこのような流れです。

生成された投稿文を、文単位または節単位に分割します。エピソード的な表現（「〜があった」「〜のとき」「〜したら」など）を含む文を抽出します。その文の中に出てくるキーワードが、実体験リストのどの項目に対応するかを照合します。対応する項目が見つからない場合、その文に「要確認」フラグを付けます。フラグが付いた文が含まれる投稿は、人間のレビューキューに回します。

照合には、完全一致ではなく意味的な近さ（意味検索）を使うことも検討しましたが、Lilyのパイプラインでは今のところキーワードマッチングの組み合わせで十分な精度が出ています。意味検索は精度は高いですが、設定の手間と誤検出のバランスを考えると、最初はシンプルな方法から始めるのがおすすめです。

どう組み合わせるか

全体のフローとしては、こうなりました。

Step 1：使っていい実体験・エピソードを事前にリストアップして渡す（週1回更新）
Step 2：AIに「このリストの中からだけ使って投稿を生成して、使った体験の番号を文末に記載して」と指示する
Step 3：生成された文を機械チェックに通す（出典が記載されているか、出典が実体験リストと一致しているかを自動確認）
Step 4：チェックを通ったものを人間がレビューして最終OKを出す

このフローに変えてから、明確に怪しい文章は弾けるようになりました。プロンプト1枚のときとは格段に違う。「これで安定した」と思っていたんですが——ここから新しい問題が起きました。

9月16日——厳しくしすぎて誤検出が出た

「昨日の疲れ」が架空と判定された

9月16日に実際にパイプラインを走らせてみたとき、予期しないことが起きました。「昨日の疲れが抜けないまま作業を始めた」という一文が、機械チェックに「架空の可能性あり」と引っかかったんです。

これはLilyが実際にそう感じた日のことを書いた投稿でした。架空ではなかった。でもチェックが「昨日」という言葉を拾って、「実体験リストに"昨日"の具体的な出来事が記録されていない→架空の可能性がある」と判定してしまっていました。

笑えなかったです。チェックを厳しくしたのは正しかったはずなのに、今度は本物が弾かれてしまう。「止めすぎ」という新しい問題が出てきたんです。

同じ日に出た他の誤検出も

9月16日のログを確認すると、同様の誤検出が他にも出ていました。「今日も朝から頭が回らない感じがして」「最近こういう気分が続いている」「今週ずっと集中できていない」——これらがすべて「要確認」フラグを立てられていました。

どれも実際のLilyの体感から出てきた言葉でした。でもチェックの仕組み上、「今日」「最近」「今週」という時間を示す言葉が入った文は、実体験リストとの照合が難しい。リストには「〇〇をした」「〇〇という出来事があった」のような具体的な出来事は書けますが、「最近、なんとなく疲れている」という体感は、書き残すような内容でもない。

チェックのルールが「時間軸の言葉＋エピソード的な表現＝要確認」になっていたので、日常的な体感を書いた文がことごとく引っかかっていたんです。

なぜ「昨日」という言葉が問題になったのか

実体験リストは、「この出来事を使っていい」という許可リストとして機能しています。チェックは「生成された文章の中のエピソードが、このリストにあるかどうか」を確認する仕組みです。

でも、「昨日の疲れ」のような日常的な体感は、わざわざリストに書き残すものではありません。「昨日、〇〇をした」という具体的な出来事はリストに入れられますが、「昨日、なんとなく疲れていた」は記録しにくい。なのに、「昨日」という言葉がある→リストに対応する出来事がない→架空と判定、というロジックが働いてしまっていました。

体感・気分・その日の状態を表す表現は、実体験リストに書ける形ではないことが多い。それを機械的に「架空」と判定するのは、チェックが厳しすぎる状態でした。このとき初めて、「止める」と「誤検出しない」が、もともとトレードオフの関係にあることを実感しました。

精度と感度のトレードオフを整理する

セキュリティの話でよく「偽陽性と偽陰性」という概念が出てきますが、今回の問題は同じ構図です。

偽陰性（見逃し）：架空のエピソードをチェックが通してしまう → 公開前に気づかない最悪ケース
偽陽性（誤検出）：本物の体験をチェックが弾いてしまう → レビュー負担が増え、パイプラインが非効率になる

チェックを厳しくすると偽陽性が増える。チェックをゆるくすると偽陰性が増える。どちらを重視するかは、何を守りたいかによります。Lilyの場合、「架空を公開してしまうこと」が最悪なので、多少の誤検出は許容してレビューに委ねる、という方向が正解でした。でも、誤検出が多すぎるとレビューが大変すぎて続かない。だから、「誤検出を減らすためのチューニング」が必要でした。

第3段階——日付の言葉だけをチェック対象から外した

どこを変えたか

この問題の解決策は、「日付・時間軸を示す言葉をチェックの対象から外す」ことでした。「昨日」「今日」「先週」「最近」「〜のとき」「〜していたら」のような時間表現が含まれる文は、機械チェックをスキップして、人間のレビュー段階に委ねるよう設定を変えました。

具体的には、チェック処理の中で「時間軸キーワードリスト」を定義して、そのリストに含まれる言葉がある文は、照合処理を実行しない（スキップして「人間レビュー候補」に仕分ける）ようにしました。時間軸キーワードリストには「昨日・今日・今週・先週・最近・ここ数日・〜ごろ・〜のとき」などを登録しています。

この変更で、9月16日に出ていた誤検出はほぼ解消されました。代わりに「人間レビュー候補」の数は若干増えましたが、1投稿あたりに確認すべき箇所が明確になったので、レビューにかかる時間はそれほど増えませんでした。

分類の考え方

チェック後の投稿を分類する考え方を整理すると、こうなります。

自動OK：実体験リストに出典が対応しており、時間軸表現のない文のみで構成されている投稿。そのままレビューに回す。

人間レビュー候補（時間軸あり）：「昨日」「最近」などの時間表現を含む文が入っている投稿。時間表現の文だけ目視確認する。確認ポイントは「この感覚・状態は実際のLilyのものか」という1点だけ。

差し戻し候補：実体験リストに出典が対応せず、時間軸表現もない架空エピソード疑いの文が含まれる投稿。生成をやり直す。

この3分類にしてから、レビュー作業の効率が上がりました。「全部自分で読む」から「確認が必要な箇所だけ読む」に変わったので、1投稿のレビューにかかる時間が短くなっています。

機械と人間の役割をもう一度整理した

この3段階の調整で気づいたことがあります。機械チェックにできることと、人間の目でしかできないことを、最初から整理しておくべきだった、ということです。

機械が得意なのは、「特定のパターンに当てはまるかどうか」の判定です。「このリストにあるか/ないか」「この言葉が含まれているか/いないか」のような二択は、機械が速く正確にやれる。

一方、「この表現は本当の体験から出てきたものか、それとも想像か」という判断は、文脈と書き手の状況を知らないと難しい。それは人間のレビューでやるしかない。機械チェックに「文脈を読む力」まで期待しようとしたのが、誤検出の原因でした。

自動化できる部分と、人間の判断に任せる部分を分けて考える——これが3段階かけてたどり着いた、一番大事な設計の考え方でした。

今のパイプラインの状態と、今日できること

今のフローを整理すると

今の仕組みをざっくり整理すると、こういう流れになっています。

準備（週1回、月曜）：使っていい実体験・エピソードをリストアップして、投稿生成用のシートに追加する。体験1件につき1〜2行で書く。「〇〇という出来事（日付・概要・感じたこと）」という形式で書くと、後でAIに渡しやすいです。

生成（自動）：AIに実体験リストを渡して投稿を生成する。このとき「使った体験の番号を文末に記載」のルールも同時に渡す。

チェック（自動）：生成された投稿を機械チェックに通す。時間軸キーワードが含まれる文はスキップして人間レビュー候補に仕分け。出典が対応していない文は差し戻し候補に仕分け。

レビュー（人間、短時間）：人間レビュー候補の文だけ目視確認する。差し戻し候補があれば生成をやり直す。

このフローに変えてから、架空エピソードが公開ラインに乗ることはほぼなくなりました。完全にゼロとは言い切れませんが、少なくとも「気づかずに公開する」という最悪のケースは防げています。

非エンジニアの方に今日できること

「自動化の仕組みはまだ先の話」と思っている方にも、今日から使える考え方があります。

ChatGPTなどに投稿を書かせるとき、最初にこう書いてみてください。

今週起きた出来事：
・（出来事1）
・（出来事2）
・（出来事3）

この中から使って投稿を書いてください。
書いていいのはここに書いたことだけです。
架空のエピソードは使わないでください。
使った出来事の番号を文末に書いてください。

それだけです。ツールを変えなくていいし、コードも書かなくていい。プロンプトの最初に実体験を数行書くだけでできます。「出典を文末に書かせる」というひと手間が、架空を入れにくくする効果があります。

AIへの指示は「禁止」より「条件の絞り込みと出典の義務付け」のほうが効く——これが今回の一番の学びでした。「架空を書くな」ではなく、「この実体験リストの中のことだけ使え、かつ使った番号を書け」というアプローチです。入力を制限して、使用に痕跡を残させることで、出力の架空化を防ぐ。まずはそこから試してみてください。

よく聞かれる質問に答えておくと

Q: リストに書いていない体感（「疲れた」「眠い」など）はどうする？

A: これは体感カテゴリとして別に管理するのがおすすめです。「使っていい体感リスト」を別に作って、「今週感じたこと」として週1回更新する。具体的な出来事と体感を分けて管理すると、チェックのルールも作りやすくなります。

Q: チェックを外注できるか？

A: もしパイプラインではなく手動で運用している場合、レビューを別の人に頼むことは可能です。ただし「この人の実体験リスト」を共有しないとレビューができないので、信頼できる人に限定したほうがいいと思います。Lilyは今のところ自分でレビューしています。

Q: 架空が1本混ざったらどうなる？

A: 正直に言うと、取り消せる範囲であれば速やかに削除して、説明する投稿を出すのが誠実だと思います。架空が混ざったまま放置するより、「チェック漏れがあった、すみません」と言える状態を維持するほうが、長期的な信頼に繋がります。完璧なシステムはないので、「混ざったときどうするか」まで決めておくと安心です。

まとめ——失敗を2回して、やっと設計ができた

失敗したほうが設計が深くなる

プロンプトだけで止まっていたら、「プロンプトで架空を禁止すれば解決する」という浅い理解で終わっていたと思います。機械チェックを加えてみて、それが誤検出を出して、チューニングを強いられたことで、「どの表現が機械的に判定できて、どの表現は人間の目が必要か」という構造的な理解が深まりました。

今回の3段階の調整で、2回の失敗がありました。第1段階のプロンプトだけでは止まらない失敗と、第2段階のチェックが厳しすぎる失敗です。でも、その2回の失敗がなかったら、今のパイプラインは作れていなかったと思っています。

仕組みを作るときは、最初からうまくいくことのほうが少ない、とLilyは思っています。特に「止める」と「誤検出しない」のバランスは、実際に動かしてみないとわからない部分が多い。9月16日のあの誤検出がなければ、日付の言葉を除外するという発想には至らなかった。失敗が設計を深くしてくれる、ということです。

3段階を振り返ってキーポイントを整理する

改めて、今回の試行錯誤で分かったことをまとめます。

プロンプトだけの限界：禁止形は効果が弱い。「許可リストから使え」という条件形にすると効果が高まる。それでも100%は止まらない。

機械チェックの導入効果：明確に架空なエピソードは弾ける。でも「体感・気分・日常的な状態」を表す文は誤検出しやすい。

チューニングの方向：「時間軸の言葉を含む文はスキップして人間レビューに委ねる」と、誤検出が大幅に減る。機械に文脈判断を任せようとしない、というのが設計の原則。

レビューの効率化：全文を読み直すのではなく、「人間レビュー候補」に仕分けされた箇所だけを確認する。チェックが「どこを見ればいいか」を教えてくれる仕組みにすると、レビュー時間が短くなる。

架空の体験談は、長く続けると自分が迷子になる

最後に、これだけ書かせてください。

架空の体験談を語ることは、短期的には読まれるかもしれません。でも、Lilyが怖かったのは「読者に嘘をつく」だけじゃなくて、「自分でも気づかないうちに、投稿の中の自分と本当の自分がずれていく」ことでした。架空のエピソードを積み重ねた「Lily」は、本当のLilyじゃない。それはじわじわと、発信することの意味を失わせていく気がしました。

AIを使うことと、自分の実体験を大切にすることは、矛盾しません。「AIに書かせる」のと「架空を語る」は、別の話です。きちんと仕組みを作れば、AIはちゃんと「本物の体験を、うまい文体で表現するアシスタント」になってくれます。そのためには、「何を使っていいか」を自分でコントロールする必要があって、それがリストと出典の義務付け、そして機械チェックと人間レビューの組み合わせでした。

少し大変でしたが、3段階のチューニングをやって正解でした。同じように悩んでいる方の参考になれば、嬉しいです。

📕 この記事の内容を、実装まで全部まとめた有料記事があります 手順・コード・テンプレをそのまま渡しています AIで「寝てても回る仕組み」をゼロから30日で組む全手順