お世話になっております。App Service サポート担当の仲野です。いつも Azure Functions（関数アプリ）をご利用いただき誠にありがとうございます。

本記事は Potential breaking change for older versions (October 2025) にてアナウンスされた内容の日本語抄訳です。最新情報につきましてはリンク先の Github の Issue をご確認ください。

2025 年 10 月に Azure Functions のプラットフォームのアップデートが予定されています。それに伴い、マイナー ランタイム バージョンに固定されている Azure Functions が正常に動作しなくなる潜在リスクがあります。

以下に当該アップデートにより潜在的なリスクが存在するバージョンと対策について解説します。

影響を受ける可能性のあるバージョン情報と対応内容

プラットフォームのアップデートに伴い、特定のセキュリティ機能がない古いランタイム バージョンで動作する Azure Functions に影響を及ぼす可能性があります。現時点ではプラットフォームの変更は、2025年10月28日に有効になる見込みです。そのため当該アップデート以前に Azure Functions のランタイムの更新をすることを推奨します。

下記の表に示すランタイム バージョンで動作している Azure Functions につきましては、直ちに対策をご検討ください。

影響を受ける可能性があるランタイム バージョンで動作する Azure Functions をご利用中の場合、メールによる通知がされ、App Service Advisor で新たな推奨事項が作成されます。Azure ポータルの「診断と問題の解決」ビューで推奨事項を確認できます。

重要事項

前述の表に記載したバージョン範囲は、今回の変更のためにフラグが立てられたものですが、記載されたランタイム バージョンを「最低限必要なバージョン」と解釈しないようご注意ください。他にもセキュリティ修正が後のバージョンに含まれています。古いバージョンに固定されている Azure Functions は必ず更新すべきであり、1.0.20776.0、3.20.0.0、4.24.0.0 に移行しても十分ではありません。これらの範囲は、影響を受ける可能性のある Azure Functions を特定するための目安となります。

ランタイム バージョンにつきましては、原則マイナー バージョンに固定せず、メジャー バージョンのみを指定し、最新バージョンへ移行するよう努めてください。

対策方法

常に最新バージョンで動作させる方法

Azure Functions が古いバージョンで動作している主な理由は、カスタム コンテナー イメージの基本レイヤーが更新されていないことが多いです。

カスタム コンテナー イメージを最新の 4.x ランタイムで動作させるには、以下の表にある適切な 基本イメージ タグ をプルし、カスタム イメージを定期的にリビルドして、新しいバージョンを使用してください。

詳細は カスタム コンテナーのメンテナンス を参照してください。

また、Azure Functions の設定で古いバージョンに固定している場合もあります。
4.x ランタイムの最新バージョンを対象とするには、アプリ設定FUNCTIONS_EXTENSION_VERSION の値を ~4 と設定してください。

詳細は Azure Functions ランタイム バージョンをターゲットにする方法 を参照してください。

2025 年 07 月 31 日時点の内容となります。

本記事の内容は予告なく変更される場合がございますので予めご了承ください。

お世話になっております。App Service サポート担当の山村です。いつも Azure Functions（関数アプリ）をご利用いただき誠にありがとうございます。

Azure Functions を使用してサーバーレスアプリケーションを開発・運用する際、アプリケーションや実行状況のログ監視は非常に重要です。
Azure Functions では Application Insights と統合することでこれらの監視が可能です。

本ブログでは、Azure Functions の .NET Isolated (分離ワーカー) モデルにおいて Language Worker → Application Insights のログ送信パイプラインをご利用いただいている場合に、Application Insights への 依存関係（Dependency）ログの送信について、特定の type (HTTP etc) や target (www.microsoft.com etc) 毎に制御する方法を解説します。

本ブログに記載の内容は、Dependency に関するログ保存のコストを抑えたいというユースケースでご利用いただけます。
Dependency ログの type (HTTP etc) や target (www.microsoft.com etc) 属性の値をもとに Dependency ログの保存有無を制御したい場合に、本内容が有効となります。

Azure Functions のアーキテクチャ概略

Azure Functions では、Functions Host と呼ばれるプロセスと、Language Worker と呼ばれるプロセスが動作しています。

