ChatGPTやClaudeと長く付き合っていると、誰もが一度はこう感じます——「さっき話したことを、なぜ覚えていないのか」。大規模言語モデル（LLM）は驚くほど賢い一方で、本質的に記憶を持たない（ステートレス）存在です。セッションが切れれば、あなたの好みも、これまでの作業の経緯も、すべて忘れてしまう。エージェントに長期的なタスクを任せようとするとき、この「健忘症」こそが最大の壁になります。

この壁を正面から壊そうとするのが、本記事で解説する EverOS（エバーオーエス） です。EverMind-AIが開発し、GitHubで9,000スター超を集めるこのオープンソースは、自らを「AIエージェントのための記憶オペレーティングシステム」と位置づけます。ステートレスなLLMに永続的な記憶を与え、「本当に覚えていられる」エージェントへと変える——それがEverOSの狙いです。

EverOSが他の記憶ライブラリと一線を画すのは、その設計思想にあります。記憶を専用データベースやクラウドの闇に閉じ込めるのではなく、人間が読めるMarkdownファイルを「正（source of truth）」として保存する。しかもローカルファーストで、ユーザー自身がデータを所有し、セッションをまたいで記憶が自己進化していく。AIエージェント開発の足元を支える、この新しい記憶基盤の全体像を、公式情報をもとに読み解いていきます。

ステートレスなLLM → 記憶を持つエージェントへ LLM 単体 賢いが忘れる セッションで消える 文脈が続かない ＋ EverOS（記憶OS） Markdownで永続化 ローカル検索 自己進化 → 覚える エージェント 好み・経緯 スキルを保持
EverOSは、忘れるLLMに「記憶レイヤー」を差し込み、文脈を保持するエージェントへと変える（出典: EverMind-AI/EverOS の趣旨をもとに作図）

1. EverOSとは — 「持ち運べる記憶レイヤー」

EverOSは、Pythonで書かれたライブラリであり、AIエージェントと「作り手（makers）」のためのローカルファーストな記憶ランタイムです。Apache-2.0ライセンスのオープンソースで、公式の説明では「コーディングアシスタント、アプリ、デバイス、ワークフローをまたぐ、ひとつの持ち運べる記憶レイヤー」と表現されています。

ここで言う「持ち運べる（portable）」が、EverOSの核心です。多くの記憶ソリューションは、特定のサービスやデータベースに記憶を囲い込みます。すると、ツールを乗り換えた瞬間に記憶は失われ、ベンダーにロックインされてしまう。EverOSはこれを拒否し、会話・ファイル・エージェントの軌跡を、すべて「読めるMarkdown」として保存します。そのMarkdownを正としたうえで、ローカルのSQLiteとLanceDBのインデックスを同期させ、高速な検索と再利用を実現するのです。

この設計がもたらす利点を、公式は対抗馬（一般的なエージェント記憶ライブラリ）との比較で明快に示しています。

観点 EverOS 一般的な記憶ライブラリ
記憶の正（source of truth） 読めて・編集でき・差分が取れ・Git管理できる .md ファイル API・ベクトル・グラフ・DBの状態
直接編集 .md を直接編集→ウォッチャーが同期 SDK・API・ダッシュボード経由
ストレージ構成 Markdown＋SQLite＋LanceDB（外部サービス不要） マネージドサービス・各種DBに依存
ユーザー／エージェントの分離 episodes/profile（ユーザー）と cases/skills（エージェント）を別建て チャット履歴中心
検索の軸 user_id・agent_id・app_id・project_id・session_id で直交検索 アプリ・スレッド・グラフ単位に限定
自己進化（Reflection） セッション間でepisodeを統合しprofile/skillを精製 検索のみで背景的な統合が乏しい

この表が物語るのは、EverOSが「記憶をブラックボックスにしない」という一貫した哲学です。あなたの記憶は、いつでも開いて読め、テキストエディタで直接書き換えられ、Gitでバージョン管理できる。AI時代におけるデータ主権を、設計レベルで保証しているのです。

