AWSエンジニアのスキルシートの書き方｜面談で評価される実績の見せ方

AWSエンジニアのスキルシートは、使ったサービスの名前を並べるより、構成を1〜2行で要約し、設計・構築・移行・運用のどの工程を担ったか、IaCで新しく作ったのか既存のコードを直したのかを書くのが基本です。読み手は、同じ「EC2、RDS、S3」という並びからでも、構成を決めた人なのか、決まった構成を運用していた人なのかを知りたいからです。AWS認定は、正式名称・取得年月・有効期限を添えて書きます。

この記事では、AWSならではの書き方と記入例を紹介します。案件で求められるスキルの中身はAWSエンジニアの案件で求められるスキル、独立の準備はAWSエンジニアがフリーランスになるにはで扱っています。

サービス名の羅列では伝わらないこと

AWSのスキルシートでよく見るのが、使用技術の欄に数十のサービス名を並べる書き方です。AWSにはサービスが多く、少し触れたものまで書くと、一覧はすぐに長くなります。

しかし、サービス名の一覧からは、次のことが読み取れません。

• そのサービスを、設計で選んだのか、構築したのか、画面で確認しただけなのか
• どんな構成の中で使ったのか（単体のサーバーか、複数のアカウントにまたがる構成か）
• 手作業で作ったのか、コードで管理していたのか

AWSの案件の読み手は、インフラの経験がある担当者であることが多く、一覧の長さよりも、構成と役割の説明を見ています。

スキル一覧は分野ごとに「深さ」を添える

スキル一覧では、サービスを分野ごとにまとめ、どこまで担当したかを括弧で添えると、読み手は深さを判断できます。

これは書き方を示すための例です。「利用のみ」「運用」のように、浅い関わりもそのとおりに書くのが大切です。深さを書いておけば、面談で深く聞かれる範囲を自分で示せます。

プロジェクト欄の冒頭に「構成の要約」を置く

AWSのプロジェクト欄では、案件概要の次に、構成を1〜2行で要約した行を置くと、読み手が全体像をつかみやすくなります。

• 「コンテナで動くWebサービス。複数のアベイラビリティゾーンに分けて配置し、データベースはマネージドサービス」
• 「オンプレミスの業務システムをAWSへ移行。本番・検証・開発でアカウントを分けた構成」

社名やシステム名は書かず、業種と構成の特徴で書きます。利用者数や扱うデータの量は、伏せられる範囲で「中規模」「大量のアクセスがある時間帯あり」程度にとどめます。

構成図は添えるか

構成図があると説明しやすいのは確かですが、参画先で作った構成図は、参画先の資料です。スキルシートに貼ったり、作り直して添えたりする前に、出してよいかを確かめる必要があります。判断の考え方はスキルシートに書いてよいこと・いけないことをご覧ください。多くの場合は、文章での要約にとどめ、構成図は面談で口頭で説明するほうが無難です。

工程とIaCの関わり方を書き分ける

AWSの案件は、担った工程によって合う案件が変わります。担当工程の欄には、次のように工程ごとの関わり方を書くと伝わります。

IaCは、特に書き分けが大切です。「Terraform経験あり」だけでは、モジュールの設計から作ったのか、既存のコードの値を書き換えただけなのかが分かりません。

• 新規作成：ゼロからコードを書き、モジュールの分け方を決めた
• 既存の修正：決まった構成のコードに、設定やリソースを追加した
• 手作業からの置き換え：画面で作られていた環境を、コードの管理へ移した

手作業からの置き換えは、運用中の環境を壊さずに進める工夫が要るため、経験として目に留まりやすい項目です。

AWS認定の書き方

AWS認定は、知識の範囲を示す材料として書類の段階で読まれます。書くときは、次の3点をそろえましょう。

1. 正式名称：「SAA」「ソリューションアーキテクト」などの略称ではなく、「AWS Certified Solutions Architect - Associate」のように正式な名称で書く
2. 取得年月：いつ取得したか
3. 有効期限：AWSの公式サイトでは、多くの認定は3年間有効で、最新の試験に合格するなどして更新すると、有効期間がさらに3年延びると案内されています（2026年10月時点）

失効した認定は、「取得歴」として分けて書くか、書かないかを選びます。有効な認定と同じ行に並べると、読み手が現在も有効だと受け取ることがあります。

認定の名称や区分は見直されることがあります。2026年10月時点のAWSの試験一覧では、AWS Certified Advanced Networking - Specialtyが2026年12月31日に廃止予定とされています。廃止された認定や名称が変わった認定を持っている場合も、取得したときの名称のまま、取得年月とあわせて書けば問題ありません。認定の区分や案件での見られ方はAWSの案件で求められるスキルで紹介しています。

プロジェクト欄の記入例

ここでは、オンプレミスからの移行と、その後の運用改善を担当した場合を想定した記入例を示します。以下は書き方を示すための例で、実在の案件や実績ではありません。業界や規模はぼかしています。

期間：20XX年X月〜20XX年X月（1年4か月）
案件概要：製造業向け 社内の業務システムのAWSへの移行
構成の要約：コンテナで動くWebアプリとマネージドのデータベース。本番・検証・開発でアカウントを分けた構成
規模・立場：インフラ4名（自分はメンバー。後半は運用改善のとりまとめ）
担当工程：構築、移行、運用（設計はレビューに参加）
使用技術：VPC、ECS、RDS、IAM、CloudWatch、Terraform（新規作成）、GitHub Actions
担当内容：Terraformのモジュールを作成し、検証と本番の環境を構築した。移行の手順書を作り、切り替え当日の作業を担当した
工夫・成果：移行後に多かった不要なアラームを整理し、対応が要るものだけが通知されるようにした。権限の付与を申請の手順に沿う形に変え、作業の記録が残るようにした

「設計はレビューに参加」のように、主担当ではない工程も、関わり方をそのまま書いています。設計の経験を大きく見せたくなる場面ですが、面談では構成を選んだ理由を聞かれます。答えられる範囲で書くことが、評価の安定につながります。

ほかのクラウドの経験との並べ方

AzureやGoogle Cloudの経験もある場合は、スキル一覧でクラウドごとに行を分け、プロジェクト欄ではどのクラウドの案件かを冒頭に書きます。応募する案件がAWSなら、AWSの経験を上に置き、ほかのクラウドは「関連する経験」として添える形が読みやすくなります。ほかのクラウドを軸にする場合は、Azureのスキルシートの書き方やGCPのスキルシートの書き方、運用の自動化や信頼性の改善が中心の方はSREのスキルシートの書き方も参考になります。

よくある質問

触っただけのサービスも書いたほうがよいですか？

書く場合は、「利用のみ」「検証環境で構築」のように関わり方を添えましょう。案件の条件に挙がっているサービスであれば、浅い経験でも書いておくと検討の材料になります。関わり方を添えずに並べると、面談で深く聞かれたときに答えに詰まる原因になります。

個人の検証環境での経験は書いてよいですか？

書いてかまいませんが、実務の経験とは分けて「個人の検証環境で構築」と明記します。認定の学習で作った構成や、IaCで作った環境は、実務で触れていない分野を補う材料になります。何を作り、何を確かめたかを1〜2行で書くと伝わります。

運用の経験しかありません。どう書けば評価されますか？

運用の中で、自分の判断で行ったことを拾い出して書きましょう。障害の原因の切り分け、監視の設定の見直し、手作業の手順の自動化などは、運用から構築や設計へ広げるための実績になります。上流の工程に入るための考え方は上流工程の案件に入るために必要な経験にまとめています。