Raspberry Pi
イベント
マガジン
技術ブログ
みなさん、こんにちは。ソリューションアーキテクトの市川、井上、新澤、川﨑です。この記事では、 AWS Summit Japan 2026 で AWS IoT サービスを利活用した展示の一部をご紹介します。各ブースで表示している資料もこちらに掲載予定です。 AWS IoTで実現するロボット遠隔テレオペレーション体験 (A026) Physical AIの分野では、データ収集、モデルのトレーニング、シミュレーション、現実世界への反映というサイクルを回す必要があります。このデモでは、AWSのIoTサービスを使ってデータ収集をする方法について展示を行っています。コントローラーでセイコーエプソンさんのロボットを操作し、エッジデバイス上のAWS IoT GreengrassからAWS IoT CoreやS3にデータを保存する様なアーキテクチャを紹介します。 赤枠がブースのおおよその展示場所を示しています。 図1：A026展示場所 AIエージェントで実現するスマートマシン -産業機械の自律診断とリアルタイム安全監視-(A162) このブースでは、AWS上に構築されたエージェント型の産業機械保全ワークフローをご紹介します。AIエージェントが故障を自律的に診断し、現場オペレーターへの通知からサポートへのエスカレーションまでを一気通貫で実行する様子をご覧いただけます。エッジAIによる安全監視、計画外ダウンタイムの削減、インシデント対応の迅速化など、建設・製造・農業・鉱業の各現場における機器管理・保守を変革する次世代のフィールドオペレーションを、ぜひブースでご体験ください。 赤枠がブースのおおよその展示場所を示しています。 図2：A162 と A026 展示場所 Physical AIへの第一歩 AWS IoTで実現するPhysical AI基盤 (A161) Physical AIの実現には、クラウドで学習したAIモデルをエッジデバイスにデプロイし、エッジデバイスのセンサーデータをクラウドに送信するための安定した基盤が不可欠です。本ブ ースでは、AWS IoT Core , AWS IoT Greengrass , Amazon Kinesis Video Streams などを用いてデバイス接続からエッジコンピューティング、映像配信を Raspberry PiやJetsonを利用したライブデモで体験いただけます。A/Bデプロイやロールバック等の本番運用機能、生成AI活用に関してもご紹介させていただきます。IoT をこれからはじめる方からエッジAI検討中の方まで、Physical AIへの第一歩をここから踏み出してください。 赤枠がブースのおおよその展示場所を示しています。 図2：A162 と A026 展示場所 builders’ Fair： クラウドVLAが操るミニロボたち ミニロボたちがクラウドベースのVLAで自律的に考えて卓上のフィールドを動き回ります。荷物・障害物・危険エリアなどをAIが見て判断し、複数のミニロボが「何を運ぶ？」「どこに片付ける？」「どう分担する？」「こっち危ないから回り道しよう」と自分たちで動きます。来場者の皆さんもぜひ障害物を置いたり、荷物を散らかしたりしてください。ミニロボたちは協力しながらタスク完遂を目指します。さて、ミニロボたちはちゃんとやりとげることができるか？温かい目で見守ってください！ 赤枠がブースのおおよその展示場所を示しています。 図3：展示場所 インダストリブース：AWS認定デバイスウォール(A017) 昨年のAWS Summit Japan 2025 でご好評いただいた AWS Summit Japan 2025 での AWS 認定デバイスウォール展示のご紹介 が今年も登場します！ エッジデバイスとクラウドを連携させるニーズが高まる中、多様なエッジデバイスから最適なものを選ぶことはお客様にとって課題となっています。 AWS 認定デバイスプログラム は、AWSのIoTサービスとの接続が検証された信頼性の高いデバイスを取りそろえたプログラムです。本展示では、認定デバイスを通じてプログラムの価値とハードウェアパートナーとの協力体制を紹介し、日本国内におけるエッジとAWSを活用したサービス構築の迅速化とビジネスの加速を支援します。 AWS Summit Japan 2026 製造業向け展示の見どころ紹介！ でもブース情報記載しておりますのでご確認ください。 赤枠がブースのおおよその展示場所を示しています。 図4：A017展示場所 市川 純 プロトタイピングソリューションアーキテクト AWS では IoT に関連するプロトタイピングを支援する、ソリューション アーキテクトとして、お客様の IoT 関連案件を支援しています。 新澤 雅治 IoT スペシャリスト ソリューションアーキテクト 製造業、 IT ベンダーを経て AWS に 入社。現在は IoT スペシャリストソリューションアーキテクトとして、主に製造業のお客様の Industrial IoT 関連案件の支援に携わる。 井上 昌幸 IoT Specialist Solutions Architect Internet of Things と Robotics 界隈で面白い事を探しながら、今日もこつこつリアルな世界とクラウドを繋いでいます。あなたのとっておきのアイデアを AWS と一緒にカタチにしましょう。 川﨑 裕希 アマゾンウェブサービスジャパン合同会社のソリューションアーキテクトです。普段は製造業のお客様のご支援を中心に活動しています。IoTやエッジデバイスに興味があり、エッジ推論の検証が最近の趣味です。 <!-- '"` -->
SCSK いわいです。 前回はRaspberry Pi 5で気温/気圧/湿度センサーを使って測定し、 Webで表示、DBに取得データを検索するシステムを構築しました。 今回は測定したデータからAIを使って気温/気圧/湿度をリアルタイム予測してみます。 今回は前回セットアップした環境をそのまま流用します。 Raspberry Piで気温/気圧/湿度計測 結果をWebサーバで見てみよう Raspberry Pi 5で気温/気圧/湿度センサーを使って測定し、Webで表示するシステムを構築したいと思います。DBに取得データを格納し、あとから検索できるといろいろ便利です。 blog.usize-tech.com 2025.12.08 過去データから現在値を予測す る 過去データから現在値を予測します。これには機械学習結果からの推論(教師あり学習)を使用します。 温度/湿度/気圧の予測のために「線形回帰」「非線形回帰」「LSTM(Long Short Term Memory)」の3つを試してみます。 「線形回帰」はデータの関係性が直線(線形)の場合で表せる場合に使われます。 ⇒グラフにした時にだいたいまっすぐな線で表せる 例えば商品の売上と広告費用などが該当します。 「非線形回帰」は「データの関係性が曲線（非線形）」で表せる場合に使われます。 ⇒グラフにした時に曲がった線で表せる 例えば投げたボールの高さと時間の関係が該当します。 「LSTM」は時系列データや文章など、時間の流れや順番が大事なデータをうまく使える機械学習のモデルです。 ⇒過去と今の情報を組み合わせて考えられる仕組み 例えば株価の予測、文章の意味理解が該当します。 普通の再帰型ニューラルネットワークは「昔のこと」をすぐ忘れてしまいますが、LSTMは 「長い・短い記憶をうまく使い分けできる」ので、長い文章や長期的な傾向も扱えるようです。 なんだか今回のテーマに合致しそうな気配です。 ざっくりまとめると以下になります。 方式 得意なデータ 値の関係 過去の情報との関係 例 線形回帰 数値 & シンプル 直線 考慮しない 商品の売上と広告費用 非線形回帰 (RF予測) 数値 & 複雑 曲線 考慮しない 投げたボールの高さと経過時間 LSTM 時系列・文章・音声等 複雑 + 順番 重視する 株価予測、文書生成 これらの3つの方式を実装してどの予測値が実測値に近いか確認してみます。 システムのイメージ 前回作成したFlaskアプリケーションに機能を追加します。今回はWeb画面に測定結果と予測値を表示します。 蓄積した測定結果から予測モデルを作成して、予測モデルを使ってリアルタイムで現在の温度/湿度/気圧を予測してみます。 イメージはこんなカンジで。 今回のシステムで導入する機能と各ライブラリの説明は以下のとおりです。 機能 ライブラリ 説明 Webサーバ Flask 軽量なWebフレームワーク。センサー値や予測結果をWebアプリとしてブラウザに表示。 センサー通信 Smbus2 ラズパイとI2C通信する。BME280と通信するために利用。 bme280 Bosch製の温湿度・気圧センサー BME280用のPythonライブラリ。データ取得する。 データ保存 sqlite3 軽量な組み込み型データベースSQLiteを操作するためのライブラリ。計測データをローカルDBに保存・検索するために利用。 時刻処理 datetime 計測時刻の記録に利用。ローカルDBに保存するtimestampを生成。 ファイル管理 (new) os OSレベルの操作。LSTMモデル/Scalerファイル(ディープラーニング結果ファイル)の存在確認に利用。 joblib Pythonオブジェクトを高速に保存・読み込みするためのライブラリ。学習済みScalerを保存・読み込みするために利用。 数値処理 (new) numpy 数値計算ライブラリ。線形回帰やLSTMに渡すデータを配列に整形するために利用。 機械学習 (new) scikit-learn 線形回帰、非線形回帰をつかった予測のために利用。 tensorflow LSTM予測のために利用。 前回導入済みのライブラリに加え、ファイル管理用ライブラリ(joblib)、数値処理ライブラリ(numpy)、機械学習用ライブラリ(scikit-learn、tensorflow)を追加します。ファイル管理用ライブラリであるosはデフォルトでインストールされています。 過去のデータからLSTMモデルを作成する LSTMモデルを作成するために高速演算用ライブラリのnumpy、機械学習ライブラリのscikit-learnとtensorflow、ファイル生成用ライブラリjoblibをインストールします。 sudo pip install numpy –break-system-packages sudo pip install tensorflow –break-system-packages sudo pip install scikit-learn –break-system-packages sudo pip install joblib –break-system-packages ローカルに測定結果を蓄積しているDBファイルを元にLSTMモデルとScalerファイルを生成します。 Scalerファイルとは学習時のデータの最大値/最小値、標準偏差等を求めて、それぞれのデータをを0~1の数値に 置き換えるための定義ファイルとのこと。 この定義ファイルがないとそもそもどんな情報を元に学習した結果なのかわからず、 予測もできないため、学習時と予測時には同じ定義ファイルを使う必要があります。 import sqlite3 import numpy as np import tensorflow as tf from tensorflow.keras.models import Sequential from tensorflow.keras.layers import LSTM, Dense from sklearn.preprocessing import MinMaxScaler import joblib # スケーラー保存用 # ====== 設定 ====== DB_FILE = "bme280_data.db" TREND_WINDOW = 10 # LSTM の timesteps MODEL_FILE = "bme280_lstm_model.keras" SCALER_FILE = "bme280_scaler.save" # ====== SQLite からデータ取得 ====== def load_data(): with sqlite3.connect(DB_FILE) as conn: c = conn.cursor() c.execute(""" SELECT temperature, humidity, pressure FROM measurements ORDER BY timestamp ASC """) rows = c.fetchall() data = np.array(rows, dtype=np.float32) return data # shape = (n_samples, 3) # ====== LSTM 用系列データ作成 ====== def create_sequences(data, window_size): X, y = [], [] for i in range(len(data) - window_size): X.append(data[i:i + window_size]) y.append(data[i + window_size]) return np.array(X), np.array(y) # ====== メイン処理 ====== def main(): # --- データロード --- data = load_data() if len(data) <= TREND_WINDOW: raise ValueError("データ数が TREND_WINDOW 以下です") # --- 正規化 --- scaler = MinMaxScaler() data_scaled = scaler.fit_transform(data) # --- 系列化 --- X, y = create_sequences(data_scaled, TREND_WINDOW) print("X shape:", X.shape) # (samples, timesteps, features) print("y shape:", y.shape) # (samples, features) # --- LSTM モデル --- model = Sequential([ LSTM(32, input_shape=(X.shape[1], X.shape[2])), Dense(X.shape[2]) # temperature, humidity, pressure ]) model.compile( optimizer="adam", loss="mse" ) model.summary() # --- 学習 --- model.fit( X, y, epochs=100, batch_size=16, verbose=1 ) # --- 保存（.keras 形式） --- model.save(MODEL_FILE) joblib.dump(scaler, SCALER_FILE) print("✅ モデル保存:", MODEL_FILE) print("✅ スケーラー保存:", SCALER_FILE) # ====== 実行 ====== if __name__ == "__main__": main() 予測用に直近10件のデータを測定し、学習結果から次の1件のデータを予測するLSTMモデルを作成しています。 これで温度/湿度/気圧予測の準備ができました。 Pythonスクリプト作成/実行 今回もChatGPTを利用してPythonスクリプトを作りました。 前回の構成に過去のデータから現在の気温/湿度/気圧を線形予測、RF予測、LSTM予測した結果を 表示する機能を追加しています。 線形予測は直近5000件のデータから現在の各値を予測、RF予測は過去の測定値からランダムな特徴やデータの一部を選定、 50パターンの決定木 = forestを生成して、その平均値から各値を予測するように設計しています。 Raspberry PiでWebサーバを起動します。 実行結果 上から「実測値」、「線形予測値」、「RF予測値」、「LSTM予測値」を表示しています。 線形予測はだいぶ外れた値、RF予測は実測値にかなり近い値、LSTM予測は若干ずれた値となりました。 現実では温度/湿度/気温には以下の傾向があります。 温度：平坦⇒微増/微減⇒平坦 湿度：ジグザグ 気圧：ほぼ一定＋揺れ この現象に対してそれぞれのリアルタイム予測はざっくりと以下のように動きます。 線形予測：微増/微減したら次も微増/微減するはず ⇒そもそも現実と合致してないが傾向はわかる RF予測：大体前と同じぐらいの値では？ ⇒ほぼ正解 LSTM予測：過去の値からみてちょっと変えたほうがそれっぽい？ ⇒賢すぎてノイズが発生することもあるがクセは覚えられる 今回のケースではそれぞれの予測は得意な分野があることがわかりました。 線形予測は「傾向予測、急激な変化を検出する」、RF予測は「リアルタイム予測、直近予測をする」、 LSTM予測は「周期的な予測、1時間後の予測をする」が得意なようです。 勉強になりました。
前回記事からの続きです。 IoTに高可用性はなぜ必要？信頼性を確保するための第一歩 – TechHarmony アーキテクチャ概要 まず、クラスタ構成については、以下の通りです。 Pacemaker ：リソース管理（仮想IPやサービスの制御） Corosync ：クラスタ通信（ノード間の状態同期） Raspberry Pi ５[2台] ：クラスタノード 仮想IP（VIP） ：サービス提供用IP クラスタ全体構成の構成図 今回は、HUBを用いて、1号機と2号機を接続し、同じネットワークアドレスの設定をしていきます。 仮想IPリソースを作成し、1号機と2号機にインストールしたPacemakerでリソース監視を行い、 Corosyncでノード間の状態を同期し、クラスタ通信を行います。 実際の画像です(赤枠で囲っているものがケースで覆われていますが、Raspberry Piです) 実装手順 1. 環境準備 Raspberry Pi OS ネットワーク設定（今回は固定IPにて設定） Pacemaker、Corosync、pcsインストール Raspberry Piのセットアップを2台ともに設定を入れていきます。 環境の用意ができましたら、まずは、Raspberry Pi にPacemakerとCorosyncをインストールしていきます。 1. OSアップデート ：まずRaspberry Pi のターミナルを開き、最新パッケージに更新します。 ＃sudo apt update ＃sudo apt upgrade -y 2. 必要パッケージのインストール ：PacemakerとCorosyncをインストールします。 ＃sudo apt install pacemaker corosync pcs -y 3. pcsdサービスの起動・自動起動設定 ＃sudo systemctl enable pcsd ＃sudo systemctl start pcsd 4. 設定完了確認 ＃pcs –version ＃pacemakerd –version ＃corosync -v 対象のバージョンが表示されるとOKとなります。 続いてクラスタ設定をしていきます。 2. Corosync設定 Corosyncの設定は、 /etc/corosync/corosync.conf にて行っていきます。 以下、今回設定した内容となります。 totem { version: 2 cluster_name: クラスタ名 transport: knet crypto_cipher: aes256 crypto_hash: sha256 cluster_uuid:00000000-0000-0000-0000-000000000000 (※実際にはユニークなUUIDが表示されます) } nodelist { node { ring0_addr: 192.168.179.1 name: ラズパイ1号機 nodeid: 1 } node { ring0_addr: 192.168.179.2 name: ラズパイ2号機 nodeid: 2 } } quorum { provider: corosync_votequorum two_node: 1 } logging { to_logfile: yes logfile: /var/log/corosync/corosync.log to_syslog: yes timestamp: on } quorumセクションはクラスタノードのどちらをアクティブとするかを判定する設定がされています。 今回は2ノードのみのため、2ノードで動作できる設定を入れております。 loggingセクションは、Corosync動作時のエラーログやイベント履歴を、指定したファイルとシステムログ双方に、日時付きで詳細に残す設定が入っております。 3. クラスタ認証設定 クラスタを起動していきます。 ＃sudo systemctl start corosync ＃sudo systemctl start pacemaker 1号機と2号機のノード認証を行い、クラスタ構成を作成します。 ＃pcs cluster auth ラズパイ1号機 ラズパイ2号機 ＃pcs cluster setup –name iot-cluster ラズパイ1号機 ラズパイ2号機 ＃pcs cluster start –all 4. リソース設定(仮想IPリソース) 続いて、仮想IPリソースの作成をしていきます。 ここで注意点があるのですが、仮想IPリソースを作成するのは1号機のみで実施します。 実は、1号機2号機ともに作成を最初しており、上手く動作しないなーということに陥っておりましたので、 皆様はお気を付けください。 ■設定値 – 仮想IPにしたいIPアドレス ： 192.168.179.100 – サブネット（netmask） ： /24（255.255.255.0の場合） – リソース名 ： my-vip ■実行コマンド ＃pcs resource create my-vip ocf:heartbeat:IPaddr2 ip= 192.168.179.100 cidr_netmask=24 op monitor interval=30s ■作成後の状態確認 ＃pcs status 仮想IP( my-vip )が「Started on <ノード名>」のように表示されていれば成功です。 これで、ノード障害が発生したとしても、仮想IPが自動で生きているノードに引き継がれます。 これにてクラスタ設定は完了となります。 動作確認 1. スイッチオーバー（手動） クラスタの動作確認をしていきたいと思います。 まずはスイッチオーバーと呼ばれる手動にて行うリソース移動を確認していきます。 コマンドを実行して、1号機⇒2号機へ仮想IPリソースが移動するか見ていきましょう。 事前確認でリソースがどちらのノードにあるか確認します。 ■事前確認 ＃pcs status Cluster name: クラスタ名 Status of pacemakerd: ‘Pacemaker is running’ (last updated 2025-10-29 16:53:16 +09:00) Cluster Summary: * Stack: corosync * Last updated: Wed Oct 29 16:53:17 2025 * 2 nodes configured * 1 resource instance configured Node List: * Online: [ ラズパイ1号機 ラズパイ2号機 ] Full List of Resources: * my-vip (ocf:heartbeat:IPaddr2): Started ラズパイ1号機 Daemon Status: corosync: active/enabled pacemaker: active/enabled pcsd: active/enabled 仮想IPリソース(my-vip) の箇所に記載のあるノードが、現在、仮想IPリソースを所持しているノードになります。 そのため、現時点では ラズパイ1号機 に仮想IPリソースがあること確認できました。 それでは、1号機から2号機へリソースを移動させたいと思います。 実施方法としては、以下コマンドを実行します。 ■リソース移動コマンド実行 ＃pcs resource move my-vip ラズパイ2号機 ■スイッチオーバー後の確認 ＃sudo pcs status Cluster name: クラスタ名 Status of pacemakerd: ‘Pacemaker is running’ (last updated 2025-10-29 16:55:19 +09:00) Cluster Summary: * Stack: corosync * Last updated: Wed Oct 29 16:55:20 2025 * 2 nodes configured * 1 resource instance configured Node List: * Online: [ ラズパイ2号機 ラズパイ1号機 ] Full List of Resources: * my-vip (ocf:heartbeat:IPaddr2): Started ラズパイ2号機 Daemon Status: corosync: active/enabled pacemaker: active/enabled pcsd: active/enabled 仮想IPリソース(my-vip) の箇所を確認すると、 ラズパイ2号機 の表記があり、1号機から2号機へ変更されていましたので、無事スイッチオーバーが出来たことを確認しました。 2. スイッチバック（手動） 続いて、2号機⇒1号機へコマンドを実行して、仮想IPリソースを戻せるか確認します。 ■事前確認 ＃ pcs status Cluster name: クラスタ名 Status of pacemakerd: ‘Pacemaker is running’ (last updated 2025-10-29 17:07:59 +09:00) Cluster Summary: * Stack: corosync * Last updated: Wed Oct 29 17:08:00 2025 * Last change: Wed Oct 29 17:07:28 2025 by root via cibadmin on ラズパイ2号機 * 2 nodes configured * 1 resource instance configured Node List: * Online: [ ラズパイ2号機 ラズパイ1号機 ] Full List of Resources: * my-vip (ocf:heartbeat:IPaddr2): Started ラズパイ2号機 Daemon Status: corosync: active/enabled pacemaker: active/enabled pcsd: active/enabled ■リソース移動コマンド実行 ＃pcs resource move my-vip ラズパイ1号機 ■スイッチバック後の確認 sudo pcs status Cluster name: クラスタ名 Status of pacemakerd: ‘Pacemaker is running’ (last updated 2025-10-29 17:13:58 +09:00) Cluster Summary: * Stack: corosync * Last updated: Wed Oct 29 17:13:59 2025 * Last change: Wed Oct 29 17:13:44 2025 by root via cibadmin on ラズパイ1号機 * 2 nodes configured * 1 resource instance configured Node List: * Online: [ ラズパイ1号機 ラズパイ2号機 ] Full List of Resources: * my-vip (ocf:heartbeat:IPaddr2): Started ラズパイ1号機 Daemon Status: corosync: active/enabled pacemaker: active/enabled pcsd: active/enabled 3. フェイルオーバー（自動） 最後の動作確認として、フェイルオーバーと呼ばれる、リソースが自動で移動されるかを確認します。 1号機で疑似障害を起こし、2号機へ仮想IPリソースが自動で移動するか確認します。 疑似障害としては、1号機-HUB間のLANケーブルを抜線し、疎通ができない状態にします。 抜線後、2号機にて確認コマンドを実行し、仮想IPリソースが移動していましたら、フェイルオーバーされていると判断します。 ■フェイルオーバー動作イメージ ■事前確認 ＃pcs status Cluster name: クラスタ名 Status of pacemakerd: ‘Pacemaker is running’ (last updated 2025-10-29 17:23:32 +09:00) Cluster Summary: * Stack: corosync * Last updated: Wed Oct 29 17:23:33 2025 * Last change: Wed Oct 29 17:13:44 2025 by root via cibadmin on ラズパイ1号機 * 2 nodes configured * 1 resource instance configured Node List: * Online: [ ラズパイ2号機 ラズパイ1号機 ] Full List of Resources: * my-vip (ocf:heartbeat:IPaddr2): Started ラズパイ2号機 Daemon Status: corosync: active/enabled pacemaker: active/enabled pcsd: active/enabled ■1号機-HUB間のLANケーブルを抜線 ■フェイルオーバーされたか、仮想IPリソースの確認 ＃ pcs status Cluster name: クラスタ名 Status of pacemakerd: ‘Pacemaker is running’ (last updated 2025-10-29 17:37:32 +09:00) Cluster Summary: * Stack: corosync * Last updated: Wed Oct 29 17:37:33 2025 * Last change: Wed Oct 29 17:23:33 2025 by root via cibadmin on ラズパイ1号機 * 2 nodes configured * 1 resource instance configured Node List: * Online: [ ラズパイ2号機 ] * Offline: [ ラズパイ1号機 ] Full List of Resources: * my-vip (ocf:heartbeat:IPaddr2): Started ラズパイ2号機 Daemon Status: corosync: active/enabled pacemaker: active/enabled pcsd: active/enabled my-vip の箇所に無事2号機のノード名があり、フェイルオーバーの確認ができました。 また、Node Listの1号機の表示がOflineとなっており、2号機のみOnline(稼働の確認が取れている状態)となりました。 最後に Pacemaker + Corosyncを使えば、IoT環境でも高可用性を実現できることが確認できました。 LifeKeeper製品を取り扱う、LifeKeeperチームとして、今回IoT環境での冗長化や障害対応の仕組みを実際に検証していき、普段とは違う試みが出来たと感じました。 今後も色んな活用方法を実践していきたいと思います。
動画
書籍
