EdgeSentry-Inspect

インフラ点検向けリアルタイム・デジタルツイン監査プラットフォーム。

• リポジトリ: github.com/edgesentry/edgesentry-inspect
• ドキュメント: edgesentry.github.io/edgesentry-inspect

仕組み

EdgeSentry-Inspect は、3D 点群データと BIM 設計データを現場エッジで照合し、施工誤差や構造変化をリアルタイムで検出します。クラウドへの往復なしに、現場で完結します。

3D センサ（LiDAR/ToF）
    │  点群データ
    ▼
trilink-core::project          ← 3D → 2D 深度マップ / 高さマップ
    │  深度マップ（画像）
    ▼
ビジョン AI 推論               ← ローカル GPU で異常検出
    │  バウンディングボックス + クラス
    ▼
trilink-core::unproject        ← 2D 検出 → 3D ワールド座標
    │  ワールド座標系の異常位置
    ▼
Scan-vs-BIM エンジン           ← IFC 設計データと照合
    │  偏差ヒートマップ + レポート
    ▼
現場表示（タブレット / AR）    ← 点検員が現場でズレを確認
    │
    ▼  （生点群ではなくレポートのみアップロード）
クラウド監査ストア             ← 改ざん防止証跡 + デジタルツイン更新

エッジファーストの理由

現場 PC がスキャンから偏差レポートまでの全処理を担います。アップロードされるのはレポート（JSON + PNG ヒートマップ）のみです。これにより、安定したクラウド接続がない環境でも 30 分以内の現場点検が実現できます。

依存ライブラリ

• trilink-core — 点群投影と空間融合（Rust）
• edgesentry-rs — 数学的に検証可能な監査レコード（高保証が必要な用途向けオプション）

ライセンス

MIT OR Apache-2.0

なぜ EdgeSentry-Inspect が必要か

このドキュメントでは、EdgeSentry-Inspect が解決しようとしている課題、現在の点検業務の問題点、そして既存のソリューションとの違いを説明します。

課題

インフラ点検――建設現場であれ船体であれ――は、現在も手作業による計測に大きく依存している数少ない主要エンジニアリング業務の一つです。水準器、巻き尺、クリップボードを持った人間が行う作業です。

建設引き渡し点検では、3 人チームが壁の平坦度・床の水平度・天井高・開口部寸法を確認するのに、1 ユニットあたり 45〜60 分かかります。320 ユニットの建物では 6〜8 週間の点検期間になります。計測は手作業であり空間的な再現性がないため、基準値すれすれの不適合についての争議が頻発します。

船体調査では、1 隻の船舶をカバーするために 30〜40 人の調査員が 3〜5 日間かけて作業します。結果は紙のスケッチに記録され、3 年前の調査と比較できるデジタル記録は存在しません。クラス更新のたびにゼロからやり直しです。

どちらの業務も、自動化・監査可能・空間的に精確な点検記録を求める現代の規制プログラムの要求に応えられません。

現場の課題

速度： 手作業の計測は、建設業の自動化規制適合に必要な 30 分以内の点検ウィンドウを満たせません。完全オフラインのパイプラインなしに、4 時間の自律型ロボット船体調査を実現することも不可能です。

精度： 巻き尺と水準器による計測は ±5〜10 mm の変動を持ちます。許容誤差が 10 mm の構造部材では、その変動が許容誤差全体に相当します。点検員によって結果が変わり、再現性がありません。

コスト： 大人数のチーム、長い期間、争議解決のための繰り返し作業がコストを積み上げます。コストの大部分は設備ではなく労働力であるため、スケールダウンが難しい固定的な運用費用です。

空間情報の欠如： 手作業のレポートには「柱 C4 が許容誤差 12 mm 超」と書かれています。どの面か、どの高さか、どの範囲かは書かれていません。空間情報がなければ、施工者は指摘を確認することも、対応策を計画することも困難です。

履歴比較の不在： 海事アセットでは、現在の点検と前回の調査サイクルのものを自動比較する手段がありません。構造劣化の傾向は、障害が発生するまで見えません。

接続制約： 建設現場や船舶は点検時間帯に限られた、またはゼロのインターネット接続環境にあることが多くあります。クラウド専用プラットフォームは、データをアップロードして遠隔処理するまで判定を返せません。これには数時間かかる場合も、完全に不可能な場合もあります。

既存ソリューションとその限界

既存ソリューションすべてに共通しているのは、スキャン・AI 解析・BIM 比較を 3 つの別々のツールで行い、その間にクラウドアップロードを挟むという設計です。これは現場点検の現実的な制約（時間的プレッシャー・接続制限・現場での即時判定の必要性）と相容れません。

EdgeSentry-Inspect の優位性

エッジファースト・パイプライン： すべての計算――3D 投影・AI 推論・BIM 偏差計算・ヒートマップ・レポート――が現場 PC またはロボット上で実行されます。判定の前にクラウド往復は発生しません。インターネット接続がゼロの環境でも動作します。

統合されたフロー： パイプラインは単一の連続フローです。点群 → AI 推論 → BIM 設計ジオメトリへの偏差計算 → ヒートマップ → JSON レポート。バラバラなツール間のハンドオフステップはありません。

空間的な精度： すべての異常が承認済み BIM 設計ジオメトリに対してミリ単位で位置特定されます。レポートにはワールド座標・偏差量・AI クラス分類が含まれ、写真だけではありません。

オープンかつハードウェア非依存： trilink-core（Rust）・標準 IFC ファイル・画像を受け取る任意の AI 推論エンドポイントというオープンなコンポーネントで構築されています。独自センサー・クラウド・ライセンスは不要です。

