エージェントはスキルシートのどこを見ているのか——「案件主体」と「要員主体」で視点が違う

スキルシートを丁寧に書いた。自己PRも整えた。 それなのに案件を紹介してもらえない。思うような案件の紹介がない。 そういうとき、多くのエンジニアは「自分のスキルが足りないんだ」と思い込む。

でも実態は違うことが多い。 そもそも、エージェントがスキルシートのどこを見ているかを知らないまま書いているのが原因だ。 しかもエージェントのタイプによって、同じ項目を見ていても評価の角度が違う。

3年間SESエージェントとして約500人のスキルシートを扱ってきた立場から、エージェント側の視点を正直に共有する。

---

あなたのエージェントは「案件主体」か「要員主体」か

まず知っておいてほしいのが、エージェントには大きく分けて2つのタイプがあるということだ。

案件主体のエージェントは、先にクライアントから案件を預かっている。 「この案件に合うエンジニアを探す」が起点だ。 手元に具体的な案件があり、そこにハマる人を探している。

要員主体のエージェントは、先にエンジニアを抱えている。 「このエンジニアに合う案件を探す」が起点だ。 手元にエンジニアがいて、その人を出せる案件を市場から探しに行く。

どちらが良い悪いではない。 ビジネスモデルの違いだ。 だが、同じスキルシートを見ていても、評価する角度が変わる。 見ている項目は実はほぼ同じだ。 言語と役割のマッチ、経歴、記述内容、単価。 だがそれぞれの項目を「何のために」チェックしているかが違う。

ここを理解するだけで、スキルシートの書き方の優先順位が変わる。 「自分に合ったエージェントの選び方」も参考にしてほしい。

---

案件主体のエージェントの視点——「この人を案件に推薦して大丈夫か」

案件主体のエージェントは、具体的な案件がすでに手元にある。 だから評価軸が明確だ。 一言でまとめると**「この人を推薦して、案件側に満足してもらえるか」**を見ている。

① 言語と役割のマッチ——「案件要件に合うか」

案件票に書かれた技術要件と、スキルシートの内容を照合する。 完全一致でなくてもいい。 「この経験があるなら、この案件でも動けるだろう」と説明できるかどうかが基準だ。

技術スタック欄に書いてあるだけでは判断できない。 案件概要の中にその技術の実務経験が読み取れるかまで見ている。 エンジニアとしては、技術スタック欄と案件概要の記載を一致させておくことが大事だ。 書いた技術が実務で裏付けられていないと、推薦の根拠が弱くなる。 加えて、案件概要を見る限り、エンジニアが本人ができると思っていたとしても、スキルシートにそれがわかる記入やワードマッチがないだけで見送られるケースも日常茶飯事だ。

② 経歴——「安定して稼働できるか」

案件主体のエージェントは、推薦した人が現場で問題なく稼働することを前提にしている。だから経歴の安定性を見る。

案件の在籍期間が極端に短い案件が続いていないか。 ブランクの理由が不自然ではないか。 在籍期間が短い案件がある場合は、理由を一言添えておくだけで印象が変わる。 「プロジェクトの縮小による契約終了」「短期の増員案件」など、事実を簡潔に書いておけばいい。 書いていないと、読み手は不安な方に想像する。

③ 記述内容——「推薦ストーリーが組めるか」

クライアントに推薦するとき、エージェント側は「この人はこういうエンジニアです」と一言で説明する。その一言をスキルシートから組み立てられるかが重要だ。

自己PRの冒頭3行、直近案件の概要、際立った成果の数字——この3箇所に「推薦の材料」を集中させておくことで、エージェント側は動きやすくなる。 以前「500人のスキルシートを見てきて気づいた"もったいない"5選」でも書いたが、材料がなければ他の候補者が優先される。

④ 単価——「案件の予算に合うか」

案件には予算レンジがある。 希望単価がそこに収まるかどうかは、マッチングの大前提だ。

ここで差がつくのは、単価の妥当性をスキルシートで裏付けられるかどうかだ。 記述が充実していて成果が数字で書かれていると、「この単価は妥当だ」とクライアントに説明しやすい。 逆に記述が薄いと、単価だけが一人歩きする。

---

要員主体のエージェントの視点——「この人に合う案件を見つけられるか」

