ae-migrate-tracking-code

ae-migrate-tracking-code

会話の言語：このスキルのドキュメントは英語ですが、ユーザーへのすべての出力は、必ずユーザーの入力言語にしてください。 英語の入力 → 英語で回答。中国語の入力 → 中国語で回答。日本語の入力 → 日本語で回答。 判断に迷う場合は、英語を既定とします。 これは、セクションタイトル、フェーズ名、プロンプト、コードコメントなど、すべての出力に適用されます。 ⚠️ 重要：プロバイダーアダプターのドキュメントには、中国語の用語解説が含まれていることがよくあります。英語または日本語のユーザーに回答する際は、見出しやコメントをユーザーの言語に翻訳してください。 このドキュメントの中国語のテキストを、英語または日本語の回答にそのままコピーしないでください。

用語集

中文	English	Notes
埋点迁移	トラッキング移行	既存のサードパーティ SDK のトラッキング呼び出しを AE SDK に変換します
源 SDK	ソース SDK／プロバイダー	プロジェクトですでに使用されているサードパーティ SDK（Firebase、Amplitude など）
调用点	呼び出し箇所	ソース SDK の呼び出し（logEvent／setUserId／setUserProperty／Identify）
归一化中间表示	IR（中間表現）	抽出した呼び出し箇所をプロバイダーに依存しない形式で出力したもの
映射	マッピング	ソースのイベント／プロパティから AE のイベント／プロパティへの変換
切换	切り替え	ソース SDK の呼び出しを AE の track() に置き換え、ソース SDK を削除します
双写 / 新增	追加／二重書き込み	ソース SDK を維持し、並行して AE の track() を追加します
依赖标识	依存関係識別子	切り替えモードでソース SDK を削除する際に使うパッケージ／モジュール名
自动采集事件	自動トラッキングイベント	ソース SDK が自動で収集するイベント（例：session_start）
公共属性	スーパーイベントプロパティ	すべてのイベントに自動で付与されるプロパティ。⚠️ AE での正しい中国語の用語は「公共属性」または「公共事件属性」です。「Super Property」を「超级属性」と訳さないでください。これは AE で有効な用語ではありません。
用户属性	ユーザープロパティ	ユーザープロファイルに設定するプロパティ
用户体系	ユーザー ID の体系	AE における distinct_id／account_id の方針

トリガー条件

ユーザーが「Firebase のトラッキングを AE に移行して」「Amplitude を ThinkingAI に置き換えて」「プロジェクトですでに Firebase／Amplitude のトラッキングを使っているので、AE SDK に切り替えて」「既存の分析機能と並行して AE のトラッキングを追加して」などと依頼した場合にトリガーします。たとえば、「現在のプロジェクトの xx SDK を数数に切り替えて」「既存のトラッキングを数数で実装し直して」「xx SDK を数数に置き換えて」「既存の xx SDK のトラッキングを参考に、数数を統合して」などです。

対象の AE SDK は、数数／数数 SDK／ThinkingAI／ThinkingAI SDK／Agentic Engine／Agentic Engine SDK／AE／AE SDK のいずれで呼ばれても、同じ SDK を指します。トリガーとなるのは、「既存のサードパーティのソース SDK」に加えて「移行／切り替え／置き換え／実装し直し」という依頼がある場合、または「既存の xx SDK のトラッキングを参考に、数数を統合／導入して」という依頼がある場合です。ソース SDK に触れずに単に「数数 SDK を導入して」「数数のトラッキングを追加して」と依頼された場合は、新規実装にあたるため、このスキルではなく ae-generate-tracking-code を使用します。

対象範囲：このスキルの対象はコードベースのみです。既存のサードパーティのトラッキング呼び出しをスキャンします（フェーズ 0／1）。サードパーティのトラッキングを含むソースコードがなく、製品ドキュメントや説明しかない場合は、このスキルを使用しないでください。代わりに ae-generate-tracking-plan と ae-generate-tracking-code に振り分けます。過去データの AE へのインポートはオフラインのデータ移行作業であり、対象範囲外です。このスキルでは、ユーザー ID とイベント名／プロパティ名を維持して新しいデータとインポート済みデータを結合できるようにしながら、稼働中のクライアント／サーバー SDK のみを切り替えます。

