experience-search-coordinate

検索コーディネーター

検索リクエストを適切なサブワークフロー（構造化された CMS コンテンツまたはメディア）に振り分けます。リクエストに両方が含まれる場合は、両方を実行します。

以下の → Read の指示は必須のアクションであり、参考情報ではありません — その先へ進む前に、指定されたファイルを開いてください。このスキルでは、手順を記憶に頼って進めたことで、以前に内容とのずれが生じています。

対象範囲

このスキルは、既存のコンテンツやメディアの検索に使用します。新しいコンテンツや画像の作成には使用しません。

ユーザーが次のことを求めている場合は、このスキルを使用してください。

• 記事、ブログ投稿、ニュース、FAQ、イベント、製品、カスタムコンテンツを検索する
• 画像、ロゴ、アイコン、写真、グラフィック、バナー、ヒーロー画像、音声クリップ、動画、ドキュメントを検索する
• 新しいものを作成するのではなく既存のアセットを再利用する、または上記を組み合わせて依頼する

ユーザーが次のことを求めている場合は、このスキルを使用しないでください。

• 新しいコンテンツを生成する（experience-cms-content-generate を使用）
• 新しい画像を生成する（画像生成ツールを使用）
• コンテンツタイプのスキーマを定義する（experience-cms-content-type-generate を使用）
• ブランドガイドラインを適用する（experience-cms-brand-apply を使用）
• コンテンツレコードを作成、編集、公開する

ステップ 1：チャネルの対象範囲を決定する

このステップに到達したすべてのリクエストで必ず実行してください。ステップ 2 に進んで済ませることはできません。 「記事を見つけて」「キーワードで検索して」といったリクエストの表現にかかわらず、このステップのローカルファイルのスキャンを省略することはできません。このターンで uiBundles/*/public/content-metadata.json をスキャンしていないまま、ステップ 2 で search_metadata を呼び出そうとしている場合は、いったん停止して、先にここへ戻ってください。

1. channelId が明示されている — その値を直接使用し、検出を完全に省略して、以下の対象範囲のルールへ進みます。
2. uiBundle／アプリが指定されていて、channelId がない — その uiBundle の channelId を解決します。解決できない場合は、何も指定されていないものとしてポイント 3 に進みます。
3. それ以外の場合は、ローカルプロジェクトから検出する — uiBundles/*/public/content-metadata.json ファイルをすべてスキャンし（サーバー側のデプロイ状況を条件にしてはいけません）、見つかった channelId を収集します。0 件の場合は公開チャネルのみ。ちょうど 1 件の場合は、公開チャネルとそのチャネル。2 件以上の場合は、ask_followup_question を使ってユーザーにどのチャネルか確認します。

→ 上記のポイント 1〜3 を実行する前に、検出の具体的な手順について references/scope-resolution.md の §「Step 1 points 1-3」を読んでください。対象範囲が決まったら、ステップ 2 に進みます。

対象範囲のルール（channelId がユーザーから指定された場合も、検出された場合も適用）： 対象範囲には常に、公開チャネル（contentAccessScope: "Public" を指定し、channelIds フィールドは指定しない）と、その 1 つの channelId（channelIds を設定した別の呼び出しとし、contentAccessScope フィールドは指定しない）を含めます。「公開」を表す別個の ID を解決してはならず、同じ呼び出しで contentAccessScope と channelIds を指定してはいけません。この対象範囲によって、ステップ 3 と 4 で行う検索呼び出しの回数が決まります。 対象範囲に channelId がない場合は、検索を 1 回呼び出します（公開チャネルのみ）。対象範囲に channelId がある場合は、検索を 2 回呼び出します（公開チャネル、次にその特定の channelId）。提示する前に結果を統合します。

ステップ 2：コンテンツタイプを判断して振り分ける

前提条件：このターンでステップ 1 をすでに実行していること（そのチャネル対象範囲の結果を、以下のポイント 5 でステップ 3／4 に引き継ぎます）。ステップ 1 は必ず実行します。明確なチャネル関連の意図がない単純なキーワード検索であっても、リクエストでチャネルやアプリが指定されている場合に限りません。

