はじめに

Python は、定期的に新バージョンがリリースされ、文法の追加や標準ライブラリの拡張、パフォーマンスの改善など、様々な変更が行われています。新しい機能が追加されることで、より簡潔で読みやすいコードが書けるようになったり、開発効率が向上したりといったことも少なくありません。

Python の変更点は、公式ドキュメントのリリースノートから確認できます。しかし、すべてを把握するのは容易ではありません。

そこで、この記事では、Python 3.10 以降のバージョンを対象に、特に重要と考えられる新機能や変更点を中心に要点を整理して紹介します。なお、すべての変更点を網羅するものではなく、筆者が重要だと考えるものを優先して取り上げています。

より詳細には公式ドキュメントの各バージョンにおける「What’s new in Python X.X?」というリンクを参照してください。

また、各機能の詳細については、本サイトで個別記事として解説しているものもあるため、必要に応じて関連記事へのリンクも掲載しています。

Python 各バージョンの主な新機能・変更点

Python 3.14

Python 3.14 では、型注釈の仕組みや並列処理に関する改善など、言語仕様に関わる変更がいくつか導入されています。また、文字列機能（t-string）や圧縮ライブラリ（zstd）など、開発者の利便性を高める文法や標準ライブラリ拡張も行われています。

型注釈の遅延評価

型注釈の評価モデルが変更され、遅延評価の仕組みが導入されました。これにより、型注釈は、必要なタイミングで評価されるようになりました。

フリースレッドな Python（改善）

Python 3.13 で実験的に導入されたフリースレッドな Python の改善が進められました。フリースレッドな Python では、従来の GIL (Global Interpreter Lock) に依存しない実行モデルが検討されており、マルチスレッド環境での並列処理性能の向上が期待されています。

テンプレート文字列（t-string）

新しい文字列機能としてテンプレート文字列（t-string）が文法に導入されました。これは、文字列のテンプレート処理を安全かつ柔軟に扱うための仕組みで「文字列化されていないテンプレート」という概念を Python 標準の文法として取り入れています。

f-string は、文字列として即時評価されますが、t-string は後から評価・処理できるため、安全な文字列処理を実現するための実装に役立ちます。

Zstandard（zstd）の標準ライブラリ化

Zstandard は、Meta（旧 Facebook）が開発した高速で高圧縮な圧縮アルゴリズムです。Python 3.13 以前でも、外部ライブラリで使用できましたが、Python 3.14 で標準ライブラリ（zstd）として取り込まれました。

これにより、外部ライブラリに依存しない形で、高速かつ高圧縮な Zstandard のデータ圧縮を扱えるようになりました。

Python 3.13

Python 3.13 では、Python の実行モデルや開発体験に関わる改善が導入されています。特に、並列処理や実行速度の向上を目指した実験的な機能が追加されている点が特徴的です。

フリースレッドな Python（実験）

「フリースレッドな Python」が実験的な機能として導入されました。従来の Python では、マルチスレッドの並列処理では、GIL (Global Interpreter Lock) により制限を受けていました。

フリースレッドな Python は、GIL を使わない実行モデルであり、試験的に導入されました。この機能により、将来的には、Python でも効率的なマルチスレッド処理が可能になると期待されています。

JIT (Just-In-Time) コンパイラ（実験）

プログラム実行時にコードをコンパイルして最適化する「JIT (Just-In-Time) コンパイラ」が実験的な機能として導入されました。JITは、プログラム実行時にコードを機械語へ変換・最適化することで、処理のパフォーマンス向上が期待されています。

REPL 改善

インタラクティブな実行環境（REPL）が大きく改善されています。表示機能などが強化され、Python を対話的に利用する際の操作性が向上しました。

Python 3.12

Python 3.12 では、文字列機能強化や標準ライブラリの整理など、言語仕様や開発環境を整えるための変更が行われました。

f-string 文法の拡張

f-string の使い方の制限がいくつか解除され、より柔軟に式を記述できるようになりました。例えば、「f-string を囲むクォートと同じクォートを文字列中で再利用できるようになった」などがあります。

これにより、従来制限されていた複雑な式や改行を含む表現なども f-string 内で扱えるようになっています。

distutils 削除

Python パッケージを作成・配布するためのツールとして、長年非推奨となっていた distutils モジュールが正式に削除されました。現在では、setuptools が事実上デファクトスタンダードの位置づけとなっています。

distutils の機能は、setuptools に取り込まれているため、3.12 以降で distutils が必要な場合でも、setuptools に含まれる互換実装を利用できます。

サブインタープリタ（インタープリタごとの GIL）

サブインタープリタごとに独立した GIL を持つ仕組み（Per-interpreter GIL）の実装が進められました。これは、将来的な並列処理改善に向けた重要な基盤です。

Python 3.11

Python 3.11 では、Python の大幅なパフォーマンス改善が注目されました。実行速度の向上に加えて例外処理や標準ライブラリにも変更が加えられています。

実行速度の大幅改善

インタープリタの内部最適化などが進められ、実行速度が大幅に改善されました。3.11 のリリースノートでは「Python 3.10 とくらべて 10-60% 高速」「平均的には、標準ベンチマークスイートでは 1.25倍の高速化を計測」と記載があり、大きな性能向上が確認されています。

例外グループ / except*

複数の例外をまとめて扱うための例外グループ（ExceptionGroup）が導入されました。これにより例外をグループ化してまとめて送出できるようになりました。

また、対応する構文として「except*」が追加されており、例外グループの中に指定した型の例外が含まれている場合、その例外だけを取り出して処理することができるようになりました。

例外グループにより、並列処理などで複数例外が発生する場合に、処理が行いやすくなっています。

tomllib 標準ライブラリ化

TOML ファイルを読み込むための tomllib モジュールが標準ライブラリとして追加されました。これにより、設定ファイルなどで利用される TOML 形式を標準機能として扱えるようになりました。

近年の Python では、pyproject.toml でプロジェクト設定や依存関係、ツール設定を一元化することが一般的となっているため、tomllib は重要な役割を果たします。

Python 3.10

Python 3.10 では、新しい構文や型ヒント改善など、Python の書き方に影響する重要な変更が導入されています。

構造的パターンマッチ（match / case）

新しい構文として、構造的パターンマッチ（match / case）が導入されました。構造的パターンマッチは、3.10 の中心的な新機能であり、最も議論を起こした複雑な機能とも言われています。この機能は受理されるまで何度も議論されました。

これは、値のパターンに応じて処理を分岐する仕組みで、他言語の switch に似ていますが、クラス構造などを含めてマッチングできるなど、より柔軟なマッチングを行うことができます。

Union 型（|）

型ヒントで、Union 型を | 演算子で X | Y のように記述できるようになりました。Union 型とは、「1 つの変数や引数が、複数の型のうちいずれかを取り得る」ことを示すための型ヒントです。従来の typing.Union[X, Y] といった形式より簡潔に型表現できるようになっています。

distutils 非推奨

パッケージビルドツールである distutils が非推奨となりました。その後、Python 3.12 で正式に削除されており、現在は setuptools が事実上のデファクトスタンダードの位置づけとなっています。

まとめ

この記事では、Python の各バージョン（3.10 以降）の主な新機能や変更点について紹介しました。

Python は継続的に進化しており、新しいバージョンでは文法の追加やパフォーマンス改善などが行われています。特に Python 3.10 以降では、構造的パターンマッチや例外グループ、フリースレッドな Python など、言語仕様や実行環境に関わる重要な変更が導入されています。

Python 利用の際には、使用バージョンによる違いを意識して使用してみてください。

あわせて読みたい

【Python Tech】プログラミングガイド

uv の概要

uv とは？

uv は、Python 用の高速なパッケージおよびプロジェクト管理ツールです。

従来の Python 環境の構築では、pip、venv など複数のツールを組み合わせて使用することが一般的でした。uv は、これらの機能を統合して、パッケージ管理、仮想環境管理、依存性管理などを 1 つのツールで扱えるようにしたものであり、pip の代替として非常に注目されているツールです。

また、uv は、プログラミング言語の Rust で実装されていることも特徴です。Rust の高速な処理能力を活かすことで、依存関係の解決やパッケージインストールを効率的に行うことができます。

この記事では、uv のインストール方法や使い方、pip との違いなどについて紹介していきます。

pip との比較

主な違い

pip は、Python の標準パッケージインストーラであり、PyPI (Python Package Index) からパッケージをインストールするためのツールです。一方、uv は、パッケージ管理だけでなく、仮想環境管理や依存関係の lock 管理なども統合して提供します。

速度の違い

uv は、Rust で開発されており、並列ダウンロードや効率的な I/O 処理により非常に高速に処理ができます。以下は、uv の公式サイトで紹介されている指標です。

このベンチマークでは、Python の非同期ライブラリ Trio の依存パッケージをインストールする際の速度が比較されています。Trio は、async / await を利用した非同期処理を扱う Python ライブラリで、このライブラリの依存関係をインストールする処理を各ツールで比較しています。

また、この測定は、warm cache (依存関係が既にキャッシュされている状態) で行われています。結果を見ると、poetry や pdm などの他ツールに比べて uv は非常に高速に処理できることが分かります。

uv のインストール方法

uv のインストール方法

uv のインストール方法を紹介します。手順は、公式のこちらを参照しています。

Windows でのインストール

Windows では、PowerShell を利用して以下のコマンドを実行します。

powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

実際のインストールは「"irm https://astral.sh/uv/install.ps1 | iex"」の部分で実行されています。irm は、指定URLからデータを取得する PowerShell のコマンドで、インストールスクリプトをダウンロードし、iex に渡して実行しています。

「powershell -ExecutionPolicy ByPass」は、この起動した PowerShell プロセスだけ実行ポリシーを無視してスクリプトを実行するための指定です。

インストールが完了すると「uv.exe」などの実行ファイルがインストールされます。PATH も自動的に設定されるため、PowerShell を再起動すると uv コマンドが使用できるようになります。

Linux/ macOS

