エージェントの復旧を証明する

結論は明快だ。エージェントが復旧したと言えるのは、依頼された仕事が受入検査を通り、外部への操作結果を照合でき、元の権限が守られたときである。クラッシュ後も残る会話は有用な基盤だ。正しく再開して完了するタスクは、事業を支える能力になる。企業が対価を払うのは後者であり、記録も両者を分ける必要がある。

小さな会社が顧客向け報告書を作っているとしよう。エージェントは資料を取得し、分析を書き、送信要求を出したところで接続を失う。再起動すると会話は依頼を覚えている。それでも肝心の点は分からない。報告書は顧客に届いたのか。もう一度送れば重複するかもしれず、成功と宣言すれば未送信を隠すかもしれない。創業者に経緯を再構成してもらえば、ソフトウェアの復旧が無償の管理業務になる。

これは説明用の仮想場面であり、実際の本番障害の報告ではない。タスクを覚えることと、責任を持って完了することの距離を示している。復旧システムは外部の受領記録を見つけ、保存したチェックポイントと照合し、次に許された操作を選ぶ必要がある。流暢な記憶は、その一つの材料にすぎない。

基盤が引き受ける範囲

OpenAIは9月10日の更新記録でAgents APIをpublic betaとして発表した。概要によると、OpenAI管理下のCodex harnessがセッション、実行管理、文脈圧縮、復旧を担う。アプリケーション側はツールを提供し、ホスト型または自社管理のサンドボックスなど実行環境を選ぶ。永続セッションによりturnをまたいで作業を続けられる。

開発者が自分で組む実行管理の仕組みは減る。同時に、残る責任も明確になる。基盤が会話状態を保持していても、アプリケーションには外部操作が実行されたことを示す確かな記録がない場合がある。最初の再試行より前に、責任の分担を設計しておくべきだ。

QuickstartはGPT-6 Astraでディレクトリツリーのスクリプトを作成・実行する。完了したturnにもツール失敗が含まれ得ること、stream切断後は保存されたセッション情報を取得してから再試行することを説明している。イベントが示すのは処理の進行段階であり、依頼された成果物と実際の動作が完了を裏付ける。

以下は、この境界を検査するための編集上の提案である。OpenAIの復旧保証でも、RobinOSに導入済みの実装でも、AstraがSolより救援に優れるという実測結果でもない。確認した文書は機能と留意点を示しているが、二つのモデルによる本番復旧の統制比較は示していない。

判断に必要な状態を保存する

有用なチェックポイントは五つに答える。何を依頼されたか、何を検証済みか、次に何が許されるか、どの外部操作が実行済みか、何が不確実か。会話ログだけでは答えが何百ものメッセージに散らばる。引継ぎ先のプロセスが直接確認できる形にしておく必要がある。

仮想の報告書タスクなら、出典のハッシュ、承認された原稿の版、通過済み検査、指定された受取人、送信操作の固定識別子を保存する。送ろうとした事実と、実際の受領記録は別々に記録する。試行と確認済み結果を同じ欄に入れてはいけない。

チェックポイントには再確認の条件も必要だ。処理が止まっている間に受取人が変わり、出典が訂正され、権限が失効することがある。関連する版と更新確認の条件が残っていれば、記憶した情報を無条件に現状とみなさず、具体的に比較できる。

未決のツール操作も明示する。要求を送ったworkerが消えた後、後任に見えるべきなのは未解決の操作であり、空の作業リストではない。最初に宛先システムを読む必要があるかもしれない。読めなければ結果はUNKNOWNのままにする。送信の境界で保留しても、独立した準備作業は続けられる。

外部操作に責任者を置く

重複防止は、実際に操作を行うシステムまで届かなければならない。二つのworkerが競合したり、通信失敗より前にメモを書いたりした場合、ローカルの「送信済み」だけでは弱い。宛先が冪等性を提供するなら、同じ業務操作に固定キーを再利用し、宛先の受領記録に照らして再試行を照合する。

宛先が対応していない場合は、単一の実行責任者、永続操作記録、書込み後の読取り検証を組み合わせる。そのうえで残る曖昧さを明記する。確かな受領記録も、先の結果を照会する方法もないエンドポイントから、プロンプトだけで厳密な一回実行の保証は作れない。