海事対応： パイプラインはオフラインバッファリングをネイティブに扱います。接続ゼロのミッション中、偏差ログはロボット上に蓄積され、ドッキング後に同期します。レポートペイロード（1〜6 MB）は、港湾アプローチと沿岸海域で使用される IMO 標準の海事データリンク VDES の帯域幅に対応したサイズです。

オプションの暗号学的監査： 規制提出・法的拘束力のある構造サインオフ・海事クラス認定など、高い保証が必要なコンテキストでは、edgesentry-rs を使用して偏差レポートに Ed25519 署名とハッシュチェーンを付加できます。これにより、EdgeSentry-Inspect インフラとは独立して検証可能な、事後改ざんを暗号学的に証明できる監査記録が生成されます。

EdgeSentry-Inspect — 要件

詳細なステップごとのフロー、ケーススタディ、実装優先順位については scenarios.md を参照してください。

ユースケース

UC-1: 建設現場の施工点検

30 分という制約により、クラウドへの往復は不可能です。点群データから偏差レポートまでの全処理は現場 PC 上で完結しなければなりません。

UC-2: 海事構造物の点検

KPI

非機能要件

シナリオ別精度要件

UC-1: 建設現場の施工点検

UC-2: 海事構造物の点検

EdgeSentry-Inspect — シナリオ分析

ここでは 2 つのデプロイシナリオをステップごとに詳しく解説します。各ステップで何が起きるか、どこが難しいか、具体的なケーススタディ、そして推奨する実装順序を示します。

KPI や高レベルな要件については requirements.md を参照してください。 両シナリオを支えるシステムアーキテクチャについては architecture.md を参照してください。

シナリオ 1: 建設現場の施工点検（CONQUAS スタイル）

コンテキスト

点検員が 3D センサデバイス（ハンドヘルドまたは小型ローバー搭載）を持って建設中の建物に入ります。コンクリート工事・鉄筋配置・壁面・構造部材が、承認された BIM 設計の許容誤差（コンクリートの場合は通常 10 mm）内に収まっているかを確認しなければなりません。1 ユニットの点検全体を、点検員が現場を離れる前に完了させて合否判定を出す必要があります。制約は 30 分です。

クラウドへの往復を待つ余裕はありません。現場 PC がスキャンから判定まですべてを処理しなければなりません。

ステップごとのフロー

ステップ 1 — 設計データの読み込み

点検員が現場 PC 上でこのユニットの IFC ファイルを選択します。edgesentry-inspect::ifc が参照ジオメトリを設計点群として読み込みます。これは 1 セッション 1 回のみ行われ、点検全体を通してキャッシュされます。

ステップ 2 — 現場スキャン

点検員が 3D センサを持って部屋を歩き回ります。センサが連続した点群（PointCloud）を現場 PC にストリーミングします。trilink-core::PoseBuffer が各キャプチャタイムスタンプでのセンサ姿勢を記録します。

ステップ 3 — 深度マップへの投影

各スイープに対して trilink-core::project_to_depth_map が 3D 点群を 2D 深度マップ（DepthMap）に変換します。同時に trilink-core::project_to_height_map がフロアエリアの上面図高さマップ（HeightMap）を生成します。この 2 枚の画像が AI 推論サービスに送られます。

ステップ 4 — AI 推論（ローカル GPU）

推論サービスが現場 PC の GPU 上で動作します。深度マップと高さマップを画像として受け取り、Vec<Detection> を返します: 異常バウンディングボックスとクラスラベル（例: rebar_missing、surface_void、misalignment）と信頼度スコアです。

ステップ 5 — 3D 座標の復元

各検出に対して trilink-core::unproject が、バウンディングボックス中心をキャプチャ時刻の姿勢とそのピクセルの深度を使ってワールド座標系の Point3D に戻します。

ステップ 6 — 偏差計算

edgesentry-inspect::deviation が k-d ツリー最近傍探索を実行します。スキャン点ごとに最も近い設計点を見つけ、距離をミリ単位で記録します。設定しきい値（デフォルト 10 mm）を超えた点にフラグを立てます。

ステップ 7 — ヒートマップとレポートの生成

edgesentry-inspect::heatmap がフラグ付き点を色分けして 2D に投影します（緑 / 黄 / 赤）。edgesentry-inspect::report が JSON 偏差レポートを書き出します: compliant_pct、max_deviation_mm、mean_deviation_mm、異常リストを含みます。

ステップ 8 — 点検員が現場で確認

ヒートマップとレポートが点検員のタブレットに表示されます。どの部材が不合格で、どれだけズレているかが即座にわかります。合否判定が、部屋を出る前に表示されます。スキャン開始から判定まで目標は 30 分以内です。

ステップ 9 — 監査証跡のアップロード

edgesentry-inspect::sync がレポート JSON とヒートマップ PNG をクラウド監査ストア（S3 Object Lock WORM）にアップロードします。生点群はアップロードしません。アップロードはバックグラウンドで行われ、現場判定をブロックしません。

このシナリオの難しい点

このシナリオの詳細な精度要件は requirements.md を参照してください。

シナリオ 2: 海事構造物の点検

コンテキスト

自律型ロボット（車輪走行、クローラー走行、または水中遊泳型）が、船体・ドック構造物・狭所スペースの定期点検を実施します。ロボットはミッション期間中（30 分から数時間）独立して動作します。ミッション中の接続性は貧弱からゼロまで様々で、ロボットはリアルタイムに判断が必要な処理をクラウド接続に頼ることができません。構造変化（新たな腐食、変形、ファスナーの欠落）はミッション中に検出してフラグを立て、ロボットがフラグ立て済みエリアを再点検したり管制センターに即時アラートを出したりできるようにしなければなりません。

