AIエージェントの性能はモデルだけで決まらない——ハーネスの設計次第で大きく変わります。 TL;DR JIT-Agentはタスクの特性に応じてエージェントハーネス（スキャフォールド）をジャストインタイムで自動生成・修復・進化させる専用モデルです。GLM-5.2で+7.7pt、DeepSeek-V4-Flashで+8.8ptの平均向上を達成し、9ベンチマーク中8つでGPT-5.6を含む全フロンティアモデルを上回りました。 タイトル: Scaling Harness Intelligence via Just-in-Time Harness Evolution URL: ポイント 🧩 ハーネスを「学習可能なアーティファクト」として定式化 メモリ・計画・アクション・能力オーケストレーションの4モジュールプロトコル h = (M, P, A, F) でハーネスを形式化。生成空間を制約しつつ13種類の既存ハーネスを全て表現できる設計です。 🎓 教師あり→修復→進化の3段階訓練 ステージIで教師生成ハーネスを学習、ステージIIで実行失敗時の修復を学習（最大2反復）、ステージIIIのEvo-GDPOでパレートフロンティアを前進させる新規ハーネスを進化的に探索します。 📊 精度向上とコスト削減を同時達成 xBench-DeepSearchでスコア78→82（+4pt）の一方、トークン消費は527K→212K（▲60%）、コストは$0.075→$0.039（▲48%）。9ベンチマーク平均で固定ハーネス比36%のトークン削減を実現しています。 ⚡ 複数モデルファミリーに転移可能 JIT生成ハーネスはDeepSeek V4（+10.2pt平均）、Mimo V2.5（+8.6pt）、Qwen 3.6（+4.0pt）でいずれもReActを上回り、ハーネス生成器を再訓練せずに転移できます。 🔄 ストリーミングモードで運用中も進化 デプロイ後もタスクシーケンスをまたいでハーネスを蓄積・更新する「オンライン進化」を実装。静的生成より全評価ベンチマークで上回ります。 ベースモデルのスケーリングと独立した「ハーネス知性」という新たなスケーリング軸の提案として注目です。 #AIエージェント# #LLMスケーリング#

🧵 AIにじっくり考えさせようとすると、考えれば考えるほど1トークンあたりのコストが膨らんでいく。この地味だけど本質的な壁に、ある発見から挑んだ研究があります。 きっかけはシンプルな観察でした。「42+84=126」のような計算ステップは、答えが出た瞬間にその過程はもう要らなくなる。長い推論のなかで本当に重要なのは、最初のタスク指示（プリフィックス）と、いま進行中の直近の思考だけではないか——著者らはそう考えました。 そこで提案されたのがPrefix Sliding。プリフィックスと直近k個のトークンだけをスライディングウィンドウとしてメモリに保持し、それ以外は捨ててしまうというシンプルな発想です。これにより1トークンあたりの生成コストが、どれだけ長く考えても一定に保たれるようになります。 結果は明快でした。追加学習なしで既存モデルを約3倍高速化し、さらに強化学習と組み合わせることで、これまで事実上不可能だった10万トークンを超える推論トレースへのスケーリングを実現しています。「長く考えるほどコストが増える」という当たり前を覆した点が、この研究の核心です。 タイトル: Prefix Sliding for efficient test-time scaling URL: #LLM# #テスト時間スケーリング#

LLMの「残差接続」、実は各層を一律の重みで足しているだけでした➕ 深くなるほど各層の貢献が薄まるこの問題に、アテンションで答える改良です。 タイトル: Attention Residuals URL: ➕ 概要 残差接続の固定重みでの足し合わせを、softmaxアテンションに置き換える手法AttnResの提案です。各層が、学習された入力依存の重みで、それより前の表現を選択的に集約できるようにします。 ❓ 解決する課題 現代のLLMはPreNorm付きの残差接続が標準ですが、各層の出力を固定の等しい重みで足し合わせます。 ・層が深くなるほど隠れ状態が制御不能に増大します ・一律に足すため、個々の層の寄与が深さとともに希薄化します つまり「どの層の表現をどれだけ使うか」を制御できていませんでした。 💡 方法論と提案手法 ・Full AttnRes：すべての先行層の出力にアテンションを適用します ・Block AttnRes：層をブロックに分割し、ブロック単位の表現にのみアテンションして計算を削減します ・キャッシュベースのパイプライン通信と2フェーズの計算戦略を採用 ・Kimi Linearアーキテクチャ（総48B/活性3B）で検証しました 📊 実験結果 ・1.4兆トークンで事前学習 ・深さ方向でより均一な出力の大きさと勾配分布を達成 ・評価したすべての下流タスクで性能が向上 ・スケーリング実験でもモデルサイズをまたいで一貫した改善を確認 #LLM# #アーキテクチャ#

