Home
Blog
クロード・コワークのような老舗エージェントが台頭する今、RAGは時代遅れになりつつあるのか？

クロード・コワークのような老舗エージェントが台頭する今、RAGは時代遅れになりつつあるのか？

Engineering

January 27, 2026

Min Yin

Claude CoworkはClaude Desktopアプリの新しいエージェント機能です。ローカルファイルの読み込み、変更、生成が可能で、各ステップを手動でプロンプトすることなく、マルチステップタスクを計画することができる。Claude Codeの背後にあるループと同じだが、ターミナルではなくデスクトップに公開されていると考えてほしい。

Coworkの主な機能は、状態を失うことなく長時間実行できることだ。通常の会話のタイムアウトやコンテキストのリセットは発生しない。作業を続け、中間結果を追跡し、セッションをまたいで以前の情報を再利用することができる。これは「長期記憶」のような印象を与えるが、根本的な仕組みは、永続的なタスクの状態＋コンテキストのキャリーオーバーのようなものだ。いずれにせよ、この体験は、独自のメモリーレイヤーを構築しない限りすべてがリセットされる、従来のチャットモデルとは異なる。

このことは、開発者にとって2つの現実的な問題を提起する：

もしこのモデルがすでに過去の情報を記憶できるのであれば、RAGやエージェントRAGはまだどこに位置するのだろうか？RAGは置き換えられるのか？
もしローカルでCoworkスタイルのエージェントが欲しいのであれば、長期記憶をどのように実装すればいいのだろうか？

この記事の残りの部分では、これらの疑問を詳しく取り上げ、ベクターデータベースがこの新しい「モデル記憶」の風景にどのようにフィットするかを説明する。

Claude CoworkとRAGの違いとは？

前述したように、Claude CoworkはClaude Desktopのエージェントモードで、ローカルファイルの読み書きができ、タスクをより小さなステップに分割し、状態を失うことなく作業を続けることができる。独自の作業コンテキストを維持するため、通常のチャットセッションのように複数時間のタスクがリセットされることはありません。

RAG（Retrieval-AugmentedGeneration）は、モデルが外部の知識にアクセスできるようにするという別の問題を解決する。データをベクターデータベースに索引付けし、クエリごとに関連するチャンクを取得し、モデルに送り込む。これは、LLMアプリケーションに、文書、ログ、製品データなどの「長期記憶」を提供するため、広く使われている。

どちらのシステムもモデルの "記憶 "を助けるとしたら、実際の違いは何だろうか？

Coworkのメモリ処理方法

Coworkのメモリは読み書き可能である。エージェントは、現在のタスクや会話から、どの情報が関連性があるかを判断し、それをメモリエントリとして保存し、タスクの進行に応じて後で取り出す。これにより、Coworkは長く続くワークフロー、特に進行中に新しい中間状態を生成するワークフローでも継続性を維持することができる。

RAGとAgentic RAGのメモリ処理方法

標準的なRAGはクエリ駆動型の検索である。ユーザーが何かを尋ねると、システムが関連するドキュメントをフェッチし、モデルがそれを使って回答する。検索コーパスは安定したままバージョン管理され、開発者はそこに何が入るかを正確にコントロールする。

最新のエージェント型RAGは、このパターンを拡張している。モデルは、ワークフローの計画中や実行中に、いつ情報を取得するか、何を取得するか、どのように利用するかを決定することができる。これらのシステムは、Coworkのように長いタスクを実行したり、ツールを呼び出したりすることができる。しかし、エージェント型RAGであっても、検索レイヤーは状態指向ではなく知識指向のままである。エージェントは、権威ある事実を検索するのであって、進化するタスクの状態をコーパスに書き戻すわけではない。

別の見方をしよう：

Coworkのメモリはタスク駆動型である。エージェントは自分自身の進化する状態を書き込んだり読み込んだりする。
RAGは知識駆動型である：システムはモデルが依拠すべき確立された情報を検索する。

クロード・カウワークのリバースエンジニアリング：ロングラン・エージェント・メモリの構築方法

Coworkは、自分が何をしていたかを常に忘れることなく、マルチステップのタスクを処理するため、多くの誇大広告を受けている。開発者の立場からすると、このような長時間のセッションでどのように状態を維持しているのか気になるところだ。Anthropicは内部構造を公表していないが、Claudeのメモリーモジュールを使った以前の開発実験に基づけば、まともなメンタルモデルを組み立てることができる。

クロードは、持続的長期記憶レイヤーとオンデマンド検索ツールのハイブリッドセットアップに依存しているようだ。すべてのリクエストに会話をすべて詰め込むのではなく、クロードは関連性があると判断したときだけ、過去の文脈を選択的に取り込む。これにより、トークンを毎ターン使い切ることなく、高い精度を保つことができる。

