Ibis(Python)とは?統一APIで20以上のバックエンドを扱う使い方
Ibisは、DuckDBやBigQueryなど20を超えるデータ処理エンジンを、同じPythonコードのまま操作できるポータブルデータフレームライブラリです。ここで扱うのは、鳥のトキ(ibis)でも宿泊チェーンのイビスホテルでも、お絵かきアプリのアイビスペイントでもなく、pandasの作者Wes McKinneyが立ち上げたデータ分析用のPythonライブラリ「Ibis」を指します。本記事では、Ibisの仕組みと対応バックエンド、インストールから基本操作・生成SQLの確認までを、実際のコードとともに解説します。
まとめ:Ibis(Python)の要点
- Ibisは「データフレームAPI」と「実行エンジン」を切り離すライブラリ。式(クエリ)を組み立て、接続先のバックエンドにSQLへ変換して実行させる。
- 対応バックエンドは20以上。ローカルのDuckDBが既定で、同じ式のままBigQueryやSnowflake、PySparkなどへ実行先を切り替えられる。
- 実行は遅延(deferred)。式を書いた時点では計算せず、
to_pandas()やexecute()を呼んだ瞬間にバックエンドが処理する。 - SQLやpandasに近い記法で書け、
ibis.to_sql()で生成SQLをそのまま確認できる。 - 最新版は12.0.0(2026-02-07)。pandas・daskバックエンドはIbis 10.0(2025年2月)で削除された(pandas DataFrame自体は入出力として引き続き使える)。
以下、仕組み・対応バックエンド・具体的な使い方・pandasとの使い分けの順に見ていきます。
Ibisとは:実行エンジンから切り離されたデータフレームAPI
Ibis自身はデータを計算しません。担うのは、Pythonで書いたデータ操作の式を、接続先エンジンが理解できる形式(多くはSQL)へ変換し、実行を委ねる「橋渡し」の役割です。計算はDuckDBやBigQueryといったバックエンド側で走るため、Ibisを介せば数十GB規模のデータでもPythonのメモリに全件を載せずに処理できます。作者はpandasを生んだWes McKinneyで、現在は特定企業に属さない独立ガバナンスのオープンソースとして開発され、主要メンテナはVoltron Dataに在籍しています。
Ibisの仕組み:式をSQLへコンパイルしてバックエンドに実行させる
Ibisでは、テーブルに対する絞り込みや集計を重ねて「式(expression)」を組み立てます。この式は組み立てた時点では実行されず、Ibisが接続先バックエンド向けのSQLへコンパイルし、実際の計算はエンジンが担当します。pandasが1行ずつ即時に計算するのに対し、Ibisは処理をまとめてからエンジンへ押し下げる(プッシュダウンする)ため、データが置かれている場所で計算を完結させられるのが構造上の違いです。
「ibis」の他の意味との区別(トキ・ホテル・お絵かきアプリ)
「ibis」は同名の対象が多く、検索意図が割れやすい語です。生物のibisはトキ科の鳥を指し、宿泊チェーンの「ibis(イビス)」はアコーホテルズのブランド、スマホのお絵かきアプリ「アイビスペイント(ibisPaint)」も別物です。本記事のIbisはこれらと無関係で、PythonのデータフレームライブラリであるOSSプロジェクト(ibis-project)を指します。読み方は「アイビス」です。
対応バックエンドとDuckDBが既定である理由
Ibisの価値は、対応バックエンドの広さと、それらを同一APIで扱える点にあります。ローカル解析からクラウドDWH、分散処理まで、用途に応じて実行先を選べます。
実行場所別の主要バックエンド
| 実行場所 | 代表的なバックエンド |
|---|---|
| ローカル・軽量 | DuckDB(既定), Polars, DataFusion, SQLite |
| クラウドDWH | BigQuery, Snowflake, Databricks, Athena |
| 分散・ストリーム | PySpark, Flink, Trino |
| RDB | PostgreSQL, MySQL, Oracle, MS SQL Server |
| 高速OLAP | ClickHouse, Impala, Druid |
Ibis 12時点で20以上のバックエンドに対応します。なお、かつて存在したpandasバックエンドとdaskバックエンドはIbis 10.0(2025年2月)で削除されました。pandasのDataFrame自体は入力・出力としては引き続き扱えるため、ローカルでpandasの結果が必要な場合はDuckDBなどで処理してto_pandas()で受け取る形になります。
DuckDBを既定に置く狙い
Ibisはインストール後、明示的に接続先を指定しなければローカルのDuckDBで動きます。DuckDBは追加のサーバー構築が不要な組み込み型の分析用エンジンで、メモリに収まらないCSVやParquet、JSONも直接クエリできます。SQLiteの手軽さを分析用途に持ち込んだ位置づけで、ローカルでの試行やノートブックでの分析に十分な性能が出るため、Ibisは学習・検証の初手をDuckDBに置いています。DuckDB単体の特徴はDuckDBとは?特徴・用途とSQLite・PostgreSQLとの違いを解説で詳しく扱っています。
Ibisの使い方:インストールと基本操作
ここからは実際のコードで、インストールから絞り込み・集計、生成SQLの確認までを追います。以下はDuckDBを既定バックエンドとして使う例です。
インストールと接続
バックエンドは「extras」で選んで入れます。DuckDBを使う最小構成は次のとおりです。
pip install "ibis-framework[duckdb]"
コード側では、Ibisを読み込み、DuckDBに接続します。ibis.options.interactiveをTrueにすると、式の評価結果をその場でプレビューできます。
import ibis
ibis.options.interactive = True # 結果をその場でプレビュー
con = ibis.duckdb.connect() # インメモリDuckDBに接続
データの絞り込み・集計(filter・group_by・aggregate)
テーブルを読み込み、pandasやSQLに近い記法で式を組み立てます。次の例は、カテゴリで絞り込み、店舗ごとに金額を合計して降順に並べる処理です。
t = con.read_csv("sales.csv") # CSVをテーブル式として読み込む
expr = (
t.filter(t.category == "book")
.group_by("store")
.aggregate(total=t.amount.sum())
.order_by(ibis.desc("total"))
)
df = expr.to_pandas() # ここで初めてDuckDBが計算を実行
この時点まで、filterやaggregateを書いても計算は走りません。to_pandas()を呼んだ瞬間にIbisがSQLへ変換し、DuckDBが集計を実行して結果をpandasのDataFrameとして返します。
生成SQLの確認(ibis.to_sql)
Ibisが式をどんなSQLへ変換したかは、実行前に確認できます。デバッグや、既存のSQL資産との突き合わせに使えます。
print(ibis.to_sql(expr))
接続先を変えれば、同じ式から各エンジンの方言に沿ったSQLが出力されます。SQLを直接書かずに、バックエンドごとの差異をIbisに吸収させられるのがこの機能の要点です。
インタラクティブモードと遅延実行(deferred)の使い分け
Ibisの実行は既定で遅延評価です。式は組み立てるだけで走らず、明示的に実行を指示した時に初めてバックエンドが計算します。この挙動を理解しておくと、大きなデータでも無駄な計算を発生させずに済みます。
ibis.options.interactive = False # 既定は遅延(deferred)
t = con.read_csv("sales.csv")
expr = t.filter(t.amount > 1000) # まだ実行されない(式を組み立てるだけ)
result = expr.execute() # 明示的に実行してDataFrameを取得
一方、ibis.options.interactive = Trueにすると、式を評価するたびに先頭の一部だけを実行して結果を表示します。ノートブックで中身を確認しながら分析を進める場面ではインタラクティブモード、バッチ処理や大規模データを一気に流す場面では遅延のままexecute()やto_pandas()で明示実行、と使い分けます。
pandasとの違いと、Ibisを採用すべき/すべきでない場面
Ibisはpandasの上位互換ではなく、役割が異なります。すべての分析をIbisに置き換えるべきではなく、向く場面と向かない場面をはっきり分けて判断するのが実務的です。
pandasから移す価値があるケース
pandasは全データをメモリに載せて計算するため、メモリを超える規模で行き詰まります。Ibisならメモリに載せずにDuckDBやBigQueryへ計算を押し下げられるため、大きなデータを扱う分析で効きます。もう一つの利点は移植性です。ローカルのDuckDBで書いた集計ロジックを、接続先をBigQueryへ変えるだけで本番の大規模データに適用でき、SQLの書き直しが要りません。複数のデータ基盤を横断するチームで、エンジンごとに方言SQLを書き分ける負担を減らしたい場合に向きます。
Ibisを使うべきでない場面
データが数万〜数十万行程度でメモリに収まり、単一環境で完結するなら、pandasやPolarsを直接使うほうが速く、学習コストもかかりません。Ibisは式をSQLへ変換する層が挟まるぶん、細かなセル単位の加工や、pandas固有の関数・ライブラリ連携に強く依存した処理では、かえって回り道になります。バックエンドを一つに固定して二度と替えない前提なら、Ibisの移植性という主要な利点も活きません。「複数バックエンドをまたぐ」「メモリに載らない」という動機がないうちは、無理に導入する必要はありません。pandasに近い高速化を単一環境で狙うなら、Polarsとは?pandasとの違い・高速化の仕組みと実務での採用判断【実装目線】も選択肢になります。
よくある質問
Ibisの読み方は?
「アイビス」と読みます。プロジェクト名はibis-projectで、PyPI上のパッケージ名はibis-frameworkです。
Ibisは無料で使えますか?
はい。IbisはApache License 2.0のオープンソースソフトウェアで、無料で利用できます。接続先のクラウドDWH(BigQueryやSnowflakeなど)を使う場合は、そのエンジン側の利用料が別途かかります。
IbisはpandasやSQLの代わりになりますか?
完全な置き換えではなく使い分けです。メモリに載らない大規模データや、複数バックエンドを同じコードで扱いたい場面ではpandasより有利ですが、小規模・単一環境ならpandasやPolarsで十分です。SQLについては、Ibisの式が最終的にSQLへ変換されるため、ibis.to_sql()で生成SQLを確認しながら併用できます。
どのバックエンドから始めればよいですか?
まずは既定のDuckDBが手軽です。追加のサーバー構築なしにローカルで動き、CSVやParquetを直接クエリできます。本番でBigQueryやSnowflakeを使う予定でも、ローカルのDuckDBで書いた式はそのまま実行先を切り替えて適用できます。
Ibisでpandasバックエンドは使えますか?
Ibis 10.0(2025年2月)でpandasバックエンドとdaskバックエンドは削除されました。ローカルで処理したい場合はDuckDBやPolars、DataFusionを使います。pandasのDataFrame自体は入力・出力として引き続き扱えるため、DuckDBで計算してto_pandas()で受け取る形が推奨されています。