WordPress CMS操作マニュアル¶

このドキュメントは、WordPress CMSの操作・使用方法を体系的にまとめた操作マニュアルです。

この文書の役割: WordPress CMS の日常操作の正本です。お知らせ・キャンペーン・メインバナー・メニューの作成・編集・公開はここを参照してください。各コンテンツタイプの運用ルールや設計方針の補足説明は WordPressコンテンツ管理ガイドを参照してください。

目次¶

基本操作ガイド
コンテンツタイプ別操作ガイド
ナビゲーション（ヘッダー / フッター）の編集
ACFカスタムフィールドの設定と使用
設定・管理機能
Storefront への即時反映（Webhook）
トラブルシューティング
関連ドキュメント

基本操作ガイド¶

WordPress管理画面へのアクセス¶

ブラウザで管理画面URLにアクセス
ローカル環境: http://localhost:8181/wp-admin
本番環境: https://your-wordpress-site.com/wp-admin
ユーザー名とパスワードでログイン

管理画面の構成¶

WordPress管理画面の主要なメニュー：

ダッシュボード: サイトの概要、最近の投稿
投稿: お知らせ、キャンペーンなどのコンテンツ管理
メインバナー: ホームヒーローのバナー管理（ACF Options）
メディア: 画像・動画などのメディアライブラリ
設定: サイトの基本設定、パーマリンク設定など

基本的な操作フロー¶

コンテンツの作成
左メニューから該当するコンテンツタイプを選択
「新規追加」をクリック
タイトル、本文、カスタムフィールドを入力
「公開」ボタンをクリック
コンテンツの編集
コンテンツ一覧から編集したい項目を選択
「編集」をクリック
内容を変更して「更新」ボタンをクリック
コンテンツの削除
コンテンツ一覧から削除したい項目を選択
「削除」をクリック
確認ダイアログで「OK」をクリック

コンテンツタイプ別操作ガイド¶

本文内の商品リスト埋め込み¶

記事・固定ページ・キャンペーン本文に商品リストを表示したい場合は、WordPress で商品を選ばず、Vendure Dashboard の カタログ > カスタム商品リスト で作成済みの handle を本文に shortcode として入力します。

[ritsubi_product_list handle="home-recommended"]

操作時の確認:

handle は Vendure 側のカスタム商品リスト詳細に表示される値を使う
WordPress 本文では shortcode の前後に通常の文章や見出しを置ける
商品リストの表示名、商品、並び順、社内メモは Vendure 側で編集する
商品が現在の顧客に表示不可の場合、Storefront ではその商品カードを表示しない

詳細仕様はカスタム商品リストを参照してください。

お知らせ（Announcement）¶

サイト全体のお知らせを管理します。

作成手順¶

投稿 → お知らせ → 新規追加
以下の項目を入力：
タイトル: お知らせのタイトル（必須、50文字以内推奨）
本文: お知らせの詳細内容（Markdown対応）
公開設定: 公開日時を設定（必要に応じて）

カスタムフィールド（ACF）¶

フィールドグループ: Announcement Meta

`isFeatured`（フィーチャー済み）¶

タイプ: True/False
説明: サイト上部に固定表示する重要なお知らせかどうか
設定値:
true: サイト上部の黄色バナーに表示（重要なお知らせ）
false: 通常のお知らせ一覧のみに表示

使用例:

緊急メンテナンス通知
重要なお知らせ
システム変更の告知

注意事項:

フィーチャー済みお知らせは最大5件まで推奨
古いお知らせは isFeatured を false に変更

`relatedLink`（関連リンク）¶

タイプ: URL
説明: お知らせに関連する詳細ページのURL（任意）
設定例: /announcements/123 または外部URL

運用ルール・補足情報¶

運用ルール・補足情報は WordPressコンテンツ管理ガイドを参照してください。

キャンペーン（Campaign）¶

プロモーションキャンペーン情報を管理します。

[!IMPORTANT] キャンペーン公開の正本は Vendure の Collection です。WordPress の Campaign 投稿は、長文本文や追加ビジュアルが必要な場合にだけ使う補助導線です。一覧表示・公開 URL・対象商品は、先に Vendure Dashboard 側で整えてください。

基本手順¶

