Claude Haiku → Gemini Flash に乗り換えた理由 — AIモデル選定の判断基準

開発途中でAIモデルを全面移行した。recipe-ai（YouTube料理動画からレシピを自動抽出するアプリ）の開発中、当初採用していたClaude Haiku 4.5を捨て、Gemini 2.5 Flashに乗り換えた話をする。

「どのAIモデルを使うか」は、2026年の個人開発において避けて通れない設計判断だ。しかし、ベンチマークの数字だけでは見えない「ユースケース固有の壁」が存在する。この記事は、その壁にぶつかり、サンクコストを捨てて乗り換えた実体験の記録である。

この記事でわかること:

• Claude HaikuとGemini Flashの根本的なアーキテクチャの違い
• YouTube動画処理で字幕取得がボトルネックになる理由
• Geminiのマルチモーダル能力がこの問題をどう解決するか
• 両モデルの得意・不得意と使い分けの判断基準
• 開発途中でAIモデルを切り替える際の判断フレームワーク

当初の設計: Claude Haiku + youtubei.js

recipe-aiの最初の設計はこうだった。

1. youtubei.js（YouTube字幕取得ライブラリ）でYouTube動画から字幕テキストを抽出
2. 字幕テキストをClaude Haiku 4.5に渡す
3. Claudeがレシピ（材料・手順・ポイント）をJSON形式で構造化出力

Claude Haikuを選んだ理由は明確だった。

• 速い: Haikuは応答速度が速く、ユーザー体験を損なわない
• 安い: トークン単価が低く、個人開発の予算に収まる
• JSON出力が安定: 構造化データの生成において、フォーマットの崩れが少ない
• 開発者体験: Anthropic APIのドキュメントが整備されており、実装がスムーズ

テキスト処理に限定すれば、この選択は間違っていなかった。問題は「テキスト処理に限定できなかった」ことにある。

壁にぶつかった: 字幕が取れない

開発を進めていくと、想定外の壁にぶつかった。

YouTubeの字幕が取得できない動画が大量に存在する。

具体的には以下のケースだ。

• 自動生成字幕が無効化されている動画: 投稿者が字幕機能をオフにしている
• 音声認識の精度が著しく低い動画: 料理動画では調理音やBGMがかぶり、音声認識がまともに機能しないケースがある
• youtubei.jsの制限: YouTube内部APIに依存しているため、YouTube側の仕様変更で字幕取得が不安定になる

これはClaude Haikuの問題ではない。テキストベースのAI全般に当てはまる構造的な制約だ。どれだけ優秀なLLMでも、入力となるテキストが存在しなければ何もできない。

つまり、「字幕を取得してからLLMに渡す」という2段階アーキテクチャそのものに限界があった。

Gemini 2.5 Flash という選択肢

この問題を解決するために調査した結果、Gemini 2.5 Flashが浮上した。決め手は3つある。

1. マルチモーダル: 動画URLを直接渡せる

Gemini 2.5 Flashは、YouTube動画のURLをそのままAPIに渡すことができる。字幕取得という中間処理が不要になる。

// Claudeの場合（2段階必要）
字幕取得（youtubei.js） → テキスト → Claude API → レシピJSON

// Geminiの場合（1段階で完結）
YouTube URL → Gemini API → レシピJSON

アーキテクチャが劇的にシンプルになった。

2. 字幕に依存しない動画理解

Geminiは映像そのものを解析できる。つまり、字幕が無い動画でも、映像から調理手順を読み取り、画面に表示されたテロップから材料の分量を抽出できる。

料理動画において、これは極めて大きなアドバンテージだ。多くの料理YouTuberは、材料リストや分量をテロップとして画面に表示している。音声には含まれないが映像には含まれる情報を、Geminiは拾える。

3. Google製 x YouTube という親和性

GeminiはGoogleが開発したモデルであり、YouTubeもGoogleのサービスだ。YouTube動画のネイティブサポートがあるのは、この親和性によるものだ。技術的にも事業戦略的にも、GeminiがYouTube動画を最も深く理解できるモデルであることは自然な帰結と言える。