1. リクエスト内の、個別に検索すべき意図を 1 つ以上特定します（例：「ローンチに関するプレスリリースと、ページ用のヒーロー画像を探して」は 2 つの意図です）。このステップの残りは、意図ごとに 1 回実行します。

   意図が両方のルートにまたがる場合は、ルートを順番に実行します。交互に進めたり、統合したりしてはいけません。 まず、すべてのメディアに関する意図についてメディアルート（ステップ 4）を最後まで実行し、その後、すべてのコンテンツに関する意図についてコンテンツルート（ステップ 3）を実行します。ステップ 5 を参照してください。

2. metadata-grounding MCP サーバーで search_metadata を呼び出し、意図そのものをクエリとして使用します。filters 配列はサポートされていません — 絞り込みパラメーターは metadataType のみで、トップレベルに渡します。

   search_metadata({ query: "<the user's intent>", metadataType: "ContentTypeBundle", limit: 100 })
   

各候補には、すでに完全な複合識別子（例: 00DVW00000CfBQP2A3::0T1VW000008sow60AA::ContentTypeBundle）が含まれています。返されたものをそのまま使用し、決して再構築しないでください。

他の何かを行う前に、結果を確認してください:

• metadata-grounding が利用不可（呼び出しがエラーになる／タイムアウトする） — ステップ 3/4 の検索ツールより前に、必ず get_content_types_for_workspace（ワークスペースのコンテンツタイプのフォールバック）を呼び出してください。query_metadata を試みないでください。参照するものは何もなく、想定した FQN で検索ツールへ直接スキップしないでください。
• 候補がゼロ件返された — 意図を絞り込むための明確化の質問を 1 つユーザーに尋ね（ask_followup_question、このステップの最後にある「意図そのものが曖昧」の場合と同じ質問／選択肢）、その後、明確化したクエリで search_metadata を 1 回再試行してください:
  • その 1 回の再試行後も依然として候補がゼロ件 — ワークスペースのコンテンツタイプのフォールバックを適用してください。2 回目の明確化の質問はしないでください。
  • 再試行で 1 件以上の候補 — ポイント 3 に進んでください。
• 最初の呼び出しで 1 件以上の候補 — ポイント 3 に進んでください。

search_metadata が使用可能な候補リストを生成しない場合のフォールバックチェーン → 実行する前に references/content-type-discovery.md を読んでください: まず「ワークスペースのコンテンツタイプのフォールバック」、次に最後の手段として「文言のフォールバック」です。

3. query_metadata を呼び出す — ポイント 2 の各候補の識別子を指定します（上位 5 件までに限定し、1 つの metadataIdentifiers 配列にまとめます）:

   query_metadata({ metadataIdentifiers: ["00DVW00000CfBQP2A3::0T1VW000008sow60AA::ContentTypeBundle"] })
   

   各エントリの typeDetails[].properties を読んでください — mixins、typeClasses、apiName はそこにあり、search_metadata のレスポンスにはありません。

4. まず対応している型でフィルタリングし、その後で残ったものの中からルートを決定します — この 2 つを混同しないでください:

   • properties.mixins に sfdc_cms:deliveryApiEnabled がない候補は破棄してください — 検索可能なのは delivery API が有効な型のみです。
   • 残りのうち、properties.typeClasses に sfdc_cms__structured がないものは破棄してください。 これが唯一の「検索に対応」するゲートであり、コンテンツ／メディアの分割ではありません — sfdc_cms__structured は構造化コンテンツ型とメディア型の両方に現れるため、検索可能な型と検索不可能な型を分けるだけです（例: sfdc_cms__email は sfdc_cms__content を持ちますが sfdc_cms__structured を持たないため、破棄する必要があります）。
   • ゼロ件しか残らない — どの型が見つかったが対応していないかをユーザーに伝え、その後停止してください（ルートを推測しないでください）。一部だけが残る（すべてではない） — どれがフィルタで除外されたかをユーザーに伝え（質問ではなく単純な陈述として）、残ったもので続行してください。すべてが残る — メッセージは不要です。 → 正確な文言については references/content-type-discovery.md の「フィルタ結果のメッセージ」を読んでください。
   • 最上位にランクされた残存候補の properties.typeClasses でルートを決定します（search_metadata が返した順序）: sfdc_cms__media を含む → メディアルート（ステップ 4）、それ以外 → コンテンツルート（ステップ 3）。
   • FQN を収集します — 最上位にランクされた残存候補の properties.apiName です。同じ意図に明確に関連し、同じ分類を共有する他の残存候補の FQN も追加し、型ごとに検索するのではなく、すべてを 1 つのカンマ区切りの contentTypeFqn 値として渡してください。

