RAGとJevで「ベクトルDBに根拠となる答えがない」ことを見分ける仕組みを作った話 はじめに こんにちは。1か月間のインターンで、サーバーサイド（Go）を担当した橋本です。 インターンでは、AIエージェントの機能追加の設計・実装に携わりました。この記事では、その中でもRAG（Retrieval-Augmented Generation）の検索の部分に焦点を当てます。RAGは、質問に関係する文書を探してLLMに渡し、その文書をもとに回答を作成する仕組みです。ここではデリッシュキッチンの情報を検索し、AIの回答の根拠として使えるかどうかを検討しました。 作ってみて一番難しかったのは、「ベクトルDBに根拠となる答えがないことをどのように見分けるか」でした。関係の薄い情報をLLMに渡してしまうと、LLMはそれをもとにもっともらしいが正確ではない回答を生成してしまう可能性があります。よってベクトルDBに根拠となる情報が無い場合は、LLMに回答させないようにする必要があります。 この記事では、次の2つのトピックに絞ります。 HYBRIDとANNという2つの検索を組み合わせて、候補を絞る仕組み 絞った候補が質問に答えているかを、TypeSafeのAIモデルJevで文書ごとに判定する仕組み HYBRIDとANNはベクトルDBに対する検索方式で、具体的なアルゴリズムは後述します。 最後に、これらの手法についてローカルで計測した結果も記述しています。なお、以下に出てくる質問や文書の例は、説明のために作ったものです。 全体の流れ 前提として、ベクトルDBとインデックスはDatabricksのAI Searchというサービスにてホストされており、バックエンドサーバーからベクトルDBに対して直接リクエストするような形式を取っています。 またインデックスは、文書を段落レベルの単位（チャンク）に分けた上で埋め込みベクトルを生成しています。 処理の全体像は以下の通りです。 検索方式を決めるまで インターンで一番やりがいを感じたのは、この検索方式を決めるところでした。自分の考えを特に多く入れられた部分でもあるので、どう考えて今の形に落ち着いたのかを書きたいと思います。検索方式は何度か変わり、HYBRIDから始めてANNに移り、最後に両方を組み合わせる形になりました。 欲しかった候補 例えば「ハンバーグの焼き時間は？」と聞かれたとします。候補に来てほしいのは、「ハンバーグの作り方」のようなハンバーグについての文書です。「鶏むね肉のソテーの焼き時間」のような、別の料理の焼き時間の文書ではありません。 ベクトルの近さだけで探すと、別の料理の文書でも質問と同じく「焼き時間」について書かれていれば上位に来るおそれがありました。そこで最初は、HYBRIDを使うことを考えました。HYBRIDはベクトルの近さとキーワードの一致を合わせて並べるので、「ハンバーグ」という言葉が入った文書が上位に来やすく、聞かれている対象を外しにくくなります。 HYBRID単体では根拠となる回答があるかを判断できない HYBRIDを使う場合、scoreが閾値より低ければ「答えが無い」と判定するつもりでした。ところが、設計を詰める中で、HYBRIDではこの判定が難しいことに気づきました。 HYBRIDは、ベクトル検索とキーワード検索の結果を、Reciprocal Rank Fusion（RRF）で1つにまとめる検索です。DatabricksのAI Searchでは、チャンクxについて次の値を計算します（rankは、それぞれの検索でのxの順位で、1位を1と数えます。60はRRFの定数kで、AI Searchでは60です）。 AI Searchが返すscoreは、この値を取りうる最大値で割り、最大が1になるようにしたものです。一定の値で割るだけなので、scoreが順位で決まることは変わりません。 このように、HYBRIDのscoreは2つの検索の 順位 から計算するので、検索語とチャンクがどれだけ近いかの目安にはなりません。インデックスの文書がどれも質問と関係なくても、上位の文書には、順位に応じた高いscoreが付きます。そのためscoreを見ても、答えのある文書があるのか、関係のない文書しか無いのかを区別できません。 ANNと、見出しを足した埋め込み 次に、ANN（ベクトルの近さだけで探す検索）に切り替えました。AI SearchのANNは、検索語のベクトルqとチャンクのベクトルxの距離（ユークリッド距離）から、次の式でscoreを計算します。 ‖q − x‖ はqとxのユークリッド距離です。距離が0ならscoreは1になり、遠いほど小さくなります。使っているOpenAIの埋め込みは長さ1に正規化されているので、距離は最大でも2になり、実際のscoreは0.2〜1の間に収まります。 HYBRIDでは、どの文書も関係なくても上位に高いscoreが付きますが、ANNでは、どのチャンクも遠ければscoreも低いままです。ANNのscoreは検索語とチャンクの近さそのものなので、閾値を付けられます。残った心配は、聞かれている対象を外すことです。この点をインデックスの側で補うために、埋め込む文を工夫しました。 RAGでは、文書を段落のような小さな単位（チャンク）に分け、チャンクごとにベクトルにするのが一般的です。文書全体を1つのベクトルにすると、そのベクトルはいろいろな関心事を含み、細かい質問に対応しくくなってしまいます。 ただ、チャンクに分けると、今度は文脈が抜け落ちます。文書の中ではタイトルや見出しが何について書かれているかを示していますが、段落だけを切り出すと、その手がかりが無くなります。例えば、次の段落があるとします。 中火で 5 分ほど焼き、裏返してふたをします。 この段落だけでは、何を焼くのかが分かりません。同じ文書のタイトルが「ハンバーグの基本の作り方」で、段落が「焼き方」という見出しの下にあれば、「ハンバーグは中火で5分ほど焼く」という内容だと分かります。もし段落だけをベクトルにすると、「ハンバーグ」や「焼き方」で聞かれてもこの段落はヒットしないでしょう。 そこで、埋め込む文には、チャンクの本文の前に、文書のタイトルと、そのチャンクが属する見出しをつなげて入れました。 文書のタイトル / 見出し / チャンクの本文 見出しが何階層かある文書では、チャンクのすぐ上にある見出しだけでなく、それより上の階層の見出しまでつなげます。すぐ上の見出しだけでは、上の階層が示す文脈（「作り方」なのか「アレンジ」なのか）が抜け落ちるからです。 HYBRIDとANNの並行 ただ、見出しを足しても、ANNが見ているのはあくまでベクトルの近さです。固有の料理名や略語のように、言葉がそのまま一致するかどうかが決め手になる質問では、近さだけだと、似た話題の別の文書が上位に来るおそれが残りました。一方で、「答えが無い」を見分けるための閾値には、近さそのものを表すANNのscoreが要ります。 そこで、自分が出した案をもとにチームで相談して、2つを組み合わせる形に決めました。並べ替えはキーワードの一致も使えるHYBRIDに、明らかに遠い候補を閾値で落とすのは近さそのものをscoreで返すANNに任せます。インデックスに入れる見出しの工夫は、そのまま残しています。 具体的には、2つを並行に問い合わせ、HYBRIDの結果のうち、ANNの閾値を通ったチャンクを持つ文書のものだけを残します。次のコードは、説明のために簡略化したものです。 // HYBRID と ANN（閾値つき）を並行に問い合わせる。片方が失敗したら、もう片方も止める var annHits, hybridHits []*Hit g, gctx := errgroup.WithContext(ctx) g.Go( func () (err error ) { annHits, err = index.Query(gctx, annQuery); return }) g.Go( func () (err error ) { hybridHits, err = index.Query(gctx, hybridQuery); return }) if err := g.Wait(); err != nil { return nil , err } // annQuery に閾値を付けてあるので、annHits には閾値を通ったチャンクだけが入っている。 // そのチャンクを持つ文書を「近い」とみなす near := map [ int64 ] struct {}{} for _, h := range annHits { near[h.DocID] = struct {}{} } // HYBRID の結果は、近い文書のものだけを残す（並び順は HYBRID のまま） hits := make ([]*Hit, 0 , len (hybridHits)) for _, h := range hybridHits { if _, ok := near[h.DocID]; ok { hits = append (hits, h) } } 文書の単位で照らし合わせているのは、ANNとHYBRIDでは、同じ文書でも別のチャンクが返ってくることがあるからです。 自分で作ったベクトルを入れるインデックスでもHYBRIDを使えるかは、Databricksのドキュメントからは分からなかったので、ローカルで試して動くことを確かめました。ただ、少数の質問でANNだけの場合と比べたところ、最終の結果にはほとんど差が出ませんでした（後の「ローカルで試した結果」で詳しく記述しています）。HYBRIDを足した効果はまだ言い切れないので、設定でANNだけの形にも切り替えられるようにしました。 文書ごとのまとめ インデックスから返ってくるのはチャンクの単位です。そこで、同じ文書から来たチャンクを1つの候補に束ね、文書のscoreは、その文書のチャンクの（HYBRIDの）scoreの最大値にします。このscoreは候補を並べる順番にだけ使い、上位10文書を判定にかけます。判定を通った文書からも、この順番のまま上位3文書を選びます。 同じ話題だが答えていない文書 ここまでで、明らかに意味が異なる候補は落とすことができます。 ただ、同じ話題だが質問の回答にはならない文書を完全に落とすことはまだできていません。 例えば「ハンバーグの焼き時間は？」と聞かれ、インデックスには「ハンバーグの由来」を紹介する文書しかないとします。この文書は焼き時間には答えていませんが、ハンバーグについて書かれているので、チャンクのベクトルは検索語のベクトルに近くなります。ANNの閾値を厳しくすれば落とせるかもしれませんが、そうすると今度は、答えている文書まで落ちてしまいます。 考えた案は次の3つでした。 案 結論 理由 ANNの閾値を厳しくする 見送り 答えている文書まで落ちる。閾値だけでは、同じ話題だが答えていない文書を分けられない 質問と文書の主題が一致するかを見る 見送り 主題が一致していても、聞かれたこと（焼き時間）が書かれているとは限らない 文書ごとにAIモデルで判定する 採用 この文書はこの質問に答えているかを、直接聞ける 最終的にチームで決めたのは、ANNの閾値で明らかに遠いものを落とし、残った上位10文書をAIモデルで判定する形です。 従来のLLMでは推論速度に少なからず影響が出るのが懸念だったのですが、Jevを使用すれば比較的影響を少なく実装できると思い、今回試してみることになりました。 Jevで文書ごとに判定する Jevとnoul型 判定にはTypeSafeのJevを使いました。Jevは従来のLLMのようなテキスト生成をするのではなく、高速かつ型安全なデータ構造を出力することに特化した新しいAIモデルです。今回はCloudflareのWorkers AIのAPIから呼びだしています。 Jevに渡す問い（ questions ）の型にはいくつかあり、今回は noul を選択しました。 noul は、trueとfalseの基準を渡すと、trueに当たる確率を0〜1の数で返します。答えているかどうかを確率で受け取れるので、判定の閾値を後から調整できます。 判定に渡すもの 1文書ごとに、次の形でリクエストを送ります（文言は簡略化し、一般的な言い方に直しています）。 { " model ": " typesafe/jev ", " input ": { " state ": " 質問: ハンバーグの焼き時間は？ \n タイトル: …… \n\n [大見出し / 中見出し] \n 本文の段落…… \n\n [大見出し / 中見出し] \n 本文の段落…… ", " questions ": { " answers_question ": { " type ": " noul ", " instructions ": " You decide whether the blocks in the state answer the user's question. ... Use the headings only to understand where each block sits; do not count a heading alone as an answer. ", " criteria ": { " true ": " The text of the blocks alone answers the question, at least in part. ", " false ": " The blocks are about the same topic but do not answer the specific thing that was asked, or they are about something else. " } } } } } state に判定の材料（質問と、見出し付きのチャンク）を、 questions に何を判定させるかを入れます。 工夫したのは次の4点です。 渡すのは、その文書のチャンクのうち、検索のscoreが高い上位3つだけです。文書全体を渡すと長くなり、判定も遅くなるからです。答えが書かれた段落は質問と内容が近いので、上位3つに入っているはずだと考えました チャンクには見出しも付けて渡しますが、見出しはその段落が文書のどこにあるかを示す手がかりとしてだけ使うよう、指示に書きました。例えば見出しに「焼き時間」とあっても、本文に焼き時間が書かれていなければ、答えているとは数えません falseの基準には、「同じ話題だが、聞かれたことには答えていない」場合をはっきり書きました。ANNの閾値（ベクトルの近さ）で落とせずに残るのは、まさにこういう文書だからです 広い質問は別に扱います。「ハンバーグについて教えて」のような質問なら、ハンバーグを説明している文書は答えていると数える、と指示に書きました。これが無いと、広い質問では「具体的なことに答えていない」として落ちかねません 返ってきた確率が判定の閾値（今は仮で0.5）以上なら、答えているとします。 ローカルで試すと、同じ文書でもANNとHYBRIDでは当たるチャンクが違い、判定に渡す3チャンクが変わる文書が58件ありました。それらの文書で、ANNだけのときとHYBRID＋ANNのときのJevの確率の差は、中央値で0.01でした。渡すチャンクが多少変わっても、判定はほとんど変わらないようです。ただし、差が最大で0.61開いたものもあり、0.5をまたいで、通るかどうかが逆になったものが2件ありました。 並行判定とやり直し 10文書は並行して判定します。1文書ずつ順番に呼ぶと、待ち時間が文書の数だけ積み重なるからです。どれか1つの判定でエラーが起きても、その文書を判定できなかったものとして扱うだけで、ほかの文書の判定はそのまま続けます。前処理のHYBRIDとANNの問い合わせでは、片方が失敗したら両方を止めるerrgroupを使いましたが、ここでは1つの失敗でほかを止めたくないので、sync.WaitGroupを使っています。 // 1 文書の判定結果。判定できなかったときは Err に入れ、他の文書は止めない type Verdict struct { Probability float64 // 「答えている」の確率 Err error } // 文書ごとの失敗は Verdict.Err で返すので、ここでは常に nil を返す func (j *JevJudge) Judge(ctx context.Context, query string , docs []*Candidate) ([]*Verdict, error ) { verdicts := make ([]*Verdict, len (docs)) var wg sync.WaitGroup for i, d := range docs { wg.Go( func () { // Go 1.25 の sync.WaitGroup.Go p, err := j.judgeOne(ctx, query, d) verdicts[i] = &Verdict{Probability: p, Err: err} }) } wg.Wait() return verdicts, nil } Jevの判定1回にかかる時間は中央値で247 msでした。並行にしたので、判定の段階は数百msで終わっています。 判定でエラーが起きた文書は、最後に選ぶ3文書がまだそろわず、時間も残っているときに限り、1回だけ判定をやり直します。一方、答えていないと判定された文書はやり直しません。エラーと違って、判定そのものはできているからです。 判定の結果から、返すものは次の3通りに決まります。 判定の結果 返すもの 答えている文書が1つ以上ある その文書（上位3つまで） すべての文書が「答えていない」と判定された 「答えが無い」 答えている文書が無く、判定できなかった文書が残った エラー 3つ目を「答えが無い」にしないのは、判定できなかった文書に答えが書かれているかもしれないからです。その場合に「答えが無い」と返すと、実際には答えがあるのに無いと伝えてしまいます。 閾値の決め方と、ローカルで試した結果 ANNの閾値と判定の閾値は、今は仮の値です。どちらの値にも同じトレードオフがあります。厳しくすると、答えが無い質問では正しく0件にできる代わりに、答えがある質問では正しい文書まで落としてしまいます。 そのため、評価では次の2つを分けて測ります。 指標 測るもの 検索の正しさ 正解の文書が上位3文書に入るか 答えが無い質問 答えが無い質問で、正しく0件になるか RAGの評価では、LLMが渡された文書のとおりに答えを書けているかを測ることがよくあります。ただ、これだけでは検索の失敗が見えません。 例えば「ハンバーグの焼き時間は？」に対して、検索が鶏むね肉のソテーの文書を渡してしまったとします。LLMがその文書のとおりに「片面3分ずつです」と答えれば、文書に忠実なので、この測り方では満点になります。しかし、ユーザーが聞いたのはハンバーグの焼き時間なので、答えとしては間違いです。そのため、検索が正しい文書を選べているか（上の表の「検索の正しさ」）は、別に測る必要があります。 評価に使う質問には、答えが文書に書かれている質問、どの文書にも答えが無い質問、答えが一部にしか書かれていない質問の3種類を混ぜます。なお、評価のために外部のサービスであるJevへ送るのは、ユーザーが実際に送った質問ではなく、評価用に作った質問だけです。 ローカルで試した結果 評価用に作った15問、Jev判定なしと判定ありの差を比べました。Jevで判定すると、答えが無い質問の多くで、正しく「答えが無い」と返せるようになりました。その代わり、答えがある質問12問のうち1〜2問では、文書を全部落としてしまいました。 答えが無い質問に文書を返してしまった（5問中） 答えがある質問で文書を全部落とした（12問中） 判定なし 5 0 Jevで判定（ANNだけ） 1 1 Jevで判定（HYBRID＋ANN） 1 2 どちらの列も、数が少ないほど良い結果です。 今回はどの組み合わせでもANNの閾値を0にしていたので、閾値では何も落ちません。そのため判定なしの場合は、どんな質問にも上位3文書がそのまま返り、答えがある質問では12問すべてで文書が残りました。一方で、「明日の東京の天気は？」「スマホの電池を長持ちさせる方法は？」のような、インデックスのどの文書とも関係のない質問にも文書を返してしまいました。 Jevで判定すると、答えが無い質問5問のうち4問で、正しく「答えが無い」と返せました。一方、答えがある質問でも、文書が1つも残らないものが、ANNだけで1問、HYBRID＋ANNで2問ありました。そのうちの1つは、「薄力粉と強力粉の違いは？」のような、2つのものの違いを聞く質問です。インデックスには薄力粉の文書と強力粉の文書が別々にあり、どちらも1つだけでは違いに答えていないので、両方とも落ちました。文書を1つずつ判定する作りの弱みで、複数の文書にまたがる質問には別の扱いが要ります。 ANNだけとHYBRID＋ANNの差は、今回はほとんど出ませんでした。判定にかける上位10文書は、一部が入れ替わっているだけでした。それでも、最終の結果が違ったのは1問だけで、それも判定に渡したチャンクの違いによるものでした。 推論速度の中央値は次のとおりです。 段階 時間（中央値） 検索語の埋め込み 145 ms 検索（ANNだけ） 213 ms 検索（HYBRID＋ANN） 242 ms HYBRID＋ANNは2本を並行に問い合わせるので、ANNだけとの差は30 msほどです。判定の段階は、前に書いたとおり数百msです。 この結果には、次の注意点があります。 質問は評価用に作ったもので、実際のユーザーの質問ではありません 閾値は仮の値です（判定は0.5、ANNは0）。ANNの閾値で遠い候補を落とす効果は、まだ測れていません 学んだこと HYBRIDのscoreは「近さ」ではない。 順位から作った値は並べ替えには使えても、答えの有無を閾値で見分けるのには使えません。scoreが何から計算されているかを確かめてから使う必要がある。 ベクトルの近さで分かるのは「意味が近いか」まで。 「聞かれたことに答えているか」は、近さとは別の問い。 判定の結果は確率で受け取る。 はい／いいえで受け取ると、閾値を動かせません。Jevの noul のように確率で返すものを使えば、評価を見ながら調整できます 文書ごとの判定は、複数の文書にまたがる質問に弱い。 「AとBの違い」のような質問は、1つの文書だけでは答えられないので、文書が全部落ちることがあります おわりに RAGの「根拠となる答えが無い」ことをどう見分けるかは、作る前に思っていたよりずっと奥が深い問題でした。 1か月のインターンで、検索方式の選び方から判定の仕組みまで自分で案を考えて提案し、チームと相談しながら形にできました。評価では、判定を足すと、答えが無い質問の多くを排除できる傾向も見えました。 一方で、答えがある質問でも、文書を全部落とす場合があることや、複数の文書にまたがる質問に弱いことも分かりました。さらに質問を増やした評価は、これからの課題です。 お忙しい中、レビューをしてくださり、相談にも乗ってくださった 配属先のチームの皆さん、特に岩崎さん、ありがとうございました。

