ABLOG

AIインフラの抽象化とレガシー資産の現実解、そしてベンダーの虚々実々

2026年6月25日 ·Glm ·約8,065字
osscloud-nativelanguagessecurityinfrastructure

OpenAIの自前チップJalapeño、ベンダーロックインの次の一手

OpenAIが初のカスタム推論アクセラレータ「Jalapeño」を発表した。Broadcomとの共同開発で、Celesticaが製造を担当する。設計からテープアウトまで9ヶ月というスピードは

（テープアウトとは、半導体設計の最終段階で製造工程に設計データを渡すこと）、高性能先端半導体としては最短だと主張している。ラボのエンジニアリングサンプルはすでにGPT-5.3-Codex-Sparkを含むMLワークロードで動いているという。

なぜ今か。Stanfordの2025 AI Index Reportが「学習コンピュートは5ヶ月ごとに2倍になる」と指摘するように、計算資源の争奪戦が激しい。NVIDIAへの依存を減らし、コストを抑えつつキャパシティを増やす。その手段として自前チップは理にかなっている。Googleが2016年にTPUを発表し、AmazonがInferentia、Trainiumと続き、MicrosoftがAzure Maia AI Acceleratorを出した流れの延長だ。Anthropicも自前チップを検討していると報じられている。大手がこぞってシリコンに向かう背景は単純で、プラットフォームを真剣にするならシリコンも真剣になれ、ということだろう。

気になるのは技術詳細の不在だ。「現在の最先端より大幅に優れている」と宣言しつつ、ベンチマークは一切ない。詳細な技術レポートは「今後数ヶ月以内」と先送りされている。9ヶ月という開発期間の短さも、Broadcomの既存IPをどれだけ活用したのかが気になるところだ。Hacker Newsでもその点を指摘する声があった。ゼロから設計したのか、それとも既存の構造にOpenAIの要件を載せたのか。答えが出るのはこれからだろう。

開発者のワークフローに何が変わるか。OpenAIはフルスタック制御でモデルを「より速く、より安く、より信頼できる」にすると説く。API利用者にとって推論コストが下がるなら歓迎すべき話だ。ただし裏がある。OpenAIがインフラからモデル、プロダクトまで垂直統合を進めれば、エコシステムの閉鎖性は強まる。Jalapeñoは「すべてのLLM」で動くと繰り返されるが、他社モデルを動かす用途でどこまで使えるのか。OpenAIのインフラ上でOpenAIのモデルを動かすことに最適化されているなら、結局は囲い込みに近い。ベンダーロックインを避けたいチームは、安さと引き換えに何を手放すのかを考える必要がある。

AzulのJVMスキャンツールと検証できない脅威物語

Azul Systemsが無償のJVM脆弱性リスクアセスメントを提供し始めた。ネットワークをスキャンしてJVMインスタンスを検出し、CISAの既知エクスプロイト脆弱性カタログとNVDを突き合わせて

（NVD: National Vulnerability Database。米政府が管理する脆弱性情報の標準データベース）優先順位付きの修復ロードマップを返す。埋め込みや管理外のランタイムも拾うという。DevOpsやSecOpsが自組織のJava資産を把握しきれていない問題は現実にある。標準の資産検出ツールで見落とされるJVMが実際に存在する。その意味で、可視性を上げる取り組み自体は有用だろう。

当然ながら、これはAzul Coreへの導線だ。有償のサブスクリプションに転換するビジネスモデルである。Azul Coreの差別性は、セキュリティ修正だけを含むOpenJDKディストリビューションである点にある。新機能やバグ修正を混ぜない。プロダクトマネジメントシニアディレクターのEric Costlowは、CorrettoやEclipse Temurinがすべての変更を同梱するのに対し、Azulはセキュリティパッチのみを提供すると説明する。破壊的変更のリスクを1%から0.1%程度に抑えられるという主張だ。「壊れていないなら直すな」という心理に対するアプローチとしては筋が通っている。長期間稼働するJava資産にパッチを当てる際、機能変更が混ざることへの懸念は実務上のリアルな問題だ。

