温度測定の手書き・手入力を減らすには？M5Stickとサーマルカメラを業務につなぐ

温度を測り、紙に書き、事務所でExcelやkintoneへ入力する。測定器がデジタルでも、この流れが残っていれば、記録の仕事は人の手に残ります。

シルバーウィークのIoTの題材は、M5Stickとサーマルカメラです。手のひらサイズの端末に温度の分布を表示しています。ここから考えたいのは、測定値を自分たちの業務へどう届けるかです。

自作IoTの価値は、取得したデータをExcel・kintone・クラウド・自社システムへ自動連携し、分析や判断まで、自分たちの仕事に合わせて組み立てられることにあります。

この記事では、メーカーやサービス提供元の公式資料を調べ、連携の方法と実務上の条件を整理しました。写真で示しているのは熱画像の表示です。以下の自動記録・業務連携・AI分析は、そこから発展させる設計例として紹介します。

測定器を買っても、転記の仕事が残る理由

測定して画面に表示する機能だけでは、「どの設備の、いつの、どの場所の値か」を業務システムへ届けるところまで完結しません。人が数字を読み取り、紙に手書きし、別の画面へ打ち直すことになります。

写真を保存できる機種でも、ファイルを探す、設備名を付ける、台帳へ数値を写す作業が残る場合があります。確認したいのは測定性能に加えて、測った後に誰が何をするのかです。

ただし、「市販品では自動化できない」という意味ではありません。例えばFLIRには、対応カメラの画像をクラウドへ自動アップロードする仕組みがあります。インターネット接続やアカウントとの連携が必要です。FLIR公式のクラウド接続説明

自社の設備番号や点検台帳まで結び付くか、必要な形式でデータを取り出せるか、既存製品の連携機能で足りるか。その先に、自作や追加開発の必要性があります。

小さな端末で、測定と業務をつなぐ

M5Stickは、画面を備えた小型の開発用端末です。シリーズの一例であるStickC-Plus2にはWi-Fiと外部機器用の接続端子が用意されています。ここで挙げる仕様は同機種の公式情報で、写真の機器の型番を断定するものではありません。M5Stack公式資料

サーマルカメラは、赤外線を捉えて温度の分布を画像として示す機器です。数字を一つ表示する温度センサーとは異なり、対象のどのあたりに温度差があるかを見られます。

業務へつなぐ構成例は、次の流れです。

センサー → M5Stick → 通信・受信処理 → データ保存 → 業務画面・分析・通知

端末側で測定し、Wi-Fiなどでデータを送り、受信側で記録を整えて保存します。自作することで、送る項目、タイミング、対象設備との対応、表示や通知の方法を調整できます。機器を接続するだけで全部が動くわけではなく、送受信処理と連携先に応じた設定を作ります。

Excel・kintone・クラウド・自社システムへの連携方法

Excel：普段の帳票へ届くようにする

Microsoftは、Excelのテーブルへ行を追加するAPIを公開しています。APIは、プログラム同士がデータを受け渡すための窓口です。また、Power Automateなどから使うExcel Online（Business）コネクタには、テーブルへ行を追加する機能があります。Microsoft Graph公式資料、Excel Online（Business）公式資料

例えば、受信した設備番号・測定日時・温度を表へ追記し、担当者は集計済みのシートを見る構成にします。ローカルのExcelファイルへ何でも直接送れるという意味ではなく、保存場所、接続方法、認証、権限に合わせた設計が必要です。

Excel Online（Business）では、複数の接続元から同じファイルを同時に変更する使い方に制約があります。大量の測定値を直接書き続けるより、データベースに蓄積し、必要な集計だけExcelへ届ける構成が適する場合があります。これは公式の制約を踏まえた設計上の判断です。

kintone：記録と対応履歴を一緒に扱う

kintoneには、外部からアプリへレコードを登録するREST APIがあります。測定データをアプリの項目に対応付ければ、画面へ手入力せずに記録できます。サイボウズ公式・レコード登録API

測定結果の隣に、担当者の確認、設備の状態、実施した対応を残せるようにすれば、単なる数値の保管から点検業務へつながります。APIの実行上限や権限は、利用コース・設定を確認します。高頻度の全データを送るか、集計値や確認が必要なイベントだけ送るかを分ける設計が有効です。kintone REST API共通仕様

