Llama 完全ガイド：MetaのオープンウェイトLLMを公式準拠で本番投入する（Llama 4・Bedrock・Llama API）

この記事のゴール

Llama は Meta が公開している**オープンウェイトの大規模言語モデル（LLM）**の総称です。GPT や Claude のように API の向こうにある“借り物”ではなく、重み（weights）をダウンロードして自分のものとして所有・改造・運用できる——これが Llama の本質です。

本稿は、その公式ドキュメント（llama.com / Meta AI Blog / Llama Developer Docs / Hugging Face）の内容に厳密に基づきつつ、公式には散らばっている「どのモデルを・どこで動かし・どの場面でどう使い・どこで詰まるか」を、実際に動くコードで一本に束ねるものです。読み終えたとき、次の3つができる状態を目指します。

1. Llama 4 が何のモデルで、なぜ“軽くて長い”のか（MoE と 10M トークン文脈）を人に説明できる。
2. Llama API・AWS Bedrock・セルフホストのどれを選ぶべきか判断し、今日中に手を動かせる。
3. デモではなく本番——型安全な構造化出力・冪等性・可観測性・回復性・そしてライセンスの地雷——に耐える実装を組める。

筆者について（信頼性の開示）：私は AWS Bedrock と Vercel AI SDK を土台に、RAG・音声エージェントなどの生成AIシステムを単独で設計・実装し、本番運用しています。Bedrock 上では Claude と Llama が同じ Converse API の裏に並ぶため、「クローズドAPI と オープンウェイトのどちらを選ぶか」は、毎案件で実際に下している判断です。本稿のコードと設計原則は、その実運用（音声エージェント事例、Bedrock×pgvector の RAG 設計、pgvector 本番 RAG）から抽出したものです。Llama 固有の“盛った数字”は出しません——出典は全て末尾の公式リソースに置きます。

30秒のまとめ（結論を先に）

「まず自分のプロンプトで賢さを確かめたい」なら、この後すぐの Llama API 章 に飛んでください。OpenAI SDK の baseURL を差し替えるだけで動きます。

Llama 4 とは何か：ネイティブマルチモーダル × MoE

2025年4月、Meta は Llama 4 “herd”（群れ） を公開しました。公式ブログの言葉どおり「ネイティブにマルチモーダルな AI イノベーションの新時代」を掲げた世代で、過去の Llama と決定的に違う点が2つあります。

1. ネイティブマルチモーダル：テキストと画像を、後付けではなく最初から同じモデルで扱う（early fusion）。
2. MoE（Mixture-of-Experts）：巨大な総パラメータのうち、入力ごとに必要な“専門家”だけを起動する。総量は大きいのに、1トークンあたりの計算（=コスト）は小さい。

この MoE が「Llama 4 は大きいのに軽い」のからくりです。たとえば Scout は総 109B のうち実際に動くのは 17B。だから単一 GPU でも回り、推論が安く速い。

群れの構成（公式スペック）

⚠️ 最重要の注意点：「モデル本来の文脈長」と「ホストが実際に出す文脈長」は別物。Scout は本来 10M ですが、Llama API では 128k、AWS Bedrock では Scout が約 3.5M・Maverick が 1M（公式記載、今後拡大予定）です。「10M トークン使えるはず」と設計すると、ホストの実効上限で詰みます。使う場所の上限を必ず確認してください。

Behemoth（約2兆パラメータ）は本稿執筆時点でも学習中で未公開です。Scout / Maverick は Behemoth からの蒸留（distillation）で底上げされている、というのが公式の説明です。つまり「巨大な親が小さな子を賢くした群れ」という構図です。

なぜ「オープンウェイト」を選ぶのか（Claude / GPT との使い分け）

Llama を語るうえで一番大事なのは、性能の数字ではなく「重みを所有できる」という一点です。ここが Claude や GPT との分水嶺で、用途で使い分けるのが正解です。万能の1つはありません。

Llama（オープンウェイト）が勝つ場面：

