日本最大の「AWS を学ぶイベント」、 AWS Summit Japan  が 2026年6月25日(木)、26日(金) の2日間にわたり幕張メッセで開催されます。AWS Summit は、クラウドコンピューティングコミュニティが一堂に会して、アマゾン ウェブ サービス (AWS) に関して学習し、ベストプラクティスの共有や情報交換ができる、AWS に興味がある全ての皆様のための無料のイベントです。 今回はその中から データベース関連の注目セッション を、以下の 4 つのテーマに沿ってご紹介します。 AI × データベース ― 生成 AI やエージェントがデータベースの移行・運用をどう変えるか 分散 SQL の最前線 ― Amazon Aurora DSQL のアーキテクチャから実装・検証まで コストとパフォーマンスの最適化 ― 既存環境の見直しとキャッシュ基盤の刷新 データモデリング実践 ― DynamoDB の設計力を引き上げる 今年のデータベースセッションは、この 4 つの潮流を押さえれば全体像が見えてきます。気になるテーマからぜひチェックしてみてください。 1. AI × データベース AI エージェントをデータベースの移行や運用に活用する実践的なセッションです。「移行のコード変換を自動化したい」「運用の検知・対応を AI に任せたい」「エージェントの記憶をどう永続化するか知りたい」という方に。 (DAT302) AI エージェントで切り拓く商用 DB から Amazon Aurora への移行 ―コード変換の実践手法とお客様検証事例 6月25日(木) 13:30–14:10 商用 DB 移行のコード変換、AI エージェントでどこまで自動化できるか？ ― 数千行のストアドプロシージャや動的 SQL の変換は、移行を諦める理由になりがちです。本セッションでは、AWS DMS によるルールベース変換と AI エージェントによる変換を組み合わせた新しいアプローチを解説します。変換ルールやコーディング規約を自然言語で指示し、変換・テスト・突合を自動で繰り返すワークフローにより、従来ツールでは困難だったコードをどこまで自動化できるのか、2 社のお客様検証事例と具体的な数値結果を交えてお伝えします。セッション後すぐに PoC を始められるワークショップやサンプルスクリプトもご案内します。 (DAT358) AI エージェントで実現するデータベース運用：検知・推奨・最適化 6月26日(金) 13:00–13:40 本番障害が起きる前に、AI が問題を見つけて対処法まで提案してくれたら？ ― Amazon RDS、Amazon Aurora、Amazon Redshift を監視・分析する AI エージェントの実装方法を紹介します。パフォーマンスボトルネックの検知からクエリパターンの可視化、最適化戦略の提案まで、AI によるインサイトでデータベースモニタリングを強化する方法を学べます。 (DEV303) AWS サービスを使ったエージェントのメモリ実装パターン 6月25日(木) 12:30–12:50｜シアターセッション AI エージェントの「記憶」をどのデータベースに保存すべきか？ ― 過去の会話履歴をもとに AI がアクションを実施するための重要機能であるメモリについて、AWS のデータベースサービスをメモリストアとして選択する際のポイントを考察します。 2. 分散 SQL の最前線 ついに一般公開された Amazon Aurora DSQL。マルチリージョンでの強い整合性をサーバーレスで実現する分散 SQL データベースを、アーキテクチャ・設計・実プロダクト検証の 3 つの角度から掘り下げます。 (DAT338) Amazon Aurora DSQL Deep Dive ― 内部アーキテクチャの設計思想と実装の勘所 6月26日(金) 12:00–12:40 Aurora DSQL はなぜ軽量な接続と低レイテンシを実現できるのか？ ― OLTP ワークロードに最適化されたサーバーレスの分散 SQL データベースである Aurora DSQL が、トランザクションをどのように処理するかを内部コンポーネントの役割に沿って図解します。特に中核コンポーネントである Query Processor の内部動作を掘り下げ、実装パターンや考慮事項を設計意図とともに整理します。 (AIM252) Kiro でつくる！Amazon Aurora DSQL の特性を活かしたスキーマ設計 6月25日(木) 13:30–13:50｜シアターセッション 分散 SQL のスキーマ設計、何から始めればいい？ ― 「分散 SQL データベースを使ったことがないから設計がわからない…」という方に向けて、Kiro Powers を使ったスキーマ設計支援の方法をデモで紹介します。 (ANT333) 実プロダクトで検証する Amazon Aurora DSQL の可能性と制約 6月26日(金) 14:00–14:20｜シアターセッション 実際のワークロードで Aurora DSQL はどこまで使えるのか？ ― モバイルゲームのシャーディング DB を Aurora DSQL へリフトした場合の性能・コスト・運用性を実プロダクト規模で検証。ベンチマーク結果や制約など実践的な知見を共有します。 3. コストとパフォーマンスの最適化 「今の構成でコストを下げつつパフォーマンスも上げたい」「キャッシュ基盤をモダナイズしたい」という方に。 (DAT318) 実践！Amazon RDS と Amazon Aurora のコスト最適化とパフォーマンス向上 6月25日(木) 14:30–15:10 コスト削減とパフォーマンス向上は両立できる。 ― 架空の企業 AnyCompany が直面する課題を通して、コンピューティング、ストレージ、バックアップの各要素でコストを最適化しながらパフォーマンスを向上させるベストプラクティスを学びます。CloudWatch Database Insights を使ったワークロード特定の手法も実践形式でご説明します。 (DAT456) より速く、より安く、より良く ― Valkey がもたらすキャッシュ基盤の革新 6月26日(金) 16:00–16:40 スループット 230% 向上、メモリ 40% 削減、コスト 33% 削減 ― キャッシュ基盤を一新しませんか？ ― 2024 年に誕生したオープンソースプロジェクト Valkey は、マルチスレッドアーキテクチャや効率型辞書により、キャッシュ技術に革新をもたらしています。Valkey と Amazon ElastiCache が実現する高スケーラビリティ・高可用性の Serverless 構成まで、キャッシュ基盤の未来に迫ります。 4. データモデリング実践 DynamoDB をフル活用するためのデータモデリング手法と、最新機能による設計の変化を学べるセッションです。 (DAT340) Amazon DynamoDB アドバンスドデータモデリング 6月26日(金) 14:00–14:40 「DynamoDB の設計、これで合っているのか？」という不安を解消。 ― DynamoDB の基礎と設計原則を通じて「DynamoDB データモデリングの考え方」を習得し、複雑なユースケースに対応するための実践的な戦略と機能を解説します。 (CNS204) マルチキーサポートで変わる Amazon DynamoDB の GSI 戦略 6月25日(木) 13:00–13:20｜シアターセッション GSI の設計パターンが変わる ― マルチキーサポートで何が可能に？ ― 2025 年に追加されたグローバルセカンダリインデックス (GSI) のマルチキーサポートにより、従来の GSI 設計がどのように変わるかをデモを交えて解説します。 データベース関連ブースのご案内 セッションだけでなく、EXPO 会場内のブースでもデータベースに関する技術デモや個別相談を実施しています。セッションで気になったトピックを、ブースでさらに深掘りできます。 商用データベースを Amazon RDS で最適化 Oracle / SQL Server / Db2 からの移行相談、Oracle Database@AWSに関する最新情報など 生成 AI でデータベース業務を効率化 AI エージェントによるデータベース運用のデモ・技術相談 AWS マネージドデータベース Amazon Aurora、DSQL、DynamoDB の可用性、スケーラビリティに関するデモ・技術相談 Neptune（オントロジーナレッジグラフ for AI エージェント） ナレッジグラフ、オントロジー管理のユースケース AWS Transform によるモダナイゼーション モダナイゼーション全般のご相談 まとめ AWS Summit Japan 2026 のデータベースセッションは、どのテーマも「明日から使える実践知」を重視した内容になっていますので、ぜひ興味のあるセッションに足を運んでみてください。 一部のセッションは既に満席となっております。気になるセッションがあればお早めにご登録ください。 AWS Summit Japan 2026 登録ページ 著者 長久保 武 データベース スペシャリスト ソリューションアーキテクト

みなさん、こんにちは。ソリューションアーキテクトの池田、ポール、佐山です。 2026 年 5 月 18 日〜20 日の 3 日間、AWS 大阪オフィスにて「合同 AI-DLC Unicorn Gym」を開催しました。H2O Retailing、パナソニックコネクト、パナソニックデジタル、村田製作所、東洋紡、ギフトパッド、シャープ、ダイキン工業、近鉄情報システム（順不同、敬称略）の 9 社 10 チームから計 75 名のビジネスメンバー・開発メンバーが参加し、3 日間 AI 駆動の開発プロセスを実践しました。 本記事では、9 社 75 名が 3 日間 AI-DLC をどう体験したのか、参加者の声を交えてレポートします。 AI-DLC (AI-Driven Development Lifecycle) とは AI 駆動開発ライフサイクル (AI-DLC) は、AI を開発プロセスの中心に据えた開発手法です。AI をアシスタントとして後付けで使うのではなく、要件定義・設計・実装の主役を AI が担い、人間は意図のすり合わせと重要な判断に集中する── この役割分担により、従来は数ヶ月かかっていた要件定義から実装までを数日に圧縮します。 プロセスは Inception（要件を練る）・Construction（実装する）・Operations（運用する）の 3 フェーズ。鍵となるのが、チーム全員で 1 つの画面を囲んで AI と対話する「モブエラボレーション」（Inception）と「モブコンストラクション」（Construction）です。AI が要件案やコードを素早く提示し、ビジネス・開発メンバーがその場で検証・判断する。この共同作業が、開発速度の向上だけでなく、ビジネスと開発のギャップを埋め、チーム全員の認識を揃える効果をもたらします。今回の Unicorn Gym では主にこの 2 つを 3 日間で集中実践しました。 詳しくは AI 駆動開発ライフサイクル:ソフトウェアエンジニアリングの再構築 、 11 社合同 AI-DLC Unicorn Gym で体験した開発のパラダイムシフト 、および AI-DLC ホワイトペーパー をご参照ください。 9 社 10 チームが持ち込んだテーマ 各社はビジネスメンバーと開発メンバーの混成チーム（6〜8 名）で、実際のビジネス課題をテーマに持ち込みました。営業支援ツール、現場の点検・検査業務のデジタル化、環境データの集計・可視化、社内インフラの払い出し自動化、グループウェア間のデータ連携など、テーマは多岐にわたります。新規開発だけでなく、既存システムへの機能追加に取り組んだチームもありました。AI を使わない従来の開発手法で見積もると平均して十数人月かかる規模のものです。 「色々取り組んでいるがうまくいかない」「スクラムに限界を感じている」「AI を使わないと間に合わない、AI を積極的に取り入れると決めてメンバーを連れてきた」「開発プロセスが定まらない」── 業界はバラバラでも、開発の壁にぶつかっている点では共通していました。近鉄情報システムでは CTO 自らが参加し、コーディングエージェントを操作して開発に加わるなど、各社の取り組み姿勢もさまざまでした。Spec 駆動開発を実践しているチームもあれば、AI をチームで使うのは初めてというチームもありました。 会場の雰囲気も印象的でした。パナソニックデジタルはオレンジのチーム T シャツを全員で着用して一体感を演出。シャープのメンバーは「服装自由」を活かして着物で参加するなど、普段の業務とは違う特別な 3 日間にしようという空気が会場に満ちていました。 Day 1: Inception ── 同じ画面を囲んで、要件を練り上げる 午前は AI-DLC の概要と Hands-on。午後から「モブエラボレーション」に突入しました。 モブエラボレーションとは、チーム全員が 1 つの画面を囲み、AI と対話しながら要件を練り上げる共同作業です。ビジネスメンバーも開発メンバーも同じ場で AI の提案を検証し、判断し、修正していく。このプロセスを通じてチーム全員のコンテキストが揃い、その共通認識が Construction フェーズにそのまま引き継がれます。 半日で多くのチームがユーザーストーリー作成からモックアップ確認まで到達。 普段、開発とビジネスが面と向かって議論する機会がほとんどない。やってみたら、開発側がビジネスを理解しようとする姿勢が自然に生まれた（H2O Retailing） Day 1 の共有会で印象的だったのは、こんな声です。 何もわかっていない AI に教えながら進めることで、メンバー全員の知識ラインが揃った。結果として良い要件定義になった（東洋紡） AI に説明する行為そのものが、チーム内の認識合わせになっていた。これは狙い通りでもあり、想像以上に効果的でした。 タスクを AI に任せて、判断を人間に回されるプロセスが結構大変。判断力が成果物に直結する（近鉄情報システム） AI に委ねるほど、人間の判断力が試される。この実感は 3 日間を通して繰り返し語られることになります。 自分で体験しないと効果がわからない。人に聞くのではなく自発的に新たな体験をしていきたい（東洋紡） AI-DLC は説明を聞いて理解するものではなく、やってみて初めて腹落ちする── 多くの参加者がそう語っていました。 Day 2: Construction ── コードは出る。でも判断が追いつかない 2 日目は朝からグループワーク。各チームのペースで Inception を仕上げ、Construction フェーズへ入っていきます。 Inception の仕上げとして取り組むのがユニット分割です。ユーザーストーリーを独立して開発できる単位（ユニット）に切り分け、チーム内を 2〜3 のサブチームに分けて並行開発に入る準備をします。 午前の共有会では、Inception フェーズの速さに驚く声が上がりました。 いつもなら 1 ヶ月、2〜3 スプリントかかることが 4 時間でできた。めっちゃしんどかった（パナソニックデジタル） 午後、並行開発が本格化すると「I/F 合意の壁」が見えてきます。 単体テストは通っていたのに、結合したらつながらない箇所があった（シャープ） I/F のつめが甘くて手戻りが発生した（村田製作所） AI がコードを高速に吐き出しても、チーム間の合意が足りなければ結合で引っかかる。開発全体の速度を決めているのはコード生成ではなく、人間の判断と合意形成だ── 複数のチームが同じ気づきに至っていました。 AI がわかったつもりで勝手に再定義してきて時間を食った。レビューをサボると後で痛い（ダイキン工業） AI の出力は必ず人間が検証する、というプロセスの重要性が裏付けられました。 うまくいったパターンとして共有されたのは「最初から大きく扱わず、ミニマルに絞る」「チーム全員で共通認識を作ってから分かれる」の 2 点。 社内で AI を使った開発を検討していたが明確な手順が定まっていなかった。今回の AI-DLC は開発手法としてかなり参考になった。この手法を軸に社内の既製品に対してどうアプローチするか考えていきたい（ダイキン工業） 自社への持ち帰り方が具体的に見え始めたチームもありました。 Day 2 のクロージング時点で、多くのチームがコード生成・ローカル動作確認まで進んでいました。 Day 3: 仕上げと成果発表 最終日は朝から Construction の追い込みです。ユニットの結合、テスト、デプロイ。「動くもの」を 3 日間の集大成として仕上げにかかります。 16 時からは成果発表会。各社が到達した地点を全体に共有しました。 全 10 チームがデモを実施しました。全チームが動くアプリケーションを画面に映して見せるところまで到達しています。 発表を通じて見えたのは、成果の大きさだけではありません。各チームが共通して語ったのは以下のような気づきでした。 Inception フェーズで要件を丁寧に練り上げたチームほど、Construction がスムーズに進んだ ユニット分割の前に、チーム全員で共通のインターフェース定義を固めておくと結合時の手戻りが激減する 既存システムへの機能追加にも AI-DLC は適用できる。AI-DLC Workflow にはリバースエンジニアリングのフェーズが組み込まれており、既存コードの構造を AI に理解させた上で新機能の設計に入る流れがカバーされている AI の出力が速いからこそ、人間のレビューと判断がボトルネックになる。でも、チーム全員で同じものを見ながら判断を重ねるこのプロセスは強い あるチームは「従来 6 ヶ月を見込んでいた開発が 3 日で形になった。特に要件定義のスピードが劇的に変わった」と振り返り、別のチームは「明日の社内ミーティングで、早速プロジェクトに適用したいと提案するつもり」と語っていました。3 日間の体験が、そのまま翌日からのアクションに直結している── 参加者が自社に持ち帰れる手応えを得られたことが何よりの成果です。 AWS セッション・懇親会・Lightning Talks 成果発表の後は AWS の井形（Data&AI 事業開発マネージャー）によるミニセッション「AWS Japan の事業開発マネージャーが生成 AI（Kiro）を使って業務効率化をした話」を実施しました。 AI-DLC が製品ライフサイクルの「作る力」をカバーするのに対し、GTM（Go-To-Market）は「届ける力」をカバーする。Build が速くなるほど、次のボトルネックは「誰に、どう届けるか」に移る。そして AI-DLC の考え方── AI に作業を任せ、人間は方向性と判断に集中する──は、GTM の領域にもそのまま当てはまる、という内容でした。3 日間で動くものを作った参加者にとって、「この先どう活かすか」を考えるきっかけになるセッションでした。 クロージングの後は懇親会 ＋ Lightning Talks。3 日間を共にした 10 チームのメンバーが、業界を越えて AI 駆動開発の実体験を語り合う時間です。この場での会話が、各社の持ち帰りをさらに厚くしたはずです。 3 日間を終えて AI はやっぱり自分の鏡だと思った。AI が理解できていないということは、自分がそこまでの解像度でインプットできていないということ（パナソニックコネクト） アプリ開発は 100% AI-DLC で進めたいと思えた。AI の成果物をレビューするために、私たちの知識を高めることも必要だと感じた（H2O Retailing） 個人で Kiro を触っていた時よりはるかに学びが多く、これは絶対に現場に適用すべきだと確信した（パナソニックデジタル） イベント後のアンケート（61 名回答）では、全体満足度は 5 点満点中 4.57 点。回答者の 96.7% が「満足」または「非常に満足」と評価しました。「AI-DLC はあなたの働き方を変える可能性があるか」という問いには 91.8% が 5 段階中 4 以上で回答。85.2% が継続的なフォローアップを希望しており、3 日間が「終わり」ではなく「始まり」として受け止められていることがわかります。 おわりに AI がコードを書いてくれるようになると、人間の仕事は変わります。手を動かしてコードを書くことから、何を作るか決めること、設計の方向性を判断すること、チーム間の認識を揃えることへ。人間の役割は「作業」から「意思決定」に集中していきます。 AI-DLC がモブで集まることを重視するのはそのためです。ビジネスメンバーと開発メンバーが同じ場に集まり、AI が揃えた材料をもとにその場で判断を重ねていく。意思決定に集中できる環境を作ることで、チーム全体の開発サイクルが速くなる。3 日間で参加者が体感したのは、まさにこの変化でした。 参加いただいた 9 社がこの体験を各社の現場に持ち帰り、それぞれの形で活かしていかれることを楽しみにしています。 参加企業からもレポートが公開されていますので、あわせてご覧ください。 ギフトパッド プレスリリース パナソニックデジタル 参加ブログ（1） パナソニックデジタル 参加ブログ（2） パナソニックデジタル 参加ブログ（3） パナソニックコネクト 参加ブログ 今回の AI-DLC Unicorn Gym は AWS 大阪オフィスで開催しました。前回の東京開催に続き、関西でも各社のチームが集まり、AI-DLC の実践を共にしました。AWS は地域を問わず、お客様の AI による開発プロセスの変革の挑戦に伴走していきます。 著者について 池田 敬之 (Takayuki Ikeda) 関西の製造業のお客様を担当するソリューションアーキテクトです。クラウド × データ × AI でお客様のビジネスを支援しています。好きなサービスは Amazon Bedrock AgentCore と Strands Agentsです。休日はキックボクシングで汗を流した後、愛犬と散歩といったコンボで英気を養うのが定番コースです。 ポール (Paul Nobuo Okada) 製造業のお客様を担当するソリューションアーキテクトです。サーバーレスの活用や AI 駆動開発ライフサイクル (AI-DLC) を日本のお客様への布教する活動もしてます。好きな AWS サービスは AWS サポートです。趣味はDTMとベース、最近ドラムも始めました。ただ、メンバー探しだけが難航しています。 佐山 朝葉 (Sayama Asaha) ソリューションアーキテクト。製造業のお客様をご支援しています。

本記事は 2026 年 05 月 20 日に公開された “ Introducing ExtendDB: An open source DynamoDB-compatible adapter with pluggable storage backends ” を翻訳したものです。 本日、Apache 2.0 ライセンスの下でリリースされた、プラガブルなストレージバックエンドを備えたオープンソースの Amazon DynamoDB 互換アダプターである ExtendDB を発表します。ExtendDB は DynamoDB のワイヤープロトコルを実装し、最初のバックエンドとして PostgreSQL に対応してリリースされます。そのため、DynamoDB で動作するすべての AWS SDK、CLI、ツールは ExtendDB でも変更なしで動作します。 本記事では、ExtendDB の紹介、利用開始の手順、アーキテクチャの説明を行います。これは開発、テスト、実験用途向けの v0.1 リリースです。 背景 Amazon DynamoDB は、あらゆる規模で 1 桁ミリ秒のパフォーマンスを発揮する、サーバーレスでフルマネージドな NoSQL データベースです。DynamoDB 上に構築するチームは、そのデータモデリングパターン、条件式、トランザクション、ストリームについて深い専門知識を培います。それを取り巻く CI パイプラインを構築し、運用ランブックを作成し、エンジニアのトレーニングを行います。これらのチームがエッジ、オンプレミス、切断された環境へと活動範囲を広げるにつれ、同じ API と開発者エクスペリエンスを持ち込みたいというニーズが生まれます。 ある大手航空会社は、ほとんどのアプリケーションを AWS 上で実行し、DynamoDB を主要なデータストアとして利用しています。しかし、ゲートおよび機内システムは、ネットワーク障害が発生しても稼働し続ける必要があり、搭乗、手荷物照合、機内販売についてはクラウドへのラウンドトリップ遅延を許容できません。これらのシステムは、同じアクセスパターン、同じ条件付き書き込み、同じトランザクション保証を必要とします。互換性のあるランタイムがないため、このチームは異なるデータアクセスレイヤー、異なる運用手順、異なる専門知識要件を持つ 2 つの別々のアプリケーションスタックを保守しています。 現在、AWS の外で DynamoDB ワークロードを実行することは、データアクセスレイヤーを書き直すことを意味します。DynamoDB Local はユニットテスト向けの単一プロセスのツールです。ExtendDB は初期段階のプロジェクトとして、より広範なローカル開発およびオンプレミスシナリオを対象としています。 ユースケース ExtendDB はマネージド DynamoDB サービスが利用できない、または現実的でないシナリオに対応します。 ローカル開発とCI/CD クラウドへの依存性ゼロで、ラップトップ上または継続的インテグレーションおよび継続的デリバリー (CI/CD) パイプラインで DynamoDB ワークロードを実行できます。統合テストは数秒で開始でき、決定論的に実行され、クリーンに終了します。 オンプレミスおよびエアギャップ環境 クラウド接続のない開発者、オンプレミスワークロードを実行するチーム、エッジのオペレーターは、自身のインフラストラクチャ上で DynamoDB のアクセスパターンを実行できます。 マルチクラウドおよびハイブリッド インフラストラクチャプロバイダー間でのポータビリティを試しているチームは、PostgreSQL が利用可能なあらゆる場所で DynamoDB API を利用できます。次の図は、ExtendDB から DynamoDB へのマイグレーションがエンドポイント URL の変更だけで済むことを示しています: ExtendDB とは ExtendDB は DynamoDB ワイヤープロトコルの実装で、Rust で書かれており AWS のエンジニアによって開発されています。アプリケーションとストレージバックエンドの間に位置するトランスレーターと考えてください。PostgreSQL リファレンスバックエンドを使用する場合、アプリケーションは DynamoDB プロトコルで通信し、ExtendDB が SQL に変換し、PostgreSQL がストレージを処理します。 ExtendDB はワイヤーレベルで DynamoDB JSON プロトコル を実装します。既存のアプリケーションコード、SDK、ツールは変更なしで接続できます。すべてのデータは PostgreSQL に保存されるため、 pg_dump 、レプリケーション、ポイントインタイムリカバリ、標準的な監視など、すでに知っている運用ツールを利用できます。 ストレージレイヤー は Rust の trait として定義されています。水平スケールに適した Apache Cassandra など、追加のバックエンドをコアを変更することなく実装できます。 ExtendDB は外部ランタイム依存性のない 単一バイナリ にコンパイルされます。 TLS は必須であり、初回実行時に自己署名証明書を自動生成します。ローカル IAM ライクなクレデンシャルストアを備えた SigV4 認証 により、アプリケーションコードは DynamoDB サービスに対して使用するのと同じ署名ロジックを使用します。 サポートされるオペレーション カテゴリ オペレーション テーブル CreateTable、DeleteTable、DescribeTable、ListTables、UpdateTable アイテム PutItem、GetItem、DeleteItem、UpdateItem (条件式付きの SET、REMOVE、ADD、DELETE) Query と Scan キー条件、フィルター式、プロジェクション、ページネーション、セカンダリインデックスの選択 バッチとトランザクション BatchGetItem、BatchWriteItem、TransactGetItems、TransactWriteItems ストリーム ListStreams、DescribeStream、GetShardIterator、GetRecords TTL UpdateTimeToLive、DescribeTimeToLive インポート / エクスポート ImportTable、ExportTableToPointInTime タグ TagResource、UntagResource、ListTagsOfResource アカウントとクレデンシャルの管理は、コマンドラインまたは https://127.0.0.1:8000/console/ の Web 管理コンソールから行えます。 利用開始 ExtendDB は Linux と macOS で動作します。Rust 1.85+ と PostgreSQL 14+ が必要です。 git clone https://github.com/ExtendDB/extenddb.git cd extenddb cargo build --release init コマンドは、稼働中の PostgreSQL インスタンスに接続し、必要なデータベースとスキーマを作成し、管理者用クレデンシャルを生成し、TLS 証明書をプロビジョニングし、設定ファイルを書き出します: ./target/release/extenddb init ./target/release/extenddb serve --config extenddb.toml 次に、DynamoDB アクセス権を持つ IAM ユーザーを作成します。 init コマンドは、 extenddb manage で使用する管理者パスワードとデフォルトのアカウント ID を出力します: ./target/release/extenddb manage --user admin --password '<admin-password>' \ create-user --account-id <account-id> --user-name myuser ./target/release/extenddb manage --user admin --password '<admin-password>' \ put-user-policy --account-id <account-id> --user-name myuser \ --policy-name full-access \ --policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"dynamodb:*","Resource":"*"}]}' ./target/release/extenddb manage --user admin --password '<admin-password>' \ create-access-key --account-id <account-id> --user-name myuser これによりアクセスキー ID とシークレットが返されます。CA バンドルとともにこれらをエクスポートします: export AWS_ACCESS_KEY_ID="AKIA..." export AWS_SECRET_ACCESS_KEY="extenddb..." export AWS_CA_BUNDLE=~/.extenddb/tls/cert.pem ExtendDB は https://127.0.0.1:8000 でリッスンしています。標準的な DynamoDB コマンドを使用します: aws dynamodb create-table \ --table-name Orders \ --attribute-definitions AttributeName=PK,AttributeType=S AttributeName=SK,AttributeType=S \ --key-schema AttributeName=PK,KeyType=HASH AttributeName=SK,KeyType=RANGE \ --billing-mode PAY_PER_REQUEST \ --endpoint-url https://127.0.0.1:8000 \ --region us-east-1 aws dynamodb put-item \ --table-name Orders \ --item '{"PK":{"S":"CUSTOMER#123"},"SK":{"S":"ORDER#2026-001"},"total":{"N":"49.99"}}' \ --endpoint-url https://127.0.0.1:8000 \ --region us-east-1 aws dynamodb query \ --table-name Orders \ --key-condition-expression "PK = :pk" \ --expression-attribute-values '{":pk":{"S":"CUSTOMER#123"}}' \ --endpoint-url https://127.0.0.1:8000 \ --region us-east-1 AWS SDK はエンドポイント URL の設定をサポートしています。エンドポイント URL を変更するだけで、その他はすべて変更不要です。 アーキテクチャ ExtendDB は責務を Rust の crate に分離しています。 core crate は、純粋な同期 Rust として型、検証、式の評価を処理します。 engine crate は DynamoDB API のセマンティクスを実装します。 storage-postgres crate は PostgreSQL バックエンドであり、任意のバックエンドが実装すべきインターフェースを定義する storage trait に対して構築されています。 server crate は HTTP サーバー、管理 API、Web コンソールを提供し、これらを統合します。 次のアーキテクチャ図は、ExtendDB の高レベルの概要を示しています: 制限事項 ExtendDB は DynamoDB ではありません。これは互換性のある実装であり、マネージドサービスの代替ではありません。パフォーマンス特性、スケーリング動作、運用上の特性は異なります。マネージドサービスの保証が必要な場合は DynamoDB を使用してください。 データベースが必要であり、その可用性、バックアップ、メンテナンスはユーザーの責任です。TLS は必須です。ExtendDB は SigV4 署名検証とポリシー評価を備えた独自の IAM ライクな実装を含みます。これはスタンドアロンのシステムです。ExtendDB で作成されたクレデンシャルとポリシーは AWS IAM とは完全に分離されており、両者の間で共有することはできません。グローバルテーブルとクロスリージョンレプリケーションは、これらが DynamoDB 固有のマネージド機能であるため実装されていません。 参加するには 本記事では、PostgreSQL をバックエンドとするオープンソースの DynamoDB 互換アダプターである ExtendDB を紹介しました。ローカル開発、CI/CD テスト、オンプレミスデプロイメント、エアギャップ環境のいずれであっても、AWS の外で DynamoDB アクセスパターンを必要とするワークロードがある場合、ExtendDB は既存のアプリケーションコードと SDK で動作する互換性のある実装を提供します。 ExtendDB は初期段階にあり、私たちはオープンに開発を進めています。 GitHub リポジトリ をクローンし、 Getting Started ガイド に従って、数分で DynamoDB 互換エンドポイントをローカルで実行できます。コントリビュート方法の詳細については、 Contribution Guide を参照してください。ギャップを発見した場合や、ストレージバックエンドをコントリビュートしたい場合は、issue を起票するか、プルリクエストを送信してください。 著者について Lee Hannigan Lee はアイルランドのドニゴールを拠点とするシニア Amazon DynamoDB データベースエンジニアです。彼はビッグデータと分析技術の強固な基盤の上に、分散システムにおける豊富な専門知識を持っています。彼の役割では、DynamoDB のパフォーマンス、スケーラビリティ、信頼性の向上に注力し、お客様や社内チームがその機能を最大限に活用できるよう支援しています。 Deepthi Mohan Deepthi は DynamoDB チームのプリンシパルプロダクトマネージャーです。

