はじめに

日本向けのAkeneo SaaS移行では、商品データが Akeneo v6 Production から Akeneo SaaS Production へクローンされます。ただし、移行期間中も Akeneo v6 は日々の業務で継続して使用されるため、Phase 1 のデータクローン開始後に v6 で行われた更新は、慎重に記録し、後でSaaSへ再適用する必要があります。

本ガイドでは、移行期間中の 差分データ の更新および管理に関するポイントを説明します。差分データとは、2026年8月24日 の Phase 1 開始後に Akeneo v6 で行われた商品更新、新しいSKU/SKNの組み合わせ、またはコンテンツ変更を指します。これらの変更は、SFCC同期およびGo-Live前にSaaSが最新の業務データを保持できるよう、 Phase 3: 差分データ再入力（2026年9月7日～11日）の期間中に Akeneo SaaSへ再適用する必要があります。

繰り返しの手作業を減らすため、日本eCommerceチームは日々の変更を集約し、必要に応じて各更新の最終版をSaaSへ反映することができます。本ガイドの目的は、チームがこれらの更新を一貫して管理し、変更漏れを防ぎ、Akeneo SaaSが検証および SFCCへの同期に向けて準備できるようにすることです。

合意した通り、データの複雑性を考慮し、キャロルはフェーズ2およびフェーズ3における差分商品データの更新をサポートすることに同意しました。日本eコマースチームおよびその他のユーザーは、V6で行った変更を記録し、SaaS上でデータを検証するだけでよいです。

データ準備フェーズの概要

Phase 1: Akeneoプロジェクトチームが Akeneo v6 Production から Akeneo SaaS Production へのデータクローンを開始します。

Phase 2: Carolが Akeneo SaaS Production へのアクセス権を受け取り、データ変換、インポートプロファイル設定、およびその他必要な準備作業を開始します。

フェーズ3：キャロルは引き続き差分情報をAkeneo SaaS Productionに入力します。

日本eコマースチームがAkeneo SaaS Productionへのアクセスを受け取った後、キャロルが入力したデータを検証し、システムの動作を確認します。

Phase 4: データが Akeneo SaaS Production から SFCC へ同期されます。

Phase 5: Hypercareサポートを開始します。

推奨データログ形式

個人ログ

Phase 1 および Phase 2 の間、日本チームの各メンバーは、更新したSKUを記録するための個人ログシートを管理できます。例：

sku	非画像データ	画像
1234567	TRUE	FALSE
1234256	FALSE	TRUE

共有ログ

Akeneo v6 からエクスポートし、Akeneo SaaSへインポートできるようにするため、一意のSKUを持つ共有ログを管理します。例：

各SKUはログ内で一度だけ表示される必要があります。重複レコードがある場合は、下記のように赤色でハイライトされます。各SKUにつき1レコードのみ残るよう、重複行を削除してください。

シートにアクセスするにはこちらをクリックしてください。タブは2つあります。[phase1_2] は Phase 1 および Phase 2 中に行われたすべての変更を記録するためのタブです。[phase3] は Phase 3 中に行われた変更を記録するためのタブです。

データの再入力方法

再入力するデータには、以下の3種類があります。

1. 非画像 / 非日付時刻データ

エクスポート対象となる属性は約 226項目 あり、下記では緑色でハイライトされています。

その他の属性は、使用されていない属性、または日次の AS400インポート によって更新されるシステム属性です。例えば upc などは、 Akeneo v6 からエクスポートする必要はありません。

キャロルはフェーズ2の最終日およびフェーズ3の最終日にAkeneo v6からデータをエクスポートし、その後Akeneo SaaS Productionに再インポートします。

Phase 4 は金曜日の午後に実施されるため、各担当者が Akeneo v6 Production と Akeneo SaaS Production の両方で自身の更新内容を管理する必要があります。

完全なリストはこちらをクリックしてください。

2. 日付時刻データ

日付時刻属性はカスタム属性であるため、クローン作業中に Akeneoプロジェクトチーム によって Akeneo SaaS から削除されます。

日時属性（例：scheduled_publish_time-ja_JP）はカスタム属性であるため、クローニングプロセス中に Akeneo Project Team によって Akeneo SaaS から削除されます。

日付属性（例：date_archived-ja_JP）はクローン可能です。ただし、差分データについては、ユーザーが専用のインポートプロセスを使用してインポートを実施する必要があります。

Phase 2 では、Carol がまず Akeneo SaaS 上で日付／日時属性を再作成します。Phase 2 の終了時までに、すべての日付および日時の値をインポートします。

フェーズ3の最終日に、キャロルさんはAkeneo v6からデータをエクスポートし、その後Akeneo SaaS Productionに再インポートします。

Phase 4 は金曜日の午後に実施されるため、各担当者は Akeneo v6 Production と Akeneo SaaS Production の両方で、自身の更新内容を各自で管理する必要があります。

この情報は、V6から直接エクスポートできます。

