SOCアナリストのスキルシートの書き方｜面談で評価される実績の見せ方

SOCアナリストのスキルシートは、一次分析・二次分析・検知の改善のどの段を担ってきたかを先に示し、プロジェクトごとに監視の形、扱った製品と監視対象、時間帯、自分で判断した範囲、改善したことを書くのが基本です。監視先の名前や事象の中身は書かず、判断の流れで経験の深さを伝えます。

SOCの経験は「監視◯年」とまとめられがちですが、読む側が知りたいのは、手順書どおりに振り分けていたのか、根拠を持って上に上げていたのか、ルールを直していたのかです。この記事では、要約の書き方、プロジェクト欄の項目、書かない情報、架空の記入例を紹介します。スキルシート全般の作り方はスキルシートの基本の記事をご覧ください。

要約の1行目で「担ってきた段」を示す

要約は、次の3点を短く並べます。

• 担ってきた段：例「SOCでの一次分析と二次分析。後半は検知ルールの見直しを担当」
• 扱った環境：例「クラウド型のSIEMとEDR。監視対象は端末、サーバー、クラウドの操作記録」
• 働き方の条件：例「日勤・夜勤の交代勤務の経験あり。リモートでの監視の経験あり」

働き方の条件は、ほかの職種のスキルシートでは省かれがちですが、SOCでは案件選びの大きな分かれ目になります。夜間の枠を受けられるかどうかは、要約か希望条件の欄に書いておくと、合わない案件のやり取りを減らせます。

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

判断の範囲の欄が、SOCのスキルシートで最も差が出るところです。「隔離の操作は承認を得て自分で実施」「顧客への一報は自分で判断して送った」など、任されていた範囲を具体的に書きます。

製品名は「何をしたか」と組にする

製品名だけを並べると、画面を見ていただけなのか、ルールを書いていたのかが伝わりません。「SIEM（検索言語での条件作成、ルールの見直し）」のように、使った機能と組にして書きましょう。攻撃の手口に関する経験は、MITRE ATT&CKのような公開の枠組みの言葉で書くと、監視先の情報を出さずに伝えやすくなります。たとえば「横への広がりにあたる検知の調査」のように書けます。

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

SOCは、監視先の構成や事象の中身に日常的に触れる仕事です。スキルシートに書く前に、書かない情報を決めておきましょう。

• 監視先の名前や、特定できる組み合わせ：業界と規模をぼかす
• 検知ルールの中身や、しきい値：監視先の弱いところが分かってしまうため書かない
• 事象の詳細：いつ、どこで、何が起きたかは書かない。経験は「どの段を担ったか」で示す
• IPアドレスやホスト名、アカウント名：例として書くことも避ける
• 件数の実数：監視の規模が特定につながる場合は、割合や「多い・少ない」の比較にとどめる

迷ったときの考え方はスキルシートでの守秘義務の記事と秘密保持契約の記事で解説しています。

プロジェクト欄の記入例（架空）

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

例1：監視サービスの事業者での一次・二次分析

期間：20XX年〜20XX年（2年）
案件概要：監視サービスの事業者で、複数の顧客（製造業・サービス業など）のセキュリティ監視
規模・立場：交代勤務のチーム（自分は一次分析の担当。後半は二次分析も担当）
製品：クラウド型のSIEM（保存済みの検索の実行、検索言語での条件作成）、EDR（検知の前後の記録の確認）
監視対象：端末、サーバー、クラウドの操作記録
時間帯：日勤と夜勤の交代。夜間は一次分析を一人で担当する時間帯あり
判断の範囲：手順書にない事象について、根拠を添えて二次分析に上げるかを判断
工夫・改善：判断に迷いやすい事象の扱いをまとめ、手順書への追加を提案。交代時の引き継ぎの書式を見直した

例2：社内SOCでの検知の改善

期間：20XX年〜20XX年（1年3か月）
案件概要：事業会社の社内SOCで、監視の運用と検知の改善
規模・立場：社内のセキュリティ部門と外部の監視事業者で構成するチーム（自分は検知の改善の担当）
製品：SIEM（ルールの作成と見直し）、EDR（調査と隔離の提案）、チケットの管理の道具
監視対象：端末、認証の記録、メール、クラウドの操作記録
時間帯：日勤。重大な事象のときのみ夜間の呼び出しあり
判断の範囲：ルールの変更案の作成と、変更後の取りこぼしの確認。隔離は承認を得て実施
工夫・改善：誤検知の多いルールの条件を見直し、確認が必要なアラートの割合を下げた。攻撃の流れの枠組みに沿って、検知できていない領域を一覧にした

どちらの例も、監視先の名前、事象の中身、ルールの中身は書いていません。それでも、担った段、判断の範囲、改善の内容が書かれていれば、経験の深さは伝わります。

時間帯と交代勤務の書き方

SOCの案件では、時間帯の経験が条件の合う・合わないを分けます。プロジェクトごとに、次の点を書いておくと読み手が判断しやすくなります。

• 交代の形：日勤だけか、日勤と夜勤の交代か、夜間の呼び出しだけか
• 夜間の体制：夜間に一人で担当する時間帯があったか、チームで対応していたか
• 呼び出しへの対応：自宅から対応したのか、拠点に向かったのか

夜間に一人で一次分析を担った経験は、自分の判断で動ける範囲を示す材料になります。反対に、今後は夜間を受けたくない場合は、経験として書いたうえで、希望条件の欄で「日勤のみ希望」と分けて書きましょう。

資格と学習の書き方

資格は、合格・取得の年月と正式な名称で書きます。情報処理安全確保支援士は、試験に合格した人が登録する国家資格で、登録した後は所定の講習を修了して更新する仕組みです（2026年10月時点のIPAの案内による）。試験に合格しただけの状態と、登録している状態を、「合格」「登録」と正しく書き分けましょう。評価のされ方は情報処理安全確保支援士の記事で扱っています。

業務外の学習（検証環境での調査の練習など）は、扱った範囲が自分の管理する環境であることを書き添えると、情報の扱いへの意識も伝わります。

面談でスキルシートを補う

スキルシートに書けなかった判断の流れは、面談で補います。「このアラートをどう見て、何を確かめ、なぜ上に上げたか」を、監視先の情報を伏せて一般化して話せるように準備しておきましょう。面談の進み方は面談でよく聞かれる質問の記事をご覧ください。

よくある質問

一次分析の経験しかありません。どう書けば評価されますか？

一次分析の中で、手順書にない事象をどう判断したか、引き継ぎや手順書の改善に関わったかを書きましょう。判断の範囲が書かれていれば、手順どおりの振り分けだけの経験とは区別して読んでもらえます。

SOCの前のネットワークやサーバーの運用経験も書くべきですか？

書いておくことをおすすめします。ログの意味が分かる、仕組みの動きが想像できるといった土台は、アラートの判断に直結するためです。ただし主役はSOCでの経験なので、運用の経験は短くまとめ、要約で「運用の経験あり」と添える程度にすると読みやすくなります。

扱った製品が多いと有利ですか？

製品の数より、それぞれの製品で何をしたかが見られます。画面を見ていただけの製品を並べるより、検索の条件を書いた、ルールを直したといった使い方が分かる書き方にしましょう。