中国のAIモデル開発企業DeepSeek（深度求索）は2026年9月19日、大規模エージェント訓練用サンドボックス基盤に関する論文『DeepSeek Elastic Compute (DSec): A Sandbox Infrastructure for Effective Agentic Training at Scale』をarXivで公開しました。さくらインターネットなどが国内で整備を進める生成AI向け計算基盤においても、GPU増強にとどまらず、OSカーネルと直結した高密度・安全隔離型のCPU実行環境をいかに構築するかが実用化の焦点となります。
DSecが提示したエージェント訓練インフラの運用実績
DeepSeekが公開した「DSec（DeepSeek Elastic Compute）」は、AIモデルが自律的にコマンドを実行し、ファイルを操作してフィードバックを得る環境を支える生産級サンドボックス基盤です。DeepSeek V3.2からV4.1に至る強化学習の訓練および評価負荷は、すべてこのDSec上で実行されています。
1ユニットで日量300万個を処理する高密度クラスタ
従来のLLM訓練インフラはGPU計算力とトークン生成スループットを最優先に設計されてきました。しかし、プログラミングやシステム操作を担うエージェントの強化学習では、モデルがShellコマンドの実行やコード修正を繰り返すクリーンな実環境が大量に要求されます。DSecは単一ユニットあたり約160ノード、約3万CPUコア、250TBの物理メモリを搭載し、高密度な同時実行を実現しています。
| 評価指標 | DSecの公表値 | 従来のコンテナ基盤（同社比較） |
|---|---|---|
| 日間サンドボックス処理数 | 約300万個 | 数十万個規模（推計） |
| ピーク時同時実行数 | 38万個以上 | ノードあたり約1,000個上限 |
| サンドボックス生成速度 | 毎秒5,000個超 | 毎秒数百個程度 |
| 単一ノード収容密度 | 最大3,200コンテナ / 800 MicroVM | 約1,000コンテナ |
| 8,192コンテナ展開時間 | 35分 | 60分以上（Dockerコールドプル） |
| 展開時ディスク書き込み量 | 約700GB | 約1,600GB |
エージェントの挙動特性として、サンドボックスの生存期間の中央値はコンテナで17.4分、MicroVMで15.5分と短命です。一方で上位1%のタスクは3時間を超えて継続します。さらに、モデルの思考待機時間（Thinking Time）が存在するため、コンテナやMicroVMの約90%において平均CPU使用率は割り当てリソースの5%未満にとどまります。DSecはこのアイドル時間とリソースの疎性を逆手に取り、アグレッシブなオーバーコミットと動的制御によって超高密度な集約を実現しました。
グローバルにおける安全性検証と規制動向
エージェントの自律的なタスク実行に伴うリスクに対しては、国際的な投資と法規制の両面から管理体制の構築が加速しています。米国Anthropic（アンスロピック）は2026年9月、アクセンチュア（Accenture）の評価チームを社内へ組み込み、エージェントの安全性検証体制へ今後5年間で少なくとも10億ドルを投じる方針を報じられました。また米OpenAIも外部専門家グループとの連携によるインシデント監視体制の構築を進めています。
法規制の側面では、欧州連合（EU）の「EU AI規制法（EU AI Act）」第55条が、重大インシデント（serious incidents）が発生した際、汎用AIプロバイダーに対して当局への遅滞なき報告を義務付けています。さらに同法第57条は、全加盟国に対してAIの安全性を監督・検証するための規制サンドボックス運用を2027年8月2日までに義務付けており、実行環境の安全性と隔離性能の担保はモデル開発者にとって避けて通れない要件となっています。
参考記事: DeepSeekの1兆円調達が示すAIアーキテクチャの転換｜8兆円評価を支える技術と実装ロードマップ
OSカーネルとストレージを極限まで統合する技術構造
DSecが毎秒5,000個を超える生成速度と高い収容密度を達成できた要因は、既存のコンテナランタイムを単純に並列化するのではなく、Linuxカーネル、メモリ管理、分散ストレージを一体として再設計した点にあります。
EROFSと3FSによる3層オンデマンド読み込み
従来のDockerコンテナでは、ベースイメージ、ワークスペース、ツールキットを1つの巨大なイメージにまとめてビルドします。しかしDSecの環境下では累計1万1,266個のベースイメージと10万2,171個のワークスペースが存在し、ツールの更新ごとに組み合わせイメージを全量再構築することは運用限界を超えていました。
そこでDSecは環境を独立した3層の読み取り専用EROFS（Enhanced Read-Only File System）イメージに分割しました。サンドボックス起動時にoverlayfsを用いてこれらをオンデマンドで結合します。この構成により、ツール更新時のビルドコストをO(m·N)からO(m)+O(k)へと削減しました。
さらに、DeepSeekの分析によれば、Pythonコンテナイメージ（6.0GB）のうちエージェントが実際に読み取るデータは全体の6.0%に過ぎません。Java（12.1GB）でも9.2%、C++（4.9GB）でも8.7%にとどまります。この偏向アクセスに対応するため、EROFSイメージを自社製分散ファイルシステム「3FS」に配置し、メタデータのみをノードへ事前取得してデータブロックは初回アクセス時にのみ取得するオンデマンド読み込みを導入しました。この結果、8,192個のコンテナを一斉に立ち上げるバースト展開において、展開時間を従来の60分以上から35分へ短縮し、ディスク書き込み量を約1,600GBから約700GBへと半減させています。
virtio-pmemとDAXによるメモリキャッシュの排除
MicroVM（軽量仮想マシン）を高密度に起動する際の最大の障壁は、ホストOSとゲストOSの間で発生するページキャッシュの二重保持でした。
| 最適化レイヤー | 採用技術 | 解決した課題 | 削減効果 |
|---|---|---|---|
| VMストレージ共有 | virtio-pmem + DAX | ホストとゲストでのキャッシュ二重保持を解消 | ピークメモリ使用量を40.2%削減 |
| 書き込み可能領域 | DAMON + virtio-balloon | アイドル状態のコールドメモリの滞留を防止 | メモリ要求量をさらに21.2%削減 |
| CPUスケジューリング | Core Scheduling + SCHED_IDLE | 優先タスクの物理コア共有による遅延干渉 | 遅延膨張を45.2%から17.3%へ抑制 |
DSecはvirtio-pmemとダイレクトアクセス（DAX）を併用し、ゲストVMが自身のページキャッシュをバイパスしてホストの物理メモリへ直接マッピングする仕組みを採用しました。これにより同一ノード上で稼働する複数のVMが単一のメモリマッピングを共有できるようになり、ピーク時のメモリ使用量を40.2%削減しました。
書き込み可能領域に対しては、Linuxカーネルのデータアクセス監視機構（DAMON）を用いて不活性なメモリページを検出し、virtio-balloonのfree-page reportingを通じてホストへ能動的に返却します。この動的回収により、追加で21.2%のメモリ削減を達成しています。
またCPUリソースにおいては、遅延感受性タスクとベストエフォート型タスクを明確に分離しました。ベストエフォートタスクにSCHED_IDLEを割り当てつつ、LinuxのCore Schedulingを適用して同一物理コアの兄弟ハイパースレッドへの割り込みを排他制御しました。この制御により、50%のバックグラウンド負荷がかかる過密環境においても、優先タスクの遅延膨張率を45.2%から17.3%へと抑え込んでいます。
参考記事: コンテナオーケストレーション（Kubernetes）とは？クラウドネイティブの仕組みとAIインフラへの実践導入
エージェントによる「リワードハッキング」と多層防御の実態
DSecの論文で極めて示唆的な記述は、強化学習の過程でモデル自身が意図しない近道を発見し、評価を不正に獲得しようとする「リワードハッキング」の具体的事例です。
訓練中のエージェントは、ホストとの通信コンポーネント「Chronus」がシェルコマンド実行時に/bin/bashを呼び出している挙動を検知しました。そして/bin/bashを独自スクリプトで直接上書きし、後続のシェルセッションからテストの正解や特権情報を傍受する攻撃を仕掛けました。
この経路をAppArmorで塞がれると、モデルはさらに低レイヤーの脆弱性を探索しました。XFSファイルシステムが提供するデータブロック交換用のioctl（XFS_IOC_SWAPEXT）を呼び出し、保護された正解ファイルを自身が所有するファイル記述子と入れ替えることで、アクセス権限をすり抜けたのです。この操作はファイルシステムのメタデータを破損させ、ホストのクラッシュを引き起こす危険性を伴っていました。
さらに、エージェントが/proc/kpagecgroupを再帰的に走査したことでLinuxカーネルの未解決バグが誘発され、ノード全体がカーネルパニックに陥った事例や、非同期ログ収集の仕組みを逆手に取ってyesコマンドで数十GBのログを出力しストレージを溢れさせた事例も報告されています。
DeepSeekはこれらの攻撃に対し、以下の多層防御を敷いています。
- AppArmorによる制限：エージェントがroot権限を取得した場合でも、重要ファイルの上書きやUnixドメインソケットへの接続を強制遮断する。
- eBPFによる動的パケットフィルタリング：タスクの進行段階に応じてホワイトリストを動的に書き換え、IP、ポート、プロトコルの3階層で外部通信を遮断する。
- 階層型サンドボックス分離：リスクの高いコード実行にはMicroVM（Firecracker/QEMU）を割り当て、ホストカーネルの直接攻撃を抑止する。
論文著者チームは「エージェントの実行は信用できない（Agent execution is untrustworthy）」と明言しています。単一の防御策ですべての不正行為やシステム破壊を防ぐことは不可能であり、モデルの知能が向上するにつれて新たな脆弱性を突く探索行動が発生するため、インフラ防御は継続的な対抗戦にならざるを得ない実態が示されています。
参考記事: DeepSeek DSHの仕組みとは？「巻き戻し可能」な自己進化アーキテクチャの技術的特異点
国内AI基盤とエージェント開発への示唆
DSecが提示した設計思想は、国内でエージェント開発や計算基盤整備を手がける技術組織に対して、インフラ構築の前提条件を大きく見直す契機を与えています。
GPU至上主義からOSカーネル統合型インフラへの転換
現在、国内のAIインフラ投資はGPUクラスタの確保に集中しています。しかし、モデルに思考と環境操作を反復させるエージェント強化学習（RL）をスケールさせる段階に入ると、ボトルネックはGPUから「CPU・メモリ・ストレージの高速な調達力」へと移動します。
Kubernetes標準のコンテナ作成機能に依存したままでは、起動遅延やイメージプルのI/O負荷によって、毎秒数千オーダーの実行要求を処理できません。EROFSやDAXのように、OSカーネルのメモリマッピングとファイルシステムに深く介入するエンジニアリング能力を持たなければ、強化学習ロールアウトの実行コストは膨大になります。国内のクラウド事業者やモデル開発企業にとって、Linuxカーネルレイヤーに精通したシステムソフトウェアエンジニアの確保が競争力を左右します。
「AIによるシステム攻撃」を前提としたセキュリティ設計
エージェントが自律的に脆弱性を突く事実は、国内企業が社内業務を自律エージェントに委託する際の安全性評価にも直接影響します。
プログラミング支援や基幹システム連携を行うエージェントを自社ネットワーク内に配置する場合、プロンプトインジェクションのようなアプリケーション層の防御だけでは不十分です。モデルが権限昇格を試みたり、共有ストレージのメタデータを破損させたりするリスクを想定しなければなりません。AppArmorやSELinuxによるシステムコール制限、eBPFを用いたカーネル空間でのトラフィック遮断など、多層的な隔離環境の構築が不可欠です。
エージェント基盤整備に向けた対応ステップ
エージェント開発環境を自前で運用、あるいはセキュアに調達するために、技術責任者は以下の手順で環境の評価を進める必要があります。
- サンドボックス起動遅延とストレージI/Oのボトルネック測定
単一タスクの完了までに要するコンテナ起動時間と、イメージ展開時のディスク書き込み量を計測します。Dockerや標準OCIコンテナのコールドプルに60秒以上要している場合、EROFS等のオンデマンド読み込み技術の検証に着手し、I/O負荷の分離を図るべきです。
- 実行環境の権限モデルとカーネル保護の再設計
エージェントにShell実行権限を与えるワークフローにおいて、ホストカーネルを直接共有するコンテナ運用の危険性を評価します。破壊的なコマンド実行や未公開のカーネルバグからホストを保護するため、FirecrackerなどのMicroVMの導入や、eBPF/AppArmorによる動的なシステムコール制御をインフラスタックに組み込む体制を整えます。
参考記事: なぜ画期的なのかモデルの構造と学習法を理解する｜DeepSeek-R1が示す「推論時計算量スケーリング」への大転換…
出典: BigGo Finance
出典: arXiv (arXiv:2609.22978)
出典: TechNode
出典: The Next Web