• データ主権・コンプライアンス：入力を外部APIに出せない（医療・金融・自治体・社外秘）。重みを自社VPC / オンプレに置き、データを外に出さずに推論できる。
• 微調整（fine-tuning）：自社ドメインに重みごと特化させたい。LoRA / フルFTのベースにできるのは重みが手元にあるオープンウェイトだけ。
• 原価の最適化：定常的に大量推論するなら、トークン単価×無限回の従量より、GPUを埋めて回す自前運用が1リクエスト単価で有利になりやすい。MoE で active が 17B と小さいのも効く。
• ロックイン回避：API の値上げ・仕様変更・提供終了に事業を人質に取られない。重みは消えない。
• エッジ / 隔離環境：ネット接続のない現場・端末で動かす。

クローズドAPI（Claude 等）が勝つ場面：

• 最前線の推論力・コーディング・エージェント：高難度のタスクでは、専有フロンティアモデルがまだ一枚上手（後述のベンチ比較参照）。
• 運用ゼロで始めたい：GPU 調達も MLOps も要らない。叩けば動く。
• 安全機構・ツール群が成熟：モデレーション・ツール実行・マルチエージェントの作り込み。

私の実務では、この2つを同じ抽象の裏で併用します。Bedrock なら Claude も Llama も Converse API で叩けるので、「難所は Claude、量で殴る前処理・抽出・分類は Llama」というコストと品質の二段構えが自然に組めます（その設計思想は Vercel AI SDK の本番記事、Claude API の実装記事 に通じます）。

2026年の現在地：Muse Spark で Llama は終わるのか

正直に、いま誰もが気にしている点に答えます。2026年4月、Meta Superintelligence Labs は Muse Spark を公開しました。これは Meta 初のプロプライエタリ（重み非公開）・API限定の推論モデルで、すでに Meta AI のスマートグラスは Llama 4 から Muse Spark に置き換わっています。一部メディアは「Meta がオープンソース Llama を捨てた」と報じました。

ここで設計判断を誤らないために、事実だけを切り分けます。

• Muse Spark は重みが手に入らない。所有・微調整・自前運用・データ主権という、あなたが Llama を選ぶ理由そのものを満たさない。Meta は「将来版のオープンソース化を望む」と述べていますが、現時点では希望にすぎません。
• 一方、Llama 4 Scout / Maverick は今もダウンロードでき、Hugging Face・Bedrock・Ollama で動き続けています。重みは回収不能——一度配られたオープンウェイトは消せません。
• つまり「所有して動かす」要件があるなら、2026年6月時点の本命は依然 Llama 4です。Muse Spark は「もう一つのクローズドAPI（Claude / GPT の競合）」として評価軸が違います。

結論：Muse Spark の登場は Llama を捨てる理由にならない。むしろ「オープンウェイトが必要な案件」と「最前線のクローズド推論が必要な案件」の線引きが、これまで以上にはっきりしただけです。本稿はその前者、所有して本番に載せる側の地図です。

使い方A：Llama API（OpenAI 互換・最速で試す）

「自分のプロンプトで賢さが通用するか、まず確かめたい」段階では、GPUを用意せず Meta 公式の Llama API を叩くのが最短です。最大の利点は OpenAI SDK 互換——baseURL を差し替え、鍵を LLAMA_API_KEY にするだけで、既存の OpenAI コードがそのまま動きます。

• OpenAI 互換エンドポイント：https://api.llama.com/compat/v1/
• 認証：LLAMA_API_KEY（Bearer トークン）
• モデルID：Llama-4-Maverick-17B-128E-Instruct-FP8 / Llama-4-Scout-17B-16E-Instruct-FP8 / Llama-3.3-70B-Instruct / Llama-3.3-8B-Instruct（API 上はいずれも 128k 文脈）

📌 正確性のための注記：Llama API は本稿執筆時点でプレビュー提供（ウェイトリスト制）です。モデルID・エンドポイント・パラメータは更新されうるため、最新は必ず 公式ドキュメント で確認してください。本稿のコードは構造を示すものです。

TypeScript（OpenAI SDK をそのまま使う）

// scripts/llama-quickstart.ts
import OpenAI from "openai";

// Llama API は OpenAI 互換。baseURL を /compat/v1 に向け、鍵を差し替えるだけ。
const client = new OpenAI({
  apiKey: process.env.LLAMA_API_KEY,
  baseURL: "https://api.llama.com/compat/v1/",
});

const completion = await client.chat.completions.create({
  model: "Llama-4-Maverick-17B-128E-Instruct-FP8",
  messages: [
    { role: "system", content: "あなたは事実の正確さを最優先する技術アシスタントです。推測は推測と明示します。" },
    { role: "user", content: "Llama 4 Scout の文脈長を一文で。" },
  ],
});

