ADOC、NECネッツエスアイとSalesforceの品質保証領域で協業

Salesforce専用テスト自動化ツール『Provar』により、業務効率化と外販を支援

株式会社アドックインターナショナル（本社：東京都立川市、代表取締役CEO：小林 常治、以下 ADOC）は、NECネッツエスアイ株式会社（本社：東京都港区、代表取締役：大野 道生、以下 NESIC）と、Salesforce開発・運用における品質向上および業務効率化、ソリューションの外販を目的として、Salesforce専用設計のテスト自動化ツール『Provar（プロバー）』を活用した協業を開始します。

本協業では、まずNESIC自社内のSalesforce開発・運用においてProvarを活用し、テスト工程の効率化、手動テスト工数の削減、人的ミスの低減、テスト自動化ノウハウの蓄積を進めます。そのうえで、そこで得られた実践的な知見をもとに、NECグループおよびNESICの既存顧客を中心に「Salesforce開発・運用自動化ソリューション（仮称）」として展開していくことを目指します。

Salesforceの課題とProvarの役割

Salesforceは、企業の営業、顧客管理、サポート、マーケティングの中核業務を支えるクラウドプラットフォームとして広く活用されています。一方で、導入後の機能追加、画面変更、FlowやApexの改修、外部システム連携、年3回のSalesforceメジャーリリースへの対応、さらにはAIエージェント「Agentforce」の登場などにより、開発・運用現場では手戻りのない継続的な品質確保が重要な課題となっています。

特に、手動テストに依存した運用では、確認作業の工数増大、テスト観点の属人化、リリース前後の回帰リスク、人的ミスによる確認漏れなどが発生しやすくなります。さらに今後、AIエージェントや自動化技術の活用が進む中では、Salesforce上の業務プロセス全体を継続的かつ再現性高く検証する仕組みが、より重要になります。

Provarは、Salesforceに特化して設計されたテスト自動化ツールです。Salesforceのメタデータを活用し、画面構造の変化に強いテスト設計を可能にすることで、SalesforceおよびAgentforceの開発・運用における回帰テスト、E2Eテスト、権限別テスト、外部連携を含む業務シナリオの検証を支援します。

協業の背景と概要

今回の協業において、NESICはまず自社内のSalesforce開発・運用にProvarを活用し、現場でのテスト自動化効果を検証します。具体的には、手動テストの工数削減、人的ミスの低減、Provar活用に関する技術ノウハウの内部蓄積、現場運用を通じたテスト自動化のベストプラクティスの検討を進めます。また、効率化によって創出された従業員リソースを、AI時代の戦略立案や業務改善など、より付加価値の高い業務へ振り向けることを目指します。

一方ADOCは、Provarの国内総代理店として、NESICに対する技術習得支援、Provar活用に向けた技術支援、営業活動支援、ソリューション化に向けた支援を行います。また、ADOCの見込み顧客のうち、NESICとの接点やNESICの既存サービスとのシナジーが見込まれる顧客については、NESICへの紹介や共同提案も検討します。さらに、NESIC自社内でのProvar活用結果の分析、ターゲット顧客向けソリューションの作り込み、営業同行、Provar社と連携した営業資材の作成、Provar製品の提供を通じて、NESICのSalesforce事業拡大を支援します。

今後、両社はNESIC自社内での実践を起点に、Provarを活用したSalesforce開発・運用自動化のノウハウを蓄積し、NECグループおよびNESICの既存顧客に向けて、より実践的で導入効果の高いSalesforce品質向上のためのソリューションの提供を目指します。

株式会社アドックインターナショナル 代表取締役CEO 小林 常治 コメント

「Salesforceの開発・運用に伴う品質保証は、単なるテスト工程ではなく、事業継続や業務変革を支える重要なテーマになっています。NESIC様が自社内でProvarを活用し、その実践知をもとにお客様向けソリューションへ展開していく取り組みは、」Salesforceテスト自動化の価値をより多くの企業に届けるうえで大きな意味を持つものです。今後ADOCは、Provarの技術および営業支援、ソリューション化の支援等を通じて、NESIC様とともにSalesforce開発・運用の品質向上と業務効率化を推進してまいります」

リリースPDF

【ブログ】Salesforceの「壊れない」、「続けられる」を実現するテスト自動化：手動と汎用ツールの限界を乗り越える

Salesforceの「壊れない」、「続けられる」を実現するテスト自動化：手動と汎用ツールの限界を乗り越える

はじめに：なぜ手動テストはSalesforceの進化に追いつけないのか

Salesforceは今や単なる顧客管理ツールではなく、ローコード設定と高度なプログラムが密接に絡み合う巨大な業務基盤へと進化を遂げました。この進化はビジネスに柔軟性をもたらす一方で、開発における「品質担保の難易度」を劇的に押し上げています。

「以前は手動テストで回せていたのに、最近はリリース後のトラブルが目立つようになった」

そう感じているのであれば、それは現場の体制だけの問題ではなく、システムの複雑さが「人間が目で見て確認できる限界」を超えてしまったサインかもしれません。

Salesforceには、その利便性と引き換えに、手戻りやテスト不足を誘発する構造的な要因が存在します。また、今後のAIエージェント（Agentforce）の普及などによって、AI特有の問題が現場の対応をより複雑にします。本記事では、Salesforce独自の自動化を阻む要因や、汎用ツールに比べ専用設計のテスト自動化ツール「Provar」が解決になること、またその導入ステップについても解説します。

【併せて読みたい】Salesforceの 「テスト不足」と「手戻り開発」 の問題をひも解く～なぜProvarが手動から自動化への最適解となるのか？～

Salesforceのテスト自動化が進まない理由

Salesforceにおいて、人手に頼るテストから抜け出すための自動化は、多くの企業が一度は取り組みながらも、継続できずに頓挫したり、満足する成果を得られないケースが非常に多い領域です。その理由は単純な「ツール選定の問題」や「ノウハウ不足」だけではなく、Salesforce特有の構造に起因する、“自動化を阻む壁”が存在しているためです。

1. 「壊れやすさ」の壁 ― メンテナンス地獄に陥る構造

年3回のメジャーアップデートを繰り返すSalesforceにおいて、まず最も大きな障壁となるのが、テストの“壊れやすさ”です。例えばLightning Experienceでは、画面要素のIDが動的に生成されるだけでなく、内部構造が複雑なShadow DOMで構成されているため、一般的なUIベースのテスト自動化が非常に不安定になります。その結果、現場では次のようなことが起きます。

