Claude Codeのソース漏えい、OpenAIは動画生成を撤退、Geminiは音楽生成を追加、LLMは推論時に学習する

The Batch / 2026/4/4

💬 オピニオンSignals & Early TrendsIdeas & Deep AnalysisTools & Practical Usage

共有:

要点

この記事では、音声ベースのAIインターフェースが急速に進化しており、デスクトップおよびWebアプリケーション全体に広く浸透していくと論じています。これにより、キーボードやマウスに代わる新しいインタラクションのパラダイムが可能になるでしょう。
より信頼性が高く、低遅延な音声UIが実現されれば、マウスやタッチがこれまで新しいアプリ体験を生み出したのと同様に、従来とは異なるアプリのカテゴリーを解き放つ可能性があると強調しています。
「Meow Math」の例を用い、話しかけた質問と口頭での回答を追加することで摩擦が減り、ユーザー体験が根本的に変わり得ること、特に子どもにとってその効果が大きいことを示しています。
音声による対話は、多くのユーザーにとって読んだり書いたりするよりも簡単だと位置づけ、その背景として、人がコンピュータに「入力」するのではなく「話しかける」未来に向けた、より広い「築く価値のある未来」につなげています。
Vocal Bridge（AI Fundのポートフォリオ企業）と、そのCEOが開発者向けのツールに注力している点に触れています。これにより、開発者が音声UI機能を実装しやすくなるようにしている、という文脈です。

読み込み中：Elevenlabs Text to Speech AudioNative Player...

親愛なる皆さん、

話しかけられる音声ベースのAIは急速に進歩していますが、それでも多くの人は、音声UI（ユーザーインターフェース）がどれほど広く普及していくのかを、まだ十分に実感できていません。今日私たちは、キーボードとマウスでほとんどのデスクトップおよびWebアプリケーションを操作しています。将来的には、こうした多くのアプリケーションに対して、さらに“話しかけて”操作できるようになることを期待しています。とりわけ私は、CEOのAshwyn Sharmaが先導し、この実現を可能にする開発者向けツールを提供している Vocal Bridge （AI Fundのポートフォリオ企業）の取り組みに強くわくわくしています。

重要なUIの変化が起きるたびに、多くの新しいアプリケーションが生まれると同時に、既存のものをアップグレードすることも可能になりました。マウスのおかげでポイント＆クリックが実現しました。タッチやスワイプのジェスチャーは、新しいクラスのモバイルアプリを可能にしました。つい最近までは、音声UIは高いエラー率や遅延に悩まされていましたが、より信頼性が高まってくれば、さらに多くの新しいアプリケーションが開かれていくでしょう。

たとえば私は、娘のために簡単な数学クイズのアプリを作っていました。娘はキーボードを使ってこのゲームで遊ぶのを楽しんでいました（猫が大好きなので、正解すると右側にかわいい猫のグラフィックが表示されます！）。そこに音声UIを追加し、クイズをやさしく言葉で出して娘が音声で答えられるようにすると、摩擦が減り、体験の感じ方が変わります。

大多数の人は、書くことや読むことよりも、話すことや聞くことの方がはるかに簡単だと感じています。開発者の多くは文章にとても慣れている（そして The Batch の読者も同様です）ため、書くのがどれほど難しいと感じる人が多いのかを忘れがちです。実際、大人と過ごす時間を持つ子どもは自動的に話すことや聞くことを身につけますが、明確に教えられない限り、読むことや書くことは学びません。過去数十年のSF映画、たとえば スター・トレック のような作品は、人々がコンピュータに対して打ち込むのではなく、話しかけている場面を頻繁に想像します。これは、目指して作っていく価値のある未来のビジョンです！

Meow Mathアプリは掛け算の問題を表示します。機能には回答入力、チェックボタン、音声による対話があります。

私は書いたとおり、遅延（レイテンシ）と知能（インテリジェンス）のトレードオフについて説明しました。根本的な問題は、音声イン／音声アウトのモデルは遅延が低い（それは言語でのやりとりに重要です）一方で、制御が難しく、信頼性／知能が低くなりがちだという点です。対照的に、Speech-to-text → LLM/エージェント型AI → Text-to-speechというパイプラインは高い信頼性を提供しますが、過剰な遅延が生じます。Vocal Bridgeは、ユーザーとリアルタイムで会話するためのフォアグラウンド（前景）エージェントを使う独自のアーキテクチャを実装しました。これにより低遅延を保証します。そして、複雑なエージェント型ワークフローを管理し、推論し、ガードレールを適用し、ツールを呼び出し、さらに高品質な回答やアクションを生み出すために必要なあらゆることを行うためのバックグラウンド（背景）エージェントを用意することで、高い知能を保証するのです。

