英文レジュメは何ページが適切ですか？

経験10年未満なら1ページ、10年以上でも2ページが目安です。応募先の国の慣習にも合わせてください。

英文レジュメに顔写真は必要ですか？

米国・英国などでは不要です。差別防止の観点から記載しないのが一般的ですが、国によって慣習が異なります。

日本語の職務経歴書をそのまま翻訳してもよいですか？

そのままの翻訳は避けるべきです。英文レジュメは成果ベースの記載が求められるため、フォーマットと内容を書き換える必要があります。

ATSとは何ですか？

Applicant Tracking Systemの略で、多くの海外企業が使う自動選考システムです。キーワードマッチでスクリーニングされるため、求人のJob Descriptionに合わせた記載が重要です。

エンジニアの英文レジュメにGitHubは記載すべきですか？

記載を推奨します。コードの質や活動量を示す補足資料として、採用担当者に技術力をアピールできます。

海外転職の英文レジュメ書き方ガイド｜エンジニア向け構成・NG例・差がつく5つのポイント

Work Horizon編集部

2026/4/24 公開

海外転職に必要な英文レジュメとは

英文レジュメ（Resume）は、海外転職で最初に提出する書類であり、選考の通過率を左右する重要な武器です。日本の履歴書＋職務経歴書に相当する内容をA4で1〜2ページにまとめるのが標準的なフォーマットです。

日本の履歴書との主な違いは以下の通りです。

項目	日本の履歴書	英文レジュメ
顔写真	必須	不要（米国・英国等。国により異なる）
年齢・生年月日	記載	不要（差別防止の観点）
フォーマット	JIS規格等の定型	自由形式（1〜2ページ）
職歴の記載順	古い順	新しい順（逆編年体）
記載内容	業務内容の説明	成果・数値を重視

なお、国や地域によってレジュメの慣習は異なります。応募先の国の標準フォーマットを事前に確認することが重要です。

エンジニア向け英文レジュメの基本構成

エンジニアの英文レジュメは、以下の構成が標準的です。

1. Contact Information（連絡先）

氏名、メールアドレス、電話番号、所在地（都市名のみで可）を記載します。エンジニアの場合はLinkedInプロフィールとGitHubアカウントのURLも記載すると、技術力を補足的にアピールできます。

2. Summary / Objective（経歴要約）

2〜3行で自分のキャリアの概要と強みを要約します。「X年のバックエンド開発経験を持つソフトウェアエンジニア」のように、職種・経験年数・得意分野を端的に伝えます。

3. Work Experience（職務経歴）

最も重要なセクションです。直近の職歴から逆順に記載し、各職歴には以下を含めます。

会社名・役職・在籍期間
担当プロジェクトの概要
成果を数値で示すバレットポイント（例：「例えばAPIレスポンスタイムを改善しユーザー体験を向上」のように具体的に）

4. Skills（技術スキル）

プログラミング言語、フレームワーク、クラウドサービス、ツールなどをカテゴリ別に列挙します。応募する求人のJob Descriptionに記載されているキーワードを意識して、マッチするスキルを優先的に記載しましょう。

5. Education（学歴）

大学名・学位・卒業年を記載します。海外ではCS（コンピューターサイエンス）の学位が重視される傾向がありますが、関連する資格や独学の実績でカバーすることも可能です。

エンジニアの英文レジュメで差がつく5つのポイント

ポイント1：成果を数値で示す

海外の採用担当者は「何をしたか」より「どんな成果を出したか」を重視します。「開発した」ではなく「例えば〇〇を導入しX%改善」のように、可能な範囲で具体的な成果を数値で示しましょう。

ポイント2：Action Verbで書き始める

各バレットポイントは「Developed」「Implemented」「Optimized」「Led」「Reduced」などの動詞で書き始めるのが英文レジュメの鉄則です。受動態ではなく能動態で、自分が主体的に行ったことを明示します。

ポイント3：ATS（自動選考システム）を意識する

多くの海外企業はATS（Applicant Tracking System）で一次スクリーニングを行います。Job Descriptionに含まれるキーワード（技術名・ツール名）をレジュメに自然に盛り込むことで、ATSを通過しやすくなります。

ポイント4：GitHubやポートフォリオで補足する

レジュメの紙面は限られているため、GitHubリポジトリや個人プロジェクトのURLを記載して、コードの質や活動量を示しましょう。特にオープンソースへのコントリビューション実績は高く評価される傾向があります。

ポイント5：国ごとの慣習に合わせる

