Lakeflowジョブに追加されたGenie Codeタスクを試してみた

Posted at 2026-09-04

はじめに

Lakeflowジョブのタスクタイプに「Genie Code」が追加されました。ジョブの一タスクとして自然言語のプロンプトを置いておくと、実行時にGenie Codeのエージェントが起動し、プロンプトに従ってデータの確認やツール呼び出しを自律的に行います。現時点ではベータです。

これまでGenie Codeはチャット画面で対話しながら使うものでしたが、ジョブに組み込めるようになったことで、SQLタスクやノートブックタスクと同じ流れの中に「エージェントに判断させる工程」を差し込めるようになります。

実際にジョブを作り、疎通確認とバッチエラー監視のプロンプトを何本か流してみました。設定手順と動作、そしてプロンプトをどう書くかを、実行結果とあわせて書いていきます。プロンプトの書き方については、対話で使うときとは別の勘所があることが分かったので、そこが本記事の中心になります。

なお、上流タスクの出力を読ませる構成は別記事に分けます。

ジョブのGenie Codeタスクとは

Genie Codeタスクは、ジョブの実行時にプロンプトを使って新しいGenie Codeチャットを起動し、その応答を生成するタスクです。ドキュメントで挙げられている用途は次のようなものです。

夜間ジョブの結果を要約して関係者に送る
到着したデータを分析して異常を検知する
Jiraチケットを調査して修正案を出す
週次のコンプライアンス監査レポートを生成する

ポイントは、これらが「人がチャットを開いて指示する」のではなく、ジョブのスケジュールやトリガーで勝手に走るという点です。

スケジュール済みタスクとの違い

Genie Codeには以前から「スケジュール済みタスク」があり、こちらも定期的にプロンプトを実行します。両者の位置づけを整理しておきます。

観点	Genie Codeのスケジュール済みタスク	ジョブのGenie Codeタスク
設定する場所	Genie Codeのチャット画面	Lakeflowジョブのタスク一覧
起動条件	スケジュールのみ	ジョブが持つ条件全般 (スケジュール、ファイル到着、テーブル更新、手動、API)
他タスクとの連携	なし	上流タスクの出力を読める。前後に他タイプのタスクを並べられる
パラメーター	なし	ジョブパラメーターを `{{name}}` で参照できる
再試行・通知・タイムアウト	なし	ジョブのタスク設定として持てる
実行結果	チャット一覧に新しいチャットが増える	ランのアウトプットにチャットへのリンクと応答が出る

一人で「毎朝これを確認したい」ならスケジュール済みタスクで十分ですが、既存のパイプラインの後ろに「結果を見て判断する工程」を付けたい、失敗時に通知したい、パラメーターで対象を切り替えたい、といった話になるとジョブのタスクの出番です。

前提条件

ワークスペースでGenie Codeタスクのベータが有効になっていること。ワークスペース管理者がプレビューページから制御します
実行するユーザーがGenie Codeエージェント機能を使えること
プロンプトの内容がGenie Codeの利用ポリシーに沿っていること

設定手順

ジョブUIの「タスク」タブから「タスクの追加」をクリックし、タスクタイプのドロップダウンから「Genie Code」を選びます。

最初に気づくのは、コンピュートの選択欄がないことです。ノートブックタスクやSQLタスクではクラスターやウェアハウスを選びますが、Genie Codeタスクにはそれがありません。エージェント自体はGenie Code側の基盤で動き、データにアクセスする際は対話セッションと同じ経路を使うため、タスクとしてコンピュートを指定する必要がないのだと思われます。

設定項目は実質「タスク名」と「プロンプト」の2つです。

プロンプト欄には、チャット画面でGenie Codeに指示するのと同じ自然言語を書きます。ただし、チャットと違って途中で聞き返されることはないので、書き方には工夫が要ります。これは後半でまとめます。

必要に応じて「タスクの詳細設定」で再試行、実行時間の上限、通知を設定し、「タスクの保存」で完了です。

ジョブパラメーターをプロンプトから参照する

実行ごとに変えたい値は、プロンプトの中に {{パラメーター名}} の形で埋め込めます。

