CMS ベストプラクティス

Webflow CMS アーキテクチャ、リレーションシップ、最適化、トラブルシューティングに関する専門的なガイダンスを提供します。

重要な注意事項

すべての操作には必ず Webflow MCP ツールを使用してください。

開始前に Webflow MCP の webflow_guide_tool を使用してベストプラクティスを入手する
Webflow MCP の data_sites_tool をアクション list_sites で使用して利用可能なサイトを特定する
Webflow MCP の data_sites_tool をアクション get_site で使用してサイトの詳細とプランの制限を取得する
Webflow MCP の data_cms_tool をアクション get_collection_list で使用して既存のコレクションを分析する
Webflow MCP の data_cms_tool をアクション get_collection_details で使用してコレクションスキーマを調べる
Webflow MCP の data_cms_tool をアクション list_collection_items で使用してコンテンツ量を評価する
Webflow MCP の data_pages_tool をアクション list_pages で使用してページ構造を把握する
Webflow MCP の ask_webflow_ai で特定の API に関する質問をする
Webflow の操作には他のツールやメソッドを使用しないでください
すべてのツール呼び出しには必須の context パラメータ（15～25語、第三人称視点）を含める必要があります

指示

フェーズ1: 発見と分析

リクエストを特定する: ユーザーが以下のうちどれを求めているかを判断する:
- 新しい CMS 構造の計画
- 既存コレクションの最適化
- パフォーマンス問題のトラブルシューティング
- リレーションシップの設定
- アーキテクチャガイダンスの要求
サイト情報を取得する: Webflow MCP の data_sites_tool をアクション list_sites と get_site で使用してプランの制限を把握する
既存の構造を分析する: Webflow MCP の data_cms_tool をアクション get_collection_list と get_collection_details で使用して現在の設定を調べる
コンテンツ量を評価する: Webflow MCP の data_cms_tool をアクション list_collection_items で使用して規模を把握する
ページをレビューする: Webflow MCP の data_pages_tool をアクション list_pages で使用してコンテンツがどのように表示されているかを確認する

フェーズ2: 要件の収集

ユースケースを理解する: 明確化の質問をする:
- 管理する必要があるコンテンツは何か？
- 誰がコンテンツを更新するのか？
- コンテンツはどのように表示されるのか？
- どのようなリレーションシップが必要か？
- 予想されるコンテンツ量は？
制約を特定する: プランの制限、技術的な制約、チームのスキルを考慮する
成功基準を定義する: パフォーマンス目標、編集ワークフロー、スケーラビリティのニーズ

フェーズ3: アーキテクチャ計画

コレクション構造を設計する: コレクション、フィールド、リレーションシップを計画する
フィールドタイプを選択する: 各コンテンツ要素に適切なフィールドタイプを選択する
リレーションシップを計画する: 一対多および多対多の接続を設計する
分類法を検討する: カテゴリ、タグ、および組織構造を決定する
規模に備えて計画する: 成長に対応した設計（ページネーション、パフォーマンス、制限）
決定事項を文書化する: トレードオフと理由を説明する

フェーズ4: 推奨事項と検証

推奨事項を生成する: 具体的で実践可能なガイダンスを提供する
変更に優先順位を付ける: 影響度で整理する（クイックウィン vs 長期的なもの）
トレードオフを説明する: ユーザーが制限と回避策を理解できるようにする
ベストプラクティスに照らして検証する: Webflow の制限とパターンに照らして確認する
代替案を提供する: 該当する場合は複数のアプローチを提供する
実装ロードマップを作成する: フェーズに分解する

フェーズ5: 実装ガイダンス

ステップバイステップの指示を提供する: 実装のための明確なガイダンス
支援を申し出る: 他のスキル（cms-collection-setup、bulk-cms-update）の使用を提案する
構造を文書化する: チーム参照用の文書化を推奨する
テストアプローチを提案する: 変更を検証する方法をガイドする
移行を計画する: リファクタリングの場合は移行戦略を提供する

コレクションアーキテクチャ

CMS を使用する場合と静的コンテンツを使用する場合

