Markdownで職務経歴書を書く

職務経歴書をMarkdownで書く方法GitHub管理とPDF化の手順

WordやExcelの体裁調整に時間を取られるくらいなら、職務経歴書もテキストで管理したい——エンジニアなら一度は考えることです。 この記事では、Markdownで職務経歴書を管理する方法、GitHubに置くときの構成と公開範囲の線引き、 そして最後に必ず詰まる「PDFにする」ところまでを順に解説します。

すでにMarkdownで書いたものがある方は、手持ちのMarkdownを取り込むから読んでください。AIに変換させて、この作成ツールに読み込ませる手順を用意しています。

なぜMarkdownで書きたくなるのか

職務経歴書をMarkdownで管理したくなる理由は、だいたい次の3つに集約されます。

差分
いつ何を書き換えたかが残る
使い回し
応募先ごとに分岐させやすい
体裁ゼロ
レイアウト調整から解放される

とくに効くのが2つめです。職務経歴書は応募先によって強調したい案件が変わりますが、 Wordで管理していると「A社提出版_最新_v3.docx」のようなファイルが増えていきます。 テキストならブランチや別ファイルで分岐させて、共通部分だけ更新するという扱いができます。

ポイント

一方で、Markdownにはページという概念がありません。 A4で何枚になるか、案件の途中でページが割れないかは、変換したあとに初めて分かります。 ここが後半で扱う一番の詰まりどころです。

管理方法の3パターン比較

「Markdownで管理する」と一口に言っても、実際には3つのやり方があります。

管理方法手間PDF化向いている人
Markdown+変換ツールCSSを自分で書く体裁も自分で作り込みたい人
GitHubリポジトリで管理別途変換が必要差分を残したい人
作成ツールで入力そのまま出力体裁に時間をかけたくない人
※ どれが正解ということはなく、「体裁にどれだけ時間をかけたいか」で決まります。 3つを併用して、管理はMarkdown・提出はPDFと分ける形もよく使われます。

手間の欄は、1回目に整えるまでの手間を指しています。 2回目以降の更新はどれも軽いので、最初にどこまで自分で作り込むかの判断になります。

GitHubで管理する構成と手順

リポジトリを1つ作って、次のような構成にしておくと更新が楽になります。 案件ごとにファイルを分けるのは、応募先に合わせて出し入れしやすくするためです。

リポジトリ構成の例
career/
├── README.md          # 目次。ここから各ファイルへリンクする
├── resume.md          # 職務経歴書の本体
├── skills.md          # スキル一覧(更新頻度が高いので分ける)
├── projects/
│   ├── 2023-ec-renewal.md
│   └── 2021-inventory.md
└── private/           # .gitignore に入れて公開しない
    └── contact.md     # 氏名・住所・電話・メール

更新の運用

転職活動を始めてから書き始めると、3年前の案件の詳細を思い出せません。案件が終わったタイミングで数行だけ足す運用にしておくと、 いざというときに棚卸しが要らなくなります。コミットメッセージに日付が残るので、 「この案件はいつ終わったか」も後から辿れます。

公開リポジトリに置いてよい情報

ここは慎重に判断してください。職務経歴書には、公開リポジトリに置くべきでない情報がいくつも含まれます。

  • 氏名・住所・電話番号・生年月日・顔写真
  • 勤務先の非公開情報(未発表のプロジェクト名、社内の体制や数値)
  • 顧客企業名(守秘義務の対象になっていることが多い)

連絡先や個人情報は private/ のようなディレクトリに分けて.gitignore に入れ、公開するのは技術的な内容だけにするのが安全です。 案件の書き方は職務経歴書の書き方ガイドで詳しく扱っています。

ポイント

そもそも公開する必要があるかを先に考えてください。 リポジトリ自体を成果物として見せたい(構成や自動化が凝っている)場合を除けば、 非公開リポジトリでバージョン管理し、提出はPDFで行うほうがリスクがありません。

MarkdownをPDFにする4つの方法

Markdownで書いたあと、ほぼ全員がここで止まります。主な選択肢は4つです。

1. エディタの拡張機能で出力する

VS Codeの拡張などで、開いているMarkdownをそのままPDFにできます。最も手軽ですが、 余白・フォント・改ページは拡張機能の既定に従うため、A4に収める調整は効きにくいです。

2. pandoc で変換する

コマンド1つで変換でき、CI に組み込めるのが利点です。ただし日本語フォントの指定を自分で行う必要があり、 指定を忘れると日本語が空白や豆腐になって出力されるのが定番のつまずきです。

3. CSS組版でレイアウトまで作り込む

MarkdownをHTMLにして、印刷用CSSで体裁を作る方法です。自由度は最も高い一方、 A4の余白、ページ番号、表がページをまたぐときの制御まで自分で書くことになります。 職務経歴書1枚のためにやるには重い作業です。

4. ブラウザの印刷でPDF化する

HTMLにしてブラウザから印刷する方法です。手軽ですが、ヘッダー・フッターの除去や 背景色の印刷設定など、環境ごとの調整が必要になります。

ポイント

4つに共通する弱点が改ページの制御です。 案件の途中でページが割れる、表が分断される、といった崩れはpage-break-inside などを自分で当てて潰すことになります。 職務経歴書を書くたびにここを調整するのは、本来かけたい時間の使い方ではありません。

手持ちのMarkdownを取り込む

この作成ツールは、入力した内容をPDFとMarkdownの両方で出力できます。 改ページはA4を前提に計算しているので、前の章で挙げた調整は不要です。