Linux や macOS では、以下のコマンドを実行します。

curl -LsSf https://astral.sh/uv/install.sh | sh

uv によるプロジェクトの作成と管理

uv によるプロジェクトの作成

uv では、「uv init」コマンドを使用して新しいプロジェクトを作成できます。以下は、my-project というプロジェクトを作成する例です。

uv init my-project

このコマンドを実行すると、my-project というフォルダに以下のようなファイルが自動で生成されます。

my-project
├ .gitignore
├ .python-version
├ main.py
├ pyproject.toml
└ README.md

簡単に各ファイルの説明をしておきます。

pyproject.toml

Python プロジェクトの設定ファイルです。プロジェクト情報を管理するために使用され、近年の Python プロジェクトでは、pyproject.toml が標準的な設定ファイルとして利用されています。

main.py

エントリーポイントとして利用できるサンプルの Python ファイルです。

README.md

プロジェクトの概要や使い方などを記述するためのファイルです。

.gitignore

Git の管理から除外するファイルを指定する設定ファイルです。Python プロジェクトでは、仮想環境、キャッシュファイル、一時生成ファイルなどは Git 管理対象外として除外することが一般的です。

.python-version

使用する Python バージョンを指定するファイルです。プロジェクト単位で使用する Python バージョンを明示できます。仮想環境作成時に uv は、このファイルを参照しており、開発環境ごとの Python バージョン差異を防ぐことができるようになります。

パッケージの管理方法

パッケージ管理は、uv コマンドを使用して実行します。作成したプロジェクトの配下で以下で紹介するようなコマンドを使用します。

パッケージの追加

パッケージの追加は「uv add」コマンドで行います。以下は、NumPy の追加例です。

uv add numpy

複数のパッケージをまとめてインストールする場合は、スペースでパッケージを列挙すればまとめてインストールできます。

仮想環境や lock ファイルがない場合は生成され、lock ファイルには、依存パッケージの具体的なバージョン情報が記録され、プロジェクトの依存関係を再現できます。

パッケージの削除

パッケージを削除する場合は「uv remove」コマンドを次のようにします。

uv remove numpy

uv add や uv remove で操作されたパッケージの依存関係は自動的に解決され、uv.lock が更新されます。

依存関係の表示（uv tree）

インストールしたパッケージの依存関係ツリーを表示したい場合には「uv tree」コマンドを使用します。

uv tree

例えば、NumPy、pandas、scikit-learn をインストールした状態だと以下のような依存性のツリーを確認できます。

my-project v0.1.0
├── numpy v2.4.2
├── pandas v3.0.1
│   ├── numpy v2.4.2
│   ├── python-dateutil v2.9.0.post0
│   │   └── six v1.17.0
│   └── tzdata v2025.3
└── scikit-learn v1.8.0
    ├── joblib v1.5.3
    ├── numpy v2.4.2
    ├── scipy v1.17.1
    │   └── numpy v2.4.2
    └── threadpoolctl v3.6.0

uv run によるプログラム実行

uv では、「uv run」コマンドを使用して以下のようにプログラムを実行できます。

uv run main.py

通常 Python 開発環境を利用する場合には、以下のような手順を踏む必要があります。

1. 仮想環境（venv）を作成
2. 仮想環境を activate
3. Python プログラムを実行

一方で、uv run を用いると、仮想環境が自動的に管理されるため、activate を意識せずにプログラムの実行ができます。

仮想環境（.venv）や uv.lock の生成タイミング

uv init でプロジェクトを生成したタイミングでは、仮想環境（.venv）や uv.lock ファイルは、生成されません。

これらは上記で紹介したような「uv run」「uv add」などのプロジェクトコマンドが最初に実行されたタイミングで生成されます。

仮想環境の自動管理

uv では、仮想環境が自動的に管理されるため、明示的な venv の作成や activate を意識する必要がありません。プロジェクト単位で Python 環境が管理されるため、複数のプロジェクトを扱う場合でも環境の衝突を防ぐことができます。また、プロジェクトごとに Python のバージョン指定をすることも可能です。

uv 使用に関する注意点

uv は、新しい Python プロジェクトでは非常に有力な選択肢となります。一方で、pip を中心としたプロジェクト管理と比較すると歴史はまだ浅いです。

既存の大規模プロジェクトへ導入する場合は、CI / CD 環境との整合性やチーム運用方針を確認しながら、段階的に導入を検討すると良いでしょう。新規のプロジェクトでは、ぜひ uv の採用を検討してみてください。

まとめ

Python で近年注目されている uv というパッケージおよびプロジェクト管理ツールについて解説しました。

uv は、Rust 製の高速な Python パッケージ・プロジェクト管理ツールです。pip での環境構築では複数ツールを組み合わせて行っていた「パッケージ管理」「仮想環境管理」「依存関係管理」を統合的に提供します。

uv は、pip に比べると歴史が浅いため、大規模プロジェクトでの採用には、段階的導入を検討するなど注意が必要ですが、新規プロジェクトでは、シンプルで再現性の高い開発環境を構築できるツールとして有力な選択肢となるでしょう。

あわせて読みたい

【Python Tech】プログラミングガイド

Ruff とは

Ruff（ラフ）は、Python 向けの高速なリンター兼フォーマッターです。プログラム言語としては、Rust で実装されており、従来の flake8、black、isort が担っていた役割を 1 つのツールで担える点が特徴です。

Ruff は、CLI ツールとして利用できるため Visual Studio Code (VS Code) に限らず、その他の統合開発環境（IDE）でも使用できます。

この記事では、Python の開発環境として非常によく利用されている VS Code での利用方法に焦点をあてて解説します。

Ruff でできること

Ruff では、主に以下の機能を提供します。

• フォーマット（コード整形）
• 静的解析（Lint）
• import の整理

コマンドとしては以下のように使用できます。

ruff format .

ruff check . --fix

Ruff は、コード整形でよく使われる black 互換のフォーマット機能、flake8 の静的解析（Lint）、isort 相当の import 整理機能を 1 つのツールで扱うことができます。

Ruff の特徴

Ruff の主な特徴を整理しておきます。

高速性

Ruff は、プログラム言語の Rust で実装がされており、大規模プロジェクトでも非常に高速に動作します。

Rust は、C/C++に匹敵する高性能を持ちながら、メモリ安全性が高く、Pythonなどのモダンな言語に見られる表現のしやすさも備えている、非常に優れた言語です。従来の Python 製リンターと比較しても非常に高速です。

多機能な静的解析（Lint）

flake8 のルールに加えて、多数のルールを内包しており、pyproject.toml によりルールを細かく制御することができます。

設定の一元管理

設定は、pyproject.toml にまとめて記述することができます。これにより、フォーマットと Lint の設定を同一ファイルで管理できます。

Ruff の歴史と位置づけ

Ruff は、2022 年頃に登場して急速に注目を集めてきました。高速性と利便性から、多くのプロジェクトでの採用が進んでいます。

近年では、Rust 製のツールが Python エコシステムを補完する動きが多くみられます（uv や Polars など）。その流れの中で、Ruffも実用的で高速な開発基盤ツールとして位置づけられています。新規プロジェクトでは black や isort の代替として、Ruff を採用するケースも増えています。

VSCode で Ruff を設定して使用する方法

ここからは、VS Code で Ruff を実際に利用する方法を解説します。なお、Ruff は CLI ツールであるため、以下の両方が必要です。

• プロジェクトに Ruff をインストールする
• VS Code の Ruff 拡張をインストールする

それぞれをインストールした上での基本的な設定方法などを紹介していきます。

Ruff のインストール

Ruff をインストールする場合は、以下のようにインストールします。

pip install ruff

また、uv を使用している場合は、以下でインストールします。

uv add ruff

ここで、インストールされるのは Ruff 本体の CLI ツールです。

Ruff の VSCode 拡張のインストール

次に、VS Code 拡張機能から Ruff をインストールします。VS Code の拡張機能で「Ruff」と検索すると、Astral Software の Ruff 拡張が検索できますのでインストールします。

Ruff 本体は、CLI ツールであり、この VS Code 拡張は、エディタ連携のための拡張機能という位置づけとなっています。

Ruff に関する VS Code の基本的な設定（setting.json）

Ruff を使用するにあたっての VS Code 側の基本的な設定を紹介します。

VS Code の「Ctrl + Shift + P」でコマンドパレットを開き、「Preferences: Open Settings (JSON)」から setting.json を開きます。

VS Code の設定は大きく次の 3 種類があります。

• 既定値（Default）：VS Code 本体や拡張機能が持つ初期設定
• ユーザー設定（User）：ユーザー個人に適用される設定
• ワークスペース設定（Workspace）：プロジェクト単位に適用される設定

プロジェクト単位で Ruff 有効にしたい場合は、ワークスペース設定（.vscode/settings.json）に記述するのがおすすめです。チーム開発では、この方法により設定を共有できます。

一方、自身が扱うすべてのプロジェクトで Ruff を有効にしたい場合は「ユーザー設定（User）」に記述しても問題ありません。

settings.json に以下の記載を追加してください。

{
  "[python]": {
    "editor.defaultFormatter": "charliermarsh.ruff",
    "editor.formatOnSave": true,
    "editor.codeActionsOnSave": {
      "source.fixAll.ruff": "explicit",
      "source.organizeImports.ruff": "explicit"
    }
  }
}

各項目の補足説明は以下の通りです。

Ruff の詳細設定（pyproject.toml）

Ruff の詳細設定は pyproject.toml に記述します。

Ruff は、デフォルトでも実用的な設定が有効になっているため、基本的には、pyproject.toml に追加の設定を記述しなくても利用できます。

ただし、プロジェクト方針やコーディング規約に応じて、設定を明示的に変更することも可能です。ここでは、代表的な設定の一部を紹介します。

基本設定 [tool.ruff]

Ruff の基本的な挙動は [tool.ruff] セクションで設定します。

例えば、代表的な設定として、1 行当たりの最大文字数は以下のように設定します。

[tool.ruff]
line-length = 88