CMS を使用する場合:

コンテンツが頻繁に更新される（毎週以上）
複数の類似アイテムがある（ブログ記事、商品、チームメンバー、プロジェクト）
非技術ユーザーがコンテンツを編集する必要がある
フロントエンドでフィルタリング/並べ替えが必要なコンテンツ
同じコンテンツが複数のページに表示される（著者略歴、製品機能）
コンテンツがアイテム間で一貫した構造に従っている
動的にページを生成する必要がある

静的コンテンツを使用する場合:

コンテンツがめったに変更されない（年1回以下の更新）
ユニークな単発セクション（アバウトページのヒーロー、ホームページの特別機能）
パターンに従わないアイテムごとの複雑なカスタムレイアウト
動的フィルタリングや検索が不要
コンテンツが高度にカスタマイズされており、構造を共有しない
パフォーマンスが重要でコンテンツが変更されない
セクションごとに完全なデザインの柔軟性が必要

ハイブリッドアプローチ:

CMS 駆動のセクションを持つ静的ページ（例: 静的ホームページに CMS の推薦の声）
最近のコンテンツには CMS、古いコンテンツには静的アーカイブ
静的ランディングページ、サブページには CMS

フィールドタイプの選択

コンテンツタイプ	推奨フィールド	備考	文字数制限
短いテキスト	プレーンテキスト	タイトル、名前、スラッグ	最大256文字
長いテキスト（書式なし）	プレーンテキスト（長い）	説明、抜粋	無制限
書式付きコンテンツ	リッチテキスト	ブログ記事、経歴、記事	無制限
単一画像	画像	写真、サムネイル、ヘッダー	画像あたり最大4MB
複数画像	複数画像	ギャラリー、商品写真	最大25画像
ファイルダウンロード	ファイル	PDF、書類、ダウンロード	ファイルあたり最大4MB
はい/いいえの値	スイッチ	おすすめフラグ、表示切り替え	ブール値
単一選択	オプション	ステータス、タイプ、カテゴリ	オプション数無制限
日付/時刻	日付/時刻	公開日、イベント、期限	ISO 8601 形式
1つのアイテムへのリンク	参照	著者→記事、カテゴリ→記事	1つのアイテム
複数のアイテムへのリンク	複数参照	記事→タグ、記事→関連記事	複数のアイテム
外部URL	リンク	ソーシャルリンク、外部リソース	最大2048文字
数値	数値	価格、評価、順序、カウント	整数または小数
電話番号	電話	連絡先番号	E.164 形式
メールアドレス	メール	連絡先メール	有効なメール形式
カラー値	カラー	テーマカラー、アクセント、ブランドカラー	Hex 形式
ビデオ埋め込み	ビデオ	YouTube、Vimeo 埋め込み	埋め込みURL

フィールドタイプ決定木

保存するもの:
├── テキスト?
│   ├── 短い（≤256文字）? → プレーンテキスト
│   ├── 長い + 書式あり? → リッチテキスト
│   └── 長い + 書式なし? → プレーンテキスト（長い）
├── メディア?
│   ├── 単一画像? → 画像
│   ├── 複数画像? → 複数画像
│   ├── ビデオ? → ビデオ
│   └── ファイルダウンロード? → ファイル
├── 選択/選択肢?
│   ├── はい/いいえ? → スイッチ
│   ├── 1つのオプション? → オプション
│   └── アイテムへのリンク? → 参照/複数参照
├── 構造化データ?
│   ├── 数値? → 数値
│   ├── 日付/時刻? → 日付/時刻
│   ├── 電話? → 電話
│   ├── メール? → メール
│   └── URL? → リンク
└── 視覚的?
    └── カラー? → カラー

リレーションシップパターン

一対多（参照フィールド）

例: 記事 → 著者

著者コレクション:
├── name（テキスト、必須）
├── slug（テキスト、必須）
├── bio（リッチテキスト）
├── photo（画像）
├── title（テキスト）- 役職
├── email（メール）
└── social-links（リンク）

