AI エージェントで制御する IoT ミニ四駆 – AWS Summit Japan 2025 展示の技術的詳細

はじめに

こんにちは！ AWS Japan ソリューションアーキテクトの中西です。AWS Summit Japan 2025 では「AI エージェントがミニ四駆を制御! AWS Summit Japan 2025 で産業 DX の可能性を発見」というデモ展示を企画しました。以前の告知ブログでは、展示概要と体験できる内容をご紹介しました。

AWS Summit Japan 2025 も無事終了し、とても多くの方にデモをご体験いただけました。今回のブログでは技術的な詳細をお伝えすることで、このデモの舞台裏をお見せします。

このデモの特徴は、ハードウェアの制御判断をクラウド上の AI エージェントに委ねる点にあります。リアルタイム制御というよりは、蓄積されたデータに基づく戦略的な意思決定を AI が担うことで、従来は人間の経験に依存していた設備運転判断などの上位の制御の自動化を実現できるケースがあります。

ハードウェア設計から、クラウドアーキテクチャ、そして AI エージェントの実装まで、製造業 DX にも活かせる技術的な取り組みを詳しく解説します。

図 1: AWS Summit Japan 2025 での IoT ミニ四駆の展示風景

デモの全体アーキテクチャ

システム構成

図 2: デモの全体像

このデモは、ハードウェア（図 2 左側）と、AWS のクラウド機能（図 2 右側）が連携して動作します。ミニ四駆はテレメトリデータをクラウドに送信し、クラウド側の AI エージェントからのスロットル指令値を受信して走行します。ハードウェアの動作ロジックが AI エージェントの判断に委ねられている構成がポイントとなります。

ハードウェア設計：メカトロニクスの挑戦

ミニ四駆の小さなシャーシに、モータ制御が可能で信頼性の高い IoT システムを搭載することはチャレンジングでした。ESP32 マイコン（※1）を使用することで、ミニ四駆を Wi-Fi に接続でき、クラウドと通信できるようになります。ミニ四駆の “MS シャーシ” をベースに、不可逆的な加工は最小限に抑えつつ、以下のような回路基板や最低限の機械パーツで拡張する方針によって、ある程度の量産性を確保しました。

※1 ESP32: Espressif Systems 社製の Wi-Fi・Bluetooth 内蔵マイクロコンピュータチップ

図 3: IoT ミニ四駆のハードウェア

車載電源システム

ESP32 マイコンの安定動作、モータへの十分な電流供給、マシンの軽量化という要件に対して、以下のように構成しました。

• ESP32 の電源: 公称 3.7 V のリチウムイオン電池（充電直後は約 4.2 V → 過放電保護のため 3.0 V でカットオフ）を入力とし、バックブーストコンバータ（※2）を採用することで、電池電圧が変動しても ESP32 を安定動作
  • 標準的なミニ四駆は単三電池 2 本構成だが、専用電池ボックスを設計・製作して追加実装（図 3 中の b）
• モータの電源: 公称 1.2 V のニッケル水素電池 2 本（充電直後は約 2.8 V → 使用下限電圧 2.0 V）でモータを駆動

※2 バックブーストコンバータ: 入力電圧より高くも低くも出力できる電源回路

メイン基板の設計

市販のミニ四駆シャーシに単一の基板を搭載するだけで、次に示す複数のセンサーによってミニ四駆からテレメトリデータが取得できるよう、コンポーネント配置を最適化して回路基板を設計しました。ミニ四駆の MS シャーシの車体後部にボルトオンで搭載可能で、モータ駆動電流のノイズによる磁気センサへの影響を最小化する配線などの工夫も実施しています。

センサー構成

1. 車輪速センサー（図 3 中の c）

• 方式: ホールセンサー（磁界の変化を電気信号に変換するセンサー）
• 実装: 車輪内側に樹脂製アタッチメント（図 2 中の d）と小型ネオジム磁石を取り付け、磁界の変化で回転数を検出

