データ処理とアーキテクチャ

IronFlock は、スケーラビリティ、セキュリティ、明確なデータ所有権を目的として設計された、エッジからクラウドまでのエンドツーエンドなデータ収集・保管インフラを提供します。数千のセンサーからのテレメトリを配信するケースでも、リアルタイム SCADA インターフェースを構築するケースでも、IronFlock のデータアーキテクチャは安全で分離された、アクセス可能な情報を保証します。

メッセージルーティングとセキュアレルム

IronFlock のリアルタイム通信の中核には、堅牢なメッセージルーティングクラスターがあります。このメッセージングインフラは、プロジェクト内の多様なエッジデバイスを相互に接続し、また IronFlock クラウドインフラにも接続します。

厳格なデータセキュリティと分離を確保するため、ルーティングクラスターはセキュアレルムに意味的に分割されています。レルムは隔離されたサブネットワークであり、メッセージは厳密にその中に閉じ込められます。データやコマンドはレルムを越えて移動することはありません。

エッジデバイス上で動作するアプリケーションは、ironflock-sdk を利用してこれらのメッセージングレルム上で次のいずれかの方式で通信できます：

• Publish/Subscribe (Pub/Sub)： センサーのテレメトリや状態変化を継続的にブロードキャストするのに最適です。
• Remote Procedure Calls (RPC)： アクションを直接トリガーしたり、デバイス状態を安全に問い合わせたりするのに最適です。

動的にプロビジョニングされるプロジェクトデータベース

永続的な保存と履歴分析のために、IronFlock はプロジェクトごとに専用の物理的な TimescaleDB データベースをプロビジョニングします。

このプロジェクトデータベースは、プロジェクトにインストールされたすべてのアプリにとってのデータ収集の中心拠点となります：

• アプリのデータバックエンド： プロジェクト内にインストールされたすべてのアプリのデータバックエンドは、このデータベース内に安全に格納されます。2 つ目のアプリをインストールすると、最初のアプリのテーブルと並んで独自のテーブルが追加されます — 複数のアプリを実行するプロジェクトでは、それらすべてのデータが一箇所に集約され、まとめてクエリできるようになります。
• 直接インジェスト： デバイスアプリが ironflock-sdk でデータをパブリッシュすると、そのストリームはプロジェクトデータベースに直接受信され、整理されます。
• 同意に基づく読み取りアクセス： アプリはデフォルトでは自身のデータのみを読み取りますが、あなたの承認があれば、同じプロジェクト内の別のアプリのデータを読み取ることもできます — これにより、アプリは互いの計測結果を土台にして構築できます。この共有はあなたが管理し、いつでも取り消せます（下記参照）。

プロジェクトデータベースはオペレーションの唯一のソース・オブ・トゥルースとして機能するため、高度な機能が開放されます：

• SQL クエリ： 履歴テーブルに対して直接強力なクエリを書けます。
• Physical AI 統合： IronFlock AI エージェントに自然言語でデータを抽出・分析・問い合わせさせられます。
• 可視化のソース： プロジェクトデータベースは、ライブボード、IoT ダッシュボード、SCADA ボードの究極のデータソースです。

カスタム変換

アプリが書き込むテーブルが、あなたの尋ねたい問いにちょうど合った形になっていることはめったにありません。設備総合効率は可用性・性能・品質を組み合わせたものですし、シフトレポートには 1 時間ごとのバケットが必要で、2 台の機械を比較するとなれば 2 つの異なるアプリのテーブルを結合することになります。カスタム変換は、そうした問いに一度だけ答えを用意します：名前を付けて保存した SQL クエリであり、保存したあとはプロジェクト内の他のテーブルとまったく同じように振る舞います。

作成はアプリ開発者の仕事ではありません。データアクセス権限を持つプロジェクトメンバー — SQL クエリコンソールを開けるのと同じ権限です — であれば誰でも変換を保存でき、生のテーブルには存在しない数値がボードに必要なときは、IronFlock AI アシスタントに依頼して作成させることもできます。変換はすべてのアプリの外側、プロジェクト自身の IronFlock 空間に置かれるため、1 つの変換でプロジェクトにインストールされたあらゆるアプリのテーブルを横断して読み取れます。

