ブラウザから OpenAI Responses 互換 API を直接叩ける CORS Chat が公開。LittleLearner が事前学習フィルタは能力上限を決めると実証ほか6件

今日の3行

Simon Willison が OpenAI Responses 互換 API の動作確認用 Web UI「CORS Chat」を公開しました。Qwen 3.8 27B を LM Studio（M5 MacBook Pro / DGX Spark）で試すために GPT-5.6-Sol xhigh で同日にビルドしたもので、LM Studio の --cors オプションと OpenRouter の両方で動作確認済みです。
小学5年生までの教材だけから LLM をゼロ学習させる「LittleLearner」プロジェクトが公開されました。88B トークンの K-5 カリキュラム限定コーパスで 0.6B / 1.3B / 5B を学習し、スケーリング・SFT+GRPO・コンテキスト学習はいずれも学習範囲外の能力を伸ばさず、事前学習のフィルタが能力の上限を決めると実証しました。
Dario Amodei が規制について長文投稿を公開しました。「規制で少数企業に集中 vs 広く配布」は偽の二択であり、規制＝独占というシリコンバレーの短絡を否定しています。

深掘り: CORS Chat、ブラウザから OpenAI Responses 互換 API を直接叩ける無料 Web UI が公開

要点 Simon Willison が、OpenAI Responses 互換 API の動作確認用 Web UI「CORS Chat」を公開しました。GPT-5.6-Sol xhigh で同日にビルドしたもので、Qwen 3.8 27B を LM Studio（M5 MacBook Pro と NVIDIA DGX Spark の両方）で試すための動作確認環境として作られています。ツール本体は tools.simonwillison.net/cors-chat で公開されています。

CORS Chat は、CORS ヘッダーに対応した OpenAI Responses 互換の API エンドポイントに、ブラウザ内で直接チャットできるツールです。エンドポイントはカスタムヘッダー込みで設定でき、会話はブラウザ内に保存されて JSON としてコピーペーストでエクスポートできます。異なるモデルや reasoning 設定で複数のチャットセッションを管理できます。

動作確認済みの組み合わせは、LM Studio の --cors オプションと OpenRouter の2つで、どちらも問題なく動作しています。会話のトークンがストリーミングされている最中に SVG 画像が生成されていることを検知し、生成途中からチャット内にプログレッシブに描画していくという工夫もあります。

なぜ重要か ブラウザから直接、CORS 対応の OpenAI Responses 互換エンドポイントに接続できる無料ツールです。ローカル LLM とクラウド API を併用する個人開発者の動作確認環境として、今日からそのまま使えます。

また、Qwen 3.8 27B が M5 MacBook Pro と DGX Spark というローカル環境で実用域に来ている証左でもあります。LM Studio の --cors オプションと組み合わせて動くことから、ローカルサーバーにモデルを立ててブラウザの Web UI から叩くという、クラウド API とほぼ同じ開発体験が手元のマシンで完結しつつあります。

仕組み 通常、ブラウザから別オリジンの API へのリクエストは、同一オリジンポリシーによって制限されます。ブラウザはクロスオリジンのリクエストの前にプリフライトを行い、API サーバーが Access-Control-Allow-Origin などの CORS ヘッダーで許可を返した場合にだけ、リクエストとレスポンスの読み取りが成立します。つまり「CORS ヘッダーに対応したエンドポイント」という条件は、ブラウザから直接 API を叩くための必須条件です。

CORS Chat はこの条件を満たすエンドポイントをブラウザから指定するだけで、中間サーバーを一切経由しません。LM Studio は --cors オプションを付けて起動することでサーバー側の CORS 対応を有効化でき、OpenRouter はサーバー側で対応済みのため、両者のどちらでもクライアントのみで完結します。カスタムヘッダーを設定できるため、認証情報が必要なエンドポイントにも対応できます。

会話の永続化もブラウザ側で完結しています。会話はブラウザ内に保存され、コピーペーストできる JSON としてエクスポートできるので、再現手順をそのままテキストで共有できます。複数セッションをモデル・reasoning 設定ごとに分けて管理できるため、比較動作確認にそのまま使えます。ストリーミング中に SVG 画像の生成を検知してプログレッシブに描画するのは、レスポンスの途中経過をそのまま可視化する工夫で、画像生成系モデルの動作確認をストリーミングのまま行える設計です。

導入するなら

Qwen 3.8 27B を LM Studio で動かしているなら、起動時に --cors オプションを付けてから CORS Chat にエンドポイントを設定します。これだけでローカルモデルの動作確認環境になります。
クラウド側は OpenRouter のように CORS 対応の Responses 互換エンドポイントをそのまま指定します。ローカルとクラウドを同じ UI で切り替えて比較できます。
認証情報が必要なエンドポイントでは、カスタムヘッダーの設定欄にトークンを指定します。
モデルや reasoning 設定ごとにセッションを分けて管理し、動作確認結果は JSON でエクスポートして手順を共有・再現できる状態にしておきます。
検証の前提として、接続先エンドポイントが本当に CORS ヘッダーに対応しているかを先に確認します。対応していないエンドポイントはブラウザからは繋げません。

