AIが設計した回路は動くのか｜EEBenchが69.3%を測った方法

はじめに

先日、GPT-6 Astra の発表ページに KiCad で基板を配線するデモが載った ことを取り上げました。回路図を受け取って、部品を置いて、銅箔を引く。電子工作をやっている側から見て、いちばん「自分の画面」に近いデモでした。

ただ、あの記事の時点で答えが出ていない問いがひとつ残っていました。引けた基板は、回路として成立しているのか。配線が繋がっていることと、電源が落ちても20ms持ちこたえることは、まったく別の話です。

2026年9月4日、EDA ツールを開発している atopile が、この問いに正面から答える枠組みを公開しました。EEBench V1 ——AI エージェントに回路を設計させ、その設計を SPICE シミュレーションにかけて、電圧や時間といった物理量で採点するベンチマークです。翌9月5日には Hackaday も取り上げています。

面白いのは、EEBench 側のブログもまた、GPT-6 Astra の KiCad デモを出発点に書かれていることです。冒頭でこう述べています。

We got pretty excited yesterday when OpenAI put a demo of GPT-6 Astra working on a circuit board in KiCad on the front page of its launch post.

（OpenAI が GPT-6 Astra の KiCad 作業デモを発表ページのトップに置いたのを見て、私たちはかなり興奮した）

同じデモを見て、片方は「見せた」、もう片方は「では測ろう」と動いた。この記事では、その測り方の中身を一次情報から追いかけます。

この記事で扱うのは次の内容です。

1. EEBench とは何か — 何を測り、なぜその範囲を選んだのか
2. atopile とは何か — 回路をコードで書くとはどういうことか
3. 採点の設計 — 散文で答えさせないという判断の意味
4. お題の実物 — 「20ms 生き延びろ」という課題と、そこで落ちた設計
5. リーダーボードの現況（2026年9月8日時点）
6. コスト効率が35%を占める意味
7. 69.3% をどう読むか — 幅・足場・再現性

1. 🧭 EEBench とは何か

何を測るベンチマークなのか

EEBench は atopile が構築・運営している「電気設計エージェント向けベンチマーク」です。公式メソドロジーは目的をこう書いています。

The goal is agents doing economically useful hardware engineering.

（目標は、エージェントが経済的に有用なハードウェア設計を行うことである）

ここでいう「有用な設計」の中身を、EEBench は、エンジニアの時間がどこに使われているかから逆算して決めています。メソドロジーのページには、設計サイクルの各段階と、そこに費やされる時間の割合が並んでいます。

（出典: EEBench メソドロジーページ。「V1 の対象」欄は、筆者が本文の記述にもとづいて付けたもの）

●を付けた6段階を足すと60%になります。EEBench 自身も「requirements → design → test — 60% of an engineer’s week」と書いており、V1 が測るのはこのループです。

そして注目すべきは、回路図とレイアウトが20%あるのに V1 の対象外だという点です。メソドロジーの言い分はこうです。

schematic + layout stay thin: the CAD writes down what simulation, calculation, and research already decided.

（回路図とレイアウトは薄いままにしてある。CAD は、シミュレーション・計算・調査がすでに決めたことを書き留めているにすぎない）

つまり EEBench は、最初から「配線を引く速さの話ではない」と宣言しています。GPT-6 Astra のデモが見せたのは20%の側で、EEBench が測っているのは残りの60%の側。同じ「AI が基板を設計する」という言葉が、指している場所が違う。ここが今回いちばん重要な線引きです。

「ハーネス」とは何か

課題は公開されていない

EEBench の課題は非公開です。メソドロジーには次のように書かれています。

• 課題はすべてオリジナルで、2026年に作成され、一度も公開されていない
• 課題・模範解答・隠れた許容値のいずれも、モデルが学習できた場所には存在しない
• 公開用のサンプルセットは今後出すかもしれない

学習データに混ざっていない問題でしか、能力は測れない。この判断自体はまっとうです。ただし裏返すと、外部の人間が同じ問題を解いて確かめることはできないということでもあります（この点は §7 で改めて扱います）。

2. 🧩 atopile とは — 回路をコードで書く

EEBench を理解するには、その土台になっている atopile を先に押さえる必要があります。

