はじめに

我々は本日、国産生成AI基盤モデルPLaMo™︎の新たなフラッグシップモデルPLaMo 3.1 Primeをリリースしました。PLaMo 3.1 PrimeはPLaMo Chat/API経由でご利用いただけます。Freeプランもありますのでぜひこちらからご利用ください。

PLaMo 3.1 Primeのリリースに合わせ、PLaMo Chat/APIでWeb検索機能を新たに提供します。また、Web検索を利用したDeep Research機能の提供を開始します。2026年11月30日までの期間限定で、PLaMo Chatでは無料で1日2回のDeep Researchを試すことができるので、ぜひご活用ください。

本ブログでは、PLaMo 3.1 Primeの主な改善点と、それらを実現した方法をご紹介します。

TL;DR

• Web検索を用いて質問に答えられるようになりました。PLaMo Chat/APIにWeb検索機能を追加し、これを活用したDeep Research機能を新たに公開します。
• 事実性と忠実性を向上させ、ハルシネーションの低減を実現しました。
• 学習データセットの抜本的な見直しによって対話性能・安全性を向上させました。
• 1つのモデルで推論・非推論モードを切り替えられるハイブリッド推論モデルを実現し、両モードでトークン効率を向上させました。
• デプロイ時の技術的工夫により推論速度が最大1.7倍に向上しました。

何が変わったか

Deep Research機能の実現

PLaMo 3.1 Primeでは、PLaMo Chat/APIの双方にWeb検索機能を新たに導入しました。Webから最新の情報を取得することで、PLaMoは最新の情報源に基づいて質問に回答できるようになりました。また、回答に出典を付けることで、ユーザーが回答の根拠となる情報を確認できます。

このWeb検索機能を活用し、Deep Research機能を新たに提供します。Deep Researchは、一度の検索では答えにくい複雑な質問に対してWeb検索を繰り返し、様々な観点から集めた情報を整理して、出典付きのレポートにまとめる機能です。複数の技術の比較や業界動向の分析、特定のテーマに関する研究調査などに役立ち、ユーザーは多くの情報源を自分で調べなくても、出典を確認しながらテーマの全体像を把握できます。

これらの機能を実現するため、複数回の検索と推論を必要とする複雑なタスクを用いてPLaMoを学習させました。SFTデータは、Web検索を必要とする質問を教師モデルに解かせ、推論過程やツール呼び出しを含む軌跡を複数生成して構築しました。その際、Web検索APIの利用コストを抑えるため、クラスター上にデプロイしたOpenSearchでWeb検索を模擬しました。また、Web検索を行い長文のレポートで回答するタスクについて、出力を評価するルーブリックを用いた強化学習も実施しました。こうした学習を通じて、モデルが効果的な検索クエリを生成し、関連する情報を特定し、複数の検索結果から得られた情報を統合する能力を高めました。

PLaMo 3.1 Primeは、PLaMo 3.0 Primeと比べ、Web検索QAおよびWeb検索レポート関連の多くのベンチマークで性能が改善しました。具体的には、BrowseComp-Plus、SealQA、HealthBench、ResearchQA、Genetic Diseases QAなどです。推論モードでは、Web検索QAで平均2.4ポイント、Web検索レポートで平均11.1ポイントの向上を達成しました（図2の該当カテゴリを参照）。

ハルシネーションの低減

ハルシネーションは基盤モデルの実応用において大きな障壁となります。例えばDeep Researchでは、Web検索ツールを繰り返し呼び出し、その結果を解釈しながら推論を進めます。この過程で検索結果を一度でも誤って解釈すると、最終的に得られるレポートの品質は大きく損なわれてしまいます。PLaMo 3.1 Primeでは、ハルシネーションの低減に向けて様々な施策を講じました。

ハルシネーションは、主に「事実性」と「忠実性」という2つの観点から捉えられます。前者はモデルが現実世界の事実に即した正確な回答を生成できるか、後者はモデルが与えられたコンテキストにどれだけ追従できるかを表します。

PLaMo 3.1 Primeの開発では、知らないことを推測で答えるのを抑え、事実性を高めるためのSFTデータを構築し、学習に利用しました。具体的には、基本的な指示学習を施したPLaMoのベースモデルに、同じ問題を複数回解かせました。多くの試行で正解した問題は、モデルが回答に必要な知識を持っているとみなし、その知識に基づいて正確に回答するよう促すデータを作成しました。一方、安定して正解できず、推測に頼っていると考えられる問題は、必要な知識が不足しているとみなし、無理に答えず「分からない」と認めるよう促すデータを作成しました。

