LLMは数学の問題で人間より高い正解率を出せるようになりました。でもそれは「きちんと積み上げて理解している」からでしょうか？ タイトル: Do LLMs Exhibit Coherent Knowledge Structures in Mathematical Reasoning? A Perspective from Knowledge Space Theory URL: ❓ LLMは前提知識をきちんと積み上げて正解しているの？ 💡 正解率自体は人間79.6%に対しLLM最高92.5%（Qwen3-80B）と上回りますが、前提を完全に満たした上での正解の割合は人間72.7%に対しLLMは48.16%にとどまります。正解していても土台が抜けているケースが多いということです。 ❓ 前提知識をヒントとして教えてあげれば改善する？ 💡 実は前提に基づくヒントを与えても、無関係な例を与えた場合とほとんど差が出ませんでした。構造的な前提推論ではなく、表層的なパターンマッチングに頼っている可能性が高いです。 ❓ 賢いモデル同士なら、似たような知識の持ち方をしているはず？ 💡 人間の学習者グループ間では知識の重なりが0.9以上と高いのに対し、LLM同士では0.38〜0.6程度しか重なりません。強いモデルほど人間から離れていく傾向も見られました。 ❓ つまりこの研究が示しているのは？ 💡 精度という指標だけでは、LLMの「理解の仕方」のズレは見抜けないということです。知識空間理論という新しい評価レンズを使うことで、正解率の裏にある断片的な知識構造が浮かび上がります。 #LLM評価# #数学的推論#

🧭 TL;DR: LLMの「自信」を今この瞬間の推論だけで決めるのをやめ、過去の似た経験からどれくらい当たってきたかで較正する手法が登場しました。10サンプルの自己整合性より安く、しかも精度は同等以上です。 タイトル: Confidence Comes from Experience: Experiential Confidence Estimation from Reasoning to Agents URL: ポイント 🗂 過去のタスク・推論・当初の確信度・実際の正誤・教訓を経験バンクに蓄積 🔍 類似エピソードをk=50件検索し実際の的中率を統計的に把握(Recall) 💭 その実績を踏まえてモデル自身に確信度を言葉で再表明させる(Reflect) 🏆 24モデル×データセットの組み合わせ中23でSC@10と同等以上のAUROC 🤖 失敗が静かに起きがちなエージェントタスクで最大の差、AppWorldでは専用検証器すら上回る 📉 キャリブレーション誤差はドメイン全体で2〜20倍改善、計算コストは約10分の1 「今の推論だけ見る」から「積み重ねた実績を見る」への発想転換が効いている好例だと思います。 #LLM評価# #AIエージェント#

「配信率100%、スキーマ有効性100%、エラー0件」の完璧なパイプラインなのに、同じリクエストを投げ直したら判定結果が変わる。そんな衝撃の負の結果を、事前登録＋完全な監査証跡つきで報告した論文です。 タイトル: Clean Engineering, Unstable Measurement: A Preregistered Reliability Failure of Black-Box LLM Observers on Shared Endpoints URL: 🔧 注目ポイント1: エンジニアリングの完璧さは測定の信頼性を保証しない 3,312件の計画済みコールで応答率・スキーマ有効性ともに100%、再試行やエラーも0件という理想的な実行にもかかわらず、繰り返しランキングの一致度（Spearman中央値）はわずか0.400。事前登録した安定性ゲート（閾値0.90）を明確に下回りました。 🎲 注目ポイント2: バイト同一の入力でも出力がドリフトする 同じリクエストを24時間後に再実行しても、全順位の一致率はわずか0.780。しかも面白いことに、同一日内の別ウィンドウ同士でも中央値0.805とほぼ同じ数値になり、これは「翌日ドリフト」ではなく共有エンドポイントの即時的な非決定性であることが判明しました。 📉 注目ポイント3: サンプル数を増やしても解決しない オブザーバー呼び出しを8回から500回（合計74.8万コール）まで増やしても、安定性ゲートの通過率は0/500のまま。候補間のスコア差がノイズフロアより7〜10桁も小さいため、そもそも順位付け不可能なタスクが多いことが根本原因でした。 LLMを評価の「ものさし」として使う前に、そのものさし自体が安定しているかを計測する重要性を教えてくれる一本だと思います。 #LLM評価# #再現性#

