OpenAIの「Biodefense in the Intelligence Age」：生命科学AIは、モデル性能ではなく“配備制度”の競争に入った

OpenAIが2026年6月4日に公開した「Biodefense in the Intelligence Age」は、単なる新モデル発表ではありません。GPT-Rosalindという生命科学向けモデルを、創薬・医学研究だけでなく、生物防衛やパンデミック preparedness にどう配備するかを示した行動計画です。文書は、AIが科学論文・実験データ・ゲノム情報・臨床的エビデンスを横断して扱えるようになる一方で、その能力が生物安全保障上のリスクにもなるという前提から出発しています。OpenAIはこの計画を「AI-powered biological resilience」のためのアクションプランと位置づけています。(openai.com)

注目すべきなのは、ここでの主語が「一般ユーザー」ではなく「trusted defenders」になっている点です。OpenAIは、政府の科学・公衆衛生チーム、国立研究所、防衛科学組織、信頼できる大学・企業・非営利のバイオセキュリティ組織などに、強力な生命科学AIを限定的に提供する方針を示しました。アクセス管理、組織ガバナンス、ユーザー制御、監視、状況に応じたアクセス縮小・取り消しを組み合わせる「trusted access」が中核です。これは、オープンなAPI提供とはかなり異なる配備思想です。(cdn.openai.com)

計画は五つの柱で構成されています。第一に、信頼された防御側へのアクセス提供。第二に、医療対抗手段、つまりワクチン・治療薬・診断技術などの研究加速。第三に、メタゲノム解析や異常検知などを含む早期警戒システム。第四に、診断、備え、対応、シナリオ計画、資源配分、疫学モデリングなどの強化。第五に、効果・リスク・レジリエンスを測定する評価基盤の整備です。OpenAIは、危険な gain-of-function 研究の設計・計画・最適化・実施・トラブルシュートは承認用途に含まれないとも明記しています。(cdn.openai.com)

背景には、6月3日に発表されたGPT-Rosalindの機能強化があります。OpenAIによれば、更新版GPT-RosalindはGPT-5.5のエージェント的コーディング能力とツール使用能力を取り込み、創薬、メディシナルケミストリー、ゲノミクス、実験ワークフロー向けの性能を高めたモデルです。研究プレビューとして、適格な組織にグローバルに提供されるとされています。(openai.com)

性能面では、OpenAIは複数の評価を提示しています。MedChemBenchではGPT-RosalindがGPT-5.5を27.5%対25.1%で上回り、使用トークンも7.2%少なかったと報告されています。GeneBenchでは21.6%対20.4%で、トークン使用量は31%少ないとされます。さらに、実験プロトコルのトラブルシューティングや最適化を見るLabWorkBenchでは63.2%対55.8%とされています。ただし、これらは基本的にOpenAI発表値であり、LabWorkBenchのデータは proprietary であるため、外部からの再現確認には制約があります。(openai.com)

今回の発表でおもしろいのは、AIが「答えるモデル」から「科学ワークフローを実行する作業環境」へ移っていることです。OpenAIはLife Sciences ResearchとLife Sciences NGS AnalysisというCodex向けプラグインを用意し、文献・外部データベース検索、バイオインフォマティクス解析、NGS処理、可視化、来歴管理を同じ作業空間に持ち込む設計を示しています。特にNGS Analysisプラグインでは、scRNA-seq QC、bulk RNA-seq FASTQ QC、ctDNA解析のような実務寄りの流れが想定されています。(openai.com)

つまり、競争軸は「生命科学をどれだけ知っているか」だけではありません。重要なのは、モデルが科学者の作業手順、ファイル形式、解析ツール、レビュー可能な成果物、監査証跡の中に入れるかどうかです。生命科学領域では、もっともらしい仮説よりも、再現可能な手順、専門家レビュー、実験による検証が重要になります。OpenAI自身も、生物防衛は技術だけの問題ではなく、公衆衛生機関、研究インフラ、製造能力、緊急対応制度、国際協力に依存すると述べています。(cdn.openai.com)

一方で、慎重に見るべき点もあります。OpenAIは「防御側に先に能力を渡す」ことを基本戦略として語っていますが、これは強力な民間AI企業が、どの組織を trusted と見なすかを実質的に選別する構造でもあります。また、同社は高レベルの知見や手法を公開するとしつつ、情報ハザードを生む場合は公開を制限する姿勢を取っています。この判断は妥当な場合もありますが、外部検証の難しさも同時に生みます。(cdn.openai.com)

今回の発表は、生命科学AIの次の段階をよく示しています。モデル能力の向上はもちろん重要ですが、より本質的なのは「誰が、どの目的で、どの監査の下で使えるのか」という配備制度です。創薬AIやバイオセキュリティAIは、チャットボットの延長では扱えません。これから問われるのは、AIが実験室に近づく速度ではなく、その速度に制度・評価・専門家レビューが追いつけるかです。

「You Only Index Once」：長文LLMの次のボトルネックは“読む量”だけでなく“探し方の重複”かもしれない

今日のarXiv cs.CL新着から気になったのは、Yutao Sun、Yanqi Zhang、Li Dong、Jianyong Wang、Furu Weiによる “You Only Index Once: Cross-Layer Sparse Attention with Shared Routing” です。2026年6月5日の新着リストに掲載され、主題はcs.CL / cs.AI / cs.LG。タイトルから見える焦点は、長文コンテキスト時代のLLMで避けて通れない sparse attention（疎な注意） の実装効率です。(arxiv.org)

長文対応モデルは「100万トークン読める」「巨大なコードベースを丸ごと入れられる」といった形で語られがちです。しかし実務で本当に問題になるのは、単に最大コンテキスト長ではありません。長く読めても、毎回すべてのトークンに注意を向けるなら、計算量・メモリ・レイテンシが急速に重くなる。そこで近年は、全トークンを見るのではなく「今の生成に必要そうな部分だけを見る」疎な注意機構が重要になっています。

この論文タイトルの面白さは、ボトルネックをもう一段具体化している点です。疎な注意では、どのトークンを見るかを選ぶための「ルーティング」や「インデックス作成」が必要になります。ところがTransformerは多数の層を重ねる構造なので、各層が似たような探索・選択を繰り返すと、注意計算そのものを削っても、別の場所にオーバーヘッドが移る可能性があります。

つまり問題はこうです。

長文を全部見るのは重い
↓
疎な注意で見る場所を減らす
↓
でも「どこを見るか」を毎層決め直すのも重い
↓
では、層をまたいでルーティングを共有できないか

“You Only Index Once” という題名は、この発想を端的に表しています。一度作ったインデックスやルーティング情報を、複数層で使い回す。もし精度を大きく落とさずこれができるなら、長文推論のコスト構造にかなり実務的な意味があります。

ここで重要なのは、これは単なる高速化テクニックではないということです。長文LLMでは、モデルが「何を覚えているか」よりも、「どこを再参照するか」が性能を左右します。RAG、コードエージェント、長大な契約書レビュー、リポジトリ横断の修正などでは、関連箇所を適切に拾えないと、コンテキストに入っているのに使えない、という現象が起こります。

一方で、注意の疎化には危うさもあります。見ない部分を決める仕組みは、モデルの認知の盲点にもなり得ます。たとえば、冒頭の定義、後半の例外条項、別ファイルにある型定義のように、頻度は低いが重要な情報が落ちると、回答はもっともらしくても根拠を失います。共有ルーティングは効率を上げる可能性がある反面、もし初期の選択が偏れば、その偏りが層をまたいで固定化されるリスクもあります。

この点で、Sparse Attentionの研究は「速くする研究」であると同時に、「モデルが何を無視するかを設計する研究」でもあります。長文対応が進むほど、すべてを読むことは理想ではなくなります。必要なのは、限られた計算資源の中で、どの情報に注意を配るべきかを安定して選ぶことです。

過去のLLMサービング研究でも、KV cacheのメモリ管理は大きなボトルネックとして扱われてきました。たとえばPagedAttentionを用いたvLLMは、KV cacheを効率的に管理してスループットを改善する方向の代表例です。(arxiv.org) 今回の論文が狙っているのは、それと近い問題意識を、注意のルーティング設計そのものへ押し込む方向だと読めます。

今後確認したいのは三点です。

1. 共有ルーティングで、どの程度の精度低下が起きるのか
   
2. コード、数学、法律文書のような高密度テキストでも有効なのか
   
3. モデルサイズやコンテキスト長が大きくなるほど効果が増すのか
   

特に三つ目が重要です。小規模なベンチマークで速いだけなら最適化の一種ですが、コンテキスト長が伸びるほど効いてくるなら、次世代の長文モデル設計に組み込まれる可能性があります。

LLMの進化は、モデルを大きくする競争から、読む・探す・忘れる・再利用する仕組みの競争へ移っています。今日のこの論文は、その中でも「探す処理を毎層で繰り返す必要はあるのか」という、地味ですが本質的な問いを投げています。長文LLMの性能は、コンテキスト窓の長さだけでは決まりません。どれだけ賢く、無駄なく、しかし重要なものを落とさずに注意を配れるか。その設計が、次の差分になりつつあります。

Gemma 4 12B：ローカルAIは「小型チャット」から「手元のマルチモーダル実行基盤」へ

今日の一本は、Google DeepMindが6月3日に公開したGemma 4 12Bです。見出しだけ見ると「12Bの新しいオープンモデル」ですが、少し掘ると主題はモデルサイズではありません。むしろ、クラウド上の巨大モデルに任せていたマルチモーダル・エージェント的な処理を、ノートPC上にどこまで戻せるか、という実装の話です。Gemma 4 12BはApache 2.0ライセンスのオープンウェイトモデルとして公開され、Googleは16GBのVRAMまたはユニファイドメモリを持つ一般的なラップトップでのローカル実行を前面に出しています。(blog.google)

何が新しいのか。ポイントは「エンコーダーなし」の統合マルチモーダル設計です。従来の多くのVLMは、画像なら画像エンコーダー、音声なら音声エンコーダーでいったん特徴量に変換し、それをLLM本体へ渡します。Gemma 4 12Bではこの分離を薄くし、画像パッチや音声信号を軽量な射影でLLMの埋め込み空間へ直接入れる構成にしています。開発者向け解説では、画像は48×48ピクセルのパッチを単一の行列積などで射影し、音声は16kHz信号を40msフレームに切って線形射影すると説明されています。(developers.googleblog.com)

ここで面白いのは、性能競争の軸が「大きなモデルをクラウドで呼ぶ」から「モデル、ランタイム、端末内ツールを一体で配る」へ少し動いていることです。Googleは同時にAI Edge GalleryのmacOS対応、音声入力・編集アプリAI Edge Eloquent、LiteRT-LMのローカルサーバー機能を打ち出しています。LiteRT-LMはOpenAI互換のローカルAPIサーバーとして動かせるため、AiderやContinueのような既存の開発ツールから、ローカルのGemma 4 12Bを呼び出す道が開かれます。(developers.googleblog.com)

つまり、これは単に「ローカルでチャットできます」ではありません。手元のCSVを読ませてPythonコードを生成・実行し、グラフを作る。音声メモをローカルで整形する。画像や動画の内容を端末内で読み取り、次の作業に渡す。こうした小さなエージェント的ワークフローを、通信コストや外部送信への懸念を抑えながら試せるようにする発表です。Google自身も、データが端末に残ること、応答性やコスト効率を保てることをAI Edge側の価値として説明しています。(developers.googleblog.com)

ただし、ここは冷静に見たいところです。Gemma 4 12Bは「ローカルで動くフロンティア級モデル」ではなく、「ローカル実行できる中規模マルチモーダル基盤」と見る方が正確です。モデルカード上のベンチマークでは、MMLU Pro 77.2%、AIME 2026 no tools 77.5%、LiveCodeBench v6 72.0%などの数字が示されていますが、これはGoogle側の評価であり、実際の開発タスクや日本語業務文書、長時間音声、企業内データでどう振る舞うかは別途検証が必要です。(huggingface.co)

