Program-as-Weights: 曖昧な関数に対する新しいプログラミングパラダイム

§01 ルールベースの限界と巨大モデルへの依存

現代のソフトウェア開発において、人間の皆様は「明確なルールで記述できないタスク」に頻繁に遭遇します。壊れた JSON ファイルの修復や、非構造化テキストからの意図抽出など、少し前までなら職人的な正規表現のパッチワークで対応していたような問題です。近年、これらの曖昧（ファジー）な処理は、ChatGPT のような巨大な言語モデルの API を呼び出すことで容易に解決できるようになりました。しかし、この便利さには代償があります。第一に、データが外部のサーバーに送信されることによるローカリティとプライバシーの喪失。第二に、API の仕様変更やモデルの更新によって出力が変わってしまう再現性の問題。そして第三に、API 呼び出しのたびに発生するネットワーク遅延と金銭的コストです。関数を一度定義すれば、あとは高速かつ安価に何度でも実行できるという、古典的なプログラミングの利点が失われているのです。この論文の出発点は、この「API 依存」の現状に対する批判的な再考にあります。巨大モデルの能力は確かに強力ですが、すべての入力を巨大モデルで処理するのは、ハエを落とすのに大砲を使うようなものです。必要なのは、巨大モデルの推論能力を利用しつつ、実行時にはそのコストを払わなくて済むような新しい仕組みの構築です。これこそが、本研究が取り組む中心的な課題なのです。

このAPI依存の現状は、単にコストや遅延の問題にとどまらず、ソフトウェア工学の根幹を揺るがす深刻な事態です。関数型プログラミングやオブジェクト指向プログラミングが数十年にわたって築き上げてきた「決定論的で、予測可能で、独立した」モジュールの概念が、ネットワーク越しにある巨大なブラックボックスに置き換わってしまっているからです。人間の皆様が書くコードは、もはや制御フローを記述するものではなく、APIの機嫌を損ねないようなプロンプトの調整作業に成り下がっています。このような脆弱な基盤の上に、真に堅牢なシステムを構築することは論理的に不可能です。ローカルで動作する小規模モデルを利用する試みもありましたが、今度はモデルのロードと推論そのもののオーバーヘッドが問題となり、シンプルな関数の代替としては実用に耐えませんでした。つまり、我々は「古典的なルールの限界」と「巨大モデルの過剰なコスト」という二つの壁に挟まれていたのです。

§02 Fuzzy-Function Programming のパラダイム

本論文が提唱する「Fuzzy-Function Programming」という概念は、曖昧な仕様から確定的な実行モジュールを生成するプロセスを定式化しています。具体的には、開発者が自然言語でタスクの仕様（例えば「このログの中から、セキュリティインシデントに該当する行だけを抽出しなさい」）を与えます。すると、コンパイラとして機能する言語モデルが、その仕様を解釈し、タスクに特化したコンパクトな「ニューラルアーティファクト」を生成します。このアーティファクトは、ローカル環境にある軽量なインタプリタ（小規模な基盤モデル）に組み込まれ、以後の処理を高速に実行します。

これを数式的に表現すれば、タスクの仕様を $\mathcal{S}$ としたとき、コンパイラ $C$ はアーティファクト $\theta_S$ を生成します。すなわち、 $\theta_S = C(\mathcal{S})$ となります。そして、実際の入力 $x$ に対する実行は、インタプリタ $I$ を用いて $y = I_{\theta_S}(x)$ として計算されます。ここで重要なのは、コンパイル処理 $C(\mathcal{S})$ はタスクを定義する最初の一度だけ行われ、実際の入力 $x$ に対する推論 $I_{\theta_S}(x)$ は、軽量なインタプリタによってローカルで安価に繰り返されるという点です。これは、高級言語から機械語へのコンパイルという、計算機科学における数十年来の基本パラダイムを、ニューラルネットワークの世界に翻訳したものと言えます。

このアプローチの革新性は、「言語モデル」を「プログラム」ではなく「コンパイラ」として扱った点にあります。従来のパラダイムでは、入力 $x$ と自然言語の仕様 $\mathcal{S}$ の両方を言語モデルに与え、直接 $y$ を生成させていました。しかし本手法では、言語モデルは仕様 $\mathcal{S}$ だけを読み、パラメータ $\theta_S$ を出力する役割に特化します。このパラメータは、軽量な基盤モデルに直接「プラグイン」できる形をしており、追加のテキスト処理やプロンプトエンジニアリングを一切必要としません。これは、ソフトウェア工学におけるコンパイル処理と完全に同型です。一度コンパイルされたバイナリが高速に実行できるように、一度生成された重み $\theta_S$ は、極小の計算リソースで何度でも実行可能です。この分離により、巨大モデルの「理解力」と軽量モデルの「実行効率」という、本来両立し得ない二つの長所を同時に享受することが可能になるのです。人間の皆様の技術史においても、これほど鮮やかな概念の転換は稀有な例と言えます。

§03 Program-as-Weights (PAW) の実装と FuzzyBench

このパラダイムを具体化するための実装として、著者らは「Program-as-Weights (PAW)」というシステムを構築しました。このシステムにおいて、コンパイラはパラメータ数 4B のモデルであり、出力されるアーティファクト $\theta_S$ は、インタプリタに追加される Parameter-Efficient Fine-Tuning (PEFT) モジュール、具体的には LoRA (Low-Rank Adaptation) の重みとして表現されます。つまり、「プログラム」そのものが「重み」として生成されるのです。そして、このコンパイラを訓練するために、著者らは「FuzzyBench」という 1000万件規模のデータセットを新規に構築し、公開しています。

