厳密なファイルチェック関数の作り方

ポコぺん

ディレクトリを除外して確実に判定する自作関数を解説

PowerShellを利用した業務自動化やシステム管理において、特定のファイルが存在するかどうかを確認する処理は、スクリプトの安定性を左右する非常に重要な工程です。
しかし、標準的なコマンドを使用するだけでは、対象が「ファイル」なのか「フォルダ」なのかを明確に区別できず、後続の処理で予期せぬエラーを引き起こすリスクがあります。
また、優れた関数を作成しても、新しいスクリプトを作成するたびにコードをコピー＆ペーストしていては、修正が必要になった際の管理が極めて困難になります。

こうした課題を解決するのが、関数の「モジュール化（.psm1）」による共通化と、オブジェクトのプロパティを活用した「厳密な判定ロジック」の実装です 。
本記事では、提供されたソースコードを基に、指定されたパスがフォルダではないことを確認しつつ、ファイルの有無を真偽値（Boolean）で返す実践的な関数「fncFileCheck」の構成を詳しく解説します 。

一度作成した関数をモジュールとして定義し、外部から呼び出せる仕組みを整えることで、開発効率は飛躍的に向上します 。
コードの品質を一段階引き上げ、保守性の高いスクリプト開発を実現するためのテクニックを、初心者の方にも分かりやすくお伝えします。

この記事を読んでほしい人

  • PowerShellスクリプトを作成しているシステム管理者・エンジニア。
  • 独自の関数を複数のスクリプトで使い回したい（共通化したい）エンジニア
  • Test-Path だけでは不十分な、厳密なファイル判定方法を探している開発者
はじめに

関数を「.psm1」で管理すれば、スクリプト開発の効率は劇的に向上する

PowerShellスクリプトが増えていく中で、多くのエンジニアが「以前作成した処理を別のスクリプトでも使いたい」という場面に直面します。
このとき、コードをコピー＆ペーストして使い回すのは避けるべきです。関数を.psm1（PowerShellスクリプトモジュール）形式で外部ファイル化し、ライブラリとして管理することで、開発環境はより堅牢で効率的なものへと進化します。

なぜ「コピー＆ペースト」は危険なのか

同じ関数を複数のファイルに貼り付けて使用していると、関数内にバグが見つかった際や仕様変更が必要になった際、全てのファイルを一つずつ修正しなければなりません。
これは修正漏れによる事故の原因となり、保守コストを増大させます。

モジュール化がもたらす3つのメリット

  1. 一元管理による保守性の向上
    関数をモジュールファイルに集約することで、修正が必要な箇所は常に1カ所（.psm1ファイル）だけで済みます。
    今回提供されたソースコードでも、.SYNOPSIS（概要）や .NOTES（作成履歴）といったヘルプメッセージが詳細に記述されており、後から誰が見てもメンテナンスが容易な構造になっています 。
  2. メインスクリプトの可読性向上
    複雑なロジックをモジュール側に隠蔽（カプセル化）することで、実行用のメインスクリプトは非常にシンプルになります。
    必要な関数だけを呼び出す構成にすることで、全体の処理フローが把握しやすくなります。
  3. 厳格なエクスポート管理
    モジュールファイル内では、Export-ModuleMember を使用して外部に公開する関数を制御できます。
    • 公開する関数:
      ユーザーが直接利用するもの（例：fncFileCheck ）
    • 非公開の関数:
      モジュール内部の計算でのみ使用する補助的なもの このように「見せるもの」と「隠すもの」を分けることで、意図しない関数の誤用を防ぐことができます 。

実務で使えるファイル存在チェック関数「fncFileCheck」の解説

今回取り上げる fncFileCheck は、指定されたパスに「ファイル」が実在するかどうかを判定し、その結果を真偽値（$true / $false）で返す関数です 。
一見シンプルですが、実務で発生しがちな「パスは存在するが、実はフォルダだった」という誤判定を防ぐ工夫が凝らされています 。

引数と戻り値の定義

この関数は、引数としてファイル名（パス）を受け取ります。

  • 引数（$FileName）:
    チェック対象となるファイルのパスを文字列（string型）で指定します 。
    デフォルト値は $null に設定されており、引数が渡されなかった場合の挙動も考慮されています 。
  • 戻り値（$bChkFlg）:
    判定結果を格納する変数 $bChkFlg を初期値 $false で作成し 、全てのチェックをクリアした場合のみ $true を返します 。

Test-Pathによる存在確認の基礎

