Contents
JigSpaceの概要と主要機能（実務観点）
JigSpaceはAR/3Dコンテンツを現場で運用するためのプラットフォームの一例です。ベンダーやプランによって機能や対応形式が変わるため、以下は「実務で確認すべき代表的機能」を整理したものです。
3Dモデル登録と最適化
モデル登録から配信までの標準的なワークフローと現場で使える目安を示します。
- CAD（STEP/IGES等）→ポリゴン削減→UV展開→テクスチャ圧縮→配信用フォーマット変換（glTF/GLB 等が一般的）
- LOD（Level of Detail）設定で描画負荷を下げる（例：近接用高解像度、中距離用中解像度、遠距離用低解像度）
- 圧縮についてはDRACO等が一般的に使われるが、対応可否はベンダー確認必須
- 目安ファイルサイズ（配信用目標）例：単純部品 0.5–2MB、一般アセンブリ 5–20MB、大型複雑アセンブリ 30–100MB（配信要件に応じて調整）
AR配置・注釈・操作性
現場での使い勝手が採用率に直結します。配置や注釈の設計ポイントを整理します。
- マーカー不要の平面検出やスケール調整の有無を確認する
- 注釈は手順ごとにシーケンス化し、矢印・テキスト・ハイライトを現場で一貫して見られる設計にする
- 設定可能なプリセット視点やズーム制御、ユーザガイドの操作性はPoCで必ず検証する
共有・コラボレーション・ログ
共有方法とログ取得はPoC評価を数値化する上で重要です。仕様差は要確認です。
- 共有形式（短縮URL、埋め込み、Webビュー等）とアクセス権限（公開/非公開）を確認する
- セッションログ、注釈閲覧数、ユーザ操作履歴の項目（例：timestamp、user_id、action、resource_id）は取得可能かを確認する
- バージョン管理や差分更新のワークフロー（誰がいつコンテンツを更新するか）を事前合意する
JigSpace PoC設計：目的設定・KPI設計・評価設計
PoCは数値仮説を立てて検証することが成功の鍵です。ここではKPIの具体式、測定方法、統計的評価の入門的指針を示します。
KPI設計（式と埋め例）
代表的なKPI式と、実務で使える埋め例を提示します。数値はサンプルであり自社値で置き換えてください。
- 作業時間短縮率（%）= (平均作業時間_導入前 − 平均作業時間_導入後) / 平均作業時間_導入前 × 100
- 埋め例：導入前 60.0分、導入後 48.0分 → 短縮率 = 20%
- First‑time‑fix（%）= 初回解決件数 / 総修理件数 × 100
- 埋め例：導入前 70%、導入後 82%（改善 +12ポイント）
- 品質エラー削減率（%）= (不良件数_導入前 − 不良件数_導入後) / 不良件数_導入前 × 100
- 埋め例：2.0% → 1.5%（相対削減25%）
- CSAT（%）= 良評価数 / 回答数 × 100、SUSは10項目の簡易評価で可視化
各KPIはデータソース（タイムスタディ、SaaSログ、ERP/品質管理DB、アンケート）を明確にしておくこと。
統計設計（サンプル数・検定の考え方）
信頼性ある結論を出すための基本設計を示します。統計的検定はPoCの信頼性に直結します。
- 検定設計例：平均作業時間の差を検出する場合、二標本t検定または対応のあるt検定を利用する
- サンプル数の概算（数値例）：有意水準α=0.05、検出力（1−β）=0.8、効果量（差/標準偏差）を用いる。たとえば基準平均60分、標準偏差15分、目標差12分（20%）なら片側で概算 n ≒ 13/群（条件により異なる）
- 実務的指針：分散が不明またはノイズが大きい場合は各群30サンプル以上を目安にする。可能ならランダム化やペアデザインでバイアスを低減する
- 結果は平均・標準誤差・95%信頼区間・p値・効果量（Cohen's d）を併記する
実務フロー（役割・期間・測定）
PoCの典型的な手順と責任分担、評価期間の考え方を示します。
- 現状把握（タイムスタディ、品質データ取得、関係者ヒアリング）
- スコープ定義（対象工程・対象班の限定）
- ベースライン収集（導入前データを最低1〜2サイクル分）
- コンテンツ作成（モデル、注釈、手順）
- 小規模デプロイ（パイロット班）
- データ収集（自動ログ＋手動計測＋アンケート）
- 分析（KPI比較、信頼区間、統計検定）
- 評価と改善（再設計→再評価）
主要な役割例：スポンサー、PoCリード、現場オーナー、モデラー、ソリューションエンジニア、データ分析者。
JigSpaceの技術要件・モデリング実務
PoC成功には3Dデータ品質、配信性能、既存システム連携が重要です。下は実務で押さえるべき要点と数値例です。
モデリング手順と工数見積り（数値例）
モデルの種別ごとに工数と概算費用を示します。単価は例示で、実査定は発注前に確認してください。
- 社内モデラー単価の例：80,000円/日（例）
- 外注相場（参考）：1人日 50,000〜200,000円（要件で変動）
- モデル例と工数・費用（埋め例）：
- 単純部品：0.5日 → 約40,000円
- ミドルアセンブリ：2日 → 約160,000円
- 複雑アセンブリ：8日 → 約640,000円
複数点の感度試算（例：10モデル×ミドル）で総モデリング費用を推定すること。
配信方式・端末・互換性
配信設計と端末要件はPoC段階で確定しておきます。
- 配信：CDN + ローカルキャッシュが一般的。オフライン要件がある場合はローカルパッケージ配布を設計する
- 端末：iOS/Android/タブレット/Webで機能差が出るため対象機種を限定する（OSバージョン、GPU性能、メモリ）
- フォーマット互換：glTF/GLBが汎用的だがUSDZ等が必要な場合はベンダー対応確認を必須とする
既存システム連携（PLM/ERP等）
連携設計のポイントとAPI要件を押さえます。
- PLM/ERP連携でBOMや部品マスターと3DコンテンツIDを紐付ける設計を行う
- 要件例：OAuth2/OIDCまたはSAMLによる認証、ファイルアップロードAPI、イベント通知（Webhook）、ユーザプロビジョニング（SCIM）
- 運用面：コンテンツの版管理・公開フロー・権限管理を明確化する
PoCのテンプレートと実務サンプル（KPI・ROI）
実務でそのまま使える埋め例を示します。数値はサンプルなので自社データで再計算してください。
KPI表（埋め例）
主要KPIのサンプル実測値と統計情報の記載例です。
| KPI | 測定式 | データソース | 導入前 | 導入後 | 差分 | 備考 |
|---|---|---|---|---|---|---|
| 平均作業時間（分） | - | タイムスタディ / ログ | 60.0 | 48.0 | −12.0（−20%） | p=0.01 |
| First‑time‑fix（%） | - | 修理ログ | 70.0% | 82.0% | +12.0pp | p=0.04 |
| 不良率（%） | - | 品質DB | 2.0% | 1.5% | −0.5pp | p=0.12 |
| CSAT（/5） | - | アンケート | 4.0 | 4.3 | +0.3 | n=120回答 |
（表はサンプル。p値は解析結果の例示で実データで算出すること）
ROI試算（数値例・感度分析）
簡単なROI算出の埋め例を示します。自社の時給・件数で置き換えてください。
前提（サンプル）：
- 年間対象件数：10,000件
- 平均時給（工場）：3,000円/時
- 平均時間短縮：12分/件（0.2時間）
- 品質コスト削減：年間500,000円（例）
- モデリング費用：10モデル × 160,000円 = 1,600,000円
- ライセンス（初年度）：500,000円
- デバイス：10台 × 60,000円 = 600,000円
- 導入支援：300,000円
年間便益計算：
- 作業時間便益 = 0.2時間 × 10,000件 × 3,000円 = 6,000,000円
- その他便益（品質・教育） = 500,000 + 200,000 = 700,000円
- 年間合計便益 = 6,700,000円
初期投資合計 = 1,600,000 + 500,000 + 600,000 + 300,000 = 3,000,000円
回収期間 = 初期投資 / 年間便益 = 3,000,000 / 6,700,000 ≒ 0.45年（約5.4か月）
感度分析例：
- 効果が半分（時間短縮10分→6分）なら年間便益は約3,350,000円、回収期間は約0.9年になる。
KPI収集用CSVカラム（サンプル）
実務での収集用に最低限のカラムを示します（CSV化時の参考）。
| カラム名 | 型 | 説明 |
|---|---|---|
| event_id | string | 一意のイベントID |
| user_id | string | 操作者ID（匿名化可） |
| timestamp | datetime | 操作時刻 |
| operation | string | 操作タイプ（view/annotate/measure等） |
| duration_sec | integer | 作業継続秒数（該当時） |
| model_id | string | 参照モデルID |
| kpi_tag | string | 測定対象タグ（作業時間/点検等） |
セキュリティ・契約・規制対応（JigSpace導入時の注意点）
技術的・契約的なチェックはPoCの段階から入念に行う必要があります。以下は実務で押さえるべき項目です。
技術的セキュリティ要件
通信・保存・認証の基本要件とログ項目の例を示します。
- 通信：TLS 1.2以上を必須、可能ならTLS 1.3を推奨。TLS設定は強い想定（AEAD暗号、最新のプロトコル）で運用する
- 保存：機密データはAES-256等で暗号化し、鍵管理（KMS）を確認する
- 認証・認可：SSO（SAML/OIDC）とRBACによる最小権限運用、MFAを推奨する
- ログ・監査：記録項目に timestamp、user_id（またはハッシュ化ID）、action、resource_id、IP、session_id を含める。生ログの保持期間と匿名化方針を定義する（例：生ログ90日、集計データ3年）
法務・規制チェック（GDPR等）
データ主体の権利と国際的データ移転などを確認します。
- GDPR対応：データ処理契約（DPA）、処理の合法性（同意・契約履行等）、データ主体の権利（訂正・削除・ポータビリティ）対応フローを確認する
- データロケーション：クラウドのデータセンタ所在地と越境（国外移転）ルールを確認する
- 専門領域の規制：医療機器・個人医療情報や金融データ等は別途承認や標準（ISO 13485、医療機器法、金融監督規制）を確認する
契約条項チェック（実務リスト）
最低限契約で押さえるべき項目を列挙します。
- データ所有権とデータ返却（退去時のエクスポート方法）
- DPA（データ処理契約）とサブプロセッサリストの開示
- SLA（稼働率、応答時間）とサポート範囲、エスカレーションフロー
- 機密保持、保証・免責、損害賠償の上限・除外事項
- ブランド使用許諾（ベンダーロゴや名称利用の承諾）と商標注意
用語集と参考資料（実務で読むべき文献）
技術用語や参照すべき公式ドキュメントの一覧を示します。PoC設計で出てくる主要項目を素早く確認できます。
主要用語（短い定義）
以下は短い用語説明です。実務で出てきたらここを参照してください。
- glTF/GLB：3Dアセットの軽量配信用フォーマット。Khronos Groupが規格を公開している。
- USDZ：Appleが推奨するAR向けアーカイブ形式（iOS等でのネイティブ表示が優れる場合あり）。ベンダー対応を確認すること。
- DRACO：Googleが提供する3Dジオメトリ圧縮ライブラリ。対応の有無を確認する。
- PLM/ERP：製造業での部品・BOM管理システムや基幹業務システム。3DコンテンツとIDを紐付ける対象。
- CSAT：顧客満足度（簡易指標）。
- SUS：システム利用性の簡易評価尺度（10項目スコア）。
- LOD：描画負荷軽減のための複数解像度定義。
- DPA：データ処理契約（Data Processing Agreement）。
実務で参照すべき公式リソース（例）
ベンダー仕様や公式標準は常に最新を確認してください。以下は代表的な参照先の例です。
- Khronos Group — glTF 仕様ドキュメント
- Apple Developer — USDZ/ARKit ドキュメント
- Google — Draco 圧縮ライブラリ（GitHub）
- NIST/OWASP — TLS・Webセキュリティに関する推奨設定
- EU Commission — GDPR公式ガイド（法的要件の確認用）
- ベンダーの公式ヘルプセンター／ホワイトペーパー（JigSpace公式ドキュメント等）
まとめと推奨アクション（JigSpace PoC）
JigSpaceを前提にしたPoCで重要なのは「数値仮説の明確化」「実務で測れるKPI設計」「ベンダー仕様・契約の事前確認」です。
- まずは1工程（高頻度・高影響）に絞り、KPIと計測手法を確定すること。
- 統計的評価はサンプル数と検定方法を事前に定義し、ランダム化や対照群で偏りを減らすこと。
- セキュリティ・DPA・データエクスポート条項は契約段階で確実に押さえること。
上記テンプレートを自社数値で埋め、MVPで早期に検証を始めることを推奨します。