記事コレクション:
├── title（テキスト、必須）
├── slug（テキスト、必須）
├── content（リッチテキスト）
└── author（参照 → 著者）  ← 各記事に1人の著者

表示: 記事ページで、author.name、author.photo、author.bio にアクセス

フィルタリング: 特定の著者で記事をフィルタリング可能

利点:

✅ 著者データの集中管理（1回更新するだけで、どこにでも反映）
✅ 一貫性の維持が容易
✅ 著者プロフィールページを作成し、すべての記事を表示可能
✅ 効率的（記事あたり1つの参照）

ユースケース:

ブログ記事 → 著者
商品 → ブランド
イベント → 会場
プロジェクト → クライアント
推薦の声 → 顧客

多対多（複数参照）

例: 記事 ↔ タグ

タグコレクション:
├── name（テキスト、必須）
├── slug（テキスト、必須）
├── description（プレーンテキスト）
└── color（カラー）- オプションの視覚的グループ化

記事コレクション:
├── title（テキスト、必須）
├── slug（テキスト、必須）
├── content（リッチテキスト）
└── tags（複数参照 → タグ）  ← 各記事に複数のタグ

表示: 記事ページで、tags をループしてすべてのタグを表示

フィルタリング: 特定のタグで記事をフィルタリング可能

利点:

✅ 柔軟なコンテンツ整理
✅ 関連コンテンツの相互リンク
✅ より良い SEO（トピッククラスタリング）
✅ 強化されたユーザーナビゲーション

制限事項:

⚠️ コレクションあたり最大5つの複数参照フィールド
⚠️ コレクションリストでは、一度に1つの複数参照値でのみフィルタリング可能
⚠️ 参照フィールドの値で並べ替え不可
⚠️ 各参照 = 追加クエリ（パフォーマンスに影響）

複数タグフィルタリングの回避策:

組み合わせタグを作成する（例: "vegan-gluten-free"）
クライアントサイドフィルタリングに Finsweet CMS Filter を使用する
よく使われる組み合わせに対して個別のフィルタリング済みコレクションリストを作成する
Webflow API でカスタムコードを使用する

ユースケース:

ブログ記事 ↔ タグ
商品 ↔ 機能
プロジェクト ↔ 技術
レシピ ↔ 材料
コース ↔ トピック

自己参照（ネストされたコレクション）

例: サブカテゴリ付きカテゴリ

カテゴリコレクション:
├── name（テキスト、必須）
├── slug（テキスト、必須）
├── description（プレーンテキスト）
├── parent（参照 → カテゴリ）  ← 階層のための自己参照
└── level（数値）- 表示ロジック用の1、2、3

ユースケース:

サブカテゴリ付きカテゴリ
サブメニューアイテム付きメニューアイテム
組織階層
製品分類法

利点:

✅ 柔軟な階層
✅ 理論上は無制限の深さ
✅ 再編成が容易

制限事項:

⚠️ Webflow でネストされたレベルを表示するのは複雑
⚠️ 実用的な実装には最大2～3レベルを推奨
⚠️ 深いネストにはカスタムロジックが必要

代替案: 単純な1～2レベルの分類にはオプションフィールドを使用する

双方向リレーションシップ

例: 関連記事

記事コレクション:
├── title（テキスト、必須）
├── slug（テキスト、必須）
├── content（リッチテキスト）
└── related-posts（複数参照 → 記事）  ← 他の記事への自己参照

表示: 記事ページの下部に関連記事を表示

利点:

✅ ユーザーのエンゲージメントを長く維持
✅ より良い SEO（内部リンク）
✅ 柔軟なコンテンツ接続

課題:

⚠️ 真の双方向ではない（A→B が自動的に B→A を作成しない）
⚠️ 必要な場合は両方向を手動で維持する必要がある
⚠️ コンテンツ編集者にとって時間がかかる可能性がある

解決策:

自動的な「タグによる関連」ロジックにはタグを使用する
最も重要な接続には手動キュレーション
ハイブリッド: 手動 + タグ/カテゴリに基づく自動

例

例1: 新しい CMS 構造の計画

