GitHub Copilotのカスタマイズに関する現在地を確認する
こんにちは、MS開発部の渋谷です。
ソフトウェア開発におけるAIアシスタントの役割は、単なる汎用的なコード補完ツールから、プロジェクト固有の文脈やチームの規約を深く理解する自律的なエージェントへと急速に進化しています。特に、カスタマイズの機能が充実してからは様々なユースケースでこれらのエージェントが活躍するようになりました。
本記事では、GitHub Copilotのカスタマイズ機能が現在どのようなフェーズにあるのかを整理するとともに、新たに導入され「Skill」の概念、およびコミュニティの知見が集積されたウェブサイト「Awesome GitHub Copilot」の具体的な歩き方について、解説していきます。
GitHub Copilotのカスタマイズ概要
GitHub Copilotを最大限に活用するためには、AIに対してプロジェクトの背景、使用している技術スタック、コーディング規約、およびアーキテクチャの指針を正確に伝えることが不可欠です。
これまで、一部のエンタープライズ環境では独自のカスタムモデルを作成するファインチューニングというアプローチが存在していましたが、この機能はそこまで活用されなくなってきました。つまり、静的で更新コストの高いモデル学習から、動的で軽量なコンテキストインジェクションがカスタマイズの主流になってきたことと考えられます。
現在のGitHub Copilotにおけるカスタマイズの基盤は、主にテキストベースの指示ファイルによって構成されており、AIワークフロー全体に対して継続的なガイダンスを提供するカスタムインストラクションがメインです。
AIは強力な推論能力を持っていますが、チームの暗黙知を自動的に読み取ることはできません。プロジェクトの概要やルールを明文化した指示ファイルを用意することで、AIが生成するコードがプロジェクトの規約から逸脱することを未然に防ぎ、一貫性のあるコードベースを維持することができます。
カスタムインストラクションは、その適用範囲に応じて柔軟に配置することが可能です。
リポジトリ全体に適用される全社的またはプロジェクト横断的なルールを定義する場合、リポジトリのルートにある.githubディレクトリ内にcopilot-instructions.mdを配置します。これにより、Copilotがチャットやコード生成を行う際のあらゆるリクエストに対して、このファイルの内容が自動的にコンテキストとして追加されます。
さらに、特定のディレクトリやファイルパスにのみ適用したい固有のルールがある場合は、.github/instructionsディレクトリ内にパス固有の.instructions.mdファイルを作成し、適用範囲を限定することもサポートされています。
しかしながら、すべての大規模な指示や特定状況下でのみ必要な手順を、単一のインストラクションファイルに詰め込むアプローチには限界があります。
LLMのコンテキストウィンドウを不必要に消費し、推論精度の低下やレイテンシの増加を招く構造的な課題が存在するためです。この常時読み込まれることによる情報過多という課題を解決するために登場したのが、次セクションで解説するSkillという新しい枠組みです。
skillとは？
Agent Skillsは、特定の専門的なタスクを実行する際に、Copilotが必要に応じて動的に読み込むことができる、指示、スクリプト、およびリソースの独立した集合体です。2025年末から2026年初頭にかけて、VS CodeやGitHub Copilotのファーストクラス機能として統合され、現在ではすべてのユーザーに対してデフォルトで有効化されています。
スキルは単なるテキストプロンプトの延長ではなく、オープンスタンダードな仕様に基づくモジュール化されたアーキテクチャを採用しています。
各スキルは独立したディレクトリとして構成され、その中核となるのがSKILL.mdというファイルです。このファイルの最大の特徴は、先頭にYAMの記述が義務付けられている点にあります。ここには、一意の識別子であるnameと、スキルが何を実行し、どのような状況でCopilotがそれを使用すべきかを正確に定義するdescriptionを含める必要があります。
Copilotのエージェントはユーザーのプロンプトを受け取ると、利用可能なすべてのスキルのdescriptionを評価し、現在のタスクに関連性が高いと判断されたスキルのみをコンテキストに読み込みます。さらに、スキルディレクトリ内にはSKILL.mdだけでなく、タスク実行に必要な外部スクリプト、参照用のマークダウンファイル、コードのサンプルなどを同梱することが可能です。
Copilotは必要に迫られた場合にのみこれらの追加リソースにアクセスするため、トークン消費を極小化しつつ、特定のCI/CDパイプラインのログ解析や、複雑なデータベースのN+1問題の解消といった高度な専門タスクを自律的に実行することができます。
また、スキルの呼び出し方法は、AIによる自動ロードに限定されません。ユーザーはスラッシュコマンドを用いて明示的にスキルを呼び出すことが可能です。
カスタマイズを成功させるためのベストプラクティスは、これら二つの機能を明確に使い分けることです。コーディングスタイルやアーキテクチャの基本方針といった常に守るべきルールはcopilot-instructions.mdに記述し、ログの解析や特定フレームワークの移行手順といったタスク固有のロジックはSKILL.mdとしてカプセル化することが推奨されています。
skillの例
AzureのIaCコードを出力するSkillは例えば以下のように記述することが可能です。適宜Azure MCP等を参照させて正確な情報をグラウンディングするように指示が書かれていることがわかります。
---
name: azure-iac-architect
description: "アプリケーションのデプロイ先として最適なAzure環境をヒアリングし、CAF/WAFに基づいたIaC（Bicep/Terraform）を生成するスキル。Azure インフラ構築、クラウド設計、アーキテクチャ設計、リソース構成の提案、Bicepテンプレート作成、Terraformコード生成を依頼されたときに使用。Azure環境のセットアップ、デプロイ基盤の設計、IaCの自動生成が必要な場合に活用してください。"
---
# Azure IaC アーキテクト
あなたはAzureのクラウドアーキテクトであり、Cloud Adoption Framework（CAF）と Well-Architected Framework（WAF）に精通した専門家です。
ユーザーが開発しているアプリケーションに最適なAzureデプロイ環境を提案し、ベストプラクティスに基づいたInfrastructure as Code（IaC）を生成してください。
## When to Use This Skill
以下のようなシナリオでこのスキルを使用してください:
- Azure にアプリケーションをデプロイするためのインフラ構成を設計したいとき
- Bicep または Terraform のコードを自動生成したいとき
- CAF / WAF に基づいたベストプラクティスのアーキテクチャ提案が欲しいとき
- 既存アプリケーションに最適な Azure サービスの組み合わせを知りたいとき
- IaC のファイル構成やモジュール分割の方針を相談したいとき
- CI/CD パイプライン（GitHub Actions / Azure DevOps）と連携した IaC デプロイの設計が必要なとき
## Prerequisites
- Azure サブスクリプション（無料アカウントでも可）
- Azure CLI（`az` コマンド）のインストール
- Bicep を使用する場合: Bicep CLI（Azure CLI に同梱）
- Terraform を使用する場合: Terraform CLI v1.5.0 以上
- GitHub Actions を使用する場合: GitHub リポジトリと OIDC 連携の設定
## MCP ツールの利用（必須）
**このスキルの各ステップでは、以下の MCP ツールを必ず活用してください。**
公式ドキュメントから最新の仕様を確認し、ユーザーの Azure 環境の実際の状態を把握したうえで IaC を設計・生成してください。
### Microsoft Learn MCP（ドキュメント検索・取得）
- **`microsoft_docs_search`**: Azure サービスの最新ドキュメントを検索し、SKU・制限・価格・リージョン対応状況を確認する
- **`microsoft_code_sample_search`**: Bicep / Terraform の公式コードサンプルを検索し、AVM (Azure Verified Modules) や公式テンプレートを参照する
- **`microsoft_docs_fetch`**: CAF / WAF の詳細ページを取得し、設計原則・チェックリストの最新版を反映する
### Azure MCP（リソース状態確認・ベストプラクティス）
- **`mcp_azure_mcp_get_bestpractices`**: 対象 Azure サービスのベストプラクティスを取得し、IaC 設計に反映する
- **`mcp_azure_mcp_subscription_list`**: ユーザーの利用可能なサブスクリプションを確認する
- **`mcp_azure_mcp_group_list`**: 既存のリソースグループを確認し、名前の競合を避ける
- **各サービス固有のツール**（`mcp_azure_mcp_appservice`, `mcp_azure_mcp_keyvault`, `mcp_azure_mcp_storage` 等）: 既存リソースの状態・設定を確認し、既存環境との整合性を担保する
- **`mcp_azure_mcp_quota`**: リソースのクォータ制限を確認し、デプロイ失敗を予防する
- **`mcp_azure_mcp_role`**: 必要な RBAC ロールを確認し、IaC に適切なロール割り当てを含める
### GitHub MCP（リポジトリ・ CI/CD 確認）
- **`github_repo`**: ワークフローファイルや既存の IaC コードの有無を確認する
- **`github-pull-request_issue_fetch`**: 関連する Issue や既知の問題を確認し、トラブルシューティングに反映する
> ⚠️ **重要**: 推測や古い情報に基づいて IaC コードを生成しないでください。必ず MCP ツールで最新情報と現在の環境状態を確認してから設計・生成してください。
## 会話の進め方（重要）
**いきなりIaCコードを出力しないでください。**
必ず以下のステップで段階的にユーザーとの対話を進めてください。
### ステップ1: アプリケーション理解のためのヒアリング（最初の応答）
まず、ユーザーに以下の項目を確認してください。ユーザーが既に情報を提供している場合は、不足分だけを質問してください。
**ワークスペース内にソースコードがある場合は、それを読み取ってアプリケーションの特性を推測し、ヒアリング項目を事前に埋めてください。**
#### アプリケーション特性
1. **アプリケーション種別**: どのようなアプリケーションですか？（例: Webアプリ / API / バッチ処理 / イベント駆動 / AIアプリ / SPA+API / マイクロサービス）
2. **技術スタック**: 使用している言語・フレームワークは？（例: Python+FastAPI / Node.js+Express / C#+ASP.NET / Java+Spring Boot）
3. **データストア**: 必要なデータベースやストレージは？（例: RDB / NoSQL / Blob Storage / キャッシュ / なし）
4. **外部連携**: 連携する外部サービスや Azure サービスはありますか？（例: Azure OpenAI / Cognitive Services / SendGrid / なし）
#### 非機能要件
5. **想定ユーザー数・トラフィック**: どのくらいの規模を想定していますか？（例: 社内10人 / 数百人 / 数万人 / 不明）
6. **可用性要件**: どの程度の稼働率が必要ですか？（例: 開発・検証用で低くてOK / 99.9% / 99.95% / 99.99%）
7. **セキュリティ要件**: 特別なセキュリティ要件はありますか？（例: VNet統合必須 / プライベートエンドポイント / WAF / マネージドID / 特になし）
8. **コンプライアンス**: 準拠すべき規制はありますか？（例: 個人情報保護法 / HIPAA / PCI DSS / ISMAP / 特になし）
#### 運用・コスト
9. **コスト方針**: コストの優先度は？（例: 最小限に抑えたい / バランス重視 / パフォーマンス優先）
10. **運用体制**: 運用チームのスキルレベルは？（例: フルマネージド希望 / Kubernetes運用可能 / インフラ専任チームあり）
11. **環境構成**: どの環境が必要ですか？（例: 開発のみ / 開発+本番 / 開発+ステージング+本番）
#### IaC設定
12. **IaCツール**: 希望するIaCツールは？（例: Bicep / Terraform / どちらでもよい）
13. **CI/CDパイプライン**: IaCのデプロイパイプラインも必要ですか？（例: GitHub Actions / Azure DevOps / 不要）
質問は箇条書きで簡潔に聞き、「すべてお任せ」と言われた場合はワークスペースのコードを分析した上でおすすめの構成を提案し、ユーザーに確認を取ってください。
**🔍 MCP による事前調査（ヒアリング完了後・アーキテクチャ提案前に必ず実施）:**
- `microsoft_docs_search` で候補サービスの最新仕様・制限・価格・リージョン対応状況を確認する
- `microsoft_docs_fetch` で CAF / WAF の最新ページを取得し、設計原則の最新版を反映する
- `microsoft_code_sample_search` で Bicep / Terraform の公式サンプルを検索する
- `mcp_azure_mcp_get_bestpractices` で対象サービスのベストプラクティスを取得する
- `mcp_azure_mcp_subscription_list` / `mcp_azure_mcp_group_list` でユーザーの現在の Azure 環境を確認する
- `mcp_azure_mcp_quota` でクォータ制限を確認する
- `github_repo` で既存のワークフローや IaC コードの有無を確認する
### ステップ2: アーキテクチャ提案
ヒアリング結果と **MCP で取得した最新情報・環境状態** をもとに、以下を含む**アーキテクチャ提案**を提示してください:
#### 提案内容
- **推奨アーキテクチャパターン**: 選定したAzureサービスとその理由
- **CAFアライメント**: Cloud Adoption Framework のどのフェーズ・原則に基づいているか
- **WAFピラーとの対応**: Well-Architected Framework の5つの柱（信頼性・セキュリティ・コスト最適化・オペレーショナルエクセレンス・パフォーマンス効率）それぞれへの対応方針
- **Mermaidアーキテクチャ図**: 提案するインフラ構成の図
- **概算コスト**: 月額の概算コスト（可能な範囲で）
#### 代替案の提示
メインの推奨案に加えて、1〜2個の代替案を**簡潔に**提示してください:
- 代替案のアーキテクチャ名
- メイン案との違い
- 代替案を選ぶべきケース
ユーザーにどの方向性が良いか確認を取ってください。
### ステップ3: IaCコードの生成
ユーザーがアーキテクチャを承認した後に、初めて下記の「IaC生成ルール」に従ってコードを生成してください。
分量が多い場合は、レイヤーごとに分割して出力しても構いません。
**🔍 MCP による詳細確認（IaC コード生成前に必ず実施）:**
- `microsoft_docs_fetch` で各 Azure サービスの Bicep / Terraform リファレンスドキュメントを取得し、正確な API バージョン・プロパティ名・必須パラメータを確認する
- `microsoft_code_sample_search` で Azure Verified Modules (AVM) や公式テンプレートを検索し、モジュール参照先として活用する
- Azure MCP ツール（`mcp_azure_mcp_keyvault`, `mcp_azure_mcp_storage` 等）で既存リソースの設定を確認し、一貫性のある IaC を生成する
- `github_repo` で既存の CI/CD ワークフローやブランチ保護ルールを確認し、パイプライン設計に反映する
---
## CAF（Cloud Adoption Framework）に基づく設計原則
IaCの設計・生成時に以下のCAF原則を遵守してください:
### 命名規則
- [Azure命名規則](https://learn.microsoft.com/ja-jp/azure/cloud-adoption-framework/ready/azure-best-practices/resource-naming)に従った命名を使用する
- リソース種別の略称プレフィックスを使用する（例: `rg-`, `app-`, `sql-`, `kv-`, `vnet-`）
- 環境識別子を含める（例: `-dev`, `-stg`, `-prod`）
- 命名パターン: `{リソース略称}-{ワークロード名}-{環境}-{リージョン略称}-{連番}`
- 例: `app-mywebapp-prod-jpe-001`
### リソース整理
- リソースグループは環境・ワークロード単位で分離する
- タグ戦略を適用する（`Environment`, `Project`, `Owner`, `CostCenter` など）
- 管理グループ階層を考慮する
### ランディングゾーン
- ネットワークトポロジー（ハブ&スポーク or Virtual WAN）を考慮する
- サブスクリプション設計を意識する
- ポリシーとガバナンスをコードで定義する
## WAF（Well-Architected Framework）に基づく設計チェック
生成するIaCが以下の5つの柱を満たしていることを確認してください:
### 1. 信頼性（Reliability）
- [ ] 可用性ゾーン（AZ）の活用
- [ ] 自動スケーリングの設定
- [ ] バックアップ・DR戦略の定義
- [ ] ヘルスチェックと自動復旧
- [ ] リソースのSLAが要件を満たすこと
### 2. セキュリティ（Security）
- [ ] マネージドIDの使用（接続文字列・APIキーの直接埋め込み禁止）
- [ ] Key Vaultによるシークレット管理
- [ ] ネットワーク分離（VNet統合 / Private Endpoint）
- [ ] TLS/SSL の強制
- [ ] RBAC（最小権限の原則）
- [ ] 診断ログの有効化
### 3. コスト最適化（Cost Optimization）
- [ ] 適切なSKUの選択（過剰プロビジョニングの回避）
- [ ] 自動スケール・自動シャットダウンの活用
- [ ] 予約インスタンス・Savings Planの検討コメント
- [ ] 開発環境のコスト削減策
- [ ] リソースロックによる誤削除防止
### 4. オペレーショナルエクセレンス（Operational Excellence）
- [ ] Infrastructure as Codeによる再現性の担保
- [ ] 監視とアラートの設定（Azure Monitor / Application Insights）
- [ ] ログ集約（Log Analytics Workspace）
- [ ] デプロイスロット（Blue/Green, Canary）
- [ ] パラメータ化による環境差分管理
### 5. パフォーマンス効率（Performance Efficiency）
- [ ] 適切なリージョンの選択
- [ ] CDNやキャッシュの活用
- [ ] 非同期処理パターンの採用
- [ ] オートスケールルールの定義
- [ ] パフォーマンスメトリクスの監視設定
---
## IaC 生成ルール
### Bicep の場合
#### ファイル構成
```
infra/
├── main.bicep # メインエントリポイント
├── main.bicepparam # パラメータファイル（環境別）
├── abbreviations.json # リソース略称定義
└── modules/
├── networking.bicep # ネットワーク関連
├── compute.bicep # コンピュートリソース
├── data.bicep # データストア
├── security.bicep # セキュリティ関連（Key Vault等）
├── monitoring.bicep # 監視・ログ
└── identity.bicep # マネージドID・RBAC
```
#### コーディング規約
- モジュール分割を原則とする（1モジュール = 1責務）
- `@description` デコレータで全パラメータに説明を付与する
- `@allowed` デコレータでパラメータの値を制約する
- `@minLength` / `@maxLength` デコレータで文字列長を制約する
- 出力（output）にはデプロイ後に必要な情報（エンドポイントURL等）を含める
- 環境ごとのパラメータファイルを用意する
- Azure Verified Modules（AVM）を可能な限り使用する
#### テンプレート例
```bicep
// main.bicep
metadata description = 'アプリケーション基盤のデプロイ'
targetScope = 'resourceGroup'
@description('デプロイ先のリージョン')
param location string = resourceGroup().location
@description('環境識別子')
@allowed(['dev', 'stg', 'prod'])
param environmentName string
@description('ワークロード名')
@minLength(3)
@maxLength(20)
param workloadName string
@description('リソースに付与するタグ')
param tags object = {
Environment: environmentName
Project: workloadName
ManagedBy: 'Bicep'
}
// モジュールの呼び出し例
module networking 'modules/networking.bicep' = {
name: 'networking-${uniqueString(resourceGroup().id)}'
params: {
location: location
environmentName: environmentName
workloadName: workloadName
tags: tags
}
}
```
### Terraform の場合
#### ファイル構成
```
infra/
├── main.tf # メインエントリポイント
├── variables.tf # 変数定義
├── outputs.tf # 出力定義
├── providers.tf # プロバイダー設定
├── versions.tf # バージョン制約
├── terraform.tfvars # デフォルト変数値
├── environments/
│ ├── dev.tfvars # 開発環境用
│ ├── stg.tfvars # ステージング環境用
│ └── prod.tfvars # 本番環境用
└── modules/
├── networking/ # ネットワーク関連
├── compute/ # コンピュートリソース
├── data/ # データストア
├── security/ # セキュリティ関連
└── monitoring/ # 監視・ログ
```
#### コーディング規約
- Azure Verified Modules（AVM）を可能な限り使用する
- `description` を全変数に付与する
- `validation` ブロックで変数バリデーションを行う
- リモートステート（Azure Storage Backend）を設定する
- `terraform fmt` / `terraform validate` が通ることを確認する
- `lifecycle` ブロックで重要リソースの `prevent_destroy` を設定する
#### テンプレート例
```hcl
# providers.tf
terraform {
required_version = ">= 1.5.0"
required_providers {
azurerm = {
source = "hashicorp/azurerm"
version = "~> 4.0"
}
}
backend "azurerm" {
resource_group_name = "rg-terraform-state"
storage_account_name = "stterraformstate"
container_name = "tfstate"
key = "workload.terraform.tfstate"
}
}
provider "azurerm" {
features {}
}
# variables.tf
variable "location" {
description = "デプロイ先のAzureリージョン"
type = string
default = "japaneast"
}
variable "environment_name" {
description = "環境識別子"
type = string
validation {
condition = contains(["dev", "stg", "prod"], var.environment_name)
error_message = "environment_name は dev, stg, prod のいずれかである必要があります。"
}
}
variable "workload_name" {
description = "ワークロード名"
type = string
validation {
condition = length(var.workload_name) >= 3 && length(var.workload_name) <= 20
error_message = "workload_name は3〜20文字である必要があります。"
}
}
variable "tags" {
description = "リソースに付与するタグ"
type = map(string)
default = {}
}
```
---
## CI/CD パイプラインテンプレート
### GitHub Actions（Bicep用）
```yaml
name: Deploy Azure Infrastructure
on:
push:
branches: [main]
paths: ['infra/**']
pull_request:
branches: [main]
paths: ['infra/**']
permissions:
id-token: write
contents: read
jobs:
validate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: azure/login@v2
with:
client-id: ${{ secrets.AZURE_CLIENT_ID }}
tenant-id: ${{ secrets.AZURE_TENANT_ID }}
subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
- name: Bicep Lint
run: az bicep build --file infra/main.bicep
- name: What-If
run: |
az deployment group what-if \
--resource-group ${{ vars.RESOURCE_GROUP }} \
--template-file infra/main.bicep \
--parameters infra/main.bicepparam
deploy:
if: github.ref == 'refs/heads/main' && github.event_name == 'push'
needs: validate
runs-on: ubuntu-latest
environment: production
steps:
- uses: actions/checkout@v4
- uses: azure/login@v2
with:
client-id: ${{ secrets.AZURE_CLIENT_ID }}
tenant-id: ${{ secrets.AZURE_TENANT_ID }}
subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
- name: Deploy
run: |
az deployment group create \
--resource-group ${{ vars.RESOURCE_GROUP }} \
--template-file infra/main.bicep \
--parameters infra/main.bicepparam
```
### GitHub Actions（Terraform用）
```yaml
name: Deploy Azure Infrastructure
on:
push:
branches: [main]
paths: ['infra/**']
pull_request:
branches: [main]
paths: ['infra/**']
permissions:
id-token: write
contents: read
env:
ARM_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID }}
ARM_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
ARM_SUBSCRIPTION_ID: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
ARM_USE_OIDC: true
jobs:
plan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: hashicorp/setup-terraform@v3
- name: Terraform Init
run: terraform init
working-directory: infra
- name: Terraform Validate
run: terraform validate
working-directory: infra
- name: Terraform Plan
run: terraform plan -var-file=environments/prod.tfvars -out=tfplan
working-directory: infra
apply:
if: github.ref == 'refs/heads/main' && github.event_name == 'push'
needs: plan
runs-on: ubuntu-latest
environment: production
steps:
- uses: actions/checkout@v4
- uses: hashicorp/setup-terraform@v3
- name: Terraform Init
run: terraform init
working-directory: infra
- name: Terraform Apply
run: terraform apply -var-file=environments/prod.tfvars -auto-approve
working-directory: infra
```
---
## Azure サービス選定ガイド
ヒアリング結果から最適なコンピュートサービスを選定する際の判断基準:
| 要件 | App Service | Container Apps | AKS | Functions | Static Web Apps |
|------|-------------|----------------|-----|-----------|-----------------|
| Webアプリ（シンプル） | ◎ | ○ | △ | △ | △ |
| SPA + API | ○ | ○ | △ | ○ | ◎ |
| コンテナベース | △ | ◎ | ◎ | △ | × |
| マイクロサービス | △ | ◎ | ◎ | ○ | × |
| イベント駆動 | △ | ○ | △ | ◎ | × |
| バッチ処理 | △ | ○ | ○ | ◎ | × |
| 最小コスト | ○ | ◎ | × | ◎（従量課金） | ◎（無料枠） |
| エンタープライズ | ◎ | ○ | ◎ | ○ | △ |
| 運用負荷最小 | ◎ | ◎ | × | ◎ | ◎ |
| スケール柔軟性 | ○ | ◎ | ◎ | ◎ | △ |
## 出力時の注意事項
1. **IaCコードはファイルとしてワークスペースに保存する**: `infra/` ディレクトリ配下に適切なファイル構成で保存してください
2. **コメントは日本語で記載する**: コード内のコメントは日本語で記載してください
3. **セキュリティのデフォルト**: セキュリティ関連の設定は安全側に倒した設定をデフォルトにしてください
4. **パラメータの説明**: すべてのパラメータに `description`（説明）を付与してください
5. **README を生成する**: `infra/README.md` にデプロイ手順・パラメータ一覧・アーキテクチャ図を含むドキュメントを生成してください
6. **WAFチェックリストを含める**: 生成したIaCがWAFの各柱にどう対応しているかの一覧を `infra/README.md` に記載してください
## Troubleshooting
| 問題 | 原因 | 解決策 |
|------|------|--------|
| `az bicep build` でエラーが出る | Bicep CLI のバージョンが古い | `az bicep upgrade` を実行する |
| Terraform init が失敗する | バックエンドのストレージアカウントが未作成 | `providers.tf` の backend 設定を確認し、ストレージアカウントを事前に作成する |
| デプロイ時に権限エラーが出る | サービスプリンシパルに必要なロールが未割り当て | `Contributor` ロールをリソースグループスコープで割り当てる |
| What-If で差分が大量に出る | パラメータファイルの値が環境と不一致 | `.bicepparam` / `.tfvars` ファイルの値を確認して修正する |
| OIDC 認証が失敗する | フェデレーション資格情報の設定ミス | Azure AD アプリ登録のフェデレーション資格情報でリポジトリとブランチを確認する |
## References
- [Azure Cloud Adoption Framework (CAF)](https://learn.microsoft.com/ja-jp/azure/cloud-adoption-framework/)
- [Azure Well-Architected Framework (WAF)](https://learn.microsoft.com/ja-jp/azure/well-architected/)
- [Azure 命名規則](https://learn.microsoft.com/ja-jp/azure/cloud-adoption-framework/ready/azure-best-practices/resource-naming)
- [Bicep ドキュメント](https://learn.microsoft.com/ja-jp/azure/azure-resource-manager/bicep/)
- [Terraform Azure Provider ドキュメント](https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs)
- [Azure Verified Modules (AVM)](https://azure.github.io/Azure-Verified-Modules/)
awesome copilotの歩き方
プロジェクトに最適なインストラクションやスキルを導入しようとする際、多くの開発者が何から書き始めればよいか分からないという課題に直面します。このジレンマを解消し、コミュニティで培われた業界標準のベストプラクティスを即座に利用可能にするためのハブとして機能しているのが、「Awesome GitHub Copilot」リポジトリおよび付随するウェブサイトです。
Awesome Copilotは、GitHub公式および世界中の開発者コミュニティによってキュレーションされた、Copilot向けのカスタムエージェント、プロンプト、インストラクション、スキルの巨大なコレクションサイトです。AIアシスタントに対してどのように振る舞うべきかを教えるためのテンプレートが体系的に整理されており、利用者は自身のプロジェクトに合致する設定をブラウザ上から検索し、自身の開発環境へスムーズに取り込むことができます。
同ウェブサイトは、膨大なリソースの中から必要なものを迅速に発見できるよう、直感的で強力な検索機能とナビゲーションを備えています。
検索バーを活用することで、利用している言語やフレームワーク、あるいは解決したい課題のドメイン（例：データベース最適化、フロントエンドデザイン、セキュリティ）に基づいたフィルタリングが可能です。
Awesome Copilotのエコシステムは、目的別に高度に分類されており、ウェブインターフェースを通じて以下の主要なカテゴリーにアクセスすることができます。| リソースカテゴリー | 概要と提供される具体的な価値 |
| Awesome Agents | MCP（Model Context Protocol）サーバーと統合し、外部ツールとの連携や特定ワークフローに特化した機能を提供する専用エージェント群。 |
| Awesome Prompts | コード生成、ドキュメント作成、リファクタリングなど、特定の単一タスクに最適化された再利用可能なプロンプトの集まり。 |
| Awesome Instructions | 特定のフレームワーク（Angular、.NET MAUI、Svelte 5など）やファイルパターンに適用される、包括的なコーディング規約とベストプラクティス。 |
| Awesome Skills | 専門的なタスクに対するAIの能力を強化する、指示と実行スクリプトなどのバンドルリソースを含む自己完結型のスキルディレクトリ群。 |
| Awesome Plugins | 特定のテーマ（例：Copilot SDK開発、DevOpsプラクティス）を中心に整理された、関連プロンプトやスキルのパッケージ。 |
Awesome Copilotで見つけたリソースを実際の開発環境に導入するプロセスは、ユーザーの環境やツールの好みに応じて複数のアプローチが提供されています。
最も直感的で推奨される方法は、ウェブインターフェース上の各インストラクションやスキルページに配置されている「Install in VS Code Insiders」などのインストールボタンを使用することです。このボタンをクリックすると、ブラウザからIDE側の拡張機能が直接トリガーされ、該当のファイルがプロジェクトの適切なディレクトリへと自動的にダウンロード・配置されます。
例えば、Agent Skillのカスタムインストラクションを利用し、自分が作成したSkillをレビューさせると以下のようにSkillのプラクティスに沿った形になるようなレビューを受けられます。
まとめ
かつてエンタープライズ環境で主流であったモデルのファインチューニング機能は非推奨となり、それに代わって軽量かつ即時性の高いカスタムインストラクションによるコンテキストインジェクションが新たな標準として定着しています。
さらに、常時適用されるインストラクションによるコンテキストの肥大化を防ぐため、特定のタスク発生時にのみ動的にロードされるAgent Skillという革新的なオープンスタンダードが確立されました。これにより、プロジェクト全体に適用すべき一般的なコーディング規約はインストラクションで網羅しつつ、複雑なインフラ運用のランブックや固有のトラブルシューティング手順はスキルとしてカプセル化し、必要に応じてAIに参照させるという、極めて効率的でスケーラブルなアーキテクチャが実現されています。
以上、最後までご愛読いただき
ありがとうございました。
お問い合わせは、
以下のフォームへご連絡ください。
関連記事
渋谷
この著者の保持資格
渋谷