業務に合わせた独自CMS構築
お知らせ・導入事例・採用情報を、担当者が更新しやすい仕組みへ。
社内で更新したい。独自CMSが必要？
お知らせや事例を更新する目的なら、今のCMSの設定を見直す方法もあります。WordPressには、投稿の作成や公開を分ける標準の役割があります。担当者の権限や操作手順を整理して解決するかを確認し、必要な場合に独自CMSを比較します。
たとえば事例を「業種・課題・支援内容」で管理したい、複数の担当者で承認したい、予約情報を別システムとつなぎたい。そのときは、現状の仕組みでどこまでできるかと、個別に設計する範囲を整理します。独自CMSなら自動的に運用が楽になるとは限りません。
- 今の仕事：誰が、何を、どの頻度で更新しているか。外注待ちや転記がどこで発生しているか。
- 必要な機能：入力項目・承認・公開予約・外部連携のうち、必須のものと後から追加するものを分ける。
- 続けられる体制：初期費用だけでなく、クラウド利用料・機能変更・更新管理・引き継ぎの担当と費用を比べる。
相談時は、直近で更新した内容と困った操作をひとつ教えてください。必要な作業を具体化してから、既存CMSの改善か、独自CMSへの移行かをご提案します。
参考：WordPress公式：役割と権限。独自CMSの検討項目は、この仕様を踏まえたm-Labの提案の考え方です。
入力・確認・公開をひとつの流れに
お知らせならタイトル・本文・公開日、事例なら業種・課題・写真など、入力する項目を整理します。下書きとプレビュー、編集者と承認者の役割、公開予約などを要件に応じて設計します。更新頻度と担当人数を確認し、必要な操作を絞ります。これらは構築可能な機能の例で、標準搭載を示すものではありません。
公開前のプレビュー、URLを知っている人だけなら大丈夫？
新サービスの紹介や採用条件を、社内で確認してから公開したい。そんなときは「検索に出さない設定」と「担当者だけが見られる仕組み」を分けて考えます。URLを共有するだけのプレビューでは、そのURLを受け取った人がさらに転送することもできます。
noindexは、鍵の代わりにはなりません
Googleは、noindexを付けたページでもURLを知る人は直接アクセスできると説明しています。非公開情報にはパスワードなどで閲覧を制限する方法を案内しています。robots.txtはクローラーの巡回を制御するもので、利用者のアクセス認証ではありません。
検索結果に出さないためにnoindexを使う場合も、Googleがその設定を読み取れる必要があります。robots.txtで巡回を拒否するとnoindexを確認できず、URLが検索結果に出る場合があります。非公開情報は、検索の設定だけに頼らずアクセス制限で保護します。
入稿機能をつくる前に決めること
- 誰が確認するか：社内の担当者、承認者、外部の確認者を分け、必要な人だけがログインできるようにする。
- 何を見せるか：ページ本文だけでなく、未公開画像・PDF・データ取得先にもアクセス制限が働くか確かめる。
- いつまで見せるか：外部共有が必要なら、期限や失効方法を決める。ログアウトした状態や期限切れでも閲覧できないか確認する。
- 公開時に何を切り替えるか：公開対象の本文と添付資料を確認し、公開ページへ意図しないnoindexやログイン制限を残さない。
プレビューは構築可能な機能の例です。扱う情報と承認手順に合わせ、必要な制限と確認方法を制作範囲に含めて検討します。機能を付けるだけで情報漏えいの防止を保証するものではありません。
参考にした公式情報
今使っている予約や顧客管理と、つなげられる？
たとえば「ホームページから届いた相談を顧客管理に転記したい」「予約システムの空き状況を表示したい」。独自CMSでは、こうした仕事に合わせた連携を検討できます。ただし、React・Python・Google Cloudを使うだけで、どのサービスとも自動的につながるわけではありません。
最初に確認したい、連携先の条件
- 使える機能：API（システム同士が情報をやり取りする窓口）やデータ出力があるか。契約プランと利用規約で連携が認められるか。
- 連携する情報：氏名・連絡先・予約枠など、必要な項目だけを選ぶ。どちらを正しい情報として扱い、どの方向に反映するかを決める。
- 接続の条件：認証方法、接続元の制限、回数上限、テスト環境を確認する。アクセスキーを公開ページに埋め込まない。
- 運用の条件：即時反映が必要か、まとめて処理できるか。失敗時の通知先、再送による二重登録を防ぐ方法、手動で補う手順を決める。
接続元IPの指定が必要な場合
連携先が「許可したIPアドレスからだけ接続できる」仕組みなら、クラウド側もそれに合わせます。Cloud Runの外部接続は標準では動的IPを使用します。Google Cloudは、固定の接続元IPが必要な場合に、VPCへの送信とCloud NATなどを組み合わせる構成を案内しています。固定IPを付ければすべて解決するわけではなく、認証と権限も別に確認します。
鍵の管理と、失敗したときまで設計する
APIのアクセスキーは、利用できる人やシステムを限定し、変更・失効時の手順を決めます。Cloud RunはSecret Managerに保存した秘密情報を利用する仕組みを提供していますが、適切なアクセス権限や更新方法の設計は必要です。
相談時には、利用中のサービス名・契約プラン・転記している項目・更新頻度をお聞かせください。公開APIがない場合も含め、実現できる範囲と代替手段を確認します。ここで挙げた機能や構成は例で、標準搭載や最低価格に含まれることを示しません。API利用料、ネットワーク費用、連携先の仕様変更への保守も含めてお見積もりします。
参考にした公式情報
公開後の管理まで決めてから開発
管理者の認証と権限、更新管理、バックアップ、障害時の連絡先、ソースコードと手順の引き継ぎ方法を整理します。開発・移行費用とクラウド利用料、継続保守は要件に応じてお見積もりします。
入稿担当にも管理者権限は必要？ 公開・保守の役割を整理する →
Google Cloudなら、バックアップは不要？
クラウドを使っていても、データの保存先と戻し方の設計は必要です。たとえば、事例の写真を誤って削除したとき。「サイトは動いている」だけでは、その写真を戻せるかはわかりません。どの時点のデータに戻せるか、誰が作業するかを確認します。
記事・画像・プログラムの保存先を分けて確認
Cloud RunでCMSを動かす場合、標準のコンテナ内ファイルシステムに書き込んだデータは、インスタンスの停止後に保持されません。記事や画像は、継続保存するためのデータベースやストレージなど、用途に合った保存先を選びます。これはCloud Runの仕様であり、Google Cloud上のすべての保存先が一時的という意味ではありません。
Cloud SQLをデータベースに使う場合は、自動・手動バックアップや保存期間を設定できます。ただし、データベースのバックアップで別の場所に保存した画像やプログラムまで保護されるわけではありません。実際の構成ごとに、対象と設定を確認します。
制作前に確認したい5つのこと
- 記事・画像・プログラム・設定は、それぞれどこに保存するか。
- 何を、どの頻度で、何日分保管するか。取得失敗は誰が確認するか。
- どの時点まで戻せれば業務上困らないか。復旧を待てる時間はどのくらいか。
- 検証環境で戻し方を確かめ、記事・画像・フォームなどを誰が確認するか。
- 契約が終わるとき、管理権限・データ・ソースコード・手順をどう引き継ぐか。
書き出しと、復旧用のバックアップは役割が違います
記事を別のCMSに移すための書き出しと、障害前の状態へ戻すためのバックアップは同じものではありません。Cloud SQLの公式資料でも、バックアップとエクスポートは区別されています。書き出したデータを次のCMSで取り込めるか、画像や独自項目を含めて確認することが、引き継ぎの準備になります。
ここで紹介したサービスは構成例です。m-Labでは、更新する情報と業務に合わせて保存先・保守範囲を検討します。復旧時間やデータ保持を一律に保証するものではなく、必要な設定・確認作業・継続費用をお見積もり時に整理します。
WordPressのPHP更新前に確認するバックアップ・検証手順 →
WordPressから移行するときに整理したいデータと機能 →
参考にした公式情報
入稿・連携・保守のよくある質問
お知らせを社内で更新するために、独自CMSは必要ですか？
必ずしも必要ではありません。現在のCMSで入力項目・担当者の権限・公開手順を整える方法と、独自CMSを構築する方法を比較します。独自の情報管理や外部連携が必要か、公開後の費用と保守担当まで確認して判断します。
プレビューにnoindexを付ければ、社外の人には見られませんか？
いいえ。noindexは対応する検索エンジンに検索結果へ載せないよう伝える設定で、閲覧を制限するものではありません。公開前の情報にはログインやアクセス制限を設け、画像・PDF・データ取得先にも同じ制限が働くかを確認します。
独自CMSなら、今使っている予約や顧客管理と必ず連携できますか？
必ず連携できるとは限りません。連携先のAPIやデータ出力機能、契約プラン、認証、接続元IPの制限などを確認します。送受信する項目、反映の頻度、失敗時の対応を決め、検証してから開発範囲と費用をご案内します。
Google Cloudを使えば、バックアップは不要ですか？
不要にはなりません。保存先ごとに取得対象・頻度・保存期間・復旧方法を確認します。記事データ、画像、サイトのプログラムや設定は別々に管理される場合があり、ひとつのバックアップですべて戻せるとは限りません。
バックアップがあれば、すぐに元に戻せますか？
戻せる時点と復旧にかかる時間は、設定やデータ量、障害の範囲で変わります。別の検証環境で復旧手順を確認し、いつの情報まで戻せるか、誰が復旧するか、復旧後の確認項目を事前に決めます。
担当者や制作会社が変わるとき、何を引き継ぎますか？
クラウド・ドメインの契約主体と管理権限、ソースコード、データの書き出し方法、バックアップと復旧手順、連絡先を整理します。データの書き出しと障害復旧用のバックアップは役割が異なるため、両方の使い方を確認します。