Amazon Web Services ブログ

大豊建設が AWS で実現した大豊 AI：業務の様々な場面で活躍する生成 AI 活用事例

Suguru Sugiyama — Wed, 08 Apr 2026 12:20:55 +0000

はじめに

本ブログは大豊建設株式会社様と Amazon Web Services Japan 合同会社が共同で執筆しました。

みなさん、こんにちは。ソリューションアーキテクト杉山卓です。

本ブログでは、大豊建設様が AWS を基盤として生成 AI を活用した「大豊 AI」を構築し、社内で活用されている取り組みを紹介します。議事録の自動生成、資料の要約、社内規程の検索、そして日常的な疑問への回答まで、業務の様々な場面で活躍しています。

2025 年 6 月の全社展開から約 8 ヶ月で、307 名の社員が利用し、累計 32,709 回以上の利用回数を記録するなど、幅広く活用されています。規程検索だけでも約 250 時間の業務時間削減を実現し、文書作成やファイル分析を含めると、さらに大きな効果が生まれています。今後は、施工計画書の作成支援や社内資料作成支援といった、エージェント技術を活用した業務効率化も目指しています。

建設企業が直面する業務効率化の課題

大豊建設様は、土木・建築工事を中心とした総合建設会社です。現場での施工管理や営業活動において、情報へのアクセス、文書作成、そして知識の共有は業務品質を維持する上で重要な要素です。

しかし、大豊建設様では長年、業務効率化において複数の課題を抱えていました。

まず、社内の情報にアクセスしにくいという問題がありました。従来の文書管理システムでは、フォルダ構成が複雑で、どこに何の情報が格納されているのかが分かりにくい状態でした。「社内規程は、月に数回の頻度でアップデートが必要です」と大豊建設の落藤様が語るように、監査室の指摘や法改正に伴い社内規程が頻繁に更新されます。変更された規程がどこに格納されているのか探すのに時間がかかり、キーワード検索を利用しても意図しない文書まで検索結果に含まれてしまうという問題がありました。

社内規程の検索は、出張旅費規程のような全社員に関わるものから、土木工事における業者との契約に関する専門的なものまで多くの種類があります。現場監督や営業担当者が必要な情報を素早く見つけられないことは、業務効率の低下だけでなく、コンプライアンス上のリスクにもつながっていました。

また、工事が完了すると完成資料がシステムに格納されますが、その後は十分に活用されないまま保管されるだけでした。過去の類似工事の知見を活かすことができれば、施工計画書の作成や見積もりの精度向上に役立つはずですが、そのための仕組みが整っていませんでした。

次に、文書作成の負担が大きいという課題がありました。資料や議事録の作成など、日々の業務には多くの文書作業が伴います。特に議事録の作成は、会議の内容を思い出しながら整理するのに時間がかかることも珍しくありません。

さらに、中堅社員不足による知識共有の難しさもありました。建設業界全体で抱える課題でもありますが、大豊建設様でも年齢層に偏りがあり、特に中堅社員と呼べる世代が不足しています。「現場によっては若手社員とベテランの所長がペアで工事を監督するケースも多く、若手からは『質問があっても聞くタイミングを逃しがち』という声を聴くことがありました」と落藤様は振り返ります。若手社員が基本的な疑問を気軽に相談できる環境が不足していました。

こうした課題を解決するため、生成 AI に法律や社内ルール、過去の知見などを連携させ、必要な情報を即座に得られるようにすることで、ミスを減らし、誰もが共通の情報にアクセスできる環境を整えることを目指されました。

「大豊 AI」を自作する挑戦

大豊建設様が生成 AI の活用を検討し始めたのは、2023 年末の頃でした。

それ以前から社内では竣工データの利活用を目指した検索システムの構築に取り組んでいました。しかし、検索精度を高めるためにはドキュメントへの適切なラベリングなど、システム外の運用負荷が高く、広く利用されるには至っていませんでした。

そういった中、生成 AI が登場しました。「人手によるラベリングなどの労力をある程度削減しながら、社内の文書検索ができるようになるのでは」という期待から、本格的な検討が始まります。さらに、同業他社が既に AWS 環境で生成 AI の検索システムを構築し、活用事例を発表していたことも後押しとなりました。「同業他社様ができるなら、私たちも実現できるはず」という前向きな姿勢で、大豊 AI を作成するプロジェクトを推進しました。

プロジェクトは段階的に進められました。2024 年 3 月、まずは LINE WORKS を使った AI ボットの構築から開始。モバイル端末から手軽に検索できる利便性を確認した一方で、長文のドキュメントを閲覧する際の見づらさといった課題も明らかになりました。

そこで 2024 年 10 月には、Web サイトでの提供へと方針を転換しました。同時に、生成 AI ワーキンググループを設置しました。本社だけでなく、各支店から業務に精通し、生成 AI 活用に興味を持つ 11 名のメンバーを集め、協力会社であるワンダーソフト株式会社の 1 名を含めた 12 名体制でスタートしました。

生成 AI ワーキンググループでは、2024 年 10 月から 2025 年 4 月まで、計 4 回のミーティングを実施しました。第一回では「こういうことをやった方が便利なのではないか」という機能要件を議論し、その後のミーティングでは構築した機能の説明と今後の方向性を全体で検討していきました。現場の声を取り入れながら段階的に機能を拡充していったことが、後の成功につながります。

そして 2025 年 6 月、全社員に大豊 AI の展開を開始しました。社内の掲示板などを通じて「大豊 AI を作ったので、ぜひ使ってみてください」と案内し、興味を持った社員から順次利用が始まっていきました。

実際にどのように活用しているのか

「大豊 AI で、実際にどんなことをしているのか？」という疑問は、DX 推進を検討する多くの方が持つものです。ここでは、現場での具体的な活用シーンを紹介します。

利用頻度の高い機能トップ 5

ワンダーソフト様の協力のもと、大豊 AI の利用状況を分析したところ、以下の 5 つの機能が多く利用されていることが分かりました。最も利用頻度が高いのはフリートークで、次いで社内規程検索、ファイルチャット、社内資料の全文検索、ユースケース別検索の順となっています。

以下、それぞれの機能について、具体的な使われ方を紹介します。

① フリートーク：気軽な質問から専門知識まで

フリートークは、生成 AI と自由に対話できる機能です。利用データを分析したところ、質問内容は以下のように分類されました。

日常的な質問や翻訳、Excel の関数検索など：60.9%
建設業に特化した専門的な質問：24.1%
文章生成：8.3%
文章の添削・校正：6.7%

一見すると専門性を有しない質問が 6 割を占めているように見えますが、これには意味があります。「身近なことを AI に気軽に質問する」という習慣が社内に根付くことで、本当に必要な時にスムーズに活用できる土台が形成されているのです。

メール作成：正確で丁寧な文面を手軽に

業務の中で、メールの作成は日々発生する作業の一つです。しかし、適切な言葉遣いや内容の整理に負担を感じることも少なくありません。特に、社外の取引先や発注者への連絡では、正しい敬語表現やビジネスマナーに沿った文面が求められるため、一通のメール作成に想定以上の時間がかかるケースもあります。

大豊 AI では、フリートークやユースケース別の「メール作成」テンプレートを活用することで、伝えたい要点を入力するだけで、正しい日本語で適切な文面を生成してくれます。例えば、「工事の進捗報告を発注者に送りたい」「会議日程の変更を関係者に連絡したい」といった要件を伝えるだけで、ビジネスメールとしてふさわしい構成・敬語表現を備えた文面が提示されます。メール作成は一見すると小さな業務に思えますが、1日に何通も作成する社員にとっては、積み重なることで大きな時間削減効果をもたらしています。

若手社員の学習支援

施工計画について分からないことがあっても、ベテランの方に聞くのは気が引けるという若手社員がいます。そんな時、フリートークで「〇〇工法のメリットとデメリットを教えて」「△△の場合の注意点は？」といった質問をすることで、基礎知識を習得できます。ある程度調査したうえでベテランの方に相談すればよいため、若手社員の心理的負担が軽減され、ベテラン社員の時間も有効活用できるようになりました。

② 規程検索：必要な情報に素早くアクセス

社内規程の検索は、大豊 AI 構築の当初からの主要な目的の一つでした。

従来の文書管理システムでは、フォルダ構成が複雑で、どこに何の情報が格納されているのかが分かりにくい状態でした。現在は、Amazon Bedrock Knowledge Bases を活用した検索機能により、自然な文章で質問するだけで、関連する規程を見つけられるようになりました。

③ ファイルチャット：文書分析の効率化

ファイルチャットは、PDF などのファイルをアップロードして、その内容について AI に質問できる機能です。議事録作成、文書の内容確認、添削など、様々な場面で活用されています。

議事録の自動生成

最も効果が大きいのが、議事録の自動生成です。工事現場では定期的にミーティングが実施されます。従来は、会議後に記憶を頼りに議事録を作成していましたが、これには時間がかかることもありました。

現在は、会議を文字起こしでテキスト化し、それを PDF にして大豊 AI のファイルチャットにアップロードします。「この内容から議事録を作成して」と依頼すると、大豊 AI が議事録の初稿を生成してくれます。担当者は手直しするだけで完成するため、議事録作成にかかる時間が大幅に短縮されました。

この仕組みは海外の現場でも活用されています。大豊建設様では海外での事業も展開しています。現地の言語で行われた会議の内容を整理し、議事録として仕上げる作業は従来大きな負担でしたが、大豊 AI を活用することでこの工程が大幅に効率化されました。国内・海外を問わず、同じ仕組みで業務効率化が実現されています。

④ 社内資料の全文検索：過去の知見と法令情報への横断アクセス

大豊 AI の検索対象は社内資料から外部サイトまで多岐にわたります。外部サイトの例として、法令に関する資料が掲載されている政府の「e-Gov」から労働安全衛生法などの情報を PDF 化して検索対象としています。「手すりの高さに関するルールを教えて」と質問すると、大豊 AI は e-Gov から取得した法令データと社内規程を横断検索し、関連する情報を提示します。複数の資料を探し回る必要がなくなり、正確な情報に素早くアクセスできるようになりました。

⑤ ユースケース別検索：AI 初心者にも使いやすいテンプレート機能

大豊 AI は、リリース当初、ユーザー自身でプロンプトを設定できる仕様にしていました。しかし、AI 初心者にとって詳細なプロンプト設定は難易度が高く、利用の障壁となっていることが判明しました。そこで、管理者側で一般的なユースケース別にプロンプトを事前設定し、ユーザーは選択するだけで利用できる機能を開発しました。2025 年 12 月にリリースしたこの機能は、利用回数の上位にランクインしており、一定の需要があることが確認できています。

現在提供している 8 種類のユースケースは以下の通りです：

文書校正
文書チェック
議事録作成
議事録要約
メール作成
Excel 関数検索
用語解説
翻訳

自社業務に最適化できる生成 AI 基盤の選択

これらのユースケースを支える技術基盤として、大豊建設様は AWS を選択しました。その理由は大きく三つあります。

まず、既存システムとの統合のしやすさです。大豊建設様では、社内アプリケーションの多くをワンダーソフト様に依頼して構築していました。これらのアプリケーションは AWS 環境で稼働しており、生成 AI を組み込む際にも同じ基盤を活用することで、スムーズな連携が可能になると考えたのです。「AWS で稼働している既存の社内アプリに生成 AI 機能を追加する際には、セキュリティや実装における利便性などで AWS が最適」という判断でした。

次に、カスタマイズの自由度の高さです。世の中にある SaaS やパッケージ化された生成 AI サービスは、自社の業務要件に合わせた柔軟なカスタマイズが難しい場合があります。大豊建設様では、社内規程だけでなく、外部の法令サイトの情報や、建築部門で配信している資料など、多様な情報源を統合して検索できるようにしたいという要望がありました。AWS を基盤とすることで、こうした独自の要件に対応でき、「自分たちがやりやすくて、見やすいものができるのでは」と考え、カスタマイズ性の高さを評価しました。

そして、AWS チームとの協業体制です。ワンダーソフト様は次のように語ります。「実装における AWS サービスのインテグレーションが簡単な点が AWS を選定した一つのポイントです。ドキュメントが充実しているのは、生成 AI 以前から感じていました。また、AWS の担当アカウントチームとの打ち合わせを通じて情報提供をいただけるのは大変ありがたい。」と支援体制を評価しました。

また、将来的には、グループ会社や他社への展開も視野に入れる中で、「AWS Blog で事例化」という形で外部に実績を示すことができるのは、さらなる展開を目指すうえでも有効だと考えています。

システム構成と技術的な工夫

大豊建設様が構築した「大豊 AI」システムは、Amazon Bedrock を中心とした AWS サービスで構成されています。認証基盤には Auth0 を利用していますが、基本的には AWS のサービスで統一されています。

主要な AWS サービスは以下の通りです。

Amazon Bedrock：さまざまなAI基盤モデルをAPI経由で簡単に利用できるフルマネージドサービス
Amazon Bedrock Knowledge Bases：RAG 検索の実装
AWS Lambda：アプリケーションロジックの実行
Amazon S3：社内ドキュメントを格納するためのオブジェクトストレージ

