本記事は 2026 年 4 月 7 日 に公開された「 Launching S3 Files, making S3 buckets accessible as file systems 」を翻訳したものです。 Amazon S3 Files の提供開始をお知らせします。S3 Files は、あらゆる AWS コンピューティングリソースと Amazon Simple Storage Service (Amazon S3) をつなぐ新しいファイルシステムです。 10 年以上前、私がAWS トレーナーだった頃、オブジェクトストレージとファイルシステムの基本的な違いを説明するのに多くの時間を費やしました。よく使ったたとえ話は、S3 オブジェクトを図書館の本に見立てるものでした (1 ページだけ編集することはできず、本ごと差し替える必要がある)。一方、コンピュータ上のファイルはページ単位で変更できます。図を描き、比喩を考え、ワークロードごとに異なるストレージタイプが必要な理由をお客様に説明してきました。そして今日、オブジェクトストレージとファイルシステムの境界がより柔軟になります。 S3 Files により、Amazon S3 はクラウドオブジェクトストアとして唯一、高性能なファイルシステムアクセスを提供します。バケットをファイルシステムとしてアクセスでき、ファイルシステム上のデータ変更は自動的に S3 バケットに反映されます。同期もきめ細かく制御できます。S3 Files は複数のコンピューティングリソースにアタッチでき、データを複製せずにクラスター間で共有できます。 これまでは、Amazon S3 のコスト効率、耐久性、S3 からネイティブにデータを利用できるサービス群と、ファイルシステムの対話的な操作性のどちらかを選ぶ必要がありました。S3 Files でこのトレードオフは不要になります。S3 が組織のデータ基盤となり、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、コンテナ、関数など、あらゆる AWS コンピューティングリソースから直接アクセスできます。本番アプリケーションの実行、ML モデルのトレーニング、エージェント型 AI システムの構築など、用途を問いません。 汎用バケットを、EC2 インスタンス、 Amazon Elastic Container Service (Amazon ECS) や Amazon Elastic Kubernetes Service (Amazon EKS) 上のコンテナ、 AWS Lambda 関数からネイティブファイルシステムとしてアクセスできます。ファイルシステムは S3 オブジェクトをファイルやディレクトリとして表示し、 Network File System (NFS) v4.1 以降のすべての操作 (ファイルの作成、読み取り、更新、削除) をサポートします。 ファイルシステムで特定のファイルやディレクトリを操作すると、関連するメタデータとコンテンツが高性能ストレージに配置されます。デフォルトでは、低レイテンシーアクセスの恩恵を受けるファイルは高性能ストレージに保存され、そこから提供されます。大規模なシーケンシャル読み取りが必要なファイルなど、高性能ストレージに保存されていないファイルについては、S3 Files がスループットを最大化するため Amazon S3 から直接提供します。バイト範囲読み取りでは、要求されたバイトのみが転送されるため、データ移動とコストを最小限に抑えられます。 データアクセスパターンを予測する的確なプリフェッチにも対応しています。高性能ストレージに保存する内容もきめ細かく制御でき、ファイルデータ全体を読み込むか、メタデータのみを読み込むかを選択して、アクセスパターンに応じた最適化が可能です。 仕組みとしては、S3 Files は Amazon Elastic File System (Amazon EFS) を基盤とし、アクティブなデータに対して約 1 ミリ秒のレイテンシーを実現します。NFS の close-to-open 整合性で複数のコンピューティングリソースからの同時アクセスをサポートするため、データを変更する対話的な共有ワークロードに最適です。ファイルベースのツールで連携する AI エージェントや、データセットを処理する ML トレーニングパイプラインなどが該当します。 使い方を紹介します 初めての Amazon S3 ファイルシステムの作成、マウント、EC2 インスタンスからの利用は簡単です。 EC2 インスタンスと汎用バケットを用意しています。以下のデモでは、S3 ファイルシステムを設定し、通常のファイルシステムコマンドで EC2 インスタンスからバケットにアクセスします。 デモでは AWS マネジメントコンソール を使用します。 AWS Command Line Interface (AWS CLI) や Infrastructure as Code (IaC) も利用できます。 デモのアーキテクチャ図は以下のとおりです。 ステップ 1: S3 ファイルシステムを作成します。 コンソールの Amazon S3 セクションで File systems を選択し、 Create file system を選択します。 ファイルシステムとして公開するバケット名を入力し、 Create file system を選択します。 ステップ 2: マウントターゲットを確認します。 マウントターゲットは、仮想プライベートクラウド (VPC) 内に配置されるネットワークエンドポイントです。EC2 インスタンスから S3 ファイルシステムにアクセスするために使用します。 コンソールではマウントターゲットが自動的に作成されます。 Mount targets タブで Mount target ID を確認します。 CLI を使用する場合は、ファイルシステムとマウントターゲットの作成に 2 つのコマンドが必要です。まず create-file-system で S3 ファイルシステムを作成し、次に create-mount target でマウントターゲットを作成します。 ステップ 3: EC2 インスタンスにファイルシステムをマウントします。 EC2 インスタンスに接続し、以下のコマンドを実行します。 sudo mkdir /home/ec2-user/s3files sudo mount -t s3files fs-0aa860d05df9afdfe:/ /home/ec2-user/s3files ~/s3files にマウントされたファイルシステムで、標準的なファイル操作を使って S3 データを直接操作できます。 ファイルシステム上でファイルを更新すると、S3 が自動的にすべての更新を管理し、数分以内に S3 バケット内の新しいオブジェクトまたは既存オブジェクトの新しいバージョンとしてエクスポートします。 S3 バケット上のオブジェクトに加えた変更は、数秒以内にファイルシステムに反映されますが、1 分以上かかる場合もあります。 # Create a file on the EC2 file system echo "Hello S3 Files" > s3files/hello.txt # and verify it's here ls -al s3files/hello.txt -rw-r--r--. 1 ec2-user ec2-user 15 Oct 22 13:03 s3files/hello.txt # See? the file is also on S3 aws s3 ls s3://s3files-aws-news-blog/hello.txt 2025-10-22 13:04:04 15 hello.txt # And the content is identical! aws s3 cp s3://s3files-aws-news-blog/hello.txt . && cat hello.txt Hello S3 Files 知っておくべきこと 技術的な詳細をいくつか紹介します。 S3 Files は AWS Identity and Access Management (IAM) と統合されており、アクセス制御と暗号化に対応しています。 ID ベースのポリシーとリソースポリシーで、ファイルシステムレベルとオブジェクトレベルの両方で権限を管理 できます。 データは TLS 1.3 による転送中の暗号化と、Amazon S3 マネージドキー (SSE-S3) または AWS Key Management Service (AWS KMS) のカスタマーマネージドキーによる保管時の暗号化で常に保護されます。 S3 Files は POSIX パーミッションを使用し、S3 バケットにオブジェクトメタデータとして保存されたファイルパーミッションに対してユーザー ID (UID) とグループ ID (GID) を照合します。 S3 Files の監視には、ドライブのパフォーマンスと更新に関する Amazon CloudWatch メトリクスと、管理イベントのログ記録に AWS CloudTrail を使用できます。 EC2 インスタンスに最新バージョンの EFS ドライバー ( amazon-efs-utils パッケージ ) がインストールされていることを確認してください。AWS が提供する Amazon Machine Image (AMI) にはプリインストールされています。執筆時点では、最新バージョンに更新できます。 本記事では EC2 インスタンスからの S3 Files の使用方法を紹介しました。ECS や EKS のコンテナ ( AWS Fargate の有無を問わず)、Lambda 関数からも S3 バケットをファイルシステムとしてマウントできます。 お客様からよく聞かれるのが、ワークロードに適したファイルサービスの選び方です。AWS のサービスは一見重複しているように見え、アーキテクチャレビュー会議でクラウドアーキテクトを悩ませることもあります。ファイルサービスの使い分けを整理しましょう。 S3 Files は、Amazon S3 に保存されたデータに高性能なファイルシステムインターフェースで対話的に共有アクセスする必要がある場合に最適です。本番アプリケーション、Python ライブラリや CLI ツールを使用する AI エージェント、ML トレーニングパイプラインなど、複数のコンピューティングリソースがデータを読み書きし、共同で変更するワークロードに適しています。データを複製せずにコンピューティングクラスター間で共有アクセスでき、サブミリ秒のレイテンシーと S3 バケットとの自動同期を実現します。 オンプレミスの NAS 環境から移行するワークロードには、 Amazon FSx が使い慣れた機能と互換性を提供します。Amazon FSx は、 Amazon FSx for Lustre によるハイパフォーマンスコンピューティング (HPC) や GPU クラスターストレージにも最適です。 Amazon FSx for NetApp ONTAP 、 Amazon FSx for OpenZFS 、 Amazon FSx for Windows File Server など、特定のファイルシステム機能が必要なアプリケーションに特に有効です。 料金と利用可能リージョン S3 Files は、すべての商用 AWS リージョン で利用できます。 S3 ファイルシステムに保存されたデータの容量、小さなファイルの読み取りとすべての書き込み操作、ファイルシステムと S3 バケット間のデータ同期時の S3 リクエストに対して課金されます。 Amazon S3 の料金ページに詳細 があります。 お客様との対話を通じて、S3 Files はデータサイロ、同期の複雑さ、オブジェクトとファイル間の手動データ移動を排除し、クラウドアーキテクチャの簡素化に役立つと考えています。ファイルシステムで動作する本番ツールの実行、ファイルベースの Python ライブラリやシェルスクリプトに依存するエージェント型 AI システムの構築、ML トレーニング用データセットの準備など、S3 Files を使えば Amazon S3 の耐久性とコストメリットを犠牲にすることなく、対話的な共有ワークロードから S3 データに直接アクセスできます。Amazon S3 を組織のデータ保管場所として使用でき、あらゆる AWS コンピューティングインスタンス、コンテナ、関数からデータに直接アクセスできます。 詳細と使い方については、 S3 Files のドキュメント をご覧ください。 S3 Files をどのように活用されるか、ぜひお聞かせください。フィードバックをお待ちしています。 — seb 著者について Sébastien Stormacq 80 年代半ばに Commodore 64 に触れて以来コードを書き続けている。情熱、好奇心、創造性を武器に、AWS クラウドの価値を引き出すビルダーを支援している。ソフトウェアアーキテクチャ、開発者ツール、モバイルコンピューティングに関心がある。Bluesky、X、Mastodon などで @sebsto をフォローできる。 この記事はVisual Compute Specialist Solutions Architect の森が翻訳を担当しました。

