Vibe codingのサイトが3か月後に詰む前の更新設計

AIにお願いするだけで、コーポレートサイトやLPがあっという間に形になる時代になりました。ところが「公開したはいいけど、お知らせ一つ自分で直せない」という相談が、ここ最近増えています。

この記事では、Vibe codingで作ったサイトが数か月後に詰む理由を整理したうえで、最初から「更新できる仕組み」を入れておくための具体的なやり方を、非エンジニアの方にも分かる言葉で解説します。読み終わるころには、自社のサイトに何を入れておけばいいかが判断できる状態を目指します。

Contents / 目次

1. 結論。詰む前に「更新する場所」だけ切り出しておく
2. 更新できる仕組みの入れ方。公開前にやる4ステップ
3. 仕組みを入れた先に起きる変化
4. よくある失敗と回避法
5. 使う側の落とし穴と、正直な妥協点
6. よくある質問

結論。詰む前に「更新する場所」だけ切り出しておく

先に結論をお伝えします。Vibe codingで作ったサイトを長く使うコツは、サイト全体をCMSにすることではなく、「これから何度も書き換える場所」だけを本文から切り出しておくことです。

そもそもVibe codingとは、AIに自然な言葉で指示してWebサイトやアプリを組み立てる作り方のことです。かんたんに言うと「コードを自分で書かず、AIに書いてもらう」やり方です。スピードは圧倒的に速い反面、出てくるのは多くの場合、文章もデザインも1つのHTMLファイルに溶け込んだ「塊」です。

この塊が問題の正体です。お知らせの日付を1つ変えたいだけなのに、レイアウトを支えているコードの中から該当箇所を探し当てなければならない。1文字消す場所を間違えれば、ページの見た目が崩れる。これが「数か月後に詰む」の中身です。

だから打ち手は2つに1つです。更新が必要な情報を最初から載せない（更新しない前提で割り切る）か、更新する場所を本文と分けて誰でも触れるようにしておくか。どちらを選ぶかは、更新の頻度と担当者の有無で決まります。

更新の状況	向いている作り方	理由
更新はほぼしない（年1回程度）	静的サイトのまま。直すときだけ依頼	仕組みを入れる手間の方が高くつく
お知らせ・実績だけ時々更新	更新箇所だけデータ分離（後述）	本文を壊さず文章だけ差し替えできる
ブログ・採用など頻繁に更新	WordPressやヘッドレスCMSを導入	編集画面から非エンジニアでも回せる
担当者がいない・更新も未定	静的サイト＋年間保守契約	放置でセキュリティが穴になる事故を防ぐ

ここが分かれ目。「いつか更新するかも」で全部をCMS化すると、結局ログインせず放置されて古い情報が残ります。更新する場所を具体的に決めてから、その分だけ仕組みを入れるのが失敗しないやり方です。

更新できる仕組みの入れ方。公開前にやる4ステップ

ここからは、実際に手を動かす順番を具体的に説明します。Vibe codingでサイトを作る前、または作った直後に、次の4ステップを通しておくと運用が安定します。

ステップ1。更新する場所を紙に書き出す

最初にやるのは、コードでも設定でもありません。「このサイトで、今後書き換える可能性がある場所」を全部書き出すことです。たとえば、次のような項目です。

• お知らせ
• 料金
• 営業時間
• スタッフ紹介
• 実績
• ブログ

これを洗い出すだけで、CMSが必要か、一部分離で足りるかが見えてきます。

洗い出すときは、頻度も一緒にメモします。週1回なのか、半年に1回なのかで打ち手が変わるからです。ここを飛ばすと「なんとなく全部更新できるように」と過剰な作りになり、運用が重くなります。

ステップ2。更新する文章を本文から「データ」として切り出す

更新箇所が「お知らせ」程度なら、フルのCMSは要りません。文章だけを別ファイル（データ）に逃がしておけば、レイアウトを壊さずに中身を差し替えられます。やり方の考え方はこうです。

たとえばお知らせ一覧を、デザインのコードとは別のnews.jsonというファイルに分けます。担当者はこのファイルの文章だけを書き換える。デザイン部分には一切触らない。これだけで「直そうとして見た目を壊す」事故がほぼなくなります。

AIに作らせるときは、次のような短い指示（たたき台）から始めるとよいです。あとはAIと対話しながら自社の状況に合わせて詰めてください。

