DVCon Japanレポート：パネルディスカッション ― 半導体設計の現場はどこまでAIに任せられるのか？ ※修正あり

2026年9月10日、技術カンファレンス「DVCon Japan 2026」がパシフィコ横浜ノースで開催された。

DVCon Japan 2026 公式ページ

DVCon（Design and Verification Conference & Exhibition）は、Accellera Systems Initiativeがメインスポンサーとなり、半導体や電子システムの設計・検証技術をテーマに開催される技術カンファレンス。米国では30年以上の歴史を持ち、日本では2022年から開催されている。

論理設計や機能検証、HW/SW協調検証、SystemVerilog/UVM、フォーマル検証、HLS、機能安全、セキュリティなど幅広いテーマを扱い、近年はAI/LLMの設計・検証フローへの適用も主要テーマとなっている。

今年の「DVCon Japan 2026」は、基調講演、パネルディスカッション、査読論文によるテクニカルセッション、チュートリアル、企業展示などで構成。NVIDIAによる「AI Physics × Agentic AI」の基調講演や、「Agentic AI：先端EDAの状況と開発の実情」と題したパネル・ディスカッションなど、半導体設計・検証へのAgentic AI活用が大きく取り上げられた。

ここでは恐らく現在設計現場で一番ホットな話題、「半導体設計の現場はどこまでAIに任せられるのか？」をストレートに取り上げたパネル・ディスカッション「Agentic AI：先端EDAの状況と開発の実情」の内容をレポートする。

本パネル・ディスカッションの登壇者は以下の通り。

モデレータ：
笹川幸宏（株式会社ソシオネクスト）

パネリスト：
立堀道昭（日本アイ・ビー・エム株式会社）
旦木秀和（Sony Electronics Inc.）
鶴崎宏亀（Rapidus株式会社）
西沢研人（シーメンスEDAジャパン株式会社）

パネルの冒頭で笹川氏がでChatGPTやGeminiなど一般的な生成AIを普段利用している人を尋ねると、ほぼ全員が挙手した。一方、Agentic AIを実際のLSI設計、検証、P&Rなどに利用している人を尋ねると、ほとんど手が挙がらなかった。

ソフトウェア開発ではCoding Agentが急速に普及しているが、半導体設計において少なくともまだ日本国内の多くの現場では、「使えそうだが、実際どこまで使えるのか」という段階にあると言っていいのかもしれない。

パネルでは「仕様書からのRTL生成」、「Agentic AI環境の構築」、「AIにどこまで任せるのか」、「AI時代の設計者育成」など、かなり現場に近いテーマが議論された。

「仕様書からRTL」は可能。ただし問題はその先

最初のテーマは、「仕様書からRTLを生成することは現実的か」。

Rapidusの鶴崎氏は、実際のファウンドリ利用を考えれば、仕様書から新しいRTLをゼロから作るだけがAIのユースケースではないと指摘した。

既存チップを新しいプロセスへ移行したり、機能を追加・削除したりするケースでは、すでに何らかの「お手本」が存在する。そのため、既存RTLの修正、リライト、インプリメントといった用途の方が現実的で、Rapidusではそうした用途に利用できるLLMの開発を進めているという。

一方、Siemens EDAの西沢氏は、RTLを生成できることと、「実際に使えるRTL」を生成できることは別だと指摘した。

構文として正しく、要求された機能を実装したコードを生成するところまでは、一般的なCoding Agentでもかなり進んでいる。しかし半導体では、その先にLint、機能検証、そしてPerformance、Power、Area（PPA）最適化がある。

西沢氏は、一般的なAIだけですべてを解決するのではなく、AI Agentが既存EDAツールを利用して品質を確認しながら設計を改善していくことが必要になるとの考えを示した。

言い換えるとAgentic EDAの現実的な姿は、AIがEDAを置き換えるのではなく、AIがEDAを使うというものだ。