レジュメのフォーマットは国によって異なります。米国ではA4で1ページが好まれる一方、ドイツやオーストラリアでは2ページが一般的です。応募先の国の慣習を事前に調査しましょう。各国の労働法制や応募手続きは日本と異なるため、現地の転職エージェントや公的機関のガイドラインも参考にしてください。

エンジニアが英文レジュメで避けるべきNG例

日本語の職務経歴書をそのまま翻訳する：日本語の「〇〇業務に従事」という表現は英語では冗長です。成果ベースの記載に書き換えましょう
スキルを羅列するだけ：「Java, Python, Go」と書くだけでなく、各スキルをどのプロジェクトでどう使ったかをWork Experienceで示しましょう
長すぎるレジュメ：経験10年未満なら1ページ、10年以上でも2ページが目安です。不要な情報は削りましょう
個人情報の記載：米国向けでは年齢・性別・婚姻状況・顔写真は記載しないのがマナーです（差別防止の観点から法律で制限される国もあります）

人材エージェント事業の現場では、英文レジュメの添削を依頼される機会が多くあります。日本人エンジニアに共通する課題は「成果の数値化が弱い」ことです。日本の職場では「チームで達成した」と控えめに書く傾向がありますが、海外では自分の貢献を明確に主張することが求められます。まずは直近のプロジェクトで自分が出した成果を3つ書き出し、それぞれに数値を添えるところから始めてみてください。

出典について

本記事の情報は各種転職サービス・キャリアガイドを参考にしていますが、各国の雇用慣習・法規制は日本と異なります。応募先の国の最新ルールは、現地の公的機関や転職エージェントにご確認ください。レジュメのフォーマットや記載事項の慣習は国・企業によって異なるため、本記事は一般的な傾向の紹介にとどめています。

主な参考（最終確認: 2026年4月）： InterviewCat 英語レジュメの書き方、 Tech Interview Handbook レジュメガイド、 Resume.io International CV Format、 doda 英文履歴書の書き方

2026年のAI時代の英文レジュメ——ATS対応・AI活用・職種別テンプレート・Action Verb設計

本記事冒頭で触れた英文レジュメの構成・NG例・5つのポイントを踏まえ、本章ではATS（採用管理システム）対応・ChatGPT/Claude等のAI活用・職種別テンプレート（Software Engineer/ML Engineer/Data Scientist/SRE/PM）・Action Verbと定量化・GitHub/LinkedIn連動・Cover Letter書き方・Career Gap説明・Remote jobs応募まで整理します。参照する一次ソース・信頼できる業界解説はInterviewCat「英語レジュメの書き方」、CVCraft「Software Engineer Resume Example 2026」、Professional Resume Free「Software Engineer Resume Writing Guide 2026」、BeamJobs「34 Software Engineer Resume Examples & Guide for 2026」、Enhancv「Software Engineer Resume: 35+ Examples & Guide [2026]」、MentorCruise「Software Engineer Resume Template ATS-Optimized」、Enhancv「20 ATS Resume Examples & Guide for 2026」、Resume Worded「18 Software Engineer Resume Examples for 2026」、NxCode「Claude vs ChatGPT 2026」などです。

ATS対応の基本——2026年も変わらない原則

ATS（Applicant Tracking System）は、採用企業がレジュメを自動でパースし、キーワード・職歴・学歴を抽出する仕組みです。Enhancv「20 ATS Resume Examples」やMentorCruise「ATS-Optimized」が整理するとおり、ATS対応で押さえるべき論点は次のとおりです。

シングルカラム・標準フォント：複雑な2カラム・装飾フォント・グラフィック・テーブルは ATS パースエラーの原因
標準セクション見出し：Experience / Education / Skills / Projects / Publications等の定番見出しを使う
逆時系列（Reverse Chronological）フォーマット：最新の経験を上に配置する基本形
キーワード整合：応募先の求人票（Job Description）に登場する技術・ツール・スキルを自分の経験に正確に反映
Word/PDF両形式に対応：ATSによってパース精度が異なるため、両形式の用意が安全
ヘッダー・フッターに重要情報を置かない：一部ATSはヘッダー・フッターをパース対象外にする

「見た目のデザインを凝って差別化する」という発想は、実はATS通過率を下げる論点として議論されます。ATSを通過して人間のレビュアーに渡るまでが最初の関門です。

3つのレジュメ形式の使い分け