ただしMarkdownを直接読み込む機能はありません。 すでにMarkdownで書いたものがある場合は、AIにJSONへ変換してもらい、「バックアップから復元」で読み込むという手順を取ってください。 このツールのバックアップ形式はJSONなので、形さえ合っていれば読み込めます。

手順

  1. 下の「AIへの指示文」をコピーして、ChatGPTなどに貼り付ける
  2. 続けて「JSONの形」と、自分のMarkdownを貼り付ける
  3. 出力されたJSONを resume.json という名前で保存する
  4. 画面右上の「バックアップから復元」から、そのファイルを選ぶ
AIへの指示文
添付した(貼り付けた)Markdownの職務経歴書を、下記のJSON形式に変換してください。

# 変換ルール
- 出力はJSONのみ。説明文やコードブロックの記号(```)は付けない
- 元の文章表現はできるだけ変えない。要約や creative な言い換えはしない
- 元データに無い項目は空文字 "" または空配列 [] にする。情報を創作しない
- level は 1〜4 の整数(1=学習経験 / 2=指導下で実装可 / 3=独力で実装可 / 4=設計・指導可)
- 日付は periodFrom / periodTo / acquiredDate が "YYYY-MM"、birthDate と asOfDate は "YYYY-MM-DD"
- 継続中の案件は periodTo を "" にする
- phases は「要件定義」「基本設計」「詳細設計」「実装」「テスト」「運用保守」から該当するものだけ
- templateId は "sier-standard" のままでよい

# JSON形式
(ここに下の「JSONの形」をそのまま貼り付ける)

# 変換元のMarkdown
(ここに自分の職務経歴書のMarkdownを貼り付ける)
JSONの形
{
  "templateId": "sier-standard",
  "asOfDate": "2026-09-04",
  "basic": {
    "name": "山田 太郎",
    "nameKana": "やまだ たろう",
    "birthDate": "1997-04-15",
    "location": "東京都渋谷区",
    "nearestStation": "JR山手線 渋谷駅",
    "email": "[email protected]",
    "github": "github.com/yourname",
    "finalEducation": "2019年3月 ○○大学 工学部 卒業",
    "roleTagline": "Frontend Engineer"
  },
  "summary": "職務要約をここに1〜3文で。",
  "skills": [
    {
      "category": "言語",
      "items": [{ "name": "TypeScript", "years": "6年", "level": 4 }]
    }
  ],
  "projects": [
    {
      "title": "大手アパレルECサイト リニューアル",
      "periodFrom": "2023-04",
      "periodTo": "2025-12",
      "industry": "アパレル / EC",
      "role": "フロントエンドリード",
      "teamSize": "全体22名",
      "composition": "PM1 / FE5 / BE8",
      "overview": "案件の概要を2〜3文で。",
      "responsibilities": ["担当した内容を1行ずつ"],
      "achievements": ["数字で示せる成果を1行ずつ"],
      "techStack": {
        "language": "TypeScript",
        "framework": "Next.js 14, React 18",
        "db": "PostgreSQL",
        "infra": "AWS (ECS, RDS)",
        "tool": "GitHub Actions, Datadog"
      },
      "phases": ["要件定義", "基本設計", "詳細設計", "実装", "テスト", "運用保守"]
    }
  ],
  "qualifications": [
    { "name": "応用情報技術者試験", "acquiredDate": "2020-04" }
  ],
  "selfPR": "自己PRをここに。"
}

項目が一部欠けていても空欄として読み込まれ、id は自動で採番されます。 読み込んだあとは入力画面で内容を確認して、10種類のテンプレートから体裁を選べます。

ポイント

AIに変換させたあとは必ず中身を確認してください。 生成AIは空欄を埋めようとして、書いていない実績や数字を作ることがあります。 指示文には「情報を創作しない」と入れてありますが、最終確認は自分で行ってください。

よくある質問

Q.Markdownのまま提出してもいいですか?

応募先がGitHubのURLで受け付けると明記している場合を除き、PDFで提出するのが無難です。多くの企業は応募書類を採用管理システムに取り込むため、PDFかWordを前提にしています。Markdownは「自分が管理するための形式」、PDFは「提出する形式」と割り切って、両方を出せる状態にしておくのが現実的です。

Q.職務経歴書をGitHubで公開すると採用で有利になりますか?

有利になるとは限りません。公開して効果があるのは、リポジトリ自体が成果物として見せられる場合(構成や自動化が凝っている、READMEが読みやすいなど)です。中身が普通の職務経歴書であれば、公開しても評価は変わらず、個人情報を晒すリスクだけが残ります。非公開リポジトリでバージョン管理し、提出はPDFで行う形が安全です。

Q.MarkdownをPDFにすると改ページがおかしくなります

Markdownには改ページの概念がないため、変換ツール側のCSSで制御することになります。案件の途中でページが割れる、表が分断されるといった問題は、`page-break-inside: avoid` などを自分で当てて調整する必要があります。ここを毎回調整するのが面倒な場合は、A4の改ページを前提に組まれたツールで出力するほうが早いです。

Q.AIに書かせたJSONが読み込めません

先頭が { で始まるオブジェクトになっているか、コードブロックの ``` が混ざっていないかを確認してください。項目が一部欠けていても空欄として読み込まれます。skills や projects が配列になっていない場合は初期値に置き換わるので、変換をやり直してください。

Markdownでも、PDFでも出せます

ステップに沿って入力すれば、A4の改ページを整えたPDFと、 そのまま管理に使えるMarkdownの両方を書き出せます。 登録不要・無料で、入力内容はブラウザ内にのみ保存されます。

おすすめ記事

記事の一覧へ →