AIに伝えておきたい仕事のルール：AppleのiPhone Duo設計ガイドに学ぶ

2.1 手順より先に目指す結果を書く

Appleは冒頭で、端末を開閉しても作業を続けられる体験を示しています。これが後に続く細かなルールの共通の目的になります。AI向けのガイドも結果を先に示すと、細則に書かれていない場面で判断する手がかりになります。

目標は使う人が確かめられる形で書きましょう。例えば「画面の配置が変わっても入力済みの内容は失われず、フォームの続きを書ける」とします。AIが画面を調整するときに入力内容を守る理由ができ、人にも確認する結果がはっきりします。

2.2 ルールで使う名前を先に説明する

Appleは画面、ヒンジ、カメラを先に紹介するので、後の配置ルールではその名前をそのまま使えます。共通の言葉を用意すると、各指示が何を対象にしているか明確になります。AIも用語の意味を毎回推測せず、条件を正しい部分に結び付けやすくなります。

自分のガイドでは、混同しやすい名前を説明しておきます。「カードは結果一覧の一項目を指す。カードを選ぶと詳細ページが開く」と書けば、「カードのタイトルを直す」という指示が明確になります。作業に影響する背景に絞ると、大切な定義も探しやすくなります。

2.3 変わる状況を挙げて共通のルールを探す

Appleはいくつかの使い方を挙げてから、少数のレイアウトの種類にまとめています。多くの具体例を、繰り返し使える判断方法につなげる書き方です。AIに個別の答えを並べて渡すだけでは次の状況を見落としがちですが、共通のルールは新しい場合を考える助けになります。

まず、長いタイトル、別の言語、狭いウィンドウなど、扱う変化を挙げます。そのうえで「タイトル全体を読めること」「操作できること」のような共通の条件を書きます。挙げた状況でルールを確かめ、本当に別の対応が必要な場合に例外を加えましょう。

2.4 指示を先に書き、理由と例を続ける

Appleの主な推奨事項は、短い太字の指示から始まり、理由、例、リンクが続きます。何をするかが見つけやすく、理由もすぐ近くにあります。AIが長いガイドの一部分を参照するときも、ルールとそれを使うための背景を一緒に読みやすくなります。

例えば、最初に「配置が変わっても入力済みの情報を保つ」と書きます。その後に理由と、入力途中でウィンドウの幅を変えるといった確認例を添えます。細かな説明を指示の後に置けば、次に参照するときも実行すべき一文をすぐに探せます。

2.5 状況が変わっても使えるルールにする

Appleは、使える空間と内容の関係でレイアウトの条件を説明しています。画面が変わっても、その関係は使えます。AI向けのルールでも、さまざまな状況で満たすべき条件を書くと、一つの例だけをすべての場合の答えとして扱うことを減らせます。

例えば、カードのルールなら「カードの幅は入る場所に合わせる。文章が折り返しても、ボタン全体が見えるようにする」と書けます。AIは幅に合わせて配置を考えられ、人は狭い画面と広い画面を同じ条件で確認できます。

2.6 条件と動作を一緒に書く

「カメラが動作しているときだけ存在する」という説明は、後に続く指示の条件をはっきりさせています。Appleはさらに、システムが自動で調整する部分と、独自の部品で対応が必要な部分を分けています。読者は変更する前に、そもそも対応が必要かを判断できます。

自分のルールにも「一覧が空のときは、理由の説明と追加ボタンを表示する」と書けます。条件を先に、動作を後に書きます。空の一覧と内容がある一覧の両方を見れば、AIが正しい場面でルールを使ったか確認できます。

2.7 使う道具まで具体的に示す

Appleは期待する動作と標準部品へのリンクを並べ、設計上の条件から実装方法へ進めるようにしています。AIにとって、部品名と正確な参照先があれば、自分で選んだり推測したりする点を減らせます。ルールを実際の変更につなげやすくなるのです。

例えば「ボタンはチームの部品集にあるサイズと色を使う。合う部品がなければ、何が足りないか説明してから新しい案を出す」と書きます。AIはどこから始めるか、その方法では足りないときにどう進めるかが分かります。

2.8 指示が及ぶ範囲を決める

