ものづくり・製造

LLMでデジタル回路のVerilogを書く：ツール反復の効果と限界

2026/8/15 （更新: 2026/10/11）

🤖 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 らと重ならない別のグループで、ツールを外付けする方向が一つの研究室に閉じた話ではないことは、ここまでで言える。ただし要旨に具体的な数値は無い。本文 Table 3 では、著者らが精製したデータで微調整した 7B モデルが、ツールを与えると pass@1 0.5279 から 0.6003 に上がり、要旨が名指しする GPT-4o の 0.6022 に届く。構文エラーのたびに書き直させる反復を足しても 0.6080 で、著者らはほとんど改善しなかったと書く⁷。ツールを外付けする方向が一致していると言えるだけで、上の 41.9% を裏づける値としては使えない。

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

もう一方の「効いた」は、モデルに何を見せて育てたかの話だ。Wei らが NeurIPS 2025 のワークショップ DL4C で発表した報告は、既存の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%未満であると書く⁸。ただし同じ論文の表では、GPT-4 に書かせた Python の参照モデルの機能的正しさは RTLLM v2.0 で95%に届かず、GPT-4 が直接書いた Verilog はベンチマークと指標によっては5割を超える⁸。得意な言語で正解を書かせ、それを不得意な言語の合否判定に使う、という分業だ。著者らが報告する効きは小さくない。pass@5 は、5回生成して1回でも通れば合格と数える指標である。RTLLM v2.0 では GPT-3.5 のこの値が 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月に公開され、のち MLCAD 2026 に採録された ChipVerilog は、その「モジュール1個」という課題の単位のほうを測り直した。著者3名は上の AutoVeriFix と重なり、生成手順を出した側と、その評価の前提を疑う側は同じグループから出ている。著者らは、既存のVerilogベンチマークが短く自己完結したモジュール単位の課題に偏っており、実務のIPやプロセッサコアに見られるコード規模・階層・モジュール間のやりとりを捉えきれていないと述べる³。著者らは代わりに、再利用できる回路設計の単位であるIPコアをオープンソースで集めた公開リポジトリ OpenCores から 5系統・64件の生成課題を組んだ。OR1200、倍精度FPU、MIPS-16、I2C、CORDIC を含む。1,000行を超えるVerilogを要する課題もある³。

著者らは3モデルを評価した。pass@1 は、1回だけ生成させて通る割合である。結果は次のとおりだった³。

• GPT-5.4: 構文 83.13% ／ 機能 23.13%
• Claude Opus 4.5: 構文 78.75% ／ 機能 17.50%
• DeepSeek V4 Pro: 構文 45.94% ／ 機能 13.44%

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

このベンチマークでは、サブモジュールが2つ以上の課題に劣化が集中した。サブモジュールとは、別のモジュールを部品として呼び出す構造である。これをちょうど1つ持つ10課題では、機能 pass@1 は 25.33%。サブモジュールを持たない37課題の 23.06% をむしろ上回る。ところが2つ以上をインスタンス化する（あるいは依存する）17課題では、構文 pass@5 が74.51%ある一方で、機能 pass@1 も pass@5 も 0.00% に落ちる³。5回書かせても、一度も機能的に正しくならない。いずれも3モデルを集計した値である。著者らはこの劣化を、コンパイル可能性の先に、より深い階層が持ち込む困難だとしている³。上に見た VerilogEval や RTLLM の改善幅は、節の冒頭で述べたとおり、モジュール1個の課題で出ている。

同じ形は行数で見ても出る。100行に満たない課題では機能 pass@1 が 58.0%、100〜300行で 17.7%、300〜500行で 3.2%、500行を超えると 0.0% である³。また、本稿が引いた合格率は、どれも機能の一致を合格の線にしている。RTLLM は合成後の面積・消費電力・タイミングを人手の参照設計と比べる目標も持つが⁹、上の報告はその値を出していない。ChipVerilog の値はどれも、書かせた出力をそのまま判定したもので、前の節までで見たツールの出力を戻す反復は掛けていない。フィードバックによる修正の評価は、著者らが今後の課題に挙げている³。

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

生成が動いているぶん、判定も任せたくなる。書いたVerilogに脆弱性が残っていないかをモデルに見せる、という使い方だ。ここが通らない。ただし以下の三本が測っているのは、いずれも公開されている設計か、それを元に作り直した設計で、仕様からLLMに書かせたVerilogではない。Long らの報告は、通らない理由を著者らの言葉で書いている。LLMはVerilogコードの構造をとらえるのが苦手で、その結果、検出結果が一貫しない⁴。

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

評価は、公開リポジトリ Hack@21 の設計を種に変異させて作った 77件のVerilog設計、12種のCWEを対象にしている。F1スコアは、見逃しの少なさ（再現率）と誤検出の少なさ（適合率）の調和平均で、1に近いほどよい。各手法は5回ずつ走らせ、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は表現を作る側に回る。学習と評価に使うのは、公開データセット BugWhisperer の欠陥設計と、Verigen の無欠陥コードである⁵。BugWhisperer の欠陥設計は、既知のSoC脆弱性を含む公開ベンチマークを GPT-4 と GPT-4o に複製させて作った約4,000件だ⁵。一方で学習と評価の正解ラベルは、3つのLLMに欠陥の種類と行を答えさせ、2つ以上が一致した答えを採る多数決で付けている⁵。著者らは、CWE-1244 や CWE-1245 のような一般的なCWEの識別で約89%の適合率、行単位のバグ検出で96%の正解率を得たと述べる⁵。不適切なアクセス制御と有限状態機械に関わるバグでは、F1で 0.87 と 0.83 を記録し、VerilogLAVD の 0.70 と 0.67 を上回ったとも報告する⁵。これは別のデータセット同士の比較で、VerilogLAVD 側の 0.70 は4種のCWEをまとめた区分、0.67 は CWE-1245 だけの7設計の成績である⁴。

数字は上がっている。上がった先の読み方に注意がいる。以下の適合率は、どれも上の多数決のラベルとの一致で測った値である。まず 89% は、要旨が名指しした CWE-1244（適合率0.886）と CWE-1245（0.884）の2種についての適合率であって、扱った全CWEを通した値ではない。同じ表のマクロ平均まで下りると、適合率は 0.533 になる。著者らが扱った8クラスには、適合率も再現率も 0.000 のCWE（CWE-506）が含まれる。分類器はこのCWEを一件も当てていない⁵。

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

なお、この行単位の 0.50 を VerilogLAVD の 0.5台と並べて優劣を決めることはできない。前者は行単位、後者は設計単位の評価で、母集団が違う。言えるのは、判定を任せられるかを決めるのは正解率ではなく、挙がった指摘のうち何割が空振りかと、脆弱性をどれだけ見逃すかの両方だ、ということだ。空振りの割合は、VerilogLAVD で素のLLMより下がったとはいえ、本稿が見た範囲ではどれも半分前後に残っている。見逃しも、VerilogLAVD の再現率 66.10% と 72.88% で、3〜4件に1件は残る⁴。

補助しても、半分は外す

判定側のもう一本は、LLMを検出の主体から外した構成である。Ahmad らのプレプリント LASHED は、LLMと静的解析ツールを組み合わせ、RTLのバグを設計の早い段階で見つけようとする。この報告は、上のEDAツールフィードバックの報告と Pearce、Karri、Benjamin Tan の三名を共著者として共有する。静的解析ツールが機械的に走査し、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% のうちどれだけが静的解析ツールの寄与なのかは、切り分けられない。

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。