Application Insights の Logs では KQL が正常に実行できるのに、同じクエリから Azure Monitor のログ アラート（スケジュール済みクエリ アラート）を作ろうとすると「Application name pattern is blocked」で失敗する――。その原因は app() の指定方法と、アラート作成時に行われるスコープ/権限の厳格な検証にあります。本記事では最短の直し方から、再発させない設計のコツまでまとめます。
起きている現象：Logs では動くのにログ アラート作成で失敗する
まず前提として、これは「KQL が間違っている」ケースよりも、アラート作成時の制約に引っかかっているケースがほとんどです。特に、別の Application Insights（以下、App Insights）を参照するために app() を使っていると再現しやすくなります。
代表的なエラーは次のようなものです。
Failed to create alert rule. Application name pattern is blocked. The request had some invalid propertiesそして、Logs 画面では問題なく実行できるのに、アラート作成（「新しいアラート ルール」→「条件」→「カスタム ログ検索」）に進むと失敗する、という流れになります。
よくある再現クエリ例（Logs では成功、アラート作成で失敗）
app("another appInsights").exceptions
| where timestamp > ago(5m)
| summarize Count = count()上の例のように app("名前") で参照している場合、Logs では実行できても、ログ アラート（scheduledQueryRules）作成時に弾かれることがあります。
結論：ログ アラートでは app(“名前”) の「名前／パターン指定」がブロックされる
原因はシンプルで、ログ画面（対話的なクエリ実行）で許可される app("アプリ名") のような参照が、ログ アラート作成時には「名前ベース／パターン（ワイルドカード含む）の指定」がブロックされるためです。結果として、ポータル上では「Application name pattern is blocked」というメッセージで失敗します。
ログ アラートでクロスリソース参照を行う場合は、次の 2 点が事実上の必須条件になります。
app()の引数を、GUID または Azure Resource ID などの「明示的な識別子」にする- 参照先リソースを、アラート ルールのスコープ（または「許可されたリソース」）として明示的に含める
特に 1 点目が今回のエラーの直撃ポイントで、名前やワイルドカードで対象が広がり得る書き方は、アラート側で拒否されやすい設計になっています。
なぜ Logs では通るのか：実行コンテキストと検証タイミングが違う
「Logs で動くのにアラートで動かない」のは、実行する主体と責任範囲が異なるからです。
| 観点 | Application Insights の Logs（対話的） | Azure Monitor ログ アラート（スケジュール済みクエリ） |
|---|---|---|
| 実行者 | 基本的に「今ログ画面を開いているユーザー」 | Azure Monitor がスケジュール実行（アラート ルールとして保存された設定） |
| 検証のタイミング | 実行時に都度評価（保存しないなら厳密な固定は不要） | 作成時点で参照先リソースを検証・固定（スコープ/権限を確定させる） |
| クロスリソース参照 | アクセス権があれば比較的柔軟 | 参照は明示的で、パラメータ化できない（後から参照先を増やすような設計は不可） |
| 運用上の安全性 | ユーザーの権限に依存（実行者が変われば挙動も変わり得る） | 作成時の設定・権限に基づいて安定運用（だからこそ作成時の制約が厳しい） |
Microsoft のドキュメントでも、ログ検索アラートでは作成時点でアクセス検証が行われること、クロスリソース参照は明示的でなければならず、パラメータ化できないことが示されています。
この仕組み上、app("名前") のように「名前解決に依存する」「ワイルドカードで増減し得る」指定は、アラート作成時の検証と相性が悪く、ブロックされる（＝pattern is blocked）と考えると納得しやすいです。
対処手順：王道は「Resource ID で app() を書く」＋「複数リソースをスコープに入れる」
ここからは実際に解決するための手順です。ポイントは、クエリ側とアラート設定側の両方を整えることです。
手順：app(“名前”) を Azure Resource ID 形式へ置き換える
app() の引数は、少なくとも次の形式が推奨されます。特に Azure Resource ID は「どのリソースを指しているか」が明確で、アラート作成時の検証に通しやすくなります。
| 指定方法 | 例 | おすすめ度 | 備考 |
|---|---|---|---|
| GUID（アプリ ID） | app("00000000-0000-0000-0000-000000000000") | ◯ | 「どの App Insights か」が固定される |
| Azure Resource ID | app("/subscriptions/.../providers/microsoft.insights/components/...") | ◎ | アラート作成時の検証と相性が良い |
| 名前（またはパターン） | app("another appInsights") | × | ログ アラート作成時にブロックされやすい |
置き換え例は次のとおりです。
変更前
app("another appInsights").exceptions
| where timestamp > ago(5m)
| summarize Count = count()変更後（Azure Resource ID で明示）
app('/subscriptions/<subId>/resourceGroups/<rg>/providers/microsoft.insights/components/<ai-name>').exceptions
| where timestamp > ago(5m)
| summarize Count = count()Resource ID は、ポータルの App Insights リソースを開き、［プロパティ］→［リソース ID］からコピーするのが手早いです（スペースや大文字小文字を気にせず、コピーした値をそのまま使えます）。
手順：アラート作成時に「複数リソース」をスコープに含める
次に、アラート側で参照先を「対象として許可」します。ポータルで作る場合、イメージとしては「監視対象（Scope）に、参照元と参照先を両方入れる」操作になります。
- Azure portal で Monitor → Alerts → + Create → Alert rule を開く
- Scope（スコープ）で、Application Insights を検索し、参照元の App Insights を選ぶ
- 同じ画面で 「複数のリソース」として、参照先の App Insights も追加して選択する
- Condition（条件）で「Custom log search」を選び、置き換え後の KQL を貼り付ける
- Preview で結果を確認し、必要に応じてウィンドウ（Window size）と頻度（Frequency）を調整して作成する
ここでの注意点として、複数リソースをスコープに入れる運用では、スコープに指定するリソースは「同じ種類」かつ「同じリージョン」である必要がある旨が CLI の仕様として明記されています。ポータルでも同様の制約でつまずくことがあるので、参照元/参照先の App Insights が別リージョンの場合は設計を見直すのがおすすめです。
それでも失敗する場合に見るべきポイント
Resource ID に置き換え、スコープも追加したのに作れない場合は、次の観点で切り分けると原因に到達しやすくなります。
ログ アラートは「権限が固定される」：誰の権限で実行されるかを意識する
ログ検索アラートは、作成後に Azure Monitor が自動実行します。そのため、アラートが参照する全リソースに対して、実行主体が読む権限を持っていることが必須です。
ドキュメントでも、アラート作成に必要な権限（対象リソースの読み取り、アラートを作る RG への書き込み、アクション グループの読み取り）が整理されています。
さらに重要なのが「Identity（ID）」の考え方です。ログ検索アラートは、マネージド ID を使わない場合、最後に編集したユーザー（またはサービス プリンシパル）の権限を引き継いで動くため、チーム運用で編集者が変わると突然動かなくなることがあります。安定運用したい場合は、ユーザーではなくマネージド ID で固定するのが安全です。
「関数でスコーピング」は後から増やせない
複数の App Insights をまとめるために、KQL 関数（function）で union してスコーピングしたくなることがあります。しかしログ検索アラートでは、作成時にアクセス検証が行われる都合上、関数側だけを後から更新して参照先を増やすといった運用はできません。増やす場合は、アラート側のスコープも更新する必要があります。
代替案：app() を避ける設計（ワークスペースに集約してアラートを作る）
クロスリソース参照が増えるほど、アラート作成時の「許可・スコープ管理」が面倒になりがちです。そこで現場でよく採用されるのが、Log Analytics ワークスペースに集約して、workspace() 側でクエリし、ワークスペースに対してログ アラートを作る方法です。
特に workspace-based Application Insights を使っている場合、テレメトリは Log Analytics に保存されるため、そもそも app() より workspace() を使うのが自然です。
ワークスペース集約のメリット/デメリット
| 観点 | app() でクロスリソース参照 | Log Analytics ワークスペース集約 |
|---|---|---|
| アラート作成の通しやすさ | 参照先を増やすほど難易度が上がる（スコープ/権限の明示が必要） | ワークスペース中心に設計でき、スコープ管理が単純になりやすい |
| クエリの見通し | app() が増えると複雑になりやすい | 同一ワークスペースに集まれば union やフィルタで整理しやすい |
| チーム運用 | 参照先追加のたびにアラート設定も更新が必要 | 運用ルール（接続/収集）を整えるとスケールしやすい |
ワークスペース側で例外を監視するクエリ例
AppExceptions
| where TimeGenerated > ago(5m)
| summarize Count = count() by AppRoleNameこの方式なら、アラートのスコープはワークスペース（またはワークスペース配下の対象）に寄せられるため、app() の名前解決や「pattern is blocked」のような制約に遭遇しにくくなります。
複数の App Insights をまとめて監視する KQL の書き方（withsource が便利）
2 つ以上の App Insights をまたいで例外（exceptions）をまとめたい場合、union に withsource を付けて「どのリソース由来のログか」を列として残すと、アラート通知を見たときに原因追跡が一気に楽になります。Microsoft Learn の例でも、union withsource で複数の App Insights を束ね、送信元を列として持たせる方法が紹介されています。
union withsource=SourceApp
app('/subscriptions/<subId>/resourceGroups/<rg>/providers/microsoft.insights/components/<ai-1>').exceptions,
app('/subscriptions/<subId>/resourceGroups/<rg>/providers/microsoft.insights/components/<ai-2>').exceptions
| where timestamp > ago(5m)
| summarize Count = count() by SourceAppただし、クロスリソースを増やしすぎるとクエリが遅くなりやすい点は要注意です。さらに、単一クエリに含められるワークスペース/（クラシック）App Insights の上限もあるため、無制限に増やす前提で設計しないほうが安全です。
クロスサブスクリプション/クロステナントの注意点
サブスクリプションを跨ぐ参照自体は、同一テナント内で権限が揃っていれば実現できることが多いです。一方で、テナントを跨ぐ（クロステナント）参照は、対話的なクエリでは Azure Lighthouse などで実現できる一方、ログ アラートは作成時の検証や実行主体の制約により、うまくいかないケースが出やすくなります。特に今回の「pattern is blocked」を踏んだ環境では、まず同一テナントで完結しているかを確認するのが近道です。
| パターン | 実現しやすさ | ハマりどころ | 実務的な対策 |
|---|---|---|---|
| 同一サブスクリプション内 | 高い | スコープ追加漏れ、app("名前") のまま | Resource ID 化＋複数スコープ |
| 同一テナント内でサブスクリプション跨ぎ | 中〜高 | 参照先にも閲覧権限が必要、管理者が分かれていると調整が大変 | マネージド ID 運用＋RBAC を明確化 |
| テナント跨ぎ（Azure Lighthouse など） | 低〜中 | Logs では見えるのにアラートで失敗しやすい | 可能なら設計をワークスペース集約に寄せる／同一テナントへ統合を検討 |
IaC で再現性を上げる：scheduledQueryRules のスコープをコードに落とす
「ポータルでポチポチ設定すると、誰かの編集で壊れる」「環境ごとに設定が微妙に違う」という場合は、アラート ルール自体を IaC（Bicep/ARM）で管理すると事故が減ります。scheduledQueryRules リソースは properties.scopes に対象リソース ID を配列で持てるため、参照元・参照先を“明示的に固定する”という今回の対処と相性が良いです。
以下は概念を掴むための最小例です（実運用では命名、アクション グループ、しきい値、評価間隔などを環境に合わせて調整してください）。
resource logAlert 'Microsoft.Insights/scheduledQueryRules@2023-12-01' = {
name: 'ai-exceptions-cross'
location: 'japaneast'
kind: 'LogAlert'
properties: {
displayName: 'AI exceptions cross alert'
enabled: true
scopes: [
'/subscriptions/<subId>/resourceGroups/<rg>/providers/microsoft.insights/components/<ai-1>'
'/subscriptions/<subId>/resourceGroups/<rg>/providers/microsoft.insights/components/<ai-2>'
]
evaluationFrequency: 'PT5M'
windowSize: 'PT5M'
severity: 2
criteria: {
allOf: [
{
query: '''
union withsource=SourceApp
app('/subscriptions/<subId>/resourceGroups/<rg>/providers/microsoft.insights/components/<ai-1>').exceptions,
app('/subscriptions/<subId>/resourceGroups/<rg>/providers/microsoft.insights/components/<ai-2>').exceptions
| where timestamp > ago(5m)
| summarize AggregatedValue = count() by SourceApp
'''
timeAggregation: 'Count'
operator: 'GreaterThan'
threshold: 0
failingPeriods: {
numberOfEvaluationPeriods: 1
minFailingPeriodsToAlert: 1
}
}
]
}
actions: {
actionGroups: [
'/subscriptions/<subId>/resourceGroups/<rg>/providers/microsoft.insights/actionGroups/<ag-name>'
]
}
}
}IaC 化しておくと、参照先を追加するときも「KQL の app() 追加」と「scopes の追加」を同じ PR で扱えるため、app() だけ増やしてアラートが落ちる…といった事故を防げます。
ログ アラート作成でつまずきやすい制約（ついでに押さえる）
今回の「Application name pattern is blocked」とは別に、ログ検索アラートにはいくつかのクエリ制約があります。再発防止のために、よく引っかかるものだけまとめます。
| 制約 | よくある症状 | 回避策 |
|---|---|---|
bag_unpack() / pivot() / narrow() が使えない | プレビューはできるのに保存時に失敗する、または評価で失敗する | アラート用のクエリは集計・フィルタ中心に寄せる |
ago() は timespan literal のみ | ago(someVariable) のような書き方でエラー | ago(5m) のように固定で書く |
AggregatedValue は予約語 | 同名の列/別名を使うと失敗 | 列名や別名を変える |
| 設定プロパティの合計サイズは 64KB まで | クエリやカスタム プロパティを盛りすぎると保存できない | クエリは短く、付加情報は必要最小限に |
関数内の now() 等に注意 | 評価結果がブレたり、想定外のタイミングで発火する | 相対時刻はアラート本体の KQL に書き、関数にはパラメータで渡す |
上記はログ検索アラートの公式ドキュメントに記載されている代表的な注意点です。
まとめ：pattern is blocked を最短で解消する要点
- Logs で動く
app("名前")が、ログ アラート作成時にブロックされることがある app()は Azure Resource ID（または GUID）で明示し、名前/パターン指定は避ける- 参照元・参照先の両方をスコープに含めて「許可」する（複数リソース）
- 権限と実行主体（Identity）を固定し、運用で壊れない構成にする
- 規模が大きいなら、Log Analytics ワークスペース集約で
app()依存を減らす
この流れで作り直すと、「Application name pattern is blocked」系の詰まりはほぼ解消できます。
コメント