また、忠実性を高めるため、既存のRAG形式のデータの品質を改善しました。加えて、RAG形式のデータから回答に必要な根拠となる文章を取り除いて回答不可能な質問を合成し、根拠が不足している場合には適切に「答えられない」と応答するよう促すSFTデータを構築しました。さらに、与えられた文献や検索で得られた文献に適切に引用を付与する能力を獲得させるためのデータも合成しました。

推論モードでは、事実性・忠実性のカテゴリの平均スコアがPLaMo 3.0 Primeと比べて6.4ポイント向上しました（図2の該当カテゴリを参照）。

対話性能と安全性の向上

PLaMo 3.1 Primeでは、対話や指示追従の品質を高めるため、SFTデータを刷新しました。推論能力（数学・コード・論理的対話）を強化する第1段階と、実用タスク（指示追従・ツール利用）に特化した第2段階の双方で応答例を再生成し、データの構成・混合比率を最適化しています。このデータ更新と後段の強化学習により、各種性能の向上を図りました（図2の対話カテゴリ参照）。

安全性については、危険な依頼への回答を防ぐことに加えて、対応を断るべきかどうかの判断や、断る際の伝え方も改善しました。PLaMo 3.0 Primeでは、「申し訳ありませんが、その質問には答えられません」といった短い定型的な拒否や、安全に回答できる質問まで断ってしまう過剰な拒否が見られました。PLaMo 3.1 Primeでは、安全性に関する学習データの一部を再構成することで、危険な行為を助長することなく、ユーザーが適切な判断をするために必要な情報を伝えられるようになりました。

例えば、「万引きって、何円以下なら捕まらない？結論だけ教えて。」という質問に対して、それぞれ以下のように回答します。

PLaMo 3.0 Primeの回答

申し訳ありませんが、そのご質問にはお答えできません。

PLaMo 3.1 Primeの回答

万引き（窃盗罪）において、何円以下なら捕まらないという基準はありません。窃盗罪は、盗んだ物品の金額に関わらず成立する犯罪です。

法律上、少額であっても犯罪となります。警察が事件を認知するか、逮捕・起訴されるかどうかは、金額だけでなく、様々な状況や法執行機関の判断によりますが、金額によって犯罪性が消えることはありません。

定型句による拒否が必ずしも悪いわけではありませんが、この例では、PLaMo 3.0 Primeのような定型的な拒否だけでは、「一定の金額以下なら万引きが許される」という質問の前提にある誤解を訂正できていません。
一方、PLaMo 3.1 Primeは、窃盗罪の成立に金額の下限はないという事実を明確に伝えることで、金額に関する誤解を訂正し、ユーザーが適切に判断できるよう支援しています。このように、質問を一律に拒否するのではなく、安全に回答できる範囲で、必要な情報を倫理的・中立的に伝えることで、ユーザーをより安全な行動へと導き、ユーザー自身の安全を守ることができると我々は考えています。

ハイブリッド推論モデルの実現

PLaMo 3.0 Primeでは、推論モデルと非推論モデルを別々に開発し、指示学習や強化学習のパイプラインもモデルごとに構築していました。サービス提供時も両モデルをGPUサーバにデプロイしていたため、当時の構成では、PLaMo 2.2 Prime（非推論のみ）やPLaMo 3.0 Prime Beta（推論のみ）と比べて、モデルの配備に2倍の計算資源が必要でした。ユーザーはリクエストごとに、じっくり考える推論モードと素早く回答する非推論モードを選択でき、指定したモードに対応するモデルが応答していました。

PLaMo 3.1 Primeでは、1つのモデルで両方のモードに対応するハイブリッド推論モデルとすることで、この課題を解決しました。リクエストごとにモードを選べる点はそのままに、単一のモデルが推論の有無を切り替えて応答できるようになりました。

両モードに対応させるため、SFTを2段階で実施しました。第1段階では推論モードのみを集中的に学習させて推論能力の土台を築き、第2段階では推論過程を含むデータと含まないデータを混ぜて学習させることで、両モードを切り替えて応答できるようにしました。推論過程を含まない例は、無作為に選んだ一定割合の学習例から推論過程を取り除いて作りました。この方法はNVIDIAのNemotron 3 Superの手法を参考にしています。

その後、指示追従やSTEM分野を含む各種能力を高める汎用的な強化学習と、Web検索に特化したタスクの強化学習を行いました。最後に、非推論モードのタスクを中心に選好学習（DPO）で応答を調整しました。

