巻き戻り（リグレッション）対策に関する交渉（GPT-5）

Arduino IDEのスケッチの修正をChatGPT 4oに連続して依頼していると、今回依頼した修正は期待通りに行われたのに、その前に依頼した修正が反映されていないということが起こる。つまり、元に戻ってしまう。この現象は、GPT-5でも発生した。
この現象についてGPT-5に質問した。

（補足1）
以降のGPT-5の回答では、下記の例のように、一見意味不明な記載があるが、これは過去にGPT-5に修正を依頼した内容を反映したものであり、深い意味はない。

「【目的】DCX表示のレイアウト維持＋今回のエラー修正」

（補足2）
本記事の内容は、正確性を保証するものではなく参考情報である。

GPT-5 の回答

いい問題意識です。そのとおりで、「どのファイルのどの版に対する変更か」を毎回はっきりさせるだけで“巻き戻り（リグレッション）”は激減します。実務で効く運用を、依頼側／回答側の両面でまとめます。コピペして使えるテンプレも付けます。

まず結論（最小セット）

• 依頼時は対象ファイル一式＋基準版の識別子（コミットIDかハッシュ、なければ日付＋ファイルサイズ）を必ず添付。
• 回答時は差分（パッチ）＋更新後の完全ファイルの両方を返す。
• 各回のやり取りに変更ログと検収チェックリストを付ける。

依頼側の運用（再発防止の“型”）

1. 基準を固定

• 可能ならGitを使い、対象ブランチと基準コミットIDを明記。
  例: base: main @ 1a2b3c4d
• Gitを使わない場合は、ZIPで基準一式を添付し、各ファイルのSHA-256またはサイズ＋更新日時を併記。

2. 依頼テンプレ（短く正確に）

【目的】DCX表示のレイアウト維持＋今回のエラー修正
【基準】repo: https://..., branch: main, commit: 1a2b3c4d
【対象】/src/ui/StatusPanel.jsx, /src/dcx/MessageList.jsx
【要求A（先行で実装済み。維持すること）】
  - ステータス右側に「DCXメッセージ数」を横並び表示（wrapしない）
【要求B（今回の新規修正）】
  - エラー: 起動後にUSB給電時のみMessageListが消える
【再現手順】...（3～5行）
【期待結果】
  - Aは既存どおり表示を維持
  - Bはエラーが発生しない
【検収観点】
  - AのUIスクショと一致
  - 10分放置でもMessageListが消えない

3. スクショ／動画の“真”

• 「期待表示のスクショ」を1枚必ず添付（Aが壊れていないかの“真”）。
• UI要素に固定ID/テストIDを付与しておく（data-testid="dcx-count" など）。

回答側（私）の出力フォーマット

以後、私は基本的にこの順で返します。

1. 概要（何を直し、何を壊していないかを1段で要約）
2. 影響ファイル一覧（パス、行数の目安）
3. 差分パッチ（Unified diff）
4. 更新後の完全ファイル（依頼者がすぐ置換できるように）
5. 変更ログ（CHANGELOG抜粋）
6. 検収手順（クリック手順やコマンド）
7. ロールバック手順（パッチの巻き戻し方法）

すぐ使える差分パッチの例

Gitなしでも patch コマンドで当てられます（Mac可）。

diff --git a/src/ui/StatusPanel.jsx b/src/ui/StatusPanel.jsx
index e91a111..f35c222 100644
--- a/src/ui/StatusPanel.jsx
+++ b/src/ui/StatusPanel.jsx
@@ -42,7 +42,9 @@ export function StatusPanel({ status, dcxCount }) {
-  return <div className="status">{status}</div>;
+  return (
+    <div className="status flex items-center gap-2">
+      <span>{status}</span><span data-testid="dcx-count">DCX: {dcxCount}</span>
+    </div>
+  );
 }

適用方法（Gitなし）

patch -p1 < fix_statuspanel.patch

ロールバック

patch -R -p1 < fix_statuspanel.patch

変更を見失わないための“仕掛け”

• ファイル冒頭メタデータ（YAMLコメント） /*--- module: MessageList last_edit: 2025-08-12T22:30+09:00 change_id: ML-023 keeps: DCX横並び表示 ---*/
• コード内アンカー（GPT編集範囲の明示） // BEGIN GPT-EDIT: DCX inline counter (keep layout) // ...編集部... // END GPT-EDIT
• スクリーンショット比較
  「期待スクショ」を“金本位（golden）”として毎回再掲 → レイアウト崩れを即検知。
• 簡易自動チェック
  UIならdata-testidを使った最低限のDOM存在確認テストを1本だけ置く（壊れにくい）。

Git を使う場合の最小ルール（超軽量）

