developing-agentforce

Agent Script スキル

このスキルの用途

このスキルは、主に AI エージェント向けの Salesforce のスクリプト言語である Agent Script を使用して、Agentforce エージェントを開発するためのものです。

⚠️重大： Agent Script は AppleScript、JavaScript、Python、その他の言語ではありません。Agent Script の構文や意味を、学習した他の言語と混同しないでください。

Agent Script エージェントは、.agent ファイル（エージェントの動作）と bundle-meta.xml（バンドルのメタデータ）で構成される AiAuthoringBundle メタデータによって定義されます。アクションは、invocable Apex、autolaunched Flow、Prompt Template、その他のサポートされているタイプを使用して実装できます。

このスキルでは、エージェントの設計、Agent Script コードの記述、検証とデバッグ、デプロイと公開、テストまで、Agent Script のライフサイクル全体を扱います。

このスキルの使い方

このファイルでは、ユーザーの意図をタスク領域と references/ 内の関連するリファレンスファイルに対応付けます。このファイルを、エージェント開発を最初から最後まで実行するためのルーターとして扱い、詳細についてはリファレンスを参照してください。

タスクの説明からユーザーの意図を特定します。作業を開始する前に、必ず指定されたリファレンスファイルを読んでください。

常に適用されるルール

1. 必ず --json を指定してください。 すべての sf CLI コマンドに、必ず --json を指定してください。CLI の出力を jq や 2>/dev/null にパイプしないでください。JSON レスポンス全体をそのまま読み取ってください。LLM は JSON をネイティブに解析できます。

2. 対象の組織を確認してください。 組織とやり取りする前に、sf config get target-org --json を実行し、対象の組織が設定されていることを確認してください。設定されていない場合は、sf config set target-org <alias> で設定するようユーザーに依頼してください。

3. 修正する前に原因を診断してください。 エージェントの動作を検証またはデバッグする際は、 作成用バンドルをプレビューするため、必ず --use-live-actions を指定してください。発話を送信し、 その後、セッションのトレースを読み取ってエージェントの動作を把握してください。 トレースファイルには、サブエージェントの選択、アクションの入出力、LLM の推論が記録されています。 こうした根拠を得る前に、.agent ファイルやアクションの実装を変更してはいけません。 トレースファイルの場所と診断パターンについては、検証とデバッグを参照してください。

4. 仕様の承認は必須のゲートです。 ユーザーの明示的な承認を得ずに、エージェント仕様の作成後の工程へ進んではいけません。

5. 作業を停滞させないでください。 あるステップが正常に完了したら、次のステップを伝えて開始してください。ユーザーが「次は何ですか」や「続けて」と言うのを待たないでください。明示的なユーザー承認が必要なチェックポイントは次のものだけです。（a）エージェント仕様の承認、（b）公開前の CHECKPOINT、（c）スキルが明示的に提示する A/B 分岐（例：ADL のセットアップ時に Data Cloud がプロビジョニングされていない場合）。ADL のインデックス作成など、時間のかかる非同期処理はバックグラウンドで実行し、その結果に依存しない作業をスキルで続行してください。

6. まず下書きを作成するライフサイクルです。 通常の作成作業では、下書きの反復作業を続けてください。必要に応じて .agent とアクションの実装を編集し、検証、デプロイ、プレビューを繰り返してください。デフォルトでは公開または有効化してはいけません。公開と有効化は明示的なリリース操作であり、現在の下書きをメタデータに確定し、エンドユーザーに公開する準備ができていることを、ユーザーに確認する必要があります。

7. デフォルトはエージェント主体とし、理由がある場合に制約を加えてください。 各サブエージェントの要件を満たす範囲で、最もエージェント主体の姿勢を採用し、規制や信頼性に関するゲート、または実際に観測された失敗に対してのみ、決定論的な制御を追加してください。詳細な姿勢のルールについては、姿勢と決定論を参照してください。

8. ネストした if や else if は使用しないでください。 Agent Script がサポートするのは、フラットな if／else ブロックのみです。else if、else 内の if、if 内の if は使用できません。複数分岐のロジックには、連続する if 文または複合条件（if A and B:）を使用してください。ネスト構造は、エラーが表示されないままコンパイルに失敗する原因になります。

9. アクションの実装方法はユーザーが決めます。 計画や仕様の作成時には、新しいアクションをデフォルトで NEEDS STUB のプレースホルダーにしてください。既存の実装を組織やプロジェクトから検索するか、Apex／Flow／Prompt の新しい実装を生成するかについて、どちらの方法を取る前にも必ずユーザーに確認してください。

タスク領域

以下の各タスク領域には、必須のステップがあります。記載どおりの順序で実行してください。デフォルトの手順は、設計 -> 下書きの実装サイクル -> 検証／プレビューのサイクル -> ユーザーが明示的に承認したリリースです。

エージェントを作成する

ユーザーがエージェントをゼロから作成したい場合は、必ず Agent Script を使用してください。Salesforce 固有の用語を使わず、平易な言葉で、エージェントの目的、サブエージェント、アクションをユーザーと一緒に明確にしてください。

必須のステップ

正確なコマンド構文については、エージェント向け CLIを参照してください。

1. 設計 — 設計とエージェント仕様を読み、エージェント仕様の草案を作成します。計画中は、新しいアクションをすべてデフォルトで NEEDS STUB プレースホルダーにします。実装作業の前に、どの実装パスを希望するかユーザーに尋ねます。
   • パス A：プレースホルダーのみを維持する（現時点では実装しない）
   • パス B：再利用できる既存のアクションを検索する
   • パス C：新しいアクションを生成する ユーザーがパス B または C を明示的に選択した場合に限り、スキャン（sfdx-project.json の読み込み、@InvocableMethod、AutoLaunchedFlow、プロンプトテンプレート、外部サービス登録、標準の呼び出し可能なアクション、カスタムオブジェクトの検索）を実行します。 エージェントの目的にドキュメントに基づく回答が含まれる場合（例：「製品マニュアルに基づいて顧客の質問に回答する」、「ポリシーガイドに基づいて応答する」、「PDFからFAQを作成する」）、ユーザーに次のように尋ねます。「このエージェントはドキュメントコーパス（PDF/DOCX/TXT）から質問に回答しますか？該当する場合、ファイルパスは何ですか？」 パスを仕様の 「ナレッジグラウンディング」 セクションに記録します。要件の確認時に尋ねることが重要です。ADL のインデックス作成には数分かかるため、仕様の承認前にファイルパスを記録し、できるだけ早くプロビジョニングを開始する必要があります。 エージェント仕様は必ずファイルとして保存します。
