ドキュメントAEM as a Cloud Serviceユーザーガイド

Experience Modernization Agentのプロンプトガイド prompting-guide

Last update: Sat Apr 04 2026 00:00:00 GMT+0000 (Coordinated Universal Time)
  • 適用対象：
  • Experience Manager as a Cloud Service

作成対象：

  • ユーザー
  • 管理者
  • 開発者

Experience Modernization Agentは、自然言語のリクエストに基づいて適切なスキルを自動的に選択します。 このガイドでは、効果的なプロンプト作成のヒントと、そのスキルについて説明します。

一般的なヒント general-tips

一部のスキルは、他のスキルからの出力に依存します。 dependency

  • 一括読み込みには、ページの移行で作成されるインポートインフラストラクチャが必要なため、一括読み込みを実行する前に、少なくとも1つのページを移行してください。
  • ブロック CSSはグローバルデザイントークンを参照するため、個々のブロックをスタイル設定する前にサイト全体のデザインを完了します。

AIは構造化されたワークフローに従い、より多くの情報が必要な場合は、明確な質問をすることで対応します。 workflows

  • このプロセスを信頼し、適格性の高い質問に答えることで、
  • 最初のプロンプトですべての要件を前読みしようとしない。

プロジェクト内にマークダウンファイルを作成して、プロジェクト固有のルール、ガイドライン、設計決定、制約を文書化します。 markdown-files

  • これらのマークダウンファイル（INSTRUCTIONS.md、CONTEXT.mdなど）には、ファイルの命名規則、コンテンツマッピングルール、ブランドガイドラインが含まれます。
  • 新しい会話を開始する際は、タスクを進める前に、担当者に「プロジェクトのドキュメントを読んでウォームアップする」ように依頼し、このコンテキストを読み込みます。

エージェントのコンテキストウィンドウは無限ではありません。 limited-window

  • 長い会話の間、以前の指示は圧縮されるか忘れられるかもしれません。
  • 担当者が文脈を失っているように見える場合は、重要なポイントを思い出させるか、チャットをクリアして、プロジェクトのドキュメントを読むためのウォームアッププロンプトを新たに開始します。

反復プロンプトを使用して結果を絞り込みます。 iterate

  • 何かが正しく見えない場合（例：ブロックの背景色が間違っている場合）、最初からやり直すのではなく、特定の問題を修正するようにエージェントに促します。

サイトの作成と移行のスキル site-migration

Site Modernization Agentは、新しいEdge Delivery Services サイトを作成し、既存のweb サイトを移行するための多くのスキルを提供します。 新しいEdge Delivery サイトまたは移行プロジェクトでは、これらのスキルを活用する必要があります。

サイトまたはページのAEMへの移行 migrate-a-site

このプロンプトは、既存のweb サイトからEdge Delivery Servicesにコンテンツを移行する場合に使用します。

プロンプト例 example-migrate

  • "このページを移行：https://example.com/about
  • "これらのページを移行：URL1、URL2、URL3"

知っておくべきこと wtk-migrate

  • 移行は、次の7つのステップで構成されています。

    1. エージェントはソースページをスクレイピングします。
    2. セクション構造を識別します。
    3. オーサリング分析を実行します。
    4. コンテンツをブロックのバリエーションにマッピングします。
    5. マークダウンを生成します。
    6. 輸入インフラを作り出す。
    7. 結果がプレビューされます。

  • エージェントは、次の2 レベルの階層を使用してページを分析します。

    • 最初に、セクションの境界（背景の変更、間隔の移動）を特定します
    • 次に、各セクション内のコンテンツシーケンスを特定します。

  • オーサリング分析はDavidのモデル ​に従います

    • コンテンツシーケンスごとに、最初に「作成者は通常の入力でこれを作成できますか？」をチェックします。
    • デフォルトのコンテンツ（見出し、段落、リスト、インライン画像）は、ブロックよりも優先されます。

  • エージェントは、新しいブロックを作成する前に、リポジトリのブロックライブラリの既存のブロックを再利用しようとします。

    • コンテンツを既存のブロックにマッピングできない場合、新しいブロックのバリエーションが作成されます。
    • 変更の要求、新しいバリエーションのリクエスト、マッピングの調整をインタラクティブに行うことができます。

  • ブロックのバリエーションはメタデータで追跡されます。

    • 複数のページを移行する場合、エージェントは既存のカスタムバリアントを最初に読み込み、スタイルが一致する場合に再利用します（目的、色、タイポグラフィ、間隔、レイアウトに基づいて70%の類似度のしきい値）。

  • ヘッダー、ナビゲーション、フッターはページ移行から除外されます。 これらは、専用のスキルによって処理されます。

  • 各移行では、後で一括読み込みを行うためのインポートインフラストラクチャ（ページテンプレート、ブロックパーサー、トランスフォーマー）が作成されます。

