deploy-site

プラグインの確認：node "${PLUGIN_ROOT}/scripts/check-version.js" を実行します。メッセージが出力された場合は、続行する前にユーザーに表示してください。

Power Pages サイトのデプロイ

SPA のビルド、添付、または有効化の処理を実行する前に、適切なデプロイワークフローに振り分けます。

基本原則

• 実行前に確認する：デプロイを試みる前に、PAC CLI が利用可能であること、認証状態、および対象環境を必ず確認してください。
• TaskCreate/TaskUpdate を使用する：すべてのフェーズを通じて進捗を追跡します。作業を始める前に、すべてのフェーズを含む ToDo リストを作成してください。
• 同意なしに環境設定を変更しない：デプロイに環境設定の変更（JavaScript の添付をブロック解除する場合など）が必要な場合は、必ず変更内容を説明し、事前にユーザーから明示的な許可を得てください。

初回リクエスト： $ARGUMENTS

---

サイト種別の振り分け

まず、リクエストに明示されたシグナルを分類します。

• React、Vue、Angular、Astro、SPA、コードサイト、または powerpages.config.json → SPA サイト
• 非 SPA、クラシック、従来型、宣言型、Enhanced、EDM、Standard データモデル、.portalconfig、 または website.yml → 非 SPA サイト

リクエストで明示されていない場合は、現在のワークスペース内で次を検索します。

• powerpages.config.json を含む SPA のルート
• .portalconfig/ と website.yml の両方を含む非 SPA のルート。ネストされた .powerpages-site/ も対象です。

依存関係、ビルド出力、一時ファイル、生成出力、およびバージョン管理のディレクトリは除外します。 リクエスト内のパスと現在のディレクトリを使って、プロジェクトを 1 つに絞り込みます。最初に見つかった結果を恣意的に選んではいけません。

🚦 ゲート（計画 · deploy-site:0.project-type）： SPA サイトと非 SPA サイト、または複数の有効なルートが候補に残る場合は、正確なプロジェクトを選択します。

発動条件： 検出後も、プロジェクトの種別またはルートが曖昧な場合。 理由： 2 種類のサイトでは、互換性のない PAC アップロードコマンドが必要です。 キャンセル時の状態： 変更なし。ビルドもアップロードも開始されていません。

曖昧な場合は、AskUserQuestion を使って、検出された種別と正確なプロジェクトルートを選択します。

• 非 SPA サイト： ${PLUGIN_ROOT}/skills/deploy-site/workflows/non-spa-site.md を読み、記載の手順に従います。以下の SPA フェーズには進まないでください。
• SPA サイト： 以下の既存のワークフローに進みます。

非 SPA のアップロード承認

正式なマーカーとプロンプトは workflows/non-spa-site.md に記載されています。 ゲート deploy-site:non-spa-4.permissions-audit では、アップロード前に権限に関わる変更を処理します。 ゲート deploy-site:non-spa-5.upload では、アップロードの直前に、正確なルート、環境、Web サイト ID、モデル、およびローカル変更の概要について承認を得ます。

SPA サイトのデプロイワークフロー

以下のフェーズでは、既存の SPA の動作を維持します。

---

フェーズ 1：PAC CLI の確認

目標：PAC CLI がインストールされ、システム PATH から利用できることを確認します。

操作：

1. 6 つすべてのフェーズを含む ToDo リストを作成します（進捗の追跡の表を参照）。

2. pac help を実行して、PAC CLI がインストールされ、システム PATH から利用できることを確認します。

   pac help
   

3. コマンドが成功した場合：PAC CLI はインストールされています。フェーズ 2 に進みます。

4. コマンドが失敗した場合（コマンドが見つからない／認識されない）：

   1. PAC CLI が必要ですが、インストールされていないことをユーザーに伝えます。

   2. 次の方法で https://aka.ms/PowerPlatformCLI からインストール手順を取得します。

      • ユーザーに次のように伝えます：「PAC CLI はインストールされていません。次のコマンドを実行してインストールできます。」

        dotnet tool install --global Microsoft.PowerApps.CLI.Tool
        

      • dotnet も利用できない場合は、.NET SDK のセットアップを含む完全なインストール手順について、https://aka.ms/PowerPlatformCLI を案内します。

   3. インストール後、再度 pac help を実行して確認します。

   4. それでも失敗する場合は停止し、ユーザーに手動でインストールを解決するよう依頼します。