Functions Host は、HTTP トリガーや Blob トリガーなどのイベント検知や各種ログの記録といった共通処理を担い、Azure Functions のランタイムとして動作する Language Worker へ処理を要求します。 
Language Worker は各言語に応じた関数コードを実行するプロセスであり、お客様のアプリケーションコードが実行されます。
Azure Functions のアーキテクチャの詳細は、こちらのブログをご参照ください。

Application Insights へのログ送信フロー

Azure Functions .NET Isolated を Application Insights と統合している場合には、Language Worker が Application Insights へログを送信するパイプラインは以下の二通りがあります。

1. Language Worker → Functions Host → Application Insights
   
2. Language Worker → Application Insights

詳細については、こちらのブログをご参照ください。

なお、2) の場合は、Language Worker が出力するログについては、Functions Host を経由しないため host.json の Application Insights の設定は効果がありません。
Language Worker が出力するログに関する Application Insights の設定は、スタートアップ構成の Program.cs 内で実装する必要があります。

本題: Language Worker → Application Insights ログ送信パイプラインの場合の Dependency ログの送信について、特定の type や target 毎に制御する方法

実装例

スタートアップ構成の Program.cs 側で ITelemetryProcessor を用いて制御します。

まずは、外部エンドポイントに HTTP リクエストを実施するアプリケーションコード例を示します。

HTTP トリガー関数の実装例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

using Microsoft.AspNetCore.Http;  
using Microsoft.AspNetCore.Mvc;  
using Microsoft.Azure.Functions.Worker;  
using Microsoft.Extensions.Logging;
using Microsoft.Azure.Functions.Worker.Http; //追加
namespace Company.Function;
  
public class HttpTrigger1  
{  
   private readonly ILogger<HttpTrigger1> _logger;  
   private static readonly HttpClient httpClient = new HttpClient();
   public HttpTrigger1(ILogger<HttpTrigger1> logger)  
   {  
       _logger = logger;  
   }
   [Function("HttpTrigger1")]  
   public async Task<HttpResponseData> Run([HttpTrigger(AuthorizationLevel.Anonymous, "get", "post")] HttpRequestData req)  
   {  
       _logger.LogInformation("C# HTTP trigger function processed a request starting...");  
       var response = await httpClient.GetAsync("https://www.microsoft.com");  
       _logger.LogInformation(response.StatusCode.ToString());
       var res = req.CreateResponse(response.IsSuccessStatusCode  
           ? System.Net.HttpStatusCode.OK  
           : System.Net.HttpStatusCode.BadGateway);
       await res.WriteStringAsync($"Status: {response.StatusCode}");  
       return res;  
   }  
}  

次に、ビルダー構成時に AddApplicationInsightsTelemetryProcessor を用いて、Telemetry データのフィルタリングと加工処理を適用します。

Program.cs

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

using Microsoft.Azure.Functions.Worker;  
using Microsoft.Azure.Functions.Worker.Builder;  
using Microsoft.Extensions.DependencyInjection;  
using Microsoft.Extensions.Hosting;  
using Microsoft.Extensions.Logging;
using IsolatedApplicationInsightsCustomTelemetryProcessor;
var builder = FunctionsApplication.CreateBuilder(args);

builder.Services  
   .AddApplicationInsightsTelemetryWorkerService()  
   .ConfigureFunctionsApplicationInsights()  
   .AddApplicationInsightsTelemetryProcessor<CustomTelemetryProcessor>();
  
builder.Logging.Services.Configure<LoggerFilterOptions>(options =>  
{  
   LoggerFilterRule toRemove = options.Rules.FirstOrDefault(rule =>  
       rule.ProviderName == "Microsoft.Extensions.Logging.ApplicationInsights.ApplicationInsightsLoggerProvider");
   if (toRemove is not null)  
   {  
       options.Rules.Remove(toRemove);  
   }  
});  
  
builder.Build().Run();  

ITelemetryProcessor で具体的なフィルタリング処理を追加します。

※ CustomTelemetryProcessor.cs を新しいファイルとして作成し、Program.cs にインポートするような実装としています。

CustomTelemetryProcessor.cs

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

