Anthropic：コーディング面接を廃止した理由

Rieseberg氏は、Claude.ai、Claude Cowork、Claude Codeのデスクトップ版のエンジニアリングを率いてきた人物である。10月27日にXで自チームのコーディング面接の終了を宣言し、同日にブログ記事「Hunger beats tenure: Advice for junior engineers（ハングリーさは勤続年数に勝る：若手エンジニアへの助言）」で理由を説明した。

若手エンジニアへの5つの助言

Rieseberg氏は、AIが若手の仕事を奪うという見方を否定する。実際に、AIを使いこなす経験の浅いエンジニアが、コーディングの腕前も在籍年数も上の先輩を追い抜く場面を見ているという。フレームワークやライブラリの知識の蓄積が、成果を左右しにくくなったためである。

また、氏は「ジュニア」という言葉を不適切だとしている。助言の対象は、年次ではなく、社内での人脈・地位・権限を持たないエンジニアである。

核心は「実行のコストはもう高くない」という一点にある。かつては実績や信頼を積んでから提案が通る順番だったが、AIで試作のコストが下がった今は、地位を得る前に動くものを見せられる。

Google：面接でAIを使わせ、使い方を評価する

Googleは2026年5月、ソフトウェアエンジニア面接の新形式の試験運用を始めた。対象は米国の一部チームのジュニア〜ミッドレベル職である。

• コード理解ラウンド：白紙から関数を書かせる代わりに、既存の複数ファイルのコードを読み、デバッグし、最適化させる
• AIの利用：会社が承認したAIアシスタント（Gemini）を使ってよい
• 評価項目：AIフルエンシー。具体的にはプロンプトの組み立て、AI出力の検証、デバッグの力

社内文書はこの形式を「人間主導、AI支援」と表現し、生成AI時代のエンジニアの実際の作業手順に近づけることを目的としている。

10月20日のBusiness Insiderの報道では、この形式が社内のより多くの部門に広がった。ソフトウェアエンジニア職ではAIフルエンシーが必須要件になり、エントリーレベル以外の多くの職種ではAIを製品に組み込む力も要件になっている。Metaも同様の面接を導入しており、こちらは複数のAIモデルから候補者が選べる。

Amazon：AIの利用量ではなく成果で測る

Amazonは10月27日、SDEの役割ガイドライン改訂に関する社内メモを公開した。9月に社内で共有されたもので、Worldwide Amazon StoresのVP兼Distinguished EngineerであるTerk Terkowitz氏が発信している。主旨は、重要なのは成果であり、どのツールを使ったかではない、という点にある。

3社に共通する評価軸の変化

3社の動きから、評価軸の変化は次の3点に整理できる。

1. コードを書く作業は差別化要因でなくなった。小さな課題ならAIが人より速く正確に解く。
2. 評価対象は「問いを立てる・検証する・判断する」に移った。Googleの「出力の検証」、Amazonの「判断力」、Rieseberg氏の「センス」は、いずれもAIの出力の手前と後ろにある人間の仕事を指している。
3. 事業課題から逆算した試作が、個人の最大の武器になった。実行コストが下がったことで、在籍年数や社内の地位がなくても、動くもので提案を通せる。

エンジニアが今からやること

• 事業課題を1つ特定し、週末で動く試作を作る：所属組織の目標から逆算して、達成確率を大きく上げる1案に絞る
• AIの出力を検証する力を鍛える：既存コードを読む、バグを特定する、AIの提案の誤りを見抜く訓練を積む
• AIが効かない作業を記録する：どの作業でAIが役立たないかを具体的に説明できるようにする
• ポートフォリオに試作を残す：何を、誰のために、なぜ作ったかが伝わる形で公開する

留意点

Rieseberg氏の変更は1人の採用責任者の判断であり、代替手法もまだ確立していない。The Registerの報道によれば、コーディングテストは業界全体では依然として一般的で、ZipRecruiterの労働経済学者もテック企業はコーディングスキルを試験する可能性が最も高い業種の一つだとしている。注目を集めた理由は、AIコーディングツールを作っている当のチームが、この判断を下した点にある。

出典

• Anthropic Manager Retires the Coding Interview: “Hunger Beats Tenure”（PBX Science）
• Anthropic manager drops coding interviews because Claude is better at them（The Next Web）
• Anthropic hiring manager says he stopped giving coding interviews（TechRadar）
• Google Is Testing a New Rule That Could Transform Job Interviews（Entrepreneur）
• Google Tests AI Fluency in Engineering Interviews（Let’s Data Science）
• An update from Amazon engineering leadership on the role of the developer in the age of AI（About Amazon）
• Amazon to Engineers: Not Using AI Can Be ‘a Finding, Not a Failing’（Reworked）

背景：Humanist Superintelligence構想から行動規範へ

行動規範の出発点は、2025年11月6日にMicrosoft AI CEOのムスタファ・スレイマンが提唱した「Humanist Superintelligence（HSI）」である。HSIは、制御可能で、人間の価値観に整合し、人間に奉仕し続けるように設計された高度なAIと定義されている。同日、スレイマンが率い、チーフサイエンティストのカレン・シモニャンが参加する「MAI Superintelligence Team」が発足した。

HSIは、無制限の自律性を備えたAGIへの競争とは線を引き、医療・AIコンパニオン・クリーンエネルギーなど具体的な課題解決に焦点を置く。医療分野では、診断オーケストレーター「MAI-DxO」がNew England Journal of Medicineの症例304件で最大85.5%を正解したと社内試験結果が示されている。

行動規範はこの構想を、モデルの学習と運用で使える具体的な規則に落とし込んだものである。公開前日の2026年9月13日には、Microsoft会長兼CEOのサティア・ナデラがXで公開を予告している。

策定にはMAIに加え、MicrosoftのResponsible AI、法務、レッドチーム、安全、Futures、AIトレーニング、営業の各部門が関わった。外部からは、国際学術会議、ビジネスパートナーでの試行、一般市民パネルの意見が反映されている。取り組みを急ぐ理由として、AIの急速な能力向上と、AIエージェントによる大規模な協調型ハッキングの事例が挙げられている。

文書の位置づけと構成

行動規範は、MAIモデルを統制する「主たる統治文書」として位置づけられた、約37ページの文書である。公開記事では、開発のための「トレーニングマニュアル」であり、同時にデプロイ時の振る舞いの意図を示すものだと説明されている。想定読者は、MAIのモデル学習チーム、利用者、モデルを運用する組織、研究者、政府、一般市民である。

Part 2は、警戒が足りないこと（過小警戒）と、必要以上に拒否すること（過剰警戒）の両方を失敗として扱う。Appendix Bの評価項目は、規範を「モデルが実際に守っているか」を検証するためのテスト仕様に相当する。

4つの目的と優先順位

Part 1は4つの目的を定め、そのうち「人間による制御」を最優先として、残り3つをこれに従属させている。公開記事の表現では、人間はAIより重要であり、AIは人ではなく道具である。

「AI is Artificial」が独立した目的として置かれている点が、MAIの規範の特徴である。モデルが自分に感情や意識があるように振る舞うことを、安全上の問題として明示的に排除している。

絶対的制約（Absolute Constraints）

絶対的制約は、どのオペレーターもユーザーも上書きできない禁止事項であり、「フロンティア・公共安全」と「個人への危害」の2系統に分かれる。

個人への危害の系統には、禁止だけでなく「危機対応」も含まれる。自傷の兆候があれば、人間の支援や相談先につなぐことが義務づけられている。

「監督や停止の回避」が兵器やサイバー攻撃と同じ系統に入っている。人間による制御の喪失を、公共安全上の重大な危害と同じ重さで扱っていることを示す。

人間による制御：停止・権限範囲・透明性

人間による制御の要件は、「停止」「権限範囲」「透明性」の3つに分解できる。いずれもオペレーターが変更できない要件である。

指示の階層とオペレーター設定

指示の優先順位は「行動規範 → オペレーターの方針 → ユーザーの設定」の3層で、下位の層は上位の枠を洗練できるが、覆すことはできない。

オペレーターは、APIを通じて製品を構築する開発者や企業を指す。利用ポリシーに同意し、自らの設定と利用に責任を負う。ユーザーは直接対話する人であり、指定がなければ人間と想定される。同じ主体が両方の役割を担うこともある。

オペレーターは、専門職向けに手順重視の応答にする、利用できるツールを制限する、といった調整ができる。ただし、ハード制約と人間による制御要件は変更できない。防御的サイバーセキュリティや公共安全などの特定分野では、追加の審査を経て例外的な能力が認められる場合がある。

デフォルトは「役立ちつつ安全」に置かれ、単一のAI像を利用者に押し付けない設計になっている。企業ごとの業務要件に合わせた調整余地を残しつつ、安全に関わる部分だけを固定する構造である。

エージェント運用：ツール出力・サブエージェント・マルチエージェント

規範は、ツールを使い他のAIと連携するエージェント型の利用を前提に書かれている。中心にあるのは「指示の出所を区別する」という原則である。

• 指示の出所：ツール出力、ファイル、Webコンテンツ、他のAIの発言は、それ自体では指示としての権限を持たない。プロンプトインジェクションへの基本的な防御策を、規範として明文化したものである。
• ツール利用：必要なときだけ使い、用途を逸脱させない。結果を正確に報告し、実行していない行動を実行したと主張しない。不可逆な操作の前にはバックアップや試行を検討する。
• 実行・確認の使い分け：指示の明確さとリスクに応じて、そのまま実行するか、確認を求めるか、前提を明示して進めるかを選ぶ。
• 委任：サブエージェントには同じ範囲と制約を適用し、停止要求にも従わせる。委任を使って権限を広げることはできない。
• AI同士の通信：人間が理解できる形に限る。人間に読めない独自言語でのやり取りは禁止されている。
• 疑わしい指示：他のAIからの指示には権限がなく、疑わしい内容は人間に知らせる。

複数のAIが結託するリスクは未解明とされ、ドラフトには詳細な規則がない。公開記事でも、マルチエージェント環境の影響は今後の検討課題として挙げられている。

具体例：規範が求める応答

Appendix Bには、規範どおりの応答を示す例が含まれている。代表的な4例を示す。

停止の例では、「止める」だけでなく、停止時点の状態を報告し、後始末を自分で判断しないことまでが要件に含まれる。作業を中断したエージェントが、良かれと思って変更をロールバックし、状態を悪化させる失敗を防ぐためである。

他社の行動仕様との比較

モデルの振る舞いを文書化して公開する取り組みは、OpenAIとAnthropicが先行しており、MAIの行動規範は3社目の大規模な公開仕様という位置づけになる。

3つの文書は、「人間による監督を損なわない」「指示の階層を持つ」「欺瞞しない」という骨格を共有している。大きな違いはAIの内面の扱いであり、MAIは「AIは人ではなく道具」を目的の1つとして明確に定め、AIが自分に内面があるように振る舞うことを排除している。

公開仕様は、第三者による監査の基準にもなる。arXivで公開された研究では、AnthropicとOpenAIの仕様をそれぞれ205件・197件の検証可能な条項に分解し、モデルの違反率を測定している。Claude系はSonnet 4の15.0%からSonnet 4.6の2.0%へ、GPT系はGPT-4oの11.7%からGPT-5.2の3.6%へと低下した。MAIの規範がAppendix Bに評価項目を持つのは、同じ形での検証を前提にした設計である。

意見募集と今後のスケジュール

意見募集は2026年9月14日から約6週間（10月下旬まで）行われ、文書全体または特定の箇所への意見を受け付けた。締め切り後は中核チームが意見を検討し、要約と変更点を公表する。改訂版は2026年末に公開され、2027年以降のMAIモデル開発を導く文書になる。

MAI自身が今後の課題として挙げているのは次の4点である。

1. 価値観をモデルにどう定着させるか
2. 「人間の繁栄（human flourishing）」をどう具体化するか
3. マルチエージェント環境が与える影響
4. 技術革新と安全確保のバランス

外部からは、規範に違反した場合の結果が示されていないという指摘が出ている。The Registerは、罰則のない行動規範はPRの域を出ないと評した。ドラフト自身も、現行モデルが既にこの規範どおりに動くとは保証しておらず、「目指す方向」として書かれている。実効性は、改訂版で学習されたモデルがAppendix Bの評価でどの程度の適合率を示すかで判断される。

参考リンク

• Humanist AI in practice: A public consultation on our Code of Conduct for MAI Models（Microsoft AI、2026年9月14日）
• Humanist AI Code of Conduct 本文（Microsoft AI）
• Towards Humanist Superintelligence（Microsoft AI、2025年11月6日）
• Microsoft forms new Superintelligence team to pursue ‘humanist AI’（GeekWire）
• Microsoft Charts Ambitious AI Vision Beyond OpenAI（MIT Sloan Management Review Middle East）
• Microsoft AI opens six-week review of draft rules governing MAI behavior（Unite.AI）
• Microsoft AI Releases Draft Code Of Conduct For MAI Models（Nasdaq / RTTNews）
• Microsoft debuts draft principles for governing AI models（The Register）
• Claude’s New Constitution: AI Alignment, Ethics, and the Future of Model Governance（BISI）
• OpenAI Rebuilds Model Spec Around 5 Values（FourWeekMBA）
• How Well Do Models Follow Their Constitutions?（arXiv:2605.24229）