ID	Data format in V6 and SaaS / V6とSaaSにおけるデータ形式
date_archived-ja_JP	DD/MM/YYYY, eg 1/1/2001
jp_online_date-ja_JP	DD/MM/YYYY, eg 1/1/2001
preorder_release_date-ja_JP	DD/MM/YYYY, eg 1/1/2001
scheduled_publish_time-ja_JP	YYYY-MM-DDTHH:mm:ss±HH:mm, eg 2026-07-09T03:00:58+00:00
scheduled_unpublish_time-ja_JP	YYYY-MM-DDTHH:mm:ss±HH:mm, eg 2030-07-16T15:00:00+00:00
unpublished_date	DD/MM/YYYY, eg 1/1/2001
available_only_for_specific_customer_group_end_time-ja_JP	YYYY-MM-DDTHH:mm:ss±HH:mm, eg 2030-07-16T15:00:00+00:00
available_only_for_specific_customer_group_start_time-ja_JP	YYYY-MM-DDTHH:mm:ss±HH:mm, eg 2030-07-16T15:00:00+00:00
available_shipping_method_end_time-ja_JP	YYYY-MM-DDTHH:mm:ss±HH:mm, eg 2030-07-16T15:00:00+00:00
available_shipping_method_start_time-ja_JP	YYYY-MM-DDTHH:mm:ss±HH:mm, eg 2030-07-16T15:00:00+00:00

SaaSで日付時刻データをインポートする

標準の product_import プロファイルは使用できません。上記の日付時刻形式を受け入れることができるため、専用の 日付時刻インポートプロファイル を使用してください。

サンプルファイルにアクセスするにはこちらをクリックしてください。

インポートをクリックします。
tailored_import_date_time_jp を選択します。

3. XLSXファイルをドラッグ＆ドロップします。

4. 更新のみを選択します。

5. インポートを起動をクリックします。

6. 完了すると、以下のようなメッセージが表示されます。

7. これで日付時刻データのインポートは完了です。

3. 画像データ

商品画像については、命名規則およびデータの保存方法が異なります（v6では商品属性に保存され、SaaSではAssetとして管理されます）。そのため、v6からエクスポートして直接インポートすることはできません。

決定事項：キャロルさんと協議した結果、日本eコマースチームはオプションCで進めることに合意しました。キャロルさんは、チームから提供されたログに基づいて差分画像を更新します。

この点を踏まえ、以下のオプションを検討できます。

オプションA：まずZIPファイルを保存し、最後に解凍・リネームする

参考のみ — 合意した方法ではありません

PIE からダウンロードしたZIPファイルについては、各担当者が共有SharePointフォルダにコピーを保存してください。 JP_SaaS_delta_images

JP_SaaS_delta_images 内で、日本チームは以下のとおり画像準備およびアップロードを行います。

Phase 2 の終了までに、日本チームは phase1_and_2 フォルダ内の画像を解凍し、CarolのVBAツールを使用して _p* にリネームしたうえで、 Akeneo SaaS Production へアップロードします。
Phase 3 の終了までに、日本チームは phase3 フォルダ内の画像を解凍し、CarolのVBAツールを使用して _p* にリネームしたうえで、 Akeneo SaaS Production へアップロードします。
Phase 4 は金曜日の午後に実施されるため、各担当者が Akeneo v6 Production と Akeneo SaaS Production の両方で自身の更新内容を管理する必要があります。

注意： 画像準備作業の品質には十分注意してください。異なるZIPファイル内で同じ画像ファイル名が存在するものの、実際には異なる画像を指している場合があります。上書きや誤った画像のインポートを避けるため、慎重に確認してください。

オプションB：解凍・リネーム済みファイルを直接保存する

参考のみ — 合意した方法ではありません

これは オプションA と似ていますが、日本チームの各担当者は、 JP_SaaS_delta_images フォルダに配置する前に、まずファイルを解凍し、CarolのVBAツールを使用して画像を _p* にリネームする必要があります。

注意： 画像準備作業の品質には十分注意してください。ファイルは共有フォルダに保存する前に解凍・リネームされるため、各担当者は、正しい画像が選択されていること、CarolのVBAツールを使用して正しくリネームされていること、正しいフォルダに配置されていること、そして他の担当者の作業を上書きしていないことを確認する必要があります。誤ったファイル名、画像漏れ、重複画像、または上書きされたファイルは、Akeneo SaaS Productionへのアップロード時に問題を引き起こす可能性があります。

オプションC：Akeneo v6からエクスポートし、Akeneo SaaSへインポートする — 最も信頼性が高いが、技術的な対応が必要

合意した方法

この方法は、画像をAkeneo v6から直接エクスポートし、その後Akeneo SaaSへインポートできるように準備するため、最も信頼性が高い方法と考えられます。ただし、エクスポートされた画像ファイルはそのままSaaSへインポートできる状態ではないため、技術的な対応も必要になります。

エクスポート後、画像はSKUおよび画像位置ごとのネストされたフォルダ構造で整理されます。そのため、各ファイルを抽出し、SaaSのアセット命名規則に従ってリネームし、正しいフォルダに集約したうえで、インポート前に検証する必要があります。画像数が多い場合、この作業には慎重な一括処理とファイル確認が必要となり、誤ったファイル名、画像漏れ、重複ファイル、または意図しない上書きを避ける必要があります。そのため、このオプションでは、技術的なサポート、または一括ファイル処理や画像準備に詳しい担当者の対応が必要になる場合があります。