Pythonで開発していると、実行はできるものの、画面にずらっと表示されるwarnings(警告)に悩まされることがよくあります。
無視してよいのか、修正すべきなのか、そもそも非表示にしてよいのか判断に迷う場面も多いはずです。
本記事では、Pythonのwarningsを「理解する」「非表示にする」「例外やログとして扱う」ための7つの実践テクニックを、図解とサンプルコードを交えて詳しく解説します。
Pythonのwarningsとは
warningsモジュールの基本と役割

Pythonのwarningsモジュールは、プログラムの実行を止めずに「これは問題になるかもしれない」という情報をユーザーに伝えるための仕組みです。
典型的には、古いAPIの利用や将来的な仕様変更、潜在的な非推奨パターンなどを知らせる用途で使われます。
Python標準ライブラリに含まれており、次のような役割を持っています。
- 警告メッセージの発行(
warnings.warn()) - カテゴリ(種類)別の警告クラスの定義
- フィルタ機構による表示・非表示・1回だけ表示・例外化の制御
- コマンドラインオプションや環境変数からの一括制御
基本的な使い方は次のようになります。
import warnings
def old_function():
# 将来的に廃止予定の関数だと仮定
warnings.warn(
"old_function() は将来的に削除されます。new_function() を使用してください。",
category=DeprecationWarning,
stacklevel=2, # 呼び出し元の行を警告場所として表示
)
return 42
def main():
result = old_function()
print(result)
if __name__ == "__main__":
main()
このようにwarnings.warn()を使うことで、処理は続行しつつもユーザーに注意喚起ができます。
エラー(exception)との違い

Pythonの例外(Exception)と警告(Warning)は、目的と挙動が明確に異なります。
例外は「このまま処理を続けると破綻するので、ただちに中断すべき状態」を表し、発生すると通常はスタックトレースが表示され、プログラムはその場で停止します。
これに対し、警告は「今は動いているが、潜在的な問題や将来の破綻要因がある状態」を示し、原則として処理は継続されます。
もう一点重要なのは、制御方法の違いです。
例外はtry/exceptによって捕捉し、警告はwarningsモジュールやコマンドラインオプションで表示方法を制御します。
混同しないように注意が必要です。
よく出るDeprecationWarningなどの種類

Pythonの警告は、カテゴリごとにクラス分けされています。
よく見かける代表的なものをまとめると次のようになります。
| カテゴリ名 | 説明 | 実務での扱い方の目安 |
|---|---|---|
| DeprecationWarning | 非推奨機能の利用。将来のバージョンで削除予定 | 早めに修正推奨。開発中は表示させる |
| FutureWarning | 仕様変更などにより将来挙動が変わる予定 | 仕様変更内容を確認しコード修正を検討 |
| UserWarning | ライブラリ作者などが任意に発行する一般的な警告 | 文言をよく読み、必要に応じて対応 |
| RuntimeWarning | 数値計算や実行時評価での問題(オーバーフローなど) | 本番では要注意。例外化も検討 |
| SyntaxWarning | 将来構文エラーになり得るような危うい構文 | コード修正を強く推奨 |
| ResourceWarning | ファイル・ソケットなどリソース解放忘れの可能性 | バグの可能性大。早めに調査 |
| ImportWarning | モジュールのインポートに関する注意(非推奨等) | 該当モジュールの利用方法を再確認 |
特にDeprecationWarningは、Python本体や外部ライブラリのバージョンアップで頻出します。
放置していると、ある日突然「AttributeError」や「ImportError」で落ちることにつながりますので、定期的に確認しておくことが重要です。
warningsを非表示にするテクニック
warningsを一時的に無効化する