このシナリオの設計参照は、IFC ファイル（設計からの偏差）ではなく前回のスキャン（変化検出）である場合があります。両モードをサポートします。

ステップごとのフロー

ステップ 1 — 参照モデルの読み込み

ミッション開始前に、（a）IFC 船体設計ファイルを読み込む、または（b）変化検出の参照として前回の点検のベースライン点群を読み込みます。

ステップ 2 — ロボットがミッション開始

ロボットが事前計画した点検ルートを自律走行します。3D センサが連続して点群をストリーミングします。trilink-core::PoseBuffer が各スイープのタイムスタンプでセンサ姿勢を記録します。

ステップ 3 — 投影・推論（連続ループ、搭載処理）

各スイープに対して trilink-core::project_to_depth_map・AI 推論・trilink-core::unproject がロボットの搭載プロセッサ上でシーケンシャルに実行されます。スイープあたりのレイテンシ目標は 2 秒未満で、異常に近づいた際にロボットがリアルタイムで減速・停止できるようにします。

ステップ 4 — 偏差 / 変化検出

edgesentry-inspect::deviation がスキャン点と参照モデルを比較します。海事しきい値は 5 mm です（船体変形の許容誤差は建設コンクリートより厳しい）。

ステップ 5a — 異常なし: ミッション継続

ロボットが計画ルートを継続します。スキャンデータがローカルの偏差ログに蓄積されます。

ステップ 5b — 異常がしきい値の 2 倍を超過: 即時フラグ発報

edgesentry-inspect::sync がローカルメッセージキューに構造変化フラグを発報します。その時点で無線接続があれば管制センターに直接送信することも可能です。ロボットはオプションで減速・停止・フラグエリアの再スキャンができます。

ステップ 6 — ミッション完了、ロボットがドッキング

ロボットが船舶または施設のドッキングステーションに戻り、船内 LAN に接続します。edgesentry-inspect::sync が完全な偏差レポートとヒートマップ PNG をクラウドデジタルツインストアにアップロードします。デジタルツインが新たな実測ジオメトリで更新されます。

ロボットがドッキングする際の運用状況によって、アウトバウンドリンクは異なります。

VDES は IMO が標準化した次世代海事データ交換システムであり、港湾アプローチと沿岸海域での船陸間レポート転送に最適です。国家港湾当局のデジタルツイン戦略を支える通信レイヤーでもあり、これらのプラットフォームとの統合に推奨される選択肢です。生点群はアップロードしません。1〜6 MB のペイロードは、沿岸圏の下限帯域でも VDES の範囲内に収まります。

ステップ 7 — 管制センターでのレビュー

エンジニアがアップロードされたレポートを確認します。フラグが立てられた構造変化がメンテナンス優先度に基づいて分類されます。更新されたデジタルツインがアセットの現状を表示します。

このシナリオの難しい点

このシナリオの詳細な精度要件は requirements.md を参照してください。

デプロイ比較

EdgeSentry-Inspect のコードベースは両シナリオで同一です。難易度の差はほぼすべて推論ハードウェア層（シナリオ 2 の量子化）と接続層（シナリオ 2 のオフラインバッファリング）にあります。

ケーススタディ

ケーススタディ A — 高層マンション引き渡し点検（シナリオ 1）

事業者: 40 階建て住宅タワーを引き渡す元請け建設会社。

環境: 室内マンションユニット。一般的に 60〜90 m²。全 320 ユニット。エレベーターアクセス。100V 電源利用可能。

課題: 分譲主への引き渡し前に、各ユニットが構造点検に合格しなければならない: 壁の平坦度・床の水平度・天井高・開口部寸法。現在は 3 人チームが水準器と巻き尺で 1 ユニット 45〜60 分かけている。320 ユニットでは点検に 6〜8 週間かかる。基準値すれすれの不適合についての争議が頻発している。

デプロイ:

• 点検員が現場 PC とハンドヘルド 3D センサを持って各ユニットに入る。
• フロアプレートの IFC モデルが現場 PC にプリロード（同フロアの全ユニットをオフセットで 1 ファイルがカバー）。
• 点検員が 1 度の通り抜けでユニットをスキャン（約 15 分）。
• EdgeSentry-Inspect が 10 mm 許容誤差を超えるすべての部材の偏差レポートをスキャン完了後 5 分以内に出力。
• 1 ユニットあたりの合計時間: セットアップ込みで約 20 分。

結果:

• 点検時間を 1 ユニットあたり 45〜60 分から 20 分に短縮（55% 削減）。
• 不適合がミリ単位の精度と写真証拠で記録され、争議はデータで解決できる。
• レポートがプロジェクトの共通データ環境（CDE）に自動アップロードされ IFC モデルにリンク。

このシナリオが簡単な理由: 安定した室内環境・良好なセンサレンジ・接続性の制約なし。現場 PC は標準的な GPU。モデル量子化不要。

ケーススタディ B — 公共インフラ: 地下鉄駅コンコース（シナリオ 1）

事業者: 新しい地下鉄駅を完成させる土木建設会社。

環境: 広いオープンコンコース、床面積約 2,000 m²、天井高 8〜12 m。隣接エリアで工事継続中。点検時間帯に機器と作業員が存在する。

課題: 点検の時間枠が工事継続のために狭い（夜間 2〜4 時間）。その時間内に全構造部材の平坦度・アライメント調査を完了しなければならない。このサイズの空間のトータルステーション調査は 6〜8 時間かかる。各構造部材の偏差レポートへの署名がなければ駅は開業できない。

