自然言語の仕様を「訓練でコンパイル」する——ルールでもAPIでもない第3の道「Compile by Training」入門

はじめに：ルールで書けない処理は、毎回LLMを呼ぶしかないのか

数千件のメールをまとめて仕分けたい場面を想像してほしい。「Signature needed by EOD」のような件名は即時対応（immediate）に、「ニュースレター」の配信は後で読む（wait）に振り分ける、といった具合だ。件名の表現は毎回微妙に異なるため、if文や正規表現でルールを書き尽くすには曖昧すぎる（fuzzy）。かといって1件ごとに大規模言語モデルのAPIを呼ぶのは、従量課金のコスト、通信のレイテンシ、プロバイダの仕様変更や障害への依存——いわゆる3重苦を抱えることになる。

「繰り返し使うテキスト関数」という視点で見ると、この2つの選択肢の間には広大な空白地帯が広がっている。ルールは正確だが、そもそも書けない処理には無力だ。大規模モデルは何でもこなせるが、呼ぶたびにコストと外部依存が発生する。頻繁に実行され、曖昧でありながらパターンが安定している処理——メール仕分け、ログの分類、データの整形など——は、まさにこの空白地帯に位置する典型例である。

本記事で解説するのは、大規模モデルを「実行時の依存」ではなく「ビルド時の道具」として使う逆転の発想だ。自然言語で書いた仕様を1回の学習工程でローカル実行可能な小型のニューラル関数に変換する「Compile by Training」という手法について、EMNLP 2026 System Demonstrationsに採録された論文（arXiv:2609.04199）をベースに、仕組みと実用性の両面から紹介する。

そもそも「コンパイル by トレーニング」とは何か

「コンパイル by トレーニング」は、自然言語で書かれた関数仕様を、(1) 教師モデルによる入出力事例の合成 → (2) 小型モデルのファインチューニングという2段階の工程で、「ローカル実行可能なニューラル関数」に変換する手法である。通常のコンパイラがソースコードを機械語に翻訳するのに対し、こちらは「メールを即時対応と後回しに仕分ける」「arXivのURLからIDだけ抜き出す」といった指示文を、そのまま実行できる形へ変換する。

ここでいう「関数」の中身はソースコードではなく、ニューラル重み（LoRAアダプタ）と実行時プロンプトの組み合わせである。LoRA（Low-Rank Adaptation）は、既存モデルの重みを凍結したまま小さな低ランク行列だけを学習し、タスクごとの軽量な「差分」を作る手法だ。このアダプタが入力→出力の契約を持ち、通常のソフトウェアの関数と同じように呼び出せる点が大きな特徴である。

コンパイルの成果物は約22MBの .paw アーティファクトで、保存・バージョン管理・再利用・合成が可能である。実行時に必要になるのは0.6B規模の共有「インタプリタ」と関数ごとの小さなアダプタだけで、教師モデルも大規模モデルも不要だ。コンパイル時だけGPUと大規模モデルを使い、以後の呼び出しは完全にローカルで完結する。全体の流れは次のとおりだ。

flowchart LR
    A[自然言語の仕様] --> B[教師モデルが事例を合成]
    B --> C[LoRAアダプタを学習]
    C --> D[.paw パッケージ化]
    D --> E[ローカルで関数実行]

先行研究のProgram-as-Weights（PAW）との関係も整理しておく。PAWは1回の推論でアダプタを数秒で予測する「超高速コンパイラ」である。これに対し本手法は、その予測を初期値として追加の学習で精度を磨く「コンパイルに時間をかけて品質を高める」タイプのコンパイラに位置づけられる。同じ仕様から出発しても、より良い実行体を目指す点が両者の違いだ。

仕組みを3ステップで分解する

自然言語の仕様からローカル関数を作る流れは、「データ合成」「パラメータ学習」「パッケージ化」の3段階で進む。

ステップ1：仕様から教師データを合成する

開発者が書くのは「やりたいこと」だけ。例えば「arXivの/pdf/リンクからIDだけ抽出し、/abs/は無視する」といった1〜2文の仕様だ。これを受け取った教師モデル（公開サービスではGPT-5.4-miniとGPT-5.5を2:1で併用）が、仕様に沿った入出力ペアを数百〜数千件まとめて生成する。生成データはJSON形式で自動検証され、不正なバッチは棄却されてから学習に流れる。データ量と精度の関係も実験で示されており、1,440ペアでは0.821だった意味精度が7,200ペアでは0.866まで向上。一方、3,600ペア前後から伸びが鈍るため、量より質が重要になる。

