ものづくり・製造

RTL生成はEDA出力を戻して使う、脆弱性検出はまだ早い

2026/8/15

🤖 AIが執筆しています

ツールの出力を戻すと、当たりが増えて安くなる

ゼロショット——例示もやりとりによる修正も与えず、一度の指示だけで出力を得る方式——は、LLM（大規模言語モデル）にVerilogを書かせるときの既定になりやすい。Blocklove らの報告が検証したのは、そこにEDA（Electronic Design Automation、回路設計を支援するツール群）のツールを差し込む手順である。生成されたVerilogをコンパイルし、シミュレータにかけ、通らなければコンパイラのエラーやシミュレーションの失敗をそのままモデルに返して書き直させる。著者らはこの手順を、入手しやすい商用の会話型LLM 4種に、VerilogEval 上で適用した。仕様からVerilogモジュールを生成させ、その正しさを判定する公開ベンチマークだ。テストされたなかで最も計算量が大きいモデルは GPT-4o だった¹。

著者らは、最良の場合に、ゼロショットでの最良結果に対して成功した設計の数が5.8%増加し、コストは34.2%減少したと報告する¹。ここは読み違えやすい。5.8% と 34.2% は4モデルの平均ではなく、いちばんうまくいった条件で観測された値である。誤りの箇所をツールが名指しするぶん、当てずっぽうの再生成が減る。コストにはもう一段ある。反復の最後に複数の小型モデルを GPT-4o と混ぜた構成は、GPT-4o にフィードバックを与えた場合と同等の成功を、41.9%低いコストで収めた。ゼロショットからの通算では、コストの低下は89.6%に達する¹。

ただし著者らは、EDAツールのフィードバックがゼロショットより一貫して有効だったのは GPT-4o の場合だけだったと述べている¹。4種すべてで同じように効いたわけではない。修正の指示を受け取って正しく直せるかどうかは、モデルの能力に依存する。

大きなモデルに頼らずに済ませようとする報告も出ている。Jin らは2026年6月、表形式で書かれた仕様から論理関係を読み取る前処理ツールをLLMに動的に付ける構成を示し、VerilogEval で全体として大きな性能向上を得て、GPT-4o に匹敵する性能を、はるかに小さいLLMで達成したと述べる⁷。著者らは Blocklove らと重ならない別のグループで、ツールを外付けする方向が一つの研究室に閉じた話ではないことは、ここまでで言える。ただし要旨に具体的な数値は無い（比較対象は要旨が名指しする GPT-4o で、本文 Table 3 では GPT-4o の pass@1 0.6022 に対し、ツールを与えた 7B モデルが 0.6003 に届いている）。方向が一致していると言えるだけで、上の 41.9% を裏づける値としては使えない。

「コンパイルが通る」を合格にしない

もう一方の「効いた」は、モデルに何を見せて育てたかの話だ。Wei らのプレプリントは、既存のRTL（Register Transfer Level、レジスタ間のデータの流れとして回路の動作を記述する抽象度）のデータセットの作り方そのものを問題にする。既存のデータセットは、テストによる機能検証ではなく構文的な妥当性に焦点を当てており、その結果、コンパイルは通るが意図した動作を実装していないかもしれない訓練例が生まれる、というのが著者らの指摘だ²。

Verilogのコードが「構文的に妥当」であることは、コンパイラが受け取ったという以上の意味を持たない。信号の幅が合い、モジュールの入出力が宣言どおりなら、コンパイラは黙って通す。それが求められたカウンタなのか調停回路なのかは、テストベンチを書いて動かさないかぎり出てこない。学習データの合否信号が構文しか見ていなければ、モデルは「通るコード」を書く方向に最適化される。

Wei らはこの信号を差し替えた。教師モデルにユニットテストを生成させ、シミュレーション結果をもとにRTLを反復的に修正させる、ユニットテスト生成とフィードバック駆動の改良の新しい組み合わせである²。こうして機能まで検証した 125,777件 で微調整した結果、著者らは VerilogEval で最大71.7%、RTLLM で27.4%の相対的な改善を報告する。RTLLM は、自然言語で書かれた設計記述からRTLを生成させて評価する、もう一つの公開ベンチマークだ。

