AI駆動開発 2026年7月12日

エージェントを10万個動かす時代のインフラ——隔離・スケール・攻撃面という3つの壁

AIエージェントの話題は、どうしても「どのモデルが賢いか」に流れがちだ。GPT-5かClaudeか、ベンチマークは何点か。でも、実際に複数のエージェントを並列で動かし始めると、最初に壁になるのはモデルの性能ではない。インフラだ。

Modal の CTO が Latent Space のインタビューで明かした数字が、この現実をよく表している。強化学習（RL）のロールアウトでは「時に10万個のサンドボックス」を瞬間的に立ち上げる必要があるという。10万個。それも「起動して使い捨てる」サイクルで。このスケールのインフラを前提に設計しないと、どれだけ賢いモデルを積んでも運用は崩れる。

この記事は、エージェントを「安全に・大量に・境界付きで」動かすために直面する3つの壁——①隔離 ②スケール ③攻撃面——を整理しながら、それぞれの実務的な含意を掘り下げる。

「DX→AX」という転換が意味するもの

Modal の CTO は、自社 SDK チームの設計思想を「開発者体験（DX）からエージェント体験（AX）へ変えた」と語る。理由はシンプルで、「エージェントに数百の Kubernetes YAML を読ませて型のないファイルを書かせるより、コード内のデコレータを数行変えて変更をライブで確認できる方が圧倒的に速い」からだ。

さらに彼はこう続ける。「コードを誰も読まなくなった時代にこそ、オブザーバビリティ（可観測性）が最重要」。出力の挙動を観察して変更をプロンプトする——それが AX 時代の運用スタイルだという。

この言葉と呼応するのが、Every.to の Dan Shipper が書いた「Don't do your work. Tend your loop（仕事をするな、ループを世話せよ）」という一文だ。人は「タスクの実行者」から「作業をこなすシステムを世話する管理者」へ変わる、という論点。Modal の「DX→AX」と、言葉は違うが同じことを指している。

ここからは見方だが、この転換は単なる設計思想の変化ではなく、エンジニアの役割定義そのものが書き換わっているサインだと思っている。タスクを自分でやるのではなく、タスクをこなすエージェントをどう設計・監視・修正するかが仕事になる。そして、そのエージェントを「安全に大量に動かすインフラ」が整っているかどうかが、チームの生産性を直接決めるようになる。

壁①：隔離——「速くて安全」でなければ使われない

エージェントに手を動かさせるということは、任意のコードを走らせるということだ。暴走・情報流出・意図しない副作用を防ぐには、閉じ込め（サンドボックス）が要る。

隔離の強度は大まかに4段階に整理できる：カーネル制限 / コンテナ / MicroVM / 仮想マシン。MicroVM は「ハードウェア仮想化による強い隔離」と「コンテナ並みの高速起動」を両立する中間解で、macOS では Apple Container がこの役割を担う。Modal の CTO 自身も「サンドボックスレベルでは LLM 仲介の権限に懐疑的で、ハードなガードレールが必要」と明言している。

ここで見落とされがちなのが、起動速度だ。「重ければ安全」という発想で作られた隔離は、エージェント運用では使われなくなる。エージェントは頻繁に立ち上げ直すので、起動に数十秒かかる隔離は実用にならない。参照されていた h5i というサンドボックスは、コンテナを使わずに 0.2〜3秒で起動し、プロンプトインジェクション対策と全操作の監査記録を両立させている。「速い隔離」こそが AX 時代の要件、というのは逆説的に聞こえるが、実際には至極まっとうな要求だ。

Claude Code は Bubblewrap/seccomp を Bash Tool に適用して settings.json で許可範囲を制御し、Codex は read-only / workspace-write / danger-full-access という3段階の権限モデルを持つ。実務的には、このレベルのきめ細かい設定を「最初から入れる前提」でエージェントを設計するかどうかが、後の痛みを大きく左右する。

壁②：スケール——問題は「0→1」ではなく「1,000→1,500」

Modal が直面している最大の技術的挑戦は、自動スケーリングだ。CTO によれば、通常のエージェントやサンドボックスはさほどバースト的でないが、「RL は異常なほどバースト的」で、ロールアウト時には 10万サンドボックスを瞬時に必要とする。

しかも問題の本質は「ゼロから何かを立ち上げる」ことではない。「1リージョン内で 1,000 から 1,500 GPU へ超弾力的にスケールする」こと、つまり既存リソースの超高速拡張だ。Modal は GPU スナップショット（モデルの状態を保存してコールドスタートを高速化する手法）でこれに対応している。

10万サンドボックスは無縁に聞こえるかもしれないが、原理は個人開発者にも同じ形で降ってくる。たとえば複数のサブエージェントを並列起動して Reddit の情報収集をする場面を考えてほしい。IP 単位の WAF でブロックされないためには、1サブレッドずつ、各取得の間に12秒以上のスリープを挟む逐次実行にする必要がある。短間隔で一括ループすると全経路が数分デッドになる。規模はまるで違うが、「大量アクセスを安全にさばくにはレート制御が要る」という原理はまったく同じだ。

壁③：攻撃面——権限を渡すと、新しい種類の穴が開く

エージェントに権限を与えると、これまで存在しなかったカテゴリの脆弱性が生まれる。GitLost はその典型例だ。攻撃者は公開リポジトリの Issue に隠した指示を仕込むだけで、AIエージェントに非公開リポジトリの内容を公開コメントとして吐き出させられる。認証情報は一切不要。報告者はこれを「エージェント AI の間接プロンプトインジェクションは、Web アプリの SQL インジェクションに相当する」と表現した。

モデル自体にも攻撃面は開く。2026年7月に GPT-5.6 がリリースされた際、UK AI Security Institute は数時間以内に「普遍的ジェイルブレイク」を発見したと報告している。単発の逸脱ではなく、モデルの能力を損なわないままエージェント的タスクやエクスプロイト開発に悪用できる、という深刻なものだ。「賢いモデルほど安全」ではない、という事実をここに置いておく。

防御側の研究も進んでいる。Anthropic の GRAM は、危険知識を性能を落とさずに削除可能な区画に隔離するアプローチだ。攻撃面を「言うこと」ではなく「知っていること」のレベルで塞ごうとしている。

「権限は使い捨て」が、エージェント設計の次の定石になる

実務的な対策として、ZOZO が全社導入した JIT（ジャストインタイム）アクセスの考え方が参考になる。強力な AWS 権限を必要な時だけ一時付与し、読み取り専用は常時・書き込みのみ JIT 対象と割り切る設計だ。これをエージェントにそのまま適用するべきだ、というのが元記事の主張でもある。

常時フルアクセスのエージェントが GitLost のような間接インジェクションを受けると、被害は最大化する。「強い権限を常時持たせない」設計は、人間の運用では既に定石になりつつあるが、エージェントへの適用はまだ遅れている。

一方で、Modal は逆方向の未来も見せている。同社の auto inference では、エージェントが GPU を H200 から B200 に変えながら設定を自己最適化するという。権限を絞りつつ、どこまで委ねるか——この綱引きが AX 時代の設計の中心になる、というのが今の見方だ。

ここからは論点の提示になるが、次に問われるのは「権限委譲の粒度設計」だと思っている。読み取りは自動許可、送信・作成・削除は確認を挟む——という大雑把な2分割ではなく、コンテキストに応じて動的に権限を付与・剥奪する仕組みが求められるようになる。エージェントが増えれば増えるほど、この設計の粗さがそのままリスクとして表面化する。