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 を参照してください。