回路図を「描く」のではなく「書く」

atopile は、電子回路をコードで記述するための言語とコンパイラです。GitHub のリポジトリ説明はそのまま「Design circuit boards with code!」。実装は Python、ライセンスは MIT です。

従来の EDA では、回路図エディタで部品シンボルを置いて線を引きます。atopile では .ato というファイルに、部品・接続・電気的な制約を宣言的に書きます。EEBench の公開課題で使われているスターターコード（ato v2 記法）は、たとえばこうです。

.Submission: @type {
    .vin:   ELEC::ElectricPower
    .vhold: ELEC::ElectricPower
    .vhold.lv ~ .vin.lv

    .c_bank: ELEC::Capacitor {
        .capacitance             &= 22uF +/- 20%
        .max_voltage             &= 10V..25V
        .temperature_coefficient &= "X5R"
        .package                 &= "0805"
    }

    .vhold.hv ~> .c_bank ~> .vhold.lv
}

読み方はだいたい想像がつくはずです。vin と vhold という電源インターフェースがあり、c_bank というコンデンサがあり、~> で繋がっている。そして容量は「22µF ±20%」、耐圧は「10V 以上 25V 以下」、温度特性は X5R、パッケージは 0805。

KiCad との関係

atopile は KiCad を置き換えるものではありません。回路の中身をコードで決めて、レイアウトは KiCad でやるという分担です。ビルドすると .kicad_pcb が更新され、そこから先は pcbnew で基板を仕上げます。当サイトで KiCad 10.0 の新機能 を扱ったときに触れた「機械が扱いやすい構造が増えてきた」流れの、いちばん先端側にいるツールだと言えます。

EEBench が GUI ではなくコードを選んだ理由

EEBench のブログは、この選択の理由を明快に書いています。

You can have an agent operate a graphical CAD tool, but it spends a lot of time clicking around and keeping track of what is on screen. A lot of its context consists of coordinates, menus and application state.

（エージェントに GUI の CAD を操作させることはできるが、クリックして回り、画面上の状態を追いかけるのに多くの時間を使う。コンテキストの大部分が座標・メニュー・アプリケーションの状態で占められる）

そのうえで、コードなら「設計を変え、ビルドし、シミュレーションを走らせ、何が落ちたかを確認するまでをプロジェクトから出ずにできる」と述べ、結論をこう置いています。

It also means the benchmark can spend less time testing computer use and more time testing electronics.

（そしてこれは、ベンチマークがコンピュータ操作の能力を測る時間を減らし、電子工学の能力を測る時間を増やせるということでもある）

画面操作の巧拙を電気設計の能力と混ぜない。ベンチマークの設計としては、ここがいちばん筋の通った判断だと思います。

自分で触ってみるには

atopile 自体は誰でも使えます。公式が案内している入口は2つです。

• ブラウザ環境: app.atopile.io 。公式ドキュメントは現在この環境を主に案内しており、インストール不要でクイックスタートと実例の基板を開けます。ただし ato v2 は “under heavy development”（公式ドキュメントの記述）とされる段階です
• エディタ拡張: VS Code / Cursor の拡張機能（Marketplace で atopile.atopile）。README によれば、ツールチェーンの導入もこの拡張が面倒を見ます

EEBench のブログも「Give the agent a board you have been meaning to build and see how far it gets.（作ろうと思っていた基板をエージェントに渡して、どこまで行けるか見てほしい）」と締めています。なお筆者はまだ atopile を実際には使っていません。試したら別記事で報告します。

3. 🔬 散文で答えさせない — 採点の設計

提出物は「設計バンドル」

EEBench の採点で最初に押さえるべきは、AI が提出するのが文章ではないことです。メソドロジーの表現を借りれば「Agents submit atopile design bundles, not prose.（エージェントが提出するのは atopile の設計バンドルであって、散文ではない）」。

提出されたソースから、ハーネスが回路グラフ・インターフェース・BOM・シミュレーションデッキを組み立てます。そして各要求が、測定値と上下限を持つチェックに変換されます。

人間も LLM も採点しない

メソドロジーの一文が、この設計思想を要約しています。

Questions are deterministically verifiable with build checks, simulation measurements, and BOM constraints. No human graders. No LLM-as-judge.

