Python で考えて、
AI に翻訳させる。

基板を相手にするときも、思考は Python の側に置く。

2-13: 図と資料を作る ── Mermaid・Marp・そのほかの道具で、センサの筐体を Build123d のコードで設計し、その日のうちに 3D プリンタで刷るところまで来た。刷った筐体の中には基板が入り、基板にはセンサが繋がり、測った値はネットワークを通って手元に戻ってくる。この章では、その一続きを作る。部品を買ってブレッドボードに組み、ロジックを PC の Python で確かめ、動くと分かってから必要な部分だけ C や Rust へ翻訳させ、集めた値を手元の置き場に積むところまでを見る。

この章は、そのまま AI に渡す最初の仕様書として読める。決めるのは四つだ ── どの基板を選ぶか、何の言語で書くか、値をどこに置くか、どこまでを自分の手元に持つか。コードの書き方は AI が知っている。人が渡すのは、この四つの答えのほうだ。

難しいのは、ロジックとハードウェアが混ざることだ

組み込みのコードを書いた人は、どこで時間が溶けるかを知っている。

• 実機に焼き込むまで、動作を確かめられない
• ハードウェアのデバッグは、PC のデバッグより、はるかに時間がかかる
• print を一つ出すのに UART を設定する
• メモリが足りない、バッファが溢れる、タイミングがずれる
• 一行直すたびに、ファームウェアを焼き直す

ロジックの間違いと、ハードウェアの不安定さが混ざる。動かないときに、原因がコードか、配線か、電源かを切り分けられない。組み込み開発が遅かった一番の理由は、ここにある。

最初に書くのは Python だ

新しい組み込みの仕事で、最初に書くのは Python になる。

センサから値を読み、フィルタをかけ、判定する ── この処理を実機ではなく PC で書く。サンプルデータを JSON で用意し、Python で読み込み、フィルタを通し、判定結果を出す。

def detect_anomaly(values):          # 判定はこの数行に収まる
    avg = sum(values) / len(values)
    return any(abs(v - avg) > 3 for v in values[-10:])

このコードは PC で動く。一秒で終わる。グラフを描いて目で確かめられる。テストデータを差し替えて、何度でも回せる。残りは、サンプルの JSON を読んで、この関数に渡して、結果を出すだけだ。そこは AI が書く。

ロジックが正しいかどうかを、ハードウェアと切り離して確かめられる。

翻訳は AI に任せる

ロジックが Python で動いたら、それを C に翻訳する。

頼むときに、人が決めて渡すのは次のあたりになる。翻訳のコード自体は AI が書く。

• 翻訳先 ── Arduino で動く C++ か、embassy の Rust か
• 配列は固定長にする(長さも決めて渡す)
• 使う数値の型(float か int か)
• 関数が返す形(判定なら真偽値)
• 割り込みの中で動くかどうか

返ってきたコードを実機に書き込んで動かす。ロジックは Python で確かめてあるので、*実機で動かないなら原因はハードウェアの側にある*。デバッグの向きが定まる。

言語は、ハードウェアではなく開発フェーズで決める

組み込みの言語は、ハードウェアごとに決めるのではなく、開発フェーズと用途で決める。最初は Python、性能が要るときに Rust、C と C++ は既存のものを扱うとき ── これが AI ネイティブな組み込みの作法になる。

第一選択肢は、ハードウェアが許すなら MicroPython または Python。性能や容量で Python が届かないときに Rust を選ぶ ── Rust は型と所有権の検査がコンパイル時にあるので、AI が書いたコードの誤りがコンパイルで止まる。C と C++ は、既存資産の保守と認証済みコードを扱うときに使う。新規に C や C++ を選ぶ場面は、ここまで狭くなっている。

Raspberry Pi クラスなら、最終形も Python のままで足りることが多い。Python のまま動かせるなら、翻訳は要らない。エッジ AI や画像処理で性能が要る部分だけを、C / Rust の拡張モジュールにする(pybind11、PyO3)── これも AI が書ける。

五段階で進める

上の表は静的な選択肢で、実際の開発は段階的に進む。