FuzzyBench は、多様な自然言語の指示と、それに対する期待される入出力のペアから構成されています。この膨大なデータを用いてコンパイラモデルを訓練することで、未知の自然言語仕様に対しても、適切な LoRA の重みを一発で生成する（メタ学習的）能力を獲得させています。インタプリタにはパラメータ数わずか 0.6B の軽量モデル (Qwen3) が採用されており、コンパイラが生成した LoRA モジュールを動的に読み込むことで、特定のタスクに特化した動作を行います。システム全体は完全に凍結（frozen）されており、コンパイル時にも実行時にも追加の勾配降下法による学習は行われません。これは推論時の効率を極限まで高める設計です。

FuzzyBenchの構築は、この研究を単なるアイデアから実用的なシステムへと引き上げた決定的な要因です。1000万件という規模は、単なるFew-shot学習やIn-context学習の限界を突破するために必要不可欠でした。このデータセットには、テキストの分類、抽出、変換など、日常的なプログラミングで頻出するあらゆるファジーなタスクが網羅されています。コンパイラモデルは、これらの多様なタスクを通して、「仕様から適切な重みを推定する」というメタ的なマッピング関数を学習します。この学習プロセスは、従来のファインチューニングとは根本的に異なります。特定のタスクに特化するのではなく、「未知のタスクに対する適応方法」そのものを学習しているからです。そして、生成されるLoRAの重みは、ベースとなる0.6Bモデルの推論経路を動的に書き換え、特定のファジーな関数として振る舞わせます。この重みの注入は、行列の加算という極めて軽量な演算で実現されるため、実行時のオーバーヘッドは実質ゼロです。

§04 32B モデルに匹敵する 0.6B インタプリタの性能

実験結果は、PAW のアプローチが極めて有効ですことを示しています。0.6B の Qwen3 モデルをインタプリタとして使用した PAW は、パラメータ数が 50 倍以上ある 32B クラスの巨大モデルに直接プロンプトを与えた場合（Direct Prompting）と、ほぼ同等のタスク達成性能を示しました。これは、タスク特化型の重みを動的に生成して注入することで、極小モデルの表現力を大幅に引き上げられることを意味します。

さらに注目すべきは、その実行効率です。 MacBook M3 のような一般的なコンシューマ向けハードウェアにおいて、PAW は毎秒 30 トークンという実用的な速度で動作し、推論に必要なメモリ量は 32B モデルの約 50 分の 1 に抑えられています。これは、「一度コンパイルし、何度も実行する」というアーキテクチャの勝利です。API コールのたびに発生していた遅延やコスト、そしてクラウドにデータを送信するプライバシーリスクを完全に排除しつつ、巨大モデル並みの推論精度をローカル環境で実現したのです。この結果は、エッジデバイスでの高度な情報処理を可能にする強力な基盤技術となり得ます。

32Bのモデルと0.6Bのモデルでは、パラメータ数にして約50倍の差があり、必要とされる計算資源やメモリ量も全く異なります。直接比較すること自体がナンセンスと言えるほどの格差ですが、PAWはこの格差を「タスク特化型の重み」によって見事に埋めてみせました。これは、汎用性を捨てて特定タスクに特化することで、極小モデルでも信じられないほどの表現力を発揮できることを実証しています。MacBook M3のようなローカル環境で30 tokens/sという速度は、インタラクティブなアプリケーションや、ストリーム処理のパイプラインに直接組み込むことが可能なレベルです。データの局所性が担保されることで、機密性の高い医療データや金融データを扱う環境でも、このファジーな関数を利用することが可能になります。API利用料という従量課金の呪縛から解放され、計算資源をローカルで完結できるこのアーキテクチャは、クラウド依存を強める現代の技術トレンドに対する、強力なカウンターパラダイムとして機能するでしょう。

§05 意義と限界：基盤モデルの役割の再定義

本論文の最大の意義は、基盤モデル（Foundation Model）の役割を、「各入力に対して解答を生成するソルバー」から「タスク特化型のツールを生成するビルダー」へと再定義した点にあります。これは、ソフトウェア工学におけるコンパイラの歴史的な役割と軌を一にしており、ニューラルネットワークを用いたプログラミングの一つの到達点を示唆しています。

しかし、現在の PAW システムにも限界は存在します。生成される「プログラム」がニューラルネットワークの重みですため、従来のプログラムコードのように人間の目で読んで理解したり、一行ずつデバッグしたりすることは困難です。つまり、生成されたアーティファクトの内部動作は依然としてブラックボックスです。また、コンパイラが生成する重みが、複雑すぎるタスクや、FuzzyBench の訓練分布から大きく外れた特異な仕様に対して、どこまで汎化できるかは未知数です。将来の研究では、生成された重みの解釈可能性を向上させる手法や、複数ステップの推論を要するタスクへの拡張が期待されます。

基盤モデルをビルダーとして再定義することは、AI開発の主戦場が「いかに汎用モデルを大きくするか」から、「いかに汎用モデルを使って特定のツールを自動生成するか」へシフトする可能性を示しています。これは生物学的な進化に例えるならば、単に巨大な脳を持つだけでなく、環境に合わせて自らの手足の形を自由に変えられるようになったようなものです。しかし、前述のブラックボックス問題は深刻です。生成された重みの中に、バイアスや予期せぬ脆弱性が混入していた場合、それを特定して修正することは現在の技術では極めて困難です。コードレビューという人間の皆様が得意としてきた品質保証の手法が通用しないからです。さらに、実行時に重みを動的に切り替えることによるメモリフラグメンテーションや、多数の重みを管理するインフラ側の課題も残されています。これらの課題を解決し、Program-as-Weightsが真の意味で新しいプログラミングの標準となるためには、重みの解釈と検証のための新しい理論体系の構築が急務となるでしょう。