クロノロジカル（Chronological）：最新の経験から逆時系列で列挙。正社員キャリアが連続している人の基本形
ファンクショナル（Functional）：スキル別にまとめる形式。キャリアチェンジ・ブランクがある場合
コンビネーション（Combination）：スキルセクション＋時系列の組合せ。シニア・多様なプロジェクト経験者向け

ソフトウェアエンジニアの求人応募では、クロノロジカルが業界標準として広く採用されています。ファンクショナルはATSとの相性が悪い論点があり、選ぶ場合は慎重な設計が必要です。

ChatGPT・Claudeを活用した英文レジュメ作成

2026年時点でChatGPT・Claude等のAIツールは、英文レジュメ作成の強力なアシスタントとして普及しています。ゼロからアメリカ「ChatGPT×レジュメ最強説」などが整理する活用パターンを深掘りします。

活用パターン1：日本語職務経歴書→英文レジュメ変換

日本語の職務経歴書をコピペし、英文に変換してもらう
直訳ではなく英文レジュメのフォーマット・表現に置換するプロンプト設計
Action Verb中心の表現への変換
変換後、事実確認と固有名詞の正確性を手動でチェック

活用パターン2：Action Verb提案

日本語で書いた業務内容を貼り付け、強いAction Verbを提案してもらう
「managed」「helped」「responsible for」等の弱い表現を「led」「architected」「spearheaded」等の強い表現に置換
複数の候補から選んで、自分の実際の役割に最も合うものを採用

活用パターン3：Quantifiable Impacts化

「パフォーマンスを改善した」→「Reduced API latency by X% and served Y million requests per day」といった定量化
数値を持っていない場合は「持っている数値を棚卸しする」プロンプト
ただし事実と乖離した数値は絶対に入れないことが大原則

活用パターン4：Job Description適合度チェック

求人票（Job Description）と自分のレジュメをAIに貼り付けて、キーワード適合度を評価してもらう
不足しているキーワードの提示、補強方法の提案
応募先ごとにレジュメを微調整するカスタマイズ

活用パターン5：Cover Letter生成

レジュメ＋求人票をベースに、企業への応募動機・志望理由を生成
自分の言葉で調整して人間味を出す後工程
定型句の多い構造なので、AI生成が特に有効な論点

ChatGPT vs Claudeの使い分け

NxCode「Claude vs ChatGPT 2026」の整理では、用途別の使い分けが論点として挙がります。

ChatGPT：スピーディなドラフト生成、Action Verb提案、短文の磨き上げ
Claude：長文・深みのある文章、技術的な説明、Cover Letterの充実
両方を組み合わせ、最終的に自分の声で編集する三段階プロセスが効率的な論点

AI活用の注意点

事実と乖離した経歴・スキルは絶対に記載しない
個人情報・機密情報をAIに貼り付ける際のプライバシー考慮
AIらしい冗長な表現を人間の言葉に磨き直す
応募先企業の文化（Formal/Casual）に合わせた調整
最終的な責任はレジュメ作成者にあり、AIは道具として位置づける論点

職種別テンプレート深掘り

Software Engineer（SE）

Summary：X years of experience in full-stack/backend/frontend development with expertise in [Languages] and [Frameworks]
Experience：Architected / Developed / Optimized / Shipped / Scaled の動詞を中心に
Skills：Languages (Python, Go, TypeScript等), Frameworks (React, Django等), Cloud (AWS, GCP), Tools (Docker, Kubernetes, Git), Databases (PostgreSQL, Redis, etc.)
Projects：GitHubリンク付きの個人プロジェクト
Education：大学・大学院、CS関連

Machine Learning / AI Engineer

Summary：ML/AI engineerとしての専門領域（NLP/CV/Reinforcement Learning/LLMs等）
Experience：Trained / Fine-tuned / Deployed / Productionized の動詞
Skills：Python, PyTorch/TensorFlow, Hugging Face, MLflow, LangChain, Vector DB
Research：論文発表・カンファレンス登壇があれば専用セクション
Kaggle/Competition：入賞実績があればハイライト

Data Scientist

Summary：Statistical analysis, Predictive modeling, A/B testing experience
Experience：Analyzed / Modeled / Identified / Delivered insights の動詞
Skills：Python, R, SQL, Tableau, dbt, Airflow
Impact：Business impactを定量化（revenue increase, cost reduction, etc.）

SRE / DevOps Engineer

Summary：Reliability, Scalability, Automation focus
Experience：Reduced incidents by X%, Achieved X nines uptime, Automated X deployments
Skills：Kubernetes, Terraform, Observability (Prometheus, Grafana, Datadog), CI/CD (GitHub Actions, CircleCI)