Ruff のデフォルトは、black 互換の設定の 88 文字であるため、基本的に上記のような記載は必要ありません。

一方で、PEP8 準拠の 79 文字にしたい場合には、次のように指定します。

[tool.ruff]
line-length = 79

プロジェクトのコーディング規約にあわせて調整してください。

Lint 設定 [tool.ruff.lint]

ルール群の指定方法（select）

Ruff には、複数のリントルールがあります。こちらも基本的にはデフォルト設定で問題ありませんが、以下のように [tool.ruff.lint] セクションで制御できます。

[tool.ruff.lint]
select = ["E", "F", "I"]

select では、ルール群を表す文字列を指定します。なお、Ruff の記事執筆時点でのデフォルト設定は、["E4", "E7", "E9", "F"] です。これは、実行時エラーにつながる可能性が高い問題や、明確なコーディングエラーを中心に検出するルール群が有効になっていることを意味します。

リントのルール一覧は、公式ページの Rules ページにまとめられています。このページの「Code」列に書かれている値が各ルールを示すコードです。

例えば、"E" は、pycodestyle 由来のルール群を示します。また、"E4" は "E4"から始まるルールコードをまとめて指定する指定方法で、Rules ページを確認すると、"E4" には以下のルールが含まれることになります。

なお、"E" を指定すれば、"E" から始まる pycodestyle 由来のリントルール群がすべて有効になります。

ルールの除外（ignore）

まとめて指定した際に、特定ルールのみを除外したい場合は、ignore を使用します。

[tool.ruff.lint]
select = ["E", "F", "I"]
ignore = ["E501"]

上記では、"E" から始まるルール群をすべて有効にしつつ、"E501"（行長の違反） のみを除外しています。

Ruff は、デフォルト設定でも十分実用的です。まずは、デフォルトのまま導入し、必要に応じて、pyproject.toml を用いて柔軟に調整していくのがおすすめです。プロジェクトの方針に応じて検討してください。

まとめ

Python の高速なリンター兼フォーマッターである Ruff の概要と VSCode での設定方法を解説しました。

Ruff を導入することで、コード整形や静的解析（Lint）、import 整理といった機能を 1 つのツールで扱うことができるようになります。Ruff は、Rust で実装がされており非常に高速であることが特徴です。

VS Code と組み合わせることで、保存時に自動フォーマットや Lint 修正が実行され、より快適な Python 開発環境を構築できます。

Ruff 自体の設定方法についても一部紹介しましたが、Ruff はデフォルト設定でも十分実用的であり、まずは最小構成で導入し、必要に応じて pyproject.toml で調整していくのがおすすめです。

ぜひプロジェクトに導入してみてください。

あわせて読みたい

【Python Tech】プログラミングガイド

Zstandard (zstd) の概要

Zstandard は、Meta（旧 Facebook）が開発した圧縮アルゴリズムです。Zstandard は、「高速」で「高圧縮率」のバランスの取れた圧縮形式として普及が進んでいます。

zstd は、Zstandard の略称でライブラリ名としてよく使われており、Python では、Python 3.14 から標準ライブラリとして zstd モジュールが提供されています。

この記事では、zstd により Zstandard アルゴリズムを使ったデータを圧縮する方法の基本について紹介します。

Zstandard の標準ライブラリ化 zstd

これまでは、Python における圧縮ライブラリは、gzip、zlib、bz2、lzma といったライブラリが標準ライブラリとして使用できました。これらは標準であることの安心感や長年の互換性・安定性という面で優れる一方で、性能面では Zstandard の方が高速、高圧縮率という状況でした。

Python の 3.13 以前でも Zstandard が使えなかったというわけではなく、外部ライブラリとして「pip install zstandard」とすることで使用できました。外部ライブラリとして成熟はしていたものの、Python の標準ライブラリではなかったため、依存関係や運用面の観点から標準的には採用しずらい状況がありました。

PEP 784 に基づき、Python 3.14 に zstd ライブラリとして取り込まれたことで、これらの懸念は大きく緩和され、標準的に使用しやすくなりました。

zstd の基本的な使い方

zstd による基本的なデータ圧縮／解凍方法

zstd では、bytes データの圧縮を compress() 関数、解凍を decompress() 関数を使って実行することができます。以下の簡単な例で見てみましょう。

from compression import zstd

# 圧縮／解凍対象のデータ
data = "Zstandard 圧縮テストデータ".encode("utf-8")

# zstd を使ってデータを圧縮
compressed = zstd.compress(data)

# zstd を使ってデータを解凍
restored = zstd.decompress(compressed)
print(f"解凍後のデータ: {restored.decode('utf-8')}")

【実行結果】
解凍後のデータ: Zstandard 圧縮テストデータ

zstd は、compression モジュール配下にあるので「from compression import zstd」のようにインポートして使います。

例では、文字列を圧縮／解凍してます。compress() に対象データを渡すと圧縮データが生成され、圧縮したデータを decompress() に渡して解凍することで元のデータを復元できます。

なお、compress() / decompress() は、bytes 型を扱う API であるため、例のように文字列（str）を圧縮する場合には、事前に encode() で bytes に変換し、解凍後には decode() で文字列に戻します。

from compression import gzip
from compression import zlib
from compression import bz2
from compression import lzma

圧縮レベルの設定 level

zstd では、圧縮のレベルを 1 ~ 22 の値を指定することができます。値が大きいほど高圧縮になりますが、処理時間が多くかかります。圧縮レベルを指定するには level 引数を指定します。何も指定しないときのデフォルトは level=3 となります。

以下では、4つのパターンで圧縮率を比較してみます。

• level=1 (高速・低圧縮)
• level=3 (デフォルト)
• level=10 (中程度の圧縮)
• level=22 (最大設定で高圧縮)

対象データは単純なデータの繰り返しでは差が見えないため、ログ風のデータを繰り返しで生成して確認しています。

from compression import zstd
from datetime import datetime, timedelta

# ログ風の大きなテストデータを生成
lines = []
start = datetime.now()
num = 100_000

for i in range(num):
    ts = start + timedelta(seconds=i % 60)
    lines.append(
        f"{ts.strftime('%Y-%m-%dT%H:%M:%S')} INFO user_id={i%10000} action=click page=/items/{i%500}\n"
    )
data = "".join(lines).encode("utf-8")


def report_compression_results(level, compressed, original_size):
    """圧縮結果を表示する関数"""

    compressed_size = len(compressed)
    compression_percent = (compressed_size / original_size) * 100

    print(
        f"Level {level:>2}:"
        f" 圧縮後サイズ: {compressed_size:>10,} バイト,"
        f" 圧縮後サイズ比: {compression_percent:>6.2f} %"
    )


original_size = len(data)
print(f"元のサイズ: {original_size:,} バイト")

# level=1 (高速圧縮)
compressed_level1 = zstd.compress(data, level=1)
report_compression_results(1, compressed_level1, original_size)

# zstd を使ってデータを圧縮 (level指定による変化を確認)
# デフォルトは level=3
compressed = zstd.compress(data)
report_compression_results(3, compressed, original_size)

# level=10 (中程度の圧縮)
compressed_level10 = zstd.compress(data, level=10)
report_compression_results(10, compressed_level10, original_size)

# level=22 (最大の設定、最高圧縮、非常に遅い)
compressed_level22 = zstd.compress(data, level=22)
report_compression_results(22, compressed_level22, original_size)

【実行結果】
元のサイズ: 6,666,900 バイト
Level  1: 圧縮後サイズ:    192,821 バイト, 圧縮後サイズ比:   2.89 %
Level  3: 圧縮後サイズ:    139,030 バイト, 圧縮後サイズ比:   2.09 %
Level 10: 圧縮後サイズ:     37,436 バイト, 圧縮後サイズ比:   0.56 %
Level 22: 圧縮後サイズ:     25,827 バイト, 圧縮後サイズ比:   0.39 %

結果を見るとレベルを上げるほど、高い圧縮率で圧縮できていることが分かります。

圧縮レベルは高いほど圧縮率は向上しますが、その分CPU負荷が増加します。多くのケースではデフォルト（level=3）が速度と圧縮率のバランスがよく、まずは level 指定せずに利用するのがおすすめです。

一方で、ストレージ削減や転送量削減を重視する場合は、level=6~10 程度を検討するのが良いでしょう。それ以上の level は、CPU 負荷増加に対して圧縮率の改善幅は小さい結果となる可能性が高いです。

zstd によるストリーミング圧縮／解凍方法

compress() / decompress() は、bytes を一括で圧縮／解凍するために非常に便利ですが、巨大なファイルを対象にする場合は、すべてのデータをメモリに読み込む必要があり、メモリ消費量が大きくなってしまいます。

そこで、大容量のファイルでは、一定サイズのチャンク（塊）毎にデータ読み込みながら、圧縮／解凍する「ストリーミング処理」を利用します。

以降の例では、以下スクリプトで指定したサイズの大きなログ風のファイルを生成してストリーミング圧縮／解凍します。

from datetime import datetime, timedelta


def create_sample_log_file(filepath: str, size_mb: int = 10) -> None:
    """指定サイズ(MB) 以下に収まるログ風のサンプルファイルを作成する関数

    Args:
        filepath (str): 作成するファイルのパス
        size_mb (int, optional): 目標サイズ(MB). デフォルトは10MB.
    """
    target_size = size_mb * 1024 * 1024  # MB をバイトに変換
    start = datetime.now()

    written = 0
    i = 0

    with open(filepath, "wb") as f:
        while written < target_size:
            ts = start + timedelta(seconds=i % 60)
            line = (
                f"{ts:%Y-%m-%dT%H:%M:%S} INFO user_id={i%10000} "
                f"action=click page=/items/{i%500}\n"
            ).encode("utf-8")

            # 書き込み後にサイズ超過しそうなら終了
            if written + len(line) > target_size:
                break

            f.write(line)
            written += len(line)
            i += 1

    print(f"Created: {filepath}")
    print(f"Target : {size_mb} MB ({target_size:,} bytes)")
    print(f"Actual : {written / 1024 / 1024:.2f} MB ({written:,} bytes)")
    print(f"Lines  : {i:,}")


