---

Elasticsearch API 入門：基本の使い方を徹底解説

はじめに：ElasticsearchとAPIの重要性

現代のデータ活用の世界において、大量の非構造化データや半構造化データを高速かつ柔軟に検索、分析、可視化するニーズは増大の一途をたどっています。Elasticsearchは、その強力な全文検索機能、リアルタイム分析能力、そして高いスケーラビリティによって、こうしたニーズに応えるためのデファクトスタンダードとも言える存在となっています。

Elasticsearchは、RESTful APIを通じてその全ての機能を提供しています。つまり、Elasticsearchを操作し、データを取り込み、検索し、設定を変更するといった全ての操作は、HTTPリクエストを使って行われます。このAPIを理解し、使いこなすことが、Elasticsearchを最大限に活用するための最初の、そして最も重要なステップとなります。

本記事では、ElasticsearchのAPIの基本に焦点を当て、データのインデックス作成（登録）、取得、更新、削除といった基本的なCRUD操作から、インデックス管理、マッピングの理解、そして最も重要な検索APIの使い方までを、初心者の方にも分かりやすいように徹底的に解説します。約5000語のボリュームで、各APIの役割、リクエストの形式、レスポンスの内容、そして具体的な使用例を豊富に盛り込みながら、Elasticsearch APIの基本をマスターすることを目指します。

記事全体を通して、主にcurlコマンドを使ったAPIコールの例を示しますが、KibanaのDev Toolsを使う方法についても触れます。

1. Elasticsearch APIに触れる準備

Elasticsearch APIは、標準的なHTTPプロトコルを使用します。これは、Webブラウザからアクセスするのと同じプロトコルですが、通常はコマンドラインツール（curlなど）やプログラム言語のクライアントライブラリを使って操作します。

本記事では、説明をシンプルにするため、主にcurlコマンドを使用します。Kibanaをお使いの場合は、Dev Toolsコンソールが非常に便利です。

前提条件:

• Elasticsearchインスタンスが起動していること（通常はlocalhost:9200でアクセスできます）。
• curlコマンドが使える環境があること。またはKibanaがインストールされ、Elasticsearchに接続されていること。

APIの基本形式:

Elasticsearch APIの基本的なリクエスト形式は以下のようになります。

<HTTPメソッド> /<インデックス名>/<タイプ名>/<ドキュメントID>
<HTTPメソッド> /<インデックス名>/_endpoint
<HTTPメソッド> /_endpoint

• <HTTPメソッド>: GET, POST, PUT, DELETEなど。
• <インデックス名>: データの集合を表す名前。必須でないAPIもあります（例: クラスター情報取得）。
• <タイプ名>: Elasticsearch 6.xまでは必須でしたが、7.x以降は単一の_docタイプを使用することが推奨されています。8.x以降はタイプ名なしが標準です。本記事では7.x/8.xの慣習に従い、タイプ名を省略するか、互換性のために_docを使用します。
• <ドキュメントID>: 特定のドキュメントを一意に識別するID。
• _endpoint: Elasticsearchが提供する特定のアクションのエンドポイント名（例: _search, _bulk, _mapping）。

多くの場合、リクエストボディにはJSON形式でデータを指定します。その際は、HTTPヘッダーでContent-Type: application/jsonを指定する必要があります。

動作確認:

まず、Elasticsearchクラスターが応答するか確認してみましょう。

curlの場合:

bash
curl -X GET "localhost:9200/"

-X GETはHTTPメソッドを指定します。今回は省略してもデフォルトでGETになりますが、明示的に指定する習慣をつけるのが良いでしょう。

Kibana Dev Toolsの場合:

json
GET /

レスポンス例:

json
{
"name" : "your_node_name",
"cluster_name" : "your_cluster_name",
"cluster_uuid" : "...",
"version" : {
"number" : "8.x.x", # または 7.x.x
"build_flavor" : "default",
"build_type" : "...",
"build_hash" : "...",
"build_date" : "...",
"build_snapshot" : false,
"lucene_version" : "...",
"minimum_wire_compatibility_version" : "...",
"minimum_index_compatibility_version" : "..."
},
"tagline" : "You Know, for Search"
}

Elasticsearchのバージョン情報やクラスター名などが返ってくれば、APIが正しく機能しています。

2. Elasticsearchの基本概念

APIの説明に入る前に、Elasticsearchにおけるいくつかの重要な概念を理解しておきましょう。

• クラスター (Cluster): 1つ以上のノードの集まりです。データを共有し、検索やインデックス作成機能を提供します。分散システムの中心的な単位です。
• ノード (Node): Elasticsearchの単一のインスタンスです。ノードはクラスターに参加し、データの格納や検索処理を行います。
• インデックス (Index): 同じような特性を持つドキュメントの集まりです。リレーショナルデータベースにおけるテーブルのようなものですが、スキーマの柔軟性が高いのが特徴です。検索の最小単位となります。
• タイプ (Type): Elasticsearch 6.x以前で使用されていた概念で、インデックス内のドキュメントをさらに分類するものでした。7.x以降は非推奨となり、8.xで廃止されました。今後は1つのインデックスに1つのタイプ（実質的にタイプなし、または_docタイプ）として扱うのが一般的です。
• ドキュメント (Document): 検索対象となるデータの単位です。JSON形式で表現されます。リレーショナルデータベースにおける1つの行に相当しますが、スキーマは柔軟です。
• フィールド (Field): ドキュメント内の個々のデータ項目です。JSONオブジェクトのキーに相当します。
• マッピング (Mapping): ドキュメント内の各フィールドがどのように扱われるかを定義するスキーマのようなものです。フィールドのデータ型（文字列、数値、日付など）や、文字列フィールドの分析方法（単語分割や正規化など）を定義します。
• シャード (Shard): インデックスを水平に分割したものです。巨大なインデックスを複数のシャードに分割することで、複数のノードに分散して格納・処理できるようになり、スケーラビリティとパフォーマンスが向上します。各シャードは独立したインデックスのように扱われます。
• レプリカ (Replica): シャードの複製です。レプリカを作成することで、データの冗長性が高まり、ノード障害時のデータ損失を防ぎます。また、検索リクエストをレプリカシャードに分散することで、検索のスループットを向上させることができます。

これらの概念を頭に入れながら、APIの操作を見ていきましょう。

3. インデックスの管理

Elasticsearchでデータを扱うためには、まずインデックスを作成する必要があります。インデックスの作成、一覧表示、削除といった基本的な管理操作を見ていきます。

