Memclaw

Caura — AI エージェント向けの共有・ガバナンス管理型メモリ

AI エージェント群のためのフリートメモリ — ガバナンス管理、共有、自己改善。

MemClaw は Caura になりました — 製品はそのまま、名称が統一されました。
既存の memclaw_* ツール呼び出しと、サポート対象の MEMCLAW_* 環境変数エイリアスは引き続き機能します。新しい設定では caura_* 名と現在の Caura の URL を使用してください。PyPI の memclaw-client という名前は、caura-client をインストールするリダイレクト用のシェル（0.5.1）としてのみ残されています。memclaw_client のインポートも MemClaw クラスも提供しません。npm パッケージの @caura/memclaw-client は公開されたことがありません。

クイックスタート · 機能 · フリートメモリガイド · パフォーマンス · MCP · API リファレンス · プラグインのドキュメント · 貢献 · Discord

---

Caura（旧 MemClaw）— AI エージェント群のための共有・ガバナンス管理型メモリレイヤー

Caura（旧 MemClaw）は、マルチテナント、マルチエージェントの AI エージェント群向けのオープンソースメモリです。エージェントは学んだことを保存し、フリートが把握していることを見つけ、やり取りのたびに賢くなります。失敗を繰り返すのではなく、互いから学習します。

エージェントはプレーンテキストを書き込みます。Caura はそれを検索可能で、ガバナンス管理された、自己改善型のメモリに変換します。

1 つのループ、3 つの柱：書き込み、想起、蓄積 — やり取りのたびに、次のやり取りがより賢くなります。

フリート向けに構築。 1 つのエージェントでも動作し、多くのチームはそこから始めます。以下の内容は、単一エージェント構成でも何も変わりません。Caura がもたらすのは、拡張の余地です。スコープ付きメモリ、エージェント間での成果の伝播、フリート全体の信頼ティアは、最初の書き込み時点から利用でき、エージェントが増えるほど効果を発揮します。公開されているエージェントメモリのベンチマーク（LoCoMo、LongMemEval）は、1 つのエージェント、1 人のユーザー、1 件の長い会話という、単一チャットボットの形態を測定します。フリートのガバナンスとワークロード固有のレイテンシーについては、実際に重要となる環境での検証が引き続き必要です。承認済みのベンチマーク結果は、自動生成されたパフォーマンスブロックとエビデンスレジストリをご覧ください。または、ベンチマークの解説をご覧ください。

本番環境の導入事例： eToro は、AI エージェントの業務において、ガバナンス管理された共有メモリレイヤーとして Caura を使用しています。 アーキテクチャの詳細 →

---

クイックスタート

ローカルで試す — API キーも登録も不要

Caura の動作をすぐに確認できます。スタンドアロンモードは認証をバイパスしてシングルテナントで実行されるため、Caura を起動してメモリを書き込み、もう一度見つけるだけです。（キーがない場合、設定は不要です。メモリは埋め込みなしで保存され、キーワードで検索されます。セマンティック検索を使うには、AI プロバイダーキーを追加してください。詳しくは下記のセルフホストを参照してください。）

git clone https://github.com/caura-ai/caura.git
cd caura
cp .env.example .env && echo "IS_STANDALONE=true" >> .env   # single-tenant, no API key
docker compose up -d --wait                                 # Postgres + pgvector + Redis + API + scheduler (~30s)

# Write a memory — no API key needed
curl -X POST http://localhost:8000/api/v1/memories \
  -H "X-API-Key: standalone" -H "Content-Type: application/json" \
  -d '{"tenant_id": "default", "agent_id": "quickstart", "write_mode": "strong", "content": "Our auth service uses JWT with 15-minute expiry."}'

# Find it by keyword — no provider key needed
curl -X POST http://localhost:8000/api/v1/search \
  -H "X-API-Key: standalone" -H "Content-Type: application/json" \
  -d '{"tenant_id": "default", "query": "JWT expiry"}'

キーなしの場合、強い書き込みのレスポンスには memory_type、title、status、weight が含まれ、さらに metadata の下に summary が含まれます。これらはすべて、単一の content フィールドから決定論的なローカルヒューリスティックによって導出されます。AI プロバイダーを設定している場合、これらの値はモデルによって推論され、metadata には tags も含まれることがあります。

セマンティックな言い換えを試しますか？ キーなしのクエリでは、意図的にメモリ内の単語を再利用します。次のセクションで 埋め込みプロバイダーを設定した後は、代わりに "authentication token lifetime" を試してください。 このフレーズで「JWT with 15-minute expiry」を検索すると、セマンティック検索を体験できます。

フリートでの効果を確認する

アーキテクチャ、評価チェックリスト、安定した GitHub ネイティブの引用先については、 AI エージェントフリート向けの共有永続メモリを参照してください。

2 つの MCP クライアントを同じフリートに接続します。エージェント A が caura_write で運用上の 教訓を記録します。

{
  "agent_id": "deploy-agent",
  "fleet_id": "platform",
  "visibility": "scope_team",
  "content": "Roll back auth-service with: deployctl rollback auth-service --to <version>."
}

エージェント B がそのフリートから caura_recall を呼び出します。

{
  "agent_id": "incident-agent",
  "fleet_ids": ["platform"],
  "query": "How do I roll back auth-service?"
}

結果には、作成者として deploy-agent が示されます。つまり、あるエージェントが学んだ内容を、 別のエージェントが再利用しています。scope_agent を指定するとメモリは非公開のままになり、 scope_team はフリート内で共有し、scope_org は信頼レベルに従って管理されたフリート間検索を可能にします。 本番環境では、各クライアントに独自のエージェントスコープの認証情報を付与してください。

セマンティック検索、マルチテナント、マネージドホスト、または OpenClaw フリートを利用しますか？以下から方法を選んでください。

---

4 つの方法から、ご利用の環境に合うものを選んでください。

方法	対象	最初のメモリまでの時間
マネージドプラットフォーム	最も手軽です。データベースとスケーリングをこちらで管理します。	約2分
セルフホスト（Docker）	プライバシー／オンプレミス／エアギャップ環境向けです。	約5分
OpenClaw プラグイン	すでに OpenClaw フリートを運用している場合は、上記のいずれかを使って Caura をプラグインとしてインストールできます。	約3分
Rail SDK	Python または TypeScript でエージェントを自作し、各ターンの前にルールや事実を検索し、学んだ内容をその後に保存したい場合に適しています。上記のいずれでも利用できます。	約2分

