【ITニュース解説】From One Prompt to 39 Finished Products: What Actually Broke

デジタルコンテンツのアップロードと製品化は、一見するとシンプルな作業に見える。しかし、その過程には多くの技術的課題が潜んでおり、それらを解決するためには具体的なアプローチが必要となる。ある開発者が、Adobe Stockへデジタル画像を一括アップロードしようとした際、メタデータに関する不備が原因で全てのアップロードが拒否された経験から、製品化プロセス全体を自動化するパイプラインを構築した事例を紹介する。この経験は、システム開発において単に機能を実現するだけでなく、外部システムとの連携、エラー処理、リソース管理、そして長期的な運用までを考慮することの重要性を示している。

最初に直面した課題は、メタデータヘッダーの厳格な要件であった。Adobe Stockのアップロード用CSVファイルは固定の5列ヘッダーを要求し、Vecteezyは4列、Dreamstimeは15列と、プラットフォームごとに形式が異なる。もし提出するCSVファイルがこれらの要件と少しでも異なると、システムは即座にファイルを拒否し、画像の中身を見る前に不合格としてしまう。開発者は、ヘッダーが1列不足していただけで、一晩かけて準備した全バッチを無駄にした経験から、この厳格なルールを学んだ。この問題の解決策は、退屈ながらも確実なものだった。プラットフォームが要求するヘッダーを正確に記述し、それ以外の情報を一切含めないスクリプトを開発したのである。このスクリプトは、単一の画像フォルダから、--platform adobe、--platform vecteezy、--platform dreamstimeといったフラグを用いて、それぞれのプラットフォームに合ったCSV形式を生成できるようにした。ファイル名からタイトルを自動生成する機能も持たせたが、最終的には人間がレビューする際に適切に見えるよう、別途用意したタイトルとキーワードのJSONファイルを使うようにした。この経験から、外部システムと連携する際は、その仕様を正確に理解し、それに完全に準拠することの重要性を痛感した。また、全てのプラットフォームで使える汎用的なCSV形式を作ろうとするのではなく、プラットフォームごとに専用の形式を用意し、アップロード前に列数を検証することが不可欠であると学んだ。

次に起こった失敗は、重複投稿の問題であった。ネットワークの不具合により、すでにアップロードされたアイテムを誤って二重に投稿してしまい、アカウント停止の危険に直面した。デジタルコンテンツのプラットフォームでは、重複投稿は厳しく禁じられている場合が多く、このようなミスは重大なペナルティにつながる可能性がある。この問題を解決するため、開発者はアップロードの履歴を記録する「台帳」スクリプトを導入した。これは、未完了のタスクを表示し、完了したアイテムをマークし、現在の状態の概要を提供するシンプルなテキストベースの台帳である。この台帳をチェックすることで、過去にアップロードしたアイテムを再送信するミスを防ぎ、二重投稿のリスクを完全に排除した。この教訓は、自動化されたパイプラインが外部アカウントにアクセスする際には、必ず「自身の状態を記憶する」仕組みが必要であるという普遍的な原則を示している。特に深夜の作業など、人間の記憶に頼ることが難しい状況では、システムの記憶が不可欠となる。

このパイプライン全体は、1 vCPU、2 GB RAMという非常に限られたリソースのサーバー上で実行されるように構築された。この制約が、開発のあらゆる側面に規律をもたらした。限られたリソースの中で効率的に作業を進めるために、いくつかの習慣が確立された。例えば、イメージ処理のジョブを並列で実行しようとすると、かえってシステム全体が効率を失うため、一度に一つのプロセスのみを実行するようにした。また、各アセットの処理後にはメモリを解放するgc.collect()を呼び出すことで、複数のアイテムを処理する際にメモリ使用量が徐々に増加してシステムが停止するのを防いだ。メモリ使用量の計測では、平均値ではなくピーク値に注目し、resource.getrusage(RUSAGE_SELF).ru_maxrssを用いて最大メモリ使用量を把握した。これにより、いつメモリが枯渇するかが正確に予測できるようになった。さらに、重いレンダリング処理は各ファイルごとにサブプロセスを生成して実行することで、処理が終了した後にメモリが確実にオペレーティングシステムに返還されるようにした。プレビュー画像は低解像度（60 dpi）で確認し、最終版のみ高解像度（300 dpi）でレンダリングすることで、デバッグ中に無駄なリソース消費を防いだ。これらの対策は決して高度なものではなく、限られたサーバー環境が必然的に開発者に課す規律であったが、結果としてパイプラインはよりシンプルで堅牢なものになった。

コンテンツを「製品」として提供するための工程も重要である。開発者は、生のMarkdown形式のドキュメントを持っていたが、そのままでは販売可能なPDF製品にはならないことに気づいた。ドキュメントを製品に変えるには、見出し、表、リスト、リンクといったスタイリングが必要だった。この課題は、reportlabというライブラリを利用したmd2pdf.pyスクリプトによって解決され、Markdownファイルを販売可能なPDFに変換できるようになった。パッケージングも同様であった。カバー画像のない単なるzipファイルは購買意欲をそそらない。pack_product.pyスクリプトは、Pillowというライブラリを使ってファイルをバンドルし、1280×720ピクセルのカバー画像と600×600ピクセルのサムネイルを生成して、それらをzipファイルとともに特定のシステムフォルダに格納するようにした。このパイプライン全体で、外部ライブラリはPillowとreportlabの二つのみを使用し、その他は全てPythonの標準ライブラリで構築された。これは、複雑なフレームワークに頼らずとも、シンプルかつ効果的な解決策が実現可能であることを示している。

最後に、開発者が最も過小評価していたのは、フォルダの構造であった。体系化されていないフォルダ構成は、まるで雑然とした引き出しのように、コンテンツが散乱し、後から必要なものを見つけるのが困難になる。最終的に採用されたフォルダ構造は、次の五つのフォルダで構成された。assets/には生の出力ファイル、output/には提出準備が整ったファイルとメタデータCSV、packs/には完成したzipファイルとカバー画像、research/にはメモやスクレイプログ、scripts/には各種ツールが格納される。この経験から学んだ重要なルールの一つは、「research/フォルダは永久に保持すること」であった。一度「クリーンアップ」のために削除してしまった結果、将来の三つの製品の原材料となる情報を失ってしまったという苦い経験から、スクレイプログやメモは単なる「ごみ」ではなく、未来の「在庫」であるという認識に至った。

これらの困難な経験と解決策を経て、最終的に開発されたパイプラインは、約19,000行の親プロジェクトコードと300ページ以上のリサーチに基づき、39の製品をパッケージ化し、856 MBの出力を生成できるようになった。この全てのプロセスは、前述の1 vCPU、2 GB RAMの限られたサーバー上で検証された。このパイプラインは特定のフレームワークやクラウドサービスに依存せず、Python 3.9以降の環境で動作し、メタデータ生成とトラッキング機能だけであれば、追加のライブラリインストールも不要である。この事例は、システムエンジニアを目指す者にとって、単にコードを書くスキルだけでなく、問題の特定、適切な解決策の設計、リソースの効率的な利用、そして長期的な運用を見据えた設計能力が、いかに重要であるかを教えてくれる。シンプルながらも堅牢なシステムを構築する過程で得られる知見は、どんな高度な技術にも勝る価値を持つと言えるだろう。