3.1. インデックスの作成 (PUT Index API)

新しいインデックスを作成するには、PUTメソッドを使用し、インデックス名をパスに指定します。

bash
curl -X PUT "localhost:9200/my_first_index"

Kibana Dev Tools:

json
PUT /my_first_index

レスポンス例:

json
{
"acknowledged" : true,
"shards_acknowledged" : true,
"index" : "my_first_index"
}

acknowledged: trueとなっていれば、インデックスの作成リクエストは受け付けられました。

インデックス作成時には、設定（シャード数、レプリカ数など）やマッピング（フィールドの定義）を同時に指定することが一般的です。これはリクエストボディにJSONで記述します。

例：シャード数1、レプリカ数1、簡単なマッピングを指定してインデックスを作成

bash
curl -X PUT "localhost:9200/my_products" -H "Content-Type: application/json" -d'
{
"settings": {
"index": {
"number_of_shards": 1,
"number_of_replicas": 1
}
},
"mappings": {
"properties": {
"name": {
"type": "text"
},
"price": {
"type": "float"
},
"release_date": {
"type": "date"
}
}
}
}
'

Kibana Dev Tools:

json
PUT /my_products
{
"settings": {
"index": {
"number_of_shards": 1,
"number_of_replicas": 1
}
},
"mappings": {
"properties": {
"name": {
"type": "text"
},
"price": {
"type": "float"
},
"release_date": {
"type": "date"
}
}
}
}

ここでは、settingsブロックでシャード数とレプリカ数を、mappingsブロックでname（text型）、price（float型）、release_date（date型）というフィールドを定義しています。マッピングについては後述します。

3.2. インデックスの一覧表示 (GET _cat/indices API)

現在存在するインデックスの一覧を確認するには、_cat/indices APIを使用するのが便利です。_cat APIは、マシンフレンドリーではなく、人間が読みやすい形式で情報を返します。

bash
curl -X GET "localhost:9200/_cat/indices?v"

?vパラメータをつけるとヘッダー（列名）が表示されます。

Kibana Dev Tools:

json
GET /_cat/indices?v

レスポンス例:

health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
yellow open my_first_index ... 1 1 0 0 208b 208b
yellow open my_products ... 1 1 0 0 208b 208b

作成したインデックスが表示されているのが確認できます。yellowはレプリカシャードが割り当てられていない状態、openはインデックスが使用可能な状態、docs.countはドキュメント数を示します。

3.3. インデックスの削除 (DELETE Index API)

インデックスを削除するには、DELETEメソッドを使用し、インデックス名を指定します。

bash
curl -X DELETE "localhost:9200/my_first_index"

Kibana Dev Tools:

json
DELETE /my_first_index

レスポンス例:

json
{
"acknowledged" : true
}

acknowledged: trueとなっていれば、削除リクエストは受け付けられました。再度_cat/indicesを確認すると、インデックスが消えていることがわかります。

注意点: インデックスの削除は元に戻せません。実行には十分注意してください。

4. ドキュメントの管理 (CRUD操作)

Elasticsearchの主要な操作は、インデックスに対するドキュメントの登録（Create/Index）、取得（Read/Get）、更新（Update）、削除（Delete）です。これらの操作をまとめてCRUD操作と呼びます。

4.1. ドキュメントのインデックス作成 (Index API)

ドキュメントをElasticsearchに登録する操作を「インデックス作成（Indexing）」と呼びます。主にPUTまたはPOSTメソッドを使用します。

4.1.1. IDを指定してインデックス作成 (PUT)

ドキュメントのIDを自分で指定してインデックス作成する場合、PUTメソッドを使用します。指定したIDのドキュメントが既に存在する場合は、そのドキュメントが上書き（更新）されます。

bash
curl -X PUT "localhost:9200/my_products/_doc/1" -H "Content-Type: application/json" -d'
{
"name": "Laptop",
"category": "Electronics",
"price": 1200.00,
"stock": 10,
"release_date": "2023-01-15"
}
'

Kibana Dev Tools:

json
PUT /my_products/_doc/1
{
"name": "Laptop",
"category": "Electronics",
"price": 1200.00,
"stock": 10,
"release_date": "2023-01-15"
}

• /my_products: インデックス名
• /_doc: タイプ名（Elasticsearch 7.x/8.xでの標準）
• /1: ドキュメントID（ここで指定）

レスポンス例:

json
{
"_index" : "my_products",
"_type" : "_doc",
"_id" : "1",
"_version" : 1,
"result" : "created", # または "updated"
"_shards" : {
"total" : 2, # プライマリ + レプリカ
"successful" : 2,
"failed" : 0
},
"_seq_no" : 0,
"_primary_term" : 1
}

• _index, _type, _id: 登録されたドキュメントの識別情報。
• _version: ドキュメントのバージョン。変更があるたびに増加します。
• result: 操作の結果。”created”または”updated”。
• _shards: シャードに関する情報。
• _seq_no, _primary_term: 内部的なバージョン管理に使用されるフィールド。

同じID（1）で別のドキュメントをPUTすると、resultがupdatedとなり、_versionが増加します。

4.1.2. IDを自動生成してインデックス作成 (POST)

ドキュメントのIDをElasticsearchに自動生成させる場合、POSTメソッドを使用します。この場合、IDを指定する必要はありません。

bash
curl -X POST "localhost:9200/my_products/_doc" -H "Content-Type: application/json" -d'
{
"name": "Keyboard",
"category": "Electronics",
"price": 75.00,
"stock": 50
}
'

Kibana Dev Tools:

json
POST /my_products/_doc
{
"name": "Keyboard",
"category": "Electronics",
"price": 75.00,
"stock": 50
}

• /my_products: インデックス名
• /_doc: タイプ名

レスポンス例:

json
{
"_index" : "my_products",
"_type" : "_doc",
"_id" : "...", # ここに自動生成されたIDが入る
"_version" : 1,
"result" : "created",
"_shards" : {
"total" : 2,
"successful" : 2,
"failed" : 0
},
"_seq_no" : 1,
"_primary_term" : 1
}

_idフィールドにElasticsearchが生成した一意のIDが入ります。これはタイムスタンプとノードIDなどに基づいて生成されることが多く、重複することはありません。

4.1.3. 作成のみを行う (_create)

IDを指定してインデックス作成する際に、同じIDのドキュメントが既に存在する場合はエラーとしたい場合があります（上書きを防ぎたい場合）。この場合は、_docの代わりに_createエンドポイントを使用します。

