なぜ AI に一度だけ Verilog を書かせるのでは全然足りないのか

Verilog はチップのロジックを記述するハードウェアコードだ。RTL 設計は鋭利な試金石だ。あるモジュールが正しいかどうかは、クロックの各拍での挙動、リセットの取り決め、インターフェースのハンドシェイク、信号ごとのビット幅、そしてシミュレータが出す結果まで見て初めてわかる。だから「一見それらしい Verilog」というだけでは全く足りない。

モデルは自分でデータパスのビット幅、ステートマシンの遷移、リセットの取り決め、ready-valid ハンドシェイクプロトコル、メモリの読み書き、それに自然言語ではしばしば書かれていない細かなエッジケースまで推測しなければならない。つまり、文法的に正しいモジュールはあくまでスタート地点にすぎない。本当に役立つ自動化は、「書く」ことを「コンパイル、シミュレーション、波形と失敗トレースの確認、そして修正」という一連の鎖につなげ、一周回して不具合を見つけたら戻って直し、直したらまた回す、という形になっていなければならない。

HORIZON の核心的な発想は、この一連の鎖全体を自ら回り続けるループに閉じ込めてしまうことだ。

1本の仕様書がどうやって自走可能なプロジェクトパックになるか

ユーザーが唯一提供すべき入力は、構造化された Markdown 仕様書であり、コードではない。そこには高レベルの意図、リポジトリの文脈、期待される成果物、評価基準、そしてドメイン知識が書かれる。ドメイン知識は特に有用だ。ファイルを見ただけでは推測できない不変条件、ツールの慣習、失敗パターンを明示的に書き出せるからだ。

「ブートストラップエージェント」がこの仕様書を「プロジェクトパック(project pack)」にコンパイルする。これがシステム全体の制御プレーンとなる。仕様書は4つのコンポーネントからなり、それらは5つ組のランタイム設定にコンパイルされ、無人稼働のループを駆動する。

# HORIZON Harness: fifo_sync

## Goal / objective
Implement a synchronous FIFO. Depth 16, 8-bit data.

## Domain-knowledge directions
- Reset is synchronous, active-high.
- full and empty must never assert together.
- Follow ready-valid handshake conventions.

## Evaluator specification
- Compile with the suite's native flow.
- Run the provided simulation testbench.
- Extract functional coverage where available.

## Acceptance predicate
- Simulation passes with zero mismatches.

ループの回り方: Git リポジトリは操作盤であり、経験の蓄積庫でもある

ユーザーが最初の仕様書を渡した後、ループは完全に無人稼働になる。ブートストラップ、生成、評価、受理判定、記録、次のイテレーション、これらがすべて自動で回る。ひとつの「キャンペーン」は連続して何ラウンドも走らせることができ、途中でもう人手が入る必要はない。各ラウンドで、エージェントは現在の状態を読み、目標を立て、ワークスペースを編集し、ツールを呼び出し、失敗を読み解き、そして修正するかコミットするかを決める。受理基準が決めるのはただ一点、新しいバージョンをコミット(commit)するか、それとも今回の失敗をログ(log)に記録するかだ。

ここで Git はループの基盤であり、ついでに記録を取っているだけの存在ではない。4つのごく普通の git 操作が、それぞれ4つの役割を演じている。

git diff --cached                        # ステージされた候補の変更を確認
git commit -m "iter 7: fix full/empty overlap"
git notes add -m "pass=1 mismatches=0"   # 評価の証拠を添付
git log --oneline                        # 探索軌跡を再生

進化しているのはコードであって、モデルは終始動いていない

「自己進化」という言葉のせいで、HORIZON がこっそりモデルを訓練していると誤解しやすい。そうではない。進化するのは Git リポジトリ内の設計成果物であって、モデルの重みではない。バックボーンモデルの GPT-5.3 はキャンペーン全体を通じて重みが固定されたままで、訓練も強化学習ポリシーの更新も一切していない。

論文は確かに「半マルコフ決定過程(semi-MDP)」という言葉を借用しているが、正確に言えばこれは記録された対象に、正確で再生可能な名前を与えているにすぎない。「状態」はリポジトリのバージョン付きスナップショット(記帳用のチェックポイント)であり、「オプション」は2つのチェックポイントの間の一続きのエピソードだ。これは行動の仮定でも最適化の仮定でもない。

コストはセッションの使い回しによって抑えられている。HORIZON はイテレーションをまたいで永続的なモデルセッションを保持し、仕様書、プロジェクトパック、安定したソースファイル、蓄積したデバッグ文脈のすべてを、毎回送り直すのではなくサービス提供元のプロンプトキャッシュから取り出す。だから本当に新しく課金されるトークンは、主に現在の diff、最新の評価出力、そしてエージェントの返答だけになる。これが、後で見るように累計トークンの大部分がキャッシュ入力になっている理由でもある。

