3
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Genie Codeワークショップの資料を公開しました: 一人で辿るための進め方つき

3
Posted at

はじめに

2026年8月31日と9月1日に実施したGenie Codeワークショップの資料を、Speaker Deckで公開しました。

どちらも2時間のハンズオン前提で作った資料です。座学は基礎編で15分、応用編で5分ほどしかありません。残りはすべて自分の環境で手を動かす時間に充てています。

スライドは当日の進行に合わせて作ってあるので、そのまま読むだけだと「で、何をすればいいのか」が伝わりにくい部分があります。参加できなかった方が資料だけで一人で辿れるように、それぞれの演習が何を狙っていて、どこで詰まりやすいのかを書いておきます。Genie Code自体の検証記事は別に書いているので、深掘りしたい方向けの導線も最後に用意しました。

2つの資料の関係

基礎編と応用編は、対象読者も題材も分けています。

基礎編 応用編
想定読者 Genie Codeをこれから使う方 一通り触った方、データエンジニア
題材 samples.tpch の既存テーブル 自分で生成するEC注文のダミーデータ
ゴール 対話の型を身につける パイプラインを委譲し、手順をスキルに畳む
演習数 4本 (座学15分 + ハンズオン105分) 3本 (座学5分 + ハンズオン中心)
必要な権限 SELECT権限、演習4でテーブル作成権限 SELECT権限のみ (一時ビューで完結)

ここは資料を作りながら悩んだところです。応用編の方が内容は重いのですが、必要な権限はむしろ軽い。演習A・Bを永続テーブルではなく createOrReplaceTempView の一時ビューで組んだためです。会社の共有ワークスペースで書き込み先の相談から始めると、それだけでハンズオンの時間が溶けます。後片付けも不要になるので、自習で試す場合も一時ビューのまま進めるのをおすすめします。

基礎編: 対話の型を先に体に入れる

基礎編の座学は、Genie Codeとは何か、Genieファミリーの中でのGenie Codeの位置づけ、アーキテクチャとガバナンス、料金までを15分に圧縮しています。ここを厚くしたくなる誘惑はあるのですが、コーディングエージェントは説明を聞いても分からない類のツールです。触ってから戻ってきた方が腹落ちするので、座学は「触る前に知っておかないと事故る話」だけに絞りました。

代わりに、全演習を貫く3つのコツを先に置いています。

  1. @ でテーブルやファイルを会話に渡す (文脈を与える)
  2. 小分けにして段階的に依頼する
  3. 実行前に生成コードを必ず読んでから承認する

この3つは4本の演習すべてで繰り返し出てきます。演習の見た目は違っても、やっていることは同じ型の反復です。

演習1: データディスカバリーとEDA

samples.tpchorderscustomer@ で渡して、要約統計から可視化までを対話で進めます。手作業だと25分くらいかかる作業を5分程度でやってしまおう、という設計です。

自習で試す場合、samples カタログが使えない環境なら、SELECTできるスキーマなら何でも構いません。むしろ自分の業務データでやった方が学びは大きいです。

ここでの狙いは「テーブルを渡す」感覚を掴むことです。@ で渡さずに「orders テーブルを分析して」とだけ書くと、エージェントはカタログを探すところから始めます。渡すか渡さないかで応答の質がはっきり変わるので、あえて両方試してみてください。

演習2: デバッグとエラー修正

意図的にエラーを起こして、原因の説明と修正を依頼します。資料では型不一致のクエリを例に使っています。

SELECT SUM(CAST(o_orderstatus AS INT)) FROM samples.tpch.orders;

o_orderstatus は文字列なので、これはキャストで落ちます。

演習として地味に見えますが、エージェントを使い始めて最初に効くのは実はここです。エラーメッセージをそのまま貼って「直して」と言えば直ります。ただし修正内容を読まずに承認する癖が付くと、後々の演習で確実に事故ります。ここでレビューの習慣を作っておくのが本当の狙いです。

演習3: カスタム指示の設定

毎回同じ前置きを書かなくて済むように、既定の振る舞いをファイルに置きます。

ユーザースコープの場合は /Users/<自分>/.assistant_instructions.md です。中身は日本語で構いません。

- 回答は日本語で
- 可視化は plotly を使う
- まず要点を3行で示してから詳細

plotlyを推しているのには理由があります。matplotlibやseabornで日本語ラベルのグラフを描かせると、フォント設定なしでは文字が豆腐になります。フォントを入れて設定する道もありますが、plotlyを指定してしまえばその問題ごと回避できます。この話は別記事で詳しく書きました。

制限として、カスタム指示はクイックフィックスやオートコンプリートには効きません。対話エージェント向けの設定です。1ファイル20,000字まで。

演習4: 簡単なETLと変換

