グラフDBとIoT

2026.5.30 (Sat)
SORACOM UG 山梨 #1
https://soracomug-tokyo.connpass.com/event/388799/

Transcript

1. 2026-05-30(Sat) SORACOM UG 山梨 #1 ko2a (こにゃ) グラフDBとIoT
2. 沖 幸一郎 / Oki Koichiro / ko2a (こにゃ) ・長野県安曇野市在住 ・株式会社DOA 　　クラウド系（AWS/Cloudflare/kintoneなど） 　　組み込み開発（医療機器/複合機/車載機器など） 　　社内インフラ管理者（MS365/Cloudflareなど） 　　見習いSA？ 　　オフィスレイアウト設計 ・コミュニティ運営おじさん 　・SORACOM UG 信州 コアメンバー 　・SORACOM UG 農業活用コミュニティ コアメンバー Who am I?
3. グラフデータベース Graph Database https://neo4j.com/blog/graph-database/what-is-a-graph-database/
4. グラフ構造を備えたデータベースのことである。 データの構造が従来のリレーショナルではなくネットワーク状になっている場合に、 格納・検索の面で威力を発揮する。 グラフデータベースとは https://www.imagazine.co.jp/12805-2/
5. 【特徴】 ・関係をそのまま表現できる ・関係探索が得意 ・ネットワーク構造と相性が良い グラフデータベースとは
6. 比較：リレーショナルデータベース https://aws.amazon.com/jp/compare/the-difference-between-graph-and-relational-database/ リレーショナルデータベースは、データの完全性をしっかりとサポートする構造化され たスキーマを提供します。次のようなシナリオでは、リレーショナルデータベースの方 が適しています。 金融取引のように、ACID 準拠と高いレベルのデータの完全性と整合性が必要な場 合 エンタープライズリソース管理のように、表形式のデータモデルにうまく適合する 高度に構造化されたデータを扱っている場合 扱っているデータに限られた関係しかない場合
7. 比較：グラフデータベース https://aws.amazon.com/jp/compare/the-difference-between-graph-and-relational-database/ グラフデータベースは、データの動的な変更と適応を可能にする柔軟なスキーマを提供 します。 データ関係に重点を置いているため、分析、セマンティック検索、またはレコメンデー ションエンジンに役立ちます。 次のようなシナリオでは、グラフデータベースの方が適しています。 ソーシャルネットワーク、不正検出、ナレッジグラフ、セキュリティグラフ、パー ソナライズされたレコメンデーションエンジンなど、複雑な関係を持つデータを扱 っている データベース構造の他の部分に影響を与えることなく、エッジ、ノード、プロパテ ィを修正するため、進化するスキーマを必要としている 相互接続されたデータを利用しており、関係間で複数または不明な数のホップを実 行する必要がある (Friend-of-Friend タイプのクエリ) グラフデータベースは、柔軟性があり、スケーラブルで、動的で、かつデータ間の関係 を示すのに優れています。
8. IoTとグラフデータベースの 関わり方
9. ［工場］ A工場／B工場／C工場／D工場／E工場 ［ライン］ A～C工場は20ライン D～E工場は10ライン ライン名はA-01やD-10のようなルール ーブルデータを作ってほしい 説明用の構成イメージサンプル ［ラインのセンサー］ 工程毎に装置がある 工程は01～20程度 ［担当者］ 工程毎に専任担当者がいる
11. １．センサー異常から、工場・ライン・工程・装置・担当者を取得 ２．あるセンサーから通知先を取得 ３．A-01ラインの全センサーをRAWデータ検索条件として取得 ４．A-01-P10工程から前後工程を辿る例 シチュエーション例 https://www.imagazine.co.jp/12805-2/
12. RDBの場合
13. RDBの場合 １．センサー異常から、工場・ライン・工程・装置・担当者を取得 SELECT a.alert_id, a.alert_type, a.value, a.occurred_at, f.factory_name, l.line_name, pr.process_name, e.equipment_name, s.sensor_name, pe.person_name, pe.phone, pe.email FROM alerts a JOIN sensors s ON a.sensor_id = s.sensor_id JOIN equipments e ON s.equipment_id = e.equipment_id JOIN processes pr ON e.process_id = pr.process_id JOIN lines l ON pr.line_id = l.line_id JOIN factories f ON l.factory_id = f.factory_id JOIN process_persons pp ON pr.process_id = pp.process_id JOIN persons pe ON pp.person_id = pe.person_id WHERE a.alert_id = 'AL-00001';
14. RDBの場合 ２．あるセンサーから通知先を取得 SELECT s.sensor_id, f.factory_name, l.line_name, pr.process_name, e.equipment_name, pe.person_name, pe.phone, pe.email FROM sensors s JOIN equipments e ON s.equipment_id = e.equipment_id JOIN processes pr ON e.process_id = pr.process_id JOIN lines l ON pr.line_id = l.line_id JOIN factories f ON l.factory_id = f.factory_id JOIN process_persons pp ON pr.process_id = pp.process_id JOIN persons pe ON pp.person_id = pe.person_id WHERE s.sensor_id = 'S-0001';
15. RDBの場合 ３．A-01ラインの全センサーをRAWデータ検索条件として取得 SELECT s.sensor_id, s.sensor_name FROM lines l JOIN processes pr ON l.line_id = pr.line_id JOIN equipments e ON pr.process_id = e.process_id JOIN sensors s ON e.equipment_id = s.equipment_id WHERE l.line_id = 'A-01' ORDER BY pr.process_no;
16. RDBの場合 ４．A-01-P10工程から前後工程を辿る例 SELECT cur.process_id AS current_process, prev.process_id AS previous_process, next.process_id AS next_process FROM processes cur LEFT JOIN processes prev ON cur.previous_process_id = prev.process_id LEFT JOIN processes next ON next.previous_process_id = cur.process_id WHERE cur.process_id = 'A-01-P10';
17. グラフDBの場合
18. グラフDBの場合 １．センサー異常から、工場・ライン・工程・装置・担当者を取得 MATCH (a:AlertEvent {alert_id:'AL-00001'}) -[:DETECTED_BY]->(s:Sensor) -[:MONITORS]->(e:Equipment) -[:INSTALLED_IN]->(pr:Process) -[:PART_OF]->(l:Line) -[:BELONGS_TO]->(f:Factory) MATCH (person:Person)-[:RESPONSIBLE_FOR]->(pr) RETURN a.alert_id AS alert_id, a.alert_type AS alert_type, a.value AS value, a.occurred_at AS occurred_at, f.name AS factory_name, l.name AS line_name, pr.name AS process_name, e.name AS equipment_name, s.name AS sensor_name, person.name AS person_name, person.phone AS phone, person.email AS email;
19. グラフDBの場合 １．センサー異常から、工場・ライン・工程・装置・担当者を取得
20. グラフDBの場合 ２．あるセンサーから通知先を取得 MATCH (s:Sensor {sensor_id:'S-0001'}) -[:MONITORS]->(e:Equipment) -[:INSTALLED_IN]->(pr:Process) -[:PART_OF]->(l:Line) -[:BELONGS_TO]->(f:Factory) MATCH (person:Person)-[:RESPONSIBLE_FOR]->(pr) RETURN s.sensor_id AS sensor_id, f.name AS factory_name, l.name AS line_name, pr.name AS process_name, e.name AS equipment_name, person.name AS person_name, person.phone AS phone, person.email AS email;
21. グラフDBの場合 ２．あるセンサーから通知先を取得
22. グラフDBの場合 ３．A-01ラインの全センサーをRAWデータ検索条件として取得 MATCH (s:Sensor) -[:MONITORS]->(:Equipment) -[:INSTALLED_IN]->(pr:Process) -[:PART_OF]->(l:Line {line_id:'A-01'}) RETURN s.sensor_id AS sensor_id, s.name AS sensor_name ORDER BY pr.process_no;
23. グラフDBの場合 ３．A-01ラインの全センサーをRAWデータ検索条件として取得
24. グラフDBの場合 ４．A-01-P10工程から前後工程を辿る例 MATCH (cur:Process {process_id:'A-01-P10'}) OPTIONAL MATCH (prev:Process)-[:UPSTREAM_OF]->(cur) OPTIONAL MATCH (cur)-[:UPSTREAM_OF]->(next:Process) RETURN cur.process_id AS current_process, prev.process_id AS previous_process, next.process_id AS next_process;
25. グラフDBの場合 ４．A-01-P10工程から前後工程を辿る例
26. まとめ
27. 【RDB】 ・業務システムの主役 ・高速な検索・集計 ・トランザクション管理が得意関係をそのまま表現できる ・デバイスからのデータ保存向き 【グラフDB】 ・関係性を直接保持 ・ネットワーク構造に強い ・影響範囲や関連探索が得意 ・デバイス情報の管理など まとめ
28. 【グラフDB】 関係性を管理する 　工場　→　ライン　→　工程　→　担当者 【GraphRAG】 関係性を辿りながら、AIが回答を生成する 　工場　→　ライン　→　工程　→　担当者　→　過去障害　→　手順書 【これからの活用】 ・デジタルツイン ・ナレッジ管理 ・IoTデータ活用 ・GraphRAG グラフDBの先にあるもの
29. ご清聴ありがとうございました GraphDBは「データを保存するDB」から、 「知識をつなぐ基盤」へ進化しつつある