プラットフォーム
本格的なAIソフトウェアデリバリーのためのInspect-to-prompt
動作中のアプリ内の任意の要素をクリックして、次のプロンプトでそれを参照します — 変更は、AIが推測したものではなく、あなたが指し示したものに届きます。
Inspect-to-promptは、Ciao Builderの機能で、ライブプレビュー内の任意の要素 — ボタン、テーブル、グラフ、フォームフィールド — をクリックし、次のプロンプトで直接それを参照できます。言葉でUIを説明し、AIが自分と同じようにカードを数えることを期待するのとは異なり、inspect-to-promptはターゲットを明確にするため、編集は選択されたコンポーネントに範囲づけられ、小さくレビュー可能な差分になります。
公開日 2026-07-03 · 最終更新 2026-07-03
失敗したプロンプトのほとんどは、悪いアイデアではなく悪い住所だ
「3枚目のカードを小さくして」は、AIがあなたと違うカードを数えるまでは機能します。ユーザーインターフェースを言葉で説明することは損失の多い作業です: あなたの「ヘッダー」、モデルの「ヘッダー」、コードの「ヘッダー」は3つの異なるものかもしれません。曖昧さが入り、間違った編集が出てきて、あなたは次の3つのプロンプトを、一度も言及していない要素へのダメージを元に戻すために費やします。
Inspect-to-promptは、この住所の問題を取り除きます。アプリは構築中、チャットの隣でライブに動作します。そのプレビュー内の任意の要素をクリックすると、それが次のプロンプトで参照されます。Builderはあなたが何を意味するか正確に知っています — 数える必要も、説明する必要も、用語の交渉も不要です。
これは小さなインタラクションですが、影響は甚大です。Builderは、まさに指し示しが可能になるように会話と動作中のアプリケーションをペアにします — プレビューはデモパネルではなく、あなたとAIの間で共有される参照フレームです。
Inspect-to-promptの仕組み
このループは数秒で完了し、ランディングページを仕上げる創業者にも、管理画面のテーブルを調整するエンジニアにも同じです。
1. ライブプレビューを開く
アプリケーションは、構築中に会話の隣で動作します — 本物のコンポーネント、本物のデータ構造、本物のクリックです。
2. 意図する要素をクリックする
ボタン、テーブルの列、グラフ、フォームフィールド、迷子のラベル。選択は、スクリーンショットではなく動作中のアプリに対して機能します。
3. それが次のプロンプトの一部になる
選択された要素は、プロンプトで直接参照されるため、Builderはそれをコード内の正確なコンポーネントに解決します。
4. 平易な言葉で変更を説明する
「これをドロップダウンにして」「これをサマリーの上に移動して」「これは管理者にのみ表示すべき」。何をするかは自然なままで、どこにするかはすでに解決済みです。
5. 編集は範囲づけられて届く
変更は選択されたコンポーネントを対象とし、投機的な書き換えではなく、本物のgitブランチ上の小さな差分を生み出します。
6. その場で検証する
プレビューはチャットの隣で更新されます。まだ正しくなければ、再度クリックしてください — undoとチェックポイントが反復を安価にします。
なぜ重要なのか
精度は積み重なります。編集が指し示した場所に届くと、反復は減り、差分は縮小し、レビューは容易になります — 「選択されたボタンが変わった」ことを確認するレビュアーは、書き換え全体を監査するレビュアーより速く動きます。小さく範囲づけられた変更は、まさにGuardrailsとQAが最も得意とするゲート対象でもあります。
それはまた、誰が作業を指示できるかを広げます。創業者、デザイナー、クライアントは、意味することを言うためにCSSの用語を必要としません — 彼らは動作中のアプリを指し示します。「問題を見る人」と「修正を表現できる人」の間のギャップは、クリック一つに縮まります。
チームはフィードバックラウンドの間にこの違いを最も強く感じます。人々が見ている間にリクエストされた変更が届くレビューコールは、来週のためのチケットリストを生み出すコールとは異なる製品関係です。
誰がinspect-to-promptを使うのか
問題を見ることができる人なら誰でも、今では正確にそれに対応できます:
- 創業者とデザイナー — パディングとマージンの違いを学ぶことなく、指し示すことでインターフェースを仕上げます。
- 代理店 — 「あれをそこに動かして」というクライアントフィードバックを、レビューコールの後ではなく最中に、正確な編集に変えます。
- プロダクトマネージャー — ステークホルダーが不満を持った正確な要素への変更を、チケットの翻訳ロスなしに指示します。
- 開発者 — AIの編集を厳密に範囲づけ、差分を小さく、レビューを速く保ちます。
セキュリティとガバナンスに関する注記
精度はルールを緩めません — 指し示された変更も、入力された変更と同じゲートを通過します。
- ✓ 範囲づけられた編集は、本物のgitブランチ上の小さくレビュー可能な差分を生み出します。
- ✓ 指し示されたものであれ入力されたものであれ、すべての変更はマージ前にGuardrailsのポリシーレビューを通過します。
- ✓ 追記専用の監査証跡が、プロンプトと結果として生じた変更を一緒に記録します。
- ✓ undoとチェックポイントの復元により、どんな誤動作も数秒で回復可能です。
- ✓ ロールベースのアクセス制御が、誰が編集しマージできるかを統制します。
UI変更の説明: 言葉だけ対inspect-to-prompt
この比較は、両方の方法で作業した最初の午後の後、微妙なものではなくなります。
| 言葉だけ | Inspect-to-prompt | |
|---|---|---|
| ターゲティング | 共有された用語と数え方に依存 | 動作中のアプリで正確な要素をクリック |
| 反復 | 説明が洗練されるまで何度も試行 | 少ない — 参照が明確 |
| 副作用 | 編集が似た要素に届く可能性 | 選択されたコンポーネントに範囲づけられる |
| 差分のサイズ | しばしばリクエストより大きい | 小さく1つの要素に紐づく |
| 誰が作業を指示できるか | UI用語に堪能な人 | 問題を指し示せる人なら誰でも |
よくある質問
inspect-to-promptはアプリのどの部分でも機能しますか?
動作中のインターフェース全体で要素を選択できます — ボタン、テーブル、グラフ、フォーム、ラベル。ライブプレビューが画像ではなく本物のアプリケーションだからです。選択は、生成されたReactとTypeScriptコード内の実際のコンポーネントに解決されます。
使うためにコードを理解する必要がありますか?
いいえ。要素を指し示し、平易な言葉で変更を説明します。Builderが選択された要素からコード内のコンポーネントへのマッピングを扱い、差分は読みたい人のためにそこにあります。
一度に多くの要素に影響する変更はどうですか?
プロンプトでパターンを説明してください — 「このスタイルをすべてのサマリーカードに適用して」— あるいはプロンプトキューで範囲づけられた変更のシーケンスをキューに入れてください。Inspect-to-promptは精度のためのものであり、広範な変更を望むときにそれを妨げません。
何が選択され変更されたかの記録はありますか?
はい。各変更はgitブランチ上の差分であり、追記専用の監査証跡がプロンプト、マージ、デプロイを記録します。レビュアーは何がリクエストされ、正確に何が変わったかを確認できます。
inspect-to-promptはセルフサーブプランに含まれていますか?
はい — Builderのコア機能であり、個人のビルダーはクレジットでセルフサーブから始められます。本格的な本番プログラムは年間10,000米ドルからです。