先に Vendure Dashboard操作ガイドを参照し、campaigns 親 Collection 配下に対象 campaign の child collection を作成・更新する
公開 URL、対象商品、一覧表示、説明/画像を Vendure 側で確認する
長文本文や補足ビジュアルが必要な場合だけ、投稿 → キャンペーン → 新規追加 を開く
WordPress 側では以下を入力する：
タイトル: 通常は Collection 名に合わせる
アイキャッチ画像: 本文用に必要な場合だけ設定
公開設定: 公開日時を設定
WordPress 投稿の slug や内容が、対象 Collection と対応していることを確認する

Storefront で表示される条件¶

キャンペーンは、WordPress 投稿を公開しただけでは Storefront に表示されません。次をすべて満たす場合だけ、キャンペーン一覧・キャンペーン詳細・メインバナーの campaign 連動導線に表示されます。

Vendure の campaigns 親 Collection 配下に対象 campaign の child collection がある
対象 campaign collection が表示制御ルールで現在の顧客に許可されている
対象 campaign code が有効である
対象 campaign collection に、現在の顧客から見える商品が1件以上ある

対象商品が0件の場合は、campaign collection や WordPress 投稿が存在していても Storefront の導線には出ません。

カスタムフィールド（ACF）¶

フィールドグループ: Campaign Meta

`order`（表示順序）¶

タイプ: Number
説明: キャンペーンの表示順序（小さい順）
設定例: 1（最初）、2（2番目）、10（最後）

`image`（キャンペーン画像）¶

タイプ: Image
説明: キャンペーン専用の画像（アイキャッチ画像より優先）
推奨サイズ: 1200x600px（アスペクト比 2:1）

運用ルール・補足情報¶

運用ルール・補足情報は WordPressコンテンツ管理ガイドを参照してください。Vendure 側の設定確認は Vendure Dashboard操作ガイドも参照してください。

メインバナー（ホームヒーロー）¶

ホームページのヒーローセクション用バナーを管理します。

編集手順¶

メインバナー を開く
スライドを追加・編集
ドラッグ&ドロップで並び替え、保存

カスタムフィールド（ACF）¶

フィールドグループ: メインバナー（リピーター）

`slides`（スライド）¶

主な項目:

title: スライドの識別用タイトル（ユーザーには表示されません）
lead: リード文（任意）
media.type: メディアタイプ（image / video）
media.image.desktop / media.image.mobile: 画像（デスクトップ/モバイル）
media.video.desktop / media.video.mobile: 動画（デスクトップ/モバイル）
media.image.alt: 代替テキスト
displayPeriod.startAt / displayPeriod.endAt: 表示期間
trackingId: 計測用ID
campaignId: 連動先 campaign の一意ID（任意）
scheduleMode: campaign 連動時の期間判定モード（banner-only / campaign-only / both）

campaign 連動と通常バナーの違い¶

campaignId 未設定の通常バナーは、商品や campaign には紐づきません。表示可否は displayPeriod だけで判定します。
campaignId 設定済みの campaign 連動バナーは、Vendure 側の campaign collection に解決でき、表示制御で許可され、有効 campaign code と一致し、現在の顧客から見える商品が1件以上ある場合だけ表示されます。
campaign 連動バナーで scheduleMode: campaign-only を選んだ場合でも、対象商品が0件の campaign は表示されません。

画像ガイドライン¶

デスクトップ: 2048x663px 相当（比率 2048:663）
モバイル: 751x485px 相当（比率 751:485）
画像サイズは前後しても可。比率は固定。
実装は object-cover のため、比率を維持したまま必要に応じてトリミングされる
ビジュアル（画像/動画）のみ使用（コンテンツレイアウトは廃止）
ホーム画面では通常 1枚ずつ切り替える表示 とし、desktop 幅が十分にある場合だけ サブメインサブ の 3枚表示へ切り替わる

仕様の正本¶

比率と表示モードの正本は docs/specifications/2026-03-storefront-home-hero-ratio.md を参照
campaign 連動の正本は docs/specifications/2026-04-home-hero-campaign-linkage.md を参照

運用ルール・補足情報¶

運用ルール・補足情報は WordPressコンテンツ管理ガイドを参照してください。

ストア設定のSNSリンク¶

