Leteo

インストール • 仕組み • コマンド • 言語

---

Leteo — AI コーディングエージェントのための永続メモリー

コーディングエージェントはセッションが終わるとすべてを忘れ、コンテキストが圧縮されると、その大半を忘れてしまいます。Leteo は、エージェントが保持するメモリーです。判断、バグ修正、規約、そして学ぶのに大きなコストがかかった発見をローカルの SQLite データベースに保存し、関連するタイミングで呼び戻します。

バイナリは 1 つ、サーバーも API キーも不要です。名前を指定したプロジェクトでクラウドレプリケーションを有効にしない限り、データがマシンの外に出ることはありません。

同じ条件で比較 — 同じエージェントに同じ質問をし、Leteo を使った場合と使わない場合を比べました。

**Leteo なしでは 3 回中 0 回だったのに対し、ありでは 4 回中 4 回正解しました。**ばらつきを考慮しても残るのがこの結果で、トークン数はそれより不確かな指標です。すべての実行結果はこちらです。両方のベースライン、両条件で負担するセッションあたり約 15,400 トークンの固定コスト、そして同じ 7 回の実行をペアにして、Leteo は 3.7 倍のコストがかかる とした比較も掲載しています。

対応： Claude Code · ZCode · Codex · Cursor · Gemini CLI · OpenCode · Windsurf · VS Code Copilot · Kilo Code · Qwen · Kiro · Antigravity · Pi · DeepSeek Harness · Command Code

使い心地

記憶するように指示する必要はありません。それがこの仕組みの要点です。エージェントはプロジェクトの知識をすでに持った状態で各セッションを開始し、作業中にバグ修正や合意した規約、すぐには分からない発見などを保存していきます。メモはあなた向けではなく、未来の自分であるエージェント向けに書かれるため、会話の邪魔になりません。

残りは、自分で管理する SQLite ファイルです。leteo tui で開き、leteo export で持ち出し、leteo delete で削除できます。

コストに見合う価値はありますか？

13回の実行で測定した結果です。コードでは答えられない質問に対して、正解は4問中4問で、これを使わなかったエージェントは3問中0問でした。厳格なプロトコルでは、同じく0問だった相手に対して3問中3問です。ばらつきを考慮しても残るのは、この結果です。

トークン数のばらつきはさらに大きくなります。同じ質問での節約率は、中央値で27％、最大で70％です。ただし、プロンプトが1項目だけ異なっていた実行を除くと、17％と44％になります。記事ではその調整も行っています。コードで答えられる質問では差は誤差の範囲内で、同じ13回の実行から、反対の組み合わせを選べば「3.7倍のコストがかかる」という結論も導けます。

メモリでトークンを節約できる？では、すべての実行、2種類のベースライン、セッションごとに固定でかかる約15,400トークンのコスト、そして数値の信頼性が低い箇所を示しています。率直にまとめると、トークンを確実に節約できるわけではありません。エージェントが自信満々に別のことを答えるのを防ぎます。

インストール

# Linux and macOS
curl -fsSL https://raw.githubusercontent.com/asanabrial/leteo/main/scripts/install.sh | sh

# Windows
irm https://raw.githubusercontent.com/asanabrial/leteo/main/scripts/install.ps1 | iex

すでにツールをパッケージマネージャーで管理している場合は、そちらからインストールすることもできます。Homebrew は macOS と Linux の両方のアーキテクチャに対応しています。

brew tap asanabrial/leteo && brew install leteo

# Windows
scoop bucket add leteo https://github.com/asanabrial/scoop-leteo
scoop install leteo

# Windows, through winget
winget install asanabrial.leteo

winget では、各リリースがメンテナーによるレビューを受けるプルリクエストとして提出されるため、新しいバージョンがほかの方法より1、2日遅れて公開される場合があります。

# Anywhere with Node, if that is what you already have
npm install -g @asanabrial/leteo

最後の方法では、コマンドライン用に leteo が PATH に追加されますが、エージェントを設定できない唯一の方法です。npm が管理するバイナリからは leteo setup を実行できません。書き込もうとするパスが npm によって削除されるためです。代わりにインストール不要の npx の行でエージェントを設定するか、上記のいずれかの方法でインストールしてください。

次に Leteo を開き、Setup 画面からエージェントを設定します。

leteo tui

