GitHub Copilot を活用した Azure インフラ設計の方法

Azure で何か作りたいと思っても、最初からサービス名、SKU、台数、ネットワーク、監視まで決めるのは難しいものです。料金を知りたくても、Azure Pricing Calculator に何を入力すればよいか分からない、というところで止まりがちです。

でも、最初から Azure に詳しい人と同じように考える必要はありません。作りたいものを GitHub Copilot に話し、不足していることを質問してもらい、まず試す具体案を出してもらうところから始められます。

本サイトも、その進め方で作りました。相談から要件を整理し、構成図と Bicep を作り、実際の Azure へデプロイして、動作やコストを見ながら直してきた実例を紹介します。

目次

• 先に結論
• 作りたいものを話すところから始める
• 曖昧な相談が具体案になるまで
• Bicep で動かして確かめる
• 本サイトも相談と検証を繰り返して育った
• まずはこのプロンプトから始める
• Copilot に任せることと人が決めること
• まとめ

先に結論

GitHub Copilot を使う魅力は、Azure の用語を知ってから相談する必要がないことです。

たとえば Plan モードで「小さな Web サービスを Azure で公開したい。利用者はまだ少ない。できるだけ運用を増やしたくない」と話せば、Copilot は不足している要件を質問し、回答をもとにサービス、初期サイジング、構成図、見積もり前提まで具体化できます。

プランに納得できたら Agent モードへ切り替えます。その結果を設計書で終わらせず、Bicep とアプリケーションへ落とし、実際にビルドして試すところまで同じ会話で進められます。

詳しい人の代わりに最終判断をしてもらうのではなく、詳しい人へ相談できる形まで短時間で持っていく。さらに、小さく動かして判断材料を作る。

これなら Azure の経験が少なくても、白紙の状態から一歩目を踏み出しやすくなります。

作りたいものを話すところから始める

本サイトを作り始めたときは、仕様を完全には決めず、まず作りながら考えるつもりでした。

• 個人ブログを復活させたい
• 技術、コミュニティー、写真、日常の記事を分けたい
• コンテンツは GitHub で管理したい
• Azure で動かしたい
• あとからデモや便利な機能を追加したい

このくらいの粒度から GitHub Copilot と会話を始めました。当時は Agent モードへ「まずプランを考えて」と頼みましたが、これから始めるなら、ファイルを変更せずに方針を詰められる Plan モードを使うと設計と実装を分けやすくなります。

すると、「記事は誰が更新するのか」「下書きと公開をどう分けるのか」「画像はどこへ置くのか」「認証は必要か」「障害時にどこまで復旧したいか」といった質問が返ってきます。

Azure を知らないと、自分では何を決め忘れているのかも分かりません。Copilot が質問することで、頭の中にある要望と未決定の部分が分かれます。分からないものは「未定」で構いません。未定だと分かれば、仮の前提を置いて試せます。

曖昧な相談が具体案になるまで

要件がある程度そろうと、Copilot へ「まず動かすならどうするか」を聞けます。このとき、正解を一つ出してもらうのではなく、初期案と、その案を選んだ前提をセットで出してもらうのがポイントです。

たとえば小規模なコンテンツサイトなら、次のような具体案へ進められます。

これは人間の「たぶんこのくらい」という勘を再現するものではありません。利用者数、ピーク時のリクエスト、データ量、許容する応答時間といった前提から、検証を始めるための数値を置くものです。

GitHub Copilot は、その途中でツールも使えます。

• Microsoft Learn MCP Serverで、現在の公式仕様、制約、推奨事項を確認する
• Azure MCP Serverで、サブスクリプション上のリソース、設定、ログ、価格情報などを確認する
• リポジトリを読み、既存のコードや Bicep と提案が矛盾していないか確認する

つまり、一般的な回答だけではなく、公式情報、実際の Azure 環境、現在のコードを材料にして相談を続けられます。

Bicep で動かして確かめる

構成案と初期サイジングが出たら、そこで終わりではありません。Copilot に Bicep を作ってもらい、小さな環境へデプロイして確かめます。

進め方はシンプルです。

1. 作りたいものと、分かっている利用条件を伝える
2. Plan モードで不足要件を質問してもらう
3. 最小構成と初期サイジング、その根拠を出してもらう
4. Microsoft Learn MCP Server で仕様を確認する
5. プランを確認し、Agent モードへ切り替える
6. 構成図、見積もり前提、Bicep を作ってもらう
7. what-if で差分を確認してから Azure へデプロイする
8. 応答時間、エラー、ログ、実際のコストを確認する
9. 結果を Copilot へ返し、構成やサイズを直す

この流れでは、最初のサイジングは完成品ではなく仮説です。負荷が足りなければ上げ、余っていれば下げます。Azure Pricing Calculator の見積もりも、デプロイ後は Microsoft Cost Management の実績と比較して更新します。

Copilot の価値は、仮説から Bicep、デプロイ、計測、修正までの距離を短くできるところにあります。

本サイトも相談と検証を繰り返して育った

2026年7月13日の最初の開発では、Copilot に次の順番で進めたいと伝えました。

1. 設計を docs に残す
2. サイトをデザインする
3. Phase 1 の Bicep を作る
4. アプリケーションをスキャフォールドする