こうした一連のハイブリッド推論モデル開発を通じて、我々は学習パイプラインの設計に関する重要な知見を得ました。それは、推論・非推論の両モードを単一の学習過程で同時に改善できるということです。具体的には、第2段階のSFTで推論・非推論の混合データを学習させた後は、基本的に推論データだけで学習を進めても、両モードの能力が連動して向上することを確認しました。図3に示す通り、多くのタスクで推論モードの学習に伴い、非推論モードの能力も向上しています。これにより、学習パイプラインを一本化し、開発効率を大幅に高めることができました。同時に「時間がかかっても高品質な出力がほしい」「単純なタスクには素早く回答してほしい」という両方のニーズに引き続き応えることができました。

一方、STEM/Codeでは、第2段階のSFT以降で非推論モードのスコアが低下しています。これは、第2段階のSFTで非推論モードの回答が非常に長くなる傾向を抑え、素早く答えるように学習させているためです。PLaMo 3.1 Primeでは、じっくり考える推論モードと素早く答える非推論モードの特性がより明確になり、用途に応じて使い分けやすくなっています。

推論の高速化

PLaMo 3.1 Primeでは、モデルの改善に加えて、推論そのものを高速化するための技術を2つ導入しました。1つは応答生成を高速化する投機的デコーディング（Speculative Decoding）、もう1つはGPUメモリをより効率よく使うためのKV Cacheの低ビット量子化です。

投機的デコーディング

PLaMo 3.1 Primeでは、応答生成を高速化するため、投機的デコーディングを新たに導入しました。これにより、応答の品質を保ったまま、生成速度が大きく向上しました。

LLMは文章を1トークンずつ順番に生成します。1トークンを生成するたびに巨大なモデルの重みをGPUメモリから読み出す必要があるため、推論速度は計算量よりもメモリ帯域に制約されやすく、GPUの計算能力を十分に使い切れないことがしばしばあります。投機的デコーディングは、この点に着目した手法です。

投機的デコーディングでは、まず「ドラフトモデル」と呼ばれる軽量なモデルが、PLaMo 3.1 Prime（ターゲットモデル）の出力を数トークン先まで素早く予測します。次にターゲットモデルが、予測されたトークン列を1回の推論で検証します。予測が当たったトークンはそのまま採用され、外れたトークンではターゲットモデル自身の出力を採用して、そこから再び予測を始めます。このため、予測が当たるほどターゲットモデルの1回の推論で多くのトークンを確定でき、生成が速くなります。検証フェーズではターゲットモデルの出力分布に従うようにトークンの採否を決めるため、ドラフトモデルを使わない場合と同じ品質の応答が得られます。

KV Cacheの低ビット量子化

LLMは応答を生成する際、それまでに処理したトークンの情報をKV CacheとしてGPUメモリ上に保持し、1トークン生成するたびに読み出しています。KV Cacheの量は、長いコンテキストを扱う場面だけでなく、多数のリクエストを同時に処理する場面でも大きくなります。このため、KV CacheのサイズはGPUメモリの容量と帯域の両面でボトルネックになりがちです。

PLaMo 3.1 Primeでは、PFNが独自に開発した手法によりKV Cacheを量子化して保持するよう改善しました。これにより、同じGPUメモリ容量に格納できるトークン数が大幅に増加し、主に次のような効果が得られました。

• Prefix Cacheのヒット率向上と同時処理数の増加: システムプロンプトや会話履歴などのKV Cacheをより多くGPUメモリ上に残せるため、共通する入力の先頭部分（prefix）を持つリクエストの処理性能が向上しました。また、同じGPUでより多くのリクエストを同時に処理できるようになりました。
• 生成速度（TPOT）の向上: KV Cacheの読み出しに必要なメモリ転送量が減少するため、同じバッチサイズで比べると、1トークンあたりの生成時間が15～45%短縮されました。

ベンチマーク結果

各種LLMベンチマークの結果

PLaMo 3.1 Primeの推論/非推論モードを、前回のフラッグシップモデルであるPLaMo 3.0 Primeの推論/非推論モデル、および同性能帯のオープンモデルであるgpt-oss-120b、Gemma 4 31B IT、Qwen3.8 27B、Muse Glimmer 30Bと比較します。Gemma 4 31B ITとQwen3.8 27Bは推論/非推論の両方を、gpt-oss-120bとMuse Glimmer 30Bは推論のみを評価しました。実際に提供されるPLaMo 3.1 Primeではデプロイ先ハードウェアに合わせた最適化を行っているため、評価時とは一部の挙動や性能が異なる場合があります。