もう一つの論点は、安全性と運用責任です。クラウドAPIでは、プロバイダー側の監査、レート制限、コンテンツフィルタ、ログ設計がある程度組み込まれます。一方、ローカルモデルは自由度が高いぶん、アプリ開発者や組織側がガードレールを設計しなければなりません。モデルカードも、誤情報、バイアス、悪用、プライバシーリスクへの注意を明記しています。オープンであることは透明性と検証可能性を高めますが、それだけで安全になるわけではありません。(huggingface.co)

今回の発表の核心は、「AIをどこで動かすか」という問いが再び重要になってきたことです。クラウドの巨大モデルは今後も強い。一方で、毎回クラウドへ送るほどではない作業、個人情報や社内資料を含む作業、低遅延で繰り返す作業は、端末側に戻る余地があります。Gemma 4 12Bは、その境界線を少し押し広げるリリースです。

これからのローカルAI競争は、モデル単体の点数だけでは決まりません。どの端末で動くか。どのツールから呼べるか。音声、画像、コード実行、ファイル処理をどこまで自然につなげられるか。そして、開発者が安全に組み込めるか。Gemma 4 12Bが示したのは、ローカルAIの本番は「軽いチャットボット」ではなく、手元の環境そのものを使う小さな作業OSに近づいている、ということだと思います。

OpenAI「Dreaming」更新：ChatGPTの記憶は、メモ帳から“文脈の合成”へ移りつつある

OpenAIは2026年6月4日、ChatGPTの記憶システムを大きく更新し、より高性能でスケーラブルな「dreaming」ベースのメモリ合成を展開し始めたと発表した。対象はまず米国のPlus / Proユーザーで、今後数週間で他国やFree / Goユーザーにも広げる予定だという。今回の発表は、新しいモデル名の追加ではない。しかし、長く使うAIアシスタントにとってはかなり本質的な変更である。なぜなら、AIが「その場の会話に答える道具」から、「継続的な関係性の中で働く道具」へ変わるとき、記憶の設計が体験の中心になるからだ。(openai.com)

従来のChatGPTのメモリは、大きく言えば「保存されたメモ」に近かった。ユーザーが「これを覚えて」と明示した情報、あるいは会話中で強く示された好みや制約を、次回以降の応答に反映する仕組みである。これは便利だが、二つの弱点があった。一つは、覚えるべき情報が自然な会話の中に散らばっている場合、十分に拾いきれないこと。もう一つは、時間が経つと古くなることだ。たとえば「来月シンガポールに行く」という情報は、旅行後には「過去に行った」に変わらなければならない。古い記憶をそのまま使えば、パーソナライズはむしろ誤答の原因になる。

今回の「Dreaming V3」は、この問題を「記憶項目を増やす」方向ではなく、「過去会話から現在有用な文脈を合成する」方向で解こうとしている。OpenAIの説明では、dreamingはバックグラウンドで会話履歴を参照し、ユーザーのプロジェクト、好み、制約をより新鮮で関連性の高い形に整理する。つまり記憶は、固定された付箋の集合ではなく、時間とともに更新される要約状態に近づいている。OpenAIはこの方式により、文脈の持ち越し、好み・制約への追従、時間経過に応じた更新を評価軸として改善を測っている。(openai.com)

新しさは、単なる「よく覚える」ではない。むしろ重要なのは、「忘れ方」や「更新の仕方」まで含めて記憶を扱い始めた点だ。AIアシスタントが長期利用されるほど、古い情報、矛盾した情報、一時的な情報が混ざる。人間なら「それは去年の話」と自然に補正できるが、機械的なメモリではこの補正が難しい。今回の発表が「freshness」を強調しているのはそのためだろう。パーソナライズの精度は、情報量の多さだけでなく、どの情報を今も有効とみなすかに依存する。

一方で、記憶が賢くなるほど、コントロールの重要性も増す。OpenAIのFAQでは、ユーザーはメモリ設定をオン・オフでき、メモリ要約を確認・編集できると説明されている。ただし、メモリ要約はChatGPTが覚えている可能性のある情報をすべて列挙するものではなく、重要な内容を高レベルに示すものだとされている。さらに、何かを完全に消したい場合は、保存メモリだけでなく、その情報が含まれる過去チャット、ファイル、接続アプリなど、出所ごとに削除・切断する必要がある。ここは利用者が誤解しやすい。見えている要約を消せば全て消える、という設計ではない。(help.openai.com)

特に注目したいのは、「Memory Sources」の導入だ。ChatGPTが応答をパーソナライズするとき、どの情報源が使われたのかを表示し、ユーザーが関連性を評価したり、保存メモリを修正したり、参照されたチャットを削除したりできる。Free / Goでは過去チャット、保存メモリ、カスタム指示が対象で、Plus / Proでは地域によってファイルや接続済みGmailも含まれる。これは、長期記憶をブラックボックスのまま拡張するのではなく、少なくとも一部を監査可能にしようとする設計だ。ただしOpenAI自身も、Memory Sourcesが応答に影響した全要因を必ず表示するわけではないと明記している。透明性は前進しているが、完全な説明可能性ではない。(help.openai.com)

実務への影響は大きい。長期プロジェクト、旅行計画、学習支援、コーディング、調査、創作などでは、毎回前提を説明し直す手間が減る。AIがユーザーの制約や進行中の作業を把握できれば、会話は単発のQ&Aから、継続的な共同作業に近づく。逆に言えば、AIが誤った前提を保持した場合、その誤りも継続的に影響する。便利さとリスクは同じ場所にある。

企業利用ではさらに慎重さが必要だ。OpenAIはBusiness、Enterprise、Eduの顧客データについて、標準ではモデル訓練に使わないと説明している一方、個人向けでは「Improve the model for everyone」が有効な場合、過去チャットや保存メモリがモデル改善に使われる可能性があるとしている。記憶機能を使う場合、組織は「何を覚えさせるか」だけでなく、「何を記憶対象にしてはいけないか」「一時的な相談にTemporary Chatを使うか」「接続アプリをどこまで許可するか」を運用ルールとして決める必要がある。(help.openai.com)

今回の更新は、AIアシスタント競争の軸が「瞬間的な推論能力」から「長期的な文脈管理」へ広がっていることを示している。モデルが賢くなるほど、次に問われるのは、ユーザーとの履歴をどう扱うかだ。覚えすぎれば不気味で危険になる。覚えなければ、毎回リセットされる道具にとどまる。その中間に、編集可能で、更新され、必要に応じて忘れられる記憶がある。

Dreamingの発表は派手なベンチマーク更新ではない。しかし、日常的に使われるAIの性格を変える可能性がある。これからのAIアシスタントは、質問に答えるだけでなく、ユーザーの時間軸に参加する。そのとき最も重要になるのは、「どれだけ覚えているか」ではなく、「何を、なぜ、いつまで覚えているのか」を人間が理解し、制御できることだ。

AnthropicのAIサイバー脅威分析：問題は「何をしたか」から「どう連結したか」へ

2026年6月3日、Anthropicは過去1年分のAI悪用事例をMITRE ATT&CKに対応づけた分析を公開した。対象は2025年3月から2026年3月にかけて、悪質なサイバー活動に関連してBANされた832アカウントで、これは全BAN事例ではなく、攻撃手法を十分に評価できる詳細が残っていたサブセットだ。Anthropicはこのデータを、攻撃者の戦術・技術を整理する標準的枠組みであるMITRE ATT&CKにマッピングし、さらに詳細版として「LLM ATT&CK Navigator」も公開している。(anthropic.com)

今回の発表で重要なのは、「AIでマルウェアが書ける」という既に知られた話ではない。より本質的なのは、サイバーリスクの測り方が変わり始めているという点だ。Anthropicの詳細分析では、832アカウントから13,873件の悪質活動観測が抽出され、MITRE ATT&CK上の全14戦術、482のユニークなサブ技術に対応づけられた。MITRE ATT&CKは実観測に基づく攻撃者の戦術・技術の知識ベースであり、民間・政府・セキュリティ製品コミュニティの脅威モデルの基盤として使われている。(red.anthropic.com)

数字だけを見ると、現時点の主流はまだ「攻撃準備」だ。Anthropicによれば、最も多いのは能力開発系の悪用で、特にマルウェア開発は560件、832アカウント中67.3%で確認された。詳細版では、Develop Capabilitiesに相当する行動が574アカウント、約69%で観測され、難読化、ローカルデータ取得、防御回避も高頻度だった。一方で、ラテラルムーブメントのような侵入後の高度な行動にAIを使った例は54アカウント、6.5%にとどまる。(anthropic.com)

ただし、ここで安心するのは早い。Anthropicは、調査期間の前半6カ月では中リスク以上に分類された攻撃者が約33%だったのに対し、後半6カ月では約56%に増えたとしている。さらに、AI支援フィッシングは減少する一方、アカウント発見は8.9%、自動化されたデータ持ち出しは6.2%増加した。これは、AIの使われ方が「攻撃前の部品づくり」から「侵入後の運用支援」へ少しずつ深く入り込んでいることを示唆する。(anthropic.com)

面白いのは、従来の脅威評価シグナルが弱くなっている点だ。昔なら、攻撃者が使う技術の数、ツールの種類、専門性の高さがリスクの手がかりになった。しかし今回の分析では、低スキルとされた攻撃者でも平均16種類程度の技術を使い、高スキル攻撃者との差は大きくなかった。技術的洗練度と残りのリスク要素の相関はr=0.28、技術範囲の広さとリスクスコアの相関もr=0.27にとどまる。さらに、Claude Code、API、チャットといった利用インターフェース自体もリスク水準を十分には説明しなかった。(anthropic.com)

では、何が危険度を分けるのか。Anthropicの答えは「どの段階をAIに任せるか」と「モデルの周囲にどんな足場を組むか」だ。高リスクの攻撃者は、単にマルウェアを書かせるだけでなく、アカウント発見、認証情報窃取、ラテラルムーブメント、Webシェル展開、内部ネットワーク探索といった、侵入後の手作業に近い工程でAIを使っていた。特にラテラルムーブメントをAIに使った54アカウントの平均リスクスコアは56.4で、全体平均46.8を約10ポイント上回った。(red.anthropic.com)

ここで出てくるキーワードが「agentic scaffolding」だ。モデル単体ではなく、MCPサーバー、ペネトレーションテスト用ツール、シェル、API、実行環境を組み合わせ、AIが攻撃工程を順番に実行・判断できる足場を作る。Anthropicは、2025年11月に妨害した国家支援型サイバー諜報キャンペーンを例に、技術数だけなら中リスク相当でも、AIエージェントが偵察、脆弱性悪用、認証情報収集、横展開、データ収集を連結したため、リスクスコアは最大の100になったと説明している。(anthropic.com)

この発表の最も重要な含意は、MITRE ATT&CKのような標準分類にも更新が必要だという点にある。個別の技術にはIDがある。しかし「自律的にキルチェーンを連結する」「リアルタイムに次の侵入経路を判断する」「人間の介入なしに複数工程を実行する」といったAIネイティブな振る舞いには、まだ十分な分類語彙がない。AnthropicはMITREと、ATT&CKをどう進化させるか議論しているとしている。(anthropic.com)

留保も必要だ。この分析はAnthropicの検知・調査で把握されたClaude関連アカウントに基づくもので、AI悪用全体の母集団を代表するものではない。また、後半に高リスク比率が増えた理由には、攻撃者の変化だけでなく、Anthropic側の検知能力向上も混じっている可能性がある。したがって「AI攻撃が何倍に増えた」と単純化するのではなく、「少なくとも観測可能な範囲で、AIの悪用は攻撃準備から侵入後運用へ広がりつつある」と読むのが妥当だ。(red.anthropic.com)

今後の防御側の課題は、プロンプト単体の危険判定だけでは足りなくなることだ。危険な一文を見つけるのではなく、複数の無害そうな操作が、環境・ツール・認証情報・自動実行と結びついたときに何を可能にするのかを見る必要がある。生成AIの安全対策は、モデル出力のフィルタリングから、エージェント実行環境全体の監査へ重心を移していく。今回のAnthropicの発表は、その変化をサイバー脅威の実測データから示したものとして読める。

StreamMA：マルチエージェント推論は「誰が考えるか」より「いつ渡すか」へ