●ボタンの位置や構造が少し変わるだけでテストが失敗する
●Salesforceのアップデート後に大量のテストが一斉に壊れる
●どこが原因で失敗したのか特定に時間がかかる

一つひとつは小さな問題に見えても、テストケースが増えるほど影響は加速度的に拡大します。最終的には、テストを修正する作業そのものが開発工数を圧迫し、「自動化しているのにむしろ遅くなる」という逆転現象が発生します。

ここで多くの現場がたどり着く結論が、「これなら手動で確認した方が早い」という判断です。つまり問題は単なる不安定さではなく、自動化が“持続不可能”になる構造そのものにあります。

【関連記事】Salesforce Lightningテストの課題：Shadow DOMと動的ID、頻繁な構造変化の壁とは（「Shadow DOM」や「動的ID」といったSalesforce特有の構造が、なぜ具体的にテストを壊してしまうのか。その技術的な背景と現場の課題について解説。）

2. 「スキルの壁」 と属人化 ― 作る人と分かる人が分断される

次に大きな障壁となるのが、スキルの問題です。Seleniumなどの汎用的なテストツールを使いこなすには、プログラミングスキル（Java, Pythonなど）が必要です。しかしSalesforceの現場では、本当に業務仕様を理解しているのは、アドミニストレーターや業務部門に近いQA担当者であることも多く、彼らは必ずしもプログラミングに精通しているわけではありません。

一方でエンジニアはコードを書けるものの、業務フローの細かな例外や権限による挙動差、さらには現場特有の運用ルールまでは把握しきれないケースが多いのが実情です。この結果、「仕様が分かる人はテストを書けない」「テストを書ける人は仕様を完全に理解できない」という分断と属人化が生まれます。

3. 「テストデータの壁」 ― 見えないボトルネック

三つ目の壁は、意外に見落とされがちですが最も深刻な問題の一つ、それがテストデータの管理です。Salesforceは単純なデータ構造ではなく、以下のような特徴を持っています。

●複雑なオブジェクト間リレーション
●参照整合性の制約
●権限や共有設定による可視性の違い

そのため、テストを実行するためには単に「レコードを1つ用意する」だけでは足りず、正しい前提条件を満たしたデータセット全体を準備する必要があります。

これに伴い現場では「テスト用データを手動で作成する」「実行後にデータを削除・リセットする」「テスト間でデータが干渉しないように管理する」というような負担が発生します。このプロセスが自動化されていない場合、テスト実行そのものがボトルネックになり、「自動化しているのに実行できない」という状況が発生します。

さらに問題なのは、データ不備によるテスト失敗は、本当に不具合なのか、単なるデータ問題なのかの切り分けが難しい点です。この曖昧さが、テストの信頼性を下げ、結果として自動化そのものへの不信感につながります。

汎用ツールと一線を画す、「Provar」の強みとは

上述の自動化の壁を乗り越え、Salesforceのテスト自動化を目指すうえで、なぜ多くの企業が汎用ツールで挫折し、専用ツールにたどり着くのか。その理由は単純で、「何を基準にテスト対象を特定するか」という設計思想が根本的に異なるためです。

汎用ツールのあくまで画面の“見た目”やDOM構造を外側から捉えるアプローチと、Salesforceの内部構造であるメタデータと連動し、業務オブジェクトや項目単位でテストを定義する違いが、そのまま「壊れやすさ」と「運用コスト」の差として現れます。

メタデータ駆動（Metadata-Driven）の安定性：Provarの最大の特徴は、Salesforceのメタデータ（オブジェクト、項目、権限などの設定情報）を直接参照してテストを構築する点にあります。たとえばもボタンの位置が変わったり、UIがアップデートされたりしても、Provarはメタデータレベルで要素を特定するため、テストが極めて壊れにくいのが特徴です。

ノーコード/ローコードによる「テストの民主化」：Provarは基本的にブラウザ操作をレコーディングするだけでテストを作成できます。特筆すべきは、記録されたステップがプログラミングコードではなく、Salesforceの項目名に基づいた「人間が読める形式」で保存される点です。これにより、エンジニアではない現場の担当者が協働してテストを構築・運用できます。

Shadow DOMへの標準対応：Salesforce独自の技術であるShadow DOMに対しても、Provarは標準で内部構造を認識します。汎用ツールでは、Shadow DOMを扱うために複雑なスクリプトや独自ロジックを実装する必要がありますが、Provarではその必要がなく、標準機能の範囲で安定した操作・検証が可能です。

高いレジリエンス（復元力）とメンテナンスコストの削減：汎用ツールで自動化を運用する際、最大のボトルネックとなるのが「テストスクリプトの破損」です。Salesforceの微細なUI変更によってテストが止まるたび、エンジニアはコードを解析し、新たな要素特定パス（XPath等）を書き直さなければなりません。
Provarは、メタデータとの強固な紐付けにより、画面構造の変化を自動的に吸収する「高いレジリエンス」を備え、メンテナンス工数を削減することで、運用における圧倒的なROI（投資対効果）を実現します。

回帰リスクを防ぐ、「壊れないテスト」の価値：Salesforce開発において最も頻繁に、かつ広範囲に実行されるのが、既存機能への影響を確認する「回帰テスト（リグレッションテスト）」です。年3回のメジャーバージョンアップや頻繁なリリースが行われる環境では、この回帰テストが「常に、正しく、動き続けること」が品質の生命線となります。

汎用ツールではリリースのたびにテストが壊れやすいため、手戻り開発の常態化や回帰テスト自体が形骸化してしまうという課題を内包しています。一方、Provarで構築されたテストは、プラットフォームの進化に左右されない、高レジリエンスによる「壊れない資産」となります。

【併せて読みたい】Provarの優位性：「メタデータ駆動」がSalesforceのテスト自動化を革新する

Provarによる自動化成功への実践的なステップ

手動テストや汎用テストツールの限界をクリアし、自動化を成功させる上で重要なのは、「最初から完璧を目指さないこと」です。ここでは現実的な成功パターンの例として、小さく始めて確実に価値を出しながら、段階的に拡張していくアプローチを解説します。

ステップ1：影響度の高いリグレッション領域から着手