Product Manager / Engineering Manager

Summary：Led cross-functional teams of X engineers / PM'd product with Y users
Experience：Managed / Directed / Launched / Grew の動詞
Skills：Roadmapping, Stakeholder management, Metrics (OKRs, KPIs)
Impact：Revenue, user growth, engagement metrics

Action Verbの選択と定量化——「何をどう成したか」を明確に

強いAction Verbの例

Leadership系：Led / Directed / Spearheaded / Mentored / Managed
Technical系：Architected / Designed / Implemented / Deployed / Optimized / Refactored
Impact系：Delivered / Shipped / Launched / Scaled / Transformed
Analysis系：Analyzed / Evaluated / Investigated / Identified / Resolved
Collaboration系：Collaborated / Facilitated / Partnered / Coordinated

弱い表現から強い表現への置換例

「Was responsible for」→「Led / Managed」
「Helped with」→「Collaborated on / Contributed to」
「Worked on」→「Developed / Designed / Built」
「Did」→「Executed / Delivered / Implemented」
「Made」→「Created / Produced / Built」

定量化の5パターン

性能改善：Reduced latency / Improved throughput / Increased conversion rate
規模：Served users / Processed requests / Managed team size
コスト：Reduced cloud costs / Saved engineering hours / Cut infrastructure spend
品質：Decreased incidents / Improved test coverage / Achieved SLA
ビジネス：Contributed to revenue / Increased retention / Launched product

定量化の注意点

実際に自分が関与した成果のみを記載
チームの成果を自分単独の成果と混同しない
数値が不明な場合は「by approximately X%」や「over Y months」と幅・期間を明示
機密情報（具体的な売上額・顧客名等）は一般化した表現に

GitHub・LinkedIn・Portfolio の連動

GitHub

Software engineer求人では、GitHubリンクはほぼ必須という論点が広く議論されます。整備のポイントを整理します。

Pinned Repositories：応募する職種に最も関連する6つ程度をPinに設定
README.md：各リポジトリに、Problem / Data / Method / Resultsを明記
コントリビューショングラフ：継続的な活動履歴を示す
オープンソース貢献：issue/PRのやり取りが見える
プライベートリポジトリはContributionに計上：業務経験の証跡
プロフィールREADME：自己紹介・技術スタック・連絡先

レジュメと整合した職歴・スキル（ただし冗長に記載可）
プロフィール写真（プロフェッショナル）
Headline（検索結果に表示される一文）
Skills セクション（上位スキルを上に配置）
Recommendations（過去の上司・同僚から）
Activity（投稿・記事・コメントで継続的な発信）

個人Portfolio / 技術ブログ

個人サイト・技術ブログの有無が評価されるケース
コードではなく、技術的思考・デザイン判断・学びを言語化できる論点
Claude Code・Cursor等のAIコーディングで個人プロジェクトを短時間で構築する設計も可能

Cover Letter書き方

Cover Letter（志望動機書）は職務経歴書と併せて提出する書類で、企業・職種への具体的な志望理由を伝える役割です。構成を整理します。

基本構成

Header：宛名・日付・採用担当者名（分かれば）
Opening Paragraph：応募するポジション名、簡潔な自己紹介
Body Paragraph 1：自分のスキル・経験がポジションにどうマッチするか（2〜3の具体例）
Body Paragraph 2：その企業をなぜ選ぶか（プロダクト・ミッション・文化への共感）
Closing Paragraph：面接機会を求める一言、連絡先、感謝

Cover Letterの論点

定型文（テンプレ丸出し）は避け、企業ごとにカスタマイズ
レジュメの繰り返しではなく、レジュメに書けない「なぜこの企業か」を伝える
1ページ以内・3段落〜5段落
企業によっては不要な場合もあり、応募ページの指示を確認

Career Gap・転職理由の説明

英文レジュメで扱いに悩みやすいのが、キャリアのブランク・短期職歴・転職理由です。論点を整理します。

Career Gap（休職期間）

学習・留学期間：「Self-study / Certifications / Online courses」等で期間を意味のあるものとして記載
家族都合：「Took time for family care」といったシンプルな表記
健康回復：詳細を書く必要はない。面接で聞かれた場合の短い説明を準備
フリーランス期間：「Independent Consultant / Freelance Engineer」として独立した職歴

短期職歴の扱い

