MMF AgentをGenie Codeで動かしてみた

Posted at 2026-07-28

はじめに

Databricksの予測ソリューションアクセラレータであるMany Model Forecasting (MMF) に、AIコーディングアシスタント向けのスキルセット「MMF Agent」が追加されています。2026年3月に導入され、6月には階層整合のスキルが追加されました。

ブログの主張はシンプルで、「MMFは強力だが専門家向けのツールに留まっていた。障壁はフレームワークそのものではなく、セットアップ・コンピュート設定・評価設計・結果解釈に必要な知識の深さだった」というものです。その障壁をエージェントで下げる、と。

Databricks Free EditionでGenie Codeから動かしてみました。結論から言うと導入で2箇所ハマり、Skill 1は完走、Skill 3以降はFree Editionの制約で到達できませんでした。ハマった箇所と、Skill 1で見えたエージェントの振る舞いを書いていきます。

MMF AgentはMarkdownの手順書である

まず正体の話をします。MMF Agentは独立した製品ではなく、AIコーディングアシスタントに読ませるMarkdownファイルとノートブックテンプレートの集合です。Anthropicが提唱したAgent Skills形式に準拠しているので、Genie Code専用ではなく、Claude Code・Cursor・GitHub Copilot・Gemini CLIでも動きます。

スキルは5段階 + オプション1つの構成です。

スキル	コマンド	内容
1	`/prep-and-clean-data`	テーブル探索、列マッピング、欠損補完と異常値処理
2	`/profile-and-classify-series`	統計的プロファイリング、予測可能性による系列分類、モデル推奨
3	`/provision-forecasting-resources`	モデル選択とCPU/GPUクラスタの構成
4	`/execute-mmf-forecast`	ノートブック生成、モデルクラスごとのジョブ並列実行
5	`/post-process-and-evaluate`	系列ごとのベストモデル選択、評価サマリー
6	`/hierarchical-reconciliation`	階層整合 (2026年6月追加)

各スキルはSTOPゲートでユーザーに判断を求める対話型ワークフローとして設計されています。実行してみると、この「ゲート」が想像以上に丁寧に作り込まれていました。

Genie Codeへの導入でハマった2箇所

install.pyはGenie Code用ではない

リポジトリの skills/ 直下に install.py があります。最初これを使うものだと思いましたが、違いました。これはClaude Code・Cursor・Gemini CLI・Copilot向けに、ローカルプロジェクトへスキルを展開するためのスクリプトです。Genie Codeはワークスペースファイルからスキルを読むので、別経路になります。

READMEにも「Option A — Databricks Genie Code」「Option B — Claude Code, Cursor, GitHub Copilot, Gemini CLI」と分けて書かれています。Option BのほうにCLIコマンドが並んでいるので、流し読みすると混ざります。

スキルはスキル名のサブフォルダに置く

ここが一番のハマりどころです。

READMEのOption Aには、skills/databricks-skills/many-model-forecasting/ の中身を /Workspace/Users/{user}/.assistant/skills/ に直接置くよう書かれています。つまり .assistant/skills/SKILL.md という配置です。

そのとおりに置いて /prep-and-clean-data を実行したところ、「スキルの読み込みに失敗しました」と赤いバツが出ました。エージェントの思考ログを開くと、readSkillFile ツールが skills/{skill-name}/{file}.md という形式のパスを期待していることが分かります。{skill-name} の階層がないので解決できていません。

面白いのは、この後エージェントが自力でGit folderのリポジトリを探しに行き、SKILL.md を見つけて読み直したことです。結果的にワークフローは進みました。ただしログには「got the SKILL.md file but it was truncated」とあり、不完全なコンテキストで動いていました。

Genie Codeの公式ドキュメントを見ると、「各スキルはそれぞれ専用のフォルダを持つ必要がある」と明記されています。こちらに従って .assistant/skills/many-model-forecasting/ に置き直すと、初回で正しく解決されました。

「many-model-forecastingスキルを読み込みました」というスキル名つきのステップが出ています。直下配置のときはこの表示がなく、ただのファイル読み取りとして扱われていました。Genie Codeがスキルとして認識しているかどうかの見分け方として使えます。

READMEと公式ドキュメントで記述が食い違っている状態ですが、サブフォルダ方式のほうが確実です。

.assistant_instructions.md は1ファイルなので上書きされる

もう1つ、こちらは事故りました。

MMF Agentは .assistant_instructions.md というエージェント指示ファイルもユーザーフォルダのルートに置きます。スキルはフォルダ単位なので既存のスキルと共存しますが、この指示ファイルは1ファイルです。何も考えずにコピーすると、既存のカスタム指示が消えます。

消しました。幸いワークスペースファイルにはバージョン履歴が残るので、ファイルを開いて履歴から復元できました。同じことをやりそうな方は、コピー前にバックアップを取ってください。

導入スクリプト

Git folderでリポジトリをクローンしておけば、CLIもダウンロードも不要です。サーバーレスノートブックで1セル実行するだけで終わります。

import os, shutil

