はじめに：存在確認ロジックに潜む“癖”

Pythonでファイルの存在確認をする方法として、os.path.existsは定番中の定番です。私自身もこの方法に長らく慣れ親しんできました。しかし、あるとき他のエンジニアが書いたコードで、「ファイルの存在をファイル数のカウントでチェックしている」場面に出会い、ハッとしました。「存在確認」の目的は同じでも、ロジックの組み方に“癖”が出るという事実──本記事では、このようなコードスタイルの違いと、その背景や実務での影響について整理していきます。

Pythonにおけるファイル存在確認の基本

公式ドキュメントでは、Pythonでファイルやディレクトリの存在確認を行うにはos.pathモジュールを使うのが一般的とされています。中でも以下の関数はよく利用されます。

os.path.exists(path): ファイル・ディレクトリの両方を対象に存在確認
os.path.isfile(path): ファイルのみを対象に確認
os.path.isdir(path): ディレクトリのみを対象に確認

しかし、公式には「存在確認」そのものの手法は示されているものの、どのようにロジックを構成すべきかといった実践的な部分はほとんど触れられていません。ここが実務での実装方針に個性が出るポイントとなっています。

よくある“数で確認する”存在チェックの癖

実際に私が遭遇したコードは次のようなものでした。

import os

def is_folder_empty(folder_path):
    return len(os.listdir(folder_path)) == 0

if not is_folder_empty("/path/to/dir"):
    print("ファイルがあります")
else:
    print("ファイルがありません")

このコードではos.listdir()を使ってファイル一覧を取得し、その 件数が0かどうか で存在確認をしています。一見遠回りにも思えますが、実はこの方法には 「中身が空かどうかも同時に判定したい」 という意図が隠れている場合があります。

比較：`os.path.exists` と `os.listdir` の使い分け

# os.path.existsを使うケース（ファイル・フォルダの有無を知りたいだけ）
import os

if os.path.exists("/path/to/file_or_dir"):
    print("存在します")

# os.listdirを使うケース（ディレクトリ内が空かどうか確認したいとき）
import os

files = os.listdir("/path/to/dir")
if len(files) > 0:
    print("ファイルがあります")

このように、前者は 存在の有無、後者は 空かどうか を判断したいときに向いています。ただし、空であることが「存在しない」と同義ではない点に注意が必要です。

なぜ“癖”が出るのか？背景にある意識と設計

このようなコードスタイルの違いは、単なる記法の違いではなく、次のような背景が影響しています。

例外処理の設計方針（try-exceptを使う vs 条件分岐で逃がす）
エラーの原因調査を容易にしたいという保守性の意識
コードレビュー文化：明示的な意図の共有が求められるプロジェクト
個人の習慣や、過去に遭遇した不具合経験

例えば「フォルダはあるけどファイルが0件」な状態で不具合になった経験があるエンジニアは、以降len(os.listdir()) == 0のようなスタイルを好む傾向があります。

実務でのTipsと注意点

以下に、存在確認 に関するベストプラクティスと注意点をまとめます。

単純な存在確認だけなら os.path.exists を使うのがベスト
os.listdirはフォルダが存在しない場合エラーになるので例外処理が必要
ファイルの種類まで厳密に確認したい場合は os.path.isfile も併用
データ処理系のバッチなどでは「ファイルがN件以上なら処理実行」といった条件で len() を使うのが実務では一般的
ユニットテストの際は モックを使って存在確認の挙動を再現 するのがベター

まとめ：ロジックは「何を守りたいか」で変わる

ファイルの存在確認という単純な処理であっても、ロジックの組み方にはエンジニアの 経験・思想・責任感 がにじみ出ます。コードに正解は1つではありません。大事なのは、その意図が他者にとっても明確であることです。
また、今回のようにos.path.existsとos.listdirのような 似て非なる手法 の違いに気づくことで、自分の“癖”を俯瞰し、より良いコーディングに繋げるきっかけになります。コードレビューで出会う小さな違和感を見逃さず、自分のロジックの棚卸しをしてみるのはいかがでしょうか。

今後は、より柔軟に構成できる存在確認処理のユーティリティ化（例：存在＋中身＋更新日時）も視野に入れつつ、チーム内での共通ルール作成にも活かせるでしょう。