azure-app-onboard

何を作るかは分かっているが、どのサービスを使えばいいか分からないときに効きます。入口は、事業の構想、アプリの構想、既存のアプリのどれでも構いません。出口は、Azure で実際に動いている状態です。

説明文に並ぶ呼び方は「アプリを Azure に持っていきたい」「動かすといくらかかるか」「コードはデプロイできる状態か」「まだコードが無い」「書き直さずに Azure へ移したい」などです。

本体の進め方

10 手順

承認の関門（IaC の生成の前、デプロイの前）

2 回

同梱ファイル（下位の SKILL.md 3 件を含む）

67 件

同梱の数は 2026-10-22 時点で、SKILL.md 自身を除いて数えています。

4 段を 10 の手順で進める

段は、点検 → 設計 → IaC の生成 → デプロイ の 4 つです。本文の冒頭は、どのリポジトリも 10 の手順を全部通せと決めています。見覚えのある構成だからといって、手順を飛ばしたり断ったりしない、という決まりです。

1. 記録とログイン作業の記録を作るか続きから再開し、Azure CLI のログインとサブスクリプションを確かめる
2. 範囲の振り分けazd の雛形や既存の IaC があるかを見る
3. 点検azure-app-onboard-prereq を呼ぶ。止まる判定なら止まる
4. 意図の確認点検の結果を見せ、技術とサービスを確かめる
5. 設計サービス・SKU・費用・名前を決めて計画に書く
6. 1 回目の承認ファイルを作る前に計画を見せる
7. IaC の生成Bicep か Terraform を作り、自分で点検する
8. 2 回目の承認検証の結果と費用を見せる
9. デプロイIaC を流し、コードを載せ、応答を確かめる
10. 引き渡し置き場所・片付けのコマンド・再デプロイのコマンド・次の提案

点検だけのスキルとの使い分け

同じ公開元の azure-app-onboard-prereq は、この流れの 3 番目の手順を単体で切り出したものです。

点検だけ済ませて結果を見たいなら prereq、Azure に実際に載せるところまで任せたいならこちらです。

本文の「使わない場面」の表は 7 行あり、それぞれ別のスキルを案内しています。

• azd up や既存のデプロイを流すazure-deploy の担当
• 構成が決まっていて Bicep や Terraform を作るだけazure-prepare の担当
• IaC の点検や事前のチェックazure-validate の担当
• 動いているデプロイの不具合を追うazure-diagnostics の担当
• AKS や Kubernetes を直接扱うazure-kubernetes の担当
• 既存のリソースを探す・一覧にするazure-resource-lookup の担当

既存の azd の雛形をそのまま流すなら azure-deploy、IaC を作るだけなら azure-prepare、点検は azure-validate、不具合は azure-diagnostics、Kubernetes は azure-kubernetes、リソース探しは azure-resource-lookup です。

残る 1 行は、すでに払っている費用を減らしたいときで、任意の azure-cost のプラグインにある cost-optimization を案内しています。

既存の azd の雛形があるリポジトリ

azure.yaml と infra/ の IaC がそろい、azure.yaml にサービスが 1 件以上あれば、この流れを続けずに azure-prepare へ回します。このスキルは新しく組むためのもので、既存の Azure の IaC があるリポジトリは別の流れの担当、という整理です。

実際にリソースを作り、費用が発生する

デプロイの段では、az deployment sub create（Terraform なら terraform apply）でリソースを作り、コードを載せます。SKILL.md の解析で見つかった記述は az role assignment のシェル実行だけですが、下位の SKILL.md と同梱の資料には、デプロイ・ビルド・設定の変更のコマンドが多く書かれています。

デプロイの前には what-if の確認が必須です。リージョン・サービスの種類・SKU が承認したものから変わると、承認を取り直します。自分で点検した結果、セキュリティか、存在しない名前や版を書いていないかの層で問題が残っていれば、デプロイに進めません。

データベースを外に開く既定

計画に PostgreSQL や MySQL があると、既定の設定では Azure の全サービスからの接続を許す規則（0.0.0.0）が入ります。1 回目の関門は、このことを独立した太字の文で見せ、「Private access」の選択肢を出す決まりです。

私設の網（VNet と private endpoint）を選ぶと、このスキルはそこで止まり、azure-enterprise-infra-planner に設計とデプロイを引き渡します。こちらには戻ってきません。

消す操作は利用者に任せる

同梱の禁止の一覧は、エージェント自身が流してはいけないコマンドを並べています。主なものは次のとおりです。

• az group delete は絶対に流さない。片付けのコマンドは引き渡しの文に書き、利用者が流す
• terraform destroy、DROP TABLE や DROP DATABASE、新しい一時フォルダの外での rm -rf
• git reset --hard などの未コミットの作業を消す操作、強制の push、--no-verify
• 失敗したデプロイを通すために、TLS や HTTPS の強制などの守りを弱めること

引き渡しでは、そのリソースグループを消すコマンドと、作業の印のタグで同じ回のリソースグループをまとめて消すコマンドの両方を、必ず出す決まりです。

リポジトリに作業の記録と秘密の控えを置く

.copilot-azure/sessions/ の下に、計画や結果の JSON、デプロイの手順書を書き出します。最初に、.gitignore に .copilot-azure/ が無ければ足します。記録に秘密が入りうるため、と書かれています。

パスワードは利用者に聞かずに自動で作り、Key Vault に入れます。再試行で使い回すための控えを deploy-secrets.env として記録の中に置きます。有効な回でない記録は、最終更新から 7 日を過ぎると、次に呼んだときに消されます。

デプロイ後に設定を変える

App Service と Functions のアプリには、デプロイのあとで基本認証での配置（SCM）を無効にするコマンドを必ず流します。デプロイの前にはポータルの画面の URL を作り、ブラウザで自動で開きます。

手元のコードは書き直さない

動いているアプリのコードを作り直したり、版を上げたりはしない決まりです。ビルドの失敗や依存の欠けを直すのは、承認を経てなら構いません。版上げの提案は、引き渡しの「次の提案」に回します。

まだコードが無くても使えますか

使えます。説明文の呼び方に「まだコードが無い」「雛形のプロジェクト」が入っていて、空の作業場所なら点検の段のコードが無い場合の道に進みます。

azd は使いますか

使いません。azure.yaml を作らず、azd up などのコマンドも流さない決まりで、Bicep は az deployment sub create、Terraform は terraform apply でデプロイします。流れの途中で azure-deploy などのスキルを呼ぶことも禁じていて、呼んでよいのは点検の azure-app-onboard-prereq だけです。範囲外と分かったときに azure-prepare などへ回すことはあります。

デプロイが失敗したらどうなりますか

エラーを分類して、直しながらやり直します。3 回やり直したところで利用者に聞き、その後は 5 回ごとに聞きます。直せずに終わっても、失敗の内容を結果のファイルに書いてから止まります。

終わったあと、コードを直したらどう載せ直しますか

引き渡しで、デプロイの段で実際に流したコードの配置のコマンドを、再デプロイのコマンドとして出す決まりです。流れ全体は最初の 1 回だけの準備で、そのあとはビルドして載せ直すだけ、という位置づけです。

費用の見積もりはどこから来ますか

Azure の MCP サーバーの料金の道具で、有料のサービスごとに調べます。使えないときは、Azure の公開の料金の API を直接引く手順に切り替えます。見積もりと承認の関門には、MCP が使えなかったという注記を足します。