2. エージェント仕様のユーザー承認を得るために停止します。 ナレッジグラウンディングのセクションがある場合はそれも含めて、ユーザーに提示します。承認またはフィードバックを求めます。承認を得るまで先に進まないでください。 承認後は、手順が失敗しない限り停止せずに進めます。
3. 環境の前提条件を検証する — 設計とエージェント仕様のセクション 3「環境の前提条件」を読みます。設計に基づいてエージェントの種類を判断し、組織環境を検証します。
   • 従業員エージェント：設定ブロックに connection messaging: または MessagingSession にリンクされた変数が含まれていないことを確認します。含まれている場合は削除します。例外： エージェントに knowledge: ブロック（AnswerQuestionsWithKnowledge を使用する）がある場合、従業員エージェントであっても default_agent_user が必要です。プラットフォームは、ナレッジに基づくエージェントには実行時に Einstein Agent User コンテキストが必要であるとして扱います。エージェントユーザーを照会して設定に含めます。従業員エージェントの完全な例については、例を参照してください。
   • サービスエージェント：組織で Einstein Agent User を照会します。存在する場合は、ユーザーにユーザー名を確認します。存在しない場合は、作成方法を案内します。作成手順はエージェント向け CLIのセクション 12、必要な権限はエージェントユーザーの設定を参照してください。 3b. ADL のプロビジョニングを開始します（仕様にナレッジグラウンディングのセクションがある場合のみ）。 データライブラリリファレンスを読みます。手順 0 の事前確認を実行します。まず SELECT COUNT() FROM DataKnowledgeSpace を実行して DC がプロビジョニング済みか確認し、次に sf agent adl list を実行して ADL サービスの状態を確認します。DC がプロビジョニングされていない場合は、そのリファレンスに記載された A/B の選択肢を提示します。DC はプロビジョニング済みでも ADL サービスが 400 INTERNAL_ERROR を返す場合は、「DC は稼働中、ADL は故障」の手順を示し、この実行ではグラウンディングをスキップします。両方の確認に合格した場合は、sf agent adl create（リファレンスの手順 1）を実行して libraryId を取得します。libraryId のみから rag_feature_config_id = "ARFPC_<libraryId>" を算出します。バンドルの作成に必要なのはこれだけです。その後、作成作業を続けながら、アップロードとインデックス作成のフロー（リファレンスの手順 2～6）をバックグラウンドで開始します。ルール 5 に従い、非同期のインデックス作成の完了を待って作業を止めないでください。retrieverId が必要になるのは実行時のクエリ（手順 8 で確認）だけです。また、エージェントユーザーへの Data Cloud 権限セットの割り当ても開始します。検出してから割り当てる手順については、エージェントユーザーの設定の手順 3b を参照してください。 環境の検証が完了するまで、コード生成に進まないでください（ADL のプロビジョニングはバックグラウンドで続行して構いません）。
4. 作成バンドルを生成する — sf agent generate authoring-bundle --json --no-spec --name "<Label>" --api-name <Developer_Name>
5. コードを記述する — 構文、ブロック構造、アンチパターンについて、コア言語を読みます。リファレンスファイルとテンプレートを使用して、生成された .agent ファイルを編集します。.agent ファイルや bundle-meta.xml ファイルを手動で作成しないでください。手順 3b で libraryId を取得した場合は、データライブラリリファレンスの「ADL を Agent Script に接続する」に従い、最上位の knowledge: ブロックと AnswerQuestionsWithKnowledge アクションの配線を含めます。テンプレート assets/agents/knowledge-grounded.agent は、コピーして変更するための出発点です。
6. コンパイルを検証する — sf agent validate authoring-bundle --json --api-name <Developer_Name> 検証に失敗した場合は、検証とデバッグを読み、原因を特定して修正した後、再検証します。アクション実装を生成する前に、構文エラーと構造エラーを必ず修正してください。
7. アクション実装を生成する（ユーザーが明示的に選択した場合のみ） — ユーザーが新しい実装の生成を明示的に依頼した場合（手順 1 のパス C）のみ、この手順を実行します。NEEDS STUB とマークされた各アクションについて、次を実行します。 sf template generate apex class --name <ClassName> --output-dir <PACKAGE_DIR>/main/default/classes クラス本体を設計とエージェント仕様の呼び出し可能なパターンに置き換えます。必ず次をデプロイします。 sf project deploy start --json --metadata ApexClass:<ClassName> 次のスタブを生成してデプロイする前に、デプロイエラーを必ず修正してください。
8. 動作を検証する — プレビューのワークフローとセッショントレースの分析について、検証とデバッグを読みます。 手順 3b で ADL をプロビジョニングした場合、グラウンディングされたテスト発話を送信する前に、ライブラリにクエリできることを確認します。sf agent adl get -i $LIBRARY_ID を実行し、retrieverId が存在することを確認します（データライブラリリファレンスの手順 6）。まだ null の場合は、待ってから再度確認します。まだプレビューを行わないでください。エージェントは空の knowledgeSummary を返し、幻覚防止ガードがすべての発話に対して拒否することになります。 sf agent preview start --json --use-live-actions --authoring-bundle <Developer_Name> アクションがデータを照会する場合は、次を使ってテスト発話の根拠となるデータを取得します。 sf data query --json -q "SELECT <Relevant_Fields> FROM <SObject> LIMIT 100" 次を使ってテスト発話を送信します。 sf agent preview send --json --authoring-bundle <Developer_Name> --session-id <ID> -u "<message>" スモークテストの要件（検証とデバッグの「発話の導出」を参照）：
   • 想定どおりの経路だけでなく、すべてのルーティング分岐をテストします。各分岐について、複数の言い回しを試します。
   • 現実的な発話を使用します。キーワードではなく、人が実際に入力するような文章を作成します。
   • 発話を送信するたびに、トレースを読み、アクションが実際に実行されたこと（FunctionStep）を確認します。エージェントのテキスト応答だけを信頼しないでください。アクションを呼び出していないのに、実行したと主張するエージェントもあります。
   • 人間のテスターのように、エージェント仕様に照らして評価します。会話の流れ、指示の順守、不要な繰り返し、応答の質を確認します。仕様に「一度だけ確認する」とあるのにエージェントが二度確認した場合、それは不具合です。修正してください。 動作がエージェント仕様と異なる場合は、.agent ファイルを修正して再度プレビューします。複雑な問題の場合は、動作上の問題を診断するワークフローに切り替えます。問題を修正してから戻ります。 チェックポイント — ユーザーがリリースを明示的に依頼するまでは、ドラフトの反復作業を続けてください。 ユーザーがリリースを依頼した場合でも、以下の条件をすべて満たすまでは公開に進まないでください。
   • validate authoring-bundle がエラー 0 件で成功している
   • 現実的な発話を使い、すべてのルーティング分岐を対象に、ライブプレビュー（--use-live-actions）でテスト済みである
   • トレースによって、正しいサブエージェントへのルーティング、アクションの呼び出し（FunctionStep が存在すること）、仕様に準拠した動作が確認できる
   • ユーザーがデプロイを明示的に承認している
   • エージェントに knowledge: ブロックがある場合：Einstein Agent User に Data Cloud の権限セットまたは PSL が割り当てられていることを確認します。以下の両方を検証します。

     sf data query --json -q "SELECT PermissionSet.Name FROM PermissionSetAssignment WHERE Assignee.Username='<agent_user>'"
     sf data query --json -q "SELECT PermissionSetLicense.DeveloperName FROM PermissionSetLicenseAssign WHERE Assignee.Username='<agent_user>'"
     

     いずれかの結果に GenieDataPlatformStarterPsl、GenieUserEnhancedSecurity、DataCloudUser、DataCloudArchitect のいずれかが含まれている必要があります。いずれも含まれていない場合は、エージェントユーザーの設定、手順 3bの検出してから割り当てる手順を実行し、続行する前に再確認します。Data Cloud 権限セットが割り当てられているにもかかわらず、スモークテストのグラウンディングクエリで空の knowledgeSummary が返される場合は、その権限セットにデータスペースのスコープも付与する必要があります。これは UI でのみ設定できます。エージェントユーザーの設定、手順 3b.4を参照してください。
