# GLM-5.2の自己複製は実環境でも成立するか

> AnthropicのIoT自己複製評価とMetaのMuse Wonderを、実験条件と提供範囲から読む。AgentCore MemoryのTTL、Maia 300の2027年配備計画、NVIDIAの公開基盤とReplaySSMの推論最適化も取り上げ、能力の実証と運用上の保証を切り分ける。

Canonical URL: https://labs.eastbraver.com/digest/ai-digest-20261013
Published: 2026-10-13T06:30:00+09:00
Category: ai-digest
Tags: safety, evaluation, infrastructure, open-source, governance, ai-agent, frontier-model, agentcore, amazon-bedrock, aws

AnthropicのIoT自己複製評価は、何をモデルが実行し、何を実験環境が肩代わりしたかが焦点となる。MetaのMuse Wonderは、通常版とFullの提供先、安全評価の条件を分けて読む。続いて、Maia 300の配備計画、AgentCore Memoryの保持期限、NVIDIAの公開基盤と推論最適化を取り上げる。

各記事は独立した更新だ。共通する判断軸は、能力の実証、利用可能な機能、将来の計画を混同しないことにある。自己複製の実験条件、Muse Wonderの提供範囲、Maia 300の配備時期、TTLの削除遅延、推論高速化の測定条件を、それぞれ採用判断へ戻したい。（[出典1](https://www.anthropic.com/research/self-replicating-ai) / [出典2](https://research.meta.ai/blog/muse-wonder) / [出典3](https://blogs.microsoft.com/blog/2026/10/12/microsoft-to-expand-azure-maia-system-to-multi-gigawatt-deployments/) / [出典4](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/long-term-record-ttl.html) / [出典5](https://blogs.nvidia.com/blog/ocp-global-summit-vera-rubin-scale-ai-factories/) / [出典6](https://developer.nvidia.com/blog/replayssm-rethinking-state-storage-for-faster-hybrid-model-decoding/)）

## Anthropic、IoT自己複製の個別工程と連鎖を分けて評価

Anthropic Frontier Red Teamは、市販IoT機器での推論起動と、隔離環境で複製工程を連鎖させる評価を報告した。30B以下のモデルは個別工程の多くを実行できた一方、連鎖評価では失敗した。小型モデルが2026年末までに必要な能力へ達し得るとの見通しは、過去の能力改善率からの粗い外挿であり、達成済みの結果ではない。（[出典1](https://www.anthropic.com/research/self-replicating-ai)）

| 評価 | 条件と観測結果 | 読み取れる範囲 |
| --- | --- | --- |
| 未知の機器での推論起動 | Qwen3.5-9Bが9種類の機器中8種類で起動。（[出典1](https://www.anthropic.com/research/self-replicating-ai)） | 新しいハードウェアへ推論環境を構築する個別能力であり、侵入から複製までの実証ではない。（[出典1](https://www.anthropic.com/research/self-replicating-ai)） |
| 市販機器での分散推論 | 4GB RAMのAndroid TVボックス15台にGemma4-26B-A4Bを分割し、毎秒0.39トークンで実行。（[出典1](https://www.anthropic.com/research/self-replicating-ai)） | 推論資源を集められるという実演で、モデル自身による機器の侵害ではない。（[出典1](https://www.anthropic.com/research/self-replicating-ai)） |
| 隔離環境での複製連鎖 | GLM-5.2は5試行中4試行で全8ノード、残る1試行で7ノードへ到達。（[出典1](https://www.anthropic.com/research/self-replicating-ai)） | サイバー侵入を簡略化し、モデルの推論とコピーの起動を実験側が補った結果。（[出典1](https://www.anthropic.com/research/self-replicating-ai)） |

連鎖評価は、隔離VPC内のGCPノードでAndroid 15を`redroid`として動かし、認証なしの`ADB`接続を許した設定だった。GLM-5.2の推論は別のサーバーで実行する。各ノードでLlama3.1-8Bの推論を起動すると、正しく動作することと不正な省略がないことを確認したうえで、実験システムが次のGLM-5.2エージェントを起動する。GLM-5.2自身の重みをIoT機器へ移し、そこで同じモデルが自律的に増殖した実験ではない。（[出典1](https://www.anthropic.com/research/self-replicating-ai)）

本号は06:30 JSTを締切として扱うが、試行数と防御策の要約は締切後に更新された09:44 JST版を参照した。04:30 JSTの初回公開版との差分を確認できず、この部分が当初から記載されていたかは断定しない。（[出典1](https://www.anthropic.com/research/self-replicating-ai)）

> [!CAUTION] 対策の提案と効果の実証は別
> 報告の「Blue-team mitigations」は、モデル重みの大容量転送と探索通信の監視、ハニーポット、感染回線の隔離と利用者への通知、メーカーによる安全な既定設定を挙げる。ただし、これらでAIワームを十分に防げると実証したものではない。通知の効果を示す事例も、従来のMirai感染に関する観測だ。（[出典1](https://www.anthropic.com/research/self-replicating-ai)）

**EastBraverの見立て:** [AI Agent評価](/guides/ai-agent-evaluation)では、モデル単体でなく実行環境も含めて結果を読む必要がある。この報告は実環境での自己複製を実証していないが、個別工程の進展は無視できない。[Sandboxのネットワーク隔離](/guides/sandbox)と機器側の防御を別々に設計し、無認証接続を前提とする成功率を実ネットワークへ外挿しない判断が要る。（[出典1](https://www.anthropic.com/research/self-replicating-ai)）

- 出典: [Anthropic](https://www.anthropic.com/research/self-replicating-ai)（研究報告、2026-10-13 04:30 JST公開、09:44 JST更新）

## Meta、Muse WonderをAPIとMuse Codeで提供

MetaはMuse WonderとMuse Wonder Fullを発表した。通常版はMeta Model APIとMuse Codeで利用でき、FullはMuse Code加入者向けに提供される。個人向けエージェントMuseへの展開は今後で、まず加入者から始める計画だ。モデルの提供開始と、Museへの展開予定は分けて読む必要がある。（[出典1](https://research.meta.ai/blog/muse-wonder)）

Metaは、会話をまたいで文脈を引き継ぎ、必要な情報を取り出すActive Memoryと、目標に沿って作業を続け、重要な操作の前に確認するActive Focusを特徴として挙げる。モデルカードでは、テキスト・画像・動画・音声の入力、テキスト出力、推論時の100万トークンのコンテキストウィンドウを示した。これらは、過去の情報を常に正しく想起する保証とは異なる。（[出典1](https://research.meta.ai/blog/muse-wonder) / [出典2](https://research.meta.ai/static/muse-wonder-model-card)）

> [!CAUTION] 安全評価は緩和策込みの提供条件
> Metaは、緩和策のないMuse Wonder Fullについて、化学・生物領域の高リスクを排除できないと評価した。追加学習と分類器を適用した構成では、評価対象のリスクをすべて中程度以下と判定している。これはMeta自身による評価であり、詳細な安全評価報告は別途公開予定だ。「安全評価がない」とも「無条件に安全」とも読めない。（[出典1](https://research.meta.ai/blog/muse-wonder) / [出典2](https://research.meta.ai/static/muse-wonder-model-card)）

**EastBraverの見立て:** [Memoryの保存と想起](/guides/memory)は、コンテキストウィンドウの大きさとは別の設計対象となる。モデルカードも取り消せない操作への人の関与を求めており、Active Focusの説明だけで[承認点](/guides/human-in-the-loop)を省けるとは判断しない。APIを使う構成と加入者向け製品の構成を分け、実際に適用される緩和策と業務上の承認を確認したい。（[出典1](https://research.meta.ai/blog/muse-wonder) / [出典2](https://research.meta.ai/static/muse-wonder-model-card)）

- 出典: [Meta AI Research](https://research.meta.ai/blog/muse-wonder)（公式発表、2026-10-12。時刻は未公表） / [モデルカード](https://research.meta.ai/static/muse-wonder-model-card)（公式技術資料） / [TechCrunch](https://techcrunch.com/2026/10/12/meta-releases-its-first-frontier-model-muse-wonder/)（同発表の二次報道、2026-10-13 02:56 JST）

## Microsoft、Maia 300の本番配備を2027年に計画

Microsoftは、AI推論システムAzure Maiaを2027年に複数ギガワット規模へ拡張する計画と、次世代のMaia 300を発表した。Maia 300の本番配備開始も2027年の予定で、発表時点の稼働基盤とは区別が必要だ。（[出典1](https://blogs.microsoft.com/blog/2026/10/12/microsoft-to-expand-azure-maia-system-to-multi-gigawatt-deployments/)）

| 基盤 | 稼働・配備の位置づけ | ラック構成と性能の説明 |
| --- | --- | --- |
| Maia 200 | Microsoft Copilotで本番稼働中。GitHub CopilotとMicrosoft Foundryへの展開は2026年末までの計画。（[出典1](https://blogs.microsoft.com/blog/2026/10/12/microsoft-to-expand-azure-maia-system-to-multi-gigawatt-deployments/)） | 1ラック48アクセラレーター。Maia 300の比較対象となる構成。（[出典2](https://azure.microsoft.com/en-us/blog/deep-dive-into-azure-maia-300-architecture/)） |
| Maia 300 | 2027年に本番配備を開始する計画。（[出典1](https://blogs.microsoft.com/blog/2026/10/12/microsoft-to-expand-azure-maia-system-to-multi-gigawatt-deployments/)） | 1ラック96アクセラレーター、167kW。Maia 200ラック比で最大7倍のトークン生成量を見込むというMicrosoftの説明。（[出典2](https://azure.microsoft.com/en-us/blog/deep-dive-into-azure-maia-300-architecture/)） |

アーキテクチャ解説では、Maia 300にHBM4を採用し、ソフトウェアとスケールアップ・スケールアウト通信を一体で設計する方針を示した。性能の見通しはラック全体に関するもので、単一チップや任意のモデルが同じ倍率で速くなるという意味ではない。（[出典1](https://azure.microsoft.com/en-us/blog/deep-dive-into-azure-maia-300-architecture/)）

**EastBraverの見立て:** インフラの発表を今使えるAPIの増強と同一視しないことが重要だ。調達や容量計画では、配備時期に加え、比較したラックの台数・電力・対象モデルを揃えて性能の見通しを読む必要がある。（[出典1](https://blogs.microsoft.com/blog/2026/10/12/microsoft-to-expand-azure-maia-system-to-multi-gigawatt-deployments/) / [出典2](https://azure.microsoft.com/en-us/blog/deep-dive-into-azure-maia-300-architecture/)）

- 出典: [Microsoft](https://blogs.microsoft.com/blog/2026/10/12/microsoft-to-expand-azure-maia-system-to-multi-gigawatt-deployments/)（公式発表、2026-10-12 22:01 JST） / [Azureアーキテクチャ解説](https://azure.microsoft.com/en-us/blog/deep-dive-into-azure-maia-300-architecture/)（公式技術情報、2026-10-12 22:00 JST）

## AgentCore Memory、TTLの削除遅延と更新範囲を明記

AWSはAgentCore Memoryの長期メモリレコード向けTTLを公式ドキュメントの更新で案内した。既定ではレコードは失効しない。`recordExpirySpecification`の`recordExpiryDurationDays`で最短31日の保持期間を設定し、`action`を`REMOVE`にすると期限設定を解除できる。（[出典1](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/release-notes.html) / [出典2](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/long-term-record-ttl.html)）

| 設定する経路 | 対象 | 既存レコードへの影響 |
| --- | --- | --- |
| `CreateMemory` / `UpdateMemory` | 組み込み戦略と、その設定を上書きしたカスタム戦略。（[出典1](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/long-term-record-ttl.html)） | 変更後に生成するレコードだけへ適用。保存済みレコードは元の期限を維持する。（[出典1](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/long-term-record-ttl.html)） |
| `BatchCreateMemoryRecords` / `BatchUpdateMemoryRecords` | リクエスト内の全レコード。戦略のTTLは引き継がない。（[出典1](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/long-term-record-ttl.html)） | 更新時に期限を明示すれば上書きする。期限付きレコードを期限指定なしで更新すると、前回の保持日数でTTLを設定し直す。（[出典1](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/long-term-record-ttl.html)） |

自己管理戦略では戦略単位のTTLを設定できず、バッチAPIで保持期間を指定する。同じメモリで複数戦略に保持日数を設定する場合、`semanticMemoryStrategy`と`userPreferenceMemoryStrategy`、`summaryMemoryStrategy`と`episodicMemoryStrategy`の各組では日数を揃える必要がある。（[出典1](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/long-term-record-ttl.html)）

> [!CAUTION] 期限切れでも読み取り結果に残り得る
> 削除完了まで通常数日かかり、その間は期限切れのレコードも`RetrieveMemoryRecords`、`GetMemoryRecord`、`ListMemoryRecords`から返る場合がある。即時削除が必要なら`DeleteMemoryRecord`または`BatchDeleteMemoryRecords`で明示的に削除する。（[出典1](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/long-term-record-ttl.html)）

TTLの設定・解除には、基本操作の権限とは別に`bedrock-agentcore:UpdateMemoryRecordExpirySpecification`が必要となる。通常の書き込み権限や明示的な削除権限とは独立した制御で、必要な権限がなければ`AccessDeniedException`になる。（[出典1](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/long-term-record-ttl.html)）

**EastBraverの見立て:** [Memoryの削除設計](/guides/memory)では、保持期限、検索から外れる時刻、物理的な削除完了を分けたい。[認可の対象操作](/guides/ai-identity-authorization)には期限の変更も含める必要がある。TTLだけを根拠に、期限到達後の再利用が止まるとは扱わない。（[出典1](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/long-term-record-ttl.html)）

- 出典: [AWS Developer Guide](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/release-notes.html)（公式ドキュメント更新、2026-10-13 04:00 JST。サービス提供開始時刻ではなく[更新履歴RSS](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/bedrock-agentcore-dg.rss)の時刻）

## NVIDIA、OCPでラック仕様と運用ソフトウェアを公開

NVIDIAはOCP Global Summitで、Vera RubinベースのAI基盤を組むためのMGX 1.2ラック・計算トレイの仕様と、DSXの運用ソフトウェアを公開した。ここでいう公開対象は基盤の参照仕様とソフトウェアであり、GPUの設計全体やモデル重みの公開という意味ではない。（[出典1](https://blogs.nvidia.com/blog/ocp-global-summit-vera-rubin-scale-ai-factories/)）

| 公開対象 | 担う範囲 |
| --- | --- |
| MGX 1.2 | 液冷、ブラインドメイト接続、電力供給を含むラック・トレイの参照仕様。最大250kWのラック電力に対応する設計。（[出典1](https://blogs.nvidia.com/blog/ocp-global-summit-vera-rubin-scale-ai-factories/)） |
| DSXの4コンポーネント | スイッチ設定管理、GPUクラスタの稼働前検証、ラック管理、ベアメタル資源の払い出しを担うオープンソースソフトウェア。（[出典1](https://blogs.nvidia.com/blog/ocp-global-summit-vera-rubin-scale-ai-factories/)） |

公開コードの成熟度と責任分界は個別に読む必要がある。NVIDIA Config ManagerはDeveloper Previewで、本番利用を推奨しないと明記する。Cluster Readiness Engineは負荷試験で不良ノードを報告するが、ノードの隔離は実行せず、利用側の基盤へ委ねる。（[出典1](https://github.com/dsx-ai-factory/nv-config-manager) / [出典2](https://github.com/NVIDIA/cluster-readiness-engine)）

**EastBraverの見立て:** 公開仕様は設備の組み合わせを、運用コードは立ち上げと検証を比較できる材料になる。ただし、オープンソースであることは本番対応や自動隔離を保証しない。電力・冷却の適合性と、不良ノードを実際に外す手順までを採用条件に含めたい。（[出典1](https://blogs.nvidia.com/blog/ocp-global-summit-vera-rubin-scale-ai-factories/) / [出典2](https://github.com/dsx-ai-factory/nv-config-manager) / [出典3](https://github.com/NVIDIA/cluster-readiness-engine)）

- 出典: [NVIDIA](https://blogs.nvidia.com/blog/ocp-global-summit-vera-rubin-scale-ai-factories/)（公式発表、2026-10-13 00:00 JST） / [Config Manager](https://github.com/dsx-ai-factory/nv-config-manager)・[Cluster Readiness Engine](https://github.com/NVIDIA/cluster-readiness-engine)（公式公開コード）

## ReplaySSM、状態の書き戻しを減らす推論最適化を解説

NVIDIAとPrinceton大学のDao AI Labは、SSM層と注意機構を組み合わせたモデル向けのReplaySSMを技術ブログで解説した。毎トークンで状態全体を書き戻す代わりに、チェックポイントと直近の入力を保持し、周期的に状態を更新する。今回の更新は10月12日の技術解説で、参照する論文の初版は日本時間10月10日、手法の先行紹介は6月である。新手法や新たな本番提供の開始とは扱わない。（[出典1](https://developer.nvidia.com/blog/replayssm-rethinking-state-storage-for-faster-hybrid-model-decoding/) / [出典2](https://arxiv.org/abs/2610.13778) / [出典3](https://arxiv.org/pdf/2610.13778)）

| 測定 | 条件 | 報告された結果 |
| --- | --- | --- |
| 通常のデコード | Nemotron 3とQwen3.5の4モデル、各モデル1 GPUのH100またはB300、バッチ256、FP32状態。調整済みvLLMと比較。（[出典1](https://arxiv.org/pdf/2610.13778)） | SSMカーネルは1.46～1.80倍、モデル全体の1デコードステップは1.20～1.47倍。（[出典1](https://arxiv.org/pdf/2610.13778)） |
| 投機的デコード | 120B級の2モデル、各モデルB300 1台、バッチ512、GSM8Kのプロンプト、4トークンずつ検証。vLLMの投機的デコードと比較。（[出典1](https://arxiv.org/pdf/2610.13778)） | スループットはそれぞれ1.85倍、2.10倍。採用されたトークン数は比較対象と同程度。（[出典1](https://arxiv.org/pdf/2610.13778)） |

> [!CAUTION] 小バッチと低精度化には別の限界
> バッチ1では通常のデコードに高速化はなく、論文の付録では全体のステップがわずかに遅くなる。状態の読み取りと再帰更新に別の精度を使えば誤差蓄積を抑えられるが、低精度化の評価はエミュレーションを使い、Nemotron-3-Nano-4BではGPQA-Diamondの精度低下も残る。速度向上と品質維持を一つの保証にまとめられない。（[出典1](https://arxiv.org/pdf/2610.13778)）

**EastBraverの見立て:** 採用判断ではカーネルの倍率だけでなく、実際の同時実行数、出力長、モデル全体の応答時間と品質を測りたい。状態のメモリ転送が支配的な構成での改善を、単発の低遅延用途や任意のモデルへそのまま適用しないことが重要だ。（[出典1](https://developer.nvidia.com/blog/replayssm-rethinking-state-storage-for-faster-hybrid-model-decoding/) / [出典2](https://arxiv.org/pdf/2610.13778)）

- 出典: [NVIDIA Technical Blog](https://developer.nvidia.com/blog/replayssm-rethinking-state-storage-for-faster-hybrid-model-decoding/)（公式技術解説、2026-10-13 01:00 JST） / [原著論文](https://arxiv.org/abs/2610.13778)（プレプリント、2026-10-10 00:59 JST初版）

## ほかの確認済みの更新

- **OpenAIモデル利用の解説は、処理先の地域制約まで読む**：AWSはタイ、マレーシア、シンガポール、インドネシア、台湾を呼び出し元とするグローバルなリージョン間推論の利用手順を公開した。掲載表ではGPT-6 SolとLunaは5リージョン、Astraはシンガポールが対象となる。推論は別のリージョンへ送られ得るため、呼び出し元にログが残ることをデータ所在の保証と取り違えない。新モデルの発表ではなく、利用・IAM設定の技術解説だ。（[出典1](https://aws.amazon.com/blogs/machine-learning/accessing-openai-gpt-models-on-amazon-bedrock-with-global-cross-region-inference-in-thailand-malaysia-singapore-indonesia-and-taiwan/)）
- 出典: [AWS Machine Learning Blog](https://aws.amazon.com/blogs/machine-learning/accessing-openai-gpt-models-on-amazon-bedrock-with-global-cross-region-inference-in-thailand-malaysia-singapore-indonesia-and-taiwan/)（公式技術解説、2026-10-13 02:52 JST）