TripDataHub

1概要

何をするアプリか / なぜ必要か / 誰のためか / 主な機能

どんなアプリか

TripDataHub は、貨物・旅客のパイロットが自分の乗務スケジュールをタイムゾーン込みで正しく把握するための iOS アプリです（旧称 BidProSchedule、バンドル ID は今も com.sfune.BidProSchedule）。使い方はシンプルで、パイロットは社内スケジューリングシステム CrewAccess からスケジュール PDF を書き出し、iOS の共有シートから本アプリに渡すだけ。あとはアプリが PDF を解析・保存し、乗務の時系列ビュー（Timeline）と、iPad では 8 週間の Bid Period カレンダーとして表示します。

解決する課題

CrewAccess が出すスケジュールは PDF で、UTC とローカル時刻が混在した生の形式です。そのため「これからの 2 週間が実際どうなるのか」を時系列で一覧する手段がなく、次のフライトまでのカウントダウンもなければ、同僚の予定を見る方法もありません。TripDataHub はこの PDF を、次の 4 つに変換します。

• 一目で読める、タイムゾーン正確な乗務の時系列ビュー（Timeline）。
• Bid Period 全体を俯瞰できる カレンダー（iPad）。割り当てられたトリップに加え、手動管理のリザーブ・コールアウト・個人予定も並べて表示。
• 「空港まであと何時間か」を頭で計算せずに済む 次のフライトまでのカウントダウン（ウィジェット＋ライブアクティビティ）。
• 信頼できる同僚との 読み取り専用のスケジュール共有（相互承認制）。

対象ユーザー

• CrewAccess を使う貨物・旅客のパイロット（App Store 上では「brown-tail cargo pilots」と位置づけ）。
• 複数の母基地（現在 ANC / SDF・SDFZ / ONT / MIA）をまたぐ、リザーブ中心・タイムゾーン中心の運用をこなす人。
• 同僚に自分の予定を読み取り専用で共有したいパイロット。

主な機能

• CrewAccess PDF の取り込み — 共有拡張で PDF を受け取り、PDFKit でテキスト抽出 → トリップ／レグ／勤務の構造化 JSON に変換。
• Timeline タブ — トリップ・フライト・デッドヘッド・レイオーバー（ホテル情報つき）・手動の運用イベントを、空港ローカル時刻で時系列に表示。
• Calendar タブ（iPad） — 8 週間の Bid Period グリッド。トリップ、運用イベント（RSV / LCO / HOT / RCID / CQ）、個人予定（通勤・医療・予約・その他）を「運用 > Bid > 個人」の優先順でレイヤー表示。
• 次のフライトまでのカウントダウン — ホーム画面ウィジェット（T-12h〜T-6h）とライブアクティビティ／ダイナミックアイランド（T-6h〜T+6h）。STD を過ぎても未出発なら自動で「Delayed」表示に。
• フレンド共有 — GEMS ID の相互承認による、CloudKit Public Database 経由の読み取り専用共有。
• TripBoard「OpenTime」閲覧 — 任意・読み取り専用。ユーザー自身の BidPro / TripBoard 認証情報が必要で、App Review デモモードでは無効。
• LogTen 互換エクスポート。
• CloudKit によるデバイス間同期 — 取り込んだスケジュールを同期（競合は local-wins、削除はトゥームストーン方式）。

現在のステータス

• Version 1.2.1（build 68） — 2026-06-13 時点で最新（main の当日コミット）。v2.x タグの扱いについては「現状」を参照。
• iOS 17.0 以上。iPhone（縦向き中心）と iPad（横向き最適化）で UI を分けて提供。
• v1 のコア機能（取り込み・Timeline・Calendar・カウントダウン・フレンド共有・手動イベント・LogTen エクスポート・App Review デモモード）はすべて実装・出荷済み。
• 直近の開発はフレンド共有／プロフィールの CloudKit 同期の安定化が中心で、その仕上げが v1.2.0 / v1.2.1 リリース。

2アーキテクチャ

ビルド構成 / データの流れ / 保存先 / CloudKit / 守るべき不変条件

ビルドターゲット

すべて project.yml から XcodeGen で生成しています。

