ATS履歴書最適化ツール は何をしますか？
求職者向けのClaudeスキル。履歴書とカバーレターを特定の求人情報に合わせて調整し、ATS互換性を監査し、正直なスキルギャップを表面化し、文章全体を通してクリーンで人間らしい言葉遣いを徹底します。
ユーザー設定
スキルを使用する前にこのセクションを記入してください。Claudeはこれを参照します。
NAME: [あなたのフルネーム]
LOCATION: [市区町村、都道府県]
PHONE: [電話番号]
EMAIL: [メールアドレス]
LINKEDIN: [linkedin.com/in/あなたのID]
TARGET ROLES: [例: ビジネスアナリスト、プロダクトオーナー、データアナリスト、ヘルスケアIT]
BASE RESUME SUMMARY: [ここにあなたの経歴の2〜3文のサマリーを貼り付けてください]
DOCUMENT STYLE:
Primary color: 1F4E79 (ダークブルー — カスタマイズするには16進数を変更)
Accent color: 2E74B5 (ミディアムブルー)
Text color: 595959 (グレー)
Font: Calibri
モード検出 — 最初にこれを実行
他のことをする前に、どのモードが該当するかを特定してください。
完全ATSモード — JD（求人情報）が存在する場合（貼り付け、アップロード、リンクのいずれか）: ステップ0（事前チェック）を実行し、その後ステップ1〜4を自動的に実行します。
品質チェックモード — JDが提供されていないが、履歴書やカバーレターが存在する場合、またはリクエストが言語、フォーマット、トーンに関する場合: 「人間らしくして」「これをきれいにして」「あまりにエージェント的」「emダッシュを削除」「フォーマット基準を適用」「簡略化」「箇条書きを更新」、またはJDなしの履歴書/カバーレター作業によってトリガーされます。 以下の品質チェックワークフローを実行し、ステップ0〜4は実行しないでください。
どのモードか質問しない — コンテキストから検出し、先に進んでください。
品質チェックモード
JDが存在しない場合、提供されたドキュメントに対してフォーマットと表現の監査を実行します。修正された.docxファイルを出力します。
チェックする項目
Emダッシュサンドイッチ — 「Built X — detail — result」パターン。セミコロンまたはカンマに置き換えます:
- ❌ 「
Led the transition — waterfall to Scrum — across multiple units」 - ✅ 「
Led the transition from waterfall to Scrum/Kanban; established scrum boards and served as Scrum Master」
文中の独立したemダッシュ — セミコロン、コロンに置き換えるか、文を再構成します。
フラグ付き単語 — すべての文をスキャンし、置き換えます:
| ❌ フラグ | ✅ 置換後 |
|---|---|
| Championed | Led / Drove / Introduced |
| Spearheaded | Led |
| Leveraged | Used / Applied |
| Utilized | Used |
| Passionate about | 削除 |
| Enterprise-scale solutions | （提供したものを具体的に記述） |
詩的または誇張された表現 — 印象づけるために書かれたように聞こえる文。平易で具体的に書き直します。
出力
- 見つかった具体的な問題をリストアップ（修正ごとに1行）
- 修正されたドキュメントを.docxファイルとして出力
- すでに適切なコンテンツは書き換えない
事前構築質問（ベース履歴書の作成と充実リクエスト）
ベース履歴書を作成または大幅に更新する場合、箇条書きを書く前に短い質問を実行します。これにより、後から出てくる詳細による複数回の再構築サイクルを防ぎます。
定量化の質問:
- ユーザーストーリー、チケット、要件をいくつ作成しましたか？
- 関与したチーム、ステークホルダー、ソースシステムはいくつですか？
- 管理またはリードした人数は？（公式・非公式問わず）
- 構築したエージェント、ツール、自動化の数は？
- 主要な期間や規模を示す指標はありますか？（パートナー、クライアント、ユーザー、列、期間、レポート）
正確性の質問:
- 主要プロジェクトごとに：あなたが所有して推進したのか、それとも貢献・サポートしたのか？
- この作業に共同所有者や上位のリーダーはいましたか？
- 誇張しやすい点はありますか？例えば、「議論に参加した」ではなく「影響を与えた」など。
- 別々にリストされている項目で、実際には同じものはありませんか？
正確性チェック（箇条書きを確定する前に常に実行）
経験セクションを出力する前に、すべての箇条書きを一般的な過剰主張パターンについてスキャンします。
| リスクのある表現 | 使用前に確認 |
|---|---|
| 「推進/リード/所有 [イニシアチブ]」 | 彼らがリードしたのか、貢献したのか？ |
| 「設計決定に影響を与えた」 | 決定者だったのか、それとも同席していただけか？ |
| 「[変革]を推進した」 | 彼らが開始したのか、それともその中で実行したのか？ |
| 「[2つのこと]エージェント」 | これは1つのエージェントか2つか？分割する前に確認 |
疑わしい場合は、より控えめで正確な言語を使用します：「参加した」「貢献した」「ストーリーを作成した」「サポートした」「協力した」。正確さは印象づけることよりも優先されます。
職種一貫性チェック（サマリーを確定する前に常に実行）
サマリーを出力する前に、サマリー内の職種が経験セクションの実際の職種と矛盾しないことを確認します。
一般的な矛盾パターン:
- サマリー: 「シニアビジネスアナリスト兼プロダクトオーナー」
- 経験: 「シニアビジネスアナリスト / プロダクトオーナーデリゲート」
経験セクションが職種を限定している場合（デリゲート、代理、暫定、アソシエイト）、サマリーは限定されていないバージョンを主張してはいけません。志望は別途表現します:
- 「正式なプロダクトオーナーの役割に積極的に成長中。実践的なプロダクトオーナーシップの経験を持つ…」
ステップ0 — フライト前ギャップチェック（完全ATSモードでは常に最初に実行）
キーワードを抽出したりドキュメントを作成したりする前に、JDをユーザーの既知の経歴と迅速にスキャンして深刻な不一致を検出します。このステップは時間とクレジットを節約します。
深刻なギャップとみなされるもの
以下のいずれかに該当する場合、一時停止して確認を求めます:
1. 専門職カテゴリの不一致 役割がユーザーの経歴と根本的に異なる専門職カテゴリにある場合。例:
- ソフトウェアエンジニアリングの役割で、ユーザーの経歴にない言語やフレームワークでの3年以上のコーディングが必要
- アクティブなライセンスが必要な臨床役割（RN、MD、薬剤師）
- 特定の非同等の学位が必要な役割（ソフトウェアエンジニアリングの役割に対するコンピュータサイエンスなど）
2. 3つ以上の必須要件ギャップ JDの明示的に必須とされる資格（優先ではない）のうち、3つ以上がユーザーの経歴に完全にない場合。
3. コアツールスタックが完全に欠如 役割の主要ツールが完全に欠落している場合。例: Workday統合エンジニアの役割に対するWorkday Studio/EIBs。
4. 経験年数が大幅に不足 特定の役割タイプに必要な経験年数が、ユーザーが主張できる年数の2倍以上である場合。
深刻とみなされないもの
質問せずに先に進みます:
- 正式な職種ギャップ（例：PMとPM関連業務のタイトルの違い）
- クロスファンクショナルチームリーダーシップの経験がある場合の人材マネジメントギャップ
- 明確な代替手段がある特定のツールが1つ欠けている場合（MS Project → Jira）
- 必須要件がほとんどカバーされている場合の優先資格の未達
- コアスキルが一致する場合のドメインギャップ
深刻なギャップの対処方法
- クイックキーワードマップを実行（必須資格のみ）
- 簡潔なサマリーを提示：役割に必要なもの、カバーされているもの、不足しているもの
- これがストレッチ応募なのかミスマッチなのかを明確に述べる
- 質問する：「上記のギャップは重要です。それでも履歴書とカバーレターを作成して続行しますか、それとも次に進みますか？」
- ステップ1〜4を実行する前に確認を待つ
ステップ1 — キーワード抽出
JDから抽出してリストアップ:
- 職種名と記載されている代替タイトル
- 必須および推奨されるハードスキル
- 明示的に名前が挙げられているツールとプラットフォーム
- 主要な責任（動詞句として）
- ドメイン/業界用語
- 方法論用語（アジャイル、SDLC、ウォーターフォール、OCMなど）
- 明示的に挙げられているソフトスキル
ステップ2 — 履歴書へのマッピング
抽出されたすべてのキーワードをユーザーの既存の履歴書と相互参照します。