Kumbuka

ステータス：プレベータ。 kumbuka は現在、活発に開発されています。アーキテクチャとデータモデルは確定しており、プライベートメモリの保証は設計上の必須条件です。ただし、まだ十分な堅牢性を備えた正式リリース製品ではありません。未完成な部分や、互換性を損なう変更が発生する可能性があります。

kumbuka はスワヒリ語で、命令形の 「覚えておいて！」 を意味します。このプロジェクトのサイトは kumbuka.ai です。

---

問題：記録のない成果

AI アシスタントはセッション間で状態を保持せず、作業の結果は残しても、その記録が残ることはほとんどありません。AI アシスタントを使うチームは、二重の代償を払います。

まず、コンテキスト税を払います。同じルールを新しいセッションのたびに説明し直す必要があるからです。「システム・オブ・レコードには Postgres を使う」、「金額は整数の最小通貨単位で表し、浮動小数点数は使わない」 といった、作業の指針となるはずの決定事項、規約、制約が、人々の頭の中や、あちこちに散らばったチャット履歴の中にあるためです。

そして、作業そのものの経緯も失われます。アシスタントやエージェントが何かを実行したあとでは、誰が依頼し、どのルールに基づき、何が返され、誰が承認したのかという、後になって重要になる問いに答えるのが困難です。セッションの記録はセッションが終われば途切れ、完成したファイルを見ても、どの依頼から生まれたのかはわかりません。

kumbuka とは

kumbuka は、チームが合意したこと、委託して受け取った作業、その後に予定していることを、それぞれ個別にアドレス指定できるオブジェクトとして保持するサービス群です。アシスタントは Model Context Protocol（MCP） を通じてこれらを読み取り、チームが内容を管理します。

サービス	保持するもの
Memory	チームが合意したルールを管理します。意思決定、慣例、制約、定義、未解決の質問、ステータスを型付けし、範囲を定めて、作業の開始時にアシスタントが読み取ります。
Dispatch	委託され、返却される作業を管理します。一方がタスクを提示し、もう一方が引き受けて回答します。また、その回答を承認することも独立した行為です。委託内容は送信時点で固定されるため、後から誰が何を依頼し、誰が回答し、何が承認されたかを確認できます。
Worklist	実行する作業とその順序を一覧で管理します。アイテムは作成、特性の付与、計画、担当者の割り当て、作業、終了の各段階を経て、そのライフサイクル全体を通じて編集できます。
Documents	現時点で有効な内容を記したドキュメントを管理します。kumbuka-documents はまだ一般公開されていません。

各サービスはそれぞれ 独立した製品 として構築され、独自のリポジトリで公開されています。すべてのサービスに完全な REST インターフェースがあります。Dispatch と Worklist にはそれぞれ独自の MCP エンドポイントもあります。Memory には独自の MCP アダプターがなく、アシスタントはプラットフォームの MCP エントリーポイントを通じてアクセスします（アーキテクチャを参照）。

kumbuka は意図的に、ドキュメントストアでも RAG インデックスでもなく、人々の行動を監視することもありません。保持するのは、誰かが書き留め、チームが内容に責任を持つ 厳選された コンテンツです。各自のドキュメントやソースのコピーを保持するのではなく、それらはそれぞれのシステムに残ります。

プライベートメモリの保証

メンバーのプライベートメモリは、そのメンバーだけのものです。 アクセスできるのは本人に限られ、本人が認証した MCP セッションを通じてのみ利用できます。管理者も、コンソール画面も、チーム向け API も、これを読み取ることはできません。

これは機能フラグではなく、製品の基盤です。データアクセス層で適用されます。特権を持つ（管理者／コンソールの）コードパスには、プライベートな行を返す経路がありません。切り替え可能な設定トグルによって適用されているわけではありません。メンバーを無効にするとアカウントは停止されますが、プライベートメモリには手を加えず、引き続きそのメンバーだけのものとして保持します。

構造上どのように適用されているかについては、セキュリティとプライバシーのガイドを参照してください。

