PLaMo 3.0 Prime を試してみた

はじめに

こんにちは、クラスメソッド製造ビジネステクノロジー部の森茂です。

2026-06-22 に Preferred Networks（PFN）から、フルスクラッチで作られた国産大規模言語モデル PLaMo 3.0 Prime の正式リリースが発表されました。奇しくも同じ日に Sakana AI の Fugu も GA リリースされていて、国産 LLM が二つ揃って表に出てきた一日になりました。

このうち PLaMo 3.0 Prime は、国産フルスクラッチで初めて Reasoning（長考）モードを乗せたモデルとして紹介されています。OpenAI 互換 API、256K の長いコンテキスト、Tool calling 対応、医療・法律ドメインのベンチで上位スコアを主張ととっても気になる素材が揃っています。

本記事では、Standard プランで契約して API Key を発行するところから、OpenAI 互換 SDK で Reasoning OFF / ON の挙動を実機で観察、Claude Code から呼べるところまでを 1 日で回した記録を残しています。

PLaMo 3.0 Prime とは何者か

PLaMo 3.0 Prime は、Preferred Networks（PFN）が独自開発した国産生成 AI 基盤モデルです。PFN が継続的に出している PLaMo シリーズの最新作で、Reasoning ありの「長考モード」と、即応性重視の Non-Reasoning モードを使い分けられる構成になっています。

公式ブログでは、評価軸として IFBench / JFBench / MT-bench / Japanese MT-bench / BFCL v4（ツール利用）/ BrowseComp-Plus / LongBench v1, v2 / AIME 2024 / GPQA-Diamond / LiveCodeBench / lawqa_jp / MedRECT / 医師国家試験 / HELM Safety といった、英語と日本語が混在する幅広いベンチを並べています。比較対象として置かれているのが、同価格帯では Qwen3.6-27B / gpt-oss-120b / GPT-5.4 Mini / Claude Haiku 4.5、上位帯では DeepSeek V4 Pro / GPT-5.5 Pro という顔ぶれです。

提供形態は PLaMo Platform 経由のクラウド API か、オンプレへの導入。PLaMo 3.0 Prime 本体の重みは公開されていません。

モデル仕様と料金プラン

API 経由で使うときに必要な仕様は次のとおりまとまっています。コンテキストや出力上限は公式 API リファレンスで確認した値です。

料金は 2026-06-22 時点で 3 プラン用意されていて、自分は今回 Standard を選んで触りました。

出力 1M トークン 250 円という単価は、海外の同価格帯モデルと比べてもかなり手が届きやすい印象です。さらに 2026-07-31 までの GA リリースキャンペーンとして、新規登録するだけで 1000 万トークン相当のクレジットがもらえる扱いになっていました。今回の検証は実質この枠で動いているので、これから触ってみる方も最初の数日は気軽に試せると思います。Standard プランの利用枠の見え方については後述します。

同価格帯モデルとの位置づけ

公式ブログが並べている同価格帯（Qwen3.6-27B / gpt-oss-120b / GPT-5.4 Mini / Claude Haiku 4.5）は、いずれも海外勢が中心です。PFN 自身の主張としては「指示追従、対話、ツール使用、医療領域で、同価格帯と匹敵もしくは上回る」「HELM Safety では海外勢と同等以上」という言い方で、具体的な数値は記事中の図でグラフ表示されています。

自分の側でベンチを再走したわけではないので、ここでは図を再掲しない形にしました。本記事は API を OpenAI 互換 SDK で素直に叩いて、Reasoning モードがどんな挙動になるかを観察するスコープで割り切っています。客観的な数値比較が知りたいときは公式ブログを直接参照してください。

国産フルスクラッチ LLM という文脈で言うと、医療（医師国家試験 / MedRECT）と法律（lawqa_jp）の日本語ベンチで上位主張があるのが、海外勢にはない切り口かなと思いました。

触ってみる Console 契約から API Key 発行まで

PLaMo Platform Console（console.platform.preferredai.jp）にアクセスするとサインアップ画面が出ます。Standard プランで契約を進めると、API Key を発行する画面に到達します。発行直後の画面でしか full key が見えない仕様だったので、その場でコピーして手元の .envrc に書き込みました。

Playground は plamo.preferredai.jp/chat から開けます。チャット UI 上で Reasoning ON / OFF を切り替えられるので、API を叩く前にここでざっと挙動を見ておくと、後の検証がスムーズです。

