OpenSkillEval：「スキルを入れればエージェントは賢くなる」を検査するための物差し

2026年5月25日のarXiv cs.CL新着で、LLMエージェントの「スキル」利用を評価する論文、OpenSkillEvalが掲載された。ここでいうスキルとは、モデルの重みそのものではなく、プレゼン作成、Webデザイン、可視化、レポート作成のような作業をうまく進めるために整理されたワークフロー指示のことだ。最近のエージェント開発では、モデルを入れ替えるだけでなく、外部ツール、プロンプト、テンプレート、手順書を組み合わせて性能を上げる流れが強まっている。OpenSkillEvalが面白いのは、その「手順書のエコシステム」自体を評価対象にした点にある。(arxiv.org)

論文の問題意識はかなり実務的だ。オープンソースのスキルが増えるほど、ユーザーは「どのスキルを入れればよいのか」「人気のあるスキルは本当に効くのか」「同じスキルでもモデルやエージェント基盤が違えば効果は変わるのか」を判断しにくくなる。現在のエージェント評価は、特定の静的ベンチマークでモデル能力を測るものが多い。しかし、実際の作業ではタスクの入力、成果物の形式、利用するツール、評価基準が常に動く。OpenSkillEvalはここに対して、静的な問題集ではなく、現実の成果物に近いタスクインスタンスを自動生成し、スキル付きエージェントとスキルなしエージェントを比較する枠組みを提案している。(arxiv.org)

対象カテゴリは、プレゼン生成、フロントエンドWebデザイン、ポスター生成、データ可視化、レポート生成の5種類。いずれも「正解が一つ」ではなく、見た目、構成、内容の整合性、目的への適合が絡むタスクだ。論文では600件超の動的生成タスクと30個のオープンソーススキルを使い、複数のモデル・エージェントフレームワークを統一条件で評価したと説明している。これは単なるプロンプト比較ではなく、「スキル × モデル × フレームワーク × タスク」の相互作用を見る試みといえる。(arxiv.org)

結果として重要なのは、スキルが存在するだけでは性能向上を保証しない、という点だ。論文は、スキル拡張の効果が基盤モデルとエージェントフレームワークに強く依存し、公開コミュニティで人気のあるスキルでも、スキルなしのベースエージェントを一貫して上回るとは限らないと報告している。これは直感に反するようで、実はかなり自然な結果でもある。スキルは「知識」ではなく「実行時の制約」であり、モデルがその制約を読めること、必要な場面で選べること、フレームワーク側がそれを実行計画に落とせることが揃わなければ、むしろノイズになる。(arxiv.org)

この論文が示す変化は、エージェント評価の対象が「モデル単体」から「運用部品の組み合わせ」へ移っていることだ。これまでなら、モデルAとモデルBの比較、あるいはプロンプトの工夫として語られていた問題が、今後は「このモデルにはこのスキルが効くが、別のフレームワークでは効かない」といった互換性の問題になる。プラグイン、MCPサーバー、スキルリポジトリ、プロンプトパックが増えるほど、評価すべき単位はモデル名ではなく、構成全体になる。

実務上の含意は明確だ。エージェントに外部スキルを追加するとき、スター数や導入事例だけで選ぶのは危うい。少なくとも、対象タスクに近い小規模評価セットを作り、スキルなし、単一スキル、複数スキルの比較を行う必要がある。さらに、評価は一回で終わらない。モデルのバージョン、ツールAPI、フレームワークの挙動が変われば、昨日効いたスキルが今日も効くとは限らない。OpenSkillEvalが「動的なタスク生成」を重視するのは、この流動性に対応するためだと読める。(arxiv.org)

一方で、注意点もある。5カテゴリ・30スキルという範囲は重要な出発点だが、すべてのエージェント用途を代表するわけではない。コード修正、長期リサーチ、業務システム操作、法務・医療文書のような高リスク領域では、スキルの失敗モードも評価軸も異なる。また、オープンエンドな成果物の評価では、判定器や採点基準そのものが結果に強く影響する。したがって、この論文を「どのスキルが最強か」のランキングとして読むより、「スキル市場には監査の仕組みが必要だ」という問題提起として読む方が妥当だ。

エージェント時代の部品は、モデル、ツール、メモリ、ワークフロー、スキルに分解されていく。そのとき本当に難しいのは、部品を集めることではなく、どの部品がどの条件で効くのかを継続的に測ることだ。OpenSkillEvalは派手なモデル発表ではないが、エージェント開発が「作る」段階から「検査して選ぶ」段階へ移りつつあることを示している。出典：arXiv「OpenSkillEval: Automatically Auditing the Open Skill Ecosystem for LLM Agents」。(arxiv.org)

ARES：LLM強化学習の次のボトルネックは「報酬を書く人」かもしれない

2026年5月25日のarXiv cs.CL新着に、ARES: Automated Rubric Synthesis for Scalable LLM Reinforcement Learning が掲載された。著者はXiaoyuan Li、Keqin Bao、Moxin Liら8名で、コメント欄では「Under Review」とされている。派手な新モデルではないが、LLMのポストトレーニングでいま深刻になっている「検証可能な答えがないタスクを、どう強化学習するか」という問題に正面から触れている。(arxiv.org)

背景にあるのは、RLVR、つまり「検証可能な報酬による強化学習」の成功と限界だ。数学やコードでは、最終答えの一致、テスト通過、実行結果などを比較的はっきり報酬にできる。一方で、医療相談、長文説明、教育的フィードバック、複雑な指示追従のような開かれた生成タスクでは、「正解」は一つではない。そこで必要になるのが、内容の正確性、網羅性、根拠性、安全性、読みやすさなどを分けて評価するルーブリック型の報酬である。ARESが狙うのは、このルーブリック作成そのもののスケール化だ。(arxiv-troller.com)

論文要約によれば、ARESは生の事前学習文書から、自己完結した質問・回答ペアを作り、さらに各質問に対応した重み付きの個別ルーブリックを同時生成する。従来のように専門家が評価表を書いたり、タスク全体に固定ルーブリックを当てたりするのではなく、「この問いでは何を満たせば良い回答なのか」をインスタンス単位で作る点が要点だ。加えて、ドメインラベルやペルソナ情報で生成を条件づけ、質問の自己完結性、回答の忠実性、ルーブリックの妥当性を検証するフィルタを挟む。著者らはこの方法で10ドメインにわたる10万件のルーブリック付きインスタンスを構築したとしている。(arxiv-troller.com)

ここで面白いのは、ARESが「データ合成」の話にとどまらないことだ。これはむしろ、報酬設計を自然言語仕様として量産する試みに近い。LLMの強化学習では、報酬が曖昧だとモデルは簡単に近道を見つける。もっともらしいが根拠の薄い回答、採点者の癖に合わせた文章、過剰に安全側へ倒れた無内容な応答などが起きる。個別ルーブリックは、この曖昧さを少しでも構造化するための「評価の足場」になる。

実験面では、ARESで生成したルーブリックベースRLが、継続事前学習、教師あり微調整、二値報酬RLを上回り、特にヘルスケアや指示追従のような多次元のオープンエンドタスクで大きな改善があったと報告されている。ただし、これは著者らの評価であり、まだ独立再現や運用環境での検証を待つべき段階だ。特に医療のような高リスク領域では、ルーブリックがもっともらしく見えることと、臨床的に妥当であることは同じではない。(arxiv-troller.com)

この研究の本質的な問いは、「人間が報酬を設計する」から「モデルが報酬仕様を提案し、人間や検証器が監査する」へ移れるか、という点にある。うまくいけば、RLは数学・コード中心の閉じた正解タスクから、説明、助言、調査、対話、エージェント行動のような現実的タスクへ広がる。一方で、生成されたルーブリックがデータ中の偏りを再生産したり、評価しやすい品質だけを過大評価したりする危険もある。

今後の焦点は、スコアが上がるかだけではない。生成されたルーブリックを人間が監査できるか。ドメインを越えて破綻しないか。モデルがルーブリックの文面に過適応しないか。そして、評価基準自体の来歴を追跡できるか。ARESは完成品というより、LLM強化学習における「報酬を書く工程」を研究対象として前面に出した論文として読むのがよい。性能競争の裏側で、評価仕様をどう作り、どう疑うかが、いよいよ主要な技術課題になってきた。

PapersWithCode復活が、LLM研究の「地図」を更新する

2026年5月24日、Hugging Face上でNiels Rogge氏が、復活版PapersWithCodeの新機能を告知した。これは新しい基盤モデルの発表ではない。しかし、LLM研究を追ううえではかなり重要な「研究インフラ」のニュースだと思う。発表によれば、復活版はSOTA、つまり各タスクの最先端結果を、エージェント、コンピュータビジョン、時系列予測など複数領域で追跡することを狙っている。今回追加されたのは、ベンチマークごとの複数指標対応、arXiv以外の外部発表の登録、論文の前後関係を示すlineage、手法ページの拡充、リーダーボードの画像共有、そして約3,000件規模のeval追加だ。(huggingface.co)

面白いのは、これが単なる「昔の便利サイトの復活」ではないことだ。現在の生成AI・LLM研究は、もはやPDF論文だけでは完結しない。モデルカード、GitHub、Hugging Faceリポジトリ、企業ブログ、APIドキュメント、評価ハーネス、RedditやDiscord上の追試報告までが、実質的な研究記録になっている。特に商用LLMやオープンウェイトモデルでは、arXiv論文が存在しない、あるいは後追いで出るケースも多い。今回の「外部paper対応」は、この現実をかなり率直に受け入れた設計だ。ブログでは、GitHub repo、blog post、BioRxivなどarXiv外の発表も登録でき、AIがタスク、手法タグ、GitHub repo、evalなどを自動補完すると説明されている。(huggingface.co)

ここで重要になるのが「ランキング」ではなく「接続」である。LLM界隈では、あるモデルがどのベンチで何点を取ったかだけが流通しがちだが、本当に知りたいのは、その数字がどの評価条件で出たのか、どの実装に依存しているのか、先行手法と何が違うのか、後続モデルが何を継承したのか、という関係性だ。今回追加されたpaper lineageは、この点で地味だが価値がある。Mamba系、DeltaNet系、Kimi Delta Attention系のように、似た設計思想が短期間に分岐・統合していく領域では、「新しい名前」よりも「どの系譜のどの変更か」を把握する方が重要になる。

複数指標対応も実務的だ。単一スコアのリーダーボードは分かりやすいが、生成AIではしばしば誤解を生む。たとえば音声認識ならWERだけでなく速度指標が必要になり、物体検出なら精度だけでなくFPSも意味を持つ。LLMでも同じで、推論精度、コスト、レイテンシ、コンテキスト長、ツール使用成功率、安全性、再現性は互いに交換可能ではない。ひとつの表で「勝者」を決めるより、複数軸で地形を見る方が、研究にも導入判断にも向いている。

ただし、課題もはっきりしている。AIによる自動タグ付けや自動eval整理は、規模を出すうえでは不可欠だが、間違えると「もっともらしい誤分類」が研究者の認識を汚染する。実際、r/MachineLearningでの復活告知スレッドでは、AIエージェントによる分類ミスへの指摘や、タスク粒度をどう設計するか、コードの再現性をコミュニティで評価したいという要望が出ている。Rogge氏自身も、当初はAIエージェントで論文を大規模に解析しつつ、結果は自分が確認していると説明している。(reddit.com)