「local-first（ローカルファースト）」という言葉も、EverOSを理解する鍵です。これは、データがまず手元のマシンに存在し、クラウドはあくまで補助的、という思想を指します。近年、メモや知識管理ツールの世界で広がってきたこの考え方を、EverOSはAIエージェントの記憶に持ち込みました。記憶という最もプライベートな情報を、他人のサーバーに預けっぱなしにするのではなく、自分の管理下に置く。プライバシーが重視される時代において、この設計選択は単なる技術的な好みを超えた、価値観の表明でもあります。エージェントが賢くなるほど、それが何を記憶しているかは重大な関心事になります。EverOSは、その記憶を「ユーザーのもの」として位置づけることで、AIとの長期的な信頼関係の土台を作ろうとしているのです。

2. なぜ「Markdownが正」なのか

EverOSの最も独創的な決断は、記憶の保存形式にMarkdownを選んだことです。ベクトルデータベースやグラフデータベースが主流の記憶ライブラリ界において、これはやや意外な選択に映るかもしれません。しかし、ここには深い合理性があります。

第一に、人間が読めることです。ベクトル（数値の羅列）として保存された記憶は、人間には解読できません。何が記憶されているのか、なぜそう検索されたのかが、ブラックボックスになります。Markdownなら、~/.everos フォルダを開くだけで、エージェントが何を覚えているかを自分の目で確認できます。

第二に、編集・差分・バージョン管理ができることです。.md ファイルなので、テキストエディタで直接書き換えられます。間違った記憶を修正したり、不要な記憶を消したりが、自由自在です。しかもGitで管理すれば、記憶の変遷を差分（diff）で追え、いつでも巻き戻せます。EverOSには「カスケードウォッチャー」があり、ファイルを直接編集すると、その変更が自動でインデックスに同期されます。

第三に、ロックインがないことです。すべての記憶はクリーンなMarkdownとしてエクスポートできるため、EverOSをやめても記憶は手元に残ります。特定のサービスに人質に取られることがありません。

ポイント：記憶を「ファイル」に戻す

EverOSの思想は、複雑なデータベースに囲い込まれた記憶を、もう一度「人間が触れるファイル」へと引き戻すことにあります。読めて、直せて、Gitに乗る——エンジニアが日々扱う .md と同じ土俵に記憶を置くことで、透明性とユーザー所有権を同時に達成しています。ベクトルDBの速さは、その上に重ねるSQLite＋LanceDBで別途確保する、という二段構えが巧みです。

3. 3層ストレージとメモリ・ライフサイクル

EverOSのストレージは、外部サービスを一切必要としない、軽量な3層構成です。MongoDBもElasticsearchもRedisも要りません。

・Markdown：記憶の正本。すべての記憶はまずここに書かれる
・SQLite：構造化されたメタデータと関係性の高速な索引
・LanceDB：埋め込みベクトルによる意味検索（セマンティック検索）のための索引

記憶を追加すると、まずMarkdownに同期的に書き込まれ、その後でローカルのインデックス（SQLite／LanceDB）がバックグラウンドで追いつきます。この「Markdown優先、索引は後追い」という設計が、データの確実性と検索速度を両立させています。

では、ひとつの記憶はどのように生まれ、検索されるのでしょうか。EverOSのコアループ（add → flush → search）を図で示します。

