Xcode のエージェントで UI プロトタイプを作る

ハイライト

Xcode の coding agents と SwiftUI Previews を組み合わせると、開発者は自然言語で要件を説明するだけで、インタラクティブな UI プロトタイプをすばやく生成できます。反復的なプロンプトで複数のデザイン方向を試し、現実味のあるコンテンツを入れ、アニメーションパラメータを微調整し、最終的に生成されたネイティブ Swift コードをそのまま本番開発に持ち込めます。

主要内容

曖昧さから精密さへ：プロンプトでデザイン方向を制御する

（02:56）

多くの開発者が初めて coding agent を使うとき、「読書会を管理する App を作って」のような、とても広いプロンプトを書きます。Agent は一見使えそうな画面を生成しますが、すぐに問題が出てきます。ナビゲーション構造は任意に選ばれ、機能一覧は推測で作られ、投票やアルバムのような関係の薄い機能に引きずられることもあります。その後の修正はどんどん肥大化します。

Apple のデザインチームの助言は明快です。誤解しようがないほど具体的なプロンプトを書くことです。

具体的にはどうすればよいのでしょうか。

第一に、欲しい機能を明確に列挙します。Agent があなた以上に App を理解していると期待してはいけません。

第二に、スタイルの手がかりを与えます。読書会の App なら、カフェのような暖かい雰囲気にしたいのか、紙と美しい組版の質感にしたいのかを伝えます。

第三に、複数案の生成を求めます。初期段階は違う方向性を探索するのに最適な時期です。1 つの案だけを受け取ってすぐに修正を始めない方がよいです。

（04:48）

発表者は改善されたプロンプト例を示しました。10 種類の異なるスタイルの読書クラブ App 画面を生成し、それぞれに独立した名前と Swift Preview を持たせる、というものです。Agent は、タブ構造の “Club Hub”、New York フォントと明確な区分を持つ “Cozy”、雑誌風レイアウトの “Editorial”、グリッドから詳細画面へ進む “Blueprint Atelier” など、さまざまな案を生成しました。

重要なのは、複数案から気に入った要素を選び、それらを agent に「リミックス」させられることです。

（06:13）

発表者の反復プロセスは典型的でした。“Cozy Club” のスタイルから始め、racetrack 型の進捗可視化を取り入れ、中立的な外観に寄せ、最後に冗長な要素を整理していきます。このプロセスの合言葉は、go wide, remix, repeat です。

画面を「生きたもの」にする：現実味のあるコンテンツを入れる

（07:31）

構造ができたら、次は App が実際に誰かに使われているように見せることです。空白のテンプレートや粗いプレースホルダーでは、実際の使用感は見えてきません。

Agent は「ユーザー」の役割を演じ、もっともらしいサンプルデータを生成できます。そこに自分で取り込んだ実際の画像を組み合わせると、空洞のテンプレートが、実際の利用場面に近い、豊かで現実味のある画面に変わります。

実用的なコツは次のとおりです。

複数の preview を求め、異なるコンテンツ状態をカバーする
境界条件を自分でも考える。会議予定がない場合、詳細エリアは何を表示するのか。メンバー一覧が非常に長い場合はどうするのか
サンプルコンテンツが対象ユーザーの実際の文脈に合っていることを確認する。読書クラブの議論は本に関する内容であるべきです
無制限に増えうる UI 要素に注意する。メンバー数、メッセージの長さ、過去の本の一覧などです
サンプルデータを独立した編集可能なファイルに置くよう agent に求める

（09:52）

発表者は、現実味のあるコンテンツを入れたことで見つかったいくつかの UI 問題を示しました。非常に長い会議説明が本の表紙を覆う、ランキングのメンバーが多すぎてスクロールが長くなる、空状態やアカウント管理への入口がない、などです。こうした問題は、実際のコンテンツを入れる前には予測しにくいものです。

重要なインタラクションを微調整する：アニメーションとモーションのパラメータ

（11:19）

SwiftUI の強みは、静的な画面だけでなく、インタラクション、アニメーション、遷移も構築できることです。ただし、アニメーションのパラメータはコードのあちこちに散らばりがちです。手作業で調整すると、文脈を何度も切り替える必要があり、体験としてはぎこちなくなります。