出力：PAC CLI がインストールされ、確認済み

---

フェーズ 2：認証を確認する

目標：ユーザーが PAC CLI で認証され、有効なセッションがあることを確認します。

アクション：

1. pac auth who を実行して、現在の認証状態を確認します。

   pac auth who
   

2. 認証済みの場合：出力から次の値を取得します。

   • 環境名とURL
   • 環境 ID — Environment ID: の後に続く GUID
   • クラウド — Cloud: の後に続く値（例：Public、UsGov、UsGovHigh、UsGovDod、China）

   フェーズ 3 に進みます。

3. 未認証の場合：

   1. PAC CLI で認証されていないことをユーザーに伝えます。

   2. AskUserQuestion を使用して、環境 URL を尋ねます。

      質問	ヘッダー	オプション
      PAC CLI で認証されていません。認証できるように、Power Pages 環境の URL（例：https://org12345.crm.dynamics.com）を入力してください。	認証	（「Other」から自由入力）

      ユーザーを案内するため、次の 2 つのプレースホルダーオプションを提示します。

      • 「URL を貼り付けます」（説明：「下の『Other』を選択し、環境 URL を貼り付けてください」）
      • 「URL がわかりません」（説明：「Power Platform 管理センターの［環境］> 対象の環境 >［環境 URL］で確認できます」）

   3. ユーザーが URL を入力したら、認証コマンドを実行します。

      pac auth create --environment "<USER_PROVIDED_URL>"
      

      ブラウザーウィンドウが開き、ユーザーはサインインできます。

   4. コマンドの完了後、pac auth who を再度実行して確認します。

   5. 認証に成功したら、フェーズ 3 に進みます。

   6. 認証に失敗した場合は、エラーをユーザーに提示して、トラブルシューティングを支援します。

出力：環境名と URL を取得した、認証済みの PAC CLI セッション

---

フェーズ 3：環境を確認する

目標：ユーザーが正しいターゲット環境にデプロイすることを確認します。

アクション：

🚦 ゲート（同意・deploy-site:3.confirm-env）： 現在の環境を伝え、アップロードの前に明示的な確認を求めます。同じセクション内の「別の環境を選択する」という追加プロンプトにも適用されます。このスキルにおいて、誤った環境へのデプロイは共有状態を破壊する最大の原因であるため、PAC CLI に見覚えのある環境が表示されている場合も、このゲートを必ず実行してください。

トリガー： フェーズ 3 の開始時。PAC CLI から環境が特定されたとき。 確認が必要な理由： サイトが誤ったテナント／環境にアップロードされると、ユーザーの意図しない Dataverse インスタンスに変更が確定されます。クリーンアップには手動での削除、または別の環境からの再デプロイが必要です。 キャンセル時の状態： 変更なし — アップロードは実行されていません。

1. 現在の環境情報をユーザーに提示し、確認を求めます。

   次の形式で AskUserQuestion を使用します。

   質問	ヘッダー	オプション
   現在、環境 <ENV_NAME>（<ENV_URL>）に接続しています。この環境にデプロイしますか？	環境	はい、この環境を使用する、いいえ、別の環境を選択する

2. 「はい、この環境を使用する」の場合：フェーズ 4 に進みます。

3. 「いいえ、別の環境を選択する」の場合：

   1. pac org list を実行して、利用可能なすべての環境を取得します。

      pac org list
      

   2. 出力を解析して、環境名と URL を取得します。

   3. AskUserQuestion を使用して、利用可能な環境をオプションとして提示します（関連性の高いものを最大 4 つ選ぶか、ユーザーに指定してもらいます）。

   4. ユーザーが環境を選択したら、次のコマンドで切り替えます。

      pac org select --environment "<SELECTED_ENV_ID_OR_URL>"
      

   5. pac auth who を再度実行して、切り替えを確認します。

出力：デプロイ先として確認済みの環境

---

フェーズ 4：SPA サイトをデプロイする

目標：プロジェクトを見つけてビルドし、Power Pages にアップロードします。

アクション：

4.1 プロジェクトルートを特定する

プロジェクトのルートディレクトリを特定します。プロジェクトルートは、powerpages.config.json を含むディレクトリです。Glob を使用して検索します。

