プロトタイプ債とは何か、一般的に言われる「プロトタイプがまだ十分に完成度が高くない」こととはどう違うのか？
プロトタイプ債とは、「このプロトタイプはまだ洗練されていない」といった表面的な問題を指すのではなく、蓄積的で見えないコストを指す。視覚的な成果物を素早く出すために、十分な文脈のないまま下された設計上の決定は、短期的には「とにかく何かを作り出す」というニーズを満たすが、これらの決定が互いに調整されていないため、後になってこれらの画面を修正・拡張・統合する必要が出てきたときに、理解し整理するための追加時間という負担になる。
これは「洗練度が足りない」とは別の次元の問題だ。プロトタイプは視覚的に洗練されていても、重いプロトタイプ債を背負っていることがある（例えば、各画面がそれぞれ独自にログインロジックを処理し、互いに異なっている場合）。逆に視覚的には粗くても、プロトタイプ債がほとんどない場合もある（一連の画面全体が同じコンポーネントと命名ロジックを共有していれば、見た目が簡素でも後で拡張しやすい）。プロトタイプ債が注目しているのは「これらの設計上の決定が互いに調整されているか」であり、「その画面の見た目が良いかどうか」ではない。
なぜプロトタイプ債はAI生成ツールが普及した後に特に顕著になったのか？
核心的な理由は、「完成しているように見える」画面を生成するのに必要な時間が大幅に圧縮された一方で、「この画面が他の画面と調整されていることを確認する」のに必要な時間はそれに応じて圧縮されていないことにある。従来の手作業によるデザインプロセスでは、デザイナーが20番目の画面を描く頃には、通常システム全体に対する心的モデル（このコンポーネントをどこで使ったか、このインタラクションパターンが他の場所でどう扱われていたか）が自然と築かれている。なぜなら、各画面を描くこと自体に十分な時間がかかり、その積み重ねが自然に起きるからだ。
AI生成ツールは「1つの画面を描く」時間をほぼゼロにまで圧縮するが、ツール自体は通常、20番目の画面を生成する際に前の19画面が似た状況をどう処理していたかを遡って確認することを求められておらず、またその能力もない——ユーザーが能動的にデザインシステムや既存のルールを参照として与えない限りは。これは、生成速度が向上する一方で、「調整を保つ」ために必要な労力がそれに応じてツールに自動的に吸収されるわけではなく、むしろ見落とされやすい隠れたタスクとなり、後に保守を担当する人の肩にのしかかることを意味する。
蓄積したプロトタイプ債は、実際どのような具体的な姿として現れるのか？
エンジニアリング側の技術的負債に見られる典型的な進化パターンを参考にすると、プロトタイプ債の蓄積には認識可能な時系列がある。初期（プロトタイプ生成直後）はすべて問題ないように見える。画面はクリックでき、プレゼンにも使え、ステークホルダーの反応も好意的だ。中期（一見小さく見える機能を修正・拡張し始める段階）で最初のシグナルが現れる。ちょっとした調整だと思っていたものが、実は同じ機能の背後に微妙に異なる複数の実装方法が、異なる画面に分散して存在していることが判明する。なぜなら、新しい画面を生成するたびに、以前すでに確立されたルールを再利用するのではなく、ロジックを一から推測し直しているからだ。後期になり、これが放置されると、この不一致はあるパターンへと拡大する。新機能の実装に予想をはるかに超える時間がかかるようになる。なぜなら、変更のたびに、「ここで変更する必要があるロジックと、他の3箇所にある似ているが完全には一致しないロジックのうち、どちらが正しいのか」をまず突き止めるのに時間がかかるからだ。
具体的な兆候としては、同じインタラクションパターン（ドロップダウンメニュー、フォームのバリデーションメッセージなど）が画面ごとに少しずつ異なって見えること、同じデータが画面ごとに異なる名前で扱われていること、新しくチームに加わった人が「この画面のロジックは何を根拠に決められたのか」と尋ねたときに「よく分からない、当時生成されたものだ」という答えが返ってくることなどが挙げられる。
ユーザーとして、今作っているプロトタイプが、プロトタイプ債への対処に追加の時間を割く価値があるかどうかをどう判断すればよいのか？
最も重要な判断基準は、この一連のプロトタイプが今後どう使われるかだ。目的がコンセプトの検証、一度限りのユーザーインタビュー、あるいは一度限りの提案プレゼンであり、使い終われば破棄するか丸ごと作り直す予定であれば、プロトタイプ債はほとんど気にする必要がない。これはまさにAI生成ツールが最も得意とし、最も採算の取れる使用シナリオであり、デザインシステムを統一するために余分な時間を割くことはむしろ無駄になる。なぜなら、この一連のプロトタイプはそもそも長期的に保守される予定がないからだ。
しかし、この一連のプロトタイプが、今後継続的に機能を積み重ねていく製品の種になる可能性がある場合（例えば社内検証を通過した後すぐにエンジニアリングに引き渡す予定である、あるいは開発チームに実装の根拠として渡す準備をしている場合）、数量がまだ少ない早い段階で、生成プロセスにデザインシステム、少なくとも共有のコンポーネントルールが取り込まれているかを確認する時間を割く価値がある。そうすれば、その後の生成のたびに、すでに確定しているルールを参照でき、毎回一から推測し直す必要がなくなる。判断の分かれ目は「このプロトタイプがどれだけ本格的に見えるか」ではなく、「今後誰かがこの上に何かを構築し続けるかどうか」である。
「プロトタイプ債」（prototype debt）とは、素早く視覚的な成果物を出すというプレッシャーの下で、文脈の乏しいテンプレート的なデザインを作った際に生じる下流コストを指す言葉だ。短期的には目の前のニーズを満たすが、後になってデザインチームやエンジニアリングチームに一連の疑問と手戻りという見えないコストを残す。この言葉自体はまだ広く定着しているわけではないが、それが描写する現象は、AI生成ツールが普及した後に特に顕著になった。完成しているように見える画面を生成するのにわずか10分しかかからないとき、「とりあえず作ってしまおう」という誘惑は、「作る前にきちんと考えよう」という規律を容易に上回る。そしてその代償はすぐには現れず、蓄積された後にまとめて噴出する。
この概念は本質的に、「技術的負債」（technical debt）のデザイン版の対応物である。技術的負債という言葉は1992年にWard Cunninghamによって作られ、Wikipediaの項目自体がこれを「デザイン負債」の同義語として挙げている。これは、短期的な開発速度を得るために便宜的な解決策を選び、その代償として将来の保守コストが高くなる可能性がある現象を指す。プロトタイプ債もまったく同じロジックに従うが、それがコードのレベルではなくデザイン上の決定のレベルで起きている点が異なる。
「AI生成プロトタイプの下流コスト」だけを対象にした大規模な定量研究はまだ存在しないが、同じ現象がエンジニアリング側では確かなデータとして存在しており、そのロジックは密接に対応している。810万件のプルリクエストを分析した大規模研究によると、チームがAIコーディングツールを採用した後、技術的負債は30%から41%増加した。GitClearによる2億行を超えるコードの分析では、重複したロジックの割合が2021年の8.3%から2024年の12.3%へと増加している。この期間はまさにAIコーディングツールが主流になり始めた時期と重なる。これらの数字が定量化しているのはコードレベルの現象だが、その根底にあるメカニズム——即座に使えることを目的に生成されたコンテンツが、それ以前に生成されたものと調整されていない——は、プロトタイプ債がデザイン側で描写している現象と同一のものであり、単に別の形で現れているに過ぎない。
エンジニアリング側の技術的負債で見られる時系列パターンを参考にすると、この種のコストは通常すぐには現れない。生成したばかりのプロトタイプは完成しているように見え、クリックして動き、プレゼンに使うにも十分な出来だ——短期的には何の問題もない。摩擦が現れ始めるのは通常、一見小さく見える何かを変更する必要が出てきた最初の瞬間だ。例えばフォームのフローを調整しようとして、実はそのフローが3つの別々の画面によってそれぞれ処理されており、しかもロジックが微妙に食い違っていることに気づく。なぜなら、AIが新しい画面を生成するたびに、その時のプロンプトからロジックを一から推測し直しており、以前に似たようなものをすでに生成していたことを認識していないからだ。エンジニアリング側の対応する現象は「同じバリデーション関数が3つのファイルにそれぞれ微妙に異なる形で存在する」ことであり、デザイン側の対応する現象は「同じインタラクションパターンが、異なる画面で3通りの微妙に異なる形で実装されている」ことだ。
プロトタイプ債が早期に発見されにくい根本的な理由は、その初期段階が効率向上とまったく同じように見える点にある。納品が速くなり、生産量が増えているように見える。本当の違いが現れるのは、その後の保守・拡張段階になってからだ。チームが素早く生成された一連の画面の上に新機能を積み重ねようとしたとき、各画面の背後にある前提、命名ロジック、インタラクションルールが互いに一致していないことに気づく。こうした不一致を解消するのにかかる時間は、そもそも最初から従来の方法でゼロからデザインすることで節約できたはずの時間を、容易に上回ってしまう可能性がある。これが、プロトタイプ債が能動的に探しに行かなければならないものであり、自ら知らせてくれるものではない理由でもある。10番目の画面を生成しているとき、自分が未来の自分に請求書を積み重ねていることに気づく人は誰もいない。
AIデザインツールを使って大量のプロトタイプ画面を素早く生成している場合、実務上使える自己チェック方法の一つは、プロジェクトがある程度の規模に達した時点で立ち止まり、それらの画面が実際に一貫した命名ロジックとインタラクションルールを共有しているかを見直すことだ。各画面が個別に生成され、使えそうに見えればそれでよしとするのではなく。もしそのプロトタイプが、コンセプトを検証し、一度限りのユーザーテストを行い、その後は破棄される予定のものであれば、プロトタイプ債はほとんど気にする必要がない——これはまさにAI生成ツールが最も適したシナリオだ。しかし、この一連のプロトタイプが、今後機能を積み重ねていく本格的な製品の種になる可能性があるなら、早い段階でデザインシステム、少なくとも共有のコンポーネントルールを生成プロセスに取り込むために、少し余分な時間を割く価値がある。この早期の時間投資は、通常、後になって不一致を解きほぐすために払う手戻りのコストよりはるかに安い。