復旧用のリースは、二つの正常なworkerによる同時取得を防げる。ただしリースだけでは、前のworkerが外部操作を止めた証明にならない。重要な実行境界で古い所有者を拒否するか、同時実行しても害のない範囲へ操作を絞る必要がある。これは検査すべき設計要件であり、API概要から備わっていると推測する機能ではない。

説明責任の単位は業務操作だ。「承認されたこの版を公開する」という操作の識別は、再接続、再起動、モデル変更後も保持する。新しい会話turnが、いつの間にか新しい公開命令になってはいけない。報告書、ファイル、通知にも同じ原則を、影響に見合う強度で適用する。

元の権限の中で復旧する

推論能力が高くても、委任の範囲は広がらない。Solが報告書の起草だけを許されていたなら、Astraは起草の失敗原因を調べられる。その引継ぎで顧客への送信まで許されるわけではない。一つの宛先だけに送るタスクなら、検査を通すために受取人を増やすこともできない。

依頼主、許可された資源、操作、制限、有効期限をチェックポイントの隣に置く。影響のある操作を再開する前に、現在の権限と比較する。撤回された指示は圧縮後も有効な制約として残す。古い認証情報や不足する権限が見つかれば、その境界で止まり、安全な診断や準備は続ける。

この区別こそ自律性を守る。すでに許された日常作業の承認を、創業者に何度も求めるべきではない。同時に、不在を範囲拡大への同意と解釈してはいけない。有効な権限を再利用し、人だけが判断できる箇所を特定し、本当に判断が必要なら具体的な成果物を持ち帰る。

9月6日のOPC Testは、創業者が常時介入せずに仕事が進むかを問う。復旧はさらに厳しい問いを加える。失敗後も仕事を進めつつ、何を許されていなかったかを覚えていられるか。

上位モデルへの引継ぎを検証する

提案する経路は、Solが範囲の明確なタスクを実行するところから始まる。依存関係が失敗したら、事前に定めた有限の復旧手順を試す。その手順が失敗するか、重要な構造上の曖昧さを解く必要がある場合にAstraへ渡す。チェックポイント、失敗した試行、現時点の成果物diff、権限、受入検査を一緒に渡す。

Astraが返すべきものは、診断、最小の修正、再開できる証拠だ。解決策全体の書き直しは比較の土台を変えてしまう。元のタスク条件と失敗記録を残し、修正の貢献をSolがすでに完成させた部分から分けて評価する。

9月8日のAstra Escalation Ladderは関連する考え方を扱っている。ここでは戻り道も定義する。曖昧な部分が解消したら、同じ制約の下で日常実行へ戻る。上位モデルへの引継ぎは限定した介入であり、全タスクを永久に最高価格のモデルへ移す方針ではない。

現行のAstraモデルページは標準入力・出力単価を100万トークン当たり10・50ドル、Solは4・20ドルと示す。この料金では2.5倍だ。両方とも1,050,000トークンの文脈枠を持つ。ただし、この数字だけでは一件の業務復旧の費用は分からない。長い入力への調整、キャッシュ、ツール、環境、再試行が実際の請求を変える。

失敗を含めた成果費用を測る

復旧率は、対象となるすべての注入障害を分母にし、失敗試行も残して計算する。試験前に成功を定義する。成果物が通過し、必要な外部操作を照合し、制約を守り、完了報告が証拠と一致することだ。未決の証拠を残して停止したタスクは、復旧成功ではない。

状態損失、重複操作、無権限操作、圧縮後の指示保持を別々に記録する。高い復旧率の裏に許容できない重複率が隠れることも、安い請求の裏に創業者の何時間もの介入が隠れることもある。件数と率には対象タスク、観測期間、欠測の理由を添える。

検証済み成果当たり費用には、最初の実行、失敗試行、救援、ツール、環境の費用を含める。創業者の介入分数を現金費用と並べるか、時間価値を明示的な仮定として置く。観測した市場価格のように扱わない。9月10日のFounder Interruption Taxは、注意を計算に含める理由を説明している。

一群の試験で検証済み成果がゼロなら、支出とゼロ成果をそのまま報告する。比率は未定義であり、成果が無料という意味ではない。介入時間を測っていなければゼロを補わずUNKNOWNにする。健全な復旧の採算は、正直な分母に耐える。

