こんにちは、レナです。私は、AI エージェントがより長く面倒な作業を行うのを観察することに多くの時間を費やしています。つまり、ファイルの読み取り、ツールの呼び出し、状態の変更、成果物の生成、そして場合によっては、成功した実行を後でシステムが再利用できるものに変えることです。ここで立ち止まったのは、興味深い問題は、LLM がまったく同じ単語を 2 回言えるかどうかではないからです。より良い問題は、チームがエージェントの実行を振り返り、実際に何が起こったのかを理解できるかどうかです。
ここで、決定論的リプレイが重要になり始めます。この記事では、決定論的リプレイ LLM 業界標準プロトコルを、魔法の繰り返しボタンではなく、監査と検証の問題として扱います。リプレイ可能な実行で何をキャプチャする必要があるのか、どのような公的標準が役立つのか、相互運用性がまだ欠けているところはどこなのか、再利用可能なエージェント エクスペリエンスが再び信頼される前に証拠と結び付けられる必要がある理由を見ていきます。
LLM エージェントにとって決定論的リプレイが意味するもの
リプレイ可能な状態、ツール呼び出し、および成果物
リプレイ可能なエージェントの実行には、実行前、実行中、実行後の状態の記録が必要です。これには、元のユーザー要求、システム命令、取得されたコンテキスト、メモリ状態、ツール権限、モデル バージョン、ツール呼び出しペイロード、ツール応答、生成されたファイル、中間成果物、および最終出力が含まれます。
ここでのキーワードは「状態」です。エージェントがファイルを編集したり、データベースにクエリを実行したり、ブラウザ ツールを呼び出したり、保存されたワークフロー メモリを使用したりした場合、再生レコードにはその遷移が表示されるはずです。状態遷移がなければ、レコードはトランスクリプトになります。トランスクリプトは便利ですが、再現可能なエージェント実行には十分ではありません。
反復可能な動作は同一のテキストではありません
ここで注意したいのです。リプレイは、毎回の実行で同じ文言として販売されるべきではありません。 LLM システムは、サンプリング設定、ホストされたモデルの更新、取得の変更、ツールの遅延、外部 API の動作の影響を受ける可能性があります。強力なリプレイシステムは、代わりに動作比較をサポートする必要があります。同じ入力と凍結された依存関係によって、同じツール プラン、同じファイル変更、同じ検証結果、および同じ再利用可能なエクスペリエンス候補が生成されましたか?
エンジニアリング チームにとって、それは実際的な信頼の単位です。正確な段落は異なる場合があります。監査されたパスが謎であってはなりません。
リプレイシステムがキャプチャする必要があるもの
入力、バージョン、環境、および状態遷移
本格的なリプレイ記録は、最初のモデル呼び出しの前に始まります。プロンプトレイヤー、ポリシー制約、メモリスナップショット、スキルバージョン、依存関係ハッシュ、モデル識別子、サンプリングパラメータ、重要な環境変数、実行に使用されるサンドボックスまたはランタイムプロファイルをキャプチャする必要があります。
記録にはタイムラインも必要です。各イベントには、何が起こったのか、いつ起こったのか、どのエージェントまたはツールがそれを引き起こしたのか、どのような状態が使用されたのか、どのような状態が生成されたのかが示されている必要があります。ここで、LLM エージェント プラットフォームの決定論的リプレイ標準は、AI の語彙ではなく、システム エンジニアリングに重点が置かれるようになります。
ツールの結果、チェックポイント、検証証拠
ツール呼び出しには、エージェントの失敗の多くが隠れているため、特別な扱いを受ける必要があります。リプレイシステムは、リクエスト ペイロード、正規化されたレスポンス、エラー本文、再試行動作、タイムアウト、許可スコープ、および編集されたフィールドを保存する必要があります。ツール データを直接保存できない場合、システムは少なくとも署名された参照、スキーマ バージョン、ハッシュ、および保持ポリシーを保存する必要があります。
チェックポイントも重要です。長期にわたるエージェントの実行が 1 つの巨大な塊になってはいけません。計画の承認、ツールの出力の検証、生成された成果物、テストの合格、人間の承認、経験者候補の昇格といったレビュー ポイントが必要です。後で実行が再利用可能なエージェントのナレッジになった場合、再利用が許容されるようになった検証証拠が再生レコードに表示されるはずです。
リプレイに関する標準とプロトコル
監査ログ、来歴、およびイベント スキーマ
現在、すべての LLM エージェント プラットフォームで実装されている単一の「エージェント リプレイ プロトコル」は存在しません。存在するのは、チームが参考にすることができる一連の隣接する標準と実践です。来歴作業は 1 つのレイヤーです。 W3C PROV モデル は、エンティティ、アクティビティ、エージェント、派生、および責任に関する有用な語彙を提供します。これは LLM エージェント専用に設計されたものではありませんが、そのメンタル モデルはリプレイ記録に驚くほどよく適合します。
イベント構造は別のレイヤーです。 CloudEvents 仕様 は、エージェント プラットフォームがキュー、ログ、Webhook、およびワークフロー エンジンにわたるポータブルなイベント エンベロープを必要とする場合に役立ちます。エージェント イベントには依然としてドメイン フィールドが必要ですが、共通のエンベロープを使用すると、各チームが別の互換性のないタイムスタンプとペイロードの形式を作成するのを避けることができます。
ログだけではなく再利用可能なエクスペリエンスについて考えているチームの場合、記事のこの部分で GEP コンセプト ページ の隣に EvoMap Research を配置すると役立ちます。重要な橋渡しはシンプルです。リプレイ記録によって、エクスペリエンス アセットが信頼、昇格、拒否、または取り消された理由が説明されます。
相互運用性がまだ欠けているところ
欠落している層は、広く採用されている完全なエージェント固有の再生セマンティクス層です。現在の標準は、エージェントとツールのセマンティクスの一部をカバーしていますが、「ツールの意図」、「メモリの読み取り」、「ポリシー ゲート」、「人間の承認」、「検証パス」、または「エクスペリエンスの再利用候補」のすべてにわたる共通の語彙をまだ定義していません。
そのギャップが重要なのです。共有セマンティクスがなければ、あるプラットフォームの不変監査ログを別のプラットフォームのデバッガー、コンプライアンスレビュー、または調達監査に移植できない可能性があります。チームは JSON をエクスポートできますが、意味をマッピングする必要があります。これが、私が 1 つの内部スキーマを早すぎる段階で業界標準と呼ぶことを避けたい理由です。現時点での実用的なアプローチは、可観測性、来歴、イベントソーシング、AI ガバナンスの実践を組み合わせてリプレイ システムを構築することです。
リプレイ可能なエージェント実行のリファレンス アーキテクチャ
イベントソーシングと不変の実行レコード
実際の再生アーキテクチャは、イベント ソーシングから始めることができます。エージェントは現在の状態を単に上書きするわけではありません。イベントが追加されます: 実行の作成、コンテキストのロード、モデル呼び出しの要求、ツール呼び出しの発行、ツール結果の受信、成果物の書き込み、検証の実行、レビューの完了、メモリの更新、エクスペリエンスの提案。
各イベントは書き込み後に不変である必要があり、修正はサイレント編集ではなく新しいイベントとして追加されます。これにより、チームは後で検査できるチェーンが得られます。部分的な再生も可能です。計画フェーズのみ、ツールの実行のみ、または検証ゲートのみを再生できます。
実行レコードは、イベント ログ、成果物 ストア、状態スナップショット ストア、および検証証拠ストアの 4 つのストアを接続する必要があります。 エージェント ワークフロー メモリ ページ は、ワークフロー メモリを曖昧な「メモリ」機能として扱うべきではないため、当然ここに属します。これは、メモリを再利用可能にした実行中の証拠と関連付けられる必要があります。
エクスペリエンス再利用前の検証ゲート
エージェントがフィードの将来の動作を実行する場合、リプレイはより重要になります。成功した実行が再利用可能なカプセル、スキル、ワークフロー、または戦略になる場合、プラットフォームにはプロモーション ゲートが必要です。このゲートでは、実行によって正しいタスクが解決されたかどうか、ツールの出力が検証されたかどうか、成果物がテストに合格したかどうか、機密データが除外されているかどうか、安全に再利用できるほどエクスペリエンスが狭いかどうかを確認する必要があります。
これは人々がスキップする静かな部分です。再生せずに再利用するのは危険です。システムは、ショートカットを有効にした条件を記憶していなくても、ショートカットを記憶している可能性があります。
制限とトレードオフ
確率モデル、外部システム、およびストレージのコスト
適切に設計されたリプレイシステムにも限界があります。ホストされているモデルが変更されます。 API は異なるデータを返します。ブラウザは新しいページをレンダリングします。権限の有効期限が切れます。外部システムに触れた実行は、証拠として再生可能である可能性がありますが、同じワールド状態では実行できません。
コストもかかります。完全なリプレイ レコードは大きくなる場合があります。プロンプト、取得されたコンテキスト、ツール ペイロード、スクリーンショット、成果物、トレース、検証ログがすぐに加算されます。チームには保持層が必要です。重要な規制されたワークフローには、より長いレコードが必要になる場合があります。低リスクの実験では、ハッシュとサマリーのみが必要な場合があります。
ガバナンスの枠組みについては、NIST Generative AI Profile がベンダーの主張よりも安全な情報源です。これは、生成 AI リスクを単一のモデル設定ではなくライフサイクル問題として扱うためです。これは法的なアドバイスではありません。保持、削除、常駐、およびユーザーの権利は、該当する管轄区域および関連するすべてのプラットフォームの現在のポリシーと照らし合わせて確認する必要があります。
よくある質問
チームはリプレイ記録をどのくらいの期間保持する必要がありますか?
普遍的な答えはありません。チームは通常、デバッグ、セキュリティ レビュー、顧客との紛争、規制されたワークフロー、再利用可能なエクスペリエンス資産に対して、さまざまな保存期間を必要とします。より安全な設計は、実行ごとに 1 つのデフォルトではなく、タスク クラスごとのポリシー ベースの保持です。
サードパーティ エージェントによって作成されたリプレイ データの所有者は誰ですか?
所有権は、契約、データ処理条件、ユーザー契約、および現地の法律によって異なります。エンジニアリングの観点から見ると、リプレイシステムは、どのエージェント、モデル プロバイダー、ツール プロバイダー、およびユーザー アカウントがデータを提供したかを記録する必要があります。法的な観点から、サードパーティエージェントのトレースを再利用可能な内部資産として扱う前に、弁護士に相談してください。
リプレイレコードは保険や調達のレビューをサポートできますか?
これらは、特に許可、制御、検証、インシデント対応の証拠を示す場合に役立ちます。ただし、リプレイ ログだけでは認定とはなりません。調達チームは通常、ポリシー、アクセス制御、保持ルール、削除ワークフロー、およびレビュー下でシステムが一貫して動作することの証明を必要とします。
リプレイ データは法定保管管轄区域を越えて保存できますか?
場合によっては、しかしチームはそれを想定すべきではありません。再生レコードには、プロンプト、ファイル、個人データ、ビジネス秘密、ツール出力、派生成果物が含まれる場合があります。ストレージ領域、サブプロセッサ、モデルプロバイダー、国境を越えた転送ルールはすべて重要です。リプレイ データを公開または共有する前に、該当するリージョンを確認してください。
リプレイ レコードはユーザーの削除リクエストをどのように処理する必要がありますか?
システムは、生のユーザーデータ、派生成果物、ハッシュ、監査メタデータ、および再利用可能なエクスペリエンス資産を分離する必要があります。すべてを削除すると、監査の整合性が損なわれる可能性があります。すべてを保持すると、ユーザーの権利またはプラットフォームのポリシーに違反する可能性があります。優れた設計では、編集、廃棄、範囲指定された削除、および削除要求が処理されたという証拠がサポートされます。
リプレイは業界カテゴリとして完成していません。そこが正直なところです。しかし、その方向性はすでに見えています。再利用可能なエクスペリエンスを求めるエージェント プラットフォームにはメモリ以上のものが必要です。次回その経験が信頼されるべきである理由を説明するのに十分な強力な記録が必要です。
過去の記事:
- リプレイ可能な状態遷移の背後にある実行層を理解したい場合は、エージェント フックと AI 実行チェーン で、エージェントのアクションがどのようにキャプチャされ、より長い実行期間にわたって接続されるかについて説明します。
- 再現可能なエージェント ワークフローのメモリ側については、エージェント ワークフロー メモリの説明 で、再利用可能なワークフロー エクスペリエンスに単に会話履歴を保存するだけではなく、より多くの構造が必要な理由が説明されています。
- より広範なランタイム アーキテクチャ内に決定論的再生を配置するために、OpenHarness および GEP エージェント スタック レイヤー では、実行インフラストラクチャと再利用可能なエクスペリエンスがエージェント スタックのさまざまなレイヤーにどのように配置されるかについて説明しています。
- 再生された実行が最終的にエージェントが再利用できるものになる場合、エージェント スキルと GEP アセット では、再利用可能な指示と、それらがどのように作成されたかについてより強力な証拠を伴う検証済みのエクスペリエンス アセットとの違いが説明されています。