大学生向けのプログラミング学習コミュニティ「POSSE」では、実践的な開発スキルやチームワークの向上を目指して、独自のカリキュラムを提供しています。 その中でもチーム開発は、個人の学習では得られない「チームでものをつくる力」を試される実践プログラムとなっており、約2 カ月間、企業から提示されたリアルな課題のもとで、プロダクト開発に取り組み、その成果を発表します。 2年生・3年生にとって学びの集大成となる取り組みで、要件定義から設計・開発・発表までを一貫して経験します。上級生となる4年生は後輩たちの取り組みに対して相談に乗り、サポートしています。 この記事では、2026年4月12日に開催された決勝戦の模様をお届けします。 POSSEとは 「POSSE」は、株式会社アンチパターンが運営する大学生向けプログラミング学習コミュニティです。関東圏の大学生約 180 名が所属し、学生同士が教え合うコミュニティ形式で学んでいます。 独自カリキュラムによる学習に加え、ハッカソンやチーム開発といった実践的な開発機会を通じて、技術力とチームワークの両方を磨いています。AWS もこの活動を支援しています。 【参考記事】 大学の 4 年間で、即戦力レベルのデジタル人材に。AWS も支援する”人が育つ”コミュニティ「POSSE」 要件定義・開発・チームワーク──学生たちの挑戦が実を結ぶ！ 大学生向けプログラミング学習コミュニティ「POSSE」決勝レポート 開会式 今年もPOSSEチーム開発決勝戦の日がやってきました。2026年4月12日、目黒セントラルスクエアにはPOSSE関係者、新入生候補者、企業審査員など約100名を超える来場者が集まり、昨年を上回る規模での開催となりました。 運営メンバーによる開会の挨拶で幕を開けると、会場は一気に熱を帯びました。今年はPOSSE入会予定の新入生も発表を見に来ており、コミュニティとしての成長を感じさせるイベントとなりました。 会場には、POSSEを卒業された社会人メンバーの姿もあり、後輩たちの発表を見届けようという温かいまなざしが印象的でした。かつて同じ舞台に立った先輩たちが、今度は見守る側として後輩を支えている。そんな光景に、POSSEが大切にしてきたつながりを感じました。 チーム開発発表 運営メンバーによる概要紹介が始まりました。チーム開発概要の説明に先立ち、POSSEというコミュニティが何を目指し、チーム開発がその中でどのような役割を果たしているのかが語られました。POSSEが見据える未来と、そこに向かうためにチーム開発が果たす役割について語られる場面があり、これから始まる発表の意義を改めて感じさせる導入となりました。 チーム開発は、2年生が挑む「初級プログラム」と3年生が挑む「中級プログラム」の 2 部門で構成されています。今年のチーム開発には初級 16 チーム、中級 6 チーム、合わせて 22 チームがエントリーしました。約 8 週間にわたり、テーマ提供企業へのヒアリングを起点に要件定義や設計、開発、そして発表までをチームで走り抜けるプログラムとなっていました。前日（2026年4月11日）の予選で全チームが成果を披露し、審査を経て初級 4 チーム・中級 4 チームが決勝へ駒を進めました。 チーム開発の序盤は、要件定義期間からスタートします。テーマ提供企業へのヒアリングをもとに、誰のどんな課題を解決するのか、本当に必要な機能は何かをチーム内で徹底的に議論します。方向性が固まってから設計・実装に入り、途中のヒアリングで得たフィードバックをもとに軌道修正を重ねながら、動くプロダクトとして仕上げていきます。 今回の初級プログラムのテーマは、主催の株式会社アンチパターン代表・小笹氏が独自に設計した「企業向けオフィス利用可視化ソフトウェア」。ハイブリッドワークが当たり前になった今、自社のオフィスは適正な広さなのかという経営課題に対して、データで意思決定を支援するプロダクトの開発に学生たちは挑みました。開発期間中には計 2 回の要件ヒアリングが設けられ、単に動くものをつくるだけでなく、なぜそれが必要なのかを問い続ける姿勢が求められました。 中級プログラムのテーマは、株式会社リンクアンドモチベーションが提供した「チームの生産性とモチベーションを高めるプロダクト」。 プロジェクトの停滞やメンバーのコンディション低下といった、組織マネジメントの現場で実際に起きている課題に正面から向き合いました。開発期間を通じて計 4 回の要件ヒアリングが行われ、プロダクトの実現可能性や提供価値について踏み込んだ対話を重ねました。 閉会式（結果発表） 全チームの発表が終わり、会場に緊張感が漂うなか、結果発表の時間を迎えました。 「OOPARTS」チーム 初級最優秀賞に輝いたのは「OOPARTS」チームでした。ハイブリッドワーク時代のオフィス最適化をテーマに、オフィス利用データの可視化と分析で経営判断をサポートするプロダクトを提案しました。受賞を受けてメンバーは、家族や友人をはじめ多くの人の支えに感謝を伝えた上で、「最後まで走り切れたのは自分たちだけの力ではない。この経験を通じて大きく成長できたと実感しています」と笑顔で振り返りました。 「marni」チーム 中級最優秀賞に選ばれたのは「marni」チームでした。チームの生産性やメンバーのモチベーションを見える化し、マネージャーが役割の再設計やメンバー間の相互理解を促しながらチーム力を底上げできるプロダクトを提案しました。 受賞を受けてメンバーは「チームのメンバーや周囲の方々に感謝したい」と穏やかに語りました。しかし、その言葉の裏には、昨年の予選で敗退し、悔しさを日記に書き殴った経験を持つメンバーもいました。「あの日があったから、今ここに立てている。諦めなければ来年は決勝に立てる」と、最後に後輩たちへ向けて力強いメッセージを送りました。 講評では、審査員・ゲストそれぞれの立場から温かいメッセージが贈られました。審査基準については「お客様に自信を持って提案できるかどうかで選んだ」と明かされ、ビジネスの現場に直結する視点で評価が行われたことが窺えます。また、「学びが大きいのは、むしろ負けたチームではないか。この経験を記録し、振り返ることで必ず次に活きる」と、結果に関わらず全チームの挑戦に敬意を表する言葉が印象的でした。加えて、「プレゼンテーションの水準が高く、実務の場でも通用するレベルにある」といった評価も寄せられ、学生たちの取り組みに対する期待の大きさが伝わる講評となりました。 AWS 相澤恵奏氏 POSSEの活動を支援する AWS からは、相澤恵奏氏が総評を行いました。「努力は熱中に勝てない」という言葉とともに、悔しさを感じられること自体が熱中の証であると述べ、その情熱を今後も大切にしてほしいとメッセージを贈りました。 基調講演 衆議院議員 平井卓也氏 イベント終盤には、初代デジタル大臣を務めた衆議院議員 平井卓也氏が基調講演に登壇しました。 講演では、インターネットの普及からクラウドコンピューティングの台頭、そして AI の急速な進展に至るまでの技術変遷を概観した上で、AI 時代に求められる姿勢について語られました。平井氏は、AI が既存の業務を担う時代において人間に求められるのは、責任ある意思決定と感性に基づく価値創造であると述べました。 学生たちに対しては、テクノロジーの主導権を自らの手に持ち続けること、すなわち道具としての AI を主体的に活用しながら、自分自身の価値を磨いていく姿勢が重要であると語りかけました。また、変化の激しい時代だからこそ、その変化を楽しんでほしいと前向きなメッセージを贈りました。 さらに、当日の学生たちの発表についても言及し、技術力だけでなく課題解決のアプローチやプレゼンテーションの質を高く評価されました。POSSE の活動については、ともに学び合う中で生まれる深いつながりに価値があると述べ、温かい言葉で講演を締めくくりました。 最後に 今年の決勝戦を振り返ると、印象に残るのは結果そのものよりも、各チームの発表から伝わってくる 8 週間の密度でした。プレゼンテーションの完成度や質疑応答での受け答え、そしてチームワークを語る時の実感のこもった言葉、どれも 8 週間を全力で走り抜けてきたチームにしか出せないものだと感じました。 POSSEで過ごした時間は、社会に出てからもふとした瞬間に立ち返る原点になると思います。あの時チームで悩み抜いた経験、本音でぶつかり合った記憶、そして最後にやり切った達成感、それらは年月が経つほど、自分を支える土台になっていくはずです。 今回の決勝に立った学生たちも、惜しくも届かなかった学生たちも、この 8 週間で得たものをぜひ大切にしてほしいと思います。学生たちのこれからに、大いに期待しています！ 【関連リンク】 大学生向けプログラミング学習コミュニティ「POSSE」 公式サイト 株式会社アンチパターン コーポレートサイト 著者情報 影嶋亮太朗（Kageshima Ryotaro） AWS Cloud Support Engineerとして、AWSサービスを活用したアーキテクチャ設計のお問い合わせや障害対応などに日々取り組んでおり、お客様の技術的課題解決に努めております。スタートアップの支援や次世代デジタル人材の育成とAI領域に興味があり、活動しております。 森 瞭輔（Mori Ryosuke） ソリューションアーキテクトとして幅広いお客様の AWS 導入支援を担当しています。好きな AWS サービスは Amazon Connect で、業界問わずコンタクトセンター関連の技術支援も行っています。先日念願だったフルマラソン完走を達成することができました。

本ブログは 2026 年 4 月 8 日に公開された Amazon Science Blog “ How Amazon uses agentic AI for vulnerability detection at global scale ” を翻訳したものです。 Amazon の RuleForge システムは、エージェンティック AI を活用して、従来の手法より 336% 速く本番環境向けの検出ルールを生成します。 2025 年、NVD (米国国立脆弱性データベース) には 48,000 件を超える新しい CVE (共通脆弱性識別子) が公開されました。これは、自動化ツールや AI を活用したツールが脆弱性発見に与える影響を反映しています。しかし、セキュリティチームにとっては、新しい脆弱性を把握するだけでは十分ではありません。各開示情報を、大規模で複雑なシステムを保護するのに十分な速度で、堅牢な検出ロジックに変換する必要があります。 そこで AWS が構築したのが RuleForge です。RuleForge は、脆弱性を悪用するコードのサンプルから直接検出ルールを生成するエージェンティック AI システムです。本番セキュリティシステムに求められる精度を維持しつつ、お客様のセキュリティを強化しながら、手動でのルール作成と比較して 336% 速く検出ルールを生成しています。 CVE リポジトリ、ルール生成、検証、フィードバック統合のコンポーネントを示す RuleForge のアーキテクチャ。 開示から防御までのギャップの解消 Amazon では、検出ルールは JSON で記述され、MadPot へのリクエストなどのデータに適用されます。MadPot は、デジタルおとりを使って悪意のあるハッカーの動作を捕捉する世界規模の「ハニーポット」システムです。また、社内の検出システムである Sonaris が検知した、エクスプロイトの試行と思われるものにも適用されます。NVD で公開される高深刻度の脆弱性の数は今後も増加し続けると予想されるため、大規模なセキュリティ運用には AI を活用した自動化が不可欠です。 ルール生成を自動化することで、私たちはそのギャップを埋めながら、対応範囲を拡大しています。チームは現在、従来の手法では不可能だったペースと規模で、高深刻度の CVE を検証済みの検出ルールに変換できるようになり、お客様により包括的な保護を提供しています。 手動の検出ルールワークフロー RuleForge 登場以前、新しい CVE に対する検出ルールの作成は、アナリスト主導の複数ステップから成るプロセスでした。 ダウンロードと分析: セキュリティアナリストは、公開されている概念実証 (PoC) エクスプロイトコード (脆弱性を悪用する方法を示すコード) を見つけ出し、それを調査して攻撃メカニズム、入力、想定される動作を把握 検出ロジックの作成: アナリストは脆弱性を狙う悪意のあるトラフィックを捕捉するルールを作成し、トラフィックログに対するルールの精度を測定するクエリを記述 検証とイテレーション: アナリストはこれらのクエリを実行し、結果を確認し、誤検知 (False Positive) を減らすためにルールを調整するという作業を、ルールが本番環境で十分に機能するまで繰り返し ピアレビューとデプロイ: 最後にアナリストは、デプロイ前に別のセキュリティエンジニアによるコードレビューを受けるためにルールを提出 このワークフローは高品質なルールを生み出す一方で、時間がかかるため、チームはどの脆弱性を最初にカバーするかを慎重に優先順位付けする必要がありました。 エージェンティック AI パイプラインとしてのルール作成の再構築 RuleForge は、このワークフローをエージェンティック AI システムとして再構想したものです。検出ルールの生成、評価、改良を協調して行う特化型 AI エージェント群で構成されており、最終承認には引き続き人間が関与します。単一のモデルでエンドツーエンドに問題を解決しようとするのではなく、RuleForge はタスクを人間の専門家の働き方を模した段階に分解します。 自動取り込みと優先順位付け: RuleForge は、特定の脆弱性を狙う方法を示す公開済みの PoC エクスプロイトコードをダウンロードします。コンテンツ分析と脅威インテリジェンスソースを使用して各エクスプロイトをスコアリングします。これにより、ルール生成が最も重要な脅威に集中することが保証されます 並列ルール生成: 優先順位付けされた各 CVE について、AWS Fargate 上で Amazon Bedrock を使用して動作するルール生成エージェント (generation agent) が、複数の検出ルール候補を並列に提案します。各候補は、後段のステージからのフィードバックに基づいて複数のイテレーションで改良できるため、システムは最も有望なものを選択する前に、さまざまな検出戦略を検討できます。一人の専門家がルールを 1 つずつ作成するのに頼るのではなく、RuleForge は検出エンジニアリングを、AI が選択肢を提案し人間がデプロイの可否を決定するパイプラインとして扱います AI を活用した評価: 個別のルール評価エージェント (evaluation agent) が各候補をレビューします。これは RuleForge の重要な革新の 1 つです。生成モデル (generation model) が自身の作品を判断するのではなく、RuleForge は専用の「ジャッジ」モデル (judge model) を使用して、人間の専門家が検出ルールを評価する際に用いる 2 つの次元で各ルールをスコアリングします。 感度 (sensitivity): このルールが CVE で説明されている悪意のあるリクエストを検知できない確率はどのくらいか? 特異度 (specificity): このルールが脆弱性そのものではなく、脆弱性と相関する特徴を狙っている確率はどのくらいか? 多段階検証: ジャッジを通過したルールは、段階的に厳格になるテストパイプラインを通過します。合成テストでは、悪意のあるテストケースと無害なテストケースの両方を生成し、基本的な検出精度を検証します。次に、ルールは MadPot などのトラフィックログに対して検証され、期待どおりに動作することを確認します。いずれかの段階で失敗したルールは、理由を説明する具体的なフィードバックとともにルール生成エージェントに送り返され、改善のクローズドループを形成します 人間によるレビューとデプロイ: 最高のパフォーマンスを発揮するルールは、以前と同様にコードレビューに進みます。セキュリティエンジニアがレビューを行い、フィードバックは修正のためにルール生成エージェントに戻されます。本番デプロイ前の最終ゲートには、引き続き人間の判断が残ります RuleForge の 5 × 5 生成戦略を表した図。5 つの並列検出ルール候補、それらの信頼度スコア、および反復的な改良を示しています。システムは複数の候補を同時に生成し、検証結果に基づいて最高のパフォーマンスを発揮するものを選択します。 個別のジャッジモデルが重要な理由 ルール生成モデルに対して自身の検出ルール候補への信頼度を報告するよう求めたところ、生成したほぼすべてのものを良いと判断しました。これは、セキュリティトピックにおける LLM のキャリブレーションが不十分であることを示す研究結果と一致しています。 その解決策は、生成と評価を分離することでした。専用のジャッジモデルを使用することで、真陽性 (True Positive) の検出数を維持しながら、誤検知を 67% 削減できました。 ジャッジを効果的にしたのは、主に 2 つの設計選択です。 否定的な表現が精度を向上させる: 「ルールが悪意のあるリクエストを検知できない確率はどのくらいか?」と尋ねた方が、「ルールがすべての悪意のあるリクエストを正しく検知する確率はどのくらいか?」と尋ねるよりも、より良いキャリブレーションが得られます。LLM は肯定に傾く傾向があるため、評価を問題探しとして組み立てることで、より誠実な評価が得られます ドメイン固有のプロンプトは汎用的なものより優れている: 単にモデルにルールへの全体的な信頼度を評価するように依頼するだけでは、キャリブレーションが不十分になりました。うまくいった質問は、セキュリティエンジニアが実際に注目する観点を組み込んだものでした。たとえば、ルールが相関する表面的な特徴ではなく脆弱性メカニズム自体を狙っているか、ルールがエクスプロイトのバリエーションの全範囲をカバーしているかといった観点です システムは、スコアを説明する推論チェーンも生成します。私たちはこれらの推論チェーンを人間の評価と照らし合わせて評価し、9 つのルールのうち 6 つで AI ジャッジの推論が人間の専門家の推論と一致することを確認しました。たとえば、人間の評価者が「あの SQL インジェクションの正規表現はゆるすぎる」と指摘した際、ジャッジは独立して「正規表現パターンはシングルクォートを含むあらゆるクエリパラメータを捕捉するため、特定の脆弱性だけよりも範囲が広い」と判断していました。 結果と今後の展望 私たちは 2025 年 8 月に信頼度スコアリングシステムをデプロイし、アナリストが新しい検出ルールをデプロイする速度を加速させました。その年の最後の 4 か月間で、RuleForge により、本番セキュリティシステムに必要な高い精度を維持しながら、手動より 336% 速くルールを生成および検証できるようになりました。アナリストの焦点を作成からレビューに移すことで、品質を損なうことなく全体的なスループットを大幅に向上させました。脆弱性開示と防御の間のギャップをこれまで以上に効果的に埋めることで、AWS 上のお客様のワークロードを守るマネージド保護がより速く更新され、より多くの高深刻度の CVE をカバーできるようになっています。 RuleForge は、エージェンティック AI が精度要件を満たしながら、本番規模で人間のセキュリティ専門知識を強化できることを実証しています。重要な革新はアーキテクチャ的なものです。ルール生成とルール評価の分離、単一のモデルではなく複数の特化型 AI エージェントの使用、そして最終承認のためのヒューマンインザループの維持です。脆弱性開示の頻度が加速し続ける中、これらの設計原則は、防御を最新の状態に保つのに役立ちます。 評価方法論や実験結果を含む RuleForge の技術的詳細について詳しくは、 私たちが arXiv で公開している論文 を参照してください。 著者について C. J. Moses C. J. Moses は Amazon の chief information security officer 兼 vice president of security engineering です。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