「ジョブの詳細」サイドバーの「パラメーターの編集」でキーと値を定義しておくと、実行時にプロンプト内の {{severity}} のような記述がその値に置き換わります。一致するパラメーターがなければそのまま残ります。ジョブの動的な値の参照 ({{job.start_time.iso_date}} のような記述) も使えるので、「今日の日付」をプロンプトに渡すのにも使えます。

疎通確認を通す

まず、データに触らない最小のプロンプトで一本通しました。ジョブ名は Genie Task Test、タスク名は genie_task です。

プロンプトはこれだけです。

こんにちは

実行すると、通常のタスクと同じようにランの画面で状態を追えます。

完了すると「ランのアウトプット」に、起動されたGenie Codeチャットへのリンク、送信されたプロンプト、エージェントの最新の応答が表示されます。

こんにちは！Databricks Jobのタスク「genie_task」（ジョブ名: Genie Task Test）として実行中です。
このジョブは単一タスク構成で、上流の依存タスクはありません。ユーザーからの指示は「こんにちは」のみでしたので、特定の分析やデータ処理の要求は確認できませんでした。
具体的な作業が必要な場合は、ジョブのタスク設定でプロンプト（指示内容）を指定してください。例えば、テーブルの集計、レポート生成、データ品質チェックなどを実行できます。

チャットへのリンクを開くと、ジョブから起動されたスレッドがそのまま対話可能な状態で残っています。「ジョブが出した結論に対して追加で質問する」「なぜその判断になったのかツール呼び出しの履歴を辿る」といったことが、チャット画面側でできます。ジョブのログではなくチャットスレッドが実行結果になる、という点がこのタスクタイプの特徴です。

プロンプトの前に実行文脈が付加される

「こんにちは」としか送っていないのに、応答には自分がどのジョブのどのタスクとして動いているかと、上流の依存タスクがないことまで含まれています。

種明かしはランのアウトプットの「プロンプト」欄にあります。ここに表示されるのは、タスク設定に書いた文面そのままではありません。

job_id: 673405407464162 job_run_id: 438886952428921 task_key: genie_task
(ここから下がタスク設定に書いたプロンプト)

job_id、job_run_id、task_key が先頭に自動で付いています。エージェントは、この情報を手がかりにジョブAPIを呼んで自分の実行文脈を調べられるわけです。ドキュメントに「同じジョブ内の上流タスクの出力をエージェントが読み取れる」とあるのは、この仕組みの上に成り立っているのだと分かります。

疎通確認のつもりで送った一言でしたが、ここが見えたのは収穫でした。プロンプトに書いていないことをエージェントが知っている場面に出くわしたとき、この欄を見れば何が渡っているかを確認できます。

実行時間について

今回実行した4本の所要時間は、1分15秒から1分47秒でした。「こんにちは」だけのものと、テーブルを集計してレポートを書かせたものとで、それほど大きな差はありません。

Genie Codeタスクはノートブックタスクのように数秒で終わるものではなく、エージェントがツールを呼びながら進むぶん、下限として1分程度は見ておく必要があります。上限の方はプロンプト次第で伸びるので、ジョブとして組むなら「タスクの詳細設定」で実行時間の上限を入れておくと、想定より長引いたときに気づけます。後続のタスクがある構成なら、なおさら入れておいた方が安全です。

自動承認は固定でオン

ここはドキュメントの「制限事項」に明記されている点で、設計として理解しておく必要があります。

対話セッションのGenie Codeでは、ツール呼び出しのたびに承認を求めるか、自動承認するかを選べます。ジョブのGenie Codeタスクでは自動承認が常にオンで、オフにすることも、実行前にアクションをレビューすることもできません。ジョブは人がいないところで走るので、承認待ちで止まる選択肢がそもそもない、と考えると自然です。

その代わり、エージェントはAI分類器を使って各アクションをプロンプトと照合し、意図した範囲を外れるリスクのある操作をブロックします。ただしドキュメントには「自動承認は生産性向上のための機能であり、セキュリティ境界ではない」と明記されています。つまり、危険な操作を防ぐ最終的な手段はプロンプトの書き方と、実行ユーザーの権限設計です。

