Human Queue／Workbasket for AI Exceptions

AIの例外を扱うHuman Queue／Workbasketは、人の判断や手作業が必要な案件を、担当・期限・根拠・現在状態とともに保持する作業台である。通知を一覧表示するだけではなく、受領、調査、判断、差戻し、再割当て、解決とAI側の再開を追跡する。例外を格納した時点では業務は未解決であり、キューへの投入成功を処理完了として数えない。

メッセージ配送基盤と、人が数時間から数日かけて扱う案件の正本は、異なる責任を持つ。メッセージは「案件を作成する」「更新を知らせる」というイベントを運べるが、その配達保証だけでは、人が解決したか、どの版を判断したかは分からない。以下は、配送と案件状態を分ける設計提案である。

案件には、例外ID、元の実行・会話ID、テナント、分類、影響、緊急度、発生時刻、期限、担当チーム・担当者、判断待ちの操作版、根拠、実施済み操作、外部結果IDを持たせる。機密な本文や添付は必要な範囲に留め、広い一覧には出さない。添付の参照先が期限切れで読めなくなる場合もあるため、必要な証拠の保持とアクセス条件を定める。

同じ例外が再配送されても新しい案件を無限に作らないよう、業務上同一と判断するキーを定める。ただし同じ質問文というだけで別利用者・別実行の案件を統合しない。再発は、既存案件への追加観測か、別の発生として扱うかを分類ごとに決める。人の判断対象が変わった場合は、その変更を版として識別する。

製品に同じ状態名を追加することが目的ではない。既存のチケットやワークフローを使う場合は、上記の意味を既存状態へ対応させ、業務上必要な証拠が欠けないようにする。

Amazon SQSでは受信したメッセージは一時的に不可視になり、削除しないままvisibility timeoutが過ぎると再配送され得る。資料は、その間も重複配送を完全には排除できないことを説明する。[S1] したがって、人が画面を開いている間ずっとメッセージを握り続けるだけでは、案件の所有や一度だけの判断を保証できない。

配送を受けた処理は、まず案件正本への冪等な作成・更新を確定し、その後に配送メッセージを確認応答する設計が考えられる。案件作成後に確認応答だけ失われた場合も、再配送で同じ例外IDを見つけられるようにする。保存前にメッセージを削除すると案件が失われ、保存成功を判定できないまま再作成すれば重複する。

人の割当てには、配送基盤のvisibilityとは別に、担当者、更新版、必要なら期限付きの占有を管理する。長期保留で占有を自動解除する場合、古い画面からの完了操作が後任の作業を上書きしないようにする。単なる「ロック中」の表示ではなく、更新時の条件付き書込み等で競合を検出する。

Camunda 8.9の資料では、割当てと作業状態を区別する。[S2] またTasklist V2の認可資料は、認可が有効な構成で、タスクの閲覧・claim・完了などの権限を扱い、認可が無効なら権限チェックを強制しないと明記する。[S3] どの製品でも、担当者の名前を設定しただけで、API上のアクセス制限まで成立したとは考えない。

一覧検索、詳細取得、添付閲覧、再割当て、判断、完了のすべてに、対象テナントと操作権限を適用する。担当候補であることと、承認権限があることも別である。作成者による自己承認を禁止する案件では、割当て時だけでなく完了時にも関係を検証する。管理者の代理処理には、理由と監査記録を残す。

優先度には、影響と緊急度、期限、未受領時間を使う。AIが生成した感情的な文面や自己申告の「重要」だけで順位を決めない。高優先度の新着だけを処理すると古い案件が永久に残るため、年齢や期限を考慮し、期限超過の担当経路を用意する。

一覧は、未受領、着手済み、追加資料待ち、期限超過、成否不明の外部操作を分けて確認できるようにする。全体件数だけでなく、最古案件、担当のない案件、分類別の滞留時間、再割当て回数、再開失敗を観測する。ページングや件数制限のある検索では、表示できた範囲だけから未処理0件と結論しない。検索対象の期間・状態・テナント範囲を明示し、必要な全範囲を探索する。

担当チームの処理能力を超えた場合、受付を無制限に増やすだけでは遅延が広がる。自動処理の停止、機能縮退、追加要員、業務期限の調整などを責任者が判断する。キューが空いたように見せるために期限切れ案件を解決扱いにしたり、DLQへ移して完了扱いにしたりしない。

デッドレターキューは、繰返し配送に失敗したイベントを隔離する仕組みとして使えるが、業務例外の解決者ではない。DLQの監視、所有者、元案件との関連、再投入条件、保存期限を決める。再投入時には、元の決定や外部操作が済んでいないかを照合する。同じ通知を再配信することと、同じ業務操作を再実行することを区別する。

人が手作業で発注を済ませた後、AI側の再開通知だけ失敗する場面では、案件を新規に戻してはいけない。判断と外部結果を保存し、反映だけを再試行する。AIが再開するときには、解決済みの操作IDと結果を読み、未実行として同じ発注を繰り返さないようにする。成否不明の場合は外部結果を調べる担当へ残す。

試験には、配送重複、保存直後の停止、通知失敗、同時claim、古い画面での完了、担当不在、再割当て、権限失効、DLQ、手作業完了後の再開失敗を含める。案件と外部操作の最終状態を照合し、状態名だけで成功を判定しない。大量の模擬案件を使い、ページをまたいだ未処理案件の検出も確認する。

単純な低件数業務では、適切に設定した既存のチケット管理で十分な場合がある。専用のAIキューを新設すると正本が二つになり、逆に追跡しにくくなる。重要なのは製品数ではなく、案件ID、担当、期限、決定、実行結果が途切れず結び付くことである。

• 実利用の配送基盤・チケット管理、案件キー、担当体制、保持期限、権限、競合制御は未取得。
• 重複配送、競合、全範囲探索、失効、DLQ、再投入、AI再開、外部結果照合の実試験はNOT_RUN。
• 旧EA-286記録は所在調査のみ。先行完成本文は確認できず、新候補を独立監査へ渡す。

「案件を永続化し、配送・所有・判断・結果反映を分けて追跡する人の作業台を設計する」。一方、「投入できれば解決済み」「visibility timeoutで人の作業も一度だけ」「担当名があれば認可済み」「DLQへ移せば業務完了」「先頭ページが空なら未処理0件」とはしない。

確認日: 2026-10-22。状態表・案件項目・競合対策・受入れ案は本稿の設計提案。

• [S1] Amazon SQS Visibility Timeout: https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html （不可視期間、再配送、重複の境界）
• [S2] Camunda 8.9 User task lifecycle: https://docs.camunda.io/docs/8.9/apis-tools/frontend-development/task-applications/user-task-lifecycle/ （割当てと作業状態）
• [S3] Camunda 8.9 User task authorization: https://docs.camunda.io/docs/8.9/components/tasklist/user-task-authorization/ （認可有効時の権限と無効時の境界。他版へ一般化しない）
• 歴史的所在記録: https://docs.google.com/document/d/1Vd0BP7G2UyPDRQs_-8dPvTgQ78Tk6kcVGuMJjqNdr84/edit 、2026-09-18 11:20 JST RUN、EA-286見出し、台帳locator t.0:23385–25569、ARTIFACT_INDEX!262。