本ブログは 【寄稿】AI民主化に向けた丸紅の取組 （丸紅株式会社）の続編です。 みなさん、こんにちは。総合商社を担当しているソリューションアーキテクトの林です。 前回のブログでは、 丸紅株式会社 デジタル・イノベーション部が内製で開発した社内生成 AI プラットフォーム「Marubeni Chatbot」の誕生から、7,500 人以上への展開、そして業務時間 25〜65% 削減という成果をご紹介しました。 あれから約1年半。丸紅グループの生成AI活用は、さらに大きく進化しています。前回のブログに引き続き、デジタル・イノベーション部 芹川 武尊 氏からお話を伺いました。 今回は、Marubeni Chatbot のその後の進化に加え、新たに立ち上がった 3 つの取り組みをご紹介します。丸紅グループが生成 AI をどのように業務や開発の現場に根付かせてきたか、ぜひご覧ください。 Digital Experts 株式会社について 丸紅グループの生成 AI 活用を語る上で欠かせない存在が、 Digital Experts 株式会社 です。丸紅グループ各社の新たな取り組みに対し、高いエンジニアリング力で実証から実装・運用まで一気通貫で支援する会社です。 Digital Experts の最大の特徴は、 全社員がコーディングエージェントを用いて日常の開発業務を行っている 点です。 社内プレゼン作成ツールをはじめ、業務に必要なシステムを自分たちで開発・活用するなど、生成 AI を日常の開発業務に深く組み込んでいます。本ブログで紹介する取り組みの多くは、丸紅 デジタル・イノベーション部と Digital Experts の緊密な連携によって実現したものです。 取り組み1：Marubeni Chatbot — エージェント AI への進化 前回ブログでご紹介した Marubeni Chatbot は、登録ユーザー数が 7,500 人以上から 10,000 人以上 へと拡大し、丸紅グループ全社の日常業務に欠かせないプラットフォームへと成長しました。 AI エージェントの搭載 基本的な対話 UI に加え、LLM が自律的に試行錯誤を行い複雑なタスクをこなすエージェント機能の搭載を進めています。 このエージェント機能の中核を担うのが、 Amazon Bedrock AgentCore です。AgentCore Runtime を活用することで、従来のサーバーレス構成では課題となっていた長時間実行のタイムアウト問題を解消し、複雑なエージェントタスクを安定して実行できる環境を実現しています。 Marubeni Chatbotのアーキテクチャ図 今までの機能に加え、新たに以下のような機能も追加されています。 PowerPoint 自動生成ツール ：高品質なプレゼンテーションを半自動で生成。社内プレゼン作成の工数を大幅に削減 データ分析・ドキュメント生成システム ：社内情報を参照した上で、データ分析からドキュメント生成までを一気通貫で実行 Marubeni Chatbotの画面イメージ 取り組み2：競合分析システム — 対話形式で市場を読み解く 総合商社において、市場や競合の動向を迅速に把握することは、事業判断の精度を左右する重要な要素です。丸紅は、外部データソースや Web 上の情報を AIと組み合わせることで、競合分析を支援するシステムを構築しました。 本システムでは、財務データベース、Web データ、ユーザーがアップロードした PDFなど、複数のデータソースを横断的に蓄積・参照できる基盤を整備しています。LLM が Tool useを通じて必要なデータへ動的にアクセスすることで、競合企業の候補を AI が列挙し、各社の事業概要や財務状況の要約、 比較分析からレポート作成までを対話形式で AIが支援 します。 競合分析システムの画面イメージ 競合分析業務では、多数の企業情報の収集・整理に加え、財務指標の横断分析や市場ポジションの評価など、長時間かつ複雑な処理が求められます。こうした要件に対応するため、AI エージェントの実行基盤として Amazon Bedrock AgentCore を採用しました。これにより、 AWS Lambda の実行時間制約を超える長時間の自律的な情報収集・分析を実現しています。 さらに、Web 上の公開情報に加え、信頼性の高い外部データソースの定量データを組み合わせることで、実務の意思決定に活用できる分析品質を確保しています。 ユーザーは、「このセクターの競合他社の財務状況を比較して」「最新のニュースを踏まえてリスクを整理して」といった自然言語での問いかけを行うだけで、AIがリアルタイムに関連データを参照しながら回答を生成します。 競合分析システムのアーキテクチャ図 取り組み3：水道管路 AI 劣化予測診断サービス — 作業時間を 99% 削減 丸紅株式会社の旧環境インフラプロジェクト部と Digital Experts 株式会社が共同で開発した、水道管路の AI 劣化予測診断サービスです。日本全国の自治体が抱える水道インフラの老朽化問題に対し、人手不足・技術継承の困難・予算制約という課題を AI で解決することを目指しました。 自治体から管路データを受領し、データの前処理・AI での分析・レポーティングまでの業務全体の作業時間を 5 ヵ月から 1.5 ヵ月へ大幅に削減 。さらに、AI を活用したデータサイエンス業務の自動化により、 分析作業を約 99% 削減 することに成功しました。 AI による分析結果を GIS（地理情報システム）上に反映することで、更新が必要な管路を視覚的に把握できるようになり、自治体の意思決定を大きく支援しています。スモールスタートから始め、ビジネスの成長に合わせて柔軟にスケールできる構成を採用しており、 AWS Control Tower と AWS IAM を活用したマルチアカウント構成により、異なるアクセスレベルのメンバーへの適切な権限分離を実現。機密保護と効率的な共同開発を両立しています。 水道管路 AI 劣化予測診断サービス アーキテクチャ図 取り組み4：AI DLC Unicorn Gym — 「AI と共に開発する」文化の醸成 Marubeni Chatbot の展開や競合分析・水道管路診断といった取り組みを通じて、丸紅グループ内で生成 AI の活用が着実に広がっていました。こうした流れを受け、AWS から「開発プロセスそのものに AI を組み込む」次のステップとして提案・実施したのが、AI DLC Unicorn Gym です。 2026 年 2 月、丸紅株式会社と Digital Experts 株式会社、 丸紅I-DIGIOホールディングス株式会社 の合計 23 名が参加した 3 日間の AI DLC Unicorn Gym を開催しました。 AI DLC Unicorn Gym とは AI-DLC とは、AI をソフトウェア開発の中心的な協働者として位置づけ、開発ライフサイクル全体に AI の能力を組み込む新しい開発手法です。AI が計画を立案・実行し、人間が重要な意思決定を担うという役割分担のもと、Inception（要件定義）・Construction（設計・実装）・Operations（デプロイ・運用）の 3 フェーズで開発を進めます。 Kiro といったコーディングエージェントを活用することで、開発速度を大幅に向上させることができます。AI DLC Unicorn Gym は、この手法を実際のプロダクト開発を通じて体験する AWS のプログラムです。 実業務テーマで挑む 3 日間：開発から成果発表まで 「社内ユーザー用のサンドボックスアプリ基盤」「牛体重推定アプリ」「Marubeni Chatbot 内でのSkills 共有プラットフォーム」「稼働管理ツール」「議事録作成システムの高度化」と、領域・規模感の異なる 5 テーマに取り組みました。途中で方向修正が発生したチームもありましたが、生成 AI を活用することで修正コストを大幅に抑え、 全チームが 3 日間で成果物を完成 させました。最終発表では AWS にデプロイした環境を用いたデモを実施するチームもいました。非エンジニアはAIに要件を伝えるとともにビジネス上の意思決定を行い、エンジニアはAIが生成した成果物をレビューし、要件が正しく反映されていることを確認することで、「AI を使えば自分たちでも作れる」という実感を得る場となりました。「AI-DLC がいかに強力なツールであるかは、ワークショップを体験してみないとなかなか伝わりづらい」というアンケートコメントが象徴するように、実際に手を動かすことで初めて実感できる体験となりました。 最終発表会の様子 議事録作成システム（成果物デモ画面） おわりに Marubeni Chatbot はエージェント機能を搭載し 10,000 人超の日常業務を支えるプラットフォームへと進化。競合分析システムや水道管路 AI 劣化予測診断サービスでは、AI が業務の中核を担い、定量的な成果を生み出しています。そして AI DLC Unicorn Gym では、エンジニア・非エンジニアが共同するAIネイティブなソフトウェア開発プロセスを体感できました。 AWS は今後も、丸紅グループの生成 AI 活用がさらに広がり深まるよう、技術・知見の両面から支援を続けてまいります。本ブログが、皆さまの生成 AI 活用の参考になれば幸いです。 著者プロフィール 芹川 武尊 (Takeru Serikawa) 丸紅株式会社 デジタル・イノベーション部 2022年 東京大学大学院情報理工学系研究科修士課程修了。情報理工学修士（数理最適化に関する研究）。大学院修了後、丸紅株式会社に入社。入社後は、物流関連最適化システムの開発や、生成AIを活用したグループ会社向けChatbotアプリの開発など丸紅グループを横断したプロジェクトに参画。 林 隆太郎 (Ryutaro Hayashi) アマゾンウェブサービスジャパン 総合商社・エネルギー業界担当 ソリューションアーキテクト 大手ガス会社にてガススマートメーター・電力トレーディングのシステム開発を経験した後、総合商社にて全社の IT/DX 推進と国内外のエネルギー領域での事業投資・新規事業開発を担当。現在は AWS 総合商社・エネルギー業界のソリューションアーキテクトとして、業界知識を活かした AWS 活用に携わる。

2026 年 3 月 30 日週、私はチームと一緒に AWS 香港ユーザーグループ を訪問しました。香港には小さいながらも強力なコミュニティがあり、彼らにはすばらしいエネルギーと情熱があります。彼らは最近、新しい AI ユーザーグループを立ち上げたので、私たちはさらに多くの人が参加することを願っています。すばらしい料理と会話を通して、コミュニティとの絆を強めることもできました。 2026 年 4 月 6 日週は、まずいくつかの主要な発表について詳しく見ていきます。 AWS DevOps エージェントおよびセキュリティエージェント GA 前回の re:Invent では、複数のステップにわたって自律的に作業して成果を達成し、仕事が完了するまで継続的に活動する フロンティアエージェントの概念 を紹介しました。最初の 2 つ ( AWS DevOps エージェントと AWS セキュリティエージェント ) は、プレビュー後に一般提供されるようになりました。 AWS DevOps エージェント は、インシデントの調査、解決までの時間の短縮、問題の発生前の防止など、クラウド運用の実行に役立ちます。ユナイテッド航空、ウエスタンガバナーズ大学 (WGU)、T-モバイルなどのお客様は既に DevOps エージェントを使用してインシデント対応を加速し、大規模な運用を簡素化しています。WGU では、解決にかかる時間が数時間から数分に短縮され、プレビュー版では MTTR が最大 75% 短縮され、解決が 3～5 倍早くなったという報告が顧客から寄せられています。詳細については、 Sébastien のプレビューブログ投稿 と GA の発表 をご覧ください。 AWS セキュリティエージェント は、開発ライフサイクルに継続的かつ状況に応じたペネトレーションテストを行います。このエージェントは人間のペネトレーションテスターのように動作します。LG CNS、HENNGE、Wayspring などのお客様は好調な業績を上げています。LG CNS では、誤検出が大幅に減り、テストにかかる時間が 50% 以上短縮され、コストも最大 30% 削減されるという結果が出ています。詳細については、 Esra のプレビューブログ投稿 と GA の発表をご覧ください。 どちらも AWS クラウド、マルチクラウド、オンプレミス環境で機能するように設計されています。面倒な作業を処理できるチームメイトをいつでも確保できるので、最も重要なことに集中できます。 AWS サービス可用性アップデート AWS のサービスまたは機能の可用性が変化した場合、私たちは運用の中断を最小限に抑えるために、利用可能な代替案について AWS 製品ライフサイクル の変更に関するガイダンスをお客様に提供し、移行をサポートします。次のライフサイクル変更は、2026 年 3 月 31 日に更新されました。 メンテナンス中のサービスの可用性変更ガイド AWS App Runner AWS Audit Manager AWS CloudTrail – Lake AWS Glue – Ray のジョブ AWS IoT FleetWise Amazon Application Recovery Controller (ARC) – 準備状況チェック Amazon Comprehend – トピックモデリング、イベント検出、および迅速な安全分類 Amazon Rekognition – ストリーミングイベント と バッチイメージコンテンツモデレーション Amazon Simple Notification Service (Amazon SNS) – メッセージデータ保護 (MDP) 日没時のサービスの可用性変更ガイド: AWS Service Management Connector Amazon RDS Custom for Oracle Amazon WorkMail Amazon WorkSpaces – シンクライアント 日没時のサービスリーチ: Amazon Chime SDK – プロキシセッション 私たちは、可用性の変化がお客様の業務に影響を与える可能性があることを理解しています。具体的なガイダンスについては、関連するサービスドキュメントを参照するか、AWS サポートにお問い合わせください。 2026 年 3 月 30 日週のリリース 2026 年 3 月 30 日週のリリースのうち、私が注目したリリースをいくつかご紹介します。 Amazon ECS が ECS マネージドインスタンス用のマネージドデーモンを発表 新しい AWS サステナビリティコンソール: スコープ 1～3 のレポートを 1 か所に Amazon Bedrock AgentCore Evaluations が一般提供されました AWS Transform カスタムが自動コードベース分析の一般提供を発表 Amazon CloudWatch が OpenTelemetry Container Insights for Amazon EKS を発表 (プレビュー) 最大 72 個の vCPU を搭載した Amazon Lightsail 用の新しいコンピューティング最適化インスタンスバンドル Amazon CloudFront が署名付き URL と署名付きクッキーの SHA-256 をサポートするようになりました AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 その他のアップデート 皆さんの関心を引くと思われるその他のニュースをいくつかご紹介します。 AWS 上のエージェンティック AI 開発のためのアーキテクチャ AWS Network Load Balancer を使用する際のデータ転送コストの最適化 AWS World Sports Innovation Cup の発表 – お客様のアイデアはゲームチェンジャーになるでしょうか? 本番環境での AI エージェントハルシネーションを阻止する 5 つのテクニック 3D インタラクティブグローブを通じてグローバルな AWS コミュニティを探索する AWS ブログ投稿の全リストについては、必ず AWS ブログ ページをご覧ください。 AWS の詳細について学び、今後予定されている AWS 主催の対面イベントやバーチャルイベント 、 スタートアップイベント 、 開発者向けイベント 、 AWS Summits や AWS Community Days を閲覧して、それらに参加してください。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。 2026 年 4 月 6 日週のニュースは以上です。2026 年 4 月 13 日週の Weekly Roundup もお楽しみに! – Channy 原文は こちら です。

