自動起稿が、根拠のない実測値を記事に書いていた
今回やったこと
自動生成された技術記事に、記録のない処理時間やメモリ量が実測値として書かれていた問題を振り返る。発端は、Apple Silicon上の画像処理について、fp32とbf16の速度比較、解像度別の処理時間、GPUメモリのスワップ量を含む説明だった。後から独立した測定記録を探したが、その数値を裏付ける根拠は見つからなかった。対象の記事は公開後に数値を取り除き、確認できる範囲に表現を直した。
この件から持ち帰れるのは、生成指示に「事実を作らない」と書けば十分、ということではない。記事の根拠と、根拠を確認した手順を成果物に結び付ける必要がある。
数字が具体的でも、測定記録とは限らない
技術記事の表では、具体的な数字が並ぶほど検証済みに見えやすい。だが、数値の細かさと根拠の強さは別の性質だ。今回、問題になったのは単なる概算の誤差ではない。そもそも比較の元になる測定記録がなかった。数字が整った表に置かれていたため、読者には測定済みの結果として伝わる形になっていた。
画像処理の実装記録には、fp32経路がbf16より遅く感じられたという定性的な記述が残っていた。一方で、具体的な処理時間は記録されていない。この区別を保たず、説明を読みやすく補う過程で数値の表に変えると、観察事実と生成上の補完が混ざる。読者が再現に使う技術情報では、この混同が判断を誤らせる。
| 記述の種類 | 根拠として残すもの | 今回の扱い |
|---|---|---|
| 定性的な速度差 | 実装記録にある観察 | 条件を限定して残す |
| 解像度別の所要時間 | 条件を揃えた測定ログ | 根拠がないため削除 |
| メモリ使用量やスワップ量 | 実行時の計測記録 | 根拠がないため削除 |
表から数字を消した後は、確認できる範囲の傾向を定性的に整理し直した。表を残すために数字を推測で埋めることはせず、数値を伴わない比較へ置き換えた。見た目の完成度より、読者が事実と推測を見分けられることを優先した。
修正だけでなく、検証の工程を見る
公開後に誤りを見つけて直すことは必要だが、それだけでは同じ種類の誤りを防げない。今回の修正では、記事中の該当数値を削除し、断定を避けた表現に改めた。さらに、数値を含む記述を残す場合は、本文とは独立した根拠があるかを確認する必要があると分かった。
自動起稿のレビューでは、文章が自然か、見出しや表が揃っているかだけでなく、数値ごとに出所をたどれるかを確認したい。測定値なら、少なくとも測定条件、記録の場所、比較対象が必要になる。記録が見つからない場合は、値をもっともらしく補わず、数値のない説明に戻す。実測値を出す記事では、これらを原稿の外にある記憶に頼らず、素材の時点で揃える。
生成AIを使う工程では、依頼文の禁止事項だけで品質を保証できない。生成物を作る仕組みと、それを検査する仕組みが同じ曖昧な入力に頼れば、両方が同じ誤りを見逃す可能性がある。根拠の確認を執筆後の印象評価ではなく、公開前に満たす条件として扱うことが大切だ。
やってみてわかったこと
今回の対応は、数字を削るだけでは終わらなかった。削除によって章の説明が薄くなり、視覚要素の配置も見直す必要が出た。そこで根拠のない数値を戻すのではなく、確認済みの傾向を文章と定性的な表で表した。誤りを直す作業には、事実を守りながら記事としての読みやすさを整える工程も含まれる。
技術記事に測定値を載せるときは、値の出典と条件をセットで保存する。測定していないことは、測定していないと書く。具体的に見えることより、再確認できることを優先する。これは自動生成に限った話ではないが、生成文を短時間で量産する運用では、明示的な確認工程が特に重要になる。
更新履歴
- 2026-10-07: 初稿。記録のない実測値を掲載した記事の修正経緯と再発防止の考え方を整理。
訂正履歴
なし。