cloudflare-app-bootstrap

Cloudflare アプリケーションのブートストラップ

プロジェクトを現在の状態から、要求されたアプリケーションの動作を試せるローカルリクエストが実行できる状態にします。ユーザーが使用しているフレームワーク、パッケージマネージャー、CLI、既存のサービスを維持してください。設定やコマンドを選ぶ前に、関連する最新のドキュメントを読み、ローカル CLI のヘルプとスキーマを使って、インストール済みバージョンでのサポート状況を確認してください。

プロジェクトから始める

アプリのディレクトリ、ロックファイル、スクリプト、フレームワークとアダプターのバージョン、Cloudflare の設定（cloudflare.config.ts または Wrangler の設定ファイル）、既存のセットアップ手順を確認してください。モノレポでは、インストールやファイル生成の前にアプリケーションのルートを特定してください。既存のロックファイルからインストールし、プロジェクトの依存関係と設定の規約を再利用してください。

プロジェクトに Cloudflare の設定がまだない場合は、フレームワークアプリでは frameworks-on-cloudflare スキル、それ以外では cf-cli スキルを使って、先に設定してください。フレームワークによって生成された設定のソースを特定し、そのソースを編集してください。設定の問題を解決するために、動作中のアプリをスターターで置き換えないでください。

アプリに必要なリソースだけを接続する

アプリケーションコードで使われている各バインディングを特定し、既存のリソースまたは新しいローカルリソースに割り当ててください。コードと設定の間で名前を統一してください。既存のリソース識別子はそのまま維持してください。識別子のないバインディングは、次回のデプロイ時にプロビジョニングする新しいリソースとして扱われます。

サポート対象のリソースを手動で作成する前に、自動プロビジョニングを読み、どのリソースタイプが対象か確認してください。プロビジョニングの方法は CLI によって異なります。

• Wrangler： wrangler dev は実行間で保持されるローカルリソースを作成し、wrangler deploy はリモートリソースを作成して、その識別子を設定ファイルに書き戻します。
• cf： cf deploy は不足しているリソースをプロビジョニングしますが、識別子を cloudflare.config.ts に書き戻しません（開発、ビルド、デプロイ）。報告された識別子を設定に記録してください。

必要なリモートリソースを作成する前に、アカウント、環境、リソースを確立してください。

アプリのスクリプトとローカル開発ガイドに基づいて、開発コマンドを選んでください。ローカル Worker ではリモートバインディングを使用できます。書き込みを試す前に、どのリソースがシミュレートされ、どの呼び出しが実際のサービスに到達するかを特定してください。フレームワークがサポートする Workers 開発用統合を使ってください。フロントエンド専用の開発サーバーでは、サーバーバインディングが機能することは確認できません。

データを利用する機能では、最初の意味のあるリクエストに必要な状態だけを初期化してください。既存のマイグレーションツールを維持してください。D1 では、マイグレーションに従い、d1 migrations applyには--localまたは--remoteを明示的に指定してください。--localはシミュレートされたデータベースだけを初期化します。要求されたセットアップにそのデータベースの変更が含まれる場合に限り、リモートにマイグレーションを適用してください。Durable Objects では、D1 の SQL マイグレーションとして扱うのではなく、現在のクラスのマイグレーション設定を確認してください。

設定とシークレットの解決

必須の値を、ビルドプロセス、ブラウザーバンドル、Worker ランタイムのどれが使用するかで分類します。非公開のランタイム認証情報を公開クライアント設定に含めないでください。ランタイムシークレットにはWorkers secretsを使用し、ビルドに必要な値はビルド環境で設定します。

Wrangler および Vite のプロジェクトでは、ファイル名、環境の優先順位、必須シークレットの宣言について、ローカルシークレットの読み込みに従います。cfプロジェクトでは、Wrangler の動作を想定せず、cf cli searchで同等の方法を探します。プロジェクトで選択されているローカルシークレットファイルを再利用し、実際の値を含むファイルが Git の対象外になっていることを確認したうえで、値が不足している場合は名前と安全なプレースホルダーを用意します。ローカルシークレットはデプロイ済みの Worker には設定されません。選択したワークフローでアカウントへのアクセスが必要な場合にのみ認証します。ローカル環境のセットアップで、ログインやデプロイを一律に必須にしないでください。

最初のアプリケーションリクエストを検証する

設定を変更した後、プロジェクトのスクリプトを使ってバインディングとランタイムの型を再生成します。Wrangler プロジェクトではwrangler typesを、cfプロジェクトではcf workers typesを使用します。生成された宣言を手作業で編集しないでください。既存のビルドと型チェックのうち、該当するものを実行します。

実際の開発ワークフローを開始し、該当する場合はバインディングへのアクセスも含めて、代表的なルートまたは UI 操作を試します。サーバーが起動したことだけでなく、レスポンスと意図した状態変更を確認します。認証情報が不足している場合や、ローカルでサポートされていないサービスがある場合は、アプリが動作すると断言せず、未検証の内容を正確に報告します。

再現可能なインストール、初期化、開発用コマンドをプロジェクトのセットアップドキュメントに記載します。テストした URL または操作、ローカルまたはリモートのどちらで動作するリソースか、不足している必須値、残っているリモート環境のセットアップを報告します。ユーザーのタスクにデプロイが含まれている場合にのみ、デプロイに進みます。

スキルへのフィードバック

ユーザーから、このスキルの案内に誤りや古い情報がある、または情報が不足していると報告された場合は、references/skill-feedback.mdを読んでください。