ハクソク

世界を動かす技術を、日本語で。

AIコーディングアプリのためのバックエンド「Instant 1.0」

30日前原文(instantdb.com)

概要

Instant 1.0 が4年の開発期間を経てリリース。 AIコーディングエージェント向けのフルスタックアプリ構築基盤 として、完全オープンソースで提供。 無制限アプリ作成・リアルタイム同期・多機能サービス が標準搭載。 マルチテナントDB（Postgres）とClojure製同期エンジン による独自アーキテクチャ。 開発効率とユーザー体験の両立 を実現した新世代バックエンド。

Instant 1.0リリースと特徴

  • Instant 1.0 は、AIコーディングエージェントがフルスタックアプリを構築できる オープンソース基盤。
  • 無制限のアプリ作成 が可能。アプリは一切フリーズしない設計。
  • リアルタイム同期エンジン を搭載し、オフライン動作や高速なユーザー体験を実現。
  • 認証・ファイルストレージ・プレゼンス・ストリーム など、一般的なSaaS機能を標準装備。
  • APIやCLI経由で完全プログラマティック操作 が可能。エージェントによる自動アプリ構築も容易。

無制限アプリ作成の仕組み

  • 従来のVM型と異なり、 マルチテナントDB 上で数行のレコード追加のみで新規プロジェクトを生成。
  • 非アクティブ時はリソース消費ゼロ、アクティブ時も数KBのRAMのみ消費。
  • VMのような数百MBのオーバーヘッドが発生しない 効率設計。
  • 即時に独立したバックエンドを提供、数百ミリ秒でセットアップ完了。

リアルタイム同期エンジン

  • マルチプレイヤー・オフライン・高速UI を実現するための独自同期エンジンを標準搭載。
  • IndexedDB によるローカルキャッシュと DatalogベースのTriple Store を採用。
  • クライアントSDK がローカルでクエリ解決・楽観的更新を担当。
  • Clojure製バックエンド がリアルタイム同期・権限管理・追加サービスを一元管理。
  • Postgres をマルチテナントTriple Storeとして利用、App IDで論理分離。

追加サービスの統合

  • ファイルストレージ ：ファイルもDBの行として管理、リアルタイム連携やCASCADE削除対応。
  • 認証（Auth） ：Magic Codes、OAuth、ゲスト認証に対応。ユーザーもDBの行として一元管理。
  • プレゼンス・ストリーム ：オンライン状態やデータストリームも標準機能。
  • 複数サービスの統合管理 により、複雑な同期や複数ソース管理が不要。

プログラマティックな操作性

  • API/CLIを通じてアプリ・スキーマ・権限設定が自動化可能。
  • エージェントによる 自動アプリ生成・機能追加 が容易。
  • npx create-instant-app 等のコマンドで主要フレームワークへの即時導入。

アーキテクチャの詳細

  • クライアントSDK ：オフライン対応・楽観的更新・IndexedDBを活用したTriple Store実装。

  • Clojureバックエンド ：リアルタイム同期・権限・ストレージ等のサービスを統合管理。

  • Postgres ：マルチテナントTriple Storeとして利用、アプリごとに論理分離。

    • IndexedDB ：Web標準のローカルストレージを活用、数十MBのデータ保存が可能。
    • Triple Store ：エンティティ・属性・値の三つ組でデータを管理、柔軟なリレーショナルクエリを実現。
    • Datalog ：ロジックベースのクエリエンジン、シンプルかつ強力なクエリ記述を可能に。

Instantの価値

  • 現代的なアプリ（Linear, Notion, Figma等）に求められる同期・オフライン・マルチプレイヤー機能を標準化。
  • 開発者・ユーザー・AIエージェントすべてにとっての生産性と体験向上。
  • オープンソース であり、コミュニティ主導の発展も期待。

Instant 1.0は、 AI時代のアプリ開発の新しい標準 となるべく設計された、 リアルタイム・多機能・高効率 なバックエンド基盤。 開発者・AIエージェント・エンドユーザー の全てに新しい体験を提供。

Hackerたちの意見

