デイリーAIダイジェスト — 2026-07-11
Hacker News シグナル
GPT-5.6 Sol UltraがCycle Double Cover予想の証明を生成 [pdf]
Cycle Double Cover予想（CDC）——Szekeres（1973）およびSeymour（1979）以来未解決——は、すべての橋なしグラフに対して、各辺がちょうど2回カバーされるようなサイクルの集合が存在することを主張しています。OpenAIが公開したPDFは完全な証明を主張しており、もし検証されれば、位相的グラフ理論の中心的問題の一つが解決されることになります。証明の論法は、nowhere-zero flowとそのcubicグラフにおけるcycle coverとの関係についてより強い結果を確立し、標準的な帰着によって一般的な橋なしの場合に持ち上げるという手順で進められると報告されています。証明は形式的な補題を含む長文の数学的散文であり、LeanやCoqによる形式検証ではないため、独立した人間によるレビューが当面のボトルネックとなっています。数学コミュニティの反応は慎重なものとなっており、MathOverflowおよびHNスレッド上の複数のグラフ理論家が、PetersenグラフとそのsnarkにまつわるStructural補題を注意深く精査する必要があると指摘しています。これらはまさに、これまでの証明試みが崩壊してきた箇所です。組合せ論におけるその重要性は言い過ぎることができないほどであり——CDCは曲面への埋め込みやnowhere-zero 4-flowに関する一連の系を意味します。このモデルが自律的な証明器として使われたのか、それとも高度に足場が組まれたアシスタントとして使われたのかは開示されておらず、OpenAIの表現もこの点を曖昧なままにしています。証明検証の計算論的非可約性により、領域の専門家が真剣に取り組んだとしても、決着には数週間から数ヶ月を要するでしょう。正しさとは独立した、より広い含意として、大規模な推論モデルが今や少なくとも構文的には、フロンティア研究レベルの説得力ある専門数学と見分けのつかないアウトプットを生成しているという事実があります。
Source: https://cdn.openai.com/pdf/04d1d1e4-bc75-476a-97cf-49055cd98d31/cdc_proof.pdf
MiMo v2.5の推論最適化：ハイブリッドSWA効率の極限への挑戦
小米（Xiaomi）のMiMo v2.5ブログ記事では、ハイブリッドsliding-window attention（SWA）モデルに対する推論レベルのエンジニアリングについて詳述されています。核心的な課題は、SWAモデルがローカルウィンドウと周期的なfull-attentionレイヤーを交互に配置するため、ほとんどのサービングスタックが前提とする均一なKV-cacheレイアウトが崩れる点にあります。本記事ではいくつかの具体的な最適化手法が紹介されています。
第一に、レイヤータイプを考慮したKV cache割り当てです。ローカルSWAレイヤーはウィンドウ w に比例した固定サイズの循環バッファのみを必要とするのに対し、full-attentionレイヤーは完全な O(n) キャッシュを必要とします。VRAMをこれに応じて静的に分割することで、長いコンテキストにおけるピークメモリを報告値で30〜40%削減できます。
第二に、カーネルレベルのchunked prefillをSWAレイヤーとfull-attentionレイヤーに対してそれぞれ個別にチューニングし、タイルサイズの不一致によるパディングの無駄を回避します。
第三に、speculative decodingがウィンドウ境界を尊重するよう適応されています。素朴なdraft検証器では、受け入れウィンドウ外のトークンを誤ってキャッシュしてしまう問題があります。
128kコンテキストのリクエストにおけるスループットの定量評価では、MiMo v2.5は同一ハードウェア上の素朴なvLLMベースラインと比較して約2.1倍高いtoken/sを達成しています。これは主に、メモリ節約によって大きなバッチサイズが可能になったことに起因します。また、リクエスト単位ではなくレイヤー単位でキャッシュタイプを追跡するcontinuous batchingスケジューラについても議論されており、より密なbin-packingを実現しています。
本記事はresearch-novelというよりもエンジニアリング重視の内容であり、個々の技術の多くは既知のものです。しかし、ハイブリッドアーキテクチャに対してアロケータ、スケジューラ、カーネルレイヤーにわたって統合されている点は非自明であり、提示された数値の信頼性も高いと言えます。SWA系モデル（Mistral、Gemma 2など）を大規模にデプロイする際に、素朴な「full attentionとして扱う」アプローチでは効率面で大きな損失が生じるため、こうした取り組みは実務的に非常に関連性があります。
Source: https://mimo.xiaomi.com/blog/mimo-v2-5-inference
Geosql: 地理空間データのためのClaude/Codexスキル
GeosqlはLLMエージェントに対して構造化されたツールインターフェースを通じて地理空間クエリ機能を公開する、薄いインテグレーション層です。実装はDuckDBとその空間拡張（Parquet、GeoJSON、その他のフラットファイルに対してPostGIS互換の関数を提供する）をラップし、エージェントが呼び出せる query(sql: str) -> GeoJSON ツールを提供します。興味深い設計上の選択は、ツール登録時のスキーマ自動検査です。ラッパーは利用可能なデータセットを検査してカラム名と空間参照系を抽出し、コンパクトなスキーマのサマリーをシステムプロンプトに注入することで、モデルがカラム名を幻覚することなく有効なSQLを記述できるようにしています。リポジトリには、座標の算術演算よりも ST_Within、ST_Intersects、および関連する空間述語を優先するようモデルに指示するプロンプトテンプレートが含まれています。これはDuckDB spatialのクエリプランナーが前者に対してインデックス高速化を適用できるため、重要な考慮事項です。ゼロ依存という主張はエージェントインターフェース層に適用されるものであり、DuckDB自体はバイナリ依存関係として存在します。実用的なユースケースは、PostGISを立ち上げることなく、地理空間データセット（国勢調査の境界線、OSMの抽出データ、ベクターにラスタライズされた衛星由来のラスター）を自然言語でクエリすることです。注目すべき制限として、DuckDB spatialはまだすべてのPostGIS操作をサポートしているわけではなく、複雑なトポロジー操作（例：自己交差入力に対する ST_BuildArea）はサイレントにnullを返すかエラーとなり、現在のラッパーはこれらの失敗モードをエージェントに明確に伝えていません。ただし、GeoParquetファイルに対する探索的分析においては、DuckDBのカラム型エンジンとエージェントインターフェースの組み合わせは真に有用で高速です。
Source: https://github.com/dekart-xyz/geosql
Show HN: FableCut – AIエージェントが操作できるブラウザ動画エディタ（依存関係ゼロ）
FableCutは、npmの依存関係を一切持たないバニラJavaScriptで完全に実装されたブラウザネイティブの動画エディタであり、エージェントからの操作を想定した明示的なAPIを備えて設計されています。技術的なコアは宣言的なタイムラインモデルです。内部状態はクリップ、カット、トランジション、テキストオーバーレイを記述するプレーンなJSON構造であり、完全にシリアライズ・デシリアライズが可能です。エージェントや外部の呼び出し元は、この状態を変更して再レンダリングをトリガーするコマンド関数群（addClip、trimClip、applyTransition など）を通じて操作します。動画のデコードとコンポジットには、ブラウザネイティブの <video> 要素とCanvas 2Dを使用しており、互換性の観点からWebCodecsは使用していません。そのため、コーデックによってはフレーム単位の正確なシークに制限が生じます。依存関係ゼロという主張は確かで、リポジトリには package.json が一切なく、プレーンなHTML、CSS、JSファイルのみで構成されています。エージェントインターフェースは意図的にシンプルに設計されており、JSON入力・JSON出力という形式をとることで、カスタムのシリアライズロジックなしに任意のtool-calling LLMへの接続が容易になっています。主なエンジニアリング上の制限はパフォーマンスです。トランジションを含むマルチトラックタイムラインでCanvas 2Dコンポジットを30fpsで行うと、長尺または複雑なプロジェクトではすぐにCPUのボトルネックに直面し、WebGLコンポジターも存在しません。LLMがトランスクリプトからカットリストを生成するエージェント駆動のアセンブリパイプラインを対象とした短尺コンテンツ（2分未満、2〜3トラック）においては、合理的なプルーフオブコンセプトといえます。既存のエディタにエージェントアクセスを後付けするのではなく、状態を完全にシリアライズ可能にすることをファーストクラスの設計目標とした、このアーキテクチャ上の選択が本プロジェクトで注目すべき判断です。
Source: https://github.com/ronak-create/FableCut
Show HN: Webアプリをagent toolにリバースエンジニアリングする
この投稿では、ソースコードや公式APIへのアクセスなしに、任意のWebアプリケーションを構造化されたagent tool APIに変換するための方法論および関連ツールについて解説しています。このアプローチは3つのステージで構成されています：(1) ブラウザ自動化ハーネス（Playwrightベース）を使用したrecord-and-replayによるトラフィックキャプチャで、主要なユーザーフローのHTTPリクエスト／レスポンスのペアを記録する；(2) キャプチャされたペイロードに対するスキーマ推論 — JSONボディからスキーマを抽出し、フォームのsubmissionを型付きフィールド定義にパースし、ヒューリスティックなヘッダー解析によって認証トークンのパターンを特定する；(3) パラメータ置換を伴うキャプチャ済みリクエストのreplayをラップするtool manifest（OpenAPI互換JSON）の生成。技術的に興味深い問題はセッション状態の取り扱いです：多くのWebアプリのアクションでは、セッションごとに変化する有効なCSRFトークンやセッションクッキーが必要となるため、生成されたtool wrapperには各呼び出し前に軽量な再認証ステップが含まれています。HNのディスカッションでは、利用規約違反に関する当然の懸念と、このアプローチの脆弱性——フロントエンドに変更が加わると記録されたフローが壊れる——が指摘されていますが、技術的なメカニズム自体は、APIサーフェスを持たない内部ツールやレガシーシステムに対しては妥当なものです。完全には対処されていない関連する難問として、JavaScript重視のSPAが挙げられます。この場合、意味のある状態遷移がすべてクライアントサイドのコード内で発生し、対応するネットワークリクエストが存在しないため、現在のアプローチではこれらを捉えられません。実践的なニッチとしては、APIティアが存在しないか高価なAPIアドオンを持つエンタープライズSaaSツールへのアクセスをagentに与えることが挙げられ、オペレーターがそのアカウントを管理しており、利用規約の問題が解決済みである場合に適しています。
Source: (投稿者によるURL未提供)
GLM 5.2はほぼ人間の経理担当者と同等の精度を達成
Toot Booksは、構造化されたVAT会計タスクにおいて複数のLLMをベンチマーク評価しました。このタスクでは、自然言語で記述された一連のビジネス取引が与えられ、正しいVATカテゴリ分類、適用税率、および準拠した申告書サマリーを出力することが求められます。このベンチマークは範囲が限定されていますが、英国MTD VATルールという具体的に定義された基準に基づいており、正解データは公認会計士によって検証されています。GLM 5.2はトランザクションレベルで94.3%の精度を達成しており、人間の経理担当者のベースライン96.1%に迫る結果であり、GPT-4o（91.2%）およびClaude 3.5 Sonnet（89.7%）を本タスクにおいて上回っています。評価手法の詳細も重要です。この評価では、部分免税、混合用途資産、リバースチャージといったエッジケースを含む12のVATカテゴリにわたる200件のトランザクションを使用しており、カテゴリの誤りと税率の誤りをそれぞれ独立してペナルティとするスコアリングを採用しています。GLM 5.2の相対的な強みは、複合ルール——複数のVAT規定を順番に適用する必要があるトランザクション——の処理が優れている点にあるようであり、これはより構造化された規制テキストを含む学習データを反映している可能性があります。このベンチマークには実際の限界もあります。200件という少ないサンプル数、英国VATのみへの限定、複数期間や修正シナリオの欠如、そして人間のベースラインが分布ではなく1人の経理担当者である点などが挙げられます。HNのスレッドでは、94%が教師なし運用に「十分な精度」かどうかについて議論されています。実際的な答えは、エラーが高額取引に集中しているか（問題あり）、それとも均一に分布しているか（レビューがある場合はより許容できる）に依存します。それでもこの結果は、ルールが学習データに十分に表現されている狭く規則に基づくプロフェッショナルタスクにおいて、小規模な特化型モデルがフロンティアモデルに匹敵あるいは凌駕できるという証拠として興味深いものです。
Source: https://toot-books.com/blog/glm-5-2-vat-benchmark
自作GPUがあっという間に大規模化した話 [動画]
このYouTube動画は、ディスクリートロジックとFPGAコンポーネントを用いて機能するGPUを自作するホビイストプロジェクトを記録したものです。アーキテクチャはタイルベースのラスタライザで、三角形セットアップユニット、エッジ関数評価器、SRAMに格納された小さなフレームバッファを持つ固定機能パイプラインです。中級クラスのXilinx FPGAと、制作者がゲートレベルで理解したかった部分向けの7400シリーズTTLロジックを組み合わせて実装されています。「あっという間に大規模化した」という表現は、単純なスキャンラインラスタライザから始まり、透視補正テクスチャ補間の実装へとスコープが拡大したことを指しています。透視補正補間では各フラグメントで 1/z 補間された座標を除算する必要があり、固定ロジックでは非自明な処理です。この補間は 1/z 用のルックアップテーブルベースの逆数ユニットと乗算器チェーンによって処理され、仮数部で約8ビットの精度を持ち、デモシーンで示されたものには十分な品質です。クロック速度は低く（TTL部分では約10 MHz、FPGAファブリック上ではより高速）、フレームバッファは8ビットカラーの320x240ですが、パイプラインは本当に機能しており、テクスチャ付きクワッドをリアルタイムでレンダリングします。教育的価値は、現代のGPUアーキテクチャでは抽象化されてしまっている概念の具体的な実装にあります。この動画では、エッジ関数評価がタイルクワッド全体でどのように並列化されるか、深度バッファの精度が限られている場合になぜZファイティングが発生するか、そして共有エッジのラスタライゼーションルールがハードウェア上でどのように見えるかを正確に示しています。新規の研究内容はありませんが、技術的に厳密であり、APIレベル以下のコンピュータグラフィックスアーキテクチャを教えたり学んだりする人にとって良いリファレンスとなります。
Source: https://www.youtube.com/watch?v=qMR3IXF2sWw
5歳児向けリアルタイムAIチューターの構築
Elloのエンジニアリングブログ記事では、エンドツーエンドの応答時間をサブ1000ms以内に抑えることを目標とした、音声ベースの読み書き指導チューターにおけるレイテンシの制約とアーキテクチャの選択について詳述しています。パイプラインの構成は次のとおりです：発話をセグメント化するデバイス側のVAD（voice activity detection）、子供の音声に対してfine-tuningされた自己ホスト型WhisperバリアントへのストリーミングASR（発音のばらつきにより標準的なWhisperではWERが大幅に高くなります）、読み取り位置とエラー履歴を追跡する小規模なコンテキスト管理層、教育的応答生成のためのLLMコール、そしてTTSです。1000msのバジェットは明示的に分割されています：ASRに約150ms（ストリーミング、first token）、LLMに約400ms（max-tokenの制限と、フロンティアAPIではなくfine-tuningされた小規模モデルにより短い出力に制約）、TTSに約200ms、ネットワークおよびオーディオバッファリングに約150msです。子供の音声ASRはこの中で最も難しいサブ問題であり、標準的なWhisper large-v3は5歳の読者を対象とした内部ベンチマークで約18%のWERを示すのに対し、大人の音声では約4%であると報告されています。彼らのfine-tuningされたモデルはこれを約9%まで改善しています。教育的応答モデルは、レイテンシ目標を達成するために意図的に小規模に保たれており（指導インタラクションでfine-tuningされた7Bクラスのモデルと報告されています）、より大きなモデルでは合計レイテンシが1.5〜2秒に達し、子供が再発話したり集中力を失ったりする原因となります。この記事は残された困難な問題についても率直に述べており、子供が単語を本当に理解したのか暗記したのかを検出することは、ASR出力だけでは得られないより豊富なシグナルを必要とすると指摘しています。
Source: https://www.ello.com/blog/teaching-a-child-in-1000-ms
注目の新しいリポジトリ
nullpointexception-i/agent-sphere
知覚 → 計画 → 実行 → フィードバックのループを実装したLLM駆動のエージェントオーケストレーションプラットフォームです。決定エンジンは、各ステップでケイパビリティレジストリから選択を行うLLMプランナーをラップしており、登録済みのケイパビリティには組み込みツール、MCP（Model Context Protocol）エンドポイント、任意のCLI呼び出し、およびブラウザ自動化が含まれます。アーキテクチャはプランナーと実行器を分離しており、各ケイパビリティがLLMの推論に利用可能な型付きインターフェースを公開できるようになっています。クローズドループ設計により、実行出力が次の計画ステップのコンテキストとしてフィードバックされるため、人間が再プロンプトを行うことなくマルチステップタスクを実現できます。管理されたエージェントAPIに依存するのではなく、異種ツールバックエンドを持つセルフホスト型オーケストレーションレイヤーを求める場合に有用です。MCP統合は特筆すべき点であり、ツール呼び出しに標準のワイヤプロトコルを提供することで、コアプランナーを変更することなく新しいケイパビリティをプラグイン可能にしています。
Source: https://github.com/nullpointexception-i/agent-sphere
modiqo/skillspec
SkillSpec は、LLM エージェントのスキル — エージェント動作の離散的な呼び出し可能単位 — に対する仕様検証フレームワークです。核心となるアイデアは、スキルをフォーマルなコントラクトとして扱うことです。各スキルは構造化されたインターフェース定義、事前条件、事後条件、および実装が宣言されたコントラクトと一致することを示すアライメント証明を持ちます。「Doctor」コンポーネントはスキルグラフ上で静的リスク解析を行い、デプロイ前に安全でない組み合わせ、エラーハンドリングの欠如、またはコントラクトの不整合を検出します。ガイド付きインポートにより、外部ソースから取り込まれたスキルは使用前にコントラクトスキーマに照らしてレビューされることが強制されます。テスト容易性の観点でも実用的です。コントラクトが機械可読であるため、テストの雛形を自動生成できます。これは、スキルの組み合わせの失敗が事後のデバッグを困難にする本番エージェントパイプラインで直接役立ちます。「証明可能」というフレーミングはフォーマルメソッドから借用しており、典型的なプロンプトベースのスキル記述より厳密です。
Source: https://github.com/modiqo/skillspec
modiqo/cliare
CLI Agent-Readiness Evaluation（cliare）は、コマンドラインツールが人間の介入なしにLLM agentによって操作できる度合いを測定するツールです。コマンド形状推論（command-shape inference）を実行し、ヘルプテキスト、manページ、および観測された動作を解析することで、CLIのサブコマンドツリー、フラグ、および引数型の構造化モデルを構築します。このモデルから、出力フォーマットの予測可能性、idempotencyシグナル、エラーコードの一貫性、および機械解析可能な出力の利用可能性を網羅したagent-readinessスコアを生成します。CIスコアカードとの統合により、readinessの回帰に基づいてリリースをゲーティングすることが可能となります。これはagentがツールチェーンの第一級の利用者である場合に重要です。推論パイプライン自体も独立して有用であり、CLIインターフェースの型付きスキーマを生成し、手動でドキュメントを作成することなくtool-calling LLMに直接供給できます。既存のCLIツールチェーン上でAI自動化パイプラインを構築するDevOpsおよびプラットフォームチームを対象としています。
Source: https://github.com/modiqo/cliare
lemma-work/lemma-platform
エージェントを外部ツールとして扱うのではなく、人間とエージェントの混合チームを中心に設計されたオープンソースの協調ワークスペースです。このアーキテクチャは、人間とエージェントの両方を第一級のワークスペース参加者としてモデル化し、共通のAPIサーフェスを通じてタスクの状態、コンテキスト、および成果物を共有します。これにより、サイドチャネルを介してエージェントを人間中心のインターフェースに後付けするという典型的なパターンを回避しています。このプラットフォームは共有タスクグラフを維持しており、作業項目を人間またはエージェントのいずれかに割り当てることができ、それらの間のハンドオフは来歴（provenance）とともに追跡されます。オープンソースのセルフホスティングが主要なデプロイメントモデルであり、データレジデンシー要件を持つチームにとって重要です。この設計は、チームコンテキスト内でのエージェントアクションの説明責任と監査可能性が必須要件となる「自動化スクリプトとしてのエージェント」から「コラボレーターとしてのエージェント」ワークフローへの移行を進める組織に関連性があります。
Source: https://github.com/lemma-work/lemma-platform
umputun/agterm
人間のインタラクティブセッションではなく、エージェント型ワークフロー専用に構築されたターミナルエミュレータです。標準的なターミナルは人間が出力を読んで応答を入力することを前提としていますが、agterm はターミナルの I/O に構造化されたイベントレイヤーを追加することで、エージェントプロセスが出力ストリームをプログラム的に監視し、プロンプトを検出し、入力を注入し、長時間実行されるコマンドのライフサイクルを処理できるようにします。Go で書かれており、スクリーンスクレイピングや expect スタイルのスクリプティングのような脆弱な手法を使わずに、信頼性の高いターミナルインタラクションが必要なエージェント実行環境への組み込みを対象としています。エージェント型フローモデルにより、次の入力が解析済みの出力に依存するような分岐インタラクションパターンを、継ぎ接ぎのステートマシンではなくファーストクラスの構造として扱うことができます。プログラム的な API を持たないレガシー CLI ツールやインタラクティブなプログラムを駆動する必要がある上位レベルのエージェントフレームワークの、インフラコンポーネントとして有用です。
Source: https://github.com/umputun/agterm
yeet-src/httpinspect
ローカルホスト上で最もアクティブなプレーンテキストHTTPエンドポイントを表示する、top インターフェースをモデルにしたライブターミナルダッシュボードです。ループバックおよびLANインターフェース上のHTTPトラフィックをキャプチャし、リクエスト／レスポンスのペアをリアルタイムで解析して、リクエストレート・エラーレート・レスポンスレイテンシによってエンドポイントをランク付けします。これらはすべて自動更新されるncursesスタイルのTUIで表示されます。対象サービスへのプロキシや計装は不要で、パケットキャプチャレイヤーで動作します。マイクロサービストラフィックのデバッグ、負荷テスト中のホットエンドポイントの特定、あるいはホスト上で実際に流れているHTTP（HTTPSではない）トラフィックの監査に直接役立ちます。プレーンテキストHTTPへの特化は実用上の制約であり、カバレッジをゼロ設定での動作と引き換えにしています。開発環境、暗号化されていないHTTPを使用する内部サービスメッシュ、またはTLS終端が別の場所で行われるレガシーシステムに適しています。
Source: https://github.com/yeet-src/httpinspect
alvinunreal/lazyskills
エージェントスキルのミッションコントロール：エージェントのデプロイメント全体にわたり、スキルの登録・バージョン管理・呼び出しルーティング・モニタリングを一元化する管理レイヤーです。スキルの定義をエージェントのコードベース全体に分散させるのではなく、lazyskillsはスキルを一度宣言し、名前とバージョンで参照するレジストリを提供します。名前に含まれる「lazy（遅延）」は遅延ロードを反映しており、スキルは呼び出されるまでインスタンス化されないため、スキルセットが大規模なエージェントでのオーバーヘッドを削減します。コントロールプレーンはスキルのヘルス状態・呼び出し回数・失敗率・レイテンシを公開し、どのスキルが使用されているか、どれが失敗しているか、どれをリタイアできるかをオペレーターが把握できるようにします。これは実際の運用上のギャップに対処するものです：ほとんどのエージェントフレームワークはスキルの追加を容易にしていますが、スケールでの管理ツールが提供されていません。共通のスキルライブラリを共有する複数のエージェントを運用するチームを対象としています。
Source: https://github.com/alvinunreal/lazyskills
AI-Builder-Club/skills
エージェントスキル開発のためのコードベースハーネスおよびループエンジニアリングツールです。本リポジトリは、スキルの実装・テスト・反復を緊密な開発ループの中で行うための標準化されたスキャフォールドを提供します。具体的には、スキルを記述し、エージェント呼び出しをシミュレートするハーネスに対して実行し、構造化された出力を観察し、反復するという流れになっています。「ループエンジニア」というフレーミングは、ハーネスがスキルの宣言されたコントラクトから生成されたエッジケース入力を通じてスキルを能動的に駆動し、ライブエージェントへの統合前に障害を表面化させることを意味します。このコードベースは再利用可能なスキルのコミュニティ貢献型ライブラリとして設計されており、ハーネスが一貫したインターフェースを強制することで、異なるエージェントフレームワーク間でスキルが組み合わせ可能になっています。スキルベースのエージェントを構築するチームにとっては、スキルごとのセットアップコストを削減し、共通のテスト語彙を提供します。コミュニティ貢献モデルにより、一般的なエージェントタスクに対するリファレンス実装ライブラリとして有用です。