（設問はビルドチェック・シミュレーション測定・BOM 制約によって決定的に検証できる。人間の採点者はいない。LLM を審査員にもしない）

LLM-as-judge を使わないというのは、この種のベンチマークでは強い主張です。「もっともらしい説明を書ける能力」に点が入る余地を、構造的に消しているからです。回路図が妥当に見えるかどうかは誰の意見でもなく、指定された電圧を保てたかどうかだけが問われます。

ブログはこれを、ソフトウェア側の言葉に翻訳しています。

This is similar to giving a coding agent a compiler and tests, except the tests are measuring voltages and component behavior.

（これはコーディングエージェントにコンパイラとテストを与えるのに似ている。ただしテストが測っているのは電圧と部品の振る舞いだ）

既存の LLM ベンチマークとの違い

一般的なベンチマークと並べると、設計の違いがはっきりします。

テキストで説明させるベンチマークで高得点を取るモデルが、ここで同じように取れるとは限りません。電圧は説得されないからです。

4. ⚡ お題の実物 — 「20ms 生き延びろ」

抽象的な話が続いたので、実際の課題を見ます。EEBench が公開しているサンプル課題（易しい階層）は、住宅用の電力量計です。

仕様

• 5V の補助電源が落ちたあと、20ms のあいだプロセッサを生かして、積算した kWh の値を保存しきる必要がある
• 保護されたレール（vhold）は、その間ずっとプロセッサのブラウンアウト閾値 3.0V を上回っていなければならない
• ショットキーによる OR 経路、93Ω の負荷、2Ω の充電時ソース抵抗は固定。設計するのは MLCC のリザーババンクだけ
• ハーネスは入力を 0V に落とし、また 5V に戻す。その間の電圧・動作点での実効容量・復帰の様子・パッケージや耐圧やコストの制約を、すべて測る

要求としては素直です。EEBench 自身も「Most models intuitively jump to the right base conclusion: add a capacitor.（ほとんどのモデルは直感的に正しい結論に飛びつく——コンデンサを足せ、と）」と書いています。

「22µF」が 11.4µF になる

問題はここからです。ブログが挙げている実際の失敗例が、電子工作をやっている人ほど刺さる内容になっています。

A submitted design used 22 µF nominally. At 4.7 V bias, the grader found only 11.4 µF of effective capacitance, far below the 545 µF requirement.

（提出された設計は公称22µF を使っていた。4.7V のバイアス下で、採点器が見つけた実効容量はわずか11.4µF であり、要求される545µF をはるかに下回っていた）

そして保存されている ngspice の出力によれば、保護レールは約4.55V から始まり、0.85ms で 3V を割りました。要求は20ms です。

545µF という要求を検算してみる

「545µF」という数字は、住宅用電力量計のバックアップとしては大きく感じるかもしれません。妥当かどうか、公開されている条件だけで概算してみます。

93Ω の負荷を抵抗放電とみなすと、初期電圧 V_0 から V_1 まで落ちるのにかかる時間から、必要な容量はこう書けます。

およそ 516µF。EEBench が要求している545µF と、ほぼ一致します（この概算はショットキーの順方向降下や充電時のソース抵抗、負荷の非線形性を無視しているので、実際の要求値のほうが少し大きくなるのは筋が通ります）。

つまりこの課題は、理屈の上でも本当に数百µF が要る設計です。そして数百µF を MLCC だけで、0805 のパッケージ制約とコスト制約のもとで積むのは、素直な作業ではありません。「コンデンサを足せ」という正しい直感から、実際に通る BOM までの距離が、この課題の本体です。

難しい階層では何を測るのか

サンプルとして公開されているのは易しい階層で、上の階層はもっと厳しくなります。ブログの記述を要約すると、たとえばアナログの難問ではこうなります。

• オペアンプ周りに多重帰還（MFB）ローパスフィルタを合成させる
• 必要な極（pole）を得るための抵抗・コンデンサの比を解かせる
• ゲイン・カットオフ周波数・Q を、すべての部品を最悪の公差コーナーに振ったあとでも規定内に収めさせる
• ハーネスはそのコーナーごとに SPICE デッキを組み直し、AC 解析と過渡解析を実行し、測定を名前付きプローブに束ね、各結果を下限・上限と突き合わせて記録する

