はじめに こんにちは、WEAR開発部バックエンドブロックの小山です。普段は弊社サービスである WEAR のバックエンド開発を担当しています。 WEARの投稿検索（フリーワード検索）では、 OpenSearch を検索基盤として利用しています。従来の検索方法では、ユーザーが入力するクエリの表記ゆれや誤字・略称により、適切な検索結果を返せないケースがありました。この課題を解決するため、全文検索とベクトル検索を組み合わせたハイブリッド検索を導入しました。しかし、導入の過程ではストレージの肥大化やレイテンシの増加、検索精度のチューニングといった技術的課題に直面しました。本記事では、これらの課題と解決に至るまでの取り組みをご紹介します。 なお、ハイブリッド検索の導入にあたって行った検索インデクサーの刷新（ベクトルデータのOpenSearchへの連携基盤）については、以下の記事で紹介しています。本記事では、検索処理を担うアプリケーション側で直面した課題と解決策に焦点を当てます。 techblog.zozo.com 目次 はじめに 目次 背景・課題 従来のフリーワード検索の限界 ハイブリッド検索とは hybrid queryの構造 normalization-processorによるスコアの統合 ベクトル検索の導入で直面した課題 1. ストレージの肥大化 2. レイテンシの問題 3. 検索精度の課題 課題を解決したアプローチ 1. ベクトルデータの量子化と_source最適化によるストレージ削減 スカラー量子化（fp16）の適用 derived_sourceによる_sourceからのベクトル除外 施策の効果 2. warmup APIの定期実行による暖気機構の導入 スパイクの原因はコールドスタート warmup APIを実行するだけでは解決しなかった 導入した暖気機構 3. スコアの組み合わせ比率の最適化 search pipelineの設定 全文検索の重みを大きくした理由 精度検証の進め方 スコア閾値による関連性の低い結果の除外 あいまい検索を実行する条件の制御 効果 今後の改善 まとめ 背景・課題 従来のフリーワード検索の限界 WEARの投稿検索では、ユーザーが入力したクエリをルールベースでDBのレコードと突き合わせ、性別・カラー・カテゴリー・ブランド・タグなどの検索条件に変換して検索結果を返しています。しかし、この方式だけでは以下のようなケースで適切な検索結果を返せませんでした。 表記ゆれ：「Tシャツ」「Ｔシャツ」「ティーシャツ」のように同じ意味でも表記が異なるクエリ 誤字・略称：ルールベースのマッピングではカバーしきれない入力 意味的な類似検索：クエリと字面は異なるが意味的に近い投稿をヒットさせられない たとえば「平成レトロ」で検索した場合、従来は「#平成レトロ」というタグが付いた投稿しかヒットしませんでした。「夏フェス 野外」のような複数キーワードの検索は、両方のタグに完全一致する投稿しか返せず、ほとんどヒットしない状態でした。 これらのケースをカバーするには、タグの完全一致とは別の検索手段が必要でした。一般的に、キーワードが厳密に一致しない検索には次のような手法があります。 全文検索：タイトルや説明文などのテキストを対象に、キーワードと字面が一致する投稿を広く拾える ベクトル検索：キーワードの字面ではなく「意味」の近さで検索でき、別表記や言い換えにも対応できる WEARの課題は、「夏フェス 野外」のように字面の部分一致で解決できるケースと、「ティーシャツ」のように字面が異なるケースの両方にまたがっています。そのため、どちらか一方ではなく両者を組み合わせるハイブリッド検索の導入を決定しました。 なお、ハイブリッド検索は従来の検索を置き換えるものではありません。ルールベースのマッピングには、クエリの意図を性別やカラーなどの構造化された検索条件へ正確に落とし込めるという強みがあります。そのため従来のマッピングの機構は残したまま、タグ検索のヒット件数が少ない場合に検索結果の量を補助する位置づけでハイブリッド検索を適用しています（適用条件の詳細は後述します）。WEARでは、このハイブリッド検索を利用した検索機能を「あいまい検索」と呼んでいます。 ハイブリッド検索とは ハイブリッド検索とは、キーワードマッチによる全文検索と、意味的な類似度で検索するベクトル検索を組み合わせ、双方のスコアを統合して検索結果を返す検索手法のことです。OpenSearchでは、バージョン2.10で導入された hybrid query と normalization-processor を利用することで実現できます。 それぞれの検索手法には以下のような長所・短所があり、互いに弱点を補完し合う関係にあります。 検索手法 長所 短所 全文検索（BM25） キーワードの完全一致に強い、高速 同義語・言い換えに弱い、意味を理解しない ベクトル検索（k-NN） 意味的な類似性を捉えられる、表記ゆれ・言い換えに強い 計算コストが高い、キーワードの完全一致に弱い hybrid queryの構造 ハイブリッド検索のクエリは、hybrid queryの中に全文検索クエリとベクトル検索クエリを並べた構造になります。WEARでは、全文検索にはmulti_matchクエリを、ベクトル検索には検索キーワードをOpenSearch側でベクトル化して検索するneuralクエリを利用しています。 { " query ": { " hybrid ": { " queries ": [ { " multi_match ": { " query ": " 夏フェス 野外 ", " fields ": [ " title.sudachi ", " content.sudachi ", " ... " ] } } , { " neural ": { " text_embedding ": { " query_text ": " 夏フェス 野外 ", " model_id ": " <モデルID> " } } } ] } } } なお、フィールド名の .sudachi は形態素解析器（Analyzer）を表しています。全文検索における日本語の形態素解析にはSudachiを利用しており、kuromojiで解析したフィールドも併用できる構成にしています。 normalization-processorによるスコアの統合 ここで問題になるのが、2つの検索のスコアを単純に比較できないことです。BM25のスコアには上限がなく、マッチした単語数や出現頻度によって数十以上の値も取る一方、ベクトル検索の類似度スコアは0〜2程度の狭い範囲に収まります。そのまま足し合わせると、値の大きい全文検索のスコアに結果が引きずられてしまいます。 normalization-processorは、このようにスケールの異なるスコアを揃えて統合するための仕組みです。search pipelineに設定すると、検索結果へ次の2段階の処理を適用します。 正規化（normalization）：各クエリのスコアを同じ土俵で比較できるように変換する。min_max方式では (スコア - 最小値) / (最大値 - 最小値) で0〜1の範囲に正規化する 結合（combination）：正規化したスコアを重み付きで結合し、最終スコアを算出する なお、WEARの検索では、ハイブリッド検索のスコアを並び順に使っていません。スコアは、関連性の低い投稿を除外する足切りに使っています。足切りを通過した投稿は、人気順スコアで並べ替えて返します。関連度だけで並べると、検索結果に含まれる投稿の質がばらつきやすいためです。関連度は足切りで担保し、その上で人気の高い投稿から表示して検索結果の質を保つ設計です。 検索リクエストからレスポンスまでの流れは以下のとおりです。 ベクトル検索の導入で直面した課題 ハイブリッド検索を実現するためにベクトル検索を導入したところ、リリース前に解消すべき以下の技術的課題が発生しました。 1. ストレージの肥大化 投稿ごとに1024次元の埋め込みベクトルを保持するため、インデックスのストレージサイズが大幅に増加しました。ベクトルの各要素を32ビットの浮動小数点（fp32、4バイト）で保持すると、1投稿あたり約4KB（1024次元 × 4バイト）のベクトルデータが追加されます。対象の投稿は膨大なため、全量を投入するとベクトルデータだけで数十GB規模の追加になる見積もりでした。実際に、一部の投稿データで構築した検証用インデックスを実測すると、fp32のベクトルを含むサイズは13.2GBに達していました。 ベクトルデータの増加は、ストレージコストだけの問題ではありません。後述のとおり、k-NN検索ではHNSWグラフを検索時にメモリへロードしておく必要があるため、ベクトルデータが増えるほど必要なメモリ容量も増えます。ディスクは増設で対応できますが、メモリの確保はインスタンスの増強が必要になり、コストへの影響が大きくなります。 2. レイテンシの問題 ベクトル検索（k-NN検索）では、近いベクトル同士をつないだグラフ構造（HNSW）をインデックスとして構築し、検索時にそれをたどることで高速な近傍探索を実現しています。このグラフをメモリにロードしていない状態で検索すると、レイテンシが大きく悪化する問題を抱えていました。実際に、通常時は200ms程度で応答する検索が、不定期に20秒程度まで悪化するスパイクを起こしていました。 3. 検索精度の課題 ハイブリッド検索を導入しただけでは期待する検索精度が得られず、全文検索とベクトル検索のスコアをどのような比率で組み合わせるかのチューニングが必要でした。 たとえば、ベクトル検索の重みを大きくしすぎると、ブランド名で検索した際に意味的に近い別ブランドの投稿が混入してしまいます。逆に全文検索の重みを大きくしすぎると、表記ゆれや言い換えをカバーするというベクトル検索導入の狙いが薄れてしまいます。 課題を解決したアプローチ 1. ベクトルデータの量子化と_source最適化によるストレージ削減 ストレージの肥大化に対しては、ベクトルデータの量子化（fp16化）と、 _source フィールドからのベクトルデータ除外（derived_source）の2つの施策で対応しました。 スカラー量子化（fp16）の適用 量子化手法にはFaissエンジンのスカラー量子化（SQfp16）を採用しました。ベクトルの各要素をfp32から16ビットの浮動小数点（fp16）に変換して保持する手法で、ベクトルデータのサイズを50％削減できます。プロダクト量子化やバイナリ量子化ほどの圧縮率はないものの、精度への影響が小さく、事前学習も不要でマッピングの encoder 設定を追加するだけで導入できます。精度と導入の手軽さのバランスを重視して、この手法を選びました。 knn_vector フィールドの定義は以下のとおりです。 { " text_embedding ": { " type ": " knn_vector ", " dimension ": 1024 , " method ": { " name ": " hnsw ", " space_type ": " innerproduct ", " engine ": " faiss ", " parameters ": { " ef_construction ": 128 , " m ": 16 , " encoder ": { " name ": " sq ", " parameters ": { " type ": " fp16 " } } } } } } ただし、fp16化のみを適用した場合、インデックスサイズは13.2GBから12.2GBへと7.6％の削減にとどまりました。k-NN検索用のデータ構造は半減しても、 _source フィールドに元のベクトル値がそのまま保存されているためです。 derived_sourceによる_sourceからのベクトル除外 そこで、OpenSearch 2.19で実験的機能（experimental）として導入された knn.derived_source を有効化しました。この設定を有効にすると、ベクトルデータが _source に重複して保存されなくなり、必要な場合はk-NN検索用のデータ構造から導出されるようになります。 { " settings ": { " index ": { " knn ": true , " knn.derived_source.enabled ": true } } } なお、derived_sourceの有効化で検索時に20ms程度のオーバーヘッドを確認しましたが、許容範囲と判断しています。 施策の効果 2つの施策によるストレージ削減効果は以下のとおりです（検証用インデックスで実測）。 インデックス設定 ストレージサイズ 削減率 ベースライン（fp32） 13.2GB - fp16のみ 12.2GB 7.6％ fp16 + derived_source 5.2GB 60.6％ fp16化により検索精度への影響が懸念されたため、fp32のインデックスとfp16のインデックスのそれぞれに同一クエリで検索をかけ、結果を比較して検証しました。上位20件の重複率はおおむね95％以上で、スコアの差も小数点以下6桁目程度の違い（例：1.5960883と1.5960877）にとどまりました。結果が異なる投稿は実際に目視で確認し、検索クエリの意図から外れていないことを確かめた上で採用しています。 なお、この施策は投稿数がもっとも多いコーディネートのインデックスのみに導入しています。データ量の少ないインデックスでは削減効果が限定的なためです。 2. warmup APIの定期実行による暖気機構の導入 レイテンシの問題に対しては、OpenSearchの warmup API を定期実行する暖気機構を導入しました。 スパイクの原因はコールドスタート まず、k-NN統計API（ GET /_plugins/_knn/stats ）でレイテンシ悪化時の状態を分析しました。すると、メモリ不足によるグラフ破棄（Eviction）は発生しておらず、キャッシュミス（Miss Count）が多発していることがわかりました。つまり、スパイクの原因はメモリ不足ではなく、以下のメカニズムによるコールドスタートでした。 インデックス更新に伴いバックグラウンドでmerge/refreshが発生し、新しいHNSWグラフが作成される 新しいグラフはまだネイティブメモリにロードされていない そこに検索リクエストが到達すると、ディスクからのグラフロードが発生し、完了まで数秒〜数十秒待たされる warmup APIを実行するだけでは解決しなかった コールドスタート対策として、グラフを事前にメモリへロードするwarmup APIをデータ投入後に実行しましたが、それでもスパイクは解消しませんでした。調査の結果、原因はデータ投入とwarmupのタイミングにありました。 処理 同期/非同期 Bulk APIによるデータ投入 同期（ただし検索可能になるのはrefresh後） HNSWグラフ構築 非同期（Bulk完了後もバックグラウンドで継続） flush/merge 非同期（グラフデータのディスク永続化） warmup APIの対象になるのは、flush/mergeが完了しディスクに永続化済みのグラフのみです。HNSWグラフ構築とflush/mergeはBulk APIの完了後も非同期で続くため、データ投入直後にwarmupを実行しても、永続化前のグラフには適用されません。つまり「Bulk APIの完了 ≠ warmup実行可能なタイミング」だったのです。 導入した暖気機構 この調査を踏まえ、インデックスの洗い替え時と日常の差分更新のそれぞれに対して暖気を組み込みました。 フィールドの追加やマッピングの変更の際は、新しいインデックスを作成してデータを入れ直す洗い替え（リインデックス）が必要になります。洗い替えの際は以下の順に処理し、暖気が完了したインデックスだけがユーザーからの検索を受けるようにしています。 新インデックスを作成し、データを投入する refreshを実行し、投入したデータを検索可能にする warmup APIを実行し、HNSWグラフをネイティブメモリにロードする エイリアスを新インデックスに切り替える 一方、日常運用では差分更新によって新しいHNSWグラフが継続的に作られるため、洗い替え時の暖気だけではカバーできません。WEARでは、差分データを10分間隔で投入するワークフローが動いています。このワークフローの最終ステップにwarmup APIの実行を組み込み、差分投入で作られた新しいグラフを毎回暖気しています。ワークフローの流れは以下のとおりです。 差分データを抽出する（BigQuery） データをGCSからS3へ転送する ベクトル化してOpenSearchへ投入する（詳細は前述のインデクサー刷新の記事を参照） 投入完了を確認する 削除済みの投稿をインデックスから除去する refreshを実行し、投入したデータを検索可能にする warmup APIを実行し、新しいHNSWグラフをネイティブメモリにロードする なお、暖気を組み込んでもスパイクを完全には防げません。そのため、あいまい検索専用のOpenSearchクライアントに0.5秒の短いタイムアウトを設定しています。タイムアウトや一時的なエラーが発生した場合は、従来のタグ検索の結果を返すフォールバックを実装しています。あいまい検索が失敗してもユーザーには正常なレスポンスが返る多層的な構えとし、フォールバックの発生は監視基盤に記録して検知できるようにしています。 3. スコアの組み合わせ比率の最適化 検索精度の課題に対しては、ハイブリッド検索の実行結果を確認しながら、全文検索とベクトル検索のスコアを組み合わせる際の最適な重みを探りました。 search pipelineの設定 スコアの正規化と結合は、以下のsearch pipelineで行っています。正規化手法にはmin_maxを、結合手法には重み付き算術平均（arithmetic_mean）を採用し、最終的に全文検索を重視した重みに落ち着きました。 PUT /_search/ pipeline / hybrid - search - pipeline { " description ": " Post processor for hybrid search ", " phase_results_processors ": [ { " normalization-processor ": { " normalization ": { " technique ": " min_max " } , " combination ": { " technique ": " arithmetic_mean ", " parameters ": { " weights ": [ <全文検索の重み>, <ベクトル検索の重み> ] } } } } ] } 全文検索の重みを大きくした理由 検索方式 重み 理由 全文検索 大 ユーザーが入力したキーワードへの一致を重視。ファッション検索ではブランド名・アイテム名などの正確な一致が重要なため ベクトル検索 小 セマンティックな関連性を補完。「秋コーデ」に対する「紅葉」「ニット」のような関連概念の発見を支援するため 前述のとおり、ベクトル検索の重みを大きくしすぎるとキーワードと一致しない投稿が混入します。ファッションの検索ではブランド名やアイテム名の正確な一致が重要なため、キーワード一致を主、意味的な類似を従と位置づけてこの比率を選びました。 精度検証の進め方 精度検証は、nDCGのような定量指標による自動評価ではなく、目視による定性評価で進めました。評価用のクエリを用意し、検索結果をスプレッドシートへ並べて、キーワードとの関連性や表示順の違和感をチームで確認していきました。 調整は以下の手順で進めました。 ベクトル検索単体の足切りスコア（min_score）を見極める 全文検索の単体での足切りスコアを決める 重みづけを設定した上でハイブリッド検索を試し、ハイブリッド検索としての足切りスコアを決める その結果を定性評価する 実際に調整を進める中で、ベクトル検索・全文検索の単体では良い結果が得られているのに、ハイブリッド検索として組み合わせると期待どおりの結果にならないケースがありました。このようなケースを1件ずつ確認しながら、重みは固定したまま、足切りスコアの調整で精度を追い込んでいきました。 スコア閾値による関連性の低い結果の除外 重みの調整とあわせて、全文検索・ベクトル検索のそれぞれにスコアの下限値（min_score）を設定しています。ベクトル検索はどんなクエリに対しても「もっとも近い」ドキュメントを返してしまうため、閾値を設けないと関連性の低い投稿が検索結果に含まれてしまいます。閾値は、複数の評価用クエリで検索結果を定性評価し、クエリごとに求めた「関連性の低い結果を除外できるスコア」の平均値として決定しました。 なお、スコアの分布は固定ではない点に注意が必要です。実際、リリース後にOpenSearchをバージョンアップした際、全文検索のスコアが全体的に低く出るようになり、正常な検索結果が閾値で除外される事象が発生しました。この事象は、検索結果からの遷移率などのKPIモニタリングがきっかけで検知しました。その際は、リリース判定時と同じ検索語句でスコア順TOP1000件の分布を確認し、閾値を引き下げて対応しました。min_scoreを利用する場合は、バージョンアップなどによるスコア分布の変化まで含めた運用を想定しておくことをおすすめします。 あいまい検索を実行する条件の制御 背景で述べたとおり、あいまい検索は従来の検索を補助する位置づけであり、すべてのキーワードに対して実行しているわけではありません。検索キーワードがタグにマッピングされ、タグ検索で一定の件数以上の結果を得られる場合は、タグ検索の結果をそのまま返します。タグに完全一致する検索結果は精度が高く、十分な件数があればあいまい検索で補完する必要がないためです。 効果 これらの取り組みにより、ハイブリッド検索を本番運用できる状態でリリースできました。 ストレージ：fp16量子化とderived_sourceにより、インデックスサイズを13.2GBから5.2GBへ約60％削減しました レイテンシ：暖気機構により、コールドスタートに起因する最大20秒のレイテンシスパイクを大幅に抑制しました。リリース時のあいまい検索のレイテンシはp99平均369msで、事前の負荷試験と同水準の結果でした 検索精度：スコアの重みと閾値の調整により、キーワード一致を保ちつつ、表記ゆれや言い換えを含むクエリでも意図した投稿がヒットするようになりました たとえば「平成レトロ」と検索すると、従来はタグ「#平成レトロ」が付いた投稿しかヒットしませんでした。ハイブリッド検索の導入後は「平成」「平成ギャル」をタグや説明文に含む投稿も返せています。「秋っぽいコーデ」のようなあいまいな言い回しのクエリや「夏フェス 野外」のような複数キーワードのクエリでも、意味の近い投稿をヒットさせられています。 今後の改善 ハイブリッド検索の導入で表記ゆれや言い換えへの対応は進みましたが、運用する中で新たな課題も見えてきています。 部分一致によるノイズ：検索キーワード「白シャツ」に対して、「白Tシャツ」や「黒シャツ」を含む投稿まで高い類似度でヒットしてしまう 複数キーワードの検索意図の解釈：「ロングスカート 低身長」のような検索では、どちらか一方しか含まない投稿もヒットしてしまい、クエリ全体の意図を汲み取れない こうしたノイズを除外するチューニングとあわせて、コーディネート画像の活用も検討しています。社内ではすでに別部署が 画像からの特徴量の抽出・テキスト化 に取り組んでいます。その成果を検索データとして取り込む案と、画像そのものをベクトル化する案の両方が選択肢です。テキスト情報だけでは表現しきれないコーディネートの特徴から検索できるようになれば、あいまい検索の適用範囲をさらに広げられると考えています。 また、全文検索側では辞書の拡充も検討しています。語彙数の多い辞書や独自のユーザー辞書を導入すると、「夏フェス」のような複合語やトレンドから生まれる新語も1語として扱えるようになります。意図しない単語分割が減り、全文検索のノイズの低減にもつながると考えています。 さらに、あいまい検索の手前にあるクエリ理解の改善も検討しています。キーワードから検索条件へのマッピングの精度を高めれば、あいまい検索に頼る前の段階で、より適切な検索結果を返せるようになります。 まとめ 本記事では、WEARのフリーワード検索にハイブリッド検索を導入した際の課題と、その解決のための技術的工夫をご紹介しました。 ベクトル検索導入によるストレージ肥大化には、fp16へのスカラー量子化とderived_sourceによる _source 最適化で対応しました k-NN検索のレイテンシ問題には、リインデックス時の暖気完了後のエイリアス切り替えと、差分更新ワークフローへのwarmup組み込みによる暖気機構で対応しました 検索精度の課題には、全文検索とベクトル検索のスコアを組み合わせる重みとスコア閾値の最適化で対応しました OpenSearchでのハイブリッド検索の運用を検討している方や、精度検証の進め方に悩んでいる方の参考になれば幸いです。 ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com

