静的サイトの小さなお知らせを更新する方法を考える

小規模なWebサイトで「お知らせだけは更新したい」と言われたとき、どのような方法にするか迷うことはないでしょうか。

このような更新機能で、まず候補に挙がるのはWordPressです。ただ、WordPressを導入すると、定期的なアップデートやメンテナンスも必要になります。更新頻度が低く、扱う情報も少ないサイトでは、WordPressが最適とは限りません。

更新方法を考えるときは、担当者が無理なく操作できるか、新しいサービスへの登録をお願いできるかといった点も確認します。そのため、どの方法が合うかはお客さんによって変わります。

自分自身、こうした相談を受けるたびに、どの方法がよいか比較して検討しています。そこで今後の判断材料としても使えるように、静的サイトに小さなお知らせ欄を設ける場合の選択肢と、構成を決める前に確認しておきたいことを整理します。

先に結論

今回想定するような小さなお知らせでは、次の4つを検討します。

HTMLを直接更新する

更新が年に数回なら、制作者へ都度依頼する方法が有力です。担当者向けの更新マニュアルを用意する方法もありますが、HTMLを扱う知識と、手間をかけて更新する理由が必要になります。

Googleスプレッドシートで更新する

スプレッドシートの内容をApps Scriptから取得し、JavaScriptで表示する方法です。複数人から情報を受け付ける場合は、Googleフォームも組み合わせられます。

RSSで別媒体の記事を表示する

noteやはてなブログですでに発信している記事を、RSSから取得して表示する方法です。同じ情報をサイト用に入力し直す必要がありません。

SNSの投稿を埋め込む

X、Instagram、TikTokなど、普段から更新しているSNSの投稿を表示する方法です。投稿しやすい反面、表示や利用条件は外部サービスの仕様に左右されます。

お知らせを記事として蓄積したい場合は、WordPressやヘッドレスCMSも候補になります。ただし、一覧、詳細ページ、検索、複数サイトでのデータ共有などが必要になった段階で検討する方法です。今回のような小さなお知らせだけなら、オーバースペックになる可能性があります。

この記事では、この4つの方法を比較します。WordPressとヘッドレスCMSについては、要件が増えた場合の選択肢として最後に整理します。

この記事で想定するケース

今回は、次のような小規模サイトを想定します。

• 数ページ程度の静的サイト
• トップページに短いお知らせを1件表示
• 休業案内やイベント告知などの短い情報
• 一覧ページや詳細ページは不要
• 更新頻度は毎日ではない

お知らせを何件も蓄積し、カテゴリ、公開予約、検索なども必要になる場合は、最初からCMSを使った方が管理しやすくなります。

1. HTMLを直接更新する

仕組み

もっとも単純なのは、HTMLに書かれたお知らせを変更し、サイトを再度公開する方法です。

HTMLを変更
↓
サーバーへアップロード
↓
公開サイトへ反映

メリット

• 新しいサービスやアカウントが不要
• 外部サービスの障害や仕様変更を受けにくい構成
• 最初からHTMLに含まれるお知らせ内容
• 少ない初期設定と保守対象

デメリット

• 更新ごとに行うファイルの変更と公開作業
• 制作者へ依頼する場合の時間と費用
• 担当者が更新する場合に必要なHTMLの知識
• 記述ミスによる表示崩れの可能性

更新方法の例

• 制作者へ都度依頼
• FTPやSFTPによるファイル更新
• レンタルサーバーのファイルマネージャー
• Gitを使った更新とデプロイ

向いているケース

• 年に数回程度の更新
• 急な変更が少ないサイト
• 制作者へ更新を依頼できる体制
• 管理画面や保守対象を増やしたくない案件

実装・運用時の注意点

担当者向けに更新マニュアルを渡したこともあります。ただ、HTMLを扱うには一定の知識が必要です。更新に手間をかける理由を感じてもらえないと、その後あまり更新されないこともあります。

担当者が直接変更する場合は、変更する範囲を限定し、元へ戻せる方法も用意しておきたいところです。

現時点での判断

