はじめに ―「画像って、どう扱えば正解なんだ？」から始まった一日
前回の記事では、MQTT や HiveMQ を中心にリモート通信の仕組みづくりをまとめました。
(👉 前回: https://qiita.com/GGT1629/items/f744dae9276a84fd80d0)
今回は、画像が実際に流れ始めたその後のストーリーです。
Raspberry Pi → Gyazo API → Node-RED → フロントエンド。
この一連の流れの中で、
「あれ？画像バッファってどうやって扱う？」
「URLはどこで取得すべき？」
「最新画像とログ画像、どう両立する？」
といった技術的なハードルが次々と登場しました。
この記事では、議事録をもとに実際に起きた混乱・気づき・改善をストーリー形式でまとめます。
問題点 ― バッファ沼にハマる。JSON地獄に落ちる。そして気づく。
1. Gyazo APIキーを Node-RED にどう渡す？
- APIキーの定義場所（Function Node？Change Node？）で混乱
- 部分コピーによる設定ミスが多発
- 「JSONインポートすれば一発」という真理に到達
2. バッファが壊れる
- 画像データは文字列ではなく バイナリバッファ
- なのに「文字列のまま変換しようとして失敗」する事故が発生
-
Failed Parse Form Dataの赤エラーが連発
3. Node-REDの目視設定は危険
- JSON設定を目視で再現するとプロパティ名のブレが発生
- AIのコード補助は便利だが、ノード設定は正確に写経が必要
つまり、画像処理の問題は「コード」ではなく「設定」がボトルネックでした。
解決策 ― Gyazo の強み × Node-RED の柔軟性 × MQTT の軽量性
解決策1：Gyazo API の採用が決定打に
Gyazo の良いところは…
- アップロードした瞬間にパーマリンクURLが返る
- URL生成をクライアント側でやらなくてよい
- バッファ形式で返されるJPEGは Node-RED と相性◎
Gyazo から返ってきた URL は MQTT で通知、
Node-RED が HTTP GET して保存する構成に決定しました。
解決策2：LATEST_JPEG と 日時付きJPEG の“二刀流保存”
議論の結果、画像保存はシンプルに 2系統 にまとめられました。
| 保存方式 | 役割 |
|---|---|
| LATEST_JPEG | フロントエンドが常に参照する“最新画像” |
| timestamped_YYYYMMDD-HHMMSS.jpeg | ログとして履歴管理する“証跡” |
なぜこの構成が良いのか？
- DB不要
- ファイル名で時系列が自然に並ぶ
- Express/Node.js の静的ファイル提供が超簡単
- フロントエンドは常に
/static/LATEST_JPEGを表示するだけ
「最新」と「履歴」の矛盾を完全に解消したバランスの良い設計です。
解決策3：MQTT＋HTTP GET のハイブリッド構成
今回の構成はかなりスマートです。
-
MQTT
- 「新しい画像ができたよ！」という通知だけを送る
-
Node-RED
- その通知を受けて HTTP GET で画像を取得
- LATEST_JPEG と ログJPEG を生成
-
フロントエンド
- LATEST_JPEG を自動リロードして表示
MQTTは軽量通知、HTTPはデータ取得。
役割分担が完璧です。
実装 ― バッファ処理の闘いと、JSONフローの救世主
バッファ問題を突破したポイント
- Node-RED HTTP Request Node を「バイナリモード」に設定
-
msg.payloadはバッファとして扱う - そのまま File Node に渡せばOK（文字列変換不要）
JSONインポートの重要性
議論の中で強く共有された結論はこれ：
Node-REDはJSONインポートを使わないと沼る。
目視でフローを再現すると100%事故が起きる。
プロパティ名1文字違うだけでバッファが壊れる。
（これは多くの人が通る道…！）
結論 ― 「最新」と「履歴」を両立できる、ミニマムで強い構成が完成した
今回の議論と実装の結果、システムの土台が一気に強化されました。
完成した設計のポイント
- Gyazo APIで画像URLを自動生成
- MQTTで画像更新の通知
- Node-REDがHTTP GETで画像取得
- LATEST_JPEGで最新画像を即参照
- 日時付きJPEGでログ保存
- フロントエンドは静的パスを参照するだけ
これにより、
リアルタイム性 × ログ保存 × 実装の簡易さ
をすべて両立した、“美しい構成” が生まれました。
最後に ― この構成はどんなプロジェクトにも応用できる
- Raspberry Pi のカメラシステム
- IoTデータ収集デバイス
- 監視カメラ
- センサーデータログ
- Web アプリ側への画像提供
など、幅広い用途で同じ設計が活躍します。