私は、音声UIが古いインターフェースを完全に置き換えるとは期待していません。むしろ、マウスがキーボードを補完するように、音声UIはそれらを補完する存在になるでしょう。たとえば、他の人のすぐ近くで作業しているといった状況では、話すよりも入力（タイピング）を好むユーザーもいます。しかし、音声UIの可能性は、現在主流となっているコールセンターの自動化や、文字入力の代替を提供するといった用途をはるかに超えています。私の数学クイズアプリでは、アプリが話すだけでなく、音声（またはタイピング）による入力に応じて、画面に表示される問題やアニメーションも更新できます。このマルチモーダルな“視覚＋音声”による対話は、多くの音声AI企業が注力してきた“音声だけ”のやり取りよりも、はるかに豊かなユーザー体験を生み出します。うまく動かすための鍵の1つが、UIから双方向に入力を受け取り、さらにUIを更新するためにツールを呼び出せるバックグラウンドエージェントのループです。

音声UIを作るのは、たぶんあなたが思っているより簡単です。私の数学クイズアプリの、初期の音声なしバージョンから始めて、Claude Codeを使ったところ、音声機能を追加するのに1時間もかかりませんでした。最近DeepLearning.AIとAI Fundが主催したハッカソンでは、開発者たちがVocal Bridgeを使って音声対応アプリを作り、たとえばがん患者のための臨床試験マッチャー、会話型のポートフォリオアドバイザー、既存のテキストベースエージェント向けのインタラクティブな音声レイヤーなどが生まれました。この新しいUIが可能にする創造性に、私はとても喜びました。

音声UIは、AIアプリケーションにとって重要な構成要素になるでしょう。世界中の開発者のうち、音声アプリを作ったことがあるのはほんのわずかな割合です。つまり、ここは“作る”ための肥沃な領域です。アプリに音声を追加してみたいなら、無料でVocal Bridgeを試してみてくださいこちら。

作り続けましょう！

Andrew

DEEPLEARNING.AIからのメッセージ

AI Dev 26のアジェンダを公開しました！Andrew Ngがホストする2日間にわたる講演、ワークショップ、デモを通じて、Google DeepMind、Oracle、AMDなどのチームの話を聞いてください。予定されている内容を確認して、スケジュールの計画を始めましょう

ニュース

赤い記号のある黒い箱が開き、中で光っている様子が見え、セキュリティ侵害を象徴している。

Claude Codeの中身

新たに分かったこと: Claude CodeのNode.jsパッケージの最近のバージョンに、偶然にも、コードにアクセスできることを通じてそのコマンドライン・インターフェースの背後にあるソースコードを「明らかにする」鍵が含まれていました。ブロックチェーンのスタートアップSolayer LabsのインターンであるChao fan Shou（チャオファン・ショウ）がコードを解き明かし、公開しました。エンジニアはその秘密を急速に解読しました。

何が起きたか: 通常、ソフトウェア企業がクローズドソースのコードを公開するとき、バンドラツールによってソースファイルがスクランブル（かき混ぜ）されます。ところが、Anthropicが3月30日にClaude Codeのnpmレジストリへバージョン2.1.88を公開した際、ファイルをデコードするための「翻訳キー」として機能するソースマップファイルが含まれていました。

Shouはソースマップを発見し、ファイルをデコードし、Xソーシャルメディア上で公開しました。これにより、1,900ファイルにまたがる51万2,000行以上のコードが露出しました。
Anthropicはすぐに、そのパッケージをnpmレジストリとGitHubから削除しました。しかし、すでに4万回以上フォークされていました。
Anthropicの広報担当者はリークを確認し、それを「セキュリティ侵害ではなく、人為的なミスによって引き起こされたリリースのパッケージング問題」と呼び、ユーザーや顧客データは一切公開されていないと述べました。

Claude Codeはどう動くのか: ソースコードを研究したエンジニアは、Claude Codeはチャットボットのラッパーというより、小型で専用のオペレーティングシステムのように作られていると述べています。

