この文章は Salesforce 機械翻訳システムを使用して翻訳されました。詳細はこちらをご参照ください。
英語に切り替える

デバッグログ

デバッグログには、データベースの操作、システムプロセス、トランザクションの実行時または単体テストの実行中に発生したエラーを記録できます。デバッグログには、次の情報を記載できます。
  • データベースの変更
  • HTTP のコールアウト
  • Apex のエラー
  • Apex によって使用されるリソース
  • 次のような自動化されたワークフロー処理:
    • ワークフロールール
    • 割り当てルール
    • 承認プロセス
    • 入力規則

    デバッグログに、時間ベースのワークフローでトリガされたアクションからの情報は記載されません。

    メモ

自分自身を含む特定ユーザ、クラス、およびトリガのデバッグログを保持および管理できます。クラスおよびトリガの追跡フラグを設定してもログの生成や保存は行われません。クラスおよびトリガの追跡フラグによって他のログレベル (ユーザ追跡フラグによって設定されたログレベルなど) が上書きされますが、ログが記録されることはありません。クラスまたはトリガが実行されたときにログ記録が有効であれば、実行時にログが生成されます。

デバッグログを表示するには、[設定] から、[クイック検索] ボックスに「デバッグログ」と入力し、[デバッグログ] を選択します。次に、確認するデバッグログの横にある [表示] をクリックします。[ダウンロード] をクリックしてログを XML ファイルとしてダウンロードします。

デバッグログには、次の制限があります。
  • 各デバッグログは最大 20 MB です。デバックログのサイズが 20 MB を超えると、System.debug ステートメントの始めの方のログの行など、古いログの行の削除によってサイズが縮小されます。ログの行は、デバッグログの最初からだけでなく、どの位置からでも削除できます。
  • システムデバッグログは 24 時間保持されます。監視デバッグログは 7 日間保持されます。
  • 15 分間で 1,000 MB を超えるデバッグログを生成すると、追跡フラグが無効になります。追跡フラグを最後に更新したユーザにメールが送信され、15 分後に追跡フラグを再度有効化できることが通知されます。
  • 組織で 1,000 MB を超えるデバッグログが蓄積された場合、組織のユーザは追跡フラグを追加したり、編集したりできなくなります。この制限に達した後、さらにログを生成できるように追跡フラグを追加または編集するには、デバッグログをいくつか削除します。

クラスまたはトリガの実行前にシステム検証エラーが発生すると、ログ記録が実行されない場合があります。特定のユーザについてデバッグログが生成されていない場合は、ユーザ権限と他の類似する検証エラーを調べてください。

メモ

デバッグログセクションの調査

デバッグログを生成した後、表示される情報の種類や量は、ユーザに設定した検索値によって異なります。ただし、デバッグログの形式は常に同じです。

Apex デバッグログでは、セッション ID は「SESSION_ID_REMOVED」に置き換えられます。

メモ

デバッグログには、次のセクションがあります。
ヘッダー
ヘッダーには、次の情報が含まれます。
  • トランザクションで使用される API のバージョン。
  • ログの生成に使用されるログのカテゴリとレベル。次に例を示します。
次に、ヘッダーの例を示します。
155.0 APEX_CODE,DEBUG;APEX_PROFILING,INFO;CALLOUT,INFO;DB,INFO;SYSTEM,DEBUG;VALIDATION,INFO;VISUALFORCE,INFO;
2WORKFLOW,INFO
この例では、API バージョンは 55.0 で、次のデバッグログカテゴリおよびレベルが設定されています。
Apex コード DEBUG
Apex プロファイリング INFO
コールアウト INFO
データベース INFO
システム DEBUG
入力規則 INFO
Visualforce INFO
ワークフロー INFO

Apex コードのログレベルが FINEST に設定されていると、Apex 変数の割り当ての詳細がデバッグログにすべて含まれます。追跡する Apex コードで機密データが処理されないことを確認してください。FINEST ログレベルを有効化する前に、組織の Apex で処理される機密データのレベルを必ず把握してください。コミュニティユーザのセルフ登録など、ユーザパスワードが Apex 文字列変数に割り当てられる場合があるプロセスには特に注意が必要です。

警告

実行ユニット
実行ユニットは、トランザクションと同じです。実行ユニットには、トランザクション内で発生した���べての情報が含まれています。EXECUTION_STARTEDEXECUTION_FINISHED の間が実行ユニットの範囲です。
コードユニット
コードユニットは、トランザクション内の作業単位です。たとえば、webservice メソッド、または入力規則であるトリガはコードの単位の 1 つです。

クラスはコードの単位ではありません

メモ