💻 最強クラスのコーディングAIでも、非プログラマー相手だとスコアが半分以下に落ちる…そんな現実を突いたベンチマークが登場しました。 タイトル: SWE-Journey: Towards More Realistic Evaluation of Coding Assistants through Long-Horizon, Multi-Turn Interaction URL: ❓ 何が課題だったの？ 既存のコーディング評価ベンチマークは、タスクが短く、かつ要件を最初から全部提示してしまうものが多く、実際のユーザーが段階的に要望を出していく現実の使われ方を反映できていませんでした。 ❓ SWE-Journeyは何が違うの？ 平均10.2ファイル・768行規模の長期タスクを自動合成し、Claudeの実対話ログから抽出した「非プログラマー」「プロダクトマネージャー」「新人開発者」「ソフトウェアアーキテクト」という4つのペルソナがAIと何十ターンもやり取りしながら評価します。 ❓ 結果はどうだったの？ 最高性能のモデルでもFinal F2P（最終的な機能実装成功率）は52.22%にとどまりました。しかもソフトウェアアーキテクト相手では78.50%出せるのに、非プログラマー相手だと23.00%まで落ち込み、差は55.50ポイントにも及びます。 ❓ なぜそんな差が出るの? 弱いモデルは曖昧な要求を聞き返さず、見当違いの箇所に過信して固執し、根拠なく「修正完了」と報告してしまう傾向が確認されています。相手に応じて質問の仕方や確認の仕方を変える力が、実力の差になっていました。 #AIコーディング# #LLM評価#

エージェントのベンチマーク、どうやって作ればいいのか？LangChainが実践ノウハウを公開しました。 タイトル: How We Build Agent Environments & Tasks URL: ❓ エージェントの「タスク」って何で構成されているの？ 💡 タスクは「インプット・環境・テストスクリプト」の3要素で成り立ちます。環境はエージェントの実行場所を提供し、ルーブリックが採点基準を定義します。複数の関連タスクにまたがる共有知識は「ワールドスペック」としてまとめ、APIスキーマ・データ生成方法・トレース解析スクリプトなどを一元管理します。 ❓ 大量のタスクを効率よく作るにはどうすればいい？ 💡 LangChainは2段階パイプラインを採用しています。最初に「スペック生成」フェーズでコーディングエージェントがリポジトリをスキャン・トレースを分析しワールドスペックを自動生成します。次に「Spec2Task」フェーズでそのスペックから実行可能なタスクに変換します。最初のタスク作成時のスペックをベースに、後続のサイクルで反復的に品質を高めていく設計です。 ❓ タスク作成で特に注意すべき落とし穴は？ 💡 3点が重要です。 ・実際のエージェントを動かさないと環境の欠陥が見えない（ペーパーテストでは不十分） ・モデルティア間（例: gpt-5.6-Luna vs Sol）で難易度を均等に校正する必要がある ・自由記述にはLLMベースの生成、表形式データにはSQLスクリプトという使い分けを徹底する ❓ ベンチマークは作ったら完成ですか？ 💡 いいえ。本番データを使った継続的改善が核心です。コスト分析・プロンプト簡略化の検証・ツール設定テストに本番トレースを活用し、ベンチマーク自体の品質を運用しながら高め続けます。 評価環境の構築を「一度やれば終わり」でなく継続的なエンジニアリングとして捉える姿勢が実践的です。 #AIエージェント# #LLM評価#