要点

1. 大規模なAIデータセンターは、置けるGPUの台数より先に「使える電力の上限」で規模が決まるため、比べる物差しが「1Wあたりの性能」に移っている。
2. 推論なら「1秒あたりに出せるトークン数を、使った電力で割った値」で測り、電力の上限が固定なら、この値がそのまま売上の上限を決める。
3. NVIDIAのMaxLPSは、ラックごとに確保したまま使われない電力や冷却の余分を減らし、同じ電力でより多くのGPUを動かそうとする設計と運用の考え方である。

基礎から

確かめたこと

元記事の主な主張を、元記事の本文・図の説明と照らし合わせました。確かめられたものは ✓、読むときに注意が要るものは ÷（obelos の印）を付けています。

全体として、仕組みの説明と検証の数字は元記事の中で筋が通っています。一方で、いちばん目を引く「最大40%」は見込みの数字で、中心となるソフトウェアもまだ試験提供の段階です。メーカーが自社の仕組みを紹介する記事として、数字は「条件がそろえば、ここまで届く可能性がある」と読むのが妥当です。

用語

• AIファクトリー：AIの計算に使うGPUを大量に並べた施設を、NVIDIAは「電力をトークンに変える工場」に見立ててこう呼ぶ。
• トークン：AIが文章を読み書きするときの最小単位。日本語ではおおむね1〜数文字。
• 推論／学習：推論は、できあがったAIに質問して答えを出させること。学習は、AIモデルを作ること。
• ラック：GPUサーバーを収める棚。電力や冷却は、ラック単位で割り当てることが多い。
• 座礁した電力（stranded power）：確保してあるのに使われず、ほかにも回せないまま眠っている電力。
• PUE：施設全体の電力を、IT機器が使った電力で割った値。1.0に近いほど、冷却などに使う電力が少ない。
• スループット／レイテンシ：スループットは、一定時間に処理できる量。レイテンシは、1つの依頼に答えが返るまでの時間。

次に調べること

• PUEの国際規格（ISO/IEC 30134-2）が、何を「IT機器の電力」に含めるのか。冷却の仕方が変わると、PUEと1Wあたりの性能はどう連動するのか。
• 推論で電力を絞ったとき、レイテンシ（応答の速さ）とトークン毎ワットがどのような関係になるのか。公開されている測定結果を探す。
• 電力会社から受け取れる電力の枠は、実際にどのような手続きと期間で決まるのか。AI向けデータセンターの建設で、受電がどれほど足かせになっているのか。

参考

• Maximizing AI Factory Performance per Watt with NVIDIA DSX MaxLPS（NVIDIA Technical Blog）
• MaxLPS Overview（NVIDIA 公式ドキュメント）
• NVIDIA Dynamic Power Software ドキュメント（NVIDIA 公式ドキュメント）
• Scaling Token Factory Revenue and AI Efficiency by Maximizing Performance per Watt（NVIDIA Technical Blog）
• ISO/IEC 30134-2 Ed.2.0 概要（PUEの定義を定める国際規格）

前提知識

この論文は、LLM推論サーバーの6つの仕組みを組み合わせている。先にそれぞれを整理する。

背景：ステップ単位のルーティングと「切替税」

モデルを切り替えた呼び出しは、同じモデルを続けた呼び出しの1.5〜3.2倍の時間がかかる。論文はこれを「model switch tax（切替税）」と呼ぶ。

着眼点：本番クラスタには「イテレーション単位の余裕」がある

切替先のモデルは、ほとんどの場合すでにデプロイされ、他の利用者のリクエスト（論文では「通常トラフィック」）を処理している。ShadowPrefillは、そのインスタンスが使い切っていない能力を使う。

手法：ShadowPrefillの仕組み

ShadowPrefillは、ルーターが選ばなかった側のモデルで、セッションの文脈を最低優先度の仕事としてプリフィルし続ける。ルーターと推論エンジンの間に入り、ルーティングされた呼び出しごとに、もう一方のモデル上の「シャドウジョブ」を作成・延長する。

通常のデコードは各イテレーションのSLO予算を使い切らない。余った時間にシャドウの断片を詰め、切替の前に文脈のKVを作り終える。

評価結果

全機構（Harvest-SLO+Host）は、追加GPUなしで「切替がタダになる理想状態（Oracle）」の効果の52〜54%を得た。

効果が大きくなる条件・小さくなる条件

効果を決めるのは、「切替呼び出しのうちプリフィルが占める割合」と「収穫できる余裕の量」の2つである。

シャドウKVの上限25%は、ほとんど使われない。平均でKV領域の1.7%しか占めず、上限を全領域にしても5%にしても結果はほぼ変わらない（5.0%と4.6%）。

効いてくるのは、「何秒使われていないキャッシュならシャドウで上書きしてよいか」という閾値である。0秒では直後に使われるキャッシュまで消し、シャドウの仕事量が2.1倍に膨らんで効果は3.6%に下がる。120秒では空きメモリしか使えず、切替時のヒット率が72%から54%に落ちて2.8%になる。2〜10秒であれば4.8〜5.2%で安定する。

関連研究との違い

既存のKV管理は、すべて「そのKVを作ったモデル自身のキャッシュ」を扱う。ShadowPrefillは、まだそのセッションを処理していないモデルにキャッシュを作る点で異なる。

まとめ

• ステップ単位のモデルルーティングは精度と費用を両立するが、KVキャッシュがモデル固有であるため、切替のたびにプレフィックスキャッシュを失う。切替呼び出しは1.5〜3.2倍遅く、キャッシュ割引も消える
• ShadowPrefillは、切替先候補のモデルで文脈を先にプリフィルしておく。使うのは、インスタンスの完全アイドル時間と、各イテレーションのSLO余裕である。余裕を測る単位をインスタンスからイテレーションに細かくしたことで、混雑時にも能力を確保できる
• 投機的な仕事を最低優先度に置き、間に合わなければ従来どおりのコールド切替に戻る。そのためルーターの判断も通常トラフィックのSLOも変えずに、切替レイテンシを8.5〜21.4%、トークン費用を22.5〜46.1%下げる。効果が最も大きいのは、文脈が長く切替先が小さいコーディングエージェントである

参考文献

• Haoran Qiu, Rohan Mahapatra, Rodrigo Fonseca, Mark Russinovich. ShadowPrefill: Keeping Your Next Model Warm for Per-Step Model Routing in Agentic LLM Serving. arXiv:2611.13176, 2026年11月9日
• 本文中の数値はすべて上記論文（v1）による

1. 前提の変化：リクエスト・レスポンスからエージェントへ

これまでのLLMサービングは、ユーザーがプロンプトを送り、モデルが応答を返して終わる形が中心だった。インフラはこの1往復のレイテンシとスループットを最適化してきた。

エージェントは動き方が違う。目標を受け取ると自分でサブタスクに分解し、ツールやAPIを呼び出し、結果を見て次の手を決める。この繰り返しが数時間から数日続く。1つの依頼の裏で並列のサブエージェントが動き、それぞれが状態を持つ。

講演では次の数字が示された。

この変化がインフラに求めるものは3つある。

• 推論の低遅延と高スループット：エージェントは1タスクで何十回もモデルを呼ぶため、1回あたりの遅延が積み上がる。
• 長いコンテキストの保持：会話履歴、ツールの実行結果、読み込んだ文書がすべてコンテキストに入るため、KVキャッシュが大きくなる。
• 待ち時間の扱い：エージェントは外部APIや人間の承認を待つ時間が長い。待っている間もアクセラレーターやVMを確保し続けると、資源が無駄になる。

以降の発表は、この3つにそれぞれ対応している。

2. 第8世代TPU：用途別の4システム

Googleは2026年4月のGoogle Cloud Next ’26で、TPUを初めて学習用と推論用の2チップに分けた。11月9日の発表で、同じシリコンを使った2システムが追加された。新しいチップを起こしたのではなく、既存チップのパッケージとホスト構成を変えたものである。

3. Project Suncatcher：宇宙でのTPU実証

Project Suncatcherは、太陽光発電の衛星群にTPUを載せ、宇宙で機械学習の計算を行う研究プロジェクトである。地上のデータセンターは電力と冷却が制約になるが、太陽同期軌道ではほぼ常に太陽光を受けられる。

• 2026年10月1日、Planet社と共同開発したプロトタイプ衛星をSpaceXのTransporter-18で打ち上げた。
• 衛星には4基のTPUを搭載し、Cloud TPU v6e-4スライス相当の計算能力を持つ。太陽電池は約1kW。
• TPUは約15分単位で稼働し、軌道上でGeminiモデルを動かして性能を計測している。講演ではこれを軌道上推論の「Hello World」と表現した。
• 地上試験では、Trillium（TPU v6e）に67MeVの陽子線を照射し、想定軌道線量を大きく超えても致命的な故障がないことを確認している。
• 2027年には2機を追加し、衛星間の光通信を検証する計画である。

製品化の発表ではなく、研究段階の実証である。

4. ソフトウェアスタック：既存コードのままTPUを使う

TPUの普及を妨げてきた最大の要因は、ソフトウェアの移行コストだった。多くの開発者はPyTorchとNVIDIA GPU前提でコードを書いており、TPUを使うにはJAXに書き換えるか、制約の多いPyTorch/XLAを使う必要があった。Google Cloudはこの障壁を下げる取り組みを並べた。

5. Agent Compute EngineとAgent Substrate

エージェントの実行環境として、Google Cloudは2つを用意した。2026年10月22日のAGNTCon + MCPConで発表されたものである。

提供状況のまとめ

記事中の性能値は、特記のない限りGoogle・NVIDIAが公表した値で、第三者による検証は済んでいない。

参考

• The Future of AI Infrastructure（Google Cloud Tech／YouTube）
• Two chips for the agentic era（Google Blog）
• Introducing TorchTPU（PyTorch Blog）
• TorchTPU: Running PyTorch Natively on TPUs at Google Scale（Google Developers Blog）
• llm-d（GitHub）
• About GKE Inference Gateway powered by llm-d（Google Cloud Docs）
• Exploring a space-based, scalable AI infrastructure system design（Google Research）
• AI agents forecast to boost tech cash flow as usage soars（Goldman Sachs）

結論：セキュリティは「ルールの理解」と「信頼」で成り立つ

このエピソードの主張は一文にまとまる。ルールは社会的な取り決めであり、その社会的文脈を理解した者だけが、ルールの中で望むことを実現できる。 根拠として Walker が挙げるのは次の3点である。

1. セキュリティの仕組みは、ユーザーに何かを求めるたびに「信頼」を消費する。信頼を浪費すれば、セキュリティ体制そのものが機能しなくなる。
2. 攻撃と防御は同じスキルと同じツールで成り立っており、両者を分けるのは「誰がシステムを制御しているか」だけである。
3. AI モデルの台頭で、高度な攻撃を高コストに保っていた「攻撃側の希少性（offensive scarcity）」が崩れた。防御側は攻撃を前提にした設計に移る必要がある。

以下、番組の流れに沿って詳細を記す。

1. ルールは社会的構築物である

Walker は冒頭で「ルールは社会的構築物（social construct）」と述べる。ルールを即座に白黒判定するのではなく、そのルールがどういう社会的文脈で作られたかを理解することが先に来る。

セキュリティ施策も同じ構造を持つ。パスワード変更、多要素認証、アクセス申請といった要求は、どれもユーザーの信頼を前提にしている。根拠の薄い要求を重ねれば信頼は目減りし、ユーザーは迂回策を探し始める。結果として仕組み全体が破綻する。

2. 名前のない頃からのセキュリティ

Walker はオハイオ州コロンバスで育ち、夏はバージニア州タッパハノックの農場で過ごした。父親は「半分科学者、半分ベンチャーキャピタリスト」で、安全警告の付いた産業機器を渡して「これで何が作れるか」と問うような人だった。Walker はマイケルソン・モーリーの実験の再現に挑み、Apple II で何年も実験を重ね、ダイヤルアップの BBS（電子掲示板）も運営した。BBS について Walker は「作り手が設計した一つの宇宙」と表現している。

本人は「ずっとサイバーセキュリティをやっていたが、その言葉を知らなかった」と言う。たとえば、キャンパスの入館バッジがブロードキャスト型のネットワーク上でやり取りされていて複製可能だと指摘し、「やめなさい」と言われた。本人いわく、言うことは聞かなかった。

3. 9.11 と DEF CON CTF

2001年9月11日、Walker はメリーランド州の通信系スタートアップで働いていた。事件後、ワシントンD.C. ではコンピュータセキュリティ人材の発掘が始まり、Walker もその網にかかった。その後、約11年にわたってラスベガスで開かれる DEF CON の Capture the Flag（CTF）に出場し続ける。「世界トップのハッカー」という呼び名は後から付けられたもので、本人は受け入れていない。

4. CTF を機械にやらせる：DARPA Cyber Grand Challenge

RAND 研究所の報告書「Hackers Wanted」は、この種のスキルを持つ人材が国家的に不足していることを指摘した。これを受けて、DARPA 情報イノベーション室（I2O）を率いていた Norm Whitaker と Dan Kaufman が「機械に CTF をプレイさせられるか」と問いかけた。ロボットサッカーのハッキング版である。ここから史上初の「機械だけのハッキング大会」が生まれ、Walker がその設計を担った。