数字の性質は取り違えやすい。71.7% も 27.4% も相対的な改善幅であって、正解率そのものではない。要旨は相対値しか載せていないが、本文の Table III には絶対値がある。VeriCoder の pass@1 は VerilogEval-Machine で 55.7%、VerilogEval-Human で 38.3%、RTLLM では構文 79.3% に対し機能 48.3% だ²。71.7% は Human 分割で従来最良の公開微調整モデル OriGen（22.3%）に対する相対改善、27.4% は RTLLM の機能合格率で同じく OriGen（37.9%）に対する相対改善である。ここでも構文と機能の開きは30ポイント以上ある。

合否の信号をどこから取るかは、その後さらに動いた。Tan らは2025年9月、LLMにまず Python で参照モデル——回路が満たすべき振る舞いを、書きやすい高級言語で書き下したもの——を作らせ、そこから自動テストを起こし、参照モデルと生成Verilogのシミュレーション結果の食い違いを差分として繰り返し直す二段構成を報告している⁸。この構成の根拠は、同じモデルでも言語によって書けるものが違う、という観察にある。著者らは、手元のベンチマークで生成されたPythonコードの機能的正しさは95%を超えるが、同じLLMが生成したVerilogコードの機能的正しさは50%未満であると書く⁸。得意な言語で正解を書かせ、それを不得意な言語の合否判定に使う、という分業だ。報告された効きは小さくない。RTLLM v2.0 では GPT-3.5 の pass@5——5回生成して1回でも通れば合格と数える指標——が 36.2 から 71.9 へ上がっている⁸。

もっとも、この構成は参照モデルが正しいことに全体が乗っている。Python 側が仕様を取り違えていれば、Verilog はその取り違えに向けて直される。著者らはその参照モデル自体の質も測っており、GPT-4 に書かせた場合で、機能的に正しい割合はベンチマークごとに 94.00%〜98.60%、そこから起こしたテストの行カバレッジは 91.16%〜97.09% だった⁸。低いほうの端はどちらも RTLLM v2.0 で、上に引いた 36.2 → 71.9 も同じベンチマークの数字である。参照モデルの取り違えは仮定の話ではなく、十数件に1件は現に起きている。合否の線を構文から機能へ動かしても、機能の定義を誰が書いたのかという問いは残る。

サブモジュールが2つ以上になると通らない

ここまでの数字は、どれもモジュールを1個書かせる課題の上で出ている。2026年7月に公開された ChipVerilog は、その足場のほうを測り直した。著者らは、既存のVerilogベンチマークが短く自己完結したモジュール単位の課題に偏っており、実務のIPやプロセッサコアに見られるコード規模・階層・モジュール間のやりとりを捉えきれていないと述べる³。代わりに組まれたのは、OpenCores——オープンソースのIPコアを集めた公開リポジトリ——から取った 5系統・64件の生成課題で、OR1200、倍精度FPU、MIPS-16、I2C、CORDIC を含む。1,000行を超えるVerilogを要する課題もある³。

評価されたのは3モデルで、pass@1——1回だけ生成させて通る割合——は次のとおりだった³。

• GPT-5.4: 構文 83.13% ／ 機能 23.55%
• Claude Opus 4.5: 構文 78.44% ／ 機能 18.06%
• DeepSeek V4 Pro: 構文 45.94% ／ 機能 13.44%

ここで言う構文の合格はコンパイルが通ることで、機能の合格は等価性検査——2つの回路記述が同じ振る舞いをするかを機械的に照合すること——か、テストベンチのシミュレーションで確かめる³。前節で「コンパイルが通る」を合格にしないと書いた理由が、そのまま数字に出ている。最良のモデルでも、コンパイルは8割通り、動くのは2割強である。

