リポジトリはこちら👇
https://github.com/unagi/jtr-generator

「AIに履歴書・職務経歴書を作らせたら最強では？」と思って始めたんですが、“最強プロンプトを1発入れる”みたいな作りは全く役に立たない、からスタートしました 😇

結論はシンプルで、勝ち筋はここでした👇

LLM：ユーザー体験を生む「対話・整理・不足確認」担当 🗣️🧠
アプリ（scripts/schema）：高速＆高品質＆再現性の「決定的な生成」担当 🧱⚙️✨
references/：検索に頼らず、会話UX（質問設計）を再現する“地図” 🗺️📚

以下、裏話です。

“最強プロンプト”が役に立たない理由 ☠️

LLMに「履歴書PDF作って」と頼むと、だいたいこうなりがちです 🤖💦

遅い：その場でコーディングから始める（毎回ゼロから）🐢
見た目がイマイチ：帳票の完成度が甘い（余白・揃え・文字組み）📄🥲
フォント品質まで気が回らない：日本語PDFの“信頼感”が落ちる 🔤⬇️
ブレる：毎回別実装・別レイアウトになりやすい 🎲

つまり、LLMは「文章」や「整理」は得意でも、
“帳票として美しいPDFを、安定して、速く” は苦手になりやすい。

なので、プロンプトを鍛えるよりも、LLMとアプリの境界を設計する方が勝てました 🧱🧩

解決策：LLMとアプリの境界をハッキリ引く 🧱🧩

jtr-generatorでやったのは、LLMにやらせないことを増やすこと。

ざっくり境界線（図）📐

[User]
  ↓（会話UX）
[LLM / SKILL.md]  …質問順・品質ゲート・禁止事項・推測ルール
  ↓（データ契約）
[schema + scripts] …バリデーション・フォント/レイアウト・PDF生成（決定的）
  ↓
[PDF outputs]

アプリ（scripts/schema）の仕事：高速＆高品質を“事前実装”で固定する ⚙️⚡️✨

1) 「遅い」を潰す：LLMに都度コーディングさせない 🏎️

LLMに任せると毎回コーディングから始める → それが遅さの元。

なので、PDF生成は main() を呼ぶだけに寄せて、生成処理を固定しました。
LLMは「何を聞くか／何が足りないか」だけに集中できる。

速い（毎回ゼロから書かない）
ブレない（同じ入力なら同じ出力に寄せられる）

ここがまずデカいです ⚡️

2) 「見た目イマイチ」を潰す：帳票品質をLLMに任せない 📄🧱

見た目が微妙になりやすい理由はだいたい2つで、

完成度（レイアウトの詰め）
フォント品質（日本語の“それっぽさ”）

ここを「プロンプトで頑張る」のではなく、最初から“高品質な帳票”として実装しておく。

さらに、イケてる日本語フォントを同梱して、PDFの可読性と信頼感を底上げしました 🔤✨
（環境対策というより、LLMに“見た目の完成度”を任せないための設計です）

3) 「再現性」を作る：入力はスキーマで契約する 📐✅

LLMがどう頑張っても、入力が自由すぎると壊れます。

だから入力は JSON Schema準拠を前提にして、
型・必須・日付形式などの“守るべきライン”を決めました。

ここで狙っているのは「厳格さ」ではなく、UXの安定です 😄

SKILL.mdの仕事：プロンプトじゃなく“契約書”として書く 📜🧠

SKILL.mdで意識したのは、それっぽく喋らせるより、迷わせないこと。

1) 指示の優先順位：衝突したらどうする？🚦

仕様・制約を最上位に置いて、ユーザー指示や会話のノリより優先する。
これがあると「雰囲気で破る」が起きにくいです。

2) 品質ゲート：「入力埋めゲーム禁止」🎮🚫

入力欄が埋まっていても、採用判断に必要な情報（役割・期間・規模・技術・成果）が不足していれば生成に進まない。

この“止める勇気”が、実は ユーザー体験を作ります ✨
（雑にPDFが出るより、ちゃんと聞き返してくれた方が価値がある）

3) 推測・補完のルール：捏造を仕組みで防ぐ 🧯

