GPT-6 Astra の性能とループ型トランスフォーマー、隠された推論について

ここ数週間で多くの出来事がありました。おそらく今、誰もが OpenAI の GPT-6 Astra について気になっているでしょう。特にその性能や、ループ型トランスフォーマー（Looped Transformer）や再帰的な深さに関する議論、そして「Astra が思考の連鎖（Chain of Thought）を隠している」という噂が話題になっています。

そこでこの記事では、まず GPT-6 Astra についての簡単な印象と、今後どのような方向へ向かっていくのかについて考えを述べます。その後、「ループ型トランスフォーマー」が何を指すのか、そしてそれが思考の連鎖を隠すこととどう関係しているのか（あるいはしていないのか）について詳しく解説します。

最後に、ループ型トランスフォーマーの基本を押さえた上で、この分野に関する最近の研究論文から得られた新たな知見を紹介したいと思います。

1. GPT-6 Astra についての印象

まずは基本から。アーキテクチャの噂や関連する研究文献に入る前に、GPT-6 Astra に関するいくつかの観察点と断片的な情報をまとめてみましょう。

先週、OpenAI は新モデル「GPT-6 Astra」を大々的に発表しました。私は過去数日間で実際に使用しましたが、これは非常に優れたモデルで、現時点で使用した中で最も優秀なものだと言えます。では、具体的に何がどのように改善されたのでしょうか。

1.1 Astra のベンチマーク結果

Astra は私がこれまで使った中で最高のモデルです。特に 3D レンダリングやアニメーションのタスクにおいて、他モデルと比較して突出した性能を発揮します。つまり、文章作成、数学、コーディングなどあらゆるカテゴリーで前世代の GPT-5.6 を大きく凌駕していますが、その差が最も顕著に現れるのがグラフィカルなデモ関連のタスクです。

これらの性能はベンチマーク結果にも反映されています。例えば、GPT-6 Astra は数学とコーディングの両面で非常に高い能力を示しています（下図参照）。

図 1：主要なコーディングベンチマーク 3 つと、難易度の高い数学ベンチマーク 1 つの選定結果。詳細は Astra のリリースブログで確認できます：https://openai.com/index/gpt-6-astra/

なお、図には掲載されていませんが、Astra は論理パズルの解決と一般化能力を測定する「ARC-AGI-3」ベンチマークでも 99.9% のスコアを達成しています。これに対し、GPT-5.6 Sol はわずか 7.8% でした。しかし、数学・コーディング・コンピュータ操作に関するベンチマークの方が、実世界での利用に近いという点でより興味深い結果と言えます。

先ほどの図の右下にある「Artificial Analysis Coding Agent Index v1.4」に戻りましょう。これは複数のエージェント型コーディングタスクを統合した指標ですが、GPT-6 Astra は明確に最前線に位置しています。ただし、他社モデルとの差が劇的に拡大しているわけではありません。

この傾向は、コーディングに限らず多様なタスクを統合した「Artificial Analysis Intelligence Index」のグラフ（下図）でも確認できます。

Figure 2: Artificial Analysis Intelligence Index via https://artificialanalysis.ai/#intelligence

Artificial Analysis のベンチマークには、開発者が自己評価するものとは異なり、独立して実施されるため信頼性が高いという大きな利点があります。

ハッチ（検証環境）の構成はベンチマークによって異なります。例えば、GDPval-AA と AA-Briefcase では、比較対象となるさまざまな大規模言語モデルに対して、オープンソースで最小限の「Stirrup」ハッチが共通して使用されています。上記の Intelligence Index v4.2 においては、Terminal-Bench v2.1 が Terminus 2 を、τ³-Banking は τ-Bench ハッチを採用しています。また、個別に設けられた Coding Agent Index でも、異なるコーディングエージェント用のハッチ同士が比較されています。

共通のハッチを用いた評価では、「りんごとりんご」を比べるような公平な比較が可能になります。一方で、モデルの開発段階では、通常は特定の主要なハッチを想定してトレーニングが行われ、他のハッチに対する微調整はあまり行われません。さらに、主要なハッチ自体が、そのモデルの強みを最大限に引き出すように設計されているケースも少なくありません。