あなたはWeb制作のサポートです。
私は非エンジニアで、お知らせ欄だけ自分で更新したいです。
お知らせの「文章データ」と「表示するコード」を分けて作ってください。
文章は ［お知らせのファイル名］ にまとめ、
私はそのファイルの中の日付とタイトルだけ書き換えれば
画面に反映される形にしてください。
HTMLやデザインのコードは触らずに済む構成にしてください。

実際に出てくる形のイメージも載せておきます。まず、担当者が書き換える文章データ（これだけ触ればOK）です。

[
  { "date": "2026-06-19", "title": "夏季休業のお知らせ" },
  { "date": "2026-06-01", "title": "新サービスを公開しました" }
]

そして、この文章データを読み込んで画面に並べる側のコードです。一度設置すれば、以降はさわる必要がありません。

<!-- 前提：このHTMLと同じ場所に news.json を置く。
     サーバーにアップして表示を確認する（自分のPCで直接開くと動かない場合あり） -->
<div id="news-list"></div>
<script>
fetch('news.json')  // ［更新する文章は news.json 側にまとめる］
  .then(function (res) { return res.json(); })
  .then(function (items) {
    var rows = items.map(function (item) {
      return '<li><time>' + item.date + '</time> ' + item.title + '</li>';
    }).join('');
    document.getElementById('news-list').innerHTML = '<ul>' + rows + '</ul>';
  });
</script>

このやり方は「自社で管理している文章」を表示する前提です。外部から投稿を受け付けるような用途では、入力内容をそのまま画面に出すと表示崩れや攻撃の入口になり得るため、その場合はWordPressなどのCMSを使ってください。

ステップ3。更新頻度が高い箇所はCMSを選ぶ

ブログや採用情報のように、毎週のように増えていくコンテンツは、データファイルの手編集では追いつきません。ここは素直にCMSを使います。CMSとは、専門知識がなくても管理画面から文章や画像を投稿できる仕組みのことです。

選び方の目安として、社内で完結させたいならWordPress、表示速度やフロントの自由度を重視するならヘッドレスCMS（microCMSなど）が候補になります。どれを選ぶかで迷う場合は、広報担当者のための失敗しないCMS（管理画面）の選び方に判断軸をまとめているので参考にしてください。

ステップ4。公開前チェックリストで「運用の穴」を塞ぐ

仕組みを入れたら、公開前に次の項目を確認します。AIが生成したサイトは見た目が整っていても、運用に必要な土台が抜けていることが多いからです。

• 更新担当：誰がどの箇所を更新するか、名前まで決まっているか
• 編集手順：手順を3行のメモにして担当者に渡せるか
• フォーム送信：問い合わせフォームの通知メールが実際に届くか、テスト送信したか
• バックアップ：サイトのファイル一式を別の場所に保存してあるか
• SSL・ドメイン：httpsで表示され、ドメインの更新期限を把握しているか
• 更新の反映確認：文章を1行書き換えて、実際に画面に反映されるか試したか

特にフォームの動作確認は飛ばされがちです。AI生成のサイトは送信ボタンの見た目だけ作られて、裏側の送信先が空のまま、というケースが珍しくありません。フォームの設計そのものを見直したい方は問い合わせフォームを5項目に減らすBtoBの設計と問い直しもあわせてどうぞ。

仕組みを入れた先に起きる変化

更新できる仕組みを最初に入れておくと、何が変わるのか。一番大きいのは「ちょっとした修正のたびに外注する」状態から抜け出せることです。

たとえば、お知らせの差し替えを毎回制作会社に頼んでいたとします。1回ごとに費用と待ち時間がかかり、これが月数回発生すると、年間ではまとまった負担になります（金額や日数は依頼先や内容で大きく変わります）。文章だけ自社で差し替えられる状態にしておけば、この往復がゼロになります。

スピード面の変化も見逃せません。「採用を締め切ったのにサイトに募集が残っている」「終わったキャンペーンが出たまま」といった、信頼を下げる情報のズレを、その場で直せるようになります。情報が新しい状態を保てると、訪問者に与える信頼も保たれます（更新頻度そのものが検索順位を上げるわけではありません）。

うまく回している会社に共通するのは、派手な仕組みを入れていないことです。「更新する場所はここだけ」と割り切り、その1〜2か所を確実に回している。あれもこれも更新できるようにした会社ほど、かえって何も更新されずに放置される。これは現場で何度も見てきた傾向です。