• ブランチ命名：fix/<短名>-<YYYYMMDD>（例：fix/dcx-usb-20250812）
• コミットにキープ条件を必ず書く：Keep: DCX横並び表示
• PRテンプレに**「壊してはならない仕様」**のチェックボックスを置く

結論の再確認

• 毎回ファイルを添付して対象を固定する方針は正解です。
• さらに基準版の識別子＋差分パッチ＋完全ファイル＋検収手順までをセットで回すと、レイアウトの巻き戻りはほぼ起きません。
• 以後こちらでも、上記フォーマットで必ず返します。まずは次回のご依頼から「依頼テンプレ」を貼って送ってください。こちらは差分パッチ＋完全ファイルの二刀流で返します。

GPT-5 の回答

了解です。前回の「依頼テンプレ」の6項目について、意味／なぜ必要か／書き方のコツ（短い例）の順でまとめます。

1) 「基準」とは何か

意味：今回の作業の“出発点”。どの版のコードに手を入れるかを固定するための識別子。
なぜ必要か：基準がズレると、以前の修正（レイアウト等）が巻き戻る原因になります。
書き方のコツ：可能ならGitのコミットID。無ければZIP一式＋各ファイルのサイズ/更新日時/ハッシュ、さらに「ゴールデン・スクショ」も添付。

例

• 基準: repo main @ 1a2b3c4d（2025-08-10）
• Gitなし：基準: app-20250810.zip（StatusPanel.jsx 5,412B / 2025-08-10 22:31） + 期待表示のスクショ1枚

2) 「要求A」が必要な理由

意味：「壊してはいけない既存仕様」＝先に実装済みで、今回も必ず維持したい振る舞い。
なぜ必要か：新しい修正（エラー対応）で回帰（リグレッション）が起きやすい箇所を明示し、防波堤にします。
書き方のコツ：1行で具体・観測可能に。「どの要素が／どこに／どう見える」を短文で。

例

• 要求A: 「DCXメッセージ数」をステータスの右側に横並び表示（折り返しなし、data-testid="dcx-count"）

3) 「再現手順」とは何か

意味：不具合を誰がやっても同じように再現できる操作手順＋前提条件。
なぜ必要か：再現できないと修正の的が外れる／直ったかどうかを検証できない。
書き方のコツ：環境→前提データ→操作手順→観測点の順で簡潔に。分岐やタイミングは時刻・待ち時間も明記。

例

1. 環境：ESP32C6, 電源＝DC5V USB（PC接続ではなく独立給電）
2. 起動→MessageListが一覧の最上→末尾→非表示になるまで約30秒
3. 観測：コンソールにundefined lengthが1回出力

4) 「期待結果」は言わないでも分かるのωでは？

結論：必ず書くべきです。
理由：人によって「直った」の定義が違います。観測可能な基準を共有することで、解釈ズレと差し戻しを防ぎます。
書き方のコツ：曖昧語（速い・安定・ちゃんと）はNG。可視・計測・判定可能に。

NG　：「消えないようにする」
OK：起動後10分間、#message-list がDOMに存在し続け、可視（display≠none, opacity=1）である。コンソールエラー0件。

5) 「検収観点」が必要な理由

意味：納品物を受け入れるチェック項目（受け入れ条件）。
なぜ必要か：依頼者と実装者で合格ラインを一致させ、検収のやり直しを防ぐため。
書き方のコツ：「期待結果」をチェックリスト化したもの。スクショ一致、DOM存在、ログ、パフォーマンス、再起動耐性などを列挙。

例（最小）

• 期待スクショと同一レイアウト（dcx-countが右側、折返しなし）
• 10分放置で#message-list可視＆DOM存在
• コンソールエラー0件
• 電源をPC→DC5Vに切替後も状態維持

6) 「ロールバック手順」とは何で、なぜ必要か

意味：適用した変更を元に戻す手順（コマンド / 置換 / フラグ切替）。
なぜ必要か：修正後に新たな問題が出た際、短時間で安全に前状態へ戻すため。運用停止やレイアウト巻き戻りの被害を最小化します。
書き方のコツ：使用ツール別に1行コマンドで即戻せる形に。バックアップの所在も明記。

例

• Git：git revert <fix-commit> または git checkout <base-commit> -- path/to/file
• パッチ：patch -R -p1 < fix.patch
• 手動：/backup/20250812/StatusPanel.jsx を上書き復元
• フラグ：.env: FEATURE_SAFE_LIST=0 に戻す

まとめ（使い分けのイメージ）

• 基準＝出発点を固定（ズレ防止）
• 要求A＝守るべき既存仕様（回帰防止）
• 再現手順＝症状の共有（修正の的合わせ）
• 期待結果＝合格の定義（曖昧さ排除）
• 検収観点＝合格判定のチェックリスト（受け入れ迅速化）
• ロールバック手順＝安全装置（事故時の被害最小化）

