汎用から所有・特化への揺り戻しと、制御を手にする代償

JVMにWasmが載るParquetパーサー、そしてQuarkusのランタイム最適化

6月22日時点のJava界隈で目を引くのは、Endive 1.0.0とHardwood 1.0.0のGAリリースだ。

EndiveはJVMネイティブのWebAssemblyランタイム。Chicoryという既存プロジェクトをルーツに持ち、DylibsoのBenjamin EckelとIBMのAndrea Peruffoが作ったものがベースになっている。1.0.0で注目なのが二つ。WasmGCのexternref値型をJava Objectとして扱えるホスト連携と

（WasmGCはWebAssemblyでガベージコレクションをサポートする仕様で、これにより高水準言語のメモリ管理を効率的に行える）、不要なスタックフレーム割り当てを削るテールコール最適化。後者はCPythonのようなインタープリタループでテールコールを採用している言語に効く。JVM上でWasmを動かす選択肢が実用段階に入りつつあると読める。ただ、どの程度のオーバーヘッドが残るのか、本番ワークロードでどこまで耐えられるかはまだ分からない。

Hardwood 1.0.0はApache Parquet専用パーサー。close()の冪等性修正でパフォーマンス回帰を解消し、AvroRowReaderがDECIMALやUUIDの列プロジェクションを正しく扱うようになった。またHardwoodContextでデコーダのスレッドプールサイズを制御できる。データパイプラインでParquetを読む層に選択肢が増えた形だ。

Quarkus 3.37.0ではJLink拡張が実験的追加に。jlinkで必要なJDKモジュールだけを含むカスタムランタイムイメージを生成する。コンテナイメージのサイズ削減に直結するし、起動時間も短くなるはず。あとJacksonのリフレクションなしシリアライザがデフォルト有効になった。マイクロサービスの実行時オーバーヘッドを減らす流れが明確になっている。

LangChain4j 1.17.0はDebatePlannerクラスが目新しい。Debateエージェントパターンをサポートするというが、複数エージェントが対立する主張をぶつけ合うアプローチなのか、それともプロンプト上の工夫なのか。具体的な挙動については今後のアップデートを追う必要がある。OracleChatMemoryStoreでOracleデータベースをチャットメモリに使えるようになった点は、エンタープライズ寄りの選択として理解できる。

Azul Payara 7.1.0はAdmin ConsoleとREST管理インターフェースのCSRF・SSRF脆弱性修正が含まれる。セッション情報から取得できるREST URLを不要にリクエストで渡していたのが原因。Spring Frameworkの@TransactionalアノテーションでJakarta Dataリポジトリインターフェースのメソッドをオーバーライド可能にした点も、Spring移行組織には意味があるだろう。

Eliya JDKはAsymm SystemsによるOpenJDKダウンストリームディストリビューション。四半期のOpenJDK 25 CPUを追従し、Linux x86_64とaarch64向け。最初のバージョンは25.0.3。Open Source Sustainability InitiativeはHeroDevsとCommonhaus Foundationの設立によるもの。End-of-Lifeのオープンソースリスクに対処する取り組みだ。

WildFly 41のベータも出ている。グレースフルシャットダウン中のトランザクションデータ処理と、Elytronサブシステムでの認証リクエスト署名・暗号化対応が入る。

特化モデルが汎用モデルに勝つという賭け

Base44が自社製AIモデル「Base One」を発表した。vibe coding、つまり自然言語の指示でWebアプリを生成する分野に特化したモデルだ。同社は「アプリ生成プラットフォーム初の独自モデル」と主張している。ただし、これはスクラッチから学習した基盤モデルではない。オープンソースLLMをファインチューニングしたものだ。「独自モデル」という言葉の使い方、業界全体が緩い。

興味深いのは学習手法。強化学習ベースで、実際のプラットフォーム上でアプリを構築・編集させるタスクを繰り返し実行し、出力の良し悪しをスコアリングして重みを更新している。学習データの大半は、このプラットフォーム上での実行と強化学習フィードバックから生成されたもの。すでに本番環境でユーザーに提供されている。