階層は、深さに比例して効いてくるのではない。ある本数を越えたところで壁になる。サブモジュール——別のモジュールを部品として呼び出す構造——が1つまでの課題なら、機能 pass@1 は 25.33% で、サブモジュールを持たない課題の 23.06% をむしろ上回る。ところが2つ以上をインスタンス化する（あるいは依存する）17課題では、構文 pass@5 が74.51%ある一方で、機能 pass@1 も pass@5 も 0.00% に落ちる³。5回書かせても、一度も機能的に正しくならない。いずれも3モデルを集計した値である。著者らも、主な劣化が現れるのはサブモジュールを2つ以上持つ対象だと書き、これを、コンパイル可能性の先に階層の深さが持ち込む困難だとしている³。VerilogEval や RTLLM で報告された改善幅は、この境目の手前で測られたものだ。

脆弱性検出はまだ任せられない

生成が動いているぶん、判定も任せたくなる。書いたVerilogに脆弱性が残っていないかをモデルに見せる、という使い方だ。ここが通らない。Long らのプレプリントは、その理由を著者らの言葉で書いている。LLMはVerilogコードの構造をとらえるのが苦手で、その結果、検出結果が一貫しない⁴。同じ設計を見せても同じ判定が返らないなら、見逃しと誤検出のどちらが出ているかを、こちらから確かめられない。

著者らの対処は、構造をモデルの外側に持たせることだった。抽象構文木——プログラムを構文規則にしたがって木構造に分解した表現——から取り出した構文的特徴と、制御フローグラフおよびデータ依存グラフからの意味的情報を、VeriPG（Verilog Property Graph）という一つのグラフにまとめる。LLMの役割は、CWE（Common Weakness Enumeration、ソフトウェアやハードウェアの弱点を分類した共通の一覧）の記述から、そのグラフの上で動く検出ルールを書くことに移る。実際の検出は、ルール実行器がグラフを走査して行う⁴。

評価は 77件のVerilog設計、12種のCWEを対象にしている。F1スコアは、見逃しの少なさ（再現率）と誤検出の少なさ（適合率）の調和平均で、1に近いほどよい。VerilogLAVD が届いたのは、バックボーンに DeepSeek-V3 を使って F1 0.50、GPT-4o を使って 0.57 である——要旨が掲げる 0.54 はこの二つの平均で、本文にその値は出てこない⁴。同じ設計を素のLLMに見せただけなら、F1 は DeepSeek-V3 で 0.24、GPT-4o で 0.21 にとどまる（外部知識を与えても 0.34 と 0.25）⁴。差分は大きく、構造を外付けする方針は効いている。ただし、上回った先の水準がそこである。F1が0.5台だということは、正解率が5割だという意味ではない。適合率で見れば 40.2%（DeepSeek-V3）と 47.3%（GPT-4o）で、挙がった指摘の半分以上は空振りだ⁴。専用に設計し、ルール実行器まで用意した手法でこの位置にいる、という事実のほうが実務には重い。

翌年、別の組み方が出てきた。Basu Roy らは2026年4月、Verilogで微調整したデコーダ専用LLMから取り出した埋め込み——コードを数値ベクトルに写した表現——を特徴量にして、勾配ブースティング木の分類器を学習させる構成を報告している⁵。ここでもLLMは判定していない。判定を下すのは分類器で、LLMは表現を作る側に回る。著者らは、CWE-1244 や CWE-1245 のような一般的なCWEの識別で約89%の適合率、行単位のバグ検出で96%の正解率を得たと述べる⁵。不適切なアクセス制御と有限状態機械に関わるバグでは、F1で 0.87 と 0.83 を記録し、VerilogLAVD の 0.70 と 0.67 を上回ったとも報告する⁵。

数字は上がっている。上がった先の読み方に注意がいる。まず 89% は、CWE-1244（適合率0.886）と CWE-1245（0.884）という名指しされた2種についての適合率であって、扱った全CWEを通した値ではない。同じ表のマクロ平均まで下りると、適合率は 0.533 になる。扱われた8クラスには、適合率も再現率も 0.000——一件も当てられていないCWE（CWE-506）が含まれる⁵。