リクエストの構造を分解すると、だいたいこんな感じだ：

[0] Static system instructions
[1] User memory (long-term)
[2] Retrieved / pruned conversation history
[3] Current user message

興味深い動作は構造そのものではなく、モデルが何を更新し、いつ検索を実行するかを決定する方法である。

ユーザーメモリ：永続層

クロードは長期的なメモリストアを保持し、時間とともに更新します。ChatGPT の予測可能なメモリシステムとは異なり、クロードのメモリはもう少し "生きている" 感じがします。XML のようなブロックでメモリを保存し、2つの方法で更新します：

暗黙の更新：時々、モデルは何かを安定した嗜好や事実と判断し、それを静かにメモリに書き込む。これらの更新は即座に行われるわけではなく、数ターン後に表示され、関連する会話がなくなると古い記憶はフェードアウトすることがある。
明示的な更新：ユーザーはmemory_user_edits （"Xを覚えておく"、"Yを忘れる"）ツールを使って直接記憶を変更することができる。これらの書き込みは即座に行われ、CRUD操作のように振る舞う。

クロードは、永続化する価値のあるものを決定するためにバックグラウンドでヒューリスティックを実行しており、明示的な指示を待つことはない。

会話の検索：オンデマンドパート

Claudeは多くのLLMシステムのようにローリングサマリーを保持しません。その代わり、文脈が足りないと思ったときにいつでも呼び出せる検索関数のツールボックスを持っている。これらの検索呼び出しは毎ターン行われるわけではなく、モデル自身の内部的な判断に基づいてトリガーされる。

顕著なのは、conversation_search 。ユーザーが "先月のプロジェクト "のような漠然としたことを言ったとき、Claudeは関連するターンを掘り起こすためにこのツールをしばしば起動する。特筆すべきは、言い回しがあいまいだったり、違う言語であったりしても、このツールは機能するということだ。これはかなり明確な意味を持っている：

何らかの意味的マッチング（埋め込み）
おそらく正規化または軽量翻訳との組み合わせ
精度を高めるためのキーワード検索

基本的に、これはモデルのツールセットの中にバンドルされた小型のRAGシステムのように見える。

クロードの検索動作と基本的な履歴バッファの違い

テストとログから、いくつかのパターンが目立つ：

検索は自動的には行われない。検索は自動的には行われない。すでに十分なコンテキストを持っていると判断した場合は、わざわざ呼び出さない。
取得されたチャンクには、 ユーザーとアシスタントの 両方のメッセージが含まれる 。ユーザーだけの要約よりもニュアンスが残ります。
トークンの使用は、正常なままです。履歴は毎ターン注入されるわけではないので、長いセッションが予測不可能に膨らむことはない。

全体的には、検索を強化したLLMのように感じられるが、検索はモデル自身の推論ループの一部として行われる。

このアーキテクチャは賢いが、自由ではない：

検索は、待ち時間と、より多くの「動く部分」（インデックス作成、ランキング、再ランキング）を追加する。
モデルは時々、コンテキストが必要かどうかの判断を誤る。つまり、データが利用可能であったにもかかわらず、古典的な「LLMの忘却」を見ることになる。
モデルの動作はプロンプトの入力だけでなく、目に見えないツールのトリガーに依存するため、デバッグはより厄介になる。

長期記憶の取り扱いにおけるクロード・コワークとクロード・コーデックスの比較

クロードの検索を多用するセットアップとは対照的に、ChatGPTはより構造的で予測可能な方法で記憶を扱います。意味的なルックアップを行ったり、古い会話をミニベクターストアのように扱う代わりに、ChatGPTは以下のレイヤーコンポーネントを通して各セッションに直接メモリを注入します：

ユーザーメモリ
セッションメタデータ
現在のセッションメッセージ

ユーザーメモリ

ユーザーメモリはメインの長期保存層で、セッションをまたいで持続し、ユーザーが編集できる部分です。名前、経歴、進行中のプロジェクト、学習の好みなど、ごく標準的なものを保存します。すべての新しい会話は、このブロックを開始時に注入するので、モデルは常に一貫したユーザービューから始まります。

ChatGPTは2つの方法でこのレイヤーを更新します：

明示的な更新：ユーザはモデルに "これを覚えておいて "とか "それを忘れておいて "と指示することができ、メモリは即座に変更されます。これは基本的に、モデルが自然言語を通して公開するCRUD APIです。
暗黙的な更新：OpenAIの長期記憶のルールに適合する情報をモデルが発見した場合、例えば職種や嗜好など。

開発者の視点から見ると、このレイヤーはシンプルで、決定論的で、推論が簡単です。ルックアップを埋め込むこともなく、何を取得するかについてのヒューリスティックもありません。

セッションメタデータ