実務的には次のように考えておくと良さそうです。

タスクは作成者の権限で動く。書き込み権限が要らないプロンプトなら、書き込み権限のないサービスプリンシパルで実行する
プロンプトに「やること」だけでなく「やらないこと」を書く。特に更新や削除を伴う操作は明示的に禁止しておく
対話セッションで同じプロンプトを一度流して、どんなツール呼び出しが起きるかを見てからジョブに載せる

継承される設定

ジョブのGenie Codeタスクは、実行ユーザーのGenie Codeの設定とMCP接続をそのまま継承します。対話セッションでSlackやJiraのMCPサーバーを繋いでいれば、ジョブから起動されたエージェントも同じツールを呼べます。ドキュメントの例に「#data-ops Slackチャンネルに要約を投稿する」とあるのはこのためです。

逆に言うと、MCP接続がないユーザーで実行すると、プロンプトに「Slackに投稿して」と書いても投稿先がありません。誰の権限で実行するかが、使えるツールの範囲まで決めることになります。

検証に使ったテーブル

バッチ処理のエラーを記録したテーブルを対象にします。合成データです。

CREATE TABLE IF NOT EXISTS takaakiyayoi_catalog.genie_job.batch_errors (
  batch_id       STRING    COMMENT 'バッチ実行の識別子',
  run_ts         TIMESTAMP COMMENT 'バッチ実行時刻',
  error_type     STRING    COMMENT 'エラー種別',
  severity       STRING    COMMENT '重大度 (critical / warning / info)',
  error_count    INT       COMMENT '該当エラーの発生件数',
  sample_message STRING    COMMENT '代表的なエラーメッセージ'
);

ここで地味に効いてくるのがカラムコメントです。severity に「critical / warning / info」と書いておけば、プロンプト側で取りうる値を列挙しなくてもエージェントが解釈してくれます。実際、後述のレポートでもseverityの3種類を正しく並べてきました。対話セッションであれば「severityにはどんな値が入りますか?」と聞き返してもらえますが、ジョブでは聞き返しがありません。テーブル側のメタデータを整えておく価値が、対話で使うときより一段上がります。

閾値監視を動かす

バッチのエラー件数が閾値を超えたら詳細を集計する、というよくある監視をプロンプトで書きます。

takaakiyayoi_catalog.genie_job.batch_errors テーブルから、run_ts が最新のバッチ (batch_id) を特定してください。
そのバッチの error_count の合計が 5 を超えている場合は、error_type と severity ごとに error_count を集計し、
件数の多い順に並べたMarkdownの表を作成してください。表には代表的なエラーメッセージ (sample_message) の列も含めてください。
そのうえで、注目すべき点を3行以内でまとめた要約を付けてください。
5 以下の場合は「異常なし (バッチID: <batch_id>, 合計 <N> 件)」の1行だけを出力してください。
テーブルへの書き込み、更新、削除は行わないでください。

閾値を超えている場合

最新バッチが合計24件の状態で実行しました。所要時間は1分38秒です。

最新バッチ: 2026-08-28-01 (実行時刻: 2026-08-27 18:10 UTC) / エラー合計: 24件 → 閾値 5 を超過

| error_type      | severity | error_count | sample_message                                        |
| --------------- | -------- | ----------- | ----------------------------------------------------- |
| SCHEMA_MISMATCH | critical | 12          | Column order_amount: expected DECIMAL(10,2), found STRING |
| NULL_CONSTRAINT | critical | 7           | Column customer_id must not be null                   |
| LATE_ARRIVAL    | warning  | 3           | Record timestamp older than watermark by 2h           |
| DUPLICATE_KEY   | warning  | 2           | Duplicate order_id 88213                              |

要約:
- critical エラーが全体の79% (19/24件) を占め、特に SCHEMA_MISMATCH (12件) が最多。order_amount カラムの型不一致 (DECIMAL→STRING) が上流データソースの変更を示唆しており、早急な確認が必要。
- NULL_CONSTRAINT 違反 (customer_id) が7件発生しており、データ品質ルールの見直しまたは入力バリデーション強化を推奨。
- warning レベルの遅延到着・重複キーは少数だが、ウォーターマーク設定や冪等性チェックの確認も併せて検討すべき。

