azure-app-onboard-prereq

Azure App Onboard の前提条件 — リポジトリの評価

インフラストラクチャの計画前に、ユーザーのリポジトリのビルドの健全性、アプリの完成度、Azure へのデプロイ可能性を評価します。後続のフェーズで使用するコンポーネントごとの判定（PASS/WARN/FAIL）を生成します。

オーケストレーターとの関係： Step 3 で azure-app-onboard から呼び出されるか、コードの準備状況を確認するために単独で実行されます。オーケストレーターから呼び出された場合は、成果物を書き込んだ後、制御を azure-app-onboard に戻してください。後続のフェーズを直接呼び出してはいけません。

AppOnboard パイプラインの 4 フェーズ中のフェーズ 1 です。セッション：.copilot-azure/sessions/{session-id}/。context.json を読み込みます。components[]、repo{}、detectedInfra[] を書き込みます。prereq-output.json を生成します。スキーマ：prereq-schemas.ts — PrereqOutput、BuildRequirements。直接実行にも対応しています。

使用しない場合

シグナル	リダイレクト先
インフラストラクチャを検証する（Bicep/TF/azure.yaml）	azure-validate
IaC を生成する	azure-prepare
アイデアから本番環境までエンドツーエンドで進める	azure-app-onboard
azd up の実行またはデプロイ	azure-deploy

ルール

⛔ 絶対禁止 — npm install、npm test、npx jest、pytest、およびすべてのインストール／ビルド／テストコマンドは、いかなる場合も実行してはいけません。 いかなる状況でも、前提条件フェーズ中に npm install、npm test、npx jest、pip install、pytest、dotnet build、dotnet restore、dotnet test、go mod download、cargo build、またはパッケージマネージャーによるインストール／ビルド／テストコマンドを実行してはいけません。コードを検証するためにテストスイートを実行してはいけません。代わりに、テスト設定ファイルを静的に確認してください。前提条件フェーズで許可されるのは、読み取り専用の評価と静的検証のみです。 唯一の例外 — いずれも同意が必要な、許可された 2 つの状況： (a) 移行／修正中にエージェントが変更したコード（remediation-protocol.md の step 6 を参照）、または (b) ゼロコードパスでエージェントが新規に作成したコード（zero-code-path.md を参照）。どちらの場合も、インストール／ビルド／テストの実行は、ユーザーが個別のコマンドごとの同意プロンプトに回答した後に限り、ユーザー確認済みのビルド検証ゲート（build-check.md の Step 3）を通じてのみ許可されます。事前の包括的な同意は有効ではありません。

1. ⛔ 例外なく、パイプライン全体（Steps 1–8）を実行してください。 すべてのプロンプトの後、直接 Step 1 に進みます。具体的な質問には、事前ではなく、調査結果の一部として（Step 5）回答してください。
2. ⛔ 評価にサブエージェントを使用してはいけません。 3 軸評価はインラインで行います。例外： ゼロコードパスでのスキャフォールディング（Step 2）。
3. コードの変更や破壊的な変更には ask_user が必要です。結果を提示するまでの質問は最大 3 つです。直接実行の場合、オーケストレーターが行った意図確認の質問を繰り返してはいけません。

MCP ツール

ツール	目的
mcp_azure_mcp_get_azure_bestpractices	検出されたスタックのパターンを Azure のベストプラクティスに照らして検証します
mcp_azure_mcp_extension_cli_install	必要な CLI ツール（az、azd、func）を確認／インストールします

ワークフロー

Step 1：セッションの確認

オーケストレーターからの実行： セッションが存在する場合は、context.json を読み込み、Step 2 に進みます。

直接実行： .copilot-azure/sessions/active-session.json を確認します。

• 存在する → 再開／新規のゲートについて、session-protocol.md を読みます。ユーザーの回答を得るまでは先に進んではいけません。
• 存在しない → セッションを作成します：UUID を生成し、New-Item -ItemType Directory -Path ".copilot-azure/sessions/{uuid}" -Force を実行し、create ツールで context.json と active-session.json を書き込みます。

次に、az account show を実行し、{id, name, tenantId} を context.json.azure にマージします。⛔ スキャンを開始する前に、セッションがディスク上に存在していなければなりません。

ステップ 2：ワークスペースのスキャン

プロジェクトファイルをスキャンします。コンポーネント、repo{}、detectedInfra[]、detectedServices[] を検出します。Terraform プロバイダーを分類します。CLI が利用可能か確認します。スタック検出の不一致：ユーザーによる明示的な説明を優先します（context.json に記録し、スキャンを上書きとしてマークします）。スキャンのみの場合 → ユーザーに確認します。複数のスタックがある場合 → すべてを提示して質問します（component-mapping.md を参照）。コードがない場合 → zero-code-path.md。

プロジェクトファイルも Dockerfile も index.html もない場合 → ⛔ zero-code-path.md を読みます。

⛔ Cloud SDK の早期ゲート。 aws-sdk|@aws-sdk|boto3|google-cloud|@google-cloud|firebase を grep します。機能上の依存関係が見つかった場合 → cloud-sdk-migration.md を読み、その後 ask_user：「Azure Cloud Migrate にリダイレクト」（routeToSkill: "azure-cloud-migrate" を設定）・「それでも評価を続行」（準備状況の評価と SDK→Azure のマッピングを完了し、ステップ 8 で停止します — 依存関係を置き換えるまでプランは作成しません）・「キャンセル」。

