Cloudflare Rust WorkersとAgent Memoryに学ぶエッジ運用設計

Cloudflareが2026年4月に公開した複数の発表は、エッジでAIエージェントを本番運用するチームにとって重要な示唆を含んでいます。Rust Workersにおけるpanic/abort回復の強化、そしてAgents Weekで示されたメモリ管理・セッション運用の実装方針です。

この2つは別々の話ではありません。結論から言えば、エージェント基盤は「プロンプトの工夫」より先に「失敗時の整合性」を設計しないと運用できない、ということです。

まず押さえるべき失敗モデル

Wasm実行時のpanicやabortがインスタンスを汚染し、後続リクエストにまで影響するケースは、エージェント処理では特に危険です。理由は、1つのリクエストに以下が混在するからです。

推論呼び出し
外部ツール実行
永続状態更新
通知やチケット作成

途中で失敗した際に、どこまで確定したかを失うと、再試行で二重実行や矛盾状態が発生します。

副作用は必ず冪等化する

再試行を前提にしない設計は、障害時に必ず破綻します。各ツール操作に対して最低限次を定義してください。

冪等キー（operation id）
状態遷移ルール
同一キー再実行時の返却仕様

例えばIssue作成なら、「成功したか」だけでなく「同じキーなら既存Issueを返す」を保証します。これだけでpanic後の再送事故が大きく減ります。

メモリは3層に分離する

Agent Memoryを導入しても、全情報を1つのメモリ塊に入れると監査不能になります。少なくとも次の3層を分離します。

会話コンテキスト（短寿命）
タスク事実（中寿命）
ポリシー情報（版管理・不変）

推奨TTL例:

セッション記憶: 数時間
タスク記憶: 数日
統制ポリシー: 明示更新まで固定

この分離で、利便性と監査性を両立しやすくなります。

エッジエージェントの制御プレーン設計

1. セッション状態機械を明示する

最低でも以下の状態を持ちます。

initialized
active
waiting_for_tool
completed
failed
quarantined

quarantined を設けるのが重要です。ランタイム異常が疑われるセッションを自動再実行から隔離し、障害の連鎖を防げます。

2. ツール外向き通信をポリシー化

エージェントにブラウザ操作やAPI実行を許すなら、出口制御が必須です。

宛先ホストallowlist
メソッド制限
ペイロード上限
ツール別タイムアウト

Gateway系のポリシーを活用し、アプリ再デプロイなしで制御変更できるようにすると現場運用が安定します。

3. 同時実行とコストの上限管理

エージェントは見えにくいキュー渋滞を作ります。上限は多段で設定します。

テナント単位の同時セッション数
ツール単位の同時呼び出し数
全体のTPM/費用予算

上限到達時はリトライ連打ではなく、延期実行に落とす設計が必要です。

観測設計, プロンプトログだけでは不十分

運用品質を上げるには、次を同じ軸で追跡します。

推論遅延とトークンコスト
ツール呼び出しの成功/失敗
状態遷移の妥当性
再試行系列（冪等キー紐付け）

この4点が揃わないと、障害原因が「モデル品質」「ランタイム不安定」「オーケストレーション不備」のどれか切り分けられません。

事前にやるべき障害注入テスト

本番拡大前に、次のシナリオを実行してください。

ツール実行中にpanic注入
副作用確定直後のネットワーク遮断
メモリ部分書き込み後の再試行
同一セッションへの競合更新
長時間タスク中のリージョン切替

合格基準は「エラーゼロ」ではなく、「エラーが有界で、回復手順が決定的であること」です。

まとめ

2026年のエッジエージェントは、試作フェーズから運用フェーズへ移りました。Rust Workersの回復強化とAgent Memoryの整備は、その転換を示しています。

冪等化、状態機械、出口ポリシー、観測設計。この4点を先に固めたチームほど、機能追加の速度も品質も上がります。エージェントを“賢くする”前に、“壊れても戻せる”ようにすることが最短ルートです。