namespace IsolatedApplicationInsightsCustomTelemetryProcessor  
{  
   using Microsoft.ApplicationInsights.Channel;  
   using Microsoft.ApplicationInsights.DataContracts;  
   using Microsoft.ApplicationInsights.Extensibility;
   public class CustomTelemetryProcessor : ITelemetryProcessor  
   {  
       private ITelemetryProcessor Next { get; set; }
       public CustomTelemetryProcessor(ITelemetryProcessor next)  
       {  
           this.Next = next;  
       }
       public void Process(ITelemetry telemetry)  
       {  
           // if (telemetry is DependencyTelemetry dependency && dependency.Target == "www.microsoft.com") // target URL or service name etc.  
           // if (telemetry is DependencyTelemetry dependency && dependency.Type == "Http") // "Http", "InProc" etc.  
           if (telemetry is DependencyTelemetry dependency) // Don't send all dependencies telemetry  
           {  
               Console.WriteLine($"target: {dependency.Target}");  
               Console.WriteLine($"type: {dependency.Type}");  
               return;  
           }  
           this.Next.Process(telemetry);  
       }  
   }  
}

具体的なフィルタリング例

上記までのアプリケーションコードを Azure Functions にデプロイします。

また、実行した際の Application Insights のログに対して、下記 KQL クエリで Dependency のログが記録されているかを確認します。

1
2
3
4
5

union requests, traces, dependencies, exceptions
| where timestamp > ago(30d)
| where operation_Id == '<対象の実行の operation id を入力>' or customDimensions['InvocationId'] == '<対象の実行の invocation id を入力>'
| order by timestamp asc
| project-reorder timestamp, itemType, target, type, sdkVersion, message

1. すべての Dependency ログを送信する場合

Program.cs で AddApplicationInsightsTelemetryProcessor を利用しなければ、すべての Dependency のログが送信されます。

2. すべての Dependency ログを送信しない場合

ITelemetryProcessor で if (telemetry is DependencyTelemetry dependency) とします。

下記のように Dependency のログは記録されません。

3. 特定の target のみを送信しない場合

ITelemetryProcessor で if (telemetry is DependencyTelemetry dependency && dependency.Target == "www.microsoft.com") とします。

下記のように Dependency のログのうち “www.microsoft.com“ を target とするログは記録されません。

ITelemetryProcessor で if (telemetry is DependencyTelemetry dependency && dependency.Target == "") とします。

※ Application Insights 側に送信されると target が Invoke となっているように見えますが、ローカルでは null なので null でフィルタリングします。

下記のように Dependency ログのうち “Invoke” を target とするログは記録されません。

4. 特定の type のみを送信しない場合

ITelemetryProcessor で if (telemetry is DependencyTelemetry dependency && dependency.Type == "Http") とします。

下記のように Dependency ログのうち “Http” を type とするログは記録されません。

ITelemetryProcessor で if (telemetry is DependencyTelemetry dependency && dependency.Type == "InProc") とします。

下記のように Dependency ログのうち “InProc” を type とするログは記録されません。

最後に

上記の通り、ITelemetryProcessor を用いてフィルタリングを追加することで、特定の target や type のみを Application Insights に送信しないことを実現可能ですが、本番や運用環境でお試しいただく前に、検証環境でお客様想定通りとなるかを確認してご利用いただくようにお願いいたします。
また、Application Insights にログを送信しないと、問題発生時のトラブルシューティングが難しくなる場合もございますので、どのログをフィルタリングするかは要検討いただく必要がございます。

参考リンク

• Application Insights SDK におけるフィルター処理および前処理

2025 年 07 月 16 日時点の内容となります。

本記事の内容は予告なく変更される場合がございますので予めご了承ください。

AI Search インデックスを作成する際に、選択したアナライザーでドキュメントがどのようにトークナイズされるのかを確認する方法、および正規表現を使用したクエリで検索を行う際の注意点について例を交えて解説します。

以下のように日本語ドキュメントをクエリで検索したいが、フィルターがうまくかからず期待された結果が返ってこない、なぜですか？

※フィールドにはデフォルトの standard.lucene アナライザーを使用しています。

1

"filter": "not search.ismatch('/.* 階層 .*/','field_1,field_2','full','any')"

回答

まず、上記のクエリは正規表現を使用しており、フィールド “field_1” と “field_2” に “階層” を含むドキュメントを検索するといった動作となります。