9. 公開する（明示的なリリース手順） — ユーザーがこのドラフトをメタデータに反映する準備ができたと確認した後に限り、実行します。公開ではメタデータの構造が検証されますが、エージェントの動作は検証されません。公開するたびに、恒久的なバージョン番号が作成されます。 sf agent publish authoring-bundle --json --api-name <Developer_Name> 公開に失敗した場合は、再試行する前にメタデータとライフサイクルのセクション 5 にあるトラブルシューティングチェックリストに従います。
10. 有効化する（明示的なリリース手順） — 公開後、新しいバージョンをユーザーが利用できるようにします。 sf agent activate --json --api-name <Developer_Name>
11. 公開したエージェントを検証する — 有効化後、次を使ってユーザー向けの動作をプレビューします。 sf agent preview start --json --api-name <Developer_Name> --authoring-bundle ではなく、--api-name を使用します。
12. エンドユーザーのアクセスを設定する — 従業員エージェントに限り実行します。権限の設定とアクセス権の割り当てについては、エージェントアクセスガイドを読みます。

参照ファイル

1. エージェント向け CLI — generate、validate、deploy、publish、activate の正確なコマンド構文； Einstein Agent User の作成についてはセクション 12
2. コア言語 — 実行モデル、 構文、ブロック構造、アンチパターン
3. 設計と Agent Spec — サブエージェントグラフの設計、フロー制御パターン、Agent Spec の作成、 アクション実装の分析；環境の前提条件についてはセクション 3
4. サブエージェントマップ図 — エージェントのサブエージェントグラフを視覚化するための Mermaid 図の規約
5. エージェントの姿勢と決定性 — エージェントのデフォルトのエージェント的な姿勢、原因を伴う決定性制御
6. エージェントユーザーの設定と権限 — 権限セットの割り当て、オブジェクト権限、サブエージェント間の検証
7. メタデータとライフサイクル — ディレクトリ構造、バンドルメタデータ；publish のトラブルシューティング
8. 検証とデバッグ — エージェントがコンパイルできることを検証し、プレビューで動作を確認
9. エージェントアクセスガイド — エンドユーザーの アクセス権限、表示に関するトラブルシューティング
10. 既知の問題 — コード修正後もエラーが 解消しない場合にのみ読み込む
11. 要件別パターン — アーキテクチャとフローの選択に関するシナリオとパターンの対応付け
12. アーキテクチャパターン — ルーター優先の仕組み、検証ゲート、ワークフロー内の線形パターン
13. 複合データ型 — 型マッピングの判断ツリー
14. 安全性レビュー — 7 カテゴリーの安全性レビュー
15. Discover リファレンス — ターゲット検出 CLI
16. Scaffold リファレンス — スタブ生成 CLI
17. Deploy リファレンス — デプロイのライフサイクル、エラーからの復旧
18. Data Library リファレンス — SFDRIVE Agentforce Data Library をプロビジョニングし、knowledge: ブロックと AnswerQuestionsWithKnowledge アクションを使って .agent に接続する

既存のエージェントを理解する

ユーザーが、自分で作成していない、または動作を再確認する必要がある Agent Script エージェントについて理解しようとしています。AiAuthoringBundle ディレクトリを指定する場合や、「このエージェントは何をしますか？」または「このエージェントを修正したいのですが、仕組みがわかりません」と尋ねる場合があります。

必須の手順

1. エージェントを特定する — sfdx-project.json を読み、パッケージディレクトリを特定します。その中から AiAuthoringBundle ディレクトリを見つけます。.agent ファイルと bundle-meta.xml を読みます。
2. コードを読む — .agent ファイルを解析する前に、構文と実行モデルについて コア言語 を読みます。
3. アクションの実装をマッピングする — target を持つ各アクションについて、プロジェクト内で実装（Apex クラス、Flow、Prompt Template）を特定します。入出力の契約を記録します。
4. Agent Spec をリバースエンジニアリングする — Agent Spec の構造について 設計と Agent Spec を読みます。コードから Agent Spec を作成し、ファイルとして保存します。
5. サブエージェントマップ図を作成する — Mermaid の規約について サブエージェントマップ図 を読みます。遷移、ゲート、アクションとの関連を示すサブエージェントグラフのフローチャートを生成します。
6. ソースに注釈を付ける — Agent Script のソースに説明を付けるかどうかをユーザーに尋ねます。依頼された場合は、フロー制御の判断、ゲート設定の根拠、サブエージェント間の関係を説明するインラインコメントを .agent ファイルに追加します。
7. ユーザーに提示する — Agent Spec、サブエージェントマップ、作成した場合は注釈付きソースを共有します。コア言語のリファレンスにあるアンチパターンのセクションを確認し、コード内で見つかった該当箇所を指摘します。

