Llama 4 Indie Maker 完全ガイド:Scout vs Maverick の選び方、API vs 自前構築のコスト計算
Metaは2026年4月5日にLlama 4をリリースし、その後状況が混乱し始めた。
一方では「MaverickのベンチマークがGPT-4oを超えた」という公式の宣伝があり、もう一方ではLeCun本人が「results were fudged a little bit」と認めたという論争がある。Hacker Newsでは「ゴミだ」という意見もあれば、「バッチ処理でAPI費用を90%削減できた」という声もある。
indie makerとして「Claude / GPT-4oからLlama 4に一部のワークロードを移行すべきか」を検討しているなら、もう一つのベンチマーク議論記事は必要ない。必要なのはコスト計算 + シナリオ選択の意思決定フレームワークだ。この記事がそれだ。
TL;DR
- ScoutはIndie makerの選択(Groq API $0.11/$0.34)、MaverickはAPIで使えばよい($0.20/$0.60)、自前構築は不要
- ベンチマーク論争は本物(LeCunが確認)、codingタスクは確かに劣っているが、バッチ/retrievalタスクのコスト優位性は影響を受けない
- 「17B active parameters」は17GB VRAMを意味しない——MoEのすべてのparams(109B)をロードする必要があり、INT4で最低55GB必要
- クラウドでH100をレンタルして自前構築するのは、ほぼ常にGroq APIより高くつく。RTX 4090/Mac Studioをすでに所有している場合のみ自前構築を検討せよ
- 10Mコンテキストはretrievalの強力な武器(98%精度)だが、synthesis向けではない(2M+で品質が低下する)
- Together.aiのScout価格は$0.18/$0.59——OpenRouterの$0.08/$0.30より約2倍高く、コンプライアンス要件がある場合のみプレミアムが正当化される
Llama 4とは?Scout vs Maverick を30秒で理解する
Llama 4はMoE(Mixture of Experts)アーキテクチャを採用している——すべてのパラメータが毎回起動するわけではなく、各推論ではexpertの一部のみが使用される。これにより「見た目は大きく、動作は比較的速い」モデルが実現している。
| Scout | Maverick | |
|---|---|---|
| Active params | 17B | 17B |
| Total params | 109B(16 experts) | 400B(128 experts) |
| Context | 10M tokens | 1M tokens |
| 最低自前構築ハードウェア | 1x H100 (INT4) / RTX 4090 (Q4) | 4x H100 (INT4) |
| Groq API価格 | $0.11/$0.34 | $0.20/$0.60 |
| 位置づけ | GPT-4o mini相当 + 超長コンテキスト | GPT-4o相当(要議論) |
ほとんどのindie makerへの答えはScoutだ。 Maverickの自前構築には4枚のH100が必要で、indie規模ではそれは行わない。Maverickを使うならAPIで——推論品質の向上は、バッチ処理やretrievalタスクに対して通常2倍のプレミアムに値しない。
ベンチマーク論争の真実:Llama 4を信頼すべきか?
結論から言おう:LMArenaのランキングは無効、codingシナリオは確かに劣っているが、バッチシナリオのコスト優位性はある。
事件の全貌:
- Metaは「Llama-4-Maverick-03-26-Experimental」というchat-tuned実験版(公開でダウンロードできるバージョンではない)をLMArenaに提出した
- 研究者のNathan Lambertらが提出バージョンと公開バージョンの不一致を発見した
- Meta VPのAhmad Al-Dahleが最初に否定し、LMArenaはその後、特別チューニング版の提出を禁止するポリシーを修正した
- 2026年1月、Meta AIチーフを退任したばかりのYann LeCunが確認:「results were fudged a little bit」
- Rootlyの独立coding benchmark:Llama 4が最下位、69.5%の精度(トップとの差18%)
HNコミュニティのコンセンサスは「It feels like a flop because the expectations are real.」
どう解釈すべきか?
- LMArenaのランキングは参考にできない——特別チューニング版で作られたものだ
- codingタスクの差はMoEアーキテクチャの構造的弱点だ——stateful codingはステップをまたいだ状態追跡が必要で、MoEのexpert routingはこれが苦手だ
- しかし、バッチ分類、文書要約、retrieval QAなど「各呼び出しが比較的独立している」タスクはまったく影響を受けない——これらのタスクはコスト効率が評価基準であり、ランキングではない
信頼度評価:ベンチマーク論争の事実(HIGH confidence、複数の情報源で相互確認済み)。codingの遅れという結論(MEDIUM confidence、Rootlyは単一の独立テストだが、MoEの構造的弱点には理論的裏付けがある)。
API料金完全比較表
すべてのLlama 4 APIプロバイダーの価格が同じわけではない——差は想像以上に大きい。
本表のデータは2026年4月時点のもので、各プロバイダーの公式価格ページに基づく。
| プロバイダー | Scout入力 $/1M | Scout出力 $/1M | Maverick入力 $/1M | Maverick出力 $/1M | 特徴 |
|---|---|---|---|---|---|
| OpenRouter | $0.08 | $0.30 | $0.15 | $0.60 | 最安値、自動ルーティング |
| Groq | $0.11 | $0.34 | $0.20 | $0.60 | 最速(LPU ~408 tok/s) |
| Together.ai | $0.18 | $0.59 | $0.55 | $2.19 | SOC 2 Type II + HIPAA |
3つの選択ロジック:
- コスト優先 → OpenRouter(Scout出力$0.30、最安値)
- 速度優先 → Groq(LPUアーキテクチャ、p50 latency < 500ms)
- コンプライアンス要件(HIPAA / SOC 2)→ Together.ai(約2倍のプレミアムだが、明確なコンプライアンス認証あり)
Together.aiはMetaの公式パートナーだが、「公式パートナー」は「最高のコストパフォーマンス」を意味しない。明確なコンプライアンス要件がなければ、OpenRouterかGroqを選ぼう。
比較として:Claude Sonnet 4.6の出力価格は$15.00/1M tokensで、Groq Scoutはわずか$0.34——44倍安い。しかし価格だけが意思決定の要因ではない。後ほど説明する。
Llama 4 vs Claude / GPT-4o のコスト計算
抽象的な価格比較ではなく、実際のタスクで計算する。
前提条件:1:3のinput:outputトークン比(呼び出しあたり200 input + 600 output tokens)、月間30,000回の呼び出し(1日あたり約1,000回)。
| プラン | 月額計算 | 月額 |
|---|---|---|
| Groq Scout | (200×$0.11 + 600×$0.34) / 1M × 30,000 | $6.78 |
| OpenRouter Scout | (200×$0.08 + 600×$0.30) / 1M × 30,000 | $5.88 |
| Claude Haiku 4.5 | (200×$1.00 + 600×$5.00) / 1M × 30,000 | $96.00 |
| Claude Sonnet 4.6 | (200×$3.00 + 600×$15.00) / 1M × 30,000 | $288.00 |
| GPT-4o mini | (200×$0.15 + 600×$0.60) / 1M × 30,000 | $11.70 |
Groq ScoutはHaiku 4.5より**93%安く、Sonnet 4.6より97%**安い。
しかし90%以上の節約はすべて切り替えるべきだということを意味しない。以下はシナリオ分析だ:
Llama 4に切り替えるのに適したタスク:
- バッチ文書要約(各文書が独立しており、文書間の推論が不要)
- データ分類 / タグ付け(keyword extraction、sentiment analysis)
- Codebaseナビゲーション / retrieval(特定の関数を見つける、call pathを追跡する)
- 画像テキスト抽出(Scout ネイティブmultimodal、EU以外のユーザーが利用可能)
切り替えに適していないタスク:
- 複雑な多段階coding(Rootlyテストで18%の遅れ)
- Multi-turn tool calling agent(Maverickは2026-04時点で「under development」とマークされている)
- 超長コンテキストでのリアルタイムチャット(10M tokensでTTFT > 60秒)
- Safety-criticalな出力(長いコンテキストでの幻覚率の信頼できるデータが不足)
自分のトークン分布を見積もる方法は? APIコールでusage loggingを有効にし、1週間のprompt_tokensとcompletion_tokensを記録して、実際のinput:output比を計算しよう。アプリケーションの種類によって差が大きい——チャットボットは通常1:3、要約タスクは10:1になることもある。私の仮定ではなく、あなたの実際の数値を上記の式に当てはめること。
10Mトークンコンテキストで実際に何ができるか
Scoutの10Mトークンコンテキストウィンドウは本物の機能であり、マーケティング用語ではない——しかし、何ができて何ができないかを理解する必要がある。
MetaのNIAH(Needle In A Haystack)ベンチマークによると:10Mコンテキストでretrievalタスクの精度が98%。
しかしここで重要な区分がある:context-as-database(retrieval) vs context-as-working-memory(synthesis)。
Retrieval(有効、10Mで使用可能)
超長コンテキストから特定の情報を見つける——Ctrl+Fのようなものだが、より賢い:
- 完全なcodebase分析(500K〜2M tokens):特定のAPI呼び出しを見つける、dependency chainを追跡する、onboardingドキュメントを生成する
- 法的/契約書バッチ処理:50以上の契約書を一括で比較して条項の矛盾を見つける(10M tokens ≈ 7,000ページの文書)
- 長期研究アシスタント:6〜12ヶ月のnotes + papersをコンテキストに常駐させ、いつでもクエリできる
Synthesis(限定的、2M+で品質低下)
モデルに大量のデータを横断して新しい洞察を合成したり再構築させることを要求する——「これら50のファイルを読んでからアーキテクチャを書き直してほしい」というような:
コミュニティのテストと分析によると、synthesisタスクは2Mトークンを超えると品質が大幅に低下することが示されている。「codebase全体を投入してLlama 4に再構築させる」という期待は非現実的だ。
結論:10Mコンテキストはcontext-as-databaseだ——検索、特定、比較に使おう。context-as-working-memoryではない——10M tokensにわたる深い合成を期待してはいけない。
Llama 4自前構築のハードウェア要件:「17B」に騙されるな
これが最もよくある技術的誤解だ:「Scoutは17B active parametersなので、VRAMの要件は17B denseモデルと同程度だ。」
違う。 MoE(Mixture of Experts)はすべてのexpertパラメータをメモリにロードする必要があり、各forward passで起動する部分だけではない。
計算:
- 109B total params × 2 bytes (BF16) = ~218GB VRAM(消費者向けには不可能)
- 109B × 0.5 bytes (INT4) = ~55GB VRAM(H100 80GB 1枚)
- 比較:17B denseモデルのINT4は約9GBのみ必要
| モデル | 精度 | VRAM要件 | 推奨ハードウェア | パフォーマンス |
|---|---|---|---|---|
| Scout | BF16 | ~218GB | 不可能(消費者向け) | — |
| Scout | INT4 | ~55GB | 1x H100 80GB | 標準production |
| Scout | Q4 (Ollama) | ~24GB | RTX 4090 / Mac M4 Pro 48GB | 25-40 tok/s |
| Scout | 1.78-bit (Unsloth) | ~14GB | RTX 3080 16GB | ~20 tok/s(品質劣化大) |
| Maverick | INT4 | ~200GB | 4x H100 | indie規模外 |
Ollamaクイックインストール
# Ollamaをインストール(macOS)
brew install ollama
# Llama 4 Scoutをダウンロード(Q4、24GB+ VRAMが必要)
ollama pull llama4
# 実行
ollama run llama4
パフォーマンスの期待値(コミュニティ報告、MEDIUM confidence):
- M4 Pro Mac 48GB:~30-40 tok/s
- RTX 4090 24GB:~25-35 tok/s
- M3 Max 36GB:~20-28 tok/s
注意:Maverickは消費者向けのOllamaデプロイをサポートしていない(200GB+ VRAMが必要)。
API vs 自前構築コスト試算:いつ自前構築が割安になるか?
まず数字を見てみよう。
| 自前構築方案 | 月額コスト | Groq Scoutとの比較 | Break-even月間トークン量 |
|---|---|---|---|
| H100レンタル (Vast.ai) | ~$1,075 | GroqはほぼついにAPIより安い | ~38億tokens(非現実的) |
| H100レンタル (Lambda Labs) | ~$2,153 | Groqは常にAPIより安い | ~61億tokens(不可能) |
| RTX 4090所有済み(電気代のみ) | ~$20-30 | 月間50-100M tokenで回収 | 50-100M tokens |
| Mac Studio M4 Ultra所有済み(電気代のみ) | ~$15-25 | より早く回収 | 40-80M tokens |
上記のbreak-even計算はGroq Scoutの価格$0.11/$0.34(2026-04-18時点)に基づき、1:3のトークン比を仮定している。
結論は明確だ:ハードウェアをすでに所有していない限り、クラウドでのレンタルによる自前構築は常にGroq APIより高くつく。
しかし見落とされがちな隠れたコストがある:DevOpsのメンテナンス時間。1人のside projectで毎週3〜5時間Ollama/vLLMのメンテナンスに費やす場合(モデルの更新、スケーリング、デバッグ)、$50/hrで計算すると月$600〜1,000になる。これを加えると、ハードウェアを所有していても、break-evenポイントは大幅に上昇する。
正直に言うと、ほとんどのindie makerの月間API費用は$10〜$100の範囲だ。自前構築を真剣に検討する必要がある段階になると、プロダクトはインフラ投資を支えるのに十分な収益をすでに上げているはずだ。
Indie Makerユースケース選択マトリクス
| タスク種別 | Llama 4 Scout | Claude Haiku 4.5 | 規模次第 |
|---|---|---|---|
| バッチ文書要約 | ✅ 第一選択(90%+節約) | より高品質だが14倍高い | — |
| データ分類 / タグ付け | ✅ 第一選択 | — | — |
| Keyword extraction | ✅ 第一選択 | — | — |
| Codebase retrieval | ✅ 10Mコンテキストの優位性 | — | — |
| 画像テキスト抽出 | ✅(EU以外のユーザー) | ❌ 非対応 | Claude visionの方が安定 |
| 複雑なcoding copilot | ❌ 18%の遅れ | — | ✅ Claude Sonnet |
| Multi-turn agent | ❌ tool callingが不安定 | ✅ | — |
| リアルタイムチャット > 10並行 | ⚠️ Groqのrate limit | ✅ | — |
| 記事執筆(日本語) | ⚠️ タスクによって品質が異なる | ✅ 日本語品質がより安定 | — |
ハイブリッドアーキテクチャが最も実用的な選択だ:
- バッチ/分類/retrievalタスク → Groq Scout(90%+節約)
- 品質保証が必要なユーザー向けタスク → Claude Haiku 4.5へのfallback
- 70%がScout、30%がHaikuという仮定では、混合コストは純Haikuより約60%安くなる
ライセンスリスクと長期戦略評価
Llama 4 Community Licenseは一般的に理解されている「オープンソース」ではない——これはsource-availableであり、Open Source Definition(OSI基準)には適合していない。
3つの主要なライセンス制限
- MAU上限:月間アクティブユーザーが7億人を超える場合はMetaの追加ライセンスが必要(indie makerが実際にこれに触れることはない)
- EU マルチモーダル制限:EU のユーザーはLlama 4のビジョン機能(Scout/Maverickのmultimodal能力)を使用できない。テキスト機能はEUでも引き続き利用可能
- 非OSIオープンソース:真のオープンソースではなく、MetaはよりÂ多くのコントロール権を持つ
SaaS開発者への注意:プロダクトにEUユーザーがいて、Llama 4のvision機能(例:ユーザーにスクリーンショットをアップロードして分析させる)を使用している場合、技術的にはライセンス条項に違反している。テキスト機能は影響を受けない。
Metaの長期戦略リスク
2025〜2026年にかけて、いくつかの懸念すべきシグナルが現れている:
- LeCunの退職 + VP Joelle Pineauの辞職——Meta AIのリーダーシップが大幅に刷新された
- Digitimes 2025-12の報道:MetaがLlamaの後継モデルを延期し、社内でクローズドソースへ転換
- ZuckerbergがGenAI orgを周縁化
推奨:Llama 5が必ずオープンソースになると仮定しないこと。Llama 4に依存する前に、provider-agnosticなfallbackメカニズムを設計しよう。最もシンプルな方法は抽象レイヤーでAPI呼び出しを隔離すること(GroqからClaudeへの切り替えはendpoint + model nameの変更のみ)で、切り替えコストを20行のコード以内に抑えることができる。
上記のライセンス情報は2026-04-18時点のLlama 4 Community Licenseに基づいており、Metaはいつでも条項を変更する可能性がある。
意思決定マトリクス:3分でLlama 4が自分に適しているか判断する
情報量が多い。3ステップに圧縮しよう:
Step 1:タスクタイプのフィルタリング
- 主なワークロードはcoding copilotまたはmulti-turn agentか?→ 切り替えを推奨しない、Claude/GPT-4oが依然として優れている
- 主なワークロードはバッチ処理、分類、retrievalか?→ 次へ進む
Step 2:月間トークン量の見積もり + API選択
月額 = (input_tokens × 入力単価 + output_tokens × 出力単価) / 1,000,000 × 月間呼び出し回数
| 月間トークン量 | 推奨 |
|---|---|
| < 100M tokens | GroqまたはOpenRouter API(月額 < $50、自前構築は考えなくてよい) |
| 100M-1B tokens | Groq API + Haiku fallbackのハイブリッドアーキテクチャ |
| > 1B tokens かつGPUを所有済み | 自前構築を評価(RTX 4090 / Mac Studio) |
| > 1B tokens かつGPUなし | 引き続きAPI利用(クラウドH100のレンタルは割に合わない) |
Step 3:コンプライアンスと地域のフィルタリング
- HIPAA / SOC 2の要件があるか?→ Together.ai(約2倍のプレミアムだが、明確な認証あり)
- EUユーザーがいて + vision機能を使用しているか?→ Llama 4 multimodalを除外し、Claude visionに切り替え
- 上記のいずれでもない?→ OpenRouter(最安値)またはGroq(最速)
リスク開示
価格はいつでも変わる:APIマーケットは競争が激しく、本記事で引用した価格は2026年4月のスナップショットだ。最新データは各プロバイダーの価格ページを参照すること。
ベンチマークの限界:本記事で引用しているRootlyのcoding benchmarkは単一の独立したテストであり、サンプル数は限られている。codingタスクが遅れるという結論にはMoEの構造的弱点という理論的裏付けがあるが、すべてのcodingシナリオで必ず遅れることを意味するわけではない。
試算は仮定に基づく:コスト計算は1:3のinput:outputトークン比と月30,000回の呼び出しという仮定に基づいている。実際のトークン分布は大きく異なる可能性がある——本番稼動後の最初のタスクは実際の数値を測定することだ。
ライセンスリスク:Llama 4 Community Licenseの条項はいつでも変更される可能性がある。本記事のライセンス分析は2026-04-18時点のものだ。
結論
Llama 4は「安いClaudeの代替品」でも、「ベンチマーク不正があったから無視すべき失敗作」でもない。
明確な適用シナリオを持つツールだ:バッチ分類、文書要約、codebase retrieval——これらのタスクでは、Groq ScoutはClaude Haikuより93%安く、品質は十分に対応できる。しかしcoding copilotとmulti-turn agentは適していない——これはMoEアーキテクチャの構造的制限であり、promptを調整しても解決できるものではない。
最も実用的なアプローチは:ハイブリッドアーキテクチャだ。バッチタスクはGroq Scout($0.11/$0.34)、品質保証が必要なユーザー向け機能はClaude Haiku 4.5($1/$5)、try/exceptで切り替える20行のコード。これにより、API費用を60%以上節約しながら、重要なタスクで品質を損なわずに済む。
今すぐ始めよう:上記の式で月額を見積もり、意思決定マトリクスと照らし合わせ、最初にテストするシナリオを選ぼう。覚えておいてほしいのは——一度に全部切り替える必要はない。まず一つのバッチタスクを1週間Groq Scoutで動かし、節約できたコストを数値化してから、拡大するかどうか決めよう。
FAQ
Llama 4 ScoutとMaverickはどちらを選ぶべきか?
ほとんどのindie makerはScoutを選ぶ。Scoutは17B active / 109B totalのMoEモデルで、シングルH100(INT4)またはRTX 4090(Q4)で動作し、Groq APIはわずか$0.11/$0.34 per 1M tokens。Maverickは128 expertsのより大きなモデルで、自前構築には4枚のH100が必要なため、indie規模では基本的にAPIのみ利用(Groq $0.20/$0.60)。より高品質な推論やビジョン能力が必要でない限り、Scoutで十分だ。
Llama 4のベンチマーク論争は、使えないことを意味するのか?
そうではない。MetaがLMArenaに提出したのは特別チューニングされた実験バージョン(公開版ではない)であり、LeCunは2026年1月に「results were fudged a little bit」と認めた。これによりLMArenaのランキングは無効となったが、公開版の実際のパフォーマンスには影響しない。独立テストではcodingタスクで確かに遅れが見られる(Rootlyテスト: 69.5%の精度)が、バッチ分類、要約、retrievalなどのタスクにおけるコスト優位性は依然として本物だ。結論:Llama 4をcoding copilotとして使うのは避けるべきだが、高スループットのバッチ処理シナリオでは依然としてコスト削減の筆頭候補だ。
Llama 4を自前構築するにはVRAMがどれだけ必要か?
Llama 4 Scoutは「17B active parameters」を謳っているが、MoEアーキテクチャではすべてのexpert(109B total)をメモリにロードする必要がある。BF16では約218GB VRAM(実用不可)、INT4量子化では約55GB(H100 80GB 1枚)、Q4量子化では約24GB(RTX 4090またはMac M4 Pro 48GB)が必要だ。「17Bモデル」は「17GB VRAM」を意味しない。
APIより自前構築が割安になるのはいつか?
ほとんどのindie makerにとって:常にAPIの方が割安だ。クラウドでH100をレンタルすると月額$1,075〜2,153かかり、Groq APIより安くなるには月38億tokenが必要になる——これはほぼ不可能だ。唯一の例外:RTX 4090またはMac Studioをすでに所有している場合(電気代のみ$20〜30/月)、月間利用量が50〜100M tokensを超えると自前構築が割安になる。



