「Claudeで進めながら、Codexにも別の作業を投げています」。そう聞くと、速くなる話にしか見えません。実際、工程が分かれていれば速くなります。
つまずくのはそのあとです。両方のエンジンが「終わりました」と報告したのに、どちらの版を完成品として扱えばよいのか分からなくなる。中身が消えたわけでもなく、赤いエラーも出ません。だから、気づくのが遅れます。
この記事は、WEBMARKSで実際に起きた誤爆をたどりながら、ClaudeとCodexを同時実行するときの注意点を組み立て直します。素材は自社の運用記録と、両エンジンの公式ドキュメントです。
こんなふうに調べていませんか
- ClaudeとCodexを同時に走らせているが、同じ場所へ書いたときに何が起きるのか分からない
- 身に覚えのない完了報告が出た。どこから調べればよいのか、見当がつかない
- エンジンをまたぐと、どちらの設定で止められるのかがはっきりしない
この記事を読み終えたときに手に入るもの
- 同時実行でどこまで見えていないのかを、エンジンごとに線引きできるようになります
- 更新時刻を手がかりにした判定が崩れる理由を、自分の言葉で説明できるようになります
- 書き込む前に担当範囲を宣言する手順を、そのまま自社の工程へ持ち込めます
結論30秒でわかる、この記事の結論
- 同時実行の注意点は、相手のエンジンがこちらを見ていないことです。競合は中身が消える形だけでなく、どの版を完成品とみなすかの判定が壊れる形でも起きます。
- 更新時刻だけを手がかりにした判定は、3日間で233回の誤爆になりました。
- 打ち手は二段構えです。書いた事実を名指しで残し、書く前に担当範囲を宣言します。
進行役は3人です。高梨課長が自分の手で動かす側から、大森部長が体制を決める側から聞き、鈴木さん（本誌監修）が答えます。
01「claude codex 同時実行 注意点」で調べた人は、AIエージェントの何を先に確かめればいいんですか？
高梨課長検索して出てくるのは、設定項目の話ばかりなんです。知りたいのは、そこではない気がしていて。
鈴木さん二人で同じ床を張っている現場に近いと思っています。手元は丁寧でも、お互いの背中は見えません。設定を整えることと、相手が映ることは別なんですよ。
先に確かめておくとよいのは、次の3つです。
- 競合は、中身が上書きされて消えることだけを指しません。どちらのエンジンの、どの時点の版を完成品として扱うかを、機械が判定できなくなることも含みます。
- 判定の材料は、エンジンの外側にはほとんど残りません。片方の設定をどれだけ整えても、もう片方の動きは映らないままです。
- 打ち手は、書いたあとに残す記録と、書く前に置く宣言の二段に分かれます。役割が違うので、片方だけでは埋まりません。
同時実行そのものを避ける話ではありません。工程を分ければ、複数のエンジンを走らせる運用は速く進みます。ただし、同時実行が安全になるわけではなく、境界の外側には注意点が残ります。
本記事が扱うのは、その外側の一点です。エンジンが違うと、検出そのものが難しくなります。
02ClaudeとCodexを同時実行したとき、AIエージェントの側からは何が見えていないんですか？
WEBMARKSは2026-07-08、Codexに「成果物が納品先へ正しく格上げされたか」を確認する仕組みを入れました。作りっぱなしを防ぐための追加です。
導入した直後から、業務と関係のない確認メッセージが、セッションの末尾に出るようになりました。あるブラッシュアップ監査（TASK-048）を走らせた回では、完了報告の末尾が「直近で成果物が作られました」という表示に置き換わっています。
そこに並んでいたのは、そのセッションが一度も触っていない別案件のファイルでした。走らせた本人には、なぜその名前が出るのかが分かりません。
Codexから見えていたのは、自分の実行の内側だけです。同じ時間帯にClaude Codeの別セッションが動いていたことは、Codexの画面には現れません。逆に、Claude Code側にも、Codexが何かを判定していることは映りません。
見えていないもの同士が同じ場所へ手を伸ばすと、症状は「知らない名前が出る」という形で表に出ます。原因を探そうとしても、手がかりになる情報がエンジンの中に残っていません。
この章のまとめ
症状は表示の異常でした。ただし異常が出ているのは表示であって、壊れているのは判定のほうです。
03233回の誤爆は、同時実行しているAI社員の運用のどこで起きたんですか？
原因は、Codexの旧フックが、ファイルの更新時刻（mtime）だけで「自分が書いたファイルか」を判定していたことです。
Claude Codeの並行セッションが書いたファイルも、同じ土俵で更新時刻が動きます。Codex側からは、どちらの手で動いた時刻なのかを区別できません。
導入から2026-07-10までの3日間で、この誤判定は233回発火しました（出典: 社内タスク台帳、2026-07-10記録）。
高梨課長233回というのは、誰かが数えて気づいたということですか。
鈴木さんあとから台帳をたどって数えた形です。1回ずつは「変な表示が出たな」で済んでしまうので、積み上がるまで大きさが見えませんでした。
同じ「競合」でも、現れ方は一つではありません。次の表は、この誤爆と、エンジンの内訳がまだ特定できていない別の事故を並べたものです。
| 項目 | 更新時刻の誤爆（本記事の主題） | 参考: 記事の上書き |
|---|---|---|
| 発生期間 | 2026-07-08〜07-10（3日間） | 2026-07-24 22:07〜22:27（20分間） |
| 発生回数・被害 | 233回の誤表示 | 記事3本の上書き |
| エンジンの内訳 | Claude Codeの並行セッション×Codexの旧フック | 監視プロセスと本体セッション（内訳は未特定） |
| 対策 | 書き込みの明示記録（record-output.py） | 着手宣言（WRITER_CLAIM） |
この表で押さえておきたいのは、被害の大小ではありません。片方は画面に異変が出て、片方は何も起きないように見える、という気づき方の差です。
この章のまとめ
中身が消える競合は、開けば分かります。判定が狂う競合は、開いても分かりません。
04Codex単体の不具合だと見たのは、生成AIの同時実行の何を疑わなかったからですか？
最初の対処は、Codex単体のバグとして扱われました。2026-07-09、更新時刻の判定対象から中間ファイルを外すパッチが当たっています。判定方法そのもの、つまり更新時刻を見るという設計は変えていません。対象範囲を絞っただけです。
このパッチのあとも、誤判定は止まりませんでした。Claude Codeの並行セッションは、中間ファイル以外にも書き込みます。除外リストを増やしていく対応では追いつきません。
同時実行という前提そのものを疑わなかったこと。これが、対処が後手に回った理由です。
| 論点 | 誤診（2026-07-09時点の対処） | 本当の原因 |
|---|---|---|
| 問題の切り分け方 | Codex単体の表示バグ | エンジンをまたぐと判定材料がなくなるという設計の隙間 |
| 対処の方向 | 除外ファイルを増やすパッチ | 書き込みを明示的に記録し、両エンジンが同じ記録だけを見る |
| 判定に使った材料 | 更新時刻（mtimeのみ） | スレッドID・案件ID・SHA-256ハッシュの明示記録 |
05同時実行の注意点は、AIエージェントの検出範囲がどこで途切れることなんですか？
Claude Codeのサブエージェントは、専用のコンテキストウィンドウとツール権限を持ちます。ツール呼び出しのたびにフックが発火し、入力にはそのサブエージェントを識別するagent_idが乗ります（出典: Claude Code公式フックドキュメント、2026-08-02確認）。
ただし、この可視化は1つのセッションの中に閉じています（出典: Claude Code公式サブエージェントドキュメント）。セッションをまたぐと、もう届きません。
同じエンジン同士でも事情は変わりません。cronのような別プロセスと本体セッションが同じ対象に触れば、種類としては同じ競合が起こり得ます。
Codexも構造は似ています。サンドボックスモードは、Codexが書き込める範囲を技術的に決めます。値はread-only・workspace-write・danger-full-accessです。承認ポリシーは、いつ確認を求めるかを決め、on-request・untrusted・neverがあります（出典: Codex公式ドキュメント、2026-08-02確認）。
どちらもCodex自身の実行を制御する設定です。他のセッションや他のエンジンの動きを知る手段ではありません。
検出できる範囲は、同じセッションの中がいちばん広く、同じエンジンの中、エンジンをまたぐ、の順に狭くなります。ClaudeとCodexという別のエンジン同士には、共有された識別子がそもそもありません。
大森部長両方の設定をきちんと書けば、いずれ噛み合うのではありませんか。
鈴木さんそこが盲点でした。どちらの設定も、自分の実行を制御するためのものなんです。相手を覗く窓は、最初から付いていません。
06更新時刻は、同時実行するAIエージェントの判定材料としてなぜ弱いんですか？
更新時刻（mtime）は、ファイルシステムが誰にでも見せる、数少ない共有情報です。だからこそ、手がかりに使いたくなります。
ただし、advisory lock（勧告的ロック）のような明示的な合図とは違います。複数の処理が同時に走る環境では、更新時刻だけでは「誰が触ったか」の証拠になりません（出典: man7.org flock(2)マニュアル）。
WEBMARKSは2026-06-24に7部署・30体のAI社員体制を統合しています。関わるセッションと案件が増えるほど、同じ盲点に当たる組み合わせも増えていきます。
置きかえてみると、性質の差がはっきりします。片方は「そこに誰かがいるらしい」という気配で、もう片方は「私が担当します」という申し出です。気配は、当たっているあいだだけ申し出と同じ働きをします。
07同時実行の記録に切り替えて、AIエージェントの誤爆はどう止まったんですか？
2026-07-10、WEBMARKSは判定方法そのものを作り直しました。柱は、更新時刻による推測をやめ、書き込みイベントを明示的に記録する方式への切り替えです。
ツール実行の直後に発火するフック（record-output.py）が、実際に書いたファイルだけを拾います。記録にはスレッドID・案件ID・SHA-256ハッシュが付きます。ゲート（promotion-gate.py）は、この記録だけを見て判断します。
この記録によって、Codexは「これは自分の成果物だ」と正確に言えるようになりました。233回の誤爆は、これで止まっています。
ただし、この記録は書いたあとに残るものです。書いた瞬間に、もう一方のエンジンへ知らせる経路はまだありません。ClaudeとCodexが同時に同じ対象へ書き込もうとする場面そのものは、記録だけでは防げません。
この章のまとめ
記録は「誰が書いたか」を後から言えるようにします。「いま誰が書こうとしているか」は、まだ空いたままです。
08着手宣言は、同時実行しているAIエージェントのどちらから見ても同じ結果になるんですか？
高梨課長記録が残るのは分かりました。ぶつかる瞬間のほうは、どう止めるんでしょう。
鈴木さん会議室の予約札に近いです。入る前に札を見て、空いていれば自分の札を掛ける。札は廊下にあるので、どの部署の人が来ても同じものを見ます。
ここで使うのが、姉妹メディアの事故で導入された着手宣言（WRITER_CLAIM）です。
書き込む前に、対象範囲の宣言ファイルが_work/にあるかどうかを、ファイルの有無で確認します。ファイル名には対象範囲と日時を入れます。範囲が重ならなければ、複数の宣言が同時にあってもかまいません。
この判定は、シェルコマンド一つで済みます。Claude CodeのBashツールからも、CodexのCLIからも同じ結果になります。
# 書き込み前に、どちらのエンジンからでも同じ手順で確認する
ls _work/WRITER_CLAIM_AGIM-503*.md 2>/dev/null && echo "他エンジンが担当中" || \
printf 'range: AGIM-503\nengine: self\nstarted: %s\n' "$(date -u +%FT%TZ)" \
> _work/WRITER_CLAIM_AGIM-503_$(date +%Y%m%d-%H%M).md着手宣言がエンジンをまたいで働くのは、Claude Codeのフック設定にもCodexの承認ポリシーにも寄りかかっていないからです。判定の材料をどちらか一方の内部機能に置いた時点で、もう一方には届きません。
09検索語の「claude codex 同時実行 注意点」を社内ルールに直すと、AI社員は何を守るんですか？
大森部長これを社内のルールにするなら、一行で言うと何になりますか。
鈴木さん「判定の材料を、どのエンジンの内部にも置かない」だと思っています。置いた瞬間に、もう一方からは見えなくなりますから。
AGI Journal自身の制作も、複数のセッションが同じ対象へ同時に動きうる運用です。この案件では、着手宣言で担当範囲を示してから書き始める形を、立ち上げ当初の設計として採用しています。姉妹メディアの事故を後から輸入したのではなく、同じ注意点が最初から前提にありました。
ファイルの有無というOS標準の合図に寄せておけば、将来別のエンジンが加わっても、確認の手順を書き直さずに済みます。逆に、片方のエンジンの機能に寄りかかった手順は、エンジンが増えるたびに書き足しが要ります。
誤検知が出たときの扱いも、ルールに含めておくと後が楽です。片方のエンジンだけの不具合として処理すると、原因の切り分けが今回と同じ道をたどります。発生期間・発生回数・対象ファイルを記録に残しておけば、次に似た症状が出たときの照合が速くなります。
送信・公開・削除のような人間ゲートの設計は、承認ゲートを扱った記事に譲ります。着手宣言は、その手前でエンジン同士がぶつかるのを防ぐ、もう一段手前の仕組みです。
更新時刻の誤爆をどう切り分けるかという手順そのものも、別の記事にまとめてあります。あちらは一つの症状の診断手順、本記事はエンジンをまたぐと診断も対策も届きにくいという構造に焦点を当てています。
10よくある質問
ClaudeとCodexを同時実行するのは、そもそもやめたほうがいいですか
工程が分かれていれば、同時実行そのものは成り立ちます。問題になるのは、同じ対象へ同時に向かう設計のほうです。書き込む先が重ならないように工程を割り、重なりうる範囲だけを宣言で守る、という順番で考えてみてください。同時実行をやめる判断より、対象を重ねない設計のほうが先に効きます。
着手宣言のファイルは、いつ消せばいいですか
その範囲の書き込みが終わった時点です。残したままにすると、次の担当が待ち続けます。逆に、書き終える前に消すと、宣言が無い状態で書き込みが続きます。作業の単位と宣言の寿命を同じ長さに揃えておくのが、扱いやすい形です。
更新時刻を判定に使うのは、いつでも間違いですか
一人だけが触る前提の場所なら、手がかりとして使えます。弱くなるのは、複数の処理が同時に走る場所です。更新時刻そのものが悪いのではなく、同時実行という前提の下で「誰が触ったか」の証拠に使うと外れます。使う場所を選べば、いまでも役に立つ情報です。
記録と宣言は、どちらか片方だけでもいいですか
役割が違うので、片方だけでは埋まりません。記録は書いたあとに「これは自分の成果物だ」と言うためのものです。宣言は書く前に「いまここは自分が持っている」と示すためのものです。誤爆を止めたのは記録で、ぶつかること自体を減らすのが宣言です。
エンジンが三つ以上になったら、手順は増えますか
ファイルの有無で判定しているあいだは、手順は増えません。確認する側がいくつになっても、見る対象は同じ札です。増えるとすれば、範囲の切り方を丁寧にする場面くらいでしょう。どのエンジンの内部機能にも寄りかかっていないことが、この性質を支えています。
11まとめ｜今日やる3つのこと
同時実行でつまずくのは、エンジンの能力差ではありません。相手が見えない、という構造です。見えないものを推し量ろうとすると、更新時刻のような弱い手がかりに手が伸びます。
記録は、その推し量りをやめるための仕組みでした。宣言は、ぶつかる場面そのものを減らすための仕組みです。どちらもOS側の合図に寄せてあるので、エンジンが入れ替わっても手順は残ります。
今日はこの順で手をつけます
同じ対象へ同時に向かう工程が無いか、いまの割り振りを見直す
重ならなければ、宣言そのものが要りません
書き込みを名指しで残す記録が、両方のエンジンに効いているかを確かめる
片側だけだと、誤爆はもう一方から出ます
重なりうる範囲について、書く前に札を置く手順を決める
手順が一つなら、どちらのエンジンでも同じに回ります
AI検索では、こう聞かれています
ClaudeとCodexを同時に動かすと、何が起きるんですか？
「ClaudeとCodexを同時実行したとき、AIエージェントの側からは何が見えていないんですか？」の章で症状から追っています
同時実行で起きた誤爆は、なぜ止まらなかったんですか？
「Codex単体の不具合だと見たのは、生成AIの同時実行の何を疑わなかったからですか？」の章に誤診の経緯があります
別のエンジン同士で、書き込みの競合はどう防ぐんですか？
「着手宣言は、同時実行しているAIエージェントのどちらから見ても同じ結果になるんですか？」の章で手順を説明しています
更新時刻で担当を判定してはいけないのはなぜですか？
「更新時刻は、同時実行するAIエージェントの判定材料としてなぜ弱いんですか？」の章で理由を書いています
次に読むなら、この記事です