デプロイ:

• 1 人のオペレーターがローバー搭載の 3D センサでコンコースを走行。
• 8〜12 m の天井高はハンドヘルドより長距離レンジのセンサを必要とする（トレードオフ: 距離が長くなると密度が下がる）。
• EdgeSentry-Inspect が部材タイプごとに動的にしきい値を調整: 柱面 5 mm、天井高の壁パネル 15 mm。
• コンコース全体のスキャンが 90 分で完了。スキャン終了後 10 分で偏差レポートが準備できる。

ケーススタディ A との主な差異:

• 部材タイプごとの動的しきい値（単一のグローバルしきい値ではない）。
• 広大なスキャンエリアは複数スイープのスティッチングが必要（SLAM システムが処理。EdgeSentry-Inspect は統一された点群を受け取る）。
• 作業員と機器によるオクルージョンが多い — 点検不足エリアのフラグ立てにカバレッジレポートが重要。

ケーススタディ C — ドライドック船体点検（シナリオ 2）

事業者: 180 m バルクキャリアのクラス更新調査を実施する船舶修理ヤード。

環境: 船がドライドック中。船体は地上レベルと足場からアクセス可能。一部の閉じたバラストタンクはクローラーロボットが必要。タンク内は携帯電波なし。

課題: クラス更新調査では船体全体の厚みと表面状態の記録が必要。従来の超音波厚み測定と目視点検では 30〜40 人の測定者が 3〜5 日間かかる。ヤードは調査を 1 日に短縮し、前回の調査と比較できるデジタル記録を残したい。

デプロイ（外部船体、ドライドック）:

• 3D センサと搭載 GPU を持つ車輪ロボットが外部船体表面を走行。
• 参照モデル: 前回調査のスキャン（3 年前）。元の IFC ではない（船はその後改造されているため）。
• EdgeSentry-Inspect が変化検出モードで動作: 新スキャン vs 前回スキャン。
• 5 mm 超の偏差（表面損耗または変形と解釈）が無線経由でヤード管制室に即時フラグ発報（ドライドックの外部船体では接続利用可能）。
• ロボットが 8 時間で外部船体を完走。ミッション終了時にレポートアップロード。

デプロイ（閉じたバラストタンク）:

• 小型クローラーロボットがアクセスマンホールからタンクに入る。
• タンク内は接続なし。
• 偏差フラグがローカルバッファに蓄積。
• ロボットがタンクを出ると偏差ログが自動同期。
• 管制室がタンク点検セッション後にすべてのタンクレポートを確認。

結果:

• 調査時間を 3〜5 日から約 28 時間に短縮（船体 + タンク）。
• デジタル偏差マップが前回調査と直接比較可能。3 年間の構造変化が色分けオーバーレイとして即座に可視化。
• 船級協会がデジタルレポートを主要証拠として受理（紙のスケッチが不要に）。

ケーススタディ A との主な差異:

• 1 つのデプロイに 2 つのサブシナリオ: 接続あり外部船体 + 接続なし閉じたタンク。
• クローラーロボット SoC のための量子化が必要。
• IFC 偏差モードではなく変化検出モード。
• ドッキング後同期ロジックが部分レポートを正確に扱わなければならない（ロボットが複数回タンクに出入りする必要がある場合）。

推奨実装順序

シナリオ 1（建設、接続あり）を先に実装する。

根拠

1. 30 分制約がエッジパイプライン全体を検証する。 投影 → 推論 → 逆投影 → 偏差 → レポートの全サイクルが現場 PC で 30 分以内に完了できるなら、シナリオ 2（現場での厳しい時間制約がない）は同じコードで直ちに達成可能。

2. 量子化の依存なし。 シナリオ 1 は標準的な現場 PC GPU で動作する。ロボットハードウェアチームやモデル量子化ツールチェーンへの依存なし。ハードウェアパートナーなしでパイプラインを構築・テスト・実証できる。

3. IFC 偏差モードが変化検出モードの基盤となる。 シナリオ 2 の変化検出モード（新スキャン vs 前回スキャン）は偏差エンジン全体を再利用する。「設計参照点群」が前回のスキャン点群に置き換わるだけ。IFC 偏差を先に実装するとシナリオ 2 で構造的なコード変更が不要になる。

4. シナリオ 1 の稼働デプロイがシナリオ 2 の投資を正当化する証拠となる。 船舶修理ヤードや港湾当局に自律型ロボットの試験導入を説得するには、AI + 偏差パイプラインが信頼できる結果を生む証拠が必要。建設現場の引き渡し点検（運用の複雑さが低く、アクセスが容易で、環境が制御されている）がその証拠を生む最適な最初のデプロイ。

5. シナリオ 2 は EdgeSentry-Inspect の管理外の依存を追加する。 ロボット SoC の量子化・GPS 拒否環境での SLAM 精度・ミッションプランニングはすべてロボットプラットフォームパートナーが提供する。これらの統合は、シナリオ 1 の稼働デプロイがパイプラインの精度を実証した後のほうが交渉・実施が容易。

推奨フェーズ

フェーズ 3 は EdgeSentry-Inspect のコード変更なし。投資はロボットプラットフォーム統合層（量子化・フリート管理・ドッキング後同期リトライロジック）に集中する。これはフェーズ 2 の結果によって正当化される投資。

現場での計測精度を決定する要因の詳細は architecture.md を参照してください。

EdgeSentry-Inspect — アーキテクチャ

エッジ・クラウド分担

