architecture-diagram-page-builder

name	architecture-diagram-page-builder
description	Adobe Experience Platform ブループリントリポジトリ用の新しいアーキテクチャ図ページの作成をガイドします。 このスキルは、新しいトップレベルのアーキテクチャ図、統合アーキテクチャページ、またはアプリケーションアーキテクチャの概要を追加する際に使用します。 アーキテクチャページでは、トップレベルのAEPとアプリケーションアーキテクチャおよび主要な統合ポイントについて説明します。詳細なユースケースは含まれません（ユースケースのpattern-builderに属するもの）。 ワークフロー全体を処理します。ページ情報の収集、マークダウン ファイルの生成、正しいトピックフォルダーへの配置、TOC.mdの更新です。
source-git-commit	4d236750286c28a8b8eb53a5bdec0645cc0e3e91
workflow-type	tm+mt
source-wordcount	1556
ht-degree	1%

アーキテクチャ図ページビルダー

このスキルでは、Adobe Experience Platform ブループリントリポジトリ用の新しいアーキテクチャ図ページの作成について説明します。 アーキテクチャ図ページでは、AEPとAdobeのアプリケーションがどのように連携するのか、それらのアプリケーション間の主要なデータフロー、ソリューションを設計する際に作成者が認識する必要のある統合ポイントなど、視覚的に重要な情報を提供します。

範囲

アーキテクチャ図ページは、に焦点を当てた参照スタイルのページ​です。通常、マークダウンは40～100行で、次の内容を含みます。

• 各図の目的を簡潔に説明した1つ以上のアーキテクチャ図
• アーキテクチャがサポートするユースケースパターンへのリンク（アーキテクチャページはそのコンテンツを複製しません）
• 図に示す主要なデータフローと統合ポイントのリスト
• アプリケーションドメインの詳細については、Experience Leagueのリンクを参照してください

詳細なユースケースのコンテンツを提供する場所は​not​です。 KPI、ビジネス目標、戦術的なユースケースの例、機能、ペルソナのストーリーは、代わりにuse-case-pattern-builder スキルで生成されたユースケースパターンページに属しています。 完全なガードレールについては、references/scope-guardrails.mdを参照してください。

開始する前に読む必要があります

テンプレートとルールについては、次の参照ファイルを参照してください。

• references/diagram-template.md - プレースホルダー値を含んだ完全なマークダウンテンプレート
• references/toc-placement.md — TOC.mdのサブセクション マッピング テーブルとエントリ形式
• references/scope-guardrails.md — アーキテクチャページに属するものとユースケースパターンページに属するもののルール

フェーズ 1：情報収集

線形の面接ではなく、フォームを使用します。 一度に1つの質問をするのではなく、AskUserQuestion個のフォームを論理的に一括して提示することで、必要なすべての情報を収集します。 これにより、ユーザーは高速でスキャン可能なエクスペリエンスを維持できます。

AskUserQuestionの制約

• AskUserQuestion回の通話ごとに最大​4件の質問​件です。
• 1つの質問につき最大​4個のオプション​件です。
• 質問に4つ以上の妥当なオプションがある場合は、2つのコールに分割します（例：最初の4つのオプションを尋ね、次に5番目のオプションにyes/noを付けます）。
• 複数の回答が適用される質問（解決策、パターン、データフロー）にはmultiSelect: trueを使用します。

ラウンド 1 - コアページ情報（1回のAskUserQuestion呼び出し、最大4つの質問）

次のことを1つのフォームで要求します。

1. ページタイトル — ユーザーが既に伝えたものから派生した2～3個の候補のバリエーションと、「その他」のエスケープハッチングを表示します。
2. トピックフォルダー – 有効な5つのフォルダーをオプションとして提示します。ユーザーの入力に基づいて、最も可能性の高いフォルダーを推奨します。
3. Adobe ソリューション — マルチセレクト。ページのトピックに基づいて、最も可能性の高い候補を提案します。
4. ダイアグラム数 — ページに含まれるダイアグラム数（1 / 2 / 3 / 4+）。

ラウンド 2 – 図の詳細（AskUserQuestion呼び出し1回、最大4つの質問）

各図の画像ファイル名とページの目的を1つの形式で求めます。

• 図ごとに（1回のフォームラウンドで最大2個）、画像ファイル名​を2～3個の候補ファイル名（ページタイトルから派生）に「その他」オプションを付けた質問として要求します。
• ページの目的 （1-2文の説明）を、2-3の推奨フレーズに「その他」を加えた質問として尋ねます。
• >[!MORELIKETHIS]コールアウト​が必要かどうかを確認します（はい/いいえ）。 「はい」の場合は、フォローアップメッセージでURLとリンクテキストを収集します。

