生成AIの書くコードは、正直かなり優秀です。数年前なら数日かかった実装が、数分で「動く」形になります。ちょっとしたLP、管理画面の試作、フォームのたたき台、社内ツールのプロトタイプ。スピードだけで見れば、もう制作現場でも無視できない存在です。
ただし、ここで見落とされやすいのが、「動く」と「保守できる」は別物だということです。公開直後に見た目が整っていて、ボタンを押したら反応する。それだけでは、半年後に安全に直せるか、担当者が変わっても引き継げるか、トラブル時に戻せるかまでは分かりません。
この記事では、AI生成コードを否定するのではなく、公開前にどこを確認すればよいかを整理します。非エンジニアの方でも「これは一度見てもらったほうがよさそう」と判断できるように、実務寄りの視点でまとめます。すでに公開してしまっていて表示が崩れている場合は、崩れ方の見分け方を先に読むほうが早いかもしれません。
「動く」と「保守できる」は何が違うのか
「動く」とは、今この瞬間に期待した結果が出ることです。ページが表示される。フォームが送れる。メニューが開く。アニメーションが動く。これはもちろん大切です。
一方で「保守できる」とは、あとから安全に直せることです。文言を変えてもレイアウトが崩れない。ボタンを増やしてもCSSが破綻しない。エラーが出たときに原因を追える。別の人が見ても、どこを触ればよいか分かる。ここまで含めて、事業で使えるコードになります。
AI生成コードは、前者には強いです。短時間で形にする力があります。ただ、後者は指示しないと抜けやすい。特に「とにかく動くものを作って」と頼むと、AIは動作を優先し、整理や命名、分割、例外処理、運用時の読みやすさを後回しにすることがあります。
AI生成コードで起きやすい問題
AI生成コードでよくある問題は、見た目では分かりにくいものが多いです。公開時には気づかず、あとから修正や更新をするときに表に出ます。
- 同じようなCSSや処理が複数箇所に重複している
- クラス名や関数名に一貫性がなく、役割が読み取りにくい
- 1つのファイルにHTML、CSS、JavaScriptの責務が詰まりすぎている
- スマホ表示や長い文章、画像差し替えへの耐性が弱い
- エラー時の処理や入力チェックが不足している
- APIキーや秘密情報の扱いが危ない
- 外部ライブラリに依存しているのに、読み込み失敗時の想定がない
- コメントやREADMEがなく、なぜその実装になったか分からない
これらは、すぐに事故になるとは限りません。だから厄介です。公開直後は問題なくても、「1行だけ直したい」「フォーム項目を増やしたい」「担当者が変わった」といったタイミングで一気に重くなります。
公開前に見るべきチェック項目
公開前にすべてを完璧にする必要はありません。ただし、最低限ここだけは見ておくと、あとからの事故を減らせます。
- PC、スマホ、タブレット幅で主要ページを確認する
- 長い見出しや文章を入れても崩れないか試す
- 画像を別サイズに差し替えてもレイアウトが破綻しないか見る
- フォームの必須項目、エラー表示、自動返信を確認する
- 送信先メール、reCAPTCHA、添付ファイルなどの処理を確認する
- ページタイトル、description、OGP、構造化データを見る
- 不要なテスト文言、サンプル画像、仮リンクが残っていないか探す
- APIキー、パスワード、秘密情報が表側に出ていないか確認する
非エンジニアの方におすすめなのは、「1ヶ所だけ実際に直してみる」ことです。見出しを変える、画像を差し替える、カードを1つ増やす。これを安全にできるなら、ある程度運用に耐えます。逆に、少し触るだけで全体が崩れるなら、公開前に整える価値があります。
引き継げる状態にしておく
サイトやシステムは、作った瞬間よりも、引き継ぐ瞬間に品質が出ます。作った本人は分かっていても、1ヶ月後の自分、別の担当者、外部パートナーが分からなければ、運用コストは上がります。
最低限、次の情報は残しておきたいところです。
- どのファイルが何の役割を持っているか
- 更新するときに触る場所
- フォームや外部サービスの設定場所
- 公開手順と、戻す手順
- 使っているライブラリやツール
- まだ仮のまま残っている部分
立派なドキュメントでなくても構いません。READMEに数行書くだけでも、未来の修正はかなり楽になります。AIに作らせた場合ほど、「どういう前提で作ったか」を人間側で残すことが大切です。
AIと人のちょうどいい分担
AIは、最初の形を作る力が非常に強いです。アイデアを画面にする、たたき台を作る、選択肢を出す、単純な実装を早める。ここは積極的に使ってよいと思います。
一方で、人が見るべきなのは、事業上の責任がある部分です。お問い合わせが届くか。個人情報を安全に扱っているか。表示崩れで信頼を落とさないか。検索や広告の計測ができるか。担当者が変わっても続けられるか。ここは、単にコードが動くかどうかでは判断できません。
つまり、生成はAI、品質保証と運用設計は人。この分担にすると、AIの速さを活かしながら、公開後の不安を減らせます。
よくある質問
完全にではありませんが、命名の一貫性のなさ、似た処理の重複、コメントの有無などから傾向は見えます。確実に判断したい場合は、コード全体を一度見てもらうのが早いです。
見た目や操作で分かる範囲であれば可能です。スマホ表示、フォームの送信、文言の差し替えなどは実際に触って確認できます。ただしセキュリティやコードの構造は専門知識が必要なので、そこだけ第三者に見てもらう形がおすすめです。
指示の仕方次第である程度は改善できます。「動くものを作って」ではなく、「命名を分かりやすく」「ファイルを役割ごとに分けて」「コメントを残して」のように具体的に指示すると、保守性は上がります。ただし最終的な確認は人が行うのが安全です。
Webコーダー/ディレクターとして独立後、2026年にI-to.合同会社を設立。Webサイト制作・コーディング代行・AIケアを通じて、社内のWeb業務を整理し、運用しやすい形に整えています。プロフィール詳細