『その仕事、AIに任せた後は? あなたの脳を整える、焙煎士の診断ガイド』
PR

AIに指示を重ねるのをやめて「前提」を聞き出したら、開発の先祖返りがピタリと止まった話

社会人の勉強

AIにコードを書かせたり、ツールの画面を直してもらったりしているとき、こんな経験はないでしょうか。

せっかく綺麗に整えたフォーマットが、ちょっと次の指示を出した瞬間に、なぜか過去の壊れた失敗作に戻ってしまった

いわゆる「先祖返り(リグレッション)」と呼ばれる現象です。

私自身、ブログ投稿アシスタントや日々の自動化ツールを開発する中で、この先祖返りに何度も悩まされてきました。「さっきのルールを守って」「なんで昔の形に戻すんだ」とプロンプトで強く命令を重ねても、AIはますます混乱し、かえって泥沼にハマっていくばかりでした。

しかし、あるとき「命令するのをやめて、AIが何を見ているのかを聞いてみる」というアプローチに変えたところ、この先祖返りがピタリと止まりました。

AI開発で本当にやるべきだったのは、プロンプトのテクニックをこねることではなく、「AIの判断根拠(前提)をデバッグし、正本ファイルとして基準を固定すること」でした。その現場での気づきと実践法を共有します。


1. なぜAIは「過去の失敗作」に巻き戻してしまうのか?

AIが意図せず古いフォーマットに戻してしまうとき、AIに悪意があるわけでも、サボっているわけでもありません。

原因はいたってシンプルで、「AIが手探りで参照した過去の断片コードを、正解だと誤解しているから」です。

  • コンテキストの変化:
    • 会話が長くなると、過去の細かな指示がそのまま参照されなくなったり、要約や圧縮によってニュアンスが変わったりすることがあります。
  • ワークスペース内の探索:
    • エージェントにファイル検索やコード参照の権限がある場合、指示の根拠を探す過程で、フォルダ内にある過去のスクリプトや試作段階の残骸コードを参照してしまうことがあります。
  • 間違った前提での最適化:
    • 「過去にこういうコードがあるから、この形に合わせよう」とAIが親切心で判断し、結果としてせっかく直した最新のフォーマットを昔の失敗作へ巻き戻してしまうのです。

つまり、人間側がいくら「最新のルールを守れ!」と怒っても、AIが見ている「前提(参照している情報源)」が狂っている限り、どれだけプロンプトを工夫しても解決しません。


2. 怒ってプロンプトをこねる前に、「AIの判断根拠」を聞く

この泥沼から抜け出すために私が始めたのが、「なぜそのコードを選んだのか?」とAIの判断根拠を直接質問することでした。

実際にAIに投げかける問い

  • 「なぜさっきのフォーマットではなく、この形式を採用した?」
  • 「どのファイルやコードを手がかりにしてその判断をした?」
  • 「現在の仕様として、どのルールを適用した?」
  • 「今回の変更で、既存仕様のどこを維持した?」

こうしてAIの前提を聞き出してみると、驚くほど明確な理由が返ってきます。

scripts/ 内にある古いスクリプトを参照したところ、この形式で記述されていたため、それに統一しました」
「直前の会話で言及されたデザイン指示を、過去のレイアウト構造に適用しようと解釈しました」

AIを問い詰めるのではなく、「判断根拠・参照したファイル・適用したルール」を説明させて実際のコード差分と照合することで、どのファイルがAIを迷わせているのか、どこで解釈のズレが起きたのかという原因候補を一瞬で絞り込めるようになります。


3. チャットに頼らず、「正本ファイル」で基準を固定する

AIの誤解ポイントが分かったら、次にやるべきことはプロンプトの修正ではありません。AIが二度と迷わないための「環境とファイルの整備」です。

小規模な個人開発であれば、まず判断の中心となる「正本(System of Record)」を1枚決め、参照基準を固定することから始めます。

私が実践している具体的な対策は以下の3点です。

① 旧コードの退避と流用禁止(環境構造とルールの両面で防ぐ)

AIの設定ファイル(AGENTS.md や指示書)に「過去コードの勝手な検索・コピペ禁止」を明記するだけでなく、不要になった古いコードは archive/ フォルダなどに物理退避して作業対象から切り離します。ルールと物理構造の両面から防ぐほうが安全です。

② 「これが最新の完成形」という正本(マスター)を1枚置く

チャットの会話の中に仕様を書くのをやめ、Markdownファイル(SKILL.md や仕様書)に完成形のフォーマットやCSS、禁止事項をまとめておきます。
AIには「この正本ファイルを参照して作業してほしい」と案内するだけで、セッションが切り替わってもブレない判断基準が維持されます。

③ 決定事項と「なぜそうしたか(理由)」をObsidianに残す

「なぜこのUIを採用し、なぜ別の案をボツにしたのか」という設計の理由をObsidianに短いメモとして蓄積します。
そして、その設計判断をAIが必要なときに参照できる導線(パス)まで作っておくことで、将来機能を追加・改修するときにも、過去の決定を壊さずに安全に拡張できるようになります。


まとめ:AI開発の本質は「命令」ではなく「前提の同期」

AIを使っていて思い通りに動かないとき、私たちはつい「もっと賢いプロンプトを書かなければ」と力づくで操ろうとしてしまいがちです。

しかし、本当に必要だったのは、AIを従わせることではなく、「AIが何を参照し、何を前提にしているのか」に耳を傾けることでした。

  • AIが迷走したら、まず「何を手がかりに判断したか」を聞いてみる。
  • AIを迷わせている古い記憶や残骸ファイルを特定し、環境を整理する。
  • チャットではなく、判断の基準となる正本ファイルに決定事項を固定する。

AIの頭の中を整理して、迷わないための「1枚の地図」を渡してあげること。これこそが、AI開発の先祖返りを防ぎ、真に頼れるパートナーへと育てる一番の近道だと感じています。


タイトルとURLをコピーしました