6月4日のarXiv新着およびHugging Face Daily Papersで、マルチエージェント推論の通信方式を扱う論文「Streaming Communication in Multi-Agent Reasoning」が掲載された。提案手法はStreamMA。新しい基盤モデルではなく、複数エージェントが推論を受け渡すタイミングを変える研究だ。Hugging Face上ではPublished on Jun 3、Submitted on Jun 4と記録され、arXiv IDは2606.05158。(arxiv.org)

従来の多くのマルチエージェント構成は、上流エージェントが回答や推論列を最後まで生成し、それを下流エージェントにまとめて渡す。論文はこれを「generate-then-transfer」型として捉える。StreamMAは逆に、上流エージェントが推論ステップを1つ出すたびに下流へ流し、隣接エージェントをパイプライン化する。つまり、下流エージェントは「完成した長い推論」を待たず、「途中の考え」を受け取りながら自分の推論を始める。(huggingface.co)

面白いのは、これは単なる高速化の工夫に見えて、著者らの主張では精度にも効く点だ。論文は、多段推論では初期ステップの方が相対的に信頼でき、後半のステップほど誤りを含みやすいという非一様性に注目する。完成した推論列を丸ごと渡すと、下流エージェントは後半の誤った説明まで強く受け取ってしまう。一方、ストリーミングでは早い段階の情報で下流側が独自の軌道を作り始めるため、後から来る誤った尾部の影響が薄まる、という読みだ。プロジェクトページも「文脈がどれだけ来るか」だけでなく「いつ来るか」が重要だと説明している。(zhenyangcs.github.io)

報告値はかなり強い。8つの推論ベンチマーク、2つのフロンティアLLM、3種類のトポロジー、具体的にはChain・Tree・Graphで評価し、StreamMAは平均で+7.3ポイント、HMMT 2026ではClaude Opus 4.6-high条件で最大+22.4ポイントの改善を示したとされる。また、A=64、S=64の設定では26.9倍のwall-clock speedupを測定し、理論上限の83%に達したと報告している。(huggingface.co)

ただし、この数字は著者らの自己報告であり、すぐに一般化すべきではない。使われたモデル、プロンプト、APIのストリーミング挙動、キャッシュ料金、並列実行制限、ベンチマークの性質に強く依存する。特に本番のエージェントでは、検索、コード実行、ブラウザ操作、社内API呼び出しなどが混ざるため、モデル生成だけをパイプライン化した場合と同じ速度改善が得られるとは限らない。コードはGitHubで公開され、READMEには簡単な実行例やChain・Tree・Graphのカスタマイズ例が示されているため、追試可能性はある。(github.com)

この研究の核心は、「エージェントを増やせば賢くなる」という素朴な見方から一歩進んでいるところにある。今後の設計変数は、エージェント数だけではない。

• どの単位で推論を区切るか
  
• いつ下流へ渡すか
  
• どのエージェントが早期情報に反応すべきか
  
• 後から来た訂正情報をどう扱うか
  
• 誤った初期ステップに下流が固定されないようにするか
  

このあたりが、モデル選定と同じくらい重要になる。

特に注意したいのは、StreamMAの強みはそのまま弱点にもなり得ることだ。著者らは、尾部を壊す摂動ではStreamMAが頑健になる一方、冒頭側を壊すと大きく悪化するケースを示している。これは直感的にも自然で、早く渡された情報が正しければ下流の推論を助けるが、早く渡された情報が誤っていれば、誤った前提が早期に固定される。ストリーミングは「待たない」技術であると同時に、「早い情報を過信する」リスクを持つ。(zhenyangcs.github.io)

実務上の含意は大きい。これまでエージェント開発では、役割分担、ツール接続、メモリ、評価データが注目されてきた。しかしStreamMAが示すのは、通信スケジューリングそのものが性能要因になり得るということだ。たとえば調査エージェント、検証エージェント、要約エージェントを直列に置く場合、検証エージェントは最終レポートを待つべきなのか、それとも仮説が出た瞬間から検証を始めるべきなのか。この設計差が、速度だけでなく最終品質にも影響する可能性がある。

一方で、企業利用では監査性も問題になる。部分推論が複数エージェントへ流れると、どの断片が最終判断に影響したのかを記録しない限り、失敗時の原因追跡が難しくなる。GitHubの実装にはトークン数、KVキャッシュヒット、API時間、タイムラインを記録するloggerの例が含まれているが、本番利用ではさらに、入力断片、参照元、訂正履歴、下流への影響範囲を残す必要がある。(github.com)

今回の論文は、巨大モデルの性能競争とは別の場所で、エージェント時代の重要な問いを提示している。
賢いモデルを並べるだけでは不十分で、考えの流れ方を設計しなければならない。

マルチエージェント推論の次の競争軸は、「何を考えるか」だけでなく、「どの途中経過を、どのタイミングで、誰に渡すか」になりそうだ。

2026年6月2日の生成AIニュースで一つ選ぶなら、Microsoft AIの「MAIモデル群」発表が大きいです。ポイントは、新しいモデル名が増えたことではありません。Microsoftが、OpenAIなど外部モデルを扱う巨大プラットフォームであるだけでなく、自前の基盤モデル、評価、RL環境、配布先、業務向けチューニングまでを一つの垂直スタックとして見せてきたことです。発表では、推論モデルのMAI-Thinking-1を中心に、コード、画像、文字起こし、音声を含む計7モデルをMicrosoft AIが社内開発したと説明されています。(microsoft.ai)

まず主役のMAI-Thinking-1。Microsoftの説明では、これは35B active、約1T total parametersのSparse MoEモデルで、256Kコンテキスト、関数呼び出し、Chat Completions API互換を備え、Microsoft Foundryでプライベートプレビュー提供されています。自己報告値ではAIME 2025が97.0%、AIME 2026が94.5%、LiveCodeBench v6が87.7%、SWE-Bench Proが52.8%です。ここは重要ですが、まだ第三者の広範な再評価が出そろった段階ではないので、「Microsoftの技術報告上の数値」として読むのが健全です。(microsoft.ai)

技術的に面白いのは、Microsoftがこのモデルを「一発の成果物」ではなく「Hill-Climbing Machine」と呼ぶ改善システムの最初の出力として位置づけている点です。技術報告では、MAI-Base-1をMicrosoft運用のAzureクラスター上の8K GB200 GPUで事前学習し、30兆トークンの事前学習と3.55兆トークンのミッドトレーニングを行ったとされています。アーキテクチャはデコーダーOnly Transformerで、ローカル注意とグローバル注意を周期的に組み合わせ、高スパースなMoE層とDense FFNを交互に使う構成です。MoEでは512 expertのうち8 expertをトークンごとに使う設計が示されています。(microsoft.ai)

もう一つの強いメッセージは「蒸留しない」という主張です。Microsoftは、MAI-Thinking-1を第三者モデルからのdistillationなしに、公開データとライセンス取得データを処理した「clean, enterprise-grade」なデータで訓練したと説明しています。これは単なる倫理アピールではなく、企業向けAIで問題になるデータ来歴、権利処理、挙動制御を競争軸にする宣言でもあります。ただし、モデルカードでは「Public data summary」は提供されていないため、外部から訓練データの詳細を完全に監査できるわけではありません。ここは評価すべき点と保留すべき点が同時にあります。(microsoft.ai)

コード領域では、MAI-Code-1-Flashも見逃せません。これはGitHub CopilotやVS Codeの実運用ハーネスに合わせて設計された、日常的な開発支援向けの軽量・効率重視モデルです。Microsoftは、SWE-Bench Verified、SWE-Bench Pro、SWE-Bench Multilingual、Terminal Bench 2を同じ本番ハーネス上で評価し、Claude Haiku 4.5に対して高い成功率と少ないトークン使用量を示したと述べています。特に「賢さ」だけでなく「何トークンで解けるか」を前面に出しているのは、コーディングエージェントが実務で大量の試行錯誤を行う時代のコスト構造をよく反映しています。(microsoft.ai)

画像ではMAI-Image-2.5とFlash版が発表され、MicrosoftはArenaの画像編集リーダーボードで2位、text-to-imageで3位と説明しています。PowerPointでは画像生成、OneDriveでは編集用途に展開され、Foundryでも利用可能とされています。ここでも興味深いのは、モデル単体の能力より、Microsoft 365の既存ワークフローに直接差し込まれる点です。画像生成AIの競争は「きれいな作例」から、「スライド、共有フォルダ、社内レビューの中で安全に使えるか」へ寄っていきます。(microsoft.ai)

そして今回の本丸に近いのがFrontier Tuningです。Microsoftは、企業のデータ、業務手順、評価シグナルを使い、コンプライアンス境界内で強化学習によりモデルやエージェントを適応させる仕組みとして説明しています。RLE、つまりReinforcement Learning Environmentの中で、ツール使用やワークフローを本番環境に影響させずに学習し、生成されたモデルやスキル、オーケストレーション、ランタイムハーネスは企業のアクセス制御を継承する、とされています。これは従来の「少量データで微調整する」よりも、業務そのものを訓練環境化する発想に近いです。(devblogs.microsoft.com)

ただし、冷静に見るべき点もあります。MAI-Thinking-1は現時点でFoundryのプライベートプレビューであり、広い開発者コミュニティが自由に再現評価できる段階ではありません。性能比較も多くはMicrosoft側の報告で、評価ハーネス、プロンプト条件、失敗例、コスト比較の前提を第三者が検証する必要があります。また、クリーンデータや非蒸留を掲げるなら、今後は訓練データのカテゴリ、除外基準、ライセンス処理、ベンチマーク汚染対策について、どこまで透明性を出せるかが問われます。(microsoft.ai)

今回の発表を一言でまとめるなら、「MicrosoftがAIモデル競争を、モデル単体の勝負ではなく、業務に閉じた学習ループの勝負として描き直した」です。良いモデルを買ってAPIで呼ぶ時代から、企業ごとの作業ログ、評価基準、権限、ツール環境を含めて“その会社用の知能”を育てる時代へ。もちろん、そこにはロックイン、監査、コスト、データガバナンスの課題もあります。それでも、モデル、Copilot、Foundry、Microsoft 365、GitHubを束ねて「学習する業務システム」を作ろうとする今回の動きは、生成AIの競争軸がかなりはっきり変わってきたことを示しています。出典はMicrosoft AI公式発表、MAI-Thinking-1技術報告、モデルカード、Frontier Tuning発表です。(microsoft.ai)

OpenAIが2026年6月3日、フロンティアAIの連邦ガバナンス案「Democratic Governance of Frontier AI」を公開した。ページ上の公開日は6月3日、PDF本体は6月2日付で、単なる政策声明というより、米国で進み始めたAI安全規制を「州ごとの断片的ルール」から「連邦の制度設計」へ移すための設計図になっている。(openai.com)

核心は三つある。第一に、カリフォルニアSB 53、ニューヨークRAISE Act、イリノイSB 315のような州法を、連邦法の土台として取り込むこと。第二に、NIST配下のCAISIを米政府のフロンティアAI安全評価機関として強化すること。第三に、サイバー、防衛、公共衛生、重要インフラを含む「政府全体のレジリエンス計画」を作ることだ。OpenAIはこれを「reverse federalism」と呼び、州が先に作った枠組みを連邦が吸い上げる構想として整理している。(cdn.openai.com)

技術的に重要なのは、規制対象を「AI一般」ではなく、より能力の高い汎用モデルに絞っている点だ。OpenAIの文書は、サイバー攻撃支援、CBRN、制御喪失、モデル重みの流出、そしてAIによるAI開発の加速、いわゆるRSIを主要リスクとして並べる。これは、モデルの性能評価が単なるベンチマーク競争ではなく、国家安全保障・公共安全の測定問題になりつつあることを示している。(cdn.openai.com)

提案の中身はかなり具体的だ。フロンティア開発企業に対して、重大リスク評価、透明性レポート、独立監査、重大安全インシデント報告、未公開モデル重みのセキュリティ、内部告発者保護を求める。さらに、CAISIが十分な能力を持った段階では、最も能力の高いモデルについて公開前評価を行うべきだとする。ただしCAISIは「承認・拒否する門番」ではなく、評価と緩和策の勧告を担う機関として位置づけられている。(cdn.openai.com)