更新が年に数回なら、制作者へ都度依頼する方法が有力です。小さな更新機能のために別の仕組みを導入するより、全体の管理が簡単になる場合があります。

2. Googleスプレッドシートで更新する

仕組み

Googleスプレッドシートへ入力した内容を、Google Apps ScriptからJSONとして返します。サイト側では、そのJSONをJavaScriptで取得します。

スプレッドシートに保存
↓
Apps Scriptが公開用データを返す
↓
サイトのJavaScriptで表示

実装の大まかな流れ：

1. スプレッドシートにお知らせ本文や掲載日の列を作る
2. Apps Scriptで公開してよい項目だけを返す
3. Apps Scriptをウェブアプリとしてデプロイする
4. サイトのJavaScriptから取得して表示する

メリット

• 更新ごとのビルドとデプロイが不要
• Googleアカウントを利用できる構成
• 本文、掲載日、公開状態を一覧できる画面
• 表示する項目を用途に合わせて決められる仕組み

デメリット

• Apps Scriptの実装とウェブアプリの公開設定
• スプレッドシートの列や入力範囲を守る運用
• JavaScript実行後に表示される内容
• 読み込みに失敗した場合の代替表示
• 最初のHTMLに含まれないお知らせ内容

現在のお知らせを確認しながら編集するなら、スプレッドシートを直接更新する方が分かりやすそうです。本文、掲載日、公開状態などを同じ画面で確認できます。入力するセルを限定し、見出しやApps Scriptで使う列を誤って変更しないように保護する必要があります。

Googleアカウントを持っているお客さんは多いため、新しいサービスを一から説明する負担も抑えられます。

Googleフォームも組み合わせる場合

Googleフォームは、回答を追加していく入力方法です。現在のお知らせを見ながら修正する用途より、次のような運用に向いています。

• 複数の担当者から受け付けるお知らせ
• 入力者へスプレッドシートの編集権限を渡さない運用
• 入力項目を固定して記述漏れを減らす場合
• 投稿履歴を残し、管理者が公開内容を選ぶ運用

フォームの回答は、連携したスプレッドシートへ保存できます。Apps Scriptでは、公開状態の付いた最新行を返すような処理が必要です。

1件のお知らせを何度も更新するだけなら、フォームを作り込む利点は小さくなります。入力者と公開する人を分ける場合に、フォームを追加する方法が適しています。

向いているケース

• 担当者がすぐ変更したい短い案内
• 検索対象にしなくてもよい情報
• 更新のたびにサイトを再ビルドしたくない案件
• Googleアカウントを普段から利用している担当者

現時点での判断

お知らせ用途ではまだ採用していませんが、フォームの入力内容をサイトへ自動表示する仕組みは実装したことがあります。その構成では、入力から表示まで概ね問題なく運用できています。

この経験から、GoogleスプレッドシートとApps Scriptの組み合わせは、お知らせ更新にも応用できそうです。1件の内容を確認しながら更新するなら、フォームを増やさず、スプレッドシートを直接編集する方が扱いやすいと考えています。

3. RSSで別媒体の記事を表示する

仕組み

別のブログやお知らせページですでに発信している場合は、RSSから最新情報を表示する方法もあります。情報を二重に入力しなくてよいのが利点です。

メリット

• 別媒体で公開した記事の再利用
• タイトル、URL、公開日などの構造化されたデータ
• サイト用に同じ情報を入力し直さない運用
• カテゴリーやマガジンによる記事の絞り込み

デメリット

• サービスごとに異なるRSSの形式と配信内容
• ブラウザーから直接取得できない場合の中継処理
• 配信元の仕様変更やサービス停止による影響
• JavaScriptで表示する場合に必要な代替表示

RSSを利用できるサービス例

はてなブログ

はてなブログの更新フィードに関する公式ヘルプでは、ブログ全体、カテゴリー、著者ごとのRSSとAtomフィードが案内されています。特定カテゴリーを「お知らせ」として運用すれば、該当する記事だけをサイトへ表示できます。

note

