LangChain の創設者 Harrison Chase が 2026年4月11日に公開した記事「Your harness, your memory」を読んだ。AI エージェント開発におけるハーネス（harness）とメモリの密接な関係、そしてクローズドなハーネスがもたらすロックインの危険性を指摘する内容だ。本記事ではその要点を整理し、エージェント開発者が考慮すべきポイントを解説する。

エージェントハーネスとは何か

エージェントハーネスとは、LLM がツールやデータソースとやり取りするための「足場」を提供するシステムだ。テストハーネスがテスト実行環境を支える外枠であるように、エージェントハーネスはエージェントの実行環境を支える外枠を指す。Chase は以下のような進化の流れを示している。

  1. RAG チェーン時代（2023年〜）: ChatGPT 登場直後、シンプルな検索拡張生成（LangChain）
  2. 複雑なフロー時代: モデルの改善に伴い、より複雑なワークフローが可能に（LangGraph）
  3. エージェントハーネス時代（現在）: モデルの大幅な性能向上により、新しい種類の足場が登場

具体的なエージェントハーネスの例として、Claude Code、Deep Agents、Pi（OpenClaw を駆動）、OpenCode、Codex、Letta Code などが挙げられている。

Chase は「モデルがハーネスの機能を吸収していく」という意見に反論する。2023年に必要だった足場の多くは不要になったが、それに代わる新しい種類の足場が登場している。エージェントは定義上、LLM がツールやデータとやり取りするものであり、その相互作用を仲介するシステムは常に必要だ。Chase はその根拠として、Claude Code のソースコードが51万2000行に及ぶ規模を挙げている。

エージェントハーネスとメモリが切り離せない理由

Chase は Letta の CTO Sarah Wooders のブログ「memory isn’t a plugin (it’s the harness)」を引用し、ハーネスとメモリは不可分だと主張する。

メモリをエージェントハーネスにプラグインしてほしいと頼むのは、運転を車にプラグインしてほしいと頼むようなものだ。コンテキストの管理、すなわちメモリの管理は、エージェントハーネスの中核的な能力であり責任だ。

メモリはコンテキストの一形態に過ぎない。ハーネスが管理するコンテキストには以下が含まれる。

  • 短期メモリ: 会話内のメッセージ、大きなツール呼び出し結果
  • 長期メモリ: セッションをまたぐ記憶（クロスセッションメモリ）
  • 設定ファイル: AGENTS.md や CLAUDE.md のロード方法
  • スキルメタデータ: エージェントへの提示方法
  • コンパクション（要約による圧縮）: 長い会話履歴を要約して短縮する際、何が残り、何が失われるか

これらすべてがハーネスの設計に依存しており、メモリを独立したサービスとして切り離すことは現時点では現実的ではない。

エージェントにおける「メモリ」の実体

Chase の記事では「メモリ」が抽象的に語られているが、その実体は大きく4つの層に分けられる。それぞれの層がなぜハーネスと切り離せないのかを具体的に見ていこう。

第1層: コンテキストウィンドウ内のメッセージ履歴

最も基本的なメモリの実体は、LLM に渡される会話メッセージの配列だ。ユーザーの発言、アシスタントの応答、ツール呼び出しの結果がすべてこの配列に格納される。

このメッセージ配列をどう構築・管理するかがハーネスの中核機能だ。ツール呼び出しの結果をどの位置に挿入するか、大きすぎる結果をどう切り詰めるか、システムプロンプトに何を含めるか。これらはすべてハーネスの設計判断であり、エージェントの応答品質を直接左右する。

管理が重要な理由: メッセージ配列の構成方法が異なれば、同じ LLM でもまったく異なる応答を返す。つまり、ハーネスを切り替えると「同じエージェント」が再現できなくなる。

第2層: コンパクション（会話の要約圧縮）

LLM のコンテキストウィンドウには上限がある。長い会話を続けるには、過去のやり取りを要約して圧縮する必要がある。これがコンパクションだ。

実体は「これまでの会話を要約したテキスト」で、ハーネスが自動生成してメッセージ配列の先頭に挿入する。各ハーネスの実装は異なる。

  • Claude Code: 会話が長くなると自動でコンパクションを実行し、要約をシステムメッセージとして挿入する
  • OpenAI Codex: 暗号化されたコンパクションサマリーを生成する。OpenAI 以外の環境では復号できないため、会話の継続性がプラットフォームに縛られる
  • Anthropic サーバーサイドコンパクション: サーバー側で状態を保持し、クライアントには要約済みのコンテキストだけを返す

管理が重要な理由: 何を残し何を捨てるかで、エージェントの「記憶の質」が決まる。コンパクションのロジックがブラックボックスだと、重要な文脈が予期せず失われるリスクがある。さらに暗号化やサーバーサイド保持の場合、そのデータを他のハーネスに持ち出すことが技術的に不可能になる。

第3層: 永続的なファイル・データベース（長期メモリ）

セッションをまたいで保持される情報で、エージェントのパーソナライズの基盤だ。ハーネスごとに保存形式と保存場所がまったく異なる。

ハーネスメモリの実体保存場所
Claude CodeCLAUDE.md 設定ファイル、auto-memory（Markdown ファイル群）ローカルファイルシステム
Deep Agentsユーザープロファイル、学習済み嗜好データMongoDB / PostgreSQL / Redis（選択可能）
Claude Managed Agentsセッション状態、ユーザー嗜好Anthropic のクラウドサーバー（非公開）
Lettaarchival memory（長期記憶）+ recall memory（想起記憶）Letta サーバーの DB

