Databricks Genie Codeを試す (3): スケジュールされたタスクで夜間ジョブの朝サマリーを作る

Posted at 2026-07-27

はじめに

Genie Codeに、プロンプトを定期実行する「スケジュールされたタスク」がベータとして追加されました。

Data + AI Summit 2026で「まもなく提供される」と予告されていた機能が、実際に触れるようになったかたちです。スケジュールされたタスクは、Genie Codeをインタラクティブな支援から自律的な作業へと移行させるものと説明されていました。

ここまで私はGenie Codeを2本の記事で追いかけてきました。

どちらも、突き詰めれば「承認ゲート」の記事でした。エージェントが提案し、人間が一つずつ確認して通す。その往復が安全性の担保になっていたわけです。スケジュールされたタスクは、その人間が席にいない時間帯の話になります。前提が一つ外れるので、何が変わって何は変わらないのかを整理しておく価値があります。

実際に「毎朝9時に、夜間のジョブの状況を要約してください。」という一行を投げるところから始めて、翌朝のレポートが返ってくるまでを試しました。そのあたりも含めて書いていきます。

名前が同じでも別物: Genieチャットのスケジュールされたタスクとの違い

最初に紛らわしい点を潰しておきます。「スケジュールされたタスク」という名前の機能は、Genieファミリーの中に2つあります。

Genie (旧Databricks One) のチャットのスケジュールされたタスク: ビジネスユーザーがデータに関する定型的な問い合わせを定期実行し、結果をメールで受け取るもの。以前 Databricks Genie (旧Databricks One) チャットの「スケジュールされたタスク」を試すで扱いました
Genie Codeのスケジュールされたタスク: 本記事の対象。開発者向けのコーディング・データアシスタントであるGenie Codeのプロンプトを定期実行するもの

後者は、単に質問の答えが返ってくるだけではありません。1回のランがGenie Codeのセッションまるごとに相当し、その結果としてチャットが1本生まれます。生まれたチャットは通常のチャットと同じ扱いで一覧に並び、開いて中身を追うことも、続きを話しかけることもできます。

つまり、ノートブックを読む、クエリーを投げる、コードを実行する、といったツール操作を含むエージェントの一連の仕事が、無人で走ります。ここが決定的な違いです。

準備: プレビューの有効化

2026年7月時点でこの機能はベータです。ワークスペース管理者がプレビューページで有効・無効を切り替える形になっているので、手元のUIに見当たらない場合はまずここを確認してください。Genie Code Scheduled Tasks という名前で並んでいます。

有効にすると、Genie Codeのフルページの左ナビゲーションに Schedules が現れます。ここがスケジュールされたタスクの入り口です。

タスクを作る: チャットで一行頼むだけ

ドキュメントには、チャットで依頼する、提案されたタスクから始める、手動でフォームに入力する、の3つの方法が書かれています。まずは一番手軽なチャットから試しました。投げたのはこの一行です。

毎朝9時に、夜間のジョブの状況を要約してください。

タスクの作成自体が承認ゲートを通る

ここで最初の発見がありました。Genie Codeはこの依頼を受けると、Creating scheduled task というツールアクションとして扱い、いつもの承認プロンプトを出してきます。毎回確認のセレクター、スキップ、許可という、第1弾・第2弾でさんざん見てきたあのUIです。

つまり、スケジュールされたタスクを作る行為そのものが、通常の承認モデルの中にあります。無人で走るタスクを仕込むという、それなりに影響の大きい操作が、ノートブックのセルを編集するのと同じゲートを通る。一貫していて気持ちのいい設計です。逆に言えば、インタラクティブなセッションで自動承認をオンにしていれば、この作成も自動で通るということでもあります。

許可すると、タスクが作られたという報告が返ってきます。

タイトルは「夜間ジョブ状況の朝サマリー」。私は何も指定していませんが、Genie Codeが依頼内容から命名しました。実行時刻についての聞き返しはなく、9時はJSTとして解釈されました。作成後の説明も「毎朝、前夜21時から当日9時までに実行されたジョブの成功・失敗数、エラー概要、注意事項をレポートします」と、依頼より具体的になっています。

一行の依頼は、裏で仕様書に書き換えられている

作られたタスクの詳細画面を開いて、これが一番面白い挙動だと思いました。Prompt欄に入っていたのは、私が書いた一行ではありません。

