Cloudflare Durable Objects の AI 利用：状態と復旧

Cloudflare Durable Objects の AI 利用は、アシスタントが会話や仕事を調整する安定した場所を必要とする場合に役立ちます。難しい設計上の問題は、その状態が何を意味するかです。同じアシスタントに属するからといって、会話履歴、実行中の仕事、承認した業務変更を同じ記録にしてはいけません。

Durable Objects は、明確に識別したアプリの状態の調整に使い、会話履歴、作業状態、外部の業務結果を分けます。中断後は保存済み記録から仕事を再構成し、再接続時に現在権限を確認し、モデルの文脈を正本状態と区別します。永続保存は部品であり、完全な復旧方針ではありません。

保守アシスタントがサービス報告書を準備する場面を考えます。メモを集め、提案を作り、監督者を待ちます。その間にブラウザーが切断し、監督者は別の場所で仕事を開き、承認前に設備記録が変わるかもしれません。

このガイドはその状況に対する状態設計の案です。すべての会話を保持する必要があるとも、オブジェクトの識別子が組織のアクセス境界と自動的に一致するとも主張しません。

Cloudflare Durable Objects の AI 利用には識別モデルが必要

Cloudflare は Durable Objects を、状態を持つアプリを調整する基盤と説明しています。AI 機能に割り当てる前に、会話、受理済み作業、共有資源、その他の限定単位のどれを表すか定義します。

会話ごとのオブジェクトは対話に便利です。一方、サービス報告書は会話を超えて残る識別情報が必要かもしれません。複数の同僚が同じ報告書に協力するなら、最初のブラウザーセッションだけに結び付けると、その後のアクセスと引き継ぎが混乱します。

経路の識別子は信頼できるアプリ情報から決めます。別の仕事番号を推測しただけで内容にアクセスできてはいけません。オブジェクトへの振り分けとアプリの認可は別の責任です。

正本となる事実を会話要約の外に保つ

モデルが作った要約は会話継続に役立ちますが、監督者が提案を承認した唯一の証拠にしてはいけません。承認イベントを、報告書の版と認証済み確認担当に結び付けて保存します。

現在の作業段階も明示します。「確認待ち」は以前の会話でアシスタントが覚えた一文ではなく、記録したアプリ状態にします。履歴から仕事が終わったらしく見えても、後のモデル応答で状態変更を創作してはいけません。

Cloudflare の会話状態とメモリのガイド は、保存する会話履歴とモデルへ渡す情報を区別しています。これは重要な実装上の違いです。保存した情報すべてを次のプロンプトに入れる必要はありません。

報告書では、簡潔な作業要約と、選んだ閲覧可能な証拠をモデルに渡す方法があります。アプリは正本となる資料とイベント記録を、独自の権限と保持方針で別に保管できます。

古い判断を拒否する状態変更を設計する

確認可能な報告書ごとに版を与えます。監督者の承認はその版を特定します。確認画面を開いた後で新しいメモが来たら、提案を無効にするか、別に扱うかをアプリが決める必要があります。

操作が来たら現在状態を確認します。古いタブから取り消した報告書を承認したり、繰り返しクリックで二つ目の業務操作を作ったりしてはいけません。受理済みなら確定した結果を返します。

これらはアプリの規則です。状態基盤は実装場所を提供しますが、保守メモの変更が商業的に重要か、どの監督者が権限を持つかは判断できません。

プロセスメモリではなく記録から復旧する

メモリ上の値は一時的な作業状態として扱います。再開に必要な事実と、既に行った外部要求を記録します。再起動時に会話全体をモデルへ再投入せず、現在段階を組み立てられるようにします。

保守報告書では、資料版、下書き版、承認状態、宛先の操作番号を保持します。宛先が報告を受理して応答を失ったときは、もう一つの生成説明より、その番号が役立ちます。

未着手の仕事と結果不明の仕事を分けます。明らかに開始してよいのは前者です。後者では再送前に宛先を調査するか、その重複防止機構を使います。

意味のある段階の間でアプリを中断して復旧を試します。別のエンジニアに、保存証拠から仕事を特定して次の行動を決めてもらいます。通常の成功実演では見えない状態不足を発見できます。

現在の権限で再接続する

