Elastic Certified Engineer Exam対策 – Dynamic Templates

このブログの目的

本ブログシリーズの目的は、Elastic Certified Engineer Examの合格に必要な知識と技術を体系的に習得することです。Elastic Certified Engineer Examでは、Elasticsearchの運用や設計に関する実践的なスキルが問われます。本記事は、Dynamic MappingおよびDynamic Templatesに関する知識と実装スキルの習得を目的としており、Elastic社が公開している試験ガイドの以下の試験範囲に関連する内容を扱います。

Data Management – Define an index that satisfies a given set of requirements

Dynamic Mappingは、Elasticsearchが新しいフィールドを検出した際に、自動的にMappingを生成する機能です。一方、Dynamic Templatesは、その自動生成ルールを利用者が制御するための仕組みです。試験では、dynamicパラメータ（true / false / strict / runtime）の動作を理解するだけでなく、Dynamic Field Mappingによる型の自動判定や、match_mapping_type、match、path_matchなどを利用したDynamic Templateを要件に応じて実装できることが求められます。

本記事では、Dynamic Mappingの基本的な仕組みから、dynamicパラメータの動作、Dynamic Field Mappingによる型の自動判定、Dynamic Templatesの主要な設定方法、代表的な実装例、そして試験で問われやすいポイントまでを解説します。実際にIndexを作成し、Documentを投入しながら学習を進めることで、試験対策と実践的なスキルの習得を目指します。ぜひ実際に手を動かしながら学習を進め、試験合格につなげてください。

試験情報は以下サイトで確認可能です。

https://www.elastic.co/training/elastic-certified-engineer-exam

Dynamic Mappingとは

Dynamic Mappingは、Elasticsearchが新しいフィールドを検出した際に、自動的にMappingを生成する機能です。あらかじめすべてのフィールドを定義しておかなくても、新しいフィールドをMappingへ追加できるため、ログやメトリクスのようにフィールド構成が事前に確定していないデータを扱う場合に特に有効です。

また、追加されたフィールドに対しては、Dynamic Field Mappingによって適切なデータ型が自動的に判定されます。一方で、自動判定された型が利用者の意図と異なる場合もあるため、その動作を理解したうえで利用することが重要です。

Dynamic Mappingを使用するメリット・デメリット

メリット

• Mapping定義を事前に準備しなくてもデータ投入を開始できる
• 新しいフィールドが出現しても自動で対応できる
• PoCや開発初期段階で素早く環境を構築できる

デメリット

• 意図しない型でMappingが作成される場合がある
• 不要なフィールドが大量に作成される可能性がある

4つのdynamicパラメータとその動作

Dynamic Mappingの動作は、mapping内のdynamicパラメータによって制御できます。dynamicパラメータを設定することで、新しいフィールドが検出された際に、Mappingへ自動追加するか、無視するか、エラーとするかを選択できます。デフォルト値はtrueであり、多くの場合は新しいフィールドが自動的にMappingへ追加されます。本番環境では、意図しないフィールドの増加やMapping Explosionを防ぐために、要件に応じて適切な設定を選択することが重要です。

Elastic Certified Engineer Examでは、各設定値の動作の違いを問われることはありませんが、どの設定でどう動くか、という点と、これらの設定値がどのドキュメントのどこに記載があるか、は把握しておきましょう。

dynamic: true (デフォルト)

新しいフィールドを検出すると、自動的にMappingへ追加します。

PUT blogs_dynamic_true
{
  "mappings": {
    "dynamic": true,
    "properties": {
      "title": {
        "type": "text"
      }
    }
  }
}

dynamic: false

新しいフィールドを受け入れますが、Mappingへは追加しません。

PUT blogs_dynamic_false
{
  "mappings": {
    "dynamic": false,
    "properties": {
      "title": {
        "type": "text"
      }
    }
  }
}

dynamic: strict

未定義のフィールドが投入されるとエラーとなります。

PUT blogs_dynamic_strict
{
  "mappings": {
    "dynamic":"strict",
    "properties": {
      "title": {
        "type":"text"
      }
    }
  }
}

