担当の割り当てと遅れた提出を分ける——期限切れ・引継ぎ・二重処理の検証設計

返事がないことは未実行とは限らない

月末の請求書確認を複数の担当が処理する場面を考えます。一人がある請求書を担当すると知らせた後、応答が途切れました。別の担当へ渡した直後に、最初の担当も確認を終えて提出します。二つの分類結果が違う場合、後から届いた方を採用してよいでしょうか。外部への支払まで含むなら、同じ請求を二度処理する危険があります。返事がないことと実行していないことを分け、担当を切り替える前に現在の結果を確認する必要があります。

まず「まだ誰も担当していない」「担当を予約した」「作業中」「結果を受け取った」「結果が不明」を分けます。予約は作業を始めてよい権利を一時的に確保する段階です。担当者が自分のメモへ書くだけでは、他の担当から見えません。共有する受付で、同じ請求書を同時に予約できないようにします。人の注意に頼るだけでなく、受付側が一度に一人へ渡す条件を検査することが必要になります。

この例では請求書の確認までを自動処理の対象とし、支払の確定は別の工程へ残します。予約の設計を外部操作へ広げる場合は、相手側の受付記録も確認する必要があります。同じ仕事を一人へ渡したことは、外部の処理が一度だけ行われた保証ではありません。何を一つの仕事とみなし、どこまでを管理するかを最初に決めることで、二重処理の防止を過大に説明せずに済みます。

同じ仕事を見分ける根拠を持つ

請求書を同じ仕事として識別するには、会社名と金額だけでは足りません。同じ会社から同じ金額の別請求が届く場合があります。請求番号、対象期間、発行元を基に識別し、訂正版は別の版として結び付けます。入力が二度届いた場合も、同じ内容の再送なのか訂正なのかを分けます。似た文章をAIが見つけたことだけで一件へまとめず、業務上の識別規則を使います。

受付で同じ依頼が再度届いたなら、既存の担当と進行を返せるようにします。一回目が処理中なのに二回目を新しい仕事として発行すると、予約の仕組みがあっても別件として進みます。逆に、内容が違う訂正を同じ仕事として黙って受け入れると、担当者が以前の内容を処理し続けます。内容の一致と依頼の一致を検査し、違う場合は新しい版として確認する必要があります。

一つの仕事に複数工程がある場合、請求書全体を一人へ固定するか、分類、照合、確認の工程ごとに担当を変えるかを決めます。工程ごとに予約すれば専門分担ができますが、前工程の結果の版を確認する必要があります。照合担当が古い分類結果を使わないように、受け取った版を記録します。仕事の識別だけでなく、その工程で扱う入力の範囲を固定することが引継ぎを支えます。

予約を受けた証拠を提出まで使う

担当者は、予約が成功したことを確認してから作業を始めます。空いているように見えた画面だけで着手すると、同時に別の担当も始められます。受付側で予約を一つの処理として確定し、担当、対象の版、有効期限を記録します。その確認情報は成果を提出するときにも照合します。今の担当ではない人から届いた結果を、到着した順だけで採用しないためです。

予約が失敗した担当には、既に別の担当が処理中であることを返します。失敗を通信エラーとして扱い、同じ作業を再度始めないようにします。仕事の一覧を更新すれば進行は見られますが、見る権限と担当になる権限は別です。複数担当が閲覧し、助言や検査を行うことはできます。結果を確定して提出する権限だけを一つにすることで、協力を止めずに二重提出を防げます。

提出時には入力の版も確認します。作業中に請求書が訂正されたなら、以前の結果を新しい請求書の結果として受け入れません。担当者へ対象が変わったことを返し、どの部分をやり直すかを確認します。完了の判断には、予約が有効であること、入力が一致すること、成果が必要条件を満たすことを含めます。予約があるだけで成果の内容まで正しいと扱わないことが重要です。

期限切れを再実行の命令にしない

予約の期限は、担当が永久に仕事を抱えないために必要です。ただし期限が切れたことは未実行の証拠ではありません。結果を保存した直後に応答が途切れた場合もあります。期限切れは状態を確認するきっかけとし、まず担当の記録と成果の存在を確かめます。結果が見つかれば検査へ進み、見つからなければ引継ぎ候補にします。外部操作を行った可能性があるなら、相手側の記録も確認します。

作業が続いていることを定期的に知らせる方法もありますが、それだけで進捗を保証するわけではありません。応答しているが処理が止まっていることもあります。担当の応答、成果の更新、処理の進行を区別して記録します。長い処理なら中間成果を保存し、引継ぎで使える範囲を示します。期限を延長する条件も決め、応答があるという理由だけで無期限に延長しないようにします。

確認しても外部の結果が分からない場合は、結果不明として止めます。再送すれば解決するとは限らず、二度目の請求や通知が生まれるかもしれません。支払や投稿のような操作では、相手側に同じ依頼を識別する機能があるかを事前に確かめます。今回の請求書分類のように外部操作がない工程でも、二つの結果が矛盾した場合は選択理由を記録する必要があります。

引継ぎは残った仕事を明示する

新しい担当へ渡すのは元の依頼だけではありません。確認済みの項目、未確認の項目、保存した中間成果、外部操作の有無、停止の理由を渡します。既に照合した金額を再確認する必要があるか、請求先だけ調べればよいかを判断できます。以前の担当が「半分終わった」と書いた曖昧なメモだけでは、残りを定められません。工程と対象項目に分けた記録が引継ぎを短くします。