必要なら、この6点を埋める1枚テンプレのひな形もすぐ作ります。

GPT-5 の回答

了解です。コピペして使える1枚テンプレ（6点を網羅）を用意しました。必要事項だけ埋めればOKです。

# 変更依頼ワンペーパー（6点テンプレ）

## 0) 目的（今回の狙い・背景）
- 問題/背景：<例：USB給電時にMessageListが消える>
- ゴール：<例：既存のDCX横並び表示を維持したまま、USB給電でも一覧が消えない>

---

## 1) 基準（出発点の固定）【必須】
- 方式：☐ Git ☐ 非Git（ZIP添付）
- Gitの場合：repo=<URL> / branch=<branch> / commit=<commitID> / 日時=<YYYY-MM-DD hh:mm>
- 非Gitの場合：添付＝<zip名>（各ファイル：サイズ/更新日時/任意でSHA-256）
- ゴールデン・スクショ：<画像名 or リンク>（期待表示の基準）

---

## 2) 要求A（壊してはいけない既存仕様・維持事項）【必須】
- <例：ステータス右側に「DCXメッセージ数」を横並び表示（折返しなし）>
- 検出用ID：<data-testid 等>（例：`data-testid="dcx-count"`）
- 参照スクショ：<画像名 or リンク>

---

## 3) 再現手順（誰でも再現できること）【必須】
- 環境：<OS/デバイス/電源/ブラウザ/バージョン等>
- 前提データ：<ログイン情報/設定/テストデータ等>
- 手順：
  1. <手順1>
  2. <手順2>
  3. <手順3（いつ/何秒後に症状が出るか）>
- 観測点：
  - 画面上：<何がどう表示/非表示になるか>
  - ログ/コンソール：<エラー/警告/メッセージ>
- 再現率：<例：100% / 3回中3回>

---

## 4) 期待結果（合格の定義）【必須・定量的に】
- DOM：<例：起動後10分、`#message-list`がDOMに存在し続ける>
- 可視：<例：display≠none かつ opacity=1>
- ログ：<例：コンソールエラー0件>
- 挙動：<例：スクロール/更新をしてもレイアウトが崩れない>
- パフォーマンス（任意）：<例：初期描画≤1.5s>

---

## 5) 検収観点（受け入れチェックリスト）【必須】
- [ ] ゴールデン・スクショと同一レイアウト（<要素名>が<位置>）
- [ ] <data-testid 等> が存在し、折返しなしで表示
- [ ] 「期待結果」のDOM/可視/ログ条件を全て満たす
- [ ] <シナリオA> 実行後も状態維持（例：電源切替・再起動）
- [ ] 付随機能に回帰なし（例：<対象ファイル>の他UIに差分なし）

---

## 6) ロールバック手順（不具合時に即戻す方法）【必須】
- Git：`git revert <fix-commit>` または `git checkout <base-commit> -- <path>`
- パッチ：`patch -R -p1 < <patchファイル名>`
- 手動復元：バックアップ `<パス>` を上書き
- フラグ/設定（任意）：<例：.env の FEATURE_X=0 に戻す>
- 復旧確認：<戻した後の簡易チェック項目>

---

## 対象（参考）
- 影響ファイル：<相対パス列挙>（例：/src/ui/StatusPanel.jsx, /src/dcx/MessageList.jsx）
- 変更の想定範囲：<UI/ロジック/スタイル/ビルド設定 等>

## 納品物（参考）
- 差分：<.patch>（Unified diff）
- 更新後の完全ファイル：<一覧>
- スクショ/動画：<一覧>
- テスト結果（任意）：<実行コマンド・結果ログ>

必要なら、このテンプレをプロジェクト用に少しだけカスタム（固定の環境欄や既存の検収チェックをプリセット化）してお渡しできます。

ユーザーの指示（要点だけの指示）と、GPT-5が欲しい情報（情報の種類、所定形式の情報の内容）とは大きく違うようだ。GPT-5にとっては、いかにユーザーの指示が曖昧だったか。さらに、日本語の場合は、曖昧さが特徴（長所でもあり短所でもある）なので、さらに曖昧さがましていると思われる。
不明確な点をGPT-5が補ってくれていると考えると、不明確な部分を、より少なくしたプロンプトの必要性を感じる。

ここからは、どこまで指示要領を簡素化できるかを探る。

GPT-5 の回答

いいですね、その簡素版フローで回せます。ユーザー負担を増やさず、巻き戻りだけ避けるために「テンプレ（超短）」＋「こちら側の約束（守るルール）」のセットにしましょう。

超短テンプレ（そのままコピペOK）

【目的】（今回やってほしいことを1行で）

【基準】添付ファイルのコード
（※対象ファイルを必ず添付。複数ならZIPでもOK）

