はじめに
設計現場において、過去の図面や仕様書は「宝の山」です。
しかし、その多くはネットワークHDD（NAS）の膨大なフォルダ階層の中に埋もれています。
Windows標準の検索機能は時間がかかり、かといって安易な自作スクリプトはNASに過負荷をかけてIT部門から「出禁」を食らうリスクがあります。
今回は、非IT部門のエンジニアが 「IT部門も納得する安全性」と「実務者が納得する速度」 を両立させた検索ツールを実装する際のポイントを解説します。
1. 実務に即した「3つの安全設計」
NASへのアクセスにおいて最も懸念されるのは「負荷」と「不測の操作」です。
① 階層リミッター（再帰深度の制限）
NASのディレクトリ構造は、時に人間の想像を超える深さ（あるいはショートカットによる循環）を持っています。
無限ループや過度なアクセスを防ぐため、検索の深さを制限するリミッターを実装します。
# 安全のためのリミッター：最大で何階層まで潜るか
def recursive_search(target_dir, search_word, depth=0):
MAX_DEPTH = 5 # 第5階層までをカットオフラインに設定
if depth > MAX_DEPTH:
return
try:
with os.scandir(target_dir) as it:
for entry in it:
if entry.is_dir():
recursive_search(entry.path, search_word, depth + 1)
elif search_word in entry.name:
print(f"Found: {entry.path}")
except PermissionError:
pass # アクセス権限のないフォルダは静かにスルー
② 「読み取り専用」スキャン (os.scandir)
ファイルを open() して中身を読み取ると、ファイルシステムに「最終アクセス日時」の更新などの変化を与えてしまうことがあります。
os.scandir を使用することで、ファイルの中身に触れず、OSが保持しているメタデータ（ファイル名、属性）だけを高速に取得します。
③ アクセス権限の尊重
プログラムがシステム権限で動かないよう、あくまで「実行ユーザーの権限」の範囲内で動作させます。
権限エラーが発生した際にプログラムを止めず、ログを残してスキップするエラーハンドリングが、ツールを安定させるコツです。
2. 【コラム】なぜ Power Automate Desktop ではなく Python なのか？
社内の効率化ツールを検討する際、必ずと言っていいほど「PAD（ローコードツール）でいいのでは？」という議論が起こります。
今回、あえてPythonを選んだのには明確な理由があります。
1. 圧倒的な実行速度
PADのファイル操作は、GUIを介したエミュレーションに近い挙動をすることがあり、数万件のファイルを走査するような用途ではPythonの方が数倍〜数十倍高速です。
2. 「再帰処理」の柔軟性
「フォルダの中にフォルダがある限り探し続ける」という再帰処理は、Pythonなら数行で記述できます。PADで同様のロジックを組むと、フローが非常に複雑になり、メンテナンス性が低下します。
3. バージョン管理と配布のしやすさ
PythonであればGitでソースコードの変更履歴を完全に管理できます。「いつ、誰が、なぜリミッターの値を変更したか」が明確なことは、社内ツールとしての信頼性に繋がります。
4. リソース消費の制御
Pythonはメモリ消費やCPU負荷を細かく制御できるため、「バックグラウンドで静かに動かす」といった気遣い（社内政治的な配慮）が可能です。
3. 現場への導入：信頼を勝ち取るために
技術的に優れたツールを作るだけでは、社内ツールとして定着しません。
私は導入にあたり、IT部門に以下の3点を約束しました。
- 「参照のみ」で「書き込み」は一切行わないこと
- 「リミッター」により、サーバーへのリクエスト数を物理的に制限すること
- 「ソースコード」を公開し、誰でも安全性を確認できるようにすること
「勝手に作った怪しいツール」ではなく「透明性の高い安全なツール」として見せることで、現場のDXは一気に加速します。
まとめ
非IT部門のエンジニアが作るツールには、IT部門とは異なる「現場の痛み」への理解があります。
安全設計という「保護回路」をコードに組み込むことで、皆さんの現場にある「NASという名の深淵」から、ぜひ宝の山を掘り出してみてください。