仲裁は最終手段。衝突は設計で減らす

小さなチームでよく起きる構図

ここで言う「スキル」は、イベント発生時に特定タスクを自動的に実行する AI の自動化モジュールです。

次のような状況は意外と多いです。

• 1件の顧客イベントを、CS下書き・進捗整理・返金確認の3つが同時に受ける
• 2つ以上のスキルが同じステータス欄を更新できる
• 自動化を進めたいが、実行順がぶれる

これはモデルが悪いわけではありません。

問題は、同じ事件に対して「入口」が明確でない設計です。

まず覚えておく原則

仲裁は安全網。

衝突を減らす順番は次の通りです。

• イベント境界を最初に決める
• 重複トリガーを取り除く
• 書き込み権限を集約する
• フローを再設計して競合しにくくする

本番前の4ステップ

1. 先にイベント境界を固定する

イベントにウェブフック（webhook）、スケジューラ（cron）、メッセージキュー（queue）など複数入口があると、設計が曖昧になりやすいです。

• まずイベント源をすべて列挙し、同じ種類のイベントを 1 つのイベントグループにまとめる
• ticket.updated、refund.alert のようなイベントキーでイベントグループ化し、キーごとに起動責任を 1 人に固定
• 監査条件：同じ種類のイベントグループが同時に 2 つ以上の入口から開始されないこと

2. 重複トリガーを事前に除外する

多くの衝突は「条件の名前は違うが意味が同じ」ケースです。

• 直近 2 週間の重複起動ケースを抽出し、重複条件をペアで表示する
• 同じ業務結果を生む条件は統合して 1 本にし、判断が必要な代替は一時停止で管理
• 監査条件：主要フローの開始条件はイベントファミリーあたり 1 つのみ

3. 責任と権限を具体化する（ownership）

「書ける人」を増やすより、「誰が責任を持つか」を先に決める。

• 書き換え対象フィールドを洗い出し、重要項目を高リスクに分類
• 高リスク欄は write owner を 1 人だけにし、他は read-only、または suggest-only（提案のみ）へ変更
• 例外ルール：関連 ID 欠損、バージョン不一致、人による介入中は即時停止

4. ワークフロー（workflow）を競合しにくく再設計する

「最初に着手した人が勝つ」ではなく、引継ぎルールを先に決めます。

• 主担当を 1 つだけ定義し、実行決定権はその担当に集約
• 補助担当は事実確認・追加根拠・提案を返し、実行はしない
• 判断困難なケースは自動停止し、handoff（人への引継ぎ）でレビューへ送る
• 日誌に必ず残す: primary_skill、blocked_by、handoff_target

生活四コマ

1. 同一イベントに対して一つの標準入口を決め、同時起動を防ぐ。
2. 重複トリガーを統合して、競合しやすい条件を整理する。
3. 高リスク欄は一人だけが書き込み責任を持ち、他は提案・参照へ。
4. 避けられない重複だけ仲裁に渡し、人間の最終確認へ引き継ぐ。