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 の学習を始めてみましょう !

みなさん、こんにちは。株式会社 APTO で Physical AI のデータ基盤を構築している田中です。 近年、ロボット向け VLA モデルの台頭により、AI 開発の成否は「学習データの品質」に強く依存するようになっています。 しかし、大容量かつ厳密な同期が求められるロボットの操作データを品質を落とさずに日々収集することは非常に困難であり、Physical AI 開発における最大のボトルネックとなっています。 このブログでは、同じ課題に直面するチームの参考となるよう、APTO 社がこの「データ収集」のハードルをどのように仕組み化して解決したのかを紹介します。 想定読者 Physical AI / ロボティクス分野でデータ基盤を設計している方 AWS 上で大量データのイベント駆動処理を構築しようとしている方 スタートアップで少人数チームの MLOps を運用している方 APTO が AWS 上に構築している双腕遠隔操作ロボット向けの Physical AI データ基盤について、下の図 1 でグリーンの  ① 収集 の部分 — エッジ側で完全性をどう確定させ、Amazon S3 へどう引き渡しているか — を 3 章シリーズの第 1 章として解説します。データ基盤の全体像は「収集 → キュレーション → 拡張 → 学習 → 評価」という MLOps ループで構成されており、第 2 章ではクラウド側の自動キュレーションパイプラインに相当する ② キュレーション 、第 3 章では ③ 拡張 および ④ 学習 への接続を扱う予定です。なお、本稿で扱う ① 収集ではエッジ側のチェックを「データの同期が取れているか」に絞っており、品質スコアリング・重複判定・PII検査・統計集計などのキュレーション工程はすべてクラウド側で実施する設計です。 図 1: MLOps ループ全体像 — 収集が本稿のスコープ   1. APTO と Physical AI APTO は 2020 年 1 月設立、東京都千代田区にある約 40 名のスタートアップです ( APTO 会社概要 2026時点)。「イノベーティブなアノテーションで AI 開発に変革を」を掲げ、AI データプラットフォーム harBest を軸に、画像・動画・3D (LiDAR)・自然言語・音声まで幅広い学習データ事業を展開するスタートアップです。近年は LLM 開発支援、RLHF、エージェント、RAG といった領域に加え、Physical AI のユースケースを増やしています。 その一環として、双腕の遠隔操作ロボット (bimanual teleoperation robot) からデータを集め、Vision-Language-Action (VLA) モデルのファインチューニングに供する自社基盤を AWS 上で開発しています。本基盤の中心は「収集 → 自動キュレーション → 学習」のループを効率よく回し続けるための仕組みであり、このブログではそのうち最も上流にあたる「収集」を扱います。 2. 背景と課題 Physical AI とデータ基盤の関係 Vision-Language-Action (VLA) モデルは、視覚と言語指示を統合してロボットの動作を生成する基盤モデルとして、研究と産業応用の両面で進展しています。Google DeepMind の RT-2 、Physical Intelligence の π0 など、大規模 VLA モデルが相次いで発表されており、ファインチューニング向けの高品質データセットへの需要は今後も拡大が見込まれます。 ファインチューニングの成否は、モデルアーキテクチャの良し悪し以上に「投入するデータが安定した品質で揃っているか」に依存します。LLM の RLHF データセットに対する経験則と同じく、Physical AI でもデータおよびそれを提供するデータ基盤の完成度がモデル品質の上限を決める構造になりつつあります。 データを利用する上で直面する 3 つの構造的課題 Physical AI のデータパイプラインを運用しようとすると、次の課題に必ず突き当たります。 収集現場の不安定性 : 双腕ロボットの遠隔操作中に PC が落ちる、USB が外れる、オペレータが途中で介入する、といった事象は日常的に発生します。1 件でも破損エピソードが混入すれば、その後の再現実験や学習指標の信頼性が損なわれます。 後段クラウドで品質判定するコスト : 1 エピソードが数百 MB〜数 GB に達するため、「ひとまず Amazon S3 にアップロードしてから品質判定する」設計では、転送・ストレージ・再ハッシュのコストが線形に積み上がります。 手動キュレーションの限界 : 収集 → キュレーション → 学習 のループを回すには、目視確認・品質ラベル付け・Snapshot 構成といった工程を機械化しなければ、収集にキュレーションが追いつきません。 本基盤が目指す状態 これらを踏まえ、APTO の Physical AI データ基盤は次の状態を実装目標としています。 不完全なエピソードは エッジ側で除外 し、Amazon S3 には「完成したエピソードだけ」が届く Amazon S3 への到着をイベント駆動で受け取り、人間の判断は Release 承認のみ に限定する レビュアーは、クラウド側のキュレーションパイプラインが算出する品質ゲート結果・データセット統計・lineage を見て承認 / 差し戻しを判断する (詳細は次回ブログで扱う) データの ID をハッシュから導出し、ingest を 冪等 にする (同じデータを何度取り込んでも結果が変わらない)   3. Physical AI のデータ収集が難しい理由 図 2: 収集からキュレーションまでのデータフロー全体像 模倣学習 (imitation learning) は、お手本となるデモンストレーションデータを再現するようにポリシーモデルを学習させる手法です。Physical AI の文脈では、教師データの候補として 人間のテレオペレーションで収集されたデータとシミュレーション環境で生成された合成データが挙げられます。現時点では動作や映像の自然さや接触の忠実度といった面でテレオペデータの方が品質が高いと考えられ、多くの場合は人間が遠隔操作したロボットの動作を再現するようにモデルを学習させます。VLA モデルのファインチューニングでは、この教師データとして用いる「人間のデモンストレーション」が一定品質で揃っていることが前提となります。 ところがロボットの生ログには、次の三つのノイズが必ず混入します。 アクションと状態の混在 : 双腕遠隔操作では、人間が操作するリーダーアームと追従するフォロワーアームを別ストリームとして残さないと、 action と state が同一テンソルに混ざってしまいます。これは学習側のラベル設計を破壊します。 同期ズレ : カメラフレームとモータサンプルのタイムスタンプ差分が一定値を超えると、視覚と動作の対応関係が崩れます。本実装では WARNING / CRITICAL（2ms / 5ms）の二段階閾値で逐次判定しています。 エピソードの欠損 : 書き込み中に PC が落ちた、人間が途中で介入した、といった理由で不完全なエピソードが混じります。1 件の混入で再現実験の信頼性が失われます。 図 3: 双腕遠隔操作の Leader / Follower 構成   これらを後段のクラウドで除去する設計は費用対効果が悪く、Amazon S3 にアップロードしてから「不完全だった」と判明する経路では、転送と再ハッシュのコストが線形に積み上がります。本基盤ではエッジ側で完全性を確定させ、不完全なエピソードは S3 に渡さないことを設計の出発点としました。 4. 設計を貫く 3 原則 本基盤を貫く設計原則は次の 3 つです。データ品質を担保するためのルールとして先に定義し、そのうえでルールに則って AWSのサービスや機能を選定しています。 Immutability : Episode / Snapshot / Batch は一度作ったら書き換えません。修正は新ハッシュで別エンティティを作り、 derived_from で系譜を残します。 Content-Addressed Storage : エピソードの ID はファイル群の決定論的ハッシュから導出します。同じデータを何度取り込んでも同じ ID になり、ingest が冪等になります。 Event-Driven : 完了したエピソードの到着を S3 イベントで検知し、自動処理を駆動します。人間の判断は Release 承認のみに限定します。   5. 収集エンジンの 3 プロセス構成 図 4: sync-engine の 3 プロセス分離   エッジ PC 側の収集エンジン (sync-engine) は、責務の異なる 3 つのプロセスを共有メモリ ( SharedRingBuffer ) で接続する構成を採っています。 Collector プロセス : センサーとカメラからの読み取り、H.264 と FFV1 (深度) の動画エンコードを担当します。 Sync プロセス : メタデータだけでタイムスタンプを照合し、同期品質を逐次判定します。 Storage プロセス : motor_state.bin / sync_log.bin / events.jsonl などのバイナリファイルをディスクに書き出します。 この 3 プロセス構成は、後述する異常停止時の安全装置 (QualityMonitor) と直接結びつきます。Sync プロセス内で品質劣化を検知した時点で multiprocessing.Event を立て、Collector / Sync / Storage の 3 つを同時にグレースフル停止し、エピソードに .failed センチネルを置く流れです。 6. raw フォーマットの設計 現状のフォーマット選定と今後の方向性 エッジで保存する原本 (raw) のフォーマットは、学習で使う LeRobot v3.0 への変換前データを格納するレイヤです。Physical AI / ロボティクスで一般に検討される候補と評価ポイントを並べると次のようになります。 候補 評価ポイント apto-raw-v5 (現行試行) 変換前の物理層を可逆に残せる。当面の運用には十分だが標準ではない MCAP (Foxglove + ROS 2) スキーマと可視化が強い。ロスレス深度動画 (FFV1) や CAN-FD 生ログを 1 階層に同居させる運用を確立できれば有力候補 HDF5 自己 記述型で扱いやすい一方、動画コーデックの選択肢が限定的、巨大単一ファイルが S3 のオブジェクト単位アップロード／部分取得と相性が悪いという課題 Apache Arrow IPC 列指向で学習側との親和性は高い。Stream Format で追記は可能だが、エピソード途中で異常終了した際の整合性保証が現時点のネック これらを踏まえ、現時点では自前の apto-raw-v5 を試行的に採用しています。標準フォーマット側で「ロスレス深度動画 + CAN-FD 生ログを 1 階層に同居させる」運用ノウハウが揃いきっていないため、まずは可逆性と運用容易性を優先した暫定解という位置づけです。 ただし、このレイヤのフォーマット選定は引き続き検討中で、Physical AI 周辺のフォーマット標準は流動的なため、将来的に MCAP などの標準フォーマットへ移行する可能性は残しています。いずれを採るにせよ、(1) 全タイムスタンプを int64 ナノ秒で統一する、(2) CAN-FD 生ログをそのまま保持する、(3) 深度動画をロスレスで保持する、という三点はフォーマット選定に依らず満たす方針です。これらは将来「キュレーションをやり直す」「別の特徴量を後付けで計算する」という要件に直接効いてきます。 クロック同期源 i64 ns で精度を確保しても、各センサーのクロック源が揃っていなければ同期判定そのものが意味を失います。本基盤では次の方針を取っています。 カメラ : PTP (IEEE 1588) 対応の GigE Vision カメラを採用し、PC ホストを PTP マスタとして全カメラを同期。フレームには PC 受信時刻ではなくカメラ側ハードウェアクロックのタイムスタンプを正として保存します。 モータ (CAN-FD) : CAN フレーム自体はタイムスタンプを持たないため、CAN コントローラの SOF 受信タイミングを PC ホストの CLOCK_MONOTONIC_RAW で打刻しています。CANコントローラのHWタイムスタンプを使う方法も考えられます。 WARNING / CRITICAL 閾値の根拠 : カメラフレーム間隔 33 ms (30 fps) に対し、サブフレーム精度を保つために WARNING 2 ms、CRITICAL 5 ms を設定。CRITICAL を超えるとフレーム内での視覚と動作の対応関係がずれ、模倣学習で扱えなくなります。 PTP 同期がない環境では NTP のミリ秒精度に劣化し、CRITICAL を超えるリスクが増えます。本基盤を別環境に適用する場合は、まずクロック同期源の選定が出発点になります。 7. 完全性をエッジで確定させる仕組み 収録中の電源断・プロセスクラッシュで、エピソードが「途中まで書かれた状態」になることは避けられません。問題はそれを後段が完成済みと誤認することです。誤認すると不完全なデータが学習データセットに混入します。エッジ側では「途中で壊れた状態のエピソードを下流に流さない」ことを最優先にしています。 エッジでは抽象度の異なる3つの層で完全性を担保します。 防ぐ失敗 仕組み 失敗時のマーカー レイヤ 1: ファイル単位 単一ファイルが書きかけのまま本来名で残る アトミック書き込み: .part 拡張子で書き出し → fsync → atomic rename 中間ファイルは .part のまま残る（本来名は存在しない） レイヤ 2: エピソード単位 個々のファイルは完全だが、エピソード全体としては途中で中断している .done センチネルによる完了判定。全ファイルが揃った後に .done センチネルを置く .done が存在しない レイヤ 3: 意味的品質 ファイルとしては完全だが、同期ズレで学習に使えない 同期品質劣化時の安全停止 (QualityMonitor): QualityMonitor が閾値超過を検知 .failed を置く 後段（クラウド ingest や Storage プロセス側のスキャナ）は、この3つのマーカーだけを見て「完了 / 未完了 / 失敗」を判定します。中身のパースや SHA-256 検証は後段の責務として明確に切り分けています。 ファイルの存在だけを完了条件にしている理由は、 復旧時の判断を静的検査だけで完結させたい ためです。「特定ファイルが存在するか否か」だけで判定できれば、復旧ロジック自体を実質的に ゼロにできます。後述する Amazon S3 Event Notifications のフィルタ設計も、この原則の延長線上にあります。 全体シーケンス まず初めに全体の流れを図示します。 各データファイルを .part で書き出し → fsync → atomic rename manifest.json を atomic write + 親ディレクトリ fsync 正常完了なら .done、異常停止なら .failed を touch RawUploadAgent が各ファイルを並列 PUT 後、manifest.json を最後に PUT して S3 Event を発火 ファイル単位のアトミック書き込み 個々のファイルは次の手順で書き出します。 .part 拡張子で書き出す（例: cam_front.mp4.part ） 書き終わったら fsync() でデータを物理デバイスに永続化する os.replace() で .part を本来名（例: cam_front.mp4 ）にアトミックに rename する 親ディレクトリに対して fsync() を呼び、ディレクトリエントリの変更も永続化する この手順を守ることで、電源断が起きても「古い完全なデータが残っている」「新しい完全なデータが置かれてい る」「 .part のまま残っている」のいずれかにしかならず、 本来名で半端なファイルが見える状態は発生しません 。 manifest.json も同じ手順で書き出します。 また、エッジストレージ は NVMe SSD + ext4 (data=ordered) を採用しています。ext4 の data=ordered モードでは、データブロックがジャーナル commit より先にディスクへ書き出されることが保証されます。このため、fsync() + os.replace() の組合せでクラッシュ後も「古い完全なデータ」または「新しい完全なデータ」のどち らかが必ず観測されます。これは アトミック書き込みが成立する前提条件です。NFS / FUSE 等にファイルシステムを変更する場合、アトミック書き込みが破綻する可能性があるため、必ず再評価が必要です。 エピソード単位の完了判定 すべてのファイルが揃った時点で、エピソードディレクトリ直下に .done を touch します。途中で中断した場合は .done を置かないか、QualityMonitor が .failed を置きます。 完了検知は、 .done と manifest.json の両方が揃っているかだけで判断します。中身のパースや整合性チェックはクラウド側 ingest の責務として後段に切り分けています。 意味的品質を守る安全装置 (QualityMonitor) ファイルが完全に書けても、収録中の同期品質が劣化していれば学習には使えません。Sync プロセスはカメラフレームと最近傍モータサンプルのタイムスタンプ差分（同期ズレ）を逐次監視しています。この差分の時系列は原本中の sync_log.bin に保存され、後段の品質ゲートでも参照できます。 QualityMonitor が .failed を置く判定条件は次の二つです。 CRITICAL レベルのドリフトが一定フレーム数連続する 観測ウィンドウ内で CRITICAL の割合が一定割合を超える いずれかを満たした時点で、3 プロセス全体（Sync / Storage / Camera）をグレースフル停止し、エピソードに .failed センチネルを置きます。これにより、品質が劣化したフレームが含まれるエピソードはクラウ ドに渡る前にエッジで除外されます。 8. Amazon S3 へのアップロード manifest.json を最後に PUT する設計 RawUploadAgent は完了したエピソードのディレクトリを 1 ファイルずつ Amazon S3 raw バケットにアップロードします。ここで重要なのは、 manifest.json を 最後に PUT することです。 理由はクラウド側の S3 Event Notifications との接続にあります。1 エピソードから 8 オブジェクト前後が生成されますが、すべてに対してイベントを発火させると下流の Amazon SQS キューが 8 倍に膨らみます。さらに、まだアップロード途中の状態で Worker が S3 を読みに行くと、ファイル不一致による偽の IntegrityError が DLQ に積まれてしまいます。 そこで、(1) S3 Event Notifications 側でフィルタを filter_suffix = "/manifest.json" に絞り、(2) manifest.json は他の全ファイルの PUT が完了してから最後に置く、という二段の制約で「完了したエピソード 1 つに対して SQS メッセージ 1 つ」を成立させています。 この設計が成立するのは、S3 Event Notifications がオブジェクトキーの prefix / suffix フィルタをネイティブにサポートしているからです。Terraform での設定はほぼ次の 1 ブロックに収まります。 resource "aws_s3_bucket_notification" "raw" { bucket = aws_s3_bucket.raw.id queue { queue_arn = aws_sqs_queue.s3_events.arn events = [ "s3:ObjectCreated:Put" ] filter_suffix = "/manifest.json" } depends_on = [aws_sqs_queue_policy.s3_events] } filter_suffix を /manifest.json に固定するだけで、エッジ側が manifest.json を最後に PUT した瞬間にのみ SQS メッセージが 1 件キューに入る関係が S3 側で完結します。 実装は concurrent.futures.ThreadPoolExecutor で並列 PUT し、 as_completed() で全 future の完了を待ってから manifest.json を PUT します。1 つでも失敗していれば例外を伝播させ、 .failed を残してエピソード全体を破棄します。 from concurrent.futures import ThreadPoolExecutor, as_completed def upload_episode (episode_dir: Path , bucket: str , key_prefix: str ) -> None : data_files = [f for f in episode_dir.iterdir() if f.name not in { "manifest.json" , ".done" }] with ThreadPoolExecutor(max_workers= 8 ) as pool: futures = [pool.submit(_put_with_checksum, f, bucket, f"{key_prefix}/{f.name}" ) for f in data_files] for fut in as_completed(futures): fut.result() # raise on failure → episode を破棄 # 全データファイル PUT 完了後に manifest.json を最後に PUT # → S3 Event Notifications の filter_suffix="/manifest.json"が発火 _put_with_checksum(episode_dir / "manifest.json" , bucket, f"{key_prefix}/manifest.json" ) _put_with_checksum は boto3 の put_object(ChecksumAlgorithm="SHA256") を呼び、S3 の Additional Checksum 機能でサーバ側でも SHA-256 を再計算させてオブジェクトメタデータに保存します。Worker 側の再計算検証と組み合わせ、データ整合性は二重に担保しています。 .tar でまとめない理由 今回はエピソードを .tar でまとめずに、ディレクトリ構造をそのまま Amazon S3 のキー階層に写し取る方針を採っています。tar 一括 PUT 案と個別 PUT 案を精査した結果、コスト差は小さく(現状 8 ファイル/エピソード規模で損益分岐は約 43 ファイル)、判断は技術観点で決まりました。個別 PUT を選んだ主な理由は次の通りです。 後段 Stage の非対称なアクセスパターン : CosmosStage(映像品質判定)は動画のみ、学習(DataLoader)は Parquet のみを必要とします。個別 PUT なら必要なファイルだけ GET できますが、tar 化すると毎回全体を GET して展開する必要があり、特に GPU ノードで I/O 待ちが発生するのは設計として不適切です。 CopyObject による stream-copy 最適化が崩れる : ColdConvertStage では動画を raw から cold へ CopyObject で転記し、ECS Worker の CPU・帯域コストをゼロに抑えています。これは個別ファイルが独立した S3 オブジェクトとして存在することが前提です。 tar の「全か無か」性質との不整合 : 部分破損で全体が読めなくなる、Range Request で部分読みできない、Glacier 復元で毎回全体を取り出すことになる、IAM / KMS 粒度がファイル単位で切れない、といった問題が積み重なります。 なお tar 形式そのものを否定しているわけではなく、学習配布用の WebDataset 形式や Glacier Deep Archive への長期アーカイブなど、raw アップロード経路とは別レイヤーで tar 化する価値がある用途は存在します。 9. まとめと次回予告 このブログでは、Physical AI のデータ基盤において「完成したエピソードだけを AWS に渡す」状態をエッジ側でどう作るかを解説しました。要点は次の三点です。 自前フォーマット apto-raw-v5 を採用 : i64 ns タイムスタンプ・CAN 生ログ・ロスレス深度を 1 階層で保持しています。MCAP / HDF5 / Apache Arrow IPC のいずれでもこの組合せを単独では満たせなかったためです。 完了判定をファイル存在のみに統一 : .done と manifest.json の両方が揃ったときだけ完了とみなす原則を採り、状態機械の複雑化を避けました。これがクラウド側のイベント駆動設計に直結します。 manifest.json を最後に PUT : Amazon S3 Event Notifications を「エピソード完了 = 1 通知」という対応関係に整理しました。 Physical AI のデータパイプラインを長く回し続けるには、「機械的にやれる工程は全部自動に寄せ、人間の判断を Release 承認だけに集中させる」ことが鍵となります。エッジ側で完全性を確定させる本稿の設計は、その自動化を成立させる土台です。 第 2 章では、この manifest.json 到着イベントを起点に動く AWS 側のキュレーションパイプラインを扱います。Amazon S3 → Amazon SQS → Amazon ECS Fargate Worker のイベント駆動 ingest、Episode / Snapshot / Batch の 3 層モデル、9 サブステップの構造化キュレーションと 2 階層品質ゲートが中心です。続く第 3 章では、データ拡張と VLA ファインチューニングへの接続、シミュレーション環境との統合、マルチロボット対応の方向性を予告編としてお届けします。 同じような課題に取り組まれているスタートアップの参考になれば幸いです。 We are hiring!! APTOは、AIやPhysical AI領域のデータに特化したサービスを提供しています。 技術の実装を進めたい方、研究開発に興味がある方などは、下記採用ページからエントリーください！ https://apto.co.jp/careers/ 著者プロフィール 田中 達也 (Tatsuya Tanaka) APTOにてPhysical AIやロボティクス領域のデータパイプライン開発、およびUI構築をメインに担当しているAIエンジニアです。データの同期やマルチモーダルデータ管理など、AI活用に向けたデータ基盤の設計・開発に従事しています。趣味は競技プログラミングと陸上観戦。学生時代は陸上一筋でしたが、現在はもっぱら見る専門です。 遠藤 俊策 (Shunsaku Endo) ポジション: Co-founder / AI Engineer バンタンゲームアカデミーで、学内の審査会で数々の賞を受賞。その後、AI開発にも興味を持ち2020年1月にAPTOを共同創業。現在は、APTOのCDOとして開発とビジネス双方を管理。 GitHubアカウント: synsax( https://github.com/synsax ) 黒澤 蓮 (Ren Kurosawa) は AWS Japan のソリューションアーキテクトで、Startup 業界のお客様を中心にアーキテクチャ設計や構築をサポートしています。データアナリティクスサービスや機械学習の領域を得意としています。将来の夢は宇宙でポエムを詠むことです。  

