ログアウト後も動作するエージェントの実行条件を定める

目的

2026年10月25日時点の情報である。操作者が接続を切った後にエージェントが何をしてよいか、どこまでリソースを消費してよいか、その権限がどのように終了するかを定める。導入済みの監督プロセスの再起動動作、資格情報のライフサイクル、リモートのキャンセル対応を再確認する。この実行条件の提案は、サービスアカウントの設定を補い、無人実行全体を制御するためのものである。

前提条件

責任を負う担当者、永続的なタスクストア、モデルから独立して作業を停止できる監督プロセスを定める。ローカルプロセス、委任先の子エージェント、リモートジョブを一覧にする。対話セッションとは異なり、このワークフローでは確認を求められない場合の対応を決めておく必要がある。作業が進められない状態を永続化し、承認された経路で責任者に通知する。

手順

1. 実行条件を記録する。 目的のリビジョン、許可されたリソースと操作、出力先、有効期限、予算、エスカレーション経路を保存する。サービスには専用の制限付きIDを与え、開始したユーザーは別途記録する。対話用の資格情報ストアをコピーして、サービスのID設定に流用してはならない。
2. 必要なアクセス権だけを付与する。 プラットフォームのワークロードID機能を使う。Kubernetesのサービスアカウント文書は、ワークロードごとに異なるIDを用いることと、API資格情報を自動マウントすべきでないPod向けのautomountServiceAccountToken: falseを説明している。アクセス先のリソースで権限を狭く設定する。資格情報の更新によって、タスクの認可期間を暗黙に延長してはならない。
3. タスク全体の予算を管理する。 子エージェント、再試行、プロセスの再起動をまたいで、累積消費量を永続化する。経過時間、モデルとツールの呼び出し、同時実行数、ストレージ、有料サービスに制限を定める。並行ワーカーが共通の利用枠を超える可能性がある場合は、作業を送出する前に枠を予約する。どの制限を監督プロセスまたはゲートウェイが実際に強制するのかを文書化する。プロンプト中の一文は、要求にすぎない。
4. 独立した停止経路を設ける。 有効期限切れや操作者による停止の際は、新たな作業の送出を止め、その実行の自動再起動を無効にし、追跡中の作業のキャンセルを要求する。利用できる場合は、書き込みゲートウェイで認可の有効期限を強制する。停止完了を報告する前に、リモート側ですでに受け付けた操作の結果を照合する。未解決の影響を見える状態に保ち、再起動後の無確認の再実行を防ぐ。
5. プラットフォームの制御を正確に対応付ける。 KubernetesのJobは、activeDeadlineSecondsと一時停止に対応する。Jobを一時停止すると、稼働中のPodが終了し、再開時には実行期限のタイマーがリセットされる。そのため、認可の絶対的な有効期限をこのタイマーとは別に保持する。一時停止はプロセスのライフサイクル制御として扱い、復旧にはアプリケーションの永続的なチェックポイントを用意し、リモート側の結果は別途検証する。
6. 無人実行の状態を確認可能にする。 タスクと試行の識別子、目的のリビジョン、IDへの参照、予算の使用量、ツールの結果、停止理由を、秘密情報を含めずに記録する。OpenTelemetryのコンテキスト伝播は、サービス間のトレースを関連付ける。ワークロードをクリーンアップする前に、必要なログをエクスポートする。KubernetesのJobでは、kubectl get job JOB -o yamlで記録された状態を表示できる。kubectl logs jobs/JOBは出力を確認する出発点であり、すべての試行の完全な履歴ではない。

期待される結果

接続を切った操作者が、誰が実行を承認したか、何がまだ稼働中か、書き込み権限がまだあるかを確認できる。ワーカーを再起動しても、残りの予算と元の有効期限が引き継がれる。完了、入力待ち、停止処理中、リモート側の結果が未解決の状態を区別できる。

限界と検証の根拠

これは手順の提案であり、検証済みのデプロイではない。隔離した環境で、模擬のリモート操作が保留中の間に、操作者の切断、割り当て枠の枯渇、再起動、有効期限切れを試す。制限に達した後は新たな操作が受け付けられず、保留中の影響が記録され続けることを確認する。プロセスの終了は、リモート操作が取り消された証拠にはならない。