他のツールで作ったアプリを持ち込む
Lovable、Bolt、v0 などで作ったアプリや、手元で開発したアプリも、ソースコードがあれば Keelson へのデプロイを検討できます。対応できるかどうかは、使ったツールの名前ではなく、アプリの言語やデータの保存方法で決まります。
まず AI エージェントにコードを確認してもらい、必要な変更を確認してからデプロイします。外部サービスにあるデータや利用者のアカウントは、コードをデプロイしただけでは Keelson に移りません。
1. ソースコードを用意する
Section titled “1. ソースコードを用意する”作成したツールからコードをエクスポートするか、Git リポジトリを手元に取得し、アプリのフォルダを AI エージェントで開きます。
Keelson CLI とエージェント用の Skill の準備、Keelson へのログインがまだの場合は、クイックスタートを先に進めてください。
2. エージェントに確認を頼む
Section titled “2. エージェントに確認を頼む”次のように依頼してください。
このアプリを Keelson にデプロイしたいです。コードを確認し、対応できるかと必要な変更を説明してください。データベース、ログイン、ファイルの保存先、定期的な処理を確認し、既存のデータや利用者のアクセス権に影響する変更は、実施前に説明してください。
エージェントが確認するのは、主に次の点です。
| 確認すること | 確認する理由 |
|---|---|
| アプリの言語とフレームワーク | Keelson の対応範囲と、起動・ビルド方法を確認するため |
| データの保存先 | 外部 DB を使い続けるか、Managed SQLite に変更するかを判断するため |
| ログインとアクセス権 | 既存の利用者が自分のデータを引き続き使えるようにするため |
| ファイルの保存先 | 再起動で消える保存方法になっていないかを確認するため |
| タイマーやバックグラウンド処理 | リクエスト処理や Keelson の定期実行ジョブに変更する必要があるかを確認するため |
対応している言語・フレームワークは対応アプリと制約、処理の実行方法はアプリが動くタイミングにまとめています。
3. データとログインの扱いを確認する
Section titled “3. データとログインの扱いを確認する”外部のデータベースやストレージを使っている場合
Section titled “外部のデータベースやストレージを使っている場合”アプリから接続できる外部サービスは、デプロイ後も使い続けられます。この場合、データを移す必要はありません。たとえば、外部 DB を使うアプリは db.mode: none にし、接続情報を設定します。
サーバー側で使う API キーやパスワードはシークレットで渡します。ブラウザ側で使うサービスの URL や公開用のキーは、そのサービスの案内に従って設定してください。秘密の値をブラウザに送るコードへ埋め込まないでください。
Supabase などをブラウザから直接呼ぶ構成では、外部サービス側のアクセス権設定も引き続き必要です。Keelson のログインでアプリを保護しても、外部サービスのデータ権限が自動で置き換わるわけではありません。
すでにログイン機能がある場合
Section titled “すでにログイン機能がある場合”Keelson では、アプリを開くときに Keelson のログインが必要です。元のログイン機能を残すと、利用者は両方にログインすることになります。
元のログインを外せるかどうかは、ユーザーの識別やデータのアクセス権に使っているかで判断します。
| 元のログインの役割 | 対応方法 |
|---|---|
| アプリを開く人を制限するためだけに使っている | Keelson のログインとアプリのアクセス権に置き換えることを検討できます |
| ユーザーごとに見せるデータを制限している | 元の認証を残すか、Keelson のユーザー情報を使って権限を判定するように変更します |
| データに元のサービスのユーザー ID を保存している | 既存のユーザーと Keelson のユーザーをどう対応付けるかを決めます |
たとえば Supabase の RLS(行ごとのアクセス制御)で auth.uid() を使っている場合、ログイン機能だけを外すと、誰のデータかを判定できなくなります。ログイン画面を削除する前に、データへのアクセス方法を確認してください。
アプリ内のファイルに保存している場合
Section titled “アプリ内のファイルに保存している場合”アプリが動くサーバー内のファイルは、再起動・再デプロイで失われます。残したいものに合わせて保存方法を変更します。
| 残したいもの | Keelson の保存先 |
|---|---|
| 顧客情報、案件、申請など、検索・更新するデータ | Managed SQLite |
| アプリ内部の設定ファイルや処理済みデータの記録 | Files SDK |
| 画面に表示する画像、利用者が開く PDF や添付ファイル | Media SDK |
保存先を変更する場合は、コードの変更に加えて、既存データを移す手順もエージェントに確認してください。
4. デプロイする
Section titled “4. デプロイする”変更内容を確認したら、エージェントに依頼します。
確認した内容で必要な変更と keelson.yaml の作成を行い、このアプリを Keelson にデプロイしてください。
エージェントはアプリの構成に合わせて設定を作成します。主な構成は次のとおりです。設定を自分で書く必要はありません。
| アプリの構成 | デプロイ方法 |
|---|---|
| 静的サイト / SPA(ビルド済みの HTML・CSS・JavaScript) | ビルドしたファイルを assets に指定して配信します。外部サービスの API をブラウザから呼ぶアプリも含みます |
| サーバー側の処理がある Web アプリ(Next.js、Express、FastAPI など) | command で Web サーバーを起動します |
| 静的な画面と API サーバーを組み合わせたアプリ | assets と command を設定し、assets.api で API のパスを指定します(ハイブリッド構成) |
設定の読み方は keelson.yaml の設定、操作手順はデプロイするを参照してください。
静的サイトのビルドについて
Section titled “静的サイトのビルドについて”静的サイトは、手元でビルドしてからデプロイします。Keelson にアップロードされるのは assets.dir の中身と keelson.yaml で、Keelson 上で npm install や npm run build は実行されません。
ビルド時に読み込むサービスの URL や公開用のキーは、ビルド前に設定します。デプロイ後にサーバーの環境変数を設定しても、ビルド済みの画面には反映されません。エージェントには、設定を含めてビルドとデプロイを依頼してください。
5. デプロイ後に確認する
Section titled “5. デプロイ後に確認する”- Keelson の URL で画面が開き、必要な操作ができる
- 既存のデータが表示され、追加・更新したデータも保存される
- 画像や添付ファイルを表示・閲覧できる
- 元の認証を残した場合も含め、想定したログイン手順で利用できる
- 他のメンバーも利用でき、見せるべきでないデータは表示されない
コードと一緒には移らないもの
Section titled “コードと一緒には移らないもの”作成ツールが提供するデータベース、認証、ファイル保存、サーバー側の関数は、ソースコードだけをデプロイしても移りません。外部から利用できるものは接続を維持し、利用できないものはデータの移行や処理の書き換えが必要です。
作成ツール内の編集機能も Keelson には移りません。デプロイ後のコード変更は、手元の AI エージェントなどで行い、再デプロイして反映します。