MITLicense|OSS

3Dvenue-CMSとは

3Dvenue-CMS 開発ストーリー

開発者
こんにちは。このページをご覧いただき、ありがとうございます!
私は、華やかなインターネットの世界の裏側で、何十年もの間、黙々とコードを書き続けてきた65歳のベテランWebシステムエンジニアです。

Web黎明期から、Perl、ASP、Java、AppleScript、VB、C++、PHPなど、さまざまな言語を独学で学んできました。HTML、CSS、JavaScriptも、すべて手書きで作ってきました。
30年ほど前に私が書いたプログラムの中には、驚くことに今でもトラブルなく動き続けているものがあります。それは、シンプルで、軽量で、見通しの良いコードを書くことを大切にしてきたからだと思っています。この考え方は、今でも変わっていません。

なぜ、CSSをそのまま書けないんだろう?

さまざまなCMSを使っていて、私がよく疑問に感じていたことのひとつが、CSSの扱い方でした。
多くの場合、スタイルの設定はプルダウンメニューや数値入力に限られていて、単位もpxしか使えないことがよくありました。
clamp()、calc()、min()、max()、CSS変数といったCSSの機能を使いたい場合には、わざわざ別のCSSエディターを開かなければなりません。ページのデザインを実際に見ながら、なぜその場でCSSを直接書けないんだろう?と、ずっと疑問に思っていました。

Webサイトの移設、どうしていますか?

Webサイトを移設するたびに、私はいつも同じような作業を繰り返していました。
WordPressやMovable Typeを使っていると、サイトの移設は「どうしてこんなに手間がかかるんだろう?」と感じることがよくありました。

まずデータベースサーバーを準備して、データをエクスポートしてインポート。場合によっては移設用のツールを使うこともあります。ドメインが変われば設定を変更し、別のディレクトリへ移動するだけでも、さらに設定が必要になることがあります。

私だけかもしれませんが、毎回すべての手順を覚えていられるほど記憶力が良くありません。サイトを移設するたびに、以前調べたはずのことを、またWebで検索していました。
だから私は、もっと簡単に移設できるCMSを作りたいと思いました。

別のドメインでも、ドキュメントルートでも、何階層も下のサブディレクトリでも、置いた場所でそのまま動いてほしい。
インストールしたその場所が、その瞬間からCMSの新しい基準位置になる。
たとえばFTPでディレクトリAにアップロードしたあと、「やっぱりディレクトリBにすればよかった」と気づいたとします。
そんなときは、ディレクトリ名を変更するだけで、その場所ですぐにCMSが動き始める。そんな仕組みにしたいと考えました。
移設ツールは必要ありません。

設定変更も必要ありません。

フォルダを移動するだけです。

なぜ3Dに対応したのか?

CMSからGLBモデルを直接アップロードして、そのままWebページに表示できるようにしたいと思いました。Three.jsは2010年から存在していますが、私の感覚では、Webでの3D表現が本格的に注目され始めたのは、コロナ禍でメタバースが大きな話題になった頃からだったように思います。
時々、こんなことを考えます。
「Webサイトは、いつまでもHTMLだけではないかもしれない」
いつかWebサイトを見るということが、単にページを読むことではなく、そこにある何かを「体験する」ことになっていくのかもしれません。
最近では、Web 5.0は「体験」が中心になるのではないか、そんなことを考えています。

それが、CMSに3D機能を組み込みたいと思った理由のひとつです。
現在は、GLBモデルを表示するだけのシンプルな機能です。

でも、最初はそれで十分だと思っています。

ライティングをもっと良くしたり、操作機能を追加したり、さらに高度なものを作ったり。誰かがこの機能を発展させてくれたら、どんなものが生まれるのか見てみたいと思っています。
そう思うようになった理由のひとつは、数年前にさかのぼります。
私は以前、展示会ブースのシミュレーターを作ったことがあります。
その開発をしながら、ずっと考えていました。

「これからWebの3Dは、もっと重要になっていくんじゃないか」
もともと、この機能は半分遊びのような感覚で作り始めたものでした。
でも、途中でひとつ気づいたことがあります。