中国 (国番号 +86) へのコンプライアンスに準拠した発信を維持することは、通信規制が進化し続ける中、グローバル企業にとって大きな課題です。 Amazon Connect Customer を使用して中国へ顧客コミュニケーションを行っている場合、コンプライアンスのベストプラクティスを理解し実装することで、サービスの中断を回避し、顧客との関係を保護できます。 あるグローバル旅行サービス企業は、承認済みの電話番号の設定とレート制限の実装によって、Amazon Connect Customer による中国への発信を中断なく維持しています。規制要件が変更された際も、収益と顧客関係の継続を守ることができました。この事例は、適切なツールとアプローチを用いれば、複雑な規制環境でも安心してビジネスを運営できることを示しています。 本記事では、中国へのコンプライアンスに準拠した発信に関する 5 つの重要なベストプラクティスを説明します。承認済み番号の組み合わせの設定、禁止番号タイプの排除、レート制限の実装、発信者 ID の設定、番号検証の実装です。これらのプラクティスに従うことで、通信要件を満たしながら中国の顧客への安定した通話の接続性を維持できます。 中国の通信規制環境 中国の通信キャリアは、国際通話に対して特定の基準を適用しています。正常に運用するには、以下の機能が必要です。要件と適格基準の完全なリストについては、Amazon Connect Customer 管理者ガイドの アウトバウンド発信の制限 を参照してください。 コールバック機能を備えた 直通ダイヤル (DID) 番号 パラメータ設定によるレート制限 発信前の番号検証 コンプライアンスに準拠した発信者識別情報 アウトバウンド発信での承認された番号タイプの利用(フリーダイヤル番号 (TFN) および国際フリーダイヤル番号 (UIFN) を除く) Amazon Connect Customer と AWS のモニタリングおよび検証サービスを組み合わせることで、通話量に関係なく中国への安定した接続を維持しながら、これらの要件を満たすことができます。 コンプライアンス要件の理解 中国のキャリアは、ネットワークの品質とセキュリティを維持するために通信基準を一貫して適用しています。準拠した設定をしない場合、以下の問題が発生するリスクがあり、それぞれの対処が有効です。 顧客コミュニケーションに影響するサービスの中断(例 : 通話切断のリスク) レート制限 [ベストプラクティス 3] によって、承認されたしきい値内に収めることができます 中国への発信機能の利用制限(例 : 中国への発信機能が使えなくなるリスク) 承認済み番号の設定 [ベストプラクティス 1] と禁止された番号タイプの排除 [ベストプラクティス 2] でリスクを軽減できます カスタマーサポートおよび営業チームの運用上の課題(例 : 運用ミスによる非準拠の通話や設定をするリスク) 番号検証 [ベストプラクティス 5] によって、発信前に失敗を防止できます 事業継続性と顧客関係への影響(例 : 発信者 ID が表示されず受信者からの信頼を失うリスク) 発信者 ID の設定 [ベストプラクティス 4] によって、受信者からの信頼を構築できます 本記事の各ベストプラクティスを活用することで、これらのリスクに直接対処できます。たとえば、レート制限によってキャリアに承認されたしきい値内に収めることで、サービス中断のリスクを軽減できます。承認済み番号の設定により、スパムフラグや受信者への課金につながる発信機能の制限を回避できます。 AWS は、規制要件をすぐに満たすためのツールを提供しています。これらのサービスのモニタリングおよび検証機能はプロアクティブな管理をサポートし、発信オペレーションの安定性と信頼性の維持に役立ちます。一方で、これらのツールの使用が適用される通信規制に準拠しているかどうかはお客様の責任で確認が必要です。 成功のための重要なポイント Amazon Connect Customer を使用した中国向け発信をコンプライアンスに準拠して行うには、以下の 5 つのベストプラクティスが不可欠です。最初の 2 つ (承認済み番号の設定と禁止された番号タイプの排除) から始めることを推奨します。残りのステップは、規制に準拠した番号が設定されていることを前提としています。 1. 承認済み番号の設定 達成基準: アウトバウンド発信の 100% が承認済みの DID 番号を使用していること。 番号を中国向けの発信に利用する承認を得るためには、以下の手順に従います。 承認のリクエスト: 正確な電話番号リストを添えて AWS サポート にリクエストを送信します。 サービスの 直通ダイヤル (DID) 番号を使用します。 香港、マカオ、台湾の番号は使用できません。注: この国リストは変更される可能性があります。最新情報は Amazon Connect Customer の ドキュメント を確認してください。 1 つのインスタンスでキャリアが発信機能を停止した場合の影響を軽減するため、複数の Amazon Connect Customer インスタンスに番号を分散させることを検討してください。 コールバック機能の設定 各 DID 番号がインバウンドコールを受信できることを確認します。会社名を明確に伝えるメッセージを再生するインバウンドコンタクトフローを設定します。 コンタクトフロー、キュー、ルーティングポリシーなどの設定変更後にコールバック機能をテストします。 ユースケースの説明を提出 詳細なユースケースの説明を提出します。 Amazon Connect Customer 管理者ガイドの サポートされるユースケース に対して適格性を確認します。 2. 禁止された番号タイプの排除 達成基準: 中国への発信で TFN/UIFN 番号を使用していないこと。 中国のキャリアは、中国へのアウトバウンド発信で以下の 2 つの番号タイプの利用を禁止しています。 フリーダイヤル番号 (TFN): ダウンストリームプロバイダーでスパムフラグが立てられ、レピュテーションスコアの低下や予期しない受信者への課金が発生する可能性があります。詳細については、Amazon Connect Customer 管理者ガイドの アウトバウンド発信の制限 – フリーダイヤル番号 を参照してください。 国際フリーダイヤル番号 (UIFN): 中国のキャリアは、中国へのアウトバウンド使用で UIFN 番号をブロックします。詳細については、Amazon Connect Customer 管理者ガイドの アウトバウンド発信の制限 – UIFN 番号 を参照してください。 対処するため、現在の番号インベントリを監査し、禁止番号を承認済みの DID 番号に置き換えます。 3. レート制限の実装 達成基準: 通話レートが アウトバウンド発信の制限 – 中国のドキュメント に記載された規制上の制限内に収まっていること (たとえば、本記事執筆時点では同一の発信者 ID で 1 分あたり 5 通話以下)。 発信方法に応じて 2 つの実装オプションがあります。 直接アウトバウンド発信の場合: GitHub の AWS Samples にある Amazon Connect Customer Outbound Rate Limiting サンプルなどのレート制限ソリューションを実装します。規制要件に従ってレート制限を設定します。 Amazon Connect Customer のクイック接続設定の場合: クイック接続を使用した中国へのアウトバウンド発信では: Amazon Connect Customer インスタンスで、「キュークイック接続」タイプのコンタクトフローのみを使用します。電話番号クイック接続とユーザークイック接続はサポートされていません。 「キューへの転送フロー」タイプのコンタクトフローを作成します。 新しいコンタクトフローを作成し、コンプライアンスに準拠した中国へのアウトバウンド発信のために「キューへの転送フロー」タイプを選択します。 「電話番号への転送」ブロックを使用してコンタクトフローを設計し、 E.164 形式 (国際電話番号形式) で番号を指定します (例: +86XXXXXXXXXX)。 「電話番号への転送」ブロックを使用し、宛先番号を E.164 形式 (例: +86XXXXXXXXXX) で指定してコンタクトフローを設計します。 前のステップで設定したコンタクトフローに対して、キューとフローを指定してクイック接続を設定します。 キュータイプを指定し、前のステップで作成したキューとコンタクトフローを設定してクイック接続を構成します。 モニタリング: レート制限違反に対するオブザーバビリティとリアルタイムアラートを設定します。たとえば、Amazon Connect Customer と Amazon CloudWatch を使用した以下のアプローチがあります。 Amazon Connect Customer のコンタクトフローログ を有効にします。 CloudWatch ログメトリクスフィルター を作成して通話レートメトリクスを追跡します。 通話が制限に近づいた場合や超過した場合にトリガーされる CloudWatch アラーム を作成します。 リアルタイム可視性のために CloudWatch ダッシュボード を設定します。 通話が制限を超過した際にリアルタイムアラートを受信するために Amazon Simple Notification Service ( Amazon SNS ) 通知を設定します。 4. 発信者 ID の設定 達成基準: アウトバウンド発信の 100% が準拠した発信者識別情報を表示していること。 ステップバイステップの手順については、Amazon Connect Customer 管理者ガイドの アウトバウンド発信者 ID の設定 ドキュメントに従ってください。 5. 番号検証の実装 達成基準: 番号の正確性を検証し、発信の失敗を防止すること。 通話検証には 2 つのアプローチがあります。 初期検証には AWS End User Messaging Phone Number Validate API を使用します。結果はリアルタイムの番号ステータスを反映しない場合があるため、リアルタイムチェックではなく簡易的な初期チェックが必要な場合に適しています。 サードパーティの検証サービス: ほぼリアルタイムの検証が必要な場合は、サードパーティの検証サービスを通話ワークフローに統合できます。発信前に最新の番号ステータスが必要な場合に適しています。利用可能なソリューションについては、 AWS パートナーネットワーク または AWS Marketplace を確認してください。AWS は特定のサードパーティソリューションを推奨していません。要件に基づいてパートナーソリューションを独自に評価することを推奨します。 次のステップ 本記事の要件に照らして現在の番号設定を監査します。非準拠の番号の利用はサービスの即時中断につながる恐れがあります。 AWS サポート を通じて番号の承認リクエストを送信します。 GitHub サンプル または本記事で説明したクイック接続設定を使用してレート制限を実装します。 AWS End User Messaging またはサードパーティサービスを使用して番号検証を設定します。 チームが制限事項と承認済み番号タイプを理解していることを確認します。 継続的な運用として、オブザーバビリティダッシュボードとアラートの維持、要件変更に応じた承認済み番号リストの更新、新しい番号や設定変更後のコールバック機能のテスト、チームの制限事項に対する認識の検証を推奨します。 まとめ 最新のコンプライアンス要件については、Amazon Connect Customer 管理者ガイドの アウトバウンド発信の制限 を参照してください。レート制限の実装については、 Amazon Connect Customer Outbound Rate Limiting サンプルを参照してください。番号検証については、 AWS End User Messaging Phone Number Validate API のドキュメントを参照してください。 コンプライアンスに準拠した中国への発信には、5 つの要素を正しく実装する必要があります。承認済みの DID 番号、禁止されている番号タイプの不使用、キャリアのしきい値内でのレート制限、準拠した発信者 ID、宛先番号の検証です。これらのベストプラクティスを実装することで、サービス中断のリスクを軽減しながら中国の顧客への安定した通話接続を維持できます。 コンプライアンスに準拠した中国への発信オペレーションを確立した後は、顧客にサービスを提供している他の規制市場にもこれらのプラクティスを展開することを検討してください。また、大量発信オペレーションの管理を最適化するために Amazon Connect Customer の アウトバウンドキャンペーン 機能も活用できます。 サポートリソース 最新のコンプライアンス要件と設定手順については、Amazon Connect Customer の ドキュメント を参照してください。 技術的な実装支援については、AWS サポートにお問い合わせください。 ユースケースに合わせた追加のガイダンスについては、AWS アカウントチームにお問い合わせください。 筆者について Vivek は、カナダのバンクーバーを拠点とし、ISV のお客様を支援する AWS のテクニカルアカウントマネージャーです。お客様のクラウドオペレーションの最適化、セキュリティ体制の強化、先進的なテクノロジーの導入を支援しています。Vivek は、AWS 上でコスト効率が高く、Well-Architected なソリューションの構築をお客様が実現できるよう支援することに情熱を注いでいます。仕事以外では、テニスを楽しんだり、さまざまな文化や料理を探求したりしています。 Andrey は、カナダのトロントを拠点とし、AWS の Applied AI & Communications Technical Field Community に所属する Amazon Connect のシニアスペシャリストソリューションアーキテクトです。2015 年にコーポレート IT サポートエンジニアとして AWS でのキャリアを開始しました。その後、エンタープライズサポートリードとして、カナダの公共セクターのお客様を支援しました。現在の役割では、さまざまな業界のお客様と協力し、Amazon Connect を活用したカスタマーエクスペリエンスの向上に取り組んでおり、AWS のテレフォニーソリューションや AI テクノロジーに関するプロアクティブなガイダンスを提供しています。 Avijit は、ロンドンを拠点とし、AWS の戦略アカウント担当のシニアテクニカルアカウントマネージャーです。2019 年にシアトルを拠点とするクラウドサポートアソシエイトとして AWS でのキャリアを開始し、Amazon Connect やサーバーレスサービスなどを専門としていました。現在の役割では、プロアクティブなアーキテクチャガイダンスと運用の健全性の監視を提供し、ビジネスの自動化とオペレーショナルエクセレンスを推進することで、お客様の AWS 上での継続的な成功を加速させています。 翻訳はテクニカルアカウントマネージャーの高橋が担当しました。原文は こちら です。

2026 年 5 月 28 日、各種機能を大幅に強化した次世代の AWS Resilience Hub を発表いたしました。これにより、新しいアプリケーションモデル、依存関係の検出・評価、生成 AI を活用した障害モード分析、モジュール型レジリエンスポリシー、組織全体のレポート機能を統合し、包括的な体験を実現します。 数百単位のアプリケーションを運用している組織はいずれも、可用性が最重要課題である一方で、レジリエンス目標の設定、進捗状況の測定、ポートフォリオ全体でのコンプライアンス証明を行う一貫した方法がないという、共通の課題を抱えています。チームごとに採用している基準やツールが異なるため、アプリケーションが実際に期待どおりの水準を満たしているかどうかについて情報共有に苦労しています。 次世代の AWS Resilience Hub はこうした状況を打破します。サイト信頼性エンジニア (SRE) と開発チームがレジリエンスポリシーに関する要件への認識を合わせ、アプリケーションチームがその要件を達成できるよう支援するとともに、テストによってコンプライアンスを証明できるようにします。 AWS Organizations との連携により、チームはレジリエンスの大規模な評価、障害モードの特定、隠れた依存関係の検出、企業全体にわたる進捗状況のレポート作成が可能になりました。 次世代の Resilience Hub は企業によるレジリエンス向上の取り組みを段階的に支援するため、以下の概念を取り入れています。 レジリエンスポリシー : モジュラー型の組み合わせ可能な要件により、レジリエンスに関する要件を設定できます。単一の固定的なポリシーの種類を指定するのではなく、サービスレベル目標 (SLO)、マルチ AZ やマルチリージョンのディザスタリカバリ、データ復旧要件など、アプリケーションにとって重要な要件を選択してポリシーを構築できます。 ビジネスレベルの把握 : ビジネス成果に直結する重要なエンドユーザーパスを通じて、新しいアプリケーションモデリングを使用できます。 システムはビジネスアプリケーションを表し、ユーザージャーニーは重要なビジネスパスを示します。また、サービスは AWS リソース、コード、オブザーバビリティに関する要素で構成されるデプロイ可能な単位です。Resilience Hub はそれらを自動的に検出し、リソースの接続関係を示すトポロジにマッピングします。 AI による障害モード評価 : 生成 AI を活用した評価を実行し、自社定義のレジリエンスポリシー、 AWS Well-Architected ベストプラクティス、 AWS Resilience Analysis Framework に照らしてサービスを分析できます。この評価を通じて潜在的な障害モードを特定し、実行可能な推奨事項を得ることができます。 依存関係の検出・評価 : サービスが依存している AWS サービス、内部エンドポイント、サードパーティのエンドポイントを自動的に検出できます。依存関係評価では DNS クエリログ分析を活用し、予期しないクロスリージョン呼び出しや重大なサードパーティ依存関係など、見落としがちな依存関係を特定できます。 次世代 AWS Resilience Hub の活用例 まず、レジリエンスポリシーを設定し、最初のシステムとサービスをセットアップします。その後、障害モード評価を実行して結果を確認し、検出結果に基づいて対応を行います。 開始する前に、Invoker IAM ロールを設定する必要があります。このロールにより、Resilience Hub に AWS リソース、クロスアカウントロール (AWS Organizations を使用しない場合)、または サービスリンクロール (SLR) (AWS Organizations を使用する場合) への読み取り専用アクセス権限が付与されます。 また、Resilience Hub は AWS Organizations と統合されており、単一の委任管理者アカウントから組織全体のレジリエンスを管理できます。これにより、企業全体のレジリエンス体制を評価するために個々のアカウントにログインする必要がなくなります。詳細は、AWS Resilience Hub ユーザーガイドの「 前提条件の詳細 」を参照してください。 レジリエンスポリシーを設定するには、 AWS Resilience Hub コンソール の [ ポリシー ] メニューで [ ポリシーを作成する ] を選択します。ポリシー名と説明を入力し、レジリエンス要件を選択します。たとえば、金融アプリケーションで使用されるマルチリージョンのディザスタリカバリ用に再利用可能なポリシーを作成できます (例: 99.95% の可用性 SLO、15 分の RTO、マルチリージョンのディザスタリカバリにおける 5 分の RPO、RTO と RPO の要件に沿ったディザスタリカバリアプローチ)。 データリカバリ要件を選択した場合は、このポリシーに関連付けられたサービスごとに、バックアップから復元する際のデータリカバリ時間目標を設定できます。 ビジネスアプリケーションを表す最初のシステムを作成するには、[ システム ] メニューの [ システムを作成する ] を選択します。システムには、AWS Organizations アカウントアクセスを有効にできます (任意)。 これで、特定のマイクロサービスなど、デプロイ可能なユニットを表すサービスを作成し、それをシステムに関連付けるとともに、Resilience Hub がリソースを検出する場所を指定できます。サービス名 (例: stock-exchange-service ) を入力し、レジリエンスポリシーと Invoker AWS IAM ロール名を選択します。サービスリージョンのほか、リソースタグ、AWS CloudFormation スタック、Terraform ステートファイルの場所、Amazon EKS のクラスターと名前空間などのサービスリソースを選択できます。 このサービスに対する依存関係検出を有効にすると、AWS はサービス内のリソースに関連付けられた VPC の VPC クエリログを分析します。この機能は、サービス詳細ページの依存関係検出設定からいつでも無効にできます。 これで、サービスの作成が完了し、ポリシーが適用された状態で、最初の評価を実行できます。サービスページで [ 障害モード評価を実行する ] を選択し、評価が完了するまで待ちます。 評価中、Resilience Hub は Invoker ロールを引き受け、設定された入力ソースからリソースを読み取り、親子関係を特定し、アプリケーショントポロジサービスにクエリを実行してリソース間の接続関係を示し、データフロー、包含関係、権限を示すトポロジを構築します。 [ サービストポロジ ] を選択すると、グラフ、表、JSON 形式でサービスリソースをサービス機能別に表示できます。 [ 障害モードガイダンス ] を選択すると、障害モード評価の実行中にエージェントに指示を与えるためのアサーションを追加できます。 アサーションはエージェントが生成することも、ユーザーが追加することもできます。既存のアサーションを修正して、評価の精度を向上させることが可能です。 評価が完了すると、サービスページの [ 評価 ] タブで検出結果と推奨事項を確認できます。 各検出結果からは、障害モードの内容と、それがアーキテクチャにとって重要な理由、修正方法、関連するポリシー要件を把握できます。 推奨事項を実装する場合は [ 解決済みとしてマークする ] を選択します。検出結果がユースケースに当てはまらない場合は、[ 無関係としてマークする ] を選択することもできます。 Resilience Hub をすでに導入済みの場合は、Resilience Hub の移行 API を使用して、既存のアプリケーションを簡単に移行できます。移行 API を使用することで、既存の評価ポリシーを新しいレジリエンスポリシーに変換し、既存のアプリケーションを新しいモデルにマッピングできます。たとえば、複数の関連アプリケーションを、複数のサービスを備えた単一のシステムにマッピングできます。 新機能の詳細は、 AWS Resilience Hub ユーザーガイド をご確認ください。 今すぐご利用いただけます このたび、Resilience Hub が利用可能な AWS 商用リージョンで、次世代 AWS Resilience Hub の一般提供を開始しました。リージョンごとの提供状況や今後のロードマップについては、「 AWS Capabilities by Region 」をご確認ください。 Resilience Hub は、新しいサービスベースの料金モデルを採用しています。料金には、サービスごとに月 2 回の障害モード評価と、オプションの自動依存関係評価が含まれます。AWS Resilience Hub は無料でお試しいただけます。料金の詳細は、 AWS Resilience Hub 料金ページ をご確認ください。 Resilience Hub コンソール で新しい AWS Resilience Hub をお試しいただき、 AWS re:Post for Resilience Hub または普段ご利用の AWS サポート窓口にフィードバックをお寄せください。 – Channy 原文は こちら です。

4 名の傑出したコミュニティリーダーを、最新の AWS ヒーローとしてお迎えできることを大変うれしく思います。これらのリーダーは、AWS コミュニティの発展を支えるコラボレーションと知識の共有の精神を体現しています。他のビルダーが AWS re:Invent を効果的に活用するのに役立つ AI を活用したツールの構築から、ラテンアメリカにおける最大規模のいくつかの AWS コミュニティの主導や、ブログやイベントを通じたクラウドアーキテクチャに関する深い専門知識の共有まで、その活躍は多岐にわたります。教育、メンターシップ、コミュニティ活動を通じて他者をサポートするこれらのリーダーの献身的な姿勢は、世界中のビルダーにインスピレーションを与えています。 Damiano Giorgi 氏 – パヴィア (イタリア) AI ヒーローである Damiano Giorgi 氏は、AI とその進化に焦点を当てた Cloud Solutions Architect です。オンプレミスシステムエンジニアリングから AWS へと転身し、以来、後悔したことは一度もありません。同氏は AWS User Group Pavia および AWS User Group Milan の運営をサポートしており、個人的なブログである「Bass and Bytes」でコンテンツを共有しています。 Damiano 氏は、ビルダーが自身の興味に合った AWS re:Invent セッションを見つけるのをサポートするために、Amazon Bedrock と Amazon Nova を利用する「Unofficial post:Invent Session Suggester」を開発しました。同氏は、AWS Summit Milan や AWS Community Day Italy のほか、アドリア地域、ギリシャ、オランダなど、欧州各地のカンファレンスで講演しています。 Darryl Ruggles 氏 – オタワ (カナダ) サーバーレスヒーローである Darryl Ruggles 氏は、Cloud Solutions Architect であり、AWS アプリケーションおよび AI/ML アーキテクチャに注力するようになる以前は、長年ソフトウェアデベロッパーとして活躍していました。同氏は、自身のブログ、LinkedIn、公開プロジェクトを通じて、サーバーレス、コンテナ、AI/ML、FinOps に関する知識を共有しています。Darryl 氏は、「Believe In Serverless」をはじめとする多くのオンライン AWS コミュニティで積極的に活動しており、オンラインイベントと実地イベントの両方でコミュニティとの交流を楽しんでいます。 Ricardo Daniel Ceci 氏 – ブエノスアイレス (アルゼンチン) AI ヒーローである Ricardo Daniel Ceci 氏は、アルゼンチン最大の AWS コミュニティであり、約 2,400 名のメンバーを擁する AWS User Group Buenos Aires を率いています。同氏はまた、AWS Community Day Argentina の主要なオーガナイザーであり、AWS Community Leader of the Year 2025 for LATAM に選出されました。Ricardo 氏は、ラテンアメリカ各地のクラウドエキスパート、AWS ヒーロー、デベロッパーアドボケイトとの対話を特集したポッドキャストを配信しています。同氏は、クラウドとウェブ開発において 15 年を超える期間にわたる経験を有しておりち、スペイン語圏のビルダーを支援し、LATAM におけるクラウドと AI の普及を促進することに情熱を注いでいます。 Matias Kreder 氏 – ブエノスアイレス (アルゼンチン) AI ヒーローである Matias Kreder 氏は、AWS Certification Subject Matter Expert (SME) であり、AWS Certified AI Practitioner 試験を含む複数の AI/ML 認定に貢献しました。同氏のジャーニーは AWS DeepRacer から始まり、そこで 3 度ファイナリストに選出されました。同氏はこれをきっかけにして、地域全体でレースイベントや ML に関する講演会を企画するコミュニティ活動に積極的に取り組むようになりました。AWS User Group Leader for Buenos Aires として、同氏は AWS Community Day Argentina 2025 を主催し、LATAM 全域におけるコミュニティイベントにおいて講演しています。 詳細 AWS ヒーロープログラムの詳細を知りたい、またはお近くのヒーローとつながりたい場合は、 AWS ヒーローのウェブページ にアクセスしてください。 – Taylor 原文は こちら です。

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 AWS Summit Japan が開催される 6 月 25 – 26 日 まで 1 ヶ月を切りましたね。登録がまだの方は こちら から登録しぜひ来場ください！様々なコンテンツをご用意してお待ちしております！ また最近気軽に参加いただける勉強会として「昼休みの 30 分」を活用した Amazon Quick 勉強会が開催されています。 6 月 3 日 、 6 月 10 日 に予定されていますのでぜひご参加ください！ 「 AWS ジャパン生成 AI 実用化推進プログラム 」も引き続き募集中ですのでよろしくお願いします。 それでは、5 月 25 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ「寄稿：生成 AI で”探せなかった開示情報”を見つけ出す 〜 JPX の AI 開示情報検索サービス J-LENS〜」を公開 日本取引所グループ（JPX）傘下の JPX 総研様が開発した、上場企業の適時開示情報を対象とした AI 検索サービス「J-LENS」の技術的な仕組みと成果を紹介する寄稿記事です。Amazon Bedrock と Amazon OpenSearch Service を基盤に、クエリ解析・ベクトル検索・リランキングなど多層的な工夫を組み合わせることで、キーワード検索では見つけられなかった情報を自然文で発見できるセマンティック検索を実現しています。 ブログ記事「Physical AIのためのデータ収集基盤を構築する①：模倣学習データの完全性を保証させるエッジシステム」を公開 株式会社 APTO 様が AWS 上に構築している双腕遠隔操作ロボット向け Physical AI データ基盤について、3部作の第1回としてエッジ側の「収集」レイヤーを解説しています。VLA モデルのファインチューニングに使う模倣学習データを、エッジ側で品質を確定させてから Amazon S3 に送る仕組みや、不完全データの排除、S3 Event Notifications によるイベント駆動設計など、Physical AI / ロボティクス分野のデータパイプラインを構築する際の実践的なアーキテクチャが紹介されています。 ブログ記事「AI ツールで実現する継続収益ビジネス 〜開発力を資産に変える〜 – AWS Local Executive Roadshow 名古屋編（#4/8）開催レポート」を公開 2026 年 4 月 23 日に名古屋で開催された、IT 企業エグゼクティブ向けイベントのレポートです。製造業 SI を行うエスツーアイ株式会社様が Kiro の仕様駆動開発を活用して上流工程の課題を解決した事例と、i Smart Technologies 株式会社様が Amazon Bedrock を使い IoT データを現場の意思決定に活かす「AI 製造部長」を開発した事例を紹介しています。AI を「パートナー」として自社のドメイン知識と掛け合わせる発想が印象的です。 ブログ記事「Kiro アンバサダープログラムのご紹介」を公開 AWS が提供する AI 開発ツール「Kiro」のコミュニティアンバサダープログラムが発表されました。アンバサダーには無償サブスクリプションや未公開機能への早期アクセス、プロダクトチームとの直接コミュニケーションなどの特典があり、月 3〜4 時間程度の活動が期待されます。Kiro を日常的に使っている開発者にとって、製品の方向性に直接影響を与えられる機会です。応募は kiro.dev から随時受付中です。 ブログ記事「満員御礼！ Claude Code による開発体験ワークショップ【イベントレポート】」を公開 2026 年 5 月に NHN テコラス主催で開催された Claude Code のハンズオンワークショップのレポートです。Agentic Coding の基礎から、CLAUDE.md による設定、Plan Mode、MCP の活用までを座学で学んだ後、Excalidraw のコードベースへ実際に Claude Code で機能追加を体験する内容です。ワークショップコンテンツは公開されており自身の AWS アカウントで取り組めるので、Claude Code を始めてみたい方はぜひ参考にしてみてください。 サービスアップデート Kiro で Claude Opus 4.8 が利用可能に Kiro の IDE、CLI、Web で Claude Opus 4.8 が利用可能になりました。自己検証機能の強化、より効率的なツール呼び出し、長期プロジェクトでのフォロースルー改善が特徴です。Pro、Pro+、Power プランで利用でき、CLI ユーザーは v2.5.0 以上へのアップデートが必要です。 Amazon Connect が生成 AI を使用してセルフサービスインタラクションを自動評価 Amazon Connect で、AI エージェントによるセルフサービス対応の品質を生成 AI が自動評価する機能が追加されました。マネージャーが自然言語で評価基準を定義すると、生成 AI がその基準に基づいてインタラクションを評価し、詳細な理由付けとトランスクリプトからの参照ポイントを提供します。東京リージョンを含む 7 リージョンで利用可能です。詳細は こちらのドキュメント をご参照ください。 Amazon Connect の生成 AI 搭載コンタクト後サマリーが 8 つの新しい言語に対応 Amazon Connect で生成 AI を活用したコンタクト後の要約機能が、新たに日本語・フランス語・ドイツ語・スペイン語・ポルトガル語・イタリア語・中国語・韓国語の 8 言語に対応しました。会話の言語に合わせて自動的にサマリーが生成されるようになり、多言語サポートを提供するグローバル組織でもコンタクト内容を効率的に把握できます。詳細は こちらのドキュメント をご参照ください。 Amazon Bedrock が Service Quotas のサポートを拡大 Amazon Bedrock の bedrock-mantle エンドポイントに対する推論クォータ（input-tokens-per-minute / output-tokens-per-minute）が AWS Service Quotasコンソールから確認可能になりました。クォータの可視化により本番スケールの事前計画が容易になり、標準的なプロセスでクォータ増加をリクエストできます。東京リージョンを含む複数リージョンで利用可能です。詳細は こちらのドキュメント をご参照ください。 Claude Opus 4.8 が AWS で利用可能になりました Anthropic 社の最新モデル Claude Opus 4.8 が AWS 上で利用可能になりました。エージェント型コーディング、自律的タスク実行、複雑な知識労働において優れた性能を発揮し、長い自律実行セッションでもコンテキストを保持しながら深い推論を行えます。Amazon Bedrock および Claude Platform on AWS からアクセスできます。詳細は こちらの Amazon Bedrock ページ をご参照ください。 Amazon SageMaker HyperPod Slurm クラスターが継続的プロビジョニングでの最小キャパシティ要件の指定をサポート Amazon SageMaker HyperPod の Slurmクラスターで、継続的プロビジョニング利用時に最小キャパシティ要件（MinCount）を指定できるようになりました。固定数のノードを必要とする分散学習フレームワーク（PyTorch FSDP、Megatron-LM等）で、最小閾値が満たされるまでクラスターが待機するため、不完全な状態でのジョブ開始を防止できます。HyperPod対応の全リージョンで利用可能です。詳細は こちらのドキュメント をご参照ください。 P5.48xl インスタンスが SageMaker ノートブックインスタンスで東京リージョンに拡大 NVIDIA H100 GPU 搭載の P5.48xl インスタンスが、SageMaker ノートブックインスタンスにおいて東京リージョンで利用可能になりました。前世代比で処理時間を最大 4倍短縮し、トレーニングコストを最大 40% 削減できます。LLM や拡散モデルのトレーニングなど生成 AI 開発に活用できます。詳細は こちらのドキュメント をご参照ください。 P4de インスタンスが SageMaker ノートブックインスタンスで東京リージョンに拡大 NVIDIA A100 GPU 8 基搭載（合計 640 GB GPU メモリ）の P4de インスタンスが、SageMaker ノートブックインスタンスにおいて東京リージョンで利用可能になりました。P4d 比で MLトレーニング性能が最大 60% 向上し、コストを 20% 削減できます。詳細は こちらのドキュメント をご参照ください。 P6-B200 インスタンスが SageMaker ノートブックインスタンスでバージニア北部リージョンに拡大 NVIDIA Blackwell GPU 8 基搭載（1440 GB GPU メモリ）の P6-B200 インスタンスが、SageMaker ノートブックインスタンスにおいてバージニア北部リージョンで利用可能になりました。P5en 比で最大2 倍の AI トレーニング性能を提供し、大規模基盤モデルのインタラクティブな開発やファインチューニングに最適です。 次世代 Amazon OpenSearch Serverless が一般提供開始 Amazon OpenSearch Serverless の次世代版が一般提供開始されました。エージェント構築向けに設計され、前世代比 20 倍速いオートスケーリング、スケール・トゥ・ゼロによる最大 60%のコスト削減、コンピュートとストレージの完全分離を実現しています。Kiro や Claude Code などとのネイティブ統合も提供されます。詳細は こちらのドキュメント をご参照ください。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は AI Agent と毎日戯れており、AI Agent 無しでは生きていけなくなっています。好きなうどんは’かけ’です。