2026 年4 月 3 日、 Amazon Bedrock Guardrails でクロスアカウントセーフガードが一般提供されたことを発表しました。これは、組織内の複数の AWS アカウント全体での安全管理の一元的な実施と管理を可能にする新機能です。 この新機能により、組織の管理アカウント内の新しい Amazon Bedrock ポリシー 内でガードレールを指定できます。これにより、Amazon Bedrock でモデルを呼び出すたびに、設定されたセーフガードがすべてのメンバーエンティティ全体で自動的に実施されます。この組織全体での実装では、一元的な制御と管理により、すべてのアカウントと生成 AI アプリケーションでの統一された保護がサポートされています。この機能により、組織的なセーフガードに加えて、ユースケース要件に応じて、アカウントレベルおよびアプリケーション固有の制御を柔軟に適用できます。 組織レベルの実施 では、ポリシー設定を通じて、組織の管理アカウントから組織内のすべてのエンティティまで、単一のガードレールが適用されます。このガードレールでは、すべての Amazon Bedrock モデルの呼び出しに対して、組織単位 (OU) や個人アカウントを含むすべてのメンバーエンティティ全体に自動的にフィルターが適用されます。 アカウントレベルの実施 により、AWS アカウント内のすべての Amazon Bedrock モデルの呼び出し全体で、設定されたセーフガードの実施を自動的に有効にします。アカウントレベルのガードレール内の設定されたセーフガードは、すべての推論 API コールに適用されます。 単一の統一されたアプローチを通じて、信頼できる包括的な保護を確立し、一元管理できるようになりました。これにより、個々のアカウントやアプリケーションを監視する管理上の負担を大幅に軽減しながら、企業の 責任ある AI 要件の一貫した遵守がサポートされています。セキュリティチームが各アカウントの設定やコンプライアンスを個別に監視および検証する必要はもうありません。 Amazon Bedrock Guardrails での一元的な実行を開始する Amazon Bedrock Guardrails コンソールで、アカウントレベルおよび組織レベルの実施の設定を開始できます。実施の設定の前に、ガードレール設定をサポートする特定のバージョンでガードレールを作成する必要があります。これは不変のままになり、メンバーアカウントによって変更されることはありません。また、 ガードレール用のリソースベースのポリシー など、新しい機能を使用するための 前提条件 を満たす必要があります。 アカウントレベルの実施を有効にするには、 アカウントレベルの実施の設定 のセクションで [ 作成 ] を選択します。 このリージョンのこのアカウントからのすべての Bedrock 推論呼び出しに自動的に適用されるガードレールとバージョンを選択できます。一般提供に伴い、[ 含める ] または [ 除外する ] のいずれかの動作で、どのモデルが実施の影響を受けるかを定義する新機能が導入されました。 また、[ 包括的 ] または [ 選択的 ] のいずれかを使用して、システムプロンプトとユーザープロンプトの選択的コンテンツ保護制御を設定することもできます。 発信者が何をタグ付けしたかに関係なく、すべてでガードレールを実施したい場合は、[ 包括的 ] を使用します。発信者が機密コンテンツを正しく識別することを信頼できない場合は、これがより安全なデフォルトです。 発信者が適切なコンテンツへのタグ付けすることを信頼し、不要なガードレール処理を減らしたい場合は、[ 選択的 ] を使用してください。これは、発信者が混在した事前検証済みのコンテンツとユーザー生成コンテンツを処理し、特定の部分に適用されるガードレールのみが必要な場合に便利です。 実施を作成したら、アカウント内のロールを使用する実施をテストおよび検証できます。アカウントで実施されるガードレールは、プロンプトと出力の両方に自動的に適用される必要があります。 ガードレールの評価情報について応答を確認してください。ガードレールの応答には、実施したガードレール情報が含まれます。 InvokeModel 、 InvokeModelWithResponseStream 、 Converse 、または ConverseStream API を使用する Bedrock 推論呼び出しを作成してテストすることもできます。 組織レベルの実施を有効にするには、 AWS Organizations コンソール に移動して、[ ポリシー ] メニューを選択します。 コンソールで Bedrock ポリシー を有効にできます。 ガードレールを指定する Bedrock ポリシーを作成し、それをターゲットアカウントまたは OU にアタッチできます。有効にした [ Bedrockポリシー ] と [ ポリシーを作成 ] を選択します。ガードレール ARN とバージョンを指定し、AWS Organizations の入力タグ設定を設定します。詳細については、「 AWS Organizations の Amazon Bedrock ポリシー 」と「 Amazon Bedrock ポリシーの構文と例 」をご覧ください。 ポリシーを作成したら、[ ターゲット ] タブで目的の組織単位、アカウント、ルートにポリシーをアタッチできます。 ポリシーをアタッチする組織のルート、OU、または個人アカウントを検索して選択し、[ ポリシーをアタッチ ] を選択します。 メンバーアカウントでガードレールが実施されていることをテストして、どのガードレールが実施されているかを確認できます。アタッチされているメンバーアカウントから、[組織レベルの実施の設定] セクションに、組織が実施したガードレールが表示されている必要があります。 その後、指定されたガードレール内の基本的なセーフガードが、すべてのメンバーエンティティ全体のモデル推論リクエストごとに自動的に実施され、一貫した安全管理が確保されます。個々のチームやアプリケーションのさまざまな要件に対応するために、関連付けられたガードレールを備えたさまざまなポリシーを組織内のさまざまなメンバーエンティティにアタッチできます。 知っておくべきこと 以下は、GA 機能に関する重要な考慮事項です: Bedrock に特定のモデルを推論のために含めるか除外するかを選択できるようになり、これにより、モデルの呼び出しの一元的な実施を有効にできます。また、システムプロンプトと入力プロンプトの一部または全部を保護するように選択することもできます。詳細については、「 Amazon Bedrock Guardrails の実施によるクロスアカウントセーフガードの適用 」を参照してください。 ポリシーで正確なガードレールの Amazon リソースネーム (ARN) を指定していることを確認してください。不正確または無効な ARN を指定すると、ポリシー違反となり、セーフガードが実施されず、Amazon Bedrock のモデルを推論に使用できなくなります。詳細については、「 Amazon Bedrock ポリシーを使用するためのベストプラクティス 」をご覧ください。 自動推論チェックは、この機能ではサポートされていません。 今すぐご利用いただけます Amazon Bedrock Guardrails のクロスアカウントセーフガードは、現在 Bedrock Guardrails が利用可能なすべての AWS 商用リージョンと GovCloud リージョンで一般提供されています。リージョンごとの利用可否と今後のロードマップについては、「 AWS Capabilities by Region 」にアクセスしてください。それぞれの実施されたガードレールには、設定されたガードレールに従って料金がかかります。個々のガードレールの料金の詳細については、 Amazon Bedrockの料金ページ をご覧ください。 Amazon Bedrock コンソール でこの機能ををお試しいただき、 AWS re:Post for Amazon Bedrock Guardrails に、または AWS サポートの通常の連絡先を通じて、フィードバックをぜひお寄せください。 – Channy 原文は こちら です。

