停電しても、ネットが落ちても、山の中でも動く。そういう装置を作りたかった。
ハードが作りたいというのがあった。
世の中のスマートホーム製品は、たいていインターネットとクラウドを経由する。だから災害時に真っ先に死ぬ。見守りや防犯みたいに「困ったときにこそ動いてほしいもの」が、困ったときに動かない。これはおかしいんじゃないか、と思っていた。
結論から言うと、1日でできた。ルーターもWi-Fiのパスワードもクラウドも、一切使っていない。マイコン2枚が、直接会話している。
そして今日いちばん面白かったのは、設計を、別のAIに外注したことだった。
別のAIに、設計だけを頼んだ
僕が普段使っているのは Claude Code の Opus 4.8。そこにもう一つ、Fable 5 という別のモデルがある。深い設計や分析が得意だと言われている。
僕は「Fableでやろう」と言っただけだ。そこから起きたことは、こうだった。
僕
│ 「fableでやろう」
▼
Opus 4.8（いつも話している）
│ 仕様書を書いて依頼
▼
Fable 5（別のAI・別プロセスで起動）
│ 設計書2本を書いて返す
▼
Opus 4.8 が受け取って、実装・配線・デバッグ
モデルを切り替えたのではない。 Opus 4.8 が、自分とは別のAIを呼び出して、仕事を投げた。これは「サブエージェント」という仕組みで、得意分野の違うAIに、得意な仕事をさせられる。
ここで一番大事だったのは、Fableは僕たちの会話を一切知らないということだった。ゼロから立ち上がるので、何も文脈がない。だからOpusは、依頼文の中に全部書き出した。
手元にある部品の全リスト（買い足さない前提）
絶対条件（サーバーを使うな。ルーターも使うな）
禁止事項（「命を守る」と名乗るな。医療機器を名乗るな）
設計の判定基準（6つ目のモードを他人が書けるか）
引き継ぎの質が、そのまま成果物の質になった。 これは人に仕事を頼むときと、まったく同じだ。
そして返ってきた設計が、良かった。
「コアはインタープリタ、モードはデータ」
Fableが書いた設計の1行目が、これだった。
普通に作ると、こうなる。
見守りモードのコード
防犯モードのコード ← それぞれ別々に書く
労働安全モードのコード
Fableはそうしなかった。コアは8つの「語彙」しか知らない、という作りにした。
しきい値を超えた ／ 急に変化した ／ バタついた回数
何も起きていない ／ 電波が途絶えた ／ 夜間だけ ……
そして、個別のモードはこの語彙で書かれた「設定表」にすぎない。コアは福祉も防犯も労働安全も知らない。新しいモードは、コードを1行も書かずに追加できる。
実際Fableは、僕が頼んだ3つのモードに加えて、自分で考えた2つのモード（温度の逸脱監視、独居者の「生活反応がないこと」の検知）を同じ設定表で書いてみせた。汎用性を、自分で証明した。
これがどういうことか、後から効いてくる。
実際に動いたもの
1. ルーターなしで、マイコン同士が直接話す
ESP32というマイコンには、Wi-Fiとは別に ESP-NOW という通信方式がある。ルーターを経由せず、機械同士が直接電波を飛ばす。Wi-Fiのパスワードすら設定していない。
2枚をUSBで給電しただけで、会話が始まった。片方をPCから抜いて、ただの充電器に挿しても、平然と喋り続けていた。インターネットが要らないというのは、こういうことだった。
2. 「沈黙」を検知する
これがこの設計の核心だと思う。
普通、センサーは「何かが起きたこと」を検知する。でもFableの設計は、「何も来なくなったこと」自体をイベントとして扱う。
相手が0.5秒ごとに「生きてるよ」と言い続ける
↓
3秒間、何も聞こえなくなった
↓
「分からなくなった」と判定する
USBを抜くと、3秒後にもう1枚のLEDが高速点滅を始めた。挿し直すと、勝手に元に戻った。再起動もペアリングもボタン操作もいらない。
ここで大事なのは、これが「異常が起きた」ではないということ。相手が倒れたのか、電池が切れたのか、遠くへ行きすぎたのか、受信側からは区別がつかない。だからこの通知の意味は「分からなくなった」であって、それ以上でも以下でもない。設計書はそこをはっきり書いていた。この誠実さが、僕は好きだ。
3. 揺れを検知して、猶予を置いて、人間が取り消せる
傾きセンサー（SW-520D）を繋いだ。金属のボールが転がって接点が開閉する、ただそれだけの部品だ。
これは加速度センサーではない。転倒を正確に検知することは、原理的にできない。 装着の向き次第では、倒れても何も起きない。逆にポケットの中で寝返りひとつで発火する。
だからFableの設計は、こうなっていた。
揺れを検知 → すぐには通報しない
↓
猶予10秒。ブザーが鳴り出す（本人に予告する）
↓
残り時間が減るほど、ビープが速くなる
↓
ボタンを押せば → 取り消し。何も起きない
押さなければ → もう1枚に通報。鳴り続ける
誤検知はバグではなく、仕様。 だから「誤報を人間が握りつぶせる」ことを、設計の核に据える。取り消せない設計は、この基盤では書けないようになっている。
実際に動かすと、これがすごく腑に落ちる。ブザーが速くなっていく間、「押せば止まる」という安心感がある。技術じゃなくて、思想の部分だ。
4. 電波の強さで、距離が見える
おまけみたいに作ったこれが、いちばん「おおっ」となった。
無線のパケットには、電波の強さが乗っている。それを読むだけで、相手との距離が分かる。部品はゼロ。プログラムだけ。
実測してみた。
くっつける -1 dBm
手で握りこむ -47 dBm ← 手が電波を吸う
46 dBの差。dBは対数なので、電波の強さで言うと約4万倍違う。手で握るだけで、これだけ変わる。
これをLEDの明るさに繋いだ。近づけば明るく、離せば暗くなる。 距離が、目に見えるようになった。
つまずいたところ（ここが本題かもしれない）
きれいに書いたけど、実際は半日、配線で溶けた。
ブレッドボードが本当に分からなかった
あの白い、穴だらけの板。あれの「どの穴とどの穴が裏で繋がっているか」が、見えない。
同じ列（縦）の A・B・C・D・E は裏で繋がっている
でも溝を挟んだ F・G・H・I・J とは繋がっていない
端の「＋／−」の行は、横に繋がった別物
しかも僕のマイコンは幅が広くて、基板が穴を物理的に覆ってしまう。使える穴が片側1行しかない。「27番ピンの真下の穴に挿して」と言われても、その真下が基板の下敷きになっていて見えない。
AIは「GNDから右へ6本目です」と説明してくれる。でも目の前の基板の文字は小さくてかすれていて、数えられない。言葉と現物が噛み合わない時間が延々と続いた。
結局、ブレッドボードを捨てた
解決策は、拍子抜けするほど簡単だった。
マイコンをブレッドボードから引き抜いて、ピンに直接線を挿す。
ブレッドボードあり → 「どの穴がそのピンなのか」を数える
ブレッドボードなし → 文字が書いてあるピンに、直接かぶせる
両端が穴になっている線（メス-メスのジャンパー線）を使えば、マイコンの足に直接挿さる。列を数える作業が、まるごと消えた。
これで一気に進んだ。ブレッドボードは「部品をたくさん繋ぐときの土台」であって、部品が2〜3個なら、無い方が早い。
抵抗が読めない
LEDを繋ぐには抵抗が要る。でもキットの抵抗は、色の帯が薄くて読めないし、印字も雑だった。
危ないのは、間違えると壊れること。
220Ω・470Ω・1kΩ → ◎ LEDに使える
10Ω・100Ω → ✕✕ 小さすぎ。LEDとマイコンが壊れる
470kΩ → ✕ 大きすぎ。光らない
そして罠がある。「470」と「470K」は、1000倍違う。 Kが付いているかどうかだけで、まったく別物になる。
僕は結局「1K」と読めたものを使った。少し暗くなるが、安全側なので初心者にはむしろ良いらしい。
一度に3つ足して、全部壊した
これが一番の失敗だった。動いていた状態から、ブザーとボタンとGNDの配線を、一度に3つ足そうとした。
結果、それまで動いていた傾きセンサーの配線まで巻き込んで、全部繋がらなくなった。どこが悪いのか、もう分からない。
部品は1個ずつ足す。1個足すごとに動作確認する。 当たり前のことだけど、うまくいっている時ほど欲が出る。
いちばん効いた技：マイコンに自己申告させる
配線が分からなくなったとき、決定打になったのがこれだった。
「どのピンが、今GNDに繋がっているか」を、マイコン自身に喋らせる。
やり方はこうだ。全部のピンを「内部で軽く電圧を上げた状態」にしておく。線がGNDに繋がっているピンだけ、電圧が引き下げられる。それを読んで、報告させる。
目で穴を数える → 分からない。間違える。心が折れる
マイコンに聞く → 「今、33番が繋がっています」
これで一発だった。僕が狙っていた穴と、実際に繋がっていた穴が、4つズレていたことが判明した。目視では絶対に気づけなかった。
さらに進めて「どのピンとどのピンが線で繋がっているか」を総当たりで調べる道具も作った。配線図を、マイコン自身に復元させる。
これは電子工作全般で効く発想だと思う。見えないものを目で確認しようとせず、装置に喋らせる。
閾値は、勘で決めない
もう一つ、地味だけど大事だったこと。
傾きセンサーの「どれくらい揺れたら反応させるか」を決める必要がある。ここで勘に頼らず、実測した。
じっと静止 0〜2 （1秒あたりの信号の暴れ回数）
振る・傾ける 100〜700
100倍以上の差があった。だから「20を超えたら動いたと判定する」と決めた。静止時のノイズの10倍、動作時の5分の1。どちらからも十分に離れている。
この数字は、僕の部屋の、僕の部品で測った値だ。設計書に書いてある値ではなく、目の前の現物から出した値。 これがあるから、後で「なぜ20なのか」と聞かれても答えられる。
方針：まずエンタメ。人の安全に関わるものは、その先
作りながら、はっきりした方針が固まった。
見守り、防犯、労働安全。これらは外したときに、人の安全に直結する領域だ。だから薬機法や警備業法の話になるし、「検知できなかった責任」がついて回る。設計書も、そこを厳しく釘刺していた。
名乗ってよいこと 「気付くきっかけを増やすかもしれない装置」
名乗ってはいけない 「命を守る」「転倒を検知する」「医療機器」「防犯装置」
一方で、エンタメなら、外しても誰も傷つかない。
近づくと光る ← 今日、もう動いている
離れると鳴る ← これも動いている
二人の距離で振動が変わる ← 部品を足せばすぐ
同じハードウェア、同じコード。違うのは「責任の重さ」だけ。
だから順番はこうする。軽い方で先に世に出して、経験と信用を貯めてから、重い方へ行く。
そしてこれは、Fableの設計思想の証明でもある。カップル用の玩具と、独居老人の見守り装置は、まったく同じコードで動く。違うのは設定表1枚だけ。汎用性というのは、こういうことだった。
これから必要なもの
1. 買っておくといいもの（自分メモ）
テスター（マルチメーター） — 千円台から。これが一番効く。 抵抗値が読めない問題が永久に消える。当てるだけで値が出る。今日いちばん時間を溶かしたのがこれなので、最初に買うべきだった。
USBモバイルバッテリー — スマホ用のもので十分。これでPCから切り離せて、持ち歩ける装置になる。「災害時でも動く」を実演するなら必須。
振動モーターのモジュール — 数百円。「モジュール」と書いてあるものを買うこと。 生のモーターは、ハンダ付けとトランジスタ回路が必要になる（モーターは電流を食いすぎて、マイコンのピンに直結すると壊れる）。モジュールなら基板にその回路が載っていて、線を挿すだけで動く。
メス-メスのジャンパー線 — 多めに。ブレッドボードを使わない配線なら、これが主役になる。
2. 必要な知識
電気は「行って帰る」 — これが全部の土台だった。マイコンのピンから出て、部品を通って、GNDに帰る。GNDに帰れないと、何も動かない。 今日、ブザーもボタンも死んだのは、全部この一点が原因だった。
抵抗は「流れすぎ」を防ぐ栓 — LEDは抵抗なしで繋ぐと焼き切れる。値が大きいほど暗くなり、小さいほど明るく、そして危険。
ピンには限界がある — マイコンのピンが安全に流せるのは12mA程度。振動モーターは70mA食う。だから直結できない。 間にトランジスタ（力の弱いマイコンが、力持ちを操るスイッチ）を挟む。リレーも同じ理屈。
部品には向きがあるものと、ないものがある — LEDは向きがある（長い足が＋）。抵抗は向きがない。傾きセンサーも向きがない。
3. 必要な技術
ハンダ付け — 今日は一度も使わなかった。ここが意外だった。ジャンパー線で挿すだけで、全部動いた。
ハンダが必要になるのは、この2つのときだ。
小さくして完成品にするとき （試作から製品へ）
線が細くて挿さらない部品 （コイン型振動モーターなど）
つまり「動くものを作る」だけなら、ハンダは要らない。「持ち歩ける形にする」段階で初めて必要になる。
プログラム — これは正直、AIに任せられる。僕は一行も書いていない。ただし「何を作りたいか」と「何が起きているか」は、自分で言語化できないといけない。今日AIが役に立ったのは、僕が「鳴らない」「反応しない」と現物の状態を伝えられたからだ。
ここまでで、何ができるか
ハンダなし、Wi-Fiなし、今日の構成のままで、これだけできる。
距離で光る・鳴る・強さが変わる （電波の強さを読むだけ。部品ゼロ）
揺れ・傾きの検知
明るさの検知（光センサー。「夜だけ作動」などのスイッチに使える）
温度の検知
「相手が黙った」の検知
外部機器のON/OFF（リレー経由。サイレンやライトを起動できる）
電池で持ち歩く
これで作れるもの：迷子防止タグ、置き忘れ防止、二人の距離で反応する玩具、部屋に入ると光る演出、深夜の見回り補助、簡易な侵入通知。
ネットが要らないので、電波が届く範囲（見通しで100〜200m、屋内なら1〜2部屋）で完結する。 これは弱点でもあり、強みでもある。
4. その先：Wi-Fiとアプリ
今日はあえてWi-Fiを使わなかった。でも同じESP32に、Wi-Fiは最初から載っている。
Wi-Fiを繋ぐと、こうなる。
【今】 マイコン ⇄ マイコン （その場で完結）
【Wi-Fi】 マイコン → 家のルーター → インターネット → スマホ
↓
外出先から通知が受け取れる
履歴が残る／グラフになる
複数の家をまとめて見られる
できることが一気に増える。 でも同時に、失うものがはっきりある。
ネットが落ちると死ぬ
停電すると死ぬ（ルーターも電気で動くので）
サーバー代がかかり続ける
個人情報がクラウドに出ていく（「いつ動いたか」は生活情報だ）
だから僕は、Wi-Fiは「後から足すもの」であって、「土台にするもの」ではないと考えている。今日作ったものは、ネットが死んでも動く。その上に、余裕があればWi-Fiを乗せる。逆にはしない。
アプリまで行くなら、スマホから通知を受けたり、履歴を見たり、複数台を管理したりできる。ただしそこはサービス運営の世界で、電子工作とは別の仕事になる。急がなくていい。
免責
この記事は、僕（素人）が1日でやったことの記録です。
回路や配線の内容について、一切の責任を負いません。 電気を扱う以上、間違えれば部品が壊れますし、扱い方によっては発熱や発火の危険もあります。特に、
コンセントの電源（AC100V）を扱うこと
電池を短絡（ショート）させること
抵抗を入れずにLEDを繋ぐこと
これらは危険です。真似する場合は、必ずご自身で調べ、ご自身の責任で行ってください。
そして繰り返しますが、ここで作ったものは、人の安全を保証する装置ではありません。検知できないことが構造的にあります。誰かの安全を、これに預けてはいけません。
僕がやりたいのは、① まずエンタメを作る → ② その先で、役に立つものを作る、という順番です。①のうちに失敗して、学んでおきたい。
おわりに
一日でここまで来られたのは、設計を別のAIに投げ、実装を手元のAIとやり、詰まったところは装置自身に喋らせたからだと思う。
でも一番効いたのは、「勘で決めない」という態度だった。
閾値は実測から決めた。配線はマイコンに自己申告させた。分からないものを「たぶんこうだろう」で進めなかった。そして、できないことは「できない」と書いた。
転倒は検知できない。電池は数日しか保たない。電波は壁を越えると弱くなる。弱点を先に言えることが、たぶん一番の強みになる。
次は、これでエンタメを1つ作ろうと思う。