5. ステップ 1 のスコープを引き継ぎます（パブリックチャネルのみ、またはパブリックチャネルに加えて channelId）— 呼び出されるどちらのルートにも引き継いでください — 以下の各ルートの channelIds フィールドを参照してください。

意図そのものが曖昧な場合（例: 型や主題の手がかりが一切ない「何かコンテンツを探して」）→ search_metadata を呼び出す前に、正確な質問／選択肢について references/content-type-discovery.md の「意図そのものが曖昧」を読んでください。推測しないでください。

ステップ 3：コンテンツルート

ステップ 2 でここに振り分けられた各インテントについて、以下の手順に従います。コンテンツタイプの FQN は、ステップ 2 ですでに特定されています。

1. 検索クエリを作成します：

   • キーワードを抽出します — コンテンツのタイトルや本文に含まれる具体的な名詞と固有の対象です。ドメイン固有の同義語を使い、最大 10 個の語句を OR でつなぎます。例：「持続可能なビジネス慣行に関するブログ投稿」→ sustainable OR sustainability OR business OR environmental。
   • 分類を抽出します — 説明的な特性、カテゴリ、またはトピックタグのみです（形容詞、カテゴリ、属性。具体的な名詞は含みません）。{"OR": ["term1", "term2"]} の形式にし、該当するものがなければ "{}" とします。例：「持続可能なビジネス慣行と環境への責任」→ {"OR": ["Business", "Corporate", "Environment", "Responsibility"]}、「パスワードリセットに関する FAQ」→ "{}"（説明的・分類的な語句なし）。
   • リクエストペイロードの構造を確認するため、assets/search-payload-template.json を読み込みます。contentTypeFqn には、ステップ 2 で収集した FQN のカンマ区切りリストを設定します。contentAccessScope と channelIds は相互排他的です。同じ呼び出しで両方を送信しないでください。そのため、ここではなく、以下のポイント 3 で呼び出しごとに設定します。

2. ユーザーに確認します — 必須の 2 メッセージパターン（ラベル付きパラメーターのチャットメッセージの後に、Yes - search now／Edit search／Cancel を選択肢とする ask_followup_question）。ラベル付きリストを ask_followup_question のテキストに含めないでください。書式が失われます。→ テンプレートについては references/content-route.md §「検索前のクエリ確認」を参照してください。

3. ステップ 1 のスコープに従って検索呼び出しを実行します — パブリックのみのスコープでは 1 回、channelId がスコープに含まれる場合は 2 回（パブリックとチャネルスコープ）。結果を解析する前に、配列と統合のルールについて references/content-route.md §「検索呼び出しの実行」を参照してください。

4. コンテンツタイプごとにグループ化して、最大 5 件の一意な結果を提示します（表示上のみ managedContentKey で重複を除外します。複数のチャネルで見つかった項目も、ここでは 1 回だけ表示します）。残りの結果がある場合は、Load More オプションも表示します。各項目には、グループ化キーとしてではなく、項目ごとのフィールドとしてチャネルを表示します：

   I found 3 content items:
   
   Editorial (c__Editorial):
   1. <title> — Channel: Public
   2. <title> — Channel: <uiBundle>
   
   Blog (sfdc_cms__blog):
   3. <title> — Channel: Public
   

   スコープ内のコンテンツタイプ FQN が 1 つだけの場合は、見出しを省略してもかまいません（グループは 1 つのままです）。項目ごとのチャネルフィールドは常に表示します。項目が複数のチャネルに存在する場合は、ここでは最初のチャネル／優先チャネルを表示します。チャネルの選択は提示時ではなく、選択後に行います（ポイント 5）。

5. ユーザーが 1 件、複数件、またはすべての項目を選択します。選択された各項目の配信詳細配列に複数のエントリーがある場合は、詳細を表示する前に、どのチャネルのコピーを使用するかを尋ねます — managedContentChannelDetails.name を使って各エントリー名を付け、ask_followup_question の選択肢をエントリーごとに 1 つ設定します。エントリーが 0 個または 1 個の項目は、そのまま詳細を表示します。managedContentId、managedContentKey、language、チャネルを表示します。また、contentUrl がある PUBLIC_UNAUTHENTICATED／COMMUNITY エントリーの場合に限り、完全な未認証 URL（すべてのクエリパラメーターを含む）を表示します。WEB_APP エントリーでは表示しません。質問する前に references/content-route.md §「選択時のチャネルの特定」を参照してください。チャネル名は ask_followup_question の options 配列に渡し、質問文に直接含めないでください。