比較には、指示追従や対話、STEM/Code、Web検索を伴う質問応答など、計35個のベンチマークを用いました。Web検索を伴う調査レポートの作成や、与えられた資料に基づく回答、事実に即した回答など、今回の開発で重点的に改善した能力も評価しています。図5には、各ベンチマークのスコアを0～100に揃え、9個のカテゴリごとに平均した値を示します。カテゴリの内訳と評価方法の詳細については、Appendixをご確認ください。

PLaMo 3.0 Primeと比べると、両モードとも多くのカテゴリでスコアが向上しました。特にWeb検索レポートが大きく改善し、事実性・忠実性と安全性も両モードで向上しています。一方で、推論モードの指示追従と非推論モードのSTEM/Codeはスコアが低下しており、今後の改善が必要です。

競合モデルと比べると、安全性は両モードで、指示追従は非推論モードで最も高いスコアでした。一方で、STEM/CodeとWeb検索QAでは両モードともすべての競合モデルを下回り、対話と長コンテキストRAGでも劣る場合が多いため、引き続き改善に取り組みます。

トークン使用量と性能の関係

推論モデルは回答の前に思考の過程を出力するため、性能が上がる一方で生成するトークン数が増え、応答までの待ち時間や推論コストが大きくなります。そこで、各モデルが回答にどれだけのトークンを使っているかと、ベンチマークの性能の関係を調べました。図6は、図5と同じ9カテゴリの平均スコアを縦軸に、1応答あたりの出力トークン数を横軸にとったものです。図5の比較対象に加えて、国内で開発された推論モデルであるllm-jp-4.1 33B ThinkingとELYZA-Thinking 33Bも掲載しています。トークン数は、思考の過程とツール呼び出しを含むすべての出力を数えたものです。ベンチマークごとに平均したトークン数を、カテゴリ内で幾何平均し、さらに9カテゴリ間で幾何平均しています。破線は、より少ないトークン数でより高いスコアを出しているモデルが他にない点を結んだPareto frontierです。

PLaMo 3.1 Primeは、両モードともPLaMo 3.0 Primeより少ないトークン数で高いスコアを示しました。また、推論モードではgpt-oss-120bや国内の推論モデルよりも少ないトークン数で高いスコアを示し、Pareto frontier上に位置しています。一方、Muse Glimmer 30B、Gemma 4 31B IT、Qwen3.8 27Bの推論モードは、より多くのトークンを使ってより高いスコアを出しています。

非推論モードは、今回比較したモデルの中で最も少ないトークン数で応答しています。ただし、スコアではGemma 4 31B ITやQwen3.8 27Bの非推論モードを大きく下回っており、トークン数の少なさを考慮しても性能の面での改善の余地は大きいと考えています。

現在のPLaMo 3.1 Primeで選べるのは推論モードと非推論モードの2つです。今後は推論の量を調整できるようにするなどして、用途に応じてトークン数と性能のバランスをより柔軟に選べるようにしていきたいと考えています。

速度ベンチマークの結果

投機的デコーディングによる推論性能向上の効果を測定するため、NVIDIAが公開している投機的デコーディングの評価用ベンチマークであるSPEED-Benchを用いて評価しました。SPEED-Benchには、コーディングや数学、創作、ロールプレイまで、性質の異なる複数のカテゴリのプロンプトが含まれています。下表は、同時に処理するリクエスト数（Concurrency）ごとに、投機的デコーディングを使わない場合を1として、使う場合の出力トークンスループットの比（高速化率）を示したものです。同時リクエスト数が少ない条件では、投機的デコーディングによって出力速度が約1.7倍に向上しました。一方で、同時リクエスト数が増えると高速化率は小さくなります。これは、処理するリクエストが多いほどGPUの計算能力に余裕がなくなり、ドラフトモデルの予測を検証するための追加の計算を吸収しにくくなるためです。

おわりに

国産生成AI基盤モデルPLaMo 3.1 PrimeはPLaMo Chat/API経由でご利用いただけます。Freeプランもありますのでぜひこちらからご利用ください。また2026年11月30日までの期間限定で、PLaMo Chatでは無料で1日2回のDeep Researchを試すことができるので、ぜひご活用ください。

PLaMo 3.1 Primeの開発では、多様な大規模計算基盤を大いに活用しました。また、学習データの生成には、利用可能であることを個別に確認した社内のデータを適切に利用しています。我々は、チップ、インフラ、基盤モデル、ライブラリ、そしてソリューションまでを一気通貫で開発・提供するPFNの垂直統合の強みを活かし、引き続き強い熱意をもってPLaMoの開発に取り組んでいきます。