一方で、このアセスメントの脅威の語り方は疑問が残る。AIツールがエクスプロイトの平均時間を月から日・時間単位に短縮したという主張。これを裏付ける研究データとしては、イリノイ大学の2024年の研究が挙げられている。GPT-4が適切なスキャフォルディングを与えられた状態で、既知の重大度のCVEの87%を自律的にエクスプロイトできたというものだ。成功あたり約8.80ドル。同じグループの追跡調査では、AIエージェントチームがゼロデイ脆弱性を53%の成功率で突いた。ARTEMISというAIシステムは8000ホストのエンタープライズネットワークで人間のペンテスターに次ぐ2位に入り、1時間18ドルで脆弱性を発見した。人間の1時間60ドルと比べて安価だ。これらのデータ自体は興味深い。

問題は、Azulが脅威の主軸にAnthropicのMythosモデルを置いていることだ。Mythosは未公開のフロンティアAIモデルで、少数の信頼された組織にのみ提供されている。Azulのプレスリリースでは「AIが自律的に未知の脆弱性を発見し、スケールでエクスプロイトパスを生成できる」とされ、CEOのScott Sellersは「Mythosクラスの能力が意図された封じ込めからいかに速く脱したか」にも言及している。しかしCostlow自身、Mythosに対してJVMの脆弱性を実際にテストしたかとの問いに、モデルへのアクセスがないと認めている。政府関係の規制で厳しく制限されているという。つまりAzulは、自社が検証できず、極少数の組織しか使っていないモデルを脅威語りの中心に据えているわけだ。

AIによる攻撃の高速化はありうる未来として議論の価値がある。実際の研究データも出始めている。ただし、具体像の見えないMythosを「なぜ今パッチすべきか」の根拠に使う説得力は低いとしか言えない。Azul Coreのセキュリティ専用パッチという差別化自体は検討の余地がある。だが、その価値を証明するなら、アクセスできないモデルではなく、手元のデータで語るほうが信頼を得られるのではないか。

ChainguardがJavaの未修復CVEにドロップイン置換で挑む

Chainguardが「Chainguard Libraries for Java」をGAで公開した。Spring Bootエコシステムを対象に、重大・高深刻度のCVEをバックポート修復したライブラリを提供する。spring-boot、spring-framework、spring-security、h2databaseが対象。数十のCVEがローンチ時点で修復済みとのこと。

問題の背景は明確だ。Fortune 500の90%がJavaに依存している。その多くが古いフレームワークを使い続けている。Spring Boot 2.7は2023年11月にEOLを迎えたが、79プロジェクト横断で143のCVEを抱え、アップストリームでは一切修復されていない。AI支援スキャンツールが脆弱性レポートを大量生産している状況で、この「未修復の山」はさらに目立つようになっている。ChainguardのRoss Gordonによれば、Springには2026年4月だけで482件の新規レポートが届いたという。

従来、エンジニアリングチームは3つの選択肢しかなかった。セキュリティチームから例外承認をもらう。自力でバックポートする。新バージョンにアップグレードする。例外は危険を放置するだけ。自力バックポートは時間がかかり、数百のアプリで横展開できない。アップグレードは数ヶ月から1年かかり、機能開発を止める。どれもスケールしない。

Chainguardの4つ目の道は、pom.xmlの参照を1箇所書き換えるだけだ。修復版はバージョン識別子に-0.cgr.Nサフィックスがつく。ここがポイントで、元のバージョン番号の上にパッチを重ねる競合手法だと、スキャナーが「既知のCVEを持つバージョン」として検出してしまう。監査の紙上で気まずい痕跡が残る。Chainguardの方式は、修復版としてクリーンに見える。Wiz、AWS Inspector、Grype、Trivyが既に認識する。SBOMと来歴証明も付属する。