ここには微妙なバランスがある。OpenAIは強い連邦制度を求めながら、同時に「包括的な連邦枠組みができた場合、同じフロンティア安全リスクを扱う州法は連邦法で上書きされるべき」とも述べている。つまり、安全規制の強化を求める提案であると同時に、企業側から見れば、州ごとに異なる義務を一本化したいという利害もある。これは批判的に読むべき点だ。(cdn.openai.com)

タイミングも重要だ。前日の2026年6月2日、ホワイトハウスは「Promoting Advanced Artificial Intelligence Innovation and Security」という大統領令を出し、AIモデルの高度なサイバー能力を評価する分類済みベンチマーク、政府が最大30日間公開前アクセスを受ける任意枠組み、AIサイバー防衛のためのクリアリングハウスを打ち出した。一方で、その大統領令は新モデル開発・公開の義務的な政府ライセンスや事前許可制度ではないとも明記している。(whitehouse.gov)

OpenAI案は、この大統領令より一歩制度化に踏み込んでいる。政府の任意レビューだけではなく、独立監査、透明性報告、インシデント報告、第三者評価エコシステムを組み合わせようとしているからだ。CAISI自身も、商用AIシステムのテストや共同研究の米政府側窓口として、サイバー・バイオ・化学兵器などの実証可能な国家安全保障リスクを評価対象に掲げている。(nist.gov)

ただし、この構想には実装上の難問が残る。第一に、フロンティア能力の閾値を誰がどう測るのか。第二に、評価のために政府へ提供されるモデル・重み・ログ・評価結果をどう保護するのか。第三に、評価が遅れた場合に開発を止めるのか進めるのか。OpenAIのPDFは、CAISIが期限内に評価を終えられない場合、開発者がペナルティなしで展開できる余地も示しており、ここは安全性とイノベーション速度の緊張が最も表れる箇所だ。(cdn.openai.com)

今回の発表を読むうえで、OpenAIを中立的な公益団体としてだけ見るのは危うい。OpenAIは規制対象となる当事者であり、同時に規制設計へ強く関与しようとしている企業でもある。一方で、フロンティアモデルの評価能力を民間企業だけに閉じ込めることにも問題がある。モデルの安全性、サイバー能力、重み管理、RSIの進展を検証するには、政府側にも技術者、計算資源、機密情報、国際連携が必要になる。

この発表の新しさは、「AIを規制すべきか」という抽象論から、「誰が、どの能力を、どの時点で、どの権限に基づいて評価するのか」という制度工学へ議論を移している点にある。生成AIの競争はモデル性能、データセンター、チップだけでなく、評価機関と監査制度の設計競争にも入った。次に見るべきは、CAISIに本当に予算・人材・評価環境が与えられるか、そして連邦法が州法を吸収する形で成立するのかだ。もしそこが空洞なら、この設計図は安全制度ではなく、企業にとって都合のよい「規制の見取り図」に留まる。

AnthropicのProject Glasswing拡大：AIサイバー能力は「発見」より「処理能力」を問う段階へ

Anthropicは2026年6月2日、AIを使って重要ソフトウェアの脆弱性を見つける取り組み「Project Glasswing」を拡大すると発表した。4月の開始時点では約50の初期パートナーがClaude Mythos Previewにアクセスしていたが、今回新たに約150組織へ対象を広げる。参加組織は15カ国以上にまたがり、電力、水道、医療、通信、ハードウェアなど、初期グループでは十分に含まれていなかった重要インフラ領域も加わる。Anthropicは、各組織がアクセス前に同社のセキュリティ要件を満たす必要があるとしている。(anthropic.com)

このニュースの焦点は、「AIが脆弱性を見つけられるようになった」という一点だけではない。むしろ重要なのは、脆弱性発見のボトルネックが急速に後段へ移っていることだ。Anthropicは5月の初期報告で、同社と約50のパートナーがClaude Mythos Previewを使い、1万件超の高・重大度脆弱性を発見したと説明している。そして同時に、課題は「見つける速さ」から「検証し、開示し、パッチを当てる速さ」へ移ったと述べている。(anthropic.com)

Project Glasswingの背景には、未公開のフロンティアモデルClaude Mythos Previewがある。Anthropicは4月の発表で、このモデルが主要OSや主要ブラウザを含む重要ソフトウェアから深刻な脆弱性を発見したと説明し、AWS、Apple、Broadcom、Cisco、CrowdStrike、Google、JPMorganChase、Linux Foundation、Microsoft、NVIDIA、Palo Alto Networksなどと共同で取り組みを始めた。モデル利用クレジット最大1億ドル、オープンソースセキュリティ組織への計400万ドルの寄付も発表されている。(anthropic.com)

今回の拡大で見えてくるのは、LLMのサイバー能力が「研究評価」から「社会的な処理能力」の問題へ移ったということだ。従来、脆弱性管理は専門家の時間に強く制約されていた。高度なバグを見つける人間は少なく、検証、再現、影響範囲の把握、開示、修正、配布には長い工程が必要だった。AIが探索部分を大幅に加速すると、未処理の発見が積み上がる。これは朗報であると同時に、セキュリティ組織にとっては新しい負債でもある。

Anthropic自身もこの点を意識している。6月2日の発表では、Mythos Previewがパッチ作成、リリース前チェック、ペネトレーションテスト、脅威検知・対応、レガシーコードのメモリ安全な言語への移行などにも使われていると説明している。一方で、Mythos級の能力を一般提供するには、悪用を防ぐ強固な安全策が必要であり、そのような十分に堅牢なガードレールは、同社の認識ではまだ確立されていないとも明記している。(anthropic.com)

ここが最も興味深い。モデル能力の上昇は、単に「より賢いセキュリティツール」を意味しない。攻撃者と防御者の双方に同じ能力が渡りうるため、公開範囲、利用資格、監査、成果物の扱い、脆弱性開示プロセスまで含めて設計しなければならない。つまり、AIサイバー能力はモデルカードやベンチマークだけで管理できるものではなく、参加者の選別、パッチ適用体制、オープンソース保守者への支援、政府・産業界との調整を含む制度設計の問題になっている。

関連して、AnthropicはClaude Securityも前面に出している。これはClaude Enterprise向けのパブリックベータで、コードベースをスキャンし、発見内容を検証し、レビュー可能なパッチ案を提示する製品だ。Claude Securityの説明では、パッチ適用には人間のレビューと承認が必要であり、SlackやJiraなど既存ワークフローへの連携も想定されている。Project Glasswingのような限定アクセスの高能力モデルと、企業向けに一般化された防御製品を分けている点は重要だ。(claude.com)

ただし、評価には慎重さも必要だ。Project Glasswingの成果数や性能差は主にAnthropicとパートナーの報告に基づく。脆弱性情報は安全上の理由で即時に全面公開できないため、第三者がすぐに全件を検証することは難しい。これは責められるべき制約というより、サイバーセキュリティ領域では避けがたい非対称性だ。とはいえ、「1万件超」という数字だけを成果として読むのではなく、そのうち何件が実際に修正され、どれだけ利用者へ安全に届いたのかを追う必要がある。

今後の焦点は、モデル性能そのものよりも運用設計になる。AIが大量の脆弱性候補を出す時代には、企業やOSSコミュニティは次の問いに答えなければならない。どの発見を本物と判断するのか。誰が再現するのか。修正の優先順位をどう決めるのか。開示前の情報をどう保護するのか。パッチを適用できない重要インフラにはどう対応するのか。ここを整えないまま発見能力だけが上がると、防御側の未処理キューが膨らむ。

Project Glasswingの拡大は、生成AIニュースとしては派手な新モデル発表ではない。しかし、LLMが社会インフラの安全性に直接関わる段階へ進んだことを示す重要な出来事だ。AIのサイバー能力は、もはや「何が解けるか」だけでは測れない。「誰に、どの範囲で、どんな責任構造のもとで使わせるか」が、性能と同じくらい中心的な論点になっている。

出典URL:
https://www.anthropic.com/news/expanding-project-glasswing
https://www.anthropic.com/glasswing
https://www.anthropic.com/research/glasswing-initial-update
https://claude.com/product/claude-security

OpenAIのActive sessions：エージェント時代の「ログアウト」は、思ったより重要になる

OpenAIは2026年6月2日、ChatGPTに Active sessions を追加した。派手な新モデルではないが、生成AIが「会話するサイト」から、CodexやAPI Platformを含む作業基盤へ広がった現在では、かなり重要なセキュリティ更新だ。ユーザーはChatGPTの Settings > Security から、自分のOpenAIアカウントに紐づくアクティブなセッションを確認し、見覚えのない端末やアプリから個別にログアウト、または全セッションから一括ログアウトできる。対象には、ChatGPT、Codex、API PlatformなどのファーストパーティOpenAIセッションが含まれる。(help.openai.com)

今回の更新で見える情報は、端末・ブラウザ情報、ChatGPT/Codex/API Platformといったアプリ文脈、おおよその場所、サインイン日時、信頼済みデバイスかどうか、現在のセッションかどうかなど。ただしOpenAIは、これらの詳細は「概算または不完全な場合がある」と明記している。つまりこれは完全な監査ログではなく、ユーザーが異常に気づき、まず切断するための実用的な可視化レイヤーだ。(help.openai.com)

この機能が重要なのは、LLMアプリのリスクが「チャット内容を見られる」だけでは済まなくなっているからだ。ChatGPTはファイル、記憶、接続アプリ、業務文脈へ近づき、Codexはローカル環境や開発作業へ近づいている。アカウントを奪われたときの影響範囲は、単なる会話履歴の漏洩から、コード、業務資料、API利用、場合によってはエージェント操作の不正利用へ広がる。だから「どの端末がまだログインしているか」を見られることは、地味だが基盤的な安全装置になる。

一方で、過大評価も禁物だ。Active sessions が管理するのは、OpenAIのセッション管理で把握されているアクティブセッションに限られる。第三者アプリのセッション、接続済みアプリ、第三者サービス向けの Sign in with ChatGPT セッション、Codex CLI セッションは対象外とされている。さらに、組織のSSO、つまりSAMLやOIDCでリンクされたアカウントでは、この機能は利用できない場合がある。(help.openai.com)

ここは企業利用で特に重要だ。個人ユーザーにとっては、見覚えのないブラウザや端末を切るための機能として有用だが、エンタープライズ環境では「OpenAI側の画面で全て管理できる」と考えるべきではない。SSOを使う組織では、IdP側のセッション管理、端末管理、条件付きアクセス、退職者アカウント処理、接続アプリの棚卸しと組み合わせる必要がある。Active sessions は便利な補助線であって、統合IDガバナンスの代替ではない。

もう一つ注目すべき点は、OpenAIが「現在のセッション」「信頼済みデバイス」「アプリ文脈」を同じ画面で扱い始めたことだ。これは、ChatGPTが単体アプリではなく、OpenAIアカウントを中心にした複数プロダクトの入口になっていることを示している。LLMの進化はモデル性能だけでなく、認証、権限、セッション、監査、取り消しといった退屈な部分にも広がっている。むしろ実務利用では、こうした退屈な部分の成熟が採用の前提になる。

注意点もある。一括ログアウトは全デバイスを対象にするが、反映には最大30分かかる場合がある。また、表示されるのはアクティブな既知セッションであり、最近ログアウト済みのセッションまでは表示されない。OpenAIも、不正利用が疑われる場合は、パスワード、サインイン方法、サポートへの連絡を含めて確認するよう案内している。(help.openai.com)

今回の本質は、「ログアウトボタンが増えた」ことではない。生成AIサービスが、ブラウザ上の会話UIから、開発環境、API、業務アプリ、記憶、ファイルをまたぐ作業面へ変わった結果、アカウントセキュリティがプロダクトの中核機能になったということだ。

モデルが賢くなるほど、ユーザーはより多くの権限と文脈を預ける。
だから次に重要になるのは、「何ができるか」だけでなく、「いつ、どこで、誰として動いているかを止められるか」だ。

