2025年12月11日·1 分
安全で小さな反復のために「変更しない」プロンプトパターンを使う
主要なUIフロー、ビジネスルール、重要な振る舞いをフリーズして、1つだけ小さな更新を安全に行う「変更しない（do not change）」プロンプトパターンを学びます。
主要なUIフロー、ビジネスルール、重要な振る舞いをフリーズして、1つだけ小さな更新を安全に行う「変更しない（do not change）」プロンプトパターンを学びます。
「小さな」変更はめったに小さいままで終わりません。ボタンラベルをちょっと変えてほしいと頼むと、ページのレイアウトが崩れたり、フォームのバリデーションが効かなくなったり、チェックアウトの一段が別の挙動をするようになったりします。アプリはつながったシステムです。UI、ロジック、データ、統合は互いに依存しています。
よくある原因は境界が曖昧なことです。もしリクエストが「サインアップを簡単にして」とだけ書かれていたら、ビルダー（人でもAIでも）は「簡単にする」とは何かを推測しなければなりません。推測は余計な編集を生みます：フィールドを削る、ステップを変える、コピーを直す、バリデーションを書き換える、などです。別の原因は隠れた依存関係です。小さなUI変更が5つの画面で使われているコンポーネントを再利用すると大きな影響になります。
安全な反復とは、意図した1つの改善だけを得て、それ以外は実質的に同一のままであることを意味します。非技術チームにとっては、ユーザー向けのワークフローが同じに感じられ、サポートスクリプトがプロダクトと整合し、レポートが意味をなすことです。技術チームにとっては、ルート、データ形状、API契約、エッジケースの振る舞いに予期せぬ変更がないことを意味します。
それを可能にするには、動かしてはいけないものをフリーズしなければなりません。実務では通常、クリティカルなフロー（ユーザーがたどる正確なステップ）、UI/UXの詳細（レイアウト、余白、インタラクションの挙動）、ビジネスルール（価格、権限、バリデーション）、データ挙動（いつ何が保存されるか）、および統合（分析イベント、メール、支払い、外部API）を含みます。
この「変更しない（do not change）」プロンプトパターンは、推測を排し、変更のスコープを保つことでリスクを下げます。保証ではありません。元の挙動が不明瞭だったり、共有コンポーネントに触れたり、結果を検証しなければドリフトは起こり得ます。目標は驚きを減らし、承認を速めることです。
このパターンは、1つの特定の更新を求めつつ、その他すべてを明確にロックする簡単な方法です。やってほしい1つの変更を名指しし、その後に更新後も同一でなければならない部分の短いフリーズリストを書きます。
これは重要です。モデルはしばしば親切にリファクタリングしたり、名前を変えたり、ファイルを整理したり、ロジックを「きれいにする」ことに走りがちです。出力が動作しても、余計な変更はバグを招き、振る舞いを変えたり、レビューを難しくしたりします。
比べてみてください：
“Make the settings page better.”（設定ページを良くして）これはデザイン変更、新しいコピー、レイアウトの変更、ロジック調整を招きます。
“Change only the label text from ‘Phone’ to ‘Mobile phone’. Do not change layout, validation, or the save behavior.”（ラベルテキストを「Phone」から「Mobile phone」にだけ変えてください。レイアウト、バリデーション、保存動作は変更しないでください。）これは狭く、テスト可能で、安全です。
堅牢なフリーズリストは通常、次の三つの領域をカバーします：
このパターンをKoder.aiのようなチャットベースのビルドツールで使うと、モデルは1つの編集に集中し、勝手に広範な「改善」を始めないため、反復が速くなりがちです。
このパターンは、リクエストが小さな契約のように読めるときに最も効果的です：1つの明確なゴール、同一であるべき項目のフリーズリスト、そして結果を確認するためのいくつかのチェック。
ブラケットに当てはめてコピーして使ってください。短く、しかし具体的に。
Goal (one sentence):
- Change: [describe the one small change you want]
Context (1-3 sentences):
- Current behavior: [what happens today]
- Desired behavior: [what should happen after]
DO NOT CHANGE (must remain identical):
- Critical flows: [e.g., sign up -\u003e checkout -\u003e receipt stays the same]
- UI/UX that must not move: [e.g., button location, labels, navigation order]
- Business rules: [e.g., pricing, permissions, validation rules]
- Data behavior: [e.g., database schema, stored fields, migration rules]
Constraints (limit drift):
- Scope: [only this screen / only this endpoint / only this component]
- Files/modules (if known): [list a couple, or say “only touch what’s necessary”]
- No refactors: do not rename, reorganize folders, or change formatting beyond the touched lines
Acceptance checks (how I will verify):
1) [a simple before/after check]
2) [a user path that must still work]
3) [a rule that must still hold]
Output requested:
- Provide a brief diff-style summary: what changed, where, and why
- Call out any risk or unclear requirement before implementing
具体例：チェックアウトボタンの色を変えたいなら、「プライマリチェックアウトボタンの色を #1A73E8 に更新する。」というゴールです。DO NOT CHANGE項目にはチェックアウトフロー全体、ボタンテキスト、価格計算をフリーズしておきます。
Koder.aiを使う場合、この形式はレビューを速くします。受け取ったプレビューと変更サマリを受入チェックと照らし合わせて承認できます。
小さな変更を要求するとき、「何も壊すな」とだけ書かないでください。最初のクリックから最終結果まで、同じように振る舞ってほしい正確なユーザージャーニーを名指ししてください。アプリ全体を凍結するわけではなく、回帰が痛い部分だけをフリーズするのです。
まず、重要なフローを箇条書きで列挙します：ログイン（パスワードリセットを含む）、オンボーディング、チェックアウト、設定。各フローについて「完了」の定義を示します。例：「ユーザーはメール＋パスワードでログインでき、ダッシュボードに遷移し、リロード後もサインイン状態が維持される。」
次に、よく忘れられるエッジケースをロックします。戻るボタンの振る舞いはドリフトの古典です：「Checkoutから戻るとCartに戻る（Homeではない）、カート内の商品は残る」。エラー状態（「パスワードが違うと同じメッセージを出す」）、空状態（「プロジェクトがないときのコピーは同じ」）、読み込み状態（「スピナーは200ms以内に出てレイアウトジャンプを起こさない」）なども指定します。
パフォーマンスやセキュリティ要件が重要なら、それも凍結します。書かなければ、モデルが「改善」として追加のリクエストや新しいロギング、認証チェックの変更を行うかもしれません。
短くまとめると：
データフローは1行で具体的に書きます。例：「住所はSaveを押したときのみ保存され、user profileレコードに格納され、ログアウト/ログイン後も持続する。」このレベルの詳細があれば自動保存や新しいフィールド、タイミングの変更を防げます。
UIドリフトはモデルがスタイルやコンポーネント構造を「きれいにする」ために発生します。対応はビジネスロジックと同じです：同一にしておくべきものを名指しし、許される1つの変更だけを指定します。
見た目の構造を固定します。レイアウト（カラム/行、ヘッダーとフッターの配置）、スペーシングルール（パディング、ギャップ、整列）、コンポーネントの挙動（ホバー、無効時、読み込みスピナー、エラーメッセージ）を明示します。コンポーネントに特定の「感触」があるならそのまま書きます：「ボタンのサイズ、角丸、色は完全に同じであること」。
レスポンシブ挙動も明示的に定義してください。モバイルについて書かなければ、ツールは勝手に改善するかもしれません。気にするブレークポイントとそこでの挙動（スタッキング順、非表示要素、固定バー、タップターゲット）を指定します。
コピーも凍結します。すべてのコピー、ラベル、プレースホルダー、補助テキストは、編集する1つのラベル以外は変更しないよう明示してください。これは意味や表示を密かに書き換えられるのを防ぎます。
短いプロンプト例：
可能ならビフォー/アフターのスクリーンショットを求めてください。スクリーンショットがなければ短い「UI差分」説明（何が動いたか、何がリサイズされたか、何が色変更されたか）を求め、確信を持って承認できるようにします。
ビジネスルールは小さなUI変更が静かに回帰を生む最も簡単な場所の一つです。ラベルの更新が計算、ステータス遷移、または誰がレコードを見られるかを誤って変えることがあります。ルールとデータ挙動は契約として扱ってください。
まず、ドリフトすると困る少数のルールを列挙します。テストのように書いてください：入力、出力、誰が何をできるか。
「価格は同じにして」と言う代わりに明確にします：
解釈の余地をなくすために数値例を1つ入れます。例：「注文小計 $120、割引10%（税前適用）、税8.25% を割引後の金額にかける。期待合計 = (120 - 12) * 1.0825 = $116.91。最終合計でのみ小数第2位に丸め。」
ロールベースの可視性も明確にします。例：「サポート担当は注文ステータスと顧客メールを見られるが、カードの全情報は見られない。返金は管理者のみ可能。」
バリデーションが重要なら、それも凍結します。トリガーとユーザー向けメッセージを具体的に："開始日が終了日より後なら保存をブロックし、'End date must be after start date.' を表示する。文言を変えないでください。"
アプリ外の副作用も忘れないでください。メール、Webhook、外部API呼び出しがあるなら、イベント名、ペイロードのフィールド、タイミング（即時か遅延か）、冪等性（再試行で重複送信しない）を凍結します。
小さな更新をミニ契約のように扱います。パターンは、変更が狭く、その他すべてが明示的にフリーズされているときに最も効果的です。
変更を1つのテスト可能な文で書く。「設定ページにダークモードを有効にするトグルを追加する」はテスト可能。「設定UIを良くする」は不可です。30秒でテストできなければまだ広すぎます。
傷が最も痛い部分をフリーズリストに書く：ユーザーフロー、主要UI要素、ビジネスルール、データ挙動、APIやDBテーブルなど。
受入チェックと簡単なテスト計画を追加します。ここで「私の環境では動く」型の surprises を防ぎます。例：新しいトグルが表示される、既存設定が引き続き保存される、他にページ上の要素が動かない、など。
編集を始める前に、アシスタントに制約を繰り返させてください。何を変え、何を同一に保つかを確認させます。サマリがずれていたら編集を許可する前に修正します。
可能な限り最小の実装を要求します：リファクタなし、名前変更なし、フォーマット調整なし、触るのは必要箇所のみ。あなたは1つの変更を買っているのであって、全面改修を買っているのではありません。
簡単なレビュー用チェックリスト：
Koder.aiでは特に効果的です：フリーズリストをPlanning Modeに貼り、アシスタントに制約をエコーさせてから最小パッチを生成します。
ほとんどの「小さな」編集が失敗する理由は同じです：リクエストはゴールを保護するが、振る舞いまでは保護していない。モデルはゴールを達成する新しい方法を取ることで、画面やロジック、データを静かに変えることがあります。
よくある落とし穴は、結果をフリーズすること（「オンボーディングを滑らかに」）や、「すべて同じにして」とだけ書いて、システムが何を同じにすべきかを理解していると仮定することです。
最もよく起きるミス：
小さな例：ボタンを目立たせてほしいと頼み、色は凍結したが無効状態を凍結し忘れたとします。結果としてボタンが常に有効になってしまい、後で気づくと重大な挙動変更になっているかもしれません。
役立つ対策は、何が動かせないかを具体的に書くことです。受け入れる前に簡単な回帰テストを行いましょう：
これらが変わっていたら、リクエストにフリーズすべき項目が欠けていたというサインであり、単なる「間違ったコーディング」ではありません。
よくある安全な反復は、ワークフローを変えられない小さなUI磨きです。
シナリオ：創業者が短いフォーム（Name, Email, Company size）と、そのフォームを送信してダッシュボードに遷移するプライマリボタンがある単純なサインアップ画面を持っています。
正確な変更要求（一文）：「プライマリボタンの文言を 'Create account' から 'Continue' に変更し、'Company size' フィールドをフリーテキスト入力からドロップダウンに変えてください。」
このパターンを当てはめて、何を同一に保つかをフリーズします：
数分で行える受入チェック：
良いアシスタントの応答は、フリーズ項目の再記述、あいまい点の確認（例：ドロップダウンの選択肢と保存される値の正確な仕様）、そして最小限の変更のみを行ったこと（ルーティング、バリデーションロジック、ペイロード形状には触れていないこと）を明示するべきです。
「小さな変更」を受け入れる前に、サイレントなドリフトを探すための簡易チェックを行ってください。目標は完全なQAではなく、あなたが「変更するな」と言った箇所が想定通り同じままであることを確認することです。
同じ順序で実行してください。手順を決めるとレビューが落ち着き、回帰が見つけやすくなります。
フリーズした項目が何か変更されていたらロールバックしてください。アプリが「動く」場合でも、ラベルが変わったり、新しいフィールドが増えたり、ルールが微妙に変わっているなら、それはモデルが余計な権限を行使したサインです。
プロンプトを再依頼するときは、より厳密に書きます：1文で変更を繰り返し、フリーズすべきフローと画面を名前で列挙し、「スキーマ変更禁止、エンドポイント変更禁止、X以外の振る舞い変更禁止」と付け加えます。Koder.aiを使っている場合は、テスト前にスナップショットを取っておけば不具合発生時に戻すのが簡単です。
Koder.aiで構築するなら、このパターンを習慣にしてください：1つの小さな変更、その他をロック、そして何かずれたら戻る方法を用意することです。
変更要求の前にPlanning Modeに切り替え、アシスタントにスコープを要約させてください。アシスタントに2つを繰り返させます：（1）正確な変更、（2）フリーズリスト（フロー、UI詳細、ビジネスルール）。
効果的な計画用プロンプト例：「私の要求を繰り返してください。次に、変更してはいけない項目を一覧にしてください。あいまいな点があれば、編集前に質問してください。」
すべての変更リクエストをチェックポイント扱いにします。変更を適用する前にスナップショットを取り、検証後にもう一つ取れば、ずれがあればロールバックが速いです。
例えばReact画面でボタンラベルを変えるなら、変更は小さく見えてもスペーシングを崩したり、レンダリングを誘発したり、テストを壊したりする可能性があります。スナップショットがあれば比較と復帰が簡単です。
簡単なワークフロー：
Koder.aiはWeb（React）、バックエンド（Go + PostgreSQL）、モバイル（Flutter）を生成できます。コードは変わってもパターンは同じです。振る舞いを定義する部分を凍結してください。
バックエンドのエンドポイントを変えるなら、リクエスト/レスポンスの形、バリデーション、データ書き込みを凍結します。モバイル画面を変えるならナビ順、フィールドのデフォルト、エラーメッセージを凍結します。DBロジックを変えるなら既存行の意味を保ち、安全なマイグレーションを行ってください。
テンプレートを保存しておき、今日1つの小さな変更を実行して、チェックリストで検証してから受け入れてください。テンプレを使い回して、1回に1つの変更だけ行いましょう。
特定の1つの変更を行いたいとき、かつそれ以外は同じままであってほしいときに使います。チェックアウト、認証、請求など、わずかなずれが実際のユーザーに影響するフローで特に有用です。
アプリの各部分はコンポーネント、データ、ルールを共有しています。小さなUI編集が再利用されるコンポーネントに影響し、他の画面でレイアウトが崩れたり、バリデーションやAPIのペイロードが変わってしまうことがあります。
1つの明確なゴールを書き、その後に変更後も同一でなくてはならない項目を列挙することです。重要なのは、単に「壊さないで」と言うのではなく、フロー、ルール、データ、統合など振る舞いそのものをフリーズすることです。
短く具体的に：クリティカルなフロー、動かしてはいけないUI/UXの詳細、ビジネスルール、データ挙動、統合を含めます。何を同じままにするか言えないなら、モデルは推測する必要があり、その推測がずれを生みます。
守るべき範囲を最小限に絞ってください。例えばラベル1つの変更ならチェックアウト全体をフリーズするのではなく、そのラベルが使われる画面と共有コンポーネントだけを凍結します。範囲が広すぎると作業が止まります。
ユーザージャーニーをステップ単位で書き、何が「完了」なのかを定義します。さらに、戻るボタンの挙動、エラーメッセージ、空状態、リフレッシュ挙動などの一般的なエッジケースを追加しておくと、ユーザーが気づく部分が同じままになります。
レイアウト構造、スペーシング、コンポーネント状態（ホバー/無効/読み込み）、および変更する唯一の文字列以外のすべてのコピーを明示的にフリーズしてください。そうしないとモデルがスタイルを“クリーンアップ”して意味やレイアウトが変わることがあります。
契約としてフリーズします：リクエスト/レスポンスの形、バリデーションルール、権限、計算、何がいつ保存されるかを凍結します。価格のようなセンシティブなルールには数値例を1つ入れると解釈の余地がなくなります。
実行可能な受入チェックを要求し、何がどこで変わったかの短い差分サマリを求めてください。凍結したフローをエンドツーエンドで確認し、少なくとも1つのエラー状態を起こし、データや統合が変わっていないことを確かめます。
変更前にスナップショットを取り、計画フェーズでスコープとフリーズリストを繰り返し確認してから最小パッチを適用します。検証後に再度スナップショットを取れば、ずれがあればすぐに戻せます。