まずはすべてを自動化しようとせず、効果の高い領域に絞ることが重要です。具体的には、ログインや商談作成、見積作成といった「毎回必ず使われ、かつ壊れると業務が止まる機能」から着手します。この段階の目的は、自動化の網羅性ではなく、「自動テストがあることで安心してリリースできる状態」を作ることです。

ステップ2：定期実行による“早期検知の仕組み化”

次に、作成したテストをCI/CDと連携、またはいきなりCI/CDのハードルを乗り越えるリスクは侵さずに、Provar単独で早期検知を実装することで、定期的に自動実行する仕組みを構築します。夜間実行やリリース前実行を組み込むことで、「問題が起きた後に気づく」のではなく、「問題が起きた瞬間に検知する」状態へと変わります。
この段階で初めて、自動化は単なる効率化ではなく、品質保証の仕組みとして機能し始めます。

ステップ3：データ管理の自動化とE2Eテストの確立

自動化が一定レベルに達すると、次に課題となるのがテストデータです。ここでProvarのAPI連携機能などを活用し、「テスト前に必要なデータを自動生成」と「テスト後にクリーンアップ」といったフローを組み込むことで、安定したテスト実行環境を確立します。

同時に、単体的なテストから一歩進み、ユーザー操作 → データ更新 → 自動処理 → 結果確認という一連の業務プロセスを検証するE2Eテストへと拡張していきます。

ステップ4：内製化とスケール（テストが自然に増える状態へ）

最終的には、テストが属人かすることなく、現場のアドミニストレーターやQA担当者が、新機能のリリースに合わせてテストを自ら追加したり、積極的に参画できる体制へと移行します。

この状態になると、テストがボトルネックになることはなくなり、変更と同時にテストが増える（テスト不足や網羅性の解消）、また手戻り開発によるメンテナンスコストも劇的に改善され、品質が継続的に担保されるという好循環が生まれます。

ここまで到達して初めて、自動化は一時的な取り組みではなく、組織の開発プロセスに組み込まれた基盤として機能します。

まとめ：「壊れない」「続けられる」「現場主導」の自動化を実現

このようにProvarの本質的な価値は、ただ単に「Salesforceに対応しているツール」であることではありません。Salesforce特有の構造を前提に、「壊れない」「続けられる」「現場主導（内製）で使える」自動化を実現する設計にあります。

そして導入において重要なのは、
●小さく（重要なところから）始めて確実に価値を出す
●仕組みとして運用に組み込む
●最終的に現場主導で回る状態を作る

という段階的なアプローチであり、それが容易に実装できるSalesforce専用設計ツールの採用です。このプロセスを踏むことで初めて、「自動化しても続かない」という従来の手動テストと自動化の問題を解消し、「テスト不足による手戻り開発」の壁を乗り越え、品質とスピードを両立する開発体制が現実のものになります。

このように、Provarは単なる自動化ツールではありません。少々大げさに言えば、それは開発やQAに携わるエンジニアを「修正作業」から「創造的な仕事」へと解き放つことが役割なのです。

ADOCインターナショナルはこのProvarのPoCや導入支援を通じて、貴社のSalesforce運用を「世界基準の品質とスピード」へと導く伴走者となります。まずは「どこから自動化を進めれば良いか」について、お気軽にご相談ください。お問い合わせはこちらから。

よくある質問（FAQ）

Q1. 手戻りコストが「数倍から10倍以上」になるというのは大げさではありませんか？

A. 決して誇張ではありません。不具合が本番環境に近い段階で見つかるほど、原因を特定するためのデバッグ、修正による二次バグ（デグレード）の確認、汚染された本番データのクレンジング、そして関係各所への説明と再デプロイの調整といった「付随作業」が爆発的に増加します。実装直後なら5分で終わる修正が、数日間の全社的な対応に発展することは珍しくありません。

Q2. なぜSeleniumなどのオープンソースツールではメンテナンスが大変なのですか？

A. Seleniumなどの汎用ツールは、HTMLのタグやIDを「点」で捉えます。しかし、SalesforceのUIは数千行の階層構造を持つ「面」であり、かつアップデートのたびにその構造が変化します。汎用ツールでは、この構造変化を自力でコードに反映し続けなければなりませんが、Provarは「メタデータ」という変わらない定義を捉えているため、構造変化の影響を自動的に吸収できるのです。

Q3. メタデータ駆動型ツールを使うと、テスト作成のスキルは不要になりますか？

A. テストの「ロジック（何を検証すべきか）」を考えるスキルは依然として重要です。しかし、Provarのようなツールを使えば、従来の自動化で必要だった「HTMLの解析」や「複雑なコーディング」という技術的な障壁が取り除かれます。その結果、業務仕様を最もよく知るQA担当者やビジネスアナリストが、自らテストを作成・メンテナンスできるようになるという大きなメリットがあります。

Q4. メジャーバージョンアップの際に、具体的にどのようなテストを自動化すべきですか？

A. まず優先すべきは「回帰テスト（Regression Testing）」です。これは、新機能ではなく「既存の重要機能が、アップデート後も変わらず動くか」を確認するものです。ログインから主要な業務フロー（商談成約、請求発行など）を自動化しておくことで、アップデート初日に「ビジネスが止まっていないこと」を即座に確認できるようになります。

Q5. 自動化を導入する際、最初の一歩として推奨されるアプローチはありますか？

A. 「全てを一度に自動化しようとしないこと」が重要です。まずは、最も頻繁に実行され、かつ手戻りが発生した際の影響が大きい「コアな業務シナリオ」からスモールスタートすることをお勧めします。Provarを回帰テストに適用するなど、まずは1つの重要シナリオを安定して回す実績を作ることで、自動化による投資対効果（ROI）を組織内で証明しやすくなります。

Salesforce Flow × Lightningテストの ボトルネックを解決 手動とスクリプト頼みから抜け出す、「E2E自動化」の実践

【ブログ】手戻り開発を引き起こす、「テスト不足」はなぜ起こる？Salesforceの構造的な課題と対策

手戻り開発を引き起こす、「テスト不足」はなぜ起こる？Salesforceの構造的な課題と対策

Salesforceの開発現場で「テスト不足」が起こる主な原因は、多くの工程が手作業に依存していることと、属人化の問題にあると言われています。また、Salesforceシステムの複雑化や頻繁なアップデートなどの構造的な要因も加わり、このテスト不足が品質の不安や手戻り開発を誘発するなど、生産性を損なうパターンとして常態化している現場が少なくありません。