一括読み込み bulk-import

最初の単一ページの移行を完了した後、同じテンプレートの多くのページを読み込むには、このプロンプトを使用します。

プロンプト例 example-prompts-bulk-import

  • 「URL1、URL2、URL3のページで一括読み込みを実行します。」
  • 「すべての製品ページで一括読み込みを実行する」
  • 「これらのブログページを一括インポート：URL1、URL2。」

知っておくべきこと wtk-bulk-import

  • 一括読み込みは、事前のシングルページ移行時に作成されたインポートインフラストラクチャによって異なります。
    • これには、ページテンプレート（セクション構造）、トランスフォーマー（サイト全体のDOM クリーンアップ）、およびパーサー（ブロック固有のHTMLからテーブルへの変換）が含まれます。
  • 一括読み込みを実行するには、テンプレートごとに少なくとも1つの代表ページを移行する必要があります。
  • 一括読み込みでは、単一ページの移行時に確立された構造とマッピングを再利用します。
    • テンプレートをゼロから推測することはありません。
  • トランスフォーマは、解析の前後にDOM全体で動作します。 パーサは個々のブロックレベルで動作します。
  • 一括読み込みを続行する前に、すべてのパーサーが検証されます。
  • 1つのテンプレートは、1つの一括読み込み設定に対応します。
    • 1回の実行でのテンプレートの混在はサポートされていません。

一般的なワークフロー typical-workflow

推奨されるワークフローは反復的なものです。小さなセットで検証してからスケールアップします。

  1. 最初に単一ページの移行を実行します。 – 一括インポートするテンプレートの代表ページを1つ移行します。
    • これにより、必要な読み込みインフラストラクチャが作成されます。
  2. 少数のページに対して一括読み込みを実行します。 - エージェントに一括インポートを実行し、同じテンプレートに従うURLの短いリストを提供するように依頼します。
  3. 結果を確認して調整します。 - インポートしたページを調べます。
    • 何か問題が見つかった場合は、エージェントにパーサー、トランスフォーマー、またはインポートロジックを調整するように依頼します。
  4. スケールアップ。 – 結果が正しく表示されたら、URLの完全なリストを入力します。
    • エージェントは同じインポートロジックを再利用し、一括読み込みを大規模に実行します。

Web ページのスクレイピング scraping-webpages

このプロンプトを使用して、分析または移行用にソース URLからコンテンツ、メタデータ、画像を抽出します。

プロンプト例 example-scraping

  • 「分析のためにこのページをスクレイピング：https://example.com」
  • 「https://example.com/productからコンテンツを抽出」

知っておくべきこと wtk-scraping

  • このプロンプトは通常、ページ移行の最初の手順として自動的に呼び出されます。

  • CSSで非表示になっているコンテンツも、DOMに存在する場合は取り込まれます。

  • 遅延読み込み画像とクライアント側でレンダリングされたコンテンツは、ヘッドレス Chromiumでページをスクロールし、スクリプトを実行することで処理されます。

  • WebP/AVIF/SVG画像は、互換性を保つためにPNGに変換されます。

  • タイトル、説明、Open Graph タグ、JSON-LD構造化データ、正規URLなどのメタデータが抽出されます。

  • DOMの画像は固定されています。

    • background-imageはimgに変換されます。
    • 画像要素のラップを解除
    • srcsetはsrcに解決されます
    • 相対URLは絶対URLに変換されます
    • インラインSVGからimg ファイルに変換されます。

  • 消去済みの文書パスが生成されます（小文字で.html拡張子はありません）。

  • 次の出力が生成されます。

    • screenshot.png
    • cleaned.html （スクリプト/スタイルなし）
    • metadata.json
    • ローカル コピーを含むimages/ フォルダー

  • ユーザーは、スクリーンショットのサイズについて尋ねたり、コンテンツ抽出のために特定のデバイスサイズ（モバイル、デスクトップ）を要求したりできます。

  • 複数のブレイクポイントでコンテンツを抽出すると、処理時間が増加します。

