課題
記事を公開した後、内容が正しく反映されているかをAIに確認してもらう。ただ、その確認のためのTool自体が、文章を読み込む過程で内部的に要約や言い換えをしていると、実際には無い間違いを「見つけてしまう」ことがある。確認する側のTool自体を、無条件には信用できない場合がある。
この記事でわかること
- 確認用のAI Toolが、実際には存在しない誤りを「見つけて」しまう仕組み
- 確認結果を鵜呑みにせず、生データまで遡って確認するときのやり方
解決できたこと
確認Toolの報告を鵜呑みにせず、生データまで遡って確認したことで、実際には存在しない誤りだったと分かった経緯を振り返る。この教訓を個人の記録だけで終わらせず、仕組みとして残した話も合わせて紹介する。
本文
3つの不一致が見つかった
ある記事をWordPressへ公開した直後、内容がDraftどおりに反映されているかをAIに確認してもらった。すると、閉じカギ括弧が抜けている箇所、ちょっとした誤字、そして「鮭のホイル焼き」が「鯛のホイル焼き」に変わっている箇所という、3つの不一致が報告された。
「また事故が起きたのでは」と、生データまで遡って確認する
ちょうど直前に、別の記事で本当に古いバージョンがそのまま公開されてしまうIncidentが起きていた。AIはそれと同じ種類の事故を疑い、WordPressの生データをもう一度直接取得して、Pythonで整形しながら本文を1文字ずつ確認し直してくれた。
間違っていたのは、確認に使ったTool自身だった
AIが確認し直した結果、公開されていた本文は実際にはDraftと完全に一致していた。閉じカギ括弧はちゃんとあり、誤字も無く、「鮭のホイル焼き」も正しく「鮭」のままだった。
つまり、最初に見つかった3つの不一致は、公開された記事の問題ではなく、確認のために使ったTool自身が作り出した誤りだった。
原因は、確認Tool内部の「要約」だった
原因を調べると、最初に使った確認Toolは、Webページの内容を取得する際に内部でAI Modelによる要約・言い換えを行う仕組みになっていた。文章を大まかに理解するには十分でも、1文字単位の正確な比較が必要な場面には向いていなかった。要約や言い換えの過程で、閉じカギ括弧が消えたり、似た単語（鮭と鯛）に変換されたりすることがある、というわけ。
この教訓を、個人の記録だけで終わらせない
この一件を、自分からAIへ「個人用のメモとしてだけでなく、Repository全体の資産として残してほしい」と伝えた。結果、「文字単位の正確な照合が必要な場面では、要約を挟むToolではなく、生のデータを直接取得するToolを使う」というRuleとして明文化してもらった。
個人の「気をつけよう」で終わらせず、次に同じような確認作業をする誰か（未来の自分やAI自身も含めて）が同じ勘違いをしないよう、仕組みとして残しておくのが良さそうだった。
確認のためのAIも、間違えることがある
記事の内容確認や、何かのFactCheckにAIを使うとき、そのAI自身が文章を要約・言い換えする過程で、実際には無い誤りを作り出してしまうことがある。特に「事故が起きたかもしれない」と感じたときほど、その確認結果を鵜呑みにせず、生のデータまで遡って確認してみるといいのかもしれない。
同じ状況に陥ったときの回避策
- 文字単位の正確な照合が必要な場面では、要約・言い換えを挟むToolではなく、生データを直接取得するToolを使う
- 確認Tool自体が出した「間違い」報告も鵜呑みにせず、必要なら生データまで遡って確認する
この記事は、筆者が実際に運営しているBlogの公開作業の記録（2026年8月7日）を基に、独自調整したAIが下書きを作成し、筆者が事実確認・編集を行った上で公開しています。
