hz-unity-device-readiness

デバイス対応状況

コンテキスト

このスキルは、Meta VR Glasses デバイスの要件に合わせて Unity プロジェクトを、入力（フォールバックではなく、主要な入力としてのハンドトラッキング）と視野角（現在の Quest ヘッドセットより FoV が狭いデバイス）の 2 つの観点から準備します。入力に関するワークフローはすぐ下にあり、視野角に関するワークフローは後半の独立したセクションにあります。

対象デバイスでは、フォールバックではなく、ハンドトラッキングを主要な入力方式として扱います。既存の Quest プロジェクトのほとんどはコントローラーを前提に構築されているため、必要な作業は単に「ボタン操作をジェスチャーに置き換える」だけではありません。コントローラーより劣る感覚にならず、手で自然に操作できるよう、インタラクションデザインを見直す必要があります。体系的に調査することが重要です。コントローラーへの依存箇所をすべて見つけ、背後にあるゲームプレイ上の意図を理解し、適切な ISDK パターンに対応づけます。

Meta VR Glasses または Meta Quest デバイスが接続されている場合は、まず実際のデバイスデータを基に監査してください。metavr device list で接続されているデバイスを確認でき、metavr device info <id> で監査対象となるデバイスの入力機能とディスプレイ機能を確認できます。

分析ワークフロー

ステップ 1：プロジェクトをスキャンする

プロジェクトが現在どのように入力を処理しているか、全体像を把握します。コントローラーへの依存箇所は、意外なところに潜んでいます。明らかな OVRInput.Get() の呼び出しだけでなく、XR Interaction Toolkit のコンポーネント、Unity の旧 Input システム、カスタムのグラブシステムにもあります。幅広く調査してください。

# Find controller input usage
grep -r "OVRInput\.\(Get\|GetDown\|GetUp\)" --include="*.cs" .
grep -r "OVRInput\.Button\|OVRInput\.Axis" --include="*.cs" .

# Find XR Interaction Toolkit usage
grep -r "XRGrabInteractable\|XRRayInteractor\|XRDirectInteractor" --include="*.cs" .

# Find legacy Input system usage
grep -r "Input\.GetButton\|Input\.GetAxis\|Input\.GetKey" --include="*.cs" .

# Find interaction patterns
grep -r "Grabbable\|IGrabbable\|OnGrab\|OnRelease" --include="*.cs" .
grep -r "Raycast\|RaycastHit\|Physics\.Raycast" --include="*.cs" .

ステップ 2：調査結果を分類する

各項目を次のように分類します。

カテゴリ	調査対象	影響
コントローラー入力	OVRInput.Get()、ボタン／軸の参照	ハンドジェスチャーまたは ISDK コンポーネントへの置き換えが必要です
グラブシステム	トリガー式グラブ、距離グラブ	ピンチ検出を使う HandGrabInteractable に変換します
UI インタラクション	レイベースの UI、ポインタークリック	ポークインタラクション（PokeInteractable）に変換します
移動	サムスティックによる移動、スナップターン	ハンドベースまたは視線ベースのナビゲーションに再設計します
オブジェクト操作	サムスティックによる回転、ボタンによる拡大縮小	両手対応で、手による直接的な回転／拡大縮小を使用します

ステップ 3：適応方法を提案する

コントローラーに依存する各システムについて、ISDK に基づいた具体的な置き換え方法を提案します。実装の詳細は、references/hand-tracking-patterns.md にあるハンドトラッキングのパターンを参照してください。

ステップ 4：優先順位を付ける

影響度と作業量に基づいて提案をランク付けします。

• 優先度：高 — コントローラー API を使用している中核的なゲームプレイのインタラクションで、置き換えが必要なもの（例：OVRInput ベースのグラブ、トリガー式の射撃）。
• 優先度：中 — コントローラー API を使った副次的なインタラクション（例：サムスティックによるスクロール、レイベースの UI ナビゲーション）。
• 優先度：低 — すでにハンドトラッキングを使用しているコードを改善するための拡張（ホバーフィードバック、音声キュー、両手対応）。あると望ましい改善であり、ハンド対応に必須ではありません。

重要。 プロジェクトがすでに ISDK のハンドトラッキング（HandGrabInteractable、PokeInteractable など）を使用していて、コントローラーに依存するコードがない場合は、すでにハンド対応済みであると報告してください。拡張は優先度「低」の項目としてのみ挙げ、必須の変更として扱わないでください。すでに手で操作できるプロジェクトに、改善案を長々と列挙してはいけません。

出力形式

分析結果を次の構成のレポートとして提示してください。

1. プロジェクト概要 — プロジェクトの種類と中核となる仕組み。
2. 対応状況スコア — すでに手で操作できるインタラクションの、おおよその割合。
3. 必須の変更 — 優先順位を付けたリスト。各項目に以下を含めます。
   • 見つかった内容（具体的なファイル／クラス）。
   • 変更が必要な内容。
   • 使用する ISDK パターン（hand-tracking-patterns.md を参照）。
   • 推定される複雑さ（低／中／高）。
4. すぐにできる改善 — 簡単で影響の大きい変更。
5. 移行時のリスク — 注意すべき潜在的な問題。

主要な参考資料

詳しい実装パターンについては、以下を参照してください。

• references/hand-tracking-patterns.md — コンポーネントの参考情報を含む、7 つの ISDK インタラクションパターン。
• references/migration-guide.md — コントローラーからハンドトラッキングへ移行するための、ステップごとのチェックリスト。

重要な注意事項

