AIエージェントを比べる軸は、「一度うまく答えるか」ではなく「仕事を持ち越せるか」になった

1. プロジェクト / セッション層

まず必要なのは、仕事の単位を会話より少し太く持つ器である。ChatGPT の Projects は長く続く作業を一か所にまとめ、 繰り返し使う業務フローを再利用できる場として説明される。Google の Sessions も同様に、継続中の対話の履歴と進捗を保持する。 ここが弱いと、毎回やり直す agent しか作れない。

2. 実行継続層

次に必要なのは、文脈だけでなく実行そのものを持ち越す層である。OpenAI の SandboxAgent は start, stop, resume を前提にし、 Anthropic の Managed Agents はセッションログを harness や sandbox の外へ出して、container が落ちても再開できる構成を取る。 AWS AgentCore Runtime も非同期 agent と厳密なセッション分離を中核に置く。

3. 成果物継続層

長い仕事では、最終返答より途中成果物の方が重要になる。Google ADK の Artifacts は大きいデータや生成ファイルをセッション状態と分離して保持し、 Anthropic も引き継ぎ用の成果物やファイルベースの受け渡しを使ってセッション間の引き継ぎを扱う。ここがないと、agent は途中で作ったものを安全に渡せない。

4. 運用継続層

持ち越せるだけでは足りず、運用し続けられる必要がある。AWS は Observability と Evaluations を通じてセッション数、レイテンシ、エラー率、 本番トラフィックの継続評価を可視化する。つまり「仕事を続ける agent」には、結果だけでなく過程を観測する面が必要になってきた。

OpenAI は、継続仕事の利用面を一気につないだ

Projects は週次調査のような定例タスクを再利用する器になり、Tasks は user が席を外していても動く予定実行を持ち、 Apps はデータ source を search するだけでなく更新操作まで扱う。そこへ Codex が background computer use、継続作業、 記憶機能、自動実行を足したことで、「会話の外でも仕事を続ける」面が一つの流れとして見えるようになった。

Anthropic は、継続仕事の設計原則をはっきり言語化した

Managed Agents はセッションを追記型ログとして扱い、推論部、実行部、sandbox を分ける。Claude Agent SDK もセッション再開を明示し、 code execution tool は pause_turn と container reuse を持つ。Anthropic の強みは、長い仕事を続けるために何をモデル文脈の外へ出すべきかを、 実装原則としてかなりはっきり書いている点にある。

Google は、継続状態の契約を細かく分けた

Vertex AI Agent Engine Sessions は event、state、memory を分け、ADK は state を作業メモ、artifacts を大きな生成物の持ち場として分離する。 さらに session TTL や session listing まで公開面に出しているので、継続仕事を「いつ消すか」「どこまで残すか」まで含めて設計しやすい。

AWS は、継続仕事の本番運用面を強く押し出した

AgentCore Runtime は async agent と session isolation を中核に置き、Observability は実行経路と運用指標を可視化し、 Evaluations は本番トラフィックを継続的に採点する。つまり AWS は「持ち越せるか」に加えて、「本番で見守り続けられるか」を比較軸に入れている。

定期実行は、無人化とは違う

Tasks や automations が増えたことで、agent は user が離れている間も仕事を進められるようになった。 ただしこれは、全判断を無人化できるという意味ではない。実際に価値が出るのは、定期的に起動し、 必要なところだけ人に戻して、次の作業へ引き継げる時である。

記憶は正しさの代わりではない

Codex の memory や Google の cross-session memory は継続性を強くするが、古い判断も持ち越す。 継続仕事で重要なのは remember できることより、どの文脈を再利用し、どの文脈を捨てるかを設計できることだ。

resume は recoverability の問題でもある

OpenAI の snapshotting and rehydration や Anthropic の durable session log が示すのは、継続仕事の本質が会話保持ではなく復旧可能性にもあることだ。 container が落ちても、前の続きへ戻れるなら長い作業は実務に載せやすい。

継続性は auditability とセットで効く

AWS Observability が trace、latency、error rate、session count を前面に出すのは偶然ではない。 長く動く agent ほど、「何をしたか」を後から追えなければ、安心して任せられない。

週次の調査・報告