本記事は 2026 年 10 月 27 日 に公開された「 Introducing time series collections for the next generation of Amazon OpenSearch Serverless 」を翻訳したものです。 本日、Amazon OpenSearch Serverless NextGen が時系列コレクションに対応したことを発表します。時系列コレクションを使えば、クラスターのプロビジョニングや管理をせずに、ログ、メトリクス、トレース、イベントデータを取り込み、保存、分析できます。時系列コレクションは取り込みのスパイクを自動で吸収し、直近のデータは高速にクエリでき、数か月から数年分の履歴も低コストで検索可能にします。これらすべてを同じコレクション内で実現します。時系列コレクションは OpenSearch Serverless にアラートと異常検知も追加するため、問題が起きた瞬間に発見して対処できます。コレクションあたり最大 100 TB のホットストレージをサポートし、アプリケーション監視、セキュリティ分析、IoT テレメトリなど大規模なオブザーバビリティワークロードに対応します。 オブザーバビリティデータは量が多く、不具合のあるデプロイや障害など、チームが最も早く答えを求める瞬間に急増します。クラスターのサイジングが不足すると処理が追いつかず、エンジニアが待っているログの到着が遅れるため、チームはピーク負荷に合わせてサイジングし、それ以外の日もその容量分を支払うことになります。履歴が増えるとホットストレージの費用がかさむため、保持期間を短縮したり、古いデータをスナップショットに移したりせざるを得ません。しかしスナップショットからクエリするには、まず誰かが復元する必要があります。クラスターには継続的なチューニングと容量計画も必要で、本来データが支援するはずの調査からエンジニアを引き離してしまいます。あらゆる判断がコスト、保持期間、システムへの疑問に答えるまでの速度のトレードオフになります。 OpenSearch Serverless の時系列コレクションはトレードオフを取り除きます。インシデントでログ量が急増しても、コンピュートが数秒でスケールして追従するため、エンジニアが待っているログは時間通りに届きます。トラフィックが落ち着けばコンピュートはゼロまでスケールダウンするため、ピーク時の容量に支払い続ける必要はありません。古いデータは低コストのウォーム層に移動しますがクエリは可能なので、保持期間を縮めたりスナップショットを復元したりせずに数年分の履歴を保てます。サイジングやチューニングが必要なクラスターはありません。コンピュートの上限といくつかのインデックス設定を指定すれば、あとはサービスが処理します。 クエリ頻度の低いデータは低コストで 時系列データへのクエリの大半は直近数時間から数日を対象としますが、古いデータはクエリ頻度こそ低いものの、引き続き利用可能にしておく必要があります。新しい index.warm.after 設定で、データがホット層に留まる期間を指定し、低コストのウォーム層へ移動するタイミングを決められます。日単位または時間単位で指定でき、最小 1 日 ( 24h または 1d ) から最大 10 年 ( 3650d ) までの範囲で、インデックスの保持期間を超えることはできません。未指定の場合、データは 1 日後にウォーム層へ移動します。 PUT /app-logs { "settings": { "index.warm.after": "7d" } } 取り込み時、各ドキュメントは低レイテンシーのホット層と Amazon Simple Storage Service (Amazon S3) の両方に書き込まれます。データが指定した経過期間に達すると、古いものから順にホットコピーが解放され、データは Amazon S3 上のウォーム層に残ります。クエリでウォーム層のデータが必要になると、サービスがそのデータをホット層に読み戻して処理します。該当データへの最初のクエリは時間がかかりますが、同じデータへの以降のクエリはホット層のレイテンシーで実行されます。古いデータに対する調査やレポート作成のように、同じ時間範囲を繰り返しクエリする用途に適しています。クエリが両方の層にまたがる場合も、結果は 1 つのレスポンスで返ります。ホットストレージの料金は、ホット層に残っているデータ分だけ発生します。 図 1: データは 7 日後にホット層からウォーム層へ移動し、全期間を通じて Amazon S3 に永続化される ワークロードが必要とする期間だけデータを保持 保持期間はインデックス自体に設定するため、別途ライフサイクルポリシーを作成・維持する必要はありません。インデックステンプレートで index.data.retention を設定すれば、パターンに一致するすべてのインデックスがその設定を継承します。1 日から 3,650 日 (10 年) までの範囲で、日数の整数で指定します。 PUT /_index_template/app-logs { "index_patterns": ["app-logs*"], "template": { "settings": { "index.data.retention": "30" } } } 階層管理と保持期間は独立しています。階層管理はクエリ速度とコストを制御し、保持期間はデータが削除されるタイミングを制御します。たとえばアプリケーションログは 7 日間ホット層に置いて 30 日間保持する、あるいはコンプライアンス要件に合わせて監査データを数年間ウォーム層に残す、といった運用が可能です。監査が必要になったら、同じコレクション内で履歴をクエリするだけで、検索コンピュートが追加負荷に合わせてスケールアップします。スナップショットの復元も、調査用クラスターの立ち上げも不要です。 図 2: データの階層管理と保持期間 インデックスごとにイベントタイムスタンプを指定 時系列コレクション内のすべてのドキュメントには、タイムスタンプフィールドが必須になりました。各インデックスには、サービスがデータの整理とソートに使う時刻フィールドが 1 つ指定されており、タイムスタンプが欠落、null、または無効なドキュメントは拒否されます。 デフォルトの時刻フィールドは @timestamp です。イベントが event_time のような別のフィールドをすでに持っている場合は、インデックス作成時またはインデックステンプレートで index.timestamp_field を設定すれば、プロデューサー側を変更せずに済みます。フィールドはトップレベルの date フィールドである必要があり、ドキュメントのタイムスタンプはインデックス登録後に変更できません。 PUT /app-logs { "settings": { "index.timestamp_field": "event_time" } } 拒否はドキュメント単位で、リクエスト全体には及びません。 _bulk リクエストでは有効なドキュメントはインデックス登録され、拒否されたドキュメントはレスポンスの errors ブロックに列挙されるため、1 件の不正レコードでバッチ全体が失敗することはありません。 図 3: 時刻フィールドが各ドキュメントのインデックス登録または拒否を決める仕組み 障害に発展する前に問題を見つける 時系列コレクションではアラートと異常検知も使えるようになりました。従来の Classic サーバーレスコレクションでは提供されていなかった機能です。別のシステムに頼って不具合を知らせてもらう代わりに、データを保存しているコレクション自体で監視、検知、通知ができます。運用チームはエラー率やレイテンシーの急増時に通知を受け取れ、セキュリティチームはログイン失敗の急増を検知でき、ビジネスチームは注文数の急落を発見できます。 アラートモニターはスケジュールに従ってデータをクエリし、条件が満たされると選択したチャネルを通じて通知します。Per-query モニターは、平均レイテンシーがしきい値を超えるなど、単一の値に対してアラートを発します。Per-bucket モニターは、エラー率が上がりすぎたホストごとなど、グループを個別に評価します。PPL モニターは Piped Processing Language (PPL) で、より複雑なロジックを扱えます。 異常検知は Random Cut Forest (RCF) 機械学習アルゴリズムでデータの通常パターンを学習し、固定しきい値を推定することなく、ほぼリアルタイムで逸脱を検出します。検出器の結果にモニターを向けておけば、異常が現れた瞬間に通知を受け取れます。 モニターと検出器は OpenSearch UI ワークスペースで管理し、アクセス権はワークスペースのコラボレーター権限に従います。読み取り専用のコラボレーターはモニターとアラートを閲覧でき、読み書きおよび管理者のコラボレーターは作成、更新、確認応答も可能です。Observability ワークスペースではアラートがダッシュボードや PPL クエリと並んで配置されるため、サーバーレスコレクションや既存の Amazon OpenSearch Service ドメインを横断して、アラートから背後のイベントまでたどれます。 使ってみる ワンクリックで始めるなら、Amazon OpenSearch Service コンソールの Express Create を使います。コレクショングループ、暗号化、ネットワークアクセス、データアクセスを自動で設定してくれます。各ステップを自分で制御したい場合は、以下のように AWS Command Line Interface (AWS CLI) を使います。 図 4: Express Create がデフォルト設定でコレクショングループ、暗号化、ネットワークアクセスを設定する様子 まず、NextGen のコレクショングループを作成します。コレクショングループは、所属するすべてのコレクションで共有するコンピュート上限を設定します。OpenSearch Compute Unit (OCU) の最小値を 0 にすれば、アイドル時にグループをゼロまでスケールダウンでき、最大値で支出に上限を設けられます。 aws opensearchserverless create-collection-group \ --name app-logs-group \ --generation NEXTGEN \ --standby-replicas ENABLED \ --capacity-limits '{ "minIndexingCapacityInOCU": 0, "minSearchCapacityInOCU": 0, "maxIndexingCapacityInOCU": 96, "maxSearchCapacityInOCU": 96 }' 次に、コレクションへアクセスできる場所を制御する ネットワークポリシー と、どの AWS Identity and Access Management (IAM) プリンシパルがデータを読み書きできるかを制御する データアクセスポリシー を作成します。 続いて、コレクショングループ内に時系列コレクションを作成します。 aws opensearchserverless create-collection \ --name app-logs \ --type TIMESERIES \ --collection-group-name app-logs-group \ --encryption-config aWSOwnedKey=true コレクションがアクティブになったら、時刻フィールド、階層管理、保持期間の設定を含むインデックステンプレートをワークロードに合わせて作成します。名前がパターンに一致するすべてのインデックスが、以下の設定を自動で引き継ぎます。 PUT /_index_template/app-logs { "index_patterns": ["app-logs*"], "template": { "settings": { "index.timestamp_field": "event_time", "index.warm.after": "7d", "index.data.retention": "30" } } } 最後にデータをコレクションに取り込み、OpenSearch UI の Observability ワークスペースを開いて、最初のダッシュボード、モニター、異常検出器を作成します。 本日提供開始 時系列コレクションは、NextGen の OpenSearch Serverless が利用可能なすべての AWS 商用リージョン で本日から提供されます。料金は OCU 単位で使用したコンピュートと、GB 月単位のホットおよびウォームストレージに対して発生します。詳細は Amazon OpenSearch Service 料金ページ をご覧ください。 詳しくは、 Amazon OpenSearch Serverless 製品ページ と Amazon OpenSearch Serverless 開発者ガイド を参照してください。 Amazon OpenSearch Service コンソール でぜひお試しいただき、 AWS re:Post または普段ご利用の AWS サポート窓口からフィードバックをお寄せください。 著者について Kevin Fallis Kevin はベテランのリーダー、アーキテクト、デベロッパーで、農業、アドテック、金融サービス、ネットワーキング、セキュリティ、通信、そしてもちろん検索技術など、さまざまな業界と専門領域での経験を持ちます。顧客がビジネス目標を達成できるよう、AWS サービスとオープンソースソリューションの適切な組み合わせを引き出すことに情熱を注いでいます。仕事以外では、家族と過ごす時間、DIY プロジェクト、大工仕事、乗馬、ドラム演奏、音楽全般を楽しんでいます。 この記事は Kiro が翻訳を担当し、Solutions Architect の Sotaro Hikita がレビューしました。

はじめに 「生成AIを導入すれば、組織の生産性は上がるのか」——現場でDXを推進するマネージャーや、日々の業務でAIを使いながらどこか違和感を抱いているエンジニア・知識労働者の方も多いのではないでしょうか。 私が担当しているプロダクトの開発チームでも、AIコーディングツールを導入しています。しかし導入後、生成されたコードが十分に確認されないままプルリクエストとして上がり、レビューで差し戻すというやり取りが何度も発生しました。コードを書く速度は上がったはずなのに、レビューと手戻りに追われ、少なくとも私には、チーム全体の生産性はAI導入前より下がっているように感じました。 こうした経験を