そのため、アジェンシー（自律型）評価においては、Astra が本来得意とする主要なハッチでの性能を過小評価している可能性があります。これが Intelligence Index のスコアにどの程度影響を与えるかは、同じタスクで Astra を異なるハッチ間で比較して検証する必要があります。

補足として、最近の同僚（Claude Code の責任者も推奨していることですが）から提案があったように、既存の AGENTS.md や SKILL.md ファイルの一部を削除（またはアーカイブ化）しても悪くないかもしれません。最新の LLM はプロンプト理解や問題解決において非常に効率的になっているためです。

これらのファイルに過度な指示を加えると、新しいモデルが不必要に制約され、かえって質の低い解決策を生む恐れがあります。

もちろん、SKILL.md ファイルを今後一切使わないべきだと提案しているわけではありません。一度作成したファイルを再利用すれば効率化できるワークフローも存在します。なぜなら、モデルがその都度再発見する必要がないからです。

私が言いたいのは、「説明が必要ない」ワークフローもあるということです。「古い」記述が常に最適とは限らず、LLM 自身がより良い解決策を導き出す可能性もあります。つまり、これらの指示ファイルを更新または再生成する時期が来ているのかもしれません。

1.2 コンピュータ操作機能

GPT-6 Astra は画像処理やレンダリング関連のタスクにおいて特に強力です。これらがグラフィカルユーザーインターフェース（GUI）との対伴を伴う場合、モデルはローカルのコンピュータ上でソフトウェアを操作する「コンピュータ操作」能力を発揮します。これは Codex や ChatGPT アプリを通じて実現されます。

他のモデルと比較しても、このコンピュータ操作機能こそが GPT-6 Astra の真価が発揮される部分です。グラフィック関連のタスクは、ソーシャルメディアプラットフォーム上で直感的で興味深いデモとして非常に人気があります。Blender でニューヨーク市をモデリングするレンダリングや、バーチャルなオープンハウスツアーなど、印象的なデモ事例は無数に存在します。

一例として、GPT-6 Astra の Medium と High モデルに、私のパソコンのブラウザ版 MS Paint でマウス操作しながら私の写真を描き直してもらった比較結果を以下に示します（Extra High や Max は使いませんでした。トークンを無駄にしたくないからです）。

これはモデルの芸術的スキルを示すだけでなく、何より重要なのは、パソコン上のツールを実際に使える点です（今回は Paint です。マウスカーソルを通じて、モデルがインターフェースを操作している様子が確認できます）。

これは、ハネスの中で汎用的なコンピュータ操作が可能になった最初のモデルではありません。今年初めから、私は GPT モデルを使って UI 関連のタスク（例えば Excel の経費処理など）を成功させてきました。しかし、コンピュータ操作は比較的新しい機能で、ハネスによって可能になったものですが、まだ完全に成熟したとは言い難いのが現状です。これは当然のことです。LLM はテキストモデルなので、まずは文章作成やコーディング、API や CLI の利用といった「手が届きやすい」分野から発展するのは自然な流れです。

一方で、まだ CLI を提供していないツールやソフトウェアは数多くあります。誰かがそのためのインターフェースを設計するのを待つのではなく、むしろモデルがグラフィカルユーザーインターフェース（GUI）を使えるように改善すべきではないでしょうか？前述した通り、これは非常に美しく印象的なデモにもなります。これは最近注目されているヒューマノイドロボットの開発とある程度似ています。確かに、アセンブリラインのように専用機械が存在する場所では、ヒューマノイドロボットは最も効率的ではありません。しかし、その汎用性は際立っています。

今後数ヶ月、あるいは数年は、LLM とエージェントの制御層の両面で「コンピュータ操作」の精度を高める時代が到来すると予想しています。つまり、現在の能力に加え、数学やコーディングのスキルを拡張するだけでなく、モデルにはコンピュータ操作を意識したトレーニングがより多く施されるようになるでしょう。これにより、テック業界以外の一般ユーザーにとっても、LLM は日常のパソコン作業にさらに身近な存在になります（「チャットGPTさん、私の確定申告を手伝って」といった使い方が可能になるのです）。

1.3 コンピュータ操作トレーニングの現状