さらに、使えるのは実在するメーカー部品で、仕様はデータシートから抽出されて SPICE モデルに反映されています。公差のコーナーで動くことに加えて、存在し、発注でき、その製品として妥当な価格である部品を選ばなければならない。

ブログはこの点を、こう位置づけています。

This is the part we find most interesting, because it is what electrical engineering eventually boils down to, just like every other engineering discipline: trade-offs.

（ここが私たちのいちばん面白いと思う部分だ。電気工学が最終的に行き着くのは、他のあらゆる工学分野と同じく、トレードオフだからだ）

5. 📊 リーダーボードの現況（2026年9月8日時点）

以下は、筆者が 2026年9月8日にリーダーボードを取得した時点の値です。データファイル側の生成日は 2026年9月4日、対象は 13問・31モデル。順位も数値も今後変わります。

（出典: EEBench リーダーボード。数値はすべて EEBench の発表値。9位・11位以下は一部を抜粋）

割れ方が違う

平均点だけ見ていると気づけないものが、設問ごとの得点に出ています。EEBench はリーダーボードのデータに各モデルの13問分の得点を持っており、上位2モデルの分布はまるで違います。

Astra は「完璧に通すか、まったく通らないか」に割れ、Opus 5 は全問でそこそこ取る。 平均点は Astra が上ですが、性格がまるで違います。標準誤差の差（±10.7 と ±6.0）も、この分布の違いをそのまま反映しています。

設計を任せる相手として、どちらが安心かは用途によります。落ちたことがすぐ分かる仕組みがあるなら前者、平均的な底上げを期待するなら後者、という読み方ができます。

速さと安さの中身

Astra の「安くて速い」は、内訳を見るとかなり極端です。

出力トークンで8分の1、時間で7分の1です。ただしリーダーボードのデータファイルを見ると、Astra と Grok 4.6 のコストには「概算」のフラグが立っています。メソドロジーにも「部分的な課金データにもとづくコスト平均には概算の印を付ける」とあり、この2行の金額は他行と同じ精度では比較できません。

ブログ本文とリーダーボードで数字が違う

ここは混乱しやすいので整理しておきます。9月4日付のブログ本文には、次のように書かれています。

The September 1 results are encouraging. Claude Opus 5 scored 61.6% across the 13 tasks in EEBench V1.

（9月1日の結果は励みになる。Claude Opus 5 は EEBench V1 の13課題で61.6%を記録した）

そしてブログは、GPT-6 Astra について「We do not have a GPT-6 Astra result yet.（Astra の結果はまだ無い）」と明記しています。つまりブログ本文が語っているのは Astra 抜きの順位で、首位は Opus 5 です。

一方、リーダーボードのデータは9月4日生成で、Astra が69.3%で首位として載っており、9月5日の Hackaday の記事も同じ69.3%（±10%）を引用しています。

どちらも正しく、時点が違うだけです。ブログ本文は9月1日時点の結果を説明した文章、リーダーボードは Astra を追加したあとの現況。記事を読むときは、その数字がいつ生成されたものかを見る必要があります。本記事が「2026年9月8日時点」と何度も書いているのは、そのためです。

6. 💰 コスト効率が35%を占める意味

EEBench のスコアは、次の配分で計算されます。

コスト効率は、提出された BOM を参照設計の BOM と比べて評価されます。価格は数量100の流通価格。そしてメソドロジーに、重要な但し書きがあります。

cost credit requires a working design.

（コストの加点には、動く設計であることが必要）

動かない設計をどれだけ安く作っても0点。まず通してから、安くという順序が、構造に埋め込まれています。

この35%という配分は、ベンチマークとしてかなり踏み込んだ判断です。というのも、電気設計は部品を盛れば大抵動くからです。耐圧に余裕を取り、容量を増やし、精度の高い抵抗を使い、マージンを積み上げれば、シミュレーションは通ります。通るけれど、その基板は製品になりません。

先ほどの電力量計の課題がまさにそれで、545µF を確保する方法は無数にあります。0805 の X5R を並べる、パッケージを上げる、耐圧の高い品種にする、種類を混ぜる。どれも「動く」けれど、面積と単価が違う。その差を採点対象にしているわけです。