CODE_UNIT_STARTEDCODE_UNIT_FINISHED の間が、コードの単位の範囲です。作業の単位に他の作業単位を組み込むことができます。次に例を示します。
1EXECUTION_STARTED
2CODE_UNIT_STARTED|[EXTERNAL]execute_anonymous_apex
3CODE_UNIT_STARTED|[EXTERNAL]MyTrigger on Account trigger event BeforeInsert for [new]|__sfdc_trigger/MyTrigger
4CODE_UNIT_FINISHED <-- The trigger ends
5CODE_UNIT_FINISHED <-- The executeAnonymous ends
6EXECUTION_FINISHED
コードの単位には、次が含まれますが、これらには限定されません。
  • トリガ
  • ワークフローの呼び出しおよび時間ベースのワークフロー
  • 入力規則
  • 承認プロセス
  • Apex リードの変換
  • @future メソッドの呼び出し
  • Web サービスの呼び出し
  • executeAnonymous コール
  • Apex コントローラの Visualforce プロパティアクセス
  • Apex コントローラの Visualforce アクション
  • Apex start メソッドや finish メソッドの一括実行、および execute メソッドの各実行
  • Apex System.Schedule execute メソッドの実行
  • 受信メールの処理
ログの行
ログの行は、コードユニット内に含まれ、どのコードやルールが実行されたかを示します。ログの行は、デバッグログに書き込まれたメッセージである場合もあります。次に例を示します。
デバッグログの行の例
ログの行は、一連の項目で構成され、項目はパイプ (|) で区切られます。形式は次のとおりです。
  • タイムスタンプ: イベント発生時の時刻と括弧で囲まれた値で構成されます。時刻はユーザのタイムゾーンで、形式は HH:mm:ss.SSS となります。括弧内の値は、要求が開始されてからの経過時間をナノ秒単位で表します。[Execution Log (実行ログ)] ビューを使用すると、経過時間の値は開発者コンソールで確認したログには含まれません。ただし、[Raw Log (未加工ログ)] ビューを使用すると、経過時間を確認できます。[Raw Log (未加工ログ)] ビューを開くには、開発者コンソールの [Logs (ログ)] タブからログの名前を右クリックし、[Open Raw Log (未加工のログを開く)] を選択します。
  • イベント識別子: デバッグログエントリをトリガしたイベントを指定します (SAVEPOINT_RESETVALIDATION_RULE など)。

    コードが実行されたメソッド名、または行番号と文字番号など、そのイベントで記録された詳細情報も含まれます。行番号を特定できない場合、代わりに [EXTERNAL] が記録されます。たとえば、管理パッケージに含まれる組み込みの Apex クラスまたはコードでは [EXTERNAL] が記録されます。

    一部のイベント (CODE_UNIT_STARTEDCODE_UNIT_FINISHEDVF_APEX_CALL_STARTVF_APEX_CALL_ENDCONSTRUCTOR_ENTRYCONSTRUCTOR_EXIT) では、イベント識別子の最後にパイプ (|) とその後に Apex クラスまたはトリガの typeRef が含まれます。

    トリガの場合、typeRef は SFDC トリガプレフィックス __sfdc_trigger/ で始まります。たとえば、__sfdc_trigger/YourTriggerName または __sfdc_trigger/YourNamespace/YourTriggerName のようになります。

    クラスの場合、typeRef では YourClassYourClass$YourInnerClass、または YourNamespace/YourClass$YourInnerClass の形式が使用されます。

その他のログデータ
さらに、ログには次の情報が含まれます。
  • 累積リソース使用状況は、多くのコードユニットの末尾に記録されます。このようなコードユニットとして、トリガ、executeAnonymous、Apex のメッセージの一括処理、@future メソッド、Apex テストメソッド、Apex Web サービスメソッド、Apex リードの変換などがあります。
  • 累積プロファイル情報はトランザクションの終わりに 1 回記録され、DML の呼び出し、コストのかかるクエリなどの情報が含まれます。「コストのかかる」クエリでは、多くのリソースが使用されます。