40種類以上のツール（ファイルを読み取る、bashコマンドを実行する、ウェブから情報を取得する等）それぞれに独自のモジュールと権限ゲートがあり、これにより、それらは言語モデルとユーザーのコンピュータの両方から切り離されます。バックグラウンドのプロセスがメモリを管理し、権限ゲートによって、定義されたリソースを超えてエージェントが任意のコードを実行することを防ぎます。
Claude Codeは、サポートエージェントとして振る舞うサブエージェントの「群れ」を生成します。各サブエージェントには独自のツールセットとリソースがあります。コントローラ・エージェントがそれらの権限とサブタスクを委任します。各群れのチームには共通のメモリがあり、行動の調整に役立てます。
Claude Codeのメモリには 3つの階層があります。（i）常にロードされるメモリインデックス「MEMORY.MD」がありつつ、中身は（ii）Markdownメモリファイルへのポインタだけです。Markdownメモリファイルは必要になったときにだけ呼び出されます。さらに（iii）JSONのトランスクリプトファイルがファイル変更を記録します。これらはアクティブなコンテキストには読み込まれませんが、関連するテキスト行を検索することはできます。この3階層構造により、メモリの肥大化を防ぎ、コンテキストウィンドウから無関係または不完全な情報を排除でき、エージェントのメモリとファイルの実際の状態との間に生じるすべての競合を解決します。
Claude Codeは、メモリを圧縮し、会話をコンテキスト上限の範囲内に保つために、3段階の戦略を使います。（i）まず、キャッシュされたツール出力をローカルで切り詰めます。（ii）次に、会話がコンテキスト上限に近づいたとき、直近のセッションの構造化された20,000トークンの要約を生成します。（iii）最後に、会話全体を圧縮し、その上で、最近アクセスされたファイル（1ファイルあたり最大5,000トークン）、アクティブな計画、関連するスキルを追加します。

将来の機能は?: ソースマップは、Claudeに向けたAnthropicの可能性のある計画もいくつか明らかにしています。例えば、未公開の複数の機能がフラグの裏に隠されており、公開ビルドではそれらが「false」にコンパイルされているようです。これは、それらが現在開発途中であり、将来のリリースに含まれるかもしれないという兆候です。

Kairos（ギリシャ語で「時にふさわしい」を意味する）と呼ばれるサブシステムは、常時稼働のバックグラウンドエージェントとして動作するはずです。そのロジックシステムであるautoDreamは、重複したメモリを統合し、矛盾を取り除き、推測を解消し、その他にもメモリを刈り込むことで、保存されたデータが行動により適したものになるようにします。
他の隠れた機能としては、音声インターフェース、クラウドにリソース集約型のタスクを送るサブエージェントのUltraplan、そしてパーソナ（分身のような役割）としてBuddyがあり、あなたの作業にコメントすることで、おそらくエンゲージメントを高める狙いがあるようです。
Claude Codeには、以前は明かされていなかった「アンダーカバーモード」があり、エージェントが稼働していたことを示す署名やその他の痕跡を残さずに、ファイルを公開gitリポジトリへコミットできます。この機能によって、Anthropicは、そうした活動を意図せず開示することなく、高度なモデルのテストや、未公表のパートナーとの協業が可能になるかもしれません。
ファイルには、CapybaraというコードネームのClaude 4.6バリアントに関する参照や、Numbatという未リリースのモデルへの言及が含まれています。Capybaraバージョン8は、約30％の確率で誤った、または誇張した主張を行うとのことです。これは、より前のバージョンの16.7％を大きく上回っており、最新バージョンのモデルが、慎重に抑えるよりも早合点して結論に飛びつくように調整されていることを示唆しています。

重要な理由: 今回のリークは、利用可能な最も高度で人気のあるエージェント型システムのひとつについて、裏側を垣間見せてくれます。Claude Codeがどう動くのか、そして近い将来どう動く可能性があるのかが見えてきました。私たちは自分たちのシステムをそれに合わせて見直したり、異なる選択によって製品を差別化したりできるでしょう。

考えています: AIコミュニティは、ソフトウェアエージェントがうっかりコードベースを削除したり、秘密ファイルを公開してしまったりしうる点を懸念しているのは当然です。人間にも同じことは起こり得ます！