引継ぎを確定した後は、以前の担当の予約を無効にします。古い担当が遅れて提出した場合は、現行の結果へ黙って混ぜず参考情報として扱います。新しい担当が再利用するなら、内容と対象版を確認します。古い担当からの有益な成果を全て捨てる必要はありませんが、誰が最終結果を確定するかは一人に保ちます。担当の切替と成果の再利用を分けることで、遅れた返答にも対応できます。

引継ぎ記録には、切り替えた時点と理由を残します。担当が交代した事実だけでは、期限切れによる切替か、専門性の違いによる切替かが分かりません。後から同じ仕事が二度処理された場合、受付の問題か担当の操作の問題かを調べるために必要です。引継ぎが成功したことと、成果が受け入れられたことも別です。交代後の検査を省略せず、通常の受入条件を適用します。

同時に起きる失敗を試す

試験では二つの担当が同時に予約し、一つだけ成功することを確かめます。順番に押して一人だけ選ばれたことでは、同時予約の問題を確認できません。提出も同時に行い、同じ結果が一度だけ受け入れられるかを見ます。また、期限切れの直前に提出が来る、引継ぎ直後に古い担当が戻る、作業中に入力が訂正される場面を用意します。通常の流れだけでは境界の誤りを発見しにくくなります。

停止からの再開も重要です。受付を再起動した後に予約が残り、既存の担当を認識できるかを確認します。画面を閉じると予約が失われる構成では、長い作業を管理できません。保存した状態と実際の成果が一致するかも見ます。完了と記録されているのに成果がない場合は、完了表示を信用せず調査へ戻します。逆に成果だけある場合も、誰がどの入力で作ったかを確かめます。

試験の成功から言える範囲を限定します。内部の予約と提出が一度だけ処理されることを確認しても、外部サービスへ二重送信が起きない保証にはなりません。対象ごとの検証が必要です。担当の名前を変えただけで別人の確認を装うことも避けます。予約は排他の仕組み、独立レビューは評価の仕組みであり、両者を混ぜずに検証することで、何を防げたかを具体的に説明できます。

履歴と現在の担当状態を別に保つ

実行の試行を追記し、結果を受領記録として残す方法は、期限切れの調査に役立ちます。実行履歴サービスのヤクモ提供の実装にも、この構成があります。請求書確認では、担当が何を試したかと、受付が何を受け取ったかを別の記録にします。返答がなくても成果が保存されているなら、再配分の前にそれを検査できます。ただし履歴だけで請求書の識別や予約期限は決まりません。請求番号と入力版を記録へ結び付け、切替に必要な情報を取得できるかを試します。

作業、成果物の照合、別担当レビュー、差戻し、受入を状態として保存する設計が考えられます。途中状態を保存して再開することと、完了の成果を確かめることは別の条件です。作業担当の提出を待ち、確認担当が受け入れる構成なら、完全無人の常駐AIを前提にせず担当の交代も扱います。請求書確認では、作業中の入力版と保存した成果を照合し、別担当の提出へ古い結果を混ぜないようにします。再起動後にも現在の担当と待機理由を復元できることを検査します。

実行履歴と現在の担当状態は役割が違います。履歴は何が起きたかを残し、担当状態は今誰が提出できるかを決めます。履歴を追記するだけでは二人の着手を止められず、現在状態だけを上書きしても過去の切替理由を失います。両方を持つ設計が考えられますが、具体的な実装では保存と変更を一つの整合した処理として扱う必要があります。名前を付けただけで保証が成立するわけではありません。

LangGraphで作業待ちやレビュー待ちを管理し、SQLiteへ状態を保存する構成が考えられます。提出時には、いまの待機に対応する識別子と成果物の照合値を確認し、古い提出を受け入れない条件を設けます。請求書確認では、担当切替後に以前の担当が戻る試験を用意し、現行の予約と対象版に合う提出だけを採用します。内部の提出照合ができても、予約期限の運用や外部サービスの排他保証は別の検査が必要です。外部操作の可能性がある場合は相手側の記録へ戻ります。

完了は担当の数ではなく結果で決める

運用開始前に、同じ入力の再受付、予約の衝突、期限切れ、引継ぎ、遅れた提出の扱いを短い一覧へまとめます。担当者が読む手順と受付側が検査する条件を一致させます。完了の条件は誰かが終わったと述べることではなく、対象の版に合う成果が一度受け入れられ、必要な検査を通ったこととします。結果不明の仕事が残るなら、解決した仕事と分けて報告します。

この考え方は問い合わせの担当分担、文書レビュー、画像制作の受付にも応用できます。一方、作業を細かく予約しすぎると、引継ぎと調整の負担が増えます。独立して検査できる単位を選び、同じ資料の小さな段落まで予約するような過剰な細分化は避けます。内部の処理なら再実行が可能な場合もあり、外部操作を含む仕事とは扱いを変えます。業務の性質に合わせて境界を決めます。

返事がないときに急いで別の担当へ渡す判断は、現場では自然です。だからこそ、引継ぎ前に何を確認すればよいかを仕組みにします。予約、進行、結果、結果不明を分ければ、止まった仕事を再開することと、同じ仕事を重ねることを区別できます。二人が動かないことだけを目指すのではなく、必要な仕事が失われず、採用した結果の理由を説明できることまでを目指します。