この記事では、speedtest.jspで測定できる全9項目について、推奨値・判断基準・具体的な対策を解説します。

speedtest.jspとは — アクセス方法

speedtest.jspは、Salesforceが標準で提供するクライアントサイドの性能診断ツールです。設定メニューにはリンクがないため「隠れ機能」と呼ばれることもありますが、どのSalesforce組織でも利用できます。

アクセス方法： Salesforceにログインした状態で、URLを以下に書き換えるだけです。

https://[あなたのドメイン].lightning.force.com/speedtest.jsp

ページが開いたら「Test Speed」ボタンをクリックすると、数十秒で全項目の測定が完了します。

端末性能の指標 — Octane Score・Hardware Cores・Frame Rate

1. Octane Score — JavaScript実行性能

Google Octane 2.0 ベンチマークで、ブラウザのJavaScript実行速度を数値化したスコアです。

Lightning Experience（Salesforceの現行UI）はクライアント側のJavaScript処理に大きく依存しているため、この値がページの読み込み速度に直結します。Salesforce公式のTrailheadでも、Octane Scoreがパフォーマンスの最重要指標として紹介されています。

Salesforceは独自のパフォーマンス指標として EPT（Experience Page Time） を採用しており、ページの知覚的な読み込み完了時間を計測しています。Octane Scoreが低い端末では、このEPTが大幅に悪化します。AuraフレームワークからLWC（Lightning Web Components）への移行によりレンダリング効率が2〜60%改善された実績がありますが、それでもクライアント側のJS実行性能が基盤であることに変わりありません。

用語解説： 「ベンチマーク」とは、ハードウェアやソフトウェアの性能を統一基準で測定するテストのことです。Octane 2.0はGoogleが開発したJavaScriptベンチマークで、21種類のテストを実行してスコアを算出します。

補足： Octane 2.0は 2017年4月にGoogleが正式に非推奨（Retired）としています。 廃止の理由は「ブラウザベンダーがスコアを不正に最適化できる問題」と「現代のJavaScript利用パターンを反映していない」こと。後継ベンチマークとしてGoogleは Speedometer を推奨しています。ただし、Salesforceのspeedtest.jspでは現在もOctane Scoreを参考指標として採用しているため、Salesforce環境の診断においては依然として有用な指標です。

Salesforce公式ドキュメントによると、最低要件の環境では推奨スペックと比較してページロード時間が約50%遅くなるとされています。

対策： – ノートPCは電源に接続する（バッテリー駆動だと省電力モードでCPU速度が低下する） – 不要なブラウザ拡張機能を削除する（各拡張機能がJavaScriptリソースを消費する） – 他のアプリケーションを閉じてCPU/メモリリソースを確保する – VDI（仮想デスクトップ基盤）環境では、ユーザー密度の見直しやCPU世代の新しいサーバーへの移行が有効

2. Hardware Cores — CPUコア数

端末のCPUコア数（論理プロセッサ数）を表示します。

用語解説： 「コア」はCPU内部の処理ユニットです。コア数が多いほど同時に処理できるタスクが増えます。「論理プロセッサ」はHyper-Threadingなどの技術で1つの物理コアを2つに見せる仕組みです。8コアと表示されても、物理的には4コア+Hyper-Threadingの場合があります。

VDI環境では共有CPUにより実効コア数が少なくなるため、1セッションあたりの割当vCPU数をモニタリングすることが重要です。

3. Frame Rate — 描画性能

ブラウザのレンダリング性能をfps（frames per second：1秒あたりのフレーム数）で測定します。UIのアニメーション・ドラッグ操作・スクロールの滑らかさに影響します。

用語解説： 「fps」は映像の滑らかさを表す単位です。映画は24fps、一般的なモニターは60fpsで表示しています。Webアプリでは、60fpsを維持できていればユーザーはストレスを感じません。

対策： – ブラウザのGPUアクセラレーションが有効か確認する（Chrome: chrome://gpu にアクセス） – 重いVisualforceページやiframeの埋め込みを減らす – GPUが統合グラフィックス（Intel UHD Graphics等）の場合、ディスクリートGPU搭載機への更新を検討する

用語解説： 「GPUアクセラレーション」とは、通常CPUが行う画面描画処理をGPU（画像処理専用チップ）に委任して高速化する技術です。ブラウザの設定で無効になっていると、フレームレートが大幅に低下します。

ネットワーク性能の指標 — Latency・Download/Upload Speed

4. Latency — ネットワーク遅延

端末からSalesforceサーバーまでの往復遅延時間（RTT：Round Trip Time） です。ボタンクリックから画面が反応するまでの「もたつき」に直結します。

Salesforceの組織（Org）は、AP（アジア太平洋）、NA（北米）、EU（ヨーロッパ）などのインスタンスに紐づく物理データセンターでホストされています。ユーザーがデータセンターに近いほどレイテンシが低くなります。

用語解説： 「インスタンス」とは、Salesforceが世界各地に配置しているサーバー群の識別名です。AP26なら東京リージョン、NA135なら北米リージョンに配置されています。自分のOrgのインスタンスは「設定 > 組織情報」で確認できます。

対策： – VPN経由のアクセスでルーティングが遠回りになっていないか確認する – Salesforce CDNを活用して静的コンテンツの初回ロードを高速化する

用語解説： SalesforceはLightning Componentフレームワークの静的コンテンツ（JavaScript・CSS・画像等）の配信に Akamai CDN を使用しています。CDNにより、静的アセットがユーザーに最も近いエッジサーバーからキャッシュ配信されるため、初回ロードが高速化されます。なお、Experience Cloud（コミュニティサイト）はAkamai、Commerce CloudのLWRサイトはCloudflareと、製品ごとにCDNが使い分けられています。 – ネットワーク管理者に traceroute で経路を解析してもらう – 日本のユーザーが多い場合は、APxx（東京）インスタンスでの運用が理想

5. Download Speed — ダウンロード速度

Salesforceサーバーからのデータ受信速度です。ページの初回読み込み、レポート表示、ファイルダウンロードの体感速度に影響します。

用語解説： 「Mbps（メガビット毎秒）」はデータ転送速度の単位です。1 Mbpsなら1秒間に約125KBのデータを転送できます。5 Mbpsあれば、一般的なSalesforceの画面遷移はストレスなく行えます。

対策： – 社内LANの帯域やプロキシサーバーのボトルネックを確認する – 同一ネットワーク上の他のトラフィック（動画ストリーミング等）による帯域圧迫を排除する – Wi-Fiが不安定な場合は有線接続を試す – プロキシ/ファイアウォールでSalesforce関連ドメインがスロットリング（帯域制限）されていないか確認する

6. Upload Speed — アップロード速度

端末からSalesforceサーバーへのデータ送信速度です。レコード保存、ファイルアップロード、添付ファイル操作の体感速度に影響します。

対策はダウンロード速度と同様のネットワーク最適化が有効です。

サーバー・環境情報 — Your Server・Trust Status・User Agent

7. Your Server / Release — 接続先情報

接続先のSalesforceインスタンス名（例：AP26、NA135）と、適用されているSalesforceリリースバージョン（例：Spring ’26）を表示します。

活用方法： Orgのインスタンスが地理的に遠い場合、Salesforceサポートに相談してインスタンス移行を検討できます。日本のユーザーが大半なのにNAインスタンスに配置されている場合は、APインスタンスへの移行で大幅なレイテンシ改善が期待できます。

8. Trust Status — サービス稼働状況

Salesforce Trustサイトの情報と連携して、接続先インスタンスの稼働状況やメンテナンス情報を表示します。

2026年より My Trust Center が一般提供（GA）となり、各テナント固有のステータス情報がパーソナライズ表示されるようになりました。特定インスタンスや製品を選んでアラートメールを自己登録することも可能です。

活用方法： パフォーマンス低下時に、原因がSalesforce側のインフラ障害なのか自社環境なのかを切り分ける最初の確認ポイントになります。「遅い」と言われたらまずここを確認しましょう。

9. User Agent / WebGL — ブラウザ・GPU情報

ブラウザの種類・バージョン、OS情報、GPUの種類を表示します。

確認ポイント： – Salesforce公式が最もパフォーマンスが高いとするのはGoogle Chrome – GPUが統合グラフィックス（Intel UHD Graphics等）の場合、フレームレートがやや低めになる可能性がある

用語解説： 「WebGL」はブラウザ上で3Dグラフィックスを描画する技術で、GPUの種類と密接に関連します。「統合グラフィックス」はCPUに内蔵されたGPUで、独立GPU（NVIDIA GeForce等）と比べて描画性能が低い傾向があります。

総合推奨スペックまとめ

エンタープライズ環境で特に注意すべき2項目

エンタープライズ環境（特に金融系・官公庁系プロジェクト）では、以下の2項目がボトルネックになりやすいです。

1. VPN経由のレイテンシ セキュリティポリシーでVPN必須の環境では、VPNゲートウェイの物理的な位置によってレイテンシが大幅に増加します。東京→海外VPN→東京インスタンスという経路になると、100ms以下で済むはずの遅延が300ms以上になるケースもあります。

