Enterprise Data Access
プロトタイプは、もう
「作って終わり」では済まない。
Replit で組んだ社内アプリは、これまで「面白い試作」で止まりがちでした。情報システム部門が管理する本番データに、正規のルートで触れる手段がなかったからです。Databricks の Postgres データベース「Lakebase」とのネイティブ統合が、その壁を崩し始めています。
The Gap
試作と本番の間に
横たわっていた壁
Replit のようなエージェント型開発ツールは、アイデアを数分でアプリの形にできます。ところが多くの企業では、そのアプリが触れられるのは架空のダミーデータまで。実際の顧客台帳や在庫データのような「統制された本番データ」には、情報システム部門の審査を経たシステムからしかアクセスできませんでした。結果として、Replit で作られたものの大半はデモの域を出ないまま止まる、という状況が続いていたのです。
この構図を変えるのが、Databricks が公式ブログで発表した Replit とのネイティブ統合です。Replit Agent が組んだアプリから、Databricks 側で管理される実データへ、ガバナンスとセキュリティの枠組みを保ったまま直接アクセスできるようになりました。加えて本番運用を支えるデータベースには日次の自動バックアップも標準搭載され、「動くプロトタイプ」を壊れやすい実験のままにしておく必要がなくなっています。
Under the Hood
統合の土台は、買収1年半の
データベース会社
この統合を支えるのは Lakebase という Postgres 互換データベース。その中身は、Databricks が2025年に買収した1社の技術そのものです。
Lakebase の正体は、サーバーレス Postgres のスタートアップ Neon が持っていた技術です。SiliconANGLE の報道によれば、Databricks は2025年5月に約10億ドルで Neon を買収し、その1か月後には早くも Lakebase としてサービス化しました。Neon は2021年に Nikita Shamgunov 氏（CEO）と Heikki Linnakangas 氏、Stas Kelvich 氏が立ち上げた企業で、「ブランチを切れる Postgres」という開発者向けの発想で知られていました。
Lakebase は2026年2月に AWS 版が正式一般提供（GA）となり、今回 Replit がそこにネイティブ対応したことで、既存の分析基盤（レイクハウス）とアプリ用の可変データベースが、同じガバナンス下でつながる形になりました。課金体系も素朴な固定料金ではなく、稼働時間に応じた Capacity Unit（CU）単位の従量制に加え、常時稼働アプリ向けの Always-On プランではベースライン容量が25%割安になる設計です。
How It Works
デプロイした瞬間に、
データベースが立ち上がる
開発者が意識するのはコードだけ。基盤側のセットアップは Replit Agent が肩代わりします。
アプリをエージェントに作らせる
自然言語の指示から Replit Agent がアプリの画面とロジックを組み立てます。この時点ではまだ、どのデータベースを使うかを開発者が意識する必要はありません。
デプロイ時に Lakebase を自動生成
本番へ公開する操作をした瞬間、Replit Agent が Lakebase インスタンスを自動でプロビジョニングします。接続文字列の発行やスキーマ作成といった手作業は発生しません。
ガバナンス下で運用が続く
その後は Databricks 側のアクセス制御下でデータが更新され続け、日次バックアップも自動で走ります。運用に入ってからの「壊れたら終わり」のリスクが下がります。
In Practice
誰に、どう効くか
恩恵の大きさは職種によってはっきり分かれます。
エンジニア
DB接続の配線やIAM設定に時間を溶かさずに済みます。ただし本番データを触る以上、Agent が生成したクエリはレビュー対象にすべきです。
ビジネス・情シス
IT部門が許可した経路の中でツールを内製できるので、「野良アプリ」を止めるのではなく、統制しながら数を増やせます。承認プロセスの設計が新たな仕事になります。
PM・個人利用
社内のちょっとした業務ツールを、開発チームを待たずに自分で作って本番運用に載せられるようになります。個人の実験用途にはほぼ影響しません。
「作れること」と「使い続けられること」の間にあった溝を、データベースの自動化が埋め始めている。
What's Next
次の一手と、見ておくべきリスク
短期的には、社内向け業務ツールの内製が加速するはずです。まず着手しやすいのは、閲覧中心のダッシュボードや申請フォームのように、書き込み権限が限定的な用途から。次に、Replit Agent が生成した接続・クエリコードを情シス側でレビューする体制を先に整えること。最後に、Always-On プランの料金試算を早めに行い、常時稼働アプリの月額コストが「個人プランの延長」から外れていないかを確認することです。
一方で楽観一辺倒にもなれません。Agent が自動生成するデータベーススキーマや権限設定は、人間が丁寧に設計した場合に比べて粒度が粗くなりがちです。「つながること」と「安全につながること」は別問題であり、統合の速さがそのまま監査のしやすさを意味するわけではない点は、今後の実運用で検証が必要です。また Lakebase 自体はまだ Azure 版がベータ段階で、マルチクラウド構成の企業では展開速度に差が出る可能性があります。