はじめに
Databricksの運用保守を担当していると、避けて通れないのがジョブの失敗です。
しかし、ジョブが失敗したからといって、すぐにNotebookのコードが原因だとは限りません。実際には、コンピュートの起動、権限、外部ストレージ、データの形式、ライブラリなど、さまざまな場所に原因が存在します。
この記事では、Databricksのジョブが失敗したときに、運用担当者がどのような順番で確認・一次切り分けを行えばよいかを初心者向けに整理して解説します。
本記事の画面名や機能名は、Azure Databricksを前提としています。実際の対応では、組織の手順や権限設計を優先してください。
対象読者
- Databricksの運用保守を始めたばかりの方
- ジョブ失敗時に、どこから確認すればよいか迷っている方
- 障害発生時の一次切り分け手順を標準化したい方
まず押さえたい考え方
一次切り分けの目的は、その場で必ず障害を解決することではありません。
重要なのは、次の3点を明らかにすることです。
- どこで失敗したのか
- 何が原因として疑われるのか
- 誰に、どの情報を添えて引き継ぐのか
そのため、エラーを見つけて慌ててすぐに再実行するのではなく、先に実行結果やログを確実に保存・記録しておくことが大切です。
全体の切り分けフロー
ジョブが失敗した場合は、以下のステップ順に確認を進めます。
- 対象ジョブと実行時刻を特定する
- 失敗したタスクを特定する
- エラーメッセージとログを確認する
- コンピュートの起動状況を確認する
- 権限・認証・外部接続を確認する
- 入力データとテーブルの状態を確認する
- 過去の正常実行と比較する
- 再実行の可否を判断する
以下、各ステップの詳細を説明します。
1. 対象ジョブと実行時刻を特定する
最初に、調査対象のジョブと実行を明確にします。
Databricksのサイドバーから Jobs & Pipelines（または Workflows > Jobs）を開き、対象ジョブの実行履歴（Runs）を確認します。
最低限、以下の情報を記録します。
| 確認項目 | 例 / 説明 |
|---|---|
| ジョブ名 | daily_sales_import |
| Run ID | 123456789 |
| 開始日時 | 2026-09-12 02:00 JST |
| 終了日時 | 2026-09-12 02:08 JST |
| 実行結果 | Failed |
| 実行契機 | Schedule（定期実行） / 手動 / APIトリガー |
| 通常の処理時間 | 約15分 |
タイムゾーンに注意
Databricksの画面（UTC/JST設定）、クラウド側のログ（Azure Monitor / Log Analytics等）、アラート通知メールなどでタイムゾーンが異なると、別の実行履歴を調べてしまう原因になります。必ず基準のタイムゾーンを統一して確認しましょう。
2. 失敗したタスクを特定する
複数のタスクで構成されるマルチタスクジョブでは、「ジョブ全体が失敗した」という情報だけでは不十分です。
Run details を開き、DAG（タスクグラフ）の中でどのタスクが最初に失敗したのかを確認します。
【タスク実行の流れの例】
[データ取得 (Succeeded)]
└─> [データ加工 (Failed!)] ※
├─> [集計テーブル更新 (Skipped)]
└─> [外部サービス連携 (Skipped)]
上記のように「データ加工」が失敗した結果、後続タスクが Skipped になっている場合、最初に調査すべきは データ加工 です。Skipped になった後続タスクを調べても根本原因にはたどり着けません。
確認ポイント
- 最初に失敗したタスクはどれか
-
後続タスクは
FailedかSkippedか - Retry（自動再試行）が行われているか
- すべてのRetryが同じエラーで失敗しているか
- タスク間で受け渡すパラメーターに異常がないか
3. エラーメッセージとログを確認する
失敗したタスクをクリックして開き、Output や実行ログを確認します。
このとき、最後の1行だけではなく、エラーが発生する少し手前から確認するのがコツです。最後に表示される例外は、根本原因をラップした上位のエラーであるケースが多いためです。
ログで探すべき情報
- エラーの種類（Exceptionクラス名やエラーコード）
- 最初にエラーが発生した正確な時刻
- 対象のNotebook、SQL文、テーブル名、ファイルパス
- HTTPステータスコード（4xx / 5xx系）
-
Caused by:に続く根本例外メッセージ - 同じエラーの繰り返し
代表的なエラーと疑うべき箇所
| エラーの例 | 主に疑う箇所 |
|---|---|
PERMISSION_DENIED |
Unity Catalogの権限、Azure RBAC、マネージドID、Azure Key Vault / Secret、接続先のアクセス制御 |
TABLE_OR_VIEW_NOT_FOUND |
Catalog / Schema / テーブル名の間違い、参照先環境の相違 |
AnalysisException |
SQL構文エラー、スキーマ不一致、列名変更、データ型不一致 |
ModuleNotFoundError |
Pythonライブラリ未インストール、Databricks Runtime変更による環境差異 |
OutOfMemoryError (OOM) |
急激なデータ量増加、非効率なクエリ/処理、コンピュートサイズ不足 |
429 Too Many Requests |
外部APIのレートリミット（リクエスト頻度超過） |
Connection timed out |
ネットワーク設定、NSG (Network Security Group)、Private Endpoint、接続先ダウン、DNS |
4. コンピュートの起動状況を確認する
Notebookやタスクの処理が開始される前に失敗している場合は、コンピュート（クラスタ）側の問題を疑います。
確認ポイント
-
コンピュートは正常に起動したか（
Runningに到達したか） - 起動に通常より時間がかかっていないか（タイムアウトしていないか）
- Azure側で必要なVMサイズ・コア数クォータを確保できたか（容量不足など）
- ライブラリのインストール（PyPI/Maven等）は成功したか
- Cluster Policy（クラスタポリシー）に違反していないか
切り分けの目安
| 状況 | 主に確認する場所 |
|---|---|
| コンピュートが起動しない | コンピュートの Event Log、Azure側の設定・コア数クォータ制限 |
| 起動直後にすぐ停止する | Init Scriptのエラー、ライブラリの依存関係競合、ポリシー違反 |
| Notebook開始後に失敗する | Notebookセル出力、SQL実行ログ、入力データ |
5. 権限・認証・外部接続を確認する
「昨日まで正常に動いていた」ジョブでも、権限やトークンの期限切れによって突然失敗することがあります。
直近で以下の変更がなかったか確認
- 実行ユーザーや Service Principal（Microsoft Entra ID）の権限変更
- Unity Catalog の
GRANT設定変更 - Azure RBAC（ロール割り当て）や ADLS Gen2 / ストレージアカウントのアクセス制御変更
- Databricks Secret / Azure Key Vault のシークレット更新・失効
- 外部APIキーやOAuthトークンの期限切れ
- 接続元IPアドレス制限（ファイアウォール設定）の変更
- 接続先外部サービスやデータベースのメンテナンス・障害
ポイント
「権限エラーだからDatabricksの画面内だけを確認する」と決めつけないことが重要です。
6. 入力データとテーブルの状態を確認する
ジョブの設定やプログラムコードが変わっていなくても、取り込むデータの変化によって処理が落ちることがあります。
入力データの確認例
- 対象ファイルが所定の場所に配置されているか
- ファイルサイズが
0バイト（空ファイル）になっていないか - ファイル名やディレクトリ構成の規則が変わっていないか
- CSV等の区切り文字や文字コード（UTF-8, Shift-JIS等）が変わっていないか
- 想定外の新しい列が追加されていないか（スキーマドリフト）
- 列のデータ型が変わっていないか（数値列に文字列が入った等）
- NULL非許容の列に NULL が混入していないか
- 上流テーブルのバッチ更新が遅延・未完了になっていないか
Delta Lakeの変更履歴を確認するSQL
Deltaテーブルを使用している場合、テーブル履歴（Time Travel機能）を確認して直前の変更を特定できます。
-- テーブルの全変更履歴を確認
DESCRIBE HISTORY catalog_name.schema_name.table_name;
-- 直近10件の変更履歴を確認
DESCRIBE HISTORY catalog_name.schema_name.table_name LIMIT 10;
実行ユーザー、操作種別（WRITE, MERGE, OPTIMIZE 等）、コミット日時を確認し、ジョブ失敗直前に予期せぬ更新がなかったかを調べます。
7. 過去の正常実行と比較する
原因の特定が難しい場合、「直近の成功したRun」と「失敗したRun」の差分を比較するのが最も効果的です。
| 比較対象 | 確認内容 |
|---|---|
| コード | NotebookやSQL、Gitブランチ・コミットの変更 |
| 実行設定 | ジョブパラメーター、スケジュール、Retry設定の変更 |
| コンピュート | Databricks Runtime、VMサイズ（ノードタイプ）、ワーカー数 |
| ライブラリ | ライブラリの追加・更新・削除によるバージョン差異 |
| データ | 処理レコード件数、ファイル容量、スキーマ、異常値 |
| 権限 | 実行者、Service Principal（Microsoft Entra ID）、Azure RBAC |
| 処理時間 | どのタスク・どの処理フェーズから遅延し始めたか |
「前回は成功した」という事実だけでなく、「前回から何が変わったのか」を見つけることが原因究明への最短ルートです。
8. 再実行の可否を判断する
調査を始める前に安易に再実行ボタンを押すと、原因調査に必要なエラーログが上書きされたり、データが二重計上されたりするリスクがあります。
再実行前に必ずチェックすべき項目
- 同じ処理を複数回実行しても問題ない設計になっているか（冪等性の確認）
-
INSERTによるレコードの重複が発生しないか（MERGEや上書きになっているか） - 外部APIやWebhookを二重に呼び出さないか
- メールや通知メッセージを二重送信しないか
- 途中まで中途半端に書き込まれた一時データ・ファイルが残っていないか
- 再実行の対象は「ジョブ全体」か「失敗したタスクのみ（Repair Run）」か
- 後続システムや下流バッチへの影響・実行順序は大丈夫か
冪等性（べきとうせい）とは
ある操作を1回行っても複数回行っても、得られる結果が同じになる性質のことです。運用担当者が安心してリカバリできるよう、ジョブごとに「再実行時の挙動」と「リカバリ手順」をあらかじめドキュメント化しておくことが推奨されます。
運用開始前に用意しておきたいチェックリスト
障害が発生してから調査方法を調べるのではなく、平時のうちに以下の情報を整理・標準化しておくと迅速に対応できます。
- ジョブ一覧と主担当・副担当者
- ジョブの実行スケジュールと依存関係図
- 平常時の標準処理時間
- 入出力テーブル一覧と外部接続先
- 障害通知の通知先（Slack、Teams、メール等）
- リトライ設定（回数・間隔）のガイドライン
- 再実行可否の判断基準（冪等性の有無）
- エスカレーションフローと連絡体制
まとめ
Databricksジョブの一次切り分けにおける重要ステップをおさらいします。
- 対象の実行履歴（Run ID）を特定する
- DAGを確認し、最初に失敗したタスクを見つける
- ログから「根本原因（Caused by）」となる事実を集める
- コンピュート ➔ 権限 ➔ データ の順に確認する
- 直近の正常実行との「差分」を探す
- 冪等性を確認してから再実行を判断する
- 「事実・推測・未確認」を分けて関係者へ報告する
障害発生時に大切なのは、焦って設定を変えたり再実行を繰り返したりしないことです。
決まった手順に沿って確認を進め、原因の範囲を段階的に絞り込んでいきましょう。