安全で小さな反復のために「変更しない」プロンプトパターンを使う

なぜ小さな変更が他の部分を壊しがちか

「小さな」変更はめったに小さいままで終わりません。ボタンラベルをちょっと変えてほしいと頼むと、ページのレイアウトが崩れたり、フォームのバリデーションが効かなくなったり、チェックアウトの一段が別の挙動をするようになったりします。アプリはつながったシステムです。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」にだけ変えてください。レイアウト、バリデーション、保存動作は変更しないでください。）これは狭く、テスト可能で、安全です。

堅牢なフリーズリストは通常、次の三つの領域をカバーします：

• フロー（ユーザージャーニー）: ユーザーが通るステップと表示される画面。
• UIとUXの詳細: レイアウト、余白、フィールド順、ボタン配置、インタラクション。
• ビジネスルールとデータ挙動: バリデーションルール、価格計算、権限、DB書き込み、APIレスポンス。

このパターンを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以内に出てレイアウトジャンプを起こさない」）なども指定します。

パフォーマンスやセキュリティ要件が重要なら、それも凍結します。書かなければ、モデルが「改善」として追加のリクエストや新しいロギング、認証チェックの変更を行うかもしれません。

短くまとめると：

• フリーズするフロー： Login, Signup, Checkout, Settings（新しいステップ禁止、画面の順序変更禁止）
• フリーズするエッジケース： 戻るボタン、エラーメッセージ、空状態、リフレッシュ挙動
• フリーズするデータ挙動： 何が保存されるか、いつ保存されるか、リロード後にどこに表示されるか
• フリーズするセキュリティ： 権限、認証チェック、レート制限、新しい公開エンドポイント禁止
• フリーズするパフォーマンス： これらのフローで余計なAPI呼び出し禁止、応答時間が現状より悪化しないこと

データフローは1行で具体的に書きます。例：「住所はSaveを押したときのみ保存され、user profileレコードに格納され、ログアウト/ログイン後も持続する。」このレベルの詳細があれば自動保存や新しいフィールド、タイミングの変更を防げます。

UIとUXの詳細をどうフリーズするか

UIドリフトはモデルがスタイルやコンポーネント構造を「きれいにする」ために発生します。対応はビジネスロジックと同じです：同一にしておくべきものを名指しし、許される1つの変更だけを指定します。

見た目の構造を固定します。レイアウト（カラム/行、ヘッダーとフッターの配置）、スペーシングルール（パディング、ギャップ、整列）、コンポーネントの挙動（ホバー、無効時、読み込みスピナー、エラーメッセージ）を明示します。コンポーネントに特定の「感触」があるならそのまま書きます：「ボタンのサイズ、角丸、色は完全に同じであること」。

レスポンシブ挙動も明示的に定義してください。モバイルについて書かなければ、ツールは勝手に改善するかもしれません。気にするブレークポイントとそこでの挙動（スタッキング順、非表示要素、固定バー、タップターゲット）を指定します。

コピーも凍結します。すべてのコピー、ラベル、プレースホルダー、補助テキストは、編集する1つのラベル以外は変更しないよう明示してください。これは意味や表示を密かに書き換えられるのを防ぎます。

短いプロンプト例：

• 同一を保つ：ルート/画面、ナビ順、戻るボタンの挙動
• 同一を保つ：レイアウトグリッド、スペーシング、フォント、色、コンポーネントの状態
• 同一を保つ：唯一変更する文字列以外のすべてのテキストとラベル
• モバイルルール：現状のブレークポイントでの挙動を維持し、他のセクションをリフローしない
• 出力：行ったすべてのUI変更を記述し、触ったファイル/コンポーネントを一覧化

可能ならビフォー/アフターのスクリーンショットを求めてください。スクリーンショットがなければ短い「UI差分」説明（何が動いたか、何がリサイズされたか、何が色変更されたか）を求め、確信を持って承認できるようにします。

ビジネスルールとデータ挙動をどうフリーズするか

ビジネスルールは小さなUI変更が静かに回帰を生む最も簡単な場所の一つです。ラベルの更新が計算、ステータス遷移、または誰がレコードを見られるかを誤って変えることがあります。ルールとデータ挙動は契約として扱ってください。

まず、ドリフトすると困る少数のルールを列挙します。テストのように書いてください：入力、出力、誰が何をできるか。

変えてはいけないルールを明確に書く

「価格は同じにして」と言う代わりに明確にします：

• 価格：正確な式、丸め（切り上げ/切り捨て）、通貨、税/VATの扱い、割引適用タイミング
• 権限：どのロールが作成、編集、削除、承認、返金、エクスポート、機密フィールドの表示をできるか
• ステータス：許可される状態と有効な遷移（何がトリガーになるか）
• 計算：合計、コミッション、クレジット、上限や最小値
• データ書き込み：どのテーブル/レコードが作られるか、何を不変に保つか

解釈の余地をなくすために数値例を1つ入れます。例：「注文小計 $120、割引10%（税前適用）、税8.25% を割引後の金額にかける。期待合計 = (120 - 12) * 1.0825 = $116.91。最終合計でのみ小数第2位に丸め。」

