実行の仕組み

すべてのリクエストは同じステップで実行され、チャットには各ステップがリアルタイムのタイマー付きで表示されます。［停止］を選択すると、いつでも実行を終了できます。実行中だったステップはスキップとして表示されます。

ステップ

ステップ	内容
計画	高速なモデルが3～5項目の短い計画を書きます。リクエストが曖昧すぎる場合は代わりに質問し、残りのステップはスキップされます。 下書きについての質問にはチャットで回答し、作るものがないリクエストにはその旨を伝えます。
構築	選択したモデルが画面のコードを書きます。届いた部分から順にキャンバスに描かれます。
チェック	下書きを非表示のサンドボックス化されたフレームでレンダリングし、実際に動作することを確認します。
レビュー	幅1280、768、375ピクセルで、アクセシビリティ（WCAG 2.2のAとAA）と、ページが横にスクロールしないかをチェックします。スマートフォンの幅では、タップ領域もチェックします。カラーテーマを使う下書きは、ダークモードでのコントラストもチェックします。
修復	レビューで問題が見つかった場合、モデルが1回でまとめて修正します。チェックに失敗した場合は、修復が先にそのエラーを修正します。
下書き完成	新しいバージョンがキャンバスに表示されます。

詳細を読む

補足のあるステップには［詳細］リンクがあります。レビューの詳細には、見つかった問題が1つずつ表示されます。問題がなかった場合は、その旨とチェックした幅が表示されます。修復の詳細には、修正した内容とまだ未解決の内容が表示されます。

取り消し線が引かれたステップはスキップされています。たとえば、レビューで何も見つからなかった場合は修復がスキップされ、Vibrが質問した場合は計画以降のすべてのステップがスキップされます。 Vibrが下書きについての質問に回答した場合や、作るものがないと判断した場合も同様です。

修復ですべてを修正できない場合

修復では、修正後の下書きが引き続きレンダリングされる場合にのみ、その修正を採用します。修正によって何かが壊れた場合、Vibrはレビュー済みの下書きを維持し、その旨を表示します。未解決の項目は修復の詳細に表示されるため、次のリクエストで依頼するか、フィードバックとしてピン留めできます。

バックアップモデル

各モデルには、同じプロバイダーのバックアップモデルがあります。選択したモデルが混み合っている、応答開始が遅い、割り当て上限に達したといった場合は、そのステップをバックアップモデルが引き継ぎ、ステップにその旨が表示されます。例：「gemini-3.5-flashが割り当て上限に達したため、gemini-3.7-flashが引き継ぎました。」サーバーエラーの場合も、実行が失敗する前に何度か再試行されます。

両方のモデルが割り当て上限に達した場合や、アカウントのクレジットが不足している場合は、対処方法を示すメッセージとともに実行が停止します。トラブルシューティングをご覧ください。

所要時間

各カードのステップのタイマーと下部の合計時間で、どこに時間がかかったかがわかります。通常、計画は数秒、構築が最も長く、チェックとレビューはそれぞれ数秒です。