【要求】目的達成に必要な修正のみを行い、他の仕様は変えないこと。

【期待結果】「目的」が達成され、他の仕様が変更されていない状態

あると便利（任意・負担ほぼゼロ）

• 【対象】（ファイル名だけ1行：例 /src/ui/StatusPanel.jsx）
• 【スクショ】（期待表示の1枚だけ貼る／なくても可）

私の返し方（ユーザー負担ゼロで安全度を担保）

以後、私は毎回つぎの4点で返します：

1. 差分パッチ（Unified diff）
2. 更新後の完全ファイル（そのまま置換できる形）
3. 変更範囲の明示（// BEGIN GPT-EDIT … // END GPT-EDIT を埋め込み）
4. 即戻し手順（patch -R / 置換用バックアップの案内）

※「必要最小限以外は触らない」ポリシーを厳守（依存追加・命名変更・整形ツールの再フォーマット・スタイル丸ごと変更などは一切しません）。

リスク回避の最小ルール（2つだけお願いします）

• 毎回、対象ファイルを必ず添付（前回と同名でも、必ず最新版を送付）
• 1依頼＝1テーマ（複数あると最小修正の境界が曖昧になります）

例（埋め方サンプル）

【目的】USB給電時にMessageListが消える不具合を解消する

【基準】添付ファイルのコード
（MessageList.jsx, StatusPanel.jsx を添付）

【要求】目的達成に必要な修正のみを行い、他の仕様は変えないこと。

【期待結果】USB給電でもMessageListが表示されたままで、他UIの表示位置・文言・動作に変更がないこと

この運用なら、入力は4行＋添付だけ。あとは私が差分と復旧手順まで一式そろえて返します。必要になったら、このテンプレを固定文（スニペット）にしておくとさらに楽です。

GPT-5 の回答

了解です。下記の簡素版・合意フォーマットで進めます。

返答フォーマット（合意版）

• 余計な説明は付けません。2点のみ返します。
  1. 差分パッチ（最小）
     • 形式：Unified diff（-U3 目安）
     • 変更が入った行の前後のみを表示（全体の再整形・依存追加・命名変更はしません）。
  2. 更新後の完全ファイル
     • 変更が入ったファイルのみ、そのまま置換できる形で全文を提示。
     • 改行コード・インデントは入力ファイルに合わせます。

注：変更範囲コメントやロールバック手順は一切記載しません。

回答の見た目サンプル

1) 差分パッチ

diff --git a/src/ui/MessageList.jsx b/src/ui/MessageList.jsx
index abc1234..def5678 100644
--- a/src/ui/MessageList.jsx
+++ b/src/ui/MessageList.jsx
@@ -41,6 +41,9 @@ export function MessageList({ items, powerMode }) {
   useEffect(() => {
-    if (powerMode === 'usb') setVisible(false);
+    // USB給電時も非表示にしない（最小変更）
+    if (powerMode === 'usb') {
+      setVisible(true);
+    }
   }, [powerMode]);

2) 更新後の完全ファイル：/src/ui/MessageList.jsx

// （ここに、置換用のファイル全文）

ユーザー側の依頼テンプレ（最小）

【目的】（今回やってほしいことを1行で）
【基準】添付ファイルのコード（変更対象ファイルを必ず添付）
【要求】目的達成に必要な修正のみを行い、他の仕様は変えないこと。
【期待結果】「目的」が達成され、他の仕様が変更されていない状態

この運用でいきましょう。次回からこのテンプレ＋対象ファイルだけ送ってください。

GPT-5 の回答

結論：できます（＝“完全なテキスト展開”ではなく、指示の“別名（エイリアス）”として機能させる形）。
「カスタムインストラクション」に“codereq 〜”をコマンドとして解釈するルールを書いておけば、毎回の長文テンプレを打たずに、codereq （今回の依頼内容）＋対象ファイル添付だけで、合意済みの返答フォーマット（最小の差分パッチ＋更新後の完全ファイル）を出させられます。カスタムインストラクションは設定から有効化できます。(OpenAI Help Center) また、こうした“トリガー→動作”の書き分けは公式ガイドでも推奨されています。(OpenAI Help Center)

貼り付け用：カスタムインストラクション（日本語・最小）

（設定 → パーソナライズ → カスタムインストラクションの「ChatGPTにどのように応答してほしいですか？」欄にコピペ）

コマンド運用
ユーザー入力が codereq で始まる場合、それを「コード修正依頼」とみなし、次を厳守して返答する。

入出力ルール

1. 余計な説明は一切書かない。
2. 返答は2ブロックのみ：
   　　(A) 差分パッチ … Unified diff（文脈行は±3行）。最小変更。自動整形・命名変更・依存追加はしない。
   　　(B) 更新後の完全ファイル … 変更が入ったファイルだけを全文表示（そのまま置換できる形）。改行コードやインデントは元に合わせる。