プロジェクトを進める中で、いくつかの技術的な試行錯誤がありました。

当初は Amazon Kendra を使用していましたが、検索精度の課題、特に社内規程に含まれる表の取り扱いが難しかったため、Amazon Bedrock Knowledge Bases へ移行しました。特に、PDF を一枚丸ごと取り込んで表示できる「Advanced RAG」の機能が有効だったとワンダーソフト様は語ります。今後は、Amazon S3 Vectors を利用したコスト削減についても検討を進めていく方針です。

また、新しいモデルが登場した際に、それを大豊 AI に積極的に取り込む点にもチャレンジしています。バージニア北部やオレゴンなどのリージョンでは素早くモデルが追加されるため、それを大豊 AI に取り込むことで、最新モデルを活用できる体制を構築しています。モデルの更新に加え、ユーザーの利便性向上にも日々取り組んでいます。

エージェント技術による次なる業務変革への挑戦

大豊建設様の生成 AI 活用は、エージェント技術を積極的に取り込み、以下の方針でこれからも取り組みを続けていきます。

エージェント機能の実装

Amazon Bedrock AgentCore を活用し、次の二つの業務領域での自動化を検討しています。

施工計画書の作成支援

工事が始まる前に作成する施工計画書は、ゼロから作成するのが大変な業務です。現場の担当者は過去の竣工データから類似工事の施工計画書を探し出し、参考にして作成していますが、この作業を AI エージェントが支援することで、大幅な効率化が期待されています。

社内資料の作成支援

「パワーポイントでこのファイルを作って」といった指示に基づいて、AI が資料の初稿を作成し、担当者が最終調整を行うワークフローの実現を目指しています。既存の資料に対して「この部分を変更して」といった細かい要望にも対応できることを目指しています。

まとめ

大豊 AI は検索システムとして始まりましたが、実際には文書作成、ファイル分析、相談相手など、業務の様々な場面で活用されています。単一の用途に限定せず、ユーザーが自由に活用できる環境を提供することで、想定以上の効果が生まれました。フリートークでの時事ネタの質問も、「AI を気軽に使う習慣」を醸成し、本当に必要な時にスムーズに活用できる土台となっています。

生成 AI の活用は、単なる技術導入ではなく、業務プロセスの再設計や組織文化の変革を伴う取り組みです。「入社当時はまだフロッピーディスクを使用していましたが、10 年を経て最新エージェント技術へ」という落藤様の言葉に象徴されるように、新たなことに挑戦する姿勢は、建設業界における生成 AI 活用のモデルケースとして大いに参考になります。

Kiro スタートアップクレジットプログラムが復活します

Mizuki Ugajin (syobochim) — Wed, 08 Apr 2026 07:09:39 +0000

本記事は 2026 年 4 月 7 日に公開された Deepak Singh の「We’re bringing back the Kiro startup credits program」を翻訳したものです。

起業家の皆さん、12 月のスタートアップクレジットにたくさんのご応募をいただきありがとうございました。昨年 Kiro スタートアップクレジットプログラムを開始した際、その反応は予想を大きく上回るものでした。数千もの応募が寄せられ、ニーズは明確でした。アーリーステージのチームには、成長に合わせてスケールする開発者ツールが必要だということです。

そこで、このプログラムを復活させます。本日より、対象となるスタートアップは最大 1 年分の Kiro Pro+ を無料で申請できます。仕様駆動開発と高度な AI エージェントを活用して、コストを気にせず開発を加速できます。

提供内容

アーリーステージから Series A までのスタートアップであれば、最大 1 年分の Kiro Pro+ クレジットを受け取れます。クレジットは AWS アカウントに自動的に適用されます。チーム規模に応じて 3 つのティアを用意しています。

Starter ティア – 最大 2 ユーザー
Growth ティア – 最大 10 ユーザー
Scale ティア – 最大 30 ユーザー

申請は順次審査し、結果はメールでお知らせします。ティアのユーザー上限を超えた場合や Pro+ 以上にアップグレードした場合は、追加料金が発生することがあります。

注意: すでに AWS Activate クレジットを受け取っている場合、本プログラムの対象外となります。

仕様駆動開発が重要な理由

IDE でも CLI でも、すぐにコードを書き始めるスタイルでも事前に計画・設計するスタイルでも、Kiro はツール、環境、チームを横断して AI コーディングに構造をもたらします。私たちが仕様駆動開発を推進しているのは、構造化によってコード品質が向上し、手戻りが減り、開発時間全体を短縮できると確信しているからです。多くのツールを使い分けたり、プロンプトエンジニアリングに何時間も費やす代わりに、Kiro では要件を定義するだけで、テスト済みのコードを数分でリリースできます。ドキュメント作成、テスト、レビューは AI エージェントが自動で処理するため、本当に重要なプロダクト開発に集中できます。

MVP からプロダクトマーケットフィットへ進む起業家にとって、これはすべてを変える力になります。イテレーションが速くなり、チームの足並みが揃い、複雑さが増してもスケーリングがボトルネックになりません。開発速度は短距離走ではなく、持続可能な前進になります。

「Kiro のおかげで開発チームをスケールでき、デバッグの高速化、テストカバレッジによるコード品質の向上、革新的な PoC の迅速な作成が可能になりました。テスト開始まで 24〜32 週間かかると見積もっていたプロジェクトが、わずか 5〜7 週間で完了しました。現在、Terraform コード、ユニットテスト、Playwright のオブジェクトモデルの 80% を Kiro で生成しており、プラットフォームチームは週 8〜12 時間を節約しています。さらに、MCP サーバーやエージェント全体を 80% の AI 支援で構築できるようになりました。これはイノベーションのスピードを根本から変える成果です。」 — Matthew Trevathan、SVP Architecture and Innovation、Nymbus

「CoverTree では、住宅向けの保険商品とインフラを構築しています。複雑なルール、エッジケース、そして間違えれば実際のコンプライアンスリスクにつながる領域です。何を作るのか、どう作るのかを明確にすることが日々欠かせません。Kiro は、適切な場面で立ち止まり、コードを書く前に要件をしっかり考える習慣をチームにもたらしてくれました。Kiro 導入以降、自動テストカバレッジは 60% 以上向上し、テストやドキュメント作成にかかる時間は約 60〜70% 削減されました。以前はテスト可能な状態になるまで 3〜4 週間かかっていた機能が、今では数日で準備できます。Kiro は要件定義からテスト生成、コードレビューまで、コアとなるエンジニアリングの作業全体で活用されています。日々の開発プロセスの一部となっており、プロダクトの成熟とともに Kiro チームと一緒に成長していけることを楽しみにしています。」 — Divyansh Sharma、Co-founder and CTO、CoverTree

申請方法

本プログラムはほとんどの国でグローバルに利用可能です。今すぐ申請して、Kiro で 1 年間の高速開発を始めましょう。利用規約もご確認ください。

ハッシュタグ #KiroforStartups または #BuildwithKiro を使って、あなたが作っているものをぜひ共有してください。X、LinkedIn、Instagram では @kirodotdev、Bluesky では @kiro.dev でお待ちしています！

スタートアップ向けのその他のリソース

AWS Activate は Amazon Web Services のスタートアップ専用プログラムで、プロモーションクレジット、テクニカルサポート、ビジネスリソースを提供し、構築とスケーリングを支援します。コンピューティングや機械学習からデータベース、セキュリティまで、AWS Activate はスタートアップの成長に必要なインフラとサポートを提供します。

お困りですか？ Kiro コミュニティの Discord に参加して、他のビルダーとつながり、ベストプラクティスを共有し、テクニカルサポートを受け、最新機能の情報を入手しましょう。コミュニティがあなたの成功をサポートします。

翻訳は App Dev Consultant の宇賀神が担当しました。

Amazon OpenSearch Service、FAISS エンジンでのベクトル検索トラブル対処の考え方：新規ベクトルデータの投入が不安定、または失敗する場合

Takuo Kuroki — Tue, 07 Apr 2026 06:37:56 +0000

はじめに

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 などで投入する場合、インデクシングに要する負荷は大きくなりがちです。特に、ベクトル検索を高速化するためのグラフ構造を保持するメモリのようなリソースのキャパシティ枯渇が問題になることが多いです。
調査および対処法選択の大まかな流れは以下にようになります。

新規ベクトルデータの投入が不安定、または失敗する場合の対処法選択

原因調査1.1: KNNGraphMemoryUsage によるネイティブメモリ使用状況の調査

ベクトル検索を行う際にしばしば問題になるのがメモリ管理です。新規ベクトルデータの投入がブロックされる場合、使用メモリサイズ増加に伴いサーキットブレーカーが発動している可能性があります。OpenSearch 自体は Java により実装されており、デフォルトでは、各ノードが持っているメモリ領域の50%か 32GB の大きい方が JVM ヒープとして使用されます。残りの領域がネイティブメモリとして、OS やファイルシステムキャッシュ、そして k-NN ベクトルの検索用メモリとして使用されることになります。

OpenSearchベクトル検索におけるメモリ管理

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のコミュニティ活動や機能改善に取り組んでいます。

Amazon OpenSearch Service、FAISS エンジンでのベクトル検索トラブル対処の考え方：検索レイテンシの増加が問題になっている場合

Takuo Kuroki — Tue, 07 Apr 2026 06:35:35 +0000

はじめに

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 において検索リクエストに対するパフォーマンスはユーザーの視点でもクラスター全体の健全な運用をする上でも重要な要素です。ベクトル検索ワークロード構築初期においてはデータ量が少ないため大抵の場合検索レイテンシーが問題になることはありませんが、検索対象となっているベクトルデータや新規に投入されてインデクシングされるベクトルが多くなるにつれて、さまざまな要因により検索レイテンシーが悪化する可能性があります。このような問題は単純な、検索パフォーマンスが悪化しているタイミングや CPU リソースやメモリの使用状況からどのようことが要因となっているか調査し、対処法を選択することが重要です。インスタンスタイプを増強したり、データノード数を増やすなどの対応によりクラスター全体のキャパシティを大きくすることでこのような問題に対処できることは多いですが、ここではその前段階として検討すべき最適化の手法について紹介します。
調査および対処法選択の大まかな流れは以下にようになります。

原因調査2.1：JVMMemoryPressure、CPUUtilizationの確認

検索パフォーマンスが悪化している場合などにおいて調査すべきメトリクスの一つが JVMMemoryPressure および CPUUtilization です。これらのメトリクスは AWS コンソールの OpenSearch Service ページにおける、ドメインの Cluster Health および CloudWatch Metrics から調査することができます。
JVMMemoryPressure や CPUUtilization を確認することにより、検索およびインデクシングといった処理にどの程度の負荷がかかっているかが確認できます。JVMMemoryPressure は JVM ヒープメモリの使用率であり、CPUUtilization はデータノードにおける CPU 使用率です。k-NN グラフ構築などのデータ投入処理やセグメントのマージなどで上昇します。これらのメトリクスが高い値を示している場合は、クエリやデータ投入のパフォーマンスが悪化している可能性があります。一般的に JVMMemoryPressure は 75% 以上になると GC が発生しますが、インデクシングや検索リクエストの処理が追いつかない場合 GC が多発し、JVMMemoryPressure も下降しない状態になります。さらに 95% に到達するとサーキットブレーカーにより新規リクエストを拒否します。

原因調査2.2：シャードの偏り状況の調査

OpenSearch Service のドメインでは、シャード分布がノード間で偏りが生じることにより特定のノードに処理が集中する場合があります。このような場合、ドメイン全体のリソース状況に余裕があったとしてもノード単体のリソース不足によりパフォーマンスに支障をきたす可能性があります。
以下のコマンドにより、ノードごとにシャード数やデータ量の偏りがないか調査することができます。

GET _cat/allocation?v

また、以下のコマンドにより、シャードごとのデータ量に偏りがないか調査することができます。

GET _cat/shards?v

また、シャードごとの集計情報は Cluster Insights を確認することでも簡単に調査できます。OpenSearch UI から Cluster Insights を開き、対象となる OpenSearch ドメインを選択します。Shard view と記載されたタブを開くことで直近使用されている index の各シャードごとの集計情報が表示されます。

対処2.1：シャード最適化

各シャードが持つドキュメントのサイズを調整したり、ノードに存在するシャード数の偏りを解消することで検索パフォーマンスが改善する場合があります。ベクトル検索のインデックスにおいて、適切なシャードサイズは一般的に 10GB〜75GB とされています。検索クエリが、ベクトル検索に加えて様々な全文検索を加えたハイブリットなものである場合、シャードサイズを小さくすることで検索レイテンシを改善する効果があります。一方で、シャードサイズを大きくすることで純粋なベクトル検索クエリに対してはパフォーマンス改善につながる可能性があります。また、ノードごとにシャードの偏りが発生している場合は、プライマリシャード数をノード数の倍数にすることで偏りを解消でき、検索パフォーマンス改善につながる可能性があります。