薄暗いスタジオ。待機中のカメラと、撤退を示すように点灯した出口ドア。OpenAIが動画生成から退くことを示す。

OpenAIが動画生成を撤退

OpenAIは、動画市場からの急な後退として、動画生成モデルのSoraを shut down（停止）する計画だ。

何が新しいのか： OpenAIは、ChatGPTの著名な後継として同社が別の大衆向けの大ヒットになることを期待していたSoraを中止する。そうすることで、より収益性の高い投資にリソースを振り向けるという。 ウォール・ストリート・ジャーナル が報じた。Webおよびアプリ経由でのモデルへのアクセスは4月26日に終了し、APIは9月24日に閉じる。Soraチームは、ワールドモデルやロボティクスのような長期的なプロジェクトへ振り向けられる。さらに、OpenAIは、ブラウザ、コーディングツールのCodex、ChatGPTアプリを、単一のデスクトップアプリケーションに統合する。 ウォール・ストリート・ジャーナル は別のレポートでそう書いている。

仕組み： Soraは最大25秒の high-definition（高精細）動画を生成し、その現実味と映像品質で称賛を集めた。だが、各クリップを生成するには数分かかり、テキストや画像を作るのとは比べものにならないほど大量の処理能力が必要になる。OpenAIは2024年2月にこのモデルをプレビューした。さらに同社は更新を行い、2025年9月にはiOSアプリ経由で利用可能にした。

Soraの収益の大半は、OpenAIの有料プランのサブスクライバーから入ってくる。Soraは3つの階層で提供されている。アプリのユーザーは（招待制で）1日あたり約5本の無料10秒動画を生成できる。ChatGPT Plusのサブスクライバー（毎月20ドル）は、1280x720ピクセル解像度で、Sora 2を使って15秒のクリップを限られた数だけ生成できる。ChatGPT Proのサブスクライバー（毎月200ドル）は、より進んだSora 2 Proモデルを使って、1920x1080ピクセル解像度で最大25秒の動画を生成できる。
Soraはおおむね1日あたり100万ドルを失っている。日次アクティブユーザー数はモバイルアプリのリリース直後に約1,000,000まで伸びたが、その後すぐに、それを下回るどころか半分未満の水準にまで落ちた。
Xのソーシャルネットワーク上で shutdown（停止）を発表する前に、OpenAIは報道によれば、Soraの処理リソースを、Spud（コードネーム）と呼ばれる新しいAIモデルの運用に振り向けた。このモデルは、さまざまなコーディングおよびエンタープライズ向け製品を支えている。
Soraチームは、ChatGPT内で動画を生成する新しいモデルの訓練を提案していた。これは、おそらくSoraアプリの代替としての位置づけだった。別の動画モデルを訓練するにはコストが高すぎると判断し、同社は動画生成そのものを中止することを選んだ。
本稿執筆時点で、Sora 2 Proは 19位でArtificial Analysisのテキストから動画へのリーダーボードに掲載されている。ByteDance、Kling、xAI、Googleの競合モデルに比べて大きく後れを取っている。

背景： 2025年末、OpenAIはSoraを活用して、ディズニーとの大きな注目を集めるパートナーシップを形成した。OpenAIはディズニーのキャラクターをライセンスし、ディズニーの映像を用いて同社のモデルを訓練する。そしてディズニーはOpenAIに最大10億ドルを投資する計画だった。ディズニーは、Soraの動画を配信サービスDisney+で紹介し、Soraを使って事前制作のビジュアル化、マーケティングキャンペーン、特殊効果の制作を支援するつもりだった。Soraの差し迫った demise（終焉）により、この提携は事実上終了している。

なぜ重要か： OpenAIは動画生成におけるリーダーシップを手放し、他の企業――強力な有力候補のいくつかを含めて――が覇権を争う余地を切り開いた。OpenAIは2年前にSoraを投入した際、別のChatGPTの瞬間が来ることを構想していた。同社は、生成した動画が大衆市場を驚かせ、最大限の文化的インパクトを達成することを望んでいた。だが、計算が合わなかった。動画生成は、ビジネスやコーディング向けのアプリのように多くの有料サブスクライバーを引き付けられず、動画モデルの訓練と運用にかかるコストは負担しきれないほど大きすぎた。