デザインの移行 design-migration

このプロンプトを使用して、ソースサイトからビジュアルデザインを抽出し、Edge Delivery Servicesに適用します。

プロンプト例 example-design

  • 「デザインをhttps://example.comから移行する」
  • 「デザイントークンの抽出」
  • 「ヒーローブロックのスタイル設定」

知っておくべきこと wtk-design

  • デザインの移行には、次の2つのフェーズがあります。

    1. フェーズ 1 （サイト全体）では、次の項目がstyles/styles.cssに抽出されます。

      • グローバルカラーパレットとアクセントカラー
      • タイポグラフィシステム（フォント、サイズ、重み）
      • 間隔システム（パディング、余白、ギャップ）
      • セクションの背景（明、暗、色付き）
      • 基本コンポーネントスタイル（ボタン、リンク、画像）
      • への出力

    2. フェーズ 2では、個々のブロック スタイルを移行し、/blocks/{name}/{name}.cssにブロック固有のCSSを作成します。

  • ブロックのスタイル設定（フェーズ 2）では、サイト全体のデザイン（フェーズ 1）を最初に完了する必要があります。

    • グローバルデザインシステムは、参照をブロックするCSS カスタムプロパティを提供します。

  • 推定時間：

    • フェーズ 1:5～10分
    • フェーズ 2:10～15分

  • あいまいな要求は、デフォルトで移行を完了します（両方のフェーズ）。

批判をブロック block-critique

このプロンプトを使用して、個々の移行ブロックを検証および調整し、元のweb サイトに対する視覚的な正確性を確保します。

プロンプト例 example-block-critique

  • 「批評家ヒーローブロック」
  • 「ブロックのカスタムカードの検証」

知っておくべきこと wtk-block-critique

  • ブロックの批判は、移行されたブロックを元のソースと比較し、85%の視覚的な類似性が達成されるか3つのイテレーションが完了するまで、CSS修正を繰り返し適用します。

  • このスキルでは、最初にページの移行によってブロックが作成されている必要があります。

  • ブロック批判は、次の6 ステップのワークフローに従います。

    1. XPath セレクターを使用して、ソースページの元のブロックをキャプチャします。
    2. 批判的セッションが始まります。
    3. 元のブロック（スクリーンショット、スタイル、HTML）を調べます。
    4. 移行されたブロックが検査されます。
    5. 要素を比較し、CSS修正を含む類似性スコアを生成します。
    6. 85%の目標に達するまで修正を適用し、再検査します。

  • 各イテレーションは、すべての違いを含む完全な批判的レポートを表示し、すべてのCSS修正を適用し（視覚的な影響で優先）、プレビューで検証し、再検査し、改善指標を表示します。

  • ​ デザインの移行が完了した後で、ブロックの条件を使用します。

ページの評価 page-critique

このプロンプトを使用して、移行されたページ全体の元のweb サイトに対するページ全体の視覚的な忠実度を検証します。

プロンプト例 example-page-critique

  • 「概要ページを批判」
  • 「移行したページをhttps://example.com/aboutに対して検証する」

