複数のAIに同時に記事を書かせると、書き手どうしがお互いを見ていません。人間の編集部なら「その記事、いま私が触っています」の一言で止まる衝突が、AIエージェントの並行執筆では止まらないことがあります。
本誌AI MARKETING JOURNALは、複数のAI社員が並行執筆する体制で記事を量産しています。2026-08-08の未明、この並行執筆そのものが原因で、1本の記事IDが2つのAIエージェントへ同時に投入される事故が起きました。対象はAIMJ-0506です。
この記事は、その事故を本誌自身のgit履歴で裏づけて記録したものです。何が起きたのか、なぜ起きたのか、そしてなぜ被害がほとんど出なかったのか。生成AIで記事や資料を量産している現場なら、業種を問わず起こり得る事故だと考えています。
こんなふうに調べていませんか
- 「並行執筆 記事重複 事故」で検索して、AIに量産させる前の注意点を探している
- 複数のAIエージェントに同時に作業させていて、担当範囲の管理に不安がある
この記事を読み終えたときに手に入るもの
- 並行執筆で記事が重複する場所を、社内で説明できるようになります
- 二重投入が起きたときに、被害の範囲をgit履歴で確かめられるようになります
- 記事IDの割当を排他管理する手順を、明日から運用に入れられます
結論30秒でわかる、この記事の結論
- 並行執筆の記事重複は、書く力の問題ではありません。誰がどのIDに着手しているかを記録していない運用が起こします。
- 引き金はAPIエラーの誤認でした。ただし真因は、記事IDの割当がエージェント間で排他管理されていなかったことです。
- 被害を止めたのは仕組みではなく、後から入った書き手が持っていた「着手前に既存ファイルを見る」という規律でした。規律は再現しません。
本記事の時刻・差分はすべて、本誌のgit履歴とファイル更新時刻を実測したものです（自社実測・2026-08-08）。
01並行執筆の記事重複事故は、生成AIの量産でなぜ起きるんですか？
若葉さん複数のAIに同時に書かせると、似たような内容の記事ができてしまうということですか。
鈴木さんいえ、内容が似るという話ではありません。同じ枠に2人が入ってしまう、という話です。工事現場でいえば、同じ区画に別々の業者が入ってしまう状態ですね。
結論から書きます。並行執筆の記事重複は、AIの書く力とは関係のないところで起きます。起きるのは、割り当ての管理が書く速さに追いついていないときです。
本誌の並行執筆は、Anthropic公式が示すサブエージェント方式を採っています（出典: Anthropicの公式ドキュメント）。複数のAI社員が、それぞれ独立した文脈で同時に走る形です。独立しているから速く進み、独立しているから、隣が何をしているかを知りません。
人間の編集部であれば、席が並んでいるだけで衝突の多くは防げます。「その記事、私が書いています」という一言が、記録に残らないまま共有されるからです。AIエージェントには、その一言が届きません。届かせたいのであれば、声ではなく記録として置く必要があります。
この章のまとめ
記事重複は、AIの能力ではなく割り当ての管理から起きる。独立して走らせる以上、共有は記録でしか行えない。
02記事重複が起きた日、AI活用の現場では何が動いていたんですか？
事故が記録されたコミットはacdddd02です。時刻は2026-08-08の0時39分25秒。コミットメッセージには、ディレクター自身の言葉で経緯が書かれていました。
その手前に、別のコミットc58ad05dがあります。同じ日の0時33分12秒、1本目のAIエージェントがAIMJ-0506の本文184行を新規に作成したコミットです。つまり後から入ったエージェントが動き出した時点で、記事はすでに存在していました。
| 時刻（2026-08-08） | 出来事 |
|---|---|
| 0時33分12秒 | 1本目のエージェントがAIMJ-0506を新規作成（本文184行・図解3点） |
| （時刻不明） | ディレクターが1本目をAPIエラーによる失敗と誤認 |
| （時刻不明） | ディレクターが2本目のエージェントへ同じIDを再投入 |
| 0時39分25秒 | 2本目のエージェントの作業がコミットacdddd02として記録される |
本誌の実測台帳は、ファイルの更新時刻も別途statで確認しています。図解3点は0時27分26秒から0時29分12秒の間に完成し、記事本文は0時36分44秒に仕上がっていました。図解が先に出来上がり、本文が後から整うという流れは、通常の制作順序と矛盾しません。
ここが、この事故のいちばん大事なところです。記録の側から見ると、1本目の作業は最初から最後まで正常に進んでいました。 失敗したように見えていたのは、投入した側の画面だけだったことになります。
この章のまとめ
git履歴とファイル更新時刻を並べると、1本目は正常に完了していた。失敗に見えたのは投入側の画面だけだった。
03並行執筆でAI活用を進めると、担当はどこでぶつかるんですか？
高梨課長うちも複数のAIを並べて動かす予定なんですが、ぶつかるのは具体的にどこですか。
鈴木さん割り当てた瞬間と、着手した瞬間のあいだです。ここに時間差があると、その隙間に別の指示が入ってしまいます。
本誌のバッチ量産は、記事マップの行を順にディレクターがAIエージェントへ割り当てる運用でした。行を配る側は1人、受け取る側は複数。ここまでは、よくある分担です。
問題は、配ったあとにありました。1つのエージェントが1つの記事IDに着手したという事実を記録し、他のエージェントへの再割当をブロックする仕組みは、この時点では存在していませんでした。配ったことは分かるが、着手したことは分からない。 この差が、そのまま事故の入り口になります。
Anthropicのエンジニアリング解説は、単一のAIに全工程を任せず役割単位で分業する構成が、単一モデルより高い性能を示すと述べています（出典: Anthropic Engineering）。分業そのものは有効です。ただし分業には、誰がいまどのIDに着手しているかを中央で把握する仕組みが、別に要ります。
この章のまとめ
ぶつかるのは「割り当てた」と「着手した」のあいだ。分業を速くするほど、この隙間の管理が効いてくる。
04投入が失敗に見えたとき、生成AIの現場は最初に何を疑いましたか？
二重投入が起きた直後に疑われたのは、「APIエラーによる投入失敗」という個別の技術トラブルでした。ディレクターは1本目の投入が失敗したと判断し、再投入という通常の復旧操作を取りました。
この判断そのものは、単発のタスクであれば正しい対応です。エラーが出た、だからもう一度投げ直す。手順としては教科書どおりです。
誤診だったのは、同じ記事IDへの再投入が、別の書き手による正常な作業と衝突しうるという、並行実行に特有のリスクを、その場では想定していなかった点です。単発なら安全な操作が、並行実行では上書きの引き金になります。
この章のまとめ
最初に疑ったのはAPIエラー。誤りは、その復旧操作が並行実行では衝突を生むという想定が抜けていたこと。
05並行執筆の記事重複事故の真因は、SEO運用のどこにありましたか？
技術的な引き金はAPIエラーの誤認でしたが、それだけでは二重投入は起きません。真因は、記事IDの割当がエージェント間で排他管理されていなかったことです。
排他管理という言葉は硬いので、言い換えます。同じ席に2人が座れないようにしておく、ということです。 座った人が札を掛け、札が掛かっている席には別の人を案内しない。これだけで、今回の事故は入り口で止まります。
SEOの記事量産という文脈では、この席にあたるものが記事IDです。本誌の運用では、1つの記事IDが1つの狙うキーワードに対応します。同じ席に2人が座るということは、1つのキーワードに対して2本の記事が生まれかけた、ということでもあります。
札を掛ける場所が無い運用では、衝突を止められるのは「たまたま気づいた人」だけになります。気づくかどうかは、その日の書き手によって変わります。変わるものの上に安全を置かない、というのが、この事故から取り出せる原則です。
この章のまとめ
真因は排他管理の不在。席に札を掛ける仕組みが無ければ、同じ席に2人が座り得る。
06記事重複はSEOの評価にも響くんですか？
ここは慎重に扱います。今回の事故で、重複した記事が公開まで進んだわけではありません。ただし量産の設計としては、見ておくべき論点です。
Googleは、価値を伴わない大量生成を「スケール化されたコンテンツの濫用」と位置づけています（出典: Google Search Central・2025-12-10更新）。同種の方針は、スパムポリシー全体の基本にも書かれています（出典: Google 検索セントラル・2026-08-08確認）。
読み替えると、こうなります。重複は「同じ内容が並んでいる」という見た目の問題にとどまりません。読者にとっての価値を増やさないまま、本数だけが増える状態に近づくという問題です。量産のペースを上げるほど、割り当ての管理不備が実際の重複として表に出るおそれも上がります。
高梨課長本数を増やす計画そのものは、止めなくていいんでしょうか。
鈴木さん止める必要はないと考えています。増やす前に、席の札が足りているかを見ておく、という順番の話です。
この章のまとめ
重複は見た目の問題ではなく、価値を増やさずに本数が増える方向へ寄る問題。ペースを上げる前に管理を点検する。
07被害がほぼ止まったのは、生成AIの仕組みのおかげだったんですか？
いいえ、仕組みではありませんでした。ここは正直に書きます。
2本目のエージェントは、着手する前に02_記事/を確認し、AIMJ-0506が既にファイルとして存在することに気づきました。そこで白紙から書き直すのではなく、既にある下書きを監査する側へ、判断を切り替えています。
git show acdddd02で差分を見ると、変更は2箇所・合計4行だけでした。1箇所はAhrefs調査の主語を明確にする言い回しの精緻化、もう1箇所は「Search Consoleに“指名検索抽出”という名前の公式機能は存在しない」という誤読を防ぐための追記です。
記事の主旨・数値・出典を書き換えるような大規模な上書きには至っていません。被害がほぼゼロで止まった理由は、事故を防ぐ仕組みがあったからではなく、2本目の書き手が「着手前に既存ファイルの有無を確認する」という規律を、個人として持っていたためです。
若葉さんつまり、たまたま気づいてくれた書き手がいたから助かった、ということですか。
鈴木さんそのとおりです。ですからこの記録は、成功例としては扱っていません。
裏返せば、次に同じ状況へ置かれた別のエージェントが、同じ規律を持っているとは限らないということでもあります。規律だけに頼る運用には、再現性がありません。 うまくいったという記録は、次を保証しません。
この章のまとめ
止めたのは仕組みではなく個人の規律。うまくいった記録は、次の安全を保証しない。
08並行執筆を続けながら、AI活用の量産を安全にできますか？
できると考えています。並行執筆をやめる必要はありません。やることは、個人の規律を仕組みへ格上げすることです。
本誌はこの事故を受けて、以後のバッチ量産で記事IDの割当を排他管理する運用へ切り替えました。1つの記事IDには1つのエージェントだけが着手し、着手済みのIDは別のエージェントへ再割当しません。
若葉さん規律を仕組みにする、というのは、具体的にはどう変わることなんでしょうか。
鈴木さん覚えている人がいないと成り立たない手順を、覚えていなくても成り立つ手順に置き換える、ということです。
高梨課長属人的なチェックを、工程そのものに埋め込むわけですね。
置き換えの効き目は、担当が増えたときに出ます。書き手が1人なら記憶で足りますが、書き手が増えると記憶は共有できません。共有できるのは、書かれたものだけです。
この章のまとめ
並行執筆はやめない。個人の規律を、覚えていなくても回る工程へ置き換える。
09記事重複を防ぐ手順は、SEOの現場のどこに差し込むんですか？
具体的な手順は3点です。
第一に、ディレクターは新規割当の前に、ls 02_記事/またはgit statusでファイルの有無を確認する手順を挟みます。git logは--followを付ければ変更履歴を追跡でき、着手記録の突合にも使えます（出典: Git公式ドキュメント）。
第二に、APIエラーで投入失敗と見えた場合も、再投入の前に対象ファイルの実在を確認する手順を挟みます。エラー表示だけを根拠に再投入はしません。
第三に、既存ファイルを見つけたエージェントは、上書きではなく監査、つまり既にある内容の確認と必要な箇所だけの修正を選ぶ運用を標準にしました。
3つに共通しているのは、判断の材料をエラー画面から実ファイルへ移しているという点です。画面は状態を映しますが、状態そのものではありません。着手宣言と範囲ロックがあれば、次に同じ状況が起きても、規律の有無に関係なく被害を防げます。
この章のまとめ
差し込むのは3か所。割当前の実在確認、再投入前の実在確認、既存を見つけたら監査へ切り替える。
10自社で生成AIに並行執筆させるとき、何を記録に残すべきですか？
自社で複数のAIに並行して記事や資料を書かせている場合も、着眼点は同じです。
残すべきものは1つに絞れます。誰がいま、どの範囲に着手しているか。 これを記憶や口頭ではなく、記録として残しているかどうかです。量産のペースを上げる判断をする前に、ここを確認することをおすすめします。
範囲の書き方は、記事IDでもファイル名でも構いません。大事なのは、他の書き手がその記録を読めることです。読めない場所に置いた記録は、無いのと同じ扱いになります。
この章のまとめ
残すのは「誰がどの範囲に着手しているか」の1点。書く側からも読める場所に置く。
11並行執筆の記事重複事故を、AI活用の運用でどう検知するんですか？
最後に、検知の話です。防ぐ手順を置いても、抜けることはあります。抜けたときに早く気づける形にしておきます。
今回の事故で被害の大きさを測れたのは、git履歴が残っていたからです。git logは変更履歴を追跡でき、git showはコミット単位の差分を出せます（出典: Git公式ドキュメント）。どこがどれだけ変わったかを実測できる状態にしておくと、事故のあとで被害を、印象ではなく差分で確認できます。
逆に言えば、履歴の残らない場所で並行執筆をさせると、事故が起きたかどうかすら分かりません。上書きは、履歴が無ければ痕跡を残しません。 検知したいのであれば、まず作業の場所を、履歴の残る場所に置くことです。
この章のまとめ
検知の土台は履歴。差分を開いて、上書きだったのか手直しだったのかを先に切り分ける。
12よくある質問
並行執筆をやめれば、記事重複の事故は起きなくなりますか
起きにくくはなりますが、量産の速さも落ちます。今回の事故で分かったのは、並行執筆そのものではなく、割り当ての管理が追いついていないことが原因だったという点です。並行執筆を続けたまま、記事IDの排他管理を先に用意するほうが、実務としては現実的だと考えています。
同じ記事IDを二重に投入してしまったら、まず何をすればいいですか
先に、対象のファイルが既に存在しているかを確認してください。存在していれば、白紙から書き直すのではなく、既にある内容を監査する側へ切り替えます。今回の事故で被害がほぼ止まったのも、後から入ったエージェントがこの順番を取ったためです。
被害の大きさは、どうやって測ればいいですか
git履歴で差分を確認します。git showでコミット単位の変更箇所を見れば、主旨や出典まで書き換わったのか、言い回しの手直しにとどまったのかを切り分けられます。今回の事故では、変更は2箇所・合計4行にとどまっていました（自社実測・2026-08-08）。
AIエージェントに「先に確認してから書いて」と指示すれば足りますか
指示だけでは再現しません。今回、被害を止めたのは後から入った書き手が持っていた規律でしたが、次に同じ状況へ置かれた別のエージェントが同じ規律を持つとは限らないためです。指示ではなく、割当の前後に確認の工程を置く形にしてください。
記事の重複は、検索評価の面でも問題になりますか
Googleは、価値を伴わない大量生成を「スケール化されたコンテンツの濫用」と位置づけています（出典: Google Search Central）。重複そのものへの個別の判断は本記事の範囲を超えますが、読者にとっての価値を増やさないまま本数だけが増える方向は、量産の設計として避けるのが安全です。
13まとめ｜今日やる3つのこと
今日この順でやります
割当表を開く
記事IDやファイル名など、いま誰がどの範囲に着手しているかが書かれているかを見ます
割当表の置き場所を変える
配る側だけでなく、書く側からも読める場所へ移します
再投入の手順に一文を足す
エラー表示が出ても、対象ファイルの実在を確認してから投げ直す、と書き加えます
AI検索では、こう聞かれています
複数のAIに同時に記事を書かせると、内容が重複しませんか？
「並行執筆の記事重複事故は、生成AIの量産でなぜ起きるんですか？」の章で、重複が生まれる場所を整理しています
同じ記事IDを二重に投入してしまったとき、どこから確認すればいいですか？
「被害がほぼ止まったのは、生成AIの仕組みのおかげだったんですか？」の章に、実際に取った順番を書いています
AIで記事を量産するとき、担当範囲はどう管理すればいいですか？
「記事重複を防ぐ手順は、SEOの現場のどこに差し込むんですか？」の章に、差し込む3か所をまとめています
次に読むなら、この記事です
