PathruleLettaが正しく押さえていること、そしてきちんと評価すべき1つの点
LettaはMemGPTの論文を源流としており、そこから正しい教訓を得ています。エージェントは自分のメモリを自分で管理すべきだ、ということです。メモリブロックは、やり取りをまたいで残り、検索しなくても常に見える、コンテキストウィンドウの構造化された区画で、エージェントは組み込みのツールでそれを読み、更新します。その後ろには、必要に応じて問い合わせる、セマンティックに検索できるストアとしてのアーカイブメモリがあり、エージェントは常に見えるものと調べられるものとのあいだでナレッジを移します。
はっきり評価しておくべき点があります。コアメモリは、問い合わせられるのを待ちません。構造上、最初からコンテキストウィンドウの中にあります。したがって、このサイトがメモリAPIに対して述べている「尋ねられたときにしか答えない」という主張は、Lettaのコアブロックには当てはまりません。そうでないふりをするのは不誠実です。
ハーネスはオープンソースで、マネージドのクラウドとセルフホストのサーバーがあり、Lettaは作れるものの1つとしてコーディングエージェントを挙げています。
並べて比較
| Letta | Pathrule | |
|---|---|---|
| 得られるもの | ステートフルなエージェントを作るためのプラットフォーム | すでに使っているコーディングエージェントのためのインテリジェンスレイヤー。CLI、MCPサーバー、VS Code拡張機能、Pathrule Cloud |
| ナレッジを編集するのは誰か | エージェント自身。組み込みのメモリツールで | チームとそのエージェント。学習した発見は助言のままで、チームのパターンには人の承認が必要 |
| 常にコンテキストにあるもの | メモリブロック。構造上 | パス単位の一部分。最初のツール呼び出しより前に注入 |
| ウィンドウを超えたときのスケールのしかた | アーカイブメモリを必要に応じて問い合わせる | パスのスコープ：このディレクトリ向けの部分だけを送る |
| 整理の軸 | human、persona、taskなどのブロック | リポジトリのパス |
| 変更をブロックできる制約 | 目的ではない | ルールはスコープ、優先度、強制レベルを持つ |
| エージェントとのつなぎ方 | 代わりにエージェントを自分で作る | `pathrule setup`がClaude Code、Codex、Cursor、GitHub Copilot、Windsurfを接続。あらゆるMCPクライアントがサーバーを使える |
Lettaに関する記述は、2026年8月に読んだLetta自身のドキュメントとブログに基づいています。誤りのある行があればお知らせください。修正します。
両者が本当に分かれるところ
エージェントを作るか、手元のエージェントを強化するか. 出荷する製品がエージェントそのものであり、そのメモリを第一級の機能にしたいなら、Lettaが正しいツールです。Pathruleは、すでにClaude Code、Codex、Cursor、GitHub Copilot、Windsurfを使っていて、エージェントを作り直したくない場合を前提にしています。
ブロックは設計するもの。パスは最初からあるもの。. メモリブロックは、誰かが設計する区画です。humanのブロック、personaのブロック、taskのブロック。役割を持つアシスタントには良いモデルです。コードの場合、構造はすでに存在しています。リポジトリです。Pathruleはそれをキーにするので、
/services/billingを編集しているエージェントが受け取るものに、ブロックの設計は必要ありません。自己編集か、レビューされたナレッジか. 自分のメモリを編集するエージェントは強力ですが、同時にレビューされていません。間違ったことを書き込み、それを事実として読み返すのを止めるものはありません。Pathruleでは、エージェントが保存したものは、チームが確認、編集、削除できる共有ワークスペースに置かれ、記録した発見は助言のままで自動的にルールへ昇格することはなく、チームのパターンは人が検証してはじめてエージェントに届きます。1件あたりの手間は増えますが、ナレッジをチームで共有するなら、そこが肝心な点です。
どちらを選ぶか
エージェントの製品を作っていて、そのメモリが出荷するものの一部であるとき、あるいはエージェント自身に記憶する内容を管理させたいときは、Lettaを選びましょう。
エージェントはすでに決まっていて、問題はそれらがチームの決定を知らないままリポジトリの中で動くことにあるなら、Pathruleを選びましょう。両方に当てはまっても、ぶつかることはありません。製品の中ではLettaを、それを作るコーディングエージェントの下ではPathruleを使います。
出典と検証
公式ドキュメントは2026年10月1日に確認しました。確認したドキュメントにはLettaの製品バージョンの記載がなく、ローカルでのテストもしていません。Pathruleに関する記述は、2026年10月9日に、リリース済みのPathrule CLI 0.6.1と照らし合わせて確認しました。
- Letta：プラットフォームの概要
ステートフルなエージェントのプラットフォームと、オープンソースのハーネスの位置づけについての公式情報。
- Letta：メモリブロックの付け外し
エージェントのコンテキストに表示され続ける、永続的なブロックの動作についての公式情報。
よくある質問
PathruleはLettaのようなエージェントフレームワークですか？
いいえ。そこが主な違いです。Lettaは、ステートフルなエージェントを作るためのプラットフォームです。Pathruleは、すでに使っているコーディングエージェント（Claude Code、Codex、Cursor、GitHub Copilot、Windsurf）に接続し、それらを乗り換えても残る、共有のパス単位のナレッジを渡します。
Lettaのメモリブロックは常にコンテキストにあります。注入より優れているのではありませんか？
決まった数のブロックについては、すっきりした設計であり、私たちも評価しています。トレードオフは規模です。常にコンテキストにあるものはすべてウィンドウを奪い合うので、ナレッジが手入れされた少数のブロックであるときに最もよく機能します。Pathruleは、リポジトリ全体にわたる数百のメモリとルールを前提とし、現在のパスを管理する部分だけを送ります。
Lettaのエージェントが自分のメモリを編集するように、PathruleでもエージェントがナレッジをPathruleに書き込めますか？
保存はでき、主導権はチームに残ります。MCPのツールを使えば、エージェントはメモリ、ルール、スキルを書き込め、それはチームが確認、編集、削除できるワークスペースに置かれます。Pathruleが自ら学習したものは、より慎重に扱われます。発見は助言のままで自動的にルールに変わることはなく、チームのパターンは人が検証してはじめてエージェントに届きます。チームで共有するナレッジにとって、そのレビューの手順は摩擦ではなく機能です。
どちらもオープンソースです。同じものですか？
公開している部分が違います。Lettaはエージェントのハーネスをオープンソースにしており、クラウドでもセルフホストでもデプロイできます。Pathruleがオープンソースにしているのはコンテキストのコアです。パス単位のエンジン、MCPのインターフェース、そしてアカウントもネットワークもなしにループを動かす組み込みのSQLiteバックエンドです。