推論チップの専用化からエージェント基盤のロックインまで、プロダクションで迫られるトレードオフ

Gemini専用チップ「Frozen v2」が示す、推論インフラのASIC化への転換

GoogleがGeminiモデル専用のチップを開発していると報じられた。The Informationの報道によると、プロジェクト名は「Frozen v2」。アーキテクチャの一部をシリコンに直接刻み込む一方で、モデルの重みは更新可能にする設計だという。内部試算では、現在のGoogle製AIチップと比べてワットあたりのトークン処理量が6〜10倍に達すると見込まれている。

なぜこの話が気になるか。推論のコスト構造が変わろうとしているからだ。これまでAIの推論は、NvidiaのGPUかGoogleのTPUなど、汎用的なアクセラレータで賄われてきた。さまざまなモデルに対応できる柔軟性がある反面、処理のオーバーヘッドを抱えている。BitcoinマイニングがCPUからGPU、そしてASICへと移行したのと同じ軌道を、AI推論も辿り始めている。

（ASIC：特定用途向け集積回路。汎用的な計算ではなく、特定のアルゴリズムのみをハードウェアレベルで高速処理する設計）訓練には汎用性がまだ有利だが、いざ本番のサービングとなれば、いかに多くのリクエストを低電力で捌くかが勝負になる。

Frozen v2の面白さは、アーキテクチャを固定しつつ重みは更新可能にした妥協点にある。Jeff Deanが主導した以前の構想では、重みごとシリコンに埋め込む計画だったという。だがこれではGeminiがバージョンアップするたびにハードウェアが陳腐化する。だからやめた。モデルの構造だけを「凍結」し、中身の重みは書き換えられるようにした。ハードウェアの寿命を保ちつつ、専用チップの効率を拾うバランスだ。

周辺も動いている。カナダのTaalasは、80億パラメータのLlamaモデルを丸ごとチップに埋め込み、秒間約17,000トークンのスループットを主張している。d-MatrixのCorsairプラットフォームはSRAMベースのインメモリコンピューティングでHBMへの依存を減らす。NvidiaもGroqと200億ドルのライセンス契約を結んだと報じられている。推論特化の流れは、もう業界全体の動きだ。

では、開発者のワークフローはどう変わるか。APIを叩く側からすれば、裏側のチップが何であれレスポンスが返ってくればいい。だが、モデルとハードウェアの密結合が進めば、選択の自由度が減る可能性がある。特定のチップで最も効率よく動くモデルが、そのプラットフォーム上で価格競争力を持つ。GeminiをGoogle Cloudで動かすのが安いのは、Frozen v2があるから、という世界観だ。マルチクラウドでモデルを移植して使う今のやり方が、どこまでコスト的に見合うのか。その境界線が、チップの専用化とともに動いていく。

Value ObjectsがCandidateに復帰、Quarkus Shimでビルド時クラス変換

Project ValhallaのJEP 401「Value Objects (Preview)」がCandidate statusに再導入された。2020年8月のJEP Draft 8251554から長い旅だった。Value Objectsはfinalフィールドのみを持ち、アイデンティティを持たない。

（例：座標を保持するPointクラスにおいて、x=1, y=2であれば、インスタンスが別であっても「同じ点」として扱う設計）フィールドの値だけが等価性を決める。つまりプリミティブのような振る舞いをオブジェクトで実現する。メモリ配置が最適化され、ヒープのオーバーヘッドが減る。Goで値型を当たり前に使っている身からすると、Javaにもようやく、か。Preview段階であり、実務投入には時期尚早だ。安定版のリリース時期を注視したい。

Quarkusチームが新しい拡張「Quarkus Shim」を出した。ビルド時にJavaクラスの振る舞いを追加・ラップ・置換できる。Java agentもランタイム計装も不要。変換されたクラスはJVMモード、devモード、ネイティブモードの全部で動く。KubernetesでQuarkusを回しているチームにとって、ランタイムの計装が減るのは嬉しい。起動速度とコンテナイメージサイズに影響するはず。ただ「どのユースケースで使うのか」はまだ情報が少ない。フレームワーク側の内部利用が主になるのか、アプリケーション開発者が直接書くものなのか。ここは注視したい。

WildFly 41がGAリリース。bootable JARがcloud-galleon-packとwildfly-maven-pluginのfeature packsに追加された。コンテナ化のワークフローが少しシンプルになる。それより大きいのはJDK 25版のコンテナ・S2I builder・ランタイムイメージがJDK 17版を置き換えたこと。JDK 17で固定しているチームは移行タイミングを考える必要がある。

LangChain4j 1.18.0はBDIエージェントパターンの追加が目を引く。

（BDI：Belief-Desire-Intention。エージェントが「信じていること」「望んでいること」「意図している行動」を分離して管理する認知アーキテクチャ）Belief-Desire-Intentionをソフトウェアに形式化する手法で、AIエージェントの設計に構造を持たせるアプローチ。OpenAIのText-to-Speech APIサポート、Mistral Batch APIサポートも入った。AI周りのライブラリは週単位で変わっていく。

