結論：FigmaではiPhone Duoの画面案と姿勢ごとの意図を先に整理し、ネイティブアプリの挙動は開発ビルドと利用可能なテスト環境を確認してから検収してください。今週は、デザイン準備と実機・シミュレーターでの確認を別の作業として開発側と合意しましょう。
UIデザイナー：iPhone Duo向けの画面をFigmaで設計し、姿勢ごとの意図を伝えたい方に向けています。
プロダクトデザイナー：双画面のレイアウトや操作の想定をAppleプラットフォームの開発者へ渡す方に役立ちます。
Windows中心のチーム責任者：今の環境で進められる準備と、Macが必要な検収を切り分けたい場合に読んでください。
最終更新：2026年10月10日。Apple Developerのデザインリソース更新、iPhone Duoの設計指針、公式デザインリソースを確認しました。端末、シミュレーター、Xcodeの対応状況は更新される可能性があるため、作業開始時にも公式情報を見直してください。
01着手前に、今回の「検収」を分けて定義します
まず、依頼されている納品物がどれなのかを確認します。Figma上の視覚案、操作の説明、または実行できるネイティブアプリでは、確認できることが異なります。ひとまとめに「デザイン確認済み」とすると、未検証の動作まで承認されたように受け取られるおそれがあります。
- 視覚案の確認：画面の構成、文字、色、主要な部品の位置をFigmaで確認します。
- 操作説明の確認：操作前後の状態や画面遷移が、仕様として開発者に伝わるかを見ます。
- ネイティブアプリの検収：開発ビルドを、利用可能と確認できた端末またはシミュレーターで動かして確かめます。
この区分を、作業依頼や納品メモの冒頭に記載してください。Figmaファイルの共有だけでネイティブアプリの動作まで承認したことにはなりません。
02Figma UI Kitは設計の土台として使います
Appleはデザインリソースの更新を案内し、iOSおよびiPadOS 27向けのFigma UI Kitを提供しています。キットは画面案を組み立てる出発点として便利ですが、それを使っただけでiPhone Duo上の表示や動作が保証されるわけではありません。対象のキットや配布素材の利用条件は、公式デザインリソースとライセンスを確認してください。
配布素材をチームで利用する場合は、Apple Design Resourcesのライセンスも確認します。納品先へ渡すファイルに、素材の利用条件を無視した再配布が含まれないようにしましょう。
WindowsからFigmaを操作する場合は、先にブラウザーと作業環境を確認します。Figmaのブラウザー設定に関する案内を参照し、ファイルを編集・共有できる状態を整えてください。これはFigmaでの準備に関する確認であり、Mac用の開発ツールを使えることの証明ではありません。
03姿勢ごとの差を、画面と注釈で伝えます
iPhone Duoの公式設計指針では、デバイスの姿勢や双画面に応じた動的なレイアウトが扱われています。デザインでは、どの情報をどの画面に置くのか、姿勢が変わったときに操作や情報の優先順位がどう変化するのかを、開発者が追える形にします。設計内容は、冒頭で案内したAppleの公式指針と照らし合わせ、Figma UI Kit上の部品をそのまま配置するだけで終わらせないようにします。
具体的には、代表画面ごとに次の内容をそろえます。
- 画面の目的：画面が担う役割と、利用者に見せたい情報を記します。
- 姿勢ごとの違い：レイアウトの変化が想定される場合、画面案を分けるか、注釈で差を説明します。
- 主要な操作部品：ボタンや入力欄の位置、操作後に期待する状態を記します。
- 未確定の挙動：設計で決めていないことと、開発・検証で判断することを分けます。
ここで重要なのは、Figmaの表示を実機の挙動と同一視しないことです。静止画は画面構成を伝え、プロトタイプは設計した遷移を説明できますが、ネイティブアプリの応答や端末上での表示を確認した証拠にはなりません。
04開発引き継ぎでは、判断の担当者を明記します
開発者にファイルを渡す前に、画面名だけでなく、どの状態を再現すれば設計意図を確認できるのかを整理します。代表画面、姿勢ごとの差、操作前後の状態、未確認事項を一か所にまとめると、質問や修正の対象を絞れます。
シナリオ段落の例として、一覧から項目を選んだ後に詳細をどちらの画面へ表示するか、姿勢が変わるときに操作部品をどう扱うかを記載します。これは設計意図を共有するための例であり、iPhone Duoでの動作を確認済みという意味ではありません。
引き継ぎ資料では、項目ごとに「デザイン決定」「開発側で実装」「テスト環境で要確認」と担当を明記してください。Macや対象端末の準備が済んでいない場合は、実機確認の期限や担当も未確定事項として残します。
05よくある確認事項
納品前の判定チェックリスト
上から順に確認し、該当する分岐に従ってください。チェックできない項目がある場合は、原生アプリの検収を完了扱いにせず、未確認として記録します。
- [ ] Figmaの視覚案と注釈を渡すだけですか？ はいの場合は、Windows上で画面と状態の説明を整えて開発者へ共有します。この段階だけならMacを手配する必要はありません。
- [ ] ネイティブアプリの動作まで確認しますか？ はいの場合は、開発ビルドが用意できるかを開発担当者に確認します。ビルドがない場合は、まずビルドの準備を依頼し、動作確認を合格にしないでください。
- [ ] 対象端末またはシミュレーターの利用可否を公式情報で確認できましたか？ はいの場合は、確認した環境と操作を記録して検収へ進みます。確認できない場合は、対応を推測せず、利用可否が判明するまで検収を保留します。
- [ ] macOS上の開発ツールが必要で、手元にMacがありませんか？ はいの場合は、プロジェクト、アカウント、テスト条件を確認してから、ローカルMacと遠隔Macを比較します。原生ツールを使わない作業なら、現在のWindows環境で進めます。
この順序なら、設計作業だけのためにMacを手配する事態や、未確認のシミュレーター対応を前提に工程を組むリスクを抑えられます。
06ネイティブアプリの確認は、環境の対応を調べてから進めます
作業開始時には、AppleのiPhone Duo向け開発準備資料を確認し、チームの開発ビルドで使える端末やツールが示されているかを調べます。Xcodeのバージョン情報は公式リリースノートで照合してください。資料に記載が見つからない場合、特定のシミュレーターがiPhone Duoをサポートすると決めつけず、開発担当者に確認します。
シミュレーターを使う場合でも、画面サイズや操作の再現範囲が実機と同じとは限りません。AppleのXcodeシミュレーター操作の解説を参考に、使用環境と確認した操作を記録します。実機とシミュレーターのどちらも利用できるか確定していなければ、検収計画を確定扱いにしないでください。
Macが必要になるのは、Figmaの画面案を作るときではなく、プロジェクトのビルドやmacOS向け開発ツールを使う工程がある場合です。チームに使えるMacがあるなら、その環境での確認を優先できます。手元の環境では工程を実行できない場合に限り、ローカルMacと遠隔Macの条件を比較しましょう。
07証拠に合わせて修正か納品かを決めます
検収記録は、結果を次の区分に分けると誤解が減ります。
- 確認済み：Figmaの視覚確認、共有資料の確認、利用した環境で実施した操作。
- 未確認：テスト端末が未確保、シミュレーター対応が未確認、開発ビルドが未準備などの理由がある項目。
- 対象外：今回の納品範囲に含まれない機能や端末条件。
不具合が出た場合は、Figmaの想定、実装、実行環境のどこで差が生じたのかを分けて開発者へ返します。確認していない項目は合格にせず、制限と次の担当者を記録してから納品可否を判断してください。
08Macを手配するのはネイティブ検収が必要な場合です
WindowsとFigmaだけで進める方法は、画面設計や注釈づくりを始めやすい一方、ネイティブアプリのビルドやmacOS上の開発ツールによる確認は別途必要です。Macを購入すれば手元で使えますが、今回の検収だけが目的なら、購入費用や継続的な保有が負担になる場合があります。反対に、同じMacを長期間、継続的な高負荷作業に使う場合や、物理接続が必要な場合は、レンタルより自前の実機が向くこともあります。
プロジェクトでネイティブツールを使うと確認できた後なら、VpsMeshのMac環境を確認して、必要な期間や利用条件が合うかを見比べられます。東京のMac環境を候補にする場合は、Mac miniの利用案内も確認してください。Figmaのデザイン準備だけであれば、まず現在のWindows環境で進め、Macの手配は開発ビルドとテスト条件が固まってから判断するのが適切です。