ユーザープロンプト:

レシピサイトを作っています。CMS をどのように構成すればよいですか？

ステップ1: 要件の収集

📐 CMS 計画: レシピサイト

最適な構造を設計するためにいくつか質問させてください:

1. **コンテンツ量**: 何件のレシピを予定していますか？
   - 少ない（≤50件）: シンプルな構造
   - 中程度（50～200件）: 適度な整理
   - 多い（200件以上）: 高度な分類法が必要

2. **レシピ属性**: 各レシピに含まれる情報は？
   - 基本: 名前、材料、手順、画像
   - 詳細: 準備時間、調理時間、難易度、栄養情報、食事タグ

3. **整理ニーズ**: ユーザーはどのようにレシピを見つけますか？
   - 食事タイプ別（朝食、昼食、夕食）
   - 料理別（イタリアン、メキシカン、アジアン）
   - 食事制限別（ヴィーガン、グルテンフリー、ケト）
   - 調理法別（ベーキング、グリル、スロークッカー）
   - 材料別（鶏肉、パスタ、野菜）

4. **著者設定**: 単数か複数か？
   - 単数: すべてのコンテンツを自分で管理
   - 複数: レシピ作成者のチーム

5. **ユーザーエンゲージメント**: どのようなインタラクティブ機能？
   - コメント/レビュー
   - 評価
   - お気に入り保存
   - レシピカードの印刷

あなたの回答に基づいて、最適な CMS アーキテクチャを設計します。

ステップ2: ユーザーが回答した後

📐 推奨 CMS アーキテクチャ: レシピサイト

あなたの要件（中程度の量、複数の著者、高度なフィルタリング）に基づきます:

---

## 必要なコレクション: 4

### 1. レシピ（メインコンテンツ）
├── name（テキスト、必須）- "自家製パスタカルボナーラ"
├── slug（テキスト、必須）- "homemade-pasta-carbonara"
├── description（プレーンテキスト、160文字）- SEO用の簡単な概要
├── featured-image（画像）- 詳細ページのヒーロー画像
├── thumbnail-image（画像）- グリッドカード用の小さな画像
├── prep-time（数値、必須）- 準備の分数
├── cook-time（数値、必須）- 調理の分数
├── total-time（数値）- 自動計算または手動
├── servings（数値、必須）- 人数分
├── difficulty（オプション: 簡単、中程度、難しい）
├── ingredients（リッチテキスト、必須）- 分量付き材料リスト
├── instructions（リッチテキスト、必須）- ステップバイステップの手順
├── notes（リッチテキスト）- 料理人のメモ、ヒント、代替材料
├── nutrition-info（プレーンテキスト）- カロリー、タンパク質など
├── author（参照 → 著者、必須）
├── category（参照 → カテゴリ、必須）- 主要な食事タイプ
├── cuisine（参照 → 料理）- イタリアン、メキシカンなど
├── dietary-tags（複数参照 → 食事タグ）- ヴィーガン、GFなど
├── cooking-methods（複数参照 → 調理法）- ベーキング、グリルなど
├── featured（スイッチ）- ホームページでハイライト
├── published-date（日付、必須）
└── view-count（数値）- 人気度を追跡

**合計フィールド:** 22フィールド
**必要なプラン:** CMS プラン最小（20コレクション、2000アイテム）

### 2. 著者
├── name（テキスト、必須）
├── slug（テキスト、必須）
├── title（テキスト）- "ヘッドシェフ"、"レシピ開発者"
├── bio（リッチテキスト）
├── photo（画像）
├── specialty（プレーンテキスト）- "イタリア料理"、"ベーキング"
├── social-instagram（リンク）
├── social-website（リンク）
└── email（メール）

**目的:** すべてのレシピで再利用可能な著者情報

### 3. カテゴリ
├── name（テキスト、必須）- "朝食"、"昼食"、"夕食"、"デザート"
├── slug（テキスト、必須）
├── description（プレーンテキスト）
├── image（画像）- カテゴリのヒーロー画像
├── color（カラー）

Webflow CMS ベストプラクティス