Salesforce デバッグログ詳細分析とトラブルシューティング

1. 予期せぬエラーや挙動不審…開発・運用時の悩み
2. デバッグログとは？開発・カスタマイズにおける役割
3. デバッグログの基本的な取得・設定方法（開発者コンソール/トレースフラグ）
1. 開発者コンソール (Developer Console) を利用する
2. トレースフラグ (Trace Flag) を利用する
4. デバッグログの読み解き方が分からない、分析に時間がかかる（効率化の課題）
5. 開発・運用効率を劇的に改善するSFsolutionのログ分析構築サービス
6. 処理速度のボトルネック特定（ガバナ制限）のためのデバッグログ分析
1. 注目すべきログライン
7. Apex、Visualforce、フローなど、各コンポーネントのデバッグ手法
8. 大量のログを効率的に検索・フィルタリングするテクニック
9. デバッグログを活用した開発者と管理者の連携ベストプラクティス
10. 次のステップ：Salesforce イベントログファイル（ELF）の徹底解説と活用事例

1. 予期せぬエラーや挙動不審…開発・運用時の悩み

Salesforceの開発・運用において、技術者が最も頭を悩ませるのは、「なぜ意図しない挙動になるのか？」という疑問です。

カスタム機能が特定のユーザーでのみ動作しない。
突然、ガバナ制限のエラーで処理が停止する。
大量データ更新時に処理速度が極端に低下する。
デプロイ後に予期せぬサイドエフェクトが発生する。

これらの問題の「真の原因」を特定するための、最も強力で基本的な手がかりこそが Salesforce デバッグログです。

2. デバッグログとは？開発・カスタマイズにおける役割

デバッグログ (Debug Log) は、Salesforce上で実行されたトランザクション（Apexの実行、ワークフローの処理、データベース操作、APIコールなど）の詳細を記録するタイムスタンプ付きの実行履歴ファイルです。

これは、アプリケーションの動作を外科医のメスのように詳細に記録するものであり、開発・カスタマイズにおいて以下の重要な役割を果たします。

エラー原因の特定: どこでエラーが発生し、どのようなデータが渡されたのか、どのコード行で例外が発生したのかを正確に示します。
処理フローの追跡: 複数のトリガーやクラス、ワークフローがどのように連携して実行されたかの流れを把握できます。
パフォーマンスの分析: ガバナ制限の消費状況（ヒープサイズ、DMLコール数、SOQLクエリ数など）を確認し、ボトルネックを特定します。

3. デバッグログの基本的な取得・設定方法（開発者コンソール/トレースフラグ）

デバッグログを取得する主要な方法は以下の2つです。

開発者コンソール (Developer Console) を利用する

最も簡単で一般的な方法です。

Salesforce画面右上の歯車アイコン → 開発者コンソールをクリック。
Debug メニュー → Change Log Levels でログレベルを設定します。
Debug メニュー → Open Execute Anonymous Window から任意のApexコードを実行するか、コンソールを開いた状態でSalesforceの操作（レコードの保存など）を実行します。
操作完了後、開発者コンソールの Logs タブにログが表示されます。

トレースフラグ (Trace Flag) を利用する

特定ユーザー、特定のApexクラス/トリガーに対して、指定期間中、ログを継続的に取得したい場合に利用します。

設定 (Setup) のクイック検索でデバッグログを検索し、デバッグログ画面へ移動します。
新規をクリックし、トレースエンティティ（ユーザーまたはクラス/トリガー）を選択し、開始日/終了日を設定します。
デバッグレベルを適切に設定します。通常、Apexのデバッグでは $ApexCode = DEBUG$ や $FINER$ 程度に設定します。

4. デバッグログの読み解き方が分からない、分析に時間がかかる（効率化の課題）

デバッグログは極めて強力なツールですが、その「読み解きにくさ」が大きな課題となります。

ログの巨大化: 複雑な処理や長時間のトレースでは、ログファイルが数十MB〜数百MBになり、テキストエディタでの分析が困難になります。
必要な情報の見つけにくさ: 大量のテキスト行の中から、エラー発生箇所、特定のSOQLクエリ、ガバナ制限の情報を抽出するのに時間がかかります。
手動分析の非効率性: ログを何度もダウンロードし、手動で検索・フィルタリングする作業は、トラブルシューティングの時間を大幅に長期化させます。

技術者が「ログ分析」にかける時間を削減し、「本質的な開発・改善」に集中するためには、効率的なログ分析環境の構築が不可欠です。

5. 開発・運用効率を劇的に改善するSFsolutionのログ分析構築サービス

このようなログ分析の課題を解決し、Salesforceの開発・運用効率を劇的に改善するのが、SFsolutionのログ分析構築サービスです。

SFsolutionでは、Salesforceのデバッグログやイベントログを外部のログ分析プラットフォーム（例：AWS OpenSearch Service、Splunkなど）に連携し、以下のメリットを提供します。

