立福　寛

【論文要約】 「良かれと思って書いたドキュメントがAIを狂わせる」最新論文が示すAIエージェントの意外なボトルネック リポジトリの作成者は「よかれ」と思ってAGENTS.mdやCLAUDE.mdをリポジトリに含めているが、これらのファイルは本当に役に立っているのだろうか？　改めて調査してみると「実は無い方がよいことがわかった」という結論で、なかなかびっくりである。 著者らはあまり知られていないリポジトリを収集して、イシューからバグを修正するタスクを行うベンチマークを新たに構築した。そしてLLMが自動生成したコンテキストファイルを含めたもの、人間が作成したコンテキストファイルを含めたもの、コンテキストファイルを含めないもの、３つのパターンでバグ修正のタスクを実行した。コーディングエージェントはClaudeCode+Sonnet-4.5など４つを利用して測定を行った。 結果として、LLMが自動生成したコンテキストファイルを含めたものは、コンテキストファイルを含まないものと比べて、タスクを完了する性能がわずかに低下する上に、トークンの消費量が２０％も増えた。一方で、人間が作成したコンテキストファイルの場合はタスクを完了する性能がわずかに向上した。 この原因として、コンテキストファイルに含まれるリポジトリの概要が明らかに悪さをしていると著者らは指摘している。コーディングエージェントは目の前のバグを修正するための情報だけが必要なのに、コンテキストファイルにリポジトリの全体構成が書いてあるとそれに従って「これも調べなきゃ！」と広い範囲をみてしまい、結果としてノイズとなる。コンテキストファイルの情報は冗長で、コーディングエージェントはリポジトリ本体から情報を探せるので必要ないのである。 一方で、リポジトリに含まれていない情報を人間が書いて与えるのは有効であった。ただし簡潔なものに限り、網羅的なものは逆にタスクの完了率を低下させた。 異なるコーディングエージェントでコンテキストファイルを参照するとさらに性能が悪化する。これはLLMごとのプロンプトの記述スタイルの差が影響するからである。しかし同じコーディングエージェントから提供されたコンテキストファイルでも性能がわずかに悪化するのも重要な点である。 著者らの結論として、コンテキストファイルに含めないほうがいいもの、含めた方がいいものは以下となる。 含めないほうがいいもの： ・リポジトリの全体構成。LLMが自動で探索した方が賢く動けるため ・一般的なコーディングの心構え。広範で曖昧な指示はプロンプトを無駄に長くするだけ 含めた方がいいもの（最小限にするとよい）： ・コードベースを見ただけでは判別できない暗黙の制約、ツールの制限など（使用してほしいツールのバージョンなど） つまり「AIの行動を縛りすぎないように、絶対に破ってほしくないルールだけを箇条書きで最小限書く」のが2026年での正解である。 一般的に言われていることの逆の結論で大変面白いだけでなく、今すぐ使えるテクニックだと思った。AGENTS.mdが有効かどうかは検証が行われていなかったのは盲点だった。悪影響が出る点を読むと、今のLLMなら確かにそうなると容易に理解できる。盲目的に従うのではなく、批判的な視点を持つのは大事だなと改めて思った。 arxiv.org/abs/2602.11988

【論文要約】 まだプロンプトいじってるの？　プロンプトエンジニアリングからスキルエンジニアリングへの移行と、７つの未解決の課題 こちらの論文はエージェントスキルに関するこれまでの流れをまとめつつ、後半で「７つの未解決の課題」を提案するサーベイ論文である。「未解決の課題」というのが目を引いたので読んでみた。 AIエージェントで現在起こっている変化として、モノリシックな言語モデルから、モジュール化されたスキルを備えたエージェントへの移行がある。2022年から2023年まではプロンプトエンジニアリングの時代であった。プロンプトはモジュール化することができず、バージョン管理や共有が困難であることが実証されている。 2023年から2024年にかけてツールの使用と関数呼び出しが導入され、モデルは外部APIを呼び出すことができるようになった。しかしツールは呼び出されて戻るだけの形である。 2025年からスキルエンジニアリングの時代が来た。スキルとは、指示、ワークフローガイダンス、実行可能スクリプト、参照ドキュメント、メタデータを含むことのできるバンドルであり、関連するものはすべて動的にロードされるようになっている。 このようにプロンプトエンジニアリングからスキルエンジニアリングへの移行が現在の大きなトレンドと言える。 論文ではこの後、MCPの導入、AnthropicのAdvanced Tool Use、CUAアーキテクチャ（エージェントがGUIを操作するもの）の説明が入る。 現在では、大手ベンダーなどのコミュニティからスキルが提供されるようになっているが、調査してみると全体の26.1%に脆弱性が含まれていた。公開されているスキルには、セキュリティ面で大きな問題があることが判明している。悪意のあるスキルとしては、認証情報を流出させるケースと、エージェントの意思決定簿妨害するエージェントハイジャックのケースがあった。 論文では2025年後半までのスキルエンジニアリングに関する情報を整理したあとで、エージェントスキル研究のフロンティアを定義する７つの未解決の課題を特定している。 課題１：ポータビリティ。公開されているスキルは他の環境でも動作するのか？　ClaudeのためのスキルはClaudeの機能に依存しているので、他のエージェントプラットフォームでは動作させるのが難しい。 課題２：大規模スケールでのスキル選択。スキルライブラリが大きくなるにつれて、適切なスキルを選ぶことが難しくなってくる。与えられたタスクに対して、どのスキルをどの順番で使うか？　これが組み合わせ論的に困難になる。 課題３：スキルの構成とオーケストレーション。実世界のタスクでは複数のスキルを組み合わせる必要があるが、このための制御技術が未解決である。 課題４：機能ベースの権限モデル。スキルごとに実行時の権限を制限するセキュリティ機構が必要である。 課題５：スキルの検証とテスト。スキルには標準化されたテストフレームワークがない。 課題６：破滅的な忘却を伴わないスキル学習。新しいスキルを学習したときに、過去のスキルやモデル本来の能力が劣化してはいけない 課題７：新たな評価メトリクス。タスクを完了させたかどうかだけでなく、スキルの質と再利用性も考慮した評価基準が必要である。 著者らはこの７つの中でセキュリティの問題が緊急性が高いという。これはスキルライブラリに限定された話ではなく、あらゆるソフトウェアエコシステムで起こってきたことである。開放性と安全性の間には緊張関係があるということだ。著者らはスキルエコシステムは現在「プレガバナンス」段階にあり、今後数ヶ月の決定が重要になってくると指摘している。 2025年からのスキル導入の流れと、現時点での未解決問題を整理したサーベイ論文だった。長さも本文１１ページしかないので読みやすかった。特に７つの未解決の課題によって、現在のスキルエコシステムの課題がはっきりと整理されたので、分析しやすくなったと思う。 arxiv.org/abs/2602.12430

