mcpField
I
ionic-appflow-migration

ionic-appflow-migration

github.com/capawesome-teamクラウド・DevOps52873 回インストール1 週間前に更新
リポジトリ

ionic-appflow-migration について

Ionic Appflow のプロジェクトを Capawesome Cloud に移行するチーム向けのスキルです。Capawesome CLI で組織データをプレビュー、インポートし、Live Update SDK、Git 接続、CI/CD の移行も案内します。エクスポートは機密情報として扱います。

主な機能

  1. 01Appflow 機能の利用状況を検出
  2. 02CLI によるアプリのプレビューとインポート
  3. 03Live Update とビルド設定の移行
  4. 04Git プロバイダー接続の案内
  5. 05エクスポートを機密情報として扱う

活用シーン

  1. 01Appflow 組織のアプリを Capawesome Cloud に移行
  2. 02Live Updates、ネイティブビルド、ストア公開の移行
  3. 03インポート前に対象アプリと警告を確認

MCP 対応

記載によると、Capawesome MCP サーバーは Capawesome のドキュメントと Cloud 管理 API を提供します。利用可能な場合、ドキュメント検索を推奨し、cloud_* ツールでクラウド管理手順を実行できます。

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/capawesome-team/skills --skill ionic-appflow-migration

インストール後、Claude Code で/ionic-appflow-migrationを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
ci-cd-migration.md
cordova-sdk-migration.md
live-update-sdk-migration.md

詳細

Ionic Appflow の移行

既存の Ionic Appflow プロジェクトを Capawesome Cloud に移行します。

移行の大部分は自動化されています。Ionic Appflow では組織を ZIP ファイルとしてエクスポートでき、Capawesome CLI では 1 つのコマンドでインポートできます。アプリ、署名証明書、環境、ライブアップデートチャネル、ネイティブ設定、ストアの送信先、ビルドの自動化がすべて含まれます。残りの作業は、アプリの Live Update SDK の差し替え、Git プロバイダーの接続、CI/CD パイプラインの更新です。

Ionic Appflow は 2027 年 12 月 31 日にサポート終了となり、新規顧客への販売はすでに 2025 年 2 月に終了しています。既存顧客はサービス終了日まで引き続きアクセスできますが、すべての Appflow プロジェクトで移行計画が必要です。早めに移行すれば、段階的でリスクの低い展開が可能になります。

この移行の公式ガイドは Ionic Appflow からの移行です。このスキルの内容と異なる場合は、ドキュメントに従ってください。

前提条件

  1. 現在 Ionic Appflow を使用している Capacitor 6、7、または 8 のアプリ。純粋な Cordova アプリ(Capacitor なし)の場合は、ライブアップデートを代わりに Cordova Live Update SDK(@capawesome/cordova-live-update)に移行してください。インポートと Capawesome Cloud の手順はどちらにも適用されます。
  2. Node.js 18 以降と npm がインストールされていること。
  3. プロジェクトのソースコードリポジトリにアクセスできること。
  4. Capawesome Cloud のアカウントと組織があること。
  5. Ionic Appflow 組織の管理者アクセス権。エクスポートの作成に必要です。アクセス権がない場合は、手順 3~7 をスキップして、代わりに手動での代替手順を使用してください。

厳守事項:エクスポートを読み取らない

