datapizza-ai は何を薄くして、何を残したのか

datapizza-ai が削ろうとしている抽象化の層

README の冒頭には Less abstraction, more control という一文が置かれています。これは宣伝文句として読むより、設計方針の宣言として読んだほうが実用的です。多くの GenAI フレームワークは、プロンプト、チェーン、メモリ、ツール呼び出しを独自の抽象クラスで包み、利用者をその語彙に合わせさせます。datapizza-ai はその語彙を小さく保ち、Agent、Client、tool、Tracing という数個の登場人物で構成しようとしています。

対象読者は、RAG やエージェントを試作ではなく運用に載せようとしている Python エンジニアです。とくに、フレームワークの内部で何が起きているか分からなくなり、障害時にログを追えない状態を避けたい層を想定していると読めます。逆に、ノーコードに近い形でパイプラインを組みたい人や、多数のベンダー製コネクタをそのまま繋ぎたい人には、この薄さは作業量の増加として現れます。

Agent と tool デコレータの関係

中心にあるのは Agent クラスです。README の Quick Start では、Agent(name="assistant", client=client, tools=[get_weather]) のように名前、クライアント、ツール群を渡し、agent.run("What is the weather in Rome?") で実行します。戻り値は response.text として取り出します。

ツールは @tool デコレータを付けた通常の Python 関数です。get_weather(city: str) -> str のように型ヒント付きで書き、戻り値は文字列です。スキーマ定義用の別ファイルも、登録用のレジストリ関数も登場しません。関数のシグネチャがそのままツール定義になる、というのが README から読み取れる範囲の説明です。

マルチエージェントの例では planner_agent.can_call([weather_agent, web_search_agent]) という呼び出しで、あるエージェントから別のエージェントへ処理を委譲できると示されています。ここで注意したいのは、3 つのエージェントが同一の client インスタンスを共有している点です。モデルをエージェントごとに変えたい場合は、client を分けて渡す設計になるはずですが、README にはその明示的な例がありません。

プロバイダ差し替えは import の一行で済むのか

README は OpenAI、Google Gemini、Anthropic、Mistral、Azure をマルチプロバイダ対応として挙げています。コード例では from datapizza.clients.openai import OpenAIClient としており、クライアントはプロバイダごとのモジュールから個別に import する形です。

インストールも分割されています。コアは pip install datapizza-ai、プロバイダ別に pip install datapizza-ai-clients-openai、datapizza-ai-clients-google、datapizza-ai-clients-anthropic という名前が示されています。つまり差し替えは「設定ファイルの一行変更」ではなく、依存パッケージの追加と import 文の書き換えを伴います。ベンダー中立をうたうフレームワークとしては、この点はやや手作業寄りです。

ただし OpenAIClient(api_key="YOUR_API_KEY", model="gpt-4.1") のように model を引数で渡す形なので、モデル名の切り替え自体はクライアント生成時のパラメータで完結します。ビジネスロジック側にモデル名が散らばらない、という意味では素直な設計です。

ContextTracing が出力するスパンの粒度

可観測性はこのプロジェクトの売りの一つです。README では OpenTelemetry 準拠のトレース、クライアント入出力のトレース切り替え、カスタムスパンという 3 点が挙げられています。

使い方は with ContextTracing().trace("my_ai_operation"): で囲み、その中で agent.run() を呼ぶだけです。README に載っている出力例では、Total Spans が 3、Duration が 2.45s、そしてモデル名、Prompt Tokens、Completion Tokens、Cached Tokens が表形式で表示されます。トークン数がスパン単位で見えるため、どのステップでコンテキストが膨らんだかを追いやすい構造です。

ここで確認しておきたいのは、この表が ContextTracing の既定出力なのか、特定の設定を有効にした場合のものなのかが README からは判別できないことです。クライアント入出力のトレースは optional toggle と書かれているため、プロンプト本文をログに残す挙動は明示的に有効化する必要があると推測できますが、推測の域を出ません。本番導入前には、機密情報がスパン属性に乗らないかを自分の手で確認すべき領域です。

RAG 側の部品と、その組み合わせ方

ドキュメント処理まわりでは PDF、DOCX、画像のパースに Azure AI と Docling を使うと記載されています。チャンキングは context-aware な分割と埋め込み、リランキングは Cohere などのリランカーを追加して関連度を上げる、という構成です。