2. VDI環境のOctane Score VDI（仮想デスクトップ基盤）環境では、サーバーのCPUリソースを複数ユーザーで共有するため、Octane Scoreが物理PCの半分以下になることがあります。ユーザー密度（1台のサーバーに何人収容するか）の見直しが有効です。

用語解説： 「VDI（Virtual Desktop Infrastructure）」とは、サーバー上で仮想的なデスクトップ環境を動かし、端末からリモートで接続する仕組みです。セキュリティが強化される一方、CPUやメモリが共有されるため個々のユーザーのパフォーマンスが低下しやすい特徴があります。

Salesforceのパフォーマンス改善でお困りなら

speedtest.jspで問題箇所を特定できても、「VPN経路の最適化をどう進めるか」「VDI環境でのチューニングをどこから始めるか」は、環境ごとに事情が異なります。

AI開発実践ラボでは、Salesforce環境のパフォーマンス改善やLightning Experience最適化について、1on1のオンライントレーニングで実践的なノウハウをお伝えしています。

→ AI駆動開発トレーニング — 詳細を見る

まとめ

• speedtest.jsp はSalesforceの標準ツールで、URLを書き換えるだけでアクセスできる
• Octane Score 30,000以上・Latency 150ms以下・Download 3Mbps以上 が推奨ライン
• エンタープライズ環境では VPN経由のレイテンシ と VDI環境のOctane Score が課題になりやすい

パフォーマンス問題の切り分けの第一歩として、ぜひ活用してみてください。

関連リンク: – Salesforce Trailhead — Lightning Experienceパフォーマンス最適化 – Salesforce Trust — サービス稼働状況 – ポートフォリオ — AI汎用入力フォームLWC（LWCによるパフォーマンスを考慮したUI設計の実例）

Vibe Coding（バイブコーディング）とは、従来の詳細な設計書やドキュメントベースの開発から脱却し、開発者の直感と感覚、そしてAIの支援を活用した新しいコーディング手法です。

開発者が「こんな機能を作りたい」という漠然としたアイデアや要求を、AIエディタとの対話を通じて具体的なコードに変換していくため、完璧な設計よりもスピードや柔軟性を重視しており、Salesforceの開発と非常に相性がよい手法となります。

サポーターさん

Vibe Codingを使えば、開発が必要な画面や機能も要件定義の段階でプロトタイプをサクッと作ったり、設計書や開発のコーディングのベースを作成して開発を大幅に効率化できます

従来のSalesforce開発の課題を解消

Salesforceの開発では、Javaなどの言語は経験があるが、ApexやLWCは経験がないというメンバーがアサインされることもありますが、Vibe codingを行うことで、Salesforce独自の言語（Apex/LWC/Visualforce/SOQL/SOSL）への対応やガバナ―制限への対応もAIが自動的に対応してくれるため、キャッチアップも用意で、開発効率も大幅にアップすることができます。

作成されたソースコードについて仕様や解説もしてくれるしコメントを入れることができるので、処理内容を把握して、要件と異なるところもすぐに検索して修正することができます。

AIエディタで実現できること

AIエディタとは？

開発現場で、皆さんが一番利用している生成AIは何でしょうか？実際はコーディング以外の作業もあるのでChatGTPが一番多いかもしれませんね。

コーディングで利用するAI エディター（※1）については、「GitHub Copilot」「Cline」「Cursor」「Windsurf」「Claude Code」 など数多くのエディタが出てきてますが、それぞれ一長一短があるような印象です。

ちなみに私は、現時点ではClaude Codeが一番のお気に入りです。Salesforceの開発IDEとしてはVisual Studio Codeが一般的になってきてますが、Claude Code はVSCodeの拡張プラグインとして利用することができます。

CursorやWindsurfは、VSCode のフォークエディタの位置づけとなります。

※1.AIエディタとは、AI（人工知能）技術を活用して、文章作成やコード編集などの作業を支援するソフトウェアで、コード補完やエラーチェック、自動生成などの機能を持ちます。

Salesforceの開発ではVSCodeを利用することが多いと思うので、現時点では、VSCodeと相性の良いものを選択するのがいいかもしれません。現在はまだ過渡期なので、特定のエディタというよりは、ChatpGPTやCluade.aiを使ってソースコードを生成して利用するなど組み合わせで進めていくのもよいと思います。

エディタについては、開発者ごとにこだわりが強く表れるので、まずは使ってみて気に入ったものを見つけるところから始めてください

主要AIエディタの比較

比較表

項目	GitHub Copilot	Cline	Cursor	Windsurf	Claude Code
料金	$10/月	無料/有料プラン	$20/月	$15/月	無料（プレビュー）
統合性	多エディタ対応	VS Code専用	専用エディタ	専用エディタ	コマンドライン
Salesforce対応
コード補完	非常に高精度	高精度	高精度	高精度	中程度
ファイル操作	限定的	可能	可能	可能	可能
学習コスト	低	中	低	中	高

GitHub Copilot の詳細分析

概要と特徴 GitHub Copilotは、OpenAIのCodexモデルをベースとしたAIコーディング支援ツールです。GitHub上の膨大なオープンソースコードで訓練されており、多言語に対応しています。Salesforce開発においては、ApexやLightning Web Componentsのコード補完に優れた性能を発揮します。

Salesforce開発における強み

• Apex言語の高精度な補完とコード生成
• Lightning Web Componentsのテンプレート自動生成
• SOQLクエリの最適化提案
• テストクラスの自動生成
• Salesforce APIの適切な使用方法提案

Cline の詳細分析

概要と特徴 ClineはVS Code拡張として動作するAIアシスタントで、ファイル操作やターミナル操作が可能な点が特徴です。Salesforce開発においては、Salesforce CLIとの連携や、複数ファイルにまたがる機能実装に威力を発揮します。

Salesforce開発における活用方法

• Salesforce CLIコマンドの自動実行
• プロジェクト構造の自動生成
• 設定ファイルの一括更新
• デプロイメントスクリプトの作成

Cursor の詳細分析

概要と特徴 CursorはAI機能を内蔵した専用エディタで、自然言語でのコード編集指示が可能です。コードベース全体を理解した上での提案を行うため、Salesforceの複雑なオブジェクト関係を理解した開発が可能になります。

Salesforce開発における強み

• 自然言語でのApexクラス生成指示
• オブジェクト関係を考慮したコード提案
• Lightning Web Componentの統合的な開発支援
• プロジェクト全体の一貫性チェック

Windsurf の詳細分析

概要と特徴 WindsurfはCodeium社が開発したAI統合開発環境で、マルチファイル編集とプロジェクト全体の理解に優れています。Salesforce開発においては、複雑なビジネスプロセスの実装や、大規模プロジェクトの管理に特に有効です。

Salesforce開発における特徴

• 複数のApexクラス間の依存関係管理
• Lightning Web Componentとバックエンドの連携設計
• カスタムオブジェクトとコードの同期的開発
• エンタープライズレベルのアーキテクチャ提案

Claude Code の詳細分析

概要と特徴 Claude CodeはAnthropic製のコマンドライン型AIツールで、ターミナルから直接Claude AIを活用できます。Salesforce開発においては、複雑なロジック実装や、アーキテクチャレベルの意思決定に強みを発揮します。

Salesforce開発における活用シーン

• 複雑なビジネスロジックの設計相談
• パフォーマンスチューニング戦略の策定
• セキュリティ要件の実装方法検討
• 大規模データ移行戦略の立案

AIエディタとSalesforce開発の相性

Salesforce特有の開発要素への対応

Apex言語の特殊性 ApexはJavaライクな構文を持ちながら、Salesforceプラットフォーム特有の制約とオブジェクトモデルを持っています。AIエディタは、標準的なJavaの知識を持つ開発者でも、Salesforce特有の書き方（sObjectの操作、SOQL埋め込み、ガバナーリミット対応など）を自然に習得できるよう支援します。

// AIエディタが提案する効率的なApexコード例
public class ContactProcessor {
    public static void updateContactsByAccount(Set<Id> accountIds) {
        // バルク処理を意識したSOQL
        List<Contact> contactsToUpdate = [
                      SELECT Id, AccountId, LastName 
                      FROM Contact 
                      WHERE AccountId IN :accountIds
                  ];
        
        for (Contact contact : contactsToUpdate) {
            // ビジネスロジックをここに記述
            contact.LastModifiedById = UserInfo.getUserId();
        }
        
        // DML操作もバルク処理
        if (!contactsToUpdate.isEmpty()) {
            Database.update(contactsToUpdate, false);
        }
    }
}

Lightning Web Componentsの複雑性 LWCは、HTML、JavaScript、CSSの組み合わせに加え、Salesforce特有のデコレータやワイヤーサービスの理解が必要です。AIエディタは、これらの複雑な連携を自然な形で提案し、モダンなWeb開発の知識をSalesforceプラットフォームに適用できるよう支援します。

SOQL/SOSLの最適化 データクエリの最適化は、Salesforce開発において極めて重要です。AIエディタは、パフォーマンスを考慮したクエリの作成、適切なインデックス活用、クエリプランの最適化などを支援します。

AIエディタによる開発効率化のポイント