1. 設計とプロトタイプ ── AI と対話しながら、PC の Python で動作確認。データ取得、アルゴリズム、AI モデルの動作を PC で確かめる。
2. マイコンへの移植 ── MicroPython 版への翻訳を頼む。ESP32 や RP2040 で動かす。多くの IoT・センサー用途は、ここで完結する。
3. 性能ボトルネックの特定 ── 動かして測る。リアルタイム性能が足りない箇所、メモリが厳しい箇所を見つける。
4. ホットスポットの Rust 化 ── ボトルネックだけ、Rust 化を頼む。MicroPython と Rust を組み合わせるか、全体を Rust + embassy / RTIC で書き直すかを決める。
5. エッジ AI が要るとき ── Raspberry Pi(Linux)上で、Python + C/Rust 拡張で動かす。マイコンより一段上のハードウェアを使う。

大事なのは、最初から Rust や C で書き始めないこと だ。Python でロジックを確かめてから、必要な部分だけ翻訳する。2-04: 処理を書く ── Python と Flet で、自分の道具を持つ で Excel の中の処理を Python に出したのと、同じ手をハードウェアに使っている。AI が翻訳を担うので、人が複数の言語を行き来する手間は残らない。

MicroPython なら、書き換えの往復が短い

ESP32 や RP2040 のような小型マイコンでは、MicroPython が動く。Python のサブセットだ。

PC で書いた Python を、ほぼそのままマイコンに転送できる。コンパイルが要らず、転送は数秒で終わる。デバッグの感覚も PC と同じだ。

MicroPython の制約 ── メモリ、速度、使えるライブラリ ── にぶつかったら、その部分だけを C に翻訳する。全部を翻訳する必要は無い。Python のまま残せる部分は、そのまま残す。

作るものは、市販のボードとモジュールの組み合わせだ

電子工作の側から見ると、いま作るものはほとんどが組み合わせでできている。

• 開発ボード ── ESP32、RP2040、Raspberry Pi のような、電源と通信と書き込み口が載った板
• センサモジュール ── 温度、湿度、土壌水分、照度、距離、加速度。素子とその周辺回路が小さな板に載っている
• 出力モジュール ── 表示器、リレー、モータードライバ
• 繋ぐもの ── ブレッドボード、ジャンパ線、USB ケーブル

回路を設計するのではなく、どのモジュールをどのピンに繋ぐかを決める作業になる。抵抗の計算やレベル変換が要る場面は残るが、そこは回路図とデータシートを AI に読ませる ── 次の節で扱う。

ブレッドボードで試し、基板に移す

最初はブレッドボードで組む。差して抜くだけなので、繋ぎ方を何度でも変えられる。ここでセンサの値が出るところまで確かめる。

繋ぎ方が決まったら、常設の形に移す。ユニバーサル基板にはんだ付けするか、基板の設計データを起こして製造に出す。ブレッドボードのままでも動くが、線が抜けたり、接触が不安定になったりする。畑や工場に置くもの、電源を入れたまま放っておくものは、はんだ付けまで進めておくほうが後が楽だ。

はんだ付けが要る所と、要らない所

はんだごてが要らない範囲は、思っているより広い。

• ピンヘッダが最初から付いているモジュールを、ブレッドボードとジャンパ線で繋ぐ ── はんだ付けは要らない
• ねじ端子やコネクタで繋ぐモジュール ── 要らない
• ピンヘッダの付いていないモジュールに、ピンを立てる ── ここで要る
• ユニバーサル基板に部品を固定して常設する ── ここで要る
• 電線どうしを繋ぐ ── はんだ付けか、圧着の工具が要る

試作の段階では、はんだ付けを後回しにできる。動くと分かってから、固める。

筐体は、前章の CAD から続く

基板が動いたら、入れ物が要る。2-13 の Build123d や OpenSCAD で、基板の寸法、取り付けねじ穴、ケーブルの通し口、放熱のスリットを書いて、3D プリンタで刷る。寸法が合わなければ数字を直して刷り直す。センサの筐体は、ここで自分の手に戻ってくる。

防水や防塵が要る場所では、市販の防水ケースを買って穴を開けるほうが早い場面もある。屋外に置くもの、水が掛かるもの、高い電圧を扱うものは、感電と火災の危険がある。商用電源側を扱う工事には資格が要る。低圧の直流側 ── 電池や USB 電源で動く範囲 ── から始めて、交流側は資格を持つ人に任せる。

部品と道具は、通販で揃う

部品は、電子部品の通販と、ボードを出している側の販売店で買える。開発ボード、センサモジュール、ブレッドボード、ジャンパ線、USB ケーブル ── これらは在庫として置かれていて、数日で届く。はんだごてとテスターは、最初に一つずつ買えば長く使える。

