Azure FunctionsでAIコーディング支援を使っているものの、「生成されるコードが古い」「接続文字列が残る」「デプロイ前の確認が属人化する」と感じているチームは少なくありません。今回のAzure Functions向けCopilot-assisted codingとagent skillsのPublic Previewは、その課題を減らすための更新です。
結論から言うと、この更新は既存のFunction Appを自動で変更するものではありません。開発者がVS Code、CLI、azdなどの作業環境で、Azure Functionsに特化したスキル、MCP設定、検証コマンドを使えるようにし、作成・診断・デプロイ・運用確認をAIエージェントに任せやすくする仕組みです。Microsoftの公式情報では、azure-functions-skillsはPublic Previewとして提供され、GitHub Copilot CLI、Claude Code、Codex CLI、VS CodeにAzure Functions向けのスキルや指示ファイルを追加します。(Microsoft for Developers)
一方で、Public Previewは本番利用前提の機能ではありません。Azure Updatesでは「In preview」は非本番での利用・テスト向けと説明されています。導入する場合は、まず検証用リポジトリや開発環境で試し、権限、シークレット管理、CI実行条件、生成コードのレビュー体制を決めてから段階的に展開するのが安全です。(Microsoft Azure)
Azure FunctionsのAI/Copilot更新で何が変わるのか
今回のポイントは、汎用的なAIコーディング支援に「Azure Functionsの現在の作法」を渡せるようになることです。
従来のAIコーディング支援では、モデルの学習時期や参照できる情報によって、古いプログラミングモデル、古いテンプレート、接続文字列を直接使うサンプル、スケールしにくい実装が提案されることがありました。公式ブログでも、汎用エージェントがAzure Functions向けにコードを書くと、古いモデルに寄ったり、ハードコードされたキーや接続文字列、スケールしないパターンを残したりする問題があると説明されています。(Microsoft for Developers)
この更新では、Azure Functions専用のスキルセットにより、Managed Identity、Key Vault参照、Flex Consumption、最新のトリガー・バインディング、並行実行やデプロイ前検証といった観点を、AIエージェントの作業に組み込みやすくなります。(Microsoft for Developers)
| 観点 | これまで起きやすかった課題 | 今回の更新で期待できる変化 |
|---|---|---|
| プロジェクト作成 | 古いテンプレートや汎用的な構成が提案される | Azure Functions向けスキルが最新テンプレートや構成を使う方向に誘導 |
| セキュリティ | 接続文字列やキーをコード・設定に直書きしがち | Managed IdentityやKey Vault参照を前提にした構成を促しやすい |
| デプロイ | azdやCLIのエラー調査が手作業になりがち | デプロイ前検証やエラー説明・修正ガイドをAI支援で進めやすい |
| 運用確認 | 設定、トリガー、ログ、ヘルス確認が属人化 | diagnostics、health-status、inventoryなどのスキルで確認観点をそろえやすい |
| 品質管理 | PR後や本番直前に問題が見つかる | doctorで設定・コード上の問題をデプロイ前に検出しやすい |
重要なのは、これは「AIが自動で正しいFunction Appを完成させる魔法」ではないという点です。あくまで、Azure Functionsに詳しい作業手順と検証観点をAIエージェントに渡し、開発者の判断を補助する仕組みとして捉えるべきです。
中核となるazure-functions-skillsとは
azure-functions-skillsは、Azure Functions向けのAI coding agent用プラグインです。npmパッケージとしては@azure/functions-skillsで提供され、1コマンドでスキル、エージェント定義、MCPサーバー設定、hooks、copilot-instructions.md、CLAUDE.md、AGENTS.mdなどの指示ファイルを導入できます。(Microsoft for Developers)
公式情報で示されている主な要件は、Node.js 18以上、Azureサブスクリプション、そしてGitHub Copilot CLI、Claude Code、Codex CLI、VS Codeのいずれかです。(Microsoft for Developers)
代表的な導入コマンドは次のとおりです。
# GitHub Copilot CLI向け
npx @azure/functions-skills install --agent ghcp
# Claude Code向け
npx @azure/functions-skills install --agent claude
# Codex CLI向け
npx @azure/functions-skills install --agent codex
# エージェントを起動
npx @azure/functions-skills chat組織で検証する場合は、最初からユーザー全体に広げるより、検証用リポジトリで--localを使ってプロジェクト単位に閉じる方法が扱いやすいです。公式ブログでも、既定ではスキルはユーザースコープ、MCPやhooksなどのワークスペース成果物は現在のディレクトリに配置され、すべてをプロジェクト側に置きたい場合は--localを使うと説明されています。(Microsoft for Developers)
npx @azure/functions-skills install --agent ghcp --localどのスキルを何に使うべきか
Public Preview時点でのスキルは、Azure Functionsの作成、デプロイ、診断、運用確認に沿って構成されています。GitHubリポジトリのREADMEでは、ローカル前提条件の確認、プロジェクト作成、デプロイ、ベストプラクティス確認、診断、ヘルス確認、インベントリ取得、デプロイ前検証などのスキルが整理されています。(GitHub)
| スキル | 主な用途 | 使うタイミング |
|---|---|---|
azure-functions-setup | Azure CLI、Core Tools、ランタイム、Azure Skillsなどの前提確認 | 初回セットアップ時 |
azure-functions-create | 新規Functionsプロジェクト作成、既存プロジェクトへの関数追加 | 新規開発・機能追加時 |
azure-functions-agents | Azure Functions上で動くAI agentアプリの作成・拡張・トラブルシュート | イベント駆動のAIワークフローを作る時 |
azure-functions-deploy | Azure Skillsと連携した準備、検証、デプロイ | Azureへ展開する前後 |
azure-functions-best-practices | 既存Function Appの構成、セキュリティ、信頼性確認 | レビュー・改善時 |
azure-functions-diagnostics | デプロイ失敗、実行時エラー、トリガー、バインディング、ログ問題の調査 | 障害調査時 |
azure-functions-health-status | 実行状態、メトリック、Application Insights、Resource Health、Activity Log確認 | 運用確認時 |
azure-functions-inventory | SKU、ランタイム、ネットワーク、ID、設定、関数、トリガーの棚卸し | 移行計画・監査時 |
azure-functions-doctor | デプロイ前の設定・コード検証 | CIやリリース前 |
azure-functions-feedback | セッション中の気づきをIssueやPR案にまとめる | プレビュー機能へのフィードバック時 |
開発者が特に使いやすいのは、create、deploy、doctorの3つです。新規作成からデプロイ前検証までを一つの流れにできるため、チーム内で「Function Appを作るときの最低限の型」をそろえやすくなります。
開発者がまず試すべき基本フロー
最初の検証では、既存の本番リポジトリではなく、最小構成の検証用リポジトリを作るのがおすすめです。AIエージェントが生成するファイル、MCP設定、hooks、指示ファイルがどこに置かれるかを確認してから、チームの標準に合わせます。
検証用ブランチでセットアップする
まずは作業ディレクトリをGit管理下に置き、未コミットの変更がない状態で始めます。AIがファイルを生成するため、変更差分を必ずレビューできる状態にしておくことが重要です。
git checkout -b trial/functions-skills
npx @azure/functions-skills install --agent ghcp --local
npx @azure/functions-skills chatVS Codeを使う場合は、ワークスペースを開いた後、GitHub Copilot Chatでfunctions-copilotエージェントを選び、setupスキルを実行する流れになります。公式ブログでは、VS CodeでもCLIのchatと同様に、ワークスペース内でfunctions-copilotを選んでセットアップできると説明されています。(Microsoft for Developers)
依頼文は「作りたい処理」と「守りたい制約」をセットで書く
AIエージェントに依頼するときは、「HTTPトリガーを作って」だけでは不十分です。実務では、接続先、認証方式、デプロイ先、ログ、失敗時の扱いまで含めると、レビューしやすい成果物になります。
例えば、次のように依頼します。
PythonでHTTP triggerのAzure Functionsを作成してください。
Cosmos DBからデータを読み取り、Service Busに出力します。
接続文字列は使わず、Managed Identityを前提にしてください。
ローカル実行手順、必要なAzureリソース、デプロイ前の検証項目も出してください。このように書くと、生成されたコードだけでなく、Bicepやazure.yaml、アプリ設定、権限設定、検証手順まで確認しやすくなります。
生成結果は「動くか」より先に「安全か」を確認する
AIが生成したFunction Appは、ローカルで動作してもそのまま採用しないほうが安全です。特に次の点を確認してください。
| 確認項目 | 見るべきポイント |
|---|---|
| 認証・認可 | 接続文字列やキーではなく、Managed Identityを使っているか |
| シークレット | .env、local.settings.json、アプリ設定に本物のシークレットが混ざっていないか |
| トリガー・バインディング | 対象ランタイム、言語バージョン、拡張バンドルが現在のサポート範囲にあるか |
| スケール | クライアントを毎回生成していないか、同期I/Oをホットパスで使っていないか |
| 監視 | Application Insights、ログ、失敗時の再試行やDead-letter確認が設計に入っているか |
| IaC | 手動作成前提ではなく、Bicepやazdで再現可能な構成になっているか |
doctorでデプロイ前検証を標準化する
今回の更新で実務上の価値が大きいのが、doctorによるデプロイ前検証です。
公式ブログでは、doctorは2段階の検証を行うと説明されています。Tier 1はLLMを使わない決定的な検証で、host.json、ランタイムバージョン、トリガー設定、拡張バンドル、非推奨設定、lockfile、追跡対象の.env、サプライチェーン関連のチェックなどを確認します。Tier 2は--deepで有効化するLLMによる意味的な検証で、ハードコードされたシークレット、ホットパス上のブロッキングI/O、クライアントの都度生成、Durable Functionsの非決定的処理などを探します。(Microsoft for Developers)
ローカル検証では、次のようにHTMLレポートを出力できます。
npx @azure/functions-skills doctor --dir . \
--deep --accept-deep-risk \
--agent github-copilot \
--format html --output doctor-report.htmlただし、--deepは慎重に扱う必要があります。公式ブログでは、--deepはファイル書き込みやシェル実行権限を持つコーディングエージェントを使うため、エージェントが見る入力がprompt injectionの攻撃面になると説明されています。そのため、未信頼のpull requestではTier 1のみ、信頼済みのmainブランチへのpush後やリリース前に--deepを使うパターンが推奨されています。(Microsoft for Developers)
実務では、次のように使い分けると安全です。
| 実行場所 | 推奨設定 | 理由 |
|---|---|---|
| 開発者のローカル | --deep --accept-deep-risk | 自分の作業差分を詳しく確認できる |
| 外部からのPR | --no-deep | 未信頼コードをLLMエージェントに実行させない |
| 社内PR | まず--no-deep | チームルールが固まるまで安全側に倒す |
| mainマージ後 | --deepを承認付き環境で実行 | リリース前に深い検証を行う |
| 本番デプロイ直前 | 高severityでゲート化 | 重大な検出があれば展開を止める |
azdとの関係：デプロイ体験もAI支援が進む
今回のAzure Functions向けスキルは、CLIやVS Codeでの作成・検証だけでなく、Azure Developer CLI、つまりazdの体験とも組み合わせて考えると効果が出ます。
Microsoftは別の公式ブログで、azd 1.23.11以降にGitHub Copilot連携が入り、azd init中のAI支援によるプロジェクトスキャフォールディングと、azdコマンド失敗時のエラートラブルシューティングを提供すると説明しています。azd initでは、Copilotがコードベースを分析し、azure.yaml、インフラテンプレート、デプロイ構成を生成する流れが案内されています。(Microsoft for Developers)
また、azd provisionやazd upが失敗した場合、Copilotによる説明、修正手順、診断とガイド、修正適用の選択肢が表示されます。よくある例として、リソースプロバイダー未登録のMissingSubscriptionRegistration、SKUやクォータ制限のSkuNotAvailable、ストレージアカウント名の重複で起きるStorageAccountAlreadyTakenなどが挙げられています。(Microsoft for Developers)
Azure Functionsの開発では、azure-functions-skillsでプロジェクト作成と事前検証を行い、azdでインフラ・デプロイを再現可能にする流れが現実的です。
# azdのバージョン確認
azd version
# Copilot支援付きの初期化
azd init
# プロビジョニングとデプロイ
azd up管理者は、azdのCopilot支援を許可するか、どの環境で使うか、Copilotが修正を提案したときに自動適用を認めるかを事前に決めておきましょう。特にfix系の設定は便利ですが、検証前の自動修正がIaCや本番構成に影響する可能性があるため、最初は説明・ガイド止まりにするのが安全です。
管理者が確認すべき設定とガバナンス
今回の更新は開発者体験の改善に見えますが、実際には管理者やプラットフォームチームの確認項目が多い更新です。AIエージェントはコード、設定、インフラ定義、場合によってはCLIやシェル実行にも関わるためです。
| 確認領域 | 管理者が決めること | 実務上の注意点 |
|---|---|---|
| 利用範囲 | どのチーム・どのリポジトリで使うか | まず非本番・検証用から始める |
| エージェント | GitHub Copilot CLI、VS Code、Claude Code、Codex CLIのどれを許可するか | 組織のライセンス、データ取り扱い、監査要件に合わせる |
| インストールスコープ | ユーザースコープかプロジェクトローカルか | 共有リポジトリでは--localで差分管理しやすくする |
| Node/npm | Node.js 18以上、npm利用、パッケージ取得元 | 社内プロキシやnpm許可リストがある場合は事前確認する |
| MCP・hooks | 生成される設定ファイルをコミットするか | MCPサーバーが何にアクセスするかをレビューする |
| Azure権限 | 開発者・CIに与えるRBAC | Contributorを広く与えず、環境ごとに最小権限を検討する |
| シークレット | Key Vault、Managed Identity、GitHub Actions secrets | 接続文字列の直書きを禁止し、Key Vault参照を標準化する |
| CI実行 | PRでは--no-deep、main後に--deepなど | 未信頼PRでLLM深掘り検証を動かさない |
| 監査 | 生成・変更されたファイルのレビュー方法 | AIが作った差分も通常のコードレビュー対象にする |
特に、Managed IdentityとKey Vault参照の確認は重要です。Microsoft Learnでは、Azure Functionsを含むApp Service系アプリでKey Vault参照を使うには、Key Vaultを作成し、アプリにManaged Identityを作成し、そのIDにシークレット読み取り権限を付与する流れが説明されています。Key Vault参照は、アプリ設定や接続文字列の値として使えるため、シークレットをアプリ構成から分離できます。(Microsoft Learn)
移行・展開で注意すべきポイント
今回のCopilot-assisted coding更新は、Azure Functionsのランタイム移行を自動で完了させるものではありません。既存アプリに古いランタイム、古い言語バージョン、.NET in-processモデル、Linux Consumptionの制約がある場合は、別途移行計画が必要です。
Microsoft Learnでは、Azure Functionsランタイム4.xが全言語で推奨され、1.xはC#で.NET Frameworkが必要なアプリ向けの保守モードであり、2026年9月14日にサポート終了予定と説明されています。(Microsoft Learn)
.NETアプリでは、in-processモデルにも注意が必要です。Microsoft Learnでは、Azure Functionsの.NET in-processモデルは2026年11月10日にサポート終了予定で、完全なサポートを維持するにはisolated worker modelへの移行が推奨されています。(Microsoft Learn)
また、Flex Consumptionも判断材料になります。Microsoft Learnでは、Flex ConsumptionはLinuxベースのAzure Functionsホスティングプランで、Consumptionの従量課金モデルを基にしつつ、プライベートネットワーク、インスタンスメモリサイズ選択、高速または大規模スケールアウトなどを提供し、Azure Functionsの推奨サーバーレスホスティングプランと説明されています。(Microsoft Learn)
移行や新規展開では、次の順序で判断すると迷いにくくなります。
| 判断項目 | 推奨アクション |
|---|---|
| 新規開発か既存改修か | 新規ならFlex ConsumptionやManaged Identity前提で設計する |
| .NET in-processを使っているか | isolated worker modelへの移行計画を作る |
| Functions runtime 1.xを使っているか | runtime 4.xへの移行対象として棚卸しする |
| Linux Consumptionを使っているか | 新機能や将来の言語バージョン要件を見てFlex Consumptionを検討する |
| 接続文字列依存があるか | Key Vault参照またはidentity-based connectionへ寄せる |
| IaCがないか | azd、Bicep、Terraformなどで再現可能な構成にする |
| 監視が弱いか | Application Insights、ログ、Resource Health、Activity Log確認を標準化する |
ここでazure-functions-inventoryやazure-functions-best-practicesを使うと、移行前の棚卸しや改善候補の整理に役立ちます。ただし、AIが出した移行案はそのまま適用せず、対象ランタイム、言語バージョン、拡張機能、トリガーの互換性を必ず公式ドキュメントと実機検証で確認してください。
導入してよいケース、慎重にすべきケース
Azure FunctionsのCopilot-assisted codingは便利ですが、すべての環境ですぐ使うべきとは限りません。判断基準を明確にすると、現場展開で混乱しにくくなります。
導入効果が出やすいケース
次のようなチームでは、早めに検証する価値があります。
- Azure Functionsの新規プロジェクトが多い
- 開発者ごとにテンプレートや設定の作り方がばらついている
- 接続文字列やシークレット管理のレビューで手戻りが多い
azd、Bicep、GitHub Actionsを使った標準化を進めたい- .NET in-processや古いランタイムの棚卸しを始めたい
- 本番障害の原因が設定ミスやコード品質に偏っている
特に、複数チームがFunction Appを作っている組織では、「AIを使うかどうか」よりも「AIが作る成果物をどの基準でレビューするか」が重要になります。doctorのレポートやbest-practicesの提案をレビュー観点に組み込むと、属人化を減らせます。
まだ慎重にすべきケース
一方で、次の条件に当てはまる場合は、すぐに広げないほうが安全です。
- 本番環境に直接触れる権限しか用意されていない
- npmパッケージや外部エージェントの利用審査が終わっていない
- GitHub CopilotやClaude Codeなどの利用ポリシーが未整備
- MCPサーバーやhooksのアクセス範囲をレビューできない
- 外部コントリビューターのPRが多く、CIで未信頼コードを扱う
- 生成AIによるコード生成を監査・記録するルールがない
この場合は、まずローカルの検証専用リポジトリで動作を確認し、生成されるファイル、通信先、権限、CI上の実行条件を文書化してから展開しましょう。
開発チーム向けの実践チェックリスト
最初の1週間でやるべきことは多くありません。大事なのは、いきなり全リポジトリに導入せず、ひとつの検証プロジェクトで標準パターンを作ることです。
| ステップ | 作業内容 | 完了条件 |
|---|---|---|
| 1 | 検証対象のFunction Appまたはサンプルリポジトリを決める | 本番と切り離された環境がある |
| 2 | 使用するエージェントを決める | VS Code、GitHub Copilot CLIなどが明確 |
| 3 | --localでazure-functions-skillsを導入する | 生成ファイルをGit差分で確認できる |
| 4 | setupとcreateを試す | 新規関数またはサンプル構成が作成できる |
| 5 | Managed IdentityとKey Vault参照を前提に修正する | 接続文字列の直書きがない |
| 6 | doctor --no-deepを実行する | 決定的チェックの結果を確認できる |
| 7 | ローカルでdoctor --deepを試す | HTMLレポートをレビューできる |
| 8 | PR用CIに--no-deepを入れる | 未信頼PRでも安全に回せる |
| 9 | mainマージ後の--deep実行を検討する | 承認付き環境とスコープ済みsecretがある |
| 10 | チーム標準プロンプトを作る | 開発者が同じ品質で依頼できる |
標準プロンプトは、次のようにテンプレート化しておくと便利です。
Azure Functionsで次の機能を実装してください。
目的:
- ここに業務目的を書く
トリガー:
- HTTP / Timer / Service Bus / Event Grid など
使用言語:
- Python / TypeScript / C# isolated / Java など
接続先:
- Cosmos DB / Storage / Service Bus / SQL など
制約:
- 接続文字列を使わずManaged Identityを使う
- シークレットはKey Vault参照を使う
- IaCはBicepまたはazd前提
- デプロイ前にdoctorで検証できるようにする
出力してほしいもの:
- 実装コード
- 必要なAzureリソース
- アプリ設定
- ローカル実行手順
- デプロイ手順
- レビューすべき注意点失敗しやすいポイント
今回の更新で失敗しやすいのは、AIエージェントを「詳しい新人」ではなく「自動運用者」として扱ってしまうことです。実務では、次の落とし穴に注意してください。
| 失敗パターン | 起きる問題 | 回避策 |
|---|---|---|
| 生成コードをそのままmainに入れる | シークレット、権限、スケール設計の問題を見逃す | PRレビューとdoctorを必須にする |
--deepを全PRで実行する | 未信頼コードによるprompt injectionリスクがある | PRでは--no-deep、main後に--deep |
| ユーザースコープで無秩序に導入する | チーム内で挙動やバージョンがそろわない | 検証中は--localと手順書で統一 |
| 接続文字列を許容する | キー漏えいやローテーション負荷が残る | Managed IdentityとKey Vault参照を標準にする |
| 古いランタイムのまま新機能だけ入れる | サポート終了や互換性問題が残る | inventoryで棚卸しし、移行計画を作る |
| azdの自動修正を無条件に許す | IaCや環境設定が意図せず変わる | 最初は説明・ガイド中心で運用する |
特に、AIが出す「修正案」は説得力があるため、レビューが甘くなりがちです。接続先、権限、課金、ネットワーク、リージョン、監視の観点は、人間が責任を持って確認する必要があります。
まず何から始めるべきか
Azure FunctionsのCopilot-assisted codingとagent skillsは、Function Appの開発を速くするだけでなく、生成コードの品質、シークレット管理、デプロイ前検証、運用確認のばらつきを減らすための更新です。特にazure-functions-skillsとdoctorは、開発者の作業を支援するだけでなく、チームの標準化にも使えます。
最初にやるべきことは、次の3つです。
1つ目は、非本番の検証リポジトリで@azure/functions-skillsを--local導入し、どのファイルが生成されるかを確認することです。
2つ目は、Managed Identity、Key Vault参照、Flex Consumption、azd、CIのdoctor実行条件を、チームの標準として整理することです。
3つ目は、既存Function Appのランタイム、言語バージョン、.NET実行モデル、シークレット管理を棚卸しし、AI支援で新規作成する範囲と、人間が移行計画を立てる範囲を分けることです。
この更新は、Azure Functions開発を「AIに任せる」ためのものではありません。Azure Functionsに適した判断基準をAIエージェントに持たせ、開発者と管理者がより早く、安全にレビューできる状態を作るためのものです。
コメント