TL;DR: ベテランエンジニアの「効くプロンプト」が個人の引き出しに留まる問題を解消するため、業務フロー特化型マルチエージェント・オーケストレーター + 個人→組織メモリ自動循環機構 を持つ OSS Praxia を Apache 2.0 で公開しました。SSO / RBAC / 監査ログ / KMS 暗号化までフル OSS、商用 SaaS の Enterprise tier paywall を回避できます。

エージェント開発で 6 ヶ月後に当たる「壁」

シリアスにエージェントを作っているチームを観察すると、ほぼ必ず同じ壁に当たります。

Month 1:  「X 用のチャットボットを作った」     (動く)
Month 6:  「精度が下がってきた」                (memory bloat、curation 不在)
Month 12: 「シニアが退職してプロンプトも消えた」

3 番目が真の killer です。シニアエンジニアは「効くプロンプト」を磨きますが、それは個人の notes.md や Cursor の履歴に閉じ込められています。組織の資産にならないまま、半年積み上げた tribal knowledge が退職と共に消える。

既存のエージェントフレームの大半は メモリを 1 つのバケツ扱い します。ベクトル DB に何でも入れて、similarity で検索。これが最初の間違いで、メモリには種類があります:

生のユーザメモ: 一時的、個人別、低 S/N
チームの慣習: 全社共通、時間経過で陳腐化
不変のベストプラクティス: バージョン管理、レビュー済、変更ゆるやか

3 種類で寿命・ACL・検索の意味が違うのに、一緒くたにすると同じ速度で減衰します。

Praxia の解決策 — 5 層スタック + 3 経路昇格

Praxia は 意図された寿命 + ACL 境界でメモリを階層化し、自動昇格エンジンでループを閉じます。

L1 PersonalMemory   ユーザ別、6 種のバックエンド (JSON/Mem0/Letta/Zep/...)
L2 PromotionEngine  3 経路並列で昇格判定
L3 SharedMemory     組織横断、RBAC ゲート、減衰あり
L4 MarkdownStore    git 管理、PR レビュー必須、不変
L5 GraphLayer       任意 (Zep/Graphiti)、関係抽出向け

肝は L1 → L4 が手動ではない こと。Sleep-time Consolidator (夜間バッチ) が個人メモリをスキャンし、「組織に昇格させるべきか」を判定します。

3 経路昇格エンジン

「memory consolidation」系の論文/OSS で見るのは大半が単一機構 (要約 + 閾値、または LLM スコアリング)。両方とも本番で破綻します:

頻度のみ: 1 件しかないが致命的に重要な insight (シニアの custom prompt 等) を取りこぼす。FN 高い
アウトカムのみ: 結果データが疎な領域でノイズに弱い。FP 高い
LLM 自己評価のみ: 候補ごとに LLM 呼出で高コスト、長文に偏る bias あり

Praxia は 3 つの独立シグナルを並列実行 して合成:

頻度 (Frequency): N 人/N セッション以上で再出現するか
アウトカム相関 (Outcome correlation): 受注成功 / テスト合格 / PR 承認等の正成果と共起するか
LLM 自己評価 (Self-eval): 0..1 で「組織知候補度」スコア

最終スコアは加重ブレンド。いずれか 1 経路でも決定的なら昇格、単一機構依存を避ける。これが「memory + LLM」プロジェクトが落ちる罠の回避策です。

実装: praxia/memory/promoter.py

なぜ Layer 4 が git 管理 Markdown なのか

「組織として承認された best practice」は、コードと同じレビューフローを通すべきです。Layer 4 を平文 Markdown でリポジトリに置くと:

PR + CODEOWNERS で承認
git blame で「誰がいつ何を言ったか」
git log で変更履歴
マージコンフリクトで標準的な解決

エージェント基盤がこれを内部で再発明するのは退化です。組織凍結知を Markdown ファイルに置けば、これら全部タダで使えます。

OSS 同梱の機能 — 商用 SaaS が paywall する箇所

商用 SaaS が Enterprise tier 課金にするものを、Apache 2.0 で全部同梱:

