親愛なる皆さん、

話しかけられる（会話できる）音声ベースのAIは急速に進歩していますが、それでも多くの人は、音声UI（ユーザーインターフェース）がどれほど広く浸透していくのかを、まだ十分に理解できていません。現在、私たちはキーボードとマウスで、ほとんどのデスクトップ／Webアプリケーションを操作しています。将来的には、これらの多くのアプリに対して、さらに「話しかける」ことで操作できるようになってほしいと願っています。私は特に Vocal Bridge （AI Fundのポートフォリオ企業）による取り組みに胸を躍らせています。そこではCEOのAshwyn Sharmaが、この実現を可能にする開発者向けツールを提供する道を切り拓いています。

重大なUIの変化が起きるたびに、多くの新しいアプリケーションが生まれるだけでなく、既存のものをアップグレードできるようにもなります。マウスのおかげで、ポイントしてクリックする操作が可能になりました。タッチやスワイプのジェスチャーによって、モバイルアプリの新しいカテゴリが生まれました。つい最近までは、音声UIはエラー率が高い、またはレイテンシが大きいといった問題を抱えていました。しかし、信頼性が高まってくるにつれて、多くの新しいアプリケーションが開けていくでしょう。

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

圧倒的多数の人にとって、書くことや読むことよりも、話すことや聞くことのほうがずっと簡単です。なぜなら多くの開発者は非常に読み書きが得意であり（そして The Batch の読者もそうです）、そのため「書くことがどれほど難しいと感じる人が多いのか」を忘れがちになります。実際、大人と一緒に時間を過ごす子どもは、自然に話すことや聞くことを身につけますが、明示的に教えられない限り、読むことや書くことは学びません。過去数十年のSF映画、例えば Star Trek では、人々がコンピュータに向かってタイピングするのではなく、話しかける場面がよく描かれます。これは、目指して作っていく価値のある未来の姿です！

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

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

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

音声UIは、AIアプリケーションにとって重要な構成要素になるでしょう。世界中の開発者のうち、これまでに音声アプリを作った人はごくわずかです。つまり、ここは構築の余地がとても大きい、実りある分野なのです。もしアプリに音声を追加してみたいなら、Vocal Bridgeを無料で こちらで試してみてください。

作り続けてください！

Andrew

DEEPLEARNING.AI からのメッセージ

AI Dev 26のアジェンダを公開したところです！ 2日間にわたるトーク、ワークショップ、デモを通じて、Google DeepMind、Oracle、AMD、そしてそれ以上のチームからの話を聞いてください。主催はAndrew Ngです。 予定を確認して、あなたのスケジュールを計画し始めましょう

ニュース

Claude Codeの内部

何が新しいのか：  Claude CodeのNode.jsパッケージの最近のバージョンに、うっかりキーが含まれていました。これにより コードが そのコマンドラインインターフェース背後のコードが「revealed 」とされ、露呈しました。ブロックチェーン・スタートアップのSolayer LabsでインターンをしていたChaofan Shouがコードを解錠して公開しました。エンジニアたちは急速にその秘密を解読しました。

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

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

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

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

将来の機能は？：  ソースマップは、Claudeに向けたAnthropicの可能性のある 計画 も示しています。たとえば、いくつかの未公開機能は、公開ビルドでは「false」にコンパイルされるフラグの背後に隠れており、現在開発途中であり、将来のリリースに含まれるかもしれないことを示すサインです。

• Kairos（ギリシャ語で「時宜を得た」）と呼ばれるサブシステムは、常時稼働するバックグラウンド・エージェントとして動作します。その論理システムであるautoDreamは、重複したメモリを統合し、矛盾を排除し、推測を解決し、そして（その他にも）メモリを剪定して、保存されたデータが行動により適するようにします。
• 他の隠された機能には、ボイス・インターフェース、Ultraplanというサブエージェント（負荷の高いタスクをクラウドに送る）、およびBuddyというペルソナがあります。Buddyはあなたの workにコメントし、恐らくはエンゲージメントを高めるためのものだと考えられます。
• Claude Codeには、以前は未公開だった「アンダーカバーモード」があり、エージェントが署名や、リポジトリで活動していたことを示すその他の痕跡を残さずに、ファイルを公開Gitリポジトリへコミットできるようにします。この機能により、Anthropicは、そうした活動を意図せず開示することなく、先進的なモデルのテストや、公に発表されていないパートナーとの連携が可能になるかもしれません。
• ファイルには、Capybaraというコード名のClaude 4.6バリアントへの参照や、Numbatという未リリースのモデルへの言及が含まれています。Capybaraのバージョン8は、誤りや誇張した主張を行う確率が約30%で、以前のバージョンの16.7%を大きく上回っています。これは、最新バージョンのモデルが抑制するよりも早とちりして飛びつくよう調整されていることを示唆しています。

なぜ重要か：  今回のリークは、利用可能な中でも最も先進的で人気のあるエージェント型システムの一つについて、内部を覗ける機会を提供します。Claude Codeがどのように動くのか、また近い将来どのように動く可能性があるのかが分かります。自分たちのシステムをそれに合わせて修正したり、異なる選択によって製品の差別化を図ったりすることもできます。