要員主体のエージェントは、先にエンジニアを抱えている。 一言でまとめると**「この人を提案できる案件が市場にあるか」**を見ている。 見ている項目は案件主体とほぼ同じだが、角度が変わる。

① 言語と役割のマッチ——「市場で需要のあるスキルセットか」

案件主体が「特定の案件に合うか」を見るのに対し、要員主体は**「市場全体で提案先が見つかりやすいか」**を見る。

Java / React / AWSあたりは案件数が多いから提案先を見つけやすい。 一方でニッチな技術だけだと、提案できる案件自体が限られる。 ニッチな専門技術がメインでも、隣接する汎用技術の経験を併記しておくと、提案先の幅が広がる。

② 経歴——「長期で継続できそうか」

要員主体のエージェントにとっても経歴の安定性は重要だが、角度が少し違う。 案件主体が「現場で問題を起こさず動けるか」を気にするのに対し、要員主体は**「この人は案件に入ったら長く続けてくれるか」**を見ている。

短期退場が続いていると「提案しても、またすぐ終わるかもしれない」と判断される。 長期稼働の実績があるなら、案件概要に在籍期間を明記しておくだけで安心材料になる。

③ 記述内容——「提案書の材料になるか」

要員主体のエージェントは、エンジニアのスキルシートをもとに案件元に提案書を出す。 スキルシートの充実度がそのまま提案書の質に直結する。

自己PRが充実していて、案件概要に具体的な成果が書かれていると、提案書の説得力が上がる。 逆にスカスカだと、エージェント側が自分で文面を補わなければならない。 推薦しやすいスキルシートを渡すことが、エンジニア側からできる最大の協力だ。

④ 単価——「スキルと単価のバランスが取れているか」

要員主体の場合、単価の評価は「案件予算に合うか」ではなく**「このスキルセットでこの単価は市場的に妥当か」**という視点になる。

同じスキルセットで単価が適正なエンジニアは、提案先が広がる。 相場より高めの場合は、それを正当化できるだけの実績がスキルシートに書かれている必要がある。 数字で成果が示されていれば「この実績があるからこの単価です」と説明できる。

---

どちらのタイプにも刺さるスキルシートの共通項

案件主体と要員主体で角度は違うが、「良いスキルシート」の条件は結局同じだ。

**自己PRに「推薦の材料」があること。**テンプレ文ではなく、「この人はこういうエンジニアだ」と一言でまとめられる情報を入れる。 「生成AIでスキルシートの自己PRを壁打ちする」で紹介したプロンプトを使えば、材料の棚卸しは5分でできる。

案件概要に「判断」と「数字」があること。 「やったこと」の羅列ではなく、なぜそうしたか、何が変わったかを書く。 「生成AI活用をスキルシートにどう書く？」で紹介した3つの型がそのまま使える。

技術スタックと案件概要の整合性が取れていること。 書いた技術が実務経験で裏付けられているか。 「面談で必ず聞かれるスキルシートの行間」でも書いたが、答えられない技術は自分で地雷を埋めるようなものだ。

更新が直近であること。 半年前の情報で止まっていると、どちらのタイプのエージェントからも「この人は今何をしているんだ？」と思われる。

---

まとめ——エージェントの視点を知ると、書き方が変わる

エージェントは一枚岩ではない。 案件主体は「この人を推薦して大丈夫か」、要員主体は「この人に合う案件を見つけられるか」を見ている。 見ている項目は同じでも、角度が違う。

だが、どちらにも共通するのは**「推薦しやすいスキルシートかどうか」**だ。 エージェントはあなたの味方だが、同時にあなたとクライアントの間の翻訳者でもある。 翻訳しやすい原文を渡すことが、エンジニア側からできる最大の協力だ。

今のスキルシートを開いて、エージェント側の視点で読み直してみてほしい。 「自分がエージェントだったら、この人を推薦できるか？」 ——この問いに自信を持って「YES」と言えるスキルシートを目指そう。

---

※関連記事：500人のスキルシートを見てきて気づいた"もったいない"5選 / 面談で必ず聞かれるスキルシートの行間 / 生成AIでスキルシートの自己PRを壁打ちする / 自分に合ったエージェントの選び方