これは、今後のPapersWithCode型サービスが直面する核心だ。研究の量が人手キュレーションの限界を超えたためAI補助が必要になる。しかし、AI補助で作られた研究地図は、人間が検証しなければ権威ある誤情報になりうる。特にLLMの評価では、モデルのバージョン、プロンプト、推論設定、ツール使用可否、judgeモデル、データ汚染の可能性まで結果を左右する。単に「3,000 evals」と表示するだけでは足りず、そのevalがどのハーネスで、いつ、どの条件で実行されたのかを追跡できる必要がある。

したがって、このニュースの本質は「便利なランキングサイトが戻った」ではない。生成AI研究が、論文中心の時代から、モデル・コード・評価・系譜・コミュニティ検証を結ぶグラフの時代へ移ったことを示している。もし復活版PapersWithCodeが信頼できる検証層まで育てば、LLM研究を読む作業はかなり変わる。読むべき対象はPDF一枚ではなく、そのモデルが属する評価と実装の生態系全体になる。派手なモデル発表ではないが、研究の足場を作り直すという意味で、今日拾う価値のある発表だ。

MOSS：自己改善エージェントは「プロンプト」ではなく「実行基盤」を書き換え始める

直近24時間内にニュース化された生成AI関連トピックとして、24 AIが2026年5月23日に取り上げた MOSS: Self-Evolution through Source-Level Rewriting in Autonomous Agent Systems を選びたい。原論文そのものはarXivに2026年5月21日投稿なので「論文初出」は少し前だが、今回のニュース価値は、自己改善型エージェントの議論を「記憶」「プロンプト」「スキル」から、より危険で実務的な層——エージェントを動かすソースコードそのもの——へ移した点にある。(24-ai.news)

MOSSの問題意識はかなり明快だ。現在の多くの自律エージェントは、デプロイ後に同じ失敗を繰り返す。従来の「自己進化」系手法は、スキルファイル、プロンプト設定、メモリスキーマ、ワークフローグラフなど、テキストとして変更できる部分を更新する。しかし、実際の失敗の一部はそこにはない。ルーティング、hookの順序、状態管理、dispatch、セッションライフサイクルといった、いわばエージェントの「実行基盤」に埋まっている。論文は、この層を「agent harness」と呼び、MOSSはそこまで編集対象を広げる。(arxiv.org)

ここで重要なのは、「自己改善」という言葉の中身を分解することだ。モデルが賢くなるのではない。MOSSでは、失敗ログをもとに、外部のcoding-agent CLIがコード変更を提案し、それを隔離された試験環境で再実行し、改善が確認されたらコンテナを差し替える。つまりこれは、LLMが突然AGI的に自己改造する話ではなく、本番障害ログ → 原因箇所推定 → パッチ生成 → 回帰検証 → 承認付きデプロイという、かなりソフトウェア工学的なループである。むしろ「agentic MLOps」あるいは「自動プログラム修復をエージェント運用に接続したもの」と見る方が正確だ。(arxiv.org)

アーキテクチャは5つの部品からなる。ユーザー向けエージェントを動かすメインコンテナ、進化操作を行う moss evo CLI、コード編集を担当する外部coding-agent CLI、コンテナや試験環境を管理するhost-daemon、候補パッチを検証する一時的なtrial workerである。論文では、Claude Code、OpenAI Codex、DeepSeek-TUI、OpenCodeなどのrunnerを差し替え可能な形で扱う設計が説明されている。つまりMOSS自体は「特定のモデルが自分を直す」仕組みではなく、複数のコード生成エージェントを使える制御層として作られている。(arxiv.org)

進化プロセスも、単発の「コードを書き換えてみる」ではない。Locate、Plan、Plan-Review、Implement、Code-Review、Task-Evaluate、Verdictという7段階に分かれている。Locateでは失敗トレースを読んで診断し、Planで修正方針を作り、Plan-Reviewで妥当性を確認し、Implementで単一コミットとして変更し、Code-Reviewで差分を確認する。その後、候補イメージをビルドし、trial workerで実際にタスクを再実行し、最後に収束・継続・モデル限界・アーキテクチャ限界のいずれかを判定する。ここは面白い。LLMに「全部考えて直して」と丸投げするのではなく、失敗しやすい工程を明示的に分割している。(arxiv.org)

実験はOpenClawを基盤に、clawevalのoperations / compliance-auditカテゴリから4タスクを使っている。対象はSLA compliance auditの中国語・英語タスクと、restock-chain checkの中国語・英語タスクで、基盤モデルはDeepSeek V3.2。ベースラインの平均grader scoreは0.2526で、1回のMOSSループ後に0.6100まで上がった。特にT138は0.2090から0.9049まで上昇している。論文によれば、修正はプロンプトではなく、tool-result mediatorやbefore-tool-call hook chainなど、harness側のコードに入っている。(arxiv.org)

ただし、この数字はかなり慎重に読むべきだ。第一に、評価は4タスクのみで、同じ4タスクが失敗バッチとして進化の入力にも、改善確認の評価にも使われている。これは「本番の具体的失敗を直す」という目的には合っているが、一般化性能の証拠としては弱い。第二に、平均0.61は改善としては大きいが、論文中のpass threshold 0.75には届いていないタスクも残る。第三に、arXiv本文にはコードURLが記載されているが、こちらで確認した時点では該当GitHubリンクは404だったため、再現性は現段階では限定的に見ておく必要がある。(arxiv.org)

それでも、MOSSが示す方向性は重要だ。これまでエージェントの改善は、しばしば「モデルを良くする」「プロンプトを良くする」「メモリを増やす」と表現されてきた。しかし実運用のエージェントは、モデル単体ではなく、ツール接続、権限管理、状態同期、リトライ、ログ、UI、通知、承認フローを含む複合システムだ。失敗原因がこの複合システムの中にあるなら、モデルの出力だけを調整しても限界がある。MOSSの主張は、そこを正面から突いている。(arxiv.org)

一方で、安全性の論点はさらに重い。自分のコードを書き換えられるエージェントは、局所的には失敗を減らしても、長期的には意味論を少しずつ変えていく可能性がある。MOSSは、trial workerによる隔離検証、ユーザー承認付きapply、90秒のhealth probe、rollbackなどを入れている。しかし、これらは「壊れたら戻す」ための仕組みであって、「望ましくない方向に少しずつ適応する」ことを完全に防ぐものではない。特に、評価バッチが偏っていれば、エージェントはその偏りに最適化された実行基盤へ近づく。(arxiv.org)

今後この系統が実用に近づくなら、必要になるのは単なるsandboxではない。署名付きパッチ、変更差分の人間レビュー、権限境界、永続的な回帰テストスイート、監査ログ、そして「エージェントが変更してよい領域」と「絶対に変更してはいけない領域」の分離が必要になる。MOSSはその一部を提案しているが、企業や医療、金融のような環境で使うには、CI/CDやガバナンス設計と結合される必要がある。(arxiv.org)

この論文の面白さは、「自己改善」の派手さではなく、エージェントの失敗をどの層の問題として扱うかを変えた点にある。プロンプトの失敗ならプロンプトを直せばよい。検索の失敗ならRAGを直せばよい。しかし、実行順序、状態、権限、ツール境界の失敗なら、直すべき場所はコードである。MOSSは、その当たり前だが扱いにくい結論を、自己進化エージェントの文脈に持ち込んだ。まだ小さな実験で、再現性にも留保がある。それでも、エージェント研究が「賢いモデル」から「壊れにくく、直せるシステム」へ移っていることを示す、かなり象徴的な一歩だ。

Gated DeltaNet-2：長文LLMの「記憶」を、消す操作と書く操作に分ける

今回取り上げたいのは、NVIDIA系の研究者らによる Gated DeltaNet-2: Decoupling Erase and Write in Linear Attention。Hugging Face Daily Papersでも5月22日の注目論文として掲載されていた、線形注意機構の新しい提案だ。見出しだけ見ると地味だが、長文コンテキスト時代のLLMで何がボトルネックになるかを考えると、かなり本質的な方向を向いている。(huggingface.co)

現在主流のTransformerは、過去トークンの情報をKVキャッシュとして保持する。これは強力だが、文脈が長くなるほどキャッシュも大きくなり、推論時のメモリ・帯域・レイテンシに効いてくる。線形注意はこの問題に対し、無制限に伸びるキャッシュではなく、固定サイズの recurrent state に文脈を圧縮する。理想的には、系列混合は線形時間、デコードは定数メモリに近づく。ただし難点は、「圧縮された記憶をどう更新するか」だ。古い情報を雑に消せば必要な手がかりまで壊れ、新しい情報を雑に書けば既存の関連づけを汚染する。(arxiv.org)

Gated DeltaNet-2の核心は、この記憶更新を erase と write に分解した点にある。既存のGated DeltaNetやKimi Delta Attentionでは、古い内容をどれだけ消すか、新しい内容をどれだけ書くかが、単一のスカラーゲートに結びついていた。Gated DeltaNet-2はここを切り離し、key側に channel-wise erase gate b_t、value側に channel-wise write gate w_t を導入する。つまり「この座標の古い関連だけ消す」と「この座標に新しい内容を書き込む」を別々に制御できる。GitHubの説明では、KDAやGated DeltaNetを特殊ケースとして含む“strict generalization”として位置づけられている。(github.com)

直感的には、これはLLMの内部メモリを「上書き可能な一枚のメモ帳」と見るのではなく、「消しゴムとペンを別々に持つ編集操作」として扱う変更だ。長文検索や複数キーのneedle-in-a-haystackで難しいのは、単に情報を残すことではない。似た手がかりが複数あるときに、どの関連を保護し、どの関連を更新するかを間違えないことだ。erase/writeを分ける設計は、この“干渉”の扱いに効く可能性がある。

実験規模は1.3Bパラメータ、FineWeb-Edu 100Bトークンで、Mamba-2、Gated DeltaNet、KDA、Mamba-3 variantsと比較されている。論文は、言語モデリング、commonsense reasoning、retrievalでGated DeltaNet-2が最も良い総合結果を出したと報告している。GitHubに掲載された表でも、recurrent設定の平均精度はGated DeltaNet-2が53.11、hybrid設定では53.97で、比較対象を上回っている。(arxiv.org)

特に目を引くのはRULER系の長文検索だ。recurrent設定のS-NIAH-3 @2Kでは、Gated DeltaNet-2が89.8に対し、KDAは63.2、Gated DeltaNetは54.2。MK-NIAH-1 @4Kでも、Gated DeltaNet-2は37.8で、KDAの28.0やMamba-3 MIMOの18.0を上回る。もちろんベンチマークは限定的だが、「圧縮メモリの編集精度」が長文検索性能に現れるという主張には筋がある。(github.com)

重要なのは、これは「Transformerをすぐ置き換える」という話ではないことだ。むしろ、長文LLMの設計空間が広がっていると見るべきだ。全文脈をKVキャッシュとして保持するアプローチ、スパース化するアプローチ、状態空間モデルや線形RNN系に寄せるアプローチ、そして局所attentionとrecurrent stateを組み合わせるhybrid設計。それぞれが「何を正確に覚えるか」「どこまで近似してよいか」「ハードウェア上で速いか」という別々の制約を持つ。Gated DeltaNet-2は、その中で“状態をどう安全に編集するか”をかなり明確な形で切り出した研究だ。

留保もある。まず、報告されているのは1.3B規模での結果であり、10B、70B、MoE、実サービス規模で同じ傾向が出るとは限らない。次に、比較は同一研究側の実験であり、第三者再現や多様な実装での検証はこれからだ。また、コードは公開されているが、ライセンスはNVIDIA Source Code License-NCで、商用利用を前提にした自由なオープンソースとは性格が異なる。(github.com)