dynamic: runtime

新しいフィールドをRuntime Fieldとして追加します。

PUT blogs_dynamic_runtime
{
  "mappings": {
    "dynamic":"runtime",
    "properties": {
      "title": {
        "type":"text"
      }
    }
  }
}

動作確認用データ投入 : dynamic: true

“title” fieldのみ定義している”blogs_dynamic_true” indexに対して、以下のDocumentを投入してみます。

POST blogs_dynamic_true/_doc
{
  "title":"My first blog",
  "author":"Tom Hanks"
}

下図、赤枠の通り、動的に”author” fieldが追加されていることがわかります。

動作確認用データ投入 : dynamic: false

“title” fieldのみ定義している”blogs_dynamic_false” indexに対して、以下のDocumentを投入してみます。

POST blogs_dynamic_false/_doc
{
  "title":"My first blog",
  "author":"Tom Hanks"
}

“author” fieldは追加されていないことがわかります。

ただし、以下の通り、”_source”領域には、author : Tom Hanks が含まれた状態で保存されています。

動作確認用データ投入 : dynamic: strict

“title” fieldのみ定義している”blogs_dynamic_strict” indexに対して、以下のDocumentを投入してみます。

POST blogs_dynamic_strict/_doc
{
  "title":"My first blog",
  "author":"Tom Hanks"
}

以下のように、Errorが発生し、status code 400を返却しています。

動作確認用データ投入 : dynamic: runtime

“title” fieldのみ定義している”blogs_dynamic_runtime” indexに対して、以下のDocumentを投入してみます。

POST blogs_dynamic_runtime/_doc
{
  "title":"My first blog",
  "author":"Tom Hanks"
}

以下は、「get blogs_dynamic_runtime/_mapping」を実行した結果

下図は、次のコマンドを実行した結果です。

get blogs_dynamic_runtime/_search
{
    "fields": [
      "author"
    ]
}

結果として、mappingとして”author” fieldは追加されませんが、runtime fieldとして”author”が追加されています。また、”_source” 領域に author : Tom Hanksは保持され、runtime fieldのauthorは、クエリ返却時に_sourceからauthorの値を取得して返す、という動きをとります。

Dynamic Field Mapping : 型の自動判定

Dynamic Field Mappingは、Dynamic Mappingによって新しいフィールドが検出された際に、そのフィールドのデータ型を自動的に判定する仕組みです。Elasticsearchは投入されたJSONデータの値を解析し、文字列・数値・日付・真偽値などの型を推定したうえで適切なMappingを生成します。

例えば、以下のようなDocumentを投入した場合を考えてみましょう。

POST blogs_test/_doc
{
  "title": "My first blog",
  "views": 100,
  "is_public": true
}

この場合、Elasticsearchは各フィールドの値をもとに、以下のような型を自動的に割り当てます。

このように、利用者が明示的にMappingを定義しなくても、Elasticsearchが適切な型を判断してMappingを作成します。

ただし、自動判定された型が必ずしも利用者の意図と一致するとは限りません。そのため、本番環境では明示的なMappingやDynamic Templateを利用して型を制御するケースも少なくありません。

また、Dynamic Field Mappingでは日付形式を自動判定する date_detection や、文字列として格納された数値を数値型として認識する numeric_detection を利用できます。これらの設定を適切に利用することで、より柔軟な型判定を実現できます。

date_detection

date_detectionは、文字列形式の値を日付型として自動認識する機能です。デフォルトでは有効になっており、Elasticsearchが認識可能な日付形式に一致した場合、自動的にdate型のMappingが作成されます。

例えば、以下のDocumentを投入した場合、

{
  "event_date": "2025-06-17"
}

event_dateフィールドは文字列ではなくdate型として登録されます。

一方で、日付のように見える文字列を単なる文字列として扱いたい場合は、date_detectionをfalseに設定します。

PUT blogs_test
{
  "mappings": {
    "date_detection": false
  }
}

試験では、日付文字列が自動的にdate型へ変換されることを理解しておけば十分です。

numeric_detection

