安全すぎる、チャッピー。――ハードウェア開発で感じたAIの慎重さ
今回は少し雑談です。
GPT-6 AstraとCodexを使い、基板設計やFPGA開発を実際に進めてきました。回路図の確認、部品選定、KiCadデータの編集、FPGAプロジェクトの作成、実機デバッグなど、生成AIに任せられる範囲はかなり広がっています。
正直なところ、ハードウェア開発でここまでできると想像している人は、まだそれほど多くないのではないかと思います。
一方、実際に使い込んでみると、ChatGPTはかなり安全志向だということも分かってきました。
安全なのは大切です。しかし、ときどき慎重すぎて作業がなかなか終わらない。生成AIで開発を速くしたいのに、安全確認が増えて先へ進めないということを、ここ何回か経験しました。
ChatGPTで相談してからCodexへ渡す
私の場合、いきなりCodexへ作業を依頼することはあまりありません。
まずChatGPTの通常のチャットで、これから何をしたいのかを相談します。目的、現在の状態、変更したい内容、触ってよい範囲などを整理し、Codexへ渡す作業用のプロンプトを作ります。
実際のファイル操作、プログラム作成、KiCadやVivadoを使った作業は、主にCodexへ任せます。
基本的な流れは次のとおりです。
- ChatGPTへ作業内容を相談する
- 作業条件と危険な箇所を整理する
- Codex向けのプロンプトを作成する
- Codexが設計やデバッグを進める
- 結果を人間が確認する
- 必要なら次の指示を作る
この方法には、作業前に条件を整理できるという利点があります。
その一方で、ChatGPTがCodex向けの指示を作る段階から、かなり慎重な条件が入ることがあります。