フッターや商品一覧サイドバーに表示する SNS リンクは、ストア設定 の SNS タブ内にある SNSリンク で管理します。

編集手順¶

ストア設定 (site-settings) を開く
SNS タブを開く
SNSを追加 で行を追加する
種別 / platformKey / 表示名 / URL を入力する
必要に応じて アイコンURL / 表示 / 並び順 を設定する
更新をクリックする

入力ルール¶

URL が空欄の行は無視される
表示 を OFF にした行は表示されない
LINE / Instagram / YouTube は固定アイコンが使われる
TikTok など未知SNSや独自リンクは、iconUrl を設定するとその画像が使われる

注意事項¶

SNSリンクを 1件も表示したくない 場合は、行を空にするか、全行を 表示=OFF にする
Storefront は 有効な実 URL が設定された行だけ を表示し、example.com 系のプレースホルダー URL は表示しない
反映が遅い場合は、Storefront のストア設定キャッシュ更新を待ってから確認する
ローカルで just wp-bootstrap 直後は https://example.com/line / instagram / youtube のプレースホルダー URL が入るため、公開前に必ず公式 URL へ置き換える（未置換の行は Storefront 上で非表示になる）
商品リストの初期値は WordPress ではなく Vendure の カタログ > カスタム商品リスト で管理する

ブランド情報の管理先¶

ホーム画面や商品一覧上部で使うブランド名・説明文・画像は、WordPress 管理画面ではなく Vendure の collection で管理します。WordPress 側の操作対象は site-settings の共通設定、メインバナー、お知らせ、キャンペーンに限定します。

Vendure 側の運用ルール¶

Vendure で brand Facet と各ブランド FacetValue を用意する
親 collection brands を用意する
各ブランドを child collection として追加し、facet-value-filter で brand=<facet value> を設定する
必要に応じてブランド配下に 業務用商品 / 店販用商品 / セット商品 / 販促品 / キャンペーン商品 などの menu collection を追加し、親 filter 継承 + 追加 Facet 条件で絞り込む
slug を Storefront 導線と plugin 判定に使う安定キーとして決める
name / description / featuredAsset / assets にブランド表示や導線用の内容を設定する
価格・配送・同意・契約条件は collection に入れず、Vendure の Facet / custom field で管理する
ホームの「ご契約ブランド一覧」と商品一覧上部のブランド紹介は、当該ブランド collection に可視商品が1件以上ある場合のみ表示される
ホームの「ご契約ブランド一覧」に使う featuredAsset は 3:1 横長を前提に制作・登録する

注意事項¶

WordPress には brand-settings options page は存在しない
WordPress のメディアにブランド画像を置いても Storefront のブランド表示には使われない
ブランド導線の運用変更が必要な場合は、WordPress ではなく Vendure 側の collection を更新する
ブランド画像比率の正本は docs/specifications/2026-03-storefront-contract-brand-ratio.md を参照する

サポート / 固定ページ（Page）¶

Storefront の /support および /support/<子ページ> の本文は、WordPress の 固定ページを正本にします。 Storefront は URL パス（pathname）をそのまま WordPress 固定ページの URI として解決するため、 ページを追加するのに Storefront のコード変更・再デプロイは不要です。設計の正本は docs/specifications/2026-06-storefront-support-pages-cms-ssot.md。

サポートトップ（`/support`）¶

固定ページ → 新規追加
タイトルを入力（例: 「サポート窓口」）。Storefront の見出し・パンくずに使われます。
スラッグを半角小文字 support にする（URI が /support になる）。
本文に各種案内・子ページへの導線を書く。
「公開」。

サポート子ページ（例: `/support/contact`）の追加手順¶

固定ページ → 新規追加
タイトルを入力（例: 「お問い合わせ窓口」）。
ページ属性 → 親ページで 「サポート」(support) を選択する。これで URI が階層化されます。
スラッグを 半角小文字で URL 末尾に合わせる（例: contact → URI /support/contact）。
日本語タイトルから自動生成されたスラッグは、必ず ASCII の半角小文字へ修正する。
本文（問い合わせ先・外部フォーム URL・FAQ など）を書く。
「公開」。公開と同時に page.updated（タグ cms / pages）の revalidate が発火し、Storefront のキャッシュが自動 purge されます。