実務では、一部のコードだけ一時的に警告を抑制したい場面があります。
たとえば、どうしても修正できない古い外部ライブラリを呼び出す部分や、テストで意図的に警告を発生させるが、ログ汚染は避けたい場合などです。
そのようなときは、warnings.catch_warnings() と filterwarnings() を組み合わせて使います。
import warnings
def use_legacy_library():
# ここでは仮に非推奨APIを呼び出しているとする
warnings.warn(
"このAPIは非推奨です。",
category=DeprecationWarning,
stacklevel=2,
)
def main():
print("=== 通常の動作 (警告が表示される) ===")
use_legacy_library()
print("\n=== 一時的に警告を無効化 ===")
# catch_warnings() コンテキスト内では警告を一時的に制御できる
with warnings.catch_warnings():
# すべての警告を無視する設定
warnings.simplefilter("ignore")
use_legacy_library()
print("\n=== コンテキスト外では再び警告が表示される ===")
use_legacy_library()
if __name__ == "__main__":
main()
=== 通常の動作 (警告が表示される) ===
/path/to/script.py:7: DeprecationWarning: このAPIは非推奨です。
warnings.warn(
=== 一時的に警告を無効化 ===
=== コンテキスト外では再び警告が表示される ===
/path/to/script.py:7: DeprecationWarning: このAPIは非推奨です。
warnings.warn(
このようにコンテキストマネージャを使うと、「この処理の間だけ警告OFF」という粒度の制御が可能になります。
コマンドラインでwarningsを非表示にする

Pythonはコマンドラインオプション-Wで警告の表示方法を制御できます。
もっともシンプルなのは、すべての警告を無視する設定です。
python -W ignore your_script.py
-Wオプションは、次の形式を取ります。
-W action:message:category:module:line
ここで最低限よく使うのはaction部分で、以下の値を指定できます。
| action | 意味 |
|---|---|
| ignore | 警告を無視して表示しない |
| default | デフォルト動作(Pythonの標準設定) |
| error | 警告を例外に変換する |
| always | 常に表示する |
| module | モジュールごとに1回だけ表示する |
| once | プログラム全体で1回だけ表示する |
たとえば、「警告をすべて例外として扱いたい」場合は次のようにします。
python -W error your_script.py
このようなコマンドライン指定はテスト実行やCI環境で一括制御したい場合に特に有用です。
特定モジュール・特定カテゴリだけ非表示にする

実務では「この外部ライブラリのDeprecationWarningだけ無視したい」といった、限定的な抑制が求められることが多いです。
こうした場合はwarnings.filterwarnings()を使います。
import warnings
import some_legacy_lib # 仮の古いライブラリ名とする
# 1. ライブラリ内で発生する DeprecationWarning だけ無視
warnings.filterwarnings(
action="ignore", # 無視する
category=DeprecationWarning, # DeprecationWarningのみ
module=r"^some_legacy_lib(\.|$)", # 正規表現でモジュール名を指定
)
def main():
# ここで old_api() が DeprecationWarning を出すと仮定
some_legacy_lib.old_api()
if __name__ == "__main__":
main()
module引数には正規表現を渡せるため、特定モジュール配下のみに絞り込むことが可能です。
抑制範囲を狭くすることで、本来見るべき警告まで消してしまうリスクを減らせます。
同じことはコマンドラインからも行えます。
たとえば「DeprecationWarningだけ無視する」なら次のようにします。
python -W "ignore::DeprecationWarning" your_script.py
カテゴリをさらに絞ることで、必要な警告は残しつつ、ノイズだけを減らすことができます。
テストコードでのwarnings非表示

テストコードでは、警告をどう扱うかが重要です。
放置するとテストのログが警告だらけになり、本当に重要な警告が埋もれてしまうためです。
一方で、完全に無視してしまうと将来の破綻を見逃すことになります。
代表的なテストフレームワークであるpytestには、警告を制御するためのオプションと設定が用意されています。
最も簡単なのは、コマンドラインから指定する方法です。
# すべての警告をエラーにする (推奨: CIなどで利用)
pytest -W error
# 特定カテゴリだけ無視する例
pytest -W "ignore::DeprecationWarning"
頻繁に使う設定はpytest.iniに書いておくと便利です。
# pytest.ini
[pytest]
filterwarnings =
# プロジェクト外ライブラリからの DeprecationWarning を無視
ignore::DeprecationWarning:third_party_lib\.
# 自分のコードの DeprecationWarning はエラーにする
error::DeprecationWarning:my_project\.
このようにテスト時にだけ厳しく(or 緩く)警告を扱うことで、本番運用に影響を出さずに品質を高めることができます。
warningsを例外化・ログ化するテクニック
warningsを例外として扱う

一部の警告は、実質的にエラーとみなした方が安全なケースがあります。
たとえば、数値計算でのRuntimeWarningやリソースリークを示すResourceWarningなどです。
このような場合、warnings.filterwarnings()でaction="error"を指定すると、対象の警告を例外に変換できます。
import warnings
def risky_calculation(x, y):
if y == 0:
# 本来はエラーにしたい状況だが、既存挙動の都合で警告だけ出していると仮定
warnings.warn(
"0除算が発生します。結果は無限大になります。",
category=RuntimeWarning,
stacklevel=2,
)
return float("inf")
return x / y
def main():
# RuntimeWarning をエラーとして扱う
warnings.filterwarnings("error", category=RuntimeWarning)
try:
result = risky_calculation(10, 0)
print(result)
except RuntimeWarning as e:
print("RuntimeWarning を例外として捕捉:", e)
if __name__ == "__main__":
main()
RuntimeWarning を例外として捕捉: 0除算が発生します。結果は無限大になります。
このようにすることで、「一見動いているが危うい状態」を明示的なエラーとして取り扱うことができます。
例外化して問題箇所を早期にあぶり出す方法

プロジェクトをリファクタリングしたり、Pythonやライブラリのバージョンを上げると、warningsが大量に出ることがあります。
これを放置すると、本番投入後に仕様変更へ対応しきれず、予期せぬエラーにつながってしまう可能性があります。
そこで有効なのが、開発環境やCIで一時的に「全warningsを例外扱い」にするアプローチです。
# conftest.py (pytest の共通設定ファイルとして利用する想定)
import warnings
def pytest_configure(config):
# テスト実行時は、すべての Warning をエラー(例外)として扱う
warnings.filterwarnings("error")
この設定を有効にしてテストを走らせると、これまで単にメッセージが表示されていただけの警告がすべて例外に変わり、問題のある箇所がテスト失敗として浮き彫りになります。
一度にすべてを例外化するのが難しい場合は、カテゴリ単位やモジュール単位で徐々に厳しくしていく戦略も有効です。
# 例: まずは DeprecationWarning だけ厳しくする
warnings.filterwarnings("error", category=DeprecationWarning)
このように、「開発・CIでは厳しく、本番ではやや緩く」という住み分けをすることで、品質と安定性のバランスをとることができます。
warningsをログに出力する

本番環境では、警告を画面(標準エラー)に出しっぱなしにするより、ログとして一元管理したいケースが多くなります。
そのために使えるのが、warnings.showwarningのフックとloggingモジュールの連携です。
import logging
import warnings
import sys
# ログ設定
logger = logging.getLogger("app")
logger.setLevel(logging.INFO)
handler = logging.StreamHandler(sys.stdout)
formatter = logging.Formatter(
"[%(asctime)s] [%(levelname)s] %(name)s - %(message)s"
)
handler.setFormatter(formatter)
logger.addHandler(handler)
def log_warning_to_logger(message, category, filename, lineno, file=None, line=None):
"""
warnings.showwarning と同じシグネチャの関数を定義し、
ここで logging に流し込む。
"""
logger.warning(
"Warning (%s) at %s:%d: %s",
category.__name__,
filename,
lineno,
message,
)
def setup_warning_logging():
# デフォルトの showwarning を差し替える
warnings.showwarning = log_warning_to_logger
def main():
setup_warning_logging()
# 適当に警告を発生させてみる
warnings.warn("これはテスト用の警告です。", UserWarning)
if __name__ == "__main__":
main()
[2025-01-01 12:00:00,000] [WARNING] app - Warning (UserWarning) at /path/to/script.py:37: これはテスト用の警告です。
このようにwarningsの出力先を自前のログ処理に差し替えることで、監視基盤や分析ツールへの連携が容易になります。
ログレベル別にwarningsを記録する

カテゴリごとにログレベルを変えたい場合は、categoryで分岐してlogger.infoやlogger.errorを呼び分けるだけです。
import logging
import warnings
import sys
logger = logging.getLogger("app")
logger.setLevel(logging.INFO)
handler = logging.StreamHandler(sys.stdout)
formatter = logging.Formatter(
"[%(asctime)s] [%(levelname)s] %(name)s - %(message)s"
)
handler.setFormatter(formatter)
logger.addHandler(handler)
def log_warning_with_levels(message, category, filename, lineno, file=None, line=None):
"""
Warning カテゴリに応じてログレベルを変える例。
"""
text = f"Warning ({category.__name__}) at {filename}:{lineno}: {message}"
if issubclass(category, DeprecationWarning):
# 非推奨は情報レベルで記録
logger.info(text)
elif issubclass(category, RuntimeWarning):
# 実行時の危険な状態はエラーレベルで記録
logger.error(text)
else:
# その他は通常の警告レベル
logger.warning(text)
def setup_warning_logging():
warnings.showwarning = log_warning_with_levels
def main():
setup_warning_logging()
warnings.warn("古いAPIを使用しています。", DeprecationWarning)
warnings.warn("0除算が発生しました。", RuntimeWarning)
warnings.warn("その他の注意喚起です。", UserWarning)
if __name__ == "__main__":
main()
[2025-01-01 12:00:00,000] [INFO] app - Warning (DeprecationWarning) at /path/to/script.py:32: 古いAPIを使用しています。
[2025-01-01 12:00:00,001] [ERROR] app - Warning (RuntimeWarning) at /path/to/script.py:33: 0除算が発生しました。
[2025-01-01 12:00:00,002] [WARNING] app - Warning (UserWarning) at /path/to/script.py:34: その他の注意喚起です。
このようにログレベルを分けることで、重要度の高い警告だけを監視通知の対象にするといった運用が可能になります。
実務で使えるwarnings制御のベストプラクティス
ライブラリ開発でのwarningsの出し方と抑え方

ライブラリを提供する立場では、warningsの出し方そのものがAPI設計の一部になります。
特に非推奨化(Deprecation)の際には、利用者に配慮した段階的移行が重要です。
推奨されるパターンとしては、次のような流れがあります。
- 機能を非推奨にするバージョンで
DeprecationWarningを追加 - ドキュメントやリリースノートで非推奨化を明記
- 少なくとも1〜2メジャーバージョンは
DeprecationWarningのみで猶予を与える - その後のバージョンで実際に機能を削除し、
ImportErrorやAttributeErrorに切り替える
コード例を示します。
# mylib/old_module.py
import warnings
def old_api():
warnings.warn(
"old_api() は非推奨です。new_api() を使用してください。",
category=DeprecationWarning,
stacklevel=2,
)
# 旧来の処理…
return "old"
def new_api():
return "new"
ライブラリ側でstacklevelを適切に設定しておくと、利用者のコード位置が警告に表示されるため、対応がしやすくなります。
一方、ライブラリ内部で自分自身の警告を抑制したい場合もあるため、内部利用に対するフィルタを用意することもあります。
ただし、ユーザーが制御できなくなるため、必要最小限にとどめることが望ましいです。
本番環境(production)でのwarnings運用設定

本番環境では、一般的に次のような方針が現実的です。
- 画面(標準エラー)への大量出力は避ける
- ログとして記録し、モニタリング対象にする
- クリティカルなカテゴリ(例: RuntimeWarning, ResourceWarning)は例外化または高レベルログで扱う
環境変数PYTHONWARNINGSを用いて一括制御する方法も有効です。
# 例: 本番環境で DeprecationWarning を非表示、RuntimeWarning をエラー化
export PYTHONWARNINGS="ignore::DeprecationWarning,error::RuntimeWarning"
python app.py
アプリケーションコード側では、先ほど紹介したshowwarningの差し替えでログ出力への集約を行い、さらに監視ツール(CloudWatch, Stackdriver など)と連携しておくと、重大な警告を早期に検知できます。
CIテストでwarningsを検出・制御する

CI環境では、warningsを品質ゲートの一部として扱うことが増えています。
具体的には、次のような戦略が考えられます。
- すべての
DeprecationWarningをエラー扱いにし、テスト失敗とする - 新規追加の
RuntimeWarningを許可しない - 一定回数以上の警告発生をビルド失敗条件にする
pytestを使う場合は、前述のようにpytest.iniやconftest.pyでwarnings.filterwarningsを設定します。
CIのジョブ定義(例: GitHub Actions, GitLab CI)では、次のようなステップを設けることができます。
# 例: GitHub Actions での pytest 実行 (抜粋)
- name: Run tests with strict warnings
run: |
export PYTHONWARNINGS="error::DeprecationWarning"
pytest -W error
このようにしておけば、非推奨APIの利用が混入した時点でCIが落ちるため、問題を早期に発見できます。
Pythonバージョンアップ時のwarnings対応戦略

Python本体のバージョンを上げる際には、warningsが重要なナビゲーションになります。
特にDeprecationWarningとFutureWarningは、将来破綻するコードを事前に教えてくれるサインです。
現実的な対応フローの一例を挙げます。
- 既存バージョンで
PYTHONWARNINGS="default"などとして、警告をすべて表示 - テストを実行し、発生する警告をログに収集
- カテゴリ別・モジュール別に件数を集計し、優先度を決める
- 外部ライブラリ由来の警告は、ライブラリ側のアップデートで解消できないか確認
- 自前コード由来の
DeprecationWarningは、順次推奨APIへの書き換えを実施 - 新バージョンのPythonでテストを行い、warningsを一時的に例外化して漏れをチェック
移行作業中は、たとえば次のように段階的に厳しさを上げていくとスムーズです。
# フェーズ1: まずは表示だけ
export PYTHONWARNINGS="default"
# フェーズ2: DeprecationWarning だけ例外化
export PYTHONWARNINGS="error::DeprecationWarning"
# フェーズ3: すべての Warning を例外化 (一時的に)
export PYTHONWARNINGS="error"
このようにwarningsを「ノイズ」ではなく「設計変更のシグナル」として活用することで、バージョンアップのリスクを大きく下げることができます。
まとめ
Pythonのwarningsは、単なるうるさいメッセージではなく、将来のバグや互換性問題を事前に知らせてくれる重要な仕組みです。
本記事では、warningsの基本から、非表示・例外化・ログ化の具体的なテクニック、さらにライブラリ開発や本番運用、CI、バージョンアップといった実務シナリオでの活用方法までを解説しました。
ポイントは、「開発やテストでは厳しく扱い、本番ではログと監視でケアする」というバランスです。
ここで紹介した設定とサンプルコードをベースに、自分のプロジェクトに最適なwarnings運用ポリシーを設計してみてください。