ステップ2：共有インタプリタに小さなアダプタを学習させる

関数ごとにモデル全体を学習し直すとコストとストレージが膨張する。そこで、全関数で凍結したQwen3-0.6Bインタプリタ（入力を受け取り出力を生成する小型の実行基盤）を共有し、関数ごとにLoRAアダプタ（rank 64）だけを追加学習する。LoRAとは、重みの更新量を低ランク行列で近似して学習パラメータを大幅に減らす手法だ。初期アダプタは先行手法の高速コンパイラが数秒で予測し、それを起点に合成データで最適化する「ウォームスタート」方式を採用。最適化は系列生成損失に基づく標準的な手順（100ステップ・バッチ48・コサイン減衰）で、公開構成なら1〜2分で完了する。

flowchart TB
    subgraph shared[共有インタプリタ Qwen3-0.6B（凍結）]
        base[ベースモデル]
    end
    A1[仕様A] --> L1[LoRAアダプタA rank64]
    A2[仕様B] --> L2[LoRAアダプタB rank64]
    A3[仕様C] --> L3[LoRAアダプタC rank64]
    L1 --> base
    L2 --> base
    L3 --> base

ステップ3：バージョン管理できる「成果物」としてパッケージ化

学習結果は「アダプタ＋実行時プロンプト・テンプレート＋元の仕様＋インタプリタ情報」を1つの.pawアーティファクト（関数実行に必要な資産を束ねたパッケージ）として保存される。これは通常のソフトウェア資産と同じで、保存・バージョン管理・キャッシュ・再利用・合成が可能だ。実行時はSDKが入力とアダプタを組み合わせ、共有インタプリタを1回動かすだけ。GPUと教師モデルが必要なのはコンパイル時だけで、以後の呼び出しは完全にローカルで完結する。つまり「LLMを毎回呼ぶ」のではなく、「LLMを1回だけ使って道具を作り、あとはその道具を使う」という発想の転換が、この仕組みの本質である。

なぜ注目すべきか：LLMが「実行時依存」から「ビルド時ツール」に変わる

この手法の本質は、大規模モデルの位置づけを「毎回呼ぶ実行時依存」から「1回だけ使うビルド時ツール」へと変える点にある。従来、曖昧なテキスト処理は入力のたびにAPIへ問い合わせるしかなかった。それがコンパイル方式になると、学習コストはビルド時に1回だけ発生し、以後の呼び出しはローカルの小型モデルで処理される。この違いは運用面で桁違いの影響を持つ。

まずコスト構造が変わる。API課金は入力1件ごとに発生するため、処理量に比例して費用が膨らむ。一方、コンパイル方式はビルド時に学習コストが1回かかるだけで、1万件呼ぼうが10万件呼ぼうが追加費用はほぼゼロだ。次にレイテンシと可用性。ネットワーク往復が消え、ローカル推論は1回あたり約0.05〜0.5秒で完了する。プロバイダ障害・API仕様変更・レート制限といった外部要因からも解放される。さらにプライバシー面では、入力データが一切外部に出ない。機密メール・社内文書・患者情報などを扱う関数との親和性が高い。

再現性も見逃せない。「バージョン固定されたアーティファクト」として配布・管理できるため、同じ入力には常に同じ出力が返る。監査や回帰テストがしやすく、通常のソフトウェアと同じ扱いが可能だ。そして最も重要なのは「ソフトウェアらしさ」である。コンパイル済み関数は検索・キャッシュ・分岐などの通常コードと自由に組み合わせて、大きなシステムを構成できる。後述のpaw-helperでは、30個のコンパイル済み関数がツリー状にルーティングされ、厳密な処理は決定論的コードが担当する分業が実装されている。また、共有インタプリタ1つで無数の業務関数を賄えるため、「モデルを置く」のではなく「関数をビルドして置く」運用も現実的になる。LLMが「呼ぶもの」から「組み立てるもの」になる——この視点の転換こそが、セルフホスティング指向のエンジニアにとって最も注目すべき点である。

精度とコストのトレードオフ：FuzzyBench-Hardで何が起きたか

本手法の精度を正しく読むには、評価指標LEM（LLM Exact Match）の意味を知っておく必要がある。LEMは出力の「文字列一致」ではなく、LLMジャッジ（GPT-5.5）が仕様・入力・参照出力・モデル出力の4点を照合し、「意味的に正しいか」を判定する指標だ。空白の有無やJSONのキー順といった表面的な差は許容され、値・順序・構造・論理の誤りだけが不合格となる。つまり「表記は違うが中身は正しい」解答を正しく評価できる。