このコンピュータ利用のトレンドは、OpenAI が強化学習のために数万台もの Mac Mini や Mac Studio を購入したという最近の報道とも一致しています。ここで重要なのは、Mac 自体がモデルの学習に直接使われるわけではない点です（学習には GPU の方が適しています）。むしろ、トレーニング中に macOS の環境をモデルに曝露させ、OS とその中で動作するツール類の使い方を学ばせるための「教材」として活用されています。

では、この Mac を用いたコンピュータ操作トレーニングは具体的にどのように行われるのでしょうか。一言で言えば、Mac（正確には macOS という OS）が、モデルがトレーニング中に相互作用できる環境として機能します。

基本的なワークフローは以下の通りです。

• モデルに「アプリ xyz を開いて abc を実行する」などのタスクを与えてプロンプトを入力する。
• macOS のインターフェースのスクリーンショットを提供する（これは通常、制御ハッチによって行われる）。
• LLM がマウスやキーボードの操作（クリック、キー入力、スクロールなど）を予測して出力する。
• 予測された操作を実際に Mac で実行する（これも制御ハッチが担当します）。

前ステップで実行したアクション後に、更新された環境の新しいスクリーンショットをフィードしてください。

タスクが成功するか失敗するまで、手順 2〜5 を繰り返します。

成功・失敗のシグナルや検証器（または採点者）をトレーニングフィードバックとして活用し、ポストトレーニング中に強化学習を行います。これは、検証可能な報酬を用いた通常の強化学習（RLVR: Reinforcement Learning with Verifiable Rewards）に相当します。

図 3: コンピュータ操作トレーニングのワークフロー概要。

ここで Mac は主に環境として機能しており、モデルの実行や更新を行うマシンではありません。モデルは実際には NVIDIA の GPU 上に置かれ、API を介して上記の Mac に供給されます。なお、NVIDIA の CEO は GPT-6 Astra が約 10 万基の Grace Blackwell GPU でトレーニングされていると述べています。

1.4 GPT-6 Astra は依然として推論モデルである

前節で議論したコンピュータ操作に特化したトレーニングへの注目は、トレーニングパイプラインにおける根本的なパラダイムシフトではありません。GPT-6 Astra（および今後 foreseeable な期間内のあらゆる大規模言語モデル）は、依然として推論モデルです。つまり、この LLM は検証可能な報酬を用いた強化学習（RLVR）で訓練され、中間的な推論トレース（思考の連鎖）を生成します。

ただし、GPT-6 Astra の推論モデルとしての側面、特に思考の連鎖を隠す仕組みについては、本記事の後半で詳しく取り上げます。

1. ループ型トランスフォーマー

さて、公式モデル発表の約 2 日前に、ニュース誌『The Information』が内部情報に基づき、Astra が「再帰的深さ（recurrent depth）」または「ループ型トランスフォーマー」と呼ばれる概念を採用していると報じました。

図 4: The Information の記事抜粋（出典：https://www.theinformation.com/articles/secret-technique-behind-openais-astra-model-sparks-security-concerns）

大規模言語モデル（LLM）のアーキテクチャは私の専門分野であり、情熱を注いでいる領域です。そこで私は、ループ型トランスフォーマーの一般的な仕組みと、「思考の連鎖が隠されている」という指摘について解説した短い講義動画を制作しました。動画は以下の通りです。

次の小節では、まずループ型トランスフォーマーとは何かを説明し、思考の連鎖が隠されているという点については本記事の後半で改めて取り上げます。

（ループ型トランスフォーマーの説明は少し長くなるかもしれませんが、この技術の基礎的な理解を深めるために必要だと考えています。その上で、「推論の痕跡や思考の連鎖を隠している」という主張が妥当かどうかを判断する材料となるはずです。）

2.1 トランスフォーマーブロックの再利用

では、ループド・トランスフォーマー（Looped Transformer）とは何か。

これは本質的にアーキテクチャ上の工夫であり、中間表現を同じトランスフォーマーブロックに複数回通すというアイデアが核心です。単にブロック数を増やすのではなく、この「技」のポイントは、各パスで重み（weights）を共有することにあります。

用語と専門用語について

本記事では以下の用語を使用します。

トランスフォーマー・ブロックとは、アテンション機構、フィードフォワード層、正規化層、そしてスキップ接続を含むユニットのことです。論文などでは「トランスフォーマー・レイヤー」と呼ばれることもあります。

