AIとArduinoを使ったバイブコーディング
バイブコーディングはAI分野で人気のあるキーワードとなり、最近では様々な意味を持つようになりました。この記事では、実際のハードウェアをAIエージェントに接続してバイブコーディングがどのように機能するかをご紹介します。混乱を避けるために、バイブコーディングを「特定の望ましい結果を達成するためにAIエージェントと行き来するチャット」と定義します。通常は声によるものですが、この記事の目的のために、大規模言語モデル（LLM）に与えられた「話された」プロンプトを印刷します。Visual Studio CodeをCopilotのエージェントモードで使用し、コンピューターのUSBポート（この場合はMacBookに接続）にArduino Uno R4を接続します。
始めに
プロジェクトを始める人間と同じように、適切なコンテキストでAIエージェントをスタートさせることが重要です。このスクリーンショットでは、画面の中央にCopilotを搭載したVisual Studio Codeが動作しているのがわかります。
初期プロンプトに注目してください。「私はここにArduino Uno R4を接続しています。私のMacBookに。arduino-cliを使用して、通信して検証する必要があります。Arduinoが接続されていることを。」重要なキーワードをいくつか太字にしました。これを二つの部分に分けてみましょう。
私はここにArduino Uno R4を接続しています。私のMacBookに：まず、私が使用しているデバイスが何であるか、それが「ここ」に接続されていること、そしてMacBookを使用していることをLLMに正確に伝えています。もしかすると、私がMacOSを実行していることをすでに知っているかもしれませんが、余分なコンテキストを与えることに損はありません。たとえそれが環境からそのコンテキストを引き出せるとしても、別の検索が必要になる可能性があります—それを避けることができます。これらは、始めるために重要な情報です。
arduino-cliを使用して、通信して検証する必要があります。Arduinoが接続されていることを確認してください。具体的にどのツール/コマンドを使用するか指示しています（brewを使用してインストールしたarduino-cliパッケージ）。これにより、どのツールを使用するかを判断するための少なくとも（もしくは多くの）検索/呼び出しを避けるショートカットが再び作成されます。ツールが完全なタスクを与えられた場合に自身を正しく設定できるかどうかも疑問に思っているので、Arduinoと通信できることを確認してもらいます。これは些細なことのように思えるかもしれませんが、実際のタスクから離れてこれを確認することで、コードの記述を開始する一度準備が整ったことを確実にするのに非常に役立ちます。
その応答は、すぐにarduino-cliコマンドを実行することです（まず位置を探してから）、Arduinoツールとボードへの通信が適切に設定されていることを確認します。すべてが正常に動作していることを確認したら、次の一連の指示を出す準備ができていますが、基本的なスケッチを作成し、基本的なプログラムをデバイスにアップロードできることを確認することで、私の先を越してきます：
ログにあるように、Copilot Agentがいくつかの問題に遭遇しています。心配無用です - エージェントワークフローの美しい側面の一つは、エラー出力を見て自己修復することができる点です。最終的には、それが成功し、コンパイルされたスケッチをArduino Uno R4デバイスに正常にアップロードします。
フィードバック付きのVibeコーディング
ウェブアプリケーションの一般的なビブラコーディングに関して言えば、エージェントがフィードバックを得るのはかなり簡単です。エージェントがコマンドラインにアクセスできると仮定すると（私たちの場合はアクセスできます）、スクリプトが完了した後にアプリケーションからフィードバックを提供させることができます。たとえば、エージェントにCSVファイルを読み込んで、その内容をマークダウンテーブルに変換し、その内容を.mdファイルに書き込むアプリケーションを作成するよう依頼するという簡単な例を考えてみましょう。スクリプトが機能したかどうかを検証する方法はいくつかあります。最も一般的なアプローチは、テストを書くことです（エージェントが簡単に行えること）または、エージェントが新しいファイルの存在を確認し、ファイルの内容をレビューすることもできます。フロントエンドを持つウェブアプリケーションも同様に機能することができます。エージェントはウェブページに対してcurl操作を実行し、HTMLの内容を読み取ることができます。ウェブバックエンドのみを書いた例では、エージェントがテストを書いたり、curlリクエストを実行してレスポンスコード、ボディテキストなどを確認することもできます。
組み込みシステムにおいては、検証（特にボードの立ち上げ時）は通常、視覚的に、または一連の手動チェックを通じて行われます。最も原始的な検証方法の一つとして、LEDが点滅していることを目で見て確認する、点滅するLEDの例を考えてみましょう。ADCに信号を送り込み、出てくるテレメトリーを見ることは、通常、自動化された方法でスクリプト化されることはありません - それは、自動化されたテストを書いた後に通常行われます。組み込みシステムのためのエージェント指向のワークフローでコーディングする際には、テレメトリーをフィードバックメカニズムとして組み込む必要があります。エージェントは、LEDを見ることができないため（少なくとも今日のエージェント技術では）、コードが機能しているかどうかを知ることができません。ここで重要なのは、コマンドラインを通じて読み取り、検証できる何かを生成することを強調することです：
この時点で、LEDを点灯させるだけでなく、「LED_ON」と「LED_OFF」という状態をシリアル出力で提供するテレメトリーも生成します。これらの応答をどのように取得するかも自動的に知っています：
このタイプのリクエスト（「SSH」コマンドリクエストにも見られる）で一般的な問題は、エージェントがターミナル内でコマンドを発行した後、プロセスが終了しないことです。Arduino CLIモニターは無期限に実行されるため、エージェントは永遠にハングアップします。将来のアップデートでエージェントに何らかのタイムアウトが導入されると考えるのはかなり論理的ですが、この例では、このワークフローでは、それが存在しません。エージェントにそのターミナルがハングアップしたこと、そしてそれを考慮する必要があることを伝えなければなりません：
これでコマンドは修正され、エージェントはより洗練されたコード例に取り組むことができるようになりました。この時点で、エージェントがコードがコンパイルされアップロードされたかどうかだけでなく、ターゲットデバイス上で正しく実行されたかどうかについてもフィードバックを得る方法を確立しました。
結論
組み込みシステムのためのバイブコーディングを始めることは、直感的ではなく、時には「ブラックマジック」のように思えるかもしれません。エージェントとあなたの組み込みデバイスとの成功したバイブコーディングセッションの鍵は、エージェントが常に十分なフィードバックを受け取ることを確実にすることです。コードがコンパイル/アップロードされるだけでなく、ターゲットデバイス上でも正しく機能することを知る必要があります。これらの例のいくつかは基本的なものでしたが、より複雑で洗練されたAIインザループやハードウェアインザループの開発の基礎です。これらの例とウォークスルーを武器に、指一本動かさずにAIが生成した組み込みコードの書き込み、コンパイル、実行を始めることができるはずです。
