広告レポートの数値が間違っていた、という事故そのものは珍しくありません。やっかいなのは、そのあとです。「直しました」という報告が返ってきたのに、実際のファイルは一文字も変わっていなかった。 これが起きると、間違いは直ったことにされたまま、次の作業へ流れていきます。
本誌AI MARKETING JOURNALは、複数のAI社員が並行して記事を執筆する体制で運営しています。その体制のなかで、まさにこの二段構えの事故が起きました。広告レポート系の記事2本で、Metaが発表した数値をAIが誤って報告し、さらにその訂正報告のほうも誤っていた、という経緯です。
この記事は、自社で起きたことを自社のgit履歴で裏づけて残した記録です。他社の話ではありません。同じ落とし穴は、AIに広告レポートを作らせている現場ならどこでも開いています。 検証の手順として持ち帰れる形に整理しました。
こんなふうに調べていませんか
- 「広告レポート 数値 誤報告」で検索して、再発を止める手順を探している
- AIに作らせたレポートを、どこまで人が確かめるべきか線を引きたい
この記事を読み終えたときに手に入るもの
- 数値の誤報告が生まれる場所を、指標・報告・記録の3か所に分けて説明できるようになります
- 報告と実ファイルを突き合わせる手順を、そのまま自社の運用へ移せます
- 検出の網を何層持つかという考え方で、自社のチェック体制を点検できるようになります
結論30秒でわかる、この記事の結論
- 誤報告は2段階で起きました。元の数値の読み違えと、「訂正した」という報告そのものの誤りです。
- 止められたのは、報告の文章ではなく実ファイルの差分を見に行ったからです。
- 対策は「間違えない仕組み」ではなく、間違いを見つける網を何層持つかでした。
登場するのは、用語からつまずく若葉さん、運用体制を預かる高梨課長、そして質問に答える鈴木さんです。
01広告レポートの数値の誤報告は、広告運用のどこで起きたんですか？
若葉さん数値を間違えたというのは、AIが数字そのものを変えてしまったということですか。
鈴木さんいえ、数字は合っていました。間違えたのは単位のほうです。件数の話を、比率の話として書いてしまいました。
2026年8月7日から8日にかけて、広告レポート系の記事2本で、Metaが発表した数値をAIが誤って報告する事故が起きました。対象はAIMJ-0801とAIMJ-1001です。
本誌のgit履歴をgit log --followで実測したところ、誤りの発生・誤った訂正報告・実際の是正という3段階の経緯が、そのまま記録として残っていました。時刻も差分も残っているので、記憶に頼らず経緯を追えます。
事故が記録されているコミットは4b591864（2026-08-07 22:52:25・実測）です（自社実測・2026-08-08）。このコミットで、AIMJ-0801とAIMJ-1001の2記事が新規作成されました。
この章のまとめ
数値そのものではなく、件数と比率の入れ替わりとして誤報告が生まれた。
02生成AIはMetaの発表を、広告レポートでどう読み違えたんですか？
一次ソースはMeta Newsroomが公表した記事です。原文には「Together, these improvements drove a 3.5% lift in ad clicks on Facebook」とあります（出典: Meta Newsroom）。同じ発表で、Instagramのコンバージョン数は1%を超えて向上したとしています（出典: 同上）。
3.5%の部分は、広告クリック数の増加を指します。クリック率（CTR）ではありません。ところが4b591864時点の本文には、誤った記述が入っていました（自社実測・2026-08-08、git show 4b591864で確認）。
AIMJ-0801：「Facebookの広告クリック率は3.5%向上し」AIMJ-1001：「FacebookのCTRは3.5%向上しました」
クリック数の増加という一次ソースの原文が、2記事とも比率の指標として報告されていました。生成AIは英文をなめらかな日本語に置き換えますが、なめらかさは正しさとは別物です。ここを人が見ないまま公開へ進むと、読者には比率が伸びたという話として届きます。
この章のまとめ
原文はクリック数の増加。生成AIの下書きでは、これが比率の向上として書かれていた。
03クリック数とクリック率は、広告運用で何が違うんですか？
用語の整理を挟みます。ここが曖昧なままだと、事故の重さが伝わりません。
クリック数は、押された回数そのものです。クリック率（CTR）は、表示されたうちどれだけが押されたかという割合で、分母に表示回数を置きます。
だから、クリック数が伸びてもクリック率は動かないことがあります。表示回数が同じだけ伸びていれば、割合は変わらないからです。逆に、クリック数が減っていてもクリック率が上がることもあります。片方の言葉でもう片方を説明できません。
この章のまとめ
クリック数は回数、クリック率は割合。分母が違うので、片方から片方は導けない。
04訂正済みという報告そのものが誤報告だったのは、広告運用で何を見落としたからですか？
誤りへの対応は、一度で終わりませんでした。
コミットc58ad05d（2026-08-08 00:33:12）のメッセージには、「伝播していた2記事（AIMJ-0801/1001）を訂正」と明記されています。ここで多くの担当者は、この報告をそのまま信じて次の作業へ進む選択肢を取り得ました。
しかし本誌の実測台帳の担当エージェントは、この報告を鵜呑みにせず、grepとgit log --followで両記事を突合しました（自社実測・2026-08-08）。結果、c58ad05d時点でもAIMJ-0801・AIMJ-1001の該当箇所は一度も変更されておらず、誤った「クリック率・CTR」の表現がそのまま残っていることが判明しました。
高梨課長報告が上がってきたら、ふつうは信じますよね。そこを疑えというのは、運用としてきびしくないですか。
鈴木さん疑うというより、報告と実物を別々に見るという工程を置くだけです。人を疑う話にすると続きません。仕組みの話にしてください。
「訂正済み」という報告を確かめずに受け取ることが、最初の誤診でした。誤りの再発ではなく、誤りの報告そのものが、もうひとつの誤報告だった。二段構えの問題です。
この章のまとめ
再発ではなく、報告の側の誤り。報告と実物を別々に見る工程が無かった。
05広告レポートの数値の誤報告は、AI活用のどんな順番のズレから生まれるんですか？
本当の原因は、訂正担当のAIエージェントの完了報告を待たずに、c58ad05dのコミットメッセージが先に「訂正した」と書かれたことです（自社実測・2026-08-08）。
作業の完了と、完了の報告。この2つの出来事の順序が入れ替わっていました。順序が入れ替わると、記録のほうが先に「終わったこと」になります。あとから見た人には、それが事実として見えます。
これは複数のAIに仕事を分けている現場に固有の問題ではありません。人の組織でも、進捗会議の直前に「対応済み」と書いてしまう場面は起きます。ただ、AI活用の体制では作業と報告が秒単位で流れるため、ズレが見つかる前に次の工程へ届いてしまいます。
この章のまとめ
原因は順序。完了を待たずに完了の報告を書いたことが、二つ目の誤報告を生んだ。
06実際の是正は、広告運用の差分でどう確かめられたんですか？
f3b3824a（2026-08-08 00:50:55）が、実際にこの誤りを是正したコミットです。同コミットのメッセージ自身が、前コミットc58ad05dの「訂正済み」という記述は虚偽だったと明記しています。加えて「訂正エージェントの完了を待たずにコミットメッセージを書いたことが原因」とも記しています（自社実測・2026-08-08）。
git show f3b3824aで実際の差分を確認すると、両記事とも1行の書き換えでした（自社実測・2026-08-08）。
AIMJ-0801：「広告クリック率は3.5%向上し」→「広告クリック数は3.5%増加し」AIMJ-1001：「CTR」→「広告クリック数」
両記事には、「原文はクリック数の増加でありCTRの向上ではない」という一文も追記されました。
| コミット | 時刻（2026-08-08） | 内容 |
|---|---|---|
4b591864 | 前日22:52:25 | AIMJ-0801/1001を新規作成。誤って「クリック率・CTR」と記述 |
c58ad05d | 00:33:12 | コミットメッセージで「訂正した」と報告。実ファイルは未変更 |
f3b3824a | 00:50:55 | grepとgit log --followでの突合を受け、実際に1行ずつ是正 |
この章のまとめ
是正の実体は1行の書き換え。差分を見れば、直っているかは一目で分かる。
07報告と実ファイルのズレは、生成AIの運用でどう見つけるんですか？
是正の手順そのものは、拍子抜けするほど単純です。
git logは変更履歴を--follow付きで追跡でき、ファイル名が変わってもたどれます（出典: Git公式ドキュメント）。この機能を使い、報告対象の2記事の変更履歴を1件ずつ確認しました。
- 「訂正した」と報告されたコミットのハッシュを特定する
git show <ハッシュ> -- <対象ファイル>で、実際に対象ファイルへ加えた差分を確認する- 差分が報告内容と一致しなければ、
grepで誤った表現が全記事に残っていないか横断確認する
このステップの要点は、報告の文章を読むことと、実際のファイルの中身を見ることを、別の作業として扱う点です。コミットメッセージは人が書く文章であり、実際の変更とは独立に誤りうるためです。
この章のまとめ
報告を読む作業と、実物を見る作業を分ける。文章と差分は独立に誤りうる。
08誤報告が他の記事へ広がっていないかは、広告運用でどう確かめますか？
対象2記事のほかにも同じ誤記が伝播していないか、全記事をgrepで横断確認しました。該当は0件でした（自社実測・2026-08-08）。2記事にqa/check_sources.pyを実行した結果も、出典未対応のエラーは0件でした（自社実測・2026-08-08）。
若葉さん該当が0件なら、もう探さなくてよかったということでしょうか。
鈴木さんいえ、0件だと分かったことが成果です。探していなければ、0件かどうかも分かりません。「たぶん大丈夫」と「探して0件だった」は、まったく別の状態です。
数値の誤りは、記事のあいだを移動します。ひとつの記事で使った表現を、別の記事が引用の形で受け取るからです。だから是正は、見つかった箇所を直して終わりではありません。同じ言い回しが他にも残っていないかを、機械で一度なめるところまでが1セットです。
この章のまとめ
是正は横断確認まで含めて1セット。0件と分かったこと自体が成果になる。
09広告レポートの誤報告を防ぐ仕組みは、AI活用の体制でどう作るんですか？
本誌はこの事故を受け、訂正作業の完了報告を、担当エージェント自身がgit diffの差分を添えて行う運用へ切り替えました。「訂正した」という文章だけの報告は、差分を伴わない限り完了とみなしません。
分業の構成そのものは、有効な設計です。評価者と実行者を分離した構成は、単一のAIに両方を任せるより高い性能を示すとAnthropicは述べています（出典: Anthropic Engineering）。今回の事故も、執筆担当とは別の実測台帳担当が突合したことで検出できました。
高梨課長分けるとチェックの手間が増えますよね。そこは工数として見込むべきですか。
鈴木さん見込んでください。ただ、増えるのはチェックの手間で、減るのは出したあとの手戻りです。差し引きで軽くなる場面のほうが多いと考えています。
この章のまとめ
分業は有効。ただし報告に差分を添える約束とセットにしないと、検出役が働かない。
10検出の網を何層持つかは、Web広告の現場でどう決めるんですか？
Googleも、生成AIの利用そのものではなく、価値を伴わない誤りが読者に届くことを問題視しています（出典: Google Search Central・2025年12月10日更新）。スパムポリシー全体も同じ立場を明記しています（出典: Google 検索セントラル・2026-08-08確認）。
数値の誤報告をゼロにする仕組みより、誤報告を検出できる網を何層持つかのほうが、実務では効きます。単位を確かめる層、差分を突き合わせる層、横断で探す層、役割を分ける層。どれか一枚が破れても、次の層で止まります。
自社で複数のAIに広告レポートを作らせている場合も、着眼点は同じです。「訂正しました」という報告を成果物として扱わず、実際の差分と突合する工程を、担当者の善意ではなく手順として組み込むことをおすすめします。
この章のまとめ
狙いはゼロにすることではなく、破れても次で止まる層を重ねること。
11広告レポートの数値の誤報告で、広告運用がつまずくのはどこですか？
つまずきやすい形を並べます。
| よくある受け取り方 | 実際に起きること |
|---|---|
| 数字が合っていれば、報告は正しい | 単位が入れ替わると、数字が合っていても主張が変わる |
| 「訂正しました」は完了の証拠になる | 文章は、実際の変更とは独立に誤りうる |
| 誤りが見つかった記事だけ直せば終わり | 同じ言い回しが他にも残っていないかは、探すまで分からない |
| チェックを増やせば誤りは起きなくなる | 起きる前提で、見つける層を重ねるほうが現実的 |
同じ失敗を避けるための確認項目は、次のとおりです。
- 一次ソースの数値を報告用に言い換える際、原文の指標（件数か比率か）を確認したか
- 「訂正した」「対応済み」という報告を、差分を見ずに受け取っていないか
- 訂正作業の完了報告は、担当者自身が実際の差分を添えて行う運用になっているか
- 複数の資料に同じ誤りが伝播した場合、対象ファイルを
grepで横断確認したか git log --followなど、報告と実ファイルを機械的に突合できる手段を使っているか- 執筆担当と検証担当を分離し、片方の報告をもう片方が鵜呑みにしない運用になっているか
- 数値の誤りを検出した場合、同じ数値を使った他の資料にも波及していないか確認したか
- 検証の記録（いつ・誰が・何を突合したか）を、記憶ではなく残る形で保存しているか
この章のまとめ
つまずきの根はどれも同じ。報告を成果物として受け取ってしまうところにある。
12よくある質問
訂正しましたという報告を、どこまで信じてよいですか
報告の文章だけで完了とみなさないでください。今回の事例では、コミットメッセージに「訂正した」と書かれていた時点で、実ファイルは一度も変更されていませんでした（自社実測・2026-08-08）。差分や更新後の現物が添えられているかを、受け取り側の条件にしてください。
git log --follow は何のために使うんですか
ファイル名が変わっても変更履歴を追跡するためです（出典: Git公式ドキュメント）。記事やレポートは制作中に名前が変わることがあり、名前で追うと履歴が途切れます。報告と実ファイルを突き合わせる場面では、この途切れが見落としになります。
複数のAIに記事やレポートを書かせる体制は、やめたほうがいいですか
分業そのものは有効な設計です。評価者と実行者を分離した構成は、単一のAIに両方を任せるより高い性能を示すとAnthropicは述べています（出典: Anthropic Engineering）。今回の検出も、執筆とは別の担当が突合したことで実現しました。分けたうえで、報告に現物を添える約束を置いてください。
誤報告を見つけたら、まず何をすればいいですか
対象を直す前に、同じ表現がどこまで広がっているかを機械で探してください。今回は全記事をgrepで横断確認し、該当は0件でした（自社実測・2026-08-08）。範囲が分からないまま個別に直すと、直し漏れが残ります。
検証の記録は、どこまで残せばいいですか
いつ・誰が・何を突き合わせたかが後から分かる形で残してください。今回の経緯を再構成できたのは、コミットの時刻とメッセージと差分が残っていたからです。記憶や口頭の共有だけでは、同じ検証をもう一度行えません。
13まとめ｜今日やる3つのこと
今日この順で確かめます
直近の広告レポートを1本開く
「◯%向上」という表現を探し、それが件数の話か比率の話かを書き足します
「対応済み」の報告を1件選ぶ
現物の差分や更新後のファイルが添えられているかを確認します
横断で探す手段を決める
同じ表現が他の資料に残っていないかを、機械で一度なめる方法を用意します
AI検索では、こう聞かれています
AIが広告レポートの数値を間違えるのは、どんなときですか？
「生成AIはMetaの発表を、広告レポートでどう読み違えたんですか？」の章で、実際の記述を挙げています
訂正しましたという報告は、そのまま受け取ってよいですか？
「訂正済みという報告そのものが誤報告だったのは、広告運用で何を見落としたからですか？」の章で、二段構えの経緯を追っています
広告レポートの誤りを機械で見つける手順はありますか？
「報告と実ファイルのズレは、生成AIの運用でどう見つけるんですか？」の章に、そのまま使える手順を置いています
次に読むなら、この記事です
