Strapi 5を極限カスタマイズ、Quillと多組織対応など

2025年9月、ヘッドレスCMSの急先鋒である「Strapi 5」は多くの開発者に様々な驚きをもって迎えられました。Strapi 4 のデータ構造は一切引き継がず破壊的変更が施され、APIから多言語化、パフォーマンスの大幅な向上です。殆ど0からの設計と行ってもよいほどシンプルな構造になりながらも、強力なアプリに変身しました。

しかし、標準搭載された「Blocks」エディタ（Lexicalベース）はモダンな設計である一方、日本のWeb制作現場で求められる「緻密な表編集」やWYSIWYGエディッターとしての文字装飾があまりにも弱すぎます。簡単なテーブル表示すらできないって・・。外国では罫線を利用した表は殆ど使われないので、きっと問題ないのかもしれませんが、日本では罫線を用いた表は見やすいページを作る上でかかせません。

また、マルチテナントにも対応していません。もちろん、コンテナを組織ごと作る事は当然できますが、strapiサーバーだけでなくPostgreSQLなどのDBまでテナント分作成しなければなりません。複数のテナントを抱えつつ、コスト削減するには向いていないのです。そこで「柔軟なマルチテナンシー」を実現できる改造など、今回多岐に渡って魔改造を施しています。

この記事では、ブログメディア「kuro.boo」を支えるStrapi 5のバックエンド環境が、どのように「魔改造」され、究極の編集体験と高い管理効率を手に入れたのか。その全貌を技術的な視点から説明します。

■ 最初にstrapi上でまともに修正できなかった・・

いや、冗談でしょ？と思う人も多いと思う。strapiは Reactベースのアプリなのですが、当然ながらReactの挙動に引きずられます。そしてstrapi5 のメイン画面が日本語に標準対応していないように、日本語における挙動管理や配慮がしっかりされていないのです。いや、英語の文章は良いのです。全く問題ありません。

原因はIMEのイベント処理とstrapiひいてはLexical（Meta社謹製）との相性と言っても良いかもしれません。自分は macOS で開発や記事を書いているので、もしかしたIME変えればいけるのではと思い、Apple 標準から、Google Japanese Inputに変え、かわせみを購入し3つのIMEを試しても結局ダメでした。ようするにキーの入力時にIMEだけに渡せばよいものを余計なイベントまでstrapi側で拾ってしまって、カーソル位置が飛びまくります。なので最初はzedなどで文章を打ち込んでからコピペして投稿していました。面倒くさい・・

■ 複数の画像に対応していない・・

え？マジですか？そんな学術ブログじゃあるまいし、今どき文章だけとか・・もちろん、カバー画像は出ますよw。そこで最初のチャレンジは以下のpluginを入れてみました。

TipTap

そう、巷では非常に評判が良いのでとても期待して入れた所、確かに複数画像は扱える・・。扱えるけどサー、文章ブロック、画像設定、文章ブロック、画像設定とか別々の入力フィールドで毎回そのブロックを追加してあげないといけないって、いつの時代のUIだよ！というお粗末な実装だったのです。WYSIWYGじゃなかったの？・・、これには驚きを通り越して悲しみがやってきました。それと同時に、Dropbox Paper って意外と凄かったんだな〜と、全然違う意味で関心していました。（黒兎はDropbox Paperを良く使っています）

■ 決断：これはLexicalもTipTapもダメだ。

Strapi 5が標準採用するLexicalは、Meta社（旧Facebook）が開発する高機能なエディタフレームワークです。しかしJSONベースの厳格なデータ構造は、従来のHTMLベースの運用に慣れた編集者にとって「融通が利かない」と感じられる場面が多々あります。そしてTipTapも多画像が扱えるだけましですが、全くWYSIWYG的ではなかったのです。そこで黒兎は調べに調べてQuillにたどり着きました。（５分くらい？w）現在v2になりかなり自由度が高そうです。期待大です。

■ あれ？表作れないの？

インストールするとQuillの機能はWYSIWYG的な実装がされており非常に良い見た目でした。しかし・・、あれ？表作れない？。そうです。Quill 単体では日本人には必須の罫線の表が組めないのです。いや誤解が内容に言っておくと表を表示することは、できるにはできるのです。しかし表に必要な簡単な列の追加や背景色の変更、罫線の位置のスムーズな変更ができないのです。何でカナー・・、日本人の罫線に対する愛情はそんな中途半端なおまけ実装では役に立たんのですよ。偉い人にはわからんのです。という感じで、何とかQuillでまともに表が出せないかと探しに探して必死の思いでたどり着いた（５分）のがQuill-better-table です。これ本当にすばらしいです。多少の不具合がありましたが（1日格闘しましたが）無事にQuill上でテーブルが使えるようになりました。Dropbox Paper で作った表付きの文章もそのままコピペで貼り付けられます。実はQuillはデータを、JSON形式ではなくHTMLで持っているから、WEBページの表でも何でも貼り付けられます。超便利です。

