マッピングはElasticsearchインデックス内の各フィールドの構造と処理ルールを定義するもので、検索やストレージ動作に直接影響します。適切なマッピング設計はデータの一貫性と検索精度を保証します。

マッピングの基本概念

マッピングとは、文書内の各フィールドがどのようなデータ型を持ち、どのように解析・保存されるかを事前に宣言する仕組みです。たとえば、text型のフィールドはトークン化され、形態素解析や正規化（大文字小文字変換、同義語統合など）を経てインデックスされます。一方、keywordやdate型はそのまま全体が1つのトークンとして扱われます。

重要なのは、インデックス作成時と検索時の分析設定が一致することです。異なる設定では検索結果が期待通りにならない可能性があります。

マッピングの構成要素

各マッピングは以下の要素から構成されます：

• メタフィールド：内部管理用の特殊フィールド（例：_id, _source）
• プロパティ：ユーザー定義フィールド群。同一インデックス内では、同じ名前のフィールドは同じ型と設定を持つ必要があります（copy_toやignore_aboveなどの一部例外を除く）。

フィールドタイプの種類

主要なフィールドタイプには以下があります：

• text：全文検索用。アナライザーによるトークン化が必要
• keyword：完全一致検索用。トークン化なし
• integer, float：数値型
• date：日付型。フォーマット指定可能
• boolean, object, nested など

マッピングの作成方法

インデックス作成時に明示的にマッピングを定義できます。以下はblog_indexというインデックスを作成し、authorタイプに複数フィールドを定義する例です：

PUT /blog_index
{
  "mappings": {
    "properties": {
      "author_id": { "type": "keyword" },
      "full_name": {
        "type": "text",
        "analyzer": "kuromoji"
      },
      "years_active": { "type": "short" },
      "gender": { "type": "keyword" },
      "joined_date": {
        "type": "date",
        "format": "yyyy-MM-dd"
      },
      "bio": {
        "type": "text",
        "index": false
      }
    }
  }
}

※ 注意：index: falseとするとそのフィールドは検索対象外になります。_allフィールドは非推奨となり、代わりにcopy_toを使用してカスタム総合フィールドを作成することが推奨されています。

マッピングの更新制限

一度作成されたマッピングは、既存フィールドの型や設定を変更できません。これは内部インデックス構造が固定されるためです。ただし、新規フィールドの追加は可能です：

PUT /blog_index/_mapping
{
  "properties": {
    "last_login": {
      "type": "date",
      "format": "epoch_second"
    }
  }
}

既存インデックスに対して新しいマッピング定義全体をPUTしようとすると、resource_already_exists_exceptionエラーが発生します。

マッピングの確認方法

現在のマッピング構成を確認するには、以下のAPIを使用します：

GET /blog_index/_mapping

レスポンスには、各フィールドの型、アナライザー設定、インデックス可否などが詳細に表示されます。これにより、スキーマ設計の検証やトラブルシューティングが容易になります。