Pixeltable: 変換を計算列として扱うマルチモーダル基盤

Pixeltable が畳もうとしている 4 つの層

README の冒頭はこう宣言する。データベース、オーケストレーション、サービングの 3 層を 1 つの Python ファイルにまとめる、と。具体的には、画像・動画・音声・文書がテーブルに格納され、変換は計算列（computed column）になり、インデックスは宣言、HTTP ルートもまた宣言になる。行を 1 つ挿入すれば、その下流にある処理がまとめて走る。

対象読者は、マルチモーダルの前処理と推論を本番に載せようとしている Python エンジニアだ。典型的には、オブジェクトストレージに素材を置き、別プロセスのオーケストレータが特徴量を計算し、ベクター DB に書き込み、FastAPI のエンドポイントがそれらを繋ぐ、という構成を組んだ経験がある層を想定している。README はその構成を「オブジェクトストレージ、ベクター DB、オーケストレータ、そしてそれらの間をコピーするエンドポイントコード」と列挙し、それが 1 つのアプリケーションファイルに collapse すると表現する。

ここで注意したいのは、Pixeltable が汎用のワークフローエンジンではない点だ。変換の単位はあくまでテーブルの列であり、実行の起点は行の挿入か更新である。DAG を自由に組める仕組みではなく、テーブルスキーマに処理の依存関係を埋め込む設計だと言える。

計算列と udf が処理グラフになる仕組み

README に載っているサンプルが仕組みを最もよく示している。pxt.model_base() で基底を作り、その派生クラスとしてテーブルを定義する。クラス属性のうち型注釈として書かれたもの（doc_id: pxt.Int、title: pxt.String）は挿入する値であり、代入として書かれたもの（title_upper = pxtf.string.upper(title)）は計算列になる。計算列は挿入時と更新時の両方で評価される、と README は説明している。

もう 1 つの要素が @pxt.udf デコレータだ。サンプルでは excerpt という Python 関数を udf として登録し、summary = excerpt(title) という計算列から呼んでいる。つまり、組み込みの pixeltable.functions（pxtf.string.upper など）で足りない処理は、自分で Python 関数を書いて列の定義に直接埋め込める。

データフローとしては、行の挿入がトリガとなり、その行に依存する計算列が評価され、結果が保存される。README の curl 例では、POST した本文に対して title_upper と summary の 2 つが返っている。パイプラインの途中結果を別ジョブとして管理するのではなく、テーブルの状態として保持する設計だ。この点は、再計算の範囲を列単位で制御できるという意味で、ジョブ単位のオーケストレータとは発想が異なる。

導入手順: pxt init から schema update、service update まで

README が示す最短経路は次のとおり。pip install 'pixeltable[serve]' でインストールし、pxt init で初期化する。次に pxt service example --out app.py でサンプルのアプリケーションファイルを生成し、pxt schema update app.py my_app でカタログ my_app とそのテーブルを作成、pxt service update app.py my_app で HTTP を起動する。

ここで README が明示的に警告しているのが役割分担だ。pxt schema update はカタログとテーブルを作るが HTTP は起動しない。pxt service update は HTTP を起動するがテーブルは作らない。この 2 つを混同すると、ルートを叩いてもテーブルが存在しない、あるいはテーブルはあるがエンドポイントが立たないという状態になる。

ポートは固定値ではなく割り当てられるため、README は pxt service list --json の結果から endpoint を読み出す例を示している。curl で POST /docs に JSON を送ると、計算列の結果が返る。JSON のキーは title_upper と summary で、列名がそのまま出力名になっている。

Cloud を使う場合の手順も README にある。ダッシュボードで API キーを作成し、PIXELTABLE_API_KEY を設定、pixeltable.toml でデータベース名を指定したうえで、pxt://org:mydb のような URI で対象を指定する。pxt db update はホスト側のデータベースを作成または更新するが行の挿入は行わない。また pxt service run はローカル専用であり Cloud を対象にできないと明記されている。

エージェントとスターターキットの位置づけ

Pixeltable はコーディングエージェント経由の利用を強く想定している。README は get-started.md をエージェントに渡すよう指示し、そのプレイブックがパッケージ、スキル、MCP をインストールすると説明する。スキルは npx skills add pixeltable/pixeltable-skill で追加する。

ここにはバージョン由来の落とし穴が明記されている。スキル 2.8.0 以降は app.py に TableModel を書き、エージェントがアプリケーションコード内で create_table を出力したならインストール済みスキルが古いので再インストールせよ、という指示だ。ノートブックとテストは今も pxt.create_table() を使うが、アプリではテーブルを app.py に置き pxt schema update で作成する、という使い分けになっている。

uvx pixeltable-new myapp はスターターキットからアプリを 1 つコピーする。既定はチャットアプリで、pxt schema update app.py agent のように最後の引数で種類を選ぶ。--video なら動画検索、引数は videointel になる。ナレッジテーブルへの挿入に API キーは不要だが、/ask ルートには ANTHROPIC_API_KEY が必要、という条件も README に書かれている。

FastAPI に載せ替える場合と、エンドポイントを省く場合

