Product
@OpenAIDevs
OpenAI、Codexアプリの使い勝手まわりを今週まとめて改善
OpenAI Devs が、Codex アプリの細かな改善を今週いくつか投入したと報告した。長いスレッドのスクロールが滑らかになり、会話を移動しても表示位置が保たれる。スレッド切り替え時の裏処理を減らしてローカル履歴をより深く表示でき、アーカイブ済みチャットの一覧・削除も扱いやすくなった。ズーム変更時にツールチップやダイアログ、メニューなどの表示位置がずれない調整も加えている。
メモ
新機能ではなく地道なQoL改善のまとめ。日常的にエージェント型コーディングツールを使う側にとっては、長時間セッションでのスクロール・履歴まわりのストレスが直接効いてくる箇所なので、更新の中身を把握しておきたい。
出典 @OpenAIDevs↗
Perspective
@dwarkesh_sp
「コンピュータ操作の進歩はなぜこんなに遅いのか」
Dwarkesh Patel が、現在のAIの進歩の性質を考えるうえで興味深い問いを投げかけた。「コンピュータ操作(computer use)は明らかに検証可能なのに、なぜ進歩がこれほど遅いのか」というものだ。彼の見立てでは、答えは「ある領域が検証可能であるだけでは十分ではない」という点にあるという。
メモ
「検証可能ならRLで伸びるはず」という素朴な期待がなぜ当たらないのか、という論点。自社の業務をエージェントに任せられるか判断するうえで、タスクが検証可能かどうかだけでは測れない、という視点は実務的にも効く。
出典 @dwarkesh_sp↗
Perspective
@emollick
「AIは指数関数か定常状態か」── 認識のズレが議論をすれ違わせる
Ethan Mollick が、AIを「本物だ」と考える人は増えた一方で、新たな分断が生じていると指摘した。一方は「我々は指数関数的な成長の途上にいる」と捉える人々、もう一方は「ある種の定常状態にある」というメンタルモデルを持つ人々で、この前提の違いが互いの誤解を生んでいるという。
メモ
AIの導入判断や投資の温度差は、しばしばこの「前提のズレ」に起因する。相手がどちらのモデルで話しているかを意識するだけで、社内の議論の噛み合わなさが整理できる。
出典 @emollick↗
Open Models
@emollick
「オープンソース運動とオープンウェイトの最先端モデルは分けて語るべき」
Ethan Mollick が、「オープン」をめぐる議論は2つを区別すべきだと述べた。1つはハーネス(エージェントの足回り)などで最先端を押し進める活発なオープンソース運動。もう1つはオープンウェイトの最先端モデルで、こちらは一握りの中国企業の善意に完全に依存している、という指摘だ。
メモ
「オープン」とひと括りにされがちな話を、ツール側(誰でも作れる)とモデル側(出し手が限られる)に分けて見る視点。オープンウェイトモデルを前提にプロダクトを組む場合、その供給が外部の意思に左右されるリスクを意識させる。
出典 @emollick↗
Open Models
@HamelHusain
GLM 5.2に画像を渡すとどうなる ── ハーネスごとの挙動の違い
Hamel Husain が、GLM 5.2 の画像入力まわりの実挙動を共有した。GLM 自体は視覚(vision)機能を持たないが、Cursor や Amp のような一部のコーディングハーネスは画像を別のモデルに自動で回してから処理するため、結果的に画像入りでも動くという。一方 Opencode はこれを拒否し、GLM は画像をサポートしていないと明示する。
メモ
同じモデルでも、ハーネスが裏で別モデルにルーティングするかどうかで「できる/できない」が変わる好例。挙動がツール依存になっている点は、再現性やコストを見積もるうえで見落としやすい落とし穴。
出典 @HamelHusain↗
Product
@_akhaliq
「hf-claude」でClaude Code上から100以上のオープンモデルを利用可能に
_akhaliq が、Claude Code から100を超えるオープンモデルを使える「hf-claude」を紹介した。GLM 5.2、minimax-m3、deepseek v4 pro などが対象に含まれるという。
メモ
使い慣れたClaude Codeのインターフェースを保ったまま、バックエンドのモデルだけ差し替えて試せるのが利点。コストや用途に応じてオープンモデルを比較検証したい場面で、乗り換えの摩擦を下げてくれる。
出典 @_akhaliq↗
Perspective
@swyx
「推論予算を固定すれば、オープンモデルはトークン単価で稼げる」
swyx が、評価(eval)を報告する際に推論予算を一定に保つべきだという Noam の主張を、言葉どおりに受け取るとどうなるかを論じた。その帰結として、オープンモデルはクローズドなモデルのAPIに比べて「1ドルあたりのトークン量(mileage)」がはるかに大きい、と指摘している。
メモ
ベンチマークのスコアだけでなく「同じ予算で何トークン回せるか」という軸でモデルを見る発想。テスト時に推論量を増やせる手法が当たり前になるほど、トークン単価の差は実利用のコスト構造に直結する。
出典 @swyx↗
AI Agents
@TDataScience
軽量リサーチエージェントの実装ブループリント(Gemma 4 + Ollama + Agents SDK)
Towards Data Science が、軽量なリサーチエージェントを作るための実践的なブループリントを紹介した。Shuai Guo によるもので、Gemma 4、Ollama、OpenAI Agents SDK、Tavily MCP を組み合わせて構築する手順を示している。
メモ
ローカル実行のOllamaとMCP対応の検索ツールを組み合わせる構成は、自前でエージェントを試す際の最小構成として参考になる。クラウドAPIに頼らずに検証ループを回したい場合の出発点になる。
出典 @TDataScience↗
Research
@TDataScience
Transformerは「事実」をどう格納し読み出すのか ── 残差ストリームの役割
Towards Data Science が、Subhanga Upadhyay のデビュー記事を紹介した。Transformer の各層を通じて事実がどのように格納され、ルーティングされ、読み出されるのかを詳しく解説し、なぜ残差ストリーム(residual stream)がその大部分の仕事を担っているのかを論じている。
メモ
モデルの内部で知識がどこに宿るのかという解釈可能性(interpretability)の話。挙動の理由を雰囲気でなく構造から理解しておくと、なぜ特定の事実を間違えるのか、といったデバッグの勘所が変わる。
出典 @TDataScience↗
Open Models
@TDataScience
オープンソース「Docling」でローカルPDFパースを高度に行う手順
Towards Data Science が、オープンソースパッケージ「Docling」を使ってローカルマシン上で高度なPDFパースを行う方法を紹介した。Kezhan Shi と Angels Shi による「Enterprise Document Intelligence」シリーズの最新回で、ステップごとの詳細なガイドが示されている。
メモ
文書をRAGなどに取り込む前段の「パース」は地味だが品質を大きく左右する工程。クラウドにアップロードせずローカルで処理できる点は、機密文書を扱う社内利用で実務的な選択肢になる。
出典 @TDataScience↗