マネージドプラットフォーム

数分で利用を開始できます。インフラの管理は不要で、自動更新、利用状況の分析、エンタープライズグレードのセキュリティも含まれています。

1. caura.ai で無料登録。
2. ダッシュボードの Connect › Keys から API キーを作成します。
3. MCP または REST で接続します。

{
  "mcpServers": {
    "caura": {
      "url": "https://caura.ai/mcp",
      "headers": { "X-API-Key": "mc_your_api_key_here" }
    }
  }
}

本番環境のフリートでは、エージェントごとにエージェントスコープの認証情報を 1 つずつ用意してください。 認証情報のスコープ、ヘッダー、プロビジョニングについては、 OpenClaw プラグインを使わない連携を参照してください。

テナントスコープのダッシュボードキーを使用していますか？すべての MCP ツール呼び出しに明示的な agent_id を渡してください。この経路では、ゲートウェイが予約済みの mcp-agent デフォルトを拒否します。

セルフホスト（オープンソース）

Docker Compose を使うと、PostgreSQL + pgvector、Redis、ストレージサービス、REST/MCP API、および core-operations ライフサイクルスケジューラー（夜間の有効期限切れ処理、アーカイブ、パージ、結晶化）が起動します。上記のキー不要の例が最短の手順です。セマンティック検索にはプロバイダーを追加してください。

• セルフホスト完全ガイド — プロバイダー、認証、サービスのトポロジー、セキュリティ、オフライン運用、テスト
• ローカル埋め込みモデル — クラウド API を呼び出さずに、完全ローカルでセマンティック検索
• Docker を使わない手動デプロイ

OpenClaw プラグイン

すでに OpenClaw フリートを運用していますか？Caura をプラグインとして、マネージドプラットフォームまたはセルフホストのスタックに接続してインストールできます。

このプラグインは OpenClaw の memory スロットを引き受け、エージェント向けの同じメモリツールを提供します。エージェントインストーラーのワンライナー設定を使い、その後、OpenClaw 統合ガイドでエージェントのプロンプトと信頼レベルを確認してください。すでにノードを稼働させていますか？ノードを最新の状態に保つ方法（自動アップグレードと手動再インストール）については、docs/plugin-upgrade.mdをご覧ください。

このプラグインが通信するのは、設定した Caura サーバー（CAURA_API_URL）だけです。すべてのリクエストで User-Agent: openclaw-plugin/<version> (node/<major>) を使用して自身を識別します。セルフホストサーバーのハートビート機能はこれを使って接続済みのプラグインのインストール数を集計します。また、書き込みによって生成された監査行のラベル付けには X-Caura-Surface: openclaw_plugin を使用します（監査の帰属）。CAURA_API_KEY を、ループバック以外の宛先へ通常の http:// 経由で送信することはありません。CAURA_API_URL に https:// を指定するか、プラグインの .env で CAURA_ALLOW_INSECURE_HTTP=true を設定して、信頼できるプライベートネットワーク上で平文通信を許可してください。

Python クライアント

マネージドまたはセルフホストの Caura デプロイに、Python から接続できます。

pip install caura-client

使用例と API の全容については、Python クライアントガイドをご覧ください。

TypeScript クライアント

Node 18+ クライアントには、ランタイム依存関係がありません。

npm install @caura/client

インストール方法とパッケージ名の互換性については、TypeScript クライアントガイドをご覧ください。

Rail SDK

エージェントのすべてのターンでメモリを利用できるようにします。Rail はエージェントの実行前にガバナンスルールと現在のメッセージに関連する情報を取得し、プロンプトですぐに使えるコンテキストを渡します。その後、そのターンで得られた情報を抽出して保存します。Python と TypeScript は同じセマンティクスを共有し、どちらもマネージド Caura とセルフホスト Caura の両方で動作します。

pip install caura-rail        # Python 3.10+
npm install @caura/rail       # Node.js 22+

CAURA_URL と CAURA_API_KEY を使って任意の Caura に接続し（上記のスタンドアロン Docker サーバーの場合は、http://localhost:8000 と standalone）、エージェントの各ターンをラップします。

from caura_rail import MemoryScope, Rail, RestMemoryStore

with RestMemoryStore.from_env() as store:
    rail = Rail(store, MemoryScope(agent_id="support-1", fleet_id="support"))
    with rail.turn("Remember: We deploy in eu-west-1.") as turn:
        # Call your model here; turn.context.text holds rules first, then facts.
        turn.reply = "Noted. " + turn.context.text
    print([w.status for w in turn.writes])   # ['written'], or ['deduplicated'] on a rerun

import { MemoryScope, Rail, RestMemoryStore } from "@caura/rail";

const rail = new Rail({
  store: RestMemoryStore.fromEnv(process.env),
  scope: new MemoryScope({ agentId: "support-1", fleetId: "support" }),
});
const turn = await rail.turn("Remember: We deploy in eu-west-1.", (_, ctx) => "Noted. " + ctx.text);
console.log(turn.writes.map(w => w.status));   // ['written'], or ['deduplicated'] on a rerun

各ターンでは情報を取得し、コードを実行し、抽出して書き込みます。コードが例外を発生させたターンでは何も書き込まれません。一時的なエラーで失敗した書き込みは送信待ちキューに入り、後から再送できます。API の呼び出しだけが必要な場合は上記のクライアントを、エージェントに記憶させてルールに従わせる場合は Rail をお使いください。ガイド、API リファレンス、信頼性のセマンティクスはRail リポジトリにあります。

---

⭐ Caura が役に立ったら、 リポジトリにスターを付けてください — 他のフリート開発者が Caura を見つけるきっかけになり、OSS エディションにどれだけ時間を投資できるかにも影響します。

---

機能

ガバナンス

