翌朝の「続けて」だけでは決められない
月次の受注報告をAIと担当者で作り、夜のうちに作業が止まったとします。翌朝、画面には途中の会話と報告の下書きがあります。営業会議が迫っているため、担当者はすぐ続きを頼みたい。しかし、集計担当がまだ数字を調べているのか、提出済みの報告を確認者が読んでいるのかで、必要な行動は変わります。前者なら提出を待ち、後者なら確認を引き継ぐべきです。下書きの存在だけで作り直しを選ぶと、進んでいた仕事を重複させます。
この場面で必要なのは、仕事の進行を保存し、作業の提出と別担当の確認を分けて再開する構成です。LangGraphは工程の順序と分岐を管理する技術、SQLiteは途中の進行を保存するデータベースとして使われています。保存された進行に沿って、取りまとめ役が各担当へ実作業を依頼するため、工程管理の再開と、AIによる完全無人処理は区別する必要があります。
報告の数字が正しいかという品質の問題に入る前に、まず「今は誰の何を待っているか」を確定する必要があります。同じ報告を、提出前、提出後、確認後という三つの停止地点から見直します。止まる原因が同じ電源断でも、戻す工程が同じになるとは限りません。
実装ではLangGraphのSqliteSaverを使い、ジョブIDに対応するチェックポイントへ状態を保存します。チェックポイントは、単に会話を残す場所ではなく、次に動く工程と待機条件を引き継ぐための記録です。同じジョブに対する操作はOSのロックで排他し、保存と同時操作の制御を別々に担わせています。
入力が変わったら、同じ続きを頼めるか
報告を始めるときには、対象月、集計の材料、会議で必要な結論を決めます。例では九月の受注表から商品別の件数と金額をまとめ、未確定の案件を確定分に混ぜないことを条件にします。依頼と材料をこの単位で残せば、翌朝の担当者は下書きを読んで仕事の目的を推測せずに済みます。会話を全て保存するより、何を作る依頼だったかを短く取り出せることが再開には役立ちます。
ところが停止中に、営業担当から訂正版の受注表が届いたとします。件数が同じでも一件の金額が変わっていれば、前日の報告の続きとして扱えるとは限りません。保存された依頼を維持することと、新しい資料を採用することを分けます。実装で自動的な再開拒否を確認したのは、工程の実装や設定など、進行の前提が変更された場合です。受注表の全変更まで自動検出するという意味ではありません。資料の訂正を受けた場合には、担当者が変更内容と集計への影響を確認して扱いを決める運用が考えられます。
この場合の選択は、古い入力を維持して途中の仕事を完了するか、変更を反映した新しい仕事として始め直すかです。会議に最新値が必要なら後者が適します。一方、前日の締め時点の数字を報告する目的なら、訂正版が存在しても採用しない判断があり得ます。再開の可否と、業務上どの資料を採用するかは、別々に判断しなければなりません。
提出前に止まったら、担当を二度呼ばない
最初の停止地点は、集計担当へ作業を渡した後、報告がまだ提出されていない場面です。保存状態には今回の依頼、何回目の作業か、提出を待つ相手が残ります。翌朝に提出が見つからないからといって、直ちに別の担当を呼ぶと、前の担当が後から返した報告と競合します。先に、今回の作業依頼が既に発行されていることと、期待する提出がまだ届いていないことを確かめます。
実装では作業を発行する工程と、その成果を受け取る工程を分け、発行時の進行を先に保存します。これにより待機を再開しても、発行をやり直す必要はありません。今回の提出を見分ける情報も依頼に付けます。例なら一回目の集計への提出と、差し戻し後の二回目への提出を混ぜない役割です。一回目の担当が遅れて報告を持ってきても、二回目の成果として受け取ることはありません。
ただし、この仕組みから担当が今も作業中だと断定はできません。提出待ちという記録が示すのは、必要な返事をまだ受け取っていないことです。担当側の障害や連絡漏れを確認し、再作業が必要なら新しい試行として発行します。待機を続けるかやり直すかの判断に、保存されている依頼の時点と、担当からの返答を使うのであって、会話の最後の一文だけを使うわけではありません。
提出後に止まったら、報告を作り直さない
次の停止地点では、集計担当の報告が保存され、機械的な検査まで終わっています。例では必要な金額欄や未確定案件の区別があるかを調べ、その後に別担当が原表と比較する予定です。ここで止まったなら、続ける仕事は報告の生成ではなく確認です。提出済みという事実と、その提出が合格したという事実を別に残しているため、確認の未完了を制作の未完了と取り違えずに済みます。
確認者に渡すのは、保存された今回の報告と受入条件です。どれが最新かを保存時刻だけで選びません。提出時の内容を計算して得られる照合値は、同じ内容を確認しているかを調べる印になります。この印だけでは金額の正しさも文章の読みやすさも分かりませんが、別の版へ確認結果を付ける事故を防ぐ材料になります。内容品質は原表との比較や人の読解で判断します。
例えば集計担当が提出後に誤字を直すつもりで金額も変更した場合、確認者が前の報告を読んだ結果は変更後の報告へ適用できません。変更後の現物を改めて検査へ戻します。停止前に確認者が口頭で「よさそう」と伝えていても、必要な条件への回答が保存されていなければ、正式な確認完了には進めません。翌朝は口頭の記憶を補うのではなく、どの版をどの条件で確認したかを揃えます。
確認待ちと故障では、連絡先が違う
保存状態が担当からの提出を待っているなら、作業担当へ連絡します。別担当の確認を待っているなら、確認担当へ現在の報告を渡します。それに対して、担当の返答待ちではないのに後続工程が残ったまま止まっている場合は、処理の中断として調べます。表示はこの違いが分かる言葉にする必要があります。「止まっています」だけでは、人の返事を急ぐべきか、実行環境を復旧すべきかが分かりません。
例の会議資料なら、営業担当の照合待ちをシステム障害として何度も起動しても、数字を確認した返事は得られません。逆に、確認結果を受け取り済みなのに最終検査が中断している場面で、確認担当へ同じ資料を送り直す必要はありません。実装には保存された待機内容に合わせて提出や確認を受け取る入口があり、一般的な再開操作で人の確認を飛び越えない構造が見られます。
運用画面で欲しいのは、停止の色よりも次の相手です。依頼の対象、今回の提出、待っている返答、停止理由を並べれば、引き継ぐ人が連絡先を選べます。返事が遅い場合の期限や代理担当の決め方は、業務側で補う必要があります。工程が正しく待っていることは、会議に間に合うことまで保証しません。保存の設計と、待機を管理する運用ルールを接続して初めて使える仕組みになります。
会議前の引継ぎは、例えば「九月分の報告は提出済み、未確定案件の照合だけが未回答、営業担当へ返答を依頼中」と書けます。この一行からは文章を再生成せず、照合の返答を回収する判断ができます。担当者が不在の場合は代理者へ同じ資料と条件を渡し、会議で使う期限までに返答が得られなければ、未確認の数字を確定値として使わないという業務上の選択へ進みます。
確認後に止まったら、最後の検査を通す
三つ目は、別担当の確認が終わった後、完了の保存前に停止した場面です。確認済みならすぐ会議へ持ち出せそうですが、確認中に成果が変更されていないかを最終段階で確かめる必要があります。実装では機械検査、別担当の確認、最終の再検査を通って完了します。再開時には残っている工程から進め、確認済みという表示だけで後続の検査を省きません。
この順序を置く理由は、作業者と確認者の間に時間差があるからです。例では確認者が午前に報告を読み、午後に作業者が別の資料を同じ場所へ保存する可能性があります。最終検査で提出内容との一致を確かめれば、午前の確認が別の文章へ流用されることを止められます。確認者の判断が正しかったことと、今から納品する文章がその判断の対象であることの両方が必要です。
ここで不一致が見つかれば、完了に押し込むのではなく対象を揃えて再検査へ戻します。工程の実装や設定が変わっているなら、既存の仕事をそのまま再開できない場合もあります。材料が訂正された場合も、古い報告をどこまで使えるかを担当が判断します。訂正のたびに最初から生成する方法は分かりやすいものの、変更と無関係な工程まで繰り返す負担があります。保存した条件を維持できる範囲では、必要な工程だけをやり直す方が、何を再確認したかを説明しやすくなります。
二人が同時に再開したらどうなるか
引き継ぎ担当と元の担当が、同じ朝に同じ仕事を開く場合もあります。両者が提出を受け付けると、片方の操作で状態が変わった後に、もう片方が古い状態を前提に進めてしまいます。途中経過を保存する機能だけでは、同時操作の衝突は防げません。このジョブ基盤は同じ仕事の操作を重ねないための排他も持ち、提出が今回の待機に対応するかを受取時に確認します。
比較すると、保存は停止しても続きを残す役割、排他は同時に二つの操作が進むのを抑える役割です。一方をもう一方の代わりにはできません。例なら最初の担当の提出が受理された後、同じ提出がもう一度届いても二重に進行させないことが必要です。また、差し戻し後に古い提出が届いた場合は、内容が一見もっともらしくても現在の仕事に使わない判断になります。
記録で確認できるのは、同じ一台のコンピューター上の操作を扱う構成です。複数拠点の別々の機械が同じ仕事を動かす環境まで、この排他だけで安全だとは言えません。共有する保存先、担当間の通信、同時操作の範囲が変われば追加の設計が必要です。導入先で再開を許す端末と担当を先に限定することは、便利さを減らすだけでなく、確認すべき競合条件を具体的にする選択でもあります。
自分の業務で試すなら、停止地点を選ぶ
この内容は、同じコンピューター上で開始・提出・確認を順に行い、途中で保存した仕事を引き継ぐ手順を確かめるために定義したものです。三つの端末や別々の運用環境を使った検証ではありません。また、同時に届く重複提出を一度だけ受け取る試験もあります。これらは保存された試験の定義で、現行環境での実行結果を示すものではありません。工程の実装や設定の変更時に再開を拒否する設計はありますが、全ての停止原因からの復帰と月次報告の作業時間への効果は、導入先で別に検証する必要があります。
読者が試すなら、外部へ送らない小さな報告を一つ選びます。担当への依頼後に止めた場合は再発行しないこと、提出後に止めた場合は同じ報告を確認へ渡すこと、確認後に止めた場合は最終検査を残すことを、それぞれ期待結果にします。さらに工程の設定を変更した条件で、古い前提の再開が拒否されるかを確かめます。材料だけを訂正版へ替える条件では、担当がどの資料を使うか判断できる情報を残すという、別の運用上の確認を行います。正常に最後まで進む例だけでは、この違いは見えません。
試作の結果は「再開できた」の一語で済ませず、止めた位置、保存されていた資料、再開後に最初に動いた担当を残します。業務に戻したときに一番困るのが提出待ちなら、その表示と連絡先から整えるのが実践的です。確認待ちが多いなら代理担当や返答期限を補います。まず自分の仕事の止まり方を一つ選び、その地点から余分な作業も確認の飛越しもなく戻れることを、導入の最初の条件にしてください。
設計に持ち帰るポイント
再開時には、止まった場所、今回の提出、次に必要な担当の三つを保存状態から確かめる。
この記事について
執筆：ウェルネスライン編集部（自社の制作・実装をもとにした解説）
関連事例「AI作業を検証・受入まで管理するジョブ基盤」を見る →
各工程は担当者（人またはAI）が実行する構成で、AIだけで全工程を無人で処理した実績ではありません。
この記事は設計の考え方を説明するもので、導入効果を測った結果ではありません。
コード例は説明用の抜粋で、そのままでは動かない場合があります。