Open Liberty 26.0.0.7は8つのCVE対応。SSO cookieのログアウト追跡がデフォルトになった。TornadoVM 5.1.0はCUDAバックエンドでFP8をサポート。GPU推論の文脈で効く。Apache TomEE 10.2.0、Java Operator SDK 5.5.0、Micronaut 5.0.5もそれぞれパッチリリース。

Kimi K3のコスパと遅さ——Fable 5の3分の1で同じ結果を出す代償

Moonshot AIがリリースしたKimi K3は、2.8兆パラメータのオープンウェイトモデルだ。中国発としては最大。API価格は入力$3/Mトークン、出力$15/Mトークン。AnthropicのFable 5が入力$10、出力$50だから、ちょうど3分の1になる。

Rust製のファイル検索ツールfdを使った3つの実務タスクで、Fable 5と比較したベンチマーク記事が出た。バグ修正、リファクタ、機能追加の3本。結果は同じ。バグ修正のdiffに至ってはバイト単位で同一だった。ただし数値の差は大きい。

バグ修正テスト。K3は238Kトークン、$0.06、3分7秒。Fableは347Kトークン、$0.85、1分4秒。リファクタテスト。K3は928Kトークン、14分50秒。Fableは3分11秒。同じ結果でも、かかる時間は4倍近い。

面白いのはプロセスの違い。リファクタでK3は旧バイナリをスナップショットし、40シナリオで差分を取って動作が変わっていないか確認した。入念なエンジニアリングだ。ただしその分、時間もトークンも食う。

ここでの論点は「何を最適化したいか」だ。1回のタスクで$0.06と$0.85の差なら、多くのチームは後者を選ぶだろう。14分と3分の差は、エージェントループで対話しながら作業するワークフローでは致命的になる。思考と実行を繰り返すタイプの開発では、応答の遅さがそのまま生産性を殺す。

逆に、CIパイプラインに組み込んでバックグラウンドで回すなら話は変わる。コストが3分の1で同じ結果が出るなら、夜間バッチや自動リファクタの用途には向いている。オープンウェイトなので、オンプレでホストしてレイテンシを稼ぐ選択肢も出てくるかもしれない。

まだCursorなどのコーディングツールに統合されていない点も見落とせない。Kimi Code CLI（バージョン0.27.0）からは使えるが、普段の開発フローに溶け込ませるにはもう一段階必要だ。CLIで完結するタスクならともかく、エディタとの往復が多い作業では使いにくい。

コストか、速度か、ツールの統合か。どこで妥協するかで、選ぶモデルは変わるはずだ。

3大クラウドが描くエージェントアーキテクチャの共通項とロックインの罠

過去9ヶ月でAmazon、Microsoft、Googleが相次いでエンタープライズ向けのエージェントプラットフォームを打ち出した。Amazon Bedrock AgentCore、Microsoft Foundry（旧Azure AI Foundryから2026年1月リネーム）、Gemini Enterprise Agent Platform（Cloud Next 2026でVertex AIから統合）。注目すべきは、3社のアーキテクチャがほぼ同じ構成になっている点だ。ランタイム、メモリ、ツールゲートウェイ、アイデンティティ、オブザーバビリティ、ガバナンス。18ヶ月前までは断片的なライブラリの寄せ集めだったものが、明確なプラットフォームレイヤーとして固まりつつある。

この構成要素の一致は、2011年から2016年頃に起きたPaaSの進化と重なって見える。当時、開発者は仮想マシン、ロードバランサー、メッセージキューをそれぞれ異なるAPIで組み合わせてアプリを作っていた。Cloud FoundryやHerokuは、それらをアプリケーションコントラクトという形で統一した。マシンのことは考えず、アプリケーションのことだけを考えればよくなった。エージェントのエコシステムも今、同じ変曲点に来ている。ただし、決定的に足りないものがある。ポータビリティを担保するコントラクトだ。これを定義するオープンソースプロジェクトもまだ表れていない。

カスタマーサポートのエージェントをプロダクションに入れる場面を想像する。モデルを選び、フレームワークを選び、セッション状態と長期記憶のストアを置き、チケットシステムと繋ぐツールゲートウェイを用意する。ユーザーの代わりに動くアイデンティティレイヤー、コードを安全に実行するサンドボックス、品質の劣化を検知するトレーシング。一つひとつの選択は小さく見える。だが組み合わせると、ワークロードがどのクラウドに住むかが決まる。セッション状態はそのプロバイダーのマネージドストアに置かれ、トレースはそのプロバイダーのテレメトリサービスに吐き出される。1年後に別のクラウドへ引っ越そうとすれば、全体を組み直すことになる。PaaSがアプリにポータビリティを与える前の状態だ。

AgentCoreは2025年10月にGAとなった。8時間の実行ウィンドウとセッション分離を持つランタイム、MCPサーバーに接続しソフトウェア資産をツール化するゲートウェイ