注意事項¶

slug / pathname → ページの対応表は Storefront コードに持ちません。WordPress の固定ページ URI が Storefront URL の正本です。
固定ページが存在しない URL は、仮ページへ fallback せず 404 になります。
/support/maintenance だけは app 固有ルート /maintenance への redirect 例外です（CMS ページではありません）。
WordPress のパーマリンク設定は pretty permalink（投稿名 / 数字ベース）を維持してください（nodeByUri が URI を解決できなくなるため、「プレーン」は不可）。

ナビゲーション（ヘッダー / フッター）の編集¶

Storefront のヘッダー・フッターのリンク／ラベル／並び順は、WordPress の 「外観 → メニュー」 で管理します。

概要¶

表示位置	WordPress のメニュー位置（Location）	備考
サイトヘッダー	`Primary Navigation`	子メニューはメガメニュー的に展開可能
サイトフッター	`Footer Navigation`	「テキストブロック」項目はリッチテキスト領域として描画

メニュー項目は、項目に設定された displayType に応じてフッターでの描画形態が変わります。

link / page（既定）: フッター下段の リンクセクション に並びます。子メニューがあれば横並びリンクとして展開されます。
text_block: フッター上段の テキストセクション として、HTML 本文（ACF body）が描画されます（注釈・営業時間など）。

編集手順¶

WordPress 管理画面で 外観 → メニュー を開く
上部の「編集するメニューを選択」で対象メニューを選ぶ（新規作成も可）
左側の「ページ」「カスタムリンク」「投稿タイプ」から項目を追加、もしくは右側の項目をドラッグして並び替え
各項目を展開し、ラベル・URL・description・新規タブで開くか・displayType を確認
画面下部の メニュー設定 → 表示位置 で、Primary Navigation または Footer Navigation にチェックを入れる
「メニューを保存」 をクリック

保存と同時に Storefront の revalidation webhook が呼び出され、Storefront / Vendure CMS cache が無効化されます。次回ページ表示で必ず最新メニュー が反映されます（後述の「Storefront への即時反映」を参照）。

注意事項¶

フッターからは /quick-order パスへのリンクは自動的に非表示になります（Storefront 側の意図的な除外）。
子メニューはフッターでは「親項目の見出し下の横並びリンク」として描画されます。深い階層（孫メニュー以降）はフッターでは展開されません。
ロゴ・コピーライト・SNS リンクなど メニュー項目以外 のフッター要素は、設定 → ストア設定（ACF Options）で管理します。これも編集後に即時反映されます。

反映確認¶

WordPress でメニューを保存する
Storefront を開く（同一タブで開いていた場合はリロード）
フッター／ヘッダーが期待通り更新されていることを確認する

数秒〜十数秒経っても反映されない場合は「Storefront への即時反映」節と「トラブルシューティング」節を参照してください。

ACFカスタムフィールドの設定と使用¶

ACFとは¶

Advanced Custom Fields（ACF）は、WordPressの標準機能を拡張してカスタムフィールドを追加できるプラグインです。

このプロジェクトでの ACF 運用原則¶

ACF フィールド定義の正本は管理画面ではなく apps/wordpress-cms/plugins/ritsubi-ec-plugin/acf-json/ の JSON です
管理画面で項目が見えない、設定タブが欠ける、固定ページ導線が崩れる場合は、まず DB スキーマ差分ではなく CMS 構成 drift を疑います
構成確認の正規コマンドは just wp-drift-audit、運用環境は just wp-drift-audit-vps staging|production です

カスタムフィールドの見つけ方¶

コンテンツ編集画面を開く
スクロールして「カスタムフィールド」セクションを確認
フィールドグループ名（例: Announcement Meta）を確認

フィールドの入力方法¶

True/False フィールド: チェックボックスをオン/オフ
Number フィールド: 数値を直接入力
URL フィールド: URLを入力（例: https://example.com）
Image フィールド: 「画像を追加」ボタンをクリックして画像を選択
Group フィールド: サブフィールドが展開されるので、それぞれ入力

よくある質問¶

Q: カスタムフィールドが表示されない¶

A: フィールドグループが正しい投稿タイプに割り当てられているか確認
A: ページをリロードしてみる

