AI コーディングアシスタントに「自分で見直して直して」と促すと、出力の質は上がります。ただし、それがどこまで本当に効くのかは研究上はっきり線が引かれています。結論を先に言うと、自己改善は外部の検証に接地して初めて効く。本稿はこの線を論文で確認し、そこから「Copilot のような事前指示（custom instructions）に何を書くべきか」を導きます。
自己フィードバックで出力は良くなる（ただし条件つき）
まず、自己改善が効くことを示した代表的な研究から。Self-Refine は、同一の LLM が「生成 → 自分でフィードバック → 改善」を反復するだけで出力が良くなることを示しました。
the same LLMs provides feedback for its output and uses it to refine itself, iteratively
（出典 [1]）
uses a single LLM as the generator, refiner, and feedback provider
（出典 [1]）
Reflexion は、重みの更新ではなく言語的なフィードバックでエージェントを強化する枠組みです。
Reflexion agents verbally reflect on task feedback signals
（出典 [2]）
ここまでは「自己改善は効く」という明るい話です。ただし両者に共通するのは、改善が feedback signals（テスト結果や環境からの応答など）に支えられている点です。ここが次の落とし穴につながります。
落とし穴：外部フィードバックなしの自己修正は当てにならない
「自分で見直す」だけ、つまり外部の手がかり無しでモデルが自力で直す形を、Huang ら（ICLR 2024）は intrinsic self-correction として切り出して検証しました。
an LLM attempts to correct its initial responses based solely on its inherent capabilities, without the crutch of external feedback
（出典 [3]）
そして推論タスクでの結論はこうです。
LLMs struggle to self-correct their responses without external feedback, and at times, their performance even degrades after self-correction
（出典 [3]）
つまり「もう一度よく見直して」と促すだけでは、モデルは自分の誤りを当てにならない仕方でしか直せず、ときに悪化する。改善を生んでいたのは内省そのものではなく、外部のフィードバックだったわけです。
なぜ検証が鍵か：生成と検証は別物
検証の効き方をさらに掘ると、Let's Verify Step by Step が示唆的です。最終結果だけに正解信号を与える outcome supervision と、各推論ステップに信号を与える process supervision を比較しています。
process supervision, which provides feedback for each intermediate reasoning step
（出典 [4]）
process supervision significantly outperforms outcome supervision
（出典 [4]）
どこに検証信号を置くかで信頼性が変わる。検証は生成のついでに済むものではなく、独立した設計対象だということです。これは「作り手と検品役を分ける（builder ≠ checker）」という運用上の定石に、研究側からの裏付けを与えます。
設計含意：自己改善ループを外部検証に接地させる
ここまでをまとめると、実用での設計指針は次の3点になります。
- ループの合否は外部の検証信号で決める（テスト実行・実データ照合・一次情報）。モデルの自己採点だけを完了条件にしない。
- 検品役を作り手から分ける。可能なら別モデル・別スレッドに回す。
- 検証を実行できない場（チャットだけのアシスタント等）では、人間が検証を回す前提を明記し、「確認していないものを確認済みと言わせない」。
3 は特に重要です。コードを実行できないアシスタントに自己検証ループを丸ごと真似させると、Huang らの言う intrinsic self-correction の過信に陥り、モデルが脳内で「テストは通るはず」と緑を偽装します。だから「実行が要る検証は人間が回す」と線を引いておく必要があります。
Copilot に「事前指示」として持たせる
幸い、この規律はツール固有の機能ではなく、事前指示（custom instructions）として書けます。GitHub Copilot のリポジトリ カスタム命令は、保存すると毎回のリクエストへ自動的に添えられます。
Instructions are automatically added to requests that you submit to Copilot
（出典 [5]）
Microsoft 365 側も、宣言的エージェントに指示・アクション・知識を与えて Copilot を仕立てる設計です。
you provide the instructions, actions, and knowledge to tailor Copilot for your business scenarios
（出典 [6]）
つまり「完成と言う前に、外部検証に接地して敵対的に検品せよ」「実行が要る検証は人間が回せ」という規律を、これらの指示欄に常駐させればよい。研究が示した落とし穴（外部フィードバックなしの自己修正への過信）を、運用側であらかじめ回避できます。
まとめ
- 自己改善は効く（Self-Refine / Reflexion）。ただし feedback に支えられている。
- 外部フィードバックなしの自己修正は当てにならず、悪化することもある（Huang ら, 2024）。
- 検証は生成と別物で、信号をどこに置くかが信頼性を決める（Let's Verify Step by Step）。
- だから実用では、自己改善ループを外部検証に接地し、検品役を分け、検証できない場では人間が回す前提を事前指示に書く。これが Copilot に「自分で検品して直す」質を持たせる勘所です。
出典
本稿の引用はすべて一次資料と逐語照合（verify_article 通過）のうえ掲載しています（2026-07-23 検証）。
[1] https://arxiv.org/abs/2303.17651
[2] https://arxiv.org/abs/2303.11366
[3] https://arxiv.org/abs/2310.01798
[4] https://arxiv.org/abs/2305.20050
[5] https://docs.github.com/en/copilot/how-tos/configure-custom-instructions/add-repository-instructions
[6] https://learn.microsoft.com/en-us/microsoft-365-copilot/extensibility/overview-declarative-agent