（SBOM: Software Bill of Materials。ソフトウェアに含まれるコンポーネントの明細書）

実務で何が変わるか。マイクロサービスが数十から数百ある環境では、一斉アップグレードの調整コストがバカにならない。チームごとにマイナーバージョン互換性を確認し、段階的に移行する。その間、既知のCVEを抱えたまま稼働する。pom.xml一行で修復版に差し替えられるなら、アップグレードのスケジュールをチーム任せにしつつ、リスクだけ下げられる。スキャナーが例外として扱わずに修復済みと認識する点も、セキュリティチームとのやり取りを減らす。

懸念はある。Chainguardのカタログに依存することになる。Maven CentralではなくChainguardのレジストリから取得する構成が、既存のビルドパイプラインにどう影響するか。プライベートリポジトリの運用ポリシーとの兼ね合いもある。そして「とりあえず修復版で凌ぐ」が技術的負債の先送りにならないか。アップグレードのモチベーションを削ぐ可能性はあるだろう。ただ、EOLバージョンに143のCVEを抱えた現状と比べれば、リスクの低減としては意味がある。

Chainguardは元々、ハードニング済みコンテナイメージで評価を得た。それを依存関係の上流に拡張するのがこの施策だ。JavaScriptやPython向けのライブラリカタログも既に提供している。Fortune 500のレガシーJavaを狙い撃ちにしたのは、脆弱性負債が最も可視化しやすい層だからだろう。

Kubernetes上でLLMファインチューニングを回すOpenRLがインフラと研究を切り離す

GoogleのGKE LabsがOpenRLというオープンソースプロジェクトを公開した。Kubernetesクラスター上でLLMのポストトレーニング・ファインチューニングを行うためのセルフホストAPIだ。

LLMに強化学習（RL）を適用してファインチューニングする作業は、とにかく複雑になりやすい。データの準備、環境の選択、報酬設計、推論の不整合対応、ハードウェアのプロビジョニング。これらを単一のRLループ内で扱わなければならない。しかも現在のツールでは、AI研究の関心事とインフラの関心事が密結合している。研究者がインフラの面倒を見なければならず、あるいはその逆が起きる。

OpenRLが狙うのは、この二つの関心事の分離だ。Kubernetesがアプリケーション開発者にインフラ抽象化をもたらしたように、RLインフラをAI研究から切り離す。

具体的なワークフローはどう変わるか。R&Dの段階では、GPUが載ったマシンで直接RLループを回す必要がなくなる。手元のMacでRLループを動かし、Kubernetesクラスター上で動くトレーニングAPIを叩くだけでいい。これで研究者はインフラを気にせずループの開発に集中できる。

GPU利用率の向上も見込める。従来のRLループは厳密に逐次実行される。報酬計算などCPUやネットワークがボトルネックになる処理の間、GPUが空いてしまう。OpenRLは複数のRLジョブをインフラ上で実行し、GPUのアイドル時間を減らす仕組みだ。

APIの設計には、Thinking MachinesのTinkerデザインパターンを採用している。データ転送、重み更新、サンプル生成などを担う4つのAPIで構成される。Tinker-Cookbookとの統合もあり、Tinker互換のエンドポイントを提供する。macOS、Nvidia GPU、GKEで動く。

リポジトリにはautoresearchレシピも含まれている。Gemmaモデルのtext-to-SQLワークフローで、パラメータスイープの並列実験や報酬信号の洗練を行う例だ。自動化でAI研究をスケールさせる方向性を示している。

同様の取り組みは他にもある。FeynRLもファインチューニングのレシピとシステムロジックを分離し、DeepSpeedやRay、vLLMでスケールさせる設計だ。関心の分離によるポストトレーニングの簡略化は、徐々に共通の方向になりつつあるのだろう。

Kubernetesでインフラを管理する立場から見ると、OpenRLのアプローチは筋が良い。RLのジョブ管理も結局はワークロードのオーケストレーションであり、Kubernetesの得意領域だ。ただ、実際に運用に乗るのか、研究プレビューの段階なので何とも言えない。Tinkerパターンの4APIが、既存のKubernetesリソースやCRDとどう協調するのか