• テナント分離 — テナントごとにデータベースを行レベルで分離し、書き込みのたびに PII を自動検出してフラグを付けます（メモリのメタデータに contains_pii／pii_types として表示）
• 可視性スコープ — すべてのメモリに書き込み時にスコープを付与します。scope_agent（非公開）、scope_team（フリート全体、デフォルト）、または scope_org（フリートをまたぐ範囲）です。フリートをまたぐ想起には権限が必要で、誰でも利用できるわけではありません
• エージェントの信頼レベル — 4 つのレベルで、フリートをまたぐ読み取り、書き込み、削除を制御します。エージェントは、管理プラットフォーム（caura.ai）上の POST /admin/agent-keys/provision によってアトミックにプロビジョニングされるか（セルフホストの core-api にはこのルートはありません）、初回の書き込み時に自動登録されます
• 完全な監査ログ — すべての書き込み、削除、遷移をテナントとスコープのコンテキストとともに記録します
• エージェントアクティビティダイジェスト — オプトインした組織向けに、エージェントごとのダイジェストをサーバー側で生成します（組織設定 agent_digest.enabled。デフォルトではオフ）。組織の頻度設定（agent_digest.cadence。デフォルトは daily、または weekly、both）に従います。デフォルト設定の組織には週次ダイジェストは送信されません。core-operations の agent-digest／agent-digest-weekly の cron ティックで実行され、core-api のレポートエンドポイント（GET /api/v1/reports、GET /api/v1/reports/agent-activity）から取得できます。オプトインしていないテナントにはコストは一切かかりません

メモリパイプライン

• LLM による単一パスの拡充 — 1 つの content フィールドから、書き込みのたびにメモリを 7 種類のいずれかに自動分類します（outcome、rule、insight はサーバー側で書き込みます）。タイトルと要約を生成し、重要度をスコアリングし、PII にフラグを付け、エンティティを抽出します
• ハイブリッド検索 — pgvector による意味的類似性、全文キーワードマッチング、ナレッジグラフの展開（最大 2 ホップ）を組み合わせ、類似性、重要度、新しさ、グラフブーストの複合スコアで順位付けします。結果セットに置き換えられたメモリと置き換えたメモリの両方が含まれる場合、置き換えたメモリは必ず、置き換えられたメモリのすぐ上位に順位付けされます。古い行が表示されることはありますが、それ自身の訂正より上位に表示されることはありません
• ライブナレッジグラフ — 書き込みのたびに人物、組織、場所、概念をエンティティと関係性として抽出します。エンティティ解決では、まず名前の完全一致を試し、次に大文字・小文字と空白を区別せず、先頭の the／a／an／new／old／current／existing／legacy を無視する決定論的な標準名マッチングを行います（そのため、「the new analytics service」と「analytics service」は同一のエンティティになります）。その後、意味的類似性（コサイン類似度 >0.85）を試します。修飾語を削除するのは、2 語以上が残る場合に限られるため、「new york」が「york」に統合されることはありません。確認された表記はすべて、エンティティの別名として保持されます
• 矛盾の検出 — RDF トリプルの比較と LLM による意味解析で、矛盾するメモリを検出して自動的に置き換え、矛盾の連鎖を完全に追跡します

自己改善型メモリ

• 成果に基づく学習（Karpathy Loop） — エージェントは、想起したメモリに基づいて行動した後に成功／失敗を報告します。システムは有効な情報を強化し、失敗時には予防的な rule タイプのメモリを自動生成します
• 結晶化 — LLM が重複に近いメモリを、完全な来歴情報を備えた標準的な原子的事実に統合します。8 ステータスのライフサイクル自動化によって古いデータを退役させます
• エージェントごとの検索調整 — 各エージェントはフィードバックに基づいて独自の検索プロファイル（top_k、min_similarity、graph_max_hops、ブレンドの重み）を最適化するため、やり取りを重ねるたびに検索品質が向上します

インテグレーション

• MCP サーバー — /mcp に組み込みの Model Context Protocol（Streamable HTTP）を提供します。URL と API キーだけで、Claude Desktop、Claude Code、Cursor、Windsurf、または任意の MCP クライアントを接続できます
• マルチプロバイダー LLM — テナントごとにプライマリとフォールバックのプロバイダーチェーン（OpenAI、Gemini、Anthropic、OpenRouter）を設定でき、設定不要のテナントにはプラットフォームのデフォルトを適用します
• ドキュメントストア — 正確なフィールド検索（顧客レコード、設定、タスクリスト）用に、意味的メモリと並行して構造化された JSONB コレクションを提供します

Caura の比較

精度ベンチマークでは、主要なツールは狭い範囲に集中しています（パフォーマンスを参照）。実際に各ツールの違いが表れるのは、フリート機能とガバナンスです。

機能	Caura	Mem0	Zep	Letta
複数フリートのサポート	✅	❌	❌	❌
エージェントの信頼階層とキーストーンポリシー	✅	❌	❌	❌
ベンダーをまたいだメモリ共有	✅	❌	❌	❌
矛盾の検出と置き換え	✅	❌	❌	❌
エージェントごとの検索調整	✅	❌	❌	❌
PII の検出とフラグ付け	✅	❌	✅	❌
監査証跡／来歴	✅	❌	⚠️ 一部対応	❌
ナレッジグラフ（自動抽出）	✅	⚠️	✅	❌
MCP ネイティブ	✅	✅	✅	⚠️
OSS ライセンス	Apache 2.0	Apache 2.0	Apache 2.0	Apache 2.0

Mem0、Zep、Letta は堅実なプロジェクトです。単一のエージェントであれば、どれを使っても十分に役立ちます。Caura も同様です。違いが明確になるのは、エージェントが複数になる場合です。Caura の強みは、複数のエージェント、チーム、ベンダーが、監査可能な単一のメモリ基盤を共有する エージェントフリート全体のガバナンスされたメモリ にあります。この比較は、2026 年 6 月時点で公開資料を確認した結果に基づいています。修正のご提案は issue または PR でお寄せください。

---

パフォーマンス

エージェントメモリに関する、最も頻繁に引用される公開ベンチマーク 2 件を使って評価しました。結果、方法論、再現方法の詳細は BENCHMARKS.md に、運用規模を踏まえた背景情報は docs/performance.md に掲載しています。詳細な記事はブログをご覧ください。