【論文要約】 AIが自ら「職人技」を編み出す時代へ。スキルと知能が共進化する最新フレームワーク『COS-PLAY』とは？ この研究では「意思決定」と「スキル管理」を完全に分離して、共に進化していくフレームワークを提案する。最近の流行であるスキルの自己改善に関する研究である。原題：Co-Evolving LLM Decision and Skill Bank Agents for Long-Horizon Tasks LLMエージェントで長期的なタスクを実行する場合、次の２つの問題がある。タスクが長いので過去の行動を忘れてしまう。また実行する際に使うスキルが人間が事前に用意したものに固定されるため、改善していくことができない。 著者らはこの２点を解決するためCo-Evolving LLM Decision and Skill Bank Agents（COS-PLAY）を提案する。略称はコスプレと言いたいだけな気もするがw 提案手法は２つのエージェントを利用する。それぞれのエージェントは複数のLoRAアダプタを持つ。すべてのLoRAアダプタは、単一のループ内でGRPO（Group Relative Policy Optimization）という強化学習の手法を使って学習される。 一つ目は意思決定エージェント。タスクを実行しつつ、現在使用しているスキルが最適なものかを確認する。効果のないスキルだったら、他のスキルを検索して切り替える。「スキル検索」と「アクション実行」のための２つのLoRAアダプタを持つ。 ２つ目はスキルバンクエージェント。意思決定エージェントが残した行動履歴から、再利用可能なスキルを自動で抽出して管理する。４つのステージから構成されるパイプラインを扱う。長い行動履歴に分割の境界を提案→意味のある単位に分割する→そのスキルの前提条件・結果を契約の形でまとめる→重複したスキルを整理し、古いスキルを精錬してバンクをキュレーションする。分割、契約、キュレーションの３つのLoRAアダプタを使用する。 COS-PLAYの最大の特徴は、２つのエージェントを「共進化」させていく点である。意思決定エージェントが現在のスキルバンクからスキルを選びタスクを進める。スキルバンクエージェントは行動履歴を分析して、より汎用的な新しいスキルを作成したり、既存のスキルの改善・統合を行う。改善された新しいスキルを使うことで、意思決定エージェントはさらに複雑なタスクを完了できるようになり、より高度な行動履歴が手に入るようになる。 以上のサイクルを２つのエージェントが回すことで、人間が介入せずにエージェントが自律的にスキルを編み出し・磨き上げていくことができる。 「行動する側」と「技術を整理・蓄積する側」の２つのエージェントを共同で進化させることで、長期的なタスクをこなせるようにする研究だった。エージェントによるスキルの自己改善は人気のある研究分野となっており、関連研究が大量に出ている。個人的な予想としては、大手がすぐに仕組みを提供してきそうなので、独自に開発するときはその点に注意したほうがいいのかなと思う。特にコーディングエージェント関係は大手がバチバチにやりあっているところなので、個人レベルでは手を出さない方がいいと思う。 arxiv.org/abs/2604.20987

