次世代DevOpsCenterでSalesforce開発はどう変わる？

こんにちは、株式会社TERASSでSalesforceをやったりやらなかったりしているimslpです。
今回は次世代DevOpsCenterを試してみた話です。

はじめに

少し前にSalesforceの変更管理・リリース管理を支援するDevOpsCenterに「次世代DevOpsCenter」なるものが登場しましたね。
https://help.salesforce.com/s/articleView?id=platform.next_generation_devops_center.htm&type=5

従来のDevOpsCenterは、Salesforceの変更をワークアイテム単位で管理し、GitHubなどのソース管理と連携しながら、開発環境から本番環境まで変更を安全に昇格させるためのツールです。宣言的な開発が多いSalesforceにおいて、変更セットよりもチーム開発に向いたリリース管理を実現できる点が大きな価値でした。

https://zenn.dev/terass_dev/articles/6670f7051aa2c3

一方で、日々の操作ではDevOpsCenterのUI、GitHub、ローカルのSalesforceプロジェクト、開発環境を行き来する場面も多く、もう少し作業導線が短くなるとよいなと感じることもありました。

次世代DevOpsCenterは、よりモダンな開発体験へと刷新されています。特に注目したいのは、Salesforce DX MCP Serverを通じたDevOpsCenter操作です。

この記事では、まず従来のDevOpsCenterと次世代DevOpsCenterの違いを整理し、そのうえでMCP経由でワークアイテムを操作できるようになった点を中心に紹介します。

次世代DevOpsCenterとは

基本的には従来のDevOpsCenterと同じです。チームはDevOpsCenter上でプロジェクトを作成し、開発環境、検証環境、本番環境などをパイプラインとして接続します。そして、個々の変更を「ワークアイテム」として管理し、作業の進捗や変更内容を追跡しながら、段階的にプロモートしていきます。

つまり、DevOpsCenterの中心にあるのは引き続き以下のような流れです。

1. 作業単位としてワークアイテムを作成する
2. 開発環境で変更を行う
3. 変更内容を確認してコミット・プッシュする
4. PRやレビューを通じてチームで確認する
5. パイプラインに沿って次の環境へプロモートする
6. 最終的に本番環境へリリースする

この流れ自体は従来のDevOpsCenterと大きく変わりません。

従来のDevOpsCenterとの主な違い

次世代DevOpsCenterでは、従来のDevOpsCenterに対していくつかの大きな改善が加えられています。ここに挙げているもの以外にも変更はあると思いますが、個人的なトピックを挙げています。

1. 管理パッケージではなくなった

従来のDevOpsCenterは管理パッケージとして組織にインストールする必要がありましたが、次世代DevOpsCenterでは有効化するだけですぐに使用を開始することができます。

2. MCPによるDevOpsCenter操作

個人的に最も大きく感じている変更点のひとつがMCPによるDevOpsCenter操作です。

次世代DevOpsCenterでは、Salesforce DX MCP ServerとDevOpsCenter MCP Toolsを利用することで、DevOpsCenterの操作やトラブルシュートをAIと連携して進められるようになります。

たとえば、マージ競合が発生した場合や、デプロイに失敗した場合に、自然言語のプロンプトを使って原因の調査や解決方針の提示を受けることができます。

今回の記事では、このAI支援のうち、特にMCP経由でDevOpsCenterのワークアイテムを操作できる点に注目します。

3. DORA Metricsによる分析

次世代DevOpsCenterでは、DORA Metricsを使ってプロジェクトのパフォーマンスを確認できます。

お恥ずかしながらDORA Metricsというものをきちんと知らなかったのですが、DevOpsのパフォーマンスを測るための代表的な指標のようです。ざっくり言うと、「どれくらい速く、安定して変更を届けられているか」を見るためのものです。

次世代DevOpsCenter上では、たとえば以下のような指標を確認できます。

• Promotions to Production: 選択した期間中に本番に昇格された作業項目の数。
• Average Lead Time: 最初の確定から最終昇格、本番稼働までの平均時間。
• Change Failure Rate: 失敗したプロモーションまたは修正が必要なプロモーションの割合。

まだ具体的にどのように使うのかイメージついていませんが、リリースの振り返り材料になりそうですね。

4. DX Inspectorとの統合