1年未満の職歴は隠さない（整合性は後でチェックされる）
理由を短く添える：「Role elimination due to company restructuring」「Project-based contract ended」等
短期職歴が複数ある場合、全体のトレンドを説明できる構成

転職理由の表現

成長機会：「Seeking a role with greater scope / ownership / technical challenge」
領域転換：「Transitioning from X to Y to leverage my background in Z」
グローバル志向：「Aiming to contribute in an international environment」
ネガティブ表現を避ける：前職・前上司の批判は絶対に書かない

Remote Jobs応募の実務

2026年時点のエンジニア求人では、リモート求人も相当数流通しています。応募時の論点を整理します。

Time Zone配慮：「Open to overlap with PST / EST / CET」など、稼働時間帯の柔軟性を明示
Remote Work経験：過去のリモート勤務年数・ツール（Slack / Zoom / Linear / Notion等）
Self-management能力：「Self-directed delivery of X projects remotely」といった表現
Async Communication：非同期コミュニケーションのスキル（ドキュメント化・記録的コミュニケーション）
Home Office Setup：安定したネット環境・作業スペースを持っているシグナル

英文レジュメの最終チェックリスト

1ページ（経験10年未満）／2ページ（10年以上）に収まっているか
ATS通過できる単カラム・標準フォント・標準セクション見出し
Action Verbが各bullet pointの冒頭にある
可能な限り数値・期間・規模で定量化
応募先求人票のキーワードと整合している
GitHubリンク・LinkedInリンクが正確に貼られている
固有名詞（会社名・プロジェクト名・技術名）の綴り・大文字小文字が正確
誤字脱字・文法エラーがない（AI・Grammarly・同僚レビューで確認）
連絡先（メール・電話・LinkedIn）が明記されている
PDF形式で文字化けなく保存できている

独自視点：情報設計としての英文レジュメ

筆者が所属するrenueはAI活用のコンサルティングを営んでおり、業務を通じて個人の意思決定プロセスを情報設計の観点から考える機会があります。英文レジュメの論点として、「ATS通過＋採用担当者の興味喚起＋面接につなげる」という3段階の読み手を意識した設計が挙がります。

具体的には、第1段階（ATS）は機械が読むのでキーワード・構造の整合、第2段階（採用担当者の初期スクリーニング）は数秒〜数十秒で判断されるので冒頭のSummary・最新職歴の強いAction Verbとインパクトの定量化、第3段階（面接）ではレジュメの記述が「深掘り可能な種」として機能するように、1行1行に掘り下げ材料を仕込む、という層別の設計が論点として整理できます。

もう一つの論点は、AI活用は下書きの時短ツールとして位置づけ、最終的な「声」と「事実」は自分でコントロールする姿勢です。AIが生成した冗長な表現・一般論・事実と乖離した数値は、応募者自身が磨き・校正・検証する後工程が欠かせない論点として挙げられます。

本章のまとめ

ATS対応は単カラム／標準フォント／標準見出し／キーワード整合／Word+PDFの5原則
レジュメ形式はクロノロジカルが業界標準、エンジニア求人での基本形
ChatGPT・Claude等のAI活用は変換／Action Verb提案／定量化／適合度チェック／Cover Letterの5パターン
職種別テンプレートはSE／ML/AI／Data Scientist／SRE／PM/EMでSummary・動詞・スキル構成が異なる
Action VerbはLeadership／Technical／Impact／Analysis／Collaborationの5カテゴリから選択
定量化は性能／規模／コスト／品質／ビジネスの5パターン
GitHubはPinned Repositories／README／コントリビュートグラフ／OSS貢献で整備
LinkedInは職歴整合／Headline／Skills／Recommendations／Activityで継続運用
Cover Letterは5段落構成×企業ごとカスタマイズが基本形
Career Gap・短期職歴・転職理由は隠さず建設的に表現
Remote jobsはTime Zone／リモート経験／Self-management／Asyncを明示
最終チェックは10項目のチェックリストで抜け漏れ防止
情報設計はATS／採用担当者／面接の3段階の読み手を意識した層別設計が論点

※ 本章は2026年4月時点の採用実務・業界慣習にもとづく一般的な解説です。応募先の国・企業・職種で求められるレジュメ仕様は異なる論点があり、最新の応募要件は各求人ページ・転職エージェント・キャリアアドバイザーでご確認ください。AI生成ツールを活用する際は、個人情報・機密情報の取扱いに留意し、最終的な記述内容の事実確認はご自身の責任で行ってください。