エージェント

DatabricksがLakebase PostgresでAIエージェント運用を簡素化。KafkaやRedisなしの構成を提示

Databricksが、Lakebase Postgresを中心にAIエージェントの長時間タスクを動かす構成を発表しました。CLAとの文書処理事例をもとに、AIを試す段階から業務として回す段階への変化を示しています。

この記事の要点

  • DatabricksはLakebase PostgresをAIエージェントのオーケストレーション基盤として紹介しました。
  • CLAとの監査向け文書処理では、抽出時間を数時間から数分へ短縮したとしています。
  • 今回の発表には、料金や一般提供の開始日は書かれていません。

AIは回答から業務の流れへ進んでいる

Databricksが2026年7月22日、Lakebase Postgresを使ったAIエージェントの運用構成を発表しました。テーマは、AIに作業を頼んだ後の順番待ち、再実行、費用把握、進み具合をどう支えるかです。

これは派手な新モデルの発表ではありません。けれど、AIが会社の中で本当に働く時の土台に関わります。AIエージェントは、答える道具から作業を進める仕組みへ移っています。

今回の題材は、CLA(CliftonLarsonAllen LLP)との監査向け文書処理です。Databricks Forward Deployed Engineeringと共同で、文書から情報を抜き出すアプリを構築し本番化したと説明されています。

発表によると、このアプリは抽出時間を数時間から数分へ短縮しました。品質を犠牲にしなかったともDatabricksは書いています。ここでのポイントは、AIの賢さだけではありません。作業をさばく仕組みまで含めて作った点です。

Lakebase Postgresが順番待ちを持つ

AIエージェントの仕事は、1回で終わる質問応答とは違います。PDFを受け取り、文書を読み、モデルを呼び出し、結果を書き戻し、失敗したらやり直します。

この流れを担当する部分がオーケストレーション(複数の処理を順番に動かす制御)です。Databricksは、その中心にLakebase Postgresを置きました。

アプリ全体はDatabricks上に作られています。使われた主な部品は次の通りです。

・Lakebase Postgres

・Databricks Apps

・Lakeflow Jobs・MLflow・Unity Catalog Volumesが連携する構成です。文書はUnity Catalog Volumesに置かれ、依頼はLakebaseへ書き込まれます。AI Agents側はLakeflow Jobsで処理を実行します。結果はLakebaseへ戻されます。

外部の道具を減らす意味

Databricksの主張は明確です。今回の構成では、Kafka、Redis、Airflow、Temporal、専用キャッシュ層に頼らないとしています。外部システムを増やさず、Databricks内で仕事の列を扱う設計です。

これは非エンジニアにも大事な話です。AI導入では、モデルそのものよりも周辺の運用が重くなりがちです。道具が増えるほど、認証、監視、障害対応、費用管理も増えます。

Lakebaseの中には、tasksとtask_attemptsという2つのPostgresテーブルを置きます。tasksは作業の状態や結果を持ちます。task_attemptsは実行ごとのJob run ID、MLflow trace ID、費用メタデータを持ちます。

これにより、1つの作業が失敗して再実行されても、どの試行で何が起きたかを追えます。AIが仕事をするほど、結果だけでなく途中経過の記録が価値を持ちます。

発表で見える範囲

項目発表で書かれている内容
公開日2026年7月22日
題材CLAとの監査向け文書処理アプリ
効果抽出時間を数時間から数分へ短縮
料金今回の発表には書かれていません
提供時期今回の発表には書かれていません
対象条件今回の発表には書かれていません

料金や一般提供の開始日が書かれていない点は、読者にとって大切です。今回の記事は新しい価格プランの告知ではありません。技術構成と実例を見せる発表です。

ただし、Databricksの開発者向けページでは、同社が企業データの近くで低遅延アプリやエージェントを作る環境を掲げています。Agent Bricksでは、企業データ上でAIエージェントを構築、配備、オーケストレーションし、状態や記憶をLakebaseに保存すると説明しています。

仕事で響くのは見えない部分

AIが文書を読めることは、もう驚きにくくなりました。差が出るのは、何百件も来た時に止まらないことです。誰の依頼を先に処理するかも重要です。

今回の設計には、優先度付きの取り出し、リース(一定時間だけ作業を預ける仕組み)、レート制限に合わせた制御、同じ通知が来ても二重処理しない仕組みが入っています。難しく見えますが、要は仕事の渋滞を減らす工夫です。

運用画面も用意されています。タスク状態、入出力トークン、LLM費用、コンピュート費用、中央値の応答時間、信頼度を見られるとされています。状態変化はPostgres LISTEN/NOTIFYとSSE(サーバーから画面へ更新を送る仕組み)で届きます。

Databricksは、意味のある状態変化を約1秒で画面へ反映すると説明しています。さらに、SSEが使えない時のために既定10秒間隔のポーリング(定期的な取り直し)も残しています。

このニュースの核心は、AIエージェントを動かす現実味です。チャット画面の外側で、AIが書類を受け取り、待ち、やり直し、費用を残す。その裏側が整うほど、AIは実験室から職場へ近づきます。

出典
  • Databricks「Simplify AI agent orchestration with Lakebase Postgres」元記事へ
  • www.databricks.com「For App Developers」元記事へ
  • www.databricks.com「Databricks AI Research」元記事へ

最新のAIニュースを毎日追うなら

新モデル、料金、仕事への影響まで、働く人の目線で毎日1本にまとめています。