https://github.com/fcavalcantirj/claude-code-eyes
AIに「現物確認」を渡したところが一番うまい
この実験で二度見したのは、Claude CodeがESP32のコードを書く部分ではない。そこはある程度想像できる。効いているのは、Webカメラ越しに実物の画面や配線を見せ、ログに出ないバグを拾わせようとしている点だ。
ソフトウェアだけなら、AIはエラー文、テスト結果、DOM、スクリーンショットを読める。だがESP32のような小さなハードウェアでは、失敗が急に物理側へ逃げる。画面が変な位置で切れている。配線が1本ズレている。電源を入れる前に見たほうがいい危ない状態がある。こういうものは、ログを何度読んでも出てこない。
そこにカメラを足すと、AIの役割が「コードを書く係」から「机の上を一緒に見る係」へ少し変わる。地味だが大きい。個人開発で一番つらいのは、相談相手がいないまま、現物とにらめっこする時間だからだ。
真似すべきは万能ロボット化ではなく、目だけ足す割り切り
この手の話は、すぐにAIがロボットアームで配線し、はんだ付けし、全部作る未来へ飛びがちだ。だがこのリポジトリのうまさは、そこまで行かないところにある。
公開情報から見る限り、やっているのは「Claude Codeにカメラで見える情報を渡す」方向の実験だ。手は人間のまま。AIには目を足す。この分担がいい。
個人がすぐ盗めるのは、この小さな分担だ。AIに全部やらせようとすると、途端に装置が大きくなる。画面を見せる、配線を見せる、完成品の状態を見せる。それだけなら、作業台の横にWebカメラを置けば始められる。AIエージェント開発で大事なのは、頭を良くすることだけではない。入力を増やすことだ。
ログに残らないバグを相手にできるのは強い
小さなWebアプリやゲームを作っていると、バグはだいたい画面に出る。ボタンがズレる。色が変。余白が気持ち悪い。コード上はエラーなし、テストも通る。人間なら一瞬で「ここ変だな」と分かるのに、AIにはその一瞬がない。
ESP32の表示パネルでも同じことが起きる。むしろもっと厄介だ。ブラウザならスクショを撮ればいいが、実機の小さな画面や配線は開発環境の中にない。AIに見せるには、外側の世界を入力として渡すしかない。
この発想はゲーム制作にもそのまま使える。Design、Code、Art、Reviewの4エージェントで小さな教材ゲームを作るとして、最後のReview役がログだけ見ていたら弱い。画面を見て「子ども向けなのに文字が小さい」「店員研修ゲームなのに選択肢が読みにくい」と言える目がいる。Webカメラでハードを見る話は、AI制作全般のレビュー役を強くする話でもある。
学校や店が払うのは、AI製ガジェットではなく確認済みの教材
この実験をそのまま商売にするなら、「Claude CodeでESP32を作れます」では弱い。払う側から見ると、それは作り手の都合に近い。学校、教室、地域店が欲しいのは、5分で使えて、壊れにくく、説明しやすい小さな教材や研修道具だ。
たとえば、店員研修用のミニ端末、理科教室のセンサー教材、子ども向けの反応ゲーム。こういうものをAIで量産する時、カメラ確認の価値が出る。コード生成よりも、納品前に「実機で見てもちゃんと読めるか」「配線が危なくないか」「画面表示が教材として成立しているか」を潰せるからだ。
自分なら、この技術を派手な自律制作デモには寄せない。白ラベルの研修ゲームや教室向けキットを作り、制作過程にカメラ確認エージェントを入れる。売り物はAIではなく、現物チェックまで済んだ小さな教材。そこまで落とすと、急に生活に近くなる。