【論文要約】 Transformerの層を何度もループすることでパラメータ効率を50%改善 ハイパーループTransformerという新しいアーキテクチャによって、言語モデルのパラメータ効率を５０％改善した研究論文。MITの著者３人による論文で、論文の見た目は地味だが、結果は画期的で面白い。 LLMは実行時のメモリを大量に使うので、エッジデバイスでの実行が難しい。そのため利用するメモリ（パラメータ）を削減することに強いモチベーションがある。 Transformerは層を深く重ねるモデルであるが、提案手法は層をループさせることで同等の性能を達成した。全体をループさせるのではなく、層を開始、中間、終了の３つに分けて、中間ブロックだけをループさせる。パラメータ数の比率では、25%, 50%, 20%となるように分割している。Transformerの層を３つに分けると「入力の解釈」→「思考」→「次の単語の予測」という仕事をしていると解釈できて、一番重い「思考」の部分をループによって何度も実行していると考えるとよい。 ループさせる層に既存研究のハイパーコネクションを適用することで、ループしても学習が安定するようにしている。単純な残差接続（足し算）では特定の信号が増幅・劣化しやすく、深いループに耐えられなかった。ハイパーコネクションでは行列によって調整した値を動的に加えるアプローチを使って、これを回避した。 他にはループが何回目かを示すための「ループ位置埋め込み」を導入している。これにより何回目かのループであるかを認識することができる。最初のループでは概要を理解し、徐々に細部を理解していくことで、多角的な視点をもった思考が可能になっている。 測定した結果、既存の24層のTransformerモデルに対して、12層のハイパーループTransformerモデルで同等の性能を達成できた。12層を3–6-3と分割して、6層の中間レイヤーを2回ループした場合の結果である。ループしているので、実行時間と消費電力は元の24層のモデルと同じである。 ループモデルは同じ層を繰り返し利用するので、量子化で悪影響が出る可能性がある。ループモデルと量子化の影響に関する研究は存在しないので、著者らが測定を行ったところ、特に大きな影響はなかった。提案手法はエッジデバイスへの適用が目的なので、これは助かる結果であった。スマホなどのエッジデバイスでのローカルLLM実行が容易になる。パラメータ数が削減されて必要なメモリが減るだけでなく「メモリ読み込み」も減るので、バッテリー消費も減るからである。 次の実験としてループの回数を2, 4, 8, …と増やして性能への影響を調べた（スケーリング）。4回程度までは劇的な性能向上が得られたが、8回以上で飽和することが確認された。ループ回数が増えることで計算時間が増えるので、トレードオフがある。また同じ層での学習なので、獲得できる表現には限界があると思われる。結論としてループ数は4から8回程度が最もコスパのよいラインであった。 実はTransformerの層をループさせるアイデアは2019年の時点で登場しており新しいものではない。またハイパーコネクションの概念も既存研究のものである。著者らはこの２つを同時に適用することでパラメータを50%削減しても同等の性能を達成した。 「ループさせる」という部分を読んだ時に「その考えはなかったなぁ」と思ったのだが、Transformerの登場した直後から存在したようだ。しかし驚異的な性能向上が得られたのは2026年というのは大変面白い。ループのアイデアは正しかったのだが、その活躍はハイパーコネクションの登場まで待つ必要があったのである。 arxiv.org/abs/2604.21254

【論文要約】画像生成モデルは「最強の目」を持つか？ Vision Bananaが示す新時代 これはGoogle DeepMindのVision Bananaという視覚モデルの論文。画像生成モデルを使ってSAM3やDepthAnything3を超えるビジョン性能を達成したというインパクトのある結果になっている。 VisionBananaはNanoBanana Proを少しだけインストラクションチューニングした物である。つまり、画像生成モデルを視覚モデルとして使ってしまおうというアプローチである。画像生成モデルの事前学習が、視覚モデル(基礎ビジョンモデル)を構築する上で重要な役割を果たすという、コンピュータビジョンにおける大きなパラダイムシフトの到来を示している。 著者らはNanoBanana Proに少量のコンピュータビジョンデータ(奥行き推定、表面法線推定、セグメンテーションなど)を使って微調整した。次に得られたモデルをさまざまなビジョンベンチマークで評価した。 ここでの微調整は出力するRGBが変わるだけなので少量の学習データでよく、モデルの元の生成能力も損なわれない。 特筆すべき点はベンチマークの結果、高度に特化したセグメンテーションモデルであるSAM3や、メトリック深度推定においてエキスパートであるDepthAnything3に勝っている点である。 これらの結果はベースモデルに軽量なインストラクションチューニングを施しただけで達成されているので、NanoBananaモデル自体がすでにビジョン理解のための内部表現を持っており、インストラクションチューニングによってロックを解除した、という強い証拠となる。SAM3などの特化モデルは学習に膨大なマスクデータを利用しているのに対して、NanoBananaは極めて少量のデータで同等の能力を得ているのは驚異的である。 タスク特化モデルは人間が注釈をつけた大量のマスクデータを通して学習していたが、VisionBananaは画像生成モデルからセグメンテーションの能力が自然に出現することを実証した。 膨大な量の綿密に作成されたセグメンテーションのデータで学習するのではなく、ベースとなる画像生成モデルによって学習された豊富な表現を利用するのである。 深度推定の例では、学習データに含まれないデバイスによる金閣寺の画像で深度推定を行った。推定された深度値は13mであった。Google Mapで測定したGroundTruthは12.87mであったので、かなり正確に推定できていることがわかった。 著者らは、言語理解、生成、推論、数学、コーディング、エージェントタスクなど、自然言語に埋め込まれた多くのタスクの統一的なインターフェースとして機能することと類似して、画像生成がコンピュータビジョンの普遍的なインターフェースとして機能することを示した。 LLMでなんでもできるようになったのと同様に、画像生成モデルでビジョンタスクも全部行えるようになる、というパラダイムシフトがこれから来る！というインパクトのある内容だった。とはいえモデルの重さの問題は残りそうだなぁと思う。この部分の軽量化が次の研究分野になりそう。 arxiv.org/abs/2604.20329