値段の構造は、後の農家の例で出てくる。市販の IoT 機器は 1 台ごとの値段で買うが、ESP32 とセンサを自分で組めば部品代だけになる。同じ場所に何ヶ所も置くときほど、この差が効く。

買う前に、型番を AI に確かめさせるとよい。「このセンサは 3.3V で動くか」「このボードにそのまま挿さるか」「必要な部品を一覧にして」── 手元に届いてから足りないものに気づく回数が減る。

回路図とデータシートも、AI に読ませる

回路図、配線、データシート ── これらの読み解きも AI に頼める。

「この OLED 表示モジュールを ESP32 に繋ぎたい。配線とコードを教えて」と頼めば、ピン配置、ライブラリ、初期化コード、表示コードが返ってくる。

データシートが PDF なら、テキストにして渡せば「このセンサのレジスタ 0x21 は何か」に答える。ハードウェアの知識も AI が持っている。

ただし、実機を動かす側には気をつける点がある。ファームウェアの書き込み中に電源が落ちると、基板の復旧に手が要る。ブートローダやヒューズの設定を書き換える操作は、一度きりで戻せないものがある。リレーやバルブやモーターを動かすコードは、人が居るところで、電源を入れる前に読む。これらは後の「人が持つ物」にまとめる。

測った値を、どこへ流すか

基板が値を測れるようになったら、次はその値の行き先を決める。ここが IoT の側だ。

まず、繋ぎ方を選ぶ。

畑や倉庫のように電源も LAN も届かない場所では、LoRa で母屋まで飛ばし、母屋の機械から先は Wi-Fi か有線にする、という組み合わせになる。値を送る間隔も、ここで決める ── 1 分ごとに記録し、10 分ごとにまとめて送る、という形にすれば、電池が長くもつ。

次に、送った先での扱いを決める。ここから先は、この連載で既に立てた道具がそのまま使える。

1. 基板が JSON を送る ── SD カードに 1 分ごとに記録し、10 分ごとにまとめて送る
2. 受け口は FastAPI ── 値を受け取る口を一つ立てる。届いた JSON の形を確かめてから通す(2-12)
3. 保存は 2-03 の置き場 ── SQLite か PostgreSQL に入れ、貯まった分を Parquet に落とす
4. 読み出しも同じ FastAPI ── 期間と地点を指定して返す口を、隣に足す
5. 画面は 2-04 の Flet ── 現場ではタブレット、事務所ではブラウザ。日別のグラフだけなら Altair の HTML でも足りる

業者のクラウドに送る代わりに、自分の機械に送る。受け口と読み出し口を FastAPI に揃えておくと、基板が増えても、画面が増えても、足すのは口を一つだけになる。値は手元に残り、月額の契約も要らない。

ここで気をつける点が一つある。基板を外から届く場所に置くときは、入口を開けたままにしない。基板から手元の機械へ送る向きだけにして、外から基板を呼び出せる口は閉じておく。既定のままのパスワードや、認証なしで開く管理画面は、そのまま侵入口になる。認証の立て方は 2-05: 門番を立てる ── PocketBase で認証を一つににある。

取れたデータの分析も、Python で続く

値が手元に貯まったら、その分析も Python でやる。

2-03: 土台を据える ── SQLite・PostgreSQL・pgvector・DuckDB・Polars の置き場から読み出し、polars で集計、matplotlib / altair でグラフ、numpy で数値処理。基板の側で書いた JSON と、PC の側で読む Polars が、同じ列の名前で繋がる。

「センサが温度を 1 分ごとに記録している。この JSON から、1 日のうちで温度が急に上がった時間帯を見つけて、グラフにして」と頼めば、コードが返ってくる。

組み込みの本体が C で動いていても、その周辺 ── 検証、分析、可視化 ── は Python と AI で動く。これが新しい組み込み開発のかたちだ。

例: 室温モニターは、三段階で立つ

具体例を一つ。ESP32 で室温を測り、30 度を超えたら通知する。

第一段階(PC で Python)。ロジックを Python で書く。サンプルの温度データ(JSON)を用意し、判定処理を書く。しきい値の調整、ノイズ除去、通知の条件 ── すべて PC で実験する。ここで人が決めるのは、判定の中身だ ── 「直近 5 分の平均が 30 度を超えたら通知する」。この一行が決まれば、Python は AI が書く。

