結論からいうと、2026年6月15日の更新は、Azure FunctionsやAzure Storageのサービス仕様・料金を変更するものではありません。Visual Studio Code向け公式手順で参照しているhost.jsonのサンプルが修正され、Python、PowerShell、Javaでは、非推奨の拡張機能バンドル3.xではなく、現行の4.xが表示されるようになりました。(GitHub)
既存のFunction Appが自動更新されたり、突然動作しなくなったりする変更ではありません。ただし、プロジェクトのhost.jsonがまだ3.xを指定している場合は、バインディングの互換性を確認したうえで4.xへの更新を検討すべきです。
Azureの新機能・変更点：Connect Azure Functions to Azure Storage using Visual Studio Codeの変更点
2026年6月15日の変更では、公式ドキュメント内に埋め込まれるコードスニペットの参照先が、旧PythonサンプルからPython v2モデルのサンプルへ切り替えられました。
| 確認項目 | 変更前 | 変更後 |
|---|---|---|
host.jsonの参照先 | 旧Pythonサンプルリポジトリ | Python v2モデルのサンプルリポジトリ |
| 拡張機能バンドル | [3.*, 4.0.0) | [4.*, 5.0.0) |
| サポート状態 | 3.xは非推奨 | 4.xはアクティブ |
| ログ設定例 | 拡張機能バンドルのみ | Application Insightsのサンプリング設定を含む |
| Azure上の既存アプリ | 変更なし | 変更なし |
| 料金体系 | 変更なし | 変更なし |
旧サンプルリポジトリは2026年6月12日にアーカイブされています。更新後は、現在も管理されているPython v2モデルのhost.jsonが参照されます。(GitHub)
なお、Microsoft Learnのページ下部には「最終更新日：2024年4月26日」と表示されていますが、GitHub上のソース履歴には2026年6月15日のコミットが記録されています。更新日だけを確認すると今回の修正を見落とす可能性がある点には注意が必要です。(Microsoft Learn)
実務上の重要な変更は拡張機能バンドル4.xへの更新
拡張機能バンドルは、Azure Functionsでトリガーや入出力バインディングを利用するための拡張機能をまとめたものです。Python、JavaScript、TypeScript、PowerShell、Javaなどの非.NET言語では、通常host.jsonで使用するバンドルを指定します。
現在推奨される最小構成は次のとおりです。
{
"version": "2.0",
"extensionBundle": {
"id": "Microsoft.Azure.Functions.ExtensionBundle",
"version": "[4.0.0, 5.0.0)"
}
}公式手順にある[4.*, 5.0.0)も同じ意味で、4.xの範囲内から利用可能な新しいバージョンが選択されます。4.xはアクティブ、3.x以前は非推奨です。3.xのアプリが直ちに停止するわけではありませんが、新機能、性能改善、セキュリティ更新、完全なサポートを受けるには4.xへの移行が推奨されています。(Microsoft Learn)
host.json全体を上書きしない
更新後の公式サンプルには、次のApplication Insights設定も含まれています。
"logging": {
"applicationInsights": {
"samplingSettings": {
"isEnabled": true,
"excludedTypes": "Request"
}
}
}この設定は、サンプリングを有効にしつつ、Requestテレメトリをサンプリング対象から除外する例です。HTTP要求の実行履歴を残しやすくなる一方、アクセス量が多い環境ではApplication Insightsへのデータ取り込み量も確認する必要があります。(Microsoft Learn)
既存プロジェクトには、ログレベル、タイムアウト、HTTP設定、個別バインディング設定などが含まれている場合があります。公式サンプルをそのまま貼り付けるのではなく、まずextensionBundle.versionだけを比較してください。
誰に影響するのか
| 対象 | 影響 | 必要な対応 |
|---|---|---|
| Python利用者 | 今回のドキュメント修正の直接対象 | host.jsonのバンドルバージョンを確認 |
| PowerShell利用者 | Python v2のhost.jsonサンプルを共通参照 | 3.xなら4.xへの更新を検討 |
| Java利用者 | 同じコードスニペット参照を利用 | バインディングを含むローカルテストを実施 |
| JavaScript・TypeScript利用者 | 別の4.xサンプルを参照しており、今回の差分は限定的 | 現在の設定確認のみ |
| C#利用者 | 拡張機能バンドルではなくNuGetパッケージを利用 | 今回の変更による直接対応は不要 |
| 既存Function Appの管理者 | Azure上の構成は自動変更されない | 再デプロイや緊急対応は不要 |
| 新規構築する利用者 | 最初から4.xの例を参照できる | 現行手順に沿って構築 |
拡張機能バンドルは非.NET言語向けです。C#では、分離ワーカーモデルとインプロセスモデルに応じたStorage拡張パッケージをプロジェクトへ追加します。(Microsoft Learn)
host.jsonを確認して更新する手順
現在のバージョンを確認する
プロジェクト直下のhost.jsonを開き、extensionBundleを検索します。
次のような指定なら3.xです。
"version": "[3.*, 4.0.0)"次の指定なら4.xです。
"version": "[4.*, 5.0.0)"4.xを利用している場合、今回の変更だけを理由に設定を変更する必要はありません。
3.xから4.xへ更新する
3.xの場合は、次の順序で進めます。
- 作業用ブランチを作成する
- Queue以外に利用しているバインディングを洗い出す
extensionBundle.versionを4.xへ変更する- Azure Functions Core Toolsでローカル起動する
- HTTPトリガーを実行する
- Queue Storageへの書き込みを確認する
- 検証環境へデプロイしてから本番へ反映する
拡張機能バンドルにはQueue、Blob、Service Bus、Event Hubs、Cosmos DBなど複数の拡張機能が含まれます。Queue出力だけが正常でも、同じFunction App内の別バインディングに影響が出る可能性があるため、使用中の関数を一通りテストしてください。公式情報でも、バンドル更新後のローカル検証と破壊的変更の確認が推奨されています。(Microsoft Learn)
ネットワーク制限がある環境ではCDNへの接続も確認する
バンドルの更新時には、Function Appがcdn.functions.azure.comから拡張機能を取得します。送信通信を制限している環境では、このエンドポイントへ接続できないと拡張機能の取得に失敗する可能性があります。(Microsoft Learn)
Azure Storageへの接続設定で確認すべき項目
公式手順では、Function App作成時のストレージアカウントを使い、AzureWebJobsStorageを介してQueue Storageへ接続します。
| 設定・項目 | 確認内容 | 失敗しやすいポイント |
|---|---|---|
AzureWebJobsStorage | 接続先が意図したストレージアカウントか | 別環境の接続文字列を使用している |
local.settings.json | ローカル実行用の設定が存在するか | リポジトリへ誤ってコミットする |
queueName | outqueueまたは運用上のキュー名か | 別名のキューに出力している |
| ストレージのネットワーク | Function Appからアクセス可能か | ファイアウォールやVNetで遮断される |
| マネージドID | 必要なRBACロールがあるか | IDだけ有効化して権限を付与していない |
| Application Insights | 取り込み量とサンプリング設定 | 高トラフィック環境でログ量が増える |
リモート設定のダウンロードに注意する
Visual Studio Codeでは、コマンドパレットからAzure Functions: Download Remote Settings...を実行すると、Azure上のアプリ設定をlocal.settings.jsonへダウンロードできます。
この操作では既存のローカル設定を上書きすることがあります。実行前に次の点を確認してください。
- 正しいサブスクリプションとFunction Appを選択しているか
- ローカル固有の設定をバックアップしたか
local.settings.jsonがGitの管理対象外になっているか- 接続文字列をチャットやチケットへ貼り付けていないか
公式手順でも、local.settings.jsonにはシークレットが含まれるため、ソース管理に含めないよう案内されています。(Microsoft Learn)
本番環境ではマネージドIDも検討する
今回の更新は、接続文字列からマネージドIDへの移行を強制するものではありません。ただし、本番運用で接続文字列の漏えいやローテーション負担を減らしたい場合は、IDベース接続を検討できます。
AzureWebJobsStorageをIDベース接続に変更する場合は、対応するFunctionsランタイムと拡張機能を使用し、ストレージアカウント側で必要なRBACロールを付与する必要があります。既存の接続文字列だけを削除すると、Function Appが起動できなくなることがあるため、設定と権限をセットで移行してください。(Microsoft Learn)
Visual Studio Codeで動作を確認する方法
公式手順の確認フローは次のとおりです。
F5でFunction Appをローカル起動する- AzureのFunctionsビューから対象関数を右クリックする
Execute Function Now...を選択する- HTTP要求を送信する
- Azure Storage Explorerで対象ストレージアカウントを開く
- Queuesから
outqueueを選択する - 送信した値に対応するメッセージがあることを確認する
outqueueが存在しない場合、出力バインディングが最初に正常実行された時点で作成されます。HTTPレスポンスが成功しただけでは、Queueへの書き込み成功までは確認できません。必ずStorage Explorerでメッセージを確認してください。(Microsoft Learn)
言語別の設定箇所
| 言語 | Queue出力バインディングの主な設定箇所 |
|---|---|
| JavaScript | output.storageQueue、extraOutputs、context.extraOutputs.set |
| TypeScript | StorageQueueOutput、extraOutputs、context.extraOutputs.set |
| Python | @app.queue_outputとmsg.set |
| PowerShell | function.jsonとPush-OutputBinding |
| Java | @QueueOutputとOutputBinding.setValue |
| C#分離ワーカー | QueueOutput属性を持つ戻り値クラス |
| C#インプロセス | Queue属性とICollectorなど |
JavaScriptとTypeScriptでは、現在の公式手順がNode.js向けFunctionsプログラミングモデルv4を前提としている点にも注意してください。(Microsoft Learn)
移行期限はあるのか
今回の2026年6月15日のドキュメント更新自体に、対応期限は設定されていません。
| 対象 | 状態・期限 | 推奨対応 |
|---|---|---|
| 公式ドキュメントの参照先変更 | 対応期限なし | 既存設定を確認する |
| 拡張機能バンドル3.x | 非推奨、明示的な終了日は未掲載 | 4.xへの更新計画を立てる |
| 拡張機能バンドル4.x | アクティブ | 継続利用する |
| C#インプロセスモデル | 2026年11月10日にサポート終了 | 分離ワーカーモデルへ移行する |
C#インプロセスモデルの期限は、今回のコードスニペット修正とは別のサポート変更です。C#で旧モデルを利用している場合は、Storage接続の確認だけでなく、分離ワーカーモデルへの移行計画も進める必要があります。(Microsoft Learn)
料金への影響
今回の変更によって新しい料金が追加されたり、料金単価が変更されたりしたわけではありません。ただし、サンプルを実行するとAzureリソースを利用するため、次の費用は引き続き発生する可能性があります。
| 費用の種類 | 主な確認項目 |
|---|---|
| Azure Functions | ホスティングプラン、実行回数、実行時間、メモリ使用量 |
| Queue Storage | 保存容量、メッセージ書き込み、読み取り、削除などの操作回数 |
| Application Insights | テレメトリのデータ取り込み量、保持期間 |
| ネットワーク | リージョン間転送や外向きデータ転送 |
| Always Readyなど | 常時確保しているインスタンスとメモリ |
Azure Functionsのストレージ料金はFunctionsの無料枠に含まれず、ストレージ料金とネットワーク料金が別途発生する場合があります。Queue Storageでは容量に加え、PutMessageやDeleteMessageなどの書き込み系操作、GetMessageやPeekMessageなどの読み取り系操作が課金対象になります。(Microsoft Azure)
Application Insightsは、データ取り込み量や無料保持期間を超えた保持が料金に影響します。高トラフィックのHTTP関数では、excludedTypes: "Request"を含むサンプリング設定と実際の取り込み量をAzure Monitorで確認してください。(Microsoft Azure)
よくある失敗と注意点
- ドキュメント修正をAzureサービスの強制変更と誤解し、不要な緊急デプロイを行う
- 公式の
host.jsonを丸ごと貼り付け、既存のログやタイムアウト設定を削除する - 拡張機能バンドルを本番環境で直接3.xから4.xへ変更する
- Queue以外のバインディングをテストせずにデプロイする
- HTTPレスポンスだけを確認し、Queueにメッセージがないことを見落とす
local.settings.jsonや接続文字列をGitへコミットする- マネージドIDを有効化しただけで、ストレージ側のRBAC設定を忘れる
まずhost.jsonを確認して必要な場合だけ更新する
今回の変更で最初に行うべきことは、プロジェクトのhost.jsonを開き、拡張機能バンドルが3.xか4.xかを確認することです。
すでに4.xなら、今回の更新を理由とした再デプロイは不要です。3.xなら作業用ブランチで4.xへ変更し、Queueを含むすべてのバインディングをローカルで検証してください。そのうえで、AzureWebJobsStorage、Storage Explorer上の出力メッセージ、Application Insightsのログ量を確認してから本番へ反映するのが安全です。
コメント