Webサイト上で3Dモデルを見てもらいたいだけなら……
もう外部サービスを使う必要はないんじゃないか。
だからこそ、この機能をCMSそのものに組み込みたいと思ったのです。

原点に戻る

これは、私自身が快適に使えるCMSを作ろうと思った背景にある話です。 なぜ、このCMSはここまで「軽量」であることにこだわっているのか。 そして、なぜ私はこのCMSを作ろうと思ったのか。 30年間Webに関わってきた経験と、現在のインターネットを見ながら、その理由を書いてみたいと思います。

30年前、「軽いこと」は正義だった

今から30年ほど前、インターネットが普及し始めた頃は、ダイヤルアップ接続が当たり前でした。Web制作者にとって大きな課題のひとつは、「どうすれば少しでも速くページを表示できるか」でした。

当時と比べれば、現在のコンピューターは何千倍も高速になり、通信環境も桁違いに速くなっています。それでもWebを構成するHTML、CSS、画像、JavaScriptといった基本的なものは、それほど大きく変わっていません。

本来なら、現在のWebサイトは一瞬で表示されてもおかしくないはずです。 ところが、現実は少し違う方向へ進みました。
インターネットを流れる情報は、今も昔も「パケット」という単位でやり取りされていて、その基本的な仕組みはそれほど大きく変わっていません。

現状を見ていると、せっかく高速道路が整備されたのに、そこへ大量の車、つまり大量のパケットが押し寄せ、再び渋滞を引き起こそうとしているようにも見えます。

そもそもTCPは、データを確実に届けるために、届かなかったデータがあれば再送する仕組みを持っています。道路をどれだけ広くして高速化しても、そこを走る車そのものが増え続ければ、いつか道路は混雑します。

いずれ、今よりも効率よくデータ通信ができる仕組みが誕生するのかもしれません。

しかし、仮にそうなったとしても、やり取りするデータの量そのものが増え続ければ、それに伴って必要となるエネルギーも増えていくような気がするのです。

それが良いことなのか、悪いことなのか、私にはわかりません。

ただ、今の私たちにできることのひとつは、
「通信量そのものを減らすこと」なのではないか。

私は、これこそが次世代への責任のような気がしてならなのです。

便利になるほど、Webは重くなっていった

CMSが広く使われるようになるにつれて、Webサイトの構造は多層化し、複雑になっていきました。 昔なら表示するだけで何分もかかったような高解像度画像も、今では当たり前のように使われています。 パララックスや大きなアニメーションなど、操作性の向上とは直接関係のない演出も増えました。 目立たせるために文字を赤くしたら、いつの間にかページ全体が真っ赤になっていた。そんな感覚に近いのかもしれません。 高解像度の画像そのものが悪いわけではありません。 ただ、その美しさと引き換えに失っているものもあります。 多くの場合、わずかな画質の違いより、表示速度のほうが大切なのではないかと私は考えています。

ユーザーが求めているのは、高解像度よりも速さ

この30年間で、Webを見るための中心的なデバイスはPCからスマートフォンへと変わりました。 ディスプレイも高密度化し、非常に美しい画像を表示できるようになりました。 しかし同時に、ユーザーがWebに求めるものも変化しています。 多くの人が求めているのは、最高画質の画像を見ることよりも、「知りたい情報へ早くたどり着くこと」ではないでしょうか。 どれほど美しい写真でも、多くのユーザーは数秒でスクロールして次へ進みます。 本当に重要なのは、目的の情報へどれだけ早く到達できるかだと思っています。

AI時代の「1秒」は、世界規模では巨大になる

AIの普及によって、世界中を流れるデータ量はさらに増えています。 Webサイトを配信するとき、通信量の多くを占めているのはHTMLではなく画像です。 画像形式を変えるだけでも、ページの表示時間を1秒、場合によっては2秒短縮できることがあります。 世界規模で考えれば、その1秒は非常に大きなものになります。 軽量化は単なる好みではなく、これからのWebに必要な考え方のひとつだと思っています。

軽量化の鍵になる画像フォーマット