よくある失敗と回避法

Vibe codingで作ったサイトの運用で、実際によく見かける失敗を3つ挙げます。どれも「あるある」なので、当てはまりそうなものから対策してください。

失敗1。とりあえず全部CMS化して、結局誰もログインしない

「将来更新するかもしれないから」と全ページをCMSにした結果、操作が複雑で誰も触らなくなるパターンです。忙しさにまぎれてログインしなくなり、何年も同じ内容のまま放置される。古い情報が残り、かえって信頼を下げます。

防ぐには、ステップ1の「更新する場所の書き出し」を必ず先にやることです。本当に更新する箇所だけ仕組みを入れ、それ以外は静的のままにする。更新しない情報は、いっそ最初から載せないという割り切りも有効です。

失敗2。AIが書いたコードを誰も理解できず、直せる人がいなくなる

Vibe codingで一気に作ると、コードの構造を作った本人すら把握していないことがあります。半年後に「ここを少し直したい」となったとき、どこをいじれば安全か分からず、結局ゼロから作り直しになる。これが一番もったいない失敗です。

回避策は、作った直後に「どのファイルが何の役割か」を3〜5行のメモに残すことです。AIに「このサイトの構成を、非エンジニア向けに簡単に説明して」と頼めば、その説明文を保存しておくだけでも将来の自分を助けます。あわせて、ファイル一式のバックアップを必ず取っておきます。

失敗3。セキュリティとアップデートを放置して穴になる

AIが生成したコードは、人が確認しないとセキュリティ上の弱点を見落とすことがあります。さらにWordPressなどを使う場合、本体やプラグインの更新を放置すると、乗っ取りや改ざんの入口になります。

対策はシンプルです。次の4つを習慣にしておくと、放置が原因のトラブルを起こしにくくなります。

• SSL（https化）の確認
• 定期的なアップデート
• 二段階認証の設定
• こまめなバックアップ

WordPressを使う方はWordPress乗っ取りを防ぐ更新と二段階認証の最低限設定に最低限の手順をまとめています。ドメインやSSLの期限切れでサイトが止まる事故も多いので、ドメイン・SSL期限切れでサイト停止を防ぐ中小企業の更新管理もあわせて確認しておくと安心です。

使う側の落とし穴と、正直な妥協点

ここからは、教科書的な記事には書きにくい「現場で見えた本音」をお伝えします。Vibe codingは便利ですが、向き不向きがあります。

まず、AIは「下書き」と「壁打ち相手」としては非常に優秀ですが、最終的な品質の判断は人がやる必要があります。出てきたコードが動いているように見えても、公開前に次の点は自分の目で確かめてください。

• スマホで表示が崩れていないか
• フォームが本当に届くか
• 表示が遅くないか

この確認を省くと、見た目だけ立派で中身が穴だらけのサイトが完成します。AIに「作らせる」だけでなく「人が確認して仕上げる」工程は省けません。

次に、内製と外注の線引きです。お知らせの差し替えのような「文章を入れ替えるだけ」の作業は内製がおすすめです。一方、サイト全体の構造変更、決済やデータベースが絡む機能、独自のシステム連携は、無理に自社で抱えると後で詰みます。ここは早めにプロに渡したほうが、結果的に安く早く済むことが多いです。

コストの見落としも一つ。Vibe codingは「作る費用」がほぼゼロに見えますが、運用にはサーバー代、ドメイン代、保守の手間という見えにくいコストがかかり続けます。作る瞬間だけ見て「タダで作れた」と判断すると、放置・事故・作り直しでかえって高くつきます。

向き不向きの本音。更新頻度が低く、社内に一人でも触れる人がいるなら、Vibe coding＋一部分離は相性抜群です。逆に、複雑な機能が必要だったり、更新する人が誰もいないなら、最初からプロに設計を入れてもらうほうが長い目で見て安心です。

よくある質問

ここまで読んで、「更新する場所の切り分けや、AIで作ったサイトの仕上げを自社だけでやり切るのは難しそう」と感じた方もいるかもしれません。コレットラボでは、AIで作るLPやコーポレートサイトの内製化を、現場目線で伴走支援しています。「自分たちで更新したい」「プロに任せたい」のどちらにも合わせて設計できるので、まずは現状を整理するだけでも構いません。気軽にお話を聞かせてください。AI業務システム化の詳細はこちらからご覧いただけます。