8月25日、Praveen Bodigutlaが「Inside LinkedIn's cognitive memory agent for agentic personalization」と題した記事を公開した。リクルーター向けAIエージェントにおいて「ユーザーの好みをセッションをまたいで引き継ぐ」という一見シンプルな要件が、いかに深い設計上の問題を内包しているか——LinkedInのエンジニアリングチームがその解として構築した4層構造の認知メモリエージェント（Cognitive Memory Agent）の設計と実装が、本記事で詳細に解説されている。

なぜ「メモリエージェント」が必要だったのか

LinkedInは採用担当者（リクルーター）向けに「Hiring Assistant」と呼ばれるAIエージェントを開発・リリースしている。このエージェントを使うなかでリクルーターは、採用する職種の条件や候補者へのフィードバックを繰り返し表明する。LinkedInのチームが気づいたのは、こうした好みには「粘着性」があるという事実だ。つまり、ある役職の採用で表明したスキル要件や立地の好みは、別の類似役職の採用にも引き継がれる傾向がある。

単純なセッション内の会話履歴だけでは、このようなセッションをまたいだ文脈を保持できない。そこでチームが構築したのが、「メモリのライフサイクル全体を管理する」エージェント——Cognitive Memory Agent（認知メモリエージェント）だ。

AIエージェントにおける長期メモリの設計は、2024年以降の業界共通の課題として急速に注目を集めている。Mem0やZepといった専用のメモリレイヤーサービスが登場し、LangChainもMemoryの抽象化を継続的に整備してきた背景がある。LinkedInの事例は、こうした汎用ツールをそのまま使うのではなく、ドメイン固有の要件に合わせて独自設計した点で実践的な参考事例となっている。

4層メモリアーキテクチャの設計

このエージェントの核心は、4種類のメモリ層を組み合わせた構造にある。それぞれが異なる粒度・時間軸で情報を保持する。

1. 会話メモリ（Conversational Memory）
現在進行中のセッション内の発話と好みをリアルタイムで保持する。最も新鮮だが、セッションをまたいでは持続しない。

2. エピソードメモリ（Episodic Memory）
個々のアクティビティや過去セッションの出来事を時系列で保存する時間軸レイヤー。「最近この候補者を好んだ」「先週この条件を変更した」といった時間的クエリを可能にする。また、後述のセマンティック層で集約された結論の根拠（provenance）を追跡する役割も担う。

3. セマンティックメモリ（Semantic Memory）
複数セッションや複数プロダクト表面（エージェントだけでなく検索プラットフォームでの行動も含む）を横断して集約された、ユーザーの長期的な好みの表現。いわば「このリクルーターは何を重視しているか」を蒸留したレイヤーだ。

4. 手続きメモリ（Procedural Memory）
同じ採用タスクを達成するにしても、リクルーターによってアプローチが異なる。立地を最優先する人もいれば、シニアリティにこだわる人もいる。この「どのようにタスクを達成するか」というスタイルを捉えるのが手続きメモリだ。

この4層構造は、認知科学における人間の記憶モデル（エピソード記憶・意味記憶・手続き記憶の分類）をAIエージェントに応用した設計として読むこともできる。Praveenは原文中でこの構造を **"a layered cake of conversational, episodic, procedural, and semantic memory"**（会話・エピソード・手続き・セマンティックの4層でできた層状のケーキ）と表現している。

ツリー構造による長期メモリの組織化

エンジニア的に最も興味深い設計判断のひとつが、ツリー構造による長期メモリの組織化だ。

LinkedInのリクルーターのデータは自然なヒエラルキーを持つ。

• 最下層：個々の採用プロジェクト単位の好み（リーフノード）
• 中間層：リクルーター個人レベルの集約
• 上位層：同一企業内の複数リクルーターのコホート

このコホートレイヤーが実用上の「超能力」として機能する。新しいリクルーターがオンボードした際、同コホートの蓄積データを使ってゼロから始めなくて済むブループリントを自動生成できる。

なお、Praveenはグラフ構造も対応可能な設計にしており、各アプリケーションが自身の長期メモリ構造を定義しつつ、オーケストレーション・推論・合成のレイヤーは共通インターフェースで再利用できるアーキテクチャを採用している。リクルーティング用途にはツリー構造が適合するが、より複雑なエンティティ関係を扱うアプリケーションではグラフ構造を選択できる設計だ。

大規模運用での課題：鮮度・レイテンシ・アクセス制御

設計上の課題はアーキテクチャだけではない。リアルタイムで動くプロダクションシステムとして、以下の課題に対処している。

コンテキストの肥大化（Context Bloat）
採用プロセスは多段階にわたるため（JD作成→候補者レビュー→フィードバック→連絡→アーカイブ…）、インタラクションが積み重なると文脈が膨張する。リアルタイム・ニアリアルタイムで情報を圧縮・統合するIngestionサービスを用意することで対処している。

情報の鮮度と競合の解決
会話中に好みが変わった場合（「この地域ではなく別のスキルセットを重視したい」）、直近の表明を優先しつつ、既存の集約データとの競合を低レイテンシで解決する必要がある。

エピソード境界の定義
固定ワークフローエージェントならステップ境界が明確だが、より高度なインタラクションでは境界が曖昧になる。「どこまでが一つのエピソードか」を動的に判断するロジックが必要になる。

実装：LangGraphベースのエージェント

メモリエージェントの実装は**LangGraph**ベース。各メモリ層へのアクセスはツールとして抽象化されており、APIシグネチャは共通化されている。アプリケーションごとにツールの説明文をオーバーライドして挙動をカスタマイズする設計だ。

セッションをまたいだユーザー好みの保持という課題に対し、LinkedInが選んだのは汎用ツールの組み合わせではなく、認知科学の知見を参照した4層アーキテクチャとドメイン固有のツリー構造メモリだった。AIエージェントのメモリ設計に取り組む実務者にとって、プロダクションスケールでのトレードオフと設計判断の根拠が具体的に示された記事であり、一読の価値がある。

詳細はInside LinkedIn's cognitive memory agent for agentic personalizationを参照していただきたい。