cold-email-writer

コールドメールの作成

このスキルを使う場面

ユーザーが次のことをしたい場合に、このスキルを使います。

• 採用担当マネージャー、創業者、採用担当者に、面識のない相手へ送る営業メールを書きたい
• 紹介を受けていない求人について問い合わせたい
• 働きたい企業に自己紹介したい
• 「コールドメール」「連絡する」「紹介メール」「アウトリーチ」「採用担当マネージャーに連絡する」などの言葉を使っている

基本原則

コールドメールがうまくいかないのは、カバーレターのように聞こえるからです。目指すのは、自分の経歴を一方的にアピールする候補者ではなく、企業について具体的な何かに心から気づいた、聡明な人のように聞こえることです。

メールが目指す印象： 営業トークではなく、同僚が読んで興味を持ったことを話題にするような印象です。

テンプレートの構成

件名

Quick intro — [First Name Last Name]

シンプルにします。クリックベイトは避けます。職種名も入れません。名前だけにします。

書き出し — つかみ（2～3文）

候補者が心から興味を引かれたことから始めます。その企業ならではの具体的な内容にしてください。ありきたりな褒め言葉は避けます。

I just came across [Company] and ended up spending more time on it than I expected.
[One specific thing that caught their attention — a stat, a product decision, a market insight from the JD or website]

よいつかみの例：

• 企業の資料にある具体的な数値や統計（「市場のうちオンライン化されているのはわずか5％」）
• 業界への理解が伝わる製品上の判断（「流通だけでなく、引受担当者と一緒にゼロから構築している」）
• 求人票から読み取れる技術的な知見（「モデル層だけでなく、LLMの活用に向けてデータ基盤を改善している」）

悪いつかみの例：

• ありきたり：「御社の取り組みが大好きです」
• 曖昧：「御社のミッションに共感しています」
• お世辞：「この分野で最も注目すべき企業の一つです」

所在地の開示（海外にいる場合）

候補者が企業とは別の国にいる場合は、早い段階でさらりと伝えます。

Before you read further, I should mention I'm based in [country]. But if we both
feel there's a strong fit, I'd be open to figuring things out.

経験年数の差（該当する場合）

職務に記載された必要年数が候補者の経験年数を上回る場合は、簡潔に触れたうえで話題を切り替えます。

The role mentions [X] years of experience — I'm at [Y], but the work I've
shipped is production-facing and I'd rather you judge that directly.

本文 — 自分について（3～5文）

現在の職務 → 関連する過去の経験 → 1～2件のプロジェクト。単なる経歴の羅列ではなく、文脈に沿って書きます。

A bit about me: I currently work at [Company], [one line on what the company does],
where I [what they actually do there — not a job title]. Before that I worked
with teams in [region], mostly around [relevant domain].

On the side I've been building [Project] ([link if applicable]) — [one line: what
it is and one proof point like "got to paying clients" or "20K downloads"].

ルール：

• 仕事については、優秀さの証明ではなく、背景情報として触れます
• 実績の羅列（「XをY％増加させました」など）は避けます。プロジェクト自体に語らせます
• 現在の勤務先が欧州または国際的なチームを擁するリモート企業なら、そのことを明記します
• プロジェクトへの言及は最大1～2件に絞り、最も関連性の高いものだけを選びます

接点（1～2文）

本人の経歴と具体的な職務とのつながりを示します。主張ではなく、気づきを伝えるような印象にします。

I think you're looking for [what the role actually wants] — that's the kind of
work I've been doing, and honestly I feel like I'd be a strong fit.

より具体的にする場合：

My stack maps naturally to yours — [specific tech overlap]. But more than the
stack, it's the [domain/problem] that I'm genuinely interested in.

ポートフォリオのリンク

More about me: [portfolio URL]

1行だけにします。説明は加えません。

結び

押しつけがましくなく、自信を感じさせる雰囲気で締めくくります。必死な印象にも、堅苦しい印象にもならないようにします。