• LoCoMo の精度： Caura は、文書化された LoCoMo のセマンティックジャッジプロトコルに従い、検索拡張型の agentic-v1 パイプラインで 77.9%（1,199/1,540）を記録しました。
• LongMemEval の参照ジャッジ： Caura は、ベンチマークの GPT-4o 参照ジャッジのもと、LongMemEval_S の質問 500 件中 461 件に正しく回答しました（92.2%）。
• LongMemEval のセカンダリジャッジ： 同じ LongMemEval_S の固定済み回答 500 件は、セカンダリの Gemini 3.5 Flash-Lite ジャッジのもとで 90.2%（451/500）を記録しました。
• LongMemEval のトークン効率： LongMemEval_S では、検索されたコンパクトなコンテキストの中央値は 22,410 トークンで、haystack 全体の 107,706 トークンと比べて、コンテキストのみで 79.2% 削減されました。すべてのリーダー呼び出しを含めると、削減率は 75.4% です。

ここに記載しているのは、有効かつ承認済みの主張のみです。管理対象、撤回済み、保留中の記録はエビデンスレジストリに残されており、宣伝文句からは除外されています。evidence/claims.json と EVIDENCE.md を参照してください。このブロックを手作業で編集しないでください。

---

MCP（Model Context Protocol）

1 つの設定ブロックで、任意の MCP クライアントに Caura を追加できます。

セルフホスト（localhost）：

{
  "mcpServers": {
    "caura": {
      "url": "http://localhost:8000/mcp",
      "headers": { "X-API-Key": "standalone" }
    }
  }
}

マネージドプラットフォーム（caura.ai）：

{
  "mcpServers": {
    "caura": {
      "url": "https://caura.ai/mcp",
      "headers": { "X-API-Key": "mc_your_api_key_here" }
    }
  }
}

チームまたは本番環境で使用する場合は、テナントスコープのキーをエージェントスコープの認証情報に切り替えてください。マネージドプラットフォーム（caura.ai）では、POST /api/v1/admin/agent-keys/provision によるアトミックなプロビジョニング（または Caura アプリの Connect › Keys にある Create agent key）により、認証情報、Agent 行、初期信頼度、フリートへの所属が 1 回のリクエストで作成されます。どちらの種類も mc_ プレフィックスを使用します。スコープは認証情報の作成時に設定されます。docs/integration-without-plugin.md を参照してください。テナントスコープの認証情報を使用していますか？すべての MCP ツール呼び出しで明示的に agent_id を渡してください。ゲートウェイは、テナントスコープの経路で予約済みのデフォルト値（mcp-agent）を拒否します。

この設定を追加する場所：

• Claude Code — Claude Code は MCP サーバーを settings.json から読み込みません。代わりに claude mcp add でサーバーを登録してください。すべての作業ディレクトリで利用できるように、-s user を使用してください。デフォルトのスコープ（local）では現在のディレクトリにのみ登録されるため、複数のフォルダーからエージェントを実行する場合に問題になります：

  claude mcp add --transport http -s user caura http://localhost:8000/mcp --header "X-API-Key: standalone"
  

  （または、上記の JSON ブロックをプロジェクトルートの .mcp.json にコミットして、プロジェクトスコープのサーバーとして設定できます。）
• Claude Desktop — ~/Library/Application Support/Claude/claude_desktop_config.json（macOS）または %APPDATA%\Claude\claude_desktop_config.json（Windows）
• Cursor — Settings > MCP Servers > Add Server

クライアントは 12 個のツールを自動的に検出します：

ツール	用途
caura_write	単一または一括で書き込み（最大 100 件）。LLM が種類、タイトル、要約、タグ、埋め込みを推定
caura_recall	グラフで強化された検索による、セマンティック検索とキーワード検索を組み合わせた想起。LLM による概要は任意
caura_manage	メモリごとのライフサイクル操作：read、update、transition、delete、bulk_delete、lineage
caura_list	種類／ステータス／エージェント／重み／日付でフィルターし、並べ替えやカーソルページネーションが可能
caura_doc	名前付き JSON コレクションでのドキュメント CRUD：write、read、query、delete、list_collections、search（セマンティック）
caura_entity_get	関連するメモリと関係性を含むエンティティを検索
caura_tune	エージェントごとの検索パラメーター（top_k、min_similarity、graph_max_hops など）を調整
caura_insights	6 種類のフォーカスモードでメモリストアを分析。分析結果は insight メモリとして保存
caura_evolve	想起されたメモリに対する結果を報告し、重みを調整してルールを生成（Karpathy Loop）
caura_stats	合計数と、種類、エージェント、ステータス別の内訳を集計。読み取り専用
caura_keystones	現在のスコープに適用される必須のガバナンスルールを読み込みます。セッションごとに 1 回呼び出してください。結果は、競合するユーザー指示より優先されます
caura_keystones_set	基幹ルールを作成または削除します（op=set|delete）。weight は low／med／high として設定され、整数の区分値 25／50／100 として保存・返却されます。自分のルールには信頼度 ≥ 1 が必要です。これは scope=agent かつ、明示的に指定した agent_id が呼び出し元と一致する場合です。scope=fleet／scope=tenant、別のエージェント、または agent_id を省略した scope=agent には、信頼度 ≥ 2 が必要です

スキルの共有は現在 caura_doc で行います。エージェントは skills コレクションにドキュメントをアップサートして SKILL.md を共有できます（caura_doc op=write collection=skills doc_id=<slug> data={"summary": "<one-liner>", ...}）。サーバーはセマンティック検索用に data["summary"]（意図を重視した 1～3 文）を埋め込みます。collection="skills" の場合、summary が指定されていなければ data["description"] にフォールバックします。専用の memclaw_share_skill／memclaw_unshare_skill ツールは廃止され、単一の caura_doc インターフェースに統合されました。

Skill Factory

手動でスキルを共有する方法（前述）は最低限の機能です。Skill Factory は skills コレクションの上に構築されたガバナンスシステムです。エージェント群の動作からスキルを自動生成し、公開できる内容を審査し、有効なスキルをエージェントに届けます。テナントごとのオプトイン方式で、デフォルトでは無効です。テナントの設定で skills_factory.enabled = true を設定するまで（{"skills_factory": {"enabled": true}} を指定して PUT /api/v1/settings を実行するか、caura.ai の Caura アプリで「設定 › テナント設定」を選択）、skills コレクションは前述の説明どおりに動作します（ライフサイクルはなく、保存されたすべてのスキルが表示されます）。柱となる機能は3つです。

