チップおよび半導体

ワークフローを再構築せずにRF回路設計へAIを導入する実践的方法

本稿は、無線周波数回路設計にAIを段階的に導入する道筋を提案する。まず専門知識を文書化し、次にツールを連携させ、その後、設計探索を高速化する。モデルの速度だけでは不十分であり、シミュレーション結果が実測ハードウェアと対応していることの検証と、訓練データの追跡が必要だと強調している。

2026-08-27
1 分で読めます
12 閲覧数
فريق تحرير certi.news
ワークフローを再構築せずにRF回路設計へAIを導入する実践的方法

Semiconductor Engineeringが2026年8月27日に掲載した記事は、無線周波数(RF)回路設計への人工知能(AI)の導入を、現在のプラットフォームを置き換えたり、ワークフロー全体を再構築したりする必要のあるプロジェクトではなく、段階的な道筋として捉えるよう呼びかけている。その出発点となるのは実務上の問題だ。RFおよびマイクロ波チームの能力の大部分は、経験豊富なエンジニアが蓄積してきた組織内知識に依存している。そこには、電力増幅器の設計手法、デバイスの特性評価、作業中に下されるものの再利用可能な形で文書化されていない判断が含まれる。

記事によれば、こうした専門知識が失われると、新人エンジニアの育成期間が長期化し、設計空間の評価が遅れ、より多くの候補を試験すれば発見できたはずの再設計が発生する可能性がある。したがって、最初に問うべきなのはチームがAIを導入するかどうかではなく、実際の設計成果物の製作にエンジニアが依存しているツールを妨げずに、この能力をどう構築できるかである。

並行して実行できる3つの段階

筆者のDaren McClearnonは、情報源によればKeysightでAIおよび機械学習の製品マネージャーを務めており、知識の取り込み、ツールの連携、探索の高速化という3段階の枠組みを提案している。この枠組みでは、ある段階を完了してから次の段階を開始する必要はない。

専門知識を取り込み、再利用可能な資産に変換する

情報源は、RFの専門知識は通常、コードだけに存在するのではなく、ツール、方程式、そしてシミュレーション結果を実測ハードウェアで観測される結果と結び付ける実務経験に分散していると指摘する。取り込みの段階では、この知識をチームが実行・共有でき、後にソフトウェアエージェントへ引き渡せる形式へ変換すべきである。

  • 回路図とレイアウトを、調整可能なパラメーターを持つPythonコードへエクスポートする。
  • 専門家の手順を実行可能なスクリプトとして記録する。
  • シミュレーションのフローダイアグラムを、エージェントベースのシステムが理解できる文書化されたコードへ変換する。

この段階の実務的な価値は、それ自体で大規模言語モデルを使うことではなく、内部の方法論を可視化し、特定の個人の記憶にとどめず、再現可能にすることにある。

スクリプト作成から目標設定へ

連携の段階では、取り込まれた知識を活用する。エンジニアがすべてのスクリプトを手作業で記述・管理する代わりに、例えば20 dBを超える利得と28 dBmを超える出力電力を持つMMIC電力増幅器を設計するというように、求める結果を指定し、ツールに接続された大規模言語モデルに適切なツールの発見と呼び出しを任せることができる。

しかし記事によれば、これは完全な自律性へ直接移行することを意味しない。現在、組織は多くの場合、手作業によるプログラミングと、エンジニアの意図を理解しつつ人間による監督を近くに残す初期の協調支援との間に位置している。次の段階は、同じ連携基盤に依拠し、部分的な委任のもとで複数段階のタスクを担う専門エージェントである。

物理を監視し続けながら探索を高速化する

第3段階では、探索できる設計数を増やし、待ち時間を短縮することに焦点を当てる。情報源は主なツールとして2つを挙げている。1つはサロゲートモデリングで、重い電磁シミュレーションをニューラルネットワークに基づく高速な近似へ置き換えるものであり、一部の構造では規模の観点で2桁から3桁速くなる可能性がある。もう1つはAI支援最適化で、より多くのパラメーターを同時に扱い、少ないシミュレーション回数で適切な解を見つけることができる。

ただし、結果が信頼できなければ高速化は実務的な価値を持たない。特にリスクが顕著なのは、パッケージング、インターコネクト、結合、電源およびグラウンドの完全性、3次元電流である。これらの要因によって、高速で確信に満ちた回答が実際のハードウェアの挙動から大きく外れ、ひいては故障の根本原因分析を難しくする可能性がある。そのため、システムへの委任範囲を拡大する前に、モデリングで用いた物理を実測値と比較しなければならない。

拡大する前に何を検証すべきか

この枠組みは、モデルの品質だけでなく、データの出所を追跡することの重要性も強調している。チームは、サロゲートモデルの訓練データの出所、データがどのようにラベル付け・クリーニングされたか、既知の仮定と制約が何であるかを把握する必要がある。この透明性こそが速度の限界を定め、速度が見えないリスクへ変わるのを防ぐ。

情報源は、RFIC設計会社であるSphere Semiの例を紹介している。同社は、一度に1つの設計を探索するという問題に直面していた。同社は、生成、シミュレーション、ランキング、最適化の各段階を実行するため、完全にコードで定義され、Pythonを基盤とするフローを採用し、回路と電磁気の協調シミュレーションを通じて数百から数千の候補を実行した。記事に記載された数値によれば、この手法により、生産性が5~10倍向上し、絶縁が6 dB改善し、従来の手作業による設計プロセスと比較してフィルター面積が30%縮小した。

certi.newsの見解:記事が提案する実際の変化は、エンジニアを独立したエージェントに置き換えることではなく、分散した知識を実行可能なフローへ移し、それを明確な設計目標と測定可能な検証ツールに結び付けることだ。これにより、導入は単一のプラットフォームに関する判断との結び付きが弱まり、文書化、データ、測定の品質との結び付きが強くなる。ただし、前述の結果は情報源が示す1つの例に関するものであり、同じ効果があらゆる設計や環境で再現されることを単独で証明するものではない。また、パッケージング、構造、データが変化した場合のサロゲートモデルの一般化可能性と限界などの問題については、各チーム固有の検証が必要である。

ニュースの出典
Semiconductor Engineering
原文を開く ↗
ف
著者

فريق تحرير certi.news

同じカテゴリー

おすすめ記事

すべてのニュースを見る