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」プロジェクトが落ちる罠の回避策です。
なぜ 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 インテグレータ