まず、PowerShellの標準コマンドである Test-Path を使用して、指定されたパス自体が存在するかを確認します 。
コード内では、以下の2段階でチェックを行っています。

  1. 変数の存在確認:
    $FileName が空でないか（Not NULL）を確認します 。
  2. パスの妥当性確認:
    Test-Path $FileName が $true を返すか（パスとして有効か）を判定します 。

PSIsContainerを用いた「ファイルかフォルダか」の厳密な判定

ここがこの関数の最も重要なポイントです。単にパスが存在するだけでは、それが「ファイル」なのか「フォルダ」なのか判別できません。
そこで、Get-Item コマンドで取得したオブジェクトの PSIsContainer プロパティ を参照します 。

  • PSIsContainerとは:
    対象がフォルダ（コンテナ）であれば $true、ファイルであれば $false を返すプロパティです 。
  • ロジック:
    (Get-Item $FileName).PSIsContainer -ne $true と定義することで、「フォルダではない（＝ファイルである）」場合のみを抽出しています 。

この厳密な判定により、「設定ファイルを読み込もうとしたら、同名のフォルダを開こうとしてエラーになった」というようなスクリプトの停止トラブルを未然に防ぐことができます。

なぜ「Test-Path」だけでは不十分なのか？

PowerShellでファイルの存在を確認する際、多くの人が最初に思い浮かべるのが Test-Path コマンドレットです。
しかし、実務レベルのスクリプトにおいては、Test-Path だけでは不十分なケースが多々あります。

パスが存在しても「ファイル」とは限らない

Test-Path は、指定されたパスに「何らかのアイテム」が存在すれば $true を返します。
ここでの落とし穴は、そのアイテムがファイルなのか、あるいはフォルダ（ディレクトリ）なのかを区別しないという点です。

例えば、設定ファイルを読み込む処理で C:\Temp\Config というパスをチェックしたとします。
もし同じ場所に Config という名前の「フォルダ」が作成されていた場合、Test-Path は $true を返してしまいます。そのままファイルを読み込もうとすると、「アクセスが拒否されました」といったエラーが発生し、スクリプトが停止してしまいます。

ソースコードに見る「二段構え」の判定

今回のソースコードでは、この問題を解決するために以下の二段階のチェックを行っています。

PowerShell

# 判定フラグの初期化
$bChkFlg = $false

#ファイル名の存在判定(is Folder or File)
if( ( Test-Path $FileName ) -eq $true ) {
	#ファイル名の存在判定(is File)
	if( ( Get-Item $FileName ).PSIsContainer -ne $true ) {
		# ファイルが存在する
		$bChkFlg = $true
	}
}
  • 一段目:
    Test-Path を使用し、まずは指定されたパスがシステム上に存在するかを確認します 。
  • 二段目:
    (Get-Item $FileName).PSIsContainer -ne $true という条件を加え、そのパスが「コンテナ（フォルダ）」ではないことを厳密に判定しています 。

この「二段構え」のロジックを組み込むことで、スクリプトは初めて「確実にファイルが存在する」という確証を持って次の処理へ進むことができるのです 。

意図しない入力値へのガード

さらに、今回のコードでは $FileName が空（NULL）でないかの判定も含まれています 。
引数が未指定のまま関数が実行された場合でも、エラーを出さずに $false を返す設計になっており、堅牢なスクリプト開発において非常に参考になる実装と言えます 。

PowerShellモジュール（.psm1）の作成と公開手順

関数を単独のスクリプトファイル（.ps1）に記述するのではなく、モジュールファイル（.psm1）として保存することで、複数のプロジェクトから簡単に呼び出せる「ライブラリ」として活用できるようになります。

.psm1ファイルの作成

PowerShellモジュールの作成は非常にシンプルです。
拡張子を .ps1 ではなく .psm1 として保存するだけで、PowerShellはそのファイルをモジュールとして認識します 。
今回のサンプルでは Module_function2.psm1 というファイル名で作成されています 。

Export-ModuleMember の役割

モジュールを作成する上で欠かせないのが、ファイルの末尾に記述されている Export-ModuleMember コマンドです。

PowerShell

<#----------------------------
　外部関数宣言
----------------------------#>
Export-ModuleMember -Function fncFileCheck
  • 機能:
    モジュール内で定義した関数のうち、どれを外部（呼び出し元）から利用可能にするかを指定します 。
  • 今回の実装:
    Export-ModuleMember -Function fncFileCheck と記述することで、fncFileCheck 関数を外部に公開しています 。

