「AWSって結局なに？」と聞けずに困っていませんか

会議や社内チャットで、当たり前のように飛び交う「AWS（アマゾン ウェブ サービス）」という言葉。「うちのシステム、AWSに乗ってるから」「それAWSで作れるよね」——そんな会話を聞きながら、内心「AWSって、結局なんなんだ……？」とモヤモヤしている方、けっこう多いのではないでしょうか。

私自身も、情シス部門に異動してきたばかりの頃はまったく同じでした。AWSという単語は毎日のように耳にするのに、いざ「それって何ができるの？」と聞かれると、うまく説明できない。かといって、今さら「AWSって何ですか？」とは聞きづらい。そんな宙ぶらりんな状態が、しばらく続いたのを覚えています。

でも、安心してください。AWSは「言葉が難しそう」なだけで、考え方そのものは決して複雑ではありません。

AWSがわからないのは、あなたのせいではありません。専門用語の壁が高すぎるだけです。

この記事では、ITにあまり詳しくない情シス担当者の方や、AWSという言葉は聞くけれど中身を知らない方に向けて、「AWSとは何か」「何ができるのか」を、できるだけ日常の言葉でかみくだいて解説していきます。

そもそもクラウドとは？AWSをわかりやすく理解する第一歩

AWSを理解するうえで、まず避けて通れないのが「クラウド」という言葉です。ここが曖昧なままだと、AWSもずっとモヤモヤしたままになってしまいます。

クラウドは「電気のように使った分だけ払うコンピューター」

昔は、会社で何かシステムを作ろうとしたら、まず「サーバー」という大きなコンピューターを自分たちで買ってきて、社内の専用の部屋に置いて、電源やネット回線をつないで……という作業が必要でした。これを「オンプレミス（自社で機器を持って運用する形）」と呼びます。

このやり方には、いくつもの面倒がありました。機器は高い、置き場所がいる、壊れたら自分たちで直す、使わなくなっても捨てるのが大変——情シスの現場では、まさにこの「物理的な機械の世話」に多くの時間が取られていました。

クラウドは、この発想をまるごとひっくり返したものです。サーバーやストレージ（保存場所）といったコンピューターの機能を、インターネット経由で「サービスとして借りる」。これがクラウドの正体です。

たとえるなら、クラウドは「電気」とよく似ています。電気を使うために発電所を自宅に建てる人はいませんよね。コンセントにつなぎ、使った分だけ電気代を払う。クラウドもこれと同じで、コンピューターの機能を必要なときに必要なだけ借りて、使った分だけ料金を払うのです。

自分で機械を持たなくていい——これがクラウドの一番おいしいところです。

AWSはクラウドサービスの「最大手」

そして、このクラウドを提供している会社の代表格が、Amazon（アマゾン）です。あのネット通販のアマゾンが、自社で培った膨大なコンピューター技術を、世界中の企業に貸し出すサービスを始めました。それが「Amazon Web Services（AWS＝アマゾンが提供するクラウドサービス）」です。

AWSは世界でもっとも使われているクラウドサービスのひとつで、私たちが普段使っているネットサービスやアプリの裏側も、実はAWSで動いていることが少なくありません。「知らないうちにお世話になっている」存在なのです。

なぜ今、情シスがAWSを知っておくべきなのか

「裏側の仕組みなんて、専門の人に任せておけばいいのでは？」——そう思う気持ちもよくわかります。でも、情シスとしてAWSの基本を知っておくことには、はっきりとした理由があります。

ここでは、初心者の方にこそ押さえてほしい「知っておくべきポイント」を3つに絞ってお伝えします。

ポイント① 多くの会社のシステムが、もうAWSの上で動いている

今や、自社で運用しているシステムや使っている業務アプリの多くが、クラウド——とりわけAWS——の上で動いています。つまり「AWSを知らない」ということは、「自社のシステムがどこで、どう動いているのかを知らない」のとほぼ同じ意味になりつつあるのです。

トラブルが起きたとき、外部の業者さんと話すとき、あるいは新しいツールを導入するとき。基本的な言葉を知っているかどうかで、話の通じ方がまったく変わってきます。

ポイント② 「コスト」と「セキュリティ」の判断に直結する

クラウドは「使った分だけ払う」仕組みなので、放っておくと無駄な費用が積み上がることがあります。また、設定をひとつ間違えるだけで、社外秘の情報が外から見える状態になってしまう——そんなリスクもゼロではありません。

これらは、まさに情シスが目を光らせるべき領域です。仕組みの大枠を理解しているかどうかが、会社のお金と情報を守れるかどうかに直結します。

ポイント③ 専門用語に振り回されなくなる

EC2、S3、RDS……AWSには暗号のような名前のサービスがたくさんあります。でも、ひとつひとつの「役割」さえ押さえておけば、会話の中で出てきても怖くありません。

用語そのものを覚えるのではなく、「何のための道具か」を知ることが大切です。

AWSで何ができるのか？代表的なサービスの全体像

それでは、いよいよ本題です。「AWSで何ができるのか」を、代表的なサービスを通して見ていきましょう。AWSには200を超えるサービスがありますが、初心者がまず知っておけばいいのは、ほんの数個だけです。

身近なたとえに置き換えながら紹介していきますので、肩の力を抜いて読んでみてください。

EC2：クラウド上で借りる「仮想のサーバー」

最初に押さえたいのが、EC2（Elastic Compute Cloud＝クラウド上で借りられる仮想のサーバー）です。名前は難しいですが、やっていることはシンプルで、「インターネット経由で借りられるコンピューター（サーバー）」です。

これまで自社で買って置いていたサーバーを、AWSの中に「数分で立てて、いらなくなったら消せる」イメージです。たとえるなら、EC2は「必要なときだけ借りられる貸しオフィス」のようなもの。自分でビルを建てなくても、必要な広さの部屋をすぐに借りて、使い終わったら返せる。これが大きな魅力です。

S3：いくらでも入る「クラウド上の倉庫」

次によく登場するのが、S3（Simple Storage Service＝クラウド上のファイル保存サービス）です。これは、写真・書類・バックアップデータなど、あらゆるファイルを保存しておける「クラウド上の倉庫」です。

容量を気にせずどんどん入れられて、しかも壊れにくい。社内のファイルサーバーがいっぱいで困った経験のある方なら、その便利さがすぐにイメージできるはずです。S3は「容量無限のクラウド倉庫」だと覚えておけば十分です。

RDS：面倒を肩代わりしてくれる「データベース係」

3つ目は、RDS（Relational Database Service＝AWSが管理してくれるデータベースサービス）です。データベースとは、顧客情報や売上データなどを整理して貯めておく仕組みのこと。

このデータベース、本来は管理がとても手間のかかるものなのですが、RDSを使えば、バックアップや故障時の復旧などの面倒な作業をAWSが肩代わりしてくれます。RDSは「データの管理を任せられる頼れる事務スタッフ」のような存在です。

その他にもいろいろ——でも、まずはこの3つでOK

このほかにも、メールを送る、AI（人工知能）を使う、Webサイトを公開するなど、AWSでできることは本当に多岐にわたります。ただ、初心者がいきなり全部を覚える必要はまったくありません。

「サーバー＝EC2」「倉庫＝S3」「データベース＝RDS」。まずはこの3つだけで、会話の8割は理解できます。

今日からできる、AWSとの付き合い方

ここまで読んで、「なんとなくイメージはつかめたけど、次に何をすればいいの？」と思った方へ。情シス初心者の私が実際にやってよかった、今日からできる具体的なアクションを紹介します。