numeric_detectionは、文字列として保存されている数値を自動的に数値型へ変換する機能です。デフォルトでは無効となっています。

例えば、以下のDocumentを投入した場合、

{
  "price": "100"
}

通常は文字列として認識されます。しかしnumeric_detectionを有効にすると、Elasticsearchは数値と判断し、long型としてMappingを作成します。

PUT blogs_test
{
  "mappings": {
    "numeric_detection": true
  }
}

ログデータやCSV取込時など、数値が文字列として格納されるケースで利用できますが、本番環境では明示的なMappingを定義することが一般的です。

dynamic_date_formats

dynamic_date_formatsは、date_detectionで認識する日付形式をカスタマイズするための設定です。Elasticsearchはデフォルトでも複数の日付形式を認識できますが、独自の日付フォーマットを利用する場合は明示的に定義する必要があります。

例えば、以下の設定では「yyyy/MM/dd」形式の日付を認識できます。

PUT blogs
{
  "mappings": {
    "dynamic_date_formats": [
      "yyyy/MM/dd"
    ]
  }
}

これにより、

{
  "event_date": "2025/06/17"
}

のような値がdate型として自動登録されます。

“dynamic_date_formats”のdefault値としては、

["strict_date_optional_time","yyyy/MM/dd HH:mm:ss Z||yyyy/MM/dd Z"]

の2つの値が設定されます。

Elastic Docs > Manage data > The Elasticsearch data stre > Mapping > Dynamic mapping > Dynamic field mapping

https://www.elastic.co/docs/manage-data/data-store/mapping/dynamic-field-mapping

“strict_date_optional_time”は、

yyyy-MM-dd'T'HH:mm:ss.SSSZ or yyyy-MM-dd

を意味します。

Elastic Docs > Reference > Elasticsearch > Mapping > Mapping parameters > format

https://www.elastic.co/docs/reference/elasticsearch/mapping-reference/mapping-date-format#strict-date-time

Dynamic Field Mappingを利用すると、Elasticsearchはフィールド名や値から自動的に型を推定してMappingを生成できます。しかし、実際の運用では「すべての文字列をkeyword型にしたい」「特定のフィールドだけ別の型にしたい」といった要件も少なくありません。次章では、このような型推定ルールを柔軟にカスタマイズできるDynamic Templatesについて解説します。

Dynamic Templatesとは

Dynamic Templatesは、Dynamic Field Mappingによる型判定やMapping生成ルールをカスタマイズするための機能です。Dynamic Mappingでは、新しいフィールドが検出されるとElasticsearchが値を解析して自動的に型を決定します。しかし、実際の運用では自動判定だけでは要件を満たせないケースも少なくありません。

例えば、文字列フィールドは通常「text + keyword」として作成されますが、「すべての文字列をkeyword型として登録したい」「*_ipという名前のフィールドは自動的にip型として登録したい」といった要件が発生することがあります。このような場合に利用するのがDynamic Templatesです。

Dynamic Templatesでは、フィールド名や検出されたデータ型を条件として指定し、その条件に一致したフィールドに対して任意のMappingを適用できます。つまり、Dynamic Field Mappingの型推定結果をそのまま利用するのではなく、利用者が定義したルールに従ってMappingを動的に生成できる仕組みです。

例えば、以下の設定では、新しく検出された文字列フィールドをすべてkeyword型として登録します。

PUT blogs_template
{
  "mappings": {
    "dynamic_templates": [
      {
        "strings_as_keyword": {
          "match_mapping_type": "string",
          "mapping": {
            "type": "keyword"
          }
        }
      }
    ]
  }
}

この設定が適用されたIndexに以下のDocumentを投入すると、

{
  "title": "My first blog",
  "author": "Tom Hanks"
}

titleフィールドおよびauthorフィールドは、通常のDynamic Field Mappingで生成される「text + keyword」ではなく、keyword型としてMappingが作成されます。

Dynamic Templatesは、Dynamic Mappingの柔軟性を維持しながらも、Mappingの生成ルールを制御できる非常に強力な機能です。Elastic Certified Engineer Examでも頻繁に出題される重要な機能であり、特にmatch_mapping_type、match、path_matchなどの条件指定方法は必ず理解しておきましょう。