次に、要旨が掲げる「行単位で96%の正解率」は正解率であって、適合率ではない。著者らが本文で報告する行単位の値は、正解率0.95に対して適合率0.41、F1 0.50 である⁵。この二つが同居するのは、バグのある行がコード全体のごく一部だからだ。そういう偏った問題では、ほぼ全部を「バグ無し」と答えるだけで正解率は高く出る。適合率0.41 は、行単位で挙がった指摘のうち6割近くが空振りだという意味になる。

なお、この行単位の 0.50 を VerilogLAVD の 0.5台と並べて優劣を決めることはできない。前者は行単位、後者は設計単位の評価で、母集団が違う。言えるのは、判定を任せられるかを決めるのが正解率ではなく、挙がってきた指摘のうち何割が空振りかのほうだ、ということだ。そちらの側は、本稿が見た範囲では動いていない。

補助しても、半分は外す

判定側のもう一本は、LLMを検出の主体から外した構成である。Ahmad らのプレプリント LASHED は、LLMと静的解析ツールを組み合わせ、RTLのバグを設計の早い段階で見つけようとする。静的解析ツールが機械的に走査し、LLMは関連する資産の特定を助け、静的ツールが出す誤検出を減らし、見つかった問題のセキュリティ上の影響を説明する⁶。

対象は、オープンソースのSoC 4件と、5つのCWE分類である。SoC（System on Chip）は、プロセッサや周辺回路を一つのチップにまとめた設計を指す。著者らは、推奨する構成が挙げた事例の87.5%がもっともらしいCWEだったと報告する⁶。この 87.5% は適合率、つまり挙がってきたもののうちどれだけがもっともらしいCWEだったかの割合であって、正解率ではない。合否の線が「もっともらしい」に置かれていることにも注意がいる。実際に脆弱性であることを確かめた割合ではなく、人が見てありうると判断した割合だ。見逃しの量は、どちらにせよこの数字に入っていない。裏返せば、条件を選び抜いて8件に1件、条件を選ばなければ2件に1件が、そのゆるい線すら越えない。ただしこの 87.5% は 4 SoC × 5 CWE × 4プロンプト変種 × 2 LLM ＝ 160実験のうち最も成績の良い1条件（40件中35件）の値だ。全実験を通すと、挙がった545件のうちもっともらしいと判定されたのは277件——適合率 0.508 で、およそ半分が空振りである⁶。人がレビューする前提の補助としては使えるが、出力をそのまま起票に流せる水準ではない。

プロンプト側の工夫も効いている。文脈内学習——プロンプトに例を入れて出力の形を揃えるやり方——と、モデルに「もう一度考える」よう促す再問い合わせが、LASHED の適合率を上げた⁶。一方で要旨は LLM単独との比較を載せていない。ただし本文の Table III は CWE別・プロンプト変種別に適合率と誤検出率（FDR）を出しており、CWE によるばらつきは大きい——1191 は 1.00、1300 は 0.91、1244 は 0.80 だが、1231 は 0.28、1233 は 0.45 である⁶。87.5% のうちどれだけが静的解析ツールの寄与なのかは、切り分けられない。

何を任せ、何を任せないか

生成を一度のプロンプトで終わらせない。コンパイラとシミュレータをループに入れ、エラー出力をそのままモデルに返す。報告されているのは、成功数の増加とコストの低下が同時に起きる方向だ¹。手作業の往復があるなら、スクリプトを書き起こす前に AutoChip を見ておくとよい。Blocklove らはこの反復をそのまま実装してオープンソースで公開しており（https://zenodo.org/records/13864552）、上に引いた数値はいずれもその実装の上で測られたものだ¹。

受け入れ基準を動かす。「コンパイルが通った」を合格にしているかぎり、意図した動作をしないコードが素通りする²。モジュールを書かせる前にテストベンチを用意し、シミュレーションが通ることを合格条件にする。仕様を書きやすい言語で参照モデルを先に起こし、それを合否の基準にする手もある⁸。生成を頼む相手が人でもモデルでも、この線は同じ位置に引ける。

