CAD（コンピュータ支援設計ツール）やPCB（プリント基板）設計、シミュレーションといった「物理世界」のエンジニアリング領域にChatGPTやCodex（OpenAIが提供するコーディング支援エージェント）を組み込む動きが出てきています。ソフトウェア開発のQA（品質保証）やCI/CD（継続的インテグレーション・継続的デリバリー）パイプラインに関わる方のうち、ハードウェア開発チームとの連携やEDA（電子設計自動化）ツールの自動化を検討している方に向けて、この動きをテスト戦略の観点から整理します。
対象読者は、組み込み機器やIoT製品、ロボティクスなど「ソフトウェアとハードウェアが交差する」開発に関わるエンジニアです。CADやPCB設計工程にAIエージェントを導入する際、何を検証し、どの品質メトリクス（品質を測る指標）を追跡すべきか、判断材料になればと思います。
何が起きているのか
OpenAIは、ChatGPTとCodexをCAD設計、PCB設計、物理シミュレーションといったワークフローに適用する取り組みを紹介しています。従来、これらの工程はSolidWorksやAltium Designerのような専用ツール上で、設計者が手作業で進めるものでした。
ここにLLM（大規模言語モデル）ベースのエージェントが介在することで、設計案の生成、設計ルールチェック、シミュレーション条件の設定といった作業を自動化・半自動化する流れが生まれています。ソフトウェア開発で言えば、コード生成から静的解析、テスト自動化までをAIが支援する構図と似ています。
注目すべきは、これが単なる「コード生成の延長」ではない点です。物理法則やハードウェア制約という、ソフトウェアのテストでは扱わない検証軸が加わります。たとえば生成されたPCBレイアウトが実際に製造可能か、配線が信号干渉を起こさないかといった検証です。
技術的な仕組みを段階的に見る
まず理解しておきたいのは、CodexがもともとGitHub連携を前提としたコーディングエージェントだという点です。リポジトリ内のコードを読み、タスクを実行し、プルリクエストを作る、というソフトウェア開発のワークフローに最適化されています。
これをCAD・PCB設計に応用する場合、入力となる「ソースコード」が設計ファイル（SolidWorksの.sldprt、KiCadの.kicad_pcbなど）に置き換わります。ChatGPTが自然言語の設計要求を解釈し、Codexのようなエージェントがツールのスクリプティングインターフェース（API経由で操作する仕組み）を通じて設計変更を実行する、という構造になります。
この構造は、ソフトウェアのCI/CDパイプラインにおける「コード変更→自動テスト→マージ」の流れと構造的に対応します。ただし物理設計では、自動テストに相当する工程がDRC（デザインルールチェック）やシミュレーションになり、実行コストが桁違いに高くなる点が異なります。
たとえばPCBの熱シミュレーション1回に数分から数時間かかることもあります。ソフトウェアのユニットテストが秒単位で終わるのとは対照的です。AIエージェントが設計案を複数生成しても、検証のボトルネックは依然として人間かシミュレーション実行環境に残ります。
既存のソフトウェアQAとの比較で見える違い
ソフトウェアのCI/CDパイプラインでは、テストピラミッド（ユニットテスト・統合テスト・E2Eテストの比率モデル）という考え方が定着しています。高速で安価なテストを土台に多く配置し、低速で高価なテストを頂点に少数配置する発想です。
CAD・PCB設計の自動化にこの発想を持ち込むなら、まず「構文チェック」に相当する軽量な検証を最初の防波堤にする設計が合理的です。具体的には、設計ルールの静的チェック（配線幅・クリアランスなど）を最速レイヤーに置き、物理シミュレーションは変更が一定規模を超えたときだけ実行する、という段階的なゲート設計です。
Gitベースのバージョン管理との親和性も論点になります。KiCadやFreeCADはテキストベース・差分管理しやすいファイル形式を採用しており、Gitでの差分レビューが可能です。一方、プロプライエタリなCADツールの中にはバイナリ形式でファイルを保存するものがあり、プルリクエストでの差分レビューが困難なケースがあります。AIエージェントを導入する前に、使用中のCADツールがどちらの形式かを確認しておくことは実務上の判断材料になります。
読者が今日確認できること
AIエージェントを設計ワークフローに組み込む前に、既存のパイプラインで確認しておきたい項目を整理します。
- 使用中のCAD/PCBツールにスクリプティングAPIやCLI（コマンドラインインターフェース）が用意されているか（KiCadはPythonスクリプティングAPIを公開しています）
- 設計ファイルがテキストベースでGit管理と相性が良いか、バイナリでレビューに工夫が必要か
- DRCやシミュレーションの実行時間を計測し、どの段階でゲートを設けるのが現実的かの見積もりがあるか
- 生成された設計案を人間がレビューする際のチェックリスト（製造可能性・部品在庫・コストなど）が明文化されているか
- 既存のCI/CDパイプラインに物理検証ジョブを追加した場合のパイプライン全体の実行時間への影響
品質メトリクスの観点では、ソフトウェアで使われる「テストカバレッジ」に相当する指標を物理設計領域で定義し直す必要があります。たとえば「DRC違反ゼロ」「シミュレーション許容誤差内」「部品調達可能性チェック通過」といった具合に、工程ごとの合格基準を数値化しておくと、AIエージェントが生成した設計案の採否判断が属人化しにくくなります。
まとめ
ChatGPTやCodexをCAD・PCB設計に適用する動きは、ソフトウェアのコーディング支援がハードウェア領域に広がる延長線上にあります。構造としてはCI/CDのコード変更検証フローと似ていますが、検証コスト（シミュレーション時間）がソフトウェアテストより桁違いに高い点が最大の違いです。
導入を検討する際は、まず自社のCAD・PCBツールがスクリプティング可能か、ファイル形式がGit管理に向くかを確認するところから始めると見通しが立てやすくなります。そのうえで、軽量な静的チェックを前段に、重いシミュレーションを後段に配置する段階的なゲート設計を検討してみてください。
品質メトリクスについても、DRC違反件数やシミュレーション誤差率など、物理設計特有の合格基準を数値化しておくことが、AI生成物の採否を属人的な判断から切り離す一歩になります。