2024年度にAWS認定資格をすべて取得し、 2025 ALL AWS Certifications Engineers として表彰していただきました！ 振り返ってみると、当初の予定を大幅に前倒しした 資格取得RTA のような怒涛のスケジュールでした。 今回は、なぜ実務経験が断片的だった私が全冠を目指したのか、そしてどうやって駆け抜けたのか、その記録を公開します。 挑戦前のスペック：AWS経験は「点」でした 「全冠」と聞くと、さぞかしAWSを使いこなしている人を想像されるかもしれませんが、当時の私の状況はこんな感じでした。 仕事：クラウドネイティブな開発基盤構築チームで、いわゆる「何でも屋」をしているエンジニア 主戦場： Azure、GoogleCloud（仕事の比率はこちらが高め） AWS実務経験： 特定サービスのアプリ部品を1つ作成。あとは、炎上プロジェクトでの技術支援（火消し）にスポット参戦 得意なこと： プログラミング、DevOps関連技術、アプリ開発周り 保有資格： 高度情報（システムアーキテクト、データベーススペシャリスト）、Java資格など AWSに関しては「広く浅く」どころか、特定のスポットだけ激しく触ったことがあるという、非常に偏った知識状態からのスタートでした。 取得動機：あふれるAWSへの想いを形にしたかった 理由はシンプルです。AWSが好きだから。 しかし、世の中はAWSエンジニア戦国時代。人気すぎて競争率が高く、インフラ専任ではない私には、なかなかAWSメインの案件が回ってきませんでした。 「好きなのに、触れない……。この熱意をどうにかして証明したい！」 そう思い立った結果が、「資格で可視化すること」でした。当初は「年2個くらいずつ、ゆっくり取ろうかな」と考えていたのですが、いざ始めると火がついてしまいました。 得意なDevOps分野が意外とスルスル取れたことで弾みがつき、1資格2週間（1・2月は月3個ペース）という怒涛の短期集中モードに突入してしまったのです。 （※よい子の皆さんは、無理のないスケジュールを立ててくださいね！） 攻略ルート：得意を固めてから「専門領域」に挑む 一般的にはSAA（Associate）からSAP（Professional）へ進むのが王道ですが、 私は知識のオーバーラップを意識して、得意な領域からグルーピングして攻略しました。 実際に進んだ順番 1. 基礎・開発系（足場固め） CLF → SAA → DVA → DOP → SOA まずは得意なDevOps周りを固め、勢いをつけました。 2. トレンド・データ系（攻めの姿勢） DEA → AIF → MLS → MLA 新設されたデータ・AI系資格を一気に攻略。 3. インフラ・専門系（最難関の壁） ANS → SCS → SAP 最難関のネットワーク（ANS）をあえて後半に。 最後は集大成としてラスボス的存在のSAPで締めました。 実際に駆け抜けたロードマップ コード 正式名称 レベル 初回取得日 コメント CLF-C01 AWS Certified Cloud Practitioner Foundational 2023-01-28 AWSはじめ SAA-C03 AWS Certified Solutions Architect Associate 2024-02-12 穏やかに取得 DVA-C02 AWS Certified Developer Associate 2024-06-26 ウォーミングアップ期間 DOP-C02 AWS Certified DevOps Engineer Professional 2024-12-20 覚醒 SOA-C02 AWS Certified SysOps Administrator Associate 2025-01-10 ここからRTAスタート DEA-C01 AWS Certified Data Engineer Associate 2025-01-25 　↓ AIF-C01 AWS Certified AI Practitioner Foundational 2025-01-29 　↓ MLS-C01 AWS Certified Machine Learning Specialty 2025-02-06 　↓ MLA-C01 AWS Certified Machine Learning Engineer Associate 2025-02-13 　↓ ANS-C01 AWS Certified Advanced Networking  Specialty 2025-02-26 　↓ SCS-C02 AWS Certified Security Specialty 2025-03-05 　↓ SAP-C02 AWS Certified Solutions Architect Professional 2025-03-17 ゴール！！ 勉強方法：三種の神器 短期集中を成功させるために、効率を最優先しました。 1. AWS Black Belt (動画/資料) 知らないサービスは、まずこれ。公式の「正解」を脳に叩き込みます。 2. Udemy (動画教材) 特に未知の領域（AI、ネットワーク）は、ハンズオン付きの教材で「触った感触」を擬似体験しました。 3. オンライン問題集 「試験の勘」を養うために、仕上げとして数周。間違えた部分は公式ドキュメントに戻って徹底的に潰しました。 挑戦中に感じた「光と影」 苦しかったこと：最難関ネットワークの壁 一番しんどかったのは、やはりANS（ネットワーク）です。 開発をしていると不具合の原因として立ちはだかることもあるネットワークですが、実務で使ったことのない細かいサービス仕様には本当に苦戦しました。 また、MLA（機械学習エンジニア）も普段の業務と距離があったため、根気強く動画と問題集を往復する日々でした。 楽しかったこと：アーキテクチャの万華鏡 逆に一番楽しかったのは、試験を通じて膨大なアーキテクチャ事例に触れられたことです。 普段は特定の基幹システムを見ることが多いのですが、多種多様な構成を学ぶのは新鮮で、「AWSならこんな解決策があるのか！」と、ただただワクワクしました。余計にAWSが好きになりました。 おまけ 最後にちょっとだけ自慢させてください！ 12回もの試験を乗り越えたご褒美に、AWS Summit2025で取得した資格のシールをいただいてきました！（デザイン好きすぎて額縁に入れました。） 某RPGが大好きでたくさんのシリーズをやっているのですが、まさかAWSの資格シールがRPG風なんて…！！ドット絵のキャラクターが並んでいるのを見るだけで、テンションが上がります。こうして物理的な形になると、頑張ってよかったな～と改めて実感します。  総評：全冠を取得して変わったこと 2月から3月のラストスパートは、正直くじけそうになる瞬間もありました。 ですが、1つ合格するたびに「自分でもできるんだ」という自信が積み重なり、最後は 早く次の試験を受けたい！ というランナーズハイに近い状態になっていました（笑）。 全冠を達成して得られたのは、単なる称号だけではありません。 AWSという巨大なパズルの全体像 が見えるようになったことで、アーキテクトとして自信を持って提案ができるようになりました。   もし、「実務経験が少ないから」と迷っている方がいたら、ぜひ一歩踏み出してみてください。資格取得の過程で得られる知識は、必ず現場でのあなたの武器になります。 最後まで読んでいただきありがとうございました！ 2025 ALL AWS Certifications Engineers の名に恥じぬよう、これからも精進します！ P.S.勢いそのままに、実は「AWS Certified Generative AI Developer – Professional」のベータ版も突撃し、Early Adopterバッジをもらってきました。気力が湧いたら、そちらの記事も書く…かもしれません。