これによって、IMEの変な挙動も一緒に直して下記の画像のような strapi の編集画面になりました。文字装飾の多い事w

めっちゃ、WYSIWYG的なツールになりました。サードパーティ製のライブラリ「quill-better-table」を統合したことにより、右クリックメニューによる行・列の動的追加・削除、セルの結合、ヘッダーの個別スタイリングなど、Strapiの管理画面上でシームレスに動作します。重要なのは、これらの編集内容がStrapiのAPIを通じて「正しく」保存され、フロントエンド（Astro）で再現されるのです。

■ 複数画像も貼り付けたい・・

そうなってくると、人間欲が出てくるものです。こんどは複数の画像をDropbox Paperのように、貼り付けたいと考えるわけです。そこでAIと一緒に考えたのが、エディタ上に画像を貼り付けた瞬間に、裏側でStrapiのアップロードAPIを叩き、メディアライブラリへ即座に登録。これで、Drop&Dragで画像ファイルを貼り付ける事も、Cut&Paster でクリップボードの画像も貼り付けられ、当然ながらエディタ上部の画像アップロードパネルを使っても複数の画像を貼り付けられるように改造したのです。これによってかなり記事制作の手間は削減されました。※但しDrag&Dropで画像を貼り付ける場合、サイズオーバーの場合はエラーが表示されず貼り付けられないので、少しわかりずらい。

■ 多数の組織でも使いたい

そうなってくると、自分が管理している複数のサイトや組織を一つのStrapiで管理する場合、通常は Strapi の「Multi-Tenant」機能や複数のインスタンス立ち上げを検討します。しかしそれでは組織ごとにDBコンテナを起動することになり、コストがどんどん増えていきます。そこで、strapiのDB操作において「同一のDBインスタンス内で接続スキーマ（DATABASE_SCHEMA）を切り替える」という変形型多組織対応を採用しました。これによって組織ごとに strapi は別になり管理がすっきりしながら、DBは1つでコスト削減ができるという仕組みになりました。そもそも、strapi には多組織のための権限管理などの仕組みは存在せず、strapi まで一つにするとかなりの運用負荷及びにトラブル発生が考えられるからです。そのため安全に運用するためにstrapi用のコンテナは別に立ち上げるのは必然でした。

■ strapiの存在価値を否定するような開発時専用CMS設計

誤解が無いように最初に説明しますが、strapi は非常に素晴らしいソフトです。特に多人数の人間が編集作業を行うのであれば、strapi はサーバーとして常時起動しておく必要があります。しかし個人のブログや頻繁に更新がない組織ではどうでしょうか？普段参照にしか使わないstrapi＋Databaseを起動しておく経済的損失、公開サーバーが増える事におけるセキュリティリスク。それらを考えデプロイまでの仕組みを変更することにしました。

1. 記事作成時にstrapi起動、記事を作成する。
2. developビルドで、strapi のコンテンツを astro ベースの静的ページに変換し、画像データはデプロイ領域にコピーして画像リンクを張り替える。
3. strapi を停止。作成された静的ページを、Cloudflare の Pagesなどに投稿画像ともども一式Deploy

さてこうなるとどうなるか。まず外部の公開サーバーは、Cloudflareのエッジサーバーのみ。なので全ページ表示が静的なため超高速になり、CDN対応にしておけば更に高速化され、strapi サーバーも、PostgreSQLなどの db サーバーも公開されず、そもそも起動もしていないのでコストも全くかからない素晴らしい仕組みになるのです。

これらの強力な構造を支えているのは、Strapiを「公開サーバー」としてではなく、「開発用アセットビルダー」として位置づけるアーキテクチャです。本プロジェクトでは成果物だけをCloudflare Pagesなどのエッジネットワークで配信しているのです。kuro.boo の実際の環境ではstrapiの起動・停止が面倒なので費用のかからないローカル環境で strapi を起動したままで利用しています。

■ カスタマイズ項目の比較表

■ 結論：道具を自分に合わせる勇気

他にも１文字でも修正するとその日の日付で再登録扱いされるため、古い記事がトップに表示してしまう問題があり、編集項目に新しく公開日という項目を追加し、表示順はこの公開日でソートして意図通りの表示順に変えたりと、色々細かい最適化も行っています。

Strapi 5は素晴らしい基盤ですが、そのまま使うのが正解とは限りません。もちろんバージョンアップ時に泣くかもしれませんw、しかし逆にカスタマイズが容易な懐の深さが strapi の魅力でもあります。プロジェクトのニーズに合わせてソースコードレベルで介入し、独自の拡張を施すことで（今回の魔改造では特に）、本当に「愛着の持てる執筆環境」が誕生しました。kuro.booの試練は、ヘッドレスCMSが持つ本来の柔軟性を証明する、一つの好例となるかもしれません。

■ 出典

・Strapi 5 Documentation

・Quill - Your powerful rich text editor

・quill-table-better (GitHub)