「デザイン引き継ぎの失敗」とは具体的にどのような状況を指すのか？
デザイン引き継ぎの失敗とは、「ファイル転送のプロセス自体に技術的な問題が起きた」という意味ではなく、エンジニアが実際に実装した結果と、デザイナーが本来伝えたかった意図との間にずれが生じることを指す。ある状態が抜け落ちていたり（誰も読み込み中の画面をデザインしておらず、エンジニアが仕方なく適当に作る）、インタラクションの感触が違っていたり（タイミングが明示的に指定されていなかったため、アニメーションが速すぎたり遅すぎたりする）、視覚的な細部がずれていたり（システム上「青」という同じ名称が実は5つの微妙に異なる16進カラーコードに対応しており、エンジニアが間違ったものを選んでしまう）することがある。
これらの状況に共通しているのは、引き継ぎの時点では画面が「完成しているように」見えるという点だ。問題は、エンジニアが実装を始め、仕様がカバーしていなかった状況にぶつかったときに初めて表面化する。これが、引き継ぎの失敗が一度の劇的な爆発ではなく、一連のSlackメッセージ、確認の質問、遅延へと変わっていく理由でもある。ギャップの一つ一つが、実際に何を意図していたのかを確認するために作業を中断しなければならない、新たな割り込みとなる。
なぜデザインの引き継ぎは、単一の原因としてではなく「文脈のギャップ」と「成果物のギャップ」という2つに分解して語られるのか？
それは、この2つのギャップがまったく異なる方法で解決される必要があり、一緒くたに論じると問題に手をつけにくくなるからだ。成果物のギャップは「有形」の問題だ。欠けているのは具体的で、一つずつリスト化してチェックできるもの——このコンポーネントの読み込み中の状態はどう見えるか、この色の正確な16進コードは何か、このブレークポイントでレイアウトはどう並ぶか、といったものだ。この種の問題は理論上、より完全な仕様書やより優れた検証ツールによって体系的に埋められる。
一方、文脈のギャップは「無形」の問題であり、「何か」ではなく「なぜか」を問うている。同じ間隔の数字を見ても、エンジニアはそれがデザイナーの意図的な選択なのか、なんとなく決めたものなのかを、誰かが明示的に理由を注釈していない限り、数字だけでは判断できない。この種の問題は、より完全なチェックリストだけでは解決できない。なぜなら、欠けているのは特定の項目ではなく「決定の背後にある推論プロセス」であり、これは本質的に人間による説明を必要とするものであって、より精密な測定ツールが自動的に補ってくれるものではないからだ。この2つを分けて見ることで、初めて的確な対処ができる。成果物のギャップはツールとプロセスで解決し、文脈のギャップはコミュニケーションと文書化で解決するのだ。
実務上、自分のチームの引き継ぎ問題がどちらのギャップに属しているか、どちらを優先して補うべきかをどう判断すればよいのか？
最も直接的な方法は、直近の何回かの引き継ぎ後に発生した手戻りを振り返り、エンジニアが提起した質問がどのタイプに属していたかを見ることだ。もし質問の大半が「この状態はどう見えるべきか？」「この色の正確な16進コードは何か？」「このブレークポイントではどうレイアウトすべきか？」といった、具体的な答えがあり、チェックリスト化できるものであれば、チームは主に成果物のギャップにつまずいていることを意味する。仕様書を補完し、デザイントークンを取り込み、ハッピーパス以外の状態（空、読み込み中、エラー）もデザインしておくことで、通常は明確な改善が見られる。
もし質問がより頻繁に「なぜこれはこのようにされたのか？」「この間隔は意図的なのか、それともなんとなく決めたのか？」といったものであったり、あるいはさらに見えにくい状況——エンジニアが仕様通りに作り上げたのに、デザイナーが完成品を見て「この感じじゃない」と感じたりする場合、これらは仕様の一行として正確に書き込むことができない問題であり、チームが文脈のギャップにつまずいていることを意味する。この場合、検討すべきなのは仕様書が十分詳細かどうかではなく、引き継ぎのタイミングが遅すぎないかどうかだ。もしエンジニアがデザインが「完成」してから初めてそれを目にしたのであれば、文脈の伝達は最初から断絶していたことになる。解決策は、引き継ぎ文書にもっと言葉を加えることではなく、エンジニアをデザインプロセスにより早い段階から巻き込むことだ。
もしチームがすでにAIプロトタイプ生成ツールを使っているなら、引き継ぎの問題は自動的に解決されたことになるのか？
完全にそうとは言えない。AIプロトタイプ生成ツールは確かに成果物のギャップを大幅に縮小する。生成されたプロトタイプにはすでにインタラクションロジックとコンポーネント構造が組み込まれており、従来の静的なモックアップにテキストの説明を添える方式に比べ、エンジニアが受け取る参照物は実際の動作にはるかに近い。この改善は実質的なものであり、単なる宣伝文句ではない。チームの引き継ぎ問題が主に「仕様が具体的でない」ことに起因していたなら、この種のツールを導入することで通常明確な違いを実感できるだろう。
しかし文脈のギャップは、ツールが変わったからといって自動的に消えるわけではない。プロトタイプはあるインタラクションがどう動作するかを完全に示すことはできても、なぜそう作られたのか、その決定の背後でどんなトレードオフが検討されていたのかを説明することはできない。この部分は依然として、注釈、口頭でのウォークスルー、あるいはエンジニアをより早い段階でデザインの議論に巻き込むことを通じて、人が能動的に補う必要がある。もしチームが「AIプロトタイプツールを使っているのだから、引き継ぎは自然とスムーズになるはずだ」と誤解してしまうと、実はもともと存在していて対処されていなかった文脈のギャップを見落としてしまう可能性がある。成果物のギャップが先に解決されることで、文脈のギャップがかえって目立つようになるだけなのだ。
エンジニアの91%、デザイナーの92%が、デザインの引き継ぎプロセスには改善の余地があると答えている——これはFigmaの「2025年デザイナー現況レポート」の数字だ。これは一部の不満ではなく、業界のほぼ全体が公然と認める痛点である。より具体的な分析では、デザインの引き継ぎが失敗する最も一般的な理由は、エッジケースと状態のバリエーション（読み込み中、エラー、空の状態）に関する文書化の不足であり、チームメンバー間の相互理解と基本的な技術リテラシーだけで、引き継ぎの摩擦を40%削減できるとしている。これらの数字が合わさって示しているのは、見落とされがちなあることだ。引き継ぎがつまずく根本的な理由は、通常ツールが十分に優れていないからではなく、明確に言語化されることのめったにない2つのギャップにあるということだ。
引き継ぎの失敗を分解すると、ほぼすべてが2つのカテゴリーのどちらかに当てはまる。1つ目は「文脈のギャップ」だ。エンジニアは画面がどう見えるかは分かるが、なぜそうデザインされたのかは分からない——なぜここの間隔は特に詰まっていて、あちらは余裕があるのか。なぜあるインタラクションは特定の感触である必要があるのか。データが空のときは何を表示すべきか。この「なぜ」がなければ、エンジニアは妥当な推測でその隙間を埋めるしかなく、その推測は気づかぬうちに元のデザイン意図からずれていく。2つ目は「成果物のギャップ」だ。エンジニアが実際に必要とする具体的な仕様が提供されていない——コンポーネントがそのライフサイクル全体を通じて取りうるすべての状態（デフォルト、読み込み中、エラー、空）、色や間隔のデザイントークン、異なる画面サイズにおけるレスポンシブな挙動ルールなどだ。どちらのギャップも、ビジュアルモックアップが「完成しているように見える」というだけでは埋まらない。
現代の検証ツールは、間隔、タイポグラフィ、色、コンポーネントのプロパティを自動的に取得できるようになっており、これは成果物のギャップの基礎的な部分を解決している。これが「十分に優れたツールがあれば、引き継ぎは自然とスムーズになる」と思われがちな理由の一部でもある。しかし、これらのツールが捉えられないものこそが、通常手戻りの原因となる。インタラクションの挙動（タップ、ホバー、ドラッグ、スクロール時にそれぞれ何が起きるか）、条件ロジック（要素が状態に応じていつ表示・非表示・変化するか）、アニメーションのタイミングと構成、コンテンツルール（文字数の上限、あふれた場合の省略方法）——そして最もよく見落とされるのが、ハッピーパス以外の状態、すなわち空、読み込み中、エラーの状態だ。デザイナーは理想的なケースの画面を磨き上げることに集中し、エンジニアが結局これらの理想的でない状態も構築しなければならないことを忘れがちで、その結果エンジニアは構築の途中でその場しのぎでデザインを考案することになる。
インタラクティブなプロトタイプを生成できたり、コード環境と直接双方向に連携できたりするClaude Designのようなツールは、成果物のギャップという層において実質的な改善をもたらしている。生成されたプロトタイプにはすでにインタラクションロジックとコンポーネント構造が組み込まれており、もはやテキストの説明が添えられた静的な画像ではない。エンジニアが受け取るのは「推測の出発点」ではなく「すでに一度動作したことのある参照物」だ。これにより、純粋にビジュアルなモックアップが従来必然的に残していたギャップが縮まる。
しかし文脈のギャップは別の問題であり、ツール自体が「なぜ」を自動的に生成することはできない。プロトタイプはあるインタラクションがどう動作するかを完全に示すことはできても、なぜその場所の間隔が特に詰まっている必要があるのか、なぜあるアニメーションがその特定のタイミング感を持つ必要があるのかを説明することはできない。こうした決定の背後にある理由は、注釈であれ口頭での説明であれ、依然として人が能動的に補う必要があり、現時点でこれを自動化するものは何もない。言い換えれば、AI生成ツールはプロトタイプ自体を最終製品にはるかに近づけることができるが、「なぜこう作られたのか」をデザイナーに代わって答えることはできない。それは依然として人間の仕事なのだ。
チームが引き継ぎの問題を解決するためにAIプロトタイプ生成ツールの導入を検討しているなら、まずチームの過去の引き継ぎの摩擦が主に成果物のギャップの問題だったのか、それとも文脈のギャップの問題だったのかを明確にする価値がある。もしエンジニアがこれまで具体性の足りない仕様を受け取り、エッジケースを推測せざるを得なかったのであれば、この種のツールは明確で直接的な改善をもたらすだろう。しかし、より一般的な問題が「エンジニアは仕様通りに作ったのに、出来上がったものがデザイナーの意図した感触ではなかった」ということであれば、それは通常文脈のギャップであり、新しいツールだけでは解決しない。本当に必要なのは、引き継ぎの際に決定の背後にある理由をもっと時間をかけて書き留めること、あるいは画面が「完成」してから一括で渡すのではなく、デザインの初期段階からもっと早く引き継ぎの対話を始めることだ。引き継ぎを一度きりのファイル転送として捉えるか、継続的な対話として捉えるか——この心構えの違いこそが、どのツールを選ぶかよりも、引き継ぎがどれだけスムーズに進むかを左右することが多い。