こんにちは。QAエンジニアのなおたです。 日々ソフトウェア品質と向き合っている若手エンジニアの皆さん。昨今、「生成AI」という言葉を聞かない日はないでしょう。 先日、生成AI本のベストセラー 『 生成AIで世界はこう変わる 』 （今井翔太著／SB Creative）を読んでみました。想像を超える速度でAIのインパクトは社会全体に及んでいますが、私たちソフトウェア開発の現場、特に「ソフトウェアテスト」の領域は、今まさに変革期の入り口に立っていると感じました。 「AIがテストケースを自動で作ってくれるなら、エンジニアの仕事はなくなるのでは？」 そんな不安や疑問を感じている方も少なくないかもしれません。 しかし、結論から言えば、仕事は「なくなりません」。 ただし、その「質」は根本から変わります。本ブログでは、生成AIがソフトウェアテストをどう変革し、私たちエンジニア、特に若手エンジニアの方々が今後どのようなスキルを身につけるべきか、考察していきます。 なぜ今、ソフトウェアテストが「変革期」なのか IPA（情報処理推進機構）が示すように、ソフトウェアテストは開発プロセスにおいて「品質の作り込み」と「品質の確認」を担う、極めて重要な工程です。（参考: IPA ソフトウェアテスト） ※1 従来の開発（例えばV字モデル）において、テスト工程は多くの工数とコストを要する領域でした。テスト設計の属人性、テストケースの網羅性の担保、膨大なリグレッションテストの工数確保等 これらは、多くのプロジェクトが抱える共通の課題です。 まさに今、この領域に、生成AIがメスを入れようとしています。 生成AIが可能にすること（例）： テストケースの自動生成: 仕様書（自然言語）を読み込ませ、境界値や同値分割を考慮したテストケースを瞬時に生成する。 テストデータの多様化: 正常系だけでなく、異常系やエッジケースのテストデータを大量に生成する。 テストコードの自動記述: E2Eテストや単体テストのコード（例: Selenium, JUnit）を生成・修正する。 バグ報告の初期分析: ログやエラーメッセージをAIが分析し、原因のあたりをつけたり、バグ報告書を自動起票したりする。 リグレッションテストの最適化: コードの変更箇所を解析し、影響範囲を特定。実行すべきテストケースを最小限に絞り込む。 これらが実用レベルになれば、テストにかかる工数や時間は劇的に減少するでしょう。もはや「テストは作業工数で頑張るもの」という時代は終わりを告げ、 生成AIの活用を前提とした新しいテストプロセス が主流になる。これが、私たちが「変革期」と呼ぶ理由です。 ※1 IPA 独立行政法人 情報処理推進機構 新しい視点：AI時代に「本当に」求められるスキルとは？ 視点を変えてみましょう。テスト作業の多くをAIが担うようになったら、エンジニアの価値はどこにあるのでしょうか？ ここで、一つの重要な視点があります。それは、 「生成AIを活用するためには、基礎的なビジネスリテラシーが、むしろ以前より重要になる」という逆説的な事実です。 生成AIは「万能の魔法」ではありません。AIは「指示されたこと」しかできません。 そして、その指示が曖昧で不明確であれば、AIが生み出すアウトプット（テストケースやコード）もまた、曖昧で使い物にならないものになります。 つまり、私たちが獲得すべき新しい知的スキルとは、以下の3つに集約されます。 1. 高度な「仕様読解力」と「要件定義能力」 AIに的確なテストケースを生成させるためには、 エンジニア自身が、その機能の「要件」と「仕様」を完璧に理解している 必要があります。 「この機能の目的は何か？明示的、暗示的な意味は何か？」 「ユーザーにとっての本当の価値はどこにあるのか？」 「仕様書のこの一文の『行間』に隠された暗黙の前提条件はどこにあるのか？」 要件を深く理解し、AIが解釈できる明確な言葉（プロンプト）に落とし込む能力。 これこそが、AI時代のテストエンジニアに求められるメインスキルです。 曖昧なテスト仕様書を渡されて「あとはAIさん、よろしく」は成立しません。 AIを使いこなす前提として、人間の本質的な能力と知見、深い洞察力が問われるのです。 2. 「論理的思考」に基づくテスト設計能力 AIが何千ものテストケースを生成したとして、その妥当性を誰が判断するのでしょうか？ 「網羅性、カバレッジは十分か？」 「重要な観点（セキュリティ、パフォーマンス、ユーザビリティ）が抜けていないか？」 「AIが“見落としているケースはないか？将来の潜在リスクはないか？」 これらを判断するには、基本仕様の理解やテスト設計の原理原則（同値分割、境界値分析、状態遷移など）を深く理解した上での「論理的な思考力」が不可欠です。 AIは「作業」自体は高速化しますが、「基本設計の思想」や「品質保証」を担保してくれるわけではありません。AIの出力を鵜呑みにせず、クリティカルに評価し、テスト戦略全体を設計する「知的アーキテクチャ」としての役割が重要になります。 3. 基礎的な「読み書き能力」 ここでいう「読み書き能力」とは、言語化力そのものです。 書く力: AIへの的確な指示（プロンプトエンジニアリング）、ステークホルダー（開発者、PM）への明瞭なバグ報告、AIが生成したドキュメントの校正。 読む力: 膨大な仕様書の本質を掴む読解力、AIの生成物を迅速にレビューする能力。 結局のところ、私たちの仕事は「言葉」で成り立っています。AIという新しい”仲間”と正確にコミュニケーションを取り、プロジェクトを円滑に進めるための「読み書き能力」の重要性は、かつてないほど高まっていると考えます。 まとめ：変革を乗りこなし、新しい価値を生み出すAIテストエンジニアへ 生成AIの登場により、「ソフトウェア産業」全体が抜本的に変わることは間違いありません。特に、ソフトウェアテストの現場は、その影響を最も強く受ける領域の一つです。 テストエンジニアの役割は、「手を動かしてテストを実行する人」から、「AIを駆使して、品質レベルをどのように高めて、どう保証するかを設計・判断・評価する人」へとシフトしていくでしょう。 こうした変革の中で、実際のテスト現場でも新しいAI駆動型のソリューションが登場し始めています。 例えば、AGESTが展開する次世代AIテストツール『TFACT』のように、生成AIの力をテストの標準プロセスに組み込んだAIプラットフォームもその一つです。 ■AGEST AIテスト管理ツール ｜ TFACT 自律走行型AIソリューションは、私たちのテストプロセスを劇的に効率化してくれる強力なパートナーとなり得ます。 そして、AIに意図通りのテストを行わせるためには、曖昧さを排除し、「正確な言葉」で表現する力が不可欠です。ツールが進化すればするほど、そのツールを指揮する人間の「言語化能力」や「論理的思考」の価値はむしろ高まるのです。 若手エンジニアへのエール 若手エンジニアの皆さんにとって、この変革は「脅威」ではなく、むしろ「チャンス」です。なぜなら、ベテランエンジニアが長年の経験で培ってきた「経験」や「勘」の一部をAIが補完し、若手エンジニアは新しい発想とAIツールで勝負できるからなのです。 今、身につけるべきは、特定のツール操作ではなく、 1. 仕様を深く読み解く力。 2. 物事を論理的に考える力。 3. 要件を深く理解し正確な言葉で表現しATに的確なプロンプトを定義できる力。 という、極めて「基礎的」で「普遍的」なスキルです。 このAI変革の波を恐れず、AIという強力な仲間を使いこなし、ソフトウェアの品質を支えるプロフェッショナルとして、共に未来に向けて成長していきましょう。 プロフィール： QAエンジニアなおた 前世紀は主に大手携帯通信事業者の海外（米国・英国・インド）新規事業開発マネジャーとして従事。 今世紀は、主に自動車向けコネクテッドカーの企画コンサルティング、開発実務の支援、実装テスト関連のPMを経験。近年は幅広い企業クライアント向けQAコンサルタントとして活動中。 The post 生成AIはソフトウェアテストを”破壊”するのか？ ー 若手エンジニアが備えるべき「変革」と「新しいスキル」 first appeared on Sqripts .