🐡 もう「どのLLMが最強か」を一つに絞って悩む時代は、終わるのかもしれません。 タイトル: Sakana Fugu Technical Report URL: Sakana AI の Fugu は、複数のフロンティア LLM を部下として束ね、タスクに応じて最適な布陣を自動で組む「指揮官（オーケストレータ）モデル」です。注目ポイントを3つに絞って紹介します。 🧭 学習された司令塔 Fugu は事前学習済みバックボーンに軽量な選択ヘッドを載せ、隠れ状態から最適なワーカーモデルをロジットで直接選びます。自己回帰生成を挟まないため、単一のフロンティアモデルを呼ぶのと同等の低遅延を保てるのが巧みです。 🕸️ ワークフローを動的に自作（Fugu-Ultra） 上位版はタスクを自然言語のワークフローとして書き下し、サブタスク分割・担当割り当て・通信戦略まで設計します。最大5ステップで討論型・逐次連鎖・木構造といった多エージェント協調を、問題ごとに組み立てます。 📊 単体モデルを超える成績 SWE-Bench Pro で 73.7 点（Claude Opus 4.8 の 69.2 を上回る）、GPQA-Diamond 95.5、LiveCodeBench 93.2 など主要ベンチで公開モデル最高水準。エージェント型コーディングでは「世代交代級」の 5〜6% の相対改善を達成しました。 巨大化ではなく賢い"指揮"で最先端へ。新しいスケーリング軸を示した一本です。 #SakanaAI# #LLM#

⚙️ 月125兆トークンを捌くLLM推論基盤は、どう信頼性とコストを両立しているのか。リクエスト数ではなく「モデルユニット」でコストを測り、GPUコストを80%削減しつつ安定運用を実現したDatabricksの実戦知です。 タイトル: Reliable LLM Inference at Scale URL: 📝 概要 本記事は、大規模なLLM推論を信頼性高く・コスト効率よく運用するための、Databricksのアーキテクチャと手法を解説します。GPUインフラの不安定さや、予測困難なリクエストコストといった本番特有の課題に、具体的な仕組みで対処しています。 ❓ 解決する課題 ・GPUインフラはCPUより本質的に不安定で、prefill/decodeを分離した構成では単一障害が複数ノードに波及します ・リクエストコストは事前推定が難しく、出力トークン生成がレイテンシを支配する一方、その時間は予測困難です ・高負荷時には、リクエストの組み合わせ次第で健全なサーバが突然不健全状態に陥ります 💡 方法論と提案手法 ・コストを「α×入力トークン＋β×出力トークン＋γ×マルチモーダル」とモデル化する「モデルユニット」抽象を導入し、係数はモデル/ハードウェアごとの自動ベンチマークで決定します ・自動シャーダーDicerが、キュー長でなくモデルユニットで測ったサーバ負荷でルーティングし、ステートフルセッションでキャッシュヒット率を高めます ・保留リクエスト数でなく「モデルユニット利用率」でオートスケールし、ピーク閾値に近づくと増設します ・ブラックボックスのヘルスチェックでサイレントハングを検知し、ヘルスチェックを最高優先度にして誤検知を防ぎます 🎯 ユースケース Superhumanやコーディングエージェント、サポートボットなど、トラフィックが数時間で急増するマルチテナントのエージェント型アプリを支えます。LLMアプリが単一テナントから共有本番環境へ移る局面に直結します。 📊 実験結果 ・コスト認識オートスケーリングで、静的なピーク見込みプロビジョニング比のGPUコストを80%超削減しました ・ヘルスチェックの誤検知を週数件からゼロへ、サイレント障害の検知・回復は5分未満に収めました ・画像処理をTorchvisionへ切り替え、OMP_NUM_THREADSをコンテナ上限に正しく設定し、同じレプリカ・負荷でスループットを3倍超に跳ね上げました ・月125兆トークンをマルチテナントで処理しています #LLM# #MLOps#