セッション・メタデータは、その対極に位置する。短命で、永続性がなく、セッション開始時に一度だけ注入されます。会話のための環境変数と考えてください。これには以下のようなものが含まれます：

どのデバイスを使用しているか
アカウント/サブスクリプションの状態
大まかな使用パターン（アクティブな日数、モデルの分布、平均的な会話の長さ）

このメタデータは、長期的なメモリを汚染することなく、現在の環境（例えば、モバイルでより短い回答を書くなど）に合わせてモデルが回答を形成するのに役立ちます。

現在のセッションメッセージ

これは標準的なスライディングウィンドウの履歴で、トークン制限に達するまでの現在の会話のすべてのメッセージです。ウィンドウが大きくなりすぎると、古いターンは自動的に削除されます。

重要なことは、この削除はユーザーメモリやクロスセッションサマリーには影響しないということです。ローカルな会話履歴だけが縮小される。

クロードとの最大の相違点は、ChatGPTが "最近の、しかし現在ではない "会話をどのように扱うかに現れます。クロードは過去の文脈を検索するために検索ツールを呼び出します。ChatGPTはそれをしません。

その代わりに、ChatGPTはすべての会話に注入される非常に軽量なクロスセッションサマリーを保持します。このレイヤーのいくつかの重要な詳細：

アシスタントメッセージではなく、ユーザーメッセージのみを要約します。
それは非常に小さなアイテムのセット-安定したテーマや興味をキャプチャするのに十分な約15-を格納します。
埋め込み計算も、類似度ランキングも、検索呼び出しもしない。基本的に、動的な検索ではなく、事前に噛み砕かれたコンテキストなのだ。

エンジニアリングの観点からは、このアプローチは柔軟性と予測可能性を引き換えにするものである。奇妙な検索失敗の可能性はなく、推論レイテンシは安定したままです。欠点は、ChatGPTがサマリーレイヤーに入らない限り、6ヶ月前のランダムなメッセージを取り込めないことです。

エージェントメモリを書き込み可能にする課題

エージェントが読み取り専用メモリ（典型的な RAG）から書き込み可能メモリ（ユーザの行動、決定、好みを記録できる）に移行すると、複雑さは一気に跳ね上がります。もはやドキュメントを取り出すだけでなく、モデルが依存する成長状態を維持することになります。

書き込み可能なメモリーシステムは、3つの現実的な問題を解決しなければならない：

何を記憶するか：エージェントは、どのイベント、プリファレンス、オブザベーションを保持する価値があるかを決定するためのルールを必要とする。これがないと、メモリは爆発的に大きくなるか、ノイズでいっぱいになる。
どのようにメモリーを保存し、階層化するか：記憶はすべて同じではない。最近のアイテム、長期的な事実、刹那的なメモなど、すべて異なるストレージ層、保持ポリシー、インデックス戦略が必要である。
検索を中断することなく高速に書き込む方法：メモリは継続的に書き込まれなければならないが、システムが高スループットの挿入用に設計されていない場合、頻繁な更新はインデックスの品質を低下させたり、クエリを遅くしたりする可能性がある。

課題1：何を記憶する価値があるのか？

ユーザーが行ったことすべてが長期メモリに残るわけではありません。誰かが一時ファイルを作成し、5分後に削除したとしても、それを永遠に記録することは誰の役にも立たない。これが核心的な問題である。システムは、実際に何が重要かをどうやって決めるのだろうか？

(1) 重要性を判断する一般的な方法

チームは通常、さまざまなヒューリスティックに頼っている：

時間ベース：最近のアクションは古いものより重要である。
頻度ベース：繰り返しアクセスされるファイルやアクションは、より重要である。
タイプベース：あるオブジェクトは本質的に重要度が高い（たとえば、プロジェクトの設定ファイルとキャッシュファイルなど）

(2) ルールが衝突するとき

これらのシグナルはしばしば衝突します。先週作成され、今日大量に編集されたファイルは、年齢とアクティビティのどちらを優先すべきでしょうか？唯一の "正しい "答えがないため、重要度スコアリングはすぐに厄介なことになりがちです。

(3)ベクターデータベースはどのように役立つか

ベクターデータベースは、手動でクリーンアップすることなく、重要度ルールを強制する仕組みを提供します：

TTL：milvusは設定された時間経過後にデータを自動的に削除することができる。
減衰：古いベクターは重み付けを下げることで、検索から自然にフェードアウトさせることができる。

課題2：メモリ階層化の実際

エージェントの稼働時間が長くなるにつれ、メモリは溜まっていく。そのため、システムはメモリをホット層（頻繁にアクセスされる層）とコールド層（めったにアクセスされない層）に分ける方法が必要になる。

(1) メモリがコールドになるタイミングの決定