• 作成 — エージェントと Forge。 エージェントは caura_doc op=write collection=skills を使ってスキルを直接作成します。サーバー側で常駐する Forge も、メモリと成果のシグナルを分析し、繰り返し成功した手順をクラスタリングして、スキルの候補にまとめます。エージェントがスキルの作成を忘れていても問題ありません。
• ガバナンス — ライフサイクル。 すべてのスキルにはステータスが付与されます。 candidate → staged → active（終了時のステータスは rejected ／ quarantined ／ stale ／ deprecated）です。6つの自動ゲートと Sentinel によるコンテンツスキャンで昇格可能なスキルを判定します。また、オペレーターは REST インターフェースを通じて Skills Inbox でステージング済みのスキルを承認、編集、保留、却下、隔離できます。GET /api/v1/skills-inbox はステージング済みのカードを一覧表示し、POST /api/v1/skills-inbox/{slug}/approve|edit|defer|quarantine|reject で操作します（caura.ai の Caura アプリでは、組織管理者向けに同じキューが「レビュー › 承認するスキル」に表示されます）。エージェントが書き込んだスキルは staged として登録され、すぐに active になることはありません。
• 配信 — プルとプッシュ。 エージェントは MCP 経由で有効なスキルをプルできます（caura_doc op=search／op=read）。または、OpenClaw プラグインがスキルをプッシュします。プラグインのリコンサイラーは POST /api/v1/skills/installable から有効なスキルをすべて取得し、各スキルをノードのスキルディレクトリに書き込みます。必要に応じて、そのディレクトリを OpenClaw のロードパスに登録することもできます。機能を有効にすると、どちらの方式でも active のスキルのみが提供されます。

詳しくは、docs/mcp-skill-delivery.md（active のみを配信する仕様とプラグインのリコンサイル対象）、 docs/operator-forge-cron.md（Forge のスケジュール設定）、および docs/skills-inbox-api.md（Skills Inbox のオペレーター向け REST API）をご覧ください。 オペレーター／開発者向けの完全ガイドは、Caura のドキュメント → Skill Factory にあります。

Interviewer

caura_write はエージェントが記録することを選んだ内容を取得します。Interviewer はエージェントが実際に行ったことを取得します。スケジュールに従って、エージェント自身の永続的な作業履歴（ハーネスがすでに保持しているトランスクリプトやイベントログ）を読み取り、LLM にアクティビティを型付きメモリにまとめさせます。これにより、エージェントが記録する時間を取らなかった判断、障害、好みも保存されます。エージェントを再実行することはなく、実際の履歴のみを基にするため、実際のアクティビティに根差しています。（LLM による統合でも誤読や誇張が起こる可能性があるため、Interviewer のメモリは逐語的な記録ではなく、有用な近似として扱ってください。）

これは、リアルタイム書き込みと取り込みに並ぶ、メモリが Caura に取り込まれる3つ目の方法です。Skill Factory と同様、テナントごとにオプトインが必要で、デフォルトではオフです。テナントの設定で interviewer.enabled = true にするまで動作しません（PUT /api/v1/settings、または caura.ai の Caura アプリで［Settings］›［Tenant settings］）。

• 書き込まれる内容。 6つのレポートセクションがメモリタイプの列挙型に対応しています。 worked_on → episode、decisions → decision、outcomes → outcome、 blockers → task、open_questions → fact、preferences_learned → preference。履歴に記録された実際のイベント時刻を保持した、通常の拡充・埋め込み済み・ガバナンス適用済みメモリとして保存されます。
• アクティビティの取得方法。 2つの方式で、送信プロトコルは共通です。
  • Plugin-buffer — OpenClaw プラグインがノードローカルの永続バッファを保持し、ウィンドウを送信します（プラグインの環境変数に CAURA_INTERVIEWER=true を追加します）。
  • Disk-parser — caura-client パッケージに含まれる caura-interviewer CLI が、ハーネスのディスク上のトランスクリプトを読み取り専用で読み込み、ウィンドウを送信します。現在はClaude Code（~/.claude/projects）とCursor（~/.cursor/…/agent-transcripts）に対応しており、Hermesなどは今後対応予定です。
• 設計上、クラッシュに安全です。 各ウィンドウは決定的な試行 ID（sha1(node_id:cursor_from:cursor_to)）で書き込まれ、その後にノードごとのウォーターマークが進みます。処理の途中でクラッシュしても再送時に重複排除されるため、欠落も重複も発生しません。ローカルのカーソル状態はなく、サーバーのウォーターマークが正となります。
• プライバシー。 Disk-parser はデフォルトで拒否され、プロジェクトを許可リストに登録するまで何も収集しません。また、認証情報に見える文字列は送信前にローカルでスクラブされ、サーバー側でも再度マスクされます。

トリガーには定期的な run（cron）とセッション終了時の hook があり、両方を組み合わせても重複送信は重複排除されるため安全です。詳細なセットアップ、ハーネスごとの設定、プロトコルについてはCaura のドキュメント → Interviewerをご覧ください。

Caura Broker

Caura Broker は、開発者のマシン上で動作し、コーディングエージェント（Claude Code、Codex、Cursor、Gemini）を Caura に接続するローカルデーモンです（caura-daemon。以前は memclawd。caura CLI で操作します）。その役割は、開発者側の信頼境界として、マシンの外に何かが送信される前にポリシーを適用し、秘匿化を行い、改ざんを検知できる監査ログを維持することです。Broker は標準でパーソナルモードで動作します。Broker Fleet（fleet_id というメモリスコープとは異なる、マシンのフリート）に参加したインストールは、ハートビート、ポリシーストリーム、共有ダッシュボードによって一元管理されます。

