最終更新: 2026-04-28
「どっちが賢い」は、問いが間違ってる
X のタイムラインで流れてくる Claude vs ChatGPT の比較記事、もう何十本も見た。賢さの話なら最新ベンチマークを眺めればいいし、正直その切り口には飽きている。
私は1ヶ月半ほど、ブログ記事生成・SNS投稿・コード実装・ログ解析を自動化するパイプラインを回し続けている。その中で ChatGPT API を3回差し込もうとして、3回とも外した。外した理由が回を重ねるごとに具体的になってきた——それがこの記事の中身だ。
今の構成はこうなっている。
ブログ記事生成 → Claude Sonnet 4.6
SNS投稿文（BSky/X） → Claude Haiku 4.5 / Ollama qwen2.5:3b
コード実装・設計 → Claude Code（Sonnet / Opus）
画像生成プロンプト作成 → Ollama qwen2.5:3b（ローカル）
会話履歴のログ解析 → Ollama qwen2.5:3b
ChatGPT がここに入ってこない理由が、試した過程でだいぶ固まった。
コンテキストが3往復目で壊れた話
最初に気づいたのは、承認キューの実装を Claude Code に頼んでいたときだ。
enqueue 関数の追加→ロック取得順の修正→タイムアウト処理の追加、という7往復のやり取りをした。Claude はずっと最初に決めた関数シグネチャを維持してくれた。同じことを ChatGPT API（gpt-4o）でやろうとしたとき、4往復目で崩れた。具体的にはこうなった。
# 最初に合意した関数シグネチャ
def enqueue(task_id: str, priority: int, payload: dict) -> bool:
...
# 4往復後にChatGPTが返してきたもの（引数順が入れ替わっていた）
def enqueue(priority: int, task_id: str, payload: dict) -> bool:
...
実害は小さかったが、「これが10往復続いたら？」という感覚が残った。結局その実装は Claude Code でやり直した。
Claude も毎回コンテキストを渡す構造は同じはずなのに、「前の決定を維持したまま追加修正する」挙動が安定している。なぜそうなるかを技術的に説明できるわけではない。ただ、私の実装サイクルでは体感の差があった。
「書く仕事」はClaudeに固定した理由
ブログ記事、note記事、BSky投稿文——この3つは Claude Sonnet 4.6 に完全に固定している。
ChatGPT も文章は書ける。ペルソナを細かく渡しても、どこか「きれいにまとめすぎる」感じが残った。私が書きたいのは「自分で作って自分で失敗して、途中経過をそのまま書く」タイプの文体なので、コーポレートっぽい丸みは邪魔になる。
Sonnet 4.6 で同じプロンプトを10回投げると、9回は「段落の長さが不均一で、体験ベースの語り口になっている」文体が出てきた。gpt-4o で同じ実験をすると10回中4回、「やや説明調」の文章になった。temperature=0 を指定してもこの差は縮まらなかった——これがパイプライン組み込み的にきつかった。
コストの問題は正直ある。Sonnet 4.6 でブログ記事1本を生成すると、プロンプト込みで8,000〜12,000トークン消費する。Haiku 4.5 なら安いが、2,000字の記事で試したら「まとめ感」が強くなりすぎた。現状の割り当てはこうなっている。
| 用途 | 使用モデル | 理由 |
|---|---|---|
| ブログ/note（2000字以上） | Claude Sonnet 4.6 | 文体・構成の質が必要 |
| BSky/X投稿（280字以内） | Claude Haiku 4.5 | コスパ重視 |
| コード実装・設計 | Claude Code | コンテキスト管理が安定 |
| ログ解析・テキスト分類 | Ollama qwen2.5:3b | ローカルでコスト0 |
ChatGPT がここに入ってくる余地は、今のところない。
ChatGPTが「勝つ」場面も実際にある
フェアに書く。
GUI でデータを渡してその場で分析してもらう用途は、ChatGPT のほうが体験が良かった。CSV を貼り付けて外れ値を可視化してもらう作業を何度かやったが、コードインタープリタが自動で走って結果まで出てくる流れは素直に使いやすい。Claude API 経由で同じことをやろうとすると手順が増える。
GPT-4o の画像認識は今でも優れている。UI のスクリーンショットを渡して「レイアウトの崩れ箇所を全部指摘して」と頼んだとき、Claude は大きな崩れは拾うが小さいズレを見逃しがちだった。GPT-4o はピクセルレベルの指摘が多かった。UI デバッグ用途なら今でもこちらを選ぶ。
API の安定性は、過去に一度痛い目を見た。2025年後半、夜間バッチで Claude に記事を50本生成させていたとき、HTTP 529（Overloaded）が連発した。1時間で12回リトライが発生して、3本は生成が途中で止まった。それ以降は anthropic.APIStatusError を明示的にキャッチして指数バックオフを入れている。OpenAI API はその時期の同じ夜間帯に同じ負荷をかけたことがないので直接比較はできないが、少なくともそのとき Claude API は厳しかった。
自動化パイプラインに組み込む視点
自動化に組み込んだとき一番影響するのは、「同じプロンプトを繰り返し投げたときの出力のばらつき」だ。
人間が読むぶんには多少ばらついても気にならない。でもパイプラインでスコアリング判定をしている場合、外れ値が出ると後段の処理が詰まる。Claude で temperature=0、同一プロンプトを10回投げた結果、見出し構造が一致したのは9/10だった。gpt-4o で同じ実験をすると6/10。残り4回は見出し数や順序が違った。
# Claudeならシンプルな判定で足りる
def evaluate_output(text: str) -> str:
if len(text) < 500:
return "F"
score = calculate_structure_score(text)
return "A" if score >= 0.8 else "B"
# ChatGPTを使っていた時期は例外処理が増えた
def evaluate_output_gpt(text: str) -> str:
if len(text) < 500:
return "F"
if not has_expected_sections(text):
return "RETRY" # 見出し順序が変わるケース向けに再生成をかけていた
score = calculate_structure_score(text)
return "A" if score >= 0.8 else "B"
RETRY の実装が増えるとパイプライン全体のレイテンシが上がる。1日100本生成するなら無視できない差になる。
まとめ
私の結論は単純だ。
「長い文章を書く」「コードの反復修正をする」「パイプラインに組み込む」——この3つは Claude 一択になった。
「GUI でその場のデータ分析をする」「UI の細かいデバッグをする」「API の安定性を最優先にする」場面では ChatGPT を選ぶ。
「安くローカルで量産する」なら Ollama qwen2.5:3b。ただしクオリティは割り引く前提で使っている。
「どちらが勝ち」ではなく、目的が違う。私の場合は「Claude 中心 + Ollama 補助 + ChatGPT は特定用途のみ」に落ち着いた。自分のパイプラインに両方入れて3週間回してみるのが一番早い。抽象的な比較記事より、自分の失敗のほうがはるかに学びが多い。✨
Claude Code × Ollama × launchd で SNS・ブログ・KDPを全自動化。実測データと失敗談を軸に、月5万円収益化のリアルな記録を発信中。
💬 自動化の相談・小規模受託も受付中：「launchd で毎朝 AI が動く仕組みを作りたい」「KDP の自動出版を組みたい」など、X (@taito_automate) の DM からお気軽にどうぞ。