次世代DevOpsCenterはDX Inspectorと統合されており、開発組織から直接メタデータやデータの変更を追跡・確認できます。

DX InspectorはSandboxのヘッダーとして表示されているアレです。いつの日からか追加されたと思っていましたが、ここで使うようです。

次世代DevOpsCenterでUI上からコミットを行う場合はDX Inspectorを利用することになります。従来の方法とは全く違うので戸惑わないように注意が必要です。

MCP経由でDevOpsCenterを操作できるようになった

今回特に興味をそそられたのが、Salesforce DX MCP ServerのDevOpsCenterツールです。

Salesforce DX MCP Serverを使うことで、Claude Code、Codex、Copilotなどから、Salesforce組織やSalesforce DX関連の操作を行えるようになります。

Salesforce DX MCP Serverには複数のtoolsetが用意されており、その中にdevopstoolsetがあります。このDevOpsCenter toolsetには、DevOpsCenterのワークアイテムやプロモーションに関する操作が含まれています。

たとえば、以下のような操作がMCPツールとして提供されています。

• DevOpsCenterプロジェクトの一覧取得
• ワークアイテムの一覧取得
• ワークアイテムの作成
• ワークアイテムのステータス更新
• ワークアイテムに関連するブランチのチェックアウト
• ワークアイテムへの変更コミット
• PR作成
• マージ競合の検出
• マージ競合の解決
• デプロイ失敗の診断・解決
• 承認済みワークアイテムの次フェーズへのプロモート

MCPの詳細はこちら↓
https://github.com/salesforcecli/mcp

従来は、DevOpsCenterのUIを開き、プロジェクトを選び、ワークアイテムを作成し、ステータスを変更し、プロモートするという操作を画面上で行う必要がありました。
（もちろん、ワークアイテムなどはオブジェクト管理されているはずなので、CLIでうまいことやりくりしている組織もあるかもしれませんが、私はそこまで踏み込めていませんでした）

しかし、DevOpsCenter MCP Toolsを利用すると、自然言語プロンプトから、ワークアイテムの作成からプロモートまでの一連の操作を行えるようになります。

これはかなり大きな変化だと思います。開発者がVS Codeなどを開いたまま、「この作業用のワークアイテムを作って」「変更をコミットして」「次の環境にプロモートして」と指示できるようになると、DevOpsCenterを強く意識する必要がなくなります。

実際に試してみる

ここからは、MCP経由でDevOpsCenterのワークアイテムを操作できるか試してみます。

今回は、以下のような流れで検証します。

1. DevOpsCenterのプロジェクト一覧を取得する
2. 対象プロジェクトにワークアイテムを作成する
3. 作成されたワークアイテムのステータスを更新する
4. 変更を行い、ワークアイテムに紐づけてコミットする
5. ワークアイテムのステータスを更新し、プロモート準備完了状態にする
6. 次の環境へプロモートする

プロジェクト一覧を確認する

まずはDevOpsCenterに接続できているかを確認します。

DevOpsCenterのプロジェクト一覧を取得してください。

ここでMCPクライアントがlist_devops_center_projectsを利用し、対象組織のDevOpsCenterプロジェクトを取得できれば、接続は成功です。

ワークアイテムを作成する

次に、対象プロジェクトにワークアイテムを作成します。

ワークアイテムを作成してください

この操作ではcreate_devops_center_work_itemが利用されます。
作成後、DevOpsCenterのUIを開いて、実際にワークアイテムが作成されているか確認します。

ワークアイテムのステータスを更新する

作業を開始する前に、ワークアイテムのステータスを更新します。

ワークアイテムを進行中にしてください

この操作ではupdate_devops_center_work_item_statusが使われます。
DevOpsCenterのUI側でも、対象ワークアイテムがIn Progressになっていることを確認します。

なお、checkout_devops_center_work_itemでもワークアイテムは進行中に更新されるはずなので、実運用ではステータス更新とチェックアウトをまとめて行ってもよさそうです。今回はMCPツールの動きを確認するため、あえてステータス更新を単独で実行しています。

ワークアイテムのブランチをチェックアウトする

作業を開始するため、ワークアイテムのブランチをチェックアウトします

ワークアイテムのブランチをチェックアウトしてください

