LOTUS v1.2.3のagentic map-reduce入門

大量のテキストやコードをLLMで処理するとき、行ごとにプロンプトを書くループはすぐにコストと品質の両方で限界に当たります。Stanford大学とUC Berkeleyが開発するオープンソースのLOTUSは、宣言的なセマンティックオペレーターでこの課題に正面から取り組んでいます。2026年7月2日にリリースされたv1.2.3では、agentic map-reduceが追加され、ツールを使えるエージェントを並列実行して結果を集約するパターンが公式APIになりました。

この記事では、開発者のLiana Patel氏がXで紹介した新機能の位置づけと、LOTUS全体の設計思想を整理します。

この記事でわかること

• LOTUS v1.2.3で追加されたagentic map-reduceの役割
• フィルタ・結合・ソートなどセマンティックオペレーター群の全体像
• agentic map-reduceの4段階パイプライン（Plan・Shard・Map・Reduce）
• 通常のsem_filterなどとの使い分け

v1.2.3で何が変わったか

https://github.com/lotus-data/lotus

LOTUS v1.2.3は2026年7月2日に公開され、リリースノートには「Agentic map-reduce（Corpus + tools/REPL）、ドキュメント、README刷新」と記載されています。Pull Request #264で@liana313氏が実装し、Pythonパッケージlotus-aiとしてpip install lotus-aiで導入できます。

Liana Patel氏は同日のX投稿で、agentic map-reduceを「非常に強力なパターン」と評価しつつ、それはフィルタ・結合・ソートなど宣言的LLMオペレーター群の一例に過ぎないと述べています。大量データセットに対するLLMベースのバルク処理を改善するための枠組みとして、LOTUSのオープンソース実装を紹介する内容でした。

READMEも刷新され、プロジェクトのキャッチコピーは「エージェントとLLMでデータセットを大規模に処理し、精度を上げつつコストを下げる」方向に更新されています。v1.2.3以前からあったセマンティックオペレーターの思想はそのままに、エージェントとツール呼び出しを組み込んだ新しい実行パターンが前面に出たリリースです。

大量データをLLMで処理する際の課題

非構造化テキストを含むデータセットに対して、開発者がよく直面するのは次の2点です。1行あたり1回のLLM呼び出しでは、計算やファイル解析など「推論だけでは足りない作業」を任せられない。数千〜数万行に及ぶと、APIコストとレイテンシが実用の壁になります。

従来のLOTUSは、自然言語で条件を書くだけでフィルタ・マップ・結合・集約・ソートを行うセマンティックオペレーター（sem_filter、sem_map、sem_join、sem_agg、sem_topkなど）を提供してきました。これらはリレーショナルデータベースの演算子を、LLMが解釈する自然言語パラメータ付きの変換として拡張したものです。研究論文では、セマンティックフィルタや結合の最適化により最大1000倍の高速化と、ゴールドアルゴリズムに対する統計的精度保証が報告されています（参考）。

一方で、行ごとにPythonコードを実行して検証したり、ファイルを読み込んで解析したりするタスクには、単純な1回呼び出し型のオペレーターでは不足があります。agentic map-reduceは、そのギャップを埋めるために追加されました。

agentic map-reduceの仕組み

https://lotus-ai.readthedocs.io/en/latest/agentic_map_reduce.html

agentic map-reduceは、コーパス（文書リスト、ファイル群、DataFrame、長文テキスト）と自然言語のタスクを渡すと、LOTUSが処理を分割し、シャードごとにツールを使えるエージェントを並列起動し、最終的に1つの回答へ集約します。公式ドキュメントでは4段階のパイプラインとして説明されています。

Plan（計画） — タスク文から、シャードごとのmap指示、reduce指示、分割方法をプランナーが導出します。開発者はmapやreduceを個別に上書きできます。

Shard（分割） — コーパスを上限付きのバッチに分割します。Corpus.from_documentsでインライン文書、Corpus.from_filesでファイルやglob、Corpus.from_dataframeで表形式データ、Corpus.from_textで長文のチャンク分割に対応します。

Map（並列実行） — シャードごとに1エージェントが並列動作します。各エージェントは自分のシャードだけを見ながら、サンドボックス化されたPython REPLなどのツールをループで呼び出し、所見（finding）を出力します。