これは決して現場のエンジニアの怠慢ではなく、Salesforceというプラットフォーム特有の性質と、現代のビジネススピードが引き起こしている「構造的な問題」ともいえます。

本ブログではSalesforce特有の構造を前提に、「壊れない」「続けられる」「現場が使える」自動化を実現するテスト自動化ソリューションの適用について考えます。

Salesforceの開発現場で起きる「テスト不足」とは何か

Salesforce開発における「テスト不足」とは、単純にテストの量（カバレッジ）が少ないことを指すわけではありません。本質的には、“業務として正しく動くことを確認できていない状態”を指します。

一見すると、テストは実施されているように見えるケースも多いのですが、その中身を見ると、いくつかの重要な観点が抜け落ちていることがほとんどです。

①「テストはしているのに不具合が出る」状態の正体

多くの現場では、以下のような流れで開発とテストが進みます。

一見すると問題ないプロセスに見えますが、それでも本番で不具合が発生するのはなぜでしょうか。それは、検証の粒度と範囲が業務の実態に追いついていないためです。
例えば、以下のこうした問題は、部分的なテストでは検知できません。

●単体テストは通っているが、Flowとの連携で不具合が出る
●管理者では問題ないが、一般ユーザーではエラーになる
●個別機能は正常だが、一連の業務フローとしては成立しない

②Salesforce特有の「テスト不足」を生む要因

Salesforceでは特に、次のような要因が重なり、テスト不足が構造的に発生します。

年3回のバージョンアップ：プラットフォーム全体の強制的なアップデートにより、自社の改修とは無関係な場所で、標準機能の仕様変更やUIの構造変化が起き、既存の挙動が変わってしまうリスクを常に抱えています。この変化をリリースのたびに手動で全検証するのは、工数的にほぼ不可能です。

複雑な開発要素：Salesforce開発はコードだけではありません。Apexに加えて、Flow、プロセスビルダー、権限設定、レイアウトなど、多くの要素が組み合わさって動作します。そのため、ある一つの変更が、思わぬ形で別の機能に影響を与えることがあります。

ユーザー権限による挙動の違い：管理者では正常でも、実際の業務ユーザーではエラーになるというケースは非常に多く、これを網羅的にテストするのは容易ではありません。

外部システムとの連携：API連携やバッチ処理などが絡むと、単体のテストだけでは実際の動作を再現できず、本番で初めて問題が顕在化することがあります。

特に頻繁なアップデートは、「自分たちは何も変えていなくても、システムが壊れる可能性がある」という、Salesforce特有の“回帰テストの必要性”をリスクとして抱えることになります。これが、手動テストでは追いつけない大きな「構造的欠陥」となり、自動化の取り組みを促す、強い動機付けにもつながります。

③テスト不足の本質は「E2E視点」と「継続性」

これらを踏まえると、Salesforceのテスト不足の本質は大きく2つに集約できます。一つは、E2E（エンドツーエンド）の視点の欠如です。つまり、個々の機能だけではなく、「業務全体が成立するか」を検証できていない状態です。
もう一つは、テストの継続性の不足です。リリース前に一度テストするだけでは、頻繁な変更やSalesforceのアップデートに対応できません。本来は、変更のたびに繰り返し検証されるべきですが、多くの現場ではそこまで手が回っていません。

テスト不足の背景にある、5つの構造的な課題とは

Salesforceには、その利便性と引き換えに、手動テストや汎用ツールではテスト不足を誘発せざるを得ない構造的な要因がいくつか存在します。本章では、影響分析や環境の差分、メジャーバージョンアップの影響、ブラックボックス化しやすいUI構造など、手戻り開発を引き起こすSalesforceの構造的な「５つの課題」について解説します。

1. 「ローコード」による依存関係のブラックボックス化

Salesforceは、マウス操作の設定だけで高機能なシステムを構築できるのが最大の利点ですが、これがQAにおいては最大の難所となります。

見えない影響範囲：一つのカスタム項目を追加・変更しただけで、それに関連する「フロー」「入力規則」「レポート」「権限セット」「Apexコード」などが連鎖的に影響を受けます。

自動的な影響分析の欠如：標準機能では「この設定を変えたらどこが壊れるか」を完璧にリストアップする術が乏しく、開発者は「影響はないはずだ」という推測に基づいてテスト範囲を決めてしまいます。これが「テスト漏れ」の温床です。

2. 膨大な「組み合わせパターン」による複雑化

Salesforceは、ユーザーの「プロファイル」や「権限セット」によって、画面の見え方や動くロジックが動的に変わります。

テストケースの加速度的な増加：例えば、3つの権限パターンと4つの業務シナリオがあるだけで、12通りのテストが必要です。これを手動で行う場合、時間が足りず「主要な1パターンだけ確認して完了」とする現場が後を絶ちません。

環境差分の罠：開発環境（Sandbox）と本番環境（Production）の間でデータ量や設定が微妙に異なるため、「Sandboxでは動いたが、本番の複雑なデータ構造ではエラーになる」という事態が頻発します。

3. 「リリース頻度」と「手動テスト」のミスマッチ

ビジネス側は「アジャイルに、すぐに機能をリリースしてほしい」と要求します。しかし、テスト手法が「手動」のままであることが、ボトルネックを生んでいます。

回帰テストの断念：新機能をリリースする際、本来は「既存の機能が壊れていないか」を全点検（回帰テストの実行）すべきです。しかし、機能が増えれば増えるほど手動での全点検は不可能になり、「今回直した箇所だけ」の限定的なテストで妥協せざるを得なくなります。

深夜・休日作業による思考停止：Salesforceの現場では、深夜・休日のリリース作業が常態化しやすく、担当者の集中力が低下し、「早く終わらせたい」という心理から確認作業が疎かになります。

4. Salesforce特有の「UI構造」による問題

「手動がダメなら自動化すればいい」と考えるかもしれませんが、一般的な自動テストツール（Seleniumや汎用的なUI操作ツールなど）ではSalesforceの壁を容易には越えられません。

動的な要素（ID）の変動：Salesforceの画面要素は表示のたびに内部的なIDが変わることが多く、汎用ツールでは「ボタンが見つからない」というエラーが頻発します。