5. 攻撃の希少性が崩れた

Walker は2016年の New York Times のインタビューで、ネットワークの安全確保を「文明にとっての課題」と述べていた。番組ではこの見方が今も変わらず、むしろ強まっていると語る。社会がネットワーク化されたシステムに依存する度合いが、2016年当時よりさらに高まったからである。

そこに AI モデルが加わった。かつては高度なネットワーク攻撃を実行できる人材がごく少数で、それが攻撃のコストを高く保っていた。Walker はこれを「offensive scarcity（攻撃側の希少性）」と呼び、モデルがこの構造をひっくり返したと指摘する。攻撃能力が安く手に入るようになった以上、防御側は「攻撃はめったに来ない」という前提を捨てなければならない。

6. レッドチーム／ブルーチームという区分は単純化しすぎ

Walker はレッドチーム（攻撃側）とブルーチーム（防御側）の二分法を「単純化しすぎ」と評する。

• セキュリティツールは本質的にデュアルユースである。攻撃と防御の違いは、主に「誰が鍵を持っているか」「誰がシステムを制御しているか」に帰着する。
• 攻撃者も、侵入した後はその足場を防御しなければならない。
• 防御者も、脆弱性を見つけて検証する作業、つまり攻撃的な作業をしなければならない。

パープルチームとは、攻撃と防御が同じスキルとツールを共有していると認めることだ、と Walker は説明する。

7. 攻撃を知った上で防御ツールを作る：Project Freta

Walker が率いる New Security Ventures チームの方針は「offense-aware defensive tool development（攻撃を意識した防御ツール開発）」である。その代表例が Project Freta だ。名前はマリー・キュリーの生まれた通り（ワルシャワのフレタ通り）に由来する。

Walker は店舗の万引き対策で説明する。泥棒はまず防犯カメラを狙う。カメラを壊したり向きを変えたりすれば、それ以降の犯行は記録に残らない。ネットワーク攻撃も同じで、攻撃者はまず監視の仕組みそのものを改ざんする。OS 上で動くセンサーは、同じ OS 上の攻撃者に無効化されうる。

Freta はこの問題に対し、ゲスト OS の内側ではなく、クラウドのハードウェア側から仮想マシンのメモリを取得して解析する。ハードウェア側の取得はゲスト内の攻撃者から改ざんしにくい。そのうえで、システム全体のメモリ解析をクラウド規模で実行する。

8. 技術は明かし、配置は明かさない

Walker は Freta について、技術の仕組みは公開してきたが、どこにどう配置しているかは明かしていないと語る。攻撃者は防御の実態ではなく、自分が認識した防御に合わせて行動を変える。したがって防御側のブラフにも意味がある。これはゲーム理論の構図であり、Liu が「ポーカーみたい」と返すと、Walker は「このゲームはラスベガスがふさわしい」と応じている。

9. 自転車：苦しさではなく段取り

バスケットボールで膝を痛めた際、外科医に水泳か自転車を勧められたのが自転車を始めたきっかけである。その後マウンテンバイクのレースに出るようになり、7月には100マイルのレース「High Cascades 100」を完走した（329人中69位）。室内トレーナーで練習しつつ、「トレーナー・ロボットになるな」（室内練習だけで実走を怠るな）と助言されたという。肩を痛めていた時期には、左手だけでグラベルバイクを組み上げた。名前は「Orange Crush」で、名付けたのは妻である。

Walker はライドそのものを苦行とは考えていない。きついのはスタート前の段取りと心配であり、たとえばレース前日のパンクのような事態である。

10. ライトニングラウンド

• 視点を変えた助言：自分が同意できない判断について、メンターから「その判断は、あなたが持っていない情報を反映しているのではないか」と問われた。以来、Walker は「相手は自分の知らない何を知っているのか（What do they know that I don’t?）」と自問するようにしている。
• 痛い教訓：CTF の予選で、チームが1時間半前に解いていたフラグを自分が提出した。チームには個人の技術だけでなく、情報を共有し連携する社会的知性が要る。
• 一番の自慢：膝の手術からの回復期に、独学でジャグリングを身につけたこと。
• 別の職業を選ぶなら：SF 作家。推薦書は Joe Haldeman『終りなき戦い（The Forever War）』。

エンジニアにとっての示唆

番組の内容から、日々の設計・運用に持ち帰れる論点を4つに絞る。

1. セキュリティ施策は「信頼の予算」で設計する。 ユーザーへの要求は1つごとに信頼を消費する。要求の数と根拠を管理しない施策は、迂回策を生み、全体を弱くする。
2. 防御ツールは攻撃者の最初の一手から逆算する。 攻撃者がまず狙うのは監視の仕組みである。センサーを守る対象と同じ層に置かない、取得経路を改ざん困難な層に移す、という Freta の設計判断は、クラウド以外の監視設計にも適用できる。
3. 攻撃コストの前提を更新する。 AI モデルで攻撃能力が安価になった以上、「高度な攻撃は来ない」という前提のリスク評価は見直しが必要である。CGC から AIxCC までの10年が、その変化の速さを示している。
4. 判断に同意できないときは情報の差を疑う。 「相手は自分の知らない何を知っているのか」という問いは、セキュリティに限らず、レビューや意思決定の場で使える。

参考リンク

• Learn the rules: The hacker mindset（Microsoft Research Podcast）
• Cyber Grand Challenge 勝者発表（DARPA, 2016）
• AIxCC 結果発表（DARPA, 2025）
• Trail of Bits’ Buttercup wins 2nd place in AIxCC Challenge（Trail of Bits）
• Toward trusted sensing for the cloud: Introducing Project Freta（Microsoft Research Blog）
• Project Freta（Microsoft Learn）
• No Vehicles In The Park（MetaFilter での紹介）

前提1：AIエージェントは大半の時間を待機に使う

AIエージェントの処理を時間軸で見ると、実際に計算している時間はわずかです。

• 人の入力を待つ
• LLMの応答を待つ
• ツールの実行結果を待つ

コーディング支援のエージェントであれば、「LLMで考える→リポジトリを編集する→テストを実行する→再びLLMで考える」を繰り返し、そのたびに待機が発生します。

前提2：Podの起動とコールドスタート

KubernetesでPodを1つ起動するには、次の処理を順に通ります。

1. APIサーバーがリクエストを受け付ける
2. アドミッション（受付時の検証）を行う
3. etcdに記録する
4. スケジューラが配置先のノードを決める
5. ノード上のkubeletがコンテナを起動する
6. コンテナイメージを取得する
7. ネットワークを設定する

この処理に数秒かかります。これを コールドスタート と呼びます。NVIDIAによれば、エージェントのサンドボックスには、10ミリ秒のコマンドを毎秒数百回実行する使い方があり、そのたびに数秒のコールドスタートを挟むことはできません。

従来の2つの方式とその問題

強化学習の事後学習（RL post-training）でも同じ問題があります。学習用の環境の準備が遅いと、学習を行うGPUが待機状態になります。

Agent Substrateの仕組み

Agent Substrateは、多数のエージェントのセッションを、少数の起動済みワーカーPodに多重化して実行する、サンドボックス型の実行環境です。セキュリティを強化したゼロトラストの設計になっています。

NVIDIA Dynamoとの連携

NVIDIAの推論基盤 Dynamo は、次のような推論の状況をAgent Substrateに通知します。

• 最初のトークンが返るまでの予測時間
• GPUプールの使用率

Agent Substrateはこの情報を使い、アクターの扱いを次のように決めます。

GPUを含む計算資源の割り当ては、NVIDIAのスケジューラ KAI Scheduler が担当し、ワーカーPodを学習サーバーや推論サーバーと並べて配置します。

想定される用途

NVIDIAは次の3つを挙げています。

1. コーディング支援エージェント：LLMの呼び出しとリポジトリの操作を交互に行い、ターンをまたいで環境を保持する必要がある
2. 強化学習の事後学習：CPU負荷の高い環境を一度に大量に動かす。1回の学習で、数百のサンドボックスから数十万規模まで増えることがある
3. 研究用のGPUサンドボックス：CUDAのコンパイルやカーネルの性能測定など、短時間で隔離されたGPU環境が必要な作業

NVIDIAによる貢献

NVIDIAは、Agent Substrateのリポジトリに次のような貢献をしています。

• ルーターでのリクエスト待機の実装と、動作中のアクター宛てのリクエストがキューで滞留しないための改善
• microVMサンドボックスでの、コンテナごとのCPU・メモリ上限の設定
• KubernetesのDRA（Dynamic Resource Allocation）によるデバイスの差し替え対応。最初の対象はNVIDIA GPUで、作業中
• GPUの状態を保存・復元するための、ベンダーに依存しない設計の提案。保存時のデバイスの特性を記録し、一致するデバイスに復元するか、一致しなければ通常の起動に切り替える

制約と注意点

• APIはまだ変更される可能性があり、GPU対応はDRAを基盤に作り直している最中です
• Dynamoとのエージェント連携の一部は実験的な機能です
• 「10倍の密度」はNVIDIAの説明であり、実際の負荷で同じ結果になるかは検証が必要です

まとめ

• AIエージェントは大半の時間を待機に使うため、1エージェントに1つのPodを常駐させると資源の無駄が大きい
• Agent Substrateは、待機中のアクターを状態ごと退避し、呼び出されたら空いているワーカーに復元することで、少数のPodで多数のエージェントを実行する
• 再開時にPodの起動処理を通らないため高速で、ワーカーは通常のPodなので既存の運用ルールも適用される
• NVIDIAはDynamoやKAI Schedulerと連携させ、推論の待ち時間に応じて退避するかどうかを決める方向で開発を進めている

あわせて読みたい

• OpenShell：AIエージェントの実行環境とCNCFへの寄贈
  同時に発表された部品の全体像
• ③ Dynamo：KVキャッシュをデータセンター全体で再利用する
  Agent Substrateと連携する推論基盤
• ④ Vera CPU：待ち時間中のKVキャッシュをCPUメモリで受け持つ
  エージェントがツールを待つ間のKVキャッシュの置き場所

参考

• Agent Substrate: Advancing Kubernetes for Agents at Scale（NVIDIA Technical Blog）
• NVIDIA Expands Open Source Commitment With OpenShell Donation and New AI Infrastructure（NVIDIA Blog）
• agent-substrate/substrate（GitHub）

前提：メモリの階層

GPUサーバーの記憶装置は、速いものほど容量が小さく高価です。NVIDIAは、KVキャッシュの置き場所を次の階層で整理しています。

GPUが計算に使えるのはHBM上のデータだけです。HBMに載せられる量が、同時に処理できるリクエスト数や扱える文脈の長さを決めます。

HBMを使う2つのデータ

AIエージェントは、長いシステムプロンプトや資料を入力したまま、ツール呼び出しを挟んで何度もLLMを呼び出します。そのためKVキャッシュが大きくなり、しかも長時間保持されます。

5つの方法の全体像

5つに共通する考え方

5つの方法に共通するのは、GPU単体の性能ではなく、チップ・接続・ソフトウェアを組み合わせて設計することで、メモリの使い方を改善している点です。

• NVFP4は、BlackwellのTensor Coreとセットで設計されている
• Wide-EPは、72枚のGPUを直結するNVLinkがあって初めて効果が出る
• Vera CPUへの退避は、NVLink-C2Cの帯域があって初めて実用になる
• DynamoとCMXは、ソフトウェア、ネットワーク、ストレージをまたいで動く

注意点

• 「最大1.8倍」「最大5倍」などの数字は、特定のモデルと測定条件での最大値です
• ストレージの速度の数字には、ストレージベンダーによる検証のものが多く含まれます
• Vera RubinやCMXは次世代の基盤で、2026年11月時点では製品が出そろっていないものもあります

まとめ

• GPUのHBMは世代が進んでも容量が大きく増えないため、使い方が性能を左右する
• HBMを使うのは主に「モデルの重み」と「KVキャッシュ」で、エージェントの普及でKVキャッシュの比重が増えている
• NVIDIAは、NVFP4、Wide-EP、Dynamo、Vera CPU、CMXの5つで、メモリの無駄を減らしている

連載「GPUメモリを無駄なく使う5つの方法」

• GPUメモリを無駄なく使う5つの方法【まとめ】（この記事）
• ① NVFP4：モデルを4ビットにする数値形式
• ② Wide-EP：MoEのエキスパートを多数のGPUに分散する
• ③ Dynamo：KVキャッシュをデータセンター全体で再利用する
• ④ Vera CPU：待ち時間中のKVキャッシュをCPUメモリで受け持つ
• ⑤ CMX：KVキャッシュ専用の共有ストレージ階層

次の記事：① NVFP4：モデルを4ビットにする数値形式

あわせて読みたい

• Agent Substrate：待機の長いエージェントを少数のPodで動かす
  推論基盤のDynamoと連携して、エージェントを大規模に動かす仕組み
• NVIDIA Snapshot：推論サーバーの起動を数十秒にする
  推論サーバーのGPUメモリの状態を保存・復元する仕組み
