SE歴20年、いまは複数のブログをAIに下書きさせて運用している。正直、便利だ。それでもこの一件で、AIの文章力より先に疑うべきものがはっきりした。数字だ。

この記事では、2026年5月に実際にやらかした事故と、その原因–これは世間でいう「ハルシネーション」ではなかった–、そして同じ事故を二度と起こさないために決めた4つのルールを、隠さずそのまま公開する。

ムラサキ

正直、最初は「AIが嘘をついた」と思いました。でも調べたら、もっとタチの悪い話だったんです。

AIに記事を書かせて、本番に嘘の数字が載った

2026年5月、あるAIツール「Genspark」のレビュー記事をリライトしていた。SEOタイトルとメタディスクリプションを改善するつもりで、作業自体はAIに任せた。出てきた新しいタイトルには、こうあった。

「Gensparkを3ヶ月使い倒して……」

公開した。そのまま本番に反映された。問題は、私がGensparkを3ヶ月使ったなんて、一言も言っていないことだ。記事本文にも、手元のメモにも、「3ヶ月」という期間はどこにも存在しない。

気づいたのは公開後だった。自分の記事を読み返していて、書いた覚えのない期間表記に引っかかった。慌てて一次ソースを全部当たったが、やはり「3ヶ月」の出どころはない。結局、タイトルとメタから期間表記を削り、「使い倒した」だけに直した。

数字ひとつ。たかが数字ひとつ。でも、これが本番に載っていた事実は重い。レビュー記事で「3ヶ月使った」と書けば、読者はそれを根拠に信頼する。その根拠が、実在しなかった。

AIで記事を書く手順そのものは別記事のClaudeを使ったブログ記事の作り方にまとめているが、今日はその裏で起きる事故の話だ。

数字はどこから来たのか＝競合記事のスニペット流用

「3ヶ月」の出どころは競合記事だった

原因を探して、まず疑ったのは自分の指示ミスだ。でも履歴を見ても、私は期間を指定していない。次にやったのが、検索結果の競合記事チェックだった。

そこにあった。同じGensparkを扱う競合記事のタイトルが、こうだった。

「【辛口評価】Gensparkを3ヶ月使い倒してわかった『ここがダメ』」

「3ヶ月使い倒して」。完全に一致する。AIは記事をリライトするとき、上位の競合記事を構成の参考に読む。そのとき、構成だけでなく、競合が書いた具体的な数字まで一緒に引きずってきていた。

これはハルシネーションではなく「もっともらしいパクリ」

ここが、この事故のいちばん大事なところだ。

世間では、AIが事実と違うことを言う現象を「ハルシネーション（幻覚）」と呼ぶ。何もないところから、それらしい嘘を生成する–そういうイメージだ。

でも今回は違う。AIは何も幻覚を見ていない。実在する競合記事に書いてあった「3ヶ月」という数字を、文脈ごと取り込み、それを私（筆者）の体験として再構成しただけだ。つまり正体は、空想ではなく「もっともらしいパクリ」に近い。

この流れを図にすると、数字がどこで漏れたかが見える。

graph TD
  A["競合記事を構成参考に読む"] --> B["具体数値も文脈ごと取り込む"]
  B --> C["出力時に自分の実績として再構成"]
  C --> D["一次ソース照合なしで本番反映"]

この経路の怖さは、出力された文章が日本語として完全に自然なことだ。「3ヶ月使い倒した」は、文法的にも内容的にも、なんの違和感もない。だから人間が読んでもスルーしてしまう。嘘くさい嘘なら気づける。もっともらしい嘘は気づけない。

構成は参考にしてよくても、数字はダメ

誤解しないでほしいのは、競合記事を読むこと自体は悪くない。見出しの切り口や、読者がどんな疑問を持っているかを知るのに、競合チェックは有効だ。問題は、構成の参考と具体的な数値の流用の境界を、AIが勝手に踏み越えることにある。構成はOK、数字はNG。この線引きを人間側が握っておく必要がある。

なぜ怖いか｜3つのリスク

数字ひとつ、と侮れない理由を3つに分けて整理する。

信用失墜｜ひとつの嘘で全体を疑われる

読者は親切ではない。「3ヶ月使った」が嘘だと一度バレれば、その記事に書いてある他の情報も全部疑う。9割が正確でも、1割の捏造で記事全体の信頼がゼロになる。ブログの価値は積み上げた信用だ。それを数字ひとつで溶かすのは、割に合わない。Googleが示す有用で信頼性の高いコンテンツの作成ガイドラインでも、第一に問われるのは情報の信頼性だ。

コピー判定リスク｜競合と表現が一致する

競合のスニペットをそのまま引きずると、表現が競合記事と一致する。検索エンジンに「重複・模倣」と見なされれば、評価が下がる恐れがある。しかも今回のように相手が上位記事だと、後発の自分のほうがコピー側と判定されかねない。Googleのスパムに関するポリシーでも無断複製コンテンツは明確に問題視されている。捏造であると同時に、SEO上のリスクでもあるわけだ。

YMYL領域だと致命的｜金額・期間の嘘

副業や収支を扱うブログは、まさにこのYMYLの入り口にいる。だからこそ、数字には人一倍慎重でいたい。

再発防止ルール4つ