コンテキスト理解の向上 最新のAIエディタは、単一ファイルではなくプロジェクト全体のコンテキストを理解し、一貫性のあるコード提案を行います。これにより、Salesforceの複雑なオブジェクト関係やビジネスプロセスを考慮した開発が可能になります。

リアルタイムコード検証 コーディング中にSalesforceのガバナーリミットやセキュリティルールをチェックし、問題のあるコードパターンを事前に警告します。これにより、デバッグ時間の大幅短縮が実現できます。

自動テストケース生成 Salesforceでは高いテストカバレッジが求められますが、AIエディタは機能的なテストケースを自動生成し、テスト品質の向上と開発時間の短縮を両立させます。

コード品質向上への貢献

ベストプラクティスの自動適用 AIエディタは、Salesforce開発のベストプラクティス（トリガーパターン、バルク処理、エラーハンドリングなど）を自動的に適用したコードを提案します。経験の浅い開発者でも、高品質なコードを作成できるようになります。

セキュリティ強化 CRUD権限チェック、SOQL インジェクション対策、適切な共有設定など、セキュリティに関する考慮事項を自動的に組み込んだコードを生成します。

保守性の向上 可読性が高く、拡張しやすいコード構造を提案することで、長期的な保守性を向上させます。また、適切なコメントやドキュメンテーションも自動生成されます。

以下のようなコードとコメントが自動生成されるためSalesforce特有の書き方（sObjectの操作、SOQL埋め込み、ガバナーリミット対応など）を自然に習得することができます。

実践的なVibe Coding手法

AIエディタを活用した具体的な開発フロー

ステップ1: 要件の自然言語化

従来の詳細設計書の代わりに、実現したい機能を自然言語で記述します。この段階では、技術的な詳細よりもビジネス価値に焦点を当てます。

例：「顧客からの問い合わせメールを受信したときに、自動的にケースを作成し、
適切な担当者にアサインし、顧客に自動返信を送信する機能を実装したい」

ステップ2: AIとの対話による要件精緻化

AIエディタとの対話を通じて、曖昧な要件を具体的な技術要件に変換します。

開発者: "メール受信時の自動ケース作成機能を実装したい"
AI: "Email-to-Caseの機能実装ですね。以下の要素が必要です：
1. インバウンドメール処理のApexクラス
2. ケース作成とアサインメントロジック
3. 自動返信のEmailテンプレート
4. エラーハンドリングとログ機能

どの部分から開始しますか？"

ステップ3: 段階的な実装

AIの提案に基づいて、機能を小さな単位に分割して段階的に実装します。

// ステップ3-1: 基本的なメール処理クラス
global class EmailToCaseHandler implements Messaging.InboundEmailHandler {
    global Messaging.InboundEmailResult handleInboundEmail(
        Messaging.InboundEmail email, 
        Messaging.InboundEnvelope envelope
    ) {
        Messaging.InboundEmailResult result = new Messaging.InboundEmailResult();
        
        try {
            Case newCase = createCaseFromEmail(email);
            assignCaseToAgent(newCase);
            sendAutoReply(email.fromAddress, newCase.CaseNumber);
            result.success = true;
        } catch (Exception e) {
            logError(e, email);
            result.success = false;
        }
        
        return result;
    }
}

ステップ4: AIによる継続的改善

実装したコードをAIがレビューし、改善提案を行います。

// AIが提案する改善版
global class EmailToCaseHandler implements Messaging.InboundEmailHandler {
    // 設定値の外部化
    private static final EmailToCaseSettings__c settings = EmailToCaseSettings__c.getInstance();
    
    global Messaging.InboundEmailResult handleInboundEmail(
        Messaging.InboundEmail email, 
        Messaging.InboundEnvelope envelope
    ) {
        Messaging.InboundEmailResult result = new Messaging.InboundEmailResult();
        
        try {
            // バリデーション追加
            if (!isValidEmail(email)) {
                throw new EmailValidationException('Invalid email format');
            }
            
            Case newCase = createCaseFromEmail(email);
            assignCaseToAgent(newCase);
            
            // 非同期での自動返信（ガバナーリミット対策）
            System.enqueueJob(new AutoReplyQueueable(email.fromAddress, newCase.CaseNumber));
            
            result.success = true;
        } catch (Exception e) {
            logError(e, email);
            result.success = false;
            result.message = 'Error processing email: ' + e.getMessage();
        }
        
        return result;
    }
}

プロンプトエンジニアリングのコツ

効果的なプロンプトの構造

1. コンテキストの明確化

"Salesforceの本番環境で使用する、エンタープライズレベルのApexトリガーを作成してください。
ガバナーリミットとセキュリティを考慮した実装が必要です。"

2. 具体的な制約条件の提示

"以下の制約を満たすLightning Web Componentを作成してください：
- 10,000件以上のレコードを効率的に表示
- モバイル対応（レスポンシブデザイン）
- Lightning Design Systemに準拠
- アクセシビリティ要件（WCAG 2.1 AA）を満たす"

3. 期待する出力形式の指定

"以下の形式でコードを生成してください：
1. クラス全体のコード
2. 重要な部分の解説コメント
3. 使用方法の例
4. テストクラスの実装
5. 注意点とベストプラクティス"

反復的改善のためのプロンプト例

"先ほど生成したApexクラスを以下の観点で改善してください：
1. パフォーマンス最適化（特にSOQL実行回数の削減）
2. エラーハンドリングの強化
3. ログ出力の改善
4. コードの可読性向上
5. 単体テストカバレッジの向上"

ベストプラクティス

1. 段階的な開発アプローチ 一度に完璧なコードを求めるのではなく、動作する最小限の実装から始めて、段階的に機能を追加していきます。

2. AIの提案の検証 AIが生成したコードは必ず動作確認を行い、Salesforceの制約やセキュリティ要件を満たしているかチェックします。

3. チーム知識の共有 効果的だったプロンプトや手法は、チーム内で共有し、組織全体のVibe Coding能力を向上させます。

4. 継続的学習 AIエディタの新機能や改善されたプロンプト技術を継続的に学習し、開発手法をアップデートしていきます。

Salesofrceの開発に関するユースケース

参考

AIエディタを使ったVibe codingの実際の開発事例（ユースケース）

AIエディタを使ったVibe codingの実際の開発事例（ユースケース） Li…

続きを読む

まとめ

Vibe Codingがもたらす開発パラダイムの変化

AIエディタを活用したVibe Codingは、Salesforce開発において従来の課題を大幅に解決し、新しい開発体験を提供しています。詳細な設計書に依存した開発から、直感的で創造的な開発へのシフトが可能になり、開発者はより高次元のビジネス価値創出に集中できるようになります。

技術トレンドとの統合

ローコード・ノーコード開発との融合 AIエディタによるVibe Codingは、Salesforceのローコード・ノーコード機能と相互補完的な関係にあります。Flow Builder、Process Builder、Lightning App Builderなどの宣言的開発ツールとAIエディタを組み合わせることで、より柔軟で強力な開発環境が実現できます。

DevOpsとの統合 CI/CDパイプライン、自動テスト、デプロイメント自動化などのDevOpsプラクティスとAIエディタを統合することで、コード生成から本番環境への展開まで一貫した自動化が可能になります。

アジャイル開発手法との親和性 Vibe Codingの反復的で柔軟なアプローチは、アジャイル開発やスクラム手法と非常に相性が良く、スプリント内での迅速な機能開発と改善が可能になります。

続き

本記事では、AIエディタやVibe codingについての用語や概念について説明してきました。AIエディタの種類やそれぞれの特徴についても理解いただけたと思います。

環境構築については、別の記事で紹介したいと思います。

サポーターさん

実際に環境を構築して、AIエディタを利用できるようにしていきましょう。

関連記事

Salesforce導入案件では、要件定義工程で非機能の検討を行う際に、必要となるストレージ容量の算出を行うことが多いと思います。

移行データのボリュームや将来的なデータの増加見込みを考慮して試算を行いますが、毎回エクセルとかで数式を作成して計算している方も多いと思います。

毎回エクセルファイルを作成してというのも面倒なので、簡単にストレージの計算が行えるようにWEBのシミュレーター機能を作成してみました。

サポーターさん

生成AIを使って数分で作成したものですが、意外としっかりしていてファイル出力やクリップボードへのコピーもできます。

今回は、このツールの機能や使い方を簡単に説明していきたいと思います。

ツールはこちらのページにて利用可能となっております。

Salesforceストレージ容量シミュレーターの仕様について

本シミュレーターでは、以下の機能を実装しています。

ツールの利用方法

基本操作

ストレージ容量試算画面を開くと以下の画面が表示されます。デフォルトでは、Accountなどのオブジェクト3つのレコードを初期表示しています。

上部は、試算のための入力フィールドが表示されます。

オブジェクトの追加と削除

オブジェクトを追加ボタン：クリックすると以下のように1行レコードが追加されます。

レコードの一番右の列にある削除ボタンをクリックすると明細レコードが削除されます。

容量計算

オブジェクト名を入力後、以下の項目を入力することで自動的に計算が行われます。

1. ユーザ数：オブジェクトを利用するユーザ数を入力します。
2. 月間レコード登録数/ユーザー：1ユーザ当たりの月間の登録レコード数を入力します。
3. 保存期間（年）：レコードの保存期間を年単位で入力します。
4. 成長率（%/年）：年間当たりのレコードの成長率（増加率）を入力します。

