Question 1

AI SDK 6を使用するときに、withSupermemoryがAI_UnsupportedModelVersionErrorをスローするのはなぜですか？

Accepted Answer

withSupermemory関数はオブジェクトスプレッドを使用して言語モデルをラップしますが、AI SDK 6のモデルはspecificationVersion、provider、modelId、supportedUrlsのような非列挙型/プロトタイププロパティを格納します。スプレッドはこれらをコピーしないため、undefined値が発生しエラーを引き起こします。修正方法：wrapVercelLanguageModel（packages/tools/src/vercel/index.ts）のスプレッドパターンを、'ai'（import { wrapLanguageModel, LanguageModelV3Middleware } from 'ai'）の標準的なwrapLanguageModelミドルウェアアプローチに置き換えてください。一時的な回避策として、ライブラリが更新されるまでwrapLanguageModelを使用したラッパーを手動で実装してください。影響を受けるバージョン：@supermemory/tools@1.4.1、ai@6.0.158、@ai-sdk/provider@3.0.8。

Question 2

esbuild で supermemory SDK v5 をブラウザまたはエッジランタイム向けにバンドルする際に発生する「Could not resolve fs/stream」エラーの修正方法

Accepted Answer

**原因:** supermemory v5.0.0-rc.6 以降（Speakeasy から Fern コード生成への切り替え）、生成されたコアにはリテラルの動的インポートが含まれています — `generated/core/file/file.js` 内の `await import("fs")` と `generated/core/form-data-utils/FormDataWrapper.js` 内の `await import("stream")` です。esbuild のようなバンドラーは、そのコードパスが実行されない場合でも、ビルド時にリテラルの `import()` 指定子を解決するため、ブラウザ/エッジ向けバンドル（Cloudflare Workers、Vercel Edge、Convex のデフォルトランタイム、Vite/esbuild）は、ファイルを一度もアップロードしなくても `Could not resolve "fs"` / `Could not resolve "stream"` で失敗します。

**回避策:**
1. バンドル可能な最後のバージョンに固定します: `npm i supermemory@5.0.0-rc.5`（Speakeasy で生成されたビルドは問題なくバンドルできます）。
2. **Convex:** Convex のデフォルトランタイムは Node API を使用できないため、ファイルの先頭に `'use node'` ディレクティブを追加して、SDK をインポートするすべてのモジュールを Convex の Node ランタイムに移動します。
3. **SDK メンテナー / ローカルでのパッチ適用の場合:** 生成後のパッチ（例: `scripts/generate.ts` 内）を適用し、リテラルの指定子を計算されたものに置き換えて、esbuild がそれらをランタイムインポートとして残すようにします: `import("fs")` の代わりに `import(["f","s"].join(""))`（注意: `const s = "fs"; import(s)` や `/* @vite-ignore */` コメントは機能しません — `--minify-syntax` を指定した esbuild は定数をインライン化し、依然としてそれらを解決します）。webpack にも対応するために `/* webpackIgnore: true */` を追加します。Node は実行時に計算された形式を引き続き解決するため、そこではアップロードも動作し続けます。
4. ビルドされたパッケージをブラウザターゲット向けにバンドルする（`esbuild entry.js --bundle --platform=browser --format=esm`）CI チェックを追加し、解決エラー時に失敗させることでリグレッションを防ぎます。

Question 3

Supermemory SDK の client.fetch() が 'Failed to parse URL' をスローしたり、Authorization header なしで 401 を返したりするのはなぜですか？

Accepted Answer

これは既知のバグ（v5.0.1）で、`client.fetch()` パススルーがデフォルト環境を無視するものです。型付きメソッドとは異なり、`SupermemoryEnvironment.Default` にフォールバックしないため、相対パスには結合先となるベース URL がなく（`Failed to parse URL` がスローされ）、絶対 URL は `Authorization` ヘッダーを付与する認証チェックをスキップするため、401 エラーが発生します。回避策：クライアントの作成時にベース URL を明示的に渡してください：

```js
import { Supermemory } from "supermemory"
import { SupermemoryEnvironment } from "supermemory/environments"

const client = new Supermemory({
  apiKey: "sm_test",
  baseUrl: SupermemoryEnvironment.Default, // または "https://api.supermemory.ai"
})

await client.fetch("/v3/settings") // これで解決され、Bearer 認証が送信されます
```

`baseUrl` が設定されると、相対パスの解決と `targetsBaseUrl` による認証の付与の両方が正しく動作します。恒久的な修正には、生成されたクライアント内でベースを `this._options.baseUrl ?? this._options.environment ?? environments.SupermemoryEnvironment.Default` として解決することが必要です。

Question 4

セルフホスト環境でのドキュメントのupsertにおいて、ファイル中盤への小さな編集後にほぼすべてのチャンクが再エンベディングされてしまうのを防ぐにはどうすればよいですか？

Accepted Answer

これは、チャンクの境界が位置に依存するために発生します。先頭付近での挿入や削除は、それ以降のすべての境界をずらすため、コンテンツハッシュが一致しなくなり、ほぼすべてのチャンクが再埋め込みされてしまいます。末尾への追加は既存の境界をずらさないため、問題なく動作します。

修正方法： PR `fix(chunking): stable content-defined chunking with hash-based reuse planning`（issue #1649 の修正）を含むリリースにセルフホストサーバーをアップグレードしてください。この修正では、安定したコンテンツ定義のチャンキングとハッシュベースの再利用が使用されるため、ファイル中間部の編集ではドキュメント全体ではなく、影響を受けるチャンクのみが無効化されます。

アップグレードできるまでの間は、以下の回避策を使用してください：
1. 可能な場合は、末尾への追加のみによる更新を優先してください。
2. 頻繁に更新される大きなドキュメントは、主要な Markdown 見出しごとに1ファイルとするなど、より小さく比較的安定したドキュメントに分割してください。
3. 頻繁に編集するセクションは、ドキュメントの末尾に移動してください。
4. より高速な埋め込みプロバイダー、GPU アクセラレーション、またはより小さなローカル埋め込みモデルを使用して、避けられない完全な再埋め込みのコストを削減してください。

アップグレード後は、同じ `customId` を使用した後続の `/v3/documents` upsert で、変更されていない下流のチャンクは再埋め込みされずに再利用されるようになります。

supermemory

概要

README プレビュー

FAQ (4)

同类型项目

tensorflow

superpowers

everything-claude-code

flutter