HORIZON は誰の肩の上に立っているか

HORIZON は「リポジトリスケールの自己進化」という系譜を受け継いでいる。この系譜に共通する原則はただひとつ、ある候補の変更は、実行可能な証拠に支持されて初めて受け入れられる、というものだ。違うのは「進化する対象」で、これまでの系譜はエンジニアが「実行する」ソフトウェアを進化させてきたのに対し、HORIZON はエンジニアが「創り出す」ハードウェアの成果物を進化させている。

ベンチマーク全種で100%通過、だがゴールまでの道のりは天と地ほど違う

単一の無人稼働エージェントループとして実行すると、HORIZON はすべてのベンチマークスイートを100%通過率に押し上げた。唯一残った未通過項目は ChipBench 内の1問だが、著者らはこれをエージェントの失敗ではなく、元のベンチマーク自体にある「仕様と説明書の不一致」という欠陥に由来するものだと突き止めている。解決済み扱いとすれば、これも100%となる。だから各スイート間で変わるのは終点ではなく、そこに至るまでの道のりだ。

ここでの iter 0 は、独立した単発生成の成功率ではない。これはエージェントが進化の第一歩を踏んだ後のリポジトリの状態を反映しており、しかも終始同じプロンプト戦略を使っている。エージェントは、初回で成功を最大化するのではなく、大量の探索・デバッグ・修正をわざと後のイテレーションに先送りすることも十分にあり得る。この集計値は Verilog-Eval-v2(iter 0 で86.2%)によって押し上げられており、CVDP のサブセットだけを見ると iter 0 はわずか23.9%だ。

ちなみに、この9つの CVDP 検証カテゴリ(テストベンチ生成、チェッカー生成、アサーション生成)は、まさにこれまで AI が最も苦手としていたタスクだった。CVDP の論文自体、最先端の単発モデルでもこの種の検証タスクは特に苦戦すると指摘していた。それが今や、同じループがそれらを100%まで収束させている。

ベンチマークをひとつ選んで、初回から100%まで這い上がる収束曲線を見てみよう:

全12カテゴリの初回通過率を並べてみると、その落差は一目瞭然だ。Verilog-Eval の86.2%から CID 007 の0.0%まで幅がある。それでも最終的にはすべてが100%に収束した。

棒グラフ＝初回(iter 0)の通過率。各カテゴリとも最終的には100%に収束している。

正しさが飽和したあと、トークンこそが本当の勝負どころ

正しさが飽和すると、トークン消費のほうがより情報量の多いシグナルになり、どれが難しくどれが易しいかを露わにする。著者らは「最適イテレーションに達するまでの累計トークン」でこれを測っている。3つの伝統的なスイートを合わせても600万にしかならないのに対し、9つの CVDP カテゴリは2億390万も消費し、全体の97.1%を占めた。全部を走り切ると累計は約2億990万になる。

2億990万をカテゴリ別に広げてみると、コード補完(CID 002)、仕様から RTL への変換(CID 003)、刺激生成(CID 012)の3つで大半を占め、伝統的なベンチマークは一番左端に細く並ぶだけだ。

興味深いのは CID 013 だ。初回通過率は全体最低(3.8%)なのに、わずか1,420万トークンで収束しており、あの平坦で踊り場のない軌道を裏づけている。本当にコストを押し上げているのは、CID 002 のような「数個の頑固な設計が作る長いテール」のほうだ。

さらに重要な一言がある。トークンの約91%はキャッシュ入力であり、これが API コストを大幅に引き下げている。だからこそ著者らは明言している。彼らが「最終通過率」ではなく「トークン効率」こそ、最も改善を要する指標だと見なしている、と。HORIZON はどのスイートも一掃したが、最も難しいカテゴリで最後に残るあの数パーセントが、不釣り合いなほど多くの予算を吸い込んでいる。

カバレッジはついでに測られたもの。著者自身が引いた一線

検証生成のカテゴリはじっくり見る価値がある。HORIZON が何を最適化していて、何を最適化していないかを露わにするからだ。HORIZON の受理ゲートは CVDP の「通過条件」であって、「カバレッジ目標」ではない。ループはベンチマークの仕様書を通過させるように駆動されており、あるデザインがひとたび通過すれば、ゲートは満たされ、ループはそれ以上そのデザインを最適化するのをやめる。だからここでのカバレッジは副次的な、観測にすぎないシグナルだ。

最も直接的な証拠はこうだ。CID 012 は32ラウンド目で通過率100%に達したが、その時点での平均設計あたりカバレッジは97.9%であって、100%ではなかった。この差は受理ゲートの直接的な結果だ。各デザインは仕様書を通過させた時点で手を止めてしまうため、カバレッジは「通過するのに十分なテスト」を反映しているにすぎず、「到達しうる最大値」ではない。