noteのRSSに関する公式ヘルプによると、通常機能でも最新記事一覧とマガジンのRSSを利用できます。最新記事は冒頭の一部分、マガジンは含まれる記事を配信する仕組みです。お知らせ用のマガジンを作れば、関連する記事だけをサイトへ表示できます。

記事全文を配信するRSSはnote proの機能です。独自ドメインの接続が必要で、特定のハッシュタグが付いた記事に絞ることもできます。

noteでは、RSSをWebサイトへ直接埋め込まず、一度サーバー側で取り込むように案内されています。静的サイトで利用する場合は、Apps ScriptなどでRSSを取得し、サイトから読み込める形式へ変換する方法が考えられます。

RSSの配信元によってデータ形式が異なります。ブラウザーから直接取得できない場合は、Apps Scriptなどでデータを中継する処理も必要です。

お知らせのためだけに新しくブログを開設するより、すでにnoteやはてなブログを更新している場合の再利用に向いています。

向いているケース

• noteやはてなブログをすでに更新している場合
• ブログの記事をサイトのお知らせとしても見せたい場合
• 同じ情報を複数の場所へ入力したくない運用

現時点での判断

RSSは、お知らせの入力画面として新しいブログを用意する方法ではなく、すでに発信している記事の再利用に向いています。特定カテゴリーやマガジンへ記事をまとめられるサービスなら、サイトに表示する情報も絞りやすくなります。

4. SNSの投稿を埋め込む

仕組み

SNSでの発信を、そのままサイトへ表示する方法です。普段から更新している場所を利用できる反面、表示デザインや取得できる情報はSNS側の仕様に左右されます。

メリット

• スマートフォンから投稿しやすい更新方法
• 普段から運用しているアカウントの再利用
• 文章、画像、動画に合わせて選べるサービス
• 公式の埋め込み機能を使った比較的簡単な設置

デメリット

• サイト側で制御しにくい表示デザイン
• 外部スクリプトによる表示速度への影響
• 投稿やアカウントの削除による表示切れ
• 埋め込み機能やAPIの仕様変更
• SNSを利用していない閲覧者への配慮

用途に合わせたSNSの例

X

短い文章、営業案内、イベント告知などを頻繁に投稿している場合に使いやすい候補です。Xの公式ヘルプで案内されている埋め込みタイムラインや、個別投稿の埋め込みを利用できます。

Instagram

写真、商品、店舗、制作実績など、画像が中心の情報に向いています。Instagramの公式ヘルプによると、公開アカウントの投稿やプロフィールは埋め込み機能を利用できます。短い営業案内だけを表示する用途には、情報量が多くなりがちです。

TikTok

商品、店舗、採用などを動画で紹介している場合の候補です。個別動画は、TikTokの動画埋め込みに関する公式ドキュメントを参考に設置できます。

投稿一覧を取得する場合は、TikTok Display APIの公式ドキュメントも確認します。APIの利用には、開発者アカウント、アプリの承認、認証などが必要です。

どのSNSも、お知らせのためだけに始めるものではありません。すでに運用しており、サイトでも同じ情報を見せたい場合に検討します。

公式の埋め込み機能やAPIを使っていても、利用条件、認証方法、表示仕様は変更される可能性があります。外部サービスを取得できない場合でも、サイトの主要な情報と導線が残るようにしておきたいところです。

向いているケース

• SNSをすでに継続して更新している場合
• Xの短い告知をサイトにも表示したい場合
• Instagramの写真やTikTokの動画を見せたい場合
• サイト用に同じ情報を入力し直したくない運用

実装・運用時の注意点

• 読み込み中と読み込み失敗時の表示
• 投稿を削除した場合のサイト表示
• Cookieやプライバシーに関する外部スクリプトの扱い
• 埋め込み機能やAPIの仕様変更
• サイトの主要情報をSNSだけに依存させない構成

現時点での判断

SNSは、お知らせの更新機能として新しく始めるものではなく、すでに発信している情報をサイトでも見せる場合に向いています。