┌──────────────────────────────────────────────────────────┐
│  現場 PC（エッジ）                                       │
│                                                          │
│  3D センサ（LiDAR / ToF）                               │
│      │  点群データ（PointCloud）                        │
│      ▼                                                   │
│  trilink-core::project_to_depth_map                      │
│  trilink-core::project_to_height_map                     │
│      │  DepthMap  HeightMap                              │
│      ▼                                                   │
│  AI 推論（組み込みモデルまたは HTTP エンドポイント）    │
│      │  Vec<Detection>（BBox2D + クラス + 信頼度）      │
│      ▼                                                   │
│  trilink-core::unproject                                 │
│      │  ワールド座標系の Point3D（検出ごと）            │
│      ▼                                                   │
│  edgesentry-inspect::ifc      — IFC ジオメトリ          │
│  edgesentry-inspect::deviation — 偏差計算（mm）          │
│  edgesentry-inspect::heatmap   — ヒートマップ PNG        │
│  edgesentry-inspect::report    — JSON レポート           │
│      │                                                   │
│      ├── タブレット / AR ヘッドセットに即時表示         │
└──────┬───────────────────────────────────────────────────┘
       │  レポート JSON + ヒートマップ PNG（生点群ではない）
       ▼
┌──────────────────────────────────────────────────────────┐
│  クラウド（監査ストア / デジタルツイン）                │
│                                                          │
│  edgesentry-inspect::sync                                │
│      │  S3 互換アップロード（Object Lock WORM）         │
│      │  構造変化フラグ → メッセージキュー               │
│      ▼                                                   │
│  監査レポートストア — 改ざん防止の証跡                  │
│  デジタルツイン更新 — 実測 IFC デルタ                   │
│  中央ダッシュボード — フリート全体の偏差傾向            │
└──────────────────────────────────────────────────────────┘

現場 PC で処理するもの

クラウドに送るもの

コンポーネント設計

edgesentry-inspect::ifc

• 入力: IFC ファイルパス（.ifc）
• 出力: Vec<Point3D> — 壁・スラブ・柱のジオメトリからサンプリングした設計参照点群
• 実装: pyo3 経由の Python FFI（ifcopenshell）またはネイティブ Rust IFC リーダー
• 参照点群は点検セッション 1 回につき 1 度だけ読み込み、メモリにキャッシュ

edgesentry-inspect::deviation

• 入力: スキャン Vec<Point3D>（trilink-core::unproject 経由）+ 設計 Vec<Point3D>（ifc 経由）
• 出力: スキャン点ごとの偏差値 f32（メートル単位）
• アルゴリズム: k-d ツリー最近傍探索（kiddo クレート）。O(n log m)
• しきい値: 設定可能（建設デフォルト 10 mm、海事船体 5 mm）

edgesentry-inspect::heatmap

• 入力: スキャン点群 + 点ごとの偏差値
• 出力: PNG 画像 — 偏差を色でマッピング（緑 ≤ しきい値、黄 2 倍、赤 4 倍以上）
• trilink-core::project_to_depth_map を再利用して各色点を 2D に配置

edgesentry-inspect::report

JSON スキーマ:

{
  "compliant_pct": 94.2,
  "max_deviation_mm": 23.1,
  "mean_deviation_mm": 3.8,
  "point_count": 142850,
  "threshold_mm": 10.0
}

AI 検出位置はレポートと並んで points.json に書き込まれます:

{
  "scan_points": [
    { "x": 12.3, "y": 4.1, "z": 2.05, "deviation_mm": 23.1 }
  ],
  "detections": [
    { "x": 12.3, "y": 4.1, "z": 2.05 }
  ]
}

edgesentry-inspect::sync

• 偏差レポート JSON とヒートマップ PNG を S3 互換監査ストアにアップロード（Object Lock WORM）
• 設定しきい値の 2 倍を超える異常が検出された場合、構造変化フラグをメッセージキュー（SQS または MQTT）に発報
• edgesentry-rs の S3 互換インタフェースを再利用

AI 推論モード

EdgeSentry-Inspect は config.toml の inference.mode で選択できる 2 つの推論バックエンドをサポートします。どちらも同じ Vec<Detection> を出力し、以降のパイプラインで使用されます。

組み込みモデル（inference.mode = "builtin"）

EdgeSentry-Inspect にバンドルされた軽量の欠陥検出モデルです。ONNX Runtime を使ってプロセス内で実行されるため、外部サーバーもネットワークアクセスも不要です。

• 入力: trilink-core が生成する DepthMap + HeightMap 画像
• 出力: Vec<Detection> — バウンディングボックス・クラスラベル・信頼度スコア
• 初期クラス: surface_void（表面空洞）・misalignment（位置ずれ）・rebar_exposure（鉄筋露出）
• ハードウェア: 標準的な現場 PC CPU で動作。基本的な用途では専用 GPU 不要

外部サーバーが利用できないオフライン専用デプロイや、すぐに使い始めたい場合に builtin を使用してください。

外部 HTTP エンドポイント（inference.mode = "http"）

推論クライアントが inference.base_url に深度マップと高さマップを POST し、検出リストを受け取ります。エンドポイントは以下のいずれかです。

• 現場 PC またはロボット上でローカルに動作するベンダーのモデルサーバー（同一ホスト。インターネット不要）
• 専門的なクラウド推論 API（シナリオ 1 / 接続ありのデプロイのみ）

このモードがベンダー連携の統合ポイントです。ベンダーは自社モデルでサーバー側を実装し、EdgeSentry-Inspect は固定スキーマでそれを呼び出します。オペレーターは設定で inference.base_url を指定するだけでコード変更は不要です。

インタフェース仕様:

