生の写真からマルチチャネル在庫へ

数枚の写真から出品を作るのは簡単に見える。物品を認識し、タイトルを生成し、価格を見積もり、マーケットプレイスの API を呼べばよい。この構図はデモでは機能する。しかし、箱一つ分を丸ごと処理する、写真が順不同で届く、同じ物品を複数チャネルに配信する--そうなった途端に足りなくなる。

本当の問題は、もはやコンテンツ生成ではない。不完全な入力から販売に至るまで、唯一の物理的な物品のライフサイクルを、混同・重複・在庫衝突なしに制御することだ。

この記事ではまず、写真フォルダから出品の下書きに至る実運用のパイプラインを説明する。次に、社内データベースが真実の源であり続け、アダプターが eBay、Leboncoin その他の販売チャネルを同期するマルチチャネル・アーキテクチャへの発展を提案する。

指針：AI は観察と提案を生み出してよい。識別情報、在庫、不可逆な遷移は、明示的なアプリケーションのルールの管理下に置かれなければならない。

写真、物品、出品は三つの異なる識別情報である

本の箱がこの問題をよく示す。同じ一冊が、表紙、裏表紙、背、扉、複数の本文ページで表現されうる。逆に、よく似た二冊が著者、叢書、装丁、ほぼ同一の見た目を共有することもある。

したがって最低限、次を区別しなければならない。

メディアファイル：内容とハッシュで識別される
物理的な物品：ここでは複数の写真を持ちうる唯一の一冊
正規レコード：タイトル、状態、属性、価格をまとめたもの
リモート出品：プロバイダーごとの制約に固有のもの
販売：在庫単位を消費または予約するもの

これらの識別情報を混同すると、最も高くつくバグが生まれる。別の本に紐づいた写真、出品の重複、マーケットプレイス固有のデータから商品を書き換えること、一点物の二重販売である。

最初のパイプライン：箱を検証可能な本に変える

システムの最初の版は、写真がすでにまとまっていれば一冊を正しく処理できた。箱への拡張は、その前に一段階を加える。フォルダの順序、ファイル名、人工的な区切りに頼らず、各物品に対応する写真の集合を見つけ出すことだ。

1. 信頼できない入力を棚卸しする

各画像はまず信頼できない入力として扱う。

拡張子ではなくデコードによって実際の形式を検証する
ファイル数、容量、展開後のピクセル数に上限を設ける
原本を変更せずに EXIF の向きをローカルで補正する
識別、再開、追跡のためにハッシュを計算する
存在すれば EXIF の撮影時刻を読む
結果が検証されるまで原本を保持する

ファイルシステムの日付は業務上のシグナルとして使わない。コピー、エクスポート、クラウド経由で簡単に変わってしまうからだ。

2. グループ化の前に記述する

安価なマルチモーダルモデルが、閉じたスキーマに従って画像をバッチで記述する。モデルはパスを選ばず、ファイルも動かさない。各写真について、とりわけ次を抽出する。

見え方の種類：表紙、裏表紙、背、扉、本文
見える書誌要素：タイトル、著者、出版社、ISBN
特徴的な印：装丁、欠陥、模様、書き込み
本が実際に写っているか、および観察の確信度

これらの構造化された観察が、次に疎な候補グラフを養う。同一の ISBN、テキストの重なり、両立する視覚的手がかり、時間的近接によって、二枚の画像が候補になりうる。

タイムスタンプは意図的に弱い手がかりにしてある。数分差で撮られた二枚は同じ物品を写している可能性が高いが、別々の二冊が続けて撮影されたこともありうる。時間的近接は検証を開く。それ単独で統合を引き起こすことは決してない。

3. 誤った混同より、一つ多い分割を選ぶ

候補のペアやグループはすべて、的を絞った視覚的検証を通る。統合は肯定的な証拠がある場合にのみ受け入れる。強い矛盾--たとえば異なる二つの ISBN--は照合を阻む。不確かな判断は関係を一切作らない。

この選択は再現率より精度を優先する。unassigned キューに残った一枚の写真は人の確認一回分のコストで済むが、一つの出品に混ざった二冊は、誤った説明、矛盾した価格、係争になる販売を生みうる。

結果は完全で追跡可能な分割である。

安全とみなされたグループ
レビュー対象として印を付けたグループ
未割り当ての写真
利用可能な物品が検出されず無視された画像

4. 不可逆な境界に人を置く

インターフェースはこの入出力の順序をそのまま映す。取り込み、グループ化、検証、そして作成。安全なグループは事前選択してよいが、曖昧なケースは決して選択しない。未割り当てと無視された写真は見えたままだが、次のパイプラインへ黙って送られることはない。

確認後、各グループは単体パイプラインの入力になる。