• 自社がAWSを使っているか確認してみる — まずは身近なところから。社内のシステム担当や資料で、自社がAWSを使っているのか、何のサービスを使っているのかを聞いたり調べたりしてみましょう。「自分ごと」になると理解が一気に進みます。
• AWSの公式サイトをのぞいてみる — AWSには初心者向けの無料の入門コンテンツがたくさんあります。難しければ眺めるだけでもOK。「こういう言葉があるんだ」と知っておくだけで十分です。
• 無料利用枠（一定の範囲なら無料で試せる仕組み）で触ってみる — 百聞は一見にしかず。AWSには一定範囲を無料で試せる枠があります。S3に試しにファイルを1つ置いてみるだけでも、「あぁ、これがクラウドか」と体感できます。
• 資格の入門編をのぞいてみる — 私自身も、AWS Cloud Practitioner（AWSの基礎を学べる初心者向け資格）の勉強を通して、全体像が一気にクリアになりました。資格を取らなくても、学習範囲を眺めるだけで良い地図になります。

いきなり全部を理解しようとしないこと。これがクラウドで挫折しないいちばんのコツです。

まとめ：AWSは「借りられるコンピューター」だと覚えればいい

最後に、この記事の要点を振り返ります。

• AWSとは、Amazonが提供するクラウドサービスのこと
• クラウドとは、コンピューターの機能を「電気のように使った分だけ払って借りる」仕組み
• 代表的なサービスは、サーバーのEC2、倉庫のS3、データベースのRDSの3つを押さえればOK
• 情シスにとっては、コストとセキュリティを守るために知っておくべき知識

「AWS＝難しそう」というイメージは、最初の一歩を踏み出せば必ず薄れていきます。私自身も、わからないことだらけのスタートでした。だからこそ言えます——わからなくて当然、今日から少しずつで大丈夫です。

このブログでは、AWSの各サービスや情シスの実務に役立つ知識を、初心者目線でかみくだいて発信しています。次は、ファイル保存の定番「S3」や、安全を守る「IAM」あたりから読んでみると、理解がぐっと深まりますよ。

関連記事：クラウドとは？AWSの基本をやさしく解説 関連記事：AWS資格（SAA）の始め方

AWS SAAの勉強、何から手をつければいいか分からず止まっていませんか？

「AWSの資格を取ってみたい。でも参考書を開いた瞬間、知らない横文字だらけで閉じてしまった」——そんな経験、ありませんか。

私自身も、情シス（社内の情報システム部門）で働きながらAWSの資格に挑戦しはじめたとき、まさに同じ壁にぶつかりました。私は理系の学部を出たわけでもなく、プログラミングをバリバリ書いてきた人間でもありません。最初に手に取った参考書には「VPC」「サブネット」「冗長化」といった言葉が当たり前のように並んでいて、1ページ目から正直くじけそうになりました。

いま私が挑戦しているのは、AWS認定の中でも人気の高い AWS Certified Solutions Architect – Associate（ソリューションアーキテクト アソシエイト、略してSAA） という資格です。ひとつ手前の AWS Certified Cloud Practitioner（クラウドプラクティショナー、入門レベルの資格）はすでに取得済みで、その次のステップとして勉強中の身です。

だからこの記事は「合格しました、こうすれば受かります」という上から目線の話ではありません。「いま勉強中の、文系・非エンジニアの私が、実際にやって手応えを感じている方法」を、同じように悩んでいるあなたに共有する記事です。

「分からなくて当然」——ここからのスタートで、何も問題ありません。

なぜ非エンジニアはAWS SAAでつまずくのか、その本質

そもそも、なぜ文系・非エンジニアにとってAWS SAAは難しく感じるのでしょうか。

私が思うに、本質はあなたの「頭の良さ」や「IT適性」の問題ではありません。問題は、教材の多くが「ある程度ITの土台がある人」を前提に書かれていることにあります。

たとえばSAAの参考書には「オンプレミスのサーバーをクラウドに移行する際は……」といった文章がよく出てきます。エンジニアなら「オンプレミス（自社で持っている物理的なサーバーのこと）」と聞いてすぐ情景が浮かびますが、ITに不慣れな人にとっては、その前提知識からして説明されていないことが多いのです。

つまり、つまずいているのはあなたの能力不足ではなく、「前提知識のギャップを埋めるステップが、教材から抜け落ちている」だけ。ここを理解しておくだけで、ずいぶん気がラクになります。

情シスの現場でも同じで、新しいクラウドの仕組みを最初から完璧に理解している人なんて、ほとんどいません。みんな調べながら、触りながら覚えています。

つまずいているのは、あなたが悪いのではなく、間に「橋」がかかっていないだけです。

非エンジニアがAWS SAAでつまずく原因は3つ

私の経験上、文系・非エンジニアがSAAの勉強で止まってしまう原因は、だいたい次の3つに集約されます。

原因① 専門用語を「言葉のまま」覚えようとしている

一番多いのがこれです。「EC2」「S3」「IAM」といった用語を、意味のイメージを持たないまま、ただ暗記しようとするパターンです。

たとえば Amazon EC2（Elastic Compute Cloud、クラウド上で借りられる仮想のパソコン・サーバー） を「イーシーツー」という記号として丸暗記しようとすると、すぐ忘れます。「これは、ネット上で月額で借りられるパソコンのことなんだな」と、身近なものに置き換えて理解できていないと、知識が頭に定着しないのです。

原因② 最初から満点を目指して、全部を完璧に理解しようとする

まじめな人ほど陥りがちです。1つのサービスの細かい仕様まで完璧に理解してから次へ進もうとして、最初の数サービスで力尽きてしまう。

SAAは満点を取る試験ではありません。合格ラインは1000点満点中720点と言われており、つまり全部を完璧に分からなくても受かる試験です。完璧主義は、非エンジニアにとってむしろ敵になります。

原因③ 手を動かさず、読むだけで終わっている

参考書を読むだけ、動画を観るだけで「勉強した気」になってしまうパターンです。

クラウドは、実際に画面を触ってみると「あ、こういうことか」と一気に腑に落ちることが多い世界です。読むだけだと、いつまでも他人事のような、ふわっとした理解のまま止まってしまいます。

「覚えられない」のではなく、「覚え方」と「進め方」がズレているだけなのです。

文系でも合格を目指せるAWS SAAの勉強法

では、勉強中の私が実際にやっていて「これは効く」と感じている方法を紹介します。難しいことはありません。

1. いきなりSAAから始めず、土台を作る

もしまだなら、ひとつ手前の クラウドプラクティショナー から始めるのを私は強くおすすめします。私もこの順番で進めました。

クラウドプラクティショナーは「AWSってそもそも何？」を広く浅く学ぶ資格です。ここで全体像をつかんでおくと、SAAの内容が「知ってる言葉が増えた状態」で入ってくるので、体感の難易度がぐっと下がります。遠回りに見えて、これが一番の近道でした。

2. 用語は「日常のたとえ」に置き換えて覚える

私は新しいサービスを覚えるとき、必ず「これは現実世界でいうと何か」を考えるようにしています。たとえば——

• Amazon S3（Simple Storage Service、データを保管しておく倉庫サービス） → 「クラウド上の、容量無制限の引き出し・物置」
• Amazon EC2 → 「ネットで月額レンタルできるパソコン」
• AWS IAM（Identity and Access Management、誰が何を操作できるかを管理する仕組み） → 「会社の入館証・鍵の管理係。誰がどの部屋に入れるかを決める人」

こうやって身近なものに翻訳すると、記号だった用語に意味が宿り、驚くほど忘れにくくなります。

3. 「動画講座 → 問題集 → 復習」の流れを回す

独学の王道ですが、非エンジニアこそこの順番が効きます。