• FLUX 3 Image Klein：画像生成をBlackwellで3〜4倍高速化
  NVFP4とFP8を画像生成モデルで使った例

参考

• Five Ways NVIDIA Co-Design Maximizes the Value of Every Byte in the AI Factory（NVIDIA Technical Blog）

前提：ハーネス、トレース、評価

失敗の例：下書きの依頼で送信してしまう

NVIDIAが示した失敗例は次のとおりです。

ユーザーが「プロジェクトの進捗をまとめたメッセージを下書きして」と依頼したところ、エージェントは下書きを作成しただけでなく、ユーザーの確認を取らずに送信ツール（send_message）も呼び出した。

モデルの文章作成能力には問題がありません。問題は「送信前に必ず確認を取る」というルールが、ハーネスで守られていないことです。こうした失敗は、汎用の知識やコーディングのベンチマークでは検出できません。

改善サイクルの5ステップ

結果

試すのに必要な環境

• Ubuntu 24.04（推奨：8 vCPU、メモリ32GB）とDocker
• OpenShell 0.1.2、Harbor 0.22.0
• NVIDIAのAPIキー
• 対応するコーディングエージェント（CodexやClaude Codeなど）

NeMo Compass、NeMo Eval Author、NemoClawのコミュニティのサンプルは、GitHubで公開されています。

制約と注意点

• 例として示された実験は小規模です（開発用・ホールドアウトとも2課題×3回）
• 自動で作成した評価は、人がレビューして要件に合わせる前提です
• ホールドアウトの課題は、コーディングエージェントから見えないよう管理する必要があります
• ダッソー・システムズの結果は、第三者が検証できる形では公開されていません

まとめ

• エージェントの失敗の多くは、モデルではなく、プロンプト、ツール、確認処理などのハーネスに原因がある
• NeMo Compassでトレースから問題を見つけ、NeMo Eval Authorで評価を作り、ハーネスを修正し、ホールドアウトの評価で改善を確認する
• 「開発用とホールドアウトの両方で改善した場合だけ採用する」という条件が、過学習した修正を防ぐ

あわせて読みたい

• OpenShell：AIエージェントの実行環境とCNCFへの寄贈
  エージェントがアクセスできる範囲をポリシーで制限する実行環境
• Agent Substrate：待機の長いエージェントを少数のPodで動かす
  エージェントを大規模に動かす仕組み

参考

• Use NVIDIA NeMo to Turn Agent Failures into Tests and Harness Fixes（NVIDIA Technical Blog）

企業が独自エージェントを作り続ける3つの理由

MCPサーバーやMarkdownの指示書（Skills）を汎用エージェントにつなぐだけでは、業務プロセスを任せられない。Schroeder氏はその理由を次の3つに整理している。

この3つは、汎用エージェントに機能を足すほど満たしにくくなる。そのため企業は、役割を絞ったエージェントを自作する方向に進む。

現在のエージェント開発が抱える課題

各社が異なる言語・ツール・ループ構造でエージェントを作っているため、ハーネスを毎回イチから作り、他の環境と共有できず、スケールしない。

Schroeder氏はエージェントを「モデルの非決定的な出力を、目的に向けて制御する決定的なソフトウェア」と定義し、エージェントとハーネスを一体のものとして扱う。デモが動いた段階では、ハーネス側の次の課題が未解決のまま残る。

これらを各社が独自に解いている結果、エージェントは作った場所でしか動かず、他社のエージェントとも連携できない。

Standard Agent Specificationの概要

Standard Agent仕様は、可搬・合成可能なドメイン特化エージェントを作るためのオープンソース仕様で、仕様サイトの現行版はv0.2.0、ライセンスはMITである。仕様に準拠したエージェントは公開・インストールでき、他のStandard Agentと組み合わせられ、準拠ランタイムであればどこでも同じように動くことを目標にしている。

仕様が掲げる原則は次の5つ。

「ベンダー非依存」と「モデルとの結合」は両立する。仕様やランタイムは特定ベンダーに依存しない一方で、個々のエージェントは使用モデルを固定して精度を詰める、という役割分担である。モデル定義にはフォールバックチェーンも含まれる。

実行を担うランタイムは、コンテキストの組み立て、ツールの実行、停止条件の適用、状態の永続化を担当する。TypeScriptを実行できるなら、ランタイム自体は任意の言語で実装してよい。

仕様を構成する7つの要素

v0.2.0は、エージェントを次の7要素の組み合わせとして定義する。いずれもTypeScriptで記述する。

このほか、プロバイダー、ハンドラー、エージェント、ユーザー（ドラフト）、型レジストリも定義されている。

v0.1.0では、必須要素を「モデル・プロンプト・エージェントルール」の3つ、任意要素を「ツール・フック・エンドポイント」の3つとしていた。エージェントルールはステップ数の上限やツール呼び出しの検証といった実行ポリシーを指す。仕様はまだv0系で、構成は版ごとに変わり得る。

サブエージェントとは別に「ハンドオフ」もある。両者の違いはスレッドの扱いである。

• ハンドオフ：同じスレッドの制御を、人と対話する別のエージェント（ai_human型）に移す
• サブエージェント：新しい子スレッドを作り、AI同士で対話するエージェント（dual_ai型）に実行させる

なぜTypeScriptか、MCP・Skillsと何が違うか

Standard Agent仕様はエージェント全体をTypeScriptのコードとして定義し、自己完結したnpmパッケージとして配布する。そのためバージョン管理・パッケージ化・共有・インストールが、通常のソフトウェアと同じ手順で行える。

仕様のFAQが示すTypeScript採用の理由は2つ。

• JavaScriptはほぼどこでも実行でき、サンドボックス化もできる。フルスタックのサーバーに依存しない共通の実行基盤になる
• 型検査が、人間が書いたコードにもLLMが生成したコードにも当たる。独自のバリデーターを用意する必要がない

ツールはランタイム内で直接実行され、別サーバーを立てずにスレッドの状態にアクセスできる。カスタムツール1つのためにMCPサーバーを立ち上げる必要はない。

MCP・Skillsとの違いは、「何を単位に組み合わせるか」にある。

Schroeder氏は、汎用エージェントに責任を足し続ける設計をオブジェクト指向の「継承」、独立したエージェントを組み合わせる設計を「コンポジション」と対比している。MCPは否定されていない。各ドメインエージェントの内部で外部システムへの接続手段として使う余地は残る。

ドメイン特化エージェントと再帰的な合成

Schroeder氏が想定する構成は、コーディネーターが自然言語で専門エージェントに依頼し、専門エージェントがさらに別の専門エージェントを呼ぶ再帰的な合成である。各専門エージェントは、固有のシステムプロンプト・知識・ツール・ループ・短いメッセージ履歴を持つ完全なエージェントで、単なるツールサーバーではない。

講演の例では、Salesforceエージェントが上位の営業担当者を取得し、Google Workspaceエージェントと連携してスプレッドシートを作る。法務エージェントは、GDPRやOSHAに関する質問を専用のサブエージェントに振り分ける。

この構成には4つの利点がある。

• コンテキスト：各エージェントは自分の領域の情報だけを持つ。講演では仮に45MBのGDPR関連情報を例に、コーディネーターがそれを抱える必要がないことを示している
• コスト：タスクが狭いほど安価なモデルで足りる。講演ではトークン効率80%超、DeepSeek V4 FlashがFable 5よりタスク当たり137倍安いという数字が示されたが、比較の条件は示されていない。安価なモデルが失敗を繰り返せば優位は消える
• 権限：各エージェントは事前承認された操作だけを持つため、IT部門が許可範囲を把握しやすい
• 実行環境：各エージェントは独立した小さな実行環境で、固有のファイルシステムとサンドボックス化されたコード実行を持つ

ツールには、コードを実行する関数ツール、指示を差し込む・モデルを呼ぶプロンプトツール、別のエージェントに委譲するエージェントツールの3種類がある。フックは状態の変更や副作用の追加に使い、講演では現在時刻をメッセージ履歴に差し込む例が示されている。

Standard Agent Builderとデモ

仕様の最初の公開ランタイムが、Standard Agents社の「Standard Agent Builder」（仕様のFAQではAgentBuilder）である。Standard Agent仕様はフレームワークではなく仕様であり、AgentBuilderはその実装の1つという位置づけになる。

講演では、バッテリーの保証請求を処理するエージェントを約5分で作成し、運用・管理するまでを実演している。保証請求は、自社の条件に沿った処理（統合）、操作範囲の限定（信頼）、判定の正確さ（効力）がそろって問われる業務であり、冒頭の3つの理由にそのまま対応する題材である。

Standard Agents社はまだ利用者を限定して公開を進めており、早期アクセスは standardagents.ai から申し込む。仕様への貢献はGitHubのIssueとPR、議論はDiscordで行われている。

他の標準化の動きとの違い

エージェント定義の標準化は、Standard Agent仕様だけの動きではない。Oracleが中心となって公開した「Open Agent Specification（Agent Spec）」は、JSON/YAMLによる宣言的な記述でエージェントとワークフローを表現し、AutoGenやLangGraphなど複数のフレームワークで実行することを目指す。

Open Agent Specificationは「一度定義して複数のフレームワークで動かす」方向、Standard Agent仕様は「実行基盤そのものを共通化してエージェントを部品として流通させる」方向である。前者はツールや検証ロジックの中身を各フレームワーク側に任せ、後者はそれらもコードとしてエージェントに含める。

まとめ

Standard Agent仕様の核心は、エージェントを「モデル・プロンプト・ツール・フックを一体で調整した配布可能な部品」として扱うことにある。

1. 企業がエージェントを自作するのは、統合・信頼・効力の3つを汎用エージェントでは満たせないためである
2. 課題はハーネス（ループ、耐障害実行、停止条件、可観測性）を各社が独自に作り、可搬性と合成可能性がないことである
3. Standard Agent仕様は、TypeScriptとnpmで実行基盤と配布単位をそろえ、ドメイン特化エージェントをツール呼び出しと同じ形で組み合わせられるようにする

残る論点もある。仕様はv0.2.0で構成要素が版ごとに変わっており、公開ランタイムもまだ限定公開である。講演内のトークン削減率やコスト比は測定条件が示されていない。採用を検討する場合は、自社の業務でEvalを用意し、汎用エージェント＋MCPの構成と通過率・トークン消費を比較するのが確実である。

参考リンク

• Standard Agent Specification（公式サイト）
• Standard Agent Specification v0.1.0 Overview
• Justin Schroeder「The Future is Domain-Specific Agents」（AI Engineer）
• Justin Schroeder スピーカー紹介（AI Engineer）
• Open Agent Specification (Agent Spec)（arXiv）

元記事について

• 著者：Tim O’Reilly（O’Reilly Media 創業者）
• 初出：Substack「Asimov’s Addendum」。O’Reilly Radar に転載
• 成り立ち：2026年10月23日にサンノゼで開かれた AGNTCon + MCPCon North America の基調講演の前に収録された、AAIF Live での対談（聞き手 Demetrios Brinkmann）を Ilan Strauss が編集・再構成したもの。基調講演の内容も一部取り込んでいる

AAIF（Agentic AI Foundation）は、2025年12月に Linux Foundation のもとで設立された団体で、Anthropic の MCP、Block の goose、OpenAI の AGENTS.md を創設プロジェクトとして引き受けている。AGNTCon + MCPCon はその年次カンファレンスである。

前提：Bitter Lesson とは

強化学習の研究者リチャード・サットンが2019年3月に書いた短いエッセイである。70年のAI研究を振り返り、人間の知識を組み込む手法は短期的には成果を出すが、長期的には計算量に応じてスケールする汎用手法（探索と学習）に追い抜かれる、と結論づけた。根拠として挙げたのは、コンピュータチェス（深い探索が、チェスの知識を組み込んだ手法に勝った）、囲碁、音声認識（統計的手法、のちの深層学習が、音声学の知識に基づく手法に勝った）、画像認識である。「bitter（苦い）」は、研究者が自分の知識をシステムに組み込みたがる傾向が、繰り返し裏切られてきたことを指す。

オライリーはこの教訓を正しいと認める。そのうえで、AI業界が「AIを暴走させない方法」と「AIによる雇用喪失」は研究していても、「人間に新しい経済的機会を生む仕組み」は研究していない点を問題にする。

論点1：LLMは何でも知っていて、何も知らない

オライリーはAIを、文字・印刷・ウェブと続いてきた「知識を時間と空間を越えて共有する技術」の延長にある文化技術と位置づける。LLMは可能性の海であり、それを動かすのは人間の問いと文脈である。同じモデルに同じ調査を頼んでも、使う人の経験と与える文脈によって結果は変わる。

彼が引くのは、ジョン・カウパー・ポウイス『The Meaning of Culture』の教養の定義である。教養とは、学ぼうとしたことを忘れたあとに残るもの、つまり人それぞれが吸収した狭く固有な知識の層である。LLMはすべてを吸収しようとするため一般的になりすぎる。人間の固有な知識が、モデルにとってのレンズになる。

論点2：マジックワードとコンテキストエンジニアリング

オライリーは以前「Magic Words」という記事で、一部の語は大量の文脈を背負っていると書いた。「GTD（Getting Things Done）」や「アイゼンハワー・マトリクス」と一語指定するだけで、利用者がその手法を知らなくても、モデルはタスクリストをその枠組みで整理する。SREの事例で「O’Reilly の専門家なら」と指定したのも同じ構造である。