知っておくべきこと wtk-page-critique

  • ページの評価では、元のページと移行されたページの視覚的な比較を全体ページにわたって実行し、85%の類似度の目標に到達するか、3回の反復が完了するまで反復します。

  • ページ批判には5つのステップがあります。

    1. 批判的なセッションが始まる。
    2. 元のページ上のすべての要素を調べます。
    3. 移行されたページのすべての要素が検査されます。
    4. 優先順位が付けられたCSS修正と類似性スコアを比較して生成します。
    5. 85%の目標に達するまで修正を適用し、再検査します。

  • ページ記述書には、ソースページ URLと移行されたパス（例：「/about」）が入力として必要です。

  • ページ全体の忠実度を検証する場合や、複数のブロックを同時に検証する場合は、ページ批判を使用します。

  • 特定のコンポーネントに焦点を絞った検証に​ ブロック批判を使用します。

  • 次のワークフローをお勧めします。

    1. ページを移行します。
    2. デザインを適用します。
    3. キーブロックに対するブロック批判の実行
    4. 完全な検証のためにアプリの年齢制限を実行します。

Figma ブロックの移行 figma-block-migration

Figma デザインからEdge Delivery Servicesにブロックを移行するには、このプロンプトを使用します。

このプロンプトを使用するには、Experience Modernization ConsoleでFigmaの詳細を設定する必要があります。

プロンプト例 example-figma

  • 「ブロック https://figma.com/design/{fileKey}?node-id={nodeId}をEdge Delivery Servicesに移行する」
  • 「{blockName}をhttps://figma.com/file/{fileKey}からEdge Delivery Servicesに移行する」

知っておくべきこと wtk-figma

  • このスキルは、ページ全体または完全なFigma ファイルではなく、一度に1つのブロックを移行します。

  • 最適な結果を得るには：

    • Figmaに移行する特定のブロックを選択し、そのリンク（node-id）または名前をコピーします。
    • 正確なブロックをターゲットにするURLにnode-id パラメーターを指定します。

  • このスキルを実行すると、次の手順がホスト環境で自動的に実行されます。

    1. ブロック構造の検出 — エージェントはFigma ノードを読み取り、レイヤーとコンポーネントを理解します。
    2. グローバルスタイル抽出 — エージェントは、色、タイポグラフィ、間隔をstyles/styles.cssにCSS カスタムプロパティ（デザイントークン）として取り込みます。
    3. ブロック固有のスタイル作成 – 移行されるブロックに固有の追加のCSS カスタムプロパティをエージェントが作成します。
    4. 既存のブロックへのマッピング — エージェントは、プロジェクトのブロックライブラリの中で最も近い一致するブロックを識別し、カスタムバリアントを作成します。
    5. CSS generation — エージェントは、抽出されたCSS カスタムプロパティを参照するスタイルを記述し、デザインの一貫性を確保します。
    6. アセットのダウンロード — エージェントは、画像とアイコンをFigmaからホスト環境のワークスペースに保存します。
    7. Edge Delivery Services content generation — エージェントは、EDS ブロック構造に従ってマークダウン ファイルを作成します
    8. 出力検証 — エージェントは結果をプレビューし、元のFigma デザインと視覚的に比較します。

  • このスキルは、まずメタデータを読み取り（ステップ 1）、構造を理解し、次に詳細なデザインコンテキストを抽出します（ステップ 2～5）。

    • この段階的なアプローチにより、大きなファイルや複雑なファイルのFigmaに関する問題を回避できます。

  • このスキルは、スタイルファーストのアプローチを採用しています。

    • すべてのスタイルは、CSSを記述する前にCSS カスタムプロパティ（デザイントークン）として抽出されます。
    • これにより、移行されたブロックがデザインシステムとの整合性を維持できます。

  • プロンプトには、Figma URL （fileKeyおよびオプション node-id）またはFigma ファイルキーが入力として直接必要です。

ナビゲーション設定 navigation-setup

サイトナビゲーションを設定または移行するには、このプロンプトを使用します。

プロンプト例 example-navigation

  • 「https://example.comからナビゲーションを設定する」
  • 「ナビゲーションメニューの修正」

