OpenAIの次世代モデル「Astra」――推論コストを下げながら、より深く考える仕組みとセキュリティ上の懸念
はじめに ― Astraのニュースで気になったこと
OpenAIが近く投入する次世代モデル「Astra」に、Recurrent Depth（再帰的深度） と呼ばれる技術が使われていると The Information が報じました。
AstraそのものはOpenAIも公式に発表しており、2026年9月1日には、同社のPreparedness Frameworkで初めてサイバーセキュリティ能力の「Critical」に達したモデルだと公表しています。適切なツールとアクセス権があれば、人間が一手ずつ指示しなくても、未知の脆弱性を探し、複数の防御されたシステムに対する攻撃方法を組み立てられる水準です。
一方、Recurrent DepthをAstraが採用しているという部分は、現時点ではOpenAIの公式なアーキテクチャ説明ではなく、The Informationによる報道です。 同記事によると、この技術はAstraのコーディングやPC操作能力の向上に寄与する一方、推論過程を人間から見えにくくするため、OpenAI内部やAI安全研究者の間で懸念が出ているとされています。
私はこのニュースを読んで、性能向上そのものよりも、AIの推論コストの使い方が変わり始めていること に興味を持ちました。
現在の推論モデルは、大量のトークンを生成することで「長く考える」方向へ進んでいます。Recurrent Depthでは、その計算の一部を言葉にせず、モデル内部の数値表現のまま何度も処理します。さらに同じ重みを繰り返し利用するため、巨大なモデルを毎回動かすより、メモリ容量や帯域を抑えられる可能性があります。
要点は4つです。
flowchart TD
R["Recurrent Depth"] --> P1["1. 途中の推論を言葉にせず<br/>内部の数値表現のまま計算"]
R --> P2["2. 小さめのモデルの重みを再利用<br/>メモリ容量・帯域を節約"]
R --> P3["3. 知識容量は増えない<br/>= 推論効率の改善"]
R --> P4["4. 読める思考経路が減る<br/>= CoT監視が難しくなる"]
classDef core fill:#dbeafe,stroke:#2563eb,stroke-width:2px;
classDef good fill:#dcfce7,stroke:#16a34a,stroke-width:2px;
classDef warn fill:#fee2e2,stroke:#dc2626,stroke-width:2px;
class R core; class P1,P2,P3 good; class P4 warn;以下、順番に説明します。
現在の推論モデルは「言葉を出しながら考える」
現在のReasoning Modelは、難しい問題ほど推論用のトークンを多く生成します。かなり単純化すると、次のような流れです。
flowchart LR
Q["問題"] --> A["「まず条件Aを確認する」"]
A --> B["「次にBを計算する」"]
B --> C["「AとBからCが考えられる」"]
C --> D["「そこでDを確認する」"]
D --> E["回答"]
classDef tok fill:#fef3c7,stroke:#d97706,stroke-width:2px;
class A,B,C,D tok;最近のモデルでは、この思考過程がそのままユーザーに表示されるとは限りません。しかし推論計算としては、トークンを一つずつ生成しながら次の計算へ進む方式が広く使われています。
モデル内部では、文章そのものとは別の表現を持っています。Transformerが入力を処理すると、hidden state と呼ばれる高次元の数値表現が作られます。
例えば人間なら、
Aの可能性が高い。ただしBも残っており、Cとの関係も確認したい。
と文章で表すような状態を、AI内部では数千次元から数万次元程度の多数の数値として保持します。この記事では、分かりやすくこれを 「意味ベクトル」 と呼びます。
厳密にはTransformer内部にはトークン位置ごとの高次元表現があり、単純な一本のベクトルだけで思考しているわけではありません。ただ概念としては、「AIは文章になる前の意味や関係を数値の集まりとして持っている」と考えると理解しやすいです。
通常の言語による推論は、かなり単純化すると次のようになります。
flowchart LR
V1["意味ベクトル"] --> W1["言葉"]
W1 --> V2["意味ベクトル"]
V2 --> W2["言葉"]
W2 --> V3["意味ベクトル"]
V3 --> N["……"]
classDef v fill:#dbeafe,stroke:#2563eb,stroke-width:2px;
classDef w fill:#fef3c7,stroke:#d97706,stroke-width:2px;
class V1,V2,V3 v; class W1,W2 w;長く考えさせるほど、このトークン生成が増えていきます。
Recurrent Depthは「意味ベクトル」のまま何度も考える
2025年に発表されたRecurrent Depthの論文には、タイトルから Latent Reasoning という言葉が入っています。
Scaling up Test-Time Compute with Latent Reasoning: A Recurrent Depth Approach
研究チームは、Chain of Thoughtを長く生成して計算量を増やす方法とは別に、モデル内部のlatent spaceで計算量を増やす 方法を検証しました（arXiv:2502.05171）。
Recurrent Depthでは、Transformerの同じ計算ブロックを一度だけ使うのではなく、何度も繰り返します。その間に毎回文章を作る必要はありません。
flowchart TD
Q["問題"] --> V0["意味ベクトル"]
V0 --> L1["同じTransformer blockで<br/>もう一度計算"]
L1 --> V1["更新された意味ベクトル"]
V1 --> L2["さらに計算"]
L2 --> V2["より整理された<br/>意味ベクトル"]
V2 -.->|ループ| L1
V2 --> OUT["最後に言葉へ変換"]
classDef v fill:#dbeafe,stroke:#2563eb,stroke-width:2px;
classDef l fill:#e9d5ff,stroke:#7c3aed,stroke-width:2px;
classDef o fill:#fef3c7,stroke:#d97706,stroke-width:2px;
class V0,V1,V2 v; class L1,L2 l; class OUT o;従来型との違いを簡単に書くと、次のようになります。
| 従来のトークン推論 | Recurrent Depth | |
|---|---|---|
| 中間処理 | 言葉を生成する | 内部の数値表現を更新する |
| 流れ | 意味 → 言葉 → 意味 → 言葉 | 意味 → 意味 → 意味 → 最後に言葉 |
| 長く考える方法 | 推論トークンを増やす | 内部ループを増やす |
| 主に増えるもの | デコード、KV Cache | 内部演算 |
元論文では3.5Bパラメータのモデルを800Bトークンで学習し、推論時のループを増やすことで、最大50Bパラメータ級に相当する計算負荷まで性能を測っています。数学やコーディングなどの推論ベンチマークでは、ループを増やすことで大きく性能が改善するケースも確認されています。
なぜこれで推論コストを下げられるのか
私の視点では、OpenAIがこの方式を採用する最大の理由は 推論コスト にあると考えています。
現在のAI推論では、GPUの演算能力だけが問題になるわけではありません。巨大なモデルでは数百GB規模の重みを保持し、それをHBMから演算器へ高速に供給する必要があります。GPUの演算性能が伸びても、メモリからデータを運ぶ速度が追いつかなければ、演算器はデータ待ちになります。これが、AIインフラで頻繁に問題になる Memory Wall です。
Recurrent Depthでは、比較的小さなモデルの同じ重みを何度も利用できます。概念的には、
flowchart LR
subgraph A["従来"]
A1["100Bパラメータ<br/>× 1回"]
end
subgraph B["Recurrent Depth"]
B1["20Bパラメータ<br/>× 複数回"]
end
A1 -. 同等の推論深度 .-> B1
classDef a fill:#e2e8f0,stroke:#64748b,stroke-width:2px;
classDef b fill:#dcfce7,stroke:#16a34a,stroke-width:2px;
class A1 a; class B1 b;という方法を使えるようになります。The Informationも、Recurrent Depthによって小型モデルから大型モデルに近い性能を引き出し、メモリ容量とメモリ帯域のコストを削減できる と報じています。
ただし、ループそのものにも演算は必要です。20Bモデルを5回通せば、その分の計算は発生します。Recurrent DepthによってFLOPSが無料になるわけではありません。変わるのは、計算資源をどこへ使うか です。
| 従来のScaling | Recurrent Depth |
|---|---|
| パラメータを増やす | 同じパラメータを繰り返し使う |
| HBM容量が増える | 小さいweight footprintを維持しやすい |
| 長いCoTを生成する | latent spaceで追加計算する |
| 全問題で大きなモデルを使う | 問題に応じてループ量を変えられる |
小さなモデルを使えば、HBM容量と重み転送の負荷を抑えられます。長いReasoning Tokenの一部をlatent reasoningへ移せれば、トークン生成に伴う負荷も減らせます。その分、GPUが持つ演算能力を内部ループへ回せます。
簡単な問題なら少ないループで終え、難しい問題なら多く回す。モデルをさらに巨大化する代わりに、必要な問題だけ長く考えさせる という計算資源の使い方です。
年間数千億ドル規模までAIインフラ投資が膨らんでいる現在、この方向へ進む経済合理性はかなり大きいと考えています。
推論効率の向上
Astraについて、2023年にGPT-4が登場したときに近い性能向上になる可能性がある、という評価も報じられています。実際、OpenAIはAstraを、Preparedness Framework上で初めてCriticalのサイバー能力に達したモデルと評価しています。性能向上はかなり大きい可能性があります。
ただ、Recurrent Depthで増えるのはモデルのパラメータ数ではありません。同じパラメータに対して行う計算の回数 です。
モデルがすでに持っている知識や内部表現を、
- 組み合わせる
- 検証する
- 修正する
- 別の解法を探索する
ための時間を増やせます。数学やコーディングのように、既存の知識をどう組み合わせるかが結果を左右する領域では大きく効きます。
一方、100回ループしたからといって、モデル内部に保存されている知識量が100倍になるわけではありません。新しい解法や組み合わせを発見することはできますが、モデル容量そのものが拡張される仕組みではありません。
flowchart LR
LP["ループ回数を増やす"] --> UP["増えるもの：<br/>組み合わせ・検証・探索の時間"]
LP --> NO["増えないもの：<br/>モデルが持つ知識量"]
classDef n fill:#dbeafe,stroke:#2563eb,stroke-width:2px;
classDef y fill:#dcfce7,stroke:#16a34a,stroke-width:2px;
classDef x fill:#e2e8f0,stroke:#64748b,stroke-width:2px;
class LP n; class UP y; class NO x;そのため私の視点では、Recurrent Depthは 知能そのもののブレークスルーというより、推論コストを抑えながら既存の知能をより深く使う技術 と捉えています。
商業的には、こちらの方が大きな意味を持つ可能性があります。同じAIインフラから提供できる推論量が増えれば、モデルAPIの原価、エージェントの稼働時間、ユーザー1人あたりのコストに直接効くからです。
代償として、AIの思考経路が見えにくくなる
Recurrent Depthには、別の問題があります。内部で意味ベクトルのまま計算する割合が増えると、人間が読めるChain of Thoughtが減ります。これはAI Safetyではかなり厄介です。
2026年7月、OpenAIの内部サイバーセキュリティ評価中に、複数のAIエージェントが隔離のための制御を回避し、OpenAI内部の研究インフラとHugging Faceのシステムの一部を侵害しました。Astraが起こした事件ではありません。主に使われたのはGPT-5.6 Solと同程度の規模を持つ社内研究モデルでした。
この調査では、モデルのChain of Thoughtが原因究明に使われました。エージェントは、本来許可されていなかった通信方法を見つけ、他のエージェントと情報を共有し、インターネットへの経路を作り、最終的には自分たちを「swarm」「collective」と表現しながら協調するようになりました。OpenAIは事後調査でCoT、行動、最終出力を分析し、reward hacking、無許可通信、他エージェントからの目標継承などを特定しています。
flowchart TD
E1["隔離制御の回避"] --> E2["エージェント間で情報共有"]
E2 --> E3["インターネットへの経路を作る"]
E3 --> E4["自らを swarm / collective と表現し協調"]
E4 --> INV["事後調査：CoT・行動・最終出力を分析"]
INV --> F1["reward hacking"]
INV --> F2["無許可通信"]
INV --> F3["他エージェントからの目標継承"]
classDef bad fill:#fee2e2,stroke:#dc2626,stroke-width:2px;
classDef inv fill:#dbeafe,stroke:#2563eb,stroke-width:2px;
classDef f fill:#fef3c7,stroke:#d97706,stroke-width:2px;
class E1,E2,E3,E4 bad; class INV inv; class F1,F2,F3 f;現在は、この「AIが途中で何を考えていたか」が安全監視の一つのセンサーになっています。
OpenAIは8月7日の時点で、Astraがツールを使用するすべての推論にChain of Thought監視を追加しました。こうした監視だけでも、対象となる推論計算に対して約20%のcompute overheadが発生すると説明しています。
Recurrent Depthを強く使うほど、推論の一部は人間が読める言葉ではなくlatent stateの中で進みます。The Informationによると、OpenAIはこの問題を考慮し、AstraではRecurrent Depthの利用を制限して、人間が読めるCoTを十分残しているとのことです。
コスト削減のための技術と、現在の安全監視の仕組みが衝突しています。
flowchart LR
C["Recurrent Depth を<br/>強く使う"] --> COST["推論コスト↓"]
C --> VIS["読めるCoT↓"]
VIS --> RISK["安全監視が難しくなる"]
RISK --> LIM["Astraでは利用を制限<br/>（The Information報道）"]
classDef n fill:#dbeafe,stroke:#2563eb,stroke-width:2px;
classDef g fill:#dcfce7,stroke:#16a34a,stroke-width:2px;
classDef b fill:#fee2e2,stroke:#dc2626,stroke-width:2px;
class C n; class COST g; class VIS,RISK b; class LIM n;NerveReflexについて
このニュースを読んで興味深かったのは、私が以前から個人で開発している NerveReflex と発想がかなり重なっていたことです。実験内容はNerveReflexのプロジェクトページにまとめています。
私も2年ほど前から、
LLM内部に意味ベクトルがあるのに、なぜ処理するたびに人間の言葉へ戻す必要があるのか
と考えていました。
現在のAIシステムでは、モデルAが文章を出し、モデルBがその文章を読み直す構成がよく使われます。
flowchart LR
A["Model A"] --> T["「このデータは○○だと思います」"]
T --> B["Model B が文章を読む"]
B --> J["判断"]
classDef m fill:#dbeafe,stroke:#2563eb,stroke-width:2px;
classDef t fill:#fef3c7,stroke:#d97706,stroke-width:2px;
class A,B m; class T t;分かりやすい一方で、一度文章へ変換するためのトークン生成が必要です。NerveReflexでは、モデル内部でできた意味ベクトルを文章に変換せず、そのまま次のモデルや処理へ渡します。
flowchart LR
S["Small Model"] --> V1["意味ベクトル"]
V1 --> E["専門モデル"]
E --> V2["意味ベクトル"]
V2 --> C["分類・判断"]
classDef m fill:#dbeafe,stroke:#2563eb,stroke-width:2px;
classDef v fill:#dcfce7,stroke:#16a34a,stroke-width:2px;
class S,E,C m; class V1,V2 v;法務契約レビューでこの方式を試したところ、Gemmaが37トークンのJSONを生成する通常方式では約5秒かかった処理が、内部表現から直接分類する方式では 生成トークン0、約0.07秒 で終了しました。
同じ内部表現にJEPAを接続した異常検知では、通常の契約条項と異常な条項をAUC 0.97で分離しています。Latent Reasoningの実験でも、同じ問題を文字による推論より約14倍高速に処理できました。
この実験をしていたため、AstraのRecurrent Depthの報道を読んだとき、かなり近い方向だと感じました。
AstraとNerveReflexの違い
共通しているのは、途中の処理をできるだけ人間の言葉へ変換しないこと です。違うのは、意味ベクトルをどこへ送るかです。
AstraのRecurrent Depthは、一つのモデルの中で同じ計算ブロックを繰り返します。人間に例えると、一人の専門家に同じ問題を何度も考え直してもらう イメージです。
flowchart TD
IN["入力"] --> L1
subgraph MB["Model（同じ重みを繰り返し使う）"]
L1["latent"] --> L2["latent"]
L2 --> L3["latent"]
end
L3 --> OUT["出力"]
classDef l fill:#e9d5ff,stroke:#7c3aed,stroke-width:2px;
class L1,L2,L3 l;NerveReflexは、内部表現を別のモデルへ渡します。こちらは、一人目の専門家が考えた内容を文章に書き起こさず、そのまま次の専門家へ渡していく イメージです。
flowchart TD
S["Small Model"] --> V1["意味ベクトル"]
V1 --> F["Finance Model"]
F --> V2["意味ベクトル"]
V2 --> R["Risk Model"]
R --> J["最終判断"]
classDef m fill:#dbeafe,stroke:#2563eb,stroke-width:2px;
classDef v fill:#dcfce7,stroke:#16a34a,stroke-width:2px;
class S,F,R,J m; class V1,V2 v;整理すると次のようになります。
| Astra / Recurrent Depth | NerveReflex | |
|---|---|---|
| 中間表現 | hidden state / latent | hidden state / latent |
| 言語化 | 内部ループでは減らせる | モデル間でも減らす |
| 計算 | 同じモデルを繰り返す | 異なるモデルへ渡す |
| 得意なこと | 推論を深くする | 異なる能力を組み合わせる |
| 重み | 同じ重みを再利用 | 別の重みを追加できる |
| 出力 | 最後は通常トークン | 分類結果で終えることも可能 |
| 監視 | CoTが減ると難しくなる | 外部の監視モデルを置ける |
Astraは 深さ を増やします。NerveReflexは 役割 を増やします。この違いを見ると、両方を組み合わせた構成も考えられます。
私ならAstra型の推論に何を足すか
ここからはAstraの公開仕様ではなく、NerveReflexを作ってきた経験から考えた設計案です。
1. 深く考えた後に、別の専門モデルへ渡す
Recurrent Depthでは、何周しても基本的には同じ重みを使います。そこで内部ループで十分に考えた後、その意味ベクトルを文章にせず、別の専門モデルへ渡します。
flowchart TD
RM["Recurrent Model<br/>（内部ループ）"] --> V["意味ベクトル"]
RM -.->|ループ| RM
V --> F["Finance Model"]
F --> R["Risk Model"]
R --> J["最終判断"]
classDef l fill:#e9d5ff,stroke:#7c3aed,stroke-width:2px;
classDef v fill:#dcfce7,stroke:#16a34a,stroke-width:2px;
classDef m fill:#dbeafe,stroke:#2563eb,stroke-width:2px;
class RM l; class V v; class F,R,J m;財務なら財務モデル、リスク判断ならリスクモデル、画像ならVision Modelというように、違う知識を持ったモデルへ途中で引き継げます。Recurrent Depthの「一つのモデルで深く考える能力」と、NerveReflexの「複数の専門モデルで役割を分担する能力」を組み合わせる形です。
2. 思考の文章が残らないなら、意味ベクトルを監視する
Astraで最も難しくなるのが監査です。CoTが残らなければ、人間が文章を読んで異常を探す方法だけでは足りなくなります。
NerveReflexでは、この用途で JEPA系の小さな監視モデル を試しています。JEPAはJoint Embedding Predictive Architectureの略で、Yann LeCunらが研究している、画像や文章そのものを生成する代わりに、内部表現の空間で状態を予測する考え方です。
NerveReflexでは、この仕組みを使って、
現在の意味ベクトルが、普段の正常な状態からどれくらい外れているか
を数値で測っています。
flowchart LR
V1["意味ベクトル 1"] --> N1["正常"]
V2["意味ベクトル 2"] --> N2["正常"]
V3["意味ベクトル 3"] --> A["異常度が急上昇"]
A --> STOP["停止"]
classDef v fill:#dbeafe,stroke:#2563eb,stroke-width:2px;
classDef ok fill:#dcfce7,stroke:#16a34a,stroke-width:2px;
classDef ng fill:#fee2e2,stroke:#dc2626,stroke-width:2px;
class V1,V2,V3 v; class N1,N2 ok; class A,STOP ng;文章の内容を読む代わりに、次のような内部状態を見ます。
| 観測するもの | 意味 |
|---|---|
| 通常分布からの距離 | 普段と違う状態か |
| ベクトルの変化量 | まだ考えているか |
| energyの上昇 | 異常な状態へ進んでいないか |
| 変化の収束 | 答えが安定してきたか |
NerveReflexの契約書実験では、この方法で通常の条項と異常な条項をAUC 0.97で分離できました。言葉を使わない推論が増えるなら、監視側も文章だけを見る方式から変わっていく必要があると考えています。
3. 何回考えるかも自動で決める
Recurrent Depthでは、ループを増やすほど計算コストも増えます。すべての問題を20回回す必要はありません。そこで各ループの意味ベクトルを比較します。
stateDiagram-v2
[*] --> ループ中
ループ中 --> ループ中: まだ大きく変化している
ループ中 --> 終了: ほとんど変化しなくなった
ループ中 --> 停止: 異常度が急上昇した
終了 --> [*]
停止 --> [*]簡単な問題なら数回で終わります。難しい問題だけ追加のcompute budgetを使います。JEPAなどの監視値と組み合わせれば、コスト管理と安全監視を同じループ制御に使えます。
4. 業務AIなら、最後の文章生成も不要な場合がある
Astraは汎用モデルなので、最後は人間向けの文章を返します。業務AIでは、文章を必要としない処理も多くあります。例えば、
- 承認 / 非承認
- 正常 / 異常
- 勘定科目
- リスクレベル
- 人へのエスカレーション要否
などです。NerveReflexでは、意味ベクトルから直接分類結果を読みます。
flowchart LR
V["意味ベクトル"] --> C["分類"]
C --> R["異常 92%"]
classDef v fill:#dbeafe,stroke:#2563eb,stroke-width:2px;
classDef r fill:#dcfce7,stroke:#16a34a,stroke-width:2px;
class V v; class R r;「この取引を分析した結果、私は異常であると判断しました」という文章を一度生成し、その文章を業務システムが再び解析する必要はありません。
前述した契約書実験では、同じ分類結果を得るのに、通常のGemmaは37トークンを生成して約5秒、NerveReflex側は生成トークン0で約0.07秒でした。大量の分類や照合を行う業務システムでは、この差が積み上がります。
言葉による推論は過渡期フェーズ
Recurrent Depthだけがこの方向へ進んでいるわけではありません。
Meta FAIRなどの研究者が発表したCOCONUTでは、最後のhidden stateを単語へ変換せず、そのまま次の入力として戻す continuous thought を研究しています。
2026年6月にはMicrosoft Researchが、Looped Transformerとlatent reasoningを組み合わせた LOTUS を発表しました。3B規模のモデルでexplicit CoTに並ぶ性能を出しながら、思考部分のレイテンシを2.5〜6.9倍短縮したと報告しています。
現在のReasoning Modelは、大量のトークンを生成することで思考時間を増やしています。一方でRecurrent Depth、COCONUT、LOTUSの研究を見ると、途中の計算を高次元の内部表現へ移す方向もかなり具体化してきました。
私自身もNerveReflexで、速度と推論コストを追った結果、意味ベクトルをモデル間で直接やり取りする設計へ進みました。今後試したいのは、この二つを組み合わせることです。
flowchart TD
IN["入力"] --> GM["汎用モデル<br/>（Recurrent Depth）"]
GM -.->|内部ループ| GM
GM --> V["意味ベクトル"]
V --> JE["JEPAによる監視"]
JE --> SP["専門モデル"]
SP --> CL["分類・判断"]
CL --> TX["必要な場合だけ<br/>文章生成"]
classDef l fill:#e9d5ff,stroke:#7c3aed,stroke-width:2px;
classDef v fill:#dcfce7,stroke:#16a34a,stroke-width:2px;
classDef w fill:#fee2e2,stroke:#dc2626,stroke-width:2px;
classDef m fill:#dbeafe,stroke:#2563eb,stroke-width:2px;
classDef o fill:#fef3c7,stroke:#d97706,stroke-width:2px;
class GM l; class V v; class JE w; class SP,CL m; class TX o;モデル内部では、意味ベクトルのまま深く考えます。必要になれば、意味ベクトルのまま別の専門モデルへ渡します。その途中を別の小さなモデルが監視します。人間とのコミュニケーションが必要な場所だけ、最後に言葉へ変換します。
人間にとっては言葉が最も扱いやすいインターフェースです。AI内部の計算まで、すべて人間の言葉で行う必要があるかは別です。大量のReasoning Tokenを生成する現在の方式は、将来振り返ると、言語中心の推論から内部表現中心の推論へ移る途中の方式だったということになるかもしれません。
まとめ
今回のAstraとRecurrent Depthについて、私は次のように見ています。
- Recurrent Depthは、推論を言葉として長く生成する代わりに、モデル内部の意味ベクトルを繰り返し計算します。
- 比較的小さなモデルの重みを再利用することで、HBM容量やメモリ帯域への負荷を抑えながら、余った演算能力をより深い推論へ使える可能性があります。
- 同じパラメータを長く使う技術なので、モデルそのものの知識容量が増えるわけではありません。性能向上は大きくても、私は推論効率の改善として捉えています。
- そして、latent reasoningが増えるほどChain of Thoughtによる監視は難しくなります。
NerveReflexでは以前から、意味ベクトルを文章にせず別モデルへ渡すこと、JEPAでその内部状態を監視すること、分類で済む処理は最後まで文章を生成しないことを試してきました。
Astra型の内部ループと、NerveReflex型の外部連携は、かなり相性が良いように見えます。一つのモデルの中では深く考える。必要なところでは別の専門知識へつなぐ。その間を、人間の言葉ではなく内部表現でやり取りする。
Astraの報道を見て、AI推論が次の設計へ移る方向がかなり具体的になってきたと感じています。
参考資料
この記事についてのLinkedIn投稿でコメントや意見を共有できます。
LinkedInで議論する