前日21時から当日9時(JST)までに実行されたDatabricksジョブの状況を要約してください。以下を含めてください:
- 実行されたジョブの総数
- 成功したジョブの数と一覧
- 失敗したジョブの数、名前、およびエラーの概要
- 実行中または保留中のジョブがあればその状況
- 特に注意が必要な項目 (連続失敗、異常に長い実行時間など) のハイライト

結果は簡潔な日本語レポート形式でまとめてください。

「夜間」を前日21時から当日9時と定義し、出力項目を5つに分解し、レポート形式と日本語であることまで指定してあります。前回の記事で「DEのプロンプトは意図伝達ではなく仕様書だ」と書きましたが、その仕様書化をGenie Codeが自分でやってくれた、というのが実態でした。

ただ、便利さと引き換えに注意点が生まれます。毎朝走るのは、私が書いた一行ではなく、この展開後のプロンプトです。 「夜間」を21時からと定義したのはGenie Codeであって、私ではありません。もし夜間バッチが20時に始まる環境なら、この定義では取りこぼします。

なので、チャットで作った直後に詳細画面を開いてPrompt欄を読む、というのを手順に入れることを強くおすすめします。解釈がずれていたらEditからプロンプトを直接書き換えられます。作るのは一行で構いませんが、走るものを確認しないまま放置すると、ずれた仕様が毎朝静かに実行され続けます。

提案されたタスクから始める

自分で思いつかないとき用に、Schedulesページには提案が並んでいます。私の環境では6件表示されました。

Review model metrics for drift (登録済みモデルのメトリクスからドリフトや劣化を検出する)
Review and optimize endpoint performance (モデルサービングエンドポイントのレイテンシーやコストを点検する)
Summarize overnight job results (夜間ジョブの結果を要約する)
Review assigned Jira tickets and suggest next steps (自分に割り当てられたJiraチケットを見て次にやることを提案する)
Surface insights from favorited dashboards (お気に入りのダッシュボードから注目すべき変化を拾う)
Monitor data quality (主要テーブルのNULL、重複、スキーマドリフトを日次で確認する)

執筆時点では英語表記で、内容もワークスペースの中身を見た個別提案ではなく汎用的なものでした。ただ、並びを見るとGenie Codeがどういう用途を想定しているかがよく分かります。モデルの監視、エンドポイントの点検、ジョブの要約、データ品質の確認。どれも読み取りと要約が中心で、書き込みや変更を伴うものは1つもありません。後述する自動承認の話と合わせて考えると、この選び方は示唆的です。

なお、私が最初に投げた依頼は、期せずして Summarize overnight job results とほぼ同じ内容でした。手っ取り早く試すなら、この提案をそのまま追加してしまうのが早いです。

手動で作る

作りたいものが決まっているなら、Create in chatの横のドロップダウンからフォームでも作れます。

入力するのはタイトル、プロンプト、スケジュール、タイムゾーンの4つだけです。タイムゾーンは (UTC+09:00) Asia/Tokyo のように一覧から選びます。

「間隔 (〜毎)」のドロップダウンを開くと、時間、日、営業日、週、月の5つが選べました。

ここで注目したいのが営業日です。夜間ジョブの朝サマリーのようなタスクは、土日に動いても読む人がいません。営業日を選んでおけば、平日の朝だけレポートが生成されます。地味ですが、無駄なランを減らせるという意味でコスト面でも効いてきます。チャットから「毎朝9時に」と依頼した場合は毎日になったので、平日だけにしたいなら後からEditで変えるか、最初から依頼文に「平日の朝9時に」と書いておくのがよさそうです。

時間が選べる点も押さえておきましょう。Genie (旧Databricks One) チャットのスケジュールされたタスクでは、2026年7月に日次より細かい頻度が使えなくなりましたが、Genie Code側にはその制限が入っていません。ただし後述の通りランはGenieの使用量に乗るので、時間単位を選ぶ場合はコストの見積もりを先にしておくべきです。

フィールドがこれだけしかない、という点も押さえておくとよいです。ジョブのようなパラメーターもリトライ設定もなく、渡せるのは実質プロンプト1本。裏を返せば、このプロンプトの精度がタスクの品質を決めます。前述の通り、チャットで作った場合はGenie Codeが仕様書に展開してくれますが、手動で作る場合はその展開も自分でやることになります。定型のタスクを量産するならフォーム、まず動くものを作りたいならチャット、という使い分けになりそうです。

なお、プロンプト欄のプレースホルダーが「例: $sentryでクラッシュがないか調べてください」となっているのが目を引きました。スケジュールされたタスクからも、MCPで接続した外部サービスを対象にできる想定なのでしょう。Databricksの中だけで完結しない朝の確認作業も守備範囲に入ってくる、という方向性が読み取れます。

