【DSF2026レポート】生成AIによるRTL開発は「コード生成」から「検証・最適化」へ―最優秀講演に選ばれたAIエージェント活用の実践術

2026年10月6日に開催された「Design Solution Forum 2026（DSF2026）」の開催レポート続編。

今回は最優秀講演賞を受賞した石原ひでみ氏の講演「生成AIで動くRTLを作りきるための実践術」についてレポートする。

石原氏は長年FPGAのRTL設計に携わってきた経歴を持ち、FPGA設計関連の技術書なども執筆している人物。自身が約2年間にわたって生成AIをRTL開発に活用してきた経験を基に、チャット型AIから単一エージェント、複数エージェントによるチーム開発へと進化した開発手法を、具体的な回路開発事例とともに紹介した。

石原氏が冒頭で示した結論は、「生成AIはコード生成の道具ではなく、検証と最適化の相棒」というもの。RTL開発で時間を要するのは、コードを書くことだけではない。シミュレーションによる検証、合成、タイミング確認、修正を繰り返す工程が大きな負担となる。同氏は、生成AIの真価は、この反復サイクルを加速させることにあると説明した。

RTL特有の難しさをどう乗り越えるか

ソフトウェア開発と異なり、RTLでは1ビットの不整合やクロック・タイミングのずれが深刻な不具合を招く。AIによって生成されたRTLが文法的に正しくても、FPGAに収まらなかったり、要求する動作周波数を満たさなかったりする可能性がある。さらに、ハードウェア分野では学習データがソフトウェアほど豊富ではないこと、AIが生成したコードの検証にかえって時間がかかることも、AI導入をためらう要因になるという。

こうした問題に対し、石原氏は「AIに正しい答えを一発で書かせる」のではなく、「何が正しいかを人間が定義し、AIに実装と検証の反復を担わせる」方法を提案した。その基盤として石原氏が挙げたのが、「仕様書駆動」、「スケルトン駆動」、「テスト駆動」という3つの手法である。

石原氏は、3つの手法を組み合わせることで、従来2カ月かかっていたRTL開発を1週間程度に短縮し、AIの利用コストを約3,000円、手書きのRTLをほぼゼロにすることも視野に入ると述べた。

仕様書、スケルトン、テスト―AIを自走させる3つの型

仕様書駆動では、AIとの会話だけに頼らず、情報を文書として残す。用意するのは、何を作るかを明らかにする「要求仕様」、どのように構成するかを定める「設計仕様」、作業手順と進捗を管理する「タスク仕様」の3種類。対話の中で指示が埋もれたり、開発が進むにつれて前提が曖昧になったりすることを防ぐのが狙いだ。

スケルトン駆動では、複雑な回路を機能ごとのモジュールに分け、まずモジュール間のインターフェースを厳密に決める。内部の実装を空の状態からAIに作らせることで、大きな回路を一度に生成させる場合に比べて作業範囲を限定しやすくなる。重要なのは、各モジュールが何を受け取り、何を返すかという外枠を先に固定することだ。

テスト駆動では、RTLの生成よりも先に正解を判定する仕組みを準備する。例えばJPEGエンコーダーの開発では、C言語によるリファレンスモデルを用意し、関数単位の入力と出力を基準として、生成したRTLモジュールの動作を検証した。この「正解」があることで、AIは生成、実行、結果の解析、修正というループを自律的に繰り返しやすくなる。

石原氏によれば、人間が担うのは正しさの定義、制約の明文化、最終結果の評価である。

チャット型でJPEGエンコーダーを開発、最初は約1fps

石原氏が2025年に取り組んだのは、Webブラウザ上のチャット型AIを使ったRTL開発だ。AIにコードを生成させ、設計者がそのコードを開発ツールに貼り付け、実行結果を再びAIに渡す。この方法でも回路自体は作れたが、AIと開発ツールの間で人間が情報を往復させることが、開発速度の制約となった。

当初は「JPEGエンコーダーを作って」と指示しても、10回程度試しただけでは狙ったRTLが得られなかったという。そこで、色成分の処理、量子化、ハフマン符号化など、JPEGエンコーダーを機能ごとに分割して個別に生成する方法に切り替えた。その結果、動く回路の作成には成功したものの、処理性能は約1fpsにとどまった。

同氏は、TCP/IPオフロード・エンジンの開発にも挑戦したが、チェックサムのバイト単位の計算やエンディアンの扱いで苦労したという。こうした経験から、AIには「作ってほしいもの」を漠然と指示するだけでなく、守るべき構造や制約を明確に伝える必要があると認識した。

単一AIエージェントが6モジュールを生成、約78fpsまで改善

次に取り組んだのが、Claude CodeやCodexのように、ターミナルから開発ツールを実行できる単一エージェント型の開発だ。AIがコードを生成するだけでなく、ツールを実行して結果を確認し、修正案を試すため、設計者による手作業の受け渡しを減らせる。

