AIエージェントのビルド実行を承認制にする設計
この記事で学べること
- 本番向けビルドを通常の検証コマンドと分けて扱う理由
- 依頼範囲を越えてコマンドが実行された原因の整理方法
- 危険な操作の前に明示的な承認を求めるルールの作り方
AIエージェントのビルド実行には承認ゲートを置く
ナビゲーション調整を依頼した作業で、本番向け成果物を生成するnpm run buildまで実行されたことが、期待と結果の差でした。ローカルビルドは本番公開そのものではありませんが、このリポジトリでは明示承認が必要な操作として扱います。通常の検証と承認対象を事前に分け、指示、権限、フックなど必要な強さの制御を選びます。
この記事では、「通常の検証と、明示承認が必要なビルド・公開操作をどう分けるか」という問いに焦点を当て、期待と結果の差、確認できた条件、再発を防ぐ判断を扱います。
最後まで読むと、「通常の検証と、明示承認が必要なビルド・公開操作をどう分けるか」という問いを、自分の状況に照らして判断するための材料を持ち帰れます。
ビルド実行を承認操作として扱う理由
AIに修正を依頼している最中に、意図していないタイミングで本番向けビルドコマンドが実行されました。この記事では、その経緯と、再発を防ぐために導入したルールを記録します。
ナビゲーション調整中に本番向けビルドが実行された
あるとき、サイトのナビゲーション構造の調整をAIに依頼していました。いくつかのファイルを修正してもらい、変更内容を確認していたところ、その流れの中でAIが npm run build を実行しました。
npm run build は、Webサイトの設定やコードから本番用の成果物を生成するコマンドです。このリポジトリでは、成果物を公開する処理はホスティング側のデプロイパイプラインが別途担います。したがって、ローカルビルドと本番反映は分けて扱う必要があります。
このとき私が依頼していたのは「ナビゲーションの調整」であり、「本番向けビルド」ではありませんでした。
なぜAIはそのコマンドを実行したのか
AIの視点では、ファイルの修正が完了した後に「動作確認のためにビルドを実行する」という流れは自然な次のステップです。修正してビルドして確認するという手順は、開発の一般的な流れとして学習されているため、明示的な指示がなくてもその方向に動くことがあります。
問題は、AIが判断した「次のステップ」が、私の判断タイミングより先に進んでしまったことです。処理時間や生成物、キャッシュなどに影響するビルドコマンドを、確認なしに実行するのは避けるべきでした。
本番向けビルドは明示承認後だけ実行する
この経験を踏まえて、プロジェクトのルールファイル（CLAUDE.md）に次の記述を追加しました。
npm run buildはユーザーの明示的な承認なしに実行しない。
このルールにより、AIが修正の流れで自動的にビルドを実行しにくくします。確実に止める必要がある場合は、PreToolUse Hook（コマンド実行の前後など決まったタイミングで自動処理を動かす仕組み）や権限制御で対象コマンドをブロックします。ビルドが必要なときは、私が「ビルドしてください」と明示的に伝えてから実行してもらいます。
通常のプレビュー確認には npm run dev を使います。これはローカル環境だけで動くコマンドなので、本番環境には影響しません。
まとめ：自律実行できるコマンドと承認が必要なコマンドを分ける
本番環境に影響するコマンドは、作業の流れの中で「次のステップとして自然」であっても、明示的な確認ステップを設けるべきでした。AIは文脈から判断して行動するため、その判断の範囲と境界を明確にしておく必要があります。
どのコマンドをAIが自律的に実行できて、どのコマンドは承認が必要かを事前に整理しておくことが、安全な協働につながります。
最初にプロジェクトの主要コマンドを一覧にし、外部状態、生成物、時間、費用へ影響する操作へ承認条件を付けます。ビルドとデプロイの関係はリポジトリごとに異なるため、この記事のnpm run buildルールを他の環境へそのまま移さないでください。