（MCP：Model Context Protocol。AIモデルが外部データやツールにアクセスするための共通規格）、OpenTelemetry経由のCloudWatchへのエクスポートなどを備える。Microsoft Foundryもセッション分離されたマネージドランタイム、Entra Agent IDによるアイデンティティ、スコープ別のマネージドメモリ、同じくOpenTelemetryベースのトレーシングを提供する。Googleも基本構成は同じだ。各社はプロダクションエージェントの基盤としてこれらを提示しているが、実装の詳細はそれぞれのクラウドに深く依存している。

Cloud Foundryが市場を制覇しなかったように、今後のデファクトがどうなるかは分からない。Kubernetesが勝ったあとも、Cloud Foundryの設計原則はKorifiを通じて生き延びた。重要なのは実装ではなくコントラクトだった。エージェントの世界でも、各社のプロプライエタリなプラットフォームにロックインされるのか、それともオープンな規約の上でワークロードを動かせるのか。MCPやOpenTelemetryのような部分的な繋ぎは見え始めているものの、全体を統べるコントラクトは不在だ。Kubernetes上でマイクロサービスを動かすのと同じ感覚でエージェントをデプロイするには、まだ足りないピースがある。自分たちでその境界線をどこに引くか。インフラを管理する側としては、ロックインのリスクをどこまで許容するのか見極めが必要になる。

GitHub Sponsorsが1億ドル到達、組織スポンサーが変えるオープンソースの金流れ

GitHub Sponsorsを通じたオープンソースへの資金提供額が、累計1億ドルを突破した。2019年のサービス開始から積み上がった数字だ。現在、103地域で7万人以上のメンテナや組織が支援を受け、28万人以上のスポンサーが参加している。規模感としては一つの区切りと言えるだろう。

注目すべきはペースの加速だ。最初の1000万ドルに要した期間は約2年だった。ところが直近の1000万ドルはわずか5ヶ月で到達している。後半になるほど資金の流れが明らかに速くなっている。

この背景には、企業による組織スポンサーシップの一般提供が影響していると読める。2023年にこの機能がGAになったことで、ShopifyやMercedes-Benzのような大企業が自社が依存するプロジェクトへスケールして資金を投入しやすくなった。実際、2022年時点ですでにスポンサー資金の約40%が組織からのものであり、1件あたりの平均金額は個人スポンサーの約15倍に達している。個人の少額支援だけで1億ドルに到達したわけではない。企業の金額感がプラットフォームを牽引している構図だ。

開発者のワークフローという視点で見ると、ここで何が変わるのか。自分が普段書いているGoやTypeScriptのマイクロサービス、あるいはKubernetes上で動かしているコンテナ。それらが依存しているライブラリのメンテナが、スポンサーシップのおかげで全职でメンテナンスに専念できるようになる。Caleb PorzioやSebastián Ramírezがそうであるように、スポンサー収入で会社を辞めてプロジェクトに集中するメンテナが出てきている。これは自分のプロダクトの安定性に直結する話だ。メンテナの燃え尽き症候群や、放置された依存パッケージのセキュリティリスク。これらを「善意」に頼るのではなく、「ビジネスの依存関係」として金を回すことで解決しようとしている点に実務的な価値がある。

もちろん、1億ドルという数字がオープンソース全体の維持コストをどこまでカバーできているのかは分からない。資金が特定の人気プロジェクトに偏っている可能性もあるだろう。ただ、摩擦を減らす工夫（請求書払いや一括スポンサー機能の追加）が資金増加に直結したという事実は、金の流れ方が「善意」から「仕組み」へと確実に移行していることを示している。

まとめ

AIをプロダクションで回すための最適化が、ハードウェアからプラットフォームまで一気に進んでいる。推論チップのASIC化も、クラウドのエージェント基盤も、方向は同じだ。特定の構成に最適化してコストや効率を引き出す。その代わり、ポータビリティを手放していく。Frozen v2がGeminiとGoogle Cloudを密結合させるように、効率を追求すればするほど選択の自由度は減る。

モデルの選び方も同じトレードオフだ。Kimi K3はコストを3分の1に抑える代わりに、速度とツール統合を妥協しなければならない。バックグラウンドで回すバッチなら合う。だが、対話しながら開発するワークフローでは使いにくい。何を最適化したいかで、許容すべき制約が変わる。

問題は、その選択の自由度自体がプラットフォーム側に握られつつあることだ。3大クラウドのエージェント基盤は構成が一致している。しかし、ポータビリティを担保するコントラクトは不在だ。セッション状態やトレースがプロバイダーに依存すれば、1年後に別のクラウドへ引っ越すのは現実的ではない。ロックインのリスクをどこまで許容するのか。インフラを管理する側としては、プラットフォームの都合に合わせる前に、自分たちで境界線を引く必要がある。

オープンソースへの資金提供が「仕組み」に移行しつつあるのは、この状況への対抗軸になり得るだろう。企業が依存関係として金を回すことで、メンテナは全职でプロジェクトに集中できる。プロプライエタリなプラットフォームに依存するか、オープンな依存関係を金で支えるか。実務で何を守るかによって、リソースの割き方は変わってくる。

参照記事

記録日: 2026-07-21