例えば Claude Code の auto-memory では、ユーザーの好みやフィードバックが個別の Markdown ファイルとして保存され、会話開始時にコンテキストに注入される。一方、Claude Managed Agents では同等の情報が Anthropic のサーバーに保存され、ユーザーからは直接アクセスできない。

管理が重要な理由: 長期メモリはエージェントの「人格」を形成する。Chase のメールアシスタントが削除された際に体験が劣化したのは、この層のデータが失われたからだ。保存場所が自分の管理下にあれば、バックアップ・移行・監査が可能になる。プロバイダーのサーバーにしかなければ、サービス停止やプラン変更でメモリごと失われるリスクがある。

第4層: 設定・スキルのロード方式

CLAUDE.md や AGENTS.md といった設定ファイル、スキル定義、ツール設定もメモリの一部だ。

  • どのファイルをロードするか: ディレクトリ階層のどこまで探索するか
  • いつロードするか: 起動時に一括か、必要に応じて都度か
  • コンパクション時の扱い: 設定情報をコンパクション後も保持するか

管理が重要な理由: ロード方式がエージェントの能力を規定する。同じ設定ファイルでも、ハーネスが異なればロードのタイミングや優先順位が変わり、エージェントの振る舞いが変わる。この仕様が非公開であれば、ハーネス移行時に同等の振る舞いを再現する手がかりすらない。

メモリの4層が意味すること

これら4層のいずれもがハーネスの内部実装に深く結びついている。クローズドなハーネスを使うということは、4層すべての管理を第三者に委ねるということだ。Chase が「メモリを所有しろ」と主張するのは、具体的にはコンパクションのロジック、長期メモリのストレージ、設定のロード方式をすべて自分で制御できる状態にしておけということである。

クローズドハーネスが生むロックイン

Chase はクローズドなハーネスの問題を3段階で整理している。

ステートフル API のロックインリスク

ステートフル API（サーバー側で状態を保持する API）を使用する場合のリスクだ。OpenAI の Responses API や Anthropic のサーバーサイドコンパクションのように、状態をプロバイダーのサーバーに保存する方式では、モデルを切り替えて以前のスレッドを再開することができなくなる。

クローズドソースハーネスの不透明性

Claude Agent SDK のように、内部でクローズドソースの Claude Code を使用するハーネスの問題だ。メモリとの相互作用が不透明で、生成されるメモリデータやログの形式・活用方法が外部から把握できない。そのため、別のハーネスへの移行が困難になる。

API の背後に隠されたメモリの危険

ハーネス全体（長期メモリを含む）が API の背後に置かれるケース。メモリの所有権も可視性もゼロになる。Chase は Anthropic の Claude Managed Agents をこの例として挙げ、すべてが API の背後にロックされると警告している。

さらに、OpenAI の Codex がオープンソースであるにもかかわらず、暗号化されたコンパクションサマリー（OpenAI エコシステム外では使用不能）を生成している点も指摘されている。

メモリがロックインを生む理由

メモリはまだ初期段階だが、その重要性は明確だ。

  • メモリによりエージェントはユーザーとの対話を通じて改善される
  • ユーザーごとのパーソナライズが可能になり、データフライホイールが構築される
  • メモリがなければ、同じツールにアクセスできる誰もがエージェントを複製できる
  • メモリがあれば、ユーザーインタラクションと嗜好の独自データセットが蓄積される

これまでモデルプロバイダーの切り替えは比較的容易だった。API は類似しており、プロンプトの微調整程度で済んだ。しかしそれは API がステートレスだったからだ。一方、状態（メモリ）が紐づいた瞬間、切り替えのコストは劇的に上がる。

Chase 自身のエピソードも印象的だ。社内のメールアシスタントが誤って削除された際、同じテンプレートから再作成しても体験は大幅に劣化した。トーンや好みをすべて再教育する必要があったという。

オープンソースのエージェントハーネスによるロックイン回避

Chase は解決策として、LangChain が開発する Deep Agents を提示している。なお、Deep Agents は Chase 自身が率いる LangChain のプロダクトであり、その点を踏まえて評価する必要がある。

  • オープンソース: コードが公開されている
  • モデル非依存: 特定のモデルプロバイダーに縛られない
  • オープン標準の採用: agents.md や skills などの標準規格を使用
  • 柔軟なストレージ: MongoDB、PostgreSQL、Redis など複数のデータベースでメモリを保存可能
  • デプロイの自由: LangSmith Deployment（セルフホスト可能）や任意の Web ホスティングフレームワークで展開可能

エージェント開発者への示唆

この記事から得られる実践的な教訓は以下のとおりだ。

  1. メモリの所在を意識する: 自分のエージェントのメモリがどこに保存され、誰がコントロールしているかを把握する
  2. 移植性を確保する: メモリのエクスポート・インポートが可能な設計を選ぶ
  3. ステートフル API の依存を最小化する: サーバーサイドのコンパクションや状態管理に過度に依存しない
  4. オープンな選択肢を評価する: Deep Agents に限らず、メモリの所有権を維持できるハーネスを検討する

メモリはエージェントの競争力の源泉になりつつある。だからこそ、その所有権とポータビリティを確保することが、長期的なエージェント戦略において重要な判断基準となる。