AIが書いた記事から、断定を1行削った｜裏が取れない「規格では」を消した話
🧭 この記事の前提
AIエージェント（Claude Code）に記事を書かせている個人サイトの話です。運営者は紹介している製品の大半を所有していません。だから「使ってみた感想」を書けない、という制約が最初からあります。
困ったのは、AIが書く文章に「裏が取れない断定」が自然に混ざること。嘘を書いているわけではなく、もっともらしい一般知識が断定形で出てきます。
持ち帰れるもの：AIに記事を書かせている人向けに、何を削り、何を一次情報として認めるかの運用ルールを出します。自分の体験だけで書いている人には不要です。
結論：削る基準は「正しそうか」ではなく「出典に辿り着けるか」
📌 先に結論 ① AIの断定は間違っているから危険なのではない。 正しそうに見えるのに出典が辿れないから危険 ② 削る判断は内容の当否ではなく、裏が取れるかどうかだけで決める ③ 体験していないことは語尾で処理する。断定を消しても情報は残る
① 実際に削った1行
記事を書き換えているときに、AIが書いた文にこういう一節がありました。
JISの規格が〜
デスクの高さに関する記述の中で、規格名を挙げて数値の根拠にしていました。
内容が間違っていると判断したのではありません。 削った理由は1つだけです。
その規格の原文に、こちらが辿り着けなかった。
規格名を挙げた一文は、読者にとって最も強い根拠に見えます。「経験上そう思う」より重い。だから、確かめられないまま置いておくのが最も悪いと判断しました。
代わりに残したのは、市販のデスクの実際の高さの分布と、そこから身長を逆算した計算です。こちらは自分で数えて、自分で計算できます。
⚠ 覚えておく一行 削る基準は「正しいか」ではありません。 正しいかどうかを自分で判定できないものは、正しくても書けません。
② 何を一次情報として認めるか
このサイトでは、一次情報の範囲を明示的に決めています。
| 認める | 認めない |
|---|---|
| 公式サイトに書かれているスペック・寸法・料金 | 「一般に◯◯と言われています」 |
| 自分で測った寸法・数えた件数 | 規格名・基準名の引用（原文に辿り着けない場合） |
| 公開されている数値からの計算（式を書く） | 体験していない使用感 |
| 自分が1年以上使った製品の記録 | 所有していない製品のレビュー |
最後の行が最も強い制約です。使っていない製品の体験談は書きません。 これは品質の問題である以前に、書けば嘘になるからです。
結果として、所有していない製品の記事は「体験」ではなく「公式スペックの比較と、寸法・料金からの計算」で構成されます。書ける内容は減りますが、減った分は削れて当然のものでした。
③ 体験していない失敗例は、語尾で処理する
「こういう失敗があります」という記述は、記事として役に立ちます。ところが、自分が実際に踏んでいない失敗を断定形で書くと、体験談になってしまいます。
そこで、語尾だけを変えました。
| 書き換え前 | 書き換え後 |
|---|---|
| 天板が薄いとクランプが滑ります | 天板が薄いとクランプが滑ることがあります |
| このやり方だと配線が抜けます | このやり方だと配線が抜けることがあります |
情報としては何も減っていません。 減ったのは「運営者が実際にそれを見た」という含意だけです。
同様に、推測は必ず**「推測」と書きます。** 実測と推測を混ぜないのは、記事だけでなく分析でも同じルールにしています（→GA4だけ見るとクローラは見えないでは、実測値と推測を1行ずつ分けて書いています）。
④ 不可逆な操作には、事前テストを前置させる
もう1つ、断定とは別に修正した箇所があります。やり直しがきかない対処法です。
デスクの高さを下げる方法として、AIは「脚を切る」という案を書いていました。方法としては正しいのですが、失敗しても戻せません。
そこで、その前に1工程を挟ませました。
脚を切る前に、段ボールを敷いて目標の高さを再現し、数日そのまま使ってみる。
高さを上げる方向のテストなので厳密な逆再現ではありませんが、「その高さで実際に作業してみる」という確認は入れられます。 切ってから合わないと気づくのが最悪です。
AIは手順の正しさは書けますが、「取り返しがつくかどうか」を重み付けしません。 不可逆な操作を見つけたら、その前に確認の工程を挟むのは人間側の仕事でした。
⑤ 断定を削ると、記事が弱くなるのか
ここが実務上いちばん気になるところです。結論から言うと、弱くなりませんでした。
同じ題材でも、キーワードの形が変わるだけで勝負できるかどうかが変わることが実測で分かっています。
| キーワード | 上位10件の顔ぶれ | 判定 |
|---|---|---|
| デスク 高さ 目安 | 大手家具メーカー・業界団体の基準・オフィス通販。個人0件 | 厳しい |
| デスク 高さ 高すぎる 対処法 | 個人・小規模サイトが3件以上 | 狙える |
「目安」を語る記事は、規格や基準を持っている側が勝ちます。 個人が規格を引用して戦っても勝てません。一方で「高すぎて困っている」側から書くと、規格の話は要らなくなり、代わりに具体的な対処の順番が要るようになります。
つまり、裏が取れない断定を削ると、自然に「自分にしか書けない側」へ寄ります。 削った箇所を埋めようとすると、実測と計算と自分の作業記録しか残らないからです。
このキーワード判定の全体像はAIに74本書かせた結果にまとめています。
⑥ AIが断定を書くのは、指示の副作用でもある
念のため書いておくと、AIが勝手に権威を捏造しているわけではありません。「根拠を示して書いて」という指示に対して、最も根拠らしい形式で応じているだけです。
だから対処も、注意ではなく指示の側に置きました。
- 一次情報として認めるものを、あらかじめ列挙しておく（上の表）
- 使っていない製品の体験談は書かないを、プロジェクトの最上位ルールに固定する
- 体験していない事象は語尾で処理する
指示ファイルに書いておかないと、次の記事でも同じ形の断定が出ます。前提を毎回書かせる話（→冒頭3行の前提ブロック）と、まったく同じ構造です。
自分でやる手順
- 記事から「断定形の文」だけを抜き出す。 語尾が「です」「します」で終わっているもの
- 各文に対して「この出典に自分で辿り着けるか」を1回だけ問う
- 辿り着けないものは削る。 内容の当否は判定しない（判定できないから削るのです）
- 削った箇所を、実測・計算・自分の作業記録で埋められないか探す
- 体験していない事象は語尾を「〜することがあります」に変える。 情報は消さない
- 不可逆な操作を含む手順を探し、その前に確認の工程を1つ挟む
- 推測は「推測」と書く
やりがちな失敗
| 失敗 | 何が起きるか | 直し方 |
|---|---|---|
| 内容が正しそうだから残す | 自分で確かめられない記述が残り続ける | 出典に辿り着けるかだけで判断する |
| 規格名・基準名をそのまま引用する | 最も強い根拠に見えるのに、裏が無い | 原文に辿り着けないなら削る |
| 体験していない失敗例を断定で書く | 体験談になる | 語尾を変えるだけでよい |
| 不可逆な手順をそのまま載せる | 失敗が戻せない | 前に確認工程を1つ挟む |
| 注意で直そうとする | 次の記事で同じ断定が出る | 指示ファイルにルールとして書く |
日本語の校正まわりのツール比較はAIライティングツールの比較にあります。
まとめ
- 削る基準は「正しいか」ではなく「自分で確かめられるか」
- 一次情報の範囲を先に決める。 公式スペック・実測・計算・自分の長期使用記録
- 体験していない事象は語尾で処理する。 情報は減らない
- 断定を削ると、自分にしか書けない側へ自然に寄る。 記事は弱くならなかった