apply

コード変更を適用する (SDK インストール)

統合計画を実行します。SDK をインストールし、追跡対象の各サーフェスを初期化するために必要な最小限のコードを追加します。

このスキルは LaunchDarkly SDK インストール (オンボーディング) の下にネストされています。親の ステップ 3 は 適用です。前: 統合計画を生成する。次: アプリケーションを起動する。

デュアル SDK: 承認された計画が デュアル SDK (計画: デュアル SDK 統合) である場合、両方のトラックについてステップ 1 ～ 3 を完了する必要があります -- マニフェストに2 つのパッケージ、2 つのインストールコマンドを実行 (または同等のもの)、必要に応じて2 つの認証情報行、レシピごとに異なるエントリポイントに2 つの init です。実際のインストールと init を実行せずに、2 つ目の SDK がセットアップされたと主張しないでください。計画に 1 つのトラックしか記載されていないのに、ユーザーが両方を求めた場合は、停止して 計画 に戻ってください -- 記憶から残りの半分をでっち上げないでください。

認証情報のタイミング: これは、ユーザーに SDK キー / クライアントサイド ID / モバイルキーを尋ねる (または取得・書き込みの同意を得る) 最初のネストされたステップです。アカウントのステータスは事前に尋ねられません -- MCP がすでに設定されている場合は以前に MCP OAuth 経由で推測され、ユーザーがまだアカウントを持っていない場合はここ D7 (オプション 4) で提示されます (親の前提条件)。

ステップ 1: SDK 依存関係をインストールする

SDK レシピ で既に一致させた SDK 行から、正確なパッケージ名またはモジュール名とインストールコマンドを、プロジェクトのパッケージマネージャーで使用してください。他の場所から汎用的なインストール行をコピーしないでください -- 各レシピが正しいアーティファクトを示しています。

デュアル SDK: トラック A のインストールコマンドを実行し、次に (計画からの) トラック B のインストールコマンドを実行します。両方のパッケージ名が package.json / requirements.txt / ロックファイル (または各言語に適したパッケージマニフェスト) に表示されることを確認してください。計画がデュアルと言っている場合、2 つ目のインストールを省略することは任意ではありません。

インストール後、依存関係がロックファイルまたは依存関係マニフェストに表示されることを確認してください (計画からのすべての LaunchDarkly パッケージ)。

他の依存関係を変更する前の許可

追加の許可を求めずに実行できること（通常のリポジトリ編集の同意を超える範囲）： この統合のレシピに記載された LaunchDarkly SDK パッケージのみをインストールすること（例：サーバー SDK を 1 つ、または デュアル SDK プランに記載されたサーバー + クライアントの正確なペア -- 両方のパッケージが対象となる LD インストールと見なされます）。各レシピが指定する最小限のインストールを使用してください（正確なパッケージ名）。

コマンドを実行したりマニフェストを編集したりする前に、ユーザーの明示的な承認が必要： その範囲を超える変更。以下に限定されません：

• LaunchDarkly 以外のパッケージのアップグレード、ダウングレード、固定、または追加（peer-dependency の「修正」、「npm install X@latest」、「yarn upgrade」、「pnpm update」、React/Node の型のバージョンアップ、推移的なロックファイルの変動など）
• npm audit fix、一括更新の実行、または SDK を満たすためのプロジェクトのパッケージマネージャー解決戦略の置き換え
• LD アーティファクトの行を追加する以外の理由による engine / packageManager フィールド、resolutions / overrides、または workspaces エントリの変更

パッケージマネージャーが peer の競合やインストール失敗を報告した場合：

D8 -- BLOCKING： 今すぐ構造化質問ツールを呼び出してください。

• question: 「インストールで [具体的なエラー] が報告されました。これを修正するには、[非 LD パッケージへの具体的な変更] が必要です。これらの追加変更を進めてよろしいですか？」
• options:
  • 「はい、その変更を実行してください」
  • 「いいえ、LaunchDarkly パッケージのみを維持してください -- 競合は自分で解決します」
  • 「最初に正確なコマンドを見せてください」