if __name__ == "__main__":
    path = "sample.log"
    create_sample_log_file(path, size_mb=100)

【実行結果例】
Created: sample.log
Target : 100 MB (104,857,600 bytes)
Actual : 100.00 MB (104,857,567 bytes)
Lines  : 1,572,821

上記スクリプトは、create_sample_log_file 関数にファイルパスとサイズ（MB）を指定するとログ風のファイルを作成します。以降例では、sample.logという 100 MB のファイルを例に紹介します。

このように事前に大きなファイルを用意しておくことで、ストリーミング圧縮によるメモリ使用量の違いを確認しやすくなります。もちろん、お手元に大きなファイルがあればそちらを使って試していただいて構いません。

ストリーミング圧縮

zstd を使用して大きなファイルをストリーミング圧縮するには、以下のようにします。

from compression import zstd


def compress_file(
    src_path: str, dst_path: str, level: int | None = None
) -> None:
    """ファイルをストリーム圧縮する関数

    Args:
        src_path (str): 圧縮対象のファイルパス
        dst_path (str): 圧縮先ファイルパス
        level (int | None, optional): 圧縮レベル. デフォルトは None (zstd のデフォルトレベル 3 ).
    """
    # 1 MB のチャンクで処理
    chunk_size = 1024 * 1024

    # 対象ファイルを開いてストリーム圧縮
    with open(src_path, "rb") as f_in:
        # zstd で圧縮先ファイルを開く
        with zstd.open(dst_path, "wb", level=level) as f_out:
            # chunk_size ごとに読み込みながら圧縮して書き込み
            # ファイル末尾の b"" で停止するイテレータを使用
            for chunk in iter(lambda: f_in.read(chunk_size), b""):
                f_out.write(chunk)


if __name__ == "__main__":
    source_path = "sample.log"
    dest_path = "sample.log.zst"
    compress_file(source_path, dest_path)

例では、圧縮対象のパス（src_path）と圧縮先のパス（dst_path）、および圧縮レベル（level）を引数に受け取り、ストリーム圧縮する関数 compress_file() を作成しています。なお、level は、指定がない（None）の場合は、zstd のデフォルトの level=3 になります。

今回は、1 MB のチャンク（塊）でソースファイルのデータを読み込んでいきます。

zstd.open は、圧縮ファイル（.zst）をファイルオブジェクトとして扱えるようにするものです。例では、読み込みファイルを open のバイナリ読み込み（"rb"）で、圧縮先ファイルを zstd.open のバイナリ書き込み（"wb"）で開いています。なお、圧縮レベル（level）は、zstd.open の引数に指定します。

# ファイル末尾の b"" で停止するイテレータを使用"
for chunk in iter(lambda: f_in.read(chunk_size), b""):
    f_out.write(chunk)

具体的に圧縮書き込みをしている上記部分はイテレーターを活用している部分で少しだけ複雑なので丁寧に説明します。

iter(callable, sentinel) は、Python 組み込み関数 iter() の特殊な使い方です。第 1 引数の callable に指定した関数を繰り返し呼び出し、その戻り値が sentinel と一致したタイミングで繰り返しを停止します。

file.read() は、ファイル終端の EOF に到達すると b"" を返却するため「EOF まで chunk_size ごとに chunk に読み込む」ための for 文になっています。

なお、ここで指定している chunk_size は「読み込みの単位」であり、Zstandard の圧縮形式としてのブロックサイズとは関係ありません。write() をチャンク単位で呼び出していますが、これはデータを圧縮ストリームに順次渡すことを意味しており、write() を 1 回呼び出すたびに必ずしも圧縮先ファイルへ即座に書き込まれるわけではありません。圧縮処理では、内部でバッファリングが行われ、圧縮されたデータは適切な単位、タイミングでまとめて圧縮先ファイルに書き込まれます。

ストリーミング解凍

zstd を使って圧縮したファイルのストリーミング解凍で元のファイルに復元する場合は、ストリーミング圧縮と同様に以下のようにします。

from compression import zstd


def decompress_file(src_path: str, dst_path: str) -> None:
    """zstd圧縮ファイルをストリーム解凍する関数

    Args:
        src_path (str): 対象ファイル（.zst）のパス
        dst_path (str): 解凍先のファイルパス
    """
    # 1 MB のチャンクで処理
    chunk_size = 1024 * 1024  # 1MB

    # zstd で圧縮元ファイルを開いてストリーム解凍
    with zstd.open(src_path, "rb") as f_in:
        # 解凍先ファイルを開く
        with open(dst_path, "wb") as f_out:
            for chunk in iter(lambda: f_in.read(chunk_size), b""):
                f_out.write(chunk)


if __name__ == "__main__":
    source_path = "sample.log.zst"
    dest_path = "sample_restored.log"
    decompress_file(source_path, dest_path)

上記は、圧縮時と比べると入力（f_in）を zstd.open() で開いており、出力（f_out）を open() で開いている点で異なりますが構造は同様です。

圧縮前のファイルと圧縮／解凍後のファイルが一致しているかどうかは、以下のようなスクリプトで前後のファイルのハッシュ値を一致を確認するのが簡単です。

import hashlib


def sha256(path: str) -> str:
    """ハッシュ値計算用

    Args:
        path (str): 対象ファイルのパス

    Returns:
        str: SHA256 ハッシュ値（16 進文字列）
    """
    h = hashlib.sha256()
    with open(path, "rb") as f:
        for chunk in iter(lambda: f.read(1024 * 1024), b""):
            h.update(chunk)
    return h.hexdigest()


if __name__ == "__main__":
    original_hash = sha256("sample.log")
    restored_hash = sha256("sample_restored.log")
    print(f"Original SHA256: {original_hash}")
    print(f"Restored SHA256: {restored_hash}")
    print("一致" if original_hash == restored_hash else "不一致")

【実行結果】※ハッシュ値は対象ファイルにより変化します。
Original SHA256: 3fbff20cef2ac6b9a19f3399bb9ac58c603e597db79bb78332702bd48367b3ba
Restored SHA256: 3fbff20cef2ac6b9a19f3399bb9ac58c603e597db79bb78332702bd48367b3ba
一致

結果を見ると、処理前後でハッシュ値が一致していることが分かります。なお、ハッシュ値は対象ファイルにより変化しますので注意してください。

このようにすることで、サイズの大きなファイルについてもメモリを節約しつつ圧縮／解凍することが可能になります。

まとめ

Python で zstd により Zstandard アルゴリズムを使ったデータ圧縮／解凍をする方法の基本について解説しました。

Zstandard は、Python 3.13 以前では、外部ライブラリとして pip でインストールをして使う必要がありましたが、Python 3.14 で標準ライブラリに追加され、compression.zstd を使ってデータを圧縮／解凍ができるようになりました。

この記事では、一括で bytes データを圧縮／解凍する compress() / decompress() の使い方や level 指定による圧縮率の違いについて説明しました。また、大容量ファイルを扱う場合の、ストリーミング圧縮／解凍の方法についても紹介しています。

zstd は高速かつ高圧縮な形式として普及が進んでおり、ログ圧縮やデータのアーカイブ用途でも非常に使いやすい選択肢です。ぜひ、zstd を有効活用してみてください。

あわせて読みたい

【Python Tech】プログラミングガイド

テンプレート文字列 t-string

テンプレート文字列 t-string とは

t-string とは、Python 3.14 で新しく追加されたテンプレート文字列のための構文です。t-string は、以下のような文字列のことで、文字列をフォーマットするための f-string とよく似ていますが、最大の特徴は式の内容を保持したまま、文字列としてはまだフォーマットされない点です。

t"Hello {name}"

上記のように書いても name の値は即時に文字列には変換されません。t-string は、完成した文字列を作るものではなく、後から評価・処理されることを前提としたテンプレートを生成するものです。

この記事では、テンプレート文字列 t-string の基本的な使い方や関連する型の構造などについて紹介します。

なぜ t-string が必要になるのか

t-string は、PEP 750 で提案されて取り込まれた構文です。文字列フォーマットのための f-string は非常に便利な構文ですが「文字列が即時評価される」という性質があり、もともとどういった文字列の中に何が埋め込まれたのかが後からは分からないという特徴があります。

f-string は多くの場合で問題になりませんが、次のようなケースでは注意が必要です。

これまでは、上記には独自に対応する必要がありましたが、t-string は「文字列化されていないテンプレート」という概念を Python 標準の文法とし、この課題を解決するために導入されています。

t-string の基本的な使い方

基本的な使い方

t-string の基本構文は、文字列リテラルの前に「t」をつけるだけです。

def main():
    user = "太郎"
    age = 30

    # t-string の使い方 例
    template = t"User: {user}, Age: {age}"

    # t-string の内容を表示
    print(f"template = {template}")

if __name__ == "__main__":
    main()

【実行結果】
template = Template(strings=('User: ', ', Age: ', ''), interpolations=(Interpolation('太郎', 'user', None, ''), Interpolation(30, 'age', None, '')))

f-string と非常によく似ています。{} を使用してプレースホルダを記述し、用意した変数（例では、user や age）を渡します。

返却値を template という変数に入れて表示してみていますが、Template 型になっているということが分かります。また、Template 型の中には、Interpolation 型というものも含まれることが分かります。これらの型については、後ほど説明していきます。

t-string は文字列に変換されない

t-string の使い方は、f-string と同様で非常に簡単ですが、上記の例のポイントとしては、t-string を用意した時点で中の式は自動的に文字列には変換されない点です。上記の例でいうと user や age の値は取得されますが、文字列としては展開されません。

t-string は式と文字列部分を分離したまま保持します。つまり、「文字列を作る」ためではなく、「文字列の設計図を作る」構文と理解すると分かりやすいかと思います。

この性質により以下のようなメリットがあります。

このように、t-string は「安全に扱えるテンプレート」を実現できます。