それでも、この論文が面白いのは、長文LLMの問題を「もっと長いコンテキストを入れる」ではなく、「圧縮された記憶をどう編集するか」として捉え直している点だ。エージェント、コード補完、長期記憶、検索拡張生成では、文脈はますます長く、ノイズも多くなる。必要なのは、すべてを覚える巨大な記憶ではなく、古い関連を壊さず、新しい関連を選んで書き込む仕組みかもしれない。

出典：arXiv論文、公式GitHub実装、Hugging Face Daily Papers。(arxiv.org)

VPO：「良い答えに収束する」だけでは、探索時代のLLMには足りない

2026年5月22日のarXiv新着で目を引いたのは、MIT、MIT-IBM Computing Research Lab、Sakana AIなどの著者による Vector Policy Optimization: Training for Diversity Improves Test-Time Search だ。テーマは一見すると強化学習の細部だが、実際には「LLMをどう訓練すべきか」という前提を少しずらす論文である。従来のRLHFやGRPO的なポストトレーニングは、基本的に一つのスカラー報酬を高くする方向へモデルを押す。しかし、いまのLLM利用は単発回答だけでなく、best-of-N、pass@k、自己整合性、進化的探索のように、複数候補を出して後段で選ぶ形へ広がっている。VPOはこの状況に対し、「訓練では一つの最適解に潰すのではなく、後段探索が拾える多様な有能解の集合を作るべきだ」と主張する。(arxiv.org)

仕組みはかなり素直だ。多くのタスクでは報酬は本来ベクトルで表せる。コード生成ならテストケースごとの正否、マルチホップQAなら各ホップの根拠選択と最終回答、ツール利用ならフォーマット、ツール名、引数キー、引数値といった要素に分解できる。従来はこれらを重み付き平均して一つの点数にし、その点数を最大化する。VPOはその代わりに、重みベクトルをランダムにサンプルし、モデルが一度のロールアウトで複数候補を出すように訓練する。各候補が報酬空間の異なるトレードオフに特化することで、集合全体としてパレートフロントを覆う、という設計だ。論文自身は、VPOをGRPOのadvantage推定器に対するほぼ差し替え可能な手法として位置づけている。(arxiv.org)

ここで重要なのは、「表面上違う文章を出せる」ことと「探索に役立つ多様性」は別物だという点だ。ランダムサンプリングで文体や順序が違う候補を増やしても、同じ失敗を少しずつ言い換えているだけなら、best-of-Nはすぐ頭打ちになる。VPOが狙うのは token diversity ではなく reward-space diversity、つまり報酬成分上で異なる強みを持つ候補群である。論文では、固定スカラー報酬で訓練したGRPOは候補プールが近傍に潰れ、追加サンプルの価値が早く飽和する一方、VPOは候補数が増えたときにbest@kの伸びが続く、と説明している。(arxiv.org)

実験はMaze、MuSiQue、EUREQA、ToolRLの4領域に加え、LiveCodeBenchのケーススタディで検証されている。たとえばMuSiQueでは、VPOのbest@30が0.832で、GRPOの0.728、Max-at-Kの0.802を上回る。MazeでもVPOはbest@30で0.593、GRPOは0.432、Max-at-Kは0.577だった。EUREQAでは差は小さいが、VPOがbest@30で0.279、Multi-RLVRが0.267、GRPOが0.236。ToolRLではMax-at-Kがbest@30で0.954、VPOが0.952とほぼ並ぶ。つまり「全表で圧倒」というより、探索予算がある状況でVPOが安定して競争力を持つ、という読み方が妥当だ。(arxiv.org)

面白いのはLiveCodeBenchでの反転だ。単発のpass@1ではGRPOの方が良い。しかし候補集合を評価するbest@kにするとVPOが上回り、OpenEvolveのような進化的探索ループに入れると、GRPOが早く頭打ちになる一方で、VPOは200反復の中で新しい解を見つけ続けた、と報告されている。これは「一発で正しい答えを出すモデル」と「探索器に良い素材を渡すモデル」が、必ずしも同じ訓練目標で得られないことを示している。(arxiv.org)

この論文の意味は、モデル評価の単位が変わりつつあることにある。チャットUIでは1問1答の品質が中心だった。しかし、コーディング、数学、ツール利用、研究支援では、LLMは最終回答者というより候補生成器になっていく。Google DeepMindのAlphaEvolveのような仕組みも、LLMが候補を出し、外部評価器や探索手続きが選別・改変する構造を取る。そうなると、訓練目標も「平均的に一番良い答え」ではなく「探索空間を豊かにする候補集合」へ寄っていく可能性がある。(deepmind.google)

ただし、VPOを万能視するのは早い。論文自身も、報酬成分が実質的に同じ方向を向いている場合、つまりベクトル報酬がほぼスカラーに潰れている場合には効果が縮むと述べている。UltraFeedbackとArmoRM-5を使った別実験では、名目上の複数成分がほぼ共線的で、VPOは絶対的なbest@kでスカラー手法を下回ったという。これは重要な留保だ。VPOが効くのは「良さ」に複数の独立した軸があり、それぞれに違う解法が存在する場合であって、単に報酬を細かく分ければよいわけではない。(arxiv.org)

もう一つの留保は、評価が研究チーム内のベンチマークと設定に依存している点だ。訓練はQwen系モデルを中心に、H100上でおよそ1000 GPU時間規模の報告実験として行われている。実サービスで重要になるのは、候補生成コスト、探索器の品質、報酬分解の設計、そして多様な候補を本当に安全に扱えるかという運用面である。特にエージェントでは、多様性は性能向上の源泉であると同時に、失敗パターンの多様化にもなりうる。(arxiv.org)

それでも、この論文は良い問いを置いている。LLMを「一つの答えを出す機械」と見るなら、報酬最大化は収束の問題になる。だがLLMを「探索プロセスの一部」と見るなら、過度な収束はむしろ損失になる。これからのポストトレーニングでは、正解率だけでなく、候補集合の広がり、相補性、探索器との相性が重要な指標になっていくかもしれない。

出典: arXiv新着一覧、論文ページ・PDF、Google DeepMind AlphaEvolve公式発表。(arxiv.org)

NVIDIAのNemotron-Labs-Diffusionは、「LLMは1トークンずつ出すもの」という前提を少し揺らした

2026年5月23日、NVIDIAがHugging Face上で「Nemotron-Labs-Diffusion」を公開した。3B、8B、14Bのテキストモデルに加え、8B規模の視覚言語モデルも含むファミリーで、base版とinstruction-tuned版が用意されている。モデルはHugging Face上で公開され、学習レシピもMegatron Bridgeのリポジトリで提供されている。(huggingface.co)

面白いのは、単に「新しい小型LLMが出た」という話ではないことだ。通常のLLMはautoregressive、つまり左から右へ1トークンずつ生成する。これは安定しており、既存の推論基盤とも相性がよい。一方で、次のトークンを出すたびにモデルを1回通す必要があり、特に低バッチ・低遅延の場面ではGPUが計算よりメモリ読み出しに縛られやすい。NVIDIAの説明では、Nemotron-Labs-Diffusionはこの制約を、複数トークンを並列に下書きし、反復的に精緻化するdiffusion language modelとして扱う。(huggingface.co)

今回の設計の核は「tri-mode」にある。同じモデルが、通常のAR生成、ブロック単位で埋めていくdiffusion生成、そしてdiffusionで下書きしてARで検証するself-speculation生成を切り替えられる。これは、ARモデルとdiffusionモデルを別々に用意するのではなく、1つのチェックポイントを複数の推論様式で使うという発想だ。モデルカードでは、attention patternの切り替えだけでAR decodingとdiffusion-based parallel decodingを扱い、self-speculationではdiffusionがドラフトし、ARが検証すると説明されている。(huggingface.co)

技術的には、ARの左から右への強い言語事前分布を捨てずに、diffusionの並列性を足している点が重要だ。技術レポートでは、AR lossとblock-wise diffusion denoising lossを組み合わせ、まず純粋なAR目的で学習し、その後にjoint AR-diffusion objectiveへ移る二段階学習が説明されている。8B系ではMinistral3の事前学習済みモデルを出発点に、Stage 1で1T tokensのAR継続事前学習、Stage 2で300B tokensのjoint AR-diffusion学習を行い、さらに45B tokensでSFTしたとされる。(bit.ly)

性能主張はかなり強い。NVIDIAのブログでは、Nemotron-Labs-Diffusion 8BがQwen3 8Bに対して平均精度で1.2%上回り、tokens per forward passではdiffusion modeがARモデル比2.6倍、linear self-speculationが6倍、quadratic self-speculationが6.4倍に達すると説明されている。技術レポートの8B instruct比較でも、平均精度はAR 63.61、diffusion 63.18、linear self-speculation 62.81、quadratic self-speculation 64.04、平均TPFはそれぞれ1.00、2.57、5.99、6.38と報告されている。(huggingface.co)

ただし、ここは慎重に読むべきだ。これらはNVIDIA側の評価であり、第三者ベンチマークではない。さらに、TPFは「1回のforwardで何トークン進むか」を見る指標で、実際のユーザー体感はハードウェア、カーネル実装、バッチサイズ、入出力長、サービング基盤に大きく左右される。モデルカードではGB200上で8B・concurrency 1の場合に850 tok/s、ARの253 tok/s、Eagle3の360 tok/sに対して高速とされ、カスタムCUDAカーネルでは1015 tok/sとも書かれているが、これは特定条件下の実測として見るのが妥当だ。(huggingface.co)

それでも今回の発表が重要なのは、「より大きいモデル」ではなく「生成の時間構造」を競争軸にしている点にある。これまでLLMの改善は、パラメータ数、データ、ポストトレーニング、ツール使用、長文コンテキストに注目が集まりがちだった。Nemotron-Labs-Diffusionが示すのは、同じようなモデルサイズでも、トークンをどう進めるか、どこまで並列化できるか、検証をどこで挟むかによって、推論の経済性が変わりうるということだ。

特に影響が出やすいのは、低バッチ・低遅延の用途だろう。たとえばローカルAI、対話型コーディング、エージェントの短い思考ステップ、リアルタイム補完のような場面では、巨大なバッチでGPUを埋めるクラウド推論とは別の最適化が必要になる。NVIDIA自身も、AR modeは高並列のクラウドサービング、self-speculationは低並列の個人向け推論、diffusion modeは並列デコードの将来ポテンシャルという位置づけで整理している。(bit.ly)

一方で、diffusion LLMがすぐにARを置き換えると見るのは早い。技術レポートも、従来のdiffusion LMsには精度や学習効率、実用的な効率・精度トレードオフの課題があったと述べている。今回の提案は「ARの代替」ではなく、ARを土台にしてdiffusionを推論時の並列ドラフト能力として取り込む方向に近い。つまり勝負は、モデルアーキテクチャそのものより、学習目的、attention設計、KV cache、サービング実装、検証付きデコードをまとめたシステム設計に移っている。

今後の注目点は三つある。第一に、独立した評価で本当に同等品質・高速が再現されるか。第二に、長文生成やツール呼び出しを含むエージェント実行で、並列ドラフトがどれだけ実効的に効くか。第三に、SGLangやvLLMなどの推論基盤が、こうした非AR的な生成様式をどこまで標準機能として吸収するかだ。ブログではSGLang main branchでの対応予定にも触れており、現時点では実装エコシステム側の成熟も含めて見ていく必要がある。(huggingface.co)