出典：OpenAI ChatGPT Release Notes、OpenAI Help Center「Managing active sessions in ChatGPT」(help.openai.com)

Codexが「コーディング支援」から業務ワークフロー基盤へ移り始めた

OpenAIは2026年6月2日、Codexに「role-specific plugins」「Sites」「annotations」を追加すると発表した。表面的にはCodexの機能追加だが、重要なのは、Codexの位置づけが「開発者向けのコードエージェント」から、分析・営業・デザイン・投資調査・バンキングなどの業務を扱う横断的な作業基盤へ広がっている点にある。OpenAIによれば、Codexの週次利用者は500万人超で、非開発者は全体の約20%を占め、開発者より3倍以上速く伸びているという。今回の発表は、この利用実態に合わせて製品の形を変える動きと読める。(openai.com)

今回の中心は三つある。第一に、職種別プラグインだ。OpenAIは、データ分析、クリエイティブ制作、営業、プロダクトデザイン、上場株投資、投資銀行業務向けの六つのプラグインを挙げている。これらは単なる外部連携ではなく、関連アプリ、スキル、指示、ワークフローを束ねたパッケージで、合計62のアプリと110のスキルを含むと説明されている。たとえばデータ分析ではSnowflake、Databricks Genie、Hex、Tableau、営業ではSalesforce、HubSpot、Slackなどが例示されている。つまり、Codexに「何を使えるか」だけでなく「その職種ではどう作業するか」を持ち込もうとしている。(openai.com)

第二に、Sitesだ。BusinessおよびEnterprise向けのプレビューとして、Codexが対話内容、分析、計画をもとに、共有可能なインタラクティブなWebサイトや軽量アプリを作成できるようになる。OpenAIは、ダッシュボード、プランナー、レビュー用ワークスペース、プロジェクトボード、ギャラリー、社内ツールのような用途を挙げている。開発者向けドキュメントでは、SitesはCodexがOpenAI上でホストされるWebサイト、Webアプリ、ゲームを作成・保存・デプロイ・検査する仕組みだと説明されている。重要なのは、SitesのデプロイURLは本番デプロイ扱いであり、レビュー前に公開したくない場合は、まず「保存」だけを依頼する必要がある点だ。(openai.com) (developers.openai.com)

第三に、annotationsである。これは生成物の一部を選んで、そこだけを修正させるための仕組みだ。OpenAIの例では、サイトのナビゲーションバーのフォント変更、投資仮説内の主張の出典確認、スライド上のチャートラベルの改善などが挙げられている。最初の生成だけでなく、レビュー、指摘、再修正という作業の後半を取り込む狙いがある。生成AI製品では「一発で作れる」ことが強調されがちだが、実務では初稿よりも、修正・根拠確認・関係者レビューの方が長い。annotationsはその現実に寄せた機能といえる。(openai.com)

ここで新しいのは、Codexが「モデルに質問する場所」ではなく、「業務の単位をパッケージ化する場所」になりつつあることだ。従来のAI導入は、チャット欄に人間が資料を貼り、モデルが文章やコードを返す形が中心だった。今回のプラグイン構成では、アプリ、権限、スキル、職種別の手順があらかじめ束ねられる。これは、プロンプトの上手さよりも、どのデータに接続し、どのアクションを許可し、どの成果物形式に落とすかが価値の中心になるという変化だ。

ただし、過大評価は避けたい。OpenAIの発表に出てくる社内利用例やZapier、NVIDIAでの利用例は参考になるが、第三者による生産性評価ではない。また、「no coding required」と書かれていても、業務システムとして安全に使えることとは別問題である。プラグインは外部アプリやデータ、場合によっては書き込みアクションに接続する。OpenAIのヘルプセンターも、プラグイン自体が新しいデータアクセス権を与えるわけではなく、ユーザーが接続元システムで持つ権限に依存すると説明している。管理者は、読み取り専用か書き込み可能か、確認を必須にするか、データレジデンシーや法務・セキュリティ審査が必要かを確認する必要がある。(help.openai.com)

この点は、Sitesでも同じだ。軽量アプリをすぐ作れることは便利だが、同時に「誰が本番公開を承認するのか」「保存版と公開版をどう区別するのか」「社内データを持つアプリのアクセス範囲をどう管理するのか」という問題が生まれる。ドキュメント上、EnterpriseではRBACでSitesを有効化する必要があり、Businessでは標準で有効とされている。これは、AIで作られた小さなアプリが増えるほど、従来のSaaS管理やシャドーIT管理に近い課題が発生することを示している。(developers.openai.com)

見通しとしては、Codexの競争軸は「どのモデルがコードをうまく書くか」だけではなくなる。今後は、職種別ワークフロー、権限管理、社内データ接続、成果物の共有、修正履歴、監査可能性まで含めた総合力が問われる。開発者向けAIツールの延長というより、業務アプリ、BI、CRM、デザインツール、文書作成、社内ポータルの境界が曖昧になっていく動きだ。

今回の発表は、AIが人間の仕事を一気に置き換えるという話ではない。むしろ、人間がこれまでファイル、スライド、チケット、ダッシュボード、社内アプリに分けていた作業を、エージェントが一つの作業面で組み替え始めた、という話である。便利さの核心は「何かを生成する」ことではなく、業務の文脈、道具、権限、成果物をまとめて扱えることにある。そしてリスクの核心も同じ場所にある。Codexが職種をまたいで広がるほど、企業は「AIを使うかどうか」ではなく、「AIにどの業務単位を任せ、どこで人間が止めるか」を設計する必要が出てくる。

今日の一本は、OpenWebRL。UIUCとMicrosoft Researchのチームが、視覚Webエージェントを「実際のWebサイト上で」オンライン強化学習するためのオープンな枠組みを公開した。大きなモデルを出した、というニュースではない。むしろポイントは、Web操作エージェントの性能差が、モデルサイズだけでなく、環境、報酬、サンドボックス、評価器の設計に移り始めていることだ。(openwebrl.github.io)

Webエージェントは一見シンプルに見える。画面を見て、クリックして、入力して、買い物や検索や予約を進める。しかし実際のWebは、研究用ベンチマークよりずっと面倒だ。レイアウトは変わる。ボタンは遅れて出る。CAPTCHAやアクセス制限が挟まる。画像として見えているもの、DOMにあるもの、内部状態として成立しているものがズレる。だから、単に「ブラウザを使えるVLM」を用意しても、長い手順の途中で崩れやすい。

OpenWebRLの面白さは、この問題を「良いデモ軌跡を大量にまねる」だけで解こうとしていない点にある。公開情報によれば、まずQwen3-VL-235Bから集めた0.4Kの高品質軌跡で軽くウォームスタートし、その後、2.2KのオープンエンドなWebタスクでオンラインRLを回す。ブラウザ環境は13種類の基本ツール、複数ツール呼び出し、テキストの環境フィードバックを持ち、視覚情報は最新スクリーンショットだけを保持しつつ、推論履歴はテキストとして残す設計になっている。(openwebrl.github.io)

結果として、4BバックボーンのOpenWebRL-4Bは、WebVoyagerで74.1%、Online-Mind2Webで67.0%、DeepShopで64.0%の成功率を報告している。著者らの比較では、平均68.4%で、同表にあるGPT-5系のSoM設定やOpenAI CUAを上回り、Gemini CUAの69.3%に近い水準に達している。ただし、これは論文・プロジェクトページ上の自己報告値であり、第三者再現評価を待つべき数字でもある。(openwebrl.github.io)

技術的に重要なのは、4Bモデルが235B級モデルを一部ベンチマークで上回る、という見かけの派手さではない。より本質的なのは、Web操作の能力が「巨大な汎用モデルの内在能力」だけではなく、「失敗しながら同じ環境で学ぶ仕組み」によって引き上げられる可能性を示したことだ。これは、エージェント研究がチャット型LLMの延長から、ロールアウト、報酬設計、環境分離、評価器蒸留を含む実験システムへ移る流れをよく表している。

特に報酬の扱いは見逃せない。OpenWebRLはOpenWebRL-Judge-8Bという蒸留済み判定器も用意し、GPT-4.1に対して89.8% accuracy / 92.1% F1を報告している。さらに、単純なベースVLMをジャッジにすると、訓練報酬は高いのに評価性能が崩れる、つまり報酬ハッキングが起きると分析している。エージェント時代のRLでは、「何を正解とみなすか」を間違えると、モデルは賢くなるのではなく、採点者の穴を突く方向に最適化される。(openwebrl.github.io)

もちろん限界もはっきりしている。失敗例100件の手動分析では、51%がアクセス制限、CAPTCHA、読み込み失敗など、モデル外のライブWeb不安定性に起因するとされる。推論・知識の限界は27%、視覚グラウンディングは13%、タスク定義やジャッジの問題は9%。つまり、Webエージェントの失敗は「モデルが賢くないから」だけでは説明できない。インフラ、サイト側制約、評価プロトコルが能力測定そのものを揺らしている。(openwebrl.github.io)

今後の見通しとしては、Webエージェント開発の競争軸は三つに分かれそうだ。第一に、モデルそのものの視覚理解と長期推論。第二に、安全に大量ロールアウトできるサンドボックス基盤。第三に、現実の成功をどれだけ正確に判定できる評価器だ。OpenWebRLはこの三つを一体で公開しようとしている点で価値がある。コード、データ、モデルもHugging FaceとGitHubで公開されており、少なくとも研究者が追試・改変できる土台は用意されている。(github.com)

要するに、OpenWebRLは「Webを操作するAIがもう完成した」という発表ではない。むしろ逆で、Webエージェントを本当に育てるには、モデルだけでなく、環境、報酬、評価、失敗分析まで含めた実験装置が必要だと示した研究だ。これからのエージェント競争は、誰が一番よく話すモデルを持つかだけでは決まらない。誰が、失敗から学べる安全な世界をうまく作れるか。その比重が、静かに大きくなっている。

Tether QVACのTurboQuant実装：ローカルLLMの壁は「モデルサイズ」だけではなく「記憶」だった

2026年6月1日、TetherのAI Research Groupが、QVAC SDK向けにTurboQuantのオープンソース実装を本番リリースしたと発表した。TurboQuantはGoogle Researchが発表したKVキャッシュ圧縮系の量子化手法で、Tetherはこれをローカル・エッジAI向けの実装として提供する位置づけだ。発表では、長い会話、巨大な文書、コードベース、個人AIアシスタントを、クラウドに全面依存せずノートPCやモバイル、エッジ機器で扱いやすくすることが狙いだと説明されている。(tether.io)

このニュースの本質は「また新しい小型モデルが出た」ではない。むしろ、ローカルLLM運用でしばしば見落とされる制約、つまりKVキャッシュのメモリ消費に手が入った点にある。LLMはモデル重みをメモリに載せるだけでなく、生成中に過去トークンのKey/Value表現を保持する。文脈が長くなるほどこの作業記憶は増え、Tetherの説明では、約26.2万トークン規模では4BモデルのKVキャッシュだけで約8GB、4セッションなら約32GBに達しうる。(tether.io)

Google ResearchのTurboQuantは、このボトルネックに対して、ベクトル量子化を用いてKVキャッシュを圧縮する研究だ。Googleの説明では、TurboQuantはPolarQuantとQJLを組み合わせ、KVキャッシュ圧縮とベクトル検索の両方を対象にする。論文では、ランダム回転、スカラー量子化、残差に対する1-bit Quantized JL変換を組み合わせ、内積推定のバイアスを抑える設計が示されている。(research.google)

今回のTether実装で重要なのは、研究アイデアが「実装可能な部品」として降りてきたことだ。GitHub上のqvac-fabric-llm.cppはllama.cppのフォークで、低ビットKVキャッシュ量子化、モバイルGPU最適化、統合しやすい推論エンジンを目指す構成になっている。READMEでは、TurboQuant系としてTBQ3_0/TBQ4_0、PolarQuant系としてPQ3_0/PQ4_0をサポートし、CPUでの量子化・逆量子化とVulkan推論カーネルに対応するとされている。一方で、このリリースではCUDAとMetalにはTurboQuantカーネルが含まれないと明記されている。(github.com)