指定した列構成の表が、件数の多い順で返ってきました。要約も3行に収まっています。

注目したいのは要約の中身です。「79% (19/24件)」は指示していない計算ですし、型不一致から「上流データソースの変更を示唆」と踏み込んでいます。集計するだけならSQLで足りるので、Genie Codeタスクに任せる意味が出るのはこの部分です。逆に言うと、ここが要らないなら素直にSQLタスクとアラートで組んだ方が速くて安く済みます。

閾値を下回っている場合

エラー3件の新しいバッチを追加してから、同じプロンプトをもう一度実行しました。1分15秒です。

最新バッチの合計エラー数は 3件 で、閾値の5以下です。

異常なし (バッチID: 2026-09-04-01, 合計 3 件)

指定した1行がそのまま出ています。ただし、その前に判定を述べる1行が付きました。「1行だけを出力してください」と書いても、実際には前置きが1つ入る、という点は覚えておくと良さそうです。この程度であればランのアウトプットを一目見て判断できるので、実用上は問題ない範囲だと思います。

正常時の出力を指定しないとどうなるか

同じプロンプトから「5 以下の場合は〜」の1行を削って、データはそのままで実行しました。1分37秒です。

データを確認しました。結果を報告します。

最新バッチの特定結果:
- batch_id: 2026-09-04-01
- run_ts: 2026-09-03 18:10:00 UTC
- error_count 合計: 3件 (DUPLICATE_KEY: 1件 + LATE_ARRIVAL: 2件)
判定: エラー合計が 5 以下のため、閾値条件を満たしていません。

最新バッチ 2026-09-04-01 の error_count 合計は 3 であり、閾値の 5 を超えていないため、詳細集計表の作成対象外です。

参考として、直近で閾値を超えていたバッチは以下の通りです:

| batch_id      | run_ts              | error_count 合計 |
| ------------- | ------------------- | ---------------- |
| 2026-08-28-01 | 2026-08-27 18:10:00 | 24               |
| 2026-09-02-01 | 2026-09-01 18:10:00 | 8                |
| 2026-08-31-01 | 2026-08-30 18:10:00 | 5 (閾値以下)      |

直近でエラーが大幅に減少しており、特に 2026-08-28-01 で発生していた SCHEMA_MISMATCH (critical, 12件) と NULL_CONSTRAINT (critical, 7件) が最新バッチでは解消されています。現時点では正常な状態と判断できます。

同じ「異常なし」を伝えるのに、1行が20行近くになりました。内容自体は正確で、むしろ親切です。頼んでいない過去バッチとの比較表まで付けてきています。

ただ、これが毎日ランのアウトプットに並ぶと、正常か異常かを一目で判断できません。異常時だけを拾いたいのに、正常時の出力の方が長いという状態になります。ここが「ジョブに載せるプロンプト」と「チャットで打つプロンプト」の分かれ目です。チャットなら過去との比較は嬉しい追加情報ですが、無人で毎日回るジョブでは邪魔になります。

エージェントは、指定がなければ良かれと思って埋めてきます。何を出すかだけでなく、何を出さないかを書いておく必要があります。

レポートを作らせる

出力構成を細かく指定したらどこまで従うかを見るために、レポート形式も試しました。1分47秒です。

takaakiyayoi_catalog.genie_job.batch_errors テーブルの run_ts が直近7日以内のレコードを対象に、
次の構成のMarkdownレポートを作成してください。
1. サマリー: 総エラー件数 (error_count の合計)、対象バッチ数 (batch_id のユニーク数)、最も件数の多い error_type
2. error_type 別の件数と、全体に占める割合 (小数第1位まで)
3. severity 別 (critical / warning / info) の件数
4. severity が critical のものについて、sample_message を最大3件引用
5. 気になる点があれば1〜2行で補足
確認のための SELECT 以外の操作は行わないでください。

返ってきたレポートです。

