はじめに
本記事では、AWSをほとんど触ったことがなかった私が、学習のために実際に行った手順をまとめました。
あわせて、前の現場でAWSを使った開発に関わった際に苦労したことも紹介します。
本記事では、
- AWSを学ぶために実行した手順
- AWS開発で苦労したこと
- アカウントの権限が1アカウントにつき1つだけだった
- S3へのファイル送信方法について
- 中国語などの多言語対応
- 振り返って学んだこと
を実体験として紹介します。
AWSの公式ドキュメントや入門記事は数多くありますが、
「実際に手を動かした人がどこでつまずいたのか」
「現場に入ってから何に困ったのか」
という情報は意外と少ないのではないのでしょうか。
これからAWSを学ぶ方や、現場でAWSを使い始めたばかりの方の参考になれば幸いです。
AWSを学ぼうと思ったきっかけ
前の現場では、システムをAWS上に刷新するというプロジェクトに１年半参画させていただいていました。
しかし当時の私はAWSの知識はあるが現場での経験は乏しかったので
「S3」「IAM」「バケット」「ポリシー」といった言葉が会議で出てきても、何となくしか理解できていませんでした。
分からないまま作業を進めることも多く、
周りのメンバーに何度も質問しながら対応していたのが正直なところです。
さらに次の現場もAWSに刷新したシステムを取り扱うので、「一度きちんと手を動かして学び直そう」と考え、
個人のAWSアカウントで学習を始めました。
AWSを学ぶために実行した手順
私が最初に行ったのは、次の2つです。
- AWSアカウントを作成する（実際に手を動かす環境）
- AWS Skill Builderの無料講座を受ける（知識をインプットする場所）
「まず講座で全体像をつかみ、気になったところを自分のアカウントで試す」
という流れで学習を進めました。
※今回はAWS Skill Builderで講座を受けるとこまで紹介しています。
手順1：AWSアカウントを作成する
まずは個人用のAWSアカウントを作成しました。
作成時には、メールアドレス・クレジットカード・電話番号による本人確認が必要です。
クレジットカードの登録が必要なため、最初は「いくら請求されるのだろう」と少し身構えました。
なお、2025年7月15日以降に作成したアカウントは、新しい無料利用枠の対象になります。
- サインアップ時に100 USD分のクレジットがもらえる
- EC2・RDS・Lambda・Bedrock・Budgetsの5つの操作を試すと、それぞれ20 USD分のクレジットが追加される（最大で合計200 USD分）
- 「無料プラン」を選ぶと、有料プランへ切り替えない限り料金は発生しない
- 無料プランは6か月間、またはクレジットを使い切るまで利用できる
「無料プランなら勝手に課金されない」という仕組みがあるのは、初心者にとって大きな安心材料でした。
無料プランでは使えるサービスが限られます。
また、無料利用枠の内容は変更されることがあるため、作成前に公式サイトで最新情報を確認してください。
手順2：AWS Skill Builderに登録する
次に、AWSの公式学習サイトである「AWS Skill Builder」に登録しました。
Skill Builderは、AWSが提供しているオンライン学習サービスです。
有料のサブスクリプションもありますが、無料で受けられる講座だけでも十分に学習を始められます。
登録には「AWS Builder ID」を使います。
AWS Builder IDは、手順1で作成したAWSアカウントとは別のもので、メールアドレスがあれば無料で作成できます。
登録の流れは以下のとおりです。
- Skill Builderのトップページからアカウント作成を選ぶ
- AWS Builder IDを作成する（メールアドレス・表示名・パスワードを登録）
- メールに届いた確認コードを入力する
- プロフィール作成時に、言語を「日本語」に設定する
私は最初「AWSアカウントでログインするもの」だと思い込んでいて、少し迷いました。
Skill BuilderはAWS Builder IDで利用する、と覚えておくとスムーズです。
手順3：無料講座で全体像をつかむ
登録後、無料講座から学習を始めました。
講座は、カタログ画面で言語フィルターを「日本語」にすると探しやすくなります。
実際に受けた講座と、初心者におすすめの無料講座をまとめます。
| 講座名 | 形式 | こんな人におすすめ |
|---|---|---|
| Cloud for Beginners（日本語実写版） | 動画 | ITやクラウドの基礎用語から学びたい人 |
| AWS Cloud Practitioner Essentials（日本語実写版） | 動画 | AWS全体の基礎を体系的に学びたい人 |
| AWS Cloud Quest: Cloud Practitioner | ゲーム＋ハンズオン | ゲーム感覚で実際にAWSを操作してみたい人 |
| AWS SimuLearn: Cloud Practitioner | シミュレーション演習 | 短い演習で手軽に手を動かしたい人 |
| Official Practice Question Set | 問題集 | 資格試験（Cloud Practitionerなど）を目指す人 |
私のおすすめの順番は、次のとおりです。
- Cloud for Beginnersで、クラウドの前提知識をそろえる
- AWS Cloud Practitioner Essentialsで、AWSの主要サービスを一通り学ぶ
- Cloud QuestまたはSimuLearnで、実際に手を動かしてみる
- 資格に興味が出たら、Official Practice Question Setで腕試しをする
動画だけを見ていると「分かったつもり」になりがちですが、
Cloud QuestやSimuLearnのように手を動かす講座を挟むと、理解度がぐっと上がりました。
AWS公式ブログでも、初心者向けの学習ステップがまとめられています。
講座選びに迷ったら参考にしてみてください。
https://aws.amazon.com/jp/blogs/news/2026-aws-beginner-learning/
特にAWS Cloud Practitioner Essentialsはボリュームもあり最初に受講するにはおすすめのコースになってます。
またコースの途中にはクイズがあり、本当に理解できたか確かめながら学習を進めることができます。
前現場でのAWSの苦労話
ここからは、前の現場でAWSを使った開発に関わった際に苦労したことを紹介します。
前現場は、20年以上利用されてきたシステムをAWS上に刷新するプロジェクトでした。
長く使われてきたシステムだからこそ、AWSの仕組みやルールに合わせる過程で、思わぬところに苦労がありました。
①アカウントの権限は1アカウントにつき1つだけだった
何が問題だったのか
旧システムでは、1人のユーザーが複数の権限を持つことができました。
例えば「一般ユーザー」と「承認者」の権限を同時に持っている、といった具合です。
しかし、AWS上の新システムでは、AWSのポリシーやルールに合わせた設計により、
1ユーザーにつき権限は1つだけにするしかない、という結論になりました。
ここで問題になったのが、20年分の運用で積み重なった権限の扱いです。
- どのユーザーが、いくつの権限を持っているのか誰も把握しきれていない
- 権限を1つに絞ると、そのユーザーが今までできていた業務ができなくなる可能性がある
- どの権限を残すかは業務に直結するため、開発側だけでは決められない
つまり、技術的な問題であると同時に、お客さんの業務判断が必要な問題でした。
どうやって解決したのか
解決までの流れは、次のとおりです。
- ユーザーテーブルを調査し、各ユーザーが持っている権限を洗い出す
- 調査結果を、お客さんが見て判断しやすいCSVファイルにまとめる
- お客さんにCSVファイルを提出し、各ユーザーの権限を1つに決めていただく
- お客さんから戻ってきたファイルを元に、ユーザーの権限を1つに修正する
手順1：ユーザーテーブルから権限を調査する
まずは旧システムのユーザーテーブルを調べ、
「複数の権限を持っているユーザーは誰か」を洗い出しました。
例えば、ユーザーと権限の対応テーブルがある場合は、次のようなSQLで複数権限のユーザーを抽出できます。
-- 複数の権限を持つユーザーを抽出する例（テーブル名・列名は例です）
SELECT user_id, COUNT(*) AS role_count
FROM user_roles
GROUP BY user_id
HAVING COUNT(*) > 1;
手順2：お客さんが判断しやすいCSVファイルにまとめる
調査結果をそのまま渡しても、お客さんは判断できません。
そこで、業務担当の方が見てすぐ判断できる形にすることを意識してCSVファイルにまとめました。
| ユーザーID | 氏名 | 現在の権限 | 新システムでの権限（記入欄） |
|---|---|---|---|
| U0001 | 山田 太郎 | 一般ユーザー、承認者 | |
| U0002 | 佐藤 花子 | 一般ユーザー、管理者 |
※上記はイメージです。
記入欄をあらかじめ用意しておくことで、お客さんは「どの権限にするか」を書き込むだけで済むようにしました。
手順3：お客さんに検討していただく
CSVファイルをお客さんに提出し、
「1ユーザーにつき1権限」にするために、どのユーザーをどの権限にするかを検討していただきました。
権限の決定は業務に直結するため、ここは開発側が勝手に決めず、お客さんに判断を委ねることが大切だと考えました。
手順4：決定した内容を元に権限を修正する
お客さんが権限を決定した後、戻ってきたファイルを元に、各ユーザーの権限を1つに修正しました。
これで、新システムのルールに合わせた権限の整理が完了しました。
この経験から学んだこと
- システムを刷新するときは、旧システムで「当たり前」だった仕様が新しい環境では使えないことがある。
- 権限のように業務に直結する内容は、開発側だけで決めず、お客さんに判断していただく。
- お客さんに判断してもらうときは、見てすぐ分かる資料を用意することで、検討がスムーズに進む。
②S3へのファイル送信方法
AWSへ移行に伴い、今まで送信していたファイルはS3へ送ることになりました。
検討する際に困ったことはファイルを送信する方法でした。
| 方法 | 特徴 |
|---|---|
| マネジメントコンソール | 画面から手軽にアップロードできる。手作業向け |
AWS CLI（aws s3 cp / aws s3 sync） |
コマンドで操作でき、スクリプト化しやすい |
| AWS SDK（Java、Pythonなど） | アプリケーションからアップロードする場合に使う |
| 署名付きURL（Presigned URL） | 認証情報を渡さずに、期限付きでアップロードを許可できる |
前現場では、
- どの方法で送信するのが現場のルールなのか
- 送信先のバケット名・パス（プレフィックス）の命名ルール
- 自分の権限で、そのバケットに書き込めるのか（あとで権限が必要だったことが判明）
が分からず、最初は戸惑いました。
特に、アップロードしようとして Access Denied が出たときは、
権限の問題なのか、バケット名やパスの指定ミスなのか、切り分けに時間がかかりました。
S3のアクセス制御は、IAMユーザー側のポリシーだけでなく、
バケット側のバケットポリシーでも制御されています。
自分のポリシーで許可されていても、バケットポリシーで拒否されていればアクセスできません。
この「両方を見る必要がある」という点を知らず、自分のポリシーばかり確認していました。
また、送信先のパスを1文字間違えるだけで、別の場所にファイルが置かれてしまいます。
S3はフォルダが存在しなくてもエラーにならず、そのままファイルを作成してしまうため、
「送信は成功したのに、S3内を検索しても見つからない」ということもありました。
S3へファイルを送信するときのポイント
- S3へのファイル送信は 「方法」「送信先」「権限」の3点をセットで確認 する。
-
Access Deniedが出たら、IAMポリシーとバケットポリシーの両方 を確認する。 - 送信後は
aws s3 lsなどで、意図した場所に置かれているか を確認する。
③中国語などの多言語対応について
前現場では、日本語だけでなく中国語などの多言語のデータを扱う必要がありました。
そこで苦労したのが文字コードです。
- ファイルの文字コードがUTF-8なのかShift_JISなのか統一されていない
- Shift_JISでは中国語（簡体字など）の一部の文字を表現できない
- S3に置いたファイルをブラウザで開くと文字化けする
- CSVをExcelで開くと文字化けする。大体？？？みたいになってます。
といった問題が発生しました。
日本の現場では、昔からのシステムや運用の都合でShift_JISが使われていることがあります。
しかしShift_JISは日本語向けの文字コードのため、中国語の簡体字などには対応していない文字があります。
その結果、変換の途中で「?」に置き換わったり、意味の分からない文字列になったりしました。
さらに厄介だったのは、どの段階で文字化けしているのかが分かりにくいことです。
- ファイルを作成した時点で、すでに文字化けしているのか
- S3へ送信する際に、文字コードが変わってしまったのか
- 表示するツール（ブラウザやExcel）側の問題なのか
これを1つずつ切り分けて確認する必要がありました。
対応としては、以下を意識しました。
- ファイルの文字コードはUTF-8に統一する
- S3にアップロードする際、
Content-Typeにcharset=utf-8を指定する - Excelで開くCSVは、BOM付きUTF-8にする
# Content-Typeを指定してアップロードする例
aws s3 cp ./sample.csv s3://my-bucket-name/ --content-type "text/csv; charset=utf-8"
# ファイルの文字コードを確認する例（Linux / Mac）
file -i sample.csv
日本語環境だけでテストしていると、多言語のデータで初めて問題が見つかることがあります。
テストデータに中国語などの文字を含めておくと、早い段階で気づけます。
多言語対応へのポイント
- 多言語対応では、文字コードを最初に決めて統一することが重要。
- 「どこで文字化けしているのか」（作成時・送信時・表示時）を切り分けて考える。
振り返って学んだこと
1. 個人学習と現場のギャップを意識する
個人学習ではすべての権限を持っていますが、現場では権限が制限されています。
また、命名ルールや送信方法など、現場ごとの決まりごとも存在します。
学習の段階から、現場での運用を意識しておくとスムーズに適応できます。
また予めお客さんが権限について理解していないパターンがあるので事前に相談
しておくことで後からスムーズに作業することができます。
2. 「何ができないか」を早めに確認する
権限、送信方法、文字コードなど、つまずいたポイントの多くは
「最初に確認しておけば防げた」ものでした。
作業に入る前に「できること」と「できないこと」を確認するだけで、
手戻りや待ち時間を大きく減らせたと思います。
3. 分からないことは早めに相談する
一人で調べ続けるより、現場のルールを知っている人に早めに聞くことで解決が早くなりました。
特にAWSは、現場ごとに権限や運用ルールが異なるため、
ネットで調べた一般的な答えがそのまま当てはまらないことがあります。
すぐにメンバーへ相談することが大切です。
4. 手を動かした経験が理解を深める
現場で苦労した内容も、個人アカウントで実際に試してみることで
「あのときのエラーはこういう意味だったのか」と腑に落ちることが多くありました。
苦労した経験と学習を結びつけることで、知識が定着しやすくなると感じています。
おわりに
AWSは学ぶ範囲が広く、最初はどこから手をつければよいか迷いました。
しかし、実際に手を動かし、現場で苦労した経験を通じて、少しずつ理解が深まっていきました。
今回紹介した苦労話は、どれも大きなトラブルにはなりませんでしたが
現場で実際に時間を取られたポイントです。
同じようなところでつまずいている方の参考になればうれしいです。
これからAWSを学ぶ方は、まずはアカウントを作成し、小さく触ってみてください。
それが理解への第一歩になると思います。