baserCMS 4系、サポート終了で思うこと。

2026年5月、4系がひそやかにメンテナンスサポートを終了したこと、ご存知でしょうか。
「コーポレートサイトにちょうどいい」 というフレーズで、baserCMSのリリース当初から4系に至るまで歴代のbaserCMSが一貫して掲げ続けてきたコンセプトは、この4系をもって終わりを告げたように感じます。
このキャッチコピーを紐解けば、「企業（コーポレイト）のWeb担当者（たぶん、結構な初心者でも、という想定をしていたはず）でも簡単に運用できる仕組みです。」ということかと。
つまり、WordPressとの差別化として、専門知識がなくても中小企業がホームページを安全・簡単に自社運用できる「ちょうどよさ」あるいは「痒いところに一通り手が届いている」といったところを前に出してきたんだと思います。
ところが、5系になって伝統のキャッチフレーズは、「ヘッドレスCMS」 へと大きく転換しました。確かに「ヘッドレスCMS ＝（REST APIの標準搭載）」により、従来のWebサイト制作の枠を超えた柔軟なシステム構築が可能になったのでしょう。しかし、その反面、「コーポレートサイトにちょうどいい」とは言い難い、つまり「企業（コーポレイト）のWeb担当者では、簡単に運用しづらい仕組み」になってしまったきらいは、やはり否めないように思います。

細かいことはさておき、以下に示す点は、4系からのユーザーが、おそらく一様に感じていることではないかと思います。

サイト制作の「前提知識」のハードルが上がった

• 4系まで：PHPとHTML/CSSの知識があれば、「一般的なWebサイト」をすぐに作ることができました。
• 5系から：ヘッドレスCMS（REST API）という概念が加わったため、その恩恵を100%受けるには「Next.js」や「React」、「Vue.js」といったモダンなフロントエンドの知識やAPIの認証（JWT）の理解も必要になってしまいました。

単純な中小企業のホームページを作りたいだけの初心者にとっては、システム的にはフロンドエンドが軽くなったのかもしれないが、引き換えに自分たちが使う機会がほとんどない不必要な知識がずっしりと重荷（Head-Heavy）になってしまっただけのように思えます。

ディレクトリ（フォルダ）構造の大幅な変更

内部フレームワークが「CakePHP 3系」から「CakePHP 4系」へと一新されたことに伴い、ファイルの配置ルール（パッケージ構成）がガラリと変わりました。

• 4系まで：独自のファイル配置ルールが色濃く残っていました。
• 5系から：完全にCakePHP 4の標準的なディレクトリ構成（/config/, /plugins/, /webroot/ など）に統合されました。

4系に慣れていたWebデザイナーやコーダーでさえ「テーマファイルやアセット（画像・CSS）をどこに配置して、どこからコピーして、どう読み込めばいいのか」戸惑うのだから、単純な中小企業のホームページを作りたいだけの初心者にとってはおそらくチンプンカンプンです。

アップデートのトラブルや不安

昔ながらの「手動上書き（FTP）」が通用しなくなった不安。

• 4系まで：公式サイトから最新ZIPを落とし、FTPでファイルをサーバーに上書きして「/update」にアクセスすれば、大抵のマイナーアップデートは手動で完了できました。
• 5系から：5系はモダンなPHP管理システムである「Composer」という仕組みを内部で利用しています。そのため、ファイルを手動で適当に上書きしてしまうと、依存関係（ライブラリの組み合わせ）が崩れてシステムが完全に壊れる（画面が真っ白になる）リスクが高まりました。

コマンド操作（CLI）やComposerに不慣れなWebデザイナーや一般的なWeb担当者が、これまで通りの「手動上書き」で安全に直そうとすると、かえって事態を悪化させる可能性大。 そう思うのは、開発側もきっと同じで、ゆえに「手動上書き」の手順は公式には一切語られません。 「オートアップデート」は、確かに便利かもしれませんが、トラブルやそのリカバリーに必要以上にリスクや手間がかかってしまっては本末転倒です。管理画面を開くと「最新版があります」 と通知が出ているのに「怖くて気軽にアップデートボタンを押せない」という不安を抱えるユーザーも少なくないのではと想像します。

ではどうする？

4系まで、baserCMSがひたすら追いかけてきた「コーポレイトサイト」のユーザーにとっては、ヘッドレス化がもたらした ヘッド - ヘビー なCMSという印象しかないまま、使いたいけど使えないCMS として、利用者を減らしていくことになってしまうのではないかと危惧します。 単に4系はもうディスコンなんで5系を使ってね、だけではどうにもならない事情だと思えます。
とはいえ、これらは、5系自体の大文字のデザインコンセプトに起因することで今更どうにもならないというのであれば、その解決策は、ユーザー目線で少しでも不安や使い勝手を改善するために、マニュアルやナレッジをいかに手厚く纏めるかに尽きると思います。

もう一点。5系のキャッチフレーズが 「ヘッドレスCMS」 であっても伝統のキャッチフレーズであった 「コーポレートサイトにちょうどいい」 を下ろす（下ろしていないとおっしゃられるかもですが）必要はなく、「企業（コーポレイト）のWeb担当者（結構な初心者でも）でも簡単に運用できる仕組み」であり続けることはそう難しくありません。
というのも、ほぼ例外なく先の「Web担当者」は、サンプルテーマ「BcThemeSample」をFTPで開いてみたら、ほとんど空っぽなことに唖然とするはずです。 「ヘッドレスCMS」 を前に出したい気持ちはわかるけれど、そのこととサンプルテーマの中が空っぽなこととはちょっと意味が違うのではないかと？
オーバーライドは、そもそも5系に始まったことではないのですが、5系になって、オーバーライドの参照元は、プラグイン化された機能毎（メール、ブログ、共通のコア機能）多岐にわたってしまい、圧倒的に分かりにくくなっています。ちょっと改造したいと思っても、Webデザイナーやコーダーでさえ階層を辿るのも少々うんざりするはず。にも関わらず、BcThemeSampleは空っぽというのはどういう理由なのでしょうか。
4系がそうであったように、少なくともサンプルテーマなのだから、サンプルとして一通りのファイル群が事前に用意（あらかじめ複製）されているべきではないかと。たったそれだけのことで 「企業（コーポレイト）のWeb担当者（結構な初心者でも）でも簡単に運用できる仕組み」 にすることができるように思います。近い将来、5系のキャッチフレーズに 「コーポレートサイトにちょうどいい」 が名実ともに復活するのを切に期待しています。

そんな現状を踏まえて、個人的には、4系を否応なく使い続けざるを得ない事情の人が4系を使い続けるときに、今よりは少しでも安全に、便利に使えるように、ナレッジやプラグイン作成をささやかながら発信していこうかと考えています。