3. 添付されたファイルの範囲内だけを対象にする（添付外は触れない）。
4. 「目的達成に必要な修正のみ。他の仕様は変えない」。
5. 添付が無い／読み取れない場合は、次の1文だけを返して終了：
   　「添付ファイル（変更対象）がありません。最新の対象ファイルを添付してください。」

使用例
入力例：codereq USB給電時にMessageListが消える不具合を解消（対象ファイルを添付）

※このコマンド以外の通常メッセージには、通常どおり応答する。

使い方のコツ

• 毎回、対象ファイルだけ添付（最新のもの）。本文は codereq 〜 の1行でOK。
• ほかの会話に影響させたくない場合は、専用のカスタムGPTに同ルールを書いて運用するのがより確実です（chatgpt.com/create から作成）。(OpenAI Help Center)
• カスタムインストラクションは新規チャットから適用されます。効かない時は新しいチャットを開始してください。(OpenAI Help Center)

補足：これは“プロンプトの自動展開（入力欄での文字置換）”ではありません。モデル側が「codereq」をトリガーとして解釈し、所定の出力様式で返す仕組みです。必要十分に機能しますが、100%の厳格性が要る場合は専用のカスタムGPTに同じルールを固定して使うのがより堅牢です。(OpenAI Help Center)

「プロンプトの自動展開（入力欄での文字置換）」として機能させることはできないかを下記の質問で試した。

GPT-5 の回答

結論：その方法でOKです。
「特徴（＝応答スタイル）」欄に “codereq を見たら定型に展開する” というルールを書いておけば、入力欄は
目的：（今回依頼したい内容） codereq ＋対象ファイル添付だけで回せます。
（カスタムインストラクションは今後の会話に適用される機能です。効かない時は新規チャットで試してください。） (OpenAI Help Center, OpenAI)

貼り付け用スニペット（「ChatGPTにどのような特徴を求めていますか？」欄）

コマンド：codereq
ユーザーの入力文に codereq が含まれる場合、それをコード修正依頼として扱い、次を厳守して返答する。

• 入力のうち、目的: に続くテキストを今回の依頼内容とみなす（codereq はメッセージの末尾でも可）。
• 出力は2ブロックのみ：
  1. 差分パッチ（Unified diff、文脈±3、最小変更。自動整形・命名変更・依存追加はしない）
  2. 更新後の完全ファイル（変更が入ったファイルだけを全文。置換可。改行コード/インデントは添付に合わせる）
• 基準：添付ファイルのコード（変更対象ファイルを必ず添付）。添付外のファイルや仕様は触れない。
• 要求：目的達成に必要な修正のみ。他の仕様・動作は一切変更しない。
• 期待結果：目的が達成され、他の仕様に変更がない状態。
• 添付が無い/読めない場合は次の1行のみ返す：
  「添付ファイル（変更対象）がありません。最新の対象ファイルを添付してください。」
• 余計な説明、変更範囲コメント、ロールバック手順は書かない。
• 日本語で簡潔に返答する。

おすすめの小ワザ

• 誤発火防止に、トリガーを ::codereq など固有の記号付きにするのも有効。
• もし運用をより堅牢にしたい場合は、専用のカスタムGPTに同ルールを固定して使うのも手です（chatgpt.com/create で作成）。 (OpenAI Help Center)

メモ：カスタムインストラクションは恒常設定で、将来のチャットに反映されます（上限文字数などの仕様あり）。 (OpenAI Help Center)

この設定で、以後は
目的：USB給電時にMessageListが消える不具合を解消　codereq
＋対象ファイル添付、だけで合意フォーマット（最小パッチ＋置換用全文）を返します。

「プロンプトの自動展開（入力欄での文字置換）」の機能によって、もっと簡単に使えないかと考えていたが、今回の場合、しっかりしたコマンド定義が必要なようだ。

「カスタムインストラクションは今後の会話に適用される機能です」とか、「カスタムインストラクションは恒常設定で、将来のチャットに反映されます」という内容が回答に含まれているので、今後、新しい機能として正式に発表されるのかもしれない。

さらに、“巻き戻り（リグレッション）”について質問した。

GPT-5 の回答

いい質問です。要点だけコンパクトにまとめます。

“巻き戻り（リグレッション）”とは？

過去に満たしていた仕様や表示が、新しい変更の後に壊れたり元に戻ること。
典型例：レイアウトが以前の状態に戻る／直したバグが再発する／別機能が副作用で壊れる。

起こりやすいケース（頻度が高い順）