**/powerpages.config.json

🚦 ゲート（plan · deploy-site:4.1.multi-project）： powerpages.config.json の候補が複数見つかりました。デプロイするプロジェクトを選択してください。

トリガー： フェーズ 4.1 の glob で複数の一致が返されました。 確認する理由： 別のサイトのファイルを誤ってアップロードすると、対象環境が汚染されます。 キャンセル時： 何も起こりません。アップロードは実行されていません。

現在の作業ディレクトリまたはそのサブディレクトリ内に見つかった場合は、そのディレクトリを PROJECT_ROOT として使用します。複数見つかった場合は、AskUserQuestion を使用して、どれをデプロイするかユーザーに尋ねます。

見つからない場合は、プロジェクトルートへのパスをユーザーに尋ねます。

4.2 権限監査を提案する（再デプロイのみ）

.powerpages-site がすでに存在する場合（つまり、初回デプロイではない場合）、テーブル権限とサイト設定が前回のデプロイ以降にコードと異なっている可能性があります。デプロイ前に監査を提案します。

🚦 ゲート（plan · deploy-site:4.2.audit-permissions）： 再デプロイを検出しました。プッシュ前にコードとテーブル権限の差異を確認するため、/audit-permissions の実行を提案してください。

トリガー： .powerpages-site が存在します（初回デプロイではありません）。 確認する理由： 古い権限 YAML がデプロイされると、次回の監査が実行されるまでユーザーに 403 エラーが発生します。 キャンセル時： 何も起こりません。監査は読み取り専用です。辞退した場合はビルドとアップロードに進みます。

AskUserQuestion を使用します。

質問	ヘッダー	選択肢
このサイトは以前にデプロイされています。デプロイ前に、テーブル権限が現在のコードと一致していることを確認するため、権限監査を実行しますか？	監査	はい、権限を監査する（推奨）、スキップ — 権限は最新です

「はい」の場合：/audit-permissions を呼び出して監査を実行します。監査の完了後、ステップ 4.3 に進みます。 「スキップ」の場合：ステップ 4.3 に進みます。

.powerpages-site が存在しない場合（初回デプロイ）は、監査対象となる既存の権限がないため、このステップをスキップします。

4.3 サイトをビルドする

アップロードの前に、サイトがビルドされていることを確認します。

cd "<PROJECT_ROOT>"
npm run build

ビルドに失敗した場合は処理を停止し、再試行の前にユーザーがビルドエラーを修正できるよう支援します。

4.4 Power Pages にアップロードする

アップロードコマンドを実行します。

pac pages upload-code-site --rootPath "<PROJECT_ROOT>"

アップロードに成功した場合：フェーズ 5 に進み、デプロイを確認します。

アップロードに失敗した場合：エラーメッセージを確認します。

• ブロックされた JavaScript（.js）添付ファイルに関連する失敗の場合 → フェーズ 6 に進みます
• 「.html タイプの添付ファイルは現在ブロックされています」というエラーの場合 → これは誤解を招くエラーです。下記のトラブルシューティング：HTML ブロック添付ファイルエラーを参照してください
• その他のエラーの場合 → エラーをユーザーに提示し、トラブルシューティングを支援します

出力：サイトがビルドされ、Power Pages にアップロードされました

---

フェーズ 5：デプロイを確認する

目標：デプロイが成功したことを確認し、デプロイ後の手順を実施します

操作：

5.1 .powerpages-site フォルダーを確認する

.powerpages-site が存在することを確認し、その内容（web-roles/、site-settings/、table-permissions/）を一覧表示します。

5.2 スキルの使用状況を記録する

参照先：${PLUGIN_ROOT}/references/skill-tracking-reference.md

参照先のスキル追跡手順に従って、このスキルの使用状況を記録します。--skillName "DeploySite" を使用します。

5.3 アップロードの出力を確認する

フェーズ 4（またはフェーズ 6 の再試行）で実行した pac pages upload-code-site コマンドの出力を確認します。エラーなしでアップロードに成功したことが報告されているか確認します。

5.4 変更をコミットする

デプロイ成果物をステージングしてコミットします。

git add -A
git commit -m "Deploy site to Power Pages"

5.5 有効化ステータスを確認する

有効化ステータスの確認を実行します。

node "${PLUGIN_ROOT}/scripts/check-activation-status.js" --projectRoot "<PROJECT_ROOT>"