これで完了です。事前にほかのものをインストールする必要はありません。Rust も SQLite もランタイムも不要です。アーカイブには SQLite を組み込んだビルド済みバイナリが含まれており、各スクリプトは何かをインストールする前に、ダウンロードしたファイルを公開済みの SHA256SUMS と照合します。スクリプトを使うと、バイナリは ~/.local/bin、Windows では %LOCALAPPDATA%\leteo\bin に配置されます。Homebrew、Scoop、winget の場合は、それぞれのツールがほかのものと同じ場所に配置します。LETEO_INSTALL_DIR で配置先を変更でき、LETEO_VERSION で最新リリース以外のタグを指定でき、LETEO_BASE_URL で GitHub リリース以外の場所からダウンロードできます。この3つはバイナリではなくスクリプトの設定項目であるため、環境変数の表には記載していません。

リリースには5種類のビルドが含まれます。x86-64 の Linux、Windows、macOS と、arm64 の Linux、macOS です。Linux 向けの2種類は glibc 2.34 より新しいバージョンを必要としないため、Debian 12、Ubuntu 22.04、RHEL 9 以降で動作します。この下限は、GitHub が最新と呼ぶイメージをそのまま使うのではなく、リリースのワークフローで固定しています。v0.1.0 ではイメージのバージョンをそのまま使っていたため、Debian 安定版より新しい glibc が必要でした。Windows 向けビルドに必要なのは Windows 10 以降のみで、事前のインストールは不要です。C ランタイムはバイナリにリンクされているため、Visual C++ Redistributable も必要ありません。それ以外の環境では、Rust が必要な唯一の方法であるソースからビルドしてください。

cargo install leteo

これにより、crates.ioからリリース済みバージョンをビルドします。cargo binstall leteo を実行すると、コンパイルせずに同じリリースバイナリを取得できます。つまり、先ほどの説明のうち、より速い方法です。リリース前の作業を含め、代わりに main ブランチの内容をビルドするには、リポジトリを指定してください。cargo install --git https://github.com/asanabrial/leteo。

独自のチェックアウトをビルドする

作業コピーにあるものをインストールするには、任意のディレクトリからご利用のシステム向けのスクリプトを実行します。

# Linux and macOS
scripts/build-install.sh

# Windows
scripts\build-install.ps1

rustup と cargo が必要です。ツールチェーンがない場合は Rust 1.97.0 をインストールし、--locked を指定してリリースモードでビルドし、Cargo 独自のルート（CARGO_INSTALL_ROOT、次に CARGO_HOME、次に ~/.cargo）にインストールします。リリース用インストーラーが使用するディレクトリにはインストールしないため、ソースからのビルドでリリース版のインストールが上書きされることはありません。その後、チェックアウト内の assets/model/ からモデルをインストールします（未リリースのビルドにはダウンロード元となるリリースタグがありません）。すでに Leteo を設定している各エージェントに対して setup を再実行し、最後に doctor を実行します。ここでの setup は MCP エントリーのみを書き込みます。バイナリの新しいパスに合わせて変更が必要なのはこのエントリーであり、その --tools と --project はデフォルトにリセットされるため、手動で編集したエントリーは再度編集する必要があります。必要なエージェントには、--instructions または --hooks を自分で追加してください。まだ Leteo が設定されていないエージェントには変更を加えません。leteo setup <agent> で追加してください。LETEO_SETUP_AGENTS にエージェント名をスペース区切りで設定すると、そのエージェントだけを設定できます。また、単独で none と設定すると、どのエージェントも設定しません。空または空白のみの場合は未設定として扱われます。いずれかの手順が失敗すると、スクリプトはゼロ以外の終了コードで停止し、失敗したコマンドを示します。自身のストアやエージェントファイルに触れずに試すには、HOME、CARGO_INSTALL_ROOT、LETEO_DATA_DIR を一時ディレクトリに設定してください。

検索モデル

意味による検索では、質問に使われている単語が検索対象のメモにひとつも含まれていなくても検索できます。この検索では、バイナリ内ではなく、その隣のファイルに保存された 13 MB のモデルを読み込みます。リリースアーカイブ、インストールスクリプト、npm ラッパー、Docker イメージにはモデルが含まれています。それ以外のインストール方法（cargo install、ソースからのビルド、モデルが含まれていないパッケージなど）では、そのバージョンのタグにコミットされたファイルからモデルを一度だけ取得します。

leteo model install                      # downloads the model of this version, checks it
leteo model install --from ./model       # from a copy, with no network