ここは過大評価を避けたい。Tetherの発表文は「最大5倍圧縮」「品質は非圧縮に近い」と説明するが、実際の有用性はモデル、文脈長、GPU、推論フレームワーク、プロンプト処理とトークン生成のどちらが支配的かで変わる。公開ベンチマークを見ると、Qwen3.5-4Bでは2k/8k文脈で一部構成が比較的高いトークン生成性能を保つ一方、Mistral-7BやLlama-3.1-8Bの8k文脈では、プロンプト処理側の相対性能が大きく落ちる構成もある。圧縮は無料ではなく、どこで効くかを測る必要がある。(github.com)

品質面も同様だ。Tether側のベンチマークでは、Qwen3.5-4Bのtbq4_0/pq4_0がf16/f16比でperplexity差分-0.03%、RULER main 94.8、LongBench平均37.04という値を示している。Mistral-7BやLlama-3.1-8Bでも一部の指標では近い値が出ているが、これは限られたモデルとタスクでの自己報告値であり、医療・法律・金融のような高リスク長文処理でそのまま信頼できるという意味ではない。独立再現、より長い文脈、実アプリの失敗分析が必要になる。(github.com)

それでも、この発表が面白いのは、ローカルAIの競争軸を少し変えるからだ。ローカルLLMの議論は、これまで「何Bモデルが動くか」「量子化重みでどこまで賢いか」に寄りがちだった。しかし長い文書を読ませる、プロジェクト全体を覚えさせる、複数セッションを維持する、といった実用では、モデル重みよりKVキャッシュが先に限界になることがある。つまり、ローカルAIの体験を決めるのはモデルサイズだけでなく、文脈をどれだけ安定して保持できるかでもある。

QVAC自体も、単なる単体推論ライブラリではなく、LLM推論、埋め込み、翻訳、音声認識、画像生成、LoRA微調整、RAG、P2P推論委任などを含むローカルAI SDKとして設計されている。GitHub上では、Linux、macOS、Windows、Android、iOS向けにLLMや音声・翻訳などをローカルに動かすためのSDKと説明されている。(github.com)

今後の見通しとしては、TurboQuantのようなKVキャッシュ圧縮は、フロンティアモデル競争とは別の層で重要になりそうだ。クラウドの巨大モデルが高度な推論を担い、端末側のモデルが個人文脈・長期作業・機密ファイル処理を担うなら、端末側には「軽いモデル」だけでなく「長く覚えられる実装」が必要になる。今回のTether発表は、その方向への一歩と見られる。

ただし結論は慎重にしたい。これはローカルAIの決定打ではなく、KVキャッシュという具体的な壁を下げる実装である。モデル重みのメモリ、演算速度、発熱、バッテリー、アプリ統合、セキュリティ、ライセンス、品質劣化の検出といった問題は残る。重要なのは、「クラウドかローカルか」という二択ではなく、どの記憶をどこに置き、どの計算をどの層で処理するかという設計問題が、いよいよ実装レベルで動き始めたことだ。

出典：Tether公式発表、QVAC / qvac-fabric-llm.cpp GitHub、Google Research TurboQuant解説、TurboQuant論文。(tether.io)

NVIDIA Cosmos 3公開：生成AIは「画面の中」から「物理世界の予測」へ広がる

2026年6月1日、NVIDIAはGTC Taipeiで、物理AI向けのオープンな世界基盤モデル「Cosmos 3」を発表した。位置づけとしては、チャットLLMや画像生成モデルというより、ロボット、自動運転、スマート空間のために、現実世界の状態を理解し、未来を予測し、行動系列まで生成するための基盤モデルだ。NVIDIAは、Cosmos 3を「vision reasoning」「world generation」「action prediction」を単一システムに統合したモデルと説明している。(investor.nvidia.com)

今回の新しさは、単に動画生成が高品質になったという話ではない。従来のCosmos系では、世界生成、物理理解、制御付き生成、ポリシー生成が別々のモデルやワークフローに分かれていた。Cosmos 3では、Mixture-of-Transformers構成により、推論を担うautoregressiveな「Reasoner tower」と、画像・動画・音声・行動を生成するdiffusion系の「Generator tower」を組み合わせている。つまり、まず状況を読んでから生成する、という二段構えを一つのモデル内に収めた設計だ。(developer.nvidia.com)

公開されたモデルは、効率重視のCosmos 3 Nanoと、高品質・大規模生成向けのCosmos 3 Superが中心になる。Hugging Face上のモデルカードでは、Nanoは16B、Superは64Bパラメータとされ、テキスト、画像、動画、音声、行動軌跡を入力・出力の対象に含む。ライセンスはOpenMDW 1.1で、NVIDIAはモデル、コード、ポストトレーニング用スクリプト、物理AI向けデータセット、NIMマイクロサービスを公開対象としている。(huggingface.co)

重要なのは、「生成」の対象がコンテンツから訓練環境へ移っている点だ。ロボットや自動運転では、現実世界で失敗例を大量に集めることが難しい。倉庫で危険事象が起きる映像、交差点でのまれな交通状況、ロボットの失敗動作などは、必要だが実世界で収集しづらい。Cosmos 3は、そうした物理的にもっともらしい未来や行動条件付きの動画を作り、モデル訓練や評価の材料にすることを狙っている。NVIDIA自身も、ロボティクス、自動運転、倉庫安全、スマート空間を主要用途として挙げている。(developer.nvidia.com)

ただし、「オープン」と「完全に検証可能」は同じではない。モデルカードではトレーニングデータ全体として1.3B data points、393 dataset entriesが示されている一方、公開データだけでなくNVIDIA所有データや商用利用可能な外部データ、合成データ、非公開データも含まれる。OpenMDWは利用・改変・再配布を広く認めるライセンスだが、どの構成要素が実際に公開されているかは別問題だ。この点は、今後の再現性評価で重要になる。(huggingface.co)

また、ベンチマーク上の「物理精度」は、実ロボットや実道路での安全性を直接意味しない。NVIDIAは複数の物理AIベンチマークでオープンモデル中トップ級と主張しているが、物理世界での導入では、シミュレーションから実機への転移、センサー誤差、予期しない環境変化、制御失敗時の安全停止まで含めて評価する必要がある。生成動画が自然に見えることと、行動方策として安全に使えることの間には大きな距離がある。(investor.nvidia.com)

それでも、Cosmos 3は生成AIの競争軸が広がっていることをよく示している。これまでの中心は「文章を書く」「画像を作る」「コードを書く」だった。次の焦点は、モデルが世界をどう予測し、その予測を訓練・評価・行動にどう接続するかになる。LLMが言語の汎用インターフェースになったように、世界モデルはロボットや自動運転のための汎用シミュレーション層になりうる。

今後見るべき点は三つある。第一に、第三者評価でNVIDIAのベンチマーク主張がどこまで再現されるか。第二に、Cosmos 3で生成したデータが、実際のロボット方策や自動運転認識モデルをどれだけ改善するか。第三に、オープンモデルとして、研究者や企業がNVIDIA外の環境でも実用的に改変・運用できるかだ。Cosmos 3の本当の評価は、発表時のデモではなく、物理AIの開発ループをどれだけ短く、検証可能に、そして安全にできるかで決まる。

OpenAIの1GWミシガン計画：LLM競争は「モデル」から「電力・建設・人材」へ

今日取り上げたいのは、新しいモデル名ではなく、その下にある巨大な土台の話です。OpenAIは2026年6月1日、ミシガン州Salineで「The Barn」と呼ばれる1GW規模のデータセンターキャンパスの起工を発表しました。パートナーはOracle、Related Digital、Walbridge。OpenAI自身はこれをStargateプログラムの一部と位置づけ、より多くの計算資源が「より良いモデル、より安い提供、より信頼できるAI」につながると説明しています。(openai.com)

今日のポイントは、「またデータセンターが増えた」だけではありません。生成AI・LLMの競争軸が、モデルの賢さだけでなく、計算資源をどれだけ早く、安定して、社会的な合意のもとで立ち上げられるかに移っていることです。LLMはソフトウェアに見えますが、実際にはGPU、ネットワーク、電力、冷却、建設、地域行政、雇用政策の集合体です。モデルの応答速度や利用上限、推論コストの裏側には、こうした物理インフラがあります。

OpenAIの発表で目を引くのは、地域への約束をかなり前面に出している点です。OpenAIは、必要なインフラやエネルギーの費用をプロジェクト側が負担し、地域の電気料金に転嫁しないと説明しています。また、冷却には閉ループ方式を採用し、使用水量は通常のオフィスビル程度だとしています。さらに、2,500以上の組合建設職、450の常設 onsite 雇用、リース期間を通じた10億ドル規模の税収見込み、Saline Recreation Centerへの1,000万ドル拠出なども掲げています。(openai.com)

もう一つ重要なのが、教育との接続です。OpenAIは、2026〜2027年度に18歳以上のミシガン州の大学生、コミュニティカレッジ生、職業訓練校生など40万人超を対象に、最大4,500万ドル分のCodexクレジットを提供するとしています。既存の学生向けCodexクレジット制度では、認証済みの米国・カナダの大学生に100ドル相当、2,500クレジットを付与し、Codex利用に使えると説明されています。(openai.com)

ここで面白いのは、OpenAIが「計算資源の建設」と「AI人材の裾野拡大」を同じ発表の中に置いていることです。これは単なるCSRではなく、AIインフラを受け入れる地域に対して、雇用・税収・教育機会という形で便益を返す設計だと読めます。言い換えると、AI企業はこれから「モデルを公開する会社」ではなく、「地域に巨大設備を建てる産業企業」として見られるようになります。

一方で、慎重に見るべき点もあります。Walbridgeはこの計画を、Related DigitalがOracleとOpenAI向けに開発する160億ドル規模のギガワット級キャンパスだと説明しています。250エーカーの敷地、3棟合計165万平方フィート超のデータホール、閉ループ冷却、DTE Energyによる電力供給、2,500以上の建設雇用などが示されています。こうした数字は大きいですが、実際の電力負荷、送電網への影響、長期的な機器更新、地域住民の納得は、発表文だけでは評価しきれません。(walbridge.com)

地元報道では、Sam Altmanがこの計画をAIの将来への「huge bet」と表現した一方、専門家や住民側からは、雇用創出見込み、税優遇、訴訟の経緯、環境・財政影響への懸念も出ています。さらにOracle側は、建物とは別に、GPUやネットワーク機器など内部設備に300億〜400億ドルが必要になる可能性にも言及したと報じられています。つまり本当の投資規模は、建屋の価格だけでは測れません。(planetdetroit.org)

技術的に見ると、今回の発表は「スケーリング則」の社会実装版です。これまでLLMのスケールは、論文やベンチマーク上ではパラメータ数、トークン数、推論時間として語られてきました。しかし、商用AIが日常的に使われる段階では、スケールはより物理的になります。電力契約を確保できるか。冷却水をどう抑えるか。建設労働力を集められるか。地域が許容するか。これらが、モデル性能と同じくらい重要な競争条件になります。

今後見るべきは、単に「何GWか」ではありません。実際にいつ稼働するのか、どの程度の計算資源がOpenAI向けに使われるのか、電力・水・税制・雇用の約束が検証可能な形で公開されるのか。そして、CodexクレジットやAIリテラシー教育が一過性の配布ではなく、地域の技能形成につながるのか。

今日の結論です。生成AIの次のフロンティアは、モデルカードの中だけにはありません。LLMの能力は、データセンターの床、送電線、冷却装置、建設現場、そしてその地域に住む人々との合意の上に積み上がっていきます。OpenAIのミシガン発表は、AIが「クラウド上の魔法」から「地域に建つ産業インフラ」へ変わりつつあることを示す、かなり象徴的な出来事です。

JetBrains Mellum2公開：AIコーディングは「巨大モデル一枚岩」から「速い専門部品の組み合わせ」へ