JSON の結果を評価します。

• activated が true の場合：サイトはすでに有効化されていることをユーザーに伝えます（websiteUrl があれば表示します）。手順 5.6 に進み、その後 次のステップを提案する に進みます。有効化について質問しないでください。
• activated が false の場合：手順 5.5.1 に進みます。
• error がある場合：手順 5.5.1 に進みます。デプロイのフローを止めないでください。

5.5.1 有効化について確認する（サイトがまだ有効化されていない場合のみ）

🚦 ゲート（plan · deploy-site:5.5.1.activate）： サイトはデプロイ済みですが、まだ有効化されていません。サブドメインを割り当てるために /activate-site を実行するか、ユーザーに確認します。

トリガー： フェーズ 5.5 で、新規デプロイの activated:false が検出されました。 確認する理由： 自動有効化すると誤ったサブドメインが設定され（サイトに対して永続的です）、自動的にスキップするとサイトに公開 URL が割り当てられません。 キャンセル時の状態： 変更なし。有効化 API は呼び出されていません。

AskUserQuestion を使用して、サイトを有効化するかユーザーに確認します。

質問	ヘッダー	選択肢
サイトのデプロイが成功しました！サイトを有効化（プロビジョニング）して、公開 URL を取得しますか？	有効化	今すぐ有効化（推奨）— サイトにサブドメインを割り当てて公開する、今回はスキップ — 後で有効化します

「今すぐ有効化」の場合：/activate-site スキルを実行します。有効化が完了したら、サイトのキャッシュをクリアするために手順 5.6 に進みます。 「今回はスキップ」の場合：次のステップを提案する に進みます。

5.6 サイトのキャッシュをクリアする（有効化済みの場合のみ）

サイトが有効化されていることを確認した後（手順 5.5 の時点ですでに有効化されていた場合、または手順 5.5.1 でユーザーが有効化した場合）、デプロイした変更をすぐに反映するため、ランタイムキャッシュのクリアを提案します。

前提条件：サイトが有効化されており、プロジェクトのルートが特定されている必要があります（フェーズ 4.1 で取得）。

🚦 ゲート（plan · deploy-site:5.6.restart-cache）： デプロイしたサイトを再起動して、ランタイムキャッシュを消去します。短時間（数秒）の本番環境の停止が発生するため、操作を元に戻せる場合でも、ユーザーの明示的な同意が必要です。

トリガー： サイトが有効化されていることを確認済みです（以前から有効化されていた場合、または手順 5.5.1 で有効化された場合）。 確認する理由： キャッシュの TTL が切れるまで、本番環境のユーザーには数分間、古いコンテンツが表示されます。 キャンセル時の状態： 変更なし。デプロイ自体はすでに成功しており、キャッシュは自動的に更新されます。

続行する前に、AskUserQuestion を使用して確認します。

質問	ヘッダー	選択肢
最新の変更をすぐに反映するため、サイトを再起動しますか？数秒間の停止が発生する可能性があります。	再起動	はい、サイトを再起動する（推奨）、スキップ — 後で再起動します

「スキップ」の場合：次のステップを提案する に進みます。

「はい」の場合：プロジェクトのルートを渡して、キャッシュをクリアするスクリプトを実行します。

node "${PLUGIN_ROOT}/scripts/clear-site-cache.js" --projectRoot "<PROJECT_ROOT>"

スクリプトは powerpages.config.json から siteName を読み取り、Power Platform API を使用してウェブサイトを検索し、ランタイムキャッシュを消去するために再起動します。

結果を評価します。

• success が true の場合：ユーザーに「サイトのキャッシュをクリアしました。最新の変更が に表示されるはずです。」と伝えます。
• success が false の場合：キャッシュのクリアに失敗したことを警告し、エラーを表示します。ただし、デプロイのフローは止めないでください。デプロイ自体は成功しており、キャッシュはやがて自動的に更新されます。必要であれば、ユーザーが Power Pages 管理センターから手動でキャッシュをクリアできることを伝えます。

出力：デプロイを検証済み、変更をコミット済み、有効化を提案済み、キャッシュをクリア済み

---

フェーズ 6：ブロックされた JavaScript の処理

目標：ブロックされた JavaScript の添付エラーを解決し、デプロイを再試行します。

