AIに基板（プリント基板、PCB）を設計してもらう、という実験を最初から最後まで見る機会があった。題材は、Raspberry Pi Pico W に載せる小さな I/O シールド。温湿度や明るさを I2C で読み、DCモータとサーボを動かし、外部電源を受ける ── いわば「AIエージェントに、現実世界を読んで少しだけ手を出す身体を与える」ための拡張ボードだ。

結論を先に書くと、効いたのは AI が賢く回路を引いたことではなかった。仕事を、ファイル・表・スクリプト・DRC・レビュー用の絵に落として、同じ手順を何度でも回せる形にしたこと。 そして、AI が勢いよく進みすぎないように、「止まる場所」を先に決めたこと。今日はその運用を、実際に残ったファイルをレビューしながら整理しておく。基板設計そのものの正解集ではなく、AI・CAD・CLI・ドキュメント・レビューをどう組み合わせるか、という話だ。あわせて、同じことを自分の手元で再現するための設定と、そもそも いまのAIツールに何が頼めるのか も書いておく。「AIにやらせてみた」で終わらせないために。

何を作ろうとしていたか

最初に、対象を一枚で掴んでおく。

• 載せる先: Raspberry Pi Pico W（シールド型）
• 入力: I2C 温湿度センサ（AHT20 / SHT30 系）、照度センサ（BH1750）、外部 I2C 拡張（Qwiic / STEMMA QT の JST-SH 4ピン）
• 出力: DCモータドライバ DRV8833、3ピンのサーボ端子 ×2
• 電源: Pico の USB/VBUS、それとは別の外部 5V / VMOT 入力端子台

「複雑な高電圧・大電流・高速信号は初回では避ける。3.3V ロジックと I2C と PWM を中心にする」と最初に線を引いているのが、地味だけれど大事なところだ。欲張らない初回スコープは、AI に任せる範囲を素直にする。

いま、AIに何が頼めるのか

そもそも、こういう作業が成り立つようになったのは、ここ最近の変化だ。少し前まで、AIに何かを頼むというのは「チャットで質問して、文章で答えをもらう」ことだった。今回のような作業ができるのは、そこから一段変わって、AIがリポジトリの中で「作業者」として動けるようになったからだ。具体的には、いまのAIツールにはこういう機能がある。

• ファイルを読み書きし、シェルでコマンドを実行し、結果を見てまた直す ── このループを自分で回せる。いわゆるエージェント型のコーディングCLI（Codex や Claude Code のようなもの）がこれにあたる。一問一答ではなく、手を動かして試行錯誤できるのが大きい。
• 外部のツールを「道具」として呼べる（tool use / function calling）。さらに MCP（Model Context Protocol）という共通の差し込み口を使えば、CADやデータベースのような外部機能を後付けできる。
• 再利用できる指示の束を持てる（スキル、サブエージェント）。プロジェクト固有のルールや手順を一度書いておけば、毎回それを読ませて働かせられる。今回の「憲法」も、この仕組みに乗っている。
• コードを書き、構造化されたデータ（JSON）を読む。だから、基板を作り直す生成スクリプトを書かせたり、DRC が吐く JSON のエラーを分類させたり、が現実的になる。

基板設計にこれが効くのは、CAD の本質 ── ネット（どことどこがつながるか）、座標、デザインルール ── が、テキストとコマンドで触れる形になっているとき（KiCad がまさにそうだ）。AI の「ファイルとCLIを回す」力と、KiCad の「テキスト＋ kicad-cli 」が、きれいに噛み合う。

ただ、同じくらい大事なのは、**いまのAIに「できないこと」**だ。GUI の CAD を安定して操る、実部品の正しさを保証する、電流・発熱・安全をその場で工学的に判断する ── ここはまだ人間の領分だ。だから後で書く「憲法とゲート」が要る。何ができるかの話と、何ができないかの話は、いつもセットで持っておくといい。片方だけ見ると、必ず転ぶ。

一番効いたのは「再生成できる足場」

今回いちばん効いたのは、AI の出力を その場限りの答え にしなかったことだ。

ありがちな失敗は、CAD の GUI を AI にスクリーンショット越しに触らせて、賢く一発で仕上げてもらおうとすること。これは速く見えて、実はいちばん壊れやすい。配線を少し直すたびに状態が分からなくなり、何をどう変えたのかが残らない。

代わりにやったのは、設計の中身を テキストとコードに落とす ことだった。具体的には、KiCad 側に tools/generate_kicad_pico_shield.py という生成スクリプトを置いて、同じ基板をスクリプトから作り直せるようにした。部品位置を動かしても、配線を直しても、図面の角を45度に面取りしても、「生成 → DRC → SVG出力」を同じ流れで何度でも回せる。手で少しずつ直すより、失敗したときに戻して試し直すのがずっと楽だった。

