Maven（Javaのビルドツール）を思い浮かべるソフトウェア開発者は少なくありません。そのビルド判断ロジックをニューラルネットワークの重み行列に焼き込み、実際にJavaライブラリをビルドさせたら出力がApache Mavenとバイト単位で一致した、という実験結果が報告されています。学習ではなく、プログラムをそのまま重みに変換した点が要になっています。
MavenはAIで速くなるのか――JetBrainsの実験が示した1.49倍の遅さ
JetBrainsのブログチームは、Mavenスタイルのビルドツールが持つ「意思決定部分」だけを取り出し、ニューラルネットワークの固定重み行列へコンパイルするという実験をおこないました。かみ砕いて言えば、Mavenが「どのライブラリのバージョンを採用するか」「どのファイルをコンパイラに渡すか」「テスト失敗時にビルドを止めるか」といった判断を下す部分だけを切り出し、AIのモデルの形に書き換えた、ということです。javacやJUnitそのものを動かす部分ではなく、判断のロジックだけが対象になっています。
対象にしたのはZXing 3.5.3というバーコード処理用のJavaライブラリです。親プロジェクトと、coreおよびjavaseという2つのモジュールを、テスト込みのクリーンビルドで実行しました。このZXingは「メンテナンスモード」にあるプロジェクトで、バグ修正と小規模な改善だけが受け付けられている状態だと、ZXing自身のリポジトリが説明しています。活発な開発が続くプロジェクトではなく、枯れた成果物を検証対象に選んだ形です。GitHub - zxing/zxing at zxing-3.5.3 · GitHub
結果として、このネットワークが出したビルド結果はApache Mavenの出力とバイト単位で一致しました。テストを含むクリーンビルドにかかった時間は、同じロジックをPythonで書いた場合の1.49倍だったと報告されています（95%区間は1.4倍から1.54倍、30回の対応ペア実行による測定）。物差しとして読むなら、Python実装を「1」とすると、ニューラルネットワーク版はおよそ1.5倍の時間がかかった、という比較です。AIが判断を担うからといって処理が速くなったわけではなく、むしろ遅くなっています。
この仕組みのもとになっているのが、Handwired（ハンドワイヤード）という手法です。たとえるなら、プログラムのif-elseや繰り返し処理を、足し算・掛け算・ReGLUという数個の基本演算だけで表現し直し、それらをひとつの巨大な行列演算にまとめてしまう、というやり方です。JetBrainsのチームはMaven互換のビルド制御ロジックを、制限されたPythonのサブセットで書き、それを29,625×7の数値の表（加えて定数7,382セル）へと変換しました。学習や勾配降下は一切おこなわれていません。ゼロ回の最適化ステップで、プログラムがそのまま重みになっています。GitHub - chenglou/handwired: Turn your regular JavaScript code into a neural net. · GitHub
動作の仕組みは、ループの繰り返しです。1ステップごとに、ネットワークは表の1行を2回の行列演算で読み出し、小さなレジスタファイル上でその行が指定する演算をおこない、結果をメモリへ書き戻します。ネットワーク自体はファイルを開いたりjavacを起動したりはできません。外部とのやり取りが必要なときは、メモリの決まった場所にリクエストを書き込み、「橋渡し役」がそれを外へ運んで生の回答を書き戻す、という構造です。この橋渡し役は何も判断しません。すべての選択は重みの側から出てきます。
Handwiredという土台が抱える境界条件
同じHandwiredという仕組みを別の角度から検証した記事があります。Chia-Feng Chu氏によるブログ投稿で、x > 4 ? 10 : 12という単純な条件分岐回路を作り、入力に4.25を与えた実験です。出典が述べているのは、宣言の仕方によって結果が変わりうるという境界条件です。範囲だけを宣言した場合は10という正しい結果が返りましたが、「xは整数である」という誤った宣言を与えたところ、より軽量な回路は11.5という値を返したといいます。グリッド（整数専用）の検証機構自体はこの入力を拒否したものの、コンパイル済みの評価器本体はそれを受け入れてしまった、という点が指摘されています。
この記事が強調しているのは、これは意図的に作られた矛盾する入力による検証用の例であり、Handwiredの汎用的な欠陥を示すものではない、という限定です。宣言（レンジ宣言かグリッド宣言か）によって軽量な構成が可能になる一方で、その宣言を真であると保証するのは呼び出し側の責任である、という設計上の境界がある、と筆者は説明しています。コンパイルされた演算グラフが参照実装と一致していても、呼び出し側が意図した離散的なプログラムを必ずしも実装しているとは限らない、という趣旨です。
筆者はNode 24.19.0上でリビジョン4ea7fcb27ebe93acf49b9f29a93e162b975bad46を検証し、ブラウザもWebGPUも学習もモデルの重みも使わず、CPU上でのグラフ構築と評価だけを対象にしたと明記しています。プロジェクト本来のテストスイート（Bunを使うもの）やGPUデモは実行していません。JetBrainsのブログが示したMavenの実験とは別の検証者による、Handwiredという基盤技術そのものの挙動確認だという点を押さえておく必要があります。FP32 Grids and a Branch That Returned 11.5 | Chia-Feng Chu
判断ロジックを重みに変えるという発想の射程
JetBrainsが示したのは、プログラムの判断部分をニューラルネットワークの重みへそのまま変換すれば、学習済みモデルのように「だいたい正しい」のではなく、入力が同じなら必ず同じ結果を返す仕組みが作れる、という実証です。ビルドツールのような、曖昧さが許されない領域でAIの構造を使うという着想が、実際に動くところまで確認されています。一方で、処理時間はPython実装の1.49倍かかっており、速度面でのメリットは示されていません。
Chu氏の検証が示す境界条件も踏まえると、この手法を実際の開発現場で使う場合、宣言された前提条件が正しいかどうかを誰がどう保証するのか、という運用上の確認が欠かせない部分になりそうです。出典が示しているのはあくまで実験結果であり、実運用でのコストや保守体制についてはどちらの記事からも読み取れません。
注目ニュース
PHP開発チームが緊急脆弱性2件の修正版を公開
PHPの開発プロジェクトは、「緊急」レベルの脆弱性2件を修正したPHP 8.5.12／8.4.27／8.3.36／8.2.35を公開しました。1つはメモリ不足時の処理に起因するもの（CVE-2026-109618）、もう1つはリクエストが使っていたメモリを解放した後も内部状態が残ってしまう問題（CVE-2026-109619）です。いずれもリモートコード実行につながる恐れがあると説明されています。対象はPHP-FPM、Apacheのモジュール版（mod_php）、php-cgi、FrankenPHP、LiteSpeedなどで、特にmod_phpは認証なしのリクエストだけで攻撃を引き起こせることが実証されているとされています。PHPの開発元は「全てのPHPユーザーは、直ちにアップデートすることを強く推奨する」と案内しています。サポート対象外のPHP 8.1以前についても、深刻さを踏まえて7.4、8.0、8.1向けの最小限の修正ソースコードが公開されました。ITmedia NEWS
編集後記：速度より「正確さ」を取りにいった実験
今回の実験で印象に残るのは、JetBrainsのチームが速くするためではなく、間違えないために重みを使った点です。学習済みモデルなら「だいたい当たる」ことが評価軸になりますが、ビルドツールでは「だいたい」が壊れたビルドを意味します。1.49倍という処理時間の遅さをそのまま公開した姿勢も含めて、AIの仕組みを使う目的が速度ではなく確定的な正しさにあったことが伝わってきます。実運用に乗せるかどうかは、この遅さとどう付き合うかという別の判断になりそうです。