このスキルは移行を最初から最後まで一貫して進めますが、既存の次の 2 つのスキルの役割を重複して行うことはありません。

• トラッキングプランの生成／アップロード → ae-generate-tracking-plan に引き継ぎます（コードベースパス）。
• AE SDK コードの挿入 → ae-generate-tracking-code に引き継ぎます（挿入モード）。挿入箇所には、grep で検出したビジネストリガーではなく、移行マッピングから提供された箇所を使用します。

プロバイダーレジストリ（拡張可能）

コアはプロバイダーに依存しません。サードパーティプラットフォームごとにアダプターファイルが1つあります。新しいプロバイダーに対応するには、references/providers/ にアダプターを1つ追加し、以下に1行追加してください。この SKILL.md は変更しないでください。

プロバイダー	アダプター	対応プラットフォーム	検出パターン（概要）
Firebase Analytics	references/providers/firebase.md	Web v8/v9、Android、iOS、Flutter、React Native、Unity、C++	firebase/analytics、firebase.analytics()、FirebaseAnalytics、FIRAnalytics、Analytics.logEvent（iOS Swift）、FirebaseAnalytics.instance
Amplitude	references/providers/amplitude.md	Web legacy（amplitude-js）、Browser 2.x、Node、Python、Go、Java、Android、iOS、React Native、Flutter、Unity	amplitude-js、@amplitude/analytics-browser、@amplitude/analytics-node、amplitude.init、amplitude.getInstance()、amplitude.logEvent、amplitude.track、Identify、サーバーインポート（from amplitude import、analytics-go、com.amplitude:java-sdk）
Sensors Data（神策）	references/providers/sensors-data.md	Web、Android、iOS、Harmony、macOS/tvOS、C++、React Native、Flutter、Unity、Unreal、Cocos2d-x、ミニプログラム（WeChat／その他）、QuickApp、APICloud、uni-app、Weex、Egret、LayaAir、およびサーバー SDK（Java／Python／Go／Node／PHP／Ruby／C／.NET／Lua）	sensorsdata.min.js、sensors.init、sensors.track、SensorsDataAPI、SensorsAnalyticsSDK、profileSet、setProfile（legacy）、サーバーの sa-sdk-*（Python／Go／Node／PHP／Ruby／C／.NET／Lua）
Mixpanel	references/providers/mixpanel.md	JavaScript、Node、Python、Go、Java、Ruby、PHP、Android、iOS、Swift、React Native、Flutter、Unity	mixpanel-browser、mixpanel.init、mixpanel.track、mixpanel.identify、mixpanel.people、MixpanelAPI、mixpanel.NewApiClient（Go）、Mixpanel::Tracker（Ruby）、Mixpanel::getInstance（PHP）、mp.track／people_set（Python）
Google Analytics 4	references/providers/ga4.md	Web（gtag.js／dataLayer）、Measurement Protocol（サーバー）	gtag('event'、gtag('config'、gtag('set'、dataLayer（gtag(/G- も存在する場合に限り GA4 として扱う）、G-XXXXXXX、Measurement Protocol mp/collect

アダプターの契約（アダプターごとの必須フィールド）は references/providers/README.md で定義されています。

対応範囲：上記に記載されたプロバイダー／プラットフォーム（および各アダプターの Recognition セクションにあるプラットフォームごとの表）のみをサポートします。記載されていないものは対象外であり、このスキルではサポートされません。記載されていないプラットフォームのマッピングを捏造しないでください。

---

フェーズ 0 — ソース SDK とバージョンの検出

1. プロジェクトと、そのパッケージ／依存関係マニフェスト（package.json、build.gradle、Podfile、pubspec.yaml、*.csproj など）、およびソースのインポートを特定します。
2. 上記のレジストリと照合します。該当するアダプターの Recognition セクションを読み、プロバイダーを確認してバージョンの種類を特定します。
   • Firebase：v8 の名前空間形式と v9 のモジュール形式（Web）、および Android／iOS／Flutter のネイティブ形式。
   • Amplitude：legacy（getInstance().logEvent）と SDK 2.x（amplitude.track／@amplitude/analytics-browser）。
3. 複数のプロバイダーが存在する場合は、それらを列挙し、どれを先に移行するかユーザーに尋ねます（1回の実行につき1つのプロバイダーとすることで、マッピングを整理できます）。例外 — GA4 と Firebase Analytics は同じデータストリームです：GA4 は Firebase の Web レイヤーです（1つの測定 ID が GA4 プロパティであり、Firebase プロジェクトでもあります）。1つのプロジェクトで gtag(...) と logEvent(...) が共存する場合、2つのプロバイダーではありません。これらを1回の移行にまとめます。スキャンは1回、draft.json／mapping.json は1組、共有するイベント名／プロパティ名／ユーザー ID 名について重複排除を1回行います。1つの Google データストリームに対して、下書きを2つ作成しないでください。
4. レジストリに一致するものがなく、トラッキングコードが存在する場合は、見つかった呼び出しを提示して、プロバイダー名をユーザーに尋ねます。その後、references/providers/README.md に従い、ユーザーが提供したドキュメント／スニペットを基に最小限のアダプターを収集してから続行します。

フェーズ 1 — 呼び出し箇所を IR に抽出する

アダプターの認識パターンを使って、プロジェクト内の次の 4 種類の呼び出しを検索します。

1. イベント呼び出し：logEvent(...) / track(...) と、それらのパラメーター／プロパティ。
2. ID呼び出し：setUserId(...) / identify(...) / login(...)。
3. ユーザープロパティ呼び出し：setUserProperty(...) / setUserProperties(...) / Identify 操作。
4. スーパー プロパティ呼び出し（共通イベントプロパティ）：register(...) / registerSuperProperties(...)（Mixpanel、Sensors Data） / setDefaultEventParameters(...)（Firebase）。kind: super_property として、完全な props マップを記録します。ユーザープロパティと誤認しないでください（mapping-framework.md §6 を参照）。Amplitude と GA4 にはこの API はありません。

各呼び出し箇所について、file:line、呼び出しの種類、イベント／パラメーターの値（リテラル、または周辺コードを読んで解決する変数名）を記録します。references/ir.md に従って、正規化したダンプを .ae-cli/migration/scan.json に書き込みます。

ラッパー層の解決（呼び出しグラフの逆方向トレース） — 実際のプロジェクトでは、各ビジネスイベントからソース SDK を直接呼び出すことはほとんどありません。代わりに、分析ヘルパー（trackEvent(name, props) → mixpanel.track(name, props)）でラップします。単純な grep では、SDK 呼び出しはラッパー内の 1 箇所しか見つからず（イベント名はパラメーターなので resolved:false になります）、実際のビジネスイベントはすべて見落とされます。そのため、SDK 呼び出しのイベント名が関数パラメーター（外側の関数の引数から流れてくる実行時変数）である場合、すぐに resolved:false として記録しないでください。

• 外側の関数 F を特定します。F が分析ラッパーに該当するのは、SDK 呼び出しにそのパラメーターを渡すことだけを役割としている場合です。イベント名がパラメーターではなく、ローカルロジックや式から得られる場合はラッパーではありません。通常どおり、その呼び出し箇所を resolved:false として記録します。
• F の呼び出し元をすべて grep で検索します。静的なイベント名を指定する呼び出し元は、通常の呼び出し箇所として解決します。kind は F が委譲する SDK 呼び出しから推定する（イベント／ID／ユーザープロパティ）、event_name は呼び出し元のリテラルまたは定数の引数、source_call は呼び出し元の呼び出し行、file は呼び出し元のファイル、via_wrapper は F の名前です。
• 動的なイベント名を指定する呼び出し元は resolved:false のままにします。呼び出し元が見つからない場合（外部から使われるエクスポート済みラッパー、または動的ディスパッチ）は、フォールバックとして、ラッパー内の SDK 呼び出しを単一の resolved:false の呼び出し箇所として記録します。
• F 自体は、scan.json のトップレベルの wrappers 配列に記録します（references/ir.md を参照）。トレースの起点であり、移行対象ではありません。

自動トラッキングに関する注意：ソース SDK が自動収集するイベント（Firebase の session_start、first_open、screen_view など）は呼び出し箇所ではありません。ここではなく、フェーズ 2 のアダプターの自動トラッキングの判断表に従って処理します。

フェーズ 2 — AE にマッピングする（draft.json + mapping.json を作成）

1. references/mapping-framework.md（汎用アルゴリズム）とプロバイダーアダプター（相違点）を読みます。
2. 抽出した各イベントについて、AE イベントにマッピングします（snake_case の名前、または前方互換性が必要な場合はそのままの名前 — mapping-framework.md §1。display_name はユーザーの言語にします）。各パラメーターを型付きの AE プロパティにマッピングし、アダプターの命名制約（予約済みプレフィックス、特殊文字、長さの上限）を適用します。
3. 重複排除と昇格のルールを適用します。同じプロパティが 3 件以上のイベントにある場合は、共通イベントプロパティ（スーパー�ロパティ）にします。プリセットの # プロパティはスーパー�ロパティにしません。明示的なスーパー�ロパティの呼び出し箇所（register / setDefaultEventParameters）も draft.json の common_event_properties プールに反映します。詳しくは mapping-framework.md §6 を参照してください。
4. ID を AE の login(accountId) にマッピングします（account_id_source は user_account）。さらに、インポート済みの過去データとの前方互換性が対象範囲に含まれる場合は、訪問者 ID の継続性を確保します（初期化時の setDistinctId / identify）。詳しくは mapping-framework.md §4 を参照してください。ユーザープロパティの操作は、アダプターのマッピング表に従って AE の user_set / user_setOnce / user_add / user_append / user_unset にマッピングします。スーパー�ロパティの呼び出しは、mapping-framework.md §6 に従って setSuperProperties({...})（静的な共通イベントプロパティ）にマッピングします。
5. 呼び出し箇所の場所（アプリコード → クライアント、バックエンド → サーバー）に基づいて、各イベントの platform（client / server）を決定します。
6. ユーザーに移行モード（以下のモードを参照）と、過去のソースプラットフォームデータが AE にオフラインでインポート済み（またはインポート予定）かどうかを確認します。これは mapping-framework.md §1 に基づく前方互換性のある命名と、§4 に基づく訪問者 ID の継続性に影響します。インポート自体はオフラインでのデータ移行作業であり、対象範囲外です。このスキルではライブ SDK のみを切り替えます。次に、以下を行います。
   • .ae-cli/migration/mapping.json を作成します（ソースの呼び出し箇所 → AE イベント + モードの決定。スキーマは references/ir.md を参照）。
   • ae-generate-tracking-plan が生成するものと同じスキーマの AE プランスキーマで .ae-cli/draft.json を作成し、プランスキルから直接利用できるようにします。

マッピングの概要表を表示し、続行前にユーザーの ok を得ます。

フェーズ 3 — トラッキングプランを生成してアップロードする

すでに作成済みのコードベース／draft を使って ae-generate-tracking-plan に引き継ぎます。

1. ae-cli tracking plan draft --in .ae-cli/draft.json --out .ae-cli/draft.xlsx
2. ae-cli tracking plan validate --in .ae-cli/draft.json --fix
3. プランスキルに従って AE のホスト／ログイン／projectId を解決し、ae-cli tracking plan upload ... を実行します（アップロード前にユーザーに確認し、そのスキルの競合検出に従って追記するか置き換えるかを選びます）。

フェーズ 4 — AE SDK コードを挿入する（切り替えまたは追加）

ae-generate-tracking-code（挿入モード）に引き継ぎます。ただし、挿入箇所は grep によるビジネストリガーの検出ではなく、.ae-cli/migration/mapping.json から取得します。

• クライアント／サーバーのプラットフォームと言語はすでに draft.json のメタデータにあります。APP_ID / SERVER_URL は、そのスキルの手順に従って解決します。
• マッピングされた各 AE イベントの挿入箇所は、mapping.json に記録された元の呼び出し箇所です。 モード switch（置換） — リスクが高いため、削除前に確認してください：
• 削除する前に、削除対象（ソースの呼び出し箇所と、アダプターの Dependency identifiers にあるソース SDK の依存関係）を明示的に列挙し、削除についてユーザーの確認を得てください。
• ソースの logEvent／track 呼び出しを、同じ箇所で AE の track(...) 呼び出しに置き換え、使用されなくなったソースのインポートを削除してください。
• モジュール定数に由来するイベント名をインライン化する場合：AE の track(...) 呼び出しには、snake_case のリテラル名を指定してください（// @tracking <event_name> マーカーと一致させる必要があります）。定数の定義を削除する前に、プロジェクト全体でその名前を検索してください。モジュール定数は複数のファイルでインポートされたり、サーバー側のレポートに渡されたり、テストで検証されたりすることがよくあります。移行した呼び出し箇所だけが参照元である場合に限り（その場合、定数はデッドコードです）、削除してください。それ以外の場合は残してください。移行した呼び出しだけに使われる定数は残さないでください。
• アダプターの Dependency identifiers を使って、ソース SDK の依存関係を削除してください（例：firebase/analytics、@amplitude/analytics-browser）。
• 不要になったラッパーを削除します：ラッパーを通じて解決されたすべての呼び出し箇所が replace された場合、ラッパー関数はデッドコードです。これを（使用されなくなったソースのインポートとともに）削除してください。ラッパーのファイルにほかのコードが何もなければ、ファイルを削除してください。（add モードではラッパーを残します。ソース SDK への呼び出しは引き続きラッパーを経由するため、各ビジネス呼び出し箇所に AE の呼び出しを追加します。）
• ID／ユーザープロパティの呼び出しは同様に login(...)／ユーザープロパティの呼び出しに変換し、スーパープロパティの呼び出しは、元の呼び出し箇所で setSuperProperties({...}) に変換してください（決して呼び出し箇所より前に移動しないでください。ソースの register の位置は、値がいつ利用可能になるかを示します。たとえば、ログイン後などです。mapping-framework.md §6 を参照）。

モード add（デュアル書き込み）：

• ソースの呼び出しは変更せずに残し、AE の track(...) 呼び出しをその直後または直前に追加してください（周囲のコードのスタイルに合わせます）。
• 両方向で、2つの SDK を独立させてください。 デュアル書き込みとは、ソース側の条件で AE の書き込みを制御することではなく、すべてのプロバイダー／すべての SDK（Firebase、Amplitude、Sensors Data、Mixpanel、GA4 など）で、独立した2つの書き込みを行うことです。
  • AE の track()／login()／ユーザープロパティ／setSuperProperties() 呼び出しを、ソース SDK の利用可能性チェック、早期リターン、エラーパスの中に入れないでください。たとえば、if (!analytics) return の後、isSupported() の判定後、ソース側の try/catch の中に置かないでください。ソースの呼び出しがそのようなガードの中にある場合は、AE の呼び出しを外に移動し、無条件に実行されるようにしてください。
  • 書き込みごとに、各 SDK で個別の try/catch を設けてください。ソース SDK の失敗（利用不可、isSupported() === false、または例外のスロー）によって AE の書き込みが抑制されてはならず、AE の失敗によってソースの書き込みが抑制されたりクラッシュしたりしてもいけません。
  • ガードは、単一の例外型だけでなく、ソース SDK のすべての失敗ケースに対応する必要があります。既存の限定的な catch（たとえば400の検証エラーに対する Python の except ValueError、Java の catch (IllegalArgumentException)）は、独立性を確保するガードではありません。ほかの失敗（未設定の API キーによる RuntimeError、ネットワーク／タイムアウトなど）が AE の書き込み前に伝播し、クラッシュするおそれがあります。catch をすべての例外を捕捉するように広げ、AE の書き込みを実行してから、ソースの例外を再スローしてください。これにより、元のステータス／エラーの動作（400／503）は変わりません。
  • 初期化にも、各 SDK で個別の try/catch を設けてください。これにより、ロード時に一方の SDK がアンロードまたは無効化されても（初期化が例外をスローする／モジュールが見つからない）、もう一方の SDK に影響しません。どちらの SDK がアンロードまたは無効化されても、両方の書き込みが引き続き機能する必要があります。
  • 混在する実行でのすべての add／add_after／add_before エントリにも適用してください。
• ソース SDK の依存関係は残し、AE SDK の依存関係だけを追加してください。 非同期呼び出し箇所 — await されるソース側の呼び出し（React Native / Flutter の await analytics().logEvent(...)、一部の await mixpanel.track(...)）は Promise を返しますが、AE クライアントの track() / login() / ユーザープロパティ / setSuperProperties() の呼び出しは同期処理です。
• switch：置き換えた呼び出しの await を削除します。同期処理の AE 呼び出しを await すると lint 警告が発生し、何も変わりません。ソース側の呼び出しが、ソース SDK の Promise 拒否（ネットワーク再試行、オフライン時のフォールバック、エラー報告）を処理する catch を持つ try/catch の中にあった場合、その拒否処理の分岐はソース SDK とともに不要になります。不要になった catch ロジックを削除してください。その結果、try ブロックに AE 呼び出しだけが残る場合は、try/catch を AE 呼び出しだけにします（AE の同期エラーはコードスキルのコードスタイルに従い、switch では明示的に表面化します）。形を揃えるために、AE 呼び出しを作為的に async / await でラップしてはいけません。
• add：ソース側の呼び出しの await と try/catch はそのまま維持し、AE 呼び出しはそのブロックの外側に、await を付けずに配置します。上記の独立性ルールに従い、AE 呼び出しは独自の try/catch に入れてください。

どちらのモードも、コードスキルの挿入ルールに従います。Wiki のメインドキュメントに記載された SDK 初期化方法を使う（インポートを推測しない）、git status による事前チェック、言語スタイルの確認を伴う一括 Edit、// @tracking <event_name> コメントの接頭辞です。

ユーザープロパティの append / unset（ae_call = user_append / user_unset）：この 2 つはプランの update_type 列挙型（user_set / user_setOnce / user_add のみ）に含まれないため、draft.json には入りません。ドラフトでは、update_type にプレースホルダーとして user_set を記入します。コード挿入時には、マッピングの ae_call に従って AE SDK 呼び出しを直接出力します（user_append → userAppend、user_unset → userUnset）。Wiki のメインドキュメントから実際のメソッドシグネチャを確認してください（推測しないでください）。

**⚠️ add モードでは、コードスキルのコードスタイル「Do NOT add try/catch」が上書きされます。**このルールは単一 SDK の場合（新規コードへの挿入／切り替え完了後の switch）に適用されます。SDK が 1 つであれば、エラーを明示的に表面化させることが目的であり、初期化やトラッキングの失敗を握りつぶしてはいけません。一方、デュアル書き込みでは状況が逆になります。上記の「各 SDK に独自の try/catch を設ける」ルールは、生成される AE コードにも適用されます。

• AE の初期化も同じように保護する必要があります（独自の try/catch / 利用可能性チェックを設ける）。これにより、AE SDK の読み込みに失敗しても、読み込み時に例外が発生せず、ソース SDK にも影響しません。
• 読み込み時に SDK への参照を取得して、それが恒久的に undefined となり、呼び出しのたびに例外を発生させるコードを出力してはいけません（ラッパー内の var ta = window.TA; など）。AE SDK がない場合は、ビジネスロジックやソース側の書き込みをクラッシュさせず、呼び出しごとに何もしない動作にしてください。
• switch モードには、この上書きは適用されません。切り替え後は AE が唯一の SDK となるため、コードスキルのコードスタイルをそのまま適用し、失敗を明示的に表面化させます。

フェーズ 5 — 検証

コードスキルの検証フローを再利用します。

1. ae-cli auth status を実行し、アクティブなホストを確認します。デバッグデバイスを追加／選択します。
2. 移行したイベントを発生させ、ae-cli tracking debug-data list をクエリします。
3. add モードでは、ソース SDK を引き続き実行したまま AE データも確認します。switch モードでは、ソース SDK が完全に削除され、AE データが送信されていることを確認します。

モード

モード	ソース SDK を維持するか？	AE 呼び出しの配置	依存関係の変更
switch	削除	ソースの呼び出しを置き換える	ソースの依存関係を削除し、AE の依存関係を追加
add	維持	併せて追加	AE の依存関係のみ追加

Phase 2 で、使用するモードをユーザーに一度だけ確認してください。デフォルトは add（二重書き込み）とし、確認プロンプトでは add を推奨オプションとして提示してください。 switch はデフォルト以外の破壊的な選択肢として扱い、ユーザーが完全な切り替えを明示的に希望している場合に限って提示してください。また、推奨オプションとして示してはいけません。

段階的／混在した実行：mode は実行単位のデフォルトですが、各マッピング項目には独自の action（replace と add_after／add_before）があり、項目ごとの action が優先されます。switch の実行でも、段階的な移行のために一部の項目を add_after として維持できます（例：identity と sign-up は今すぐ切り替え、purchase はデータ検証中も二重書き込みを維持）。この場合、置き換えたファイルではソース SDK を削除し、二重書き込みを行うファイルでは維持します。ソース SDK の依存関係を削除するのは、完全な切り替え（すべての項目が replace）の場合に限ります。references/ir.md §mapping.json および mapping-framework.md §8 を参照してください。

⚠️ switch は破壊的です（高リスク）：ソースのトラッキング呼び出し、そのインポート、ソース SDK の依存関係を削除します。デフォルトで古いコードを削除してはいけません。何かを削除する前に、削除対象（呼び出し箇所と依存関係）をユーザーに明示し、確認を得てください。Phase 2 ですでに switch が選択されていても、削除の直前、Phase 4 でもう一度確認してください。

禁止事項

• AE SDK のインポート／パッケージ名を推測すること。必ず ae-generate-tracking-code 経由で Wiki のメインドキュメントを読み込んでください（references/sdk-index.md）。
• イベント名／プロパティ名を AE プランと異なるものに変更すること（snake_case、登録名）。
• ソース SDK の自動トラッキングイベントを手動の track() 呼び出しに移行すること。アダプターに従って、AE の自動トラッキングスイッチにマッピングするか、削除してください。
• add モードで、AE の track()／login()／ユーザープロパティ呼び出しを、ソース SDK の利用可能性チェック、早期リターン、または try/catch の中に入れること。いずれかの SDK の初期化をガードなしのままにすること。または、ソースへの書き込みを狭い例外型のキャッチでガードし、AE への書き込み前にソース側の障害がクラッシュを引き起こす状態にすること。すべてのプロバイダーで、二重書き込みは独立した2つの書き込みでなければなりません（各 SDK は初期化を含め、それぞれ独自の try/catch で、障害が起こり得る処理全体を囲みます）。これにより、一方の SDK が失敗したりアンロードされたりしても、もう一方に影響しません。
• Phase 2 でマッピング概要の確認を省略すること。
• draft.json の update_type に user_append／user_unset を書き込むこと（プランの列挙値は user_set／user_setOnce／user_add のみです）。append／unset は mapping.json の ae_call に記載し、Phase 4 で直接出力してください。
• ユーザー向けの出力で「Super Property」を「超级属性」と翻訳すること。
• git-status の事前チェックより前にソースコードまたは AE コードを書くこと（挿入モード）。
• プロバイダー固有のロジックをコアに追加するため、プロバイダーアダプターを編集すること。新しいプロバイダーを追加する場合は、新しいアダプターファイルのみを追加してください。
• ユーザーへの明示的な警告と、削除直前の確認を得ずに、ソースのトラッキングコードを削除したり、ソース SDK の依存関係を削除したりすること（switch モード）。

内部リファレンス

• references/ir.md — 正規化 IR スキーマ（scan.json／mapping.json）。
• references/mapping-framework.md — プロバイダーに依存しないマッピングアルゴリズム。
• references/ae-preset-properties.md — AE の正式な # プリセットプロパティ一覧とシステムフィールド（取り込み対象はこれらの # 名のみ）。
• references/providers/README.md — アダプターの仕様とプロバイダーの追加方法。
• references/providers/firebase.md — Firebase アダプター。
• references/providers/amplitude.md — Amplitude アダプター。
• references/providers/sensors-data.md — Sensors Data（神策）アダプター。
• references/providers/mixpanel.md — Mixpanel アダプター。
• references/providers/ga4.md — Google Analytics 4（gtag.js／Measurement Protocol）アダプター。