Azure Monitor で検索ジョブを実行する

検索ジョブは、Log Analytics 内のデータ ( 分析と長期リテンション期間 の両方) で実行する非同期クエリです。これにより、ワークスペース内の新しい検索テーブルの対話型クエリでクエリ結果を使用できるようになります。 検索ジョブでは、並列処理が使用され、大規模なデータセット全体に対して数時間実行できます。 この記事では、検索ジョブを作成する方法と、結果のデータを照会する方法について説明します。

このビデオでは、検索ジョブを使うべきときと、その方法について説明します。

必要なアクセス許可

アクション	必要なアクセス許可
検索ジョブの実行	たとえば、Microsoft.OperationalInsights/workspaces/tables/writeによって提供される、Log Analytics ワークスペースに対する Microsoft.OperationalInsights/workspaces/searchJobs/write および 権限。

注

テナント間検索ジョブはサポートされていません。 Azure Lighthouse の委任されたアクセスは、searchJobs/write アクセス許可を含む委任されたロールが割り当てられている場合でも、検索ジョブ (または復元) ではサポートされていません。

検索ジョブを使用する場面

検索ジョブは以下のために使います。

• 長期的なリテンション期間から、および基本ログまたは補助ログを含むテーブルから、Azure Monitor ログの完全な分析機能をサポートする新しい分析ログ テーブルにレコードを取得します。
• ログ クエリのタイムアウトが 10 分で十分でない場合は、大量のデータをスキャンします。

検索ジョブの機能

検索ジョブはデータをスキャンし、その結果をソース データと同じワークスペース内の新しいテーブルに送信します。 検索ジョブが開始されるとすぐに結果テーブルが使用可能になりますが、結果が表示され始めるまでに時間がかかる場合があります。 スキャンされたデータの 価格モデル と、取り込まれた結果のサイズに基づいてコストが発生します。 検索ジョブを実行する前に、ジョブを実行するかどうかを決定するのに役立つコスト見積もりを使用できます。

検索ジョブの結果テーブルは、クエリをログに記録したり、ワークスペース内のテーブルを使用する他のAzure Monitor機能に使用できる Analytics ログ テーブルです。 テーブルはワークスペースに設定された 保持値 を継承します。この値は、テーブルの作成後も編集可能なままになります。

検索結果テーブルのスキーマは、ソース テーブルのスキーマと指定されたクエリに基づいています。 次のその他の列は、ソース レコードの追跡に役立ちます。

列	値
_OriginalType	ソース テーブルの Type 値。
_OriginalItemId	ソース テーブルの _ItemID 値。
_OriginalTimeGenerated	ソース テーブルの TimeGenerated 値。
タイムジェネレイテッド	検索ジョブが実行された時刻。

結果テーブルに対するクエリは、最初の検索ジョブではなく、ログ クエリの監査に表示されます。

検索ジョブの実行

検索ジョブを実行して、大規模なデータセットからワークスペース内の新しい検索結果テーブルにレコードをフェッチします。

ヒント

検索ジョブの実行に対しては、料金が発生します。 検索ジョブを実行する前に、対話型クエリ モードでクエリを記述して最適化します。 コスト見積もりプレビューを使用して、潜在的なコストを把握します。

ポータル

検索ジョブを実行するには、Azure portal で次のようにします。

1. [Log Analytics ワークスペース] メニューから [ログ] を選びます。

2. 検索ジョブ クエリを入力するか、目的のテーブルを選択します。

3. 画面の右側にある省略記号メニューを選択し、[ 検索ジョブ] を選択します。

   

4. または、[ 実行 ] プルダウン メニューを使用して、[ 検索ジョブとして実行] を選択します。

   

5. 時刻の選択を使用して、検索ジョブの日付範囲を指定します。 合計保有期間内の任意の期間を選択します。

   Kusto クエリで時間範囲も指定されている場合は、時間範囲の和集合が検索ジョブに使用されます。

   

6. 検索ジョブ結果テーブルの名前を入力し、[Run a search job] (検索ジョブの実行) を選びます。

   Azure Monitor ログで検索ジョブが実行され、ワークスペースに検索ジョブ結果用の新しいテーブルが作成されます。