上記の項目はそれぞれ値を変更する度に都度計算が行われ、画面下部に計算結果が表示されます。

シミュレーション結果の表示

ストレージ使用量のサマリーとして以下の内容が自動計算されて表示されます。

①総レコード数：画面上部で入力した各オブジェクト毎のユーザ数ｘ月間レコード登録数ｘ12カ月ｘ保存期間ｘ成長率で計算したレコードの総数を表示

②総ストレージ使用量：①総レコード数ｘ2KBの結果をGB換算して表示

③月間増加量：月あたりのストレージの増加容量を表示

④年間増加量：年間あたりのストレージの増加容量を表示

CSVファイル出力

計算した結果をCSV形式やTSV形式で出力することができます。

CSV形式で出力した場合

CSV形式で出力したファイルをエクセルで開くと以下のように表示されます。

TSVファイルで出力した場合

TSV（タブ区切りファイル）の場合は、以下のように表示されます。

クリップボードへコピーする

クリップボードへコピーするを実行するとクリップボード内に以下の内容がコピーされます。

Salesforce ストレージ容量試算結果
=================================

出力日時: 2025/6/19 23:37:29

【サマリー】
総レコード数: 2,079,899
総ストレージ使用量: 3.967 GB
月間増加量: 0.0751 GB
年間増加量: 0.901 GB

【詳細結果】
Account:
– ユーザー数: 150
– 月間レコード登録数/ユーザー: 200
– 保存期間: 5年
– 成長率: 5%/年
– 累積レコード数: 1,989,227
– ストレージ使用量: 3.794 GB
– 月間増加量: 0.0696 GB
– 構成比: 95.6%

Contact:
– ユーザー数: 100
– 月間レコード登録数/ユーザー: 20
– 保存期間: 3年
– 成長率: 10%/年
– 累積レコード数: 79,440
– ストレージ使用量: 0.152 GB
– 月間増加量: 0.0046 GB
– 構成比: 3.8%

Opportunity:
– ユーザー数: 30
– 月間レコード登録数/ユーザー: 15
– 保存期間: 2年
– 成長率: 8%/年
– 累積レコード数: 11,232
– ストレージ使用量: 0.021 GB
– 月間増加量: 0.0009 GB
– 構成比: 0.5%

まとめ

いかがでしたでしょうか。使い方は非表示シンプルで分かりやすいと思います。

もし、利用にあたって仕様を変更したいなどご要望がございましたらお問い合わせフォームからご連絡ください。

ツールのURLを再度掲載しておきます。

モダンなSalesforce開発において、Lightning Web Component（LWC）は欠かせない技術要素となっています。しかし、多くの開発チームが「どのようなコーディング規約を設ければよいのか」「チーム全体で一貫したコードスタイルを維持するにはどうすればよいのか」といった課題を抱えています。

本記事では、SalesforceのApexコーディング規約の考え方を参考にしながら、LWC開発における実践的なコーディング規約の策定と活用方法について詳しく解説します。品質の高いLWCアプリケーションを開発するために、ぜひ本ガイドを参考にして、あなたのプロジェクトに最適なコーディング規約を構築してください。

本記事では、このテンプレートの特徴と効果的な活用方法について詳しく解説します。

なぜコーディング規約が重要なのか

1. フロントエンド開発の複雑性への対応

LWC開発では、JavaScript、HTML、CSS、そしてSalesforceのメタデータが複雑に絡み合います。統一されたコーディング規約がないと、以下のような問題が発生します：

• コンポーネント間でのスタイリングの不整合
• JavaScript のパフォーマンスの劣化
• コンポーネントの再利用性の低下
• デバッグの困難さ

2. Salesforceプラットフォーム特有の制約

LWC開発では、一般的なWebフロントエンド開発とは異なる独特の制約があります：

• Locker Service によるセキュリティ制約
• Lightning Data Service の効率的な活用
• イベント伝播とコンポーネント間通信
• レスポンシブデザインとLightning Design System（SLDS）の準拠

3. 長期保守性の確保

LWCコンポーネントは、Salesforceの組織内で長期間にわたって使用されます。初期開発から数年後の機能拡張や修正を考慮した、保守しやすいコード構造を保つことが重要です。

1.テーラリングガイド

１．目次サンプル

目次
1 はじめに 
　1.1 本書の目的 7
　1.1.1 利用者 7
1.2 記号 7
　1.2.1 本書で使用する記号についての説明 7
1.3 用語の定義 7
　1.3.1 本書で使用する記号についての説明 7
2 基本方針 8
　2.1 可読性の優先 8
　2.2 保守性の確保 8
　2.3 Lightning固有の考慮事項 8
3 命名規則 8
　3.1 コンポーネント名 8
　3.2 メソッド名 9
　3.3 定数名 10
4 ファイル構造とフォーマット 11
　4.1 ファイル構成 11
　4.2 インデント 11
　4.3 行の長さ 12
5 Javascript設計 13
　5.1 クラス構造の順序 13
　5.2 プロパティ設計 15
6 HTMLテンプレート設計 17
　6.1 テンプレート構造 17
　6.2 イベントハンドリング 18
7 CSSスタイル設計 21
　7.1 SLDS準拠 21
　7.2 CSSカスタムプロパティ 22
8 データアクセスとAPIコール 22
　8.1 Lightning Data Service (LDS) 22
　8.2 Apexメソッド呼び出し 24
9 イベント設計 25
　9.1 カスタムイベント 25
　9.2 プラットフォームイベント 27
10 テスト設計 28
　10.1 Jestテスト 28
　10.2 テストデータファクトリ 31
11 セキュリティとベストプラクティス 33
　11.1 セキュリティ考慮事項 33
　11.2 パフォーマンス最適化 34
12 国際化対応 36
　12.1 カスタムラベル使用 36
　12.2 日付・通貨・数値フォーマット 38
13 エラーハンドリング 40
　13.1 統一的なエラーハンドリング 40
　13.2 バリデーションエラー 43
14 デバッグとトラブルシューティング 45
　14.1 ログ出力 45
　14.2 パフォーマンス監視 46
15 コンポーネント設計パターン 48
　15.1 コンポーネント間通信 48
　15.2 コンポーネント間通信 50
16 メタデータ設計 53
　16.1 コンポーネントメタデータ 53
17 運用保守 55
　17.1 コードレビューチェックリスト 55

２.基本方針（可読性・保守性の重視）

テンプレートでは、「可読性の優先」「保守性の確保」「Salesforce固有の考慮事項」の3つを基本方針として掲げています。これらの方針は、長期的な開発・運用を見据えた重要な指針となります。

可読性の優先

• コードは書く時間よりも読む時間の方が長いことを念頭に置く
• 自己説明的なコードを心がける
• 適切なコメントで意図を明確にする

保守性の確保

• 単一責任原則に従ったコンポーネント設計
• 疎結合と高凝集を実現する構造
• 将来の変更に対応しやすい設計

パフォーマンスの重視

• 不要な再レンダリングを避ける
• 効率的なデータフェッチ
• 適切なライフサイクルフックの活用

３.命名規則の統一

3.1 コンポーネント名
規則:
• kebab-case（小文字、単語間はハイフン）
• 意味のある名前を使用
• 業務領域を表現する接頭辞を付ける

3.2 メソッド名
規則:
• camelCase（最初は小文字、以降の単語は大文字開始）
• 意味のある名前を使用
• Boolean型はis、has、canで開始

3.3 定数名
規則:
• UPPER_SNAKE_CASE（全て大文字、単語間はアンダースコア）
• 意味を明確に表現

4.ファイル構造とフォーマット

4.1 ファイル構成

my-component/

├── my-component.js         // Javascript ロジック

├── my-component.html       // HTML テンプレート

├── my-component.css        // CSS スタイル

├── my-component.js-meta.xml // メタデータ

└── __tests__/

    └── my-component.test.js // テストファイル

4.2 インデント

規則:

• 2スペースインデント（タブ文字は使用しない）
• 一貫したインデントレベルを維持

4.3 行の長さ

規則:

• 1行120文字以内を推奨
• 長い行は適切な位置で改行

5.Javascript設計

クラス構造体の順序、ﾌﾟﾛﾊﾟﾃｨ設計の規則と例を記述しています。

6.HTMLテンプレート設計

テンプレート構造、イベントハンドリングについての規約と例文について解説しています。

7.CSSスタイル設計

CSSスタイル設計のSLDS準拠について、CSSカスタムプロパティの利用方法について解説しています。

8 データアクセスとAPIコール

Lightning Data ServiceやApexメソッドの呼び出しに関する規則について解説しています。

8.1 Lightning Data Service (LDS)
規則:
• 単一レコード操作にはLDSを優先的に使用
• @wireでリアクティブなデータバインディング
• エラーハンドリングを適切に実装

8.2 Apexメソッド呼び出し
規則:
• @wireで自動データバインディング
• imperative callで手動データ取得
• 適切なエラーハンドリング

9.イベント設計

カスタムイベント、プラットフォームイベントについて解説

10.テスト設計