• STOP。質問をテキストとして書かないでください。古いリポジトリを「最新の SDK の依存関係に合わせる」ために黙ってアップグレードしないでください。ユーザーがオプションを選択するまで続行しないでください。

ユーザーがより広範な変更を拒否した場合：可能であれば LD パッケージの追加のみを維持し、競合を文書化し、プレースホルダーまたは手動の手順で進めてください。

ステップ 2：SDK キーを環境設定に追加する

SDK キー、クライアント側 ID、またはモバイルキーをアプリケーションのソースファイルにハードコードしないでください（環境変数を介してのみ参照してください）。

シークレットの前に権限を確認する

D7 -- ブロッキング (必須 -- スキップしないでください): 構造化質問ツールを今すぐ呼び出してください。この決定ポイントはセキュリティコンプライアンスのために存在します -- ユーザーはシークレットの取り扱い方法を明示的に選択する必要があります。これをスキップして同意なしにキーを書き込むことは重大な失敗です。

• question: 「SDK はあなたの環境用の SDK キー (またはクライアントサイド ID / モバイルキー) を必要とします。シークレットをどのように設定しますか?」
• options:
  • 「どこに置くか教えます」
  • 「自分でシークレットを設定します -- 使用すべき変数名だけ教えてください」
  • 「私のために .env ファイルに書き込んでください」
  • 「まだアカウントを持っていません -- サインアップを手伝ってください」 -> 解決済みのサインアップ URL を案内し (ソースの帰属を参照)、プレースホルダーを書き込んで続行します (実際のキーはアカウントの準備ができるまで保留)
• STOP。質問をテキストとして書かないでください。ユーザーが最初にオプションを選択する前に、LaunchDarkly からキーを取得したり、実際の値をリポジトリに書き込んだりしないでください。コンテキストや以前の会話から回答を推測しないでください -- 常にこの選択肢を提示してください。

ユーザーがオプション 1 (「どこに置くか教えます」) を選択した場合:

1. シークレットをどこに書き込むか (ファイルパス、シークレットマネージャーなど) を尋ねます
2. キーをどのように提供するか (貼り付けるか、エージェントが MCP/API 経由で取得するか) を尋ねます
3. キーはユーザーが指定した場所にのみ書き込みます
4. .env を作成したり、他のファイルを変更したりしないでください

ユーザーがオプション 2 (「自分で設定します」) を選択した場合:

1. 設定する必要がある変数名を伝えます (下の表を参照)
2. 適切なダッシュボードページへのリンクを伝えます。プロジェクトキーと環境キーが判明している場合: https://app.launchdarkly.com/projects/{projectKey}/settings/environments/{envKey}/keys。プロジェクトキーのみが判明している場合: https://app.launchdarkly.com/projects/{projectKey}/settings/environments を案内し、環境を選択するように伝えます。どちらも判明していない場合: https://app.launchdarkly.com/projects を案内し、Settings > Environments に移動してキーを見つけるように伝えます。
3. ステップ 3 に進む前に、ユーザーがシークレットを設定したことを確認するまで待ちます
4. キーの値を取得、書き込み、または一切取り扱わないでください

ユーザーがオプション 3 (「私のために .env ファイルに書き込んでください」) を選択した場合:

1. キーをどのように提供するか (貼り付けるか、エージェントが MCP/API 経由で取得するか) を尋ねます
2. 下の .env への書き込み セクションに従います
3. 実際の値を書き込む前に、.env が .gitignore に含まれていることを確認します

ユーザーがオプション 4 (「まだアカウントを持っていません」) を選択した場合:

1. 解決済みのサインアップ URL を案内します (ソースの帰属を参照)
2. SDK キーの設定にはアカウントが必要であることを説明します -- サインアップ後に設定を完了できます
3. 書き込む前に、.env が .gitignore に含まれていることを確認します (オプション 3 と同じチェック / .env への書き込み)
4. コードがコンパイルできるように、プレースホルダーの変数名を .env に書き込みます (実際の値は書き込みません)
5. プレースホルダーの環境変数参照を使用して、ステップ 3 (初期化コード) を続行します。実際のキーが設定されるまでアプリは LaunchDarkly に接続できませんが、これは想定どおりです。
6. オンボーディングログに、キーの設定がアカウント作成待ちであることを記録します