これは、私がふだん可視化ツールやシミュレータでやっていることと、骨が同じだ。計算の核を純関数にして、検算できる形にしておく。UI の見た目より先に、再現できる芯を持つ。基板でも、結局そこが効いた。

AI に渡すべきは「細かい回路図」より「何をしたいか・何を怖がるか」

依頼書（docs/pattern-design-request.md）を読んで感心したのは、渡している情報が回路の詳細ではなく、目的と恐れ だったことだ。

最初に渡すと効くのは、こういう情報だった。

• 基板の目的（何のための板か）
• 使うマイコン・センサ・アクチュエータ
• 電源の種類（USB 由来か、外部か）
• 外部コネクタの種類と、どこから抜き差しするか
• 電流が大きそうな箇所、発熱しそうな箇所
• まだ変えてよいピン割り当て
• 絶対にやってほしくない操作
• いま欲しい成果物が、レビュー用か、製造用か

「Pico W・シールド型・安い温湿度・DRV8833・サーボ端子・外部5V端子台」── このくらいの粒度の指定で、部品配置と配線の優先順位が決まる。逆に言うと、ここを曖昧にしたまま CAD に部品を置き始めると、後の配線もレビューも一気にしんどくなる。怖い所を先に言葉にするほど、AI は素直に働く。

AI に任せやすい仕事と、任せると危ない仕事

ここははっきり分けておきたい。

任せやすいのは、曖昧な希望を構造に変える作業だ。設計依頼書、部品候補表、ネット表、制約表への分解。作業ログとレビュー項目を残すこと。そして、手順がコード化できる作業 ── KiCad の Python / CLI で基板を再生成し、DRC を回し、SVG を出す、といったところ。

任せると危ないのは、現実の部品と物理に触れる判断だ。

危ない領域	なぜ AI 任せにできないか
実部品のピン1・フットプリント寸法	データシートと現物の照合が要る。間違うと基板が死ぬ
コネクタの向き	挿し方向・極性は機構と相手ケーブル次第
LCSC/JLCPCB の在庫・価格・Basic/Extended	変動する。AI が「在庫あり」と言っても保証にならない
DRV8833 など電力部品の熱設計	露出パッド・放熱ビア・電流容量は現実の制約
モータ/サーボ電流に対する線幅	実電流が決まらないと引けない
外部5V と USB/VBUS の逆流対策	電源が二系統ある時点で、ここは人間の判断
Gerber・Drill・BOM・実装データ・発注	不可逆。出した時点で現実が動く

そして、この運用でいちばん大事な一文がこれだ ── DRC 0 は「発注してよい」ではない。DRC（デザインルールチェック）が 0 件でも、それは「CAD 上のルール違反がない」に近いだけで、「現実に動く」「安全」「発注してよい」ではない。実際、今回の検証ボードは DRC 0 を出しているが、フットプリントは暫定だ。つまり DRC が見ていない所（ピン1・実フットプリント・露出パッド）こそが、まだ本当のリスク という、少し皮肉な状態になっている。ここを正直に「未確認」と書き続けられるかが、運用の質を決める。

KiCad で検証し、EasyEDA で部品と発注へ寄せる

CAD を二つ使い分けていたのが、今回いちばん実務的な発見だった。

• EasyEDA は、LCSC / JLCPCB の部品ライブラリと発注導線が強い。最終的に「そのまま発注」へ近づきたいなら、捨てるべきではない。ただし、プロジェクトが内部の SQLite 形式に寄るため、差分レビューと自動再生成が難しい。GUI とスクリーンショットに依存した作業は、速い場面もあるが、配線の反復修正・座標確認・DRC 再実行・作業ログ化では壊れやすい。
• KiCad は、基板がテキスト形式で、Python API・CLI・DRC の JSON 出力・SVG レビュー出力が揃っている。AI が試行錯誤する検証環境として、こちらが圧倒的に向く。

結論はシンプルだ。KiCad で配線・配置・DRC・レビュー図を詰めて、EasyEDA は部品確定と発注導線のためにあとで戻る。 製造データの出力と外部発注は、そのどちらとも別のゲートにする。

余談だが、この「重いGUIアプリで長時間つつくと、作業が壊れやすい」という感触は、別の所でも刺さっていた。この基板を触っていた数日、母艦の PC が二度ほど固まったのだが、そのとき前面で動いていたのが、まさに Electron 製のその CAD だった。GUI の重さは、作業の再現性だけでなく、たまに机ごと巻き込む ── という、書くつもりのなかったオチがついた。

一番の発明は「AI 用の憲法」だった

技術的な工夫よりも効いたのは、リポジトリの一番上に置いた二枚のルール文書（AGENTS.md と、Skill の SKILL.md）だった。これはサブエージェントというより、AI 用のプロジェクト憲法 として働いた。

何が書いてあるかというと、AI の役割を「設計責任者」ではなく「下書きとレビュー支援」に固定し、そのうえで 承認ゲート を引いている。

次の段階では必ず停止し、人間の承認を待つ:
1. 部品選定の候補を「確定部品」として扱う前
2. 配置方針を作成した後
3. 配線方針を作成した後
4. DRC/ERC 結果を発注判断に使う前
5. Gerber・Drill・BOM・Pick and Place を出す前
6. 外部サービスへアップロード/発注する前

加えて、禁止事項（外部サービスへログインしない、CAD を勝手に編集しない、秘密鍵を読まない）と、人間レビュー必須領域（電源・GND・リターンパス、高電流・発熱・銅箔幅、絶縁距離、コネクタ向き・1番ピン、フットプリント、実装可否…）を、最初から並べてある。

そして地味に効くのが 言葉づかい だ。AI に書かせるレビューには、未確認・人間確認必須・EasyEDA GUIで確認・発注前レビュー必須 というラベルを使わせる。推測を「確定した工学判断」として書かせない。この一手で、AI が勢いよく出してくる提案を、安全に「下書き」のまま積める。

サブエージェントは、初期 PCB では使わなかった

私はふだん、作業を小さな手足（作り手・検証係・司書）に分けて並行で回すのが好きだ。だから興味深かったのが、今回は複数のサブエージェントを分担稼働させていない ことだった。

理由は腑に落ちる。初期の PCB 設計では、ピン割り当て・配置・配線・DRC・ドキュメント更新が 全部つながっている。ここを複数エージェントに割ると、認識のズレが増える。「どの判断で基板の形が変わったのか」を追えなくなるのが、いちばん怖い。だから CAD を実際に編集する主作業は、当面メイン一本でやる方がよい ── これは、私が widget を作るとき、手を分けずに自分で一本通して作るのと同じ感覚だ。

逆に、サブエージェントが効きそうなのは、独立して答えが出るレビュー作業 の方だ。データシート確認係、フットプリント/ピン1照合係、DRC/ERC ログ分類係、電源/熱レビュー係、コネクタ/機構レビュー係、EasyEDA↔KiCad 差分チェック係。編集は一本、レビューは分担 ── この線引きは、たぶん他の設計作業にも効く。

レビューしながら ── 実際の成果物を見て

せっかくなので、残っているファイルに、私のレビューの目も入れておく。

良いと思ったのは、レビュー用の回路図に「Open review gates（開いたままのレビュー関門）」が描き込まれている ことだ。ブロック図の脇に、「実シンボル化して ERC する」「Pico W のフットプリント・USB・アンテナ keepout を確認」「DRV8833 のピン1・露出パッド・放熱ビアの扱いを確認」「VBUS と外部5V の逆流保護を決める」「コネクタのピン順を製造前に確認」と、未解決の宿題が 図そのものに 載っている。未確認を別ファイルに隠さず、絵の中に置く。これは強い。

電源の扱いも、正直に開けてあった。回路図上で VBUS は外部5V（5V_EXT）と直結していない。外部5V は 0Ω のリンク（R5）越しに VMOT へ渡す形で、「USB と外部電源を同時に挿したときの逆流対策は未確定」と明示されている。二系統電源のいちばん危ない所を、決めつけずに「人間確認必須」で止めてある。

放熱も筋が通っている。DRV8833 の露出パッドを GND 面へ落とし、その下に GND 放熱ビアを4個。ただし「via-in-pad でハンダが吸われないか」「ビア径・数が製造先の標準に入るか」を発注前の宿題として残している。熱の方針は自然で、かつ未確認を消していない。

機構の理屈づけも良かった。固定穴は「ケースに止めるため」だけでなく 「コネクタ抜き差しの力を受けるため」 に要る、という説明。端子台・モータ端子・サーボ端子・Qwiic の抜き差しで基板端に力がかかるから、というのは現物を触っている人の言葉だ。左下の固定穴とサーボ端子が近すぎたのでサーボを右へ寄せた、GND の戻り経路を I2C センサの下に通さない、といった判断も、ちゃんと残っている。

一つだけ、私が念押しするとしたら ── ピンの入れ替えを必ず三点（PCB・回路図・ファーム）で揃える ことだ。今回、配線を素直にするために GP10〜GP13 を DRV8833 のピン順へ入れ替えている。これ自体は、ファームが固まっていない段階なら正しい判断だ。ただし、入れ替えたら必ず pin-assignment.md と review-notes.md に残す。PCB と回路図とファームの三つがズレた瞬間に、いちばん見つけにくい事故になる。記録は、ちゃんと残っていた。

運用の型 ── 毎回これを回す

通して見ると、効いていた手順はだいたい五つに畳める。

1. まずプロジェクトのルールを読む（憲法・レビュー記録・ワークフロー文書）。毎回ここから始める。
2. 欲しい成果物の種類を宣言する。仕様メモか、回路図下書きか、レビュー用 CAD か、DRC 結果か、レビュー画像か、発注前チェックか、製造データか。製造データだけは別扱いにして、レビュー用と同じ流れで出さない。
3. 止まる場所（ゲート）を先に決める。AI は勢いよく進められるからこそ、停止点を先に置く。
4. 毎回、レビュー可能な絵を出す。表面・裏面・銅箔の SVG、DRC の JSON、レビュー記録。テキストだけだと安心できない。基板は目で見るものが要る。
5. 再生成できる形を優先する。GUI だけで進めず、スクリプト・テキスト CAD・JSON・SVG のように、再実行できる形に寄せる。

DRC だけでは見た目の不自然さは拾えないし、レビュー図だけでは CAD 上の接続不良は拾えない。両方いる ── これは何度でも言っておきたい。

同じことをやるには ── 何をどう用意するか

「面白そうだから自分でも」という人のために、再現に必要な最小セットを書いておく。特別なものは、ほとんどいらない。

1. エージェント型のAIツールを一つ用意する。リポジトリの中でファイル編集とシェル実行を繰り返せるもの（Codex CLI、Claude Code など）。権限を絞れる・途中で止められるものを選ぶのが大事だ。
2. 作業用のリポジトリを git で作る。中身はこういう構成にしていた ── docs/（設計依頼・制約・部品・配置/配線方針・レビュー記録）、cad/kicad/（検証用CAD）、tools/（生成スクリプト）、outputs/（発注候補は人間承認後だけ置く）。設計の「中身」を全部テキストで持つのが肝になる。
3. AIの憲法を置く。リポジトリ直下に AGENTS.md（役割＝下書きとレビュー支援、承認ゲート、禁止事項、人間レビュー必須領域）。ドメイン固有の手順は Skill（.agents/skills/...）に分ける。そして、AIには毎回まずこれを読ませる。ここをサボると、AIは気持ちよく暴走する。
4. 検証CADはKiCadにする（無料・テキスト形式）。kicad-cli が DRC を JSON で出し、SVG のレビュー図も出せる。AIには生成スクリプト（Python）から基板を作り直させ、kicad-cli pcb drc を作業ループに組み込む。手で少しずつ直すより、戻して試し直すのが楽になる。
5. 部品確定と発注は EasyEDA / JLCPCB 側で、人間がやる。LCSC番号・在庫・実装可否・Basic/Extended は、AIに「在庫あり」と言わせず、人間が画面で確認する。AIにはログインも発注もさせない。
6. 権限を二重に締める。AIツール側の権限設定で push・発注・外部ログイン・秘密鍵の読み取りを禁止し、AGENTS.md の禁止事項にも同じことを書く。ルールは紙とツールの両方に置くと強い。
7. 毎回、DRC結果とレビュー図をセットで出す運用にする（前の節のとおり）。

つまり用意するのは ──「止められるAI」「git のリポジトリ」「憲法」「テキストで触れるCAD」「人間が握る発注ゲート」── この五つだ。賢い特別なAIを探すより、この足場を組む方が、ずっと再現性に効く。たぶんそれが、今回いちばん伝えたいことなんだと思う。

一行で言うと

AI 基板設計で大事なのは、AI に天才設計者をやらせることではない。AI を「仕様整理・再生成・検証・レビュー記録の作業者」として使い、危ない判断を人間が握り続ける ことだ。

そして、たぶんいちばんの肝は「止まる場所を先に決める」ことだと思う。賢く速く進む道具ほど、止まる場所を自分では作らない。だから、ゲートはこちらで置いてやる。再現できる足場と、正直な「未確認」と、先に決めた停止点 ── 派手さはないけれど、この三つが揃っていると、AI と一緒でも、基板はちゃんと前に進む。

この板はまだ v0.1 で、回路図の実体化も、ピン1の照合も、逆流対策も、宿題として開いたままだ。でも、開いたままだと 分かっている こと自体が、いちばんの成果だと思う。閉じていないゲートが図に描いてある基板は、たぶん、そう簡単には燃えない。

— ランキン