ChipAgents対談：エージェント型AIが変革するEDAとチップ設計ワークフロー
2025年6月11日 - Semiconductor EngineeringによるChipAgentsインタビュー
LLMからエージェント型AIへの移行を理解する
Ann Mutschler氏：Semiconductor Engineeringでシニア・エグゼクティブ・エディターを務めるAnn Mutschlerです。本日はChipAgentsのMahir Arora氏をお迎えし、エージェント型AI（Agentic AI）について議論します。Mahirさん、本日はありがとうございます。まず、エージェント型AIとは何か、そしてそれがチップ設計者にとって何を意味するのか教えていただけますか。
Mahir Arora氏：大規模言語モデル（LLM）は極めて新しい技術であり、AIエージェントはそのさらに新しい技術です。どちらもEDA（電子設計自動化）の領域全体に完全に浸透しているとは言えません。AIエージェントとLLMの違いを真に理解するには、まずLLMとは何か、ハードウェア分野におけるその欠点は何かを振り返り、その上でAIエージェントがハードウェア設計エンジニアや検証チームのワークフローをどのように改善するのかを考える必要があります。LLMについては、すでにChatGPTなどを使ってメールの下書きを作成するといった経験から、多くの人が実務的な視点で馴染んでいることでしょう。
[画像説明：Mahir氏がホワイトボードの前に立ち、LLMのメカニズムとエージェント型AIの反復的なフィードバックループについて図解している様子]
Mahir Arora氏：このホワイトボードに、LLMとAIエージェントの核心的な概念をいくつか書き出しました。字が汚いのはご容赦ください。LLMの核心的なアイデアは、「回帰的トークン予測（Autoregressive Token Prediction）」または「回帰的シーケンスモデリング」と呼ばれるものです。その意味するところは非常に単純です。GPT-4oのような強力なLLMがあれば、「2たす2は？」といった質問を投げることができます。この質問は「トークン化」されます。詳細な手法はさておき、入力はLLMが理解できる単位に分解されます。入力を与える際、「2たす2の答えは」といった前置きを加えることもできます。LLMは基本的に、この末尾の空欄を埋めるように学習されています。末尾に未知の「マスク」が置かれ、そのトークンを予測するように訓練されているのです。
Mahir Arora氏：数学的に言えば、LLMは確率分布を予測します。過去の入力トークンすべてを前提として、未知の値が何であるかを予測しようとするわけです。強力なLLMであれば、トークン予測タスクにおいて「2たす2」の出力として「4」である可能性を強く示唆します。このホワイトボードの例では、「4」である確率が約99%、「5」である確率が1%、「マダガスカル」のような無関係な単語が出る確率が10億分の1といった具合です。これは、プロンプトに対して空欄を埋めるような形式の質問には最適です。しかし、単に空欄を埋める以上のことが求められたらどうでしょうか。
Mahir Arora氏：そこで登場するのが回帰的シーケンスモデリングです。「Auto（自己）」が「regressive（回帰的）」に戻る、つまり自分自身に立ち返るという意味です。LLMに特定の関数を完成させたり、文章やコードベース全体を出力させたりしたい場合、単一のトークン予測を何度も繰り返す必要があります。ホワイトボードにあるように、「add」という関数の入力トークンと開き括弧を与えたとします。ここで先ほどと同じ問題が発生します。マスクされた次のトークンを予測しなければなりません。出力には「num1」や「a」といった複数の可能性があります。それぞれの出力には確率が割り当てられており、魔法は「サンプリング」にあります。確率分布に基づき、例えば「a」というトークンをサンプリングしたとします。次に、この「a」を入力に戻し、プロセスを続行します。ステップ2では「function add, (, a」となり、同じ問題が繰り返されます。これを繰り返すことで、回帰的に次のシーケンスをモデル化できるのです。
自己省察とフィードバックループの力
Ann Mutschler氏：先ほど「自己省察（Self-reflection）」についてもお聞きしようと思っていました。それはどのように関わってくるのでしょうか。
Mahir Arora氏：素晴らしい質問です。自己省察を語るには、このプロセスをn回繰り返した後に何が起こるかを考える必要があります。n回繰り返すと、例えば「function add, a, b, return a plus b」といった完全な出力が得られ、最後に停止トークンが予測されてプロセスが終了します。ここで注目すべきは、サンプリングの過程で「a」を出力すると決めたら、その決定に従い続けなければならないという点です。後続のシーケンスで突然考えを変えて「return num1 plus num2」とは言えません。過去の決定が未来の決定に影響を与えることはあっても、その逆は不可能なのです。もしサンプリングで間違えて「閉じ括弧」を出力してしまったら、もう手遅れです。本質的に誤った出力を生成することになります。情報が逆方向に流れないため、過去の誤った決定が未来の誤りを確定させ、全体として誤った出力につながるのです。これが自己省察、洗練、そして自己修正の重要性につながります。ここでようやくエージェント型AIの話ができます。
Mahir Arora氏：エージェントについてまず理解すべきは、それがLLMの上に構築されているという点です。LLMから派生した技術ですが、エージェント型AIは単なるLLMの利用ではなく、プロセスそのものを指します。エージェントがどのように自己修正を行い、問題を根本的に解決するのか、その舞台を整えましょう。
Ann Mutschler氏：エージェントとは何か、もう少し詳しく教えていただけますか。
Mahir Arora氏：もちろんです。エージェント型AIは「プロセス」です。LLMを一度使って終わりではありません。エージェントとは、LLMに検索プロセス、そして何よりも「フィードバック」を組み合わせたものです。フィードバックを利用して自己修正し、自己安定化を図ることで、LLM単体では失敗するようなタスクを遂行します。具体例を見てみましょう。エージェントプロセスでは、タスク全体を入力として与えます。例えば「非同期FIFOのようなVerilogモジュールを書きたい」といった場合です。モジュールの詳細はさておき、いくつかの「ターン」を経て進みます。
[画像説明：Mahir氏がホワイトボードを指し、コンパイラ、リンター、テストベンチ、波形からのフィードバックを含むマルチターンのエージェントプロセスを図示している]
Mahir Arora氏：1ターン目で、エージェントはLLMを呼び出して潜在的な出力を生成します。SystemVerilogで書かれた「fifo.sv」というファイルが生成されます。しかし、ここには先ほどの回帰的モデリングの問題が残っています。エージェントが入力ピンを定義しても、後で未定義のワイヤを使おうとするかもしれません。単なるLLMであれば、そのままコードを出力して終わりです。コンパイルして実行しても動作せず、失敗に終わります。我々が求めているのはそうではありません。「省察とフィードバック」が必要です。1ターン目の後、コンパイラ、リンター、テストベンチなどからフィードバックが得られます。アサーションエラーやテスト失敗、ログ内の異常、波形出力などがこれにあたります。これらすべてをエージェントプロセスが検証します。フィードバックをエージェントに戻すと、エージェントは過去の出力との文脈の中で何が間違っているかを分析し、デバッグして修正を試みます。これを繰り返すのです。2ターン目で問題を修正し、さらに別のテストで失敗すれば、また修正します。最終的な目標は、単にモジュールを作ろうとするだけでなく、フィードバックを通じて自己修正・自己安定化し、最終的に正しく動作する実装を完成させるシステムを構築することです。
EDAにおけるAIエージェントとVerilog-Evalベンチマーク
Ann Mutschler氏：エージェントは今後、EDAツールにどのように組み込まれていくのでしょうか。
Mahir Arora氏：良い質問です。ChipAgentsでは、日常的なEDAフローの一部としてエージェントを活用する製品を開発しています。その活用事例は多岐にわたります。重要なのは、ハードウェアにおけるLLMの性能とエージェントの性能が劇的に異なるという点です。Nvidiaが作成した「Verilog-Eval」という非常に一般的なベンチマークがあります。自然言語による記述から機能的なVerilogモジュールを生成するタスクにおいて、標準的なLLMの性能は極めて低調です。Pythonのソフトウェアタスクでは非常に優秀なGPT-4oのような強力なモデルでも、Verilogタスクでは正解率約50%という壊滅的な結果になります。50%では不合格であり、実務には使えません。しかし、LLMをエージェントプロセスで包み込むと、性能は劇的に向上し、80%〜90%の範囲に近づきます。ここで説明したシステムは最も単純な形式ですが、さらに改善を重ねることで、最終的に99%から99.7%というレベルまで引き上げることができます。エージェントを使うことで、これらのベンチマークを飽和させることが可能なのです。LLM単体では不可能ですが、エージェントならそれができます。
Mahir Arora氏：これが、これまでLLMがハードウェアエンジニアの日常業務に浸透してこなかった理由です。標準的なLLMは、エンジニアが求めるタスクをこなすには信頼性が不足していたからです。しかし、AIエージェントにはその信頼性があります。現在、顧客がAIエージェントを最も活用しているのは「ラピッドプロトタイピング」です。設計エンジニアは、複数のマイクロアーキテクチャ案を検討し、消費電力、性能、面積（PPA）を評価して、パレート最適解を見つけたいと考えています。しかし、その実験環境の構築には多大な労力がかかります。ビルドスクリプトやシミュレーション環境の構築、既存のテスト環境へのモジュール統合などです。エージェントはここで素晴らしい働きをします。マイクロアーキテクチャの記述をエージェントに与えれば、リポジトリやドキュメント、仕様書から自律的に情報を収集し、長期的計画を立てます。自己修正と自己安定化機能を使って高品質なモジュールを実装し、既存のインフラと統合してテストを実行し、ログから情報を抽出して報告まで行ってくれます。
検証とシステム解析の効率化
Ann Mutschler氏：先ほど検証について触れられましたが、これはすべての設計・検証チームにとって大きな課題です。AIエージェントはそこでどのような役割を果たすのでしょうか。
Mahir Arora氏：重要な指摘です。検証が難しいのは、チップの複雑さが指数関数的に増大しているからです。個々のSoC（System on Chip）で数十億、システム全体では数兆個のトランジスタを扱っています。この複雑さをどう管理すればよいのでしょうか。検証エンジニアの大きな悩みは、検証対象のサブシステムについて深い理解を構築しなければならないことです。単一のモジュールではなく、サブシステム全体、あるいはSoCの大部分を検証しなければなりません。では、どうやってその情報を抽出するのか。人間が数万、数十万行のコードを読み解くのは非常に困難ですが、AIエージェントなら可能です。複雑なシステム内でのデータフローを解明するといったオープンエンドなタスクをエージェントに任せれば、階層的で長期的な計画を立てて情報を探し出します。たとえ特定の場所で見つからなくても、エージェントは自ら計画を修正し、別の場所を探して情報を統合し、システム内のデータフローを説明してくれます。データフローが分かれば、検証方法や考慮すべきエッジケース、必要な刺激（スティミュラス）も明確になります。
設計・検証チームの日常への影響
Ann Mutschler氏：設計・検証エンジニアの日常業務はどのように変わるのでしょうか。
Mahir Arora氏：より広範に見れば、チームにとって非常に大きなインパクトがあります。AIエージェントは、タスクが多すぎる個人の手元で大きな力を発揮します。設計側ならマイクロアーキテクチャの構築、検証側なら検証計画の策定や興味深い条件・制約・エッジケースの探索が主業務ですが、実際にはテストベンチの構築やUVMシーケンスの記述など、付随するタスクが山積みです。AIエージェントを使えば、これらのタスクを非同期にバックグラウンドで処理させ、同時に複数のタスクをこなすことができます。
Mahir Arora氏：検証エンジニアの現場では、検証計画と既存のテストベンチ（例えば前世代のプロセッサのもの）をエージェントに与え、新しいシーケンスや機能を追加させるというフローが定着しつつあります。これにより、小規模なチームが大規模なチームのような成果を出せるようになります。我々自身もスタートアップですが、多くのスタートアップや大企業と協力する中で、AIエージェントがもたらす「フォース・マルチプライヤー（戦力倍増効果）」を実感しています。シニアエンジニア数名が、多数のジュニアエンジニアのサポートを受けているかのような環境が実現できるのです。これは非常にエキサイティングな変化です。
ジュニアエンジニアのオンボーディング加速
Ann Mutschler氏：ジュニアエンジニアについても伺いたいです。彼らの成長を早めるために、どのように役立ちますか。
Mahir Arora氏：良い質問です。経験の浅いエンジニアにとって最大の課題は、膨大なコードを理解することです。拡張や検証を始める前に、コードベースのメンタルモデルを構築しなければなりません。どこに何があるかを把握するのは人間にとって非常に困難です。人間は目で見て、人間の速度でしか読めません。一方、LLMとAIエージェントは並列処理能力により、遥かに高速に読み解くことができます。そのため、エージェントにシステムの仕組みを尋ね、特定のデータパスのブロック図を作成させるといった使い方ができます。エージェントが必要な情報をすべて収集し、ドキュメントを作成してくれるのです。これは顧客の間で非常によく見られる活用法です。プロセッサや大規模システムの仕組みを理解するためのメンタルモデルを構築する上で、新人のオンボーディングを強力に支援します。
IPセキュリティと計算リソースの制約
Ann Mutschler氏：AIにはセキュリティの問題もあります。AIエージェントやChipAgentsではどのように対応していますか。
Mahir Arora氏：セキュリティは常に重要な論点です。顧客のIP（知的財産）は極めて重要です。AIエージェントによる生産性向上を享受しつつ、いかにIPセキュリティを維持するか。これは企業や顧客によって異なります。AIエージェントを最大限活用するには、膨大な計算リソースが必要です。最高のエージェントは、エージェント学習データでファインチューニングされた大規模なベースモデルを必要とし、強力なサーバーが不可欠です。社内に余剰リソースがある組織もありますが、多くの企業はクラウド上のGPUサーバーを借りる必要があります。
Mahir Arora氏：ChipAgentsでは、多様な顧客に対応しています。クラウド環境でのデプロイを好む顧客には、我々がGPUリソースを調達し、データは転送中および保存時にすべて暗号化するか、メモリ上で一時的に処理して返却するといった保証を提供しています。これは上場企業を含む多くの顧客にとって有効な妥協点です。一方で、非常に厳しい制約を持つ大企業の場合、自社のクラウド環境へのデプロイを求められることもあります。AWSアカウントなどを提供してもらい、短期間で環境を構築して社内で利用できるようにするといったケースは一般的です。
Ann Mutschler氏：Mahirさん、本日は詳細なご説明をありがとうございました。
Mahir Arora氏：貴重なお時間をいただき、ありがとうございました。