【ITニュース解説】How A 15-Column Dreamstime CSV And A Upload Tracker Fixed My Rejection And Double-Post Problems

システムエンジニアを目指す上で、効率的な作業フローの構築は非常に重要な課題だ。ある開発者は、ストックアートやテンプレートといったデジタルコンテンツを複数のプラットフォームに配信する過程で、二つの大きな問題に直面した。一つは「CSVファイルのヘッダーエラー」、もう一つは「同じコンテンツの二重投稿」である。これらの問題を解決するために、彼はどのように取り組み、どのような教訓を得たのか、その道のりを見ていこう。

まず「CSVファイルのヘッダーエラー」の問題から説明する。Dreamstimeというプラットフォームに40枚の画像をアップロードしようとした際、手作業で作成したCSVファイルのヘッダー行が正しくないというエラーで、丸一日を無駄にしてしまったという。Dreamstimeは15列という厳格なCSV形式を要求し、列の順番や名前が一つでも異なると、ファイル全体が拒否されてしまう。同様に、Adobe Stockは5列、Vecteezyは4列と、プラットフォームごとに異なるフォーマットを要求する。しかも、どのプラットフォームも余分な列を許容しないという厳しさがある。 当初、開発者はすべてのプラットフォームに対応できる「万能な」CSVファイルを作成しようと試みたが、これはすべてのプラットフォームで失敗に終わった。この経験から学んだことは、各プラットフォームが要求する正確なヘッダー行と列構成をスクリプトに覚えさせ、それ以外の余計な情報を含めない「make_metadata.py」というPythonスクリプトを作成することだった。このスクリプトは、指定されたプラットフォームに合わせて必要な列だけを含むCSVファイルを生成する。例えば、Dreamstime向けならば15列、Adobe Stock向けならば5列といった具合だ。手作業での編集ではなく、機械的に正しいフォーマットを生成することで、ヒューマンエラーによる拒否をなくすことができた。

次に「ダブルポスト（二重投稿）」の問題だ。これはCSVエラーよりも深刻で、一度修正すれば済むCSVエラーと異なり、同じコンテンツを複数回アップロードしてしまうと、プラットフォームによってはアカウント停止の危険性がある。開発者の作業フローでは、コンテンツのアップロード処理を複数回実行することがあり、テスト中に誤って再実行してしまったり、スケジュールされた処理が二重に実行されたりすると、この問題が発生する可能性があった。 この問題を解決するために作成されたのが、「upload_tracker.py」という別のPythonスクリプトだ。このスクリプトは、どのコンテンツがすでにアップロードされたかを記録するシンプルな台帳の役割を果たす。重要なのは、コンテンツ一つ一つが正常にアップロードされるたびに、すぐにその事実を台帳に記録する習慣だ。もし途中で処理が中断しても、台帳にはそれまでに完了したコンテンツの情報が残るため、再開時には未完了のコンテンツから処理を始められる。この台帳は、複雑なデータベースを使わず、シンプルなプレーンテキストファイルとして実装されているため、破損の心配が少なく、非常に信頼性が高い。システムの基盤となる部分だからこそ、シンプルさが重要な機能となる。

これらのスクリプトは、Pythonの標準ライブラリのみで構築されている点も注目に値する。開発者が使っていたサーバーは、1vCPU、2GB RAMという限られたリソースしかないため、外部のライブラリやフレームワークを導入すると、メモリ消費が増え、動作が不安定になる可能性があった。そこで、あえて標準機能にこだわり、余計な依存関係を排除することで、低スペックの環境でも安定して動作するツールを実現したのだ。また、それぞれの資産処理の後には、ガベージコレクション（gc.collect()）を明示的に実行し、最大メモリ使用量（resource.getrusage(RUSAGE_SELF).ru_maxrss）を測定するなど、限られたリソースを最大限に活用するための細やかな工夫も凝らされている。

また、効率的な作業のために、適切なフォルダ構造を確立することも重要だった。生データを置く「assets/」、アップロード準備ができたファイルとCSVを置く「output/」、最終的な成果物をまとめる「packs/」、調査メモやログを保管する「research/」、そして作成したスクリプトを置く「scripts/」といった明確なルールを設けた。これにより、スクリプトは常に適切なファイルにアクセスし、作業の混乱を防ぐことができた。特に「research/」フォルダに保管されたログやメモは、将来の製品開発の貴重な情報源となるため、削除せず永久に保存することの重要性が強調されている。一度失われた調査データや記録を再作成するコストは、ディスクの費用よりもはるかに高くなるため、この教訓はシステム開発においても非常に有効だ。

この一連の経験から得られた最大の教訓は、手作業での複雑な管理は必ず破綻するという事実だ。40枚ものコンテンツの15列CSVを手作業で管理するのは、現実的ではない。解決策は、プラットフォームのルールを機械的に適用する二つの小さなスクリプトと、アップロード状況を追跡するシンプルな台帳に集約された。メタデータのヘッダーは手作業で覚えるのではなくスクリプトに任せ、アップロードの状況は「たぶん終わった」といった曖昧な記憶ではなく、台帳で正確に管理する。 これらのスクリプトは、「md2pdf.py」や「pack_product.py」といった他のツールと合わせて「Pipeline Starter Kit」としてまとめられ、実際にこのプロジェクトから39の製品、総計856MBものデジタルコンテンツを、先述の小さなサーバーで効率的に出荷することに成功した。システムエンジニアを目指す皆さんも、日々の作業の中で繰り返される手間やミスの原因を見つけ、それを自動化する視点を持つことが、効率的で信頼性の高いシステムを構築するための第一歩となるだろう。この事例は、大きな問題も小さなスクリプトの組み合わせで解決できること、そして制約のある環境でも工夫次第で高品質な成果を出せることを示している。