はじめに 7 月は AWS オブザーバビリティにとってアップデートの多い月となりました。すでに収集しているテレメトリをより実用的なものにし、その収集にかかる運用作業を AWS 側で引き受ける機能をリリースしました。ログ分析は、ログクエリから直接実行できるアラームと、取り込み時に行われるエンリッチメントによって、アクションに繋げやすくなりました。アプリケーションレベルのオブザーバビリティは、エラーとデプロイイベントを自動的に捕捉するようになりました。AI コーディングエージェントの可視化が、新しいオブザーバビリティのカテゴリとして登場しました。Prometheus メトリクスのスクレイピングのために自前で運用していたエージェントは、マネージドコレクションによって不要になりました。そしてこれらすべてを支える基盤として、OpenTelemetry と Prometheus が引き続き中核的な役割を果たしています。 Amazon CloudWatch 、 Amazon Managed Service for Prometheus 、 Amazon Managed Grafana 、 AWS DevOps Agent の最新情報をご紹介します。 これらのリリースのライブデモをご覧になりたい方は、9 月 16 日開催の「 I didn’t know Amazon CloudWatch could do that! 」ウェビナーにご登録ください。過去のまとめを見逃した方は、「 今月の AWS オブザーバビリティ 」の 2026 年 1 月〜5 月 および 2026 年 6 月 のブログをご覧ください。 ログ分析: クエリからアクションへ 7月のテーマとして最も分かりやすいのは、ログクエリと、そこから起こすアクションに繋げやすくすることでした。 CloudWatch Logs のクエリから直接アラームを作成 できるようになりました。クエリを記述してしきい値を設定すれば、エラーが急増したときに周辺のログコンテキストとともにアラートを受け取れます。これら一連の操作が 1 つのワークフローで完結します。メトリクスフィルターやカスタムメトリクスを事前に作成する中間ステップは不要になりました。ログアラームは、Amazon Simple Notification Service や Amazon EventBridge を含む、すでに利用している標準的なアラームアクションをサポートしているため、他の CloudWatch アラームと同じ通知・自動化の経路にルーティングできます。 新しい ログエンリッチメント用の lookup プロセッサ は、アップロード済みの CSV のルックアップテーブルとログイベントのフィールドを照合することで取り込み時にコンテキストを追加します。カスタムのエンリッチメントロジックを書かなくても、IP アドレスから担当チームへ、エラーコードから人が分かりいやすい説明文へ、ユーザー ID からアカウントのメタデータへ、といったマッピングができます。エンリッチメントはデータの到着時に行われるため、クエリ、ダッシュボード、アラームのすべてが追加されたフィールドの恩恵を直ちに受けられます。 CloudWatch Logs が、 Application Load Balancer のログを Vended Logs (AWS のサービスが発行するログ) としてサポート するようになりました。Application Load Balancer のアクセスログ、接続ログ、ヘルスチェックログが CloudWatch Logs に直接ストリーミングされ、Logs Insights でのクエリ、メトリクスフィルターの作成、Live Tail によるリアルタイム監視が可能になります。テレメトリ有効化ルールにより、組織内の既存および新規のロードバランサーに対してロギングが自動構成されるため、1 つずつ手作業で設定する必要はありません。 CloudWatch Logs Insights には、7 月に 25 個の新しいクエリコマンドと関数 が追加されました。統計関数、セッション化 (sessionization)、外れ値検出、NULL 処理などが含まれます。これらにより、結果を別の場所で後処理するのではなく、クエリ言語の中でより多くの分析を直接実行できます。 コスト効率の良いログストレージ ログを 1 か所に集めるほど、ストレージコストが課題になります。7 月はこの点にも対応しました。 CloudWatch Logs Intelligent Tiering は、直近のアクセス状況に基づいて、ログデータを Standard、Infrequent Access、Archive Instant Access の 3 つの階層に分類します。30 日間アクセスされていないデータは Infrequent Access に移動し、90 日間アクセスされていないデータは Archive Instant Access に移動します。古いデータをクエリすると、自動的に Standard に戻ります。クエリの操作感は 3 つの階層すべてで同じであるため、チームの運用を変えることなくストレージコストを削減できます。有効化はアカウントレベルで行います。 アプリケーションのオブザーバビリティ Application Signals が、計装済みのサービスから エラー、パフォーマンス異常、デプロイイベントを自動的に捕捉 するようになりました。追加のコード変更は不要です。例外とレイテンシーのイベントスナップショット、関数レベルのパフォーマンスデータ、デプロイイベントを記録します。そのため、何か変化が起きたときには Errors ビューを直接開き、最近のデプロイが新しい例外を引き起こしたかどうかを確認できます。この機能は、AWS Distro for OpenTelemetry SDK、または Amazon Elastic Kubernetes Service (Amazon EKS) 用の CloudWatch Observability アドオンで計装された Java、Python、JavaScript のサービスでサポートされます。イベントはログとして、関数メトリクスは OpenTelemetry メトリクスとして配信されるため、既存のオブザーバビリティデータとまとめて扱えます。 AI コーディングエージェントのオブザーバビリティ Coding Agent Insights は、AI コーディングツールが組織全体でどのように価値を生み出しているかを、エンジニアリングリーダーが把握できるようにします。Claude Code、Codex、GitHub Copilot と統合され、追加の計装なしで OpenTelemetry メトリクスを収集します。データは既存の CloudWatch の運用ビュー上に表示されます。支出のトレンドを追跡し、トークン課金のアラートを設定し、エージェントの導入状況をコミットのスループットやプルリクエストの速度と突き合わせ、どのモデルが最も優れたコスト対アウトプット比を実現しているかを特定できます。コーディングエージェントを大規模に導入していくチームにとって、リターンを推測ではなく計測する手段となります。 OpenTelemetry とマネージドコレクション Managed Prometheus collectors は、エージェントのデプロイや保守なしに、Prometheus メトリクスをフルマネージドで収集します。スクレイプ設定を用意すれば、プロビジョニング、スケーリング、収集は CloudWatch が処理します。エージェントを一切デプロイ・管理することなく、Amazon EKS、Amazon EC2、Amazon ECS、Amazon MSK、Amazon OpenSearch Service のワークロードの監視を有効化できます。メトリクスは OpenTelemetry 形式で配信され、AWS Vended メトリクス (AWS のサービスが発行するメトリクス) とともに PromQL でクエリできます。 AWS Cloud Operations Blog の関連記事 (2026 年 7 月) 2026 年 7 月に AWS Cloud Operations Blog で公開された記事は以下のとおりです。 Getting per-resource alarm notifications with Amazon CloudWatch   – Himanshu Dewan, Ashish Kumar, Radheshyam Baliga Bantwal Autonomous Root Cause Analysis for AWS Systems Manager Patch Failures Using AWS DevOps Agent   – Rizwan Mohammed, Samir Behara, Shanmukha Jaya Harsha Alluri, Vinod Kisanagaram Build bespoke operational workflows with AWS DevOps Agent custom SRE agents   – Harish Mandhadi, Brent Everman, Joe Alioto, Janardhan Molumuri Automate CI/CD troubleshooting with AWS DevOps Agent and GitHub   – Purushotham G K, Abhishek Taparia Extend Amazon CloudWatch Beyond Native Connectors with Cribl Stream   – Gabriel Costa, Kishore Vinjam How Amazon Achieved Full Stack Observability Across 400 Offices with Amazon OpenSearch Serverless   – Shivansh Singh, Arijit Chakravorty, Bishr Tabbaa, Leonardo Quintero Deploy OpenTelemetry Gateway on AWS: Monitoring Your Observability Pipeline  – Ankita Saxena, Jyothi Madanlal Amazon CloudWatch アラームをアクション可能なシグナルに変える   – Helen Ashton, Gagandeep Singh Using Amazon S3 Server Access Logs with Amazon CloudWatch Logs   – Isaiah Salinas, Erik Weber まとめ 7 月のリリースによって、ログ分析はクエリとアクションのギャップを埋め、ストレージの階層化はデータ保持コストを抑えやすくしました。さらに、アプリケーションのオブザーバビリティは追加のコードなしで重要なイベントを捕捉し、AI コーディングエージェントは計測可能になり、マネージドコレクションはエージェント運用の負担を取り除きました。これらはすべて OpenTelemetry と Prometheus の基盤の上に構築されています。 これらの機能を使い始めるには、以下を実施してください。 CloudWatch コンソール で、ログクエリから直接アラームを作成する。 CloudWatch Pipelines で 取り込み時にログをエンリッチするルックアップテーブル をアップロードする。 エラーとデプロイの自動捕捉のために、Application Signals のサービスイベントを有効にする。 Coding Agent Insights にデータを取り込むために、 Claude apps gateway のテレメトリを設定する 。 自己管理型のコレクターを マネージド Prometheus コレクター に置き換える。 テレメトリ有効化ルールを使って、 Application Load Balancer のログ を CloudWatch Logs にストリーミングする。 ストレージコストを自動的に削減するために、ログアカウントで CloudWatch Logs Intelligent Tiering を有効にする。 最近のリリースの一覧については、Amazon CloudWatch で絞り込んだ AWS What’s New ページ をご覧ください。 さらに詳しく知りたい方へ 9 月 16 日開催の「 I Didn’t Know Amazon CloudWatch Could Do That 」ウェビナーにご参加ください。これらの新機能の実際の動作をご覧いただき、トラブルシューティングの迅速化にお役立てください。 著者について Dot Ho Dot は AWS オブザーバビリティのシニアテクニカルプロダクトマーケティングマネージャーです。WCA (World Cube Association) の 3×3 マルチブラインド (目隠しで複数のキューブを解く種目) の記録向上に向けて練習中です。 Erik Weber Erik Weber は AWS Cloud Operations サービスのシニアワールドワイドスペシャリストソリューションアーキテクトです。AWS Systems Manager、AWS Config、AWS CloudTrail、AWS Audit Manager を専門としています。仕事以外では、ハイキング、料理、サイクリングを愛好しています。 Kevin Lewin Kevin は Amazon Web Services のクラウドオペレーションスペシャリストソリューションアーキテクトです。オブザーバビリティと自動化を通じて、お客様が運用目標を達成できるよう支援することに注力しています。 本ブログは 2026 年 8 月 18 日に公開された This Month in AWS Observability: July 2026 の日本語訳です。翻訳はテクニカルアカウントマネージャーの日平が行いました。

はじめに サーバーワークスの池田です。 AI コーディングツールの普及にともない、「AI は人間より多くバグを生むのか」が議論されるようになりました。この問いには感覚ではなく測定値で答えたいところです。 本記事では 2025 年から 2026 年に公開された査読論文・企業の実測データを一次ソースとして、AI 生成コードの測定結果と検証側の実態を整理します。数値はすべて原文にあたって確認し、測定条件と母集団を併記しています。 なお本記事で扱う「欠陥」の多くは、静的解析ツールが出すアラートです。実際に本番で発生した障害を AI と人間で直接比較した研究は、今回の調査範囲では見つかりませんでした。こ…