DOM構造の複雑性：SalesforceのHTML（DOM）は、何層ものタグが積み重なる非常に深い階層構造をしています。さらに、同じような名前の要素が画面内の別々の場所に存在するため、汎用ツールで特定の入力項目を示すためのXPathなどは極めて長く、複雑なものになります。

Shadow DOMの隠蔽性：Lightning Experienceは、コンポーネントの独立性のために「Shadow DOM」を採用しています。これにより、画面要素がカプセル化（隠蔽）されており、汎用ツールからは内部のボタンや入力項目が「存在しない」かのように見えてしまいます。

メンテナンスの問題：汎用ツールで無理やり自動化しても、Salesforce側のアップデートでテストスクリプトがすぐに壊れます。その修正に時間がかかるため、結局「手動でやったほうが早い」という先祖返りが起きてしまいます。

ここで、動的IDやDOM/Shadow DOMの課題、壊れないテストの必要性は、なぜProvarのようなSalesforce専用ツールが必要なのかを強く訴求するポイントです。

5. 開発者とビジネス側の「品質基準」のズレ

Salesforceはビジネス部門が主導して導入されることも多いため、開発・QA部門との間でITガバナンスが効きにくい側面があります。

「設定」を「開発」と認識しない危惧：「少し設定が変わっただけだから、大がかりなテストは不要だろう」という過信が、ときに重大な不具合を招きます。

ドキュメントの欠如：開発スピードを優先するあまり、仕様書やテストシナリオが整備されず、何が「正解（期待値）」なのかが曖昧なままテストが行われています。

まとめ：「テスト不足」を防ぐ、Salesforce専用設計ツールを採用

このように、Salesforceにおけるテスト不足とは、単なる作業量の問題ではなく、
●業務全体を検証できていない
●権限や連携を含めた現実の利用状況を再現できていない
●継続的にテストを実行できていない
という状態を指します。

一言で言えば、「Salesforceの進化と変更のスピードに対し、人間による『手動テスト』という手法が物理的な限界を迎えているから」です。
この構造的な問題を解決するには、人間の努力に頼るのではなく、Salesforceの内部構造（メタデータ）を理解し、画面変更に左右されない「専用設計の自動テストツール」を導入し、テストを「日常的なルーチン」に組み込むことが唯一の脱出口となります。
また、Salesforceの開発現場において、テスト自動化が「理想」とされながらも「現実として浸透していない」のには、明確な理由があります。そして、その停滞を打ち破る「Provar」がなぜ他のツールと一線を画すのか、その機能的優位性と具体的な導入ステップについてはまた別記事で解説します。

よくある質問（FAQ）

Q1. なぜSalesforceの開発では、手動テストだけで品質を担保することが難しいのですか？

A. Salesforceは、Apexコードだけでなく、Flow、権限設定、カスタム設定など、無数の「メタデータ」が複雑に依存し合っているためです。一箇所の変更が、目に見えない場所で予期せぬ挙動（デグレード）を引き起こすリスクが高く、人間がすべての影響範囲を網羅的に目視確認するには、構造的な限界があるからです。

Q2. リリース直前のバグ発見による「手戻り開発」のコストはどのくらい膨らみますか？

A. 一般的なソフトウェア工学の指標では、本番稼働後やリリース直前に見つかった不具合の修正コストは、実装直後に修正する場合と比較して数倍から10倍以上に跳ね上がると言われています。これには、原因調査だけでなく、関連するテストのやり直しや、他部署との再調整といった「見えない工数」が含まれるためです。

Q3. 年3回のSalesforceメジャーバージョンアップに、自動テストは有効ですか？

A. 非常に有効です。メジャーバージョンアップでは、自社の改修とは無関係に標準機能やUI構造が変化するため、広範囲な「回帰テスト」が必要になります。手動では不可能なこの全件確認を自動化することで、アップデート当日（Day 1）からシステムの安定稼働を保証できるようになります。

Q4. Selenium等の汎用ツールでの自動化が、Salesforceで失敗しやすいのはなぜですか？

A. SalesforceのUI（Lightning Experience）が、「Shadow DOM」や「動的ID」といった特殊な構造を採用しているためです。汎用ツールは画面表面のHTML情報を頼りに動作するため、Salesforce側の微細なアップデートでテストスクリプトが即座に壊れてしまい、メンテナンス工数が手動テストを上回ってしまうことが主な原因です。

Q5. Provarのような「メタデータ駆動型」のテストツールを採用するメリットは何ですか？

A. 最大のメリットは、画面の見た目ではなくSalesforceの内部定義（メタデータ）を直接参照してテストを実行するため、「テストが壊れにくい」点にあります。UIのレイアウト変更や複雑なDOM構造の影響を受けにくいため、スクリプトの保守工数を劇的に削減し、変化の激しいSalesforce環境でも継続的な自動テスト運用が可能になります。

期間限定！無料トライアルキャンペーン実施中

1Day Provar 適用診断サービス

【ホワイトペーパー】「Salesforce×Agentforce」開発の ROIを最大化するために Provarによるテスト自動化戦略と品質保証の革新

「Salesforce×Agentforce」開発の ROIを最大化するために Provarによるテスト自動化戦略と品質保証の革新

Salesforceエコシステムが「Agentforce」と「Data Cloud」を軸とした高度な自動化時代に突入する中、企業が競うべきは機能実装の速さではなく、AIが最新データに基づいてどれだけ正確に顧客を支援できるかという「信頼性の精度」です 。しかし、これまでにないAI特有の非決定的な挙動や複雑なデータ連携は品質保証の大きな障壁となり、手動テストや汎用ツールによる検証はすでに限界を迎えています 。テストが追いつかないためにリリースが遅れ、メンテナンスコストが膨れ上がる「負の螺旋」は、企業の投資対効果（ROI）を著しく低下させる要因です。

本格導入への足踏み（PoC止まり）を解消し、中長期的なビジネス価値を最大化するには、「AIが動くための土台」となる安定した自動テスト環境の構築が欠かせません。Salesforce社自身が自社の回帰テストに採用しているという事実こそが、このプラットフォームに最適化された検証体制の必要性を物語っています。

本資料では、Provar独自の「メタデータ駆動＆AI」アプローチが、Salesforce環境の開発ROIにどのような変革をもたらすかを徹底解説します 。テストメンテナンス工数を最大80%以上削減し 、プロンプトの改善サイクルを5倍に高速化させるなど 、AI時代の競争優位性を確立するための最も賢明な品質保証戦略を提示します。