console.log(completion.choices[0]?.message.content);

Python（同形）

# pip install openai
import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["LLAMA_API_KEY"],
    base_url="https://api.llama.com/compat/v1/",
)

resp = client.chat.completions.create(
    model="Llama-4-Scout-17B-16E-Instruct-FP8",
    messages=[{"role": "user", "content": "MoE を3行で説明して"}],
)
print(resp.choices[0].message.content)

「OpenAI 互換」が効くのは、プロバイダ切り替えのコストがほぼゼロになる点です。プロトタイプは Llama API、本番は Bedrock、ローカル検証は Ollama——baseURL と model を変えるだけで同じコードが回ります。この“差し替え可能性”こそ、ベンダーロックインを嫌う人が Llama を選ぶ実利です。

使い方B：AWS Bedrock（本番・フルマネージド）

既存スタックが AWS なら、Bedrock が最短で本番品質です。GPU 調達も MLOps も不要で、IAM・VPC・監査ログ・課金が AWS に統合されます。Llama は Bedrock の Converse API（モデル横断の統一インターフェース）で叩けるため、Claude と Llama をワンコードで差し替えられます。

• モデルID（基盤モデル）：meta.llama4-scout-17b-instruct-v1:0 / meta.llama4-maverick-17b-instruct-v1:0
• クロスリージョン推論プロファイル（可用性向上・推奨）：us.meta.llama4-scout-17b-instruct-v1:0 / us.meta.llama4-maverick-17b-instruct-v1:0
• 文脈長（Bedrock 実効）：Scout 約 3.5M / Maverick 1M（公式記載・今後拡大予定）

本番品質の最小実装（型安全・回復性・可観測性）

“動く”コードと“本番で落ちない”コードの差は、境界の検証・リトライ・トークン課金の可視化にあります。

# llama_bedrock.py — Bedrock 経由で Llama 4 を本番品質で叩く
import logging
import boto3
from botocore.config import Config

logger = logging.getLogger("llama")

# 認証はIAMロール/環境に委譲（鍵をコードに置かない＝CLAUDE.md準拠）。
# リトライは指数バックオフ。スロットリング(429)・一時障害を正常系として吸収する。
_bedrock = boto3.client(
    "bedrock-runtime",
    region_name="us-east-1",
    config=Config(retries={"max_attempts": 4, "mode": "adaptive"}, read_timeout=60),
)

# クロスリージョン推論プロファイル（us. 接頭辞）で可用性とスループットを底上げ。
MODEL_ID = "us.meta.llama4-scout-17b-instruct-v1:0"


def ask_llama(system: str, user: str, *, max_tokens: int = 1024) -> str:
    """単発の質問応答。Converse API はモデル非依存なので Claude へも一行で差し替え可能。"""
    resp = _bedrock.converse(
        modelId=MODEL_ID,
        system=[{"text": system}],
        messages=[{"role": "user", "content": [{"text": user}]}],
        inferenceConfig={"maxTokens": max_tokens, "temperature": 0.2, "topP": 0.9},
    )
    # 可観測性：トークン課金を構造化ログに残す（本文＝PIIは出さない）。
    usage = resp["usage"]
    logger.info(
        "llama.converse",
        extra={"in_tokens": usage["inputTokens"], "out_tokens": usage["outputTokens"], "model": MODEL_ID},
    )
    return resp["output"]["message"]["content"][0]["text"]

ストリーミング（体感レイテンシを削る）

対話 UI では、全文を待たずトークンを逐次表示するだけで体感が一変します。Converse はストリーミング版を持っています。

def stream_llama(system: str, user: str):
    """生成を逐次 yield。UI 側はそのまま流し込めば“タイプしている”体験になる。"""
    stream = _bedrock.converse_stream(
        modelId=MODEL_ID,
        system=[{"text": system}],
        messages=[{"role": "user", "content": [{"text": user}]}],
        inferenceConfig={"maxTokens": 1024, "temperature": 0.2},
    )
    for event in stream["stream"]:
        if delta := event.get("contentBlockDelta"):
            yield delta["delta"]["text"]

