なぜポートフォリオがプロンプトエンジニアの転職に必須なのか
プロンプトエンジニアは比較的新しい職種であり、資格や学歴で実力を証明することが困難です。採用担当が最も重視するのは「実際に何を作れるか」であり、ポートフォリオはその証明手段として最も効果的です。
本記事では、採用担当の視点から「選考を通過するポートフォリオ」の作り方を、必須プロジェクト3本の具体例からGitHubでの見せ方、面接でのプレゼン方法まで解説します。
採用担当が見る5つのポイント
| ポイント | 内容 | 評価基準 |
|---|
| 1. 問題解決力 | 実際のビジネス課題をAIで解決した事例 | 「何を解決したか」が明確か |
| 2. プロンプト設計力 | 体系的なプロンプト設計のアプローチ | Few-shot、Chain of Thought等の活用 |
| 3. 再現性 | プロジェクトを第三者が再現できるか | READMEの充実度、手順の明確さ |
| 4. 継続性 | 定期的にプロジェクトを更新しているか | GitHubのコミット頻度、最終更新日 |
| 5. 実用性 | 実際に使えるものを作っているか | デモ環境、実績データの有無 |
必須プロジェクト3本の具体例
プロジェクト1：業務自動化ツール
最も採用担当に評価されるのは、実際の業務を自動化したプロジェクトです。
| 項目 | 内容 |
|---|
| テーマ例 | カスタマーサポートの自動分類・回答生成システム |
| 使用技術 | GPT-4 API、LangChain、Python |
| プロンプト設計 | Few-shotで問い合わせカテゴリを分類→カテゴリ別の回答テンプレートをChain of Thoughtで生成 |
| 成果指標 | 回答精度90%、対応時間70%削減 |
| READMEに書くこと | 課題の背景、プロンプトの設計思想、評価方法、改善の過程 |
プロジェクト2：コンテンツ生成パイプライン
| 項目 | 内容 |
|---|
| テーマ例 | SEO記事の自動生成＋品質チェックパイプライン |
| 使用技術 | Claude API、GPT-4、Gemini（複数LLM比較） |
| プロンプト設計 | キーワード分析→構成案生成→本文執筆→品質チェック→修正の多段パイプライン |
| 成果指標 | 生成品質スコア、人間のレビュー工数の削減率 |
| 差別化ポイント | 複数LLMの出力比較、品質評価の自動化 |
プロジェクト3：RAG（検索拡張生成）システム
| 項目 | 内容 |
|---|
| テーマ例 | 社内ナレッジベースのAI検索・回答システム |
| 使用技術 | OpenAI Embeddings、Pinecone/Weaviate、LangChain |
| プロンプト設計 | 検索クエリの最適化→コンテキスト注入→回答生成→ソース引用 |
| 成果指標 | 回答精度、ハルシネーション率、ユーザー満足度 |
| 差別化ポイント | ハルシネーション対策の工夫、評価メトリクスの設計 |
GitHubでの見せ方 — リポジトリ構成のベストプラクティス
| 要素 | 推奨内容 | 理由 |
|---|
| README.md | 課題→解決策→プロンプト設計→成果→使い方 | 採用担当が最初に見るファイル |
| prompts/ディレクトリ | 全プロンプトをバージョン管理 | プロンプトの進化過程を見せる |
| evaluation/ディレクトリ | 評価結果、比較データ | 定量的な成果を証明 |
| docs/ディレクトリ | 設計ドキュメント、図解 | 思考プロセスの可視化 |
| コミットメッセージ | 変更理由を明確に記載 | 思考の過程が見える |
| Issues/PR | 改善点をIssueで管理 | 継続的改善の姿勢を示す |
| LICENSE | MITライセンス推奨 | オープンソースへの理解を示す |
| .env.example | APIキーの設定方法を示す | 再現性の確保 |
技術ブログの書き方 — プロンプトエンジニアとしての発信
| ブログテーマ | 内容例 | SEO効果 |
|---|
| プロンプト設計の比較記事 | 「同じタスクをGPT-4とClaudeで比較してみた」 | 高（検索需要あり） |
| 失敗と改善の記録 | 「ハルシネーションを90%削減した3つの工夫」 | 高（実践的な情報） |
| 業界別のユースケース | 「医療分野でのプロンプト設計の注意点」 | 中（ニッチだが専門性が高い） |
| ツール紹介 | 「LangChainとLlamaIndexの使い分け」 | 高（ツール比較は需要大） |
| 学習記録 | 「プロンプトエンジニアになるまでの12週間」 | 中（同じ志の人に響く） |
ブログの発信プラットフォームはZenn・Qiita・noteが推奨です。GitHubのプロフィールからリンクすることで、ポートフォリオの補完になります。
面接でのプレゼン方法 — STAR法で語る
| STAR要素 | 内容 | プロンプトエンジニアの例 |
|---|
| Situation（状況） | どんな課題があったか | 「カスタマーサポートの回答に平均30分かかっていた」 |
| Task（課題） | 自分の役割は何か | 「AIで回答を自動生成し対応時間を短縮する」 |
| Action（行動） | 何をしたか | 「Few-shotプロンプトで問い合わせを分類し、Chain of Thoughtで回答を生成」 |
| Result（結果） | どんな成果が出たか | 「回答精度90%、対応時間70%削減、月40時間の工数削減」 |
ポートフォリオのNG例 — 採用担当が不合格にする5パターン
| NGパターン | なぜダメか | 改善策 |
|---|
| 1. ChatGPTの会話ログだけ | プロンプト設計の思考プロセスが見えない | 設計意図・改善過程を文書化 |
| 2. コピペのプロジェクト | チュートリアルそのまま | 独自の課題設定と工夫を加える |
| 3. READMEが空 | 何のプロジェクトかわからない | 課題→解決→成果を明記 |
| 4. 更新が半年以上前 | 学習意欲が疑われる | 週1回以上のコミットを維持 |
| 5. 成果指標がない | 効果を定量評価していない | 精度、速度、コスト削減率を計測 |
ポートフォリオ作成のタイムライン — 4週間で完成させる
| 週 | タスク | 成果物 |
|---|
| 第1週 | プロジェクトテーマ選定、技術調査 | 3プロジェクトの企画書 |
| 第2週 | プロジェクト1の実装・評価 | GitHubリポジトリ1つ完成 |
| 第3週 | プロジェクト2・3の実装 | GitHubリポジトリ3つ完成 |
| 第4週 | ブログ執筆、GitHubプロフィール整備 | ブログ2本、プロフィール完成 |
まとめ — ポートフォリオは「思考プロセスの証明」
- プロンプトエンジニアのポートフォリオは資格の代わりとなる最重要ツール
- 必須プロジェクトは業務自動化・コンテンツ生成・RAGシステムの3本
- GitHubではプロンプトのバージョン管理と評価データを必ず含める
- 技術ブログはZenn・Qiita・noteで定期発信
- 面接ではSTAR法で成果を語る
- 4週間で基本的なポートフォリオは完成可能