6. スコープ内の channelId が uiBundle の検出によって得られた場合は（パブリックのみのスコープ、または uiBundle を使わずユーザーから提供された channelId の場合は、この手順全体を省略します）、experience-cms-content-render への引き継ぎを、同じ 2 メッセージパターンで提案します。各項目の title、コンテンツタイプ FQN、選択したエントリーの managedContentChannelDetails.id（チャネル ID）を渡します。ただし配信エントリーがある場合のみ渡し、エントリーが 0 個の項目では省略します。プレースホルダーは決して渡さないでください。また、未認証 URL があればそれを、なければ managedContentKey を contentKey として渡します（受け取り先スキルのフィールド名です）。→ 全手順については references/content-route.md §「レンダリングへの引き継ぎの提案」を参照してください。

→ エンドツーエンドの完全な例については references/content-route.md を参照してください。

ステップ 4：メディアルート

ステップ 2 でここにルーティングされた各インテントについて、以下の手順に従います。メディアのコンテンツタイプ FQN（例：sfdc_cms__image、sfdc_cms__audio、sfdc_cms__video、sfdc_cms__document）は、ステップ 2 ですでに判明しています。画像だと決めつけず、このインテントについてステップ 2 で特定した FQN を使用してください。

1. ask_followup_question を使って利用可能な検索ソースを提示します。まだ他のツールは呼び出さないでください。 実際に利用できるツール（イントロスペクション経由で確認）に対応するソースと「その他」のみを、それぞれ個別の選択肢として提示します。ツールを呼び出す前に、ユーザーの選択を待ちます。→ 完全なテンプレートについては references/media-route.md の「利用可能な検索ソースの提示」を参照してください。
2. クエリを作成してから、検索前にユーザーに確認します。必須の 2 メッセージパターンで、同じターン内に行います。
   • キーワードを使った検索（search_media_cms_channels）：キーワード（具体的な名詞、最大 10 語）と分類語（説明、スタイル、ムード、カテゴリに関する語）を抽出します。クエリに実際に含まれている分類語はすべて抽出してください。キーワードが見つかったというだけで、分類語を空にしないでください。例：「川を望む高級マンション」→ キーワード apartment OR villa OR penthouse OR residence、分類語 {"OR": ["Luxury", "Premium", "Waterfront", "Riverside"]}。「車」→ 分類語 "{}"（説明的な語なし）。contentTypeFqn にステップ 2 の FQN（複数可）を設定し、searchLanguage にロケール（en_US、es_MX など。デフォルトは en_US。必須。null にしたり省略したりしないでください）、searchLimit: 5 を設定してペイロードを作成します。→ 詳細な例については references/media-route.md を参照してください。
   • Data 360 ハイブリッド検索を使った検索（search_electronic_media）：searchQuery はそのまま使用します。スキーマに記載されている場合に限り、ISO 形式の言語コードを指定します。必ず先に確認してください。結果が 0 件の場合、または言語エラーが発生した場合は、それを指定せずに 1 回再試行してよいか、ユーザーに確認します。サーバーエラーの後は再試行しないでください → references/media-route.md。
   • その他 — 直接 URL、アセットライブラリのパス、または確認する特定のシステムをユーザーに尋ねます（ツールを呼び出さないため、確認手順は不要です）。 → 検索前のクエリ確認用メッセージテンプレート（ラベル付きパラメーターのチャットメッセージ、続いて Yes - search now / Edit search / Cancel を伴う ask_followup_question）については、references/media-route.md の「検索前のクエリ確認」節を参照してください。