実際の比較: Claude Haiku vs Gemini Flash

recipe-aiの開発を通じて得た、両モデルの実比較を整理する。

観点	Claude Haiku 4.5	Gemini 2.5 Flash
入力方式	テキストのみ（字幕が必要）	マルチモーダル（動画URL直接）
YouTube動画対応	別途字幕取得ライブラリが必要	ネイティブサポート
字幕なし動画	処理不可	映像から解析可能
JSON出力品質	安定（構造化出力が得意）	安定（Freeformモードで高品質）
応答速度	速い	Freeformモード: 非常に速い / Structuredモード: やや遅い
無料枠	あり（制限あり）	あり（より大きい無料枠）
映像情報の活用	不可	テロップ・調理映像から情報抽出可能
API安定性	高い	高い

Gemini側で見つかった注意点

Geminiへの移行後、別の課題も見つかった。

• Freeformモードの方が約2倍速い: Gemini 2.5 Flashには「Structured」と「Freeform」のモードがあり、Structuredモードはスキーマに従った出力を保証する代わりに処理が遅くなる。recipe-aiではFreeformモードでJSON出力させ、バリデーションをアプリ側で行う設計に切り替えた。
• 無料枠のタイムアウト: Geminiの無料枠にはリクエストあたりのタイムアウト制限があり、長い動画で制限に引っかかることがある。この問題については別記事で詳しく書いた。

乗り換えの判断基準

今回の移行から、AIモデル選定で重要な判断基準を3つ抽出する。

1. 技術的制約が最優先

「どのモデルのベンチマークが高いか」ではなく、「そもそもそのモデルで要件を満たせるか」が最初の判断基準だ。recipe-aiの場合、字幕が取れない動画を処理できないという技術的制約が決め手になった。性能比較以前の問題である。

2. サンクコストを捨てる勇気

Claude Haiku向けに書いたプロンプト、youtubei.jsとの連携コード、テスト用のフィクスチャ。これらはすべて書き直しになった。しかし、動かないものを改善し続けるより、動くものに乗り換える方がはるかに合理的だ。個人開発では特に、「今まで書いたコードがもったいない」という感情を判断基準にしてはいけない。

3. 最適なモデルはユースケースで決まる

「Claude vs Gemini、どっちが優れているか」という問い自体が間違っている。正しい問いは「このユースケースにはどちらが適しているか」だ。テキスト処理ならClaudeが強い。動画処理ならGeminiが強い。それだけのことだ。

いつClaude、いつGemini？

recipe-aiの経験から導いた使い分けの指針を整理する。

Claudeが向いているケース:

• テキストの分析・要約・構造化
• コード生成・レビュー・リファクタリング
• 長文の文脈理解（200Kトークンのコンテキストウィンドウ）
• 厳密なJSON構造化出力が必要な場面
• 複雑な指示への追従性が重要な場面

Geminiが向いているケース:

• YouTube動画・画像・音声を含むマルチモーダル処理
• 動画からの情報抽出（テロップ読み取り、シーン理解）
• Google系サービスとの連携
• 大量データのバッチ処理（無料枠が大きい）
• 視覚情報が重要なユースケース

両方使うパターン:

• マルチモーダル入力はGeminiで処理し、構造化・分析はClaudeで行う
• フロントエンドの開発補助はClaude、データ収集パイプラインはGemini

要は「テキストの世界で閉じるならClaude、現実世界の情報（映像・音声）を扱うならGemini」というのが、2026年4月時点での実感だ。

まとめ

• 字幕取得に依存するアーキテクチャの限界から、Claude HaikuからGemini Flashに全面移行した
• AIモデル選定はベンチマークではなく「ユースケースの技術的制約」で決まる
• テキスト処理はClaude、マルチモーダル処理はGemini、という使い分けが現時点での最適解

---

関連記事

Gemini 2.5 Flash で YouTube動画からレシピを自動抽出する方法

Gemini APIの具体的な実装方法を解説

→

150秒を1.9秒超えて全滅した話

Gemini移行後に遭遇したタイムアウト問題

→

Cursor vs Claude Code 徹底比較

AI開発ツールの選び方

→