みなさん、こんにちは。ソリューションアーキテクトの杉山です。今週も 週刊AWS をお届けします。 「AWS 初学者向けの勉強方法 7 ステップ ! 2026 年版 !」 のブログを公開しました。「AWS を勉強したいけど、何から手をつければいいんだろう…」という方に向けて、クラウドの概要をつかむところからお客様事例、サービスの全体像、各サービスの深掘り、ハンズオンでの実践、最新情報のキャッチアップ、そしてさらなるレベルアップまで、知識の深め方が 7 ステップで体系的にまとめられています。 これから AWS の学習を始める方や、「勉強し始めたけど次にどうしよう」という方はもちろん、社内で AWS 初学者を育成する立場の方にもぴったりの内容です。 それでは、先週の主なアップデートについて振り返っていきましょう。 2026年5月25日週の主要なアップデート 5/26(火) Amazon GuardDuty Malware Protection for AWS Backup が Amazon S3 continuous backups に対応 Amazon GuardDuty Malware Protection for AWS Backup が Amazon S3 continuous backups (継続的バックアップ) に対応しました。これにより、S3 の継続的バックアップに対してマルウェアスキャンを実行し、バックアップタイムライン全体から安全な復元時点を特定できるようになります。バックアッププラン内でフルスキャンまたは増分スキャンを有効化でき、復元可能な任意の時点までオンデマンドスキャンを実行できます。新しい GetPITRMalwareScanResults API により、継続的バックアップ内の任意の時点におけるマルウェアスキャンステータスをクエリできるため、復元前に特定の復元時点が安全であることを確認できます。 5/27(水) AWS Backup、論理的エアギャップボールトのマルチパーティ承認に OTP 検証を追加 AWS Backup は、論理的エアギャップボールトに隔離されたバックアップへ一時的に読み取り専用アクセスする際などに用いるマルチパーティ承認において、承認者が投票する際に 6 桁のワンタイムパスワードによる検証を必須としました。承認者は AWS IAM Identity Center に登録されたメールアドレスに送信される OTP を入力する必要があります。この機能は追加料金なしで、既存および新規のすべてのマルチパーティ承認セッションに自動適用され、設定作業は不要です。論理的エアギャップボールトをサポートするすべての AWS リージョンで利用できます。 Amazon Aurora MySQL が Kiro Powers との統合をサポート AWS は、Amazon Aurora MySQL-Compatible Edition が Kiro Powers との統合をサポートすることを発表しました。Kiro Powers は、Model Context Protocol (MCP) サーバー、ステアリングファイル、フックを事前パッケージ化したリポジトリで、AI エージェント支援により Aurora MySQL を使用したアプリケーション開発を加速します。この統合により、開発者は自然言語の会話形式で、データベースクエリの実行、スキーマ管理、クラスタ作成などの操作を実行できます。Kiro IDE または Kiro Web からワンクリックでインストールでき、Aurora MySQL が利用可能な全ての AWS リージョンで使用できます。 Amazon Connect Customer が生成 AI によるセルフサービスインタラクションの自動評価に対応 Amazon Connect Customer に、生成 AI を活用してセルフサービスインタラクション（タッチトーン、Lex ボット、AI エージェントとの対話）を自動評価する機能が追加されました。マネージャーは自然言語で評価基準を定義でき（例：「AI エージェントは顧客の問題をすべて解決しましたか？」）、生成 AI が会話トランスクリプトを分析して評価結果と詳細な理由付けを提供します。これにより、最大 100% のセルフサービスインタラクションを自動評価し、AI エージェントのパフォーマンス改善サイクルを加速できます。米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (ソウル、シンガポール、シドニー、東京)、欧州 (フランクフルト) の 7 リージョンで利用可能です。 AWS Elemental Inference が Smart Subtitles でライブ字幕の自動生成に対応 AWS Elemental Inference に Smart Subtitles 機能が追加されました。この機能は、AI を活用した音声認識により、ライブビデオストリームからリアルタイムで字幕を自動生成します。英語 (米国、英国、オーストラリア)、フランス語、ドイツ語、イタリア語、ポルトガル語、スペイン語の6言語に対応し、TTML または WebVTT 形式で低レイテンシーの字幕を配信します。AWS Elemental MediaLive とのネイティブ統合により、手動の字幕作成ワークフローやサードパーティサービスなしでアクセシブルなコンテンツを配信できます。スポーツ中継の選手名や専門用語に対応するため、カスタム辞書の作成も可能です。 Amazon Bedrock が Service Quotas のサポートを bedrock-mantle エンドポイントに拡張 Amazon Bedrock は、bedrock-mantle エンドポイントの推論クォータを AWS Service Quotas コンソールから確認できるようになりました。これにより、OpenAI Responses API、OpenAI Chat Completions API、Anthropic Messages API をサポートする bedrock-mantle エンドポイントについて、モデルごとの入力トークン毎分 (input-tokens-per-minute) および出力トークン毎分 (output-tokens-per-minute) のクォータを、bedrock-runtime エンドポイントや他の AWS サービスと同じ方法で追跡できます。この機能は、米国東部 (バージニア北部、オハイオ)、米国西部 (オレゴン)、アジアパシフィック (ムンバイ、東京、シドニー、ジャカルタ)、欧州 (フランクフルト、アイルランド、ロンドン、ミラノ、ストックホルム)、南米 (サンパウロ) の全 13 リージョンで利用可能です。 5/28(木) Amazon OpenSearch Serverless 次世代版が一般提供開始 AWS は Amazon OpenSearch Serverless の次世代版 (NextGen) の一般提供を開始しました。前世代と比較して 20 倍速いオートスケールを実現し、数秒でリソースをプロビジョニングできます。10 分間アイドル状態が続くとコンピュート容量が 0 に縮小してコンピュート課金が停止し、再びリクエストが到着すると約 10 秒で容量が復帰します。この scale-to-zero と従量課金制により、ピーク負荷用にプロビジョニングした OpenSearch クラスタと比較して最大 60% のコスト削減が可能です。コンピュートとストレージの完全な分離、2 種類の新しいエンドポイント構造、Vercel や Kiro などの AI 開発プラットフォームとのネイティブ統合により、エージェント構築のワークフローに最適化されています。 Amazon WorkSpaces Applications が Windows Desktop OS をサポート Amazon WorkSpaces Applications が、ライセンス持ち込みを通じて Windows Desktop OS (Windows 11) を使用したストリーミングリソースのセットアップをサポートしました。お客様は既存の Windows Desktop ライセンスを持ち込むことで、Microsoft 365 Apps for enterprise を含む Windows デスクトップアプリケーションを専用ハードウェア上でストリーミングできるようになります。BYOL を利用することで OS ライセンス料が免除され、コンピュートとストリーミングインフラのみの支払いとなり、コスト削減を実現します。ただし、利用にあたってはライセンス上の制約があります。仮想ホスト環境での利用が許可された Microsoft の Windows VDA または Windows Enterprise ライセンス（VDA E3/E5 など）が必要で、リージョンあたり月間最低 50 WorkSpaces の稼働コミットメントが求められます。 Claude Opus 4.8 が AWS で利用可能に Claude Opus 4.8 の提供を開始しました。Anthropic の最高性能モデルとして、agentic coding、知識作業、長時間自律タスクで大幅な性能向上を実現しています。提供方法は Amazon Bedrock と Claude Platform on AWS の 2 つで、後者は AWS Console から Anthropic のネイティブプラットフォーム体験にアクセスできる新しいサービスです。料金は入力 $5/MTok、出力 $25/MTok で、1M トークンのコンテキストウィンドウと 128K トークンの最大出力に対応します。 Amazon Connect の生成 AI 搭載コンタクト後サマリーが 8 つの新しい言語に対応 Amazon Connect の生成 AI 搭載コンタクト後サマリーが、ポルトガル語、フランス語、イタリア語、ドイツ語、スペイン語、中国語、日本語、韓国語の 8 つの言語に対応しました。これにより、グローバルなコンタクトセンター運営組織は、会話の言語に合わせて自動的にサマリーを生成できるようになり、エージェントのアフターコンタクトワーク (ACW) の効率化と、複数言語にまたがる問い合わせのレビューが可能になります。この機能は Amazon Connect が利用可能なすべての AWS リージョンで提供されます。 5/29(金) AWS Interconnect – multicloud に 500 Mbps の無料枠を提供開始 AWS は AWS Interconnect – multicloud で 500 Mbps の無料枠の提供を開始しました。この無料枠により、AWS と他のパブリッククラウド間でプライベート接続を簡単に評価・テストできるようになります。月間約 160 TB のデータ転送が可能で、マルチクラウドワークロード、データレプリケーション、ハイブリッドアプリケーションアーキテクチャを AWS 側の料金負担なしでサポートします。オープン仕様に基づき、Google Cloud と Oracle Cloud Infrastructure (Public Preview) が既に対応しており、Microsoft Azure も 2026年後半に対応予定です。 それでは、また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です。

2026 年 5 月 13 日に公開された “ Accelerating VMware migrations with AWS Transform and MGN replication agent installation automation ” を翻訳したものです。 オンプレミスの VMware 環境から AWS への数百台のサーバー移行には、チーム、アカウント、ツール間の調整が必要です。ターゲット環境のセットアップ、ウェーブの計画、レプリケーションエージェントのデプロイ、進捗の監視、テストの実行、カットオーバーの実施が必要であり、多くの場合、複数の AWS アカウントにまたがります。各ステップはそれ自体が困難であり、マイグレーションを成功させるためには全体を通じた慎重な計画と調整が求められます。 AWS Transform は、これらのステップを単一の AI アシスト付きリホスト (リフトアンドシフト) ワークフローに統合します。AWS Transform は AWS Transform for VMware のマイグレーションライフサイクル全体のオーケストレーション機能を基盤とし、プロセスの各ステップで対話型 AI ガイダンスを提供します。 AWS Transform for VMware をすでにご利用の方は、その エクスペリエンス に馴染みがあるかもしれません。ワークフローの概要を簡単に振り返ります: ディスカバリー : AWS Transform がソース環境を分析します マイグレーション計画 : マイグレーションの目標とビジネス要件を共有すると、AWS Transform がディスカバリーフェーズで収集したデータを目標に沿って処理します ランディングゾーンの作成とネットワーク構成の移行 : AWS Transform がデプロイ可能なターゲットランディングゾーンの基盤構築を支援し、ソース環境のネットワーク設定をクラウドネイティブな AWS ネットワーク構成に変換するネットワーク構成の移行を自動化します サーバーマイグレーション : AWS Transform が既存のレプリケーションエージェントを使用して、ソースサーバーの AWS への移行を行います このワークフローは完全にダイナミックでカスタマイズ可能であり、マイグレーションジョブに最適なタスクを選択できます。 レプリケーションエージェントは、組織の既存のソフトウェア配布ツールを使用してデプロイしたり、ソースサーバーに手動で接続してデプロイしたり、あるいは MGN コネクタ (AWS Application Migration Service (MGN) 独自の効率化されたレプリケーションエージェントデプロイ機能) を使用してデプロイしたりできます。 MGN コネクタは、ソース環境の Linux マシンにデプロイされ、認証情報とソースサーバーへのネットワーク接続を提供すると、前提条件の検証からインストール、インストール後のデプロイ検証チェックの実行まで、ソースサーバー (Windows または Linux) へのレプリケーションエージェントのデプロイという「重労働」を含むインストールプロセス全体を管理・処理します。 本稿では、最新の AWS Transform リホストジョブの改善が、MGN コネクタのセットアップと構成のプロセスを自動化・加速し、大規模なマルチアカウントマイグレーションを高速に実行する方法をご紹介します。セットアッププロセスは、AWS Identity and Access Management (AWS IAM) ロールの作成と AWS Systems Manager ハイブリッドアクティベーションコードの生成を自動化するガイド付きの対話型エクスペリエンスにより合理化されました。その結果、ソース環境に MGN コネクタをデプロイするためのすぐに使用できるインストールコマンドが得られます。コネクタがデプロイされると、AWS Transform はソースサーバー全体へのレプリケーションエージェントのインストールを自動的に管理し、マイグレーションプロセス全体を通じてインストールの進捗、ステータス、実行結果の一元的な可視化を提供します。 前提条件 サーバーマイグレーションフェーズにある VMware マイグレーションジョブを持つ AWS Transform ワークスペースがあること。 AWS Transform の ランディングゾーン とネットワークマイグレーション機能を活用して、マイグレーション実行前にこのターゲット環境のセットアップと構成を自動化できます。 移行されたサーバーが起動するターゲット AWS アカウントに、ネットワークインフラストラクチャ (VPC、サブネット、セキュリティグループ) が既に配置されていること。 ソース環境に MGN コネクタをホストするための、 サポートされるオペレーティングシステム の Linux マシンが利用可能であり、ソースサーバーへのネットワークアクセスと AWS への接続があること (ネットワークフローについては アーキテクチャ図 を参照)。 ソースサーバーの認証情報が AWS Secrets Manager に保存されていること。エントリ形式の例については ドキュメント を参照してください。 マルチアカウントマイグレーションの場合、複数の AWS アカウントが AWS Organizations メンバーアカウント としてセットアップされており、メンバーアカウントのいずれかが AWS MGN の AWS Organizations 委任管理者 として機能するか、AWS Organizations 管理アカウントを使用すること。 MGN コネクタは最初のウェーブで管理アカウントまたは委任管理者アカウントにセットアップされ、他のメンバーアカウントをターゲットとする後続のウェーブで再利用できます。 AWS Transform を介した MGN コネクタのセットアップとレプリケーションエージェントデプロイのウォークスルー 以下の画像は、サーバーインベントリを AWS Transform ジョブワークスペースに読み込み完了後のセットアッププロセスを示しています。「レプリケーションエージェントのデプロイ」フェーズを開始し、AWS Transform による自動インストールで MGN コネクタを使用することを選択します。 AWS Transform は、コネクタに名前を付けるよう求めます (または自動生成されたデフォルトを使用します)。この名前は、環境全体で複数のインストールを管理する際にコネクタを識別するのに役立ちます。 図 1 – AWS Transform へ MGN コネクタの使用を指示 次のフェーズでは、MGN コネクタセットアップを使用してソース環境に MGN コネクタをインストールするための AWS アカウントの準備を行います。AWS Transform は、AWS アカウントコンソールでセットアップを起動するためのリンクを提供します。以下の画像は、エージェントと連携してこれらのステップを進め、AWS コンソールでセットアップを完了する様子を示しています。 このプロセスでは、MGN コネクタに必要なリソースの作成を効率化します: IAM ロール : MGN コネクタは、エージェントデプロイタスクの実行中に引き受ける一連の IAM ロールに依存します。IAM リソースを自分で管理したい場合は、代わりにセットアップページから AWS CloudFormation テンプレートをダウンロードできます。 SSM ハイブリッドアクティベーション : 最大 30 日間有効なアクティベーションコードで、安全なコマンド実行のためにコネクタマシンを AWS Systems Manager にリンクするために使用されます。 図 2 – AWS Transform がユーザーにコンソールで MGN コネクタセットアップを完了するよう指示する 図 3 – AWS コンソールでの ATX MGN コネクタセットアップ ATX MGN コネクタセットアップページは、必要なすべての認証情報と構成を含む完全なインストールコマンドを生成します。これを、MGN コネクタ用に準備したサーバーにコピーして実行できます。 インストールが完了するまでセットアップページを開いたままにしてください。インストールコマンドにはブラウザにのみ存在する機密性の高い認証情報が含まれており、AWS Transform には保存されません。 セットアップページからインストールコマンドをコピーし、MGN コネクタを実行するために指定した Linux マシンで実行します。 コネクタのインストールには約 2〜3 分かかります。インストールにより、Linux マシン上に SSM Agent が構成され、コネクタが AWS サービスに登録されます。 図 4 – ソース環境の Linux サーバーへの MGN コネクタのインストール AWS Transform ワークスペースに戻り、MGN コネクタが正常にインストールされたことをエージェントに確認します。 図 5 – AWS Transform で MGN コネクタのデプロイ完了を確認する 以下の画像に示すように、AWS Transform はソースサーバーの認証情報を必要とします。これは AWS Secrets Manager にシークレットとして保存したものです。Transform は、Linux サーバーと Windows サーバーのシークレット ARN を提供するよう求めます。これらのシークレットは後でオンデマンドで取得され、ソースサーバーにレプリケーションエージェントをデプロイするために使用されます。 図 6 – ソースサーバーへの認証情報を含むシークレット ARN を AWS Transform に提供する オペレーティングシステムの種類ごとに、すべての Linux サーバーと Windows サーバーに対して単一の共有シークレットを構成するか、認証情報がアプリケーションやサーバー間で異なる場合には、サーバーごとに複数のシークレットを定義できます。多様な認証情報を持つ環境の場合、AWS Transform はサーバーインベントリが事前入力された CSV ファイルを生成してプロセスを簡素化し、各サーバーを対応するシークレットにマッピングしてワークフローにアップロードし直すことができます。 AWS Transform はシークレットを MGN 内のソースサーバーに関連付け、コネクタは IAM ロールを使用してレプリケーションエージェントをデプロイする際にオンデマンドでシークレットを取得します。シークレットは Secrets Manager 以外のどこにも保存されません。 MGN コネクタが構成され、シークレットがソースサーバーに関連付けられると、Transform はレプリケーションエージェントをデプロイする準備が整います。 AWS Transform は、SSM エージェントを使用してコネクタにデプロイコマンドを送信し、ソースサーバーにレプリケーションエージェントをインストールします。以下の画像に示すように、各ソースサーバーに対してコネクタは以下を実行します: Secrets Manager から認証情報を取得 サーバーに接続 (Linux は SSH 、Windows は WinRM) サーバーが前提条件を満たしているか検証 (利用可能な CPU、RAM、ディスクスペース) レプリケーションエージェントをインストール レプリケーションエージェントを構成 インストールの成功と AWS MGN サービスへの接続を検証 図 7 – AWS Transform がソースサーバーの前提条件を検証し、レプリケーションエージェントをデプロイする AWS Transform ジョブワークスペースを通じてデプロイの進捗をリアルタイムで監視し、各ソースサーバーのステータスを個別に追跡できます。サーバーが前提条件の検証に失敗した場合、コネクタは具体的な問題を報告するため、再試行前に対処できます。 次のステップ エージェントがデプロイされると、データレプリケーションが自動的に開始され、ソースサーバーは AWS MGN の ライフサイクルステート を経ていきます。 AWS MGN は、レプリケーション対象として選択された各サーバーのディスクの初期同期を実行し、その後、継続的なブロックレベルのレプリケーションを維持します。AWS Transform は、移行されたワークロードを検証するためのテストインスタンスの起動や、本番稼働の準備が整った際のカットオーバーの実行など、残りのステージを引き続きガイドします。 マルチアカウントマイグレーションの場合、最初のウェーブでセットアップしたコネクタは、組織内のメンバーアカウントをターゲットとする後続のウェーブで再利用できます。AWS Transform は AWS CloudFormation StackSets を通じてクロスアカウント IAM ロールのデプロイを処理するため、アカウントごとにコネクタのセットアップを繰り返す必要はありません。 クリーンアップ VMware マイグレーションに AWS Transform for VMware を使用した場合は、 AWS Transform ワークスペースまたはその使用中に作成されたリソースに関連するコストが発生しないよう、不要なリソースをクリーンアップしてください。具体的には: AWS Application Migration Service によって作成されたリソース (進行中のレプリケーションジョブ、マイグレーション中のテスト用に起動された EC2 インスタンス、ソース環境で MGN コネクタを実行する Linux サーバーなど) をクリーンアップしてください AWS Secrets Manager で作成されたシークレット AWS Transform ワークスペースまたはコンソールでの MGN コネクタセットアッププロセスによって作成された IAM ロール 有効な SSM ハイブリッドアクティベーション インフラストラクチャコンポーネント (VPC、サブネット、セキュリティグループ) リソースの削除によりデータも削除されるため、マイグレーションが完了したことを確認した後に、不要なリソースのみをクリーンアップしてください。 まとめ 本稿では、AWS Transform が大規模なレプリケーションエージェントデプロイのための MGN コネクタのセットアップと構成をどのように合理化するかをご紹介しました。IAM ロールの作成、SSM ハイブリッドアクティベーションを自動化し、ガイド付きのセットアップエクスペリエンスを提供することで、AWS Transform はソースサーバーへのレプリケーションエージェントのデプロイにかかる時間と労力を削減し、マイグレーションを加速します。今すぐ AWS Transform ワークスペースを作成 して VMware マイグレーションジョブを始めてみましょう。 著者について Dor Shiloni Dor は AWS シニアスペシャリストソリューションアーキテクトで、EMEA マイグレーション・モダナイゼーションチームのメンバーです。彼は顧客のニーズを理解し、クラウドを活用して革新的なソリューションを設計し、顧客にビジネス価値をもたらすことに情熱を注いでいます。 Efrat Manor Portnoy Efrat は、AWS Transform のシニアプロダクトマネージャーであり、ディスカバリー・計画からランディングゾーン、ネットワーク、サーバー移行まで、完全な移行ライフサイクルを加速する簡素化されたエージェント駆動型の新しい AWS エクスペリエンスを構築するチームの一員です。顧客、パートナー、AWS フィールドチームと密接に連携してきた彼女の専門知識と経験は、この進化を形作る上で重要な役割を果たし、移行を AWS Transform 内でより自動化された、エージェント駆動型のエクスペリエンスに変革することを支援しています。 Patrick Kremer Patrick Kremer は、インフラストラクチャの移行とモダナイゼーションに焦点を当てたシニアスペシャリストソリューションアーキテクトです。Patrick は 2022 年に AWS に入社し、20 年間の VMware の経験を活かして、お客様の AWS ソリューションへの移行を支援しています。彼は認定 AWS ソリューションアーキテクトプロフェッショナルであり、教育とブログ執筆に情熱を注いでいます。 翻訳はソリューションアーキテクト齋藤が担当しました。原文は こちら です。  

アマゾン ウェブ サービス ジャパンのソリューションアーキテクト、齋藤です。 NHN テコラス様が主催する 「はじめてでも大丈夫 – 今からでも遅くない、Claude Code による開発体験ワークショップ」 に、AWS のソリューションアーキテクトが登壇しました。本イベントは定員に達し満員御礼での開催となりました。ご参加いただいた皆様、ありがとうございました！ 本イベントは、「AI コーディングツールは気になっているけど、まだ触ったことがない」というエンジニアの方を対象に、Claude Code を使った Agentic Coding を実際に体験いただくオフライン形式のワークショップです。 Claude Code 入門 & ハンズオン ～ Agentic Coding を一緒に体験しよう～ AWS ソリューションアーキテクト 山澤による座学セッション 座学パートでは、Agentic Coding の概要に加え、 CLAUDE.md による設定、Plan Mode を使った計画的な実装、コンテキスト管理、MCP（Model Context Protocol）といった Claude Code を使いこなすためのポイントを解説しました。 ハンズオンに取り組む参加者の様子 ハンズオンでは、 手を動かして学ぶ Claude Code 入門ワークショップ のモジュール 1 を、AWS ソリューションアーキテクトの齋藤がファシリテーターとして進行しました。オープンソースのホワイトボーディングツール Excalidraw を題材に、本物のコードベースへ Claude Code で機能追加を行う体験をしていただきました。 AWS ソリューションアーキテクト 齋藤によるハンズオンセッション 参加者は AWS 上にデプロイされた Code Editor サーバーにブラウザからアクセスするだけで、ローカル PC に何もインストールすることなく Claude Code を体験できる環境を用意しました。Claude Code は Amazon Bedrock 経由で Claude モデルを呼び出す構成です。モジュール 1 では、以下の内容を体験しました。 Claude Code の基本操作（プロンプトの書き方、ファイル操作） CLAUDE.md の作成と活用 Plan Mode を使った計画的な実装 Excalidraw への機能追加 Playwright MCP を使った視覚的な動作確認 Claude Code を AWS で始めるには ～ Amazon Bedrock 連携から組織導入まで～ NHN テコラス株式会社 AWS Ambassador 福永 悠斗 氏 2 つ目のセッションでは、NHN テコラスの福永氏より、Claude Code を AWS 環境で動かすための 2 つの選択肢を解説いただきました。 Amazon Bedrock API 連携 — セットアップ手順や必要な IAM 権限の設定方法 AWS Marketplace Enterprise Plan — 請求の一元化や管理面でのメリットなど、組織導入を見据えた選択肢 企業で Claude Code を導入する際の具体的なステップが示され、「明日から自社でも始められそう」という声が聞かれました。 参加者の声 「自然言語でコードを改修できることを体感できた」「サポートが手厚く安心して取り組めた」といった声が多く、初めて AI コーディングツールに触れる方にとって実践的な学びの場になったほか、「第二弾・第三弾も開催してほしい」というリクエストや「これから利用・提案予定」という回答も多く、本イベントが Claude Code の導入検討を後押しする機会になりました。 おわりに 本イベントでは、Claude Code on Amazon Bedrock を活用した実践的な開発体験を提供しました。AI コーディングツールの第一歩を踏み出すきっかけとなれば幸いです。 今回使用したワークショップコンテンツは公開されています。ご自身の AWS アカウントにデプロイして取り組むこともできますので、ぜひお試しください。 ワークショップ: 手を動かして学ぶ Claude Code 入門ワークショップ 解説ブログ: 手を動かして学ぶ Claude Code 入門ワークショップを公開しました〜！ AWS では今後もパートナー企業様と連携し、最新の AI 開発ツールを体験いただけるイベントを企画してまいります。 著者について 齋藤 拓巳 ソリューションアーキテクトとして幅広いお客様の AWS 導入支援を担当しています。AWS Lambda や Amazon API Gateway などのサーバレスのサービスが好きです。 森 瞭輔 ソリューションアーキテクトとして幅広いお客様の AWS 導入支援を担当しています。好きな AWS サービスは Amazon Connect で、業界問わずコンタクトセンター関連の技術支援も行っています。先日念願だったフルマラソン完走を達成することができました。 登壇者について 山澤 良介 ソリューションアーキテクトとして、業種業態を問わず様々なお客様を支援させて頂いています。前職では主にネットワーク案件を担当していました。好きなサービスは、Amazon Bedrock と AWS Transit Gateway です。休日はスノーボードが大好きなので、シーズン中は毎週スキー場に行っております。 福永 悠斗 NHN テコラスにてデータ・AI 活用を中心にお客様のクラウド活用支援に従事。2025 年には、AWS がグローバルで選出する表彰プログラムである AWS Ambassador に認定。AWS 普及・啓発活動を精力的に推進している。

