CS-Cart の挙動を前提に、Cloudflare を設計できていますか？

なぜ CS-Cart 前提の設計が必要なのか

CS-Cart は状態を持つ EC 基盤です。

• 商品・注文・顧客を一体で管理する EC の中核として動く
• カスタマイズ前提で、サイトごとに挙動が変わる
• 管理・注文・画面表示など、状態が連動している

前提がズレると、来店者ごとの画面やカートの整合が崩れやすくなります。

そのうえで Cloudflare のキャッシュやセキュリティを重ねると、テンプレに近い設定だけではエッジとアプリの読み取り結果がそろいにくい場面が出ます。

なぜそうなるかの結論づけは、次の「構造的な問題」で述べます。

CS-Cart を前提に設計できる理由

強みは「Cloudflare に強い」「CDN に詳しい」ことではありません。CS-Cart の挙動を理解したうえで Cloudflare を設計する点にあります。Safe Setup は、CS-Cart の動作を成立させる構成設計サービスです。根拠は次のとおりです。

• CS-Cart のセッション・カート挙動を理解している
• 実運用での不具合パターンを把握している
• カスタマイズ環境での挙動差を考慮している

設計から納品まで

境界の切り方、運用で押さえる点、対象経路、納品物のイメージまでを、このブロックにまとめています。

Safe Setup で行う設計

「設定を足す」のではなく、境界設計です。何をエッジに載せ、何をオリジン／セッション側に残すかを先に決めます。

• キャッシュ適用範囲の設計（何をエッジに載せるか）
• セッション依存処理の分離（認証・カート等の経路の扱い）
• 動的レスポンスと静的に見えるレスポンスの整理
• 認証と管理画面の分離（運用者向けと来店者向けの切り分け）

設計で押さえるポイント

Safe Setup は、上記の複雑性と CS-Cart の前提を組み合わせて、説明できる構成へ寄せるための初期設計です。

• キャッシュの適用範囲（何をキャッシュし、何を除外するか）の整理
• 動的な処理（カート・ログイン・管理）との切り分け方針を文書化する
• CS-Cart に合わせた例外（URL・Cookie・セッションの前提）の整理
• ルール変更時に影響範囲を追える前提（責任範囲を擦り合わせる材料）
• 担当者の頭の中にしかない判断を、手順とドキュメントに残す

設計の対象範囲（公開できる粒度）

次のような経路の種類を、CS-Cart の前提と突き合わせながら キャッシュ対象／バイパス／条件付き に分類し、判断理由まで含めて文書化します。ここでは具体のルール式や Cookie 名の列挙は行いません（バージョン・カスタム・マルチストアで変わるため、契約後の納品物で確定します）。

• ストアフロント：商品一覧・詳細など、静的に近いがセッションや条件で変わり得る部分
• カート〜チェックアウト：数量変更・配送／支払・注文確定などの動的経路
• ログイン／ログアウト・会員まわり：セッション・Cookie が絡む経路
• 管理画面：運用者向け URL とストアフロントの切り分け
• Ajax／内部 API に相当する応答：部分更新や JSON 応答がキャッシュと干渉しやすい経路

公開ページで示すのは「何をどの観点で設計するか」までです。実際の設定値・ルール順序・全一覧は、合意した範囲の納品ドキュメントにまとめます。

納品としてそろえるもの

「設定代行」ではなく、CS-Cart の挙動と設計思想を前提にした Cloudflare の構成設計です。株式会社あんどぷらすが、合意した範囲で反映し、判断と変更内容を文書化します（ツール配布型ではありません）。

• キャッシュ適用範囲の設計 — ストアフロント／カート／管理の前提に沿ったルール
• 動的な処理との分離 — カート・ログイン・管理などの経路を明確にする
• セッション・認証の整合 — Cookie やセッション前提を含め、再現可能な形で固定する
• 例外と境界のドキュメント — そのまま変えてよい範囲と、レビューが必要な領域を共有する

意思決定に必要なのは「速さ」だけではなく、再現性・責任の切り分け・影響の説明です（＝設計責任の可視化）。CS-Cart と Cloudflare の両方に通じた視点で、説明のしやすさまで含めて整えます。変更の管理や復旧の運用は、プランに応じて AP SafeCache と組み合わせられます。