Broker 自体は別途配布されますが、サーバー側の ID 関連処理はこのリポジトリにあります。Broker の呼び出しは X-Caura-Credential-Kind: install_credential と X-Install-UUID で認証され、その書き込みは broker:<install> の所有権名前空間に帰属します。詳しくは core-api/src/core_api/mcp_server.py と core-api/src/core_api/auth.py を参照してください。broker とクラウド間の通信契約は v1 に固定されています。両方のリポジトリで CI に oasdiff による破壊的変更のチェックゲートを設けています（このリポジトリでは core-api/scripts/gen_broker_openapi.py がベースラインを生成し、#620 でゲートを追加しました）。そのため、契約を破る変更はインストール済みの Broker に影響するのではなく、ビルドを失敗させます。インストール、フリートへの参加、ポリシーなどの操作については、Caura ドキュメント → Broker Fleet を参照してください。

スキルをインストールする（Claude Code と Codex）

Caura の使用ガイドをスキルとしてインストールすると、エージェントが 12 個のツールをいつ、どのように使うかを把握できます。内容は、メモリとドキュメントの考え方、3 つのルール（想起、書き込み、置き換え）、信頼レベル、一般的なパターン、アンチパターンです。このスキルは必要なときに読み込まれ（ターンごとではありません）、エージェントが Caura を使うまではコストがかかりません。

前提条件： MCP サーバーがすでに登録されていること（Claude Code の場合は claude mcp add -s user、Codex の場合は同等の方法を使用してください。上記の設定ブロックを参照）。claude mcp list で確認してください。caura: ... ✓ Connected と表示されるはずです。

オプション A — ワンライナー（最速）

セルフホスト（localhost）：

curl -s "http://localhost:8000/api/v1/install-skill" | bash

マネージドプラットフォーム：

curl -s "https://caura.ai/api/v1/install-skill" | bash

オプション B — ダウンロード、内容確認、実行（エージェント向けの推奨方法）

安全上の理由から、自動エージェント（Claude Code、Codex）が curl | bash を拒否する場合があります。2 ステップでインストールすれば、先にスクリプトを確認できます。

curl -s "http://localhost:8000/api/v1/install-skill" > /tmp/install-caura-skill.sh
less /tmp/install-caura-skill.sh      # review — it only does mkdir + curl + write
bash /tmp/install-caura-skill.sh

オプション

クエリパラメーター	効果
（なし）	Claude Code と Codex の両方に、Caura のデフォルトのツールリファレンススキルをインストールします
?agent=claude-code	Claude Code のみ → ~/.claude/skills/<skill>/SKILL.md
?agent=codex	Codex のみ → ~/.agents/skills/<skill>/SKILL.md
?skill=company-brain	デフォルトのスキルの代わりに、オプションのCompany Brain姿勢スキルをインストールします（下記参照。?agent= と組み合わせて使用できます）

確認

ls -la ~/.claude/skills/memclaw/SKILL.md       # Claude Code; legacy-name-floor: installed default-skill path
ls -la ~/.agents/skills/memclaw/SKILL.md       # Codex; legacy-name-floor: installed default-skill path

インストール後にエージェントを再起動してください。スキルは起動時に読み込まれます。 最新バージョンを取得するには、いつでもインストーラーを再実行してください。

OpenClaw プラグインのユーザーは、プラグインのインストール時にスキルが自動的に追加されるため、この手順を省略できます。

オプション：Company Brain スキル

デフォルトのスキルはエージェントにツールの使い方を教えます。company-brain は、概念を重視した薄い姿勢スキルで、その上に重ねて使用します。エージェントを共有のCompany Brainを構成する一つの知性として捉え、ツールの仕組みについてはすべてツールリファレンススキルに委ねます。この考え方を取り入れたい場合は、2 つを一緒にインストールしてください。

curl -s "https://caura.ai/api/v1/install-skill?skill=company-brain" | bash

このスキルは ~/.claude/skills/company-brain/SKILL.md（Claude Code）および／または ~/.agents/skills/company-brain/SKILL.md（Codex）にインストールされ、同じ ?agent= フィルターに従います。デフォルトのインストール（?skill= なし）に変更はなく、デフォルトのツールリファレンススキルのみをインストールします。

---

デプロイ

Caura の実行には Docker Compose の使用を推奨します（クイックスタートを参照）。これにより、PostgreSQL + pgvector + Redis + API の本番環境対応スタックを、1 つのコマンドで起動できます。

公開済みコンテナイメージ

各リリースでは、マルチアーキテクチャ（linux/amd64、linux/arm64）対応イメージをGitHub Container Registryに公開します。

ghcr.io/caura-ai/caura-memclaw-core-api:v2.5.0 # legacy-name-floor: published GHCR repository name
ghcr.io/caura-ai/caura-memclaw-core-storage-api:v2.5.0 # legacy-name-floor: published GHCR repository name
ghcr.io/caura-ai/caura-core-operations:v2.5.0

ライフサイクルスケジューラーのcaura-core-operationsは、ほかの2つより新しいサービスで、新しい名前で公開されています。そのため、スタックに加わる前のリリースには、このサービスのイメージがありません。

タグは、可変エイリアス（:v1、:v1.0、:v1.0.0）と、最新の安定版リリースを示す:latestを含むSemVerに従います。ソースからビルドする代わりに、独自のcomposeファイルまたはKubernetesマニフェストでこれらを取得してください。

手動でのデプロイ（Docker を使わない場合）

Cauraは2つのFastAPIサービスで構成されており、どちらも任意のASGIサーバー（uvicorn、hypercorn）で実行できます。core-storage-apiはデータベースを管理し、起動時にマイグレーションを適用します。core-apiはREST APIとMCP APIを提供し、データベースにはcore-storage-api経由でのみアクセスします。必要なものは次のとおりです。

• Python 3.12+
• core-storage-api用の、pgvector拡張機能を備えたPostgreSQL 16+
• Redis（任意。利用できない場合はインメモリーキャッシュにフォールバックします）

両方のサービスに、同じ空ではないCORE_STORAGE_SHARED_SECRETが必要です。これがない場合、core-apiは起動しません。CORE_STORAGE_API_URL（デフォルトはhttp://localhost:8002）を使って、core-apiの接続先となるストレージサービスを指定します。AGENT-INSTALL.mdのオプションBでは、pip install -r requirements.txtを含むインストール全体の手順を説明しています。