leteo setup も、モデルが見つからない場合は同じ処理を行います。検証済みのモデルが用意されるまでは、これまでどおり単語だけで検索します。leteo doctor は、次の 3 つの状態のどれに当たるかを示します。見つかって検証済み（場所も表示）、未インストール、またはモデルはあるものの、このビルドで受け入れられるモデルではない状態です。モデルが読み込まれるのは、すべてのファイルがバイナリのビルド時に使われたハッシュと照合された後に限られます。

何もインストールせずに使う

MCP のドキュメントの多くは npx を前提としているため、npm に用意されたラッパーがリリースバイナリをお使いのプラットフォーム向けに取得し、同じ公開済みの SHA256SUMS と照合したうえで、すべての引数をバイナリに渡します。

{
  "mcpServers": {
    "leteo": {
      "command": "npx",
      "args": ["-y", "@asanabrial/leteo", "mcp"]
    }
  }
}

bunx @asanabrial/leteo mcp も同じように動作します。同じレジストリにある同じパッケージであり、ラッパーが依存するのは、どちらのランタイムにもともと備わっているものだけです。上記の npm install -g は同じパッケージを実行ごとに取得するのではなく、一度だけインストールする方法です。

npm のバージョンはリリースタグそのものなので、npm でバージョンを固定すると、取得するバイナリも固定されます。公開済みのバージョンがリリースに遅れると、この方法で利用するすべての人にひとつ前のリリースが気づかれないまま提供されてしまうため、両方のバージョン番号を一致させるチェックが設けられています。これは利用を始めるための方法であり、実行に最適な方法ではありません。PATH 上のバイナリならダウンロードなしで起動でき、leteo setup がエージェントに書き込むのもそのバイナリです。

プラグインとして

Claude Code は Leteo をプラグインとして導入します。Claude Code 独自のプラグイン機構を通じて、同じ MCP エントリーと、leteo setup が書き込むものと同じ5つのライフサイクルフックを登録します。

/plugin marketplace add asanabrial/leteo
/plugin install leteo@leteo

プラグインに含まれるのは設定であり、バイナリではありません。まず上記のいずれかの方法で leteo をインストールしてください。プラグインが登録する MCP エントリーとすべてのフックは PATH から leteo を実行するため、インストールされていないと、実行できないコマンドが5つ登録されることになります。プラグインが置き換えるのはセットアップ手順であり、削除すると登録内容も取り除かれます。

どちらか一方を選び、両方は使わないでください。二重に登録すると、ライフサイクルイベントのたびに処理が二重に実行されます。実際、気付かれるまでにプロンプトが二重に保存され、あるマシンでは同じ内容のペアが23組できていました。現在の leteo setup --hooks はインストール済みのバンドルを探し、見つかったファイル名を示して、二重登録を拒否します。

Codex にも plugin/codex に同じバンドルがあります。こちらはフックを登録する唯一の方法です。leteo setup codex は MCP サーバーを登録しますが、フックは一切登録しないため、Codex にツールがあっても、それをいつ使うかを指示するものがありません。

同じマーケットプレイスには、plugin/zcode に ZCode 用のプラグインもあります。マーケットプレイスの追加はコマンドではなく、デスクトップでの操作です。設定 → プラグイン → 作成 → マーケットプレイスを追加を選び、asanabrial/leteo を指定します。その後、一覧から leteo-zcode をインストールします。

CLI ではマーケットプレイスを追加できません。zcode plugins で一覧表示・有効化できるのは、すでにインストール済みのものだけです。zcode 0.16.5 で確認済みです。

$ zcode plugins --help
  plugins    List and enable installed plugins (`plugins list`)

このクライアントは SubagentStop と SessionEnd のどちらも発生させないため、5つではなく3つのフックを登録します。また、他者が設定した切り替えに依存しない方法でもあります。ZCode は ~/.zcode/cli/config.json の hooks.enabled が true の場合に限り、設定ファイルのフックを実行します。この設定は初期状態では無効で、プラグインを有効にすると、そのプラグインのフックも有効になります。

Pi では Leteo をパッケージとして導入します。leteo setup pi は、Pi のエージェントディレクトリ（PI_CODING_AGENT_DIR、または ~/.pi/agent）に plugin/pi を書き込み、以前のセットアップが mcp.json に残した leteo エントリーを取り除きます。このパッケージはセッションを開始・終了し、プロンプトとツールの戻り値から得た Key Learnings を保持し、コンパクションの要約を保存して、メモリプロトコルをシステムプロンプトに追加します。また、leteo mcp 自体を MCP サーバーとして登録します。Pi 1.2.0 以降ではツールをオンデマンドで読み込み、それより前のバージョンではリクエストごとに宣言します。 mcp.json のエントリーは名前によってこの登録を上書きするため、セットアップでは書き込まなくなりました。このパッケージは npm からもインストールできます（pi install npm:@asanabrial/leteo-pi）。どちらか一方の方法を選び、両方は使わないでください。