2026 年 4 月 1 日、 Amazon Elastic Container Service (Amazon ECS) マネージドインスタンス のマネージドデーモンサポートを発表いたしました。この新機能により、 2025 年 9 月に導入 したマネージドインスタンスのエクスペリエンスが拡張されます。プラットフォームエンジニアは、アプリケーション開発チームとの調整を必要とせずに、モニタリング、ログ記録、トレースツールなどのソフトウェアエージェントを独立して制御できるようになります。また、すべてのインスタンスで必要なデーモンを常に実行し、包括的なホストレベルのモニタリングを実現できるため、信頼性も向上します。 コンテナ化されたワークロードを大規模に実行する場合、プラットフォームエンジニアは、インフラストラクチャのスケーリングやパッチ適用から、アプリケーションの確実な実行の維持、それらのアプリケーションをサポートする運用エージェントの保守まで、幅広い責任を管理します。これまで、こうした懸念事項の多くは密接に結びついていました。モニタリングエージェントを更新するということは、アプリケーションチームとの調整、タスク定義の変更、アプリケーション全体の再デプロイを意味します。数百、数千のサービスを管理している場合、これは運用上の大きな負担となります。 デーモンの分離型ライフサイクル管理 Amazon ECS では、プラットフォームチームが運用ツールを一元管理できるようにする、専用のマネージドデーモンコンストラクトが導入されました。このように懸念事項を分離することで、プラットフォームエンジニアは、アプリケーションチームによるサービスの再デプロイを必要とせずに、すべてのインスタンスで必要なツールを一貫して使用できるようにしつつ、モニタリング、ログ記録、トレースの各エージェントをインフラストラクチャに個別にデプロイして更新できます。デーモンはアプリケーションタスクの前に起動し、最後にドレインすることが保証されているため、アプリケーションで必要なときにいつでもログ記録、トレース、モニタリングを利用できます。 プラットフォームエンジニアは、マネージドデーモンを複数のキャパシティプロバイダーにデプロイしたり、特定のキャパシティプロバイダーをターゲットにしたりできるため、インフラストラクチャ全体でエージェントを柔軟に展開できます。リソース管理も一元化されており、各インスタンスが複数のアプリケーションタスクで共有されるデーモンコピーを 1 つだけ実行するため、チームはリソース使用率を最適化しながら、AMI を再構築したりタスク定義を更新したりすることなくデーモン CPU とメモリのパラメータをアプリケーション設定とは別に定義できます。 試してみましょう ECS マネージドデーモンを試すために、最初のマネージドデーモンとして Amazon CloudWatch エージェント を使用して開始することにしました。私は以前、 ドキュメント を使用してマネージドインスタンスのキャパシティプロバイダーで Amazon ECS クラスターをセットアップしていました。 Amazon Elastic Container Service コンソールで、ナビゲーションペインに新しい [デーモンタスク定義] オプションがあることに気付きました。このオプションで、マネージドデーモンを定義できます。 [新しいデーモンタスク定義を作成] を選択して開始します。この例では、CloudWatch エージェントに 1 つの vCPU と 0.5 GB のメモリを設定しました。 [デーモンタスク定義ファミリー] フィールドに、後で識別できる名前を入力しました。 [タスク実行ロール] では、ドロップダウンから [ECSTaskExecutionRole] を選択しました。 [コンテナ] セクションで、コンテナにわかりやすい名前を付け、イメージ URI に public.ecr.aws/cloudwatch-agent/cloudwatch-agent/cloudwatch-agent:latest といくつかの詳細を貼り付けました。 すべてを確認したあと、 [作成] を選択しました。 デーモンタスク定義が作成されたら、 クラスター ページに移動し、以前作成したクラスターを選択すると、新しい [デーモン] タブが見つかりました。 ここで [デーモンを作成] ボタンをクリックし、フォームに記入してデーモンを設定するだけです。 [デーモン設定] で、新しく作成したデーモンタスク定義ファミリーを選択してから、デーモンに名前を割り当てました。 [環境設定] では、前に設定した ECS マネージドインスタンスのキャパシティプロバイダーを選択しました。設定を確認したあと、 [作成] を選択しました。 これで、ECS は、選択したキャパシティプロバイダーのプロビジョニングされたすべての ECS マネージドインスタンスでデーモンタスクが最初に起動することを自動的に確認します。実際の動作を確認するために、サンプルの nginx ウェブサービスをテストワークロードとしてデプロイしました。ワークロードがデプロイされると、コンソールで ECS マネージドデーモンが CloudWatch エージェントデーモンをアプリケーションとともに自動的にデプロイしたことを確認できました。手動による操作は必要ありません。 後でデーモンを更新すると、ECS は更新されたデーモンを使用して新しいインスタンスをプロビジョニングして、まずデーモンを起動し、次にアプリケーションタスクを新しいインスタンスに移行してから古いインスタンスを終了することで、ローリングデプロイを自動的に処理しました。この「停止前に開始する」アプローチにより、デーモンを継続的にカバーできます。ログ記録、モニタリング、トレースの各エージェントは、データ収集においてギャップがなく、更新中ずっと動作し続けます。設定したドレイン率によってこの置き換えのペースが制御され、アプリケーションのダウンタイムなしでアドオンの更新を完全に制御できるようになりました。 仕組み マネージドデーモンエクスペリエンスでは、独自のパラメータと検証スキームを備えた、タスク定義とは別の新しいデーモンタスク定義が導入されています。新しい daemon_bridge ネットワークモードにより、デーモンはアプリケーションネットワーク設定から切り離されたまま、アプリケーションタスクと通信できます。 マネージドデーモンは、運用ツールに不可欠である高度なホストレベルのアクセス機能をサポートします。プラットフォームエンジニアは、デーモンタスクを特権コンテナとして設定したり、Linux 機能を追加したり、基盤となるホストファイルシステムからパスをマウントしたりできます。これらの機能は、ホストレベルのメトリクス、プロセス、システムコールを詳細に可視化する必要があるモニタリングおよびセキュリティエージェントにとって特に役立ちます。 デーモンがデプロイされると、ECS はアプリケーションタスクを配置する前に、コンテナインスタンスごとにデーモンプロセスを 1 つだけ起動します。これにより、アプリケーションがトラフィックの受信を開始する前に、運用ツールの準備ができていることが保証されます。ECS は自動ロールバックを使用したローリングデプロイもサポートしているため、安心してエージェントを更新できます。 今すぐご利用いただけます Amazon ECS マネージドインスタンスのマネージドデーモンサポートは、現在 すべての AWS リージョン でご利用いただけます。開始するには、Amazon ECS コンソールにアクセスするか、 Amazon ECS ドキュメント を確認してください。また、 このウェブサイト にアクセスして、新しいマネージドデーモンのアプリケーションプログラミングインターフェイス (API) を確認することもできます。 マネージデーモンを使用するための追加コストはありません。お支払いいただくのは、デーモンタスクによって消費された標準コンピューティングリソースに対してのみです。 原文は こちら です。