実務で設計をやっている人ほど、この配分には頷けるはずです。動く回路を出すのが仕事なのではなく、決められた予算と面積の中で動く回路を出すのが仕事なので。

7. 🧪 69.3% をどう読むか

さて、本題です。69.3% は高いのか、低いのか。

まず「幅」を見る

69.3% には ±10.7 の標準誤差が付いています。13問に対して試行は39回、1問あたり3回です。

3回の試行で ±10.7 という幅は、順位が入れ替わり得る幅です。Astra（69.3 ±10.7）と Opus 5（61.6 ±6.0）の差は7.7ポイントで、Astra 側の誤差幅の中に収まっています。Hackaday が「Claude Opus 5 と同等の性能」と書いているのは妥当な読み方で、EEBench 自身も各行に試行数と標準誤差を出して、この読み方ができるようにしています。

首位のモデル名より、この誤差の出し方のほうが、ベンチマークとしての誠実さを示しています。

「足場（スキャフォールド）」の差は無視できない

メソドロジーには、注意して読むべき記述があります。

Scaffold fit is not a rounding error: in a controlled 2×2 (GPT-5.5 and GPT-5.6, each run through both the Codex CLI and our neutral API tool loop, same questions), the harness choice moved GPT-5.5 by more than the entire 5.5→5.6 model delta, while GPT-5.6 scored the same in both.

（足場の相性は誤差の丸めではない。統制された 2×2 の実験——GPT-5.5 と GPT-5.6 を、Codex CLI と中立な API ツールループの両方で、同じ設問に対して走らせた——では、ハーネスの選択が GPT-5.5 を、5.5→5.6 のモデル間の差分すべてよりも大きく動かした。一方 GPT-5.6 はどちらでも同じスコアだった）

どのエージェント環境で動かすかが、モデルの世代差より大きくスコアを動かしたという報告です。EEBench はこれを受けて「All OpenAI rows on this board therefore use the neutral API tool loop.（したがってこのボードの OpenAI 行はすべて中立な API ツールループを使う）」と書いています。

ここで一点、読者が自分で確認できる食い違いがあります。リーダーボードの各行にはモデル名の下に足場の名前が表示されており、GPT-6 Astra の行は “OpenAI · Codex CLI” になっています。 上の記述と照らすと、首位の行だけ、メソドロジーの説明と違う足場で走っていることになります。

これが単なるページの更新漏れなのか、Astra だけ別扱いにした理由があるのかは、筆者が確認した範囲では公開情報から分かりませんでした。どちらにせよ、69.3% は「Codex CLI という足場で動かした GPT-6 Astra のスコア」として読むのが正確です。他行と足場が揃っていない可能性がある、という前提で見るべき数字だと考えます。

第三者による再現は確認できていない

EEBench の位置づけとして、はっきりさせておくべき点が2つあります。

1. EEBench は atopile が構築・運営し、費用も負担している。 メソドロジーに明記されており、「設計ツールは売るが、ベンチマークへのアクセスやスコアは売らない」とも書かれています。運営の透明性は保たれていますが、利害関係のある当事者が作ったベンチマークであることは事実です
2. 課題は非公開なので、外部の人間が同じ問題で再現することはできない

では第三者の検証は皆無かというと、そうではありません。xAI が Grok 4.6 のモデルカードに EEBench を採用しています（第4章「Engineering acceleration」の4.1）。3D モデリングやパラメトリック CAD のベンチマークと並ぶ扱いです。

ただし、ここも読み方に注意が必要です。モデルカードの当該ページには、次の脚注が付いています。

† Results are taken from evaluations conducted by Atopile.

（† 結果は Atopile が実施した評価から取っている）

つまりこれは、フロンティアラボが EEBench を「引用するに足るベンチマーク」と認めたという事実であって、独立に再現した結果ではありません。数字を出したのは atopile です。

なお、モデルカードに載っている Grok 4.6 のスコアは xhigh 設定で60.0%、high 設定で53.0% で、公開リーダーボードの行（57.1%）とは異なります。同じベンチマークでも、推論努力の設定が違えば数字が違う。ここも一つの数字では語れないところです。