続いて、Dynamic Templateの設定について解説します。まずは、Dynamic Templateの基本構文を確認しておきましょう。

PUT blogs_template
{
  "mappings": {
    "dynamic_templates": [
      {
        "template_name": {
          "match_mapping_type": "string",
          "mapping": {
            "type": "keyword"
          }
        }
      }
    ]
  }
}

Dynamic Templateは以下の3つの要素で構成されます。

新しいフィールドが検出されると、ElasticsearchはDynamic Templateを上から順番に評価し、最初に一致したTemplateのMappingを適用します。そのため、条件の指定方法とTemplateの記述順序を理解することが重要です。

それでは、試験で頻出となる各設定を順番に見ていきましょう。

match_mapping_type

match_mapping_typeは、Elasticsearchが判定したデータ型に基づいてDynamic Templateを適用するための条件です。Dynamic Templateの中で最も利用頻度が高く、試験でも頻出の設定です。

例えば、以下の設定では、文字列として判定されたフィールドをすべてkeyword型として登録します。

{
  "dynamic_templates": [
    {
      "strings_as_keyword": {
        "match_mapping_type": "string",
        "mapping": {
          "type": "keyword"
        }
      }
    }
  ]
}

この設定が適用されているIndexに対して、

{
  "title": "My first blog",
  "author": "Tom Hanks"
}

を投入すると、titleとauthorはtext型ではなくkeyword型としてMappingが作成されます。主な指定可能値は以下の通りです。

「文字列をすべてkeyword型へ変更する」という条件が問題に含まれている場合、match_mapping_type=”string”を指定するようにしましょう。

match と unmatch

matchは、フィールド名のパターンによってDynamic Templateを適用するための条件です。例えば、以下の設定では、フィールド名が「_ip」で終わるフィールドに対してip型を適用します。

{
  "dynamic_templates": [
    {
      "ip_fields": {
        "match": "*_ip",
        "mapping": {
          "type": "ip"
        }
      }
    }
  ]
}

この設定がある場合、

{
  "client_ip": "192.168.1.1"
}

は自動的にip型としてMappingされます。一方、unmatchは除外条件を指定するための設定です。

{
  "match": "*_ip",
  "unmatch": "temp_*"
}

上記の場合、「ip」で終わるフィールドのうち、「temp」で始まるフィールドは除外されます。matchとunmatchを組み合わせることで、特定の命名規則を持つフィールドだけにDynamic Templateを適用できます。

{dynamic_type}

Dynamic Templateでは、Template Variableとして “ {dynamic_type} ”を利用できます。” {dynamic_type} ” は、ElasticsearchがDynamic Field Mappingによって判定したデータ型を表します。これを利用することで、検出された型を動的に参照しながらMappingを生成できます。

例えば、以下の設定では、Elasticsearchが判定した型をそのままMappingへ適用します。

{
  "dynamic_templates": [
    {
      "default_types": {
        "match_mapping_type": "*",
        "mapping": {
          "type": "{dynamic_type}"
        }
      }
    }
  ]
}

例えば、

{
  "price": 100,
  "is_public": true
}

を投入すると、Elasticsearchは以下のように型を判定します。

そして、Dynamic Template内の “ {dynamic_type} ” がそれぞれの型へ置換されることで、以下のようなMappingが生成されます。

{
  "price": {
    "type": "long"
  },
  "is_public": {
    "type": "boolean"
  }
}

match_pattern

matchは通常、ワイルドカード（*）によるパターンマッチで評価されます。しかし、より複雑な条件でフィールド名を判定したい場合は、” match_pattern ”に “ regex ”を指定することで正規表現を利用できます。

例えば、以下のDynamic Templateでは、

{
  "to_long": {
    "match_pattern": "regex",
    "match": "^(runtime_ms|bytes_sent|response)$",
    "mapping": {
      "type": "long"
    }
  }
}

フィールド名が

• runtime_ms
• bytes_sent
• response