アンインストール

leteo uninstall
leteo uninstall --yes
leteo uninstall --yes --keep-data

最初のコマンドは削除対象を表示するだけで、何も変更しません。2つ目のコマンドは削除を実行します。Leteo は設定済みのすべてのエージェントから削除され、その後、検索モデルも含めてマシンから削除されます。Windows では「インストールされているアプリ」にも登録されるため、そこから削除することもできます。

--keep-data は、再取得できない唯一のものを残すためのオプションです。このオプションを付けると、データディレクトリはそのまま残ります。ストア、settings.json、およびその隣にある移行時のコピーが保持され、エージェントとバイナリのみが削除されます。付けない場合、ストアとその -wal／-shm ファイルも削除されます。

どちらの方法でも、Leteo が作成していないファイルは削除されません。手動で作成したコピー（アップグレードの説明で以前作成を求めていた leteo.db.bak-before-migrate など）は、名前にかかわらず残ります。移行によって作成された leteo.db.pre-schema-N のコピーも同様です。--yes を付けずに leteo uninstall を実行すると、何かを変更する前に、削除されるものと残るものがすべて表示されます。

1つのエージェントだけから削除し、他のエージェントでは使い続けるには、次のようにします。

leteo setup claude-code --uninstall

これにより、MCP エントリー、ライフサイクルフック、プロトコルブロックだけが取り除かれ、それ以外は何も変更されません。他のサーバー、他のツールのフック、ユーザー自身のメモはそのまま残ります。

MCP

標準入出力を使う 23 個のツールを備えた MCP サーバーです。直接実行することも、leteo setup でクライアントに書き込むこともできます。

leteo mcp

このように実行すると、すべてのツールを利用できます。23 個のうち 3 個はストア全体を変更またはカウントするため、leteo setup では除外されています。エージェントに書き込まれるのは --tools=agent で、エージェントが作業中に使う 20 個のツールです。--tools ではプロファイルまたは単一のツールを選択し、--project ではプロセスに使用するプロジェクトを固定します。

これに加えて、JSON コマンドライン、対話型ターミナル UI、および 15 種類の MCP クライアント向けのセットアップ機能があります。リストはこのページの上部にあります。

MCP レジストリにおける名前は mcp-name: io.github.asanabrial/leteo で、server.json で公開されています。この行をコメントに隠さず明記しているのは、レジストリがこれを読み取って、このリポジトリがクレートを所有していると判断するためです。また、crates.io はこのファイルを表示する際に HTML コメントを削除します。

HTTP

HTTP をすでに扱えるスクリプトやプラグイン向けに、leteo serve を実行すると、同じツールをループバックで公開できます。MCP クライアントは不要で、呼び出しごとにプロセスを起動する必要もありません。

leteo serve

GET /tools はエンドポイントを示し、GET /health は稼働中であることを返します。POST /tools/<name> には、そのツールの引数を JSON 本文として渡します。MCP ツールと同じ名前、同じ引数なので、覚える用語は一つだけです。

curl -s http://127.0.0.1:7437/tools/mem_save -d '{"title":"A decision","content":"what and why","type":"decision"}'

MCP や CLI 経由の場合と同じストア、同じルールが適用されます。HTTP 用の保存処理も同じハンドラーを使うためです。HTTP 経由で保存した内容も、エージェントから保存した場合とまったく同じようにインデックス化、正規化され、レプリケーション用にキューへ追加されます。デフォルトではループバックにバインドされます。--bind 0.0.0.0:7437 を指定するとネットワークに公開され、その旨がログに出力されます。ストアにはエージェントが記憶したすべての内容が保存されるためです。

入力する内容

ほとんどありません。保存も呼び出しも自動で行われます。自分で確認したいときのために、外からストアを見てみましょう。回答を返すすべてのコマンドは JSON を出力します。画面表示を行う tui は例外です。デフォルトのデータベースは ~/.leteo/leteo.db です。

読み取り。 実際に使うのは search です。--all-projects を指定すると、現在いるプロジェクトの範囲を超えて検索できます。recent は時系列で並んだ直近の項目、context はセッション開始時にエージェントへ渡されるブロックで、セッションが何をもとに始まるかを表示します。timeline は、あるメモリーの前後に保存された内容を読み取ります。stats は保存されている内容を数えます。tui ではすべてを一画面に表示します。

