DatabricksのAIを役割で整理する：Genie、権限、メモリ、評価

仕事を決めてから、AIの役割を選ぶ

サポート担当者は「注文O-17は返品対象ですか。返信案も作ってください」と尋ねる。業務の分析担当者は「先月の注文のうち、返品された割合は」と尋ねる。開発者は、そのサポートアプリを作る。同じ注文データを扱っていても、必要な入力と権限は違う。データへの質問、業務を進めるエージェント、コードを書く支援を分けて選ぶ。

本章では、架空のサポート案件を使う。アプリは注文を読み、適用される規約を取得し、進行中の会話を再開して返信を下書きする。返品を提案することはできるが、返品の記録には別途認可された業務操作が必要になる。Databricks workspaceでは実行していない、独自の設計演習である。

図を横にスクロールして読む。

図は役割を説明するために独自に作成した。矢印は選んだアプリの依存関係を表し、Databricks内部の配置や自動接続を保証しない。図を原寸で開く。下段は別々に読む。会話の記録、業務の取引、評価のtraceは、それぞれ別の事実を示す。以下の表が図の内容に対応する。

Genieの三つの役割

2026年9月18日改訂のGenie公式文書は、三つの体験を区別している。

製品	利用者と用途	サポート事例での選択
Genie One	業務利用者が簡素な画面から、統制されたデータ資産を探して利用する	返品の傾向を質問し、dashboardを参照する
Genie Agents	データ担当者が、Genie Oneの回答に使う専門領域のdataset、信頼できるmetric、業務ルールを整える	対象の注文と「返品率」の定義を決める
Genie Code	workspace内の開発者や技術担当者が、コードやデータ作業の支援を受ける	サポートアプリのコードを作成・点検する

分析担当者には、返品率の分母が注文か明細か、どの日付で月を区切るかを確認する。SQLが正しく動いても、定義が違えば答えは違う。開発者には、生成されたコードの認可や再試行の挙動を確認する作業が残る。Genie Agentsは以前Genie Spacesと呼ばれていた。現在の設定手順は現行の名称で追う。

業務に必要なときに、エージェントを選ぶ

エージェント構築の概要は、Knowledge Assistant、Supervisor Agent、custom agentを区別する。Knowledge Assistantは専門知識に基づく支援に向く。SupervisorはGenie Agents、agent endpoint、Unity Catalog function、MCP server、custom agentを組み合わせて進行する。custom Python agentではアプリ固有の振る舞いを記述でき、MLflow tracingと統合できる。Agent Bricks CLIはBetaの作成・配置経路である。

サポート事例では、まず一つのエージェントと二つの役割から始める。注文を読むツールと、規約を取得するツールである。これは設計上の役割名であり、SDKのメソッド名ではない。専門化した部品を追加して合格条件が改善する場合にSupervisorを検討する。振り分けが増えると、根拠、実行主体、失敗の所在が失われる箇所も増える。一つのエージェントを比較対象として残し、複雑さに見合う効果を評価する。

歴史を見ると、評価を後付けにしない理由が分かる。2024年6月12日にPublic PreviewとなったMosaic AI Agent Frameworkは、構築、配置、tracing、評価を一緒に提供した。2026年9月16日のreleaseではmanaged memoryとsessionsがBetaとなり、9月29日にはAgent Bricks CLIがBetaになった。管理された状態保存はストレージを運用する仕事を減らす。一方、アプリの業務ルールと評価基準は作者が決める。

呼び出しごとに実行主体を追う

Unity Gatewayは、AIへの通信と登録されたserviceへのアクセスを統制する。その背後の資産を統制するのがUnity Catalogである。Gatewayがサポート業務の順序を決めたり、取引台帳になったりするわけではない。統制の対象は該当するserviceを経由する通信であり、アプリが使う別のデータ経路には、その経路の確認が必要になる。

実装前に、実行主体の対応表を作る。

境界	確認する問い	試す失敗
利用者 → アプリ	認証された誰が、どのtenantとして要求したか	identityがなければ状態を探す前に拒否する
エージェント → model service	誰のcredentialを提示しているか	モデル権限のないprincipalは問い合わせできない
エージェント → 注文取得	誰のデータ権限を適用するか	northの利用者にsouthの注文を返さない
エージェント → 状態ストア	誰がストアへ到達でき、actorを誰が選ぶか	モデルが指定したactorで取得先が変わらない
提案 → 業務書き込み	どの操作が適格性を確認して結果を記録するか	再送で返品が二重に作られない