CEOのMaor Shlomoは、ClaudeやGPTのような汎用フロンティアモデルはWeb開発からGPUカーネル、C++、中国語の詩まで何でもこなすように訓練されていると指摘する。Base44の賭けは、自然言語プロンプトを動作するWebアプリに翻訳し、デザインやプロダクト判断を組み込んだ特化モデルなら、その用途において汎用モデルを上回るというものだ。「多くのユースケースでは、フロンティアモデルは最善の選択ではないかもしれない。特に自社のニーズに合わせて制御・適応・アライメントできるなら」とShlomoは語る。

この判断の背景にはコストがある。推論コストはAIネイティブビジネス最大のコスト要因だ。自前でモデルスタックを持てば、計算資源と推論支出を直接制御できる。外部ベンダーへの依存を減らせるのは、ビジネスとしての安定性にも直結する。

Wixが8000万ドルでBase44を買収したのは昨年のこと。買収後、売上は300万ドルから1億5000万ドルへ、1年未満で急成長した。モデル開発はWixの機械学習・データサイエンスチームとの協業で進められている。Wix Harmonyを構築したチームだ。Base OneはBase44のエージェントハーネス、つまりツール・指示・プラットフォーム内でのエージェント動作にチューニングされている。

競合はLovable, Replit, Bolt, Figmaなど。Shlomoは今回のモデルリリースで競争環境が根本的に変わるとは予想していない。品質と効率の優位性として捉えている。Base Oneは一連のリリースの最初であり、より大きなモデルと深いプロダクト統合が計画されているそうだ。

特化モデルが汎用モデルに勝つという主張は、実際のところユースケース次第だろう。Webアプリ生成という限定された領域で、プラットフォーム固有のタスク・ツール・制約に最適化されたモデルが、汎用モデルより安定した出力を出す可能性はある。ただし、特化することで失うものもある。汎用モデルは日々改良され、数週間単位で能力が跳ね上がる。特化モデルはその波に乗れるのか。ベースモデルの進化を取り込む追従コストはどうなるか。ここが実務上の論点になる。

ノートブックはPythonのものだった

JetBrainsがKotlin Notebookの終了を発表した。2023年7月のローンチから約3年。IntelliJ IDEA 2026.2でプラグインをアンバンドルし、ソースコードをApache 2.0で公開する。ただし2026.3以降の互換バージョンは出さない。引き取り手が現れても、いきなり互換性の崖に直面する構造だ。JVMエコシステム責任者のMarco Behlerは「期待した採用レベルに達しなかった」と認めている。

タイミングが妙だ。Microsoftが2月にPolyglot Notebooksを非推奨にしたばかりだからだ。VS CodeでC#などをJupyter形式で動かす拡張で、インストール数180万超、星4つ。それを1ヶ月の告知期間で終了させ、「AI駆動のコーディング体験」へ向かうよう案内した。両社ともAIを退場理由に挙げている。

確かにAIツールは探索的コーディングの一部を代替している。プロトタイプを対話で試すなら、ノートブックよりチャットの方が早い場面はある。でも、それで説明がつくのかというと怪しい。GitHubのOctoverseレポートを見ると、Jupyter Notebookを含むリポジトリは140万から242万へ75%増。AIタグ付きリポジトリでのJupyter使用はほぼ2倍になり、40万プロジェクトがアクティブに動いている。ノートブックそのものは衰退していない。Google Colabに至っては、2025年6月にAIファースト版をロールアウトした。エージェント機能をノートブックに組み込む方向で、捨てる方向ではない。