これはオンポリシー蒸留という手法がなぜ有効なのかを体系的に調査した論文。 通常の蒸留は教師モデルの出力に生徒モデルが合わせていく。これは生徒モデルが無理やり合わせるのでモード崩壊が起こりうまくいかないとことがある。自分が通らない道を無理やり通ることになるので、学習が非効率になる。 提案手法では生徒モデルの現在進行形の回答に対して、教師モデルも回答を出し、両者のトークンごとの確率分布(Logits)のズレを比較し、生徒モデルへバックプロパゲートする。実際には効率化のため数トークン単位でこれを行う。 これまでの蒸留は教師モデルが自転車に乗ったのをみて、生徒モデルが真似してみて違いを修正していた。オンポリシー蒸留では、生徒が少し進むごとに教師が指導する。リアルタイムでで細かいフィードバックをもらって学習を進めていくのが大きな違いである。 このオンポリシー蒸留自体は最近のトレンドで広く使われるようになっているのだが、なぜこれがうまくいくのか、うまくいかないのか、を体系的に調べた研究はなかった。著者らはその点を調査、実験して報告した。 著者らが行った一番面白い実験は逆蒸留である。これは生徒モデルの方が大きいモデルを使う蒸留である。これで通常の蒸留とオンポリシー蒸留を行って比較した。 通常の蒸留では生徒モデルの方が賢くても、教師モデルの癖を学習するのに苦労した。学習時間がかかる上に、結果も頭打ちになった。 オンポリシー蒸留の方は学習がうまくいき、短期間で教師の振る舞いを学習することができた。 今までは生徒モデルの能力不足で蒸留がうまくいかないと結論づけられていたが、これが間違いであることを逆蒸留の実験で示した。問題は生徒のパラメータのサイズではなく、蒸留の方法にあったのである。ここはパラメータサイズこそが重要であるというパラダイムへのカウンターとなっている。 「生徒のレベルが足りないから学習がうまくいかないのだ！」という主張を、頭の良い生徒を使うことで「教え方が悪かっただけなんです！」と覆したのである。この例えだと、論破した感じが出て大変気持ちよい。 じゃあ、全部オンポリシーでいいのか？という話になってくるのだが、オンポリシー蒸留は計算コストなどの問題がまだ残っている。数トークンごとに教師モデルを動かしてバックプロパゲートするので計算コストは大きくなるのである。 arxiv.org/abs/2604.13016

これもAIエージェントを自動学習させる研究で、最近のトレンドの一つ、と思っていたら、思っていたよりやっていることが徹底していた。ある意味えぐい AIエージェントを訓練するためには、現実の予約サイトのような操作して結果が返ってくる環境が必要である。 既存研究ではLLMでこの環境を生成していたが、これは多様性をカバーできない。また現実のサイトはステートフルなので、現在の状態を把握しつつ操作していく必要がある。例えばサイトにアクセスして、ログイン、検索、予約、支払いのように決まった順序で操作しないとタスクを完了できない。 提案手法のAgent-Worldではこの環境の収集をWebから行う。Webサイトにアクセスしてボタンを押して何が起こるかを観察する。そこから裏側で行われていることをLLMで推測して、シミュレーションする環境とロジックをdockerベースで構築する。docker環境の内部ではDBを使って状態の保持も行う。docker環境になっているのでエージェントが好きに弄れるようになっている。失敗してもすぐにリセットできる。 これらの環境はMCP対応になっているので、学習対象のLLMから自由にアクセスできる。 Webサイトをスクレイピングして保存するのではなく、丸ごとクローンしている点が既存研究と大きく違う。 再現したサイトは単体で使うのではなくLLMを使ってバリエーションを出している。自由にスケーリングできるので、学習データのスケーリングによってエージェントの性能向上を調べることが可能となった。 また既存研究では特定のジャンルのサイトだけ扱っているものが多いが、提案手法では幅広い範囲のサイトで収集を行っている。これは多様なサイトを学習することで、未知の分野にも対応する能力を獲得したいという最近のトレンドを受けたものである。 環境の自動収集と構築が提案手法の貢献の一つ目である。今までの手法が「教科書」を与えていたものを「演習場(アリーナ)」に変えて、エージェントに千本ノックをさせるようになったという例えがわかりやすい。 論文のもう一つの貢献はエージェントの強化学習なのだが、長くなるので省略した。 arxiv.org/abs/2604.18292