MCP 経由でのキーの取得

ユーザーがエージェントにキーの取得を依頼した場合（上記のオプション 1 または 3 を使用）、get-environments MCP ツールを使用します（設定されている場合）。プロジェクトキーを指定して呼び出してください。レスポンスには各環境の SDK キー、クライアントサイド ID、モバイルキーが含まれます。get-environments がすでにそれらを返している場合、個々のキーに対して別々の API リクエストを行わないでください。

get-environments({ request: { projectKey: "PROJECT_KEY" } })

セキュリティ: キーを含む MCP レスポンスは機密情報として扱ってください。 キーは、チャットのレスポンスで完全なキーの値をエコーすることなく、ユーザーが選択した場所にのみ書き込んでください。エージェントの会話履歴やログ内のキーは、セッションを超えて保持される可能性があります。

レスポンス内の一致する環境から正しいキータイプを選択してください（以下の表を参照）。MCP が設定されていない場合は、ユーザーに LaunchDarkly ダッシュボードでキーを取得するよう案内してください: https://app.launchdarkly.com/projects/{PROJECT_KEY}/settings/environments/{ENV_KEY}/keys。

変数名と値の取得元

SDK タイプ	変数名（一般的なもの）	LaunchDarkly での取得元
サーバーサイド	LAUNCHDARKLY_SDK_KEY	get-environments レスポンス → 環境 → SDK キー
クライアントサイド	論理名 / バンドラープレフィックス付きの名前（以下を参照）	get-environments レスポンス → 環境 → クライアントサイド ID
モバイル	LAUNCHDARKLY_MOBILE_KEY	get-environments レスポンス → 環境 → モバイルキー

クライアントサイド（ブラウザ）プロジェクト: LaunchDarkly の値は依然としてクライアントサイド ID です。.env では、バンドラーがクライアントコードに公開する名前を使用してください:

スタック	.env のキー	コード内での読み取り
Create React App	REACT_APP_LAUNCHDARKLY_CLIENT_SIDE_ID	process.env.REACT_APP_LAUNCHDARKLY_CLIENT_SIDE_ID
Vite	VITE_LAUNCHDARKLY_CLIENT_SIDE_ID	import.meta.env.VITE_LAUNCHDARKLY_CLIENT_SIDE_ID
Next.js	NEXT_PUBLIC_LAUNCHDARKLY_CLIENT_SIDE_ID	process.env.NEXT_PUBLIC_LAUNCHDARKLY_CLIENT_SIDE_ID

その他のスタックでは、異なるプレフィックスや単純な LAUNCHDARKLY_CLIENT_SIDE_ID を使用する場合があります -- プロジェクトがパブリック環境変数にすでに使用しているものに合わせてください。

.env への書き込み（ユーザーが同意した場合）

ファイルパスには統合ルート（リポジトリルート、またはモノレポの場合は対象パッケージ -- リポジトリスタックの検出を参照）を使用してください。

1. .env の作成または更新: .env が存在しない場合は作成します。存在する場合は、LaunchDarkly の行のみを追記または更新してください -- 無関係な変数を削除しないでください。
2. 統合に必要なものを追加:
   • サーバー専用: LAUNCHDARKLY_SDK_KEY=...
   • クライアント / ブラウザ: 正しいバンドラープレフィックス付きキーの下にクライアントサイド ID（例: VITE_LAUNCHDARKLY_CLIENT_SIDE_ID=...）。
   • フルスタックまたはハイブリッド（例: Next.js、SSR + クライアント）: 両方の SDK が使用されている場合は、サーバー SDK キーとクライアントサイド ID の行を両方追加してください。
   • モバイル: 該当する場合 LAUNCHDARKLY_MOBILE_KEY=...。