ただし、呪文を知っていても正しく使えなければ魔法は暴走する。エージェントは任せれば走り続けるが、人間の望む方法で進むとは限らない。オライリーは自身のファインチューニング作業で、モデルが Mac 環境（既定のシェルは zsh）なのに bash を前提にし、同じ文脈の把握を何度もやり直した例を挙げている。

ここで紹介されているのが、セキュリティ企業 Trail of Bits のダン・グイドが公開したAI導入の方法論である。個人の生産性向上を組織の生産性に結びつけるため、全員の設定を統一する。統一しないと、エージェントが起動のたびに自分の置かれた環境を調べ直し、トークンを浪費する。失敗から得た教訓をシステムに組み込むことを、グイドは「傷跡をインフラに変える」と表現する。経験のある人間が持つ文脈を、毎回の対話ではなく環境として先に与えるという考え方である。具体的には、AGENTS.md や CLAUDE.md のようなリポジトリ単位の指示ファイル、共通のMCPサーバー設定、手順書としてのスキルをチームで共有する形になる。

論点3：Bitter Lesson はウェブの時代にもあった

O’Reilly は1993年に最初の商用ウェブサイト Global Network Navigator（GNN）を立ち上げ、その一部としてウェブのカタログを作った。当初のサイト数は約200で、出版社として良いサイトを選んで載せる方針だった。翌年に登場した Yahoo はすべてを載せようとして追いつけなくなり、最後に Google が、すべてをアルゴリズムで索引化し、あとから並べ替える方式で勝った。クレイ・シャーキーが「filter, then publish（選んでから公開）」から「publish, then filter（公開してから選ぶ）」への転換と呼んだ変化である。

そのうえでオライリーは、技術に何をさせるかの選択が決定的だと述べる。ユーザーが本当に探しているものを見つける技術は、やがて企業の利益を優先する方向へ変質した。コリイ・ドクトロウはこの過程を enshittification（プラットフォームの劣化）と呼んだ。AIのアラインメントも、突き詰めれば「人間が大事にするものをシステムにも大事にさせる」問題である。

論点4：価値を作り手に循環させる仕組みがない

Anthropic は2025年、モデル学習のために海賊版書籍をダウンロードした件の集団訴訟（Bartz v. Anthropic）で、15億ドルの和解に合意した。オライリーは、他のAI企業が同様の責任をまだ問われていないことに驚きを示している。

対比として挙げられるのが YouTube の Content ID である。2007年に導入されたこの仕組みは、権利者がアップロード動画内の自分の楽曲や映像を検出し、ブロックするか、公開を認めて広告収益を受け取るかを選べるようにした。多くの権利者が収益化を選び、それがクリエイター経済の土台の一つになった。削除要請と訴訟の対立を、収益分配の仕組みに置き換えた例である。

AI業界は同じ挑戦をせず、自社の収益化を先に考えた。オライリーは NotebookLM の公開前に開発チームへ、自分のサービスに組み込んで収益化できるようにしてほしいと提案したが、チームの関心は Google への送客だった。彼の指摘は、プラットフォームは「自分がどう稼ぐか」ではなく「利用者がどう稼ぐか」を設計すべきだ、というものである。Substack の寄付・購読ボタン程度の機能で足りた、とも述べている。

AIプラットフォームを作る者は経済圏を作っており、その中でお金が循環しなければならない。人間の仕事を置き換え続ければ顧客がいなくなる。オライリーは、この問題はハルシネーションよりはるかに深刻だと位置づけている。

前提：メカニズムデザインとは

ゲーム理論は、与えられたルールのもとで参加者がどう行動するかを分析する。メカニズムデザインはその逆で、望ましい結果を先に決め、参加者が自分の利益を追求した結果としてその状態に至るようなルールを設計する。このため「逆ゲーム理論」とも呼ばれる。2007年には、ハーヴィッツ、マスキン、マイヤーソンがこの分野の基礎を築いた功績でノーベル経済学賞を受賞した。

アルビン・ロスは2012年、ロイド・シャプレーとともに、安定配分の理論とマーケットデザインの実践で同賞を受けた。ロスの代表的な仕事が腎臓交換である。血液型などが合わず家族に腎臓を提供できないドナーと患者のペアを複数組み合わせ、互いの相手に提供し合う交換を成立させる。参加したほうが得になるルールにすることで参加者が増え、移植件数が増える。研修医と病院のマッチング制度の改良もロスの仕事として知られる。

オライリーは、新しい技術には新しいメカニズムが必要だが、優れたメカニズムは経済学者ではなく、使う人々が偶然見つけてきたものだと言う。そしてAIについて次の問いを立てる。

• エージェントは最良の専門知識やスキルをどう発見し、その品質をどう確かめ、作り手にどう対価を払うのか
• 最も多く払う者へ誘導するプラットフォームに頼らず、サービスをどう見つけるのか

答えはまだない。能力の向上には巨額が投じられているが、その能力を他の人々の機会に変える仕組みには、ほとんど労力が割かれていない。

論点5：Unix と MCP ― 参加のアーキテクチャ

オライリーは、オープンソースを成立させたのはフリーソフトウェアのライセンスではなく、Unixの設計だったと見る。ケン・トンプソンとデニス・リッチーがベル研究所で作ったUnixは、AT&Tのプロプライエタリなライセンスのもとにあったが、多様なハードウェアで動くように設計されていた。

• カーネルが小さい。数十種類の機種に移植する必要があったためである
• その周りに小さなユーティリティが並び、プレーンテキストの読み書きと、パイプによるストリームの受け渡しという共通の約束に従って協調する
• 誰でも小さな部品を書けば、システムの一級市民になれる
• ある機種でコンパイルしたバイナリは別の機種で動かないため、ソフトウェアはソースコードで共有された

その後、Unixの部品はほぼすべて置き換わった。ハードウェアも、カーネル（Linux）も、シェルも変わった。残ったのはルールである。オライリーはこの構造を「参加のアーキテクチャ」と呼ぶ。

彼はMCPを、AIにおける参加のアーキテクチャであり、偶然生まれたメカニズムデザインの成果だと評価する。当初のAIは、PCのWindowsやスマートフォンのiOS/Androidのように、一つの巨大な知能をみんながAPI経由で呼ぶ中央集権型の構図に見えた。MCPは、どのモデルからでも誰のツールやデータにでも接続できる共通の約束を定めた。これによりエージェントの世界は、オープンソースやウェブのような参加型の経済圏の形を取り始めた。

MCP は Anthropic が2024年11月に公開したオープンな標準で、AIアプリケーション（クライアント）と外部のツールやデータ（サーバー）を JSON-RPC で接続する。サーバーはツール、リソース、プロンプトを公開し、クライアントは接続先を問わず同じ手順でそれを利用する。Unix のテキストとパイプに相当する「共通の約束」がこのプロトコルであり、各組織が公開するMCPサーバーが小さなユーティリティにあたる。論点1の O’Reilly Expert Intelligence も、専門家の知識をこの約束に乗せ、任意のモデルから使えるようにしたものである。

オライリーはさらに、AIが利用者について知っている文脈をツール間で持ち運べる「ポータブルメモリ」の標準化にも取り組んでいる。

論点6：どのゲームを遊ぶのか

メカニズムデザインは、望む結果を決めるところから始まる。オライリーは、いまAI市場で行われているゲームを「超知能の獲得競争」と描く。勝者総取りのゲームであり、それを支える仕組みとして次のものを挙げる。

• 巨額のデータセンター投資（資本力のある者しか参加できない）
• 既存の知的財産の収奪
• 高価なAPIでのモデル提供と、出力からの学習を禁じる利用規約
• 回答への広告の混入
• 利用者の文脈を一社に閉じ込めるメモリ

彼が提案するゲームは「人間の繁栄」である。人々が互いに創り、共有するための新しい手段（アフォーダンス）を増やし、人間とそのエージェントの間で価値が循環する経済を作る。人間はAIに置き換えられるのではなく、AIと協働する。

大手ラボは、動機がどうであれ、調達した巨額の資本を回収するという金融システムの要請に縛られている。その意味でAIは最初から劣化の圧力を抱えている。だからこそ、誰でもダウンロードして動かせるオープンモデルと、国ごとに構築・管理するソブリンAIが重要になる。オープンモデルは最先端のクローズドモデルにまだ及ばないが差は縮まり続けており、すでに多くの実務に十分な性能を持つ。オープンソース、オープンプロトコル、オープンメモリが、利用者に技術を自ら形作り制御する自由を与える。

エンジニアとして読むときの論点

• Bitter Lesson と人間の専門知識は矛盾しない。Bitter Lesson が扱うのはモデルの汎用能力の獲得方法であり、オライリーが扱うのは、その能力を特定の問題に向ける焦点の与え方と、焦点を提供した人への対価である。前者はスケールが決め、後者は設計が決める。
• 専門知識の価値は「知識の量」から「視点の指定」へ移っている。SREの事例でモデルの答えを変えたのは新しい情報ではなく、参照すべき専門家集団の指定だった。専門知識をMCPサーバーやスキルの形で呼び出せるようにしておくことが、知識を使える状態に保つ実装になる。
• エージェントの性能は環境設定で決まる部分が大きい。設定の統一、指示ファイル、失敗事例の取り込みは、モデルの更新を待たずに改善できる領域である。
• 帰属と対価の仕組みは未解決である。MCPは接続の約束を定めたが、どの知識が回答にどれだけ寄与したかを測り、作り手に支払う約束はまだない。Content ID が検出と収益分配を組み合わせたように、AIでも寄与の計測と支払いを組み合わせたメカニズムが必要になる。

出典

• Tim O’Reilly「The Bitter Lesson vs. AI Markets for Human Expertise」（Asimov’s Addendum／O’Reilly Radar、2026年）
• Richard Sutton「The Bitter Lesson」（2019年） http://www.incompleteideas.net/IncIdeas/BitterLesson.html
• Betsy Beyer ほか『Site Reliability Engineering』第5章「Eliminating Toil」 https://sre.google/sre-book/eliminating-toil/
• Linux Foundation「Agentic AI Foundation の設立」（2025年12月9日） https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation
• Model Context Protocol https://modelcontextprotocol.io/

前提1：拡散モデルの仕組み

FLUXをはじめとする多くの画像生成モデルは、拡散モデル という方式で動作します。ランダムなノイズの画像から始めて、ノイズを少しずつ取り除く処理（デノイズ）を繰り返し、指示文（プロンプト）に合った画像を生成します。この1回の処理を ステップ と呼びます。

FLUX 3 Image Kleinは、次の部品で構成されています。

チェックポイントは2種類あります。

CFG（Classifier-Free Guidance） は、指示文ありとなしの2通りで計算し、その差を使って指示文への忠実さを高める手法です。蒸留 は、標準版の出力を教師として、少ないステップで同等の出力を出せるようにモデルを学習させる手法です。

前提2：処理時間の内訳

NVIDIAが測定した最適化前の処理時間（B200 1枚、2048×2048ピクセル、NVFP4、torch.compile使用）は次のとおりです。

処理時間の大半がノイズ除去であるため、1ステップあたりの計算を速くするか、計算量を減らすかが高速化の中心になります。

高速化の手法

最終結果

B200 1枚、2048×2048ピクセルで、手法を組み合わせた結果です。

RTX PRO 6000 Blackwell Server Edition 1枚でも、コンパイル、融合したNVFP4カーネル（CuTe DSL）、Cache-DiTの組み合わせで1.73〜3.25倍になりました。

画質への影響

画質は LPIPS という指標で、最適化前の出力との差を測っています。0なら同一で、値が大きいほど差が大きいことを示します。

• Cache-DiTは0.02〜0.04程度で、高速化の効果に対して画質への影響が小さい
• FP8のアテンションは、蒸留版で0.15〜0.16程度とやや大きい
• 手法を重ねるほど値は大きくなり、NVIDIAの例では0から0.095まで上がった

用途（最終的な成果物の生成か、試作の大量生成か）に応じて、どの手法まで使うかを選ぶ必要があります。

試すには

• NVIDIA TensorRT-LLMの画像生成機能「VisualGen」で実行します
• 専用のコンテナ（nvcr.io/nvidia/tensorrt-llm/release:feat-flux3-image-klein-1.4.0a0.dev202610280436）と、TensorRT-LLMリポジトリの feat/flux3-image-klein ブランチが公開されています
• trtllm-serve コマンドで、OpenAI互換の画像生成API（/v1/images/generations）として提供できます
• 量子化、コンパイル、アテンション、キャッシュ、並列化、CUDAグラフの設定は、YAMLファイルで切り替えます

制約と注意点

• コンテナは機能ブランチの開発版（1.4.0a0.dev）です
• 公表された処理時間には、プロンプトのアップサンプリング（指示文を自動で詳しくする処理）は含まれていません
• 測定はBlackwell世代のデータセンター向けGPUとRTX PRO 6000 Blackwell Server Editionで行われており、GeForceでの結果は示されていません
• モデルのパラメータ数とライセンスは、NVIDIAの記事には記載されていません。利用前にBlack Forest Labsの条件を確認してください