ロールベースの可視性も明確にします。例：「サポート担当は注文ステータスと顧客メールを見られるが、カードの全情報は見られない。返金は管理者のみ可能。」

バリデーションが重要なら、それも凍結します。トリガーとユーザー向けメッセージを具体的に："開始日が終了日より後なら保存をブロックし、'End date must be after start date.' を表示する。文言を変えないでください。"

アプリ外の副作用も忘れないでください。メール、Webhook、外部API呼び出しがあるなら、イベント名、ペイロードのフィールド、タイミング（即時か遅延か）、冪等性（再試行で重複送信しない）を凍結します。

ステップバイステップ：1つの安全な変更要求の作り方

小さな更新をミニ契約のように扱います。パターンは、変更が狭く、その他すべてが明示的にフリーズされているときに最も効果的です。

1. 変更を1つのテスト可能な文で書く。「設定ページにダークモードを有効にするトグルを追加する」はテスト可能。「設定UIを良くする」は不可です。30秒でテストできなければまだ広すぎます。

2. 傷が最も痛い部分をフリーズリストに書く：ユーザーフロー、主要UI要素、ビジネスルール、データ挙動、APIやDBテーブルなど。

3. 受入チェックと簡単なテスト計画を追加します。ここで「私の環境では動く」型の surprises を防ぎます。例：新しいトグルが表示される、既存設定が引き続き保存される、他にページ上の要素が動かない、など。

4. 編集を始める前に、アシスタントに制約を繰り返させてください。何を変え、何を同一に保つかを確認させます。サマリがずれていたら編集を許可する前に修正します。

5. 可能な限り最小の実装を要求します：リファクタなし、名前変更なし、フォーマット調整なし、触るのは必要箇所のみ。あなたは1つの変更を買っているのであって、全面改修を買っているのではありません。

簡単なレビュー用チェックリスト：

• 要求した振る舞いだけが変わったか
• フリーズしたフローと画面は一致しているか
• ビジネスルールとデータ書き込みは変わっていないか
• テスト（または手動ステップ）は通るか
• 「クリーンアップ」コミットが紛れ込んでいないか

Koder.aiでは特に効果的です：フリーズリストをPlanning Modeに貼り、アシスタントに制約をエコーさせてから最小パッチを生成します。

それでもドリフトを招く一般的なミス

ほとんどの「小さな」編集が失敗する理由は同じです：リクエストはゴールを保護するが、振る舞いまでは保護していない。モデルはゴールを達成する新しい方法を取ることで、画面やロジック、データを静かに変えることがあります。

よくある落とし穴は、結果をフリーズすること（「オンボーディングを滑らかに」）や、「すべて同じにして」とだけ書いて、システムが何を同じにすべきかを理解していると仮定することです。

最もよく起きるミス：

• 抽象的に書く：意図は守るが、クリック単位のフローや期待結果は守らない
• エッジケースを見落とす：空状態、読み込み、バリデーションエラー、権限エラー、オフライン挙動
• 変更を束ねる：2つ3つの変更を同時に頼むとトレードオフが発生しやすく、回帰を見つけにくい
• 「同一」の定義をしない：同じUIレイアウト、同じAPI呼び出し、同じDB書き込み、同じメール/通知、同じ分析イベントを意味するのかを明示しない
• 感覚で承認する：見た目が「問題なさそう」だけで主要パスを検証しない

小さな例：ボタンを目立たせてほしいと頼み、色は凍結したが無効状態を凍結し忘れたとします。結果としてボタンが常に有効になってしまい、後で気づくと重大な挙動変更になっているかもしれません。

役立つ対策は、何が動かせないかを具体的に書くことです。受け入れる前に簡単な回帰テストを行いましょう：

• メインフローをエンドツーエンドで実行する（フリーズしたもの）
• 少なくとも1つのエラー状態と1つの空状態を発生させる
• 権限（管理者と一般ユーザー）をチェックする
• 副作用を確認する：作成/更新されたレコード、送信された通知、ログ/メトリクスが変わらないか

これらが変わっていたら、リクエストにフリーズすべき項目が欠けていたというサインであり、単なる「間違ったコーディング」ではありません。

例：ワークフローを変えずに小さなUI修正を行う

よくある安全な反復は、ワークフローを変えられない小さなUI磨きです。

シナリオ：創業者が短いフォーム（Name, Email, Company size）と、そのフォームを送信してダッシュボードに遷移するプライマリボタンがある単純なサインアップ画面を持っています。

正確な変更要求（一文）：「プライマリボタンの文言を 'Create account' から 'Continue' に変更し、'Company size' フィールドをフリーテキスト入力からドロップダウンに変えてください。」

このパターンを当てはめて、何を同一に保つかをフリーズします：