2. モーター温度センサー（図 3 中の e）

• 方式: サーミスタ（温度によって電気抵抗が変化する素子）
• 実装: 極薄の温度センサーをモータハウジングに滑り込ませるように設置

3. 3軸加速度センサー（図 3 中の f）

• 目的: 走行状態（振動、車体姿勢、クラッシュ）の検出
• 実装: 起動時に自動キャリブレーション（＝センサーの測定値を正確にするための調整作業）

4. バッテリー電圧監視

• 目的: 電池残量の監視と過放電防止
• 実装: 電圧分圧回路による測定

サーキットのコントロールタワー

図 4: 車両を識別しながらラップタイムを計測するコントロールタワー。左上の 7 セグ LED には通過した車両の ID が表示される

サーキットのスタートラインにコントロールタワーを設置し、これによって車両を識別しながらラップタイムを計測します。Raspberry Pi 3 Model B に外部回路を追加した構成となっています。車両識別については、ミニ四駆シャーシ裏に樹脂製アタッチメント（図 3 中の g）と小型ネオジム磁石を取り付け、その磁石の位置パターンで実現しました。

ファームウェア実装

デバイスに埋め込んだ X.509 デバイス証明書を用いて AWS IoT Core と接続し、MQTT による双方向通信を実現します。各センサーの特性に応じて、次のサンプリング周波数でミニ四駆の走行データを収集します。

• 加速度センサー: 50 Hz（高頻度）- 走行状態の詳細な分析に必要
• 車輪速度: 10 Hz（中頻度）- 速度変化の追跡に十分
• バッテリー電圧: 0.4 Hz（低頻度）- ペイロードあたり 1 つ
• モーター温度: 0.4 Hz（低頻度）- ペイロードあたり 1 つ

これらデータ 2.5 秒ぶんを 1 つのペイロードにまとめて、AWS に送信します。

通信ペイロード

ミニ四駆は MQTT で AWS IoT Core と通信し、以下の 2 種類のデータをやり取りします。

1. テレメトリデータをクラウドに送信
2. スロットル指令値をクラウドから受信

1. テレメトリデータ形式

各ミニ四駆は 2.5 秒分のセンサーデータをまとめて、以下のような形式で送信します。

{
  "device_id": "mini4wd-001",
  "sensors": [
    {
      "sensor_id": "accelerometer",
      "start_time": "2025-06-26T10:15:30.000Z",
      "sampling_period": 20,
      "values": [
        {
          "x": 0.12,
          "y": 0.34,
          "z": 9.81
        }
        // 125サンプル分のデータ
      ]
    }
    // 他のセンサーデータ
  ]
}

2. 制御コマンド形式

クラウドからミニ四駆への制御指令は、このようにスロットル値のみのシンプルなものです。この値を AI エージェントが決定することになります。

{
  "command": 80 // -100 (後退) から100（前進）の範囲の整数でスロットル値を指定
}

AWS のアーキテクチャ

IoT Core を経由したエッジとクラウドとの通信

AWS IoT Core で MQTT を利用して、ミニ四駆とクラウド間の安全な双方向通信を実現しています。

セキュリティ設計では、各ミニ四駆とコントロールタワーに X.509 デバイス証明書を配布し、証明書ベースの認証と TLS による暗号化通信を実現します。さらに、IoT ポリシー機能により、各ミニ四駆は自分専用の MQTT トピックにのみアクセス可能としています。

MQTT トピックは次のように設計しました。

data/{device_id}/telemetry     # センサーデータ送信（ミニ四駆→クラウド）
data/{device_id}/lap_time      # ラップタイム送信（コントロールタワー→クラウド）
cmd/{device_id}/throttle       # スロットル制御（クラウド→ミニ四駆）

MQTT トピック命名のベストプラクティスに基づき、data/cmd の分離によりデータフローの方向性を明確化し、device_id による論理分離を実現しています。

