Cloudflare Agent Memoryで業務システムにAIエージェントの永続記憶を組み込む受託パターン 2026

Cloudflareが2026年4月30日に発表した 「Cloudflare Agent Memory」 は、AIエージェントの永続記憶（persistent memory）をマネージドで提供する新サービスです。これまで受託案件で AI エージェントを業務システムに組み込むときに、毎回つまずいていた「会話を跨いだ文脈保持」「ユーザー別の記憶」「契約期間中の記憶寿命設計」を、自前のストレージ運用なしで実装できる可能性が出てきました。

業務システムに AI エージェントを入れたい受託案件は、2025 年下半期以降明らかに増えています。ただし「PoCは盛り上がったが、本番では会話のたびに同じ情報を聞き返してくる」という課題で頓挫するケースが多発しており、永続記憶の設計はもはや AI 受託開発の主戦場です。本記事では、Cloudflare Agent Memory を実プロジェクトでどう組み込むか、価格レンジと一緒に整理します。

なぜ「永続記憶」が業務システム AI の本丸なのか

AI エージェントを業務システムに組み込むときの典型的な失敗は、次の 3 つです。

失敗パターン	症状	受託での損失
会話を跨ぐと忘れる	顧客が「前回お願いした件ですが…」と言っても文脈ゼロ	クレーム → 再開発
記憶を全部詰め込む	コンテキストが膨れて精度劣化・コスト増	月額運用費が想定の3倍
記憶の寿命が無設計	退職した社員の発言が永遠に残る	個人情報・コンプラ事故

これらを回避するには、「短期記憶」「中期記憶」「長期記憶」「組織知識」を意図的に分けて設計する必要があり、これまでは Pinecone / Redis / Postgres などを組み合わせて自前で組むのが定石でした。Cloudflare Agent Memory は、この 4 層の記憶を 1 つの API で扱える点が最大の差別化です。

OpenAI Agents SDK v2 のサンドボックス記憶 でも本番運用での記憶設計の難しさを書きましたが、Cloudflare はそこを 「インフラ事業者として一段下のレイヤーで吸収する」 戦略に出てきた格好です。

Cloudflare Agent Memory の主要機能

公式アナウンスから、受託で重要になる機能を 4 つに絞って整理します。

機能	概要	受託での使いどころ
Scoped Memory	ユーザー / セッション / 組織単位で記憶を分離	マルチテナント SaaS の記憶設計
TTL & Retention Policy	記憶ごとに保持期間を設定可能	個人情報の削除義務対応
Semantic Recall	ベクトル検索で関連記憶を引く	RAG / FAQ 補完
Workers AI 統合	Workers から低レイテンシでアクセス	エッジ AI エージェント

特に Retention Policy が API 単位で設定できるのは、個人情報保護法・GDPR・改正電気通信事業法への対応を求められる業務システムでは大きいです。手作業での「1 年経ったら削除」スクリプトを書かずに済みます。

受託で組み込むときの 4 層記憶アーキテクチャ

弊社で AI エージェントを業務システムに組み込むときの、Cloudflare Agent Memory を前提とした 4 層アーキテクチャです。

[Layer 1] 会話バッファ（短期）         直近 10〜20 ターン、TTL: 30 分
   └ Cloudflare Agent Memory: scope=session

[Layer 2] ユーザー記憶（中期）         好み・口調・履歴サマリ、TTL: 90 日
   └ Cloudflare Agent Memory: scope=user

[Layer 3] 組織記憶（長期）            社内ナレッジ・FAQ、TTL: 無期限（手動更新）
   └ Cloudflare Agent Memory: scope=organization

[Layer 4] 監査ログ（永続）             誰が何を聞いたか、TTL: 7 年
   └ Cloudflare R2 / D1（独立管理）

ポイントは Layer 4 の監査ログだけは Agent Memory に乗せないこと。監査要件は「AI エージェントが消し忘れた / バグで上書きされた」を許容できないので、独立した永続ストレージで保持します。

実装サンプル — Workers + Agent Memory

最小構成のエージェント実装例です。

// src/agent.ts
import { AgentMemory } from '@cloudflare/agent-memory';
import Anthropic from '@anthropic-ai/sdk';