7. 新しいテーブルの準備ができたら、'<searchtablename>_SRCH' を選択して Log Analytics でテーブルを表示します。

   新しく作成された検索ジョブ結果テーブルに挿入が開始されると、検索ジョブ結果を使用できます。

   

   Azure Monitor ログには、完了時に 検索ジョブが完了 したことを示すメッセージが表示されます。 そのメッセージが表示されるか、進行状況に 100%が表示されると、検索クエリに一致するすべてのレコードで結果テーブルの準備が整いました。

Azure CLI

次の Azure CLI の例では、az monitor log-analytics workspace table search-job create コマンドを使用します。 検索ジョブを実行して、Log Analyticsワークスペースの検索結果テーブルを作成します。 --name パラメーターを使用して設定した結果テーブルの名前は、_SRCHで終わる必要があります。

# Set variables
resourceGroupName="<ResourceGroupName>"
workspaceName="<WorkspaceName>"
tableName="<TableName>_SRCH"
searchQuery='Heartbeat | where ComputerIP has "198.51.100.101"'
limit="1500"
startSearchTime="2026-01-01T00:00:00.000Z"
endSearchTime="2026-01-08T00:00:00.000Z"

# Create the Log Analytics workspace search results table
az monitor log-analytics workspace table search-job create \
  --resource-group "$resourceGroupName" \
  --workspace-name "$workspaceName" \
  --name "$tableName" \
  --search-query "$searchQuery" \
  --limit "$limit" \
  --start-search-time "$startSearchTime" \
  --end-search-time "$endSearchTime" \
  --no-wait

注

Azure CLIコマンドは現在の CLI コンテキストからAzure Resource Manager エンドポイントを使用するため、コマンド構文で management.azure.com を指定する必要はありません。

Azure PowerShell

次のAzure PowerShell例では、New-AzOperationalInsightsSearchTable コマンドレットを使用します。 検索ジョブを実行して、Log Analyticsワークスペースの検索結果テーブルを作成します。 -TableName パラメーターを使用して設定した結果テーブルの名前は、_SRCHで終わる必要があります。

# Set variables
$resourceGroupName = "<ResourceGroupName>"
$workspaceName = "<WorkspaceName>"
$tableName = "<TableName>_SRCH"
$searchQuery = 'Heartbeat | where ComputerIP has "198.51.100.101"'
$limit = 1500
$startSearchTime = "2026-01-01T00:00:00.000Z"
$endSearchTime = "2026-01-08T00:00:00.000Z"

# Define parameters for New-AzOperationalInsightsSearchTable
$newAzOperationalInsightsSearchTableParams = @{
    ResourceGroupName = $resourceGroupName
    WorkspaceName     = $workspaceName
    TableName         = $tableName
    SearchQuery       = $searchQuery
    Limit             = $limit
    StartSearchTime   = $startSearchTime
    EndSearchTime     = $endSearchTime
}

# Create the Log Analytics workspace search results table
New-AzOperationalInsightsSearchTable @newAzOperationalInsightsSearchTableParams

注

Azure PowerShellコマンドレットは現在の Az コンテキストからAzure Resource Manager エンドポイントを使用するため、コマンドレット構文で management.azure.com を指定する必要はありません。

REST

次の REST の例では、 テーブル - REST API の作成または更新 操作を使用します。 検索ジョブを実行して、Log Analyticsワークスペースの検索結果テーブルを作成します。 結果テーブルの名前は、 _SRCHで終わる必要があります。

要求の本文には次の値を含めます。

名前	タイプ	説明
properties.searchResults.query	文字列	KQL で記述されたデータ取得のためのログ クエリ。
properties.searchResults.limit	整数	結果セット内のレコードの最大数(最大 1 億レコード)。 (省略可能)
properties.searchResults.startSearchTime	文字列	検索する時間範囲の始まり。
properties.searchResults.endSearchTime	文字列	検索する時間範囲の終わり。

要求のサンプル

次の使用例は、 Heartbeat テーブルで特定のコンピューター IP を持つレコードを検索する検索ジョブを実行して、検索結果テーブルを作成します。

PUT https://management.azure.com/subscriptions/{SubscriptionId}/resourceGroups/{ResourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{WorkspaceName}/tables/{TableName}_SRCH?api-version={apiVersion}
Authorization: Bearer {AccessToken}
Content-Type: application/json

{
  "properties": {
    "searchResults": {
      "query": "Heartbeat | where ComputerIP has \"198.51.100.101\"",
      "limit": 1500,
      "startSearchTime": "2026-01-01T00:00:00.000Z",
      "endSearchTime": "2026-01-08T00:00:00.000Z"
    }
  }
}