• TripDataHub — 本体アプリ（SwiftUI / iOS 17.0+ / Swift 5.9 / Team 54WZM2U9MK / バンドル com.sfune.BidProSchedule）。
• TripDataCountdownWidgetExtension — カウントダウン用のホーム画面ウィジェット＋ライブアクティビティ。
• TripDataShareActionExtension — CrewAccess PDF を受け取る共有シート拡張。
• TripDataHubTests / TripDataHubUITests — ユニットテストと UI テスト。

ソース構成（TripDataHub/）

Models/ — データ型

TripModels.swift（PayPeriodSchedule / TripLeg / OpenTimeTrip / FriendConnection）を中心に、CalendarModels、FlightCountdownSupport、FriendScheduleMatching、ProfileModels / ProfileSnapshot、DeviceScheduleModels、RosterParsingModels などが並びます。

Services/ — 業務ロジック・解析・同期

• AppViewModel.swift — 状態管理とオーケストレーションの中核（かなり巨大）。
• CrewAccessPDFImportService.swift + PDFTripParser.swift — PDFKit によるテキスト抽出と、CrewAccess スケジュールの行単位パース。
• CloudKit 同期系 — CrewAccessImportCloudKitService / DeviceScheduleCloudKitService / FriendScheduleCloudKitService / GEMSVerificationCloudKitService / ProfileCloudKitService。
• IATATimeZoneResolver（空港→タイムゾーン）、BidPeriodService（Bid / Pay Period の境界計算）、DomicileSupport（母基地の扱い）。
• TripBoardSyncService / TripBoardAuthService — OpenTime 取得（任意・ユーザー認証）。
• FlightCountdownCoordinator / NextReportNotificationService — カウントダウンと通知。
• TripScheduleSnapshotEncoder（Web ビューア／共有向けシリアライズ）、AppGroupImportHandoff（共有拡張からの受け渡し）、AppReviewDemo（審査用デモモード）。

ViewModels/ ・ Views/ ・ その他

• ViewModels/ — MVVM ルートの AppViewModel、BrowserViewModel、プレビュー用データ。
• Views/ — Timeline / Calendar（iPad 専用は Views/iPad/）/ OpenTime / Settings / Profile / Friends などの SwiftUI 画面と、共有描画ヘルパー（TimelineRowViews / CalendarSupport / MaterialIconView）。
• TripDataHubApp.swift — エントリポイント。ディープリンク tripdatahub://import?manifest=<id> を処理。

データの流れ ① 取り込みパイプライン

1. ユーザーが PDF を共有 → 共有拡張 が public.pdf を受け取り、ファイルとマニフェスト JSON を App Group コンテナ にコピーし、本体アプリへディープリンク。
2. 本体の AppGroupImportHandoff がマニフェストと PDF を読み込む。
3. CrewAccessPDFImportService（PDFKit）でテキスト抽出 → PDFTripParser が行単位でトリップ・勤務・レグ・ホテル・クルーの JSON に変換。
4. CrewAccessTripSummaryStore が JSON を Documents/CrewAccessImports/{date}_{tripId}.json に保存。このローカル JSON が正本（INV-006）。
5. 起動時に reconcileCrewAccessSchedulesWithImportFiles() がファイル群からメモリ上の状態を再構築。
6. CloudKit 同期（後述）が、生の取り込みファイルと解析済みスナップショットの両方をミラーし、複数端末で利用可能に。

データの流れ ② Timeline / Calendar の描画

• PayPeriodSchedule が 1 ペイ期間分のトリップを保持し、TripLeg が個々のフライト区間（出所は CrewAccess または OpenTime）。
• Timeline — レグを pairing（トリップ ID）でまとめ、空港ローカル時刻でカード描画。iPhone / iPad で共通の行コンポーネントを使用（INV-005）。
• Calendar（iPad） — CalendarSupport が TripLeg を正規化し、Bid Period 開始からの日付インデックスを UTC で 計算（INV-009）。8 週間グリッドを「運用 > Bid > 個人」のレイヤーで描画（INV-010）。

保存先

• ローカル JSON（Documents/CrewAccessImports/）— 取り込みスケジュールの正本。
• App Group 共有コンテナ — 共有拡張↔本体の受け渡しとウィジェット用データ。
• Keychain — TripBoard の認証情報。
• UserDefaults / ローカルキャッシュ — ScheduleCacheService 経由。

外部サービス