I'm currently at [Company] and open to what's next. I think my experience lends
nicely to what you're building — so I think we'd both get something out of a
conversation.

[First Name]
[email]

避ける表現：

• 「ご連絡をお待ちしております」
• 「履歴書を添付いたしました」
• 「ぜひ機会をいただければと思います」
• 「入社できる可能性にわくわくしています」

執筆前のリサーチ

メールを書く前に、次の情報を集めます。

1. 企業の特徴 — 企業のウェブサイト、求人票、または「About」ページを読みます。言及する価値のある具体的な点を一つ見つけます。
2. 宛先の氏名 — LinkedIn、チームページ、またはAngelListで確認します。「[Name]さん」への挨拶は、どんな場合でも「採用担当者様」より効果的です。
3. 関連するプロジェクト — 候補者の最も関連性の高い実績を、職務の分野に結び付けます。
4. 技術スタックの重なり — 本当に合致する場合に限って触れます。

ユーザーが求人票を提示していて企業のウェブサイトがない場合は、執筆前に尋ねるか、ウェブサイトを確認します。

長さの目安

• 理想： 200～300語
• 最大： 400語
• 最小： 150語（簡潔さを優先して内容を削りすぎないでください）

すべての文に意味があるなら、長くてもかまいません。どの企業にも当てはまりそうな内容は削ります。

出力形式

最終的なメールは、コピーしてそのまま使えるよう、必ずプレーンなコードブロックで囲みます。

Subject: Quick intro — [Name]

Hi [Name],

[Email body]

[First Name]
[email]

避けるべきよくある間違い

自信過剰すぎる表現： ❌ 「私はあなたのチームにとって、非常に優れた人材になるでしょう」 ❌ 「私の経歴は、この役割に他の誰よりも適していることを示しています」 ✅ 「自分はこの役割にぴったりだと思います」— 確信を断言するのではなく、自分の考えを伝えます

謙遜しすぎる表現： ❌ 「ご希望の経験をすべて備えているわけではないかもしれませんが……」 ❌ 「万が一の可能性にかけて、ご連絡しています……」 ✅ 足りない点があれば率直に認めて、話を先に進めます。謝る必要はありません

長すぎる文章： ❌ 実績をすべて並べた3段落 ✅ 経歴について1段落、共通点について1段落

一般的すぎる表現： ❌ 「興味をお伝えしたく、ご連絡いたしました」で始める ✅ その会社に特に惹かれた理由から始める

下調べが足りない： ❌ 「御社の製品とミッションが大好きです」 ✅ 「市場規模250億ドルのうち、オンライン化されているのはわずか5％という数字は、機能の不足というより、デジタル化されていない業界が丸ごと残っているように感じます」

メールの例

Subject: Quick intro — Sarah Chen

Hi Marcus,

I just came across Meridian and spent more time on your site than I planned.
What pulled me in was the framing around your data infrastructure — you're not
just building an LLM layer on top of existing records, you're rethinking how
clinical data flows through the system in the first place. That's a harder
problem and a more interesting one.

I'm based in India, flagging that upfront. Happy to figure out the rest if
there's a real fit.

I currently work at Lune, a London-based climate intelligence company, where I
build event-driven data pipelines and agentic AI workflows for emissions
compliance — regulated, data-intensive systems where reliability isn't optional.
I also built Memos, a RAG system from scratch: hybrid retrieval, reranking,
ChromaDB, FastAPI. And InframetAI, an SDK for LLM cost and latency
observability that came out of seeing what breaks when the data layer isn't
designed around how models actually work.

I think you're looking for engineers who've actually built AI systems end to
end, not just wrapped APIs. That's the work I've been doing.

More about me: yourportfolio.com/about

I'm currently at Lune and open to what's next. I think my experience maps
closely to what you're building — so I think we'd both get something out of
a conversation.

Sarah
[email protected]