ここからの検証は、PLAMO_API_KEY を環境変数で渡せる状態を前提に進めます。

OpenAI 互換 API で叩いてみる

PLaMo Platform は OpenAI 互換 API なので、Python の openai パッケージから base_url を差し替えるだけで叩けます。実機で挙動を見るために、軽い質問を 1 件と、軽い推論を 1 件、それぞれ Reasoning OFF / Reasoning ON で投げる小さなスクリプトを書きました。

from openai import OpenAI

client = OpenAI(
    base_url="https://api.platform.preferredai.jp/v1",
    api_key=os.environ["PLAMO_API_KEY"],
)

# Reasoning OFF（default）
resp = client.chat.completions.create(
    model="plamo-3.0-prime",
    messages=[{"role": "user", "content": "..."}],
)

# Reasoning ON（long-think）
resp = client.chat.completions.create(
    model="plamo-3.0-prime",
    messages=[{"role": "user", "content": "..."}],
    extra_body={"reasoning_effort": "medium"},
)

プロンプトは次の 2 種類で投げました。

• light_question: 「PLaMo 3.0 Prime というモデルが何者なのか、50 字程度で読者に紹介してください。」
• light_reasoning: 「リンゴ 3 個とミカン 4 個を 2 人で分けます。1 人あたり何個になるかと、公平な分け方の提案を 100 字以内で答えてください。」

reasoning_effort の値については公式ドキュメントに none と medium の 2 値しか書かれていません。せっかくなので、よくある low / medium / high の感覚で high と low も順に試してみたら、両方とも HTTP 422 で返ってきました。

{
  "detail": [
    {
      "type": "literal_error",
      "loc": ["body", "reasoning_effort"],
      "msg": "Input should be 'none' or 'medium'",
      "ctx": { "expected": "'none' or 'medium'" },
      "input": "high"
    }
  ]
}

OpenAI や Anthropic が low / medium / high の 3 段階を採るのに慣れていると、いきなり high を狙いたくなりがちですが、PLaMo は none と medium の 2 値だけを厳密に validate する作りでした。low も high も同じエラーメッセージで弾かれるので、指定できる値が公式に明示されている分、迷いどころは少ないとも言えます。

Reasoning OFF / ON の 2 通りで実機を回した結果が次の表です。

light_question で completion_tokens が 60 → 754 と約 12 倍、light_reasoning では 42 → 1454 と約 35 倍に膨らんでいます。Reasoning ON にすると、可視の応答テキスト以外に内部で消費されるトークンがそれだけ増える、というイメージです。

レイテンシのほうも、Reasoning ON で 6〜17 倍にスケールしました。長考分は当然そのまま待ち時間になります。

ここで気になったのが、usage フィールドの構造です。OpenAI の Responses API などでは usage.completion_tokens_details.reasoning_tokens のようなフィールドで「長考に何トークン使ったか」が見えるようになっていますが、PLaMo の場合は次のとおり completion_tokens_details が null で返ってきます。

{
  "completion_tokens": 754,
  "prompt_tokens": 33,
  "total_tokens": 787,
  "completion_tokens_details": null,
  "prompt_tokens_details": null
}

completion_tokens のなかに長考分が丸め込まれている形で、内訳までは見えません。Standard プランで課金されるのは出力 250 円 / 1M tok 全体なので、Reasoning ON で出力枠の消費が早くなる点は意識しておいたほうがよさそうです。

応答の内容も触れておきます。light_question では Reasoning OFF が約 135 字を返してきて、50 字目安からはみ出していました。一方 Reasoning ON は 38 字で「PLaMo 3.0 Prime は、最新の大規模言語モデルで、高度な自然言語処理を実現します。」と、字数制約をきちんと守って返してきました。長考の結果として「指示遵守の精度が上がる」現象が観測できたのは良いですね。

light_reasoning では、Reasoning OFF が「1 人あたりリンゴ 1.5 個、ミカン 2 個、計 3.5 個」と要素ごとの数を律儀に並べてきたのに対し、Reasoning ON は「合計 7 個で 1 人 3.5 個。公平案：リンゴ 2 個 + ミカン 1 個を A、リンゴ 1 個 + ミカン 3 個を B、残り 1 個は半分に切るか交代で」と、合計だけ先に言ってから公平案にひと工夫を加えるアプローチでした。応答スタイルそのものが変わってくる感触があります。

長考モードで踏み込む