第二段階(MicroPython で実機)。Python のロジックを MicroPython に転送する。 MicroPython は Python のサブセットなので、ほぼそのまま動く。温度センサ(DHT22 など)を繋ぎ、本物のデータで動かす。

第三段階(必要なら C に翻訳)。電池で長く動かしたい、メモリが厳しい ── そのときに C へ翻訳する。AI に頼めば翻訳が出てくる。

多くの場合、第二段階で終わる。MicroPython で十分に動く。

例: 農家の畑センサネットワーク

別の例。農家 B さん。畑の数箇所に、土壌水分・温度・日射のセンサを置きたい。市販品は 1 台ごとの値段で、データは業者のクラウドに集まる。

第一段階(PC で Python)。過去の気象データで、灌水判定のロジックを書く。「日射 ○ Wh/m² 以上 + 土壌水分 △ % 未満が 3 時間続いたら灌水推奨」── これを Polars で過去データに当て、しきい値を調整する。初版は AI が書く。

第二段階(MicroPython で実機)。ESP32 + センサに、上のロジックを移植する。MicroPython なので、PC のコードがほぼそのまま動く。SD カードに JSON で 1 分ごとに記録する。

第三段階(母屋の一台に集約)。B さんの母屋に一台を置く (2-02: AI に PC を一台渡す ── 自立編を動かす機械の機械をそのまま使ってもよい)。ESP32 が 10 分ごとに JSON を送り、その一台の FastAPI が受けて、 SQLite に入れ、貯まった分を Parquet に落とす。日別グラフは Altair、異常検出の履歴は SQLite。

第四段階(自動灌水アクチュエータの設計)。ソレノイドバルブを動かす筐体を、2-13 の Build123d で設計し、3D プリンタで刷る。ESP32 のリレー出力でバルブを開閉し、Python の制御コードは、MicroPython のメモリで足りないときだけ AI に C へ翻訳させる。

結果はこうなる。1 ヶ所あたり部品代だけで何ヶ所にも置け、データは自分のもの、業者のクラウドの月額も要らない。判定ロジックは Markdown で読め、故障したら 3D プリンタで部品を刷り直して自分で直せる。

ここまでの章の道具立てが、一つの作品にまとまっている ── 2-04 の Python と Flet、2-13 の CAD、2-03 の Parquet、そして 2-12: API を作る ── FastAPI で基幹のロジックを出すの FastAPI が、受け口と読み出し口の両方を担う。

二十年物のラダーが、Python になる

C は 1970 年代から、Python は 1990 年代から動いていて、この先も動く。

業界ごとの独自言語(古い PLC のラダー、車載の特殊規格)に閉じ込められてきた組み込みの知識を、 Python と C と Markdown の側へ出していく。特定ベンダーの形式から、時間を超える形式へ移す作業だ。長く続く仕事だが、毎日少しずつ進められる。

差が出るのは、一回の往復の長さだ。C++ で書き始めると、直すたびにコンパイルして実機に焼き直す ── 一回が分の単位になる。MicroPython なら転送は秒で済み、PC の Python ならシミュレーションは一瞬だ。往復が短いほど、試す回数が増え、判定の中身が早く固まる。

そして、この章で一番大きい例。産業用 PLC のラダー言語で書かれた二十年前の制御ロジックがあり、書いた担当者が引退して、社内に読める人が残っていない。AI にラダーを読ませ、Python に翻訳し、Markdown で意味を書き起こす。人手で読み解くなら終わりが見えない仕事が、読める形になって戻ってくる。

センサデータの可視化も同じ形になる。自前で Web ダッシュボードを一から組む代わりに、 matplotlib の plot() 一行に「これを HTML レポートにして」を足せば、実用になる。

工作が好きな人が、ソフトウェアを書く側に入る

この章の内容には、もう一つの意味がある。

3-06: 各社がビルダーを雇用する時代で、ビルダーの供給源はコーダー出身者だけではない、という話をする。工場や町工場の技術者、電子工作をやってきた人、Maker Faire に出てきた人 ── 物を作る経験を持つ人が、ソフトウェアを書く側に入ってくる、と。

その技術的な裏づけが、この章だ。Raspberry Pi と ESP32、MicroPython、そして AI による回路・制御コードの生成。この三つが揃ったので、入口にあった学習コストが下がった。何を作るかを決めた経験、動かないときに切り分けた経験、部品を組み合わせて構造を分ける経験 ── 工作をやってきた人は、ビルダーに要る資質をすでに持っている。足りていなかったのは、コードを書く手だけだった。その手を、AI が貸す。