Jestテスト、テストデータファクトリについて解説

11.セキュリティとベストプラクティス

11.1 セキュリティ考慮事項
規則:
• ユーザー入力は常にサニタイズ
• lightning-formatted-textでXSS対策
• CRUD/FLS権限を考慮

その他

テンプレートを参照ください。

テンプレートの効果的な活用方法

1. プロジェクト開始時の規約策定

新しいSalesforceプロジェクトを開始する際、このテンプレートをベースとして、プロジェクト固有の要件に合わせてカスタマイズすることで、短時間で実用的なコーディング規約を策定できます。

活用手順：

1. テンプレートをダウンロードし、開発チーム全体で内容を確認
2. プロジェクトの特性に応じて、必要な項目を追加・修正
3. チーム内での合意形成とドキュメント化

2. 既存プロジェクトの品質改善

既に進行中のプロジェクトでも、段階的にコーディング規約を導入することで品質向上を図ることができます。

段階的導入のアプローチ：

• 第1段階: 新規開発コードから規約適用開始
• 第2段階: 既存コードの修正時に規約に合わせてリファクタリング
• 第3段階: 重要なモジュールから順次全面的な規約適用

3. コードレビューの効率化

テンプレートに含まれるチェックリストを活用することで、コードレビューの観点が明確になり、見落としを防ぐことができます。

4. 新人教育・オンボーディング

新しくチームに参加する開発者に対して、このテンプレートを教育資料として使用することで、Salesforce開発のベストプラクティスを効率的に伝えることができます。

実装時の注意点とコツ

段階的な導入を心がける

すべての規約を一度に導入しようとすると、開発チームに大きな負担をかけてしまいます。重要度の高い項目から順次導入し、チーム全体が慣れてから次の項目に進むことが重要です。

ツールを活用した自動化

可能な限り、IDE（Salesforce CLI、VS Code）の設定やCI/CDパイプラインを活用して、規約チェックを自動化しましょう。手動でのチェックに頼りすぎると、継続が困難になります。

定期的な見直しと改善

プロジェクトの進行に伴い、新たな課題や改善点が見つかることがあります。定期的に規約を見直し、チームの成長とプロジェクトの変化に応じてアップデートしていくことが大切です。

テンプレートに含まれる実践的なコード例

このテンプレートの大きな特徴の一つは、豊富な実装例が含まれていることです。抽象的な説明だけでなく、具体的なコード例を通じて「良い例」と「悪い例」を明示しているため、開発者が実際のコーディング時に迷うことなく適用できます。

SLDSの活用例

(css)
/*  良い例 - SLDS準拠 */
.account-container {
  padding: var(--lwc-spacing-medium);
}

.header {
  margin-bottom: var(--lwc-spacing-large);
}

.content {
  display: flex;
  flex-direction: column;
  gap: var(--lwc-spacing-medium);
}

.empty-state {
  text-align: center;
  padding: var(--lwc-spacing-x-large);
  color: var(--lwc-color-text-weak);
}

.error-message {
  color: var(--lwc-color-text-error);
  padding: var(--lwc-spacing-small);
  border: 1px solid var(--lwc-color-border-error);
  border-radius: var(--lwc-border-radius-medium);
  background-color: var(--lwc-color-background-error);
}

/* レスポンシブ対応 */
@media (max-width: 768px) {
  .content {
    padding: var(--lwc-spacing-small);
  }
}

継続的な品質向上のために

コーディング規約の導入は、ゴールではなくスタートラインです。継続的に品質を向上させるために、以下の取り組みを推奨します：

定期的なコードレビュー会の実施

チーム全体でコードレビューを行う時間を定期的に設け、規約の適用状況や新たな課題について議論します。

メトリクス測定と改善

テストカバレッジ、複雑度、規約違反数などのメトリクスを測定し、定量的な改善を図ります。

知識共有とベストプラクティスの蓄積

チーム内で発見されたベストプラクティスを規約に反映し、組織の知見として蓄積していきます。

まとめ

今回公開したSalesforce Apexコーディング規約テンプレートは、実際の開発現場での経験を基に作成された実践的なドキュメントです。このテンプレートを活用することで、開発チームは以下のメリットを得ることができます：

• 開発効率の向上: 統一されたコーディングスタイルにより、コードレビューや保守作業が効率化
• 品質の向上: Salesforce特有の制約を考慮したベストプラクティスにより、バグの削減と性能向上を実現
• チーム力の強化: 共通の規約により、チーム内でのコミュニケーションと協力が促進
• スケーラビリティの確保: 将来の機能拡張や保守作業に対応しやすいコード構造の実現

Salesforce開発の品質向上を目指すすべてのチームに、このテンプレートを積極的に活用していただき、より良いシステム開発を実現していただければと思います。

資料のダウンロード

テンプレートのダウンロードは、Creative Content Lab Tokyoの公式サイトから無料で行えます。ぜひ、あなたのプロジェクトでもご活用ください。

資料のダウンロードおよびご利用に関しては、本サイトのコンテンツ利用規約に同意される場合のみ利用可能となります。

一般公開資料

開発コーディング規約のダウンロード

※クリックして資料のダウンロードが開始されるまで少し時間がかかる場合がありますので、そのままお待ちください。

もしダウンロードが開始されない場合、ブラウザでポップアップブロックされている可能性があるのでご確認ください。

最後に

サポーターさん

テンプレートのご利用に関して不明な点があればお問い合わせください。また、テンプレートに対しての要望がありましたらご意見ください。 皆様の役に立つように改善していきたいと思います。

サポーターさん

ブログランキングに参加しましたので、ご支援していただけると幸いです。

にほんブログ村

Salesforce開発において、品質の高いコードを書くことは、システムの保守性、拡張性、そして開発チームの生産性に直結する重要な要素です。

しかし、多くの開発現場では「どのようなコーディング規約を設ければよいのか」「チーム全体で一貫したコードスタイルを維持するにはどうすればよいのか」といった課題を抱えています。

そこで今回、Creative Content Lab Tokyoでは、実際の開発現場で使用できるSalesforce Apexコーディング規約テンプレートを無料公開いたします。

本記事では、このテンプレートの特徴と効果的な活用方法について詳しく解説します。

是非、本テンプレートを利用して各プロジェクトの実態にあった実践的なApexコーディング規約を作成してみてください。

なぜApexコーディング規約が重要なのか

1. チーム開発における統一性の確保

複数の開発者が参加するプロジェクトでは、各々が異なるコーディングスタイルでコードを書いてしまうことがよくあります。

これにより、コードレビューが困難になり、バグの発見が遅れたり、新しいメンバーがコードを理解するのに時間がかかったりします。

統一されたコーディング規約があることで：

• コードの可読性が向上し、誰が書いたコードでも理解しやすくなる
• コードレビューの効率が上がり、品質向上に集中できる
• 新規参画メンバーのオンボーディングが迅速になる

2. Salesforce特有の制約への対応

SalesforceのApex開発では、一般的なプログラミング言語にはない独特の制約があります：

• ガバナ制限（SOQL、DML、CPUタイムなど）
• セキュリティモデル（共有設定、FLS）
• マルチテナント環境特有の考慮事項

これらの制約を理解せずに開発を進めると、本番環境で予期しないエラーが発生する可能性があります。

3. 保守性の確保

Salesforceシステムは長期間にわたって運用されることが多く、初期開発から数年後に機能追加や修正が必要になることが一般的です。この際、コーディング規約に従って書かれたコードは、修正や拡張が容易になります。

1.テーラリングガイド

目次サンプル

1.基本方針（可読性・保守性の重視）

テンプレートでは、「可読性の優先」「保守性の確保」「Salesforce固有の考慮事項」の3つを基本方針として掲げています。これらの方針は、長期的な開発・運用を見据えた重要な指針となります。

2.命名規則の統一

クラス名、メソッド名、変数名、定数名それぞれに対して明確なルールを設定しています。例えば：

クラス名: PascalCaseで名詞または名詞句を使用

• AccountService
• accService

メソッド名: camelCaseで動詞または動詞句で開始

• updateAccountStatus()
• update()

3.コード構造とフォーマット

一貫したインデント（4スペース）、適切な行の長さ（120文字以内）、効果的な空行の使用など、チーム全体で統一すべき基本的なフォーマットルールを定義しています。

4.クラス設計のベストプラクティス

クラス内の要素の配置順序（定数→静的変数→インスタンス変数→コンストラクタ→パブリックメソッド→プライベートメソッド）や、適切なアクセス修飾子の使用方法を明示しています。

5.SOQL/DML操作の最適化

Salesforce開発で最も重要な要素の一つであるデータベース操作について、パフォーマンスとガバナ制限を考慮したベストプラクティスを提供しています：

• バルク処理の実装方法
• 効率的なSOQLクエリの書き方
• Database クラスを使用した部分成功制御

6.包括的なテスト戦略

85%以上のテストカバレッジ達成を目標とし、ポジティブ・ネガティブ両方のテストケースを含む、実践的なテストクラス作成方法を解説しています。

テンプレートの効果的な活用方法

1. プロジェクト開始時の規約策定

新しいSalesforceプロジェクトを開始する際、このテンプレートをベースとして、プロジェクト固有の要件に合わせてカスタマイズすることで、短時間で実用的なコーディング規約を策定できます。