Lucene クエリ構文 - Azure AI Search | Microsoft Learn

ドキュメントをインデックスに保存された際のトークナイズ動作については、ドキュメントをインデックスに保存した時点で、各フィールドに設定されたアナライザーによってトークナイズされてから保存されます。

たとえば、”階層関係” というドキュメントをそれぞれ、standard.lucene アナライザーのフィールドと、ja.lucene アナライザーのフィールドに保存された場合、

異なる方法でトークナイズされます。

具体的にドキュメントは異なるアナライザーによってどのようにトークナイズされるかを確認するには、以下の REST API をご使用ください。

Indexes - Analyze - REST API (Azure Search Service) | Microsoft Learn

ここで上記の REST API を使用して “階層関係” はどのようにトークナイズされたかを見てみましょう。

standard.lucene アナライザー

上記の結果から分かるように、standard.lucene アナライザーは日本語の語彙を考えずに単純な一つ一つの文字（Unicodeでエンコードされた表示）にトークナイズされました。

では、ja.lucene はどうでしょうか

上記の結果から、ja.lucene アナライザーは日本語の語彙を考え、”階層” と “関係” でトークナイズしました。

ここで先にクエリで正規表現を使用する場合と使用しない場合のトークナイズの動作の違いについて説明します。

1. クエリで正規表現を使用しない場合、検索語句（ここでは “階層”）はフィールドに設定されているアナライザーによってトークナイズされてから、トークン単位で一致するものはないか検索し、一致するものがあったら、そのドキュメントを結果に返します。

2. クエリで正規表現を使用する場合、検索語句はアナライザーによってトークナイズされず、そのままで検索にかけます。
   
   部分的な語句、パターン、特殊文字 - Azure AI Search | Microsoft Learn

1

正規表現、ワイルドカード、あいまい検索の場合は、クエリ時にアナライザーは使用されません。 演算子と区切り記号の存在を基にパーサーによって検出されるこれらのクエリ フォームの場合、クエリ文字列は字句解析なしでエンジンに渡されます。 これらのクエリ フォームでは、フィールドに指定されたアナライザーは無視されます。

そのため、上記に説明した動作から分かるように、standrard.lucene アナライザーは “階層” を “階” と “層” でトークナイズし、正規表現はアナライザーを適用しないので、

“階層” で検索しても、”階” と “層” はどちらでも一致しないことが分かります。

この場合は、日本語アナライザー ja.lucene、もしくは ja.microsoft を使用する必要があります。

それでは、もう一つの例を見てみましょう

質問

フィールドに日本語アナライザー ja.microsoft を設定したのに、以下のクエリで検索したら、”階層関係” が含まれているものが取れてしまいます。なぜでしょうか。

1

'filter' : 'not search.ismatch'/.* 階層関係 .*/','field_1,field_2','full','any''

回答

さきほどの説明から、正規表現を使用するときは検索語句がトークナイズされずそのまま検索にかける、”階層関係” は日本語アナライザーによって、”階層” と “関係” にトークナイズされることがわかります。

そのため、”階層関係” と一致するものはなく、全件返ってくる動作も理解できます。

さて、この状況では期待された動作にするためには、どうすればいいでしょうか。

今の状況から、正規表現の部分はトークナイズされず検索されているため、ドキュメントにある “階層関係” の部分もトークナイズされなかったら、正規表現と一致するようになることが分かります。

そのため、別のアナライザーで “階層関係” を分割しないものがあればよいわけです。

その要件に合致するのは Keyword アナライザーとなります。

KeywordAnalyzer (Lucene 6.6.1 API)

Keyword アナライザーはドキュメントを分割せずにそのまあ一つのトークンとして保存します。これを使用すれば正規表現を使用して検索するときも期待された結果になります。

ただし、Keyword アナライザーを使用することで、逆に正規表現を使用しないクエリで検索すると、トークナイズされた検索語句で分割されていないトークンと一致しなくなるため、使用の場面を考慮してどのアナライザーを使用するかを検討する必要があります。