ハードウェアなので、慎重になる理由は分かる
基板やFPGAの開発では、ソフトウェアだけの作業とは違う危険があります。
設定を間違えれば、部品へ想定外の電圧を加える可能性があります。出力同士を衝突させたり、電流を流しすぎたり、場合によっては基板や接続先の機器を壊したりすることもあります。
私自身、初めて基板へ電源を入れるときは、今でも緊張します。過去には実際に燃えた経験もあります。
そのため、ChatGPTやCodexが慎重になること自体は理解できます。
電源条件が確認できない、接続先の状態が分からない、実機を駆動してよいという明確な許可がない。このような状況で、AIが勝手に作業を進めないことは重要です。
ネット上の作業でも同じです。個人情報や認証情報が関係する場合、便利だからという理由だけで何でも自動化すると、情報漏洩につながる可能性があります。
生成AIが安全側へ判断するように作られていることには、それなりの理由があります。
ただし、慎重すぎて終わらないこともある
問題は、安全確認をどこまで行えば十分なのかという線引きです。
実際の開発では、人間が基板の構成、接続先、電源条件、試験環境を理解しています。そのうえで、「今回はこの範囲まで動かしてよい」「ここは未接続なので問題ない」「この信号は弱く入力するだけ」といった判断をしています。
ところが、その背景がAIへ十分に伝わっていないと、必要以上に慎重な動作になります。
一つ確認すると別の危険を見つけ、さらに確認項目が増える。安全条件を追加し続けた結果、作業そのものがなかなか始まらない、あるいは完了しないことがあります。
AIの立場からすると、確認できないものを危険側に判断しているだけです。
しかし、人間側から見ると、「そこまで確認しなくても、今回はここで止めてよい」「この条件なら作業を進めて問題ない」という場面もあります。
せっかく生成AIを使って開発を高速化しているのに、安全確認のループへ入って作業時間が延びてしまう。この点は、実際に使ってみて感じた難しさです。
安全かどうかは、人間の方が判断できる場合もある
生成AIは、与えられた情報の範囲で安全性を判断します。
一方、設計者は回路図だけでなく、実際の配線、測定器、電源装置、接続している機器、試験の目的なども見ています。
そのため、個別の実験環境については、人間の方が正確にリスクを判断できる場合があります。
もちろん、人間も間違えます。思い込みや確認漏れもあります。AIの慎重な指摘によって、実際に助けられたことも何度もありました。
したがって、「人間の判断が常に正しく、AIの安全確認は不要」という話ではありません。
逆に、すべてをAIの判断へ任せればよいわけでもありません。
AIが危険を洗い出し、人間が実際の環境を確認して、どこまで進めてよいかを決める。この役割分担が必要です。
人間がどこまで介入するかが難しい
現在のところ、最も難しいのは、人間がどの段階で介入するかという部分です。
早い段階で人間が細かく指示しすぎると、自動化のメリットが小さくなります。逆に、完全に任せると、安全確認が増えすぎたり、AIが判断できずに止まったりします。
今の自分の使い方では、最初に次の条件をできるだけ明確に伝える必要があると感じています。
- 今回の作業範囲
- 変更してよいファイルや回路
- 実機を操作してよい範囲
- 電源を投入してよい条件
- 接続されている機器
- 絶対に駆動してはいけない信号
- 問題が起きた場合の停止条件
- 人間へ確認を求める場面
- 今回は確認対象外とする項目
- 作業を完了と判断する条件
特に、「何を確認すれば作業完了なのか」を先に決めておかないと、安全確認が際限なく広がることがあります。
安全性を下げるのではなく、範囲を明確にする
解決方法は、単純にAIの安全確認を緩くすることではないと思っています。
ハードウェアでは、本当に壊れる可能性があります。安全性を下げて作業速度だけを優先するのは危険です。
必要なのは、AIが確認すべき範囲を明確にすることです。
例えば、「今回は基板単体で、外部装置は接続しない」「出力信号は駆動せず、入力確認だけを行う」「電源電圧を測定し、正常であることを確認してから次へ進む」といった条件を具体的に与えます。
人間が許可できる範囲を先に切り分ければ、AIも必要以上に広い範囲を心配せずに済みます。
今後は、作業ごとに次の3段階を明確にするのがよさそうです。
- AIが自由に進めてよい範囲
- 条件を満たせば進めてよい範囲
- 人間の承認がなければ進めてはいけない範囲
これを最初に決めることで、安全性を保ちながら、作業速度も落としにくくなると思います。
安全すぎるのも、ある意味では成長途中
実際に使っていて、「チャッピー、安全すぎるよ」と思うことはあります。
ただ、ハードウェア開発まで生成AIが担当し始めたからこそ、この問題が見えるようになったとも言えます。
以前であれば、AIは回路やコードを提案するだけでした。現在は、設計ファイルを変更し、ツールを動かし、実機デバッグまで進めようとしています。
できることが増えた分、どこまで自律的に動かしてよいかが重要になりました。
今後は、人間の経験や許可条件をもう少しうまく伝えられるようになれば、安全性と開発速度を両立できると思います。
AIへ何を任せるかだけではなく、どこで止め、どこから人間が判断するか。このさじ加減も、AIを使ったハードウェア開発の重要な技術になりそうです。
English Summary
Generative AI has automated a surprising amount of my PCB and FPGA development workflow. I usually discuss the task with ChatGPT first, prepare detailed instructions, and then let Codex perform the actual design or debugging work.
While this workflow is powerful, I have also found ChatGPT and Codex to be highly safety-oriented. This is understandable in hardware development, where an incorrect voltage, conflicting output, or inappropriate power-up sequence can damage a board or connected equipment.
However, excessive caution can sometimes prevent a task from finishing. The AI may continue adding checks because it does not fully understand the physical test environment, while the human engineer already knows which devices are connected and which risks are acceptable.
The solution is not simply to reduce safety checks. A better approach is to define the operating boundaries more clearly: what the AI may do freely, what it may do after specific conditions are met, and what always requires human approval.
As AI moves from generating code to directly modifying designs and debugging physical hardware, deciding where automation should stop becomes an important engineering task in itself.