セクションタイトルと代替テキスト：​画像ファイル名がわかりやすい場合（例：fac-architecture.svg、fac-dataflow.svg）、H2 セクションタイトルと代替テキストを推測します。ユーザーに尋ねる必要はありません。 セクションタイトルとして、タイトルが大文字と小文字を区別したファイル名ステムを使用します（例：Architecture diagram、Data flow diagram）。 ファイル名があいまいかどうか確認します。

ラウンド 3 - ユースケース パターン（スキャン後にAskUserQuestion）

このフォームを提示する前に、グローバル化/help/blueprints/use-case-patterns/​し、ページタイトル、目的、ソリューションに基づいて、3 ～ 5個の一致するパターンを特定します。 提案する前に、各ファイルが存在することを確認します。

上位4人の候補者をmultiSelect件の質問として提示します。 強力な5番目の候補が存在する場合は、その候補に対して個別の「はい/いいえ」の質問を付けます。 また、見逃したパターンに名前を付けるようにユーザーを招待します。

ファイルの存在が確認されたパターンのみを含めます。 パターン名をハルシネーションしないでください。

ラウンド 4 - データフローとExperience League リンク（AskUserQuestion呼び出し1回）

データフロー： 3～5個の事前記述されたデータフロー箇条書きをmultiSelect個の質問として提案します（ページトピックから派生）。 ユーザーが適用するオプションを選択します。 各オプションをひとつの簡潔な文にまとめましょう。 ユーザーがリストに含まれていないカスタムフローを必要とする場合は、フォローアップで提供することができます。

Experience League リンク： フォームの後、記事タイトル、URL、および1行の根拠を含む4～6個の推奨リンクのマークダウンテーブルを表示します。 すべてのURLに​未確認​のマークを付けます。 ユーザーに、（a）同意する、（b）検証済みURLに置き換える、または（c）独自のURLを追加するように依頼します。 リストが長い場合は、最大4つのオプションでフォローアップ AskUserQuestionを使用します。それ以外の場合は、プレーンテキストで確認を受け入れます。

取得していないURLは絶対に作成しないでください。 不明な場合は、記事のタイトルを提案し、ユーザーがURLを入力できるようにします。

すべてのラウンドが完了すると

ファイルを生成する前に、ユーザーに設定されている情報をすべて確認してください。 必要な項目が見つからないか、値なしで「その他」とマークされている場合は、先に進む前に必要な項目を求めてください。 図、パターン、またはリンクを作成しないでください。

フェーズ 2：範囲チェック

生成する前に、ユーザーのダイアグラムの説明、データフローの箇条書き、下書きの表現を再度読みます。 references/scope-guardrails.mdからガードレールを適用します。

計画されたコンテンツに次のいずれかが表示される場合は、そのセクションをユースケースパターンページにリダイレクトするようにユーザーに警告し、提案します（またはアーキテクチャページからトリミングします）。

• KPIまたは測定式
• ビジネス目標やビジネス影響のストーリー
• 戦術的なユースケース例（特定のパーソナライゼーションシナリオ、キャンペーンの例など）
• 機能（A > B > C > D スタイル）
• ペルソナ主導のstorytelling

計画されたコンテンツがアーキテクチャページスコープ（トップレベルのアーキテクチャ、システムデータフロー、統合ポイント、デプロイメントトポロジ、エッジとハブ）内に留まる場合は、ユーザーに確認し、フェーズ 3に進みます。

フェーズ 3：コンテンツの生成

次の場所でページを生成：

/help/blueprints/{topic-folder}/{kebab-filename}.md

ソース テンプレートとしてreferences/diagram-template.mdを使用します。 すべてのプレースホルダー値を、収集した情報で入力します。 生成されるファイルには、次のものが含まれている必要があります。

1. YAML frontmatter — title、description、solutionのみ。

   • 含まないexl-id – 公開パイプラインが自動的に割り当てます。
   • 含めない product_v2、feature_v2、role_v2、topic_v2、TQID、ktまたはthumbnail – これも自動入力されます。

2. H1 heading — ページタイトル。

3. 段落を開く — ページ目的の入力から派生した1 ～ 2個の文章。

4. オプションの>[!MORELIKETHIS] ブロック — ユーザーが関連コンテンツのリンクを提供した場合のみ。

5. 図ごとに1つのH2 セクション — ユーザーが提供した順序で。 各セクションには、次の内容が含まれます。

   • H2見出しとしてのセクションタイトル

   • 1-2図の目的を説明する文

   • 標準規則を使用して埋め込まれた画像：

     <img src="assets/{filename}" alt="{Alt Text}" style="border:1px solid #4a4a4a; width:90%; margin-bottom: 15px;" class="modal-image" />
     