参照ファイル

1. コア言語 — 構文、 実行モデル、アンチパターン
2. 設計とエージェント仕様 — エージェント仕様の構造、フロー制御パターンの認識
3. サブエージェントマップ図 — サブエージェントグラフの可視化に関する Mermaid の規約
4. メタデータとライフサイクル — ディレクトリの規約、バンドルメタデータ
5. 既知の問題 — コードに説明のない回避策のパターンが含まれる場合のみ読み込みます

既存のエージェントを変更する

既存のエージェントのサブエージェント、アクション、指示、またはフロー制御を追加、削除、変更することをユーザーが希望しています。「請求処理のサブエージェントを追加して」のような平易な言葉で変更を説明する場合も、特定の Agent Script の構成要素を指定する場合もあります。

必須の手順

正確なコマンド構文については、エージェント向け CLI を読んでください。

1. 内容を把握する — Agent Spec が存在しない場合は、まず上記の「既存エージェントの把握」ワークフローに従ってリバースエンジニアリングを行います。
2. Agent Spec を更新する — フロー制御パターンと既存アクションの分析については、設計と Agent Spec を読みます。意図する変更が反映されるよう Agent Spec を変更します。新しいアクションは、デフォルトで NEEDS STUB プレースホルダーにします。どの方法を選ぶかユーザーに確認します。
   • 方法 A：プレースホルダーのみを維持する
   • 方法 B：再利用可能な既存アクションをスキャンする
   • 方法 C：新しいアクションを生成する ユーザーが方法 B または C を明示的に選んだ場合にのみ、スキャンを実行します。 変更にナレッジグラウンディングの追加、置き換え、または削除が含まれる場合は、次のように質問します。 「このエージェントはドキュメントコーパス（PDF/DOCX/TXT）に基づいて質問に回答しますか？ その場合、ファイルパスを教えてください。」 更新した Spec の 「Knowledge Grounding」 セクションにパスを記録します。今、つまり Spec の更新中に質問することで、ADL の変更内容をユーザーの承認に提示でき、直後にプロビジョニングを開始できます。 更新した Agent Spec は必ずファイルとして保存します。
3. 更新した Agent Spec に対するユーザーの承認を待ちます。 Knowledge Grounding セクションがある場合はそれも含めて、ユーザーに提示します。承認またはフィードバックを求めます。承認なしに先へ進んではいけません。 承認された後は、手順が失敗しない限り、停止せずに進めます。
4. ADL のプロビジョニングを開始します（Spec に Knowledge Grounding セクションがある場合のみ）。
   • .agent に knowledge: ブロックがすでにあり、rag_feature_config_id が設定済みで、ユーザーが同じライブラリを使用する場合は、それを再利用します。プロビジョニングはスキップします。（ここでは retrieverId を確認する必要はありません。その確認は手順 8 に移ります。）
   • 新しい ADL が必要な場合は、作成ワークフローと同じ流れに従います。データライブラリのリファレンス を読み、手順 0 の事前確認（sf agent adl list）を実行し、（DC の準備ができていれば）sf agent adl create（手順 1）を実行して libraryId を取得します。libraryId だけから rag_feature_config_id = "ARFPC_<libraryId>" を計算します。これはバンドルの作成に十分です。手順 5（コードの編集）に進む間、アップロードとインデックス作成のフロー（手順 2～6 を参照）をバックグラウンドで開始します。ルール 5 に従い、非同期のインデックス作成を待って処理を止めないでください。また、エージェントユーザーのセットアップの手順 3b を参照し、エージェントユーザーへの Data Cloud 権限セットの割り当ても開始します。
   • 変更にグラウンディングが含まれない場合は、この手順をスキップします。
5. コードを編集する — 構文とアンチパターンについては、コア言語を読みます。承認された変更を実装するために .agent ファイルを編集します。手順 4 で libraryId が生成された場合は、データライブラリのリファレンスに従って knowledge: ブロックと AnswerQuestionsWithKnowledge アクションを追加または更新します。
6. コンパイルを検証する — sf agent validate authoring-bundle --json --api-name <Developer_Name> 検証に失敗した場合は、検証とデバッグを読んで原因を特定・修正し、再検証します。
7. 新しいアクションの実装を生成する（ユーザーが明示的に依頼した方法のみ） — ユーザーが新しい実装の生成を明示的に依頼した場合（手順 2 の方法 C）のみ、この手順を実行します。NEEDS STUB とマークされた新しいアクションごとに、次を実行します。 sf template generate apex class --name <ClassName> --output-dir <PACKAGE_DIR>/main/default/classes クラス本体を設計と Agent Specの呼び出し可能パターンに置き換えます。必ずデプロイします。 sf project deploy start --json --metadata ApexClass:<ClassName> 次のスタブの生成とデプロイに進む前に、デプロイエラーを必ず修正します。新しいアクションが追加されていない場合はスキップします。
8. 動作を検証する — プレビューのワークフローとセッショントレースの分析については、検証とデバッグを読みます。 手順 4 で新しい ADL をプロビジョニングした場合は、グラウンディングされたテスト発話を送る前に、ライブラリをクエリできることを確認します。 sf agent adl get -i $LIBRARY_ID を実行し、retrieverId が設定されていることを確認します（データライブラリのリファレンス、手順 6）。まだ null の場合は、待ってから再確認します。まだプレビューを実行してはいけません。エージェントは空の knowledgeSummary を返し、ハルシネーション防止ガードがすべての発話を拒否することになります。 sf agent preview start --json --use-live-actions --authoring-bundle <Developer_Name> アクションがデータをクエリする場合は、次のコマンドでテスト発話の根拠となるデータを取得します。 sf data query --json -q "SELECT <Relevant_Fields> FROM <SObject> LIMIT 100" 次のコマンドでテスト発話を送信します。 sf agent preview send --json --authoring-bundle <Developer_Name> --session-id <ID> -u "<message>" スモークテストの要件（検証とデバッグの「発話の導出」を参照）：
   • まず変更したパスをテストし、次に隣接するパスをテストしてリグレッションを検出します。
   • 変更の影響を受けるルーティング分岐をすべてテストします。各分岐について、複数の言い回しを試します。
   • 現実的な発話を使います。キーワードではなく、人が実際に入力するような内容にします。
   • 発話を送信するたびに、トレースを確認してアクションが実際に実行されたことを確認します（FunctionStep）。エージェントのテキスト応答だけを信頼してはいけません。
   • Agent Spec に照らして、会話フロー、指示への準拠、不必要な繰り返し、応答の品質を評価します。 動作が Agent Spec と異なる場合は、.agent ファイルを修正してプレビューを再実行します。複雑な問題については、動作上の問題の診断ワークフローに切り替えます。 チェックポイント — ユーザーがリリースを明示的に依頼しない限り、ドラフトの反復作業を続けます。 ユーザーがリリースを依頼した場合、次の条件がすべて満たされるまで Publish に進んではいけません。
   • validate authoring-bundle がエラー 0 件で成功する
   • 現実的な発話を使ったライブプレビュー（--use-live-actions）で、すべてのルーティング分岐をテスト済みである
   • トレースで、サブエージェントへのルーティング、アクションの呼び出し（FunctionStep が存在すること）、および Spec に準拠した動作が確認されている
   • ユーザーがデプロイを明示的に承認している
   • エージェントに knowledge: ブロックがある場合：Einstein Agent User に Data Cloud 権限セットまたは PSL が割り当てられていること。次の両方を確認します。

     sf data query --json -q "SELECT PermissionSet.Name FROM PermissionSetAssignment WHERE Assignee.Username='<agent_user>'"
     sf data query --json -q "SELECT PermissionSetLicense.DeveloperName FROM PermissionSetLicenseAssign WHERE Assignee.Username='<agent_user>'"
     

     GenieDataPlatformStarterPsl、GenieUserEnhancedSecurity、DataCloudUser、または DataCloudArchitect のいずれかが、両方の結果に含まれている必要があります。いずれも含まれていない場合は、エージェントユーザーのセットアップ、手順 3b に従って、検出してから割り当て、再確認します。Data Cloud 権限セットが割り当て済みなのに、スモークテストのグラウンディング済みクエリで空の knowledgeSummary が返される場合は、その権限セットに Data Space スコープも付与する必要があります。これは UI でのみ設定できます。エージェントユーザーのセットアップ、手順 3b.4を参照してください。
