Supabase、Dockerなしで動く。AIごとの練習場も

Points

おさえるところ

• Supabaseの公式ブログには「Each coding agent gets its own database to reset, migrate, and test against while the others keep working.」とある。コードを書くAIごとに専用のデータベースを持ち、ほかのAIが作業を続けている間にも、初期化・構造変更・テストができるという意味（筆者の訳）。AIそのものの知能が上がった、という発表ではない
• 注目点は2本ある。「Dockerなしで起動できること」と「ローカルプロジェクトを複数持てること」。この2つを組み合わせることはできるが、選ぶべき環境は同じとは限らない。公式は、同じPCで複数動かす場合には、隔離に強いDockerやPodmanを勧めている
• 今回のネイティブ実行は、Supabaseの各サービスを、対応OS上のプロセスとして直接動かす。コンテナーを動かすエンジンがなくても使える、別の起動方法。従来の一般的なSupabaseのローカル開発では、Dockerを使っていた。「手元で動く」と「どのPCでも動く」は別
• Git worktree（同じリポジトリから作る、別の作業フォルダー）ごとに、ローカルプロジェクトを持てる。一方がデータベースを初期化しても、別のプロジェクトのテストデータは消えない。ただし、アプリがそれぞれ正しい接続先を使っていることが前提。同じフォルダー・同じブランチを使うAIは、同じローカルプロジェクトを共有する
• 新しい仕組みでは、まずデータベースを動かし、そのほかは要求が来てから起動する。初回は標準で有効なサービス一式を取得するため、ネット接続や待ち時間は必要。公式の測定例では、資材が保存済みの起動が、従来37秒、新方式のDockerで5.2秒、ネイティブで3.9秒。待機時のメモリは、従来2.6GiBに対し、新方式の両方で290MiBとしている。これは会社が示した測定例で、私のPCで再現した数字ではない
• 古い設定に固定のポート番号が残っていると、その指定が優先される。「新しい機能をオンにしたのに2つ目が起動しない」というときは、ここを確認する。旧方式と新方式はデータを別に持つので、既存のローカル環境のデータが、そのまま新方式に移るわけではない
• 2026年10月16日確認時点では、ローカル開発自体は無料。公式は、クラウド側のプロジェクトの利用枠を消費しないと説明している。ただし、Supabaseをローカルで動かす費用と、AIに作業を頼む費用は別。今回のローカル環境を起動しただけで、公開サーバーの契約や運用が済むわけではない
• Linuxはamd64・arm64で、Ubuntu 22.04以降、またはglibc 2.35以降などの条件がある。MacはApple silicon搭載で、macOS 14以降が対象。WindowsとIntel搭載Macでは、公式はDockerを使うよう案内している。発表上の導入版はv2.119.0以降で、固定ポート変更の扱いはv2.121.0以降で改善されている
• 実験機能は、新しい練習用フォルダーで「SUPABASE_EXPERIMENTAL_STACK=1 supabase init」と実行して有効にし、「supabase start --runtime native」で起動する。実行方式は、ローカルプロジェクトを作ったときに固定される。Dockerで作成済みのものに「--runtime native」を足しても切り替わらない
• 今回のローカルスタックは、開発用。公式は、本番向けに防御を固めた構成ではないとして、外部からの通信にさらさないよう説明している。「supabase stack destroy」は保存データも削除する操作。データベースが手元にあっても、AIにデータやログを読ませれば、そのAIの利用経路に情報が渡り得る。私は今回、Supabaseの起動や性能測定を行っていない