# AIエージェント開発の意思決定ポイント # オーケストレーション vs コレオグラフィ 🎼 🎯 ポイント 複数のエージェントやサービスを協調させるとき、「指揮者を置くか、各自が自律的に踊るか」を選ぶ必要があります。 オーケストレーションは中央の指揮者がすべてを統制する方式。コレオグラフィは各コンポーネントがイベントに反応して自律的に動く方式。制御の所在が根本的に異なるため、障害処理・監査・デバッグ・スケーリングの設計が全く変わります。 📋 概要 オーケストレーションでは中央のオーケストレータが全体のワークフローを定義し、各コンポーネントを順次または並列に呼び出し、結果を集約して次のステップを決定します。Temporal、Airflow、LangGraphのSupervisorパターンなどが典型的な実装基盤です。コレオグラフィでは各コンポーネントがイベントバス（Kafka、EventBridge等）上のイベントを購読し、関心のあるイベントに自律的に反応して新たなイベントを発行します。全体の制御フローを知る中央は存在しません。 🔍 意思決定のポイント 判定の主軸は **説明責任（accountability）** です。 🏛️ **オーケストレーションに倒す条件**: - 処理の全体像と各ステップの判断根拠を事後に説明する必要がある - 審査→承認→実行のような厳密な順序制約がある - LLMの出力を次のステップに渡す前に検証・変換が必要 - 全体の予算（トークン・時間・コスト）を中央で管理したい - コンポーネント数が概ね10以下 🌊 **コレオグラフィに倒す条件**: - 高スループット・高スケールが求められ、中央がボトルネックになる - 多数のチームが独立してコンポーネントを開発・デプロイしている - イベントへの「反応」が主な処理パターン（通知、ログ、非同期集計） - 実行順序の厳密な追跡が不要 💡 要点と詳細 🟢 **オーケストレーションの強み**は制御の明確さと監査性です。ワークフローの全体像が1箇所に定義されているため「今どこまで進んでいるか」「なぜこのステップが実行されたか」が常に明らかです。障害時のリカバリもどのステップで失敗したかを特定して再開できます。エージェント固有の利点として、LLMの出力を検証してから次ステップに進められるため、ハルシネーションの伝播を各ステップで遮断できます。 🟡 **コレオグラフィの強み**は疎結合とスケーラビリティです。各コンポーネントはイベントスキーマだけを共有し、他の存在を知りません。新コンポーネントの追加はイベント購読の追加だけで、既存コンポーネントに変更不要です。独立スケールも可能で、イベントバスがバッファとして一時的な負荷偏りを吸収します。 ⚖️ トレードオフ | 観点 | オーケストレーション | コレオグラフィ | |---|---|---| | 全体状態の可視性 | 常に明確 🟢 | イベントログの突合が必要 🔴 | | 監査性 | 高い（因果関係を示せる） | 低い（分散した追跡が必要） | | スケーラビリティ | 中央がボトルネック | 各コンポーネントが独立スケール | | 結合度 | 高い（中央への変更が集中） | 低い（スキーマ共有のみ） | | ハルシネーション制御 | ステップごとに検証可 | 各自でガードレールが必要 | | チーム独立性 | オーケストレータ変更で衝突 | 独立開発・デプロイ可 | 🛠️ ユースケース 🔵 **オーケストレーションが向くケース**: 業務系システム、規制対象の処理、審査・承認ワークフロー、LLMの出力検証が必要な処理。説明責任が求められる環境。 🔴 **コレオグラフィが向くケース**: 高スループットのイベント駆動処理、通知・ログ集約・分析パイプライン。多数のチームが独立してコンポーネントを開発する大規模システム。 📌 **デフォルト戦略**: 業務系システムではオーケストレーション（中央集権）がデフォルトです。AIエージェントを含むシステムでは、LLMの確率的な出力を制御・検証する中央の存在が安全性と監査性の両面で重要です。実用的な折衷は「中核は中央集権、周辺探索はイベント駆動」で、主要な業務フローはオーケストレータが管理し、周辺の非同期処理はイベント駆動で疎結合に構成する形です。 #AIエージェント# #ソフトウェアアーキテクチャ#

🌐 強いAIエージェントを作る鍵は、実は「エージェントが動く環境の設計」かもしれません。環境エンジニアリングという視点を体系化した、全63ページのサーベイです。 タイトル: Agentic Environment Engineering for Large Language Models: A Survey of Environment Modeling, Synthesis, Evaluation, and Application URL: 📝 概要 LLMエージェントは単独でなく、相互作用する「環境」の中で動きます。本サーベイは、その環境そのものを工学的に設計・構築する「環境エンジニアリング」という観点から、研究の全体像を体系化しています。 ❓ 解決する課題 これまで「環境の作り方」は断片的に語られてきました。エージェント能力の向上が良い環境設計に大きく依存するにもかかわらず、それを統一的に整理する枠組みがなかったのです。 💡 方法論と提案手法 環境を開発ライフサイクルに沿って4つの柱で分類します。 ・環境モデリング：代表的な環境の特徴づけとコア能力の評価 ・環境合成：シンボリック合成とニューラル合成の2パラダイム ・環境評価：合成パラダイムに整合したドメイン固有の評価 ・環境応用：記憶中心・ワークフロー中心・軌跡中心・探索中心という、エージェントと環境の共進化4経路 🎯 ユースケース エージェント研究者が自分の取り組みを地図上に位置づけ、抜けている観点を見つける指針になります。環境合成・評価・自己進化の設計を考える際の出発点としても有用です。 📊 トレンドと展望 ・進化のアプローチを、ニューラル駆動・難易度駆動・スケーリング駆動の3系統で整理しています ・8つの属性と8つの応用ドメインを軸に分析しています ・今後の方向性として、Environment-as-a-Service、マルチエージェント、ニューラル・シンボリック統合を挙げています #AIエージェント# #LLM#