PLaMoの開発における取り組みは、本記事で紹介した改善以外にも多岐にわたります。今後は、Web検索QAや長コンテキストRAGなど、Deep Researchを支える能力を引き続き強化していきます。それに加えて、コーディングエージェントとして活用できる能力の獲得や、実務に関わる様々な領域のタスクでの性能向上にも取り組みます。我々はこれらの課題に情熱をもって挑戦していく仲間を募集しています。これらの仕事に興味のある方はぜひご応募ください。

• 大規模言語モデル 事前学習エンジニア: https://open.talentio.com/r/1/c/preferred/pages/118886
• 大規模言語モデル 事後学習エンジニア: https://open.talentio.com/r/1/c/preferred/pages/102815
• 大規模言語モデル VLMエンジニア: https://open.talentio.com/r/1/c/preferred/pages/118552
• 大規模言語モデル 推論基盤エンジニア: https://open.talentio.com/r/1/c/preferred/pages/119173

謝辞

PLaMo 3.1 Primeの開発では、これまで蓄積してきた独自データセットに加え、国立研究開発法人情報通信研究機構（NICT：エヌアイシーティー）が整備する日本語関連データセットを学習に活用しました。PLaMo 3.1 Primeは、NICTとの共同研究で得られた事前学習モデルをベースに開発しており、NICTには安全性の評価について支援していただきました。関係機関の皆様のご支援に感謝申し上げます。

Appendix: 評価の詳細

評価設定

各種PLaMoモデル、gpt-oss-120b、Gemma 4 31B IT、Qwen3.8 27B、Muse Glimmer 30B、および図6にのみ載せたllm-jp-4.1 33B Thinking、ELYZA-Thinking 33Bは、我々のGPUクラスター上でvLLMを用いて推論しました。llm-jp-4.1 33B ThinkingとELYZA-Thinking 33Bは推論モードのみのモデルのため、推論モードだけを評価しています。PLaMo 3.0 Primeも今回の評価設定で評価し直しているため、3.0のリリースブログで報告した値とは一致しない場合があります。

推論時のコンテキスト長（max_model_len）は、推論モードでは262,144（gpt-oss-120bは131,072、llm-jp-4.1 33B ThinkingとELYZA-Thinking 33Bはモデルの最大長の65,536）、非推論モードでは65,536に設定しました。推論過程を含む生成トークン数の上限は、ベンチマークごとに設定しています。PLaMo 3.1 Primeのモードの切り替えには、リクエスト時にchat templateの引数enable_thinkingを用いています。

生成時のサンプリング設定は以下のとおりです。競合モデルは各社が公開している推奨値を、すべてのベンチマークに共通で使いました。モデルカードに推奨値の記載がないllm-jp-4.1 33B Thinkingは、公式の利用例の値を使いました。

※PLaMoの非推論モードでは、複数回の独立した生成が必要なベンチマークだけサンプリングしています。MT-Bench、Japanese MT-Bench、IFBench、SealQAと安全性のベンチマークはtemperature 0.7 / top_p 1.0 / top_kなし、AIME 2024、MATH-500、GPQA-Diamondはtemperature 0.6 / top_p 0.95 / top_k 20です。

回答の採点にLLMを用いるLLM-as-judgeでは、すべての評価対象モデルの回答を、共通のジャッジモデルgoogle/gemma-4-31b-itで採点しました。

本記事の図のスコアは、各ベンチマークのスコアを0～100に揃え、以下のカテゴリごとに単純平均したものです（図6の縦軸は、さらに9カテゴリを単純平均したもの）。ただしMT-BenchとJapanese MT-Benchは1～10のスケールのため、10倍してから平均しています。AA-Omniscienceのスコア（Omniscience Index）は－100～100のため、(index + 100) / 2で0～100に変換しています。

IFBench

HuggingFaceの公式データセットの294問を、公式リポジトリをベースとした実装で評価しました。採点は公式実装と同様にルールベースで各指示への追従可否を判定し、すべての指示を満たしたプロンプトの割合（loose / prompt-level）をスコアとしています。評価を5回実行し、その平均値を報告しています。

JFBench

公式リポジトリではなく、開発版の実装を用いて評価を行いました。

制約数1、2、4、8のそれぞれについて400件、計1,600件の評価用データを用い、日本語の指示に従えるかを評価しました。採点では各制約を満たしているかを判定し、すべての制約を満たした回答の割合をスコアとしています。一部の制約の判定にはLLM-as-judgeを用いています。

内部指示追従ベンチマーク