t-string の型を深堀する

f-string は結果として str となりますが、t-string は単なる str ではありません。内部的には、テンプレートとしての構造を持ったオブジェクトが生成されます。

ここでは、その型構造について、以下の例を使いながら紹介していきます。

def main():
    user = "太郎"
    age = 30
    height = 1.72

    # t-string を作成
    template = t"User={user!r}, Age next year={age + 1}, Height={height:.2f}m"

    # t-string の内容を表示
    print(f"template = {template}\n")

    # strings, interpolations, values の内容を表示
    print(f"template.strings = {template.strings}\n")

    print("template.interpolations:")
    for i, interp in enumerate(template.interpolations):
        print(f"  [{i}]")
        print(f"    value        = {interp.value!r}")
        print(f"    expression   = {interp.expression!r}")
        print(f"    conversion   = {interp.conversion!r}")
        print(f"    format_spec  = {interp.format_spec!r}\n")

    print(f"template.values = {template.values}")

if __name__ == "__main__":
    main()

Template 型

t-string の返却は、Template 型となっています。具体的には、string.templatelib.Template です。Template は以下の構造を持ちます。

• strings：テンプレート内の固定文字列部分のタプル
• interpolations：strings 要素間の補間データ（Interpolation）のタプル
• values：式を評価した結果の値のタプル

例の出力結果では以下のようになります。

template.strings = ('User=', ', Age next year=', ', Height=', 'm')

template.interpolations:
  [0]
    value        = '太郎'
    expression   = 'user'
    conversion   = 'r'
    format_spec  = ''

  [1]
    value        = 31
    expression   = 'age + 1'
    conversion   = None
    format_spec  = ''

  [2]
    value        = 1.72
    expression   = 'height'
    conversion   = None
    format_spec  = '.2f'

template.values = ('太郎', 31, 1.72)

上記の結果を見てみると len(strings) == len(interpolations) + 1 という関係が成り立っているので、strings の要素の間に interpolations が挟まれている構造になっていることが分かるかと思います。また、values で各変数の部分にどのような値が埋め込まれるのかを確認できます。

Interpolation 型

interpolations の要素となっている Interpolation 型 についても要素を確認しておきましょう。具体的には、string.templatelib.Interpolation です。

• value：式を評価した結果の値
• expression：元の式を文字列として保持したもの
• conversion：変換指定子（!r / !s / !a）
• format_spec：書式指定文字列（: 以降に記載）

value は式を評価した結果の値を確認できます。また、結果がどのような式により計算されたかについては expression で文字列として確認できます。これは、式レベルで妥当性を評価する際に使用できます。

変換指定子である conversion や書式指定文字列 format_spec は f-string でも指定できる要素です。t-string の特徴の通り、これらの変換はまだ適用されていません。テンプレートを受け取った側がどのような処理をするか判断をして使用します。

t-string の使いどころ

t-string がテンプレートの構造を保持する構造であるということが分かったかと思います。f-string との使い分けを記載すると以下のようになります。

• ”最終的な文字列がほしい” ⇒ f-string
• “文字列化前に、値を安全に処理したい” ⇒ t-string

例えば、ユーザー入力に対して SQL 実行や HTML レンダリングをするような関数やメソッドを作成したとしましょう。この時、引数に str を受け取ると、その文字列に悪意のある文字列が含まれているかを判断するのは大変です。

このような際に、関数やメソッドの引数を t-string（Template 型）を受け取るような形式にしておけば、受け取った側で適切な処理をした上で文字列として活用することができ、SQL インジェクションや XSS の脆弱性に対策した処理をすることが可能です。

まとめ

Python のテンプレート文字列（t-string）の使い方の基本について解説しました。

t-string とは、Python 3.14 で新しく追加されたテンプレート文字列のための構文です。t-string は式と文字列部分を分離して保持し、まだ文字列として変換されていない構造を保持します。この性質により「意図しないコードの実行を防ぎセキュリティ上のリスクを防ぐ安全な処理を実装しやすい」「評価タイミングを呼び出した側に委ねることができる」といったメリットがあります。

t-string は、Template 型となっており、Interpolation 型を含むような構造になっており、その概要についても紹介しました。

t-string は、安全な関数やメソッドを構築する際に非常に便利なものであるため、うまく活用してみてほしいと思います。

あわせて読みたい

【Python Tech】プログラミングガイド

tomllib での TOML ファイルの読み込み

TOML ファイルは、Tom’s Obvious, Minimal Language という設定ファイルフォーマットの 1 種です。Tom というのは、開発者の Tom Preston-Werner 氏からとられています。名称にもあるようにミニマルであることを目指して開発されています。

TOML ファイルは以下のような形式のファイルです。

[DB_SERVER]
HOST = "192.168.1.200"
PORT = 3306

[WEB_SERVER]
HOST = "192.168.1.100"
PORT = 80

セクションは [] で表すことができ、数値はそのまま書けますが、文字列は必ずクォート (") で囲う必要があります。

TOML ファイルは、人が読み書きしやすいような構造となっており、プログラムでも安全に解析できます。Python では、PEP 517 / 518 で pyproject.toml が導入されプロジェクト設定や依存関係、ツール設定を一元化する役割を担っています。

Python の設定ファイル管理では、古くからは INI ファイルが使われており、その後は、インフラや各種ツール設定を中心に YAML ファイルが広く使用されていますが、pyproject.toml の導入をきっかけにプロジェクトや開発ツール設定としてTOMLファイルの利用が急速に増えてきています。

Python では以前は toml や tomli といった外部ライブラリが採用されていましたが、Python 3.11 より tomllib として標準ライブラリ化されたため、簡単に使用することができます。なお、tomli は tomllib の実装のベースとなっています。

この記事では、tomllib を使って TOML ファイルを扱う方法を紹介します。

tomllib の基本的な使い方（読み込み）

tomllib を使用した TOML ファイルの読み込みは以下のようにします。config.toml というファイルを用意して読み込んでいます。

config.toml

[WEB_SERVER]
HOST = "192.168.1.100"
PORT = 80

[DB_SERVER]
HOST = "192.168.1.200"
PORT = 3306

tomllib_basic.py

import tomllib

# TOMLファイルの読み込み
with open("config.toml", "rb") as f:
    config = tomllib.load(f)

# 読み込んだデータの型を確認
print(type(config))

# 読み込んだ値の参照
print(config["WEB_SERVER"])
print(config["WEB_SERVER"]["HOST"])
print(config["WEB_SERVER"]["PORT"])

print(config["DB_SERVER"])
print(config["DB_SERVER"]["HOST"])
print(config["DB_SERVER"]["PORT"])

【実行結果】
<class 'dict'>
{'HOST': '192.168.1.100', 'PORT': 80}
192.168.1.100
80
{'HOST': '192.168.1.200', 'PORT': 3306}
192.168.1.200
3306

TOML ファイルの読み込みを行う場合には、tomllib.load 関数を使用します。ファイルはバイナリモード（"rb"）で open したオブジェクトを指定します。

"r" 開いたオブジェクトでもいいかと思うかもしれませんが、"r" とした場合には以下の TypeError となります。

TypeError: File must be opened in binary mode, e.g. use `open('foo.toml', 'rb')`

これは、TOML が UTF-8 固定の仕様であり、文字コード処理をライブラリ側で一貫して行うためです。

まとめ

Python で TOML ファイルを読み込む際に使用する tomllib の基本的な使い方について解説しました。

TOML は、Python におけるプロジェクト定義の pyproject.toml で使用されており、もちろん他の設定ファイル管理にも使用ができます。Python 3.11 からは、tomllib として標準ライブラリ化したため、より使用しやすくなりました。

tomllib は人が手で直す設定ファイル用途前提であり、TOML ファイルの安全な読み込みを目的とした標準ライブラリであるため、書き込み機能は提供されていない点には注意が必要です。この記事では取り上げていませんが、公式ドキュメントで、Tomli-W や tomlkit といったライブラリが紹介されているので必要に応じて確認してください。

tomllib を使って TOML ファイルを有効活用してもらえたらと思います。

あわせて読みたい

【Python Tech】プログラミングガイド

クリーンアーキテクチャの概要

クリーンアーキテクチャとは

クリーンアーキテクチャとは、Robert C. Martin（Uncle Bob）氏が提唱した、ソフトウェアの設計手法・アーキテクチャパターンの 1 つです。

クリーンアーキテクチャの主な目的は、以下です。

1. 疎結合になり、テストしやすい。
2. 技術選択を後から変更しやすい。
3. ドメインのロジックの見通しがよくなる。
4. 大規模・長期プロジェクトで特に力を発揮する。

クリーンアーキテクチャの考え方を採用することで「変更に強く、テストしやすく、長期運用に耐えうるシステム」を作ることが可能になります。

この記事では、クリーンアーキテクチャの概要について紹介します。

クリーンアーキテクチャの基礎となる 4 層

クリーンアーキテクチャ では、エンティティ (Entities) / ユースケース (Use Cases) / インターフェースアダプター (Interface Adapters) / フレームワークとドライバー (Frameworks & Drivers) という 4 つの代表的な層（レイヤ）があります。

クリーンアーキテクチャは、以下のような図で表現されます。まずは、それぞれの層について概要を説明していきます。

エンティティ (Entities)

エンティティ (Entities) は、企業のビジネスルールのデータをまとめてカプセル化したデータ構造のことを言います。このエンティティは、メソッドを持ったオブジェクトなどであり、企業の様々なアプリケーションから利用されるものです。

機能の追加や UI の変更があっても、ビジネス上で中核となるデータ構造は比較的安定しているため、エンティティは外側の変更の影響を受けにくい層になります。

ユースケース (Use Cases)

ユースケース (Use Cases) は、アプリケーション固有のビジネスルールを定義する層です。ユースケースでは、エンティティのデータをもとに目的を達成するための機能を実装します。

この層は、データベースや UI、その他のフレームワークといった外部の変更から影響を受けることはありません。例えば、データベースが Oracle だとしても、PostgreSQL であったとしても、その上でユースケースとして実装する機能にとってはどちらでもいいのです。

ただし、アプリケーションの画面などの操作変更により、ユースケースに手を加えなければいけないということはあり得ます。

インターフェースアダプター (Interface Adapters)

インターフェースアダプター (Interface Adapters) は、エンティティやユースケースにとって便利なデータフォーマットと、データベースや UI などにとって便利なフォーマットとの間の変換をするためのアダプターです。

インタフェースアダプター層が変換を担うため、ユースケースの層では、外部のデータ構造を意識する必要がなくなります。

フレームワークとドライバー (Frameworks & Drivers)

フレームワークとドライバー (Frameworks & Drivers) は、円の最も外側で最も詳細な部分です。これらは、DB や UI 等の外部インターフェースに関する機能です。

例えば、DB アクセス用のライブラリやデバイスのための制御プログラムなどがこの層に該当します。

SOLID 原則とクリーンアーキテクチャ

SOLID 原則

クリーンアーキテクチャを理解する上で重要な原則に「SOLID 原則」があります。SOLID とは、Robert C. Martin（Uncle Bob）氏が提唱した 保守性と拡張性の高い設計を行うための 5 つの原則 をまとめたものです。

各原則の細かな説明についてはしませんが、SOLID 原則の中でもクリーンアーキテクチャで特に重要な原則である「依存性逆転の法則 (DIP)」については、この記事で考え方を紹介します。

その他の設計原則については、書籍「Clean Architecture 達人に学ぶソフトウェアの構造と設計」を参考にしてください。

クリーンアーキテクチャで特に重要な依存性の方向（DIP)

