AIエージェントに本番を触らせない。
壊して学べる開発環境の作り方

AIに任せる勇気は、信頼ではなく復旧可能性から生まれる

AIエージェントは、指示を出すと大量のファイルを読み、修正し、コミットまで進められる。これは強力だが、同時に危険でもある。人間なら慎重に触る場所も、AIは文脈を誤解したまま一気に変更することがある。

このとき必要なのは、AIを信用するかどうかの議論ではない。信用できる部分と、信用してはいけない部分を分ける設計である。AIには作業速度がある。人間には判断と検証がある。この役割分担を前提に、AIが壊しても戻せる場所で作業させる。

つまり、安全性はAIの性格ではなく環境で作る。実験用リポジトリ、作業ブランチ、PR止め、差分確認、禁止事項。これらが揃うと、AIに任せる心理的ハードルが下がる。

本番ブランチではなく、壊れてもよい実験場を先に用意する

AIにサイト改修や記事投入を任せるなら、最初から本番を触らせない方がよい。特にCSS、JS、共通テンプレート、カテゴリ構造、ナビゲーション、sitemapなどは、1箇所の変更が全体に影響する。

実験用リポジトリやバックアップ環境を作ると、AIに広めの作業を任せやすくなる。失敗しても本番には影響しない。壊れたら捨てればよい。うまくいったら差分だけを本番に反映する。この順序にすると、AI活用のリスクがかなり下がる。

ブランチ運用も有効だが、初心者にはリポジトリ単位で分ける方が分かりやすいことがある。どれが本番で、どれが実験場かが明確だからだ。AI時代の開発では、技術的に正しいだけでなく、運用者が迷わない構造も重要になる。

AIには教育より柵が必要である

AIに「気をつけて」と言っても、安全にはならない。必要なのは、触ってよい範囲、触ってはいけない範囲、完了条件、確認方法を明示することである。これはプロンプトというより、作業場の柵に近い。

たとえば、記事追加だけなら記事フォルダ、index、sitemapに限定する。AGENTS.mdやDESIGN.mdのようなルールファイルは触らせない。共通CSSを変更する場合は、事前に明示したときだけにする。画像は元ファイルを読み取り専用として扱い、記事フォルダへコピーさせる。

こうしたルールは、AIの自由度を下げるためではない。むしろ、安全に任せる範囲を広げるためである。柵があるから、AIはその内側で速く走れる。柵がない状態で速く走らせるから事故になる。

弱い使い方と強い使い方を分けて考える

AIエージェントに本番を触らせない。壊して学べる開発環境の作り方で重要なのは、表面的な作業名ではなく、何を残し、何を次に使える形へ変えるかである。

AIエージェントは、優秀な部下ではなく、超高速で動く不安定な実行主体である。

AIエージェントは、優秀な部下ではなく、超高速で動く不安定な実行主体である。 だから必要なのは信頼ではなく、隔離、権限、差分、承認の設計である。