RTLを生成し、Lintを回し、検証を実行し、結果を解析して修正する。さらにPPAを確認しながら繰り返す。こうしたループを人間の代わりにAgentが回すところに、Agentic EDAの本質がある。というSiemens EDA西沢氏の主張は今日の設計業界のトレンドの王道をいくものと言える。

AIより先に「仕様書」を直す必要がある？

興味深かったのが、「AIに仕様書を渡しても、期待したRTLが出てこない」という問題についての議論だった。

簡単なチュートリアルを試すと「おお、できている」と感じる。しかし、自分がよく知っている実際の設計を生成させると、一見それらしく見えても、詳しく確認すると使えない。「直しているうちに、自分で書いた方が早かった」という話もよく聞くとIBM立掘氏。

これに対してSiemens EDA西沢氏からは、AIだけではなく、入力する仕様側にも問題があるとの指摘があった。

人間同士なら暗黙的に補完できる記述でも、AIにとっては曖昧である場合がある。高品質なRTLを生成するには、階層構造などを含め、インプリメンテーション仕様としてかなり具体的なレベルまで落とし込む必要がある。

逆に、AIにいきなりRTLを書かせるのではなく、「仕様のどこが曖昧なのか」をAIに指摘させるという使い方も有効ではないかと西沢氏はコメントした。

これは、AIによるRTL生成以前に、「AIが読める仕様書を作る」という仕事が重要になるという話だ。

さらに会場からは、「正常系よりも例外処理が難しい」という指摘も出た。
「このエラーが発生したらどうするのか」といった異常系は仕様書に明確に書きにくい一方、実際の製品では非常に重要になるというものだ。

これについては、現状AIが自動的にすべてを補完できる段階ではなく、アサーションなどを使った検証を充実させ、テストを通じて仕様の穴を発見し、仕様とRTLを反復的に更新していく形が現実的だとSiemens EDA西沢氏は意見を述べた。

Agentic EDAで重要なのは「Harness Engineering」

続いて議論は、「Agentic AIシステムを誰が作るのか」というテーマへ進んだ。

IBM立掘氏は、その前提としてまず、「自分たちは今、どうやって開発しているのかを理解することが重要」と指摘した。

半導体設計の現場では、設計フローや判断基準の一部が文書化されず、ベテラン設計者の経験として「一子相伝」のように残っている場合もある。しかし、その状態でAgentに「後は良きに計らって」と頼んでも、現在のAIは期待通りには動かないと立掘氏。

Agentにどんなナレッジを与えるのか。どのツールを使わせるのか。何をもって成功と判断するのか。失敗したらどこへ戻るのか。こうしたAIが仕事をするための環境やワークフローそのものを設計すること、すなわち「Harness Engineering」が重要になると立掘氏は指摘した。

言い換えれば、Agentic EDAで重要なのは、単に高性能なLLMを導入することではない。「AIを働かせる仕組み」を作ること。という考え方と言えるだろう。

「上司の仕事は安いAIでいい？」

モデルの使い分けについても面白いやり取りがあった。

クラウドの高性能モデルを使うのか、ローカルLLMを使うのかという問いに対して、IBM立掘氏から示された答えは「両方使う」だった。

すべての仕事に高価なフロンティア・モデルを使う必要はない。「上司が『君これね』と仕事を割り振る部分は、安いモデルでいい」と立掘氏。例えば仕事を分割したり、次の作業を割り振ったりする、いわば「マネジメント・ワーク」は比較的軽量なモデルでも対応できる。その一方で緻密な生成や高度な推論には強力なモデルが必要になる。

立掘氏の指摘を踏まえると、Agentic AIでは一つの巨大モデルですべてを処理するのではなく、仕事の難易度に応じて複数のモデルを使い分ける構成が現実的になりそうだ。

ベンダーのAgentだけでは完結しない

ソニーの旦木氏からは、実際の半導体開発全体を一つのAgentic AIでカバーするのは難しいとの指摘があった。

設計、検証など工程ごとに異なるAgentを組み合わせる必要がある。さらに重要なのは、Agentそのもの以上に、「社内のナレッジやスキルをどのように蓄積するか」だという。

