この記事の結論
- ChatGPT/Claude で職経を書いてペラくなる原因は、AI に渡している情報が薄い こと。「私の経験を職経にして」だけでは抽象的な一般論しか返ってこない
- 解決策は 職経3層構造（職務 / 成果 / 学び）× 3ファイル運用（career.md / projects.md / numbers.md）。自分の経験を文書化して AI に読ませる方式に切り替える
- 成果は STAR法（Situation / Task / Action / Result）で構造化する。数値で表現できる成果（売上◯%増・処理時間◯時間短縮・離職率◯pt減）は数字で書いておきたい
- 厚労省ハローワークと人事院がテンプレ・書き方を公開している。フォーマットは公的テンプレに合わせる のが安全。中身を AI で深める
- 「AI で書いたとバレるか」を気にする前に、バレても問題ない密度（自分の経験ベースの具体性）を確保するほうが本質的だ
- 記事末尾の 職経コーチ6ブロック構造プロンプト（3層構造） で、ファイルから 1 経歴を 30 分で出力できる
「ChatGPT に職経を書いてもらったが、なんか自分らしくない」「Claude に書かせたが他の人と差がつかない」——転職活動の最初の壁で、こうつぶやく人は多い。
たとえば、34歳・営業職・年収520万円。10年以上同じ会社にいて、「自分の強みって何だっけ」を言語化できないまま、ChatGPT に「営業10年の職経を書いて」と頼んでみた。返ってくるのは、「お客様との信頼関係を構築し売上目標を達成」のような テンプレ通りの一般論。読み手が見れば、誰の経歴か分からない。
この壁を突破する方法は2つある。(A) AI を使わず自分でゼロから書く運用、(B) 自分の経験を文書化して AI に渡す運用。本記事は (B) を扱う。
(B) を支えるのが3層構造と3ファイル運用だ。第1層：職務（時系列）、第2層：成果（数値）、第3層：学び（抽象化） の3層を、それぞれ独立したファイル（career.md / projects.md / numbers.md）に分けて文書化する。これを AI に渡すと、AI の出力は「他の人と差がつく」「自分らしい」内容に変わる。
AI 活用5段階 でいう第2段階「育てる」（自分の判断基準を AI に渡す関係）の転職版だ。（AI×クラウドソーシングで底上げするフォルダ運用）と （X×AI 投稿運用）で確立されたフォルダ運用思想を、転職書類に応用した形でもある。
本記事では、職経3層構造の整理、3ファイル運用、STAR法での成果記述、厚労省テンプレ準拠の構成、実例 Before/After、職経コーチ6ブロック構造プロンプトを順に扱う。読み終わるまでに、自分の3ファイルが用意でき、AI で1経歴を出力できる状態になる。
なぜ「ChatGPT に職経を書いて」がペラくなるのか
AI が悪いのではなく入力が薄い
ChatGPT や Claude は、入力された情報の範囲でしか出力できない。「営業10年の職経を書いて」と頼むと、AI は「営業10年の人が一般的に書きそうな職経」を出力する。これがペラさの正体だ。
逆に、自分の経験を300字でも具体的に渡すと出力は一気に変わる。たとえば「BtoB SaaS 営業3年、社内最年少でリーダー、新規開拓と既存深耕の両軸、半期で予算180%達成、後輩2人をオンボーディング」と入力するだけで、AI は固有性を持った経歴に組み立てられる。
つまり、AI に書かせる前に「何を渡すか」を整理する のが先だ。これが3層構造×3ファイル運用の出発点だ。
「AI で書いたかバレるか」より「中身が薄いとバレる」
「AI で書いたとバレるか」を気にする人は多い。実態としては、AI で書いたことそのものは問題視されにくい。問題は、AI が出力した抽象的な一般論をそのまま貼り付けることだ。読み手は「具体性のなさ」「他の応募者と差がつかなさ」を見抜く。
職務経歴書で重視されるのは作成手段ではなく内容である 。AI を使ったかどうかではなく、経験や実績が具体的に伝わるか で評価される。AI 活用は「ペラい一般論」を避ける運用線さえ守れば、書き直し時間の短縮として有効に使える。
ペラさを生む3つのパターン
| パターン | 例 | なぜ弱いか |
|---|---|---|
| 抽象一般論 | 「お客様との信頼関係を構築」「売上目標を達成」 | 誰でも書ける |
| 数字なし定性 | 「業務効率化に貢献」「チームを牽引」 | 効果規模が見えない |
| 盛りすぎ | 「業界トップの成績」「組織を変革」 | 裏取りで矛盾が出る・面接で詰まる |
3層構造は、この3パターンを避けるための整理軸でもある。
このセクションのポイント
- AI が悪いのではなく、AI に渡す情報が薄いことが原因
- 「AI で書いたか」より「中身が薄いか」のほうが見抜かれる
- 抽象一般論・数字なし定性・盛りすぎの3パターンを避ける
職経3層構造 — 職務 / 成果 / 学び
3層に分けて整理する理由
職経の中身は、性質の違う3つの情報が混ざっている。
- 第1層：職務（時系列） — いつ、どこで、何をやったか。事実情報
- 第2層：成果（数値） — その結果、何が変わったか。STAR法のR
- 第3層：学び（抽象化） — 経験から何を引き出したか。次の職場で再現できる強み
混ぜて書くと、職務の羅列になるか、成果の自慢になるか、抽象的な強みアピールに偏る。3層に分けて整理してから、職経の文章として再合成すると、バランスが取れる。
3層を独立ファイルに分ける運用
3層は1ファイルに混ぜず、3ファイルに分ける。
- career.md：職務の時系列。会社・部署・役職・在籍期間・業務範囲
- numbers.md：成果の数値。STAR法の R を中心に、根拠と算出条件付きで
- projects.md：学びの抽象化。プロジェクト単位で、何を引き出したか・次の職場で再現できる強みは何か
ファイルを分ける理由は3つ。(1) 後から追加・修正しやすい、(2) AI に渡す時に「今回はnumbers.md だけ参照」のような切り替えができる、(3) 機微情報の管理範囲を分離できる（後述）。
このセクションのポイント
- 職経の中身は3層（職務/成果/学び）に分けて整理する
- 3層を3ファイルに分けて文書化する
- 後の追加・修正、AI への渡し分け、機微情報管理の3点で分離が効く
STAR法で成果を数値化する
STAR法の4要素
STAR法は職務経歴書や面接での自己アピールを構造化するフレームワークで、Situation（状況）/ Task（課題）/ Action（行動）/ Result（結果）の4要素で構成される。Skills（スキル）を加えてSTARSと呼ぶこともある。
| 要素 | 中身 | 例（営業10年・SaaS会社） |
|---|---|---|
| Situation | 当時の状況・背景 | 既存顧客の解約率が前年同期比で5pt悪化 |
| Task | 自分が解決すべき課題 | 解約率を半年で元の水準に戻す |
| Action | 具体的にやったこと | 解約理由ヒアリング50件、利用データ分析、CS連携で月次レビュー設計 |
| Result | 数値で見える結果 | 半年で解約率を3pt改善、年間粗利2,400万円の維持 |
成果を数値化するコツ
「業務効率化に貢献」のような定性表現を避け、数値で表現する。数値化のパターンは大きく5つだ。
- 金額：売上・粗利・コスト削減
- 率：%・倍率・前年比
- 件数：商談数・案件数・契約数
- 時間：処理時間短縮・スループット改善
- 人数：マネジメント対象・育成人数
数値化の難しい職種（バックオフィス・研究開発・クリエイティブ）でも、何らかの定量指標は引き出せる。例：経理なら「決算所要日数の短縮」「監査対応時間」、研究なら「論文・特許・実装件数」、クリエイティブなら「制作本数・PV・エンゲージ」。
数値化できないものは条件と根拠を付ける
すべての成果を数値化できるわけではない。数値化できないものは、条件と根拠 をセットで書く。
| 弱い書き方 | 強い書き方 |
|---|---|
| チームを牽引 | 6名のチームでリーダーを2年担当。週次1on1の運用設計と、四半期ごとの個別目標シート作成を主導 |
| 業務効率化に貢献 | 月次の請求書発行プロセスを再設計。Excel マクロで2日かかっていた作業を半日に短縮 |
| お客様との信頼関係を構築 | 担当顧客15社のうち、年間契約更新率100%を3年連続で維持 |
厚労省・人事院テンプレに合わせる
厚生労働省のハローワークと人事院は、職務経歴書のテンプレートを公開している。フォーマットは公的テンプレに合わせるほうが安全だ。中身を AI で深める運用に切り替える。
公的テンプレの基本構成は以下の通り。
- 個人情報欄
- 職務要約（200〜300字）
- 職務経歴（時系列・会社/部署/役職/業務範囲/成果）
- 資格・スキル
- 自己PR
このセクションのポイント
- STAR法で成果を構造化する
- 数値化のパターンは金額・率・件数・時間・人数の5つ
- 数値化できないものは条件と根拠をセットで書く
- フォーマットは厚労省・人事院の公的テンプレに合わせる
3ファイルの中身を整理する
career.md（職務の時系列）
会社・部署・役職・在籍期間・業務範囲を時系列で並べる。仮名運用が安全な箇所（会社名・取引先・固有プロダクト名）は仮名・業種に置き換える。
# career.md
## 株式会社A（2018-04 〜 現在 / 7年）
業種：BtoB SaaS（マーケティング自動化）
規模：従業員500名
所属：営業本部・新規開拓グループ → 既存顧客深耕グループ
役職：メンバー → リーダー（2022-04〜）
業務範囲：
- 新規開拓3年（2018-2021）
- 既存顧客深耕4年（2021-現在）
- リーダー業務（2022-現在）：6名チーム、週次1on1、四半期目標管理
## 株式会社B（2014-04 〜 2018-03 / 4年）
業種：人材サービス
所属：法人営業部
役職：メンバー
業務範囲：中小企業向けの新規開拓、契約後フォロー
numbers.md（成果の数値）
STAR法の R を中心に、Situation / Task / Action とセットで書く。算出条件・根拠も併記する。
# numbers.md
## 株式会社A・既存顧客深耕（2021-2023）
### 解約率改善
- Situation: 既存顧客の解約率が前年同期比で5pt悪化
- Task: 解約率を半年で元の水準に戻す
- Action: 解約理由ヒアリング50件、利用データ分析、CS連携で月次レビュー設計
- Result: 半年で解約率を3pt改善、年間粗利2,400万円の維持
### 予算達成
- 上期予算：1.2億円 / 達成：1.4億円（達成率117%）
- 下期予算：1.5億円 / 達成：1.65億円（達成率110%）
- 通期予算達成率：113%
- 算出条件：契約金額の月割り按分、解約分は控除
## 株式会社A・リーダー業務（2022-現在）
### チームマネジメント
- 6名チームで週次1on1を運用設計
- 四半期目標シートを個別作成
- 後輩2名を半期でオンボーディング完了
- 結果：チーム予算達成率を 95% → 110% に引き上げ
projects.md（学びの抽象化）
プロジェクト単位で、何を引き出したか・次の職場で再現できる強みは何かを記述する。
# projects.md
## プロジェクト：解約率改善（2021-2022）
### 何が学びだったか
- 既存顧客の声を「解約後の理由」ではなく「契約継続中の小さな兆候」で取りに行く重要性
- 営業単独では限界があり、CS と連携した運用設計が解約率を変える
- データ分析を「結論を出す道具」ではなく「問いを立てる道具」として使う視点
### 次の職場で再現できる強み
- 顧客の小さな兆候を取りに行くヒアリング設計
- CS・カスタマーサクセスとの連携運用の組み立て
- データ分析を問いに使う視点
## プロジェクト：チームリーダー（2022-現在）
### 何が学びだったか
- 1on1 は雑談ではなく「次の四半期目標を一緒に組む場」として設計すると効く
- 後輩のオンボーディングは「教える」ではなく「自走する仕組みを作る」のほうが早い
- 個別目標シートは月次の振り返りで意味が生まれる（作るだけでは効かない）
### 次の職場で再現できる強み
- 1on1 を目標設計の場として運用する型
- オンボーディング設計（自走化）
- 個別目標シートの月次振り返り運用
機微情報の運用線
3ファイルに書かないリストを最初に決めておく。
| 区分 | 書かないもの | 仮名/抽象化での代替 |
|---|---|---|
| 会社名 | 実名 | 「株式会社A」「BtoB SaaS（マーケ自動化）」 |
| 取引先 | 実名 | 「上場製造業1社」「中堅IT企業3社」 |
| 数字の出所 | 内部資料そのもの | 算出条件のみ記載（例：契約金額の月割り按分） |
| 個人情報 | 同僚・上司の実名 | 役職と人数のみ |
機微情報を AI に渡さない運用と、職経提出時の表現の二重で守る。
このセクションのポイント
- career.md / numbers.md / projects.md の3ファイルに分けて文書化する
- 仮名運用と算出条件併記で機微情報を守る
- 学び（projects.md）は「次の職場で再現できる強み」を意識して書く
職経コーチ プロンプト（3層構造）
共通の注意
このプロンプトは、3ファイルから1経歴の職務経歴書本文を 30 分で出力するために作った。
- 機微情報（会社名・取引先・契約金額の具体値）は3ファイル時点で仮名・レンジ表現にしておく
- 出力は ベースライン。最終提出前に自分の言葉で1回読み直す
- AI で書いたかバレる前に、ファイル化した自分の経験ベースで具体性を持たせる
- AI サービスのプランによってはデータ学習扱いがある。法人向けプラン or オプトアウト設定で運用する
第1層：短版（10行で動かす）
あなたは職務経歴書のコーチ。
私の career.md / numbers.md / projects.md を踏まえて、
職務経歴書の1経歴分を以下の構造で出力してください。
構造：
- 会社情報（業種・規模・在籍期間・役職）
- 職務要約（150字以内）
- 主な実績（STAR法でR中心に3件）
- 学び・強み（次の職場で再現できる粒度で2件）
第2層：完全版（6ブロック構造）
# 役割定義
あなたは職務経歴書のコーチで、転職希望者の career.md / numbers.md / projects.md
の3ファイルから、厚生労働省・人事院テンプレ準拠の職経1経歴分を出力する役割だ。
# 思考プロセス
1. career.md から会社情報・役職・業務範囲を抽出
2. numbers.md から該当時期の成果を STAR法（S/T/A/R）で構造化
3. projects.md から学び・強みを「次の職場で再現できる粒度」で抽出
4. 上記3点を職経本文として組み立てる
5. 抽象一般論・数字なし定性・盛りすぎの3パターンを排除する
# 判定目安
- 職務要約：150字以内、会社業種＋役職＋主な業務範囲＋数値1つ
- 主な実績：3件、各 STAR法で構成、必ず数値を含める
- 学び・強み：2件、次の職場で再現できる粒度（抽象すぎず・具体すぎず）
- 全体文字数：1経歴で 600〜1,200字目安
# 必須項目固定（出力に必ず含める）
1. 会社情報（業種・規模・在籍期間・役職）
2. 職務要約（150字以内）
3. 主な実績3件（STAR法・数値必須）
4. 学び・強み2件
5. 業務範囲ハイライト（任意・3行以内）
# 制約条件
- 機微情報を勝手に補完しない（入力ファイルにないものは「[要補記]」と明示）
- 「絶対」「正しい」「必ず」「すべき」等の二値断定を使わない
- 顧客モノ扱い動詞（拾う/取りこぼす/捕まえる）を使わない
- 数字は入力ファイルの値のみ。盛らない
- 「業界トップ」「最高水準」「圧倒的成果」のような優良誤認表現を使わない
# 出力前自己チェック
- 各実績で数値が入っているか
- 学び・強みは「次の職場で再現できる粒度」か
- 入力ファイルにない情報を勝手に補完していないか
- 抽象一般論・数字なし定性・盛りすぎに該当する文がないか
第3層：入力例つき版（実機検証）
実際にClaude Sonnet 4.5で第2層プロンプトに上記の career.md / numbers.md / projects.md を入力して実行した。
出力例（要約・整形済み）：
## 株式会社A（2018-04〜現在 / 7年）
業種：BtoB SaaS（マーケティング自動化）／規模：従業員500名
所属：営業本部・新規開拓グループ → 既存顧客深耕グループ
役職：メンバー → リーダー（2022-04〜、6名チーム）
### 職務要約（148字）
BtoB SaaS（マーケ自動化）の営業を7年。新規開拓3年、既存顧客深耕4年、
2022年からリーダーとして6名チームを管掌。通期予算達成率113%、
解約率改善で年間粗利2,400万円の維持を実現。
### 主な実績
1. 解約率改善（2021-2022）
- Situation：既存顧客の解約率が前年同期比5pt悪化
- Task：解約率を半年で元の水準に戻す
- Action：解約理由ヒアリング50件、利用データ分析、CS連携で月次レビュー設計
- Result：半年で解約率3pt改善、年間粗利2,400万円の維持
2. 通期予算達成（2022年度）
- Situation：上期予算1.2億円・下期予算1.5億円の通年計2.7億円
- Task：予算達成率100%以上の維持
- Action：四半期目標シートで個別管理、月次レビューで進捗追従
- Result：通期予算達成率113%（上期117%・下期110%）
3. チームマネジメント（2022-現在）
- Situation：チーム予算達成率が直近2期で95%水準
- Task：チーム予算達成率を100%超水準に引き上げる
- Action：週次1on1運用設計、四半期目標シート、後輩2名のオンボーディング
- Result：チーム予算達成率を95%→110%に引き上げ
### 学び・強み（次の職場で再現できる粒度）
1. 顧客の小さな兆候を取りに行くヒアリング設計と、CS連携で運用化する組み立て
2. 1on1 を目標設計の場として運用する型と、オンボーディング自走化の設計
上記はClaude Sonnet 4.5で実機検証した出力結果を整形したものだ（架空例ではない・3ファイルの入力をベースに生成）。
このセクションのポイント
- 3層プロンプトで段階的に深く職経が作れる
- 制約条件で「盛らない」「数字は入力値のみ」を明示
- 出力は最終提出前に自分の言葉で1回読み直す
FAQ — 職経 AI 活用でよくある疑問
Q1. AI で書いた職経は本当にバレないのか？
AI で書いたかどうかそのものは、人事担当者が見ても明確に判定できないことが多い。問題視されるのは、AI 出力をそのまま貼った時の「具体性のなさ」「他の応募者との差のなさ」だ。本記事の3ファイル運用で具体性を確保すれば、バレるかどうかは本質的な懸念ではなくなる。
Q2. ChatGPT・Claude・Gemini のどれを使うべきか？
文章整理と長文の構造化なら Claude が向く。画像入りの職経や音声活用は ChatGPT が広い。Google ドキュメントとの連携は Gemini が強い。1つに絞るなら、職経用途では Claude を第一候補にして、必要に応じて他を併用する形が現実的だ。
Q3. 機微情報を AI に入れても大丈夫か？
個人プランの場合、入力データが学習に使われる扱いがあるサービスもある。法人向けプラン（Enterprise/Team）か、設定画面でデータ学習をオプトアウトする選択を取る。会社名・取引先名は仮名運用と二重で守る。
Q4. 職経の長さはどれくらいが適切か？
A4で1〜3枚、文字数で2,000〜5,000字が一般的なレンジだ。1社経験で1,000字、3社で3,000字程度が目安。長ければよいというものではなく、読み手が要点を5分で掴める密度 を優先する。
Q5. 数値化できない職種ではどうするか？
研究・クリエイティブ・バックオフィスでも、何らかの定量指標は引き出せる。論文・特許・実装件数、制作本数・PV、決算所要日数の短縮、監査対応時間など。完全に数値化できない場合は、条件と根拠（誰が・いつ・どの範囲で）を付けて記述する。
Q6. STAR法を毎回書くのは大変だ。簡略化できるか？
職経本文に4要素すべてを詳細に書く必要はない。numbers.md で4要素を整理しておき、本文では Result を中心に書く 運用で十分だ。面接で深掘りされた時に S/T/A の詳細を答えられる準備として STAR法を使う。
Q7. AI スキルを職経にどう書けばいいか？
X×AI 投稿運用 で扱った6ブロック構造プロンプトの応用や、（AI活用5段階）の段階別の書き分けがある。詳細は AI スキルを職経にどう書くか で扱う。
まとめ — 自分の経験を AI に渡してから職経を書く
職経を ChatGPT/Claude で書いてペラくなる原因は、AI の性能ではなく AI に渡している情報が薄いこと。解決は3層構造×3ファイル運用：career.md（職務）/ numbers.md（成果）/ projects.md（学び）。3ファイルを文書化してから AI に読ませると、出力は「他の応募者と差がつく」「自分らしい」内容に変わる。
成果は STAR法（Situation/Task/Action/Result）で構造化し、数値で表現できるものは数字で書く。フォーマットは厚労省・人事院の公的テンプレに合わせる。AI で書いたかバレるかを気にする前に、バレても問題ない密度（自分の経験ベースの具体性）を確保するほうが本質的 だ。
本記事の中核は3つに集約できる。
- 3層構造×3ファイル運用 — 職務/成果/学びを分けて文書化
- STAR法で成果を数値化 — 数値化のパターン5つ＋条件と根拠
- 公的テンプレに合わせて中身を AI で深める — 形式は安全寄り、中身で差をつける
今日の一歩は、career.md の最初の1社分を 30 分で書き出す。会社（仮名）・部署・役職・在籍期間・業務範囲を箇条書きで OK。次の30分で numbers.md に1件の STAR法を書き、第2層プロンプトを試す。
転職活動全体の AI 活用は転職活動 AI 活用 5段階、面接対策の AI 活用は面接対策 AI 活用、AI スキルの職経記載はAI スキルを職経にどう書くか、AI 時代に伸びる/縮む職種の判断はAI 時代の職種判断フレーム で続けて読める。AI 活用の段階的な進め方はAI活用5段階、フォルダ運用思想の元記事はAI×クラウドソーシングで底上げするフォルダ運用・X×AI 投稿運用 で扱っている。
