権限（管理者 or 作業者 or 発注元 or 協力会社）

機能

• 管理者
  • 物件情報の登録
  • 工事情報の登録
  • 工事スケジュールの作業者への割り振り
  • 作業者の居場所の管理
    • スマートフォンのGPS情報をトラッキングして今どこにいるのかを確認する
  • 報告書の承認
• 作業者
  • 今日行く工事現場の確認
    • 所有者（個人、法人）、発注者（所有者と同じ場合もある）
  • 工事前後の写真アップロード
    • 工事現場の現地確認 Before（最小10枚~最大120枚）マンション名、外観、設備写真、養生しているかどうか
    • カメラを起動して撮る場合はアップロードするだけでなくローカル端末にも保存する
  • 作業中の写真
  • 作業後の写真　
    • 片付けができたかどうか
• 協力会社
  • 自分に割り振られた工事情報のみ閲覧できる。（作業者と同様の機能だが、物件検索などはできない限定的権限）
• 報告書作成者（作業者 or 協力会社）
  • 報告書の書式ダウンロード
    • 報告書アップロード
• 発注者
  • 報告書閲覧
  • 報告書検収または差し戻し
  • 工事完了

サイドバー

• 権限情報（まずは全権所有者を想定）
• 物件情報の登録
• 工事情報の登録
• 工事スケジュール管理
• 作業人員登録
• 工事写真管理
• 報告書管理
• 検収管理

ダッシュボード

今日の作業現場情報

今日の作業人員のGPS情報

コンセプト

惑星居住空間の安全性、快適性の維持ジョブをDistributed Processing Nodeにより処理し、Virtual Computing PlatformにNodeのデータを集めることで、Adaptive Intelligent Asset Platformが実現し、Over The AirのようにNodeのソフトウェアをアップデートすることができる。

Nodeは以下のようなCapacityを搭載して、ObjectのJobをこなしていく。ただし、各ノードはMinimum Viable Payloadでなければならない。（小学校に酸素ボンベをつけていかないのと同様、警察官に落とし物を届けるのに弁護士は必要ないのと同様、ゴールが決まった場合にAからBに移動するコストは最小化され、最小作用経路を通るという最小作用原理が働く）

• Object
  • Corporate Owner
  • Individual Owner
  • Facility Management Agency
  • Land
  • Building
  • Plant
  • Equipment
  • Habitat（居住モジュール）, Rover, Power Unit, Airlock, Water Recycler, Regolith Shield…
• Event
  • Job
    • Unit Specification
    • Capacity Specification
  • Work items
• Capacity
  • Node
    • Skilled Staff
    • License Attribution
  • Attatchment Devices
    • Tools
    • Equipment
    • Gears
    • Machinery
  • Mobility
    • Vehicle
      • Mini Truck
      • Compact-Size Car
      • Mid-Size Car
    • Parking
  • Inventory
    • Facility Units
      • Kitchen
      • Bath
      • Toilet
      • LED Light
      • Air Conditioner
  • Vendors
• Sync to Platform
  • Drawing
  • Diagrams
  • Plan
  • Docs
  • Media

TANAAKKファシリティーズがインフラが集中したグローバル都市経済圏の住宅街において新築以外の住宅管工事を中心とする場合、Distributed Processing Nodeとして、ここの作業員をパッケージ化できる。例えば、駐車場、車両、工具、材料、足場、機械等が１つのノードとして駆動する際、ノードロボットのスペックを定義し、受注というクエリが来た場合に最小のパラメータ積載でプロセッシングできるようにする。
dpn.tbedy.comとしてバーチャル化されたアプリに受注後の全ての動きをインプットするとしたらどうか。

最小Payload

ノードの「最小パラメータ積載（Minimum Viable Payload）」の定義

受注（クエリ）に対し、過不足ないリソースを割り当てるためのパラメータ設定を以下のように構造化

• Logic : 標準的なJobプロセッシングのロジック
• Processor(Skilled Staff / License): どの資格・スキルを持つ作業員が必要か。
• Storage (Inventory / Vehicle): 必要な部材（配管、継手等）と、それを運搬・保管する車両の容量。
• Hardware (Tools / Equipment / Scaffolding): 高圧洗浄機や足場、特殊工具などの物理デバイス。
• Address (Mobility / Parking): 作業地点への到達可能性と、待機場所（駐車場）の確保。
• Port Scanning/Connection/Authorization:工事毎に各種作業に必要となる資格、行政許可、申請などの認証取得