インデックスのシャード数を変更する場合、Shrink API の実行や reindex による index 移行を行う必要がありますが、reindex 中は CPU 負荷が増大することや index 移行に際して実行中のワークロードに影響を与えないよう注意が必要です。

対処2.2：量子化

スカラー量子化 (Scaler Quantization)

バイナリ量子化
ベクトルの各次元を 1 ビット（-1 または +1）で表現する最も圧縮率の高い量子化手法。最大 32 倍と大幅にメモリ、ストレージ使用量を低減できますが、精度の低下が最も大きくなります。
バイト量子化
各次元を 8 ビット整数（int8）で表現し、元の浮動小数点数を 256 段階に量子化する手法。メモリを約 1/4 に削減しつつ、比較的高い精度を維持できるバランスの良い方式です。
FP16量子化
32 ビット浮動小数点数（FP32）を 16 ビット浮動小数点数（FP16）に変換する手法。メモリを半分に削減し、精度の劣化が少ないため、高精度が求められる用途に適しています。

直積量子化（Product Quantization）

対処2.3：force merge、warm upの事前実行

FAISS エンジンでは、初回の検索クエリを行う際にベクトルグラフをメモリにロードする必要があり、これに非常に時間がかかる場合があります。事前に Warm-up APIを使用してグラフをメモリにロードすることにより初回検索のレイテンシを低減することが可能です。

GET /_plugins/_knn/warmup/<index-name>

また OpenSearch において、投入されたデータは最初セグメントと呼ばれる単位で管理されます。このセグメント数が大きくなると検索パフォーマンスの低下につながります。Warm-up 実行の前に Force Merge API を実行することでセグメント数を小さくすることができます。ただし、これらの処理は CPU リソースを多く消費する可能性があるので、データ投入などのリクエストが少ないタイミングで行うべきです。

POST /<index-name>/_forcemerge

対処2.4：refresh_intervalの調整

OpenSearch では、refresh_interval で指定した時間ごとに、メモリバッファに保持していたデータをセグメント化し検索対象に登録する処理を行っています。Approximate k-NN では、このタイミングでグラフの構築が行われます。
refresh_interval が小さいと、グラフ構築の頻度が上がり CPU リソースを消費する他、セグメント数が多くなることで検索クエリパフォーマンスが低下する可能性があります。データ投入から検索対象になるまでにかかる時間が長くなるデメリットがありますが、refresh_interval を大きくすることでパフォーマンス改善につながります。

PUT /<index-name>/_settings
{
  "index.refresh_interval": "30s"  # デフォルトは1s
}

対処2.5：GPUアクセラレーションの活用(対象：HNSW、バージョン3.1+)

ベクトルデータ数が非常に大きくなると、データ投入のタイミングで発生するグラフ構築に長い時間がかかり、CPU リソースの消費も大きくなります。ベクトルデータのインデクシングにおける GPU 加速を使用すると、大規模ベクトルデータに対するグラフ構築をマネージドな GPU を使用して高速化しつつ、CPU への負荷をオフロードすることが可能です。もし、検索クエリなどのパフォーマンス低下がベクトルデータのインデクシングによる CPU リソースの枯渇が原因であった場合、この機能の活用により改善する可能性があります。

$ aws opensearch update-domain-config \
    --domain-name <domain-name> \
    --aiml-options '{"ServerlessVectorAcceleration": {"Enabled": true}}'

GPU アクセラレーションを使用するかどうかは index.knn.remote_index_build.enabled からインデックスごとに設定可能です。

PUT <index-name> 
{ 
    "settings": { 
        "index.knn": true, 
        "index.knn.remote_index_build.enabled": true 
    }, 
    "mappings": { 
        "properties": { 
            "vector_field": { 
                "type": "knn_vector", 
                "dimension": 768
            }, 
            "text": { 
                "type": "text" 
            } 
        } 
    } 
}

ベクトルグラフ構築の高速化は最大 10 倍にのぼり、ユーザーは GPU リソースの使用を全く意識する必要はありません。有効化にはまず、OpenSearch ドメインの設定をアップデートします。この設定変更によるダウンタイムの発生はありません。
詳細についてはこちらのブログを参照ください。

対処2.6：クエリの工夫

検索パフォーマンスに問題がある場合、しばしばクエリ設計を工夫するアプローチが有効です。一般に OpenSearch におけるクエリ設計の最適化は様々な要素があり、クエリの種類によって取ることのできるアプローチも異なります。
ここでは、knn_vector フィールドへのクエリに対して取ることのできるアプローチを紹介します。

ef_search(対象：HNSW、バージョン2.16+)

HNSW を使用している場合、クエリに対して ef_search として小さい値を指定することで、精度を落として検索速度を向上することができます。ef_search はインデックスマッピング作成時に指定することができるパラメータですが、デフォルトは 100 となっており、クエリごとに調整することで、精度と検索速度のトレードオフを調整することが可能です。

GET /<index-name>/_search
{
  "size": 2,
  "query": {
    "knn": {
      "my_vector": {
        "vector": [2, 3, 5, 6],
        "k": 2,
        "method_parameters": {
          "ef_search": 90
        }
      }
    }
  }
}

HNSW ではこれ以外にもパラメーターが存在し、精度、レイテンシー、メモリ使用量のトレードオフを調整することができます。クエリのタイミングで指定できるパラメーターは ef_search のみであり、他のパラメーターはインデックス作成時に指定することができます。詳細に関してはこちらの資料を参考にしてください。

_sourceフィルタリングでベクトルデータ転送量を削減

ベクトル検索の多くの場合、ヒットしたドキュメントが持つベクトルデータはアプリケーションから直接利用されません。検索クエリで事前にベクトルデータを返さないように設定することでネットワーク転送や json シリアライゼーションのオーバーヘッドが削減され、結果的に検索レイテンシを低減する効果があります。

GET /<index-name>/_search
{
  "_source": {
    "excludes": ["vector_field"]
  },
  "query": {
    "knn": {
      "vector_field": {
        "vector": [...],
        "k": 5
      }
    }
  }
}

まとめ

本ブログでは、OpenSearch Service において FAISS エンジンを使用したベクトル検索ワークロードを運用している際に発生しうるトラブルとして検索クエリに対するレイテンシーの増加に着目し、その原因究明と対処方法選択の考え方について紹介しました。一般的に OpenSearch を利用した検索のクエリパフォーマンスを改善する場合は、様々な要素が複雑に絡み合う場合があり、特に複数の検索条件、フィルター、集計などを併用している場合にクエリパフォーマンスに影響が出る場合が多いです。一方で今回取り上げたようにベクトル検索単体においてもそのパフォーマンスの改善の余地があり、適切にモニタリングをした上で改善施策を取ることが重要です。
OpenSearch Service の機能は継続的に拡充されているため、新機能を活用するためにもクラスターのバージョンアップグレードを定期的に検討することを推奨します。

著者

黒木琢央 (Takuo Kuroki)

アマゾンウェブサービスジャパン合同会社ソリューションアーキテクト

C# を使用した Amazon DynamoDB でのネストされたトランザクションの有効化

shimada akari — Tue, 07 Apr 2026 05:17:31 +0000

本記事は 2026 年 03 月 31 日に公開された “Enabling nested transactions in Amazon DynamoDB using C#” を翻訳したものです。翻訳は Solutions Architect の嶋田朱里が担当しました。

Amazon DynamoDB は、あらゆる規模の高性能アプリケーション向けに設計された、フルマネージド型のサーバーレス NoSQL データベースサービスです。この記事では、C# を使用して DynamoDB で ACID (原子性、一貫性、分離性、永続性) 準拠のトランザクションを管理するフレームワークを紹介します。このフレームワークは、ネストされたトランザクションのサポートを特徴としています。この機能により、.NET アプリケーション内でデータの一貫性とエラー処理をより細かく制御しながら、洗練されたロジックを実装できます。このネストされたトランザクションフレームワークを使用すると、問題を分離し、部分的なロールバックを可能にし、DynamoDB の組み込みトランザクション機能の上に保守可能でモジュール化されたワークフローを構築できます。

トランザクションフレームワークのおさらい

ネストされたトランザクションに入る前に、このトランザクションフレームワークが何をするのかを簡単に振り返りましょう。Amazon DynamoDB トランザクションフレームワークは、DynamoDB の組み込みトランザクション機能を使った作業を効率化する C# ライブラリです。このフレームワークは以下を提供します。

トランザクションのライフサイクル (開始、コミット、ロールバック) を管理する TransactScope クラス
複数の DynamoDB テーブルにわたる ACID 準拠の操作の効率化
DynamoDB の TransactWriteItems および TransactGetItems API の低レベルの詳細 (複数のネストされたレベルにわたるトランザクションの調整やリクエストの構築など) を管理する抽象化レイヤー
フレームワークに組み込まれたエラー処理と再試行ロジック

このフレームワークは、複数の関連するデータアイテムを扱う場合でも、データの一貫性を維持する信頼性の高いアプリケーションの構築を支援します。在庫管理、金融取引、ユーザープロファイルの更新、または複数の DynamoDB 操作が単一のユニットとして成功または失敗する必要があるあらゆる状況で使用できます。

ネストされたトランザクションが重要な理由

ネストされたトランザクションにより、トランザクション操作を親トランザクションのスコープ内に存在させることができます。この機能は、エンタープライズグレードのシステムにおける柔軟性と堅牢性を向上させます。たとえば、システム内のモジュール化されたコンポーネントは、親トランザクション構造に影響を与えることなく独自のロジックをカプセル化でき、プロセスの一部で問題が発生した場合に部分的なロールバックを実行できます。エラーの影響範囲を発生元のトランザクション内に閉じ込めることで、ネストされたトランザクションはトランザクション全体の失敗のリスクを軽減し、フォールトトレランスを向上させ、システムのデバッグと保守をより容易にします。

サンプルアプリケーションの概要

ネストされたトランザクションを実際にどのように使用できるかを示すために、フレームワークの機能を紹介するサンプル Windows Forms アプリケーションを作成しました。このアプリケーションでは、複数レベルのネストされたトランザクションを通じてトランザクションの整合性を維持しながら、さまざまな製品タイプに対して一般的なデータ操作 (作成、削除、取得) を実行できます。

このサンプルアプリケーションは、ネストされたトランザクションが特に有効な、いくつかの一般的なシナリオを想定して作られています。

複雑なビジネスワークフロー : 複数の関連アイテム (e コマースの注文プロセスやコンテンツ管理の更新など) に変更を加える必要がある場合
エラーの分離 : プロセス全体をロールバックすることなく、特定の操作グループ内で障害を封じ込めたい場合
モジュール化されたシステム統合 : システムのさまざまなコンポーネントが独自のトランザクションコンテキストを維持する必要がある場合

次の画像の UI アプリケーションは、ネストされたトランザクションフレームワークを使用する DynamoDB Transaction Example というタイトルのフォームを提供します。これは、ネストされたトランザクションの仕組みを使って書籍、アルバム、映画を管理します。

主要な手順の流れは次のとおりです。

書籍、アルバム、映画用の DynamoDB テーブルを初期化するには、Create Product Tables (Book, Album, Movie) を選択します。これは通常、管理者として処理する 1 回限りのセットアップ手順です。
テーブルが配置されたら、Product Type ドロップダウンメニューから Album、Book、または Movie を選択します。この選択により、フォームフィールドが製品の属性に合わせてカスタマイズされます。たとえば、Album を選択すると Album Artist と Title の入力が求められ、Movie では Director と Genre が求められます。
対応する製品の詳細を入力します。これらの詳細は、選択した製品カテゴリによって異なります。たとえば、書籍には著者名、タイトル、およびオプションで出版日が必要であり、映画には監督名、タイトル、ジャンルが必要です。フォームでは、製品エントリの追加、削除、取得を含むトランザクション操作を実行するオプションが提供されます。

このアプリでは、ネストされたトランザクションを使用して、複数のトランザクションを開始し、それぞれのトランザクション内でアイテムの追加や削除を行い、個別にコミットまたはロールバックできます。また、ネストされたトランザクションフレームワークの動作を確認できるよう、親トランザクションと子トランザクションの間を行き来できるナビゲーション機能も備えています。これにより、どの操作をどのトランザクションにまとめるかを細かく制御できます。現在のトランザクションの階層は括弧内の数字で表示され (たとえば、Transaction (1))、Commit Transaction や Rollback Transaction などの操作は、現在の階層とその配下の子トランザクションに対して適用されます。

Album Artist や Title などのキーを提供することで、オプションで製品データを取得できます (Retrieve Item を選択)。すべての応答 (成功メッセージ、エラー通知、または取得されたデータ) は、Response Message フィールドと対応する製品属性ボックスに表示されます。

次の図は、DynamoDB でのネストされたトランザクションのシーケンスフローを示しています。親と子のトランザクションスコープがどのように相互作用して分離されたアトミック操作を提供するかを示しています。

フレームワークアーキテクチャ