スケジュール実行で変わること、変わらないこと

ランで動くGenie Code自体は、普段対話しているものと機能的に同じものです。ただし、そこに人間がいないことから来る挙動の違いが3つあります。

自動承認が常にオンになり、オフにできない

これが一番重要な変更点です。承認を押す人がいない前提なので、ラン中のツールアクションはGenie Codeが自分で承認しながら進みます。歯止めになるのはAI分類器で、個々のアクションが元のプロンプトの意図に沿っているかを見て、危ないものを止めます。そしてこの自動承認は、スケジュールされたランではオフにできません。

インタラクティブなセッションであれば、毎回確認 (デフォルト)、現在のスレッドで許可、常に許可、自動承認の4つから選べます。スケジュールされたタスクにはこの選択肢がありません。承認する人間がいないので当然といえば当然ですが、意味するところは重いです。

ドキュメントは自動承認について強い調子で釘を刺しています。要約すると以下のような内容です。

自動承認は生産性のための機能であって、セキュリティ境界ではない。分類器はベストエフォートのヒューリスティックであり、安全でないものを通すことも、安全なものを止めることもある。セキュリティやコンプライアンス、アクセス制御の要件をこれに依存して実現してはいけない。

そのうえで、本番データや機密性の高いワークスペース、誤った承認が響く共有リソースを相手にするときは自動承認を切るように、とも書かれています。スケジュールされたタスクではそのオフができない以上、**「自動承認をオフにすべき対象は、そもそもスケジュールされたタスクの対象にしない」**という判断に読み替えるのが妥当だと思います。

線引きの目安も示されています。通る側にあるのは、読み取り専用のクエリー、自分のワークスペースファイルやノートブックの編集、自分が所有するテーブルへの書き込み、すでに文脈に入っているジョブやパイプラインの実行あたり。止まる側にあるのは、破壊的な操作、本番へのデプロイ、権限やシークレットの変更、サードパーティへの外部呼び出し、強制プッシュのような危険なソース管理操作です。要するに、影響範囲が自分の手元を超えるものは通らない、という設計になっています。

第2弾の記事でも、overwriteでの書き込みに対してGenie Codeが破壊的な操作だと警告し、明示的な実行確認を求めてきた場面がありました。あのときは私が「実行する」を押しましたが、スケジュール実行では押す人がいません。読み取りと要約が中心のタスクから始めるのが安全というのが、素直な結論です。提案されたタスクが揃って読み取り系だったのも、同じ考え方の反映でしょう。

各ランが新しいチャットを作る

ランの結果は1本の長いスレッドに積み上がっていくのではなく、毎回独立したチャットとして生まれます。どのランについても、後からチャットを開けばGenie Codeが何をしたのかを辿れますし、そこから対話を再開できます。

これは地味ですが、運用上ありがたい仕様です。毎回まっさらな文脈から始まるので、前回のランの誤解を引きずりません。第2弾で、同じ珍しいタイポが繰り返し現れて文脈汚染を疑った場面がありましたが、ラン単位でスレッドが切れているなら、その心配はそもそも発生しません。

一方で、前回のランで分かったことも引き継がれないということでもあります。「先週との差分を教えて」のような、履歴に依存するプロンプトは素直には効きません。差分を見たいなら、比較対象をテーブルやノートブックなどの資産側に置いて、プロンプトからそこを参照させる構成にする必要があります。これは第2弾で書いた「プロンプトの外に文脈を置く」の話が、そのまま効いてくる場面です。

自分の権限で走る

ランはタスクを作った本人の権限で動きます。データへのアクセスも操作も、その人に対するUnity Catalogの権限の範囲内です。

サービスプリンシパルではなく作成者の権限、という点は運用設計に効きます。作成者が異動して権限が変われば、タスクの挙動も変わります。逆に言えば、自分に見えないデータをタスクが勝手に見にいくことはないので、権限設計をきちんとしているワークスペースであれば、この点は素直に安心材料です。

翌朝、何が返ってきたか

9時になると、ラン履歴に Running が現れます。生成されるチャットの名前は「夜間ジョブ状況の朝サマリー 2026-07-27 00_00 UTC」。タスクはAsia/Tokyoの9時で設定してあるのに名前はUTC表記なので、一瞬「00時?」と戸惑いますが、9:00 JST = 00:00 UTCで合っています。

そして出てきたレポートがこちらです。6ステップかけて生成されています。

構成は次の通りでした。

