Claude で Salesforce Apex・フロー設計の下書きを作る｜人間レビュー必須の前提で

Salesforceのカスタマイズにおいて、標準機能の「フロー（Flow Builder）」と、プログラミングによる「Apex」の使い分けは、システム全体の保守性とパフォーマンスを左右する極めて重要な判断です。近年、Claude 3.5 Sonnetなどの高度なAIモデルの登場により、これら開発要素の「下書き」を生成するハードルは劇的に下がりました。

しかし、Salesforceには「ガバナ制限（Governor Limits）」という特有の制約があり、AIが生成したコードをそのまま本番環境に適用することは推奨されません。本記事では、Claudeを活用してApexクラスやフロー設計のプロトタイプを効率的に作成しつつ、実務者がどこをレビューし、どのようにブラッシュアップすべきかを具体的に解説します。

Salesforce開発におけるClaude活用の意義と限界

ClaudeをSalesforce開発の補助として利用する最大のメリットは、ゼロからコードを書く「最初の一歩」を省略できる点にあります。特に、複雑なSOQLクエリの構築や、テストクラスのボイラープレート（定型文）の生成において、Claudeは非常に高いパフォーマンスを発揮します。

なぜClaudeはApexに強いのか

Claude（特にClaude 3.5 Sonnet / Opus）は、論理的思考能力とコード生成の正確性に定評があります。ApexはJavaに近い構文を持つオブジェクト指向言語であり、Claudeの学習データセットに含まれる膨大なJavaおよびApexの公開リポジトリを基に、Salesforceのベストプラクティスに近いコードを提示することが可能です。

【大前提】AIは「下書き」担当。人間による「最終レビュー」が必要な理由

AIは「文脈的に正しいと思われる回答」を生成しますが、Salesforce組織固有のメタデータ、既存のトリガーフレームワーク、あるいは現在進行中のリリースによる仕様変更までは把握できません。以下の点は、必ず人間が判断する必要があります。

• ガバナ制限の遵守: ループ内でSOQL（クエリ）やDML（挿入・更新）を実行していないか。
• 既存実装との競合: 同じオブジェクトに複数のトリガーが乱立し、実行順序に問題が出ないか。
• 業務要件の特例: 「この条件の時だけは例外とする」といった、ドキュメント化されていない暗黙のルール。

なお、基幹システムのデータを扱う際は、周辺システムとの連携も視野に入れる必要があります。例えば、バックオフィス全体の効率化については、こちらの記事が参考になります。

SaaSコストとオンプレ負債を断つ。バックオフィス＆インフラの「標的」と現実的剥がし方（事例付）

セキュリティとコンプライアンス：機密情報の入力禁止

Claudeにプロンプトを投げる際、以下の情報は絶対に入力しないでください。

• 実際の顧客名、メールアドレス、電話番号。
• Salesforce組織のIDやパスワード、APIキー。
• 自社のビジネスロジックにおける機密性の高い数式や条件。

オブジェクト名や項目名（API参照名）は、「Custom_Object__c」や「Field_A__c」のように匿名化して伝えるのが実務上の鉄則です。

Claudeに「正しい下書き」を出させるプロンプトエンジニアリング

精度の高いアウトプットを得るためには、Salesforceの文脈を詳細に定義したプロンプトが必要です。

要件定義：オブジェクト構造と期待する動作の言語化

単に「商談が成立したらタスクを作るトリガーを書いて」と頼むのではなく、以下のように条件を分解して伝えます。

プロンプト例：

SalesforceのApexトリガーの下書きを作成してください。

【要件】

– オブジェクト：商談 (Opportunity)

– トリガー条件：フェーズ (StageName) が ‘Closed Won’ に変更された時

– 動作：商談の所有者 (OwnerId) を割り当て先とする「お礼状の送付」という名前のタスクを新規作成する。

– 制約：一括更新 (Bulk) に対応し、ループ内でのDML発行を避けること。

– 構成：Trigger本体と、ロジックを切り出したHandlerクラスの2構成にする。

Apexコード生成：Bulk処理とガバナ制限を意識させる指示

Salesforce開発で最も多い失敗は、1件のレコード更新では動くが、200件の一括更新でガバナ制限エラー（Too many DML statements）が出るコードです。Claudeに対しては必ず「Bulkified code（バルク化されたコード）を生成して」と明示してください。

【実践】Apex開発をClaudeで加速させるステップ