見立て： AIデモ――どれほど見事であっても――が行われるだけでリーダーシップを確立できる時代は、終わりに近づいているのかもしれない。分野は急速に成熟しており、持続可能な価値を生み出すことが最優先事項になりつつある。

GoogleのGeminiアプリでテキスト入力からコミカルなR&Bソングが生成され、音楽生成の能力を示している。

Geminiの音楽生成器

Googleは、GeminiとYouTubeに音楽生成器を追加し、合成ソングを作り出すモデルを数億人規模のユーザーの前に投入した。

新着情報： Lyria 3 は、テキストによる説明や画像を受け取り、複数の言語で楽器、歌声、そして歌詞を含めることができる30秒のオーディオクリップを生成します。Googleは、モデルの出力が著作権を侵害しないようにするための措置を講じています。具体的には、学習データのライセンス提供、著作権のある作品との類似性について出力をフィルタリングすること、そして特定のアーティストの音の“そっくり”な特徴を再現しないことです。

入出力： テキスト入力、オーディオ（30秒）とテキスト（歌詞）出力。Geminiアプリは入力として画像や動画を受け取り、それらをテキストに変換してLyria 3に渡します
アーキテクチャ： 潜在拡散モデル
機能： ユーザーは、インストゥルメンテーション、スタイル、時代、ボーカルスタイル、テンポ、ダイナミクスを指定できます。8言語の歌詞（英語、ドイツ語、スペイン語、フランス語、ヒンディー語、日本語、韓国語、ポルトガル語）。Googleの画像生成器であるNano Bananaが制作したカバーアート。MP3（音声）および、カバーアート付きMP4（動画）形式。透かし（ウォーターマーク）付き出力
性能： Googleが実施した、人手と自動の評価の両方において、Lyria 3は音質とプロンプトへの追従の点で、先代のLyria 2を上回りました
提供状況： Geminiアプリの18歳以上のユーザーは無料（Google AI Plus、Pro、Ultraのサブスク向けは利用上限が高い）。また、動画のサウンドトラック生成ツール経由でYouTube Shortsのユーザーにも無料で提供 Dream Track
非公開： アーキテクチャ、パラメータ数、学習データと手法

仕組み： Googleは、Lyria 3のアーキテクチャと学習について、高レベルの概要のみを開示しました。純粋なノイズの埋め込みからノイズを取り除くことで画像を生成する潜在拡散画像生成器のように、Lyria 3は、与えられた時間区間における音声の表現からノイズを取り除きます。The Batchは以前、Stability.AIが開発した音声拡散プロセスや、Googleの先行するMusicLMによる音楽生成手法についても説明していました。なお、Stability.AIは Stability.AI によって開発されています。

Lyria 3は、詳細度の異なるテキストキャプション付きで注釈された音声データで学習され、品質、重複、安全性についてフィルタリングされました。Googleは、Lyria 3の学習データにライセンスを付与しました。これはLyria 2の後に大きく変わった点で、Lyria 2は伝えられているところによれば、許可なく著作権のある音源の録音を用いて学習されたとのことです。
モデルは3つの段階で学習を受けました。事前学習、教師ありの微調整、そして人間のフィードバックからの強化学習です。
Lyria 3は、合成メディアを識別する隠しウォーターマークである SynthID によって出力に印を付けます。ユーザーはGeminiアプリに音声ファイルをアップロードして、それがGoogleのモデルによって生成されたものかどうかを確認できます。
プロンプトに特定のミュージシャン名が含まれている場合、モデルは、そのアーティストの声やサウンドを複製することなく、似たスタイルの音楽を生成します。Googleは、著作権侵害を避けるために、既存の音楽と出力を照合すると説明しましたが、このアプローチには限界があり、知的財産権を侵害している可能性のある出力についてユーザーに報告してもらいたいとも認めました。

背景： Lyria 3は、音楽業界が、AI音楽生成器の開発者を、著作権侵害の疑いで積極的に提訴している状況で登場します。主要な音楽生成ツールであるSunoとUdioは、自分たちでゼロから音楽を生成することをやめており、Googleは、そうした開発を続けている数少ない開発者の1社になっています。