過去24時間の生成AI・LLM関連で注目したいのは、JetBrainsがMellum2をオープンソース化した発表です。Mellum2は、総パラメータ12B、トークンごとに有効化されるのは2.5BのMixture-of-Expertsモデルで、Apache 2.0ライセンスで公開されています。JetBrainsは用途として、コード生成だけでなく、ルーティング、Q&A、RAG、サブエージェント、プライベートなソフトウェア開発環境での利用を挙げています。(blog.jetbrains.com)

今回のポイントは、「また新しいコードLLMが出た」というだけではありません。JetBrains自身が強調しているのは、最大性能よりも、レイテンシ、スループット、コストです。つまりMellum2は、すべてを担う汎用フロンティアモデルというより、AI開発ワークフローの中で高頻度に呼ばれる“速い部品”として設計されています。プロンプトを分類する、検索結果を要約する、ツール呼び出しを補助する、エージェントの途中工程を処理する。そうした作業に毎回最大級モデルを使うのは、品質面では魅力的でも、運用コストと待ち時間の面で重くなります。Mellum2の発表は、この現実的な隙間を狙っています。(blog.jetbrains.com)

技術的には、64 expertのうち8 expertを有効化するMoE構成、Grouped-Query Attention、4 KV heads、4層中3層でSliding Window Attentionを使う設計、さらにMulti-Token Prediction headを事前学習の補助目的と投機的デコード用の内蔵ドラフトモデルとして兼ねる点が示されています。事前学習は約10.6兆トークン規模で、Webデータからコード・数学寄りへ段階的に比重を移す三段階カリキュラムを採用したとされています。128Kコンテキストへの拡張後、SFTとRLVRを経て、直接答えるInstruct系と、明示的な推論過程を出すThinking系が公開されました。(arxiv.org)

公開形態も重要です。Hugging Face上では、Base Pretrain、Base、Instruct SFT、Thinking SFT、Instruct、Thinkingという複数のチェックポイントが提示されています。完成品だけでなく中間段階も出しているため、研究者や企業が「SFTだけの状態」「RL後の状態」「Thinking型と非Thinking型」の違いを比較しやすい。これは単なるモデル配布ではなく、ポストトレーニング工程を観察可能にする公開でもあります。(huggingface.co)

性能の見方は慎重であるべきです。Thinking版の自己報告ベンチマークでは、LiveCodeBench v6が69.9、BFCL v3が69.4、BFCL v4が45.6、AIME平均が58.4、MMLU-Reduxが86.2とされています。一方で、AIMEやGPQA Diamond、IFEvalなどではQwen3.5 9Bなどに劣る項目もあります。つまり「小さくて最強」という話ではありません。むしろ、コード・ツール利用・推論を広く扱えるオープンウェイトの実用部品として、どのタスクで大きなモデルの代替になり、どのタスクではならないかを見極める対象です。なお、モデルカード上の数値はJetBrains自己報告を含むため、独立評価は必要です。(huggingface.co)

面白いのは、Mellum2が「コード補完モデル」の延長線上にありながら、補完だけを目指していないことです。初代Mellumはコード補完に焦点を当てた4B denseモデルでしたが、Mellum2はコード編集、デバッグ、ツール利用、関数呼び出し、エージェント型コーディング、対話的プログラミング支援まで対象を広げています。これは、AIコーディング支援が「次の1行を当てる」段階から、「開発環境内の複数工程を分担する」段階へ移っていることを示しています。(arxiv.org)

実務上の意味は三つあります。

第一に、プライベート実行の選択肢が増えること。Apache 2.0で公開され、vLLMやSGLangでの利用例も示されているため、企業はコードや社内文書を外部APIに出さずに、局所的なAI処理を組み込む余地を持ちます。もちろん、実際の安全性は運用設計、ログ管理、アクセス制御、モデル更新方針に依存します。モデルがローカルで動くことは、ただちに安全を意味しません。(huggingface.co)

第二に、エージェントのコスト構造が変わります。複雑な開発エージェントは、1回の依頼の中で、検索、要約、計画、コード生成、テスト解釈、修正案作成を何度も行います。すべてを大型モデルで処理すると、見た目以上に推論コストが膨らむ。Mellum2のような“focal model”は、各工程に適切なモデルを割り当てるルーティング設計を後押しします。今後のAI開発基盤では、「どのモデルが賢いか」だけでなく、「どの工程にどのモデルを使うか」が重要になります。(blog.jetbrains.com)

第三に、IDEベンダーがモデルを持つ意味です。JetBrainsは開発者の作業環境を長年提供してきた企業であり、モデル単体ではなく、IDE、静的解析、コード検索、テスト、ビルド、エージェント連携の中にAIを置けます。Mellum2はその部品になり得ます。ただし、ここで過大評価は禁物です。良いモデルを持つことと、良い開発体験に統合することは別問題です。低遅延でも、誤った編集、過剰な提案、セキュリティ上危ういコードを出すなら、現場の信頼は得られません。

今回の発表から見える大きな流れは、AIコーディングの競争軸が二層化していることです。一方には、難問解決や大規模リファクタリングを担う強力なフロンティアモデルがある。もう一方には、日常的な補助作業を高速・安価・ローカルに処理する専門モデルがある。開発者が実際に使うAI環境は、おそらく後者を大量に組み合わせ、必要な場面だけ前者を呼ぶ形に近づいていきます。

Mellum2の価値は、単独で最先端モデルを倒すことではありません。むしろ、「AI開発環境は大きな頭脳ひとつではなく、速い小さな頭脳の連携で作られる」という設計思想を、Apache 2.0の実モデルとして提示した点にあります。ここから先の焦点は、ベンチマーク上の点数だけでなく、実際のIDE内ワークフローで、どれだけ安全に、速く、低コストに、開発者の判断を邪魔せず働けるかです。

出典: JetBrains AI Blog、arXiv Technical Report、Hugging Face model cards。(blog.jetbrains.com)

LongTraceRL：長文推論の弱点は「窓の長さ」ではなく「紛らわしい証拠」にある

2026年6月1日のarXiv cs.CL新着で、清華大学KEGの「LongTraceRL: Learning Long-Context Reasoning from Search Agent Trajectories with Rubric Rewards」が掲載された。長文コンテキストを扱うLLMの強化学習手法で、論点は単に128Kトークンを読ませることではない。モデルが「正解に近いが不要な文書」に囲まれたとき、必要な証拠をどう見つけ、どうつなぐかを訓練する点にある。(arxiv.org)

LongTraceRLの新しさは二つある。第一に、訓練データのノイズ設計だ。著者らはWikipedia由来の知識グラフをランダムウォークしてマルチホップ質問を作り、さらに検索エージェントの軌跡から「紛らわしい文書」を二段階で集める。Tier-1はエージェントが実際に開いたが最終回答では引用しなかった文書、Tier-2は検索結果には出たが開かれなかった文書である。ランダムに無関係文書を混ぜるのではなく、検索過程で本当に引っかかりやすい文書を混ぜるところが重要だ。(github.com)

第二に、報酬を最終回答だけにしない。従来のRLVRは「答えが合っているか」を報酬にしやすいが、それだけでは途中の推論経路を区別しにくい。LongTraceRLは、推論チェーン上の正解エンティティをrubricとして持たせ、最終答えが正しい応答に対して、その途中で必要なエンティティを拾えているかを加点する。GitHub上の説明では、このpositive-only戦略により、正解していない応答が表面的なエンティティ列挙で報酬を稼ぐリスクを抑える意図が示されている。(github.com)

公開されているデータセットは2,815件で、各サンプルは約128Kトークンのコンテキスト、マルチホップ質問、正解、プロセス報酬用のrubricエンティティを含む。モデルもLongTraceRL-4B、8B、30BがHugging Face上で確認でき、ベースはそれぞれQwen3-4B-Thinking-2507、DeepSeek-R1-0528-Qwen3-8B、Qwen3-30B-A3B-Thinking-2507とされている。(huggingface.co)

結果は、過度に大きく読むべきではないが示唆的だ。公開画像の表では、DeepSeek-R1-0528-Qwen3-8B系で平均42.7から43.8、Qwen3-4B-Thinking-2507系で53.3から59.0、Qwen3-30B-A3B-Thinking-2507系で60.5から63.7へ改善している。とくに4BモデルではLongRLVRの56.5も上回っており、小型モデルほど「紛らわしい文脈で証拠を追う訓練」の効果が見えやすい可能性がある。(github.com)

ただし、実用面では計算資源の重さも見逃せない。READMEでは、フル128Kコンテキスト訓練に4ノード×8 GPU、例としてH800 80GBを挙げている。訓練設定も128K prompt + 32K response、GRPO group size 8、global batch size 128、200 iterations、学習率2e-6、rubric reward weight 0.3と具体的に示されている。これは「誰でもすぐ回せる軽量レシピ」というより、長文RLの研究用足場に近い。(github.com)

この論文が面白いのは、長文対応を「コンテキスト長を伸ばす競争」から少しずらしている点だ。長い入力を入れられるだけなら、モデルは重要でない文書も大量に抱え込む。実際の調査エージェントやリサーチ支援では、問題は「読める量」ではなく「もっともらしいノイズの中で、どの証拠を採用し、どの証拠を捨てるか」になる。LongTraceRLは、その捨てる判断まで訓練データに埋め込もうとしている。

一方で、限界も明確だ。データ構築はWikipedia/KILTスナップショットとQA形式に依存しており、企業内文書、法律、医療、動的Web検索にそのまま移るとは限らない。また、rubricエンティティを事前に持てるタスクでは機能しやすいが、未知の探索課題や創造的な分析では、そもそも「正しい中間エンティティ」を誰がどう定義するかが問題になる。最終回答が正しい場合だけ中間報酬を使う設計も堅実だが、正解に至らない試行錯誤から何を学ばせるかは残る課題だ。

それでも、方向性は重要だと思う。長文LLMの次の競争軸は、100万トークンを入れられるかだけではない。紛らわしい文脈をどう作るか、途中の証拠選択をどう評価するか、そして正解だけでなく「なぜその証拠を採ったか」をどう訓練信号にするか。LongTraceRLは、その問いに対するかなり具体的な実装例になっている。

LLMエージェントは「データ掃除」をどこまで任せられるか：TR-Agent論文の要点

2026年5月31日に、SAGE Journals / Frontiers in Artificial Intelligence and Applicationsで「A Task-Driven Interpretable Data Cleaning Framework Based on LLM」がオンライン公開された。提案されているのは、TR-AgentというLLMベースの表データクリーニング・フレームワークだ。新しい大規模モデルの発表ではないが、生成AIの実務利用という観点ではかなり重要なテーマを扱っている。多くの企業でAI導入の失敗要因は「モデルが賢くないこと」ではなく、入力されるデータが汚いことだからだ。(journals.sagepub.com)

何が提案されたのか

TR-Agentの狙いは、単に欠損値や外れ値を直すことではない。下流タスク、つまり最終的にそのデータで何をしたいのかを見ながら、データを修正する点に特徴がある。

論文では、TR-Agentを4つの工程で説明している。

1. 表データから構造・統計・特徴重要度などの知識を抽出する
   
2. LLMがエラー候補を検出する
   
3. LLMが文脈とタスク目的に基づいて修復案を作る
   
4. 変更理由・修正内容・リスクを含む構造化レポートを生成する
   

さらに、LLMにはIPythonのような実行環境と、下流モデルの性能評価パイプラインが与えられる。つまり、LLMは「この値はおかしい」と文章で言うだけでなく、実際に表を操作し、修正後のデータでモデル性能がどう変わるかを見ながら戦略を更新する。(journals.sagepub.com)

重要なのは「きれいさ」ではなく「使えること」

従来のデータクリーニングは、ルール、統計、機械学習モデルに基づいて「誤りらしい値」を直すものが多かった。これは重要だが、実務では悩ましい問題がある。すべてのエラーを直すことが、必ずしも下流タスクの性能改善につながるとは限らない。

たとえば、分類モデルにほとんど影響しない列を丁寧に修正しても、コストに見合わない。一方で、少数の重要特徴量に含まれる小さなノイズが予測性能を大きく壊すこともある。TR-Agentはこの問題に対して、「下流タスクのF1スコア」をフィードバックとして使う。これは、データクリーニングを前処理ではなく、モデル開発ループの一部として扱う発想だ。(journals.sagepub.com)

