AIエージェントにとって「記憶」をどう持つかは、性能と運用コストを左右する設計上の核心的な問いです。最近のTypeScript向けエージェント開発では、Mem0とTurboMemという2つのアプローチが比較されており、それぞれが異なるアーキテクチャ上のトレードオフを持ちます。
サービス分離型 vs. 組み込み型：メモリ層の2つの設計思想
Mem0は「外部サービスとしてのメモリ」という設計を取ります。エージェントプロセスとは別にメモリサービスが独立して動作し、エージェントはAPIを通じて記憶を読み書きします。これはマイクロサービスアーキテクチャ（システムを独立した小さなサービスに分割する構成）と親和性が高く、複数エージェントが同一のメモリストアを共有できる点が強みです。たとえば、顧客対応エージェントと注文管理エージェントが同じユーザーの会話履歴を参照するようなシナリオで有効に機能します。
一方TurboMemは「組み込み型メモリ」を採用しています。メモリ管理がエージェントプロセス内に直接統合されるため、ネットワーク越しのAPIコールが不要です。この差はレイテンシ（応答遅延）に直接影響します。外部サービスへの1回のRPCコールが数十ミリ秒を要する場合、会話ターンのたびにそのコストが積み重なります。リアルタイム性が求められるチャットエージェントではこの差が体感として現れやすくなります。
設計判断の軸として整理すると次のようになります。
- スケーラビリティ：複数エージェントを横断してメモリを共有したい場合はMem0のサービス分離型が有利
- レイテンシ：1エージェント完結でリアルタイム応答を優先するならTurboMemの組み込み型が有利
- 運用複雑度：Mem0はメモリサービス自体の監視・デプロイ・障害対応が別途必要になる
- データ一貫性：外部サービス経由では分散システムの整合性問題（書き込み後の読み取りに若干のラグが生じるなど）が発生しうる
どちらが優れているという話ではなく、エージェントの用途と規模に応じて選択する問題です。
SlackのAgentic Testingが示す非機能要件へのアプローチ
メモリ層の設計とは別に、AIエージェントをQA（品質保証）の文脈に応用した事例として注目されるのがSlack Engineeringの「Agentic Testing」です。これはAIエージェントがUIを自律的に探索し、テストシナリオをその場で生成するというアプローチです。
従来のE2Eテスト（エンドツーエンドテスト：UIから始めてバックエンドまで通して動作を確認するテスト手法）では、テストスクリプトをあらかじめ人手で書く必要がありました。UIの変更があるたびにスクリプトが壊れ、修正コストが発生するという問題は多くのプロジェクトで共通の課題です。
SlackのAgentic Testingはこの脆弱性を根本から変えようとします。エージェントがUIの構造を学習しながらテストを動的に生成するため、画面レイアウトが変わってもテストロジックが自己適応します。これはテストスクリプトのメンテナンスコストという技術的負債（将来の変更コストを増大させる設計上の問題の蓄積）を削減する効果があります。
可用性の観点でも意義があります。定義済みのパスしか検証しない従来型テストは、エッジケース（仕様の境界付近の特殊な入力や状態）を見逃しやすい傾向があります。エージェントが自律探索することで、人間が想定しなかったUIの組み合わせを発見できる可能性が高まります。
ワークフロー設計における「スキル」の粒度管理
シード記事にはもう一つの視点として、コンテンツ自動化ワークフローの設計進化が紹介されています。単体のプロンプトファイルから「エージェントスキル」（特定のAIタスクをカプセル化した再利用可能な処理単位）へと移行するという話です。
これはソフトウェアアーキテクチャの文脈では、手続き型コードから関数・モジュールへの分解と本質的に同じ問題です。スキルを適切な粒度に分割することで、再利用性と可読性が上がります。しかし粒度が細かすぎると、スキル間の呼び出しオーバーヘッドやオーケストレーション（複数のスキルの実行順序と依存関係を管理する仕組み）の複雑度が増します。
たとえば「記事の要約を生成する」というスキルを「センテンス抽出」「重要度スコアリング」「出力フォーマット変換」の3スキルに分解するかどうかは、それぞれを独立して再利用する必要があるかどうかで判断が変わります。分解しすぎると呼び出しチェーンが深くなり、デバッグが難しくなります。
この粒度判断はAIエージェントのワークフロー設計でも従来のシステム設計でも同様に現れます。将来の変更容易性とランタイムの実行効率はトレードオフの関係にあり、両者を天秤にかけながら設計を進めることになります。
AIエージェントのアーキテクチャは「記憶をどこに持つか」「テストをどう自律化するか」「処理をどんな粒度に分割するか」という古典的な設計問題の新しい形です。新しい技術が登場しても、トレードオフの本質は変わりません。