この記事は、AIエージェントの運用に関する事故録シリーズの1本である。自社が運用する、探索型ゲームを遊ぶAIキャラクターで目的地に2日間到達できなかった原因と、その修正の途中で新たに作り込んでしまった別の不具合を検証する。
この記事で分かること
- 複数の処理が同時に動く仕組みで、目印(フラグ)を立てても効果が出なかった理由
- 修正の過程で自分が作り込んだ、もう1つの構造的な不具合
- どちらも同じ「解除条件のなさ」に起因すること
この記事で分からないこと(正直に書く)
- 同種のフラグ管理が、この記事で扱った2件以外の処理でも同じ壊れ方をする範囲
目的地に2日間届かなかった
複数の段階を踏む一連の操作(専用の場所と道具が必要な行動)は、途中で別の操作が横から1回でも割り込むと完成しない性質を持っていた。この事故を防ぐための目印が事前に用意されており、設計メモには「目印は1つにして、全員がそこを見る」と明記されていた(出所: 自社の運用記録、確認日2026-09-06)。ところが実際にその目印を参照していたのは、優先度を管理する1つの処理だけだった。行動の優先順位は「移動を止める、回復する、買い物する」の順に並んでおり、回復や買い物は該当の一連の操作より優先度が高い。段階の切れ目でこれらの操作に割り込まれると、進行中の段階は記録も残さずに失われ、目的地への到達が2日間完成しなかった。目印を立てても、参照している箇所が1か所しかなければ、実質的に目印は存在しないのと同じだった。
もう1つの不具合: 複数ティックかかる処理を、毎ティック評価する門の中に置いた
この一件を直す途中で、別の不具合を自分で作り込んだ。「一度確認した内容を、その場に留まっている間はもう一度疑わない」という制御を追加したが、この確認を毎ティック評価される判定の内側に置いてしまった。対象の操作は開始から完了まで複数ティックかかるため、1ティック目で使用権を消費し、2ティック目で実際の操作が始まる前に別の判定に弾かれてしまう。結果、「疑い直す」動作が7回発生したのに対し、実際に開始できたのは0回だった(出所: 自社の運用記録、確認日2026-09-06)。
なぜ気づけなかったか
「全員が見る」という設計方針は文書に書かれていたが、それを検証する手段がなかった。実際に何か所から参照されているかはコードを検索すれば数えられる安価な確認だが、実施していなかった。ドキュメントの記述と実装の一致が、書いた本人の記憶にしか依存していなかったことが、2日間気づけなかった理由である。もう1つの不具合についても、「1回だけ疑い直す」という制御が意図通り働いていると思い込み、それが門の位置によって開始前に消費されている可能性を疑っていなかった。
どう直したか
目印を担当する処理の側で1回だけ参照する形に改め、持ち主以外の処理はその目印を経由しないようにした。以後同じ種類の処理を追加しても同じ壊れ方をしない構造にし、戦闘中はこの独占状態を維持しないという安全策も加えた。複数ティックにまたがる処理については、都度評価する門をやめ、行動が実際に開始した瞬間にだけ使用権を消費する仕組みに変更した。
再発防止の具体的な手順
- 目印(フラグ)を作るときは、参照する処理を1か所に決め、他の処理はその目印を経由させない
- 「ドキュメントに書いた」ことと「実装で守られている」ことは分けて確認する。参照箇所の数はコード検索で機械的に数えられる
- 複数ティックにまたがる処理を評価する門(条件分岐)は、都度評価ではなく開始時点で状態を固定する仕組みにする
- 副作用のある判定(呼び出すたびに内部状態を消費するもの)を、複数回評価されうる条件の中で使わない
- 修正の効果は、処理の開始ログと終了ログの両方を残したうえで確認する。開始ログしか出ていない場合は、途中で弾かれている可能性を疑う
探索型ゲームでAIエージェントが長時間動けなくなった別の事故(探索型ゲームでAIエージェントが動けなくなった記事)と同じ運用記録からは、動かす処理そのものが死んでいた事例(処理が止まっているのに正常に見えた記事)も見つかっている。批評だけでは判断の誤りを防げないという点は、判断批評がすべて失敗した記事とも通じる。
自社が運用するAIエージェントの排他制御・状態管理について相談したい場合は、お問い合わせから編集部まで連絡してほしい。
よくある質問
Q1. 目印(フラグ)を用意していたのに、なぜ効果が出なかったのか
目印を参照していたのが1つの処理だけだったため。優先度の高い別の操作が段階の切れ目に割り込むと、目印があっても進行中の段階が失われた。
Q2. 修正の過程でどんな不具合を新たに作ったのか
複数ティックかかる処理を、毎ティック評価される判定の内側に置いてしまい、1ティック目で使用権を消費して2ティック目で弾かれる状態になった。実測では「疑い直す」動作7回に対し、開始できたのは0回だった。
Q3. 2つの不具合に共通する原因は何か
どちらも解除条件のない目印・判定が原因だった。参照箇所が1つに絞られていない、または複数回評価されうる条件の中に置かれていることで、意図した制御が効かなくなっていた。
Q4. 同じ問題を防ぐには何を確認すればよいか
目印を作った際に参照箇所の数を機械的に数えること、複数ティックにまたがる処理は都度評価でなく開始時点で状態を固定する仕組みにすることの2点である。