※本記事は2026年6月23日に米国で公開された Analyze and Consolidate Apex Triggers via Agentforce Vibesの抄訳です。本記事の正式言語は英語であり、その内容および解釈については英語が優先されます。
どのSalesforce組織にも開発の経緯があり、それは、たいてい同じように始まります。問題を解決するためにApexトリガーが作られ、問題が出るたびに別のApexトリガーが作られます。そして時間が経つにつれ、一本化された戦略がないまま、同じオブジェクトに対して違う開発者が作成したいくつものApexトリガーが蓄積されていきます。やがて、実行順序が読めない、ガバナ制限に引っかかる、ロジックが衝突する、再帰処理で問題が起きるといった状況に向き合うはめに陥ります。思い当たるところがありませんか？
当然ながら、管理パッケージのトリガーはブラックボックスです。利用者側では管理できず、手を加えることもできません。しかし、カスタムトリガーなら話は別です。カスタムトリガーは開発者が管理し、方針を決められます。解決策は、トリガーを増やすことではありません。正しく作られた1つのトリガーにまとめることです。
ここで、Agentforce Vibesが、ペアプログラミングのよきパートナーとなります。Agentforce Vibesはトリガーを読み取り、それぞれの処理内容を明確に説明し、潜在的な問題を見つけ出して、本来そうあるべきだった、クリーンでスケーラブルなパターンへ統合できるよう支援します。通常であれば数日はかかる手作業のコードレビューとアーキテクチャーの計画が、わずかな時間で完了するため、チームは優れたソリューションを構築するという重要な仕事に集中できます。
私の組織では、Opportunityオブジェクトに対して複数のトリガーが実行されていました。しかも、それぞれ作成された時期も、担当した開発者も、作られた理由も違っていたのです。この記事では、管理パッケージのトリガーには手を加えず、ばらばらになっていたカスタムトリガーを、1つのクリーンなトリガーに統合するために使ったアプローチを紹介します。
ここで紹介するワークフロー、スキル、プロンプト、手順は、私自身の組織をもとにしたものなので、皆さんの組織では当然違った形になるでしょう。トリガーの数、ロジックの複雑さ、依存関係は、もちろん組織によって異なります。実は、それこそがこのアプローチのポイントです。
コンセプトから実践へ – スキルとワークフロー
このアプローチの長所は、再利用可能なスキル（英語）やワークフロー（英語）として形にできることです。つまりどのオブジェクトでも実行でき、チーム全体で共有し、他のAIエージェントに組み込めるフレームワークです。基本となる考え方は共通ですが、どう実行するかは皆さん次第です。
スキル – 必要なときにすぐ頼れる、コード分析の専門家
スキルは、いつでもすぐ呼び出せる専門家のようなものです。スキルをトリガーに向けて使うと、再帰処理の問題、ループ内SOQL、項目への代入の競合、テストカバレッジの抜けなど、注意すべきポイントを洗い出してくれます。以前ならコードを注意深く読み、何時間もかけて行っていた分析が、今では数分で完了します。
ワークフロー – 大規模に展開できる、安全で反復可能なリファクタリング
ワークフローはその分析を受け取り、構造化された段階的なプロセスに変換します。最初に監査を行い、修正が必要な部分をリファクタリングし、統合済みのトリガー、ハンドラー、テストを適切な順序で生成します。必要な手順を飛ばしたり、準備が整っていないコードをマージしたりすることはありません。混乱した状態から保守しやすい状態へ移行する、シンプルな道筋ができあがります。
ごちゃごちゃした複数のトリガーから、1つのクリーンなトリガーへ
以下に示すのは、1つのオブジェクトに対する複数のApexトリガーを、クリーンで保守しやすい単一のハンドラーにまとめるために私が実装した、汎用的なワークフローです。
| ステップ | 内容 |
| 1. ワークフローの開始 | /trigger-consolidationコマンドを実行して、トリガー統合ワークフローを開始します。 |
| 2. メタデータの取得 | ��リガー統合ワークフローがSalesforce CLIを使用して組織のメタデータを照会し、すべてのトリガーとクラスのソースを取得します。 |
| 3. トリガーの分析 | ワークフローが2つのトリガー分析スキルを使って、コードを15の観点でリスク評価します。 |
| 4. 計画の作成 | ワークフローが監査計画をdocs/trigger-audit-plan.mdに書き込みます。 |
| 5. 計画のレビュー | 人が計画を読み、編集し、調整して承認します。 |
| 6. 計画の実行 | ワークフローが計画を読み取り、トリガー統合を実装するファイルを生成します。 |
| 7. 人によるレビュー | 生成されたファイルを人がレビューし、// CONFLICTコメントと// ASYNC REQUIREDコメントで示された問題を解決します。 |
このワークフローはオブジェクト名をハードコードしていないため、標準オブジェクトにもカスタムオブジェクトにも使用できます。対象のオブジェクトを変えて何度でも実行でき、再設定も不要で、同じ手順で同じ品質の分析結果を得られます。
それでは、ワークフローの各ステップを詳しく見てみましょう。
ステップ0 – プロジェクトの準備
始める前に、いくつか準備しておくものがあります。
このウォークスルーでは、Salesforce Extension Pack（英語）がインストールされたVisual Studio Codeで作業していること、Salesforce CLIで組織への認証が完了していること、Agentforce VibesでSalesforce DX MCP Server（英語）が有効になっていることを前提としています。すでに設定が済んでいる場合は、先に進んでください。未設定の場合は、上記の各リンクから準備できます。
トリガー統合用のスキルとワークフローのベース版をGitHubで公開しています。たたき台として利用してください。フォークして、ご自分の組織のオブジェクトや規約に合わせて調整してください。
それではスキルとワークフローをインストールしましょう。セットアップ手順については、このREADME（英語）を参照してください。.a4drules/ディレクトリをSalesforce DXプロジェクトのルートにコピーする手順が説明されています。
これにより、apex-trigger-risk-scan.md、apex-trigger-consolidation-analysis.md、trigger-consolidation.mdの3つのファイルがプロジェクトにコピーされます。
1your-sfdx-project/
2├─ .a4drules/
3│ ├─ skills/
4│ │ ├─ apex-trigger-risk-scan.md ← 単一のトリガーを分析するスキル
5│ │ └─ apex-trigger-consolidation-analysis.md ← 複数のトリガーを横断して分析するスキル
6│ └─ workflows/
7│ └─ trigger-consolidation.md ← トリガー統合ワークフローインストールはこれだけです。再起動や設定は必要ありません。Agentforce Vibesが新しいスキルとワークフローをすぐに認識します。
ステップ1 – ワークフローの開始
-
- Visual Studio CodeのアクティビティバーでAgentforce Vibesアイコンをクリックし、チャットパネルを開きます。
- 次のコマンドを入力して、トリガー統合ワークフローを開始します。
1/trigger-consolidation - ワークフローが開始すると、処理対象のオブジェクトを尋ねられます。
1どのSalesforceオブジェクトのトリガーを統合しますか？ 2（例：Opportunity, Case, Account, Invoice__c） - 「
Opportunity」などのオブジェクト名を入力し、Enterキーを押します。
ステップ2 – メタデータの取得
ワークフローはSalesforce CLIを使用して組織のメタデータを照会し、Apexトリガーと関連するヘルパークラスを取得します。
チャットパネルに次のような出力が表示され、処理の様子を確認できます。
1Running: sf data query --query "SELECT Name, ... FROM ApexTrigger
2WHERE TableEnumOrId = 'Opportunity' AND Status = 'Active'"
3
4## 取得内容の概要：
5**トリガー（合計9件、うち5件は読み取り可能）：**
61. **OpportunityBefore** (x2) - 本文は非表示（管理パッケージ/組織にインストールされたもの、読み取り不可）
72. **OpportunityAfter** - 本文は非表示（読み取り不可）
83. **OpportunityTrigger** - 本文は非表示（読み取り不可）
94. **OppDeleteTrigger** - before delete — 読み取り可能
105. **OppCreateTrigger** - before insert、after insert — 読み取り可能
116. **OpportunityNotifyTrigger** - after insert、after update — 読み取り可能
127. **OppStageTrigger** - before update — 読み取り可能
138. **OpportunityUpdateTrigger** - before update、after update — 読み取り可能
14依存するクラスにはすべてアクセスできます。OpportunityUtils、OpportunityHelper、NotificationServiceです。この一連のトリガーに対応するテストクラスは存在しません。リスク評価を行うため、apex-trigger-analysisスキルを読み込みます。ステップ3 – トリガーの分析
ソースを取得すると、ワークフローは2つのトリガー分析スキルを読み込み、すべてのトリガーをすべてのリスク観点から評価します。
トリガーごとのスキャン：apex-trigger-risk-scanスキル（7つの観点）
| 観点 | 検出される問題 |
| 実行順序のリスク | トリガーが、別のトリガーの先または後に実行されることを想定している箇所を洗い出します。たとえば、そのような前提を示すコメントや、別のトリガーが先に設定するはずの値に依存する項目参照などです。 |
| 再帰リスク | DML処理があるにもかかわらず、Boolean型の静的変数を使った再帰防止ガードがない場合に検出します。DML処理があるのにガードがない場合はCRITICAL、ガードがないだけの場合はHIGHと判定します。 |
| ガバナ制限に達するリスク | ループ内SOQL（CRITICAL）、ループ内DML（CRITICAL）、トリガーコンテキスト内の同期HTTPコールアウト（HIGH）、LIMITなしの集計クエリー（MEDIUM）をスキャンします。 |
| before/afterコンテキストの境界 | トリガーが起動するコンテキストを整理し、そのコンテキストに適さないロジックを検出します。たとえば、afterコンテキストでの項目への代入（何の通知もなく変更が反映されない）や、beforeコンテキストでのトリガー対象レコードに対するDML（再帰を引き起こす）などです。 |
| バイパスの仕組み | カスタム設定やメタデータチェック、権限にもとづくスキップ、外部から設定されるBoolean型の静的フラグなどのキルスイッチパターンを探し、その有無を記録します。 |
| 静的変数の一覧 | ハンドラー/ヘルパークラスにあるすべての静的変数をリストアップし、統合後に別のトリガーのクラスで使われている同名の変数と衝突する、isRunningやprocessedなどの汎用的な変数名を検出します。 |
複数のトリガーを横断する分析：apex-trigger-consolidation-analysisスキル（8つの観点）
| 観点 | 確認する内容 |
| ロジックの重複 | すべてのトリガーを比較し、複数のトリガーで同じ項目に値が代入されている箇所、同一の検証ロジック、複数のトリガーから呼び出されている同一のヘルパーメソッドにフラグを付けます。 |
| ロジックの競合 | 同じトリガーイベントで実行されるトリガー間の矛盾を検出します。たとえば、同じ項目に相反する値を設定する処理、トリガーが読み取る項目を別のトリガーがnullにする処理、互いに排他的な条件分岐、先行する書き込みに依存する読み取り処理などです。 |
| ヘルパークラスの結合 | ヘルパークラスやユーティリティクラスと、それらに依存するトリガーの関係を整理します。3つ以上のトリガーから使用されているクラスは、変更するとすべての呼び出し元に影響する可能性があるため、統合��のリスクとなります。 |
| テストカバレッジの抜け | トリガーごとに、テストクラスが存在するか、カバレッジが85%未満かどうか、200件以上のレコードを使用する一括処理テストがないかどうかを判定します。 |
| 静的変数名の衝突 | トリガー単位のスキャンで作成された静的変数の一覧を突き合わせ、2つのクラスで同じ静的変数名が使われている場合など、再帰防止の仕組みを損なう名前の衝突を検出します。 |
| バイパスの統合戦略 | バイパスの仕組みを統合できるかを評価します。互換性のあるバイパスは1つにまとめ、統合できないバイパスにはメソッドごとにフラグを設定します。また、バイパスのなかったトリガーが統合後のバイパスを意図せず引き継ぐ場合は、該当するトリガーを検出します。 |
| 自動化による再実行リスク | トランザクションの途中でDML処理を行い、Apexトリガーを再度実行させる可能性があるフロー、プロセスビルダー、ワークフローの項目自動更新を特定します。また、処理を再び起動する可能性がある@future/Queueable/Platform Event呼び出しを検出します。 |
| ガバナ制限の累積使用量 | すべてのトリガーで発生するSOQL、DML、ヒープの消費を集計し、トリガー単体では見えない複合的なリスクを明らかにします。個々のトリガーだけを見れば問題がなくても、合算した推定値がSalesforceのガバナ制限に近づく場合はフラグを付けます。 |
次のような検出結果がリアルタイムでパネルに表示されます。
1スコア 意味
21～3 Low — 最小限の準備で安全に統合可能
34～6 Medium — マージ前にリファクタリングが必要
47～9 High — 早急な対応を推奨
510 Critical — ただちに対応しなければ、本番環境でインシデントが発生する可能性が高い
6全体的なリスクスコア: 7/10ステップ4 – 計画の作成
ここで重要なのは、ワークフローは、この時点ではコードを1行も生成しないという点です。
代わりに詳細な計画ファイルをdocs/trigger-audit-plan.mdに出力し、そこで処理をいったん停止します。
1監査が完了しました。詳細な監査計画をdocs/trigger-audit-plan.mdに書き出しました。
2全体的なリスクスコア: 7/10
3統合コードのひな形を生成する前に、検出結果を確認し、
4必要な箇所を編集してください。
5準備ができたら、YESと入力して続行してください。ここで停止する場合は、NOと入力してください。ステップ5 – 計画のレビュー
Visual Studio Codeで監査計画ファイルを開きます。このファイルには、次の内容が含まれます。
- トリガーの一覧 – 各トリガー、対応するイベント、行数、リスクスコア、主な検出結果
- リスクの一覧 – 各検出結果について、重大度、平易な言葉による説明、推奨事項を記載
- 依存関係グラフ – どのトリガーがどのヘルパークラスを共有しているかを、プレーンテキストの図として表示
- ロジック統合マップ – どのトリガーのどのロジックを統合後の各コンテキストに組み込むかを正確に示し、競合箇所を明示
- ベストプラクティスへの準拠 – 現在のトリガーがApex標準に違反している箇所と、統合後のコードで修正される内容
このファイルは自由に編集できます。指示を書き換え、チーム用のメモを追加し、監査計画からトリガーを外すことができます。編集が完了し、続行する準備ができた段階で、ワークフローはコードを生成する前に、編集後の計画ファイルを読み込みます。計画に記載した内容が、そのまま構築されます。
監査計画の内容に問題がなければ、Agentforce Vibesのチャットパネルに戻り、次のように入力します。
1YESステップ6 – 計画の実行
ワークフローは、（必要に応じて編集された）監査計画を読み取り、統合済みのファイルをSalesforce DXプロジェクト内に作成します。
たとえば、Opportunityトリガーを統合する場合、次のような内容が表示されます。
1✓ force-app/main/default/triggers/OpportunityTrigger.trigger (28行)
2✓ force-app/main/default/classes/OpportunityTriggerHandler.cls (74行)
3✓ force-app/main/default/classes/OpportunityTriggerHelper.cls (32行)
4✓ force-app/main/default/classes/OpportunityTriggerTest.cls (58行)
5Consolidation complete. Search for // CONFLICT and // ASYNC REQUIRED
6comments — these are the only places that need manual review.この例では、次の4つのファイルが生成されます。
OpportunityTrigger.trigger– 元の各トリガーに含まれていたイベントのみを対象とする単一のトリガーです。本体にはビジネスロジックを記述せず、すべての処理をハンドラーに委譲します。OpportunityTriggerHandler.cls– 各トリガーコンテキストに1つずつメソッドが用意され、その先頭には静的Boolean型の再帰防止フラグがあります。また、各メソッドには統合元のトリガーを示す注釈が付けられます。ロジックは、レビュー済みのロジック統合マップに従って、正しい順序でマージされます。OpportunityTriggerHelper.cls– 元のトリガーから完全に移植された、実際のビジネスロジックです。すべてのSOQLは一括処理に対応するようループの外に配置され、複数のトリガーに存在していた重複ロジックは1か所にまとめられます。OpportunityTriggerTest.cls– 単一レコードの挿入、一括挿入（200レコード）、更新、一括更新、削除の各テストメソッドは、それぞれ統合元トリガーまで追跡できます。
ステップ7 – 人によるレビュー
ワークフローが終了したら、最後に手作業で、実行中に残されたコメントをレビューします。対応が必要なコメントには、次の2種類があります。
// CONFLICT– 2つのトリガーが同じ項目に異なる値を設定している箇所です。どちらを採用するかを判断します。// ASYNC REQUIRED– デプロイの前に、同期コールアウトを@futureまたはQueueableを使用した非同期処理へ変更する必要がある箇所です。
これで、複雑に入り組んだトリガーの問題は解消されます。トリガーを最適化した後は、プロンプトを使って古いトリガーを無効化し、テストと検証が完了した段階で、新しい実装を上位環境へ展開できます。
注意点
- このフレームワークを活用する際は、自社の環境に合わせて作り変えてください。このワークフローとスキルは、あくまでも作業の起点となるもので、そのまま使える台本ではありません。組織の複雑さ、命名規則、ビジネスロジックはそれぞれ異なり、ここで生成される内容にも影響するため、採用する前に監査計画を編集してください。
- コードを生成する前に、計画モードに十分な時間をかけてください。
docs/trigger-audit-plan.mdを開き、各フェーズを順に確認し、すでに把握している競合に印を付け、マージの順序をチームの計画に合わせます。事前に時間をかけて検討するほど、出力の質が向上します。 - 生成されたコードは、完成版ではなく1つの提案として扱ってください。デプロイの前に必ず内容を確認し、検証することが大切です。AIの出力は有益な提案にはなりますが、本番環境への投入が保証されたコミットではありません。
- 統合に着手する前に、重大度が「High」の問題を修正してください。監査によって再帰のリスク、ループ内のSOQLやDML、または項目の競合が明らかになった場合は、作業を止めて、まずこうした問題を解決しましょう。問題のあるロジックを1つのトリガーにまとめても、問題は解決しません。後からデバッグしにくくなるだけです。
- すべてをバージョン管理���対象にしてください。トリガー、ハンドラークラス、サービスクラス、監査ファイル、テストクラスなど、すべてです。生成または変更された成果物は、ソース管理に含めてください。
- 本番環境に対していきなり実行せず、必ず最初にSandboxでテストしてください。このワークフローは、現在認証している組織に接続します。そのため、
/trigger-consolidationを実行する前に、sf org listでSandbox組織またはスクラッチ組織がデフォルトに設定されていることを確認してください。テストせずに本番環境でトリガーを統合すると、障害を引き起こしかねません。 - 作業はオブジェクトごとに進めますが、常に組織全体を意識してください。これは、一度で完了する修正ではありません。Opportunityオブジェクトの整理が完了したら、Case、Accountと続き、カスタムオブジェクトへ進んでください。段階的に進めることで、確信をもって次の統合作業に臨めます。
まとめ
トリガーがむやみに増えてしまうというのは、多くの組織で見られるやっかいな問題ですが、正しい方法で取り組めば解決できます。
善は急げ。まず最も単純なトリガーを選んで、このガイドの手順に従って統合してみてください。自信を得たら、トラフィックの多いオブジェクトに取り組むといいでしょう。Agentforce Vibesの分析スキルを実行し、監査キャンバスを使えば、対処すべき内容を正確に確認できます。トリガーもハンドラーも1つにまとめて、想定外の事態をなくしましょう。
関連情報
Agentforce Vibes（リンク先はいずれも英語）
- 開発者向けガイド – Agentforce Vibesの概要
- 開発者向けガイド – Agentforce Vibesクイックスタート
- インストール – Salesforce Extension Pack for Visual Studio Code
- ドキュメント – Agentforce Vibes MCP Server
- 開発者向けガイド – Agentforce Vibesのスキル
- 開発者向けガイド – Agentforce Vibesのワークフロー
Salesforce CLI（リンク先はいずれも英語）
- セットアップガイド – Salesforce CLI
- コマンドリファレンス – SF Project Retrieve
- コマンドリファレンス – SF Data Query
Apexトリガーのベストプラクティス
- 開発者向けガイド – Apexトリガー
- 開発者向けガイド – Apexベストプラクティス
- Trailhead – Apexトリガー入門
メタデータとデプロイ
- 開発者向けガイド – メタデータAPIについて
- リファレンス – Package.xmlマニフェストファイルのサンプル
- Salesforceヘルプ – カスタムメタデータ型
執筆者について
Lakshmi Anusha Myneniは、金融サービス業界で15年の経験を持つSalesforceのプリンシパルテクニカルアーキテクトです。ジャーニーの重要な段階でお客様に寄り添い、筋の通った、技術的にも確かなSalesforceソリューションで、複雑なビジネス課題を解決しています。