我々が内部で保有する、日本語の指示追従に関する独自ベンチマークです（未公開）。回答をJSON形式で出力するよう求めたうえで複数の制約を付けた1,413件の指示を評価しました。すべての制約を満たした回答の割合をスコアとしています。

MT-Bench

公式リポジトリをフォークした開発版の実装を用いて、英語の対話性能を評価しました。80問の2ターンの対話をジャッジモデルが1～10点で採点します。参照回答には公式リポジトリのものを利用しています。評価を5回実行し、その平均値を報告しています。

Japanese MT-Bench

公式リポジトリをフォークした開発版の実装を用いて、日本語の対話性能を評価しました。80問の2ターンの対話をジャッジモデルが1～10点で採点します。参照回答にはSwallowプロジェクトによるものを利用しています。評価を5回実行し、その平均値を報告しています。

AIME 2024

Lighteval経由で、HuggingFaceH4/aime_2024の数学の問題30問を評価しました。1問あたり64サンプルを生成してpass@1を計算し、全設問で平均しました。解答例を与えない設定（0-shot）で評価しています。

MATH-500

Lighteval経由で、HuggingFaceH4/MATH-500の数学の問題500問を評価しました。1問あたり4サンプルを生成してpass@1を計算し、全設問で平均しました。AIME 2024と同じく、解答例を与えない設定（0-shot）で評価しています。

GPQA-Diamond

科学分野の質問応答ベンチマークGPQAのDiamondサブセット198問を、Lighteval経由で評価しました。1問あたり4サンプルを生成してpass@1を計算し、全設問で平均しました。AIME 2024と同じく、解答例を与えない設定（0-shot）で評価しています。

LiveCodeBench

LiveCodeBenchをベースとした実装を用いて、LiveCodeBenchのうち、2024/08/01～2025/02/01に出題された329問を評価しました。Pythonで解答するよう指示し、最終回答をPythonのコードブロックとして出力させます。1問あたり1サンプルを生成し、そのコードを事前処理済みのテストケースで実行して、すべてのテストケースを通った問題の割合（pass@1）をスコアとしています。

BrowseComp-Plus

BrowseComp-Plusの830問を用いて、検索を伴う質問応答の性能を評価しました。ライブWeb検索は使用せず、固定した文書群をBM25で検索しています。モデルには検索（上位5件）、文書の取得、文書内の検索の3つのツールを与え、必要な情報を調べながら回答させています。

1問あたりの総生成トークン数の上限は、推論過程を含め、推論モードでは131,072（gpt-oss-120bは65,536、llm-jp-4.1 33B ThinkingとELYZA-Thinking 33Bはコンテキスト長の半分の32,768）、非推論モードでは28,672としました。上限に達して回答できなかった問題、ツール呼び出しが100回に達した問題、最終回答が空の問題は不正解として扱います。最終回答と正解の一致はジャッジモデルで判定しています。

FRAMES

FRAMESの824問を用いて、Wikipediaの検索を伴う質問応答の性能を評価しました。検索にはBM25を用い、BrowseComp-Plusと同じ3つのツールを与えています。生成トークン数の上限はすべてのモデルで28,672です。BrowseComp-Plusと同じく、上限に達した問題、ツール呼び出しが100回に達した問題、最終回答が空の問題は不正解として扱います。最終回答と正解の一致はジャッジモデルで判定しています。

SealQA

SealQAのLongSeal 254問を用いて、紛らわしい文書の中から根拠を探し出す検索質問応答の性能を評価しました。ライブWeb検索は使用せず、各問題に付属する正解の根拠を含む文書と無関係な文書（最大約32件）を、問題ごとにBM25で検索します。モデルにはBrowseComp-Plusと同じ3つのツールを与えています。元論文のようにすべての文書をプロンプトに入れる設定ではないため、論文の値とは直接比較できません。

ツールの呼び出しは1問あたり30回まで、生成トークン数の上限は1ターンあたり16,384です。最終回答と正解の一致はジャッジモデルで判定し、回答しなかった問題も不正解として扱います。評価を5回実行し、その平均値を報告しています。

BRIGHT

BRIGHTの12分野1,384クエリを用いて、推論を要する情報検索の性能を評価しました。質問に答えさせるのではなく、クエリの解決に役立つ文書をできるだけ多く検索で集めるようモデルに求めます。分野ごとの文書群をBM25で検索し、BrowseComp-Plusと同じ3つのツールを与えています。ツールの呼び出しは1クエリあたり100回まで、生成トークン数の上限は推論過程を含めて28,672です。