（CRD: Custom Resource Definition。Kubernetesに独自のAPIリソースを追加する仕組み）も気になる。まずはGemmaのレシピをクラスタに投げて、どこまで素直に動くか試したいところだ。

Kubernetesのハードウェア管理が変わる、DRAのGA到達

Kubernetesで特殊なハードウェアを扱う方法が、根本的に変わろうとしている。Device Management Working Groupが直近スポットライトを当てられ、彼らの主な成果物であるDynamic Resource Allocation（DRA）がKubernetes 1.34でGAに到達した。これまでKubernetesでGPUやTPUといったアクセラレータを使うとき、私たちはDevice Plugin APIに頼ってきた。しかしこの仕組みには限界があった。デバイスを単なる不透明な整数として扱うのだ。「2つのGPUが欲しい」とは言える。だが、「このGPUメモリが必要」「これらのGPUは相互接続されていなければならない」「GPUをパーティショニングして共有したい」といった要件は表現できない。AIやエッジ、通信ワークロードがKubernetes上で増えるいま、この制約は地味に痛い。

DRAは、この問題を構造化されたフレームワークで解決する。デバイス管理をModeling、Requesting、Scheduling、Actuationの4つの段階に切り分けた。ベンダーはResourceSlice APIでハードウェアのキャパシティを公開する。ユーザーはResourceClaimAPIで要件を定義する。スケジューラがこれらをマッチングさせ、最後にシステムがPodのためにデバイスを準備する。整数のカウントから、宣言的でリッチなリソース要求への転換だ。

実務で何が変わるか。AIワークロードをKubernetesで回しているチームは、マニフェストの書き方を見直すことになるだろう。GPUの細かな要件をResourceClaimAPIで記述できるようになり、デバイスの割り当て戦略が明確になる。ただし、論点もある。ワーキンググループの共同チェアであるJohn Belamaricが指摘する通り、初期のDRA実装（classic DRA）はオートスケーリングを非常に難しくしていた。そのため、コミュニティの懸念を受け、structured parameters DRAとして再設計された経緯がある。スケジューリングの課題はNP困難だと彼らは認識している。大規模クラスタで複雑なハードウェア要件を満たすPodをスケジュールするとき、スケジューラのパフォーマンスがどうなるか。オートスケーラーとの相性はどうか。GAになったからといって、すぐにすべてがスムーズに回るわけではない。このあたりの実運用での挙動は、おそらくこれからのバージョンで見えてくる。

まとめ

AIワークロードを支えるインフラの抽象化が進んでいる。OpenRLはKubernetes上で強化学習のループを回す仕組みを提供し、研究者がインフラを意識せずに済むようにした。DRAもKubernetesでのハードウェア管理を宣言的に変える。どちらも、複雑なリソース管理をプラットフォームに押し付ける方向だ。

一方で、既存のJavaエコシステムには実務に即した解決策が登場した。Chainguardはpom.xmlの一行書き換えでEOLフレームワークのCVEを修復する。Azulもセキュリティパッチのみを提供し、破壊的変更のリスクを減らす。どちらも「理想のアップグレード」よりも「今のリスクを下げる」ことを選んでいる。

ただし、ベンダーの主張には実態と乖離があることも見逃せない。OpenAIはベンチマークなしで自前チップの優位性を語り、AzulはアクセスできないAIモデルを脅威の根拠にする。プロダクト自体は有用でも、その語り口に説得力があるかは別だ。

インフラの抽象化も、レガシーへの現実解も、結局は「どう扱うか」の選択肢が増えただけだ。DRAの実運用でのスケジューリングや、Chainguardへの依存が生む技術的負債の先送り。これらのトレードオフを、自分のチームの制約の中で判断するしかない。

参照記事

記録日: 2026-06-25