leteo search "connection pool" --project leteo
leteo search "connection pool" --all-projects
leteo recent --project leteo --limit 20
leteo context leteo --scope project
leteo timeline 42 --before 5 --after 5
leteo stats
leteo tui

手動での書き込み。 エージェントが作業中に保存するため、ほとんど必要ありません。ただし、自分の言葉で残したいメモリー、エージェントが代わりに設定するセッションの境界、複数のメモリーを一つにまとめ、置き換えた内容を削除せずに記録する consolidate は例外です。

leteo save "SQLite architecture" "One writer, many readers" --project leteo --type architecture
leteo consolidate 12 13 --title "SQLite architecture" --content "One writer, many readers" --type architecture
leteo session-start session-1 --project leteo
leteo session-end session-1

エージェントのセットアップ。 エージェントを指定しなければ、対話形式でセットアップが進みます。エージェント名を指定すると、そのエージェントがセットアップされます。--hooks を指定すると、メモリーを自動化するライフサイクルフックが追加されます。--dry-run を指定すると、書き込みは行わず、変更対象となるすべてのファイルを報告します。

leteo setup
leteo setup claude-code --hooks
leteo setup opencode --dry-run

健全な状態の維持。 doctor はすべてのチェックを実行し、失敗したチェックとその理由を示します。--repair を指定すると、単独で安全に実行できる修復が行われます。具体的には、不足している全文検索トリガーの復元、インデックスの再構築、古くなったハッシュの再計算、以前の導入時に統合されなかったメモリータイプの統合、ビジー状態のフックがストアの横に保持していたキャプチャーの再適用です。 export と import はストアを別のマシンに移行し、obsidian-export はストアを Markdown としてボルトに書き出します。

leteo doctor
leteo doctor --repair
leteo export --project leteo --output leteo-export.json
leteo import leteo-export.json
leteo obsidian-export --vault C:\Vaults\Notes --project leteo

プロジェクト。 プロジェクトはディレクトリから判定されるため、同じ作業が別々の名前で登録されることがあります。consolidate は複数のプロジェクトを一つの名前にまとめ、prune はメモリーを一つも持たないプロジェクトを削除します。

leteo projects list
leteo projects consolidate --project leteo --apply
leteo projects prune --apply

競合。 新しいメモリーが古いメモリーと矛盾しているように見える場合、両者がペアにされ、エージェントがそのペアを解決します。次のコマンドでは、同じペアを外部から確認できます。list と show は登録済みのペアを表示し、scan はまだ記録されていないペアを探し、stats は判定結果ごとに件数を数えます。

leteo conflicts list --project leteo --status pending
leteo conflicts show 7
leteo conflicts scan --project leteo --apply
leteo conflicts stats --project leteo

削除。 --hard を指定しない場合、メモリーには削除済みの印が付き、回答に再び表示されなくなります。指定した場合は、行が削除され、関連付けも解除されます。プロジェクトにも同じフラグを指定できます。セッションにはフラグを指定できません。メモリーが残っている間は削除が拒否され、件数が示されます。セッションは、メモリーを一緒に削除して消すのではなく、空になったときに削除されます。

leteo delete observation 42 --hard
leteo delete session session-1
leteo delete project leteo --hard

projects consolidate、projects prune、conflicts scan は、--apply を指定するまで何も変更しません。指定しない場合は、それぞれが実行する内容を正確に報告します。

言語

3 つの設定があります。それぞれ異なる問いに答えるためのものです。

interface は、パネル、メニュー、ヘルプなど、Leteo 自体の画面で使う言語です。英語、スペイン語、ポルトガル語、フランス語、ドイツ語、イタリア語、ルーマニア語、カタルーニャ語、ガリシア語、バスク語、オランダ語、ポーランド語、スウェーデン語の 13 言語に対応しています。メモリに設定できる言語と同じ表から、意図的に同じ 13 言語を選んでいます。未設定の場合はマシンのロケールに従うため、スペイン語のコンピューターでは、尋ねられることなくダッシュボードもスペイン語になります。ルーマニア語は話者が書いたのではなく機械翻訳であり、選択メニューにもその旨が表示されます。他の 12 言語はそうではありません。

voice_language は Sardi が話す言語です。Leteo の画面ではなく、エージェントとの会話に書き込まれる文を決めるため、別の設定になっています。スペイン語のマシンで英語を使って作業するのはごく普通のことです。未設定の場合は interface に従います。対応する言語は同じ 13 言語です。