本記事は 2025 年 12 月 10 日 に公開された「 How to use Sustainability Insights Framework on AWS 」を翻訳したものです。 従来、組織は炭素排出量を追跡し、気候関連レポートを作成する際に、複雑で労働集約的、かつエラーが発生しやすい手動プロセスに直面してきました。このプロセスでは通常、従業員が公共料金の請求書、燃料消費記録、調達文書、出張領収書、施設運営ログなど、異なるソースから無数の時間をかけてデータを収集する必要がありました。大規模なチームは、このデータをスプレッドシートに手動で入力する必要があり、多くの場合、一貫性のない形式や単位を扱い、慎重な変換と検証が必要でした。このプロセスは、異なる地域基準、報告要件、排出係数を扱う多国籍組織にとって特に困難でした。スタッフは、スコープ 1 排出量（所有するソースからの直接排出）、スコープ 2 排出量（購入した電力からの間接排出）、さらに複雑なスコープ 3 排出量（バリューチェーン内のその他すべての間接排出）を手動で計算する必要がありました。各計算には適切な排出係数の慎重な適用が必要であり、これらの係数自体も基準の進化に伴って定期的に更新する必要がありました。 これらの懸念に対処するため、AWS は AWS Solutions Library に Sustainability Insights Framework (SIF) を導入しました。 これは、あらゆる規模の組織が AWS 上で炭素排出量を自動的に追跡し、気候関連レポートを作成するアプリケーションを構築するのに役立つ、柔軟でスケーラブルなソフトウェアプラットフォームです。計算、パイプライン処理、参照データセット用の特殊なコンポーネントを含むモジュラーアーキテクチャを通じて、SIF は組織が膨大な量のサステナビリティデータを処理しながら、すべての計算とレポート全体で精度と一貫性を維持できる高度なアプリケーションを作成することを可能にします。 フレームワークの有効性は最終的に入力データと推定方法の品質に依存し、すべての出力は規制遵守と公式開示のために独立した検証が必要ですが、SIF の自動化されたアプローチは 3 つの重要な利点を提供します：自動化されたデータ処理と計算を通じて人的エラーのリスクを劇的に削減し、増大する報告要件を処理するために動的にスケールし、進化するサステナビリティ基準と規制に容易に適応します。SIF には、それぞれ特定の目的を果たす複数のモジュールが含まれています。これらのモジュールは、アクセス管理、インパクト管理（排出係数管理）、参照データセット管理、計算、データパイプラインを処理します。 ​ SIF の主要機能 アカウント管理 – 組織の報告境界を設定します。フレームワーク内でユーザーアクセス、ロール、権限を制御します。 インパクト – GHG 排出係数などの活動インパクトのカタログを作成します。公開されたソースから排出係数を追加するか、独自のカスタム係数を作成します。 参照データセット – データパイプラインにカスタムデータセットを追加して、データ品質を向上させます。 計算 – ローコードアプローチを使用してカスタム計算を作成します。 メトリクス（KPI） – 処理された活動を自動的に集計するメトリクスを設定します。これらを組織の報告境界と期間に合わせます。 データ取り込みパイプライン – CSV ファイル、AWS Clean Rooms、または入力データコネクタフレームワークを使用した他のソースからデータをインポートします。計算を適用してデータを必要な出力に変換します。 監査可能性 – すべての計算と結果を完全な透明性で追跡および再現します。 マルチテナンシー – シングルテナントまたはマルチテナントモードで動作します。自社の排出量を計算したい組織と、SaaS オファリングを構築する組織をサポートします。必要に応じて、分離されたテナント間でデータを安全に共有します。たとえば、SaaS オファリングを構築する場合、トップティアのお客様は業界固有の数式などの事前定義された計算にアクセスできます。中央テナントは、集中管理のためにこれらの計算を保存します。トップティアテナントは、これらの計算にリモートでアクセスして使用する権限を取得します。 ソリューションアーキテクチャ SIF は、それぞれ特定の機能に焦点を当てた複数のモジュールで構成されています。以下のアーキテクチャ図は、これらのモジュールがどのように連携するかを示しています。 ​ SIFソリューションアーキテクチャモジュール ​ ユーザーは REST API を通じて SIF を操作します。 アクセス管理モジュール は、ユーザーと権限を管理し、グループごとにリソースを分離します。 インパクトモジュール は、データ処理計算中にインパクト係数などのリソースを管理するのに役立ちます。これらは計算モジュールとパイプラインモジュールから参照できます。 参照データセットモジュール は、ルックアップテーブルなどのデータセットを管理するのに役立ちます。これらのデータセットは、計算モジュールとパイプラインモジュールから参照できます。 計算モジュール は、方程式または関数を作成および管理するのに役立ちます。これらの計算は、データ処理計算のために他のモジュールで参照できます。 パイプラインモジュール は、計算用のデータ処理パイプラインを設定するのに役立ちます。 パイプラインプロセッサモジュール は、パイプラインを管理し、パイプライン集計を実行します。 計算機モジュール は、バックエンドコンポーネントとしてパイプライン内の操作を実行します。これには、算術演算とリソースルックアップが含まれます。 SIF は、AWS サービス上に構築されたモジュールのレイヤーとして機能します。各モジュールは特定の機能を処理します。各コンポーネントを見てみましょう： ​ アクセス管理モジュール アクセス管理モジュールは、ユーザーとグループを使用して SIF 内の権限を管理し、リソースを分離します。外部 REST API を通じてユーザーとグループを作成できます。他の SIF モジュールは、アクセス管理モジュールを呼び出して権限を確認します。各テナントは、独自のアクセス管理インフラストラクチャのコピーを取得します。 ​ SIF アクセス管理モジュール図 ​ インパクトモジュール インパクトモジュールは、インパクト関連のリソースを管理するのに役立ちます。排出量追跡などのデータ処理計算中に、計算モジュールとパイプラインモジュールからこれらのリソースを参照できます。インパクトの例としては、モバイルディーゼル燃料消費の二酸化炭素換算量（CO2e）があります。インパクトモジュールは、インパクトタスク API を通じて一度に多くのインパクトリソースを作成できます。すべてのインパクトには、透明性のためのバージョン追跡が含まれています。 ​ SIF インパクトモジュール図 ​ 参照データセットモジュール 参照データセットモジュールは、ルックアップテーブルなどのデータセットを管理するのに役立ちます。排出量追跡などのデータ処理計算中に、計算モジュールとパイプラインモジュールからこれらのデータセットを参照できます。参照データセットの例は、特定の場所の発電ミックス（石炭、原子力、風力）を示すテーブルです。すべての参照データセットには、透明性のためのバージョン追跡が含まれています。 ​ SIF 参照データセットモジュール ​ 計算モジュール 計算モジュールは、方程式または関数を作成および管理するのに役立ちます。排出量追跡などのデータ処理計算中に、他の計算モジュールまたはパイプラインモジュールでこれらの計算を参照できます。計算は、単純（単位変換など）または複雑（ビジネス固有の排出量計算など）にすることができます。すべての計算には、透明性のためのバージョン追跡が含まれています。 ​ SIF 計算モジュール ​ パイプラインモジュール パイプラインモジュールは、パイプライン構成を管理するのに役立ちます。これらの構成は、排出量追跡などの計算用のデータ処理パイプラインを設定します。パイプラインを構成して、実行全体で出力を結合し、メトリクスにグループ化できます。メトリクスは、時間の経過に伴う総排出量などの主要業績評価指標（KPI）を捕捉します。パイプライン構成のドライランをリクエストして、計算機を通じて処理し、作成前にエラーをチェックできます。すべてのパイプライン構成には、透明性のためのバージョン追跡が含まれています。 ​ SIF パイプラインモジュール ​ パイプラインプロセッサモジュール パイプラインプロセッサモジュールは、パイプライン操作を管理します。これには、入力ファイルを提供したときのパイプライン実行の開始と、パイプライン構成で定義された集計の実行が含まれます。パイプラインプロセッサモジュールは、パイプライン実行のステータスも表示します。 ​ パイプラインプロセッサモジュール ​ 計算機モジュール 計算機モジュールは、パイプラインで定義された操作を読み取って実行するバックエンドコンポーネントとして機能します。これには、算術演算と、参照データセットやインパクトなどのリソースのルックアップが含まれます。計算機は、入力値と実行で使用された各リソース（参照データセット、インパクト、計算）のバージョンを含む、すべてのパイプライン操作の監査ログも作成します。 ​ さまざまなモジュールの詳細については、こちらをご覧ください： Architecture diagrams for SIF on AWS ​ 米国環境保護庁（EPA）は、AWS と Sustainability Insights Framework（SIF）を使用して、サブパートW規制に基づく温室効果ガス排出量を管理および報告しています。SIFは、データ収集、分析、報告を容易にする包括的でスケーラブルかつ安全なプラットフォームを提供します。これにより、コンプライアンスが向上し、環境の持続可能性がサポートされます。このユースケースの詳細については、こちらをご覧ください： U.S. EPA Subpart W Greenhouse Gas Reporting with AWS and Sustainability Insights Framework ​ SIF 計算機モジュール ​ SIF の利点 SIF は以下の利点を提供します： 運用効率と自動化 ：データ収集から自動化された排出量計算と報告までの手動作業を削減します。 透明性と監査可能性 ：すべてのデータソース、計算式、結果がバージョン管理され、ログに記録されます。これにより、監査をサポートするトレーサビリティが作成されます。 標準化されたデータモデル ：データ統合と品質保証、さらにレポートの再利用性と高度なデータ分析を可能にします。 高い柔軟性とスケーラビリティ ：排出係数、ワークフロー、計算式を簡単に追加または変更できます。これにより、将来のニーズに柔軟に対応できます。 セキュリティと一貫性 ：データ暗号化や最小権限の原則を含む、AWS セキュリティのベストプラクティスに従います。 ガイダンスをデプロイする手順 SIF のソースコードは GitHub で見つけることができます： Guidance for AWS sustainability insights framework 。2 つのデプロイオプションがあります： CDK を使用して手動でデプロイする。 sif-cli を使用してデプロイする 。SIF コマンドラインインターフェース（sif-cli）は、コマンドラインコマンドを通じて SIF コンポーネントと対話するのに役立つオープンソースツールです。最小限のセットアップで、sif-cli は SIF の管理の多くの複雑さを簡素化します。また、デプロイされたバージョンと最新の SIF リリース間の互換性を確保する機能も含まれています。 デプロイを完了し、SIF を本番環境に移行したい場合は、 Considerations of running SIF in production を確認してください。 ​ カスタマイズガイダンス（さまざまなお客様向け） SIFは、多様なお客様要件を満たすために柔軟に適応します。 業界および地域別の排出係数のカスタマイズ ：製造や輸送などの業界、または米国や日本などの地域に応じて排出係数を管理します。 お客様固有の KPI とレポート形式の追加 ：SIF のカスタマイズ可能な計算式とレポートテンプレート機能を使用して、独自のメトリクスとカスタマイズされたレポート出力をサポートします。 既存のデータレイクとシステムとの統合 ：API と AWS サービス統合を通じて、SIFを既存のデータインフラストラクチャとシームレスに接続します。 組織構造とセキュリティ要件の最適化 ：SIF のマルチテナントアーキテクチャを使用して、複数の部門またはグループ会社間で操作を分離します。必要に応じて詳細なアクセス制御を設定します。 次のステップ SIF を始める準備はできましたか？以下をお勧めします： 初めてのユーザー向け： GitHub リポジトリを探索する – コードベースと要件を理解するために、AWS sustainability insights framework のガイダンスを確認してください。 開発環境をセットアップする – 必要な AWS CLI、CDK、および権限が構成されていることを確認してください。 パイロットデプロイから始める – 最もシンプルなセットアップエクスペリエンスのために、sif-cli ツールを使用して開発環境に SIF をデプロイします。 EPA ユースケースを確認する – 米国環境保護庁がサブパート W 報告のためにSIFをどのように実装したかを研究して、実際のアプリケーションを理解してください。 実装の準備ができている組織向け： データソースを評価する – SIF と統合する必要があるシステムとデータ形式を特定します。 排出係数を定義する – 構成する必要がある業界固有または地域固有の排出係数を決定します。 組織構造を計画する – 報告境界に基づいて、シングルテナントまたはマルチテナントアーキテクチャが必要かどうかを決定します。 本番環境の考慮事項を確認する – 本番環境にデプロイする前に、「 Considerations of running SIF in production 」のドキュメントを読んでください。 サポートを受ける： ベストプラクティスとピアサポートのために、AWS サステナビリティコミュニティに参加してください。 実装ガイダンスとカスタマイズサポートについては、AWS プロフェッショナルサービスをご検討ください。 SIF が使用する基盤となるサービスについては、AWS ドキュメントを確認してください。 パイロットプロジェクトから小規模に始めてアプローチを検証し、プラットフォームの経験を積むにつれてスケールアップしてください。 ​ 結論 AWS Sustainability Insights Framework（SIF）は、AWS上に構築された貴重なツールです。自動化された炭素排出量追跡のためのアプリケーションの設計と実装を加速する基盤となるソフトウェアコンポーネントを提供します。SIF は、自動化、カスタマイズの柔軟性、スケーラビリティ、コスト効率、セキュリティなどの利点を提供するために連携する、さまざまな独立したモジュールで構成されています。 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。 Smita Srivastava Smita Srivastava は、Amazon Web Services のシニアソリューションアーキテクトで、デジタルネイティブ企業のイノベーション促進を支援しています。その経験を活かし、企業の成長を導き、AWS サービスを活用した AI/ML に重点を置きながら、アイデアを現実に変えるサポートをしています。AWS のお客様にサステナビリティソリューションを提案することに深い関心を持っています。仕事以外では、旅行好きで、読書家であり、食の探求者でもあります。

本記事は、2025 年 6 月 20 日に公開された Implement a rollback strategy for Amazon Aurora PostgreSQL upgrades using Amazon RDS Blue/Green deployments を翻訳したものです。翻訳は Cloud Support Engineer の野島 正就が担当しました。 Amazon Aurora PostgreSQL 互換エディション は、高いパフォーマンスと可用性を実現するために設計されたフルマネージドのリレーショナルデータベースエンジンで、更新時のダウンタイムの削減とリスクの最小化を支援する マネージドなブルー/グリーンデプロイ をサポートしています。ブルー/グリーンデプロイは、論理レプリケーションを使用してフルマネージドのステージング環境を作成し、本番環境の変更を安全にデプロイおよびテストできるようにします。ブルー環境は現在の本番データベースです。グリーン環境には必要な更新や変更が含まれていますが、アプリケーションエンドポイントを変更する必要はありません。このアプローチにより、エンジンバージョンのアップグレードやシステムパッチなどの更新に伴うリスクとダウンタイムを最小限に抑えることができます。検証が完了したら、アプリケーションエンドポイントの変更なしにグリーン環境をシームレスに本番環境に昇格させることができます。 非本番環境で入念に計画とテストを行ったとしても、バージョンアップグレード後に予期しない問題が発生することがあります。例えば、新しいスキーマ変更がステージング環境では完璧に動作しても、本番環境では実際のデータパターンの違いやテスト中に実行されなかったアプリケーションクエリが原因でエラーが発生する場合があります。また、実際のトラフィックやワークロードによってパフォーマンスが低下することもあります。このような場合、サービスの安定性を迅速に復旧するためにロールバック計画を用意しておくことが不可欠です。ブルー/グリーンデプロイ機能には現在組み込みのロールバック機能はありませんが、バージョン管理のための代替ソリューションを実装することができます。 この記事では、Amazon RDS ブルー/グリーンデプロイの切り替え後に、セルフマネージドな論理レプリケーションを使用してロールバッククラスターを手動でセットアップし、新しいバージョンとの同期を維持する方法を紹介します。ロールバッククラスターは、元のバージョンに戻す必要がある場合のバックアップオプションとして機能します。 ソリューションの概要 次の図は、このソリューションの高レベルなワークフローを示しています。 スイッチオーバーの前には、2 つのクラスターがあります: ブルークラスター – 既存の本番データベースクラスター グリーンクラスター – ブルークラスターからミラーリングおよび同期されたステージング環境 スイッチオーバー後、3 つのクラスターが存在します: 旧ブルークラスター – 元の本番クラスター (以前のブルークラスター) 新ブルークラスター – 本番クラスターの新バージョンで、ワークロードが実行される場所 (以前のグリーンクラスター) ブループライマリ (ロールバック) クラスター – 旧ブルークラスターのクローンで、新ブルークラスターのデータと同期されたもの (ロールバッククラスターとして使用されます) ワークフローのステップは以下のとおりです: ブルー/グリーンデプロイを作成 します ブルークラスターへのトラフィックを停止し グリーンクラスターへのスイッチオーバーを実行 します ブルー/グリーンデプロイを削除 します 旧ブルークラスターを クローン して、ブループライマリ (ロールバック) クラスターを作成します 新しいブルークラスターからブループライマリ (ロールバック) クラスターへの論理レプリケーションを設定します 新しいブルークラスターへのトラフィックを開始します この記事では、 Amazon Aurora PostgreSQL 互換エディション のメジャーバージョンアップグレード (バージョン 15.10 から 16.6 へ) をシミュレーションします。 制限事項 Aurora ブルー/グリーンデプロイは DDL、シーケンス、マテリアライズドビューのリフレッシュ、ラージオブジェクトの作成や変更、プライマリキーのないテーブルでのデータの更新や削除をレプリケートしません。詳細については、 Amazon Aurora のブルー/グリーンデプロイの制限と考慮事項 を参照してください。 Aurora ブルー/グリーンデプロイはスイッチオーバー後にプライマリクラスターエンドポイントを自動的に管理しますが、以前のバージョンへのロールバックが必要な場合は、アプリケーションまたは DNS レベルでエンドポイントの変更を処理する必要があります。 ロールバッククラスターのセットアップには追加のダウンタイムが発生します。 前提条件 このソリューションを実装するには、以下のコンポーネントが必要です: ブルー/グリーンデプロイのサポート – 既存の Aurora クラスターのバージョンがブルー/グリーンデプロイをサポートしていることを確認します。詳細については、 データベース更新のために Amazon RDS ブルー/グリーンデプロイを使用する および New – Fully managed Blue/Green Deployment in Amazon Aurora PostgreSQL and Amazon RDS for PostgreSQL を参照してください。 ソースデータベースクラスター (この記事では Aurora PostgreSQL v15) で論理レプリケーションを有効にします。 必要に応じてブルー/グリーンデプロイをサポートするバージョンへのインプレースマイナーバージョンアップグレードを 1 回実行します。 AWS CLI による操作。 注意: 論理レプリケーションパラメータを有効にするには、ライターインスタンスの再起動が必要です。詳細については、 Aurora PostgreSQL DB クラスターの論理レプリケーションの設定 を参照してください。 新しいバージョンのデータベース用のクラスターパラメータグループ : 新しいバージョンから古いバージョンへの論理レプリケーションを設定するため、新しいバージョン (Aurora PostgreSQL 16) で論理レプリケーションが有効になっていることを確認する必要があります。以下の AWS CLI コマンドでクラスターパラメータグループを作成し、論理レプリケーションパラメータを有効にします。 aws rds create-db-cluster-parameter-group \ --db-cluster-parameter-group-name pg16-blue-green \ --db-parameter-group-family aurora-postgresql16 \ --description "Parameter group that contains logical replication settings for Aurora PG 16" aws rds modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name pg16-blue-green \ --parameters "ParameterName='rds.logical_replication',ParameterValue=1,ApplyMethod=pending-reboot" Aurora のクローン機能については Amazon Aurora DB クラスターのボリュームのクローン作成 を参照してください。 ブルー/グリーンデプロイの作成 Amazon RDS ブルー/グリーンデプロイは AWS によって管理されます。内部的には、ブルー環境からグリーン環境にリソースを作成してミラーリングし、ネイティブの論理レプリケーションを使用してブルー環境からグリーン環境に DML の変更をレプリケートします。 AWS コマンドラインインターフェイス (AWS CLI) を使用して、以下のコマンドで RDS ブルー/グリーンデプロイを作成できます。ここで source は本番データベースの Amazon Resource Name (ARN) です。以下の RDS コンソールのスクリーンショットは、論理レプリケーションが有効になっている既存のクラスター (ブルークラスター) を示しています。 以下のコマンドを使用して、Amazon Aurora PostgreSQL バージョン 16 のグリーンクラスターを持つブルー/グリーンデプロイを作成します。グリーンクラスターには、事前に作成した論理レプリケーション用の適切なパラメータグループをアタッチする必要があります。 aws rds create-blue-green-deployment \ --blue-green-deployment-name my-blue-green-deployment \ --source arn:aws:rds: {REGION} : {ACCOUNT_NUMBER} :cluster: {CLUSTER_ID} \ --target-engine-version 16.6 \ --target-db-cluster-parameter-group-name pg16-blue-green すべてのインスタンスが利用可能になると、ブルークラスターとグリーンクラスターの両方がアタッチされたブルー/グリーンデプロイが完成します。 トラフィックの停止とスイッチオーバーの実行 グリーンクラスターを昇格させるには、 スイッチオーバー アクションを開始する必要があります。スイッチオーバーを開始する前に、ブループライマリの作成中のデータ整合性を確保するために、ブルークラスターのデータベーストラフィックを停止してください。VPC セキュリティグループを使用して、インバウンドおよびアウトバウンドのデータベーストラフィックをブロックできます。スイッチオーバーが完了したら、RDS ブルー/グリーンデプロイの更新されたラベルを確認してください。 aws rds switchover-blue-green-deployment \ --blue-green-deployment-identifier {BG_RESOURCE_ID} \ --switchover-timeout "300" ブルー/グリーンデプロイの削除 ブループライマリ (ロールバック) クラスターを設定する前に、ブルー/グリーンデプロイを削除する必要があります。RDS ブルー/グリーンデプロイを削除すると、マネージド環境からクラスターが解放され、Amazon RDS ブルー/グリーンデプロイによって生成されたレプリケーションスロット、パブリケーション、サブスクリプション、論理レプリケーションコンポーネントなどのオブジェクトがクリーンアップされます。 aws rds delete-blue-green-deployment \ --blue-green-deployment-identifier {BG_RESOURCE_ID} \ --no-delete-target 次のスクリーンショットに示すように、apg-blue-green-demo (v16.6) と apg-blue-green-demo-old1 (v15.10) の 2 つの独立したクラスターが作成されました。 新しいブルークラスターをクローンしてブループライマリ (ロールバック) クラスターを作成 コンプライアンスや監査の目的で、元のブルークラスターを保持する必要がある場合があります。ロールバッククラスターをセットアップするには: 元のブルークラスターをクローンしてセルフマネージドのブループライマリ (ロールバック) クラスターを作成します 利用可能になったら、クローンしたクラスターで簡単な読み取り専用クエリを実行して、クラスターとデータへのアクセスを確認します ロールバックが必要になった場合に備えて、DNS またはアプリケーションのエンドポイント更新用にブループライマリ (ロールバック) クラスターのエンドポイントを記録します aws rds restore-db-cluster-to-point-in-time \ --db-cluster-identifier "apg15-blue-prime" \ --restore-type copy-on-write \ --use-latest-restorable-time \ --source-db-cluster-identifier "apg-blue-green-demo-old1" \ --db-subnet-group-name " {DB_SUBNET} " \ --vpc-security-group-ids " {VPC_SECUITY_GROUP} " \ --db-cluster-parameter-group-name " pg15-blue-green " aws rds create-db-instance \ --db-instance-identifier "apg15-blue-prime" \ --db-instance-class "db.r6g.large" \ --db-cluster-identifier "apg15-blue-prime" \ --engine "aurora-postgresql" \ --engine-version "15.10" 次のスクリーンショットに示すように、ロールバック先となる新しい復元クラスター「apg15-blue-prime」を作成しました。 ブループライマリ (ロールバック) クラスターのセットアップ ブループライマリのクローンが完了したら、新しいブルークラスター (パブリッシャー) からブループライマリクラスター (サブスクライバー) へのセルフマネージドな論理レプリケーションを設定します。データ同期の問題を防ぐため、書き込みアクティビティやスキーマ変更が行われないようにしてください。 新しいブルークラスター (パブリッシャー) で、クラスターエンドポイントを使用してデータベースに接続し、新しいパブリケーションを作成します: CREATE PUBLICATION publication_name FOR ALL TABLES ; 重要 : 各テーブルにレプリケーションアイデンティティ (プライマリキーやユニークキーなど) があることを確認してください。同じクラスターに複数のデータベースがある場合は、新しく昇格した本番クラスター (新しいブルークラスター) の各データベースに対して以下の手順を繰り返してください。 新しいブルークラスター (パブリッシャー) で、クラスターエンドポイントに接続し、以下のコマンドを使用して ‘pgoutput’ プラグインを使用したレプリケーションスロットを作成します: SELECT pg_create_logical_replication_slot(' replication_slot_name ', 'pgoutput'); ブループライマリクラスター (サブスクライバー) で、以下のコマンドを使用して、データのコピーや新しいスロットの作成を行わずに新しいサブスクリプションを作成します: CREATE SUBSCRIPTION subscription_name CONNECTION 'postgres:// admin_user_name : admin_user_password @ source_instance_URL / database ' PUBLICATION publication_name WITH (copy_data = false, create_slot = false, enabled = false, connect = true, slot_name = ' replication_slot_name '); このコードには以下のパラメータが必要です: subscription_name – サブスクリプションの名前 admin_user_name – rds_superuser 権限を持つ管理ユーザーの名前 admin_user_password – 管理ユーザーに関連付けられたパスワード source_instance_URL – パブリケーションサーバーインスタンスの URL database – サブスクリプションサーバーが接続するデータベース publication_name – パブリケーションサーバーの名前 replication_slot_name – ステップ 2 で作成したレプリケーションスロットの名前 重要 : ブループライマリクラスター上のすべてのパブリケーション (ステップ 1) に対して、この作業を繰り返す必要があります。 ブループライマリクラスターで、以下のコマンドを使用してサブスクリプションを有効にします: ALTER SUBSCRIPTION subscription_name ENABLE ; 重要 : ブループライマリクラスター上のすべてのサブスクリプションに対して、この作業を繰り返す必要があります。 論理レプリケーションのセットアップが完了し、新しいブルークラスターからブループライマリクラスターへのデータフローを確認した後、既存のクラスターエンドポイントを使用して新しいブルークラスターへのトラフィックを再開できます。Amazon RDS ブルー/グリーンデプロイが DNS の変更を自動的に処理するため、アプリケーションは同じエンドポイントを引き続き使用できます。 ブループライマリクラスターへのロールバック ブループライマリクラスター (元のバージョン) にロールバックする必要がある場合は、以下の手順に従ってください。 移行中のデータ整合性を維持するためにアプリケーショントラフィックを停止します (Amazon Aurora VPC セキュリティグループを使用して受信トラフィックをブロックできます) アプリケーションまたは DNS レコードを更新して、ブループライマリクラスターのエンドポイントを指すようにします ブループライマリクラスターのサブスクリプションを削除します 該当する場合はシーケンス値を手動で更新します この切り替えは自動ではありません。ブループライマリクラスターはマネージドサービスの管理下にないためです。実行時のエラーを最小限に抑えるために、ロールバック手順のランブックまたは自動化スクリプトを作成することをお勧めします。 この戦略はロールバックオプションを提供しますが、ブループライマリクラスターのセットアップ時に追加のダウンタイムが発生します。このアプローチを実装する際に考慮すべきトレードオフであり、本番環境に移行する前にステージング環境で十分にテストすることを推奨します。 クリーンアップ 本番環境では、すべてのアプリケーションが正常に移行されたことを検証する間、新しいブループライマリクラスターを維持する必要があります。両方の環境を同時に稼働させておくことで、新しいインフラストラクチャで何か不整合や予期しない動作が発生した場合にロールバックできることが保証されます。コンプライアンス目的で旧ブルークラスターをバックアップした後、コスト削減のためにクラスターを削除できます。すべてのクラスターは削除されるまで課金されます。 テスト目的でこれらのリソースを作成した場合は、追加料金が発生しないように、すべてのクラスター (ブルー、グリーン、ブループライマリ) を削除する必要があります。データベースクラスターをクリーンアップするには、以下の手順を実行してください。 リードレプリカインスタンスがあれば、 それぞれを削除します。 プライマリインスタンスを削除します。 データベースクラスターを削除します。 まとめ この記事では、Amazon RDS ブルー/グリーンデプロイを使用してデータベースバージョンのアップグレードを行う際のロールバック戦略の作成方法を紹介しました。安全性を高めるために、ロールバック戦略として論理レプリケーションを設定しました。ブルー/グリーンデプロイは、ミラーリングされた同期済みのデータベースステージングバージョンの作成、ガードレールチェックの実行、スイッチオーバーの実施、DNS 変更の自動化など、多くの複雑なタスクを自動的に処理します。しかし、本番データベースの変更には、アプリケーションの非互換性などのリスクが伴う可能性があります。ロールバッククラスターを設定しておくことで、アップグレード後に問題が発生した場合に迅速にフォールバックできる追加の安全策が得られます。問題が解決されるまで、以前の本番バージョンに戻すことができます。 本番ワークロードを切り替える前に、本番レベルの負荷をかけた状態で新しいデータベースバージョンに対してアプリケーションを十分にテストしてください。アプリケーションが完全に互換性があり、パフォーマンスが安定していることを確認してください。これにより、ブルー/グリーンデプロイの切り替え後にアプリケーションの問題やパフォーマンス低下が発生する可能性を大幅に減らすことができます。このロールバック戦略を実装する前に、 RDS ブルー/グリーンデプロイ の仕組みと機能について確認することから始めることをお勧めします。 Chirag Dave Chirag は マネージドな PostgreSQL を専門とする Amazon Web Services のプリンシパルソリューションアーキテクトです。セキュリティ、コスト、パフォーマンス、信頼性、効率的なオペレーション、アーキテクチャについてのベストプラクティスを通じてお客様と技術的な関係を構築しています。 Kovan Chandra Kovan は PostgreSQL データベースを専門とする Amazon Web Services (AWS) のテクニカルアカウントマネージャーです。エンタープライズサポートのお客様と協業し、クラウドにおけるカスタマージャーニー、セキュリティ、レジリエンシー、コスト削減、およびオペレーショナルエクセレンスの改善に取り組んでいます。 Daxeshkumar Patel Daxeshkumar は Amazon Web Services (AWS) のソリューションアーキテクトであり、主要なクラウド案件においてお客様やパートナーと密接に連携しています。概念実証（PoC）プロジェクトの設計・提供、実装支援、および AWS サービスを活用したアプリケーションの構築・移行を支援しています。データ処理、分散コンピューティングソリューション、そしてお客様が AWS クラウドを効果的に活用できるようにすることに注力しています。 Kamal Singh Kamal は Amazon Web Services (AWS) のシニアデリバリーコンサルタントです。データベースの移行およびモダナイゼーションプログラムに重点を置き、お客様やパートナーの AWS クラウドへの移行を支援しています。 Jinesh Shah Jinesh は Amazon Web Services (AWS) のデリバリーコンサルタントです。レガシーデータベースおよびアプリケーションのモダンな AWS プラットフォームへの移行を支援しています。データ処理、分散コンピューティングソリューション、そしてお客様が AWS クラウドを効果的に活用できるようにすることに注力しています。