上記で紹介した SOLID 原則は、いずれも重要な設計原則ですが、その中でもクリーンアーキテクチャを考えるうえで特に重要な原則が「依存性逆転の原則 (DIP: Dependency Inversion Principle)」です。以降、DIPと略します。

プログラミングでは、何も考えずに実装を始めると図でいう外側に依存するようなプログラミングをよくしてしまいます。しかし、DIP では、依存の向きを図における内側、つまり Entities 方向に向けることが重要であると言っています。

依存方向とは、「どちらの変更がどちらに影響するか」を示します。Python を例にすると A が B をインポートしているとき、A は B の変更の影響を受けるため A は B に依存していると言います。矢印としては A → B となります。

import module

例えば、上記例のように module モジュールをインポートしているプログラムは module に依存します。これは module での変更が当該プログラムに影響を与える可能性があるということです。

クリーンアーキテクチャにおいては、Entities や UseCases といった、企業のビジネスルールやアプリケーションのルールが、詳細である外側の層から影響を受けてはいけないということを言っています。

なかなかイメージが難しいと思いますので、DIP に反する依存関係の例と DIP に従っている例を見ながら考えてみましょう。

DIP に反する依存関係の例

以降では、ユーザー情報を DB に登録するような例を使って紹介していきます。まずは、依存関係が DIP に反する例を見てみましょう。

以下は、ユーザー情報を定義した User クラスがあり、CreateUserUseCase クラスで PostgreSQL にユーザー登録している場合です。

この例では、CreateUserUseCase → PostgreSqlUserRepository → PostgreSqlDriver というように内側から外側に向かう依存関係となっています。

この場合、PostgreSqlDriver が変更されると PostgreSqlUserRepository の変更が必要になる可能性があり、その次には、CreateUserUseCase クラスの実装まで変更が波及する可能性があります。

詳細である DB 管理が変更されても、ユースケース自体が何も変更されているわけでもないのにプログラムの修正が必要になってしまうかもしれないわけです。

依存関係の理想（DIP）

では、次に DIP がどのようにこの問題を解決するのかを見てみましょう。以下が、DIPを考慮した場合のクラス図の例です。

抽象化されたインターフェース

DIP でポイントとなるのは、抽象化されたインターフェースの使用です。

例では、UseCases 層で Interface Adapters 層 で実装するべきインターフェース (UserRepository) を定義します。Interface Adapters 層側では、そのインターフェースに従うように PostgreSqlUserRepository の具体的な実装を行います。UseCases 層では、CreateUserUseCase → UserRepository に依存（矢印）が向いているように、具体的な実装ではなく抽象化されたインターフェースに依存します。

同様に、Interface Adapters 層でもインターフェース (DbDriver) を定義し、Frameworks & Drivers 層の PostgreSqlDriver が、そのインターフェースに従って具体的な実装を行います。PostgreSqlUserRepository は 抽象化されたインターフェースである DbDriver に依存します。

この例で、各層の間の矢印を確認してみてください。先ほどの DIP に反した例とは依存関係の矢印が逆向きになっています。これが、依存性逆転と言われる理由です。この逆転のためには、抽象化されたインターフェースがポイントとなります。

依存性の注入

DIP での構成が優れているところは、各層が自身の層で定義したインターフェースで定義された機能の仕様のみ知っておけばよいということです。ここで、仕様と言っているのは、例えば、メソッドの引数、戻り値、それらの型だと思ってください。外側の具体的実装は、そのインターフェースに従うように実装されるため、具体的な詳細まで知る必要がありません。

例では PostgreSql を想定したクラスを例示していますが、UserRepository というインターフェースに従ったクラス（例えば、OracleUserRepository や MySqlUserRepository など）を作成すれば、そのクラスはインターフェース仕様で決められた引数や戻り値、型を持つ機能を実装しているため、付け替えも容易です。

インターフェースを使うため、テスト時にドライバーやスタブを用意しやすい点も重要な特徴です。また、DBMS などの詳細技術が決まっていない段階では、技術の選択を後回しにしてビジネスロジックの開発を進められるという利点があります。

内側の関数やメソッドでは、抽象化されたインターフェースを呼び出すように開発されるため、具体的にインスタンス化するクラスを変更するだけで簡単に実装の変更ができます。このようにどの具象クラスを使うかを外側から渡す方法を「依存性の注入（DI: Dependency Injection）」と言います。DI は、DIP の考え方を現実のコードで実現する代表的な手法の 1 つです。

例のクラス図での UseCases 層と Interface Adapters 層の間の関係性をイメージして、実際に簡単なコードイメージを見てみましょう。

# interface.py
from abc import ABC, abstractmethod

class UserRepository(ABC):

    @abstractmethod
    def save(self, user_name: str) -> None:
        ...

# postgresql_repository.py
from interface import UserRepository

class PostgreSqlUserRepository(UserRepository):

    def save(self, user_name: str) -> None:
        print(f"[PostgreSQL] save user: {user_name}")
        # ※本当は具体的な登録処理が実行される

# usecase.py
from interface import UserRepository

class CreateUserUseCase:

    def __init__(self, repo: UserRepository):
        self.repo = repo  # 抽象に依存

    def execute(self, user_name: str):
        # 具体的なDB処理は知らない
        self.repo.save(user_name)

# main.py
from usecase import CreateUserUseCase
from postgresql_repository import PostgreSqlUserRepository

def main():
    repo = PostgreSqlUserRepository()   # ここで具体を選択（OracleUserRepository に変えれば Oracle に切替が簡単にできる）
    usecase = CreateUserUseCase(repo)   # 依存性の注入（内側へ注入）
    usecase.execute("Taro")

if __name__ == "__main__":
    main()

UserRepository という抽象クラスをインターフェースとして用意し、それを継承して、PostgreSqlUserRepository を作成しています。CreateUserUseCase クラスは実際にユーザーを作成・登録するためのユースケースだと思ってください。

上記でのポイントは、CreateUserUseCase のコンストラクタ __init__ が、抽象の UserRepository を引数に取っている点です。これは、ユースケースが、具体的に PostgreSQL を使うのか、Oracle を使うのかといった具体的なことは全く意識していないということを意味しています。

具体的にどの実装を使うかはエントリポイントである main 関数で選択しています。CreateUserUseCase のインスタンス化で PostgreSqlUserRepository のインスタンスを渡しています。これが、依存性を注入している部分です。

このようにしておくと DB を Oracle に変えたければ、UserRepository を実装した OracleUserRepository を作成し、main 関数でインスタン化するクラスを変えれば、技術の付け替えが完了します。この時には、main 関数のみに変更を加えればよく、 usecase.py を変更する必要が全くないことが非常に重要なことです。

上記で見てきたように DIP の考え方に従うロジックの見通しがよくなり、テストがしやすく、技術選択も後から変更しやすいシステムを構築できます。これにより、特に大規模・長期のプロジェクトでは、改修・維持・管理といった負担が軽減されます。

依存関係の現実

DIP の考え方について紹介しましたが、現実の場面では少し柔軟性を持って考える必要が出てくる場合があります。以下は、Frameworks & Drivers の層として、PostgreSQL を扱うためのモジュールである psycopg2 を使っている例です。

psycopg2 は、コミュニティで開発されているため、自分たちで定義した Interface Adapters 層のインターフェースに従うように機能を実装してもらうことは困難です。そのため、アダプターから psycopg2 への依存はどうしても発生します。

ただし、この依存は外側の詳細同士の依存であり、内側の Entity や UseCase からは、psycopg2 が見えていない限り、DIP の本質は守られていると言えます。

クリーンアーキテクチャでは、DIP を完全に実現することが目的ではなく、重要なビジネスルール（Entity や UseCase）を外部の詳細から守ることがより重要です。

もちろん Frameworks & Drivers 層の機能も自分たちで開発する場合は、DIP に従うように考えるのがベストですが、世の中にある便利なモジュールを使うことは、開発コストを抑えることができて合理的な場合も多くあります。原則にこだわりすぎるのではなく、柔軟な考え方でアーキテクチャを検討するようにしましょう。

ドメイン駆動設計（DDD）との関係

システムの設計では、ドメイン駆動設計（DDD: Domain Driven Design）という設計思想があります。エリック・エヴァンス（Eric Evans）氏が提唱したもので、クリーンアーキテクチャと一緒に語られることが多く、混同されやすいため簡単に整理しておきます。