“`bash

最初にID:2のドキュメントを作成

curl -X PUT “localhost:9200/my_products/_doc/2” -H “Content-Type: application/json” -d’
{
“name”: “Mouse”,
“category”: “Electronics”,
“price”: 25.00,
“stock”: 100
}
‘

同じID:2で_createを使ってみる -> エラーになるはず

curl -X PUT “localhost:9200/my_products/_create/2” -H “Content-Type: application/json” -d’
{
“name”: “Mouse (Attempt 2)”,
“category”: “Electronics”,
“price”: 30.00,
“stock”: 90
}
‘
“`

Kibana Dev Tools:

“`json
PUT /my_products/_doc/2
{
“name”: “Mouse”,
“category”: “Electronics”,
“price”: 25.00,
“stock”: 100
}

PUT /my_products/_create/2
{
“name”: “Mouse (Attempt 2)”,
“category”: “Electronics”,
“price”: 30.00,
“stock”: 90
}
“`

2回目のPUTリクエストでは、ステータスコード409 Conflictが返され、ドキュメントは上書きされません。

4.2. ドキュメントの取得 (GET API)

特定のIDを持つドキュメントを取得するには、GETメソッドを使用し、インデックス名、タイプ（_doc）、ドキュメントIDをパスに指定します。

既にID 1 で登録したドキュメントを取得してみましょう。

bash
curl -X GET "localhost:9200/my_products/_doc/1"

Kibana Dev Tools:

json
GET /my_products/_doc/1

レスポンス例:

json
{
"_index" : "my_products",
"_type" : "_doc",
"_id" : "1",
"_version" : 1,
"_seq_no" : 0,
"_primary_term" : 1,
"found" : true, # ドキュメントが見つかったか
"_source" : { # 元のドキュメントデータ
"name": "Laptop",
"category": "Electronics",
"price": 1200.00,
"stock": 10,
"release_date": "2023-01-15"
}
}

found: trueであればドキュメントが見つかり、_sourceフィールドに登録したJSONデータが含まれています。ドキュメントが見つからない場合は、found: falseとなり、_sourceフィールドは含まれません。ステータスコードは通常404 Not Foundとなります。

特定のフィールドだけを取得したい場合は、_source_includesまたは_source_excludesパラメータを使用します。

bash
curl -X GET "localhost:9200/my_products/_doc/1?_source_includes=name,price"

Kibana Dev Tools:

json
GET /my_products/_doc/1?_source_includes=name,price

レスポンス例:

json
{
"_index" : "my_products",
"_type" : "_doc",
"_id" : "1",
"_version" : 1,
"_seq_no" : 0,
"_primary_term" : 1,
"found" : true,
"_source" : {
"name": "Laptop",
"price": 1200.00
}
}

4.3. ドキュメントの更新 (Update API)

ドキュメント全体を置き換えるのではなく、一部のフィールドだけを更新したい場合は、POSTメソッドと_updateエンドポイントを使用するのが便利です。これは、既存のドキュメントを取得し、指定された変更を適用し、新しいバージョンとして再インデックスするという内部的な処理を行います。

“`bash

ID:1のドキュメントの在庫数を更新

curl -X POST “localhost:99200/my_products/_update/1” -H “Content-Type: application/json” -d’
{
“doc”: {
“stock”: 5
}
}
‘
“`

Kibana Dev Tools:

json
POST /my_products/_update/1
{
"doc": {
"stock": 5
}
}

リクエストボディのdocフィールド内に、更新したいフィールドとその値を指定します。Elasticsearchは、既存のドキュメントの_sourceとこのdocの内容をマージします。

レスポンス例:

json
{
"_index" : "my_products",
"_type" : "_doc",
"_id" : "1",
"_version" : 2, # バージョンが増加
"result" : "updated",
"_shards" : {
"total" : 2,
"successful" : 2,
"failed" : 0
},
"_seq_no" : 2,
"_primary_term" : 1
}

_versionが2に増え、resultがupdatedとなっています。更新後のドキュメントをGETで取得すると、stockフィールドが5になっていることが確認できます。

更新時には、スクリプトを使用してより複雑な更新を行うことも可能です。例えば、在庫数を現在の値から減らす場合などです。

“`bash

ID:1のドキュメントの在庫数を3減らす

curl -X POST “localhost:99200/my_products/_update/1” -H “Content-Type: application/json” -d’
{
“script”: {
“source”: “ctx._source.stock -= params.quantity”,
“lang”: “painless”,
“params”: {
“quantity”: 3
}
}
}
‘
“`

Kibana Dev Tools:

json
POST /my_products/_update/1
{
"script": {
"source": "ctx._source.stock -= params.quantity",
"lang": "painless",
"params": {
"quantity": 3
}
}
}

scriptフィールド内で、更新処理をPainlessというスクリプト言語で記述します。ctx._sourceは現在のドキュメントのソースデータを参照します。

4.4. ドキュメントの削除 (Delete API)

特定のIDを持つドキュメントを削除するには、DELETEメソッドを使用し、インデックス名、タイプ（_doc）、ドキュメントIDをパスに指定します。

“`bash

ID:2のドキュメントを削除

curl -X DELETE “localhost:9200/my_products/_doc/2”
“`

Kibana Dev Tools:

json
DELETE /my_products/_doc/2

レスポンス例:

json
{
"_index" : "my_products",
"_type" : "_doc",
"_id" : "2",
"_version" : 2, # バージョンが増加して削除が記録される
"result" : "deleted",
"_shards" : {
"total" : 2,
"successful" : 2,
"failed" : 0
},
"_seq_no" : 3,
"_primary_term" : 1
}

resultがdeletedとなっていれば削除成功です。削除されたドキュメントをGETしようとすると、found: falseとなり404レスポンスが返されます。

4.5. 複数ドキュメントの一括操作 (Bulk API)

個別のAPIコールでドキュメントを1つずつ操作するのは非効率です。Elasticsearchは、複数のインデックス作成、更新、削除操作を1つのAPIコールで実行できる_bulk APIを提供しています。これはパフォーマンスが非常に重要です。

_bulk APIは、リクエストボディに特殊な形式のデータ（NDJSON: Newline Delimited JSON）を期待します。各行が1つのJSONオブジェクトであり、改行で区切られます。形式は「アクションメタデータ」の行と「ドキュメント/更新データ」の行がペアになっています。

json
{ "action": { ...meta... } }
{ "document" or "update_data" }
{ "action": { ...meta... } }
{ "document" or "update_data" }
...

アクションはindex, create, update, deleteのいずれかです。

