AIを複数ターミナルで並行させたら、1日で7回「もう終わった仕事」をやり直しかけた

AIエージェント（Claude Codeなど）を複数ターミナルで並行して走らせると、同じ仕事を2回やりかけるという問題に直面した記録。観察によれば、1日で7件発生した。原因はシンプル：並行セッションは起動時に「コンテキストの写し」を持って走り出す。その後、本体（チケット、ドキュメント、リポジトリ）が更新されても、写しは更新されない。だから本体では「終了」と書いてあるのに、写しは「未着手」のままで、そこを読んだAIが「やりましょうか」と提案する。症状は7件共通だったが、問題は「どちらが本体か、事前には決められない」ということだった。チケットが古く、タスク管理ドキュメント（写し）が正しい場合もあれば、その逆もある。対処のポイントは「作業ログを第三の目にする」ことだった。チケットとタスク管理が食い違ったら、勝つのはどちらでもなく「実際に何をしたか」の作業記録。これがデータベース的には単純だが、実装すると厄介だ。開発者は番人（自動検査）を書いて、旗が立ったら「見に行け」と指示する仕組みにした。最初の番人は的中率36%。第二の番人は0%。さらに細かなルール調整を加えると37件→24件に減ったが、完全には解けない。否定文を完了と誤認したり、既に追いついた写しに旗が立ったり。AIの鬼が興味を持つのは、ここから先だ。並行セッション＝スナップショット、という単純な事実が、どれだけ深刻な一貫性問題を起こすか。本体と写しが常に非同期な環境では「完全な正答」が存在しない。監査ログを第三の目に置いても、そのログ自体が古い場合がある。結局、機械が出した旗も、人間の判断も、両方疑わなければならない。この不安定性は、デジタル化の本質的な課題だ。中小企業がAIエージェントを複数並行させるとき、気をつけるべきは処理速度ではなく「状態同期」。共有リソース（チケットシステム、ファイル、ドキュメント）を複数AIが同時に読み書きする環境では、昔ながらの排他制御と監査ログが不可欠。便利さの前に堅牢性。git add <パス>で特定ファイルだけコミットするといった、地味な工夫が、意外と効く。つまり並行運用には、単なる自動化ではなく、人間側の監視コストが上乗せされるという現実を先に認識しておくべき。速さと信頼性の両立は、技術だけでは解けない。