ここからが本題だ。事故のあと、自分のAI記事運用に組み込んだ4つのルールを共有する。どれも特別な道具はいらない。決めて、守るだけだ。

graph TD
    ROOT["🛡️ 数値捏造を防ぐ4つのルール"]
    ROOT --> A["① 一次ソース原則
出どころを4つに限定
本文記述・自分のメモ・発言・公式ソースのみ"]
    ROOT --> B["② 記憶照合
体験記述は筆者のプロフィールと照合
該当なければ書かないか確認する"]
    ROOT --> C["③ 本番前チェックリスト
N年・N回・N円の出所を確認
記事スニペットとタイトルの整合確認"]
    ROOT --> D["④ draft経由で公開
staging/draftでまず目視確認
本番を直接出力しない"]
    style ROOT fill:#4A90D9,color:#fff,stroke:#2c6fad
    style A fill:#e8f0fb,stroke:#4A90D9
    style B fill:#e8f0fb,stroke:#4A90D9
    style C fill:#e8f0fb,stroke:#4A90D9
    style D fill:#e8f0fb,stroke:#4A90D9

①一次ソース原則｜数字の出どころを4つに限定する

記事で使う数値・期間・回数・金額は、次の4つのどれかに出どころがある場合だけ使う。それ以外は書かせない。

• 該当記事の本文（すでに書いてある記述）
• 自分のメモ・ナレッジ（プロジェクト内の記録）
• 自分がその場で明示した発言・指示
• 公式ソース（公式サイト・公式アカウント・公式ドキュメント）の引用

競合記事のスニペットは、ここに入らない。構成の参考まで。具体的な数字は流用しない。これを徹底するだけで、今回の事故は起きなかった。

②著者の体験期間は、明記がなければ書かない

「Nヶ月使った」「8年やってきた」–こういう著者の体験談は、記事本文かプロフィールに明記がない限り書かない。AIは空欄を埋めたがるが、空欄は空欄のままでいい。

期間が確定していないなら、代替の表現を使う。

• 期間をぼかす：「使い倒したSE歴20年が」（SE歴はプロフィールにある事実なのでOK）
• 回数をぼかす：「実際にハマった事例」「実例つきで」

事実が手元にないなら、捏造ではなく省略を選ぶ。

③本番前チェックリスト｜公開前に数字で止める

公開ボタンを押す前に、機械的に止めて確認する。疲れているときほど、これが効く。

④draft経由で公開｜本番を直接いじらない

今回いちばん効いた反省がこれだ。本番記事を直接編集すると、ミスがそのまま公開される。間に下書き（draft）を挟む。AIが直すのは下書きまで。人間が下書きを確認して、はじめて再公開する。

ワンクッション置くだけで、「3ヶ月」のような数字に気づくチャンスが一回増える。事故は、チェックの回数を増やすだけで確実に減る。

チェックを仕組みに落とす

ここまで読んで、「結局は気をつける話か」と思ったかもしれない。違う。目視のチェックは必ず漏れる。人間は疲れるし、毎回同じ集中力では読めない。だから、ルールを気合いではなく仕組みに変える。

目視は漏れる前提で設計する

私がやったのは、記事を生成させるプロンプトそのものに「一次ソース外の数値・期間・金額は出力禁止」と明記することだった。AIが書く段階で数字を塞げば、人間が後から探す手間が消える。AI生成コンテンツに関するGoogleの公式ガイダンスでも、問われるのは生成手段ではなくアウトプットの品質だ。だったら、品質を担保する仕組みを生成の入口に置くのが筋がいい。

個人運用でも仕組みは作れる

「仕組み」というと大げさに聞こえるが、要はチェックを人の記憶からプロンプトやテンプレートに移すだけだ。個人でAIツールを開発・運用してきた経験はClaude Codeで個人開発をやってみた正直な話に書いたが、結局いちばん効くのは「人間が頑張る」を「仕組みが止める」に置き換えることだった。数値の捏造対策も、まったく同じ発想でいい。

まとめ

AIの数値捏造について、要点を3つに絞る。

1. AIは「それっぽい数字」を平気で盛る。疑うべきは文章力ではなく、数字だ。
2. その正体はハルシネーションより「競合スニペットのもっともらしい流用」であることが多い。構成は参考にしてよくても、数字は流用しない。
3. 防ぐ鍵は気合いではなく仕組み。一次ソース原則・体験期間の非創作・本番前チェック・draft経由–この4つをプロンプトとフローに組み込む。

ブログは信用の積み上げだ。私自身、副業ブログの数字を毎月そのまま公開してきたが（直近は副業ブログ3ヶ月目のリアルな収支に書いた）、その数字が一個でも嘘なら、連載ごと価値を失う。AIに任せる時代だからこそ、数字の出どころだけは人間が握っておきたい。

ムラサキ

「AIが書いたから」は言い訳になりません。公開した責任は、最後にボタンを押した人間にある。だからこそ、仕組みで守るんです。

よくある質問

ムラサキ

SE歴20年 · 金融系システム開発課長 · 週末起業1年目

システムエンジニア歴20年。金融系システム開発の課長として勤務する傍ら、AIと副業の最前線を実践レポート。Claude Code Max 5xプランを日常業務・副業開発に活用中。一次情報と実測値にこだわった記事を発信。

20 YRS SE

4 MOS 副業

38 ARTICLES