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

デバッグログ

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

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

    メモ

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

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

デバッグログには、次の制限があります。

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

    頻繁にアクセスされる Apex クラスや、要求を何度も実行するユーザに対して、デバッグログ追跡フラグを有効にすると、デバッグログの時間枠やサイズにかかわらず、要求が失敗する場合があります。

    警告

  • 組織で 1,000 MB を超えるデバッグログが蓄積された場合、組織のユーザは追跡フラグを追加したり、編集したりできなくなります。この制限に達した後、さらにログを生成できるように追跡フラグを追加または編集するには、デバッグログをいくつか削除します。

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

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

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

メモ

デバッグログには、次のセクションがあります。
ヘッダー
ヘッダーには、次の情報が含まれます。
  • トランザクションで使用される API のバージョン。
  • ログの生成に使用されるログのカテゴリとレベル。次に例を示します。
次に、ヘッダーの例を示します。
この例では、API バージョンは 59.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 の間が、コードの単位の範囲です。作業の単位に他の作業単位を組み込むことができます。次に例を示します。
コードの単位には、次が含まれますが、これらには限定されません。
  • トリガ
  • ワークフローの呼び出しおよび時間ベースのワークフロー
  • 入力規則
  • 承認プロセス
  • 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 の呼び出し、コストのかかるクエリなどの情報が含まれます。「コストのかかる」クエリでは、多くのリソースが使用されます。
次に、デバッグログの例を示します。

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

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

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

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

クラスおよびトリガ用デバッグログの微調整 クラスおよびトリガ用デバッグログの検索条件
この図のもとになった擬似コード例を次に示します。
  1. Trigger1Class1 のメソッドと Class2 の別のメソッドを呼び出します。次に例を示します。
  2. Class1Class3 のメソッドを呼び出し、このメソッドが次にユーティリティクラスのメソッドを呼び出します。次に例を示します。
  3. Class2 によってトリガ Trigger2 の実行が起動されます。次に例を示します。