3. .gitignore: .env を作成したのと同じルート（またはモノレポの場合は最も近い関連する ignore ファイル）の .gitignore に .env が記載されていることを確認してください。エントリがない場合は追加してください -- ただし、ユーザーがリポジトリの変更に同意した後のみです（.env の書き込みと同じ権限スコープ）。実際のシークレットを含むファイルをコミットしないでください。
4. .env.example / .env.sample: プロジェクトでこれらを使用している場合は、プレースホルダーのエントリのみを追加してください（実際のキーは不可）。これにより、チームメンバーが設定すべき変数を把握できます。

プロジェクトが dotenv を使用せず、設定モジュールやホスト型シークレットに依存している場合は、代わりにそこでの既存のパターンに従ってください -- 実際の値をいずれかのファイルに書き込む前には、上記と同じ D7 の同意が依然として適用されます。

ステップ 3: SDK 初期化コードを追加する

初期化の形は、検出と計画の際にどの SDK を選択したかによって異なります。このスキルには SDK ごとのコピー＆ペースト用サンプルは含まれていません -- 誤ったスニペットを使用すると（たとえばレシピが Node サーバーであるのに React Web を使うなど）、誤った方向に導かれます。

信頼できる情報源（順番に使用し、デュアル SDK の場合はトラックごとに繰り返します）:

1. SDK レシピ -- このトラックの SDK に対応する行: インストールは上記のステップ 1 です。初期化については、そこに記載されている SDK の詳細 / ドキュメントのリンクに従ってください。
2. snippets/ 配下の SDK 詳細ファイル（レシピからリンクされている場合）-- 厳選されたリンクと、多くの SDK についてはその SDK に沿った完全なオンボーディングサンプル。
3. その SDK に関する LaunchDarkly の公式ドキュメント（レシピまたは詳細ファイルにある URL）-- それらのエントリーポイントと非同期パターンを使用してください（例: React Web: React Web SDK）。

認証情報はステップ 2 を使用して接続します: サーバー SDK は LAUNCHDARKLY_SDK_KEY を使用し、クライアント/ブラウザー SDK はクライアントサイド ID を、該当する場合はステップ 2 のバンドラー接頭辞付きの環境変数名とともに使用します。

そのトラックのアプリケーションエントリーポイント（モノレポの場合は対象パッケージのエントリーポイント -- リポジトリスタックの検出を参照）にインポートと初期化を追加します。デュアル SDK: サーバーの初期化は計画で指定されたサーバーのエントリーポイントに、クライアント/プロバイダーの初期化はクライアントのエントリーポイントに記述します -- そのスタックの公式ドキュメントが両方に対して単一のパターンを明示的に規定していない限り、両方をカバーすると装う単一の共有ブロックを決して使用しないでください。

主要な原則

1. ファイルの先頭で他のインポートとともにインポートする
2. そのランタイム（Node サーバーかブラウザーか）のアプリケーションライフサイクルの中で早い段階で初期化する
3. SDK がサポートしている場合は、フラグを評価する前に初期化を待つ
4. エラーを処理する -- 失敗をログに記録しますが、アプリケーションをクラッシュさせないでください
5. 既存のコードスタイルに合わせる -- コードベースの残りの部分と同じパターン（async/await、コールバック、モジュールの CommonJS か ESM か）を使用する
6. サーフェスごとに適切なパターンを使用する -- サーバーサイドの初期化はサーバーコード内のサーバーレシピから、クライアント/プロバイダーの初期化はクライアントコード内のクライアントレシピから行います。両方のトラックで 1 つのスニペットを再利用したり、計画がデュアル SDK の場合に 2 つ目のトラックの初期化を省略したりしないでください。

ステップ 4: コードがコンパイルされることを確認する

変更を行った後:

1. プロジェクトのビルドまたはコンパイル手順を実行する
2. リンターが設定されている場合は実行する
3. インポートエラーや型の問題を修正する。ただし、ユーザーがその範囲を承認しない限り、無関係な依存関係をアップグレードせずに修正してください（他の依存関係を変更する前の許可）

コードがコンパイルされない場合は、次のステップに進まないでください。

---

完了したら: アプリケーションを起動する