「AIコーディングエージェントは便利だが、毎回ゼロから説明し直すのが面倒だ」——Claude CodeやCodex CLIを日常的に使う人なら、一度は感じたことがあるはずです。セッションを閉じれば、プロジェクトの文脈も、あなたの好みも、前回つまずいた場所も、きれいに忘れられてしまう。エージェントは優秀な「道具」ではあっても、経験を積み重ねる「同僚」ではありませんでした。
Letta Code は、その前提を覆そうとするOSSです。ひとことで言えば「記憶・アイデンティティ・学習能力を持つ、ステートフルなAIエージェントを動かすCLIハーネス」。MemGPTという記憶付きLLMの論文で知られる開発チーム（Letta社）が公開したもので、エージェントが自分の記憶・スキル・さらにはハーネス自体を書き換えながら、長い時間をかけて成長していく——それがこのツールの核心です。
この記事では、letta-ai/letta-code の設計思想を一次ソース（公式リポジトリ・ドキュメント・論文）から読み解き、Claude CodeやCodex CLIとの違い、インストール、そしてメモリブロックやMemFSといった記憶の仕組みまでを、順を追って解説します。エージェントとの付き合い方そのものを変えうる、その正体を見ていきましょう。
- ・Letta Codeは「記憶を持つステートフルなエージェント」を動かすCLIで、セッションをまたいで文脈と学びを保持する。
- ・記憶はメモリブロック・MemFS（git管理）・スキルの多層で管理され、エージェント自身が読み書きして成長する。
- ・Claude Code / Codex CLIが「セッション単位の道具」なら、Letta Codeは「使うほど賢くなる同僚」を目指す立ち位置。
- ・モデルはOpenAI・Anthropic・Z.aiなどから選択可。CLI・デスクトップ・ブラウザ・Slack/Telegramで同じエージェントに触れる。
AIエージェントを「時間をかけて動かし続ける」設計思想については、当サイトの ハーネスエンジニアリング入門ガイド——AIエージェントの器を設計する でも整理しています。Letta Codeは、その「器（ハーネス）」に記憶という軸を持ち込んだ実装として読むと理解が進みます。
1. Letta Codeとは何か——記憶を持つステートフルエージェント
Letta Codeを一文で説明すると、「人よりも道具に近かったエージェントを、道具よりも人に近づけるためのハーネス」です。公式リポジトリの説明は明快で、次のように書かれています。
Letta Code is a stateful agent harness for creating agents that are more like people than tools. Letta Code agents have memory, identity, and a sense of experience over time. （Letta Codeは、道具よりも人に近いエージェントを作るためのステートフルなエージェントハーネス。Letta Codeのエージェントは記憶とアイデンティティ、そして時間を通じた経験の感覚を持つ。）
ここで鍵になるのが「ステートフル（stateful）」という言葉です。従来のコーディングエージェントは基本的に「ステートレス」でした。1回のセッションの中では文脈を保持しますが、セッションを閉じれば記憶はリセットされます。CLAUDE.md や AGENTS.md のようなファイルに指示を書いておくことはできても、それは「エージェントが自分で覚えた記憶」ではなく「人間が毎回読ませる資料」です。
Letta Codeのエージェントは違います。記憶はサーバー側に永続化され、エージェントは自分の判断で記憶を書き換えます。次にセッションを開いたとき、エージェントは「あなたが誰で、何をしていて、前回どこでつまずいたか」を覚えている——それが「アイデンティティと経験の感覚」の意味です。
「人に近い」を支える4つの性質
Letta Codeが目指すエージェント像は、次の4つの性質で整理できます。
・記憶（Memory）：会話やセッションをまたいで情報を覚え続ける
・アイデンティティ（Identity）：自分が誰で、どんな役割かを保持する
・経験からの学習：使われるほど文脈が蓄積し、応答が的確になる
・自己改善：記憶だけでなく、スキルやプロンプト、ハーネス自体（mods）まで自分で書き換える
とくに4つ目の「自己改善」がLetta Codeの野心を象徴しています。エージェントは、繰り返し使う手順を「スキル」として保存し、振る舞いのルールを「メモリブロック」に書き込み、必要なら動作環境そのものを拡張する。公式ドキュメントには「Letta Codeのエージェントは自己設定型に設計されている。何かを設定したくなったら、エージェントに頼めばやってくれる」とすら書かれています。
誰が作っているのか——MemGPTの系譜
Letta Codeを理解するうえで、開発元の背景は外せません。作っているのはLetta社で、その中心にいるのはMemGPT（論文『MemGPT: Towards LLMs as Operating Systems』, arXiv 2310.08560）の著者らです。MemGPTは、LLMを「OSのように限られたメモリ（コンテキスト）を階層的に管理する存在」として捉え、長期記憶と短期記憶を出し入れする仕組みを提案した研究でした。
Letta Codeは、そのMemGPTのアイデアを「コーディングエージェント」という実用の器に落とし込んだもの、と位置づけられます。後述する「ドリーミング（/sleeptime）」も、同チームが研究する「sleep-time compute（arXiv 2504.13171）」——推論の合間ではなく待機時間に計算を先回りさせる手法——の応用です。論文で提唱した記憶とメモリ管理の理論を、そのまま動くOSSにしている点が、Letta Codeの信頼性の source になっています。
エージェントの記憶を扱うOSSは他にもあります。記憶レイヤーそのものを比較したい場合は、AgentMemory解説——AIエージェントに長期記憶を与えるOSS や EverOS解説——エージェントの記憶をOS化する も参考になります。Letta Codeはそれらの「記憶ライブラリ」ではなく、記憶を核に据えた「エージェントを動かすCLIそのもの」である点が異なります。
2. なぜ今か——Claude Code / Codex CLIとの決定的な違い
2025年から2026年にかけて、Claude Code・Codex CLI・OpenCode・Cursorといったコーディングエージェントは一気に普及しました。では、なぜ今さら「もう一つのCLI」であるLetta Codeに注目する価値があるのでしょうか。答えは、Letta Codeが解こうとしている問題が、他のCLIとは違うからです。
既存のCLIが磨いてきたのは「1回のタスクをどれだけ上手くこなすか」でした。優れたツール呼び出し、正確なコード編集、高速な補完——これらは「セッション内の性能」です。一方、Letta Codeが挑むのは「セッションをまたいだ連続性」という別軸の課題です。
ステートレス vs ステートフル
両者の違いを、具体的な場面で並べてみましょう。
＜従来のステートレスなCLI＞ 月曜日に「このリポジトリはbunを使う。テストは
bun test --coverageで」と教える。金曜日に別セッションを開くと、エージェントはそれを忘れている。再びCLAUDE.mdを読ませるか、口頭で説明し直す必要がある。
＜Letta Code（ステートフル）＞ 月曜日に同じことを教えると、エージェントは「これはプロジェクトの記憶に入れておくべきだ」と判断し、自分のメモリブロックに書き込む。金曜日に
resumeで再開すると、エージェントはbunの規約を覚えたままタスクに入れる。
この違いは、実際のデモ画面にも表れています。Letta CodeのCLIは起動時に「Resumed agent」と表示し、https://app.letta.com/agents/agent-... という永続エージェントのURLを示します。エージェントはセッションではなく「アカウントに紐づく永続的な実体」であり、CLIはそこへ接続する窓口にすぎません。
上の画面は、実際にエージェントが「I need to store the CLAUDE details in the project memory（CLAUDEの詳細をプロジェクト記憶に保存する必要がある）」と考え、自分の記憶を更新しようとしている瞬間です。これはLetta Codeの本質を端的に示しています。記憶の管理が、人間の手作業ではなくエージェント自身の行動として組み込まれているのです。
比較表：4つのコーディングエージェントCLI
主要なCLIとLetta Codeを、記憶と連続性の観点で整理すると次のようになります。
| 観点 | Claude Code | Codex CLI | OpenCode | Letta Code |
|---|---|---|---|---|
| エージェントの実体 | セッション単位 | セッション単位 | セッション単位 | 永続（サーバー側に常駐） |
| 記憶の永続性 | ファイル（CLAUDE.md）中心 | ファイル中心 | ファイル中心 | メモリブロック＋MemFSで自動永続 |
| 自己改善 | 限定的（人間が設定） | 限定的 | 限定的 | エージェントが記憶・スキル・ハーネスを書き換え |
| 常時稼働 | 基本は対話起動 | 基本は対話起動 | 基本は対話起動 | crons/heartbeatで proactive に稼働可 |
| 対応サーフェス | CLI / IDE | CLI | CLI / IDE | CLI・デスクトップ・ブラウザ・Slack/Telegram等 |
| モデル | Claude中心 | OpenAI中心 | マルチ | マルチ（OpenAI/Anthropic/Z.ai等をBYOK） |
| ライセンス | プロプライエタリ | プロプライエタリ | オープンソース | Apache-2.0（OSS） |
※ Claude Code / Codex CLIの仕様は各社の2026年時点の一般的な挙動に基づく整理で、細部は更新されうる。
注意したいのは、これは「どれが優れているか」の表ではないことです。単発のコード生成や、その場限りの修正なら、Claude CodeやCodex CLIの完成度は高く、Letta Codeを持ち出す必要はありません。Letta Codeが効くのは「同じエージェントに長く付き合わせ、文脈と好みを蓄積させたい」場面です。そして重要なのは、Letta Codeがモデル非依存である点——/connectでAnthropicのキーを挿せば、Claudeを頭脳に使いながら、Letta Codeの記憶機構を載せるという組み合わせも成立します。
3. Letta Codeのインストールと最初のセッション
Letta Codeの導入は、他のCLIと同じくnpm一発です。Node.js/npmが入っていれば、グローバルインストールしてすぐ使えます。
# グローバルインストール（npm）
npm install -g @letta-ai/letta-code
# プロジェクトディレクトリに移動して起動
cd ~/your-project
letta
# まず触ってみたい人はチュートリアル用エージェントで
letta --new-agent --personality tutorial
起動したら、最初にやるのはモデルの接続です。Letta Codeは頭脳となるLLMを外から挿す設計なので、自分のAPIキーやログインを/connectで設定します。
# CLI内のスラッシュコマンド
/connect # OpenAI(ChatGPT) / Anthropic / Z.ai coding plan などのキーを設定
/model # 使うモデルを切り替える
/palace # エージェントの記憶を可視化して確認する
/doctor # 記憶の品質を監査する
/search # すべてのメッセージ・エージェントを横断検索
/connectではOpenAI（ChatGPT）、Anthropic、Z.aiのコーディングプランなど、複数プロバイダーのキーを設定できます。つまりLetta Codeは「特定のモデルベンダーに縛られないハーネス」であり、手元のClaudeやGPTをそのまま頭脳として使えます。
CLI以外の入り口
Letta Codeの面白さは、同じエージェントに複数の窓口から触れる点にあります。CLIで育てたエージェントは、次の入り口からも同じ記憶のまま呼び出せます。
・デスクトップアプリ（macOS / Windows / Linux）——CLIで作ったエージェントがそのまま使える
・ブラウザ（chat.letta.com、モバイル対応）——外出先からスマホで同じエージェントに指示
・メッセージ連携——Slack・Telegram・Discord、さらに独自チャネルからも会話
この「マルチサーフェス」は、エージェントがサーバー側に永続化されているからこそ実現できます。CLIはあくまで窓口の一つ。エージェント本体はどこか一つのアプリに閉じ込められていません。
macOS以外の導入手段も用意されています。Arch Linuxユーザー向けにはAURパッケージ、Nixユーザー向けにはFlakeが提供されています。
# Arch Linux（AUR / コミュニティ管理）
yay -S letta-code # リリース版
yay -S letta-code-git # nightly
# Nix（リポジトリのflakeから）
nix run github:letta-ai/letta-code
nix profile install github:letta-ai/letta-code
4. 記憶の仕組み——メモリブロック・MemFS・ドリーミング
Letta Codeの心臓部が、この記憶の仕組みです。「ステートフル」を実際に支えているのは、役割の異なる複数の記憶レイヤーと、それらを更新するループでした。ここを理解すると、Letta Codeが「なぜ覚えていられるのか」が腑に落ちます。
なぜ記憶を「1つの箱」ではなく複数の層に分けるのか。理由は、記憶の性質がそれぞれ違うからです。「常に見ておきたい短い前提」と、「必要なときに引き出す長い履歴」を同じ場所に置くと、コンテキストがすぐ溢れます。これはMemGPTが提起した「LLMは限られたメモリを階層的に管理すべき」という発想そのもので、Letta Codeはそれを、常駐（メモリブロック）・保管（MemFS）・手順（スキル）・履歴（メッセージ検索）という役割ごとの層に分けて実装しています。人間で言えば、机の上に置くメモ、本棚のファイル、体で覚えた手順、日記——を使い分けるのに近い構造です。
メモリブロック——常駐する編集可能な記憶
メモリブロックは、システムプロンプトの中に常駐する、短くて編集可能な記憶の単位です。「このユーザーはbunを使う」「敬語より簡潔な回答を好む」「このプロジェクトのテストはbun test --coverage」——といった、常に参照しておきたい情報を保持します。
重要なのは、これがエージェントによってプログラム的に書き換えられることです。公式ドキュメントはこれを「システムプロンプト学習（system prompt learning）」と呼びます。人間がプロンプトを手直しするのではなく、エージェントが会話の中で得た学びを、自分のシステムプロンプト（メモリブロック）に反映していくのです。
MemFS——記憶をファイルとしてgit管理する
MemFSは、メモリブロックを含むすべてのコンテキストを「ファイル」として扱い、gitでバージョン管理する仕組みです。これにより、記憶の変更履歴が追跡でき、「いつ・何を覚えたか／忘れたか」を後から確認できます。
さらに、記憶を任意のGitHubリポジトリに同期することもできます。
# 記憶を自分のGitHubリポジトリに同期する
/memory-repository set [email protected]:you/your-agent-memory.git
これは強力な発想です。エージェントの記憶が「ブラックボックスのDB」ではなく「gitで追跡できるファイル群」になることで、記憶の中身をレビューし、差分を見て、必要なら巻き戻せる。記憶がエンジニアにとって扱い慣れた「コード」と同じ土俵に乗るわけです。
スキル——手順を再利用可能な形で保存する
繰り返し使う手順やノウハウは、スキルとして保存されます。スキルは3つのスコープを持ちます。
・グローバルスキル（~/.letta）——どのプロジェクトでも使える
・プロジェクトスコープ（.agents/skills）——そのリポジトリ限定
・エージェントスコープ（MemFS内に保存）——特定のエージェント固有
/skillsで一覧を見て、/skill-creatorで新しいスキルを作れます。外部のスキルをインストールすることも可能です。
# GitHubやスキルハブから、特定エージェントのメモリにスキルを導入
letta skills install https://github.com/owner/repo
letta skills list --agent <agent-id>
letta skills delete <skill-name> --agent <agent-id>
ドリーミング——待機時間に記憶を整理する
そして、記憶レイヤーを「育てる」のがドリーミングです。/sleeptimeで有効化すると、エージェントは待機している時間を使って自分の記憶を整理・要約・再構成します。人間が睡眠中に記憶を定着させるのになぞらえた命名で、技術的にはLetta社の「sleep-time compute」研究に基づきます。
Claude系エージェントにおける類似の「記憶とドリーミング」の考え方は、Claudeの管理エージェントとメモリ・ドリーミング解説 でも扱っています。Letta Codeはこの発想を、モデル非依存のOSSとして実装した点に特徴があります。
記憶が更新されるループ
これらの記憶レイヤーは、次のようなループの中で更新されていきます。エージェントはタスクを実行し、結果を内省し、覚えるべきと判断した情報を記憶に書き込み、次のセッションでそれを再利用します。
ツール呼び出し"] A --> R["結果を観察して内省"] R --> D{"覚えておくべき
情報か"} D -->|"はい"| M["メモリブロックを書き換え
スキルとして保存"] D -->|"いいえ"| N["そのまま次の行動へ"] M --> P["サーバー側に永続化
MemFSでgit管理"] N --> A P --> S["次セッションで
resumeして再利用"] S --> U
このループが回り続けることで、エージェントは「使うほど賢くなる」わけです。/palaceで記憶を可視化し、/doctorで記憶の品質を監査できるため、成長の過程を人間が覗いて手を入れることもできます。
5. 自己拡張とマルチ環境——スキル・Mods・Constellation
記憶の次にLetta Codeが持つ武器が、「ハーネス自体を拡張できる」という点です。エージェントは記憶を書き換えるだけでなく、自分が動く環境そのものを広げていけます。
サブエージェントとマルチエージェント
Letta Codeには、組み込みのサブエージェントがあります。general-purpose（汎用）、forked（分岐）、recall（想起）、history-analyzer（履歴分析）などで、同期・非同期のどちらでも呼び出せます。さらに、エージェントは他の任意のエージェント（自分自身を含む）をサブエージェントとして呼び出せます。「自分を呼ぶ」という再帰的な構造は、複雑なタスクを分割統治するのに効きます。
エージェントを複数協調させる設計パターン全般に興味があれば、12 Factor Agents解説——壊れないAIエージェントの12原則 も併せて読むと、Letta Codeの選択の背景が見えてきます。
Mods——ハーネスをコードで拡張する
Modsは、Letta Codeのハーネスそのものを拡張する仕組みです。~/.letta/mods/にモジュールを置いて/reloadすれば、ツールの追加やターン開始時のリマインダー挿入など、エージェントの動作をコードで拡張できます。
公式が例示しているのがmemory-citations.tsという mod で、ChatGPTのような「記憶の引用（この回答はどの記憶に基づくか）」をエージェントに付けさせる試作です。さらに面白いのが、mod自体をエージェントに作らせる「mod学習」機能です。
# CLI内で、指定ターゲット用のmodをエージェントに生成・評価させる
/mods learn memory-citations
これは「エージェントが自分の動作環境を、自分で改造する」という、Letta Codeの自己改善思想を最も先鋭化させた機能です。生成されたmodは自動では導入されず、人間がレビューしてから採用する安全設計になっています。
権限モードとツール
エージェントにコードを触らせる以上、権限管理は欠かせません。デモ画面では、ツール呼び出しが Shell(command="pwd && ls -la", workdir="/", timeout_ms=100000, with_escalated_permissions=false, justification="") のように、権限昇格の有無と理由まで構造化されて表示されていました。
権限モードはshift+tabで循環でき、慎重に確認しながら進めるモードから、すべてを自動承認する「yolo（allow all）モード」まで選べます。Hooks（実行の要所でカスタムスクリプトを走らせる）やPermissions（自動承認・自動拒否のカスタマイズ）と組み合わせれば、チームの運用ポリシーに沿ったガードレールを敷けます。
Constellation——エージェントをどのマシンからも
Constellationは、Letta社がホストするプラットフォームで、エージェントを「どのマシンからでも」使えるようにします。ラップトップ、クラウドVM、Mac Mini、サンドボックス、GitHub Actions——同じエージェントにどこからでも接続できます。
# 任意のマシンを、エージェントが動ける環境として公開する
letta server --env-name "work-laptop"
# 接続可能な環境を一覧
letta environments list --online-only
# 特定環境を経由してヘッドレスにメッセージを送る
letta -p --agent <agent-id> --environment "work-laptop" "hello from that machine"
/loginでConstellationにログインすると、この「マルチ環境」に加えて、Secrets（値を隠したまま環境変数として使わせる）機能も使えます。ローカルで試すだけならログイン不要ですが、複数マシンをまたぐ常時稼働エージェントを組むなら、Constellationが前提になります。
6. 詰まりやすいポイントと導入の判断
ここまで見てきたLetta Codeは魅力的ですが、導入前に知っておくと良い「詰まりどころ」と「向き・不向き」があります。誇張なく整理します。
- ・research preview段階のため、コマンド名や仕様は今後変わりうる。バージョン間の差分に注意。
- ・記憶が自動で蓄積される反面、「余計なことを覚える」こともある。
/doctorや/palaceで定期的に記憶を点検する運用が要る。 - ・Constellation連携（マルチ環境・Secrets）はLetta社ホストへのログインが前提。完全ローカル・オフライン運用とは設計思想が異なる。
- ・自分のLLM APIキーを使うため、モデル利用料は別途かかる。CLI自体はOSSでも、頭脳のコストは自己負担。
よくあるつまずき
・モデルが繋がらない：起動しただけでは頭脳が無い。まず/connectでOpenAI/Anthropic/Z.aiなどのキーを設定し、/modelでモデルを選ぶ
・記憶が思ったより増えない／増えすぎる：記憶はエージェントの判断で書かれる。/palaceで中身を確認し、方針をメモリブロックで指示すると制御しやすい
・別マシンからエージェントが見えない：マルチ環境はConstellationログインとletta serverの起動が前提。letta environments list --online-onlyで疎通を確認
・modが読み込まれない：~/.letta/mods/に置いたら/reloadが必要。開発時はLETTA_MODS_DIRで読み込み先を差し替えられる
Letta Codeが向く人・向かない人
- ・同じプロジェクトに長く付き合い、エージェントに文脈と好みを覚えさせたい。
- ・CLIだけでなく、スマホやSlackからも同じエージェントに触れたい。
- ・記憶をgitで追跡・レビューできる形で持ちたい（ブラックボックスを避けたい）。
- ・cronやheartbeatで、自律的に動き続けるエージェントを組みたい。
逆に、「その場限りのコード生成を高速に済ませたい」「完全ローカル・オフラインで完結させたい」「新しいツールの学習コストを払いたくない」という場合は、Claude CodeやCodex CLIなど成熟したCLIのほうが素直です。Letta Codeは、記憶と連続性に価値を感じる人にとって刺さるツールであり、万人向けの置き換えを狙ったものではありません。
7. まとめ——Letta Codeが変えるエージェントとの付き合い方
Letta Codeは、AIコーディングエージェントの評価軸を「1回のタスクの上手さ」から「時間を通じた成長」へとずらそうとするOSSです。記憶をメモリブロック・MemFS・スキルの多層で管理し、エージェント自身がそれを読み書きし、ドリーミングで整理し、必要ならハーネス（mods）まで自分で拡張する。MemGPTの研究を、そのまま動く道具にした系譜がここにあります。
- ・Letta Codeは「記憶を持ち、使うほど成長するステートフルなエージェント」を動かすApache-2.0のCLIハーネス。
- ・記憶はサーバー側に永続化され、CLI・デスクトップ・ブラウザ・Slack/Telegramなど複数の窓口から同じエージェントに触れられる。
- ・Claude Code / Codex CLIの置き換えではなく、「連続性と記憶」という別軸を足す選択肢。モデルはBYOKで、Claudeを頭脳に使うこともできる。
- ・research preview段階ゆえ変化は速い。まずは
npm install -g @letta-ai/letta-codeで触り、/palaceで記憶の育ち方を観察するのがおすすめ。
「エージェントにプロンプトを打つ」時代から、「エージェントを育てる」時代へ。Letta Codeが示すのは、その具体的な一つの形です。まずは手元のプロジェクトでチュートリアルエージェントを起動し、あなたの文脈を覚えていく感覚を確かめてみてください。エージェントとの付き合い方が、少し変わって見えるはずです。
参照ソース
・letta-ai/letta-code（公式GitHubリポジトリ） — README・機能一覧・インストール手順の一次ソース
・Letta Code ドキュメント（CLI） — スラッシュコマンド・メモリ・チャネル・Constellationの公式解説
・MemGPT: Towards LLMs as Operating Systems（arXiv 2310.08560） — 記憶とメモリ管理の理論的背景
・Sleep-time Compute（arXiv 2504.13171） — ドリーミング（/sleeptime）の元になった研究
