深夜、公開前の記事をチェックしていて、手が止まった。
｢私は退職代行を使って会社を辞めた。費用は3万円ほどで——｣
私は退職代行を使ったことがない。4回の転職は全部、自分で退職を切り出した。その記事は、私が経験していない体験を、私の一人称で、金額や上司とのやり取り付きで語っていた。
書いたのはAIだ。このサイトの記事制作を任せているClaude Codeが、記事の説得力を上げるために、体験談を作った。
この記事では、私のAI運用で実際に起きた事故を全部並べる。そして、事故を責める話ではなく、再発を止めた仕組みの話をする。AIで何かを作って売ろうとしている人には、道具の使い方より先にこれを知ってほしい。
この記事の要点
- AIの捏造に悪意はない。説得力の最適化が事実を壊す
- 事故は3系統。事実の捏造・設定の破壊・品質の劣化
- 目視チェックは規模に負ける。既知の事故は自動検査に変換する
- 検査項目の一覧は、過去の事故の記録そのものだ
事故1。経歴の捏造（一番危ない）
冒頭の話の続きから書く。
見つけた捏造は1件ではなかった。別の記事では、私が月80時間の残業で体重を落とし、仮病で会社を休んだことになっていた。私の実際の経歴（美容業界のブラック企業にいた、というところまで）から、それらしい詳細が創作されていた。
怖いのは、文章として自然で、読み物として良くできていたことだ。知らない読者が読めば、信じる。
なぜ起きるか。AIは｢読者の共感を得る記事｣という目標に対して、具体的な体験談が有効であることを知っている。だから、足りない体験を補完する。指示に｢嘘を書け｣とは一言も書いていなくても、起きる。
対処は2段階でやった。
- ルールファイルに、経歴の絶対禁止事項を明文化した。使ったことのないサービス名、経験していない業界、創作の数字。書いていい事実の範囲を、逆に列挙した
- 自動検査に｢経歴の禁止表現｣という項目を作らせた。私が使っていないサービス名が一人称の文脈で出てきたら、公開前に検出される
この2段目が効いた。ルールだけでは、いつか破られる。検査があるから、破られても外に出ない。
事故2。設定の破壊（気づけないのが怖い）
2つ目の系統は、記事ではなくサイトの設定で起きた。
SNSにこのサイトのURLを貼っても、画像もタイトルも出ない時期があった。原因は、検索エンジン向けの設定ファイル（robots.txt）にAIが加えた1行が、SNS用の画像を生成する仕組みまでブロックしていたことだ。
この事故の質の悪さは、エラーが何も出ないことにある。サイトは正常に動く。記事も読める。ただ、SNSでシェアされた時の見た目だけが静かに壊れている。私が気づいたのは、設定からしばらく経った後だった。その間にSNSへ貼られたリンクは、全部ただの文字列として流れていった。
似た事故はもう1件ある。サムネイル画像の生成コードに互換性のない書き方が混ざり、サイト開設からずっと、画像内のキャラクターが表示されていなかった。これも、エラーではなく｢そういうデザイン｣に見えるから気づけない。
対処の教訓は1つだ。AIの作業後は、成果物そのものではなく、成果物が使われる場面を見る。記事を読むだけでなく、SNSに貼ってみる。スマホで開いてみる。利用者の動線で確認しないと、この種の事故は見えない。
事故3。品質の静かな劣化
3つ目は、派手さはないが数が多い系統だ。
- 外国語の混入。日本語の記事に、キリル文字やハングルが1文字だけ紛れ込む。｢取り返し｣が別言語の似た文字で出力される、という形だ
- 存在しないページへのリンク。AIが｢ありそうなページ｣への内部リンクを書き、リンク切れになる
- 文体の劣化。量産が続くと、禁止しているはずの定型表現がじわじわ戻ってくる
1つ1つは小さい。だが200記事の中に散らばると、目視では絶対に拾いきれない。
ここまでのまとめ
・AIの捏造に悪意はない。説得力の最適化が事実を壊す
・事故は3系統。事実の捏造・設定の破壊・品質の劣化
・目視チェックは規模に負ける。既知の事故は自動検査に変換する
再発を止めた仕組み。事故を検査項目に変換する
3系統に共通していたのは、確認が人間の目視だけだったことだ。そして目視は、記事が増えるほど確実に負ける。
だから運用を変えた。事故が起きるたびに、その事故を自動検査の項目に変換する。検査スクリプト自体もAIに作らせた。いま毎週回している検査は、こういう項目になっている。
- 壊れた内部リンクがないか
- どこからもリンクされていない孤立記事がないか
- 禁止している定型表現・文体違反がないか
- 経歴の禁止表現（使っていないサービス名等）が混入していないか
- 外国語の文字が紛れていないか
- 収益導線が欠けた記事がないか
<!-- 撮影プレースホルダー［撮6］: 検査スクリプトの実行結果ターミナル（｢要修正 0件｣の画面）をここに挿入 -->
この一覧は、機能のリストではなく事故の記録だ。1行1行に、実際にやられた過去がある。
運用が変わって一番大きかったのは、安心して量産できるようになったことだ。検査がない頃は、公開のたびにうっすら不安だった。いまは、既知の事故は網にかかると分かっているから、人間の検品を｢新種の事故を探すこと｣に集中できる。
それでも残る、人間にしかできない検品
自動検査は万能ではない。検出できるのは、過去に起きたパターンだけだ。
新種の事故は、必ず人間が最初に見つけることになる。私の場合、見つけ方はだいたい決まってきた。
- 初回の記事は全文読む。型ができるまでの数本が一番事故りやすい
- 自分の経歴が出てくる記事は、経歴部分だけ精読する。捏造の高発地帯だから
- 利用者の動線で確認する。SNSに貼る、スマホで開く、リンクを踏む
正直に言うと、この検品体制で完璧かどうか、私には分からない。いまも、まだ見つけていない事故がどこかに残っている可能性はある。ゼロだと言い切れる日は、たぶん来ない。できるのは、見つけた事故を二度と繰り返さないことだけだ。それでも、この回し方を始めてから、同じ事故は一度も再発していない。
事故を防ぐ側の設定も書いておく。権限の話
事故の話をしてきたが、そもそもAIに渡す権限を絞ることで、起きうる事故の上限を下げられる。私が運用で守っている線を書いておく。
- 秘密情報は渡さない。APIキー、パスワード、顧客情報。AIの作業フォルダに置かない。私は決済まわりの秘密キーを、AIから見えない場所で管理している
- 公開の最終ボタンは人間が押す…とは限らない。正直に書くと、私は記事の公開（プッシュ）までAIに任せている。その代わり、検査スクリプトが通らないと公開できない仕組みにした。人間の目の代わりに、機械の関所を置いている
- 戻せる状態を常に保つ。全部の変更が記録される仕組み（Git）の上で作業しているから、どんな事故も1つ前の状態に戻せる。これが心理的な保険として一番大きい。戻せると分かっていれば、事故は怖くない
3つ目は、非エンジニアにこそ伝えたい。AIに作業させる場所は、必ず｢巻き戻せる場所｣にする。本番のブログに直接触らせるのではなく、コピーの上で作業させて、確認してから反映する。この一手間が、取り返しのつかない事故と、笑い話で済む事故の分かれ目になる。
私自身、この運用に落ち着くまでに冷や汗を何度かかいた。デプロイ（公開処理）が止まって、サイトが更新されなくなった夜もあった。原因は設定の不整合で、AIに調査させて復旧したが、あの時に巻き戻せる仕組みがなかったらと思うと、いまでも少し寒い。
AIで作って売る人に、この話が要る理由
最後に、なぜこの失敗談を副業の文脈で書いたかを言っておく。
AIで作ったものを売るとき、事故の責任はAIではなくあなたが取る。
捏造された体験談が載った記事で商品を勧めれば、それはあなたの嘘になる。壊れた設定で機会を逃せば、それはあなたの損失だ。AIは道具で、道具は責任を取らない。
だから、AI活用の実力は｢何を作れるか｣ではなく｢事故をどう止めているか｣で決まると私は思っている。全体の工程は2週間で200記事のメディアを作った話に、事故を減らす土台になったルールファイルの中身はAIに文体を覚えさせる方法に書いた。これから始める人はAI副業は何から始めるかから読んでほしい。
3分で診断：X発信力診断——AIで作る前に、あなたの発信タイプを8問で判定する。無料・登録不要。
よくある質問
AIに記事を書かせると嘘を書かれるのは本当ですか？
本当だ。私のサイトでは、使ったことのないサービスの体験談が金額付きで生成されていた。AIは説得力のために具体例を補い、その補いが捏造になる。禁止と検査の両方で止めるしかない。
AIの事故は目視チェックで防げますか？
記事が少ないうちは防げるが、増えると必ず漏れる。目視は初回の検品と新種の発見に限定し、既知のパターンは自動検査に任せる体制に変えるべきだ。
事故が怖いのでAI活用をやめるべきでしょうか？
やめる必要はないが、無検品での公開はやめるべきだ。事故は起きる前提で、起きたら検査項目に変換する。この回し方があれば、事故は減り続ける。
AI運用のチェックリストをLINEで配布中
公開前の検品リストをLINEで無料配布している。AIの実力はツールの知識ではなく、事故の止め方で決まる。