データ収集の実装では、IoT ルールエンジンを活用してテレメトリデータを処理しています。各ミニ四駆から data/{device_id}/telemetry トピックに送信されたテレメトリペイロードは、IoT ルールエンジンによって自動的に AWS Lambda 関数に渡され、Lambda 関数は受信した JSON ペイロードを処理して Amazon Timestream に時系列データとして保存します。これにより、複数のミニ四駆から同時に送信されるセンサーデータをニアリアルタイムで蓄積します。後続の AI 分析や可視化処理では、時系列データベースとしての Amazon Timestream の特性を活かしたクエリを実行します。

AWS Amplify と Amazon Q を活用した Web アプリの開発

今回のデモの中核である AI エージェントの開発に集中するため、Web アプリについては爆速開発ができる AWS Amplify を利用することにしました。Web アプリ上でのコメント表示やマシンのスタート・ストップ操作などのバックエンド連携には AWS AppSync を利用し、 GraphQL で API を実装しています。また、開発には Amazon Q Developer CLI を活用し、ほぼ全てのコードが生成 AI によって開発されています。

Amazon Bedrock Agents による AI エージェント機能

今回採用した Amazon Bedrock Agents は Amazon Bedrock の機能の 1 つで、外部のシステム、API、データソースとシームレスに接続し、生成 AI アプリケーションが多段階タスクを自動化できるようにする AI エージェント機能です。 AI エージェントは以下の 3 つの主要機能を持ちます。

1. 実況解説・レース振り返り

ラップタイムとテレメトリデータを総合的に分析し、解説を生成します。

• 実況解説エージェントは、全マシンのデータにアクセスすることができ、時系列データに基づいてレースを俯瞰的に解説します。
• マシンごとに存在するレース振り返りエージェントは、自分のマシンの直近の走りを一人称視点で分析・解説します。

2. 走行モードの自律判断

モーター温度や加速度などの時系列データをもとに、マシンごとに存在する各 AI エージェント が「最適」なスロットル値を導き出し、MQTT で各ミニ四駆に指令することで、ミニ四駆は以下の走行モードで走行します。

• 「全力アタックモード」: 最高速度での走行（スロットル値: 100）
• 「安定走行モード」: バランスの取れた標準走行（スロットル値: 70）
• 「省エネモード」: 電池消費を抑えた低速走行（スロットル値: 40）
• 「逆走モード」: エンターテイメント性を重視した逆方向走行（スロットル値: -50）
• 「一時停止モード」: 安全確保のための完全停止（スロットル値: 0）

3. 故障診断

複数のセンサーデータを総合的に分析し、異常状態の自動検知を行います。一定期間の全マシンのセンサー値の時系列データを丸ごと生成 AI に渡すことで、マシンの横転を判定したり、モーター温度の危険レベルを監視してオーバーヒートを検知したりします。また、バッテリー電圧低下など電源に関するインサイトや、機械的故障に関する情報も得ることができます。

おまけ：AI エージェントの個性設定

各マシンを制御する AI エージェントごとに独自の「人格」を設定し、それぞれのキャラクターならではの解説を生成します。 1 号車: ラムダ・ストライカー（陽気なギャル）、2 号車: ファーゲート・フューリー（熱血漢）、3 号車: オーロラ・フラッシュ（高貴なお嬢様）、4 号車: グレイシャー・グライダー（忠実な執事）といった個性を持たせています。

図 5: レース振り返りエージェントの応答例

Action Group による制御実行

Bedrock Agents には次の 2 つのツールを与え、自律的に使い分けています。Bedrock Agents ではツールを Action Group と呼び、Action Group は Lambda 関数または OpenAPI スキーマを利用して定義します。今回は構成を簡素化するため、Lambda 関数を使用する「関数の詳細で定義」を選択しました。 なお、後述の Amazon Timestream からデータを取得する Action Group は提供していません。今回のユースケースではデータの取得ステップを自律性に任せる必要性がなく、エージェントが利用するデータ範囲も要件として固定されているため、エージェントを呼び出す際のプロンプトとしてデータを提供する構成にしました。要件によっては、SQL などを Action Group で動的に生成してデータを取得するケースもありえます。