• クエリは一度書くだけ。 プロジェクトのデータビューのクエリコンソールで作り込み、変換として保存を選びます。あるいは、そこにある変換タブから直接作成します。ソーステーブルは databackend_<key>.<table> として参照します — データツリーが各アプリの隣に表示している名前です。
• 計算方法を選ぶ。 マテリアライズド変換は結果を保存し、あなたが設定したスケジュールで再計算します。スケジュールは 5 項目の cron 式で、先頭に秒の項目を加えた 6 項目でも指定できます。スケジュールされた実行で再計算されるのは、読み取るテーブルが前回の実行以降に変更された場合だけで、少なくとも 10 分ごとには再計算されます。マテリアライズド変換が更新されるタイミングを参照してください。通常のビューは読み取りのたびに計算されます：コンソールや SDK からのクエリは常に最新ですが、速さはそのクエリ次第です。どちらの種類であっても、変換にバインドされたボードがその結果を受け取るのは、あなたが設定したスケジュールのタイミングであり、その下にあるテーブルへの書き込みのたびではありません（後述のテーブルと同じようにバインドするを参照）。
• 何を返すのかを記述する。 変換には説明を付けられ、結果の各カラムにも表示名とそれぞれの説明を付けられます。これらは変換とともにデータベースに保存され、ウィジェットエディタが表示する内容であり、AI アシスタントが読み取る内容でもあります — よく記述された変換は、数か月後でもアシスタントが正しく使える変換です。
• テーブルと同じようにバインドする。 変換はウィジェットエディタのデータピッカーに、各アプリのテーブルと並んで IronFlock の下に現れ、同じライブチャネルに接続されます。スケジュールされた実行のたびに、それにバインドされたボードが結果を受け取ります。カスタム変換がボードに届く経路はこれだけであり、変換が読み取るテーブルへの書き込みでは届きません。（アプリが自身のデータテンプレートに同梱する変換は、これに加えてアプリのコードからも更新できます。オンデマンドでの更新を参照してください。）

変換は、エンティティの現在の状態を表示したり、削除済みレコードを非表示にしたりするための手段ではありません。エンティティごとの最新の行はウィジェットのフィルター設定にある latest トグルで得られ、削除済みレコードは deleted: true を持つ行であり、そのカラムに対するフィルターで非表示にします。どちらもテーブルそのものに対してライブで動作します：ウィジェットは新しい行をすべて 1 秒以内に追従しますが、変換であれば同じ行が次の実行のときにようやく表示されます。エンティティの最新状態の追跡とレコードの論理削除を参照してください。

行儀のよい変換を書く

変換は、自身の SQL が選択した行をそのまま返します。ウィジェットの時間ウィンドウ、カレンダーフィルター、latest モードはテーブルに適用されるものであり、ここでは無視されます。そこから、身に付けておく価値のある 3 つの習慣が導かれます：

• 時間範囲はクエリの中で区切る。 たとえば WHERE tsp > now() - interval '7 days' のようにします。1 回の読み取りは 3000 行が上限でもあるため、生の履歴をそのまま選択するのではなく、クエリの中で集計してください。
• 時系列は新しい順に並べる（ORDER BY <time column> DESC）。こうするとウィジェットは古い順から新しい順に行を受け取り、行数制限がかかる場合でも新しい行が残ります。
• プロットやフィルターに使いたいカラムはすべて選択する。 変換に隠れたタイムスタンプカラムやデバイスカラムはありません：ウィジェットが使えるのは、クエリが実際に返すものだけです。

変換が動かなくなった場合 — 読み取っていたアプリがアンインストールされた、使っていたカラムがなくなった、など — は、変換タブにその理由が表示され、他の変換はそのまま動き続けます。ボード上で変換を読み取る際のアクセスルールは、どのアプリのデータの場合とも同じです。データアクセスが管理するのは、誰が変換を書けるかだけです。

アプリ開発者は代わりに、データスキーマで宣言して変換をアプリに同梱することもできます — 変換テーブルを参照してください。どちらの種類も読み取り方は同じです。

プロジェクトファイルストア