みなさん、こんにちは。ソリューションアーキテクトの田村です。 サイバー攻撃の脅威は質的に変化しています。AI の進展により高度な技術を持たない攻撃者でも大規模な攻撃を実行できるようになり、攻撃の参入障壁が大きく下がっています。サプライチェーン攻撃も急拡大しており、正規の開発プロセスそのものが攻撃経路として悪用されるケースが増えています。（参考：「 サプライチェーン攻撃への防御策: Chalk/Debug 侵害と Shai-Hulud ワームの対応事例から 」「 最近の npm サプライチェーン攻撃への対応から AWS Security が学んだこと 」） こうした状況を受け、AWS Japan パブリックセクター技術統括本部では2026年4月よりセキュリティワークショップを月次で開催してきました。4月・5月は特に「ランサムウェア対策」をテーマとしました。ランサムウェアは侵入後に長期間潜伏し、業務データだけでなくバックアップ自体も暗号化する高度な攻撃が増加しており、多くの組織にとって喫緊の課題であるためです。第1回は脅威検知、第2回は統合セキュリティ管理にフォーカスしました。 さらに直近では、Claude Mythos に代表されるフロンティア AI モデルの登場を背景に、これを悪用したサイバー攻撃への対策が急速にクローズアップされています。金融庁は2026年5月22日に「 フロンティアAIによる脅威変化を踏まえた金融機関等の短期的な対応 」を発出し金融機関に対応を要請、厚生労働省も同日に医療機関を含む重要インフラへの AI を活用したサイバー攻撃について 対策強化の議論を開始 しています。こうした状況を踏まえ、6月12日（金）開催予定の第3回では急遽「Claude Mythos の登場で変化する脅威への対応」をテーマとし、生成 AI 時代の脅威動向を座学で解説するとともに、ハンズオンではアプリケーションの脆弱性管理を体験いただきます。 本記事では第1回・第2回の開催レポートと、今後の取り組みについてご紹介します。 ワークショップの概要 本ワークショップは「ランサムウェア対策」を共通テーマとし、第1回と第2回で異なる AWS セキュリティサービスにフォーカスした内容となっています。講師はシニア セキュリティ ソリューションアーキテクトの中島 章博が務め、前半の座学で近年の脅威動向やセキュリティ対策の考え方を解説し、後半はハンズオン形式で実際に AWS のセキュリティサービスを体験していただきました。 ランサムウェア対策を考える上では、NIST Cybersecurity Framework（CSF）の識別・防御・検知・対応・復旧という各段階に沿って対策を整理することが有効です。 AWS にはこれらの各段階で活用できるセキュリティサービスがあります。 本ワークショップでは「検知」を担う Amazon GuardDuty と、「識別」「検知」を担う AWS Security Hub にフォーカスしました。 以下、各回の内容をご紹介します。 第1回: Amazon GuardDuty で実現する脅威検知（2026年4月10日） Amazon GuardDuty とは Amazon GuardDuty は、AI と ML に AWS と主要なサードパーティーが提供する統合脅威インテリジェンスを組み合わせて使用し、AWS アカウント、ワークロード、およびデータを脅威から保護します。ランサムウェア、バックドア、暗号通貨マイナー、トロイの木馬などのマルウェアを検出することもできます。 ハンズオン概要 参加者一人ひとりにワークショップ専用の AWS サンドボックス環境が払い出されます。この環境にはあらかじめ悪意のあるアクティビティを模したシナリオが構築されており、GuardDuty が実際に検出結果（Findings）を生成した状態になっています。参加者はセキュリティ担当者の立場で、攻撃（Attack）→ 検知（Detect）→ 調査・対応（Respond）の一連の流れを体験します。 ハンズオンは「基礎・設定」「脅威対応シナリオ」の2パートで構成されています。 前半の基礎・設定パートでは、GuardDuty の有効化と検出結果の読み方、自社固有の脅威 IP リストを GuardDuty に登録するカスタム脅威リストの構築、Amazon Simple Storage Service (Amazon S3) にアップロードされたマルウェアを自動検知する Malware Protection for Amazon S3、Amazon Elastic Compute Cloud (Amazon EC2) などのランタイムアクティビティを監視する Runtime Monitoring の設定、Amazon EventBridge と Amazon Simple Notification Service (Amazon SNS) を組み合わせた脅威通知の仕組みづくりを行います。 後半の脅威対応シナリオでは、ランサムウェア攻撃を模した「攻撃シーケンス検出結果への対応」がメインシナリオです。このシナリオでは、攻撃者が AWS Identity and Access Management (IAM) 認証情報を窃取し、Amazon S3 バケットのポリシーを変更してデータを流出させた後、証拠隠滅のためにログを無効化しバケットを削除する、という多段階の攻撃が再現されています。GuardDuty はこれらの個々のシグナルを相関分析し、「攻撃シーケンス」として一つの重大な検出結果にまとめます。参加者は MITRE ATT&CK の戦術マッピングを手がかりに攻撃の全体像を把握し、AWS CloudTrail で攻撃者の行動を時系列で追跡した上で、IAM 認証情報の無効化や Amazon S3 バケットポリシーの修正といった封じ込めを実践します。 このほか、侵害された Amazon S3 バケットへの対応、IAM 認証情報が流出した場合の対応、Amazon EC2 上で Runtime Monitoring が検出した不正プロセスへの対応、Amazon Elastic Block Store (Amazon EBS) ボリュームのマルウェアスキャンと対応など、実際のインシデントで遭遇する代表的なシナリオに取り組みます。 「GuardDuty をオンにしてはいるが、検出結果が出たときに何を見ればいいのかわからない」「インシデント発生時にどこから調査を始めればよいかわからない」という方にとって、実践的なインシデント対応を安全な環境で体験できる内容です。ワークショップ教材は「 Amazon GuardDuty & Amazon Detective ワークショップ 」として公開しています。 第2回: AWS Security Hub で実現する統合セキュリティ管理（2026年5月15日） AWS Security Hub とは AWS Security Hub は、お客様の重大なセキュリティ問題に優先順位を付け、規模に応じた対応を支援して環境を保護します。クラウド環境全体の可視性を一元化することで、セキュリティ運用を統合します。シグナルを相互に関連付け、実用的なインサイトへと充実させることで重大な問題を検出し、効率的な対応を可能にします。ランサムウェア対策の「予防」の観点から、自環境の弱点を事前に把握し改善しておく上で重要な役割を果たします。 ハンズオン概要 第2回のハンズオンでは、Security Hub が複数のセキュリティサービスの検出結果を相関分析して検出する「露出（Exposure）」の概念を中心に、セキュリティポスチャの改善サイクルを体験しました。 ハンズオンの前半では、Security Hub の概要と露出の仕組みを学びます。露出とは、設定ミス（Misconfiguration）、ネットワーク到達可能性（Reachability）、ソフトウェア脆弱性（Vulnerability）、機密データの存在（Sensitive Data）といった複数の特性を Security Hub が自動的に相関分析し、「このリソースは攻撃者に悪用される可能性が高い」と判断した検出結果です。参加者は実際に露出の検出結果を確認し、潜在的な攻撃パスを視覚的に把握した上で、以下のような修復作業を実践しました。 ネットワークアクセスの制限 : セキュリティグループで不要なポート（Telnet など）を閉じ、SSH アクセスを Amazon Virtual Private Cloud (Amazon VPC) 内に限定する ソフトウェア脆弱性へのパッチ適用 : Amazon Inspector が検出した既知の CVE に対し、AWS Systems Manager Session Manager 経由でパッチを適用する IAM 権限の最小化 : 過度に広範な権限を持つインスタンスプロファイルを特定し、IAM Access Analyzer を活用した最小権限への道筋を確認する 構成の改善 : IMDSv2 の強制適用により、SSRF 攻撃による認証情報窃取のリスクを排除する 後半では、Security Hub の自動化ルール（検出結果に対するアクションの自動実行）、Automated Security Response ソリューションによる修復の自動化、Security Hub と Slack を連携した通知の仕組みなど、運用に直結する内容に取り組みました。 「Security Hub を有効にしたものの、大量の検出結果をどう優先順位付けすればよいかわからない」という方にとって、露出を起点に最もリスクの高い問題から対処していくアプローチを実感いただける内容です。ワークショップ教材は「 Security Hub ワークショップ 」として公開しています。 参加者からのフィードバック 両回とも多くの方にご参加いただき、ご好評をいただきました。 「実際に手を動かすことで理解が深まった」「自組織での活用イメージが湧いた」「普段から利用しているサービスだが、何を見ればいいのか理解できるようになった」など、日々の運用に直結する学びを得られたというフィードバックをいただきました。 まとめと今後の取り組み 本ワークショップシリーズは、皆様のご要望に応じて今後も継続的に開催予定です。次回（2026年6月12日）は「Claude Mythos 時代の脅威と対応」をテーマに、フロンティア AI の普及により変化しつつある脅威動向を座学で扱い、ハンズオンではアプリケーションセキュリティワークショップとして Amazon Inspector を用いた脆弱性管理を体験いただきます。さらに 7月2日（木）には第4回として、お客様自身がフロンティア AI を使って攻撃者より先に脆弱性を検出して対策ができる  AWS Security Agent をテーマに開催予定です。ご関心ある方は担当営業にご連絡ください。 ワークショップで学んだ内容を次のアクションにつなげるために、AWS では以下のようなセキュリティ支援を提供しています。 AWS セキュリティ成熟度モデル : 組織のセキュリティ対策の現在地を把握し、次に取り組むべき施策を明確にするフレームワークです。脅威検知やポスチャ管理が自組織ではどの段階にあるのか、確認してみてはいかがでしょうか。 Security Health Improvement Program (SHIP) : データ主導でセキュリティ改善を進めるための無償プログラムです。 脅威モデリングワークショップ : 設計段階からセキュリティを組み込みたい方に向けて、サンプルシステムを対象としたワークショップ形式のほか、実際のワークロードを対象とした個別支援も実施しています。 上記の支援にご興味がある方は、担当の AWS アカウントチームまでお気軽にお声がけください。 著者 田村 健祐 (Kensuke Tamura) — AWS Japan, Public Sector, Solutions Architect 梅田 昌太 (Shota Umeda) — AWS Japan, Public Sector, Sr Solutions Architect