物品とその状態の詳細分析
カテゴリ属性の構築
類似品の検索と価格見積もり
忠実な写真の準備
メディアのアップロード
自動公開なしの下書き作成

「メタデータと価格」と「写真の準備」の枝は並列に実行できる。互いに依存するのは下書きを組み立てる時点だけだからだ。

この最初のアーキテクチャがすでに解決すること

モデルの具体的な選択より、四つの性質のほうが重要だ。

慎重さ：弱い類似だけで二つの物品を統合することはない。
再開可能性：高価な観察と判断は、ハッシュ、モデル、プロンプトのバージョンをキーにキャッシュされる。
追跡可能性：各メディアは最終マニフェストに正確に一度だけ現れ、配置と関連する判断を伴う。
責務の分離：モデルが観察し、業務の中核が決定し、インターフェースが確認を求め、アダプターがプロバイダーと話す。

このアーキテクチャは、単一のマーケットプレイスが唯一の配信チャネルで、その下書きがリモート在庫の役割を果たせる間は十分である。しかし唯一の物品が複数の場所に公開された途端、構造的な限界に達する。

公開パイプラインから在庫システムへ

マルチチャネルのシステムでは、eBay、Leboncoin、その他の販売チャネルが物品の真実の源になってはならない。各プラットフォームは独自のカテゴリ、状態、識別子を持ち、いずれも他を信頼できる形で把握していない。

社内データベースが正規の状態を持たなければならない。物品の識別情報、在庫単位、メディア、基準価格、ライフサイクル、リモート出品、販売である。アプリケーションはこのデータベースを読み、プロバイダーはそれぞれの契約に合わせた投影を受け取る。

目標アーキテクチャは三つの古典的パターンを組み合わせる。

各マーケットプレイスの特殊性を隔離するポートとアダプター
意図を失うことも危険に再実行することもなく、データベースとリモート呼び出しを同期するトランザクショナル outbox/inbox
システム間の避けられないずれを補正する定期的な突合

物理的な物品を中心にしたデータモデル

一点ずつ販売する物品なら、最小モデルは単純なままでよい。

エンティティ	責務
`media_asset`	原本、ハッシュ、EXIF メタデータ、派生物
`item`	マーケットプレイスに依存しない正規レコード
`inventory_unit`	物理的な一点と実際の可用性
`listing`	特定プロバイダー向けの物品の投影
`provider_binding`	リモート識別子、バージョン、最後に確認した状態
`reservation`	取引中の在庫の一時的な確保
`sale`	成立した販売、発生元プロバイダー、財務データ
`inbox_event`	重複排除された受信イベント
`outbox_event`	実行すべき同期の意図
`sync_attempt`	試行、レイテンシ、正規化された応答、エラー

商業的な内容はチャネルごとに変わってよいが、識別情報と数量を各出品に複製してはならない。一点物の本なら inventory_unit.available_quantity はゼロか一であり、この制約はデータベースがトランザクションで保証しなければならない。

脆い二重書き込みなしに公開する

素朴な実装は二つの操作を続けて行う。データベースを更新し、次にマーケットプレイスを呼ぶ。その間でプロセスが落ちれば、データベースとプロバイダーは食い違う。順序を逆にしても解決しない。ローカルのトランザクションが失敗したのに出品だけ作られることがある。

トランザクショナル outbox はこの罠を避ける。

ローカルのトランザクションが物品を変更し、outbox_event に意図を挿入する
ワーカーがその意図を読み、該当するアダプターを呼ぶ
アダプターは冪等キーまたは安定した業務識別子を使う
リモートの応答が provider_binding と出品の状態を更新する
リトライは同じ意図を再実行するのであって、新しい論理的作成ではない

分散環境での仮想的な「exactly once」を追い求めはしない。at least once の配信を受け入れ、各処理を冪等にする。

アダプターは共通の語彙を公開する。たとえば：

upsert_draft(item)
publish(listing)
update_price(listing, price)
reserve_or_pause(listing)
end_listing(listing, reason)
fetch_status(binding)
fetch_recent_sales(cursor)

各プロバイダーはこの契約を自身の API--あるいはプラットフォームが許す同期方式--に翻訳し、その詳細を業務ドメインに漏らさない。

真偽値ではなくライフサイクルを管理する

published = true というフィールドでは足りない。明示的な状態機械が遷移を観察可能にし、ありえない組み合わせを防ぐ。

出品には独自の状態--下書き、公開中、有効、停止中、終了、エラー--があるが、それらは在庫単位の投影のままである。inventory_unit がすでに sold を示していれば、有効な出品が物品を利用可能にすることは決してない。

あるチャネルでの販売は他を閉じなければならない