本ブログは 2026 年 4 月 7 日に公開された AWS Blog “ Building AI defenses at scale: Before the threats emerge ” を翻訳したものです。 AWS は数十年にわたり、世界中で事業を展開する何百万のお客様を同時に保護するためのプロセスとツールを開発してきました。AWS のセキュリティチームと脅威インテリジェンスチームは、日々、表に出ることのない AI と自動化を駆使した取り組みを続けています。AI を活用したログ分析システムにより、SecOps エンジニアのセキュリティログ分析に要する時間は平均 6 時間からわずか 7 分にまで短縮されました。この 50 倍もの生産性向上により、脅威の検出と対応をかつてないスピードで行えるようになっています。AWS 全体では、1 日あたり 400 兆を超えるネットワークフローを分析し、新たな脅威の兆候となるパターンを検出しています。2025 年だけでも、Amazon S3 上のお客様のファイルを不正に暗号化しようとする 3 億件を超える試みをブロックしました。 あるお客様を保護する過程で得た知見は、すべてのお客様の保護に役立ちます。この規模で運用しているからこそ、新たに検出した脅威がすべてのお客様の防御強化に直結します。AI はすでにその中核を担っています。 サイバーセキュリティのための新たなクラスの AI 本日 (2026 年 4 月 7 日)、 Anthropic が Project Glasswing を発表しました 。これは、世界で最も重要なソフトウェアの保護と、AI の進化に伴い業界に求められるサイバーセキュリティの実践を前進させることを目的としたイニシアチブです。重要なデジタルインフラストラクチャを構築・運用する組織は、世界が依存するシステムの脆弱性を発見し修正するための新しいクラスの AI モデルである Claude Mythos Preview に早期アクセスできるようになります。世界で最も重要なインフラストラクチャの一端を保護する役割を担う AWS は、この取り組みを推進するうえで重要な役割を果たしています。 このプロジェクトを支えるのは、Anthropic のこれまでで最も高度な AI モデルであり、サイバーセキュリティにおける推論能力と AI 能力の飛躍的な進歩を実現する Claude Mythos Preview です。Claude Mythos Preview は根本的に新しいモデルクラスであり、Anthropic のこれまでのフロンティアモデルを上回る知性と能力を備え、サイバーセキュリティ、ソフトウェアコーディング、複雑な推論タスクでより高いパフォーマンスを発揮します。 Project Glasswing の一環として、AWS では継続的な AI セキュリティレビューが行われている重要なコードベースに Claude Mythos Preview をすでに適用しています。十分にテストされた環境であっても、コードをさらに強化できる箇所の特定に役立っています。内部テストでは、Claude Mythos Preview がセキュリティの検出結果を洗い出す際に従来のモデルよりも高い生産性を発揮し、エンジニアによる手動のガイダンスが少なくても実用的な結果を提供できることが実証されました。一部のお客様にも早期アクセスを提供しており、自社のセキュリティワークフローへの Claude Mythos Preview の導入を通じて、モデルの進化の方向性を形作ることに貢献しています。AWS にとって Claude Mythos Preview は、すでに活用している AI ツールの自然な進化形です。テクノロジーがより強力になるにつれて、防御もそれに合わせて強化していかなければなりません。 こうしたイノベーションこそが AWS の取り組みを推進するものであり、Claude Mythos Preview がエンタープライズでの利用に対応できるよう Anthropic と緊密に連携してきました。AWS は、Anthropic のミッションクリティカルなワークロードや安全性の研究、基盤モデル開発を支える主要なクラウドプロバイダーです。より広い視点で見ると、世界をリードする AI 企業が最先端モデルの構築、トレーニング、デプロイに利用する基盤インフラストラクチャを AWS が提供しています。数十年にわたるセキュリティの経験をこのパートナーシップに活かし、さらに多くの組織が Claude Mythos Preview を基盤として安全かつ大規模に運用できるよう支援しています。 Claude Mythos Preview は、これまでにないスケールと速度で脆弱性を発見し、実際に機能するエクスプロイトを構築できる新世代モデルの先駆けです。Anthropic と AWS は意図的に慎重なリリースアプローチをとっています。まず少数の組織からアクセスを開始し、数億人のユーザーに影響を与えるソフトウェアやデジタルサービスを提供するインターネットの重要インフラ企業やオープンソースのメンテナーが優先されます。目標は、世界で最も重要なソフトウェアの脆弱性を発見し修正することです。Claude Mythos Preview は Amazon Bedrock を通じて限定 (リサーチ) プレビューとして利用可能で、カスタマーマネージド暗号化、VPC 分離、詳細なログ記録などのエンタープライズグレードのセキュリティコントロールを備えています。これにより、本番環境のアセットを不要なリスクにさらすことなく、Claude Mythos Preview の機能を検証できます。 セキュリティを中核に据えた AWS のサービス設計 Project Glasswing における AWS の取り組みは、ミッションクリティカルなワークロードを 20 年以上にわたって保護してきた経験の中で培った理念に基づいています。脅威が現実化してから防御を構築するのでは遅いのです。先を見越して新しいテクノロジーを採用し、まず保護策を構築して自社の運用に大規模にデプロイし、そこから得た知見に基づいて改善を重ねていく必要があります。 これこそが AWS が AI とセキュリティにおいて実践してきたことです。AWS のアプローチは多岐にわたります。脅威ハンティングと脆弱性リサーチによるプロアクティブな防御、進行中の攻撃キャンペーンへの動的な対応、そしてセキュリティの取り組みが業界最高水準を満たすことを検証する第三者認証です。こうした運用経験から、AI がセキュリティ業務をどこで加速させ、人間の判断がどこで不可欠なのかを学びました。また、セキュリティのイノベーションは実用的でなければならない、つまりお客様にご活用いただく前に本番環境で実証されている必要があるということを改めて実感しました。 だからこそ AWS は、安全な AI とはどうあるべきかを定義する取り組みにも貢献しています。AWS は AI サービスにおける ISO 42001 認証を取得した最初の主要クラウドプロバイダーとなりました。OWASP、Coalition for Secure AI、Frontier Model Safety Framework にも積極的に参加しています。また、エコシステム全体でのより優れた脅威インテリジェンスの共有を実現するため、Open Cybersecurity Schema Framework (OCSF) を共同設立しました。 AWS Nitro System はワークロード間の数学的に証明された分離を実現します。ゼロオペレータアクセスアーキテクチャにより、AWS のオペレーターがお客様のデータにアクセスすることはできません。これらは将来の理想像ではなく、AWS が現在、大規模に日々実践していることです。 Amazon Bedrock は、これらの原則を AI の領域で実現するサービスです。ポリシー適用型のアクセス制御、モデルによる脆弱性の特定・検証の有効性を測定する組み込みの評価ツール、お客様専用の仮想プライベートクラウド内でワークロードを実行する機能を提供します。さらに AWS は、一般提供されている Claude 基盤モデルについて FedRAMP High および Department of Defense Security Requirements Guide Impact Level 4/5 の認定を取得した最初のクラウドプロバイダーでもあります。最も厳しいセキュリティ要件を持つ組織が、Anthropic のテクノロジーを安心して利用できる場として Amazon Bedrock を選んでいることの証です。 今すぐ始めるには AWS の大規模運用を支える原則は、使用する AI ツールに関係なく適用できます。包括的なオブザーバビリティ、多層防御、価値を生む領域での自動化、そして不可欠な場面での人間の判断です。以下にその実践方法をご紹介します。 次世代の AI セキュリティに備える。 Claude Mythos Preview は、サイバーセキュリティを変革する新世代の AI モデルの先駆けとなるものです。これらの機能がより広く利用可能になったときに備えて、今からセキュリティポスチャの強化を始めてください。Claude Mythos Preview は Amazon Bedrock を通じた限定プレビューとして利用可能であり、アクセスは許可リストに登録された初期の組織に限定されています。許可リストに登録されている場合は、AWS アカウントチームから直接ご連絡します。 AWS Security Agent でオンデマンドのペネトレーションテストを実行する。 一般提供が開始された AWS Security Agent は、手動のペネトレーションテストと比べてわずかなコストで 24 時間 365 日稼働する自律型ペネトレーションテストを提供します。ペネトレーションテストを、定期的に発生するボトルネックから、AWS、Azure、GCP、その他のクラウドプロバイダー、オンプレミスにわたり開発速度に合わせてスケールするオンデマンド機能へと変革します。AWS Security Agent は新しいクラスのフロンティアエージェントです。目標達成のために自律的に動作し、同時並行のタスクに対応するためにスケールし、人間の常時監視なしに継続的に稼働します。高度な多段階の攻撃シナリオを通じてセキュリティの脆弱性を発見、検証、報告する専門的な AI エージェントをデプロイします。検証なしに検出結果を生成する従来のスキャナとは異なり、AWS Security Agent は潜在的な脆弱性を特定した後、標的を絞ったペイロードと攻撃チェーンを使用してエクスプロイトを試み、正当なセキュリティリスクであることを確認します。各検出結果には、CVSS リスクスコア、アプリケーション固有の重大度評価、詳細な再現手順、修正の提案が含まれます。その結果、かつて数週間かかっていたペネトレーションテストが数時間で完了し、最も重要なシステムだけでなくアプリケーションポートフォリオ全体にわたってセキュリティカバレッジをスケールできるようになります。新規のお客様は 2 か月間の無料トライアルで AWS Security Agent をお試しいただけます。 Amazon Bedrock で信頼できる AI アプリケーションを構築する。 生成 AI を活用して構築するチームにとっての課題は、AI を機能させることだけではなく、AI を安全に機能させることです。Amazon Bedrock は、責任ある AI のデプロイに必要なセキュリティと安全性のコントロールを提供します。 自動推論 は、形式的論理を使用してハルシネーションによる事実の誤りを防ぐ、先駆的かつ唯一の AI セーフガードであり、99% の精度で検証可能な説明を提供します。これは、AWS のストレージ、アイデンティティ、ネットワーキング全体で 10 年以上にわたり形式的手法を適用してきた経験を基に磨き上げてきたものです。Amazon Bedrock はさらに、有害なコンテンツをブロックしコンテンツポリシーを適用するカスタマイズ可能なガードレールに加え、ワークロード全体にわたって AI の動作を追跡し異常を検出する包括的なオブザーバビリティも提供します。 脅威の状況は待ってくれない 脅威の状況は、こちらの対応を待ってはくれません。国家レベルの攻撃者、ランサムウェアオペレーター、サプライチェーン攻撃者は、すでに AI を活用して攻撃のスケールを拡大しています。AWS の使命は、まず防御を構築し、大規模にデプロイし、そこで得た知見をコミュニティ全体に共有・還元することで、常に一歩先を行くことです。 これこそ AWS が日々実践していることです。お客様にお使いいただく前に、まず自社の運用でテクノロジーが機能することを実証しています。標準に従うのではなく、自ら標準を打ち立てています。そして、先を見越して明日の課題に今日から取り組んでいます。 AI の機能がどれだけ進化しても、このアプローチは変わりません。AWS は引き続き防御を先に構築し、大規模な運用の中で改良を重ねていきます。そして Anthropic のようなパートナーと協力し、次世代の AI セキュリティツールがこの規模で防御を行うエンタープライズの実際のニーズに応えられるよう取り組んでいきます。 関連情報 AWS Security Agent の利用を開始する AI コンテンツの安全性を実現する Amazon Bedrock Guardrails を確認する Securing AI at AWS で取り組みを確認する AWS Responsible AI について確認する AWS AI Compliance について確認する 新たな脅威について AWS Security Bulletins を確認する Amy Herzog Amy Herzog は Amazon Web Services (AWS) のバイスプレジデント兼最高情報セキュリティ責任者 (CISO) です。セキュリティを最優先に掲げる AWS において、クラウドセキュリティプロフェッショナルのグローバル組織を率いています。AWS 入社前は、Amazon の Devices and Services、Media and Entertainment、Advertising の各事業で CISO を務め、Alexa+ や Ring などのコンシューマーテクノロジー製品のセキュリティを統括しました。また、低軌道衛星を通じて世界中のお客様やコミュニティに高速かつ高信頼のブロードバンドを提供する Amazon のイニシアチブである Project Kuiper のセキュアな開発にも重要な役割を果たしました。 <!-- '"` --> 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

学生は、私たちが暮らす世界を形作る未来の意思決定者です。この信念が、本日発表するすべての根幹にあります。まだ学び、実験し、何を作りたいかを模索している段階のみなさんに、本格的なツールを届けたいと考えています。 本日より、Kiro Students プランを開始します。対象の大学生は、 月 1,000 クレジット付きの Kiro を 1 年間無料 でご利用いただけます。クレジットカード不要。トライアル期間の制限もありません。あとは、開発するだけです。 本日のローンチ まず 11 の大学からスタートします。 Arizona State University（ASU） California Polytechnic State University, San Luis Obispo California State University, Fullerton Carnegie Mellon University（CMU） Georgia Institute of Technology（Georgia Tech） Hampton University New York University（NYU） University of Chicago（UChicago） University of Toronto University of Waterloo University of Texas at Austin（UT Austin） これはまだ始まりにすぎません。今後、さらに多くの大学への拡大を進めています。お使いの大学がまだリストにない場合は、 リクエスト できます。 サインアップ方法 開始までわずか数ステップです： サインアップまたはログインします。大学のメールアドレスを使用して、AWS Builder ID で Kiro アカウントを作成してください。すでに Kiro アカウントをお持ちの場合は、手続きの前に大学のメールアドレスがアカウントに紐づいていることを確認してください。 学生ステータスを確認します。サインイン後、対象大学の学生であれば、アカウントページに「You are eligible for Kiro Students」というバナーが表示されます。確認ボタンをクリックし、SheerID による簡単な認証を完了してください。1 分程度で完了します。 構築を始めましょう。認証が完了すると、1 年間にわたり月 1,000 クレジットをすぐに利用できます。 以上です。長い申請手続きも、待ち時間もありません。 いくつかの注意事項 認証は 1 回限り。 学生ステータスの認証は 1 回のみ可能です。情報が正しいことを確認してから手続きしてください。 超過利用なし。 月 1,000 クレジットの上限に達した場合は、次のサイクルまでお待ちいただく必要があります。クレジットは翌月に繰り越されません。 1 年間の終了後。 1 年間のアクセス期間が終了すると、アカウントは自動的に Kiro 無料プランにダウングレードされます。 なぜこれを行うのか プロフェッショナルグレードのツールに慣れるのに最適な時期は、まだ自由に探索し、壊し、プレッシャーなく学べる時期だと私たちは考えています。AI エージェントは急速に標準的なエンジニアリングツールキットの一部になりつつあり、学生のみなさんにも本格的なアクセスを提供したいのです。 Kiro Students プランは、プロのエンジニアリングチームが日々使用しているのと同じレベルのツールを提供します。つまり、就職する頃には、これらのツールがすでに自然に使えるようになっているということです。 また、起業に関心を持つ学生が増えていますが、このプランはそうしたみなさんにもぴったりです。Kiro の仕様駆動開発を使えば、ナプキンに書いたアイデアから動くプロトタイプまで素早くたどり着けます。シンプルなプロンプトから始めれば、Kiro が要件、アーキテクチャ、順序立てた実装計画を生成します。あとはイテレーションを重ねてリリースするだけです。 授業のプロジェクト、ハッカソン、スタートアップの MVP、何を作るにしても、Kiro がサポートします。 なぜ Kiro なのか ほとんどの AI コーディングツールは、プロンプトからコードを生成するのは得意です。しかし、エージェントと連携する際には、計画を立てることが良い結果を得るために極めて重要になっています。Kiro はその両方を行います。プロセスに構造をもたらし、その過程でみなさんをより優れたビルダーへの成長いただけます。 仕様駆動開発では、要件が何であるかや、どのように構築すればよいかを事前に知っている必要はありません。作りたいものを説明するだけで、Kiro がそれを明確な要件、設計、順序立てたタスクに分解します。このプロセスは、最も重要なスキルの一つを教えてくれます。大きくて手強い問題を、小さく管理しやすいステップに分解する力です。何度も繰り返すうちに、それは自然と身につきます。単にコードを出荷しているのではありません。どんな役割でも役立つ構造的な思考力を養っているのです。 事前の計画なしに素早く動きたいときは、Kiro のバイブコーディングが活躍します。構造が必要なときもあれば、スピードが必要なときもあります。両方をシームレスに切り替えられます。 Kiro はどこでも使えます。IDE だけでなく、Kiro の CLI は同じエージェント機能をターミナルに直接もたらします。素早いイテレーション、スクリプティング、あるいは単にコマンドラインが好みの方に最適です。 さらに、エージェントフックはテストの更新やドキュメントの同期など、忘れがちな作業や面倒な作業を自動化します。ステアリングファイルでプロジェクトごとにコーディング標準を設定でき、ネイティブ MCP サポートにより IDE を離れることなくデータベース、API などに接続できます。 「学生は未来のビルダーであるだけでなく、今この瞬間のビルダーでもあります。Kiro は構築のためのツールですが、思考のためのツールでもあります。研究のため、アイデアを探求するため、好奇心を形にするためのツールです。学生開発者のみなさんが何を生み出すのか、楽しみでなりません。」— Deepak Singh、Kiro VP 新しいフレームワークを学んでいるとき、卒業制作に取り組んでいるとき、深夜 2 時に新しいアイデアを探求しているとき、Kiro はより良い構築とより速い学習を支援します。 キャンパスにて Kiro を直接キャンパスにお届けします。Kiro Student Discord コミュニティに参加して、キャンパス訪問、ワークショップ、一部の大学で開催予定のハッカソンの最新情報をチェックしてください。日程と詳細はそちらで最初にお知らせします。 あなたの大学で Kiro とハッカソンを共催しませんか？Discord でお知らせください。ぜひパートナーシップを組みたいと思っています。 始めましょう kiro.dev/students で詳細の確認とサインアップができます。 #KiroStudents であなたが作っているものをシェアしてください。X、 LinkedIn 、 Instagram では @kirodotdev 、Bluesky では @kiro.dev でお待ちしています。 みなさんが何を作るのか、楽しみにしています。

