低レイヤコード特化LLMの構想と実現可能性・リスクに関する考察 ― LLVM IR・アセンブリ・バイナリを対象とする大規模言語モデルの位置づけ ―
前書き：本記事はエンジニア向けの「ポジションペーパーの叩き台」レベルのメモです。本当はちゃんと研究していつか論文としてどこかに出したかったのですが、内容からして無理ゲーだなと感じました。ただ、このままローカルで眠らせておくよりは、粗いままでも外に出したほうが誰かの考えるきっかけにはなると思い、そのまま公開することにしました。
要旨
本稿では、ソースコードではなく LLVM IR・PTX 等の中間表現（IR）、アセンブリ、バイナリおよび CPU/GPU マイクロアーキテクチャ挙動を直接扱う「低レイヤコード特化 LLM（以下、低レイヤLLM）」という概念を定義し、その設計目標、理論的実現可能性、実装要件、および安全保障上・社会的なリスクを体系的に検討する。
既存研究は、ソースコード解析向け LLM の包括的サーベイ［1］、バイナリから高級言語へのデコンパイル専用 LLM［2,3］、バイナリトークナイズ方式の性能影響［4］、基本ブロックスループットを DNN で予測する Ithemal［5］、アセンブリレベルでのアルゴリズム探索を行う AlphaDev［6］、強化学習によるコンパイラ最適化ポリシー学習 MLGO［7］などを通じて、「低レイヤ情報を扱う深層モデル」が有効であることを既に示している。一方で、これらは個別タスクに特化したモデルであり、本稿で想定するような「IR／アセンブリ／バイナリ／マイクロアーキテクチャを統合的に扱う大規模モデル」はまだ存在しない。
本稿の結論は次の通りである。第一に、機械語や IR を「言語」とみなすこと、デコンパイル・性能予測・最適化ポリシー決定などの要素タスクをニューラルネットで近似することは、既存研究に照らして理論的に十分可能である。第二に、実用レベルの低レイヤLLMを構築するには、ハードウェアベンダ内部の詳細な性能データ、膨大な IR／アセンブリ・バイナリコーパス、大規模計算資源と専門チームが不可欠であり、現実的に実装し得る主体はCPU/GPUベンダ、巨大クラウド企業、一部の国家機関など極めて限定される。第三に、そのようなモデルが攻撃者側の手に渡った場合、ゼロデイ探索・エクスプロイト生成・マルウェア高度化を自動化し得ることから、サイバーセキュリティ・インフラ防御・ハードウェア産業・ソフトウェア工学に対して構造的なリスクをもたらす。
これらを踏まえ、本稿は、低レイヤLLMを「技術的には実現可能だが、安全な運用には厳格なタスク分解とガバナンス設計が必須な、高リスク・高インパクトな技術」と位置づける。
キーワード:低レイヤコード、大規模言語モデル、LLVM IR、アセンブリ、コンパイラ最適化、バイナリ解析、サイバーセキュリティ
1. 序論
大規模言語モデル（LLM）は、自然言語だけでなくプログラミング言語に対しても高い性能を示し、コード補完・自動修正・バグ検出など、ソフトウェア開発プロセスの多くの局面に浸透しつつある。ソースコード解析向けLLM のサーベイ［1］は、コード補完、コード要約、バグ検出と修正、コード検索など多様なタスクに対して、GPT 系や専用コードモデルが有効であることを整理している。
しかし、既存のコード特化LLMの多くは、高級言語（C/C++、Python等）のソースコードを主対象とし、コンパイル後の IR、アセンブリ、バイナリ、さらにはマイクロアーキテクチャレベルの挙動を主たる扱いとするモデルは限定的である。一方で、バイナリから高級言語へのデコンパイル専用LLM［2,3］や、バイナリトークナイズ、基本ブロック性能予測、コンパイラ最適化ポリシー学習といった低レイヤ領域への深層学習適用は着実に進展している［4–7］。
この文脈において、本稿は以下の問いに答えることを目標とする。
ソースコードではなく IR／アセンブリ／バイナリ／マイクロアーキテクチャを主対象とする「低レイヤコード特化LLM」とは何か。
そのようなモデルは、情報表現と学習能力の観点から理論的に実現可能か。
どのような主体が、どのようなデータと計算資源を前提として実装し得るのか。
実現した場合、サイバーセキュリティやソフトウェア工学にどのようなリスクとインパクトを与えるか。
以下ではまず関連研究を整理し（第 2 節）、続いて低レイヤLLMの定義と設計目標を明確化する（第 3 節）。そのうえで、理論的実現可能性（第 4 節）、実装要件と実現可能なプレイヤー（第 5 節）、潜在的危険性と社会的インパクト（第 6 節）を順に議論し、最後にガバナンスと研究アジェンダを提示する（第 7 節）。
2. 関連研究
2.1 ソースコード解析向けLLM
ソースコード解析に対するLLMの適用については、サーベイ［1］が包括的な整理を与えている。そこでは、
コード補完・生成
自動バグ検出と修正
コード要約とドキュメンテーション
コード検索・類似コード検索
リファクタリング支援
などが主なタスクとして挙げられ、GPT ベースの汎用モデルと、CodeBERT・CodeT5 系のコード特化モデルが比較されている。しかし、［1］に登場するモデル・データセットの多くはソースコードを対象としており、IR やバイナリを主対象とするものは周辺的である。
2.2 バイナリデコンパイルと逆アセンブル
バイナリコードから高級言語ソースを復元する「デコンパイル」は、低レイヤLLMの中核タスクの1つである。TanらのLLM4Decompile［2］は、アセンブリ／バイナリと対応するCコードの関数ペアを用いてLLMを学習し、汎用 LLMやGhidraなど従来ツールを大きく上回る復元品質を達成している。
産業側でも、RevEng.aiによる専用モデル開発［3］が報告されており、1.1B パラメータ規模のEncoder–Decoder Transformerを約 3,300 万組の関数ペアで訓練することで、高い可読性を持つ擬似コードを生成している。これらの結果は、「命令列→高級言語構造」という変換がLLMによって十分に学習し得ることを示している。
2.3 バイナリトークナイズと表現
バイナリコードのトークナイゼーションは、LLM性能に大きな影響を与える。Mostafa ら［4］は、バイトレベル、BPE、構造化トークナイズ等の方式が、バイナリ解析タスクにおけるTransformerの性能に与える影響を系統的に評価し、トークン粒度・語彙設計・アーキテクチャ固有情報の扱いが重要であることを示している。これは、低レイヤ LLM の構築において「単にソースコードと同じトークナイザを流用する」ことが不適切であることを示唆する。
2.4 性能予測・アルゴリズム探索・最適化ポリシー学習
基本ブロック単位のスループットをDNNで予測するIthemal［5］は、「命令列 → 性能指標」という写像がニューラルネットで高精度に近似できることを示した。DeepMindのAlphaDev［6］は、アセンブリレベルでソートやハッシュのアルゴリズムを強化学習で探索し、標準ライブラリより高速なアルゴリズムを発見した例として知られる。
コンパイラ最適化に関しては、GoogleのMLGO［7］が、インライン展開・レジスタ割り当て等のパス選択を強化学習で学習し、実際のコンパイルパイプラインに組み込んで運用している。これらの研究は、
マイクロアーキテクチャ挙動のニューラル近似［5］
アセンブリレベルでのアルゴリズム探索［6］
コンパイラ最適化ポリシーの学習［7］
が既に実用レベルで成立していることを示しており、低レイヤLLMの構成要素として重要な知見を提供する。
2.5 セキュリティ分野におけるLLM利用
セキュリティ分野では、汎用LLMを逆アセンブルやマルウェア解析の「アシスタント」として利用する試みが既に現れている。SentinelOne Labs［8］は、ChatGPT を用いて難読化解除、シグネチャ生成、挙動分析など 11 種類のタスクを支援できることを示した。Cisco Talos［9］も、逆アセンブル作業において LLM をサイドキックとして用いる事例を紹介し、専門家の生産性向上に有用であると報告している。
また、Microsoft による調査をまとめたレポート［10］では、攻撃者が LLM を用いて脆弱性探索やマルウェア生成を自動化し、攻撃サイクルを短縮しつつあることが指摘されている。これらは現在のところ主にソースコード・スクリプト・ログレベルの利用であるが、低レイヤ LLM が実現した場合、その適用範囲がバイナリやファームウェアにまで拡大し得ることは容易に想像できる。
3. 低レイヤコード特化LLMの定義と設計目標
3.1 定義
本稿では、「低レイヤコード特化LLM」を次のように定義する。
低レイヤコード特化LLMとは、
・LLVM IR、MLIR、NVVM IR、PTX などの IR
・x86/ARM/RISC-V 等のアセンブリおよびバイナリ
・キャッシュ階層・分岐予測・パイプライン構造などの CPU/GPU マイクロアーキテクチャ情報
を主な入出力とし、それらの解析・変換・最適化・再構成を行う大規模言語モデルである。
通常のコード LLM が高級言語ソースを対象とし、人間の可読性や API レベルの抽象に重点を置くのに対し、低レイヤ LLM は実行時挙動とハードウェア資源利用を主な関心事とする点に本質的な違いがある。
3.2 想定タスク
低レイヤ LLM の主なタスクとして、以下のようなものが想定される。
静的解析の高度化
IR／アセンブリ／バイナリに対するデータフロー解析・制御フロー解析
メモリ依存・レジスタ依存関係の推定
単純な CFG を超えた、高レベルループ構造やアルゴリズム構造の復元
マイクロアーキテクチャを考慮した最適化
ターゲット依存の命令選択・命令スケジューリング
SIMD やテンソルコア等のベクトル化戦略の決定
キャッシュ階層に最適化されたメモリアクセスパターンの提案
Ithemal や AlphaDev, MLGO が扱うタスクの統合的な一般化［5–7］
高レイヤ構造・意図の逆推定
デコンパイルにおける高級言語へのリフティング［2,3］
セキュリティ観点からの脆弱性候補（バッファオーバーフロー、UAF、競合状態等）の抽出
コンパイラバックエンドとしてのポリシーネット
拡張 IR とハードウェア記述、プロファイル情報を入力し、
適用すべき最適化パスの選択、
レジスタ割り当て・インライン展開方針の決定、
を出力する「意思決定モジュール」としての利用［7］。
ここで重要なのは、LLM に完全な静的解析や形式的正当性の保証を委ねるのではなく、解析器・SMT ソルバ・プロファイラと連携する「ポリシーネット」と位置づけることである。すなわち、LLM は候補やヒューリスティックを提示し、最終的な正当性は従来技術で検証するという役割分担が前提となる。
3.3 実装アーキテクチャのイメージ
実装形態として自然なのは、「チャットボット的なアセンブリ自動生成器」ではなく、コンパイラや静的解析ツールのバックエンドとして組み込まれた LLM である。具体的には、
フロントエンド：既存コンパイラ／解析器が IR、CFG、DFG、各種解析結果を生成
ポリシーネット：低レイヤ LLM が最適化・変換方針や脆弱性スコアリングを出力
バックエンド：SMT ソルバによる等価性検証や実機プロファイルで結果を検証
という三層構成が考えられる。この構成は、MLGO［7］のような既存の「ML によるコンパイラ最適化」の枠組みを、より広範なタスクに拡張したものとみなせる。
4. 理論的実現可能性
4.1 機械語・IRを「言語」として扱う妥当性
Transformer系LLMは、本質的に「トークン列間の条件付き確率分布」を学習するモデルであり、対象が自然言語である必然性はない。実際、LLM4Decompile［2］および RevEng のモデル［3］は、アセンブリ／バイナリをトークン列として扱い、高級言語コードへの翻訳を成功させている。
これらは、命令列の局所パターンやレジスタ・メモリアクセスの依存関係、分岐命令と制御フローとの対応などが、十分なデータとコンテキスト長が与えられれば内部表現として獲得し得ることを示している。従って、「低レイヤコードをLLMの対象とする」こと自体は理論的に妥当である。
4.2 データフロー・制御フロー解析の近似可能性
データフロー解析やCFG構築は、本来は決定的アルゴリズムに基づく形式的手続きである。LLMによる近似は、正確性の観点からは劣後する。しかし、十分な訓練データ（コードとその解析結果のペア）があれば、LLMは解析手順を模倣し、入力コードに対する「解析結果らしいもの」を出力できることが期待される。
実際、LLMデコンパイラ［2,3］は、二重ループや複雑な制御構造を持つコードに対しても元の構造を復元しており、内部で暗黙的にデータフロー・制御フローパターンを捕捉していると解釈できる。ただし、これは統計的に有用なヒューリスティックを学習できるという意味であり、任意のプログラムに対してsoundness / completenessを保証できるわけではない。従って、LLMは解析結果の「提案者」として使い、形式的検査で必ず確認するという前提が必要である。
4.3 トークナイズと多アーキテクチャ対応
バイナリコードのトークナイズは、オペコード・オペランド・即値・アドレッシングモードなどが混在し、命令セットにより表現が多様である点で自然言語より厄介である。Mostafa ら［4］は、各種トークナイゼーション方式がバイナリ解析タスクに与える影響を検証し、
命令境界を意識した構造化トークン
バイトレベル表現との併用
ISA 固有情報を埋め込んだトークン設計
などが有効であることを示している。低レイヤLLMでは、x86/ARM/RISC-V/GPU等の異なるISAを1モデルで扱う場合、トークナイズと埋め込み設計がボトルネックとなる可能性が高い。これは理論的な不可能性ではないが、「万能1モデル」の実現を大きく困難にする要因である。
4.4 性能予測・最適化ポリシー決定への拡張
Ithemal［5］は、基本ブロックのスループットをDNNにより高精度に予測できることを示した。AlphaDev［6］は、アセンブリ列の探索を通じて既存実装を凌駕するアルゴリズムを自動発見した。MLGO［7］は、コンパイラの最適化パス選択を強化学習で行い、実サービスで利用されている。これらは、
「命令列 → 性能指標」
「命令列 → アルゴリズム品質」
「IR → 最適化ポリシー」
といった写像がニューラルネットで近似可能であることを実証している。従って、低レイヤLLMがこれらのタスクを統合的に扱うことは、理論的には十分射程内にある。
4.5 小括
以上より、
機械語・IR をトークン列として扱うこと
デコンパイル、性能予測、最適化ポリシー決定などのタスクをニューラルモデルで近似すること
はいずれも既存研究で部分的に実証されている。低レイヤLLMは、これらを統合したより大規模なモデルとして構想されるものであり、原理的な障壁は小さいと言える。一方で、多ISA対応、分布外一般化、形式的正しさの保証など、実用上の課題は依然として大きい。
5. 実装要件と実現可能なプレイヤー
5.1 データ要件
実用レベルの低レイヤLLMを構築するには、以下のようなデータが必要になる。
ハードウェアベンダ内部の詳細なマイクロアーキテクチャ情報
（レイテンシテーブル、ポートマップ、キャッシュ構成、分岐予測アルゴリズム等）大規模な IR／アセンブリ／バイナリコーパス
（自社コンパイラが生成したコード、ドライバ、ファームウェア、最適化済み職人アセンブリ）実行トレース・性能カウンタ・最適化ログ
（IthemalやMLGO が利用するようなプロファイルデータ［5,7］の大規模版）
これらは多くが企業内の秘匿情報であり、公開データのみでは高品質モデルの訓練は困難である。
5.2 計算資源と人材要件
モデル規模とタスクの複雑さを考えれば、数千～万GPUクラスの学習インフラと
コンパイラ・静的解析に精通したエンジニア
CPU/GPUマイクロアーキテクチャの専門家
深層学習・強化学習の研究者
から構成されるチームが必要になる。さらに、長期的な実験と検証を継続する予算と組織も不可欠である。
5.3 実現可能な主体
このような条件を満たし得る主体としては、現実的には次のような組織に限られる。
CPU/GPU ベンダ
Intel, AMD, NVIDIA, Appleなど。自社コンパイラやドライバ・ライブラリ、ハードウェア内部情報へのアクセス権を持つ。巨大クラウド＋コンパイラ技術を持つ企業
Google（LLVM への貢献、MLGO、TPU）、Microsoft（Clang/.NET JIT, Azure）、Meta/AWS等。国家機関・サイバー部隊
NSA、各国サイバー軍、情報機関など。攻撃・防御両面で低レイヤ解析能力へのインセンティブが強い。
大学や中小企業でも、特定ISA・特定タスクに特化したモデルであれば構築し得るが、本稿で想定するような汎用・高性能な低レイヤLLMは、事実上、上記のような巨大プレイヤーにしか実装不可能であると考えるのが妥当である。
6. 潜在的危険性と社会的インパクト
低レイヤLLMが高い性能で実現し、攻撃者側にも利用可能になった場合のリスクは、通常のコードLLMと比較して質的に異なる。ここでは主なリスクカテゴリを整理する。
6.1 サイバー攻撃の自動化と大規模化
低レイヤLLMが任意バイナリに対して脆弱性候補の探索（バッファオーバーフロー、UAF等）、ROP/JOPガジェット列の抽出、権限昇格パターンの検出を自動で行えると仮定すると、現在は国家レベルのAPTが数ヶ月～年単位で実施している作業が、半自動化されたパイプラインとして回せるようになる。
既に汎用LLMを用いた脆弱性探索・マルウェア生成の自動化は報告されており［10］、攻撃サイクルの短縮が現実に起きつつある。低レイヤLLMは、この流れをバイナリ・ファームウェア・ドライバレベルにまで押し下げ、特にパッチが困難な古いシステムに対するリスクを大幅に増大させる可能性がある。
6.2 マルウェア・Rootkitの高度化
低レイヤLLMがOSカーネル、ハイパーバイザ、GPU、UEFI/BIOS等を理解し得る場合、カーネルレベル Rootkitやハイパーバイザ攻撃、GPUを悪用したステルス型マルウェア、ファームウェアへの永続感染といった攻撃コードが自動生成・自動改良可能になる。
現状でも、LLMを逆アセンブルやマルウェア解析の支援に用いる事例は存在し［8,9］、防御側の生産性向上には寄与している。しかし、同様のツールが攻撃者側にも開放されると、「人間の解析者には読みにくいが、モデルには最適化されたマルウェア」が設計される可能性があり、攻防の非対称性が拡大する。
6.3 ハードウェア企業秘密の漏洩
ハードウェアベンダが、自社の詳細な性能データや最適化ログを用いて低レイヤLLMを訓練した場合、そのモデルが外部に流出すると、モデルへのクエリを通じて企業内の最適化ノウハウが再構成されるリスクがある。
例えば、「このGPUで行列乗算を最速にするアセンブリを生成せよ」「このループを最大スループットで動かす命令列を設計せよ」といった問いに対する出力は、実質的に社内のアセンブリの分布を反映する。これはLLM一般に付きまとう訓練データ由来の情報漏洩問題の特殊ケースであり、ハードウェア産業では競争優位性そのものを損なう可能性がある。
6.4 ソフトウェア工学への構造的ダメージ
低レイヤLLMがコンパイラの最適化バックエンドとして機能し、極端に最適化されたバイナリを大量に生成するようになると、人間の開発者が高レイヤからその挙動を理解することが困難になる。
形式検証により「仕様どおり動作する」ことは保証できても、障害発生時の原因追跡、仕様変更への対応、新たなセキュリティ要件への適応など、保守運用上のタスクは大幅に難化する。ソフトウェア工学は、「人間が理解・変更可能なコード」を前提として発展してきたが、低レイヤLLMベースの最適化は、この前提を侵食する危険性がある。
6.5 暗号実装・インフラ・制御系への影響
暗号分野では、アルゴリズムそのものより実装上のタイミング差やキャッシュ挙動等を突くサイドチャネル攻撃が主戦場となっている。低レイヤLLMがこれらのパターンを学習すると、暗号ライブラリの実装に潜む微妙な差異を利用した攻撃手法を高スループットで探索できる可能性がある。
また、更新が滞っている古いファームウェアや産業制御システム（ICS/OT）は、既に脆弱性の宝庫である。低レイヤLLMによる自動逆解析と攻撃コード生成は、電力・交通・水道・工場などのクリティカルインフラに対して、現在より遥かに高いリスクをもたらすことが懸念される［10］。
6.6 「丸ごとリーク」シナリオについて
極端な仮定として、「フルスペックの低レイヤLLMがそのまま外部に流出する」シナリオを考えることもできる。この場合、攻撃者はハードウェアベンダ級の低レイヤ解析・最適化能力を即座に獲得することになり、既存の IT 基盤を根本から見直さざるを得ないレベルのリスクが発生する可能性がある。
もっとも、このシナリオはレアケースであり、実際にどの程度の時間スケールでどこまでのダメージが発生するかは高い不確実性を伴う。重要なのは、「大きいインパクトを持ち得る技術である」という認識を前提に、モデル設計とガバナンスを行う必要があるという点である。
7. ガバナンスと研究アジェンダ
低レイヤLLMを現実に開発・運用する場合、単に性能を追求するだけではなく、初期設計段階からセキュリティ・ガバナンスを組み込む必要がある。本節では、最低限検討すべき論点を列挙する。
7.1 タスク分解とAPI設計
フルスペックの「何でも屋」モデルではなく、
コンパイラ最適化支援
デコンパイル支援
性能予測専用
などのタスク特化モデルに分割する。
各モデルの入出力を厳格に制限し、明らかに攻撃用途に直結する組み合わせ（例：任意バイナリからROPチェーンを直接生成するAPI）を禁止する。
7.2 形式検証・解析器との強制的連携
LLMの出力は常に既存の静的解析器・SMTソルバ・プロファイラによる検証を通過しなければ採用されないよう、システム構成に強制的に組み込む。
特に暗号実装や安全関連システムについては、「LLMが提案する最適化は構造的な安全性を悪化させない」ことを形式的に確認するワークフローを必須とする。
7.3 訓練データとモデル利用のアクセス制御
ハードウェア内部データや最適化ログを用いたモデルは、原則として社外提供しない。
研究用に共有する場合でも、モデルへのアクセスログ取得、利用目的の制限、オンプレミス運用などを通じて、外部への漏洩リスクを最小化する。
7.4 レッドチーミングと評価プロトコル
SentinelOne［8］や Talos［9］、Microsoftレポート［10］に見られるような攻撃者視点の評価を、低レイヤLLMに対しても継続的に実施する。
「意図しない攻撃自動化機能」が出現していないかを検査する標準化されたベンチマークの整備が望ましい。
7.5 学術・産業・政府間の情報共有
低レイヤLLMのリスクと対策技術に関する情報が閉じたサイロに埋もれると、防御側全体のレジリエンスが低下する。
具体的な脆弱性情報を共有せずとも、高レベルなリスク評価や防御技術については公開の場で議論できるような枠組みが必要である。
8. 結論
本稿は、ソースコードではなく IR／アセンブリ／バイナリおよびマイクロアーキテクチャを対象とする「低レイヤコード特化LLM」という概念を定義し、既存研究［1–7］との関係を整理したうえで、理論的実現可能性、実装要件、潜在的危険性を検討した。
結論をまとめると、
技術的には：バイナリデコンパイル、性能予測、アルゴリズム探索、最適化ポリシー学習などの要素タスクは既に実証されており、低レイヤLLMの構想は既存研究の延長線上にある。
実装上は：必要となるデータと計算資源・人材要件が極めて高く、実際にフルスペックのモデルを構築し得る主体は限られた巨大プレイヤーに絞られる。
社会的には：高性能モデルが攻撃者の手に渡った場合、サイバー攻撃の自動化・大規模化、マルウェア高度化、企業秘密の漏洩、ソフトウェア工学への構造的ダメージをもたらし得るため、技術開発と同時にガバナンス設計が不可欠である。
したがって、低レイヤLLMは「作れるか／作れないか」という二元論ではなく、「どの機能をどの境界までモデルに委ねるのか」「それをどのような検証と監査の下で運用するのか」という設計の問題として捉えるべきである。今後の研究課題としては、タスクごとの安全なAPI設計、形式検証との統合フレームワーク、セキュリティ観点を含んだ評価ベンチマークの整備などが挙げられる。
参考文献
[3] RevEng.ai Blog, “AI Models for Decompiling Assembly Code,” 2024.
[6] DeepMind, “AlphaDev,” Nature 2023.
[8] SentinelOne Labs, “11 Problems ChatGPT Can Solve For Reverse Engineers and Malware Analysts,” 2023.
[9] Cisco Talos Intelligence Group, “Using LLMs as a Reverse Engineering Sidekick,” 2024.
[10] Extortion and ransomware drive over half of cyberattacks – Microsoft Report