実際に「リレーショナルクエリ && リアルタイム」の約束を実現してるのはすごいことだね。ただ、コンソールは他のインフラやウェブサイトほど愛されてない感じがする。1.0のローンチおめでとう！これからもInstantを使ってどんどん作っていくのが楽しみだよ。

└

ありがとう！ホームページのデモ、エッセイページ、ドキュメントのアップグレードにかなり時間をかけたよ。次の数週間でダッシュボードを再設計する予定。ユーザーからの興味深い観察があって、ダッシュボードはある意味であまり使われてないけど（AIエージェントがアプリを立ち上げたりスキーマを変更したりするから）、他の方法ではもっと使われてることがわかったんだ。InstantにはデータをクエリできるExplorerコンポーネントが付いていて、ユーザーはそれにもっと関わりたいみたい。

これ、ほんとに必要なのかな？FigmaやLinearみたいなマルチプレイヤーアプリを作ってる人ってどれくらいいるんだろう？99%はCRUDだと思うし、これが変わるとは思えないな。仮にそうだとしても、試験済みのオープンソースコンポーネントを使うより、独自の技術にロックインされたくないんじゃない？

└

ちなみに、Instantは100%オープンソースだよ！ https://github.com/instantdb/instant

└

FigmaやLinearみたいなマルチプレイヤーアプリをほんとに作ってる人ってどれくらいなんだろう？これについては2つの驚きがあると思う。1. アプリをマルチプレイヤーにするのがもっと簡単だったら、もっと多くのアプリがそうなってたと思う。例えば、Linearがマルチプレイヤーである必要がある理由がわからないけど、他のCRUDアプリはそうじゃない。2. 抽象化がうまくいけば、同期エンジンを使ったアプリ作りは従来のCRUDアプリを作るよりも簡単なんだ。Linearチームもここで言ってたよね。 https://x.com/artman/status/1558081796914483201

└

うん、なんとなく同意する。今やほとんどのコードはLLMが書いてるから、 fancyな技術の必要性は以前より低くなってるよね。古典的なCRUDアプリはAIにぴったりだと思う。シンプルで繰り返しが多いし、AIはSQLが得意だから。バックエンドはバイナリで、フロントエンドはReactを使えば、99.9%のユースケースをほぼゼロのリソースでカバーできる。5ドルのノードで10万MAUも余裕で処理できるよ。

これめっちゃクールで、個人プロジェクトにぴったりだと思う。試してみたいけど、「エージェント」部分がもう少しスムーズだといいな。私のコーディングエージェントはこれをどうやって使うか知ってるの？このためのスキルを含めるか、ブログにリンクがあるならそれを教えてほしいな！

└

スキルはあるよ！npx skills add instantdb/skills プロジェクトをスキャフォールドするために bunx/pnpx/npx create-instant-app を使うのもおすすめだよ！

└

いいアイデアだね！エッセイを更新しておいたよ： https://github.com/instantdb/instant/pull/2530 数分後には公開されるはず。

正直な疑問なんだけど、バイブコーディングされたアプリにフレームワークって必要なの？フロントエンドは純粋なHTML5/バニラJS/CSSを使うようにコーディングエージェントに指示すればいいし、バックエンドも同様にやらせればいい。何百、何千もの依存関係なんていらないよ。デプロイも同じように頼めばいいし。

└

いくつか理由があるよ：1. 無制限のプロジェクト：従来のバックエンドを立ち上げるときは、通常はVMを使うけど、たくさん立ち上げるのは高くつくんだ。Instantなら無制限にプロジェクトを作れる。2. ユーザー体験：従来のCRUDアプリは動くけど、あんまり楽しくないよね。マルチプレイヤーやオフラインモード、楽観的更新みたいな機能をサポートしたいなら、もっとカスタムなインフラを書く必要がある。Instantはこれをすぐに使える状態で提供してくれるし、エージェントもCRUDコードより書きやすいって言ってるよ。3. よりリッチな機能：時にはバックエンド以上のものを追加したくなることもある。たとえば、ファイルを保存したり、カーソルを共有したり、トークンをマシン間でストリーミングしたり。これらはしばしばもっと特注のシステム（S3、Redisなど）が必要になる。Instantはこれらもすぐに使える状態で、エージェントも使い方を知ってる。投稿にはこれを示すデモセクションもいくつかあるよ。たとえば、ボタンをクリックするだけでバックエンドが手に入るし、サインアップも不要。約25行のコードでリアルタイムのTODOアプリが作れるんだ。