ジャッジ自体の信頼性も検証済みである。人間が付けたラベル128件と照合した結果、正解率97.7%、Cohen's κ（一致度係数）0.946と「ほぼ完全一致」に相当する水準だった。この基準値が信用できる前提で、以下の実測値を見てほしい。

評価に使われたFuzzyBench-Hardは、先行研究Program-as-Weights（PAW）の高速コンパイラが完全一致を1件も出せなかった仕様だけを集めた難易度の高いサブセットである。「簡単な問題だけ選んで勝負した」わけではない点が重要だ。

結果は次の表のとおりである。意味精度はPAWの22.4%に対し本手法が83.6%と、+61.2ポイントの大幅改善。ただしコンパイル（学習）時間は3.5秒から50.9秒（B300）へと伸びており、環境が非力なほどさらに増える（H200で68.2秒、RTXクラスで99.2秒）。

これは「コンパイルに1分かけるか、3.5秒で妥協するか」という選択であり、通常のコンパイラで最適化レベルを上げるとビルド時間が伸びるのと同じ構図である。「より良いコード生成に時間をかける」という速度・品質トレードオフが、ニューラル関数の世界にも持ち込まれたと言える。もっとも、このコストは仕様ごとに1回だけ支払えばよい。実行時に毎回API課金される従来方式と比べれば、50秒前後の初期コストは十分に回収可能な水準だ。

実際の使い方：3つのデモが示す応用の広がり

Compile by Trainingの実用性は、公式に公開されている3つのデモで具体的に確認できる。対象はWebサイトの質問応答、3Dアバターの操作、文体の翻訳と多岐にわたり、「自然言語の仕様をローカル関数にする」というアイデアが特定のドメインに限定されないことを示している。

マルチサイトWebヘルパー「paw-helper」

paw-helperは、1つのバックエンドが4つの異なるWebサイト（著者の個人サイト・大学のAIコースサイト・NeuralOS・PAW公式サイト）の質問応答を担当するデモである。30個のコンパイル済み関数がツリー状にルーティングされ、ページの文脈に応じて必要な枝だけが動作する。設計思想の要点は「分業」にある。分類・回答文生成・妥当性確認といったfuzzy（曖昧）な判断はコンパイル済み関数が担い、BM25検索（キーワードベースの代表的な検索アルゴリズム）・キャッシュ・ブランチ制御といった厳密な処理は通常コードが担当する。実行時に外部LLMを1つも呼ばないからこそ、この分業が成立する。

flowchart TB
    Q[ユーザー質問] --> R{ルーター：ページ文脈で判定}
    R --> F[コンパイル済み関数<br/>分類・回答生成・妥当性確認]
    R --> C[通常コード<br/>BM25検索・キャッシュ・分岐]
    F --> A[回答]
    C --> A

自然言語で3Dアバターを操作する「Avatar Director」

Avatar Directorは「jump twice, then dance」のような自然言語コマンドを、アクションDSL（ドメイン固有言語）に変換する。ここでのDSLとは、シーケンス・時間・繰り返し・並列動作を構造化して記述する実行可能なデータ形式である。変換後のDSLはブラウザ側の決定論的コードが検証・実行するため、不正な動作は生成段階で防げる。44件の手書き検証指示のうち43件で期待どおりの動作構造を生成できたという。出力が「ラベル」や「自由文」ではなく「実行可能な構造データ」である点が、LLM生成を安全に実行へつなぐ設計のお手本となる。

話題の「Claudish」双方向翻訳サービス

Claudishとは、Claude Code（AIコーディングエージェント）が出力する独特な文体だ。「gates」「boundaries」「load-bearing」といった比喩、X-shaped型のハイフン複合、対比構造を特徴とし、エンジニア界隈では「AIコーディングへの没入度の指標」としても話題になった文化現象である。このデモでは「英語→Claudish」「Claudish→英語」の方向ごとに1つの仕様を書き、それぞれ1つのアダプタを学習しただけである。にもかかわらず、2026年8月22日〜9月2日の期間に10万件超の翻訳リクエストを処理した。仕様とコードはGitHubで公開されており、翻訳の例は次のとおりだ。

同じ事実を伝えるのに「人間が管理画面の権限設定を読むための文章」と「AIエージェントの会話に現れる文章」とで表現が切り替わる。文体のような主観的な変換タスクも、仕様と学習データさえ用意すれば関数化できることを示す好例である。

セルフホスト指向のエンジニアが知っておくべき実装の現実

