Deta Surf: ファイルとウェブを1冊のノートに束ねるローカル優先AIノートブック

Surf が埋めようとしている「タブとクリップボードの往復」という隙間

README の Motivation は、既存アプリの多くがノート、ウェブサイト、PDF のどれか1種類のメディアに最適化されていると指摘する。実際の調べ物は、PDF を読みながらブラウザのタブを開き、動画の該当箇所に戻り、必要な断片をエディタに貼り付ける作業の連続になる。Surf が狙うのはこの往復そのものを減らすことだ。対象は、個人が自分の資料を手元に置いたまま横断的に考えたい場面であり、チーム共有や共同編集のワークフローではない。README の TL;DR には YouTube Notes、PDF Notes、applet 作成、web search 付きノートという4つの試し方が並ぶ。つまり最初から想定されているのは、単一ファイルの要約ではなく、複数ソースをまたいだノート作成である。

SFFS と Electron のあいだでデータがどう流れるか

保存層の中心は SFFS（Surf Flat File System）と呼ばれるローカルストレージエンジンで、README はこれを「open and transparent format」でデータを保存する仕組みと説明している。ライブラリに取り込んだローカルファイル、ウェブのリンク、Surf 内で直接作ったメディアはこの上に載り、Notebooks という単位で整理される。アプリ本体は Svelte、TypeScript、Rust で書かれ、Electron を土台に macOS、Windows、Linux で動く。Rust がどこを担い、TypeScript がどこまでかという境界は README からは読み取れないので、採用判断でそこが重要なら CONTRIBUTING.md のコードベース概説を先に読む必要がある。データの流れとしては、取り込んだメディアがライブラリに入り、Smart Notes がそれを @-mention で参照し、必要なら web search ツールで外部に出て、結果が引用付きでノートに戻る、という循環になる。

Smart Notes の引用と Surflets が担う範囲

Smart Notes は任意のタブやライブラリ内リソースを @-mention で参照でき、自動生成もできる。README が挙げる引用の粒度は具体的で、ウェブページのセクション、動画のタイムスタンプ、PDF のページ単位で元ソースにディープリンクする。要約だけを返して出典が曖昧になるタイプのツールとは、ここが違う。Surflets は「app generation」ツールからコードを書かずに対話的なアプレットを作る機能で、README の用例は概念やデータの可視化、探索だ。ただし生成されたアプレットがどの実行環境で動き、外部依存をどう扱うかは README には書かれていない。コード生成物を自分の環境で動かす以上、生成結果の検証は利用者側の作業になる。ノート側の書式はリッチテキスト、コードブロック、To-do リストに対応し、画像や表の貼り付けも Surf が解釈して取り込むと説明されている。

セットアップで実際に触るファイルと設定

導入手順の本体は docs/INSTALL.md にあり、ソースからのビルドとローカル開発は CONTRIBUTING.md に分かれている。したがって配布バイナリで使うか、リポジトリを clone して自分でビルドするかの2経路があり、後者の手順は README ではなく CONTRIBUTING.md を読むことになる。AI まわりの設定は docs/AI_MODELS.md に集約され、README は「Bring your own key for popular models」「Add a cloud model」「Use Local Language Models」の3通りを示す。つまりノート生成と Surflets の推論は、クラウドの API キーを自分で持ち込むか、クラウドモデルを追加するか、ローカル LLM を動かすかのいずれかに落ちる。キーの保管場所やローカルモデルへの接続方法（Ollama などトピックには挙がっているが、README 本文に具体的な設定キーは書かれていない）は AI_MODELS.md 側で確認する必要がある。ショートカットは docs/SHORTCUTS.md にまとまっている。

ローカル推論を選んだ瞬間に変わる体験

モデル選択の自由度は、そのままマシン性能とのトレードオフになる。ローカル LLM を使えばデータを外に出さずにノート生成ができるが、扱えるモデル規模はハードウェアに縛られる。逆にクラウドモデルを選べば品質と速度は上がるが、ノートに取り込んだ資料の該当部分が推論のために外部へ送られる。README はこの境界について、どのデータがどの経路で送られるかを明示していない。プライバシーを理由にこのツールを検討するなら、AI_MODELS.md を読んだうえで、自分が使うモデル経路ごとに何が送信されるかを実際に確認する作業が残る。もう一点、対応モデルとして claude、deepseek、gemma、ollama、openai といったトピックが並ぶが、それぞれの接続方式や必要キーの種類は README からは分からない。

Obsidian や NotebookLM と何が違うのか

ノートツールとして近い位置にあるのは Obsidian だ。Obsidian は Markdown ファイルの集合を Vault として扱い、ノート間のリンクとプラグインで機能を足す。Surf は Markdown の編集環境ではなく、PDF、動画、ウェブページといったメディアをライブラリに取り込み、それを LLM に読ませてノートを生成する側に重心がある。既存の Markdown 資産をそのまま持ち込みたい人には Obsidian のほうが素直だ。クラウド型では NotebookLM が近いが、あちらは資料をアップロードして質問するモデルで、ローカルファイルを手元の形式のまま保持する設計ではない。Surf の差分は SFFS によるローカル保存と、モデルを差し替えられる点に集約される。ただし SFFS がどの程度プレーンな形式に近いかは docs/LIBRARY.md を読まないと判断できず、README の「open and transparent」という表現だけでは、他ツールでの再読み込みが容易かどうかまでは分からない。

Apache-2.0 と、名前だけが対象外という但し書き

ライセンスは Apache-2.0 で、例外が2つ明記されている。1つは @ghostery/adblocker-electron へのパッチで、上流に合わせて MPL-2.0 が適用される。もう1つは個別のファイルに独自のライセンスヘッダがある場合で、その場合はそちらが優先される。加えて、Deta の名称とロゴは Apache-2.0 の対象外と明記されている。フォークして配布する場合、コードは Apache-2.0 の条件に従いつつ、名前とロゴは使えないという整理になる。ここから先は法的助言ではないが、社内配布や再配布を計画するなら LICENSE と各ファイルのヘッダを確認する作業は省略できない。

更新頻度と、追随コストをどう見るか

リポジトリはアーカイブされておらず、最終 push は 2026-08-24。直近のリリースは 1.4.7-beta.0 系で、2026-04-25 の rc.0、04-29 の rc.1、同日の beta.0 と、ベータ表記のビルドが続いている。安定版の番号はここからは確認できない。デスクトップアプリであり Electron と Rust を含む構成なので、ソースからビルドして追随する場合、Node 側と Rust 側の両方のツールチェーンを保守することになる。配布バイナリを使うならこの負担はないが、ベータ由来のビルドを業務の中心に置くかどうかは別の判断になる。CONTRIBUTING.md にはコードベースの概説があると README が案内しているので、フォークして手を入れる前提なら、まずそこを読んでから自分の改修範囲が Svelte 側で完結するのか Rust 側に及ぶのかを見極めるのが現実的だ。

編集部の結論

自分が調べた素材を手元に置いたまま、複数モデルを使い分けてノート化したい個人研究者やエンジニアには向く。逆に、チームでの同時編集やクラウド同期を前提にした運用、モバイルからの閲覧を主目的にする使い方には合わない。導入前に確認すべきは、docs/INSTALL.md の手順が自分の OS で通ること、docs/AI_MODELS.md に記載されたモデル接続方法（自前キー、クラウド追加、ローカル LLM）のどれが自分の環境で動くか、そして SFFS ディレクトリの実体を開いて中身が読める形式で保存されているか、の3点だ。

公式情報源

1. deta/surf on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases