第2章：なぜ結線を「コード」で書くのか
この章では、まだ手を動かしません。前章で決めたボードの結線を、KiCad入門のように回路図に名札を置いて手でつなぐやり方と、このコースのつなぐ関係をコードで書くやり方を並べて、何が同じで何が違うのかを見ます。「結線をコードで書く」という発想を持ち込んだ人が、回路図の何を面倒と見て、どこを文字に置き換えたのかを追いかけます。先に結論だけ言えば――コードにするのは“論理（どこをつなぐか）”で、“物理（どう並べ・どう引くか）”は人の手に残る、という線引きです。回路図を捨てる話ではありません。
2.1 回路図は「見てわかる」。では、何が面倒だったのか
はじめに、回路図の良さを先に認めておきます。回路図の一番の強みは、構造が目で見てわかることです。電源が上、GNDが下、信号が横に流れる――そういう“絵”として描かれていると、初めて見る人でも全体像をつかめます。KiCad入門で、グローバルラベルを置きながら回路を組んだあの感覚は、多くの人にとって回路を理解する自然な入口です。この良さは、このコースでも否定しません。
そのうえで、手で描く回路図がどこで面倒になりやすいかを見ておきます。善し悪しの話ではなく、「どういう作業でミスや手間が出るか」という観察です。
- 同じパターンの繰り返し。 抵抗を10個並べる、同じデカップリングコンデンサを何個も置く――同型の繰り返しを、一つずつ手で置いてラベルを付けるのは単調で、貼り間違いが起きやすい。
- ピンの多いバス。 何十本もの信号を、名前を合わせながらつないでいく作業は、名札の打ち間違いが紛れ込みやすい。
- 部品が増えたときの描き直し。 「やっぱりこの部品を足そう」となると、図の配置をやり直し、線を引き直すことになる。
- 「どこが変わったか」が見えにくい。 図を差し替えても、前の版と何が違うのかは、目で見比べるしかない。
KiCad入門で、基本形の結線を早見表を見ながら一つずつラベルで置いていったのを思い出してください。あれ自体は良い訓練ですが、ボードが育って部品と結線が増えるほど、この“単調さ”と“差分の見えにくさ”が効いてきます。「結線をコードで書く」という発想は、まさにこの面倒に向けて出てきました。
2.2 「つなぐ関係」は、突きつめると名前の対応表
ここで、大事な見方をはさみます。回路図が最終的に吐き出しているものは、実は“絵”ではありません。「どのピンと、どのピンが、同じ網（ネット）につながっているか」という一覧表――ネットリストです。KiCad入門の第5章で、回路図から基板へ部品を移したとき、部品同士を結んだ細い予約線（ラッツネスト）が現れました。あれは、この一覧表が形になったものでした。
どの部品のどのピンが、どのネット（電気的に同じ網）に属するかを列挙した対応表です。たとえば「U1の9番ピンと、C1の1番ピンと、U2の出力ピンは、みんな
VCC という網に属する」といった具合。回路図エディタも、結局はこのネットリストを出力するための道具で、基板エディタ（Pcbnew）はこのネットリストを受け取って配線していきます。つまり“つなぐ”という行為の本体は、絵ではなく名前の対応表なのです。
ここが、コードの話の出発点です。「名前の対応表」は、絵で描かなくても、文字で書けます。「この網に、このピンと、このピンをつなぐ」を文字で列挙すれば、それはもうネットリストです。“つなぐ”が文字で書けるなら、コードと相性がいい――この気づきが、次の話の起点になります。
2.3 コードで書くと、何が楽になるのか（skidlの着眼）
結線をPythonのコードで書く道具の一つが、このコースで使う skidl です。作者が何を面倒と見て、どこを文字に置き換えたのか――その着眼をたどると、コードにする利点が見えてきます。
skidlの説明でくり返し出てくるのは、「何ページもの回路図を追いかけて信号をたどる、あの手間をなくしたい」という動機です。信号を目で追う代わりに、テキストで「つなぐ順」に書く。たとえば「電源→抵抗→出力→抵抗→GND」という直列を、つなぐ順に一行で書けば、それがそのまま結線になる――という具合です。図を描くのではなく、関係を文章のように書き下す。ここが出発点の着眼です。
- 繰り返しは、ループで畳める。 同じデカップリングコンデンサを10個――なら、10回ぶんのループで書ける。一個ずつ手で置く単調さが消える。
- 値や型番は、パラメータにできる。 「抵抗値をここで一括で変える」「部品を条件で入れ替える」が、変数の書き換えで済む。
- 差分が、そのまま見える。 テキストなので、
gitやdiffで「前の版と何が変わったか」が一行単位でわかる。回路の変更履歴が、ソフトウェアと同じ流儀で追える。 - 再利用できる。 「電源部」「書き込み端子」といったまとまりを部品のように使い回せる。人の作った回路モジュールを取り込むこともできる。
- 機械が読める・検査できる。 つなぎ忘れや電源の衝突といったミスを、コードの段階で機械（ERC＝電気的ルールチェック）に洗わせられる。
上の利点は、あくまでこういう作業のときに効くという観察です。逆に、初めて回路を眺めて全体像をつかむ、少数の部品の関係を直感的に見せる――そういう場面では、絵である回路図のほうがずっと伝わります。コードと回路図は、得意な場面が違う道具だと考えてください。このコースが結線をコードにするのは「回路図より偉いから」ではなく、今回のように“繰り返しの検算”や“差分の管理”を機械に任せたい作業に向いているからです。
2.4 コードから「図」を起こす ― 3つの道と、その使い分け
「結線をコードで書くと、回路図（絵）はもう見られないのか？」――そんなことはありません。結線をコードで持っていれば、そこから“図”を起こす道がいくつもあります。ただし、これも目的が違う道が混在しているので、切り分けて押さえます。大きく3つです。
- 清書して“見せる図”を作る（例：SchemDraw）
SchemDrawは、部品を一つずつ「右・下・左・上」と向きを指定しながら、手で描くようにコードで配置していくPythonの作図ライブラリです。配置は人が決めますが、そのぶん資料や教材に載せられるきれいな回路図が作れます。結線から自動で起こすのではなく、「人が構図を決めて、コードで清書する」道具。“見せる図”を、バージョン管理できる形で描くのに向きます。 - 結線から“確かめる図”を自動で起こす（例：skidlの図出力）
skidl自身にも、書いた結線から図を出す機能があります。接続を機械が自動でレイアウトしたつながり図（SVG）や、部品を点・ネットを線で結んだグラフ表示を出せます。見た目は素朴で、人が整えた回路図ほど読みやすくはありませんが、「自分の書いたコードが、意図どおりつながっているか」を目で確かめるのに役立ちます。人手の配置は要りません。 - 編集できるKiCad回路図（.kicad_sch）を自動生成する
「コードから、KiCadで開いて編集できる回路図そのものを吐かせたい」という道もあります。ただしここは発展途上で、対応するKiCadのバージョンや実装状況が動きます。安定して使える段階とは言いにくいので、本コースは当てにしません。使ってみたい場合は、必ず各ツールの最新の公式情報で対応状況を確認してください。
①のSchemDrawが作るのは、人に見せる“見せる図”。②のskidlが自動で出すのは、自分の結線を点検する“確かめる図”です。どちらが上ということはなく、用途で選びます。そして大事なのは、どちらも「結線をコードで持っている」からこそ、後から自由に選べるという点です。絵から入ると図は一枚に固定されますが、コードから入ると「確かめる図も、見せる図も、必要なときに起こせる」――ここが、コードで持っておくことの効きどころです。
補足として、近年のKiCadは「いったん描いた回路図を正本（マスター）とする」流儀に寄っていて、ネットリストから回路図を逆に起こす方向は、素直な道ではありません。そのため実務では、「回路図の自動生成にこだわらず、コード→ネットリスト→基板（Pcbnew）へ直行する」のが定石になっています。本コースの本線（次章以降）も、この直行ルートです。回路図（絵）が欲しいときは、上の①②で“別に起こす”と割り切ると、話がすっきりします。この辺りはツールの更新で変わりやすいので、細かい手順は公式に委ねます。
なお、「コードから回路図までを、もっと積極的に自動で描く」新しい系統の道具も登場しています。それらは終章「いま、世界はどう作っているか」で、今どこを向いて動いているかの見取り図として眺めます。
2.5 では、コードにしないほうがよいものは何か
ここまで「結線＝論理はコードに向く」と見てきました。では逆に、コードにしないほうがよいものは何でしょうか。答えは、物理――部品を板のどこに置き、線をどう引き回し、どこでビアを打ち、ベタGNDをどう流すかです。これらは、盤面を見ながらの判断が要ります。「この部品はコネクタの近くに」「この電源線は太く短く」「ここは裏に逃がす」といった判断は、文字で列挙するより、盤面を見て手を動かすほうが早く、確かです。
【このコースの背骨（再掲）：どこをコードに、どこを人と機械に】
結線（論理） 物理設計 自動配線 検算
「どこをつなぐか」 「どう引くか」 「線を引く」 「間違い探し」
↓ ↓ ↓ ↓
コード(skidl) 人（KiCad） 機械＋人 機械（DRC）
＝この章の話 盤面を見て判断 大半を任せ、 全数検査
幅/ビア/ベタGND 混む所は人が引く
つまり、コードは万能の置き換えではありません。「つなぐ（論理）」はコードに渡せるが、「並べる・引く（物理）」は人の判断が要る。この線引きこそ、序章で示した背骨そのものです。このコースは「全部コードでやる」を目指しません。コードに向くところをコードに渡し、人にしかできない判断を人に残す――その配分を、実際に手を動かして確かめていきます。
2.6 このコースの立場：回路図を捨てるのではなく、役割で分ける
まとめます。このコースは、回路図を捨ててコードに乗り換えるという話ではありません。回路図もコードも道具で、それぞれ得意な場面が違う。今回は、“つなぐ”をコードに、“並べる・引く”を人と機械に振り分けます。KiCad入門で身につけた回路図の考え方は、ここでも生きています。ネットリストが何か、ネットクラスが何か――それを手で一度やったからこそ、コードが吐くネットリストの意味がわかります。
結線をコードにすると、“ぱっと見て全体像がわかる”という回路図の良さは、いったん手放すことになります（だからこそ2.4で「図を起こす道」を用意しました）。コードは、慣れるまでは全体像がつかみにくい。ここは正直な代償です。それでも、繰り返しの検算・差分の管理・再利用といった“作業”を機械に任せられる利点が、今回のボードづくりでは効いてきます。何を得て、何を手放すかを承知したうえで、道具を選ぶ――それが、このコースの立場です。
2.7 次章への橋渡し
- 回路図の良さ（見てわかる）は認めたうえで、手描きが面倒になる場面（繰り返し・バス・描き直し・差分）を見た
- “つなぐ”の本体は絵ではなくネットリスト（名前の対応表）で、だから文字＝コードで書ける、と押さえた
- コードにすると効く場面（ループ・パラメータ・差分・再利用・機械の検査）を、skidlの着眼として観察した
- コードから図を起こす3つの道（清書＝SchemDraw／確かめる図＝skidl自動／編集可能な回路図＝実験的で公式委ね）を切り分けた
- コードにするのは論理まで。物理（配置・配線・ビア・ベタGND）は人に残す、という背骨を確認した
考え方の準備ができました。次章からは、手を動かします。まずskidlを自分のPCに入れ、いちばん小さな回路を一つ、コードで書いて動かします。