プラットフォーム
本格的なAIソフトウェアデリバリーのためのライブプレビュー
アプリケーションは構築中、チャットの隣でライブに動作します — 実際のフロー、実際のクリック — そしてプレビューリンクにより、何かが出荷される前にステークホルダーがそれを見られます。
ライブプレビューは、Ciao Builderでチャットの隣にある動作中のアプリケーションです: AIが構築する間、本物のアプリが更新され、本物のクリックに応答します。何を得たかを発見するためにデプロイするツールとは異なり、ライブプレビューはすべての変更が届いた瞬間にそれを示し、inspect-to-promptのターゲティングを動かし、共有可能なプレビューリンクを生成するため、ステークホルダーは公開前に実際のアプリをレビューできます。
公開日 2026-07-03 · 最終更新 2026-07-03
決して目隠しで構築しない
ソフトウェアデリバリーにおける最も古い失敗モードは距離です: リクエストとデモの間に数週間が経過し、結果は初日に30秒で気づけたであろう方法で間違っています。AIはタイムラインを圧縮しますが、目隠しを悪化させる可能性もあります — コードは今や誰も読めるより速く現れ、間違った想定は機械の速度で積み重なります。
Ciaoはその距離をゼロに縮めます。アプリケーションは構築中、チャットの隣でライブに動作します。モックアップでもスクリーンショットでもなく、本物のデータ構造の上の本物のアプリが、本物のクリックに応答します。何かがおかしいとき、コンテキストがまだ新鮮で修正がプロンプト一つ分の距離にある間に、今それを見ます。
プレビューはまた、Builderの他の習慣の錨でもあります: inspect-to-promptはそれを共有参照フレームとして使い、キューに入れられたプロンプトは届いたときにそれに対してレビューされ、フルスタックコンソールは表面下で何が起こっているかを説明します。
ライブプレビューの仕組み
最初のプロンプトから公開まで、プレビューは定数です — 判断が下される間、誰もが見ているものです。
1. 説明すると、それが現れるのを見る
Builderが作業する間、会話の隣のプレビューペインでアプリが形になります。進捗は約束ではなく可視化されます。
2. 実際のフローをクリックして進む
サインイン、レコードの作成、検索の実行、フォームの送信。プレビューは動作するアプリケーションなので、テストは構築が始まった瞬間に始まります。
3. 次に変更するものを指し示す
ライブプレビューはinspect-to-promptを動かします: 動作中のアプリ内の任意の要素をクリックし、次のプロンプトでそれを参照します。
4. プレビューリンクを共有する
何かが公開される前に、動作中のアプリへのリンクをステークホルダーに送ります。フィードバックはスライドではなく、本物のものに対して届きます。
5. ゲートを通過する
公開時、QAはまず決定論的なブラウザリプレイとスモークゲートを実行し、その後本番チェックを行います — プレビューは、ゲートが欠陥を捉える前に、意図の問題を捉える場所です。
6. 意図的に公開する
プレビューと本番は別です。あなたが出荷することを選ぶまで、ユーザーには何も届きません。
なぜ重要なのか
フィードバックのコストがビルドの品質を決定します。変更を見ることがデプロイサイクルのコストになるとき、人々は疑いをバッチ処理し、問題を遅く発見します。それが一目のコストになるとき、まだ修正が安価なうちに、すべての想定がチェックされます。ライブプレビューは検証のコストをほぼゼロに縮めます。
それはまた、ステークホルダーレビューを会議からリンクに変えます。クライアント、経営陣、エンドユーザーは、ローンチの数日前に動作中のアプリに反応します — まさに彼らの意見がまだ行動を起こせるうちに、安価な段階です。
利便性の中にガバナンスの利点も隠れています: 人々は実際に見た、動いているものを承認します。ライブアプリケーションに対する承認は、ローンチ日の驚きが少なく、誰かが後で誰がこれをレビューしたのか尋ねたときのより明確な説明責任を意味します。
誰がライブプレビューを使うのか
ライブプレビューはプラットフォームの中で最も専門特化していない機能です — アプリに利害関係を持つすべての人がそれを使うことになります:
- 創業者 — 感触を想像する代わりに、リアルタイムで動作中のアプリに対して製品の判断を検証します。
- 代理店 — プロジェクトの途中でクライアントにプレビューリンクを送ります — 驚きの少ない発表、より速い承認、落ち着いたローンチ。
- プロダクトマネージャー — 公開前にステークホルダーに実際のアプリケーションをデモし、彼らの反応をプロンプトキューに折り込みます。
- 運用チーム — ツールを使う人々に、それが出荷される前にクリックして試してもらいます。
セキュリティとガバナンスに関する注記
早く見ることは、緩く出荷することを意味しません:
- ✓ プレビューと本番は別です — 公開は意図的でゲートされたアクションです。
- ✓ プレビューがどれだけ良く見えても、公開前にQAスモークゲートが、公開後に本番チェックが実行されます。
- ✓ プレビューの裏にある変更は、差分とチェックポイントを持つ本物のgitブランチ上に存在します。
- ✓ Guardrailsのポリシーレビューと記録された人によるレビューが、プレビューとマージの間に立ちます。
- ✓ 公開とデプロイは追記専用の監査証跡に記録されます。
デプロイして見る対ライブプレビュー
ワークフローの違いは、プロジェクトの生涯にわたって積み重なります:
| デプロイして見るワークフロー | Ciaoのライブプレビュー | |
|---|---|---|
| 変更を見るまでの時間 | ビルドとデプロイのサイクルの後 | チャットの隣で即座に |
| ステークホルダーのフィードバック | 会議、スクリーンショット、ステージングアクセスのリクエスト | 動作中のアプリへのプレビューリンク |
| 間違った想定のコスト | 誰かがデプロイして気づくまで積み重なる | コンテキストが新鮮なうちに捕捉される |
| 次の変更の指示 | 記憶から説明される | inspect-to-promptで直接指し示される |
| 公開の判断 | 結果を見ることと絡み合っている | 別々で、意図的で、ゲートされている |
よくある質問
ライブプレビューは本物のアプリケーションですか、それともシミュレーションですか?
本物のアプリケーションです。生成されたReact、TypeScript、Supabaseアプリがライブで動作しているため、実際のフローをクリックでき、inspect-to-promptがクリックしたものを本物のコンポーネントに解決できるのです。
ビルド外の人もプレビューを見られますか?
はい — プレビューリンクはまさにそのために作られています。クライアントとステークホルダーは公開前に動作中のアプリをレビューするため、フィードバックはモックアップではなく現実に対して起こります。
プレビュー内の何かが本番環境に影響しますか?
いいえ。プレビューと本番は別で、公開はQAスモークゲートによってゲートされた意図的なステップです。公開するまで、ユーザーには何も見えません。
プレビューと公開の間に何が起こりますか?
変更は記録された人によるレビューとともにGuardrailsのもとでマージされ、QAは公開前に決定論的なブラウザリプレイとスモークゲートを実行し、公開後に本番チェックが実行されます。プレビューは意図を修正する場所であり、ゲートは欠陥が捕捉される場所です。
ライブプレビューは標準のBuilderの一部ですか?
はい — アプリがチャットの隣で動作することがBuilderの仕組みであり、個人のビルダーはクレジットでセルフサーブから始められます。本格的な本番プログラムは年間10,000米ドルからです。