language はメモリの記述に使う言語です。これはモデルに渡され、解析されるものではないため、自由記述で、上記の 13 言語に限られません。español、Spanish、português do Brasil、日本語 はすべて使用できます。未設定の場合、各メモリはそれを生成した会話の言語で記述されます。

メモリには、記述されたときの言語が保持されます。そのため、この設定を変更しても、以後記述される内容だけが影響を受けます。保存済みのメモリは変換されず、それらを検索するときも引き続き以前の言語の語幹処理が使われます。Setup では、変更を確定する前に該当するメモリ数を警告します。また、leteo doctor は、これを問題として扱わず、言語ごとのメモリ数を報告します。

設定

この 3 つと、さらに 3 つの設定は、データディレクトリ内の settings.json に保存されます。移動していない場合の場所は ~/.leteo/settings.json です。Setup 画面からファイルを書き込めます。また、手動で開いて編集することも想定されています。読み取れない値があっても、ファイル全体ではなく、その設定だけが無効になります。ただし、編集中にフックが失敗してはならないため、その場では通知されません。読み取りに失敗した設定を確認するには、leteo doctor を実行してください。

キー	値	未設定の場合
interface	上記 13 言語のいずれか	マシンのロケールに従う
voice_language	上記 13 言語のいずれか	interface に従う
language	自由記述	各会話の言語
voice	all、reminders、quiet	reminders
context_size	slim、full、deep	full
semantic_search	true、false	true

2 つの言語設定には、その言語での名称を指定します。es ではなく español のようにします。人が入力するファイルなので、読み取り時には表記の違いも許容されます。英語名、ISO コード、アクセント記号を省いたつづりもすべて使用できます。

voice は、Sardi が自分の作業についてどれだけ声に出して伝えるかを指定します。すべて伝える、保存時のリマインダーだけを伝える、何も伝えない、のいずれかです。別途指定しない限り reminders になります。すべてのプロンプトで報告するのは、求められていない人にとってはノイズです。一方、リマインダーは実際の処理を担うため、報告を再び有効にするには all を指定します。context_size は、セッション開始時に読み込むメモリの数を指定します。小さなコンテキストウィンドウ向け、あるいは予算よりもストアを優先する場合に合わせて、20、30、80 から選べます。semantic_search は、単語だけでは答えられない検索で、13 言語すべてを対象に意味検索も行うかどうかを指定します。意味検索にはバイナリと一緒に配布されるモデルを使い、検索時にネットワークへ接続することはありません。この方法で見つかった結果には semantic と表示されます。実行中に保持されるメモリが多すぎる場合や、入力した単語を含む回答だけが必要な場合は、これを無効にしてください。

6 つの設定のうち 2 つはフラグでもあります。エージェントを再設定せずに変更できるようにするためです。どちらも単独で完全なコマンドになります。

leteo setup --language "español"
leteo setup --context slim

Cloud

オプション機能で、デフォルトでは無効になっており、プロジェクトごとに設定します。お使いのマシンがクライアントであり、クラウド側から接続してくることはありません。

有効にするには、サーバーの場所と、どのプロジェクトを送るかの2つを指定します。config set は最初の情報をデータディレクトリに書き込みます。トークンが含まれるため、アクセス権限が制限されたファイルに保存されます。enroll はプロジェクトを指定します。両方を設定するまで複製は行われず、以下のコマンドは何も言わずに開始するのではなく、そのことを知らせます。

leteo cloud config set --server https://memory.example.com --token YOUR-TOKEN
leteo cloud enroll --project leteo
leteo cloud config show

config show は設定を読み取り、トークンを存在を示すフラグに置き換えて表示するため、安全に貼り付けられます。

有効にすると、health はサーバーが稼働して応答しているかを確認します。status は一切接続せず、このマシン側の状態を報告します。登録済みの項目、保留中の変更数とその期間、最後の試行が失敗したかどうか、失敗した場合はその理由を確認できます。sync は今すぐ1サイクル実行し、leteo serve は中断されるまで、HTTP API と並行してバックグラウンドでサイクルを実行し続けます。

leteo cloud health
leteo cloud status
leteo cloud sync
leteo serve

leteo cloud serve と混同しないでください。こちらはもう一方、つまりサーバー自体を起動するコマンドであり、自分でサーバーをホストする場合にのみ実行します。

Engram からの移行

Leteo は、Gentleman Programming の Engram のワークフローと MIT ライセンスの実装を基にした、独立した Rust 製品です。同プロジェクトとの提携や推奨を受けておらず、CLI のドロップイン互換性も保証しません。