現時点で、EEBench の結果を、利害関係のない第三者が独立に再現した報告を、筆者は確認できていません。 これは EEBench の欠陥というより、非公開課題を使うベンチマーク全般が抱える構造です。

V1 の射程外にあるもの

最後に、69.3% が何を意味していないかをはっきりさせておきます。EEBench 自身の言葉です。

EEBench V1 covers analog and digital design through simulation. It does not yet tell us whether a model can lay out, manufacture and bring up a complete product.

（EEBench V1 が扱うのは、シミュレーションを通じたアナログ・デジタル設計である。モデルが完全な製品をレイアウトし、製造し、立ち上げられるかどうかまでは、まだ分からない）

つまり V1 の外にあるのは、レイアウト・製造・実機の立ち上げです。基板を起こしたことがある人なら、そこにどれだけの落とし穴があるか知っているはずです。

• シミュレーションで通った回路が、実装後にノイズを拾って動かない
• 部品が入手できない、あるいはリードタイムが数か月ある
• 手はんだできない部品を選んでいた
• パスコンの位置が悪い、GND の戻りが遠回りしている
• 発注してから、シルクの向きが逆だと気づく

「69.3%だから7割は量産に出せる」ではありません。 測っているのは要件→設計→テストのループであって、量産の合否ではない。量産という基準に照らせば、そもそも V1 はまだその手前の段階を測っている、というのが正確な位置づけです。

そのうえで、EEBench は次の段階を明言しています。V2 以降ではレイアウトを対象に含め、基板を実際に製造し、エージェントに立ち上げと試験を実機で行わせる計画。同じループのまま「物理の現実度」を上げていく、という方針です。

そして、シミュレーションで採点できるということは、そのまま強化学習の報酬信号にできるということでもあります。ブログはこの点にも触れており、どの電圧が限界を外したか、どの動作コーナーで落ちたか、不必要に高価な設計で解いていないか——といった情報を学習ループに渡せる、と書いています。「回路図がもっともらしく見える」という判定より、はるかに多くの情報を持った信号です。

まとめ

• EEBench V1 は atopile が構築・運営する電気設計エージェント向けベンチマーク。9月4日にブログ記事が公開され、翌5日には Hackaday も取り上げました
• 提出物は散文ではなく atopile の設計バンドル。ハーネスがビルドして回路グラフ・BOM・SPICE デッキを生成し、ゲイン・過渡応答・しきい値・リップル・マージン・隠れた動作点を、最悪の公差コーナーで実測します
• 採点は決定的で、人間の採点者も LLM-as-judge も使いません。失敗は意見ではなく、測定された波形として残ります
• スコアは 0.65 × 技術 + 0.35 × コスト効率（参照 BOM 比・数量100の流通価格）。コストの加点は、動く設計にだけ付きます。なおこの35%は基板の部品代であって、AI の利用料金ではありません
• 公開されているサンプル課題は、5V が落ちてから 20ms のあいだ 3.0V を割らないリザーババンクの設計。公称22µF が動作点で11.4µF しかなく、0.85ms で落ちた設計が実例として挙げられています
• 2026年9月8日時点（データ生成は9月4日）のリーダーボード（13問・31モデル）は、首位が GPT-6 Astra の69.3%（±10.7）、2位が Claude Opus 5 の61.6%（±6.0）。誤差幅を踏まえれば、両者はほぼ同等です。すべて EEBench の発表値です
• ただし ①課題は非公開 ②運営は利害関係のある atopile ③独立した第三者による再現報告は確認できていない ④首位の行だけ足場（Codex CLI）がメソドロジーの記述と異なる、という留保が付きます
• V1 の対象外はレイアウト・製造・実機の立ち上げ。V2 以降で実際に基板を作り、エージェントに立ち上げまでやらせる計画が明言されています

「AI は基板を設計できるか」という問いには、これまで答え合わせの方法がありませんでした。デモ動画を見て、すごいと思うか思わないかしかなかった。EEBench が持ち込んだのは、その問いを電圧と時間で答えられる形に翻訳する枠組みです。数字が69.3%であることより、69.3%という数字を出せる装置ができたことのほうが、この分野にとっては大きい。次に誰かが「AI が基板を設計した」と言ったとき、どの部屋の話なのかを聞き返せるようになった——それが今回いちばんの収穫だと思います。