発表者は 1 つの考え方を提示しました。Agent に「調整パネル」を作らせることです。

SwiftUI でよく使うアニメーションの種類は次のとおりです。

ease：イージングアニメーション。加速、減速、時間を制御できる
spring：スプリングアニメーション。stiffness（剛性）、damping（減衰）、mass（質量）を調整できる

アニメーション以外にも、調整する価値のある動的要素があります。

friction と inertia：ドラッグ時の摩擦と慣性。要素の「重さ」を左右する
device motion：加速度計やジャイロスコープへの応答。Wallet の Apple Cash カードにある虹色の視差効果のようなもの
haptics：触覚フィードバック。Find My で対象に近づいたときの振動のようなもの

（13:43）

調整パネルのベストプラクティスは次のとおりです。

何を反復したいのかを詳しく説明する。アニメーションスタイルなのか、スプリング曲線なのか、複数要素の協調アニメーションなのか。
アニメーションを複数の phase に分け、共通の語彙を作る。
調整パネルをアニメーションだけでなく、App 状態、色、フォント、視覚的なオフセットの切り替えにも使う。
パネルとメイン画面を横並びにし、大きなウィンドウで同時に見られるようにして、文脈切り替えを避ける。

（15:46）

発表者は、本の詳細画面への遷移アニメーションを調整する流れを示しました。横並びの調整パネルによって、phase 1（表紙から詳細画面への遷移）と phase 2（コンテンツ行の staggered な入場）を別々に制御できます。delay や stagger の値をリアルタイムで調整し、bouncy プリセットも試しながら、最も自然な動きの組み合わせを見つけていきました。

基本原則は、複数のビュー構成を管理したり、異なるアニメーションパラメータを比較したりする必要がある場面では、調整パネルを作ることです。フィードバックループを短くし、最適解をすばやく見つけられます。

詳細

Coding Agents と Xcode Previews の連携

（01:21）

Xcode の coding agents は、作りたい機能を自然言語で説明すると、agent が直接コードを生成してくれます。操作は、new conversation ボタンをクリックし、欲しいコード変更や機能を説明するだけです。

Xcode Previews を使うと、毎回再コンパイルして実行しなくても UI の結果を確認できます。Swift ファイルに preview view があることを確認し、show canvas ボタンをクリックすればリアルタイムでプレビューできます。

この 2 つを組み合わせると、coding agents がコードを生成し、Previews がすぐに結果を表示する高速な反復ループができます。しかも agent が出力するのは本物のネイティブコードなので、後続の開発でそのまま再利用できます。

プロンプトエンジニアリング：悪い例から良い例へ

悪いプロンプト：

定期的集まりを持つ読書クラブの管理画面を作成する。

問題点：agent がレイアウトを任意に選び、機能を推測するため、機能の肥大化や重い画面につながりやすい。

改善したプロンプト構造：

読書クラブ App 向けに 10 種類の異なる UI バリエーションを生成する。それぞれに以下を含める：
- 独立した名前（例："Cozy"、"Editorial"）
- 独立した Swift Preview
- 明確な機能一覧：現在の本の表示、会議予定、メンバーの議論エリア、読書進捗
- スタイルの手がかり：暖かい書店の雰囲気 / 雑誌風レイアウト / モダンでシンプルなスタイル

要点：

1 つだけでなく、複数の選択肢を求める
機能範囲を明確にし、agent の推測を避ける
スタイルや感情の手がかりを与える
各バージョンに独立した名前を付け、後から remix しやすくする

リミックス戦略

（06:01）

複数案の中から好きな要素を見つけたら、次のようなプロンプトで agent に統合を依頼できます。

次の要素が気に入っています：
- Cozy 版の New York フォントと明確な区分
- Racetrack 版の進捗可視化
- Blueprint Atelier のグリッドナビゲーション

新しい混合案を生成してください。各案には独立した Swift Preview と名前を残してください。

現実味のあるコンテンツを入れるためのプロンプトテンプレート

（09:28）

読書クラブ App 向けに現実味のあるコンテンツデータを生成する。要件：
- 次の境界条件をカバーする：会議予定なし、非常に長い説明文、大量のメンバー、空の議論エリア
- サンプルデータは本のテーマを中心にし、実際のユーザー場面に合うものにする
- データは独立した編集可能なファイルに置く
- 各境界条件に独立した Swift Preview と説明的な名前を付ける

