WPP ログ、STELINA/MDPI 記録、工場書類を GDST 1.1 の EPCIS ファイルに変換するための、インドネシア特化の実用的プレイブック。WPP→FAO マッピング、船舶 ID の選択肢、CSV→JSON のフロー、イベント例を含む。
買い手が単に「GDST 1.1」を求めているだけなら、明日ソフトを購入する必要はありません。インドネシアですでに保持している記録（WPP-NRI エリア、漁行ログ、ランディングノート、BKIPM 書類、工場の生産台帳）でバイヤー対応にできます。私たちはこの方法でマグロ、ハタ類、エビ、混合礁魚種の GDST ファイルを納品してきました。以下に、どのようにマッピングするかを正確に示します。
バイヤー対応の GDST ファイルの3本柱
-
信頼できるソース ID。クルーが実際に携行し、許可証に記載されている船舶 ID を使用してください。現物の書類で見つかる養殖収穫 ID を使用してください。書類に一度も現れない ID をでっち上げないでください。
-
明確なロット論理。受入時およびトリミング/梱包を通じてロットをどのように追跡するかを決めてください。紙の書類で分割や結合を説明できないものは EPCIS で検証されません。
-
適切な EPCIS パッケージング。買い手はますます EPCIS 2.0 JSON-LD を要求しています。Excel から始めても構いませんが、後でイベントに 1:1 で変換できるように列の設計を行ってください。
実務上の結論：JSON に触れる前に、ロット定義と各 KDE を証明する書類が何かを確認してください。そうすれば作業の80%は完了しています。
買い手が実際に要求する最小 KDE は何か？
インドネシアでは2つの一般的なシナリオを確認しています。
-
野生捕獲のマグロ、ハタ類、礁魚
- 種（学名＋一般名）、生産方法 = wild-capture
- 漁獲海域（FAO コード）、漁具タイプ
- 船舶識別子と旗国。漁行の開始/終了日
- 荷揚げ日と港。乗り替え（トランスシップ）された場合は搬送船と日付
- 加工業者のロット/バッチコード、生産日、数量と UoM
- 施設識別子（GLN があればそれ、なければ工場承認番号）
- 証明書／許可証の参照（該当する場合）
-
養殖バナメイ（vannamei）エビ
- 種、生産方法 = aquaculture
- 養殖場識別子（池／クラスター）、収穫日、所在地（可能であれば州名／座標）
- バイヤーが求める場合は種苗場と飼料供給者の ID
- 加工業者のロット/バッチコード、生産日、数量
- 施設識別子
買い手が厳格な GDST 要件を持つ場合は、各イベントの一意 ID、タイムゾーン、ビジネスステップ、および発生地点（readPoint）を追加してください。これらが揃っていると、買い手の処理は迅速になることが多いです。
WPP-NRI から買い手が受け入れる FAO マッピング
WPP-NRI を記録している場合、買い手は FAO を求めます。インドネシアの GDST ファイルで広く受け入れられている単純なマッピングは次のとおりです：
- WPP 571, 572, 573 → FAO 57（インド洋 東部）
- WPP 711, 712, 713, 714, 715, 716, 717 → FAO 71（太平洋 西部中央）
- WPP 718 → 混在することが多い。ティモール海／サウー海は通常 FAO 57、アラフラ海は通常 FAO 71。座標がない場合、買い手の多くは両方（FAO 57 と 71）を注記付きで併記することを受け入れます。
二つの意外と見落としがちなヒント：
- ランディングノートに座標や命名された漁場があれば、それを含めてください。WPP 718 の曖昧なケースは緯度／経度を追加すると迅速に解決します。
- オリジナルの WPP は “notes” フィールドに保持してください。監査人は元の参照を確認することを好みます。
特定の漁業についてマッピングの簡易チェックが必要ですか？WhatsApp でお問い合わせください。
当社の船に IMO 番号はありません。どの ID が受け入れられますか？
実務上、インドネシアの手釣り／日船はほとんど IMO を持っていません。GDST 1.1 は複数の識別子タイプを許容します：
- 国家登録番号または許可番号（例：MMAF 書類の番号）
- 無線コールサイン（IRCS）や MMSI（利用可能であれば）
- UVI（Unique Vessel Identifier：プログラムや登録で割り当てられている場合）
- EU 帆船向けの CFR（インドネシア沿岸艦隊では稀）
当社のルール：ランディングノートや許可証に記載され、年ごとに安定している識別子を選んでください。MDPI が管理する FIP の小型船については、プログラムで使用される船舶コードを使用し、紙の許可証にリンクするよう notes に記載してください。
Excel/CSV で開始して後で EPCIS に切り替えられますか？
はい。推奨します。EPCIS イベントを鏡写するスプレッドシートを設計すれば、変換は機械的に行えます。
クリーンに変換できる最小列：
- eventType, eventTime, timeZone, bizStep, disposition, readPointId
- inputLot, inputQty, inputUoM, outputLot, outputQty, outputUoM
- species, productionMethod, FAOArea, gearType, vesselId, flagState
- landingPort, landingDate, farmId, harvestDate
- facilityId, processType (peeling, filleting), certificateRefs, notes
その後、EPCIS 2.0 JSON-LD に変換してください。マグロのロット受入の非常にシンプルな ObjectEvent の例は次のようになります：
{
"@context": [
"https://ref.gs1.org/standards/epcis/2.0.0/epcis-context.jsonld",
{"gdst": "https://traceability-dialogue.org/ontologies/gdst#"}
],
"type": "EPCISDocument",
"schemaVersion": "2.0",
"epcisBody": {
"eventList": [
{
"type": "ObjectEvent",
"eventTime": "2025-08-01T07:15:00+07:00",
"eventTimeZoneOffset": "+07:00",
"action": "observe",
"bizStep": "receiving",
"disposition": "in_progress",
"readPoint": {"id": "urn:epc:id:sgln:8999999.00001.0"},
"quantityList": [{
"epcClass": "urn:epc:class:lgtin:08999999.00001.20250801TUNALOT01",
"quantity": 1200,
"uom": "KGM"
}],
"gdst:kde": {
"gdst:species": "Thunnus albacares",
"gdst:productionMethod": "wild-capture",
"gdst:FAOArea": ["71"],
"gdst:gearType": "HANDLINE",
"gdst:vesselId": "ID-BA-12345",
"gdst:flagState": "IDN",
"gdst:landingPort": "Bitung",
"gdst:landingDate": "2025-07-31"
}
}
]
}
}
当社は同様の手法を、小売向け出荷（例：Grouper Fillet (IQF)）や刺身向けプログラム（例：Yellowfin Saku (Sushi Grade)）でも使用しています。
ブレンドや分割を含む剥き・トリミングはどう表現するか？
TransformationEvent でブレンドと歩留まりを表現します。入力は原料ロット、出力は加工ロットです。
例：二つの池の収穫をブレンドして一つの完成ロットにするエビの剥き作業。
{
"type": "TransformationEvent",
"eventTime": "2025-08-02T10:00:00+07:00",
"eventTimeZoneOffset": "+07:00",
"bizStep": "processing",
"readPoint": {"id": "urn:epc:id:sgln:8999999.00001.0"},
"inputQuantityList": [
{"epcClass": "urn:epc:class:lgtin:08999999.00001.20250801POND01", "quantity": 800, "uom": "KGM"},
{"epcClass": "urn:epc:class:lgtin:08999999.00001.20250801POND02", "quantity": 600, "uom": "KGM"}
],
"outputQuantityList": [
{"epcClass": "urn:epc:class:lgtin:08999999.00001.20250802SHRIMPPEELED01", "quantity": 1000, "uom": "KGM"}
],
"gdst:kde": {
"gdst:processingType": "peeling",
"gdst:productionMethod": "aquaculture",
"gdst:farmIds": ["FARM-A-01","FARM-B-07"],
"gdst:harvestDates": ["2025-07-29","2025-07-30"]
}
}
分割（splits）は同じイベントタイプで、入力が1つで出力が複数になります。出力ロットコードはラベルと追跡可能なように保持してください。
買い手にメールする前の簡易検証
2段階チェックを推奨します：
- スキーマ検証。EPCIS 2.0 JSON-LD として有効か確認してください。任意の JSON Schema バリデータで EPCIS 2.0 スキーマをローカルで実行できます。スクリプトを使用する場合、検証に失敗したらビルドを失敗させてください。
- GDST ビジネスルールの確認。製品タイプとイベントごとに KDE の存在を確認します。例として、野生捕獲イベントには FAO 海域、漁具、船舶 ID が必須です。
私たちが使用する、または一般的に使われている無料オプション：
- 構造のための JSON スキーマバリデータやリンター
- イベントとコンテキストの簡易チェック用のオープンソース EPCIS 2.0 テストツール
- 送信前にイベントごとに KDE をアサートする簡単な Python または Node スクリプト
買い手が独自のチェッカーを提供する場合は、必ず最初にそのチェッカーでファイルを実行して、手戻りを避けてください。
GDST は既に収集している STELINA や MDPI のデータを取り込めますか？
はい、かつ取り込むべきです。インドネシアでは次のようにマッピングしています：
- STELINA の漁行／荷揚げ：漁行 ID、荷揚げ日／港、種別、数量、船舶許可は、荷揚げ／受領時の ObjectEvent の KDE になります。STELINA ID は notes に保持してください。
- MDPI や FIP アプリ：船舶コード、手釣り漁具、WPP、漁行の詳細はキャッチ KDE および FAO マッピングにフィードされます。座標がある場合は必ず含めてください。
二重入力は不要です。監査人が STELINA や MDPI に遡れるよう、元の ID を KDE の notes に参照してください。
BKIPM 衛生証明書のフィールドを GDST KDE にマッピングする方法
私たちは次のフィールドを直接抽出して使用することが多いです：
- 製品記述、HS コード、学名 → 種／製品 KDE
- 正味重量とパックタイプ → 数量と UoM
- 生産日とロット／バッチ → ロット ID と加工時の eventTime
- 輸出者／加工業者の承認番号 → 施設識別子
- 送り先、コンテナ、封印番号 → 物流を含める場合の出荷レベルの ObjectEvent（shipping bizStep）
興味深いのは、BKIPM 証明書がチェーン終端のための GDST 欄をどれだけカバーしているかという点です。積極的に利用してください。
承認を遅らせる一般的なミス
- WPP 718 に関する FAO 57/71 の混同。確信がなければ座標を含めるか、注記付きで両方を併記してください。
- いかなる書類にも現れない船舶 ID。撮影して保存できる許可証やコールサインを使用してください。
- 加工の途中でロットコードが変更される。トリミングで新しいロットが作られる場合は TransformationEvent で示してください。
- タイムゾーンの欠落。インドネシアの工場では常に eventTimeZoneOffset を設定してください。
この助言が適用される場合（および適用されない場合）
このアプローチはインドネシア沿岸艦隊、手釣りマグロ、礁魚、養殖バナメイに適しています。洋上でのトランスシップや遠洋艦隊を扱う場合は、キャリア船や RFMO レポーティングの追加 KDE が必要になる可能性があります。アイテムレベルのシリアライゼーションを伴う完全なチェーン・トゥ・リテールには、本ガイドを越えたラベル統合も必要です。
CSV 列の簡易レビューや、マグロまたはエビ向けに調整したコピペ可能な EPCIS テンプレートが必要であれば、メールでお問い合わせください。
最終的な要点
- 信頼できる書類から始めてください。WPP ログ、STELINA/MDPI 記録、BKIPM 証明書で GDST KDE の90%を埋められます。
- WPP を FAO にマップする際は、インド洋は 57、太平洋は 71 を使用し、WPP 718 には注意してください。
- トリム、剥き、分割、ブレンドには TransformationEvent を使用してください。現場で発生したならそれを示してください。
- 送信前に構造とビジネスルールを検証してください。ファイルが最初から綺麗だと買い手の対応は速くなります。
準備ができたら、GDST ペイロードは刺身グレードのマグロプログラムでも冷凍小売用フィレでも、あらゆる輸出ラインに添付可能です。製品例が必要な場合は、当社の現行ラインを参照して KDE が包装仕様にどのように整合しているかを確認してください。当社の製品一覧。