前回はenebularで簡単なリモートMCPサーバーを作ってみましたが、今回はenebularのデータストアを使って、Raspberry Piでセンサーデータをデータストアに収集し、そのデータを取得できるリモートMCPサーバーを作ってみました。
あと簡単に自分だけアクセスできる仕組みも追加してみました。
簡易的なものなので、完璧ではありません。
データストアのテーブル作成
最初にセンサーデータを入れるためのデータストアのテーブルを作ります。
ダッシュボードのメニューからデータストア画面を表示し、右下の＋ボタンをクリックします。
次の内容で設定します。
テーブルの作成が終わったら設定画面からテーブルIDをメモしておきます。
フローの構成
センサーMCPサーバー
フローは、discoverで公開しています。
メインフロー
メインフローは前回と同じです。
データストアとAPIキーの指定用に次のような環境変数を使用しています。
| 変数名 | 説明 | 備考 |
|---|---|---|
| TABLE_ID | 作ったデータストアのテーブルIDを指定します。 | - |
| API_KEY | 任意の文字列を指定します。 | - |
フローエディタで動作させるときは、フローの概要画面から設定します。
クラウド実行環境の場合は、設定画面から設定することができます。
また、クラウド実行環境の場合は、データストアへの接続をONにすることを忘れないでください。
MCPメッセージ処理用のサブフロー
前回のフローから簡易APIキー認証、tools/list応答の内容、ツールの処理を変更しています。
センサーデータ収集
フローは、discoverで公開しています。
センサーデータの収集は、Raspberry Pi 5とオムロンのセンサー2JCIE-BU01を使ってます。
Raspberry Pi OSを使用し、エージェント実行環境をインストールしています。
オムロンのセンサーを使うための設定は、この記事を参考にしてください。
フローは次のようになっています。環境変数で指定した周期でセンサーデータを取得し、データストアに書き込みます。
環境変数は、次の値を設定します。
| 変数名 | 説明 | 備考 |
|---|---|---|
| TABLE_ID | 作ったデータストアのテーブルIDを指定します。 | - |
| DEVICE_ID | 任意の文字列を指定します。 | - |
| INTERVAL_SEC | 秒でセンサーデータを記録する周期を指定します。 | 例：600だったら10分 |
エージェント実行環境は、設定画面から環境変数の設定ができます。設定すると遠隔で書き込まれます。
フローの動作確認
データストアの作成、フローのデプロイ、環境変数の設定が終われば、動作可能です。
LLMは、Claude Desktopを使用しました。
Claude DesktopでのMCPサーバーの設定は、設定メニューから開発者を開き、設定を編集をクリック。
claude_desktop_config.jsonをテキストエディタで開き、以下を記載して保存します。
（すでに他のMCPサーバーを設定している場合は、get-sensor-dataの内容を追記してください。）
{
"mcpServers": {
"get-sensor-data": {
"command": "npx",
"args": [
"mcp-remote",
"https://{フローエディタのURL、クラウド実行環境のURL}/{フローエディタの場合はmcp-server、クラウド実行環境の場合は設定したパス}/mcp",
"--header",
"api-key:${APIKEY}"
],
"env": {
"APIKEY": "環境変数で指定したAPIキーを設定"
}
}
}
}
ファイルを保存したら、いったんClaude Desktopは終了します。
（Windowを閉じただけだと終了しないので、タスクトレイ等から終了をしてください）
再び、Claude Desktopを起動し、新規チャット等の検索とツールで、get-sensor-dataが追加されていれば成功です。
プロンプトで、以下のように入力します。センサーデータを取得し始めたばかりの場合は、期間を調整して指定してください。
(センサーIDはエージェント実行環境の環境変数で指定した文字列を記入してください)
センサーIDがsensor001のセンサーは仕事部屋の環境センサーです。 ここ1週間の環境を評価して
次のように許可を求められるので許可します。
成功すれば、次のように取得したセンサーデータから解説してくれます。
1週間分のセンサーデータを取得しました。仕事部屋の環境を分析して評価いたします。
仕事部屋の環境評価レポート(2026年1月12日〜1月18日)
📊 主要項目の評価
温度環境:★★★☆☆(3/5)
平均温度:約21℃
変動範囲:17℃〜27℃
日中は23℃〜26℃程度まで上昇し、夜間は18℃〜20℃程度に低下
評価:昼夜の温度差がやや大きめです。昼間に暖房を使用しているようですが、夜間は18℃前後まで下がっています
湿度環境:★★☆☆☆(2/5)
平均湿度:約45%
変動範囲:38%〜57%
特に1月12日〜14日は42%〜44%と低め
評価:全体的に低めで、冬場としては乾燥気味です。快適湿度の40〜60%の範囲にはありますが、下限寄りです
空気質(CO2):★★★★☆(4/5)
平均:約900ppm
ピーク値:2,621ppm(1月12日6時頃)、3,033ppm(1月14日17時40分頃)
評価:ほとんどの時間帯で1,500ppm以下で良好ですが、早朝や夕方に急上昇する時間帯があります
空気質(TVOC):★★★★☆(4/5)
平均:約200ppb
ピーク値:2,921ppb(1月14日17時40分頃)、2,469ppb(1月14日17時50分頃)
評価:通常は200ppb以下で良好ですが、1月14日の夕方に異常な高値を記録しています
照度:★★★★☆(4/5)
昼間は15〜22 luxの自然光
夜間は0 lux(照明を消灯)
評価:昼夜のリズムが明確で良好です
騒音レベル:★★★★★(5/5)
平均:約45dB
変動範囲:33〜82dB
評価:一般的に静かな環境が維持されています
⚠️ 注意すべきポイント
急激な空気質の悪化
1月14日の17時40分頃、CO2が3,033ppm、TVOCが2,921ppbに急上昇
何らかの活動(料理、掃除用品の使用など)による可能性があります
朝の空気質
早朝(6時前後)にCO2が1,500〜2,600ppm程度まで上昇
夜間の換気不足が原因と考えられます
湿度の低さ
冬場で暖房使用のため乾燥しがちです
加湿器の使用を検討してください
💡 改善提案
換気の強化
起床後すぐに窓を開けて換気
日中も1〜2時間に1回、5〜10分程度の換気を推奨
加湿対策
湿度を50%前後に保つよう加湿器の使用を検討
観葉植物の設置も効果的です
温度管理
夜間の温度低下を防ぐため、就寝前の暖房設定を見直し
18℃以下にならないよう調整することをお勧めします
総合評価:★★★☆☆(3/5)
全体的には許容範囲内の環境ですが、換気と湿度管理に改善の余地があります。特に朝の空気質と冬場の乾燥対策を行うことで、より快適な仕事環境になるでしょう。
フローの解説
センサーMCPサーバーの変更したMCPメッセージ処理用のサブフローを解説します。
簡易APIキー認証
自分以外がデータを取得しないようにするAPIキー認証の部分は簡易的なものです。
環境変数で指定した値とリクエストのヘッダーに含まれるAPIキーを比較してるだけです。
tools/list応答
ツールとして、get_sensor_dataというツールを定義して返すように変更しています。
引数の意味合いや必須項目を定義しています。
{
"jsonrpc": '2.0',
"id": id,
"result": {
"tools": [
{
"name": "get_sensor_data",
"description": "指定されたセンサーIDと時間範囲のセンサーデータを取得できます",
"inputSchema": {
"type": "object",
"properties": {
"id": {
"type": "string",
"description": "センサーIDを指定します"
},
"startTime": {
"type": "string",
"format": "date-time",
"description": "取得開始時刻（ISO 8601形式）例：日本標準時の場合は2026-01-01T00:00:00+09:00"
},
"endTime": {
"type": "string",
"format": "date-time",
"description": "取得終了時刻（ISO 8601形式）例：日本標準時の場合は2026-01-01T23:59:59+09:00"
},
"limit": {
"type": "number",
"description": "一度に読み出すデータの数"
},
"mainKey": {
"type": "string",
"description": "再読み出す際のメインキー"
},
"sortKey": {
"type": "number",
"description": "読み出す際のソートキー"
}
},
"required": ["id", "startTime", "endTime"]
}
}
]
}
}
データストア上では、センサーデータのタイムスタンプ(ts)として、unix時刻で保存していますが、試した限りLLMはunix時刻を指定するのが苦手らしく、ISO8601形式で指定するようにしています。フローの中で、ISO8601⇔unix時刻変換しています。
ツール:get_sensor_data
ツールとして、get_sensor_dataが呼ばれた場合は、LLMから指定された引数をデータストアへアクセスするための値に変換してデータを読みだしています。
読み出したデータは、時刻だけ変換して出力しています。
今後は
今回は、データストアから読み出すパターンを試しましたが、LLMからデータストアにデータを書き込むこともできると思うので、相互にできるように何か試してみたいと思います。