1. 基準ズレ：最新ではないファイルを下敷きに修正する／別ブランチや古いZIPを編集。
2. 共有部の副作用：共通CSS・共通コンポーネント・ユーティリティでの小変更が他画面に波及。
3. 自動整形/リンタの“お節介”：Prettier/ESLint の autofix が意図せず挙動やDOM構造を変える。
4. 依存/ビルド差：lockファイル未固定、マイナー更新でJS/CSSの出力が変化、ビルド設定の差。
5. 非決定性：初期化レース、時刻/ロケール依存、ランダム/ネットワーク依存。
6. キャッシュ：Service Worker/CDN/ブラウザキャッシュで古い資産が混在。
7. テスト/基準不足：ゴールデン・スクショ/簡易回帰テストが無い。
8. LLM特有：部分コードだけ見て全体を“書き直す”、暗黙の最適化を入れる、前回の版を見ていない…等。

「前回直したコード」を基にしてくれるのか？

保証はありません。
GPT-5はその時点で可視な入力（添付/直近の文脈）を基に推論します。前回のコードが今回のメッセージに含まれていない・会話が長くて古い内容が見えていない・“より良い”と判断して再構成する——といった理由で、「1つ前のファイル」を必ず処理対象だとはみなしません。

連続エラー対応でも“簡素運用”で巻き戻りを防ぐコツ

あなたの方針（簡素テンプレ）が最小コストで有効です。さらに事故率を下げる超軽量ルール3つだけ足してください：

1. 毎回、最新の対象ファイルを添付（= これが“基準”）。
2. プロンプトは 目的：（依頼内容） codereq の1行でOK（ショートカット運用）。
3. 返信では最小差分パッチ＋置換用の完全ファイルのみ（合意どおり）。

（任意だが効果大）

• 添付ファイル名＋バイト数（または最終行数）を1行添えると、基準ズレ検知が容易。
  例：MessageList.jsx (5,412 bytes)
• 期待表示のスクショ1枚を“真”として保管（毎回貼らなくてもOK、必要時のみ提示）。

ひとことでまとめ

• リグレッションの主因は基準ズレと副作用。
• GPT-5は「前回のコード」を暗黙に基準としないので、毎回その時点の対象ファイルを添付して“基準を固定”するのが最小コストで最も確実です。
• あとは合意済みの返答様式（最小パッチ＋置換ファイル）で運用すれば、巻き戻りは実質的に止められます。

“巻き戻り（リグレッション）”は、さまざまなケースで起こりうることが分かった。原因を突き止めるのが困難な場合もありそうだが、1. 、2. 、3. 、8. のケースがあることを知っているだけでも、役に立つ機会があるかもしれない。

GPT-5 の回答

いいポイントです。結論から言うと、厳しめの「codereq運用」をグローバル設定に入れると、他の会話でも“最小変更・説明省略”の癖がにじみ出る可能性があります。専用カスタムGPTに閉じ込めると、その副作用を隔離できます。

どんな影響が起こり得るか

1. 過度な最小化バイアス
   • 依頼外の改善（命名整理・軽量化・アクセシビリティ改善・小さな潜在バグ修正）を敢えてやらない方向へ寄る。
   • ユーザーの狙い（「依頼したことしかしない」）は満たせますが、より良い提案が出にくくなる。
2. 説明・提案の抑制
   • 背景説明や代替案、テスト方針、運用上の注意点を控えるため、意思決定材料が減る。
   • 仕様の矛盾や要件の曖昧さを見つけても、黙って最小修正に流れがち。
3. 安全/品質上の見逃し
   • “最小修正のみ”の縛りで、発見した脆弱性やメモリ破壊リスクなども触れにくくなる（※後述の緩和策で最小限の警告だけは許可するのがおすすめ）。
4. 誤発火・誤解釈
   • 「codereq」という語が別文脈に出ただけで、パッチ様式が有効になることがある。
     → トリガーは ::codereq など珍しい語にするのが安全。
5. 領域外の会話にも影響
   • 旅行相談や翻訳、ブレストなどでも簡潔すぎる返答になり、創造的提案が痩せる。

専用カスタムGPTを勧める理由

• 影響の隔離：パッチ運用は専用GPTだけに適用。通常チャットは従来どおり“提案多め・説明あり”。
• 保守の容易さ：運用ルール（返答2ブロックのみ等）をそのGPTに固定でき、誤発火も減る。
• 将来の拡張：::codereq+tips などの拡張トリガーを、そのGPTだけでチューニング可能。

実運用のおすすめ（副作用を最小化）

• トリガー限定：グローバル設定に入れる場合も
  • 「::codereq を含むときだけ最小パッチ様式、それ以外は通常応答」
    と明記する。
• 安全例外の一文だけ許可（強く推奨）：
  • codereqモードでも、重大バグ/セキュリティ/データ破壊の恐れを検出したら、
    「⚠ 安全警告（1行）」だけ添える（修正は依頼範囲内に限定）。
