よくある失敗

AIが迷うときは、能力不足ではなく、作業条件が見えていないことがあります。まずは材料、目的、置き場所をそろえましょう。

つまずきやすい場面

いきなり全部作らせる

範囲が広すぎると、AIは勝手に前提を作りやすくなります。

直し方: まず構成、次に一部、最後に全体へ進めます。

作る前の条件が薄い

作りたいものや今回はやらないことが曖昧だと、AIが必要以上に広げやすくなります。

直し方: 小さな要件メモを作り、作る範囲と後回しにする範囲を分けます。

作業場所を決めない

元資料、作業中、完成物が混ざると、AIも人間も迷います。

直し方: sources/, notes/, outputs/, logs/ に分けます。

途中結果を見ない

最後まで任せると、方向違いに気づくのが遅くなります。

直し方: 「まず案だけ」「まだ変更しないで」を使います。

エラー文を省略する

「動かない」だけでは、原因候補が広すぎます。

直し方: エラー文、直前の操作、期待した結果を渡します。

戻れる地点を作らない

AIの変更でうまく動かなくなったとき、前の状態が分からないと修正が長引きます。

直し方: 大きな変更の前に、Gitでコミット（保存地点）を作るか、作業記録に変更前の状態を残します。GitHubなど外部へ送る場合は、秘密情報が含まれていないか先に確認します。

同じ修正を続けすぎる

何度も同じ方向で頼むと、時間とAIの利用量が増えていきます。

直し方: 3回直らなければ、原因候補だけ出させるか、動いていた状態へ戻ります。

相談するときに情報を出しすぎる

別のAIや人に相談するとき、エラー解決に不要な個人情報や内部情報まで渡してしまうことがあります。

直し方: 目的、症状、エラー文、変更したファイル、試したことだけを残し、秘密情報は伏せます。

毎回ゼロから説明する

前回の判断や未完了が消えると、同じ確認が増えます。

直し方: 作業記録を残し、「これを読んで続き」と頼みます。

確認せずに完成扱いする

見た目が整っていても、リンク切れや説明不足が残ることがあります。

直し方: 利用範囲に応じた確認の観点を指定します。