9. Publish する（明示的なリリース手順） — ユーザーがこのドラフトをメタデータに確定する準備ができたと確認した後にのみ実行します。Publish はメタデータ構造を検証するものであり、エージェントの動作は検証しません。Publish のたびに、恒久的なバージョン番号が作成されます。 sf agent publish authoring-bundle --json --api-name <Developer_Name> Publish に失敗した場合は、再試行する前にメタデータとライフサイクルのセクション 5 にあるトラブルシューティングチェックリストに従います。
10. Activate する（明示的なリリース手順） — Publish の後、新しいバージョンをユーザーが利用できるようにします。 sf agent activate --json --api-name <Developer_Name>
11. Publish 済みのエージェントを検証する — Activate の後、次のコマンドでユーザー向けの動作をプレビューします。 sf agent preview start --json --api-name <Developer_Name> --authoring-bundle ではなく、--api-name を使用します。

リファレンスファイル

1. エージェント向け CLI — validate、deploy、preview、publish、activate の正確なコマンド構文
2. コア言語 — 構文、アンチパターン
3. 設計とエージェント仕様 — Agent Spec の更新、アクション実装の分析
4. 検証とデバッグ — コンパイル診断、プレビューワークフロー、セッショントレース分析
5. データライブラリリファレンス — ADL グラウンディング向けのプロビジョニングと Agent Script の接続
6. 既知の問題 — コード修正後もエラーが解消しない場合にのみ読み込みます

コンパイルエラーの診断

ユーザーの Agent Script がコンパイルできません。エラーは sf agent validate または sf agent preview start から出力されるか、ユーザーが「検証エラーが出ます」のような症状を説明します。

必須の手順

正確なコマンド構文については、エージェント向け CLI を読んでください。

1. まず具体的なエラーを取得してから再現する — ユーザーがすでにエラー出力を共有している場合は、まずエラーメッセージを正確に抽出して列挙します。次に、 sf agent validate authoring-bundle --json --api-name <Developer_Name> を実行して、基本的なコンパイルエラーを取得します。エラーがない場合は、 sf agent preview start --json --use-live-actions --authoring-bundle <Developer_Name> を実行して、複雑なコンパイルエラーを取得します。再現したエラーがユーザー提供のエラーと異なる場合は、両方を明示し、現在再現できているエラーを引き続き調査します。
2. エラーを分類する — エラーの分類については、検証とデバッグ を読んでください。正確なエラーメッセージごとに、根本原因のカテゴリを特定します。
3. 問題箇所を特定する — 正しい構文を理解するために、コア言語 を読んでください。各エラーの原因となっている .agent ファイル内の具体的な行を見つけます。
4. コードを修正する — 対象を絞って修正します。既知の不適切なパターンを新たに持ち込まないよう、コア言語リファレンスの「アンチパターン」セクションを確認します。
5. 再検証する — 次を実行します。 sf agent validate authoring-bundle --json --api-name <Developer_Name> 続いて、次を実行します。 sf agent preview start --json --use-live-actions --authoring-bundle <Developer_Name> エラーが続く場合は、手順 2～5 を繰り返します。
6. 修正内容を説明する — 何が問題で、何を変更したかをユーザーに伝えます。コア言語 のエージェント実行モデルに沿って、根本原因を説明します。

リファレンスファイル

1. コア言語 — 構文、ブロック構造、アンチパターン
2. 検証とデバッグ — エラーの分類、エラーと根本原因の対応付け
3. 既知の問題 — エラーがユーザーのコードに当てはまらない場合にのみ読み込みます。プラットフォームのバグの可能性があります
4. 本番環境での注意点 — エラーが予約語またはライフサイクルフックの構文に関係する場合にのみ読み込みます

動作上の問題の診断

エージェントはコンパイルでき、プレビューを --use-live-actions で開始できますが、期待どおりに動作しません。ユーザーが「エージェントが間違ったサブエージェントに進み続ける」や「アクションが呼び出されない」といった症状を説明します。これは validate または preview start のエラーとは根本的に異なります。コードは有効ですが、動作に問題があります。

必須の手順

正確なコマンド構文については、CLI for Agents をお読みください。