Ionic Appflow のエクスポートには、環境シークレット、キーストアと .p12 のパスワード、プロビジョニングプロファイル、Google サービスアカウントの秘密鍵、Apple アプリ固有のパスワードなど、すべての認証情報が平文で含まれています。**エクスポート ZIP は不透明なものとして扱ってください。**以下のルールは、このスキル内の他のすべての指示より優先されます。

  • エクスポート ZIP やその中のファイル(manifest.json、app-detail.json、その他の JSON、キーストア、.p12 ファイル、.mobileprovision ファイル、json-key.json を含む)を、いかなるツール(シェルコマンド、ファイル読み取り、コード)でも、絶対に解凍、展開、開く、読み取る、cat、grep、一覧表示、解析、調査しないでください。構造を「確認」したり、含まれているアプリ名や ID を調べたりしないでください。
  • エクスポートの内容を絶対に出力、ログ記録、貼り付け、要約、保存しないでください。エクスポートの内容、シークレットの値、パスワードをチャットに貼り付けるようユーザーに絶対に求めないでください。
  • エクスポートに対して許可されている操作は、npx @capawesome/cli apps:import --file <path> にパスを渡すことだけです。CLI 自身が出力する要約は読み取ってかまいません。この要約には、アプリ名、リソース数、警告、名称変更など、機密ではない値のみが含まれます。--include に必要なアプリ名と ID を確認するには --dry-run を使用してください。ZIP 自体を調べてはいけません。
  • 同じルールは手動での代替手順にも適用されます。キーストア、.p12 ファイル、プロビジョニングプロファイル、サービスアカウントキー、環境シークレットの値を絶対に開かないでください。ユーザーにはファイルパスを尋ね、それらを開かずに CLI に渡してください(例:apps:certificates:create --file、apps:environments:set --secret-file)。パスワードとシークレットの値は、対話型プロンプトまたはユーザー自身のシェルを通じて、ユーザーが CLI に直接入力する必要があります。エージェントがそれらを入力、表示、または伝達してはいけません。
  • 移行後は、エクスポート ZIP を削除するようユーザーに注意を促してください。エージェントが独自に ZIP を削除、移動、コピー、または名前変更してはいけません。

一般的なルール

  • @capawesome/cli コマンドを初めて実行する前に、--help フラグを付けて実行し、利用可能なオプションをすべて確認してください。
  • インポートは必ず1回だけ実行してください。 2回目の実行では既存のアプリは更新されず、名前を変更した複製が作成されます。インポートする前に、ステップ2(Git 接続)を完了してください。
  • エクスポート ZIP をコミットしたり、リポジトリに追加したりしないでください。一時的な追加も禁止です。
  • 対応する Capawesome Cloud 機能のセットアップと検証が完了するまで、Ionic Appflow の設定を削除しないでください。インポートによって Ionic Appflow 側は変更されないため、移行中は両方のプラットフォームを並行して実行できます。
  • 変更を加える前に、package.json(@capacitor/core)から Capacitor のバージョンを確認してください。使用するプラグインのバージョンと更新方法は、これによって異なります。

MCP サーバー

Capawesome MCP サーバーは最新の Capawesome ドキュメントを提供するため、このスキルに含まれるガイダンスよりも常に新しい情報を確認できます。API トークンを使用すると、Capawesome Cloud 管理 API も利用できます。

  • Capawesome MCP ツールを利用できる場合は、トピックについて search_docs を呼び出し、該当ページを get_doc_page で読んでから、以下のガイダンスを適用してください。両者に相違がある場合は、ドキュメントに従ってください。cloud_* ツールを使うと、このスキルに記載されている Capawesome Cloud の手順(アプリの作成、ビルドの実行、チャンネルやストアへのデプロイ、ロールバック、失敗したジョブの診断)を、Capawesome CLI の代わりに直接実行できます。
  • 利用できない場合は、以下のコマンドでサーバーを追加できることを一度だけ伝えたうえで、このスキルを続けてください。サーバーの利用を必須にしないでください。
claude mcp add --transport http capawesome "https://mcp.capawesome.io/mcp"

ドキュメントツールの利用にアカウントやトークンは必要ありません。Capawesome Cloud ツールを含むセットアップ手順の全容については、capawesome-mcp スキルを参照してください。

手順

ステップ1:Ionic Appflow の使用状況を確認する

プロジェクトを調べ、使用中の Appflow 機能を特定します。これにより、後続のどのステップを適用するかが決まります。インポート自体は常に Capawesome Cloud 側を対象とします。

1.1 Live Updates の確認

次の手がかりを検索してください。

  1. package.json(dependencies または devDependencies)内の @capacitor/live-updates。
  2. package.json 内の cordova-plugin-ionic。これは Ionic Live Updates 用の従来の Cordova SDK です。
  3. capacitor.config.ts または capacitor.config.json の plugins オブジェクト内の LiveUpdates キー。
  4. TypeScript/JavaScript のソースファイル内の @capacitor/live-updates または cordova-plugin-ionic のインポート。

いずれかの手がかりが見つかった場合は、Live Updates を使用中として記録してください。また、使用中の SDK(@capacitor/live-updates または cordova-plugin-ionic)も記録してください。