テナントの分離

各サービスは、PostgreSQL 内に独自のスキーマとデータベースロールを持ちます。テナントは、テナント軸における 行レベルセキュリティ によって分離されます。ポリシーはフェイルクローズ方式であるため、テナントに紐付けられていないリクエストでは、すべての行が見えるのではなく、行が一切見えません。サービスのランタイムロールは何も所有せず、マイグレーションで列挙された権限だけを持つため、ポリシーを無効にすることはできません。

すべてのサービスで使える単一のサインイン

サインインは、アイデンティティプロバイダーの前段にある OAuth 2.1 認可サーバー、cimd-proxy を通じて行われます。外部向けには Client ID Metadata Documents を使用します。MCP クライアントは、自ら管理する URL によって自身を識別するため、クライアントに必要なのはエンドポイント URL だけです。クライアント ID もクライアントシークレットも、コピーして配布する必要はありません。内部では Keycloak にサインインを連携し、Keycloak がトークンを発行します。

外部から見ると、プラットフォームは 単一のオーディエンスを持つ単一のリソース です。サインインするとトークンが 1 つ発行され、そのトークンはエントリーポイントの背後にあるすべてのサービスで有効です。各サービスは変更されていないトークンをそれぞれ独自に検証し、前段のサービスが検証済みであることに依存しません。

アシスタントを接続する

kumbuka は、AI クライアントからカスタム MCP コネクターとして利用します。claude.ai では、設定 → コネクターから追加し、OAuth フローで一度サインインすると、アシスタントがユーザーに代わってサービスのツールを呼び出せるようになります。これには、ユーザー専用のプライベートなメモリスコープも含まれます。

プラットフォームのエントリーポイントを通じて、ツールは <service>_<verb> という名前で呼び出します。たとえば、memory_query、dispatch_claim、worklist_create などです。そのため、1 つのコネクターで各サービスのツールを利用できます。

アーキテクチャ

この図は、現在稼働しているホスト型デプロイを示しています。Caddy はエッジであり、トークンの検証は行いません。cimd-proxy は認可サーバーで、その背後には ID プロバイダーの Keycloak があります。platform はエントリーポイントです。アドレスに指定されたサービスを読み取り、そのサービスを所有するサービスへ REST 経由で呼び出しを転送するルーターであり、スコープ、チーム、設定を管理するコアも備えています。Memory、Dispatch、Worklist はそれぞれ独自にトークンを検証し、1 つの PostgreSQL インスタンス内に独自のスキーマを保持します。ops console は運用担当者専用のインターフェースで、IP 許可リストに登録されたアドレスからのみアクセスできます。

flowchart TD
    C["AI assistant or agent<br/>(any MCP client)"]
    O["Operator browser"]

    E["Caddy edge<br/>(validates no token)"]

    X["cimd-proxy<br/>OAuth 2.1 authorization server<br/>(Client ID Metadata Documents)"]
    K["Keycloak<br/>(identity provider, issues the token)"]

    R["platform<br/>router + management core"]

    subgraph services["Domain services (each validates the token itself)"]
      M["Memory"]
      D["Dispatch"]
      W["Worklist"]
    end

    OC["ops console<br/>(operator, IP allow-list)"]
    P[("PostgreSQL<br/>one schema and one role per service")]

    C -- "1 · sign-in" --> E
    E -- "auth host" --> X
    X -- "federates sign-in" --> K
    C -- "2 · MCP or REST + bearer token" --> E
    E -- "/mcp, /api" --> R
    R -- "REST, token forwarded unchanged" --> M
    R -- "REST, token forwarded unchanged" --> D
    R -- "REST, token forwarded unchanged" --> W

    O --> E
    E -- "ops host" --> OC

    R --> P
    M --> P
    D --> P
    W --> P
    K --> P
    OC --> P

ルーターと統合インターフェースは、エンタープライズ版にのみ存在します。コミュニティ版のインストールにはルーターがなく、各サービスに直接アクセスします。

クイックスタート