既存の FastAPI アプリに組み込みたい場合、README は app.include_router(...) でルートをマウントする方法を示している。Pixeltable が独自のサーバを強制するわけではなく、FastAPIRouter を経由して既存のアプリケーションに相乗りできる。

逆に HTTP を一切公開したくない場合は、pxt schema update を実行して Python から行を挿入し、その後 export_sql する、という道筋が README に書かれている。この場合、サービング層は使わずデータベースと計算列だけを利用することになる。セルフホスティングの選択肢についてはドキュメントの deployment/overview へのリンクのみが示されており、README の範囲では具体的な構成までは分からない。

この 2 つの経路は排他ではないが、設計思想の違いが出る。ルータをマウントする場合、計算列の評価は HTTP リクエストの処理中に走る。export_sql で外に出す場合、計算はバッチ側の責務になる。どちらを選ぶかで、レイテンシとスループットの性格が変わる。

向かないケースと制約

第一に、Pixeltable はテーブル中心の設計であり、任意の DAG を組むワークフローエンジンではない。分岐やリトライ、複数テーブルをまたぐ複雑な依存関係を細かく制御したい場合、計算列という抽象は窮屈になる。README のサンプルにあるのは単一テーブル内の列依存であり、それを超える構造については README からは読み取れない。

第二に、Cloud 利用には制約がある。README は Pixeltable Cloud が Limited Beta であると冒頭で述べており、利用には contact@pixeltable.com への問い合わせが必要とされている。さらに pxt service run はローカル専用で Cloud を対象にできない。Cloud を前提にした開発フローを組む場合、この非対称性は考慮に入れる必要がある。

第三に、エージェント経由の開発はスキルのバージョンに依存する。前述のとおり、スキルが古いと create_table を出力してしまい、アプリの流儀と食い違う。README がわざわざこの症状を名指ししているのは、実際に起きやすいからだと推測できる。

第四に、ドキュメントの本体は docs.pixeltable.com にあり、README はその入口として機能している。たとえばセルフホスティングの具体的な構成や、pxt db update が何を変更するのかの詳細は、この記事の材料からは確認できない。採用判断の前に本体ドキュメントを読む必要がある。

代替手段との違い: Postgres とベクター DB を自分で繋ぐ場合

最も近い比較対象は、Postgres に pgvector を入れ、前処理は別ジョブ、HTTP は FastAPI で書くという、よくある自前構成だ。この構成の利点は、スキーマも権限もバックアップも既存の運用に乗ることで、SQL エコシステムのツールがそのまま使える。欠点は、前処理ジョブと DB の間、DB と API の間を自分で繋ぐ必要があり、計算結果の整合性を保つ仕組みも自分で書くことになる点だ。

Pixeltable はこの後半部分を引き受ける。計算列は挿入と更新の両方で評価され、udf を列定義に直接書けるため、「この列はこの関数から導出される」という関係がスキーマに残る。前処理のコードとスキーマが同じ app.py に同居するので、両者がずれる余地が小さい。

ただし、これは Postgres を置き換えるという話ではない。README には export_sql という記述があり、計算結果を SQL として外に出す経路が用意されている。つまり既存の SQL ベースの分析基盤と併用する前提だと考えられる。どちらかを選ぶというより、前処理とサービングの層を Pixeltable に寄せるかどうか、という判断になる。

メンテナンスとライセンスの確認点

ライセンスは Apache-2.0。README の末尾にも明記されており、バッジも Apache 2.0 を示している。商用利用や改変、再配布に関する条件は Apache-2.0 の条文に従う。ここでは法的助言はできないので、自組織のポリシーと照らし合わせる必要がある。

リリースの頻度は材料から読み取れる。v0.7.6 が 2026-09-09、v0.7.5 が 2026-09-03、v0.7.4 が 2026-09-02 と、直近 1 週間で複数のパッチリリースが出ている。0.x 系であり、API の安定性よりも開発速度を優先している段階だと判断できる。アップグレードコストを見積もる際は、この粒度のリリースが継続する前提で、pxt schema update でスキーマを再適用する手順がどの程度自動化できるかを確認しておきたい。

CI については pytest、nightly、stress-tests の 3 つのワークフローバッジが README に並んでいる。テストが継続的に走っていることは分かるが、その中身やカバレッジはこの材料からは評価できない。採用前にリポジトリの workflows ディレクトリを直接確認することを勧める。

編集部の結論

採用を検討すべきなのは、前処理と推論を別々のジョブに分け、その間をオブジェクトストレージとベクター DB がつないでいる構成に疲れているチームだ。逆に、既存の Postgres スキーマと権限管理をそのまま使い続けたい場合や、HTTP を一切公開せずバッチ処理だけを回したい場合は、Pixeltable の宣言的サービング層は荷が重い。導入前に確認すべきは、pxt schema update と pxt service update の役割分担（前者はカタログとテーブルを作るが HTTP は起動せず、後者は HTTP を起動するがテーブルは作らない）、および pxt service list --json で返る endpoint をアプリ側でハードコードしていないか、の 2 点である。

公式情報源

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