軽い質問だけだと Reasoning ON の効き目が見えにくいので、コード生成で踏み込んでみます。題材は「進化的アルゴリズム（遺伝的アルゴリズム）で文字列 HELLO PLAMO を進化させる Python スクリプト」をお願いするもの。Reasoning OFF と ON で同じプロンプトを 1 回ずつ投げて、生成されたコードを並べてみます。

レイテンシは 3.4 倍、出力トークンは 4.5 倍ほどに伸びました。それより気になったのが、生成されたコードの構造です。

Reasoning OFF のほうは、ざっくりと動くものをコンパクトに返してきます。ルーレット選択でフィットネス比例の親選択、一点交叉、突然変異率 0.05、エリート保存ありの構成。説明文も短くまとまっていて、初見でもすぐ読める分量です。

ただし、よく見ると population という名前の関数と、その関数を呼び出して受ける同名の変数 population が evolve() のなかで衝突しています。Python の名前解決の都合で、関数内に population = ... という代入が 1 行でもあると population は関数全体を通じてローカル変数として束縛されます。右辺の population(POPULATION_SIZE, target_len) を評価しようとしたタイミングではまだ代入が走っていないので、手元で動かすと初回からそのまま UnboundLocalError で止まります。実害として完成度に欠ける実装で、レビューで指摘したくなるラインですね。

def population(size, length):
    return [random_individual(length) for _ in range(size)]

def evolve():
    target_len = len(TARGET)
    population = population(POPULATION_SIZE, target_len)  # <- ここで関数 -> 変数 にすり替わる
    ...

Reasoning ON のほうは、構造をひと回り丁寧に組み直してきます。ルーレットの代わりにトーナメント選択（k=2 のサンプリングで適合度の高い方を採用）、一点交叉で 2 つの子を返す、関数ごとに日本語の docstring を書く、20 世代ごとに進捗ログを出す、といった具合です。先ほどの population 関数 / 変数の名前衝突は起こりません。

def create_individual():
    """ランダムな個体（文字列）を生成"""
    return ''.join(random.choice(alphabet) for _ in range(len(target)))

def tournament_selection(pop, fit, k=2):
    """トーナメント方式で親を 2 体選ぶ"""
    selected = random.sample(list(zip(pop, fit)), k)
    selected.sort(key=lambda x: x[1], reverse=True)
    return selected[0][0], selected[1][0]

長考分のコストを掛けると、コードがいきなり別物に化けるというよりは、構造的な選択肢のなかから一段安全な方を選ぶ、という挙動に見えます。

Tool calling も軽く試しておきました。get_current_weather という天気取得モック tool を定義して、「東京の今の天気を摂氏で教えてください」を Reasoning OFF / ON で投げてみます。

OFF / ON どちらも finish_reason: tool_calls で正しく tool を呼びにきて、引数も {"city": "Tokyo", "unit": "celsius"} でぴったり同じでした。OpenAI 互換の tools / tool_choice パラメータがそのまま動く、というのが実機で確認できた感じです。Reasoning ON のほうが completion_tokens が 2.2 倍ほど（58 → 128）に膨らんでいたので、tool 1 回呼ぶだけでも長考は走っているようです。

Claude Code から PLaMo を呼ぶ

ここまでで OpenAI 互換 API として PLaMo が素直に動くことが分かったので、エージェント駆動側にも乗せてみます。題材は claude-code-router（CCR）です。

CCR は Claude Code 用の OpenAI 互換ルータで、Anthropic 形式のリクエストを受けて、内部で OpenAI 形式に変換して任意の provider に転送してくれます。~/.claude-code-router/config.json の Providers 配列に PLaMo を追加するだけで完了します。

{
  "Providers": [
    {
      "name": "plamo",
      "api_base_url": "https://api.platform.preferredai.jp/v1/chat/completions",
      "api_key": "${PLAMO_API_KEY}",
      "models": ["plamo-3.0-prime"],
    },
  ],
}

transformer セクションは無くても動きました。CCR は OpenAI 互換 API なら自動判別してくれる挙動のようです。Sakana provider など他の OpenAI 互換 provider が既に同居しているなら、その隣に並べる形で追加すれば OK です。

設定を反映するには ccr restart。ログには次のように plamo provider registered が記録されていれば成功です。

{"level":30,"msg":"plamo provider registered"}

疎通確認は curl で十分です。Claude Code が普段使う Anthropic 形式の /v1/messages を叩いてみると、CCR が OpenAI 形式に変換して PLaMo へ送り、戻ってきた OpenAI レスポンスを Anthropic 形式に戻して返してくれます。