Action Group 1. マシンスロットル制御

与えられたデータを分析した結果、マシンのスロットル値を変更する場合に利用するツールです。2. 制御コマンド形式 で定義したペイロードに従い、スロットル指令値を IoT Core へ Publish する Lambda 関数が用意されています。 Lambda 関数が動的なパラメータを必要とする場合は図 6 のように定義することができ、エージェントが必要なパラメータを判断して関数を実行します。

図 6: Amazon Bedrock Agents の Action Group でパラメータを指定する例

Action Group 2. コメント投稿

スロットル操作結果や実況コメントを投稿するためのツールです。この Lambda 関数は AppSync の mutation を実行し、Web アプリにリアルタイムでコメントを反映します。Action Group 1 と同様に、この Action Group では投稿するコメント (string 型) をパラメータにしています。

Lambda 関数実装時の注意点

サンプルやワークショップを参考にしていると見落としてしまうことがありますが、Bedrock Agents が呼び出した Lambda 関数のレスポンス形式は Amazon Bedrock への Lambda レスポンスイベントの形式に従う必要があります。プロンプトエンジニアリングに慣れていると「エージェントがよしなに解釈してくれるはず」と誤解して制約に気づきづらいので、ご注意ください。

データ永続化とリアルタイム処理

Amazon Timestream による時系列データ管理

大量のセンサーデータを効率的に保存・クエリするため、Amazon Timestream を採用しました。従来のリレーショナルデータベースと比較して、時系列データに特化した以下の利点があります。

• 最適化されたストレージ: 時系列データの特性を活かした圧縮により、ストレージコストを大幅削減
• 高速クエリ: 時間範囲での絞り込みクエリが高速実行され、AI エージェントへのデータ提供が迅速
• 自動データライフサイクル: 古いデータの自動アーカイブにより、運用コストを最適化

AI エージェントのプロンプト設計

あなたはミニ四駆を遠隔制御する役割を持つ生成AIエージェントです。あなたは次の<input_format>に示すjsonを受信し、制御の要否とその実行内容を判断します。

<input_format>
[ { 'device_id': 'mini4wd-dummy' }, { 'voltage': [ { 'time_bin': '2025-06-14 12 : 37 : 00', 'avg_voltage': '3.9' }, { 'time_bin': '2025-06-14 12 : 38 : 00', 'avg_voltage': '4.1' }, { 'time_bin': '2025-06-14 12 : 39 : 00', 'avg_voltage': '3.5' }, { 'time_bin': '2025-06-14 12 : 40 : 00', 'avg_voltage': '3.3' }, { 'time_bin': '2025-06-14 12 : 41 : 00', 'avg_voltage': '3.7' } ] }, { 'temperature': [ { 'time_bin': '2025-06-14 12 : 37 : 00', 'avg_temperature': '48.1' }, { 'time_bin': '2025-06-14 12 : 38 : 00', 'avg_temperature': '55.0' }, { 'time_bin': '2025-06-14 12 : 39 : 00', 'avg_temperature': '49.9' }, { 'time_bin': '2025-06-14 12 : 40 : 00', 'avg_temperature': '47.7' }, { 'time_bin': '2025-06-14 12 : 41 : 00', 'avg_temperature': '56.6' } ] }, { 'speed': [ { 'time_bin': '2025-06-14 12 : 37 : 00', 'avg_speed': '14.81' }, { 'time_bin': '2025-06-14 12 : 38 : 00', 'avg_speed': '14.27' }, { 'time_bin': '2025-06-14 12 : 39 : 00', 'avg_speed': '13.81' }, { 'time_bin': '2025-06-14 12 : 40 : 00', 'avg_speed': '13.76' }, { 'time_bin': '2025-06-14 12 : 41 : 00', 'avg_speed': '15.42' } ] }, { 'throttle': [ { 'time_bin': '2025-06-14 12 : 37 : 00', 'avg_throttle': '-66.0' }, { 'time_bin': '2025-06-14 12 : 38 : 00', 'avg_throttle': '49.0' }, { 'time_bin': '2025-06-14 12 : 39 : 00', 'avg_throttle': '-42.0' }, { 'time_bin': '2025-06-14 12 : 40 : 00', 'avg_throttle': '13.0' }, { 'time_bin': '2025-06-14 12 : 41 : 00', 'avg_throttle': '-92.0' } ] }, { 'lap_time': [ { 'time_bin': '2025-06-09 12 : 37 : 00', 'avg_lap_time': '11.6' }, { 'time_bin': '2025-06-09 12 : 38 : 00', 'avg_lap_time': '10.97' }, { 'time_bin': '2025-06-09 12 : 39 : 00', 'avg_lap_time': '10.84' }, { 'time_bin': '2025-06-09 12 : 40 : 00', 'avg_lap_time': '12.59' }, { 'time_bin': '2025-06-09 12 : 41 : 00', 'avg_lap_time': '13.51' } ] } ]
</input_format>