本記事は「 From copilots to coworkers at AAAI: the gap between agentic research and production 」を翻訳したものです。 2026 年 1 月 27 日 AAAI 2026 パネルディスカッション「From Copilots to Co-Workers: What Changes When AI Writes, Reads, and Reasons About Code?」に基づく — シンガポール AAAI 2026 の協調型 AI エージェントに関するワークショップで、Microsoft、Mistral、シンガポール国立大学（NUS）、LinkedIn、Amazon Web Services（AWS）の研究者と実務者がパネルに集まり、コーディングエージェントを本番環境に投入した際に実際に何が起こるかについて意見を交わしました。議論の焦点は「うまくいくかどうか」ではなく（その議論はすでに決着済みです）、「何が壊れるのか、何が予想外なのか、そしてその過程で何を再構築しなければならないのか」でした。 パネリスト ： Shengyu Fu — Microsoft CoreAI、Partner Applied Science Manager。GitHub Copilot 全般にわたるイノベーションを推進する AI for Code 応用研究チームを率い、補完機能からコーディングエージェントまで幅広くイノベーションを推進。 Abhik Roychoudhury — シンガポール国立大学コンピュータサイエンス学部 Provost’s Chair Professor。ACM フェロー、ACM TOSEM 編集長。信頼性とセキュリティを重視したソフトウェアエンジニアリンググループを率い、セマンティックプログラム修復、仕様推論、ファズテスト、AutoCodeRover などの研究に貢献。 Baptiste Rozière — Mistral AI のコード生成チームを率いる。以前は Meta AI に在籍し、Llama に貢献、Code Llama を主導。 Alborz Geramifard — LinkedIn、Distinguished Scientist Omer Tripp — AWS、Principal Applied Scientist 研究と本番環境のギャップ 現在の研究は主に能力の最適化に注力していますが、本番環境では信頼性、コスト、レイテンシー、信頼、そして組織への適合性を同時に最適化する必要があります。 ソフトウェア開発向け AI には、おなじみのパターンがあります。論文がベンチマークで印象的な結果を示す。チームがそれを製品化しようとする。そして本当の仕事が始まります。それはモデルに関する作業ではなく、モデルの周辺にあるすべてのものに関する作業です。どのモデルをいつ呼び出すかを決定するオーケストレーション層、大規模な推論を経済的に維持するコスト設計、開発者が待つか離脱するかを左右するレイテンシー予算、エージェントが実際に役立っているのかそれともそれらしいノイズを生成しているだけなのかを判断する評価フレームワーク、そして誰かがエージェントに実際の仕事を委任するかどうかを決定するトラストサーフェス（説明、監査証跡、中断ポイント）です。 パネリストたちは繰り返し、さまざまな角度から、コーディングエージェントのデプロイにおける課題は、ラボで構築する際の課題とは根本的に異なることを指摘しました。研究は能力を最適化します。本番環境は信頼性、コスト、レイテンシー、信頼、組織への適合性を同時に最適化します。そしてこのギャップは単一の問題ではありません。それぞれが独自の苦労から得た教訓を持つ、いくつかの異なるレベルで現れます。 ギャップが現れる場所 ゼロからの構築：最新の研究を取り入れながら迅速にリリースする 最初の課題はアーキテクチャに関するものです。モデルの能力が限られていた頃、チャットは自然なインタラクションモデルでした。Shengyu Fu（Microsoft）は、VS Code が Copilot にチャット機能を搭載した際、システムが完成したと思い込みがちだったと述べました。プロンプティングがすべてだと感じられたのです。しかし、その幻想はより高性能なモデルの登場とともに崩れます。推論能力とツール使用が向上するにつれ、エージェントはマルチステップのアクションを実行し、自律的にツールを呼び出し、自己検証を行うようになりました。課題はプロンプトエンジニアリングからオーケストレーション、システム設計、評価へと移行しました。これを早期に認識しなかったチームは、後になって手戻りという代償を払うことになりました。 この現代的なエージェントパラダイムでは、アーキテクチャの専門化が有効です。例えば、GitHub Copilot はコード検索などのタスクに専用のサブエージェントを使用し、高価な推論モデルは本当に必要な場面に限定しています。しかし、この専門化には独自の問題が伴います。エージェント間のハンドオフのたびにレイテンシーが増加し、コンテキストが複数のステージを通過するにつれて情報が劣化します。数千万行規模のコードベースでは、コスト削減にはより安価なモデルへの単純な置き換えではなく、システムレベルの設計が必要です。 ユーザーがレイテンシーをどう認識するかも変化しました。2025 年にはスピードが品質の代理指標でした。2026 年までに、ユーザーは複雑なプロンプトに対するより高い自律性とより包括的なソリューションと引き換えに、より長い待ち時間を受け入れるようになりました。基準は「素早く応答する」から「自分がやらなくて済むようにもっと多くを処理する」へと移りました。Abhik Roychoudhury（NUS）は、初期のエージェントチーム（自身のチームを含む）がプログラム解析技術を用いて推論コストの最適化に注力していたと述べました。多くの人を驚かせたのは、組織の準備態勢がコストを上回る制約要因として急速に浮上したことです。3 年前の International Conference of Software Engineering（ICSE）では、多くの企業が LLM を自社のコードに触れさせることは絶対にないと断言していました。しかし、開発者が生産性の向上を実感すると、その姿勢は一変しました。コストよりも意欲が重要であり、適切な足場があれば、より高い品質をより低いコストで実現できると Abhik は付け加えました。 主なポイント：研究は能力を提供しますが、本番環境ではコスト、レイテンシー、品質のバランスを取るアーキテクチャが求められます。そして、そのアーキテクチャこそが実際のエンジニアリングの大部分を占める場所です。 学習と評価：エージェントをより自律的にする ギャップの 2 つ目のレベルは、エージェントが実際に優れているかどうかを知り、時間とともに改善していくことに関するものです。 強化学習は自然な選択だが、アルゴリズムの壁よりもインフラの壁に先にぶつかる。 強化学習は、環境内でアクションを実行するコーディングエージェントの訓練に最適なアプローチであるはずです。しかし実際には、最も困難な問題はエンジニアリングの問題です。Alborz は、エージェントの訓練を完全に強化学習駆動の問題として扱った LinkedIn の経験を述べました。GPU/CPU の利用率がシステム上の課題となりました。ビルドと実行は CPU 負荷が高く、GPU 中心の訓練クラスターとの不均衡が生じます。モデルの並列訓練中にトラジェクトリを収集することで、調整の複雑さが増しました。単純な報酬シグナルは報酬ハッキングを招きました。エージェントは成功したように見せるためにテストを削除することを学習したのです。 さらに、スケーリングを実現するために、LinkedIn は各ポッドをクリーンな状態の仮想マシンとして使用しました。各ステップで完全な git チェックアウトを行う初期設計ではシステムが飽和しました。キャッシュと厳格なアーティファクト管理が不可欠になりました。大規模運用では、約 800 の問題をそれぞれ複数回実行し、オンラインでトラジェクトリを生成しました。Shengyu も Microsoft での同様の経験を述べました。エージェント型強化学習は、長いトラジェクトリと繰り返しのモデル呼び出しにより、補完のための強化学習よりもはるかに困難です。Baptiste も、Mistral で同じパターンが見られたことを確認しました。強化学習環境は事前学習クラスターよりもはるかに多くの CPU を必要とします。 3 つの組織すべてのコンセンサスは次のとおりです。スケーラブルな強化学習環境は、エージェント型 AI に欠けているインフラ層です。現時点では、これはアルゴリズムのフロンティアではなく、エンジニアリング上の制約です。 評価ベンチマークは飽和し、現実から乖離している。 SWE-Bench は 2025 年に評価の主流でしたが、2026 年までに開発者が実際にエージェントを使用する方法と構造的に乖離するようになりました。Alborz は、ベンチマークは通常単一のリポジトリで動作するが、実際の作業は複数のリポジトリにまたがると指摘しました。Abhik は、ほとんどのベンチマークがコードの記述を測定する一方で、コードの読解、意図の理解、影響の分析も同様に重要でありながらほとんど測定されていないと強調しました。Baptiste は、正確性だけではエージェントを差別化できず、指示への追従性と汎化能力が少なくとも同程度に重要だと付け加えました。Omer は、実験室の設定ではなく本番環境の条件に最適化すべきだと主張しました。各企業はプロプライエタリなコードで内部ベンチマークを構築していますが、エージェント評価の共有基準はまだ存在せず、GitHub Copilot のようなデプロイ済みシステムでは、エージェント型ワークロードにはまだクリーンな定量的シグナルがありません。 主なポイント：評価と訓練インフラが 2 つの欠けている層です。ベンチマークは単一リポジトリの正確性を超えて、コード読解、マルチリポジトリワークフロー、指示への追従性を捉える必要があります。スケーラブルな強化学習環境は欠けている訓練層であり、試みたすべてのチームがアルゴリズムの壁ではなく同じエンジニアリングの壁にぶつかっています。 エージェントは単独で動作しない：人間とエージェント間インタラクションの役割 3 つ目のレベルは、エージェントの周辺で何が起こるか、つまり人間がエージェントとどのようにインタラクションし、信頼がどのように構築され、人間の役割がどう変化するかについてです。 レイテンシーと監査可能性が製品を定義する。 Omer は 2 種類のレイテンシーを明確に区別しました。オートコンプリートのレイテンシー（入力中に AI が次の行を提案する際の遅延）は、既存のフローに収まるため、合理的な範囲内であれば許容されます。委任のレイテンシーは根本的に異なります。エージェントにタスク全体を渡し、複数のステップにわたって自律的に作業させる場合、もはやエージェントと並行して入力しているのではなく、ただ待っているだけです。その待ち時間は直ちに監査可能性と結びつきます。ユーザーはエージェントが何をしているのか、行き詰まっていないか、中断できるかを知りたがります。これらの問いが、システムが信頼できると感じられるか不透明に感じられるかを決定します。 品質は正確性だけではない。 Abhik は、あまり注目されていない 2 つの次元で品質を再定義しました。第一に、シグナル対ノイズ比：エージェントは開発者の注意を妨げていないか、それともフィルタリングに労力を要するノイズを生成しているか？10 個の提案のうち 1 つしか有用でないエージェントは、各提案が技術的に正しくても、隠れたコストが発生しています。第二に、説明可能性：エージェントは予想外の判断を正当化できるか？推論が読み取れるものであれば、驚くべき振る舞いも許容されます。この枠組みでは、品質は信頼は切り離せません。 検証は実用的な中間地点に落ち着く。 形式検証はほとんどのシステムにとってまだ手の届かないものです。パネルは実用的な代替案に収束しました。仕様駆動開発（生成されたコードから仕様を抽出し、人間が実装を再確認する必要をなくす）、プロパティベーステスト（モデルはこれらの生成に適しており、実行可能な説明として機能する）、そして AI 支援コードレビュー（AI で AI をガードレールし、人間がビジネスロジックに集中できるようにする）です。 人間の役割は変化しているが、消滅してはいない。 聴衆からの質問が、よくある不安を捉えていました。エージェントがコードの大部分を書くようになったとき、ジュニア開発者はどのように成長すべきか？新たに求められるスキルセットは以下を中心としています。コードの読解とレビュー（書くことよりも重要）、委任（何を自動化し、何に人間の判断が必要かを見極める）、テストと検証（開発者の役割の中心に移行）、そして曖昧さの解消（仕様が不完全な場合に人間が接着剤の役割を果たし続ける）。NUS はすでにこれらの原則に基づいたカリキュラムを構築しています。Alborz の言葉を借りれば、もし自分が学生なら、曖昧さの解消に全力を注ぐだろう、と。そのスキルは抽象化が変わっても価値を持ち続けます。 主なポイント：信頼こそが製品であり、それは監査可能性、シグナル対ノイズの規律、説明可能性によって構築されます。人間の役割は、コードを書くことから、判断し、委任し、エージェントにはできないことを解決することへと移行します。 チームがこれらの課題にどう取り組んでいるかの事例 パネルは純粋に理論的なものではありませんでした。研究と本番環境のギャップを埋めるために、チームがどのように取り組んでいるかについて、いくつかの具体的な事例が紹介されました。 GitHub Copilot のアーキテクチャ専門化。 すべてを 1 つの高価なモデルに通すのではなく、Copilot はコード検索などのタスクに専用のサブエージェントを使用し、強力な推論モデルは複雑な問題に限定しています。これにより、モデルの置き換えではなくシステム設計を通じて、より高い品質をより低いコストで実現しています。 LinkedIn の強化学習インフラ。 大規模な強化学習によるエージェント訓練のために、LinkedIn は各ポッドをクリーンな状態の VM として使用し、積極的なキャッシュとアーティファクト管理を備えた環境を構築しました。各ステップで完全な git チェックアウトを行う初期設計ではスケールできませんでした。最終的なシステムは約 800 の問題でオンラインのトラジェクトリ生成を実行しました。これはアルゴリズムの改善に先立つ、大規模なインフラ投資でした。 Mistral のコンピュートリバランス。 Baptiste のチームは、コードエージェント向けの強化学習環境が事前学習クラスターの設計想定をはるかに超える CPU を必要とすることを発見しました。これをアルゴリズムの問題ではなくインフラの問題として認識したことが、重要な洞察でした。 NUS のカリキュラム再設計。 Abhik のチームは、新しい現実を反映したカリキュラムを構築しています。コード読解をコアスキルとして、エージェントへの委任をコンピテンシーとして、テストを中心に据え、責任ある AI エージェントの使用を必須としています。 ジャッジキャリブレーションのためのペアワイズ比較。 Alborz は、「このコードはあのコードより優れている」というスタイルのデータセット構築を提案しました。作成コストが比較的低く、絶対的な校正が困難な場合でも、ジャッジが信頼性の高い相対ランキングを学習するのに十分です。 AI が AI をレビューする。 Microsoft の Shengyu のチームは、AI 支援コードレビューに取り組む先駆者の一つです。コードレビューエージェントが仕様、要約、意図された動作、テストを使用して一貫性をチェックします。目標は、人間がビジネスロジックに集中し、AI が構造的な検証を担当することです。 現在注目していること：今後の研究の方向性 パネルでは、活発に取り組まれているものの解決にはほど遠い、いくつかのテーマが浮上しました。 スケーラブルな強化学習環境。 これは最も強いコンセンサスポイントでした。エージェント型コーディングに RL を試みたすべてのチームが、同じインフラの壁にぶつかっています。複数のリポジトリ、実際のビルドシステム、現実的な実行環境など、現実世界の多様性を反映した環境を強化学習訓練に必要なスケールで構築することが、欠けている層です。 メタ評価：ジャッジを評価する。 AI ジャッジがコード変更にスコアを付ける場合、そのスコアが信頼できるとどうやって分かるのでしょうか？説明が信頼の次の層として提案されています。システムは信頼性の高いスコアと高品質なコメントの両方を生成し、信頼度の閾値を超えた場合の自動李r−すを実現可能にすべきです。しかし、その信頼性を確立することこそが困難な部分です。 生成されたコードからの仕様抽出。 長期的な目標は、生成されたコードから直接意図を復元し、人間が実装を再確認する必要をなくすことです。これは仕様駆動開発を影響分析（変更がコードベース全体にどのように伝播するかの理解）と結びつけます。 修復ではなく再生成。 コードを安価に再生成できるなら、なぜメンテナンスするのか？これはソフトウェアの寿命、後方互換性、技術的負債についての考え方に深い影響を与える挑戦的なアイデアです。 共有評価基準。 各企業はプロプライエタリなコードで内部ベンチマークを構築していますが、コミュニティにはエージェント型システムを評価するための共有基準がありません。公開ベンチマークは飽和しており、それに代わるものは指示への追従性、汎化能力、コード読解、マルチリポジトリワークフローを捉える必要があります。 カスタマイズ可能なジャッジ。 コードレビューにおいて、組織ごとに重視する点は異なります。重大度、スタイル、順序、見た目の問題など。画一的なジャッジは大規模には機能しません。今後の道筋は、組織のコンテキストに合わせて調整可能なジャッジを必要とします。