アニメーション調整パネルの設計

（14:11）

Agent に調整パネルを生成させるときのプロンプトの要点は次のとおりです。

遷移アニメーションを管理する調整パネルを作成する：
- Phase 1：表紙画像が詳細ページへ遷移する
- Phase 2：コンテンツ行が staggered なタイミングで入場する
- 調整可能なパラメータ：delay、stagger 間隔、スプリング剛性、減衰
- bouncy / smooth / snappy のプリセットオプションを使う
- パネルとメイン画面を横並びで表示し、大きなウィンドウで同時に確認できるようにする
- 各 phase は独立してオンオフでき、個別にデバッグしやすくする

関連する SwiftUI API の呼び出し方：

// スプリングアニメーション
.withAnimation(.spring(stiffness: 100, damping: 10)) {
    // 状態変更
}

// スタガードアニメーション
ForEach(Array(items.enumerated()), id: \.element.id) { index, item in
    ItemRow(item: item)
        .transition(.opacity.combined(with: .move(edge: .bottom)))
        .animation(.easeInOut.delay(Double(index) * staggerInterval), value: isVisible)
}

要点：

.spring(stiffness:damping:) はスプリングの物理特性を制御する
.delay() は要素の入場における stagger 効果を制御する
.combined(with:) は複数の遷移効果を組み合わせる
value パラメータにより、目的の状態が変化したときだけアニメーションが発火する

デザイン哲学：Agent は協力者であって、デザイナーではない

（17:33）

発表者は 1 つの原則を繰り返し強調しました。重要な思考をツールに丸投げしてはいけない、ということです。Agent はプロトタイピング過程の協力者であり、最高の体験を見つける手助けをしてくれます。しかし最終的な判断権は常にあなたの手元にあります。

Coding agents の強みは、疲れることなく新しい案を出し続けられることです。あなたの役割は、自分の判断力でユーザーにとって最良の体験を作ることです。

主な示唆

何をするか：次の App プロジェクトで「デザイン探索」ワークフローを作る。まず agent に 5-10 種類の異なるスタイルの画面案を生成させ、すばやく比較してから深く反復する。 なぜ価値があるか：このセッションは、曖昧なプロンプトと精密なプロンプトの差が非常に大きいことを示しています。早い段階で複数方向を探索すると、後から誤ったデザイン判断に縛られにくくなります。 始め方：Xcode で coding agent を開き、「[機能説明] の画面を X 種類の異なるスタイルで生成し、それぞれ独立した Preview を持たせて」と最初のプロンプトにします。
何をするか：App の重要な遷移アニメーションに内部用の調整パネルを作り、デザイナーやプロダクトマネージャーが直接パラメータを調整できるようにする。 なぜ価値があるか：セッションでは、調整パネルによって「コード修正、コンパイル、確認」という分単位のループを秒単位に短縮でき、得られたパラメータ値をそのままコードに戻せることが示されました。 始め方：Agent に横並びレイアウトの tuning panel を生成させ、@State でアニメーションパラメータを管理し、Slider と Picker で .spring() や .delay() の値をリアルタイムに調整します。
何をするか：プロトタイプ段階から現実味のあるコンテンツデータを入れ、空状態、長すぎるコンテンツ、大量データなどの境界条件をカバーする。 なぜ価値があるか：セッションで示された複数の UI 問題、たとえば表紙が隠れる、ランキングが長すぎるといった問題は、現実味のあるコンテンツを入れて初めて露出しました。空白テンプレートは実利用での体験欠陥を隠します。 始め方：Agent に独立した sample data ファイルを生成させ、極端値と境界条件を含め、各条件に対応する Preview を用意します。
何をするか：Agent が生成したプロトタイプコードを、一度きりの草稿ではなく、本番開発の出発点として扱う。 なぜ価値があるか：セッションでは、agent が生成するのは本物のネイティブ Swift コードであり、そのまま carry forward できると明言されています。プロトタイプから本番への作り直しを避けられます。 始め方：プロトタイプ段階から正式な SwiftUI プロジェクト構造を使い、コードを清潔に保ち、反復の途中で不要になった Preview バリエーションを定期的に整理します。