【正解】D
【0からの解説】
①前提知識：BigQuery はクエリを受け取ると、それを複数の「ステージ」（読み取り・集計・結合・シャッフルなど）から成る実行計画（クエリプラン）に分解し、多数のワーカー（スロット）で並列に処理します。各ステージにどれだけ時間がかかったか、どれだけの行が入出力されたか、待機・読み取り・計算・書き込みのどこに時間を使ったか、といった情報はジョブの統計情報として記録されます。Google Cloud コンソールでは、この情報を「クエリ実行グラフ」として図示でき、ジョブ履歴（個人の履歴／プロジェクトの履歴、元問題でいう Query History）から対象ジョブを開き「実行グラフ」タブを選ぶだけで、ステージ間のつながりと各ステージの詳細（ステップ、スロット時間、シャッフル量など）を確認できます。さらに、スロットの競合、シャッフル割り当て不足、データの偏り（スキュー）といった「パフォーマンス分析情報（クエリ インサイト）」も表示されます。
②要件と制約語の整理：(1) 大規模な JOIN を含むレポートが遅い、(2) 「実行計画」を調べて JOIN 内のボトルネックを特定したい、(3) 「できるだけ迅速に」＝追加の仕組みやクエリを用意せず、すぐに見られる方法が望ましい。
③正解の理由：ジョブ履歴から実行グラフを開けば、既に実行済みの日次レポートのジョブについて、JOIN ステージでの入出力行数の急増（行の爆発）、特定ワーカーへの偏り、シャッフルの大きさなどを、追加の準備なしでその場で視覚的に確認できます。実行計画そのものを最短で確認できるのはこの方法です。
【誤りの選択肢】
A：--dry_run（ドライラン）はクエリを実際には実行せず、構文チェックと処理予定バイト数の見積もりを返すだけです。実行されないためステージごとの所要時間や JOIN での行の増減といった実行時の情報は得られず、JOIN のボトルネックは特定できません。
B：INFORMATION_SCHEMA.JOBS_BY_PROJECT はジョブのメタデータを SQL で調べられる便利なビューですが、選択肢の内容は total_bytes_processed（処理したバイト数の合計）を見るだけです。ジョブ全体の合計値ではどのステージ、どの JOIN が遅いのかは分からず、実行計画の分析にはなりません。クエリを書いて結果を解釈する手間もかかり、「できるだけ迅速に」という条件にも劣ります。
C：監査ログ（Cloud Audit Logs）は「誰が・いつ・何をしたか」を記録するためのもので、ログにジョブ統計の一部が含まれることはあっても、実行計画を見やすく分析する用途ではありません。ログを検索して読み解く手間がかかり、実行グラフを開くより明らかに遅く非効率です。
【参考】
クエリプランとタイムラインクエリのパフォーマンス分析情報を取得する