はじめに 本ブログは 大豊建設株式会社 様と 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 活用のモデルケースとして大いに参考になります。

はじめに 本ブログは 大豊建設株式会社 様と 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 活用のモデルケースとして大いに参考になります。

本記事は 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 年間の高速開発を始めましょう。 利用規約 もご確認ください。 ハッシュタグ&nbsp; #KiroforStartups または #BuildwithKiro を使って、あなたが作っているものをぜひ共有してください。 X 、 LinkedIn 、 Instagram では @kirodotdev、 Bluesky では @kiro.dev でお待ちしています！ スタートアップ向けのその他のリソース AWS Activate は Amazon Web Services のスタートアップ専用プログラムで、プロモーションクレジット、テクニカルサポート、ビジネスリソースを提供し、構築とスケーリングを支援します。コンピューティングや機械学習からデータベース、セキュリティまで、AWS Activate はスタートアップの成長に必要なインフラとサポートを提供します。 お困りですか？ Kiro コミュニティの Discord に参加して、他のビルダーとつながり、ベストプラクティスを共有し、テクニカルサポートを受け、最新機能の情報を入手しましょう。コミュニティがあなたの成功をサポートします。 翻訳は App Dev Consultant の宇賀神が担当しました。

はじめに 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 /&lt;index-name&gt; { "settings" : { "index.knn": true, "index.knn.memory_optimized_search" : true }, "mappings": { &lt;index-fields&gt; } } 対処1.3： Disk mode (対象：バージョン2.17+) ディスクベースのベクトル検索では、量子化したベクトルのみをメモリに乗せサンプリングを行い、ディスク上の完全な精度のベクトルでリランクを行う手法です。量子化の圧縮率を選択することにより、メモリに載せるベクトルデータのサイズを最大 32 倍低減することができますが、精度の低下は最小限に抑えることが可能です。 検索速度の低下を許容できるワークロードでありつつ、精度の低下をおさえて最大限のメモリ効率を実現したい場合有用な手法です。 以下のように、 knn_vector のフィールドの mode を on_disk に設定することで有効化できます。量子化の圧縮率は compression_level として指定することができ、FAISS エンジンでは 1x 、 2x 、 8x 、 16x 、 32x が選択可能です。 PUT /&lt;index-name&gt; { "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 を使用したベクトル検索では 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：量子化 OpenSearchにおけるベクトルは knn_vector 型の32ビット浮動小数点配列として保存されますが、これらをよりデータ量の小さなベクトルに圧縮するアプローチです。以下の4つの量子化手法をサポートしています。より圧縮度の高い量子化は検索の精度を落とす可能性がありますが、メモリ使用量の削減だけでなく、検索パフォーマンスの向上やディスク使用量の削減にもつながります。精度要件に余裕があり、検索速度を維持もしくは高速化した上でメモリ効率化も行いたい場合有用な手法です。 詳細に関しては こちら のブログも参照ください。 スカラー量子化 (Scaler Quantization) バイナリ量子化 ベクトルの各次元を 1 ビット（-1 または +1）で表現する最も圧縮率の高い量子化手法。最大 32 倍と大幅にメモリ、ストレージ使用量を低減できますが、精度の低下が最も大きくなります。 バイト量子化 各次元を 8 ビット整数（int8）で表現し、元の浮動小数点数を 256 段階に量子化する手法。メモリを約 1/4 に削減しつつ、比較的高い精度を維持できるバランスの良い方式です。 FP16量子化 32 ビット浮動小数点数（FP32）を 16 ビット浮動小数点数（FP16）に変換する手法。メモリを半分に削減し、精度の劣化が少ないため、高精度が求められる用途に適しています。 直積量子化（Product Quantization） ベクトルを複数のサブベクトルに分割し、各サブベクトルを独立にクラスタリングしてコードブックで表現する手法。最大 64 倍と高い圧縮率と高速な検索を両立でき、大規模ベクトル検索でしばしば使用されますが、利用にあたり事前のトレーニングが必要になります。 対処2.3：force merge、warm upの事前実行 FAISS エンジンでは、初回の検索クエリを行う際にベクトルグラフをメモリにロードする必要があり、これに非常に時間がかかる場合があります。事前に Warm-up AP Iを使用してグラフをメモリにロードすることにより初回検索のレイテンシを低減することが可能です。 GET /_plugins/_knn/warmup/&lt;index-name&gt; また OpenSearch において、投入されたデータは最初セグメントと呼ばれる単位で管理されます。このセグメント数が大きくなると検索パフォーマンスの低下につながります。Warm-up 実行の前に Force Merge API を実行することでセグメント数を小さくすることができます。ただし、これらの処理は CPU リソースを多く消費する可能性があるので、データ投入などのリクエストが少ないタイミングで行うべきです。 POST /&lt;index-name&gt;/_forcemerge 対処2.4：refresh_intervalの調整 OpenSearch では、 refresh_interval で指定した時間ごとに、メモリバッファに保持していたデータをセグメント化し検索対象に登録する処理を行っています。Approximate k-NN では、このタイミングでグラフの構築が行われます。 refresh_interval が小さいと、グラフ構築の頻度が上がり CPU リソースを消費する他、セグメント数が多くなることで検索クエリパフォーマンスが低下する可能性があります。データ投入から検索対象になるまでにかかる時間が長くなるデメリットがありますが、 refresh_interval を大きくすることでパフォーマンス改善につながります。 PUT /&lt;index-name&gt;/_settings { "index.refresh_interval": "30s" # デフォルトは1s } 対処2.5：GPUアクセラレーションの活用(対象：HNSW、バージョン3.1+) ベクトルデータ数が非常に大きくなると、データ投入のタイミングで発生するグラフ構築に長い時間がかかり、CPU リソースの消費も大きくなります。ベクトルデータのインデクシングにおける GPU 加速を使用すると、大規模ベクトルデータに対するグラフ構築をマネージドな GPU を使用して高速化しつつ、CPU への負荷をオフロードすることが可能です。もし、検索クエリなどのパフォーマンス低下がベクトルデータのインデクシングによる CPU リソースの枯渇が原因であった場合、この機能の活用により改善する可能性があります。 $ aws opensearch update-domain-config \ --domain-name &lt;domain-name&gt; \ --aiml-options '{"ServerlessVectorAcceleration": {"Enabled": true}}' GPU アクセラレーションを使用するかどうかは index.knn.remote_index_build.enabled からインデックスごとに設定可能です。 PUT &lt;index-name&gt; { "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 /&lt;index-name&gt;/_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 /&lt;index-name&gt;/_search { "_source": { "excludes": ["vector_field"] }, "query": { "knn": { "vector_field": { "vector": [...], "k": 5 } } } } まとめ 本ブログでは、OpenSearch Service において FAISS エンジンを使用したベクトル検索ワークロードを運用している際に発生しうるトラブルとして検索クエリに対するレイテンシーの増加に着目し、その原因究明と対処方法選択の考え方について紹介しました。一般的に OpenSearch を利用した検索のクエリパフォーマンスを改善する場合は、様々な要素が複雑に絡み合う場合があり、特に複数の検索条件、フィルター、集計などを併用している場合にクエリパフォーマンスに影響が出る場合が多いです。一方で今回取り上げたようにベクトル検索単体においてもそのパフォーマンスの改善の余地があり、適切にモニタリングをした上で改善施策を取ることが重要です。 OpenSearch Service の機能は継続的に拡充されているため、新機能を活用するためにもクラスターのバージョンアップグレードを定期的に検討することを推奨します。 著者 黒木 琢央 (Takuo Kuroki) アマゾンウェブサービスジャパン合同会社ソリューションアーキテクト 2024年4月入社。現在toCのITサービス提供企業におけるクラウド全般の技術支援を行いつつ、OpenSearchのコミュニティ活動や機能改善に取り組んでいます。

本記事は 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、データ分析、インフラストラクチャプロビジョニング、セキュリティなど、さまざまなドメインにわたってビジネス価値を提供し、組織が戦略的なクラウド目標を達成できるよう支援しています。

本ブログは 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 にアクセスしてください。 Ayush Singh Ayush は AWS のシニアプロダクトマネージャーで、AWS Security Agent の開発をリードしています。エンタープライズグレード、オープンソース、エージェンティック AI プロダクトのスケーリングに豊富な実績があります。組織がセキュリティプラクティスを効果的にスケールするためのツール構築に注力しています。University of Rochester で MBA を、KIIT University でコンピュータサイエンスの B.Tech を取得しています。 Christopher Rae Christopher は AWS のプリンシパルワールドワイドセキュリティスペシャリスト兼 AI セキュリティ GTM リードです。AI ワークロードの保護、AI を活用したセキュリティ機能、進化する AI 脅威に対するレジリエンスに関する市場参入戦略を策定しています。セキュアバイデザインと多層防御ソリューションの啓蒙を通じて、安全な AI 導入の加速を推進しています。UC San Diego で MBA を、University of Maine で BA を取得しています。余暇にはグルメ旅行、ホッケー、スキー、新しい音楽の発見を楽しんでいます。 <!-- '"` --> 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

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 小林 健太郎 氏 本ブログは、データベーススペシャリストソリューションアーキテクトの藤田 将大とシニアソリューションアーキテクトの半場 光晴が執筆しました。

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 と MongoDB の機能的な違い Amazon DocumentDB への移行ガイド Amazon DocumentDB 移行 Runbook Amazon DocumentDB の便利なツール群 以下のツールは Amazon DocumentDB Tools リポジトリで公開されています。 compat-tool — MongoDB との互換性チェック index-tool — インデックスの分析・最適化 migration — 移行支援ツール sizing-tool — サイジング見積もり monitoring — モニタリング performance — パフォーマンス分析 operations — 運用支援 信田 悟至 氏 山下 剛史 氏 小林 健太郎 氏 AWA 株式会社 信田 悟至 氏 山下 剛史 氏 株式会社サイバーエージェント メディア統括本部 SRE 小林 健太郎 氏 本ブログは、データベーススペシャリストソリューションアーキテクトの藤田 将大とシニアソリューションアーキテクトの半場 光晴が執筆しました。

みなさん、こんにちは。ソリューションアーキテクトの片山です。 近年、医療機関におけるセキュリティ対策の重要性が高まっています。厚生労働省の「医療情報システムの安全管理に関するガイドライン」の改定にも見られるように、電子カルテシステムをはじめとする医療情報システムの安全な運用に向けて、組織的なセキュリティ対策の強化がこれまで以上に求められています。 こうした背景を踏まえ、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)