要するに「ノートブック」が終わったのではなく、「Python以外の言語でノートブックを習慣にする試み」が終わったのだと思う。Jupyterのカーネルプロトコルは言語非依存に設計されている。技術的にはKotlinでもC#でも繋げる。でもノートブックの実践文化、探索的分析、インライン可視化、生きたドキュメントとしての共有、これらはPythonのデータサイエンス領域で育った習慣で、アプリケーション開発者の日常とは合わなかった。JetBrainsはそれをIntelliJのKotlin層に持ち込もうとした。MicrosoftはC#と.NETコミュニティで同じことを試した。どちらもPythonでのJupyterのような定着を見なかった。AIは都合のいい退場口かもしれない。

JetBrainsにとってこの決定は全体の再調整の一ピースに過ぎない。同社は6月初旬に120億パラメータのコーディングモデルMellum2をオープンソース化している。ニッチなプラグインを捨ててフロンティアモデルを公開する。IDEのあり方がAIネイティブなツールに押されている中で、JetBrainsが未来を見ている場所は明確だ。Kotlin開発者にデータサイエンティストのように働いてもらうこと、ではない。

APIを呼ぶだけじゃ済まない世界線へのシフト

PalantirがNvidiaと組んで「インテリジェントエンジン」を発表した。中身はNvidiaのオープンウェイトモデル群Nemotronを、エアギャップ環境で動かし、

（エアギャップとは、外部ネットワークから物理的・論理的に完全に遮断された環境のこと）カスタマイズし、継続的に改善するための仕組み。注目すべきは、Palantirがモデルそのものではなく「モデルをデプロイし所有するための装置」を出した点だ。

なぜこれが必要なのか。政府機関や重要インフラの運営者は、データをセキュアなネットワーク外に出せない。OpenAIやAnthropic、GoogleのAPIエンドポイントは、そうした制約とは相容れない。ホストされたエンドポイントは論外。データもモデルウェイトも自分の手中に置く、それが前提になる。

Nemotronは3サイズ展開。Nanoが約31.6Bパラメータ、Superが120B、Ultraが550B。ハイブリッドのMamba-Transformerによる mixture-of-experts 設計で、トークンあたりのアクティブパラメータは全体の約1割。見かけのパラメータ数より安く動く。コンテキストウィンドウは最大100万トークン。重みとトレーニングデータ、レシピが許容ライセンスで公開され、vLLMやSGLang、llama.cpp、Ollamaなどのオープンランタイムで動く。NvidiaのNIMマイクロサービスとしてもデプロイ可能だ。

ベンチマークの絶対スコアではDeepSeekやQwen、Kimi K2に軍杯が上がる。だがNemotronの売りはNvidiaシリコン上での効率性と、真正なオープン性。エアギャップの奥で自前ハードウェアを回す用途では、まさにこの軸が効いてくる。

Palantir側の貢献は3つのエンジニアリング面。デプロイ（ベースモデルとカスタムモデルを分類ネットワークに載せる）、コンテキスト（プロンプトやワークフロー構造、運用時のモデル挙動）、モデル（独自データとミッション成果に基づいてウェイト自体を変える）。下敷きになるのはAIP、Ontology、Foundry、Apolloの既存スタック。データ認可、隔離の強制、監査可能性を担う。「自己改善」という謳い文句はテレメトリループで、使用データとトレースデータを捕捉してポストトレーニングとアライメントに回す仕組み。ただし評価ハーネスなしのフィードバックループはドリフトの温床。ここにどれだけの運用規律を注げるかが肝だ。

そして所有のコスト。モデルを自分で持つということは、スタック全体を自分で持つということ。GPUの資本支出、電力と冷却、推論スタックのパッチと性能維持、ファインチューニングから評価、ロールバックまでのモデルライフサイクル、切断されても消えないセキュリティ負担。Ultraクラスの550Bモデルを動かすには、アクティベーションが1割でもマルチGPUサーバーノードが要る。法規でホストAPIを使えない機関にとっては、これが単に仕事のコスト。使える側は、統制とデータレジデンシと、運用のコストとを天秤にかけることになる。「どのモデルを呼ぶか」から「どのモデルを自分で所有・運用するか」へ。問いが変わった。