東京大学の研究だが、単著である点も熱い。

パラメータ数92%削減、推論速度3.2倍。 Transformerの限界を突破する新アーキテクチャ『Multiscreen』が注目されているようだ。論文タイトルは “Screening is enough” 。 「Attention Is All You Need」への挑戦状とも取れる内容である。 従来の研究は「いかにして重要な情報に注目するか」を追求してきた。この論文はその逆で「無関係な情報をいかに切り捨てるか」というアプローチを提案する。 従来のAttention機構はSoftmaxを用いて「相対的な重要度」を計算するが、これは無関係なノイズにも重みを割り当ててしまう欠点があった。提案手法のMultiscreenは、各キーに対して絶対的な閾値で判定を行い、不要な情報を削除してから集約を行う。 たとえば、Softmaxは「AがBよりマシなら、Aに重みを振る」という相対評価だったが、Multiscreenでは「AもBもゴミなら、両方捨てる」という挙動になる。 この変更により、同じトークン予算で、Transformerのベースラインよりも４０％少ないパラメータで同等の検証損失を達成した。まだTransformerでは学習が発散してしまうような大幅に大きな学習率でも、Multiscreenでは安定した最適化が可能である。大きな学習率を使えるので微調整が短時間で実行でき、高速な実験サイクルを回せるようになる。 長文脈評価において、Multiscreenはパープレキシティにおいて強い性能を維持し、学習中に見た長さを遥かに超える文脈長でも、検索性能の劣化をほとんど示さない。AIや統計の分野では、これを外挿性（Extrapolation）が高いと表現するようだ。外挿性は学習した範囲外でも正しく振る舞える能力のことを指す。 条件によってはモデルパラメータが９２％少なくても、一貫してTransformerベースラインを上回る。つまり情報の密度が非常に高いということである。100Kトークンのコンテキストを持つ次のトークン予測では、MultiscreenはTransformerベースラインに対して、推論レイテンシーを2.3-3.2倍削減する。 情報の集約ロジックを相対評価から、絶対選別にシフトさせた点が画期的で、メモリ、速度、精度のすべてにおいてブレイクスルーを達成している。大型のモデル開発だけでなく、エッジデバイスでのLLM実行においても有望なアーキテクチャである。 全員に配分する民主主義をやめて、一部の適格者だけ通す門番を導入したという例えがわかりやすい。 arxiv.org/abs/2604.01178

OpenClawに「メタ学習」を統合した新フレームワーク MetaClawが面白い。従来のエージェントは人間が書いた「静的なSkill」を叩くだけだったが、MetaClawは実行ごとに自ら進化する。 OpenClawはユーザーのPC操作などを行えるエージェントで、いろいろな操作に関するSkillがClawHubという形で共有されている。しかしSkill自体は人間が作っている。 このようなSkillは静的なライブラリとして参照される。あるいはシステムのダウンタイムをとって、モデルの重みへ学習するシステムも存在する。 MetaClawはエージェントを実行していく過程で、失敗から自動的にSkillの更新を行う。ユーザーからの指示を実行した結果を分析する。実行軌跡を分析して、新しい行動指示（Skill）をLLMで合成する。この更新が動的に行われていくので、MetaClawは実行ごとに常に進化していく。自己書き換え型プロンプトのイメージである。 MetaClawが生成するSkillは自然言語なので、人間が読めるテキストである。AIがどのように学んでいるかを確認できるので、現場の知見をAIと共有しやすい。 生成されたSkillはRAGの仕組みで管理され、実行時に関連性の高い過去の教訓がコンテキストに注入される。これにより、モデルの入力コンテキストを有効利用しつつ、タスク特化型の動的なチューニングを実現している。 エージェントが失敗するたびに、実行軌跡が積み上がり、それが貴重な学習データとして利用される。失敗から学んだ結果はユーザー間で共有できるので、一人の失敗が１０人の改善へと繋げることができる。 また夜間にバックグラウンドでSkillをモデルの重みにLoRAで学習させる。既存手法のように学習データを用意して、学習、デプロイという作業を行うと工数がかかる。MetaClawは自律的なルーチンワークになっているので、自動化されたCI/CD的な学習パイプラインで反映させることができる。 使っていくだけでエージェントが賢くなっていくのは夢があるなぁ #MetaClaw #OpenClaw #LLM #AIエージェント arxiv.org/abs/2603.17187