見出し: 夜間ジョブ実行レポート (2026/7/26 21:00 〜 7/27 9:00 JST)
サマリー: 総実行数49件、成功37件 (75.5%)、失敗12件 (24.5%)、実行中/保留中0件
成功したジョブ: シリーズ名でまとめた1行の要約
失敗したジョブ: ジョブ名、失敗回数、原因タスクの3列の表
注意が必要な項目: 連続失敗、長時間実行後の失敗、共通エラーパターンの3分類
推奨アクション: 優先的に確認すべき対象の指名

展開後のプロンプトの箇条書きと、レポートの見出しが1対1で対応しています。 総数、成功、失敗、実行中、注意項目。あの仕様書がそのまま効いていることが、出力側から確認できました。プロンプトを詰める作業がそのまま出力の安定につながる、という手応えがあります。

内容も、単なる件数の羅列では終わっていませんでした。失敗12件について「すべて Workload failed でダウンストリームタスクがスキップされるパターン」と共通性をまとめ、同一タスクが複数のジョブにまたがって失敗していることを見つけて「共通の依存データまたはリソースの問題の可能性あり」と踏み込んでいます。あるジョブが30.7分走ってから失敗したことも拾っています。

もちろん、この「可能性あり」は推測です。推測を含んだレポートが毎朝無人で生成されるという点は、読む側が意識しておく必要があります。とはいえ、朝イチで49件のジョブ実行履歴を自分で眺めるコストを考えれば、当たりを付けてくれるだけでも十分な価値があります。

ランのチャットは、自分がスケジュールから生まれたことを知らない

面白かったのが、レポートの末尾に出たフォローアップの提案です。片方は「xxxx の失敗詳細を調査する」で、これはまさに私が続けたかったことでした。ここをクリックすれば、そのまま普通のGenie Codeセッションとして深掘りに入れます。ランの結果を読んで終わりではなく、そこが調査の起点になる。この機能の一番おいしいところです。

ただ、もう片方の提案が「毎朝このレポートをスケジュール実行する」でした。すでにスケジュール実行された結果なのに、です。

各ランが独立したチャットとして生まれる仕様の、副作用と言えそうです。生成されたチャットの側からは、自分がスケジュールされたタスクの産物であるという文脈が見えていないように見えます。実害はありませんが、ランのチャットは「たまたま無人で始まった普通のチャット」として振る舞うということがよく分かる例だったので、挙げておきます。

タスクの管理

スケジュールされたタスクのペインには、作成済みのタスクとそのスケジュール、次にいつ動く予定かが一覧で並びます。個々のタスクをクリックすると詳細画面が開きます。

できることは以下の通りです。

Run nowでスケジュールを待たずに手動で走らせる
トグルをオフにして一時停止する (Activeの表示が切り替わります)
Editでタイトル、プロンプト、スケジュール、タイムゾーンを直す
ケバブメニューから削除する (確認のため2回クリックする形です)
Run historyから過去のランを選び、その回のチャットを開く

実務上ありがたいのはRun nowです。毎朝9時のタスクを作ったからといって、明日の朝まで検証を待つ必要はありません。プロンプトを書いたらまず手動で回してみて、返ってくる内容を見てからプロンプトを直す。この試行錯誤ができるかどうかで、タスクの完成度が変わります。前述の「展開後のプロンプトを確認する」とセットで、作ったらまず1回回すを習慣にするのがよさそうです。

制限事項

ドキュメントに明記されているのは2つです。

1つはタスクの共有です。タスクそのものは他のユーザーに渡せません。共有できるのは、ランから生まれた個々のチャットの方だけで、こちらは通常のGenie Codeチャットと同じように共有できます。

「チーム共通の朝の要約タスクを1つ作って全員で見る」という運用はできません。各自が自分のタスクを作るか、誰か1人が作ってラン結果のチャットを都度共有するか、のどちらかになります。前述の「作成者の権限で走る」仕様とも整合的で、現時点ではあくまで個人の生産性ツール、という位置づけだと理解しています。

もう1つはコストです。スケジュールされたタスクの実行はGenieの使用量に乗ります。使用量の上限に達している状態でも、ランの実行自体は試みられ、インタラクティブなセッションが失敗するときと同じように失敗します。

2026年7月からGenieは従量課金に移行し、ユーザーあたり月150 DBUの無料枠が付いています。スケジュールされたタスクは黙って毎日走るので、インタラクティブな利用と違って「使いすぎに気づかない」ことがあり得ます。今回のレポートも6ステップかけて生成されていました。実行頻度は必要最小限にして、Genieの予算とコスト管理で予算を設定しておくのが無難です。間隔に営業日を選ぶだけでもランは3割ほど減りますし、使わなくなったタスクをオフにしておくのも忘れずに。