💡 Converse API を選ぶ理由：InvokeModel はモデルごとに入出力 JSON 形状が違います。Converse はモデル横断で同一形状。だから「Llama でコスト、難所だけ Claude」を条件分岐ひとつで切り替えられ、ベンダー比較や A/B が一気に楽になります。

使い方C：セルフホスト / ローカル（所有して動かす）

データを外に出せない、原価を1リクエスト単位で削りたい、微調整したい——所有して動かすなら3択です。

Ollama（ローカル開発・PoC・データ非送出）

ローカルで ollama を立てれば、ネットにデータを出さずに Llama が動きます。ollama は OpenAI 互換サーバ（http://localhost:11434/v1）も兼ねるので、本番コードのまま検証できます。

# テキストの常用（70B・枯れていて扱いやすい）
ollama run llama3.3

# Llama 4 Scout：109B MoE / 17B active（約 67GB）
ollama run llama4:16x17b

# Llama 4 Maverick：400B MoE / 17B active（約 245GB・要大容量メモリ）
ollama run llama4:128x17b

// 本番コードを一切変えず、ローカル Ollama に向けて検証する
import OpenAI from "openai";
const local = new OpenAI({ baseURL: "http://localhost:11434/v1", apiKey: "ollama" });
const r = await local.chat.completions.create({
  model: "llama3.3",
  messages: [{ role: "user", content: "RAG のチャンク戦略を3点で" }],
});
console.log(r.choices[0]?.message.content);

vLLM（高スループットな自前サーブ）

大量・低レイテンシを自前で捌くなら vLLM。OpenAI 互換エンドポイント（:8000/v1）を立て、テンソル並列で複数 GPU に分散します。

# Scout を 8 GPU にテンソル並列で配置し、長文脈を許可してサーブ
vllm serve meta-llama/Llama-4-Scout-17B-16E-Instruct \
  --tensor-parallel-size 8 \
  --max-model-len 1000000

transformers（微調整の基盤・研究）

重みに直接触れて fine-tune したい・内部を調べたいなら transformers。v4.51.0 以降が必要で、Llama 4 専用クラスを使います。

# Maverick は 8GPU 構成が前提（torchrun --nproc-per-instance=8 script.py）
from transformers import AutoProcessor, Llama4ForConditionalGeneration
import torch

model_id = "meta-llama/Llama-4-Scout-17B-16E-Instruct"
processor = AutoProcessor.from_pretrained(model_id)
model = Llama4ForConditionalGeneration.from_pretrained(
    model_id,
    attn_implementation="flex_attention",  # 長文脈を効率的に処理
    device_map="auto",
    torch_dtype=torch.bfloat16,
)

実務パターン：どの場面でどう使うか

公式は「動かし方」までしか書きません。ここからは実際の案件でどう効かせるかを、Vercel AI SDK（このサイトの AI 群の中心スタック）で示します。鍵は出力を型で縛ることです。LLM の生出力は信頼境界の外側——Zod で parse して初めて安全になります（型安全の徹底は TypeScript 型安全の記事 に詳述）。

パターン1：型安全な構造化抽出（請求書・帳票・問い合わせ）

「非構造テキスト → 構造化JSON」は Llama の最頻出ユースケースです。Maverick の安さで大量に回し、Zod スキーマで境界検証します。

// lib/extract-invoice.ts — Llama 4 で型安全に構造化抽出する
import { bedrock } from "@ai-sdk/amazon-bedrock";
import { generateObject } from "ai";
import { z } from "zod";

// 出力の“あるべき形”を単一の真実源として宣言する。
const InvoiceSchema = z.object({
  vendor: z.string().min(1),
  total: z.number().nonnegative(),
  currency: z.enum(["JPY", "USD", "EUR"]),
  issuedAt: z.string().date(), // YYYY-MM-DD
  lineItems: z.array(z.object({ name: z.string(), amount: z.number() })).max(200),
});

export async function extractInvoice(text: string) {
  const { object, usage } = await generateObject({
    model: bedrock("us.meta.llama4-maverick-17b-instruct-v1:0"),
    schema: InvoiceSchema, // ← LLM 出力はここで検証される。形が違えば例外で弾く
    system: "請求書テキストから構造化データのみ抽出する。値を推測・捏造しない。",
    prompt: text,
  });
  // object は InvoiceSchema 準拠が“型レベルで”保証された安全な値。
  return { invoice: object, usage };
}