応答

状態コード: 202 Accepted。

検索ジョブの状態と詳細を取得する

ポータル

1. [Log Analytics ワークスペース] メニューから [ログ] を選びます。

2. [テーブル>検索結果] で、検索結果テーブルの上にカーソルを合わせると、進行状況が表示されます。

   検索ジョブの結果テーブルのアイコンには、検索ジョブが完了するまで更新インジケーター アイコンが表示されます。

   

Azure CLI

次のAzure CLI例では、az monitor log-analytics workspace table show コマンドを使用します。 検索ジョブ テーブルの状態と詳細を取得します。

# Set variables
resourceGroupName="<ResourceGroupName>"
workspaceName="<WorkspaceName>"
tableName="<TableName>_SRCH"

# Get the status and details of the search job table
az monitor log-analytics workspace table show \
  --resource-group "$resourceGroupName" \
  --workspace-name "$workspaceName" \
  --name "$tableName" \
  --output table

注

Azure CLIコマンドは現在の CLI コンテキストからAzure Resource Manager エンドポイントを使用するため、コマンド構文で management.azure.com を指定する必要はありません。

Azure PowerShell

次のAzure PowerShell例では、Get-AzOperationalInsightsTable コマンドレットを使用します。 検索ジョブ テーブルの状態と詳細を取得します。

# Set variables
$resourceGroupName = "<ResourceGroupName>"
$workspaceName = "<WorkspaceName>"
$tableName = "<TableName>_SRCH"

# Define parameters for Get-AzOperationalInsightsTable
$getAzOperationalInsightsTableParams = @{
    ResourceGroupName = $resourceGroupName
    WorkspaceName     = $workspaceName
    TableName         = $tableName
}

# Get the status and details of the search job table
Get-AzOperationalInsightsTable @getAzOperationalInsightsTableParams

-TableNameを指定しない場合、コマンドレットはワークスペースに関連付けられているすべてのテーブルを一覧表示します。

注

Azure PowerShellコマンドレットは現在の Az コンテキストからAzure Resource Manager エンドポイントを使用するため、コマンドレット構文で management.azure.com を指定する必要はありません。

REST

次の REST の例では、 Tables - Get REST API 操作を使用します。 検索ジョブ テーブルの状態と詳細を取得します。

ジョブ テーブルの状態を検索する

provisioningState プロパティは、検索ジョブの現在の状態を示します。 この API は、検索ジョブを開始するときにこのプロパティを返し、後でテーブルに対する GET 操作を使用してこのプロパティを取得します。 provisioningState プロパティには、次のいずれかの値があります。

値	説明
更新中	テーブルとそのスキーマを事前設定しています。
進行中	検索ジョブが実行中で、データをフェッチしています。
成功	検索ジョブが完了しました。
削除中	検索ジョブのテーブルを削除しています。

要求のサンプル

この例では、前の例の検索ジョブのテーブルの状態を取得します。

GET https://management.azure.com/subscriptions/{SubscriptionId}/resourceGroups/{ResourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{WorkspaceName}/tables/{TableName}_SRCH?api-version={apiVersion}
Authorization: Bearer {AccessToken}

応答

検索ジョブ テーブルの状態の応答

{
  "properties": {
    "retentionInDays": 30,
    "totalRetentionInDays": 30,
    "archiveRetentionInDays": 0,
    "plan": "Analytics",
    "lastPlanModifiedDate": "Thu, 08 Jan 2026 00:00:00 GMT",
    "schema": {
      "name": "HeartbeatByIp_SRCH",
      "tableType": "SearchResults",
      "description": "This table was created using a Search Job with the following query: 'Heartbeat | where ComputerIP has \"198.51.100.101\"'.",
      "columns": [],
      "standardColumns": [],
      "solutions": [
        "LogManagement"
      ],
      "searchResults": {
        "query": "Heartbeat | where ComputerIP has \"198.51.100.101\"",
        "limit": 1500,
        "startSearchTime": "Thu, 01 Jan 2026 00:00:00 GMT",
        "endSearchTime": "Thu, 08 Jan 2026 00:00:00 GMT",
        "sourceTable": "Heartbeat"
      }
    },
    "provisioningState": "Succeeded"
  },
  "id": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/ContosoRG/providers/Microsoft.OperationalInsights/workspaces/ContosoWorkspace/tables/HeartbeatByIp_SRCH",
  "name": "HeartbeatByIp_SRCH"
}

