はじめに
こんにちは。ITフィールドセールスをしている長井洸太です。
これまでの記事で、Claude APIでエンジニアへのアプローチDM文を生成する仕組みと、Gemini APIでURLを渡すだけで記事を要約する仕組みをそれぞれ紹介してきました。
実はこの2つのスクリプト、どちらも「AIに文章を作らせる」処理という意味では同じなのに、なぜかGeminiとClaudeを使い分けています。最初は「なんとなく」で選んでいたのですが、複数のスクリプトを見比べているうちに、自分の中で明確な基準ができてきました。今回はその基準を言語化してみます。
結論：「読む・集める」はGemini、「書く・伝える」はClaude
先に結論を書くと、自分が組んでいる自動化スクリプトでは役割がこうなっています。
| 役割 | 使うAPI | 具体例 |
|---|---|---|
| URLや記事本文を読んで要約する | Gemini |
summarize_url()（Facebook投稿生成） |
| 複数ソースからニュースを収集・要約する | Gemini |
fetch_rss() + Geminiまとめ（LinkedIn投稿生成） |
| プロフィール情報から自然な文章を生成する | Claude |
generate_dm()（GitHubエンジニア発掘） |
| 要約結果をSNS投稿文の型に整える | Claude |
generate_facebook_post()（Facebook投稿生成） |
つまり「インプットを処理してテキスト化する（読解・要約）」はGemini、「アウトプットとして人に読ませる文章を作る（生成・パーソナライズ）」はClaudeという分担です。
なぜこの分担になったか
Geminiは「URLをそのまま渡せる」のが強い
以前の記事（Gemini APIでニュースを要約してSNS投稿文を作る方法）で書いた通り、GeminiはURLを文字列としてプロンプトに埋め込むだけで、requests や BeautifulSoup によるスクレイピング処理なしに本文を読んで要約してくれます。
def summarize_url(url: str) -> str:
client = genai.Client(api_key=GEMINI_API_KEY)
prompt = f"""
以下のURLの記事を読み、要点を3〜5行で日本語で要約してください。
URL: {url}
"""
resp = client.models.generate_content(
model="gemini-2.0-flash", contents=prompt
)
return resp.text.replace("**", "").strip()
RSS収集やHTMLスクレイピングを自前で書かなくていい分、「情報を集めて要点を抜き出す」前段の処理はGeminiに寄せた方が実装コストが低くなります。
Claudeは「条件を細かく指定したときの自然さ」が強い
一方、Claude APIでエンジニアへのアプローチ文を自動生成した 記事で書いた generate_dm() のように、「売り込み感を出さない」「200文字以内」「相手の技術スタックに触れる」といった細かい条件をいくつも重ねたときに、テンプレっぽさが消えて自然な文章になるという体感がありました。
prompt = f"""
【候補者情報】
- 名前: {name}
- 自己紹介: {bio}
- 主な使用言語: {langs}
【条件】
- 200文字以内
- 売り込み感を出さない
- 相手の技術スタックに触れる
- 返信しやすい一言で締める
""".strip()
msg = client.messages.create(
model="claude-haiku-4-5-20251001",
max_tokens=400,
messages=[{"role": "user", "content": prompt}],
)
DM文やSNS投稿文のように「読み手の反応」を狙う文章では、条件をどれだけ細かく積めるかが品質に直結します。ここはClaudeに寄せています。
実際の使い分けフロー（LinkedIn投稿生成の例）
複数ソースからニュースを集めてSNS投稿を作る linkedin_all_patterns.py では、この役割分担がそのままパイプラインになっています。
Hacker News / 公式ブログ / GitHub Trending
↓ Gemini が複数ソースをまとめて日本語要約
Claude が要約を3パターン（反論型・数字リスト型・問題提起型）の投稿文に変換
↓
Markdownに下書き保存
「収集して要約する」までを1回Geminiに任せ、そこから先の「読者に刺さる型に書き分ける」部分をClaudeに渡す、という順番は今回紹介した3つのスクリプトすべてで共通していました。
やってみてわかったこと
「両方できるから」で選ぶと基準がブレる
GeminiもClaudeも、単体では要約も生成もどちらもできます。だからこそ「なんとなく前に使った方」で選んでしまいがちで、実際に自分もスクリプトごとにモデル選定が揃っていませんでした（前回記事でも触れた通りです）。「入力を処理する工程か、出力を磨く工程か」で線引きすると迷わなくなりました。
1回のAPI呼び出しで完結させようとしない
最初は「Geminiだけで要約からSNS投稿文まで一気に作れないか」も試しましたが、要約と文章生成の指示を1つのプロンプトに詰め込むと、条件のどれかが無視されやすくなりました。工程を分けて2回API呼び出しをした方が、結果的に安定した出力になっています。
コスト面でも役割分担が合理的
Geminiの無料枠・低コストなモデルで要約という「量をこなす」処理を担当し、Claude Haikuで文章生成という「質を作り込む」処理を担当する形になっているため、コスト構造としても無理がありません。
おわりに
「GeminiとClaude、結局どっちを使えばいいか」で悩んでいたのですが、複数のスクリプトを振り返ることで「読解・収集はGemini」「生成・パーソナライズはClaude」という自分なりの基準が見えてきました。
次回はプロンプト設計そのもの、DM文を作るときにどんな条件を積むと自然になるかをもう少し掘り下げて書く予定です。
毎日X（Twitter）・Instagram・LinkedInで自動化ツールや開発の話を投稿しています。ぜひ繋がりましょう！