🛬

Salesforce の mcp server でできることを VibeCody に聞いてみた

に公開
Salesforce
Model Context Protocol
MCP サーバー
zennfes2025free
tech

Salesforce の開発エージェント Vibe Cody に、Salesforce の mcp server でできることを聞いてみたよ！
自分のメモも兼ねて投稿します。

はじめに

Salesforce MCP サーバー（ https://github.com/salesforcecli/mcp ）が提供する主なツールと用途のカタログです。
実装観点で、いつ使うべきか・入力要件のポイントも併記します。

1. get_username

  • 目的: デプロイ/取得/テストなど他ツールに渡す org の username/alias を安全に解決
  • 代表的用途: 既定のターゲット org（または Dev Hub）を取得
  • 入力要点: defaultTargetOrg, defaultDevHub の指定。曖昧な場合は両方 false で解決候補を返す

2. deploy_metadata

  • 目的: ローカルのメタデータを org にデプロイ

  • 代表的用途: force-app の変更を反映、特定のディレクトリ/manifest を指定してデプロイ、テストレベルの制御

  • 入力要点:

    • sourceDir or manifest（曖昧依頼なら未指定で差分計算）
    • apexTestLevel または apexTests（両方は同時指定しない）
    • usernameOrAlias（不明なら get_username で解決）

3. retrieve_metadata

  • 目的: org からローカルへメタデータを取得

  • 代表的用途: 最新設定の引き込み、特定コンポーネント/manifest の取得、差分確認

  • 入力要点:

    • sourceDir or manifest（曖昧依頼なら未指定で必要コンポーネント計算）
    • usernameOrAlias（不明なら get_username）

4. run_soql_query

  • 目的: 指定 org に対する SOQL 実行
  • 代表的用途: データ確認、設定検証、ID の取得、デバッグ補助
  • 入力要点: query は必須。Tooling API 利用可否(useToolingApi)は必要時のみ

5. run_apex_test

  • 目的: Apex テストの実行と結果取得

  • 代表的用途: 単一/複数テストクラス実行、全ローカル/全組織テスト、非同期実行、カバレッジ集計

  • 入力要点:

    • testLevel（RunLocalTests / RunAllTestsInOrg / RunSpecifiedTests）
    • RunSpecifiedTests の場合は classNames（必要に応じて methodNames）
    • async/verbose/codeCoverage の指定
    • usernameOrAlias

6. assign_permission_set

  • 目的: パーミッションセットの付与

  • 代表的用途: UAT/開発ユーザへ権限付与、自分または「onBehalfOf」指定の他ユーザへ割当

  • 入力要点:

    • permissionSetName は単一
    • onBehalfOf は明示時のみ
    • usernameOrAlias

7. list_all_orgs

  • 目的: ローカルに認証済みの org 一覧を取得
  • 代表的用途: 接続確認、対象 org の選定
  • 入力要点: ディレクトリ指定のみ。org 選定には get_username 推奨

8. resume_tool_operation

  • 目的: 途中で中断/非同期の長時間ジョブを再開/待機
  • 代表的用途: デプロイジョブ、テストラン、スクラッチ org 作成、スナップショットなどの継続
  • 入力要点: jobId が必須。必要に応じて wait 分指定、usernameOrAlias

9. guide_lwc_development

  • 目的: LWC 開発のガイダンスを取得（設計/実装ベストプラクティス）
  • 代表的用途: 新規コンポーネントの構成、状態管理、テスト、イベント設計の指針

10. orchestrate_lwc_component_creation

  • 目的: LWC 作成を段階的にオーケストレーション
  • 代表的用途: 要件定義→雛形生成→テスト→アクセシビリティ確認のワークフロー提示

11. create_lwc_component_from_prd

  • 目的: PRD（要件）から LWC を自動生成するための支援
  • 代表的用途: PRD テキストを入力し、フィールド・UI・イベントの雛形生成ガイド

12. guide_lwc_accessibility

  • 目的: LWC のアクセシビリティ改善ガイド（画像有りなら Vision AI 観点も）
  • 代表的用途: ARIA、キーボード操作、コントラスト、代替テキスト、フォーカス管理

13. detect_devops_center_merge_conflict

  • 目的: DevOps Center の特定 Work Item を対象に、ターゲットブランチとの競合検出

  • 代表的用途: マージ前の衝突チェック、自動で対象ブランチ/リポジトリを解決

  • 入力要点:

    • workItemName（厳密一致必須）
    • username（DevOps Center org）
    • localPath（通常は作業リポジトリ）

14. resolve_devops_center_merge_conflict

  • 目的: 上記検出結果に基づく競合解消手順の提示（ファイル別に具体コマンド）

  • 代表的用途: keep current/incoming/both の選択、ステージング〜コミットまでの誘導

  • 入力要点:

    • workItemName（厳密一致）
    • username（DevOps Center org）
    • localPath

実務での使い分けの指針

  • org 指定の原則: usernameOrAlias が不確かな場合は必ず get_username を先行使用

  • デプロイ/取得の絞り込み:

    • manifest を持つ場合は manifest 指定
    • 単一/限定範囲なら sourceDir 指定
    • 作業差分を一括反映したい曖昧依頼は未指定（自動計算）

  • テスト戦略:

    • 開発時は RunSpecifiedTests で対象を最小化
    • CI/本番前検証は RunLocalTests（パッケージ外のみ）または RunAllTestsInOrg

  • DevOps Center:

    • マージ前に detect_devops_center_merge_conflict → 競合があれば resolve_devops_center_merge_conflict を実施

  • LWC 開発:

    • 仕様検討は guide_lwc_development / guide_lwc_accessibility
    • 自動生成型は orchestrate_lwc_component_creation / create_lwc_component_from_prd を活用

補足（運用ルール）

  • Salesforce CLI は sf 系を使用（sfdx 形式は非推奨）
  • 実 org 操作（デプロイ/取得/テスト/PermSet）は影響範囲があるため、usernameOrAlias を厳密に解決してから実行
  • 新規オブジェクト/クラス/トリガ作成時はメタデータ XML を併せて用意する

この機能カタログは実装手順に直結できるように整理しています。必要であれば、上記のいずれかのツールについて具体的な実行例（パラメータ指定のサンプル）を提示した実装ガイドを提供します。

Discussion