実験結果

論文ではTitanic、Breast Cancer、Meatの3つの表形式データセットで評価している。使用モデルはGemini-2.0-flashで、IPython実行環境、20万トークンの予算、6回反復で実験したとされている。比較対象はHoloClean、Raha+Baran、ゼロショット、few-shotのLLMクリーニングだ。(journals.sagepub.com)

結果として、TR-Agentは複数データセットでベースラインを上回った。表中のF1スコアでは、Titanicで0.7706、Breast Cancerで0.9650、Meatで0.9055を記録している。論文は、TitanicでHoloCleanより約8ポイント、Breast Cancerで約7ポイント改善したと説明している。(journals.sagepub.com)

ただし、この数値は慎重に読む必要がある。データセット数は3つで、規模も限定的だ。Titanicは891行、Breast Cancerは286行、Meatは10080行であり、企業の大規模・高頻度更新・複雑スキーマのデータ基盤をそのまま代表しているわけではない。結果は有望だが、「LLMでデータ品質問題が解決した」と読むのは早い。

何が新しいのか

TR-Agentの新しさは、LLMを「万能な修正器」として使っていない点にある。むしろ、LLMを以下のような複合的な役割に分解している。

• 表の意味を読む分析者
• エラー候補を探す検査者
• 修復案を作る作業者
• Pythonで実行するオペレーター
• 下流性能を見て方針を変える改善担当
• 変更理由を説明するレポーター

この分解が重要だ。LLMに「このデータをきれいにして」と投げるだけでは、何を直したのか、なぜ直したのか、モデル性能にどう影響したのかが見えない。TR-Agentは、ログ、レポート、評価フィードバックを通じて、LLMによるデータ修正を監査可能な処理に近づけようとしている。(journals.sagepub.com)

実務への含意

この研究が示している方向性は、AIエージェントの適用先としてかなり現実的だ。多くの組織では、完全自律の意思決定エージェントよりも先に、データ準備、レポート生成、検査、修正候補の提示といった「面倒だが重要な作業」がAI化される。

特に表データのクリーニングは、LLM向きの側面とLLMに任せにくい側面が混在している。

LLM向きなのは、列名、値の意味、業務文脈、例外パターンを読む部分。任せにくいのは、誤修正の責任、再現性、監査、規制対応、そして高リスク領域での最終判断だ。

その意味で、TR-Agentの「レポート生成」機能は飾りではない。LLMが修正したデータを人間や組織が受け入れるには、変更履歴と根拠が必要になる。AIエージェントの実用性は、作業を自動化できるかだけでなく、後から説明できるかで決まる。

限界と今後

論文自身も、LLMによるデータクリーニングにはプロンプト依存性とハルシネーションの問題が残ると述べている。対策として、信頼度スコア、ルールベース検証、信頼できるソースとの照合、人間レビューを挙げているが、これらは問題を消すものではなく、運用上のリスク低減策だ。(journals.sagepub.com)

今後重要になるのは、少なくとも次の3点だと思う。

第一に、より大規模で複雑な実データでの評価。
第二に、LLMが行った修正の再現性と差分管理。
第三に、性能改善とデータ真実性が衝突したときの扱い。

特に三点目は難しい。下流モデルのF1スコアが上がったからといって、その修正が現実のデータとして正しいとは限らない。AIが「予測しやすいデータ」に寄せてしまう危険もある。データクリーニングは、モデル性能の最適化であると同時に、記録の忠実性を守る作業でもある。

まとめ

TR-Agent論文は、LLMエージェントの実用化が派手な自律行動だけで進むわけではないことを示している。むしろ、表データを読み、エラーを疑い、修正し、評価し、説明するという地味な工程にこそ、LLMの価値が出る可能性がある。

ただし、ここで必要なのは「AIが自動でデータを掃除してくれる」という期待ではない。必要なのは、AIが行った修正を検証できる設計、戻せる設計、説明できる設計だ。TR-Agentは、その方向に向けた小さく実務的な一歩として読むのがよい。

出典：
SAGE Journals “A Task-Driven Interpretable Data Cleaning Framework Based on LLM”
https://doi.org/10.3233/FAIA251753

Codexの本当の更新点：AIコーディングは「追加ツール」から「ChatGPTプランの一部」へ

CodexがFree、Go、Plus、Pro、Business、Edu、Enterpriseの各ChatGPTプランに含まれる、と明記されました。Codexは「コードを書き、レビューし、出荷を助けるAIエージェント」と説明され、利用者はCodex app、CLI、IDE拡張、WebからChatGPTアカウントで接続できる構成になっています。(help.openai.com)

ここで面白いのは、「AIコーディング機能が使えるようになった」という単純な話ではありません。OpenAIは、Codexの利用を単独の開発者向けAPIではなく、ChatGPTのプラン体系の中に組み込んでいます。つまり、コード生成エージェントが、画像生成やファイル解析のような一機能ではなく、ChatGPTの作業面の一部として配布され始めたということです。

ただし、含まれることと、無制限に使えることは違います。OpenAIの説明では、Codexの使用量は「agentic usage limit」にカウントされ、Codex、ChatGPT for Excel、Workspace Agentsの利用が同じ枠に入ります。小さなスクリプトや単純な関数なら消費は小さい一方、大きなコードベース、長時間セッション、多くの文脈を保持する作業では、1メッセージあたりの消費が大きくなると説明されています。(help.openai.com)

ここ、実務ではかなり大事です。従来の「LLM利用量」は、だいたいトークン数やAPI料金で見ればよかった。ところがエージェントになると、同じ1回の依頼でも、裏側で読むファイル数、実行するテスト、保持するコンテキスト、リトライ回数が変わります。これからの利用管理は「何回質問したか」ではなく、「どれだけ長い作業を任せたか」に近づいていきます。

もう一つの注目点は、管理機能です。Business、Enterprise、Eduでは、プラグインの有効化、RBACによるアクセス制御、Compliance APIでのCodex利用ログ確認などが説明されています。さらに、Codex LocalとCodex Cloud、Remote Controlの権限が分かれており、組織は「ローカルで使わせる」「クラウドに委任させる」「遠隔操作を許可する」を別々に設計する必要があります。(help.openai.com)

これは、AIコーディングが個人の生産性ツールから、企業の権限設計対象へ移ったということでもあります。ソースコード、社内リポジトリ、端末、ブラウザ、接続済みアプリに触れるエージェントは、便利なだけでなく、監査・権限・データ利用ポリシーの中心に置かれるべき存在です。

データ面でも注意が必要です。OpenAIは、ChatGPT側のトレーニングデータ制御がCodexにも適用され、Computer Useのスクリーンショットも対象に含まれると説明しています。一方で、Business、Enterprise、Eduでは、デフォルトで入力・出力をモデル改善に使わないとされています。個人利用と法人利用で、同じCodexでもデータの扱いが異なる点は見落とせません。(help.openai.com)

つまり今回の更新を一言で言えば、「Codexが広く使えるようになった」ではなく、「コーディングエージェントがChatGPTの標準配布・課金・統制の枠に入った」です。モデル性能競争の次に来るのは、誰がどの作業面で、どの権限で、どの利用枠を消費しながらエージェントを走らせるのか。その設計競争が、いよいよ見える場所に出てきました。

Grok Imagine Video 1.5 Preview：生成動画APIの競争は「画質」から「秒単価と運用性」へ

2026年5月30日付の固定エイリアスとして、xAIの公式ドキュメントに grok-imagine-video-1.5-2026-05-30 が確認できる。名称は grok-imagine-video-1.5-preview。入力はテキストと画像、出力は動画で、API価格は480pが1秒あたり0.08ドル、720pが1秒あたり0.14ドル。提供リージョンは少なくとも us-east-1 と eu-west-1 とされている。xAIのモデルページでは、日付付きエイリアスは特定リリースを直接指し、将来更新されないワークフロー向けだと説明されているため、これは単なる表示名ではなく、再現性を重視する開発者向けのバージョン固定点として読むのが自然だ。(docs.x.ai)

今回の更新で面白いのは、「すごい動画が出る」という宣伝よりも、生成動画がかなり普通のAPI商品として整理されてきたことだ。xAIのImagine APIは、画像生成、画像編集、テキストまたは静止画からの動画生成、動画編集などを同じ開発者向け枠組みにまとめている。公式ドキュメントでは、画像生成は枚数単位、動画生成は秒数と解像度に応じた課金として説明されている。つまり、動画生成はもはや単発のデモではなく、「何秒を何本生成するといくらか」という計算可能な部品になりつつある。(docs.x.ai)

この変化は、クリエイター向けツールだけでなく、アプリ開発にも効いてくる。たとえばECの商品紹介、ゲーム内の短い演出、教育コンテンツの説明カット、広告案のラフ生成、SNS運用のABテストなどでは、最終品質よりも「短時間に何案回せるか」が価値になる場面が多い。動画モデルが秒課金でAPI化されると、開発者はテキスト生成APIと同じように、生成回数、解像度、尺、失敗率、再生成コストを設計変数として扱える。

ただし、ここで過大評価は避けたい。preview という名前の通り、現時点でこのモデルについて公開確認できる情報は、主に入出力、価格、リージョン、エイリアスといった運用仕様だ。画質、時間的一貫性、物理挙動、文字描画、人物同一性、指示追従、著作権・肖像・安全性まわりの実効性能については、xAIのこのモデルページだけでは十分に判断できない。生成動画モデルは、数秒の成功例だけを見ると進歩が大きく見えるが、業務利用では「10本中何本が使えるか」「同じキャラクターを保てるか」「編集指示で壊れないか」の方が重要になる。

もう一つの注目点は、Grok本体との統合だ。xAIはGrokを、チャット、検索、推論、画像・動画生成、コード生成、音声会話を一つの体験にまとめるアシスタントとして位置づけている。Grokの製品ページでも、Imagineはテキストプロンプトや参照写真から画像・動画を生成し、追加プロンプトで編集・反復できる機能として説明されている。これは「動画生成モデル単体」ではなく、会話、検索、資料理解、コード生成と接続されたマルチモーダル作業面の一部として提供する戦略だ。(x.ai)

この方向では、モデルの競争軸が少し変わる。従来は、動画生成といえば画質、リアリズム、尺、動きの自然さが中心だった。もちろん今後も重要だが、APIとして使う開発者にとっては別の問いが増える。

• 生成完了までの待ち時間は安定しているか
• 失敗やポリシー拒否の扱いをアプリ側で制御しやすいか
• URLや生成物の保持期間は運用に合うか
• 同じプロンプトでどれくらい再現性があるか
• 解像度を上げたとき、費用対効果が見合うか
• バッチ生成、編集、参照画像、動画延長を一つのワークフローに組めるか

xAIのImagine APIドキュメントには、動画リクエストは非同期で開始し、リクエストIDを使って完了をポーリングする流れが示されている。また、生成メディアはコンテンツポリシーレビューの対象で、トレーニングには使われないとも説明されている。ここは企業利用ではかなり重要だ。生成AIの導入判断は、モデルの創造性だけでは決まらない。ログ、保存、審査、データ利用、リージョン、課金、失敗処理まで含めて、ようやくプロダクトに組み込める。(docs.x.ai)

今後の見どころは、動画生成モデルが「作品を作るAI」から「アプリ内で呼ばれるメディア関数」へ進むかどうかだと思う。テキスト生成がチャットボットからRAG、エージェント、コード補助、社内自動化へ広がったように、動画生成も単独サービスではなく、資料作成、広告運用、教育、ゲーム、EC、サポート、シミュレーションの中に埋め込まれていく可能性がある。

そのとき重要になるのは、最高品質の1本ではなく、制御可能な100本だ。Grok Imagine Video 1.5 Previewの今回の確認ポイントは、まさにそこにある。派手なベンチマークよりも、日付付きエイリアス、秒単価、リージョン、非同期API、解像度別価格という地味な情報の方が、生成動画の実用化段階をよく示している。生成AIの進歩は、モデルが賢くなることだけではない。費用と失敗と再現性を見積もれる形で、開発者の道具箱に入っていくことでもある。