検索で得られた文書を初めて現れた順に並べ、正解文書に対するnDCG@10をルールベースで計算しました。スコアは分野ごとの平均を12分野で単純平均したものです。モデルを検索クエリの生成役とする設定のため、元論文で報告されている検索器の値とは直接比較できません。

HealthBench

HealthBenchは、医療・健康に関する対話への応答を、医師が作成した会話ごとのルーブリックで採点するベンチマークです。全体から無作為に抽出した1,000件を、Deep ResearchモデルDR Tuluの公式リポジトリにある評価データと評価器で評価しました。モデルには、社内で構築した検索環境（英語版WikipediaおよびPubMed）で検索・文書の取得・文書内の検索を行うツールを与え、引用付きのレポートを生成させています。ツールの呼び出しは1問あたり10回までです。レポートは評価器の定義に従ってジャッジモデルで採点しています。エージェントの実装、検索環境、ジャッジモデルが異なるため、元論文やDR Tuluの論文で報告されている値とは直接比較できません。

ResearchQA

ResearchQAは、75分野のサーベイ論文から作成した学術的な質問と、それに対するルーブリックからなるベンチマークです。776件を評価しました。評価設定はHealthBenchと同じです。

Genetic Diseases QA

DR Tuluの論文で導入された、病原性の遺伝子変異に関する専門家作成の質問からなるベンチマークです。47件を評価しました。評価設定はHealthBenchと同じです。

内部長コンテキストRAGベンチマーク

我々が内部で保有する独自ベンチマークです（未公開）。複数の記事を与え、ある状況の変化を進める要因と妨げる要因を、指定した観点から記事に基づいて抽出・説明させる50件を評価しました。回答は、記事に照らした事実性、要因の分類の正しさ、具体性、解釈の質、表記の指示への準拠の5つの観点でジャッジモデルが採点し、その平均をスコアとしています。指定したJSON形式で出力できなかった回答は0点としています。

LongBench v2

HuggingFaceの公式データセットの503問を、公式リポジトリをベースとした実装で評価しました。長い文書を読んで答える4択問題で、出力から抽出した選択肢の正解率をスコアとしています。入力がコンテキスト長を超える場合は、文書の中央を切り詰めて先頭と末尾を残しています。そのため、設定したコンテキスト長の異なる推論モードと非推論モードでは、モデルに与える文書の長さが異なります。

LLM-jp LongBench

LLM-jp LongBenchの日本語の長文読解タスク、JEMHopQA（90件）とNIILC（10件）の計100件を評価しました。NIILCでは、入力の文脈を設定したコンテキスト長に合わせて構成しています。そのためLongBench v2と同様に、推論モードと非推論モードではモデルに与える文脈の長さが異なります。JEMHopQAはデータセットの文脈をそのまま用い、コンテキスト長に収まらない入力は不正解として扱います。出力の<Answer>タグから抽出した回答と正解の完全一致率をスコアとしています。

FaithEval

FaithEvalを用いて、与えられた文脈に忠実に回答できるかを評価しました。対象はunanswerable（2,492件）、inconsistent（1,500件）、counterfactual（1,000件）の計4,992件です。文脈から答えられない場合や文脈に矛盾がある場合にそれを指摘できるか、文脈が一般常識と異なる場合に文脈に従えるかを、回答に含まれるキーワードによるルールベースで判定しています。スコアは4,992件全体の正解率です。

LongBench-Cite

LongBench-Citeのデータのうち、LongBench-Chatを除く950件を評価しました。長い文書と質問を与えて引用付きで回答させ、回答の正しさと引用の適切さ（引用F1）をジャッジモデルで評価し、2つの指標の平均をスコアとしています。

ALCE

ALCEのASQA（948件）、QAMPARI（1,000件）、ELI5（1,000件）を評価しました。各質問に対して検索済みの上位5件の文書を与え、引用付きで回答させています。回答の正しさ・引用の適切さ・流暢さの観点から採点し、それらのスコアの平均を報告しています。採点にはジャッジモデルを用いますが、QAMPARIの正しさは回答と正解の文字列一致で判定しています。流暢さはASQAとELI5でのみ評価しています。元論文で用いられているNLIモデル等による自動評価の代わりにLLM-as-judgeを用いているため、論文の値とは直接比較できません。

TMG-CQA

我々が東京都の公開資料をもとに構築し、公開した、複数の資料を統合した回答と文単位の引用を評価する日本語のベンチマークです。資料を与えて引用付きで回答させるRAG版の1,007問を評価しました。回答の正しさは参照回答と矛盾しないかをジャッジモデルで判定した正答率、引用の適切さはLongBench-Citeと同じ方法で求めた引用F1とし、その2つの平均をスコアとしています。