export default {
  async fetch(req: Request, env: Env) {
    const { userId, sessionId, message } = await req.json();
    const memory = new AgentMemory(env.AGENT_MEMORY);

    // 短期：直近の会話を取得
    const recent = await memory.recall({
      scope: { sessionId },
      limit: 20,
    });

    // 中期：このユーザーの記憶を意味検索で引く
    const userMemories = await memory.semanticRecall({
      scope: { userId },
      query: message,
      limit: 5,
    });

    // 長期：組織のFAQから関連を引く
    const orgKnowledge = await memory.semanticRecall({
      scope: { orgId: 'gleamhub' },
      query: message,
      limit: 3,
    });

    const client = new Anthropic({ apiKey: env.ANTHROPIC_API_KEY });
    const result = await client.messages.create({
      model: 'claude-opus-4-7',
      max_tokens: 1024,
      system: buildSystem(orgKnowledge, userMemories),
      messages: [...recent, { role: 'user', content: message }],
    });

    // 会話を Layer 1 に書き戻し
    await memory.remember({
      scope: { sessionId },
      ttl: 1800,
      content: { user: message, assistant: result.content[0].text },
    });

    return Response.json({ reply: result.content[0].text });
  }
};

このコードのポイントは、「記憶の Layer ごとに recall API のスコープを変える」こと。スコープを誤ると、ユーザー A の発言がユーザー B に漏れる事故が発生するので、TypeScript の型で scope を絞るのが事故防止のコツです。

既存業務システムへの統合パターン

すでに動いている基幹システムに AI エージェントを後付けする場合、次の 3 パターンが現実的です。

パターン	概要	適合する案件
MCP 経由統合	既存 API を MCP サーバー化し、Agent Memory と連動	内製基幹システム、ERP の AI フロント化
エッジ・サイドカー	フロントの問い合わせ窓口だけに Agent を配置	EC サイト、サポートチャット
ETL + 夜間サマリ	業務 DB を夜間バッチで Agent Memory に同期	顧客分析、CRM の AI アシスト

MCP 経由統合は、既存 API を MCP サーバー化する設計パターン の延長で、Agent Memory を「会話と記憶の層」、MCP を「業務データの層」に分離するときれいに収まります。

コストと価格レンジ — 受託案件への組み込み

Cloudflare Agent Memory の従量課金は、Workers / R2 と同じ「リクエスト課金 + ストレージ課金」のスケールで、PoC〜中規模本番では月数万円〜数十万円のレンジに収まる見込みです。これを前提とした弊社の受託パッケージは次のとおりです。

パッケージ	期間	価格レンジ	主成果物
AI エージェント PoC（記憶設計込み）	4〜6 週	250〜450 万円	プロト + 4 層記憶設計書 + KPI 設計
業務システム統合本開発	12〜20 週	1,000〜1,800 万円	本番システム + MCP 統合 + 監査基盤
運用・改善（月額）	月額	80〜250 万円/月	月次レポート + 記憶チューニング + ガバナンス対応

「AI が会話を覚えていてくれる」という当たり前の体験は、業務システムでも顧客体験でも価値が高く、見積で説得しやすい部類に入ります。これは AI Evals を初手で組む受託パターン と組み合わせて、「記憶 × 評価 × ガバナンス」を運用月額に乗せるのが 2026 年の標準形です。

設計上の落とし穴 5 つ

落とし穴	症状	対策
全記憶を user scope で書く	個人情報過多、削除リクエスト対応が困難	必要最小限を session に閉じる
TTL を未設定	古い情報で誤回答、コスト膨張	API 呼び出し時に必ず TTL を渡す
Semantic Recall を生で出す	関係ない記憶が混入し精度劣化	スコア閾値 + リランキングを挟む
監査ログを Agent Memory のみ	削除事故・改ざんに弱い	R2 + 改ざん検知ハッシュで二重化
ベンダーロック	撤退・移行が困難	抽象化レイヤを挟む（後述）

特に ベンダーロック対策は受託で重要で、弊社では MemoryAdapter インターフェースを必ず挟み、Cloudflare Agent Memory / Redis / 自前 Postgres を 後から差し替えられるようにしています。

まとめ ─ 「記憶を持つ AI」を受託の標準仕様へ

Cloudflare Agent Memory の登場は、AI エージェントを業務システムに組み込む受託案件にとって、「記憶設計のインフラを自前で持たなくていい」という大きな楽になり方です。一方で、スコープ設計と TTL 設計を誤ると個人情報事故に直結するため、初期設計の重要性はむしろ上がっています。

弊社では、AI エージェントを業務システムに組み込む受託開発を、記憶設計 → MCP 統合 → 監査基盤 → 運用月額の 4 ステップで提供しています。「AI を入れたいが、会話の記憶設計や個人情報対応で詰まっている」「既存基幹システムに自然言語インターフェースを後付けしたい」というご相談は お問い合わせフォーム からお気軽にどうぞ。