例：複数のドキュメントをインデックス作成、更新、削除

bash
curl -X POST "localhost:9200/_bulk" -H "Content-Type: application/json" -d'
{ "index": { "_index": "my_products", "_id": "3" } }
{ "name": "Monitor", "category": "Electronics", "price": 300.00, "stock": 20 }
{ "create": { "_index": "my_products", "_id": "4" } }
{ "name": "Mousepad", "category": "Accessories", "price": 15.00, "stock": 100 }
{ "update": { "_index": "my_products", "_id": "1" } }
{ "doc": { "price": 1150.00 } }
{ "delete": { "_index": "my_products", "_id": "4" } }
'

Kibana Dev Tools:

json
POST /_bulk
{ "index": { "_index": "my_products", "_id": "3" } }
{ "name": "Monitor", "category": "Electronics", "price": 300.00, "stock": 20 }
{ "create": { "_index": "my_products", "_id": "4" } }
{ "name": "Mousepad", "category": "Accessories", "price": 15.00, "stock": 100 }
{ "update": { "_index": "my_products", "_id": "1" } }
{ "doc": { "price": 1150.00 } }
{ "delete": { "_index": "my_products", "_id": "4" } }

注意点: curlコマンドの-dオプションでNDJSONを渡す場合、改行文字はそのまま含める必要があります。ファイルから読み込む場合は、-d @filenameのようにします。Kibana Dev Toolsでは改行区切りでそのまま貼り付けられます。

レスポンス例:

json
{
"took" : 35,
"errors" : false, # エラーがなければfalse
"items" : [
{
"index" : {
"_index" : "my_products",
"_type" : "_doc",
"_id" : "3",
"_version" : 1,
"result" : "created",
"_shards" : { "total" : 2, "successful" : 1, "failed" : 0 },
"_seq_no" : 4,
"_primary_term" : 1,
"status" : 201 # HTTPステータスコード
}
},
{
"create" : {
"_index" : "my_products",
"_type" : "_doc",
"_id" : "4",
"_version" : 1,
"result" : "created",
"_shards" : { "total" : 2, "successful" : 1, "failed" : 0 },
"_seq_no" : 5,
"_primary_term" : 1,
"status" : 201
}
},
{
"update" : {
"_index" : "my_products",
"_type" : "_doc",
"_id" : "1",
"_version" : 3,
"result" : "updated",
"_shards" : { "total" : 2, "successful" : 1, "failed" : 0 },
"_seq_no" : 3,
"_primary_term" : 1,
"status" : 200 # 更新成功は通常200
}
},
{
"delete" : {
"_index" : "my_products",
"_type" : "_doc",
"_id" : "4",
"_version" : 2, # 削除もバージョンが記録される
"result" : "deleted",
"_shards" : { "total" : 2, "successful" : 1, "failed" : 0 },
"_seq_no" : 6,
"_primary_term" : 1,
"status" : 200 # 削除成功も通常200
}
}
]
}

items配列には、各操作の結果が順番に格納されます。errors: trueの場合、いずれかの操作でエラーが発生しています。その場合、対応するitemの結果にエラー情報が含まれます。Bulk APIは、一部の操作が失敗しても全体の処理は継続されます。

Bulk APIは、大量のデータを取り込む際に非常に効率的です。一度に処理するドキュメント数は、ドキュメントのサイズやネットワーク帯域幅、Elasticsearchノードのリソースなどに応じて調整する必要があります（一般的には数MBから数十MB程度が良いとされます）。

5. マッピングの理解と操作

マッピングは、インデックス内のドキュメントやフィールドがどのように格納され、インデックス化され、検索されるかを定義するスキーマです。フィールドのデータ型や分析方法を指定することで、検索の挙動や精度に大きく影響します。

5.1. マッピングの表示 (GET Mapping API)

インデックスの現在のマッピングを確認するには、GETメソッドを使用し、インデックス名と_mappingエンドポイントを指定します。

bash
curl -X GET "localhost:9200/my_products/_mapping"

Kibana Dev Tools:

json
GET /my_products/_mapping

レスポンス例:

json
{
"my_products" : {
"mappings" : {
"properties" : {
"category" : { # 動的に追加されたフィールド
"type" : "text",
"fields" : {
"keyword" : {
"type" : "keyword",
"ignore_above" : 256
}
}
},
"name" : { # インデックス作成時に定義
"type" : "text"
},
"price" : { # インデックス作成時に定義
"type" : "float"
},
"release_date" : { # インデックス作成時に定義
"type" : "date"
},
"stock" : { # 動的に追加されたフィールド
"type" : "long"
}
}
}
}
}

インデックス作成時に定義したname, price, release_dateフィールドに加え、ドキュメントをインデックス作成した際に初めて出現したcategoryとstockフィールドが、Elasticsearchのダイナミックマッピング機能によって自動的に追加されているのがわかります。categoryはtextとしてインデックス化され、さらにサブフィールドとしてkeywordタイプも追加されています。stockは数値なのでlongとしてマッピングされています。

5.2. マッピングの追加・更新 (PUT Mapping API)

既存のインデックスに新しいフィールドのマッピングを追加したり、既存のフィールドの設定を変更したりするには、PUTメソッドと_mappingエンドポイントを使用します。

ただし、一度設定されたフィールドのデータ型を後から変更することは基本的にできません。 （例外的に、特定の設定は更新可能ですが、型の変更は不可）型の変更が必要な場合は、新しいインデックスを作成し、データをreindex（再インデックス）する必要があります。

新しいフィールドtagsをkeyword型で追加してみましょう。

bash
curl -X PUT "localhost:9200/my_products/_mapping" -H "Content-Type: application/json" -d'
{
"properties": {
"tags": {
"type": "keyword"
}
}
}
'

Kibana Dev Tools:

json
PUT /my_products/_mapping
{
"properties": {
"tags": {
"type": "keyword"
}
}
}

レスポンス例:

json
{
"acknowledged" : true
}

再度マッピングを取得すると、tagsフィールドが追加されていることが確認できます。

5.3. 主なデータ型

Elasticsearchには様々なデータ型があります。主なものをいくつか紹介します。