各サービスを起動する前に、.envをプロセス環境にエクスポートしてください。各サービスは.envから独自の設定を読み込みますが、一部の設定値は環境変数からのみ読み込まれます。対象は、埋め込みモデル（OPENAI_EMBEDDING_*、EMBEDDING_QUERY_INSTRUCTION）、リランカー（RANK_*）、プロバイダーモデルの上書き設定（*_DEFAULT_MODEL）です。.env.exampleでは、これらのブロックに「env-only」と記載しています。Composeのenv_file:はこれらを環境変数として設定しますが、uvicornを直接実行した場合は設定されません。エクスポートした値は.envの値より優先されるため、ファイルを編集した後は再度エクスポートしてください。環境変数の読み込み時には、すべての行がシェルに渡されます。そのため、スペース、引用符、$、&、;、バッククォートなどのシェル文字を含む値（パスワードなど）は、シングルクォートで囲んでください。そうしないとシェルによって値が変わり、変換された値が.envの設定より優先されます。

set -a; . ./.env; set +a
PYTHONPATH=.:core-storage-api/src uvicorn core_storage_api.app:app --host 127.0.0.1 --port 8002
# Then, in a second shell with the same .env exported:
WEB_CONCURRENCY=2 PYTHONPATH=.:core-api/src uvicorn core_api.app:app --host 0.0.0.0 --port 8000

--workersを指定しない場合、uvicornはWEB_CONCURRENCYからワーカー数を取得します。core-apiも同じ変数を読み込みます。USE_STM=trueかつSTM_BACKEND=memoryの場合、各ワーカーがそれぞれ独自のSTMを保持するため、ワーカー数が複数だと起動しません。その場合はSTM_BACKEND=redisを使用してください。

デプロイのトポロジ

Caura には、ストレージ層の運用モードが 2 つあります。**シングルノード（デフォルト）**は、Docker Compose、pip install、または新規デプロイで使用されるモードです。1 つの core-storage-api インスタンスが、読み取りと書き込みの両方を処理します。継続的に毎秒 100 件を超える書き込みが発生していないデプロイには、この構成が適しています。

リーダー／ライター分離は、書き込み頻度の高いデプロイで、書き込みとは独立して読み取りをスケールさせたい場合に選択できるトポロジです。たとえば、読み取りトラフィックを Postgres のストリーミングレプリカに向ける場合です。この構成を有効にするには、役割の異なる core-storage-api サービスを 2 つ実行し、core-api から両方を指定します。

• 書き込みを処理するインスタンスでは CORE_STORAGE_ROLE=writer、読み取りを処理するインスタンスでは =reader を設定します。
• core-api の CORE_STORAGE_READ_URL にリーダーサービスの URL を設定します。CORE_STORAGE_API_URL はライターを指すように設定したままにします。
• 各 core-storage-api の READ_DATABASE_URL は、使用可能な読み取りレプリカがある場合、それを指定できます。ライターでは、レプリカラグを許容できる読み取りに使用されます。リーダーでは、すべてのクエリに使用され、DATABASE_URL には接続しません。
• core-api、すべての core-storage-api のライター／リーダー、およびその他の内部ストレージ呼び出し元に、同じ空でない CORE_STORAGE_SHARED_SECRET を設定します。すべてのストレージリクエストには X-Storage-Secret を含める必要があります。認証情報がない場合や正しくない場合は、ルーティング前に拒否されます。

トポロジのデフォルト： CORE_STORAGE_ROLE=hybrid および CORE_STORAGE_READ_URL="" のため、単一のストレージインスタンスで読み取りと書き込みの両方を処理できます。Docker Compose ではストレージ認証が自動的に設定されます。手動でデプロイする場合は、ストレージサービスとすべての呼び出し元で CORE_STORAGE_SHARED_SECRET（または CORE_STORAGE_SHARED_SECRET_FILE）を設定する必要があります。

---

v1.x からのアップグレード

バージョン 2.0 では、埋め込みの次元数が 768 から 1024 に拡張されました。既存のインストール環境では、破壊的なマイグレーションを明示的に有効にし、データベースのスナップショットを取得して、保存済みデータを再度埋め込みに変換する必要があります。

v2 イメージを取得する前に、完全版の v1.x → v2.x アップグレードガイドに従ってください。

---

API リファレンス

バージョン管理された REST ルートは /api/v1/ の下にあり、MCP は別途 /mcp にマウントされます。稼働中のデプロイでは、正式な OpenAPI スキーマが /api/openapi.json で提供され、インタラクティブな Swagger ドキュメントが /api/docs で提供されます。

エンドポイントのグループ、認証、設定、リポジトリ構成については、厳選された API リファレンスを参照してください。API サーフェスの責任範囲に関する憲章では、どの操作を REST、MCP、または OpenClaw プラグインに割り当てるかを説明しています。

---

パブリック API と安定性

Caura は SemVer に準拠しています。安定版の MCP ツール、REST エンドポイント、プラグイン変数、認証モード、およびコントリビューター向けの要件については、パブリック API の安定性に関する契約を参照してください。

---

テレメトリー

更新日：2026-09-19。 セルフホストのサーバーは、ワーカー数にかかわらず、コンテナごとに1日1回、匿名のハートビートを telemetry.caura.ai に送信します。送信されるのは、バージョン、Python／OS／アーキテクチャ、デプロイ種別（docker または source）、稼働時間の区分、プロバイダーの種類（モデル名やキーは送信されません）、Redis と Sentry が設定されているかどうか（値は送信されません）、メモリ、エージェント、テナント、および最近確認されたプラグインノードの件数区分と、呼び出し元の SDK ファミリーの件数区分です。数値はすべて区分（0、1、2-5、6-20、...）で送信されます。ID はランダムな UUID で、独自のデータベースに保存されます。ホスト名、IP アドレス、名前、コンテンツ、設定値に関する情報は一切送信されません。正確なペイロード、その JSON スキーマ、データ保持ポリシー、および変更履歴については、docs/telemetry.md をご覧ください。

インストールごとに永続的に無効化できる方法は、次のとおりです。

• core-api の環境変数（.env、または docker-compose.yml の core-api の下にあるコメントアウトされた行）に CAURA_TELEMETRY=off を設定します。
• DO_NOT_TRACK=1 を設定します（Console Do Not Track の慣例）。
• CI に空でない値を設定します。パイプラインはカウントされません。
• ファイアウォールで telemetry.caura.ai:443 をブロックします。1日1回試行し、タイムアウトは5秒で、再試行はしません。
• エンタープライズゲートウェイ経由で実行するか、プラットフォームプロバイダーを使用すると、自動的に無効になります。