このフレームワークは、TransactScope クラスを強化し、Composition や Chain of Responsibility などのデザインパターンを採用することで、ネストされたトランザクションをサポートします。

コミット操作は後入れ先出し (LIFO) の順序に従い、親の前に子の TransactScope を処理します。また、ロールバック操作も下位へと順次伝播するため、障害発生時には完全にクリーンアップされます。このシステムはスコープ間の双方向移動を可能にし、複雑なトランザクションフローの管理をより簡単にします。

アーキテクチャの適用性に関する注意: ここで提示されるフレームワークアーキテクチャ設計は、上記のサンプルアプリケーションでは C# で実装されていますが、他のすべてのオブジェクト指向プログラミング言語とプラットフォームに適用され、設計原則の幅広い適用性を保証します。

次の図は、カスタム TransactScope クラス構造を使用したネストされたトランザクションモデルを示しています。_transactRequest プロパティは TransactWriteItemsRequest を保持し、DynamoDB の複数の書き込み操作 (Put、Update、Delete) を単一のトランザクションにバッチ処理するために使用されます。_childTransactScope は TransactScope (具体的には子スコープ) を指し、この TransactScope 内にネストされたトランザクションが存在することを示します。逆に、_parentTransactScope は親の TransactScope を指し、トランザクション間の親子関係を確立します。

レイヤードアーキテクチャ

アプリケーションでネストされたトランザクションフレームワークを効果的に使用するには、そのレイヤードアーキテクチャを理解することが役立ちます。この設計は責務の分離を提供し、コードの保守性とテストのしやすさを向上させます。アーキテクチャは 4 つの主要なレイヤーで構成されています。

UI レイヤー : Windows Forms インターフェイスは、トランザクションの開始と管理のエントリポイントとして機能します。サービスレイヤーのメソッドを呼び出して、BeginTransaction()、CommitTransactionAsync()、RollbackTransaction() を実行し、トランザクションのライフサイクルを制御します。
サービスレイヤー : ProductService や TransactScope を含むこのレイヤーは、トランザクションのオーケストレーションを管理します。ネストされたスコープ間を作成およびナビゲートし、トランザクションロジックを一元化します。これは、トランザクション管理コードの大部分が存在する場所です。
データアクセスレイヤー : ここで、ProductProvider は、サービスレイヤーによって提供されるトランザクションコンテキスト内で、挿入や削除などのデータ操作を実行します。このレイヤーで、ドメインオブジェクトの特定のデータアクセスロジックを実装します。
DynamoDB : 最下層では、DynamoDB が組み込みトランザクション API (TransactWriteItems) を通じてアトミックな実行をサポートし、すべての操作が成功するか、いずれも成功しないことを保証します。

設計のハイライト

ワークフローは、使いやすさと堅牢性を向上させるコア機能を備えて設計されており、主に Begin/Commit/Rollback 構造を通じて実現されています。これにより、操作をアトミック (すべて成功するか、いずれも成功しない) にすることで、DynamoDB でのトランザクションの整合性と一貫性が保証されます。さらに、ネストされたトランザクションを使用する機能により、親スコープと子スコープを簡単に切り替えることで、より複雑でモジュール化されたワークフローが可能になります。

インターフェイスは、アクションを追跡するのに役立つ動的なフィードバックも提供します。トランザクションの深さインジケーター (括弧内に表示) は、操作がステージングされるにつれて更新され、ワークフローの現在の状態に関する明確な洞察を提供します。最後に、システムは統一されたインターフェイス内で複数の製品タイプ (書籍、アルバム、映画) をサポートします。これにより、同じトランザクションスコープ内で複数の DynamoDB テーブルにわたってアイテムを追加、削除、取得できます。サービスレイヤーでの一元化されたトランザクション管理により、責任が明確に分離され、DynamoDB が原子性を提供します。このレイヤードアプローチは、実世界のアプリケーションに必要な柔軟性を提供しながら、保守性を向上させます。

ネストされたトランザクションのベストプラクティス

アプリケーションでこの設計を最大限に活用するには、次の実用的なガイドラインに従ってください。

DynamoDB の制限に注意する – DynamoDB の制限 (100 アイテム、トランザクションあたり 4 MB) 内に収まるように、トランザクションを短く保ちます。それに応じてデータモデルを計画してください。
再試行ロジックを実装する : DynamoDB トランザクションは、条件チェック、競合、または容量の問題により失敗する可能性があります。指数バックオフを使用した効果的な再試行メカニズムをアプリケーションに組み込んでください。
パフォーマンスを監視する : Amazon CloudWatch アラームを設定して、トランザクション競合率、レイテンシー、例外などのトランザクションメトリクスを追跡し、ボトルネックを早期に特定します。
ネストの深さを制限する : ネストされたトランザクションは柔軟性を提供しますが、過度のネスト (3 〜 4 レベルを超える) は、デバッグと保守が困難な過度に複雑な実行パスを作成する可能性があります。

実世界のユースケース

フレームワークを理解したところで、独自のアプリケーションでネストされたトランザクションを適用できるいくつかの実用的なシナリオについて説明しましょう。

e コマースの注文処理 : 顧客が注文を行う場合、在庫レベルの更新、支払い情報の処理、注文レコードの作成が必要になる場合があります。ネストされたトランザクションを使用すると、支払い処理をサブトランザクションに分離でき、支払いが失敗した場合に独立してロールバックできます。
複数ステップのユーザー登録 : 初期ユーザープロファイルの作成、セキュリティ検証、アカウントの最終化など、複数の検証ステップを含む複雑な登録プロセスがアプリケーションに必要な場合、ネストされたトランザクションを使用して各段階の進行状況を追跡しながら、必要に応じて特定のステップをロールバックする機能を維持できます。
コンテンツ管理システム : 複数の関連エンティティ (記事、著者、カテゴリなど) への更新を必要とするコンテンツを公開する場合、ネストされたトランザクションは、特定のドメイン内で部分的な操作を可能にしながら一貫性を維持するのに役立ちます。
金融アプリケーション : 複数のアカウントや金融商品を含む操作の場合、ネストされたトランザクションは、アカウント管理コンテキスト、トランザクション処理コンテキスト、データ整合性コンテキストなどの特定の操作コンテキストを分離しながら、一貫性を提供するために必要なきめ細かい制御を提供します。

まとめ

この記事では、C# を使用した Amazon DynamoDB でのネストされたトランザクションフレームワークを紹介しました。これにより、トランザクションワークフローでの制御と堅牢性が向上します。TransactScope クラスを拡張することで、このソリューションは、コミットとロールバックの動作をより細かく制御しながら、複雑でモジュール化されたビジネス操作をモデル化する柔軟性を提供します。構造化された UI ワークフローと、UI レイヤー、サービスレイヤー、データアクセスレイヤーにまたがるレイヤードアーキテクチャは、すべての製品関連操作にわたってトランザクションの整合性、分離性、一貫性を提供します。

この実装の完全なソースコードは、GitHub リポジトリで入手できます。

著者について

Jeff Chen

Jeff は、AWS Professional Services のプリンシパルコンサルタントであり、生成 AI を活用したアプリケーションのモダナイゼーションと移行プロジェクトを通じて顧客を支援することを専門としています。生成 AI 以外にも、DevOps、データ分析、インフラストラクチャプロビジョニング、セキュリティなど、さまざまなドメインにわたってビジネス価値を提供し、組織が戦略的なクラウド目標を達成できるよう支援しています。

AWS Security Agent のオンデマンドペネトレーションテストの一般提供を開始

中島章博 — Tue, 07 Apr 2026 01:59:54 +0000

本ブログは 2026 年 3 月 31 日に公開された AWS Blog “AWS Security Agent on-demand penetration testing now generally available” を翻訳したものです。

本日 (2026 年 3 月 31 日)、AWS Security Agent のオンデマンドペネトレーションテストの一般提供を開始しました。最も重要なアプリケーションだけでなく、すべてのアプリケーションに対して包括的なセキュリティテストを実施できるようになります。この一般提供開始により、ペネトレーションテストは定期実施というボトルネックから脱却し、AWS、Azure、GCP をはじめとするクラウドプロバイダーやオンプレミス環境全体で開発速度に合わせてスケールするオンデマンドの機能へと進化します。マルチクラウドに対応しているため、AWS Security Agent を使用してインフラストラクチャ全体のペネトレーションテストを一元管理できます。

AWS Security Agent は、手動のペネトレーションテストの数分の一のコストで、24 時間 365 日稼働する自律型ペネトレーションテストを提供します。多くの組織では、時間とコストの制約から、手動のペネトレーションテストを最も重要なアプリケーションに限定して定期的に実施しています。このアプローチでは、テストの合間にアプリケーションポートフォリオの大部分が脆弱性にさらされたままになるリスクがあります。AWS Security Agent を使用すれば、最も重要なアプリケーションだけでなく、すべてのアプリケーションを対象にペネトレーションテストの速度、頻度、カバレッジを向上させることができます。AWS Security Agent のアプローチにより、ペネトレーションテストの所要期間を数週間から数日に短縮でき、開発速度を維持しながらリスクにさらされる期間を大幅に削減できます。

プレビュー期間中、HENNGE株式会社は次のように述べています。「AWS Security Agent は、手動テストでは発見できなかった貴重なインサイトを提供し、HENNGE の製品やサービスの堅牢性向上に貢献してくれました。コンテキスト認識型のエージェンティック AI アプローチは従来の方法とは異なるインサイトを提供し、セキュリティの検出結果にとどまらず、貴重なアプリケーション改善点を明らかにしてくれます。これにより、セキュリティライフサイクルを大幅に加速し、一般的なテスト期間を 90% 以上短縮できます」。

オンデマンドペネトレーションテストの仕組み

AWS Security Agent は、フロンティアエージェントと呼ばれる新しいクラスの自律型システムです。目標達成のために自律的に動作し、同時実行タスクに応じて大規模にスケールし、人間による常時監視なしで継続的に稼働します。高度なマルチステップ攻撃シナリオを通じてセキュリティ上の脆弱性の検出、検証、レポートを支援する専門的な AI エージェントをデプロイします。検証せずに検出結果を生成する従来のスキャナーとは異なり、AWS Security Agent はペネトレーションテスターとして動作します。潜在的な脆弱性の特定を支援し、その後ターゲットを絞ったペイロードと連鎖攻撃による悪用を試みることで、それらが実際のセキュリティリスクであることを検証します。

例えば、新しい決済処理機能をデプロイするケースを考えてみましょう。従来のペネトレーションテストでは、次のアセスメントのスケジュール (数週間から数か月先になることもあります) までリリースを遅らせるか、不確実性を残したままデプロイするかの選択を迫られます。AWS Security Agent を使用すれば、図 1 に示すように数分でペネトレーションテストを開始でき、数時間以内に検証済みの検出結果を受け取ることができます。これにより、重大な脆弱性が本番環境に持ち込まれる前に特定・修復でき、より確信を持ってデプロイできます。

図 1: 数分でペンテストを開始し、数時間以内に検証済みの検出結果を受け取る

この検証アプローチにより誤検知を最小限に抑えるとともに、エージェントの推論プロセスを可視化します。エージェントは、攻撃の計画方法、使用するペイロード、悪用のために構築するツール、悪用の成功を検証する方法を提示することで、透明性を確保します。図 2 に示すように、各検出結果には共通脆弱性評価システム (CVSS) のリスクスコア、アプリケーション固有の深刻度評価、詳細な再現手順が含まれています。これにより、チームはスキャナーのノイズを調査する代わりに、確認済みの脆弱性への対応に集中できます。

図 2: 各検出結果には CVSS リスクスコア、アプリケーション固有の深刻度評価、詳細な再現手順が含まれる

AWS Security Agent によるプロアクティブなコンテキスト認識型アプリケーションセキュリティの実現

AWS Security Agent は、静的アプリケーションセキュリティテスト (SAST)、動的アプリケーションセキュリティテスト (DAST)、ペネトレーションテストの機能を、単一のコンテキスト認識型エージェントに統合します。エージェントは、設計ドキュメント、アーキテクチャ図、Infrastructure as Code、ソースコード、ユーザーストーリー、脅威モデルを取り込むことで、アプリケーションの設計・構築・デプロイの方法を理解します。その上で、個々の脆弱性がどのようにつながり、より深刻度の高い連鎖攻撃を形成するかを特定します。こうした豊富なコンテキストにより、より品質の高い検出結果と、実行しやすい修復の推奨事項が得られます。

AWS Security Agent が検出する 3 つの検出結果の例

以下の検出結果の例は他のツールでも発見される可能性がありますが、それらのツールにはアプリケーションの設計・構築・使用方法や、各検出結果が連鎖攻撃の一部としてどのように悪用されるかについてのコンテキスト認識が欠けるため、個別に検出されたとしても適切に優先順位付けされない可能性があります。これらの検出結果はお客様が記述したカスタムコードに存在するため、必ずしも既知の CVE の脆弱性が存在するとは限らないため、ゼロデイ脆弱性の発見にあたります。

