AIコーディングの道具を触っていると、便利さは本当に速く伸びます。以前の私は、その勢いのまま「できるなら任せよう」と進めてしまい、あとで止めどころを失って怖くなる場面が何度かありました。最初は小さな違和感でしたが、積み重なると運用全体の不安に変わっていきました。
特に怖かったのは、コード品質そのものより、影響範囲を把握しないまま書き込み権限を渡してしまうことです。差分を見れば直せると思っていても、対象ディレクトリが広いと確認コストが跳ね上がり、結果的に判断が雑になります。
今は、任せる前に「どこまで触ってよいか」「何を絶対に触らせないか」「どこで人が止まるか」を先に固定してから動かすようにしています。今回は、この切り替えで実際に何が変わったかを書きます。
ここで言うガードレールは、AIを縛るための壁ではなく、判断を安定させるための土台です。任せる範囲が明確なほど、むしろAIの強みを安心して使えるようになる、というのが今の実感です。
- AIコーディングで怖いのは、能力不足よりも書き込み範囲と停止条件が曖昧なまま進むことでした。
- 読み取り専用で試す期間を置くと、AIの問題だけでなく自分の監督の穴も見えやすくなります。
- 対象範囲、禁止操作、停止条件を先に固定すると、任せる範囲を広げても確認しやすくなりました。
最初に壊れたのはコードではなく、確認のリズムでした
最初の失敗は、AIが致命的なコードを書いたことではありませんでした。問題は、確認の順番が壊れたことです。変更対象が広いまま実行すると、差分レビューの負荷が急に上がり、「全部は見切れないから大丈夫そうなところだけ見る」という悪い癖が出ます。
私の場合、srcだけ触らせる想定だったのに、補助スクリプトと設定ファイルまで同時に変更され、どの変更が本命でどれが副作用かを切り分けるのに時間がかかりました。結局、修正よりも「何が起きたかを把握する時間」が長くなり、効率が逆転しました。
このとき痛感したのは、レビュー前提の運用を作らずに自動化へ寄ると、実装速度より不安の速度のほうが早くなることです。確認が追いつかない状態で進めても、最後は人が止めるしかなく、チーム全体のテンポが落ちます。
この経験以降、私は「AIの提案精度」より先に「人間が追跡できる変更単位か」を見るようになりました。追跡できない変更は、正しさ以前に運用として不安定だと実感したからです。
読み取り専用で1週間回して、失敗パターンを先に集めた
いきなり書き込みを許可せず、最初は読み取り専用で1週間回しました。ここでやったのは、AIの能力評価ではなく、私の監督の穴を見つける作業です。「どの依頼で曖昧な指示になりやすいか」「どの出力が過信を誘うか」を意識してログを残しました。
実際に見えたのは、私の依頼文が短すぎるときほど、AIが善意で補完しすぎることです。補完自体は有能でも、補完範囲が期待とズレると、あとで「その変更は頼んでいない」が増えます。これはモデルの問題というより、私の設計不足でした。
逆に、入力の前提を3行だけ増やしたタスクでは、提案のズレが明確に減りました。目的、対象範囲、除外条件を最初に与えるだけで、戻り作業が小さくなります。読み取り専用でこの差を比較できたのは大きな収穫でした。
読み取り専用の期間を置いたことで、書き込み前に直すべき指示テンプレートが明確になりました。急いで実行権限を渡すより、先に失敗を小さく採集したほうが、結果として速かったです。
書き込み権限の前に、対象ディレクトリと禁止操作を固定した
書き込みに進むときは、対象範囲を先に固定しました。私が今使っている最小セットは、「許可ディレクトリ」「禁止操作」「停止条件」の3つです。これだけでも、運用の安定度はかなり変わります。
許可ディレクトリは、機能開発ならsrc/features/対象機能のように細く切ります。禁止操作は、削除・一括置換・設定ファイルの横断変更など、復旧コストが高いものを明示します。停止条件は「想定外のファイル変更が1件でも出たら止まる」のように、曖昧さのない文で書きます。
この3点を先に固定すると、レビュー会話が感覚論から条件論に変わります。条件に合っていれば進める、外れていれば止める、と判断の往復が短くなるので、議論がぶれにくくなりました。
ここを文書化してからは、レビュー時の会話が「なんとなく危ない」ではなく「この条件を外れたから止める」に変わりました。止める理由を言語化できると、スピードを落とさずに安全側へ戻せます。
外部操作を切り離したら、むしろ判断が速くなった
以前は「どうせあとで使うから」と外部操作まで同時に許可しがちでしたが、これが迷いの原因でした。ファイル編集と外部反映が同じ経路にあると、ひとつの判断ミスが一気に外へ出ます。私はこの構成をやめ、外部操作は必ず別ステップに分離しました。
分離後は、作業が遅くなると思っていました。実際は逆で、判断は速くなりました。なぜなら、レビュー時に見るべき論点が減るからです。まずはローカル差分だけを確定し、その後に別承認で外部操作を実行する形にしたら、確認の迷いが減りました。
また、失敗が起きたときの切り戻しも簡単になりました。外部反映前なら、差分単位で撤回できます。これが分かっているだけで、AIへの依頼文を少し攻めた内容にしても心理的な負担が小さくなります。
「一気に終わらせる」より「判断を分割する」ほうが、私の運用には合っていました。AIに任せる量を増やすほど、この分割の価値は大きくなると感じています。
失敗した日ほど、ログを残す運用が効いた
うまくいった日の記録だけ残すと、次に失敗したときに再現性が落ちます。私は、失敗した日のほうこそ「何を依頼したか」「どこでズレたか」「どの条件で止めたか」を短く残すようにしました。
このログを見返すと、同じ種類のミスが繰り返される場所が見えます。例えば、範囲指定が曖昧なタスク、依存関係が多いタスク、差分が大きくなりやすいタスクは、最初から監督密度を上げるべきだと分かりました。
ログを残す目的は反省会ではなく、次の判断を速くすることです。ルールが現場に合っていれば、失敗は運用改善の入力に変わります。ここを仕組みにすると、怖さが少しずつ管理可能なものへ変わります。
結果として、AIに任せること自体への不安が減り、依頼の質も上がりました。止める条件が明確だと、任せる条件も明確になるので、日々の運用が安定します。
次に改善するのは、差分レビューの自動チェックポイントです
今の運用でも事故は減りましたが、課題は残っています。特に、レビューの抜け漏れを人の集中力だけに頼ると、忙しい日に品質が揺れます。次は、差分レビューのチェックポイントをもう一段自動化したいです。
例えば「許可外ディレクトリの変更検知」「禁止操作パターンの検出」「変更ファイル数の上限超過アラート」は、先に機械で弾けます。ここを入れておけば、人は内容判断に集中できます。安全と速度の両立は、こういう分業で作るしかないと考えています。
もう一つの課題は、例外対応の扱いです。緊急修正のときにルールを一時緩和するなら、誰が、どの条件で、いつ戻すかまでセットで決めないと、運用がすぐ形骸化します。ここは次の改善テーマとして残しています。
私の結論はシンプルで、AIコーディングの怖さは能力不足ではなく境界の曖昧さにあります。だからこそ、任せる前に境界を固定する。この順番を守るだけで、実装の手応えはかなり安定しました。
最後に、私が毎回見ている最小チェックは、対象範囲、禁止操作、停止条件の3点です。項目を増やすより、毎回確実に回せる仕組みにするほうが、実務では効果が高いと感じています。これを最初に見るだけでも、かなり落ち着けます。