型のばらつき、重複、NULLを含むサンプルを整形して保存します。ここで初めてテーブルへの書き込みが発生するので、権限を確認しておいてください。

流れは「説明させる (実行なし) → コード生成 → 承認前確認 → 実行」の4段です。基礎編で一番伝えたいのはこの順番で、応用編にもそのまま引き継がれます。

応用編: 委譲する、寄せる、畳む

応用編は3つのゴールを掲げています。

  1. 委譲できる: 対話でデータパイプラインを完成まで任せる
  2. 応答を寄せられる: カスタム指示で組織のルールに合わせる
  3. スキルにできる: 繰り返す手順を再利用可能な形に整理する

演習A・B・Cがそれぞれに対応しています。

カスタム指示は3階層ある

応用編では、基礎編で触ったカスタム指示をもう一段掘り下げて、置き場所と優先順位を扱います。

レベル ファイル 場所 範囲
ユーザー .assistant_instructions.md /Users/<自分> 個人
ワークスペース .assistant_workspace_instructions.md Workspace直下 チーム共通
プロジェクト AGENTS.md / CLAUDE.md 任意のフォルダ プロジェクト固有

個人の好み (日本語で答えて、plotlyを使って) はユーザースコープ、チームの規約 (カタログはこれを使う、テーブル名はこの命名で) はワークスペースかプロジェクトスコープ、という切り分けになります。

チームの規約をここに書けるようになると、レビューで毎回同じ指摘をする必要がなくなります。人間がコードレビューで捕まえていたものの一部を、生成の手前に移せる。規約の置き場所ができたこと自体が、実務では大きいと思っています。

演習A: ダミーデータ生成からbronze層まで

EC注文のダミーデータ (orders・customers・products 各200行) を対話で生成し、取り込み層に相当するところまで整えます。

依頼文の例はこうです。

EC注文のダミーデータをPySparkのDataFrameで作るコード。orders/customers/products各200行。amount NULL・マイナス、status表記ゆれ、重複行を少し混ぜて。まだ実行せずコードを見せて。

最後の「まだ実行せずコードを見せて」が肝です。これを付けないとエージェントは生成から実行まで一気に走ります。走ること自体は悪くないのですが、演習としては生成物を読む時間が欲しい。

汚れをあえて混ぜているのは、演習Bのクレンジングで「何件減るはずか」を自分で答え合わせできるようにするためです。生成コードをレビューする段階で、どのデータにどんな問題を何件仕込んだかを確認しておいてください。ここを読み飛ばすと、演習Bで件数が減ったときに、それが正しい除外なのか事故なのか判断できなくなります。

bronze層は createOrReplaceTempView の一時ビューにして、取り込み時刻の列だけ足します。一時ビューはセッション内でしか有効ではないので、本番ではDeltaテーブルへの永続化と冪等性の考慮が要る、という補足を資料には入れてあります。

演習B: silver層のクレンジングと結合

演習Aのビューを整形して結合します。依頼文にはこう入れています。

status は placed/shipped/cancelled の3値に正規化 (大文字小文字・空白の表記ゆれ吸収)。ANSIモードでCAST失敗注意。

ANSIモードへの言及を入れているのは、キャスト失敗が黙って NULL になるのではなくエラーになる挙動を、生成コードのレビュー観点として意識してほしいからです。

生成コードで読むべき箇所は3つです。

  • 除外条件が意図通りか
  • 型変換が失敗していないか
  • 件数の減り方が妥当か

結合では、行が増減していないかを必ず見ます。結合で行が増えるのは、たいてい結合キー側に重複が残っているサインです。件数が減りすぎたときは、除外条件を1つずつ緩めて原因を切り分けます。

このあたりが、データエンジニアリングでエージェントを使うときの難しさです。分析なら結果がグラフとして見えるので曖昧な指示でも軌道修正できますが、パイプラインでは曖昧さがそのまま仕様としてテーブルに焼き付き、下流へ静かに伝わっていきます。プロンプトが意図の伝達ではなく仕様書に近づく。だからこそカスタム指示やメタデータでの補完が効いてきます。

演習C: 手順をスキルに畳む

ここが応用編の山場です。演習Aでやった「bronze相当を用意する手順」を、SKILL.md として再利用可能な形にします。

置き場所はカスタム指示と同じ考え方で、個人なら /Users/{user}/.assistant/skills/、ワークスペース共通なら Workspace/.assistant/skills/ です。スキルごとにフォルダを作り、その中に SKILL.md を置きます。

---
name: <スキル名>
description: <いつ・何のために使うか>
---

# 本文: 入力・出力・確認手順を明記

演習では、手書きではなくGenie Code自身に書かせます。手順のノートブックを @ で渡してから依頼する形です。