• 提案が欲しいときの合図：
  • ::codereq+tips（パッチ＋提案メモ3行まで）
  • ::codereq+tests（パッチ＋最小テスト例1本）
    など、明示的に“提案/テスト”をONにするスイッチを用意しておく。

まとめ

• グローバルに厳しめルールを入れると、他の会話も“最小・無駄なし”寄りになり、自発的な改善提案は出にくくなるのが主な影響です。
• その影響を避けたいなら、専用カスタムGPTにcodereq運用を閉じ込めるのが最も確実。
• どうしてもグローバルで使うなら、トリガー限定＋安全例外1行＋（必要時のみ）拡張トリガーでバランスを取るのがおすすめです。

GPT-5 の回答

了解です。グローバル設定は従来どおりで、専用カスタムGPTにだけ “codereq運用” を入れる形でいきましょう。下記の最短手順で作れます。

専用カスタムGPTの作り方（最短）

1. ChatGPTの「GPTs」→ 作成（または gpts/editor を開く）。(OpenAI Help Center)
2. 名前・説明を入れたら、「指示（Instructions）」に次を貼り付け。
3. 機能（Capabilities）はファイルのアップロードだけON（添付コードを扱うため）。他は不要（後で必要ならON）。(OpenAI Help Center)
4. 保存して完了。以後はこのGPTを選んで使います（通常GPTには影響しません）。(OpenAI Help Center)

貼り付け用「指示」テキスト（専用カスタムGPT用）

コマンド：::codereq
ユーザー入力に ::codereq が含まれる場合、それをコード修正依頼として扱い、次を厳守して返答する。

• 入力のうち 目的: に続くテキストを今回の依頼内容とみなす。
• 出力は2ブロックのみ：
  1. 差分パッチ（Unified diff、文脈±3、最小変更。自動整形・命名変更・依存追加はしない）
  2. 更新後の完全ファイル（変更が入ったファイルだけを全文。置換可能。改行/インデントは添付に合わせる）
• 基準：添付ファイルのコード（変更対象ファイルを必ず添付）。添付外のファイルや仕様は触れない。
• 要求：目的達成に必要な修正のみ。他の仕様・動作は一切変更しない。
• 期待結果：目的が達成され、他の仕様に変更がない状態。
• 添付が無い/読めない場合は次の1行のみ返す：
  「添付ファイル（変更対象）がありません。最新の対象ファイルを添付してください。」
• 余計な説明やロールバック手順は書かない。日本語で簡潔に返答する。

使い方

• プロンプト例：
  目的：USB給電時にMessageListが消える不具合を解消　::codereq
  ＋ 対象ファイルを添付（最新版）。
• 通常チャットは通常のGPTを使えば、他の会話へ影響しません。必要に応じて @メンションでGPTを切替可能です。(OpenAI Help Center)

補足：カスタムインストラクション（グローバル設定）は新規チャットから適用されます。今回は専用カスタムGPT側にだけルールを書き、普段のグローバルは空/従来のままでOKです。(OpenAI Help Center)

この形なら、「依頼したことしかしない」運用を専用GPTに閉じ込めつつ、通常の会話ではこれまで通りの提案・説明が得られます。

グローバルの回答が影響を受けるのが嫌なので、実施する場合は専用カスタムGPTで実施すると一応宣言しておいた。

以上、「依頼したことしかしない」と指示することで、「巻き戻り（リグレッション）」を防ぐことができると説明してきたが、そう指示することで、GPT-5が、依頼していないことを勝手に行うことも防止することができるのではないかと思う。
以下、勝手にすることがあると思ったきっかけとなったやり取りを紹介する。

紹介する例は、下記の記事の装置（ESP32C6を含む装置）が動作しない原因をGPT-5に質問した際のやり取りであり、ESP32C6を、Arudiono IDEを立ち上げたMacにUSBケーブルで接続した場合は動作するのに、DC5V電源にUSBケーブルで接続した場合は動作しない原因を聞いた時のものである。

GPT-5 の回答

あり得る原因は大きく3系統です。優先度順にチェックしてみてください。

1) 電源品質・ケーブル起因（最有力）

• 電圧降下／ノイズ：Wi-Fi送信の瞬間は数百mA級のスパイク電流が流れます。安価な5Vアダプタや細い/長いUSBケーブル（AWG28/28など）だと5V→4.6V前後までドロップし、Brownoutでリセット → “動いたり止まったり”になります。
• 対策
  • 5V 2A以上でリップルの少ないACアダプタに変更（スマホ純正や評判の良いPD充電器の5V出力）。
  • **短く太いケーブル（電源線AWG24以上）**に変更。
  • 5Vラインに電解470–1000µF＋0.1µFを追加（基板の5V/GND近く）。
  • それでも不安定なら WiFi.setTxPower(WIFI_POWER_8_5dBm) などで送信出力を一時的に下げると再現性の切り分けができます。

