Salesforce DevOps オートメーション(開発作業の自動化)を sf CLI v2(Salesforce のコマンドラインツール)で実現します。 **次のような場合に使用:** - ユーザーがメタデータ(システムの設定情報)をデプロイ(本番環境に反映)する - スクラッチ組織やサンドボックス(テスト用の環境)を作成・管理する - CI/CD パイプライン(自動テスト・デプロイの仕組み)をセットアップする - sf project deploy でデプロイエラーをトラブルシューティング(問題解決)する **次のような場合は使用しない:** - Apex コード(Salesforce の開発言語)を記述する場合 → platform-apex-generate を使用 - LWC コンポーネント(Salesforce の UI 部品)を構築する場合 → experience-lwc-generate を使用 - メタデータ定義を作成する場合 → platform-custom-object-generate または platform-custom-field-generate を使用 - 組織データをクエリ(検索・抽出)する場合 → platform-data-manage を使用
Salesforce DevOps automation using sf CLI v2. TRIGGER when: user deploys metadata, creates/manages scratch orgs or sandboxes, sets up CI/CD pipelines, or troubleshoots deployment errors with sf project deploy. DO NOT TRIGGER when: writing Apex code (use platform-apex-generate), building LWC components (use experience-lwc-generate), creating metadata definitions (use platform-custom-object-generate or platform-custom-field-generate), or querying org data (use platform-data-manage).
次のような場合に使用: ユーザーが導入の調整・実行を必要としている場合。つまり、事前検証、対象を絞った導入、マニフェスト(変更内容をリストアップしたファイル)による導入、CI/CDワークフロー(開発から本番への自動化の手引き)のアドバイス、スクラッチ組織(テスト用の一時的な組織)の管理、導入失敗の原因特定、Salesforceメタデータ(組織の構成情報)の安全な段階的導入などが該当します。
次の作業に platform-metadata-deploy を使用:
sf project deploy start、quick、report などのコマンドや検索ワークフロー以下の場合は別のスキルに任せてください:
sf CLIはバージョン2のみを使用。--source-dir、--metadata、--manifest などの範囲指定が必須。--dry-run(事前検証)を実施。platform-data-manage に任せる。| 段階 | メタデータ(構成情報)の種類 |
|---|---|
| 1 | カスタムオブジェクト / フィールド |
| 2 | 権限セット |
| 3 | Apex |
| 4 | フロー(下書き状態) |
| 5 | フロー有効化 / 検証後処理 |
この順序で進めることで、多くの依存関係エラーやセキュリティ設定エラーを防げます。
以下について質問するか、推測で判断:
導入前の確認:
sf --version
sf org list
sf org display --target-org <alias> --json
test -f sfdx-project.json
認証、リポジトリの構成、パッケージディレクトリ、対象範囲を確認。
sf project deploy start --dry-run --source-dir force-app --target-org <alias> --wait 30 --json
変更内容が限定的な場合は、マニフェストまたはメタデータでスコープを絞った検証を使用。
検証成功後、ユーザーを正しい次のアクションに導く:
# ソースディレクトリ導入
sf project deploy start --source-dir force-app --target-org <alias> --wait 30 --json
# マニフェスト導入
sf project deploy start --manifest manifest/package.xml --target-org <alias> --test-level RunLocalTests --wait 30 --json
# Spring '26で関連テストの選択機能を使ったマニフェスト導入
sf project deploy start --manifest manifest/package.xml --target-org <alias> --test-level RunRelevantTests --wait 30 --json
# 検証成功後の高速導入
sf project deploy quick --job-id <validation-job-id> --target-org <alias> --json
sf project deploy report --job-id <job-id> --target-org <alias> --json
その後、テスト、フロー状態、権限の割り当て、動作確認を検証。
導入されたもの、失敗したもの、スキップされたもの、次に安全に進めるべきアクションを要約。
出力テンプレート: references/deployment-report-template.md
| エラー / 症状 | 原因の可能性 | 対応方向 |
|---|---|---|
FIELD_CUSTOM_VALIDATION_EXCEPTION |
検証ルールまたは不正なテストデータ | データまたはルールのタイミング調整 |
INVALID_CROSS_REFERENCE_KEY |
必要なメタデータが不足 | 参照先メタデータを先に含める |
CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY |
トリガー(自動実行プログラム)、フロー、検証ルールの副作用 | 自動化全体と失敗ロジックを検査 |
| 導入時のテスト失敗 | コード破損またはテストが脆弱 | 対象テストを実行、根本原因を修正、再検証 |
| 権限セットにフィール ド/オブジェクトがない | 導入順序の誤り | オブジェクト/フィールドを権限セットの前に導入 |
| フロー無効 / バージョン競合 | 依存関係または有効化の問題 | フローを下書きで導入、検証後に有効化 |
詳細ワークフロー: references/orchestration.md、references/trigger-deployment-safety.md
標準的なパイプライン(自動化の流れ):
--test-level RunRelevantTests の使用を検討。@IsTest(testFor=...) や @IsTest(isCritical=true) といった最新のApexテストアノテーション(記号)と組み合わせる。作成ガイドは platform-apex-generate を参照。静的分析は廃止されたsf scannerではなく、Code Analyzer v5(sf code-analyzer)を使用。
詳細参考資料: references/deployment-workflows.md
このスキルを使用してエージェント周辺の導入・公開順序を調整しますが、エージェント作成の判断は専用スキルで行ってください:
.agent ファイル作成、Agent Builder(ビルダー)、Prompt Builder(プロンプト作成)、メタデータ設定エージェント DevOps 全般(Agent: 疑似メタデータ、公開・有効化、組織間同期など)について詳しくは:
| 必要な作業 | 任せるスキル | 理由 |
|---|---|---|
| カスタムオブジェクト作成 | platform-custom-object-generate | 導入前にオブジェクト定義 |
| カスタムフィールド作成 | platform-custom-field-generate | 導入前にフィールド定義 |
| Apex作成 / 修正 | platform-apex-generate | コード作成と修復 |
| フロー作成 / 修復 | automation-flow-generate | フロー作成と有効化ガイド |
| テストデータまたはレコード作成 | platform-data-manage | データ設定と削除 |
| エージェント作成と公開準備 | agentforce-generate | エージェント固有の確認 |
| スコア | 意味 |
|---|---|
| 90+ | 導入計画と実行ガイダンスが充実 |
| 75–89 | 導入ガイダンスが充実、軽微な確認項目あり |
| 60–74 | 導入リスク対応が部分的 |
| < 60 | 信頼度が不十分、ロールアウト前に計画を詰める必要あり |
導入目標: <検証 / 導入 / 検索 / パイプライン>
対象組織: <エイリアス>
範囲: <ソースディレクトリ / メタデータ / マニフェスト>
結果: <成功 / 失敗 / 部分成功>
重要な知見: <エラー、順序、テスト、スキップ項目>
次ステップ: <安全な次アクション>
Use this skill when the user needs deployment orchestration: dry-run validation, targeted or manifest-based deploys, CI/CD workflow advice, scratch-org management, failure triage, or safe rollout sequencing for Salesforce metadata.
Use platform-metadata-deploy when the work involves:
sf project deploy start, quick, report, or retrieval workflowsDelegate elsewhere when the user is:
sf CLI v2 only.--source-dir, --metadata, or --manifest.--dry-run first before real deploys.platform-data-manage after metadata is validated or deployed.| Phase | Metadata |
|---|---|
| 1 | Custom objects / fields |
| 2 | Permission sets |
| 3 | Apex |
| 4 | Flows as Draft |
| 5 | Flow activation / post-verify |
This ordering prevents many dependency and FLS failures.
Ask for or infer:
Preflight checks:
sf --version
sf org list
sf org display --target-org <alias> --json
test -f sfdx-project.json
Confirm auth, repo shape, package directories, and target scope.
sf project deploy start --dry-run --source-dir force-app --target-org <alias> --wait 30 --json
Use manifest- or metadata-scoped validation when the change set is targeted.
After a successful validation, guide the user to the correct next action:
# source-dir deploy
sf project deploy start --source-dir force-app --target-org <alias> --wait 30 --json
# manifest deploy
sf project deploy start --manifest manifest/package.xml --target-org <alias> --test-level RunLocalTests --wait 30 --json
# manifest deploy with Spring '26 relevant-test selection
sf project deploy start --manifest manifest/package.xml --target-org <alias> --test-level RunRelevantTests --wait 30 --json
# quick deploy after successful validation
sf project deploy quick --job-id <validation-job-id> --target-org <alias> --json
sf project deploy report --job-id <job-id> --target-org <alias> --json
Then verify tests, Flow state, permission assignments, and smoke-test behavior.
Summarize what deployed, what failed, what was skipped, and what the next safe action is.
Output template: references/deployment-report-template.md
| Error / symptom | Likely cause | Default fix direction |
|---|---|---|
FIELD_CUSTOM_VALIDATION_EXCEPTION |
validation rule or bad test data | adjust data or rule timing |
INVALID_CROSS_REFERENCE_KEY |
missing dependency | include referenced metadata first |
CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY |
trigger / Flow / validation side effect | inspect automation stack and failing logic |
| tests fail during deploy | broken code or fragile tests | run targeted tests, fix root cause, revalidate |
| field/object not found in permset | wrong order | deploy objects/fields before permission sets |
| Flow invalid / version conflict | dependency or activation problem | deploy as Draft, verify, then activate |
Full workflows: references/orchestration.md, references/trigger-deployment-safety.md
Default pipeline shape:
--test-level RunRelevantTests for Apex-heavy deployments.@IsTest(testFor=...) and @IsTest(isCritical=true) — see platform-apex-generate for authoring guidance.Static analysis now uses Code Analyzer v5 (sf code-analyzer), not retired sf scanner.
Deep reference: references/deployment-workflows.md
Use this skill to orchestrate deployment/publish sequencing around agents, but use the agent-specific skill for authoring decisions:
.agent authoring, Agent Builder, Prompt Builder, and metadata configFor full agent DevOps details, including Agent: pseudo metadata, publish/activate, and sync-between-orgs, see:
| Need | Delegate to | Reason |
|---|---|---|
| custom object creation | platform-custom-object-generate | define objects before deploy |
| custom field creation | platform-custom-field-generate | define fields before deploy |
| Apex authoring / fixes | platform-apex-generate | code authoring and repair |
| Flow creation / repair | automation-flow-generate | Flow authoring and activation guidance |
| test data or seed records | platform-data-manage | describe-first data setup and cleanup |
| Agent authoring and publish readiness | agentforce-generate | agent-specific correctness |
| Score | Meaning |
|---|---|
| 90+ | strong deployment plan and execution guidance |
| 75–89 | good deploy guidance with minor review items |
| 60–74 | partial coverage of deployment risk |
| < 60 | insufficient confidence; tighten plan before rollout |
Deployment goal: <validate / deploy / retrieve / pipeline>
Target org: <alias>
Scope: <source-dir / metadata / manifest>
Result: <passed / failed / partial>
Key findings: <errors, ordering, tests, skipped items>
Next step: <safe follow-up action>
原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。