Q: フィールドの値を変更しても反映されない¶

A: 「更新」ボタンをクリックして保存
A: ブラウザのキャッシュをクリア

設定・管理機能¶

パーマリンク設定¶

WordPress管理画面 → 設定 → パーマリンク設定

推奨設定¶

数字ベース または カスタム構造（/%post_id% や /post/%post_id%）
理由: 一意性が保証され、日本語が混入しないため

設定の影響¶

GraphQLエンドポイントのURLが変わる可能性があります
パーマリンク設定が「プレーン」の場合、index.php?graphql 形式になることがあります
推奨設定に変更すると、/graphql でアクセス可能になります

詳細は WordPress CMSローカル開発環境を参照してください。

公開状態の管理¶

WordPressでは、以下の公開状態を設定できます：

公開: サイトに表示される
下書き: 保存のみ、サイトに表示されない
非公開: 管理者のみ閲覧可能
予約投稿: 指定した日時に自動公開

公開日時の設定¶

公開日時が未来: 指定時刻まで非公開
公開日時が過去: すぐに公開
公開日時を変更: 表示順序に影響（新しい順に並ぶ）

Storefront への即時反映（Webhook）¶

WordPress の保存操作が完了すると、ritsubi-ec-plugin が 自動で Storefront 側のキャッシュ無効化 endpoint を叩く ため、運用担当が Cloudflare 管理画面・CLI・curl を触る必要はありません。

反映の対象と event¶

WordPress 側の操作	発火する WP action	送信される event	Storefront 側で無効化される tag
メニュー（Primary / Footer）の保存・並び替え	`wp_update_nav_menu`	`menu.updated`	`cms`, `menus`
メニューの新規作成	`wp_create_nav_menu`	`menu.updated`	`cms`, `menus`
メニューの削除	`wp_delete_nav_menu`	`menu.updated`	`cms`, `menus`
ページ / 固定ページの公開・更新・取り下げ	`transition_post_status`	`page.updated`	`cms`, `pages`
お知らせの公開・更新・取り下げ	`transition_post_status`	`announcement.updated`	`cms`, `announcements`
キャンペーンの公開・更新・取り下げ	`transition_post_status`	`campaign.updated`	`cms`, `campaigns`
商品詳細ページ（product_detail）の公開・更新	`transition_post_status`	`product.updated`	`cms`, `products`
ACF Options の保存（ストア設定 / メインバナー / ランキング）	`acf/save_post`	`settings.updated`	`cms`, `settings`, `banners`, `rankings`

[!NOTE] transition_post_status は publish 状態の出入り だけで発火します（draft → draft や autosave / revision はスキップ）。「公開→公開」の更新はもちろん発火するため、公開済み記事のタイトル修正なども即時反映されます。

反映されるまでの時間¶

メニュー: WordPress 保存 → 数秒以内に Storefront の次回 SSR で反映（plugin 側のメモリキャッシュは bypass 済み）
その他コンテンツ: WordPress 保存 → Storefront 側のキャッシュは即時無効化されますが、Vendure plugin 内のメモリキャッシュ（既定 5 分）に残る間は古い本文が返ることがあります。詳細はキャッシュ戦略の「即時反映」節を参照してください。

設定値（運用担当が直接編集することはありません）¶

環境変数	役割	配置先
`STOREFRONT_REVALIDATE_URL`	WordPress から POST する Storefront の revalidate endpoint URL（任意）	`b2b-ecommerce/{env}/wp`
`CMS_REVALIDATE_SECRET`	`x-cms-revalidate-secret` ヘッダで送る共有 secret	`b2b-ecommerce/{env}/shared`（正本）

STOREFRONT_REVALIDATE_URL が未設定の場合、STOREFRONT_URL + /api/revalidate/cms にフォールバックします。

Webhook が動かないときの一次切り分け¶

WordPress 管理画面で 設定 → ストア設定 などを 何も変えずに保存 する（少なくとも acf/save_post で event が発火するか確認するため）
Storefront 側の Sentry / Cloudflare Workers ログで POST /api/revalidate/cms の到達を確認する
到達していない場合: WordPress コンテナの error log を確認する。[ritsubi] storefront revalidate failed が出ていれば、STOREFRONT_REVALIDATE_URL / CMS_REVALIDATE_SECRET を疑う
到達しているが反映されない場合: Vendure plugin の WP fetch cache 経由の遅延を疑い、最大 5 分待つ。menu に限っては bypass 済みなので、即時反映されるはず