同僚が再接続したら、アプリのセッション規則で再認証し、現在の作業権限を確認します。古い会話番号を持つだけで、永久にアクセスできると考えてはいけません。

記録した状態と確認時刻を読み込みます。待機、処理中、失敗、照合待ちのどれかを説明します。進捗を確定できなければ、安心させる回答をモデルに作らせず、不明であると示します。

有用な記憶と期限切れにすべき情報を決める

会話履歴、元文書、運用証拠では、必要な保持期間が異なる場合があります。自動メモリを加える前に定義します。すべての入力を永久保持すると、後の削除とアクセス見直しが難しくなります。

再利用できる好みと作業事実を分けます。好みの報告形式はセッションをまたいで役立つかもしれません。一時的なアクセストークンや撤回した顧客情報は、アシスタントの永久記憶にしてはいけません。

資料を削除したり権限を失効したりしたら、原本だけでなく派生状態も考えます。要約は元と同じ機密事実を含み得ます。保存案、検索抜粋、モデル向け情報の方針がアプリに必要です。

検索中心の記憶については、当社の RAG のデータ鮮度ガイド が索引の更新と削除を扱います。ベクトル検索結果を、仕事の現在段階に関する正本として扱わないでください。

運用できる状態境界を選ぶ

必要性が明らかになる前に、すべての関心事を別オブジェクトにしないでください。境界が多すぎると単純な仕事も追いにくくなります。同様に、すべての顧客と仕事を区別のない共有状態にすると、権限と責任の問題を生みます。

認証済み要求が仕事に到達する道筋、正本の記録、外部の業務影響が起こる場所を図にします。各失敗を説明できるコンポーネントを明らかにします。

Cloudflare の Agents 概要 は実行基盤の全体像を説明します。選ぶ版に適切な文書化済み API を使い、実験的インターフェースをサポート約束に含める前にテストします。

受入集合には、同時に確認する人、反復操作、資料版変更、再接続、宛先停止を含めます。有用なのは単に状態が残ることではなく、正しい権限で正しい仕事を再開できることです。

状態設計と引き継ぎの作業を見積もる

費用は、状態変更、共同作業、資料の関係、復旧要件に依存します。履歴を保存するだけの範囲は、承認と宛先照合を備える作業システムよりはるかに小さなものです。

状態の担当、アクセス規則、保持動作、復旧テストを明示した GBP の提案を求めます。コード変更時に保存記録を進化させる計画も含めます。配置後に既存の仕事が読めなくなってはいけません。

範囲を限定した AI 連携パイロット で、一つの有用な仕事を中心に契約を作れます。ライフサイクル、確認担当、接続システムを添えて状態を持つアシスタント案をご依頼 ください。会話履歴から偶然設計が決まるのでなく、業務に沿った保存設計になります。

よくある質問

AI の記憶は永続保存と同じですか？ 違います。永続保存はアプリ情報を保持し、モデルの文脈は特定の推論に渡す情報です。どの事実が正本で、どれを選択または要約して渡すかを決めます。

会話ごとに仕事を作るべきですか？ 業務に合う場合だけです。一つの会話で複数の候補を話し、受理した仕事が複数の会話をまたぐこともあります。受理済みの仕事には開始画面を超える識別子を与えます。

オブジェクト番号はデータの所有を証明しますか？ いいえ。状態を返す前や操作の受理前に、認証済みの本人情報と現在権限を確認します。推測や再利用した経路識別子で権限を広げてはいけません。

再起動後に何を残すべきですか？ 作業段階、資料と下書きの版、承認、外部操作番号を確定する事実を保存します。一時メモリを受理済み業務の唯一の証拠にしてはいけません。

会話要約で承認を記録できますか？ 説明はできますが、正本の承認は、正確な提案版に結び付く認証済みアプリイベントとして残します。モデルが作った一文に業務変更を認可させません。

古いブラウザー操作はどう扱いますか？ 現在状態と版を照合します。古い判断を拒否または更新し、受理済み操作には必要に応じて記録済み結果を返します。再クリックだけで新たな影響を発生させません。

有用な状態管理パイロットの条件は何ですか？ 本人情報の境界、同時操作、中断、再接続、宛先結果不明を示します。別のエンジニアがモデルに過去を再構成させず、保存証拠から復旧できることが重要です。