クラウドセキュリティエンジニアのスキルシートの書き方｜面談で評価される実績の見せ方

クラウドセキュリティエンジニアのスキルシートは、権限設計・ログと検知・設定の監査のどれを、どの範囲（アカウントやクラウドの広さ）で、指摘・是正・予防のどこまで担ったかを書くのが基本です。使ったサービスの名前を並べるより、「何を防ぐために、どんな決まりを作り、どこまで直したか」が読み取れるシートが評価されます。

一方で、クラウドセキュリティの実績は、発注元の弱点そのものに触れます。アカウントの情報や指摘の中身を書かずに経験の深さを伝える工夫が必要です。この記事では、要約の書き方、プロジェクト欄の項目、書かない情報、架空の記入例を紹介します。スキルシート全般の基本はスキルシートの書き方の基本をご覧ください。

要約は「軸の分野」と「担った段階」を先に書く

スキルシートの冒頭の要約では、3〜4行で次の点を伝えます。

• 軸のクラウド：AWS、Azure、Google Cloudのどれを主に扱ったか
• 軸の分野：権限設計、ログと検知、設定の監査、予防の仕組みのどれが中心か
• 担った段階：指摘まで、是正まで、組織の決まりづくりまで
• 範囲：一つのシステムか、組織の単位か（数は規模感で）

要約の例（架空）：

クラウドの基盤構築を経て、AWSの複数アカウントの環境で権限設計と設定の監査を担当。監査の仕組みの導入から、指摘の優先順位づけ、運用を止めない是正、新しいアカウントへの予防の決まりの適用までを担いました。Azureの環境では設定の監査の補助を経験しています。

プロジェクト欄に書く項目

クラウドセキュリティの案件では、次の項目をそろえて書くと、読む側が経験の段階を判断しやすくなります。

「照らした基準」は、公開されている基準の名前であれば書いて問題ありません。たとえばAWSのSecurity Hub CSPMは、AWSのベストプラクティスの基準のほか、CIS、PCI DSS、NISTの基準に照らしたチェックを扱えます（2026年10月時点のAWSの公式ドキュメントによる）。どの基準で監査したかを書くと、求められる水準への慣れが伝わります。

「受け取った権限」は、ほかの職種のスキルシートではあまり書かない項目です。クラウドセキュリティでは、強い権限を任されてきたこと自体が信頼の裏付けになるため、書いておく価値があります。

書かない情報を先に決める

クラウドセキュリティの実績には、外に出ると発注元の弱点になる情報が多く含まれます。次の情報は書かないようにしましょう。

• アカウントの番号、組織やテナントの名前、ドメイン、リソースの名前
• 見つかった設定の不備の具体的な中身と、その件数
• ネットワークの構成図、権限の設計書、検知ルールの中身
• 発注元の社名（業界と規模でぼかす）

数を書きたいときは、「数十のアカウント」「指摘の大半を是正まで進めた」のように、規模感と割合にとどめると安全です。秘密保持契約の範囲に迷う場合は、スキルシートで守秘義務を守る書き方と秘密保持契約の記事をご覧ください。

プロジェクト欄の記入例

以下は書き方を示すための架空の例で、実在の案件や実績ではありません。業界や規模はぼかしています。

例1：権限設計と設定の監査（AWS）

期間：20XX年〜20XX年（1年）
案件概要：小売業向けの複数アカウントのAWS環境で、設定の監査の仕組みづくりと権限の見直し
規模・立場：クラウド基盤チーム5名（自分はセキュリティの担当。監査の方針づくりから参加）
対象の範囲：組織の単位（数十のアカウント。本番を含む）
担った分野と段階：設定の監査（導入・優先順位づけ・是正）、権限設計（棚卸しと削減）、予防（新しいアカウントへの決まりの適用）
受け取った権限：普段は読み取りのみ。変更は基盤チームの承認を受けて実施
照らした基準：AWSのベストプラクティスの基準、CIS
関わった相手：各サービスの開発チーム、基盤チーム、情報システム部門
工夫・成果：同じ原因から出ている指摘をまとめ、共通の設定の見直しで一度に解消した。使われていない権限やアクセスキーを洗い出し、業務の担当者と確かめながら減らした。新しいアカウントには最初から決まりが入る流れを作り、同じ指摘が出にくくした

権限の棚卸しの部分は、AWSのIAM Access Analyzerのように、使われていないロールやアクセスキーを見つける機能を使った場合、道具の名前を添えてもかまいません。ただし、主役は道具ではなく、減らす判断をどう進めたかです。

例2：ログの集約と検知（Azure・AWS）

期間：20XX年〜20XX年（8か月）
案件概要：サービス業向けのAzureとAWSの環境で、操作の記録の集約と検知ルールの整備
規模・立場：セキュリティ運用チーム3名（自分は設計と検知ルールの担当）
対象の範囲：2つのクラウドにまたがる本番環境
担った分野と段階：ログと検知（集約先の設計・検知ルールの作成と調整）
受け取った権限：ログの設定の変更まで。変更は事前に申請して実施
関わった相手：運用チーム、監視の担当
工夫・成果：2つのクラウドで記録の項目や名前の違いをそろえ、同じ観点で検知できるようにした。誤検知の多いルールを見直し、対応すべきアラートが埋もれないようにした

MicrosoftのDefender for Cloudのように、複数のクラウドを一つの画面で見られる仕組みを使った場合は、どのクラウドをつないで何をそろえたかを書くと、複数のクラウドの経験が具体的に伝わります。

スキル欄は分野ごとにまとめ、経験の段階を添える

プロジェクト欄とは別に、使える技術を一覧にするスキル欄があるシートでは、サービスの名前を思いつく順に並べるより、分野ごとにまとめるほうが読みやすくなります。

それぞれに「指摘まで」「是正まで」「決まりづくりまで」と段階を添えると、同じ分野でもどこまで任せられるかが一目で伝わります。経験年数を書く欄がある場合も、年数だけでなく段階を書き添えておくと、面談で確かめる手間が減ります。

資格は「取得」と「有効期間」を正しく書く

資格は、名前と取得の時期を書き、有効期間があるものはその状態も正しく書きます。試験に合格しただけの状態と、認定を受けて維持している状態は区別して書きましょう。有効期間や認定の流れは、AWS認定セキュリティ–専門知識とCCSPの記事で扱っています。

よくある質問

指摘の件数を書かないと、実績が弱く見えませんか？

件数がなくても、指摘から是正、予防までどうつないだかが書かれていれば、経験の深さは十分に伝わります。数を示したいときは、「大半を是正まで進めた」のように割合や規模感で書くと、発注元の情報を出さずに済みます。

インフラ構築の経歴はどこまで書けばよいですか？

クラウドセキュリティの仕事は、守る対象の作りを理解していることが前提になるため、構築の経歴は残しておきましょう。権限やログ、ネットワークの分離など、セキュリティに関わる部分を中心に書くと、つながりが伝わります。

監査ツールの製品名は書いたほうがよいですか？

書いてかまいません。ただし、製品名だけを並べるより、その製品で何をそろえ、どの判断をしたかを書くほうが評価されます。面談では、製品が変わっても同じ進め方ができるかを聞かれることがあります。