活用手順：

1. テンプレートをダウンロードし、開発チーム全体で内容を確認
2. プロジェクトの特性に応じて、必要な項目を追加・修正
3. チーム内での合意形成とドキュメント化
4. 開発環境への組み込み（IDE設定、CI/CDパイプライン）

2. 既存プロジェクトの品質改善

既に進行中のプロジェクトでも、段階的にコーディング規約を導入することで品質向上を図ることができます。

段階的導入のアプローチ：

• 第1段階: 新規開発コードから規約適用開始
• 第2段階: 既存コードの修正時に規約に合わせてリファクタリング
• 第3段階: 重要なモジュールから順次全面的な規約適用

3. コードレビューの効率化

テンプレートに含まれるチェックリストを活用することで、コードレビューの観点が明確になり、見落としを防ぐことができます。

チェックリストの活用例：

• 基本事項（命名規則、アクセス修飾子、フォーマット）
• 設計・構造（単一責任原則、メソッドサイズ、例外処理）
• Salesforce固有（ガバナ制限、バルク処理、セキュリティ）
• パフォーマンス（SOQLクエリ最適化、DML最適化）

4. 新人教育・オンボーディング

新しくチームに参加する開発者に対して、このテンプレートを教育資料として使用することで、Salesforce開発のベストプラクティスを効率的に伝えることができます。

実装時の注意点とコツ

段階的な導入を心がける

すべての規約を一度に導入しようとすると、開発チームに大きな負担をかけてしまいます。重要度の高い項目から順次導入し、チーム全体が慣れてから次の項目に進むことが重要です。

ツールを活用した自動化

可能な限り、IDE（Salesforce CLI、VS Code）の設定やCI/CDパイプラインを活用して、規約チェックを自動化しましょう。手動でのチェックに頼りすぎると、継続が困難になります。

定期的な見直しと改善

プロジェクトの進行に伴い、新たな課題や改善点が見つかることがあります。定期的に規約を見直し、チームの成長とプロジェクトの変化に応じてアップデートしていくことが大切です。

テンプレートに含まれる実践的なコード例

このテンプレートの大きな特徴の一つは、豊富な実装例が含まれていることです。抽象的な説明だけでなく、具体的なコード例を通じて「良い例」と「悪い例」を明示しているため、開発者が実際のコーディング時に迷うことなく適用できます。

バルク処理の実装例

//  良い例 - バルク処理対応
public void updateAccountTypes(List<Account> accounts, String newType) {
    List<Account> accountsToUpdate = new List<Account>();
    
    for (Account acc : accounts) {
        if (acc.Type != newType) {
            acc.Type = newType;
            accountsToUpdate.add(acc);
        }
    }
    
    if (!accountsToUpdate.isEmpty()) {
        try {
            Database.update(accountsToUpdate, false);
        } catch (DmlException e) {
            handleDmlException(e);
        }
    }
}

セキュリティを考慮した実装例

//  良い例 - 権限チェック
public void updateAccounts(List<Account> accounts) {
    if (!Schema.SObjectType.Account.isUpdateable()) {
        throw new SecurityException('Insufficient privileges to update Account');
    }
    
    update accounts;
}

継続的な品質向上のために

コーディング規約の導入は、ゴールではなくスタートラインです。継続的に品質を向上させるために、以下の取り組みを推奨します：

定期的なコードレビュー会の実施

チーム全体でコードレビューを行う時間を定期的に設け、規約の適用状況や新たな課題について議論します。

メトリクス測定と改善

テストカバレッジ、複雑度、規約違反数などのメトリクスを測定し、定量的な改善を図ります。

知識共有とベストプラクティスの蓄積

チーム内で発見されたベストプラクティスを規約に反映し、組織の知見として蓄積していきます。

まとめ

今回公開したSalesforce Apexコーディング規約テンプレートは、実際の開発現場での経験を基に作成された実践的なドキュメントです。このテンプレートを活用することで、開発チームは以下のメリットを得ることができます：

• 開発効率の向上: 統一されたコーディングスタイルにより、コードレビューや保守作業が効率化
• 品質の向上: Salesforce特有の制約を考慮したベストプラクティスにより、バグの削減と性能向上を実現
• チーム力の強化: 共通の規約により、チーム内でのコミュニケーションと協力が促進
• スケーラビリティの確保: 将来の機能拡張や保守作業に対応しやすいコード構造の実現

Salesforce開発の品質向上を目指すすべてのチームに、このテンプレートを積極的に活用していただき、より良いシステム開発を実現していただければと思います。

資料のダウンロード

テンプレートのダウンロードは、Creative Content Lab Tokyoの公式サイトから無料で行えます。ぜひ、あなたのプロジェクトでもご活用ください。

資料のダウンロードおよびご利用に関しては、本サイトのコンテンツ利用規約に同意される場合のみ利用可能となります。

一般公開資料

開発コーディング規約のダウンロード

※クリックして資料のダウンロードが開始されるまで少し時間がかかる場合がありますので、そのままお待ちください。

もしダウンロードが開始されない場合、ブラウザでポップアップブロックされている可能性があるのでご確認ください。

最後に

サポーターさん

テンプレートのご利用に関して不明な点があればお問い合わせください。また、テンプレートに対しての要望がありましたらご意見ください。 皆様の役に立つように改善していきたいと思います。

サポーターさん

ブログランキングに参加しましたので、ご支援していただけると幸いです。

にほんブログ村

利用方法

非常にシンプルなツールとなっているため、難しい操作はございませんが、詳しい利用方法については、以下の記事を参考にしてください。

参考

Salesforceのストレージ容量試算機能（シミュレーター）の使い方

はじめに Salesforce導入案件では、要件定義工程で非機能の検討を行う際に…

続きを読む

Salesforce開発の世界では、ガバナ制限を理解することは単なる利点ではなく、必須事項です。

ガバナ制限とは、Salesforceがマルチテナントアーキテクチャの安定性とパフォーマンスを確保するために強制する実行境界です。これらの制限により、単一の組織が共有リソースを独占し、他のユーザーのエクスペリエンスを低下させることを防いでいます。

Salesforce開発者として、開発中にこれらの制限に必ず遭遇することになります。制限に達すると、診断や修正が難しいランタイム例外が発生し、フラストレーションの原因となることがあります。この記事では、Salesforceのガバナ制限について包括的な概要を提供し、それらが何であるか、なぜ存在するのか、そして最も重要なこととして、どのように効果的に対処するかを説明します。

なぜSalesforceにガバナ制限があるのか

Salesforceはマルチテナントアーキテクチャで運用されており、複数の組織が同じインフラストラクチャ、データベース、計算リソースを共有しています。このアーキテクチャには以下のような多くの利点があります：

1. コスト効率: リソースが顧客間で共有されるため、全体のコストが削減されます。
2. 自動アップグレード: すべての顧客が中断なく同時に更新を受け取ります。
3. スケーラビリティ: Salesforceは必要に応じてリソース間で負荷を分散できます。

単一の組織が過剰なリソースを消費することを防ぐため、Salesforceはガバナ制限を実装しました。これらの制限により、リソースの公平な分配とシステムの安定性およびパフォーマンスが維持されます。

ガバナ制限のカテゴリ

ガバナ制限はいくつかのタイプに大きく分類できます：

1. Apex実行制限

これらの制限は、API要求、Visualforceページ、Lightningコンポーネント、またはその他のソースによってトリガーされるかどうかにかかわらず、Apexコードの実行に適用されます。

※ガバナ制限の閾値についてはSalesforceの組織やライセンス数により変わるものがあります。またバージョンアップなどにより変更される場合があるため、最新の公式HPよりご確認ください。

トランザクションごとの実行制限

2. API制限

APIリクエストには独自の制限セットがあります：

• APIリクエスト制限: Salesforceエディションとライセンス数に基づく
• 同時APIリクエスト制限: 長時間実行APIリクエストの最大同時数
• APIバッチサイズ: API操作あたり最大2,000レコード

3. ストレージ制限

• データストレージ: エディションとユーザーライセンスによって異なる（通常、ユーザーあたり10MBから始まる）
• ファイルストレージ: エディションとユーザーライセンスによって異なる（通常、2GBから始まる）
• ビッグオブジェクトストレージ: エディションによって制限され、EnterpriseおよびUnlimitedエディションでは制限が高い

4. VisualforceとLightning制限

• ビューステートサイズ: Visualforceページの最大135KB
• Lightningコンポーネントイベントサイズ: 最大1MB
• Lightningデータサービス制限: ページあたりメモリ内で100,000レコード

トランザクション境界の理解

把握すべき重要な概念は、Salesforceにおける「トランザクション」です。トランザクションは、操作（ボタンのクリックなど）が開始されると始まり、その操作に関連するすべての処理が完了すると終了します。このトランザクション中、すべてのガバナ制限が追跡され、強制されます。

トランザクションには以下のタイプがあります：

1. ユーザーインターフェーストランザクション: UI（ボタンクリック、フォーム送信）を通じて開始
2. APIトランザクション: API呼び出しを通じて開始
3. データベーストリガー: DML操作によって発火
4. 非同期プロセス: バッチApex、スケジュールされたジョブ、またはQueueable Apexなど

