開発代理店の能力 development-agentic-capabilities
Adobe Experience Manager（AEM）as a Cloud Serviceの開発エージェンティック機能は、Coworker Chatと連携して、従来のAEM Java スタックの開発者および管理者が、より効率的にコードを作成、デバッグ、デプロイ、および最適化できるよう支援します。
ユースケース use-cases
さまざまなユースケースに対応：
Cloud Manager パイプラインの管理 aem-cloud-manager-pipeline-management
AEM Cloud Managerのパイプライン管理スキルを使用すると、Cloud Managerの画面を切り替えずに、必要な情報やコントロールを見つけながら、CI/CD パイプラインを自然言語で直接管理できます。 パイプラインのリスト作成、実行の開始またはキャンセル、ステータスと履歴の確認など、あらゆる作業を1つの会話から実行できます。
何か問題が発生した場合、スキルはステータスチェックにとどまりません。ステップ指標、ログ、アーティファクト、実行エラーなどを取得できるため、生のログファイルを自分でダウンロードして検索することなく、問題を診断できます。 また、日々のパイプライン設定（パイプライン変数の管理、キャッシュされたアーティファクトの無効化、パイプライン設定の調整）も処理できるので、UIを通じて数回クリックする必要があった日常的なメンテナンスタスクは、1回のリクエストで完了できます。
実行が失敗した理由については、AEM Cloud Manager パイプラインのトラブルシューティング を参照してください。
AIはミスを起こす可能性があるため、提案されたアクションを適用する前に、特に破壊的な運用に対して、そのアクションをレビューする必要があります。
「メインプログラムにはどのようなパイプラインがありますか？」
「開発環境用のコード品質パイプラインの設定」
「パイプラインの実行67890開始」
「実行12345ージの実行中のコードスキャンステップを停止」
「開発パイプラインの最後の5回の実行を表示」
「前回の実行でコードスキャンステップにかかる時間はどれくらいですか？」
「失敗したコードスキャン手順のログを取得する」
「前回の実行からビルドアーティファクトをどこでダウンロードできますか？」
「今週のプログラム 12345の失敗した実行をすべて一覧表示します。」
「パイプライン 67890のAPI_ENDPOINT変数を更新する」
「次の実行前にビルド キャッシュをクリアする」
「パイプライン 67890ータをリリースするトリガーブランチを変更する」
AEM Cloud Manager パイプラインのトラブルシューティング aem-cloud-manager-pipeline-troubleshooting
AEM Cloud Manager パイプラインのトラブルシューティングスキルを使用すると、生のログファイルを自分でダウンロードして検索することなく、パイプラインの実行が失敗した理由を確認できます。 パイプライン名または実行IDで失敗した実行を参照すると、スキルはCloud Managerでの失敗を確認し、失敗したステップを特定し、何が問題だったのか、なぜ、次に何をすべきかを簡単な言葉で説明します。 リクエストが複数のパイプラインと一致する場合、続行する前に1つを選択するように求められます。
この機能はスペシャリストエージェントとして実装されているため、Coworker Customizations インターフェイスにリストされたスキルとして視覚的に表示されません。
スキルは、次のパイプラインと手順でエラーを調査します。
- フルスタックのデプロイメントとコード品質パイプラインのビルドとユニットテストの手順とコードスキャンの手順。
- Dispatcher設定の検証エラーなど、web階層設定パイプライン のビルドおよびコード品質エラー。
- 無効なCDN設定など、設定パイプライン のデプロイメントエラー。
フルスタックパイプラインのデプロイメントステップなど、その他のステップで失敗した場合、スキルは失敗したステップを診断せずに報告します。 その場合は、 ログへのアクセスとログのダウンロード で説明されているようにログを調べるか、Adobe サポートにお問い合わせください。
プロンプトを書かずにトラブルシューティングを開始することもできます。 Cloud Managerで失敗したパイプラインの実行、またはExperience Manager ホームページの失敗したパイプライン ウィジェットで「AIでトラブルシューティング」をクリックして、既に参照されている実行でCoworkerを開きます。 失敗したパイプラインのトラブルシューティング Cloud Managerおよび失敗したパイプラインのトラブルシューティング ウィジェット を参照してください。
AIは間違いを犯す可能性があるので、診断に反応する前に診断を確認してください。
「メインプログラムで失敗した最後のパイプラインのトラブルシューティングを支援」
「プログラム 12345ークフローでの開発パイプラインの実行1234567のトラブルシューティング」
「プログラム 12345で設定パイプラインのデプロイメントが失敗した理由を教えてください」
権限 pipeline-troubleshooting-permissions
AEM Cloud Manager パイプラインのトラブルシューティングスキルを使用するには、Cloud Managerで Developer または Program Manager の役割を持っている必要があります。 役割ベースの権限を参照してください。
Cloud Managerからの失敗したパイプラインのトラブルシューティング troubleshoot-from-cloud-manager
Coworkerは実行をコンテキストとして受け取り、プロンプトを記述する必要がないため、失敗したパイプライン実行から開始することがトラブルシューティングの最速の方法です。
-
Adobe Experience Cloudにログインし、Experience Managerを開きます。
note tip TIP Cloud Managerを開かずにトラブルシューティングを行うには、このページの「同僚に質問」ボックスに「失敗したパイプラインのトラブルシューティング」などのプロンプトを入力します。 -
左側のパネルで、Cloud Managerをクリックし、プログラムを選択します。
-
プログラムの概要 ページのパイプライン カードで、失敗したパイプラインをクリックします。
環境とパイプライン カードを表示する
-
パイプライン実行ページで、パイプライン名の横にある失敗 ステータスと、失敗したステップに注意してください。
失敗したアーティファクト準備ステップを示す、Cloud Managerの
-
「AIを使用したトラブルシューティング」をクリックします。 ボタンは、ページの右上隅付近および失敗したステップのステップエラー ボックスに表示されます。
ページの右側にあるパネルが開き、プロンプトで失敗した実行が参照されます。 Coworkerは、失敗したステップを特定し、根本原因を説明し、手動で適用できる修正を提案します。
失敗したパイプライン実行の横にある
-
診断の見直し。 フォローアップで質問したり、詳細をリクエストしたりするには、「同僚に質問」ボックスに入力します。
失敗したパイプラインウィジェットからのトラブルシューティング troubleshoot-from-experience-home-widget
Experience Manager ホームページには、失敗したパイプライン ウィジェットが含まれており、プログラム全体のパイプラインの失敗が一覧表示されるため、最初にCloud Managerを開かなくてもトラブルシューティングを開始できます。 各行には、パイプライン名、最後の実行の日時、期間、失敗したステップ、およびAIによるトラブルシューティング ボタンが表示されます。
-
Adobe Experience Cloudにログインし、Experience Managerを開き、失敗したパイプライン ウィジェットにスクロールします。
-
調査するパイプラインの行で、AIを使用したトラブルシューティングをクリックします。
Coworkerは失敗した実行を参照して開き、分析を開始し、根本原因を特定して修正を提案します。
-
診断の見直し。 フォローアップで質問したり、詳細をリクエストしたりするには、「同僚に質問」ボックスに入力します。
AEM Cloud Manager Environment Management aem-cloud-manager-environment-management
AEM Cloud Managerの環境管理スキルを使用すると、Cloud ManagerのUI画面を移動して適切なプログラム、環境、設定パネルを見つけることなく、Cloud Manager環境を自然言語で管理できます。 環境のリストを作成し、特定の環境の詳細を表示し、プロジェクトのニーズの変化に応じて環境を作成、複製、削除できます。
環境の管理、デバッグ用のログのダウンロード、クリーンスレートが必要な場合の迅速な開発環境（RDE）のリセット、リージョンのデプロイメントの設定など、日々の環境の維持についても説明します。これらはすべて、Cloud Managerを経由した複数回の旅行ではなく、1回の会話で行います。 何かをロールバックする必要がある場合、スキルはバックアップから環境を復元することもできます。
AIはミスを起こす可能性があるため、提案されたアクションを適用する前に、特に破壊的な運用に対して、そのアクションをレビューする必要があります。
「メインプログラムのすべての環境を表示」
「実稼動環境のステータスを教えてください」
「テスト用のステージ環境を設定する」
「プログラムの12345用にステージング環境を複製する」
“未使用のテスト環境を削除”
「ステージング環境でAPI_BASE_URL変数を設定する」
「自分のステージング環境のDispatcher ログをダウンロードする」
「プログラム 12345の迅速な開発環境をリセット」
「実稼動環境のリージョンのデプロイメントを表示」
「ステージング環境で利用可能なバックアップを表示」
AEM Cloud Manager Program Management aem-cloud-manager-program-management
AEM Cloud Manager プログラム管理スキルを使用すると、Cloud Managerのプログラムリストを移動して目的のプログラムを見つけるのではなく、自然言語を使用してCloud Manager プログラムを検索および管理できます。 アクセスできるすべてのプログラムを一覧表示し、特定のプログラムの詳細を表示し、不要になったプログラムを削除できます。
プログラムはパイプラインと環境が存在する傘なので、このスキルは関連リソースへのクイックエントリポイントとしても機能します。プログラム IDを自分で追跡することなく、特定のプログラムに関連付けられたパイプラインまたは環境を表示するように依頼できます。
AIはミスを起こす可能性があるため、提案されたアクションを適用する前に、特に破壊的な運用に対して、そのアクションをレビューする必要があります。
「どのプログラムにアクセスできますか？」
「メインプログラムに関する情報を表示」
“古いデモ プログラムを削除”
「メイン プログラムのパイプラインのリスト」
「メインプログラムにはどのような環境がありますか？」
AEM Cloud Manager リリース管理 aem-cloud-manager-release-management
AEM Cloud Manager リリース管理スキルを使用すると、Adobeで自動保守アップデートをプログラムに適用するタイミングを制御できます。Cloud Managerの設定を掘り下げて適切な画面を見つける必要はありません。 現在の更新スケジュールを確認し、Adobeが更新を一時停止する毎日繰り返し時間ウィンドウを設定し、環境に変更が加えられたくない場合は、製品の発表や休暇期間などのイベントに関する複数日の更新無料期間をスケジュールできます。
プランが変更された場合は、スケジュールと同じくらい簡単に更新不要の期間を削除できます。 また、このスキルでは、Adobe独自のグローバルなコード凍結期間（Windows Adobeでは計画的なメンテナンス除外が既にブロックされています）を表示できるので、自分でスケジュールを設定する前に、どの日付がすでに制限外になっているかを事前に把握できます。
また、このスキルはスケジュール設定のエラーを回避するのにも役立ちます。 リクエストを進める際に、フローティングの365日ウィンドウ内の最大3回の更新不要の期間、期間の間の必須1週間の間隔、Adobeの計画的なメンテナンス除外ウィンドウなど、適用される制限がフラグされます。 設定が失敗した後に制約を検出する代わりに、同じ会話で有効なスケジュールに到達します。 このアプローチにより、重要なビジネスウィンドウを自動メンテナンス更新から保護し、行き違いや設定ミスを減らすことができます。 休眠時間と無料期間の更新を参照してください。
AIは間違いを犯す可能性があるため、提案されたアクションを適用する前にレビューすることができます。これは、更新スケジュールの変更に特に当てはまります。誤ってスケジュールまたは削除された更新不要の期間では、保護する予定の期間に更新が実行される可能性があるからです。
「プログラムの更新スケジュールを表示12345る」
「サイレントアワーのウィンドウを更新して1時間早く開始する」
「3月3～10日のローンチ週にプログラム 12345ークフローの更新をブロック」
「来週にスケジュールしたブラックアウトウィンドウをキャンセルする」
「Adobeの計画保守除外期間を表示する」
AEM Workflow Inspection aem-workflow-inspection
AEM Workflow Inspection スキルを使用すると、平易な言葉でワークフローアクティビティを確認できます。 ワークフローのユーザーインターフェイスを開かずに、実行しているワークフロー、受信トレイで待機しているワークフロー、ワークフローが失敗した理由を同僚に尋ねます。
特定のワークフローを検索し、利用可能なワークフローモデルを閲覧して、トラブルシューティングを行いながらフォローアップの質問をすることができます。 このスキルは読み取り専用です。何が起こっているのかを確認し、理解するのに役立ちますが、ワークフローの開始、変更、停止はありません。
AIはミスを犯す可能性があるため、対応前に調査結果を確認する必要があります。
「ワークフローは中断されていますか？」
「ステータス別のワークフローの簡単な分類を教えてください」
「検査したワークフローで見つかったエラーを要約してください」
「そのリストの2番目のワークフローのエラーを説明してください」
「前回のチェック以降、ステータスまたは現在の手順が変更されますか？」
「誰が開始したか、いつ、どの作業項目の情報を利用できますか？」
「タスクではなく、ワークフローの手順のみを表示する」
「エディトリアルレビューという名前のモデルは使用可能ですか？」
AEM Dispatcherのインサイト aem-dispatcher-insights
AEM Dispatcher インサイト スキルは、DispatcherとApacheのweb層がAEM as a Cloud Serviceでのリクエストをどのように処理するかを理解するのに役立ちます。 共同作業者に、ログファイルを手動で検索せずに、キャッシュのパフォーマンスを分析し、トラフィックと配信の問題を調査し、セキュリティ設定を確認するように依頼します。 利用可能なデータでサポートされている場合、Coworkerは調査結果をチャートやリクエストタイミングのビジュアライゼーションとして表示できます。
環境固有の分析の場合は、調査する環境と期間（7日間のログウィンドウ内）を特定します。 現在、スキルはソースリポジトリにアクセスしないため、設定とコードのレビューのために、関連するファイルを貼り付けたりアップロードしたりできます。 チームメンバーは、到達可能なURLを検証して、応答のステータス、ヘッダー、リダイレクトを確認することもできます。
これらのトピック全体で、変更を提案し、その潜在的な影響を説明し、検証とロールバックのガイダンスを提供するように同僚に依頼できます。 変更を適用してデプロイしたら、Coworkerに対して、使用可能なログまたはライブ URLの動作を再評価するように依頼します。
現在、スキルはリポジトリの変更、変更のデプロイ、コンテンツの公開または非公開、キャッシュのクリアを行いません。 CDN キャッシュのパージ、エッジトラフィックフィルターのルールのオーサリング、Adobeで管理されるインフラストラクチャ設定の変更は、その範囲外です。
AIはミスを犯す可能性があるため、分析結果や提案された変更を事前に確認してから、対応します。
キャッシュとパフォーマンス dispatcher-caching-performance
キャッシュの効果を把握し、応答の速度が遅い、または古い場合を調査し、公開するリクエストを減らす機会を特定します。
「最新のデプロイメント後にキャッシュのパフォーマンスが低下しました。 ログのエビデンスを、最近のデプロイメントと、共有した設定の違いと比較します。」
「これらのGraphQL永続クエリ応答がキャッシュされない理由を確認してください。」
“検索やページ分割を解除せずに安全に無視できるパラメーターはどれですか？”
「私が共有した設定を使用して、バージョン管理されたクライアントライブラリとDAM アセットのキャッシュポリシーを推奨します。」
“statfileslevelまたはgracePeriodの変更は無効化にどのように影響しますか。ページのキャッシュを更新するタイミングは？”
「代表的なページリクエストの場合は、観察されたDispatcherとパブリッシュの処理ステージと、どこに時間が費やされているかを表示します。」
「このページがサイトマップに含まれているかどうかを確認し、サイトマップのカバレッジがウォームアップにどのように影響するかを説明します。」
トラフィックとリクエストの処理 dispatcher-traffic-request-handling
Dispatcherに到達するトラフィックを把握し、リクエストがどのようにフィルタリング、ルーティング、配信されるかを調査します。
「自動トラフィックはキャッシュに吸収されますか、公開リクエストが増加しますか？」
「今日の403と404の応答を考慮するパスと、それらを説明するのに役立つ証拠は何ですか？」
「ルールの順序付けがGraphQL エンドポイントへのリクエストにどのような影響を与えるかを説明します。」
「新しいドメインへのリクエストは、間違ったサイトにサービスを提供しています。 共有したホストエイリアスとファームマッピングを確認します。」
「このバニティ URLはパブリッシュで動作しますが、Dispatcherを通じて404を返します。 何を調べればいいですか？」
「clientheaders.anyに属するヘッダーと、vhostまたはキャッシュ設定で処理されるヘッダーを説明します。」
「実稼動ログを変更せずに、Dispatcherを有効にしたり、ステージでデバッグログを書き換えたりするにはどうすればよいですか？」
セキュリティ dispatcher-security
Coworkerに全体的なセキュリティレビューを依頼するか、お客様が管理するDispatcher設定と関連するAEM コードの特定の懸念事項に焦点を当てます。
「このエンドポイントの許可ルールは、必要なリクエストを保持しながら絞り込むことができますか？」
「お勧めのコンテンツ セキュリティ ポリシー変更によるセキュリティ上のメリットとアプリケーションへの潜在的な影響について説明してください。」
「認証済みコンテンツをキャッシュする際に、不正アクセスを防ぐにはどうすればよいですか？」
「これらのOSGi CSRFおよびCORS設定を、私が共有したDispatcher ルールと一緒に確認してください。」
「重大度ごとに調査結果を優先し、AEM as a Cloud Serviceの制御における改善点を推奨します。」