スタートアップとの仕事には、本当に刺激的な何かがあります。私は 2 年以上にわたって、このような仕事に精力的に取り組んできました。スタートアップは、他とは異なる周波数で活動しています。切迫感は切実で、制約は厳しく、背負っているリスクは個人的なものです。これらのスタートアップがビジネスモデルを証明するという課題を乗り越えるのをサポートするには、技術的な専門知識だけでなく、迅速に行動し、前提を疑い、まだ完璧なデータが存在していない時点から適切なアーキテクチャに賭ける意欲が必要です。 私が最も気に入っているのは、仕事が決して抽象的ではないことです。すなわち、スタートアップが下すのを私がサポートするあらゆる意思決定は、適時に製品を出荷できるか、予算内に収めることができるか、投資家から次のラウンドで信頼を得られるかに直接影響があるのです。 2026 年 5 月 25 日週の AWS ニュースを見ていきましょう。 ヘッドライン 新規開設 – トルコのイスタンブールにおける AWS ローカルゾーン – AWS はトルコのイスタンブールに新しいローカルゾーンを開設しました。これにより、欧州最大の都市圏の 1 つに AWS のコンピューティング、ストレージ、ネットワーキングサービスを提供できるようになりました。トルコでデータレジデンシーに関する要件を満たす必要がある組織にとって、このローカルゾーンは、AWS サービスのあらゆる機能をフル活用しながら、データを国内に保持することを可能にします。また、エンドユーザーの実際の所在地により近い場所で実行できるため、リアルタイムゲーム、メディア制作、ライブ動画ストリーミング、金融サービスなど、1 桁ミリ秒のレイテンシーを必要とするアプリケーションに、ローカルゾーンは大きなメリットをもたらします。 ローカルゾーンは、大規模なインフラストラクチャ投資です。すなわち、ハードウェア、電力、ネットワーキング、運用上の優秀性といった点で、リージョンと同じレベルのコミットメントが必要となります。また、これは、サービスが行き届いていない市場への継続的な拡大を反映する AWS の取り組みでもあります。 トルコのビルダーにとって、これは一連の新たなアーキテクチャの可能性を切り開くものです。データレジデンシーに関する要件を満たすのに役立つよう、トルコ内にデータを保存およびバックアップできるようになったほか、イスタンブールのローカルゾーンで低レイテンシーワークロードを実行し、AWS リージョンにシームレスに接続できるようになりました。そのため、独自のデータセンターインフラストラクチャを管理することなく、ハイブリッドアプリケーションを構築するための柔軟性が得られます。トルコにおける 10 年にわたる当社の取り組み、利用可能なサービス、お客様、パートナーに関する詳細については、 立ち上げに関するブログ記事 にアクセスしてください。 2026 年 5 月 18 日週のリリース 私が注目したいくつかのリリースや最新情報をいくつかご紹介します: Security Hub Extended が 9 つのカテゴリにわたる 21 の厳選されたパートナーソリューションに対応 – AWS Security Hub Extended は、エンドポイント保護、クラウドセキュリティ体制管理、脅威インテリジェンスなど、9 つのカテゴリにわたる 21 の厳選されたパートナーセキュリティソリューションと統合するようになりました。カスタム統合を必要とせずに、より広範なツールエコシステムから、統合され、優先順位付けされた、セキュリティに関する検出結果を Security Hub 内で直接取得できるようになりました。これは、AWS およびサードパーティーツール全体にわたるセキュリティ体制の統合ビューを求めているエンタープライズセキュリティチームにとって特に有益です。 Amazon SageMaker AI now supports OpenAI-compatible APIs for inference endpoints – OpenAI 互換 API を使用して、Amazon SageMaker AI の推論エンドポイントを呼び出せるようになりました。これにより、SDK の変更なく、AI ワークロードを OpenAI から SageMaker に移行したり、複数のプロバイダー間で機能するアプリケーションを構築したりすることが大幅に容易になります。これにより、OpenAI を使用してプロトタイピングを開始し、AWS 上の、よりスケーラブルでコスト管理されたインフラストラクチャへの移行を検討しているチームにとって、移行のハードルが下がります。既存のアプリケーションコードはそのまま使用できます。必要なのは、SageMaker エンドポイントをポイントすることだけです。 AWS Secrets Manager Agent のプリフェッチと IAM ロール引き受けの紹介 – AWS Secrets Manager Agent は、起動時にシークレットをプリフェッチし、IAM ロールを引き受けてそれらのシークレットを取得できるようになりました。これにより、レイテンシーが重要な要素となるアプリケーションでオンデマンドのシークレット取得に伴うコールドスタート時のレイテンシーが解消されます。エージェントを設定することで、アプリケーションがトラフィック処理を開始する前に必要なシークレットをプリロードできるため、本番におけるシークレット関連のレイテンシースパイクのリスクを軽減できます。また、IAM ロールの引き受けのサポートにより、アクセス許可の境界が異なるワークロード間でエージェントを共有することも容易になります。 AWS がオープンソースの DynamoDB 互換アダプター ExtendDB を発表 – AWS は、DynamoDB 互換アダプター ExtendDB をオープンソース化しました。これにより、代替バックエンドストレージシステム上で DynamoDB API とデータモデルを利用できます。これは、ローカル開発およびテストワークフローにおいて特に有用です。ライブ AWS 接続を必要とせずに DynamoDB API への書き込みが可能です。また、基盤となるストレージレイヤーをより詳細に制御しながら DynamoDB 互換のセマンティクスを必要とするシナリオにも役立ちます。これは、データアクセスレイヤーに移植性を組み込みたいチームにとって実用的なツールです。 AWS SAM CLI がローカルのサーバーレス開発を加速するために AWS CloudFormation Language Extensions のサポートを追加 – AWS SAM CLI が AWS CloudFormation Language Extensions をローカルでサポートするようになりました。これは、変換、動的参照、および他の CloudFormation 言語機能を、ローカルの開発およびテストワークフローで直接使用できることを意味します。これにより、ローカルでテストできるものと、本番で実行されるものの間に長年存在していたギャップが解消され、ローカルでのサーバーレス開発がより高速かつ信頼性の高いものになります。SAM を使用してサーバーレスアプリケーションを構築し、ローカルテストでエッジケースに遭遇した場合、このアップデートによってエクスペリエンスが大幅に改善されます。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 AWS のその他のニュース 興味深いと思われる追加の記事やリソースをいくつかご紹介します: Amazon Bedrock introduces new advanced prompt optimization and migration tool – この記事は、Amazon Bedrock で新たにリリースされた高度なプロンプト最適化および移行ツールをカバーしています。これらは、お客様がモデルのパフォーマンスを向上させるためにプロンプトを自動的にチューニングするのに役立ち、異なる基盤モデル間でプロンプトを移行するのを支援します。本番 AI ワークロードにおけるプロンプトの質のイテレーションに取り組んでいる場合は必読です。 Introducing Kiro Web – AWS の AI 利用開発環境である Kiro に、ウェブベースのインターフェイスが追加されました。Kiro Web を使用することで、デスクトップ IDE をインストールすることなく、ブラウザから直接、Kiro の仕様駆動型開発、AI チャット、エージェント機能にアクセスできます。これは、クイックレビュー、新しいマシンでのプロトタイピング、チームへの Kiro ワークフローの導入など、あらゆる場面において、AI 支援開発をより身近なものにするための大きな一歩です。 Announcing updated retry behavior for AWS SDKs and Tools – AWS は、SDK および CLI ツール全体のデフォルトのリトライ動作を更新しました。これにより、デベロッパーによる設定変更を必要とせずに、一時的なエラーに対する回復力が高まりました。更新された動作には、よりスマートなバックオフ戦略と、スロットリング応答のより適切な処理が含まれています。API レート制限や一時的な障害に時折遭遇する本番ワークロードを実行している場合、今回のアップデートにより、すぐに信頼性が高まります。変更内容とアプリケーションへの影響を理解するために、ぜひご一読ください。 Bitnami image removal from ECR Public – AWS は、Bitnami コンテナイメージが Amazon ECR Public から削除されることを発表しました。ワークロードが ECR Public から Bitnami イメージをプルしている場合は、この記事を確認して、タイムラインと移行パスを理解してください。Bitnami イメージは Bitnami の独自のレジストリから引き続き直接入手できます。この記事では、イメージ参照を更新して中断なくプルし続ける方法について説明しています。 今後の AWS イベント カレンダーを確認して、これらのイベントにサインアップしましょう: AWS Summit Amsterdam – 5 月 27 日にアムステルダムで開催され、クラウドと AI に関するセッション、ハンズオンラボ、欧州各地のビルダーや AWS エキスパートとのネットワーキングといった、盛りだくさんの 1 日をお過ごしいただけます。登録は無料です。 AWS Summit Bangkok – AWS Summit Bangkok は 5 月 28 日に開催されます。東南アジアのビルダーやお客様にとって、クラウドイノベーションの最新情報を詳しく知り、つながるための絶好の機会となります。 AWS Summit Milan – 同じく 5 月 28 日、AWS Summit Milan がイタリアで開催されます。AWS コミュニティが一堂に会します。南欧州にお住まいの方は、ぜひご参加ください。 AWS Summit Mumbai – 同じく 5 月 28 日、AWS Summit Mumbai が、クラウドと AI に関するコンテンツをインド全土のビルダーにお届けします。詳細なアジェンダと登録については、リンクをご確認ください。 AWS Summit Los Angeles – ロサンゼルスにおける 6 月 10 日のイベントをお見逃しなく。近日開催予定の AWS Summit LA は、西海岸のビルダーコミュニティとつながる絶好の機会です。 AWS Community Day – コミュニティリーダーたちがコンテンツを計画、調達、提供するコミュニティ主導のカンファレンス。ラテンアメリカにお住まいの方は、8 月 22 日に開催される AWS Community Day Belo Horizonte をお見逃しなく。登録は awscommunityday.com.br で受付中です。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。 こちら から、今後開催されるすべての AWS 主導の対面イベントおよび仮想イベントとデベロッパー向けのイベントをご覧いただけます。 2026 年 5 月 25 日週のニュースは以上です。2026 年 6 月 1 日週の Weekly Roundup もお楽しみに! – Daniel Abib この記事は、Weekly Roundup シリーズの一部です。AWS からの興味深いニュースや発表を簡単にまとめて毎週ご紹介します! 原文は こちら です。