• project に過去のメモ、ソース、指示を残しておく
• task や automation で定期実行し、前回の続きを踏まえて次の下書きを作る
• Apps で Slack、Drive、Notion から最新文脈を引く

数日がかりの実装や検証

• sandbox や container を再開できると、途中のファイル状態を保ったまま続けやすい
• 成果物やセッションログが残ると、人が途中で review しやすい
• 同じ task を毎回最初から説明し直す必要が減る

SaaS をまたぐ定型フォローアップ

• Apps や tools で必要な時だけ外部 service に触る
• 定期実行と記憶機能があると、未処理項目の follow-up を日次で続けやすい
• ただし更新操作は confirmation と権限境界が前提になる

監査が必要な内部業務

• セッション数、レイテンシ、error、trace を見られると、運用責任を持ちやすい
• 継続評価があると、表面的な成功率ではなく drift を追いやすい
• resume できることと audit できることは、同じくらい重要になる

知識仕事中心なら、project と app 連携が先に効く

調査、企画、文書レビュー、フォローアップのような仕事では、まず必要なのは durable compute より、Projects、Apps、memory、定期実行である。 どこに途中メモを残し、どの外部情報を次回に引くかが品質差になりやすい。

開発作業なら、sandbox と artifact の層が重要になる

数日がかりの実装、検証、移行では、session だけでは足りない。途中ファイル、生成物、検証結果を次回に残せるかが重要になる。 この点では、resumable sandbox や container reuse を前面に出す製品が有利である。

業務システム横断なら、identity と approval が先にボトルネックになる

Slack、Gmail、Notion、社内 SaaS をまたぐ follow-up は魅力的だが、実務の詰まりどころは memory ではなく write action の統制である。 どの更新を自動で許可し、どこで確認を入れるかを決めないと継続性は逆に危うくなる。

内部運用なら、観測面の弱さが最初の限界になる

ops や高信頼系の仕事では、agent が続けられること自体より、失敗をどう見つけるかが重要になる。 traces、error breakdown、session count、token usage まで揃って初めて、継続仕事を本番に載せやすくなる。

1. resume 成功率

停止後にどれだけ自然に前の続きへ戻れるか。container 交換、session 再取得、artifact 再読込を挟んでも品質が落ちにくいかを見る。

2. stale context 事故率

古い state や memory を引き継いだ結果、もう不要な前提で作業を続けてしまう頻度を測る。継続仕事ではこの失敗が目立ちやすい。

3. artifact handoff 品質

途中成果物が次の run や次の人間 reviewer にとって読めるか、再利用できるか、version を追えるかを見る。長い仕事ほど最終返答より重要になる。

4. 介入コスト

人がどれだけ頻繁に止め、説明し直し、方向修正しなければならないかを見る。継続性の良い agent ほど、介入の粒度を粗くできる。

プロダクト側は、仕事の単位を先に定義する

conversation 単位で見るのか、project 単位で見るのか、週次の recurring task 単位で見るのかで、必要な continuity layer は変わる。

基盤側は、state と compute を分離して持つ

Managed Agents や Agents SDK が示すように、context storage と execution environment を分けた方が durability と recovery は設計しやすい。

運用側は、trace と review loop を標準装備にする

継続タスクの agent は、単発 chatbot より incident response に近い。監視、失敗分類、再実行の流れを先に標準化した方がよい。

現場側は、全部を自動化せず「持ち越しやすい仕事」から始める

調査継続、PR follow-up、未処理コメント整理、定例レポート下書きのように、途中状態が価値を持つ仕事から入る方が継続性の利点が見えやすい。

schedule だけでは品質は上がらない

定期実行は便利だが、成功条件と見直し手順がなければ、agent は古い前提のまま同じ作業を繰り返すだけになりやすい。

持ち越す文脈が古くなる

project memory や session state は便利だが、古い判断や誤った前提まで残す。継続性は思い出し精度だけでなく、何を捨てるかの設計に依存する。

外部 action は identity と approval が前提である

Apps や browser 操作が広がるほど、更新操作、OAuth、workspace control、audit trail の設計が重要になる。継続仕事は、権限の話を避けて通れない。

observability は success definition の代わりではない

trace や metric が見えても、「何をもって成功とするか」が弱ければ改善できない。継続仕事の agent ほど、運用指標と task 完了条件を先に固定する必要がある。