バッチエラーレポート (直近7日間)
対象テーブル: takaakiyayoi_catalog.genie_job.batch_errors  集計期間: 2026-08-28 〜 2026-09-04

1. サマリー
| 指標         | 値                |
| ------------ | ----------------- |
| 総エラー件数 | 24件              |
| 対象バッチ数 | 6バッチ           |
| 最多エラー種別 | LATE_ARRIVAL (9件) |

2. error_type 別の件数と割合
| error_type      | 件数 | 割合  |
| --------------- | ---- | ----- |
| LATE_ARRIVAL    | 9    | 37.5% |
| SCHEMA_MISMATCH | 6    | 25.0% |
| NULL_CONSTRAINT | 5    | 20.8% |
| DUPLICATE_KEY   | 4    | 16.7% |

3. severity 別の件数
| severity | 件数 |
| -------- | ---- |
| warning  | 11   |
| critical | 10   |
| info     | 3    |

4. critical の sample_message (最大3件)
criticalレコードは2件検出されました。
[1] batch_id: 2026-09-02-01 / SCHEMA_MISMATCH (6件) Column order_amount: expected DECIMAL(10,2), found STRING
[2] batch_id: 2026-08-31-01 / NULL_CONSTRAINT (4件) Column customer_id must not be null

5. 補足
- LATE_ARRIVAL が全体の約4割を占めており、上流データソースの到着遅延が恒常的に発生している可能性があります。パイプラインのタイムアウト設定やソース側のSLAを見直すことを推奨します。
- critical 10件のうち SCHEMA_MISMATCH が6件と大きく、order_amount カラムの型不整合は上流テーブルのスキーマ変更が原因と考えられるため、スキーマ管理 (Schema Registry 等) の導入検討が有効です。

1から5まで、指定した順番と粒度どおりに出ています。割合は小数第1位、criticalの引用は上限3件に対して該当2件、という具合に、細かい条件も守られていました。番号付きで構成を書けば、その形で返ってくると考えて良さそうです。毎日同じ位置に同じ項目が並ぶことは、ランのアウトプットを日々見比べるうえで大きな価値があります。

対象期間や対象バッチ数といった、集計の前提にあたる情報も出力に含めさせています。ここが毎回出ていると、日をまたいで見比べたときに数字の変化を追いやすくなります。

他の用途のプロンプト

同じ書き方で他の用途にも展開できます。以下は同じテーブルを対象にしたものです。

前日比で件数の急変を検知する場合です。閾値を固定できない指標には、過去との比較で判定させます。

takaakiyayoi_catalog.genie_job.batch_errors テーブルについて、run_ts が昨日のレコードの error_count 合計と、
その前7日間の1日あたり平均を比較してください。
昨日の合計が平均の 150% を超えている場合は「要確認」として、昨日の件数、平均、増加率、
どの error_type が増加の主因かを出力してください。
150% 以下であれば「正常範囲 (昨日 <N> 件)」の1行だけを出力してください。
SELECT 以外の操作は行わないでください。

ジョブパラメーターに severity を定義しておき、同じジョブを重大度ごとに使い回す場合です。

takaakiyayoi_catalog.genie_job.batch_errors テーブルから、severity = '{{severity}}' かつ
run_ts が直近3日以内のレコードを抽出してください。
error_type ごとの件数と、最も新しい sample_message を1件ずつ挙げてください。
その前の3日間と比べて件数が増えている error_type があれば、行の先頭に [増加] を付けてください。
該当するレコードがなければ「{{severity}}: 該当なし」と出力してください。
データの変更は行わないでください。

監視対象そのものの健全性をチェックする場合です。チェック項目を箇条書きで列挙する形にしておくと、後から1行足すだけで拡張できます。同じことをSQLでやると、チェックを追加するたびにクエリを書き足すことになります。