知っておくべきこと wtk-navigation

  • Edge Delivery Services ナビゲーションでは、3つのセクション構造が適用されます（header.jsによって適用されます）。

    1. ブランド （セクション 1）：ロゴとプライマリブランディングリンク
    2. セクション （セクション 2）：オプションのドロップダウンを含むメインナビゲーションメニュー
    3. ツール （セクション 3）：ユーティリティ リンク（購読、ログイン、買い物かご）

  • ナビゲーションコンテンツは、ルートディレクトリのnav.mdにあります。

  • セクションは（---）マーカーで区切られています。

  • ネストされたリストを含む太字の項目（**Text**）は、ドロップダウンを作成します。

  • ナビゲーションのリンクは、ドキュメントオーサリングの自動ラッピング動作により、ボタンとしてレンダリングされる場合があります。

    • ヘッダーブロックには、ナビゲーションリンクからボタンクラスを削除するコードが含まれています。

ブロック開発機能 block-development-capabilities

これらのプロンプトは、ブロックの作成や進化に使用され、最初のサイト作成や移行にとどまらない継続的な価値を提供します。

ブロック開発 block-development

新しいブロックを作成したり、既存のブロックを変更したりするには、このプロンプトを使用します。

プロンプト例 example-block-development

  • 「顧客の声ブロックの作成」
  • 「ヒーローブロックにビデオの背景バリエーションを追加」

知っておくべきこと wtk-block-development

  • このエージェントは、すべてのEdge Delivery Services開発に必須のプロセスであるContent-Driven Development （CDD）に従います。

    • コードを記述する前に、コンテンツモデルについて尋ね、コンテンツをテストします。

  • CDDの理念は、開発者のニーズよりも作成者のニーズの方が重要であるということです。

    • コンテンツモデルは、たとえ装飾コードが複雑であっても、制作者にとって直観的なものである必要があります。

  • 最初にテストコンテンツを作成すると、次の機能が提供されます。

    • 即時のテスト機能
    • PSI チェックのPR検証リンク
    • 作成者のための生きたドキュメント
    • コードファーストのアプローチが見逃すエッジケースの発見

  • エージェントは、実装する前に​ ブロックコレクション ​および​ ブロックパーティ ​で類似のブロックを検索し、パターンと再利用可能なコードを見つけます。

  • CSSのみの微調整に対してのみCDDをスキップします（ただし、検証のためにテストコンテンツを識別します）。

コンテンツモデリング content-modeling

このプロンプトを使用して、ブロックコンテンツを作成する際に作成者が使用するテーブル構造をデザインします。

プロンプト例 example-modeling

  • 「顧客の声ブロックのコンテンツモデルの設計」
  • 「このカルーセルに最適なコンテンツモデルは何ですか？」

知っておくべきこと wtk-modeling

  • Edge Delivery Servicesには、次の4つの正規モデルタイプがあります。

    • スタンドアロン：​明確なビジュアル/ナラティブ要素（ヒーロー、blockquote）
      • ブロックの内容を含む単一テーブル
    • コレクション：​半構造化コンテンツ（カード、カルーセル）の繰り返し
      • 繰り返し行パターンを含むテーブル
    • 設定： API駆動型または動的コンテンツ（設定コントロールが表示されるブログリスト、検索結果）
      • キー値の設定行を含むテーブル。
    • 自動ブロック：​作成者がセクション/デフォルトコンテンツとして作成し、変換される複雑な構造（タブ、YouTube埋め込み）

  • 1行につき4つのセルの制限があります。

    • 関連要素をセルにグループ化します。

  • スタイルの違いについては、設定セルよりもブロックのバリエーションを優先します。

  • ​ ポステルの法則に従う：入力構造に柔軟に対応する。

    • ヒーローブロックは、コンテンツが1つのセル内にある場合でも、2つのセルに分割されている場合でも、別々の行にある場合でも機能します。

  • このスキルは、通常、ブロックの作成中にコンテンツ駆動開発によって自動的に呼び出されます。

参照ブロックの検索 reference-blocks

このプロンプトを使用して、既存の実装を検索し、開始点として使用します。

プロンプト例 example-reference

  • 「価格表に類似したブロックの検索」
  • 「顧客の声に使用できるブロックは何ですか？」
  • 「タブ実装のブロックパーティの検索」

