Sharp 複合機＋Sharpdesk Network Scan Tool（NST）をサーバーで共用運用すると、保存先に同名ファイルがあるだけで「Duplicate filename」ダイアログが出てスキャン処理が止まることがあります。本記事では原因を整理し、AutoHotkeyで自動リネームして滞留を防ぐ方法と、PowerShell監視などの代替案を具体例付きで解説します。
現象：NSTが「Duplicate filename」で停止し、後続スキャンまで詰まる
Sharp 複合機（例：MX-M365N）＋ Sharpdesk Network Scan Tool（以下 NST）は、複合機から送られてくるスキャンデータをPC／サーバー側で受信し、指定フォルダーへ保存するためのツールです。複数ユーザーのPCへ分散配置するのではなく、サーバー上でNSTを常駐させて「スキャン結果はネットワークフォルダーに集約する」運用にすると、管理が楽になる一方で“同名ファイル問題”に直撃しやすくなります。
具体的には、複合機側で入力したファイル名が、保存先フォルダーにすでに存在していると、サーバー上のNSTが「Duplicate filename（同名ファイル）」のダイアログを表示して処理が停止します。サーバーにログオンしている人がOK/保存操作をしない限り、スキャンが宙ぶらりんになり、後続のジョブまで滞留してしまいます。
| 困るポイント | 現場で起きがちな症状 | 放置した場合の影響 |
|---|---|---|
| 解除できる人が限られる | サーバールームに行ける管理者だけがダイアログを閉じられる | スキャン運用が「人待ち」になり、業務が止まる |
| 後続スキャンも詰まる | 1件の重複で受信処理が止まり、次のスキャンが保留 | スキャンが溜まり、再送・二重送信・問い合わせが増える |
| 利用者側は原因が見えない | 複合機側は送信完了に見えても、サーバー側で止まっている | 「スキャンが消えた」疑惑になり、運用不信につながる |
| 自動連番の設定が見当たらない | NST設定や複合機Web設定で「同名なら(1)付与」が見つからない | 手動対応が前提の設計になり、無人運用ができない |
原因：NSTは“上書き防止”のためにアプリ側で処理を止める設計
この問題の核心は、Windowsの設定というよりNSTの仕様にあります。多くの受信型ツールは、同名ファイルがある場合に「自動的に別名で保存」するのではなく、誤上書き（別の人のスキャンを潰す事故）を防ぐために、明示的な判断をユーザーに求める動作をします。
NSTが表示する「Duplicate filename」ダイアログは、一般的にモーダル（操作をブロックする）なGUIダイアログです。モーダルダイアログが出ると、NSTの保存処理はそこで停止します。つまり、OS側で「メッセージボックスが出る前に握りつぶす」ような設定で解決するタイプではありません。
「Windows側の設定」で解決しにくい理由
- エラーの出し方がアプリ依存：同名チェック・ダイアログ表示・停止はNST内部のロジックです。
- OSに“自動でOKを押す”標準機能はない：グループポリシーやレジストリで一律に回避できるものではありません。
- 保存の責任はNSTが持つ：同名時に「上書き」「別名」「破棄」のどれを採るかは、アプリの仕様・UIに閉じています。
したがって、現実的な落としどころは「NSTの外側で止まりどころを自動処理する」、または「重複が起きない運用設計に寄せる」のどちらかになります。
対策全体像：おすすめは3ルート
実務で採られやすい対処は大きく3つです。結論から言うと、サーバー集約運用を崩したくないならAutoHotkey（AHK）でダイアログ処理を自動化するのが手っ取り早く、効果も分かりやすいです。
| 対策ルート | 狙い | メリット | 注意点 |
|---|---|---|---|
| AutoHotkeyでダイアログ自動処理（推奨） | 停止点を“人の代わりに押す” | 導入が早い／既存構成を大きく変えずに改善できる | GUI依存で、画面がロックされると動かないことがある |
| 受け口フォルダー＋PowerShell後処理 | 保存後に安全にリネーム＆振り分け | GUIに依存しない／ログを残しやすい | 「受け口」で重複が起きると結局止まるため、受け口設計が重要 |
| 命名・フォルダー設計の改善 | そもそも重複を減らす | 根本的で堅い／自動化が不要になる場合がある | 複合機側の設定制約や、現場の運用変更が必要 |
最短で止血：AutoHotkeyで「Duplicate filename」を自動処理する
採用されやすい理由は単純で、NSTがGUIダイアログで止まるなら、GUIを自動操作できるツールを使うのが最短だからです。AutoHotkeyはWindowsの定番自動化ツールで、特定ウィンドウの出現をトリガーに、ボタン押下や文字入力を自動実行できます。
考え方：人がやっている「リネームして保存」をスクリプト化する
実際に管理者がやっている操作を分解すると、だいたい次の流れになります。
- NSTの「Duplicate filename」ダイアログが出る
- 新しいファイル名を入力する（末尾に(1)を付ける等）
- OK/保存ボタンを押して処理を継続する
AHKでは、この一連をウィンドウ検知＋入力＋クリックで置き換えます。ポイントは、単純に「(1)を付ける」だけでなく、(1)が既にあれば(2)…と存在チェックをして重複しない名前を作ることです。
サーバー運用で先に押さえるべき注意点
AHKは便利ですが、サーバーで常駐させるときは「動く前提条件」を意識しないと、ある日突然止まります。実装前に、最低限ここを確認してください。
- NSTとAHKは同じユーザーセッションで動かす：別ユーザー／別セッションだとウィンドウが見えません。
- 画面ロックで動かなくなる可能性：ロック画面中はGUI操作ができないことがあります。運用ポリシーと折り合いをつけましょう。
- RDP切断の影響：切断とログオフは別です。ログオフすると常駐が落ちます。タスクスケジューラで「ユーザーがログオンしているときのみ」等の設定も確認します。
- UACや権限：NSTが管理者権限で動く場合、AHKも同等権限で動かさないと操作できません。
- ウィンドウタイトルが環境で変わる：英語/日本語表示、NSTバージョンで文言が変わります。
AHKサンプル：同名なら(1)(2)…を付けて保存を継続する
以下は「ダイアログにファイル名入力欄（Edit）」があり、OKボタンで保存継続できるケースを想定したサンプルです。実際のダイアログ構成は環境差があるため、コントロール名（Edit1など）はWindow Spy等で合わせてください。
; AutoHotkey v1 の例（v2の場合は文法が異なります）
#NoEnv
#SingleInstance Force
SetTitleMatchMode, 2
DetectHiddenWindows, Off
; ★運用に合わせて変更：NSTの保存先フォルダー
DestDir := "\\fileserver\scan\inbox\"
; ★運用に合わせて変更：ダイアログのタイトル（部分一致）
DupTitle := "Duplicate filename"
; 監視ループ（常駐）
Loop
{
; ダイアログが出るまで待つ（タイムアウト短めでループ）
WinWait, %DupTitle%, , 1
if (ErrorLevel)
continue
; ダイアログがアクティブになるまで待つ
WinActivate, %DupTitle%
WinWaitActive, %DupTitle%, , 2
; ファイル名入力欄（例：Edit1）から現在の名前を取得
ControlGetText, baseName, Edit1, %DupTitle%
baseName := Trim(baseName)
; 拡張子が含まれていない運用なら、ここで付ける（例：pdf）
; if !InStr(baseName, ".")
; baseName .= ".pdf"
; ユニークな名前を生成
newName := GetUniqueName(DestDir, baseName)
; 新しい名前を入力
ControlSetText, Edit1, %newName%, %DupTitle%
; OKボタンを押す（例：Button1）
ControlClick, Button1, %DupTitle%
Sleep, 300
}
return
GetUniqueName(dir, filename)
{
; dir末尾を整える
if (SubStr(dir, 0) != "\")
dir .= "\"
; 拡張子分離
SplitPath, filename, nameOnly, , ext, nameNoExt
; まず元の名前が空いていればそれを返す
full := dir . filename
if (!FileExist(full))
return filename
; (1) (2) ... を付与して空きを探す
i := 1
Loop
{
candidate := nameNoExt . " (" . i . ")"
if (ext != "")
candidate .= "." . ext
if (!FileExist(dir . candidate))
return candidate
i++
if (i > 999)
{
candidate := nameNoExt . " (" . A_Now . ")"
if (ext != "")
candidate .= "." . ext
return candidate
}
}
}サンプルを実運用に落とす手順
- ダイアログの情報を採取：AutoHotkey付属の「Window Spy」で、ダイアログタイトル、ファイル名欄、OKボタンのコントロール名を確認します。
- 保存先パスの整合：NSTが実際に保存しているフォルダーと、AHKが存在チェックするフォルダーを一致させます。
- 意図しない上書きの防止：存在チェックは必須です。単純に(1)付与だけだと(1)が既にあるケースでまた止まります。
- タスクスケジューラで常駐：サーバー再起動後に自動で立ち上がるよう、ログオン時起動＋自動再起動（失敗時の再試行）を設定します。
- ログを残す：運用が安定するまで、リネームした履歴をファイルへ追記すると原因追跡が楽です（後述のPowerShell案も参照）。
AHK運用での“あるある”と回避策
| 詰まりポイント | 起きること | 回避策 |
|---|---|---|
| 画面ロック／スクリーンセーバー | ウィンドウ操作ができず、ダイアログが残る | 運用ポリシーの範囲でロック抑制、またはGUI依存しない方式（後段処理）へ |
| RDPログオフ | AHKもNSTも終了し、受信が止まる | ログオフ禁止運用、タスクスケジューラで自動復旧、監視（死活監視）を入れる |
| NSTのUIが更新される | ボタン名やコントロールが変わり、スクリプトが効かなくなる | タイトル部分一致＋Control系の指定を見直す。更新時にテスト手順を用意する |
| 保存先が遅い／ネットワーク不安定 | 存在チェックのタイミングで誤判定し、再停止 | NAS/ファイルサーバーの性能・SMB設定を確認。リトライやSleepを調整 |
代替案：受け口フォルダーを固定し、PowerShellで“本番フォルダーへ安全に移送”する
AHKは即効性が高い一方、GUI依存という弱点があります。そこで、運用を少し設計し直せるなら、「NSTは受け口フォルダーにだけ保存」→「別プロセスが監視して重複しない名前で移送」という構成が堅くなります。
この方式の肝は、NSTが止まらないように受け口側で重複が起きにくい設計にすることです。例えば「受け口は日付ごとに自動で作る」「受け口は部署ごとに分ける」など、衝突面積を減らしておくと安定します。
構成イメージ
| 役割 | 場所 | やること |
|---|---|---|
| NST | サーバー | 受け口フォルダー（例：\\fileserver\scan\inbox\）に保存するだけ |
| 移送スクリプト（PowerShell） | サーバー（タスク／常駐） | 新規ファイルを検知し、本番フォルダーへ移動。重複時は(1)(2)…付与 |
| 利用者 | 各部署PC | 本番フォルダー（例：\\fileserver\scan\deptA\）を見に行く |
PowerShell例：同名なら連番を付けてMoveする
以下はシンプルな例です。実運用ではエラー処理やログ、ファイルが書き込み途中のタイミングを避ける工夫（数秒待つ等）を入れてください。
$inbox = "\\fileserver\scan\inbox"
$target = "\\fileserver\scan\main"
# ログ出力先
$log = "C:\ScanTools\move-log.txt"
function Get-UniquePath($dir, $name) {
$base = [System.IO.Path]::GetFileNameWithoutExtension($name)
$ext = [System.IO.Path]::GetExtension($name)
$path = Join-Path $dir $name
if (-not (Test-Path $path)) { return $path }
for ($i=1; $i -le 999; $i++) {
$candidate = "{0} ({1}){2}" -f $base, $i, $ext
$path2 = Join-Path $dir $candidate
if (-not (Test-Path $path2)) { return $path2 }
}
# 最後の手段：時刻を付ける
$ts = (Get-Date).ToString("yyyyMMdd-HHmmss")
return (Join-Path $dir ("{0} ({1}){2}" -f $base, $ts, $ext))
}
$fsw = New-Object System.IO.FileSystemWatcher $inbox
$fsw.IncludeSubdirectories = $false
$fsw.EnableRaisingEvents = $true
$fsw.Filter = "*.*"
Register-ObjectEvent $fsw Created -Action {
$src = $Event.SourceEventArgs.FullPath
# 書き込み途中を避ける（環境により調整）
Start-Sleep -Seconds 2
$name = [System.IO.Path]::GetFileName($src)
$dst = Get-UniquePath -dir $target -name $name
try {
Move-Item -LiteralPath $src -Destination $dst -Force
Add-Content -Path $log -Value ("{0} MOVED {1} -> {2}" -f (Get-Date), $src, $dst)
}
catch {
Add-Content -Path $log -Value ("{0} ERROR {1} : {2}" -f (Get-Date), $src, $_.Exception.Message)
}
} | Out-Null
# 常駐
while ($true) { Start-Sleep -Seconds 10 }AHK方式とPowerShell方式の選び方
どちらが正解というより、現場の制約で決まります。サーバーに常時ログオンできない、ロックが厳格、監査が厳しい、という環境ほどGUI依存は不利です。
| 比較項目 | AutoHotkey | PowerShell後処理 |
|---|---|---|
| 導入スピード | 速い（止血向き） | 中（設計が必要） |
| 堅牢性 | UI変更に弱い | ファイル操作中心で堅い |
| セキュリティ/監査 | 常時ログオン運用になりやすい | サービス／タスク運用にしやすい |
| 「止まらない」保証 | ダイアログが確実に拾えるなら強い | 受け口で重複が起きない設計ができれば強い |
運用改善：重複しにくい命名に寄せる（小さな工夫で効果が出る）
自動化で回避するのも現実的ですが、そもそも同名が発生しにくい設計に寄せると、トラブル頻度が一気に下がります。複合機の機種や設定項目に依存しますが、検討の価値が高いポイントをまとめます。
命名ルールの例
| 命名パターン | 例 | 効果 | 注意点 |
|---|---|---|---|
| 日時を入れる | 20251229_153012_請求書.pdf | 同名衝突が激減 | 複合機側で日時付与ができない場合は後段で付与 |
| ユーザーID/部署コードを入れる | HR_Tanaka_申請書.pdf | 複数部署での衝突を回避 | 個人情報の扱い、運用の徹底が必要 |
| 連番を強制する | scan_000123.pdf | 確実に一意になる | 複合機側で連番が無理ならスクリプト側で管理 |
フォルダー設計の例
- ユーザー別フォルダー：\\fileserver\scan\user\tanaka\ のように分離。最もシンプルに衝突を減らせます。
- 部署別＋日付別：\\fileserver\scan\sales\2025-12-29\ のように階層化。検索性と衝突回避のバランスが取りやすいです。
- 受け口→本番の二段構え：受け口は“溜めない”運用（定期移送／自動移送）にすると安定します。
ベンダー問い合わせ・更新確認で見るべきポイント
「設定で自動連番が見当たらない」場合でも、バージョンやオプションで挙動が変わる可能性はあります。すぐに自動化へ突っ込む前に、次の点だけは確認しておくと遠回りを減らせます。
- NSTのバージョン：古い版だと改善されている可能性があります。更新可否を確認します。
- 保存先の設定項目：上書き可否、エラー時の動作、命名テンプレート（日時付与など）の項目がないか再点検します。
- 複合機側のスキャン送信設定：機種によっては「自動で日時付与」や「送信時に連番」を持つことがあります。
- 代替手段：NSTを介さず、複合機の「SMBスキャン（Scan to Folder）」を使った方が要件を満たす場合もあります（運用要件次第）。
セキュリティと運用の注意：サーバーで常駐させるほど“人が触れない設計”が重要
スキャンの集約は便利ですが、サーバー運用ならではの落とし穴もあります。特に、AHKのようなGUI自動化を入れるときは、便利さとリスクの両方を理解したうえで運用設計を固めましょう。
- 最小権限：NST（およびスクリプト）が書き込むフォルダー権限は必要最小限にします。
- 保存先の監査ログ：誰がいつ作成したファイルか追えるよう、ファイルサーバー側の監査も検討します。
- バックアップと保持：スキャンデータは「いつのまにか消える」と致命的です。バックアップと保持期間を明確にします。
- 障害時の逃げ道：NSTが止まったときの一次切り分け（再起動、ログ確認、受け口の滞留解消）を手順化します。
まとめ：NSTの“同名停止”は外側で吸収し、止まらない導線を作る
Sharpdesk Network Scan Tool（NST）をサーバーで共用運用すると、同名ファイルがあるだけで「Duplicate filename」ダイアログが出て処理が止まることがあります。これはWindowsの設定で簡単に無効化できる類ではなく、NSTの上書き防止仕様として捉えるのが現実的です。
最短で効果が出るのはAutoHotkeyでダイアログを検知し、自動で(1)(2)…を付けて保存を継続する方法です。より堅牢さや監査性を重視するなら、受け口フォルダー＋PowerShell移送でGUI依存を減らす設計も検討できます。あわせて、命名やフォルダー分割で衝突を減らせば、トラブルはさらに減ります。
「サーバールームに行ける人しか解除できない」「解除までスキャンが滞留する」という状態は、運用のボトルネックになりがちです。止まるポイントを放置せず、自動処理または設計変更で“止まらないスキャン”へ寄せていきましょう。
コメント