検出結果 1 – 格納型クロスサイトスクリプティング (XSS) (CVSS 6.1、中): 脅威アクターがコメントフィールドにスクリプトをインジェクトし、標準的な HTTPS トラフィックを介して管理者のセッション Cookie をキャプチャできる可能性があります。SAST や DAST では、バックログ内の数百もの他の検出結果に埋もれる中程度の深刻度の入力検証問題として報告される可能性があります。アプリケーションのコンテキストがなければ、これが重大な連鎖攻撃への入口であることを認識するのは困難です
検出結果 2 – 管理者アクセスを介したセッションハイジャック (スコアなし): 脅威アクターが、ハイジャックした管理者セッションを使用して制限付きエンドポイントにアクセスする可能性があります。このステップは、既存のどのツールカテゴリでも検出できません。SAST はランタイムセッションではなくコードを分析し、DAST は標準ユーザーとしてクロールします。エンドポイント検出と応答 (EDR) や拡張検出と応答 (XDR) では、他の正当なトラフィックに紛れた有効な HTTPS セッションとして認識されます。検出結果は生成されず、アラートも発生しません
検出結果 3 – 管理設定エンドポイントを介したデータベース認証情報の窃取 (CVSS 9.8、重大 – これまで未発見): 管理パネルは /admin/config エンドポイントを公開しており、このエンドポイントは本番データベースの接続文字列 (プレーンテキストの認証情報を含む) などの環境変数を返します。脅威アクターは、ハイジャックした管理者セッションでこのエンドポイントを呼び出して認証情報を抽出し、顧客の個人を特定できる情報 (PII) を含む本番データベースに直接接続して、顧客データセット全体を窃取する可能性があります。SAST はコードが設計どおりに機能しているためフラグを立てません。DAST は管理パネルに到達しません。EDR や XDR は正当な認証済み API コールとして認識します

AWS Security Agent が点と点をつなぐ

ソースコードとドキュメントを取り込むことで、AWS Security Agent は /admin/config エンドポイントがデータベース認証情報を公開していることを特定します。これは SAST、DAST、またはソフトウェア構成分析 (SCA) スキャナーでは特定が困難です。SAST や DAST は、検出結果 1 を重大な連鎖攻撃への入口として認識できず、中程度の深刻度の個別の問題として報告する可能性があります。検出結果 2 は検出できません。SAST はセッションではなくコードを分析し、DAST は標準ユーザーとしてクロールし、EDR や XDR は正当なトラフィックに紛れた有効な HTTPS トラフィックとして認識するためです。検出結果 3 も報告されません。SAST は設計どおりに機能するエンドポイントにフラグを立てず、DAST は管理パネルに到達せず、EDR や XDR は正当な API コールとして認識するためです。プロダクト要件ドキュメント (PRD) からは、このエンドポイントが正当なトラブルシューティング目的で設計されたものの、認証ゲートウェイによって不正アクセスが防止されるという前提があったという重要なコンテキストが得られました。AWS Security Agent は 3 つの検出結果をすべて連鎖攻撃としてつなぎ合わせ、各ステップをテストした上で、攻撃全体が成功することを実証します。

脆弱性の連鎖が重大なリスクを生む

優先度の低い CVSS 6.1 の XSS から始まり、SAST や DAST といった自動化ツールでは検出が困難なステップを経て、CVSS 9.8 の重大なデータベース認証情報の窃取へとつながります。検出結果 1 は数週間バックログに放置され、開発者やセキュリティチームのアラート疲れの一因となります。検出結果 2 はどのツールでも検出されません。検出結果 3 は設計どおりの動作であるためフラグが立ちません。開発者は重大および高の検出結果を優先的に修正しますが、数百もの他の検出結果に埋もれた CVSS 6.1 は放置され、お客様は脆弱性にさらされたままになります。AWS Security Agent はアプリケーションコンテキストを活用し、3 つの個別の検出結果で構成されるシーケンス全体を、重大かつ検証済みの脆弱性として格上げします。これにより、より深いインサイトと推奨される修復策が得られ、誤検知が減り、費用対効果の高いペネトレーションテストが実現します。セキュリティチームは、現在のテスト対象を超えた幅広いアプリケーションポートフォリオに対して、継続的なペネトレーションテストを自信を持ってスケールできるようになります。開発中に十分なテストが行われていないアプリケーションにも対応可能です。AWS Security Agent はこれらのインサイトと推奨される修復策を数週間ではなく数時間以内に提供し、お客様がより安全なアプリケーションを迅速にリリースできるよう支援します。

Scout24 SE は、これらの機能の価値を実際に確認
「AWS Security Agent は、エージェンティックテストとソースコードのコンテキストを組み合わせてコード認識型アプリケーションセキュリティテストを実現し、従来の DAST を上回りました。他のアプローチでは検出されなかった、公開環境で悪用可能な重大な問題を特定しました。透明性の高い推論により、調査された攻撃パスと達成されたカバレッジを信頼できるようになりました」 – Abdul Al-Kibbe 氏, Tech Lead, Security, Scout24 SE

Bamboo Health は、自社での利用を通じてコンテキスト認識型検出の深さが実証できることを確認
「AWS Security Agent は、アプリケーションとそのコードを真に理解し、そのコンテキストをテスト中の発見内容とつなげることで、他のどのツールでも発見できなかった検出結果を明らかにしました。レガシースキャナーでは、Security Agent が発見した内容にはまったく及びませんでした。人間のペンテストチームでさえ通常は見つけられないような問題を可視化してくれました。防御する側の味方になってくれる AI ツールだと感じたのは初めてです」 – Travis Allen 氏、Bamboo Health、Manager of Security Operations

最初のペネトレーションテストのセットアップ

ペネトレーションテストのセットアップは簡単で、以下のステップで構成されます。

論理的な境界としてエージェントスペースを作成する

まず、各アプリケーションまたはプロジェクトのエージェントスペースを作成します。エージェントスペースは、アプリケーションのドキュメントやコードリポジトリを接続できる論理的な境界として機能します。エージェントは、ドキュメントやコードから得たアプリケーションコンテキストを使用して、実装に固有のテストケースを作成します。例えば、Ecommerce Platform エージェントスペースを作成し、GitHub リポジトリ、API 仕様、アーキテクチャドキュメントを接続します。エージェントはこれらの資料を分析し、アプリケーションが決済処理やセッション管理、ユーザーストーリーをどのように処理するかを理解します。その上で、決済操作の脆弱性やセッションハイジャックのリスクなど、実装に固有のテストケースを作成します。

ドメイン所有権の検証を完了する

テスト開始前に、DNS TXT レコードを追加するか、ドメインに検証ファイルをアップロードして、ドメイン所有権の検証を完了します。この必須ステップにより、テスト対象アプリケーションのテストが許可されていることを確認し、お客様と AWS の双方を保護します。ペネトレーションテスト実行時に遅延が発生しないよう、初期設定時にすべてのドメインに対してこの 1 回限りのセットアップを完了してください。

アプリケーションコンテキストを追加して精度と検出の深度を向上させる

これは任意ですが、ソースコードとドキュメントを提供するとテストの精度が大幅に向上します。以下の情報を提供してください。

ソースコード: ホワイトボックステストを可能にし、実装固有の脆弱性を特定します。GitHub 統合でソースコードリポジトリを直接接続できます
API 仕様 (OpenAPI または Swagger): すべてのエンドポイント、パラメータ、認証要件を文書化し、エージェントが試行錯誤でエンドポイントを探索することなく包括的にテストできるようにします
アーキテクチャドキュメント: エージェントがサービス間のやり取りや潜在的な連鎖攻撃を理解するのに役立ちます
プロダクト要件ドキュメント: アプリケーションの目的、機能、ユーザーストーリーをエージェントが理解するのに役立ちます
既存の脅威モデル: エージェントが最もリスクの高い領域と既知の懸念事項に焦点を当てるよう誘導します

あらゆる環境でテストする

AWS Security Agent は、AWS、Azure、GCP、その他のクラウドプロバイダー、およびオンプレミス環境に対して動作します。URL を指定してパブリックエンドポイントを直接設定するか、VPC を通じてプライベートエンドポイントを接続し、インターネットに公開せずに内部アプリケーションを安全にテストできます。このマルチクラウドサポートにより、AWS Security Agent を使用してインフラストラクチャ全体のセキュリティテストを一元管理できます。

認証が必要なアプリケーションのテスト

ほとんどの脆弱性はアプリケーションにサインイン後の認証済み領域に存在します。包括的にテストするために、さまざまなユーザーロールに対応する複数の認証情報を設定します。

カスタマー向け機能用の標準ユーザー認証情報
管理機能用の特権ユーザー認証情報
API 間認証用のサービスアカウント認証情報
二要素認証 (2FA) を含む多要素認証 (MFA)

複数の認証情報セットを使用してテストすることで、AWS Security Agent は権限昇格の脆弱性を特定できます。例えば、標準ユーザーが API パラメータを操作することで管理機能にアクセスできてしまうケースを発見します。

複雑な認証フローに対応するサインインガイダンスの提供

AWS Security Agent は、大規模言語モデル (LLM) ベースのサインイン機能を使用して、OAuth、SAML、Okta、MFA などの認証フローを処理します。明確なサインインガイダンスを提供することで、認証の成功率が大幅に向上します。以下はガイダンスの例です。

app.example.com/auth/login に移動する
[Email or Username] フィールドに username を入力する
[Password] フィールドに password を入力する
[Sign In] を選択する

具体的な指示、段階的な手順、成功の検証基準を提供することで、エージェントが認証フローを確実に処理できるようになります。

検出結果から修復まで: セキュリティライフサイクルの全体像

AWS Security Agent で検出結果を確認し、修復に向けたアクションを実行します。

検証済みの実用的な検出結果

AWS Security Agent は、実際に悪用を試みることで潜在的な脆弱性を検証し、セキュリティリスクの存在を確認します。この検証アプローチにより誤検知が最小限に抑えられ、検出結果の手動検証にかかる時間を削減できるため、チームは修正が必要な実際の脆弱性に集中できます。エージェントは CVE Bench v2.0 で 92.5% の成功率を達成しており、実際の脆弱性を発見し検証する能力を実証しています。

各検出結果には、CVSS リスクスコア、アプリケーション固有の深刻度評価、詳細な再現手順、およびビジネスリスクを説明する影響分析が含まれます。例えば、E コマースアプリケーションでは、エージェントが価格操作の脆弱性を発見することがあります。攻撃者がチェックアウト時に商品価格を変更して無料で商品を入手できるという、売上に直接影響を及ぼす脆弱性です。

また、エージェントは脆弱性がどのように連鎖するかも特定し、深刻度の低い検出結果が重大な攻撃への入口となる可能性を示します。

レポートは PDF ファイルとしてエクスポートでき、経営層向けレポート、コンプライアンス文書、開発者への引き継ぎ、監査証跡に活用できます。

コード修正の提案を含む修復でプロセスを完結

従来のペネトレーションテストはレポートで終わり、その後、開発者が修正を調査、実装、デプロイするまでに数週間から数か月が経過します。AWS Security Agent はセキュリティライフサイクルを完結させます。

ペネトレーションテストを実行し、確認済みの脆弱性を特定する
検出結果をレビューし、重大な問題の優先順位を付ける
修復をトリガーし、コード修正を含むプルリクエストを生成する
開発者がレビューしてマージ – すぐに実装可能な修正を、数日ではなく数時間で適用
再テストし、脆弱性が解決されたことを確認する
自信を持ってデプロイ – セキュリティの問題が対処済みであることを確認

オンデマンドペネトレーションテストの開始

AWS Security Agent のオンデマンドペネトレーションテストは、以下の AWS リージョンで利用可能です。

米国東部 (バージニア北部)
米国西部 (オレゴン)
欧州 (アイルランド)
欧州 (フランクフルト)
アジアパシフィック (シドニー)
アジアパシフィック (東京)

料金

料金体系はシンプルで明確です。料金は 1 タスク時間あたり 50 USD で、秒単位の従量課金です。タスク時間とは、AWS Security Agent がアプリケーションのテストを実際に実行している時間を指します。現在の実績に基づくと、平均的なアプリケーションテストには約 24 タスク時間を要し、ペネトレーションテストから修復までの標準的なコストは約 1,200 USD です。料金とフリートライアルの詳細については、AWS Security Agent の料金ページをご覧ください。

請求例:

小規模ウェブアプリケーション (8 タスク時間): 400 USD
中規模 E コマースプラットフォーム (24 タスク時間): 1,200 USD
大規模エンタープライズアプリケーション (48 タスク時間): 2,400 USD

注: 上記の請求例と概算コストはあくまで目安であり、保証されるものではありません。実際のコストは、アプリケーションの複雑さ、エンドポイントの数、認証メカニズム、コードベースの規模、必要なテストの深度など、さまざまな要因によって異なります。ペネトレーションテストの所要時間とコストは、アプリケーションの特性に応じて変動します。