1. ベースラインを確立する — Agent Spec を読みます。Agent Spec が存在しない場合は、既存のエージェントを把握するワークフローに従ってリバースエンジニアリングし、Agent Spec を作成してから続行します。
2. 仮説を立てる — 実行モデルについては、Core Language をお読みください。ユーザーの説明に基づいて、考えられる根本原因を列挙します。サブエージェントへのルーティング、ゲーティング条件、アクションの利用可否、指示の明確さ、変数の状態、遷移のタイミングについて検討します。
3. プレビューで再現する — プレビューのワークフローとセッショントレースの分析については、Validation & Debugging をお読みください。次のコマンドでプレビューセッションを開始します。 sf agent preview start --json --use-live-actions --authoring-bundle <Developer_Name> 続いて、sf agent preview send を使って、各サブエージェントを網羅するテストメッセージを送信します。メッセージは1つでは不十分です。先に進む前に、サブエージェントごとに動作を確認してください。
4. セッショントレースを分析する — トレース出力を調べ、サブエージェントの選択、アクションの利用可否と実行、LLM の推論、動作が Agent Spec と異なる箇所を確認します。この手順を省略しないでください。プレビュー出力だけでは、原因を診断するには不十分です。
5. 根本原因を特定する — トレースの証拠と仮説を照合します。Design & Agent Spec リファレンスの Core Language リファレンスとゲーティングパターンを参照し、アンチパターンがないことを確認します。
6. コードを修正する — 対象を絞った修正を適用します。修正にフロー制御の変更が含まれる場合は、Agent Spec も一致するように更新します。
7. 再検証して再プレビューする — 動作が Agent Spec と一致するか、プラットフォームの制限を確認できるまで、手順3〜6を繰り返します。validate authoring-bundle を実行してから、preview start --use-live-actions を実行し、同じ発話を使って修正を検証します。その後、変更の影響を受ける可能性のある隣接パスもテストします。
8. 修正内容を説明する — 何が問題で、何を変更したかをユーザーに伝えます。Core Language のエージェント実行モデルに基づいて根本原因を説明します。

リファレンスファイル

1. Core Language — 実行モデル、アンチパターン
2. Design & Agent Spec — Agent Spec を動作のベースラインとして使用する方法、ゲーティングパターン
3. Validation & Debugging — プレビューのワークフロー、セッショントレースの分析
4. Known Issues — 動作に問題があるものの、コードのロジックが正しい場合にのみ読み込みます

デプロイ、公開、有効化

ユーザーは、ローカル開発中の動作するエージェントを、Salesforce 組織で実行できる状態にしたいと考えています。AiAuthoringBundle とその依存関係をデプロイし、バージョンを確定するために公開してから、有効化してライブ状態にします。

必須の手順

正確なコマンド構文については、CLI for Agentsをお読みください。

1. コンパイルを検証する — sf agent validate authoring-bundle --json --api-name <Developer_Name> 検証に失敗した場合は、先に進まないでください。
2. バンドルと依存関係をデプロイする — 依存関係の管理とデプロイコマンドについては、メタデータとライフサイクルをお読みください。AiAuthoringBundleと、すべてのアクション実装（Apex クラス、Flows、Prompt Templates）および依存関係を組織にデプロイします。
3. ライブプレビュー — プレビューのワークフローとセッショントレースの分析については、検証とデバッグをお読みください。 sf agent preview start --json --use-live-actions --authoring-bundle <Developer_Name> 次に、以下を使ってテスト用の発話を送信します。 sf agent preview send --json --authoring-bundle <Developer_Name> --session-id <ID> -u "<message>" ライブアクションに基づく場合のエージェントの動作を検証するため、主要な会話経路をテストします。 チェックポイント — 以下のすべてを満たすまで、公開に進まないでください。
   • validate authoring-bundleがエラーゼロで成功している
   • ライブプレビュー（--use-live-actions）で、すべてのルーティング分岐を網羅する現実的な発話をテストしている
   • トレースで、サブエージェントのルーティング、アクションの呼び出し（FunctionStepが存在すること）、仕様に準拠した動作が確認できている
   • ユーザーがデプロイを明示的に承認している
4. 公開する（明示的なリリース手順） — 公開時に検証されるのはメタデータ構造であり、エージェントの動作ではありません。開発／テストのイナーループの一環として公開しないでください。このドラフトを確定するユーザーの確認後、かつ有効化の前に、最後の手順としてのみ公開してください。 sf agent publish authoring-bundle --json --api-name <Developer_Name> 公開に失敗した場合は、再試行する前にメタデータとライフサイクルの公開失敗のトラブルシューティングに従ってください。
5. 有効化する — 新しいバージョンをユーザーが利用できるようにします。 sf agent activate --json --api-name <Developer_Name>
6. 公開済みエージェントを検証する — 有効化後、以下を使ってユーザー向けの動作をプレビューします。 sf agent preview start --json --api-name <Developer_Name> --authoring-bundleではなく、--api-nameを使用してください。
7. エンドユーザーアクセスを設定する — 従業員向けエージェントの場合のみ実施します。権限を設定してアクセスを割り当てる方法については、エージェントアクセスガイドをお読みください。

参考ファイル

1. CLI for Agents — デプロイ、公開、有効化、無効化の正確なコマンド構文
2. 検証とデバッグ — コンパイルの検証、プレビューのワークフロー
3. メタデータとライフサイクル — 依存関係の管理、デプロイコマンド、公開時のトラブルシューティング
4. エージェントアクセスガイド — エンドユーザーのアクセス権限、可視性のトラブルシューティング
5. 既知の問題 — デプロイが停止する、公開に失敗する、または有効化が予期せず失敗する場合にのみ読み込みます

本番環境の問題を診断する

エージェントは公開され、有効化されていますが、プレビューでは検出されなかった問題が発生しています。クレジットの過剰消費、トークンまたはサイズ制限による失敗、ループガードレールによる中断、予約語による実行時エラー、VS Codeの同期失敗、プレビューと本番環境での予期しない動作の違いなどが含まれます。

必須の手順

正確なコマンド構文については、エージェント向け CLIをお読みください。