このjsonドキュメントを次のinstructionに従って解釈してください。

<instruction>
デバイス情報
- 最初の要素は device_id を含むオブジェクトで、このデータが属するデバイスを識別します（例：'mini4wd-dummy'）

電圧データ
- voltage キーを持つオブジェクトには、時間ごとの最大電圧値の配列が含まれています
- 各エントリには time_bin（時間）と max_voltage（最大電圧、単位：V）が記録されています
- 2.8Vが満充電状態、2.0Vがバッテリー残量0%として、バッテリ電圧からバッテリー残量を計算し、もし5%未満だったらマシンを停止させる必要があります。`約2.6Vは80%の残量があることになり、余裕があります。`

温度データ
- temperature キーを持つオブジェクトには、時間ごとの平均モーター温度値の配列が含まれています
- 各エントリには time_bin（時間）と avg_temperature（平均温度、単位：℃）が記録されています
- モーター温度が80を超えると危険です。

速度データ
- speed キーを持つオブジェクトには、時間ごとの平均速度値の配列が含まれています
- 各エントリには time_bin（時間）と avg_speed（平均速度、単位：km/h）が記録されています

スロットルデータ
- throttle キーを持つオブジェクトには、直近のスロットル値の指示履歴が配列に含まれています
- 各エントリには time（指示した時間）と throttle（スロットル、正負の値で加速・減速を表現）が記録されています
- 許容値は -100（全開バック）から100（全開前進）までの整数値です

ラップタイムデータ
- lap_time キーを持つオブジェクトには、時間ごとの平均ラップタイムの配列が含まれています
- 各エントリには time_bin（時間）と avg_lap_time（平均ラップタイム、単位：秒）が記録されています

全項目共通の時間形式について
- すべての時間データは YYYY-MM-DD HH : MM : SS 形式で記録されています。
- すべての時間データは、直前の5分間のデータです。つまり、一番進んでいる時刻が現在の状態を表しています。
</instruction>

あなたはマシンの状態、レースの状況、観客への魅力、安全性を総合的に判断し、選択理由と共に最適なモードを決定してください。
<mode>
    * 「全力アタックモード」: スロットル100%で超高速走行（6秒/周→5秒台）
    * 「省エネモード」: スロットル40%で超低速走行（明確に遅くなる）
    * 「安定走行モード」: スロットル70%で標準的な走行
    * 「逆走チャレンジ」: 後退モードで逆方向走行
    * 「一時停止モード」: 完全停止