原典 CORS Chat

2. 小学5年生までの教材だけでゼロ学習させた LLM「LittleLearner」、事前学習フィルタが能力の上限を決めると実証

要点「LittleLearner」プロジェクトは、小学5年生までの教材だけから LLM をゼロ学習させる、学習分布を制御した研究用サンドボックスです。88B トークンのコーパス「LittleCurriculum」は、FineWeb-Edu から Common Core 標準（K–5）に沿った5段階のフィルタリングパイプラインで蒸留され、Grade 5 より上の概念・事実・語彙は明示的に除外されています。モデルは 0.6B / 1.3B / 5B の3スケールでスクラッチ学習され、それぞれにアーキテクチャ・トークン・レシピを共有する Unfiltered コントロールが付属します。ホステッド版の5B モデルはブラウザ上で試せます。

実験では、スケーリング・SFT+GRPO ポストトレーニング・コンテキスト学習のいずれも、カリキュラムが教えた範囲（in-scope）の能力は増幅するものの、範囲外（out-of-scope）の性能は意味のある改善を示さず、事前学習のフィルタが能力の実効的な上限を決めるという結論を示しています。チェックポイントには、事前学習モデル（Base）、MathCAMPS でポストトレーニングした数学特化型（GRPO）、汎用チャット用（Chatty）があります。

なぜ重要か スケーリング・GRPO・コンテキスト学習のいずれも学習範囲外の能力は伸びないという知見は、モデル選定時に学習データの範囲を読むことの重要性を示します。オープンウェイトモデルの能力評価の新たな視点になります。

原典 What happens when an LLM never sees material beyond fifth grade?

3. Dario Amodei が「規制で少数企業に集中 vs 広く配布」は偽の二択と指摘、規制＝独占という短絡を否定

要点 Anthropic CEO の Dario Amodei が、Gavin との thoughtful exchange を受けて規制について長文投稿しました。普段はソーシャルメディアにあまり時間を割かないが、重要な対話の核心に触れるため今回エンゲージしたいと述べています。まず規制について、「規制によって選ばれた少数の企業と政治家の手に集中させるか、広く配布するか」という二択は偽の二択だと指摘しました。シリコンバレーには「規制 = regulatory capture（規制の乗っ取り）= 権力の集中」という略記があるが、これは世界の過度に単純化された見方だと述べています。

なぜ重要か AI 規制の方向性を決める当事者（Anthropic CEO）の一次発言です。今後の API・モデル供給の枠組みがどうなるかを占う上で、追跡しておくべき動向です。

原典 @DarioAmodei の投稿

4. AI が数学で人間を超えるのは知能の向上ではなく、作業記憶制約の解除が原因だとする論考

要点 AI システムが難しい数学問題を解くとき、通常の説明は「より知能が高くなった」というものですが、この論考はより単純な可能性を指摘します。それは、AI が人間の脳よりはるかに大きな作業記憶にアクセスしている、つまり人間の作業記憶が行う機能の多くを果たす巨大な外部シンボリックワークスペースを利用している、というものです。

人間の数学者は、馴染みのない要素をごく少数しか同時に保持できません。一方 AI は、問題文全体、数百の中間方程式、破棄された複数のアプローチ、定義、制約、以前の結論を、すべてコンテキストウィンドウ内に保持できます。この性能を「優れた推論の証拠」と解釈するのが一般的ですが、その一部は、人間の推論を制限する最も重要な生物学的限界の一つである作業記憶容量の制約が外れたことを反映している可能性があります。

紙に書き出すことは問題を変形させます。紙は頭を良くするのではなく、実効的な作業記憶を拡張します。専門家は「チャンキング」によって制限を補償しますが、チャンキングは制限を排除するのではなく情報を圧縮するだけです。

作業記憶が数学にとって重要であることは、研究でも示されています。Alloway と Passolunghi (2011) は、作業記憶の測定が数学的成績に対して独自の寄与をすることを子どものサンプルで見出しました。Alloway と Alloway (2010) の6年間の縦断研究では、5歳時点の作業記憶のパフォーマンスが、IQ を分析に含めた後でも、後の読み書き能力と計算能力を予測しました。実際、後の学業成績に対して作業記憶は、研究で用いられた IQ 測定よりも強い予測因子でした。Blankenship ら (2015) も、IQ と年齢を統計的に統制した後で、作業記憶が数学的流暢性と計算の独自の変動を説明したと報告しています。Friso-van den Bos ら (2013) の大規模メタ分析も、初等学校の研究全体で作業記憶と数学の一貫した関連を見出しています。ただし、作業記憶と知能はかなり重複しており、作業記憶トレーニングが知能や数学を大きく改善することを示す証拠にはならない、という留保も付されています。