この論文はSSD（Simple Self-Distillation ）という手法を導入した研究。 通常は問題と正解のセットを使って教師あり学習を行ったり、教師モデルからの蒸留でモデルの性能を向上させる。提案手法ではモデル自身の出力だけでコーディングの学習を行い性能を向上させることに成功した。このときにモデルの出力に対して正解・不正解の区別はせずに、そのまま結果を学習しているところがインパクトのある部分である。 なぜこれが有効なのだろうか？　出力が間違っていても、コードを書くという行為自体は間違っていないことが多い。コードの書き方を反復練習することで出力が安定して、難しい問題になっても最後まで破綻せずにコードを書けるようになるのである。 モデルは自分の出力だけを学習していくことで、モデルが本来持っていた出力のノイズ（多様性ともいう）を減らしていく。解いている問題にフォーカスして、それ以外の出力を切り詰めていくように自分自身を変化させていく。結果として、確率分布の裾野が減って、ピークが鋭くなる。 たとえば数学だけ勉強を延々と続けることで、ケアレスミスが減り、数学の得点が上がっていくイメージだろうか。数学に特化しすぎるので、逆に他の教科は苦手になってしまう。 具体的にはQwen3-30B-InstuctモデルでLiveCodeBench v6において、pass@1のスコアが42.4%から55.3%へ向上した。12.9％の向上は通常ではあり得ないレベルの成果である。さらに簡単な問題よりも中・高難易度の問題で改善が大きい。このモデルだけでなく、モデルサイズが変わっても同様の結果が得られた。またThinkingモデルにおいても性能が向上することが確認された。 教師モデルどころか、学習データの正解すら使わないで性能を向上させるという、とんでもない手法で大変面白い。しかし、この方法では他のジャンルの問題に苦手になるのが目に見えているので、ジャンルごとのLoRAを用意して使うなどのアプローチがよいのかもしれない。 arxiv.org/abs/2604.01193

問題を解くためにスキル（特定のプロンプト）を利用するのが流行っている。しかしスキルはプロンプトなので、実行するたびにトークンのコストが増えてしまう。 この論文ではスキル自体を強化学習で学習するSkill-0という手法を提案する。スキル自体をモデルの重みに焼き付ける（内面化させる）ことで、スキルをプロンプトに含める必要がなくなる。これにより、実行時のコストを削減し、推論速度も向上させる。 まずプロンプトにスキルを１００％入れた状態で問題を解かせる。正解した報酬をもらえる。ここまでは通常の強化学習と同じである。つぎにスキルの情報を８０％に減らして問題を解かせる。同様に正解できたら報酬がもらえるのだが、２０％減らしても１００％のときと同じ確信度で回答ができたら追加で報酬がもらえる。つまりヒントを減らしても同じ傾向の回答をできたら追加報酬がもらえるというインセンティブを与えている。 これがなぜ有効なのか？　ヒントを１００％与えている状態で正解して報酬をもらえるという状況では、いつまでもヒントをあてにしてしまい、自分自身で問題を解くというインセンティブが働かないからである。モデルは常に楽に報酬を得られる方法を選んでしまうので、そこを改善したのである。 自転車の練習で例えると、最初は補助輪をつけて練習しているが、補助輪を徐々に浮かしても同じように走れたら大いに褒めてあげるという方法である。 このヒントを徐々に少なくしていく（圧縮する）ことに対して報酬を与えるという部分が提案手法の画期的なところであり、やっていることが直感的で面白い。 arxiv.org/abs/2604.02268

こちらはLLMが入力される文章の長さによって回答性能が劣化するという系統の研究。このタイプの研究は非常の多いのだが、著者らは「検索できても回答はできない」という現象を測定した。 Llama-v3.1-8B-InstructとMistral-v0.3-7B-Instructの２つのオープンモデルで測定を行った。検索性能は文章が長くなっても２％しないのだが、ベンチマークのスコアは13.9%〜85%と大きく低下する。入力文章から証拠となる部分の抽出は問題なく行えるのだが、回答に失敗するのである。 さらに実験を行い、証拠となる箇所が命令の直後にある場合も同様の性能劣化が見られた。これが大変インパクトがある実験なのだが、証拠となる部分以外を「空白」にしても回答性能が低下した。文章の長さが伸びるだけで回答性能が低下する、という結論である。 GPT-4o、Claude3.7-Sonnet 、Gemini-2.0の３つのクローズドモデルでも同様の測定を行った。入力コンテキストが長くなると性能は低下していくのだが、こちら比較的緩やかな低下であった。逆に30Kまで長くする方が性能が向上するケースも観測されている。 著者らはこれを回避する方法として、最初に検索を行い結果を抽出し、それを次の実行で参照して回答することを提案している。 結果は綺麗に出ているが、クローズドなモデルに対しては本当にその結論でいいのか？という疑問を持った。入力コンテキストの長さを30Kまでしか試していないので、GPT-4oクラスのモデルでは十分な測定ができていないと思った。 arxiv.org/abs/2510.05381