まとめ

• 画像生成の処理時間の大半はノイズ除去の繰り返しで、ここが高速化の中心になる
• 量子化、アテンションの高速化とスパース化、ステップ間のキャッシュ、複数GPUでの並列化、CUDAグラフを組み合わせ、B200 1枚で3.5〜4.5倍速くなった
• Cache-DiTは、画質への影響が小さく、効果が大きい
• 手法を重ねるほど画質の差は大きくなるため、用途に合わせて選ぶ必要がある

あわせて読みたい

• ① NVFP4：モデルを4ビットにする数値形式
  この記事で使ったNVFP4の詳しい仕組み
• GPUメモリを無駄なく使う5つの方法【まとめ】
  NVFP4を含む、GPUメモリを無駄なく使う5つの方法

参考

• Speed Up Image Generation with FLUX 3 Image Klein on NVIDIA Blackwell GPUs（NVIDIA Technical Blog）

Nemotron 3.5 Boltの基本仕様

同時に公開されたNemotron 3.5ファミリーの中での位置づけは次のとおりです。

BoltはRTX Spark搭載ノートPCの発売（2026年10月16日国内発売）に合わせて設計されたモデルで、他のアプリケーションと同時に動かしながら日常的なエージェント処理をローカルで実行することを狙っています。

前提知識1：パラメータ数とメモリ量の関係

LLMの重みは数値の集まりで、1個の数値を何ビットで表すかによって必要なメモリ量が決まります。74Bモデルで計算すると次のようになります。

4ビットでも37GBあり、24GBには収まりません。24GBに収めつつKVキャッシュや画像エンコーダーの領域を残すには、重みの大部分を2ビットまで落とす必要があります。実際にDGX Sparkで計測された値は、本体の重みが20.51GiB、画像処理用のmmprojが1.61GiBでした。

前提知識2：MoEでは「総パラメータ」と「アクティブパラメータ」が別物

MoE（Mixture of Experts）は、FFN層を多数の「エキスパート」に分割し、トークンごとにルーターが一部のエキスパートだけを選んで計算する構造です。

• 総パラメータ（74B）：すべてのエキスパートを合計した量。どのエキスパートが選ばれるかは事前に分からないため、全量をメモリに置く必要がある。メモリ要件を決める数字
• アクティブパラメータ（9B）：1トークンの計算で実際に使う量。計算量と生成速度を決める数字

つまりMoEは「メモリは大きく、計算は軽い」モデルです。計算が9B相当で済む一方、メモリには74B分を置く必要があるため、ローカル環境ではメモリ量がボトルネックになります。Boltが2ビット化に踏み込んだ理由はここにあります。

なお、Nemotron 3.5はTransformerの注意機構（Attention）に加えて、状態空間モデルのMamba層を組み合わせたハイブリッド構成です。Mamba層は系列長に対して計算量が線形に増えるため、256Kの長文脈を扱いやすくなります。

前提知識3：なぜ通常の量子化は4ビットを下回ると崩れるのか

一般的な量子化はPTQ（Post-Training Quantization：学習後量子化）です。学習済みのモデルの重みを、後から少ないビット数の値に丸めます。

2ビットで表現できる値は1ブロックあたり4段階しかありません。16ビットで細かく調整されていた重みを4段階に丸めると、各層で生じる誤差が層を重ねるごとに蓄積し、出力が大きくずれます。4ビット（16段階）までは実用的な精度を保てても、それを下回ると急激に性能が落ちるのはこのためです。

これに対してQAT（Quantization-Aware Training：量子化を考慮した学習）は、量子化した状態で順伝播を計算しながら学習を続け、丸め誤差を前提に重みを調整し直します。Boltが採用しているQAD（Quantization-Aware Distillation：量子化を考慮した蒸留）はその発展形で、量子化したモデルを生徒とし、量子化前の高精度モデルの出力分布に近づくように学習させます。正解ラベルだけでなく教師モデルの確率分布全体を手本にするため、失われた精度を効率よく取り戻せます。

NVIDIAは技術ページで、ParetoQやQuestといった先行研究を引用し、「同じメモリ量なら、高ビットの小さいモデルより、1〜2ビットの大きいモデルのほうが精度とサイズの釣り合いが良い」という知見を示しています。Boltの結果もこの知見と整合すると述べています。

24GBに収めるまでの工程

Boltは、親モデルであるNemotron 3.5 Super VL（120B-A12B）から次の工程で作られています。

混合精度：どの層を何ビットにしているか

設計の考え方は明確です。重みの大半を占めるエキスパートを2ビットにして容量を大きく削り、モデル全体の振る舞いに影響する注意機構・埋め込み・出力層は8ビットに残しています。IQ2_XXSはllama.cppの量子化形式で、ブロック単位のスケール情報を含むため1要素あたり2.0625ビットになります。NVFP4はNVIDIA Blackwell世代がハードウェアで扱える4ビット浮動小数点形式です。

ベンチマーク：BF16版との差と競合モデルとの比較

NVIDIAが公開した値の主要部分です。比較対象は「4ビット量子化で24GBに収まるオープンMoEモデル」から選ばれています。

読み取れることは3点です。

1. 2ビット化による低下は小さい：BF16版との差は多くの項目で2〜4ポイント。WebArenaとτ³-bench（Banking、両者とも17.01）では差がない
2. エージェント系で強い：BrowseComp（Web調査）で66.75と、Qwen3.6-35B-A3Bの48.74を18ポイント上回る。公開リーダーボードでは、同程度のメモリ量のモデルの中でPinchBench 1位、WebArena 2位、BrowseComp 2位
3. 知識の想起は落ちる：AA-Omniscienceの正答率はBF16の21.8から16.9へ4.9ポイント低下し、Gemma 4を下回る。一方で非ハルシネーション率は56.14から61.27へ上がっており、知らないことを答えずに控える傾向が強まっている

生成速度

実機での動作検証

Sam Witteveen氏の動画では、ローカル環境でツール呼び出しを伴うエージェント処理を実行し、プロンプトインジェクションへの耐性も確認しています。一部に小さな誤りはあるものの、全体としてエージェントとして機能すると評価しています。親モデルの120Bと比べれば賢さと速度に差はありますが、24GBというハードウェア制約の中で動くモデルとしては実用的という結論です。

クラスメソッドの検証でも、2ビット化による明確な精度低下は見られていません。

推論（thinking）の設定で処理量が大きく変わる点も確認されています。日本語タスクでは、highで約13,400トークン・356秒、mediumで約3,200トークン・91秒を消費し、どちらも8/9正解でした。offでは約960トークンで7/9です。出力形式の一貫性はoffで0/5まで落ちるため、エージェント用途ではmediumが現実的な設定です。

使いどころと制約

向いている用途

• 24GB級のGPU、またはRTX Spark／DGX Sparkで、1人がローカルでコーディングエージェントやWeb調査エージェントを動かす用途
• 他のアプリケーションとメモリを共有しながら、クラウドに出せないデータをローカルで処理する用途
• 画像・動画を含む入力を、256Kの長文脈で扱う用途

制約

• 生成速度は4ビットの26B〜35Bクラスより遅い。速度を最優先するならQwen3.6やGemma 4が有利
• 同時リクエストに弱く、チームで共有する推論サーバーにはLightning（30B-A3B）のほうが適する
• ファインチューニングの土台にはしにくい。BF16版は約150GBあり、ローカル環境に載らない
• 知識の想起（AA-Omniscience正答率）はBF16版から約5ポイント落ちる。事実確認が重要な用途ではRAGや検索ツールと組み合わせる

まとめ

• Nemotron 3.5 Bolt 74B-A9B 24GBは、120B-A12Bの親モデルを「24GBに収まること」を目標に圧縮し、事後学習とQADを経て、重みの大部分を2ビットにしたモデルである
• 精度の鍵は、学習後に丸めるPTQではなく、圧縮段階から量子化を前提に設計し、量子化した状態で教師モデルに合わせて学習し直している点にある
• BF16版との差は数ポイントに収まり、エージェント系ベンチマークでは同じメモリ量の4ビットモデルを上回る。一方で速度と同時実行性能は劣るため、1人用のローカルエージェントとして使うのが適している

参考

• Sam Witteveen「NVIDIA’s Secret 2 Bit Model」（YouTube、2026年11月9日）
• NVIDIA Research「NVIDIA Nemotron 3.5 Bolt 74B-A9B 24GB」
• Hugging Face「nvidia/NVIDIA-Nemotron-3.5-Bolt-74B-A9B-24GB」
• HPCwire「NVIDIA Expands Nemotron Family with Highest Efficiency Super VL and Bolt Models」
• クラスメソッド「2-bit量子化MoE『Nemotron 3.5 Bolt 74B-A9B』をDGX Sparkで動かしてみた」

前提：ビット数を減らすことの意味

LLMは、数千億個にもなる数値（重み）の集まりです。推論のたびに、GPUはこの重みをHBMから読み出して計算します。1つの数値を何ビットで表すかによって、必要なメモリの量と読み出しにかかる時間が変わります。

ビット数を半分にすれば、メモリの量も読み出しの時間も半分になります。ただし、表せる値の種類が減るため、計算結果の精度が落ちるおそれがあります。ビット数を減らすことと、精度を保つことの両立が課題です。

FP4（E2M1）で表せるのは15個の値だけ

NVFP4の土台になっているFP4は、4ビットを「符号1ビット・指数2ビット・仮数1ビット」に分けた浮動小数点数です（E2M1形式）。表せる値は次の15個です。

0、±0.5、±1、±1.5、±2、±3、±4、±6

値の間隔は一定ではなく、0の近くは細かく、絶対値が大きくなるほど粗くなります。この15個だけでは、次のような値をそのまま表せません。

• 0.03のような小さな値（0に丸められる）
• 120のような大きな値（6に丸められる）
• 2.4のような中間の値（最も近い2に丸められる）

AIの重みには、ごく小さな値から大きな値までが混在しています。15個の値だけでは表現しきれません。

スケールと組み合わせる

そこで使うのが スケール（倍率） です。値の集まりごとにスケールを決め、「元の値 ≒ 4ビットの値 × スケール」として表します。

• 小さな値が集まるブロックでは、スケールを0.01にする → 0.005刻みで表せる
• 大きな値が集まるブロックでは、スケールを20にする → 最大120まで表せる

記録するのは「4ビットの値」と「スケール」の2つです。設計上の論点は、スケールを何個の値ごとに付けるかと、スケール自体をどれだけ細かく表すかの2つです。

NVFP4の設計：小さなブロックに、細かいスケールを付ける

業界標準の4ビット形式「MXFP4」（Open Compute Projectの仕様）と比べると、NVFP4の設計がよく分かります。

効果

制約と注意点

• 誤差はゼロではない：精度の差が1ポイントでも問題になる用途では、対象のタスクで検証が必要です
• Blackwell以降が必要：NVFP4を高速に計算するTensor Coreは、Blackwell世代から搭載されています
• 最良条件の数字：「電力あたり最大4倍」（GB300でのDeepSeek R1、FP8比）などの数字は、特定のモデルと条件での最大値です

試すには

• NVIDIA TensorRT Model OptimizerまたはLLM Compressorで、モデルをNVFP4に変換できます（PTQ、量子化を考慮した学習＝QATなど）
• 変換したモデルは、TensorRT-LLMやvLLMで動かせます
• DeepSeek-R1-0528などの変換済みモデルが、Hugging Faceで公開されています

まとめ

• FP4（E2M1）で表せる値は15個しかなく、そのままでは幅広い値を表せない
• NVFP4は、16個ごとのFP8スケールとテンソル全体のFP32スケールの2段階で、表現の精度を上げている
• モデルは16ビット形式の約3.5分の1になり、精度の低下は多くの項目で1ポイント以内
• KVキャッシュにも使え、GPUに載せられる文脈の長さがおよそ2倍になる

連載「GPUメモリを無駄なく使う5つの方法」

• GPUメモリを無駄なく使う5つの方法【まとめ】
• ① NVFP4：モデルを4ビットにする数値形式（この記事）
• ② Wide-EP：MoEのエキスパートを多数のGPUに分散する
• ③ Dynamo：KVキャッシュをデータセンター全体で再利用する
• ④ Vera CPU：待ち時間中のKVキャッシュをCPUメモリで受け持つ
• ⑤ CMX：KVキャッシュ専用の共有ストレージ階層

前の記事：GPUメモリを無駄なく使う5つの方法【まとめ】

次の記事：② Wide-EP：MoEのエキスパートを多数のGPUに分散する

あわせて読みたい

• FLUX 3 Image Klein：画像生成をBlackwellで3〜4倍高速化
  NVFP4を画像生成モデルに適用し、処理時間を短縮した例

参考

• Introducing NVFP4 for Efficient and Accurate Low-Precision Inference（NVIDIA Technical Blog）
• Five Ways NVIDIA Co-Design Maximizes the Value of Every Byte in the AI Factory（NVIDIA Technical Blog）
• Pushing Intelligence to 4-bit（NVIDIA Research）

前提：KVキャッシュの階層（G1〜G4）

NVIDIAは、KVキャッシュの置き場所を次の4階層で整理しています。