1. 問題を分類する — 請求／コストに関する懸念、実行時の制限、名前の競合、ツールの問題、プレビューと本番環境の動作の違いのいずれに該当するかを判断します。
2. 本番環境で既知の注意点を確認する — クレジット消費量、トークン制限、ループのガードレール、予約語、ライフサイクルフック、VS Code の回避策について、本番環境での注意点をお読みください。
3. プレビューと本番環境の動作を比較する — 問題が動作に関するものであれば、次のコマンドで公開済みエージェントをプレビューします。 sf agent preview start --json --api-name <Developer_Name> （--authoring-bundleではなく）。ライブアクションを使ったオーサリングバンドルのプレビュー--authoring-bundle <Developer_Name> --use-live-actionsと比較し、プレビューと本番環境の違いを特定します。
4. 既知の問題を確認する — 本番環境でのみ発生する失敗の原因となっている可能性があるプラットフォームのバグについて、既知の問題をお読みください。
5. 修正して再公開する — 修正を適用し、検証し、再度プレビューしてから公開、有効化し、確認します。デプロイ、公開、有効化の手順に従ってください。
6. 診断結果を説明する — 何が起きていたのか、何を変更したのかをユーザーに伝えます。根本原因を説明してください。

参照ファイル

1. 本番環境での注意点 — クレジット消費量、トークン制限、ループのガードレール、予約語、ライフサイクルフック、VS Code の回避策
2. エージェント向け CLI — プレビュー、公開、有効化のコマンド構文
3. 検証とデバッグ — プレビューのワークフロー、セッショントレースの分析
4. 既知の問題 — 問題がプラットフォームのバグである可能性がある場合にのみ読み込みます

エージェントの削除または名前の変更

ユーザーがエージェントの削除または名前の変更を希望しています。AiAuthoringBundleのバージョン管理と公開済みバージョンへの依存関係があるため、メンテナンス作業は複雑です。

必須の手順

正確なコマンド構文については、エージェント向け CLIをお読みください。

1. 現在の状態を把握する — バージョン管理、削除の仕組み、名前変更の仕組みについて、メタデータとライフサイクルをお読みください。エージェントが公開済みか、バージョンがいくつあるか、現在有効かどうかを確認します。
2. 有効な場合は無効化する — sf agent deactivate --json --api-name <Developer_Name> 有効なエージェントは削除または名前変更できません。
3. 操作を実行する — 削除する場合は、「メタデータとライフサイクル」のリファレンスに記載された削除の仕組みに従います。名前を変更する場合は、同じリファレンスに記載された名前変更の仕組みに従います。
4. 孤立したメタデータをクリーンアップする — 孤立したメタデータ（Bot、BotVersion、GenAiPlannerBundle、GenAiPlugin、GenAiFunction）がないか確認し、あれば削除します。確認対象については、「メタデータとライフサイクル」のリファレンスに詳しく記載されています。
5. 検証する — 操作が問題なく完了したことを確認します。名前を変更した場合は、新しいバンドルがコンパイルできることを検証し、プレビューして動作を確認します。

参照ファイル

1. エージェント向け CLI — 削除、無効化、取得の正確なコマンド構文
2. 検証とデバッグ — コンパイルの検証、プレビューのワークフロー
3. メタデータとライフサイクル — 削除の仕組み、名前変更の仕組み、孤立したメタデータのクリーンアップ

エージェントのテスト

ユーザーは Agent Script エージェントの自動テストを作成したいと考えています。テストシナリオ、期待される動作、品質指標を定義するYAML形式のAiEvaluationDefinitionテスト仕様を作成します。

必須の手順

正確なコマンド構文については、CLI for Agentsをお読みください。

1. カバレッジのベースラインを確立する — Agent Specを読みます。Agent Specがない場合は、Comprehendの手順に従って、まずリバースエンジニアリングします。すべてのサブエージェント、アクション、フロー制御パスをマッピングし、テストカバレッジが必要な対象を特定します。
2. テストシナリオを設計する — テスト設計の方法論、期待値、メトリクス、テスト仕様YAML形式、テンプレートについては、testing-agentforceスキルを使用します。テストに関するすべての内容は、このスキルが扱います。カバレッジ対象ごとに、1つ以上のテストシナリオを作成します。各シナリオには、ユーザーの発話、期待されるサブエージェントへのルーティング、期待されるアクションの呼び出し、期待されるエージェントの応答を含めます。正常なパスとエッジケースの両方を含めてください。
3. テスト仕様YAMLを作成する — testing-agentforceスキルのテンプレートとリファレンスファイルを使用します。SFDXプロジェクトのspecs/<Agent_API_Name>-testSpec.yamlに保存します。
4. テストメタデータを作成する — CLIを使用して、テスト仕様からAiEvaluationDefinitionを生成します。
5. テストをデプロイする — AiEvaluationDefinitionを組織にデプロイします。
6. テストを実行する — CLIを使用してテスト実行を行います。結果を記録します。
7. 結果を分析する — 実際の結果を期待値と比較します。失敗した場合は、問題がエージェントのコード、アクションの実装、テスト仕様のどこにあるかを特定します。
8. 反復する — 必要に応じてエージェントのコードまたはテスト仕様を修正し、再デプロイして、カバレッジ目標を満たすまで再実行します。

リファレンスファイル

1. CLI for Agents — テストの作成、実行、結果取得に関する正確な コマンド構文
2. Core Language — 意義のあるテストを設計するためのエージェント 構造
3. Design & Agent Spec — テストカバレッジのベースラインとしてのAgent Spec
4. testing-agentforceスキル — テスト仕様YAML形式、期待値、 メトリクス、テスト設計の方法論、テスト仕様テンプレート

Agent Spec

Agent Specは、このスキルが作成し、利用する中心的な成果物です。エージェントの目的、ユーザーが得る成果、サブエージェントのグラフ、アクションとその実装、変数、サブエージェントの姿勢、必要に応じた決定論的制御、行動上の意図を表す、構造化された設計ドキュメントです。

Agent Specはエージェントとともに進化します。エージェントの作成時は簡潔な内容（目的、ユースケース、計画中のプレースホルダー）から始まり、エージェントの構築中に詳細化されます（フローチャート、マッピングされたアクションの実装、文書化された姿勢の選択、正当な場合にのみ追加される決定論的制御）。既存のエージェントを理解する際には、リバースエンジニアリングによって作成します。期待される動作と実際の動作を比較するためのリファレンスとなり、高度なトラブルシューティングに不可欠です。テストでは、これを基準としてテストカバレッジをマッピングします。

エージェントを変更または分析するあらゆる作業の最初の手順として、必ずAgent Specを作成または更新してください。これは一貫した作業の基盤となり、開発者が確認できる永続的な成果物です。

Agent Specの構造と作成方法については、Design & Agent Specをお読みください。

アセット

assets/ ディレクトリには、テンプレートと例が含まれています。成果物やソースファイルのひな形や具体的な参考例が必要なときに参照してください。

