セッションをまたぐたびに文脈が消える——AIエージェント開発でよくある悩みです。EverOS 1.0.0は、この課題に向けたオープンソースの記憶基盤として2026年6月3日に初の安定版を公開しました。ローカルで動かせ、中身をMarkdownファイルとして直接確認できる点が特徴です。

この記事でわかること

  • EverOS 1.0.0が解決する課題と設計思想
  • 3層ストレージ構成とデュアルトラック記憶の仕組み
  • インストールから最初の記憶の書き込み・検索までの手順
  • 類似のエージェント記憶ライブラリとの違い

https://github.com/EverMind-AI/EverOS

毎回ゼロから始まるエージェントの限界

Claude CodeやCodexのようなコーディングエージェントは、セッションを閉じると会話の文脈や作業の経緯が失われます。ベクトルDBに記憶を預ける方式もありますが、中身がブラックボックスになり、編集やバージョン管理が難しいという不満が残ります。

EverMind-AIが開発するEverOSは、エージェントの長期記憶を「ローカルで動く記憶OS」として再設計したフレームワークです。2026年6月に公開された1.0.0は、PyPI配布と安定APIを備えた初の本番向けリリースです。開発者向けに再構築されたREADME、クイックスタート、20件以上のユースケース集が揃い、実際に手を動かして検証しやすい構成になっています（参考）。

EverOSが採る3層のローカル構成

EverOSの中核は「Markdownを正（ソース・オブ・トゥルース）とする」設計です。記憶の本体はすべてプレーンな.mdファイルとして保存され、テキストエディタやObsidianで開いて編集できます。Gitでのバージョン管理も可能です。

その上に、2つの派生インデックスが載ります。

  • SQLite — 状態管理、キュー、監査ログを担当
  • LanceDB — ベクトル検索、BM25全文検索、スカラー絞り込みを1クエリで実行

MongoDB、Elasticsearch、Redisといった外部サービスは不要です。インデックスはMarkdownから再構築できるため、.indexディレクトリを削除しても記憶本体は失われません。デフォルトの保存先は~/.everos/で、環境変数EVEROS_MEMORY__ROOTで変更できます。

ユーザー記憶とエージェント記憶の2系統

EverOSは記憶を「ユーザー側」と「エージェント側」に分けて管理します。これをデュアルトラック記憶と呼びます。

ユーザー側（user-track）には、日々の出来事を記録するEpisodesと、ユーザーの嗜好や属性をまとめたProfilesがあります。エージェント側（agent-track）には、過去のタスク実績を格納するCasesと、繰り返し成功した手順を凝縮したSkillsがあります。Skillsは自己進化型の手続き記憶として設計されており、同じワークフローを繰り返すほどエージェントの振る舞いが改善されます。

検索時はuser_id、agent_id、app_id、project_id、session_idでスコープを絞り込めます。会話、ワークフロー、エージェントの実行トレース、ファイル由来の知識など、複数ソースからの抽出に対応しています。

主な機能

ハイブリッド検索

LanceDB上でBM25（キーワード一致）、コサイン類似度によるベクトル検索、スカラーフィルタを組み合わせたハイブリッド検索を提供します。RAG（検索拡張生成）の文脈でいえば、意味的な類似と語句一致の両方をカバーする構成です。

カスケードインデックス同期

Markdownファイルを直接編集すると、ファイルウォッチャーが変更を検知し、エントリ単位の差分をLanceDBへ反映します。通常はサブ秒で同期が完了します。記憶の中身を人間が手で直しても、検索インデックスが自動で追従する仕組みです。

マルチモーダル取り込み

everos[multimodal]オプションを入れると、画像・PDF・音声・Office文書などを/api/v1/memory/add経由で投入できます。LLMや埋め込みモデルはOpenAI互換プロトコルに対応しており、OpenRouter、Ollama、vLLM、DeepInfraなどに切り替え可能です。記憶抽出のアルゴリズム本体はPyPIのeveralgo-*パッケージ群に分離されています。

CLIとHTTP API

everosコマンドでサーバーを起動し、FastAPIベースのHTTP APIから記憶を操作します。ライブラリとして直接インポートする方式ではなく、常にローカルサーバーが前面に立つサービス型の設計です。デフォルトのバインド先は127.0.0.1で、ループバックのみに限定されています。

使い方の流れ

前提条件はPython 3.12以上と、LLM・埋め込み用のAPIキーです。デフォルト設定ではOpenRouter（チャット・マルチモーダル）とDeepInfra（埋め込み・リランク）の2種類のキーで動きます。

pip install everos
everos init
everos server start

別ターミナルでヘルスチェックを行います。

curl http://127.0.0.1:8000/health

記憶の追加はPOST /api/v1/memory/add、抽出の確定はPOST /api/v1/memory/flush、検索はPOST /api/v1/memory/searchです。会話を送ってflushしたあと、自然言語クエリで検索すると、Yosemiteの登山話のような事実が返ってくるデモがREADMEに掲載されています。EpisodeのMarkdownは/flushの応答前にディスクへ書き込まれるため、記憶本体の永続化は同期的に完了します。

料金とライセンス

EverOS本体はApache License 2.0のもとで無料利用できます。GitHubのスター数は8000超（2026年6月時点）で、フォークも700件以上に達しています。ただしLLMや埋め込みモデルのAPI利用料は別途発生します。EverMindはマネージド版のEverOS Cloudも提供していますが、OSS版はデータを完全にローカルに保持したい開発者向けの選択肢です。

他のエージェント記憶ライブラリとの違い

多くのエージェント記憶ライブラリは、APIやダッシュボード経由でベクトルDBやグラフDBに記憶を格納します。EverOSは公式READMEで、Markdownを正とする設計、直接ファイル編集、ローカル3層構成、ユーザーとエージェントの分離、直交した検索スコープの5点で差別化を示しています。

観点 EverOS 一般的な記憶ライブラリ
記憶の保存形式 .mdファイル（Git管理可） APIやDB上の不透明なレコード
外部依存 なし（ローカル完結） マネージドDBやRedis等が必要な場合が多い
記憶の編集 ファイルを直接編集し自動同期 SDKやダッシュボード経由が中心

同じEverMindエコシステムには、ハイパーグラフ記憶のHyperMemやベンチマークのEverMemBenchもあります。EverOSは「読める・編集できる・ローカルで完結する」記憶基盤に特化した位置づけです。

今後のロードマップ

1.0.0の公開後、1.0.1（2026年6月16日）ではパストラバーサル対策やMarkdown書き込みの防御強化が入りました。今後予定されているのはKnowledge Wiki（記憶から編集可能な知識ページを生成）とReflection（アイドル時やオフライン時に記憶を整理し、プロファイルやスキルを改善）です。

ユースケース集には、Claude Code向けプラグイン、コーディングアシスタント用MCP連携、マルチエージェントオーケストレーション、学習支援、ウェアラブル連携など20件以上の実例が掲載されています。エージェントに持続的な記憶を持たせたい開発者にとって、ローカルで検証できる実用的な出発点と言えます。