このモデルでは、ホット・メモリは低レイテンシ・アクセスのためにRAMに保持されるデータを指し、コールド・メモリはコスト削減のためにディスクやオブジェクト・ストレージに移動されるデータを指す。

メモリがコールドになるタイミングを決定する方法はさまざまです。システムによっては、軽量モデルを使用して、アクションやファイルの意味的重要度を、その意味と最近の使用状況に基づいて推定する。また、30日間アクセスされていないメモリや、1週間検索結果に出てこないメモリを移動させるなど、単純なルールベースのロジックに依存するものもある。ユーザーは、特定のファイルやアクションを明示的に重要なものとしてマークし、常にホットな状態を維持することもできる。

(2) ホットメモリーとコールドメモリーの保管場所

いったん分類されたホットメモリーとコールドメモリーは、保存場所が異なる。ホットメモリはRAMに残り、アクティブなタスクコンテキストや最近のユーザーアクションなど、頻繁にアクセスされるコンテンツに使用されます。コールドメモリはディスクやS3のようなオブジェクトストレージシステムに移され、アクセスは遅くなるが、ストレージコストははるかに低くなる。コールドメモリはほとんど必要とされず、通常、長期的な参照のためだけにアクセスされるため、このトレードオフはうまく機能する。

(3)ベクター・データベースはどのように役立つか

MilvusとZilliz Cloudは、単一のクエリ・インターフェースを維持しながら、ホット-コールドの階層型ストレージを可能にすることで、このパターンをサポートしています。これにより、頻繁にアクセスされるベクターはメモリに留まり、古いデータは自動的に低コストのストレージに移動します。

課題3：メモリの書き込み速度は？

従来のRAGシステムは通常、バッチでデータを書き込む。インデックスはオフラインで、しばしば一晩かけて再構築され、後で初めて検索可能になる。このアプローチは静的な知識ベースには有効ですが、エージェントのメモリには合いません。

(1) エージェントメモリにリアルタイム書き込みが必要な理由

エージェントメモリは、ユーザのアクションをその都度キャプチャする必要があります。アクションが即座に記録されないと、次の会話の順番に重要なコンテキストが欠けてしまう可能性があります。このため、書き込み可能なメモリシステムは、遅延したオフライン更新ではなく、リアルタイム書き込みを必要とする。

(2) 書き込み速度と検索品質の緊張関係

リアルタイム・メモリには、非常に低い書き込みレイテンシが要求される。同時に、高品質な検索はよく構築されたインデックスに依存し、インデックスの構築には時間がかかる。書き込みのたびにインデックスを再構築するのはコストがかかりすぎるが、インデックスの作成を遅らせることは、新しく書き込まれたデータが一時的に検索から見えなくなることを意味する。このトレードオフが書き込み可能メモリ設計の中心にある。

(3)ベクターデータベースの利点

ベクターデータベースは、書き込みとインデックス作成を切り離すことでこの問題に対処します。一般的な解決策は、書き込みをストリーム化し、インデックスをインクリメンタルに構築することである。Milvusを例にとると、新しいデータはまずインメモリバッファに書き込まれるため、システムは高頻度の書き込みを効率的に処理することができる。完全なインデックスが構築される前であっても、バッファリングされたデータは動的マージや近似検索によって数秒以内にクエリすることができる。

バッファが事前に定義された閾値に達すると、システムはバッチでインデックスを構築し、それを永続化する。これにより、リアルタイムの書き込みをブロックすることなく、長期的な検索パフォーマンスが向上する。高速なインジェストと低速なインデックス構築を分離することで、Milvusはエージェントメモリに適した書き込み速度と検索品質の実用的なバランスを実現している。

結論

Coworkは、永続的で、ステートフルで、長いタイムラインに渡ってコンテキストを保持できる新しいクラスのエージェントを垣間見せてくれる。しかし、それはまた別のことを明らかにしている。長期記憶は、絵の半分に過ぎないのだ。自律的で信頼性の高いエージェントを構築するためには、大規模で進化する知識ベースを構造化して検索する必要がある。

RAGは世界の事実を扱い、書き込み可能なメモリはエージェントの内部状態を扱う。そして、ベクトル・データベースはその交差点に位置し、インデックス付け、ハイブリッド検索、スケーラブルなストレージを提供することで、両レイヤーが共に機能することを可能にする。

長期間稼働するエージェントが成熟し続けるにつれ、そのアーキテクチャはこのハイブリッドデザインに収束していくだろう。Coworkは、RAGのない世界ではなく、その下にベクターデータベースを搭載したリッチなメモリスタックを持つエージェントの方向性を示す強いシグナルである。

これらのアイデアを探求したり、独自のセットアップのヘルプを得たい場合は、Milvusの Slackチャンネルに参加してMilvusエンジニアとチャットしてください。また、より実践的なガイダンスをご希望の場合は、Milvusオフィスアワーを ご予約ください。