AWS Security Agent を活用すれば、より迅速かつ頻繁に、より多くのアプリケーションに対して低コストでペネトレーションテストを実行できます。従来の手動ペネトレーションテストと比較して最大 70～90% のコスト削減を実現したお客様もいます。

セキュリティテストを変革する準備はできていますか？

数分でエージェントスペースを作成し、初めてのペネトレーションテストを実行してみましょう。

AWS Security Agent の AWS マネジメントコンソールにアクセスする
アプリケーションのエージェントスペースを作成する
ドメイン所有権の検証を完了する
コードリポジトリを接続し、ドキュメントを追加する
最初のペネトレーションテストを設定して実行する

まとめ

AWS Security Agent のオンデマンドペネトレーションテストにより、最も重要なアプリケーションだけを定期的にテストするのではなく、すべてのアプリケーションを継続的にテストできるようになります。まずは 1 つのアプリケーションから始めて、検証済みの検出結果と自動修復を体験し、その後ポートフォリオ全体へ包括的なセキュリティテストを拡大してください。

今すぐテストを開始するには、AWS Security Agent にアクセスしてください。

AWA 株式会社、MongoDB on EC2 から Amazon DocumentDB への移行でデータベースコストを約 50% 削減（Part 1/2）

Masahiro Fujita — Tue, 07 Apr 2026 01:03:33 +0000

PART1：ドキュメント指向データベースの活用と Amazon DocumentDB の選択 -検討編-

AWA 株式会社は、1 億 8,000 万曲以上の楽曲を提供する音楽ストリーミングサービス「AWA」を運営しています。
独自のライブ配信機能「AWA ラウンジ」やフラワーチャット / フラワースタンプ（投げ銭）機能を備え、幅広いデバイスに対応しています。

2015 年のサービス開始当初から AWS 上でシステムを構築してきた同社は、2025 年にサービス基盤のデータベースを MongoDB on Amazon EC2 から Amazon DocumentDB（MongoDB 互換）へ移行しました。
本ブログシリーズでは、ドキュメント指向データベースの活用方法と Amazon DocumentDB への移行プロセス、そして移行後の効果について、全 2 回に分けてお客様の声を紹介いたします。

PART1（本記事）: ドキュメント指向データベースの活用と Amazon DocumentDB の選択
PART2: 23 億ドキュメントの移行プロセスとコスト約 50% 削減の効果

移行検討の背景と課題

AWA では、マイクロサービスの実行基盤に Amazon ECS on AWS Fargate、キャッシュに Amazon ElastiCache for Redis、検索基盤に Amazon OpenSearch Service を採用するなど、「マネージドサービスへの集約」と「技術スタックの統一」を方針として掲げ、段階的にマネージドサービスへの移行を進めてきました。
その中で最後に残っていた大物が、Amazon EC2 上で MongoDB Cloud Manager を使用してセルフホストしていたデータベースでした。

この環境には、いくつかの運用上の課題がありました。

コストの高騰: セルフホスト環境の運用コストに加え、Cloud Manager の仕様変更によりバックアップコストがさらに増大した。
スケールダウンの困難さ: ピーク時に合わせて拡張した 10 シャード構成を縮小できなかった。
バージョンアップの負荷: 複数環境のクラスターを個別にアップグレードする必要があり、その作業中に予期しないエラーでの中断が発生、サポートケースへの問い合わせが頻発した。
事業継続リスク: MongoDB クラスターの運用には専門的な知識が求められ、対応できるエンジニアが限られていた。担当者が不在の際の障害対応や、引き継ぎの難しさが事業継続上のリスクとなっていた。

当初は、MongoDB のシャード数を削減してスペックを調整し、コストを最適化する案も検討されていました。
しかし、シャードを減らすためのデータ退避が何ヶ月経っても完了せず、最終的に MongoDB 側の問題であることが判明しました。
この経験から、セルフホスト環境でのコスト最適化に限界を感じ、マネージドサービスへの移行に舵を切ることになりました。

2022 年にマネージド化の計画書が作成されましたが、本格的にプロジェクト化したのは 2025 年 4～5 月でした。
Cloud Manager のバックアップコスト高騰が最終的な決め手となり、約 4 年越しの移行プロジェクトが始動しました。

移行前のシステム構成

移行対象データベースの概要

項目	内容
DB エンジン	MongoDB 4.4.29（Cloud Manager 管理）
構成	10 シャード、各シャードがレプリカセット
インスタンス	r6a.2xlarge × 20 台（データノード）
ドキュメント数	約 23 億 ( TB 規模 )
主な格納データ	アーティスト情報、プレイリスト、ログイン情報、再生回数、AWA ラウンジ機能
アプリケーション言語	Go
クエリパターン	find、update、insert が中心（アグリゲーションパイプライン不使用）
Read/Write 比率	約 30:1 以上（コンテンツ配信の特性上、Read ヘビー）

AWA におけるドキュメント指向データベースの活用

AWA はサービス開始当初からドキュメント指向データベースを採用しており、そのデータモデルはサービスの特性と深く結びついています。
移行先の選定にあたっては、ドキュメント指向 DB であることが重要な要件でした。

スキーマレス設計：サービス無停止でのスキーマ変更

「スキーマレスのところが最高です。
AWA のポリシーとして、メンテナンスによるサービス停止をゼロに近づけたい。
ALTER TABLE のためにサービスを止めるようなことはできれば避けたいですからね。」

AWA では、新しいコレクション（RDB におけるテーブルに相当）の追加が 2～3 ヶ月に 1 回程度、既存コレクションのフィールド変更 ( RDB における列追加などに相当 ) が月 1～2 回程度の頻度で発生します。
ドキュメント指向データベースでは、これらの変更をサービスを停止することなく実施できます。
新しいフィールドを追加する際は後方互換を保つようにフォールバック処理をコードに組み込み、新しいフィールドがないドキュメントに対してもアプリケーション側で対応する運用を採用しています。

スキーマレスの柔軟性を活かしつつ統制を保つため、Go 言語の Struct 定義をスキーマの正として管理しています。
Go のフィールド定義がそのまま DB スキーマに反映される仕組みで、直接 DB を変更することはせず、必ず Go コードを通じてアクセスする運用です。
アプリケーションのクラス定義と DB のデータ構造が一致するため、RDB で必要になるようなオブジェクトとテーブル間のデータ変換が不要です。
開発者は DB の構造を意識せずにアプリケーションのコードに集中でき、変換処理に起因するバグも防げます。

RDB : アプリのオブジェクト → O/R マッピング → テーブル（変換が必要）
ドキュメント指向DB : Go Struct → そのまま JSON ドキュメント

配列・ネスト構造：JOIN 不要のシンプルなクエリ

AWA では、ドキュメント指向データベースの柔軟なデータモデリングを活用しています。以下に、2 つの活用例を紹介します。

配列の活用例：外部サービス連携の管理

ユーザーが連携を許可した外部サービスの ID を配列として保持し、「特定のサービスと連携しているユーザーを検索する」といったクエリを、外部キーや JOIN を使わずにシンプルに実現しています。

RDB では、ユーザーテーブルと連携サービステーブルを外部キーで関連付け、JOIN で結合する必要がある処理を、1 回のクエリで完結できます。

ネスト構造の活用例：認証情報の管理

ユーザードキュメント内に外部認証サービスのログイン情報をネストしたオブジェクトとして格納し、auth_provider.id のようなドット記法のクエリで、特定の外部認証サービスの ID でログインしているユーザーを直接検索できます。
RDB であれば外部キーと JOIN が必要になる処理を、1 回のクエリで完結できます。

非正規化設計：Read ヘビーなサービスに最適化

AWA のサービスはコンテンツ配信という特性上、Read に大きく寄っています。
この特性を活かし、あえて正規化せず 1 ドキュメントに関連する ID を配列で保持する設計を採用しています。
1 つのドキュメントを取得すれば関連するエンティティの ID が全て分かり、それらの実体を主キーで取得するという 2 段階のクエリで、必要なデータを効率的に取得できます。

クエリの運用性を高めるため、複雑なクエリやアグリゲーションパイプラインは使用しない方針を取っています。
MongoDB のバージョンアップで仕様が変わることがあったため、アグリゲーションが必要にならないようデータ構造自体を設計し、集計が必要な値は書き込み時にカウントアップする方式を採用しています。
これにより、読み込み時に集計処理を実行する必要がなくなり、Read の負荷軽減にもつながっています。

インデックス戦略：Read 最適化の設計

AWA では、アプリケーションから発行される全ての Read クエリに対して専用のインデックスを設定しています。
論理削除フラグには専用のインデックスを設け、日付範囲検索にもクエリごとのインデックスを用意するなど、Read 性能を最優先としたインデックス戦略です。
多数のコレクション・インデックスを運用していますが、クエリごとに専用インデックスを設計しているため、意図しない実行計画が選択されることはほとんどありません。
MongoDB ではクエリがパイプライン形式で実行されるため、RDB のように複数テーブルの JOIN で実行計画が複雑化しにくいという特性も寄与していると考えられます。

Amazon DocumentDB を選択した理由

AWA がこれらのドキュメント指向 DB の設計を維持しつつ、移行先として Amazon DocumentDB を選択した理由は大きく 3 つあります。

1. MongoDB 互換による低リスクな移行

「MongoDB にこだわりはなく、ドキュメント指向 DB であることが大事。
MongoDB との高い互換性がある Amazon DocumentDB が最も移行しやすかった。」

Amazon DocumentDB は MongoDB との互換性を備えており、AWA で使用していた find、update、insert といった基本的なクエリはそのまま動作しました。

2. 本番実績に基づく性能への信頼

AWA では移行前から別のワークロードで Amazon DocumentDB を利用しており、1 クラスター・1 ノードの xlarge～2xlarge 程度のインスタンスで高い書き込み性能を確認していました。
MongoDB で 10 シャードに分散していた処理を、Amazon DocumentDB の 1 クラスターで処理できるという仮説が、既に本番環境で裏付けられていました。

3. AWS への集約によるコストと運用の最適化

「AWS に集中していたほうがやりやすい。
セキュリティ的にも Amazon VPC 内で完結させたかった。」

MongoDB Atlas も検討しましたが、AWS 上で全てを管理したいという方針から Amazon DocumentDB を選択しました。
Amazon VPC 内で通信を完結させることでセキュリティ要件を満たしつつ、ネットワーク構成を簡素化できる点も決め手の一つでした。

また、Amazon DocumentDB はコンピューティングとストレージが分離されたアーキテクチャを採用しており、Read ヘビーな AWA のワークロードに対して Reader インスタンスを柔軟にスケーリングできます。
マネージドサービスとしての自動バックアップや PITR も、運用負荷の軽減に寄与すると判断しました。

なお、Amazon DocumentDB Serverless も検討しましたが、11 月の Amazon EC2 Savings Plans 満了に合わせた移行スケジュールの中で検証時間を確保できなかったため、まずはインスタンスベースで移行し、今後の検証課題としています。

次回予告

PART1 で紹介したスキーマレス設計、配列・ネスト構造、非正規化設計、インデックス戦略といったドキュメント指向 DB の設計は、Amazon DocumentDB でどのように機能したのか。
PART2 では、23 億ドキュメントのニアゼロダウンタイム移行の具体的なプロセスと直面した課題、そしてコスト約 50% 削減を含む移行後の効果についてご紹介します。

[Part 2 に続く]

信田悟至氏

山下剛史氏

小林健太郎氏

AWA 株式会社

信田悟至氏
山下剛史氏

株式会社サイバーエージェントメディア統括本部 SRE

小林健太郎氏

本ブログは、データベーススペシャリストソリューションアーキテクトの藤田将大とシニアソリューションアーキテクトの半場光晴が執筆しました。

AWA 株式会社、MongoDB on EC2 から Amazon DocumentDB への移行でデータベースコストを約 50% 削減（Part 2/2）

Masahiro Fujita — Tue, 07 Apr 2026 01:03:19 +0000

PART2：23 億ドキュメントの移行プロセスとコスト約 50% 削減の効果 -移行・効果編-

PART1 では、AWA がドキュメント指向データベースの特性をどのように活用しているか、そして Amazon DocumentDB の採用に至った経緯を解説しました。
PART2 では、23 億ドキュメントの大規模環境をニアゼロダウンタイムで Amazon DocumentDB へ移行した具体的なプロセスと、直面した課題、そして移行後の効果についてご紹介します。

移行前後のシステム構成

移行先の構成

移行前の環境は MongoDB 4.4.29、10 シャード・レプリカセット構成、r6a.2xlarge × 20 台（データノード）、23 億ドキュメントという大規模な環境でした（詳細は PART1 の移行対象データベースの概要を参照）。

移行先の Amazon DocumentDB の構成は以下の通りです。

項目	内容
インスタンス	db.r6g.8xlarge（移行後に db.r8g.8xlarge に変更）
ストレージ	I/O-Optimized
構成	1 クラスター（Writer + Reader）

I/O-Optimized ストレージを選択した理由は、コスト予測のしやすさです。
db.r8g への変更は、コスト最適化および Database Savings Plans への対応を目的としています。