マーケットプレイスが販売を通知したとき、受信側の処理も冪等な inbox を通る。生のイベントは保持され、プロバイダーの識別子で重複排除され、ローカルのトランザクションで適用される。

available → sold の遷移は、ロック、バージョン比較、条件付き更新のいずれかを使わなければならない。こうして同時発生した二つのイベントがデータベース内で同じ単位を消費することはできなくなる。

これで物理的なリスクが完全にゼロになるわけではない。取り下げが伝播する前に、二人の買い手が二つの外部プラットフォームでほぼ同時に確定することはありうる。アーキテクチャはこの窓を大きく狭め、衝突を検知し、解決プロセスを提供する。最大限の保証は、各プロバイダーが許す Webhook、予約機構、遅延に依存する。

Webhook は突合の代わりにならない

Webhook は失われ、遅れて届き、何度も届きうる。すべてのイベントに Webhook を提供しないプラットフォームもある。したがってイベント駆動のアーキテクチャでも、ポーラーと突合タスクは必要なままである。

cron に業務ロジックを含めるべきではない。cron は冪等なジョブを起動する。ジョブは同時実行から保護され、他の処理と同じシステムで観測可能でなければならない。

妥当な初期の頻度は次のようなものだ。

目安の頻度	確認内容	期待される結果
1〜5 分ごと	Webhook のない販売と予約	他のチャネルを速やかに閉じる
10〜15 分ごと	有効な出品の状態と数量	在庫のずれを検知する
毎時	停滞したジョブ、リトライ、期限切れの予約	修復または警告する
毎晩	網羅的な突合	孤立した出品と見逃した販売を見つける
毎朝	運用サマリー	チームにレビューの優先順位を与える

これらの頻度は各プラットフォームの上限と利用規約を守らなければならない。

異常を中心にしたダッシュボード

良いダッシュボードは出品数を表示するだけでは終わらない。四つの問いに素早く答えなければならない。何を持っているか、どこに公開されているか、何がずれているか、どんな人の行動が必要か。

最も有用な指標は次の通り。

利用可能、予約済み、販売済み、レビュー中の物品
プロバイダーごとの有効な出品
孤立した、または正規の物品を持たないリモート出品
価格、数量、状態のずれ
販売から他チャネル取り下げまでのレイテンシ
未処理の最も古い inbox/outbox イベントの経過時間
アダプターごとの失敗率とリトライ回数
未割り当て写真の割合とレビューに回ったグループ
取り込んだ物品あたりの AI 呼び出しの平均コスト
チャネルごとの販売量と利益率

アラートは影響度で分類できる。

重大：販売の衝突、販売済みの物品が他所でまだ有効
高：未処理の販売イベント、リモート取り下げの失敗
中：同期の外れた出品、停滞したジョブ、期限切れの予約
情報：レビュー率の上昇、取り込みコストのずれ

各アラートは、物品、関係する出品、最後に成功した遷移、推奨される行動を指し示さなければならない。文脈のないアラートは、診断の仕事をオペレーターに押し付けるだけである。

パイプラインを書き直さずにこの発展を展開する

移行は段階的なままでよい。

正規モデルを導入する。 すでに対応しているプロバイダーの下書きを作る前に、物品と在庫単位を永続化する。
最初のプロバイダーをカプセル化する。 既存の連携をアダプターに変え、リモート識別子を必ず保存する。
outbox、inbox、突合ジョブを追加する。 チャネル数を増やす前にリトライを冪等にする。
二つ目の販売チャネルを接続する。 下書きから始め、次に公開、最後に販売の戻りを扱う。
マルチチャネルの終了を自動化する。 レイテンシを測り、衝突をテストし、人による解決モードを残す。
アラートとダッシュボードを構築する。 並行するカウンターではなく、同じイベントと状態から養う。

画像パイプラインは eBay や Leboncoin を知る必要がない。正規の物品と検証済みのメディアを生み出す。アダプターは写真がどうグループ化されたかを知ってはならない。この境界が、AI モデル、インターフェース、プロバイダーを独立に発展させることを可能にする。

結論

数枚の写真からマルチチャネル配信へ移ることは、API のリストにループを加えることではない。真実がどこに住むか、誰が在庫を持つか、各遷移をどう再実行・監査・補償できるかを決めることを強いる。

したがって堅牢なパイプラインは二段で組み立てられる。

不確かな視覚的入力を検証済みの正規の物品に変える
ライフサイクルの制御を手放すことなく、それらの物品を複数のチャネルへ投影する

AI は識別、記述、価格付けを加速する。正規データベース、トランザクショナルな遷移、冪等なアダプター、突合が運用を守る。説得力のある自動化を本物の在庫システムに変えるのは、モデル単体ではなく、この組み合わせである。