同じ合成コーパスを各エンジン独自の書き込み経路で保存し、各エンジン独自の検索機能に同じクエリを実行した、計測に基づく比較は docs/comparison.md にあります。

Engram のデータベースを直接読み取るため、移行はコピーで行います。最初のコマンドは取り込む内容を報告するだけで、何も書き込みません。2つ目のコマンドは移行を実行し、2回目の実行では二重にすべてを取り込まないよう拒否します。

leteo import --from-engram --dry-run
leteo import --from-engram

デフォルトでは ~/.engram/engram.db を使用します。別のパスを指定するには --source を渡してください。コピーでは先行書き込みログを反映するため、実行中の Engram にある最新のメモリも移行され、Engram 側のファイルには書き込みません。

2つ目のコマンドは、1つのトランザクションで移行先に書き込みます。すでにメモリ（セッション、プロンプト、観察記録など）が保存されているストアは、上書きせずに拒否され、拒否理由として保存内容が示されます。削除が行われることはありません。コピーの途中で失敗した場合、移行先はそのままの状態に保たれ、コマンドを再実行するだけで再試行できます。

ビルド

Leteo の実行には Rust 1.97 以降が必要です。

cargo fmt --all
cargo test
cargo clippy --all-targets -- -D warnings
cargo build --release

CI ではテストが実行されます。コミットする前に、フォーマットと lint を実行してください。そのため、これらはワークフローだけでなく AGENTS.md にも記載されています。

クラウドのテストには実際の PostgreSQL が必要であり、用意されていない場合はスキップされます。一時的なデータベースを TEST_DATABASE_URL に指定して cargo test -- --ignored を実行してください。テストは独自のスキーマを作成して削除するため、スキーマを共有するようには作られていません。

人間、エージェントを問わず、貢献する方はまず AGENTS.md をお読みください。

ドキュメント

個々の測定について詳しく解説した記事は docs/ にあります。最初の記事は 調整する価値のあるものは何もなかった です。第 3 段階の検索は、別のプロジェクトに関する質問に 90.2% の確率で回答しており、自分のプロジェクトに関する質問よりも 高い 頻度です。全範囲にわたって適用した 4 つのルールから、これは誰にも解決できない閾値だと分かります。

2 つ目の記事は メモリはトークンを節約するのか？ です。このプロジェクトを始めるきっかけになった問いを取り上げ、プロジェクト自身を対象に答えています。リポジトリにすでに答えがある質問では、節約量はノイズの範囲内です。答えられない質問では、メモリなしのエージェントはより多く消費し、それでも 3 回中 3 回とも間違えます。また、冒頭のブロックからサンプル抽出した 11 件のメモリのうち 6 件は、リポジトリだけで再現できることが分かりました。コード、仕様、テスト、Git の履歴をすべて合わせれば再現できます。

3 つ目の記事は Leteo と他のメモリエンジンの実測比較 です。同じ合成コーパスを Engram と 2 つの他のエンジン、そして Leteo に保存し、各エンジン独自の検索機能に同じクエリを投げて、1 回の実行で得られた数値を示しています。ハーネスから生成されるため内容がずれることはなく、各エンジンの測定時のバージョンも併記しています。

環境

設定が必要なものはありません。 これはバイナリが読み取る変数をすべて列挙したものであり、表にない変数をバイナリが尊重した場合にビルドを失敗させるテストもあります。設定する項目の一覧ではありません。leteo setup はインストールに必要な内容を各エージェント固有の設定ファイルに書き込み、インターフェースで選んだ内容は settings.json に保存されます。どちらも環境変数を設定しません。

ほとんどの変数にはコマンドラインフラグもあり、フラグが優先されます。同じ問いにコマンドラインが答えていない場合にのみ、変数が読み取られます。

変数	フラグ	用途
LETEO_DATA_DIR	--data-dir	ローカルデータディレクトリ。デフォルトは ~/.leteo です
LETEO_DATABASE	--database	ローカル SQLite の明示的なパスです
LETEO_TOOLS	mcp --tools	agent、admin、all、または個別のツール名です。何も指定しない場合はすべてのツールが対象です
LETEO_MODEL_DIR	—	セマンティック検索モデルを格納するディレクトリです。ほかの場所より先に検索されます
LETEO_MODEL_URL	model install --url	leteo model install と leteo setup がモデルを取得する場所です。このバージョンのタグにコミットされたファイルの代わりに、3 つのファイルをそれぞれ元の名前で格納したディレクトリを指定します
LETEO_PROJECT	mcp --project	MCP サーバーがプロセス全体で信頼するプロジェクトです。指定しない場合は作業ディレクトリで決まります
LETEO_AGENT_CLI	conflicts scan --semantic	競合候補を判定するエージェント CLI です。claude または opencode を指定します
LETEO_SYSTEM_LANGUAGE	—	LANG で指定されていない場合に、このマシンで使用する言語です。一度だけ読み取られ、leteo setup で選択肢として提示されます