移行スケジュール

本プロジェクトは、AWA の少人数の開発チームが自社で実施しました。
本格的なプロジェクトは 2025 年 4 月に始動し、以下のスケジュールで進められました。

時期	フェーズ	内容
2025 年 4～5 月	計画策定	移行対象の洗い出し、移行方式の決定
2025 年 6～7 月	準備	負荷試験環境の構築、データ連携ツール DB Sync の全コレクション対応
2025 年 8 月	負荷試験	通常営業負荷と AWA ラウンジ高負荷の 2 種類を約 1 ヶ月実施
2025 年 10 月～	並行運用・切り替え	マイクロサービスごとに段階的に切り替え
2025 年 12 月中旬	完了	全マイクロサービスの切り替え完了

11 月に Amazon EC2 の Savings Plans が満了するタイミングに合わせてスケジュールを組みましたが、バッチ処理の切り替えに想定以上の時間がかかり、最終的に 12 月中旬の完了となりました。

データ移行の流れ

データ移行は、自社開発のデータ連携ツール DB Sync を中心に、3 つのフェーズで実施しました。

AWS Database Migration Service (AWS DMS) の利用も検討しましたが、DB Sync で既にデータ連携運用の実績があり、それを流用するほうが安定した移行につながると判断しました。
DB Sync は MongoDB の Change Streams を利用したサブスクリプション形式のデータ同期ツールで、以前から一部コレクションの同期に利用していた実績がありました。

フェーズ 1：初期データロード

mongodump/mongorestore を使用して、MongoDB 上の 23 億ドキュメントのデータを Amazon DocumentDB へ一括投入しました。

フェーズ 2：継続的データ同期

初期ロード完了後、DB Sync で MongoDB と Amazon DocumentDB 間のリアルタイム同期を開始しました。
DB Sync は MongoDB の Change Streams をサブスクライブし、変更イベントを Amazon DocumentDB へ書き込む仕組みです。
今回の移行では、以前の限定的なコレクション同期から全コレクション対応に拡張しました。

フェーズ 3：マイクロサービスごとの段階的切り替え

約 10 のマイクロサービスを、依存関係の少ないものから順に Amazon DocumentDB へ切り替えました。
切り替えは各サービスの DB 接続先を DNS レベルで変更する方式で、サービス停止はほぼ発生していません。

移行途中では、マイクロサービスによって参照先の DB が新旧で異なる状態が発生します。
そのため、サービス間の依存関係を考慮し、他のマイクロサービスへの影響が少ないものから順に切り替えを進めました。
切り戻しも考慮しており、実際に本番で一度切り戻しを実施しています（詳細は後述）。

移行時の課題と対応

Writer への負荷集中と切り戻し

本番環境で大規模な AWA ラウンジ（AWA 独自のライブ配信機能）イベントを実施した際、以前は 10 シャードに分散していた書き込みが 1 クラスターの Writer に集中し、サービスに影響が出ました。
再生ごとにカウントされるクエリがユーザー数分発生し、Writer がボトルネックとなりました。

事前に切り戻しの手順と判断基準を準備していたため、問題発生時に即座に旧環境への復旧を決断できました。切り戻しまでの間に発生した一部の書き込みデータは失われましたが、サービス全体への影響を最小限に抑えることを優先したビジネス判断でした。
その後、以下の対応を実施しました。

負荷試験の追加実施: AWA ラウンジ高負荷を模した追加の負荷試験を実施しました。
書き込み頻度の調整: インクリメント処理など、高頻度の Write クエリをアプリケーション側で最適化しました。
Reader/Writer の分離: MongoDB 時代は全てのクエリを Writer（Primary）に送信していた設計を見直し、Amazon DocumentDB の Reader エンドポイントと Writer エンドポイントへの接続を明確に分離。それぞれ専用のドライバー設定を用意しました。

Amazon DocumentDB はコンピューティングとストレージが分離されたアーキテクチャを採用しており、Writer インスタンスとは独立して Reader インスタンスを柔軟に追加できます。
Read ヘビーな AWA のワークロードでは、この Reader/Writer 分離が特に重要でした。

「Reader と Writer を意識してアプリケーションを組むようになりました。
やらないと Writer に負荷が集中してしまい、Reader のスケールメリットを活かせません。
Amazon DocumentDB のベストプラクティスを学んで、頭を切り替えていきました。」

データ同期の課題

DB Sync を全コレクション対応に拡張した際、2 つの問題が発生しました。

1. 同期サーバーの過負荷

以前は限定的なコレクションのみ同期していたため、全コレクション対応で同期サーバーが過負荷になりました。

2. ObjectID 型のハンドリング

主キーの大半は String 型でしたが、一部コレクションで ObjectID 型が使われており、正しく同期されないケースが発生しました。
この問題は移行後に発覚し、迅速に対応を行いました。

データ同期ツールを使用する場合、データ同期ツール自体に精通しておくことだけでなく、全コレクションのスキーマとデータ型を事前に網羅的に把握しておくことが重要です。

TLS 通信と認証への対応

移行で最も工数がかかったのは、Amazon DocumentDB の TLS 通信と ID/パスワード認証への対応でした。
Amazon DocumentDB では TLS がデフォルトで有効化されており、以前の MongoDB 環境ではネットワーク隔離のみで認証を設定していなかったため、接続設定の変更が必要になりました。

「一番大変だったのは、ID/パスワード認証の対応でした。
以前の MongoDB では設定していなかったのですが、Amazon DocumentDB では必要となるため、これを機に認証と通信の暗号化を導入しました。」

結果的にセキュリティの向上につながりましたが、移行を検討される際は事前に認証設定の影響範囲を確認しておくことをお勧めします。

MongoDB 互換性

AWA では複雑なアグリゲーションパイプラインを使用しない方針を取っていたため、クエリの互換性問題はほとんど発生しませんでした。
find、update、insert を中心としたシンプルなクエリパターンにより、Web アプリケーションのクエリに関してはAmazon DocumentDB Compatibility Toolでの事前確認でも問題は検出されませんでした。
一部、古いバッチ処理と Go 言語のドライバーで対応が必要な箇所がありましたが、影響は限定的でした。

PART1 で紹介したスキーマレス設計、配列・ネスト構造を活用したデータモデル、Read 最適化のインデックス戦略、Go Struct によるスキーマ管理といったドキュメント指向 DB の設計は、Amazon DocumentDB 上でも問題なく動作しています。

Amazon DocumentDB への移行の効果

移行前後の比較

項目	移行前（MongoDB on Amazon EC2）	移行後（Amazon DocumentDB）
構成	10 シャード、レプリカセット	1 クラスター（Writer + Reader）
インスタンス	r6a.2xlarge × 20 台	db.r8g.8xlarge（Writer + Reader）
月額コスト	–	約 50% 削減
バージョンアップ	10 クラスター個別対応	マネージドサービスで一括管理
バックアップ	Cloud Manager 20 世代管理	自動バックアップ + PITR
スケール変更	シャード削減が困難（数ヶ月かかることも）	Reader の追加・削除が容易
認証・暗号化	未設定（ネットワーク隔離のみ）	TLS 通信 + ID/パスワード認証
ネットワーク	MongoDB 専用サブネットで複雑な隔離構成	Amazon VPC 内でシンプルな構成

※ 移行前コストには Amazon EC2、Cloud Manager、バックアップ、通信費を含みます。

コスト削減

データベース関連コストは約 50% 削減されました。
コスト試算は、ベストプラクティスドキュメントを参考に既存クラスターの CPU・メモリ使用率から必要スペックを机上計算し、負荷試験で実証した上で本番稼働させています。
さらに、Database Savings Plans の適用により追加で約 20% の削減を見込んでいます。

性能

20 台の Amazon EC2 インスタンス（10 シャード構成）から 1 クラスターへの集約にもかかわらず、レスポンスタイムに大きな変化はありませんでした。
コンテンツ配信という特性上 Read ヘビーなワークロードであり、Amazon DocumentDB の Reader インスタンスを活用して Read 処理を分散させることで、台数を大幅に削減しつつ性能を維持できています。
MongoDB のシャーディング構成ではスケールダウンに数ヶ月を要することもありましたが、Amazon DocumentDB では Reader の追加・削除が容易です。

運用

マネージドサービスの活用により、特定のエンジニアに集中していたバージョンアップやノード障害対応の負荷が軽減され、スロークエリの改善などアプリケーション本来の改善に注力できるようになっています。
モニタリングについては、Datadog と連携した Amazon DocumentDB 用監視ダッシュボードを構築し、フェイルオーバー検知には AWS Chatbot を使用して Slack に通知する体制を整えています。
今後は、Amazon DocumentDB のクローン機能を活用し、本番データを用いた負荷試験環境の迅速な構築にも役立てていく予定です。

補足：Amazon DocumentDB のクローン機能とは
本番クラスターのデータを短時間かつ追加ストレージコストを抑えてコピーできる機能です。コピー元とコピー先でストレージを共有する Copy-on-Write 方式のため、クローン作成時点ではデータの物理コピーが発生せず、大規模なクラスターでも高速にクローンを作成できます。

セキュリティ

移行前は MongoDB 用に専用サブネットを作成し、複雑なネットワーク構成で隔離していました。
Amazon DocumentDB への移行により、TLS 通信と ID/パスワード認証が導入され、ネットワーク構成も簡素化されました。
10 年以上前に構築された初期のネットワーク構成を、移行のタイミングで整理できたことも副次的な効果です。

移行を検討されている方へ

本プロジェクトを通じた気づきとして、以下の点に留意されることをおすすめします。

「反省として、流れてくる Write クエリの頻度とタイミングを事前に詳細に把握しておくべきでした。」

Write クエリの頻度とパターンを事前に詳細に把握する: シャーディング構成から 1 クラスターへの集約では、Writer への負荷集中が最大のリスク。特にイベント時など負荷が変動するワークロードでは、ピーク時の Write パターンを把握した上で負荷試験を実施することが重要です。
Reader/Writer の分離設計を事前に計画する: Amazon DocumentDB のアーキテクチャを活かすため、アプリケーション側で Reader と Writer を意識した設計に変更することをお勧めします。
TLS 通信と認証の影響範囲を事前に確認する: Amazon DocumentDB では TLS と認証がデフォルトで有効化されているため、MongoDB で未設定の場合は接続設定の変更が必要です。
データ同期ツールを使用する場合、全コレクションのスキーマを網羅的に把握する: 特にデータ型の違い（String vs ObjectID など）に注意が必要です。

「相当凝ったクエリでもなければ MongoDB のまま移行できると思います。今回は ID/パスワード認証の対応が最も大変でした。」

今後に向けて

「今回の移行はラスボスぐらいの強敵でしたが、やっと倒せました。
マネージドで、気持ちの面でも運用の面でも楽になりました。
副次的に、ドライバーのアップグレードや通信の暗号化など、気になっていた部分を改善するきっかけにもなりました。
今後は Database Savings Plans の適用や Amazon DocumentDB Serverless の検証を進め、さらなるコスト最適化を目指していきます。
マネージドに極力寄せていける構成にしていきたいです。」

「これまでバージョンアップやノード障害の対応に追われていましたが、今後はスロークエリの改善など、本来注力すべき領域に集中できるようになりました。
Amazon DocumentDB では Reader の増減やスペックの上げ下げも柔軟にできると期待しています。」

まとめ

AWA 株式会社は、MongoDB on Amazon EC2 から Amazon DocumentDB への移行により、以下の成果を達成しました。

データベースコスト約 50% 削減（さらに Database Savings Plans で約 20% の追加削減を見込み）
23 億ドキュメントのニアゼロダウンタイム移行
20 台の Amazon EC2 インスタンスから 1 クラスターへの集約（性能を維持）
運用負荷の大幅軽減と属人化の解消
セキュリティの向上（TLS 通信、認証、ネットワーク構成の簡素化）

2022 年の構想から約 4 年。
マネージドサービスへの集約という一貫した方針のもと、大規模移行を完遂した AWA の事例は、MongoDB 環境から Amazon DocumentDB への移行を検討している企業にとって、具体的な道筋を示すものです。

Amazon DocumentDB の詳細については、以下のリソースをご参照ください。

Amazon DocumentDB のベストプラクティス

Amazon DocumentDB のベストプラクティス

MongoDB からの移行に使えるドキュメント

Amazon DocumentDB の便利なツール群

以下のツールは Amazon DocumentDB Tools リポジトリで公開されています。

compat-tool — MongoDB との互換性チェック
index-tool — インデックスの分析・最適化
migration — 移行支援ツール
sizing-tool — サイジング見積もり
monitoring — モニタリング
performance — パフォーマンス分析
operations — 運用支援

信田悟至氏

山下剛史氏

小林健太郎氏

AWA 株式会社

信田悟至氏
山下剛史氏

株式会社サイバーエージェントメディア統括本部 SRE

小林健太郎氏

ヘルスケア業界のエンジニア 46 名がセキュリティインシデント疑似体験に挑戦 – AWS GameDay 開催レポート

