企業Webサイトの生成AI・実務実装ガイド
第3回
AI生成コードを本番投入する前に｜企業サイトの安全なCMS運用とコードレビュー
最終更新日：2026年8月27日
「問い合わせフォームの項目を少し変えたい」「ボタンのデザインを変更したい」。
以前であれば制作会社への依頼、見積もり、作業待ちが必要だった変更も、現在は生成AIに相談しながら短時間でコード案を作成できるようになりました。
しかし、AIが生成したコードは、対象サイトのサーバー環境、CMSのバージョン、既存プラグイン、権限設定、個人情報の扱いまで自動的に把握しているわけではありません。 コードが一度動いたことだけを理由に本番環境へ反映すると、表示崩れ、機能停止、保守性の低下、脆弱性などにつながる可能性があります。
本記事でいう「AIペアプログラミング」とは、AIに実装を丸投げすることではありません。人間が要件と制約を定義し、AIがコード案を作成し、人間が検証・レビューしたうえで反映する人間主導のAI支援開発を指します。
連載第3回となる今回は、AI生成コードを企業サイトの運用に取り入れる際に、どのようなリスクを確認し、どの環境で検証し、どの段階で専門家のレビューを受けるべきかを解説します。
1. AI生成コードを本番環境へ直接投入することが危険な理由
WordPressではテーマやプラグイン、functions.phpなどを編集して機能を追加するケースがあります。Movable Typeでは、テンプレート、テンプレートタグ、プラグイン、Data API、サーバー設定などが変更対象になることがあります。
最近では生成AIに「WordPressで〇〇をするコードを書いて」と指示し、出力されたコードを管理画面やサーバーへ直接反映するケースも増えています。
ここで注意したいのは、AIが生成したコードは、そのサイト固有の環境を完全に把握したうえで作られているとは限らないことです。実際には、次のような情報が不足したままコードが生成されることがあります。
- 利用中のCMS・PHPのバージョン
- 有効化されているテーマやプラグイン
- 既存コードとの依存関係
- ユーザー権限や認証の仕組み
- 個人情報や機密情報の保存方法
- サーバー、CDN、WAFなどの構成
重要なのは「動くかどうか」だけでなく、安全に動くか、既存機能に影響しないか、将来も保守できるかを確認することです。
2. AI生成コードに潜む4つのリスク
AI生成コードをレビューせずに本番環境へ投入すると、具体的にどのような問題が起きるのでしょうか。企業サイトで特に確認すべき4つのリスクを紹介します。
3. 安全なAI支援開発の実務フロー
適切なルールと検証環境を整えれば、AIは要件整理、プロトタイプ作成などに活用できます。AIに実装を丸投げするのではなく、人間が要件を定義し、AIが案を作り、人間が検証・承認して反映するという役割分担が必要です。
AIにコードを生成させる前に、対象CMS、PHPバージョン、変更対象のファイル、利用者権限、扱うデータなどを整理します。特に「個人情報、認証、決済、データベース操作」を含む場合は、専門家による設計が必要な領域として扱います。
【安全性を高めるプロンプト例】
「WordPressの投稿画面に〇〇の機能を追加するコード案を作成してください。対象環境はPHP8.xです。入力値のサニタイズ、出力時のエスケープ、権限チェック、nonce検証を含めてください。また、提示前に『既存サイトへの影響範囲』と『想定される失敗パターン』を説明してください。」
※AIの説明はあくまでレビューの材料であり、最終判断は人間が行います。
AI生成コードは、本番と近いステージング環境（テスト環境）で確認します。意図した機能が動くかだけでなく、権限のないユーザーが操作できないか、既存ページが崩れないか、エラーログが出ていないかを確認します。
テスト環境で動作確認が取れたら、最後に社内の技術責任者や保守会社のエンジニアによるコードレビュー（脆弱性、競合、パフォーマンス低下がないか）を受けます。この分業体制が、企業サイトの安全性を守る基本形です。
4. エンジニアにレビューを依頼できない場合の代替策
社内にエンジニアがいなかったり、予算の都合で都度レビューを受けられない場合は、次のようにリスクの高い作業を避けながら運用します。
- 高リスクな機能を自作しない：個人情報、認証、決済、データベース操作を扱う機能は、AI生成コードだけで実装しない。
- 実績のあるSaaSやプラグインを優先する：要件に合うSaaS（HubSpotなど）や、公式ディレクトリの安全なプラグインで代替する。
- AIによるクロスレビュー：別のAIにコードを確認させ、脆弱性やエラーの確認観点を洗い出す（※ただしこれだけで安全は保証できません）。
- 本番反映前の手順を固定する：事前のバックアップ取得と、問題発生時のロールバック（復元）手順だけは必ず用意しておく。
5. エンタープライズCMS保守に必要なガバナンス
どれだけルールを決めても、管理画面から簡単にコードを編集できる状態では人為的ミスを防げません。システムと運用の両面からガバナンスを整える必要があります。
- テーマエディターの無効化：WordPressの
wp-config.phpでDISALLOW_FILE_EDITを設定し、管理画面からの直接編集をシステム的に禁止する。 - Git等によるバージョン管理：いつ、誰が、どのコードをなぜ変更したのか履歴を残し、1つ前の安全な状態へすぐに戻せるようにする。
- 自動バックアップと復元テスト：データベースとファイルが自動でバックアップされているか、そして「実際に復元できるか」を定期テストする。
6. 本番反映前チェックリスト
AIが生成したコードを本番環境へ反映する前に、最低限次の項目を確認してください。
- 変更対象のファイルと、既存機能への影響範囲を説明できる
- 個人情報や機密情報をAIに入力していない
- 入力値のサニタイズ、出力先のエスケープが記述されている
- 権限チェックやnonce検証が必要な処理か確認した
- 本番ではなく、ステージング環境（テスト環境）でテストした
- サーバーログに警告やエラーが出ていないことを確認した
- 直前のバックアップを取得し、ロールバック（復旧）手順を手元に用意した
7. まとめ：AI時代に必要なのは管理とレビューの体制
生成AIによって、非エンジニアでもコード案を作成しやすくなりました。しかし、コードを書くことと、安全に運用できることは同じではありません。
- AI生成コードは動作だけでなく、セキュリティ・互換性・保守性を確認する。
- 原則として本番環境へ直接投入せず、必ずステージング環境で検証する。
- 個人情報、認証、決済などの領域はAIコードだけで自作しない。
- 管理画面での直接編集を禁止し、バージョン管理とバックアップを徹底する。
これからのWeb担当者に求められるのは、すべてのコードを自分で書く力ではなく、AIを使って要件を素早く形にし、それを安全に検証し、本番環境へ反映するための運用体制と判断基準を構築する力です。技術的負債を抱え込まずにサイトを拡張していくために、自社の保守体制を一度見直してみましょう。
次回予告
次回、シリーズ第4回は「『AIでデータ分析』はなぜ失敗する？GA4×生成AIで作る、意思決定できるレポーティング術」をお届けします。
「GA4のデータをChatGPTに読み込ませたけれど、当たり障りのない結果しか出ない」という悩みはありませんか。AIに実務で使えるインサイトを出させるためのデータ成形とプロンプトの工夫について解説します。
AI時代の安全なWebサイト保守・運用体制でお悩みの方へ
「担当者が退職し、サイトの中身がブラックボックス化している」
「AIを活用して内製化を進めたいが、セキュリティ面が不安」
「WordPressやMovable Typeのアップデート・保守を任せたい」
「ステージング環境やGit管理フローを構築したい」
株式会社ヒューコネクトでは、エンタープライズ向けのWebサイト構築から、技術的負債を解消する保守・運用サポートまで、エンジニアチームが伴走支援します。
現状の課題整理や、既存の制作会社との役割分担に関するご相談も可能です。貴社の運用フローに合わせた安全なシステム基盤の構築をご支援します。