スタック（stack）とは、トランスフォーマー・ブロックの連続した並びを指します。

ブロック適用（block application）とは、入力をトランスフォーマー・ブロックに一度通す処理のことです。

ループド・トランスフォーマー自体は新しい概念ではなく、その基本アイデアは 2018 年に発表された「Universal Transformer」の論文にも既に登場しています。ただし、Universal Transformer の議論に入る前に、まずはよりシンプルな例から始めましょう。それが今年夏に公開されたオープンウェイト LLM「Nanbeige4.2-3B」です。私はこのモデルについて、Substack Notes や LLM Architecture Gallery で取り上げました。

以下に示す Nanbeige のアーキテクチャは、一見すると通常のトランスフォーマーのように見えます。しかしよく見てみると、トランスフォーマースタックの最初へ戻る追加の矢印（オレンジ色）がループしていることがわかります。

図 5：Nanbeige4.2-3B は、同じ 22 層のトランスフォーマーブロックを 2 回適用しています。オレンジ色の矢印は、中間表現が再びこのスタックにフィードバックされる箇所を示しています。

これを下から順に見ていきましょう。まず、他のすべてのトランスフォーマーベースの大規模言語モデル（LLM）と同様に、入力テキストはトークン化され、埋め込みベクトルに変換されます。その後、これらのベクトルは 22 層のトランスフォーマーブロックを通過しますが、各ブロックには独自の重みが設定されています。

ここで注目すべきは「ループ型トランスフォーマー」の仕組みです。最初のパスが完了すると、隠れ状態（hidden states）が同じ 22 層のブロック群に再びフィードバックされます。つまり、ブロック 1 が再度適用され、続いてブロック 2、そして最終的にブロック 22 まで順次処理が進みます。

この計算を完全に展開すれば、トランスフォーマーブロックの適用は合計 44 回行われることになります。しかし、従来の 44 層の異なるブロックを持つトランスフォーマーと比較すると、2 回目のスタック（22 回の適用）では、1 回目のスタックで使用した重みを再利用しています。具体的には、23 番目のブロック適用で 1 番目のブロックの重みが使われ、24 番目で 2 番目のブロックの重み、というように順に重みが共有されます。

図6：Nanbeige4.2-3Bを、同じ22層のトランスフォーマーブロックに2回通すことで、実質的に44回のブロック適用を実現しています。

つまり、トランスフォーマーの重みセットを追加することなく、有効な深さを22から44へと引き上げているのがこのアプローチの核心です。

ところで、なぜループは3回や4回ではなく「2回」なのでしょうか。Nanbeige論文には詳細な記述が少ないものの、これは実質的に最も効率的な設定だったとされています。ループ数を2から3に増やすことでモデル性能が向上する可能性はあるものの、追加される計算コストに見合わないという判断でした。

2.2 ルーピングのコスト

では、そもそもなぜこのようなルーピングを行うのでしょうか。これは、トランスフォーマーブロックを追加してモデルを単純に大きくする代替案と言えます。

例えば、22層のトランスフォーマーブロックを2回使用するモデルは、44層の従来のブロックを持つモデルと比較すると、パラメータ数がおよそ半分になります（トランスフォーマーブロック部分に限った場合）。

これにより、重みを保存するために必要なメモリ量を削減できます。参考までに、通常は全体のパラメータ数の大きな割合を占める埋め込み層と出力層はこの比較対象には含まれていません。（Nanbeige 4.2 3Bの場合、埋め込み層と出力層は合計30億パラメータの約25%を占めていますが、これら2つの間で重みを共有すれば、その割合は12.5%まで削減可能です。）

図 7：従来の手法とループ処理を比較し、それぞれに必要なパラメータ数を示したものです。

もちろん、同じブロックをループで再利用しても計算コストはゼロにはなりません。具体的には、順伝播（フォワードパス）の間に中間入力を 44 回のブロック適用に渡す必要があります。また、学習時には勾配が共有されたスタックの両方の反復を通じて逆伝播します。つまり、22 個のブロックを一度だけ使う場合と比較すると、計算量は大幅に増加します。実際、44 個の異なるブロックを持つことと同等のコストがかかります（ただし、オプティマイザが更新するパラメータの種類は減りますが、バックプロパゲーションはすべての 44 回のブロック適用に対して実行されます）。