アプリが生成するすべてがテーブルに収まるわけではありません。プロジェクトデータベースと並んで、すべてのプロジェクトにはオブジェクト用のプライベートなファイルストアが用意されます — カメラのフレーム、PDF レポート、ファームウェアイメージ、音声クリップ、エクスポートなど — これらはデータベースとまったく同じ原則のもとで管理されます。

• すべてのアプリに自動的にストレージが付与されます。 アプリがインストールされると、IronFlock はアプリのデータベーステーブルをプロビジョニングするのと同様に、プロジェクトのファイルストア内にそのアプリ専用のプライベートなストレージ領域をプロビジョニングします。複数のアプリが各自のファイルを 1 つのプロジェクトストアにまとめて格納し、各アプリのオブジェクトは互いに明確に分離されて保たれます。
• 同じ所有権保証が適用されます。 ファイルはアプリ開発者ではなく、プロジェクトオーナーに帰属します。プロジェクトオーナーはファイルを閲覧、ダウンロード、上限設定、削除でき、アプリ開発者は自分のアプリがあなたのプロジェクト内で実行中に収集したファイルを見ることはできません。
• ファイルはそのままあなたのデータにリンクします。 格納されたオブジェクトは、アクセス制御された恒久的な URL を持ち、アプリはそれをデータベースのカラムに書き込めます — これにより、ダッシュボードウィジェットは追加の作業なしに画像やドキュメントをレンダリングし、あるユーザーのプロジェクトへのアクセスを取り消すと、そのユーザーがファイルを取得する権限も同時に取り消されます。
• 予算はあなたが管理します。 各アプリのストレージ設定には、どれだけ使用しているかが表示され、ストレージの上限を設定したり、テーブルを空にしたり、アプリのすべてのファイルを削除したりできます。また、プラットフォーム外のツール — DuckDB を使うアナリスト、夜間バックアップなど — のために、単一のアプリのファイルにスコープを限定した読み取り専用の S3 認証情報を発行できます。

ファイルストアはテーブルのすぐ隣で閲覧できます：プロジェクトのデータビューには、すべてのアプリについて Files エントリが表示され、格納された各オブジェクトがそのサイズ、種類、日付とともに一覧されます。ストレージの宣言、名前空間、保持期間、SDK 呼び出しといった開発者側の詳細については、ファイルストレージをご覧ください。

アプリ間のデータ共有

同じプロジェクト内のアプリは、デフォルトでは互いに分離されています：各アプリは自身のテーブルとファイルのみを読み書きします。これは安全な出発点です — エネルギーを計測するためにインストールしたアプリが、あなたがそう決めない限り、別のアプリの点検写真を読み取る理由はありません。

しかし、アプリは多くの場合、連携して動作するべきです — 分析アプリが監視アプリの履歴を読み取ったり、レポートアプリが品質管理アプリから写真を取得したり。IronFlock は、消費側アプリの設定における、あなたが管理する 1 つの同意の判断を通じて、それを可能にします：

• どのプロバイダーをアプリが読み取れるかを、あなたが正確に承認します。そして、アプリがアクセスを求める理由を確認できます。あなたの明示的な承認なしに共有されるものは一切ありません。
• 1 つの許可でハブの両側をカバーします — プロバイダーアプリの共有テーブルおよび共有ファイルです。データベースとファイルの権限を別々に管理する必要はありません。
• アクセスは読み取り専用です。 消費側アプリは別のアプリのデータを閲覧できますが、変更や削除は一切できません。
• いつでも取り消すことができ、アクセスは即座に停止します。

そもそも共有の対象として提供されるものは、アプリ開発者がテーブルごと、ファイル名前空間ごとに決定します — アプリが厳密に内部だけに留めるデータもあり、それらはあなたが付与できるものとしては一切表示されません。共有可能なもののうち、実際に共有するかどうかはあなたが決定します。開発者側の仕組みは、他のアプリからのデータの利用に記載されています。

データ所有権と EU データ法

IronFlock は明確な原則に基づいて構築されています：プロジェクトオーナーがデータ所有者であり、アプリ開発者ではありません。