• 移行中は、フォールバックとしてコントローラーのサポートを常に維持してください。
• アクセシビリティを考慮してください。一部のユーザーは、コントローラー入力を好む場合や、必要とする場合があります。
• パフォーマンスは重要です。ハンドトラッキングは CPU の負荷を増やすため、効率的な実装を提案してください。
• 左右両方の手でテストしてください。右利きが標準だと決めつけないでください。
• ハンドトラッキングは、腕の届く範囲内でのインタラクションに最適です。

視野角への対応（頭部固定 UI）

現在の開発対象デバイスより視野角が狭いデバイス向けにプロジェクトを準備するときに実行してください。広い視野角では収まっていても、視野角の狭いデバイスでは端でクリッピングされる頭部固定（HUD）UI（照準、体力／弾薬カウンター、ミニマップ、チュートリアルのピン、ビネット／レターボックスのオーバーレイなど）を見つけ、それぞれに移行時の修正案を提示します。これは、上記の入力ワークフローとは別の調査です。

「FoV bleed」の意味

VR では、ユーザーは頭を動かして画面外を見られるため、何かが恒久的に画面外になることはありません。実際にクリッピングされるのは、カメラに固定された角度オフセットで UI が配置される頭部固定コンテンツです。そのオフセットが広い視野角には収まっていても、視野角の狭いデバイスの視錐台を超えていれば、毎フレームクリッピングされ、視界に入れることはできません。この調査で完全に検出できるとするのは、この種類だけです。

信頼性に関するルール

ジオメトリを計算してください。決して推定しないでください。シーン／プレハブの YAML を読み、ネストされたトランスフォームの三角関数計算を頭の中で行ってはいけません。実行中のプロジェクトから解決済みのトランスフォームを取得してください。Play モード（またはビルド）で実行し、ライブオブジェクトを読み取ってから、以下の決定論的な視錐台テストを適用します。計算結果に基づいて判定し、分類と提案を行ってください。

ゲームの HUD 状態に到達して、手作業でクリックする代わりに自動化するには、Meta XR Operator で実行中のビルドを操作してください。プロジェクトを実行してゲームプレイ状態を再現できるため、各状態で解決済みのオブジェクトを確認できます。プロジェクトをライブで実行・確認できない場合、この調査は静的ファイルだけでは信頼性がありません。推測するのではなく、その旨を伝えてください。

視野角仕様の情報源

視錐台テストでは、両方の視錐台について、接線の半角が必要です。

• { leftTan, rightTan, upTan, downTan } — 対象デバイス（視野角が狭いデバイス）
• { leftTan, rightTan, upTan, downTan } — 現在のデバイス（「以前は収まっていたが、今は収まらない」という差分の確認用）

これらの値には、対象デバイスの公開されている視野角仕様を使用してください。両方の値セットが揃っていない場合は、視野角の調査を省略し、その旨を伝えてください。手元にない数値を決して推測しないでください。

手順

1. プロジェクトをライブで実行・確認できること（たとえば、Meta XR Operator でビルドを操作するなど）と、両方の視錐台パラメーターセットが揃っていることを確認します。いずれかが欠けている場合は中止し、その理由を報告してください。
2. 頭部固定 UI の候補を列挙します。renderMode が ScreenSpaceOverlay／ScreenSpaceCamera の Canvas、またはトランスフォームの親子関係がトラッキング対象のカメラ／CenterEyeAnchor／OVRCameraRig の中央眼を経由する Canvas／RectTransform／Renderer を対象とします。全画面のビネット／レターボックスのオーバーレイも対象です。頭部に親子付けされていないワールド固定のコンテンツは除外します。
3. 各候補について、解決済みの四隅のワールド座標と中央眼カメラのワールドトランスフォームを、YAML ではなく実行中のプロジェクトから取得します。
4. 視錐台テスト（各頂点を眼の空間に変換し、z > 0 の場合）：tanX = x/z、tanY = y/z。デバイス内にある頂点は、-leftTan <= tanX <= rightTan かつ -downTan <= tanY <= upTan を満たします。Bleed とは、少なくとも 1 つの頂点が現在のデバイス内にあり、対象デバイスの外にある状態です。
5. 検出した各 bleed を深刻度順に報告し、対象デバイスの視野角端を超える各頂点の余裕（度）を記載します。

重大度

• 重大 — プレイヤーが常に確認する必要のある HUD（照準、体力、弾薬、目標マーカー）がクリップされています。
• 警告 — 副次的な HUD が一部クリップされている、または視野角が狭くなった状態に対してコンフォートオーバーレイのサイズが適切ではありません。
• 参考 — 画面端に近い、装飾的な視点固定要素です。

移行ガイダンス

• 対象の角度上限内に HUD を収めます。必ず視認する必要のある HUD には、主要な 0～30° の範囲を優先します。
• HUD の半径／基準距離を小さくして、HUD のまとまりが占める角度を抑えます。
• 画面端に配置する必要がある HUD は、画面外インジケーター（矢印／画面端の発光表示）に置き換えます。
• ビネット／レターボックスを、広い視野角ではなく狭い視野角に合わせて再調整します。
• クリップされた HUD を単に非表示にするのではなく、位置を変更します。通常、表示される情報は必要です。

制限事項（レポートに明記してください）

• 完全性が保証されるのは視点固定 UI のみです。周辺視野で見えることが想定されるワールド固定コンテンツや、特定のゲームプレイ状態でのみ表示されるものは対象外です。
• これは一次近似モデルであり、中央の単眼視錐台を使用します。ステレオ（片目にしか見えない要素）とレンズ歪みは対象外の拡張要素です。
• 視錐台の設定を取得できなかった場合は、チェックをスキップしたと明記してください。実行されていないのに「問題は見つかりませんでした」と報告してはいけません。