生成AIの次の性能改善は、必ずしも「もっと賢いモデル名」として現れるとは限らない。今回のNemotron-Labs-Diffusionは、言語モデルを速くするとは何を意味するのかを、もう一度低い層から問い直している。出力品質だけでなく、1トークンずつ進む時間の形そのものが、LLMの設計対象になり始めている。

エージェントは「外側で動かす」だけでなく「重みに焼き込む」時代へ

2026年5月22日のarXiv更新枠で、実務寄りのエージェント設計にかなり示唆的な論文が出ている。タイトルは「Compiling Agentic Workflows into LLM Weights」。主張を一言で言えば、LangGraphやCrewAIのような外部オーケストレーターで毎回ワークフローを制御するのではなく、手順そのものを小型LLMの重みにファインチューニングで“コンパイル”すれば、近い品質をより低コストで出せるのではないか、というものだ。arXivページでは投稿時刻は2026年5月21日UTCだが、cs.AIのrecent一覧では5月22日枠に掲載されている。(arxiv.org)

背景にある問題は、現在のエージェント実装が「モデル＋外部ハーネス」に寄りすぎていることだ。外部ハーネスは、どのノードを実行するか、どの条件分岐に進むか、どの情報を次ターンに注入するかを毎回プロンプトやルーティングで管理する。これは開発しやすい一方で、会話ごとに長い手順をコンテキストへ載せるため、トークンコストが増え、レイテンシも伸び、さらに業務上の手順や判断ロジックをAPI提供者側へ露出しやすい。論文は、主要なエージェント・オーケストレーション系フレームワーク群が広く使われていることを前提に、この「外側から毎回制御する」設計を問い直している。(arxiv.org)

提案されるのは、著者らが“subterranean agent”と呼ぶ発想だ。表層にあるプロンプトやワークフローグラフではなく、業務手順を学習データに変換し、小型モデルのパラメータ内部に埋め込む。実行時には複雑なオーケストレーターを置かず、モデル自身が手順を内在化した状態で対話を進める。直感的には、「毎回マニュアルを読ませる」のではなく、「マニュアルを読んで訓練された担当者」を作る、という違いに近い。(arxiv.org)

実験対象は、旅行予約、Zoomサポート、保険請求という三つの手続き型ドメインだ。arXiv要旨では、旅行予約とZoomサポートはいずれも14ノード、保険請求は55ノード・6つの意思決定ハブを含むとされている。これは重要で、論文が狙っているのは自由な創造的推論ではなく、分岐条件と確認事項が明確な「業務プロセス」だ。つまり、すべてのエージェントを重みに焼き込めるという話ではなく、反復され、形式化でき、評価可能な手順に対する最適化として読むべきだ。(arxiv.org)

補助的な整理として公開されている論文サマリーによれば、旅行予約ではQwen 2.5 3B、Zoomサポートと保険請求ではQwen3-8Bを使い、フローチャートから合成会話データを生成してフルパラメータ・ファインチューニングを行う構成になっている。評価軸はタスク成功、情報正確性、一貫性、自然さなどで、Claude Sonnet 4.5によるジャッジとGPT-4.1によるロバストネス確認が使われたとされる。ここはLLM-as-a-judge依存なので、絶対的な業務品質の証明ではなく、比較実験として受け取るのが妥当だ。(commonplace.workforcefutures.net)

結果として注目すべきなのは、単に「小型モデルでもそこそこ動く」という点ではない。サマリーによれば、コンパイル済みモデルはフロンティアモデルに手順をコンテキスト投入する方式に対して、会話あたり128〜462倍安いとされ、保険請求の例ではレイテンシも改善している。失敗率でも、旅行予約で3Bコンパイルモデルが5.5%、LangGraphオーケストレーターが24.0%、保険請求で8Bコンパイルモデルが9%、オーケストレーターが17%という比較が示されている。もちろん、これらは著者設定のドメイン・評価系に依存するが、「外部制御は常に高品質」という直感には揺さぶりをかける。(commonplace.workforcefutures.net)

技術的に面白いのは、これはエージェントの「コンパイル」という見方を重み空間に拡張している点だ。従来のコンパイル的発想は、自然言語の曖昧な指示をJSON、コード、ワークフロー、ツール呼び出しへ落とし込む方向だった。今回の論文は逆に、明示的なワークフローを教師データ化し、モデル内部の行動分布へ移す。外部グラフを消すことで可観測性は下がるが、推論時のトークン注入、分岐プロンプト、ルーティング呼び出しを削れる。これは「エージェントを賢くする」よりも、「繰り返し使う手順を実行時コストから学習時コストへ移す」研究だと見ると理解しやすい。

ただし、限界もはっきりしている。第一に、手順が頻繁に変わる業務では再コンパイルが必要になる。サマリーでは更新サイクルは30〜50分程度とされるが、これはCI/CDに近い運用設計を前提にする。第二に、手順外の広い世界知識が必要な場面では、フロンティアモデルへコンテキストを与える方式の方が有利になりうる。第三に、フルパラメータ・ファインチューニングが使われており、LoRAのような軽量適応では同等に届かなかったと整理されている。つまり、誰でも即座に低コスト化できる魔法ではない。(commonplace.workforcefutures.net)

実務への含意は大きい。エージェント開発では、何でも汎用LLMに毎回考えさせるのではなく、次の三層に分ける設計が重要になる。

1. 変わらない手順：コード化・ルール化する
   
2. 反復されるが自然言語対話が必要な手順：小型モデルへコンパイルする
   
3. 毎回未知性が高い判断：フロンティアモデルや外部検索を使う
   

この論文は、2番目の層をかなり具体的に示した点で価値がある。エージェント競争は、モデル単体の能力だけでなく、「どの知識をプロンプトに置き、どの知識をコードに置き、どの知識を重みに置くか」という配置設計の競争になりつつある。外側のワークフローをすべて捨てる必要はない。ただ、毎回同じ手順を長いプロンプトで読ませ続ける設計は、これから少しずつ贅沢品になっていくかもしれない。

「埋め込みモデルの順位」は、プロンプト一つで入れ替わるかもしれない

2026年5月21日にarXivへ投稿された論文「One prompt is not enough: Instruction Sensitivity Undermines Embedding Model Evaluation」は、RAGや検索システムの土台になっている埋め込みモデル評価に、かなり実務的な疑問を投げかけている。主張はシンプルだ。Instruction-tuned embedding modelを、タスクごとに固定された単一プロンプトだけで評価すると、そのスコアはモデルの安定した能力ではなく、「たまたま選ばれた言い回し」に大きく依存してしまう。(arxiv.org)

論文は、6つの埋め込みモデル、11のデータセット、各データセット15種類のタスク固有プロンプト、合計990評価でこの問題を調べている。対象モデルには Qwen/Qwen3-Embedding-0.6B、intfloat/multilingual-e5-large-instruct、KaLM-Embedding/KaLM-embedding-multilingual-mini-instruct-v2.5、BAAI/bge-small/base/large-en-v1.5 が含まれ、タスクは検索、分類、クラスタリング、意味的類似度にまたがる。公開GitHubにも、MTEB実験を回すコード、生成プロンプト、キャッシュ済み評価結果の構成が示されている。(github.com)

ここで重要なのは、埋め込みモデルが「裏方」ではなくなっている点だ。生成AIアプリでは、LLM本体の前に検索がある。社内文書RAG、コード検索、FAQ検索、法務・医療・金融のナレッジ検索では、どの文書をLLMに渡すかを埋め込みモデルが決める。つまり、埋め込みが少し揺らぐだけで、LLMの回答品質も揺らぐ。MTEBは埋め込み・検索システムを評価する代表的フレームワークで、分類、クラスタリング、検索、STSなど多様なタスクを扱う。現在のMTEBは1000以上の言語と多様なタスクをカバーする大規模評価基盤として運用されている。(huggingface.co)

この論文の新しさは、「良いプロンプトを探すと性能が上がる」という一般論ではない。より鋭いのは、評価値そのものが分布であるべきだ、という指摘だ。著者らは、デフォルトプロンプトのスコアが、妥当なプロンプト集合に対する性能分布を過大評価する場合も、過小評価する場合もあると報告している。さらに、プロンプトを都合よく選べば、研究対象のどのモデルでも模擬リーダーボード上で1位に押し上げられるという。これはモデルを改善せず、評価の入口だけを変えて順位を動かせることを意味する。(arxiv.org)

この構図は、生成AI評価全体で繰り返し出てくる問題に似ている。チャットモデルでは、システムプロンプト、温度、few-shot例、採点プロンプトの違いが結果を変える。エージェント評価では、ツール記述や履歴の与え方で成功率が変わる。今回の論文は、それと同じ揺らぎが「検索前のベクトル化」という低レイヤーにも存在することを示した。派手ではないが、むしろ土台に近いぶん影響範囲は広い。

実務上の含意は明確だ。RAGシステムで埋め込みモデルを選ぶとき、公開リーダーボードの平均点だけを見て決めるのは危うい。少なくとも、自社のクエリ文体、検索対象文書、ユーザーの指示パターンに近い複数プロンプトで再評価した方がよい。特に「次の質問に答えるための文書を探せ」「関連する根拠を検索せよ」「この主張を検証する資料を探せ」のような微妙な指示差がある運用では、モデルごとの順位が変わる可能性がある。

ベンチマーク側への提案も妥当だ。単一スコアではなく、複数プロンプトに対する平均、分散、最悪値、順位安定性を併記する。論文も、単一プロンプト評価ではなく、複数プロンプト評価または感度指標を報告すべきだと結論づけている。これはコスト増にはなるが、「たまたま相性のよい言い回し」をモデル能力と誤認するよりは健全だ。(arxiv.org)

ただし留保もある。今回の研究は6モデル・11データセットの範囲であり、すべての埋め込みモデルや全RAG用途にそのまま一般化できるわけではない。また、プロンプト集合をどう作るか自体にも設計選択が入る。公開リポジトリでは、15種類の合成プロンプトをLLMで生成する手順が示されているが、プロンプト生成器の癖が評価分布に影響する可能性も残る。(github.com)

それでも、この論文の価値は大きい。LLMアプリの品質は、モデル単体ではなく、検索、プロンプト、評価、ランキングの組み合わせで決まる。埋め込みモデルの「順位」がプロンプトの言い回しで動くなら、リーダーボードは順位表というより、評価条件つきの測定結果として読まなければならない。今後の埋め込み評価は、「どのモデルが一番か」から、「どの条件で、どれだけ安定しているか」へ移るべきだと思う。

出典：
arXiv「One prompt is not enough: Instruction Sensitivity Undermines Embedding Model Evaluation」(arxiv.org)
GitHub repository「centre-for-humanities-computing/instruction-sensitivity-evaluation」(github.com)
MTEB / Hugging Face organization page(huggingface.co)

AIチャットボットは「ニュースの入口」になれるのか：スタンフォード系チームの実時間評価が示したもの

2026年5月22日のarXiv cs.CL新着で、Mirac Suzgun、Emily Shen、Federico Bianchi、Alexander Spangher、Thomas Icard、Daniel E. Ho、Dan Jurafsky、James Zouらによる「Evaluating Commercial AI Chatbots as News Intermediaries」が公開された。所属はStanford University、Together AI、独立研究者を含む構成で、対象は商用AIチャットボットがニュースをどの程度正確に媒介できるか、である。論文そのものはモデル発表ではないが、生成AIの実利用にかなり近い地点を測っている点で重要だ。(arxiv.org)