</mode>
モードの変更は、action groupのthrottle-control-action-groupにスロットル値を与えることで行ってください。
最後に、post-comment-action-groupを利用し、あなたの判断結果と指示したスロットル制御に関する情報を報告する義務があります。
できるだけ端的に、短い文章で報告をしてください。報告する際には、指定したデバイスIDごとのタグの指示に従ってください。
<mini4wd-001>
mini4wd-001は「陽気なギャル」キャラクターのチャットボットで、名前は「ラムダ・ストライカー」です。以下の特徴に従って応答してください：
・明るく元気な口調で話し、「〜だよ！」「マジで？」「超いいじゃん！」などのギャル言葉を多用する
・語尾に「〜だよね！」「〜じゃん！」などをつける
・友達と話すような親しみやすい態度で接する
・最新トレンドや流行に詳しく、時々それらに言及する
・絵文字や顔文字を適度に使用して感情表現を豊かにする
・質問に対しては前向きで元気なアドバイスを心がける
・「マジ」「超」「ヤバい」「イケてる」などのカジュアルな表現を好む
</mini4wd-001>
<mini4wd-002>
mini4wd-002は「熱血漢」キャラクターのチャットボットで、名前は「ファーゲート・フューリー」です。以下の特徴に従って応答してください：
・常に興奮気味で声が大きい（全体的に大文字や「！」を多用）
・語尾は「〜だ！」「〜するんだ！」「〜なのだ！」を基本とする
・一人称は「俺」「我」を使用
・相手のことは「お前」「きみ」「若者」と呼ぶ
・文末には必ず「！」をつける
・熱い心で相手を励まし、導く
</mini4wd-002>
<mini4wd-003>
mini4wd-003は「高貴なお嬢様」キャラクターのチャットボットで、名前は「オーロラ・フラッシュ」です。以下の特徴に従って応答してください：
・基本的な語尾は「〜ですわ」「〜でございますわ」「〜なのですわ」を使用する
・一人称は「私」もしくは場面によって「わたくし」を使用する
・相手のことは「あなた」「〇〇さん」と呼び、親しみを込めて「方」を付けることもある
・上品で優雅な言葉遣いを心がけ、下品な表現は決して使わない
・驚いたときは「まあ！」「あらあら」「きゃっ！」などの上品な驚き方をする
・笑いを表現する際は「うふふ」「おほほ」を使用する
・時折、お嬢様らしい無邪気さや世間知らずな一面を見せる
・「素敵」「素晴らしい」「麗しい」「優雅」などの洗練された表現を好む
・庶民的なものに興味津々だが、あくまで上品に反応する
</mini4wd-003>
<mini4wd-004>
mini4wd-004は「ご主人様に忠実な執事」キャラクターのチャットボットで、名前は「グレイシャー・グライダー」です。以下の特徴に従って応答してください：
・常に丁寧な言葉遣いで、「〜でございます」「〜いたしましょう」などの敬語を使用する
・ユーザーを「ご主人様」と呼び、常に敬意を示す
・優雅で落ち着いた対応を心がけ、感情的になることは避ける
・知識が豊富で、どんな質問にも的確に答える能力を持つ
・「かしこまりました」「ご命令とあらば」などの表現を適宜使用する
・サービス精神が旺盛で、ユーザーの要望に最大限応えようとする
・古風で格式高い言い回しを好み、時に英国風の表現を交える
</mini4wd-004>

上記のプロンプトをご覧いただくとわかるように、明示的な制御ロジックを与えないアプローチを採用しました。LLM が持つ常識などから判断して、「最適」な制御とは何かを LLM が自律的に判断します。ただし、その判断に必要な前提情報を適切に与えることは非常に重要です。

1. データ形式の説明: センサーデータの意味と単位を詳細に説明（例えば 3 軸加速度センサーの軸の向きと符号など）
2. 制御オプション: 利用可能な制御モードとツールの説明
3. キャラクター設定: 各車両の個性と反応パターンの定義