のいずれかに一致した場合のみ、long型としてMappingが作成されます。

正規表現の

^(runtime_ms|bytes_sent|response)$

は、

• ^ : 文字列の先頭
• $ : 文字列の末尾
• | : OR条件

を意味しており、「フィールド名が runtime_ms、bytes_sent、response のいずれかと完全一致する場合」を表しています。通常のワイルドカードでは表現しにくい複雑な条件を指定できる点が、match_pattern: "regex" のメリットです。

Dynamic Template サンプル

以下は、公式ドキュメントに記載されているDynamic templateのサンプルをピックアップしたものです。それぞれポイントと簡易的な説明文を載せます。

特定のフィールドをIP型として登録する

以下のDynamic Templateは、フィールド名が「ip_」で始まる、または「_ip」で終わるフィールドを自動的にip型として登録します。

PUT logs_ip_template
{
  "mappings": {
    "dynamic_templates": [
      {
        "ip_fields": {
          "match": ["ip_*", "*_ip"],
          "unmatch": ["one*", "*two"],
          "mapping": {
            "type": "ip"
          }
        }
      }
    ]
  }
}

学習ポイント

• match
• unmatch
• ip型
• フィールド名による型制御

説明

このDynamic Templateは、フィールド名のパターンに応じて自動的にip型を適用するサンプルです。通常のDynamic Field MappingではIPアドレスも文字列として認識されますが、ip型として登録することでCIDR検索やIPレンジ検索などの高度な検索機能を利用できます。また、unmatchを利用することで特定のフィールドのみ除外することも可能です。Elastic Securityやアクセスログ分析では非常によく利用される実践的な設定例です。

複数の指定FieldをLong型として登録する

以下のDynamic Templateは、runtime_ms、bytes_sent、responseの3つのフィールドをlong型として登録します。

PUT logs_long_template
{
  "mappings": {
    "dynamic_templates": [
      {
        "to_long": {
          "match_pattern": "regex",
          "match": "^(runtime_ms|bytes_sent|response)$",
          "mapping": {
            "type": "long"
          }
        }
      }
    ]
  }
}

学習ポイント

• match_pattern
• regex
• 正規表現
• long型

説明

このDynamic Templateは、正規表現を利用して特定のフィールド名へlong型を適用するサンプルです。通常のmatchではワイルドカードによる判定しか行えませんが、match_patternにregexを指定することで、より複雑な条件を表現できます。Webアクセスログなどでは、レスポンス時間や転送バイト数、HTTPステータスコードなどを数値として扱うことが多く、このような設定が利用されます。試験ではregexの詳細よりも、match_patternで正規表現を利用できることを理解しておきましょう。

Runtime Fieldを動的生成する

以下のDynamic Templateは、「ip」で始まる文字列フィールドをRuntime Fieldとして登録します。

PUT runtime_ip_template
{
  "mappings": {
    "dynamic_templates": [
      {
        "strings_as_ip": {
          "match_mapping_type": "string",
          "match": "ip*",
          "runtime": {
            "type": "ip"
          }
        }
      }
    ]
  }
}

学習ポイント

• runtime
• Runtime Field
• 検索時評価
• ディスク使用量削減

説明

このDynamic Templateは、通常のMappingを作成せずにRuntime Fieldを生成するサンプルです。Runtime Fieldはインデックス作成時にインデックス化を行わず、検索時に値を評価するため、ディスク使用量やMapping数を抑制できます。一方で、検索や集計時には追加の処理が発生するため、通常のフィールドより性能面では不利になります。大量の未知フィールドが発生するログ分析環境などで利用されることが多く、Runtime Fieldの代表的な利用例の一つです。

オブジェクト配下のフィールドへ適用する

以下のDynamic Templateは、nameオブジェクト配下のすべてのフィールドをfull_nameフィールドへコピーします。

PUT users_template
{
  "mappings": {
    "dynamic_templates": [
      {
        "full_name": {
          "path_match": "name.*",
          "path_unmatch": "*.middle",
          "mapping": {
            "type": "text",
            "copy_to": "full_name"
          }
        }
      }
    ]
  }
}

