Ollamaサーバー衝突から改行コード破損まで｜動画自動化パイプラインで踏んだ5つの罠

動画対応のパイプラインを作り込んだ後、実際に動かしてみると次々とトラブルに直面しました。 1つ1つは地味な原因なのですが、症状（画面に何も表示されない、Excelが更新されない）だけを見ると原因の見当がつかず、切り分けに時間がかかったものばかりです。 備忘録として記録しておきます。

① Ollamaサーバーの二重起動衝突

画像解析中に動画解析を実行したところ、画像側の処理が「1件目から突然全滅」する形でOllamaの500エラーが多発しました。

画像用・動画用それぞれのbatファイルが、起動時に無条件でollama serveを叩く作りになっていたのが原因でした。 近いタイミングで両方が起動すると、2つ目のプロセスが同じポート(11434)を取り合って既存のサーバーを不安定にさせてしまいます。 対策として、起動前に軽いヘルスチェックを入れ、既に起動していれば何もしないようにしました。

curl -s -m 3 http://localhost:11434/api/tags
if errorlevel 1 (
    start /min cmd /c "ollama serve"
    timeout /t 5 /nobreak
) else (
    echo [INFO] Ollama already running. Skip start.
)

② アップスケール後の解像度がAdobe規定オーバー

動画をアップスケールしてAdobe Stockに申請したところ、「解像度が大きすぎるためアップロードできませんでした」というエラーが返ってきました。 Adobe Stockの動画は横4096px（DCI 4K）が上限です。画像感覚で機械的に4倍アップスケールをかけていたため、1280×704の動画が5120×2816という上限オーバーのサイズになっていました。

元動画の解像度によっては同じ倍率でもOK/NGが分かれるため、固定倍率の運用には限界があると分かりました。 恒久対策として、アップスケール処理の最終段に「4096pxを超えていたら自動的に縮小する」セーフティネットを追加することにしました。

ffmpeg -i input.mp4 -vf "scale='if(gt(iw,4096),4096,iw)':'if(gt(iw,4096),-2,ih)'" output.mp4

③ 絵文字によるcp932エンコードエラー

単体実行用のbatファイル（run_analyze_video_stock.bat）を直接ダブルクリックしたところ、何も表示されずに一瞬でウィンドウが閉じてしまう現象が発生しました。 コマンドプロンプトで直接実行してエラーを保存してみると、原因が判明しました。

print(f"📋 設定ファイル読み込み完了...")のような絵文字入りのログ出力が原因でした。日本語Windowsのデフォルト文字コードcp932では絵文字を表現できません。 Streamlit UI経由の実行では-X utf8オプション付きでPythonを呼んでいたため問題が表面化していませんでしたが、単体実行用のbatにはこのオプションが抜けていました。 -X utf8の追加に加えて、そもそも絵文字を使わない方が環境依存を減らせるため、ログ出力を[INFO][OK][ERROR]のようなASCII表記に置き換えました。

④ Windowsセキュリティによるファイルブロック

UnicodeEncodeErrorを直してもStreamlit経由での動画解析だけが進まず、ログには「Run at:」という開始ヘッダーしか記録されない状態が続きました。 バックグラウンドプロセスとして裏で起動しているため、何が起きているか画面から見えないのが厄介でした。実際に発生していたのは以下のダイアログでした。

チャット経由でダウンロードしたbatファイルにはMOTW（Mark of the Web／ダウンロードマーク）というゾーン情報が付与されます。 この状態のスクリプトがnulのような特殊デバイス名にリダイレクトしようとすると、Windowsのセキュリティ機能がブロックしてダイアログを出すことがあります。 裏で非表示実行していたため、誰も気づかず永遠に「閉じる」待ちで固まっていたのが真相でした。Unblock-Fileコマンドでゾーン情報を除去して解決しました。

Get-ChildItem -Path "E:\temp\ai_stockphoto" -Recurse -Include *.bat,*.py,*.json | Unblock-File

再発防止として、そもそもnulのような特殊デバイス名へのリダイレクトを使わない形にbatファイルを書き換えました。

⑤ sed編集による改行コード破損

上記のnul回避対応を一括置換コマンドで複数ファイルに適用したところ、今度は全く別の症状が出ました。 「動画解析開始」を押すとChromeが勝手に開き、存在しないファイルへのアクセスエラーページが表示されるという奇妙な現象です。 コマンドプロンプトで直接実行してみると、原因は一目瞭然でした。

%~dp0がdp0に、PYTHONUTF8がYTHONUTF8になっており、変数のトークン化が崩れていました。 原因は編集方法の違いでした。ピンポイントの文字列置換ツールは改行コードに触れませんが、一括置換コマンド（sed）で編集した際、 Windows形式の改行コード（CRLF）がUnix形式（LF）に正規化されてしまっていたのです。cmd.exeはLFのみのbatファイルを正しく解釈できず、構文が崩れます。

# LF -> CRLF への変換
sed -i 's/\r$//' file.bat   # 既存のCRを一旦除去して統一
sed -i 's/$/\r/' file.bat   # 全行末にCRを付与

影響を受けたのは、その回の修正で一括置換コマンドを使ったファイルだけでした。 ピンポイント置換で編集していた別のファイル群は無事だったため、「動画だけ壊れやすい理由がある」わけではなく、単純に編集方法の違いが原因だったと分かりました。

まとめ：エラーの切り分けで意識したこと

今回の一連のトラブルで一貫していたのは、「画面に何も表示されない」「処理が進まない」という同じような症状の裏に、 全く異なる原因が隠れていたという点です。憶測で対策を打つより、都度コマンドプロンプトで直接実行してエラーメッセージそのものを取得する方が結果的に近道でした。 特に④と⑤のように、バックグラウンド実行では画面に何の手がかりも出ないケースでは、あえてUIを経由せず手動でコマンドを叩いて再現させることが、 遠回りに見えて最短の切り分け方法になることを改めて実感しました。

ここまでで、動画のAdobe Stock自動化パイプラインは解析からExcel反映、UI操作までひと通り動く状態になりました。 次は実際の審査結果（OK/NG）が出揃ってから、振り分け処理の実運用記録を書く予定です。

FAQ