Q.EmDashはStudioからの移行先として使えますか？本番運用しても大丈夫ですか？

問い合わせフォームから届いた内容を自動でスプレッドシートに書き溜めていた場合、移行後にその運用が途切れてしまわないか心配になりますね。StudioのGoogleスプレッドシート連携は、フォーム機能で送信された回答結果を自動的にシートへ追記してくれる便利な仕組みでした。

手軽な方法の一つは、Google フォームをサイト内に埋め込むやり方です。Google フォームは回答の保存先として新規または既存のGoogle スプレッドシートを直接指定できるため、集約の仕組みをそのまま維持できます。デザインの自由度は下がりますが、追加のコード開発を行わずに運用を継続できる利点があります。

もう一つの方法は、EmDashのフォームプラグインや外部連携を活用する構成です。EmDashには公式のフォームプラグインである「@emdash-cms/plugin-forms」が用意されており、フォームの作成、回答の収集、メール等による通知送信に対応しています。ただ、回答は通知で受け取る形になるので、シートへの自動転記を前提にはしないでください。EmDashのプラグインは、許可する接続先を宣言すれば外部のAPIへHTTPリクエストを送れます。そのため、回答をシートへ送るプラグインを作ることもできますが、作ったあとの手入れも自分たちで持つことになります。

シートを見ながら問い合わせに返信している運用なら、Googleフォームに切り替えるのがいちばん手間が少ないでしょう。

予約の受付を、EmDashの中で一から作る必要はあるのでしょうか。予約サービスを外から組み合わせる方法があります。

たとえば、Airリザーブを導入する際は、アカウントを作成したあとに予約メニューや料金を設定し、予約受付ページを公開したうえで自社サイト側へリンクを設置します。中小企業基盤整備機構の紹介ページでも、対象業種として理容・美容業が挙げられていました。メニューの設定はAirリザーブの管理画面で行うので、サイトを作り直す作業とは分けて進められます。

使い方はふたつあります。ひとつは、Airリザーブが発行する予約画面のURLを、サイトにリンクとして貼る方法です。もうひとつは、予約カレンダーをサイトのページ内に表示させる方法で、発行された埋め込みコードをサイトのソースに書き込みます。

ただし、発行されたコードは改変せずにそのまま貼り付ける仕様となっており、Airリザーブの埋め込み仕様でもコードの書き換えを行わないよう定められています。また、特定の施術メニューだけに絞り込んでカレンダーを表示させることには対応していません。カット専用のページを作ってそのメニューだけ出す、といった使い方は難しいということです。

EmDashはAstro上で作られたTypeScript製のCMSなので、埋め込みコードはAstroのテンプレート側に入れることになります。EmDash上での動作は、公開前に予約画面が開くところまで試してください。リンクを貼る方法なら、ボタンを置くだけなので作る手間はぐっと少なく済みますね。

作品を数点載せたポートフォリオを、Studioで個人公開している場合を考えてみます。EmDashに移ると、作品を載せる作業そのものより、裏側の手入れのほうが増えます。もっとも、手軽さだけを比べるなら、画面上の視覚的な操作だけで更新できるStudioのほうが圧倒的に手軽ですね。

それでもEmDashを選ぶ価値があるのは、モダンなフロントエンド開発環境を手に入れながら、コンテンツ管理を切り離して運用したいときです。EmDashはAstro向けのCMSとして設計されており、開発者がAstroでサイトを実装し、日々の実績記事や作品解説は管理画面から直感的に更新できる役割分担になっています。Cloudflare上に公開する場合、Workersでアプリを動かし、データベースにD1、メディア保存先にR2を使う構成が一般的です。

ただし、個人運用ではインフラの保守責任が自分自身にかかってきます。EmDashを自前で運用する場合、データベース、メディア保存先、バックアップ、バージョンアップ、管理画面を提供するアプリケーション本体の維持を運用者自身が担わなければなりません。反対に、作品の入れ替えが年に数回ほどで、コードに触れる予定もないなら話は変わります。作り直しの時間とバックアップや更新の手間を足すと、移る理由は薄くなるでしょう。

EmDashはCloudflareのサービスに依存しており、他のサーバー環境では動かせないのでしょうか。開発元がCloudflareであるため専用ツールのように見えがちですが、実際には一般的なNode.jsサーバー環境でもセルフホストできる仕組みです。たとえば、データベースにSQLite、ファイルの保存にローカルストレージを使う構成です。

Dockerを使ってコンテナとして動かす手順も用意されており、Dockerfileの作成からイメージのビルド、永続ボリュームを割り当てた起動、Docker Composeでの管理まで公式にカバーしています。ただし、この公式の例は自分のサイトをビルドするためのものです。他の人が配布しているイメージを使う場合とは別の話。

さらに規模が大きくなり、複数のEmDashインスタンスでデータベースを共有したいケースにも対応できます。公式ガイドでは、共有データベースとしてPostgreSQLまたはlibSQLを使う構成が示されています。SQLiteは1台で動かす構成向けと考えておけばよいでしょう。

プラグインの隔離も、Cloudflare専用ではありません。Node.js環境であってもプラグインの隔離実行に対応しており、Marketplaceやsandboxedで指定されたプラグインは、sandbox-workerdランナーを介してworkerdの子プロセス内で安全に実行されます。セキュリティの仕組みを保ったまま、自分のサーバーや好きなホスティングを選べますね。

Cloudflare上で、レジストリから入れたサンドボックス型のプラグインを使う場合を例にします。プラグインを隔離して動かすDynamic Workersは、Workers Paidプランでしか使えません。

Workers Paidプランは、1アカウントごとの月額の最低料金に、含まれる枠を超えた分の従量料金が加わる仕組みで、金額はWorkersの料金表で確かめられます。作成数は、WorkerのIDとコードで見分けて日ごとに数えます。Dynamic Workersの課金対象の利用数は、Cloudflareの管理画面の「Workers & Pages > Overview」で確かめられます。

一方、マーケットプレイスやレジストリのプラグインも、sandboxed に入れるプラグインも使わないなら、設定から sandboxRunner と LOADER バインディングを外せます。隔離機能を使わないシンプルな構成であれば、追加コストを抑えた運用も可能です。

プラグインそのものの条件も見ておきましょう。EmDashのプラグインはEmDashとコードを共有せず、ライセンスは作者が自由に決めます。本番に入れる前に、プラグインごとのライセンスを確かめてください。