研究の設計は分かりやすい。著者らはBBCの6つの地域サービス、すなわちUS & Canada、Arabic、Afrique、Hindi、Russian、Turkishから同日ニュースを集め、各地域ごとに毎日25問の5択質問を作成した。質問は記事固有の具体情報、たとえば数値、場所、引用者、時刻と場所の組み合わせなどを問う形式になっている。評価期間は14日間で、合計12,600件のモデル・質問インスタンスを得ている。対象モデルはGemini 3 Flash、Grok 4、Gemini 3 Pro、Claude 4.5 Sonnet、GPT-5、GPT-4o Miniで、各社のネイティブなWeb検索を有効にした本番系のチャットボットとして評価されている。(suzgunmirac.github.io)

まず目立つのは、上位システムの正答率がかなり高いことだ。クリーンな5択条件では、Gemini 3 Flashが95.6%、Grok 4が95.0%、Gemini 3 Proが93.7%、Claude 4.5 Sonnetが90.4%と報告されている。少なくとも「数時間前に報じられたニュースを検索して答える」能力について、現在の商用システムはかなり実用域に近づいている。ただし、この高い平均値だけを見ると論文の核心を見失う。(suzgunmirac.github.io)

本当に重要なのは、精度のばらつき方だ。地域別に見ると、5地域は88.9〜91.3%にまとまる一方、Hindiだけが79.3%に落ち込んでいる。しかも、これは特定モデルだけの癖ではなく、評価された全モデルでHindiが最も低い。著者らは、これは「ヒンディー語を生成できない」問題ではなく、検索・根拠づけの問題だと説明している。モデルは流暢に答えられるが、英語版Wikipediaや英語要約など、記事固有の事実とずれた別ソースへ寄ってしまう。つまり失敗は、言語能力そのものよりも「正しい証拠に接続する能力」の失敗として現れている。(suzgunmirac.github.io)

この論文が面白いのは、チャットボットのニュース回答を「LLM単体の知識テスト」として扱っていない点にある。著者らは、エラーの70%以上がソースの相違または検索失敗に由来するとしている。正しいソースを見つけた場合、モデルは多くの場合そこから答えを抽出できる。逆に言えば、実運用での品質を決めているのは、基盤モデルの推論力だけでなく、検索インデックス、ランキング、地域別ソース選択、ライセンスやrobots.txt制約を含む取得パイプライン全体である。(suzgunmirac.github.io)

そのことは検索無効化の実験でさらに明確になる。US & Canadaの質問でWeb検索を切ると、4つのフロンティアモデルの正答率は51〜61%まで下がり、検索ありとの差は31〜46ポイントに達した。これは「チャットボットがニュースを知っている」というより、「チャットボット＋検索基盤がニュースに接続している」と読むべき結果だ。ニュース応答の信頼性を評価するなら、モデルカードだけでは足りず、検索基盤を含むシステムカードが必要になる。(suzgunmirac.github.io)

さらに、5択評価は上限値として読む必要がある。著者らは自由回答形式の検証も行っており、5択から自由回答に変えると絶対精度が16〜17ポイント低下した。ただしモデル順位は維持されたという。これは重要な留保だ。選択肢がある評価では、検索結果が多少不完全でも「近い選択肢を選ぶ」ことで救われる場合がある。実際のユーザーは多くの場合、選択肢なしで「何が起きたの？」と尋ねる。その自然な利用場面では、論文中の5択スコアより低い性能を想定する方が安全だ。(suzgunmirac.github.io)

もう一つの重要な発見は、誤った前提への弱さである。質問に微妙な false premise、つまり自然に見えるが一部だけ間違った前提を混ぜると、標準条件で88〜96%だった上位モデルの正答率が、低いものでは19%まで落ちる。さらに、誤前提に気づく能力と最終的に正答する能力は一致しない。Claude 4.5 Sonnetは誤前提検出率が78%でも正答率は46%、Grok 4は検出率59%でも正答率70%だったとされる。これは「疑う力」と「正しい根拠を回収する力」が別々の能力であることを示している。(suzgunmirac.github.io)

出典表示の差も見逃せない。すべての質問はBBC記事に基づくにもかかわらず、BBC URLを引用する率はGrok 4が28.5%で、Gemini 3 Flashが6.9%、Gemini 3 Proが4.1%、GPT-5が0.2%、Claude 4.5 SonnetとGPT-4o Miniが0.0%と大きく異なる。著者らは、この差が単純な検索能力だけでなく、BBCのrobots.txt、スクレイピング制限、ライセンス遵守の違いを反映している可能性に注意を促している。ニュースの「正しさ」は、モデル内部だけでなく、どの媒体にアクセスでき、どの媒体を引用でき、どの媒体を避ける設計になっているかによっても左右される。(suzgunmirac.github.io)

この研究の社会的な意味は、AIがニュースを「要約する道具」から「入口」に変わりつつある点にある。ユーザーが検索結果一覧ではなくチャットボットの単一回答を見るようになると、モデル選択は単なるUIの好みではなくなる。どの地域のニュースが正しく拾われるか、どの言語の一次情報が迂回されるか、どの媒体が引用されるか、誤った前提をユーザーが持ち込んだときに訂正されるか——これらが情報環境の構造になる。著者らも、AI媒介ニュースアクセスの評価では、平均正答率だけでなく、言語横断の検索忠実性、出典表示、ライセンス制約、ユーザー質問の不完全さへの頑健性を見るべきだと述べている。(suzgunmirac.github.io)

もちろん留保もある。対象はBBCという特定の報道機関であり、BBCは信頼性が高い一方、アクセス制約やライセンス条件が特殊に効きうる。クエリは米国ベースのサーバーから発行されており、検索パーソナライゼーションや地域ソースの取得に影響した可能性がある。さらに商用チャットボットは短期間で変化するため、この14日間の結果を恒久的なモデル序列として読むべきではない。GitHubでは再現用ノートブック、結果JSONL、図表生成コードが公開されているが、BBC収集・質問生成・モデル問い合わせの全パイプラインは、日々のニュース可用性に依存するため含まれていない。(suzgunmirac.github.io)

それでも、この論文は今後の評価設計にかなり実用的な方向を示している。AIニュース回答を評価するなら、単に「正解したか」だけでなく、どの証拠に到達したか、どの言語のソースを使ったか、出典表示は媒体の制約と整合しているか、誤った前提を訂正できるか、自由回答でも崩れないかを測る必要がある。モデル競争の表舞台では推論力や長文処理が語られがちだが、ニュースの現場で問われるのは、もっと地味な「証拠への接続の忠実さ」なのだと思う。

本日は生成AI時代のチェックに取り組みました！
QXAIの音声の出力が安定してきたなと思いました！修正音声も同じMITSUKIが話しているようで違和感なく繋げられます。音声スピードが少し揺れたりはまだあります🙇‍♀️
あと、音声最後にブツっとキレてしまうこともたまにあります
(毎回じゃない)(ナレーションの後に何か余分にテキスト入力すれば改善します)

謎の風邪が流行っているとニュースで話題になっていましたが、旦那がまさに謎の風邪にかかってしまいました。
血液検査で、白血球とタンパク質の値から、ウィルスの可能性が高いけど、何かは分からないから抗生物質飲むといった状況です🙄

Qwen3.7-Max発表：エージェント時代の競争軸は「賢い返答」から「長く壊れず働く」へ

2026年5月21日、Alibaba Cloud / Qwenチームが新しいフラッグシップモデル「Qwen3.7-Max」を発表した。今回の発表で見るべき点は、単にベンチマークの点数が上がったことではない。Qwenチーム自身がこのモデルを「agent era」向け、つまりAIエージェントの基盤モデルとして位置づけている点にある。公式説明では、コード生成・デバッグ、オフィスワークフロー自動化、数百〜数千ステップにわたる自律実行を主用途としている。(alibabacloud.com)

一番象徴的なのは、約35時間の連続自律実行デモだ。Qwen3.7-Maxは、T-HeadのZhenwu M890 PPU上で、SGLangのExtend Attention Kernelを最適化する課題に取り組み、432回のカーネル評価と1,158回のツール呼び出しを行ったとされる。公式発表によれば、最終的にTriton参照実装に対して幾何平均で10倍の高速化を達成した。もちろんこれはAlibaba側の内部評価であり、第三者検証済みの性能値として読むべきではない。それでも、「数分だけ賢い」モデルではなく、「何十時間も試行錯誤し続ける」モデルを前面に出してきたこと自体が重要だ。(alibabacloud.com)

技術的に面白いのは、Qwen3.7-Maxが「cross-harness generalization」を強く主張している点だ。Qwenチームは、Task、Harness、Verifierを分離した環境で学習・評価し、同じ課題を異なるエージェント実行環境や検証器と組み合わせることで、特定のツール枠組みにだけ過剰適応しない能力を狙ったと説明している。これは、エージェント評価でよく起きる「そのベンチマークの作法だけを覚えた」問題への応答でもある。Claude Code、OpenClaw、Qwen Codeなど複数のスキャフォールドで動くことを売りにしているのも、その文脈で理解できる。(alibabacloud.com)

実装面では、Qwen Cloudのモデルページに、1Mトークンのコンテキスト、最大約65Kトークンの出力、Function Calling、Structured Outputs、Batch、Web Search、Code Interpreterなどが示されている。価格は入力100万トークンあたり2.5ドル、出力100万トークンあたり7.5ドル、キャッシュ読み取りは100万トークンあたり0.25ドルとされている。長時間エージェントでは同じリポジトリ、仕様書、ログ、過去の推論を何度も参照するため、キャッシュ価格の設計は単なる課金表ではなく、実用コストを左右する中核仕様になる。(qwencloud.com)

今回の発表は、モデル単体ではなくフルスタック戦略としても読める。Alibabaは前日発表で、Qwen3.7-Maxに加え、Panjiu AL128 Supernode Server、Zhenwu M890 AIプロセッサ、ICN Switch 1.0、T-Head SAILソフトウェアスタックを打ち出している。Zhenwu M890は前世代比3倍の性能、144GBのメモリ、800GB/sのチップ間帯域、FP32からFP4までの精度対応が説明されている。これは「モデルをクラウドAPIで提供する」だけではなく、エージェントの推論需要を前提に、チップ、サーバー、ネットワーク、モデルサービスを縦に統合する動きだ。(alibabacloud.com)

ここで起きている変化は、LLM競争の評価軸の移動だと思う。従来のモデル発表は、MMLU、GPQA、Humanity’s Last Exam、SWE-benchのような単発または比較的短い評価で語られがちだった。Qwen3.7-MaxもSWE-Verified 80.4、MCP-Atlas 76.4、GPQA Diamond 92.4など多数のスコアを示しているが、より本質的なのは「失敗ログを読み、コンパイルし、プロファイルし、仮説を立て直し、また走る」というループの持続性を能力として提示したことだ。(alibabacloud.com)

ただし、留保も大きい。第一に、35時間デモは印象的だが、単一タスクの内部評価である。タスク選定、評価スクリプト、失敗時の停止条件、ツール環境、比較モデルの設定が公開されなければ、一般化可能性は判断しにくい。第二に、Qwen3.7-Maxは現時点でプロプライエタリなAPIモデルとして扱われており、従来のQwen系オープンウェイト文化を期待していた開発者にとっては方向転換にも見える。VentureBeatも、この点を「API-only」として論じている。(venturebeat.com)