ドメイン駆動設計は、複雑なビジネスドメインをどのように定義し、正しくモデル化することを目的にした設計思想のことです。一方で、クリーンアーキテクチャは、主にソフトウェアをどのような構造で分割するかといった、システムアーキテクチャの設計手法になります。

ドメイン駆動設計の文脈で出てくる概念をアーキテクチャとして実現する際に、クリーンアーキテクチャの考え方は適用しやすいため、両者は目的は明確に異なりますが、併用されて力を発揮することが多いです。

ドメイン駆動設計に関する書籍としては「エリック・エヴァンスのドメイン駆動設計」「ドメイン駆動設計をはじめよう」「ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本」を参考にしてみてください。

まとめ

ソフトウェアアーキテクチャの 1 つとして有力なクリーンアーキテクチャの概要を解説しました。クリーンアーキテクチャの考え方を採用すると変更に強い、長期運用に耐えうるシステムの開発が可能となります。

この記事では、クリーンアーキテクチャの基本的な概念である 4 つの層の考え方や、アーキテクチャ設計原則である SOLID 原則を紹介しました。また、設計原則の中でも特に中心となる「依存性逆転の原則 (DIP: Dependency Inversion Principle)」について少し深堀をして紹介しました。

プログラミングは文法を覚えるだけでは、良いシステムを開発できるとは限りません。システムアーキテクチャの理解は、学習コストも高く、解釈も人により微妙に異なる場合がある領域かと私は思っています。また、正解のアーキテクチャが決まっているわけではなく、適用するシステムの特徴に合わせて最適なアーキテクチャを十分に検討する必要があるため、非常に難しい領域だと思っています。

この記事を参考にしていただいて、自分の中でシステムアーキテクチャの最適な考え方や理解に落とし込んでいただければと思います。

あわせて読みたい

【Python Tech】プログラミングガイド

Python で Oracle データベースへ接続する

python-oracledb とは？

python-oracledb は、以前広く使われていて cx_Oracle の後継として Oracle 社が提供する公式の Python ライブラリです。ライブラリ名はシンプルに「oracledb」です。これにより、Oracle データベースに対して Python から簡単に接続・操作することができます。

大きな特徴は、Oracle Client が不要な Thin モードに対応しており、手軽に導入ができる点です。一方で、従来の cx_Oracle 同様の機能を活用したい場合は、Thick モードを使用します。

oracledb のインストール方法

oracledb ライブラリは、PyPI で公開されており、以下のように pip install コマンドで簡単にインストールできます。

pip install oracledb

Thin モードと Thick モードの違いと選び方

oracledb は、Thin モードと Thick モードの2つの動作モードを提供しています。

Thin モードは Oracle Client も不要でとても便利です。Thin モードで問題ない場合は、そのままで十分ですが Advanced Queuing などの Oracle 特有機能を使いたい場合には、Thick モードの使用を検討する必要があります。

oracledb を用いたサンプルプログラム

以降では、oracledb を用いて Oracle データベースへアクセスするためのサンプルプログラムを紹介します。

前提条件

サンプルコード

設定ファイルおよびDBアクセスクラス定義

oracledb を使用して Oracle データベースへアクセスするための設定ファイルとDBアクセス用クラスの例は以下のようになります。設定ファイルの内容はお使いの環境にあわせて修正してください。

【dbconfig.ini】DBアクセス設定ファイル

[ORACLE_DB_SERVER]
host = localhost
port = 1521
service = XEPDB1
user = TEST
password = PAssw0rd

【db_connect_oracle.py】DBアクセスクラス

import configparser

import oracledb


class DbConnectOracle:
    """Oracle DBアクセスクラス"""

    def __init__(self, mode: str = "thin", client_lib_dir: str = None) -> None:
        """コンストラクタ

        Args:
            mode: "thin" または "thick"
            client_lib_dir: Thick モードの場合は、Oracle Client のライブラリパス
        """
        # モード判定
        if mode == "thick":
            if client_lib_dir is None:
                raise ValueError(
                    "Thick モードでは client_lib_dir の指定が必要です。"
                )
            oracledb.init_oracle_client(client_lib_dir)
        elif mode != "thin":
            raise ValueError(
                "mode は、'thin' または 'Thick' を指定してください。"
            )

        # iniファイルの読み込み
        config_db = configparser.ConfigParser()
        config_db.read("dbconfig.ini")

        # 設定の読み込み
        host = config_db["ORACLE_DB_SERVER"]["host"]
        port = int(config_db["ORACLE_DB_SERVER"]["port"])
        service_name = config_db["ORACLE_DB_SERVER"]["service"]
        user = config_db["ORACLE_DB_SERVER"]["user"]
        password = config_db["ORACLE_DB_SERVER"]["password"]

        # DSN の作成
        self.dsn = oracledb.makedsn(host, port, service_name=service_name)

        # 接続の確立
        self.con = oracledb.connect(
            user=user,
            password=password,
            dsn=self.dsn,
        )
        self.cursor = self.con.cursor()

    def execute_non_query(self, sql: str, bind_var: dict = None) -> None:
        """SQL 実行メソッド
        (CREATE / INSERT / UPDATE / DELETE 用)

        Args:
            sql: 実行SQL
            bind_var: バインド変数

        Returns: None

        """
        # SQLの実行
        if bind_var is None:
            self.cursor.execute(sql)
        else:
            # バインド変数がある場合は指定して実行
            self.cursor.execute(sql, bind_var)

    def execute_query(
        self, sql: str, bind_var: dict = None, count: int = 0
    ) -> list:
        """SQL 実行メソッド
        (SELECT 用)

        Args:
            sql: 実行SQL
            bind_var: バインド変数
            count: データ取得件数

        Returns: 取得結果リスト

        """
        # SQLの実行
        if bind_var is None:
            self.cursor.execute(sql)
        else:
            # バインド変数がある場合は指定して実行
            self.cursor.execute(sql, bind_var)

        columns = [col[0] for col in self.cursor.description]
        self.cursor.rowfactory = lambda *args: dict(zip(columns, args))

        # 取得結果を返却 (件数指定がある場合は、指定された件数分返却)
        return (
            self.cursor.fetchall()
            if count == 0
            else self.cursor.fetchmany(count)
        )

    def commit(self) -> None:
        """コミット

        Returns: None

        """
        self.con.commit()

    def rollback(self) -> None:
        """ロールバック

        Returns: None

        """
        self.con.rollback()

    def __del__(self) -> None:
        """デストラクタ

        Returns: None

        """
        self.cursor.close()
        self.con.close()


if __name__ == "__main__":
    pass

使用例（Thin モード）

oracledb の Thin モードを使用して上記で作成したクラスを用いてOracleへの接続をするには以下のように使用します。

from db_connect_oracle import DbConnectOracle


def main():
    # Thin モードでアクセスする場合
    db_oracle = DbConnectOracle()

    # ===== テーブルを作成する
    create_sql = (
        "CREATE TABLE SAMPLE_TABLE"
        "("
        "ID NUMBER GENERATED ALWAYS AS IDENTITY,"
        "STR1 VARCHAR2(50), "
        "VALUE1 NUMBER, "
        "LAST_UPDATE_DATETIME TIMESTAMP, "
        "PRIMARY KEY (ID)"
        ")"
    )
    db_oracle.execute_non_query(create_sql)
    # コミット
    db_oracle.commit()

    # ===== データをINSERTする
    insert_sql = (
        "INSERT INTO SAMPLE_TABLE "
        "(STR1, VALUE1, LAST_UPDATE_DATETIME) "
        "VALUES(:str1, :val1, CURRENT_TIMESTAMP)"
    )
    for i in range(5):
        input_str = f"test_str{i}"
        input_val = 10 * i
        bind = {"str1": input_str, "val1": input_val}
        db_oracle.execute_non_query(insert_sql, bind)
    # コミット
    db_oracle.commit()

    # ===== データを検索する (全て検索)
    print("===== 全件検索")
    select_sql = "SELECT * FROM SAMPLE_TABLE"
    select_result = db_oracle.execute_query(select_sql)
    print(select_result)

    # ===== 件数を指定して検索する (以下の例は3件)
    print("===== 取得する件数の指定")
    select_sql = "SELECT * FROM SAMPLE_TABLE"
    select_result = db_oracle.execute_query(select_sql, count=3)
    print(select_result)

    # ===== 条件を指定して検索する
    print("===== 条件を指定して実行する")
    select_sql = "SELECT * FROM SAMPLE_TABLE WHERE VALUE1 > :val1"
    print("条件１")
    select_result = db_oracle.execute_query(select_sql, {"val1": 10})
    print(select_result)
    print("条件２")
    select_result = db_oracle.execute_query(select_sql, {"val1": 30})
    print(select_result)


if __name__ == "__main__":
    main()

使用例（Thick モード）

oracledb の Thick モードを使用する場合には、クラスをインスタンス化する際に以下の引数を設定してください。

• mode："thick"
• client_lib_dir：Oracleクライアントライブラリが格納されているパス

以下の例では、Oracle の Instant Client (軽量版クライアント) を使用した場合の例です。フルのOracle Clientの場合は、環境にあわせて r"C:\oracle\product\19.0.0\client_1\bin" のような指定をしていただければいいかと思います。

from db_connect_oracle import DbConnectOracle


def main():
    mode = "thick"
    client_lib_dir = r"C:\oracle\instantclient_21_18"

    # Thick モードでアクセスする場合
    db_oracle = DbConnectOracle(
        mode=mode,
        client_lib_dir=client_lib_dir,
    )

    # 以降は、Thin モードと同じ
    # ・・・


if __name__ == "__main__":
    main()

サンプルコードのポイント解説

DBアクセス用クラス DBConnectOracle

DBアクセス用のクラスとして DbConnectOracle というクラスを定義しています。メソッドとして定義しているものは以下になります。

まとめ

python-oracledb を用いてOracleデータベースへアクセスする方法について解説しました。

このライブラリは、Oracle 公式であり、Oracle アクセス手段として非常に強力です。これまで使われていた cx_Oracle の後継として使用することができます。