◆こんな方におすすめです
・AgentforceやData CloudのPoCを終え、安全性や精度の裏付け（証跡）をもって本番環境へ移行させたい方
・ Salesforceのメジャーアップデートや設定変更のたびに、自動テストの修正や修理工数に追われている方
・プロンプトの微調整（イテレーション）とデータ整合性の検証を高速化し、新機能のTime to Marketを最速化したい方
・複雑な多オブジェクト連携テストにおける「泥臭いテストデータの準備や後始末」を自動化・効率化したい方

◆以下の入力フォームをご記入の上、「送信する」ボタンを押下してください。
ご入力いただいたメールアドレス宛に本ホワイトペーパーのダウンロードURLをお知らせいたします。

【新着事例】米政府・公共機関も導入する信頼性。MB&A社がProvarで実現した、不具合50%削減とSalesforceアプリの品質変革

米政府・公共機関も導入する信頼性。MB&A社がProvarで実現した、不具合50%削減とSalesforceアプリの品質変革

企業概要：Millsapps, Ballinger & Associates

---

Millsapps, Ballinger & Associates (MB&A) は、SalesforceのISV（独立系ソフトウェアベンダー）およびISVforce、認定コンサルティングサービスのパートナーであり、Provarの活用によってテスト時間を45%削減しています。MB&Aは、Salesforce AppExchangeでエンタープライズクラスのアプリケーションを提供しているほか、イノベーターによる新製品の立ち上げを支援する経営コンサルティングサービスを展開しています。

なぜProvarは投資に値するのか？それは、トラブル対応に追われることなく、イノベーションに集中できるようになるからです。

Millsapps, Ballinger & Associates 創業者兼CEO Joshua Millsapps氏

MB&A社は、組織が世界最高水準の製品やサービスを形にできるよう支援するという核心的なミッションを掲げ、包括的なサービスを展開しています。同社のソリューションにより、顧客はSalesforce上でデータを収集・評価・活用し、日々のビジネスプロセスを強力に推進することが可能になります。

SalesforceエコシステムのエキスパートであるMB&Aは、同プラットフォームのISV（独立系ソフトウェアベンダー）およびISVforce、さらには認定コンサルティングの各公式資格を有しており、現在はSalesforce AppExchangeにおいて4つの先進的なソリューションを市場に送り出しています。

同社は、退役軍人省、農務省、住宅都市開発省などの多くのアメリカ連邦政府機関をはじめ、ロサンゼルス統一学区、コロンビア特別区などの公的機関、さらには複数の民間企業にいたるまで、政府・公共機関を中心とした幅広い分野にソリューションとサービスを提供しています。

・設立： 2011年
・本社所在地： 米国バージニア州アーリントン
・事業内容： ソフトウェア開発および戦略コンサルティング
・Provarテスト運用数： 約200件
・テスト対象環境： サンドボックス（開発環境）および本番環境

Provarのおかげで、夜も安心して眠れるようになりました。前回のリリースによって何が動かなくなってしまったのか、そんなトラブルの言い訳からお客様との会話を始めるような事態は、絶対に避けたいですからね。

Millsapps, Ballinger & Associates 創業者兼CEO Joshua Millsapps氏

SalesforceとMB&A

---

MB&Aのチームにとって、Salesforceの技術的な機能を深く理解することは極めて重要です。同社は、クライアントがこの重要な投資を最大限に活用できるよう、複雑なSalesforce環境の設計（アーキテクト）、管理、およびガバナンスを支援する幅広い専門サービスを展開しています。

これらのコンサルティングサービスに加え、MB&AはSalesforce AppExchangeを通じて、以下4つの独自アプリケーションをラインナップしています。

・ExAM（Inspection, Audit, Compliance & Data Collection）
組織における検査、評価、および複雑な調査（サーベイ）の実施を支援するアプリです。ExAMを導入することで、現場での検査やデータ収集、コンプライアンス管理にいたるまでのプロセスを、モバイルデバイスを活用して完全にフィールド（現場）へと移行できます。

・ExAM4Assets
新規および既存のビジネスプロセスを支えるために、物理的資産や在庫の効率的な管理を可能にします。

・ExAM Achieve
ExAMの管理パッケージ（Managed Package）を活用し、高度な学習管理システム（LMS / eラーニング）のツールセットを提供します。

・ExAM Connect
REST APIを利用して、複数のSalesforce組織（環境）間、あるいはサードパーティ製の外部データとの間で、スムーズなデータ同期を実現します。

課題：アプリ機能の破損と成長の停滞

---

不良リリースによって社員が常にトラブル対応に追われるようになると、その悪影響は会社全体へと連鎖し、全員が今進めている本来の業務を一時中断せざるを得なくなるのです。

Millsapps, Ballinger & Associates 創業者兼CEO Joshua Millsapps氏

あらゆるソフトウェアがそうであるように、バグや不具合の発生リスクは常に潜んでいます。それらはリリースの遅延を招くだけでなく、「新機能の開発」に向けるべきリソースを「本番環境でのトラブル修正」へと削ぐことになり、結果として顧客の拡大（アップセル）や維持（リテンション）の双方に悪影響を及ぼしかねません。

新規リリース時のエラー混入リスクを抑えるため、MB&A社は当初、アプリの検証を手動テストに頼っていました。製品開発チームが業務負荷を分担し、リリースの直前に各自の時間を削って、手作業で新機能のテストを行っていたのです。

しかし、限られた人数の小規模なチームにとって、タイトなリリーススケジュールを守りながら、必要なすべてのテストシナリオを網羅することは事実上不可能でした。

手動テストの限界、そしてそれが製品開発や企業の成長計画そのものを阻害している現状を重く受け止め、MB&Aの経営陣はテスト自動化の導入を決断したのです。
【関連記事】Salesforceのテストにおける「10の課題」とは（なぜSalesforceのテストは手動だと限界が来るのか？10課題から紐解きます。）

Provarを導入する前は、リリースを迅速に立ち上げる体制に限界を感じていました。お客様はいち早い新機能の提供を望んでおり、私たちを頼りにしてくださっていたからです。

Millsapps, Ballinger & Associates 創業者兼CEO Joshua Millsapps氏

Provarへの移行

---