• TripBoard（OpenTime） — tripboard.bidproplus.com / fltops-portal.ups.com。任意・読み取り専用で、ユーザー自身の認証情報が必須。自動ログインや MFA 回避は一切なし。デモモードでは無効。
• 独自のクルーシステム API は使わず、CrewAccess の自動スクレイピングもしません(CrewAccess は Zscaler + MFA の背後にあるため、取り込みは手動 PDF 共有のみ)。

CloudKit の使い方

コンテナは iCloud.com.sfune.TimelineSchedule、Public Database のみ（プライベート DB・CKShare は不使用）。背景は docs/ADR/ADR-001-public-cloudkit-phase1.md を参照。

同期の設計

• 自分の端末間 — DeviceScheduleCloudKitService が TDHDeviceScheduleSnapshot を送受信。local-wins で、ローカルの updatedAt が新しければリモートを採用しない（INV-007）。起動時は ローカルが上書きされる前に 取り込みファイルを取得・整合させる必要があり、これを誤ると新しい端末が自分のデータを消してしまう。
• 取り込みファイル同期 — CrewAccessImportCloudKitService がトリップ単位の生 JSON を同期。削除はレコードのハード削除ではなくトゥームストーン（deletedAt）で表現し、他端末側でローカルファイルを消す（INV-008）。
• フレンド共有 — GEMS 認証・友人リンク承認・共有スケジュール／プロフィールの送受信を、それぞれの CloudKit サービスが担当。

カウントダウン / ライブアクティビティ

ウィジェット拡張は App Group 経由で共有スケジュールを読み取ります。ホーム画面ウィジェットは T-12h〜T-6h、ライブアクティビティ（iOS 16.1+）は T-6h〜T+6h をロック画面・ダイナミックアイランドで表示し、STD を過ぎても未出発なら「Delayed」に切り替わります。制御は FlightCountdownCoordinator / FlightCountdownSupport。

守るべき不変条件（Invariants）

変更時に必ず守るべき土台のルールです。全文は docs/INVARIANTS.md。

3現状

現行バージョン / 本番機能 / 開発の重心 / watchOS / 技術的負債 / テスト

現行バージョン

• Version 1.2.1 / build 68 — project.yml（全 3 ターゲット）で確認済み。最新コミット 681ecba "Release v1.2.1 build 68"（2026-06-13、当日の出来立てリリース）と一致。
• バンドル ID は com.sfune.BidProSchedule（製品名は TripDataHub だが、バンドルレベルでは旧称を維持）。
• 最低 iOS 17.0。iPhone / iPad とも対応で UI は別。

本番に載っている機能

• CrewAccess PDF の取り込み（共有拡張 → App Group → PDFKit 抽出 → 行ベース解析）。
• Timeline タブ（トリップ・フライト・デッドヘッド・レイオーバー・手動運用イベント）。
• iPad の 8 週間 Bid Period カレンダー（運用 / Bid / 個人のレイヤー）。
• 次のフライトのカウントダウン（ウィジェット T-12h→T-6h ＋ ライブアクティビティ T-6h→T+6h、STD 後は自動「Delayed」）。
• フレンド共有（GEMS ID 相互承認、CloudKit Public DB、CKShare 不使用）。
• 手動の運用イベント（RSV-A/B/C/D・LCO・HOT・RCID・CQ12/CQ6）。
• 手動の個人イベント（通勤・医療・予約・その他）。
• CloudKit 端末間同期（local-wins、トゥームストーン削除）。
• LogTen 互換エクスポート。
• TripBoard「OpenTime」閲覧（任意・ユーザー認証・読み取り専用、起動時自動取得オプションあり）。
• App Review デモモード（APPSTORE_REVIEW フラグ。GEMS 認証をバイパスし、OpenTime / Friends を隠して合成サンプルデータを使用。PDF 取り込み・Timeline・Calendar は審査でも利用可）。

最近の開発の重心

直近 12 コミットほど（2026-05〜06-13）は フレンド共有 / プロフィールの CloudKit 同期の信頼性向上 に集中しています。具体的には、友人タイムライン同期の修正、友人リクエストの同期リカバリと復元、リンク権限のフォールバック、マッチ時通知、アカウント削除時のリクエスト保持など。2026-06-10 の「プロフィール同期とデモデータの刷新」と、v1.2.0 / v1.2.1（build 67 / 68）が、この一連の作業の安定化・リリースの締めにあたります。

