ハードウェア設計にAIを持ち込む話は珍しくありませんが、copperheadはその中でもかなり割り切った作り方をしています。単に「回路図をそれっぽく描く」のでなく、KiCadの実ファイルを直接編集し、仕様書やBOM、検証結果までそろえることを前提にしたツールとして出てきました。しかも、途中で検証に落ちればそこで止まる設計です。ソフトウェアの開発フローに近い感覚を、基板設計へ持ち込もうとしているのが面白いところです。
元記事がまず示しているのは、copperheadが「Cursor for circuit boards.」を掲げるオープンソースのAI engineering platformだという点です。対象はプリント基板、つまりPCBで、ハードウェアチームが回路図、設計文書、検証、出荷物の作成まで進められるようにする、と説明されています。単なるチャットボットではなく、KiCadのファイルを直接扱うCLIとして動くのが特徴です。インストール例としては npm i -g copperhead が示され、利用にはNode 20以上、KiCadと kicad-cli、自分のモデルAPIキーが必要だと書かれています。
デモでは、add a USB-C power input to the key という指示から作業が始まります。copperheadはまず docs/POWER.md を読み、ネット一覧を確認し、VBUSやCC1/CC2がないことを見つけます。そのうえで変更案を検証し、USB-C receptacle と 2本の 5.1k CC pulldown を回路図に追加し、docs/POWER.md にもVBUS budgetと「5 V at 1.5 A」を追記します。さらにERCを走らせて違反ゼロを確認し、文書と回路図の差分がないかをチェックして、DECISIONS.md と CHANGELOG.md に記録を残します。画面上では、各段階の実行時間、トークン数、turn数まで表示され、最終的には17秒でverified erc、コミットID 3f2c9a1 まで出ています。
この仕組みは「Eight stages, start to finish」として整理されています。brief.md に書いた要望を起点に、spec、architecture、parts、schematic、layout、outputs、firmware、dev planの順に進み、各段階は独立したagent runです。しかも次の段階に進む前に、前の段階の成果物がディスク上に存在していなければならず、gateに失敗したらそこで止まります。例えばspecでは予算欄を埋め、architectureでは各サブシステムに実際の reasoning を書き、partsではデータシートに基づいた部品番号を選び、schematicではERC clean、layoutではDRC clean、outputsではgerberやSTEPを出し、firmwareではソースコードとpin割り当てを用意し、最後にbring-upとtest planまで書かせる、という流れです。
さらにcopperheadは、既存設計への追記にも主眼を置いています。FAQでは「主なユースケースは、すでに存在するKiCadリポジトリに対して変更を加えること」だと明言しています。dirtyなgit treeでは動かず、validatedな変更提案がない限り設計ファイルを触らず、文書化済みのbudgetやconstraintを破る変更は拒否する、と説明されています。部品番号も、データシートで裏づけられないものは勝手に作らない。しかも回路図は全体を再生成するのではなく、KiCadのs-expressionソースを外科的に編集するので、差分が小さく、レビューしやすいとしています。ここまで徹底しているので、「AIがそれっぽいものを作る」より、「壊れにくい変更を通す」ことに重心がある製品だと読めます。
正直なところ、copperheadの価値は派手な自動生成にあるというより、設計変更の面倒を一気通貫で閉じ込めるところにあると思います。基板設計では、回路図だけ合っていてもだめで、BOM、電源予算、文書、さらにはBring-upの手順までずれていない必要があります。そこで起きる事故は、しばしば「誰かが間違えた」というより「どこか1枚だけ直して、残りが追従しなかった」というものです。copperheadはそこをDriftと呼び、まさにそのズレを潰す道具として売っています。これはかなり実務的です。
興味深いのは、AIの自由度を増やす方向ではなく、むしろ縛っていることです。validated change proposalが先にあり、gateを越えない限り次へ進まない。ERCやDRC、文書との一致、予算や制約の整合が全部前提になる。これだと「何でもやってくれる魔法の設計AI」には見えませんが、逆に現場ではそのほうが使いやすいはずです。ハードウェアはやり直しが高い。元記事でも、リスピンは5000〜50000ドル、6〜8週間かかるとしています。ここで重要なのは、AIが設計を肩代わりすることより、手戻りの原因を先回りして潰すことだと思います。
デモの17秒という数字は目を引きますが、本当に見たいのは速度そのものではありません。むしろ、USB-C電源入力を足したという一見ありふれた変更に対して、回路図、文書、検証、決定ログ、CHANGELOGが同時に動いている点です。人手でやると、こうした更新は地味で時間がかかるうえに、どこか1箇所を忘れがちです。しかも忘れたことは、しばらく出荷に近づくまで見えません。copperheadはそこに「全部やったか」を機械的に残す。これはGitと相性がいいし、レビュー文化とも噛み合います。
ただし、ここには限界もあります。設計の自由な発想や、まだ要件が固まっていない段階の試行錯誤は、こうしたガードが強いツールだと少し窮屈かもしれません。brief.md に短く要件を書くところから始める設計なので、要求が曖昧な研究用途より、既に仕様がある量産寄りの現場に向いている印象です。つまり、発明の瞬間を代替するというより、「決まったものを壊さずに形にする」用途です。ここは期待を間違えると痛い。
料金表も象徴的です。CLIはApache-2.0で無料、ずっと無料だと書きつつ、Cloud、Team、Enterpriseが別料金で並んでいます。個人や小さなチームならローカルで回せる。一方で、共有のレポート、Web viewer、CI bot、SSO/SAML、監査証跡、VPC、自社ネットワーク内での運用などは有料側に寄せている。これは単なるマネタイズではなく、基板設計の実務が「個人の試作」と「組織の統制された開発」に分かれていることをよく分かっている設計です。
この二層構造は、copperheadが“AI CAD”で終わらず、開発基盤として売ろうとしている証拠でもあります。とくにEnterpriseの「監査チームに渡せる audit trail」や「設計データがネットワーク外に出ない」という表現は、ハードウェア業界で本当に刺さるはずです。部品調達、知財、委託先管理、量産前のレビュー。こうした事情がある会社ほど、単なる生成ツールではなく、履歴と責任分界まで残る仕組みを欲しがるからです。AIの面白さより、コンプライアンスと再現性のほうが購買理由になる。そこを真正面から見ているのが、このサービスの現実感だと思います。
