「AIが勝手に本番を書き換える？」への答え｜承認とGitの関係

生成AIがソースコードを書き、バグを修正し、機能を追加する。この「AIによるソフトウェア開発」が当たり前になる中で、多くのIT担当者や経営層が抱く最大の懸念は、「AIが勝手に本番環境のプログラムを書き換えて、システムを破壊してしまわないか？」という点です。

結論から申し上げます。現代の標準的なITインフラにおいて、AIが人間の承認なく、勝手に本番環境を書き換えることは、意図的にそのような設定をしない限り起こり得ません。

本記事では、AIによる自動開発の利便性を享受しつつ、システムの安全性を100%担保するための「Git」を軸とした承認フローと、主要ツールの仕様、そして実務的な運用設計について詳しく解説します。

AIは勝手に本番環境を書き換えるのか？現状の技術仕様と実態

「AIがプログラムを勝手に直す」というイメージは、SF的な暴走を連想させますが、実務上のアーキテクチャはもっと泥臭く、厳格です。

自律型AIエージェントと開発支援AIの違い

まず、私たちが使っているAIツールには大きく分けて2つのタイプがあります。

• 開発支援AI（GitHub Copilot, Cursorなど）：エンジニアのコーディング中に、次に書くべきコードを「提案」するツール。あくまでエディタ上の文字入力補助であり、これ自体がサーバーに接続することはありません。
• 自律型AIエージェント（Devin, Replit Agentなど）：指示を与えると、ファイルの作成からテストの実行、デプロイまでを「自律的に」試行するツール。

後者の自律型エージェントであっても、通常は「サンドボックス（砂場）」と呼ばれる隔離された環境で動作します。公式なドキュメントにおいても、AIが直接本番環境の認証情報を持ち、SSHでサーバーにログインしてファイルを書き換えるような構成は推奨されていません。例えば、Replit Agentにおいても、変更はプロジェクト内のワークスペースに限定され、本番公開にはユーザーによるデプロイ操作が介在します。

「サンドボックス」と「本番環境」を隔てる壁

エンタープライズ領域におけるシステム開発では、ソースコードの変更は必ず「CI/CD（継続的インテグレーション/継続的デリバリー）」というパイプラインを通過します。AIがコードを生成しても、それが本番環境に反映されるまでには、後述するGitの承認プロセスという物理的な関門が存在します。

AIの暴走を防ぐ「Git」による承認フローの再定義

AI時代において、その価値が再評価されているのがGit（GitHubやGitLabなどのバージョン管理システム）です。Gitは、誰が、いつ、どのような理由で、コードのどの行を変えたかをすべて記録します。

なぜGitがAI時代のガバナンスに不可欠なのか

AIにコードを書かせる際、最大のリスクは「なぜその修正が行われたのか、人間が理解していないこと」です。Gitを利用すれば、AIが提案したコードを「プルリクエスト（Pull Request）」という形で一時停止させ、人間が内容を確認してから「マージ（結合）」するというフローを強制できます。

ブランチ保護ルール（Branch Protection）の徹底

GitHubなどのプラットフォームには「Branch Protection Rules」という機能があります。これを設定することで、以下のような「物理的な制約」を課すことが可能です。

• 管理者であっても、1人以上の承認（Approve）がないと本番ブランチにマージできない。
• 自動テストがパスしていないコードは、マージボタンが押せない。
• 署名付きコミットのみを許可する。

このルールがある限り、AIがどれほど高度なコードを生成しようとも、人間の「Approve」ボタンのクリックなしに本番環境が書き換わることはありません。これは、社内のバックオフィス業務を自動化する際も同様です。例えば、Google WorkspaceとAppSheetを活用した業務DXにおいても、アプリの更新（本番反映）権限を管理者に絞ることで、AIによる予期せぬ改修を防ぐことが可能です。

主要なAIコード生成ツールにおける「デプロイ」の仕組み比較

現在主流のAIツールが、どのようにコードを扱い、どのように本番環境へと橋渡しをするのか、その仕様を比較しました。

注目すべきは、どのツールも「AIが勝手に本番サーバーのファイルを書き換える」のではなく、「AIがコードの修正案を作成し、人間がそれをデプロイ（またはマージ）する」というステップを踏んでいる点です。