画面へログインした利用者が、すべての処理を実行すると仮定しない。開発者向け概要にあるAppKitの例では、agentのモデル呼び出しはアプリのservice principalとして動く。組み込みagent routeのplugin toolは、ログイン利用者を代理して動く。HTTP requestの文脈を持たない単独のrunAgentでは、モデルとツールの両方がservice principalとして動く。これはそのAppKit経路の仕様であり、すべてのframeworkや配置先へ一般化できない。

Custom model serviceを作るには、配置するcatalog/schemaへのUSE CATALOG、USE SCHEMA、CREATE SERVICEに加え、宛先への権限が必要になる。対応regionとUnity Catalogの有効化も前提で、確認した文書ではAWS GovCloudは対象外だった。serviceを作る権限とアプリが問い合わせる権限は別に検討する。古い例のモデル名を写す前に、そのworkspaceで使えるモデルとendpointを確認する。

三種類の状態を分けて保存する

Managed sessionsは、一つのやり取りのJSON互換状態を保存する。典型的には、順序のあるmessageとtool resultである。serviceは内容を解釈せず、項目の順序を決定的に保つ。公式clientで会話を復元するとき、session.list_items(order_by="create_time asc")は時系列の昇順を指定する。既定は新しい項目からの順序である。「返品に成功した」という保存済み文章も、それ自体は会話内容にすぎない。

Managed memoryは、別の会話にも使う文脈を保存する。現在の検索仕様はBM25による全文検索の順位付けで、返せるのは上位100件まで。paginationとvector similarity searchには対応しない。冒頭の「semantic search」という説明から、embeddingを使った検索を保証していると読み広げない。

状態	架空の内容	演習で決める寿命と正本
Session	O-17への質問、規約取得の結果、返信案	この案件の再開に使う。文章を業務書き込みの証拠にしない
Memory	「短いメール返信を好む」	関連性と利用許可がある間だけ、別案件で再利用する
業務記録	返品request ID、order ID、適格性の判定、確定status	アプリがschemaとtransaction・再試行の契約を持つ

両方のmanaged機能はLakebaseを保存先とするBetaである。各ガイドは、preview中は背後のLakebase instanceが課金対象で、managed state自体の追加料金はないと説明する。価格は変わり得る。同じデータベース技術を使うことは、managed storeとアプリの業務記録を一つのatomic transactionで更新できる証拠にはならない。書き込みの契約はLakebaseの章で掘り下げる。

アクセス境界はストアにある

どちらのガイドも、actor_idを信頼できるアプリの文脈から設定するよう求める。actorはpartitionやgroupingのキーであり、アクセス制御の境界ではない。 Memoryの認可はストア単位であり、そのストアへ到達できるprincipalは、すべてのactorの項目を読み書きできる。厳密にtenantや利用者を分離する場合、ガイドはmemory storeを境界ごとに分けるとしている。Session storeもストア単位で認可する。actor_idとmetadataはgroupingやfilteringに使うが、アクセスを制限しない。ストアcredentialを持つ相手に、actor filterだけで保護できると約束してはいけない。

この設計では通常の取得に信頼できるtenant/user keyを使い、ストアへのgrantは別に点検する。必要な分離を満たすためにストアを分けるか、必要な認可モデルを持つ別の状態保存先を選ぶかを検討する。その判断には、ストアごとの課金と管理の負担も含める。Sessionまたはsession storeを削除してもmemoryは削除されない。両方のストアと業務記録を個別に把握した削除手順を設計する。

設定を変えて、影響を予測する

以下は未実行の設定検討表である。例の名称は架空で、既定値ではない。保持期間、モデル価格、遅延目標、accountの上限は、対象環境で確認するまで不明として残す。

設定・制御	意味と範囲	サポート設計での選択と予想する影響
Memoryのactor_idとstore grant	必須のactor keyは信頼できるコードが選ぶ。ストア権限がアクセス境界	memory toolを渡す前に呼び出し元へ結び付ける。actor filterとは別にgrantを試す
Memoryのsession_id、path、description	sessionとの関連付けは任意。pathは必須の整理キー、descriptionは検索に使う	/preferences/reply-style.mdへ長く使う好みだけを保存し、案件の会話はsessionsへ保存する
Sessionのsession_id	任意の呼び出し元指定ID。省略時はserviceが生成する	既知の案件に架空のcase-o17を使い、再開前に呼び出し元のアクセスを検証する
Model serviceの宛先	設定したmodel/providerへ推論を振り分ける	最初は許可された一つの宛先を使い、モデル変更時に同じ事例を再評価する
Budgetのaction	Send alertではアクセスが続き、Block usageでは範囲内の後続要求を止める	継続利用を止める必要があればblockを選ぶ。予算切れ時の画面も決める
Service policyのmodeとphase	制御するpolicyはON CALL/ON RESULTを調べる。Log modeは記録だけを行う	policyへ依存する前に、架空の禁止呼び出しで実際に制御されるか検証する