• フローフリーズ：送信は引き続きアカウントを作成し、同じバリデーションメッセージを出し、同じ次画面に遷移する。
• UIフリーズ：ページのレイアウト、スペーシング、色、ボタンの位置は変えない。
• データフリーズ：バックエンドのペイロードキーと型を変えない。保存されるCompany sizeのフォーマットも以前と同じにする。
• ビジネスルールフリーズ：必須フィールドは必須のまま、フォームがバリッドになるまでボタンは無効のままにする。
• 分析フリーズ：送信時とバリデーションエラー時に送られるトラッキングイベント名は同じままにする。

数分で行える受入チェック：

• ボタンの文言があらゆる状態で “Continue” になっている（デフォルト、ロード中、無効時）
• Company size がドロップダウンになり、以前と同じデフォルトを持つ
• 送信後にダッシュボードに到達し、アカウントが作成される
• 既存ユーザーがプロフィール編集時に保存された Company size を正しく見る
• サインアップ周りのテストや警告が新規に増えていない

良いアシスタントの応答は、フリーズ項目の再記述、あいまい点の確認（例：ドロップダウンの選択肢と保存される値の正確な仕様）、そして最小限の変更のみを行ったこと（ルーティング、バリデーションロジック、ペイロード形状には触れていないこと）を明示するべきです。

承認前の簡単チェックリスト

「小さな変更」を受け入れる前に、サイレントなドリフトを探すための簡易チェックを行ってください。目標は完全なQAではなく、あなたが「変更するな」と言った箇所が想定通り同じままであることを確認することです。

5つの速いチェック（10分）

同じ順序で実行してください。手順を決めるとレビューが落ち着き、回帰が見つけやすくなります。

• クリティカルフローがエンドツーエンドで完了するか： 実際のユーザーが使う入口（ログイン、ランディング、ダッシュボード）から始めて主要タスクを完了する。
• UIは意図した変更以外同一か： フリーズした主要画面を開き、レイアウト、ボタンラベル、スペーシング、ナビを確認する。
• ビジネスルールは現実と一致するか： よく壊れるケースを2〜3個スポットチェックする（割引計算、権限、ステータストランジション等）。
• データ形状は変わっていないか： 新しいフィールド、名前変更、削除、マイグレーションがないか確認する。
• 統合は触られていないか： エンドポイントの変更やペイロード変更（フィールド名、必須フィールド、ステータスコード）がないか確かめる。

ロールバックして再依頼するべきとき

フリーズした項目が何か変更されていたらロールバックしてください。アプリが「動く」場合でも、ラベルが変わったり、新しいフィールドが増えたり、ルールが微妙に変わっているなら、それはモデルが余計な権限を行使したサインです。

プロンプトを再依頼するときは、より厳密に書きます：1文で変更を繰り返し、フリーズすべきフローと画面を名前で列挙し、「スキーマ変更禁止、エンドポイント変更禁止、X以外の振る舞い変更禁止」と付け加えます。Koder.aiを使っている場合は、テスト前にスナップショットを取っておけば不具合発生時に戻すのが簡単です。

次のステップ：Koder.aiで安全な反復を実践する

Koder.aiで構築するなら、このパターンを習慣にしてください：1つの小さな変更、その他をロック、そして何かずれたら戻る方法を用意することです。

まず短い計画フェーズを行う

変更要求の前にPlanning Modeに切り替え、アシスタントにスコープを要約させてください。アシスタントに2つを繰り返させます：（1）正確な変更、（2）フリーズリスト（フロー、UI詳細、ビジネスルール）。

効果的な計画用プロンプト例：「私の要求を繰り返してください。次に、変更してはいけない項目を一覧にしてください。あいまいな点があれば、編集前に質問してください。」

各反復をスナップショットで保護する

すべての変更リクエストをチェックポイント扱いにします。変更を適用する前にスナップショットを取り、検証後にもう一つ取れば、ずれがあればロールバックが速いです。

例えばReact画面でボタンラベルを変えるなら、変更は小さく見えてもスペーシングを崩したり、レンダリングを誘発したり、テストを壊したりする可能性があります。スナップショットがあれば比較と復帰が簡単です。

簡単なワークフロー：

• スナップショットを作る：「Before - change button label only」
• 計画パスを実行しフリーズリストを確認する
• 1つの変更を依頼し、差分スタイルの簡単なサマリを求める
• チェックリストで検証（UI、フロー、ルール、データ）
• スナップショットを作る：「After - verified」

スタック全体で同じパターンを再利用する

Koder.aiはWeb（React）、バックエンド（Go + PostgreSQL）、モバイル（Flutter）を生成できます。コードは変わってもパターンは同じです。振る舞いを定義する部分を凍結してください。

バックエンドのエンドポイントを変えるなら、リクエスト/レスポンスの形、バリデーション、データ書き込みを凍結します。モバイル画面を変えるならナビ順、フィールドのデフォルト、エラーメッセージを凍結します。DBロジックを変えるなら既存行の意味を保ち、安全なマイグレーションを行ってください。

テンプレートを保存しておき、今日1つの小さな変更を実行して、チェックリストで検証してから受け入れてください。テンプレを使い回して、1回に1つの変更だけ行いましょう。