アプリが生成するすべてのデータ — エッジデバイスからのテレメトリストリーム、イベントログ、派生的な分析結果 — は、プロジェクトオーナーに属するプロジェクトデータベースに保存されます。アプリ開発者はアプリを書きますが、そのアプリがプロジェクト内で実行中に生成したデータは、それをホストするプロジェクトだけの所有物です。

このモデルは、EU データ法（EU Data Act） の要件に直接整合します。この法は、コネクテッド製品および関連サービスの利用者に対し、デバイスが生成するデータへの完全な管理権を付与します。IronFlock では：

• 排他的コントロール。 プロジェクトオーナーはプロジェクトデータベースに対して完全な管理権を持ち、格納されているすべてのデータを読み取り、エクスポート、削除、バックアップできます。
• サイレントなデータ収集は一切なし。 アプリ開発者は、明示的に招待されない限り、プロジェクトのデータにアクセスできません。プロジェクトからアプリ開発者への隠れたデータパイプラインは存在しません。
• ポータビリティ。 すべてのデータが標準的な TimescaleDB インスタンスに格納されているため、SQL で問い合わせ、オープンフォーマットでエクスポートし、自在に移行できます — プロジェクトオーナーがロックインされることはありません。
• 粒度の細かい共有。 プロジェクトオーナーは、アプリ開発者、統合パートナー、その他の関係者をプロジェクトに招待し、特定のデータ領域に対してきめ細かなアクセス権限を付与できます。これにより、サードパーティの技術サポート、リモートメンテナンス、専門のアナリティクスサービスを、オーナーが定義し、いつでも取り消せる条件のもとで活用できます。

つまり、アプリはデータを生成しますが、そのデータを所有、コントロール、共有するのはプロジェクトオーナーです。この所有権モデルは、IronFlock プラットフォームの後付けではなく、第一級の設計目標です。

オプトアウト：IronFlock データパイプラインをバイパスする

IronFlock のメッセージング層とプロジェクトデータベースは推奨される経路です — リアルタイムルーティング、永続ストレージ、ダッシュボード対応のデータ、組み込みの所有権保証を標準で提供します。しかし IronFlock は、アプリにこのパイプラインの使用を強制しません。

IronFlock 管理下のデバイス上で動作するアプリは通常のコンテナワークロードであり、ネットワーク・システムの自由を完全に保持します。プロジェクトオーナーやアプリ開発者が別のデータ処理スタックを好む場合、アプリは次のようなことを行えます：

• 外部システムへプッシュ。 データをサードパーティブローカー（MQTT、Kafka、AMQP）、クラウドインジェストエンドポイント（AWS IoT、Azure IoT Hub、Google Cloud IoT）、またはカスタム REST / gRPC API に直接送信する。
• 代替ストレージを使用。 外部データベース（InfluxDB、MongoDB、S3、顧客所有の TimescaleDB など）に書き込む — IronFlock プロジェクトデータベースの代わりに、または併用して。
• オンプレミスシステムへのブリッジ。 既存の MES、ERP、ヒストリアン、SCADA システムとローカルネットワーク経由で直接連携し、IronFlock クラウドを経由しない。
• ミックス & マッチ。 ダッシュボードや AI 分析のためのサブセットを IronFlock に送りつつ、フル忠実度のデータを別所にストリーミングする。

この柔軟性により、IronFlock はプラットフォームをエンドツーエンドで採用するグリーンフィールド展開にも、データ送信先が譲れない既存のエンタープライズデータアーキテクチャへの統合にも適します。

IoT ダッシュボードと SCADA ボードでデータを活用する

データを視覚的に活用するのは簡単です。IoT ボードや SCADA ボードのウィジェットを構成する際、ほぼすべてのプロパティ（タイトル、値、色など）はプロジェクトデータベースのライブデータに動的にバインドできます。

Board Studio でウィジェットを編集すると、設定フィールドの下にデータバインディングスイッチがあります。テーブルの特定のカラムを選択すると、そのプロパティのためのリアルタイムチャネルが確立されます。新しいテレメトリがデータベースに到着するたびに、バインド済みのプロパティは自動的にリアルタイムで更新され、UI の手動リフレッシュは不要です。

注： ウィジェットのプロパティをデータベースに接続する詳細については、IoT ダッシュボードドキュメントのデータバインディングのセクションをご覧ください。