# AIエージェントをソフトウェアに組み込むプラクティス # Critic/Judge & Sampling-Aggregation｜独立検証と多数決 🎯 LLMの出力を、同じLLMに「正しい？」と聞いていませんか？ 生成と検証を別系統にするだけで、自己確認バイアスを断ち切り、出力の信頼性を構造的に高められます。 🔥 解決する課題 LLMは確率的に出力が揺れ、事実と異なる内容をもっともらしく生成します。生成と検証を同一のモデル・プロンプトに任せると、生成時のバイアスが検証にも引き継がれます。法律文書のドラフトを生成したLLMに「この文書は正しいか」と尋ねても、自分の生成物に肯定的に評価しがちです。これが「自己確認バイアス」です。 💡 提案パターン 2つの手法を組み合わせます。まず、生成系とは別のモデル・別のプロンプト・決定論的コードで出力を検証する「Critic/Judge」。次に、同じ入力からN個の候補を生成し、スコアリングや多数決で最良を選ぶ「Sampling-Aggregation」。両者を組み合わせると「N個生成 → Judgeが各候補を評価 → 最高スコアを採用」となります。コストはN倍になるため、リクエスト価値と失敗コストが高い経路に限定して適用します。 ✅ 選定条件 使うとき： - 誤った出力がそのまま下流に流れると実害がある（契約書・医療要約・金融レポートなど） - 1回の生成に追加コストをかける経済合理性がある - 出力品質を客観的に評価できる基準がある 使わないとき： - 多少の誤りが許容されるカジュアルな対話 → ガードレールで十分 - レイテンシが極めて厳しい（数百ミリ秒以内） - 評価基準が主観的で定量化困難（創作文章の「面白さ」など） ⚠️ 落とし穴 - JudgeがGeneratorと同じバイアスを持つ場合があります。同じモデル・同じ知識で評価すると同じ種類の誤りを見逃します。異なるモデルファミリを使うか、決定論的チェックをJudgeの一部に組み込んでください - Nを増やしてもコストは線形に増えますが、品質向上は逓減します。N=1とN=3の差は大きいですが、N=3とN=5の差は小さいことが多いです。まずN=3から始めてください - Judgeのプロンプトに評価基準を明示してください。「正しいか」だけでは曖昧な判断になります。事実性・論理的整合性・スキーマ適合など具体的な軸を与えてください 🔧 実装方針 - Generator（候補生成）とJudge（評価）を別々のモデルまたは別プロンプトで構成し、同一系統による自己確認バイアスを構造的に排除します - N個の候補生成は並列実行し、レイテンシの増加を最小限に抑えます - Judgeの出力はスコアと理由を含む構造化データとして定義し、集約ロジック（最高スコア選択・多数決）を決定論的コードで実装します - 全候補がJudgeの品質閾値を下回った場合のフォールバック（再生成上限・人間エスカレーション）を事前に設計しておきます - 決定論的チェック（スキーマ検証・値域チェック・データベース照合）をJudgeの一部として組み込み、LLM判定だけに頼らない検証層を構築します #AIエージェント# #ソフトウェアアーキテクチャ#

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エージェント# #推論効率化#

LLMエージェントに「安全な理由」をちゃんと説明させられたら、それは本当に理解している証拠でしょうか。 オークションやマッチング市場のように、正直に答えることが最善手だと分かっている状況でも、LLMエージェントは最適な意思決定からずれてしまう。ハーバード大学とMITの研究チームは、インターフェースの形やテキストの補助を変えることで、この振る舞いが改善するかを検証した。結果は明確だった。第二価格オークションを上昇クロック形式に変えるだけで、最も性能の悪かったGemmaの平均偏差は-5.3からほぼ完璧な-0.3へと改善。マッチングでも「あなたの提示は拒否されるかどうかを決めるだけ」という安全性の説明だけで、誤り率は4.2%から0.2%まで落ちた。 🔍 ところが本当に驚くべき発見はここからだ。入札が大きく改善したペイオフ安全性の介入では、600件の計画の中で、述べられた安全性の理由に言及したものが一件もなかった。逆に、相手の行動を推測させる信念プロンプトは、それらしい言葉遣いを2%から43%まで増やしたのに、入札そのものは全く変わらなかった。 タイトル: Engineering Simplicity: Simple Mechanism Interfaces Steer LLM Agents URL: つまり、言葉で説明できることと実際に正しく動くことは、ほとんど別物だということだ。エージェントの「理解度」を評価するときは、説明文だけを見て安心せず、実際の決定そのものを確かめる必要がある、という実務上の教訓が重い。 #LLMエージェント# #意思決定#

LLMエージェントに「脆弱性を探して」と頼むだけでは誤検知が多くなりがちです。Cloudflareはそこに対立的検証という発想を持ち込みました。 タイトル: cloudflare/security-audit-skill URL: 🔍 概要 コーディングエージェントを自動セキュリティ監査ツールとして機能させ、独立した検証と機械可読な脆弱性報告を実現するスキルです。npxコマンド1つでClaude Codeなどに導入できます。 🧭 解決する課題 単純にAIへ脆弱性探索を任せると根拠の薄い誤検知や見落としが発生しがちです。それに対し、探索と検証を別エージェントに分離することで信頼性を高めています。 ⚙️ 方法論・提案手法 偵察→カバレッジ主導の探索→候補検証→構造化出力→独立記録検証→中立的な報告、という6フェーズのパイプラインを構成。新規の独立エージェントが候補と最終クレームをそれぞれ再検証する「対立的検証」が特徴です。 🛠️ ユースケース ・security audit this codebaseのような自然言語指示で起動 ・LLM・プロンプトインジェクションからクラウド・サプライチェーンまで12種類の攻撃クラスに対応 ・validate-findings.cjs等の検証ツールも同梱 📊 実験結果 テストでは単一実行で約50%の脆弱性を検出し、複数回の実行を重ねることでカバレッジが積み上がる設計です。GitHubでは16.3kスター・894フォークを獲得しています。 #セキュリティ# #AIエージェント#