※また、正規表現のクエリや正規表現は特にコストがかかります。 高度な検索には非常に便利ですが、正規表現が複雑な場合や大量のデータを検索する場合は特に、実行に多くの処理能力が必要になる場合があります。 これらの要因に寄って、検索待ち時間が長くなる可能性があります。 軽減策として、正規表現を簡略化するか、複雑なクエリをより小さく管理しやすいクエリに分割してみてください。

パフォーマンスに関するヒント - Azure AI Search | Microsoft Learn

今回は、Azureサービスをバックアップする、IaC観点でサービスを管理する際のベストプライスを紹介します。

Azure リソースの設定のバックアップを取る方法がありますか？

障害等で Azure リソース自体のリストア方法があるか？

回答

Azure リソースのバックアップを考える際に、Azure リソースの設定自体をバックアップするのか、それとも Azure リソースに保存されているデータのバックアップをするのかを分けて考える必要があります。

データのバックアップの場合は、ローカルで保存するなどではなく、サービスのパックアップ機能を使用します。

例：

ストレージアカウントのデータバックアップには、冗長性を構成することで、保存機器レベル、またはデータセンターレベルの障害、災害からデータを保護できます。

Azure ストレージのディザスター リカバリー計画とフェールオーバー - Azure Storage | Microsoft Learn

リソース設定情報のバックアップの場合、ARM テンプレート、または Bicep テンプレート、Terrform テンプレートを活用するのが有効です。

こちらのテンプレートを管理し、使用してリソースの管理、あるいは更新をしていくことが IaC の考え方となります。

Azure のリソースの ARM テンプレート、 Bicep テンプレート、Terrform テンプレートのスキーマは以下の公式ドキュメントにあります。

Azure resource reference - Bicep, ARM template & Terraform AzAPI reference | Microsoft Learn

既存リソースの設定情報をバックアップするには、先にリソースの 「テンプレートのエクスポート」 より ARM テンプレートを出力します。

※以前は ARM テンプレートの出力のみサポートされていましたが、最近 Bicep、Terrform テンプレートの出力もサポートされるようになりました

ただし、テンプレートのエクスポートはすべてのコンポーネントをエクスポートできなかったり、エクスポートされた情報に欠落がある場合があるため、テンプレートエクスポートする場合はチェックが必要となります。

上記のテンプレートスキーマを参照しながらチェックする必要があるため、リソースの機能などについて一定程度の理解が必要となります。

エクスポートされたテンプレートには、人によるチェックや修正が必要であることについて、公式ドキュメントにも以下のような注意書きがあります。

Azure portal でテンプレートをエクスポートする - Azure Resource Manager | Microsoft Learn

ARM テンプレートとしてエクスポートした場合、以下の方法で手動で Bicep テンプレートに変換することも可能です。

ただし、Bicep への逆コンパイルはベストエフォートでのサポートとなり、逆コンパイルは情報が欠落したり、失敗したりする場合があるため、チェックが必要です。

JSON Azure Resource Manager テンプレートを Bicep に逆コンパイルする - Azure Resource Manager | Microsoft Learn

単純なバックアップであれば、テンプレートのエクスポート、チェックを行えば、バックアップ完了となり、リソースのリストアは Azure PowerShell コマンドなどでテンプレートを使用してリソースをデプロイできます。

New-AzResourceGroupDeployment (Az.Resources) | Microsoft Learn

IaC としてリソースのデプロイなどを管理したい場合は、リソーステンプレートを以下の処理を行います。

1. テンプレートエクスポート
2. テンプレートチェック

ここまでは上記内容で説明しました

3. テンプレートのリファクタリング（モジュール化など）
4. テスト
5. デプロイ

Bicep を使用するために Azure リソースと JSON ARM テンプレートを移行する - Azure Resource Manager | Microsoft Learn

リファクタリング

テンプレートのリファクタリングは、テンプレートの変数などを読みやすく変更したり、コメントを追加してテンプレートの可読性を向上したりすることができます。

また、複数のリソースといった複雑なシステム構成の場合、個々のリソースをモジュール化することで、主テンプレートに集約することが可能で、管理を簡略化できます。

Bicep テンプレートはモジュール、ARM テンプレートはリンクされたテンプレートを使用します。

テスト

更新したテンプレートでリソースをアップデートする場合、動作の検証が必要となってくるため、いきなり本番環境へのデプロイではなく、