テスト自動化へのシフトは、私がMB&Aに入社して以来、ずっと掲げていた戦略的目標でした。テスト自動化を『競合他社との差別化要因』として見事に活用している企業を、私はこれまでに何度も目にしてきたからです。自動化を味方につければ、競合を追い抜き、新しいアイデアをどこよりも迅速かつ確実に市場へ投入できるようになります。

Millsapps, Ballinger & Associates ExAM製品の開発責任者 Sean Parker氏

テスト自動化への移行を決断した後、チームは利用可能な選択肢をリサーチし、業界の同業者に意見を求めました。すると、すぐに「ある共通の推奨事項」が浮かび上がってきたのです。それは、「テストのメンテナンス工数を削減するために、Salesforceに特化したテスト自動化ソリューションを選ぶべきだ」ということでした。ある情報源からは、利用していたテスト自動化ベンダーがSalesforce専門ではなかったために、SalesforceのメジャーリリースのたびにQAチームがすべてのテストを手作業で更新せざるを得なくなったという、手痛い失敗談も寄せられました。

この情報を得たMB&A社のチームはProvarの評価（エバリュエーション）を行い、その独自のメリットに確かな手応えを感じました。最も注目すべきは、ProvarがSalesforceの基礎となるデータモデル（メタデータ）と直接連動しているため、過度なメンテナンスを必要としない「壊れないテスト」を構築できる点でした。

また、機能拡張が容易であることも、Provar選定の大きな決め手となりました。プログラミング経験のないテスターでも、導入してすぐに（アウトオブザボックスで）テストの構築を始めることができ、さらに高度なユーザーであれば、必要に応じてJavaScriptを使用してテストを柔軟にカスタマイズすることも可能です。

デモを経て、チームはProvarとの契約を締結しました。さらに、個別最適化されたトレーニングを受け、最初のテストスイート構築を支援してもらえる「ジャンプスタート（Jumpstart）導入サービス」を合わせて利用することで、スムーズな立ち上げ（オンボーディング）をさらに加速させました。
「1Day Provar適用診断サービス」の無償トライアルキャンペーンを、期間限定で実施中

最初から、Provar以外の選択肢は考えられませんでした。私たちが求めていたのはSalesforceに特化したテスト自動化ソリューションでしたが、そもそもそうしたツール自体、市場で簡単に見つかるものではなかったからです。

Millsapps, Ballinger & Associates ExAM製品の開発責任者 Sean Parker氏

MB&A社におけるProvarの活用方法

---

Provarを使えば、開発の極めて早い段階で不具合を検知（早期発見）できます。これは、手動テストだけでは決して不可能な領域です。

Millsapps, Ballinger & Associates 創業者兼CEO Joshua Millsapps氏

現在、中核製品である「ExAM」の検証にProvarを活用しています。新リリースごとに約20件のテストを新規に構築しつつ、既存の200件におよぶテストライブラリの対象範囲を継続的に拡張しています。

手動テストの大部分は排除されましたが、現在も同社全体の検証戦略の一部として戦略的に組み込まれています。まず新機能の初期検証を手動で行い、正常に動作することが確認された段階で、そのテストシナリオを既存のリグレッション（回帰）テストスイートへと組み込んでいく運用を徹底しています。

また、検証業務の責任をテスト専任の担当者（リソース）1名に集約したことで、開発者はトラブル対応から完全に解放され、すべての時間を本来の製品開発に投入できるようになりました。

さらに、エンドツーエンド（E2E）テストにもProvarを活用しています。これにより、ExAMの主要機能である「エンドユーザーへテスト結果の通知メールが正しく配信されるか」といった一連のプロセスも自動で検証しています。
【関連記事】なぜProvarは、Agentforceの「マルチターン×E2Eテスト」を実現できるのか？（ProvarがE2Eテストに強い理由を解説しています。）

開発チームとの連携（クローズドループ）を強固にし、テストの進捗状況を長期的な視点で可視化するため、テスト結果はすべて保存されています。これらのデータは社内システムに集約され、開発チームが必要に応じていつでも確認・対処できるように共有されています。

全体として、Salesforceのリリース検証に要する時間を60%削減し、リリースのサイクルを毎回2週間前倒し（高速化）できるようになりました。さらに、通常発生するカスタマーサポートへの問い合わせ件数が80%以上も減少したのです。これは、私たちのチームにとって計り知れないほど大きな成果です。

Millsapps, Ballinger & Associates クオリティ保証（QA）リーダー Ryan Moore氏

Provar導入による、目覚ましい成果

---

Provarの導入から3年が経過し、MB&A社は「品質の向上」「時間の節約」そして「生産性の劇的な向上」という、目覚ましい成果を達成しました。現在、同社は顧客コミュニティへ提供するソリューションやサービスの品質を一段と高めながら、自社の成長計画を強力に推し進める盤石な体制を整えています。

Provarへ切り替えてから、バグの発生率が明らかに低下しました。手動テストだけに頼っていた頃とは異なり、極めて精度の高い（クリーンな）リリースを実現できています。Salesforce AppExchange向けに高品質な製品を提供する上で、まさに完全なゲームチェンジャー（変革をもたらす存在）となりました。結果として、開発全体における不具合を50%削減し、テストに要する時間を一律で45%短縮することに成功しています。

Millsapps, Ballinger & Associates ExAM製品の開発責任者 Sean Parker氏

MB&A社が達成した主な成功指標の詳細は以下の通りです。

1. 品質の向上

・不具合の大幅な抑制：リリース1回あたり、バグ・欠陥が平均して50%減少
・検証範囲の拡大：ユースケース、検証シナリオ、およびテストカバレッジが70%拡大
・サポートへの好影響：カスタマーサポートへの問い合わせ（チケット）件数が80%減少

製品を急速に進化させようとする場合、手動テストだけではスピードが追いつきません。新しい機能をリリースする際、お客様がすでに依存している既存のシステムを絶対に破壊しないという確信が必要です。Provarは、まさにその確信を与えてくれます。

Millsapps, Ballinger & Associates 創業者兼CEO Joshua Millsapps氏

2. Salesforceリリース関連における時間短縮効果

・定期アップデート検証の効率化：Salesforceのメジャーアップデート（年3回のリリースなど）におけるテスト時間を60%削減
・メンテナンス工数の削減：同アップデートに伴うテストシナリオの修正・メンテナンス時間を60%削減

当社の成長機会の多くは、既存のお客様の中にあります。製品の観点からお客様のニーズに迅速に応える必要があり、Provarはその約束を果たす強力な支えとなっています。

