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

セキュリティエンジニアのスキルシートは、要約で「診断・設計構築・監視・インシデント対応」のどの分野が軸かを示し、プロジェクトごとに対象の種類・担当した工程・手法・報告の相手を書くのが基本です。そのうえで、診断の対象や見つけた脆弱性の詳細、発注元が特定できる情報は書きません。セキュリティの案件では、何を書かないかの判断そのものが、機密を任せられるかの材料として読まれます。

分野ごとに求められるスキルはセキュリティエンジニアのスキルの記事、全体の構成はスキルシートの基本で扱っています。この記事では、セキュリティの仕事ならではの書き方に絞って説明します。

要約で分野と立ち位置を示す

セキュリティエンジニアの仕事は分野が広く、同じ「セキュリティ経験5年」でも、Webアプリの診断をしてきた人と、監視の拠点でログを見てきた人では、合う案件がまったく違います。要約の1行目で、軸の分野をはっきり書きます。

• 軸の分野（例：Webアプリとスマートフォンアプリの脆弱性診断）
• その分野での立場（例：診断の実施から報告書の作成、開発チームへの説明まで）
• ほかに対応できる分野（例：クラウドの設定の確認、開発の経験あり）

セキュリティの専任になる前に開発やインフラの経験がある方は、要約に書いておくと、直し方まで提案できる人として読まれます。

プロジェクト欄は「対象の種類・工程・手法・報告の相手」

セキュリティの案件では、ほかの職種の「使用技術」の欄だけでは経験の中身が伝わりません。次の4つをそろえて書くと、読み手が深さを判断できます。

「手法とツール」の欄では、ツールの名前より、ツールで拾えない部分を手作業でどう確かめたかを書くと、経験の深さが伝わります。たとえば「権限の異なる利用者で画面を行き来し、他人の情報が見えないかを手作業で確認」のような書き方です。

監視やインシデント対応の分野では、「担当した工程」を次のように置き換えます。

• 監視：検知ルールの作成・調整、一次対応、上位への引き継ぎの基準づくり
• インシデント対応：初動、影響範囲の調査、封じ込め、再発防止策の提案、報告書

書かない情報を決めてから書く

セキュリティの経歴は、少し具体的に書いただけで、発注元の弱点を外に示すことになりかねません。守秘義務の一般的な考え方はスキルシートに書いてよいこと・いけないことで扱っているので、ここではセキュリティの仕事に固有の線引きをまとめます。

特に気をつけたいのは、情報の組み合わせです。業種、規模、時期、事故の種類を並べると、報道された事案と結びつけられて発注元が推測できることがあります。インシデント対応の経験は、時期を年単位にぼかし、業種も「サービス業」のように広く書くほうが安全です。

診断で使った手順やツールの設定

参画先で作った診断の手順書や、ツールの設定は、参画先の資料です。スキルシートに添付したり、内容を書き写したりしないでください。「診断の手順書を整え、担当者が変わっても同じ観点で確かめられるようにした」のように、作ったことと目的だけを書きます。

プロジェクト欄の記入例

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

期間：20XX年〜20XX年（1年6か月）
案件概要：サービス業向け Webアプリとスマートフォンアプリの脆弱性診断（継続案件。新機能の公開の前に診断）
規模・立場：診断チーム4名（自分は実施と報告の担当。後半は計画の取り決めにも参加）
対象の種類：会員向けのWebアプリ、API、スマートフォンアプリ
担当した工程：計画（一部）、実施、報告、修正の確認
手法とツール：診断ツールでの自動の確認に加え、認証と権限まわりは手作業で確認。IPAの「安全なウェブサイトの作り方」などの公開資料の観点を参考にした
報告の相手：開発チーム（再現の手順と直し方の案を説明）
工夫・成果：直し方の案をコードの例で示し、開発チームが修正しやすい報告の形に改めた。修正の確認の手順を決め、再診断の手戻りを減らした

脆弱性の種類や件数は書いていません。それでも、手作業で確かめた範囲と、報告の相手と工夫が書かれていれば、経験の深さは十分に伝わります。

業務外の取り組みは「許可の範囲」を書き添える

セキュリティの分野では、個人の検証環境での学習や、技術を競う大会、脆弱性の報奨金制度への参加など、業務の外での取り組みも経験として読まれます。書くときは、実務の欄とは分けたうえで、許可された範囲で行ったことが分かる書き方にします。

• 個人の検証環境：「自分で構築した検証環境で、攻撃と検知の流れを確かめた」
• 大会：大会名と参加した年、担当した分野
• 報奨金制度：参加した制度の種類と、ルールに沿って報告したこと（対象の企業名や報告の中身は、公開が認められている範囲にとどめる）

自分の判断で他人のシステムを調べた経験を書くことは避けてください。読み手は、作業範囲の取り決めを守れる人かどうかを見ています。

資格の書き方は「合格」と「登録」を分ける

IPAの情報処理安全確保支援士試験は、安全な情報システムの企画・設計・開発・運用を支援し、対策の調査・分析・評価と助言を行う人を対象にした国家試験です。2026年度はCBT方式で前期・後期に実施され、2027年度から新しい試験制度に移る予定とされています（2026年10月時点のIPAの案内による）。

スキルシートでは、次の書き分けが大切です。

• 試験に合格しただけの場合：「情報処理安全確保支援士試験 合格（20XX年X月）」と書く
• 登録している場合：「情報処理安全確保支援士（登録セキスペ）」と書き、登録年月を添える

登録証の有効期限は登録日または更新日から3年で、更新には毎年の講習をすべて修了していることが求められます（2026年10月時点のIPAの案内による）。更新をしなかった場合は、登録していた時期と分けて書きます。IPAの案内では、登録が失効した後に紙の登録証を使って資格の名称を用いると罰則の対象になるとされています。失効後の名乗り方には特に気をつけましょう。資格の位置づけや更新の流れはセキュリティエンジニアがフリーランスになるにはで詳しく扱っています。

よくある質問

脆弱性の種類を書かないと、経験が浅く見えませんか？

確かめた観点の種類（認証、権限、入力値の扱いなど）と、手作業で確かめた範囲を書けば、経験の深さは伝わります。具体的な脆弱性の話は、面談で発注元が分からない形に一般化して説明するほうが、情報の扱いを任せられる人として受け取られます。

開発エンジニアとしての経歴は、どこまで書けばよいですか？

セキュリティに関わる部分を中心に書きます。認証や権限の実装、入力値の扱い、開発の中でのレビューなどは、診断や設計の案件で直し方を提案できる力として読まれます。クラウドの設定に強みがある方は、AWSエンジニアのスキルシートの記事の書き方も参考になります。

規程づくりや監査の経験もあります。どう並べればよいですか？

応募する案件の軸に合わせて並べ替えます。技術の作業が中心の案件なら診断や対応の経験を上に、規程や体制づくりの案件ならそちらを上に置きます。コンサルタントの案件に応募する場合の書き方はセキュリティコンサルタントのスキルシートの記事をご覧ください。