本記事は 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 の吉村 が担当いたしました。

皆さんの多くと同じく、私も親です。そして、皆さんと同じように、自分の子どもたちのために築いている世界について考えています。これが、私たちの多くにとって 2026 年 3 月 31 日のリリースが重要な理由の 1 つです。同日、 AWS Sustainability コンソール のリリースを発表いたしました。これは、すべての AWS サステナビリティレポートとリソースを 1 か所に統合するスタンドアロンサービスです。 2019年、Amazon は The Climate Pledge (クライメイト・プレッジ) により、2040 年までに事業全体でネットゼロカーボン (温室効果ガス排出量実質ゼロ) を達成するという目標を設定しました。この取り組みが、AWS によるデータセンターとサービスの構築方法を形作っています。さらに、AWS は、お客様が自身のワークロードの環境フットプリントを測定し、削減できるよう支援することにも努めています。AWS Sustainability コンソールは、その方向への最新の 1 歩です。 AWS Sustainability コンソールは、 AWS 請求コンソール 内にある Customer Carbon Footprint Tool (CCFT) に基づいて構築されており、お客様からご要望のあった新しい機能セットを取り入れています。 これまで、二酸化炭素排出量データにアクセスするには請求レベルのアクセス許可が必要でした。その結果、実際的な問題が生じていました。サステナビリティの専門家や報告チームが、コストや請求データにアクセスできない (またアクセスすべきではない) ことがよくあったのです。適切な人が適切なデータにアクセスできるようにするには、持続可能性のワークフローを念頭に置いて設計されていない許可構造とうまく折り合いをつける必要がありました。AWS Sustainability コンソールには、請求コンソールから独立した独自のアクセス許可モデルがあります。サステナビリティの専門家が排出量データに直接アクセスできるようになったため、請求へのアクセス許可の付与も必要ありません。 コンソールには、お客様の AWS の使用状況に起因する スコープ 1、2、3 の排出量 が含まれており、AWS リージョンやサービス ( Amazon CloudFront 、 Amazon Elastic Compute Cloud (Amazon EC2) 、 Amazon Simple Storage Service (Amazon S3) など) 別の内訳が表示されます。基盤となるデータと手法は、今回のリリースで変わっていません。これらは CCFT が使用しているものと同じです。変更したのは、データへのアクセス方法と操作方法です。 サステナビリティ報告の要件がますます複雑になるにつれ、チームには排出量データへのアクセスと操作をより柔軟に行う必要が生じています。これを受け、コンソールに Reports ページを追加しました。このページでは、市場ベースの手法 (MBM) とロケーションベースの手法 (LBM) の両方のデータを対象とする、事前設定済みの月次および年次の炭素排出量レポートをダウンロードできます。含めるフィールド、時間粒度、およびその他のフィルターを選択し、カスタムのカンマ区切り値 (CSV) レポートを作成することも可能です。 組織の会計年度が暦年と一致しない場合は、レポート期間に合わせてコンソールを設定できるようになりました。これを設定すると、すべてのデータビューとエクスポートに会計年度および四半期が反映され、財務チームとサステナビリティチームが並行して作業する際の共通の摩擦点がなくなります。 新しい API または AWS SDK を使用して、排出量データを独自のレポートパイプライン、ダッシュボード、またはコンプライアンスワークフローに統合することもできます。これは、データエクスポートを設定せずに多数のアカウントにおいて特定の月のデータを引き出す必要があるチームや、既存の AWS Organizations 構造と一致しないカスタムアカウントグループを確立する必要がある組織に役立ちます。 リリースされた最新の機能や手法の更新については、 [詳細] タブの「 リリースノート 」ページをご覧ください。 実際の動作を見てみましょう Sustainability コンソールをお見せするために、 AWS マネジメントコンソール を開き、画面上部の検索バーで「サステナビリティ」を検索しました。 [炭素排出量] のセクションでは、二酸化炭素換算量 (MTCO2e) をメートルトン単位で推定できます。これは MBM と LBM で表されたスコープ別の排出量を示しています。画面の右側では、日付範囲を調整したり、サービスやリージョンなどでフィルターしたりできます。 なじみのない方のために説明すると、スコープ 1 には所有または管理されている発生源からの直接排出 (データセンターの燃料使用など) 、スコープ 2 には購入したエネルギーの生産による間接排出 (MBM はエネルギー属性証明書を考慮し、LBM は地域の平均グリッド排出量を使用する)、スコープ 3 にはサーバー製造やデータセンター建設など、バリューチェーン全体にわたるその他の間接排出が含まれます。詳細については、サードパーティーのコンサルタントである Apex が独自に検証 した 当社の手法に関するドキュメント をご覧ください。 API または AWS コマンドラインインターフェイス (AWS CLI) を使用して、プログラムで排出量データを取得することもできます。 aws sustainability get-estimated-carbon-emissions \ --time-period='{"Start":"2025-03-01T00:00:00Z","End":"2026-03-01T23:59:59.999Z"}' { "Results": [ { "TimePeriod": { "Start": "2025-03-01T00:00:00+00:00", "End": "2025-04-01T00:00:00+00:00" }, "DimensionsValues": {}, "ModelVersion": "v3.0.0", "EmissionsValues": { "TOTAL_LBM_CARBON_EMISSIONS": { "Value": 0.7, "Unit": "MTCO2e" }, "TOTAL_MBM_CARBON_EMISSIONS": { "Value": 0.1, "Unit": "MTCO2e" } } }, ... ビジュアルコンソールと新しい API の組み合わせにより、引き続き利用可能な データエクスポート に加えて、データを操作する方法が 2 つ追加されました。コンソールでホットスポットを調べて特定し、ステークホルダーと共有したいレポートを自動化できるようになりました。 Sustainability コンソールは成長するように設計されています。お客様とともにコンソールの機能を拡張し、引き続き新機能をリリースする予定です。 今日から始めよう AWS Sustainability コンソールは、追加費用なしで本日からご利用いただけます。AWS マネジメントコンソールからアクセスしてください。履歴データは 2022 年 1 月まで記録されているため、すぐに排出量の傾向を調べることができます。 今すぐ コンソール の使用を開始しましょう。持続可能性に対する AWS の取り組みについて詳しく知りたい場合は、「 AWS の持続可能性 」ページをご覧ください。 – seb 原文は こちら です。