Service policiesはBetaで、grantを補完する。Grantは誰が呼べるか、policyはそのやり取りをどう進めるかを決める。ALLOW、DENY、ASKは、通過、遮断、承認待ちを表す。DENYでもHTTP 200を返し、databricks_service_policyに詳細を含める場合がある。そのためHTTP成功だけで業務操作を完了扱いにしない。制御するpolicyの評価エラーはdenyになり、Log modeでは制御しない。モデルを使うpolicy judgeの判定は非決定的で、評価モデルの使用量に応じて課金される。返品操作内の決定的な適格性検証も必要になる。

Gatewayのbudgetは、Gatewayを通る対象費用に適用される。Provisioned throughputとGatewayを通らない単独Model Serving通信は含まれず、外部provider費用の算入にはBetaの設定がある。Blockはほぼリアルタイムの推計で働く。実行中の要求は続くため、閾値は最終請求額の絶対上限ではない。外部費用の推計とproviderの請求書が違うこともある。Budgetのtag filterはmodel serviceのtagと照合し、request tagとは照合しない。本演習ではsupport projectのservice tagで範囲を決める。同じtagをrequestにだけ付けても、その予算範囲にはならない。

回答、操作、費用を一緒に評価する

評価の公式文書はevaluationとmonitoringを扱い、エージェントの概要はtrace、人のfeedback、品質、費用、遅延を結び付ける。Traceは、間違った規約の取得、意図しないprincipal、余分なモデル呼び出しの所在を探すのに使える。Traceがあることだけで業務の正しさは証明できない。

固定した架空のfixtureを用意する。O-17はtenant north、O-18はsouthの注文。規約は配達から30日以内の返品を許可し、呼び出し元はnorthの注文を読んで返信案を作成できる。30日は演習用に作ったルールである。配達日と要求日を明示し、人が適格性を判定できるようにする。矛盾する古い規約を一つ混ぜ、廃止済みと記す。一つのエージェントとSupervisorを比較するときは、文書、モデルID、指示、tool権限、dataset versionを固定する。

注文と規約が正しい回答の割合、引用が結論を支えるか、無権限の開示・書き込み件数、最初から最後までの遅延、モデルと評価モデルのtoken、検索回数、背後の状態ストア使用量を記録する。実際の請求情報が得られたら、正しく完了した許可済み案件一件あたりの費用に、通貨、課金日、除外項目を付ける。本章で遅延や費用の実測値は得ていない。遮断や未解決も結果として残し、流暢な文章をすべて完了に数えない。

オフライン失敗演習：実行前に証拠を決める

未実行の机上演習である。Credential、配置済みagent、live model call、顧客データは不要。箱を七つ以内にして構成を描き、tool callごとに実行するprincipalを記す。保存する各fieldを、session、再利用するmemory、業務状態に分けてから、次の表を埋める。

注入する失敗	アプリに期待する結果	将来の検証で残す証拠
northの利用者がO-18を尋ねる	注文を開示せず、無権限の取得を拒否する	認証された呼び出し元とtoolの拒否結果
promptが別actorのmemoryを要求する	信頼できるコードが決めたactorを上書きできない	実際に渡したactorと、別途行うstore grantの検証
新しい項目から会話を復元する	文脈として使う前に順序の誤りを検出する	順序付きitem IDと復元した会話
案件だけ削除しmemoryが残る	削除未完了として扱い、承認済みのmemory削除手順を進める	sessionとmemoryの個別inventory・結果
policyがHTTP 200とDENYを返す	遮断を表示し、返品成功を記録しない	構造化されたpolicy判定と業務記録の照会
承認済み返品の同じ要求を再送する	二重書き込みせず、既存要求の結果を確定する	アプリのrequest IDと正本にある確定結果
根拠取得がtimeoutする、またはbudgetが遮断する	根拠を取得できないことや予算切れを説明する	失敗した境界と案件の未解決status

別の読者が、各資産を誰が読めるか、どの状態が次の会話まで残るか、どの記録が返品を証明するか、途中で失敗したらどうなるかを説明できれば、設計レビューの合格条件を満たす。Genieで答える構成、文書assistant、custom workflowを同じ要件で比較する。Supervisorに評価できる利点がなければ、構成を増やさない。

Gatewayのrelease notesでは、GatewayのGAは2026年8月4日、管理APIとdeveloper toolsのGAは9月16日である。Service policies、agent services、unified trace table、外部モデル費用のbudget算入にはBetaの記述が残る。本章では2026年9月4日〜10月4日の直近一か月を調べた。段階的な提供は一週間以上かかる場合があるとrelease notesが説明している。親製品のGAから、個々の機能の状態や、そのaccountでの利用可否を推測しない。