重要なのは、これらが単一のパイプラインクラスに押し込まれているのではなく、再利用可能なブロックとして提供され、宣言的な設定と上書きができると説明されている点です。裏を返せば、取り込みから検索までの流れは利用者が自分で配線する前提です。README の Document Ingestion の節は「パイプラインが PDF を自動でパースし、チャンクに分割し…」という説明の途中で切れているため、実際の API 名や設定キーはここからは分かりません。docs.datapizza.ai を参照する必要があります。

DuckDuckGo 検索ツールは本体と別パッケージで、pip install datapizza-ai-tools-duckduckgo としてインストールし、from datapizza.tools.duckduckgo import DuckDuckGoSearchTool で読み込みます。ツールが本体から分離されている方針は一貫しています。

向かないケースと、LangChain との距離

このフレームワークが向かないのは、既存の LangChain 資産を大量に持つチームです。LangChain はローダー、テキストスプリッタ、ベクトルストア連携、コールバック群を一つの語彙体系として提供します。datapizza-ai はその語彙を意図的に持たないため、同等の機能は個別パッケージか自前実装で埋めることになります。README は migration-friendly と述べていますが、移行用のアダプタや互換レイヤーの具体名は示されていません。

もう一つの制約はバージョンです。最新リリースが v0.1.0（2026-03-13）で、その前が v0.0.9、v0.0.7 と続きます。0.x 系である以上、マイナー更新で API が動く前提は置けません。実際 v0.0.7 から v0.0.9 までの間隔は約 1 週間で、この時期は API 表面が固まっていなかったと考えられます。v0.1.0 でどこが安定宣言されたのかは、リリースノートを読まないと判断できません。

サポート体制についても、README は Community セクションへのリンクを置くのみで、有償サポートや SLA には触れていません。業務クリティカルな用途では、この点が採用可否を左右します。

ライセンスと依存の管理コスト

ライセンスは MIT です。商用利用、改変、再配布が許される寛容な部類で、コピーレフトのような伝播条件は課されません。ただし MIT は無保証であり、不具合や仕様変更に対する責任を作者が負う義務はありません。0.x 系のフレームワークを業務に使う場合、この無保証という前提を自チームのリスクとして引き受けることになります。

依存の管理は分割パッケージ方式の影響を受けます。datapizza-ai 本体に加え、使うプロバイダごとに datapizza-ai-clients-* を、使うツールごとに datapizza-ai-tools-* を requirements に列挙する必要があります。プロバイダを 3 つ試すなら依存は 4 本以上に増えます。それぞれのバージョン整合を CI で固定しておかないと、クライアント側だけが上がって本体と噛み合わない、という事故が起きやすくなります。

なお、ここに書いたのは MIT ライセンスの一般的な性質であり、特定の利用形態に対する法的評価ではありません。社内規程に照らした判断は法務に確認してください。

試すなら最初に何を確かめるか

最初の一歩は pip install datapizza-ai と pip install datapizza-ai-clients-openai を同じ環境に入れ、README の 3 行のコードがそのまま動くかを確認することです。from datapizza.clients.openai import OpenAIClient の import が通れば、コアとプロバイダパッケージの分離方針が自分の環境で機能していることになります。

次に、@tool を付けた関数の戻り値が文字列以外だった場合にどう振る舞うかを試します。README の例はすべて文字列を返す関数なので、辞書や Pydantic モデルを返したときの扱いは記載がありません。ここが自分のユースケースで詰まるかどうかは、実際に動かさないと分かりません。

最後に ContextTracing().trace() の出力を、自前のスパンを 1 つ追加した状態で確認します。カスタムスパンが表に混ざるなら、ボトルネック特定の道具として使えます。混ざらない、あるいは出力形式が README の例と異なるなら、可観測性を採用理由にする根拠は弱くなります。README の出力例はあくまで一例であり、自分の環境で同じ形が出る保証はありません。

編集部の結論

採用を検討する価値があるのは、LLM 呼び出しの内訳を OpenTelemetry のスパンとして可視化したいチームと、OpenAI と Anthropic などを設定変更で切り替えたいチームです。逆に、LangChain の既存チェーンや豊富なローダー群に業務ロジックが依存している場合、移行コストに見合う保証は README からは読み取れません。最初に確認すべきは pip install datapizza-ai と datapizza-ai-clients-openai を同時に入れた環境で from datapizza.agents import Agent が解決できるか、そして ContextTracing().trace() の出力に自前のスパンが混ざるかどうかです。バージョンは v0.1.0 で、0.0.x 系からの差分がリリースノートにどこまで書かれているかも先に確認してください。

公式情報源

1. datapizza-labs/datapizza-ai on GitHub
2. License: MIT
3. Project website
4. README
5. Releases