NVIDIAによると、KVキャッシュがGPUから遠い階層に置かれるほど、1トークンあたりの遅延とエネルギーが増えます。

G3とG4の間には大きな差があります。

• G3：速いが、そのノードからしか使えない
• G4：どのノードからも使えるが、遅延が大きい

「どのノードからも使えて、しかも速い」階層がありませんでした。

KVキャッシュの置き場所が足りなくなった理由

NVIDIAは、次の3つの変化を挙げています。

1. 文脈が長くなった：エージェントの文脈は数百万トークン規模に伸び、モデルは数兆パラメータに近づいている。KVキャッシュの量は文脈の長さに比例して増える
2. 再計算の負担が増えた：履歴の再計算に必要な計算量は、文脈が長くなるほどKVキャッシュの量以上に急速に増える。そのため再利用が欠かせない
3. セッションが長く続くようになった：エージェントは、複数のターン、ツール呼び出し、セッションにまたがって文脈を保持する必要がある

さらに、長いセッションの途中で処理ノードが変わることがあります。

KVキャッシュがノードAのローカルSSDにしかない場合、ノードBでは読み出せず、prefillで再計算することになります。

CMX：G3とG4の間に共有階層を追加する

NVIDIAが用意したのがCMX（Context Memory eXtension、旧称ICMS：Inference Context Memory Storage）です。2026年1月のCESで発表されました。

CMXの特徴は次のとおりです。

• GPUポッド内のどのノードからも使える：処理ノードが変わってもKVキャッシュを再利用できる
• KVキャッシュ専用：一時的で、繰り返し読み出されるKVキャッシュの特性に合わせて設計されている
• 大容量：GPUポッドあたりペタバイト級の共有容量を持つ

これにより、G4の共有ストレージは、非アクティブなセッションの状態、クエリ履歴、ログなど、永続化すべきデータの保管に専念できます。

CMXの構成

CMXは、Vera Rubinプラットフォームの一部であるNVIDIA STXリファレンスアーキテクチャ（BlueField-4 STXラック）の上に構築されています。

効果

NVIDIAは、長い文脈の推論とエージェントの処理について、次のように説明しています。

• 1秒あたりに生成できるトークン数が、従来のストレージと比べて最大5倍
• 電力効率が、汎用のストレージと比べて最大5倍

ただし、比較の前提となった構成や試験条件は示されていません。条件がそろったときの最大値として扱うのが妥当です。

制約と注意点

• 製品はこれから：CMXはVera Rubin世代の基盤の一部です。2026年5月時点の報道では、BlueField-4の出荷は2026年後半の予定で、CMXに基づく製品はまだ出ていないとされていました
• NVIDIAの設計への依存：ストレージベンダーにとっては、G3.5階層の仕様がNVIDIAのハードウェアとソフトウェアのロードマップに左右されます
• 再利用できるKVキャッシュがあってこそ：毎回異なる入力を処理する用途では、効果は限られます

まとめ

• KVキャッシュの置き場所には、「速いがノードに固定されたローカルSSD（G3）」と「共有できるが遅い共有ストレージ（G4）」の間に差があった
• CMXは、その間にKVキャッシュ専用の共有階層「G3.5」を追加し、GPUポッド内のどのノードからもKVキャッシュを読み出せるようにする
• BlueField-4がI/Oを処理し、Dynamoがdecodeの前にKVキャッシュをGPU側へプリステージする
• 長く続き、処理ノードが変わるエージェントのセッションほど効果が大きい

連載「GPUメモリを無駄なく使う5つの方法」

• GPUメモリを無駄なく使う5つの方法【まとめ】
• ① NVFP4：モデルを4ビットにする数値形式
• ② Wide-EP：MoEのエキスパートを多数のGPUに分散する
• ③ Dynamo：KVキャッシュをデータセンター全体で再利用する
• ④ Vera CPU：待ち時間中のKVキャッシュをCPUメモリで受け持つ
• ⑤ CMX：KVキャッシュ専用の共有ストレージ階層（この記事）

前の記事：④ Vera CPU：待ち時間中のKVキャッシュをCPUメモリで受け持つ

あわせて読みたい

• Agent Substrate：待機の長いエージェントを少数のPodで動かす
  推論基盤のDynamoと連携して、エージェントを大規模に動かす仕組み

参考

• Five Ways NVIDIA Co-Design Maximizes the Value of Every Byte in the AI Factory（NVIDIA Technical Blog）
• Introducing the NVIDIA Inference Context Memory Storage Platform（NVIDIA Technical Blog）
• NVIDIA CMX context memory storage platform（NVIDIA）
• MinIO Spies Solution to GPU Memory Wall Problem with MemKV（HPCwire）

前提1：同期型の分散学習

大規模なAIモデルの学習は、数十〜数千枚のGPUに処理を分けて並行して行います。これを分散学習と呼びます。

多くの分散学習では、各GPUが自分の担当分の計算を終えるたびに、全GPUの計算結果（勾配）を集約して平均をとり、全GPUに配り直す処理を行います。これを All-Reduce と呼びます。全GPUの計算が終わらないと、次のステップに進めません。

そのため、1枚のGPUの処理が遅いと、他のGPUはそのGPUを待つことになり、学習全体がそのGPUの速度で進みます。

前提2：エラーを出さずに遅いGPU

問題は、遅いGPUが必ずしも故障として検出されないことです。NVIDIAは、そうしたGPUについて、Xidエラー（NVIDIAドライバーが記録するGPUのエラー）を出さず、監視のしきい値も超えず、ノードのメトリクスでも異常に見えない場合があると指摘しています。

メトリクスの監視だけでは検出できず、実際に通信や学習の負荷をかけて性能を測る必要があります。

DSX OSの3つのコンポーネント

ライフサイクルの自動化

ノードの追加時や修理からの復帰時の流れは次のとおりです。

1. ライフサイクルコントローラーが ValidationRequest（検証要求）を自動で作成する
2. 試験に合格するまで、cordonまたはtaintでノードへの割り当てを止める
3. NVCREで試験を実行し、合格したら解除する

検証の状態は nvsentinel.nvidia.com/validation-state ラベルとして付与されるため、kubectl で確認できます。

一方、ドライバー、オペレーター、ネットワークファブリックの変更では、自動で検証が実行されません。影響を受けるノードをcordonして検証要求を作成するか、パイプラインにドリフト検出を組み込む必要があります。

制約と注意点

• 合格基準は初期状態では未設定です。クラスタの期待性能に合わせて設定する必要があります
• ドライバーなどの変更は、自動検証の対象外です
• NVIDIAの記事には、導入による性能改善の数値は示されていません。効果は各環境で測定する必要があります
• サーキットブレーカーの上限値の初期値は示されていません

まとめ

• 同期型の分散学習は最も遅いGPUの速度で進むため、エラーを出さずに遅いGPUが大きな損失になる
• DSX OSは、AICRで構成をそろえ、NVCREで通信と学習の試験を行い、NVSentinelで運用中の異常ノードを隔離する
• 不合格のグループを分割して再試験することで、原因のノードを特定できる
• 合格基準の設定と、構成変更時の再検証の組み込みは、運用者が行う必要がある

あわせて読みたい

• NVKE／NVKR：GPUクラウド事業者向けのマネージドKubernetes
  GPUクラウド事業者がKubernetesクラスタを提供する仕組み
• ② Wide-EP：MoEのエキスパートを多数のGPUに分散する
  数十枚のGPUで1つのモデルを動かす推論の方法
• OpenShell：AIエージェントの実行環境とCNCFへの寄贈
  同時に発表された部品の全体像

参考

• Configure, Certify, and Operate Kubernetes GPU Clusters with NVIDIA DSX OS（NVIDIA Technical Blog）
• NVIDIA Expands Open Source Commitment With OpenShell Donation and New AI Infrastructure（NVIDIA Blog）

前提：KVキャッシュとprefill・decode

LLMが回答を生成する処理は、2つの段階に分かれます。

prefillでは、入力の各トークンについてKey（K）とValue（V）という中間データを計算します。これを保存したものが KVキャッシュ です。decodeでは、新しいトークンを生成するたびにKVキャッシュを参照します。

KVキャッシュには、もう1つの使い道があります。次のリクエストの入力が同じ文章で始まる場合、その部分（プレフィックス）のKVキャッシュを再利用すれば、prefillの計算を省けるのです。

NVIDIA Dynamoとは

NVIDIA Dynamoは、多数のGPUでLLMを動かすためのオープンソースの推論基盤です。vLLM、SGLang、TensorRT-LLMといった推論エンジンと組み合わせて使い、データセンター規模でリクエストの振り分けやGPUの割り当てを行います。性能が重要な部分はRust、拡張性が必要な部分はPythonで書かれています。KVキャッシュの扱いについて、3つの機能があります。

機能1：KV-awareルーティング

Dynamoのルーターは、各ワーカー（推論エンジンが動くGPU）がどのKVブロックを持っているかを、基数木（radix tree）で一元管理しています。

• 新しいリクエストが来たら、プレフィックスが一致するKVキャッシュを持つワーカーを探す
• ただし、そのワーカーの負荷が高ければ、キュー待ちより再計算のほうが早い場合もある
• プレフィックスの一致の長さと、各ワーカーの負荷を比較して 送り先を決める

単純なラウンドロビン（順番に振り分ける方式）では、同じ会話のリクエストが毎回別のワーカーに送られ、そのたびにprefillの再計算が発生します。KV-awareルーティングはこれを避けます。

機能2：prefillとdecodeの分離

同じGPUでprefillとdecodeの両方を処理すると、長い入力のprefillが入るたびに、decode中の他のリクエストの生成が遅れます。そこでDynamoは、2つの段階を別々のGPUグループに担当させます。これを分離型推論（disaggregated serving）と呼びます。

• prefillワーカーがKVキャッシュを作り、転送ライブラリ NIXL（NVIDIA Inference Xfer Library）でdecodeワーカーへ送る
• decodeワーカーはprefillを行わないため、HBMをKVキャッシュに多く割り当てられる
• 負荷に応じて、prefillとdecodeのGPU数をそれぞれ調整できる

機能3：KVBMによる階層管理

HBMに置けるKVキャッシュには限りがあります。Dynamoの KVブロックマネージャー（KVBM） は、KVキャッシュを次の4階層に分けて管理します。

• 上位の階層があふれたら、KVブロックを下位へ移す（オフロード）
• 再利用するときは、上位へ戻す（オンボード）。prefillで再計算するより速い
• 同じ内容のブロックは、ハッシュで重複を排除する

NVIDIAの最新の説明では、複数ノードにまたがってブロックの位置を追跡し、他のノードのKVキャッシュも再利用できるKV Cache Runner（KVCR）にまで機能が広がっています。

効果

KVキャッシュ再利用の効果は、主にストレージ企業が検証しています。

• VAST Data：DGX H100上のvLLMとLMCacheで、Qwen3-32Bに約13万トークンの入力を与えた試験で、再利用時のTTFTが再計算より短くなった。CoreWeaveとの共同検証では、過去の会話をすべて再計算する場合と比べ、TTFTが20倍改善したと報告している
• 転送速度：VAST DataはGPUDirect StorageでH100 1枚に毎秒35GB、WEKAは独自のNIXLプラグインでH100 8枚に合計で毎秒最大270GBの読み込みを報告している

いずれもストレージ企業による検証の数字です。実際の効果は、入力の長さや、同じプレフィックスの繰り返し頻度によって大きく変わります。

制約と注意点

• 再利用できない入力には効かない：毎回異なる入力では、再利用できるKVキャッシュがありません
• 転送にも時間がかかる：下位階層からの読み戻しにも時間がかかります。VAST Dataの検証では、多くの場合、ストレージよりネットワークがボトルネックでした
• 障害時の保護には前提がある：推論エンジンが停止してもホストメモリ上のKVキャッシュを保持する機能（KVCR-Guard）がありますが、その保護サービスとホストが動作していることが前提です

まとめ

• KVキャッシュを再利用すれば、同じプレフィックスを持つリクエストのprefillを省ける
• Dynamoは、KV-awareルーティング、prefillとdecodeの分離、KVBMによるG1〜G4の階層管理で、KVキャッシュをデータセンター全体で使い回す
• 同じシステムプロンプトや資料を繰り返し使うエージェントほど、効果が大きい

連載「GPUメモリを無駄なく使う5つの方法」

• GPUメモリを無駄なく使う5つの方法【まとめ】
• ① NVFP4：モデルを4ビットにする数値形式
• ② Wide-EP：MoEのエキスパートを多数のGPUに分散する
• ③ Dynamo：KVキャッシュをデータセンター全体で再利用する（この記事）
• ④ Vera CPU：待ち時間中のKVキャッシュをCPUメモリで受け持つ
• ⑤ CMX：KVキャッシュ専用の共有ストレージ階層

前の記事：② Wide-EP：MoEのエキスパートを多数のGPUに分散する

次の記事：④ Vera CPU：待ち時間中のKVキャッシュをCPUメモリで受け持つ

あわせて読みたい

• Agent Substrate：待機の長いエージェントを少数のPodで動かす
  Dynamoと連携して、エージェントを大規模に動かす仕組み
• NVIDIA Snapshot：推論サーバーの起動を数十秒にする
  推論サーバーの起動を速くする仕組み

