arduino-azure-iot-edge-integration

Arduino Azure IoT Edge 統合

Arduino クラスのデバイスを Azure IoT に接続する必要がある場合、特にエッジ中心のシナリオ（ゲートウェイ、不安定なネットワーク、オフラインバッファリング、ローカルでの動作制御）でこのスキルを使用します。

使用する場面

次のようなリクエストにこのスキルを使用します。

• 「Arduino センサーを Azure に接続したい」
• 「IoT Hub に MQTT テレメトリを送信するにはどうすればよいですか？」
• 「フィールドデバイス用のエッジゲートウェイが必要です」
• 「クラウドからデバイスへのコマンドと OTA 構成の更新を行いたい」

必須のドキュメント確認

IoT Edge のトポロジーやランタイムの動作を推奨する前に、次を確認してください。

• https://learn.microsoft.com/azure/iot-edge/

ドキュメントを参照できない場合は、前提を明示して進め、専用のセクションでその前提を強調してください。

Arduino の公式リファレンスとベストプラクティス（必須）

ファームウェア、配線、通信の実装詳細を提案する前に、まず Arduino の公式資料を確認してください。

• https://www.arduino.cc/en/Guide
• https://docs.arduino.cc/
• https://docs.arduino.cc/language-reference/
• references/arduino-official-best-practices.md

実装方法を選ぶ際は、コミュニティのサンプルから逸脱する明確な技術的理由がない限り、Arduino の公式ガイダンスを優先してください。

目標

• Arduino デバイスからクラウドのインサイトまでの、安全なエンドツーエンドのリファレンスパスを作成します。
• 不安定な接続に対応します（ストアアンドフォワード、再試行、冪等性）。
• 実行可能なデバイスおよびクラウドのバックログを定義します。

統合パターン

パターン A：Arduino から IoT Hub に直接接続

接続が安定しており、クラウドのレイテンシーが許容される場合に使用します。

• プロトコル：TLS 上の MQTT。
• ID：デバイスごとの認証情報（SAS または X.509）。
• テレメトリペイロード：タイムスタンプ、デバイス ID、メトリック、任意の品質フラグを含むコンパクトな JSON。

パターン B：Arduino からローカルゲートウェイを経由して IoT Edge に接続

接続が制約される場合、ローカル制御が必要な場合、またはバッチ処理によってコストや信頼性が向上する場合に使用します。

• Arduino はローカルゲートウェイ（シリアル、BLE、ローカル MQTT、RS-485、Modbus ブリッジ）と通信します。
• ゲートウェイは IoT Edge ランタイムを介して上流にデータを発行し、IoT Hub にルーティングします。
• ローカルモジュールは、クラウドが停止している間もデータのフィルタリング、集計、アクションの実行を行えます。

設計フロー

1) デバイスの契約

次を定義します。

• センサーの一覧と単位。
• サンプリング頻度と予想スループット。
• メッセージスキーマのバージョン管理戦略。
• ランタイムの動作を制御する、デバイスツインの desired/reported プロパティ。

2) セキュリティのベースライン

次を必須とします。

• デバイスごとの一意な ID。
• ソースコードやファームウェア成果物へのシークレットのハードコーディングを禁止します。
• 認証情報のローテーション戦略。
• 可能な場合は、署名付きファームウェアと管理された更新プロセス。

3) 信頼性とオフライン時の動作

次を計画し、文書化します。

• ジッターを加えたバックオフ。
• サイズに上限を設けたローカルキュー／バッファー戦略。
• 重複の抑制、または下流での冪等な処理。
• 最後に正常と確認された構成へのフォールバック。

4) クラウドとエッジのルーティング

次のルートを定義します。

• 生のテレメトリからコールドストレージへのルート。
• 精選されたテレメトリからホット分析へのルート。
• 運用チャネルへのアラートのルート。
• エッジ／デバイスへのコマンドおよび構成のルート。

5) 可観測性

最低限必要な運用テレメトリを指定します。

• デバイスのハートビートとファームウェアのバージョン。
• 接続状態の遷移。
• メッセージ送信の成功／エラーのカウンター。
• ゲートウェイモジュールの正常性と再起動の理由。

他のスキルの再利用

関連する場合は、次のスキルを組み合わせてください。

• azure-smart-city-iot-solution-builder：都市全体のアーキテクチャと段階的なロールアウト。
• azure-resource-visualizer：リレーションシップ図。
• appinsights-instrumentation：アプリおよびサービスのテレメトリパターン。

また、ファームウェアおよびハードウェアの推奨事項に関する品質基準として references/arduino-official-best-practices.md を使用し、アーキテクチャや実装のガイダンスを最終決定する前に references/arduino-iot-checklist.md を確認してください。

必須の出力

必ず以下を提示してください。

1. 選択した接続パターンとその理由。
2. メッセージの契約（フィールド、単位、ペイロードのサンプル）。
3. ID、認証情報、更新に関するセキュリティチェックリスト。
4. 信頼性計画（再試行、バッファリング、重複排除）。
5. 実装バックログ（ファームウェア、ゲートウェイ、クラウド）。

出力テンプレート

1. シナリオと前提条件
2. 推奨アーキテクチャ
3. デバイスとゲートウェイの契約
4. セキュリティと信頼性の制御
5. デプロイ計画と検証テスト

ガイドライン

• デバイス間で認証情報を共有する本番環境へのデプロイは提案しないでください。
• フィールドでのデプロイでは、常時接続を前提としないでください。
• アクチュエーターのシナリオでは、コマンドの認可と監査を省略しないでください。