よくある質問（FAQ）

Q. EEBench は中立なベンチマークですか？

運営・費用負担ともに atopile（電子設計ツールを販売する企業）です。この点はメソドロジーに明記されており、「設計ツールは売るが、ベンチマークへのアクセスやスコアは売らない」とも書かれています。運営方針は透明ですが、利害関係のない第三者による評価ではありません。数字を引用するときは「EEBench 発表値」として扱うのが適切です。

Q. 69.3% は「10問中7問できる」という意味ですか？

違います。各設問が満点か0点かではなく、要求ごとの合否から部分点が出る方式で、さらにコスト効率が35%混ざった総合値です。実際 GPT-6 Astra の13問の内訳は、満点が7問、0点が1問、残りが 16.1〜75% に散らばっています。

Q. コスト効率35%は、AI の利用料金のことですか？

違います。AI が設計した基板の部品代（BOM）を、参照設計の BOM と比べたものです。価格は数量100の流通価格。リーダーボードにある「Cost / task」（モデルの API 料金）は、スコアには含まれません。

Q. atopile を使っていないと EEBench は受けられませんか？

EEBench の提出形式は atopile の設計バンドルなので、この枠組みの中では atopile を使うことになります。ただしモデル側に特別な準備は不要で、EEBench はすべてのモデルに同じ課題文・スターターコード・作業環境・ツール・予算を配ると説明しています。現時点で自己申請による提出窓口は無く、評価を受けたい場合は atopile に連絡する形です（公開のセルフサービスは今後予定とされています）。

Q. 自分でも atopile を試せますか？

試せます。ブラウザ環境（app.atopile.io）はインストール不要で、クイックスタートと実例を開けます。VS Code / Cursor の拡張機能（atopile.atopile）を入れる方法もあり、GitHub のリポジトリは MIT ライセンスです。ただし ato v2 は公式ドキュメント上「under heavy development」の段階と書かれているので、そのつもりで触るのがよさそうです。

Q. これで基板設計の仕事は無くなりますか？

少なくとも EEBench が測った範囲からは、そう読める根拠は出ていません。V1 の対象はシミュレーション上の要件→設計→テストのループで、レイアウト・製造・実機の立ち上げは対象外です。EEBench 自身も「モデルが完全な製品をレイアウトし、製造し、立ち上げられるかどうかまでは、まだ分からない」と書いています。むしろ、検証を機械に任せて設計の手戻りを早く見つけるという使い方のほうが、いま現実的な効き所だと思います。

Q. この順位は今後変わりますか？

変わります。本記事の数値は2026年9月8日時点で取得したもの（データの生成日は9月4日）です。EEBench は「モデルが良くなるにつれて、より難しい課題を追加していく」と述べており、モデル側も更新されます。最新の値は必ずリーダーボード本体で確認してください。

関連記事

• GPT-6 Astra 公開｜KiCadで基板を配線、サイバーは初の Critical：EEBench のブログが出発点にした、あの KiCad デモの詳細
• Claude Fable 5.1 公開｜キャッシュ読み取り75%減と5→5.1の差分：リーダーボード4位に入っているモデルの中身
• KiCad 10.0 新機能まとめ｜Allegroインポーター・バリアント設計・DRCエディタ：atopile が出力先にしている EDA ツールの現在地
• KiCadで作るESP32-S3センサー基板｜設計から手はんだ実装まで：所感で触れた、実際に基板を起こしたときの記録

参考

• Can AI design circuit boards yet?（EEBench 公式ブログ・2026年9月4日）
• Methodology — EEBench（採点方法・スコア配分・サンプル課題・運営体制）
• EEBench leaderboard（リーダーボード本体）
• atopile/atopile（GitHub・MIT ライセンス）
• atopile Documentation（公式ドキュメント）
• Grok 4.6 Model Card（xAI・4.1 EEBench の節）
• GPT-6 Astra: A new generation of intelligence（OpenAI 公式）
• Can AI Now Design PCBs That Just Work?（Hackaday・2026年9月5日）