まず動画講座で全体像をつかみ、次に問題集（模擬試験形式）をひたすら解き、間違えたところを動画や解説に戻って復習する。インプットとアウトプットを行ったり来たりするのがコツです。読むだけ・観るだけで終わらせないこと。

4. 余裕があれば、無料枠で実際に触ってみる

AWSには 無料利用枠（一定の範囲なら無料で使えるお試し枠） があります。原因③で書いたとおり、実際に画面を触ると理解が一気に進みます。

「サーバーを1台立ててみる」だけでも、EC2が一気に身近になります。情シスの現場でも、結局いちばん覚えるのは「自分で触ってみたとき」です。

おすすめ教材（私が実際に使っているもの）

勉強中の私が使っていて役立っていると感じる教材のタイプを挙げます。誇張なしの正直なところです。

• Udemyの日本語SAA対策講座：動画で全体像をつかむのに向いています。セール時に買うと安く手に入ることが多いです。初心者向けに丁寧な講座を選ぶのがポイント。
• 問題集（模擬試験形式の講座・書籍）：本番に近い形式で数をこなすのに必須。間違えた問題の解説が詳しいものを選ぶと、それ自体が参考書がわりになります。
• 入門書（一冊持っておくと安心）：全体像をパラパラ確認したいとき、紙の本は意外と便利です。

※教材は人によって相性があります。レビューや無料サンプルを確認してから、自分に合うものを選んでください。

完璧な一冊を探すより、「自分が続けられる教材」を選ぶことが合格への最短ルートです。

今日からできる具体的なアクション

「やる気はある。でも何から?」というあなたへ。今日からできることを小さく区切りました。

• 今の自分の位置を確認する：AWSの資格をまだ何も持っていないなら、まずクラウドプラクティショナーから。すでに持っているなら、SAAの試験範囲（公式サイトに出題範囲のガイドがあります）にざっと目を通す。
• 教材を1つだけ決める：あれこれ買い込まない。動画講座を1つ、または問題集を1つ。「これをやり切る」と決めるだけで前に進みます。
• 1日15分でいいので毎日触れる：まとまった時間より、毎日少しずつのほうが続きます。通勤中に動画を1本観る、でもOKです。
• 分からない用語を1日1つ「たとえ」に変換する：ノートに「S3＝クラウドの物置」のように書き溜めていくと、自分だけの辞書ができていきます。

大きく始める必要はありません。続けられる小ささから始めることが、非エンジニアにとって最大の武器です。

まとめ：文系・非エンジニアでもAWS SAAは目指せる

最後に、勉強中の私からお伝えしたいことをまとめます。

• 非エンジニアがSAAでつまずくのは能力のせいではなく、前提知識の「橋」がないだけ
• 用語は丸暗記せず、日常のたとえに置き換えると定着する
• 完璧を目指さず、続けられる教材ひとつで「インプットとアウトプットを往復」する
• 余裕があれば無料枠で実際に触ってみると理解が一気に進む

私自身もまだゴールの途中ですが、この進め方に変えてから「分からない」が「分かるかも」に変わってきた実感があります。同じように一歩を踏み出したいあなたの背中を、この記事が少しでも押せたなら嬉しいです。一緒に少しずつ進んでいきましょう。

関連記事：AWS資格（SAA）の始め方 関連記事：AWS SAA頻出用語30選

このブログでは毎週、その週に起きたAWSの主なアップデートを「ITに詳しくない情シス担当者の目線」でかみ砕いてお届けしています。今回は2026年6月第4週（6月中旬〜下旬）の動きをまとめました。

今週のAWS、ここが動きました

今週はちょうど、アメリカのニューヨークで開かれた「AWS Summit New York 2026」（AWSの大型イベント）の発表ラッシュがあった週でした。新しいサーバーや新しいAIモデル、そしてうれしい値下げまで、情シスの現場にじわじわ効いてくる話題が並びました。

正直に言うと、AWSのアップデートは毎週とんでもない数が出ます。私自身、全部を追いかけるのは到底ムリです。なので、この記事では「数で勝負」はしません。情シスや初心者の私たちに関係しそうな話だけ、4本にしぼって紹介します。

「わからなくて当然」のスタンスで進めますので、肩の力を抜いて読んでください。それでは今週のピックアップです。

今週のピックアップ

① AI向けの新しいGPUサーバー「Amazon EC2 G7」が正式提供開始

まず1本目は、AWSの定番サービスである Amazon EC2（Elastic Compute Cloud＝クラウド上の仮想サーバー）に、新しい種類のサーバー「G7インスタンス」が加わったというニュースです。2026年6月17〜18日のAWS Summit New Yorkで発表されました。

少しだけ用語の説明をすると、EC2は「クラウド上に好きなときに借りられるパソコン（サーバー）」のことです。そのEC2にはたくさんの種類があり、用途ごとに「これは計算が得意」「これは画像処理が得意」と分かれています。今回のG7は、その中でも「GPU（Graphics Processing Unit＝画像やAIの計算を高速にこなす専用部品）」を積んだ、いわば“AI・グラフィック特化型”のサーバーです。

NVIDIA（エヌビディア＝GPUで有名な半導体メーカー）の最新GPUを搭載していて、ひとつ前の世代「G6」と比べてAIの推論（学習済みのAIが答えを出す処理）が最大4.6倍、グラフィック性能が最大2.1倍速くなったとされています。

情シス・初心者目線のポイント: 「自社でAIを動かしたいけど、社内のパソコンじゃ非力すぎる」というとき、必要な時間だけこういう高性能サーバーを借りられるのがクラウドの強みです。高価なAI用パソコンを買い切る必要がなく、使った分だけ払えばよい。情シスとしては「設備投資（買い切り）」を「経費（使った分だけ）」に変えられるのが地味に大きいんですよね。

出典：Top announcements of the AWS Summit in New York, 2026（AWS公式ブログ）

② AIモデル「Grok 4.3」がAmazon Bedrockで使えるように

2本目は、AIを使う窓口サービス Amazon Bedrock（ベッドロック＝いろいろなAIモデルをまとめて呼び出せるAWSのサービス）に、新しいAIモデル「Grok 4.3」が追加されたというニュースです。6月22日のAWS公式まとめ記事で紹介されました。

Bedrockを一言で言うと、「いろんな会社のAIを、ひとつの窓口からまとめて呼び出せる受付カウンター」のようなサービスです。今回そのカウンターに、xAI（イーロン・マスク氏が関わるAI企業）の「Grok 4.3」というモデルが新しく並びました。ツール連携（AIに外部の機能を使わせる仕組み）や、回答を少しずつ表示するストリーミング出力にも対応しています。

情シス・初心者目線のポイント: ここで大事なのは「選択肢が増えた」という点です。社内でAIを使うとき、AIモデルは1社のものに縛られると、料金や性能の都合で困ることがあります。Bedrockのように複数モデルを同じ窓口から切り替えられると、「この用途は安いモデル、ここは賢いモデル」と使い分けができます。私自身、社内ツールを検討するときも“1社に依存しすぎない”構成は安心材料になります。

出典：AWS Weekly Roundup（June 22, 2026・AWS公式ブログ）

③ 「Amazon S3 Vectors」の検索コストが最大80%値下げ

3本目は、私たち非エンジニアでも素直にうれしい「値下げ」のニュースです。Amazon S3 Vectors（エススリー・ベクターズ）という、AI向けのデータ保管サービスの検索料金が、大規模な利用で最大80%下がりました。2026年6月16日付の発表です。

