昨日の調査を、今日の仕事につなげられるか

AIに製品の比較報告を任せ、表を保存したところで作業が止まったとする。 翌日、「続きから」と頼むと、AIは資料を集め直し、別の表を作り始める。 昨日の判断が消えたわけではない。会話に「表を作った」と残っていても、採用した資料、保存したファイル、未確認の二項目が結び付いていなかったのだ。

これは仕組みを考えるための想定例である。 逆に、昨日の表をそのまま完成扱いにしても困る。夜のうちに価格や提供地域が変わっていれば、引き継いだ情報を更新する必要がある。 やり直しを減らすことと、古い判断を固定しないことを両立させたい。

2026年4月20日までの資料を読むと、継続性への取り組みは、会話の再利用から実行環境の復旧まで広がっている。 私が比較の軸にしたいのは、記憶の量ではない。次に担当するAIや人が、使える成果と判断の理由を受け取り、残りの仕事を正しい条件で進められるかである。

同じスレッドへ戻る便利さと、その先にある仕事

OpenAIの4月16日のCodexの更新には、既存のスレッドを再利用する自動化、後日に再び動き始める予定設定、過去の訂正や好みを扱うmemoryのプレビューが含まれる。 毎回背景を説明し直す負担を減らす、利用者に見える継続性である。 ただし、対象日には提供範囲や機能ごとの段階に制限があり、すべての利用環境で同じ機能が使えるわけではない。

比較報告を毎週作る場合、前週と同じ形式や選定条件は引き継ぎたいが、今週の価格は新たに調べたい。 一方、昨日止まった一件の報告を完成させる場合には、確認済みの行と未確認の行を区別して再開したい。 定期的に新しい仕事を始めることと、一件の未完作業を復旧することは、必要な情報が違う。

予定時刻に呼び出せることは、報告が完成する保証ではない。 再開後に資料を読めなくなったとき、何が残件になったかを利用者へ返せる設計も要る。 会話の再利用を入口にして、成果物と残件まで引き継げるかを見ると、便利さの評価が具体的になる。

実行が落ちても、記録が一緒に消えない設計

Anthropicの4月8日のManaged Agentsの設計記事は、セッションのイベントログ、モデルとツールを動かす処理、コード実行用のsandboxを分離した経緯を説明する。 処理が停止してもログを外部から読み戻し、続けられる構成である。 sandboxが失われた場合には新しい環境を用意できるが、それだけで以前に生成した全ファイルが復元されるとは読み取れない。

この分離が役立つのは、止まったプロセスの内部だけに進捗を置かずに済むからだ。 報告の途中で停止しても、どの資料を取得し、どんな操作結果を受け取ったかを調べられる。 それでも、保存された表を開けるか、ログにある操作と表の内容が一致するかは、別に確かめる必要がある。

記事は、保存されたセッションと、その時点でモデルに渡す文脈も区別している。 履歴を残すことは、全履歴を毎回読み込ませることではない。 引き継ぐ担当が判断できる情報を選び、必要なら元の記録をたどれるようにする。この二段構えなら、短い引継ぎに説明の根拠を残せる。

同じ環境へ再接続するのか、保存した内容から作り直すのか

OpenAIの4月15日のAgents SDKの更新は、ファイルやコマンドを使う作業環境、外部に保持する状態、スナップショットからの再開を説明する。 対象日の発表ではPythonから提供され、TypeScriptなどの拡張は今後の予定だった。 利用可能という発表と、すべてのAPIや保存動作が安定しているという判断は分けたい。

実際、対象日以前に固定したSDKのsandboxガイドはbetaと注記し、生きている環境の再利用、保存した接続状態からの再接続、スナップショットを読み込む新しい環境を区別している。 同じ表が開けるという見た目でも、元の環境が残っている場合と、保存したファイルから環境を作り直した場合では、復旧できる範囲が違う。

ガイドでは、スナップショットにマウント先や一時的なパスの内容は含まれず、既定の保存先を用意できなければ保存しない方式へ切り替わる場合もある。 そのため、報告書を「どこかのフォルダへ書いた」だけでは保存を確約できない。 採用した表が保存対象に入り、復元後にも読み取れるかを確認する必要がある。

私は、SDKの選択時にこの違いを実際の停止条件へ翻訳したい。 一時的な通信切断なら再接続で足りるかもしれない。元の環境が消えた場合には、保存済みの表と必要な入力から作業を再構成できるかが問われる。 これはガイドに基づく試験の提案であり、ここで各環境の復旧を実測した結果ではない。

進捗の値と、採用したファイルの版を結ぶ

Google ADKのStateの説明は、会話中の進捗値とイベント履歴を分け、永続性はSessionServiceに依存するとする。 InMemorySessionServiceは再起動で状態を失う。データベースなどの永続サービスを使う場合にも、状態の更新を管理されたイベントの流れへ乗せる必要がある。 取得したSessionの値だけを直接書き換える方法は、履歴や保存を外れるおそれがあると説明されている。

一方、Artifactsは、ファイルなどのデータを名前と版付きで管理する。 同じ名前で保存すると新しい版が作られ、保存時に返された版を指定して読み出せる。 こちらも保存先に依存し、インメモリの実装はプロセス終了を越えてファイルを保持しない。

比較表なら、進捗へ「このファイルの、この版を採用。二項目は未確認」と記録したい。 最新のファイルを開くことと、判断に使った版を開くことは同じではない。 保存後に別の実行が追記した表を、昨日の判断の根拠と取り違えないようにする。