データフローの定義

受注フェーズ (Query Input):

• 工事内容（Job）のGoalのSpecificationの明確化
• Required Specに基づき、必要な「Node Spec（作業員＋車両＋工具＋足場）」を自動生成。
• 現場Addressに到達するために必要最小限のMobilityの選択

移動・準備フェーズ (Deployment):

• 車両のGPS、駐車場の入庫状況、材料の積み込み完了ステータスをNodeデータとして送信。

施工フェーズ (Processing):

• 作業工程（Work items）の完了報告を各Nodeが実行。高圧洗浄機の稼働時間や足場の解体状況などがテレメトリデータとして収集される。

完了・同期フェーズ (Sync to Platform):

• 施工結果（画像・数値）をVirtual Computing Platformに集約。
• これにより、Adaptive Intelligent Asset Platform側で「次のメンテナンス時期」や「ソフトウェア（作業手順書やファームウェア）をブラッシュアップ
• OTAで各ノードに配信。

安全ガバナンス

Safety Envelope（安全境界）

• これを超える判断はNodeがしてはいけない、という境界条件（例：与圧系は人間承認必須）

例

フェーズ	アプリ上の処理 (Logic)	収集されるテレメトリデータ
Query Input	JobのSpecification（例：漏水修理）を入力。	必要な資格、部材、最短経路、最小車両サイズを算出。
Deployment	Node（作業員＋車両）へのデプロイ指示。	積み込み部材（Inventory）の重量、GPS位置、到着予想時刻。
Processing	作業工程（Work items）のチェックリスト実行。	施工前・中・後の画像、トルクレンチの締付値、高圧洗浄圧力。
Sync to Platform	Virtual Computing Platformへの同期。	完了報告書、法定書類の自動生成、資産（Asset）の状態更新。

Trade-offの留意

Sync to Platformの最小化

基本的にはNodeから手動でアップロードさせる情報は最小限にすること。例えば工事のBefore Afterの写真を取って送るなど。基本的な資料の管理はOnedriveで良いので、tbedyで集めるべき最も重要な情報はなんなのかということを考える。

Autonomous化とSafety Requirement

会社に損害を与えるような漏水などの重大事故を起こさないことと、承認数を少なくすることにはトレードオフがある。

現場入力は“5タップ＋2枚写真”上限にする

1. Job開始 2) Unit選択 3) チェックOK 4) After撮影 5) 完了

共通UI/UXプリンシパル: 汎用モダン・ライトクリーン

1. カラーシステム (Light Mode Base)

• Background: Pure White (#FFFFFF) または極めて薄い Gray (#F9FAFB) をベースにする。
• Primary: 信頼感のある Blue (#3B82F6) またはブランドカラー1色に絞る。
• Text: – メイン: #111827 (Almost Black)
  • サブ: #6B7280 (Muted Gray)
• Border: #E5E7EB (薄いグレー) で、シャドウよりもラインで境界を表現する。

2. タイポグラフィ (Universal Sans)

• Font Family: システム標準フォントを優先（Inter, system-ui, sans-serif）。
• Hierarchy: – Title: Bold, 1.25rem以上
  • Body: Normal, 0.875rem ~ 1rem
  • Line Height: 1.5 ~ 1.6 で可読性を確保。

3. アイコン・コンポーネント (Universal Design)

• Library: Lucide React または Heroicons を使用（線が細く、クリーンなもの）。
• Radius: 角丸は 8px (rounded-lg) を基本とし、柔らかすぎず硬すぎない印象にする。
• Clickable: ボタンやリスト項目は、モバイルでの操作性を考慮し最小 44x44px のタップ領域を確保する。

4. コーディング制約

• Framework: React / Next.js / Tailwind CSS を前提とする。
• Consistency: 新しいコンポーネントを作成する際は、既存の shadcn/ui 等のパーツとデザイントークンを統一すること。
• Accessibility: 常に aria-label や適切なセマンティックHTML（nav, main, section）を使用する。