• text: 全文検索に適した文字列型。分析（単語分割、小文字化など）が行われ、転置インデックスに格納されます。検索時のスコアリングに利用されます。
• keyword: 構造化データ、ID、タグなど、厳密な値の一致検索に適した文字列型。分析は行われず、値全体がそのままインデックス化されます。集計やソートによく使われます。
• integer, long, float, double, scaled_float: 数値型。範囲検索やソート、集計に使用されます。
• date: 日付型。日付/時刻の範囲検索やソート、集計に使用されます。様々な形式で指定できます。
• boolean: 真偽値。
• object: JSONオブジェクトをネストして格納する場合に使用されます。ネストされたフィールドはフラット化されてインデックス化されます。
• nested: オブジェクトの配列を独立したドキュメントのように扱いたい場合に使用されます。オブジェクト内のフィールド間の関連性を維持したい場合に重要です（例えば、ユーザーのリストで、各ユーザーの姓と名がペアになっている場合など）。

text型とkeyword型の違いは非常に重要です。 全文検索したい場合はtext、完全に一致する値を検索したり、値で絞り込み・集計・ソートを行いたい場合はkeywordを選びます。一つのフィールドに対して両方の型でインデックスを作成することもよくあります（例: fieldをtext、field.keywordをkeyword）。

6. 検索の実行 (Search API)

Elasticsearchの最も強力な機能は検索です。_search APIを使用して、インデックス内のドキュメントを検索します。検索はGETまたはPOSTメソッドで実行できます。複雑なクエリをリクエストボディに記述することが多いため、POSTがよく使われます。

6.1. 基本的な検索 (Match All)

インデックス内の全てのドキュメントを検索するには、空のクエリを使用します。

bash
curl -X GET "localhost:9200/my_products/_search"

Kibana Dev Tools:

json
GET /my_products/_search

これはリクエストボディを指定しない形式です。リクエストボディを使う場合は以下のようになります。

bash
curl -X POST "localhost:9200/my_products/_search" -H "Content-Type: application/json" -d'
{
"query": {
"match_all": {}
}
}
'

Kibana Dev Tools:

json
POST /my_products/_search
{
"query": {
"match_all": {}
}
}

queryブロック内に検索条件を記述します。match_allは全てのドキュメントにマッチするクエリです。

レスポンス例 (抜粋):

json
{
"took" : 4, # クエリ実行にかかった時間（ミリ秒）
"timed_out" : false,
"_shards" : { # 検索対象のシャード情報
"total" : 1,
"successful" : 1,
"skipped" : 0,
"failed" : 0
},
"hits" : { # 検索結果
"total" : { # マッチしたドキュメントの総数
"value" : 3,
"relation" : "eq" # valueが正確な総数か（approximateの場合もある）
},
"max_score" : 1.0, # 最もスコアが高いドキュメントのスコア
"hits" : [ # マッチしたドキュメントの配列
{
"_index" : "my_products",
"_type" : "_doc",
"_id" : "1",
"_score" : 1.0, # ドキュメントの関連度スコア
"_source" : {
"name": "Laptop",
"category": "Electronics",
"price": 1150.00, # bulk updateで更新された価格
"stock": 2 # script updateで更新された在庫 (5-3=2)
}
},
{
"_index" : "my_products",
"_type" : "_doc",
"_id" : "3",
"_score" : 1.0,
"_source" : {
"name": "Monitor",
"category": "Electronics",
"price": 300.00,
"stock": 20
}
},
{
"_index" : "my_products",
"_type" : "_doc",
"_id" : "...", # 自動生成されたIDのKeyboardドキュメント
"_score" : 1.0,
"_source" : {
"name": "Keyboard",
"category": "Electronics",
"price": 75.00,
"stock": 50
}
}
]
}
}

hitsブロックが検索結果の本体です。totalはマッチしたドキュメントの総数、hits配列には上位N件のドキュメントが含まれます。各ドキュメントは_index, _id, _score, _sourceなどの情報を持っています。_scoreは検索条件との関連度を示すスコアです。match_allの場合は全てのドキュメントのスコアが1.0になります。

6.2. Query DSL (Domain Specific Language)

Elasticsearchの検索クエリは、Query DSLというJSONベースの言語で記述します。_search APIのリクエストボディのqueryフィールドに指定します。Query DSLは非常に柔軟で強力ですが、ここでは基本的なクエリタイプを紹介します。

Query DSLの基本的な構造は以下のようになります。

json
{
"query": {
"YOUR_QUERY_TYPE": {
"FIELD_NAME": {
"PARAMETER": "VALUE"
}
}
},
"size": 10, # 返すドキュメント数 (デフォルト: 10)
"from": 0, # 開始位置 (ページネーション用)
"sort": [ ... ], # ソート条件
"_source": [ ... ], # 取得するフィールドのフィルタリング
"highlight": { ... }, # ハイライト設定
"aggregations": { ... } # 集計設定
// ... その他様々なパラメータ
}

6.2.1. Full Text Search (Match Query)

文字列フィールドに対して全文検索を行うにはmatchクエリを使用します。入力されたテキストはElasticsearchによって分析され、インデックスされた単語と照合されます。

例：「Laptop」を検索する（nameフィールドはtext型）

bash
curl -X POST "localhost:9200/my_products/_search" -H "Content-Type: application/json" -d'
{
"query": {
"match": {
"name": "Laptop"
}
}
}
'

Kibana Dev Tools:

json
POST /my_products/_search
{
"query": {
"match": {
"name": "Laptop"
}
}
}

もし「Electronic」を検索した場合、categoryフィールド（text型）に含まれる「Electronics」がマッチし、関連性の高いドキュメントが返されます。

bash
curl -X POST "localhost:9200/my_products/_search" -H "Content-Type: application/json" -d'
{
"query": {
"match": {
"category": "Electronic"
}
}
}
'

matchクエリは、検索語句とドキュメントの関連度に基づいてスコアを計算します。

6.2.2. Term Level Queries (Term Query)

termクエリは、分析（Analyzer）を通さずに、指定された単語（Term）とフィールドの値を完全に一致させる検索です。これはkeywordフィールドや数値、日付などに使われます。textフィールドにtermクエリを使うと、意図しない結果になることが多いです。

例：「Electronics」カテゴリのドキュメントを検索する（categoryフィールドのサブフィールドkeywordはkeyword型）

bash
curl -X POST "localhost:9200/my_products/_search" -H "Content-Type: application/json" -d'
{
"query": {
"term": {
"category.keyword": {
"value": "Electronics"
}
}
}
}
'

Kibana Dev Tools:

json
POST /my_products/_search
{
"query": {
"term": {
"category.keyword": {
"value": "Electronics"
}
}
}
}

termクエリは、デフォルトではスコア計算を行いません（_scoreは1.0になります）。主にフィルタリングに使用されます。

6.2.3. Range Query