Reduce（集約） — シャードごとの所見を1つの結果にまとめます。リデューサーも同じツールにアクセスできるため、数値集計など決定論的な処理をLLMの手作業推測に頼らず実行できます。

READMEのクイックスタート例では、わざとバグを含むPython関数のリストをコーパスにし、「各関数をテストしてバグと反例を報告せよ」というタスクをagentic_map_reduceに渡しています。エージェントがREPL上で実際に関数を実行し、LOTUSが結果を1本のバグレポートに集約する流れです。コードベース全体のセキュリティスイープやマイグレーション調査など、幅（breadth）に分解できるタスク向けと公式ドキュメントは位置づけています。

セマンティックオペレーター群の全体像

https://lotus-ai.readthedocs.io/en/latest/core_concepts.html

agentic map-reduceはLOTUSの機能の一部です。中核はセマンティックオペレーターと呼ばれる宣言的変換で、自然言語の式（langex）をパラメータに取ります。主要なオペレーターは次のとおりです。

これらはPandas風のDataFrame APIでチェーンでき、LazyFrame APIを使えば実行前にパイプライン全体を最適化できます。クエリエンジンは安価なpandasフィルタを高コストなセマンティックフィルタより前に押し下げたり、モデルカスケードで簡単な行を小さいモデルに任せたりします。RAG、文書抽出、LLM-as-judge評価、エージェントログの失敗分析など、既存のAIパイプラインを数行の宣言で表現できる設計です。

使い方の要点

最小構成は次の3要素です。LLMの設定（lotus.settings.configureでモデルを指定）、コーパスの用意、自然言語タスクとツールリストの指定です。

import lotus
from lotus.models import LM
from lotus.tools import PythonREPLTool

lotus.settings.configure(lm=LM(model="gpt-4o-mini"))
corpus = lotus.Corpus.from_documents(["doc one", "doc two"])
result = corpus.agentic_map_reduce(
    task="各文書の要点を抽出し、全体を要約する",
    tools=[PythonREPLTool()],
)
print(result.output)

agentic_map_reduceの戻り値はResultオブジェクトで、output（最終回答）、findings（シャードごとの中間結果）、plan（導出されたmap/reduce/分割設定）、usage（トークン使用量）を参照できます。並列度はmax_parallelism、エージェントあたりのツール呼び出し上限はmax_steps（デフォルト6）で調整します。Python REPLはローカルサブプロセスのサンドボックスがデフォルトで、Dockerサンドボックスへの切り替えも可能です。

対応モデルはLiteLLM経由で、OpenAI・Anthropic・Googleなど複数プロバイダーを利用できます。APIキーは環境変数（例：OPENAI_API_KEY）で渡す想定です。

通常のセマンティックオペレーターとの違い

使い分けの基準はシンプルです。各行への単一LLM呼び出しで足りる処理はsem_filterやsem_mapを使います。行ごとにコード実行・ファイル読み込み・複数ステップの推論が必要で、最後に全体を1つにまとめたい場合はagentic map-reduceを選びます。

公式ドキュメントは、agentic map-reduceを「読み取り・計算のみのファンアウト向け」と明記しています。深い単一判断が中心のタスクは、1回のオペレーター呼び出しの方が適切です。逆に、リポジトリ内の全ファイルを走査して脆弱性を洗い出す、大量の経費レポートから正確な合計を計算する、といったタスクでは、並列エージェント＋REPL＋reduceの組み合わせが威力を発揮します。

LazyFrameで組んだセマンティックパイプラインとagentic map-reduceは補完関係にあります。前者は表形式データの宣言的クエリ、後者はコーパス全体に対するエージェント並列処理という棲み分けです。実務では、まずsem_filterで対象を絞り、残ったコーパスにagentic map-reduceをかける、といった段階的な構成も自然です。

今後の展望

LOTUSはDiscordコミュニティやColabチュートリアルで普及を進めており、VibeCheckやDeepScholarなど関連プロジェクトでもセマンティックオペレーターが使われています。v1.2.3はエージェント時代のバルク処理を公式APIに取り込んだ節目であり、宣言的オペレーター群の中にagentic map-reduceが加わったことで、フィルタ・結合・ソートからエージェント並列実行までを一つのクエリエンジンで扱える枠組みがより明確になりました。大量データをLLMで扱うバッチ処理やデータ変換の現場では、ループとプロンプトの手書きからLOTUSの宣言的APIへの移行を検討する価値があります。