Claude Codeをハードウェア開発に使う。これだけ聞くと、ちょっと夢が大きすぎる気もします。けれど、Lucas Geradsさんのこのデモは「AIに回路を丸投げする」のではなく、「AIにちゃんとフィードバックを返せる環境を渡す」とうまく回り始める、というかなり筋のいい話でした。
元記事でやっているのは、SPICEシミュレーション、オシロスコープ、Claude Codeをつないで、回路の確認作業を一段ラクにする試みです。SPICEは電子回路をPC上で動かすシミュレータ、オシロスコープは実際の電圧波形を見る計測器です。つまり、机上の計算と現物の計測を行き来しながら、Claude Codeに「ここは合っているか」を一緒に見てもらう、という発想です。
このデモが面白いのは、AIに「設計そのもの」を全部任せる方向ではなく、人間がやりたくない検証・整合チェックをAIに引き受けさせるところです。個人的には、ここがかなり現実的だと思います。AIは発明機械というより、面倒な往復作業を高速化する相棒として使った方が強い。少なくともハードウェアの世界では、そういう使い方の方が失敗しにくいはずです。
Lucasさんは、最初は「自然な英語で要件を書けば、Claudeが回路を作ってくれる」系の試みをいくつか見たそうです。ところが、単純な回路ならまだしも、少し複雑になると、作りたいものを言葉だけで正確に伝えるのが難しい。これはかなり納得感があります。ソフトウェアでもそうですが、ハードウェアは制約が多くて、しかも曖昧な表現がそのまま配線ミスや誤動作につながります。
そこで発想を変えたわけです。Claude Codeに、オシロスコープとSPICE simulatorへのアクセスを与える。するとClaudeは、計測値やシミュレーション結果を見ながら、回路が期待通りかを検証できるようになります。これが効くのは、単に便利だからではありません。Claude Codeが得意なのは、情報を見比べて差分を見つけることだからです。人間が見落としがちな「波形のちょっとしたズレ」を、かなり機械的に追える可能性がある。
記事では、この構成がSPICE回路やモデルの検証、組み込みプログラミング、データ分析にとても役立つと述べられています。特にデータ分析は、以前はかなり面倒だったとのこと。時間軸をそろえる、データ同士を位置合わせする、などの作業です。たしかに、こういう仕事は地味なのに時間を食います。しかも人間はつい「まあ見た感じで合ってそう」と目で済ませがちです。そこをClaudeに補助させると、かなり気持ちよくなるはずです。
ただし、Lucasさんはかなり重要な注意点も挙げています。まず、Claudeは物理的な配線を見ていません。つまり、「たぶんここにつながっているはず」みたいな推測をさせてはいけない、ということです。これは本当に大事です。ハードウェアで一番怖いのは、AIが自信満々に間違うことなので、接続関係は曖昧にしない方がいい。
次に、オシロスコープの測定データが古くならないようにすること。これは要するに、いま見ている波形が本当に最新の状態なのかを常に保証する、という話です。計測はリアルタイム性が命なので、古いデータを前提に議論すると一気にズレます。ここはソフトウェア以上に厳密さが要る部分だと思います。
さらに、生の測定データをClaudeのコンテキストにそのまま突っ込まない方がいい、としています。代わりにファイルに保存し、Claudeはそれを間接的に扱う形にする。これは実務感のあるアドバイスです。巨大な生データをそのまま会話に流し込むと、扱いづらいし、見通しも悪くなる。データは外に置いて、必要なときに参照させる方が賢いです。
MCU、つまりマイクロコントローラの扱いについてもコツがあります。Claudeにはpinout/pinmux mapを明示すること。pinoutは「どのピンが何の役割か」、pinmuxは「ピンの機能切り替え」のことです。ここを曖昧にすると、AIは平気で存在しない接続を想像しかねません。加えて、Makefileを用意して、build、flash、ping、eraseのような操作を明確な関数として使わせるのもポイントです。Claudeにその場でコマンドを発明させない。これはかなり正しい方針だと思います。自由度を与えすぎると、便利さより事故のほうが先に来るので。
元記事では、関連するリポジトリとして lecroy-mcp、spicelib-mcp、rc-filter-demo-files が紹介されています。MCPはClaudeのようなツールが外部機能にアクセスするための仕組みの一種で、ここではLeCroyのオシロスコープやSPICE関連のライブラリとつなぐ役割を担っているようです。デモ自体はわざと単純なRCフィルタとMCUで構成されていますが、Lucasさんが言うように、狙いは回路そのものの派手さではなく、このやり方が複雑な実案件にも伸びることを示すことです。
この手のデモを見ると、「AIが回路設計を全部やる未来」みたいな話より、まずは「人間が面倒でミスりやすい検証を、AIがかなり助ける未来」の方が先に来るんじゃないかと思います。ハードウェアは物理世界が相手なので、雑な自動化は危ない。でも、測定、比較、整形、確認のような仕事なら、AIはかなりいい相棒になれそうです。Lucasさんの試みは、その現実的な着地点をきれいに示していました。
参考: SPICE simulation → oscilloscope → verification with Claude Code — Lucas Gerads
