# Human Queue／Workbasket for AI Exceptions CURRENT_STATUS: CURRENT OBSERVATION: SPEC_ONLY FRESHNESS: CURRENT PAGE_TYPE: reference CANONICAL_URL: /tools/ea-286-human-queue-workbasket-for-ai-exceptions CLAIM_IDS: none EVIDENCE_IDS: EVD-EA-286-URL-610FBD2EE3C2, EVD-EA-286-URL-361154BF10A0, EVD-EA-286-URL-B57576952528, EVD-EA-286-URL-FB87768384BB, EA-286-CURRENT-APPROVAL, EA-286-CURRENT-BODY-READBACK UNKNOWN_IDS: EA-286-UNKNOWN-01 OPS_IDS: none ## Summary 「案件を永続化し、配送・所有・判断・結果反映を分けて追跡する人の作業台を設計する」。一方、「投入できれば解決済み」「visibility timeoutで人の作業も一度だけ」「担当名があれば認可済み」「DLQへ移せば業務完了」「先頭ページが空なら未処理0件」とはしない。 ## Current judgment 「案件を永続化し、配送・所有・判断・結果反映を分けて追跡する人の作業台を設計する」。一方、「投入できれば解決済み」「visibility timeoutで人の作業も一度だけ」「担当名があれば認可済み」「DLQへ移せば業務完了」「先頭ページが空なら未処理0件」とはしない。 ## Scope Human Queue／Workbasket for AI Exceptions ## Confirmed ## UNKNOWN - EA-286-UNKNOWN-01: - 実利用の配送基盤・チケット管理、案件キー、担当体制、保持期限、権限、競合制御は未取得。 - 重複配送、競合、全範囲探索、失効、DLQ、再投入、AI再開、外部結果照合の実試験はNOT_RUN。 - 旧EA-286記録は所在調査のみ。先行完成本文は確認できず、新候補を独立監査へ渡す。 ## Evidence - EVD-EA-286-URL-610FBD2EE3C2 (RESEARCH): [S1] Amazon SQS Visibility Timeout: — https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html - EVD-EA-286-URL-361154BF10A0 (RESEARCH): [S2] Camunda 8.9 User task lifecycle: — https://docs.camunda.io/docs/8.9/apis-tools/frontend-development/task-applications/user-task-lifecycle/ - EVD-EA-286-URL-B57576952528 (RESEARCH): [S3] Camunda 8.9 User task authorization: — https://docs.camunda.io/docs/8.9/components/tasklist/user-task-authorization/ - EVD-EA-286-URL-FB87768384BB (RESEARCH): 歴史的所在記録: — https://docs.google.com/document/d/1Vd0BP7G2UyPDRQs_-8dPvTgQ78Tk6kcVGuMJjqNdr84/edit - EA-286-CURRENT-APPROVAL (RESEARCH): 現行本文の監査・revision対応 - EA-286-CURRENT-BODY-READBACK (IMPL): 現行本文の収録照合 ## Failure / limits 試験には、配送重複、保存直後の停止、通知失敗、同時claim、古い画面での完了、担当不在、再割当て、権限失効、DLQ、手作業完了後の再開失敗を含める。案件と外部操作の最終状態を照合し、状態名だけで成功を判定しない。大量の模擬案件を使い、ページをまたいだ未処理案件の検出も確認する。 単純な低件数業務では、適切に設定した既存のチケット管理で十分な場合がある。専用のAIキューを新設すると正本が二つになり、逆に追跡しにくくなる。重要なのは製品数ではなく、案件ID、担当、期限、決定、実行結果が途切れず結び付くことである。 ## 要点と前提 AIの例外を扱うHuman Queue／Workbasketは、人の判断や手作業が必要な案件を、担当・期限・根拠・現在状態とともに保持する作業台である。通知を一覧表示するだけではなく、受領、調査、判断、差戻し、再割当て、解決とAI側の再開を追跡する。例外を格納した時点では業務は未解決であり、キューへの投入成功を処理完了として数えない。 メッセージ配送基盤と、人が数時間から数日かけて扱う案件の正本は、異なる責任を持つ。メッセージは「案件を作成する」「更新を知らせる」というイベントを運べるが、その配達保証だけでは、人が解決したか、どの版を判断したかは分からない。以下は、配送と案件状態を分ける設計提案である。 ## 案件の正本を作る 案件には、例外ID、元の実行・会話ID、テナント、分類、影響、緊急度、発生時刻、期限、担当チーム・担当者、判断待ちの操作版、根拠、実施済み操作、外部結果IDを持たせる。機密な本文や添付は必要な範囲に留め、広い一覧には出さない。添付の参照先が期限切れで読めなくなる場合もあるため、必要な証拠の保持とアクセス条件を定める。 同じ例外が再配送されても新しい案件を無限に作らないよう、業務上同一と判断するキーを定める。ただし同じ質問文というだけで別利用者・別実行の案件を統合しない。再発は、既存案件への追加観測か、別の発生として扱うかを分類ごとに決める。人の判断対象が変わった場合は、その変更を版として識別する。 | 状態・操作 | 保存すること | 未完了として残す条件 | |---|---|---| | 新規・振分け | 発生理由、対象、担当候補、期限 | 適格な担当経路が未確定 | | 受領・着手 | 受領者、着手時刻、処理対象の版 | 調査・判断の結果がない | | 保留・追加資料待ち | 理由、必要資料、次の確認日 | 保留条件が未解消 | | 再割当て・差戻し | 旧担当、新担当、理由、引継ぎ情報 | 新しい担当が受領していない | | 判断・作業完了 | 決定、根拠、手作業の結果、外部ID | AI側への反映や結果確認が未完了 | | 解決・取消し | 最終状態、責任者、利用者への結果 | なし。ただし再発は履歴と関連付ける | 製品に同じ状態名を追加することが目的ではない。既存のチケットやワークフローを使う場合は、上記の意味を既存状態へ対応させ、業務上必要な証拠が欠けないようにする。 ## 配送基盤のロックを人の占有に使わない Amazon SQSでは受信したメッセージは一時的に不可視になり、削除しないままvisibility timeoutが過ぎると再配送され得る。資料は、その間も重複配送を完全には排除できないことを説明する。[S1] したがって、人が画面を開いている間ずっとメッセージを握り続けるだけでは、案件の所有や一度だけの判断を保証できない。 配送を受けた処理は、まず案件正本への冪等な作成・更新を確定し、その後に配送メッセージを確認応答する設計が考えられる。案件作成後に確認応答だけ失われた場合も、再配送で同じ例外IDを見つけられるようにする。保存前にメッセージを削除すると案件が失われ、保存成功を判定できないまま再作成すれば重複する。 人の割当てには、配送基盤のvisibilityとは別に、担当者、更新版、必要なら期限付きの占有を管理する。長期保留で占有を自動解除する場合、古い画面からの完了操作が後任の作業を上書きしないようにする。単なる「ロック中」の表示ではなく、更新時の条件付き書込み等で競合を検出する。 ## 割当てと権限の違い Camunda 8.9の資料では、割当てと作業状態を区別する。[S2] またTasklist V2の認可資料は、認可が有効な構成で、タスクの閲覧・claim・完了などの権限を扱い、認可が無効なら権限チェックを強制しないと明記する。[S3] どの製品でも、担当者の名前を設定しただけで、API上のアクセス制限まで成立したとは考えない。 一覧検索、詳細取得、添付閲覧、再割当て、判断、完了のすべてに、対象テナントと操作権限を適用する。担当候補であることと、承認権限があることも別である。作成者による自己承認を禁止する案件では、割当て時だけでなく完了時にも関係を検証する。管理者の代理処理には、理由と監査記録を残す。 ## 例外を埋もれさせない運用 優先度には、影響と緊急度、期限、未受領時間を使う。AIが生成した感情的な文面や自己申告の「重要」だけで順位を決めない。高優先度の新着だけを処理すると古い案件が永久に残るため、年齢や期限を考慮し、期限超過の担当経路を用意する。 一覧は、未受領、着手済み、追加資料待ち、期限超過、成否不明の外部操作を分けて確認できるようにする。全体件数だけでなく、最古案件、担当のない案件、分類別の滞留時間、再割当て回数、再開失敗を観測する。ページングや件数制限のある検索では、表示できた範囲だけから未処理0件と結論しない。検索対象の期間・状態・テナント範囲を明示し、必要な全範囲を探索する。 担当チームの処理能力を超えた場合、受付を無制限に増やすだけでは遅延が広がる。自動処理の停止、機能縮退、追加要員、業務期限の調整などを責任者が判断する。キューが空いたように見せるために期限切れ案件を解決扱いにしたり、DLQへ移して完了扱いにしたりしない。 ## DLQと再処理の意味 デッドレターキューは、繰返し配送に失敗したイベントを隔離する仕組みとして使えるが、業務例外の解決者ではない。DLQの監視、所有者、元案件との関連、再投入条件、保存期限を決める。再投入時には、元の決定や外部操作が済んでいないかを照合する。同じ通知を再配信することと、同じ業務操作を再実行することを区別する。 人が手作業で発注を済ませた後、AI側の再開通知だけ失敗する場面では、案件を新規に戻してはいけない。判断と外部結果を保存し、反映だけを再試行する。AIが再開するときには、解決済みの操作IDと結果を読み、未実行として同じ発注を繰り返さないようにする。成否不明の場合は外部結果を調べる担当へ残す。 ## 受入れと反証 試験には、配送重複、保存直後の停止、通知失敗、同時claim、古い画面での完了、担当不在、再割当て、権限失効、DLQ、手作業完了後の再開失敗を含める。案件と外部操作の最終状態を照合し、状態名だけで成功を判定しない。大量の模擬案件を使い、ページをまたいだ未処理案件の検出も確認する。 単純な低件数業務では、適切に設定した既存のチケット管理で十分な場合がある。専用のAIキューを新設すると正本が二つになり、逆に追跡しにくくなる。重要なのは製品数ではなく、案件ID、担当、期限、決定、実行結果が途切れず結び付くことである。 ## OPEN_UNKNOWN - 実利用の配送基盤・チケット管理、案件キー、担当体制、保持期限、権限、競合制御は未取得。 - 重複配送、競合、全範囲探索、失効、DLQ、再投入、AI再開、外部結果照合の実試験はNOT_RUN。 - 旧EA-286記録は所在調査のみ。先行完成本文は確認できず、新候補を独立監査へ渡す。 ## SAFE_WORDING 「案件を永続化し、配送・所有・判断・結果反映を分けて追跡する人の作業台を設計する」。一方、「投入できれば解決済み」「visibility timeoutで人の作業も一度だけ」「担当名があれば認可済み」「DLQへ移せば業務完了」「先頭ページが空なら未処理0件」とはしない。 ## 出典・provenance 確認日: 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。 NEXT: /agent/start.json STOP: This is a knowledge projection, not an execution order.