用語をかみ砕きます。まずS3（Amazon Simple Storage Service＝クラウド上の巨大な保管庫）は、AWSでいちばん有名な「データの引き出し」のようなサービスです。その派生版である「S3 Vectors」は、AIが意味の近いデータを探すための“ベクトル”という特殊なデータを安く保管・検索できるサービスです。チャットボットなどに社内文書を覚えさせる「RAG（検索拡張生成＝AIに資料を参照させて答えさせる仕組み）」でよく使われます。

今回は、1,000万件を超えるような大量のデータを扱うケースで、検索時の処理料金が最大80%下がりました。しかもアプリの作り直しは不要で、自動的に新しい料金が適用されるとのことです。

情シス・初心者目線のポイント: クラウドは「気づいたら請求が膨らんでいた」が起きやすい世界です。だからこそ、何もしなくても勝手に安くなる値下げは純粋にありがたい。社内向けAIチャットなどを検討している会社なら、ランニングコストのハードルが少し下がったと言えます。

出典：AWS Weekly Roundup（June 22, 2026・AWS公式ブログ）

④ ベトナム・ハノイに新しい「AWS Local Zone」が開設

4本目は、AWSの拠点がひとつ増えたというニュースです。2026年6月、ベトナムの首都ハノイに新しい「AWS Local Zone（ローカルゾーン）」が正式に開設されました。

Local Zoneとは、ざっくり言うと「大都市の近くに置かれた、AWSの小さな出張所」のようなものです。AWSの本拠点（リージョン）は世界の限られた場所にしかありませんが、利用者の近くに小さな拠点を置くことで、通信の遅れ（遅延）を減らせます。今回のハノイ拠点は、アジア太平洋で初期に S3 や EBS（Elastic Block Store＝サーバーにつなぐ仮想ハードディスク）のローカルスナップショット（その場でのバックアップ）に対応した点が特徴です。

情シス・初心者目線のポイント: ここで効いてくるのが「データの置き場所のルール」です。国や業界によっては「データを国外に出してはいけない」という決まり（データレジデンシー要件）があります。現地に拠点ができると、その国の中にデータを置いたまま使えるようになります。海外拠点を持つ会社の情シスにとっては、コンプライアンス上の選択肢が増える話です。日本の私たちには直接関係が薄いかもしれませんが、「AWSはこうやって各国の事情に合わせて拠点を増やしている」という流れを知っておくと、世界の動きが見えてきます。

出典：Announcing the general availability of a new AWS Local Zone in Hanoi, Vietnam（AWS公式）

私が気になったのはこれ

今週いちばん私の心に刺さったのは、3本目の「S3 Vectorsの最大80%値下げ」でした。

新サービスのワクワクも好きですが、情シスの現場でいちばんありがたいのは、結局「黙っていても安くなる」というニュースなんですよね。

というのも、社内でAIを使いたいという声が増える一方で、経営層からは必ず「で、月いくらかかるの?」と聞かれます。新機能の派手さより、ランニングコストが下がる事実のほうが、稟議（社内の予算承認）を通すうえでは何倍も強い。今回のような値下げは、AI活用を「検討」から「実行」に動かす後押しになると感じました。

今週のまとめ

2026年6月第4週のAWSは、(1) AI向け新サーバー「EC2 G7」、(2) Bedrockの新AIモデル「Grok 4.3」、(3) S3 Vectorsの最大80%値下げ、(4) ハノイの新Local Zone、という4本が目立ちました。

全体として「AIをもっと安く・もっと身近に」という方向に、AWSがじわじわ舵を切っているのを感じます。難しそうに見える発表も、こうして1本ずつ「自分の仕事に関係あるか?」で見ていけば、意外と怖くありません。来週もその週の動きを、初心者目線で追いかけていきます。

「そもそもS3やEC2って何?」というところからおさらいしたい方は、過去の入門記事もあわせてどうぞ。

関連記事：先月の週間AWSニュースはこちら 関連記事：そもそもAWSとは？初心者向けの基本

AWSの管理画面を前にフリーズしていませんか？

「とりあえずAWSのアカウントを作ってみたものの、最初に何をすればいいのか全然わからない…」

情シスの現場では、こういう状況、本当によくあります。私自身も、初めてAWSの管理画面（コンソール）にログインしたとき、ボタンとメニューが多すぎて完全にフリーズしました。とくに「IAM」という見慣れない言葉が出てきた瞬間、「あ、これは難しいやつだ」と画面をそっと閉じたくなったのを覚えています。

ここで言うIAM（Identity and Access Management＝AWSの中で「誰が」「何を」操作してよいかを管理する仕組み）は、AWSのセキュリティの土台です。でも名前が固いだけで、やることはそこまで複雑ではありません。

「わからなくて当然」です。みんな最初は同じところでつまずいています。

実は「最初の設定をしないこと」が一番危ない

AWSは便利な反面、設定を間違えると会社にとって大きなリスクになります。とくに怖いのが、何も設定しないまま使い始めてしまうことです。

たとえるなら、新しいオフィスの玄関の鍵を一度もかけずに、毎日全開のまま帰宅しているようなものです。中に大事な書類（会社のデータやサーバー）があるのに、誰でも入れる状態。これがAWSで言う「初期設定をしていない」状態です。

しかもAWSは世界中からアクセスできるクラウドサービスなので、悪意のある人があなたのアカウントを狙ってくる可能性があります。万が一乗っ取られると、勝手に高額なサーバーを大量に起動されて、ある朝とんでもない金額の請求が届く…という事例も実際にあります。情シスとしては、絶対に避けたい事態です。

最初の30分の設定をサボると、後で何十万円の請求と徹夜対応が待っているかもしれません。

なぜ多くの人が初期設定でつまずくのか、原因は3つある

原因① 「ルートユーザー」をそのまま使ってしまう

AWSアカウントを作ると、最初に「ルートユーザー」という最強の権限を持つアカウントが手に入ります。ルートユーザー（root user＝アカウント内のすべての操作ができる、いわば「社長の鍵」）は、何でもできてしまう分、漏れたときの被害が最大級です。

多くの人が、このルートユーザーで毎日ログインして作業してしまいます。社長の鍵を全社員に配って日常業務に使わせているようなもので、とても危険です。

原因② 二段階認証（MFA）を設定していない

ログインがパスワードだけだと、そのパスワードが漏れた時点でアウトです。MFA（Multi-Factor Authentication＝多要素認証。スマホアプリなどで出る一時的な数字も入力させる仕組み）を設定しておけば、パスワードが漏れても、もう一つの鍵がないと入れません。

銀行のネットバンキングでスマホに届くワンタイムパスワードを入れるのと同じ仕組みです。便利で安全なのに、面倒くさそうという理由で後回しにされがちです。

原因③ 全員に「何でもできる権限」を渡してしまう

チームでAWSを使うとき、一人ひとりに専用のユーザーを作るのが基本です。ところが「設定が面倒だから」と、全員に管理者権限（何でもできる権限）を配ってしまうケースが後を絶ちません。

これは、全社員にビルのマスターキーを渡すようなもの。一人がうっかり大事な設定を消しても、誰がやったのか追えなくなります。

私が以前いた現場でも、「とりあえず全員に管理者権限を渡しておこう」という運用になっていたことがありました。普段は何も問題が起きないのですが、いざ「先月のあの設定変更、誰がやったの？」という話になったとき、全員が同じ権限を持っているせいで、まったく追跡できなかったのです。権限をきちんと分けておくことは、トラブルを防ぐだけでなく、「あとから振り返れる」ようにするためにも大切なんだと痛感しました。

解決方法：最初にこの3つをやるだけでOK

難しく考える必要はありません。情シスの現場でも、まずは次の3ステップを順番にやれば、最低限の安全は確保できます。

1. ルートユーザーは封印して、作業用のユーザーを別に作る