確かめ方

この章は、次の六つができていれば済みだ。

1. PC の Python が、サンプルデータの JSON を読んで、判定結果を一つ返す
2. ブレッドボードに組んだ基板に MicroPython でプログラムを書き込むと、LED が点くか、REPL に値が出る
3. センサを繋いだ基板が実測値を 1 分ごとに記録し、その記録を PC の Python が読める
4. 基板が測った値がネットワークを通って手元の機械に届き、2-03 の置き場に積まれて、期間を指定して読み出せる
5. 翻訳した C か Rust を書き込んだ基板が、Python と同じ判定を返す
6. 3D プリンタで刷った筐体に基板を収め、電源を入れ直しても同じ値が返る

# 基板に入っている MicroPython に、手元のファイルを送って動かす(mpremote は uv tool install で入る)
mpremote connect auto fs cp main.py :main.py
mpremote connect auto run main.py

人が持つ物

人が渡す値

• 判定のしきい値(例 直近 5 分の平均が 30 度、日射と土壌水分の組み合わせ)
• 買う部品の一覧 ── 開発ボード、センサモジュール、繋ぐもの ── と、かけてよい金額
• センサの型番と、繋ぐピンの番号
• 繋ぎ方(Wi-Fi、BLE、LoRa、有線、携帯回線)と、値の行き先の機械
• 記録の間隔(例 1 分ごと)と、送信の間隔(例 10 分ごと)
• 電源の条件(電池か常時給電か)と、動かし続ける期間
• どこまでを Python のまま残し、どこから C / Rust に翻訳するかの線

AI が「やる前に言う」操作

• 基板にファームウェアを書き込む(書き込み中に電源が落ちると、復旧の手が要る)
• ブートローダやヒューズの設定を書き換える(戻せないものがある)
• 実機のアクチュエータ ── リレー、バルブ、モーター ── を動かす
• 記録済みのログや SD カードの中身を消す、上書きする
• 基板を外から呼び出せる口を開ける、認証なしの管理画面を有効にする

確かめた版と日付

• ESP32、RP2040、STM32、Raspberry Pi、Jetson、Arduino、DHT22 ── 版は指定していない
• MicroPython、Rust(embassy / RTIC)、pybind11、PyO3 ── 版は指定していない
• mpremote(PyPI、uv tool install)、esptool(Debian 13 のパッケージ 4.7)
• Polars、matplotlib、Altair、SQLite、Parquet、FastAPI、Flet ── 版は指定していない
• 部品の値段は本文に書いていない。買う前に現在の価格を確かめる
• 手順を書いたのは 2026-09-21、見直したのは 2026-10-06
• 版が上がっていたら、AI に公式の手順を確かめさせてから進める

まとめ

基板を相手にするときも、思考は Python で。

• ハードウェアと切り離す ── ロジックを PC の Python で確かめる。実機で動かないなら、原因はハードウェアの側にある
• 組み合わせて作る ── 市販のボードとモジュールをブレッドボードで試し、動いてからはんだ付けと筐体で固める。筐体は 2-13 の CAD で刷る
• 開発フェーズで言語を決める ── Python から MicroPython、性能が要るときに Rust。C と C++ は既存資産を扱うときに使う
• 五段階で進める ── 設計、移植、測定、ホットスポットの Rust 化、必要ならエッジ AI へ。多くの IoT は二段目で止まる
• 値の行き先を決める ── 繋ぎ方を場所で選び、2-03 に積み、2-12 の API で出し、2-04 の Flet で画面にする。値は手元に残る
• 知識を時間を超える形式へ ── 二十年物の PLC ラダーが、読ませて翻訳して書き起こすと Python と Markdown になる

道具はここで揃った。土台、門番、文書、コード、メール、会議、Web、API、図、そして基板と、そこから流れてくる値まで。次章では、その上を流れる情報そのものを整える。共有フォルダの底のファイル、紙とスキャン PDF、そして人の頭の中にしかない知 ── これを書かれた形に移す。

関連記事

• 2-13: 図と資料を作る ── Mermaid・Marp・そのほかの道具
• 2-04: 処理を書く ── Python と Flet で、自分の道具を持つ
• 2-03: 土台を据える ── SQLite・PostgreSQL・pgvector・DuckDB・Polars
• 2-15: 社内情報を整える ── 整備こそ本体、AI は最後の一手
• 3-06: 各社がビルダーを雇用する時代