この操作ではcheckout_devops_center_work_itemが使われます。
ローカルでブランチをチェックアウトしてくれるので、このまま作業に移ります。

変更内容を確認してコミットする

開発環境で変更を行ったあと、その変更をワークアイテムに紐づけてコミットします。

（余談）UI上でのコミット

変更差分を確認し、コミットしてください。

この操作ではcommit_devops_center_work_itemが使われます。
このように依頼することで、DevOpsCenterのワークアイテムに紐づいたコミット操作を行わせることができます。

PRを作成する

PRを作成してください

この操作ではcreate_devops_center_pull_requestが使われます。
PRを作成し、レビューしてもらう準備ができました。

ワークアイテムのステータスも変わり、変更差分も想定通りとなっています

プロモート準備完了状態にする

レビュアーがレビューを完了したらプロモート準備完了とします。
（実際はレビュアーがやる作業になると思います）

WI-000008のワークアイテムをReady to Promoteに変更してください。

この操作でもupdate_devops_center_work_item_statusが利用されます。

次の環境へプロモートする

最後に、ワークアイテムを次のパイプラインステージへプロモートします。

WI-000008のワークアイテムをプロモートしてください。

この操作では、promote_devops_center_work_itemが利用されます。
本番へのプロモートも同様に行えるので、ここは少し注意が必要かもしれません。

その他のMCPツール

DevOpsCenter MCP Toolsは、単なる操作自動化だけではなく、AI支援による問題解決にも利用できます。

たとえば、マージ競合が発生したときに、以下のようなプロンプトを投げることができます。

このワークアイテムで発生しているマージ競合を検出し、
競合しているファイル、競合の原因、推奨される解決方法を説明してください。
解決前に、どの方法で解決するか確認してください。

また、デプロイ失敗時には以下のような使い方が考えられます。

直近のDevOpsCenterプロモーションが失敗した原因を調査してください。
エラーメッセージ、関連するメタデータ、修正候補を整理し、
次に実行すべきアクションを提案してください。

特にSalesforceのデプロイエラーは、依存関係や権限、レイアウト、フロー、Apexテストなど複数要因が絡みやすいため、AIによる整理と提案は相性が良さそうです。

Claudeなどのツールから効率よく使うための自作Skill

MCPを試す中で、この辺の作業は一気にやりたいんだよな〜と思うことがありました。
それらをまとめてスキル化してみたので紹介します。
プロジェクト名などハードコードしている部分があるので、そのまま使う場合は注意が必要です。

sf-dev-start

開発を開始するときに使用するスキルです。
ワークアイテムの作成からチェックアウトまでを行い、すぐに作業開始できるようにします。

skills本文

---
name: sf-dev-start
description: Salesforce DevOps Center でワークアイテムを作成し、進行中に移してブランチを切り替えるまでを一気通貫で行う
user-invocable: true
---

# sf-dev-start

`salesforce-dx` MCP サーバーの devops ツールセットを使い、ワークアイテム作成からブランチ切り替えまでを自動で行う。

## 実行ステップ

### 1. 入力収集

- 件名が必須、説明は任意でユーザーから入力を受け取る。

### 2. プロジェクト選択

`list_devops_center_projects` を呼び出してプロジェクト一覧を取得する。


tool: list_devops_center_projects
  usernameOrAlias: "pg-devops"


プロジェクトが1件のみなら自動選択する。複数ある場合はユーザーに選択を求める。

### 3. ワークアイテム作成

`create_devops_center_work_item` で新規ワークアイテムを作成する。


tool: create_devops_center_work_item
  usernameOrAlias: "pg-devops"
  projectId:       <手順2で選択したプロジェクトのId>
  subject:         <ユーザーが入力したタイトル>
  description:     <ユーザーが入力した説明（任意）>


### 4. ブランチ切り替えと進行中への更新

`list_devops_center_work_items` を呼び出し、subject が一致する最新のワークアイテムの `name`（例: `WI-000002`）を取得して以降のステップで使う。

`checkout_devops_center_work_item` を呼び出す前に、ローカルに未コミットの変更がないか `git status` で確認する。未コミット変更がある場合はユーザーに通知し、`git stash` またはコミットで解消してからチェックアウトするよう案内する。

