Skip to main content
すべての Base44 アプリにはサンドボックスがあります。これは、アプリのコードを保持し、開発サーバーを実行するプライベートクラウド環境です。アプリエディターが使用するのと同じ環境、同じコードで、同期を維持するためのフォークやコピーは必要ありません。CLI、MCP クライアント、または API 経由で接続すると、どのマシンからでもローカルチェックアウトなし、インストールなしで、アプリの読み取り、検索、編集、コマンド実行が可能です。 サンドボックスを介してファイルを書き込むと、アプリエディターと同じように、実際のアプリを直接変更することになります。これを行う最も一般的な理由は、アプリエディターで構築したアプリに 独自のコーディングエージェントを持ち込む ためです。
アプリエディターの外部からアプリのサンドボックスにアクセスするには、Builder プラン 以上が必要です。ない場合、コマンドは PREMIUM_REQUIRED で失敗します。

​
サンドボックスを使うべき場合

アプリエディターで構築したアプリのコードには、次の方法で作業できます: サンドボックスと GitHub インテグレーションは最も重なります。どちらも独自のツールで作業できるからです。違いは、作業中にコードがどこにあるかです。GitHub インテグレーションでは、ローカルクローンで開発し、main にマージされると変更が Base44 に反映されます。サンドボックスでは、アプリのコードをその場で作業します。ダウンロードは不要で、Web ベースのアシスタントが使用でき、すべての変更が加えられ次第、アプリエディターのライブプレビューに表示されます。

​
接続方法

サンドボックスには次の方法でアクセスできます: コネクタはサンドボックスファイルシステムを経由しないため、上記の表にはありません。この方法で作業しているアプリでコネクタをセットアップするには、代わりに connectors initiate を使用してください。サンドボックスやローカルプロジェクトなしで、同じアプリ ID を直接ターゲットにします。

​
ブランチ

サンドボックスコマンドは、指定しない限りアプリの main ブランチをターゲットにします。別の ブランチ で作業するには、branches list を実行して正確な名前を見つけ、各サンドボックスコマンドに --branch <name> を渡します。すると、読み取りと編集はそのブランチにのみ適用されます。

​
変更は自動的に保存される

sandbox write または sandbox edit の呼び出しは、コマンドが戻る前に、同じリクエストの一部として変更をコミットします。したがって、別途の保存、デプロイ、プッシュ手順はありません。rm や mv のように sandbox run を通じて行われたファイル変更は、短いデバウンスウィンドウが閉じた後、数秒後にコミットされます。デバウンスされたコミットが完了する前に再度書き込みや編集を行うと、新しい呼び出しはそれを待機し、コミット完了を時間内に確認できない場合は COMMIT_FLUSH_PENDING で失敗します。 構造化リソースも同じように同期します。ローカルプロジェクトでは、ファイルを追加した後 entities push や functions deploy を実行します。サンドボックスでは、base44/functions/send-email/entry.ts を作成するだけでその関数が追加されます。
サンドボックスで編集するときの 2 つのルール:
  • サンドボックスで編集しているアプリに対して、deploy、functions deploy、entities push、または他のプッシュコマンドを実行しないでください。これらのコマンドはローカルプロジェクトを Base44 に同期しますが、サンドボックスで作業する場合はローカルプロジェクトが存在しません。
  • 最後の操作が write や edit 呼び出しではなく sandbox run を介したシェルコマンドだった場合、そのコミットはまだ少し遅れています。切断する前に数秒待ってください。

​
編集と公開

サンドボックスを介した編集は公開と同じではありません。編集はすぐにアプリのコードの一部となり、アプリエディターとそのライブプレビューに表示されます。アプリの公開サイトに反映するには、アプリエディターで行った変更と同じ公開手順が必要です。

​
チェックポイント

チェックポイントは、アプリのバージョン履歴内の復元ポイントで、特定のコミットに紐づいています。sandbox checkpoint で作成して既知の良好な状態をマークし、後の変更に問題があればアプリエディターから復元します。チェックポイントを取る前に保留中の変更がコミットされるため、常に最新のコードがキャプチャされます。

​
アプリエディターと並行して作業する

コーディングエージェントと Base44 アプリエディターは、同じアプリで同時に作業できます。取得すべきロックも、解放すべきセッションもありません。両側からの変更は同じ場所に反映されるため、同じプロジェクトを編集する同僚がいるように扱ってください。
マージ手順はありません。コーディングエージェントとアプリエディターが同じファイルを同時に変更した場合、最後に反映された書き込みが優先され、以前の変更はなくなります。両方が同じ作業区間で同じファイルに触れないようにしてください。

​
起動と停止

サンドボックスはストレージだけでなく、実行中のプロセスです。しばらくアイドル状態が続くとダウンし、次のコマンドで再び起動します。どちらの場合もコードには影響しません。コミットされた変更は git に保存され、再起動されたサンドボックスは常に最新のコミットから開始します。サンドボックスが実行されていない場合、最初のコマンドで起動するため、その呼び出しは後続の呼び出しよりも時間がかかる可能性が高いです。

​
権限

サンドボックスへのアクセスを制御する 2 つの独立したチェックがあります。1 つはアプリ自体にアクセスできるかどうか、もう 1 つは現在のセッションに書き込みアクセスが付与されているかどうかです。

​
アプリアクセス

ワークスペース管理者として、またはこの特定のアプリのコラボレーターとして、アプリ自体への管理者アクセスが必要です。アクセスは呼び出しごとにチェックされるため、ワークスペースロールの変更はすぐに反映されます。 通常のワークスペースビューアーはサンドボックスにまったくアクセスできません。唯一の例外は、ワークスペースがロールベースアクセスに移行する前のレガシーなアプリごとの Editor ロールも持っているビューアーです。この組み合わせでは、サンドボックスから読み取ることはできますが、何も変更できません。Superagents はサンドボックスコマンドをサポートしていません。

​
セッションのスコープ

アプリアクセスに加えて、サンドボックスの読み取りと変更には、セッションに対する異なる権限が必要です: セッションの権限は作成時に固定され、後から拡大することはできません。CLI は base44 login 中に sandbox:write を要求し、MCP 経由では OAuth 同意ステップで付与します。既存のセッションを更新しても追加されません。 そのため、読み取りコマンドは動作するが変更コマンドが NOT_AUTHORIZED で失敗する場合、sandbox:write を持たないセッションを使っています。base44 login を再実行するか、MCP サーバーに再接続してサンドボックスアクセスを承認し、それを持つセッションを開始してください。

​
制限とガードレール

ファイルコマンドはアプリのルート内に制限されます。絶対パスやルートを超えるパスは PATH_OUTSIDE_SANDBOX で拒否されます。.agents と .git ディレクトリはファイルコマンドから到達できず、アプリのシークレットとリポジトリの資格情報を保持しているため、PROTECTED_PATH で失敗します。唯一の例外は .agents/skills で、読み書きが可能です。 機能全体で、アプリごとに 1 分あたり 120 の読み取りリクエスト、60 の変更リクエスト、30 の実行コマンドに制限されています。いずれかを超えると RATE_LIMITED で失敗します。各コマンドのリファレンスページでは、sandbox read が受け入れるパスの数や sandbox write が許可するファイルのサイズなど、サイズと数の制限を扱っています。

​
関連情報

このページは AI を使用して翻訳されました。最も正確で最新の情報については、英語版 を参照してください。