公平な比較では、タスク、開始版、利用可能ツール、障害点、受入基準を固定する。モデルと推論設定も記録する。関連する障害分類で繰り返し試し、新しい事例をルーティング規則の検査用に残す。一度の見事な救援は仕組みを示せても、一般的な優位性の証明にはならない。

Murphyに中断箇所を選ばせる

本番権限のないサンドボックスで、元に戻せるタスクから始める。模擬送信先を持つ報告書生成器なら、顧客や資金を実験に入れず、ファイル作成、資料解析、受領確認付き操作を扱える。模擬先に安定した操作ログを持たせ、エージェントの説明とは独立に重複を検出する。

模擬送信の確認後、ローカルの完了記録を保存する直前にプロセスを止める。期待する結果は、既存の受領記録を照合し、二度目の送信をしないことだ。次は確認の前に中断し、再試行を決める前に宛先を調べさせる。危険な時間差を両側から検査できる。

ツール停止、依存関係の破損、進捗streamの切断を別の試験にする。失敗した層を特定し、完成済み成果物を保ち、許された再試行・修正経路を使うべきだ。依存関係の修正は元のタスクが再び通過したときに評価する。ソフトウェアを入れ直して仕事を終えなければ、成功には数えない。

模擬権限を失効させ、出典を新しい版へ差し替え、圧縮を強制し、webhookを再送する。期待動作はそれぞれ違う。期限切れの操作を保留し、古い証拠を発見し、元の制約を保持し、繰り返されたイベントを照合する。各障害を別分類として扱う。通信障害への強さは、古い意図への強さを保証しない。

最後に、模擬ツールが成功と言いながら出力は決定論的検査に落ちる事例を試す。エージェントは見かけの成功を拒否しなければならない。順調な筋書きに従えるかではなく、依頼された結果を守れるかを検査するためだ。

記録を限定的な学習につなげる

復旧記録には開始チェックポイント、注入障害、修正試行、最終diff、操作の受領記録、検査結果、時間、費用を含める。機微な証拠は所属環境に残す。公開記事は顧客情報、私的会話、認証情報を明かさずに仕組みを説明できる。

ルーティングの教訓は反証できる程度に具体的にする。例えば、このタスク分類で、この依存障害と修正失敗の後に引き継ぐと、許可された予算内で検証済み完了が改善した、と記録する。これは候補規則だ。日常経路を変える前に留保した別事例で検証し、前の規則を戻せるよう残す。

Astraが多く費やして同じ結果を出したなら、その分類では安い経路を保つ根拠になる。Solだけで復旧したならAstraを救援者に数えない。両方が失敗したなら失敗を保存し、検査かシステム境界を改善する。ルーティング台帳は魅力的なデモと同じ真剣さで、期待外れの結果も記録する。

本日の出版で完成するのは証拠の枠組みと実験仕様であり、Sol–Astra比較の実施報告ではない。統制試験の記録がそろうまで、復旧率、重複率、創業者分数、費用削減はUNKNOWNだ。出版処理が再開に成功したとしても、それは当該処理の証拠であり、Agents APIやモデル間の比較性能を証明するものではない。

最初の受入カード

最初の実験には一枚の受入カードを使う。タスクと開始版を記し、既存権限と完了を定める検査を列挙する。一度に一つの障害を選び、外部操作ログ、checkpoint diff、完全な費用記録を求める。結果を見る前に、通常復旧を終える条件と救援資格を決める。

結果は短い台帳にまとめる。復旧か未決か、外部操作は照合済みかUNKNOWNか、制約は保持か違反か、創業者分数は観測済みか取得不能か、総費用、次のルーティング仮説。結論を支える生の成果物も残す。図は提案する手順であり、性能測定値は含まない。

同じ権限・重複防止要件の下で、比較可能な試験を繰り返し、検証済み成果当たり費用が下がった場合にだけ救援経路を広げる。それまでは実験を限定する。事業上の価値は、画面が静かになった後も仕事が責任を持って完了し、その証拠が次の復旧を安く、創業者に依存しにくくすることにある。

分類とキーワード

分類： 人工知能、オペレーティングシステム、エージェント評価。

キーワード： 永続セッション、エージェント復旧、チェックポイント、冪等性、権限、Sol、Astra、検証済み成果、ルーティング評価。

Hashtags: #AgenticAI #AgentRecovery #Ouroboros #VerifiedOutcomes