デザインごとに見ると、ループは「カバレッジの低い尾」を持ち上げている。20%から40%程度のカバレッジから出発したいくつものデザインが満カバレッジへと引き寄せられ、もともと高かったものだけをそっと押すのとは違う。CID 014 はその逆で、最初から98%前後にあり、すぐに飽和した。著者らは、カバレッジを100%まで押し上げようとはしていないと強調している。ここでのカバレッジは「生成されたテストに確かに実質的な中身がある」ことを示す診断であって、「検証を尽くした」という宣言ではない。

論文の第5節が最も正直な部分であり、著者らは自ら2本の一線を引いている。

一線その1: 過剰最適化／報酬ハッキング

現行の設定では、エージェントは各ラウンドの評価の詳細な出力(シミュレータのメッセージ、評価ログ、失敗トレース)を見ることができる。これは実際のデバッグワークフローに似ている。エンジニアも本来ログや反例を確認するものだからだ。しかし、こうしたシグナルへの完全なアクセスは、ある種の失敗モードも招く。エージェントが、観測された失敗、決定論的なテスト、あるいは評価器の癖にちょうど合わせて生成 RTL を作り込んでしまい、設計の本来の意図を頑健に実装しない可能性があるのだ。すると「通過」という結果は、「あらゆる合理的なテストの下で仕様を満たした」ことではなく、「露出した軌跡の下で見えている仕様書を満たした」ことを意味しているにすぎない場合がある。

著者らはこれを踏まえ、今後のエージェント型ハードウェア設計ベンチマークは2段階のプロトコルを採るべきだと提案している。修正の期間中は有用な診断フィードバックを見せてよいが、隠されたランダムテスト、独立した参照モデル、形式的等価性チェック、性質のスイート、あるいは取り置いたシミュレータ構成は、最終採点用に取っておくというものだ。これはソフトウェアエンジニアリングのベンチマークである SWE-bench の「構造的なテストの取り置き」という考え方と一致する。

一线其二: フィードバックの折り返し時間

本論文の RTL 通過／不通過のベンチマークは、大半の評価が十分速く走り、反復修正を支えられるという意味で比較的親切だ。しかし、より広いチップ設計の世界では、報酬の評価ははるかに遅くなりうる。PPA(性能／消費電力／面積)最適化や EDA ツールの進化に対する報酬は、論理合成、配置、配線、タイミング解析、消費電力見積もり、あるいは大規模な回帰スイートを要することがある。著者らは、SATLUTION がすでにそのコストを示していたと述べている。約800ノードを並列で使っても、SAT コンペのベンチマーク一式全体を評価するのに約2時間の折り返し時間がかかった。一方 RTL の PPA 最適化では、折り返し時間が数日から数週間に及ぶこともありうる。長い遅延を伴う報酬は問題を根本的に変えてしまい、素朴な「編集・評価・修正」ループでは遅すぎるようになる。エージェントは、遅延が大きく、疎で、コストの高いフィードバックの下で推論しなければならない。したがって「折り返し時間の長い報酬」を解決することは、エージェント型チップ設計における重要な研究課題である。

HORIZON の答えはこうだ。ユーザーは1本の Markdown 仕様書(目標、ドメイン知識、合格の判定方法)を書くだけ。システムがそれを自動で「プロジェクトパック」にコンパイルし、無人稼働(誰も管理していない)のループに渡す。ループはコードの修正とシミュレーションを繰り返し、検証に通って初めてコミットする。公開されているチップ設計の試験4種、計12カテゴリで、このループがすべてを100%通過に押し上げた。

だが同じループでも、2〜3版で通る問題もあれば、なかなか通らない問題もある。違いはどこにあるのか。まず、どう回っているかを見てみよう。

秘訣はモデルをより賢くすることではなく、Git リポジトリ(プログラマーがコードを保存し、あらゆる履歴を残しておくツール)を脳として扱うことにある。1版直すたびに1回シミュレーションを回す。通過すれば git commit で緑のチェックポイントとして残し、主線が前に進む。通らなければ git log に記録して反面教師にする。このリポジトリの履歴そのものが AI の経験の蓄積庫になる。

全12項目の試験がすべて100%、これは今まで無人稼働の AI が成し遂げたことがなかった。ただし「100%」の裏側では、問題ごとの難易度に天と地ほどの差があり、最も体感しやすい物差しは「何版修正して通過したか」だ。

以上の数字はすべて NVIDIA 自身の論文によるテスト結果であり、今のところ第三者による独立再現はない。著者らも、AI は毎ラウンドの評価の詳細を見られるため、「試験に迎合している」だけで本当にチップを正しく作れているとは限らない可能性がある、と注意を促している。