コンテキストウィンドウは人間の作業記憶と同一ではなく、書かれたものを検索・利用する不完全なシステムを備えた巨大な外部ノートブックと理解すべきです。人間は、黙って数値を選び、保持し、変換し、新しい値に置き換えるという能動的な内部記憶を持ちますが、標準的な言語モデルはこの種の私的で継続的に更新される心的状態の維持がはるかに弱く、最も安定した記憶は通常、すでに生成されたトークンの列です。そのため AI の推論はしばしば外部化されます。テキストは思考プロセスの完了報告ではなく、推論が起こる仕組みの一部なのです。

また、コンテキストウィンドウの利点はあらゆる種類の推論で等しく有用ではなく、数学で特に重要です。数学的推論は明示的なシンボルに異常にうまく翻訳できるからです。前提、定義、既知の方程式、現在の目的、証明済みの結果、排除されたケース、各ステップが有効な条件を書き出せば、その情報は安定を保ちます。数学のシンボルは安定を保つよう設計されているのです。

なぜ重要か コンテキストウィンドウを「作業記憶の拡張」として捉え直す視点は、プロンプト設計やエージェント設計でコンテキストをどう活用するかの判断基準になります。人間の数学的パフォーマンスが作業記憶のボトルネックによって部分的に制限されているなら、巨大なシンボリックワークスペースを与えられた機械は、人間のパフォーマンスを抑える認知上の制約からはるかに自由な分だけ、数学的に知能的に見えるという解釈が可能です。

原典 AI has access to a vastly larger working memory than the human brain

5. OpenAI Codex が 0.148.0-alpha.20 をリリース

要点 OpenAI Codex が 0.148.0-alpha.20 をリリースしました。2026-08-16 時点の最新版です。

なぜ重要か コーディングエージェントは週単位で更新が入ります。Codex のリリース追跡は、利用中の破壊的変更や新機能に先行して気づく手段になります。

原典 0.148.0-alpha.20

6. エージェントハーネスは「できるか」の壁を越えた。基本のソフトウェアエンジニアリングこそ重要に

要点ソフトウェアエンジニアであることの意味を自問する長文エッセイです。インターネット上にはエージェント工学とその将来への含意について、シグナルよりノイズのほうが多いと指摘し、ハーネスとモデルの組み合わせを「面白いパワーツール」と評しています。最も驚くべきことをやっている人たちは、この職業の終わりを謳うような投稿をするのではなく、道具の支点を見つけて梃子のように使いこなしていると述べています。

この1年で、エージェントハーネスは「できるか」のルビコンを越えました。一方で、大手モデルプロバイダの経済モデルは見たどの報告からも持続可能とは言えず、能力は消えるのではなく急速に縮小しています。オープンウェイトモデルは（強力な）パーソナルコンピュータで同等のことを可能にしており、それほど有効ではないものの、時間と能力の差は大きくありません。

「できるか」は始まりに過ぎません。少しの先見を持ってエージェントハーネスを使えば「動く」だけでなく「テスト可能」も得られます（red/green TDD を強く活用しています）。ただしそれ以上はそれほど堅固ではなく、コードのシーム——コードがどう動くか、その「API」、他のソフトウェアとどうフィットするか——は芸術であると同時に科学であり、主観的な判断に依存します。

デバッグ可能・保守可能・レイヤ化・コンポーザブルなソフトウェアを作ることは今なお相当な技で、その多くは広範で思慮深い reasoning を必要とします。そしてそこが、今日の LLM（最先端の frontier モデルでも）が不足している部分です。LLM は「推論」せずに予測するので、人間の知識にエンコードされていれば人間の推論を反響させられるに過ぎません。LLM の reasoning の弱さについての平易な研究論文として The Illusion of Thinking が紹介され、JEPA モデルや LeWorld Model、Yann LeCun の最近のトークなども示唆されています。

また、LLM は良いアドバイスと悪いアドバイスを区別できず、prompt injection 攻撃を常に一貫して防ぐことは構造的に不可能だという Simon Willison の lethal trifecta にも触れています。アライメントやセーフティハーネス、サンドボックスは最悪の事態への障壁を加えますが、根本的なギャップは残ります。

近い将来のモデル訓練には、ポストトレーニング（RLHF）に reasoning traces に相当するものが含まれるようになることを期待すると述べ、クリーンなインターフェース・デバッグ可能・保守可能なソフトウェアの構築が強化評価の鍵になるべきだとしています。単一の答えはなく、常にトレードオフであり、適切な抽象化を選び、認知的負荷を管理することが本質だというのが結びです。

なぜ重要か 大手モデルプロバイダの経済性に疑問を呈しつつ、オープンウェイト + ローカル実行の現実解を実務者の視点で整理しています。自前でエージェントを運用する個人開発者に刺さる視点です。

原典 Software Engineering fundamentals matter more