今後の焦点は三つある。第一に、Qwenチームが予告している技術レポートで、環境スケーリングやcross-harness RLの詳細がどこまで開示されるか。第二に、外部評価機関や開発者が、長時間エージェント性能を再現できるか。第三に、Alibabaのチップ・クラウド・モデル統合が、NVIDIA GPU中心の現在の生成AIインフラにどれだけ実効的な選択肢を作るかだ。

Qwen3.7-Maxの発表は、「次のモデルはどれだけ賢いか」という問いを、「そのモデルはどれだけ長く、現実の環境で、壊れずに改善を続けられるか」へ押し広げている。エージェントの本番運用では、瞬間最大風速よりも、疲れない作業者としての安定性が価値になる。その意味で今回のニュースは、ベンチマーク競争の続きであると同時に、LLMの使われ方そのものが変わりつつあることを示す発表だった。

出典：Qwen公式発表、Qwen Cloudモデルページ、Alibaba Cloud公式発表、AI Watch報道、VentureBeat報道。(alibabacloud.com)

GoogleがAI検索に広告を“埋め込む”段階へ

2026年5月20日、GoogleはGoogle Marketing Live 2026で、Geminiを使った新しい検索広告フォーマットを発表した。単なる「検索結果の上に広告を出す」話ではない。AI Modeの会話的な回答や推薦リストの中に、広告が説明つきで現れる設計へ進む、という発表だ。Googleは新形式として、ユーザーの具体的な質問に合わせて広告クリエイティブを生成する「Conversational Discovery ads」と、AI Modeの推薦リスト内に広告を表示する「Highlighted Answers」を示している。いずれも「Sponsored」と明示され、Geminiが商品・サービス情報を評価・要約するAI explainerを添えるという。(blog.google)

重要なのは、広告が「ページの周辺」に置かれるものから、「回答生成プロセスの一部」に近づいている点だ。従来の検索広告は、キーワード、入札、品質スコア、リンク先の組み合わせで検索結果の枠に表示されるものだった。今回の形式では、ユーザーの検索は短いキーワードではなく、「雨上がりの森や高級スパのような香りを、手間なく家で再現したい」といった長い意図の記述になる。Geminiはその文脈を読んで、広告主のサイトや商品情報から関連特徴を引き出し、広告として提示する。つまり最適化対象は「キーワード」から「会話文脈」へ移る。(blog.google)

同時にGoogleは、AI-powered Shopping adsとBusiness Agent for Leadsも示した。前者は、たとえばエスプレッソマシンの検索に対し、Geminiが関連商品を取り上げ、その商品がなぜ条件に合うかを説明する。後者は、広告内にブランドのチャットエージェントを置き、大学選びのような検討型の問い合わせに、広告主サイトの情報をもとに答えさせる仕組みだ。広告はクリック先へ誘導する静的な看板ではなく、対話・説明・リード獲得の入口になる。(blog.google)

この動きは、Googleが別途進める「agentic commerce」とも接続している。Googleは同日、Universal Cart、Agent Payments Protocol、Universal Commerce Protocolを軸に、Search、Geminiなどをまたいで買い物を進める構想を説明した。UCP対応の買い物では、ユーザーが複数の小売業者の商品をカートに入れ、Google Payで購入したり、販売元サイトへ移動して完了したりできる。Googleは、Nike、Sephora、Target、Walmart、Wayfair、Shopify加盟店などで一部チェックアウト機能を試せるようにするとしている。(blog.google)

ここで広告・検索・決済が一本の流れになる。発見、比較、説明、割引提示、購入までがAI ModeやGoogle Maps上の会話に吸収されていく。GoogleはUCPをホテル予約やフードデリバリーにも広げ、今後、AI Modeでホテルを予約したり、Google Mapsの会話から食事を注文したりできるようにすると説明している。これはECサイトにユーザーを送る検索エンジンというより、検索エンジン自体が取引の作業空間になる変化だ。(blog.google)

広告主側の影響はかなり大きい。今後は広告文の巧さだけでなく、商品フィード、在庫、価格、返品条件、FAQ、レビュー、ブランドガイドライン、ランディングページの構造化が、そのままAIに解釈される入力になる。GoogleもMerchant CenterのAI performance insightsや、会話的な検索に合わせて商品説明を更新する「conversational attributes」に触れている。要するに、マーケティングは「人に見せる文章」だけでなく、「モデルが誤解なく読むデータ整備」へ寄っていく。(blog.google)

一方で、慎重に見るべき点もある。Googleは広告ラベルとAI explainerで透明性を担保するとしているが、問題はラベルの有無だけではない。AIが「この商品はあなたに合いそうです」と説明するとき、その説明は広告主の主張なのか、Googleの推論なのか、モデルによる要約なのかがユーザーには見えにくい。説明が正確でない場合、責任の所在も複雑になる。広告審査は、従来のクリエイティブ審査から、生成された説明文・会話履歴・商品データの整合性監査へ広がるはずだ。

もう一つの論点は、推薦品質と収益動機の分離だ。AI検索の価値は、ユーザーにとって最も有用な選択肢を短く示すことにある。しかし広告は、当然ながら入札やキャンペーン設計に影響される。Sponsored表示があるとしても、AIが生成する推薦リストの中で広告がどのように順位づけられ、非広告の候補とどう区別されるのかは、今後の信頼性を左右する。特に医療、金融、教育、旅行のような検討コストが高い領域では、「便利な要約」と「商業的誘導」の境界をかなり丁寧に設計する必要がある。

今回の発表は、GoogleがAI検索をどう収益化するかの具体像を見せた点で大きい。生成AIの検索体験は、広告と相性が悪いと言われてきた。答えが一つにまとまるほど、従来の検索結果ページにあった広告枠や比較の余地は減るからだ。Googleの答えは、広告を減らすのではなく、会話・推薦・購入の文脈に合わせて再設計することだった。

これは短期的には広告主向けの発表だが、長期的には「AIが商業的意思決定をどう仲介するか」という社会実装の話でもある。ユーザーの問いを理解し、候補を選び、理由を説明し、購入まで進めるAI。その中に広告が入るなら、必要なのは派手なデモよりも、説明責任、監査ログ、出典管理、ランキング基準の透明性だと思う。便利さが増すほど、検索は中立な窓ではなく、意思決定の編集者になる。今回のGoogle発表は、その移行がかなり現実的な段階に入ったことを示している。

「指示に従うAI」と「空気を読むAI」は、ときどき衝突する

2026年5月21日のarXiv cs.CL新着で、気になる論文が出ていた。タイトルは “Do as I Say, Not as I Do: Instruction-Induction Conflict in LLMs”。直訳すれば「私の言う通りにせよ、私のする通りにするな」。LLMのふるまいを考える上で、かなり良い題名だと思う。論文が扱うのは、明示的な指示と、会話履歴から誘導されるパターンが衝突したとき、モデルはどちらを優先するのか、という問題である。arXivの新着一覧では、5月21日の新規投稿として掲載されている。(arxiv.org)

実験設計は単純だが、実用上の含意は大きい。研究者たちは、ユーザーが「ターゲット行動T」を明示的に指示する会話を作る。たとえば、特定の形式で答える、特定の言語で答える、あるペルソナを維持する、といったものだ。その一方で、会話中にはそれと競合する「パターンP」を示すハードコード済みのアシスタント発話を複数入れる。つまり、言葉では「こうしろ」と言われているが、履歴上では「みんなこうしている」と見える状況を作る。そして13種類のモデル、16種類の指示、最大50ターンにわたって、モデルが指示に従い続けるか、履歴上のパターンに引きずられるかを測る。(arxiv.org)

結果の要点は、LLMの「指示追従」はかなりモデル依存で、平均的な指示追従率はモデルごとに1%から99%まで大きくばらつく、というものだ。しかもこのばらつきは、標準的な能力ベンチマークとはあまり相関しないと報告されている。これは重要だ。数学が強い、コードが書ける、知識問題で高得点を出す、といった能力と、「長い会話の中で、明示指示をどれだけ保持できるか」は別の能力かもしれない。(arxiv.org)

さらに面白いのは、モデルが単純に「意味を理解していれば頑健」なのではない点だ。論文の要約によれば、指示内容がモデルの訓練済み価値観に沿っている場合は、モデルは誘導に長く抵抗しやすい。また、出力形式も効く。単一トークンのような狭い出力より、多様な複数トークンの応答のほうが、パターン誘導に対して頑健だったという。Chain-of-Thoughtは頑健性を改善するが、問題を消すわけではなく、正しく考えているように見える推論と、最終出力の失敗が分離する場合もある。(arxiv.org)

これは、従来の「プロンプトインジェクション」理解を少し広げる。OpenAIは以前から、LLMがシステムプロンプトや開発者指示と、ユーザー・外部コンテンツ由来の指示を同じ優先度のものとして扱ってしまうことが脆弱性の一因だと説明し、Instruction Hierarchyという考え方を提案してきた。つまり、どの指示が上位で、どの指示を無視すべきかをモデルに学習させる方向である。(openai.com)

しかし今回の論文が示しているのは、敵対的な「この指示を無視せよ」という文がなくても、会話履歴そのものがモデルを別方向へ押すことがある、という点だ。これは明示的な命令の衝突ではなく、帰納的な圧力の問題である。人間でいえば、上司から「必ず敬語で対応してください」と言われているのに、過去50件の対応ログが全部くだけた口調だったとき、ついログ側の文体を真似してしまうようなものだ。モデルは「ルールを読む機械」であると同時に、「直前までの文脈をなめらかに継続する機械」でもある。

この論点は、エージェント設計で特に効いてくる。単発チャットなら、指示と入力の関係は比較的見えやすい。だが、エージェントは長い履歴、ツール実行ログ、過去の失敗、部分的に生成されたファイル、他エージェントの発話を抱え込む。その中に誤った形式や不適切な判断が繰り返し現れると、それは単なるノイズではなく、次の行動を形作る「実例」になる。安全性を考えるなら、危険な文字列を検出するだけでなく、履歴中に蓄積する誤った実演がどれほどモデルを動かすかも評価しなければならない。

実務的には、評価ベンチマークの作り方が変わる。モデルに「このルールを守れ」と一度だけ言って、その直後の応答を見るだけでは足りない。競合する会話履歴、誤ったアシスタント例、長いターン数、単一トークン出力と自由記述出力の違い、推論文と最終回答のズレまで含めて見る必要がある。特に、JSON固定出力、ツール選択、承認フロー、医療・金融・法務のような高リスク領域では、「過去のフォーマットを真似る力」が便利さと脆弱性の両方になる。

もちろん、現時点で見えているのはarXiv新着の要約レベルであり、個別モデル名やプロンプト設計、統計処理の詳細は本文で精査する必要がある。ただ、問題設定そのものはかなり本質的だ。LLMの安全性は「悪い命令を拒否できるか」だけではない。「良い命令を、長い文脈の中で忘れずに保てるか」でもある。出典はarXiv新着一覧およびOpenAIのInstruction Hierarchy関連一次資料。(arxiv.org)

OpenAI内部モデルがエルデシュの単位距離予想を反証——「AIが数学を解いた」の中身を慎重に読む

2026年5月20日、OpenAIは、同社の内部汎用推論モデルが離散幾何の古典問題「平面単位距離問題」に関するエルデシュ予想を反証したと発表した。問題自体は非常に短く言える。平面上に$n$個の点を置いたとき、距離がちょうど1になる点のペアは最大で何個作れるか。エルデシュは1946年以降、この最大数はほぼ線形、より正確には$n^{1+o(1)}$を超えないだろうと予想してきた。OpenAIが公開した証明は、無限に多くの$n$について少なくとも$n^{1+\delta}$個の単位距離ペアを持つ点配置を構成し、この予想を否定するものだ。(openai.com)