└

人間がする理由と同じだよ。コンテキストと抽象化。

└

必要ではないけど、AIが出力するのにトークンがかかるからね。それが後で入力として使われるときは、もっとお金がかかるかも。ライブラリに委任するのは経済的に理にかなってるよ。

└

実際にこれを試してみた経験から言うと、現在のLLMは基盤となるフレームワークがあると大きく恩恵を受けるね。コンテキストウィンドウにコードが増えると、コストが上がるだけじゃなくて、LLM全体のパフォーマンスも悪化するんだ。ミスが増えたり、バグが出たり、余計な抽象化が増えたり、全体的に効率の悪いコードを書いたりするようになる。結局、AIに良いフレームワークを書くように指導するのにかなりの時間を費やすことになるから、その時点でトレーニングセットに含まれている既存のフレームワークを選んだ方が良かったってことになるかも。将来のLLMはここでうまくやるかもしれないけど、今のモデルでランディングページ以上のものを作るのはおすすめしないな。

└

アセンブリでコーディングするのはどう？冗談だけど、アプリ開発にも当てはまる理由があるよね。1. 良い抽象化は冗長性を減らして理解を深める 2. 生のHTML/CSS/JSはアセンブリと同じように流通外（こんな風にアプリを作る人はいない） 3. 人間はそれを理解して監査する必要がある 4. 車輪を再発明するのに時間とトークンを無駄にすることになる これは直感的に理解できるよね。LLMは人間の行動や思考を模倣するから、ウェブのスパゲッティやx86の中で迷子になる理由と同じで、LLMも迷子になるんだ。

└

他の意見にも同意だけど、最初の10,000行以上の出力コードを0トークンコストで、しかもプロンプトの手間もなく、やり取りやテストもなしで手に入れるようなもんだよ。ビジネスロジックにすぐに飛び込めるし、足場はもうできてる。あなたの質問の中にも、これからのアプリはオーダーメイドで小さくてユニークな存在になるっていう考えがあると思うけど、実際にはまだ解決済みの問題をほとんど解決しているし、エンタープライズソフトウェアは以前と同じように巨大なコードベースを必要とするんだ。フレームワークの本当の利点は、AIでも人間でも、既存のツールやパターンのセットに制約を与えることだよ。これは長期的なAIプロジェクトでも重要だし、思いもよらないエッジケースをカバーする、実績のある解決策のコレクションを提供してくれる。

└

それは組み込みのガードレールだね。知っておくべきコンテキストを減らす可能性もあるし、スケールするための非常に良い方法でもある。xのために非常に小さくてよくテストされたライブラリを作ろう、LLMはケースyのためにxを使う。xやその内容、セキュリティについて心配する必要はない。

└

これは適合性よりも、それが引き出す知識の体にもっと関係していると思う。パターンを「オフ・ザ・シェルフ」でより簡単に実装するためには、バニラの状態を保つのにもっとトークンを消費するんじゃないかな。

└

シンプルだよね。管理しなきゃいけない範囲を減らして、その責任をフレームワークに移す感じ。いいフレームワークを選べば、何千もの決定や将来のメンテナンスの手間を省けるよ。フレームワークが存在するのは、スケールするからなんだ。

└

バリデーションについてだけど、すでに検証済みのコンポーネントを使ってるから、LLMに頼って作らせたり、検証させたりしなくて済むんだ。

発表おめでとう！InstantDBは使ってて楽しいよ。正直、小さなトイプロジェクトしか作ったことないけど、私のお気に入り。今まで試した中で一番シンプルだし。コア製品がすごく良いから、AIの強調がちょっと変に感じる。これがマーケティングだけで、ピボットじゃないことを願ってる。最近は資金調達のためにそうしなきゃならないのは残念だね。

└