3. ステップ 1 のスコープに従って検索呼び出しを実行します — 公開のみのスコープでは 1 回、channelId がスコープに含まれる場合は 2 回（公開 + チャネル指定）。Data 360 のハイブリッド検索はチャネルスコープを完全に無視します。→ 結果を解析する前に、配列／マージのルールについて references/media-route.md の「検索呼び出しの実行」節を参照してください。
4. ask_followup_question を介して、重複を除いたすべての結果をコンテンツタイプごとにグループ化して提示します — 結果ごとに 1 つの選択肢（表示のみを目的として一意の識別子で重複排除 — 複数のチャネルで見つかった項目もここでは 1 回だけ表示されます）、タイトル、コンテンツタイプ、チャネルでラベル付けします（例: Product Launch Hero Banner (sfdc_cms__image) — Public）。Content Route と同じ構成です。コンテンツタイプがグループ化のキーであり、チャネルは項目ごとのフィールドです。自動選択は決して行いません。
5. ユーザーが項目を選択します。その delivery-details 配列に複数のエントリがある場合は、詳細を表示する前に、どのチャネルのコピーを使用するかを尋ねます — エントリごとに 1 つの選択肢で、managedContentChannelDetails.name から名前を付けます。Content Name、Content Type、チャネル、そして — contentUrl を持つ PUBLIC_UNAUTHENTICATED／COMMUNITY のエントリに対してのみで、WEB_APP のエントリには決して表示しません — 完全な Unauthenticated URL（すべてのクエリパラメーターを含む）を表示します。→ 尋ねる前に、references/media-route.md の「選択時のチャネルの曖昧性解消」節を参照してください — チャネル名は ask_followup_question の options 配列として渡し、質問テキストにインラインで含めないでください。
6. レンダリングへのハンドオフを提示します — 常に、uiBundle によるゲートなしで行います（uiBundle チャネルがスコープに含まれる場合にのみ表示される Content Route の提示とは異なります）。同じ 2 メッセージのパターンです。まず項目についてのプレーンテキストでの言及、続いて Yes / No を伴う ask_followup_question。Yes の場合は、mcp__skill_bridge__load_skill("experience-cms-content-render") を介してディスパッチします — 組み込みの Skill ツールは決して使用しないでください（別のレジストリであり、Unknown skill を返します） — 選択した項目の title、コンテンツタイプの FQN、選択したエントリの managedContentChannelDetails.id（チャネル ID）は配信エントリがある場合にのみ渡します — このルートはエントリが 0 件の項目を明示的にサポートしているため、そのような場合は何もないところから .id を読み取るのではなくチャネル ID を省略してください、そしてその Unauthenticated URL、または存在しない場合は managedContentKey を contentKey として（受け取り側スキルのフィールド名）渡します。ロード呼び出しが失敗した場合は、ハンドオフが失敗したことをユーザーに伝えて停止します。No の場合は停止します — 検索は完了です。フォールバックとして自分で URL を適用しないでください。

→ 完全な実例については、references/media-route.md を参照してください。

ステップ 5: 結合結果の提示

リクエストがメディアとコンテンツの意図を混在させている場合は、2 つのルートを順番に、それぞれ完全に完了するまで実行し、交互に実行したり、1 つの結合された提示にマージしたりしないでください:

1. まず Media Route — メディアの意図ごとに、ステップ 4 を完全に実行します。ソースを提示し、クエリを構築／確認し、検索し、結果を提示し、ユーザーに選択させ、（ポイント 6）experience-cms-content-render ハンドオフ（Yes/No）を提示します。Content Route を開始する前に、このルート全体（提示を含む）を完了してください。
2. 次に Content Route — コンテンツの意図ごとに、ステップ 3 を完全に実行します。クエリを構築／確認し、検索し、コンテンツタイプごとにグループ化して結果を提示し（チャネルは項目ごとに表示）、ユーザーに選択させ、（ポイント 6）uiBundle チャネルがスコープに含まれる場合は experience-cms-content-render ハンドオフを提示します。

各ルートの結果はラベル付けされ、それぞれ単独で提示されます（例: Media Route の出力には「Images:」、続いて Content Route には「Articles:」） — 2 つを 1 つの未分化なリストにマージしたり、Media Route の結果を保留して Content Route の結果と並べて提示したりしないでください。

エラー処理