【実践】AIと共存するセキュアな開発ワークフロー 5ステップ

実務担当者が導入すべき、AI時代の標準ワークフローを解説します。この手順を守ることで、AIのスピードを活かしつつ、本番環境の安全性を担保できます。

STEP 1：AI専用ブランチの作成

本番用のブランチ（mainやmaster）で直接AIを作動させてはいけません。必ず feature/ai-improvement のような作業用ブランチを作成し、そこをAIの活動領域にします。

STEP 2：AIによるコード生成とローカル検証

AI（CursorやGitHub Copilot）にコードを書かせます。この際、エンジニアは手元のローカル環境で「実際に動くか」を確認します。AIが書いたコードがシンタックスエラー（構文ミス）を起こしていないか、この段階で排除します。

STEP 3：CI（自動テスト）による機械的なバリデーション

コードをGitにプッシュすると、GitHub ActionsなどのCIツールが起動するように設定します。ここで、

• 静的解析（コードの書き方に不備がないか）
• ユニットテスト（計算結果などが正しいか）
• セキュリティスキャン（脆弱なライブラリを使っていないか）

を自動実行します。AIが書いたコードがテストを落とした場合、その時点でマージはブロックされます。

STEP 4：人間によるピアレビュー（コードレビュー）

ここが最も重要な「承認」のステップです。熟練したエンジニアが、AIの生成したコードをレビューします。

AIは「動くコード」を書くのは得意ですが、「保守しやすいコード」や「ビジネスロジックに忠実なコード」を書く際、稀に嘘（ハルシネーション）をつきます。

このステップを自動化してはいけません。人間が内容を理解し、「よし」と判断したときのみ、Approveボタンを押します。

STEP 5：本番環境へのマージと自動デプロイ

承認が得られたらマージします。マージをトリガーに、本番環境への自動デプロイが走ります。このとき、万が一問題が発生してもすぐに戻せるよう「ロールバック（切り戻し）」の仕組みを整えておくことが重要です。インフラの負債や構成に不安がある場合は、SaaSコストとオンプレ負債を断つためのインフラ再構築を検討すべきタイミングかもしれません。

「AIがテストも書く」時代の品質担保：誰が正解を定義するのか

「AIにコードを書かせ、そのテストもAIに書かせたら、それは自作自演ではないか？」という指摘は非常に鋭いものです。テストが通ったとしても、そのテスト自体が間違っていれば、本番環境は破壊されます。

テストコードの妥当性を確認する手法

AI時代におけるテストの役割は、「人間が定義した仕様（要件）」を死守することにシフトします。

• プロンプトに仕様を明記する：AIにテストを書かせる際、「Aという入力に対してBという出力を返すこと。Cのケースはエラーにすること」という期待値を人間が言葉で定義します。
• カバレッジの確認：テストがコードのどれくらいの割合を網羅しているかを計測し、AIが見逃している分岐がないかを人間がチェックします。

特に、広告データや顧客行動データなどの複雑なロジックを扱う場合、AI任せにすると計算ロジックの微細なズレが致命傷になります。例えば、CAPIとBigQueryを用いた自動最適化アーキテクチャのような高度なデータ連携では、AIの提案を鵜呑みにせず、出力結果の整合性を検証する厳格なテストコードが不可欠です。

まとめ：AIに「書かせ」、人間に「責任」を持たせる設計

「AIが勝手に本番を書き換える」という恐怖の正体は、「プロセスのブラックボックス化」です。Gitという透明性の高いバージョン管理システムを使い、適切な承認フローを組み込むことで、AIは恐ろしい破壊者ではなく、心強い超高速なアシスタントへと変わります。

重要なのは、以下の3点です。

1. AIは提案者、人間は決定者であるという責務の分離。
2. Gitのプルリクエストとブランチ保護による物理的なガードレールの設置。
3. AIが書いたコードとテストを、別の視点（CIや人間）で二重にチェックする体制。

AIの進化は止まりませんが、それを受け入れるための「器」となる開発プロセスを整備することこそが、今IT担当者に求められている最大のミッションです。