具体的な開発フローを、ステップバイステップで見ていきましょう。

STEP 1：トリガー（Trigger）の枠組み作成

まず、トリガーの入り口を作成します。最新のベストプラクティスでは、トリガー内に直接ロジックを書かず、ハンドラークラスを呼び出す形式が推奨されています。

STEP 2：ハンドラークラスへのロジック切り出し

Claudeに対し、「先ほどのトリガーに対応するハンドラークラスを書いてください。with sharingキーワードを含め、適切なコレクション（ListやMap）を使用してガバナ制限を回避してください」と指示します。

STEP 3：テストクラス（Test Class）の自動生成

Salesforceでは、コードカバー率75%以上がデプロイの条件です。Claudeはテストデータの作成（Test.startTest() / Test.stopTest()）を含むテストコードの生成が得意です。
テストクラスを書かせる際は、「正常系だけでなく、フェーズが戻った場合や、一括で200件更新した場合の異常系・境界値テストも含めてください」と指示しましょう。

データ連携やSFAの全体像を把握した上で実装を行うことは、将来的な技術負債を回避するために不可欠です。

【図解】SFA・CRM・MA・Webの違いを解説。高額ツールに依存しない『データ連携の全体設計図』

フロー（Flow）設計におけるClaudeの活用法

コードを書かない「フロー」であっても、複雑な分岐（Decision）やループ処理の論理設計にはClaudeが役立ちます。

複雑な決定要素（Decision）の条件整理

「AかつB、またはCが特定の値でDが未入力の場合……」といった複雑な条件分岐は、人間が設定するとミスが起きやすいポイントです。Claudeに条件をリストアップさせ、漏れがないか確認させます。

ループ（Loop）処理とコレクション変数の扱い

フローにおいても、ループ内での「レコードを取得（Get Records）」や「レコードを更新（Update Records）」は厳禁です。Claudeにフローの設計案を出させる際は、「コレクション変数に値を格納し、ループの外で一括処理する構成案を提示して」と依頼しましょう。

よくあるエラーと対処法

Salesforce開発におけるLLM活用比較表

現在、開発現場でよく使われる主要なAIツールの特性を比較しました。

人間がレビューすべき「3つの致命的なポイント」

Claudeが出力した「下書き」を検証する際、熟練者が必ずチェックする項目が3つあります。

1. ガバナ制限（100%のバルク対応）

AIは「1件」の処理には強いですが、数百件、数千件のレコードが同時に更新される状況を軽視しがちです。リストに対するNullチェックや、空のリストをDMLに渡さないようなガードレールの有無を確認してください。

2. 共有ルールと権限設定

Apexクラスを with sharing で宣言すべきか、あるいはシステム権限で動作させるために without sharing とすべきかは、ビジネス要件に依存します。AIは安全性に寄せて with sharing を提案することが多いですが、それが意図した動作（例：一般ユーザーでも特定レコードを更新させる）を妨げないか確認が必要です。

3. 既存のカスタマイズとの競合確認

新しいトリガーを追加する場合、そのオブジェクトに既に別のトリガーや自動化（保存前フローなど）が存在しないかを確認してください。処理順序が予期せぬ結果を生む可能性があります。複雑な環境では、既存コードをClaudeに（匿名化した上で）読み込ませ、「この既存クラスに新しいロジックを追加して」と指示する方が安全です。

なお、Salesforceをハブとした外部システム連携（ERPや会計ソフトなど）を設計する場合は、連携の「向き」と「責務」を明確にすることが重要です。特に会計連携などは手作業が残りやすいため、以下のガイドが参考になります。

Salesforceとfreeeを繋いでも「サブスク売上」は自動化できない。前受金管理とバクラクを活用した一括請求アーキテクチャ

まとめ：AIをパートナーに、開発の品質を人間が担保する

Claudeは、SalesforceのApex開発やフロー設計において、非常に強力なアクセラレーター（加速装置）になります。しかし、その出力はあくまで「可能性の一つ」であり、最終的な品質責任は実装者にあります。

「指示（Prompt）→ 生成（Generate）→ レビュー（Human Review）→ 検証（Sandbox Test）」のサイクルを回すことで、安全かつ高速な開発体制を構築しましょう。公式ドキュメント（TrailheadやApex開発者ガイド）を常に横に置き、AIの提案を鵜呑みにしない姿勢こそが、最高品質の実装への近道です。