Thin モードと Thick モードが用意されており、Thin モードではOracle Client不要で手軽に使用することができます。また、高度な機能が必要であれば Thick モードの使用を検討してください。

この記事では、汎用的に使えるDBアクセスクラスを作成して OracleDB へのアクセスをできるようにしてみました。ぜひ、参考にしていただいて Oracle 接続に活用していただければと思います。

あわせて読みたい

【Python Tech】プログラミングガイド

エスティマンドの概要

因果推論は、ある処置（介入）を行った際に出力に与える影響を推定するための手法です。ここで処置（介入）とは、例えば治療や政策介入など影響を与える動きのことを言っています。

因果推論では「何を知りたいのか？」を明確にするためにエスティマンドという概念が重要になります。この記事では、因果推論におけるエスティマンドの概念について説明し、代表的なエスティマンドの種類を紹介します。

推定器と推定量

データから因果関係を推定する際には「推定器（Estimator）」と「推定量（Estimate）」があります。

• 推定器：因果効果やパラメータを推定するために使用される統計的手法やアルゴリズムのこと
• 推定量：特定のデータセットをもとに推定器を適用した結果の数値

推定器には、単純な平均などを計算するものから、ディープラーニングのように数億ものパラメータを使った言語モデルまで多岐にわたります。推定器を用いて具体的なデータセットに対して計算を行った結果が推定量になります。

エスティマンドとは

エスティマンド（Estimand）は、理論的に求めたい因果効果を数学的に定義したものです。これは、どのような因果効果を測定しようとしているかを明確にするための概念です。実際にデータから算出される推定量（Estimate）とは異なり、エスティマンドは「もしバイアスのない完全なデータが利用できるならば求められる理想的な値」と考えることができます。

例えば、薬の効果を知りたい場合、同じ人が治療を受けた場合と受けなかった場合の結果を比較したいと考えます。しかし、現実には同じ個体に対して両方の状況を同時に観測することはできないため、反事実（Counterfactual）を推定する必要があります。反事実は、因果推論の重要な概念である「因果のはしご」において扱われるものです。

このような反事実も考慮しながら因果効果を定義することがエスティマンドの役割であり、そもそも何を推定しようとしているかを定義するためにあります。

代表的なエスティマンド

代表劇なエスティマンドに這いつくか種類があり研究の目的に応じて選択することになります。ここでは、代表的なものを紹介していきます。

平均因果効果
(ATE : Average Treatment Effect)

平均因果効果（ATE: Average Treatment Effect）は、母集団における平均的な因果効果を示します。数式で表現すると以下のようになります。

\[
\begin{eqnarray}
ATE=E[Y(1) – Y(0)]
\end{eqnarray}
\]

ここで各要素は以下のような意味を持ちます。

• $Y(1)$：処置を受けた場合の出力
• $Y(0)$：処置を受けなかった場合の出力
• $E[\cdot]$：期待値

ATE は、処置を受けた場合と受けなかった場合の出力の差の期待値ということになるため、文章にしてみると「もし、全ての個体が処置（介入）を受けた場合と受けなかった場合を比較したらどうなるか」を測る指標となります。

処置群における平均因果効果
(ATT: Average Treatment Effect on the Treated)

処置群における平均因果効果（ATT: Average Treatment Effect on the Treated）は、実際に処置（介入）を受けた集団における因果効果を示します。数式で表現すると以下のようになります。

\[
\begin{eqnarray}
ATT=E[Y(1) – Y(0) | D=1]
\end{eqnarray}
\]

ここで、$D=1$ は処置（介入）を受けた個体を意味します。これは「実際に処置（介入）を受けた人に対して、どの程度の影響を与えたか」を評価する指標となります。

対照群における平均因果効果
(ATU: Average Treatment Effect on the Untreated)

対照群における平均因果効果（ATU: Average Treatment Effect on the Untreated）は、処置（介入）を受けなかった集団における因果効果を示します。数式で表現すると以下のようになります。

\[
\begin{eqnarray}
ATU=E[Y(1) – Y(0) | D=0]
\end{eqnarray}
\]

ここで、$D=0$ は処置（介入）を受けなかった個体を意味します。これは「もし処置（介入）を受けなかった人に対して、どの程度の影響があったか」を評価する指標となります。

条件付き平均因果効果
(CATE: Conditional ATE)

条件付き平均因果効果（CATE: Conditional ATE）は、特定の条件を満たす個体群における因果効果を示します。数式で表現すると以下のようになります。

\[
\begin{eqnarray}
CATE=E[Y(1) – Y(0) | X=x]
\end{eqnarray}
\]

ここで、$X$ は特定の個体の特徴（例えば、年齢、性別、健康状態など）を表します。$X$ が特定の $x$ であるときの平均因果効果が CATE になります。

CATE は「特定の条件のサブグループに対して処置（介入）をした効果がどの程度の影響があったのか」を評価する際に有用です。機械学習モデルを利用して個々の特性ごとの処置効果のばらつきを捉える「異質な処置効果（Heterogeneous Treatment Effect）」の分析において、特に重要な指標となります。

まとめ

因果推論において重要な概念であるエスティマンドの概念について解説しました。

エスティマンドは、因果推論において「何を知りたいのか」を明確にするための重要な概念であり、代表的なエスティマンドとして ATE、ATT、ATU、CATE があります。

• ATE : 母集団全体における平均因果効果
• ATT : 処置（介入）を受けた人における因果効果
• ATU : 処置（介入）を受けなかった人における因果効果
• CATE : 特定の条件を満たす人における因果効果

実際のデータ分析では、これらのエスティマンドを適切に定義し、推定する手法を選択することが求められます。エスティマンドの考え方をしっかり理解してもらえたらと思います。

あわせて読みたい

【Python Tech】プログラミングガイド

d 分離（d-separation）とは？

d 分離の概要

因果推論では、変数間の関係を因果ダイアグラム（Causal Diagram）、特に有効非巡回グラフ（DAG: Directed Acyclic Graph）を用いて表現することが一般的です。因果ダイアグラムについては「因果ダイアグラムの概要」を参考にしてください。

グラフにおける d 分離（d-separation）とは、2 つのノード（変数）の集合 X と Y の間の統計的依存関係が遮断されることを意味します。つまり、d 分離が成り立つとき、適切な確率分布のもとで X と Y は独立となります。ただし、全ての確率分布で成り立つわけではなく、特にベイジアンネットワークの仮定（DAG に沿った因果構造をもつ確率分布）では、d 分離であれば統計的独立が保証されます。

なお、d 分離は因果推論に特化した概念ではなく、グラフィカルモデル全般において使用される統計的独立性の判断基準です。例えば、ベイジアンネットワークや機械学習における確率的モデリングの分野でも重要な役割を果たします。

因果推論の分野では、d 分離を用いることで観測データに基づく推論の際に、どの変数をコントロールするべきか判断するのに役立ちます。この記事では、d 分離の概要について紹介します。

d 分離の定式化

d 分離の説明していくにあたってまずは一般的な考え方として表現します。

ノードの集合として X、Y、Z があるとします。より簡単にはノード 1 つで考えることですが、集合を 1 つと考える場合と思っていただければと思います。このとき、X と Y を結ぶすべてのパスが Z によってブロックされるとき X と Y は Z によって d 分離されていると言います。

例えば、例として以下のようなグラフが考えられます。上の図は複数ノードから成り立っており、集合 X、Y、Z に分類することができます。下の図は各集合が 1 つのノードで成り立っている場合の例です。

これらのグラフが与えられたときにパスがブロックされて d 分離されるかの判断基準について以降で説明していきます。

チェーン、フォーク、コライダーとの関連性

因果推論の因果ダイアグラムにおいて重要な構造としてチェーン、フォーク、コライダーという構造があります。これらの構造については「チェーン、フォーク、コライダーの構造と特徴」を参考にしてください。

これらの構造と d 分離の関係は以下のように整理できます。X と Y の関係性において Z に条件付けるかどうかで d 分離（パスがブロック）されるかが判断できます。

【補足】「条件付ける」と「コントロールする」の違い

因果推論の勉強をしていると「条件付ける」という言葉や「コントロールする」という言葉が出てきます。これらについては、使われ方によってほぼ同じ意味で使われることがありますが、厳密にはニュアンスが少し異なります。

条件付ける（Conditioning）

「条件付ける」という言葉は、統計的な意味合いが強い場合で使用されます。確率分布の条件を設定することを指していて条件付確率 P(X, Y | Z) のように表されます。

あるノード（変数）の情報を得ることにより確率分布が変わるイメージです。例えば、ある病気の診断 Z を知ったうえで、遺伝子 X と生活習慣 Y の関係を考えるような場合、Z に条件付けると言います。

コントロール（Controlling）

「コントロールする」という言葉は、因果推論の文脈で使われることが多いです。「ある変数の影響を取り除く」ことを意図します。

実際のデータ分析では、回帰モデルの説明変数として対象変数を入れることをコントロールすると表現します。例えば、年収 Z をコントロール（年収帯を固定するなど）することで、教育水準 X と健康状態 Y の関係性を見極めるような場合です。

どのように使うべきか

まとめてみると「条件付ける」と「コントロールする」という表現は以下のように使い分けることが適切です。

• d 分離の文脈：「条件付ける」という表現が適切
• 因果推論の文脈：「コントロールする」という表現が適切

まとめ

確率的グラフィカルモデルの重要な概念である d 分離（d-separation）について解説しました。d 分離は因果推論に特化した概念ではなく、グラフィカルモデル全般において使用される統計的独立性の判断基準ですが、この記事では因果推論に絡めつつ説明をしました。

d 分離を判断するためには、チェーン、フォーク、コライダーといったグラフにおける重要な構造に紐づけて調べる必要があります。d 分離を用いることで観測データに基づく推論の際に、どの変数をコントロールするべきか判断するのに役立ちます。d 分離についてぜひ学んで理解を深めてみてください。

あわせて読みたい

【Python Tech】プログラミングガイド