また、KV キャッシュも考慮する必要があります。これは、従来のトランスフォーマーやループ型トランスフォーマーにおいて、次のトークン生成ステップで再利用するために、過去のトークンのアテンションキーと値を保存するものです。参考までに、KV キャッシュについては別の記事を用意していますので、よろしければご覧ください。

さて、本題に戻りましょう。ループ型トランスフォーマーでは重みの共有が行われますが、2 回目のパスでブロックに入る中間状態は異なります。その結果、KV キャッシュにおいても、この 2 つのトランスフォーマースタック間で生成されるキーと値も異なってしまうのです（ループなしの場合と同じです）。つまり、KV キャッシュに関連する節約効果も期待できません。

具体例を挙げると、ブロック 1 と 23 のアプリケーションはどちらもループド・トランスフォーマー設定でブロック 1 を使用していますが、それぞれのアプリケーションには独自の KV キャッシュエントリが必要です。両方のパスで別々のキャッシュを保持しなければならないため、22 ブロックが繰り返されるスタックの KV キャッシュ要件は、44 個の異なるブロックを持つ従来のトランスフォーマーと同等になります。

興味深いことに、Nanbeige の研究チームは論文の中で、パス間で KV キャッシュを共有しようとした試みについて報告しています。もちろんこれにより KV キャッシュサイズは半減しましたが、モデルのパフォーマンスは別々のキャッシュを使用した場合（これがリリースされたバージョンです）よりも劣りました。

他のループド・トランスフォーマーの設計に移る前に Nanbeige の議論を完結させるためにもう一つ触れておくと、彼らの技術レポートでは 2 つの追加の選択肢やトレードオフについても言及されています。

ループド・アーキテクチャをゼロからトレーニングする方が、すでに事前学習済みのトランスフォーマーをアップサイクリングして変換するよりも優れた結果を示しました。

また、前述のセクションで触れた通り、2 回のパスが最も望ましいトレードオフをもたらします。それ以上のパスを追加してもわずかな性能向上しか得られず、トレーニング速度は低下し、最適化も不安定になることがわかりました。

つまり、パス数は私たちが選択しなければならないもう一つのアーキテクチャ上の決定事項です。前述の通り Nanbeige ではこれは 2 に固定されていますが、次節で見るように、これをトークンに依存させることも可能です。

2.3 ユニバーサル・トランスフォーマーと柔軟なループ数

さて、ユニバーサル・トランスフォーマーの話に戻りましょう。Nanbeige では、22 層のトランスフォーマーブロックをスタックして 2 回適用しています。一方、2018 年のユニバーサル・トランスフォーマー論文では、複数のブロックを積み重ねるのではなく、同じトランスフォーマーブロックを繰り返し適用するアプローチを採用しました。根本的なアイデアは似ています。

ステップ数は固定することもできますが、論文では適応的停止（adaptive halting）も探求されています。例えば、ある位置のトークンは 1〜2 回のループしか通らないこともあれば、別の位置のトークンは 3〜4 回ループすることもあります。これにより、モデルは追加計算を必要とするトークンに計算リソースを柔軟に割り当てることが可能になります。

このループ回数はどのように決定されるのでしょうか？ここでは、各ステップで各位置に対して「停止確率（halting probability）」を出力する小型の学習済み関数を使用します。これらの確率は連続するループごとに累積され、合計値が閾値を超えた時点でその位置でのループは終了します。また、計算が無限に続くのを防ぐため、最大ループ回数も設定されています。

図 8: ユニバーサル・トランスフォーマーにおける適応的停止

ループド・トランスフォーマーの別の例として、ByteDance の「Ouro」があります。これは私の LLM アーキテクチャ・ギャラリーでも取り上げました。

例えば、「Ouro-Thinking 2.6B」は、48 層のトランスフォーマーブロックからなるスタックを 4 回繰り返して適用します。つまり、重みを保持するのは 48 個の異なるブロックだけで済む一方、ブロックの適用回数は合計 192 回に達します。

これは Nanbeige のケースよりもさらに極端な例と言えます。また、学習されたエグジット・ゲートが、各ステップでの確率を割り当てる仕組みも特徴です。