緊急時に手動で revalidate を叩きたい場合（運用フォールバック）:

# CMS_REVALIDATE_SECRET は b2b-ecommerce/<env>/shared から取得
curl -X POST https://<storefront-host>/api/revalidate/cms \
  -H 'content-type: application/json' \
  -H "x-cms-revalidate-secret: <secret>" \
  -d '{"event":"menu.updated"}'

event には menu.updated, announcement.updated, campaign.updated, page.updated, product.updated, settings.updated, all のいずれかを指定します。

トラブルシューティング¶

コンテンツがサイトに表示されない¶

確認事項:

公開状態が「公開」になっているか
公開日時が過去になっているか
GraphQL APIで取得できるか（開発者ツールで確認）

解決方法:

公開状態を「公開」に変更
公開日時を過去の日時に設定
ブラウザのキャッシュをクリア

フッター / ヘッダーのメニュー編集が反映されない¶

確認事項:

編集後 「メニューを保存」 を確実にクリックしたか（並び替えだけでは保存されません）
「メニュー設定 → 表示位置」で Primary Navigation または Footer Navigation にチェックが入っているか
メニュー項目の displayType が想定通りか（text_block を選ぶとフッター上段の自由文として描画されます）
Storefront 側で同じページをハードリロードしたか
「Storefront への即時反映 → Webhook が動かないときの一次切り分け」で webhook 到達を確認

解決方法:

メニュー位置のチェックを入れ直して再度「メニューを保存」する
それでも反映されない場合、緊急回避として手動 curl で event: "menu.updated" を送る（同節参照）
WordPress コンテナの error log に [ritsubi] storefront revalidate failed が出ていれば、STOREFRONT_REVALIDATE_URL / CMS_REVALIDATE_SECRET の設定を保守窓口へエスカレーションする

画像が表示されない¶

確認事項:

画像がアップロードされているか
画像のURLが正しいか
画像のファイルサイズが適切か（500KB以下推奨）

解決方法:

画像を再アップロード
画像のファイルサイズを確認・最適化
画像形式を確認（WebP、JPEG、PNG推奨）

表示順序が正しくない¶

確認事項:

order フィールドが正しく設定されているか
同じ order 値の場合は、公開日時の新しい順に表示される

解決方法:

order フィールドに一意の数値を設定
公開日時を調整

フィーチャー済みお知らせが表示されない¶

確認事項:

isFeatured が true に設定されているか
公開状態が「公開」になっているか
Storefront サーバーで VENDURE_BASE_URL / VITE_PUBLIC_VENDURE_BASE_URL が正しく設定され、Vendure shop-api 経由の CMS 取得が成功しているか

解決方法:

isFeatured を true に設定
公開状態を確認
サーバーログでデバッグ情報を確認（開発環境）

詳細はフィーチャー済みお知らせバナー機能を参照してください。

ACF フィールドや設定画面が欠けている¶

症状例:

ストア設定 や メインバナー の入力 UI が消えた
投稿タイプは見えるが必要な ACF フィールドが出ない
ローカル bootstrap 後に管理画面の構成が毎回変わる

確認事項:

just wp-drift-audit を実行し、acf-field-groups / required-post-types / required-options-pages の結果を確認する
ACF JSON 正本 (apps/wordpress-cms/plugins/ritsubi-ec-plugin/acf-json/) に期待する定義が存在するか確認する
plugin 配備直後なら just wp-acf-sync または just wp-bootstrap-verify を再実行する

解決方法:

管理画面を直接直すのではなく、まず JSON 正本と audit 結果の不一致を解消する
local の初期化直後であれば just wp-bootstrap -> just wp-drift-audit で再確認する
staging / production は just wp-drift-audit-vps <env> の結果をもとに deploy 差分か live 設定差分かを切り分ける

詳細は WordPress Drift 運用 Runbook を参照してください。

GraphQLエンドポイントに接続できない¶

プローブ使い分けの注意