あらかじめ用意されたテスト環境へデプロイし、動作の検証をすることを推奨します。

また、実際のデプロイを行わず、デプロイによる変更をプレビューすることも可能ですので、実際にデプロイする前に今回のデプロイで変更された箇所を記録することもいざとなった時に参考となれます。

テンプレート デプロイの what-if - Azure Resource Manager | Microsoft Learn

デプロイ

テンプレートの検証が終わりましたら、実際にデプロイを行います。

デプロイは、コマンドで実行するか、ポータルで実行できますが、ポータルではファイルのアップロードなどが必要となるため、

複数のテンプレートでリソースのデプロイを行う場合は、ローカルでのコマンド実行の方が迅速で、便利となります。

解説

前提

例としてはシンプルにストレージアカウント内に二つの BLOB コンテナー (con1、con2) があり、con1 配下にある BLOB に対してだけ読み書きできる、という前提にします。

回答

こちらは以下の資料が参考になります。

BLOB データにアクセスするための Azure ロールを割り当てる

この資料にあるように結論としては、以下を割り当てます。

• ストレージアカウントレベルでの 閲覧者ロール
• コンテナーレベルでのストレージ BLOB データ共同作成者などのデータ アクセス ロール

それぞれ、ロールの割り当てで探すと以下のように出てきます。

上記の二つのロールを割り当てたユーザーから、Azure ポータルで該当のストレージアカウントを参照した例を以下に示します。
まず、コンテナー自体は両方とも見えます。

そして、con1 についてはストレージ BLOB データ共同作成者のロールがあるため、コンテナー内の BLOB が見えます。また、アップロードや削除等もできます。

一方、con2 については con1 と異なり、コンテナーレベルでBLOB データ共同作成者のロールを割り当てていませんので、コンテナー内の BLOB は見えません。以下のようにエラーが表示されます。

ここまでは、正直なところ先述の資料に書いてある通りなのですが、こちらの方法ですとコンテナーの一覧まではストレージアカウントレベルの閲覧者のロールがあることによって見ることはできます。ロールを割り当てていないコンテナーの中身は見えない状況ですが、コンテナーの一覧も該当のユーザーには見せたくない、という場合にできる方法を紹介します。

他のコンテナーも見せたくない場合に実施できる方法

Azure ポータルを利用すると、どうしてもストレージアカウントのリソースを表示してからコンテナーをたどる、という手順になり、リソースを表示するために必要な閲覧者ロールの割り当てを消すことはできません。そのため、今回は Storage Explorer を利用します。
Azure Storage Explorer は GUI のツールとなり、BLOB の操作などができます。後述の参考ドキュメントのリンクよりダウンロードすることができます。

そして、実際にやることですが、ストレージアカウントレベルの閲覧者の権限は削除をし、以下の権限だけを該当のユーザーに割り当てます。

• コンテナーレベルでのストレージ BLOB データ共同作成者などのデータ アクセス ロール

そして、該当のユーザーを利用して、Storage Explorer を用いて接続する手順を以下に示します。

(1) Storage Explorer から接続するときに、BLOB コンテナーまたはディレクトリ、を選択します。

(2) OAuth  を使用してサインインする、を選択し、利用するユーザーとサインインするテナントを指定

(3) BLOB コンテナーまたはディレクトリの URL の欄に、”https://mystorage0123.blob.core.windows.net/con1” というような URL を指定します。
mystorage0123 の部分はストレージアカウント名、con1 の部分はコンテナー名で書き換えてください。

上記の手順を実施しますと、以下のように対象のコンテナー(今回は con1) の中身だけを表示し、かつ、別のコンテナーの名前が表示される、ということもございません。

閲覧者の権限がないため、接続するストレージアカウント名とコンテナー名は別途該当のユーザーに連携する、という必要がございますが、コンテナーの一覧も見せたくない、というような要件がある場合には、こちらの方法のご利用もご検討いただける内容かと思います。

参考ドキュメント

上記で利用している Azure Storage Explorer は以下からダウンロードができます。

Azure Storage Explorer

2025 年 4 月 15 日時点の内容となります。

本記事の内容は予告なく変更される場合がございますので予めご了承ください。