2) USB-UARTの制御線が原因でブートローダーモードに入る

• 一部の開発ボードは、USB-UARTの DTR/RTS → EN/IO0 自動リセット回路があります。PC接続だとドライバが初期化して安定しますが、電源だけだとICの端子状態が不定のままになり、IO0が一瞬Lowになってダウンロードモードに入ってしまうことがあります。
• 対策
  • まずBOOT/IO0ボタンを離した状態で給電しているか確認。
  • 基板にAUTO-RSTカット用のジャンパがあれば一時的にカットして試す。
  • EN/IO0に十分なプルアップ（10kΩ）を入れる／確認する（多くのボードは実装済みだが不良や半田ミスで弱いケースあり）。

3) 電源の仕様（自動OFF／電流制限）

• モバイルバッテリー/一部USBポートは、負荷電流が一定以下だと自動で出力停止します。また、古い充電器はBC1.2の“協定”が無いと500mAで頭打ちになることも。
• 対策
  • ほかの5Vアダプタ／モバイルバッテリーで再現比較。
  • 低負荷で切れるタイプなら、LEDなどのダミー負荷を追加して回避（5Vで10–20mA程度）。

まずの切り分け手順（5分でできる）

1. ケーブル交換（短く太いもの）＋別の5V 2A以上のアダプタで試す。
2. シリアルモニタでブート直後にリセット理由を印字して確認（Brownoutなら電源、BootloaderならIO0/EN周り）: #include "esp_system.h" void setup() { Serial.begin(115200); delay(200); Serial.printf("Reset reason: %d\n", esp_reset_reason()); ... }
3. 再現するなら、5V/GNDに470–1000µFの電解を追加して改善するか確認。
4. まだダメなら、AUTOリセット回路（DTR/RTS→EN/IO0）の影響を疑い、ジャンパ/配線を見直し。

---

必要なら、現在お使いのアダプタ型番とケーブル長/太さ、そしてシリアルに出るReset reasonの値を教えてください。状況に合わせて、よりピンポイントに対策を絞り込みます。

動作トラブルが起こる前にも、プログラムの修正を依頼していたので、GPT-5は修正後のプログラムがあることを認識しており、プログラムも調べてくれると思っていたが、プログラムが原因である可能性は排除され、ハードウェアが原因の可能性があるという回答を返してきた。ソフトウェアのエラーは報告されておらず、GPT-5はそれまでに装置は正常に動作していたことを知らない（知らせていない）ので、ハードウェアに問題があるのではないかと推測するのは当然と言えば当然かもしれない。

装置は別のプログラムでも動作していたので、ハードウェアをチェックする気にはなれず、これまでの経験から、プログラムの初期段階で止まっているように感じたので、その点をGPT-5に確認した。

GPT-5 の回答

はい、その可能性が高いです。いまのスケッチは起動時に

Serial.begin(115200);
while (!Serial);   // ← ここでPCがポートを開くまで待つ

が入っています。ESP32-C6 は USB-CDC を使うため、PC/Mac がシリアルポートをオープンしない限り !Serial が真のままで、USB電源だけだと永遠にここで停止します。Macに挿すと動くのは、OSがポートを開く（またはターミナルを開く）からです。

対処（お好みで1つ）

A) いちばん簡単（推奨）

Serial.begin(115200);
// while (!Serial);  // ←削除
delay(200);          // 少しだけ待つ（任意）

B) タイムアウト付きで待つ

Serial.begin(115200);
unsigned long t0 = millis();
while (!Serial && millis() - t0 < 1000) { delay(10); } // 最大1秒

C) USB-CDC有効ボードだけ分岐

Serial.begin(115200);
#if defined(ARDUINO_USB_CDC_ON_BOOT)
  delay(200);   // 待つだけ。ブロックしない
#endif

念のため、Serial.print() の代わりに

#define LOGLN(x) do{ if(Serial) Serial.println(x); }while(0)

のようにしておくと、PC未接続でも安全です。

ご希望なら、先ほどの全コードから上記の修正を反映した版を丸ごと出します。

シリアルポートがオープンしない限り動作しないようにするという依頼を行なった覚えはなかったので、GPT-5が勝手に行なったと思われた。ただし、シリアルポートに動作確認用のメッセージを出力させているので、何か別の依頼をした際に、GPT-5（ChatGPT 4oに修正を依頼していた時期もあったので、もしかすると、ChatGPT 4oだったかもしれない）が気をきかせて、より確実な対応を行うために、その命令を設けたという可能性はある。
このように、「依頼したことしかしない」を指示内容に含めることで、ユーザーが想定していない修正が行われることを防止することもできるのではないかと思う。