6. ## Use case patterns supported – 箇条書きリスト。 各弾丸：

   - [{Pattern name}](/help/blueprints/use-case-patterns/{category}/{pattern-file}.md) -- {1-line note on why this architecture enables the pattern}
   

7. ## Primary data flows and integration points — 3 ～ 7個のフロー/統合項目の箇条書きリスト。

8. ## Further reading — Experience League リンクの箇条書きリスト：

   - [{Article title}]({Experience League URL})
   

本文と箇条書きのAdobe製品名には、既存のページの規則に一致する[!DNL ...]構文を使用します。

フェーズ 4：相互参照の更新

/help/blueprints/TOC.md​を更新して、新しいページをナビゲーションに追加します。 これは、更新する唯一の相互参照ページです。

完全なサブセクション マッピング テーブルとルールのreferences/toc-placement.mdを読み取ります。 概要：

トピックフォルダー	目次サブセクション
experience-platform/	+ Architecture overviews{#architecture-overview}
experience-platform/deployment/	+ Deployment{#deployment} （アーキテクチャの概要のサブセクション）
audience-activation/	+ Audience & Profile Activation{#audience-activation}
b2b/	+ B2B activation & marketing{#b2b-activation}
customer-journey-analytics/	+ Customer Journey Analytics{#customer-journey-analytics}
customer-journeys/	+ Customer journeys{#customer-journeys}

エントリ形式（4 スペースインデント + +）:

    + [{Page title}](/help/blueprints/{topic-folder}/{filename}.md)

ユーザーが別の位置を指定しない限り、新しいエントリを一致するサブセクションの最後の項目として追加します。 4 スペースのインデントを正確に保持 – 目次解析はそれに依存します。

配置する前に、ネストされたサブグループを調べます。 一部のサブセクション（特にAudience & Profile Activation）には、ネストされたグループ化が含まれています（例：Real-Time Customer Data Platform (RTCDP) {#known-customer-audience-activation}）。 編集する前に、TOC.mdの影響を受けるサブセクションを読んでください。 新しいトップレベルアーキテクチャページは、ネストされたサブグループ内のサブセクションの4 スペースインデントレベルである​not​に属します（6 スペースインデントを使用）。 最後にネストされたサブグループエントリの後と、次の最上位サブセクション見出しの前に新しいエントリを配置します。

フェーズ 5：検証

すべてのファイルを作成して更新したら、次の点を確認し、エラーがあればユーザーに報告します。

1. 画像アセットの存在 – 各図について、/help/blueprints/{topic-folder}/assets/{filename}が存在することを確認します。 見つからない場合は​に警告します。ブロックしないでください（ユーザーはダイアグラム設計と並行してオーサリングしている可能性があります）。 見つからないファイルの明確なリストを表示して、ユーザーが何を追加すべきかを把握できるようにします。

2. ユースケースパターンリンク — ファイル内のすべてのパターンリンクは、/help/blueprints/use-case-patterns/の下にある既存のマークダウンファイルを指しています。 Readまたはグロブを使用して、各ターゲットが存在することを確認します。

3. Experience League リンク — ## Further reading セクションのすべてのURLがhttps://experienceleague.adobe.com/jaで始まることをスポットチェックします。

4. 目次エントリの配置 – 新しいエントリは正しいサブセクション内にあり、4 スペースのインデントを使用し、パスは生成されたファイルの場所と正確に一致します。

5. ファイル名 — ページのファイル名はkebab-caseで、TOC.mdで参照されているパスと一致します。

6. Frontmatter completeness — ページにはtitle、description、solutionが含まれます。 not​には、exl-id、product_v2、feature_v2、role_v2、topic_v2、TQID、ktまたはthumbnailを含める必要があります。

タスクの完了を検討する前に、検証の問題を修正します。

備考

• Adobeの製品名には、既存のページの規則に従って、本文と箇条書きで常に[!DNL ...]構文を使用します。
• アーキテクチャ図は通常、SVG（鮮明さと拡大・縮小に適しています）ですが、ラスターソースのアートワークではPNGを使用できます。
• 埋め込まれたインラインスタイル文字列（border:1px solid #4a4a4a; width:90%; margin-bottom: 15px;）とclass="modal-image"が必要です。これらは、Experience League モーダル ズーム操作を有効にします。<img>
• ユーザーがまだ存在しない新しいトピックフォルダーのページを作成する場合は、TOC.mdに+ Architecture Diagrams and Blueprints{#architecture-diagrams}の下に新しいトップレベルサブセクションが必要であることを警告します。 ユーザーの明示的な承認とは別のステップとして処理する必要があります。
• アーキテクチャ図で​単一のユースケースのエンドツーエンド （KPI、ビジネス目標、機能）を広く文書化している場合、ユーザーをuse-case-pattern-builderにリダイレクトします。これはアーキテクチャページではありません。