フラグの優先が影響するため、もう少し説明が必要なものが 2 つあります。

• LETEO_TOOLS は、Leteo がセットアップするすべてのエージェントについて、すでに指定済みです。書き込まれる MCP エントリは leteo mcp --tools=agent を実行します。その後でこの変数をエクスポートしても、そのエージェントには何も影響しません。設定ファイル内のプロファイルを編集するか、セットアップをもう一度実行してください。
• LETEO_DATA_DIR は、実際にエクスポートする理由がある唯一の変数です。MCP サーバーを起動するのはあなたではなくエージェントです。そのため、~/.leteo 以外の場所にあるデータベースを使うには、エージェントの環境変数を通じて渡すか、設定ファイルで実行されるコマンドに --data-dir を指定する必要があります。

クラウドを自分のマシンで使う

leteo cloud config set はサーバーとトークンをデータディレクトリに保存するコマンドで、設定にはこれを使用します。この2つの値は、そのファイルで該当項目が空の場合にのみ読み込まれるため、これより前に行ったセットアップも変更なく動作し続けます。

変数	用途
LETEO_CLOUD_SERVER	cloud health、cloud sync、クライアント設定に使用するクラウドのベース URL
LETEO_CLOUD_TOKEN	同期用ベアラートークン。32 バイト以上

leteo cloud serve も LETEO_CLOUD_TOKEN を独自のレガシー静的トークンとして読み込みます。クライアントとサーバーを兼ねるマシンでは、1つの変数名が2つの意味を持ちます。

サーバー上のクラウド

これらの設定は leteo cloud serve を実行する担当者のもので、サービスの定義箇所で設定します。詳しくは docker/docker-compose.yml を参照してください。これらは設定ではなくデプロイ用シークレットであり、通常のインストールには適用されないため、意図的にウィザードは用意されていません。

変数	用途
LETEO_DATABASE_URL	cloud serve 用の PostgreSQL URL
LETEO_DASHBOARD_SECRET	ダッシュボード署名用シークレット。32 バイト以上
LETEO_CLOUD_TOKEN_PEPPER	管理対象トークン用 HMAC ペッパー。32 バイト以上
LETEO_CLOUD_ADMIN	オプションのレガシー管理者ベアラートークン。32 バイト以上
LETEO_CLOUD_ALLOWED_PROJECTS	レガシーなクラウドトークンに必須の許可リスト
LETEO_CLOUD_HOST	クラウドのバインド先ホスト。デフォルトは 127.0.0.1
LETEO_CLOUD_PORT	クラウドのポート。デフォルトは 8080
LETEO_CLOUD_MAX_POOL	PostgreSQL 接続プールの上限
LETEO_CLOUD_MAX_PUSH_BYTES	クラウドへのプッシュ本文の最大サイズ

サーバーが保持する内容の閲覧。 管理者トークンで /dashboard/login にサインインすると、/dashboard から読み取り専用の閲覧画面に移動できます。画面では、プロジェクト、各プロジェクトのセッションとメモリ、メモリのタイトル、内容、トピックキーを対象にした検索を確認できます。サーバー側でレンダリングされ、何も編集しません。また、ログの現在の状態を表示するため、削除済みのメモリは表示されません。管理者であればサインインできますが、すべてのプロジェクトにアクセスできるわけではありません。閲覧画面にはトークンが許可を持つプロジェクトのみが表示され（* の許可がある場合はすべてのプロジェクト）、それ以外のプロジェクト名を指定すると 403 で拒否されます。一覧はプロジェクトが 200 件、セッションが 100 件、メモリが 100 件、検索結果が 50 件で打ち切られ、打ち切られた場合はページにその旨が表示されます。ユーザー、許可、トークンの管理は対象外です。

ライセンスと著作権表示

Leteo は MIT License の下で配布されています。上流プロジェクトの著作権表示と正確な参照リビジョンについては、LICENSE と NOTICE を参照してください。タグ付きのバイナリアーカイブには、Rust の依存関係を網羅した生成済みの THIRD_PARTY_LICENSES.html も含まれています。