Elastic Certified Engineer Exam対策 – Dynamic Mappingと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を使用するメリット・デメリット

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"
      }
    }
  }
}

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

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

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

dynamic: false

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

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

“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

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

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

“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

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

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

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

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

以下コマンドでmappingを確認します。

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の値を取得して返す、という動きをとります。

uthor : 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つの値が設定されます。“strict_date_optional_time”は、

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

を意味します。

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

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

Elastic Docs > Reference > Elasticsearch > Mapping > Mapping parameters > format
https://www.elastic.co/docs/reference/elasticsearch/mapping-reference/mapping-date-format#strict-date-time

型の自動判定に関するパラメータを設定する

以下のMappingでは、Dynamic Field Mappingの型判定に関するdate_detection、numeric_detection、dynamic_date_formatsをまとめて設定します。

PUT dynamic_detection_test
{
  "mappings": {
    "date_detection": true,
    "numeric_detection": true,
    "dynamic_date_formats": [
      "strict_date_optional_time",
      "yyyy/MM/dd"
    ]
  }
}

Point

このMappingでは、日付形式の文字列と数値形式の文字列を、Elasticsearchが自動的に判定します。

例えば、以下のDocumentを登録します。

POST dynamic_detection_test/_doc
{
  "title": "My first blog",
  "published_date": "2025-06-17",
  "event_date": "2025/06/18",
  "views": "100",
  "rating": "4.5",
  "is_public": true
}

Mappingは、次のコマンドで確認できます。

GET dynamic_detection_test/_mapping

各Fieldには、値に応じて次のField Typeが割り当てられます。

date_detectionを有効にすると、dynamic_date_formatsに一致する文字列がdate型として登録されます。また、numeric_detectionを有効にすると、JSON上では文字列として記述されている数値も、内容に応じてlong型またはdouble型として登録されます。

これらの設定により柔軟な型判定が可能になりますが、日付や数値に見える文字列が意図せず別の型として登録される可能性もあります。Field Typeを厳密に管理する必要がある場合は、明示的なMappingまたは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”を指定するようにしましょう。

{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 と 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を適用できます。

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は、Field名が「ip_」で始まる、または「_ip」で終わるFieldを自動的にip型として登録します。

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

Point

このDynamic Templateは、Field名のパターンに応じてip型を自動適用する例です。通常のDynamic Field MappingではIPアドレスも文字列として判定されるため、ip型として登録することで、CIDR検索やIPレンジ検索などの機能を利用できます。

また、unmatchを使用すると、matchに一致するFieldの一部を適用対象から除外できます。アクセスログやセキュリティログなど、IPアドレスを含むデータを取り込む場合に有効な設定です。

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

以下のDynamic Templateは、runtime_ms、bytes_sent、responseの3つのFieldをlong型として登録します。

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

Point

このDynamic Templateは、正規表現を利用して特定のFieldへlong型を自動適用する例です。通常のmatchではワイルドカードによる判定を行いますが、match_patternにregexを指定すると、複数のField名をまとめて指定するなど、より柔軟な条件を設定できます。

Webアクセスログでは、レスポンス時間や転送バイト数、HTTPステータスコードなどを数値として扱うため、このような設定が有効です。試験対策としては、match_patternにregexを指定すると正規表現を利用できることを押さえておくとよいでしょう。

Runtime Fieldを動的生成する

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

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

Point

このDynamic Templateは、文字列として検出され、Field名が「ip」で始まるFieldをip型のRuntime Fieldとして自動登録する例です。

Runtime Fieldは値を事前にインデックス化せず、検索時に評価します。そのため、インデックスサイズを抑えられる一方、検索やAggregationの実行時には追加の処理が発生し、通常のFieldより処理負荷が高くなる場合があります。検索頻度が低いFieldや、事前にField構成を予測しにくいログデータなどで利用できます。

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

以下のDynamic Templateは、nameオブジェクト配下のFieldをfull_name Fieldへコピーします。ただし、Field名がmiddleのものは対象から除外します。

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

Point

このDynamic Templateは、Object Fieldの階層を含むFieldパスを条件としてMappingを適用する例です。

matchがField名のみを対象とするのに対し、path_matchはname.firstやname.lastのような完全なFieldパスを対象とします。また、copy_toを利用すると、複数のFieldの値を1つの検索用Fieldへまとめられます。

この例では、name.firstやname.lastはfull_nameへコピーされますが、name.middleはpath_unmatchによって除外されます。matchとpath_matchの違い、およびcopy_toの役割を理解しておくことが重要です。

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

以下のDynamic Templateは、Dynamic Field Mappingが判定した型を、そのままMappingへ適用します。

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

Point

このDynamic Templateは、Template Variableである{dynamic_type}を利用して、Elasticsearchが自動判定したField TypeをMappingへ適用する例です。

例えば、整数値はlong型、真偽値はboolean型として登録されます。match_mapping_typeに「*」を指定しているため、Dynamic Field Mappingで検出されたすべての型が対象になります。

実務で利用する機会は多くありませんが、Dynamic Templateで利用できる代表的なTemplate Variableとして、{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)などの主要な条件指定を使い分けられること