学習ポイント

• path_match
• path_unmatch
• copy_to
• オブジェクト階層

説明

このDynamic Templateは、オブジェクト階層を含めたフィールドパスを条件として利用するサンプルです。matchがフィールド名のみを対象とするのに対し、path_matchは「name.first」「name.last」のような完全パスを対象とします。また、copy_toを利用することで複数フィールドの値を一つの検索用フィールドへ集約できます。matchとpath_matchの違いは試験でも問われやすいため、それぞれの適用範囲を理解しておきましょう。

Elasticsearchが判定した型をそのまま利用する

以下のDynamic Templateは、Dynamic Field Mappingが判定した型をそのまま利用してMappingを生成します。

PUT dynamic_type_template
{
  "mappings": {
    "dynamic_templates": [
      {
        "default_types": {
          "match_mapping_type": "*",
          "mapping": {
            "type": "{dynamic_type}"
          }
        }
      }
    ]
  }
}

学習ポイント

• {dynamic_type}
• Template Variable
• 型の再利用
• Dynamic Field Mapping

説明

このDynamic Templateは、Template Variableである {dynamic_type} を利用するサンプルです。ElasticsearchがDynamic Field Mappingによって判定した型を動的に参照し、そのままMappingへ適用できます。例えば数値であればlong型、真偽値であればboolean型として登録されます。実務で利用する機会はそれほど多くありませんが、Dynamic Templateで利用できる変数の代表例として公式ドキュメントでも紹介されています。試験対策としては、{dynamic_type} が利用できることを知識として押さえておけば十分です。

Elastic社が提供する無料On-Demand Trainingで理解を深めよう

本記事では、Dynamic Mappingの仕組みから始まり、dynamicパラメータの動作、Dynamic Field Mappingによる型の自動判定、そしてDynamic TemplateによるMapping制御までを解説しました。また、match_mapping_type、match、match_pattern、path_match、Runtime Field生成など、Elastic Certified Engineer Examで問われる可能性のある主要なDynamic Templateの設定についても紹介しました。

しかし、Dynamic Templateは単に構文を暗記するだけでは十分ではありません。実際にIndexを作成し、Documentを投入して、「どのようなMappingが生成されるのか」「期待した型が適用されるのか」を確認しながら学習することが重要です。

Elastic社では、ElasticsearchやElastic Cloudを実際に操作しながら学習できる無償のHands-on TrainingやOn-Demand Trainingを提供しています。これらのトレーニングでは、Dynamic Templateだけでなく、Mapping、Index Template、Query DSL、Aggregation、Ingest Pipelineなど、Elastic Certified Engineer Examで重要となる機能について体系的に学習できます。

特にDynamic Templateは、「すべての文字列をkeyword型にする」「特定のフィールドをip型にする」「Runtime Fieldを動的に生成する」といった要件を実際に実装してみることで理解が深まります。また、投入したDocumentに対してどのようなMappingが生成されるのかを _mapping APIで確認する習慣を身につけることで、試験本番でも落ち着いて対応できるようになります。

ぜひHands-on TrainingやElastic Cloud環境を活用し、Dynamic MappingやDynamic Templateを実際に動かしながら理解を深めてください。

Elastic Cloud アカウント作成

https://cloud.elastic.co/registration

Elastic Training

https://www.elastic.co/training

Elastic Learning Portal

https://learn.elastic.co/pages/58/home-page

試験で問われるポイント

試験対策として、下記項目について、Dynamic Templateを含んだIndex定義についての理解度を確認してください。

• Dynamic Templatesの基本構文を理解し、要件に応じたMapping制御の基本を習得していること
• Dynamic Mappingの役割や、dynamic（true / false / strict / runtime）の動作の違いを理解し、要件に沿って定義できること。
• Dynamic Field Mappingによる型の自動判定と、date_detection・numeric_detection・dynamic_date_formatsの役割を理解し、これらの設定値を使ったIndex定義が出来ること。
• match_mapping_type、match、path_match、match_pattern(regex)などの主要な条件指定を使い分けられること