各トランザクションタイプには異なるガバナ制限がある場合があります。たとえば、非同期プロセスは通常、同期プロセスよりもCPU時間とヒープサイズの制限が高くなっています。

一般的なガバナ制限例外

コードがガバナ制限を超えると、Salesforceは特定の例外をスローします。遭遇する可能性のある一般的な例外は次のとおりです：

1. System.LimitException: さまざまなガバナ制限違反に対する一般的な例外
2. System.QueryException: SOQLクエリ制限を超えた場合にスロー
3. System.DmlException: DML操作制限を超えた場合にスロー
4. System.CalloutException: コールアウト制限を超えた場合にスロー

ガバナ制限内で作業するための戦略

効率的なSOQLクエリ

SOQL（Salesforce Object Query Language）クエリは、開発者が制限に達する最も一般的な領域の1つです。以下にいくつかのベストプラクティスを紹介します：

1. ループ内でのSOQLを避ける

// 悪い例
for (Account acc : accountList) {
    List<Contact> contacts = [SELECT Id FROM Contact WHERE AccountId = :acc.Id];
    // コンタクトを処理
}

// 良い例
Map<Id, List<Contact>> contactsByAccountId = new Map<Id, List<Contact>>();
for (Contact c : [SELECT Id, AccountId FROM Contact WHERE AccountId IN :accountIds]) {
    if (!contactsByAccountId.containsKey(c.AccountId)) {
        contactsByAccountId.put(c.AccountId, new List<Contact>());
    }
    contactsByAccountId.get(c.AccountId).add(c);
}

2. 選択的クエリを使用する

WHERE句には常に選択的なフィルターを含めてください。選択的でないクエリは、過剰なCPU使用量とタイムアウトにつながる可能性があります。

// 選択的でない（Email__cがインデックス化されていないと仮定）
List<Contact> contacts = [SELECT Id FROM Contact WHERE Email__c = 'test@example.com'];

// 選択的（IdとNameがインデックス化されていると仮定）
List<Contact> contacts = [SELECT Id FROM Contact WHERE Id = '0031t00000ABCDE' OR Name = 'John Doe'];

3. 必要なフィールドのみを取得する

ヒープサイズの使用を最小限に抑えるために、実際に必要なフィールドのみをクエリしてください。

// 不要なフィールドを取得
List<Account> accounts = [SELECT Id, Name, BillingStreet, BillingCity, BillingState, BillingPostalCode, BillingCountry, ShippingStreet, ShippingCity, ShippingState, ShippingPostalCode, ShippingCountry FROM Account];

// より良いアプローチ
List<Account> accounts = [SELECT Id, Name FROM Account];

DML操作の最適化

データベース操作にも厳格な制限があります。最適化方法は以下の通りです：

1. 一括処理

個別にではなく、常にレコードを一括で処理します。

// 非効率 - レコードごとに1つのDMLステートメント
for (Account acc : accountList) {
    update acc;
}

// 効率的 - すべてのレコードに対して1つのDMLステートメント
update accountList;

2. クロスオブジェクトトランザクションにプラットフォームイベントを使用する

複数のオブジェクトにまたがってレコードを更新する必要がある場合は、プラットフォームイベントを使用してトランザクションを分割することを検討してください。

// 1つのトランザクションで複数のオブジェクトを更新する代わりに
public void processAccounts(List<Account> accounts) {
    // アカウントを処理
    update accounts;
    
    List<Contact> contactsToUpdate = new List<Contact>();
    // 関連するコンタクトを取得して更新
    update contactsToUpdate;
    
    List<Opportunity> oppsToUpdate = new List<Opportunity>();
    // 関連する商談を取得して更新
    update oppsToUpdate;
}

// プラットフォームイベントを使用して複数のトランザクションに分割
public void processAccounts(List<Account> accounts) {
    // アカウントを処理
    update accounts;
    
    // コンタクト処理のためのイベントを発行
    AccountProcessedEvent__e event = new AccountProcessedEvent__e(AccountIds__c = JSON.serialize(accountIds));
    EventBus.publish(event);
}

// イベントトリガーハンドラー
public void handleAccountProcessedEvent(List<AccountProcessedEvent__e> events) {
    // コンタクトを処理
    // 商談を処理
}

コールアウトの管理

外部コールアウトは、制限に簡単に達する可能性のある別の領域です：

1. コールアウトを最小限に抑える

可能な場合は、複数のコールアウトを単一のリクエストにまとめます。

2. 非同期コールアウトを使用する

緊急ではないコールアウトには、非同期アプローチを使用します：

@future(callout=true)
public static void makeCalloutAsync(String payload) {
    // HTTPコールアウトを行う
    Http http = new Http();
    HttpRequest request = new HttpRequest();
    // リクエストプロパティを設定
    HttpResponse response = http.send(request);
    // レスポンスを処理
}

3. 複雑なコールアウトシナリオにはQueueable Apexを実装する

public class CalloutQueueable implements Queueable, Database.AllowsCallouts {
    private List<Id> recordIds;
    
    public CalloutQueueable(List<Id> recordIds) {
        this.recordIds = recordIds;
    }
    
    public void execute(QueueableContext context) {
        // レコードのコールアウトを行う
        // バッチサイズまで処理
        
        // 処理するレコードが残っている場合、別のジョブをチェーン
        if (hasMoreRecords) {
            System.enqueueJob(new CalloutQueueable(remainingIds));
        }
    }
}

フローチャート：大量データ処理の意思決定プロセス

ガバナ制限のモニタリングとデバッグ

Limitsメソッドの使用

Apexは、現在の使用状況を制限と照らし合わせて確認できるLimitsクラスを提供しています：

public void monitorLimits() {
    System.debug('SOQLクエリ: ' + Limits.getQueries() + '/' + Limits.getLimitQueries());
    System.debug('DMLステートメント: ' + Limits.getDmlStatements() + '/' + Limits.getLimitDmlStatements());
    System.debug('CPU時間: ' + Limits.getCpuTime() + '/' + Limits.getLimitCpuTime());
    System.debug('ヒープサイズ: ' + Limits.getHeapSize() + '/' + Limits.getLimitHeapSize());
}

デバッグログ

デバッグログを使用して、コードのどの部分が最もリソースを消費しているかを特定します：

1. ユーザーのデバッグログを設定する
2. 問題のある操作を実行する
3. ログを確認して、実行時間やリソース使用量が多い領域を見つける

プロファイリングツール

Salesforceはコードのプロファイリングのためのいくつかのツールを提供しています：

1. Developer Console: 「実行概要」と「タイムライン」を使用してボトルネックを特定
2. Apex Flex Query: 非効率的なSOQLクエリを特定
3. ISV Customer Debugger: ISVが顧客組織でデバッグするためのツール

高度なテクニック

遅延ロード

必要になるまでリソース消費を遅らせるための遅延ロードパターンを実装します：

public class ContactService {
    private Map<Id, List<Contact>> contactsByAccountId;
    
    public List<Contact> getContactsForAccount(Id accountId) {
        if (contactsByAccountId == null) {
            loadContacts();
        }
        return contactsByAccountId.containsKey(accountId) ? contactsByAccountId.get(accountId) : new List<Contact>();
    }
    
    private void loadContacts() {
        contactsByAccountId = new Map<Id, List<Contact>>();
        for (Contact c : [SELECT Id, AccountId FROM Contact WHERE AccountId IN :accountIds]) {
            if (!contactsByAccountId.containsKey(c.AccountId)) {
                contactsByAccountId.put(c.AccountId, new List<Contact>());
            }
            contactsByAccountId.get(c.AccountId).add(c);
        }
    }
}

ステート保持設計パターン

バッチ処理のためのステート保持パターンを実装します：

public class StatefulBatchExample implements Database.Batchable<SObject>, Database.Stateful {
    private Integer recordsProcessed = 0;
    private Set<Id> processedIds = new Set<Id>();
    
    public Database.QueryLocator start(Database.BatchableContext bc) {
        return Database.getQueryLocator('SELECT Id FROM Account');
    }
    
    public void execute(Database.BatchableContext bc, List<SObject> scope) {
        // レコードを処理
        recordsProcessed += scope.size();
        
        for (SObject obj : scope) {
            processedIds.add(obj.Id);
        }
    }
    
    public void finish(Database.BatchableContext bc) {
        System.debug('処理された合計レコード数: ' + recordsProcessed);
        System.debug('処理されたユニークID数: ' + processedIds.size());
    }
}

大規模データセットのチャンキング

大規模データセットの操作では、チャンキングを実装します：

public void processLargeDataSet(List<Account> accounts) {
    Integer chunkSize = 100; // 操作の複雑さに基づいて調整
    
    for (Integer i = 0; i < accounts.size(); i += chunkSize) {
        Integer endIndex = Math.min(i + chunkSize, accounts.size());
        List<Account> chunk = accounts.subList(i, endIndex);
        
        // このチャンクを処理
        processAccountChunk(chunk);
    }
}

ガバナ制限の最近の強化

Salesforceは定期的にガバナ制限を更新し、時には緩和します。最近の強化には以下が含まれます：

