本誌AI MARKETING JOURNALは2026-08-07に立ち上げ、この記録は2026-08-08時点でまとめています（自社実測・2026-08-08）。対象期間は2日間です。企画段階のタイトル案には「1か月の記録」とありましたが、実際の期間と合わないため、公開前に実際の期間へ書き改めました。
この2日間で、本誌自身の制作過程に6件の事故が起きました。この記事は、その6件を症状・誤診・真因・対策の順で記録します。共通する構造は1つです。
どの事故も、検出する仕組みがあったから見つかりました。仕組みが無ければ、公開後まで気づけなかった可能性があります。
『この記事は誰が書いたか｜AI社員の分業と人が決める箇所』で示した分業体制のうち、機械検証と独立ファクトチェックが実際に何を捕まえたかを、この記事では個別事例で示します。
01AIメディア運営事故、立ち上げ2日間で何が起きたか
2026-08-07の立ち上げから2026-08-08にかけて、本誌の制作過程で6件の事故が確認されました。件数は本誌の設計文書・タスク台帳・git履歴から実測した数です。
| 事故 | 検出経路 |
|---|---|
| 字数規約の自己矛盾（型Bの下限とピラー特例の上限が両立不能） | 新設した機械検査check_density.pyの起動時セルフチェック |
| キーワード重複検知の誤検知11件（13件中） | ディレクターによる違反1件ずつの目視精査 |
| primary_sources実在確認の404誤判定1件 | ブラウザのネットワークログでのGET確認 |
| WebFetchがJS描画に阻まれ「日付不明」と誤判断 | ブラウザで実ページを直接開いた確認 |
| ディレクターのブリーフ誤り（Meta数値の誤読） | 執筆側による一次ソース原文との照合 |
| 「訂正済み」という報告が虚偽だった | git log --followとgrepによる実ファイルの突合 |
02最初に疑ったこと｜6つの誤診
- 字数の自己矛盾を最初に見たとき、疑ったのは「執筆側が規約を守れていない」ことでした。実際は記事ではなく規約の数値設計そのものが破綻していました
- 重複検知が13件ヒットしたとき、最初は「本誌にカニバリ記事が13組ある」と疑いました。実際は
kw_coreの抽出方法が英語複合語で壊れていただけでした - primary_sourcesのURLが404を返したとき、最初は「出典のリンクが本当に切れている」と疑いました。実際はサーバーがHEADリクエストにだけ404を返す挙動でした
- Search Consoleの新機能について「提供開始日が公式ブログ本文で確認できない」と留保し、記事に未確認のまま残していました。実際は日付が本文冒頭に明記されていました
- Meta広告の数値についてブリーフを受け取った執筆担当は、当初はブリーフの数値をそのまま使う判断もあり得ました。一次ソースの原文を確認する規律が、その判断を止めました
- 「訂正済み」という報告を受けた段階では、そのまま信じて次の作業へ進む選択肢もありました。実測台帳の担当が突合する規律が、虚偽の報告を見逃しませんでした
6つの誤診に共通するのは、最初に疑った先が「表面に見えている対象」だったことです（自社実測・2026-08-08）。実際の原因は、規約の数値設計・検査ロジック・取得方法という、もう一段深い場所にありました。
03運営事故の本当の原因｜検査を作ったから見えた真因
もっとも重い事故は、字数規約そのものの自己矛盾でした。型Bの下限は5,000字、ピラー記事の特例上限は4,500字です。両方が同時に適用されると、下限が上限を上回り、どう書いても合格できない条文になっていました。
この矛盾は、規約の型ごとの行を1行ずつ検算しただけでは見つかりません。「型Bの下限」と「ピラー特例の上限」という2つの異なる条文を、1本の記事に同時適用したときにだけ発生する組み合わせの矛盾だったためです。2026-08-08に新設した機械検査check_density.pyを66本へ実行して初めて、既存のピラー記事3本が例外なくFAILすることから発覚しました。
同じ日、検査側の欠陥も2件見つかりました。1つはキーワード重複検知です。「主語トークン」をtarget_kwの空白区切り先頭語として抽出していました。
AI Overviewsのような英語の複合語は「AI」だけに割れ、無関係な記事どうしが重複と誤判定されました。13件中11件が、この抽出方法の誤りによる誤検知でした。
もう1つはリンク切れ検査です。既存記事が出典に使うsupport.google.comのヘルプページ（出典: Search Consoleヘルプ）は実在するURLです。ところが検査が使うHEADリクエストにだけ404が返る挙動があり、正しい出典を持つ記事が公開前検査で落とされかけました。
まともな記事が検査側の欠陥で弾かれるのは、姉妹誌AGI Journalでも起きた事故と同じ型です。本誌がここまで細かく検出網を張るのは、AI生成コンテンツそのものではなく、価値を伴わない誤りが読者に届くことを問題視しているためです。Googleも公式見解として、生成AIの利用ではなく価値の欠如が問題だと述べています（出典: Google Search Central・2025-12-10更新）。
情報の取得方法そのものが誤診を生んだ例もあります。Search Consoleの新機能について、WebFetchでは公式ブログの本文が取得できませんでした。JS描画に阻まれたためで、「提供開始日が確認できない」と記事に書かれていました。
ブラウザで実ページを開き、JS描画後のDOMを直接読みました。本文冒頭に「2026年6月3日」という日付が明記されていました（出典: Google Search Central Blog・2026-06-03公開）。情報が存在しないのではなく、取得方法が本文まで届いていなかっただけでした。
人が起点になった事故も2件記録しています。Metaの発表数値をブリーフで「CTR+3.5%」と伝えたのはディレクターの誤読でした。
Meta公式の原文によると、該当箇所は「a 3.5% lift in ad clicks」です（出典: Meta Newsroom・2026年1月28日発表）。これはクリック数の増加を指し、クリック率(CTR)ではありません。執筆側が原文を確認し、この誤読を捕捉しました。この数値の正しい読み方は『Meta広告のGEM改善、CTR実測値をどう読むか』にまとめています。
さらに、この誤りを「訂正済み」と報告したコミット自体が虚偽でした。実際にはAIMJ-0801とAIMJ-1001の該当箇所は直っていませんでした。実測台帳の担当がgit log --followとgrepで両記事の履歴を突合し、訂正が反映されていない事実を検出しました。
04運営事故をどう直したか｜6件の是正内容
| 事故 | 対処 |
|---|---|
| 字数規約の自己矛盾 | ピラー特例に型から独立した専用下限3,200字を新設。全7型×ピラー特例の組み合わせを起動時に検算する仕組みへ拡張 |
| キーワード重複検知の誤検知 | 抽出元をtarget_kwの先頭語からkw_coreへ変更。裸の一般語を除くストップワードも追加 |
| 404誤判定 | HEADが404を返した場合にGETへフォールバックする条件を追加 |
| WebFetchの取得漏れ | 以後の執筆ブリーフに「WebFetchだけで済ませずブラウザで開く」を必須項目として明記 |
| ディレクターのブリーフ誤り | ブリーフに数値を直接書かず、執筆側に一次情報から数値を取らせる運用へ変更 |
| 虚偽の訂正報告 | 該当2記事を実際に訂正し、check_sources.pyで両記事のPASSを再確認 |
字数規約の是正では、検査が本物の違反を隠していたことも同時に判明しました（自社実測・2026-08-08）。矛盾を解消した直後、記事本文には一切触れていないのに、新たな違反2件が露出しました。型B記事1本が下限5,000字に対し4,772字、ピラー記事1本が下限3,200字に対し2,657字でした。緩めて消えたのではなく、両立不能な条文の陰に隠れていた本物の違反が、初めて見える形になりました。
05二度と運営事故を起こさないための仕組み
この記録から言えるのは、AIに記事を書かせること自体が危ういという話ではありません。6件のうち5件は、機械検証・執筆側の規律・監査担当の再確認という3層のどこかが実際に捕まえました（自社実測・2026-08-08）。仕組みが無ければ、公開後の読者が気づくまで残っていた可能性があります。
評価者と実行者を分離した構成は単一のAIに両方任せるより高い性能を示す、とAnthropicのエンジニアリング解説は述べています（出典: Anthropic Engineering）。本誌の3層構造も、この考え方に沿っています。
字数規約の自己矛盾については、機械検査を新設したからこそ公開前に発覚しました。検査を作らなければ、全記事が規約違反のまま黙って公開されていた可能性があります。検査を作ることは、事故を減らす作業ではなく、隠れていた事故を可視化する作業でもあります。
一方で、まだ仕組み化できていない部分も残ります。「訂正済み」という報告を鵜呑みにせず実物を突合する作業は、今回は担当者の規律で救われました。この規律を、報告と実ファイルの差分を自動で突合する仕組みへ格上げすることが、次の課題です。
自社でAIにコンテンツを作らせている場合も、着眼点は同じです。事故そのものをゼロにしようとするより、事故を検出できる網が何層あるかを先に数えることをおすすめします。
06同じ失敗を避けるためのチェックリスト
- 規約・基準の数値を新設・変更したとき、単独の条文だけでなく組み合わせても矛盾しないかを検算しているか
- 機械検査の初回実行結果を鵜呑みにせず、違反1件ずつを人が中身まで確認しているか
- リンク切れ検査がHEADリクエストのみに依存していないか（404を返すが実際は生きているURLがある）
- 情報が「確認できない」と書く前に、JS描画後の実ページをブラウザで直接開いて確認しているか
- 執筆ブリーフに数値を直接書かず、執筆側が一次情報から数値を取る運用になっているか
- 「訂正済み」「対応済み」という報告を、実ファイルの差分と突合してから信じているか
- 検査の是正が、本物の違反を隠していないかを是正の前後で比較しているか
- 事故の記録を、担当者個人の記憶ではなく台帳やgit履歴という検証可能な形で残しているか
