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

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パス内にあり、追加のヘッダーは不要です。

共有とアクセス制御¶

メモリー空間では、APIやレジストリへのアクセスにユーザーレベルの機能フラグを使用するほか、エージェントメモリーサービスで適用される空間ごとの共有ロールも使用します。

エージェントメモリーAPIへのアクセスを有効にする¶

ユーザーがエージェントメモリーサービスを呼び出したり、レジストリ > メモリー空間を開いたりするには、組織またはシステム管理者が、そのユーザーのプロファイルでエージェントメモリーAPIへのアクセスを有効にする機能フラグを有効にする必要があります。 このフラグを設定しないと、メモリーAPIおよび「メモリー空間」ページは利用できません。

1. 管理者設定を開き、ユーザー管理に移動します。
2. ユーザーを選択し、ユーザープロファイルを表示をクリックします。
3. ユーザー設定で、エージェントメモリーAPIへのアクセスを有効にするを有効にします。

このレイヤーでのアクセスは「すべて許可」または「すべて拒否」の二者択一となります。このフラグでは、メモリーAPIにおける読み取りと書き込みの権限を個別に定義することはできません。 有効にすると、ユーザーは空間ごとの共有設定（後述）に従ってメモリーサービスを利用できるようになります。

メモリー空間ごとの共有ロール¶

アクセスできる各メモリー空間は、自分が所有しているもの、あるいは別のユーザーから共有されたものです。 リストへの表示と可視性は共有（設定）に従います。機能フラグだけでは、組織内のすべてのメモリー空間が公開されるわけではありません。

メモリー空間を作成または取得する際、APIの応答には以下の内容が含まれます。

• rbacResourceId — 共有を適用するために使用されるプラットフォーム識別子（存在する場合）。 通常のエージェントメモリーAPIワークフローでは、このフィールドは必要ありません。
• permissions — その空間で実行可能な操作（CAN_VIEW、CAN_UPDATE、CAN_DELETE、CAN_SHARE）であり、リクエストごとにメモリーサービスによって適用されます。

オーナーおよび共有権限を持つユーザーは、レジストリの共有ダイアログを通じて、他のユーザー、グループ、または組織にコンシューマー、エディター、またはオーナーのロールを付与することができます。 3つのロールはすべて、ロールのドロップダウンから選択できます。 メモリー空間のロールおよびメモリー空間の共有を参照してください。

permissionsの範囲外の操作を行うと、権限不足のエラーが発生します。 スキーマの詳細については、エージェントメモリーサービスのREST API（MemorySpaceResponse.permissionsおよびMemorySpaceResponse.rbacResourceId）を参照してください。

共有空間でメモリーを取り込んだり、イベントを投稿したり、セッションを作成したりするには、その空間のエディターまたはオーナーの権限を持っている必要があります（コンシューマーのみではできません）。

ユーザーのアクセス権を取り消すと、すべての権限が直ちに削除されます。

レジストリでの共有の管理¶

アクセス権の付与、変更、または取り消しは、レジストリ > メモリー空間から、各メモリー空間の共有ダイアログを使用して行います。 これが、コラボレーターの管理においてサポートされているワークフローです。共有は、エージェントメモリーサービスのAPIやPython SDKを通じて提供されていません。

手順の詳細については、メモリー空間の共有を参照してください。

セッションのライフサイクルと保持期間¶

すべてのセッションには、時間の経過に伴う挙動を制御する1つ以上のライフサイクル戦略が割り当てられています。 各戦略は、アクション（soft_delete（セッションとそのイベントを非表示にする）またはextract_memories（会話を長期記憶へ移行する））と、そのアクションがいつ実行されるかを決定するトリガーを組み合わせたものです。 作成時に戦略を指定しない場合、サーバーはデフォルトのsoft_delete戦略（TTL 180日）を適用します。

使用可能なトリガーは以下のとおりです。

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

有効期限のないセッション¶

neverトリガーを指定すると、セッションはライフサイクルの自動実行から完全に除外されます。つまり、セッションとそのイベントは、明示的なセッション削除（または管理者による恒久的な削除）によって削除されるまで保持されます。

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

neverトリガーは以下の場合に使用します。

• アプリケーションシステムのデータ：セッションメタデータに保存されるユーザープロファイル、設定、ワークスペースなどのレコードで、有効期限が切れると古いデータがクリーンアップされるどころか、アプリケーションが機能しなくなってしまう場合です。 休止状態のインストール環境は、キープアライブトラフィックがなくても、いかなる保持期間でも存続します。
• Retention with no end date: Use never when the data must be kept for a period you cannot name today. For an obligation that is longer than two years but still finite, prefer raising the installation's maximum session TTL and keeping a ttl trigger. This allows the lifecycle worker to reclaim the session when the period ends. Confirm the applicable retention period with your compliance owner.

通常の会話履歴にはneverトリガーの使用を避けてください。有効期限のないセッションを自動的に収集する仕組みはないため、それらの削除はアプリケーション側の責任となります。 自然な有効期限があるデータについては、ttlまたはidleを優先して使用してください。

Update retention on an existing session¶

A session created before a retention decision was made can be moved onto a different schedule—including the never trigger, if enabled—by replacing its lifecycle strategies:

session.update(
    lifecycle_strategies=[{"type": "soft_delete", "trigger": {"never": True}}],
) 

The same update through the REST API:

curl -X PATCH "https://app.datarobot.com/api/v2/memory/MEMORY_SPACE_ID/sessions/SESSION_ID/" \
  -H "Authorization: Bearer <YOUR_DATAROBOT_API_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{"lifecycleStrategies": [{"type": "soft_delete", "trigger": {"never": true}}]}' 

The strategies you pass replace the whole list, so send every strategy the session should keep, not just the one you are changing. Omit the argument to leave the strategies untouched while updating other fields. The request is validated exactly as a create is: between one and five strategies, no duplicate strategy types, and the same rules for spaces without an LLM configured. Strategies cannot be cleared—Session.update raises a ValueError for lifecycle_strategies=None, and the REST API rejects an empty list or null with a 422 response.

Other semantics worth knowing:

• The update bumps the session version, and honors the If-Match precondition header like any other session update. Session.update sends the version it last read automatically; pass if_match=None to opt out of the check, or an integer to override it. Over REST, pass the version you last read as the If-Match header.
• A strategy type that has already run for the session cannot be reconfigured: the lifecycle executor never runs a type twice, so a change that could not take effect is rejected with a 409 response naming the type, rather than stored silently. Re-sending such a type with an unchanged configuration is accepted, so read-modify-write updates of the other fields keep working.
• Where the never trigger is not enabled, adding one to a strategy type that did not already carry it is rejected with a 422 response. A session that already stores a never trigger may resend it, so read-modify-write updates keep working. Moving a session off never onto ttl or idle is always allowed.