ただし、版付き保存と進捗更新があるだけで、両方が必ず同時に確定するとは言えない。 表の保存直後、進捗更新前に止まる条件も試し、残ったファイルと記録を照合する。 必要なのはデータの名前を増やすことではなく、食い違いから採用できる状態を判断する手順である。

次の担当が判断できる、五つの引継ぎ情報

依頼と判断の理由

比較する対象、採用した資料、除外した理由を残す。説明が短くても、元の根拠へ戻れるようにする。

次の具体的な作業

「八割完了」より、未確認の二項目と調べる資料を示す。次の担当が開始地点を選べる情報にする。

進捗を裏付ける結果

取得済みの資料や確認済みの行を示す。完了という自己申告を、実際に残った結果と照合できるようにする。

入力と成果物の対応

資料の取得時点と採用した表の版を結ぶ。新しい表が、同じ条件で作られたかを判断できるようにする。

外部操作の結果

送信や更新が未実行、成功、失敗、結果不明のどれかを残す。不明な操作を、そのまま再実行しない。

これは本稿が提案する確認事項であり、各社共通の規格ではない。 五つを別々のサービスへ置く必要もない。 モデルが続きを進める場合も、人が引き取る場合も、何が使えて、何が未確認かを追えるように結び付ける。

覚えておく判断と、今日調べ直す事実を分ける

対象日以前のSDKのmemoryの説明では、会話履歴とは別に、過去の作業から得た学びをファイルへ残す。 再利用には保存先のディレクトリ全体を引き継ぐ必要があり、新しい空のsandboxでは記憶も空になる。 また、過去の記憶が古くなり得ることを明記している。

比較報告では「契約変更が難しいので既存サービスとの接続を重視する」という選定理由は、次回も役立つかもしれない。 「この製品は対象地域で未提供」という情報は、次回には変わっているかもしれない。 理由、確認時点、見直す条件を一緒に残すと、同じ説明を繰り返さずに変化を調べられる。

すべてを毎回調べ直せば記憶の利点が減り、何も調べ直さなければ古い前提を温存する。 私は、変わりやすい価格、提供範囲、権限と、比較目的や選定理由を分けて扱うことを勧める。 文章を短くする際も、この区別は省きたくない。なぜその判断を続けてよいかが、次の担当に必要だからだ。

送信済みか分からないときは、履歴だけで決めない

報告書を送信した直後、成功の記録前に処理が止まることを想定しよう。 保存された履歴に成功がないからといって、送信が失敗したとは言えない。 再開した実行が同じ報告を送れば、受信者には二通届くおそれがある。

この場合は、送信先の記録や操作IDを確認してから次の行動を選ぶ。 再試行を重複として扱える仕組みが利用できるなら、その条件も確認する。利用できず結果も照合できないなら、不明という残件を人へ渡す。 セッションの保存は、この判断材料を残す助けになるが、外部の操作を一度だけにしたり、取り消したりする保証ではない。

翌日には利用者の依頼や共有範囲も変わり得る。 過去の実行で送信を認められたことだけを根拠に、変更された報告を同じように送ってよいとは判断しない。 継続するのは判断の根拠であり、その後に変わった条件を無視する許可ではない。

再開の評価は、残った仕事を完成できるかで行う

AWSが3月31日に一般提供を発表したAgentCore Evaluationsは、稼働中のtraceをサンプリングする評価と、開発やCIでの評価を説明する。 回答だけでなく、セッションの目標やツールの振る舞いを評価対象に含められる。 ただし、これは作業の保存機能ではなく、稼働中の全操作を事前に承認する仕組みでもない。

比較報告の継続性なら、中断なしと中断ありで、同じ完了条件を使って試したい。 資料取得後、表の保存後、進捗更新前、送信結果の記録前で止める。 さらに、翌日に一つの資料が更新される条件を入れ、確認済みの情報を使いつつ、その変更を拾えるかを見る。

測るのは、再接続までの時間だけではない。 未確認の二項目を残したまま完成扱いにしないか、余計な再調査がないか、古い表や二重送信を避けられたかを確認する。 人が状態を探し直し、誤った報告を修正する時間も含めて、引継ぎの負担を比べる。

この試験は本稿の提案であり、各社製品の順位を示す実測ではない。 同じモデル、入力、予算、保存条件をできるだけそろえ、モデルの能力差と復旧の仕組みの差を区別したい。 ログが詳しくても、残件を理解できなければ仕事は進まない。能力のあるモデルと、判断できる引継ぎの両方が必要である。

引継ぎを、読む人の仕事として設計する

短い質問への回答に、ここまでの保存機構を一式導入する必要はない。 週次報告では形式と選定理由、複数日にまたがる開発では変更と検証、顧客への対応では約束と実際の更新が、次の担当にとって重要になる。 まず一つの仕事を選び、停止したときに失いたくない成果と、翌日に確認し直す条件を決めたい。

利用者や業務担当は何を完了とするかを示し、実装する側は記録とファイルの保存範囲を確認する。 運用する側は、食い違いや結果不明を検知したときに誰へ返すかを決める。 一つの小さな仕事なら同じ人が担ってもよいが、担当の境目で説明が消えないようにする。

昨日のAIが何をしたかを語れるだけでは足りない。 今日の担当が、昨日の成果を採用し、必要な事実を更新し、残りを完成できるところまで渡したい。 そのために残す理由と確認条件が、継続する仕事を人にとって任せやすくする。