Salesforce の開発でAIを使っていて、いちばん多い失敗は実装の誤りではありません。設定で済むものまで、コードで返ってくることです。
「取引先の与信額を超えたら商談を登録できないようにしたい」と頼むと、トリガが返ってきます。入力規則1つで済む話です。動くので、レビューを通れば残ります。そして残ったコードは、以後ずっとテストクラスと保守の対象になります。
この種の失敗は、AIの性能の問題ではありません。何をどちらで作るかを、人が決めずに渡しているから起きます。
線引きを人が決めてから渡す
AIに「作って」と頼めば、コードが返ります。コードを書くのが得意だからです。宣言的な設定で足りるかどうかは、この組織の運用、既存の設定の積み重なり、将来の保守の担い手で決まる話で、依頼文の中には書かれていません。
だから、渡す前に人が判定します。判定は4つの問いで足ります。
| 問い | Yes のとき |
|---|---|
| 標準機能でできるか | 作らない。設定で済ませる |
| 宣言的な機能（入力規則・数式・フロー・レポート・権限）で足りるか | コードを書かない |
| 大量データや複雑な分岐で、制限に当たるか | コードを検討する |
| 動いたことを、テストで繰り返し確かめられるか | コードを任せてよい |
4つ目が決定的です。Salesforce でAIに任せやすいのは、テストで確かめられる領域です。逆に、確かめ方が「画面で操作してみる」しかない領域は、任せたあとの検証が人の目視に戻るので、任せる効果が小さくなります。
任せやすいもの／任せにくいもの
| 任せやすさ | 理由 | |
|---|---|---|
| Apex のロジック（サービスクラス・ハンドラ） | ◎ | テストクラスで確かめられる。誤りが実行時に出る |
| SOQL / SOSL の組み立て | ◎ | 結果を見れば正否が分かる。制限の回避も定石がある |
| テストクラス | ◎ | 数が多く、形が決まっている。最も費用対効果が高い |
| LWC のテンプレートと JavaScript | ○ | 見た目は目視が必要だが、構造は任せられる |
| 既存コードの読み解き・影響範囲の洗い出し | ◎ | 人が読む時間がいちばん掛かる作業 |
| フロー（Flow） | △ | メタデータが XML で、差分が人に読みにくい。壊れたときの原因が追いにくい |
| 権限（プロファイル・権限セット） | △ | 影響範囲が組織全体。誤りが「見えてしまう」事故になる |
| 共有設定（組織の共有設定・ロール階層・共有ルール） | × | 変更の影響が広く、戻すのに時間がかかる。設計判断そのもの |
| 本番への反映 | × | 取り消せない |
「任せにくい」は「AIが間違える」という意味ではありません。 間違えたときに気づきにくい、または戻しにくい、という意味です。判断の軸は難しさではなく、やり直しが効くかです。
手順
① 設定で済むかを先に判定する
前節の4つの問いを通します。ここで「設定で足りる」と分かったものは、そもそもAIに実装を頼みません。頼むとしても、設定の手順を書かせるだけにします。
判定の時点で迷うものは、「両方の案と、それぞれの保守の負担を出して」と頼むのが有効です。案を選ばせず、比較を作らせて、選ぶのは人がやる。この形にすると、コードに寄る傾向を打ち消せます。
② 対象のメタデータを揃えて渡す
Salesforce は、同じ業務でも組織ごとに項目の参照名が違います。渡さないと、一般的な名前のコードが返ります。Account.CreditLimit__c のつもりで Account.Credit_Limit__c と書かれていると、動かないか、もっと悪い場合は別の項目を更新します。
渡すのは次の4つです。
- 対象オブジェクトと項目のAPI 参照名（型・必須・参照先まで）
- 既存の似たクラス1本（命名規約・層の分け方・例外の扱いが、説明より確実に伝わる）
- 関係するトリガやフローの有無（二重に更新が走る事故を防ぐ）
- 想定するデータ量（1件ずつか、一括か）
メタデータを集める作業そのものは、組織から取得すれば済みます。項目定義の一覧やメタデータの取り出しは、Salesforceワークベンチ(workbench)の機能一覧と使い方にまとめた方法で取れます。
③ テストクラスを一緒に書かせる
Salesforce は、本番へ反映するときにテストの網羅率を求められます。つまりテストクラスを書かずに済む選択肢がありません。それなら、実装と同時に書かせます。
このとき条件を2つ付けます。
System.assertで結果を確かめること。 実行が通るだけのテストを書かないこと- 一括処理（200件）の場合も通すこと
1つ目を書かないと、網羅率だけを満たす中身の無いテストが返ります。これはあとで不具合を見逃す原因になるだけでなく、テストがあるという誤った安心を作ります。
2つ目は Salesforce 固有です。1件で動いて200件で落ちるのは、繰り返しの中で検索や更新を呼んでいるときに起きます。テストを200件で通す決まりにしておくと、実装側も自然とまとめた形になります。
④ Org へ入れる前に、差分を見る
できたものを、そのまま組織へ反映しません。見るのは差分です。
- 変更されるファイルの一覧を先に出す（自分が頼んでいないファイルが入っていないか）
- 検証のみの反映（実際には適用しない形）で、テストを通す
- 反映先の組織を毎回確認する。接続先が複数あるとき、取り違えはいつでも起こりうる
最後の1つは手順というより決まりごとです。反映先の確認を省いた回だけ事故が起きます。 確認を人の注意力に任せず、反映の直前に接続先を表示させる形にしておくのが確実です。
任せてはいけないこと
共有・権限の最終判断
誰がどのレコードを見えるか、という設計は、AIに判断させません。影響範囲が組織全体で、しかも誤りの出方が「エラー」ではなく「見えてしまう」「見えない」という形になります。テストでも気づきにくく、気づくのは業務側から指摘されたときです。
案や比較表を作らせるのは有効です。決めるのは人です。
本番への反映
取り消せない操作は任せません。手順を書かせるのはよく、実行は人がやります。
Salesforce の場合、特に注意するのはデータの投入・更新です。コードの反映は戻せますが、上書きされたデータは戻りません。実行前にバックアップを取り、そのバックアップから実際に戻せることまで確かめます。ファイルができたことと、復元できることは別です。
ガバナ制限・API 制限の前提
「1回の処理で何件まで」「1日のAPI呼び出しが何回まで」といった前提は、組織の版と契約で変わります。AIは一般的な数字を書きますが、その組織の実際の上限とは一致しません。制限に関わる設計は、自分の組織の値を確認してから決めます。
うまくいかないときの原因
| 症状 | 原因 | 対処 |
|---|---|---|
| 設定で済むものがコードで返る | 判定をせずに「作って」と頼んでいる | 4つの問いを先に通す。迷うものは比較表を作らせ、選ぶのは自分がやる |
| 存在しない項目名のコードが返る | API 参照名を渡していない | 項目定義を参照名・型つきで渡す |
| 1件では動くが一括で落ちる | 繰り返しの中で検索・更新を呼んでいる | テストを200件で通す決まりにする |
| テストが通るのに不具合が出る | 結果を確かめていないテストを受け取っている | System.assert を必須にする。網羅率だけを条件にしない |
| 既存のトリガと二重に更新される | 既存の自動処理を伝えていない | 対象オブジェクトのトリガ・フローの有無を先に渡す |
| 書き方が案件の規約に合わない | 説明で規約を伝えている | 既存の似たクラス1本を見本として渡す |
まとめ
Salesforce 開発でAIに任せる順番は、次のとおりです。
- 設定で済むかを人が判定する（標準機能・宣言的機能・制限・確かめ方の4問）
- メタデータを揃えて渡す（参照名・既存クラス1本・既存の自動処理・データ量）
- テストクラスを一緒に書かせる（
System.assert必須・200件で通す） - 組織へ入れる前に差分を見る（変更ファイルの一覧・検証のみの反映・接続先の確認）
任せないのは、共有と権限の最終判断／本番への反映／制限の前提の3つです。
AIエディタを使った Salesforce 開発の全体像と用語はAIエディタを使ったVibe CordingでSalesforceの開発を行うに、実際の開発事例はAIエディタを使ったVibe codingの実際の開発事例にまとめています。コード生成そのものの様子はAI（ChatGPT）を使ったSalesforce開発（自動コード生成）が参考になります。
複数の作業を同時に走らせる段階に進むなら、複数の作業を同時に走らせるに事故の防ぎ方を含めてまとめています。
自分の組織の構成に合わせてこの流れを通したい方へは、AI開発トレーニングで1対1の形でお伝えしています。
Salesforce、Apex、SOQL、Lightning Web Components、AppExchange、Trailhead は、Salesforce, Inc. の米国およびその他の国における商標または登録商標です。その他、記載されている会社名・製品名は各社の商標または登録商標です。本記事は Salesforce, Inc. その他いかなる第三者からも、承認、提携、後援を受けたものではありません。