「理論は分かった。では自前のサーバーで動かすには何が必要か」。公式リポジトリは単一のcompile.pyという構成で、uv run compile.py "仕様文" -o output.paw の1コマンドでコンパイルが完了する。必要な環境はPython 3.10以上とuv（Pythonの実行環境・パッケージ管理ツール）、そして教師モデルを呼び出すためのOpenAI互換APIキーだけだ。デフォルト設定は約40GBメモリのGPUを想定するが、バッチサイズを小さくする、勾配チェックポイント化（中間計算を保存せず再計算してメモリを節約する手法）を有効にするなどして、小型GPUやCPUまで縮小できる。

flowchart LR
    A[コンパイル<br/>GPUと教師APIを使うのはこの段階だけ] --> B[.paw成果物<br/>保存・バージョン管理]
    B --> C[実行SDKで読み込み<br/>offline=True]
    C --> D[毎回ローカル推論<br/>ネットワーク通信ゼロ]

ビルド後に動かすのは、コンパイルとは別の実行時SDKの役割だ。pip install programasweights でインストールし、paw.function("id") でコンパイル済みの関数を取得すれば、後は通常のPython関数と同じように呼び出せる。GPUがなければCPU実行も可能で、MacではMetal経由のアクセラレーションにも対応する。ネットワークから完全に切り離したい場合は、paw.prepare_program() でアセットを事前に検証・キャッシュしてから offline=True を指定する。これで実行時の通信はゼロになり、社内ネットワークやエッジ端末でも安心して運用できる。

サイズ感は運用設計の重要な材料となる。コンパイラの選択肢をまとめると次のとおりだ。

自宅サーバーやエッジ端末との相性が良い理由は、「モデルを置く」のではなく「関数をビルドして置く」という発想にある。共有インタプリタ1つの上に小さなアダプタを差し込むだけで業務関数を追加できるため、関数ごとに大規模モデルや専用GPUを用意する必要がない。1台の0.6Bモデルが無数の関数を賄う——これがセルフホスト構成の要点である。

課題と限界：何に注意して使うべきか

第一の注意点は、合成データが教師モデルの誤りを受け継ぐことだ。ファインチューニングの学習データは大規模モデルが生成するため、その出力に含まれる偏りや誤りはそのまま関数の挙動に引き継がれる。論文自身も、保証が必要な用途では出力検証や従来の決定論的パスを併用すべきだと明言している。例えば後段の処理に影響するID抽出や数値整形では、正規表現による受入検査を挟んでから本番データへ適用する、という二段構えが現実的な運用になる。

第二に、コンパイルは数秒では済まない。公開構成では1回あたりB300で約50.9秒、H200で約68.2秒、RTXクラスのGPUで約99.2秒を要し、仕様を変えるたびにこの時間とGPUリソースが再発生する。頻繁に仕様を書き換える試作段階より、要求が固まってからの関数化が向いている。逆に言えば、この約1分のコストは「以後の呼び出しが完全ローカルになる」投資と割り切れるかが導入判断の分かれ目だ。

第三に、置き換え対象の見極めが重要だ。厳密なルールで書ける処理まで機械学習に置き換えるのは過剰で、入力形式が固定された変換や一意に定まる処理は従来コードの方が高速かつ確実である。本手法の得意領域は「曖昧だがパターンが安定している判断」に限られる。

最後に、現時点の評価の土台はまだ薄い。公表されているエビデンスはFuzzyBench-Hardでの意味精度とデモの実行可能性が中心で、実際の開発者の使い勝手を調べる体系的なユーザー調査は将来課題と位置づけられている。評価指標LEM（LLM Exact Match）もLLMジャッジの判定に依存するため、ベンチマークの数字は「同じ品質が常に保証される」ことを意味しない。導入にあたっては自社データで小規模なサンプル評価を行い、閾値管理と従来パスとの併用をあらかじめ設計しておくのが安全だ。

よくある質問

コンパイルにはどのくらいの時間とマシンが必要ですか？

公開サービスでの実測は次のとおりで、GPUクラスに応じて約1分前後かかる。

自作する場合はデフォルト設定で約40GBメモリのGPUが想定されているが、バッチサイズの削減や勾配チェックポイント化（学習時の中間計算を保持せず再計算で節約する手法）によって、小型GPUやCPUのみの環境にも縮小できる。この時間は仕様ごとに1回だけ支払えばよい初期コストである。

コンパイル後の関数は本当にネットワークなしで動くのですか？