はじめに Amazon OpenSearch Service を使用したベクトル検索では exact k-NN もしくは Approximate k-NN が使用されます。exact k-NNでは総当たり的に近傍を探索することにより最も正確な検索が可能ですが、ベクトルデータ数に対して線形に実行時間が増えるため、大規模なデータセットに対しては深刻にパフォーマンスが悪化する可能性があります。一方で Approximate k-NN は精度を一定落とす代わりに高速な検索を実現する手法です。Amazon OpenSearch Service において利用できるApproximate k-NNアルゴリズム用のベクトル検索エンジンは主に FAISS と Lucene があり、FAISS エンジンにはアルゴリズムとして HNSW と IVF があります( 参考 )。 本ブログでは、FAISS エンジンを使用したベクトル検索において、 新規ベクトルデータの投入が不安定、または失敗する場合 の原因調査および対処法選択の考え方について説明します。 シナリオ：新規ベクトルデータの投入が不安定、または失敗する 一度ベクトルデータベースのセットアップが完了し問題なく稼働していたとしても、検索対象となるドキュメント数が増えたり、使用するユーザー数が増加していくと様々なトラブルが発生する可能性があります。OpenSearch Service におけるトラブルはインスタンスタイプの増強によるスケールアップやノード数追加によるスケールアウトをすることで解決できることは多いですが、何らかのトラブルに対して原因調査を行い、コストや精度、レイテンシーといった要素のトレードオフを理解した上で適切な対処手法を選択していくことは OpenSearch Service を有効活用していく上で非常に重要です。 FAISS エンジンにおけるベクトル検索を使用する場合のトラブルの一つとして、新規ベクトルデータの投入が不安定だったり、失敗する場合が考えられます。次元数の多いベクトルデータを Bulk API などで投入する場合、インデクシングに要する負荷は大きくなりがちです。特に、ベクトル検索を高速化するためのグラフ構造を保持するメモリのようなリソースのキャパシティ枯渇が問題になることが多いです。 調査および対処法選択の大まかな流れは以下にようになります。 新規ベクトルデータの投入が不安定、または失敗する場合の対処法選択 ベクトル検索を行う際にしばしば問題になるのがメモリ管理です。新規ベクトルデータの投入がブロックされる場合、使用メモリサイズ増加に伴いサーキットブレーカーが発動している可能性があります。OpenSearch 自体は Java により実装されており、デフォルトでは、各ノードが持っているメモリ領域の 50% か 32GB の大きい方が JVM ヒープとして使用されます。残りの領域がネイティブメモリとして、OS やファイルシステムキャッシュ、そして k-NN ベクトルの検索用メモリとして使用されることになります。 OpenSearchベクトル検索におけるメモリ管理 原因調査1.1: KNNGraphMemoryUsage によるネイティブメモリ使用状況の調査 ベクトル検索を行う際にしばしば問題になるのがメモリ管理です。新規ベクトルデータの投入がブロックされる場合、使用メモリサイズ増加に伴いサーキットブレーカーが発動している可能性があります。OpenSearch 自体は Java により実装されており、デフォルトでは、各ノードが持っているメモリ領域の50%か 32GB の大きい方が JVM ヒープとして使用されます。残りの領域がネイティブメモリとして、OS やファイルシステムキャッシュ、そして k-NN ベクトルの検索用メモリとして使用されることになります。 CloudWatch メトリクスを参照して、データノードにおける KNNGraphMemoryUsage もしくは KNNGraphMemoryUsagePercentage を参照することで、ネイティブメモリのうちどの程度をベクトルグラフが占有しているかモニタリングすることができ、大きなベクトルデータを扱っている場合非常に重要なドメインサイジングの指標になります。 特に FAISS エンジンで HNSW のインデックスを作成している場合、検索を高速化するためベクトルデータ投入時にグラフ構造が構築されます。検索クエリが実行された際、もしくは Warm-up API が呼ばれた際にこのグラフはネイティブメモリにロードされますが、グラフのデータサイズが大きくなると上記の k-NN 用ネイティブメモリサイズを超過し、サーキットブレーカーが発動する可能性があります。これに伴い、インデックスは新規ベクトルデータの投入をブロックするようになります。 サーキットブレーカーが発動するメモリサイズに関しては、 knn.circuit_breaker.limit （デフォルト 50%）に設定されており、この値に対して上記メトリクスが猶予を持っている必要があります。 各ノードの k-NN に関する統計情報は以下のコマンドによっても取得することが可能です。サーキットブレーカーによりデータ投入がブロックされている場合、レスポンスに含まれる circuit_breaker_triggered の値が true になります。 GET /_plugins/_knn/stats このシチュエーションにおいて、ベクトルグラフによるメモリ使用を削減する、もしくはメモリを増強する対応が必要になります。 原因調査1.2：FreeStorageSpace によるディスク容量の確認 CloudWatch メトリクスの一つである、 FreeStorageSpace を参照することで、OpenSearch Service における各ノードがどの程度のストレージ残量があるかを調査することができます。 OpenSearch Service は各データノードのストレージの 20%（最大 20 GiB）を、セグメントマージやログなどの内部操作用にあらかじめ予約しています。CloudWatch メトリクスの FreeStorageSpace はこの予約分を差し引いた後の残量を示すため、OpenSearch の _cluster/stats や _cat/allocation API が返す値よりも常に低い値になります。 ストレージ保護の観点では、いずれかのノードの空き容量が「利用可能ストレージの 20%」または「20 GiB」のうち小さい方を下回った時点で、書き込み操作をブロックします（ ClusterBlockException ）。ブロック機構は、OSS の OpenSearch が持つ disk watermark （low: 85%、high: 90%、flood_stage: 95%）よりも先に発動するのが一般的です。 FreeStorageSpace メトリクスを監視し、CloudWatch アラームを設定することで、ブロック発生前にストレージ逼迫を検知できます。 対処1.1：量子化 OpenSearchにおけるベクトルは knn_vector 型の32ビット浮動小数点配列として保存されますが、これらをよりデータ量の小さなベクトルに圧縮するアプローチです。以下の4つの量子化手法をサポートしています。より圧縮度の高い量子化は検索の精度を落とす可能性がありますが、メモリ使用量の削減だけでなく、検索パフォーマンスの向上やディスク使用量の削減にもつながります。精度要件に余裕があり、検索速度を維持もしくは高速化した上でメモリ効率化も行いたい場合有用な手法です。 詳細に関しては こちら のブログも参照ください。 スカラー量子化 (Scaler Quantization) バイナリ量子化 ベクトルの各次元を 1 ビット（-1 または +1）で表現する最も圧縮率の高い量子化手法。最大 32 倍と大幅にメモリ、ストレージ使用量を低減できますが、精度の低下が最も大きくなります。 バイト量子化 各次元を 8 ビット整数（int8）で表現し、元の浮動小数点数を 256 段階に量子化する手法。メモリを約 1/4 に削減しつつ、比較的高い精度を維持できるバランスの良い方式です。 FP16量子化 32 ビット浮動小数点数（FP32）を 16 ビット浮動小数点数（FP16）に変換する手法。メモリを半分に削減し、精度の劣化が少ないため、高精度が求められる用途に適しています。 直積量子化（Product Quantization） ベクトルを複数のサブベクトルに分割し、各サブベクトルを独立にクラスタリングしてコードブックで表現する手法。最大 64 倍と高い圧縮率と高速な検索を両立でき、大規模ベクトル検索でしばしば使用されますが、利用にあたり事前のトレーニングが必要になります。 対処1.2：Memory Optimized Search (対象：HNSW、バージョン3.1+) Lucene エンジンと FAISS エンジンのハイブリッドアプローチを行うことで、ベクトルグラフの全てをメモリに載せることなく検索を実行することが可能です。数% の Recall およびスループットの低下が生じる可能性がありますが、3〜4 倍のメモリ使用量削減の可能性があります。この手法を使用する場合、グラフの一部を載せるメモリとして OS ページキャッシュを使用するため、 KNNGraphMemoryUsage は増加しません。 ベンチマーキングなどは こちら のブログから参照ください。以下のように、 knn.memory_optimized_search を設定することにより有効化できます。この手法の特徴として、index 単位で有効化する場合は reindex が必要ないことが挙げられます。index の設定のみで有効化できるので手軽にメモリ使用量削減が可能です。 PUT /<index-name> { "settings" : { "index.knn": true, "index.knn.memory_optimized_search" : true }, "mappings": { <index-fields> } } 対処1.3： Disk mode (対象：バージョン2.17+) ディスクベースのベクトル検索では、量子化したベクトルのみをメモリに乗せサンプリングを行い、ディスク上の完全な精度のベクトルでリランクを行う手法です。量子化の圧縮率を選択することにより、メモリに載せるベクトルデータのサイズを最大 32 倍低減することができますが、精度の低下は最小限に抑えることが可能です。 検索速度の低下を許容できるワークロードでありつつ、精度の低下をおさえて最大限のメモリ効率を実現したい場合有用な手法です。 以下のように、 knn_vector のフィールドの mode を on_disk に設定することで有効化できます。量子化の圧縮率は compression_level として指定することができ、FAISS エンジンでは 1x 、 2x 、 8x 、 16x 、 32x が選択可能です。 PUT /<index-name> { "settings" : { "index": { "knn": true } }, "mappings": { "properties": { "my_vector_field": { "type": "knn_vector", "dimension": 8, "space_type": "innerproduct", "data_type": "float", "mode": "on_disk", "compression_level": "16x" } } } } 対処1.4：EBSボリュームの追加 OpenSearch Service におけるデータノードはストレージとして EBS ボリュームを使用しています。データノードのストレージが枯渇した際、クラスターの設定からノードあたりの EBS ストレージサイズを追加することで非常に簡単に対処することができます。データノードあたりの EBS ストレージの最大サイズは 1536 GiB です。 クラスター自体のデータノード数を増やしたり、データノードのインスタンスタイプをより大きいものに変更するのに比べてコスト効率よく手軽にストレージ枯渇に対処できる手法になっています。 CLI では以下のオペレーションによって設定変更可能です。 aws opensearch update-domain-config \ --domain-name your-domain-name \ --ebs-options '{ "EBSEnabled": true, "VolumeType": "gp3", "VolumeSize": 1024 }' まとめ 本ブログでは、OpenSearch Service において FAISS エンジンを使用したベクトル検索ワークロードを運用している際に発生しうるトラブルとして新規ベクトルデータの投入が不安定、または失敗する場合に着目し、その原因究明と対処方法選択の考え方について紹介しました。このトラブル自体はベクトルグラフのメモリに起因することがおおく、OpenSearch が提供するメモリ最適化手法の中から適切な選択を行っていくことが重要です。 OpenSearch Service の機能は継続的に拡充されているため、新機能を活用するためにもクラスターのバージョンアップグレードを定期的に検討することを推奨します。 著者 黒木 琢央 (Takuo Kuroki) アマゾンウェブサービスジャパン合同会社ソリューションアーキテクト 2024年4月入社。現在toCのITサービス提供企業におけるクラウド全般の技術支援を行いつつ、OpenSearchのコミュニティ活動や機能改善に取り組んでいます。