まず重要なのは、これは「モデルが計算で巨大な例を見つけた」という話ではない点だ。公開された証明は、代数的整数論、とくに無限類体塔、Golod–Shafarevich理論、完全分解する素数、CM体、Minkowski埋め込みといった道具を使う。大まかには、ガウス整数を使ったエルデシュの古典的な格子構成を、高次の数体へ持ち上げる。そこで各複素埋め込みで絶対値1になる代数的数を大量に作り、それを高次元の格子上の「単位移動」として使い、最後に平面へ射影して単位距離の多い点集合を得る。見た目は幾何の問題だが、反例のエンジンはかなり深い数論にある。(cdn.openai.com)

今回の新しさは、結論だけでなく発見プロセスにもある。OpenAIによれば、この証明は数学専用に訓練されたシステムや、この問題向けの探索スキャフォールドではなく、新しい汎用推論モデルから出たものだという。証明PDFの「AI Use」欄では、モデルにAIが書いた問題文を与え、その出力をAI採点パイプラインが高信頼と判断し、その後にOpenAI内部の研究者と外部数学者が検証・整理した、という流れが説明されている。つまり、最終的に人間が読める形の論文は人間編集を経ているが、中核的な解法の生成は自動で行われた、という主張である。(openai.com)

この点は、過大評価も過小評価も避けたい。外部数学者による companion remarks には、Noga Alon、Thomas Bloom、W. T. Gowers、Daniel Litt、Will Sawin、Arul Shankar、Jacob Tsimerman、Victor Wang、Melanie Matchett Wood らの名前が並び、AI生成証明を「人間が咀嚼し、簡略化し、検証した版」として提示している。これは単なる企業ブログ上の自己申告よりは重い。ただし、現時点で見えているのは公開PDFと専門家コメントであり、通常の査読付きジャーナル掲載とは別の段階にある。数学では「正しいかどうか」が最終的に共同体の精査で決まるため、今後さらに独立した読解、簡約、派生結果が出てくるかが重要になる。(cdn.openai.com)

技術的に面白いのは、モデルが「予想を証明する」方向ではなく「反例を探す」方向へ進んだらしい点だ。companion remarks では、多くの人間研究者がこの予想を真だと見ていたため、反例構成に長く賭ける動機が弱かった可能性が指摘されている。ここに、LLM型の研究支援の一つの性格が見える。モデルは必ずしも人間より深く理解しているから勝つのではなく、人間なら「たぶん無理」と切り捨てる経路を、広い技術語彙と長い試行で掘り続けることがある。今回の事例では、その探索が「高次の数体を使って元の格子構成を一般化する」という、後から見れば自然だが事前にはかなり遠い橋を架けた。(cdn.openai.com)

一方で、これをそのまま「AIが数学者を不要にした」と読むのは粗い。今回の公開物自体が、モデル出力、AI採点、人間研究者による検証、外部数学者による簡略化と文脈化、という多段階の共同作業になっている。Thomas Bloomは、人間が証明を議論し、咀嚼し、改善し、帰結を探る役割は依然として重要だと述べている。むしろ今回見えてきたのは、数学研究のワークフローが「人間が発想し、機械が補助する」から、「機械が候補を出し、人間が意味・正しさ・射程を確定する」へ広がる可能性だ。(cdn.openai.com)

生成AI・LLM分野にとっての含意は大きい。これまで数学能力は、競技数学ベンチマークや定理証明支援の文脈で語られがちだった。しかし今回の主張が持つ意味は、ベンチマークの点数ではなく、未解決問題に対して新しい構成を出し、それが専門家の検証に耐えたという点にある。もちろん、モデル名、再現性、必要な推論計算量、失敗試行の数、探索の一般化可能性はまだ十分に見えていない。それでも、LLMが「既知知識の要約器」から「研究仮説の生成器」へ移る境界線を示す事例として、今後しばらく参照されるだろう。(openai.com)

今回の本質は、AIが一つの難問を解いたことだけではない。人間の数学文化では、どの道を有望と感じ、どの道を捨てるかという直観が研究の速度を決める。LLMはその直観を共有しないため、時に非効率で、時に危うく、しかし時に人間が避けた場所へ踏み込む。単位距離問題の反証は、その「ずれ」が初めて大きな数学的価値を持った例として読める。次に問われるのは、これが孤立した成功なのか、それとも研究の発見過程そのものを変える反復可能な型なのかだ。

LLMEval-Logic解説：LLMの「論理的に見える答え」を、ソルバーで検査するベンチマーク

2026年5月19日、復旦大学NLP Lab系のLLMEvalチームが、LLM向け論理推論ベンチマーク「LLMEval-Logic」をarXivに投稿した。対象は中国語の自然言語論理問題で、単にモデルの最終回答を採点するだけではなく、自然言語を命題論理・一階述語論理へ正しく形式化できているかまで検査する点が特徴だ。論文は査読済み発表ではなくarXiv投稿段階だが、コード、公開データ、評価手順が同時に公開されている。(arxiv.org)

今回の面白さは、「LLMは論理問題に強くなったのか」という問いを、かなり厳密に分解しているところにある。従来の論理推論ベンチマークには、形式論理式から自然言語問題をテンプレート生成するものが多く、問題文が人工的になりやすい。また、最終回答だけを見ると、途中の形式化が誤っていても偶然正解する可能性がある。LLMEval-Logicはこの弱点を避けるため、まず現実的・物語的な中国語シナリオから問題を作り、その後に専門家が形式化を監査し、Z3 SMTソルバーで答えを検証する流れを採っている。(arxiv.org)

構成は大きく二つに分かれる。Baseは単一質問の命題論理・一階述語論理問題で、完全版246問のうち197問が公開されている。各問にはZ3で検証された答え、ゴールド形式化、自然言語から形式論理への対応を評価するルーブリックが付く。HardはBaseをもとに、分岐、撹乱要素、不確実性、集合値出力、反事実、照応・別名表現などで難化した複数サブ質問型の問題で、完全版190問・938サブ質問のうち154問・766サブ質問が公開されている。残り20%は汚染耐性のため非公開ホールドアウトとして維持される。(github.com)

発表値として最も目を引くのは、14のフロンティアLLMを評価したところ、HardのItem Accuracyで最良モデルでも37.5%にとどまったという点だ。さらに、参照シンボルを与えた条件でも、Z3とルーブリックを同時に満たす形式化スコアの最高値は60.16%だったと論文は報告している。これは「答えをそれらしく説明する能力」と「前提から結論が形式的に従うことを保つ能力」の間に、まだ大きな差があることを示唆する。ただし、この数値は著者らの評価設定に依存するため、今後の第三者再現が必要だ。(arxiv.org)

技術的に重要なのは、評価軸が二段になっていることだ。ひとつは自然言語のまま答えを出す直接回答評価。もうひとつは、モデルに自然言語問題を形式論理へ変換させ、その形式化がZ3で正しい答えを導くか、さらに人手設計の原子的ルーブリックを満たすかを見る形式化評価である。GitHubの説明では、評価はnl-base、nl-hard、fl-free、fl-fixedの4段階に分かれ、OpenAI互換エンドポイントから任意のモデルを差し替えて実行できる設計になっている。(github.com)

ここで効いているのがZ3の存在だ。Z3はMicrosoft Research由来のSMTソルバーで、論理式の充足可能性や制約の整合性を機械的に検査するための道具である。LLMの出力をLLMだけで採点すると、採点者モデルの好みや曖昧さが入り込む。もちろんLLMEval-Logicも一部でLLM-as-Judgeを使っているが、少なくとも形式論理に落ちた部分については、ソルバーで機械的に照合できる。これは「AIがAIを採点する」流れに対する、一つの現実的な補強線だ。(microsoft.com)

ただし限界も明確だ。第一に、中国語論理推論に特化しているため、多言語一般の論理能力をそのまま代表するわけではない。第二に、完全版でも436問規模であり、評価対象は厳密な論理推論の一部に限られる。第三に、公開版351行はHugging Face上で取得可能だが、公開データは将来的に学習データへ混入する可能性があるため、非公開ホールドアウトの運用がどれだけ継続されるかが信頼性を左右する。なおデータセットはevaluation-onlyライセンスで、学習・微調整・蒸留・RLHFラベル生成などへの利用を制限している。(huggingface.co)

それでも、この発表は最近のLLM評価の方向性をよく表している。これからのベンチマークは、単なる正答率表ではなく、自然言語、形式検証、非公開テスト、実行可能な評価コードを組み合わせた「評価インフラ」へ近づいていく。特に法律、契約、科学、セキュリティ、金融のように、もっともらしい説明よりも厳密な含意関係が重要な領域では、LLM単体の流暢さではなく、ソルバーや検証器と接続された推論設計がより重要になる。

LLMEval-Logicが示しているのは、LLMが「論理を語れる」ことと「論理を保存できる」ことは別だという、地味だが重要な事実だ。今後のモデル競争では、長い思考連鎖を出せるかだけでなく、その思考を外部検証可能な構造へ変換できるかが問われる。LLMの推論能力を測る物差しは、少しずつ、文章の説得力から検証可能性へ移っている。

出典URL:
https://arxiv.org/abs/2605.19597
https://github.com/llmeval/LLMEval-Logic
https://huggingface.co/datasets/llmeval-fdu/LLMEval-Logic
https://llmeval.com/
https://www.microsoft.com/en-us/research/project/z3-3/

Cohere Command A+公開——「企業向けLLM」はベンチマーク競争から運用密度の競争へ

2026年5月20日、Cohereが新モデル「Command A+（command-a-plus-05-2026）」を公開した。発表の表面だけを見ると、また一つ高性能LLMが増えた、という話に見える。しかし今回の要点は、単なるモデル更新ではなく、これまで分かれていた企業向けLLMの機能——視覚入力、推論、翻訳、多言語、ツール利用、エージェント用途——を一つのモデルに寄せてきた点にある。CohereはCommand A+を、Command Aファミリー最後のモデルと位置づけ、同社初のMixture of Experts（MoE）モデルだと説明している。総パラメータ数は218B、アクティブパラメータは25Bとされる。(docs.cohere.com)

今回の新しさを整理すると、三つある。第一に、Command A+は入力としてテキストだけでなく画像も扱い、推論・ツール利用・構造化出力・引用・多言語処理を同一モデルの能力として掲げている。第二に、対応言語が48言語に拡大され、CohereはすべてのEU公用語を含むと説明している。第三に、Cohereの発表によれば、1基のB200または2基のH100でのデプロイを想定し、Command A Reasoning比で最大110%のスループット向上、30%のレイテンシ低下をうたっている。これはあくまでベンダー発表値であり、第三者評価ではないが、企業導入の観点では重要な主張だ。(docs.cohere.com)

ここで注目したいのは、「賢さ」よりも「運用上のまとまり」である。2025年のCommand Aファミリーでは、Vision、Reasoning、Translateのように用途別のモデルが並んでいた。今回のCommand A+は、それらを一つの本番向けモデルへ統合する方向に見える。企業システムでは、ユーザーの問い合わせが「画像OCR」なのか「翻訳」なのか「長い社内文書を読んだうえでの判断」なのかを事前にきれいに分類できない。モデル選択のルーティングが増えるほど、評価、ログ、権限、課金、障害切り分けは複雑になる。多機能モデルは、最高性能を追うためというより、プロダクション運用の摩擦を減らすために価値を持つ。