現在の設定値を記録してください:appId(Ionic Appflow アプリ ID)、autoUpdateMethod(background、always、または none)、channel、enabled、および maxVersions。

1.2 ネイティブビルドの確認

次の手がかりを検索してください。

  1. CI/CD 設定ファイル内の Appflow CLI ビルドの呼び出し(例:.github/workflows/*.yml、.gitlab-ci.yml、bitrise.yml、Jenkinsfile、azure-pipelines.yml)。Appflow CLI のバイナリ名は appflow(旧名:ionic-cloud)です。appflow build と ionic-cloud build を grep で検索してください。
  2. CI/CD ファイルまたはスクリプト内の dashboard.ionicframework.com または appflow.ionic.io への参照。
  3. プロジェクトのルートにある appflow.config.json、.appflow.yaml、または同様の Appflow 設定ファイル。

いずれかの手がかりが見つかった場合は、Native Builds を使用中として記録してください。

1.3 App Store Publishing の使用状況を確認する

次の手がかりを検索します。

  1. CI/CD 設定ファイルにある Appflow CLI のストアへのデプロイ実行箇所を検索します。appflow deploy android、appflow deploy ios、および旧式の ionic-cloud deploy を grep します(注:appflow deploy web はチャネルへのライブアップデートをデプロイするため、App Store Publishing ではなく Live Updates に該当します)。
  2. App Store への申請用に設定された Appflow のデプロイ先を検索します(例:appflow destination コマンドや、--destination で指定されたストアのデプロイ先)。

いずれかの手がかりが見つかった場合は、App Store Publishing が使用中であると判断します。

1.4 検出結果を提示する

検出された機能をユーザーに提示し、次の点を確認します。

  1. 移行する機能(検出されたすべての機能、またはその一部)。
  2. ユーザーがIonic Appflow 組織の管理者アクセス権を持っているかどうか。持っていない場合は、手動での代替手順に進みます。
ステップ 2:Capawesome Cloud を準備する
2.1 CLI をインストールして認証する
npx @capawesome/cli login

apps:import コマンドにはCapawesome CLI 4.21.0 以降が必要です。npx @capawesome/cli --version でバージョンを確認し、インストール済みのバージョンが古い場合はアップグレードしてください。

2.2 Git プロバイダーを接続する(インポート前)

インポートでは各アプリの Git リポジトリがリンクされますが、対象の組織がそのプロバイダーとすでに接続されている場合に限ります。接続されていない場合、インポート時に警告が表示され、リポジトリはリンクされないまま処理が続行されます。その後、各リポジトリを手動でリンクする必要があります。

アプリのリポジトリで使用しているプロバイダー(GitHub、GitLab、Bitbucket、Azure DevOps、Gitea、または HTTP/S 経由の Git サーバー)を、Capawesome Cloud Consoleで組織レベルに接続するようユーザーに依頼してください。プロバイダーごとの設定については、Integrationsを参照してください。

続行する前に、ユーザーの確認を待ってください。インポート後に接続すると、手作業でやり直す必要があります。

2.3 アプリを手動で作成しない

apps:create は実行しないでください。インポートによって、エクスポート内のすべてのアプリが作成されます。あらかじめアプリを作成すると名前が競合し、インポートされたアプリの名前に数値の接尾辞が付加されます(例:prod (2))。

ステップ 3:Ionic Appflow 組織をエクスポートする

エクスポートは CLI から開始できません。Appflow Dashboard で次の手順を実行するようユーザーに案内してください。

  1. Ionic Appflow Dashboardを開き、組織を選択します。
  2. Settings → Account に移動します。
  3. Organization export セクションで、Export をクリックします。
  4. エクスポートが完了したら、Download をクリックして zip ファイルを保存します。

エクスポートには、現在のプロジェクトだけでなく、組織内のすべてのアプリが含まれます。

zip ファイルには、環境シークレット、パスワード付きの署名証明書、ストアの認証情報などの機密データが平文で含まれます。リポジトリの外に保存し、絶対にコミットせず、移行後に削除するようユーザーに伝えてください。

ダウンロードした zip ファイルのローカルパスをユーザーに尋ね、以下では <EXPORT_ZIP> として使用してください。

厳守事項: <EXPORT_ZIP> を開いたり、解凍したり、内容を一覧表示したり、調査したりしないでください。パスを CLI に渡す以外の操作は行わないでください。

ステップ 4:インポートをプレビューする

必ず最初にドライランを実行します。何も作成せず、実際のインポートで行われる処理をそのまま表示します。

npx @capawesome/cli apps:import --file <EXPORT_ZIP> --dry-run

厳守事項: エクスポートの内容を確認する唯一の方法は、ドライランです。アプリ名、ID、その他の値を調べるために、エクスポートを解凍したり読み取ったりしないでください。

CLI は対象の組織を尋ねます。オプションは次のとおりです。

オプション用途
--file <path>エクスポートファイル(.zip)へのパスです。省略すると入力を求められます。
--organization-id <id>対象の組織です。省略すると入力を求められます。非対話型の環境では必須です。
--include <apps>エクスポート内の名前または ID で指定したアプリのみをインポートします。複数回指定するか、カンマ区切りで指定できます。既定ではすべてのアプリが対象です。
--ionic-app-type <capacitor|cordova>曖昧なアプリタイプ ionic でエクスポートされたアプリのタイプを解決します。省略するとアプリごとに入力を求められます。非対話型の環境では必須です。指定しない場合、該当するアプリはスキップされます。
--dry-runリソースを作成せずにプレビューします。
--json概要を JSON 形式で表示します。

--include を省略し、エクスポートに複数のアプリが含まれている場合、CLI はインポートするアプリを対話形式で尋ねます(すべてがあらかじめ選択されています)。エクスポートには組織全体が含まれているため、ユーザーが特定のアプリのみを希望している場合は --include を使用してください。

npx @capawesome/cli apps:import --file <EXPORT_ZIP> --include "My App,My Other App" --dry-run

表示された表と警告をユーザーと一緒に確認してから、次に進んでください。今のうちに修正するほうが後で修正するより簡単な問題は、すべて解決してください。特に、Git 接続がない場合は必ず解決します(ステップ 2.2)。

ステップ 5:インポートを実行する

ステップ 4 のコマンドを、--include、--organization-id、--ionic-app-type の値も含めてそのまま繰り返し、--dry-run だけを削除して実行します。

npx @capawesome/cli apps:import --file <EXPORT_ZIP> [--include <apps>] [--organization-id <id>] [--ionic-app-type <type>]

厳守事項: エクスポートを読み取るのは CLI であり、エージェントではありません。表示された概要だけをもとに作業してください。

アプリごとに、次の項目がインポートされます。

Ionic AppflowCapawesome Cloud備考
アプリアプリ名前が競合する場合や大文字・小文字だけが異なる重複の場合は、数値の接尾辞が付きます(例:prod (2))
Live update チャネルチャネル同じ概念で、命名の自由度も同じです
環境(変数とシークレット)環境変数とシークレットの両方がインポートされます
署名証明書署名証明書キーストア、.p12 ファイル、プロビジョニングプロファイルが対象です
ネイティブ設定設定アプリ名とバンドル ID の上書き設定です
デスティネーションデスティネーションGoogle サービスアカウントキーを含むストアの認証情報です
ネイティブおよびウェブのビルド自動化自動化複数のチャネルを持つウェブ自動化は、チャネルごとに 1 つの自動化になります
リポジトリの関連付けGit リポジトリのリンクステップ 2.2 で接続した Git プロバイダーが必要です
最新のビルド番号次のビルド番号新しいビルドは Appflow のビルド番号を引き継ぎます

このコマンドは1 回だけ実行してください。再実行すると既存のアプリが更新されず、名前を変更したアプリのセットがもう 1 つ作成されます。

Step 6: インポートの概要を確認する

CLI は、アプリごとに作成されたリソースの表を出力し、その後にアプリごとのメモ、名前変更、エラー、作成された各アプリの Console URL を表示します。リソースのインポートに失敗したものがある場合、終了コードは 1 です。

ユーザーと一緒に出力を確認し、次の対応を行ってください。

メッセージ対応
名前変更(... was renamed to ...)新しい名前を記録します。古い名前を参照するすべての CI/CD ワークフロー、スクリプト、自動化を更新する必要があります(Step 9 を参照)。
自動化の Webhook はインポートされませんでしたCapawesome Cloud では、自動化ごとではなくアプリ単位で Webhook を設定します。Step 7 で追加します。
ネイティブ設定に Live Update プラグインの設定が含まれていますこれらは Capawesome Cloud の設定ではなく、アプリ自体(capacitor.config / config.xml)に含める設定です。Step 8 で対応します。
Web プレビューはサポートされていませんCapawesome Cloud に Web プレビューに相当する機能はありません。ユーザーに伝え、この機能は削除してください。
リポジトリがリンクされていませんGit プロバイダーが接続されていません。Step 7 で接続し、リポジトリを手動でリンクします。
React Native / Flutter アプリはスキップされました対応は今後予定されています。それまではエクスポートを保管し、後で対象アプリのみを指定して --include 付きでインポートを再実行してください。
サポートされていないビルドタイプ / 不明な参照がスキップされましたその値を指定せずに自動化が作成されました。Console で手動設定してください。
個々のリソースに関するエラー失敗したリソースを Console で手動作成してください。インポート全体を再実行してはいけません。
Step 7: 手動で必要な作業を完了する

これらはインポートできないため、一度だけ手動で設定する必要があります。ユーザーに一覧を提示し、CLI で対応可能な作業については実行を提案してください。

  1. リンクされていないリポジトリをリンクする — 組織レベルで Git プロバイダーを接続し、各アプリのGit リポジトリページでリポジトリを選択します。
  2. アプリ単位の Webhook を追加する — Appflow の自動化で Webhook を使用していた場合、アプリごとに設定します(Webhooksを参照)。
  3. App Store Connect API キーを追加する — インポートで引き継がれるのは Apple ID の認証情報のみです。自動公開を行うには、インポートされた宛先に .p8 の App Store Connect API キーを追加します。
  4. CI/CD 用の API トークンを作成する — Appflow の個人用アクセストークンは使用できません。代わりに Capawesome Cloud API トークンを作成します(Step 9 を参照)。
  5. チームとメンバーを再作成する — Capawesome Cloud Console でチームメンバーを招待します。

設計上、移行されないものは、ビルドとデプロイの履歴、Live Update のデプロイ履歴、依存関係キャッシュの設定、Web プレビューです。Ionic Appflow のアプリには変更を加えません。

Step 8: Live Update SDK を置き換える

Live Updates が検出されなかった場合、またはユーザーが移行しないことを選択した場合は、このステップをスキップしてください。

8.1 パッケージを置き換える

プロジェクトで @capacitor/live-updates を使用している場合:

npm uninstall @capacitor/live-updates

プロジェクトでレガシー Cordova SDK(cordova-plugin-ionic)を使用している場合:

npm uninstall cordova-plugin-ionic

プロジェクトの Capacitor バージョンに合った Capawesome プラグインのバージョンをインストールします。

  • Capacitor 8:npm install @capawesome/capacitor-live-update@latest
  • Capacitor 7:npm install @capawesome/capacitor-live-update@v7-lts
  • Capacitor 6:npm install @capawesome/capacitor-live-update@v6-lts

Cordova のみのアプリの場合は、8.2 と 8.3 をスキップし、代わりに capawesome-cloud スキルの references/live-updates-cordova.md に従ってください。プラグインを Cordova プラグイン(@capawesome/cordova-live-update)として追加し、config.xml の <preference> エントリで設定します(オプション名は 8.2 の表と同じです)。実行時は deviceready 後に cordova.plugins.LiveUpdate としてアクセスし、cordova prepare で適用します。その後、Step 9 に進みます。

8.2 Capacitor の設定を更新する

capacitor.config.ts(または .json)で、LiveUpdates プラグイン設定を LiveUpdate に置き換えます。インポート概要に記載された Capawesome Cloud のアプリ ID を使用してください。Appflow のアプリ ID は使用しないでください。オプションは次のように対応付けます。

Ionic Appflow(LiveUpdates)Capawesome Cloud(LiveUpdate)備考
appIdappIdインポートした Capawesome Cloud のアプリ ID に置き換えます
autoUpdateMethod: 'background'autoUpdateStrategy: 'background'動作は同じです
autoUpdateMethod: 'always'autoUpdateStrategy: 'background'nextBundleSet リスナーも追加します
autoUpdateMethod: 'none'(autoUpdateStrategy を省略)代わりに手動同期コードを使用します
channeldefaultChannel値は同じです
enabled(削除)不要です。コードで制御します
maxVersionsautoDeleteBundles: true数値ではなくブール値です
 // capacitor.config.ts
 const config: CapacitorConfig = {
   plugins: {
-    LiveUpdates: {
-      appId: 'abc12345',
-      autoUpdateMethod: 'background',
-      channel: 'production',
-      maxVersions: 3
-    }
+    LiveUpdate: {
+      appId: '<CAPAWESOME_APP_ID>',
+      autoUpdateStrategy: 'background',
+      defaultChannel: 'production',
+      autoDeleteBundles: true,
+      autoBlockRolledBackBundles: true,
+      readyTimeout: 10000
+    }
   }
 };

インポート時にネイティブ設定内の Live Update プラグイン設定が報告された場合は、それらの値をここに適用してください。Capawesome Cloud の設定で扱うのはアプリ名とバンドル ID のみです。

8.3 ソースコードを更新する

ソースファイルを編集する前に、references/live-update-sdk-migration.md を読んでください。インポートと API の変更、sync() の戻り値、戦略ごとのコード(background、always、none、強制更新)、ロールバック保護、ネイティブバージョンとの互換性、iOS のプライバシーマニフェストについて説明しています。

レガシー Cordova SDK を使用しているプロジェクトでは、references/cordova-sdk-migration.md も読み、Deploy から LiveUpdate へのメソッドの完全な対応表と、ネイティブ設定のクリーンアップを確認してください。

最後に、ネイティブプロジェクトを同期します。

npx cap sync
Step 9: CI/CD パイプラインを更新する

外部 CI/CD パイプラインがないプロジェクトでは、この手順をスキップしてください。インポート済みの自動化によって、同じブランチでビルドがすでに実行されます。

references/ci-cd-migration.md を読み、その内容を適用してください。Appflow から Capawesome CLI へのコマンドの完全な対応表、トークンベースの認証、Appflow 依存関係の削除が含まれています。すべての --app-id を変更し、インポート中に名前が変更されたリソースは新しい名前で参照する必要があります。

Step 10: テストと検証
10.1 Live Updates を検証する(移行した場合)

Live Update の機能をテストするか、ユーザーに確認してください。承諾された場合:

  1. アプリに小さく目立つ変更を加えます(例:見出しに「 - Migration Test」を追加します)。
  2. Web アセットをビルドします:npm run build。
  3. 既存のチャンネルを確認します:
    npx @capawesome/cli apps:channels:list --app-id <APP_ID> --json
    
  4. 対象のチャンネルがない場合は作成します:
    npx @capawesome/cli apps:channels:create --app-id <APP_ID> --name <CHANNEL_NAME>
    
  5. バンドルをアップロードします:
    npx @capawesome/cli apps:liveupdates:upload --app-id <APP_ID> --channel <CHANNEL_NAME>
    
  6. 目立つ変更を元に戻し、再ビルドして同期します:
    npm run build && npx cap sync
    
  7. ネイティブプロジェクト(npx cap open ios または npx cap open android)を開き、デバイスまたはエミュレーターで実行します。
  8. Live Update が適用されていることを確認します。autoUpdateStrategy: "background" の場合は、更新のプロンプトが表示されるまで待つか、アプリを強制終了して再度開いてください。または、アプリから離れて15分以上経過してから戻り、チェックを実行します。
10.2 ネイティブビルドを検証する(移行した場合)

テストビルドを実行し、成果物が生成されることを確認します。

npx @capawesome/cli apps:builds:create --app-id <APP_ID> --platform ios --git-ref main
10.3 App Store への公開を検証する(移行した場合)

テストビルドを設定済みの配信先にデプロイし、TestFlight または Google Play Console に表示されることを確認します。

npx @capawesome/cli apps:deployments:create --app-id <APP_ID> --build-number <BUILD_NUMBER> --destination "<DESTINATION_NAME>"
10.4 クリーンアップ

すべての機能の検証後:

  1. Ionic Appflow SDK パッケージがすべて package.json から削除されていることを確認します。
  2. Ionic Appflow の設定がすべて capacitor.config.ts/capacitor.config.json から削除されていることを確認します。
  3. Ionic Appflow の CI/CD コマンドと環境変数がすべて削除されていることを確認します。
  4. エクスポート ZIP ファイルとそのコピーを削除するよう、ユーザーに伝えてください。 エージェント自身がファイルを削除、移動、または名前変更してはいけません。

組織エクスポートを使わずに移行する場合の手動フォールバック

ユーザーが Ionic Appflow 組織の管理者アクセス権を持っていない場合、またはエクスポートを利用できない場合に限り、この手順を使用してください。すべて手作業で再作成します。ステップ 1、8、9、10 はそのままです。

厳守事項: ここでも認証情報のファイルを開いてはいけません。キーストア、.p12 ファイル、プロビジョニングプロファイル、サービスアカウントキーについては、ユーザーにファイルパスを尋ね、そのパスを CLI に渡してください(--file、--provisioning-profile、--google-service-account-key-file、--apple-api-key-file、--secret-file)。ファイルは開かないでください。パスワードやシークレット値は、CLI の対話型プロンプトにユーザー自身が入力するか、ユーザー自身のシェルでコマンドを実行してもらいます。シークレットを入力、エコー出力、転送してはいけません。

F.1 アプリを作成する
npx @capawesome/cli apps:create

返されたアプリ ID(UUID)を保存してください。これは capacitor.config およびすべての CI/CD コマンドで Appflow アプリ ID の代わりに使用します。

F.2 Live Update チャネルを再作成する

各 Appflow Live Update チャネルを再作成します。

npx @capawesome/cli apps:channels:create --app-id <APP_ID> --name <CHANNEL_NAME>
F.3 ネイティブビルドを再作成する

Git リポジトリを接続し、署名証明書をアップロードして、環境とネイティブ設定を構成します。capawesome-cloud スキルを使用し、「Connect Git Repository」から始まるNative Buildsセクションの手順に従い、手順の全容について references/native-builds.md を参照してください。元の値(キーストアと .p12 のパスワード、環境変数、シークレット)は Appflow ダッシュボードにあります。値はユーザー自身が確認し、CLI のプロンプトに入力します。チャットで値を尋ねてはいけません。

F.4 アプリストアへの公開を再作成する

公開先を作成し、Apple App Store および/または Google Play Store の認証情報を設定します。capawesome-cloud スキルを使用し、App Store Publishingセクションの手順に従い、references/app-store-publishing.md を参照してください。

F.5 自動化を再作成する

各 Appflow ビルド自動化を再作成します。

npx @capawesome/cli apps:automations:create --app-id <APP_ID>

その後、ステップ 8 に進みます。

エラー処理

インポート
  • The provided file does not look like an Ionic Appflow export → ファイルが Settings → Account からダウンロードした組織エクスポートであり、再圧縮したフォルダーやリポジトリアーカイブではないことをユーザーに確認してもらいます。不明な場合は再ダウンロードしてもらいます。確認のために zip を開いてはいけません。
  • The export file ... has an unexpected format/フォーマットバージョンの警告 → CLI を更新(npx @capawesome/cli@latest)して、ドライランを再実行します。
  • No apps found in the export that match the provided filters → --include の値は、アプリの名前または IDと完全に一致する必要があります。--include を指定せずにドライランを実行し、CLI に利用可能なアプリを一覧表示させます。
  • あいまいなアプリタイプ ionic が原因でアプリがスキップされた → --ionic-app-type capacitor または --ionic-app-type cordova を渡すか、インタラクティブモードでインポートを実行し、アプリごとに確認のプロンプトを表示させます。
  • アプリが「not yet supported」としてスキップされた(React Native、Flutter)→ 想定どおりです。エクスポートを保持し、対応開始後に --include を指定してそれらのアプリをインポートし直します。
  • インポートがエラーで終了した(終了コード 1)→ 個々のリソースの作成に失敗しています。Console で手動作成してください。修正のためにインポート全体を再実行してはいけません。アプリが重複します。
  • 誤ってアプリを二重にインポートした → Capawesome Cloud Console(apps:delete)で重複したアプリを削除し、元のアプリを残します。
  • リポジトリがリンクされていない → インポート時に組織に一致する Git 接続がありませんでした。プロバイダーを接続し、各アプリのGit repositoryページでリポジトリをリンクします。
ライブアップデート
  • npm uninstall @capacitor/live-updates が失敗する → パッケージが別の名前で登録されている可能性があります。package.json で、@capacitor スコープに属し、live-updates を含むパッケージを検索してください。
  • プラグインの入れ替え後に npx cap sync が失敗する → インストールされている @capawesome/capacitor-live-update のバージョンが、package.json の Capacitor のバージョンと一致していることを確認してください。
  • 再起動後にアプリがデフォルトのバンドルに戻る → LiveUpdate.ready() の呼び出しが早い段階で行われていない可能性があります。アプリの初期化で最初に呼び出してください。
  • autoUpdateStrategy: "background" でアップデートが検出されない → アップデートの確認は、前回の確認から15分以上経過している場合にのみ行われます。アプリを強制終了して再起動してください。デバイスのログで Live Update SDK の出力を確認してください。
  • LiveUpdates is not defined などの実行時エラーが発生する → すべてのインポートが @capacitor/live-updates から @capawesome/capacitor-live-update に更新され、クラス名が LiveUpdates から LiveUpdate に変更されていることを確認してください。
  • Deploy is not defined → プロジェクトではレガシー Cordova SDK(cordova-plugin-ionic)が使われています。メソッドの完全な対応表については、references/cordova-sdk-migration.md を参照してください。
  • activeApplicationPathChanged is not a property が表示される、または同期結果の確認に失敗する → Capawesome SDK は { activeApplicationPathChanged } ではなく { nextBundleId } を返します。同期結果を確認する箇所をすべて更新してください。
  • setConfig is not a function → インストールされているプラグインのリリースが古くなっています。対応する dist-tag の最新リリースに更新してください(Capacitor 8 では @latest、7 では @v7-lts、6 では @v6-lts)。
ネイティブビルド
  • 認証エラーでビルドに失敗する → npx @capawesome/cli login を再実行してください。CI/CD の場合は、CAPAWESOME_CLOUD_TOKEN シークレットが正しく設定されていることを確認してください。
  • 署名証明書が見つからずビルドに失敗する → 証明書のインポートに失敗した可能性があります。npx @capawesome/cli apps:certificates:create を使ってアップロードしてください。capawesome-cloud スキルの references/certificates-android.md または references/certificates-ios.md を参照してください。
  • invalid source release でビルドに失敗する → ビルド環境で JAVA_VERSION 環境変数を設定してください。capawesome-cloud スキルの references/build-troubleshooting.md を参照してください。
App Store への公開
  • 宛先の作成に失敗する → 認証情報が正しいことを確認してください。capawesome-cloud スキルの references/apple-app-store-credentials.md または references/google-play-store-credentials.md を参照してください。
  • "build not found" でデプロイに失敗する → デプロイの前にビルドが正常に完了していることを確認してください。
CI/CD
  • 移行後にパイプラインが失敗する → 移行前後のパイプライン設定を並べて比較してください。--app-id に新しい Capawesome Cloud アプリ ID が使われていること、名前が変更されたリソースが新しい名前で参照されていること、CAPAWESOME_CLOUD_TOKEN をシークレットとして利用できることを確認してください。

関連スキル

  • capawesome-cloud — ネイティブビルドと App Store 公開の設定、および手動での代替手順で参照されます。
  • capawesome-cli — このスキル全体で使われている Capawesome CLI のインストール、認証、CI/CD での使用方法について説明します。
  • ionic-enterprise-sdk-migration — プロジェクトで提供終了となった Ionic Enterprise SDK プラグイン(Auth Connect、Identity Vault、Secure Storage)も使用している場合、このスキルを使って Capawesome の代替プラグインに移行してください。
  • capgo-cloud-migration — Ionic Appflow ではなく Capgo から移行する場合は、代わりにこのスキルを使ってください。
  • capawesome-mcp — MCP クライアントをホスト型の Capawesome MCP サーバーに接続すると、常に最新のドキュメントを参照し、Capawesome Cloud を管理できます。

コメント