ステップ 3：コンポーネントごとの評価

サブステップ	アクション	リファレンス
3.1	ビルドチェック	⛔ build-check.md を必ず読んでください
3.2	完全性チェック	⛔ completeness-check.md を必ず読んでください
3.3	デプロイ可能性チェック	⛔ deployability-check.md を必ず読んでください
3.3a	コンポーネントマッピング（条件付き）	プロジェクトマニフェストが複数見つかった場合（モノレポ）のみ、component-mapping.md を読みます

評価後、コンポーネントごとに buildRequirements を設定します。判定の伝播、ティアルール、f1Viable の集約については、readiness-gate.md と各チェックのリファレンスを参照してください。

ステップ 4：アーティファクトの書き込みと準備状況ゲート

⛔ context.json がディスク上に存在することを確認します。readiness-gate.md（判定、ティア、バッチ処理後の承認、ファストトラック）を読み、その後 prereq-artifacts.md（書き込み手順、スキーマ）を読みます。

ステップ 5：調査結果の提示

readiness-gate.md § 調査結果の提示 に従い、続行する前に重大度ごとにまとめた判定を提示します。

ステップ 6：修正（条件付き）

❌ FAIL 判定、🔧 推奨される修正、または fixPhase: "prereq" を伴う ⚠️ WARN がある場合は、⛔ remediation-protocol.md を必ず読んでください。修正ループ、静的検証、再評価の必須要件、修正後のアーティファクト更新、ビルド検証への同意ゲートについて説明しています。すべての判定が ✅ PASS、または fixPhase: "prereq" を伴わない ⚠️ WARN の場合は、ステップ 7 に進みます。

ステップ 7：最終状態の書き込み

completedPhases にはすでに "prereq" があり、currentPhase: null になっています（ステップ 4 から）。その後：

⛔ lastScanCommit を書き込みます。 git rev-parse HEAD を実行し、完全な 40 文字の SHA を context.json.repo.lastScanCommit に保存します。必須です — ステップ 1 の古さ確認では、再開時に HEAD と比較して変更を検出します。

ステップ 8：ルーティング

⛔ 必須 — このステップをスキップしないでください。

ルーティングフィールド： すべてのルーティングで、context.json に routeToSkill と routeReason を書き込みます。

修正後のコンテキスト： ステップ 6 を実行した場合は、ルーティングプロンプトの先頭に「修正が完了しました — {N} 件の問題を修正し、アプリの全体的な健全性は {overallHealth} になりました。」を追加します。

⛔ 上から順に条件を評価し、最初に一致したものを適用してください。

#	条件	アクション
1	routeToSkill が設定されている（どのエントリでも）	ask_user：「{routeToSkill} にリダイレクト」／「今はしない」。⛔ パイプラインを停止します — アーキテクチャ計画に進まないでください。
2	cloudSdkFindings[] が空でない（ユーザーが「評価を続行」を選択した場合）	クラウド SDK から Azure への置き換えマッピングを 🔶 ブロッカーとして提示し、次の完全一致のプロンプトで ask_user を実行します：「🔶 クラウド SDK の移行が必要です — このアプリを Azure にデプロイするには、これらの依存関係を置き換える必要があります。（azure-cloud-migrate にリダイレクト／停止 — 手動で置き換えて再実行）」 — リダイレクトすると routeToSkill: "azure-cloud-migrate" が設定され、停止すると処理を終了します。⛔ パイプラインを停止します — アーキテクチャ計画に進まず、「準備に進む」オプションも提示しないでください。依存関係を置き換えるまで、アプリはデプロイできません。
3	オーケストレーターで、routeToSkill が設定されていない	ユーザーに「✅ アプリの評価が完了し、準備が整いました — Azure へのデプロイを計画しましょう。」と伝えます。その後、azure-app-onboard を呼び出します。⛔ 停止せず、ユーザー入力を待たず、内部の引き継ぎについて説明しないでください。ユーザーはスコープのトリアージ時に、パイプライン全体への同意をすでに表明しています。
4	直接実行で、ready／readyWithCaveats かつ Azure インフラがない	ask_user：「Azure にデプロイ（フルパイプライン）」→ azure-app-onboard を呼び出す／「今はしない」
5	直接実行で、ready／readyWithCaveats かつ既存の Azure インフラがある	ask_user：「新規に開始」→ azure-app-onboard を呼び出す／「既存のインフラを使用」→ azure-prepare を呼び出す／「今はしない」
6	直接実行で、blocked	ブロッカーの概要と「修正して再実行してください。」を報告します。

重大度の区分（🛑🔶❌🔧⚠️✅）は readiness-gate.md で定義されています。

出力

成果物	場所	利用者
セッションコンテキスト	context.json → components[]、repo{}、detectedInfra[]、detectedServices[]	すべての後続フェーズ
前提条件の出力	prereq-output.json	準備フェーズ（azure-app-onboard 経由）
準備状況レポート	.copilot-azure/sessions/{uuid}/readiness-report.md	ユーザー（オフライン参照用）