ありがとう！ > AIの強調 それはマーケティングでもピボットでもないんだ。ほとんどのユーザーがAIでコーディングしていることに気づいて、それに最適化しているだけなんだよ。

└

ありがとう！私たちのウェブサイトは2024年8月にオープンソース化したときに最後に更新したよ。 https://news.ycombinator.com/item?id=41322281 あの頃は、ほとんどの人がAIを使って本格的なアプリを作ってなかったんだ。それ以来、AIでアプリを作るコンテンツを通じて多くの人が私たちを見つけてくれた。以前のメッセージングはそれに合っていなかったから、リフレッシュする時だと思ったんだ。それに、Instantのエージェント体験を楽しいものにするためにたくさん投資したよ！

リアルタイムの同時更新のための競合解決、どうやって解決するの？私はこの問題を解決するためにCRDTを使ってるけど、ほとんどのマルチプレイヤーデータベースサービスは実際にはこれを正しく処理していないみたいで、最後の書き込みが勝つ方式を使ってるね。

└

属性レベルでLWWを使ってるから、競合がかなり減るんだよね。確かに、別のCRDTが必要な場合もあるけど、これで多くのユースケースにはバッチリだよ。Figmaにもね！

もし私の理解不足が原因ならごめんね。でも、なぜ「AIコーディング用」なの？誤解しないでほしいけど、アプリのシンプルなバックエンドを探しているときに、これは別の素晴らしい選択肢に見える。でも、私が理解できていないのは、何が「AIコーディング」に特化しているのかってこと。少なくとも、他のバックエンドと比べると、TSに特化しているように見えるけど、（ネイティブ）モバイルプラットフォーム用のドロップインバインディングを用意する予定はあるの？

素晴らしいデモだね。AIのフックは素晴らしいけど、説明が足りない。アシスタントを使ってすぐに始める方法についての段落を期待してたんだけど（編集： https://www.instantdb.com/tutorial これがそれに該当するみたいだけど、SaaSの使用とアカウント作成に焦点を当ててるね）。Triples、Datalog、Clojureに収束していく非常に反応的なアプリを見るのは楽しい。Clojureにはあまり親しみを感じなかったし、Datalogはちょっと変わってると思うから、Instantの抽象化は大歓迎だよ！InstantQL-Datalogの翻訳者は別のコンポーネントとして使えるようになるだろうし、これは私にとって超便利だね。全体的に、これは多くのことがうまくいっているように聞こえる。私が求めていたものに非常に近い感じがする。Postgresを選んだ理由は、これが主にSaaSに焦点を当てているからだと思う。バックエンドがClojureのときはあまり関係ないかもしれないけど、SQLiteのような組み込みデータベースならローカルにデプロイするのが少し簡単になるかも。

「事前定義されたパターンがトークンコストを削減する」という考え方、すごく共感できる。empla.ioを作ってるときも同じことを感じたよ。バックエンドの決定をエージェントに任せると、コミットする前にトークンを3倍から4倍消費しちゃった。逆説的なのは、宣言型クエリ言語が人間よりもトークンを節約できるってこと。エージェントは命令的な制御フローを一歩ずつ計画する必要がないからね。インスタントチームに2つのオープンな質問があるんだけど、エージェントがセッション中に新しいリレーションが必要だと判断したとき、スキーマの進化をどう扱ってるの？それがまさにSupabaseがうまくいかないところなんだ。それと、セッションごとにコスト予算のプライミティブを公開してるの？それともユーザーが別にそれを設定しなきゃいけないの？

これ、めっちゃクールだね！前にPocketbaseを似たような目的で使ったことがあるけど、唯一の欠点はローカルファーストじゃないことかな（ちょっと残念）。でも、すごく価値のある機能があって、サーバーの拡張性があるんだ。JSやGoでサーバーハックを書いて、必要な機能を追加できるよ。例えば、前のプロジェクトでは特定のユーザーアクションに基づいてプッシュ通知を送る機能を追加したんだ。InstantDBでもこういうことできるのかな？それとも、そういうイベントをリッスンして、自分で通知を発火させるワーカーを作らなきゃいけないの？それと、他の言語（特にDart）のSDKをリリースする予定はあるのかな？