アクション：

6.1 問題を説明する

ユーザーに次のように伝えます。

「Power Pages 環境では JavaScript（.js）ファイルの添付がブロックされているため、アップロードに失敗しました。これは .js ファイルのアップロードを防ぐセキュリティ設定です。SPA サイトをデプロイするには、.js ファイルに対するこの制限を緩和する必要があります。」

6.2 許可を求める

🚦 ゲート（同意 · deploy-site:6.2.unblock-js）： blockedattachments の変更を伴うリアクティブな操作 — 共有状態に対する破壊的変更（テナント全体の環境設定）です。deploy-pipeline:7.6.2.blocked-attachments と同じ形式です。

トリガー： .js がブロックされているというエラーでアップロードに失敗しました。 確認する理由： 自動的なブロック解除は、明示的な同意なしにテナントのセキュリティ設定を変更します。この変更はこのサイトだけでなく、環境全体に適用されます。 キャンセル時の状態： attachment-block-modified が発生するのは、ユーザーが承認した後に下流の手順が一部完了した場合のみです。ここで単にキャンセルした場合は何も変更されず、元の blockedattachments の値はそのままです。

AskUserQuestion を使用します。

質問	ヘッダー	選択肢
環境のブロック対象添付ファイルの一覧から JavaScript（.js）のブロックを解除しますか？SPA サイトをデプロイするには、ブロックの解除が必要です。	JS のブロック解除	はい、.js のブロックを解除する（推奨）、いいえ、環境設定を変更しない

「いいえ」の場合：.js 添付ファイルのブロックを解除しない限りデプロイを続行できないことをユーザーに伝え、停止します。

「はい」の場合：6.3 に進みます。

6.3 ブロック対象の添付ファイルを更新する

1. pac env list-settings を実行し、現在の環境設定を取得します。

   pac env list-settings
   

2. 出力から blockedattachments プロパティを探します。セミコロン区切りのファイル拡張子の一覧が含まれています（例：ade;adp;app;asa;ashx;asmx;asp;bas;bat;cdx;cer;chm;class;cmd;com;config;cnt;cpl;crt;csh;der;dll;exe;fxp;hlp;hta;htr;htw;ida;idc;idq;inf;ins;isp;its;js;jse;ksh;lnk;mad;maf;mag;mam;maq;mar;mas;mat;mau;mav;maw;mda;mdb;mde;mdt;mdw;mdz;msc;msh;msh1;msh1xml;msh2;msh2xml;mshxml;msi;msp;mst;ops;pcd;pif;prf;prg;printer;pst;reg;rem;scf;scr;sct;shb;shs;shtm;shtml;soap;stm;tmp;url;vb;vbe;vbs;vsmacros;vss;vst;vsw;ws;wsc;wsf;wsh）。

3. 一覧から js を削除します。セミコロン区切りの値を解析して js を除外し、セミコロンで再結合します。

4. 設定を更新します。

   pac env update-settings --name blockedattachments --value "<UPDATED_LIST_WITHOUT_JS>"
   

5. 更新が成功したことを確認します。

6.4 アップロードを再試行する

アップロードコマンドを再度実行します。

pac pages upload-code-site --rootPath "<PROJECT_ROOT>"

成功した場合：フェーズ 5 に進み、デプロイを検証します。

別のエラーが発生して失敗した場合は、エラーをユーザーに示し、トラブルシューティングを支援します。

出力：JavaScript のブロックが解除され、サイトが正常にデプロイされました

---

トラブルシューティング：HTML 添付ファイルのブロックエラー

次のようなエラーでアップロードに失敗した場合：

Error: Unable to upload webfile name 'index.html' with record Id <GUID> as '.html' type attachments are currently blocked on this environment.

このエラーの内容は誤解を招きます。 .html 拡張子は実際にはブロックされていません。実際の原因は、.powerpages-site フォルダー内にある古い環境マニフェストファイルです。このマニフェストは、ローカルファイルと以前のアップロード時の Dataverse レコード ID を対応付けます。環境の変更やレコードの削除などにより対応付けが古くなると、この紛らわしいエラーが発生してアップロードに失敗します。

修正方法