出してない事実・数値を断言しない
推測するなら根拠＋生成前に確認
確認できないなら「要確認」or 空欄

AIに個人情報を扱わせる以上、ここは“仕様で縛る”のが安心です 🔒

references/ の仕事：検索に頼らず、会話UX（質問設計）を再現する 🗺️📚✨

LLMにタスクを渡すと、すぐ「調べに行く」ムーブになりがちです 🤖🔎
でも運用上、検索が使えない/不安定/同時発動できないケースが普通にあります。

そこで jtr-generator では、外部検索に頼る代わりに references/ に“判断基準と質問設計”を同梱しました。

ポイントは「知識を置いた」じゃなくて、
LLMが迷わず“良い聞き方”を再現できる状態を作ったことです 🔥

✅ references/ が解決すること

質問の品質を安定させる（毎回違う聞き方をしない）
採用判断に必要な粒度で聞き出す（役割・期間・規模・技術・成果）
会話の流れ（UX）をテンプレ化して、LLMが“ちゃんと面接官っぽく”なる
検索できない環境でも同じ品質で進められる

“古い職務経歴”を最新化するとき、references が効く例 🧠📄➡️📄

たとえば「数年前時点」のPDFを入力にすると、LLMはこういう「更新のための聞き取り」に入ります 👇
（年や固有名詞は伏せています）

次のステップ：職務経歴書の最新化
アップロードされたPDFは「数年前時点」の内容なので、それ以降の職務経歴を STAR 法で構造化して聞き出します。
スキルのベストプラクティスに従い、採用判断に必要な情報を段階的に確認します。

質問セット1：直近の主要プロジェクト（時系列：新しい順）
<在籍企業>（20XX-XX〜現在）での最新職務について、以下を教えてください：

- 直近の主要プロジェクト 3〜5 件を列挙（新しい順）
  - 例：<プロジェクトA> / <プロジェクトB> / <プロジェクトC>

質問セット2：職務要約の軸（キャリアテーマ）
- 現在のあなたの肩書・部門は何ですか？（<肩書> のままですか、それとも変更されましたか）
- 20XX-XX〜現在の「一貫したテーマ」は何ですか？

質問セット3：STARで深掘り（最大インパクトの案件）
- Situation：当時、会社・部門・チームはどのような状況でしたか？
- Task：あなたが解決すべき課題・目標は何でしたか？
- Action：あなた個人が取った具体的な行動は？（技術・ツール含む）
- Result：成果は？（可能なら数値、難しければ相対比較でもOK）

これって「モデルが賢いから」だけじゃなくて、
best practices（質問の順序・粒度・深掘り軸）を references に置いておいたから再現できた、という設計上の勝ちです 🧱✨

LLMにお願いする“いいところ”：自然文でも拾って、構造に落としてくれる 🧠🗣️➡️📐

このフローの気持ちよさは、ユーザーが STARを厳密に埋めなくても回る点です 😄

ユーザーは自然言語で「当時こんな状況で〜、自分はこうして〜」と話す
LLMがそこから Situation/Task/Action/Result を抽出して整理する
さらに不足があれば「数値ある？」「あなた個人のActionはどこ？」みたいに追撃できる

つまり、入力はゆるくていい（自然文） のに、出力は堅くできる（構造化）。
これが「LLMにお願いする価値」だと思っています 🤖✨

まとめ：AIアプリは「LLMを賢くする」より「境界を賢くする」✨🧱

LLMは“曖昧→構造”変換と対話UXに寄せる 🗣️
正しさ・見た目・再現性はアプリ（schema＋実装）に寄せる 📄⚙️
SKILL.mdは契約書として書く 📜
references/ は会話UXの設計図として同梱する 🗺️

「最強プロンプト」を目指すより、
LLMが苦手なところを“設計”で取り除く方が、だいぶ勝てました 😄🔥

出来上がりサンプル 📎✨

履歴書（PDF）
https://github.com/unagi/jtr-generator/blob/main/skill/assets/examples/sample_rirekisho.pdf
職務経歴書（PDF）
https://github.com/unagi/jtr-generator/blob/main/skill/assets/examples/sample_career_sheet_mincho.pdf