/api/health/cms は Tier 3 診断用途です。Vendure および WordPress upstream へのファンアウトが発生するため、継続的なスケジュール監視には使わないでください。通常の死活監視は /api/health/live、/api/health/ready、/api/version（Tier 0 Safe Probe）を使用します。これらのエンドポイントは .github/workflows/scheduled-safe-probes.yml が30分ごとに自動確認します。

確認事項:

Vendure サーバー側の WORDPRESS_ENDPOINT（内部で /graphql を付与）が正しいか
/api/health/cms の vendureCms.status が ok か（診断時のみ）
WordPress 側の上流疎通も疑う場合は /api/health/cms の upstreamCms.status が ok か（診断時のみ）
WordPress 側でパーマリンク設定・WPGraphQL が有効か

解決方法:

エンドポイントURLを確認（/graphql または index.php?graphql）
Storefront の通常導線は Vendure shop-api 経由であることを前提に、まず vendureCms を確認する
パーマリンク設定を確認（推奨: 数字ベース）
環境変数を確認・更新

詳細は WordPress CMSローカル開発環境を参照してください。

よくある質問（FAQ）¶

Q: `/api/health/live` や `/api/health/ready` があるのに、なぜ `/api/health/cms` が別にあるのか¶

A: それぞれが答える問いが違うためです。

/api/health/live → アプリのプロセスが生きているかだけを確認します
/api/health/ready → アプリが起動・初期化を終えてリクエストを受け付けられるかを確認します
/api/health/cms → Vendure→WordPress のコンテンツ取得経路が健全かを診断します

WordPress が停止していても、アプリ自体は live かつ ready のままです。CMS コンテンツが表示されない原因を調べるとき初めて /api/health/cms を使います。

Q: `/api/health/cms` はスケジュール監視に使えるか¶

A: 使わないでください。/api/health/cms を呼ぶたびに Vendure と WordPress upstream の両方へ実際にリクエストが飛びます（ファンアウト）。高頻度で実行すると WordPress に不要な負荷がかかり、Vendure のヘルスチェック判定にも誤影響が出る恐れがあります。

継続的な死活監視は .github/workflows/scheduled-safe-probes.yml が30分ごとに実行する Tier 0 Safe Probe（/api/health/live・/api/health/ready・/api/version）で十分です。/api/health/cms は障害調査など必要なときだけ手動で一度呼ぶものとして扱ってください。

Q: `/api/health/cms` で `vendureCms` と `upstreamCms` の意味が分からない¶

A: 2つのフィールドで障害箇所を絞り込めます。

フィールド	意味	`fail` のとき疑う箇所
`vendureCms.status`	Vendure（CmsIntegrationPlugin）側で CMS データを取得・整形できているか	Vendure の環境変数・プラグイン設定
`upstreamCms.status`	Vendure から WordPress（upstream）へ直接疎通できているか	WordPress 本体・WPGraphQL・ネットワーク

両方 fail → Vendure→WordPress 経路全体に問題。vendureCms だけ fail → Vendure 側の設定ミス。upstreamCms だけ fail → WordPress 本体か upstream ネットワークに問題（Vendure がキャッシュで応答している可能性あり）。

詳細は WordPress CMS統合ガイドの「ランブック: コンテンツが見えないがアプリは生きている」を参照してください。

Q: お知らせを削除しても、サイトに表示され続ける¶

A: 通常は WordPress 保存と同時に Storefront の revalidation webhook が Storefront / Vendure CMS cache を無効化するため、即時にサイトから消えます。それでも残る場合は次の順で確認してください。

WordPress 上で本当に publish 状態を解除したか: 「ゴミ箱へ移動」または「下書きへ戻す」を実行する。draft → draft の保存は webhook が発火しません。
Webhook が Storefront へ届いているか: 「Storefront への即時反映 → Webhook が動かないときの一次切り分け」を参照。
Vendure plugin 側のメモリキャッシュ: お知らせ・キャンペーン・固定ページは Vendure 側に最大 5 分のキャッシュがあるため、削除直後は古いリストが返ることがあります。/api/revalidate/cms が叩かれていれば Storefront 側 cache はクリア済みなので、最大 5 分待てば次回フェッチで消えます。
ブラウザキャッシュ: 上記すべてに該当しない場合のみ、最終手段としてハードリロード（Ctrl+Shift+R）を試す。

