モール別に商品画像を作り直すたびに起きていること
複数モールで商品画像を作る作業には、次のような性質があります。
- モールごとにサイズ・形式・容量上限・余白の指定が違う
- 同じ商品でもモールの数だけ書き出し作業が発生する
- 文言（キャッチコピーや価格帯の表示）だけをモール別に少し変えたいケースが多い
- 誰が、いつ、どの設定で書き出したかが個人のファイル操作の記憶に依存しやすい
この状態で困るのは、作業そのものの手間よりも「前回と同じものをもう一度作れるか」が保証されていないことです。担当者が変わったり、時間が経ってから同じ商品の画像を作り直す必要が出たりすると、以前どの設定・どのテンプレートで作ったかを探すところから始めることになります。
relmeaでは、この「再現できない」状態を構造で解消することを設計の出発点にしました。単に書き出しを速くするツールではなく、1回の生成を記録に残し、同じ入力からいつでも同じ結果を作り直せることを前提にしています。
1つのテンプレートからモール別の規格ごとに書き出す仕組み
relmeaのツールは、1つの商品テンプレート（.aiファイル）から、楽天・Amazon・Yahoo!それぞれの商品画像を一度の実行で生成します。仕組みは大きく2段階です。
1段目：名前を付けたテキストフレームを差し替える
テンプレート内のテキストフレームに名前を付けておき、「フレーム名：差し替え文言」という対応関係を渡すと、該当フレームの文言が置き換わります。フレームの位置や書式そのものはテンプレート側の設計に従うため、差し替える側は「どのフレームに何を入れるか」だけを指定します。
2段目：モールごとの規格に合わせて比例スケールして書き出す
楽天・Amazon・Yahoo!はそれぞれサイズ・形式・容量上限・余白の指定が異なるため、テンプレートのアートボードを各モールの規格に合わせて比例スケールしてから書き出します。
なお、実際に使っている規格値（具体的なピクセル数や容量上限）は、各モールの公開仕様をもとにした仮の値から出発し、運用のなかで微調整を重ねている段階です。そのため本記事では規格の数値そのものは扱わず、仕組みの構造に絞って説明します。
この方式のポイントは、モールが増えても「テンプレートを増やす」のではなく「書き出しの規格設定を増やす」だけで対応できることです。商品ごとのデザインはテンプレート1つに集約され、モールごとの違いは書き出し工程側の設定として分離されています。
原本を触らない設計｜一時コピーで開き、写真はハッシュで照合する
自動化ツールが元のデザインファイルを直接開いて書き換える設計は、途中でエラーが起きたときに原本が壊れるリスクを常に抱えます。
relmeaのツールでは、原本の.aiファイルを直接開きません。実行のたびに一時コピーを作成し、そのコピーに対して作業します。原本は読み取り以外の操作を一切受けません。
写真素材を差し替える場面でも同じ考え方を取っています。差し替え作業の過程で、元の写真ファイルそのものを書き換えることはせず、作業前後でファイルのSHA-256ハッシュ値が一致していることを実測して確認します。ハッシュが一致しているということは、そのファイルの中身が変わっていないことの証明になります。
この「原本に触れない」という制約は、一見すると回りくどく見えますが、実際には次の効果があります。
- 途中で処理が失敗しても、原本には何の影響も残らない
- 何度でも同じ原本から作り直しを試せる
- 「元のファイルが壊れていないか」を都度目視確認する必要がなくなる
自動化の対象を増やすほど、失敗したときに何が壊れたかを人間が確認するコストは上がります。原本を最初から書き換えの対象外にしておくことで、そのコストそのものを設計から取り除いています。
書き換え前に「現在値」を照合する｜全部か、ゼロかの原則
複数モールの画像を1つのテンプレートから量産する仕組みで最も起きやすい事故は、テンプレートの構造を勘違いしたまま書き換えを実行してしまうことです。例えば、テキストフレームの名前が変わっていた、レイヤーの順序が変わっていた、といった変更にツール側が気づかないまま処理を進めると、意図しない箇所が書き換わったり、書き換わるべき箇所が書き換わらなかったりします。
relmeaのツールでは、これを防ぐために、書き換えの前に必ず「テンプレートの構造を読む」読み取り専用の工程を挟んでいます。この工程は次の情報を返します。
- アートボードの寸法
- レイヤーの構成
- テキストフレームの名前と現在の文言
- 使用フォント
- 使用カラー
- リンクされている画像
- 差し替え可能な箇所の一覧
この「現在値」を、書き換えを依頼する側が期待値として渡し、実行の直前に照合します。1件でも期待値と現在値が食い違えば、その時点で処理を停止し、1件も書き換えません。
テキストと写真のどちらについても、一部だけ解決できて一部だけ解決できない、という状態を許していません。全ての差し替え対象が解決できて初めて実行し、1つでも解決できなければ何も書き換えずに終わります。
この「全部か、ゼロか」という原則は、処理速度を犠牲にしてでも、中途半端な書き換え結果が生成物として残ることを避けるための設計判断です。中途半端に書き換わった画像は、見た目では気づきにくく、モール掲載後に発覚すると差し戻しの範囲が広がります。
配置画像に名前を付ける運用ルール
配置画像のスロットに名前が付いていない場合、ツールは配置順（何番目に配置されているか）に依存して特定することになります。テンプレートに手を加えて画像の配置順が変わると、この番号がずれて意図しない画像が差し替え対象になり得るため、relmeaでは配置画像にも一意な名前を付ける運用をテンプレート側のルールとしています。
生成レシートと再生成｜何を変えたかを系譜でたどる
自動化を継続的に使ううえで欠かせないのが、「いつ・何を・どの設定で生成したか」を後から確認できることです。relmeaのツールは、生成のたびに16文字の生成IDを発行し、次の情報を記録します。
- 使用したテンプレートのパス
- レシピ（書き出し設定）の名前とバージョン
- 渡した全パラメータ
- 出力先のパスとファイルのハッシュ値
- 実行日時
- 親の生成ID（元になった生成があれば）
この記録を「生成レシート」と呼んでいます。レシートを読み取るだけであればIllustrator自体を起動する必要がなく、過去に何をどう生成したかを軽い操作で確認できます。
同じ入力から作り直す、一部だけ変えて作り直す
生成IDを指定すると、同じ入力から同じ結果を作り直すこともできます。さらに一部のパラメータ（例えば見出しの文言だけ）を指定して、そこだけ変えた再生成も可能です。この場合、新しく発行されるレシートには元の生成IDが親として記録され、どの生成がどの生成から派生したかを後からたどれます。
ここで1点、意図的な制約を設けています。再生成時に2要素以上を同時に変更すると、「どの変更が結果に効いたのか切り分けられない」という警告が付きます。変更自体を禁止するわけではありませんが、1回の再生成で複数の変数を動かすと、後から見返したときに「なぜこの見た目になったか」の説明ができなくなるためです。
過去の承認を今回に流用しない
出力先の既存ファイルを上書きするには「上書きする」という指定を明示する必要があり、これは元のレシートから引き継がれません。過去に上書きを許可して実行したことがあっても、それが今回の実行の暗黙の許可にはならない、という設計です。同じ理由で、枚数超過などの承認を通す指定も引き継ぎません。過去の承認を今回に流用しないことで、上書き事故を防いでいます。
また、部分的な失敗（例えば楽天向けの書き出しだけ失敗した場合）は失敗の一覧に理由付きで記録され、全体を失敗として扱いません。成功した分は成功として残り、失敗した分だけを個別に確認・再実行できます。
CSV量産とバナー展開に広げたときに出てくる罠
同じ仕組みは、CSVの行数ぶんの画像をまとめて生成する経路や、バナーのサイズ違い（複数の広告枠サイズ）を1つのテンプレートから作る経路にも応用しています。
CSVからの一括生成では、Illustratorを起動する前にCSVの内容を検証し切ります。列が不足している、行数が0件である、といった不備があれば、Illustratorを起動する前の時点でエラーとして扱います。生成が始まってから止まるより、始まる前に止める方が、原本や出力先への影響がありません。行ごとに生成IDが発行されるため、CSVの何行目がどの生成に対応するかも後から追えます。
バナーサイズ違い（300x250、728x90、160x600など）の展開も、商品画像と同じ「1つのテンプレート＋規格ごとの書き出し設定」という構造をそのまま使っています。モールの規格が広告枠のサイズに変わるだけで、テンプレートを増やすのではなく書き出し設定を増やすという考え方は共通しています。
こうして応用範囲を広げていくと見えてくるのが、前の節で触れた「無名スロットの罠」です。配置画像に名前を付けずに走査順（何番目に配置されているか）だけで特定する運用を続けると、テンプレートの改訂（画像を1つ増やす、順番を入れ替える）のたびに、走査順に依存した処理がずれるリスクが積み重なります。
これは規模が小さいうちは表面化しません。テンプレートが1つ、モールが2つ程度であれば、順序のずれに気づいて手直しする余地があります。しかしテンプレートの種類とモールの数が増えるほど、順序依存の脆さは検知されにくい形で蓄積していきます。
relmeaが配置画像への命名をテンプレート側の運用ルールとして定めているのは、自動化の対象を広げる前に、対象を特定する方法そのものを「名前」という安定した参照に揃えておくためです。速く作ることよりも、何度でも同じように作り直せる状態を保つことを優先した結果、この運用ルールに行き着きました。