Azure FunctionsでAIコーディングエージェントを使うなら、今回の「azure-functions-skills」はかなり実務寄りの更新です。結論から言うと、これはAzure Functions本体のランタイム変更ではなく、GitHub Copilot CLI、Claude Code、Codex CLI、VS CodeなどのAIエージェントに、Azure Functions向けの作成・診断・デプロイ・検証の作法を持たせるためのプレビュー機能です。Microsoftの公式ブログでは、azure-functions-skillsがPublic Previewとして紹介され、スキル、MCP構成、hooks、各種指示ファイル、CLIをまとめて導入できると説明されています。(Microsoft for Developers)
特に重要なのは、AIが生成するAzure Functionsコードを「とりあえず動く」状態で終わらせず、マネージドID、Key Vault参照、Flex Consumption、バインディング、並行処理、デプロイ前検証まで含めて扱いやすくする点です。開発者は導入コマンドだけで試せますが、管理者はAIエージェントの権限、CIでのdoctor --deep実行、シークレット管理、リポジトリに追加される設定ファイルの扱いを必ず確認する必要があります。
Azure FunctionsのAI/Copilot更新で何が変わるのか
今回の更新で変わるのは、Azure Functionsそのものの実行基盤ではなく、AIエージェントを使った開発体験です。
これまで汎用的なAIコーディングエージェントにAzure Functionsの実装を任せると、古いプログラミングモデル、ハードコードされた接続文字列、スケールしにくいクライアント生成、IDベース接続を使わないコードが出てくることがありました。公式ブログでも、一般的なエージェントは新しいAzure Functions機能や最新のバインディング形状に追従できず、セキュリティやスケーラビリティの面で課題があると説明されています。(Microsoft for Developers)
azure-functions-skillsは、そのギャップを埋めるために、Azure Functions向けの作業手順や判断基準をAIエージェント側に渡します。たとえば、HTTPトリガーやService Busトリガーを作るだけでなく、マネージドIDを使う、Key Vault参照を使う、デプロイ前にdoctorで構成ミスを検出するといった流れを支援します。
| 観点 | 従来の汎用AIエージェント利用 | azure-functions-skills導入後の狙い |
|---|---|---|
| コード生成 | 動くサンプル中心になりやすい | Azure Functions向けの最新テンプレートや推奨パターンに寄せる |
| セキュリティ | 接続文字列やキーをコードに含めるリスク | マネージドID、Key Vault参照、IDベース接続を促す |
| デプロイ | 手順がエージェント任せになりやすい | Functions向けの準備・検証・デプロイ手順を案内 |
| 障害予防 | デプロイ後に問題が表面化しやすい | doctorで構成・依存関係・コード上の問題を事前検出 |
| チーム利用 | 開発者ごとにAIへの指示がばらつく | instructions、MCP構成、hooksをワークスペースに配置して統一しやすい |
ポイントは、AIを「コードを書くだけの補助」から「Azure Functionsの開発ワークフローに沿って動く補助」に近づけることです。
azure-functions-skillsとは何か
azure-functions-skillsは、Azure Functions向けのAIコーディングエージェント用プラグイン群です。公式ブログでは、@azure/functions-skillsはnpmパッケージ兼CLI、azure-functions-skillsはCLIが導入するスキルや指示セット、functions-copilotは適切なスキルにルーティングするエージェント定義として整理されています。(Microsoft for Developers)
含まれる主な要素は次のとおりです。
| 要素 | 役割 |
|---|---|
| Skills | setup、create、deploy、diagnostics、doctorなど、作業目的別のプレイブック |
| agent definition | ユーザーの依頼内容に応じて適切なスキルへ誘導する定義 |
| MCP server configuration | Azure Functions開発に必要な文脈や外部ツール連携をエージェントに渡す構成 |
| hooks | ワークフローの特定タイミングで動作する補助設定 |
| instruction files | copilot-instructions.md、CLAUDE.md、AGENTS.mdなど、エージェントへの指示ファイル |
| CLI | インストール、チャット起動、デプロイ前検証を実行する@azure/functions-skills |
重要なのは、これはAzure Functions Core ToolsやAzure CLIの置き換えではない点です。既存の開発ツールをAIエージェントから使いやすくし、Azure Functions向けの判断を補強するためのワークスペース支援機能と考えると理解しやすいでしょう。
対象となる利用者と影響範囲
azure-functions-skillsの影響を受けるのは、主にAzure FunctionsをAI支援で作成・運用する開発者、DevOps担当者、クラウド管理者です。既存のFunction Appが自動的に変更されるわけではありません。ただし、CLIを導入してワークスペースに設定ファイルを追加したり、CIにdoctorを組み込んだり、エージェントにデプロイ操作を任せたりする場合は、運用ルールの見直しが必要です。
| 立場 | 確認すべきこと |
|---|---|
| アプリ開発者 | 生成コードが最新のFunctionsモデル、非同期処理、バインディング、例外処理に沿っているか |
| DevOps担当者 | doctorをどのタイミングでCIに入れるか、--deepをどの環境で許可するか |
| クラウド管理者 | Azureサブスクリプション、RBAC、マネージドID、Key Vault、ネットワーク制約の設計 |
| セキュリティ担当者 | AIエージェントのシェル実行権限、シークレット、外部通信、プロンプトインジェクション対策 |
| チームリード | instructionsやMCP構成をリポジトリで共有するか、個人環境に閉じるか |
すでにAzure Functionsを本番運用しているチームは、いきなりデプロイまで任せるのではなく、まず既存リポジトリでdoctorによる検証だけを行い、検出結果を確認する使い方が安全です。
プレビューで提供される主なスキル
公式ブログでは、プレビュー開始時点のスキルセットは意図的に小さく始め、Azure Functionsのリリースに合わせて拡張していく方針が示されています。スキル一覧には、環境セットアップ、プロジェクト作成、AIエージェントアプリ、デプロイ、ベストプラクティス確認、診断、ヘルス確認、インベントリ収集、デプロイ前検証、フィードバック作成が含まれます。(Microsoft for Developers)
| スキル | 主な用途 | 実務での使いどころ |
|---|---|---|
azure-functions-setup | Azure CLI、azd、Core Tools、言語ランタイムなどの確認 | 新規メンバーの開発環境セットアップ |
azure-functions-create | 新規Functionsプロジェクト作成、既存プロジェクトへの関数追加 | HTTPトリガー、Timerトリガー、Service Bus連携などの作成 |
azure-functions-agents | Azure Functions上で動くAIエージェントアプリの作成・展開・トラブルシュート | 定期実行エージェント、イベント駆動エージェント、チャット/API型エージェント |
azure-functions-deploy | Azure Skillsと連携した準備・検証・デプロイ | Flex ConsumptionやID設定を含む展開 |
azure-functions-best-practices | 既存Function Appの推奨設定レビュー | 本番化前レビュー、技術的負債の洗い出し |
azure-functions-diagnostics | デプロイ失敗、実行時エラー、トリガー、バインディング、ログ問題の調査 | 障害調査、ログ不足の確認 |
azure-functions-health-status | 稼働状態、メトリック、Application Insights、Resource Healthなどの確認 | 運用監視、一次切り分け |
azure-functions-inventory | SKU、ランタイム、ネットワーク、ID、設定、トリガーの棚卸し | 移行前調査、監査、標準化 |
azure-functions-doctor | デプロイ前検証 | CIゲート、ローカル検証 |
azure-functions-feedback | セッション中の気づきをGitHub IssueやPR案にする | プレビュー機能への改善要望 |
この中で最初に試す価値が高いのは、setup、create、doctorです。既存システムへの影響を抑えながら効果を確認できます。
導入に必要な前提条件
公式ブログでは、利用要件としてNode.js 18以上、Azureサブスクリプション、GitHub Copilot CLI・Claude Code・Codex CLI・VS Codeのいずれかが挙げられています。(Microsoft for Developers)
導入前に、次の項目を確認してください。
| 確認項目 | 判断基準 | 注意点 |
|---|---|---|
| Node.js | Node.js 18以上 | CIではNode.jsのバージョンを固定する |
| Azureサブスクリプション | 検証用サブスクリプションまたはリソースグループを用意 | 初回検証で本番サブスクリプションを使わない |
| エージェント | GitHub Copilot CLI、Claude Code、Codex CLI、VS Codeのいずれか | チームで標準エージェントを決めると運用しやすい |
| Azure CLI / azd / Core Tools | setupスキルで不足を確認 | 既存環境に複数バージョンがある場合はPATHを確認 |
| 権限 | Azureへの読み取り・作成・デプロイ権限 | 最小権限を基本にし、個人アカウント依存を避ける |
| シークレット管理 | Key Vault、マネージドID、OIDCを優先 | 接続文字列を.envやコードに残さない |
基本的な導入手順
最小構成で試す場合は、対象リポジトリのルートでインストールし、チャットを起動し、最後にdoctorで検証します。公式ブログでは、GitHub Copilot CLI、Claude Code、Codex CLI向けのインストール例が示されています。(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デプロイ前の検証は、次のように実行できます。
npx @azure/functions-skills doctor --dir . --format html --output doctor-report.html深いコード解析を行う場合は、--deepを付けます。
npx @azure/functions-skills doctor --dir . \
--deep --accept-deep-risk \
--agent github-copilot \
--format html --output doctor-deep.htmlただし、--deepはAIエージェントにワークスペース上のファイル書き込みやシェル実行権限を与えるため、信頼できる環境でのみ使うべきです。GitHub上のDoctor Guideでも、Tier 2である--deepはオプトインであり、エージェントが高い権限で実行されると説明されています。(GitHub)
user scopeとlocal scopeの違いを理解する
導入時に見落としやすいのが、インストール範囲です。
公式ブログによると、デフォルトではスキル本体はユーザースコープに入り、MCP構成、エージェント定義、hooks、CLAUDE.mdやAGENTS.mdなどのワークスペース成果物は現在のディレクトリに配置されます。すべてをプロジェクト側に置きたい場合は--localを追加します。(Microsoft for Developers)
| インストール方法 | 向いているケース | 注意点 |
|---|---|---|
| デフォルト | 個人の開発環境で複数プロジェクトに使う | ユーザーごとの環境差が出やすい |
--local | プロジェクト単位でスキルや設定を閉じたい | リポジトリに含めるファイルのレビューが必要 |
| ワークスペース成果物をコミット | チームでAIへの指示を統一したい | MCP構成やhooksの変更をコードレビュー対象にする |
| 個人環境に閉じる | 試験導入、PoC | チーム標準化には向かない |
実務では、最初は検証用ブランチで導入し、生成・変更されたファイルを確認してから、どのファイルをコミット対象にするか決めるのが安全です。
管理者と開発者が確認すべき設定
azure-functions-skillsは便利ですが、AIエージェントがAzure操作やローカルコマンド実行に近づくため、導入前に確認すべき設定が増えます。
リポジトリに追加されるファイルをレビューする
インストールにより、MCP構成、hooks、指示ファイルなどがワークスペースに追加される場合があります。これらはAIエージェントの動作に影響するため、通常のアプリケーションコードと同じようにレビュー対象にしてください。
特に確認したいのは次の点です。
| ファイル・設定 | 確認ポイント |
|---|---|
copilot-instructions.md | チームの開発規約、禁止事項、セキュリティ方針と矛盾しないか |
CLAUDE.md / AGENTS.md | 特定エージェント向けの指示が過剰な権限を前提にしていないか |
| MCP構成 | 接続先、実行可能なツール、参照するサービスが妥当か |
| hooks | 予期しないコマンド実行や外部通信が含まれていないか |
.azure-functions-skills/ | 状態管理用の内容をコミットすべきか、.gitignoreに入れるべきか |
AI向けの指示ファイルは、実質的には「開発手順を自動化する設定」です。軽いドキュメントではなく、CI設定やIaCテンプレートに近い重要度で扱うべきです。
マネージドIDとKey Vault参照を前提にする
公式ブログでは、azure-functions-skillsがマネージドID、Key Vault参照、Flex Consumption、スケールするバインディング・並行処理パターンにエージェントを誘導すると説明されています。(Microsoft for Developers)
そのため、管理者は次の設計を先に決めておくと、AI生成コードのレビューが楽になります。
| 項目 | 推奨される確認 |
|---|---|
| Function AppのID | システム割り当てマネージドIDか、ユーザー割り当てマネージドIDか |
| Key Vault | 参照するシークレット名、アクセス権限、環境分離 |
| RBAC | Blob Storage、Service Bus、Cosmos DBなどへの最小権限 |
| ローカル開発 | 開発者のAzureログイン権限、テスト用リソース |
| 本番接続 | 接続文字列ではなくIDベース接続を優先できるか |
AIが「接続文字列を入れてください」と提案した場合は、そのまま受け入れず、IDベース接続やKey Vault参照に置き換える方針をチーム標準にしてください。
Flex Consumptionやネットワーク要件を確認する
azure-functions-deployでは、Flex Consumption、functionAppConfig、プライベートネットワーク、IDなどFunctions固有のガイダンスが含まれると説明されています。(Microsoft for Developers)
新規プロジェクトではAIが推奨構成を提案してくれる可能性がありますが、実際の採用可否は次の観点で判断します。
| 判断軸 | 確認内容 |
|---|---|
| コスト | 従量課金、常時稼働、ピーク時の実行量に合うか |
| スケール | トリガーの種類、同時実行、バックエンドサービスの制限と整合するか |
| ネットワーク | VNet統合、プライベートエンドポイント、名前解決の要件があるか |
| 監視 | Application Insights、ログ保持、アラート設計があるか |
| 運用 | デプロイ承認、ロールバック、構成変更履歴を追えるか |
AIが提示したデプロイ構成は、あくまでたたき台です。特にネットワークとID周りは、組織の標準設計に合わせてレビューしてください。
doctorで何を検出できるのか
doctorは、azure-functions-skillsの中でも管理者・開発者双方にとって価値が高い機能です。公式ブログでは、Azure Functionsのサポートインシデントの大きな原因としてユーザーコードの欠陥とFunction Appの設定ミスが挙げられ、doctorはそれらをデプロイ前に検出するための機能として紹介されています。(Microsoft for Developers)
Doctor Guideでは、doctorは2段階で動作すると説明されています。Tier 1は決定的なNode.jsチェックで、Tier 2は--deepを付けた場合のLLMエージェントによる意味的なコード解析です。(GitHub)
| 段階 | 実行方法 | 検出対象の例 | 適した場所 |
|---|---|---|---|
| Tier 1 | 通常実行、または--no-deep | host.json、非推奨設定、ランタイム不整合、FUNCTIONS_WORKER_RUNTIME不足、lockfile不足、追跡された.envなど | ローカル、PR、CI |
| Tier 2 | --deep --accept-deep-risk | ハードコードされたシークレット、blocking I/O、例外処理不足、Durable Functionsの非決定的処理、依存関係の意味的リスクなど | 信頼済み環境、post-merge、リリース前 |
最初に導入するなら、PRではTier 1だけを実行し、mainブランチへのマージ後やリリース前にTier 2を実行する構成が現実的です。
CI/CDに組み込むときの注意点
doctorはCIに組み込めますが、--deepの扱いには注意が必要です。公式ブログでは、--deepはファイル書き込みとシェル実行権限を持つコーディングエージェントを動かすため、入力がプロンプトインジェクションの攻撃面になり得ると説明されています。また、pull requestイベントではデフォルトで--deepを拒否し、信頼済みのpost-mergeやreleaseで使うパターンが推奨されています。(Microsoft for Developers)
GitHub上のDoctor Guideでも、Pull RequestではTier 1のみ、Tier 2はpush to mainなどのpost-mergeで実行し、GitHub Environmentなどで承認やシークレットのスコープ制限を行う例が示されています。(GitHub)
PRではTier 1だけを実行する
name: Azure Functions doctor
on: [pull_request]
jobs:
doctor:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '22'
- name: Run Azure Functions doctor
run: |
npx @azure/functions-skills doctor \
--no-deep \
--format markdown \
--output doctor.md \
--severity highこの段階では、未信頼のPull RequestコードにAIエージェントの高権限実行を許可しません。構成ミスや依存関係の基本的な問題を早めに検出する目的に限定します。
--deepはpost-mergeで実行する
--deepは、マージ済みの信頼できるコードに対して実行します。さらに、GitHub Environmentなどで手動承認やシークレットのスコープ制限を入れると安全性が上がります。
name: Azure Functions deep doctor
on:
push:
branches: [main]
jobs:
deep-doctor:
runs-on: ubuntu-latest
environment: trusted-deep-analysis
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '22'
- name: Run deep doctor
env:
GITHUB_TOKEN: ${{ secrets.COPILOT_TOKEN }}
run: |
npx @azure/functions-skills doctor \
--deep --accept-deep-risk \
--agent github-copilot \
--format html \
--output doctor.htmlセキュリティ文書では、--deepを本番運用に近い環境で使う場合、信頼済み環境でのみ実行すること、長期シークレットではなくOIDCを優先すること、CIランナーの外向き通信制御を検討することなどが挙げられています。(GitHub)
既存プロジェクトへ導入する場合の進め方
既存のAzure Functionsプロジェクトでは、いきなりAIに修正やデプロイを任せるのではなく、影響の小さい順に導入します。
| フェーズ | 実施内容 | 成功条件 |
|---|---|---|
| 検証 | 検証ブランチでinstallし、追加ファイルを確認 | 不要な設定や危険なhooksがない |
| 棚卸し | inventoryやdoctorで構成を確認 | SKU、ランタイム、トリガー、設定の現状が把握できる |
| ローカル検証 | doctor --dir .を実行 | 高・重大レベルの問題を洗い出せる |
| 修正 | best-practicesやdiagnosticsを参考に差分を作成 | 変更内容を人間がレビューできる |
| CI導入 | PRでTier 1を実行 | 構成ミスをマージ前に検出できる |
| 深い解析 | post-mergeで--deepを実行 | 信頼済み環境で意味的なコード問題を検出できる |
| 展開 | 検証環境でデプロイを試す | ID、ネットワーク、監視、ロールバックが確認済み |
既存システムで最も避けたい失敗は、「AIが提案した修正をまとめて適用し、レビューしきれない差分を作ること」です。最初はdoctorの検出結果を1件ずつIssue化し、通常の修正フローに乗せる方が安全です。
新規プロジェクトで活用する場合の実務例
新規のAzure Functionsプロジェクトでは、azure-functions-skillsの効果を感じやすくなります。たとえば、次のような依頼が実用的です。
PythonでHTTP triggerを作成し、Cosmos DBをマネージドIDで読み取り、Service Bus output bindingを追加してください。
ローカル実行手順、必要なAzureリソース、デプロイ前のdoctor検証も含めてください。公式ブログにも、Python HTTPトリガーからCosmos DBをマネージドIDで読み取り、Service Bus出力バインディングを追加する例が示され、エージェントがcreateやbest-practicesを使い、IDベース接続を前提に支援する流れが説明されています。(Microsoft for Developers)
新規開発で意識したいのは、最初のプロンプトに「セキュリティと運用条件」を含めることです。
| 入れるべき条件 | 例 |
|---|---|
| 認証方式 | 接続文字列ではなくマネージドIDを使う |
| シークレット | Key Vault参照を前提にする |
| 実行プラン | Flex Consumptionを前提に検討する |
| 監視 | Application Insightsのログ確認手順を含める |
| テスト | ローカル実行、単体テスト、デプロイ前doctorを含める |
| CI | PRでは--no-deep、mainでは--deepを検討する |
AIに「関数を作って」とだけ依頼すると、完成物の品質はエージェント側の判断に寄ります。最初から運用条件を渡すことで、レビューしやすい出力になります。
AIエージェントアプリ開発での位置づけ
プレビューにはazure-functions-agentsスキルも含まれています。公式ブログでは、Azure Functions serverless agents runtime向けに、イベント駆動AIエージェントの作成、拡張、デプロイ、トラブルシュートを支援するスキルとして紹介されています。(Microsoft for Developers)
ただし、AIエージェントアプリは通常のHTTP APIより確認項目が多くなります。
| 確認領域 | 注意点 |
|---|---|
| モデル利用 | サブスクリプション、リージョン、クォータ、利用可能モデルを確認 |
| 外部接続 | MCPサーバー、Connector Namespaces、外部APIの権限を確認 |
| 実行環境 | Azure Container Apps dynamic sessionsなどを使う場合のネットワーク・コスト |
| データ保護 | 入力データ、会話履歴、ログに機密情報が残らない設計 |
| 監査 | エージェントがどの操作を実行したか追跡できるログ設計 |
| 失敗時動作 | 再試行、重複実行、タイムアウト、補償処理の設計 |
AIエージェントアプリでは、「動く」ことよりも「何を実行できるかを制御できる」ことが重要です。azure-functions-skillsを使って足場を作る場合でも、権限境界とログ設計は人間が明確に決める必要があります。
プレビュー利用時のリスクと現実的な対策
azure-functions-skillsはPublic Previewです。公式ブログでも、スキルセットは開始時点では小さく、Azure Functionsのリリースに合わせて拡張されると説明されています。(Microsoft for Developers)
プレビュー段階で本番ワークフローに組み込む場合は、次の対策を取ると安全です。
| リスク | 対策 |
|---|---|
| 機能やコマンドの変更 | npmパッケージのバージョンを固定し、更新時に検証する |
| AIの出力品質のばらつき | 生成コードを必ずコードレビュー対象にする |
| 権限の過大付与 | Azure RBAC、GitHub Environment、OIDC、短期トークンを使う |
| プロンプトインジェクション | --deepを未信頼PRで実行しない |
| 設定ファイルの混入 | MCP構成、hooks、instructionsをレビュー対象にする |
| デプロイ事故 | まず検証環境、次にステージング、本番は承認後に展開する |
特に、doctor --deepは「便利な静的解析」ではなく、「権限を持ったAIエージェントをワークスペースで実行する操作」です。この前提をチームで共有しておくことが重要です。
よくある疑問
Azure Functionsの既存アプリを移行する必要はある？
必須ではありません。azure-functions-skillsはAzure Functionsの開発・診断・展開を支援するAIワークスペースであり、既存Function Appのランタイムを自動的に変更するものではありません。
ただし、既存アプリの品質確認には有用です。まずdoctorで構成や依存関係を確認し、必要に応じてbest-practicesやdiagnosticsを使う流れが向いています。
Azure Functions Core Toolsは不要になる？
不要にはなりません。Core Tools、Azure CLI、Azure Developer CLI、言語ランタイムなどは引き続き重要です。azure-functions-skillsは、それらの存在確認や利用手順をAIエージェントから扱いやすくする役割です。
VS Codeだけでも使える？
公式ブログでは、VS Codeユーザーはワークスペースを開き、GitHub Copilot Chatのエージェントピッカーからfunctions-copilotを選び、setupスキルを実行する流れが紹介されています。(Microsoft for Developers)
CLI中心のチームでなくても、VS Codeを標準IDEにしているチームなら導入候補になります。
本番CIで--deepを使ってよい？
使う場合は、Pull Requestではなくpost-mergeやreleaseの信頼済み環境に限定してください。--deepはAIエージェントにファイル書き込みとシェル実行権限を与えるため、未信頼コードで実行すると危険です。Doctor Guideでも、PRではTier 1のみ、Tier 2はpost-mergeで使う設計が示されています。(GitHub)
チーム全員にすぐ導入すべき？
全員導入より先に、1つの検証リポジトリで標準設定を固めるのがおすすめです。特に、instructions、MCP構成、hooks、CIのdoctor設定、シークレット管理方針を決めてから展開すると、開発者ごとのばらつきを減らせます。
導入前チェックリスト
最後に、管理者と開発者が確認すべき項目を整理します。
| チェック項目 | 完了の目安 |
|---|---|
| 検証用リポジトリを用意した | 本番リポジトリへ直接導入していない |
| Node.js 18以上を確認した | ローカルとCIでバージョンを固定できている |
| 利用エージェントを決めた | GitHub Copilot CLI、Claude Code、Codex CLI、VS Codeのいずれかを選定 |
| インストール範囲を決めた | user scopeか--localかをチームで合意 |
| 追加ファイルをレビューした | MCP構成、hooks、instructionsを確認済み |
| マネージドID方針を決めた | Key Vault、RBAC、接続方式の標準がある |
PRでは--no-deepにした | 未信頼PRでAIエージェントを高権限実行しない |
--deepの実行場所を決めた | post-merge、承認付き環境、スコープ済みシークレットで実行 |
| 検出結果の扱いを決めた | doctorの重大度に応じてIssue化・修正・ブロックできる |
| プレビュー更新を追う体制を作った | npmバージョン、GitHub Issue、公式ブログを確認する |
まずは検証ブランチでnpx @azure/functions-skills installを実行し、生成されるワークスペース設定を確認してください。次にdoctorをローカルで実行し、既存プロジェクトの構成ミスや依存関係リスクを洗い出します。問題がなければ、PRではTier 1、post-mergeでは必要に応じてTier 2を実行するCI構成に進めるのが、最も安全で効果を確認しやすい導入手順です。
コメント