AWS テクニカルインストラクターの杉本圭太です。 このブログは 2024 年 4 月に投稿した AWS 初学者向けの勉強方法 6 ステップ！2024 年版！ を 2 年ぶりにアップデートした内容です。この 2 年間で公開された新しい情報の追記や、変更のあったリンクの最新化を行いました。 みなさんは「AWS を勉強したいんだけど何から勉強すればよいだろう。どこかに勉強方法がまとまってないかな ?」「同僚や部下に AWS の勉強を促しているけど、ちょうど良い教材とか無いかな ?」と思ったことはありますか ? もしくはみなさんの周りでそういう悩みを抱えている方はいませんか ? このブログはそういった AWS を勉強する際の悩みを抱えた AWS 初学者の方や、AWS 初学者を育成する立場にある方を対象にしています。 どのような段取りで知識を深めていけばよいのか、この勉強方法がなぜおすすめなのか、疑問点やハマりどころに直面した際にどこのサイトをチェックすればいいのかなど、納得しながら勉強を進められるように具体的な情報を含めながら 7 ステップで紹介していきます。 ステップ 1. クラウドや AWS の概要を知るには ? ステップ 2. お客様の AWS 活用事例を知るには ? ステップ 3. AWS が提供するサービスの全体像を掴むには ? ステップ 4. AWS の各サービスに詳しくなるには ? ステップ 5. 実践的なスキルを身につけるには ? ステップ 6. 最新情報をキャッチアップするには ? ステップ 7. さらにレベルアップするには ? 紹介するサイトの量は多いですが 全てを順番に完了させる必要はありません 。自分に足りないところや興味あるところを確認すれば大丈夫です。また、 新しいことを学ぶときに一度で完璧に覚えられる方はほとんどいません 。そのため、 何度もくり返しこのブログを見直していただく のがおすすめです。 それでも量が多いと感じる方は、各ステップの「★杉本イチオシ」の目印をつけている部分からまず目を通してみてください ! ステップ 1. クラウドや AWS の概要を知るには ? 最初は AWS とは何か、そしてなぜ利用されていて、ビジネスでどのような効果をもたらしているかを確認してみましょう。メリットを知ることで、「自分も AWS を使いこなせるようになるために勉強してみよう !」と感じやすいかと思います。 AWS の用語やサービスの詳細を学ぶための資料は後のステップで紹介していきますので 、このステップでは概要を把握するだけでも大丈夫です。 1-1. クラウドとは – AWS システム開発をするために必要なサーバーやネットワーク機器などを自社で保有して運用する形態をオンプレミスと呼びます。それに対して AWS はクラウドと呼ばれるサービスを提供しています。これはシステム開発者が自社でサーバーやネットワーク機器を保有せずに、必要に応じてクラウドサービス提供者の データセンター から、インターネットを経由してサーバーリソースなどを利用できるサービスです。 そもそもクラウドのメリットは何かを知りたい方 はこちらを確認してみましょう。また AWS とは のページの中段では、AWS のデータセンターがどの地域にあるかを地球儀を回しながら確認できます。 1-2. AWS のクラウドが選ばれる 10 の理由 ★杉本イチオシ AWS がお客様に選ばれる理由に関して、図や表を用いて読みやすい形式で説明されています。「必要な時に、必要な分だけ、低価格で IT リソースを調達可能」「サービスを開始してから〇〇回以上の値下げを実施」など AWS のポイントがシンプルな言葉で説明されていて、分量もちょうど良いです。 ステップ 2. お客様の AWS 活用事例を知るには ? 事例を見ると、みなさんが普段使っている様々な企業のサービスが実は AWS を利用していることを知れて単純に面白いですし、自分たちがどのように AWS を使えるかの参考にもなります。 事例は量も多いので、まずは興味があるものがあれば目を通すだけでも良いです。 ただし AWS の知識がついた後にあらためてお客様事例を見るとさらに理解が深まりやすいので、この後の学習中にも適宜確認してみてください。 2-1. お客様のクラウド導入事例 ★杉本イチオシ 多種多様な業種や企業規模のお客様がどのようにクラウドを活用いただいているのかが網羅的にまとまっています。フィルター条件を適用することで、 エンタープライズなどのセグメント別、金融サービスなどの業種別、クラウド移行やサーバーレスなどのユースケース別で見ることもできます。 2-2. AWS Summit Japan セッション動画 AWS Summit とは AWS について学んだり、新しいつながりを築くために世界中で開催されている無料のイベントです。日本でも毎年行われていて、AWS やお客様によるセッション、ワークショップなど様々なコンテンツが用意されています。多くのセッションは動画でも公開されております。特にお客様事例セッションは、お客様のシステムにかける “熱意” が伝わってきますし、ビジネス上の課題を AWS でどのように解決していくのかのストーリーが分かりやすいです。 YouTube の再生リストとして公開されているものをいくつか挙げておきます。 AWS Summit Japan 2025 のアーカイブ – YouTube 再生リスト AWS Summit Japan 2024 のアーカイブ – YouTube 再生リスト ステップ 3. AWS が提供するサービスの全体像を掴むには ? ここまでのステップで資料に目を通して、AWS が提供するサービス数の多さに驚いた方も多いかと思います。 AWS のクラウドが選ばれる 10 の理由 でも記載されている通り、AWS はお客様の満足度を何よりも大事にしています。そのため AWS では 200 を超えるサービスを提供しておりますが、その 90% 以上のサービスや機能は全世界のお客様からのリクエストをもとに実装されています。 とはいえサービスが多いと初学者の方は何から始めれば良いかわからずに難しいと感じやすいはずです。そのためまずは AWS のサービス群の全体を俯瞰しながら理解していき、その後にそれぞれの詳細を調べていくのが有効です。そこでこのステップでは、 AWS Skill Builder で無料で視聴できる全体像の把握に役立つデジタルトレーニングなどを紹介します。 AWS Skill Builder とは ? AWS Skill Builder は、AWS の様々な学習コンテンツがまとまっているサービスです。無料で作成できる AWS Builder ID を用意すれば、多くの無料コンテンツを利用できます。さらに有償のプランを選択すれば、AWS 認定の模擬試験、 実践的な AWS スキルを身につける様々な体験型の学習コンテンツ などが利用できます。この後のステップにも AWS Skill Builder に含まれるコンテンツを紹介しています。AWS Skill Builder の概要を知りたい方は こちらのページ 、有償のプランについて知りたい方は こちらのページ を確認してみてください。 3-1. Cloud for Beginners (日本語実写版) AWS について理解するには IT の基本的な知識も必要です。そのため基本用語などを知りたい場合はこちらのデジタルコースがおすすめです。このコースではキャパシティプランニングや CIDR といった IT に関する専門用語について適宜解説しながら進行しますので、AWS に関心がある非 IT 領域の方や学生の方におすすめです。ウェブサービスや AWS クラウドがどういうものなのかといった、AWS の学習をはじめる際に前提となる知識を効率よく学ぶことができます。また、コースの後半ではいくつかの代表的な AWS サービスについてとりあげ、その概要について紹介します。もしこのコースが難しい場合は、Skill Builder の IT 基礎 (日本語実写版) コースや、 IT パスポート試験 、 基本情報技術者試験 の範囲などを併せて勉強してみてください。 3-2. AWS Cloud Practitioner Essentials (日本語実写版) ★杉本イチオシ このコースは AWS を全体的に理解したい方を対象としている基礎レベルの内容です。日本の AWS 認定インストラクターが英語版の内容を日本語で収録しております。技術職の方に限らず、AWS に関わる営業職の方などにも把握していただくのがおすすめの内容です。 3-3. 目的別クラウド構成と料金試算例 代表的な構成とその試算例が幅広く紹介されていますので、自分たちが実現したいシステムではどのような AWS サービスを使えば良いのか、そしてどれくらいの金額になるのかの参考になります。 料金の見積りは、 AWS 料金見積りツール も知っておくと役に立ちます。アクセスした後に画面の右上で言語を変更し、「見積りの作成」ボタンを押すと AWS アカウントがなくても無料でサービスとリージョンを指定した見積りが可能です。 ステップ 4. AWS の各サービスに詳しくなるには ? これまでのステップでは、AWS 全体に関する説明をしてきました。おそらく、各サービスの概要を知るにつれ、知りたいことや疑問点などが出てくると思います。例えば、「サービス A とサービス B は似ているように見えるが違いは何なのか」「サービス C の料金体系はどうなっているのか」「サービス D の設計時の制限値などは無いのか」などが気になった場合はどうすれば良いでしょうか ? そこで AWS の各サービスを深掘りしていくための資料がこちらです。最初から全て読むのは大変なので、 必要な時に都度確認する ような使い方でも大丈夫です。 4-1. AWS サービス別資料 (AWS Black Belt オンラインセミナー) ★杉本イチオシ 真っ先におすすめするのが、「AWS サービス別資料」です。サービスや機能ごとに用意されていて、要点をギュッと凝縮しつつサービス設計時の勘所が押さえられています。難しい専門用語も比喩表現を交えて分かりやすく解説されているため、気になるサービスがある場合はこちらから探して目を通してみましょう。資料の前半が基本の説明になっていることが多いので、初めのうちは前半を確認するだけでも良いかもしれません。 4-2. AWS 用語集 AWS の勉強をしていると知らない単語がどんどん出てくることもあると思います。そんな場合この用語集があることを知っていると、辞書を引くような感覚でその単語の概要を把握できるので便利です。 4-3. AWS ドキュメント 「サービス別資料」でサービスの概要を理解した後に、より詳細にサービスの仕様などを理解したい場合は「AWS ドキュメント」を参照しましょう。HTML 形式で見やすい目次が画面左に表示されるので、知りたい情報に簡単にアクセスできます。 例えば Amazon EC2 ユーザーガイド 、 Amazon S3 ユーザーガイド のようなサービスごとのユーザーガイドや、開発者ガイド、API リファレンス、そしてチュートリアルなどもドキュメントとして用意されています。他にも サービスエンドポイントとクォータ に、サービスの使用制限などが記載されています。しかし専門的で詳細な記述も多いため、いきなりこれをスラスラと読むのは難しいかもしれません。このブログで紹介している他の情報も併せながら、徐々にこのドキュメントを元に仕様の確認や設計判断ができるように目指していただくと良いです。 4-4. よくある質問 各サービスを勉強していて疑問が出た時に最初にアクセスすると良いサイトで、多くの方が気になる質問とその回答の一覧が各サービスごとに用意されています。記載内容にはサービスの特徴などの基本的なことから使用できるオプションなどの詳細まで網羅的に含まれています。 4-5. クラウドコンピューティングコンセプトのハブ クラウドコンピューティングコンセプトのハブでは、クラウドコンピューティング関連の用語に関して深く分かりやすく説明された記事を閲覧して検索できる場所です。例えば ゼロ ETL とは何ですか ? の記事では、ゼロ ETL の概要説明だけでなく、解決する課題やメリット、そしてユースケースまで網羅的に説明されています。他にも、機械学習とは ? DevOps とは ? など、改めて正しく深く理解したい用語が出てきた際にチェックしてみましょう。 生成 AI とは何ですか ? のような新しい用語の解説記事もあります。 4-6. AWS re:Post AWS re:Post は AWS コミュニティの方々向けの Q&A サービスです。AWS に関する技術的な Q&A を検索したり、専門領域ごとのコミュニティグループに参加することができます。中でもおすすめは AWS 情報センター です。AWS 情報センターでは「〇〇というエラーを解決する方法を教えて下さい」「〇〇を設定する方法を教えて下さい」などの実装に関する Q&A が豊富に記載されていますので、サービスを実装してハマりどころに直面した時に参照しましょう。 ステップ 5. 実践的なスキルを身につけるには ? 「習うより慣れろ」という言葉があるように、手を動かすことは学習定着率を高める上で非常に有効な方法です。勉強したサービスをハンズオンなどで実際に触ってみることで、知識と実践を結びつけて理解しながらスキルとして身につけやすいです。「どのサービスが入門に適しているのか分からない」「構築する際の手順書が欲しい」「できれば簡単なものから始めたい」という方に役立つ情報を紹介します。 5-1. AWS の API を理解しよう ! 初級編 ~ API の仕組みと利用方法を理解しよう ★杉本イチオシ AWS のハンズオンをする前にまず知っておいてほしいのが、「AWS は API で操作する」ということです。これを知っておくと、この後のハンズオンでマネジメントコンソールを使ってボタンを押した時に何が起きているのかを把握しやすくなります。また開発者の方であれば AWS CLI や AWS SDK を使う機会も出てくると思いますが、その場合も AWS の API を理解しておくのは重要です。 5-2. AWS Cloud Quest / AWS SimuLearn ★杉本イチオシ AWS Cloud Quest と AWS SimuLearn はどちらも AWS Skill Builder にある 実践的なシナリオで進める学習コンテンツ です。自分で AWS アカウントを用意せずにできる AWS の演習に加えて、ゲームやシミュレーション要素が組み合わさったものです。それぞれ無料で使用できる範囲もあり、その範囲であれば実施できる演習の内容は同じです。 ゲーム要素も含めて学習を楽しみたい方は AWS Cloud Quest から、手軽に演習を試したい場合は AWS SimuLearn から始めてみるのがおすすめ です。 AWS Cloud Quest は 3D ロールプレイングゲームを進めながら AWS を実際に操作するミッションをクリアしていき、コレクション要素もあるため初学者でも楽しく AWS を学べます。ロール毎や課題毎に様々なサービスを利用しながらソリューションを構築していくため、AWS のどのサービスから学習を始めればよいか悩んでいる場合でもおすすめです。 初級である AWS Cloud Quest: Cloud Practitioner と AWS Cloud Quest: 生成 AI プラクティショナー は日本語版が無料で利用可能です。詳細な説明は ゲームベースで学習できる AWS Cloud Quest: Cloud Practitioner が日本語で学習可能になりました の記事をご確認ください。 AWS SimuLearn は演習ごとにコースが独立しているため、AWS Cloud Quest とは違って「この演習だけを試してみたい !」というときに気軽に立ち上げてチャレンジできます。こちらは生成 AI を搭載した仮想顧客とのチャットで課題のヒアリングやソリューション提案のプロセスを体験した後に AWS の演習を行うのが特徴です (現在、AI との対話は英語のみ)。 SimuLearn には数多くのコースが用意されているのですが、初級に位置する合計 20 コースは無料で利用可能です。これらのコースは AWS SimuLearn: Cloud Practitioner (日本語) や AWS SimuLearn: Generative AI Practitioner (日本語版)  という学習プランからまとめて確認ができます。 さらに AWS を触り始めたばかりのときに心配になるのが「この進め方で本当にあってる ?」という部分ではないでしょうか。一人で進めるのが心配という方は [初級] やってみた – クラウドと AWS サービス実践 (解説動画付き) を見ながら SimuLearn を進めてみましょう。「やってみた」シリーズでは、日本人のテクニカルインストラクターによるコンセプトパート、実践パート、DIY パートの解説が含まれており、より AWS サービスの操作や仕組みについて理解を深めることができます。 5-3.  AWS アカウント作成の流れ – AWS AWS Skill Builder の Cloud Quest や SimuLearn、その他の演習は用意された AWS アカウントで進められますが、決められた手順の範囲しか操作できません。もっと自由に AWS を使ってみたいという方は、自分で AWS アカウントを作成してこの後紹介するハンズオンやワークショップを実施できます。AWS 無料利用枠もあるので有効に活用してみてください。こちらの 無料利用枠の紹介記事 の説明にもありますが、2025 年 7 月から始まった新しい無料利用枠では無料アカウントプランというものがあります。これは使用できるサービスに制限はありますが、プランを切り替えるまでは料金は発生しないため、リソースを削除し忘れて課金されてしまうのでは ? という不安がある方も安心して試しやすいかと思います。 AWS アカウントとルートユーザー AWS アカウントを作成した時に設定したメールアドレスとパスワードはルートユーザーと呼び、その AWS アカウントの全ての操作権限を持ちます。そのため AWS アカウントを作成した後、 ルートユーザーに多要素認証 (MFA) を設定 しておきましょう。 またルートユーザーを普段使いすることは非推奨とされており、その代わり AWS アカウント内で必要な権限のみを割り当てて使用できる IAM ロールや IAM ユーザーを作成して使用するようにしましょう。IAM ロールの使用が推奨ではありますが、別の ID 管理の仕組みと連携などが必要になるため、個人の勉強用途であれば AWS Hands-on for Beginners – ハンズオンはじめの一歩: AWS アカウントの作り方 & IAM 基本のキ を見て IAM ユーザーを使うのが始めやすいかもしれません。その場合 IAM ユーザーにも多要素認証 (MFA) を設定 できるので実施しておきましょう。 5-4.  JP Contents Hub JP Contents Hub は AWS に関する日本語のハンズオン・ワークショップ情報を一覧化しているウェブサイトです。このウェブサイトでは 日本語で手順が用意されたハンズオン を限定して掲載していますので、英語の手順だと難しいと感じる方におすすめです。トップページの左側からカテゴリ別にハンズオンを選ぶこともできますし、特定のサービス名やキーワードで検索することもできます。そしてハンズオン一覧は継続的にアップデートされます。JP Contents Hub に関する詳細な説明は AWS 日本語ハンズオンまとめ JP Contents Hub のご紹介 の記事をご確認ください。 ステップ 6. 最新情報をキャッチアップするには ? AWS のサービスは改善のサイクルが非常に早いため、サービスを使用する側も常に知識の鮮度を保つ必要があります。また、最新技術を知ることで設計の幅を広げることもできます。このステップでは各サービスの最新情報のキャッチアップに役立つ情報を紹介しますので、ブックマークしておいて定期的に確認してみてください。 6-1. Amazon Web Services ブログ (日本語) ★杉本イチオシ このブログも掲載している Amazon Web Services ブログです。RSS 登録が可能です。AWS のサービスに関するアップデートを詳しく説明した記事など AWS 関連の様々な情報を掲載していますが、特に 週刊 AWS は要チェックです ! 前の週に公開された主要なアップデートや、日本のお客様に興味を持っていただけそうなものをピックアップして紹介しているので、「ちょっと先週は忙しくて AWS の最新情報を追いきれてない…」という方の助け舟になりますし、ダイジェスト版として重宝いただけると思います。最近はアップデート量が多い生成 AI 関連の情報をまとめた「週刊生成 AI with AWS」もあります。また、関連するブログとして AWS Startup ブログ と AWS JAPAN APN ブログ もありますので合わせてチェックしてみてください。 英語ではありますが AWS Blogs には、より多くの情報がありますので興味あればこちらもどうぞ。 6-2. AWS の最新情報 (日本語) AWS の各サービスに関して、「〇〇サービスが東京リージョンで利用可能になりました」などの最新のアップデートが掲載されています。機能拡張など設計の改善に役立つ情報もありますのでチェックしましょう。なお、本サイトは RSS 登録が可能ですので、RSS リーダーのスマートフォンアプリを利用することで、更新情報を自動的に取得することもできます。 こちらも英語の What’s new with AWS には、より多くの情報が掲載されております。 6-3. builders.flash ★杉本イチオシ デベロッパー向けのウェブマガジンで、様々なレベルの方に向けてバラエティに富んだ記事構成になっています。 AWS のアーキテクチャ図を描きたい ! でもどうすれば良いの ? などの AWS の設計や開発に関する記事だけでなく、有識者に勉強方法をインタビューする ネットワークの勉強方法を聞いてみた。 といった初学者向けの記事などもあります。メンバー登録することでハンズオン記事をためす際に使える無料クーポンが配布されるなど様々な特典が用意されていますので、ぜひメンバー登録をしましょう。 6-4. SNS ( X / Facebook / YouTube ) オンラインイベントの配信開始などリアルタイム性のある内容に関しては X や Facebook をフォローすると情報を追いやすくなりますし、ブログ更新やセミナーの資料公開などの通知系の内容も投稿されています。また、様々な基調講演の内容なども YouTube で随時アップされますので、こちらもチャンネル登録しておきましょう。 6-5. AWS Builder Center ★杉本イチオシ ビルダー向けのコミュニティや AWS 製品チームへのフィードバックなどができる場をまとめたものとして 2025 年 7 月に公開されました。 Topics で興味あるサービスの記事を探したり、気になる Spaces で情報を受け取ったりできます。 AWS Builder ID があれば自分で情報を発信することや Wishlist で 新機能や改善の要望を直接送れます 。詳細は AWS Builder Center のご紹介: AWS ビルダーコミュニティの新しいホーム にも記載されています。 ステップ 7. さらにレベルアップするには ? これまでに紹介した勉強方法を実践して基礎が固まってきた方、高度な情報にアクセスしたくなった方向けの情報も最後に紹介します。 7-1. AWS Well-Architected Framework ★杉本イチオシ クラウドの設計原則や、ベストプラクティスに沿っているかを理解するための質問、実装のガイダンスなどから構成される必読のドキュメントです。6 つの柱 (優れた運用効率、セキュリティ、信頼性、パフォーマンス効率、コストの最適化、持続可能性) に基づいています。AWS を使用する場合には最初の設計段階、そしてその後も定期的にレビューのため使用していただくことを推奨しております。最初は読むのが大変ですが、これを理解できるようになることを目指すことは良い目標になると思います。 7-2. AWS アーキテクチャセンター エキスパートがまとめた AWS の技術リソース群を一覧できます。 ページ上部の「ライブラリ」タブに含まれる AWS ホワイトペーパーとガイド や AWS Prescriptive Guidance (AWS 規範ガイダンス) にはテクニカルガイドやリファレンスのアーキテクチャなどが記載された技術文書が集まっています。 より多くの構成例を確認したい場合は AWS リファレンスアーキテクチャ図 をご確認ください。200 を超えるアーキテクチャ図が掲載されていてポイントごとに解説もありますし、カテゴリ別・業種別にフィルタリングもできます。なお、お客様とパートナー様が実装したアーキテクチャを解説する動画を視聴できる This is My Architecture もおすすめです。 7-3. AWS ソリューションライブラリ 現時点では英語のみですが、業界ごとや技術ごとなどでソリューションのガイダンスを検索できます。ガイダンスごとにアーキテクチャ図が含まれているものが多いので、自分たちの課題を解決するための参考情報として利用できます。 またソリューションライブラリのページではありませんが、 The Amazon Builders’ Library では Amazon のエンジニアが実際に開発・設計・リリース・運用する方法を説明していて、設計に関する考慮事項などの生の声が記載されていて興味深いです。 7-4. ここまで紹介した以外のハンズオンやワークショップ 初級者向けのハンズオンや日本語で用意されているものをステップ 5 でご紹介しましたが、他にも複数のハンズオンがあります。 AWS Builder Center の Workshop ではレベル、カテゴリ (セキュリティ、IoT など) や AWS サービス名でのフィルタができます。ちなみに、 AWS Samples や Amazon Web Services – Labs では GitHub 上に様々なワークショップのソースコード等を公開していますので、合わせてチェックしてみてください。 他にも AWS Skill Builder で有償のサブスクリプションに申し込んでいただくと、自分で AWS アカウントを用意しなくても AWS Builder Labs  で様々な演習が実施できます。 7-5. AWS 認定 AWS の勉強をされている方の中でも「今すぐ業務で使う訳ではないから目標がないとなかなかやる気が出ない」とか「自分の業務で使うサービス以外を勉強するきっかけが少ない」という声もよく伺います。そこで AWS 認定を目指してみるのはどうでしょうか ? 試験も幅広く用意されており、普段業務で使わない知識を知るきっかけにもなります。広く用語を知っておけば、組織内で他のチームの方と会話する時にも相手のやろうとしてることの理解に役立つと思います。試験に合格することで Credly というサービス上で AWS 認定デジタルバッジ も取得できます。 試験ごとの問題集として無料で試せる Official Practice Question Set がありますし、有償サブスクリプションの方は Official Pretest という本試験と同じ問題数の模擬試験も使えます。どれから受ければ良いかわからない場合はまず AWS Certified Cloud Practitioner 、その後に AWS Certified Solutions Architect – Associate に挑戦していただくと良いです。 AWS 認定試験ガイド にはそれぞれの試験の出題範囲が記載されていますので、どの試験を受けるかの選択時や学習時に役立ててください。 7-6. Microcredentials (マイクロクレデンシャル) マイクロクレデンシャルは、実践的なスキルを証明する新しい手法として 2025 年 11 月より利用が可能になり、2026 年 4 月からは全てのコースが無料で利用できるようになっています。このコンテンツは用意された AWS 環境で発生している実践的な課題を解決することで、特定分野におけるスキルの深さを証明します。基準を満たして合格すれば AWS 認定と同様に Credly のデジタルバッジが付与されます。自分のスキルをアピールしたい方、全試験合格 (全冠) の次の目標が欲しい方は是非チャレンジしてみてください。マイクロクレデンシャルについてもっと詳しく知りたい方は [スキル証明] AWS マイクロクレデンシャル スタートガイド (日本語) をご確認ください。日本人のインストラクターがわかりやすく説明を行っています。 7-7. AWS 関連の GitHub リポジトリ AWS では様々なツールやサンプルコードなどを GitHub で公開しています。その中でもいくつかの AWS に関連するアカウントを紹介します。 Amazon Web Services 色んなツールがあり、 AWS CLI 、 AWS SDK 、 AWS CDK 、 AWS SAM などのリポジトリも含まれている Amazon Web Services – Labs こちらもツールが多く最近作成された MCP や aidlc-workflows などは現時点ではここに含まれている Amazon Web Services – Documentation いくつかのドキュメントがあるが、AWS SDK のサンプルコード ( aws-doc-sdk-examples ) があることを知っていると役に立つ AWS Samples 特定のユースケースやシナリオに対する AWS サービスの実践的な実装を示すサンプルコードなど お知らせ (AWS クラスルームトレーニング) 短期間で体系的に学びたいお客様のために、AWS 認定インストラクターが実施する有償の集合研修をオンサイト、オンラインの両方の形式で提供しております。座学だけでなくハンズオンなども含めた充実した内容となっていますので、ぜひ受講をご検討ください。どのコースを受講するかお悩みの方は AWS 認定インストラクターによる有償トレーニングコースの選び方 の記事を、そして有償トレーニングならではの価値を確認するために AWS 有償トレーニングのメリットってなんだろう の記事を参考にしてください。 まとめ 冒頭にもお伝えしましたが、新しいことを学ぶときに一度で完璧に覚えられる方はほとんどいませんので、何度もくり返すことが重要です。早速今日から AWS の学習を始めてみましょう !

本記事は「 Introducing Kiro Ambassadors 」を翻訳したものです。 先日、開発者コミュニティが互いに発見し、つながり、よりよいものを作るための場として Kiro コミュニティハブと Kiro Labs をローンチしました。すでにギャラリーにプロジェクトを投稿したり、これから開催するイベントをシェアしたりする動きが始まっています。今日はそこからもう一歩踏み込みます。 Kiro Ambassadors は、フィードバックを寄せ、コンテンツを発信し、他のビルダーを支えてくれる、最もアクティブな開発者のみなさんとの関係を公式なプログラムにしたものです。すでに Kiro を前に進めてくれていて、これからの方向性にも直接関わりたいと考えている開発者のための仕組みです。Kiro を実際のワークフローの一部として使っている開発者の影響力とインパクトを、さらに広げていきたいと考えています。 プログラム概要 アンバサダーになると、Kiro の無償サブスクリプション、未公開機能やプライベートベータへの早期アクセス、Kiro のプロダクト・エンジニアリングチームとの直接のコミュニケーション、そして Kiro ロードマップへの影響力が得られます。その代わりに、Kiro を継続的に使い込むこと、質の高いプロダクトフィードバック、機能テストへの参加、コンテンツやイベントといったコミュニティへの貢献をコミットしていただきます。 アンバサダーが受け取るもの アンバサダーに期待すること Kiro の無償サブスクリプション Kiro を継続的に使い込むこと 未公開機能への早期アクセスの機会 機能テストへの参加 Kiro チームとの直接のコミュニケーション Kiro エンジニアとの月次ミーティングへの参加 Kiro ロードマップへの影響力 具体的で実行につながるプロダクトフィードバック イベントやコンテンツ制作のサポート 月ごとのコミュニティ貢献(コンテンツまたはイベント) プロモーション面のサポート より広い Kiro コミュニティとの積極的な関わり 月ごとの稼働量には幅がありますが、アンバサダーとしての活動には少なくとも月 3 〜 4 時間程度を見込んでいます。内訳としては、Kiro エンジニアリングチームとの月 1 時間のミーティング、フィードバックをまとめるのに 1 時間、コンテンツ制作やイベント参加に 1 〜 2 時間ほどです。これは、アンバサダーに選ばれる前提として想定している、普段からのコミュニティでの会話への参加や、Kiro の日常的な利用は含めていません。 アンバサダーが Kiro をどう形づくるか 私が Kiro Ambassador プログラムに参加したのは、テックコミュニティに意味のある変化をもたらしたかったからです。アンバサダーという立場は、さまざまなプラットフォームで開発者だけでなく非開発者の方々も支えられる素晴らしい手段です。Kiro が複雑な作業をどのようにシンプルにしてくれるのかを伝えることで、ポジティブな変化を生み、他の人の成功を後押ししたいと考えています。 — James Gabriele(Kiro Ambassador) アンバサダープログラムのあらゆる特典と役割の背景には、「Kiro をよりよくする」ことと「開発者を支える」ことという2つの軸があります。Kiro のツール、チーム、そしてコラボレーションへのアクセスを提供することで、実践に根ざした意味のあるフィードバックと、コミュニティへの具体的な広がりを生み出していきます。 Kiro Ambassador になるということは、ソフトウェアの作り方そのものを捉え直そうとしているコミュニティの一員になるということです。世界中の開発者が同じ悩みを抱えています。素晴らしいアイデアが、中盤のフェーズでカオスに変わってしまう、という悩みです。そこに Kiro が入ってきて、仕様(Specs)、構造、明快さという、まっとうなアプローチを与えてくれる。だからこそ、このコミュニティは築き上げる価値があるのです。 — Asad Mohiuddin(Kiro Ambassador) アンバサダーが未公開機能を試したり、開発の中で見えてきた良かった点・うまくいかなかった点を共有したりすると、Kiro エンジニアリングチームがそれらの情報を受け止め、ロードマップに落とし込んでいきます。そしてアンバサダーが培っていく深い技術的知見は、アンバサダー自身が主催するイベントやコンテンツを通じて、より広いコミュニティへと還元されていきます。結果として Kiro は、Kiro チームとコミュニティの双方に深く関わるアンバサダーからのフィードバックによって、絶え間なくよりよいものになっていきます。 参加方法 あなたの Kiro の活用方法、コミュニティでの活動、そしてプログラムで何を持ち込めるのかを、ぜひ教えてください。私たちは、Kiro を日々の業務で活用し、コミュニティでの対話に参加し、他の開発者がもっと学べる・もっとできるようになるよう手助けしてくれる方を探しています。たとえば、次のようなことを知りたいと思っています。 Kiro の利用経験(どのくらいの期間、どんなユースケースで使っているか) サポート・参加している開発者コミュニティ イベントへの関わり 技術コンテンツ制作の経験(OSS リポジトリ、ブログ、チュートリアル、動画など) Kiro Ambassador に興味を持っていただけましたか? 応募フォームはこちら 、 プログラムの詳細はこちら からご確認ください。応募は随時審査していきますが、1か月経っても連絡がない場合は、 Discord から一声かけてください。みなさんと一緒に、より良い Kiro を作っていけることを楽しみにしています。

本記事は 2026 年 5 月 28 日 に公開された「 Introducing the next generation of Amazon OpenSearch Serverless for building your agentic AI applications 」を翻訳したものです。 本日、AI エージェントを構築するお客様向けに設計されたフルマネージドの検索およびベクトルエンジン、次世代 Amazon OpenSearch Serverless を発表します。次世代 OpenSearch Serverless は、コンピューティングリソースをゼロから 1 秒あたり数千リクエストを処理できる規模までスケールアップし、アイドル時にはゼロまでスケールダウンします。ピーク時の容量に合わせてプロビジョニングした OpenSearch Service クラスターと比べて、最大 60% のコストを削減できます。 次世代 OpenSearch Serverless は数秒でリソースを作成し、容量のスケールアップは前世代の最大 20 倍高速です。即時のリソース作成と、 Vercel や Kiro といった AI 開発プラットフォームとのネイティブ統合により、AI エージェント向けの本番環境対応の検索およびベクトルバックエンドを、インフラを管理せずに数分でデプロイできます。 次世代 OpenSearch Serverless の使い方 次世代 OpenSearch Serverless を使い始めるには、 Amazon OpenSearch Service コンソール の Serverless メニューで Create collection を選択します。 瞬時にオートスケーリングし、コスト最適化のためゼロまでスケールダウンする NextGen コレクションを作成します。リリース時点では、コレクションタイプとして全文検索とベクトル検索のみをサポートしています。既存の OpenSearch Serverless インフラを使う場合は、 Switch to Classic を選択してください。 コレクションを最速で作成するには、 Express create を選択します。設定は不要で、デフォルト設定と一致するセキュリティポリシーが自動で適用されます。一部の設定項目は後から変更できます。 Create collection を選択すると、OpenSearch Serverless は数秒でリソースをプロビジョニングします。 AWS Command Line Interface (AWS CLI) や AWS SDK でも OpenSearch Serverless のコレクションを作成できます。コレクショングループを作成する CLI コマンドの例を示します。 aws opensearchserverless create-collection-group \ --name channy-nextgen-group \ --standby-replicas ENABLED \ --generation NEXTGEN \ --description "My NextGen collection group" \ --capacity-limits '{ "maxIndexingCapacityInOCU": 10, "maxSearchCapacityInOCU": 10, "minIndexingCapacityInOCU": 0, "minSearchCapacityInOCU": 0 }' \ --region "us-east-1" 続いて、親のコレクショングループから世代を継承するコレクションを作成できます。サポートされるコレクションタイプは SEARCH と VECTORSEARCH です。 aws opensearchserverless create-collection \ --name channy-nextgen-collection \ --type SEARCH \ --collection-group-name channy-nextgen-group \ --standby-replicas ENABLED \ --description "My collection in NextGen group" \ --region "us-east-1" 次世代 OpenSearch Serverless の管理について詳しくは、 Amazon OpenSearch Serverless のドキュメント をご覧ください。 OpenSearch Serverless でエージェント開発を加速する Vercel での本番環境対応エージェントアプリケーションの構築をサポートするため、Vercel コンソール内で新しい OpenSearch コレクションを作成したり、既存の OpenSearch Serverless コレクションに接続したりできるようになりました。検索バックエンドを数秒で作成し、アプリケーションの成長に合わせてオンデマンドで機能を追加できます。詳しくは、 AWS for Vercel をご覧ください。 Claude Code、Cursor、Kiro を使えば、アイデアから動作するプロトタイプまで数分で到達できます。 OpenSearch Agent Skills は、OpenSearch のインテリジェンスをエージェントに直接組み込むスキルのリポジトリです。各スキルには特定のワークフローのドメイン知識、ベストプラクティス、複数ステップの実行ロジックがカプセル化されています。そのためエージェントは、結果を得るだけでなく、その結果に至った過程まで理解できます。 Kiro Powers の OpenSearch Launchpad を使えば、ガイド付きでエンドツーエンドにアーキテクチャを設計し、検索アプリケーションを高速に開発できます。 提供開始 次世代 Amazon OpenSearch Serverless は本日より一般提供を開始し、Amazon OpenSearch Serverless が現在利用可能なすべての AWS 商用リージョンで利用できます。 次世代 OpenSearch Serverless では、インデックス作成、検索、 GPU アクセラレーション に使用する OpenSearch Compute Unit (OCU) ベースのコンピューティングに対して課金されます。ストレージは GB 月単位で別途課金されます。詳しくは、 Amazon OpenSearch Service の料金 をご覧ください。 ぜひお試しいただき、 AWS re:Post for Amazon OpenSearch Service または通常の AWS Support 窓口からフィードバックをお寄せください。 — Channy 著者について Channy Yun (윤석찬) Channy は AWS News Blog のリードブロガーであり、AWS Cloud のプリンシパルデベロッパーアドボケイトです。オープンウェブの愛好家でブロガーでもあり、コミュニティ主導の学習と技術の共有を大切にしています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Takayuki Enomoto がレビューしました。

