Webサイトは、「自由に触れる」ほうが親切だと思われがちです。
管理画面で何でも編集できる。コードも触ろうと思えば触れる。
一見すると、柔軟で良さそうに見えます。

ただ、実務の中で感じているのは、触れる範囲を決めていないサイトほど、壊れやすいということです。

「触れる」と「触っていい」は別

最近よく感じるのは、この2つが混同されているケースが多い、という点です。

• 触れる（技術的には可能）
• 触っていい（運用上、想定している）

AIの普及によって、コードを書く・修正するハードルは確実に下がりました。
その結果、正しそうなコードを、正しくない場所に入れてしまう、という事故も以前より起きやすくなっています。

管理画面を作り込みすぎた結果、起きたこと

過去には、管理画面でほぼすべて編集できる、親切なUIを目指したサイトもありました。
「これなら困らないだろう」と思って作ったものです。

結果として起きたのは、

• 触らなくていい項目まで触られる
• 意図しない表示崩れ
• どこを直せばいいのか分からなくなる

という状態でした。

「編集できる＝編集していい」という誤解を生んでしまった、という反省があります。

HTMLは触れていい、CSSやJSは触らないほうがいい

今は、かなり割り切って考えています。

• 文言修正
• 軽微なHTML調整

このあたりは、触れていい・触りやすい状態にしておく。
一方で、

• CSS
• JavaScript
• ロジック部分

ここは、基本的に触らない前提で設計します。

「触らせない」というより、触る必要がない状態を作るという感覚に近いです。

触れる範囲を構成で示す

口頭やマニュアルで「ここは触らないでください」と伝えるよりも、

• そもそも管理画面に出さない
• ビルドが必要な領域に分ける
• ファイル構成で役割を分ける

といった形で、構成そのもので線を引くようにしています。
これだけで、事故の確率はかなり下がります。

自由度より「安心して触れる」ことを優先する

自由度が高いこと自体は、悪いことではありません。
ただ、

• 誰が
• どのタイミングで
• どこを触るのか

ここを想定しない自由度は、あとから負債になります。
特に、複数人が関わるサイトほど、「触れる範囲」を決めておくことが重要です。

AI時代だからこそ、線引きが必要になった

AIによって、コードを書く、修正案を出す、調べながら直すことは誰でもできるようになりました。
だからこそ、

• 触っていい場所
• 触らないほうがいい場所

を決めておかないと、善意の修正で壊れるケースが増えます。

まとめ

サイトを壊れにくくするために必要なのは、高度な技術や複雑な仕組みではありません。

• 触れる範囲を決める
• 役割を分ける
• 安心して触れる場所だけを用意する

それだけで、運用はかなり楽になります。
最近は、「どこまで自由にするか」よりも、「どこを自由にしないか」を先に考えるようになりました。