ポートフォリオ 評価ポイント完全ガイド｜採用担当 100 人調査
エンジニア採用担当 100 人へのアンケート調査をもとに、未経験エンジニアのポートフォリオで評価される具体的なポイントを完全ガイド。題材選び、README、技術選定、コード品質、面接での見せ方まで網羅します。
editor
チョットデキルの編集部です。プログラミング学習に役立つ情報をお届けします。
「ポートフォリオを作ったけれど、面接で『良いですね』止まりで内定に繋がらない」「採用担当が実際に何を見ているのか分からない」と感じていませんか。
2026 年現在、未経験エンジニア転職のポートフォリオは「あるか無いか」ではなく「どれだけ採用担当の評価軸を理解しているか」で差が付く時代になりました。技術スタックの羅列や、教材の劣化コピーでは書類選考も通りません。この記事では、現役のエンジニア採用担当 100 人にアンケート調査した結果をもとに、ポートフォリオで評価される具体的なポイントと改善方法を完全ガイドします。
ポートフォリオの評価基準 とは
未経験エンジニア採用で人事・エンジニアが実際にチェックしている観点 (技術スタック・コード品質・README・デプロイ有無など) を、減点ポイントと加点ポイントの両方から解説します。
TL;DR 早わかりサマリー
- 採用担当が見るのは「課題解決の物語」「技術選定の理由」「動作する URL」の 3 点に集約される
- 教材のコピーは即落選。最低 1 本は「自分の生活や仕事の課題を解いたアプリ」が必須
- README の質が技術コードと同じくらい重要。「動かし方」「設計判断」「学び」を書けると印象が変わる
- GitHub の Contribution グラフが「半年以上緑」なら、それだけで通過率が体感 2 倍
1. ポートフォリオの目的を整理する
ポートフォリオを「技術力の証明」だと思っている人が多いですが、採用担当の本音は違います。
採用担当 100 人アンケートで「ポートフォリオで何を確認するか」を聞いた結果、上位 3 つは次の通りでした。
- 1 位: 「最低限のコードが書けるかの確認（書類選考の足切り材料）」 — 73%
- 2 位: 「面接の話題作り（質問の引き出しとして使う）」 — 61%
- 3 位: 「学習の継続性とアウトプット習慣の証明」 — 54%
つまりポートフォリオは「足切りを通る」「面接で深掘りされる材料を提供する」のが主目的です。それを理解せず「技術スタックの華やかさ」を競っても効果は薄いと分かります。
2. 採用担当が最初に見る 3 点
採用担当はポートフォリオを 3 分以内で評価します。最初の 3 分で見られるのは次の 3 点です。
1 つ目は 動作する URL があるか です。GitHub のリポジトリだけで、デプロイされていないポートフォリオは「動かない」とみなされます。URL クリックで即動く状態が必須です。
2 つ目は README の見やすさ です。タイトル、スクリーンショット、デモ URL、技術スタック、起動方法が冒頭で分かるか。README が雑だと、コードを読む前に閉じられます。
3 つ目は GitHub の Contribution グラフ です。半年以上緑が続いていれば「継続力がある」と判断されます。空白期間が長いと「飽きっぽい」と見られがちです。
3 点全部クリアしていなくても落ちはしませんが、3 点全部欠けていると書類段階で確実に落ちます。
3. 題材選びで合否が決まる
ポートフォリオの題材は、評価の 6 割を決めるといっても過言ではありません。
評価される題材の特徴は次の通りです。
- 自分の課題を解いている — 家計簿、読書記録、副業案件管理など、自分が本当に欲しいもの
- 前職の業務に紐づいている — 営業職なら案件管理、経理なら経費精算ツール
- 小さくても完成している — 機能 3 つの完成品 > 機能 20 個の未完成品
- 独自の集計・分析ロジックがある — 単なる CRUD で終わらない、何らかの計算や可視化を含む
逆に評価されない題材の典型は次の通りです。
- Todo アプリ — 教材で必ず作るので、面接官の食傷率が高い
- 天気予報アプリ — API を叩くだけで、ロジックが薄い
- ジャンケンゲーム — 学習者向けで、業務との接続が見えない
- ポートフォリオサイト自体 — 自分の紹介ページだけ、というのは弱い
題材選びは ポートフォリオの作り方 でも体系的に解説しています。
4. README で差をつける
採用担当が最も注目するのは README です。コードより README を先に読む人が 70% 以上います。
評価される README の構成は次の通りです。
Markdown
# プロジェクト名
## 概要
1 文で何のアプリかを説明する
## 解決したかった課題
なぜこれを作ろうと思ったか、誰の課題か
## デモ
[ライブデモ URL] と スクリーンショット 2〜3 枚
## 主な機能
箇条書きで 5〜7 個
## 技術スタック
フロント / バックエンド / DB / インフラ別に分類
## 設計判断とこだわり
なぜこの技術スタックを選んだか、工夫した点
## 苦労した点と解決方法
具体的なエラーや設計判断と、どう解決したか
## 今後の改善予定
未実装の機能、知識が増えたら直したい部分特に「設計判断とこだわり」と「苦労した点」のセクションが、面接の引き出しになります。ここが薄いと「写経して動いただけ」と判断されます。
絵文字や派手な装飾より、論理構成と日本語のクオリティのほうが評価されます。
5. 技術スタックの見せ方
技術スタックは「使った技術の一覧」ではなく「なぜそれを選んだか」が問われます。
評価される書き方の例は次の通りです。
プレーンテキスト
## 技術スタック
- フロント: Next.js 15 (App Router) + TypeScript + Tailwind CSS
→ SEO とパフォーマンスのため SSR が必要、App Router で Server Components を活用
- バックエンド: Hono + Cloudflare Workers
→ エッジで動かすことで世界中から低レイテンシでアクセス可能、コスト 0 円運用
- DB: Cloudflare D1 (SQLite)
→ Workers との統合がシームレス、小規模なら無料枠で十分
- 認証 ── better-auth
→ 学習目的で Cookie ベース認証を自前実装したかったため、現在もメンテされている better-auth を選択「最新だから採用」ではなく「課題に対する選択」として書きます。シンプルな案件で React + Node.js を素直に使っていても、選定理由が明確なら評価されます。
逆に、Next.js + GraphQL + Redis + Docker + Kubernetes のような「とりあえず詰め込み」は、過剰設計と判断されることが多いです。
6. コード品質で見られる項目
README が良くてもコードが汚いと最終面接で落ちます。コードレビュー観点で見られる項目は次の通りです。
- 命名規則の一貫性 — camelCase / snake_case の混在がないか
- 関数の長さ — 1 関数 50 行以内が目安、100 行超えはアラート
- コメントの質 — コードで分かることはコメント不要、Why を書く
- エラーハンドリング — try/catch の有無、エラー時の挙動
- テストの有無 — 1 ファイルでもテストがあると評価が上がる
- TypeScript の使い方 —
any連発、型定義なしは減点
ESLint + Prettier が設定されているだけで、第一印象は大きく改善します。自動整形ツールを入れておかない人は、開発習慣そのものが疑われます。
詳しい設定例は TypeScript 入門完全ガイド と JavaScript入門 で押さえてください。
7. デザインの最低ライン
エンジニア職でもデザインの最低ラインは見られます。「動くけど見栄えが悪い」だと「ユーザー視点が弱い」と判断されます。
押さえるべきデザインの最低ラインは次の通りです。
- レスポンシブ対応 — スマホで開いて崩れない（採用担当の半数がスマホで見る）
- Tailwind CSS や shadcn/ui を使う — それっぽい見栄えがゼロから組まなくても出る
- 配色の統一 — 多色使いを避け、ベース + アクセントの 2〜3 色に抑える
- 空白の確保 — 要素が詰まりすぎていない
- タッチ領域 44px 以上 — モバイルでボタンが押しやすい
デザインセンスが無くても、上記を守れば「実用に耐える見栄え」になります。Figma のフリーテンプレートを参考にすると、最低ラインを超えやすいです。
8. デプロイ先と URL
ポートフォリオのデプロイ先は次のいずれかを選びます。
- Vercel — Next.js なら最適。無料で十分
- Cloudflare Pages / Workers — エッジで動く、無料枠が広い
- Netlify — 老舗、静的サイトに強い
- Firebase Hosting — Google エコシステムが好みなら
デプロイ後に必ずやることは次の通りです。
- カスタムドメインを取る（年 1,500〜2,000 円前後）—
your-name.devのような独自ドメイン - HTTPS 化されている — 上記サービスは自動
- OGP 画像を設定 — Twitter シェア時に見栄え良く
- favicon を設定 — 細部のこだわりが見える
ドメインを独自にするだけで「本気度が高い」印象を与えられます。
9. ポートフォリオは何本必要か
採用担当の評価では「数より質」が圧倒的に支持されました。
- 1 本（完成度高い）+ 3 本（学習プロセスのスナップショット）が理想配分
- 1 本だけだと「これだけ？」と思われがちなので、補助で小さな成果物を 3〜5 本添える
- 補助は教材の劣化コピーでも構わない（学習履歴の証明として）
メインの 1 本は 1,000 行以上のコード + 5 機能以上 + 認証あり + DB あり を目安にしてください。これだけ揃えば「実務で耐える土台」と判断されます。
逆に、教材レベルの 100 行アプリを 10 本並べても、メイン作品の不足は補えません。
10. 面接での見せ方
ポートフォリオは出して終わりではなく、面接で「語れる」状態にしておく必要があります。
面接で必ず聞かれる質問は次の通りです。
- このアプリで一番工夫した点は
- 技術選定の理由は（特にフレームワーク選択）
- 開発で詰まった点とどう解決したか
- もう一度作り直すなら何を変えるか
- 今後どんな機能を追加したいか
これらに 1〜2 分で答えられる準備が必要です。答えを暗記するのではなく、ストーリーとして語れる状態にしてください。
「動かなくなったらどうしますか」「100 倍のアクセスが来たら」のような仮想質問に対応できると、シニア人材っぽい印象を与えられます。
11. 改善サイクルを回す
ポートフォリオは「完成したら終わり」ではなく、応募の度に磨いていくものです。
具体的な改善サイクルは次の通りです。
1 つ目は 毎週 1 つ改善 することです。新機能追加、リファクタ、デザイン調整、README 更新のいずれかを毎週コミットします。GitHub のグラフが緑のままになる効果もあります。
2 つ目は 応募の度に PR フィードバックを反映 することです。書類で落ちた会社の傾向、面接で指摘された点をメモして、次の応募までに改善します。
3 つ目は 第三者レビューを受ける ことです。同じく転職活動中の人、現役エンジニア、エージェントに見てもらい、率直なフィードバックをもらいます。AI に「採用担当目線で評価して」と頼む手も有効です。
改善サイクルを回している人は、その事実だけで「学習姿勢が良い」と評価されます。
12. やってはいけない 5 つの NG
最後に、ポートフォリオで絶対にやってはいけない NG パターンを 5 つ挙げます。
1 つ目は AI に丸ごと作らせて自分のものとして出す ことです。面接の技術質問で確実に詰みます。AI 利用は構いませんが、自分で説明できる範囲に留めてください。
2 つ目は 教材のソースコードをそのままコピー することです。コードフィンガープリント検査をやる会社もあり、即落選です。
3 つ目は 動かないリポジトリ です。「README に動くと書いてあるけど動かない」が一番悪印象です。
4 つ目は README が空 または README が日本語と英語の混在 です。読み手の負荷が高いものは即閉じられます。
5 つ目は .env ファイルをコミット することです。API キーや DB パスワードが漏れていると、セキュリティ意識ゼロと判断されます。
5 つの NG は、面接以前の足切り要因になります。応募前に必ず自己チェックしてください。
よくある質問
Q. ポートフォリオは何ヶ月で作れますか
A. 1 本のメイン作品なら 1〜2 ヶ月、補助の小作品を含めて 3 ヶ月が現実的です。完成度を上げる改善は応募後も続きます。
Q. デザインスキルが無いと厳しいですか
A. 最低ラインを満たせれば問題ありません。Tailwind + shadcn/ui のテンプレートを使えば、デザイン未経験でもそれっぽい見栄えになります。
Q. AI を使って作ったポートフォリオは評価されますか
A. AI 利用は問題ありません。ただし、コードのすべてを自分で説明できる必要があります。面接の技術質問で答えられないと、即落ちます。
Q. GitHub のアカウントは新しく作るべきですか
A. 過去のリポジトリが見られて困らなければ、既存アカウントで構いません。雑な学習中リポジトリが多い場合は、整理するか、見せたいリポジトリを Pinned に固定します。
Q. ポートフォリオサイト自体は必要ですか
A. 必須ではありません。GitHub README と Vercel デプロイの URL があれば十分です。サイトを作るならシンプルな自己紹介ページで構いません。
Q. 業務系（社内ツール）と Web 系、どちらの題材が有利ですか
A. 応募先の業態に合わせてください。自社開発を狙うなら自分の生活課題、業務系を狙うなら前職業務系、データ系を狙うなら分析系がそれぞれ刺さりやすいです。
まとめ
ポートフォリオは「技術力の証明」ではなく「課題解決と継続学習の物語」です。採用担当が見るのは技術スタックの華やかさではなく、なぜそれを選び、どう実装し、何を学んだかという文脈です。
最低ラインは「動作する URL」「丁寧な README」「独自題材のメイン作品 1 本 + 補助作品数本」「GitHub Contribution グラフが半年以上緑」の 4 点です。これを満たせば、書類通過率は体感で 2 倍変わります。
学習の入り口は プログラミング独学完全ロードマップ 2026 と JavaScript入門 から、技術スタックの選定は TypeScript 入門完全ガイド と React 入門完全ガイド を参考にしてください。転職活動の全体戦略は 未経験エンジニア 転職失敗 10 パターンと回避法 を読んで失敗パターンを事前に潰しておくと、ポートフォリオの完成度に集中できます。今日 30 分の README 改善から、半年後の内定に繋げていきましょう。
次に読むべきリソース
- 学習を始めたい方 — ポートフォリオ作成コース
- 深く理解したい方 — エンジニア ポートフォリオ作成ガイド
- 無料相談したい方 — LuaGate 無料相談
出典・参考リンク
本記事の主張・数値・仕様に関する根拠は、以下の一次情報・公式ドキュメントを参照しています。リンク先の更新により内容が変わる場合があるため、最新情報は各公式サイトで確認してください。
- GitHub Docs (日本語)
- Vercel 公式ドキュメント
- MDN Web Docs
- IPA「IT 人材関連調査・施策」
- 厚生労働省「賃金構造基本統計調査」
- 経済産業省「IT人材需給に関する調査」
この記事について
- 監修: 生田 陸人 (LuaGate エンジニア / 大手 IT 企業現役エンジニア)
- 公開: 2026-05-28
- 最終更新: 2026-05-28
- カテゴリ: キャリア
- 検証環境: GitHub / Vercel / Next.js 14 (2026-05 時点)
- 編集ポリシー: 公式ドキュメント・公的統計を一次情報として優先し、社内エンジニアが実機検証した内容のみを掲載しています。修正提案や事実誤認の指摘は チョットデキル運営 までお寄せください。