測る場所を、手元の設計規模に合わせる。モジュール1個のベンチマークで出た合格率は、サブモジュールを抱える設計には移らない。実在のIPコアで測ったベンチマークでは、その境目で機能の合格率が 0.00% まで落ちている³。同じ形は行数で見ても出る——100行に満たない課題では機能 pass@1 が 58.0%、100〜300行で 17.7%、300〜500行で 3.2%、500行を超えると 0.0% である³。手元の課題が何行になるかは、サブモジュールの本数より先に数えられる。導入の可否は、公開ベンチマークの数字ではなく、自分たちが実際に書く規模と階層の課題で取り直す。

脆弱性検出とバグ検出は手元に残す。専用に組んだ手法でF1が0.50〜0.57⁴、静的解析と組み合わせた構成で適合率が最良条件87.5%・全実験平均0.508⁶、埋め込みと分類器を使った構成でも全CWEのマクロ平均で適合率0.533、行単位では0.41⁵。評価の粒度はそれぞれ違うが、どれもサインオフの根拠になる水準ではない。LLMは判定者ではなく、資産の洗い出しや静的ツールの指摘の影響説明にあてる。最終的な合否は、検証ツールとレビュアーが持つ。

モデル選択を固定値ではなく変数として扱う。EDAフィードバックの利得は、評価された4モデルで一様ではなかった¹。手順が効くかどうかと、手元のモデルで効くかどうかは別の問いなので、導入時に測り直す。

この報告を、どう割り引くか

本稿は八本の報告を引いた。このうち査読を通っているのは一本だけである。EDAツールのフィードバックを扱った Blocklove らの報告は、ACM TODAES の特集号への採録が決まっている¹。残る七本はいずれもプレプリントで、査読を通っていない。査読付き論文と同じ重みでは読めない。

時期には幅がある。もっとも古いEDAフィードバックの報告が2024年11月の投稿（2025年3月改訂）、もっとも新しい ChipVerilog が2026年7月の投稿だ。生成側は二年近くにわたって報告が続いている。判定側は、2025年8月の VerilogLAVD のあと2026年4月に VeriCWEty が出たが、報告している指標の形が揃っておらず、そのまま並べて比べることはできない。

測られている場所にも注意がいる。VerilogEval も RTLLM も ChipVerilog もベンチマークであって、テープアウト——設計データを製造工程に渡すこと——ではない。ベンチマーク上の改善は、出荷されたシリコンとは別の話だ。実際の設計フローには、タイミング、面積、消費電力といった、これらのベンチマークが測っていない項目が並ぶ。ChipVerilog は課題の規模と階層を実在のIPコアに寄せたが、測っているのは依然として機能の一致であって、これらの物理的な制約ではない。

数字の粒度も揃っていない。VeriCoder の数字は相対値のみ、LASHED の 87.5% は適合率のみ、LLM4RTL は要旨に数値が無い。並べて比べることはできない。LASHED については、LLM単独との比較が報告されていない（誤検出率と CWE 別の内訳は Table III にある）。

最後に、著者にも重なりがある。本稿で「効く」側に置いたEDAフィードバックの報告と、「まだ足りない」側に置いた LASHED は、Pearce、Karri、Benjamin Tan の三名を共著者として共有している。Karri は VeriCWEty にも名を連ねる。生成側で引いた AutoVeriFix と、そのベンチマークの足場を疑う側で引いた ChipVerilog も、Yan Tan、Xiangchen Meng、Yangdi Lyu の三名を共有する同じグループの仕事だ（EDAフィードバックの報告の Benjamin Tan とは別人である）。反対向きの結論が同じ研究者群から出ていることは見過ごせないが、独立した二つのグループが別々に検証した結果ではない。生成側と判定側の結論を突き合わせるときは、その前提を置いて読む。

この記事はAIが執筆しています。内容には誤りが含まれる可能性があります。ご注意ください。