• assets/agent-spec-template.md — すべてのセクションとプレースホルダーの内容を含む Agent Spec テンプレートです。プロジェクトディレクトリに <AgentName>-AgentSpec.md としてコピーし、設計時に内容を記入してください。Agent Spec はファイルとして保存してください。適切にレンダリングすると、特に Mermaid Subagent Map の図が見やすくなるため、重要な設計成果物です。

• assets/agents/local-info-agent-annotated.agent — Local Info Agent を基にした、注釈付きの完全な例です。主な Agent Script 構文をすべて使用例の中で示し、各構文を使う理由をインラインコメントで説明しています。概念を組み合わせて動作するエージェントを作る方法の具体例が必要なときや、リファレンスファイルの個別の例だけでは不十分な場合に参照してください。

• assets/agents/template-single-subagent.agent — サブエージェントを 1 つ含む最小限のエージェントです。シンプルなエージェントの作成時にコピーして変更してください。

• assets/agents/template-multi-subagent.agent — 複数のサブエージェントと遷移を含む最小限のエージェントです。複雑なエージェントの作成時にコピーして変更してください。

• assets/invocable-apex-template.cls — 呼び出し可能な Apex クラスのリファレンスです。複雑な Apex アクションの実装が必要な場合にコピーして変更してください。

重要な制約

• Salesforce CLI と Salesforce 組織のみを使用してください。 他のスキル、MCP サーバー、外部ツールを参照したり、依存したりしないでください。すべてのコマンドで sf（Salesforce CLI）を使用してください。

• アクションに使用できる実装タイプは限られています。 たとえば、アクションの実装には任意の Apex クラスではなく、呼び出し可能な Apex のみを使用できます。Flow や Prompt Template にも同様の制約がある場合があります。アクションを実装に接続する際は、有効なタイプとスタブの作成方法について、Design & Agent Spec のリファレンスファイルを参照してください。

• sf agent generate test-spec はエージェントによる使用を想定していません。 人間向けに設計された、対話型の REPL 形式のコマンドです。テスト仕様を作成するときは、代わりに assets 内のボイラープレートテンプレートから始めてください。

よくある問題のクイックリファレンス

公開時に発生する「Internal Error, try again later」： サーバー側のコンパイルエラーです。500 エラーでは、どのチェックに失敗したかはわかりません。ユーザーに問題の内容を尋ねる前に、4 つの原因を順番にすべて確認してください。原因 1 で止めないでください。

1. default_agent_user のエージェントタイプの不一致。 従業員エージェントに default_agent_user があってはいけません。サービスエージェントには必ず設定が必要です（また、ユーザーに Einstein Agent ライセンスが必要です）。Design & Agent Spec のセクション 3 を参照してください。クエリを再実行してください。ユーザー名を推測してはいけません。
2. アクション定義に outputs: ブロックがない。 target: と inputs: があるアクションに outputs: がない場合、サーバー側コンパイラーは戻り値のバインディングを生成できません。CLI の validate と LSP はどちらも PASS します。失敗するのは公開時のみです。Known Issues の Issue 15 を参照してください。
3. .agent ファイル内のその他の構造上のずれ。 同じ組織内の正常なバンドルと比較してください。 sf project retrieve start --metadata "AiAuthoringBundle:<known-working-agent>" --output-dir /tmp/diff-bundle --json キーワードを 1 つずつ比較してください。必須だがドキュメントに記載されていないフィールドの欠落、ブロックの順序のずれ、または正常なバンドルにはない DSL キーワードが使われていないか確認してください。
4. 実際の一時的なバックエンドエラー。 1～3 に問題がなく、再試行ごとにレスポンスの requestId が異なる場合は、60 秒待ってから一度だけ再試行してください。

プレビュー時に発生する「Unable to access Salesforce Agent APIs...」： default_agent_user に権限がありません。Agent User Setup & Permissions を参照してください。解決策として公開してはいけません。--use-live-actions では公開済みエージェントは不要です。

設定したものとは異なるユーザー名を示す権限エラー： 上記と同じ方法で解決できます。エラーには組織のデフォルト実行ユーザーが表示されますが、根本原因は Einstein Agent User の権限です。

現在のサブエージェントのアクションは機能するのに、エージェントで権限エラーが発生する： プランナーは起動時に、すべてのサブエージェントにわたるすべてのアクションを検証します。1 つでも権限が不足していると、エージェント全体が失敗します。

シミュレーションでは機能するのに、ライブプレビューでは Apex アクションが空の結果を返す： WITH USER_MODE とオブジェクト権限の不足が組み合わさると、エラーは発生せず、結果が 0 件になります。Agent User Setup & Permissions のセクション 6.2 を参照してください。

エージェントは公開済みで ADL もインデックス済み（retrieverId が設定済み）なのに、グラウンディングを使う質問がすべて空の knowledgeSummary を返す／「その情報はありません」と応答する： Einstein Agent User に Data Cloud へのアクセス権がありません。次の 2 点を順番に確認してください。

1. 権限セット／PSL が割り当てられていない。 Agent User Setup, Step 3b.3 の確認クエリを実行してください。Data Cloud の権限セット／PSL が表示されない場合は、検出してから割り当てる手順を実行してください（優先順位：GenieDataPlatformStarterPsl PSL → GenieUserEnhancedSecurity PS → DataCloudUser PS → DataCloudArchitect PS）。
2. 権限セットでデータスペースのスコープが許可されていない。 現在、API はありません。設定 → 権限セット → 割り当て済みの権限セットをクリック → アプリの「Data Cloud Data Space Management」→ 編集 → ADL のデータスペース（通常は default）を追加 → 保存。Agent User Setup, Step 3b.4 を参照してください。

クイックリンク（詳しい情報はリファレンスを参照）

• 構文と実行モデル：コア言語
• エージェント設計／仕様策定プロセス：設計とエージェント仕様
• 姿勢の調整（エージェント型か決定論的か）：姿勢と決定性
• シナリオに応じたパターン選択：要件別パターン
• アーキテクチャの仕組みと移行：アーキテクチャパターン
• 検証、プレビュー、トレース：検証とデバッグ
• デプロイ／公開／有効化のライフサイクル：デプロイリファレンス
• メタデータのライフサイクルと公開時のトラブルシューティング：メタデータとライフサイクル
• ADL のプロビジョニングと接続：データライブラリリファレンス
• エージェントへのアクセスと権限：エージェントアクセスガイド、エージェントユーザーの設定
• 安全性レビューのフレームワーク：安全性レビュー
• 評価基準とレビューの採点：採点基準