flowchart TD A["会話・ファイルを投入
/memory/add"] --> B["抽出 (flush)
記憶を取り出しタグ付け"] B --> C["分類
Profile / Episodic / Skill"] C --> D["Markdownに書き込み
~/.everos（正本）"] D --> E["索引を同期
SQLite + LanceDB"] E --> F["検索
/memory/search"] F --> G["ハイブリッド検索で想起
+ 出典のMarkdownを提示"] D -.オフラインで.-> H["Reflection
episode統合・profile精製"] H -.-> D

この3層は、それぞれが得意な仕事を分担します。Markdownは「永続性と可読性」、SQLiteは「構造化された絞り込み」、LanceDBは「意味的な近さの検索」。一つのデータベースにすべてを担わせるのではなく、適材適所で軽量なコンポーネントを組み合わせることで、外部サービス不要のシンプルさと、実用的な検索性能を両立させているのです。

利用者はまず会話やファイルを /api/v1/memory/add で投入します。次に /api/v1/memory/flush で「抽出（extraction）」が走り、会話の中から記憶すべき事実が取り出され、タグ付けされます。抽出された記憶はMarkdownに書き込まれ、索引が同期され、/api/v1/memory/search で意味検索によって想起できるようになります。検索結果には、その記憶の出典となったMarkdownが添えられるため、「なぜそう答えたのか」の根拠まで辿れます。

そして図の下部にある Reflection（リフレクション） こそ、EverOSを「自己進化する記憶」たらしめる仕掛けです。これはセッションの合間にオフラインで動く処理で、似たエピソードのクラスタを統合し、ユーザーのプロフィールやエージェントのスキルを精製します。多くの記憶ライブラリが「保存して検索するだけ」で止まるのに対し、EverOSは記憶を時間をかけて洗練させていくのです。

この「オフラインで記憶を整理する」という発想は、人間の睡眠中の記憶定着に似ています。私たちは日中に経験した断片的な出来事を、眠っている間に整理・統合し、長期記憶へと定着させます。EverOSのReflectionも同様に、セッションという「覚醒中」に投入された雑多なエピソードを、「睡眠中」にあたるオフライン処理で束ね、重複を取り除き、本質的なプロフィールやスキルへと昇華させます。記憶はただ増えていくのではなく、整理され、密度を増していく。この長期的な改善のメカニズムがあるからこそ、EverOSを使い込むほどエージェントは賢く、的確になっていくのです。

4. 記憶の分類 — Profile・Episodic・Skill

EverOSは、記憶をただ貯め込むのではなく、3つの種類に自動分類します。手動でのキュレーションは不要で、投入された情報をEverOSが自動で見極めてタグ付けします。

・Profile（プロフィール）：ユーザーの恒常的な属性や好み（「ヨセミテで春に登山するのが好き」「行きつけのカフェはSOMAのBlue Bottle」など）
・Episodic（エピソード）：特定の出来事やセッションの記録。いつ・何があったかの時系列的な記憶
・Skill（スキル）：エージェントが習得した、再利用可能な手順やノウハウ

さらにEverOSは、ユーザー側の記憶（episodes/profile）とエージェント側の記憶（cases/skills）を、別建ての一級市民として扱います。これは重要な設計判断です。「ユーザーが何者か」という記憶と、「エージェントが何をできるようになったか」という記憶は、性質がまったく異なるからです。

特に興味深いのが、Case（ケース）からSkill（スキル）への自己昇格という仕組みです。エージェントがタスクを完了するたびに、その記録が「Case」として残ります。そして、同じような成功が繰り返されると、そのパターンは「Skill」へと昇格し、エージェントチーム全体で共有される再利用可能なスキルになります。一度うまくいったやり方が、組織の資産として蓄積されていく——これは、人間のチームが経験から学び、ベストプラクティスを共有していく過程とよく似ています。

直交する検索軸

EverOSは記憶を user_id / agent_id / app_id / project_id / session_id という独立した軸で検索できます。「このユーザーの、このプロジェクトに関する記憶だけ」といった絞り込みが自在で、複数アプリ・複数エージェントが同じ記憶基盤を共有しても混線しません。マルチテナントな実運用を見据えた設計です。

5. ハイブリッド検索とマルチモーダル対応

記憶は、保存できても的確に想起できなければ意味がありません。EverOSは、想起の質を高めるために、複数の検索手法を組み合わせたハイブリッド検索（mRAG）を採用しています。

LanceDBによるベクトル検索（意味の近さで探す）と、SQLiteによる構造化検索（属性で絞り込む）を組み合わせ、さらにリランク（再順位付け）を経て、最も関連性の高い記憶を返します。EverOSの設定では、埋め込み（Embedding）とリランクにDeepInfra、チャットとマルチモーダル処理にOpenRouterを使う構成が標準ですが、これらはOpenAIプロトコル互換のため、OpenAI・vLLM・Ollama・DeepInfraなど、好きなプロバイダに差し替えられます。ローカルのOllamaを指せば、完全にローカル完結の記憶システムも構築できます。

さらにEverOSは、テキストだけでなくマルチモーダルな記憶にも対応します。オプションのインストールにより、画像・PDF・音声・Officeドキュメント（Word・PowerPoint・Excel）を /memory/add に投入できます。Officeファイルは、LibreOfficeのヘッドレス機能を使ってPDFに変換したうえで、マルチモーダルLLMに渡して解析されます。標準ではGoogleのGemini系モデルが使われますが、これも差し替え可能です。

検索・処理 担当 役割
意味検索 LanceDB 埋め込みベクトルで「意味が近い」記憶を探す
構造化検索 SQLite user_id等の属性で正確に絞り込む
再順位付け リランクモデル 候補を関連度順に並べ直す
マルチモーダル抽出 マルチモーダルLLM 画像・PDF・音声・Officeから記憶を抽出

このように、EverOSは「保存形式はシンプルなMarkdown、しかし想起の仕組みは高度なハイブリッド検索」という、ローテクとハイテクの巧みな組み合わせで成り立っています。

6. エコシステムと、どんな場面で活きるか

EverOSは単体のライブラリにとどまらず、その周りにエコシステムが育ちつつあります。公式リポジトリのユースケース集には、EverOSを記憶基盤として使った多彩なプロジェクトが並びます。

・AIコーディングアシスタントの長期記憶：Claude Code・Codex・OpenClaw・Hermes・MCP対応のエージェントに、横断的な長期記憶を与える
・Hive Orchestrator：複数のCLIコーディングエージェントが協調するハイブマインド
・ブラウザエージェントの個人記憶：Web操作をまたいで個人の文脈を持ち運ぶ
・スマートグラス連携：Rokidグラス上で日常活動の長期記憶を実現（近日公開）
・記憶を持つ創作アシスタント：セッションをまたいで創作の文脈を保持

特に重要なのは、EverOSが Claude Code・Codex・OpenClaw・Hermes・MCP といった主要なエージェント環境と互換性を持つ点です。エージェントは「動き方を変えることなく」永続記憶を獲得できます。MCP（Model Context Protocol）経由で接続できることは、当サイトでも繰り返し取り上げてきたエージェント連携の潮流とも合致しており、EverOSが孤立したツールではなく、エコシステムの一部として設計されていることを示しています。

では、EverOSは具体的にどんな人に向くのでしょうか。

第一に、長期記憶を持つAIエージェントを開発したいエンジニアです。記憶基盤を自前で作るのは大変ですが、EverOSを使えば、pip install everos から始めて、すぐに永続記憶を組み込めます。APIキーなしで動く everos demo という教育用のビジュアライザも用意されており、記憶が生まれ・索引され・想起される一連のライフサイクルを、ターミナル上のアニメーションで直感的に理解できます。本格導入の前に、まずこのデモで世界観を掴めるのは、学習コストを下げる嬉しい配慮です。

第二に、データ主権を重視する開発者・組織です。記憶をクラウドの闇に預けたくない、自分のサーバー内で完結させたい、という要件に、ローカルファーストとMarkdownエクスポートが応えます。

第三に、記憶の中身を検証・監査したい人です。Markdownが正なので、エージェントが「何を、なぜ覚えているか」を人間が直接確認・修正できます。AIの判断根拠の透明性が求められる場面で、大きな価値を持ちます。誤った記憶や古くなった情報を、ファイルを開いて手で直せるという安心感は、ブラックボックスな記憶では決して得られないものです。

もちろん、EverOSも万能ではありません。記憶の抽出や埋め込み生成にはLLMプロバイダを使うため、その品質や設定に出力が左右されますし、Markdownを正とする以上、極端に大量・高頻度な書き込みが続く用途では、専用のベクトルDBに特化したソリューションのほうが速い場面もあるでしょう。とはいえ、「透明で、ユーザーが所有でき、自己進化する記憶」という価値を重視するなら、EverOSの設計は非常に魅力的な選択肢です。自分の用途が「記憶の透明性・所有権」を重んじるのか、「純粋な検索スループット」を重んじるのかを見極めたうえで採用を判断するとよいでしょう。

まとめ：忘れるAIに、読める記憶を

EverOSは、ステートレスなLLMに永続的な記憶を与える、ローカルファーストの記憶オペレーティングシステムです。記憶をベクトルDBの闇に閉じ込めるのではなく、人間が読み・編集し・Git管理できるMarkdownを「正」とする——この一点に、データ主権と透明性への強いこだわりが表れています。Profile/Episodic/Skillの自動分類、CaseからSkillへの自己進化、ハイブリッド検索、マルチモーダル対応まで備え、Claude CodeやMCPとも繋がる。エージェント時代の「記憶」を考えるうえで、避けて通れないプロジェクトです。

まとめ

本記事では、AIエージェントに永続記憶を与えるMarkdownネイティブの記憶ランタイム EverOS を解説しました。

EverOSの本質は、「記憶をブラックボックスにしない」という思想にあります。会話・ファイル・エージェントの軌跡を、人間が読めるMarkdownとして保存し、それを正としたうえで、ローカルのSQLite＋LanceDBで高速なハイブリッド検索を実現する。外部サービスに依存せず、ユーザーがデータを所有し、Markdownとしていつでもエクスポートできる——この設計が、データ主権と透明性を担保します。

さらに、Profile/Episodic/Skillへの自動分類、CaseからSkillへの自己昇格、セッション間のReflectionによる記憶の精製といった仕組みが、EverOSを単なる「保存庫」ではなく「自己進化する記憶」へと押し上げています。Claude Code・Codex・MCPとの互換性により、既存のエージェントに記憶を後付けできる実用性も備えます。

LLMは賢い。しかし、賢いだけでは長期的なパートナーにはなれません。「覚えていること」が、信頼の土台だからです。EverOSは、その土台をオープンソースで、ユーザーの手の届く形で提供しようとしています。エージェントに記憶を持たせたいと考えるなら、まずは everos demo で、記憶が生まれ・想起される様子を眺めてみてください。

よくある質問（FAQ）

Q1. EverOSは何をするツールですか? ステートレスなLLMに永続的な記憶を与える、AIエージェント向けの記憶ランタイム（記憶OS）です。会話やファイルを読めるMarkdownとして保存し、ローカルのSQLite＋LanceDBで高速に検索・再利用できるようにします。

Q2. なぜ記憶をMarkdownで保存するのですか? 人間が読め、テキストエディタで直接編集でき、Gitで差分管理でき、いつでもエクスポートできるからです。ベクトルDBのようなブラックボックスを避け、データ主権と透明性を確保するための設計です。検索速度は、上に重ねるSQLite＋LanceDBの索引で別途担保します。

Q3. クラウドサービスは必要ですか? 記憶のストレージ自体はローカル完結で、MongoDBやElasticsearch、Redisは不要です。ただし、記憶の抽出や埋め込み生成にはLLM・埋め込みプロバイダ（OpenRouterやDeepInfraなど）を使います。これらはOpenAIプロトコル互換なので、ローカルのOllama等に差し替えれば、完全ローカル構成も可能です。

Q4. どんなエージェントと連携できますか? Claude Code、Codex、OpenClaw、Hermes、そしてMCP（Model Context Protocol）対応のエージェントと互換性があります。エージェントは動作を変えることなく、永続記憶を獲得できます。

Q5. テキスト以外の情報も記憶できますか? できます。オプションのマルチモーダル拡張をインストールすれば、画像・PDF・音声・Officeドキュメント（Word/PowerPoint/Excel）を投入できます。Officeファイルの処理にはLibreOfficeがシステム依存として必要です。

Q6. 記憶が「自己進化する」とはどういう意味ですか? EverOSはセッションの合間にオフラインで「Reflection（リフレクション）」を実行し、似たエピソードを統合してプロフィールやスキルを精製します。また、エージェントが繰り返し成功したCase（ケース）は、再利用可能なSkill（スキル）へと自動昇格します。記憶が、時間をかけて洗練・成長していくのです。

参照ソース

・EverOS（EverMind-AI 公式リポジトリ） — 本記事が解説した一次情報。アーキテクチャ・API・ユースケース
・EverOS — AI Agent Memory Operating System（公式サイト） — 記憶分類・ハイブリッド検索などのコンセプト解説
・How to Use EverOS: A Local Framework for Long-Term AI Agent Memory — セットアップと使い方の解説記事