この bronze 相当を用意する手順を、繰り返し使えるスキルにして。SKILL.md を作り、name と description、手順 (入力・出力・確認) を書いて。description は「いつ・何のために使うか」が伝わるように具体的に。実行せず内容を見せて。

良いスキルにするコツは、ほぼ description に集約されます。自動選択の精度が説明文の具体性に直結するためです。「データを準備する」ではなく「EC注文のような複数ソースをbronze相当の一時ビューに揃えるとき」のように、いつ使うかが書かれていないと、エージェントは呼ぶべき場面を判断できません。

**編集したスキルは、いま開いているチャットには反映されません。**新しいスレッドを開いてから確認してください。演習でも、スキルを配置したあとに新スレッドを開き、別の対象 (例えばproducts) で同じ手順を依頼して、スキルが自動選択されるかを見る流れにしています。ここを知らないと「書いたのに効かない」で時間を溶かすことになります。

発展機能は入口だけ

応用編の終盤で、MCPサーバー連携、スケジュール実行、フルページGenie Codeに触れています。ハンズオンではなく紹介にとどめているのは、どれも環境の準備や権限がハンズオンの時間内に収まらないためです。

スケジュール実行について1点だけ、資料でも強調しています。スケジュール実行では自動承認が常にオンで、実行権限は作成者のものになります。対話で使うときの「承認して実行」の感覚のまま定期実行に載せると、レビューの機会がないまま動き続けることになります。読み取り系から始めるのが無難です。

付録では公式のスキルパックも紹介しています。30以上のスキルが公開されていて、.assistant/skills/ に配置すれば自動検出されます。

外部リポジトリの取得が制限される環境では、演習Cでやったように自分で書かせるところから始めてください。

一人で進めるときの進め方

資料だけで自習する場合の目安です。

必要なもの

  • Genie Codeパネルにアクセスできるワークスペース
  • Unity Catalog上のテーブルへのSELECT権限
  • 基礎編の演習4のみ、テーブル作成と書き込みの権限

時間の目安

当日は基礎編・応用編それぞれ2時間で回しましたが、講師の説明とQ&Aを差し引くと、実作業は基礎編で60分、応用編で75分程度です。一人でやるなら、詰まったときに調べる時間を見て、それぞれ90分ほど確保しておくと落ち着いて進められます。

順番

基礎編の演習1と2だけでも、対話の型は掴めます。時間が取れない場合はここだけ先にやって、カスタム指示 (演習3) を設定してから日常業務に戻る、という進め方でも十分に元は取れます。応用編は基礎編を前提にしているので、演習1から順に。

詰まったときの対処

期待と違う結果が出たら、指示を書き直すのではなく、条件を1つずつ足していきます。一度に全部を言い直すと、何が効いたのか分からなくなります。それでも噛み合わないときは新しいスレッドを開き直すのが早いです。長いスレッドでは前半の文脈が悪さをすることがあります。

もっと詳しく知りたい方へ

ワークショップ資料は2時間で完走することを優先しているので、機能の細部までは踏み込んでいません。それぞれ検証記事を書いているので、気になったところから読んでみてください。

特に演習A・Bで作った一時ビューのパイプラインは、第2弾でSDPに載せ替えるところまでやっています。ワークショップの続きとしてはここが自然な次の一歩です。

まとめ

ワークショップ資料を公開するにあたって、あらためて整理したことをまとめます。

  • 基礎編は座学15分、応用編は座学5分。コーディングエージェントは説明よりも手を動かした方が早く分かる
  • 全演習を貫くのは「@ で文脈を渡す」「小分けに依頼する」「承認前に生成コードを読む」の3つだけ
  • 応用編の演習A・Bは一時ビューで完結するので、書き込み権限がなくても試せる
  • 演習Bの答え合わせができるよう、演習Aで汚れたデータを意図的に仕込む設計にしている
  • 編集したスキルは開いているチャットには反映されない。新しいスレッドを開く
  • スケジュール実行は自動承認が常にオン。実行権限は作成者のもの
  • カスタム指示はユーザー / ワークスペース / プロジェクトの3階層。チームの規約はワークスペース以上に置く

資料を作っていて一番考えたのは、演習の分量ではなく順番でした。エージェントを使い始めた人が最初につまずくのは機能の多さではなく、「どこまで任せて、どこから自分で読むか」の線引きです。演習2でわざとエラーを出して修正を読ませているのも、演習Aで「まだ実行せずコードを見せて」を毎回付けさせているのも、その線引きを手で覚えてもらうためのものです。使い方をきちんと理解していれば、しっかり使い物になるツールだと思っています。

参考リンク

はじめてのDatabricks

はじめてのDatabricks

Databricks無料トライアル

Databricks無料トライアル

3
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?