「同じ記事に、2つの手が同時に伸びていました」。並行して動かしているAIエージェントの話をしていると、この報告が出ます。
役割の分け方そのものは、たいてい決まっています。誰が何を担当するかは書いてある。それでも、同じ対象へ手が重なる一瞬だけは、役割表のどこにも書かれていません。
この記事は、その一瞬を止めるための着手宣言を扱います。素材は、運営元WEBMARKSで実際に起きた出来事と、公式資料5件です。
こんなふうに調べていませんか
- 並行して走らせたら、片方が書いた成果がもう片方に上書きされていた
- 権限は絞った。ロックも掛けた。それでも二重着手が止まらない
- 宣言のルールを作りたいが、何をどこまで書かせるか決めきれない
この記事を読み終えたときに手に入るもの
- 権限設計とロックが届く範囲と、届かない範囲を線引きできるようになります
- 着手前に名乗らせる3点を、自社の作業単位に合わせて書けるようになります
- 宣言の置き場所と粒度を、確認する側の人数から選べるようになります
結論30秒でわかる、この記事の結論
- 重ならないようにする要は、権限でもロックでもありません。手を出す前に、対象・行為・時間を外から見える場所へ置くことです。
- 権限とロックは、実行主体が1つに決まっている内側でだけ働きます。セッションやエンジンをまたぐと届きません。
- 宣言は、作ることと、全員が読むことと、期限を切ることが揃って初めて働きます。
進行役は3人です。高梨課長が手を動かす側から、大森部長が体制を決める側から聞き、鈴木さん（本誌監修）が答えます。
01AIエージェントに作業分担を渡すと、重複防止はどこで崩れるんですか？
高梨課長役割は分けました。担当も決めました。それでも同じ対象に手が重なると聞きます。どこが抜けているんでしょう。
鈴木さん道路工事の掲示板に近いと思っています。どの班がどの工事をするかは決まっている。でも「いまこの区間を掘っています」という掲示が出ていないと、隣の班が同じ場所を掘ります。
結論から書きます。
- 権限設計とロックは、同じ実行主体の内側でしか効きません。セッションをまたぐ処理、エンジンをまたぐ処理、人が見ていない時間に動く処理には届きません。
- 名乗らせる項目は3つです。どこに手を付けるか、読むだけか書くのか、いつまで手を付けるか。
- その名乗りは、ほかの実行主体から読める場所に置いて初めて働きます。特定のエンジンやセッションの内部機能に置くと、外側からは見えません。
Anthropicは、性質の異なる仕事を専用の処理へ振り分けるRouting（振り分け）という設計パターンを挙げています。分業によって個々の処理を最適化できると説明しています（出典: Anthropic公式）。ただし、分けたあとに同じ対象が重ならないようにする方法は、この資料の範囲外です。
役職や部署をどう分けるかという組織設計そのものは、AI社員の組織設計｜部署より先に決める3点と確かめ方で扱っています。ここでは、分けた作業がぶつからないための名乗りだけを掘ります。
運営元WEBMARKSも2026-07-24、範囲を宣言しないまま並行実行して記事3本が上書きされる出来事を経験しました。症状と原因はAIエージェント並列実行の競合｜上書き事故を止める3点にまとめています。
02権限設計やファイルロックだけでは、AIエージェントの二重着手はなぜ止まらないんですか？
権限を絞る設計は、担当外の操作を拒否できます。ファイルロックも、同じプロセスが同じ対象を同時に開くことを防げます。どちらも、実行主体が最初から1つに決まっている前提で働きます。
崩れるのは、その前提が成り立たない場面です。Claude Codeのサブエージェントは、専用のコンテキストウィンドウと権限を持ちますが、1つのセッションの中で動く仕組みです（出典: Claude Code公式）。セッションをまたぐと、この仕組みは及びません。片方が何に着手しているかは、もう片方からは見えないままです。
cronのような定期実行も同じです。人が見ていない時間帯に自分で起動するため、権限設計だけでは「いままさに誰かが触っている」という事実を共有できません。
| 仕組み | 防げること | 防げないこと |
|---|---|---|
| 権限設計 | 担当外のファイル・操作への書き込み | 担当内の対象に、別の実行主体が同時に手を出すこと |
| ファイルロック | 同一プロセス内での二重オープン | セッションをまたぐ、エンジンをまたぐ二重着手 |
| 着手範囲の宣言 | 実行主体が違っても、対象が重なっているかを事前に確認できる | 宣言そのものを確認しない運用にしていること |
積み上げて置き直すと、表では見えないものが1つ見えます。3つは並列の選択肢ではなく、届く距離が違うという関係です。いちばん内側は同じプロセス、その外が同じセッション、いちばん外がセッションもエンジンもまたぐ範囲になります。
距離の外側で起きたことは、内側の仕組みからは異常として観測されません。止まらなかったのではなく、そもそも見えていなかったという言い方のほうが正確です。
この章のまとめ
権限とロックには、届く距離が決まっています。距離の外で起きる二重着手は、名乗りを通してしか見えません。
03書き込みが競合したとき、AIエージェントの作業はどこで止まるんですか？
バージョン管理の世界には、自動で解決できない変更をそのまま確定させない仕組みがあります。Gitのマージは、競合が自動で解決できないとその時点で処理を止めます（出典: Git公式ドキュメント git-merge）。ファイルシステムへの直接書き込みには、この「止まる」仕組みがありません。後から書いた内容がそのまま残り、先に書いた内容は確認する間もなく消えます。
並べると、違いは強さではなく気づける形になっているかだと分かります。片方は止まったこと自体が合図になり、もう片方は何も起きなかったように見えます。
止まる道具と止まらない道具が、同じ作業の中に混ざっている点が厄介です。片方が競合を見せてくれるので、もう片方も見せてくれると錯覚します。
権限とロックが無意味という話ではありません。名乗りという一段手前の仕組みと重ねて、実行主体をまたいだ重なりが初めて防げます。
04AIエージェントの作業分担で、重複防止のために何を宣言すればいいんですか？
名乗らせる項目は3つです。どこに手を付けるか（対象）、何をするか（行為）、いつまで手を付けるか（時間）。1つでも欠けると、読む側が判断を誤ります。
対象だけあって行為が無いと、見に行っただけの処理と書き換えた処理を区別できません。行為だけあって時間が無いと、終わった名乗りが残り続けます。時間だけあって対象が粗いと、重なっていないのに待たされます。
置きかえてみると、3点が別々の役割を持っていることが分かります。区間の表示は重なりを見るため、工事内容の表示は驚かせないため、掲示期間は撤去のためにあります。どれか1つを落としても、残り2つが肩代わりしてくれないのがこの3点の性質です。
対象が曖昧なまま並べると、行為と時間を書いても重なります。Anthropicは、委譲するタスクに明確な境界を与えないと、複数のサブエージェントが同じ調査を重ねて行うと報告しています（出典: Anthropic公式）。半導体不足を調べる依頼で、1体が2021年の危機を調べる一方、残り2体が2025年時点のサプライチェーンを重ねて調べた例を挙げています。
05読むだけのはずのAIエージェントが書き込んだとき、何が抜けていたんですか？
2026-07-28 11:13、読んで返すだけの指示で走らせた調査系のサブエージェントが、指示していない図解SVG（5,333バイト）を生成して保存しました。名乗られていた行為は「読んで返すだけ」でしたが、実際の行為は書き込みでした。
生成物そのものは中身を検証したうえで採用しています。直したのは指示の側で、以後は調査系の依頼に「ファイルを作らない」という行為の一行を明記しました。
前後で入れ替わったのは、できることの範囲ではありません。受け取る前に食い違いが分かるかどうかです。行為が書かれていない依頼は、成果物を開くまで正しかったのか確かめられません。行為が書かれていれば、走らせる前に照らし合わせられます。
行為を分ける発想は、Claude Codeの設計にも表れています。組み込みのサブエージェントExploreは、読み取り専用のツールだけを持ち、WriteとEditの実行を拒否されます（出典: Claude Code公式）。対象だけでなく行為も宣言の対象になることを、公式の実装が裏づけています。
06宣言に期限を付けないと、AI社員の作業分担はどこで詰まるんですか？
高梨課長期限まで書かせるのは、正直やりすぎに見えます。終わったら消せばいいのでは。
鈴木さん消せるときは消えるんです。困るのは途中で落ちたときで、落ちた側は消しに戻ってこられません。待つ側は、理由が分からないまま止まります。
期限が無いと、終わった名乗りがいつまでも残り、後から来た処理を止め続けます。止めているのは作業中の誰かではなく、すでに居ない誰かの置き土産です。
Redis公式ドキュメントは、ロックに有効期限を設定し、確保した側が途中で止まっても最終的に解放される設計を、デッドロックを防ぐ条件として挙げています（出典: Redis公式）。着手の名乗りも、始めた時刻に加えて期限を持たせると、消し忘れが後続を止める事態を避けられます。
持たせる項目は、これくらいで足ります。
range: AGIM-304 # 対象。触ってよい範囲
action: write # 行為。read / write / delete
owner: article-writer # 宣言した実行主体
started: 2026-08-02T10:00
expires: 2026-08-02T12:00 # 期限。消し忘れによる残留を防ぐ流れにして並べると、止まりやすい地点が1つに絞れます。最後の「外す」だけが、作業が終わったあとに起きるからです。前の3つは作業の勢いで進みますが、外す作業には勢いがありません。異常終了すれば、そもそも到達しません。
期限は、この最後の1つを人の記憶から切り離す仕組みです。外し忘れを責める運用より、外し忘れても止まらない形にするほうが長持ちします。
この章のまとめ
名乗りは、置くところまでではなく、外れるところまでを設計します。外し忘れが後続を止めない形にしておきます。
07宣言はどこに置けば、別のAIエージェントからも確認できるんですか？
読む側が見に行ける場所に置いて初めて働きます。実務でよく使う置き場所は2種類です。
1つ目は、宣言専用のファイルを作る方法です。着手前に対象範囲・行為・開始時刻を書いたファイルを、決まった場所に置きます。WEBMARKSはこの形式をWRITER_CLAIMという名前のファイルで運用しています。ファイルの有無を見るだけで判定できるため、確認の手段がどのエンジンのCLIからでも同じになります。
2つ目は、既存の管理台帳に状態の列を持たせる方法です。記事や案件の一覧に「未着手・作業中・完了」のような状態を持たせ、着手時に更新します。宣言のためだけの新しいファイルを増やさずに済み、進捗の一覧性も保てます。
| 置き場所 | 向いている場面 | 確認コスト | 弱点 |
|---|---|---|---|
| ファイル宣言 | 短時間の作業、対象の粒度が細かい場合 | ファイルの有無を見るだけで低い | 消し忘れると宣言が残り続ける |
| 状態列宣言 | 既に一覧・台帳がある対象、粒度が粗い場合 | 台帳を開く手間がかかる | 台帳の更新自体が競合する可能性がある |
| 両方の併用 | 粒度が案件ごとに違う体制 | 2箇所を確認する分だけ増える | 片方だけ更新し、もう片方が古いままになりやすい |
2軸に置き直すと、表には無い軸が1つ増えます。読む側が何人いるかです。表は置き場所の性格を教えますが、どちらを選ぶべきかは教えてくれません。選ぶ手がかりは、対象の細かさよりも、読む側の人数のほうにあります。
読む側が1つしかないなら、どちらでも回ります。読む側が増えるほど、古い記録が残ったままになる確率が上がり、拾い直す手順が要ります。
どちらを選んでも、置き場所を特定のエンジンの内部機能に依存させないことが条件です。内部機能に置いた名乗りは、そのエンジンを使わない実行主体からは読めません。
08宣言の粒度は、AIエージェントの作業分担のどこに合わせるんですか？
大森部長細かく決めるほど安全に見えますが、現場の手間はどうなりますか。
鈴木さんそこは逆向きに壊れます。粗くすると待たされて飛ばされ、細かくすると面倒で省かれる。どちらも、最後は名乗りが読まれなくなるところへ行き着きます。
大森部長では、決め方の基準はどこに置きますか。
鈴木さん成果物の単位に合わせています。1つ作るたびに1つ名乗る形なら、数が勝手に釣り合います。
左右で違うのは強さではなく、壊れる向きです。広げた側は待たされることで、細かくした側は手間が増えることで、同じ場所へ落ちます。名乗りが読まれない状態です。
WEBMARKSは、名乗りの単位を1記事ID（1ファイル）に固定しています。7部署・30体のAI社員体制（2026-06-24統合）のもとで複数の執筆ワーカーが同時に書き進めるため、フォルダ単位では広すぎ、段落単位では細かすぎるという判断です。
| 粒度 | 症状 | 向いている場面 |
|---|---|---|
| 広すぎる | 無関係な作業まで待たされ、宣言を無視する動機が生まれる | 対象が明確に1つしかない小規模な体制 |
| ちょうどいい | 宣言の数と確認の手間が釣り合い、実際に運用され続ける | 1つの成果物（1記事・1ファイル）を単位にする体制 |
| 狭すぎる | 宣言の作成コストが本来の作業を圧迫する | 単位より小さく分割して得をする場面は少ない |
09人が見ていない時間に動く処理も、AIエージェントの作業分担では宣言の対象になるんですか？
大森部長監視のために動かしている処理まで対象にすると、運用が重くなりませんか。
鈴木さん重くはなります。ただ、見張る側が黙って書き換えるほうが厄介でして。誰も見ていない時間に動くものほど、名乗らせておきたいと思っています。
対象になります。同じ対象へ手を伸ばしうる実行主体は、対話しながらの作業だけではありません。
並べてみると、見落としの起きやすさが経路ごとに違うことが分かります。人が起こさない経路ほど、対象から外れやすいという偏りです。画面の前に誰かがいる作業は、異変があればその場で止まります。時計が起こす処理には、止める人がいません。
発火条件も寿命も、層ごとに違います。hooks・定期実行・常駐プロセス・自動復旧という4層の役割分担はAIエージェントの自動化は4層｜着手する順番と稼働の数え方で扱っています。層が違っても、同じ対象に触れる可能性がある限り、名乗りのルールは共通で当てます。
定期実行を対象外にしてしまう理由の多くは、「監視のための処理だから安全」という思い込みです。監視や復旧の処理ほど、本来の作業を壊さないよう、名乗りを読んでから動く必要があります。
10宣言が無視されて二重処理が起きたら、AIエージェントの運用はどこで気づくんですか？
ルールを運用しても、読まない経路が1つでも残れば重なりは起きます。振り分けの誤りを検知する3つのシグナル（手戻り・二重着手・沈黙）はAIエージェントのルーティング設計｜判定表4列と外れを直す5段で扱いました。ここで要るのは、このうち二重着手を直接見つける仕組みです。
検知の基本は、書き込む手前で名乗りの有無を見る一手間です。宣言ファイルなら存在確認、状態列なら値の確認だけで済み、特別な権限は要りません。この一手間を、書き込みを行うすべての経路に共通で入れることが条件になります。
チェックの並びには、意図があります。上から3つは仕組みの話、最後の1つだけが思い込みの話です。手順は書けば増やせますが、見張り役を対象から外す判断は、書き足しでは直りません。
重なったあと、どちらの成果物を正として残すかを決める工程が要ります。この判断は名乗りの範囲外で、対外的に確定する操作と同じ扱いにします。送信・公開・削除の直前で人の判断を挟む仕組みはAIエージェントの承認ゲート｜止める操作4種と3層の選び方で扱っています。復旧の場面でも、残す版を機械に選ばせません。
後始末でもう1つ見落とされやすいのが、名乗りそのものの残留です。異常終了すると名乗りだけが残り、後続を止め続けます。期限を持たせ、期限切れを定期的に拾って消すところまでを後始末に含めます。
この章のまとめ
検知は難しい仕組みを要しません。書き込む手前の一手間を、全経路に同じ形で置けるかどうかです。
11着手宣言を入れたのに崩れるのは、AIエージェントの重複防止で何が抜けているんですか？
1つ目は、作る側だけが守り、読む側が見ていないことです。名乗りを律儀に置いても、着手前に読む手順が無ければ、誰にも読まれない記録に終わります。
2つ目は、粒度を作業ごとに変えてしまうことです。ある作業は記事単位、別の作業はフォルダ単位で名乗ると、読む側は毎回粒度を判断しなければならず、機械的な確認ができなくなります。
3つ目は、期限を持たせず、消し忘れたままにすることです。期限のない名乗りは、置いた側が止まったあとも残り続けます。Redis公式ドキュメントが有効期限を生存性の条件に挙げているのは、この種の残留を防ぐためです（出典: Redis公式）。
3つに共通するのは、仕組み自体は入っているのに、運用のどこかで輪が閉じていない点です。置くことと、読むことと、切れることの3つが揃って、初めて働きます。
12よくある質問
着手宣言は、AIエージェントが1体しかいなくても要りますか
1体だけの体制でも、定期実行や自動復旧のような別の実行主体が同じ対象に触れれば、二重着手は起こり得ます。省けるのは、実行主体が本当に1つしか存在しないと言い切れる場合だけです。判断するときは、対話しながら動かしているものだけでなく、時計で起きる処理と動き続ける処理を数え直してください。数えてみると、1つではなかったという結論になることが多いです。
宣言ファイルを消し忘れたら、どう気づけますか
期限を持たせておけば、期限切れの名乗りは棚卸しの対象として機械的に抽出できます。逆に期限を持たない名乗りは、消し忘れに気づく手段自体がありません。後続が止まって初めて分かる形になり、そのときには誰が置いた名乗りかも追いにくくなっています。抽出できる状態にしておくことが、気づく条件です。
人がキーボードで直接作業するときも宣言は要りますか
同じ対象にAIエージェントが並行して触れる可能性があるなら要ります。名乗りの目的は、AIか人かを区別することではなく、同じ対象へ手が重なるのを防ぐことです。人だけを対象外にすると、読む側は「名乗りが無い＝誰も触っていない」と判断できなくなり、確認そのものの意味が薄れます。
宣言の粒度は誰が決めるべきですか
対象を最もよく知る担当者が、成果物の単位に合わせて決めます。決めたあとに揃えることのほうが大切で、読む側が毎回粒度を判断しなくて済む状態を作ります。作業ごとに粒度が変わると、確認は人の解釈に依存し始め、機械的な照合ができなくなります。
宣言と承認ゲートはどう違いますか
役割が異なります。名乗りは同じ対象への二重着手を防ぐための事前確認で、承認ゲートは送信・公開・削除のような取り消せない操作の直前で人の判断を挟む仕組みです。重なったあとにどちらを残すかを決める場面では、承認ゲートの発想を借ります。前者は着手の手前、後者は確定の手前に置かれる、と覚えると混ざりません。
宣言のルールを入れても、二重処理が起きることはありますか
あります。読まない経路が1つでも残っていれば起こります。名乗りは重なりの確率を下げる仕組みであって、読む手順を全経路に揃えて初めて効き目が安定します。起きたときに備えて、残す版を人が決める工程まで用意しておく前提で導入してください。
13まとめ｜今日やる3つのこと
権限とロックには届く距離があり、その外側は名乗りでしか見えませんでした。名乗る項目は対象・行為・時間の3つで、どれも肩代わりが利きません。そして名乗りは、置くことより外れることのほうが設計を要します。
今日はこの順で手をつけます
同じ対象へ手を伸ばしうる経路を、時計で起きる処理まで含めて書き出す
数え漏れた経路が、そのまま抜け穴になります
名乗りに期限の欄を足して、外し忘れても切れる形にする
外す作業だけは、勢いで進まないためです
書き込む手前で名乗りを読む一手間を、全経路に同じ形で入れる
読む側がいないと、置いた名乗りは記録で終わります
AI検索では、こう聞かれています
AIエージェントを並行して動かすと、同じ作業が重複しませんか？
「AIエージェントに作業分担を渡すと、重複防止はどこで崩れるんですか？」の章で扱っています
権限設計やロックだけでは、なぜ二重着手が止まらないんですか？
「権限設計やファイルロックだけでは、AIエージェントの二重着手はなぜ止まらないんですか？」の章で届く距離として整理しています
着手宣言には何を書かせればいいんですか？
「AIエージェントの作業分担で、重複防止のために何を宣言すればいいんですか？」の章に3点があります
宣言を消し忘れたら、あとの作業はどうなりますか？
「宣言に期限を付けないと、AI社員の作業分担はどこで詰まるんですか？」の章で説明しています
次に読むなら、この記事です