ポイントは、モデルが何を返そうと、InvoiceSchema を通った値しか後段に流れないこと。これで「LLM がたまに崩れた JSON を返す」問題が構造的に消えます。usage（トークン数）を返しているのは、後述のコスト可視化のためです。

パターン2：超長文脈 RAG（Scout の 10M を活かす）

Scout の長文脈は「チャンク分割を粗くできる」のが実利です。とはいえ「全部入れれば良い」わけではない——検索 → 圧縮 → 投入の RAG 設計は依然として効きます（pgvector 本番 RAG / LangChain×Pinecone を参照）。長文脈は「取りこぼしの保険」として使い、根拠の引用まで型で縛るのが筋です。

// 検索ヒットを根拠として渡し、回答 + 引用元を型で強制する
import { bedrock } from "@ai-sdk/amazon-bedrock";
import { generateObject } from "ai";
import { z } from "zod";

const Answer = z.object({
  answer: z.string(),
  citations: z.array(z.string()).min(1), // 引用ゼロを許さない＝ハルシネーション抑止
});

export async function answerWithRag(question: string, chunks: { id: string; text: string }[]) {
  const context = chunks.map((c) => `[${c.id}] ${c.text}`).join("\n\n");
  const { object } = await generateObject({
    model: bedrock("us.meta.llama4-scout-17b-instruct-v1:0"),
    schema: Answer,
    system: "提供された根拠のみで答える。根拠に無いことは『分からない』と返す。citations には使った [id] を必ず列挙。",
    prompt: `# 質問\n${question}\n\n# 根拠\n${context}`,
  });
  return object;
}

パターン3：Vercel AI Gateway でプロバイダ非依存にする

Vercel 上なら、AI Gateway 経由で "provider/model" 文字列を使うのが最も疎結合です。プロバイダSDKを直接持たず、フェイルオーバーと使用量計測を Gateway に寄せられます。

import { generateText } from "ai";

// プロバイダ非依存。Gateway 側でフォールバックや可観測性を一元管理できる。
const { text } = await generateText({
  model: "meta/llama-4-maverick", // ← 文字列を変えるだけで Claude 等にも切替可
  prompt: "オープンウェイトを選ぶ判断基準を箇条書きで",
});

その他、エージェント / tool calling（ツール実行の設計記事）、画像理解（Scout/Maverick はネイティブマルチモーダル）、入力モデレーションの一次分類器（安いモデルでゲートを作る）も、同じ「境界を型で縛る」発想で組めます。

本番運用の設計原則（型安全・冪等性・可観測性・回復性・コスト）

LLM を“動く”から“本番で稼ぐ”へ引き上げるのは、モデル選定ではなく周辺の設計です。Llama でもクローズドAPIでも、効く原則は同じです。

• 型安全（境界検証）：LLM 出力は信頼境界の外。Zod で parseしてから後段へ。any で受けない。
• 冪等性：高コスト/長時間の生成は、sha256(モデル + プロンプト + パラメータ) をジョブキーにキャッシュ。再送・連打・リトライで二重課金しない。
• 可観測性：呼び出しごとにモデルID・入出力トークン・レイテンシ・温度を構造化ログへ。「なぜこの回答だけ高コストか/崩れたか」を後から追える状態にする（PII＝プロンプト本文は出さない。OpenTelemetry 記事 参照）。
• 回復性：スロットリング・タイムアウト・一時障害を正常系として扱う。指数バックオフ＋フォールバック（Maverick → Scout → 3.3 8B、あるいは Bedrock → Llama API）で止めない（リトライ/サーキットブレーカー記事）。
• コスト効率：① モデルルーティング（簡単な分類は 8B、難所だけ Maverick）② MoE で active が小さい Llama を量側に当てる ③ 冪等キャッシュで再生成ゼロ。この3段で単価を刻む。

冪等性つきの本番ルートハンドラ（Next.js）

外部入力の検証・二重課金防止・フォールバックを1つに束ねた最小形です。

// app/api/generate/route.ts
import { NextResponse } from "next/server";
import { createHash } from "node:crypto";
import { generateText } from "ai";
import { z } from "zod";