POST /detect
Content-Type: multipart/form-data
  depth_map: <PNG バイト列>
  height_map: <PNG バイト列>

200 OK
[{"x":120,"y":45,"w":30,"h":20,"class":"surface_void","confidence":0.87}, ...]

オプション：数学的に検証可能な監査レコード

点検レポートに対して第三者が独立して改ざんを検証できる必要がある場合（規制提出書類、法的拘束力のある構造認証など）、偏差レポートを edgesentry-rs を使って署名・ハッシュチェーンに組み込むことができます。

このレイヤーはオプションです。標準的な建設点検では edgesentry-inspect::sync の S3 Object Lock WORM ストアで十分です。海事船体認証や法的効力を持つ構造サインオフなど高保証が求められる用途では、edgesentry-rs の AuditRecord でレポートをラップすることで、EdgeSentry-Inspect インフラとは独立して検証可能な暗号監査証跡が得られます。

計測精度の要因

UC-1（建設）の目標精度は 10 mm、UC-2（海事）は 5 mm です。現場での計測精度を決定する主要因と対策を以下に示します。

技術サマリー

PoC 用オープンデータセット

Inspect — ロードマップ

リリーストラック

本ドキュメントのすべてのマイルストーンはオープンソースとして公開します。商用マイルストーンは商用コンプライアンス層で追跡します。

エコシステム戦略

DuckDB モデルに倣い、アルゴリズム・ツール・仕様をできる限りオープンにすることで、ロックインではなくエコシステムへの採用を通じてデファクトスタンダードを目指す。

OSS コアを最大開放する理由

偏差計算エンジン・投影アルゴリズム・CLI を完全オープンにすることで、研究者・現場エンジニア・規制当局・パートナー企業が独立して検証・統合・拡張できる。アルゴリズムの透明性そのものが信頼の根拠となり、「商用ツールに依存しない建設検査の公共インフラ」としての地位を確立する。

規制当局との共創

BCA・CSA・国土交通省といった規制当局は競争相手ではなく、建設品質標準を共に育てるパートナーである。CLS / JC-STAR / CONQUAS への準拠を先行実装することは、これらの機関が定める標準を真剣に受け止めているというコミットメントの表明であり、OSS コアの品質を独立した第三者に検証してもらう機会でもある。この信頼関係が国際的なエコシステム採用を加速する。

基盤（trilink-core リポジトリ）

以下は Inspect の全マイルストーンの前提条件です。 trilink-core リポジトリで追跡・実装されます。

基盤の全イシューがマージ済みです。M2 の実装も完了しています。M3 の実装を開始できます。

M2 — IFC ローダーと偏差エンジン [OSS] ✅ 実装済み

目標: スキャン点群と IFC 設計ファイルから、点ごとのミリ単位偏差を計算できること。

成果物:

• Cargo.toml — ワークスペースルート。メンバー: crates/edgesentry-inspect
• src/ifc.rs — IFC ジオメトリを Vec<Point3D> として読み込む（設計参照点群）
• src/deviation.rs — k-d ツリー最近傍偏差計算。設定可能なしきい値
• src/report.rs — JSON レポートシリアライゼーション（スキーマは architecture.md を参照）
• 統合テスト: サンプル IFC フィクスチャを読み込み → 既知のスキャン点群に対して偏差を計算 → compliant_pct・max_deviation_mm・mean_deviation_mm を検証

M3 — ヒートマップ生成 [OSS] ✅ 実装済み

目標: 点ごとの偏差を色にマッピングし、深度マップ投影を使って 2D に位置付けた PNG ヒートマップを生成できること。

成果物:

• src/heatmap.rs — 偏差 → RGB 色（緑 ≤ しきい値、黄 2 倍、赤 4 倍以上）→ image クレートで PNG 出力
• trilink-core::project_to_depth_map を再利用して各色点を 2D に配置
• 統合テスト: 既知の偏差値 → 出力 PNG の期待ピクセル位置・色を検証

M4 — 現場 PC パイプライン（CLI） [OSS] ✅ 実装済み

目標: 点群から偏差レポートまでの現場エンドツーエンドパイプラインを単一の CLI コマンドで実行できること。

成果物:

• src/main.rs — CLI: edgesentry-inspect scan --config config.toml
• 接続: 点群インジェスト（trilink-core::FrameSource）→ project_to_depth_map → AI 推論クライアント → unproject → 偏差計算 → ヒートマップ → レポート
• 設定: IFC ファイルパス、inference.mode（builtin | http）、推論エンドポイント URL（http 時）、偏差しきい値、出力ディレクトリ
• エンドツーエンドテスト: MockSource + モック推論サーバーを使用。レポートが生成され全フィールドが正しく、ヒートマップ PNG が書き出されることを検証

M5 — クラウド同期 [OSS]

目標: 偏差レポートとヒートマップを S3 互換ストアにアップロードし、構造変化フラグを発報できること。

成果物:

• src/sync.rs — S3 互換アップロード（標準 PUT）。しきい値の 2 倍を超える異常検出時に SQS または MQTT へ構造変化フラグを発報
• 統合テスト: モック S3 + モック SQS → しきい値超過の異常に対してレポートがアップロードされフラグが発報されること、しきい値未満の場合はフラグが発報されないことを検証

M6 — 組み込み推論モデル [OSS]

目標: 軽量 ONNX 欠陥検出モデルを Inspect に同梱し、外部サーバーなしで inference.mode = "builtin" がすぐに使えること。

成果物:

