2026年6月15日に行われた「Azure Functions HTTP trigger」の更新は、Azure Functionsの動作仕様を変えるサービス更新ではありません。Microsoft Learnで一時的に非表示になっていたC#、Node.js、Pythonのコード例を再表示するためのドキュメント更新です。
そのため、稼働中のFunction Appについて、設定変更や再デプロイ、料金プランの変更を行う必要はありません。ただし、復元されたサンプルを利用する場合は、認証レベルやプログラミングモデルの違いを確認する必要があります。特にC#のインプロセスモデルを利用している環境は、今回の更新とは別に、2026年11月10日のサポート終了へ向けた移行計画が必要です。(GitHub)
Azureの新機能・変更点：Azure Functions HTTP triggerの2026年6月15日更新
2026年6月15日の公式リポジトリ更新では、依存するGitHubリポジトリが一時的に利用できなくなった際にコメントアウトされたコードスニペット参照が、再び有効化されました。
変更内容を整理すると、次のとおりです。
| 確認項目 | 2026年6月15日の変更内容 | 利用者の対応 |
|---|---|---|
| Azure Functionsランタイム | 当該更新による仕様変更は確認されていない | 原則不要 |
| HTTP triggerの設定 | authLevelやrouteなどの変更なし | 原則不要 |
| コード例 | C#、Node.js、Pythonのサンプル表示を復元 | 必要に応じて再確認 |
| デプロイ | 強制更新や再デプロイなし | 不要 |
| 料金 | 当該更新による料金変更なし | 不要 |
| 移行期限 | 新しい期限の追加なし | 別途、利用中ランタイムを確認 |
公式コミットでは、44ファイルに対してコード参照の復元が行われています。そのうちHTTP triggerの記事では、11件のコードスニペット参照が再有効化されました。Azure上で実行されているアプリケーションの設定やバイナリを更新する内容ではありません。(GitHub)
なお、Microsoft Learnのページ下部には「Last updated on 2025-05-02」と表示される場合があります。一方、公式GitHubリポジトリの履歴では、2026年6月15日の更新を確認できます。更新状況を厳密に確認するときは、ページ上の日付だけでなく、公式リポジトリの変更履歴も確認するのが確実です。(GitHub)
復元された主なコード例
今回の更新で復元されたのは、HTTP triggerの基本実装からHTTPストリームまでを扱うサンプルです。
C#の分離ワーカーモデル
HttpResponseDataを使ってHTTPレスポンスを作成する、C#分離ワーカーモデルのコード例が復元されました。
主に次の処理を確認できます。
HttpTrigger属性によるHTTPメソッドの指定CreateResponseによるステータスコードの設定Content-Typeヘッダーの追加WriteStringによるレスポンス本文の生成
C#で新規開発する場合は、サポート期限を考慮し、インプロセスモデルではなく分離ワーカーモデルを優先するのが適切です。(GitHub)
Node.js v4のJavaScript・TypeScript
Node.js v4プログラミングモデルでは、次のコード例が復元されています。
- 基本的なHTTP trigger
- クエリ文字列とリクエスト本文の読み取り
- ルートパラメーターの取得
- ルート制約の使用
- ルートパラメーターをTable Storage入力バインドに渡す処理
例えば、次のようなルートを設定できます。
route: 'products/{category:alpha}/{id:int?}'この例では、categoryを英字に限定し、idを省略可能な整数として扱います。URL設計と入力値の制約を同時に定義できるため、API側で不要なリクエストを早い段階で除外できます。(Microsoft Learn)
Python v2のHTTPストリーム
Python v2プログラミングモデルでは、FastAPI互換のAPIを利用したストリーミング送受信のサンプルが復元されました。
復元対象には、次の内容が含まれます。
- 必要なPythonパッケージ
- FastAPI拡張機能のインポート
- ストリーミングダウンロード
- ストリーミングアップロード
- 受信したデータをチャンク単位で処理する方法
大きなファイルや継続的なデータを扱う場合、リクエスト全体をメモリに読み込まず、チャンク単位で処理できる点が利点です。(Microsoft Learn)
Azure Functions HTTP triggerとは
Azure Functions HTTP triggerは、HTTPリクエストを受信したときに関数を実行する仕組みです。サーバーレスAPI、外部サービスから呼び出すWeb API、Webhookの受信処理などに利用できます。
Functions 2.x以降では、レスポンスを明示的に設定しない場合、空の本文を持つHTTP 204 No Contentが既定の戻り値です。Functions 1.xでは、空のHTTP 200 OKが既定値になります。(Microsoft Learn)
HTTP triggerでは、主に次の項目を設定します。
| 設定 | 役割 |
|---|---|
authLevel | 呼び出し時に必要なアクセスキーのレベル |
methods | GET、POSTなど、受け付けるHTTPメソッド |
route | APIのURLパス |
routePrefix | 既定のapiプレフィックス |
| 入力・出力バインド | StorageやService Busなどとの接続 |
routePrefixはhost.jsonのextensions.http.routePrefixで変更できます。空文字を指定すれば、既定の/apiをURLから削除できます。(Microsoft Learn)
誰に影響するのか
今回の更新による影響は、Azure利用者よりも、Microsoft Learnのサンプルを参照する開発者に限られます。
| 対象者 | 影響 |
|---|---|
| APIやWebサイトの一般利用者 | 直接的な影響なし |
| Function Appの管理者 | 設定変更や再デプロイは原則不要 |
| C#開発者 | 分離ワーカーモデルのコード例を再確認できる |
| Node.js開発者 | v4モデルのルートやバインド例を再確認できる |
| Python開発者 | HTTPストリームの導入例を再確認できる |
| 教材や社内手順書の管理者 | 欠落していたサンプルへの参照を見直す価値がある |
公式コミットの範囲から判断すると、既存のFunction App、HTTPエンドポイント、アクセスキー、ネットワーク設定に対する直接的な影響はありません。(GitHub)
設定で確認すべきポイント
ドキュメント更新への対応は不要ですが、復元されたコードをコピーするときは、次の設定を確認してください。
認証レベルを明示する
HTTP triggerの認証レベルには、主に次の3種類があります。
| 認証レベル | 動作 |
|---|---|
anonymous | アクセスキーなしで呼び出せる |
function | 関数キーまたはホストキーが必要 |
admin | マスターキーが必要 |
特に注意したいのがNode.js v4です。認証レベルを指定しなかった場合、Node.js v4ではanonymousが既定となります。Node.js v3ではfunctionが既定です。
サンプルを本番環境へコピーする際は、authLevel: 'anonymous'のまま公開して問題ないかを必ず確認してください。外部公開が不要な管理APIやバッチ起動用APIでは、functionやMicrosoft Entra IDを利用した認証を検討します。(Microsoft Learn)
ローカルとAzure上の認証差を確認する
通常のローカル実行では、設定した認証レベルにかかわらず、アクセスキーによる認証が無効になります。一方、Azureへ発行するとauthLevelが適用されます。
ローカルで成功したリクエストがAzure上で401や403になる場合は、次を確認してください。
- Function URLに
codeパラメーターが含まれているか x-functions-keyヘッダーを送信しているか- 使用しているキーが対象の関数またはホストに対応しているか
- ネットワークアクセス制限により遮断されていないか
ローカルテストだけで完了とせず、Azure上のステージング環境でも認証を含めて確認することが重要です。(Microsoft Learn)
PythonのHTTPストリームはアプリ単位で判断する
PythonでHTTPストリームを有効化する場合は、少なくとも次の条件を確認します。
- Python v2プログラミングモデルであること
- Azure Functions Runtime 4.34.1以降であること
- サポート対象のPythonバージョンを使用していること
azurefunctions-extensions-http-fastapiを追加していることPYTHON_ENABLE_INIT_INDEXINGを1に設定していること
さらに、HTTPストリームを有効化したFunction Appでは、アプリ内のすべてのHTTP関数をストリーミング対応にする必要があります。ストリーミング関数と通常のHTTP関数を同じアプリ内に混在させる構成はサポートされません。
既存アプリに1つだけストリーミングAPIを追加したい場合は、別のFunction Appに分離する判断も必要です。(Microsoft Learn)
更新や移行は必要か
2026年6月15日のドキュメント更新だけを理由に、SDK、拡張機能、Function Appを更新する必要はありません。
ただし、次の環境は別の理由で更新や移行が必要です。
C#インプロセスモデル
C#インプロセスモデルのサポートは、2026年11月10日に終了します。今回復元されたC#サンプルには分離ワーカーモデルの実装が含まれているため、移行時の参考として利用できます。(Microsoft Learn)
移行では、コードだけでなく、アプリ設定のFUNCTIONS_WORKER_RUNTIMEを次の値に変更します。
dotnet-isolatedコードとランタイム設定が一致しない状態では、Function Appがエラーになる可能性があります。Microsoftは、ステージングスロットで設定変更とデプロイを行い、動作確認後にスロットを入れ替える方法を案内しています。(Microsoft Learn)
Functions Runtime 1.x
Functions Runtime 1.xのサポートは、2026年9月14日に終了する予定です。HTTP triggerのwebHookTypeはRuntime 1.x専用の機能であり、2.x以降では通常のHTTP triggerをWebhook受信に利用する方法が推奨されています。
function.jsonにwebHookTypeが残っている場合は、Runtime 1.xを利用していないか確認し、Functions 4.xへの移行を計画してください。(Microsoft Learn)
料金への影響
2026年6月15日の更新はドキュメント上のコード参照を復元したものであり、料金体系の変更ではありません。そのため、この更新だけで請求額が増減することはありません。
実際の料金は、従来どおり次の要素で決まります。
- 利用しているホスティングプラン
- 実行回数
- 実行時間
- 割り当てメモリ
- 常時起動インスタンス
- ネットワークやストレージなど関連リソースの使用量
HTTPストリームを導入する場合は、処理時間が延びる、メモリ使用量が変わる、クライアントとの接続が長時間維持されるといった可能性があります。機能の有効化自体に新しい専用料金が追加されたという意味ではありませんが、実際のリソース消費はApplication InsightsやAzure Cost Managementで確認してください。(GitHub)
失敗しやすいポイント
サンプルのanonymousをそのまま本番公開する
公式サンプルは、動作を分かりやすくするために匿名アクセスを指定している場合があります。サンプルと同じ設定が、本番環境でも安全とは限りません。
公開前に、誰がエンドポイントを呼び出せるべきかを整理し、アクセスキー、App Service認証、API Management、ネットワーク制限などを組み合わせてください。
異なるプログラミングモデルのコードを混ぜる
同じHTTP triggerでも、Node.js v3とv4、Python v1とv2、C#のインプロセスと分離ワーカーでは記述方法が異なります。
サンプルを利用する前に、次を確認します。
- 利用言語
- プログラミングモデル
- Functions Runtimeのバージョン
- パッケージの名前空間
- Azure上の
FUNCTIONS_WORKER_RUNTIME
コードの一部分だけを置き換えると、ビルドは成功しても関数が検出されないことがあります。
長時間処理を同期HTTPレスポンスで待たせる
HTTP triggerが230秒以内に完了しない場合、Azure Load Balancerがタイムアウトし、クライアントへHTTP 502を返します。関数自体が実行を続けても、元のHTTPリクエストへ結果を返せません。
長時間処理では、処理受付時に202 Acceptedを返し、別のURLから進捗を確認する非同期パターンやDurable Functionsを検討します。(Microsoft Learn)
管理者が今すぐ確認する手順
- Azure Portalで対象のFunction Appを開きます。
- ランタイム、言語、プログラミングモデルを確認します。
- HTTP triggerの
authLevel、methods、routeを確認します。 anonymousの関数が意図せず外部公開されていないか確認します。- C#の場合は、インプロセスモデルか分離ワーカーモデルかを確認します。
- Functions Runtime 1.xや
webHookTypeを利用していないか確認します。 - Python HTTPストリームを使う場合は、同じアプリ内の全HTTP関数を確認します。
- ローカルだけでなく、Azure上で認証、ルート、レスポンス、タイムアウトをテストします。
2026年6月15日の変更に対する緊急作業はありません。まずは不要な再デプロイを避け、現在利用しているランタイムとプログラミングモデルを棚卸ししてください。C#インプロセスモデルやFunctions Runtime 1.xが見つかった場合は、今回のドキュメント更新とは切り分けたうえで、サポート期限までの移行計画を作成することが次の行動になります。
コメント