リポジトリはこちら👇
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が苦手なところを“設計”で取り除く方が、だいぶ勝てました 😄🔥