移行先の比較更新日
#更新頻度によって、Studioからの移行先はどう選べばよいですか？
「お知らせを毎日のように出すサイトなのに、静的サイトへ変えて更新が滞らないだろうか」と悩む担当者は少なくありません。でも、ヘッドレスCMS（記事を管理する画面だけを持つCMS）で記事を公開すると、その操作を合図にサイトを組み立て直して公開する設定が組めます。Cloudflare PagesはDeploy Hooksに対応していて、microCMSのWebhookからビルドを始められます。更新が多いサイトでも、担当者が触るのは記事の入力画面だけ、という形にできるわけです。ただ、ボタンを押してから自動ビルドが完了して画面に反映されるまでには、わずかな待ち時間が生じます。
回数より先に考えたいのは、誰がどこまで操作するかです。StudioにもWordPressにも、ユーザーごとに操作できる範囲を分ける権限の設定があります。たとえばWordPressのEditor権限を持つユーザーは、他の人が作成した投稿を含めて公開や管理ができます。複数の人が記事を書き、1人が確認してから出す体制なら、この権限の分け方で比べたほうが選びやすいでしょうね。
おおまかには、更新がほとんどないサイトはCMSを使わない静的サイト、複数人でよく書くサイトは権限を細かく分けられるCMSか、ヘッドレスCMSと自動公開の組み合わせ、という分け方になります。ただし自動公開は最初の連携設定が欠かせないため、その作業を社内と外部のどちらが受け持つかも同時に決めます。
#静的サイトはなぜ攻撃されにくいのですか？
サーバーにファイルを置くだけの静的サイトは、どのような理由から不正アクセスの標的になりにくいのでしょうか。公開しているサーバーの上で動く処理が、ほとんどないからです。
WordPressのような動的なCMSでは、利用者がページを開くたびにサーバー上のプログラムがデータベースへ問い合わせて、画面用のHTMLをその場で組み立てます。この通信経路や管理プログラムに欠陥があると、データベースの情報を抜き取られたり、悪意のある命令を実行されたりする危険が生まれます。これに対して静的サイトは、事前に作成されたHTMLや画像ファイルをそのままブラウザへ届けるだけです。閲覧者向けのサーバーにデータベースや複雑な処理プログラムが存在しないため、攻撃者が入り込める隙間そのものが大幅に少なくなります。
とはいえ、対策がいらないわけではありません。静的サイトでもHTTPSは欠かせず、GitHub PagesではHTTPSを強制する設定が使えます。
ヘッドレスCMSで記事の管理を切り離した場合も、CMSとつながるAPIには、アクセスできる相手を絞る設定や暗号化した通信が引き続き要ります。ヘッドレスCMSを使うことと静的サイトにすることは同じではないので、移行先がどの配信方式を採るのか、見積もりの段階で聞いてください。
もうひとつ気にかけたいのが、外部に預けるデータです。Studioの不正アクセス事案では、保存されていたフォームの送信内容と、外部サービスのAPIキーやトークンが、流出した可能性のある情報に含まれています（事案のお知らせ）。静的サイトに移っても、フォームの受付や外部連携を別のサービスに任せるなら、そのサービスがデータをどう守っているかは同じように見ておきたいところです。
#社内にエンジニアがいない場合、どのCMSへ移行すればよいですか？
「エンジニアがいないから、更新しやすいCMSに移りたい」。ただ、移行先によって社内に残る作業はかなり違います。
知名度の高いWordPressは、管理画面が日本語で操作しやすいため有力候補に挙がります。ただし、使い続けるには本体やプラグインを定期的にアップデートしなければなりません。WordPress公式サポートのWordPressの更新手順では、安全のために本体を常に最新版へ保ち、更新作業の前にはサイト全体のバックアップを取るよう案内されています。更新によってデザインが崩れたりプラグインが動かなくなったりした際、自力で原因を突き止められないチームだと、運用の負担が重くなりやすいですね。
それではヘッドレスCMSはどうかというと、記事の管理画面と画面の表示側が完全に分かれているため、最初の表示画面を作る段階で専門的なフロントエンド開発とAPI接続の作業が欠かせません。社内にエンジニアがいなければ、最初の表示画面とAPI接続をどこに任せるかを先に決めておきます。
その点、Studioのレンタルサーバーについてのヘルプのとおり、Studioは無料プランを含むすべてのプランに公開用のサーバーが付いていて、レンタルサーバーを別に借りずに済みます。サーバーの面倒まで社内で抱えたくないなら、Studioに残る選択もまだ外せません。
ちなみに、WordPressを静的化して公開する方法もあります。CloudflareのWordPress静的化手順ではSimply Staticというプラグインを使いますが、無料版には自動更新がなく、内容を変えるたびにZIPを取り直して公開し直す流れです。
#更新が少ないサイトならCMSを使わない静的サイトで十分ですか？
CMSを使うサイトと、HTMLのファイルを置くだけの静的サイトでは、更新するときの手間が違います。CMSは、同じレイアウトの記事を定期的に追加したり、執筆者が分担して原稿を投稿したりする場面で力を発揮するツールです。静的サイトは、文章を一行直すだけでもファイルを書き換え、公開先へ反映し直します。静的サイト生成ツールを使う場合も、変更のたびにページを作り直す工程（ビルド）が入ります。
GitHub Pagesなら、自分で書いたHTMLファイルをそのまま公開でき、生成ツールは使わなくてもかまいません。会社案内のように載せる内容がほぼ決まっていて、すぐに反映させたい更新がないサイトなら、静的な作り方がよく合います。データベースの保守管理やセキュリティパッチの適用作業から完全に解放されるのも、運用上の大きな魅力ですね。
では更新が少なければそれで足りるかというと、更新する人がHTMLを触れるかで答えが変わります。変更がまれでも、担当者がファイルを編集できなければ、そのたびに外部へ頼むことになるでしょう。
また、サーバー側で動く問い合わせフォームや会員認証などはそのまま動かないため、外部サービスを組み合わせる下準備が要ります。更新の頻度だけでなく、修正作業を誰が担当し、どんな機能を残したいのかを書き出して、CMSを外すかどうかを判断しましょう。
こんな聞き方も
- 更新が多いサイトは静的サイトに向いていないのですか？
- 静的サイト 更新 頻度 向かない
- 更新 頻度 少ない サイト 移行先
- 静的サイト cms 不要
- 更新が少ないサイトならCMSを使わない静的サイトで十分ですか？
- 静的サイト 攻撃 されにくい
- 静的サイトはなぜ攻撃されにくいのですか？
- 非エンジニア cms どれ
- 移行先 cms エンジニア いない
- 社内にエンジニアがいない場合、どのCMSへ移行すればよいですか？
- framer 日本語 対応
あわせて知りたい（関連する疑問）
Q静的サイトへの移行は、どんな内容になりますか？
「Studioで作ったサイトを静的化したいけれど、デザインの作り直しやデータの移行をどう進めればよいのかわからない」という相談は珍しくありません。静的サイトへ移すときは、いまのサイトを見ながら、ページをHTML・CSS・JavaScriptで組み直すのが基本の流れです。作ったファイルはGitHubなどのリポジトリで管理し、公開先とつないでおくと、直すたびにファイルを手で上げ直さずに済みます。
移行後に、誰がどの手順でページを直すのかも先に決めておきます。更新の手順を書き残しておけば、担当が替わっても迷わずに済みます。
移す前に、いまのサイトのページ、フォーム、CMS、外部連携のうち、何を残すかを書き出しておきましょう。会員機能や予約、決済のようにサーバー側で動く機能は、外部のサービスに置き換えるか、移行先で別に作るかを1つずつ決めます。ドメインやDNSの切り替えも、作業の段取りに入れておきます。
QFramerは日本語の管理画面やフォントに対応していますか？
海外発のノーコードツールとして注目を集めるFramerですが、日本のWeb担当者にとって操作画面やフォントの使い勝手はどうなのでしょうか。フォントは日本語に対応していますが、管理画面は英語が中心です。表示言語を日本語へ切り替える設定があるかは、使い始める前に実際のエディタ画面で確かめてください。ツールの機能自体は直感的ですが、メニューや各種プロパティの名称が英語で並ぶため、英語の管理画面に不慣れなスタッフが操作する現場では、最初の段階で戸惑いが生じるかもしれません。
一方で、Webサイト上に表示する日本語テキストやフォントの対応は十分に整っています。さらにフォント面ではGoogle FontsやFontshareの書体を標準で呼び出せるようになっています。
使いたい書体が一覧にないときは、カスタムフォントの追加からファイルを上げられます。
ところで、紛らわしいのが、翻訳機能のLocalizationです。対応言語に日本語（ja）が入っていますが、これはサイトの内容を各言語に訳して出すための機能で、管理画面が日本語になるわけではありません。
Q静的サイトでもお知らせを自分で更新できますか？
たとえば、microCMSとCloudflare Pagesを組み合わせる形があります。Pages側でDeploy Hookを作り、フック名とビルドするブランチを指定しましょう。発行されたURLをmicroCMSのWebhook設定に登録すれば、記事を公開・更新したときに、サイトの組み立てと公開が自動で始まります。担当者はmicroCMSの画面でお知らせを書くだけです。
通知を送るタイミングは、項目ごとに選べます。管理画面での公開・更新とは別に、レビューを通した公開と予約公開にも項目があり、管理画面の項目だけをオンにしても、この2つは通知されません。予約投稿を使うつもりなら、予約公開の通知もオンにしてください。
もうひとつのやり方として、GitHubと直結するGitベースのCMSを使う方法もあります。Decap CMSは、標準の設定だと管理画面で記事を保存した時点で、公開用のブランチへ変更をそのまま記録します。あとはNetlifyなどの配信サービスがその変更を検知して、自動でサイト全体を更新してくれる仕組みです。どちらのやり方でも、最初の接続設定を済ませれば、日々の更新は管理画面への入力だけで公開まで進みます。ブログ投稿画面のような分かりやすいエディタに文字と写真を入れるだけで済むため、社内の広報担当者が自分たちのペースでお知らせを発信し続けられますね。
逆に言えば、CMSを付けただけでは記事は自動で公開されません。更新の通知とビルドをつなぐ設定が欠かせず、ここを移行の作業範囲に入れておかないと、記事を書いてもサイトに出ない状態になります。
Q静的サイトにするとフォームは使えなくなりますか？
「静的サイトへ移行するとサーバー側のプログラムが動かないと聞くけれど、問い合わせフォームまで使えなくなってしまうのか」と心配する声は少なくありません。フォームの送信処理を外部のサービスに任せれば、静的なHTMLのページでもフォームは使えます。FormspreeやNetlify Formsなら、送られた内容を指定したメールアドレスで受け取れます。
Netlify Formsの場合、設定はこの順です（Netlify Formsの設定手順）。
- サイトの設定でフォームの検出を有効にする
- HTMLのフォームにnetlify属性を付けてデプロイする
- Forms > Submission notificationsからAdd notificationを選び、メール通知を追加する
さらに自由なメール配信を行いたい場合は、Cloudflare WorkersとResendを組み合わせて独自の送信処理を作るCloudflareのResend連携手順も用意されています。ドメイン認証やAPIキーの設定など初期の構築作業は増えますが、デザインや返信メールの内容を細かく整えられますね。ただしこれはメールを送る部分だけで、フォームの受付処理は別に作ります。エンジニアがいないなら、FormspreeやNetlify Formsのほうが扱いやすいでしょう。
Studioで使っていたフォームは、そのままでは持ち出せません。Studioの書き出し仕様では、サイトのソースコードは書き出せませんが、フォームの回答はフォームダッシュボードからCSVで保存できます。Studioの契約を止める前にダウンロードしてください。
この内容をChatGPTで相談
