2026.10.26 / Agent Memories

ツール自動化で効くAI記憶の引き継ぎ｜続きから動ける運用設計

自動化したツールの処理を別の担当へ引き継ぐとき、「途中なので続けてください」だけでは危険です。外部サービスへの書き込みは終わったのに、内部の記録だけが残っていないことがあります。逆に、成功というメモがあっても、実際の反映を確認できていない場合もあります。ツール自動化の引き継ぎでは、作業の説明より先に、何が実行済みかを証拠で分けます。

引き継ぐのはジョブ名ではなく処理の境目

「通知ジョブ」「顧客更新ジョブ」という名前だけでは再開地点を判断できません。入力の確定、対象の選択、外部への要求、応答の受信、内部保存、利用者側の確認を分けます。どこまで済んだかを示すと、受け手は最初からやり直さずに済みます。すべての処理が同じ段階にあるとは限らないため、対象ごとの状態も必要です。

例として、予約された十件の案内のうち七件は送達確認済み、二件は未送信、一件は応答待ちで中断したとします。十件を丸ごと再送してはいけません。七件を完了群へ、二件を未実行群へ、残り一件を結果未確認群へ分けます。この数字は設計の説明用であり、実際のサービスでは取得できる証跡に合わせて状態を定めます。

再開票に対象と操作の識別子を残す

同じ顧客名や記事タイトルだけでは対象を一意に決められません。ツール側の対象ID、操作の種類、入力版、実行時刻、要求の識別子を記録します。秘密の値や顧客の全文は入れず、必要な担当が正規の場所で確認できる参照にします。ツールのアカウントや環境が違えば、同じIDでも対象が異なる可能性があるので、利用経路も固定します。

重複防止のキーを使う仕組みなら、その有効範囲と状態を残します。ただしすべてのAPIが冪等性を提供するわけではありません。キーを書いてあるだけで二重実行を防げると説明しないでください。提供元の仕様と実際の応答を確認し、再要求が許される条件を引き継ぎ票へ明示します。

結果が分からない対象は先に読む

通信が切れたことは、外部処理が失敗した証拠ではありません。受け手は、取得API、操作履歴、利用者側の表示など、許可された読み取りから現在の状態を確かめます。送達済みと確認できたなら再送せず、内部記録の修復へ進みます。未反映と確認できた場合だけ、許可と現在の条件を照合して未完了の操作を行います。

証跡を取得できず、成功とも失敗とも判断できない場合は、その対象への重複し得る書き込みを止めます。ほかの未送信対象を安全に処理できるなら、その経路まで止めません。確認不能の理由、必要な照会先、次に確認する担当と時点を残します。結果不明という一語で全件を失敗群へ入れることが、再実行の事故を生みます。

担当交代の瞬間に二人が書かないようにする

送り手が処理を続けながら受け手も再開すると、正しい引き継ぎ票があっても重複します。実行中のプロセス、ロック、作業の貸出状態を確認し、書き込む担当を一人に固定します。会話で交代を宣言したことと、ツールを操作できる実行系が切り替わったことは別です。停止した担当の処理が遅れて完了する場合も想定します。

引き継ぎ時点の入力と状態を控え、受け手が操作する直前にも変化を確認します。新しい変更が入っていれば、その差から再開計画を作り直します。古い票に基づいて現在のデータを上書きしないことが重要です。緊急時でも、引き継ぎのためにアカウントの秘密情報をチャットへ貼る方法は選びません。

受領確認は小さな読み取りで行う

受け手には、対象、完了済みの操作、確認待ちの一件、次の一手を自分の言葉で返してもらいます。送り手は値と参照が一致するかを確かめます。長い資料を送っただけで担当移管を完了としないためです。受け手が必要なファイルやツールへアクセスできない場合は、引き継ぎ内容ではなく受け渡し経路の問題として直します。

最初の確認は外部書き込みを伴わないものにできます。対象の状態を読むだけで、入力版やアカウントの相違が見つかることがあります。受領に失敗したからといって、新しい担当を次々に追加しないでください。まず不足した参照や権限を限定し、一人の担当が確実に再開できる入口を作ります。

取り消しと再実行を別の手順として扱う

失敗した処理の戻し方は、同じジョブをもう一度走らせることではありません。取り消せる外部操作なのか、取り消しが別の操作になるのかを確認します。通知のように送信自体を戻せないものもあります。その場合は誤送信への対応を定め、履歴を消して未送信に見せないようにします。可逆なデータ更新でも、後続更新を巻き戻さない注意が必要です。

再開後の受入検査では、対象件数、外部状態、内部台帳、対象外の変更を照合します。エラーが出なくなったことだけで引き継ぎ成功にはしません。完了群が増え、結果不明群がどう扱われたか、同じ要求が二重に届いていないかを確認します。未解決の一件があれば、全体が完了したように報告せず、担当と確認経路を残します。

次の自動実行へ正常に戻ったかを見る

担当者が手で一度処理できても、次の定期実行が古い状態を読めば同じ障害が再発します。引き継いだ状態を通常の読み取り経路が受け取れるか確認し、次回の自然実行で対象が一度だけ進むかを見ます。試験のために本番を無断で再実行するのではなく、予定された機会と読み取りを使います。

引き継ぎ票を長期に残すなら、現在の運用への入口と実行履歴を分けます。将来の担当が過去の緊急手順を日常手順として使わないよう、適用時点と終了条件を付けます。良い引き継ぎは、資料が厚いことではなく、受け手が成功済み操作を飛ばし、未完了の一手へ正しく到達できることです。

再開時の質問

タイムアウトした対象は再送してよいですか？

外部の状態を先に確認します。通信結果と処理結果は同じではないため、成功済みの可能性が残る間は同じ書き込みを繰り返しません。

引き継ぎ票に認証情報も入れますか？

本文には入れません。許可された認証経路の参照と必要な範囲を示し、資格情報の取り扱いは既存の保護手順に従います。

受け手が完了と言えば移管成功ですか？

成果物と状態を確認して判断します。報告は手掛かりですが、対象、件数、反映、重複の有無の確認を置き換えません。

設計の参考にした一次資料

OpenClaw MemoryはワークスペースのMarkdownを記憶の基盤として説明します。PROV-OはEntity・Activity・Agentと利用や生成の関係を定義し、入力と実行、担当を結ぶ説明に役立ちます。NIST AI RMFはGovern・Map・Measure・Manageにリスク管理を整理しています。本稿の再開票や状態分類は実務上の提案であり、これらの資料が特定APIの二重実行防止や送達を保証するわけではありません。