OIDC SSO (Google / Microsoft Entra / Okta / GitHub / Keycloak)
ユーザ別 OAuth + KMS-backed トークン暗号化 (5 アダプタ: local / AWS / Azure / GCP / Vault)
複数 LTM 並列: Mem0 + Zep + HindSight を並列実行、Reciprocal Rank Fusion で融合
監査ログ + RBAC + リソース別 ACL
27 LLM エイリアス via LiteLLM: Anthropic / OpenAI / Azure OpenAI / AWS Bedrock / GCP Vertex AI、または Ollama (Llama / Gemma / Qwen / Phi) で完全オンプレ

コード生成型スキル (Claude Skills 流)

地味に楽しい機能: pptx_designer / docx_designer。LLM が python-pptx / python-docx のコードを書き、AST 許可リストの sandbox で実行、デザイン済 .pptx を直接返します — 複数カラムレイアウト・マトリクススライド・matplotlib チャート埋込・テーマ適用 (色 / フォント / ロゴ / フッター)。

from praxia.skills import PptxDesignerSkill, ThemeStore

theme = ThemeStore().load("acme_corporate")
deck = PptxDesignerSkill().design(
    "Q4 売上レビュー — 表紙、サマリ、TOP3 顧客、課題 2x2 マトリクス、次アクション。10 枚で。",
    theme=theme,
)
Path("review.pptx").write_bytes(deck.bytes)

サンドボックスは import を pptx, docx, matplotlib, numpy, PIL + 安全な stdlib に制限。os / subprocess / dunder escape は不可。30 秒タイムアウト、POSIX で 512MB RAM cap。失敗時は traceback を LLM に戻して最大 3 回リトライ。

7 拡張ポイント (各 ~50 LoC)

すべての拡張ポイントは同じプリミティブ praxia.extensions.Registry で実装。コアファイル編集なしで追加可能。

拡張ポイント	プロトコル	エントリポイント
Connector (Box / Notion / Slack / Salesforce 等)	`Connector`	`praxia.connectors`
Memory backend (JSON / Mem0 / Zep / 自前)	`MemoryBackend`	`praxia.memory_backends`
File parser (PDF / docx / pptx / etc.)	`Parser`	`praxia.parsers`
Output exporter (Markdown / HTML / pptx / docx)	`Exporter`	`praxia.exporters`
OAuth provider	`OAuthProvider`	`praxia.oauth_providers`
Skill	`Skill` (基底クラス)	`praxia.skills`
Flow (マルチエージェント pipeline)	`Flow` (基底クラス)	`praxia.flows`

pyproject.toml にエントリポイントを書いて pip install -e . するだけで Praxia が自動発見。

LangGraph / AutoGen / CrewAI との位置づけ

これらは オーケストレーション DAG が得意です。Praxia は別の問題 — マルチユーザの ACL-aware なメモリ循環 — を解いています。両者は 併用可能: リポジトリに LangGraph ノードから Praxia メモリバックエンドを呼ぶ例があります。

トップ課題が「5 つのエージェントを条件付きエッジで並列オーケストレーションしたい」なら LangGraph。「シニアエンジニアの tribal knowledge が消えるのを防ぎたい」なら Praxia。

試す

pip install "praxia[ui,office]"
praxia init && praxia ui

これで Streamlit UI が立ち上がる (SSO / 監査ログ / コード生成デザイナー / 自律エージェント全部入り)。ライブラリ利用も:

from praxia import Praxia

p = Praxia(user_id="alice", llm="claude")
result = p.run("この契約書のリスクをレビュー", attachments=["contract.pdf"])
p.personal_memory.search("契約リスクのパターン")

リポジトリ: github.com/praxia-dev/praxia
デモ: praxia.tools
ライセンス: Apache 2.0

求めているフィードバック

α 段階です。具体的に:

「個人 → 組織メモリ循環」は実際の課題ですか? 架空問題を解いている可能性?
3 経路昇格エンジン — オーバーエンジニアリング? それとも本当に必要?
5 層モデル — 過剰? それとも適切?
どんな機能があれば自社用にフォークしますか?

issue / PR 歓迎。「層モデルが under-fit する事例」を特に知りたいです — 早期に穴を見つける価値があります。

ここまで読んでいただきありがとうございます。共感したら GitHub スター⭐ お願いします。Discussions タブでアーキテクチャ議論受付中です。

関連シリーズ記事 (Zenn)

業務領域別 / ペルソナ別の詳細記事を Zenn にも順次公開中:

業務領域別: 投資 / 営業 / 設計 / 購買 / 特許 / 法務
ペルソナ別: 情報システム部門 / エンジニアリング VP / OSS インテグレータ