1. .powerpages-site フォルダー内にある環境固有のマニフェストファイルを見つけます。ファイル名は <environment-host>-manifest.yml の形式です（例：demo1.crm.dynamics.com-manifest.yml）。ファイル検索ツール（例：Glob でパターン <PROJECT_ROOT>/.powerpages-site/*-manifest.yml を指定）を使用して見つけます。

2. <PROJECT_ROOT>/.powerpages-site/<environment-host>-manifest.yml にあるマニフェストファイルを削除します。

3. アップロードを再試行します。

   pac pages upload-code-site --rootPath "<PROJECT_ROOT>"
   

再試行が成功した場合は、フェーズ 5 に進みます。別のエラーが発生して失敗した場合は、エラーをユーザーに示し、トラブルシューティングを支援します。

重要：環境のブロック対象添付ファイルの一覧で .html のブロックを解除しないでください。このエラーは添付ファイルのブロック設定が原因ではありません。

---

次のステップを提案する

ユーザーが有効化をスキップした場合（または有効化の完了後）は、次の操作を提案します。

• /activate-site — サブドメインを使ってサイトをプロビジョニングし、公開します（まだ有効化されていない場合）
• /test-site — ブラウザーでデプロイ済みサイトをテストします（ページの読み込みを確認し、API 呼び出しをチェックします）
• /audit-permissions — 現在のコードと照らし合わせてテーブルの権限を監査します（再デプロイ後に推奨）
• /setup-datamodel — 動的コンテンツ用の Dataverse テーブルを作成します
• /add-seo — メタタグ、robots.txt、sitemap.xml、ファビコンを追加します

---

重要な注意事項

pac pages upload は絶対に使用しないでください

常に pac pages upload-code-site を使用し、pac pages upload は絶対に使用しないでください。pac pages upload コマンドはポータルスタジオ形式のサイト用に設計されており、SPA サイトプロジェクトで使用すると、SPA サイトのメタデータが破損します。このスキルのすべてのアップロード手順（フェーズ 4.4、フェーズ 6.4、トラブルシューティング時の再試行）に適用されます。

すべてのフェーズを通じて

• TaskCreate/TaskUpdate を使用して、各フェーズの進捗を追跡します
• 重要な判断ポイントでユーザーに確認します（以下の一覧を参照）
• エラーを明確に提示します — コマンドが失敗した場合は、修正方法を提案する前に、関連するエラー出力をユーザーに示し、何が起きたかを説明します

重要な判断ポイント（ユーザーの応答を待つ）

1. フェーズ 2 の後：認証されていない場合は、環境 URL をユーザーから取得します
2. フェーズ 3：対象環境を確認するか、切り替えます
3. フェーズ 4.1：powerpages.config.json が複数見つかった場合は、どのプロジェクトをデプロイするかユーザーに確認します
4. フェーズ 4.2：今すぐ権限を監査するか、スキップするかを確認します（再デプロイの場合のみ）
5. フェーズ 5.5：今すぐサイトを有効化するか、後で有効化するかを確認します
6. フェーズ 6：ブロックされた添付ファイルの設定を変更する前に許可を得ます

進捗の追跡

フェーズ 1 を開始する前に、TaskCreate を使用してすべてのフェーズを含むタスクリストを作成します。

Task subject	activeForm	Description
PAC CLI のインストールを確認	PAC CLI を確認中	PAC CLI がインストールされているか確認し、未インストールの場合はインストールします
認証を確認	認証を確認中	現在の認証状態を確認し、必要に応じて認証します
対象環境を確認	環境を確認中	現在の環境を表示し、ユーザーに確認または切り替えを行ってもらいます
SPA サイトをデプロイ	サイトをデプロイ中	プロジェクトのルートを特定し、ビルドして、pac pages upload-code-site を使ってアップロードします
デプロイを確認	デプロイを確認中	.powerpages-site フォルダーの存在を確認し、アップロード出力を確認して、変更をコミットし、有効化を提案します
ブロックされた JavaScript に対処	JS のブロックを解決中	JavaScript がブロックされてアップロードに失敗した場合、ブロックを解除して再試行するか確認します

各タスクは、開始時に TaskUpdate で in_progress に設定し、完了時に completed に設定します。JavaScript のブロックに関する問題が発生しなかった場合は、フェーズ 6 を直ちに completed に設定できます。これにより、ユーザーは進捗を把握でき、ワークフローを予測可能な形で進められます。

---

フェーズ 1：PAC CLI の確認から開始します