インクリメンタルMIDXのrepackがGit 2.55で実用段階に入る

Git 2.55がリリースされた。100人以上の貢献者が参加し、うち33人は初めてのコミットという規模のアップデートだ。

個人的に注目しているのはインクリメンタルMIDXのrepack対応。これまでMIDXチェーンを扱うには、自分でレイヤーを管理するか、古い単一ファイル方式で我慢するしかなかった。Git 2.55からはgit repack --write-midx=incrementalで直接書き出せるようになった。

なぜこれが重要か。大規模リポジトリでは、packfileが日々のfetchやpush、メンテナンスタスクでどんどん増える。MIDXは複数packにまたがる単一インデックスを提供する仕組みだが、

（MIDXはマルチパックインデックスの略で、Gitが大量のオブジェクトを効率的に検索するための索引ファイルである）単一ファイルで全packをカバーすると、小さな更新でも大きな書き込みが発生する。インクリメンタルMIDXはGit 2.47で導入された方式で、チェーンとしてレイヤーを積み重ねる。追加は既存レイヤーを変更しないので、メタデータの書き直しコストを抑えられる。

ただしappend-onlyだとレイヤーが無限に増える。そこで--geometric=2との組み合わせ。repack.midxSplitFactorとrepack.midxNewLayerThresholdの2つの設定値で、いつレイヤーを統合するかを制御する。新しいレイヤーの累積オブジェクト数が、1つ古いレイヤーのrepack.midxSplitFactor倍を超えたら統合するという判定だ。

実務でどこが変わるか。Kubernetes上で動くCIパイプラインや、定期的なgit maintenanceを組んでいるチームにとって、repack時のI/O負荷と所要時間の予測が立ちやすくなるはずだ。これまでは「フルrepackを走らせるか、レイヤーを放置するか」の二択になりがちだった。幾何学的repackとインクリメンタルMIDXの組み合わせは、その中間を埋める手法と言える。

懸念がないわけではない。repack.midxSplitFactorの最適値はリポジトリの成長パターンに依存するはずで、デフォルトのまま放置していいのかは分からない。実際に手元で試していないので断言は避けるが、オブジェクト数の増減が激しいリポジトリでは調整が必須になるかもしれない。

他にもgit-history fixupコマンドやLinux向けfsmonitorデーモンなどが入っているが、インクリメンタルMIDXのrepackほど「既存の運用パターンを変える可能性」を感じる機能は今のところない。

まとめ

APIを呼ぶだけ、汎用を使うだけの世界から、自分で持ち、最適化する方向へ動いている。PalantirとNvidiaはエアギャップでのモデル所有を打ち出した。Base44は汎用モデルに頼らず特化モデルを自前で動かす。QuarkusがJLinkでランタイムを削り、GitがインクリメンタルMIDXでrepackを細かく制御する。用途に合わせて切り詰める流れだ。

制御を手にする代償。小さくはない。モデルを自分で持つなら、GPUの調達からスタックのパッチ、ドリフトの監視まで全てが自己責任になる。特化モデルを選べば、汎用モデルの急激な進化に追いつくコストと向き合うことになるだろう。GitのインクリメンタルMIDXも、設定値をリポジトリの成長に合わせて調整する前提だ。便利なものを丸ごと受け取るのではなく、自分でチューニングする前提が増えている。

Kotlin Notebookの終了は、この文脈で別の意味を持つ。JVMや.NETの開発者がPythonのデータサイエンティストと同じ習慣を自分たちの手に収めようとした。だが、文化として定着しなかった。制御や所有を望む動きが強まる一方で、土俵そのものが違う領域へ無理に乗り出すことの難しさも見えてくる。

実務に落とし込むなら、「制御できること」が正解とは限らない。APIを呼ぶ手軽さと、所有する重さの天秤だ。自前で持つことで得られる安定性やコスト予測の恩恵が、運用の負担を上回る場所で初めて選ぶべき判断なのだろうか。

参照記事

記録日: 2026-06-30