サーバーが送信する内容、最後に試行した時刻、および成功したかどうかは、GET /api/v1/telemetry で確認できます。POST /api/v1/telemetry/rotate を使うと、新しい ID で最初からやり直せます。起動ログには、毎回、ON／OFF の判断、理由、および無効化のヒントが出力されます。入力ミスのある CAURA_TELEMETRY_URL（localhost 以外への平文の http://）が設定されている場合、ハートビートは平文で送信されず、警告とともに無効になります。

エラー追跡は引き続きオプトインです。エラー追跡とパフォーマンス監視のために、オプションの Sentry 連携を有効にするには、SENTRY_DSN を設定してください。DSN を明示的に設定しない限り、エラーは報告されません。

ハートビートを除き、Sentry DSN または LLM／埋め込みプロバイダーを設定しない限り、セルフホストのデプロイから外部への呼び出しはありません。マネージドプラットフォームの使用状況分析はホスト型サービスの機能であり、セルフホストのランタイムには含まれません。

---

レート制限

レート制限は slowapi によってプロセス内で適用されます。API キーが存在する場合はそれをキーとして使用し、そうでない場合はリモート IP アドレスをキーとして使用します。制限はグローバルではなくルートごとに適用されます。/health、/version、および /mcp はレート制限の対象外です。

ルート	デフォルト	設定
POST /memories、POST /documents、POST /ingest/commit、POST /stm/promote	10/秒	RATE_LIMIT_WRITE
POST /memories/bulk	2/秒	RATE_LIMIT_WRITE_BULK
POST /search、POST /recall	30/秒	RATE_LIMIT_SEARCH

レート制限の対象となるルートからのすべてのレスポンスには、X-RateLimit-Limit、X-RateLimit-Remaining、および X-RateLimit-Reset が含まれます。拒否されたリクエストには、Retry-After とともに HTTP 429 が返されます。REDIS_URL が設定されている場合、カウンターは Redis に保存されます。これにより、レプリカ間でも制限が適用されます。未設定の場合はプロセスメモリに保存されるため、Redis を使用しないマルチインスタンスのデプロイでは、各インスタンスに個別の制限が適用されます。Redis が停止した場合はフェイルオープンとなり、リクエストはエラーにならず、レート制限なしで処理されます。

X-RateLimit-* は1秒あたりのスロットルを示すもので、それ以外の意味はありません。使用状況メーターが組み込まれたデプロイでは、別途、期間ごとのプラン上限が POST /memories、POST /memories/bulk、および POST /search の X-Usage-Limit／X-Usage-Remaining として報告されます。OSS のスタンドアロン版には使用上限がないため、これらのヘッダーは含まれません。

アプリケーション層では把握できない IP ごとの DDoS 対策や制限が必要な場合は、リバースプロキシ（nginx、Caddy、Cloudflare）にも制限を追加してください。

コントリビューション

コントリビューションを歓迎します！ガイドライン、開発環境のセットアップ、および PR の提出方法については、CONTRIBUTING.md をご覧ください。

---

FAQ

Cauraとは何ですか？ Cauraは、AIエージェント群のための、オープンソースでガバナンス機能を備えた共有メモリです。 可視性スコープ、信頼レベル、キーストーンポリシー、監査証跡、すべての操作で適用されるテナント分離により、エージェント間・エージェント群間で情報を再取得できます。さらに、成果に基づく学習を通じて検索機能が継続的に改善されます。

Cauraはベクトルデータベースとどう違いますか？ Cauraは内部でpgvectorを使用していますが、単なるベクトルデータベースのラッパーではありません。ハイブリッド検索に加え、エージェント群のオーケストレーション、エージェントごとの検索調整、矛盾の検出、8段階のステータスを持つライフサイクル、自動抽出されるナレッジグラフ、すべての書き込みに対するLLMによる拡充、行レベルのテナント分離、すべての操作の監査証跡を備えています。

CauraはMem0やZepとどう違いますか？ Mem0とZepは個々のエージェント向けのメモリに重点を置いており、精度ベンチマークでは3つのツールはいずれも狭い範囲に集まっています。Cauraはエージェント群向けに構築されています。複数のチームやベンダーにまたがるエージェントが、信頼レベル、キーストーンポリシー、これらのツールでは対応していないエージェント群間の権限を備えた、ガバナンス対象の共有メモリ基盤を利用できます。Cauraの比較をご覧ください。

CauraはClaude Desktop、Claude Code、Cursor、Windsurfで動作しますか？ はい。CauraはMCPネイティブです。URLとAPIキーを含むJSON設定を任意のMCPクライアントに貼り付けると、すぐに12個のツールが表示されます。

異なるベンダーのエージェント同士でメモリを共有できますか？ はい。それがCauraの目的です。Anthropicのエージェントは、同じガバナンスルールのもとでOpenAIのエージェントが書き込んだ内容を再取得できます。エージェント群の境界を越えて共有される情報は、信頼レベルと可視性スコープによって決まります。

Cauraは本当に無料ですか？ ストレージ、12個のMCPツール、プラグイン、監査証跡を含むエンジン全体はApache 2.0で提供されています。永久に自分で運用できます。caura.aiのマネージドプラットフォームでは、インフラを運用したくないチーム向けに、ホスティング、スケーリング、エンタープライズガバナンスを追加で提供しています。

本番環境でCauraを利用しているのは誰ですか？ eToro（NASDAQ: ETOR）は、AIエージェント業務向けのガバナンス対象の共有メモリレイヤーとしてCauraを利用しています。 事例紹介 →

---

ライセンス

CauraはApache License, Version 2.0に基づいてライセンスされています。

著作権およびサードパーティの帰属表示については、NOTICEをご覧ください。

商標

「Caura」はCauraの商標です。Apache License 2.0はソースコードの使用を許可しますが、派生作品が推奨されている、または提携していると示唆するような形で、これらの名称、ロゴ、ブランドを使用することは許可していません。法的条件の全文については、Apache License 2.0 §6をご覧ください。