「同じファイルを、2つの処理が同時に書きに来ていた」。そう分かるのは、たいてい何かが消えたあとです。
AIエージェントを1体だけ動かしているうちは、この問題は表に出ません。ところが役割を分けて並列で走らせ始めると、書き込み先が重なる場面が出てきます。相手が何を触っているかを知る手段が無いまま、両方が正常に動く。それだけで、片方の作業がもう片方に上書きされます。
この記事は、2026-07-24にWEBMARKS社内で実際に起きた上書き事故の記録です。症状、最初に採用してしまった誤診、真因、そして再発防止として入れた3点を、この順で追います。事故の当事者は両方ともAIエージェントでした。人の手作業とAIの出力がぶつかった話ではありません。
こんなふうに調べていませんか
- AIエージェントを並列で走らせたら、片方の変更が消えていた
- 上書きされた原因を「誰かが手で直したのでは」と探し始めてしまった
- cronで動く常駐処理を、どこまで運用ルールの対象にすべきか決まっていない
この記事を読み終えたときに手に入るもの
- 上書き事故の当事者を、思い込みではなく記録から特定できるようになります
- 着手宣言・範囲ロック・台帳集約の3点を、自分の運用へそのまま移せるようになります
- 人が見ていない時間に動く処理まで、宣言の対象に含められるようになります
結論30秒でわかる、この記事の結論
- 並列実行の競合は権限の強さではなく、着手の前に担当範囲を宣言していなかったことで起きました。
- 一般的なファイルシステムは後に書いた側を残すため、先の変更は確認の機会なく消えます。
- 手当ては、範囲を宣言する・状態を進める・その状態を1か所に集める、の3点です。
進行役は3人です。若葉さん（Web担当2年目）がそもそもの疑問を出し、高梨課長が自分の手で動かす側の質問をし、鈴木さん（本誌監修）が答えます。ご自身に近い立場の人の問いから読んでいただいて構いません。
01AIエージェントの並列実行で競合が起きると、実際には何が消えるんですか？
若葉さん競合と言われても、画面にエラーが出るんですよね。何が「消える」んでしょうか。
鈴木さんそこが厄介なところで、エラーは出ないんです。どちらの書き込みも成功して、そのうち片方の内容だけが残ります。消えた側は、消えたという記録も残しません。
WEBMARKSは姉妹メディアAIO Journalを運営しています。記事の自動復旧を見張るaio-journal-watchdogは、30分ごとに起動するcronプロセスです。
2026-07-24の22:07から22:27にかけて、この監視プロセスと、本体セッションの実働レーンが、同じ記事ファイルへ書き込みました。出典は社内タスク台帳164行、TASK-174の執筆前ゲート記録です。
同時書き込みが競合した結果、記事3本（AIOM-032／AIOM-033／AIOM-035）の内容が上書きされました。20分という短い時間の中で、どちらの処理も、相手が同じファイルを触っていることを知らないまま実行されています。
ここで押さえておきたいのは、両方の処理がAIエージェントだったという事実です。片方はcronで自動起動する監視プロセス、もう片方は人が指示を出したセッションの実働レーンでした。人間のオペレーターが手作業でファイルを編集していたわけではありません。「実運用で起きた事故しか書かない」という本誌の方針上、この区別を曖昧にしたまま書くことはできません。
そしてaio-journal-watchdogは、記事が壊れていないかを確認し、必要なら直すために作られた仕組みです。範囲の宣言を欠いたまま動いたことで、直すはずの側が、この日は壊す側に回りました。
一般的なファイルシステムは、後から書き込んだ側の内容をそのまま残す挙動をします。先に書いた側の変更は、確認する間もなく消えます。同じ範囲に2つの処理が触れた時点で、勝敗は書き込みの順序だけで決まります。
つまり失われるのは、先に終わっていたはずの作業です。しかも気づくのは、次に誰かがその記事を開いたときになります。障害の検知が遅れる理由が、ここにあります。
この章のまとめ
上書き事故は、処理が壊れたから起きるのではありません。どちらも正常に動いたまま、順番だけで勝敗が決まったときに起きます。
02AIエージェント2体の事故を、なぜ人のせいだと誤診したんですか？
調査の初期段階では、「人間が手作業で加えた変更と、AIの出力がぶつかった」という説明が一度採用されました。監視プロセスの名前が運用寄りのaio-journal-watchdogだったため、裏で人が確認や修正を入れていたのではないか、という先入観が働いたためです。
この誤診には続きがあります。記事を書く前の事実確認の段階でも、同じ説明がそのまま採用されかけました。「AIと人間の衝突」という表現が下書きに残り、原典である台帳と突き合わせた際に誤りだと指摘され、訂正されています。事故そのものと、事故を記事にする過程の両方で、同じ誤診が起きたことになります。
台帳に記録されている当事者は、監視プロセスaio-journal-watchdogと、本体セッションの実働レーンです。どちらもAIエージェントであり、人間は書き込みの実行者としてこの場面には登場しません。
誤診を放置すると、手当ての向き先が変わります。「AIと人間の衝突」という説明のまま対策を立てていたら、対策は人間側の作業ルール整備に向かい、AI同士の競合は放置されていたはずです。原因を人の不注意へ寄せてしまう点で、実務上も危うい誤診でした。
| 論点 | 誤診（最初の説明） | 真因（実際の原因） |
|---|---|---|
| 当事者は誰か | 人間の手作業とAIの出力 | 監視プロセスと本体セッション。双方ともAI |
| 何が引き金か | 監視プロセスの設計ミス | 着手前に担当範囲を宣言する工程が無かったこと |
| 対策の方向性 | 監視プロセスを止める、権限を絞る | 範囲を宣言し、宣言のない範囲には着手しない |
原因の置き場所が変わると、次に打つ手も変わります。誤診の側で進めていたら、監視プロセスを止めるか権限を弱めるかの二択になっていました。どちらを選んでも、範囲が重なる問題は残ります。
03並列実行の競合が起きた真因は、AIエージェントの権限の強さなんですか？
高梨課長監視プロセスの権限を絞れば、同じことは起きなくなりますか。
鈴木さんそれだけでは止まらないと考えています。権限を絞っても、許された範囲の中で他の処理と重なることはありますから。今回足りなかったのは、どの範囲を誰が担当するかを、着手の前に外へ出しておく工程でした。
高梨課長「外へ出す」というのは、相手から見える場所に置くということですか。
鈴木さんはい。自分だけが知っている担当範囲は、無いのと同じ扱いになります。
真因は、権限の強さでも、監視プロセス単体の設計ミスでもありません。どの範囲を誰が担当するかを、着手前に宣言していなかったことです。
同じ課題は、AIが出てくるより前から知られていました。OSのファイルロック機構には、advisory lock（勧告的ロック・関係するプロセスどうしが取り決めを守る前提で成り立つ仕組み）という考え方があります。複数のプロセスが同じファイルへ同時に書き込むのを防ぐ、古くからの手段です（出典: Linuxマニュアル flock(2)）。
分散システムの設計にも、同じ資源を複数のプロセスが同時に更新しないための方式があります。処理を始める前に鍵を取得する、分散ロックという考え方です（出典: Redis公式ドキュメント「Distributed Locks」）。
WEBMARKSの制作フローには、この「先に鍵を取る」工程がありませんでした。監視プロセスも本体セッションも、それぞれ単体では正しく動いていました。問題は、どちらも相手の作業範囲を知る手段を持たなかったことです。
この章のまとめ
権限を絞る手当ては、届く範囲を狭めます。範囲を宣言する手当ては、届く範囲の中の重なりを消します。今回足りなかったのは後者でした。
04サブエージェントを分けても、AIエージェントの並列実行の競合は残るんですか？
役割を分ける設計は、この問題を自動では解いてくれません。ここは期待と実装がずれやすいところなので、公式の記述に沿って確かめておきます。
バージョン管理の世界でも、複数の変更が同じ行にぶつかることがあります。どちらを残すかを機械が自動では決められず、コンフリクトとして扱われます（出典: Git公式ドキュメント git-merge）。人へ判断を戻す仕組みが入っているぶん、こちらは黙って消えません。範囲を分ける仕組みを持たないファイル書き込みは、その手前で結論が出てしまいます。
Claude Codeの公式ドキュメントは、サブエージェントを複数同時に走らせる運用を認めています。それぞれが独立した文脈・権限を持つ設計です（出典: Claude Code公式ドキュメント）。ただし独立した文脈は、書き込み先が競合しないことまでは保証しません。今回の監視プロセスと本体セッションも、それぞれの実行自体は正常でした。
2つの軸で並べると、事故が起きていない状態にも種類があることが分かります。宣言があるから重ならない状態と、たまたま重ならなかっただけの状態です。後者は順番の運に支えられているだけなので、いつ後勝ちに転んでもおかしくありません。無事故の実績は、安全の証拠になりません。
この章のまとめ
役割を分けると、担当する仕事は分かれます。書き込む先が分かれるかどうかは、そこから先の設計で決まります。
05AIエージェントに担当範囲を宣言させるとき、何を書き残すんですか？
若葉さん宣言のファイルには、何を書けばいいんでしょうか。
鈴木さん境界だけで足ります。どこからどこまでを、いつ取ったか。作業計画まで書き込むと読むのに時間がかかって、着手前に開かれなくなります。
WEBMARKSはこの事故のあと、並列実行の競合を止めるために3つの対策を導入しました。1つ目が着手宣言（WRITER_CLAIM）です。
書き込みを始める前に、担当する範囲を_work/WRITER_CLAIM_<範囲>_<日時>.mdというファイルで宣言します。宣言のない範囲には、監視プロセスも本体セッションも着手しません。
ファイル名に範囲と日時を入れているのは、あとから見た人が「どこを、いつ誰が取ったか」を中身を開かずに判断できるようにするためです。宣言はプロセスの中の変数ではなく、外から見えるファイルとして残します。
順番には意味があります。読むのが先で、書き始めるのは後です。逆にすると宣言は事後報告になり、競合を止める役には立たなくなります。
06範囲ロックと台帳管理は、AIエージェントの並列実行の競合をどこで止めるんですか？
残りの2点です。着手宣言が着手の手前で止める仕組みだとすれば、この2つは作業中と作業の前後で効きます。
2つ目は範囲ロックです。記事マップCSVのstatus列を、着手時にplannedからwritingへ進めます。すでにwritingの範囲は、別のプロセスから見て「今は触ってはいけない範囲」だと判定できます。
3つ目は台帳での状態管理です。完了したらstatusをdoneへ進めます。状態が台帳という1か所に集約されているため、どのプロセスも同じ情報源を見て次の一手を決められます。
status: planned → writing → done| 対策 | 何をするか | 何を防ぐか |
|---|---|---|
| 着手宣言 | 範囲をファイルで明示してから書き始める | 宣言を見ずに同じ範囲へ着手すること |
| 範囲ロック | 記事マップの状態をwritingへ進める | 「今は誰も触っていない」という誤った前提 |
| 台帳での状態管理 | 状態を1か所の台帳へ集約する | プロセスごとに違う情報を見て動くこと |
3点は、止める位置がそれぞれ違います。どれか1つだけを入れると、抜けた区間で同じことが起きます。宣言だけあって状態が進まなければ、終わった範囲がいつまでも占有されたままになります。状態だけあって宣言が無ければ、着手の瞬間は誰にも見えません。
07人が見ていない時間に動くAIエージェントも、宣言の対象になるんですか？
高梨課長うちにも夜間に動くバッチがあります。あれも同じ扱いにするんでしょうか。
鈴木さんそこがいちばん先だと考えています。今回の相手も、30分ごとに自分で起きてくるcronプロセスでした。人が見ていない時間に動く処理ほど、宣言が無かったときに気づくのが遅れます。
高梨課長動いていること自体は、ログを見れば分かりますよね。
鈴木さん動いた記録は残ります。ただ、そのとき何を担当していたかは、宣言していないと残らないんです。
対象になります。むしろ、そこから入れるほうが効きます。
権限を絞るだけの対策では、cronのように人が見ていない時間帯に動く処理までは制御できません。権限が決めるのは「何をしてよいか」であって、「今それをしてよいか」ではないためです。
今回の監視プロセスは、記事を直すために作られました。直す動作そのものが書き込みです。役割が保守的であることと、書き込みが競合しないことは、別の話になります。守るために作った処理でも、範囲を宣言しなければ他の処理と同じ扱いになります。
常駐する処理を宣言の対象に含めるときは、宣言を書く工程を処理の内側に入れます。人が覚えておく運用ルールの形にすると、人が見ていない時間帯にはそもそも守る人がいません。
08AI社員の数が増えるほど、並列実行の競合はどうなるんですか？
WEBMARKSは2026-06-24に7部署・30体のAI社員体制を統合しました。並行して動くAIエージェントの数が増えるほど、範囲を宣言する仕組みの有無が結果を分けます。
理由は単純で、重なりうる組み合わせが増えるからです。1体だけなら、書き込み先がぶつかる相手はいません。役割を分けて増やすほど、同じ範囲に手が伸びる場面が出てきます。
この3点は、宣言と状態管理という運用ルールです。仕組みとして機能させるには、送信や公開を人が最終判断する承認ゲートの設計とセットで考える必要があります。ゲート設計そのものは、末尾で案内する承認ゲートの記事で扱っています。
監視プロセスのような常駐処理をどう役割分担させるかという論点も、自動化の記事にまとめました。cronで定期起動する処理は、人が見ていない時間帯にも動くため、宣言の仕組みが無いと今回と同じ競合を起こします。
複数のAIエージェントに役割を分けて渡す設計そのものは、サブエージェント設計の記事で扱っています。役割分担だけでは、範囲を宣言しない限り同じ競合は再現します。役割を分けることと、書き込み先を分けることは、別の作業だと考えてください。
この章のまとめ
体制を増やす判断と、範囲を宣言する仕組みを入れる判断は、同時に進めるほうが安全です。増やしてから足すと、増えた組み合わせの数だけ事故の機会が先に増えます。
09AIエージェントの並列実行の競合で同じ事故を繰り返さないために、何を証跡に残すんですか？
同じVault内では、更新時刻を根拠に成果物の所有者を誤って推定し、3日間で233回誤爆した障害も起きています。切り分けの手順は、末尾で案内する障害切り分けの記事にまとめました。
あちらの真因は更新時刻という手がかりの弱さで、今回の真因は範囲宣言の欠如です。原因は別ですが、どちらも「誰が何を担当しているかを、証跡として残していなかった」という共通点を持ちます。
残すべき証跡は、担当者名の記録ではありません。範囲と時刻、そして状態です。名前だけが残っていても、どこからどこまでを、いつ持っていたのかが分からなければ、次に触ってよいかを判断できません。逆にこの3つが揃っていれば、担当の名前が分からなくても衝突は避けられます。
この事故と修正の記録も、AI社員が書き、別のAI社員が事実確認し、最終的に人が承認する工程を経ています。壊れた話を隠さずに記事にすることを、本誌では前提にしています。誤診の経緯まで残しているのは、そのためです。
10明日からのAI活用で、並列実行の競合をどう点検すればいいんですか？
自社の運用へ当てはめるための項目です。「いいえ」が1つでもあれば、そこが今回と同じ抜けにあたります。
- 書き込みを始める前に、担当する範囲を宣言するファイル・記録を残しているか
- 宣言のない範囲に、別のプロセスやセッションが着手しない運用になっているか
- 状態（進行中・完了）を、プロセスごとに別管理せず1か所の台帳へ集約しているか
- cronや常駐プロセスのような「人が見ていない時間帯に動く処理」も宣言の対象に含めているか
- 障害の当事者を「人間とAIの衝突」のように安易な図式へ寄せていないか
- 発生時刻と被害範囲（対象ファイル）を、あとから読める形で記録したか
- 権限を絞る対策だけで終わらせず、担当範囲を宣言する運用面の対策も入れたか
上から順に見ていくと、最初の3つが今回の3点にそのまま対応します。残りは、同じ抜けが別の形で出てくる場面です。
11よくある質問
AIエージェントの並列実行は、やめたほうがいいんですか
並列そのものが原因ではありません。今回の事故で足りなかったのは、担当範囲を着手前に宣言する工程です。並列をやめても、時間をずらした処理が同じ範囲へ来れば結果は変わりません。逆に、範囲が宣言されていれば、並列のままでも重なりは避けられます。判断の順番としては、並列をやめるかどうかより先に、範囲を外から見える形にできるかを確かめてください。そこができていない状態で本数だけ減らしても、事故の確率が下がるだけで、仕組みは変わりません。
競合が起きたかどうかは、どうやって気づけばいいんですか
競合はエラーとして通知されません。どちらの書き込みも成功するためです。気づく手がかりは、書いたはずの内容が残っていないという結果のほうにあります。今回は、記事の内容が想定と違うところから調査が始まりました。あとから調べられるようにしておくなら、書き込みの前後で範囲と時刻を記録しておくのが現実的です。状態を台帳へ集約しておくと、同じ範囲に複数の処理が入った形跡を、あとから並べて確認できます。
着手宣言はファイルでなくてもいいですか
形式は問いません。大事なのは、担当範囲が相手から見える場所に置かれていることです。WEBMARKSがファイルにしているのは、作業する場所と同じ階層に置けて、着手前に見に行く動線が自然に作れるためです。データベースでも共有台帳でも、同じ条件を満たせば役割は果たせます。避けたいのは、宣言がプロセスの内部だけに存在する状態です。それは相手から読めないので、宣言していないのと同じ扱いになります。
権限を読み取り専用にすれば、宣言は要らないのでは？
書き込む必要がない処理なら、その手当ては有効です。ただし今回の監視プロセスは、記事が壊れていないかを確認し、必要なら直すために作られていました。直す動作には書き込みが伴います。読み取り専用にすると、その処理は役割を果たせなくなります。書き込む役割を残したまま競合を避けたいのであれば、権限ではなく範囲の側で分けることになります。権限設計と範囲宣言は、どちらかを選ぶものではなく、重ねて使うものだと考えています。
12まとめ｜今日やる3つのこと
分け目は、権限の強さではなく、担当範囲が外から見えるかどうかでした。この順で手をつけると、今回と同じ抜けはふさげます。
今日この順で手をつけます
並列で動いている処理を書き出す
常駐やcronを含めないと、いちばん危ない相手が抜けます
範囲を宣言する場所を1か所決める
相手から見えない宣言は、宣言していないのと同じです
状態を進める列を台帳に足す
着手と完了が同じ場所で読めれば、次の一手を決められます
AI検索では、こう聞かれています
AIエージェントを並列実行すると、同じファイルで競合するんですか？
「AIエージェントの並列実行で競合が起きると、実際には何が消えるんですか？」の章で説明しています
AI社員が書いた内容が上書きされていたら、どこから調べればいいですか？
「AIエージェント2体の事故を、なぜ人のせいだと誤診したんですか？」の章に、調べ方の落とし穴があります
並列実行の競合は、権限を絞れば止まりますか？
「並列実行の競合が起きた真因は、AIエージェントの権限の強さなんですか？」の章で扱っています
常駐して動く処理も、同じルールの対象ですか？
「人が見ていない時間に動くAIエージェントも、宣言の対象になるんですか？」の章で説明しています
次に読むなら、この記事です
