Webアプリは一発で動くのに、ESP32の実装ではエージェントごとに結果が大きく分かれる。
本記事では、MakeUseOfのYadullah Abidi氏がESP32・DHT22温湿度センサー・SH1106 OLED・プッシュボタンを使ったダッシュボード制作で、Claude Code・OpenAI Codex・Google Antigravityを同じプロンプトで比較した検証結果を整理します。埋め込み開発やHome Assistant連携を検討している読者向けに、各ツールの得意不得意と選び方の目安を示します。
この記事でわかること
- 3つのエージェントに課したESP32ダッシュボードの要件
- Antigravity・Codex・Claude Codeがそれぞれ取った実装アプローチ
- 動くプロトタイプまで到達できたのはどれか、その理由
- 自分のプロジェクトに合うエージェントの選び方
課題は「3機能を1枚のボードで回す」こと
Abidi氏の動機は、Claude Codeの利用枠を小さなアイコンで確認する手間を減らすことでした。ESP32にSH1106 OLED（128×64モノクロ）とDHT22温湿度センサー、4ピンプッシュボタンを接続し、ボタンで表示モードを切り替えるダッシュボードを作ります。
3つのエージェントには、次の同一プロンプトを渡しました。
- Claudeプランの利用枠を表示する
- DHT22の温湿度を表示し、Home Assistantへも送信する
- ニューデリーの外気温・天気を表示する
目標は、できるだけ少ないプロンプトで3要件を満たす動くプロトタイプに到達することです。Web開発のベンチマークでは測れない、センサー・API・スマートホーム連携が絡む実装力の差がここで出ます。
Antigravityは計画が長く、コードは後から
Google Antigravity（Gemini 3.1 Pro・High effort）を最初に試した結果、プロンプト直後にAnthropic APIの利用枠取得方法をWeb検索し、実装計画と確認質問を提示しました。CodexとClaude CodeがすでにESP32へ書き込める初版コードを出している一方、Antigravityはコードを1行も書かず、計画の承認を求めました。
2回目の計画では、AnthropicにClaude Pro利用枠を取得する公式APIはないと明言。温湿度はESPHomeを使わず、Home AssistantのREST APIで送る方針を示しました。ここでAbidi氏がGitHubのClawdmeterリポジトリ（Hermann Björgvin作）のリンクを渡すと、Claude CLIのOAuthトークンとベータAPIエンドポイントで利用枠を取れると判断。それでも3つ目の実装計画の承認までコードは出ませんでした。
承認後はPlatformIOプロジェクトを約2分で生成。Wi-Fi認証情報とOAuthトークンを本体コードから分離する構成はセキュリティ上は正しい一方、ローカルネットワーク専用のガジェットには過剰です。Arduino IDE初心者にとって、想定の1ファイルではなく多数のファイルが並ぶ点も負担になります。配線図もなく、動作まで手動パッチとデバッグが必要でした。総合では2位と評価されています。
CodexはESPHomeに固執し、要件から外れた
OpenAI Codex（GPT 5.5・High effort）は、受け取ってから約3分でYAMLファイル2つを出力しました。ただし方向性はESP32をESPHomeのセンサーとしてHome Assistantに登録する案で、温湿度センサー単体なら合理的でも、OLED表示と天気API・利用枠表示を同時に担うボードには合いません。
利用枠については公式APIがないと指摘しつつ、input_number.claude_plan_usage_percentというHome Assistantの手動入力値で代用する案を出しました。Clawdmeterのリンクを渡してもESPHome路線をやめず、手動数値の延長でClawdmeter風ブリッジを足す次のステップを提案。配線図は分かりやすかったものの、YAML中心の迂回が続き、自分で書いた方が早いとAbidi氏は述べています。
Claude Codeは1つのINOで3機能を実装
Claude Code（Sonnet 4.6・High effort）は起動直後、サーバー負荷によるmodel overloaded警告が出て最も遅いスタートでした。それでも初版からArduino IDE用の単一INOファイルを生成し、3要件をまとめて処理しました。
利用枠取得は、HaikuへPOST /v1/messages（max_tokens: 1）を送り、レスポンスヘッダーのanthropic-ratelimit-*から現在ウィンドウの残リクエスト数・トークン数を読む方法です。月間トークン消費量は含まれない点も明示しました。Clawdmeterを渡すとOAuthトークン取得手順付きで即座にスケッチを更新。温湿度はAntigravityと同様REST APIでHome Assistantへ送りつつ、サーバー再起動後に値が残らない点と、MQTT連携の選択肢も説明しました。
配線図とフラッシュ可能な1ファイルが揃い、Abidi氏の用途では唯一すぐ使えた結果でした。長期利用でボード在庫やHome AssistantのIPを記憶している点も、編集箇所を減らす要因になっています。
埋め込み開発で見える「コード生成」と「問題理解」の差
Abidi氏の結論は、3つとも最終的には動かせるが、手直しの量が大きく違うというものです。Antigravityは文脈が揃えば速く、正確さも狙えるが、今回は計画偏重と過剰な構成がネックでした。Codexはドキュメントの厚いESPHomeに寄り、タスク全体の構造変更を避けました。複数サブシステムが制約のあるハードウェア上で協調する案件では、Claude Codeの慎重だがシンプルな1ファイル案が唯一ゴールまで届きました。
選定の目安は次のとおりです。
- 初回からフラッシュ可能なファームウェアが欲しい → Claude Code
- 計画の丁寧さとPlatformIO構成を重視し、手直しを許容する → Antigravity
- Home Assistant中心のセンサー専用機なら → CodexのESPHome案は選択肢になるが、多機能ボードには不向き
ベンチマークスコアだけでは測れない領域として、ESP32のようなIoT実装を試す価値があります。普段使うエージェントに蓄積したコンテキストも、今回のように配線やIP設定の省略につながる点は見逃せません。
ハードウェアと参考リポジトリ
使用部品はESP32 Devkit V1、DHT22、SH1106 128×64 OLED、4ピンプッシュボタンです。ケースはBlenderで設計し3Dプリントしたとのこと。利用枠取得のヒントになったClawdmeterは、OAuthトークンからAnthropic APIを叩き、BLE経由でESP32のディスプレイに利用率を送るOSSプロジェクトです（GitHub）。
検証の詳細はAbidi氏の原文にまとまっています（参考）。