🔁 「じっくり考えるほど賢くなる」AIを、勾配爆発を起こさずに学習させる方法が見つかりました。 タイトル: Thinking with Looped Flows URL: 再帰的に隠れ状態を更新して「考える」ループモデルは、これまでBPTT（時間方向の逆伝播）の不安定さに悩まされてきました。Looped Flowsは拡散モデルの学習原理を借りることでこれを解決した手法です。注目ポイントを3つ紹介します。 🧠 BPTTなしで再帰計算を学習 ノイズレベルを徐々に減らしながら各ステップをローカルな損失で学習することで、勾配消失・爆発を起こさずに「考え続ける」状態を安定して学習できます。 ⏱ 推論時に計算量を後から増やせる 学習時より細かい時間刻みで推論するだけで性能が伸び、Sudokuでは8ステップの74.5%から128ステップで97.9%まで向上します。 🏆 ARC-AGIで既存手法を上回る ARC-AGI-1で58.8%、ARC-AGI-2で12.2%を達成し、いずれも従来のループモデル手法を上回りました。 推論時にじっくり計算するほど賢くなる、というテスト時スケーリングの新しい実現方法として興味深い研究です。 #LLM推論# #機械学習#

🖥️ エージェントの学習用「実行環境」は軌跡の何百分の一しかない、という不均衡をひっくり返す発想の論文です。 タイトル: Terminal-Universe: Turning Agent Trajectories into Scalable Terminal Environments URL: 蓄積済みのコードエージェント軌跡からファイル操作履歴を読み解き、実行可能な検証環境を自動で逆算復元し、そこから新たな学習タスクを大量に合成するフレームワークです。 注目ポイント 🔄 軌跡から環境を逆算復元 軌跡内のread/write/edit操作をリプレイして部分的なワークスペースを再現し、補完エージェントが欠けているファイルや依存関係を補います。さらに読み取り専用ツールで充分性を判定し、質の低い環境を除外します。 🌐 幅と深さの二軸でタスクを拡張 複数リポジトリの依存関係を使うCross-WS合成で「幅」を、ユーザーからの追加要望に応じるMulti-Round対話で「深さ」を広げます。Multi-Roundは平均4.51ラウンド、失敗から修正するパターンが69.6%を占めます。 📈 二桁ポイントの性能向上を実証 Qwen3.5-27Bをこのデータで学習させ、Terminal-Bench 2.1で+11.9pt、EvoCode-Bench v2で+13.8ptと大幅に改善。同規模の既存手法もすべて上回りました。 蓄積された軌跡という「余っているリソース」を検証可能な学習環境に転換する、地に足のついたスケーリング手法だと感じます。 #エージェント学習# #LLM#

LLMエージェントの「考える」と「話す」は、実は同じ言語でやらなくてもいいかもしれません。 タイトル: Hybrid Reasoning Agents URL: ❓ 潜在空間で考えるエージェントって何が違うの? 💡 普通のLLMエージェントは、考える時も行動する時もすべてトークン(言葉)に変換しながら処理します。監視はしやすい一方で遅く、効率が悪いという課題がありました。一方「潜在推論」は言葉に変換せず隠れ状態のまま考えるので速いのですが、ツールを呼んだり人間が内容を追跡したりしにくいという別の欠点がありました。 ❓ Hybrid Reasoning Agentsはどう解決したの? 💡 HybridLinkという軽量な橋渡しモジュールを使い、1つのエージェントの中で「言葉で考えて話すモード」と「隠れ状態のまま考えるモード」を動的に切り替えます。切り替えのタイミングは、隠れ状態の意味が終了を示すトークンの埋め込みに十分近づいた時に自動で判定されます。 ❓ 本当にその両立はできているの? 💡 11種のベンチマークで検証した結果、GAIAで52.4%(既存手法ARPOの43.7%を上回る)など、エージェント推論タスクで平均10.4%の性能向上を達成しました。しかもテキストトークンの使用量を35.5〜54.7%削減しつつ、推論速度は1.8〜2.6倍、計算コストは2.7〜3.7倍も削減しています。 ❓ 潜在思考の中身は本当に「考えている」の? 💡 隠れ状態を最も近いトークン埋め込みに復号すると、人間にも読める疑似テキストが得られます。潜在部分をランダムなトークンに置き換えると性能が49〜51%も落ちることから、見せかけではなく実質的に推論へ使われていることが確認されました。 #AIエージェント# #推論効率化#