本誌AI MARKETING JOURNALは、複数のAI社員が並行執筆する体制で記事を量産しています。2026-08-08未明、この並行執筆そのものが原因で、1本の記事IDが2つのAIエージェントへ同時に投入される事故が起きました。
対象はAIMJ-0506です。本誌のgit履歴をgit log --followで実測したところ、上書きによる大規模な書き換えは残っておらず、被害はほぼゼロでした。ただし被害を止めたのは仕組みではなく、後発の書き手が持っていた1つの規律でした。
この記事は、何が起きたか・なぜ起きたか・なぜ被害が止まったかを、本誌自身のgit履歴で裏づけて記録します。並行執筆でAIに記事を書かせている現場なら、業種を問わず起こり得る事故です。量産計画そのものの点検を扱った『AI量産記事とスパムポリシー違反｜見るべきは本数でなく価値』と合わせて読むと、本誌の量産事故の全体像がつかめます。
01並行執筆で何が起きたか｜AIMJ-0506の二重投入
事故が記録されたコミットはacdddd02（2026-08-08 0時39分25秒・実測）です。コミットメッセージにディレクター自身の言葉で経緯が明記されています（自社実測・2026-08-08）。
AIMJ-0506は先に別のコミットc58ad05d（同日0時33分12秒）で1本目のAIエージェントが本文184行を新規作成していました。ところがディレクターは、この1本目の投入をAPIエラーによる失敗と誤認しました。
その結果、同じ記事IDが2本目のAIエージェントへ再投入されました。本誌の並行執筆は、Anthropic公式が示すサブエージェント方式を採っており、複数のAI社員が独立した文脈で同時に走ります（出典: Anthropicの公式ドキュメント）。独立して動くからこそ、2本目のエージェントは1本目の状況を知らないまま着手しました。
| 時刻（2026-08-08） | 出来事 |
|---|---|
| 0時33分12秒 | 1本目のエージェントがAIMJ-0506を新規作成（本文184行・図解3点） |
| （時刻不明） | ディレクターが1本目をAPIエラーによる失敗と誤認 |
| （時刻不明） | ディレクターが2本目のエージェントへ同じIDを再投入 |
| 0時39分25秒 | 2本目のエージェントの作業がコミットacdddd02として記録される |
本誌の実測台帳は、ファイルの更新時刻も別途statで確認しています（自社実測・2026-08-08）。図解3点は0時27分26秒から0時29分12秒の間に完成し、記事本文は0時36分44秒に仕上がっていました。図解が先に完成し本文が後から仕上がるという、通常の制作順序と矛盾しない時系列です。
02最初に疑ったこと｜二重投入がすぐ気づかれなかった理由（誤診）
二重投入が起きた直後、疑われたのは「APIエラーによる投入失敗」という個別の技術トラブルでした。ディレクターは1本目の投入が失敗したと判断し、再投入という通常の復旧操作を取りました。
この判断そのものは、単発のタスクなら正しい対応です。誤診だったのは、「同じ記事IDへの再投入が、別の書き手による正常な作業と衝突しうる」という並行実行特有のリスクを、その場では想定していなかった点です。
本誌が採用する並行執筆の設計は、単一のAIに全工程を任せず役割単位で分業する構成です。Anthropicのエンジニアリング解説は、こうした分業構成が単一モデルより高い性能を示すと述べています（出典: Anthropic Engineering）。ただし分業には、誰が今どのIDに着手しているかを中央で把握する仕組みが別途必要です。
03並行執筆の事故が起きた本当の原因｜ID割当の排他管理がなかった
技術的な引き金はAPIエラーの誤認でしたが、それだけでは二重投入は起きません。真因は、記事IDの割当がエージェント間で排他管理されていなかったことです。
本誌のバッチ量産は、記事マップの行を順にディレクターがAIエージェントへ割り当てる運用でした。1エージェントが1つの記事IDに着手した事実を記録し、他のエージェントへの再割当をブロックする仕組みは、この時点では存在していませんでした。
Googleは、価値を伴わない大量生成を「スケール化されたコンテンツの濫用」と位置づけています（出典: Google Search Central・2025-12-10更新）。同種の方針はスパムポリシー全体の基本にも明記されています（出典: Google 検索セントラル・2026-08-08確認）。量産のペースを上げるほど、この種の管理不備が実際の重複として表面化するリスクも上がります。
04被害がゼロで止まった理由｜後発の規律が救った
2本目のエージェントは着手前に02_記事/を確認し、AIMJ-0506が既にファイルとして存在することに気づきました。ここで2本目は、白紙から書き直すのではなく、既存ドラフトを監査する判断に切り替えました。
git show acdddd02で実際の差分を確認すると、変更は2箇所・合計4行のみでした（自社実測・2026-08-08）。1箇所はAhrefs調査の主語を明確にする言い回しの精緻化、もう1箇所は「Search Consoleに“指名検索抽出”という名前の公式機能は存在しない」という誤読防止の追記です。
記事の主旨・数値・出典を書き換えるような大規模な上書きには至っていません。被害がほぼゼロで止まった理由は、事故を防ぐ仕組みがあったからではなく、2本目の書き手が「着手前に既存ファイルの有無を確認する」という個人の規律を持っていたためです。
これは裏を返せば、次に同じ状況に置かれた別のエージェントが同じ規律を持つとは限らない、ということでもあります。規律だけに頼る運用は、再現性がありません。
05並行執筆の事故を二度と起こさない仕組み｜ID排他管理とファイル所有権
本誌はこの事故を受け、以後のバッチ量産で記事IDの割当を排他管理する運用へ切り替えました。1つの記事IDには1エージェントだけが着手し、着手済みのIDは別のエージェントへ再割当しません。
具体的な手順は次の3点です。第一に、ディレクターは新規割当の前に、ls 02_記事/またはgit statusでファイルの有無を確認する手順を挟みます。git logは変更履歴を--follow付きで追跡でき、着手記録の突合にも使えます（出典: Git公式ドキュメント）。
第二に、APIエラーで投入失敗と見えた場合も、再投入前に対象ファイルの実在を確認する手順を挟みます。エラー表示だけを根拠に再投入しません。第三に、既存ファイルを発見したエージェントは、上書きではなく監査（既存内容の確認と必要箇所のみの修正）を選ぶ運用を標準にしました。
この3点は、個人の規律を仕組みへ格上げする対策です。着手宣言と範囲ロックがあれば、次に同じ状況が起きても、規律の有無に関係なく被害を防げます。
自社で複数のAIに並行して記事や資料を書かせている場合も、着眼点は同じです。誰が今どの範囲に着手しているかを、記憶や口頭ではなく記録として残しているかを、量産のペースを上げる前に確認することをおすすめします。
06同じ失敗を避けるためのチェックリスト
- 複数のAIエージェントに並行して作業させる前に、担当範囲（記事ID・ファイル名など）の割当表を作っているか
- 割当表は、着手済みかどうかを他のエージェントも参照できる場所に置いているか
- APIエラー等で失敗と見えた作業も、再投入・再割当の前に対象の実在を確認しているか
- 新規着手の前に、既存ファイル・既存ドラフトの有無を確認する手順を明文化しているか
- 既存ファイルを発見した場合に「上書きせず監査する」という対応を、個人の判断ではなく標準手順にしているか
git logやgit statusなど、変更履歴を機械的に突合できる手段を使っているか- 二重着手が起きた場合の被害範囲を、実際の差分（追加行数・変更箇所数）で確認する運用があるか
- 量産のペースを上げる判断をする前に、ID割当の排他管理が追いついているかを点検しているか