ビジュアルな分析: ログデータをグラフやダッシュボードで視覚化し、エラー率の推移や処理時間のボトルネックを一目で把握できます。
高速な検索・フィルタリング: 大量のログデータでも、数秒で目的のエラーやトランザクションを検索・絞り込みが可能です。
アラート設定: 特定のエラーパターンやガバナ制限超過の兆候を検知した際に、自動で管理者へ通知する仕組みを構築できます。

このサービスを活用することで、開発者や管理者は「ログを読む」時間から解放され、「問題を解決する」**時間により多くのリソースを割くことができます。

6. 処理速度のボトルネック特定（ガバナ制限）のためのデバッグログ分析

Salesforceの処理速度低下の主な原因の一つはガバナ制限です。デバッグログの特定の行を分析することで、ボトルネックを特定できます。

注目すべきログライン

1. ガバナ制限の消費状況（LIMITS_USAGE）

処理の終盤に記録される LIMITS_USAGE 行を確認します。

LIMITS_USAGE_FOR_NS|(...)|[CPU_TIME_USED, 200, 10000]
LIMITS_USAGE_FOR_NS|(...)|[SOQL_ROWS, 50, 50000]
LIMITS_USAGE_FOR_NS|(...)|[DML_STATEMENTS, 3, 150]

このログから、CPU時間や SOQLクエリ数など、どのリソースが制限に近づいているか（または超過したか）がわかります。

2. 最も時間のかかった処理（CUMULATIVE_LIMIT_USAGE）

CUMULATIVE_LIMIT_USAGE 行の直後に表示される EXECUTION_TIME に注目し、最も実行時間の長いメソッドやSOQLクエリを特定します。

3. 大量データ操作 (SOQL/DML)

SOQL_EXECUTE や DML_BEGIN 行の直後に、実行されたクエリや操作の内容が記録されます。ここで非効率なクエリ（ループ内でのSOQL実行など）を見つけ出します。

7. Apex、Visualforce、フローなど、各コンポーネントのデバッグ手法

コンポーネントによって、デバッグログでの注目ポイントが異なります。

コンポーネント	主なログレベル設定	注目すべきログキーワード
Apex	$ApexCode = DEBUG/FINER$	`USER_DEBUG`, `EXECUTION_STARTED/FINISHED`, `METHOD_ENTRY/EXIT`, `SOQL_EXECUTE`
Visualforce	$Visualforce = DEBUG$	`VF_APEX_CALL`, `VF_PAGE_MESSAGE` (コントローラとの連携を確認)
フロー (Flow)	$Workflow = DEBUG$	`FLOW_START`, `FLOW_ELEMENT_BEGIN`, `FLOW_ELEMENT_END` (どのノードで処理が止まったか、条件分岐の結果を確認)
プロセスビルダー	$Workflow = DEBUG$	`WF_RULE_EVAL_BEGIN`, `WF_CRITERIA_BEGIN/END` (評価された条件とその結果を確認)

特にフローは、デバッグログとフロービルダーのデバッグモードを併用することで、より迅速に問題を解決できます。

8. 大量のログを効率的に検索・フィルタリングするテクニック

開発者コンソールやテキストエディタでログを分析する際の効率化テクニックです。

キーワード検索:
- FATAL_ERROR: 例外が発生した箇所にジャンプ。
- LIMIT_USAGE: ガバナ制限の消費状況を確認。
- SOQL_EXECUTE: 実行されたクエリを全て抽出。
- USER_DEBUG: Apexコード内で意図的に出力したデバッグメッセージを抽出。
開発者コンソールの機能:
- Filter機能: ログパネル上部の「Filter」ボックスでキーワードを入力し、表示行を絞り込みます。
- Execution Log Panel: 左側のツリー構造で、Limits や Timeline を表示し、実行ステップごとのリソース消費をグラフィカルに確認します。
外部ツールの活用: Visual Studio Code (VS Code) 拡張機能など、外部の専用ツールにログを取り込むことで、より高度なシンタックスハイライトや折りたたみ機能を活用できます。

9. デバッグログを活用した開発者と管理者の連携ベストプラクティス

デバッグログは、技術的な分析だけでなく、ビジネスサイドと連携するための重要なエビデンスにもなります。

役割	ベストプラクティス	目的
管理者 (Admin)	発生時の操作手順とログのセット提供	再現性の確保。現象発生時の操作手順を詳細に記録し、トレースフラグを設定してログを取得。
開発者 (Developer)	エラーの原因と解決策の要約	状況の共有。デバッグログの重要な行（エラー箇所、ボトルネック）を抜粋し、管理者やビジネスユーザーに分かりやすい言葉で原因と解決策を報告。
共通 (Both)	ログレベルの標準化	情報の均一化。組織内で「トラブルシューティング時は $ApexCode = FINE$」など、デバッグレベルの標準ルールを設定し、情報過多・不足を防ぐ。