Millsapps, Ballinger & Associates 創業者兼CEO Joshua Millsapps氏

3. 業務全体における時間短縮効果

・全体の工数削減：全社的なテストに要する時間を一律で45%削減
・社内アプリ運用の効率化：社内アプリケーション（自社向けSalesforce組織のカスタマイズ等）の変更に対するテスト時間を40%削減
・社内アプリ向けメンテナンス：同変更に伴うテストのメンテナンス時間を50%削減

4. 生産性の向上

・リソースの最適化（再配分）：QAチームはリリース1回あたり8時間を他のプロジェクトへ投資可能に（テスト専任担当者にとって、1回につき丸1日分の余力が生まれたことを意味します）
・開発サイクルの高速化：リリーススケジュールを1回あたり平均して2週間前倒し（短縮）
・シフトレフトの実現：リグレッション（回帰）テストだけに追われる状態から脱却し、テスト全体の30%を開発ライフサイクルのより早い段階へ移行
・新規テストへの注力：テストメンテナンスが激減した結果、新しいテストの構築に割ける時間が30%増加

Provarは、私たちの開発体制におけるこれまでの常識を一変させる、画期的なソリューションとなりました。

Millsapps, Ballinger & Associates ExAM製品の開発責任者 Sean Parker氏

Provarの迅速な導入と安定した運用なら、ADOCインターナショナルにお任せください。
現状の課題整理や導入に向けた最初の一歩として、まずはお気軽にご相談ください。

Salesforceのバージョンアップに伴う「回帰リスク」の問題

テスト自動化ツール『Provar』、Salesforce Summer ‘26リリースに対応

テスト資産の互換性を保証し、新たにAI自動修復やMCPサーバー機能を提供

Salesforce専用設計のテスト自動化ツール『Provar（プロバー）』の国内総代理店である株式会社アドックインター
ナショナル（本社：東京都立川市、代表取締役CEO：小林 常治／以下ADOC）は、6月5日から段階的に本番
リリースが予定されるSalesforceの最新メジャーバージョンアップであるSalesforce Summer ’26 リリースに同期して
、「Provar Summer ’26 リリース1」の提供を開始します。

本リリースにおいて、Provarは最新のSalesforce Summer ’26リリースの最新バージョンのCPQ（構成・価格・見
積）機能と互換性を保証しており、既存の自動テスト資産（テストケース）を修正や手戻り開発の必要なしに継続し
て利用することができます。

今回、Provar Summer ’26のリリースアップデートには、主に次のポイントが含まれています。
●AIセルフヒーリング機能（Beta版）
●Provar MCP Server（Beta版） ※Anthropic社が提唱するModel Context Protocol：MCP
●Provar Quality Hubの機能アップデート

また、ProvarがMicrosoft Dynamicsアプリケーションへのサポートを拡張したことを発表します。これは、エンタ
ープライズプラットフォーム全体にわたり信頼性が高く、拡張性に優れ、インテリジェントなテスト自動化を提供するという取り組みをさらに拡大・強化するものです。

「Provar Summer ‘26 リリース１」について

Provar Summer ’26リリースでは、Salesforceのメジャーバージョンアップに即日対応し、更新に伴うテスト停止や
スクリプト書き換えなどの回帰リスクを抑えます。マルチエージェントのオーケストレーションやMCP対応など、自動化要求
が高度化するSalesforce環境において、Provarは“先進かつ業務で安心して使える品質保証基盤”を提供します。

【主要なリリースポイント】

①「Salesforce Summer ’26リリース」への互換性対応
Salesforce Summer ‘26 との互換性を提供するとともに、自動化の信頼性、拡張性、パフォーマンスをさらに向上させています。今回のリリースでは、回帰テストスイートが最小限のメンテナンスで完全に動作し続けることを保証し、組織が事業継続性を維持し、最新の Salesforce アップデートを安心して導入できます。

② AIセルフヒーリング（自己修復）機能の実装
Provarによるテスト実行中に、テスト失敗が発生した場合、該当のXpathロケーターを検出し、DOM構造の分析とページ構造・意味情報を参照して、Xpathロケーターを自動修復します。修復されたロケーターは検証されて、テスト実行時へ再利用が可能に。これにより、Provarテストケースの保守性がさらに向上し、自動化運用負荷をさらに低減するとともに、スピーディかつ安定的な回帰テストスイートを実現します。]

③ Provar MCPの実装
Provar MCPは、Provar DX CLIに直接組み込まれたAI支援型の品質レイヤーです。これは、AIアシスタントがユーザーに代わってツールを呼び出すことを可能にするオープンスタンダード「MCP」を実装しており、Claude Desktop、Claude Code、Cursor、Agentforce VibesなどのAIアシスタントから、Provarを呼び出して使用することが可能に。Provar MCPサーバはローカルマシン上で動作し、以下の機能を実現できます。
・作成済みテストケース、およびテスト対象を参照し、カバレッジのギャップを特定
・LWCやVisualforce等で開発されるより高度なカスタム画面に対するテストケースを自動生成
・作成済みテストプラン、テストスイートを操作、修正
・テストケース、スイート、プラン、プロジェクトといったテスト階層を170以上の品質ルールに照らして検証
・チャットセッションから、Provarによる自動テストを実行
・既存のCLIコマンドを使用して、Provar Quality Hubからテスト結果を取得、レポートを作成

④ Provar Quality Hubからの、AIテストケース自動生成機能の強化
従来のメタデータアプローチに加えて、スクリーンショットやビジュアル・コンテキストからもテストケースを自動生成できるようになりました。UI主導のワークフローのサポートが拡大し、手動のテストケース作成作業が軽減され、また生成された結果はCSVファイルとしてエクスポートが可能となり、大量のアセットの管理が容易になります。

⑤ Microsoft Dynamicsの正式サポート
Salesforceと同様にMicrosoft Dynamics 365およびPower Platform向けに特化したテスト自動化機能を提供します。脆弱なロケータに頼るのではなく、コンポーネント、メタデータ、構造、ランタイム動作など、基盤となるアプリケーションフレームワークへアクセスすることで、より堅牢で保守性の高いテスト自動化を実現します。

（※国内のMicrosoft Dynamicsのサポート、セールス・マーケティングの展開等に関しては、後日発表予定）

リリースPDF