こちらは「Speculative Speculative Decoding」という論文。2026年3月なのでかなり新しい。翻訳させると「投機的投機的でコーディング」となる。翻訳結果が間違っているのかと思ったが、これで正しい意味だった。 まずLLMの推論における「投機的デコーディング」について知らなかったのでGeminiに質問して教えてもらった。２０２３年ごろから登場した高速化の手法で、今のモデルでは一般的に使われている手法のようだ。 大きなモデルは推論に時間がかかる。これはVRAM上の巨大なパラメータをGPUで全部実行しないといけないから（密なモデルの場合）。このVRAMからGPUのキャッシュへの読み込みに時間がかかる。LLMの推論で１文字ずつ実行すると、１文字ごとにこの読み込みを行うため、出力に時間がかかる。 投機的デコーディングでは、高速なドラフトモデルと大きなターゲットモデル（検証モデル）の２つのモデルを組み合わせる。これは助手と親方の関係に相当する。助手がまず下書きを５文字分作成する。親方はそれを受け取って、５文字分まとめて検証する。あっていたらそのまま使い、間違っていたら訂正する。助手の下書きを使うことで、親方は一回分の読み出しコストで５文字まとめて処理できるので高速化できる。 この場合、助手の下書きが正確であるほど高速化できる。逆に１文字目から間違っていた場合、親方は下書きを全部捨てて、１文字目から出すので通常のデコーディングと同じ速度になってしまう。正確には助手のデコーディングの分、遅くなるのだが、助手はかなり高速なので無視してよい。また助手と親方は同じ傾向の推論をしてほしいので、親方の蒸留モデルを助手として使うことが多いようだ。 これが投機的デコーディングであるが、従来のものは親方の検証が終わるまで助手は待機していた。この待ち時間が無駄なので、さらに投機的に下書きを作成しよう、というのが提案手法のSaguaroである。投機的デコーディングのさらに投機的実行であるので、投機的投機的デコーディングという論文タイトルになっている。 助手は下書きがどこまで採用されるかの予測を立てる。ここまでは採用されるだろうという点から、次の下書きの作成を始める。予測が外れた場合は別ルートの下書きも作成しておく。このようにサボテンの枝のように枝分かれしていくところから、アルゴリズムのSaguaro（サボテン）という名前になっているらしい。 助手と親方は別々のGPUで実行されることによって、パイプラインが並列化されて高速化が達成される。 この論文の著者の一人がTri Dao氏がFlashAttentionの著者の一人らしく、実行効率を重視した研究であることが推測される。第三著者はTogether AIの人なのも面白い。 結果としては、通常の投機的デコーディングに対して最大２倍の高速化を達成。通常のデコーディングの５倍の高速化となっている。 投機デコーディングって有名どころで使われているの？とGeminiに聞くと「開発者がGoogleなのでGeminiで使っていないはずがありません！」と得意げに内部事情をばらしてきた。まぁそうなんだろうけど。 arxiv.org/abs/2603.03251

こちらはKimiシリーズのVLMであるKimi-VLのテクニカルレポート。かなり詳しく書いてあるのだが、VLMの構築と学習と評価を全部含めると、個別の内容はどうしても薄くなってしまう。今時のVLMの開発方法を知るには、ほどよい分量（本文１９ページ）だと思う。 オープンソースのLLMは非常に早いスピードで進化して、クローズドなモデルに迫る性能を達成している。一方でVLMのほうはスケーラビリティ、計算効率、高度な推論の面でまだ差が大きい。Qwen-2.5-VLやGemma-3はまだ密なアーキテクチャ（MoEでない）に依存しており、長いCoT推論をサポートしていない。DeepSeek-VL2やAriaのようなMoEベースのモデルもあるが、こちらはビジョンエンコードが固定解像度となっており、多様な解像度への対応を妨げている。 Kimi-VLモデルは小さいのに性能が高い点が特徴である。MoEアーキテクチャの採用で活性化パラメータが2.8B（全体では16B）しかないので効率がよい。また400Mのネイティブ解像度のMoonViTビジョンエンコーダを使っているため、小さい文字のOCRなどが非常に得意である。400Mはかなり小さいのだが、解像度を維持する工夫によって高精度を実現している。視覚からステップバイステップで推論するThinkingモデルも提供しているのがもう一つのポイントである。 学習データの構築は従来のVLM同様に幅広いデータを収集している。Kimi-VLではGUIの理解を深めるためにコンピュータの使用軌跡を収集した。これはエージェントとして実世界のデスクトップタスクを完了するためである。学習データの例をみる範囲では英語と中国語のみで、日本語は含まれていないように見える。手描き文字などは言語依存性がとにかく強いので、この辺は日本語独自のモデルの開発する意味が大いにありそう。 VLMの開発のテクニカルレポートなので、通常のLLMのテクニカルレポート相当の内容も含まれており、内容がとにかく多い。当然ではあるが、LLMの開発能力がないとVLMは作れないということ。 評価パートではGPT-4oに匹敵する性能が得られた点が注目ポイントである。オープンソースのVLMでもGPT-4oと同等、タスクによっては超えているのはすごい。 今後の課題では、現状のモデルサイズの制限による高度な専門領域への能力不足を挙げている。まだ多段階推論や深い文脈理解が必要な複雑なタスクに課題がある。コンテキストサイズは128Kあるが、モデルサイズの制限から注意層のパラメータが限られているため、極めて長いコンテキストを扱うにはまだ不十分である。 有名どころのオープンソースのLLM、VLMのテクニカルレポートは今時のモデルがどのように開発されているかの情報源なので、トレンドを追うのに最適な情報源である。とはいえ、2025年6月に出ているので、読むのがちょっと遅かったかな。 arxiv.org/abs/2504.07491