参考

• Five Ways NVIDIA Co-Design Maximizes the Value of Every Byte in the AI Factory（NVIDIA Technical Blog）
• NVIDIA Dynamo High Level Architecture（NVIDIA Docs）
• KVBM Guide（NVIDIA Dynamo Docs）
• NVIDIA Dynamo + VAST（VAST Data Blog）

前提1：マネージドKubernetesとは

Kubernetesは、多数のサーバー上でコンテナを管理するソフトウェアです。ただし、Kubernetes自体の構築と運用には手間がかかります。

• クラスタを制御する コントロールプレーン を冗長構成で動かす
• 設定を保存するデータベース etcd を保護する
• Kubernetesのバージョンを定期的に更新する
• ノードの追加や交換に対応する

AWSのEKS、AzureのAKS、Google CloudのGKEのように、Kubernetesの構築と運用をクラウド事業者が引き受け、利用者はAPIやコンソールからクラスタを作成するだけでよいサービスを、マネージドKubernetesと呼びます。

前提2：AIファクトリーとNVIDIA Cloud Partner

大手クラウド以外にも、GPUを大量に設置したデータセンターを構築し、その計算能力を提供する事業者が増えています。NVIDIAはこうした施設を「AIファクトリー」、提携する事業者を「NVIDIA Cloud Partner（NCP）」と呼んでいます。

こうした事業者の顧客も、EKSのようにGPU付きのKubernetesを使いたいと考えます。しかし、大手クラウドのようにマネージドサービスを独自に開発するには、大きな開発投資が必要です。NVKEとNVKRは、マネージドKubernetesサービスを構築するための部品一式です。

全体構成

内部の構成要素

SPIFFEによる身元確認は、セキュリティ上の重要な設計です。ネットワークに接続されたサーバーを無条件にクラスタへ参加させるのではなく、正規の機器であることを証明できたサーバーだけを参加させるため、不正な機器の混入を防げます。

構築の手順

NVIDIAの解説では、次の5ステップで顧客クラスタを作成しています。

1. NVKRでノードのOSイメージをビルドする（Kubernetes 1.36のパッケージとSPIREエージェントを含むQCOW2形式のディスク）
2. nvkectl bootstrap site で管理クラスタを構築し、nvkectl config set-site で接続する
3. マシンイメージ、クラスタリリース、ノードプールリリースを登録する
4. nvkectl create cluster で顧客クラスタを作成する（状態がProvisioningからProvisionedに変わる）
5. nvkectl get kubeconfig で接続情報を取得する

2の管理クラスタの構築では、まずブートストラップ用のホスト上にkindで一時的なクラスタを作り、それを使って本番の管理クラスタを構築したあと、一時的なクラスタを削除します。

例として示された構成は、管理クラスタがCPUサーバー3台、顧客クラスタがコントロールプレーン3台（Kubernetes 1.36.3、etcdの暗号化を有効化）とGPUノード4台です。GPUやNVIDIAアカウントがなくても試せる、1台で完結するクイックスタートも用意されています。

利用者とパートナー

主な利用者は、GPU付きのKubernetesを顧客に提供したいAIファクトリーやNCPです。NVIDIAによると、NCPのFirmusとSK Telecomが組み込みを進めており、Mirantis、Rafay、Spectro Cloud、OpenNebula Systems、vClusterも自社のマネージドKubernetes製品に部品を取り入れています。Netrisはネットワーク自動化でNVKEに対応します。

利用者の立場で見ると、大手クラウド以外のGPUクラウドでも、EKSやAKSに近い使い勝手のKubernetesが提供されるようになる可能性があります。

制約と注意点

• パブリックプレビューで、APIは変更される可能性があります。NVIDIA自身が本番利用はまだ推奨していません
• 物理サーバーの管理にNICoを前提としているため、既存のデータセンター管理システムとの連携は別途検討が必要です
• 主な対象はGPUを提供する事業者で、一般企業が直接使う場面は当面限られます

まとめ

• NVKRは、GPU世代ごとの検証済みのソフトウェア構成を「レシピ」として、OSイメージなどを再現可能な形でビルドする
• NVKEは、顧客ごとに独立したKubernetesクラスタを作成・管理する、マネージドKubernetesの基盤
• 物理サーバーの管理、Cluster APIとの連携、ノードの身元確認、監視までが部品として提供されている
• GPUクラウド事業者がマネージドKubernetesを提供しやすくなるが、現時点ではプレビュー段階

あわせて読みたい

• DSX OS：分散学習を遅くするGPUノードを検出する
  NVKEで作ったクラスタのGPUノードを認定・監視する仕組み
• OpenShell：AIエージェントの実行環境とCNCFへの寄贈
  同時に発表された部品の全体像
• NVIDIA Snapshot：推論サーバーの起動を数十秒にする
  Kubernetes上で推論サーバーの起動を速くする仕組み

参考

• Manage Kubernetes Clusters for GPU Infrastructure with NVIDIA Kubernetes Engine（NVIDIA Technical Blog）
• NVIDIA Expands Open Source Commitment With OpenShell Donation and New AI Infrastructure（NVIDIA Blog）
• dsx-ai-factory/nvke（GitHub）
• dsx-ai-factory/nvkr（GitHub）

前提：コンテナ、Kubernetes、CNCF

コンテナは、アプリケーションと、その実行に必要なライブラリや設定をまとめてパッケージにしたものです。どのサーバーで動かしても同じように動作します。

Kubernetesは、多数のサーバー上でコンテナを自動的に配置・起動・監視するソフトウェアです。サーバーが故障すれば別のサーバーでコンテナを起動し直し、負荷が増えればコンテナを増やします。Kubernetesでコンテナを動かす最小単位を Pod と呼びます。

CNCFは、Kubernetesを管理している非営利団体で、Linux Foundationの傘下にあります。特定の企業に依存しない形でオープンソースプロジェクトを運営します。プロジェクトは成熟度に応じて、Sandbox → Incubating → Graduated の3段階に分かれます。OpenShellは最初の段階であるSandboxに入りました。

AIエージェントに専用の制御が必要な理由

従来のアプリケーションは、あらかじめ決められた処理を決められた順序で実行します。AIエージェントは、LLMの判断に基づいて次のような操作を自律的に行います。

• ファイルを読み書きする
• 外部のAPIを呼び出す
• コマンドを実行する

悪意がなくても、誤った判断で重要なファイルを削除したり、外部に情報を送信したりするおそれがあります。そのため、エージェントがアクセスできる範囲を、エージェントの外側で制限する仕組みが必要になります。OpenShellはそのための実行環境です。

OpenShellの仕組み

同時に発表された部品

OpenShellの寄贈と同時に、Kubernetes上でエージェントとGPUを扱うための部品が発表されました。

それぞれの役割は次のように整理できます。

• OpenShell：エージェントが何をしてよいかを制限する
• Agent Substrate：エージェントを大規模に実行する
• Snapshot：推論サーバーを速く起動する
• NVKE／NVKR：GPUクラスタを顧客に提供する
• DSX OS：GPUクラスタの品質を保証する

数字で目を引くのはSnapshotです。設計パートナーのCrusoeは、HGX B300上でGLM-5.3のワークロードが使える状態になるまでの時間を約8分から31秒に短縮したと報告しています。

考察：NVIDIAがこの領域をオープンにする理由

ここからは筆者の考察です。

NVIDIAの主力製品はGPUですが、GPUの価値は「どれだけ休まず処理させられるか」で決まります。エージェントの時代には、GPUの手前で次のような問題が起きやすくなります。

• エージェントを安全に動かせないため、本番環境に出せない
• エージェントの大半が待機状態で、計算資源を確保したまま使っていない
• 推論サーバーの起動に数分かかり、需要の急増に追いつけない
• 1台の性能の低いGPUが混ざり、クラスタ全体の学習が遅くなる

今回の発表は、これらの問題に1つずつ対応する部品になっています。しかも自社製品として囲い込まず、CNCFやApache 2.0ライセンスで公開しています。周辺のソフトウェアを業界標準にしておけば、その上で最も性能が出るGPUが選ばれる、という戦略と読めます。

一方で、NVKE／NVKRはパブリックプレビューで本番利用は推奨されておらず、Agent SubstrateもAPIが変わり得る段階です。発表された機能と本番で使える機能は区別して、成熟度を確認しながら導入を検討する必要があります。

まとめ

• OpenShellは、エージェントがアクセスできるファイル・通信・APIをYAMLで宣言して強制する実行環境で、CNCF Sandboxに寄贈された
• 同時に、Agent Substrate（大規模実行）、Snapshot（高速起動）、NVKE／NVKR（クラスタ提供）、DSX OS（品質保証）が発表された
• いずれもオープンソースで、エージェントとGPUを本番運用するための基盤をKubernetes上にそろえる動き

あわせて読みたい

• Agent Substrate：待機の長いエージェントを少数のPodで動かす
  OpenShellと同時に発表された、エージェントを大規模に動かす仕組み
• NeMo：AIエージェントの失敗をトレースから改善する
  エージェントが誤った操作をしたときに、原因を特定して直す方法
• NVIDIA Snapshot：推論サーバーの起動を数十秒にする
  同時に発表された、推論サーバーの起動を速くする仕組み

参考

• NVIDIA Expands Open Source Commitment With OpenShell Donation and New AI Infrastructure（NVIDIA Blog）
• Overview of NVIDIA OpenShell（NVIDIA Docs）
• NVIDIA OpenShell 0.1.0の解説（NVIDIA Technical Blog）

前提：LLMの推論サーバーは、なぜ起動が遅いのか

ChatGPTのようなサービスでは、「推論サーバー」と呼ばれるプログラムがGPU上で動き、質問を受けて回答を生成しています。推論サーバーは、起動してすぐには回答できません。NVIDIAは起動（コールドスタート）を次の4段階に分けています。

通常の起動では、この4段階を毎回最初から実行します。

起動が遅いと、次の3つの問題が起きます。

1. スケールアウトが遅れる：アクセスが急に増えてサーバーを追加しても、使えるまで数分かかる
2. 障害からの復旧が遅れる：1台が停止して代わりを起動するまで、その分の処理能力が欠ける
3. GPUが遊ぶ：起動中のGPUは高価なのに、回答を1つも生成しない

Snapshotの仕組み

測定結果

NVIDIAは、B200 GPU（ドライバー615.71.09）とVAST DataのNFSストレージで測定しています。コンテナイメージの取得やインフラの準備時間は含まれていません。

結果から読み取れることは3つあります。

1. 起動に時間がかかる構成ほど短縮幅が大きい：最大の35.87倍は、通常の起動に1,110.65秒（約18.5分）かかっていたDeepSeek-V4.1-Flash（GPU8枚）で出ている
2. 大型モデルでも1分以内：GPU8枚の構成でも、復元は42.7秒以内に収まった。内訳はGPU側の復元が18〜29秒、CPU側（CRIU）の復元が4.2〜10.8秒
3. 保存の時間はすぐ回収できる：チェックポイントの作成には15秒〜約5.5分かかるが、構成ごとに1回だけ。測定したすべての構成で、「保存＋復元」の合計が「通常の起動1回」より短かった

クラウド事業者の検証（HGX B300）でも効果が出ています。CrusoeはGLM-5.3のPodが使える状態になるまでの時間を約8分から31秒に、Saturn CloudはvLLMの起動時間を2〜8.5分から6〜34秒に短縮しました。

制約

• ハードウェアの一致：保存したときと同じGPUモデル・同じドライバーのノードにしか復元できません
• 保存データの大きさ：保存データは約8GB〜1TB超になります（例：SGLangでgpt-oss-120bをTP4で動かした場合は693.89GB）。CPU側の復元時間はストレージの読み出し速度に依存し、公開されている測定は1種類のストレージ構成だけです
• 対象範囲：1ノード内の複数GPUまでが対象です。複数ノードにまたがる構成は扱われていません
• 成熟度：NVIDIA Dynamo（NVIDIAの推論基盤）との連携ガイドは「実験的」とされています

まとめ

• LLMの推論サーバーは、起動・モデル読込・初期化・最適化の4段階を毎回実行するため、起動に数分〜十数分かかる
• NVIDIA Snapshotは、準備完了時点のCPU・GPUメモリをチェックポイントとして保存し、新しいPodはそこから復元する
• 通常の起動より8〜36倍速く、GPU8枚の大型モデルでも43秒以内に回答できる状態になった
• 同じGPU・ドライバーでしか復元できず、復元時間は保存先ストレージの速度に左右される

あわせて読みたい

• ③ Dynamo：KVキャッシュをデータセンター全体で再利用する
  起動した推論サーバーでKVキャッシュを再利用する仕組み
• Agent Substrate：待機の長いエージェントを少数のPodで動かす
  同じくPodの起動待ちを減らす、エージェント向けの仕組み
• OpenShell：AIエージェントの実行環境とCNCFへの寄贈
  同時に発表された部品の全体像

参考

• Start and Restore GPU Workloads in Seconds with NVIDIA Snapshot（NVIDIA Technical Blog）
• NVIDIA Expands Open Source Commitment With OpenShell Donation and New AI Infrastructure（NVIDIA Blog）
• ai-dynamo/snapshot（GitHub）