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