クラウド：蓄積と処理をまとめる

クラウドへデータを受け取り、保存、集計、通知へ振り分ける構成もあります。例えばAWS IoT Coreでは、機器から届くメッセージに応じて、データベースへの書き込みや別の処理の呼び出しができます。AWS IoT Core公式資料

端末が増えても同じ形式でデータを扱いやすくなります。一方、通信できなかった場合の扱い、費用、運用担当、アクセス権まで含めて設計します。クラウドを使うこと自体が目的にはなりません。

自社システム：今の仕事の流れに合わせる

自社システムにデータを受け取るAPIがあれば、そこへ連携します。APIがなければ、システム管理者や開発元と、CSV取込や中継処理などの利用可否を確認します。

設備台帳や作業指示と同じ識別番号を使うことが大切です。新しい温度グラフだけが別画面に増えても、現場の確認作業が減るとは限りません。

AIを活用する前に、分析できる記録を残す

AIによる自動分析・活用まで広げるには、温度と一緒に、その数字の意味が分かる情報を残します。設計例として、次の項目が考えられます。

熱画像の色だけをAIへ見せるより、元の数値データや測定条件を併せて扱える設計を考えます。同じ色でも、画像の表示範囲や設定が違えば同じ温度とは限りません。

活用は、目的に応じて分けます。

• 決めた条件での集計・通知：上限を超えた、測定が途切れた、といった判定は通常のプログラムで実装できます。これをすべてAIと呼ぶ必要はありません。
• 機械学習による変化の検出：蓄積データから普段の傾向を捉え、違いのある記録を確認候補として示す方法です。正常時のデータ、設備の状態、誤検知の評価が必要です。
• 生成AIによる説明・日報案：集計結果や対応履歴をもとに、変化と確認事項を文章へまとめる使い方です。元データへ戻れるリンクや測定時刻を添えると、人が確かめやすくなります。

生成AIは、もっともらしい誤りを出すことがあります。NISTもこの問題をリスクとして整理しています。温度変化の原因を断定させず、数値計算は集計処理で行い、人の点検や判断を支える用途から始めるのが私の提案です。NIST・生成AIリスク管理資料

「測れているか」と「届いているか」を確かめる

サーマルカメラの表示値は、対象表面の状態や周囲からの反射に影響されます。光沢のある金属では、対象そのものより反射した熱の影響を強く受ける場合があります。放射率は、物体の表面が赤外線を放射する性質を表す値です。FLIR公式・放射率の解説

撮影位置、距離、角度、測定領域をそろえ、必要に応じて別の適切な測定方法とも照合します。用途によっては、熱画像より接触式の温度センサーが合うこともあります。測定器を選ぶ段階で、何を判断したいのかを先に決めます。

通信側も同様です。送信に失敗したら一時保存して再送する、同じ記録が重複して登録されないよう識別子を付ける、最後に受信した日時を表示する、といった仕組みが必要になります。データが来ていないのに、画面だけが以前の正常値を示し続けないようにします。

自作する範囲は、減らしたい仕事から決める

既存製品で必要な連携までできるなら、それを使う選択があります。測定の信頼性や保守体制を重視する場面では、市販品の機能に連携処理を追加する方法も考えられます。

自作が向くのは、測定項目や設置方法を試したい、既存台帳へ独自の形式で送りたい、業務の変化に合わせて処理を直したい、といった場面です。部品代に加えて、開発、筐体、電源、検証、保守、故障時の代替まで含めて比較します。

まずは、安全に試せる対象を一つ選びます。「どの記録を、誰が、どこへ写しているか」を整理し、一つの測定項目が目的の記録先まで正しく届くところを確認します。人が入力し直す箇所、通信が途切れたときの動き、確認後の対応まで試してから、対象を広げます。

小さなM5Stickからでも、仕事につながる仕組みは考えられます。測定のたびに紙へ書いている数字が、そのまま記録され、必要な人へ届き、AIによる分析にも使える。その流れを現場に合わせて作ることが、自作IoTの面白さです。

調査日：2026年9月22日。本文のリンクはメーカー・サービス提供元などの一次資料です。製品の対応範囲やAPIの条件は導入時にも確認します。