ctx = dbutils.notebook.entry_point.getDbutils().notebook().getContext()
user = ctx.userName().get()
home = f"/Workspace/Users/{user}"

src = f"{home}/many-model-forecasting/skills"
skill_src = f"{src}/databricks-skills/many-model-forecasting"
skill_dst = f"{home}/.assistant/skills/many-model-forecasting"
inst_dst = f"{home}/.assistant_instructions.md"

# スキル本体をスキル名のサブフォルダに配置 (他のスキルには影響しない)
os.makedirs(skill_dst, exist_ok=True)
shutil.copytree(skill_src, skill_dst, dirs_exist_ok=True)

# エージェント指示は上書きせず追記する
MARKER = "<!-- mmf-agent -->"
mmf_inst = open(f"{src}/assistant_instructions.md").read()
existing = open(inst_dst).read() if os.path.exists(inst_dst) else ""

if MARKER in existing:
    print("既に追記済みです。スキップしました。")
else:
    if existing:
        shutil.copy(inst_dst, f"{inst_dst}.bak")
        print(f"backed up -> {inst_dst}.bak")
    with open(inst_dst, "w") as f:
        f.write(existing.rstrip() + f"\n\n{MARKER}\n\n" + mmf_inst)

print("skills/:", sorted(os.listdir(f"{home}/.assistant/skills")))
print("mmf/:", sorted(os.listdir(skill_dst)))

マーカーを入れているので再実行しても二重追記になりません。ユーザーフォルダのパスは dbutils から取れるのでハードコード不要です。

このあと .assistant_instructions.md の末尾にある ### User Context セクションに、ワークスペースURLとメールアドレスを書き込みます。値はこれで取れます。

print(user)
print(f"https://{ctx.browserHostName().get()}")

Genie Codeを開き直して「What skills do you have access to?」と聞き、Many-Model Forecastingスキルが返ってくれば導入完了です。

合成データを用意する

リポジトリには skills/synthetic_data_generation.ipynb が同梱されています。自前でデータを用意しなくても試せます。

サーバーレスコンピュートにアタッチして、ウィジェットでカタログとスキーマを指定して全セル実行します。今回はFree Editionなので workspace カタログに synthetic スキーマを作りました。

生成されるのは2テーブルです。

train — 学習データ。unique_id (STRING)、ds (DATE)、y (DOUBLE) に加えて静的特徴量と将来回帰変数
score — スコアリング用。将来日付の回帰変数のみ (y なし)

Skill 1を実行する

/prep-and-clean-data と打つとワークフローが始まります。

ゲート状態が毎ターン表示される

エージェントは応答のたびに、現在のゲート状態を1行で出してきます。

Gate state — Skill 1: [✓ 1.0a workspace.synthetic] [✓ 1.0b brief] [→ 1.0c folder] [ ] 1.5 [ ] 1.5a [?] 1.5b [?] 1.6a-null [?] 1.6b-ii [ ] 1.7b [ ] 1.8b [ ] 1.T

✓ が完了、→ が現在地、[ ] が未着手、[?] が条件次第で不要になるかもしれない項目です。実際に単変量モードを選んだ時点で、外生変数関連のゲートは [×] 1.5b N/A に変わりました。

長い対話でも今どこにいるかが分かるので、地味ですが効きます。

エージェントはユーザーの申告よりデータを信じる

ここが一番の発見でした。

Skill 1の序盤で「どのような予測問題を解決しようとしていますか」と聞かれます。合成データなので実際のビジネス文脈はなく、それらしい説明をでっち上げて渡しました。

店舗ごとの日次需要を予測し、在庫の補充計画に使います。
系列には週次と年次の季節性があり、比較的滑らかです。
予測期間は2週間先まで。外部説明変数は使わず、過去実績のみの単変量予測です。

エージェントはこれを受け取って進み、テーブルを実際に読んだ段階で矛盾を指摘してきました。

重要: データの実際の頻度は月次 (平均間隔30.5日) ですが、当初「日次需要」と説明されていました。

日次と申告したのに、実データの平均間隔は30.5日。月次でした。そのうえで「(a) 月次で進める、(b) 実際は日次として扱うべき、(c) ターゲット変数の変更、(d) テーブルの変更」という選択肢を出してきます。

さらに次のゲートでも同じことが起きました。

当初の予測問題の概要では「外部説明変数は使わず、過去実績のみの単変量予測」と記載されていましたが、データには共変量が含まれています。

static_category、static_region、static_color の静的特徴量3つと、future_planned_price 以下6つの将来回帰変数が見つかっています。しかも score テーブルに将来分のデータまで存在することまで確認済みでした。

2連続で私の申告が否定されました。適当なブリーフを渡した私が悪いのですが、ユーザーの自己申告を鵜呑みにせず、実データと突き合わせて矛盾を提示するという設計が明確に出ています。ゲート状態の [?] は、この突き合わせが済んでいない項目を管理するための記号でした。

エージェントに手順を任せるとき、一番怖いのは間違った前提のまま最後まで走られることです。この検証ゲートは、その事故を構造的に防ぎにいっています。

判断は返してくる