数値や日付のフィールドに対して、範囲を指定して検索します。

例：価格が100ドル以上500ドル以下のドキュメントを検索する

bash
curl -X POST "localhost:9200/my_products/_search" -H "Content-Type: application/json" -d'
{
"query": {
"range": {
"price": {
"gte": 100.00, # Greater Than or Equal (以上)
"lte": 500.00 # Less Than or Equal (以下)
}
}
}
}
'

Kibana Dev Tools:

json
POST /my_products/_search
{
"query": {
"range": {
"price": {
"gte": 100.00,
"lte": 500.00
}
}
}
}

範囲指定には以下のオプションがあります。

• gt: Greater Than (より大きい)
• gte: Greater Than or Equal (以上)
• lt: Less Than (より小さい)
• lte: Less Than or Equal (以下)

日付フィールドの場合は、日付文字列やnowなどのキーワードを指定できます。

例：2023年1月1日以降にリリースされたドキュメントを検索する

bash
curl -X POST "localhost:9200/my_products/_search" -H "Content-Type: application/json" -d'
{
"query": {
"range": {
"release_date": {
"gte": "2023-01-01"
}
}
}
}
'

6.2.4. Boolean Query

複数のクエリを組み合わせて、より複雑な検索条件を作成するにはboolクエリを使用します。boolクエリは以下の節を持ちます。

• must: この節に含まれる全てのクエリにドキュメントがマッチする必要があります。スコア計算に影響します。AND条件のようなものです。
• filter: この節に含まれる全てのクエリにドキュメントがマッチする必要があります。スコア計算に影響しません。また、頻繁に利用されるクエリ結果がキャッシュされるため、パフォーマンス上有利です。主にフィルタリングに使用されます。
• should: この節に含まれるいずれかのクエリにドキュメントがマッチすれば良いです。マッチしたクエリが多いほどスコアが高くなります。OR条件のようなものです。
• must_not: この節に含まれるいずれのクエリにもドキュメントがマッチしてはいけません。スコア計算に影響しません。NOT条件のようなものです。

例：「Electronics」カテゴリで、価格が100ドル以上のドキュメントを検索する

ここでは、「Electronics」カテゴリは正確な一致（フィルタリング）、価格は範囲指定（フィルタリング）、そして検索結果にはスコアが必要ない（or あっても気にしない）ため、filter節を使うのが適切です。もし「Laptop」または「Monitor」を検索しつつ、カテゴリと価格で絞り込む場合は、shouldとfilterを組み合わせたりします。

bash
curl -X POST "localhost:9200/my_products/_search" -H "Content-Type: application/json" -d'
{
"query": {
"bool": {
"filter": [
{
"term": {
"category.keyword": {
"value": "Electronics"
}
}
},
{
"range": {
"price": {
"gte": 100.00
}
}
}
]
}
}
}
'

Kibana Dev Tools:

json
POST /my_products/_search
{
"query": {
"bool": {
"filter": [
{
"term": {
"category.keyword": {
"value": "Electronics"
}
}
},
{
"range": {
"price": {
"gte": 100.00
}
}
}
]
}
}
}

例：「Laptop」または「Keyboard」を検索し、かつ在庫数が10以上のドキュメント（スコアを計算したい検索と、フィルタリングを組み合わせる）

bash
curl -X POST "localhost:9200/my_products/_search" -H "Content-Type: application/json" -d'
{
"query": {
"bool": {
"should": [ # スコアに影響させたい検索条件
{ "match": { "name": "Laptop" } },
{ "match": { "name": "Keyboard" } }
],
"filter": [ # スコアに影響させたくないフィルタリング条件
{
"range": {
"stock": {
"gte": 10
}
}
}
],
"minimum_should_match": 1 # should節のクエリのうち、最低何個マッチすれば結果に含めるか
}
}
}
'

Kibana Dev Tools:

json
POST /my_products/_search
{
"query": {
"bool": {
"should": [
{ "match": { "name": "Laptop" } },
{ "match": { "name": "Keyboard" } }
],
"filter": [
{
"range": {
"stock": {
"gte": 10
}
}
}
],
"minimum_should_match": 1
}
}
}

minimum_should_matchは、should節が指定されている場合に重要です。これを指定しない場合、should節 のみ が存在しても、他の節（must, filter, must_not）が全く指定されていない場合は、should節の条件にマッチしないドキュメントも結果に含まれる可能性があります。minimum_should_match: 1とすることで、should節のいずれか一つには必ずマッチする必要がある、という条件になります。

クエリコンテキスト vs フィルターコンテキスト:

mustとshould節は「クエリコンテキスト」で実行されます。これは、ドキュメントがクエリにマッチするかどうかに加えて、その関連度（_score）を計算します。転置インデックスとフィールドの統計情報（用語頻度、逆文書頻度など）に基づいてスコアが計算され、結果はスコアの高い順に並べられます。

filterとmust_not節は「フィルターコンテキスト」で実行されます。これは、ドキュメントがクエリにマッチするかどうか（Yes/No）だけを判断し、スコアを計算しません。フィルターコンテキストで実行されるクエリは、結果がキャッシュされるため、繰り返し実行される場合には非常に高速です。主に、結果セットを絞り込むために使用されます。

検索パフォーマンスにおいては、可能な限りfilter節を活用することが推奨されます。

6.3. ページネーション (Pagination)

検索結果はデフォルトで上位10件のみが返されます。それ以上の結果を取得したり、ページングを行ったりするには、sizeとfromパラメータを使用します。

• size: 返すドキュメントの最大数 (デフォルト: 10)
• from: 結果の開始位置 (デフォルト: 0)

例：最初の20件を取得する

json
POST /my_products/_search
{
"size": 20,
"query": {
"match_all": {}
}
}

例：21件目から10件を取得する（2ページ目）

json
POST /my_products/_search
{
"size": 10,
"from": 20,
"query": {
"match_all": {}
}
}

from + sizeの合計が大きくなりすぎると、パフォーマンス上の問題やメモリ消費が増大する可能性があります。深いページングが必要な場合は、search_afterやScroll APIといったより効率的な方法を検討する必要があります（これらは本記事の範囲外とします）。

6.4. ソート (Sorting)

検索結果はデフォルトで_scoreの高い順にソートされますが、特定のフィールドの値でソートすることもできます。sortパラメータにソート条件の配列を指定します。

例：価格の低い順にソートする

bash
curl -X POST "localhost:9200/my_products/_search" -H "Content-Type: application/json" -d'
{
"query": {
"match_all": {}
},
"sort": [
{ "price": { "order": "asc" } } # asc: 昇順, desc: 降順
]
}
'

