Pandasとは?できること・使い方とPandas 3.0の変更点を解説
Pandas(パンダス)は、表形式のデータをPythonで読み込み、整形し、集計するためのライブラリです。名前は経済学の「panel data(パネルデータ)」に由来します。CSVもExcelもデータベースの検索結果も、いったんPandasに載せてしまえば同じ書き方で扱えるのが最大の価値です。ただし2026年1月にリリースされたPandas 3.0で、長年書かれてきたコードの一部が動かなくなりました。この記事では、Pandasの基本から、いま書くなら避けるべき書き方までをまとめます。
まとめ
Pandasの中心はSeries(1列)とDataFrame(表)の2つで、この2つを覚えれば読み込み・抽出・集計・出力の流れは共通の書き方で回せます。導入はpip install pandasだけで済み、2026年7月時点で入るのは3.0.3です。
注意すべきはPandas 3.0(2026年1月21日リリース)の破壊的変更です。Copy-on-Writeがデフォルトになったため、df[df["price"] > 0]["flag"] = 1のような連鎖代入は元のデータに反映されなくなり、文字列列のdtypeはobjectからstrへ変わりました。既存コードを3.0へ上げる前に、この2点を先に確認してください。以降で、データ構造・できること・使い方・SQLとの線引き・移行時の注意を順に見ていきます。
Pandasの正体:Pythonの表データを扱う中核ライブラリ
Pandasは2008年にWes McKinney氏が金融データ分析のために開発を始めたオープンソースライブラリで、現在はNumFOCUSの支援するプロジェクトとして開発が続いています。内部の数値計算はNumPyに任せ、Pandasは「行と列に名前が付いた表」という抽象を提供する役割を担っています。
Excelの操作を関数呼び出しに置き換えたもの、と考えると輪郭がつかみやすくなります。違いは、同じ処理を数百万行に対して繰り返し実行でき、手順がコードとして残るところです。
SeriesとDataFrameの使い分け:1列を返すか表を返すか
| データ構造 | 形 | Excelでの対応 | 主な用途 |
|---|---|---|---|
| Series | 1次元(ラベル付き) | 1列 | 単一列の抽出・計算 |
| DataFrame | 2次元(行・列ラベル付き) | シート全体 | 表の読み込み・結合・集計 |
実務でまず触るのはDataFrameです。df["price"]のように1列を取り出すとSeriesが返り、Seriesに対する計算結果を新しい列としてDataFrameへ戻す、という往復が基本の型になります。行や列を位置で抜き出すilocとラベルで抜き出すlocの違いは、最初につまずきやすい箇所です(ilocの使い方とlocとの違いで詳しく扱っています)。
Pandasでできること:CSV・Excel・DBを同じ書き方で処理する
Pandasの守備範囲は「表になっているデータの入口から集計まで」です。入口が何であっても、DataFrameに載せた後の操作は同じになります。
ファイル入出力:CSV・Excel・Parquet
import pandas as pd
df = pd.read_csv("sales.csv") # CSV
df = pd.read_excel("sales.xlsx") # Excel(openpyxl 3.1.5以上が必要)
df = pd.read_parquet("sales.parquet") # Parquet(pyarrow等が必要)
df.to_csv("out.csv", index=False)
Excelファイルの読み書きにはopenpyxlが別途必要で、excelエクストラが要求する下限は3.1.5です。数百万行を扱うなら、列単位で圧縮が効き読み込みも速いParquet形式に変換してから読むほうが現実的です。
データベース接続:SQLAlchemy 2.0.36以上のエンジンを渡す
from sqlalchemy import create_engine
engine = create_engine("postgresql+psycopg2://user:pass@localhost:5432/shop")
df = pd.read_sql("SELECT id, price, category FROM orders", engine)
read_sqlにSQLAlchemyのエンジンを渡せば、クエリ結果がそのままDataFrameになります。Pandas 3.0が対象とするSQLAlchemyは2.0.36以上です。SQL側で絞ってからPandasへ渡すのが鉄則で、その線引きは後述します。
欠損処理とグループ集計:VLOOKUPとピボットの置き換え
df = df.dropna(subset=["price"]) # priceが欠損した行を除外
df["price"] = df["price"].fillna(0) # 欠損を0で埋める
df.groupby("category")["price"].sum() # カテゴリ別の売上合計
pd.merge(df, master, on="category", how="left") # マスタ結合
欠損補完・グループ集計・結合という、ExcelならピボットテーブルとVLOOKUPで行っていた作業がすべて数行に収まります。集計結果をそのままdf.plot()に渡せば、matplotlib経由で折れ線や棒グラフも描けます。
Pandasの基本的な使い方:読み込みから出力までの流れ
実際の分析は、ほぼ次の4段階の繰り返しで進みます。
- 読み込む(
read_csv/read_sql) - 中身を確認する(
df.head()/df.info()/df.describe()) - 絞る・整える(条件抽出、型変換、欠損処理)
- 集計して出す(
groupby、to_csv)
df = pd.read_csv("sales.csv")
df.info() # 列名・dtype・欠損数を確認
target = df[(df["price"] > 1000) & (df["category"] == "book")]
result = target.groupby("shop")["price"].agg(["count", "sum"])
result.to_csv("report.csv")
最初にdf.info()でdtypeを見る癖をつけると、後段のバグが減ります。数値のはずの列が文字列として読み込まれていた、というのが集計エラーのよくある原因です。
Pandas 3.0で動かなくなるコード:連鎖代入とstr dtype
ここが2026年時点で最も重要な論点です。Pandas 3.0.0は2026年1月21日にリリースされ、多くの解説記事がまだ前提にしている2.x系の書き方が、そのままでは通用しなくなりました。既存プロジェクトを上げる前に、少なくとも次の3点を確認してください。
連鎖代入の非反映:SettingWithCopyWarningからChainedAssignmentErrorへ
# Pandas 2.xまでは(警告付きで)元のdfが書き換わることがあった
df[df["price"] > 1000]["flag"] = 1 # 3.0では元のdfに反映されない
# 3.0での正しい書き方
df.loc[df["price"] > 1000, "flag"] = 1
Copy-on-Writeがデフォルトになり、抽出結果は常にコピーとして振る舞うよう統一されました。結果として連鎖代入は一貫して効かなくなっています。ここで入れ替わったのが警告の種類です。2.x系で「更新されるかもしれないし、されないかもしれない」と警告していたSettingWithCopyWarningは削除され、3.0では代わりにChainedAssignmentErrorという警告が出ます。警告は出ますが更新は一切反映されないため、警告を握り潰しているコードベースでは静かに壊れます。grepで]["の形を洗い出しておくのが安全です。Pandas 3.0以降はmode.copy_on_writeオプションを設定しても挙動は変わらず、このオプションはPandas 4.0で削除される予定です(仕組みはCopy-on-Writeの解説記事で扱っています)。
文字列列のdtype変更:objectからstrへ、PyArrowは任意依存
# Pandas 2.x
pd.Series(["a", "b"]).dtype # dtype('O')
# Pandas 3.0
pd.Series(["a", "b"]).dtype # str
文字列データは専用のstr型として推論されるようになりました。PyArrowが入っていればPyArrowバックエンドが、入っていなければNumPyのobjectバックエンドが使われます。つまりPyArrowは必須依存ではありません(任意依存、動作確認済みの最小版は13.0.0)。「Pandas 3.0からPyArrowが必須」という記述を見かけますが、これはPyArrow必須化を定めたPDEP-10が一度承認されたのち撤回された経緯によるもので、最終仕様ではありません。
影響が出るのはdf["col"].dtype == objectで文字列列を判定していたコードです。この判定は3.0では偽になります。欠損値はstr型でも保持できますが、センチネルが常にNaNへ正規化されるため、is Noneで欠損を判定していた箇所は通らなくなります。
削除API一覧とPython 3.11以上という下限
| 項目 | Pandas 3.0での扱い |
|---|---|
| DataFrame.applymap | 削除(DataFrame.mapへ) |
| Series.bool / DataFrame.bool | 削除 |
| DataFrame.first / DataFrame.last | 削除 |
| Python | 3.11以上 |
| NumPy | 1.26.0以上(Python 3.14以降は2.3.3以上) |
公式は「まず2.3へ上げて警告をすべて潰し、それから3.0へ」という順序を推奨しています。2.3系では3.0で壊れる書き方の一部が警告として出るため、いきなり3.0へ飛ぶより移行コストが読めます。なお3.0ではpd.col()が追加され、df.assign(c=lambda d: d["a"] + d["b"])をdf.assign(c=pd.col("a") + pd.col("b"))と書けるようになりました。
SQLとPandasの使い分け:集計をどちら側で行うか
両者は競合しません。判断軸は「データがどこにあり、どれだけ絞れるか」の一点です。
| 観点 | SQL側で行う | Pandas側で行う |
|---|---|---|
| 行数の削減 | WHERE・JOIN・GROUP BY | — |
| 試行錯誤する加工 | — | 条件抽出・派生列作成 |
| 統計・機械学習の前処理 | — | 欠損補完・正規化・特徴量作成 |
| 実行場所 | DBサーバー | 手元のメモリ |
PandasはDataFrame全体をメモリに載せるため、1000万行のテーブルを丸ごとread_sqlで引くのは避けてください。集計や絞り込みでDBサーバー側に減らせる処理は、必ずSQLで減らしてからPandasへ渡します。逆に、条件を変えながら何度も試す前処理や、可視化・機械学習に渡す直前の加工はPandasが速く書けます。メモリに載り切らない規模になったら移行を検討する段階で、書き換え量を抑えたいならPandas互換APIのDask、性能を優先するなら独自のexpression APIを持つPolarsが候補になります。
Pandasのインストール:pipとcondaの選択
pip install pandas
pip install pandas[excel,parquet] # Excel・Parquetも扱う場合
2026年7月時点で導入されるのは3.0.3です。3.0.4は2026年6月28日にリリースされましたが、日時関連の機能でsegfaultの報告があったためPyPIでyank(取り下げ)されており、バージョン指定なしのpip installでは入りません。実行前にpython -Vで3.11以上であることを確認してください。
Anaconda環境ならconda install pandasでも導入できますが、pipとcondaを同一環境で混在させると依存解決が壊れやすくなります。pipとcondaの違いと使い分けで整理しているとおり、どちらか一方に寄せるのが安全です。インストール後は次の1行で確認できます。
python -c "import pandas as pd; print(pd.__version__)"
よくある質問
Pandasは何に使うのですか?
CSV・Excel・データベースなどの表形式データを読み込み、欠損値の処理や条件抽出で整え、グループ集計して結果を出力する——この一連の作業に使います。データ分析や機械学習の前処理が主戦場ですが、毎月のExcel集計を自動化する、といった定型業務の置き換えにも向きます。統計モデリングそのものはscikit-learnやstatsmodelsの担当で、Pandasはその手前までを受け持ちます。
PandasとSQLの違いは何ですか?
SQLはデータベースサーバー上でデータを絞り込む言語、PandasはPythonのメモリ上でデータを加工するライブラリです。集計や結合はどちらでも書けますが、大量データの絞り込みはSQL側で行い、絞った結果をPandasで加工するのが定石です。Pandasは全データをメモリに載せるため、絞り込まずに巨大テーブルを読み込むとメモリ不足になります。
Pandasの読み方は何ですか?
「パンダス」と読みます。動物のパンダとは無関係で、経済学で使われる「panel data(パネルデータ/同一対象を時系列で追跡したデータ)」に由来する名前です。
Pandasを習得するのにどれくらいかかりますか?
基本操作に限れば短期間で回せるようになります。読み込み(read_csv)、確認(head/info)、抽出(loc/iloc)、集計(groupby)、出力(to_csv)の5つを手元のCSVで動かすところから始めるのが最短です。時間がかかるのは文法ではなく、dtypeの扱いと、locとilocの使い分けです。
Pandas 3.0にすぐ移行すべきですか?
新規プロジェクトなら3.0から始めて問題ありません。既存プロジェクトは、まず2.3系に上げて警告をすべて解消してから3.0へ進む手順が公式に推奨されています。連鎖代入とdtype == objectによる文字列判定を使っていないかを先に洗い出してください。この2つが移行時の主な破損箇所です。