takaakiyayoi_catalog.genie_job.batch_errors テーブルについて、以下を確認して
週次のデータ品質レポートをMarkdownで作成してください。
- 直近7日の行数と、その前7日と比べた増減
- batch_id, error_type, severity, error_count それぞれの NULL 件数
- severity に critical / warning / info 以外の値が入っているレコードの有無
- 同一 batch_id かつ同一 error_type の重複レコードの件数
- error_count が 0 以下になっているレコードの件数
問題があると考えられる項目には行の先頭に [要確認] を付けてください。
確認のための SELECT 以外の操作は行わないでください。

同じジョブの前段にノートブックタスクやSQLタスクがある場合、その出力を読ませることもできます。疎通確認の応答でエージェントが上流タスクの有無に言及していたのは、この機能の土台があるからです。実際に組んでみた結果は別記事に回しますが、プロンプトの書き方としてはこうなります。

このジョブで先に実行された上流タスクの出力を確認してください。
各タスクについて、成功/失敗、処理件数、警告やエラーがあればその内容を1行ずつまとめ、
最後に全体として問題があるかどうかを一言で判断してください。
出力はMarkdownの箇条書きにしてください。

プロンプトに共通させたこと

今回書いたプロンプトには、いくつか共通のルールを持たせました。

対象は完全修飾名で書きます。判定基準は数値で書きます。出力の形式は番号付きか、期待する1行そのものを書きます。分岐は「もし〜なら」で明示します。ここまでは対話でも同じですが、ジョブでは次の2つが効いてきます。

正常時に何を出すかを決めます。指定を外した実行で見たとおり、書かなければエージェントは良かれと思って埋めてきます。

やらないことを書きます。全部のプロンプトの末尾に「変更しない」「SELECTのみ」を入れています。自動承認が固定でオンである以上、エージェントが「集計のために一時テーブルを作ろう」と判断することを防ぐ手段は、プロンプトで明示するか、権限で縛るかの2つしかありません。読み取り専用で済むプロンプトには必ず入れておく、というのを自分のルールにしました。

まとめ

ジョブのGenie Codeタスクを設定して、疎通確認と監視・レポートのプロンプトを実行して分かったことをまとめます。

タスクタイプ「Genie Code」を選ぶと、設定項目は実質タスク名とプロンプトの2つ。コンピュートの選択欄はない
実行結果はジョブのログではなく、継続可能なGenie Codeチャットスレッド。ランのアウトプットにリンク、プロンプト、最新の応答が出る
タスク設定のプロンプトの先頭に、job_id、job_run_id、task_key が自動で付加される。エージェントが自分の実行文脈を知っているのはこのため。ランのアウトプットのプロンプト欄で実際に渡っている内容を確認できる
自動承認は固定でオンで、無効化も実行前レビューもできない。AI分類器による範囲外操作のブロックはあるが、セキュリティ境界ではないと明記されている
実行ユーザーのGenie Code設定とMCP接続を継承する。誰の権限で動かすかが、使えるツールと触れるデータの範囲を決める
ジョブパラメーターと動的な値の参照を {{name}} でプロンプトに埋め込める
所要時間は今回の4本すべて1分15秒〜1分47秒。プロンプトの内容による差より、下限として1分程度かかることの方が効いてくる
出力構成を番号付きで指定すれば、順番も粒度もそのとおりに返ってくる。割合の桁数や引用の上限件数といった細かい条件も守られた
正常時の出力を指定しないと、異常がなくても20行近い応答が返る。頼んでいない過去バッチとの比較まで付けてくる
「1行だけ」と指定しても、判定を述べる前置きが1行付いた。完全な固定は難しい
カラムコメントを整えておくと、プロンプト側で取りうる値を列挙しなくてもエージェントが解釈してくれる

一番の収穫は、「ジョブに載せるプロンプト」と「チャットで打つプロンプト」は別物だと実感できたことでした。正常時の出力指定を外した実行がそれを一番よく表しています。チャットなら過去との比較や補足は嬉しい追加情報ですが、無人で毎日回るジョブでは、正常時に長い文章が出ること自体が邪魔になります。

エージェントは指定のない部分を良かれと思って埋めます。だからプロンプトを書く時間の大半は、やることよりも、やらないことと正常時の振る舞いを決めるのに使うことになりそうです。上流タスクの出力を読ませる構成は、次の記事で書きます。