Q: カスタムフィールドが表示されない¶

A: 以下の点を確認してください：

フィールドグループが正しい投稿タイプに割り当てられているか
ACFプラグインが有効化されているか
ページをリロードしてみる

Q: 画像をアップロードできない¶

A: 以下の点を確認してください：

ファイルサイズが上限を超えていないか（通常5MB以下）
ファイル形式がサポートされているか（JPEG、PNG、WebP、GIF）
サーバーのディスク容量が不足していないか

Q: 公開日時を変更しても反映されない¶

A: 公開日時を変更した後、「更新」ボタンをクリックして保存してください。また、表示順序は公開日時の新しい順になります。

サポート・問い合わせ¶

技術的な問題や質問がある場合は、開発チームに問い合わせてください。

WordPress CMS操作マニュアル¶

目次¶

基本操作ガイド¶

WordPress管理画面へのアクセス¶

管理画面の構成¶

基本的な操作フロー¶

コンテンツタイプ別操作ガイド¶

本文内の商品リスト埋め込み¶

お知らせ（Announcement）¶

作成手順¶

カスタムフィールド（ACF）¶

isFeatured（フィーチャー済み）¶

relatedLink（関連リンク）¶

運用ルール・補足情報¶

キャンペーン（Campaign）¶

基本手順¶

Storefront で表示される条件¶

カスタムフィールド（ACF）¶

order（表示順序）¶

image（キャンペーン画像）¶

運用ルール・補足情報¶

メインバナー（ホームヒーロー）¶

編集手順¶

カスタムフィールド（ACF）¶

slides（スライド）¶

campaign 連動と通常バナーの違い¶

画像ガイドライン¶

仕様の正本¶

運用ルール・補足情報¶

ストア設定のSNSリンク¶

編集手順¶

入力ルール¶

注意事項¶

ブランド情報の管理先¶

Vendure 側の運用ルール¶

注意事項¶

サポート / 固定ページ（Page）¶

サポートトップ（/support）¶

サポート子ページ（例: /support/contact）の追加手順¶

注意事項¶

ナビゲーション（ヘッダー / フッター）の編集¶

概要¶

編集手順¶

注意事項¶

反映確認¶

ACFカスタムフィールドの設定と使用¶

ACFとは¶

このプロジェクトでの ACF 運用原則¶

カスタムフィールドの見つけ方¶

フィールドの入力方法¶

よくある質問¶

Q: カスタムフィールドが表示されない¶

Q: フィールドの値を変更しても反映されない¶

設定・管理機能¶

パーマリンク設定¶

推奨設定¶

設定の影響¶

公開状態の管理¶

公開日時の設定¶

Storefront への即時反映（Webhook）¶

反映の対象と event¶

反映されるまでの時間¶

設定値（運用担当が直接編集することはありません）¶

Webhook が動かないときの一次切り分け¶

トラブルシューティング¶

コンテンツがサイトに表示されない¶

フッター / ヘッダーのメニュー編集が反映されない¶

画像が表示されない¶

表示順序が正しくない¶

フィーチャー済みお知らせが表示されない¶

ACF フィールドや設定画面が欠けている¶

GraphQLエンドポイントに接続できない¶

関連ドキュメント¶

操作マニュアル¶

技術ドキュメント¶

機能別ドキュメント¶

よくある質問（FAQ）¶

Q: /api/health/live や /api/health/ready があるのに、なぜ /api/health/cms が別にあるのか¶

Q: /api/health/cms はスケジュール監視に使えるか¶

Q: /api/health/cms で vendureCms と upstreamCms の意味が分からない¶

`isFeatured`（フィーチャー済み）¶

`relatedLink`（関連リンク）¶

`order`（表示順序）¶

`image`（キャンペーン画像）¶

`slides`（スライド）¶

サポートトップ（`/support`）¶

サポート子ページ（例: `/support/contact`）の追加手順¶

Q: `/api/health/live` や `/api/health/ready` があるのに、なぜ `/api/health/cms` が別にあるのか¶

Q: `/api/health/cms` はスケジュール監視に使えるか¶

Q: `/api/health/cms` で `vendureCms` と `upstreamCms` の意味が分からない¶