curl -s -X POST http://127.0.0.1:3456/v1/messages \
  -H "Content-Type: application/json" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "plamo,plamo-3.0-prime",
    "max_tokens": 200,
    "messages": [{"role": "user", "content": "PLaMo 3.0 Prime を 30 字以内で紹介してください。"}]
  }'

次のようなレスポンスが返ってきます（一部抜粋）。

{
  "id": "chatcmpl-...",
  "type": "message",
  "model": "plamo-3.0-prime",
  "role": "assistant",
  "stop_reason": "end_turn",
  "usage": {
    "input_tokens": 24,
    "output_tokens": 12,
    "cache_read_input_tokens": 0
  },
  "content": ["高性能AIアシスタント、PLaMo3.0Prime。"]
}

字数制約をきちんと守った 18 字の応答。usage は CCR が Anthropic 形式に揃えて返してくれているので、Claude Code 本体から見ると普段の Claude モデルとほぼ同じインターフェイスです。ccr code で起動した Claude Code から /model plamo,plamo-3.0-prime で固定すれば、そのままエージェント駆動に使えます。

Codex CLI と Hermes Agent についても短く触れておくと、Hermes は profile を 1 つ切って provider: custom 形式で base_url と api_key を直接書けばそのまま PLaMo に接続できました。Codex CLI は v0.141.0 が wire_api = "responses" 専用に絞られていて、Chat Completions しかない PLaMo は直接接続できない状態でした。詳細は気になっていることの章にまとめています。

いま気になっていること

触ってみて、ぱっと思いついた気になりどころを箇条書きで残します。

• usage.completion_tokens_details が null で返ってくる仕様。長考分のトークン内訳が見えない状態なので、コスト見積もりは completion_tokens 合算で見るしかない。今後の API 拡張で reasoning_tokens 相当が露出してくれると、Reasoning モードの課金透明性がぐっと上がります
• Reasoning ON 時のレイテンシ振れ幅。今回は軽い質問で 22.69s、軽い推論で 43.11s、コード生成で 90.84s と、プロンプトの重さに素直にスケールしました。256K のコンテキストをフルに使ったときの実効レイテンシは別途見ておきたいところです
• Console の利用量表示がリアルタイムではないこと。今回の検証中に「あと何トークン消費したか」をその場で追いたかったのですが、コンソールの数字は時間差で更新される作りらしく、検証セッション直後には反映されませんでした。課金画面の即時性は今後の改善に期待したいところです
• 公式ベンチ主張の追検証。医療（医師国家試験 / MedRECT）と法律（lawqa_jp）あたりは、自分の手元で軽く確認したい題材です
• Hermes Agent 経由の常駐運用。provider: custom + api_mode: chat_completions で接続自体は通ったので、Slack や cron 経由で PLaMo を呼び出す常駐エージェントに乗せる、というのは別記事で書きたいネタです
• Codex CLI 経由の接続。0.141.0 で wire_api: responses 専用に絞られていて、Chat Completions しかない PLaMo は直接繋がりませんでした。0.140 系へのダウングレードか LiteLLM proxy で迂回するかは別記事で追いかけたいテーマです

おわりに

PLaMo 3.0 Prime を Standard プランで触ってみました。OpenAI 互換 API として素直に動き、Reasoning ON で指示遵守やコード品質が変わる挙動、Tool calling もきちんと動くところまでが、1 日触った範囲で確認できました。Console 側の体験もスムーズで、フルスクラッチ国産 LLM がここまで「普通に使える」状態で世に出てきたのは、開発者としてありがたいですね。

エージェント駆動の側は、CCR 経由で Claude Code に乗せるところと、Hermes Agent profile に乗せるところは、それぞれ短い設定で素直に通りました。Codex CLI は 0.141.0 で responses API 専用に絞られたあたりに当たって、こちらだけ続編候補として持ち越しです。Reasoning モードのコスト感や、256K コンテキストの実効レイテンシも、別記事で深掘りしてみたいテーマです。

国産 LLM が二発同日にリリースされたという 2026-06-22 は、振り返ると界隈にとっていい節目だったのかもしれません。

参考リンク

• PLaMo 3.0 Prime をリリースしました（Preferred Networks Tech Blog）
• 国産生成 AI 基盤モデル PLaMo 3.0 Prime を正式リリース（Preferred Networks プレスリリース）
• PLaMo Platform Console
• PLaMo Playground
• PLaMo Platform API リファレンス
• claude-code-router（GitHub）