考えていること：  AIコミュニティは、ソフトウェアエージェントが意図せずコードベースを削除したり、非公開ファイルを公開してしまう可能性に、当然ながら懸念を抱いています。人間だって同じことができます！

OpenAI、動画生成を終了

OpenAIは、動画市場からの急な撤退により、動画生成ツール「Sora」を停止する計画だ。

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

仕組み： Soraは最大25秒の高精細動画を生成し、そのリアリティと映像品質によって高い評価を得ていた。しかし、各クリップを生成するには数分かかり、テキストや画像を作るのに比べてはるかに多くの処理能力が必要になる。OpenAIは2024年2月に モデルをプレビュー した。さらに同社は モデルを更新 し、2025年9月にはiOSアプリ経由で利用可能にした。

• Soraの収益の大半は、OpenAIの有料プランのサブスクライバーから得られている。Soraは3つのティアで提供されている。アプリのユーザーは、1日あたり約5本の無料10秒動画を生成できる（招待制）。ChatGPT Plusのサブスクライバー（毎月20ドル）は、Sora 2を使って、1280×720ピクセル解像度で15秒クリップを限られた数だけ生成できる。ChatGPT Proのサブスクライバー（毎月200ドル）は、より高度なSora 2 Proモデルを使って、1920×1080ピクセル解像度で最大25秒の動画を生成できる。
• Soraは1日あたりおよそ100万ドルの損失を出し続けていた。日次アクティブユーザー数は、モバイルアプリのリリース直後に約100万人に達したが、すぐにその半分未満まで落ち込んだ。
• X（旧Twitter）のソーシャルネットワーク上で停止を 発表 する前に、OpenAIは報道によれば、Soraの処理リソースを「Spud」とコードネームされた新しいAIモデルの稼働に振り向けており、このモデルがさまざまなコーディングやエンタープライズ向けプロダクトを支えているという。
• Soraチームは、ChatGPT内で動画を生成する新モデルの学習を提案していた。これは、おそらくSoraアプリの代替案になる可能性もあった。別の動画モデルを学習させるための高コストに直面し、同社は動画生成そのものを中止することを選んだ。
• 本稿執筆時点で、Sora 2 Proは 19位 に位置している。Artificial Analysisのテキスト・トゥ・ビデオ・リーダーボードで、ByteDance、Kling、xAI、Googleの競合モデルに大きく後れを取っている。

背景： 2025年後半、OpenAIはSoraを活用して、ディズニーとの大きく注目を集める 提携 を結んだ。OpenAIはディズニーのキャラクターをライセンスし、ディズニーの映像素材で自社のモデルを学習させる一方で、ディズニーは最大10億ドルをOpenAIに投資する。ディズニーは、Disney+の配信サービス上でSoraの動画を見せるほか、Soraを使って事前制作段階のビジュアル化、マーケティング施策、特殊効果の制作を支援する計画だった。Soraの差し迫った—終焉により、この提携は実質的に終了している。

なぜ重要か： OpenAIは動画生成における主導権を手放し、他の企業—複数の有力候補を含む—が覇権を争う余地を開けた。OpenAIが2年前にSoraを立ち上げた際、同社は別のChatGPTの瞬間を構想していた。生成される動画がマス市場を驚かせ、最大限の文化的インパクトを獲得することを望んでいた。しかし、計算が合わなかった。動画生成は、ビジネスやコーディング向けのアプリに比べて、有料サブスクライバーをそれほど多く引き寄せられず、動画モデルの学習・運用コストは耐えがたいほど大きかった。

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

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の契約者向けに高く設定）。また、動画のサウンドトラック生成ツール Dream Track 経由でYouTube Shortsのユーザーにも無料提供
• 未開示: アーキテクチャ、パラメータ数、学習データ、手法

仕組み: Googleは、Lyria 3のアーキテクチャと学習について、高レベルの概要のみを開示しました。純粋なノイズの埋め込みからノイズを取り除くことで画像を生成する、潜在拡散の画像生成器と同様に、Lyria 3は、ある時間スライスにおけるオーディオ表現からノイズを取り除きます。The Batchでは以前、Stability.AIによって開発された、オーディオ拡散 process を紹介しました。さらに、Googleの以前の音楽生成 methodもあります。

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

裏側のニュース: Lyria 3は、音楽業界がAI音楽ジェネレーターの開発者を、著作権侵害の疑いで積極的に提訴・訴追している中で登場します。主要な音楽ジェネレーターであるSunoとUdioは、ゼロから音楽を生成しなくなっており、Googleは、そのような開発者が減っていく中で残っている数少ない企業の一つです。