// ① 外部入力は境界で必ず検証する（信頼境界はサーバー側）。
const Body = z.object({
  prompt: z.string().min(1).max(20_000),
  quality: z.enum(["fast", "best"]).default("fast"),
});

// ② 入力から決定的キーを作る。同じ入力＝同じ結果を返し、二重課金しない。
const keyOf = (s: string) => createHash("sha256").update(s).digest("hex");

// ③ 品質要件でモデルをルーティング（コスト最適化）。
const MODEL = {
  fast: "meta/llama-4-scout",
  best: "meta/llama-4-maverick",
} as const;

export async function POST(req: Request) {
  const parsed = Body.safeParse(await req.json());
  if (!parsed.success) {
    return NextResponse.json({ error: parsed.error.flatten() }, { status: 422 });
  }
  const { prompt, quality } = parsed.data;
  const key = keyOf(`${quality}:${prompt}`);

  const cached = await cache.get(key);
  if (cached) return NextResponse.json({ text: cached, cached: true });

  try {
    const { text, usage } = await generateText({ model: MODEL[quality], prompt });
    await cache.set(key, text);
    // usage を計測へ（トークン課金の可観測性）。PII は載せない。
    metrics.record({ model: MODEL[quality], tokens: usage.totalTokens });
    return NextResponse.json({ text, cached: false });
  } catch (err) {
    // ④ 回復性：失敗したら一段安いモデルへフォールバックして“止めない”。
    const { text } = await generateText({ model: MODEL.fast, prompt });
    return NextResponse.json({ text, degraded: true });
  }
}

sha256(入力) をキーにするだけで「ユーザーが送信を連打しても1回しか走らない」「同じ依頼はキャッシュが返る」という冪等性とコスト効率が同時に手に入ります。失敗時に安いモデルへ落とす degraded 経路が、SLO を守る最後の砦です（非同期・大量化したら SQS/Lambda の冪等処理 へ寄せます）。

ライセンスの落とし穴（商用前に必読）

Llama の商用利用は可能ですが、ライセンスは OSI 準拠の“オープンソース”ではありません。Llama 4 Community License という独自ライセンスで、踏みやすい地雷が4つあります。「無料だから自由」ではないことを、案件に入る前に必ず確認してください。

Notice 文は公式に定型があります。

Llama 4 is licensed under the Llama 4 Community License,
Copyright © Meta Platforms, Inc. All Rights Reserved.

⚖️ ここが信頼の分かれ目：受託で「Llama で安く作りました」と納品して、Built with Llama 表示も派生モデルの命名規約も知らなかった——これは事故です。オープンウェイトを商用に載せるなら、ライセンス遵守までが実装。私は案件で、この表示義務・命名規約・AUP・（必要なら）データ取扱いまでを設計に含めます。ライセンスは更新されるため、本番投入前に必ず一次情報（Llama 4 License / Acceptable Use Policy）で確認してください。

他モデルとの比較（正直版）

「結局どれを使う？」に、用途で答えます。性能の絶対値だけで選ぶと外します。

実務の意思決定はおおむねこうです。

• 重みを所有したい/微調整したい/データを外に出せない → Llama 4。
• 最高難度の推論・コーディングを任せたい → Claude（私は Claude Code を実装の主役に使っています）。
• 量で殴る前処理・抽出・分類はオープンウェイト、難所だけクローズド → 両建てが原価と品質の最適点。

ベンチの数字（Artificial Analysis 等）や各社モデルは毎月動きます。固定値で意思決定せず、自分のタスクで小さく評価してから本採用してください。

よくある質問（FAQ）

Q. Llama は商用利用できますか？ A. できます。ただし OSI の“オープンソース”ではなく Llama Community License です。700M MAU 閾値・Built with Llama 表示・派生モデル名の “Llama” 接頭辞・AUP を守る必要があります。大半の企業に 700M MAU は無関係ですが、表示と命名は普通に該当します。必ず一次情報を確認してください。

Q. 日本語は使えますか？ A. 使えます。Llama 3.x 以降は多言語性能が向上しており、Llama 4 もネイティブに多言語対応です。とはいえ「英語ほど安定はしない」場面もあるので、日本語の重要タスクは自分の評価セットで検証してから載せてください。

Q. どれくらいの GPU が要りますか？ A. Scout は単一 H100（Int4 量子化）、Maverick は単一 H100 DGX ホストが公式の目安。手元GPUが無ければ Llama API か Bedrock（GPU 不要）で始め、量が増えてから自前運用へ移すのが王道です。