どんなプロンプトを書くべきか

第2弾で、データエンジニアリングのプロンプトは意図の伝達ではなく仕様書だ、と書きました。あいまいさがテーブルに焼き付いて下流に静かに伝播するからです。スケジュールされたタスクでは、その傾向がさらに強くなります。あいまいなまま実行され、その場で軌道修正する人間がいないからです。

対話であれば、思っていたのと違う結果が返ってきた時点で「そうじゃなくて」と言えます。スケジュール実行では、ズレたまま毎日走り続けます。

今回試して分かったのは、その仕様書化をGenie Codeがかなりの精度で肩代わりしてくれる、ということでした。一行の依頼が5項目の指示に展開され、出力もその通りになりました。ただし展開の内容を決めたのはGenie Codeです。だからこそ、以下を意識しています。

展開後のプロンプトを必ず読む: 詳細画面のPrompt欄が、毎朝実際に走る本体。「夜間」のような言葉がどう定義されたかを確認し、違えばEditで直す
見る対象を固定する: ワークスペースにジョブが増えれば要約の対象も増えます。範囲を絞りたいなら、対象のジョブ名やパイプライン名をプロンプトに書く
やらないことを書く: 「調査のみ。コードの修正や再実行はしないこと」のように、書き込み系の行動を明示的に禁止する。自動承認をオフにできない以上、プロンプト側で意図を狭めておくのが実質的な歯止めになります
まず手動で回す: Run nowで試し、返ってきた内容を見てからスケジュールに載せる

そして、繰り返し使う規約はプロンプトに毎回書くのではなく、ユーザー指示やスキル、Unity Catalogのテーブルコメントといった「プロンプトの外」に置いておく。第2弾で書いた3点セットは、無人実行になるとさらに効いてきます。エージェントに文脈を渡す手段が、その場の会話ではなく資産だけになるからです。

まとめ

Genie Codeのスケジュールされたタスクを触って分かったことをまとめます。

プロンプトを定期実行し、各ランがフルのGenie Codeセッションとして走って新しいチャットを生成する。単なる定型レポートではなくエージェントの仕事が無人で回る
タスクの作成自体が通常の承認ゲートを通る。「Creating scheduled task」がツールアクションとして許可を求めてくる
チャットで一行頼むと、Genie Codeがそれを構造化されたプロンプトに展開して保存する。毎朝走るのは展開後のプロンプトなので、詳細画面で必ず中身を確認する
タイムゾーンは聞き返しなしでAsia/Tokyoと解釈された。タスク名もGenie Codeが命名する
間隔は時間、日、営業日、週、月から選べる。営業日を選べば平日の朝だけ走らせられる
スケジュールされたランでは自動承認が常にオンで、オフにできない。AI分類器がリスクのあるアクションをブロックするが、これはセキュリティ境界ではない
ランはタスク作成者の権限で実行される。サービスプリンシパルではない
各ランは独立したチャットになる。文脈汚染は起きないが、前回の結果も引き継がれず、自分がスケジュール由来であることも認識していない
出力はプロンプトの項目と1対1で対応した。共通する失敗パターンの指摘や推奨アクションまで含むが、推測を含む点は読む側が意識する
Run nowで手動トリガーできるので、スケジュールを待たずにプロンプトを検証できる
タスク自体は他ユーザーと共有できない。共有できるのはラン結果のチャット
Genieの使用量にカウントされる。無人で走る分、使いすぎに気づきにくい
現時点でベータ。ワークスペース管理者がプレビューページで制御する

一番の収穫は、承認モデルの位置づけが自分の中で整理できたことでした。これまでの2本では、承認ゲートは「エージェントの暴走を止める仕組み」として書いてきました。スケジュールされたタスクでそのゲートが外れてみると、実際にはゲートが人間のレビューを引き出す装置でもあったことがよく分かります。無人実行では、そのレビューを事前にプロンプトへ、あるいは指示やメタデータへ移しておくしかありません。便利になった分だけ、書く側の設計責任が前倒しになる。

とはいえ、朝イチで49件のジョブ実行履歴を人間が眺めるより、当たりを付けたレポートから始めるほうが確実に速いです。読み取りと要約から始めて、展開後のプロンプトを一度きちんと読む。それだけで十分に実用になる機能だと思います。