企業レベルで共有するナレッジと、プロジェクト固有のナレッジをどう分け、どこに保存し、Agentからどう利用するのか。こうした仕組みまで考えると、EDAベンダーのソリューションだけですべてを完結させるのは難しく、ユーザー企業側にもAgentic AI環境を構築する能力が求められると旦木氏は語った。

モデレーターの笹川氏も、この議論を「ベンダーのツールは有効だが、それだけで終わらないピースがたくさんある」とまとめた。

Legacy RTLはAI時代の重要な資産になる

会場からは、「社内に大量に残っているレガシーRTLをAIで活用できないか」という質問も出た。

例えば、既存RTLをAIに読ませる→仕様を抽出する→仕様を変更する→ RTLへ反映する。というフローだ。

Siemens EDA西沢氏は、既存RTLを直接読み込み、そこへ改訂を加えるフローは当然考えられるとの回答があった。

IBM立掘氏もそのフローは王道と同調した上で、そこで重要になるのがトレーサビリティだと指摘。更にソニー旦木氏もそのワークフローをどう定義するかが重要であると付け加えた。

これは、仕様からRTLへ一方向に流すだけでなく、要求が変更された際に、どの部分がどう変わったのかを追跡可能にする必要があるという話。AIが設計を変更する時代だからこそ、「誰が何を変えたのか」ではなく、「どのAgentが、どの判断に基づき、何を変更したのか」を記録する仕組みが重要になるという考えだ。

最大の問題は「コンテキスト」― ベテランの暗黙知をどうAIに渡すのか

パネル後半で議論の中心になったのが「コンテキスト」の問題だった。

会場から、Agentic AIを実際に利用すると必ず詰まるポイントは「コンテキスト」ではないか、という指摘が出た。Agentは自律的に動くが、自律的に正しい判断をするには「何を良しとするか」という判断基準が必要になる。

しかし、その判断基準は仕様には書かれていないことが多い。企業固有の設計ルール、過去の失敗、PPA改善の経験、ベテランが無意識に行っている判断など。そうした情報は人の頭の中にある。

「コンテキスト」をどう集めAIに活用させるか？　その問いに対してIBM立堀氏から、既存のコンテキストを集め、それをAgent自身に読ませることで、Agentが使いやすいコンテキストへ変換していく方法（これもHarness Engineering）が紹介された。

さらに興味深いのが、立堀氏が語った「AIの出力と人間が修正した履歴」をナレッジとして利用する方法だ。AIが生成したものと、人間が最終的に求めたものとの差分を見れば、「入力には書かれていなかった判断基準」が見えてくる。

つまりAgent自身に、「なぜ人間はここを修正したのか」を考えさせることで、ベテラン設計者の暗黙知を抽出できる可能性があるという。

これまで何十年も企業が苦労してきた「暗黙知の形式知化」に、Agent自身を利用できる可能性が出てきたわけだ。

ただし「昔のノウハウ」は本当に正しいのか

ここでRapidus鶴崎氏からは、別の興味深い視点も示された。ベテランが蓄積してきたナレッジを、そのままAIへ継承することが本当に正しいのかという問いだ。

例えばAIが作ったフロアプランが、人間には「なんだこれは」と思えるような形でも、PPAを測れば人間の設計より優れている場合がある。つまり、長年の経験から生まれた設計ノウハウが、AIによる探索にとって必ずしも最適解とは限らないという指摘だ。

これに対し、IBM立掘氏からは、だからといってAIにゼロからすべて探索させれば、そこへ到達するまでに膨大なコストと時間がかかる可能性があるとの意見も出た。現実的には、従来のナレッジを「型」や初期値として与え、そこからAIにさらに新しい解を探索させる方がよいのではないか、という考えだ。

このやり取りはAgentic EDAを考える上で非常に興味深い。

AIの役割は、人間のナレッジを単に再現することではない。人間のナレッジを出発点に、それを超える解を探すことになる可能性がある。