エラー	応答
イントロスペクションで search_content_cms_channels／search_media_cms_channels ツールが見つからない	"コンテンツ検索接続が設定されていません。コンテンツ読み取り専用の MCP サーバーに接続してください。"
どちらのメディアツールも利用できない	"現在、自動メディア検索ソースが設定されていません。直接 URL またはアセットライブラリのパスを指定してください。"
metadata-grounding が利用できない、または一致するコンテンツタイプがない	references/content-type-discovery.md のフォールバック手順を適用してください。処理を中断したり、FQN を尋ねたりしないでください。
検索結果がない（どちらの経路でも）	"[コンテンツ／メディア]が見つかりませんでした。より広いキーワードを試すか、説明的な語句を削除するか、別の[コンテンツタイプ／ソース]をお試しください。"
ユーザーの選択が無効	選択肢を再表示し、もう一度尋ねてください。
ツールがエラーを返す（入力が無効、引数が不足、その他）	エラーメッセージを表示し、修正したパラメーターで同じツールを使って再試行するよう提案してください。回避策として、別の経路の検索ツールに切り替えてはいけません（主要原則 3 を参照）。ハイブリッド言語のエラーの場合は、ユーザーの了承を得て、言語を指定しない再試行を 1 回提案してください（メディアルートを参照）。
接続先サーバーの検索ツールがサーバーエラーを返す（5xx、タイムアウト、接続失敗。「結果なし」ではない）	呼び出しを失敗とし、別のサーバーに対して黙って再試行してはいけません。 サーバーの接続／セッションを確認し、再試行まで待つようユーザーに伝えてください。

ユーザーが指定した経路で、黙って失敗してはいけません。 混在リクエストの一方の経路で結果が得られなくても、もう一方の経路の結果は提示し、その旨を明示してください。これは、接続先でエラーが発生したときに別のサーバーへ切り替えることを意味しません。上記のサーバーエラーの行を参照してください。

主要原則

1. 最初にチャネルの範囲を確定する — コンテンツタイプの検出や検索を行う前に、チャネルの範囲を確定します（ステップ 1）。
2. 最初に検索し、次に経路を決める — search_metadata と query_metadata で経路を決定します。結果がない場合に限り、get_content_types_for_workspace、次に意図を示す表現へとフォールバックします（ステップ 2）。
3. 失敗時を含め、経路をまたがない — コンテンツリクエストでメディア検索ツールを使用したり、その逆を行ったりしてはいけません。経路の検索ツールが何らかの理由でエラーになった場合は、同じツールで修正して再試行するか、停止してエラーを報告してください。回避策として別の経路のツールに切り替えてはいけません。
4. コンテンツではメタデータによるグラウンディングが必須 — コンテンツタイプの FQN を動的に検出し、ハードコードしてはいけません。
5. メディアルートはテキストのみから開始する — ソースを提示し、ツールを呼び出す前にユーザーの返答を待ちます。
6. 検索前に確認する（両方の経路） — 実行前に、ユーザーがクエリパラメーターを承認する必要があります。
7. 自動選択しない — チャネルの範囲でも両方の経路でも、常にユーザーの選択を待ちます。
8. 混在リクエストは順次実行し、メディアルートを先にする — レンダリングの提案も含めてメディアルートを完全に完了してから、コンテンツルートを開始します。各経路の結果はそれぞれ独立したラベル付きセットとして提示し、統合してはいけません。
9. エラーには適切に対処する — 経路ごとに、明確なフィードバックと代替案を提示します。
10. レンダリングは決めつけず、提案する — どちらの経路でも、引き継ぐ前に「はい／いいえ」の確認が必要です。条件だけが異なります。コンテンツルートでは uiBundle チャネルが実際に範囲に含まれている場合のみ提案し、メディアルートでは常に提案します。
11. サーバーエラー時に別のサーバーへ切り替えない — 呼び出しを失敗とし、そのサーバーのセッションを確認するようユーザーに伝えてください。別の場所で黙って再試行してはいけません。
12. チャネルではなくコンテンツタイプごとにグループ化する — 両方の経路で、チャネルは常に各項目のフィールドとし、グループ見出しにしてはいけません。
13. チャネルの曖昧さは選択時に解消し、その前には行わない — 配信詳細配列の長さにかかわらず、提示時には項目を 1 回だけ表示します。選択後にのみ、両方の経路で、managedContentChannelDetails.name による各エントリを 1 つの選択肢として、どのチャネルのコンテンツを使用するか尋ねます。
14. 認証なし URL は公開チャネル専用 — 両方の経路で、PUBLIC_UNAUTHENTICATED／COMMUNITY エントリのみを対象とし、WEB_APP（uiBundle）エントリの contentUrl は決して使用しません。