• 2024年6月に、世界の3大音楽会社であるSony Music、Universal Music Group（UMG）、Warner Musicが、Webベースの音楽ジェネレーターを提供するSunoとUdioを、著作権侵害の疑いで 提訴 しました。2025年末には、被告側は 和解 してUniversal Music Groupと合意し、ゼロから新しい音楽を生成するのではなく、既存のライセンス済み録音を編集・改変することを重視するようにサービスを変更しました。Sonyによる訴訟はなお進行中です。
• Googleは、音楽業界からの圧力に対し、部分的にはプロ向けの音楽制作を目的としたモデルを検討することで対応しました。2025年春に、Music AI Sandbox、MusicFX DJ、Lyria RealTimeを導入し、生成される音楽に対する、より細かな制御を可能にしました。Lyria 3をリリースしてから数日後、Googleは ProducerAI （以前はRiffusionとして知られていました）という別のプロ向け制作ツールを買収しました。

重要な理由: 音楽生成は、大手で強力な既存勢力によって支配されるエンターテインメント業界の中で、その居場所を見つけつつあります。Lyria 3は、現行のユーザーベースが小さいSuno（有料契約者は約200万人）やUdio（毎月のユーザー数は約330万人）を圧倒しながら、7億5000万人超のGeminiユーザーの前にその存在を送り出します。さらに、（SunoやUdioを世界最大級のレコーディング会社の標的にした）オリジナル音楽の生成を引き続き行いつつ、著作権者を刺激しないよう、ライセンスされた音楽での学習などのセーフガードも追加しています。

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

推論時に長いコンテキストを学習する

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

新しい点: 非営利団体Astera Institute、Nvidia、スタンフォード、UCバークレー、UCサンディエゴのアーヌーヴ・タンドン、カラン・ダラル、および共同研究者らが、 Test-Time Training, End-to-End (TTT-E2E) という方法を導入しました。これは、推論中に学習することで、コンテキストをトランスフォーマーの重みに圧縮する手法です。

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

仕組み: 著者らは、 sliding-window attention を実装する30億パラメータのトランスフォーマーを構築しました。これは、注意を固定の8,000トークンの範囲に制限します。彼らは、このモデルを合計1640億トークンの、8,000トークンからなる系列で事前学習しました。これはウェブからスクレイピングしてフィルタした dataset のテキストに由来します。さらに、より長いコンテキストを追跡できるようにするために、 The Pile のBooksサブセットから得た最大128,000トークンの系列で微調整しました。著者らはメタラーニングの一種、つまり「学び方を学ぶ」を用いました。この場合、モデルは推論時に与えられる入力から“学び方”を学習する、ということです。 

• 学習と微調整は2つのループで行われました。ひとつは（ここでは内側ループと呼びます）もうひとつの（外側ループ）内側にありました。内側ループは、推論時にコンテキストの一塊を学習することを模擬し、外側のサイクルは、その学習の後にモデルがどれだけうまく機能するかを評価し、それに応じて重みを調整しました。
• 内側ループでは、学習シーケンスを連続する1,000トークンのチャンクに分割しました。各チャンクについて、モデルはsliding-window attentionを使って（i）順に各トークンを予測し、（ii）典型的な次トークン予測の損失を計算し、（iii）その損失を使って、ネットワークの最後の四半期（最後の1/4区間）にある完全結合層において重みをどのように変えるべきかを計算します。その結果、1,000トークンごとに重み更新の系列が得られます。
• 外側ループでは、これらの重み更新を用いて、模擬された重み更新の後における平均の次トークン予測損失を計算しました。模擬された重み更新の系列を通じて逆伝播（backpropagation）し、モデル全体の重みを更新します。（このプロセスは、勾配の勾配を計算する必要があるため、学習時間を増やしました。）
• 推論時、モデルは内側ループに従います。入力コンテキストをチャンクに分割し、チャンク上で次トークン予測の損失を計算し、ネットワーク最後の四半期にある完全結合層のみを更新します。次に新しいトークンを生成します。（推論では内側ループのみを使うため、外側ループの学習プロセスで必要になった増加した時間は不要であり、コンテキスト長に関わらず処理時間は一定でした。）

結果: 著者らは、TTT-E2Eを、通常の注意機構を備えたトランスフォーマーや、 Mamba 2 （反復型ニューラルネットワークスタイルのモデル）や Gated DeltaNet （線形注意の独自形式を用いる）と比較しました。長いコンテキストでは、針の穴探し（Needle-in-a-Haystack）を除いて、TTT-E2Eはトランスフォーマーよりわずかに高い精度を示しました。ここで針の穴探しとは、長いコンテキストから短い目的の文字列を復元する課題です。そして、コンテキストが伸びても、より効率的なアーキテクチャと同程度の速さで出力トークンを生成しました。驚異的な推論速度には代償として、学習が遅く、より複雑になるというコストがかかりました。

• 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）アーキテクチャを設計するよりも、長いコンテキストを処理するためのより単純なアプローチを提供します。この取り組みでは、問題を「学習」と「推論」の間のトレードオフとして捉え直します。推論時に処理する方が、トークンあたりのコストが低く、かつトークンごとの一貫性が高い一方で、学習は遅くなります。

考えていること: 「学び続けよう！」と言ったとき、このモデルはその意図を受け止めました。