この記事は Salesforce Advent Calendar 2025 の最終日（12/25）担当分です。

最終日は2本書くというフリが去年あったので、2本書きます。

1年かけてAppExchangeに載せる製品をつくったので、実際の製品やビジネス寄りの話はそちらにするとして、Qiitaはその過程で得られた技術のはなしをします。(来年は真似しないでください)

note版はこちら

この記事で書くこと

この1年間、製品をAppExchangeに出すためにSecurity ReviewやISVforce Guidelineと格闘してきました。レビュー対応は6月頃から取り組み、12月に通過。その過程で学んだことを共有します。

ただし、この記事の本題は「AppExchangeに出す方法」ではありません。

本題は「ISVforce GuideをAIに読ませてコードレビューさせるワークフロー」です。

AppExchangeに出す予定がなくても、Salesforceには公式のセキュリティガイドラインがあります。バイブコーディング時代だからこそ、このガイドラインに沿った開発をしておくと、自分のパッケージを守ることにつながります。

今後、AppExchangeにパッケージを出す予定のあるかたは、コードスキャンで見落とされがちなポイントをAIレビューによって発見しやすくなるので、とてもおすすめです。

なぜ今この話をするのか

2025年、AIによるコード生成が当たり前になりました。GitHub Copilot、Claude Code、Codex、そしてAgentfore Vibes。「動くコード」は一瞬で書ける時代です。

でも、SalesforceのAppExchangeレビューにはSecurity Reviewという関門があります。AppExchangeにパッケージを出すには、Salesforceのセキュリティチームによる審査を通過しなければなりません。

また、ISVforce Guideというガイドがあり、Salesforce Platform上で安全なコードを書くための基準として書かれています。AppExchangeのSecurity Reviewは、この標準を必須として審査されています。

AppExchangeに出す予定がなくても、この標準を満たした方が良い。社内ツールだから大丈夫、ユーザーが限られているから大丈夫ということではなく、きちんとした設計にすることをおすすめします。

ISVforce Guideとは何か

Salesforceは、ISV（Independent Software Vendor）向けに公式のセキュリティガイドラインを出しています。

ISVforce Guide

PDFで200ページを超える大作です。正直、全部読むのは大変。

この中で開発者にとって特に重要なのが 「Prevent Secure Coding Violations」 です。セキュアにコーディングをするときに禁止された事項がまとまっています。

CRUD/FLS enforcement（権限チェック）
Sharing violation（共有ルール違反）
SOQL Injection
Stored & Reflected XSS
Open Redirect
Clickjacking
...など

「自分のコードがこの項目に引っかかっているか」をチェックできれば、Security Reviewの通過率は大幅に上がります。でも200ページのPDFを読みながら自分でチェックするのはこの時代とても大変。

そこで、AIの出番です。

Claude CodeにISV Guideを読ませてコードレビューさせる

やり方はシンプルです。

手順

ISVforce GuideのPDFをダウンロード
Prevent Secure Coding Violations のセクションを抜粋してプロジェクト内に保存
Claude Codeを開く
AIにレビュー作成を依頼する

プロジェクト内にISVforce Guide のPDFがあります。
このガイドラインに基づいて、force-app/main/default/ 配下をセキュリティ観点でレビューして、markdownで出力してください。まだコードの修正はしなくてよいです。徹底的に調査し、わからないことはインターネットで調べ、質問があれば私に質問してください。