• src/inference/mod.rs — InferenceBackend トレイト。inference.mode に基づいて組み込みまたは HTTP に振り分け
• src/inference/builtin.rs — ONNX Runtime ランナー（ort クレート）。バンドル済みモデルの重みを読み込む
• src/inference/http.rs — M4 の HTTP クライアントを同モジュールに抽出（組み込みとの対称性）
• models/detect.onnx — surface_void・misalignment・rebar_exposure をカバーする初期モデル
• 統合テスト: サンプル深度マップで組み込みモデルを実行 → 検出結果が空でなく、クラスラベルが正しいことを検証

既知の制約

現在の設計に内在する制約事項です。制約の詳細は trilink-core/docs/limitations.md に記載されています。

RGB-D 融合（M6 拡張）

組み込み推論モデル（M6）は、深度マップに加えてオプションの RGB チャンネルを受け付けられるよう拡張予定です。FusionPacket はすでに image_jpeg を保持しています。主な変更は推論モジュールとモデルの再トレーニングです。

このアイテムは M6 の一部として追跡されます。InferenceBackend トレイトのシグネチャは変更しません。RGB テンソルは追加のオプションチャンネルとして渡されます。

デモパイプライン

目標: オープンデータセットを使って Inspect CLI のエンドツーエンドデモを自己完結した形で実行できること。本番ハードウェアや本番データは不要。

前提条件: M2、M3、M4（CLI がビルド済みで PATH が通っていること）。

手順:

1. 公開 IFC ファイル（buildingSMART BIMNet ギャラリー）と屋内 LiDAR スキャン（S3DIS データセット）をダウンロードする。
2. IfcOpenShell で IFC 表面をサンプリングし、参照点群を生成する。
3. Open3D で 15 mm の意図的な変形を加え、既知の欠陥を持つシミュレーションスキャンを作成する。
4. edgesentry-inspect scan --config config.toml を実行する。CLI は IFC を読み込み、偏差を計算し、深度マップに投影して HTTP 推論サーバーを呼び出し、検出結果を逆投影してヒートマップを生成し、JSON レポートを出力する。
5. report.json（compliant_pct・max_deviation_mm・mean_deviation_mm）と PNG ヒートマップを確認し、シミュレーションした欠陥が検出・定量化されていることを検証する。

詳細な手順は デモパイプライン を参照してください。

監査層 — ISO 19650 対応

ISO 19650 情報コンテナスキーマの実装（BIM ステータス遷移・準拠ペイロード・第三者 BIM ツールとの相互運用性）は、edgesentry-rs クレートの責務です。

実装計画は edgesentry-audit ロードマップ — Milestone 2.7 で追跡されます。

依存グラフ

trilink-core #30, #31, #32, #33, #34（基盤 — 完了）
    └── M2（IFC ローダー + 偏差エンジン）          [OSS]
         └── M3（ヒートマップ生成）                 [OSS]
              └── M4（現場 PC パイプライン CLI）     [OSS]
                   ├── M5（クラウド同期）            [OSS]
                   ├── M6（組み込み推論モデル）      [OSS]
                   └── デモパイプライン（オープンデータセット + CLI）

商用マイルストーン（M4.5、M7、M8）および 2D/1D フェーズ 2 は商用コンプライアンス層で追跡します。

開発優先順位は 3D デモ → 2D（MPA/JTC 向け YOLO11/SAM 2）→ 1D（NEA/PUB 向け PatchTST/iTransformer）の順です。

デモパイプライン

このページでは、オープンデータセットと Inspect CLI を使って、自己完結した概念実証（PoC）デモを構築する手順を説明します。本番データが用意できる前の技術評価・現場デモでの利用を想定しています。

オープンデータセット

IFC のダウンロード URL は使用前に必ず確認してください。buildingSMART ギャラリーが一次ソースです。サードパーティのミラーは改変済みのファイルを配信している場合があります。

パイプライン手順

ステップ 1 — IFC から設計点群を生成

IfcOpenShell を使って IFC の表面ジオメトリをサンプリングし、参照点群（「正解」となる設計データ）を生成します。各 IfcProduct 要素を三角形分割し、頂点座標を (N, 3) の配列として収集します。

ステップ 2 — 損傷スキャンのシミュレーション

Open3D を使って設計点群のコピーに意図的な変形を加え、既知の欠陥を持つ「実測データ」を作成します。デモの例では、特定領域を 15 mm 押し込んで表面の凹みを再現し、結果を PLY ファイルとして保存します。

ステップ 3 — 偏差計算（M2）

eds inspect scan CLI コマンドを実行し、IFC 設計ファイルとシミュレーションスキャンの PLY ファイルを指定します。CLI は src/ifc.rs で設計参照点群を読み込み、src/deviation.rs で点ごとの最近傍偏差を計算して、compliant_pct・max_deviation_mm・mean_deviation_mm を含む JSON レポートを出力します。

このステップでは src/ifc.rs と src/deviation.rs（M2）を使います。

ステップ 4 — 3D → 2D 投影（trilink-core）

trilink-core::project_to_depth_map がスキャン点群を深度マップ画像に変換し、AI 推論の入力とします。config.toml に設定されたカメラ内部パラメータを使って CLI が自動的に処理するため、手動操作は不要です。

このステップでは trilink-core::project_to_depth_map（基盤 #31）を使います。

ステップ 5 — AI による欠陥検出

HTTP 推論パス（inference.mode = "http"）経由で深度マップに対して検出モデルを実行します。デモでは YOLOv8 を外部推論サーバーとして使用できます。CLI は深度マップ画像を設定済みの HTTP エンドポイントに送信し、バウンディングボックスの検出結果を受け取ります（M4）。

ステップ 6 — 2D → 3D 逆投影