知っておくべきこと wtk-reference

  • Block Collectionは、Adobeが管理し、ベストプラクティス、優れたコンテンツモデリング、高いパフォーマンス、アクセシビリティを備えています。

    • 一般的に必要なブロックに限定されます。 ここから始めましょう。

  • ​ ブロックパーティ ​は、コミュニティ主導であり、実験的なアプローチを含む、より幅広い種類のアプローチを提供します。

    • また、Sidekick プラグイン、ビルドツール（webpack、vite、sass）や統合も含まれます。
    • ブロック コレクションに必要な機能がない場合に使用します。

  • 検索時に代替名について考えてみましょう

    • FAQ = アコーディオン
    • Gallery = カルーセル/スライドショー
    • ナビゲーション = メニュー/ヘッダー

  • Block Partyは、承認済み/キュレートされたエントリのみを返します。

ドキュメントを検索 searching-documentation

このプロンプトを使用して、Edge Delivery Servicesの機能や実装ガイダンスに関する情報を確認します。

プロンプト例 example-documentation

  • 「Edge Delivery Servicesで遅延読み込みを実装するにはどうすればよいですか？」
  • 「ドキュメントでセクションメタデータを検索」

知っておくべきこと wtk-documentation

  • 特にaem.live ドキュメント（ドキュメントとブログ投稿）を検索します。
  • 一般的な用語（「aem」、「web サイト」、「ビルド方法」）ではなく、特定のキーワード（「ブロック装飾」、「サイドキックプラグイン」、「メタデータ」）を使用します。
  • コード例とリファレンス実装の場合は、代わりに「参照ブロックを検索」を使用します。
  • デフォルトで返される最も関連性の高い上位10件の結果。

テスト testing

このプロンプトを使用して、プルリクエストを開く前にコードの変更を検証します。

プロンプト例 example-testing

  • 「新しいカードブロックのテスト」
  • 「PRを開く前にテストを実行する」

知っておくべきこと wtk-testing

  • テストは、「価値対費用」の概念に従い、その価値がコストを超えたときにテストを作成および維持します。

    • Keeper テスト （単体テスト）は、ロジックを多用するユーティリティ、データ処理、API統合用です。 これらは高速で、メンテナンスが簡単で、再利用されたコードのリグレッションを捉えます。
    • スローアウェイテスト （ブラウザーテスト）は、DOMの変換と視覚的な検証を目的としています。 を使用して実装を検証し、PR レビュー用にスクリーンショットをキャプチャしてから破棄します。

  • 破棄されたテストはtest/tmp/で実行され、コンテンツはdrafts/tmp/でテストされます（両方とも無視されます）。

  • PRを開く前に、次のことを確認してください。

    • 既存のテストに合格
    • 単体テストは新しいロジックのために書かれている
    • ブラウザーの検証が完了しました
    • すべてのバリエーションがテストされます
    • レスポンシブ動作が検証されます
    • リンティングのパス

デバッグ debugging

このプロンプトを使用して、ブロック、画像、CSS、またはプレビューに関する問題をトラブルシューティングします。

プロンプト例 example-debugging

  • 「画像が約:errorとして表示される理由をデバッグします」
  • 「ヒーローブロックがレンダリングされない問題の修正」
  • 「変更がプレビューに表示されないのはなぜですか？」

知っておくべきこと wtk-debugging

  • 一般的な問題には既知のパターンがあります。

    • 「about:error」​を示す画像：通常、ブロック JSのcreateOptimizedPicture呼び出しが見つからないか、DOMの再構築の前に呼び出されます
    • ブロックがレンダリングされていません: マークダウンでブロック名の形式を確認し、ブロックに.jsで.cssとblocks/ ファイルの両方があることを確認します。
    • CSSが読み込まれません: ファイルのパスを確認し、CSS ファイルが存在することを確認して、ブラウザーの「ネットワーク」タブを確認します。
    • 変更が表示されない: コードの同期に3 ～ 5秒かかります。 ハードリフレッシュを試す（Ctrl+Shift+R）。

  • エージェントは、各レイヤーを体系的にチェックします。

    1. Source ファイル
    2. レンダリング出力
    3. ブロックコード
    4. ブラウザーコンソール

  • エージェントは、http://localhost:3000でローカルプレビューを確認できます。

recommendation-more-help
fbcff2a9-b6fe-4574-b04a-21e75df764ab