「1000個のAI Agent」をどこで使う？

会場の大学研究者からは、「現在は5個や10個のAgentを使っているが、将来1000個のAgentを同時に動かすとしたら、半導体開発のどこに使えるか」という質問も出た。

候補として挙げられたのが検証だ。大量のテスト作成など、現在多くの人手を投入している作業を、多数のAgentへ分割できれば、大幅な高速化が期待できる。

IBM立掘氏からは「1週間かかる検証作業を1時間にできるかもしれない」という例も示された。

一方、質問者自身が指摘した問題は、検証はチェスほどきれいに整理された問題ではないことだ。すなわち、1000個のAgentを用意することより、一つの巨大な問題を1000個の小さな問題へどう分解するかの方が難しい。

今後Agentic EDAが大規模化すれば、問題の分割そのものが重要な技術の一つになる可能性があるが、それ自身もまたAIが解決してくれるということも十分考えられるだろう。

AIにどこまで設計を任せるのか

最後の議論は、人間の役割だった。AIに設計、検証、最適化を任せるようになった場合、人間はどこまで理解している必要があるのか。

IBM立堀氏からは、「少なくともハイレベルには、自分自身で説明できる状態にしておくべき」との趣旨の意見が出た。「Agentにやらせたので分かりません」という態度では、実際の製品開発では通用しないという指摘だ。

同様にソニー旦木氏も、Agentへ丸投げするのではなく、出てきた結果が正しいかどうかを判断できる能力は残す必要があるとの意見が示された。

Rapidus鶴崎氏はさらに踏み込み、「最終的にはアイデアからチップまで」を全てAIで実現したいと語った。検証条件が決まっていて、その条件を満たす最良のチップができるなら、途中でAIがどんな設計方法を使っても構わないという考え方だ。

一方、パフォーマンスやパワーを限界まで追求する先端設計では、その結果が正しいかを判断するために、半導体設計やプロセスに対する深いナレッジは依然として必要になるとも指摘した。

設計フローは全自動でもいい

Siemens EDA西沢氏からは、EDAベンダーとして興味深い考えが示された。

設計フロー自体は、「全部自動でもいい」という。重要なのは、人間が最後に「この結果で本当に問題ない」と判断できることであり、そのためEDAベンダーには、AIが行った処理について、人間が判断するためのエビデンスを分かりやすく提示する役割が求められるとした。

つまり将来の半導体設計は、AIが設計し、→ EDAがエビデンスを提示し、 人間が判断するという形になっていくのかもしれない。

AI時代の設計者に必要なのは「作る力」から「判断する力」へ

この議論は若手設計者の育成にもつながった。AIがRTLを書き、EDAを操作し、検証まで行うようになった時、若手設計者は何を学ぶべきなのか。

パネルでは、すべてを手作業で経験すること以上に、「何を作りたいのか」、「結果は正しいのか」、「なぜこの結果になったのか」を理解・判断できる能力が重要になるとの方向性が示された。

Siemens EDAの西沢氏も、細かなコードの書き方そのものの重要性は相対的に下がり、「何を作るか」という明確なビジョンを持ち、それを仕様へ落とし込み、AIへ伝える能力が重要になるとの考えを示した。

Agentic EDAの勝負は「AIモデル」から「AI中心の設計環境」へ

今回の議論から見えてきたのは、今後Agentic EDAを設計に活用していくにあたって重要なのは、AIが働くための半導体設計環境を、どう構築するかということだ。

そして、その環境の中に企業が持つナレッジをどう組み込み、AIが行った設計を人間がどう評価するか。

Agentic EDAの競争軸は、モデルそのものから、こうした「AI Design Environment」へ少しずつ移り始めているように見える。

今回のパネルは、その変化が未来の話ではなく、すでに半導体設計の現場で具体的に議論され始めていることを感じさせる内容だった。1年後にこの日の議論がどこまで現実の設計フローに入り込んでいるのか。次回のDVCon Japanで、その答え合わせをするのが今から楽しみだ。

DVCon Japan 2026