KiCad で Codex を使う方法｜回路図・基板設計を AI で自動化
電子回路の設計ツール KiCad は、回路図も基板データもテキスト形式で保存されるため、AI コーディングエージェントの OpenAI Codex と相性がよい。本記事では、Codex に KiCad プロジェクトを読ませて部品表の整理や出図スクリプトの作成を任せる方法を、前提知識・セットアップ・実践例・注意点の順に解説する。ソフトウェア開発以外で Codex を活かしたい人にも参考になるはずだ。
KiCad の設計ファイルは、実体がプレーンテキストである。回路図の .kicad_sch も基板の .kicad_pcb も S 式と呼ばれるテキスト形式で記述されており(出典: https://docs.kicad.org/)、Codex から見れば読み取りも解析もできる普通のファイルだ。プロジェクトのフォルダで Codex CLI を起動するだけで、部品リストの抽出や設計データの調査といった作業を自然言語で頼める状態になる。
Codex が力を発揮するのは、KiCad まわりの「スクリプトを書く仕事」だ。KiCad にはコマンドラインツールの kicad-cli と、基板エディタ向けの Python スクリプト機能が公式に用意されている(出典: https://www.kicad.org/)。ガーバー出力や PDF 出図をまとめて行うシェルスクリプト、部品のリファレンス整理を行う Python スクリプトなどを Codex に書かせれば、手作業で繰り返していた出図・検査作業を自動化できる。
一方で、設計データの直接編集は慎重に進めるべきだ。S 式ファイルは Codex が書き換えられる形式だが、要素同士の整合性は KiCad 本体が管理しており、壊れた編集は開けないファイルを生む。Git などでバージョン管理した上で、変更後は必ず KiCad の ERC / DRC で検証する流れを守れば、リスクを抑えながら Codex の恩恵を受けられる。設定や最新機能は OpenAI の公式ドキュメントで確認できる(出典: https://developers.openai.com/codex)。
目次 (10)
- KiCad と Codex の相性 — 設計データがテキストであることの意味
- Codex に任せられる KiCad 作業の具体例
- セットアップ手順 — プロジェクトを Codex に読ませるまで
- Step 1: Codex CLI をインストールする
- Step 2: プロジェクトを Git で管理する
- Step 3: プロジェクトフォルダで Codex を起動する
- Step 4: AGENTS.md にプロジェクトの前提を書く
- 実践例 — kicad-cli の出図スクリプトを書かせる
- 注意点 — 設計データを壊さないための 3 つの原則
- まとめ — 設計は KiCad、周辺作業は Codex に
KiCad と Codex の相性 — 設計データがテキストであることの意味
KiCad はオープンソースの電子設計ツール(EDA)で、回路図エディタと基板(PCB)エディタを中心に、部品ライブラリやガーバー出力までを一式で備える(出典: https://www.kicad.org/)。Codex との組み合わせを考えるうえで重要なのは、KiCad のプロジェクトを構成するファイルの大半がテキストだという点だ。回路図は .kicad_sch、基板は .kicad_pcb、プロジェクト設定は .kicad_pro に保存され、いずれも括弧で構造を表す S 式という書式で記述される(出典: https://docs.kicad.org/)。バイナリ形式に閉じたツールと違い、Codex がファイルを開いて部品の一覧を数えたり、配線幅の設定値を探したりできる。
OpenAI Codex はターミナルで動く AI コーディングエージェントで、作業ディレクトリのファイルを読み、シェルコマンドを実行し、コードを書いて修正まで行える(出典: https://developers.openai.com/codex)。対象はソースコードに限らず、テキストであれば設計データも扱える。2026年6月22日に安定版となった Codex CLI v0.142.0 ではウェブ検索モードが加わり、部品のデータシートや KiCad の最新仕様を調べながら作業を進めやすくなった(出典: https://github.com/openai/codex/releases)。「設計はグラフィカルな専用ツール、周辺作業はコマンドとスクリプト」という KiCad の構造に、Codex はきれいにはまる。
Codex に任せられる KiCad 作業の具体例
実際にどんな作業を頼めるのかを先に押さえておくと、導入の判断がしやすい。ポイントは、KiCad 本体の GUI 操作を置き換えるのではなく、GUI の外側にある繰り返し作業とスクリプト作成を任せることだ。回路図を描く・部品を配置するといった設計判断は引き続き人間と KiCad エディタの仕事であり、Codex はその前後の面倒な部分を引き受ける役割になる。代表的なユースケースを挙げる。
- 部品表(BOM)の整理: 回路図ファイルから部品のリファレンス・型番・数量を抜き出し、CSV や Markdown の表に整形させる。「型番が空欄の部品を一覧にして」といった検査も一言で頼める。
- 出図スクリプトの作成: kicad-cli を使ってガーバー・ドリル・PDF をまとめて出力するシェルスクリプトを書かせる。製造データ一式を毎回同じ手順で作れるようになる。
- 基板エディタ用 Python スクリプトの生成: KiCad の基板エディタが備える Python スクリプト機能(pcbnew モジュール)向けのコードを書かせ、部品の一括リネームや配置座標の書き出しに使う。
- 設計ルールの確認: ERC(電気ルールチェック)/ DRC(デザインルールチェック)のレポートを読ませ、指摘を重要度別に整理させる。
- ライブラリの調査: プロジェクト内のフットプリント割り当てを横断的に調べ、「未割り当ての部品」「重複するライブラリ参照」を報告させる。
いずれも共通するのは、対象がテキストファイルとコマンドラインで完結する作業だという点だ。逆に、配線の引き回しやシルクの見た目調整のような視覚的な判断が要る作業は、現状では KiCad エディタで人間が行うほうが速くて確実だ。
セットアップ手順 — プロジェクトを Codex に読ませるまで
準備は少ない。KiCad のプロジェクトフォルダがあり、Codex CLI が動く環境なら、次の 4 ステップで始められる。
Step 1: Codex CLI をインストールする
Codex CLI は npm から導入できる。ターミナルで npm install -g @openai/codex@latest を実行し、codex --version で版番号が表示されれば準備完了だ。ChatGPT アカウントでのサインインが必要になるため、初回起動時の案内に従ってログインする(出典: https://developers.openai.com/codex)。すでに導入済みの場合も、同じコマンドで最新安定版へ更新しておくと後述の検索機能などが使える。
Step 2: プロジェクトを Git で管理する
Codex に書き込みを許す前に、KiCad プロジェクトのフォルダを Git リポジトリにしておく。設計ファイルはテキストなので差分管理と相性がよく、Codex の編集で問題が起きてもすぐ元に戻せる。バックアップ手段を先に用意しておくことが、AI に設計データを触らせる際の最低限の保険になる。KiCad が生成するバックアップフォルダやキャッシュは除外設定に入れておくと差分が読みやすい。
Step 3: プロジェクトフォルダで Codex を起動する
ターミナルで KiCad プロジェクトのフォルダ(.kicad_pro があるディレクトリ)へ移動し、codex を起動する。Codex は起動したディレクトリを作業範囲として扱うため、これだけで回路図・基板・ライブラリテーブルが読み取り対象になる。最初は「このプロジェクトの構成を説明して」「回路図に含まれる部品を種類別に数えて」といった読み取り専用の指示から始め、Codex がファイルを正しく解釈できているかを確かめるとよい。
Step 4: AGENTS.md にプロジェクトの前提を書く
プロジェクト直下に AGENTS.md というファイルを置くと、Codex が毎回の作業前に読む指示書として機能する(出典: https://developers.openai.com/codex)。KiCad プロジェクトなら「.kicad_sch と .kicad_pcb は指示がない限り直接編集しない」「出力物は fab/ フォルダにまとめる」「基板は 4 層、最小配線幅 0.15mm」といった前提を書いておくと、頼むたびに説明を繰り返さずに済み、危険な編集の抑止にもなる。
実践例 — kicad-cli の出図スクリプトを書かせる
具体的な流れを、製造データ出力の例で見てみよう。KiCad 付属の kicad-cli は、回路図や基板からの各種出力をコマンドで実行できるツールで、ガーバー・ドリルファイル・PDF・BOM などの生成に対応する(出典: https://docs.kicad.org/)。ただし引数やオプションが多く、毎回手で打つのは現実的でない。そこで Codex に「この基板からガーバーとドリルファイルを fab/ フォルダへ出力し、回路図 PDF も添えるスクリプトを書いて」と頼む。
Codex はプロジェクト内のファイル名を確認し、kicad-cli のサブコマンドを組み合わせたシェルスクリプトを書き、その場で実行して動作まで確かめる。ここで v0.142.0 のウェブ検索モードが効いてくる。kicad-cli はバージョンによってオプションが変わるため、手元の KiCad の版に合った書き方を Codex が調べながら組み立てられると、古い書式のまま失敗するやり直しが減る(出典: https://github.com/openai/codex/releases)。生成されたスクリプトはプロジェクトに残るので、次回からは Codex を介さず同じ出力を再現できる。エージェントに都度頼むのではなく「頼んだ結果を資産として残す」使い方が、設計業務では特に効果的だ。
基板エディタの Python スクリプト機能を使う例も同様に進められる。「全部品の座標とリファレンスを CSV に書き出す pcbnew スクリプトを書いて」と頼めば、Codex は KiCad の Python API を使ったコードを生成する。実行は KiCad のスクリプトコンソール側で行い、結果を確認してから常用に組み込む、という分担が安全だ。
注意点 — 設計データを壊さないための 3 つの原則
便利さの裏で、設計データ特有のリスクも押さえておきたい。ソースコードと違い、基板データの破損は物理的な製造ミスに直結しうる。次の 3 点を原則にすると事故を避けやすい。
第一に、設計ファイルの直接編集は原則として頼まない。.kicad_pcb の S 式は Codex が書き換えられる形式だが、ネット接続や部品の内部 ID など、KiCad 本体が整合性を管理している要素が多い。テキストとして一見正しくても、エディタで開くと壊れているデータになり得る。編集はできる限り KiCad の公式な入り口(kicad-cli、Python API、GUI)を通す。
第二に、変更後は必ず KiCad 側の検証を通す。ERC / DRC の実行、3D ビューアでの目視、ガーバービューアでの出力確認など、KiCad には検証手段が揃っている。Codex の作業結果を「開けたから大丈夫」で済ませず、製造前と同じチェックに掛ける習慣が、AI 活用の安全弁になる。
第三に、Codex の承認設定を保守的に保つ。Codex CLI には、コマンド実行やファイル書き込みの前に確認を挟む承認モードとサンドボックス設定があり、作業範囲外への影響を制限できる(出典: https://developers.openai.com/codex)。設計データを扱う間は確認ありの設定で運用し、読み取り中心の調査タスクだけ緩める、といった使い分けが現実的だ。
まとめ — 設計は KiCad、周辺作業は Codex に
KiCad の設計ファイルがテキストであること、そして kicad-cli と Python スクリプトという公式の入り口があることが、Codex 活用の土台になる。部品表の整理、出図スクリプトの作成、ルールチェック結果の整理といった周辺作業を Codex に移すだけで、設計者が KiCad エディタに集中できる時間は目に見えて増える。始めるなら、まず読み取り専用の調査タスクから。Git 管理と ERC / DRC での検証を習慣にしたうえで、スクリプト作成へと任せる範囲を広げていくのが、遠回りに見えて最短の道筋だ。KiCad の機能詳細は公式ドキュメント(出典: https://docs.kicad.org/)、Codex の設定は OpenAI の開発者向けドキュメント(出典: https://developers.openai.com/codex)を参照してほしい。