現時点ではサービスのセルフホスト用パッケージはありません。この README では、あるかのようには説明しません。各サービスのリポジトリには、サービスのビルド方法、テストスイート全体の実行方法、ご自身のデータベースと ID プロバイダーに合わせた設定方法が記載されています。テストスイートには Docker が必要です。Testcontainers を通じて、それぞれが独自の PostgreSQL を起動し、Dispatch と Worklist では独自の Keycloak も起動します。

• kumbuka-memory — 設定とビルド
• kumbuka-dispatch — 設定、ビルド、テスト
• kumbuka-worklist — 設定、ビルド、テスト
• cimd-proxy — 認可サーバーのクイックスタートと設定

kumbuka-server の Docker Compose スタックは、PostgreSQL、Keycloak、Caddy とともに管理コアを起動します。メモリエンジンはこのリポジトリから分離されたため、このスタックだけではメモリサービスを提供しなくなりました。

リポジトリ一覧

リポジトリ	内容
kumbuka	このリポジトリです。プロジェクトの入り口と公開ドキュメントを提供します。
kumbuka-memory	メモリサービスです。厳選されたエントリー、そのスコープ設定と作成者情報、およびエントリー間の型付きリレーションを扱います。AGPL-3.0。
kumbuka-dispatch	dispatch サービスです。依頼された作業とその回答を、永続的でアドレス指定可能なオブジェクトとして扱います。AGPL-3.0。
kumbuka-worklist	worklist サービスです。スコープが取り組む内容を、プロセスに沿って進めるアイテムとして扱います。AGPL-3.0。
kumbuka-documents	documents サービスです。一般公開はまだされていません。
cimd-proxy	OAuth 2.1 認可サーバーです。外部には Client ID Metadata Documents を提供し、内部では Keycloak などの既存の OIDC プロバイダーとフェデレーションします。Apache-2.0。
kumbuka-server	管理コアです。スコープ、チーム、設定、テナントディレクトリを管理します。AGPL-3.0。
kumbuka-console	Next.js 管理コンソールです。AGPL-3.0。

ルーターとエンタープライズモジュールは、非公開リポジトリにあります。

ドキュメント

ドキュメントサイトは docs.kumbuka.ai （英語とドイツ語）にあります。一部には、以前のメモリ専用スタックの説明が残っています。存在するサービスについて、サイトとこの README の記述が異なる場合は、この README が最新です。

エディションとライセンス

kumbuka はオープンコアであり、エディションの境界はリポジトリの 境界です。つまり、リポジトリの境界がライセンスの境界です。

• コミュニティエディション。 公開サービスのリポジトリ（kumbuka-memory、 kumbuka-dispatch、kumbuka-worklist、および kumbuka-server と kumbuka-console）は、GNU Affero General Public License v3.0 (AGPL-3.0) に基づくオープンソースであり、各サービスは それぞれ単独で完全な製品として構築されています。 cimd-proxy は独立したツールで、Apache-2.0 の下で公開されています。
• エンタープライズエディション。 各サービスには、ビルド時にオープンコアと 組み合わせる、個別のクローズドなエンタープライズモジュールがあります。エンタープライズエディションは 機能を追加するだけで、既存の動作を変更することはありません。最初に追加される機能は、 バージョニングと監査です。 すべてのサービスの前段にある単一のエントリーポイントであるルーターと、その上に構築される 統合インターフェースは、エンタープライズエディションに属します。

kumbuka は通常、ネットワーク経由でアクセス可能なサービスとしてデプロイされるため、AGPL §13 が適用されます。変更したバージョンを実行し、ネットワーク経由でユーザーが操作できるようにする場合、 そのユーザーに変更したバージョンの対応するソースコードを提供する必要があります。

コントリビューション

コントリビューションを歓迎します。貢献方法と各リポジトリの開発環境の設定場所については、 まず CONTRIBUTING.md をご覧ください。セキュリティの問題を報告する場合は、 SECURITY.md をご覧ください。脆弱性について公開の Issue を 作成しないでください。