検索ジョブのテーブルを削除する

テーブルの クエリが完了したら、検索ジョブ テーブルを削除します。 このベスト プラクティスにより、ワークスペースの煩雑さとデータ保持に対する追加料金が削減されます。

考慮事項

検索ジョブには、次の考慮事項が適用されます。

• 一度に 1 つのテーブルに対してクエリを実行するように最適化
• 検索の日付範囲は、合計保有期間内の任意の期間です
• 最長 24 時間のタイムアウトまで実行時間の長い検索をサポート
• レコード セット内の結果は 1 億件に制限されます。制限を超えた場合、Azure Monitor は 部分的な成功の状態でジョブを中止し、テーブルにはその時点まで取り込まれたレコードのみが含まれます
• 同時実行は、ワークスペースごとに 10 個の検索ジョブに制限されます。
• ワークスペースあたり 200 個の検索結果テーブルに制限
• ワークスペースあたり 1 日あたり 200 件の検索ジョブの実行に制限
• テナント間検索ジョブはサポートされていません
• 委任に適切な searchJobs/write アクセス許可が含まれている場合でも、Azure Lighthouse の委任されたアクセスは検索ジョブでサポートされていません。エラー メッセージで失敗します。
  ユーザー managing-tenant-userId< には、スコープ >delegated-workspace-resourceID におけるアクション Microsoft.OperationalInsights/workspaces/searchJobs/write へのアクセス権がありません。<>

KQL クエリに関する考慮事項

検索ジョブは、特定のテーブル内の大量のデータをスキャンするため、検索ジョブ クエリは常にテーブル名で開始する必要があります。 分散とセグメント化による非同期実行を有効にするために、クエリでは、次の表形式演算子を含む KQL のサブセットがサポートされます。

• where
• extend
• project
• project-away
• project-keep
• project-rename
• project-reorder
• parse
• parse-where

これらの演算子内のすべての関数と二項演算子を使用できます。

高度なテキストの一致はパフォーマンスに大きな影響を与えるので、 contains 文字列演算子は検索ジョブでの使用をブロックされます。 代わりに、 has 文字列演算子を使用します。 パフォーマンスに関する考慮事項の詳細については、「 Azure Monitor でのログ クエリの最適化」を参照してください。

価格モデル

検索ジョブの料金は以下に基づきます。

• ジョブの実行を検索する

  • 分析ログ - 長期保持されているデータのうち、検索ジョブがスキャンするデータの量。

    注

    Analytics ログの場合、分析リテンション期間のデータをスキャンしても料金はかかりません。

  • 基本プランまたは補助プラン - 検索ジョブがクエリされた時間範囲内でスキャンするすべてのデータ。

  スキャンされるデータは、指定した時間内に、検索ジョブを実行するテーブル内のデータの量として定義されます。 分析と長期的なリテンション期間の詳細については、「 Log Analytics ワークスペースでのデータ保持の管理」を参照してください。

• 検索ジョブの結果 - Analytics ログのデータ インジェスト率に基づいて、検索ジョブが検索して結果テーブルに取り込むデータの量。

価格の例

分析ログを含むテーブルの検索が 60 日間にわたって、テーブルが 1 日あたり 500 GB のデータを取り込むが、テーブルの分析リテンション期間が 30 日に設定されている場合、スキャンされたデータの 15,000 GB が課金されます。長期保有期間のデータは 30 日間のみです。 分析リテンション期間の 30 日間のデータをスキャンしても料金はかかりません。 検索ジョブが 1,000 レコードを返す場合、これら 1,000 レコードの結果テーブルへの取り込みに対して課金されます。

Basic ログまたは補助ログを含むテーブルの検索が 60 日間に及び、テーブルが 1 日あたり 500 GB のデータを取り込む場合、スキャンされたデータの 30,000 GB が課金されます。 検索ジョブが 1,000 レコードを返す場合、これら 1,000 レコードの結果テーブルへの取り込みに対して課金されます。

詳細については、「Azure Monitor の価格」を参照してください。

関連コンテンツ

• Log Analytics ワークスペースでのデータ保有期間の管理の詳細について説明します。
• 基本ログまたは補助ログを含むテーブルに直接クエリを実行する方法について説明します。