2024年6月、世界最大級の音楽会社3社であるソニーミュージック、ユニバーサル・ミュージック・グループ（UMG）、ワーナー・ミュージックは、Webベースの音楽生成器を提供するSunoとUdioを、著作権侵害の疑いで提訴しました。そして2025年後半、被告側は和解してユニバーサル・ミュージック・グループと合意し、自社サービスを、ゼロから新しい音楽を生成するのではなく、既存のライセンス済み録音を編集・変換することを重視する方向に変更しました。ソニーの訴訟は現在も継続中です。
Googleは、音楽業界からの圧力への対応の一部として、プロの音楽制作向けのモデルを検討しました。2025年春には、Music AI Sandbox、MusicFX DJ、Lyria RealTimeを導入し、生成した音楽に対する、よりきめ細かな制御を可能にしました。Lyria 3をローンチしてから数日後、Googleはさらに別のプロ向け制作ツールであるProducerAI（旧称Riffusion）を買収しました。

なぜ重要か: 音楽生成は、巨大で強力な既存事業者によって支配されるエンターテインメント業界の中で居場所を見つけつつあります。Lyria 3は、現在のユーザーベースをはるかに上回る 7億5000万人のGeminiユーザーの前に登場しました。これは、Suno（約200万人の有料サブスク）やUdio（約330万人の月間ユーザー）を大きく上回ります。Lyria 3は、SunoやUdioを世界最大級のレコーディング会社の標的にしたのと同じ「オリジナル音楽を生成する」方向性を引き継ぎつつも、著作権保有者を刺激しないために、ライセンスされた音楽での学習といった安全策を追加しています。

私たちが考えること: 音楽ジェネレーターは、驚くほど人間らしい、印象的で多用途な出力を生み出しますが、生成された音楽がChatGPTのような転機を迎えるのはまだ待たれています。それは、たとえばYouTubeクリップのプロデューサーが、事前に録画された素材ではなくLyria 3をますます使うようになる、という形で静かに起こるのかもしれません。

2つのグラフは、TTT-E2Eがコンテキスト長を増やしても128kまで損失とレイテンシが安定して維持されることを示しています。

推論時における長いコンテキストの学習

大規模言語モデルは、より長いコンテキストを処理すると、通常は精度が下がり、速度も遅くなります。しかし研究者たちは、コンテキストが大きくなっても精度を安定させ、推論時間を一定に保てるようにLLMを可能にしました。

新しい点: 非営利団体Astera Institute、Nvidia、スタンフォード、UCバークレー、UCサンディエゴのArnuv Tandon、Karan Dalal、そして同僚らは Test-Time Training, End-to-End (TTT-E2E) を導入しました。これは推論中に学習することで、コンテキストをトランスフォーマの重みに圧縮する方法です。

重要な洞察: トランスフォーマ・アーキテクチャに基づいて構築されたLLMは、次の出力トークンを生成するために、コンテキスト全体（これまでに入力・出力されたすべてのトークン）に注意を向けます。したがって、新しい出力トークンを生成するたびに、前回より多くの処理が必要になり、推論は高コストかつ遅くなり得ます。コンテキスト全体に注意を向ける代わりに、トランスフォーマは固定サイズのより小さなウィンドウに注意を制限できます。これにより、各出力トークンを生成するのに必要な時間が一定に保たれ、さらに重みを更新することでコンテキストから学習できます。

仕組み: 著者らは、8,000トークンの固定ウィンドウに注意を制限するスライディングウィンドウ・アテンションを実装した30億パラメータのトランスフォーマを構築しました。モデルは、Webからスクレイピングしたテキストから成るフィルタ済み dataset を用いて、8,000トークンのシーケンス（合計1,640億トークン）で事前学習しました。より長いコンテキストを追跡できるようにするために、彼らは The Pile のBooksサブセットから抽出した最大128,000トークンのシーケンスでファインチューニングしました。著者らは、メタラーニング、つまり「学ぶ方法を学ぶ」の一種を用いました。この場合、モデルは推論時に与えられる入力から、どのように学ぶかを学習します。

