エージェントメモリーサービス¶

DataRobotのエージェントメモリーサービスでは、異なるユースケースに対応する2つの異なるAPIが提供されています。 お使いのビルドに合った方法を選択し、その方法に関するドキュメントに従ってください。 1つのアプリケーションで2つをマージする必要はありません。

DataRobotモデル（datarobot.models.memory.Sessionまたはdatarobot.models.memory.MemorySpace経由でアクセス）を使用して、DataRobotのREST APIおよびPython APIクライアントを通じてチャットスタイルの履歴（セッション）を保持および取得する必要がある場合は、チャット履歴APIセクションに説明があるチャット履歴APIを利用します。 詳細については、REST APIおよびPython APIクライアントのリファレンスドキュメントを参照してください。

長期的なmem0スタイルのメモリー（オープンソースのmem0スタックからの移行を含む）を使用している場合、またはmem0製品に準拠した例やリクエスト形式が必要な場合は、mem0 APIを利用します。 このインターフェイスの場合、標準のリソースはmem0ドキュメントです。

クイックスタート¶

以下のクイックスタートワークフローを確認します。

前提条件¶

• Python 3.9以降
• DataRobotアカウント、APIキー、エンドポイントURL（例：https://app.datarobot.com/api/v2）
• pip install "datarobot>=3.17" "mem0ai>=2.0"

環境変数（DATAROBOT_API_TOKEN、DATAROBOT_ENDPOINT）または~/.config/datarobot/drconfig.yamlを使用して、資格情報を一度設定します。 以下のスニペットは、それらを明示的に渡します。

接続する¶

import datarobot as dr

dr.Client(token="<YOUR_DATAROBOT_API_TOKEN>", endpoint="https://app.datarobot.com/api/v2") 

メモリー空間の作成¶

メモリー空間とは、1つのアプリケーションまたは1人のエンドユーザーに対する分離境界のことです。

from datarobot.models.memory import MemorySpace

space = MemorySpace.create(
    description="Acme support assistant",
    llm_model_name="vertex_ai/claude-sonnet-4-6",  # used for mem0 fact extraction
)
print(space.id) 

llm_model_nameは、mem0の事実抽出に使用されるLLMを選択します。 DataRobot LLM Gatewayを通じて利用可能なモデルに対して検証が行われます。不明な名前は拒否され、許可されたモデルを一覧表示する422レスポンスが返されます。 プロバイダーごとに提供されているモデルについては、利用可能なLLMを参照してください。 推論モデルは、事実抽出において処理速度が著しく遅くなるだけでなく、結果の品質も向上しないため、推論機能のないモデルの使用をお勧めします。 あるいは、llm_base_urlを設定することで、メモリー空間をLLM Gatewayではなく、OpenAI互換のカスタムエンドポイントに向けることができます。そのホストは、管理者が設定した許可リストと一致している必要があります。

セッションの作成¶

セッションは1つの会話です。 participantsはMongoDB-ObjectId文字列のリストで、通常はエンドユーザーです。

from datarobot.models.memory import Session

session = Session.create(
    memory_space_id=space.id,
    participants=["67500a000000000000000001"],
    description="Triage chat #42",
)
print(session.id) 

ソフト削除ライフサイクル戦略を指定しない場合、サーバーはデフォルトの戦略（180日間）を割り当てます。

メッセージの投稿¶

各メッセージはイベントです。 bodyは自由形式のJSONです。emitterは送信者を識別します。

event = session.post_event(
    body={"content": "Hello, my deployment is failing"},
    emitter={"type": "user", "id": "67500a000000000000000001"},
    event_type="message",
)
print(event.sequence_id)  # 0 

バッチ追加（最大200イベント、単一トランザクション）：

session.post_events([
    {
        "body": {"content": "Looking at it now."},
        "emitter": {"type": "agent", "id": "67500a000000000000000002"},
        "event_type": "message",
    },
    {
        "body": {"content": "Found the issue - rolling back."},
        "emitter": {"type": "agent", "id": "67500a000000000000000002"},
        "event_type": "message",
    },
]) 

イベントの読み取りと編集¶

# Newest 20 events:
recent = session.events(last_n=20)
for e in recent:
    print(e.sequence_id, e.emitter_type, e.body)

# Edit message #1:
session.update_event(
    sequence_id=1,
    body={"content": "Looking at it now (ETA 5min)."},
) 

update_eventは、楽観的並行性のためにオプションのcreated_atを受け付けます。そのタイムスタンプ以降にイベントが変更されている場合、サーバーは更新を拒否し、呼び出し元は再読み込みして再試行する必要があります。

標準のmem0クライアントを使用したメモリーの抽出¶

このサービスは、メモリー空間ごとにmem0互換のサブルートを公開します。 標準のmem0ai.MemoryClientがそのルートを参照するようにすれば、通常のmem0クライアントは変更なしで動作します（add()、get()、search()、get_all()、delete()）。

from mem0 import MemoryClient

endpoint = f"https://app.datarobot.com/api/v2/memory/{space.id}"
memory = MemoryClient(host=endpoint, api_key="<YOUR_DATAROBOT_API_TOKEN>")

memory.add(
    [{"role": "user", "content": "I deploy on Fridays using ArgoCD"}],
    user_id="alice",
    agent_id="support-bot",
)

hits = memory.search(
    "when do we deploy",
    filters={"user_id": "alice", "agent_id": "support-bot"},
) 

api_keyはDataRobot APIトークンです。 メモリー空間のスコープは完全にURLパス内にあり、追加のヘッダーは不要です。

Session lifecycle and retention¶

Every session carries one or more lifecycle strategies that control what happens to it over time. A strategy pairs an action—soft_delete (hide the session and its events) or extract_memories (promote the conversation to long-term memory)—with a trigger that decides when the action fires. If you do not supply any strategies at creation time, the server attaches a default soft_delete strategy with a 180-day TTL.

The following triggers are available:

session = Session.create(
    memory_space_id=space.id,
    participants=["67500a000000000000000001"],
    description="Triage chat #42",
    lifecycle_strategies=[{"type": "soft_delete", "trigger": {"ttl": 604800}}],
) 

Never-expire sessions¶

The never trigger opts a session out of automatic lifecycle execution entirely: the session and its events are retained until an explicit session delete (or an administrator-triggered permanent deletion) removes them.

session = Session.create(
    memory_space_id=space.id,
    participants=["67500a000000000000000001"],
    description="Application settings store",
    lifecycle_strategies=[{"type": "soft_delete", "trigger": {"never": True}}],
) 

Lifecycle strategies are set when the session is created and cannot be changed afterwards, so the never trigger applies to new sessions only. Sessions created earlier keep the expiry they were given; to hold existing data indefinitely, create a new session with the never trigger and write the data to it.

Use the never trigger for:

• Application system data: Records such as user profiles, settings, and workspaces stored in session metadata, where expiry would break the application rather than clean up stale data. A dormant installation survives any retention window without keep-alive traffic.
• Compliance retention beyond two years: The ttl and idle triggers cap at two years, so a longer retention floor (for example, a six-year regulatory requirement for chat history) is only expressible with never.

Avoid the never trigger for ordinary conversational history: nothing collects never-expire sessions automatically, so deleting them becomes your application's responsibility. Prefer ttl or idle for data with a natural end of life.