本記事は 2026 年 5 月 28 日 に公開された「 The next generation of Amazon OpenSearch Serverless: Built from the ground up for agents 」を翻訳したものです。 対象読者向けの注記: 本記事は技術的な詳細を掘り下げたローンチ記事です。変更点とその理由を簡潔にまとめた概要は、関連する AWS News Blog の記事をご覧ください。 本日、Amazon OpenSearch Serverless のアーキテクチャをゼロから刷新したことを発表します。新しいアーキテクチャでは、オートスケーリングが従来比で最大 20 倍に高速化し、コンピューティングをゼロまでスケールできるようになりました。ピーク負荷に合わせてクラスターをプロビジョニングする場合と比べてコストは最大 60% 削減できます。Amazon OpenSearch Service は、ベクトル、レキシカル、ハイブリッド、エージェント検索を統合したフルマネージドのオープンソース検索エンジンで、低レイテンシーかつ正確で関連性の高い結果を提供します。Amazon OpenSearch Serverless は、その自動スケーリング型のデプロイオプションです。 最近のワークロードはますます動的で予測しにくくなっています。E コマースプラットフォームでは、フラッシュセール時にトラフィックが 10 倍に急増します。人工知能 (AI) エージェントは、複数ステップのタスクを推論する過程で数百もの同時ベクトルクエリをトリガーし、その後アイドル状態になります。マルチテナント SaaS アプリケーションでは、活動パターンが大きく異なる数十のテナントを処理します。こうしたワークロードには、需要に合わせてスケールアップし、需要が下がればリソースを解放できるインフラが必要です。 そこで、 Amazon OpenSearch Serverless のアーキテクチャをゼロから再構築しました。新しいアーキテクチャでは、コンピューティングとストレージを分離しています。インフラのプロビジョニングは分単位ではなく秒単位で完了し、アプリケーションがアイドル状態のときにはコンピューティングをゼロまでスケールダウンします。本記事では、新しいアーキテクチャの内容、アプリケーションへの影響、ハンズオンチュートリアルでの使い始め方を解説します。 新しいローンチに伴い、Amazon OpenSearch Serverless では 2 つのアーキテクチャに名前が付きました。既存のコレクションは Classic コレクションと呼びます。新しいアーキテクチャは NextGen と呼び、AWS コンソールから新しいコレクションを作成するときのデフォルトになります。API で NextGen アーキテクチャを使用するには、CLI で --generation NEXTGEN を指定します。Classic アーキテクチャを引き続き使用する場合は、CLI で --generation CLASSIC を指定するか、オプションの --generation パラメータを省略します。 アプリケーションへの影響 新しいアーキテクチャは、パフォーマンス、コスト、シンプルなユーザー体験という 3 つの柱で改善をもたらします。 パフォーマンス: 秒単位のオートスケーリング OpenSearch Compute Unit (OCU) は、インデックス作成と検索のワークロードを支えるコンピューティング容量の単位です。Amazon OpenSearch Serverless は、追加の OCU を秒単位でプロビジョニングできるようになりました。トラフィックが到着したときには、ワーカーがすでに高負荷に陥ってから対応するのではなく、需要に合わせて事前にリソースを追加します。同じ仕組みで、トラフィックが下がるとインフラを素早くスケールダウンします。新しいアーキテクチャは、容量のスケール速度が以前のアーキテクチャの 最大 20 倍 に達するため、トラフィックの急増時にも一貫したパフォーマンスをユーザーに提供でき、容量が不要になれば支払いも止まります。 コスト効率: 使った分だけ支払う インデックス作成、検索、ストレージ、ベクトルインデックスの GPU アクセラレーションは、それぞれ独立して計測・課金されるため、ワークロードの各次元を個別に把握し、最適化できます。 コンピューティングとストレージの分離: OpenSearch Serverless ではコンピューティングとストレージが完全に分離されており、コレクションに保存されているデータ量とは無関係に OCU をスケールアップ・スケールダウンできます。これは、インデックス作成 OCU と検索 OCU の両方からアクセスできる新しいストレージ層によって実現されています。複数のインデックスにデータを格納していても、データのインデックス作成や検索を実際に行っていなければ、コンピューティングコストは発生しません。アイドル時間が長いワークロードでは、ピーク容量に合わせて OpenSearch Service ドメインをプロビジョニングする場合と比べて、新しいアーキテクチャによりインフラコストを最大 60% 削減できます。 ゼロまでのスケール: アイドルタイムアウト期間 (10 分) の間にリクエストが到着しないと、サービスはコンピューティングリソースを解放し、OCU の使用量はゼロまでスケールダウンします。トラフィックが再開すると、約 10 秒で容量が復活します。スケールダウン中も、サービスは到着したリクエストをキューに入れ、容量が利用可能になり次第処理するため、リクエストを破棄することはありません。スケジュールされたバッチジョブやマーケティングキャンペーンの前など、トラフィックの急増が予想される場合は、本番トラフィックを送信する前に軽量なクエリ (例: size=1 の match_all ) を送信してコレクションをウォームアップしておけます。これにより、最初の実リクエストでユーザーが体感するレイテンシーを抑えられます。インデックス作成と検索は独立してスケールします。検索リクエストがなければ、検索 OCU はゼロまでスケールしますが、インデックス作成リクエストがあれば OpenSearch Serverless はインデックス作成 OCU を維持します。逆向きでも同じです。 ベクトルワークロード向けの GPU アクセラレーション: 新しいアーキテクチャで作成したベクトルコレクションでは、OpenSearch Serverless が GPU バックエンドのコンピューティングを自動的に使用して、Hierarchical Navigable Small World (HNSW) ベクトルインデックスの構築を加速し、CPU のみで構築する場合と比べてインデックス作成時間を大幅に短縮します。GPU アクセラレーションは、全体のインデックス作成時間とコストを削減できる機会があれば自動的に有効になります。Classic アーキテクチャでは、API を介してコレクションレベルで GPU アクセラレーションのオプトイン・オプトアウトが必要でした。NextGen コレクションで特定のインデックスの GPU アクセラレーションを無効にしたい場合は、 インデックスレベルでリモートインデックスビルド設定をオフ にできます。GPU の使用量は請求書に別の項目として表示されるため、いつアクセラレーションが有効で、いくらかかったかを完全に把握できます。GPU アクセラレーションの仕組みやパフォーマンスベンチマークの詳細は、 Amazon OpenSearch Service の GPU アクセラレーションで 10 億スケールのベクトルデータベースを 1 時間以内に構築する を参照してください。 シンプルな体験: 本番環境までのステップ削減 OpenSearch Serverless を日々運用する体験もシンプルになりました。 新しいアーキテクチャでは、コレクションをプロビジョニングして数秒でリクエストを送信し始められます。容量計画もサイジングの判断もインフラのウォームアップ待ちも不要です。これにより、AI エージェントがオンデマンドでベクトル検索や検索ステップを起動し、遅延なくレスポンスを期待できる、エージェントワークロードに Amazon OpenSearch Serverless が自然と適合します。 使い始めをさらに高速化するため、コンソールに Express Create を導入しました。コレクション名とコレクションタイプを指定し、Express Create を選ぶと、ネットワーク、暗号化、アクセスポリシーの事前設定なしで、コレクションが数秒でアクティブになります。ワークロードに必要であれば、後から追加できます。 コレクショングループとコレクションは、AWS Command Line Interface (AWS CLI) や AWS SDK を使ってプログラムから作成することもできます。AWS CloudFormation のサポートも近日提供予定です。 新しいアーキテクチャでは、 on.aws ドメイン上に 2 つのエンドポイント形式が導入されました。コレクション単位のエンドポイント ( <collectionId>.aoss.<region>.on.aws ) は、コレクション 1 つにつきエンドポイント 1 つという、これまでと同じ動作です。アカウント単位のリージョナルエンドポイント ( <accountId>.aoss.<region>.on.aws ) は新しく、1 つのホスト名で全コレクションを処理し、対象のコレクションは各リクエストで x-amz-aoss-collection-name または x-amz-aoss-collection-id ヘッダーで指定します。コレクション数に関係なく、コネクションプール 1 つ、Transport Layer Security (TLS) セッション 1 つ、管理するエンドポイント 1 つで済みます。テナントごとに独自のコレクションを割り当てるマルチテナントワークロードでは、大きな改善になります。両方のエンドポイントは標準の AWS PrivateLink を使用するため、他の AWS サービスと同様に、VPC コンソールや EC2 API から Virtual Private Cloud (VPC) エンドポイントを作成できます。Private Domain Name System (DNS) は自動で構成されるため、元のアーキテクチャで必要だった Amazon Route 53 プライベートホストゾーン、転送ルール、カスタム DNS インフラが不要になります。クロス VPC、クロスアカウント、オンプレミスからのアクセスは、追加のセットアップなしに標準の vpce-* DNS 名で動作します。 コレクショングループは、コレクションを整理する新しい単位 です。 コレクショングループ を使うと、複数のコレクション間でコンピューティング容量を共有でき、トラフィックパターンが補完的な小規模コレクションのコストを削減できます。同じグループ内のコレクションに異なる AWS Key Management Service (AWS KMS) キーを割り当てることもでき、コスト効率とコレクション単位の暗号化分離の両方を得られます。新しいアーキテクチャでコレクションを作成する場合、コレクショングループは必須です。 バージョンとアップグレードを管理する手間なく、OpenSearch オープンソースリリースの利点も得られます。サービスはアップストリームのリリースを自動的に追跡します。 Amazon OpenSearch Serverless は Vercel Marketplace でも利用可能になっており、開発者は Vercel プロジェクトから検索インフラを直接追加できます。委任アクセスを通じて既存の AWS アカウントをリンクするか、AWS が初めての場合は USD $100 の AWS クレジット付きの Limited Scope Account を通じて使い始められます。 この統合では、適切なデフォルト、ゼロまでのスケール課金、パブリックエンドポイント、AWS マネージド暗号化を備えたコレクションが作成され、接続情報が Vercel プロジェクトの環境変数として自動的に設定されます。フルテキスト検索でも、セマンティックや AI を活用した検索でも、ユースケースに応じて Search または Vector Search のコレクションタイプを選べます。 アーキテクチャの仕組み 新しい Amazon OpenSearch Serverless アーキテクチャは、コンピューティングとストレージを完全に分離します。OCU はステートレスで、インデックス作成 OCU と検索 OCU の両方からアクセス可能な分散共有ストレージ層から読み書きします。ストレージ層は高い耐久性を念頭に設計されており、データを処理するコンピューティングノードとは独立してデータを利用可能に保ちます。 この設計は、実用上 2 つの効果をもたらします。 高速なプロビジョニング。 ブートストラップするローカルディスクがないため、新しい OCU は数秒でリクエストの処理を開始します。OCU は共有ストレージ層をマウントし、すぐに処理を開始します。 効率的なスケールダウン。 データが OCU 上に存在したことがないため、保存されたデータに影響を与えずにアイドル容量を解放できます。トラフィックが下がるとコンピューティングリソースが解放され、それに応じてコストも下がります。 アーキテクチャの比較 次の表で、元のアーキテクチャと新しいアーキテクチャの主な違いをまとめます。 機能 Classic アーキテクチャ NextGen アーキテクチャ 最小容量 2 OCU (常時稼働) 0 OCU (ゼロまでのスケール) スケーリング速度 分単位 秒単位 ストレージ コンピューティングノードごとのローカルストレージ 分散共有ストレージ (分離) コレクションの整理 個別コレクション (デフォルト) コレクショングループ (オプション) コレクショングループ (必須) ゼロからのコールドスタート 該当なし (常時稼働) 約 10 秒 エンドポイント コレクション単位のエンドポイント リージョナルエンドポイント (アカウントごとに静的) OpenSearch Service ドメインに対するコスト ベースライン 最大 60% 低コスト スケーリング速度 (Classic 比) ベースライン ベースラインの最大 20 倍 ウォークスルー: ベクトルコレクションの作成とゼロまでのスケールの観察 このウォークスルーでは、Express Create でベクトル検索コレクションを作成し、埋め込みを持ついくつかのサンプルドキュメントをインデックスし、k-nearest neighbor (k-NN) クエリを実行し、Amazon CloudWatch でコレクションがゼロまでスケールする様子を観察します。全体で約 10 分かかります。 前提条件 Amazon OpenSearch Serverless コレクションを作成する権限を持つ AWS アカウント。 適切な認証情報で構成された AWS Command Line Interface (AWS CLI)。 curl 7.75 以降 (組み込みの --aws-sigv4 サポート用)。 ステップ 1: セキュリティポリシーを構成する 暗号化、ネットワーク、データアクセスポリシーを作成します。コレクションを作成する前にこれらが存在している必要があります。 # Create an encryption policy aws opensearchserverless create-security-policy \ --name product-vectors-encryption \ --type encryption \ --policy '{"Rules":[{"ResourceType":"collection","Resource":["collection/product-vectors"]}],"AWSOwnedKey":true}' \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2" # Create a network policy (public access for this tutorial) aws opensearchserverless create-security-policy \ --name product-vectors-network \ --type network \ --policy '[{"Rules":[{"ResourceType":"collection","Resource":["collection/product-vectors"]},{"ResourceType":"dashboard","Resource":["collection/product-vectors"]}],"AllowFromPublic":true}]' \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2" # Get your principal ARN PRINCIPAL_ARN=$(aws sts get-caller-identity --query 'Arn' --output text) # Create a data access policy aws opensearchserverless create-access-policy \ --name product-vectors-data \ --type data \ --policy "[{\"Rules\":[{\"ResourceType\":\"index\",\"Resource\":[\"index/product-vectors/*\"],\"Permission\":[\"aoss:CreateIndex\",\"aoss:DescribeIndex\",\"aoss:UpdateIndex\",\"aoss:DeleteIndex\",\"aoss:ReadDocument\",\"aoss:WriteDocument\"]}],\"Principal\":[\"\${PRINCIPAL_ARN}\"]}]" \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2" 注: AWS コンソールの Express Create ワークフローを使用すると、これらのポリシーは自動的に作成されます。 重要: データアクセスポリシーを作成した後、コレクションへの API 呼び出しを行う前に、ポリシーが伝播するまで約 30〜60 秒待ちます。403 Forbidden エラーが発生した場合は、待ってから再試行してください。 ステップ 2: コレクショングループとコレクションを作成する ゼロまでのスケール容量制限を持つコレクショングループを作成し、その中にベクトル検索コレクションを作成します。 # Create a collection group with scale-to-zero enabled (min OCU = 0) aws opensearchserverless create-collection-group \ --name product-search-cg \ --generation NEXTGEN \ --standby-replicas ENABLED \ --capacity-limits "minIndexingCapacityInOCU=0,maxIndexingCapacityInOCU=4,minSearchCapacityInOCU=0,maxSearchCapacityInOCU=4" \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2" # Create a vector search collection in the group aws opensearchserverless create-collection \ --name product-vectors \ --type VECTORSEARCH \ --collection-group-name product-search-cg \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2" コレクションのステータスは数秒で ACTIVE に遷移します。 ステップ 3: ベクトルインデックスを作成する コレクションエンドポイントを取得し、3 次元ベクトルを使った k-NN インデックスを作成します。 ENDPOINT=$(aws opensearchserverless batch-get-collection \ --names product-vectors \ --query 'collectionDetails[0].collectionEndpoint' \ --output text \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2") awscurl --service aoss --region us-east-2 \ -XPUT "${ENDPOINT}/items" \ -H "Content-Type: application/json" \ -d '{ "settings": {"index.knn": true}, "mappings": { "properties": { "description": {"type": "text"}, "embedding": {"type": "knn_vector", "dimension": 3, "method": {"name": "hnsw", "space_type": "cosinesimil", "engine": "faiss"}} } } }' 注: コレクションがゼロまでスケールしている場合、容量がスケールアップする間、最初のリクエストには数秒かかる可能性があります。リクエストがタイムアウトした場合は、10〜15 秒待ってから再試行してください。 ステップ 4: 埋め込みを持つサンプルドキュメントをインデックスする awscurl --service aoss --region us-east-2 \ -XPOST "${ENDPOINT}/items/_bulk" \ -H "Content-Type: application/json" \ -d ' { "index": { "_id": "1" } } { "description": "Wireless noise-cancelling headphones", "embedding": [0.8, 0.2, 0.1] } { "index": { "_id": "2" } } { "description": "Portable Bluetooth speaker", "embedding": [0.7, 0.3, 0.2] } { "index": { "_id": "3" } } { "description": "Over-ear studio monitor headphones", "embedding": [0.9, 0.1, 0.05] } ' ステップ 5: k-NN クエリを実行する クエリベクトルに最も近い 2 つの近傍を検索します。クエリを実行する前に、ベクトルインデックスのビルドのため、インデックス作成後 30 秒待ちます。 awscurl --service aoss --region us-east-2 \ -XGET "${ENDPOINT}/items/_search" \ -H "Content-Type: application/json" \ -d '{ "query": { "knn": { "embedding": { "vector": [0.85, 0.15, 0.08], "k": 2 } } } }' レスポンスでは、最も類似する 2 つのアイテム、つまりクエリベクトルに最も近い埋め込みを持つヘッドフォンのドキュメントが返されます。 このクエリは OpenSearch UI でも実行できます。Amazon OpenSearch Service コンソールでコレクションに移動し、OpenSearch UI Application URL を選択します。次に こちらのブログ の手順に従ってワークスペースを作成します。その後、Dev Tools に移動して、次のクエリを貼り付けて実行します。 GET items/_search { "query": { "knn": { "embedding": { "vector": [0.85, 0.15, 0.08], "k": 2 } } } } ステップ 6: ゼロまでのスケールを観察する 一定期間活動がない (インデックス作成や検索のトラフィックがない) と、コレクショングループは 0 OCU までスケールダウンします。次のコマンドで確認します。 aws opensearchserverless batch-get-collection-group \ --names product-search-cg \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2" レスポンスで、コレクションがスケールダウンした後、 currentCapacity.search.capacityInOcu と currentCapacity.indexing.capacityInOcu が 0 と表示されます。 Amazon OpenSearch Service コンソールの コレクショングループ ページに移動することもできます。コレクショングループを選択し、 モニタリング セクションまでスクロールします。 インデックス作成容量 (OCU) と 検索容量 (OCU) という 2 つのチャートを確認できます。10 分間アイドル状態 (インデックス作成や検索リクエストがない状態) が続くと、両方のメトリクスがゼロまで下がり、サービスがコレクションのコンピューティングリソースをすべて解放したことが確認できます。 クリーンアップ 継続的な課金を避けるため、このウォークスルーで作成したリソースは終わったら削除します。最初にコレクションを削除してコレクショングループを空にし、次にグループを削除し、最後にセキュリティポリシーとアクセスポリシーを削除します。 # Look up the collection ID, then delete the collection COLLECTION_ID=$(aws opensearchserverless batch-get-collection \ --names product-vectors \ --query 'collectionDetails[0].id' \ --output text \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2") aws opensearchserverless delete-collection \ --id "${COLLECTION_ID}" \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2" # Look up the collection group ID, then delete the collection group GROUP_ID=$(aws opensearchserverless batch-get-collection-group \ --names product-search-cg \ --query 'collectionGroupDetails[0].id' \ --output text \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2") aws opensearchserverless delete-collection-group \ --id "${GROUP_ID}" \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2" # Delete the security and access policies aws opensearchserverless delete-security-policy \ --name product-vectors-encryption \ --type encryption \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2" aws opensearchserverless delete-security-policy \ --name product-vectors-network \ --type network \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2" aws opensearchserverless delete-access-policy \ --name product-vectors-data \ --type data \ --endpoint-url "https://aoss.us-east-2.amazonaws.com" \ --region "us-east-2" 既存のコレクションのアップグレード 新しいアーキテクチャに移行するには、新しいコレクショングループとコレクションを作成し、データを再インデックスします。再インデックスの手順は Amazon OpenSearch Ingestion を使った Amazon OpenSearch Serverless での再インデックスの実行 に詳しく解説しています。クエリとインデックスマッピングは同じままで、変わるのはコレクションエンドポイントだけです。新しい静的リージョナルエンドポイントなら、これは 1 回限りの更新で済みます。 新しいアーキテクチャは SEARCH と VECTORSEARCH のコレクションタイプをサポートします。TIMESERIES はローンチ時にはサポートされません。 まとめ 新しい Amazon OpenSearch Serverless アーキテクチャは本日から利用可能です。Express Create を使えば最初の OpenSearch Serverless コレクションを数秒で作成し、本番トラフィックに対応するようスケールでき、アイドル状態になれば OpenSearch Serverless のコンピューティングコストはゼロまで下がります。 詳細は次を参照してください。 Amazon OpenSearch Service ドキュメント 。 Amazon OpenSearch Service コンソール 。 Amazon OpenSearch Service 料金ページ 。 質問やフィードバックがあれば、サポートケースを開くか、AWS アカウントチームを通じて連絡してください。皆さんが構築するものを楽しみにしています。 著者について Sohaib Katariwala Sohaib は AWS の Senior Specialist Solutions Architect で、イリノイ州シカゴを拠点に Amazon OpenSearch Service を担当しています。データと分析に関するあらゆる事柄に関心があります。特に、お客様がデータ戦略の中で AI を活用し、現代的な課題を解決できるよう支援することを楽しみにしています。 Raj Ramasubbu Raj は AWS の Senior Analytics and AI Specialist Solutions Architect で、ビッグデータ、分析、AI/ML に注力しています。お客様と協力して、高いスケーラビリティ、パフォーマンス、セキュリティを備えたクラウドベースのソリューションを設計・構築しています。 Arjun Nambiar Arjun は Amazon OpenSearch Service の Product Manager です。多種多様なソースから Amazon OpenSearch Service へ大規模にデータを取り込めるようにする取り込み技術に注力しています。Arjun は大規模分散システムやクラウド中心の技術に関心があり、ワシントン州シアトルを拠点としています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Takayuki Enomoto がレビューしました。

本ブログは、2025 年 10月 20 日に公開された Amazon Science Blog “ Introducing Chronos-2: From univariate to universal forecasting ” を翻訳したものです。 Chronos-2 は、追加学習なしに、多変量も共変量も扱える時系列基盤モデルです。 時系列予測は、ビジネス、科学、工学における数多くのアプリケーションにとって不可欠です。近年、基盤モデルが時系列予測にパラダイムシフトをもたらしました。1本の時系列を延長する統計モデルや、特定タスク専用に訓練された従来の深層学習モデルとは異なり、時系列基盤モデル（Time Series Foundation Model : TSFM）は大規模な時系列データで事前に訓練され、その後さまざまな予測問題に適用されます。 初回リリース以来、Amazon の TSFM である Chronos と Chronos-Bolt は、Hugging Face から累計6億回以上ダウンロードされており、TSFM への関心の高さと、幅広い予測シナリオで活用されていることを示しています。 しかし既存の TSFM には、単変量予測しかサポートされないという重要な制約があります。単変量予測は重要ですが、多くのシナリオでは追加の機能が必要です。現実の予測問題では、互いに関連しながら変動する複数の時系列を同時に予測すること（多変量予測）や、予測対象に影響を与える外部要因を取り込むこと（共変量付き予測）が求められることが多くあります。例えば、CPU 使用率、メモリ消費量、ストレージ I/O などのクラウドインフラストラクチャの指標は連動して変化し、同時にモデリングすることでより正確な予測が得られます。同様に、小売の需要はプロモーション活動に大きく影響され、エネルギー消費は気象条件に大きく依存します。 この問題を解決するため、私たちは Chronos-2 を発表しました。Chronos-2 は、単変量、多変量、共変量付き予測など、任意の予測タスクをゼロショットで処理するために設計された基盤モデルです。Chronos-2 はコンテキスト内学習（in-context learning : ICL）を活用し、追加学習なしに多変量・共変量付き予測を実現します。 多変量予測では、Chronos-2 は互いに連動する複数の時系列を同時に予測し、変数間の依存関係を捉えて予測精度を向上させます。例えば、クラウド運用チームは CPU 使用率、メモリ消費量、ストレージ I/O を同時に予測し、リソースのボトルネックを事前に検知できます。 共変量付き予測では、Chronos-2 は予測対象に影響を与える外部要因を取り込むことができます。このモデルは、過去共変量（将来のトレンドを示唆する過去の交通量データなど）と、将来既知の共変量（計画済みのプロモーションや天気予報など）をサポートします。また、特定の祝日やプロモーションの種類などのカテゴリカル共変量も扱えます。例えば、小売業者はプロモーションキャンペーンや祝日スケジュールを考慮しながら需要を予測し、在庫水準を最適化できます。 Chronos-2 の強化された ICL 機能は、系列間の情報共有（クロスラーニング）を可能にし、単変量予測も改善します。これはコールドスタートのシナリオで特に有用です。新しい配送センターを開設する物流会社は、既存施設のパターンを活用して、運用履歴が最小限であっても正確な予測を生成できます。 図1 : Chronos-2 のパイプライン Chronos-2 の全体パイプラインは以下のように構成されます。 入力時系列（予測対象と共変量）をスケーリングで正規化 タイムインデックスとマスクのメタ特徴量を追加 得られた系列を重複のないパッチに分割し、残差ネットワークを介して高次元の埋め込みにマッピング コアの Transformer スタックがこれらのパッチ埋め込みに対して動作し、入力でマスクされた将来パッチに対応するマルチパッチ分位点出力を生成 訳注：タイムインデックスは各データポイントの時間的な位置を示し、マスクは将来区間（＝予測対象）がどこかをモデルに伝える役割を持ちます。 訳註：残差ネットワーク（residual network）は入力をスキップ接続で保持しながら変換するネットワーク構造を意味します。「高次元の埋め込みにマッピング」は、各パッチを Transformer が処理しやすい数値ベクトルに変換することです。 各 Transformer ブロックは時間アテンション層とグループアテンション層を交互に配置しています。時間アテンション層は単一の時系列内のパッチ間で情報を集約し、グループアテンション層は各パッチインデックスにおいてグループ内のすべての系列間で情報を集約します。図 1 は、それぞれ 1 つの既知共変量を持つ 2 つの多変量時系列を示しており、対応するグループが青と赤でハイライトされています。この例は説明のためのものですが、Chronos-2 は任意の数のターゲットとオプションの共変量をサポートします。 Chronos-2 のように多様な予測タスクに対応する TSFM を構築するには、モデルアーキテクチャと訓練データの2つの面でイノベーションが必要でした。下流の予測タスクは、変数の数も変数が表す意味も多様です。未知のタスクにおける変数間の相互作用は事前に分からないため、モデルは与えられたコンテキストからそれを推論する必要があります。 私たちのグループアテンション機構は、任意のサイズの時系列グループ内での情報交換を通じて、このような相互作用を考慮します。例えば、Chronos-2 がクラウドの各種指標を予測する場合、CPU 使用率のパターンがメモリ消費量の予測に情報を提供できます。グループアテンションは共変量も考慮でき、例えばプロモーションスケジュールの情報を使って需要予測を支援します。 訓練コーパスはアーキテクチャのイノベーションと同様に重要です。多様な予測タスクに対応する TSFM は異種の時系列タスクで訓練される必要がありますが、多変量の依存関係や有用な共変量を含む高品質な事前学習データはほとんど存在しません。この問題に対処するため、私たちは合成時系列データを活用しています。具体的には、ベースとなる単変量生成器から時系列をサンプリングし、それらに多変量構造を付与することでデータを生成しています。 図2 fev-bench の結果 fev-bench 時系列ベンチマークでの実験結果です。平均勝率とスキルスコアは、確率的予測性能を評価するスケーリング分位点損失（SQL）指標に基づいて計算されています。両指標とも値が高いほど結果が良好であることを示します。Chronos-2 は、単変量、多変量、共変量付き予測タスクを含むこの包括的なベンチマークにおいて、既存のすべての事前学習済みモデルを大幅に上回っています。 図3 : 単変量予測との比較 Chronos-2 の単変量予測での結果と、fev-bench の共変量サブセットにおける ICL による改善（積み上げ棒グラフとして表示）です。ICL は共変量を含むタスクで大きな改善をもたらし、Chronos-2 が ICL を通じて共変量を効果的に活用できることを実証しています。Chronos-2 以外では TabPFN-TS と COSMIC のみが共変量をサポートしており、Chronos-2 はすべてのベースライン（TabPFN-TS と COSMIC を含む）を大幅に上回っています。 図4 : GIFT-Eval の結果 GIFT-Eval 時系列ベンチマークでの結果です。(a) 確率的予測指標および (b) 点予測指標に対する平均勝率とスキルスコアを示しています。両指標とも値が高いほど結果が良好であることを示します。Chronos-2 は、これまで最高性能であった TimesFM-2.5 と TiRex を上回っています。 実証的な評価により、Chronos-2 が TSFM の飛躍的な能力が確認されました。単変量、多変量、共変量付き予測など幅広い予測タスクを網羅する包括的な時系列ベンチマーク fev-bench において、Chronos-2 は既存の TSFM を大幅に上回っています。最大の改善は共変量付きタスクで見られ、この実用上重要な設定における Chronos-2 の強みを実証しています。 GIFT-Eval ベンチマークでは、Chronos-2 は事前学習済みモデルの中で1位にランクされています。Chronos-2 はその前身である Chronos-Bolt を大幅に上回り、直接比較で90%以上の勝率を達成しています。 Chronos-2 は ICL により追加学習なしに本番パイプラインへ組み込めるため、予測パイプラインを大幅に簡素化できます。Chronos-2 は現在オープンソースとして公開されています（リンクは以下）。研究者や実務家の皆様にぜひ Chronos-2 をお試しいただき、時系列基盤モデルの研究の最前線に加わっていただければ幸いです。 参考情報： Chronos-2 モデルカード Amazon SageMaker への Chronos-2 のデプロイ Chronos-2 技術レポート Chronos GitHub リポジトリ 著者について Abdul Fatir Ansari Amazon Web Services の Senior Applied Scientist Oleksandr Shchur Amazon Web Services の Senior Applied Scientist Jaris Küken Amazon Web Services の Applied Science Intern。フライブルク大学コンピュータサイエンス専攻の大学院生 本ブログは、Solutions Architect の 寺山 怜志が翻訳しました。