Yohei Katayama — Mon, 06 Apr 2026 23:57:01 +0000

みなさん、こんにちは。ソリューションアーキテクトの片山です。

近年、医療機関におけるセキュリティ対策の重要性が高まっています。厚生労働省の「医療情報システムの安全管理に関するガイドライン」の改定にも見られるように、電子カルテシステムをはじめとする医療情報システムの安全な運用に向けて、組織的なセキュリティ対策の強化がこれまで以上に求められています。

こうした背景を踏まえ、2026 年 3 月 31 日にヘルスケア業界のお客様を AWS にお招きして「ヘルステック企業向けセキュリティインシデント疑似体験 GameDay」を開催しました。今回はそのイベントのご紹介や当日の雰囲気をお伝えし、セキュリティへの取り組みを知っていただければ幸いです。

AWS GameDay とは

AWS GameDay は、AWS ソリューションを利用してチーム単位で現実世界の技術課題を実際に体験し取り組む、AWS が提供するユニークなトレーニングプログラムです。実践的なクラウドスキルを楽しみながら習得でき、特に今回のセキュリティインシデント疑似体験 GameDay はクラウドセキュリティに特化したプログラムとして評価いただいています。

このプログラムの特徴は、実際の AWS 環境で発生しうるセキュリティインシデントをシミュレーションし、参加者がチームとなって対応するという点です。例えば、不正アクセスの検知、データ漏洩インシデントの調査、マルウェア感染への対処など、現実世界で直面する可能性のある様々なセキュリティ課題に取り組みます。

参加者は、Amazon GuardDuty、AWS CloudTrail といった実際の AWS セキュリティサービスのログを SIEM on Amazon OpenSearch Service というソリューションから確認し、インシデントの検知から対応までを体験します。このワークショップ形式の学習により、座学だけでは得られない実践的なスキルと経験を積むことができます。

イベントの様子

2026 年 3 月 31 日、目黒にて「ヘルステック企業向けセキュリティインシデント疑似体験 GameDay」を開催しました。ヘルスケア業界から 18 社、46 名のエンジニアの皆さまにお集まりいただきました。

参加者の皆さまは 3 名ごとのチームに分かれ、AWS 環境でセキュリティイベントが検知されたものの原因が特定できないというシナリオのもと、実際の SIEM 環境を操作して制限時間 2 時間の中でインシデントの調査に取り組みました。

会場では各チームが真剣にログを分析しながらも、ゲーミフィケーションの要素によりリアルタイムでスコアが可視化されるため、チーム間で競い合いながら楽しく学ぶ姿が印象的でした。多くの参加者は既に AWS 上でシステム開発・運用をされており、セキュリティへの意識も高く、非常に活気のあるイベントとなりました。

ワークショップ終了後は表彰式と解説セッションを行い、今回のシナリオで実際に何が起きていたのかを AWS から解説させていただきました。インシデントの検出にはまずは Amazon GuardDuty が効果的であり、根本原因と被害範囲の調査のためにはしっかりと必要なログを保管し、いつでも取得できるような状態にしておくことが肝要です。その後は懇親会にてヘルスケア業界に関わる技術者同士や AWS メンバーとの交流を深めていただきました。

参加者からのフィードバック

イベント後のアンケートでは高い満足度の評価をいただき、参加者の 100% が「イベントを通じて学びがあった」と回答いただきました。

特に好評だったのはシナリオのリアルさです。「事象のシナリオとログ内容がかなり現実に近く、具体感をもって取り組めました」「ログ分析の奥深さを感じました」といった声が多く寄せられました。解説セッションについても「ログからセキュリティ侵害の攻撃シナリオを解説していただけたのが大変学びになりました」と、座学では得られない深い理解につながったという感想をいただいています。

「障害が発生した時にまずやるべきことが分かり、今後の運用に活かしていきたい」「普段から GuardDuty を利用していますが、何を見ればいいのか、ログの見方について理解できるようになりました」など、日々の業務に直結する学びを得られたという声も印象的でした。

まとめ

セキュリティインシデントへの対応は、実際に発生してから学ぶのでは遅すぎます。AWS GameDay は、安全な環境で事前に経験を積み、実際のインシデント発生時に適切に対応できる体制を整えるための貴重な機会です。

今回の GameDay で得た学びを次のアクションにつなげるために、AWS では AWS セキュリティ成熟度モデルをご用意しています。このモデルは、組織のセキュリティ対策の現在地を把握し、次に取り組むべき施策を明確にするためのフレームワークです。このブログを読んでいただいている皆さまも、インシデント検知や調査のプラクティスが、自組織ではどの段階にあるのかを確認してみてはいかがでしょうか。セルフチェック用の評価シートもございます。詳細は https://maturitymodel.security.aws.dev/ja/assessment-tools/ をご覧ください。

AWS ではこれからもヘルスケア業界の皆さまに貢献できるよう、クラウド技術のご紹介や各種イベントを実施いたします。積極的に活用いただけますと幸いです。

著者

Yohei Katayama (AWS Japan, Public Sector, Healthcare Solutions Architect)
Akihiro Nakajima (AWS Japan, Public Sector, Security Solutions Architect)

Kiro に MiniMax M2.5 と GLM-5 が追加されました

Hiroaki Yoshimura — Mon, 06 Apr 2026 08:58:22 +0000

本記事は 2026 年 4 月 2 日に公開された Nima Kaviani による “MiniMax M2.5 and GLM-5 are now in Kiro” を翻訳したものです。

Kiro のオープンウェイトモデルへのネイティブサポートを拡充してきました。最近では MiniMax M2.5 に続き、GLM-5 も Kiro IDE および CLI から直接利用できるようになりました。Kiro はすでにコスト・コンテキスト長・速度のバランスが異なる多様なモデルをサポートしています。今回の 2 つの追加により、その幅がさらに広がり、開発者やチームが目の前の作業に応じてモデルを選択できる余地が増えました。

モデルの詳細

各モデルが持つ特徴と、得意とする用途について詳しく見ていきましょう。

MiniMax M2.5（クレジット乗数 0.25x）— クエリごとに 100 億パラメーターを活性化するスパース MoE (Mixture of Experts) モデルです。わずか 4 分の 1 のクレジットコストで、SWE-Bench Verified において 80.2% のスコアを記録しており、Claude Sonnet を超えた初のオープンウェイトモデルとして、Claude Opus 4.6（80.8%）に次ぐ位置につけています。Kiro の中でも最もコスト効率の高いモデルの一つです。MiniMax M2.1 と比較して複雑なエージェントタスクを 37% 高速に完了します。コードを書く前に機能を分解して構造をマッピングするため、マルチステップの実装作業や長時間のエージェントセッションに優れています。また、10 以上の言語（Go、C、C++、TypeScript、Rust、Kotlin、Python、Java、JavaScript など）にわたる強力な多言語サポートを提供し、Web、Android、iOS、Windows にまたがるフルスタックプロジェクトにも対応しています。継続的なコーディングセッションや反復的な実装作業に対して、高速かつコスト効率の高いモデルをお求めであれば、MiniMax M2.5 は有力な選択肢です。

GLM-5（クレジット乗数 0.5x）— 200K コンテキストウィンドウを備えた大規模 MoE モデルです。GLM-5 は長期的なエージェントワークフローに最適化されています。リポジトリ規模のコンテキストを処理し、大規模なコードベースにわたるマルチステップのツール使用において一貫性を維持することに優れています。クロスファイルのマイグレーション、フルスタックの機能開発、あるいはモデルが全体像を把握する必要があるレガシーリファクタリングなどのユースケースが該当します。深いコンテキストが求められる複雑なアーキテクチャ変更に取り組んでいる場合は、GLM-5 を試してみる価値があります。

IDE と CLI で試してみましょう

これらのモデルは現在、IDE のモデルセレクターおよび Kiro CLI から実験的サポートとして利用できます。MiniMax M2.5 は AWS US-East-1（バージニア北部）および AWS EU-Central-1（フランクフルト）リージョンで利用可能です。GLM-5 の推論は AWS US-East-1（バージニア北部）リージョンで実行されます。

また、Kiro にすでに搭載されているオープンウェイトモデルへのアクセスも拡大しました。MiniMax M2.1、Qwen3 Coder Next、Deepseek V3.2 は、IAM Identity Center（IdC）経由で認証しているユーザーを含む全ユーザーが利用できるようになりました。推論をワークロードに近づけるため、MiniMax M2.1 と Qwen3 Coder Next は AWS US-East-1（バージニア北部）に加えて AWS EU-Central-1（フランクフルト）リージョンでも利用可能です。

設定不要、ルーティング不要、追加セットアップ不要でモデルを選んですぐに作業を始められます。モデルを切り替えたり、特定のプロジェクトタイプにデフォルトを設定したり、Auto に任せたりと、ワークフローに合わせてご利用ください。エンタープライズチームの場合、管理者はモデルガバナンスを使用して、利用可能なモデルをコンプライアンスおよびデータレジデンシーの要件に合わせることができます。いつものように、ぜひ試してみて、使い心地をお聞かせください。どのモデルが好評で、どのような課題が残っているかを注視しています。次にサポートしてほしいモデルがあれば、ぜひご要望をお寄せください。

翻訳は Solutions Architect の吉村が担当いたしました。

Amazon Web Services ブログ

大豊建設が AWS で実現した大豊 AI：業務の様々な場面で活躍する生成 AI 活用事例

はじめに

建設企業が直面する業務効率化の課題

「大豊 AI」を自作する挑戦

実際にどのように活用しているのか

利用頻度の高い機能トップ 5

① フリートーク：気軽な質問から専門知識まで

メール作成：正確で丁寧な文面を手軽に

若手社員の学習支援

② 規程検索：必要な情報に素早くアクセス

③ ファイルチャット：文書分析の効率化

議事録の自動生成

④ 社内資料の全文検索：過去の知見と法令情報への横断アクセス

⑤ ユースケース別検索：AI 初心者にも使いやすいテンプレート機能

自社業務に最適化できる生成 AI 基盤の選択

システム構成と技術的な工夫

エージェント技術による次なる業務変革への挑戦

エージェント機能の実装

施工計画書の作成支援

社内資料の作成支援

まとめ

Kiro スタートアップクレジットプログラムが復活します

提供内容

仕様駆動開発が重要な理由

申請方法

スタートアップ向けのその他のリソース

Amazon OpenSearch Service、FAISS エンジンでのベクトル検索トラブル対処の考え方：新規ベクトルデータの投入が不安定、または失敗する場合

はじめに

シナリオ：新規ベクトルデータの投入が不安定、または失敗する

原因調査1.1: KNNGraphMemoryUsage によるネイティブメモリ使用状況の調査

原因調査1.2：FreeStorageSpace によるディスク容量の確認

対処1.1：量子化

スカラー量子化 (Scaler Quantization)

直積量子化（Product Quantization）

対処1.2：Memory Optimized Search (対象：HNSW、バージョン3.1+)

対処1.3： Disk mode (対象：バージョン2.17+)

対処1.4：EBSボリュームの追加

まとめ

著者

黒木 琢央 (Takuo Kuroki)

Amazon OpenSearch Service、FAISS エンジンでのベクトル検索トラブル対処の考え方：検索レイテンシの増加が問題になっている場合

はじめに

シナリオ：検索レイテンシーが構築初期より著しく増加している

原因調査2.1：JVMMemoryPressure、CPUUtilizationの確認

原因調査2.2：シャードの偏り状況の調査

対処2.1：シャード最適化

対処2.2：量子化

スカラー量子化 (Scaler Quantization)

直積量子化（Product Quantization）

対処2.3：force merge、warm upの事前実行

対処2.4：refresh_intervalの調整

対処2.5：GPUアクセラレーションの活用(対象：HNSW、バージョン3.1+)

対処2.6：クエリの工夫

ef_search(対象：HNSW、バージョン2.16+)

_sourceフィルタリングでベクトルデータ転送量を削減

まとめ

著者

黒木 琢央 (Takuo Kuroki)

C# を使用した Amazon DynamoDB でのネストされたトランザクションの有効化

トランザクションフレームワークのおさらい

ネストされたトランザクションが重要な理由

サンプルアプリケーションの概要

フレームワークアーキテクチャ

レイヤードアーキテクチャ

設計のハイライト

ネストされたトランザクションのベストプラクティス

実世界のユースケース

まとめ

著者について

Jeff Chen

AWS Security Agent のオンデマンドペネトレーションテストの一般提供を開始

オンデマンドペネトレーションテストの仕組み

AWS Security Agent によるプロアクティブなコンテキスト認識型アプリケーションセキュリティの実現

AWS Security Agent が検出する 3 つの検出結果の例

AWS Security Agent が点と点をつなぐ

脆弱性の連鎖が重大なリスクを生む

最初のペネトレーションテストのセットアップ

論理的な境界としてエージェントスペースを作成する

ドメイン所有権の検証を完了する

黒木琢央 (Takuo Kuroki)

黒木琢央 (Takuo Kuroki)