Kibana Dev Tools:

json
POST /my_products/_search
{
"query": {
"match_all": {}
},
"sort": [
{ "price": { "order": "asc" } }
]
}

ソートには、分析されていないフィールド（keyword, 数値, 日付など）を使用するのが一般的です。textフィールドでソートすると、予期しない結果になることがあります。複数のフィールドでソートすることも可能です。

例：カテゴリで昇順、次に価格で降順にソートする

json
POST /my_products/_search
{
"query": {
"match_all": {}
},
"sort": [
{ "category.keyword": { "order": "asc" } },
{ "price": { "order": "desc" } }
]
}

_scoreでソートする場合は、フィールド名として_scoreを指定します。

json
POST /my_products/_search
{
"query": {
"match": { "name": "Laptop" }
},
"sort": [
{ "_score": { "order": "desc" } }
]
}

6.5. 結果のフィルタリング (_source filtering)

検索結果に含まれる_sourceフィールドから、特定のフィールドだけを取得したり、特定のフィールドを除外したりすることができます。これは_sourceパラメータを使用します。前述のGET APIでも使いましたが、Search APIでも同様に使えます。

例：nameとpriceフィールドだけを取得する

bash
curl -X POST "localhost:9200/my_products/_search" -H "Content-Type: application/json" -d'
{
"_source": ["name", "price"],
"query": {
"match_all": {}
}
}
'

Kibana Dev Tools:

json
POST /my_products/_search
{
"_source": ["name", "price"],
"query": {
"match_all": {}
}
}

例：stockフィールドを除外する

json
POST /my_products/_search
{
"_source": {
"excludes": ["stock"]
},
"query": {
"match_all": {}
}
}

検索結果のサイズを小さくすることで、ネットワーク帯域幅やクライアント側の処理負荷を軽減できます。

6.6. ハイライト (Highlighting)

全文検索を行った際、検索語句がドキュメント内のどこに、どのように出現するかをハイライト表示したい場合があります。highlightパラメータを使用します。

例：「Electronics」を検索し、categoryフィールドでハイライト表示する

bash
curl -X POST "localhost:9200/my_products/_search" -H "Content-Type: application/json" -d'
{
"query": {
"match": {
"category": "Electronics"
}
},
"highlight": {
"fields": {
"category": {}
}
}
}
'

Kibana Dev Tools:

json
POST /my_products/_search
{
"query": {
"match": {
"category": "Electronics"
}
},
"highlight": {
"fields": {
"category": {}
}
}
}

レスポンス例 (Highlight部分抜粋):

json
"hits" : [
{
"_index" : "my_products",
"_type" : "_doc",
"_id" : "1",
"_score" : ...,
"_source" : { ... },
"highlight" : { # ハイライト結果が追加される
"category" : [
"<em>Electronics</em>" # デフォルトでは<em>タグで囲まれる
]
}
},
...
]

ハイライト表示に使用されるタグ（例: <em>）や、表示するテキストの断片数などをカスタマイズできます。

7. 集計 (Aggregations)

Elasticsearchは単なる検索エンジンではなく、強力な分析エンジンでもあります。Search APIのaggregationsパラメータを使用することで、検索結果に対して様々な集計（統計情報、グループ化、ファセットなど）を行うことができます。

集計は大きく分けて以下の種類があります。

• Bucket Aggregations: 条件に基づいてドキュメントをグループ化します（例: カテゴリごとのドキュメント数）。
• Metric Aggregations: ドキュメントのセットに対して統計値を計算します（例: 価格の平均値、最大値）。
• Pipeline Aggregations: 他の集計の結果に対して計算を行います（例: 日ごとの売上合計の移動平均）。

ここでは最も基本的なBucket Aggregationであるterms集計を使って、カテゴリごとのドキュメント数を算出してみましょう。

bash
curl -X POST "localhost:9200/my_products/_search" -H "Content-Type: application/json" -d'
{
"size": 0, # 検索結果のドキュメント自体は不要なので0件にする
"query": {
"match_all": {} # 全てのドキュメントを集計対象にする
},
"aggs": { # aggregations のエイリアス
"products_by_category": { # 集計の名前 (任意)
"terms": { # 集計タイプ: terms aggregation (値ごとのバケットを作成)
"field": "category.keyword" # 集計対象フィールド (keyword型が適している)
}
}
}
}
'

Kibana Dev Tools:

json
POST /my_products/_search
{
"size": 0,
"query": {
"match_all": {}
},
"aggs": {
"products_by_category": {
"terms": {
"field": "category.keyword"
}
}
}
}

size: 0は、検索結果のドキュメント自体は不要で、集計結果だけが必要な場合に指定します。パフォーマンス向上につながります。

レスポンス例 (Aggregations部分抜粋):

json
"aggregations" : {
"products_by_category" : { # 集計の名前
"doc_count_error_upper_bound" : 0,
"sum_other_doc_count" : 0,
"buckets" : [ # 集計結果のバケット（グループ）
{
"key" : "Electronics", # バケットのキー（値）
"doc_count" : 3 # その値にマッチするドキュメント数
},
{
"key" : "Accessories",
"doc_count" : 1
}
]
}
}

aggregationsブロックに、リクエストで指定した名前（products_by_category）で結果が含まれています。buckets配列には、カテゴリごとの集計結果（key: カテゴリ名、doc_count: ドキュメント数）が含まれます。

集計は非常に奥が深く、様々な種類の集計を組み合わせることで、複雑なビジネス要件に基づいた分析を行うことができます。

8. その他の便利なAPI (_cat APIs, Cluster Health)

Elasticsearchには、インデックスやクラスターの状態を簡単に確認できる_cat API群や、クラスター全体の健全性を確認できる_cluster/health APIなど、多くの便利なAPIがあります。

8.1. Cluster Health API

クラスター全体の健全性を確認できます。

bash
curl -X GET "localhost:9200/_cluster/health"

Kibana Dev Tools:

json
GET /_cluster/health

レスポンス例 (抜粋):

json
{
"cluster_name" : "your_cluster_name",
"status" : "yellow", # green, yellow, red
"timed_out" : false,
"number_of_nodes" : 1,
"number_of_data_nodes" : 1,
"active_primary_shards" : 2,
"active_shards" : 2, # プライマリ + レプリカの合計
"relocating_shards" : 0,
"initializing_shards" : 0,
"unassigned_shards" : 2, # レプリカが割り当てられていないシャード数 (status=yellowの原因)
...
}

