Eidos File は SQLite を単一ファイルの表計算に変える

Eidos File が埋めようとしている穴

表計算ソフトのファイルは、人間には読めてもプログラムからは扱いにくい。逆に SQLite はプログラムからは扱いやすいが、非エンジニアが列を追加したりビューを切り替えたりするには向かない。Eidos File はこの二つの中間に位置する。README は Eidos File を「an open, single-file format built on standard SQLite」と説明しており、独自のバイナリ形式ではなく標準 SQLite を土台に据えている点が重要だ。拡張子は .eidos で、ファイル一つがデータベース一つに対応する。

対象は誰か。README の副題は「for you and your agent」で、人間が表を編集する用途と、エージェントが同じファイルを読み書きする用途を同時に想定している。ローカルフォルダに置いたファイルをデスクトップアプリで開き、同じファイルを CLI から操作する、という流れが README のコマンド例に現れている。Notion 的なリレーショナル表を、アカウントもサーバもなしで持ちたい人向けの設計だ。

リポジトリ構成から見える責務の分割

このリポジトリは単一アプリではなく、複数のパッケージとアプリの集合体だ。README の Repository 節によれば、packages/eidos-file がファイル形式と Runtime を実装し、packages/eidos-file-ui が共有の React エディタ UI を提供する。apps/eidos-lite-desktop がデスクトップアプリ、apps/eidos-file-web がブラウザエディタ、apps/cli がエージェント向け CLI とローカルサーバを含む。apps/sqlite-web-viewer は読み取り専用の SQLite ビューアとして独立している。

この分割は、形式と UI をアプリから切り離す意図を示す。同じ eidos-file-ui をデスクトップとブラウザの両方が使う構成なので、表示ロジックの重複を避けられる。一方で、形式を定義するパッケージと UI を提供するパッケージが別ライセンスになっている点は後述する。

packages/markdown も見落とせない。Lexical ベースの WYSIWYG エディタで、README は「Markdown remains the canonical value」と明記している。保存形式の正はあくまで Markdown テキストで、エディタはその編集と直列化を担う。表のセルに長文を書くときの挙動はこの設計に依存する。

eidos create と eidos serve でファイルを作る

CLI の導入は README に記載されたインストールスクリプトを使う。macOS か Linux では curl でシェルスクリプトを取得して実行し、Windows では PowerShell の irm で同様に実行する。

ファイルの作成と起動は次の形で示されている。

eidos create example.eidos --table Tasks --label-field Title --fields '[{"name":"Title","type":"text"},{"name":"Status","type":"select"}]' eidos serve example.eidos --open

ここから読み取れるのは、テーブル名、ラベルフィールド、フィールド定義を JSON 配列で渡すというインターフェースだ。フィールドには少なくとも text と select の型がある。serve サブコマンドはローカルサーバを立て、--open でそれを開く。エージェントに操作させる場合はこのサーバ経由の経路が想定されていると読める。

デスクトップを使う場合は eidos.space/download から Eidos Lite を入手し、ローカルフォルダを開く。README は「No account is required for local use」と明記しており、ローカル利用にアカウントは不要だ。インストールせず試すなら editor.eidos.space でブラウザから .eidos ファイルを作成、編集できる。

開発に参加する場合の要件は Node.js 22.23.1、Corepack、そして CLI 作業用の Rust stable だ。pnpm install --frozen-lockfile の後、pnpm dev:eidos-lite などで各アプリを起動する。CLI は別ワークスペースで、apps/cli に移動して cargo test --workspace --locked を実行する。

Graft が担う履歴と同期の境界

Eidos Lite はローカルのバージョン履歴と任意の Sync に Graft を使う。README は Graft を「an independent, developer-facing version-control system for application state」と説明し、eidos-space/graft として別リポジトリで開発されていると記す。

ここは採用判断で見落としやすい点だ。ファイル形式そのものは SQLite だが、履歴と同期の層はこのリポジトリの外にある。つまり .eidos ファイルを読むだけなら SQLite の知識で足りるが、変更履歴を追う、あるいは複数端末で同期する挙動を理解するには Graft 側の設計を別途読む必要がある。README は Graft のデータモデルや競合解決の方式には踏み込んでいない。この記事の範囲では、同期がどの単位でどうマージされるかは確認できない。