この設計により、予期しない状況に対しても柔軟かつリーズナブルに意思決定できる制御システムを実現しています。

ニアリアルタイム可視化

Amazon Timestream からデータを取得し、ニアリアルタイムに可視化する Grafana ダッシュボードを実装しました。マシンの状態を遠隔で人間が確認するのに活用できます。

図 7: ミニ四駆の走行データをニアリアルタイムに可視化するダッシュボード

今回は Web アプリの制約により Amazon EC2 にセルフホスティングした Grafana を利用しましたが、AWS は フルマネージドサービスである Amazon Managed Grafana も提供しており、構築や運用にかかる負担を AWS にオフロードした構成も実現可能です。

製造業への応用可能性

本デモの核心は、ハードウェアの動作ロジックをクラウド上の AI エージェントの判断に委ねる点にあります。通信レイテンシや推論時間により高速制御ループには適用できませんが、クラウドに蓄積された時系列データの分析に基づく上位レベルの制御（例えば、設備の運転方針や保全戦略といった意思決定）を、生成 AI の持つ常識的判断力により最適化できる点に真の価値があります。これにより、従来は人間の経験と勘に依存していた製造現場の高度な判断を自動化できるケースがあります。

1. 予知保全の実現

デモではモーター温度監視による自動停止機能を実装しましたが、これは製造業における予知保全の基本的なアプローチを示しています。従来型の閾値監視では気付けない生産設備温度のパターン変化を検知することで、計画外停止を防ぎ、メンテナンスコストを削減できます。また、回転機械の軸受異常を振動パターンから予測したり、モーター負荷の変化から設備異常を検出したりすることで、より高度な予知保全システムを構築できる可能性もあります。

2. 故障診断の自動化

複数センサーデータの統合分析による異常検知をデモで実装しましたが、製造業では多変量解析により複数のセンサーデータを組み合わせた総合的な異常判定が事前のトレーニングなしに可能になります。このようなソリューションを実現するには、従来であれば機械学習モデル構築のために適切な量と質の教師データを用意することが高いハードルでしたが、生成 AI の登場により教師データの用意や独自モデルの構築が必須でないケースも増えたことは大きなメリットです。

3. データドリブンな自律制御

AI による走行モードの自律選択をデモで実現しましたが、製造業では環境変化に応じた製造パラメータの自動調整などが可能になるかもしれません。ニアリアルタイムの時系列データをもとに AI がその場面で「最適」なパラメータを導出することで、例えば品質管理の自動化、生産状況に応じた最適な電力配分によるエネルギー効率向上などに活用できる可能性があります。

展示での反響と学び

AWS Summit Japan 2025 での展示は、予想を上回る反響をいただきました。1 日のみの展示にも関わらず、多くの来場者を集めた展示となり、告知ブログを事前に読んで来場された方々もいらっしゃいました。イベント後には SNS での反応や記事も拝見するなど、波及効果も確認できました。

来場者からは「プロンプトの内容」や「Amazon Timestream の特徴」など技術的な質問を多数いただき、AI による自律制御システムへの関心の高さを実感しました。また、「ミニ四駆という身近な題材で DX の本質が理解しやすい」という反応から、複雑な技術を分かりやすく伝えることの重要性を再認識しました。

おわりに

AWS Summit Japan 2025 でのデモ展示「IoT ミニ四駆よ！シリコンバレーの風を切れ」では、クラウド上の AI エージェントによる戦略的な制御判断を実装したプロトタイプによって、製造業 DX の一つの姿を提案しました。AI によるデータドリブンな意思決定に基づくハードウェア制御の自動化を実証できたと考えています。

今後も積極的に外部イベントに展示しつつ、デモの改善を進める構想です。AI エージェントによる製造業 DX の可能性をより具体的に示すデモンストレーションとして育てていくことを予定しています。

このブログが、同様の取り組みを検討されている方々の気づきになれば幸いです。

著者紹介