git 上には claude/* や feature/* ブランチが複数ありますが、feature/statistics や refactor/consolidate-dedup-layers 等は main に取り込み済みの完了履歴で、現在進行中の作業ではありません(例外は次の watchOS)。ほかに、マージ済みブランチに対応する古いワークツリーや、未追跡の docs/SIMULATOR_TROUBLESHOOTING.md / TDH-icon-1024.png が作業ツリーに残っています。

watchOS 対応 保留中

完成・検証済みだが、まだ main には統合されていない状態です。

調べて分かったこと

• 完全な watchOS MVP が feature/watchos に存在（単一コミット d08f733「v1.0.3 build 55: watchOS MVP (PR1–PR7)」、2026-05-24）。
• git merge-base --is-ancestor feature/watchos main は NO ＝ 一度も main にマージされていない。
• 分岐元は b1cf1ff（v1.0.3 build 54）で、現在の main から 20 コミット遅れ（その後の約 3 週間はフレンド共有強化に費やされた）。
• 現在の main には watch 関連ファイルが 一つもない。project.yml も watch ターゲットを定義していない。

ブランチ側の内容（参考）

• TripDataHubWatchApp/（watchOS 10.0、iOS アプリに同梱）— Trip / Reserve / Training / OffDuty の各モード画面とデバッグ用ピッカー。
• TripDataHubShared/ — 共有型（WatchOperationalMode ほか各種 Payload）。
• WatchConnectivity 転送（iPhone がスナップショットを生成し updateApplicationContext で送信、Watch 側でコールド起動をまたいで重複排除・永続化）。
• テスト（WatchSnapshotTests ほか。作成時点で 102/0 合格）と、ブランチ限定のドキュメント（検証チェックリスト・既知の制限）。

復活させるには、feature/watchos を現在の main にリベース／マージし、約 3 週間ぶんのずれ(分岐後に入ったフレンド共有・母基地まわりのモデル／サービス変更を含む)を解消したうえで、ブランチ内の検証チェックリストに沿って再検証する必要があります。

既知の技術的負債

• sharedTimelineCards: [WebTimelineCard]（TripModels.swift:156-187）に // TODO: Phase B 以降で削除予定 のマーク。現状アプリ内では未使用で、未着手の Web ビューア専用。
• CloudKit の Dev / Prod ずれ — スキーマ変更は Dashboard から Production へ手動デプロイが必須。両環境の不一致はフレンド共有不具合の 名指しの常習犯（docs/AI_CONTEXT_INDEX.md に明記）。
• CHANGELOG / RELEASE_NOTES が古い（v1.0.0 止まり）。v1.1.2〜v1.2.1 のリリースノートが存在しない。
• README.md は分類ルールと BP / PP 日付表だけの参照データで、プロジェクト概要になっていない（「BidProSchedule Notes」見出しのまま）。優先度は低いが要リライト候補。
• Calendar V2 のスコープ項目(疲労オーバーレイ、トリップ編集、ドラッグ＆ドロップ、同僚カレンダー重ね合わせ、リアルタイム運用追跡、月表示)は仕様で 明確にスコープ外。「すぐできる改善」として提案しないこと。
• 古いワークツリーや未コミットの画像・ドキュメントが作業ツリーに残置(ブロッカーではなく片付け案件)。

次の作業

ロードマップ以上の明確な将来計画ドキュメントはありません。最も具体的な兆候は、フレンド共有 / プロフィール同期が安定リリース点（v1.2.1 / build 68）に到達したこと。新たな同期不具合が出ない限り、次の重心はロードマップ側の項目(Web タイムラインビューアの実装、カウントダウンの種類追加、Calendar V2 項目)へ移ると見られます。

テストの状況

ユニットテストは次をカバー：カウントダウンのフェーズ／時間／レグ選択、カレンダーの日付インデックス・BP/PP 所属・DST のエッジケース、PDF パーサのリグレッション（ゴールデン JSON）、端末同期の local-wins 挙動、LogTen エクスポート形式、取り込みファイルの CloudKit 同期、GEMS 認証同期（build 32+ で追加の domicile / schemaVersion: 2 を含む）、端末スナップショット同期、取り込み受け渡し、プロフィール同期、友人リクエスト照合、スナップショット符号化、App Group 受け渡し、次レポート時刻の計算。加えて UI テストターゲット（TripDataHubUITests）あり。

4ロードマップ

Planned（着手・確定済み）/ Proposed（仕様上の将来項目）/ Ideas（緩い言及）