ルートユーザーでの作業はやめて、IAMで自分専用の「作業用ユーザー」を作ります。普段はこの作業用ユーザーでログインし、ルートユーザーは大事な金庫にしまうイメージで、ほとんど触らないようにします。

2. ルートユーザーと作業用ユーザーの両方にMFAをかける

スマホに認証アプリ（Google Authenticatorなど）を入れて、ログイン時に一時的な数字を求められるように設定します。これだけで、パスワードが漏れても乗っ取りをかなり防げます。

3. 権限は「必要な分だけ」渡す

AWSには「最小権限の原則」という考え方があります。これは「その人の仕事に必要な権限だけを渡す」という、とてもシンプルなルールです。経理担当者に開発サーバーをいじる権限はいらない、という発想です。最初は難しければ、まず管理者を自分だけに絞るところから始めれば十分です。

少し補足すると、AWSには「IAMポリシー」という、権限のルールを書いた書類のような仕組みがあります。IAMポリシー（IAM policy＝「このユーザーは何をしてよいか」を定めた設定ファイル）と聞くと身構えてしまいますが、AWSがあらかじめ用意してくれている「テンプレート（既製のひな形）」を選ぶだけでも十分始められます。最初から自分でゼロから書く必要はありません。ここも「わからなくて当然」のポイントなので、まずは用意されたものを使えばOKです。

また、複数人で使う場合は、似た仕事をする人をひとまとめにする「IAMグループ」という機能も便利です。たとえば「経理チーム」というグループを作り、そこに必要な権限をまとめて設定しておけば、新しいメンバーが入ったときもグループに追加するだけで済みます。一人ひとりに毎回手作業で権限を設定する手間が省け、設定ミスも減らせます。

セキュリティは「全部完璧に」ではなく「危ない順に一つずつ」で大丈夫です。

今日からできる具体的なアクション

いきなり全部やろうとすると挫折します。まずは今日、次の3つだけ進めてみてください。

AWSコンソールにルートユーザーでログインし、「セキュリティ認証情報」の画面からMFAを有効にします。所要時間は5分ほど。これだけで乗っ取りリスクが大きく下がります。

• その1：ルートユーザーにMFAを設定する

IAMの画面で、自分が日常作業に使うユーザーを作成します。明日からはこのユーザーでログインする、と決めてしまいましょう。

• その2：自分用のIAMユーザーを1つ作る

「いくら以上使ったらメールで知らせる」という金額の見張り番（請求アラート）を設定しておくと、万が一の不正利用にすぐ気づけます。情シスとしては安心材料になります。

• その3：請求アラートを設定しておく

私自身も、最初はMFAの設定だけで「今日はここまで」と区切りました。一気にやらなくていいんです。一つ設定するたびに、確実に会社のアカウントは安全になっていきます。

まとめ：最初の一歩がいちばん大事

AWSのIAMは、名前こそ難しそうですが、やるべきことは「ルートユーザーを守る」「MFAをかける」「権限を絞る」というシンプルな3点です。

完璧を目指す必要はありません。今日できる一つの設定が、未来の自分と会社を大きなトラブルから守ってくれます。 私もCloud Practitionerの勉強を始めた頃、このIAMの考え方が一番つまずきポイントでしたが、現場で触りながら少しずつ理解していきました。あなたも焦らず、一つずつで大丈夫です。

まずは今日、ルートユーザーのMFA設定から始めてみてください。

関連記事：クラウドとは？AWSの基本をやさしく解説 関連記事：AWSのパスワードを自動で更新する仕組み（Secrets Manager）

歴史を学ぶ意味は「過去を知ること」だけではありません。流れを理解することで、未来の変化を先読みできるようになります。

2020年代のAWSは「AI」へ大きく舵を切った

クラウドの「次」はAIです。AWSは今、AIをすべてのサービスの中心に据えています。

2023年、AWSはAmazon Bedrock（アマゾン ベドロック）をリリースしました。これは、Claude（クロード）・Llama（ラマ）などの大型AIモデルを、AWSのインフラ上で手軽に使えるようにしたサービスです。

わかりやすく言うと、「AIを自社のシステムに組み込むための部品箱」です。従来はAIを使うためにデータサイエンティストやAIエンジニアが必要でしたが、Bedrockを使えばAWSの操作ができるエンジニアがAIを活用したサービスを作れるようになりました。

「AIエージェント」が変えるシステムの姿

「AIが自律的に動いて仕事をする」時代が、すでに始まっています。

2025〜2026年、AWSはAIエージェント（自律的に判断・行動するAI）に関するサービスを次々と提供し始めました。前回の週間ニュースで紹介した「Bedrock AgentCore Payments」もその一例です。

AIエージェントとは、人間から「〇〇をして」と指示を受けたAIが、必要な情報を収集し、判断し、外部サービスを呼び出し、結果を返す——という一連の作業を自律的に行う仕組みです。

たとえば「来月の社内研修の候補日程を3つ出して、参加者に確認メールを送って」という指示をAIに出すと、カレンダーを参照し、メールを作成し、送信まで自動でやってくれる——そんな世界が現実になりつつあります。

AWSの歴史から見えてくる「変わらない原則」

20年のAWSの歴史を振り返ると、変わらない原則が見えてきます。

第1回から振り返ってみましょう。

• 第1回：Amazonは「自社の困りごと」を解決する仕組みを作り、それを外部に開放した
• 第2回：S3・EC2は「初期費用ゼロ・使った分だけ」という新しいコスト概念を生んだ
• 第3回：先行・値下げ・エコシステムで競合を圧倒した
• 第4回：災害という危機が、クラウドへの「信頼」を生んだ

すべてに共通するのは「現実の問題を解決することで、価値を生み出してきた」という姿勢です。AIも同じです。「便利そうだから」ではなく「現場の課題を解決できるから」使われていく——AWSはその流れを作り続けています。

これからの情シス担当者に求められること

情シスの役割は「なくなる」のではなく「進化する」のです。

よく「AIが普及すると情シスの仕事はなくなるのでは？」という声を聞きます。私はそう思いません。むしろ、情シス担当者の重要性は高まると考えています。

理由は3つあります。

• AIを「使わせる側」の判断は人間が行う：どのAIツールを社内に導入するか、セキュリティポリシーをどう設定するか——これは人間の判断が必要です
• 「AIが間違えたとき」に気づける人が必要：AIは完璧ではありません。出力を評価・修正できる知識を持った人が社内に必要です
• コスト管理はますます複雑になる：AIサービスの利用コストはわかりにくく、適切に管理できる人材が求められます

私自身がAWS SAAの勉強を続けているのも、「クラウドとAIが組み合わさった時代に、判断できる情シス担当者でいたい」という気持ちからです。

今日からできること

1. Amazon Bedrockのドキュメントを一度読んでみる：難しくても「こんなものがある」と知るだけで十分です
2. 「社内でAIをどう使うか」を考え始める：情シスとして先手を打てます
3. AWS認定資格（Cloud Practitionerから）を検討する：歴史・仕組みを体系的に学べます

連載のまとめ：AWSの歴史は「変化に適応した歴史」

5回にわたってAWSの歴史を振り返りました。最後に整理します。

歴史を知ることは、現在地を知ることです。そして現在地がわかれば、次の一手が見えてきます。

この連載が、AWSを「なんとなく使うもの」から「なぜ使うのかがわかるもの」に変えるきっかけになれば幸いです。ぜひSAAの勉強も一緒に進めていきましょう。

前の記事：【AWS歴史 第4回】東日本大震災が変えた日本のIT｜AWS普及の転換点
関連記事：AWS SAA試験の勉強法【情シス担当者が実践する3つの方法】

「自社のサーバーが止まった」「データセンターへの道が寸断された」「バックアップが同じ建物にあって使えない」——。