問題なければ `checkout_devops_center_work_item` を呼び出す。このツールはブランチの切り替えと同時に、ワークアイテムのステータスを自動的に **In Progress** へ更新する。


tool: checkout_devops_center_work_item
  usernameOrAlias: "pg-devops"
  workItemName:    <手順3で取得したワークアイテム名>
  localPath:       <省略（カレントディレクトリを使用）>


### 5. 完了報告

以下をユーザーに伝える。

- 作成したワークアイテム名
- 現在のブランチ名

sf-dev-commit

コミットをしてPRを作成するスキルです。
PR作成は毎回自動で行いたいわけではないため、ユーザーに確認してから作成する流れにしています。

skills本文

---
name: sf-dev-commit
description: ローカルの変更を DevOps Center のワークアイテムにコミットし、必要に応じて PR を作成する
user-invocable: true
---

# sf-dev-commit

`salesforce-dx` MCP サーバーの `commit_devops_center_work_item` を使い、ローカル変更のコミットから任意のPR作成までを行う。

## 実行ステップ

### 1. 変更の確認

`git status` と `git diff --stat` でコミット対象の変更を確認し、ユーザーに内容を提示する。

変更がない場合はその旨を伝えて終了する。

### 2. コミットメッセージの決定

- メッセージが渡されていればコミットメッセージとして使う。
- メッセージが渡されていない場合は、変更内容をもとに適切なコミットメッセージを提案し、ユーザーに確認する

### 3. ワークアイテムの特定

`list_devops_center_projects` でプロジェクトを取得する。


tool: list_devops_center_projects
  usernameOrAlias: "pg-devops"


プロジェクトが1件のみなら自動選択する。複数ある場合はユーザーに選択を求める。

次に `list_devops_center_work_items` で現在のブランチに対応するワークアイテムを特定する。


tool: list_devops_center_work_items
  usernameOrAlias: "pg-devops"
  projectId:       <選択したプロジェクトのId>


現在のブランチ名（`git branch --show-current`）と一致するワークアイテムを選ぶ。該当が複数またはない場合はユーザーに選択を求める。

### 4. コミット実行

`commit_devops_center_work_item` を呼び出す。


tool: commit_devops_center_work_item
  usernameOrAlias: "pg-devops"
  workItemName:    <手順3で特定したワークアイテム名>
  localPath:       <省略（カレントディレクトリを使用）>
  commitMessage:   <手順2で決定したコミットメッセージ>


### 5. PR 作成の確認

コミット完了後、`AskUserQuestion` でPR作成を確認する。


質問: "Pull Request を作成しますか？"
選択肢:
  - "作成する"
  - "後で作成する"


「作成する」が選ばれた場合は手順6へ進む。「後で作成する」の場合は手順7へ進む。

### 6. PR 作成（任意）

`create_devops_center_pull_request` を呼び出す。


tool: create_devops_center_pull_request
  usernameOrAlias: "pg-devops"
  workItemName:    <手順3で特定したワークアイテム名>


### 7. 完了報告

以下をユーザーに伝える。

- コミットしたワークアイテム名
- コミットメッセージ
- PR を作成した場合はそのURL（取得できる場合）

おわり

ここまで見てきた通り、次世代DevOpsCenterはかなり魅力的です。MCP経由でワークアイテムを操作できるようになったことで、開発体験は大きく変わりそうだと感じました。

一方で、すでに従来のDevOpsCenterを運用している組織では、すぐに移行するかどうかは少し慎重に考えてもよさそうです。次世代DevOpsCenterを有効化するには従来のDevOpsCenterを無効化する必要があり、既存のワークアイテム、プロジェクト、パイプラインも自動移行されません。

Salesforce側でも移行プログラムの作成に取り組んでいるとのことなので、今後の改善に期待したいところです。

新規プロジェクトであれば次世代DevOpsCenterを試しやすい一方、既存運用中の組織では、安全に移行できる見通しが立つまでは様子見でもよいのかなと個人的には思っています。

また、Hosted MCPでもワークアイテムの作成くらいはできるようになると嬉しいなと感じました。DevOpsCenterのUIを開かずに、普段使っているAIツールから作業開始できる体験はかなり便利だったので、今後さらに使いやすくなることを期待しています。