【ITニュース解説】The Simple Ledger That Stops Double-Posting on Adobe, Vecteezy and Dreamstime

ニュース記事は、デジタルコンテンツのアップロード作業で直面した具体的な問題と、その問題を解決するために考案されたシンプルなシステムについて解説している。筆者は過去に、ストックフォトサイトへ画像をアップロードする際にネットワーク接続が不安定になり、アップロードを途中でやり直した経験がある。この再実行が原因で、あるプラットフォームでは重複投稿として受け付けられ、手作業で大量のファイルを削除する羽目になっただけでなく、利用規約違反の警告まで受けてしまった。一方で、別のプラットフォームでは重複がそのままシステムに受け入れられ、審査待ちの状態になった。この経験から、手作業や記憶に頼るだけではミスが生じやすく、信頼できる自動化された仕組みが必要だと痛感し、その解決策として「台帳（ledger）」と「厳格なCSVヘッダー」を使ったシステムの構築に至った。

この解決策の中心にあるのは、まず各プラットフォームが要求するメタデータファイルのCSVヘッダーを正確に生成することだ。Adobe、Vecteezy、Dreamstimeといったストックフォトプラットフォームは、アップロードするファイルのタイトル、キーワード、カテゴリといった情報を含むCSVファイルを事前に解析する。これらのプラットフォームはそれぞれ異なる列数や順序のヘッダーを要求し、一つでも形式が異なれば即座にアップロードが拒否されてしまう。手作業でプラットフォームごとにCSVファイルを編集していた初期の試みでは、わずか2週間で入力ミスが発生し、アップロードの機会を逃す事態となった。そこで筆者は、make_metadata.pyというPythonスクリプトを開発した。このスクリプトは、単一のファイル群から、選択したプラットフォームに応じて正確な列数と順序を持つCSVヘッダーを自動的に生成する。例えば、Adobe向けには5列、Vecteezy向けには4列、Dreamstime向けには15列のCSVファイルが出力されるため、手作業によるミスがなくなり、テンプレートのずれも発生しない。ただし、このスクリプトは初期段階ではファイル名からタイトルを生成するが、最終的な提出前には必ず人間が読みやすいタイトルや適切なキーワードに置き換えるべきだと筆者は忠告する。不適切なタイトルやキーワードは、審査期間の遅延や拒否につながるためである。

次に、重複投稿を完全に防止するための「台帳」の仕組みだ。これはupload_tracker.pyというシンプルなPythonスクリプトによって実現される。このスクリプトは、すでにアップロードが完了したファイルの名前をプレーンテキスト形式の台帳ファイルに記録する。アップロード作業を開始する前にupload_tracker.py pending items.txtを実行すると、まだ処理されていないファイルの一覧が出力される。この一覧を実際のアップロードスクリプトに渡すことで、未完了のファイルだけが処理対象となる。もしアップロードが途中で中断しても、台帳には完了したファイルの情報が残っているため、再実行時には残りのファイルから処理を再開できる。この台帳は、データベースのような複雑なシステムではなく、誰でも読み書きできるシンプルなテキストファイルであるため、管理もバックアップも非常に容易だ。この仕組みは、利便性だけでなく、デジタルコンテンツ投稿者にとって非常に重要な意味を持つ。重複したコンテンツを投稿することは、プラットフォーム側からアカウントに問題があると認識される最も速い方法の一つだからだ。Vecteezyのように重複を即座に拒否するプラットフォームもあれば、Adobeのように受け付けた上で審査段階で保留にするプラットフォームもあるが、いずれにしてもレビュー担当者には同じアセットを二度投稿したことが伝わってしまう。これは、今後多くのコンテンツを投稿していく上で決して良い印象とはならない。

このパイプライン全体のスクリプトは、Pythonの標準ライブラリのみを使用しており、特別な依存関係をインストールする必要がないため、Python 3.9以降が動作する環境であればすぐに利用できる。筆者はこのシステムを、CPUが1つ、RAMが2GBという非常に限られたスペックのサーバーで運用している。このような制約された環境で効率的に動作させるために、いくつかの工夫が凝らされている。例えば、画像処理のような重い作業は複数のコアで並行して行わず、一つずつ順番に処理する方が実際には高速である。並行処理はかえってシステムのリソースを浪費し、パフォーマンスを低下させることがあるためだ。また、各アセットの処理後にはgc.collect()関数を呼び出してメモリを明示的に解放することで、次の処理に十分なメモリを確保する。さらに、メモリ使用量を監視する際には、平均的な使用量ではなく、resource.getrusage()を使ってピーク時の使用量を把握することが重要だ。これは、メモリ不足（OOM: Out Of Memory）によるプロセス強制終了を防ぐためである。特に重いレンダリング処理は、ファイルごとに別々のサブプロセスとして実行し、処理が完了したらサブプロセスが終了することで、OSが使用していたメモリを確実に回収する仕組みを採用している。これにより、全体としての安定性が向上する。プレビュー画像は低解像度（60dpi）で確認し、最終的なレンダリングは高解像度（300dpi）で行うことで、不要なリソース消費を避けるという点も、効率化のための重要なポイントだ。

数百を超えるアセットを扱うようになると、ファイルの整理方法も重要となる。筆者が提案するフォルダ構造は、project/の下にassets/（生の出力ファイル）、output/（提出準備完了ファイルとメタデータ）、packs/（最終製品のZIPファイルとカバー）、research/（調査メモ、スクレイプログ、ソース）、scripts/（ツールスクリプト）といった階層を持つ。特にresearch/フォルダには、将来的な製品開発の基盤となる調査ログなどを永久に保存しておくことが強く推奨されている。筆者は以前、これを「整理」として削除してしまい、後に再構築の際にその重要性を痛感したという。これらのupload_trackerやmake_metadataスクリプトは、より大きなパイプラインの一部として機能する。例えば、Markdownドキュメントからスタイル付きPDFを生成するmd2pdf.pyや、最終製品をZIP化しカバー画像を作成するpack_product.pyなどが連携している。これらのツールは、わずか二つのサードパーティ製パッケージにしか依存せず、合計約19,000行のパイプラインコードと、300ページ以上の調査に基づいている。これら全ての工夫は、特別な「賢い」技術ではなく、「正しく書かれたヘッダー」「何を投稿したかを覚えているテキストファイル」「一度に一つのタスクを実行するマシン」というシンプルな要素の組み合わせだ。この組み合わせによって、手作業で投稿状況を再確認する必要がなくなり、筆者は信頼できる作業環境を手に入れた。この一連のスクリプトと知見は、デジタル製品を構築する人々にとって、過去に筆者が経験したような重複投稿の苦労を避けるための「パイプラインスターターキット」として提供されている。