私自身はまだ社会人になっていない時期でしたが、後に情シス部門へ配属されてから、あの震災が日本のIT業界をいかに変えたかを先輩から繰り返し聞きました。日本のクラウド移行を一気に加速させた「転換点」として、今でも語り継がれています。

震災前の日本企業：「オンプレミス」が当たり前だった

2011年以前の日本企業のほとんどは、自社内や契約したデータセンターにサーバーを置いていました。

「オンプレミス（On-Premises）」と呼ばれるこの方式は、「自社でサーバーを所有・管理する」形態です。メリットは「すべてを自分でコントロールできる」こと。デメリットは「何か起きたとき、すべて自分で対応しなければならない」ことです。

震災前の日本では「クラウドは便利かもしれないが、セキュリティが心配」「重要なデータを外部に預けるのは怖い」という保守的な意見が主流でした。大企業ほど、その傾向は強くありました。

震災が暴いた「オンプレミスの弱点」3つ

自然災害の前では、物理的なサーバーはあまりにも脆弱でした。

弱点① 物理的な被害に無力

建物が損壊すれば、中のサーバーも終わりです。停電になればシステムは止まります。地震・津波・火災。物理的なインフラはすべての自然災害に対して根本的な弱点を持っていました。

弱点② BCP（事業継続計画）の実態が追いついていなかった

BCP（Business Continuity Plan：事業継続計画）とは、災害や障害が起きても事業を続けられるよう事前に備えておく計画のことです。多くの企業がBCPを「策定していた」ものの、実際にはバックアップのサーバーも被災地の同じエリアにあったり、復旧手順が現実的でなかったりと、機能しないケースが続出しました。

弱点③ リモートワークができなかった

社内のサーバーにしかアクセスできない環境では、オフィスに来られない状況でまったく仕事ができません。震災後の計画停電・交通機関の混乱・避難勧告……。「会社に来ないと仕事ができないIT環境」の脆さが浮き彫りになりました。

震災後の変化：クラウドへの「信頼」が一気に高まった

震災後、「クラウドは危ない」という意見は「クラウドの方が安全かもしれない」に変わっていきました。

被災地から離れたデータセンター（AWSの場合、日本リージョン以外にもシンガポールや米国にサーバーがある）にデータを預けていれば、地元の災害でデータは守られます。インターネットさえつながれば、どこからでもアクセスできます。

AWSは2011年3月に東京リージョン（ap-northeast-1）を開設しました。震災の直後というタイミングでの東京リージョン開設は、日本企業のAWS移行を象徴する出来事でした。

また、2013年には政府が「政府情報システムのクラウド化方針」を策定。行政のシステムにもクラウドを使う方向性が打ち出され、企業における「クラウドは信頼できる」という認識が加速していきました。

情シスの仕事が変わった：「守る人」から「設計する人」へ

クラウド移行は、情シス担当者の役割そのものを変えました。

オンプレミス時代の情シスは「サーバーを守る」仕事が中心でした。ハードウェアの交換、OSのアップデート、バックアップの確認……。しかしクラウドに移行すると、これらの多くはクラウドベンダーが担ってくれます。

代わりに求められるようになったのは「どのクラウドサービスをどう組み合わせるか」「セキュリティ設定をどう設計するか」「コストをどう最適化するか」という設計・判断の仕事です。私自身、この変化を感じているからこそAWSの勉強を続けています。

今日からできること

1. 自社のBCPを確認する：クラウドをどう位置づけているか把握しておきましょう
2. 「なぜクラウドを使っているか」を説明できるようにする：上司や経営層への説明に、震災の教訓は説得力があります
3. 次回（第5回・最終回）へ進む：AIとクラウドが変える「これからの情シスの仕事」を解説します

まとめ

• 東日本大震災は「オンプレミスの弱点」を一気に顕在化させた
• AWS東京リージョンの開設（2011年）が日本のクラウド移行を後押しした
• 情シスの役割は「サーバーを守る」から「クラウドを設計・判断する」へ変化した

災害という悲しい出来事が、日本のITを一段階進化させました。その流れの上に、私たちは今立っています。次回は、AWSの現在とこれからを解説します。

前の記事：【AWS歴史 第3回】なぜAWSはGoogleに勝ったのか？クラウド覇権の理由
次の記事：【AWS歴史 第5回】AIとクラウドが変える情シスの仕事｜AWSの現在と未来

Google（グーグル）はAmazonよりずっと前からデータセンターを持ち、大規模なシステムを運用していました。Microsoft（マイクロソフト）はWindowsで企業のIT基盤を押さえていました。なのになぜ、後発のAmazonがクラウド市場のトップに立てたのでしょうか。

今回は、AWSが覇権を握った3つの理由を解説します。

理由①「先に始めた」という絶大な優位性

クラウド市場では「先に始めた者」が、ほぼ永続的な優位性を持ちます。

AWSがS3・EC2を提供し始めた2006年当時、GoogleもMicrosoftもまだクラウドサービスを一般企業向けに提供していませんでした。Google Cloud（グーグル クラウド）の一般提供は2011年、Microsoft Azure（マイクロソフト アジュール）の一般提供は2010年です。

AWSには4〜5年のリードがありました。この間にAWSは何をしていたか。サービスをどんどん増やし、使いやすくし、価格を下げ続けていました。

2006年から2010年の間、AWSはサービス数を2つから約30に増やし、料金を複数回にわたって引き下げました。「まずAWSで始めてみる」という文化がエンジニアの間に根付いた頃、GoogleとMicrosoftがようやく市場に参入してきたわけです。

理由②「値下げ」を武器にした価格戦略

AWSは「値下げ」を競争優位の武器として積極的に使いました。

2006年のサービス開始から2014年までの間に、AWSはなんと40回以上の値下げを実施しています。競合他社が追いついてくると値下げし、さらにシェアを広げる——このサイクルを繰り返しました。

この戦略が機能した背景には「規模の経済」があります。ユーザーが増えるほど、データセンターの設備費・運用費を多くの顧客で分担できます。つまり「使う人が増えるほど、一人あたりのコストが下がる」仕組みです。

スーパーの「大量仕入れで安く売る」と同じ原理です。先行してシェアを取ったAWSは、この規模の経済で競合を引き離していきました。

理由③「エコシステム」という参入障壁

AWSを使いこなすための「周辺環境」が整いすぎて、他に移れなくなっていきました。

2010年代に入ると、AWSを前提とした様々な製品・サービス・書籍・資格が生まれてきます。「AWS認定資格（AWS Certified）」もその一つです。

企業がAWSを使い始めると、社内のエンジニアはAWSの使い方を覚えます。システムもAWSの機能を前提に設計されます。取引先との連携もAWS経由になっていく。こうして「AWSから他のクラウドに移るのは、コストと手間がかかりすぎる」という状態が生まれます。これを「ベンダーロックイン（乗り換えが難しくなること）」と言います。

悪い意味ではなく、AWSが「使い続けたくなる理由」を積み重ねてきた結果とも言えます。

Netflixの事例：大企業がAWSに移行した理由

「大企業もクラウドに移る」流れを決定づけたのがNetflixの決断でした。

世界最大の動画配信サービスNetflix（ネットフリックス）は、2008年にデータセンターで大規模な障害が発生し、DVDの発送が3日間停止するという事件を経験します。これを機に「自社でサーバーを持つのはリスクが高い」と判断し、AWSへの全面移行を決断しました。

2016年に移行が完了したNetflixは、世界190か国のユーザーを、AWSだけで支えるようになりました。この事例が世界中の大企業に「クラウド移行は現実的だ」という確信を与えました。

今日からできること