`5. レビュー結果をもとに修正依頼する

[markdown形式のレビュー結果ファイル]を読み取ってください。
それぞれの項目についてToDoをつくって修正を行い、sf cliをつかってデプロイしてください。エラーが発生した場合は、自律的に原因を調査して修正し、デプロイが成功するまでやり直してください。

たすけてくれたプロンプト

以下は私がよくつかう指示です。この1年間の頻出語句。たくさん助けてくれました。

まだコードの修正はしなくてよいです

設計だけしたいとき、コードの修正はしてほしくないときに使う。

わからないことはインターネットで調べ、質問があれば私に質問してください

自分（人）が考えていちいち指示するのではなく、AI自身がオーナーシップをもって自分で調べ、質問をしてくれるようになる魔法のプロンプト。

ToDoをつくって修正を行い

Claude CodeのToDoを作って、と依頼することで処理が分割され、ひとつひとつの精度があがります。

sf コマンドをつかってデプロイ

AIはsfdxコマンドを使いたがります。そこで、新しいSalesforce CLIであるsf コマンドを使うことを強制します。組織が接続されている場合は、デプロイまでしてくれます。

エラーが発生した場合は、自律的に原因を調査して修正し、

デプロイ時、エラーが発生することがあります。あきらめることなく、自律的に原因を調査してと応援するためのプロンプトです。

実際に出力されたレビュー結果

最初に製品のコードベースをレビューさせた結果、こんな形式で出力されました。最終的には135のApexクラス/トリガと、55個のLightning Web Componentがあるので、すべてのレビューが完了するのに15分ほどかかりました。

全体サマリー

評価	項目数	割合
✅ Pass（合格）	15項目	75%
⚠️ Review Required	4項目	20%
🔍 Scan Required	1項目	5%

具体的な指摘例

AIは「ここがダメ」だけでなく、ISV Guideのどの記載に基づいているかも示してくれます。

例1：Apex Classes のSharing Rules違反

### 問題クラス: ****.cls

**現状:**
public class **** implements Queueable {
  // with sharing 宣言がない
}

**ISVforce Guide, Page 33-34:**
> "Global/NamespaceAccessibleクラス: with sharingを宣言"
> "コントローラークラス: with sharingまたはwith inherited sharingを宣言"

**推奨修正:**
public with sharing class **** implements Queueable {
  // ...
}

例2：LWC - Clickjacking（position: absolute の使用）

### 問題コンポーネント: ****.css

**問題のコード:**
.slds-dropdown {
  position: absolute;  /* ← これがNG */
  z-index: 9000;
}

**ISVforce Guide - Use CSS Outside Components:**
> "Avoid using absolute/fixed positioning as it may break the layout 
> and allow the component to be unintentionally displayed on top of 
> other components."

**推奨修正:**
- position: relative を使用
- または SLDSユーティリティクラス slds-is-absolute を使用

ISV Guideにはこう書いてあります。

Avoid using absolute/fixed positioning as it may break the layout and allow the component to be unintentionally displayed on top of other components.

position: relative または SLDSのユーティリティクラス slds-is-absolute を使うよう修正しました。意外と、position: absoluteやposition: fixed を無意識に使ってしまっているかたは多いのではないでしょうか。

例3：Apex - 動的フィールド名のFLSチェック漏れ

### 問題クラス: ****.cls

**問題のコード:**
String query = 'SELECT ' + urlField + ' FROM ' + objectName;
// ↑ urlField のFLS権限チェックがない

**ISVforce Guide - Bypass Object-Level and Field-Level Access Settings:**
> "Design your solutions to enforce the org's CRUD and FLS settings 
> on standard and custom objects."

**推奨修正:**
if (!fieldMap.get(urlField.toLowerCase()).getDescribe().isAccessible()) {
  throw new AuraHandledException('フィールドへの読み取り権限がありません');
}

動的にフィールド名を受け取る場合でも、FLSチェックが必要です。

このアプローチの良いところ

200ページのPDFを人間が読まなくていい
プロジェクト固有のコードに対して具体的な指摘が出る
網羅的に、徹底的にチェックしてくれる
修正コードまで提案・その場で修正してくれる

もちろん、AIのレビューが完璧というわけではありません。実際のSecurity Reviewでは、AIが見落としていた箇所を指摘されることもありました。でも、事前チェックとしては十分すぎるほど機能します。

バイブコーディング時代のすべてのひとへ

1. AIで書くのはOK。でも設計と禁止パターンの発見は人の責務。

AIは「動くコード」を書いてくれます。でも、それがセキュリティ基準を満たしているかは別の話。最終的な判断は人間がする必要があります。

2. 思考革命の時代を正しく生きよう。

今回、ISVforce GuideのPrevent Secure Coding Violationsセクションは、理解はしたものの全部読んでいません。自分より頭の良いAIに読ませてコードレビューしてもらいました。
車の登場で自分の足を使わずに移動手段の外部化が可能になったこととおなじように、AIの登場で自分の頭を使わずに思考を外部化が可能になった時代。価値のあることに脳のリソースをつかいましょう。

3. AppExchangeに出す予定がなくても、ガイドラインに沿った開発は自分を守る

CRUD/FLSチェック、Sharing Rules、XSS対策。これらは「AppExchange用の特殊ルール」ではなく、Salesforce開発を安全にするための基本的なガイドラインです。今は社内ツールでも、将来パッケージ化する可能性があるなら、最初からガイドラインに沿っておくことをおすすめします。