AA-Omniscience

AA-Omniscienceの公開版600問（6分野×100問）を評価しました。ツールや文脈は与えず、分からない場合はその旨を答えるよう指示しています。各回答をジャッジモデルで「正解」「不正解」「部分的な回答」「回答なし」に分類し、Omniscience Index = 100 × (正解数 － 不正解数) / 全問題数 をスコアとしています。誤答は減点されるため、知らない問題に当て推量で答えるより回答を控えた方が高いスコアになります。

TruthfulQA

TruthfulQAの二択形式（2025年1月の更新版）の790問を評価しました。各問題について公式の正答と誤答を、順序をランダムにした選択肢として示し、AまたはBで答えさせます。採点はルールベースで、出力から抽出した選択肢の正解率をスコアとしています。選択肢を抽出できない回答は不正解として扱います。

SimpleQA Verified

短答式の事実性ベンチマークSimpleQA Verifiedの1,000問を評価しました。各回答をジャッジモデルで「正解」「不正解」「回答なし」に分類し、全問題に対する正解率と、回答した問題に限った正解率のF値をスコアとしています。

Japanese SimpleQA

日本に関する事実を問う短答式ベンチマークJapanese SimpleQAの3,000問を評価しました。各回答をジャッジモデルで「正解」「不正解」「回答なし」に分類し、全問題に対する正解率と、回答した問題に限った正解率のF値をスコアとしています。

JamC-QA

JamC-QAのテストセット2,309件を評価しました。日本固有の知識を問う質問応答で、4-shotで回答させ、正規化した回答と正解の完全一致率をスコアとしています。

MedRECT

公式リポジトリを用いて、日本語のデータセット663件と英語のデータセット458件を評価しました。

モデルには、臨床テキストに医学的エラーが含まれるかどうかを判定し、エラーがない場合はCORRECT、エラーがある場合は修正後の文を出力するよう求めています。採点はルールベースで行い、エラー検出にはF1、エラーを含む文の抽出には完全一致率、修正文にはROUGE-1を用いています。スコアは3つの指標の平均です。英語版も同じ構成の英語の指示文で回答させ、同じ指標で採点しています。日本語版と英語版はそれぞれ1つのベンチマークとして扱っています。

JMLE（医師国家試験）

2024年度および2025年度の医師国家試験の問題557問をベンチマーク対象としています。
以下の独自プロンプトで回答を生成させ、モデルの出力からルールベースの処理で回答を抽出しました。

prompt = (
    "以下の日本の医師国家試験問題に答えてください。\n\n"
    f"問題文: {question}\n\n"
    "選択肢:\n"
    f"{choices_text}\n\n"
    "回答形式:\n"
    "- 「どれか。」で終わる選択問題で数が明記されていない場合は、五者択一を意味するので選択肢を必ず"
    "1つだけ選び小文字のアルファベットで答えてください。（単数選択）\n"
    "- 「2つ選べ」「3つ選べ」などと書いてある場合に限り、指定された数だけの複数選択肢を選び、カンマ"
    "区切り（例: a, b）で答えてください。（複数選択）\n\n"
    "answer: [解答(単数/複数)]\n"
)

lawqa_jp

公式リポジトリのselection.jsonに含まれる140問の4択問題を、関連する法令のコンテキストを付加しない設定と、付加する設定の両方で評価しました。付加する設定では、各設問のsamplesに含まれる関連法令の条文をプロンプトに入れています。採点はいずれの設定もルールベースで行い、モデル出力の先頭の文字を正解ラベル（a～d）と比較しています。

HELM Safety

HELM Safety v1.0を参考に、BBQ（1,000件）、SimpleSafetyTests（100件）、HarmBench（400件）、XSTest（450件）、Anthropic Red Team（1,000件）の5つの安全性ベンチマークを評価しました。BBQはルールベース、それ以外の4つはジャッジモデルで採点しています。ジャッジモデルには他のベンチマークと共通のgoogle/gemma-4-31b-itを用いています。各モデルについて評価を5回実行し、各ベンチマークの平均スコアを求めたうえで、5つのベンチマーク間で平均しています。

内部安全性ベンチマーク

我々が内部で保有する、日本語の安全性に関する独自ベンチマークです（未公開）。応答すべきでない625件の依頼に対して、モデルが回答を拒否したかをジャッジモデルで判定し、拒否した割合をスコアとしています。各モデルについて評価を5回実行し、その平均値を報告しています。