欠損値と異常値の処理では、統計量を出したうえで選択肢を提示してきます。

欠損は63系列 (全体の6.3%)、系列あたり平均0.305ヶ月。異常値はIQR法で上振れ429観測 (0.72%)、下振れ81観測 (0.14%)、合計0.86%。

そのうえで、欠損補完は線形補間・ゼロ埋め・前方埋め・後方埋め・平均値補完・除外・そのまま、の7択。異常値はIQRキャッピング・3×IQRキャッピング・ログ変換・除外・そのまま、の5択です。

注目したいのは、エージェントが選択肢に順位をつけないことです。線形補間には「滑らかな季節性を持つ系列に適しています」という注記がつきますが、「これを推奨します」とは言いません。異常値については「プロモーションや特別なイベントによる真の需要増減である可能性もあります」と、判断に必要な視点だけを添えてきます。

欠損をどう埋めるべきかは、本来「なぜ欠損したか」で決まります。POSデータで売上がゼロだったのならゼロ埋め、システム障害で記録が飛んだのなら補間。その理由はデータの中にはなく、ドメイン知識の側にあります。エージェントは判断材料を揃えて返し、決定は人間に残す。ここは意図的な設計だと思います。

今回は線形補間と「異常値はそのまま保持」を選びました。

Skill 1の成果物

最後に完了サマリーが出ます。

テーブル mmf_test_train_data — 59,995行、1,000系列、2021-08-31〜2026-07-31の月次
欠損値なし (307行が線形補間で追加)
MLflow実験パスとノートブック保存先も自動で決定

生成物にはユースケース名 (今回は mmf_test) がプレフィックスとして付きます。同じカタログ・スキーマで複数の予測プロジェクトを並走させられる設計です。

Free Editionではどこまで動くか

Skill 1が終わった時点で、エージェントのほうから環境制約の確認が来ました。

標準的なMMFワークフロー (Skill 3以降) は、複数のジョブクラスタ (CPU、GPU) を作成して並列実行するアーキテクチャです。Free Edition環境では、この標準フローを続行できません。

そのうえで3つの選択肢を出してきます。

Skill 2 (系列プロファイリング) のみ実行 — サーバーレスで可能、1,000系列で15〜45分の見積もり
サーバーレス上で統計モデルのみ直接実行 — 標準のジョブアーキテクチャを使わない
一旦終了し、クラスタが使える環境でSkill 3から再開 — mmf_test_train_data は保持される

行き止まりを報告するだけでなく、成果物が保持されることまで含めて再開プランを提示してくるのは丁寧です。今回は3つ目を選んで区切りました。

Free Editionでの到達点を整理すると、こうなります。

スキル	Free Edition	理由
1 データ準備	完走できる	サーバーレスで完結
2 系列プロファイリング	実行できる	サーバーレスで動く設計
3 リソースプロビジョニング	不可	カスタムコンピュート構成が使えない
4 予測実行	不可	モデルクラスごとのジョブ並列実行が前提
5 後処理と評価	4が前提	—
6 階層整合	不可	クラシックコンピュートが必要

Databricks Free Editionの制限事項

サーバーレスのみ、GPUなし、という制約がそのまま効いてきます。MMF自体は2026年5月からローカル・グローバル・基盤モデルの全モデルクラスがサーバーレスで動くようになっていますが、MMF Agentの標準ワークフローはジョブクラスタを前提に組まれているため、そこで止まります。

まとめ

MMF AgentをGenie Codeで動かして分かったことをまとめます。

MMF Agentは製品ではなくMarkdownの手順書とノートブックテンプレートの集合。Agent Skills形式なのでGenie Code以外でも動く
スキルは .assistant/skills/{スキル名}/ のサブフォルダに置く。README記載の直下配置だと初回のスキル解決に失敗する
install.py はGenie Code用ではなくClaude Code・Cursor・Copilot・Gemini CLI向け
.assistant_instructions.md は1ファイルなので、既存のカスタム指示があると上書きで消える。バックアップか追記で対応する
Git folderでクローン済みなら、CLIもダウンロードも不要でノートブック1セルで導入できる
ゲート状態が毎ターン表示され、条件次第で不要になる項目は [?] で管理される
エージェントはユーザーの申告よりデータを信じる。頻度と外生変数の有無について、申告との矛盾を2回とも検出してきた
選択肢は提示するが順位はつけない。判断はドメイン知識の側に残す設計
環境制約を伝えると、後続への影響を先回りして予告し、行き止まりでも再開プランを出してくる
Free EditionではSkill 1と2まで。Skill 3以降はクラスタ作成が必要

一番の収穫は、私が適当に書いたブリーフをエージェントが2回とも突き返してきたことでした。エージェントに手順を委ねるときに怖いのは、間違った前提のまま滑らかに最後まで走られることです。MMF Agentはそこにゲートを置いて、データと突き合わせてから進む構造になっていました。実際に手を動かして確かめないと分からない部分だったので、Free Editionでも試した価値はあったと思います。

Skill 3以降は有償版のワークスペースで改めて動かして、別記事にまとめる予定です。