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

脆弱性診断エンジニアのスキルシートは、診断の種類ごとに、対象の種類と規模の目安、手動で確かめた観点、担った役割（実施・報告・レビュー・取りまとめ）、準拠した基準、修正の確認への関わりをそろえて書くのが基本です。読み手は、どの種類の診断を、どの深さで、どこまで一人で回せるかを知りたいと考えています。

診断の対象や見つけた脆弱性の詳細など、セキュリティの経歴で書いてはいけない情報の線引きはセキュリティエンジニアのスキルシートの記事で扱っています。この記事では、診断の経験の「量」と「深さ」をどう見せるかに絞り、架空の記入例とあわせて説明します。

要約は「種類×役割×手動の範囲」で書く

診断の経験は、年数だけでは中身が伝わりません。要約の冒頭で、次の3点をそろえて書きます。

• 診断の種類：Webアプリ・API、プラットフォーム、スマートフォンアプリ、クラウドの設定、ペネトレーションテストのどれか
• 役割：実施、報告、レビュー、取りまとめのどこまで担ったか
• 手動の範囲：ツールの結果の確認だけか、認証・権限・業務の手順を手で確かめたか

たとえば「Webアプリ・APIの診断を軸に、手動での権限まわりの確認から報告書の作成まで担当。後半はチームの報告書のレビューを担当」のように書くと、読み手は合う案件をすぐに思い浮かべられます。

開発やインフラの経験がある場合は、要約の最後に一行添えておきましょう。直し方まで提案できる人として読まれます。

診断の「量」の示し方

診断の経験は、案件ごとに期間が短いことが多く、プロジェクト欄が細かく分かれがちです。読みやすくするために、次のように工夫します。

継続案件はまとめて書く

同じ発注元の診断を繰り返し担った場合は、一つのプロジェクトとしてまとめ、「新機能の公開前に継続して診断」のように書きます。発注元の数は伏せたまま、続けて任されたことが伝わります。

規模は幅で示す

対象の画面数やホスト数は、正確な数字より、おおまかな幅で示すほうが安全です。「中規模の会員向けWebアプリ（画面数は数十程度）」のように、発注元が推測できない程度にぼかします。

種類ごとの経験期間を表にする

複数の種類を担ってきた場合は、スキル欄に種類ごとの経験期間と役割を表にまとめると、全体像が一目で伝わります。

（表は書き方の例です。期間は実際の経験に合わせて書いてください。）

役割の書き分け

診断の現場の役割は、読み手が報酬や任せる範囲を判断する材料になります。同じプロジェクトでも、時期によって役割が変わった場合は分けて書きます。

レビューや取りまとめを担った経験は、短い期間でも書いておく価値があります。品質に責任を持った経験として読まれるためです。

基準とツールの書き方

準拠した基準を書く

どの観点の体系で診断したかを書くと、抜け漏れのない診断をしてきたことが伝わります。たとえば、IPAの「安全なウェブサイトの作り方」（2026年10月時点の最新は改訂第7版）や、OWASPが公開しているWebアプリの検証の標準であるASVS（2026年10月時点で5.0.0が最新）などです。発注元や所属先が独自に定めた観点を使っていた場合は、「所属先の診断の観点（公開の基準をもとに作成）」のように書きます。

ツールは「自動」と「手動の補助」を分ける

ツールは、広い範囲を自動で調べる診断ツールと、通信を手で書き換えて確かめるための補助のツールでは、使い方が違います。名前を並べるより、どちらの使い方をしたかが分かる書き方にします。

• 自動の診断ツールで全体を確認し、結果の誤検知を取り除いた
• 通信を中継する補助のツールで、権限の異なる利用者の操作を手で確かめた

記入例1：Webアプリ・APIの診断（架空）

以下は書き方を示すための架空の例で、実在の案件や実績ではありません。

期間：20XX年〜20XX年（2年）
案件概要：サービス業向けの会員サイトとスマートフォンアプリのAPIの診断（新機能の公開前に継続して診断）
規模・立場：診断チーム数名。前半は実施と報告、後半は報告書のレビューも担当
診断の種類：Webアプリ・API
準拠した基準：所属先の診断の観点（公開の基準をもとに作成）
手動で確かめた観点：認証、セッション、権限の分離、業務の手順の飛ばし
ツールの使い方：自動の診断ツールで全体を確認したうえで、補助のツールで権限まわりを手で検証
報告と修正の確認：開発チームへの報告会で説明。修正後の再診断で直ったことを確認
工夫：直し方の説明に、開発チームが使う言語での考え方の例を添え、修正のやり取りを減らした

記入例2：プラットフォーム診断とペネトレーションテスト（架空）

こちらも架空の例です。

期間：20XX年〜20XX年（1年6か月）
案件概要：製造業向けの外部公開サーバー群の診断と、社内ネットワークを対象にしたペネトレーションテスト
規模・立場：2〜3名のチーム。プラットフォーム診断は実施と報告、ペネトレーションテストは計画にも参加
診断の種類：プラットフォーム（外部・内部）、ペネトレーションテスト
取り決め：発注元と対象の範囲、期間、試してよい手法、異常時の連絡先を書面で取り決めてから作業
担当した工程：目標の設定への参加、侵入の筋道の計画、試行、結果の整理
報告の相手：情報システム部門と経営層（経営層向けの要約を作成）
工夫：見つけた問題を、侵入の筋道の中でどこを断てば被害を防げるかの順に並べ、対策の優先順位が分かる報告にした

ペネトレーションテストでは、侵入の筋道の具体的な中身は書きません。「計画に参加した」「優先順位が分かる報告にした」のように、担った工程と工夫だけを書きます。取り決めを書面で行ったことを書き添えると、許可の範囲を守れる人だと伝わります。

資格は「合格」と「登録」を分けて書く

IPAの情報処理安全確保支援士試験は、セキュリティ対策の調査・分析・評価と、それに基づく指導・助言を行う人を対象にした国家試験です（2026年10月時点のIPAの案内による）。合格しただけの場合と、登録して講習を受け続けている場合は区別して書きます。詳しくは情報処理安全確保支援士の記事をご覧ください。診断の実技を問う民間の資格は、正式な名称と取得年月を書き、更新の条件があるものは有効期間も確かめておきましょう。

よくある質問

診断した件数は書いたほうがよいですか？

件数は経験の量を示す材料になりますが、正確な数字が発注元の推測につながることもあります。「年に数十件程度」のように幅で示すか、件数より種類と役割、手動の範囲を厚く書くほうが、経験の深さが伝わります。

所属先の手順に沿って診断していただけで、工夫が書けません。

手順に沿った診断の中でも、誤検知をどう見分けたか、報告書でどこを分かりやすくしたか、レビューで指摘されたことをどう直したかは書けます。小さな改善でも、品質に向き合った経験として読まれます。

練習環境や大会での経験は書けますか？

許可された環境での経験は、実務の欄とは分けて書けば、手法の理解を示す材料になります。業務外の取り組みの書き方は、セキュリティエンジニアのスキルシートの記事で詳しく解説しています。