こんにちは、hacomono IoT部 メカニカルエンジニアのうらです。
猫も杓子もAIという世の中ですが、私の担当するハードウェア領域でも「設計・試作」だけでなく、周辺ソフト/電気系の作業が必要になる場面が増えてきました。一方で、メカ担当にとっては経験値ゼロの領域であり、ちょっとした検証のために詳しいメンバーの手を都度借りると、相互に負担が大きくなります。
メカエンジニアでもAIを使うことで、担当外（今回は電気・ファームウェア寄り）の作業を“最低限自走できる”状態に近づけたという体験を記事にしました。
（ここで言う“自走”は、最終品質まで一人で完結するという意味ではなく、検証を前に進めるための最初の一歩を自分で踏める、という意味です）
今回の検証における業務的な到達点（ゴール）は、最速で通信のプロトタイプを立ち上げ、技術的な実現可能性を評価することです。専門外の領域であっても、初期の環境構築や「一次切り分け」を自分で進めることで、社内リソースの負担を下げ、プロジェクト自体のスピードを落としきらないための自走が目的でした。
この記事の前提、用語の補足
- ファームウェア（FW）： 機器の中で動くソフトウェア。センサーや表示モジュールなどの周辺機器を制御します。
- ビルド / フラッシュ： FWを作って（ビルド）、機器に書き込む（フラッシュ）こと。
- 配線図： どの端子をどことつなぐか、を示す図。
- DK基板： 半導体メーカーが提供する評価用の開発キット（Development Kit）。配線や電源の“罠”を減らしやすいです。
なぜAIを使おうと思ったか
今回、低消費電力通信の技術検証のために nRF54L15 というマイコンボードを使ったPoCデバイスを作る必要がありました。PoCでは「まず動くものを早く作って、検証のサイクルを回す」ことが重要です。ただ、PoCを進めるにはメカ作業だけでなく、
- 端子の接続（配線）
- 周辺機器（表示モジュール等）の制御
- “書き込み→動作確認→修正”の反復
といった、電気・FW寄りの作業が避けられません。
そこで、AIを “不慣れ領域の作業を始めるための伴走者” として使い、対話の往復を増やしながら自分の理解も上げていく、という方針で進めました。
まずは「機器が動いている」状態を作る
最初のステップは、機器にプログラムを書き込める状態を作り、「こちらの意図した動作が反映されている」と確認できるところまで持っていくことです。基板上のLEDを意図通りに光らせる、通称”Lチカ”で確認するのがお作法です。
しかしターミナル上では処理が完了しているように見えるのに、実機で期待した変化が見えず「書き込みが成功しているのか」「動作確認ができているのか」が判断できない状態になっていました。
結果として原因は、USB給電が通っておらず、機器がそもそも起動していなかったことでした。
学び：AIは“PCの外側”を観測できない
AIはログやコードの整合性は見られますが、現実世界の状態（電源が入っているか、配線が正しいか、部品が壊れていないか等）は見られません。このためAIに頼るほど、こちらが
- 電源・配線・機器状態の前提
- 何をもって「成功」とするか（観測できる指標）
を明確にしないと、対話の精度が上がりません。
メカ屋は普段から、公差や接触不良という「物理の不確実性」を前提に現物を疑う訓練をされています。「動かない原因の8割は電源か機械的接触である」という物理層のセオリーを、AIの出す「論理の正しさ」に目を奪われて失念していたことが最初のスタックでした。
「出荷時点で既にブリンクしているLED」と「自分が書いたコードによるLED」をどう弁別する（異常に気づくための仕組みを仕込む）のか、そのイメージすら当時の私にはありませんでした。
電子ペーパーを動かすために配線とFWを往復
次に、電子ペーパーモジュールをマイコンボード上から動かすことにトライしました。
- AIに配線図を作ってもらい、その通りに配線
- ビルド→書き込み→動作確認を繰り返し
- AIの提案に沿って、配線や設定の確認ポイントを洗い出し
しかし、なかなか表示されず、数日トライしても改善が見えない状態が続きました。
ここで一度、モジュール側の生死判定を切り分けるために、「変数を1つだけ変えて再現性を確認する」という、メカの不具合解析における基本動作（装置差の分離）を試みることにしました。
別の環境としてRaspberry Piに同モジュールを接続し、AIにサンプルプログラムを準備させて動かしてみたところ、こちらは問題なく動作しました。「モジュール自体の故障ではない」と分かったわけです。モジュールは生きている。なのになぜnRF54L15では動かないのか。
学び：詰まったら“切り分け設計”を先にやる
不慣れ領域ほど、がむしゃらに修正を続けると沼にはまりやすいです。
AIに頼る場面でも、最初に
- 何が確定で、何が未確定か
- どの観測で真偽を判定するか
を整理し、最短で原因を狭める進め方が重要だと直感しました。
ネクストアクション：DK基板を購入する
最終的に、今回の試行錯誤だけでは原因を十分に切り分けられなかったため（AIの最終的な出力は「ブートローダーの相性問題の可能性がある」というものでした）、メーカー純正のDK基板を購入して再挑戦することにしました。
PoCでは「早く回す」ことが目的なので、個別の配線・電源まわりで沼る確率を下げる投資（DK基板の利用）は、結果的に最短ルートになり得ます。
メカ設計において「自作によってばらつきを抱えるコストがあるなら、実績のある標準品（治具）を使え」というのは鉄則です。
「これ以上はコードの問題ではなく、物理的な環境のばらつきである」と確信を持って、自作から標準品購入へ切り替える判断ができました。
AIにすべてを「丸投げ」するのではなく、自力でここまで一次切り分けを進めたからこそ、周囲の専門メンバーへバトンタッチする際にも「何が課題か」の相談の質を上げられたと感じています。
学ぶは真似ぶ
今回の一連のトライで一番大きかったのは、
- 不慣れな電気・FW寄りの作業でも、何から始めればよいかの見通しが立つ
- コマンド操作やビルド/書き込みなど、手を動かす心理的ハードルが下がる
- 詰まったときに、確認観点（チェックリスト）を言語化できる
といった、越境の最初の壁を越える助けになったことです。AIは単に“アウトプットそのもの”を生成するだけでなく、専門外の領域へ踏み出す人間のハードルを下げる上で、間違いなく強力なツールです。
ゼロベースで何かを成そうとすると、何から手を付けたら良いかわからなくなるものです。しかし、何か上達したい、スキルを身につけたいと考えた時、その「まねる対象」がすぐそばにある環境に自分を置けるかどうかは、学習の習得速度を左右する大きな要素なのだろうと思います。
もちろん、電源の確保や配線, 部品の個体差といった、現実世界（物理層）の不確実性を含む領域においては、AIの論理だけで完結することはありません。だからこそ、AIをすべての「丸投げ先」にするのではなく、対話を重ね、機序の理解を早く積み上げるための伴走者として使う。AIの思考プロセスを「真似ぶ」ことは、物事の上達における大きな力になります。
今後、エンジニアの素養がないような人もAIを携えてハードウェア開発に参入することが多くなると見込まれる中、広く浅くがめっぽう強いAIに最初のハードルを超えるのを手伝ってもらうこと。
趣味の世界もそうであるように、「最強の入門キット」で満足できなくなってから専用ツールを買い揃えるという順序が、結局は覚えが早いのかもしれないと、改めて思っているところです。
私はまだ素人のままだが
ソフトウェア領域に関してはずぶの素人の私だが、少なくともターミナルに触れることへの抵抗感は以前より確実に減ったと思います。
ターミナルなんてプライベートでは ipconfig を打つくらいにしか使ったことがなかった。基本である ls コマンドや cd コマンドも、学びはしても定着せずに記憶を上滑るだけだった。
AIの力を借りることで、やっとPCをPCとして使えるようになる一歩を踏み出したのかなと感じています。