学習とファインチューニングは2つのループで行われました。内側のループ（ここでは「内側ループ」と呼びます）は、外側のループ（より外側のループ）に含まれます。内側ループでは、推論時にコンテキストの一部を学習することをシミュレートし、外側の循環では、その学習の後にモデルがどれだけうまく機能するかを評価し、それに応じて重みを調整しました。
内側ループでは、学習シーケンスを連続する1,000トークンのチャンクに分割しました。各チャンクに対し、モデルはスライディングウィンドウ・アテンションを用いて、(i) 各トークンを順に予測し、(ii) 通常の次トークン予測損失を計算し、(iii) その損失を使って、ネットワークの最後の四分の一にある全結合層で重みがどう変わるべきかを計算しました。その結果、1,000トークンごとに1つずつの重み更新系列が得られます。
外側ループでは、これらの重み更新を使って、シミュレーションされた重み更新の後における平均の次トークン予測損失を計算しました。シミュレーションされた重み更新の系列に対して逆伝播を行い、モデル全体の重みを更新しました。（この手順は、勾配の勾配を計算する必要があるため、学習時間を増やします。）
推論時には、モデルは内側ループに従いました。入力コンテキストをチャンクに分割し、チャンク上で次トークン予測損失を計算し、ネットワークの最後の四分の一にある全結合層のみを更新しました。その後、新しいトークンを生成します。（推論では内側ループのみを使用するため、外側ループの学習プロセスで必要になる増加した時間は不要であり、コンテキスト長に関わらず処理時間は一定になります。）

結果: 著者らはTTT-E2Eを、従来型のアテンションを用いるトランスフォーマだけでなく Mamba 2 （再帰型ニューラルネットワークスタイルのモデル）や Gated DeltaNet （線形アテンションの独自形式を用いる）とも比較しました。その精度は長いコンテキストにおいてトランスフォーマをわずかに上回りましたが、短いターゲット文字列を長いコンテキストから復元する課題「Needle-in-a-Haystack」では例外でした。さらに、コンテキストが伸びても、出力トークンはより効率的なアーキテクチャと同程度の速さで生成しました。優れた推論速度は、より遅く複雑な学習という代償のもとで得られたものでした。

TTT-E2Eは、次トークン予測損失の観点で、短いから長いコンテキストまで非常にわずかに高い性能を示しました。従来型トランスフォーマは、8,000〜128,000トークンのコンテキスト長にわたって平均損失が0.015高い値でした。Mamba 2およびGated DeltaNetの損失はそれでも0.03高いままでした。TTT-E2Eは、短いコンテキストを処理する際のNeedle-in-a-Haystack（NIAH）ではこれらのモデルに一致しましたが、8,000トークンを超えると性能が大きく低下しました。たとえば128,000トークンでは、TTT-E2E（6%）はMamba 2（7%）やGated DeltaNet（7%）を下回り、従来型トランスフォーマ（99%）はさらに大きく下回っています。
TTT-E2Eはバニラのトランスフォーマーよりも長いコンテキストをより高速に処理し、Mamba 2およびGated DeltaNetとほぼ同等の水準だった。H100 GPU上で動かした場合、TTT-E2Eの最初のトークン生成までの時間は、コンテキストが8,000トークンから128,000トークンへ増えるにつれて、1,000トークンあたり25ミリ秒ずつ線形に増加した。バニラのトランスフォーマーでは、最初のトークンまでの時間は、8,000トークンから128,000トークンへ増える間に、1,000トークンあたり12ミリ秒から70ミリ秒へ増加した。
TTT-E2Eのトレーニングレイテンシ（1,000の学習トークンごとにモデルの更新を処理して実行するまでに要した時間）は、Mamba 2およびGated DeltaNetを上回った。TTT-E2Eのトレーニングレイテンシは、8,000の学習トークンで約0.25秒だったものが、128,000の学習トークンでは約0.33秒まで上昇した。これに対して、Mamba 2およびGated DeltaNetは、約0.06秒でほぼ一定のままだった。8,000の学習トークンでは、バニラのトランスフォーマー（0.08秒）は4倍速く学習した。128,000トークンではこの関係が逆転し、バニラのトランスフォーマー（0.39秒）は約1.2倍遅かった。

重要な理由： 推論時の学習は、カスタムの注意（attention）機構や再帰的（recurrent）アーキテクチャを設計するよりも、長いコンテキストを処理するためのより単純なアプローチを提供する。今回の研究は、この問題を「学習」と「推論」のトレードオフとして捉え直すものである。すなわち、推論時に処理するのは、トークンあたりのコストが低く一貫性が高い一方で、学習は遅い。

考えていること： 私たちが「学び続けよう！」と言ったときに、このモデルはそれを真摯に受け止めた。