最終更新: 2026-04-28
この記事でわかること
Claude API と OpenAI API を3ヶ月間、同じ自動化パイプラインで並走させた。ブログ記事の生成、BSky/X への投稿文作成、品質チェック——合わせると月に数百回の API 呼び出しになる。その実費と、「安い方に切り替えたら逆に高くついた」という話をまとめる。「どちらが安いか」は用途によって完全に変わる。それが3ヶ月で出た結論だ。
APIコストの基本構造——ここを理解しないと比較できない
Claude API も OpenAI API も、課金の単位は「入力トークン数 + 出力トークン数」だ。ただしモデルによって単価の差が10倍以上開く。2026年4月時点の主要モデルの価格がこれ。詳細は OpenAI API Pricing と Anthropic Pricing を参照。
| モデル | 入力 ($/1M tokens) | 出力 ($/1M tokens) | 備考 |
|---|---|---|---|
| Claude Haiku 4.5 | $0.80 | $4.00 | 最安・高速 |
| Claude Sonnet 4.6 | $3.00 | $15.00 | バランス型 |
| Claude Opus 4.7 | $15.00 | $75.00 | 最高精度 |
| GPT-4o mini | $0.15 | $0.60 | 激安 |
| GPT-4o | $2.50 | $10.00 | 標準 |
| o3 mini | $1.10 | $4.40 | 推論特化 |
数字だけ見ると GPT-4o mini が圧倒的に安い。Claude Haiku との比較でも入力単価は 0.80 対 0.15——5倍以上の差がある。同じタスクで同じ品質が出るなら OpenAI 一択になる計算だ。ただ「同じ品質」という前提が崩れた瞬間に話が変わる。それを確認するために私は3ヶ月かけた。
実測:ブログ記事生成パイプラインの3ヶ月コスト
私のパイプラインでは ai_client.py が ai_config.yaml を読んで、タスク名に応じてモデルを自動選択する。記事本文の生成は Claude Sonnet 4.6、BSky/X 投稿文と品質チェックは Claude Haiku 4.5——という割り当てにしている。呼び出し側のコードはこれだけ。
from lib.ai_client import AIClient
client = AIClient()
result = client.generate(
task="blog_article",
prompt=topic_prompt,
context=reference_data
)
task の値を変えれば Haiku に自動で切り替わる。この抽象化がなかったら3ヶ月の間に何度も設定ファイルを手書きで書き換える羽目になっていた。
3ヶ月の実績がこれ。
| 期間 | 記事(本) | X/BSky投稿(件) | Claude API費用 | OpenAI API費用 |
|---|---|---|---|---|
| 2月 | 28 | 186 | $4.20 | $0.80 |
| 3月 | 35 | 241 | $5.60 | $1.10 |
| 4月(前半) | 18 | 130 | $2.90 | $0.54 |
合計で Claude が $12.70、OpenAI が $2.44。差額は $10 強。一見「Claude 高いじゃないか」となる——ただし OpenAI 側でやっているのは画像キャプション生成と簡易分類だけで、記事本文は全部 Claude だ。同じ土俵で比較するには、同じタスクを両方に投げた実験が必要だった。
品質差を無視したコスト比較は意味がない
2月の途中、1週間だけ記事生成を GPT-4o に切り替えて試した。1本あたりのトークン数はほぼ変わらず 4,000〜5,000 tokens。だが品質チェックのスクリプトを通した瞬間に崩れた。
8割が再生成対象に落ちた。構成の矛盾、引用元が存在しない URL、「2025年の最新データによると」と書いてあるのに数値が2023年のもの——そういう雑さが連発した。当時のログにこう残っている。
quality_check: FAIL - structure_inconsistency (score: 0.41)
quality_check: FAIL - citation_mismatch (score: 0.38)
quality_check: FAIL - structure_inconsistency (score: 0.44)
Claude Sonnet 4.6 では同じ品質チェックを初出で通過する割合が 90% を超えていた。再生成が必要なのは10本に1本ほど。GPT-4o では10本に8本が再生成対象になる——コストをトークン単価だけで比べることに意味がないと理解したのはこのときだった。再生成コストを込みで計算すると、GPT-4o の方が高くつく。
とはいえ GPT-4o mini が役に立たないわけでもない。ここが話のポイントで、タスクを選べばむしろ Claude より優位な場面がある。
短文・投稿文は GPT-4o mini が圧勝
BSky と X の投稿文は140文字前後の短文だ。構成の矛盾も引用ミスも起きようがない。このタスクで GPT-4o mini と Claude Haiku 4.5 を比べると、品質の差は体感できないレベルだった。
私のパイプラインでは現在も投稿文生成の一部を GPT-4o mini に任せている。月30件ほど生成して費用は $0.05 未満——ほぼ無料と言っていい範囲だ。Claude Haiku でも単価は低いが、それでも GPT-4o mini の6倍近い差がある。短くて単純なタスクでは OpenAI を選ばない理由がない。
画像の alt テキスト付与、URL からカテゴリを判定する分類処理——これも GPT-4o mini で十分だった。タスクが単純なほど、単価の安さがそのままコスト効率に直結する。複雑さが要求されないなら Claude の品質は過剰になる。
プロンプトキャッシュの効果——知らないと損する
Claude API には Prompt Caching という機能がある。同じシステムプロンプトを繰り返し使うとき、2回目以降の入力コストを 90% 削減できる仕組みだ。私がこれを知ったのは運用2ヶ月目に入ったころ。知らずに1ヶ月分のコストを払っていた。
設定方法は cache_control を追加するだけ。
messages = [
{
"role": "user",
"content": [
{
"type": "text",
"text": system_prompt,
"cache_control": {"type": "ephemeral"}
},
{
"type": "text",
"text": user_prompt
}
]
}
]
最初にやったミスは、cache_control を content の各要素ではなく messages のトップレベルに置いたことだ。エラーにはならない——ただキャッシュが一切効かない。API レスポンスの usage に cache_read_input_tokens というフィールドがあって、そこがずっと 0 のままだった。1時間ほど格闘して、やっと配置場所の間違いに気づいた。
正しく設定してからの3週間、記事生成コストが約 30% 下がった。私のパイプラインでは記事生成のシステムプロンプトが 1,200 tokens ほどあるので、その分まるごとキャッシュに乗る。プロンプトが長いほど効果が出る。
どちらを選ぶべきか——用途別の結論
3ヶ月で出た判断基準を一言で言うと「生成物に構造や整合性が求められるかどうか」だ。
ブログ記事・KDP 原稿・詳細な解説文など、構成が崩れると価値がゼロになるタスクは Claude Sonnet 4.6 を選んでいる。再生成コストを込みで計算すると、トークン単価が高くてもコスト効率は悪くない。GPT-4o で試して8割再生成になった経験がある以上、長文生成で OpenAI に戻すつもりはない。
BSky/X 投稿文・画像キャプション・カテゴリ分類・短い要約など、140〜300文字で完結する単純タスクは GPT-4o mini 一択。単価の安さがそのままコストに効く。品質の差は体感できなかった。
推論が必要なコーディング系タスクやデバッグは Claude Sonnet か o3 mini を状況で使い分けている——ただし o3 mini はまだ本番パイプラインには組み込んでいない。実験中の段階だ。
まとめ
3ヶ月の実費は Claude $12.70、OpenAI $2.44。この数字を「Claude は高い」と読むのは間違いで、タスクの性質が違う。記事本文を GPT-4o に切り替えた1週間は再生成コストで逆に高くついた——その体験が判断基準になっている。
現在のパイプラインは Claude Sonnet 4.6 が記事生成・KDP 原稿、GPT-4o mini が投稿文・分類、Claude Haiku 4.5 が品質チェック、という3モデル並走だ。プロンプトキャッシュを有効にしてから月の Claude 費用がさらに 30% 下がった。合計で月 $5 前後。記事を月30本以上出してこの金額なら、自動化の元は取れている。
「Claude か OpenAI か」という問いへの答えは「両方」だ。どちらかに統一しようとして、私は一度失敗している。