1. ヒープサイズの増加: 非同期操作の場合、6MBから12MBへ
2. SOQLループの強化: クエリカーソルの処理の改善
3. CPU制限の緩和: 特定のLightning操作向け
4. トランザクションファイナライザ: Queueableジョブ後の後処理を扱うため

Salesforceのリリースノートで、ガバナ制限の最新の変更に注目してください。

結論

ガバナ制限は、マルチテナント環境での公平なリソース分配を確保するSalesforceプラットフォームの不可欠な部分です。これらは課題を提示することがありますが、これらの制限を理解し、ベストプラクティスを実装することで、プラットフォーム上で効率的でスケーラブルなアプリケーションを構築できます。

Salesforce開発者のための重要なポイント：

1. 制限を理解する: コードに適用される制限を知る。
2. 一括処理を設計する: コードが複数のレコードを処理することを常に想定する。
3. 使用状況を監視する: Limitsクラスを使用して消費量を追跡する。
4. 非同期パターンを実装する: バッチApex、Queueable Apex、プラットフォームイベントを使用して処理を分散する。
5. クエリを最適化する: 選択的なSOQLクエリを作成し、不要なフィールドのクエリを避ける。
6. 最新情報を入手する: リリースノートでガバナ制限の変更を追跡する。

これらのガイドラインに従うことで、Salesforceのガバナ制限内で効果的に作業し、ユーザーに堅牢でパフォーマンスの高いアプリケーションを提供できます。

参考URL

• Salesforce開発者制限および割り当てリファレンス
• Apex開発者ガイド
• Salesforceアーキテクトのアプリケーションパフォーマンスガイド
• Trailhead: ガバナ制限の基本

Apexの処理設計書については、以下の記事よりダウンロードください。

参考

Apexトリガー処理設計書（Excelテンプレート）

Apexトリガーの処理設計書（基本設計書/詳細設計書）として利用できるエクセルの…

続きを読む

Apex Trigger一覧のサンプル

１．表紙（メッセージ定義書）

表紙については、以下の箇所をプロジェクトに合わせて変更してください。

情報種別：社外秘など

情報所有者：基本的にはお客様の会社名となります。

会社名：自社の会社名（正式名称）を記入してください。

タイトル：ドキュメントのタイトルをプロジェクトに合わせて変更

版数、作成日、作成者：※必要に応じて、最終更新日、更新者を入れてください。

２．改訂履歴

版数、変更箇所、変更内容、変更理由、作成日、作成者、更新日、更新者などを記述します。

改訂履歴は、ドキュメントのメンテナンス上必ず設定するようにしましょう。

３．Apexトリガー一覧

【記載内容】

• 機能ID：システム機能一覧より割り当てた機能IDを記入します。
• トリガー名：トリガー名（論理名）を記入します。
• API参照名：トリガーの物理名を記入します。
• トリガー起動オブジェクト：トリガーを実行するオブジェクトを記入します。
• 処理No.：トリガーに複数の機能（処理）が分かれている場合に処理毎にNo.を割り当てます。
• 処理内容：処理の概要を記入します。
• 起動契機：トリガー内の各処理が実行される契機（before  insert / before update / before delete / after insert / after update / after delete / after undelete）を〇-で定義します。
• 備考：メモ欄としてご利用ください

Apexトリガー一覧の（Excel版）のダウンロード

資料のダウンロードおよびご利用に関しては、本サイトのコンテンツ利用規約に同意される場合のみ利用可能となります。

一般公開資料

エクセルのダウンロードはこちら

圧縮ファイル（ZIP形式）でのダウンロードはこちら

以下は、スプレッドシートでの表示となります。

関連記事

他にも要件定義で必要となる以下のようなテンプレートなども用意しているのでぜひご利用ください。

バッチ処理設計書

バッチ処理設計書（Excelテンプレート）

バッチ処理設計書（基本設計書/詳細設計書）として利用できるエクセルの設計書テンプ…

続きを読む

サポーターさん

ブログランキングに参加しましたので、ご支援していただけると幸いです。

にほんブログ村

ジョブスケジュールのサンプル

バッチのジョブスケジュール表

主要項目

• サーバ：バッチを起動するサーバ環境
• 処理ID：バッチの処理ID
• バッチ処理名
• サイクル：日次、週次、月次などの処理サイクル
• タイミング：バッチ処理実行のタイミング
• 前提条件：バッチ実行の前提条件
• 開始時間：バッチ処理開始時間
• 終了時間：バッチ処理終了時間（予定時間）

テーラリングガイド

選択リスト値の定義

本テンプレートでは、バッチの処理サイクルを選択リスト値で設定し、名前の定義をしていますので、適宜変更してご利用ください。

バッチ処理一覧の（Excel版）のダウンロード

資料のダウンロードおよびご利用に関しては、本サイトのコンテンツ利用規約に同意される場合のみ利用可能となります。

一般公開資料

エクセルのダウンロードはこちら

圧縮ファイル（ZIP形式）でのダウンロードはこちら

以下は、スプレッドシートでの表示となります。

関連記事

他にも要件定義で必要となる以下のようなテンプレートなども用意しているのでぜひご利用ください。

バッチ処理設計書

バッチ処理設計書（Excelテンプレート）

バッチ処理設計書（基本設計書/詳細設計書）として利用できるエクセルの設計書テンプ…

続きを読む

サポーターさん

ブログランキングに参加しましたので、ご支援していただけると幸いです。

にほんブログ村

要件定義書（本編）が必要な方は、こちらの記事からダウンロードいただけます。

参考

Salesforceシステム要件定義書（PPTテンプレート）サンプル・利用方法

本記事では、Creative Content Lab Tokyo（クリエイティブ…

続きを読む

1.はじめに

申し送り事項一覧に関しては、前の工程で決まり切らなかった仕様や課題などについて、後工程で検討するために記録して残しておくものとなります。

要件定義工程では、要求事項を取り纏めますが、詳細な設計などについては、設計工程以降で検討する内容となりますので、申し送り対象として記録しておきます。

そのほかには、本来要件定義で決めるべきものが、決めきれなかったりした場合にも後続フェーズで引き続き検討が必要な場合がありますので、この場合にも申し送りとして記録しておきます。

1.申し送り事項一覧（サンプル）

テンプレートとして提供しているサンプルの書式を使って説明していきます。

1.表紙

画像はクリックすると拡大表示されます。

表紙については、以下の箇所をプロジェクトに合わせて変更してください。

情報種別：社外秘など

情報所有者：基本的にはお客様の会社名となります。

会社名：自社の会社名（正式名称）を記入してください。

タイトル：ドキュメントのタイトルをプロジェクトに合わせて変更（例では、「移行要件定義書」として設定）

版数、作成日、作成者：※必要に応じて、最終更新日、更新者を入れてください。

2.改訂履歴

3.本書の構成

プロジェクトによっては、要件定義書の本体の章立ての中に組み込むこともあると思いますので、適宜修正してご利用ください。

もしくは、要件定義以外でも申し送り事項として利用する場合もあると思いますので、その場合本書の構成は不要であれば削除してご利用ください。

4.申し送り事項一覧

申し送り事項について、一覧形式で以下の内容を記録していきます。

• No.：シーケンスで番号を登録しておきます。
• カテゴリ：申し送りの種別（課題、仕様検討、タスクなど）を定義します。複数のカテゴリが必要であれば列を追加して大中小などで管理してください。
• 件名：申し送りの内容がすぐにわかるようにタイトルをつけておきます。
• 申し送り内容：申し送りの内容を記入しますが、後工程で担当者が変わる場合には内容がわかるように丁寧に記載しておく必要があります。
• 申し送りの経緯（理由）：申し送りとなった経緯や理由があれば記載しておきます。
• 起票者：申し送りを記入した担当者の名前を記入
• 起票日：申し送りを記入した日付を入力
• 承認者：申し送りの内容について承認した方の名前を記入します。（基本的にはお客様のプロジェクト責任者を記入）
• 承認日：申し送りの内容が承認された日付を入力
• 備考：備考があれば記入

以上となりますが、上記以外に必要な添付ファイルがあれば、別紙や補足資料としてページを追加しておきましょう。

2.テンプレートのダウンロード

資料のダウンロードおよびご利用に関しては、本サイトのコンテンツ利用規約に同意される場合のみ利用可能となります。

一般公開資料（PPT版）

要件定義_要件定義書_別紙9「申し送り事項一覧」（Excel版）のダウンロード

※クリックして資料のダウンロードが開始されるまで少し時間がかかる場合がありますので、そのままお待ちください。

もしダウンロードが開始されない場合、ブラウザでポップアップブロックされている可能性があるのでご確認ください。

まとめ

そのほか要件定義に関するドキュメントをお探しの場合は、以下の記事にご利用可能な全てのコンテンツ（ドキュメント）が掲載されているので、合わせてご利用ください。

参考

ダウンロード可能なコンテンツ（サンプル・フォーマット）一覧

[st-kaiwa2]お問合せ・ご要望いただいているコンテンツも頑張って作成して…

続きを読む

サポーターさん

ブログランキングに参加しましたので、ご支援していただけると幸いです。

にほんブログ村