次に、デバッグログの例を示します。
137.0 APEX_CODE,FINEST;APEX_PROFILING,INFO;CALLOUT,INFO;DB,INFO;SYSTEM,DEBUG;
2    VALIDATION,INFO;VISUALFORCE,INFO;WORKFLOW,INFO
3Execute Anonymous: System.debug('Hello World!');
416:06:58.18 (18043585)|USER_INFO|[EXTERNAL]|005D0000001bYPN|devuser@example.org|
5    Pacific Standard Time|GMT-08:00
616:06:58.18 (18348659)|EXECUTION_STARTED
716:06:58.18 (18383790)|CODE_UNIT_STARTED|[EXTERNAL]|execute_anonymous_apex
816:06:58.18 (23822880)|HEAP_ALLOCATE|[72]|Bytes:3
916:06:58.18 (24271272)|HEAP_ALLOCATE|[77]|Bytes:152
1016:06:58.18 (24691098)|HEAP_ALLOCATE|[342]|Bytes:408
1116:06:58.18 (25306695)|HEAP_ALLOCATE|[355]|Bytes:408
1216:06:58.18 (25787912)|HEAP_ALLOCATE|[467]|Bytes:48
1316:06:58.18 (26415871)|HEAP_ALLOCATE|[139]|Bytes:6
1416:06:58.18 (26979574)|HEAP_ALLOCATE|[EXTERNAL]|Bytes:1
1516:06:58.18 (27384663)|STATEMENT_EXECUTE|[1]
1616:06:58.18 (27414067)|STATEMENT_EXECUTE|[1]
1716:06:58.18 (27458836)|HEAP_ALLOCATE|[1]|Bytes:12
1816:06:58.18 (27612700)|HEAP_ALLOCATE|[50]|Bytes:5
1916:06:58.18 (27768171)|HEAP_ALLOCATE|[56]|Bytes:5
2016:06:58.18 (27877126)|HEAP_ALLOCATE|[64]|Bytes:7
2116:06:58.18 (49244886)|USER_DEBUG|[1]|DEBUG|Hello World!
2216:06:58.49 (49590539)|CUMULATIVE_LIMIT_USAGE
2316:06:58.49 (49590539)|LIMIT_USAGE_FOR_NS|(default)|
24  Number of SOQL queries: 0 out of 100
25  Number of query rows: 0 out of 50000
26  Number of SOSL queries: 0 out of 20
27  Number of DML statements: 0 out of 150
28  Number of DML rows: 0 out of 10000
29  Maximum CPU time: 0 out of 10000
30  Maximum heap size: 0 out of 6000000
31  Number of callouts: 0 out of 100
32  Number of Email Invocations: 0 out of 10
33  Number of future calls: 0 out of 50
34  Number of queueable jobs added to the queue: 0 out of 50
35  Number of Mobile Apex push calls: 0 out of 10
36
3716:06:58.49 (49590539)|CUMULATIVE_LIMIT_USAGE_END
38
3916:06:58.18 (52417923)|CODE_UNIT_FINISHED|execute_anonymous_apex
4016:06:58.18 (54114689)|EXECUTION_FINISHED

Apex クラスおよびトリガ用デバッグログの検索条件の設定

デバッグログの検索条件により、ログの冗長性をトリガおよびクラスレベルで微調整できます。これは Apex ロジックのデバッグ時に特に便利です。たとえば、複雑なプロセスの出力を評価する場合、1 つの要求内で特定のクラスのログの冗長性を上げ、他のクラスまたはトリガのログをオフにすることができます。

クラスまたはトリガのデバッグログレベルを上書きすると、これらのデバッグレベルは、クラスまたはトリガが呼び出すクラスメソッドと、結果として実行されるトリガにも適用されます。実行パス内のすべてのクラスメソッドとトリガは、これらのデバッグログ設定を上書きする場合を除き、呼び出し側から継承します。

次の図は、クラスおよびトリガレベルで上書きされるデバッグログレベルを示しています。このシナリオでは、Class1 が何らかの問題を起こし、詳しい調査が必要であるとします。このために、Class1 のデバッグログレベルが最も詳細なレベルに引き上げられます。Class3 ではこのログレベルが上書きされないため、Class1 の詳細なログレベルが継承されます。ただし、UtilityClass はすでにテストされ、正しく動作することがわかっているため、ログの検索条件はオフになっています。同様に、Class2 は問題の原因であるコードパスに含まれていないため、ログは最小限に抑えられ、Apex コードカテゴリのエラーのみを記録します。Trigger2 は、Class2 からこれらのログ設定を継承します。

クラスおよびトリガ用デバッグログの微調整 クラスおよびトリガ用デバッグログの検索条件
この図のもとになった擬似コード例を次に示します。
  1. Trigger1Class1 のメソッドと Class2 の別のメソッドを呼び出します。次に例を示します。
    1trigger Trigger1 on Account (before insert) {
    2    Class1.someMethod();
    3    Class2.anotherMethod();
    4}
  2. Class1Class3 のメソッドを呼び出し、このメソッドが次にユーティリティクラスのメソッドを呼び出します。次に例を示します。
    1public class Class1 {
    2    public static void someMethod() {
    3        Class3.thirdMethod();
    4    }
    5}
    6
    7public class Class3 {
    8    public static void thirdMethod() {
    9        UtilityClass.doSomething();
    10    }
    11}
  3. Class2 によってトリガ Trigger2 の実行が起動されます。次に例を示します。
    1public class Class2 {
    2    public static void anotherMethod() {
    3        // Some code that causes Trigger2 to be fired.
    4    }
    5}