このCMSでは、標準の画像形式としてWebPを採用しています。 AVIFはさらに軽量で、将来的には標準的な形式になっていく可能性があります。 ただし、MITライセンスで公開するCMSとして、利用者のサーバー環境を限定したくありません。 PHP 8.1以下ではAVIF変換が利用できない環境もあり、現在でもPHP 7.xや8.0が稼働しているレンタルサーバーがあります。 AVIFを必須にしてしまえば、利用する側に余計な負担をかけることになります。 そのため現時点では、実用性を考えてWebPを採用しています。 サーバー環境が十分に整った段階で、AVIFへの移行を考えています。

HTML最適化とエディター設計の苦労

HTMLの最適化は、このCMSを作るうえで特に苦労した部分のひとつです。 不要な入れ子をできるだけ減らし、可能な限りシンプルな構造にしたいと考えました。 その中でも、最も難しかったのがエディターです。 画像についてはfigure要素が必要になるため、section → .inner → div → figure → imgという5階層になります。 それ以外については、基本的に3階層以内に収めています。 この構造を選んだ理由は、Version 2.0になると分かってくると思います。 その目的がなければ、さらに2階層まで減らすこともできました。 最初に作ったエディターは使い勝手に納得できず、公開直前にほぼ全面的に作り直しました。 実際のクライアントサイトで使ってみると、自分でも驚くほどスムーズに作業できるようになっていました。 HTMLやCSSを理解している制作者にとっては扱いやすいCMSだと思いますが、初心者には少し難しく感じるかもしれません。 このCMSは、一般ユーザー向けではなく、Web制作者のために作っています。

PageSpeed Insightsは、
Googleからの「軽量化しよう」というメッセージ

このCMSは、PageSpeed Insightsを強く意識して開発しています。 私がコンピューターを使い始めた頃のPCは、NECのノート型で、メモリは2MB。その後4MBへ増設しました。 HDDは40MB、ディスプレイはモノクロでした。 そんな環境でも、アプリケーションはフロッピーディスク1枚に収まりサクサクと動いていました。
現在のコンピューターは当時とは比較にならないほど高性能になりましたが、OSやアプリケーションも同じように巨大になりました。 だから私は、「CMSをどこまでシンプルにできるだろう?」ということに挑戦してみたくなりました。 私はPageSpeed Insightsを、Googleからの「世界のインターネットトラフィックを減らしていこう」というメッセージのひとつとして捉えています。 世界中で膨大な数の人がWebを利用していることを考えれば、一人あたりの1秒という小さな差も、世界規模では非常に大きなものになります。

実際の現場で、このCMSの方向性を確信した

最近、中小企業の経営者が集まる会合に参加する機会がありました。そこで「自社のWebサイトは誰が管理していますか?」と聞いてみました。 すると、全員が外部の制作会社などに任せているという回答でした。
中には20年ほど前に作られたHTMLのままで、スマートフォンにも対応していないWebサイトもありました。 自分たちでは更新できないため、そのまま時間が止まったような状態になっています。 その話を聞いたとき、「このCMSが目指している方向は間違っていなかった」と感じました。

このCMSが、あえて搭載しなかった機能

このCMSには、顧客管理、販売管理、メールフォーム、アクセス制御といった機能を搭載していません。
「それではCMSとして弱いのでは?」と思われるかもしれません。 私自身、そう思うこともあります。
でも、それらは本当にCMSそのものに必要な機能なのでしょうか。

顧客管理には専用のシステムがあります。販売管理にも専用のシステムがあります。メールフォームはサーバー環境によって仕様が異なりますし、WordPressでも多くの場合プラグインを利用します。 それなら、それぞれの環境に適したものを使えばいい。 そう考えました。 このCMSは、何でもできるCMSを目指していません。Web制作をシンプルに、速く、そして自由にすることを目指しています。 必要なものは利用する人が自由に追加できます。軽量なWebサイトを本気で作りたい制作者のためのCMSです。 使い続け手を加えていくうちに少しずつ「あなた自身のCMS」になっていく。

1MB以下のCMSで、本当の軽さを体験してみてください。 皆さんからのレビューを楽しみにしています。