Q. fine-tuning できますか？ A. できます。重みが手元にあるのがオープンウェイトの核心です。LoRA など軽量手法から始めるのが現実的。配布する場合は派生モデル名を “Llama” で始める命名規約に注意。

Q. API と自前運用、どちらが安い？ A. 少量なら API（環境構築ゼロ）。定常的に大量なら、GPU を埋めて回す自前運用が1リクエスト単価で有利になりやすい。まず API で品質と需要を確かめ、量が増えたら Bedrock 専有 or 自前へ、が損益分岐の定石です。

Q. Muse Spark が出たので Llama はやめるべき？ A. 要件次第です。重みを所有・微調整・自前運用したいなら、Muse Spark は重み非公開で要件を満たしません——本命は依然 Llama 4。Muse Spark は「もう一つのクローズドAPI」として、Claude / GPT と同じ土俵で評価する対象です。

Q. Claude と Llama、どちらを選ぶべき？ A. 最前線の推論・コーディング・エージェントは Claude、所有・微調整・データ主権・原価最適化は Llama。私は両方を Bedrock の同一 API の裏で併用し、難所は Claude・量は Llamaで組みます。二者択一ではなく使い分けが正解です。

まとめ：Llama を「所有」から「本番で稼ぐ」へ

Llama の本質は、性能の数字ではなく「重みを所有して、改造し、自分の環境で動かせる」ことにあります。だからこそ、データ主権・微調整・原価・ロックイン回避が要件の案件で、クローズドAPIにはできない選択肢になります。

実装の道筋はシンプルです。

1. Llama API（OpenAI 互換） でまず賢さを確かめる（baseURL 差し替えだけ・GPU 不要）。
2. 本番は AWS Bedrock の Converse API へ（Claude と一行で差し替え可能）。量が増えたら vLLM / 専有へ。
3. 型安全・冪等性・可観測性・回復性・コストを設計に織り込み、ライセンス遵守（Built with Llama・命名・AUP）まで実装する。

ここまでやって初めて、デモではなく「顧客の制約（データを出せない・原価を削りたい・特化させたい）で落ちない」プロダクトになります。そして、ここが一番伝えたい点ですが——モデルを繋ぐだけのデモは誰でも作れますが、オープンウェイトとクローズドAPIを使い分け、ライセンスと原価とデータ主権まで設計するのは、実運用で判断を重ねた数がそのまま品質になります。

私は AWS Bedrock × Vercel AI SDK を土台に、Llama を含む生成AIシステムを本番運用しています。オープンウェイト/クローズドの選定、RAG、エージェント、コスト最適化、ライセンス対応まで一気通貫でお考えなら、実績をご覧のうえ、お気軽にご相談ください。一人 × 生成AIで、PoC から本番運用まで、速く・安く・安全に作ります。

出典・公式リソース

• 公式サイト：llama.com — モデル一覧・ダウンロード・ドキュメント
• Llama 4 発表（Meta AI Blog）：The Llama 4 herd — Scout/Maverick/Behemoth のスペック・MoE・マルチモーダル
• Llama Developer Docs：overview / models — Llama API のモデルID・エンドポイント・OpenAI 互換
• Hugging Face（Meta 公式）：meta-llama — 重み配布・transformers 利用
• AWS Bedrock（Meta）：Meta's Llama in Amazon Bedrock — Bedrock のモデルID・Converse API
• ライセンス：Llama 4 Community License / Acceptable Use Policy — 700M MAU・Built with Llama・命名規約・AUP
• LlamaCon 2025 まとめ：Everything we announced at LlamaCon — Llama API の発表
• Muse Spark（参考）：Introducing Muse Spark — Meta の方針転換（プロプライエタリ）

※ バージョン・モデルID・文脈長・料金・ライセンスは更新されます。実装前に必ず一次情報を確認してください。本稿の数値（Scout 17B active/16 experts/総109B/最大10M、Maverick 17B/128 experts/総400B、Bedrock 実効 Scout 約3.5M・Maverick 1M、Llama API 128k など）は本稿執筆時点（2026年6月）の公式情報に基づきます。This site is "Built with Llama"–aware: when you ship a product containing Llama, display the required attribution.