
エージェントに登録しているのに紹介が来ない、来ても希望と違う、商談まで進まない——その原因がプロフィールにあるケースは少なくありません。結論から言うと、エージェントのプロフィールはまず担当者が読み、次に企業への提案資料になるという二段構造で使われます。どちらの読み手でつまずいているかが分かれば、直す場所は自然に決まります。
この記事でわかること
【結論】エージェントのプロフィールは二段階で読まれている
エージェントのプロフィールには読み手が2人います。まず担当者が案件を選ぶために読み、次に企業が採否を決めるために読みます。直し方は次の3つです。
- 紹介が来ないなら担当者向けの情報を直す技術名・経験の段階・稼働条件を、案件の要件と照合できる形で書きます
- 商談に進まないなら企業向けの情報を直す担当した課題・自分の役割・成果を具体的に書きます
- 冒頭に3行のサマリーを置く「専門・範囲・直近・条件」を最初に示すと、両方の読み手に一度で伝わります
書き直したら担当者に添削を頼み、案件終了時など4つのタイミングで更新し続けることが成果につながります。
この2人は、見ている場所がまったく違います。
| 読み手 | いつ読むか | 知りたいこと | 効く書き方 |
|---|---|---|---|
| エージェントの担当者 | 案件を探すとき | どの案件に提案できるか | 技術名・経験年数・稼働条件を、案件の要件と照合できる形で明記する |
| 企業の担当者 | 提案を受けたとき | 自社の課題を解決できるか | 担当した課題と、自分が果たした役割を具体的に書く |
利用の流れの中で、プロフィールはいつ読まれる?
エージェントの利用は「登録→担当者との面談→案件の紹介→書類選考→企業との面談→契約」の順に進み、プロフィールは面談前から書類選考まで、少なくとも3回読まれます。
| 段階 | 読む人 | 役割 |
|---|---|---|
| 登録後・面談前 | エージェントの担当者 | 面談で何を聞くか、どの案件が合いそうかの下調べ |
| 案件の紹介 | エージェントの担当者 | 案件の要件と照らし合わせ、提案する候補を選ぶ |
| 書類選考 | クライアント企業 | 複数の候補者の中から、商談に進める人を選ぶ |
| 企業との面談 | クライアント企業 | 質問の材料。書いた内容を口頭で確認される |
なぜ技術の羅列だけでは足りない?
技術の一覧は「候補に入るための情報」であって、「選ばれるための情報」ではないからです。担当者の検索には引っかかりますが、企業から見ると他の候補者との違いが分かりません。多くのプロフィールは担当者向けの情報だけで止まっており、ここを埋めるだけで商談に進む確率が変わります。
担当者向けの情報が足りなければ、そもそも提案されません。企業向けの情報が足りなければ、提案されても選ばれません。両方を満たすことが最適化の目標です。まずは自分がどちらでつまずいているかを、次の章で切り分けてください。
プロフィールの添削や書類のサポートにどこまで対応しているかは、エージェントによって差があります。書き直しに不安がある人は、サポートの手厚い会社を選んでおくと相談しやすくなります。
あわせて読みたい(利用の流れと提出書類)
症状から原因を切り分ける
やみくもに書き直す前に、いま何が起きているかを確認します。症状によって直すべき場所は違うため、ここを飛ばすと的外れな修正に時間を使うことになります。
| 症状 | 考えられる原因 | 直す場所 | 読む章 |
|---|---|---|---|
| そもそも紹介が来ない | 技術や経験の情報が不足している。条件が厳しすぎる | 担当者向けの情報 | 担当者に伝わる形に直す |
| 希望と違う案件ばかり来る | 希望条件と優先順位が伝わっていない | 稼働条件の書き方 | 担当者に伝わる形に直す |
| 提案されるが商談に進まない | 企業から見た決め手がない | 企業向けの情報 | 企業に刺さる形に直す |
| 商談後に見送られる | 書いてある内容と実際の印象が噛み合っていない | 記載の粒度と正確さ | 書きにくい項目はどう扱う? |
| 以前は来ていたのに止まった | 情報が古い。市場の需要が変わった | 更新の運用 | いつ更新する?運用のしかた |
どこで止まっているか分からないときは?
担当者に直接聞くのが最も早い方法です。「提案いただけていないのは、条件の問題でしょうか、それとも書類の内容でしょうか」と聞けば、具体的な答えが返ってくることが多くあります。見送りの理由を教えてもらえた場合、それが最も確実な改善材料になります。
あわせて読みたい(紹介や選考で止まるとき)
担当者に伝わる形に直す
まずは紹介の候補に入るための土台を整えます。担当者は案件の要件と照らし合わせて候補者を探すため、照合できる形で情報が並んでいることが前提になります。
技術名はどう書く?
一般的に使われる名称で書くことが基本です。略称や社内での呼び方は避けます。担当者は名称で候補を絞ることがあるため、表記が違うだけで対象から外れるおそれがあります。略称が広く使われている技術は、正式名称と略称を併記すると確実です。
| 避けたい書き方 | 伝わる書き方 | 理由 |
|---|---|---|
| 社内ツール名・独自の呼び方 | 一般的な製品名・技術名 | 社外の人には何の技術か分からない |
| 略称だけ | 正式名称(略称)の併記 | どちらの表記で探されても見つかる |
| 「クラウド全般」 | 使ったクラウドサービス名と、担当した範囲 | 要件との照合ができる |
| 「フレームワーク各種」 | フレームワーク名を個別に列挙 | 案件の必須条件と照らし合わせられる |
経験の深さはどう示す?
関わり方の段階を書き添えることです。同じ技術名でも、少し触った程度と、主担当として設計した経験ではまったく意味が違います。次のように整理すると、ミスマッチを避けた提案を受けられます。
| 書き方 | 伝わる内容 | 記載の例 |
|---|---|---|
| 技術名のみ | 使ったことがある、という以上の情報がない | 「〇〇(言語名)」 |
| 年数を添える | おおよその習熟度が伝わる | 「〇〇:実務3年」 |
| 段階と規模を添える | 任せられる範囲まで伝わる | 「〇〇:実務3年/主担当として設計から実装まで。5名体制のチームで使用」 |
稼働条件はどこまで具体的に書く?
担当者がその場で可否を判断できる形まで具体化します。「リモート希望」ではなく「出社は月2回まで可」、「週数日希望」ではなく「週3日・1日7時間まで」というように書きます。曖昧な表現は、確認のための連絡を発生させ、その分だけ紹介が遅れます。
- 稼働日数週何日か。増減の相談に応じられるかも書き添える
- 出社の可否完全在宅か、月何回までなら可能か
- 単価の下限これを下回るなら受けないという金額
- 参画できる時期現契約の終了時期も含めて具体的に
- 優先順位単価・リモート・技術のどれを優先するか
フリーランスボードが2026年8月7日時点の掲載案件を集計したデータでは、IT案件の働き方はフルリモート23.3%・一部リモート52.5%・常駐24.2%でした。フルリモートに限定すると対象の案件は約4分の1になるため、「出社は月◯回まで可」のように許容範囲を書いておくと、紹介の母数が広がります。
あわせて読みたい(希望条件と働き方)
企業に刺さる形に直す
紹介はされるのに商談へ進まない場合、直すのはこちらです。企業が見ているのは「自社の課題を任せられるか」という一点で、技術の一覧はその判断材料になりません。
課題と役割はどう書く?
「どんな課題があり、自分が何を担当し、結果どうなったか」の順で書くと、企業は自社の状況に置き換えて読めます。技術は目的ではなく手段として登場させるほうが、説得力が出ます。実績は次の型で書きます。
- 課題どんな状況・問題があったか(例:申し込み画面で離脱が多かった)
- 役割自分が何を任され、どの範囲を担当したか(例:画面設計と改修の主担当)
- 施策何をしたか。使った技術はここで書く(例:入力項目を整理し、確認画面を見直した)
- 成果どう変わったか。数字が出せなければ方向だけでも書く(例:入力項目を9つから5つに削減)
| 伝わりにくい書き方 | 伝わる書き方 |
|---|---|
| 「開発を担当」 | 「問い合わせが増えていた申し込み画面の改修を担当。入力項目を9つから5つに整理し、離脱の要因を減らした」 |
| 「保守運用を担当」 | 「監視の仕組みを整備し、対応手順を文書化。障害の一次対応を担当し、引き継ぎ可能な体制にした」 |
| 「チームで開発」 | 「5名のチームで、情報設計と全画面の設計を担当(実装は別メンバー)」 |
任された範囲はなぜ重要?
裁量の範囲は、企業が最も知りたい情報のひとつだからです。仕様が決まったものを実装したのか、要件から関わったのか、技術選定を任されたのか。上流に関わった経験があるなら、それを埋もれさせないでください。同じ年数でも、任せられる範囲の評価が変わります。
技術以外の貢献も書いていい?
書いたほうがよい要素です。レビューの仕組みづくり、ドキュメントの整備、非エンジニアとの調整といった動きは、チームに入る人材として評価される部分です。派手さはなくても、一緒に働く姿が想像できる情報は判断材料になります。
あわせて読みたい(面談・実績・オファー)
冒頭のサマリーを作ると通過率が変わる
読み手は最初の数行で「読み進めるか」を判断します。冒頭に3行程度のサマリーを置くと、経歴の全体像が一度で伝わり、以降の記述が読まれやすくなります。案件ごとに書き換えるのもここだけで済みます。
「何の専門か」+「経験年数と担当範囲」+「直近で何をしていたか」+「稼働条件」。この専門・範囲・直近・条件の4点が最初に分かれば、担当者は案件を選べ、企業は判断できます。
職種別のサマリーの例は?
| 職種 | 冒頭サマリーの例 |
|---|---|
| バックエンドエンジニア | 「Webサービスのバックエンド開発を中心に実務8年。要件の整理から設計・実装・リリースまでを担当できます。直近2年は利用者数の多いサービスの改修で、処理の見直しと監視の整備を行いました。週4日・フルリモートで、〇月から参画可能です。」 |
| Webデザイナー | 「事業会社のWebサイトとアプリのUIデザインを中心に実務6年。情報設計から画面設計、デザインの運用ルールづくりまで担当できます。直近1年は会員向けサービスの画面改善を担当しました。週3日・出社は月2回まで可、〇月から参画可能です。」 |
| PM・PMO | 「業務システム開発のPM・PMOとして実務7年。10名前後のチームの進行管理、課題管理、関係部署との調整を担当してきました。直近はシステム刷新プロジェクトのPMOとして、進捗の見える化と会議体の整理を行いました。週5日・一部出社可で、〇月から参画可能です。」 |
案件ごとに書き換えるべき?
全面的に書き直す必要はありません。サマリーの1行目と、強調する実績の順番を入れ替えるだけで十分です。狙う案件の傾向が変わったのに、以前と同じ内容を出し続けていると、案件への関心が伝わりにくくなります。
改善前・改善後でプロフィールはどう変わる?
全体を比べると、改善後は「担当者が照合できる情報」と「企業が判断できる情報」の両方がそろっていることが分かります。自分のプロフィールと見比べて、足りない要素を確認してください。
| 項目 | 改善前 | 改善後 |
|---|---|---|
| 冒頭 | Webエンジニアとして幅広く開発に従事。コミュニケーションを大切にしています | ECサイトのバックエンド開発を中心に実務5年。設計から実装・テストまで担当。直近は決済まわりの改修。週4日・〇月から参画可能 |
| スキル | Java、SQL、クラウド全般、フレームワーク各種 | Java(実務5年・主担当)、SQL(実務5年)、AWS(実務2年・構築と運用) |
| 経歴 | A社で開発を担当(3年)、B社でチーム開発(2年) | 8名チームで基本設計・実装を担当。処理の見直しで画面表示を約半分に短縮 |
| 希望条件 | リモート希望、単価応相談 | 週4日、出社は月2回まで可、単価の下限〇万円、〇月〇日から参画可能 |
改善後のプロフィールは、担当者は「どの案件に出せるか」、企業は「何を任せられるか」をすぐに判断できます。特に、スキルに経験の段階を添えることと、経歴に数字を1つ入れることは、すぐに取り入れられる改善です。
書きにくい項目はどう扱う?
空欄のままになりがちな項目こそ、丁寧に扱う価値があります。書けない理由を明記するだけでも、読み手の疑問は減ります。
| 書きにくい項目 | 書き方の方針 | 記載の例 |
|---|---|---|
| 守秘義務がある案件 | 業界・規模・担当業務に置き換える | 「大手小売業の会員向けサイトのリニューアルで、情報設計と画面設計を担当」 |
| ブランクがある | 期間と事情を簡潔に書き、その間の学習も添える | 「〇年〇月〜〇月:家族の事情で休業。期間中に〇〇を学習し、個人開発で〇〇を作成」 |
| 経験が浅い領域 | 「学習中」「補助として経験あり」と段階を正確に書く | 「〇〇:実務経験なし・学習中(個人開発で使用)」 |
| 数字を出せない実績 | 非公開である旨と、施策・役割を具体的に書く | 「数値は非公開のため記載を控えます。〇〇の見直しを主担当として実施」 |
守秘義務がある案件はどこまで書ける?
企業名やサービス名を出せない場合は、業界と規模感、担当した業務の水準に置き換えて書くのが一般的な対応です。どこまで書けるかは契約内容によるため、判断に迷う場合は担当者に相談してください。
経験が浅い領域を大きく見せてもいい?
避けてください。できることを大きく見せたい気持ちは自然ですが、実態を超えた記載は、商談や参画後に食い違いとして表れます。段階を正しく書いておけば、経験が浅くても任せられる範囲の案件が届きます。
経歴や経験年数を事実と異なる形で記載すると、契約の解除や損害賠償の問題に発展する可能性があります。また、守秘義務のある情報をどこまで書けるかは、締結した契約の内容によって変わります。この記事は一般的な情報提供であり、法的な助言ではありません。判断に迷う場合は、記載前に担当者へ相談し、契約上の解釈が必要な場合は弁護士などの専門家に確認してください。
あわせて読みたい(ブランク・経験不足・契約)
いつ更新する?運用のしかた
プロフィールは一度作って終わりではありません。情報が古いままだと、実力を過小評価されたまま案件が決まっていきます。更新すべきタイミングは次の4つです。
- 案件が終了したとき記憶が新しいうちに、担当範囲と成果を書き足します。時間が経つほど具体的に書けなくなります
- 新しい技術を実務で使ったとき使った時点で追記します。「習得したらまとめて書こう」とすると、そのまま抜け落ちます
- 稼働条件が変わったとき古い条件のまま紹介が続くのを防げます
- 紹介が止まったとき市場の需要か、自分の情報のどちらかが変わっているサインです
複数社に登録している場合はどうする?
元になる資料を自分で1つ持ち、そこから各社に反映する運用にします。片方だけ更新して内容に差が出ると、企業側で照合されたときに食い違いが生じます。更新した月をファイル名に入れておくと、どれが最新か迷いません。
月末に5分だけ記録する
更新をまとめてやろうとすると続きません。月末に5分、その月に担当したことと数字をメモしておくだけで十分です。この記録は、プロフィールの更新だけでなく、契約更新時の単価交渉の材料にもなります。
あわせて読みたい(複数登録・交渉・相談)
やりがちな失敗パターンと、提出前の最終チェック
次の5つは、どれも書き手には気づきにくく、読み手には伝わっている問題です。心当たりがあれば、その場所から直してください。
| 失敗パターン | 読み手の印象 | 直し方 |
|---|---|---|
| 技術の羅列だけで終わっている | 他の候補者との違いが分からない | 代表的な案件に、課題と役割の説明を足す |
| 自己紹介が抽象的な言葉で埋まっている | 誰にでも当てはまり、判断材料にならない | 「コミュニケーションを大切に」の代わりに、具体的な場面を1つ書く |
| 分量が多すぎて要点が埋もれる | 強みが薄まり、印象に残らない | 直近と狙う領域の案件を厚く、それ以外は簡潔に |
| どの案件にも同じ内容を出している | 案件への関心が伝わりにくい | 冒頭のサマリーと実績の順番だけ入れ替える |
| 古い情報のまま放置している | 直近の経験が評価されない | 案件終了時と技術の追加時に更新する |
提出前に確認したい10項目は?
- 冒頭サマリー専門・範囲・直近・条件の4点が3行程度で書かれている
- 技術名一般的な名称で書かれ、社内の呼び方や「各種」でまとめていない
- 経験の段階主要な技術に、実務年数と関わり方(主担当・メンバー・補助)が添えてある
- 実績の書き方代表的な案件が「課題→役割→施策→成果」で書かれている
- 数字チームの人数、期間、改善の結果など、少なくとも1つ数字が入っている
- 稼働条件稼働日数・出社の可否・単価の下限・参画できる日付が具体的に書かれている
- 学習中の技術実務経験のある技術と分けて書かれている
- 守秘義務出せない企業名や数値は、業界・規模・方向に置き換えてある
- 期間の連続性経歴に説明のない空白がない
- 複数社との整合各社に出している内容が、元の資料と一致している
自分では気づけないときは?
担当者に添削を依頼するのが最も早い方法です。書類の添削に対応しているエージェントは多く、案件の選考基準を踏まえた指摘をもらえます。複数社に登録していれば、それぞれの担当者から違う視点の指摘を受けられます。
プロフィールについてのよくある質問
プロフィールは、担当者が案件を選ぶ資料であり、企業への提案資料でもある。面談前から書類選考まで少なくとも3回読まれる
紹介が来ないなら担当者向けの情報(技術名・経験の段階・稼働条件)、商談に進まないなら企業向けの情報(課題・役割・成果)を直す
冒頭に「専門・範囲・直近・条件」の3行サマリーを置き、提出前は10項目のチェックリストで確認する