1. 自社が使っているクラウドを確認する：AWS・Azure・GCPのどれかわかると、現在のシェア状況がリアルに理解できます
2. 「乗り換えコスト」を意識してみる：ベンダーロックインは自社のシステムにも起きていないか考えてみましょう
3. 次回（第4回）へ進む：日本でAWSが普及するきっかけになった「東日本大震災」との関係を解説します

まとめ

• AWSは4〜5年の先行優位で市場を確保した
• 40回以上の値下げで「使うほど安くなる」サイクルを作った
• エコシステムの充実で「AWSから離れにくい」状態を築いた

AWSの強さは「最初に走り出した」こと、そして「走り続けた」ことにあります。次回は、日本でAWSが爆発的に普及するきっかけとなった出来事を振り返ります。

前の記事：【AWS歴史 第2回】「サーバーを買わなくていい」革命｜S3・EC2が変えた世界
次の記事：【AWS歴史 第4回】東日本大震災が変えた日本のIT｜AWS普及の転換点

今では当たり前になったクラウドですが、2006年以前のIT業界では「システムを動かすにはサーバーを買う」のが常識でした。その常識を根本から壊したのが、AWSが2006年にリリースした2つのサービスです。

今回は、Amazon S3（Simple Storage Service）とAmazon EC2（Elastic Compute Cloud）の登場が、IT業界にどんな衝撃を与えたかを解説します。

2006年以前：「サーバーを持つ」のが当たり前だった時代

当時のIT担当者にとって、サーバーは「買うもの」でも「借りるもの」でもなく、「管理するもの」でした。

Webサービスやシステムを作りたい企業は、まず高額なサーバー機器を購入するところから始めます。それをデータセンターや自社のサーバー室に設置し、OSをインストールし、ネットワークを設定し……と、サービスが動くまでに数週間〜数ヶ月かかることも珍しくありませんでした。

情シス担当者の仕事の大部分は「このサーバーをどう維持するか」でした。停電対策、冷却設備、ハードウェア故障への対応……。「システムを動かす」ことより「サーバーを守る」ことに時間を取られていたのです。

S3の衝撃：「ファイル置き場」がクラウドに移った日

S3の登場は「データの保管場所」という概念を根本から変えました。

2006年3月にリリースされたAmazon S3（Amazon Simple Storage Service）は、インターネット上に大量のデータを保存・取り出しできるサービスです。わかりやすく言うと、「インターネット上にある巨大な引き出し」です。

それまで企業は、画像・動画・ログデータなどを保存するために専用のストレージ（保存装置）を購入していました。S3はそれを「必要な分だけ、使った分だけ課金」で提供しました。

料金は当初1GBあたり月0.15ドル（約17円）。初期費用ゼロ、容量無制限。この衝撃は、IT業界の人々には「ありえない」と感じられるほどのものでした。

EC2の衝撃：「コンピューターを借りる」という発想

EC2は「コンピューターは買うもの」という20年来の常識を壊しました。

2006年8月にベータ版がリリースされたAmazon EC2（Elastic Compute Cloud）は、仮想サーバー（仮想コンピューター）をインターネット越しに借りられるサービスです。

「仮想サーバー」というのは、1台の物理的なサーバーの中に、複数のサーバーが動いているような状態です。レンタルオフィスをイメージするとわかりやすいでしょう。大きなビルの中に、複数のテナントが独立したオフィスを構えているイメージです。

EC2の革命的だった点は3つあります。

• 数分で使い始められる：従来は数週間かかっていたサーバー調達が、数分で完了
• 必要なときだけ使える：繁忙期だけサーバーを増やし、終わったら削除。無駄なコストゼロ
• 世界中から使える：地理的な制約なし。日本にいながら米国のサーバーを使える

誰が最初に飛びついたか？スタートアップ企業の革命

S3とEC2が最初に普及したのは、大企業ではなくスタートアップ（新興企業）でした。

理由は単純です。スタートアップは資金が少ない。でも大きなサービスを作りたい。そこに「初期費用ゼロ、使った分だけ払えばいい」というAWSが登場したのです。

たとえば、写真共有サービスのSmugmug（スマグマグ）は、S3リリース直後に採用し「ストレージコストが大幅削減できた」と公言しました。また、現在では世界最大の動画配信サービスであるNetflix（ネットフリックス）も、2008年ごろからAWSへの移行を始めます。

「大きなサービスを立ち上げるのに、もはや多額の設備投資は必要ない」——この事実が、世界中の起業家に希望を与えました。

情シス担当者として今日できること

1. 自社でS3かEC2を使っているか確認する：多くの企業でこの2つが基盤になっています
2. 「オンプレミスとクラウドの違い」を整理してみる：S3・EC2の登場前後で何が変わったかを考えると理解が深まります
3. 次回（第3回）へ進む：AWSがGoogle・Microsoftを抑えてシェアトップになった理由を解説します

まとめ

• S3は「データの保管場所」をクラウドへ移した。容量無制限・使った分だけ課金という革命的なサービス
• EC2は「コンピューターは買うもの」という常識を壊した。数分で使い始められる仮想サーバー
• 最初に飛びついたのはスタートアップ企業。初期費用ゼロが、新しいビジネスの可能性を大きく広げた

S3とEC2の登場は、「大企業だけがITに投資できる時代」の終わりを告げました。次回は、なぜAWSがGoogleやMicrosoftを抑えてトップシェアを獲得できたのかを解説します。

前の記事：【AWS歴史 第1回】AWSはなぜAmazonが作った？誕生の秘密
次の記事：【AWS歴史 第3回】なぜAWSはGoogleに勝ったのか？クラウド覇権の理由

同じように感じている方は多いのではないでしょうか。この連載では、AWSがどのように生まれ、なぜここまで普及したのかを5回にわたって解説します。歴史の流れを知ると「なるほど、だからこういう仕組みになっているのか」と腑に落ちる瞬間がたくさんあります。

AWSは「Amazonが自分たちのために作ったもの」だった

AWSの誕生は、Amazonが自社のIT問題に悩み抜いた結果でした。

2000年代初頭、Amazonはネット通販として急成長していました。毎年倍々で増えるユーザー、商品数、注文数。それを支えるサーバーやシステムも、どんどん増設する必要がありました。そこで3つの深刻な問題が起きます。

問題① 新機能を作るたびに「インフラ整備」から始めなければならない

Amazonは当時、おすすめ機能・レビュー機能・ショッピングカートなど次々と新機能を開発していました。しかし開発チームが「新機能を作りたい」と思うたびに、まずサーバーを用意し、ネットワークを設定し、ストレージを確保する……という作業が必要でした。

たとえるなら、「料理を作りたいのに、毎回ゼロからキッチンを建設しなければならない」ような状態です。

問題② サーバーの「もったいない問題」

ECサイトには年末年始・セール期間など、アクセスが集中する時期があります。この繁忙期に合わせてサーバーを用意すると、普段はサーバーの大半が「遊んでいる」状態になります。多い時期に合わせて用意したサーバーが、閑散期はほとんど使われない。でも電気代や維持費はかかり続ける。非常に非効率な状態でした。

問題③ チームごとにバラバラなシステムが乱立

急成長に伴い、開発チームの数も増えました。チームごとに「自分たちのやり方」でシステムを作ると、同じような機能をチームAとチームBがそれぞれ作ってしまう「二重投資」が発生。全体の整合性が取れなくなっていきました。

解決策：「社内共通インフラ」を作り、みんなで使い回す

Amazonが出した答えは「共通インフラを作って社内全体で使い回す」でした。