同じJPEGエンコーダーを単一エージェント型で再開発した際には、AIが6つのモジュールに自動分割してRTLを生成した。初期段階では遅延が約8nsで、回路は動作するものの、要求性能には届かなかった。そこでAIが演算方法の見直し、パイプライン構成の検討、配置配線の試行を繰り返し、最終的には約250MHzで動作する、約78fpsのJPEGエンコーダーを構成できたと説明した。

ここで重要なのは、AIが一度の生成で完成させたわけではない点だ。達成すべき周波数、スループット、対象デバイス、モジュール名・信号名、入力データと期待結果の一致条件などを仕様に記し、AIに試行錯誤を続けさせたという。また、不要な機能を追加しないことや、何を作らないかを明示することも有効だったと石原氏は述べた。

十数体のAIエージェントによる「開発組織」を構築

石原氏が現在採用しているのは、十数体のAIエージェントに仕事を分担させるチーム・エージェント型だ。人間が全体の責任者を務め、窓口となる「プロデューサー」役のエージェントを介して開発を指示する。下位には、仕事を分解して担当を割り振る役割や、個々の開発を進めるエージェントを配置する。いわば会社組織に似た構成で、複数の開発作業を並列に進める仕組みだ。

講演では、この方式を用いてRISC-Vのプロセッサと、通常はソフトウェアで実現するRTOSのタスク・スケジューラーをハードウェア化する開発に取り組んだ例が紹介された。RISC-Vのハードウェア、ハードウェア化したスケジューラー、両者を動かすためのミドルウェア、アプリケーションをそれぞれ分担させることで、設計対象が大きくなっても作業を並列化できたという。

ただし、規模の大きなシステムでは単一エージェントだけでは破綻することがあるとも指摘した。チーム化は単にAIの数を増やすことではなく、機能分割と担当範囲の明確化を前提とした開発手法といえる。

「制約は厳しく、手段は自由に」がAI活用の勘所

経験を積む中で、石原氏はAIが見落としやすい事項として、インターフェース、固定小数点、タイムアウト、バッファ、エンディアンなどを挙げた。こうした条件はAIが推測できるものとして扱わず、仕様に具体的に書き込む必要があるという。

一方、実装方法を細かく指示しすぎるのも得策ではない。例えば除算処理を高速化したい場合、特定の演算方式への変更を命じると、AIはその方法に考えを限定してしまう。それよりも達成すべきタイミング制約を与え、実現方法はAIに探索させた方がよいと説明した。石原氏は、この考え方を「制約は厳しく、手段は自由に」と表現した。

また、AIが途中で試行錯誤している際には、すぐに処理を打ち切らず、前進している限り見守ることも必要だと述べた。中断によって、それまでに蓄積された試行の文脈が失われることを懸念しているためだ。

既存開発への導入はテストベンチから

講演の終盤、石原氏は、独自に用意した「AIプロジェクト」という管理ツールも紹介した。やりたいことをA4用紙1枚程度にまとめて入力し、そこからAIに要求仕様、設計仕様、タスク仕様を作成させ、前述の3つの手法を回すという。AIエージェントが作業に行き詰まった際には、「多角サブエージェント解析」という指示で複数のサブエージェントから検討させる使い方も披露した。

また石原氏は、どの生成AIがRTLに向いているかについては、モデルによる差以上に開発の進め方が重要だという見方を示し、既存プロジェクトにもテストベンチの整備から導入できると説明。高位合成との比較については用途によるとしつつ、自身はRTLを直接生成する手法に可能性を感じているという。商用IPについては、実績のあるものは引き続き活用し、ニッチな回路や仕様変更の多い回路ではAIによる開発が有効との考えを示した。

Foundation Modelでも十分活用できる

今回の講演で特に興味深かったのは、FPGAを対象とした取り組みではあるものの、高価な専用EDAソリューションを前提とせず、汎用の基盤モデル（Foundation Model）であるLLMを活用してRTL設計を進めている点だ。さらに、単なるコード生成にとどまらず、仕様の定義から検証、最適化に至るまで、AIを活用したハードウェア設計の実践的な方法論が示された点も注目に値する。

EDA業界では今、「Agentic EDA」が大きな潮流となりつつあるが、そうした専用ソリューションに依存せず、身近な汎用LLMを起点としてハードウェア設計へのAI活用を進めるというアプローチは、むしろ新鮮に映る。AIによる設計自動化が急速に進展する一方で、その導入には依然としてハードルを感じている開発現場も少なくないだろう。今回示された手法は、そうした現場にとって、AI活用への第一歩を踏み出すための現実的かつ有用な指針となりそうだ。

Design Solution Forum 2026