OpenAIがGPT-6 AstraでKiCad上の回路設計デモを見せたことで、AIに電子回路を任せる話が一段現実味を帯びてきた。EEBenchは、その「それっぽく見える」デモが本当に使える設計なのかを測るための仕組みを公開している。単に回路図を描けるかではなく、制約を満たし、シミュレーションに通り、しかも現実の部品条件でも破綻しないかまで見るのが肝だ。この記事は、そのベンチマークの狙いと、今のモデルがどこまで来ているかをまとめたものだ。
元記事の中心にあるのは、AIが回路基板を作れるかどうかを、見た目ではなく結果で判定しようという話だ。EEBenchのチームは、OpenAIの発表でGPT-6 AstraがKiCad上で回路ボードを扱うデモを見て、電子工作が大きなモデル発表に入ってきたことを面白い変化だと受け止めている。ただし、そこからすぐに「AIにスマホ一式を一発で作らせられる」段階ではないとも言う。だからこそ、生成された電子回路が本当に良いものかを測る方法が必要になる。
その答えとしてEEBenchは、GUIをマウスで操作させるよりも、宣言的コードで回路を表す atopile を使っている。回路はコードの中にあり、AIは部品や接続、電気的制約を直接扱える。設計を変え、ビルドし、シミュレーションし、失敗箇所を確認するところまで同じプロジェクトの中で回せるので、画面の座標やメニュー位置を追いかける「コンピュータ操作」の負担が小さい。その分、ベンチマークは電子工学そのものをより強く試せるという考えだ。
記事では具体例として、住宅用エネルギーメーターの課題を挙げる。5V電源が消えたあと、処理中のマイコンが20msだけ生き延びて読み取り値を保存できるようにしなければならない。保護される電源レールは、その間ずっと3.0Vの brownout threshold を下回ってはいけない。AIがまず「コンデンサを足せばいい」と考えるのは自然だが、現実はそこまで単純ではない。セラミックコンデンサは電圧がかかると実効容量が公称値よりかなり落ちることがあり、部品のばらつきもある。容量を盛ればコストも面積も増え、電源復帰後の充電も遅くなる。
EEBenchは入力電源をシミュレーションで落とし、電圧がどう振る舞うか、実効容量がどれだけあるか、復帰後の戻りがどうか、さらにパッケージや dielectric、定格電圧、コストまで確認する。記事が挙げた失敗例では、提出された設計は名目上 22µF だったのに、4.7V の bias 下では実効容量が 11.4µF しかなく、必要な 545µF に遠く及ばなかった。ソースはビルドできたが、回路は課題に落ちた。実際の波形では、保護レールは 4.55V 付近から始まっても 0.85ms で 3V を割り、要求の 20ms をまったく満たせなかったという。
さらに難しい課題では、オペアンプ周りで multiple-feedback low-pass filter を合成し、抵抗とコンデンサの比から所定の poles を満たしつつ、部品公差が最悪側に振れても gain、cutoff frequency、Q の制約を守らせる必要がある。EEBenchはSPICEの回路を角ケースごとに組み直し、AC解析や transient を走らせ、probe に名前を付けて測定し、上下限に照らして判定する。部品は実在するメーカー品で、データシートの仕様がモデルに取り込まれている。つまり、理想値の計算ではなく、買える部品で、性能とコストと供給を両立させる設計が問われる。
採点は完全に決定的で、回路のビルド、回路グラフとBOMの作成、SPICEシミュレーション、設計チェックを順に行う。性能が満たされたあとでだけ、コスト効率が加点される。現時点のV1はアナログとデジタルをシミュレーションで扱うが、実機のレイアウト、製造、立ち上げまではまだ見ていない。チームはそこも将来的に加えたいとしている。
この話でいちばん興味深いのは、AIの弱点が「知識不足」ではないところだと思う。記事によれば、今のモデルは電子工学についてかなりの量を知っている。教科書、datasheet、application note、コードまで読んでいるからだ。にもかかわらず、実際の設計では失敗する。理由は、知識があっても現実の制約を一つずつ詰め切る能力がまだ甘いからではないか。特に電源保持のような課題は、理屈では簡単でも、電圧依存の実効容量や公差を入れると急に別物になる。
ここでEEBenchの価値が出る。AIが「コンデンサを選ぶ」という発想にたどり着くこと自体はもう珍しくない。しかし、選んだ部品が実際にはどれだけ働くか、パッケージや定格やコストまで含めて崩れないかを、機械的に突きつけるベンチマークはまだ少ない。人間の設計でも、うまくいったつもりの回路が部品実装後に失敗することはある。だからこの課題設定は、AIの評価というより、電子設計そのものの現実をちゃんと測っている感じがある。
ランキングの数字も無視しにくい。記事では、2026年9月1日の結果として Claude Opus 5 が 13タスク中 61.6% で首位、Grok 4.6 が 57.1%、Claude Fable 5.1 が 56.4% と続く。OpenAI系では GPT-5.5 が 42.3%、GPT-5.6 Sol が 39.4% だった。さらに xAI は Grok 4.6 の model card に EEBench を載せ、「engineering acceleration」の文脈で評価している。公開された実行では xhigh reasoning effort で 60.0% だったという。
ここで面白いのは、ベンチマークが単なる外部評価で終わっていない点だ。モデルを出した側が、自分たちの工程改善の物差しとして取り込んでいる。これは画像生成やコード生成で見てきた流れに近い。最初は研究者が「測るため」に作るが、やがてモデル開発側がその指標を気にし始める。EEBenchがその段階に入りつつあるなら、電子設計も「AIが少しできること」から「各社が競って伸ばす能力」へ移っているのだと思う。
ただし、順位の数字はそのまま実用性を意味しない。61.6% はまだ4割弱を取りこぼしているし、設計のどこで落ちたのかも重要だ。この記事はそこをあえて隠していない。性能が上がったと言っても、医療機器のペースメーカーを盲目的に任せる気にはまだならない、と明言している。私はこの慎重さが正しいと思う。ベンチマークで勝つことと、現場で事故を起こさないことの間には、まだ長い距離がある。
記事全体を読んで感じるのは、AIの進歩が「もっと賢い回路を思いつく」方向だけで進んでいるわけではないことだ。むしろ、部品を選び、制約を満たし、コストを抑え、供給可能性まで見るという、かなり地味な調整作業のほうが効いてきている。電子設計は、正しい式を立てれば終わりではない。部品表に載るものを選ばないと製品にならないし、温度や電圧の角で落ちる設計は現場で使えない。
だから、AIが設計できるかどうかの分水嶺は、派手なデモよりも、こうしたトレードオフを毎回きちんと解けるかにあると思う。この記事の書き手たちが面白がっているのもそこだろう。回路の世界では、うまく見える案より、あとで壊れない案のほうが価値がある。AIがその領域に入ってきたなら、評価も「それっぽさ」では足りない。シミュレーションで落とし、部品条件で落とし、最終的に現実の制約で残るものだけを採る。EEBenchは、その面倒な世界にAIを連れていくための道具に見える。
一方で、現時点の言い方はかなり慎重だ。設計できるのは「有用で、増えつつある」回路問題に限られ、いまのところ人間はペースメーカーを任せない。そこを踏まえると、AIが電子設計を置き換えるというより、設計の下書きや検証をかなり速くする方向が先に来るのではないか。実務では、そのほうがずっと効くはずだ。