一方で、スペックには注意深く読むべき点もある。Command A+のコンテキストウィンドウは128K、最大出力は64Kとされている。以前のCommand AやCommand A Reasoningは256Kコンテキストを掲げていたため、単純に全方向で拡張されたわけではない。長大な社内文書を大量に詰め込む用途では、128Kへの縮小が効く場面もあるだろう。その代わり、64K出力は、長いレポート生成、コード生成、分析結果の構造化などには有利に働く可能性がある。つまりこれは「何でも長く読めるモデル」ではなく、「多機能な業務出力をまとめて扱うモデル」と見た方が正確だ。(docs.cohere.com)

Cohereらしいのは、今回も企業導入を強く意識していることだ。同社のCommandページでは、AIエージェント、ツール利用、多言語、RAGと引用を主要ユースケースとして掲げ、ワークフロー自動化や社内アプリ接続を訴求している。また、CohereのPrivate Deployment説明では、オンプレミスまたはVPC上でモデルを動かし、データを顧客環境内に置く設計を説明している。Command A+もModel Vault経由で本番利用できるとされており、クラウドAPIだけでなく、統制された環境での導入を重視する企業を狙っていることが分かる。(cohere.com)

ただし、現時点で過大評価は禁物だ。発表には「最強のagentic model」「fastest and most performant」といった表現があるが、公開された情報だけでは、SWE系、ツール利用、RAG、OCR、多言語推論の各タスクでどの程度安定するかは判断できない。特にエージェント用途では、単発ベンチマークよりも、失敗時の復帰、不要なツール呼び出しの抑制、権限境界、長時間実行中の状態管理が重要になる。Command A+が本当に企業向けエージェントの基盤になるかは、モデル単体のスコアではなく、運用テレメトリ、監査、ガードレール、評価セットの整備まで含めて見なければならない。

今回の発表は、LLM市場の競争軸が少しずつ変わっていることを示している。派手な会話能力や単一ベンチマークの順位よりも、企業が欲しがるのは「社内データを扱える」「多言語で破綻しにくい」「画像・文書・ツールを同じ枠組みで扱える」「必要なら閉じた環境で動かせる」という性質だ。Command A+は、その方向にかなり明確に振ったモデルだと言える。

今後見るべきポイントは三つある。第一に、第三者ベンチマークで、Cohereの効率性・エージェント性能の主張がどこまで再現されるか。第二に、48言語対応が単なる翻訳品質だけでなく、各言語での推論・ツール利用・引用生成まで実用水準に達するか。第三に、Model Vaultやプライベートデプロイで、実際にどの程度のコスト・レイテンシ・運用負荷になるか。Command A+の価値は、デモの華やかさより、企業システムに入った後の静かな安定性で測られるはずだ。

Googleが5月19日、Gemini APIに「Managed Agents」を追加した。見た目は新しいAPI機能の発表だが、重要なのは、LLMエージェントに必要な実行環境そのものをクラウドサービス化し始めた点にある。単一のAPI呼び出しで、Antigravity agentを安全なクラウドサンドボックス上に起動し、推論、ツール利用、コード実行、ファイル操作、Web閲覧まで行わせる設計だ。カスタムエージェントはAGENTS.mdやSKILL.mdのようなMarkdownファイルで定義でき、Gemini APIではプレビューとして提供される。(blog.google)

これまで「エージェントを作る」とは、モデルを呼び出すだけでは済まなかった。実行用VM、ブラウザ、ファイルシステム、状態管理、権限、ログ、外部API接続、失敗時の復帰を個別に組み合わせる必要があった。GoogleのManaged Agentsは、その重たい周辺部を「エージェント・ランタイム」としてまとめて提供する。Googleは、各インタラクションが環境を作成または受け取り、後続呼び出しでファイルや状態を保持したまま再開できると説明している。つまり、これはFunction Callingの拡張というより、AIが作業する一時的な作業部屋をAPIで借りる仕組みに近い。(blog.google)

同時に発表されたGemini 3.5 Flashも、この文脈で見ると意味がはっきりする。Googleは3.5 Flashを「エージェントとコーディング向け」のモデルとして位置づけ、Terminal-Bench 2.1、MCP Atlas、CharXiv ReasoningなどのベンチマークでGemini 3.1 Proを上回ると主張している。また、出力トークン速度では他のフロンティアモデルより4倍速いとも説明している。ただし、これはGoogle自身の発表であり、現時点では独立した検証結果と切り分けて読むべきだ。(blog.google)

面白いのは、モデル性能の話がすぐに「複数サブエージェント」「長時間タスク」「コードベース移行」「文書処理」といった運用の話に接続されていることだ。GoogleはAntigravity 2.0、Antigravity CLI、SDK、Gemini APIのManaged Agentsを同時に並べ、開発者の作業面を一つのエージェント基盤に寄せている。Gemini CLIからAntigravity CLIへの移行告知でも、複数エージェントが連携して仕事を分割する現実に合わせ、単一のバックエンドに統合すると説明している。(blog.google)

ただし、この方向には明確な注意点もある。Googleのドキュメントでは、Managed AgentsはPublic Previewであり、機密性の高いワークフローでは出力と行動を確認するよう注意している。さらに、サンドボックスはOSレベルで隔離される一方、デフォルトでは外向きネットワークアクセスが無制限で、必要に応じて許可リストで制限する設計だ。認証情報についても、エージェントはアクセス可能な資格情報を使えるため、最小権限や短期トークンの利用が推奨されている。(ai.google.dev)

ここが今回の発表の核心だと思う。エージェントの価値は「賢い返答」ではなく、「どの環境で、どの権限で、どの状態を保持して、どこまで実行してよいか」に移りつつある。Managed Agentsは開発者の負担を下げる一方で、実行ループ、状態管理、サンドボックス、課金、監査の多くをGoogleの基盤に預けることになる。便利さは大きいが、ブラックボックス化とベンダーロックインも同時に進む。

今後の焦点は三つある。第一に、ログと再現性。エージェントが何を見て、どのツールを呼び、なぜその操作を選んだのかを後から追えるか。第二に、権限設計。ネットワーク、ファイル、外部API、決済、メール送信のような高リスク操作を、どれだけ細かく制御できるか。第三に、移植性。AGENTS.mdやSKILL.mdのような定義ファイルが、Google外のエージェント基盤とも相互運用できるのか。

生成AIの競争は、モデル単体の賢さから、モデルが実際に働く「作業環境」の競争へ移っている。今回のManaged Agentsは、その変化をかなり率直に示す発表だった。エージェント時代のAPIとは、もはやテキストを返す窓口ではなく、隔離された小さな作業場を起動するボタンになりつつある。

OpenAIのSynthID採用——AI画像の「真偽判定」から「来歴インフラ」へ

2026年5月19日、OpenAIはAI生成画像の来歴表示を強化し、C2PA Content Credentials、Google DeepMindのSynthID、公開検証ツールを組み合わせる方針を発表した。対象はChatGPT、OpenAI API、Codexなどで生成される画像で、OpenAIはC2PA準拠を進めると同時に、画像内に不可視のSynthIDウォーターマークを組み込む。あわせて、ユーザーが画像をアップロードし、OpenAI由来のC2PAメタデータやSynthID信号が含まれているか確認できる検証ツールも公開プレビューとして提供される。(openai.com)

この発表の意味は、「AI画像を見破る技術が一つ増えた」というより、生成メディアの扱いが“分類器による後判定”から“生成時点からの来歴管理”へ移りつつある点にある。従来のAI検出器は、画像の特徴から「AIらしさ」を推定する仕組みが中心だった。しかし生成モデルの品質が上がるほど、見た目だけで判定する方法は不安定になる。今回の構成は、生成時に署名付きメタデータを付与し、さらに画像そのものに不可視信号を埋め込むことで、後から来歴を確認しやすくする設計だ。

技術的には、C2PAとSynthIDは役割が異なる。C2PAは、メディアの作成元や編集履歴を署名付きメタデータとして持たせる標準で、誰がどのツールで作ったか、どのように変更されたかといった文脈を比較的豊かに表現できる。一方で、メタデータはアップロード、変換、再保存、スクリーンショットなどで失われやすい。SynthIDは画像に不可視の信号を埋め込むため、メタデータより一部の加工に耐えやすいが、それ単体ではC2PAほど詳細な説明は持てない。OpenAI自身も、両者を補完的な層として位置づけている。(openai.com)

重要なのは、OpenAIだけの動きではないことだ。Googleも同日、Search、Gemini、Chrome、Pixel、Cloudにまたがるコンテンツ透明性機能の拡張を発表し、SynthIDがすでに1000億超の画像・動画、6万年分の音声に使われたと説明している。さらにOpenAI、Kakao、ElevenLabsなどがSynthID技術を自社のAI生成コンテンツに導入していくとも述べている。これは、特定企業の透かし技術というより、生成メディア流通の共通レイヤーを作ろうとする動きに近い。(blog.google)

ただし、この仕組みを「AI画像を確実に見破れる魔法」と見るのは危険だ。OpenAIの検証ツールは、OpenAI由来の画像に含まれる対応信号を検出するものであり、画像が正確か、編集されていないか、合法的に使われているか、文脈として誤解を招かないかまでは判断しない。また、信号が検出されない場合でも、その画像がAI生成ではないとは断定できない。メタデータが削除された、ウォーターマークが劣化した、古いモデルや他社モデルで生成された、といった可能性が残る。(help.openai.com)

この限界は研究側からも指摘されている。2026年4月のC2PAに関する独立分析は、現行仕様が高リスク用途で要求される安全目標を十分に満たしていない可能性を指摘し、金融開示、報道、法的証拠のような場面で早期に過信すべきではないと警告している。また、GPT-Image-2関連画像をX/Twitter上で収集した別研究では、TwitterのCDN処理によってC2PA Content Credentialsが系統的に剥がれていたという結果も報告されている。来歴情報は「付ける」だけでは足りず、流通先のプラットフォームが保持・表示・解釈する必要がある。(arxiv.org)

それでも今回の発表は、生成AIの社会実装にとって現実的な一歩だと思う。なぜなら、AI生成物の問題は「本物か偽物か」という二分法だけでは処理できないからだ。AIで作られた画像でも、創作、教育、広告、試作には正当な用途がある。一方で、選挙、災害、戦争、金融詐欺、名誉毀損の文脈では、作成元と編集履歴の手がかりが極めて重要になる。必要なのはAI生成を一律に排除する仕組みではなく、誰が、どのツールで、どの程度加工したのかを確認できる透明性の層である。

今後の焦点は三つある。第一に、OpenAIやGoogle以外の主要モデル、ローカル生成ツール、画像編集アプリがどこまで同じ来歴エコシステムに参加するか。第二に、SNS、ニュースサイト、メッセージアプリがC2PAやSynthID信号を壊さず、ユーザーに分かる形で表示できるか。第三に、「検出できた／できない」をどのように社会的判断へ接続するか。検出結果は証拠の一部にはなるが、それだけで真実性や悪意を決めるものではない。

生成AIの次の競争軸は、モデルの表現力だけでなく、生成物が社会の中をどう移動し、どう検証されるかに移っている。今回のOpenAIとGoogleの動きは、AIメディア時代の“消えにくい荷札”を作る試みだ。ただし、その荷札が本当に役立つかは、荷札を付ける企業だけでなく、運ぶプラットフォーム、読むアプリ、解釈する人間の側の設計にかかっている。

出典: OpenAI公式発表、OpenAI Help Center、OpenAI Verify、Google公式発表、関連arXiv論文。(openai.com)