第4部まとめ
このページで学ぶこと
Section titled “このページで学ぶこと”- APIとCMSの関係を一続きで説明する方法
- コンテンツが管理画面からWebサイトへ届くまでの経路
- 連携・公開・障害・移行でPMが判断する事項
- 従来型CMSとヘッドレスCMSを案件条件で比較する方法
- API・CMS要件を見積と責任分界へ落とし込む方法
第4部の全体像
Section titled “第4部の全体像”flowchart LR
E[編集者] --> CMS[CMS]
CMS -->|API| F[フロントエンド]
CMS -->|Webhook| B[ビルド・検索更新]
B --> F
F --> H[ホスティング・CDN]
U[利用者] --> H
F --> X[検索・フォーム・予約等のAPI]
APIはシステム同士の窓口です。
CMSはコンテンツを管理する仕組みです。
ヘッドレスCMSでは、CMSのコンテンツをAPIから取得し、フロントエンドがWebページへ変換します。
そのため、CMS選定とフロントエンド・ホスティング・公開方式を分離して考えつつ、運用上は一つの流れとして設計します。
第4部で学んだ判断軸
Section titled “第4部で学んだ判断軸”データと機能
Section titled “データと機能”- 何を取得・作成・変更するか
- 必要な項目・検索・件数
- 正本はどのシステムか
- どこまで最新性が必要か
- 仕様
- 認証・権限
- レート制限
- CORS
- タイムアウト・再試行
- エラー・部分成功
- 検証環境
- SLA・費用
- 仕様変更
- CMS化範囲
- コンテンツモデル
- メディア
- 権限・承認
- 予約公開
- プレビュー
- 多言語
- 移行
- バックアップ
- 契約終了
- CMS更新から反映まで
- ビルド
- Webhook
- キャッシュ
- 検索インデックス
- フォーム・外部API
- 障害時の旧表示・代替表示
API・CMS構成をレビューする質問
Section titled “API・CMS構成をレビューする質問”- 何のデータ・機能を利用するか
- APIが要件を満たすか
- 認証情報をどこに置くか
- 最大件数・利用制限は何か
- エラー時に何を表示するか
- 本番以外でテストできるか
- 仕様変更を誰が受け取るか
- 誰が何を更新するか
- ページではなく情報をどう構造化するか
- 誰が公開できるか
- 下書きをどこで確認するか
- 予約公開はサイトまで反映されるか
- 現行データをどう移すか
- 解約時に何を出力できるか
- CMS・API・フロント・ホスティングの契約者
- 障害時の一次切り分け
- ビルド失敗時の旧版維持
- 検索・フォームの別サービス
- 月額・従量費
- 保守範囲
ケーススタディ1：コーポレートサイト＋ヘッドレスCMS
Section titled “ケーススタディ1：コーポレートサイト＋ヘッドレスCMS”- 500ページ
- ニュース、事例、サービス、固定ページ
- 更新は広報5名
- 承認者2名
- 静的配信
- 問い合わせは外部フォーム
flowchart LR
E[広報] --> C[ヘッドレスCMS]
C -->|Webhook| B[ビルド]
B --> W[静的ホスティング・CDN]
U[利用者] --> W
U --> F[外部フォーム]
PMが確認すること
Section titled “PMが確認すること”- ニュース・事例・サービスのコンテンツモデル
- 固定ページの自由度
- 承認フロー
- プレビュー
- CMS公開から反映までの時間
- ビルド失敗通知
- フォームとのデザイン・個人情報
- 検索
- CMS・ホスティング・フォームの契約
- 移行とリダイレクト
ケーススタディ2：WordPress継続利用
Section titled “ケーススタディ2：WordPress継続利用”- 小規模サイト
- ページ編集の自由度を重視
- Web以外へのコンテンツ利用なし
- 社内にWordPress保守担当
- フォーム・検索を既存プラグインで運用
- 予算・期間が限られる
ヘッドレスCMSへ移すことが必ずしも合理的ではありません。
既存運用が安定し、アップデート・バックアップ・セキュリティ対応を継続できるなら、WordPressを改善して使う案があります。
PMが確認すること
Section titled “PMが確認すること”- 本体・PHP・DB・プラグイン更新
- 不要プラグイン削除
- ステージング
- バックアップ復元
- 権限
- WAF・管理画面保護
- テーマ改修の保守性
- 将来の移行可能性
ケーススタディ3：施設・イベントAPI連携
Section titled “ケーススタディ3：施設・イベントAPI連携”- 施設情報は業務システムが正本
- イベントはCMS
- Webサイトで施設×イベント検索
- 営業時間はリアルタイム性が必要
- API開発は別会社
flowchart LR
B[業務システム] -->|施設API| F[Webフロント]
C[CMS] -->|イベントAPI| F
F --> S[検索表示]
PMが確認すること
Section titled “PMが確認すること”- 共通ID
- 施設とイベントの関連づけ
- API・CMSの更新タイミング差
- 施設削除時
- 検索インデックス
- API未完成時のモック
- 別会社の仕様確定日
- 障害時の部分表示
- データ責任
ケーススタディ4：問い合わせ＋CRM
Section titled “ケーススタディ4：問い合わせ＋CRM”- 問い合わせフォーム
- CRMへAPI登録
- 自動返信メール
- 営業部へ通知
- 個人情報を扱う
成功パターンを分ける
Section titled “成功パターンを分ける”flowchart TD
A[送信] --> B[入力検証]
B --> C[CRM登録]
C --> D[自動返信]
C --> E[担当通知]
C --> F[監査ログ]
CRMだけ失敗した場合、メールだけ成功した場合等を定義します。
PMが確認すること
Section titled “PMが確認すること”- APIの二重登録防止
- タイムアウト
- 再送
- 個人情報保存
- CRM障害時の代替
- 利用者への完了表示
- 運用通知
- 本番・テスト環境
- 保持・削除期間
ケーススタディ5：CMS移行
Section titled “ケーススタディ5：CMS移行”- 10年分の記事
- 本文に古いHTML
- 画像・PDF多数
- URL変更
- 公開日を維持
- リニューアル作業中も更新継続
- コンテンツ棚卸し
- 新モデルへの変換
- 移行ツール
- テスト移行
- 自動検証
- 目視サンプリング
- 初回投入
- 差分移行
- 更新停止
- 最終差分
- URLマッピング
- リダイレクト
- 公開後照合
CMS移行とサイト移行は連動します。
「APIは完成済みなので、フロント実装はすぐ終わる」と言われました。何を確認しますか。
回答例
必要項目・検索・件数・認証・制限・エラー・検証環境・応答速度・画面状態が要件を満たすか確認します。APIの存在と、Webサイト要件への適合は別です。ヘッドレスCMSの記事公開からWeb反映まで10分かかります。クライアントは即時反映を想定していました。何が不足していましたか。
回答例
CMS公開だけでなく、Webhook、ビルド、デプロイ、キャッシュを含む反映時間の要件・説明・検証が不足していました。再生成方式等も比較します。編集者から、どんなレイアウトも自由に作れるCMSを求められました。どう整理しますか。
回答例
必要なページ種類と更新頻度を確認し、固定テンプレート、構造化項目、許可するブロックを分けます。完全自由は品質・アクセシビリティ・保守・教育負荷を増やすことを説明します。API登録がタイムアウトしたため自動再送し、同じ予約が二件作られました。何が必要でしたか。
回答例
処理識別子による重複防止、登録結果の状態照会、再送可能条件、タイムアウト時の運用確認が必要でした。SaaS型CMSに移行したので保守契約をなくしたいと言われました。何を説明しますか。
回答例
CMS基盤更新は減っても、フロントエンド、ライブラリ、API、ビルド、検索、フォーム、権限、障害切り分け、料金・仕様変更対応は残るため、保守対象を再定義します。PMチェックリスト
Section titled “PMチェックリスト”- API・CMSを使う目的を業務要件から説明できる
- 送受信データと正本を整理している
- API仕様・認証・制限・エラーを把握している
- ブラウザ・サーバーのどちらからAPIを呼ぶか決めている
- テスト環境とモックを用意している
- CMS化範囲・更新者・頻度を整理している
- コンテンツモデルと参照関係を設計している
- 権限・承認・予約・緊急公開を決めている
- プレビューを本番に近い条件で確認できる
- CMS公開からサイト反映までの経路を図示している
- Webhook・検索・フォームの障害時対応を決めている
- 移行・差分・更新停止・品質確認を計画している
- バックアップと復元方法を確認している
- 契約者・月額費・従量費・終了時移行を把握している
- CMS、フロント、API、外部サービスの保守責任を分けている
よくある誤解・失敗
Section titled “よくある誤解・失敗”ツールから要件を考える
Section titled “ツールから要件を考える”製品デモにある機能を要件とせず、業務・情報・公開フローから設計します。
正常時だけで見積もる
Section titled “正常時だけで見積もる”エラー、遅延、重複、Webhook失敗、ビルド失敗、外部障害の対応を含めます。
CMSとWebサイトを同じものとして扱う
Section titled “CMSとWebサイトを同じものとして扱う”ヘッドレス構成では、CMS公開とWeb公開が別工程です。従来型でもキャッシュ・外部連携があります。
編集画面だけレビューする
Section titled “編集画面だけレビューする”一覧、検索、プレビュー、公開後の表示、権限、移行、保守まで確認します。
データ移行を単純コピーと考える
Section titled “データ移行を単純コピーと考える”新モデルへの変換、HTML品質、画像、URL、差分、公開状態、関連データを扱います。
理解度チェック
Section titled “理解度チェック”Q1. APIとCMSの関係を説明してください。
Section titled “Q1. APIとCMSの関係を説明してください。”回答と解説
CMSはコンテンツを管理する仕組みで、APIはそのコンテンツや機能を別システムが利用する窓口です。ヘッドレスCMSではAPI経由でフロントへ配信します。Q2. CMS製品を選ぶ前に何を整理しますか。
Section titled “Q2. CMS製品を選ぶ前に何を整理しますか。”回答と解説
CMS化範囲、コンテンツ種類・項目・関係、更新者、権限、承認、公開、プレビュー、多言語、移行、保守等です。Q3. API連携の見積が、単なるデータ取得作業より大きくなる理由は何ですか。
Section titled “Q3. API連携の見積が、単なるデータ取得作業より大きくなる理由は何ですか。”回答と解説
認証、制限、エラー、タイムアウト、画面状態、検証環境、監視、仕様変更、個人情報等を設計・テストするためです。Q4. 従来型CMSとヘッドレスCMSの選定で、最も重要な考え方は何ですか。
Section titled “Q4. 従来型CMSとヘッドレスCMSの選定で、最も重要な考え方は何ですか。”回答と解説
新旧や人気ではなく、コンテンツ・機能・表示、更新、保守体制、費用、複数チャネル等の案件条件と責任分界で比較します。Q5. CMS公開が成功してもWebサイトが更新されない原因を挙げてください。
Section titled “Q5. CMS公開が成功してもWebサイトが更新されない原因を挙げてください。”回答と解説
Webhook、ビルド、デプロイ、検索インデックス、CDN・ブラウザキャッシュ、フロント実装等の問題が考えられます。第5部へ進む前の確認
Section titled “第5部へ進む前の確認”次を自分の言葉で説明できれば、第4部の基礎は理解できています。
- APIがシステム向けの窓口であること
- リクエストとレスポンス
- REST、エンドポイント、JSON
- 認証と認可
- CORS、レート制限、タイムアウト、再試行
- CMSが管理するコンテンツ・公開状態・権限
- 構造化コンテンツ
- 従来型CMSとヘッドレスCMSの違い
- コンテンツモデル
- プレビュー、Webhook、ビルド
- CMS移行とバックアップ
- API・CMS・フロントの責任分界
次の第5部では、こうして作ったWebサイトの品質を守るため、セキュリティ、テスト、アクセシビリティを学びます。
- Google Cloud「REST API の基本と実装」
https://cloud.google.com/discover/what-is-rest-api?hl=ja - microCMS「ヘッドレスCMSとは？」
https://blog.microcms.io/what-is-headlesscms/ - Contentful「Content modeling basics」
https://www.contentful.com/help/content-models/content-modelling-basics/ - WordPress Documentation
https://wordpress.org/documentation/