Appleは配置用のビューの役割を定義してから、画面の移動を扱う部分をどこに置くか説明しています。この境界があると、それぞれの仕事をどの部分が受け持つか分かります。AIへの指示でも、変更の範囲を決めておくと、周辺の機能まで手を広げることを減らせます。

例えば「カードの配置を調整する。リンク先とボタンの動作は変えない」と書きます。最初の文で作業を示し、次の文で範囲を決めます。何を変えるための作業かが共有されるので、結果も確認しやすくなります。

2.9 基本のルールと例外を近くに置く

Appleは操作部品の通常の位置を説明した直後に例外を書き、その後で二つのアプリを並べる場合などを説明しています。この順番なら、読者は基本のルールを知ってから変更が必要な条件を判断できます。AIがこの部分だけを参照するときも、条件を一緒に見つけやすくなります。

フォームなら「項目名は原則として入力欄の上に置く。チェックボックスの項目名は、その横に置く」と書けます。二つの文を一緒に置き、それぞれ一例ずつ確認してもらえば、AIが基本のルールを違う場面に当てはめていないか分かります。

2.10 両立しない要求には優先順位を付ける

空間が足りなくなれば、すべてのボタンを表示し続けることはできません。Appleは優先順位を示し、グループや個々の項目についても調整できるようにしています。この書き方の良さは、何かを減らす必要が生じる前に、選ぶ基準を伝えていることです。

短い要約にも同じ考え方を使えます。「決定事項、担当者、期限を残し、背景の説明から短くする」と書きます。AIには削る基準ができ、人も事前に決めた順番で確認できます。書き直すたびに何が大切かを決め直す手間が減ります。

2.11 大まかな目標を確認できる条件にする

Appleは操作部品の位置についての指示に、理由とMailの例を続けています。その例を見ると、部品の位置によって、どの内容を操作するのかが伝わると分かります。ルールが目に見える結果につながるので、「分かりやすい画面にする」という目標だけよりも、実行しやすくなります。

自分の設計ルールなら「エラーの説明は修正が必要な入力欄の横に置き、どこを直すか分かるようにする」と書けます。具体的な動作、目的、確認する点が一文に入っています。AIは画面を作るときも、できあがりを見直すときも、この条件を使えます。

2.12 条件を満たせないときの進め方を書く

Appleは空間が足りない場合、画面の目的が閲覧か作業の完了かによって、何を残すか決めています。収まらない操作をまとめる場所も指定しています。何を選ぶかだけでなく、残りをどう扱うかまで書くことで、その場で判断する点を減らしています。

例えば「要約が一ページを超えたら、決定事項を本文に残し、補足の詳細を付録へ移す」と書けます。AIは短くする方法が分かり、詳細も残せます。それでも大切な内容を失う場合は、どの点を人に相談するかまで決めておきましょう。

2.13 例と参考資料で具体的な疑問を解く

図は位置関係を伝えるのに役立ち、正確な参照先があれば、本文のルールを長くせずに実装の詳細を確かめられます。Appleは両方を使っています。AI向けのガイドで参考になるのは、添える資料ごとに「目指す結果を見せる」「特定の疑問に答える」といった役割を持たせることです。

見本の画面を渡すときは、どこを見てほしいかも書きます。部品を使ってほしいなら、その部品へ直接リンクします。大切な条件は文章にも残し、AIのツールが画像やリンクを開けるか確かめましょう。資料は実際に読んで使えてこそ役立ちます。

Apple の図を見る

Appleのファイルにある参考資料

Markdownに含まれる補助資料へのリンクです。AIのコーディングツールが正しい資料を探せるよう、開発者向け資料の名前は原文のままにしています。

2.14 後から確かめて直せるルールにする

Appleの変更履歴と文末の情報には、日付と出所が残されています。読者はそこから助言の由来をたどり、もう一度確かめる必要があるか考えられます。繰り返しAIに渡すルールにも、この記録が必要です。製品が変われば、以前は合っていたルールも変わるからです。

更新するときは、何を、いつ、何に基づいて変えたか残します。例えば「9月14日：エラーの説明を入力欄の横に移す。承認済みフォームの例を参照」と書きます。日付だけより手がかりが多く、次に設計が変わったとき、人もAIも見直すルールを探しやすくなります。

2026年9月14日、この下書き用に提供された Markdown ファイルと照合しました。