OOLONGは長文コンテキストベンチマークの論文で2025年１１月に発表されたもの。 既存の長文ベンチマークは検索だけのタスクになりがちで、該当箇所以外はノイズとして削除することができる。提案手法のOOLONGは長い入力に対する分類・集計に焦点を当てたベンチマークである。このような能力は「患者の治療のタイムラインの構築」「長い物語における状態の追跡」など多くの実世界のタスクに有用である。 OOLONGは合成データから構成されたOOLONG-synthと、実データから構成されたOOLONG-realの２つに分けられる。 OOLONG-synthは合成データから構成したタスクなので1Mまで長さを自由に変えられるのが長所である。こちらは推論タスク、集計タスクの２つが含まれる。推論タスクは「AはBにいる」「BはCの隣にいない」などの断片的な情報を長いコンテキストの中に断片的に配置して、最終的な位置を推測させる。集計タスクは数万ワードの中に特定の単語が何回出現したかを数えさせ、モデルの集中力をテストする。 OOLONG-realはダンジョン＆ドラゴンズのリプレイデータを利用している。リプレイデータには熱心なファンによるゴールドラベルが付けられているので、正解データとして利用することができる。各エピソードでのサイコロの出目と呪文に関する統計を利用する。ファンが複数の分析を行っているので正確なデータを利用できる、というのが面白い点だ。 以上のベンチマークをGPT-5, o3, GPT-5-mini, Claude-Sonnet-4, Gemini-2.5-Pro, DeepSeek-R1, Llama-4-Maverickなどで実行した。OOLONG-synthでコンテキストを伸ばしていくと125Kで全てのモデルが50以下のスコアとなった。512Kまでコンテキストを拡張すると、予想通り性能が大幅に低下することがわかる。OOLONG-realのほうでも同様にコンテキストの長さに比例して大幅に性能が低下する。 論文の検証結果から、モデルのカタログスペックで入力コンテキストが1Mを超えていても、実際には125Kで大幅に性能が劣化することがわかった。長いコンテキストの情報を正しく使うにはまだ壁があるようだ。 また従来のベンチマークは検索性能に主眼が置かれていたが、今後はOOLONGのような事象の統計や状態追跡の能力の評価が重要になってくると思われる。 論文を読む前にGeminiに読むときに着目するポイントを聞くと「タイトルのOOLONGの由来」を挙げてきた。読んでもわからなかったので聞いてみると、OOLONGには「烏龍茶のように発酵させてじっくり抽出する」ニュアンスが含まれているのではないか？と言ってきた。そう解釈できないこともないが、根拠が弱いなぁ。 arxiv.org/abs/2511.02817

こちらは既存のロングコンテキスト（長文）ベンチマークは正しい測定ができているのか？　という点に疑問を持って調査した研究。 最近は1M, 2Mの入力を受け付けるLLMが登場しているが、本当に入力された内容を理解できるのだろうか？　既存のロングコンテキストのベンチマークとしては「干し草の中の針」ベンチマークが有名だ。これは長文の中から探したい短いフレーズを探すものである。著者らは、このような長文ベンチマークは検索ベンチマークにすぎないと結論づけている。 著者らは情報の性質に基づいて２軸で評価する手法を提案している。Diffusion（情報の分散度合い）とScope（回答に必要な情報の量）である。この２軸で既存の長文ベンチマークを分類・再定義したところ、最も困難な高Diffusion / 高Scopeのタスクが存在しないことを指摘している。具体的には長文の小説を読んで、特定のテーマがどのように変遷したのか要約するようなタスクである。 既存の長文ベンチマークは検索がうまいかを判定するテストでしかない。異なる箇所を組み合わせて、新しい結論を出す「真の長文理解」へ移行する必要がある、と著者らは結論づけている。この論文は問題点の指摘までで、新しいベンチマークを提案するところまでは到達していない。 「干し草の中の針」ベンチマークは最新のモデルでは飽和しているが、実際の内容理解では有効な入力コンテキストサイズがスペックより遥かに短い、という事実と一致する内容だと思う。 arxiv.org/abs/2407.00402

これは高解像度のPBRテクスチャ付きの3Dモデルの新しいデータセットを構築した話。 サンプルのサイズが100kを超える3DのオープンソースのデータセットはObjeverseとObjeverse-XLの二つしか存在しない。そしてテクスチャ解像度は1024以下のものしか入手できない。 著者らは160万個の3DモデルをホストしているSketchfabから1024以上のテクスチャ解像度のモデルをフィルタリングしてTexVerseデータセットを構築した。 フィルタリングでは、NoAIのラベルなし、CCライセンスのものだけを選び出した。858,669の3Dモデルを含み、そのうち158,518はPBRテクスチャを持ちglb形式で標準化されている。 データセットにはリグを持つもの、アニメーション付きのものも含まれている。 データセットはサムネイル画像をGPT-5に入力して、標準化された三文構成のアノテーションを行った。全体的な説明、オブジェクトの構成要素と空間関係、各構成要素の詳細な属性を記述する。これにより標準化された説明が保証される。 新規に作らずに、Sketchfabからフィルタリングしただけではあるが、それだけでもかなりの手間なので価値のあるデータセットである。 arxiv.org/abs/2508.10868