Elasticsearch の マッピング（mapping） は「インデックスに入る JSON ドキュメントを、どのような型・構造・検索特性で扱うかを定義する設計図」です。
RDB で言えば テーブル定義（カラム型・インデックス設計） に相当し、性能・検索精度・ストレージ使用量を大きく左右します。
以下で 基礎 → よくある落とし穴 → チューニング観点 → 実務パターン の順で解説します。
1. マッピングとは何か（役割）
何を決めるものか
フィールドの データ型
全文検索するか / しないか
集計・ソートできるか
解析（analyzer）方法
ネスト構造の扱い
例（非常に簡単なマッピング）：
PUT my-index{ "mappings": { "properties": { "title": { "type": "text" }, "price": { "type": "integer" }, "created_at": { "type": "date" } } }}
2. 主なフィールド型と用途
(1) text と keyword（最重要）
| 型 | 用途 |
|---|
| text | 全文検索（分かち書きされる） |
| keyword | 完全一致、集計、ソート |
"title": { "type": "text"},"status": { "type": "keyword"}
よくある実務パターン（multi-field）
"title": { "type": "text", "fields": { "raw": { "type": "keyword" } }}
title → 全文検索用
title.raw → 集計・ソート用
(2) 数値型
"age": { "type": "integer" }
(3) date
"created_at": { "type": "date", "format": "strict_date_optional_time||epoch_millis"}
(4) boolean
"is_active": { "type": "boolean" }
(5) object / nested
object（デフォルト）
"user": { "properties": { "name": { "type": "keyword" }, "age": { "type": "integer" } }}
nested（配列 × 検索精度が必要な場合）
"comments": { "type": "nested", "properties": { "author": { "type": "keyword" }, "message": { "type": "text" } }}
3. 動的マッピングとそのリスク
dynamic mapping（自動推測）
Elasticsearch はデフォルトで 型を自動推測します。
問題点：
対策：
"dynamic": "strict"
→ 定義されていないフィールドが来たらエラーにする
4. マッピングチューニングの考え方（超重要）
観点①：検索・集計しないフィールドは捨てる
"log_message": { "type": "text", "index": false}
観点②：doc_values を制御
"large_text": { "type": "text", "doc_values": false}
観点③：norms を無効化
スコアリング不要なフィールドでは無効化。
"status": { "type": "keyword", "norms": false}
観点④：analyzer の最適化
日本語（形態素解析）
"analysis": { "analyzer": { "ja_analyzer": { "type": "custom", "tokenizer": "kuromoji_tokenizer" } }}
"title": { "type": "text", "analyzer": "ja_analyzer"}
観点⑤：ignore_above で keyword の暴発防止
"tag": { "type": "keyword", "ignore_above": 256}
観点⑥：フィールド数の制限
"index.mapping.total_fields.limit": 1000
5. ストレージ・性能チューニング例
不要な _source を削減
"_source": { "excludes": ["debug_info"]}
低頻度データは index=false
"raw_payload": { "type": "object", "enabled": false}
6. マッピング変更時の注意点（重要）
既存フィールドの型変更は不可
修正するには：
新しいインデックスを作成
再インデックス（reindex）
エイリアス切り替え
7. 実務的な設計指針（チェックリスト）
これは全文検索する？
集計・ソートする？
スコアリング必要？
配列検索の整合性は必要？
フィールドは将来増える？
まとめ（要点）
マッピングは Elasticsearchの性能と品質を決める最重要設計
デフォルト任せは危険（dynamic mapping）
text / keyword の使い分けが肝
検索・集計しないフィールドは極力「持たせない」
本番では 事前設計 + strict mapping + 再インデックス前提 が基本
この記事へのコメント