Deuz SDK: セッションをまたぐ記憶と耐久実行を1パッケージに収めたTypeScriptエージェントランタイム

モデル呼び出しの外側で何が壊れるか

READMEは冒頭でこう書いている。「モデルを呼ぶことは解決済みの問題だ。解決していないのはその周辺のすべてだ」と。具体的には、セッションをまたいでユーザーを覚えること、40ターン目でコンテキスト窓に収めること、不可逆な操作の前に人間に確認すること、実行途中でプロセスが死んだ後に再開すること、OAuthを手書きせずにツールサーバーへ繋ぐこと。Deuz SDKはこの5つを、generateTextのオプション引数として同梱する。対象読者は、LangChain的な抽象を重ねずに、TypeScriptの型と自分のデータベースの上でエージェントを組みたい開発者だ。

記憶はメッセージ配列ではなく抽出・照合パイプライン

READMEが「他のどこも出していない2つ」の1つ目に挙げるのが記憶だ。会話から永続的な事実を抽出し、既に知っている内容と照合して add / update / delete のいずれかに振り分ける。盲目的な追記はしない、と明記されている。重要度をスコアリングし、期限切れにし、次回の呼び出しで関連するものだけを引き戻す。保存先はベクターストア、Postgresのテーブル、Obsidianのvaultのいずれか。設定は generateText の memory キーに渡し、seams に store と embedder と llm、scope に userId、recall に topK と maxChars と expandLinks、writePolicy に 'each-turn' を指定する形が例示されている。ここで注意したいのは、照合を担う llm を別途渡す必要がある点だ。記憶の書き込みごとにモデル呼び出しが発生する設計であり、無料の機能ではない。

コンパクションは積み上げずに1ブロックを更新する

2つ目の目玉がコンパクションだ。窓が埋まると、古いツール出力を剪定し、古い推論を落とし、最も早いターン群を1つの走り続ける要約に畳む。要約はスタックとして成長するのではなく、1ブロックが更新され続ける。READMEが挙げるのはもう一段踏み込んだ挙動で、プロバイダが長すぎるとしてリクエストを拒否した場合、ループは強制的にコンパクションしてそのステップを再試行し、実行全体を失敗させない。有効化は compaction: 'auto' を generateText に渡すだけだ。ただし要約への畳み込みは情報の不可逆な圧縮であり、畳まれたターンの原文が後から必要になる場面では効かない。監査目的で全履歴を保持したい用途には向かない。

注入された依存がランタイムを選ばせる

設計ルールとして READMEが最も強く押し出しているのは、時計・乱数・fetch・キー・ログをすべて注入し、周囲の環境から暗黙に取らないという方針だ。これにより同じコードがNode、Bun、Deno、エッジで動き、テストが決定的になる。代償は明白で、何もかも自分で配線する必要がある。Node ≥ 22 が前提。オプションのpeerは使うときだけ入れるもので、zod（またはStandard Schema準拠ライブラリ）、@modelcontextprotocol/sdk、react、pg / redis、unpdf / mammoth / xlsx、playwright、@opentelemetry/api が列挙されている。実行時依存はゼロ。インストールは npm install @deuz-sdk/core、UIが必要なら npm install @deuz-sdk/react。エージェントにAPIを教える用途として npx skills add Deuz-AI/Deuz-SDK で2つのAgent Skillsを追加できるとREADMEは説明している。

正規化されたデルタストリームという一本の土台

コードの大部分を説明する設計ルールがもう1つある。プロバイダのバイト列を先に正規化されたデルタストリームへ変換する、というものだ。この正規化を通すことで、リトライ、フェイルオーバー、再開、予算、サブエージェント、型付きUIイベントが同じ言語を共有できる、とREADMEは述べている。streamChat は同期的に返り、決してthrowしない。失敗は型付きのストリームパーツとして届く。この契約はエラーハンドリングの書き方を変える。try/catchで囲む代わりに、ストリームを読み切ってパーツの種類を見る形になる。28のチャットプロバイダを4つのwireで扱うという記述も、この正規化層があってこその数字だ。

チェックポイントはワークフローベンダーではなく自分のDBに置く

クラッシュに耐える実行は、ステップのチェックポイントを自分のデータベースに書き、後から resumeFromCheckpoint で再開する。READMEはこれを「ワークフローベンダーなし」と表現している。セッションとトランスクリプトは同じ接続に載せられ、例では createPostgresStores({ connectionString }) で得た stores を chat と session の両方に渡している。SQLite、Redis、Postgresのパックが memory、chat、session、run の各seamの背後に用意されている。人間の承認は needsApproval を任意の深さに置け、HMAC署名付きの有効期限トークンを使い、判定が欠けていれば拒否に倒れる。ガードレールは入力、各ツール呼び出し、最終回答の3箇所に掛けられ、pass / block / rewrite を返す。

向かないケースと、代わりに検討するもの

このフレームワークが過剰になる境界ははっきりしている。1回の呼び出しでテキストを生成して終わり、記憶も再開も承認も要らないなら、注入を強制する設計はただの配線作業になる。その場合はVercel AI SDKのほうが素直だ。README自身が from-vercel-ai-sdk という移行ガイドを用意しており、migrate-from-ai-sdk スキルは ai と @ai-sdk/* からの名前単位の移植を扱うと説明されている。つまり著者らはVercel AI SDKを前段として想定している。アプローチの差は、Vercel AI SDKがプロバイダ抽象とUIフックを中心に据えるのに対し、Deuzは記憶の照合、コンパクション、チェックポイント再開という実行の継続性を中心に据える点にある。ワークフローエンジンを既に運用していて、再開をそちらに任せているチームにとっては、責務が重複する。

ライセンスと更新の追い方

ライセンスはMIT。npmのライセンスバッジもMITを指している。MITは著作権表示と許諾表示を残せば商用利用を含めて自由に使えるが、これは法的助言ではなく、実際の適用は自組織の判断による。更新の追跡は packages/core/CHANGELOG.md と docs/content/docs/reference/whats-new-2-0.mdx が入口になる。リリースは v1.8.0（Autonomous Agent Runtime）、v1.9.0、v2.0.0 と短期間に続いており、メジャーが上がった直後である点は導入時期の判断材料になる。READMEが説明するAgent Skillsは、バージョンや固定されたAPI契約が動いた時点で鮮度チェックが失敗する仕組みだとされている。エージェントにコードを書かせる運用なら、この鮮度チェックが効いているかを最初に確かめるとよい。

編集部の結論

採用を検討すべきなのは、ユーザーをセッション横断で覚え、窓が埋まったら要約に畳み、プロセスが落ちたら途中から再開する、という3点を自前で作り直したくないチームだ。逆に、単発のプロンプト呼び出しや、モデル出力を一度きり画面に流すだけの用途には過剰で、依存ゼロの代わりに注入を強いる設計コストだけが残る。導入前に確認すべきは、memory.seams に渡す store と embedder を自分の環境で用意できるか、compaction: 'auto' が要約を書き戻す先の挙動、そして runtimeContext に載せた値がどこまで伝播するかの3点だ。

公式情報源

1. Deuz-AI/Deuz-SDK on GitHub
2. License: MIT
3. Project website
4. README
5. Releases