検出された 2D バウンディングボックスは trilink-core::unproject によってワールド座標に逆投影され、3D モデル上に重ねて表示されるとともに偏差レポートに含まれます（M4）。

デモにおける偏差エンジンの位置づけ

偏差エンジン（M2）はデモの定量的な核心です。「異常があるか？」だけでなく、「IFC 設計に対して実際の構造物が何ミリずれているか？」 に答えます。汎用的な欠陥検出器との差別化ポイントであるため、ステップ 3 を必ずデモで明示してください。

テクニカルスタックまとめ

CLI リファレンス

eds inspect は M4 フィールド PC パイプラインを実行します。IFC 参照 + PLY スキャン → 偏差計算 → オプションの AI 推論 → ヒートマップ + レポート。

インストール

エンドユーザー向け — ビルド済みバイナリ

最新リリースを GitHub Releases ページ からダウンロードしてください。

展開して eds バイナリを PATH に追加してください：

# Linux / macOS
tar -xzf eds-{version}-{target}.tar.gz
sudo mv eds /usr/local/bin/
eds --help

# Windows（PowerShell）
Expand-Archive eds-{version}-x86_64-pc-windows-msvc.zip
# eds.exe を PATH が通ったディレクトリに移動してください
eds --help

開発者向け — ソースからインストール

Rust（stable ツールチェーン）が必要です。

cargo install --git https://github.com/edgesentry/edgesentry-rs --locked --bin eds

eds inspect scan

TOML 設定ファイルからフルスキャンパイプラインを実行：

eds inspect scan --config config.toml

設定ファイルの形式

ifc_path  = "path/to/design.ifc"
scan_path = "path/to/scan.ply"

[camera]
fx = 525.0
fy = 525.0
cx = 319.5
cy = 239.5
width  = 640
height = 480

[inference]
mode = "off"          # "off" または "http"
# endpoint = "http://localhost:8000/infer"   # mode = "http" の場合に必須

[output]
dir = "out"

注釈付きのサンプルは config.example.toml を参照してください。

出力ファイル

推論モード

mode = "off" — 偏差計算とヒートマップのみ。AI 呼び出しなし。

mode = "http" — 深度マップが PNG として endpoint に POST されます。サーバーはバウンディングボックスの JSON 配列を返す必要があります：

[{"x": 10, "y": 20, "w": 50, "h": 60}, ...]

検出された領域は trilink-core::unproject によってワールド座標に逆投影され、report.json に含まれます。

オプションフィーチャーでのビルド

eds inspect scan コマンドには追加のフィーチャーフラグは不要です。トランスポートフィーチャー（transport-http、transport-tls など）は eds audit serve* コマンドにのみ適用されます。

# デフォルトビルド — inspect scan はそのまま動作します
cargo build -p eds

# 監査 HTTP トランスポートも含める場合
cargo build -p eds --features transport-http

EdgeSentry Inspect への貢献

整合性チェック

コード・テスト・スクリプト・ドキュメントのいずれかを変更するたびに、3 つの層が同期していることを確認してください。

1. コード → ドキュメント： モジュール・関数・CLI コマンド・動作を追加・削除・名前変更した場合は、それを参照するすべてのドキュメントを更新してください（architecture.md・cli.md・demo.md・roadmap.md）。
2. ドキュメント → コード： ドキュメントが機能やコマンドを説明している場合は、それが存在し、説明通りに動作することを確認してください。古くなったサンプルや誤った Cargo フィーチャー名は CI 失敗の原因になります。
3. スクリプト → コード： テストファイルや Cargo フィーチャーの名前を変更した場合は、それを参照するすべてのスクリプトとワークフローを更新してください（例：.github/workflows/ci.yml）。

PR 作成前の簡単な grep チェック：

# 変更したシンボルに言及しているドキュメントを検索
grep -r "<old-name>" docs/ scripts/ .github/

クレート構成

Issue ラベル

すべての Issue には 1 つの タイプ ラベル、1 つの 優先度 ラベル、1 つ以上の カテゴリ ラベルを付けてください。

タイプラベル

優先度ラベル

判断に迷う場合は「これはユーザーが eds inspect scan をエンドツーエンドで実行することをブロックするか？」と問いかけてください。Yes なら P0。体験を大幅に改善するなら P1。後のマイルストーンで提供できるなら P2。

カテゴリラベル

プルリクエストの規約

常にブランチを作成したユーザーをアサインしてください：

gh pr create --assignee "@me" --title "..." --body "..."

必須：コード変更後は必ずテストを実行する

毎回 のコード変更後に実行：

cargo test --workspace

すべてのテストが通過するまで変更が完了したとみなさないでください。

テストの実行

前提条件（macOS）

brew install rustup-init
rustup-init -y
source "$HOME/.cargo/env"
rustup default stable

ユニットテスト

# 全クレート
cargo test --workspace

# Inspect クレートのみ
cargo test -p edgesentry-inspect

統合テスト（CLI エンドツーエンド）

cargo test -p eds --features transport-http,transport-tls --test cli_integration

静的解析とライセンスチェック

PR を開く前に実行：

# リント
cargo clippy --workspace --all-targets --all-features -- -D warnings

# セキュリティアドバイザリ
cargo audit

# OSS ライセンスポリシー
cargo deny check licenses

main とのコンフリクトを避ける

作業開始前に：

git fetch origin
git checkout main && git pull origin main
git checkout -b <your-branch>

ブランチを最新の状態に保つ — PR を開く前に main にリベース：

git fetch origin
git rebase origin/main

最もコンフリクトしやすいファイル — 編集前に調整してください：