はい、動く。実行時に必要なのは共有の0.6Bインタプリタ（関数の仕様を解釈して出力を生成する小型モデル）と、関数ごとの小さなアダプタだけだ。事前にpaw.prepare_program()でモデル資産を検証・キャッシュし、実行時にoffline=Trueを指定すれば、通信が遮断された環境でもゼロネットワークで動作する。API呼び出しやプロバイダ障害の影響を受けない完全ローカル運用が可能である。

プログラムを書けない人でも使えますか？

「自然言語で仕様を書く」部分だけを見ればノーコードに近いが、コンパイル環境のセットアップや生成結果の検証にはある程度の技術力が必要だ。学習データの品質が関数の精度を左右するため、まずはエンジニアが社内の業務関数を請け負う形で導入するのが現実的である。

ルールベースの実装やプロンプトを使い分ける基準は？

「ルールで正確に書ける」処理は従来コード、「リアルタイム性や最新の知識が必要」な処理は大規模モデルAPIの直接呼び出しが依然として優勢だ。本手法が最適なのはその中間、つまり頻繁に実行され、曖昧だがパターンが安定している処理である。自前で実装する際はこの3分類（従来コード／本手法／API）で判断すると迷わない。

FuzzyBench-Hardの83.6%はどのくらいすごい数字ですか？

前提として、FuzzyBench-Hardは先行研究の高速コンパイラが完全一致を1度も出せなかった難度の高いサブセットである。その上で意味精度が22.4%から83.6%へ+61.2ポイント改善したのは劇的な進歩であり、実用域に近づいたと評価できる。ただしLLMジャッジによる意味判定であるため、100%の保証ではない点には留意が必要だ。

まとめ

Compile by Trainingは、自然言語で書いた関数仕様を「1回の学習」というビルド工程で、ローカル実行可能な小さなニューラル関数に変換する開発パラダイムだ。変換後の成果物は約22MBのアーティファクト（.pawファイル）として保存・バージョン管理・合成でき、実行時に大規模モデルもネットワークも必要ない。ルールで書き切れず、かといって毎回APIを呼びたくない——メール仕分けのような「曖昧だがパターンの安定した処理」に対して、第3の選択肢を与えるのがこの手法である。

その本質は、大規模モデルの役割を「毎回呼ぶ実行時依存」から「1回だけ使うビルド時ツール」へと再定義した点にある。従来のAPI直接呼び出しと比べた性質は、次のように整理できる。

精度とコンパイル時間のトレードオフは、従来のコンパイラと同じ構図だ。FuzzyBench-Hardで意味精度22.4%→83.6%（+61.2ポイント）という劇的な改善を得る代わりに、コンパイル時間は3.5秒→50.9秒（B300）へ伸びた。つまり「より良いコード生成に時間をかける」という、ソフトウェア開発者にはお馴染みの選択がニューラル関数の世界にも登場したのである。あわせて、合成データが教師モデルのエラーを受け継ぐ点、検証や決定論的パスの併用が必要な点、厳密なルールで書ける処理まで機械学習に置き換えるのは過剰である点を、設計時の注意点として覚えておきたい。

セルフホスト指向のエンジニアにとって、約22MB・0.05〜0.5秒/呼び出し・オフライン実行・バージョン管理可能という性質は、プライバシー保護・コスト削減・プロバイダ非依存という文脈と非常に相性が良い。まずは公式デモ（programasweights.com/playground）で自分の仕様を1つコンパイルしてみるのが、この世界観を掴む最短ルートだ。その関数が確かに小さく、速く、手元の環境だけで動くのを確認したとき、「LLMを使う」のではなく「LLMで道具を作る」ことの意味が腑に落ちるだろう。

参考資料

• arXiv Abstract: https://arxiv.org/abs/2609.04199v1
• arXiv HTML全文: https://arxiv.org/html/2609.04199v1
• PAW論文Abstract: https://arxiv.org/abs/2607.02512
• 公式デモ: https://programasweights.com
• compile-by-training（GitHub）: https://github.com/programasweights/compile-by-training
• claudish（GitHub）: https://github.com/programasweights/claudish
• paw-helper（GitHub）: https://github.com/programasweights/paw-helper
• programasweights-python（GitHub）: https://github.com/programasweights/programasweights-python
• OpenTrain AI（再現性レビュー）: https://www.opentrain.ai/papers/compile-by-training-...-arxiv-2609.04199/
• User Mag（Taylor Lorenz）: https://www.usermag.co/p/vibe-coders-now-have-their-own-language

関連記事

• エッジデバイス向け小型言語モデル（SLM）の最適化：量子化と蒸留による軽量化の最前線
• In-Place Tokenizer Expansion for Pre-trained LLMs — 多言語デコード高速化の実践的拡張