履歴をアプリ状態のバージョン管理として外に出した判断は、ファイル形式を小さく保つ方向に働く。その代わり、Eidos の履歴機能だけを切り出して別のツールに載せる、という使い方は README からは読み取れない。

AGPL v3 と MIT が同居するライセンス構成

リポジトリ全体は AGPL v3 で、README の License 節は「The repository is licensed under AGPL v3」と述べる。同時に、再利用可能な @eidos.space/eidos-file と @eidos.space/eidos-file-ui の二つのパッケージは MIT で提供されると明記されている。

この境界は実務に効く。AGPL v3 はネットワーク越しに利用させる場合にもソース提供を求める条項を含むため、Eidos Lite や CLI をそのまま自社サービスに組み込むのは慎重に検討すべき領域だ。一方、形式の実装と UI が MIT なら、それらを使って独自のホストアプリを書く道は残っている。ただし README はどのファイルがどちらのライセンスに属するかの一覧までは示していない。個別のパッケージの LICENSE ファイルと、apps 配下のコードがどちらに該当するかを自分で確認する必要がある。ここで法的助言はできない。

ライセンスの話とは別に、AGPL v3 である以上、フォークして改善を非公開のまま配布する形は取りにくい。個人利用や社内利用の範囲では問題になりにくいが、製品化を視野に入れるなら最初に確認すべき項目だ。

向かない場面と、代わりに何を使うか

Eidos File はファイル一つがデータベース一つだ。複数人で同じファイルを同時に開いて編集する運用は、README の記述からは想定されていない。Graft による Sync が用意されているが、その競合解決の粒度は README では説明されていない。リアルタイム共同編集を前提とするチームには、この構成は合わない。

代替として、同じく SQLite を土台に据えるローカルファーストの表計算アプリが複数ある。たとえば Grist はセルフホスト可能なリレーショナル表計算で、ブラウザ経由の共同編集とアクセス制御を中心に据えている。Eidos との違いはアプローチの重心だ。Grist はサーバを立てて複数ユーザーで共有する方向に最適化されており、Eidos は単一ファイルを手元に置いて CLI とエージェントから触る方向に寄っている。どちらが上という話ではなく、共同編集が要件なら Grist 側の設計のほうが素直に噛み合う。

もう一つの選択肢は、素の SQLite ファイルと任意の GUI クライアントを組み合わせる方法だ。拡張子が .eidos であっても中身は標準 SQLite なので、sqlite3 コマンドで読むこと自体は原理的に可能と読める。ただし README はスキーマの詳細や、Eidos 固有のメタデータがどこに格納されるかを説明していない。素の SQLite として開いて安全に書き換えられるかは、docs/specs の仕様を確認しないと判断できない。

採用前に確かめるべき三つの点

第一に、ライセンスの境界を自分の用途に照らして確認する。形式と UI のパッケージが MIT であることは README に書かれているが、それを組み込んだアプリの側がどう扱われるかは別の話だ。

第二に、Graft の同期と履歴の挙動を別途読む。Eidos Lite の履歴機能はこのリポジトリの外にあるので、README だけでは競合時の振る舞いが分からない。複数端末で使う予定があるなら、eidos-space/graft のドキュメントを先に見るべきだ。

第三に、CLI を自前でビルドする必要があるかを判断する。apps/cli は Rust ワークスペースとして独立しており、開発には Rust stable が要る。配布されているインストールスクリプトで足りるなら問題ないが、挙動を変えたい場合は cargo test --workspace --locked が通る環境を用意することになる。

最後に、表のセルに長文を入れる使い方を想定しているなら packages/markdown の仕様を確認したい。Markdown が正の値であり、エディタはそれを編集する層にすぎない。表計算と文書の中間を行く使い方をするなら、この境界が体験を左右する。

編集部の結論

ローカルの SQLite ファイルをそのまま正としたい個人や小規模チーム、そしてエージェントに表データを読ませ書き換えさせたい開発者には向く。複数人で同時編集するクラウド前提のワークフローや、AGPL v3 の伝播を避けたい製品組み込みには向かない。採用前に確認すべきは、packages/eidos-file と packages/eidos-file-ui が MIT で提供される範囲で自分の用途が収まるか、そして apps/cli の Rust ワークスペースを自前でビルドする必要があるかどうかだ。

公式情報源

1. License: AGPL-3.0
2. mayneyao/eidos on GitHub
3. Project website
4. README
5. Releases