statusはクラスターの健全性を示します。

• green: 全てのプライマリシャードとレプリカシャードが割り当てられ、正常に動作している状態です。
• yellow: 全てのプライマリシャードは割り当てられているが、一部または全てのレプリカシャードが割り当てられていない状態です。検索は可能ですが、冗長性が失われています。
• red: 一部または全てのプライマリシャードが割り当てられていない状態です。そのインデックスの一部または全体が利用できません。

yellowになる原因の多くは、レプリカシャードを格納するための十分なノードがない場合です。

8.2. _cat API群

人間が読みやすい形式で各種情報を提供するAPI群です。?vパラメータでヘッダーを表示させると見やすいです。

• GET /_cat/indices: インデックスの一覧とその統計情報
• GET /_cat/nodes: ノードの一覧とその情報
• GET /_cat/shards: シャードの割り当て情報
• GET /_cat/health: クラスターの健全性サマリ (health APIと同じ情報を見やすく)
• GET /_cat/allocation: 各ノードへのシャード割り当て状況

これらのAPIは、クラスターの状態監視やトラブルシューティングに役立ちます。

9. エラーハンドリングの基本

Elasticsearch APIは標準的なHTTPステータスコードを返します。

• 200 OK: リクエスト成功（GET, PUT/Indexで更新, POST/_update, DELETEなど）
• 201 Created: リクエスト成功、新しいリソースが作成された（PUT/Indexで新規作成, POST/Indexなど）
• 400 Bad Request: リクエストの形式が不正など、クライアント側のエラー
• 404 Not Found: 指定したリソース（インデックス、ドキュメントなど）が見つからない
• 409 Conflict: バージョン競合など、リソースの状態とリクエストが衝突
• 500 Internal Server Error: Elasticsearch内部でのエラー

リクエストが失敗した場合、レスポンスボディにはエラーの詳細が含まれていることが多いです。

例：存在しないインデックスのドキュメントを取得しようとする

bash
curl -X GET "localhost:9200/non_existent_index/_doc/1"

レスポンス例:

json
{
"error" : {
"root_cause" : [
{
"type" : "index_not_found_exception",
"reason" : "no such index [non_existent_index]",
"resource.type" : "index_or_alias",
"resource.id" : "non_existent_index",
"index_uuid" : "_na_",
"index" : "non_existent_index"
}
],
"type" : "index_not_found_exception",
"reason" : "no such index [non_existent_index]",
"resource.type" : "index_or_alias",
"resource.id" : "non_existent_index",
"index_uuid" : "_na_",
"index" : "non_existent_index"
},
"status" : 404 # ステータスコードは404
}

errorブロック内のtypeやreasonを確認することで、エラーの原因を特定できます。

10. Kibana Dev Toolsの活用

記事の冒頭でも触れましたが、Elasticsearch APIを試す上で、KibanaのDev Toolsは非常に強力なツールです。Webブラウザからアクセスでき、整形されたレスポンス、オートコンプリート機能、履歴機能などが備わっています。

Kibanaの左側メニューから「Dev Tools」を選択するとコンソールが開きます。左ペインにAPIリクエストを記述し、右ペインにレスポンスが表示されます。

“`json

リクエストはHTTPメソッドから書く

GET /_cat/indices?v

複数のリクエストをまとめて実行できる（改行区切りで選択）

PUT /my_test_index

POST /my_test_index/_doc
{
“message”: “Hello Dev Tools”
}

GET /my_test_index/_search
{
“query”: {
“match_all”: {}
}
}

DELETE /my_test_index
“`

curlコマンドは自動化スクリプトなどには適していますが、手動でAPIを試したり学習したりする際には、Dev Toolsの利用を強く推奨します。

11. 次のステップ

本記事では、Elasticsearch APIの最も基本的な使い方を解説しました。しかし、Elasticsearchの機能はこれにとどまりません。次に学習を進める上で重要なトピックをいくつか紹介します。

• 高度な検索: More Like Thisクエリ、Spanクエリ、Suggest API、地理空間検索、親-子関係検索など。
• 高度な集計: サブ集計、メトリック集計の組み合わせ、パイプライン集計、行列集計など。
• Analyzer: テキストフィールドのインデックス作成・検索時の分析方法（形態素解析、N-gramなど）をカスタマイズする。日本語など言語によって重要になります。
• Alias: インデックスに別名をつけ、アプリケーションからインデックス名を意識せずに操作できるようにする。ゼロダウンタイムでのインデックス更新などに使用します。
• テンプレート: 新しいインデックスが作成される際にデフォルトで適用される設定やマッピングを定義する。
• Reindex API: 既存のインデックスから新しいインデックスへデータをコピーする。マッピング変更やデータ構造変更の際に利用します。
• Snapshot/Restore API: クラスターやインデックスのバックアップと復元。
• Security API: ユーザー認証、ロール、権限管理。
• クライアントライブラリ: Java, Python, Ruby, Goなど、様々なプログラミング言語向けの公式およびコミュニティ製クライアントライブラリ。これらのライブラリを使うと、APIコールをよりプログラム的に扱いやすくなります。

まとめ

Elasticsearchは、RESTful APIを通じてその強力な検索・分析機能を余すことなく提供しています。本記事では、そのAPIの基本中の基本として、インデックスの管理、ドキュメントのCRUD操作（インデックス作成、取得、更新、削除、一括操作）、マッピングの概念と操作、そして検索API（Query DSLの基本的なクエリタイプ、ページネーション、ソート、集計の基本）について詳しく見てきました。

これらの基本的なAPIを使いこなせるようになれば、Elasticsearchにデータを投入し、意図した通りに検索・取得するといった最も基本的なタスクを実行できるようになります。これがElasticsearch活用の土台となります。

Elasticsearchの世界は非常に広大で、ここに紹介できたのはその表面的な部分に過ぎません。しかし、ここでの学びを足がかりに、さらに高度な機能やAPIへと学習を進めることで、より洗練された検索アプリケーションやデータ分析基盤を構築できるようになるはずです。

是非、実際にElasticsearchインスタンスを立ち上げ、curlやKibana Dev Toolsを使って、この記事で紹介したAPIを自身の手で実行してみてください。理論だけでなく、実際にコマンドを叩いてレスポンスを確認することが、理解を深める最も良い方法です。

Elasticsearch APIの学習、お疲れ様でした！この解説が、あなたのElasticsearch活用の第一歩を踏み出す助けとなれば幸いです。