最初のコミットには、docs/architecture.md、docs/design.md、Bicep、Astro、Azure Functions、GitHub Actions が一緒に入りました。会話で整理した内容が、そのまま設計文書と動くコードへつながりました。

最初は、Astro で生成したブログを Azure Static Web Apps で配信する小さな構成でした。そこから「英語記事を作りたい」「Microsoft 関連情報を自動収集したい」「独自ドメインと WAF を使いたい」「Storage を非公開にしたい」「障害や攻撃を検知したい」と相談を重ねました。

そのたびに Copilot と要件を整理し、Microsoft Learn で仕様を確認し、Bicep とアプリケーションを変更し、Azure で試しました。現在は次の構成になっています。

記事、画像、Astro、Functions のコード、Bicep は GitHub で管理しています。main へ反映すると、GitHub Actions が静的サイトをビルドして Azure Static Web Apps へ、API を Azure Functions へデプロイします。Bicep は push のたびに自動実行せず、インフラを変更するときだけ what-if を確認して明示的にデプロイします。

ここまで一度に作ったわけではありません。

たとえば Hot Topics の API では、コストを意識して Function のメモリを小さくした結果、期待した応答時間にならず、実測を見て設定を見直しました。Storage も、当初の実装案がテナントポリシーに合わないことが分かり、Managed Identity、Private Endpoint、Private DNS を使う構成へ変えました。

Copilot の最初の案が常に正しかったわけではありません。それでも、エラー、ログ、ポリシー、応答時間を会話へ戻すと、原因候補を調べ、Bicep と設計文書を一緒に直せます。

この反復で、静的ブログから現在のアーキテクチャーまで育てられました。Azure の全サービスを覚えてから始めていたら、ここまで試すのにもっと時間がかかったと思います。

まずはこのプロンプトから始める

最初から Azure サービス名や Bicep を求める必要はありません。まず Plan モードで、作りたいものと分かっていることだけを伝え、設計に必要な要件を整理します。

Azure で小さな Web サービスを作りたいです。
私は Azure のアーキテクチャーやサイジングに詳しくありません。

まず、設計に足りない要件を一つずつ質問してください。
回答が分からない項目は「未決定」とし、判断に必要な選択肢と違いを説明してください。

質問が終わったら、次を整理してください。

1. 実現したいこと
2. 確定した要件と制約
3. 仮定した内容
4. 未決定の項目
5. 次に判断が必要なこと

この段階では、ファイルの作成や変更、Azure リソースのデプロイはしないでください。

整理された内容を自分で確認し、未決定の項目に回答します。要件と前提に納得できたら、次のプロンプトで構成案へ進みます。

整理した要件と前提をもとに、次を提案してください。

1. 最小構成と、少し余裕を持たせた構成
2. 採用する Azure サービスと選定理由
3. 初期サイジングと、その根拠になった前提
4. 構成図
5. Azure Pricing Calculator に入力する項目
6. デプロイ後に確認する性能、可用性、セキュリティ、コストの指標

Microsoft Learn MCP Server で最新の公式情報を確認してください。
Azure MCP Server が利用できる場合は、対象サブスクリプションの実際の状態も確認してください。
確定事項、仮定、未決定の項目を分けて示してください。

構成案を確認してから Agent モードへ切り替え、「承認した構成を Bicep にして」「デプロイ前に what-if を実行して」「デプロイ後に応答時間とログを確認して」と続けます。要件整理、構成の選択、実装を分けることで、意図しない前提のまま Azure リソースを作り始めるのを防げます。

補足として、GitHub が公開している Awesome Copilot には、プロンプト、カスタムエージェント、Instructions、Skills のサンプルがまとまっています。今回の流れに近い azure-architecture-autopilot は、対話による Azure アーキテクチャー設計から、構成図、Bicep、what-if、デプロイまでを段階的に進める Skill です。

さらに、要件と Azure 設計を扱う azure-principal-architect、Bicep の実装計画を作る bicep-plan、Bicep を実装する bicep-implement もあります。この記事のプロンプトだけでも始められますが、自分の進め方を Skill やカスタムエージェントとして整えるときの参考になります。

Copilot に任せることと人が決めること

Copilot は相談相手になり、見落としている質問を出し、具体案を作り、実装と検証を進められます。ただし、提案を採用する責任まで任せるものではありません。

重要なシステムでは、セキュリティ、法務、運用担当者や Cloud Solution Architect などの専門家にもレビューしてもらいます。Copilot で要件、構成図、Bicep、見積もり前提、未解決事項まで用意しておけば、専門家との時間を重要な判断に使いやすくなります。

まとめ

Azure に詳しくなくても、作りたいものまで曖昧でよいわけではありません。ただし、Azure のサービス名やサイズまで決めてから相談する必要もありません。

GitHub Copilot に目的を話せば、不足要件を質問し、Microsoft Learn MCP Server と Azure MCP Server を使って情報を確認し、初期サイジングを含む具体案へ整理できます。さらに、構成図と Bicep を作り、Azure で動かして確かめるところまで同じ流れで進められます。

本サイトも、完成した設計から始まったのではなく、この反復で育ちました。

まずは、**「これを Azure で作りたい。設計に足りないことを質問して、最初に試す具体案を出して」**と GitHub Copilot に話すところから始めてみるとよいと思います。