営業時間や休業日のような重要情報は、SNSの埋め込みだけに依存させず、サイトのHTMLにも残した方が安心です。SNSは、日々の活動や写真、動画を補足して見せる用途で検討します。

要件が増えたらCMSも検討する

今回想定している小さなお知らせは、WordPressやヘッドレスCMSでも更新できます。ただし、お知らせのためだけに導入すると、管理対象が増えすぎることもあります。

microCMSなどのヘッドレスCMSを検討する場合

microCMSやNewtなどのヘッドレスCMSは、コンテンツをサイト本体から切り離して管理できます。複数サイトで同じデータを利用する場合や、リニューアル後もコンテンツを引き継ぐ場合に利点を活かせます。

WordPressのようにサイト全体をCMSへ作り替えず、既存の静的サイトでお知らせ部分だけをmicroCMSから取得できます。サイト全体の構成を変えずに、必要な部分へ更新機能を加えられる点はメリットです。

反映方法は、ブラウザーのJavaScriptから直接取得する方法と、ビルド時に取得してHTMLへ含める方法があります。

microCMSのブラウザー向けJavaScriptチュートリアルでは、APIの作成からSDKを使ったデータ表示まで確認できます。この方法なら再ビルドは不要ですが、APIキーを利用者が確認できる状態になります。読み取り権限の制限や、取得に失敗した場合の表示が必要です。

ビルド時に取得する場合は、CMSの更新後にサイトを再ビルドします。Webhook、GitHub Actions、ホスティングサービスなどをつなぎ、アカウントの所有者やビルドに失敗した場合の対応も決めなければなりません。

小規模なホームページの1件のお知らせだけでは、こうした構成はオーバースペックになりがちです。ビルドとデプロイの選び方は、別の記事で詳しく整理します。

WordPressを検討する場合

過去のお知らせを記事として蓄積し、一覧、詳細ページ、カテゴリ、検索、公開予約などが必要になったら、WordPressを検討します。担当者が操作に慣れている場合も多く、更新から公開までを管理画面で完結できます。

本体、テーマ、プラグインの更新やバックアップは必要です。1件のお知らせだけでは大きな仕組みですが、更新コンテンツとして育てる場合は素直な選択になります。

更新方法を選ぶときの判断材料

ここまで紹介した方法は、機能の多さだけでは決められません。現在の運用状況から候補を絞り、実装前に今後の使い方も確認します。

条件別に選択肢を比較する

実装前に確認しておきたいこと

• 誰が更新するのか
• どのくらいの頻度で更新するのか
• どの程度の早さで公開する必要があるか
• 公開前の確認や公開予約が必要か
• 過去のお知らせを残すか
• お知らせを検索対象にしたいか
• 今後、一覧ページや画像が必要になりそうか
• 外部サービスが停止したときに何を表示するか
• GitHubやCMSのアカウントを誰が所有するか
• ビルドやデプロイの失敗に誰が対応するか

特に、「今は1行だけ」という要件が今後も変わらないかは確認しておきたいところです。後から一覧ページ、画像、公開予約などが必要になると、最初に選んだ方法では対応しにくくなることがあります。

まとめ

小さなお知らせは、表示するだけなら難しい機能ではありません。ただ、無理なく更新を続けるには、実際の運用まで考える必要があります。誰が、どのくらいの頻度で更新するのか、普段どのサービスを使っているのかといった点です。

高機能な仕組みを選ぶことより、担当者が実際に使い続けられ、公開後も管理できる方法を選ぶことが大切です。

関連ドキュメント

• microCMS コンテンツAPI
• microCMSをブラウザーのJavaScriptで利用する
• microCMS コンテンツのWebhook設定
• Google Apps Scriptをウェブアプリとして公開する
• Google Apps ScriptのContent ServiceでJSONを返す
• Googleフォームの回答をスプレッドシートへ保存する
• はてなブログのRSS・Atomフィード
• noteの記事をRSSで受け取る設定
• Xのタイムラインを埋め込む
• Instagramの投稿やプロフィールを埋め込む
• TikTokの動画を埋め込む
• TikTok Display API