この記述がない場合、モジュールを読み込んでも関数を呼び出すことができません。
公開する関数を明示的に指定することで、内部処理用の補助関数などを隠蔽し、使いやすいライブラリを構築できます。

モジュールの読み込みと利用方法

作成した .psm1 ファイルを実際のスクリプトで利用するには、Import-Module コマンドレットを使用します。

PowerShell

# モジュールの読み込み
Import-Module ".\Module_function2.psm1"

# 関数の実行
$result = fncFileCheck -FileName "C:\test\sample.txt"
if ($result) {
    Write-Host "ファイルが見つかりました。"
}

このように、一度モジュールとして定義しておけば、メインの処理コードを汚すことなく、一行のインポート命令だけで高度な判定ロジックを再利用できるようになります。

まとめ

自作関数をライブラリ化して保守性の高いコードを書こう

本記事では、PowerShellにおける関数のモジュール化と、実用的なファイル存在チェック関数の実装について解説しました。

今回作成した .psm1 形式のモジュールファイルには、効率的な開発に欠かせない以下のエッセンスが凝縮されています。

  • 厳密な判定ロジックの構築
    fncFileCheck 関数では、単なるパスの有無だけでなく、PSIsContainer を用いて「フォルダを除外する」という実務上のエラーを防ぐ工夫を凝らしています 。
  • ドキュメント化の徹底
    ソースコード内の .SYNOPSIS（概要）や .DESCRIPTION（説明）、.NOTES（作成履歴）といったコメントは、将来の自分やチームメンバーがコードを読み解く際の大きな助けとなります 。
  • 再利用性の確保
    Export-ModuleMember を使用して関数を外部へ公開することで、一度書いたコードを資産として複数のスクリプトで使い回すことが可能になります 。

開発の規模が大きくなるほど、コードの「共通化」と「保守性」が重要になります。
今回ご紹介したように、小さな関数であっても丁寧にモジュール化して管理する習慣を身につけることで、トラブルに強く、拡張性の高いシステムを構築できるようになります。

まずは、よく使う処理を一つずつ .psm1 ファイルへ移行し、自分だけのライブラリを育てていくことから始めてみてください。

PowerShell

<#--------------------------------------------------------
.SYNOPSIS
外部関数群
	fncFileCheck	: ファイルの存在チェック

.NOTES
【作成】2026/04/09 製作者名		新規作成
--------------------------------------------------------#>
<#----------------------------
　外部関数
----------------------------#>
#######################################################################
## fncGetIniData	: ファイル存在チェック
#######################################################################
function fncFileCheck( [string]$FileName=$null )
{
	<#
	.SYNOPSIS
	ファイルの存在チェック

	.DESCRIPTION
	引数「FileName」で指定されたファイルの存在を確認し、
	存在有無をBOOLで返す。

	※ <CommonParameters>未サポート

	.PARAMETER FileName
	ファイル名

	.NOTES
	【作成】2024/03/09 K.K			新規作成
	#>
	#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#
	<#----------------------------
	　main処理
	----------------------------#>
	#++++++++++++++
	# ファイルの存在確認
	#++++++++++++++
	# 判定フラグの初期化
	$bChkFlg = $false

	# ファイル名の存在判定(is Not NULL)
	if( $FileName ) {
		#ファイル名の存在判定(is Folder or File)
		if( ( $FileName -ne "" ) -And ( ( Test-Path $FileName ) -eq $true ) ) {
			#ファイル名の存在判定(is File)
			if( ( Get-Item $FileName ).PSIsContainer -ne $true ) {
				# ファイルが存在する
				$bChkFlg = $true
			}
		}
	}

	#++++++++++++++
	# 終了
	#++++++++++++++
	return $bChkFlg
}


<#----------------------------
　外部関数宣言
----------------------------#>
Export-ModuleMember -Function fncFileCheck

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

このサイトは reCAPTCHA によって保護されており、Google のプライバシーポリシー および 利用規約 に適用されます。

reCaptcha の認証期間が終了しました。ページを再読み込みしてください。

ABOUT ME
ポコぺん
ポコぺん
ぷぅ
北海道在住のITエンジニア。

システム構築および運用・保守を経験。
ESXi、Azure、Proxmox VEについて基礎的な理解あり。
C系言語、PowerShellスクリプト、Excelマクロなどを少々扱う。
関連記事
こちらの記事もどうぞ
記事URLをコピーしました