Databricks Data + AI Summit 2026 最速レポート Day1
LT紹介｜汎用モデルの先へ━成果から継続的に学ぶ「クローズドループLLMシステム」
目次
こんにちは。ちゅらデータの宮城です。
本稿では、現在開催中のDatabricks Data + AI Summit 2026のDay1 Lightning Talkから、特に印象に残ったRevamp AI社 Co-founder & President Xinchi Qi氏のセッション「Beyond Frontier Models: Building Closed-Loop LLM Systems That Learn from Outcomes」を速報レポートとしてお届けします。
※英語のヒアリングをもとにしているため、細部の表現に誤りがあるかもしれませんので、その点ご容赦いただけますと幸いです。
前提として、Data + AI Summitは6月15日〜18日、米国・サンフランシスコ Moscone Center にて開催中。今年のキーノートテーマは、 “What’s next in AI” で、Databricks共同創業者陣に加え、Microsoft の Satya Nadella氏（fireside chat）、Greg Brockman氏、Magesh Bagavathi氏らが登壇予定です（参考: Databricks 公式プレスリリース / Summit 公式ページ）。
本稿はDay2の朝に執筆しています。Ali Ghodsi氏らによるメインキーノートを控えているタイミングです。
セッション概要
- ・セッション名：
Beyond Frontier Models: Building Closed-Loop LLM Systems That Learn from Outcomes - ・日時：
2026年6月15日（月） 3:40 PM – 4:00 PM (PDT) - ・会場：
West, Level 1, Theater 8 - ・形式：
Lightning Talk（対象レベル：Advanced） - ・トラック：
Artificial Intelligence & Agents - ・関連技術：
MLflow (OSS), Mosaic AI, Unity Catalog, Lakehouse Monitoring, Inference Tables, AI Gateway（セッション内で参照） - ・スピーカー：
Xinchi Qi氏（Revamp AI 社 Co-founder & President）
なぜ今、フロンティアモデル（汎用 API）のままではダメなのか
ChatGPT をはじめとする大規模なフロンティアモデルの進化は目覚ましく、「とりあえず APIを呼べば、賢い答えが返ってくる」状況が当たり前になりつつあります。
しかし本セッションでは、本番環境のビジネスアプリケーションにおいて外部モデルに依存し続けることには明確な構造的リスクがある、と指摘されました。
コントロールの喪失
フロンティアモデル（私たちの呼び方では“基盤モデル／ファンデーションモデル”）を外部APIとして利用する設計には、ベンダー側の判断で課金体系が変わる、知らないうちに裏側のモデルが差し替えられて、昨日まで動いていたプロンプトの挙動が変わる、といったリスクが伴います。
“The systems are controlled to ensure that no one can … impose excessive costs overnight, or swap the model underneath us and change how our product behaves.”
訳：システムは、誰もコストを過剰に押し付けたり、私たちの足元でモデルを差し替えて製品の挙動を変えたりできないようにコントロールされている。
Revamp AI社のチームは「自分たちでモデルを学習させ、運用し、所有する（we train them, we run them, and we own them）」というスタンスをとっていて、これによって誰かに勝手に挙動を変えられない構成を維持している、と説明されました。
“We don’t send the customer context to a frontier model and hope it gives us the right answer.”
訳：私たちは、顧客のコンテキストをフロンティアモデルに送信して、正しい答えが返ってくることを期待するようなアプローチはしない。
個人的にもここは強く共感します。
「API の挙動が突然変わる」「料金が予告なく動く」というリスクは、私の経験上、本番運用に入った瞬間に現実の課題として浮かんでくるな、というのが正直な実感です。
聴きながら個人的にもう1つ感じていたのは、この“コントロールの喪失”には実は「価格」も含まれるのではないか、ということでした。
今のLLM APIの単価は、複数のプロバイダーが熾烈なシェア争いを繰り広げている“戦国時代”の中で、市場拡大を優先した、ある意味赤字覚悟で攻めの価格水準になっている部分があるのではないかと、個人的には見ています。
この競争が一段落すれば、プロバイダー側は採算ラインに向けて価格を引き上げてくる可能性があります。足元の状況を見ても、電力・データセンターのキャパシティ問題、GPU調達コストの上昇など、供給側のコスト圧力は日々増す一方だと感じています。
これらを踏まえると、今のAPIレートがそのまま長期的に維持される前提でアーキテクチャを組むのは、個人的にはやや危ういのではないかな、と感じているところです。本セッションで指摘された「裏でモデルが差し替わる」というリスクに加えて、私個人としては「値付けが上振れする」ことも、外部依存のリスクとして同じ棚に置いて考えたい—と本セッションを聞きながら感じました。
文脈の忘却
フロンティアモデルへの1コールは、その場では「素晴らしい答え」を返してくれます。しかしモデル自身がそのやり取りから学び、明日の自分に蓄積していくことはありません。
“You make a call, and it gives you a decent answer or a great answer. And then it forgets it completely.”
訳：APIをコールすると、まずまずの答え、あるいは素晴らしい答えが返ってくる。そして、その内容を完全に忘れる。
つまり、いくら呼び出しても「組織にとっての知見の堀（moat）」にはなりにくいということです。
“Rent a generalist, or build a moat. One is rented. The other is owned.”
訳：汎用モデルを“借りる”のか、自分たちの堀を“築く”のか。前者は借り物、後者は自分たちの所有物だ。
「カスタマーツイン」とクローズドループ
Revamp AI社が提示するのは、「企業の顧客一人ひとりに対して、その顧客に特化したオープンウェイトモデル群（カスタマーツイン）を構築する」というアプローチです（baseモデル＋顧客固有 adapterなのか丸ごと別モデルなのか、実装の詳細は本セッションでの説明はありませんでした）。
このカスタマーツインは、以下の3ステップから成るクローズドループ（Specialize → Measure → Improve） によって自律的に進化します。
- 1．Specialize（専門特化）
オープンウェイトモデルをベースに、その顧客固有の履歴データを学習させます。「メールを開く時間帯」「割引への反応度」「気にする理由がある時だけ動く」といった個人レベルの行動パターンを取り込み、平均ではなく一人にフィットさせるのがポイントです。 - 2．Measure（現実の成果で測定）
ここが本セッションのなかで個人的に最も興味深かったポイントです。
LLM の出力評価を「もっともらしい文章か」という指標ではなく、「顧客が実際に YES / NO で反応したか」というビジネス KPI（コンバージョン）で直接スコアリングする、という設計です。
“Every message is an experiment. The conversion is the label.”
訳：送信されるメッセージの1通 1通が“実験”であり、コンバージョンこそが“ラベル”だ。
つまり、送られた1通1通のメッセージそのものが実験であり、コンバージョンが教師ラベルになる、という考え方です。本セッションでは後の数字でも、「40% better open rate ではなく、40% more people actually buying」という形で、評価軸を開封率ではなく実購入に置いていることが強調されていました。 - 3． Improve（継続的な学習）
計測された成果シグナルは、そのまま次バージョンのカスタマーツインの学習材料になります。
結果、運用すればするほど「今朝より、明日が賢くなる」ループが成立する仕組みだと語られていました。
“You can ship something today. It’s already better than it was this morning. It will be better again tomorrow.”
訳：今日リリースできるものがある。それは今朝よりすでに賢くなっている。そして明日にはさらに賢くなる。
進化のスピードを自分たちで握っている、という意味で、これは「新しいフロンティアモデルのリリースを待つ」運用とは時間軸の主導権が、まったく逆になります。
ガードレールの設置（Specialize / Measure / Improve の 3 ステップを包む安全機構）
本セッションでは、評価機構によって悪い出力を本番投入前に検出する仕組み（“our evaluations catch the bad outputs before they ever launch”）に加え、システムが不確実な判断をしたり、顧客が設定した境界線を超えそうになったりした場合には安全側へフォールバックする設計が本番に組み込まれている、と説明されていました。
ここまで聴きながら感じていたのは、現時点で「自社で学習・運用・保有するモデル群を、顧客ごとに持ちましょう」と提案するのは、多くのお客さまにとってまだハードルが高いのではないか、ということでした。
当面の現実解としては、SLM（Small Language Model）と既存フロンティアモデルを組み合わせるハイブリッド構成 —軽量タスクは SLM／自社モデルで、重い推論はフロンティアに任せる——に落ち着いていくのではないかと個人的には見ています。
本セッションが描く 「Closed-loop ＋ 所有」の世界観は、その先に目指したい到達点として捉えています。
ビジネス成果として、人間のマーケター比で +40%、フロンティアモデル比で +15〜20%
ここまでだと、ややコンセプト寄りに聞こえるかもしれませんが、本セッションでは具体的な実成果の数字にも踏み込まれていました。
- ・vs 人間チーム：
プロのマーケターチーム（代理店）と直接対決し、実際の購入につながるコンバージョン数を約 +40% 改善。 - ・vs フロンティアモデル：
フロンティアモデルでコミュニケーションを生成する構成に対して +15〜20% のコンバージョン上振れ。 - ・コスト：
これらをフロンティアモデル運用と比べて、ごくわずかな実行コスト（a small fraction of the cost）で実現。
「特定の業種・特定の規模でだけ効くのでは？」と疑問を持ちましたが、本セッションでは「これは、何か特別な技術的ブレイクスルーで起きている話ではない」とのこと。
“This is not some new breakthrough stuff. Those copies of AI that exist today already have this data. They already have the model running in production, and they usually know what happens after the model acts. Those pieces usually do not talk to each other.”
訳：これは何か新しいブレイクスルーではない。今日すでに存在するAIシステムはデータを持ち、本番でモデルを動かし、その後に何が起きたかも把握している。問題は、それらのピースが互いに連携していないだけだ。
必要なのは革新的な技術ではなく、「すでに持っているピースをループとして閉じる」だけ、というメッセージです。
これまで業務で LLM / AIエージェントをいくつも構築してきた経験から言うと、この主張には強く共感しました。
+40%という数字そのものは業種や前提条件によって割り引いて見るべきだとは思いつつ、より響いたのは数字よりも構造の方です。
「成果ラベルで学習を回す」という設計は、PoC のフェーズでは差がつきにくくても、本番運用に入った途端に効いてくるのではないか、という肌感覚と一致するように感じました。
Databricksとの接続について
本セッションがData + AI Summitのステージで語られている理由がここに集約されます。
クローズドループの各ステップがDatabricksのプリミティブとそのまま対応しているからです。
Specialize & Measure（学習と評価）
- ・Fine-tune：
Mosaic AI 上でファインチューニング。レイクハウス自体が学習コーパスになる。 - ・評価：
MLflow Evaluation と Lakehouse Monitoring で“本番トラフィックそのもの”を評価対象に据える。
Improve & Govern（改善とガバナンス）
- ・ループの閉じ方：
Inference Tables（推論ログ）が、次バージョンの学習データセットそのものになる。 - ・ガバナンス：
Unity Catalog + AI Gateway により、ガードレールと監査ログを設計時から組み込む。
「AgentOps」や「LLMOps」といった概念が注目される中、Inference Tables → 再学習データ → Mosaic AIでファインチューニング → MLflow / Lakehouse Monitoring で本番評価 → Unity Catalog でガバナンス、という具体的なプリミティブ対応が示されたことで、「実装イメージとして何をどう繋ぐか」が大きく整理された印象です。
個人的に感じたのは、Inference Tables / MLflow Evaluation / Lakehouse Monitoringといったスタックは、“自社モデル所有派” のためだけのものではないのではないかという点です。
フロンティアモデルへの依存を残す設計を選ぶ場合でも、「裏側でモデルが差し替えられた瞬間に、AIエージェントの出力品質をどう担保するのか」という問いは避けられず、同様の評価／監視スタックが必要になると感じています。
もう1点、Mosaic AI上でファインチューニングできる、という点も気になったポイントでした。
発表のメッセージとしては「データは、既にレイクハウスに揃っている」というシンプルなものでしたが、実務でやってみるとファインチューニング用のデータセットを作るところがいちばん大変で、ラベル設計・サンプリング・PII の扱い・評価データとの分離など、“前処理側” にこそ重い意思決定があると感じています。
本セッションはLightning Talkという尺の都合もあり、ここまでは踏み込めなかったのが少し惜しく、別セッションやMosaic AI関連の発表でもう一歩深掘りした話を拾えたら、というのが正直な感想でした。
なお、Databricks公式が掲げる “AgentOps” フレームワーク（MLOps → LLMOps → AgentOps の進化と 4 つの設計意思決定）については、同じDay1でDatabricks Sr. Solutions ArchitectのPavithra Rao氏が “From MLOps to AgentOps: Shipping Autonomous Agents You Can Actually Trust” として整理しています。
詳しくはこちらのレポートをご参照ください。
本稿で紹介した Revamp AI社のClosed-loopは、その AgentOpsフレームワークを「実プロダクトとしてどう体現するか」の生きた実例として読むことができそうだ、と個人的には捉えています。
まとめ：AI運用の次フェーズは「Closed-loop / Governed / Outcome-driven」
本セッションの最後は、次のように締めくくられていました。
“Every serious LLM app will be closed-loop, governed, and outcome-driven.”
訳：数年後、本格的な LLM アプリは全てこうなる —Closed-loop（成果でループを閉じている）/ Governed（ガードレールと監査が設計時から入っている）/ Outcome-driven（評価指標が実ビジネス成果に直結している）
これまでのAI活用は「新モデルのリリースを待ち、それが課題を解決してくれることを期待する」という受動的なアプローチが中心でした。
本セッションが示した未来像は、「モデルを自社で所有し、日々のビジネス成果を燃料にして自律進化させる」という、完全にクローズドループ化されたAIシステム像です。
DatabricksのUnity Catalogやレイクハウスの仕組みは、こうした「ログや成果データを集約し、モデルへフィードバックするパイプライン（AgentOps）」を構築する上で、強力な基盤になると改めて実感したセッションでした。
今回のData + AI Summitで個人的に持ち帰りたいテーマも、ちょうどここに重なっているように感じています。
“モデルを所有するか、レンタルするか” という二項対立に留まらず、その中間にあるハイブリッド構成のもとで、品質担保・コスト管理・継続学習基盤をどこまでDatabricks上で具体化できるのか。残りの3日間は、Lakebase / Mosaic AI / Unity Catalog周辺のセッションを優先的に追いかけてみたいと思っています。
20分のLightning Talkにここまで濃密な思想・数字・本番運用の知見を詰め込んだプレゼンは、本番フェーズのLLM / AI エージェント運用に向き合う立場として、何度も頷きながら聴いた、本当に学びの多いセッションでした。
素晴らしい発表をありがとうございました。
このページをシェアする：
