状態管理とは何ですか？「画面が動いて見える」こととどう違いますか？
多くの人は、画面にアニメーションやトランジション効果があれば、そのプロトタイプは「インタラクティブ」だと考えがちだが、これは実は別の話だ。単なる視覚的なトランジション（ボタンをクリックすると画面がフェードイン・フェードアウトする）は、あらかじめ録画されたパフォーマンスに過ぎず、ユーザーが何をしても再生されるのは同じアニメーションだ。状態管理が扱うのはより根本的な部分で、インターフェースがユーザーがこれまでに何をしたかを「記憶」し、その記憶に基づいて次に何を表示するかを決めることである。
例えば、ショッピングカートアイコンに表示される数字は、ユーザーが商品を追加または削除するたびにリアルタイムで更新される必要があり、この数字の裏には追跡されている状態がある。複数ステップのフォームで、ユーザーが3ステップ目まで入力した状態でブラウザを更新した際、最初の2ステップのデータが残っていれば、状態が適切に保存されていることを意味する。状態管理のないプロトタイプは、本質的には一連の固定画面をスライドショーのように投影しているだけで、製品のように見えても、実際に「操作」することはできない。
なぜプロトタイプに状態管理が必要なのですか？一連の静的な画面だけではだめなのですか？
静的な画面（ローファイプロトタイプ）にはもちろん用途がある。速く、コストも低く、「このフローのステップ順序は妥当か」といった大まかな問いを検証するのに適している。しかしチームがより細かい問い、例えば「ユーザーはどのボタンをすでにクリックしたか分からなくならないか」「フォームの入力ミス時のエラー表示は十分に分かりやすいか」を検証する必要がある場合、その答えはユーザーが操作した瞬間にインターフェースがどう即座に反応するかにかかっており、静的な画面ではまったくシミュレートできない。
より実務的な理由は信頼性だ。実際の状態を持たず、どこをクリックしても同じ固定画像に遷移するプロトタイプをステークホルダーやユーザーテストに使うと、「これは偽物だ」とすぐに見抜かれ、テスト参加者の行動も不自然になる（偽物だと分かれば真剣に操作しなくなる）。真の状態管理を持つプロトタイプは、ユーザーが自分がプロトタイプをテストしていることを忘れさせ、得られるフィードバックが実際の使用状況により近くなる。これが、2026年に複数のAIプロトタイピングツールが「実際のバックエンドロジックに接続できるか」を、画面の見た目の良さだけでなく、成熟度を分ける重要な指標として扱い始めた理由でもある。
AIが生成するプロトタイプにおいて、状態管理は実際どのように実装されるのですか？
従来のフロントエンド開発では、状態管理は通常、エンジニアが手動で判断する必要がある。あるデータを単一コンポーネントのローカル状態に置くか、アプリケーション全体で共有するグローバル状態に置くかを決め、それに対応するフレームワークツールを選んで管理する。AIデザインツールが「意味のある」インタラクティブ性を実現するには、画面を生成すると同時に、その裏側の状態ロジックも一緒に生成する必要がある。例えば「カートに追加」ボタンを押すと、実際に追跡されているカートの数量を更新する必要があり、単にボタンが押されたアニメーション効果を再生するだけでは不十分だ。
さらに進んだやり方は、実際のバックエンドサービスに接続することだ。Figma Makeを例に取ると、このツールはSupabaseと連携しており、ユーザーが「ユーザーがログインしてデータを保存できるようにしたい」と自然言語で説明するだけで、ツールは自動的にバックエンドサポートが必要だと判断し、それまでの仮のデータを実際のPostgresデータベースに置き換え、それまで機能していなかったログインボタンを実際に動作するアカウントシステムに置き換える。これは、状態がもはや「この画面がユーザーのクリックを一時的に記憶している」というフロントエンド上の見せかけではなく、実際に保存され、ページを更新しても消えないデータになったことを意味する。
エンジニアでない立場から、AIプロトタイプの状態管理がきちんとできているかを判断するには、実際にどんな挙動をテストすればよいですか？
最も簡単なテスト方法は「壊してみる」ことだ。フォームを半分入力してから別のタブに切り替え、また戻ってきたときにデータが残っているか。リストの並び順を変更した後にページを更新して、順序が元に戻ってしまわないか。同じプロトタイプを2つのブラウザタブで同時に操作し、片方の変更がもう片方に反映されるか。これらの操作は普段誰も意識してテストしないが、まさにこうしたエッジケースこそが、そのプロトタイプが本当に状態を持っているのか、それとも単に動いて見えるだけの固定画面なのかを直接あぶり出す。
もしユーザーテストやクライアントへのプレゼンでプロトタイプを使う予定なら、事前に5分ほど自分でこうした「壊してみる」テストをしておくことで、本番でのトラブルを避けられる。例えば、クライアントの目の前でページを更新した瞬間、たった今入力したフォームのデータが消えてしまうといった事態は、画面の見た目が洗練されていないことよりもずっと、提案全体への信頼を一気に失わせてしまう。
Figma MakeがSupabaseと連携した後、ユーザーが自然言語で「ユーザーログイン機能を追加して」とプロンプトを入力するだけで、ツールは自動的にバックエンド構築フローをトリガーし、元々の仮のデータを実際のPostgresデータベースに置き換え、メール/パスワードやソーシャルログインといった本物の認証手段を提供する。これにより、以前はクリックすると画面が切り替わるだけだったプロトタイプが、ユーザーが実際にアカウントを登録でき、データが本当に保存される、動作するプロトタイプに変わる。エンジニアが手動でデータベースを接続する必要はない。
利点は、ステークホルダーやユーザーがテスト段階で実際の製品に近い操作体験を得られ、フロー上の問題を早期に発見できる点だ。欠点は、真の状態管理（特に実際のバックエンドへの接続）の実装が、純粋なビジュアルプロトタイプよりも通常多くの時間と計算リソースを要する点で、フローの順序や初期のビジュアル方向性を検証するだけが目的であれば、最初からこのコストを投じる必要はないかもしれない。