2002年ごろ、創業者ジェフ・ベゾスは社内に有名な「API Mandate（エーピーアイ マンデート）」という命令を出します。要約すると「すべてのチームは、自分たちのデータや機能を、外部から呼び出せる形式で公開せよ」というものです。

これにより、Amazonの社内は「サービスをモジュール（部品）として組み合わせる」仕組みへと変わっていきました。そしてこの共通インフラを整備する中で、Amazonの技術者たちはあることに気づきます。

「これ、Amazon以外の会社にも売れるんじゃないか？」

自社の悩みを解決した仕組みが、他社にとっても価値があると気づいた瞬間でした。

2006年、AWSが世界へ

「自分たちの悩みを解決した仕組み」が、世界を変えるサービスになりました。

2004年に社内向け実験を始め、2006年、ついに外部向けサービスとして「Amazon Web Services（AWS）」を正式提供開始。最初にリリースされたのは主に2つのサービスです。

• Amazon S3（Simple Storage Service）：インターネット上にファイルを保存・取り出しできるサービス。「クラウド上の引き出し」です
• Amazon EC2（Elastic Compute Cloud）：インターネット上でコンピューターを自由に借りられるサービス

「サーバーを自分で買わなくていい」「使った分だけ料金を払えばいい」という革命的な発想が、ここから始まりました。

今日からできること

1. 自社のシステムがどこで動いているか確認してみる：クラウドを使っているなら、そのメリットが歴史から見えてきます
2. 「AWSがなければ何が困るか」を想像してみる：インフラの重要性を実感できます
3. 次回（第2回）へ進む：S3とEC2が実際にどんな衝撃を業界に与えたかを解説します

まとめ

• AWSは、AmazonがECサイト運営の「IT問題」を解決するために作ったシステムが起源
• 「インフラ整備の非効率」「サーバーのムダ」「チームの乱立」という3つの問題がAWSを生んだ
• 2006年にS3とEC2を外部提供開始。クラウドの時代が幕を開けた

「なぜAmazonがクラウドを作ったのか」がわかると、AWSの設計思想がすべて腑に落ちてきます。次回は、S3とEC2の登場が世界にどんな衝撃を与えたかを解説します。

関連記事：AWS SAA試験の勉強法【情シス担当者が実践する3つの方法】
次の記事：【AWS歴史 第2回】「サーバーを買わなくていい」革命｜S3・EC2の衝撃

私自身も、AWSの勉強をしながら現場の業務をこなしていると、最新情報を追いかける時間がなかなか取れません。

そこで今回は、2026年5月第2週のAWSニュースの中から「情シス担当者として知っておきたい3本」を選んで、わかりやすく解説します。今週はとくに「AIがお金を払う」という、ちょっと衝撃的なニュースが出ました。一緒に確認していきましょう。

今週いちばんの衝撃：AIエージェントが「自分でお金を払う」

AIはもはや「使う道具」ではなく、「動く社員」になりつつある。

まず今週の最大トピックから。AWSが「Amazon Bedrock AgentCore Payments（ベドロック エージェントコア ペイメント）」というサービスのプレビューを発表しました。

一言で言うと、AIエージェント（自律的に動くAIプログラム）が、人間の指示なしにお金を払って外部サービスを利用できるようになった、というものです。

どういうこと？具体的に説明します

たとえば、こんな場面を想像してください。

「AWS上で動いているAIに『競合他社の最新情報をまとめて』と頼む。AIは外部の有料データAPIに自動でアクセスし、料金を支払い、結果だけを報告してくる。」

従来は「外部のAPIを使う → 請求が発生する → 人間が承認する」という流れが必要でした。それが今後はAIが自律的にセッション単位で予算を管理しながら決済まで完了できるようになります。

決済はCoinbaseとStripeが担当

支払いの仕組みは、Coinbase（コインベース）とStripe（ストライプ）という2社が担当しています。

• Coinbase連携：USDCというステーブルコイン（価格が安定した暗号通貨）で決済
• Stripe連携：クレジットカードや銀行口座から普通の法定通貨で決済

どちらも「セッションごとに使える上限金額を設定できる」ので、AIが勝手に無制限に使うわけではありません。

情シス担当者として気になること

「それって、セキュリティ大丈夫なの？」と思った方、鋭いです。現時点ではプレビュー（試験運用）段階です。利用前にエンドユーザーが明示的に承認する仕組みになっており、いきなり財布の中身が全部使われるような設計にはなっていません。

ただ、将来的にはホテル予約や出張手配までAIが行えるようにする計画がAWSにはあるようです。経費精算の承認フローや稟議プロセスが根本から変わる可能性があり、情シスとしては「社内のルール整備」を今から考えておく必要があるかもしれません。

2本目：AIがAWSを「操作」するツールが登場

「AIにシステム構築を任せる」時代が静かに始まっている。

次のニュースは「Agent Toolkit for AWS（エージェント ツールキット フォー エーダブリューエス）」の発表です。これはひとことで言うと、AIコーディングエージェント（コードを自動で書くAI）がAWSのサービスを使いこなすための道具箱です。

具体的には何ができる？

• AIがAWS公式ドキュメントを参照しながらコードを書く
• AWSのサービス（S3やLambdaなど）に自動でアクセスして設定を確認する
• エラーが出たら、AIが自分でAWSのログを調べて対応策を提案する

これは「AWS MCP Server（エムシーピー サーバー）」という技術をベースにしていて、AIツールとAWSサービスをつなぐ”橋”の役割を果たしています。

情シス目線での読み解き

エンジニアがいない情シス部門にとっては、少し遠い話に聞こえるかもしれません。ただ、「AIにAWSの構築を任せる」という流れが公式化されたという点は注目です。今後、「AIが書いたコードをレビューする」「AIが提案した設定変更の可否を判断する」という役割が、情シス担当者に求められるようになっていく可能性があります。

3本目：Amazon Q Developerに動き、知っておくべき変更点

便利なツールにも「使える期限」がある。今のうちに確認しておこう。

最後は、コード補完AIツール「Amazon Q Developer（アマゾン キュー デベロッパー）」に関する変更情報です。

もし社内のエンジニアやシステム部門がこれを使っていた場合、移行計画の検討が必要になります。

情シスとしてやるべきこと

1. 社内でAmazon Q Developerを使っている人・部署を把握する
2. 2027年4月のサポート終了に向けた代替手段（GitHub CopilotやClaude Codeなど）を検討する
3. ベンダーやシステム担当者に確認する

「使えなくなってから慌てる」のが一番コストがかかります。今のうちに棚卸しをしておきましょう。

今週のAWSニュース、情シスとして今日できるアクション

「知っている」と「動いている」には、大きな差がある。

✅ すぐにできること（今日〜今週）

• Amazon Q Developerの社内利用状況を確認する（使っている人がいれば移行を検討）
• Bedrock AgentCore Paymentsのニュースを上司や関連部署に共有する（セキュリティポリシーの議論のきっかけに）

✅ 少し先を見据えてやること（今月〜来月）

• 「AIエージェントが社内システムにアクセスするルール」を考え始める
• AWSのセキュリティ設定（IAM（AWSのアクセス管理サービス）ポリシーなど）の定期見直しをスケジュールに入れる

まとめ：今週のAWSは「AIが動き出した」週だった

「AIが動く」時代において、情シス担当者の役割はなくなるのではなく、「AIを管理・判断する人」として変化していきます。

毎週のAWSニュースを追いかけるのは大変ですが、こうして要点を押さえておくだけで、会議での一言や上司への報告がぐっと変わります。来週も一緒にキャッチアップしていきましょう。

関連記事：AWS Secrets Managerの使い方｜パスワード自動ローテーションの設定方法を解説
関連記事：AWS SAA試験の勉強法【情シス担当者が実践する3つの方法】