Shopifyの納品書に注文メモや納品情報を載せる方法｜メール通知テンプレとは変数体系が違う

Shopifyで受注した内容を紙で現場に渡したい、という場面は意外と多くあります。ギフト系のECなら配送や設営の現場に、店舗の物販ECならバックヤードに、「この注文は何を・いつ・誰に届けるのか」が1枚で分かる紙が要る。そのときに使えるのが、注文管理画面から印刷できる「明細表」（英語圏の呼び名では packing slip、いわゆる納品書）です。

ただ、この明細表は初期状態だと商品名と数量くらいしか載っていません。注文フォームで受け取った日時指定や依頼者情報、管理画面のメモ欄に書いた内容を載せようとしてカスタマイズに手を付けると、多くの人が最初につまずくポイントがあります。

明細表のテンプレートは、注文確認メールなどの通知テンプレートとは編集場所も、使えるLiquid変数の体系も別物です。 メール通知のカスタマイズ経験がある人ほど、同じ書き方を持ち込んで「書いたのに何も表示されない」にはまりやすい。先にこの違いを押さえておけば、作業自体は難しくありません。

この記事では、実際のEC構築案件で明細表を「そのまま現場共有できる納品書」に作り替えた経験をもとに、編集場所・変数の違い・カスタマイズ手順・検証時の注意点をまとめます。

結論：編集場所は「設定 → 発送と配達 → 仕様表テンプレート」

明細表のテンプレートは、通知メールの一覧（設定 → 通知）の中にはありません。設定 → 発送と配達 と進んだ先にある「仕様表テンプレート」が編集場所です。ここに1枚のLiquidテンプレートがあり、印刷される明細表のHTML全体を直接編集できます。

そして、最初に知っておくと得をする仕様が2つあります。

• 注文メモ（管理画面のメモ欄）は、初期状態の明細表にすでに出ます。 {{ order.note }} が標準で組み込まれているためです。「電話で聞いた変更内容を現場に伝えたい」だけなら、メモ欄に書いて明細表を印刷するだけで足ります。テンプレートを触る必要すらありません
• お客様のメールアドレスも {{ order.email }} で出せます。 通知メールと違って印刷物には載らないだろうと思い込みがちですが、実際にテンプレートへ書いて確認したところ、問題なく出力されました

つまり「メモと連絡先を載せたい」程度なら数分で終わります。手間がかかるのは、注文フォームで受け取ったカスタム項目（配送希望日・時間帯・依頼者名など）を載せる場合です。ここから先はその話をします。

メール通知テンプレとの違い：明細のループ変数が別物

Shopifyの通知メール（注文確認メールやスタッフ向けの新規注文通知）をカスタマイズしたことがある人は、明細行のループに subtotal_line_items などの変数を使ったはずです。ところが、この書き方を明細表のテンプレートに持ち込んでも動きません。実案件で両方をカスタマイズして確認した差分がこちらです。

	通知メール	明細表（仕様表テンプレート）
編集場所	設定 → 通知 → お客様への通知	設定 → 発送と配達 → 仕様表テンプレート
明細のループ変数	subtotal_line_items ほか複数の系統に分かれる	line_items_in_shipment の1本だけ
セット商品（グループ商品）の扱い	別系統のループに落ちる	同じ1本のループに子アイテムも入る
注文メモ	標準では出ない	{{ order.note }} が標準で出る
プレビュー	サンプル注文で描画	実注文のデータでPDFが生成される

この中で実務に一番効くのが、明細のループが line_items_in_shipment の1本にまとまっていることです。

通知メール側は、通常商品・セット商品（オプション追加アプリなどが作るグループ商品）・配送区分のある商品がそれぞれ別のループで描画されるため、表示コードを差し込む場所を1か所間違えると、特定の商品タイプだけ何も表示されないという事態が起こりえます。エラーは出ません。静かに消えるだけです。通知メールに項目を足すときは、明細を描画しているループが何系統あるかを先に数え、すべてに同じ表示を入れるのが正しいやり方です。

一方、明細表は1本のループにセット商品の子アイテムまで入ってくるので、この分岐地獄がありません。表示コードを書く場所は1か所で済みます。 カスタマイズの難易度としては、明細表のほうが通知メールよりはるかに低いと言えます。

実例：問い合わせ対応を「メモ欄 → 印刷」で現場に流す運用

どんな場面で効くのか、実際に構築した例を挙げます。都内のギフト系ECで、受注ごとに配送・設営の現場スタッフと運営側が情報を共有する必要がありました。運用はこう組みました。

1. お客様からフォームやメールで届いた変更依頼（「お届けを18時以降にしてほしい」など）を、担当者が注文管理画面のメモ欄にそのまま貼る
2. 注文詳細の「その他の操作」から明細表を印刷する
3. その紙を関係者に渡す。全員が同じ1枚を見る

このために明細表側へ載せたのは、次の情報です。

• 配送希望日を、ひと目で分かる大枠で強調表示（注文データには 08-31-2026 のような月-日-年形式で入っていたため、Liquidで分解して「2026年8月31日」に整形）
• お客様のメールアドレス（問い合わせへの返信用）
• 商品ごとのカスタム項目すべて（希望時間帯・依頼者名・フリガナ・電話番号など）

ポイントは、注文確認メールに出る情報と同じものを明細表にも出すことをゴールにした点です。メールを見た人と紙を見た人で持っている情報が違うと、確認の往復が発生します。「この紙1枚に全部ある」状態を作ると、現場は紙だけ見ればよくなります。

カスタマイズ手順と、コードに入れておくべき安全策

実際の手順です。前提として、注文フォームのカスタム項目はLiquid上では各明細行の properties（プロパティ）として取れます。

1. 現行テンプレートを丸ごとバックアップする

編集を始める前に、テンプレート全文をコピーしてローカルにファイルとして保存します。仕様表テンプレートは1枚しかなく、壊すと印刷業務が止まります。戻せる状態を作ってから触るのが原則です。

2. 挿入位置を決める

おすすめは宛先・請求先ブロックの直後、商品明細の表の前です。印刷したときに「誰宛の・いつの注文か」→「何の商品か」の順で読めるので、現場が上から順に読むだけで済みます。

3. 表示ロジックに4つの安全策を入れる

プロパティをそのまま全部並べると、印刷物として使いものになりません。実案件では次の4つを入れました。

• アンダースコア始まりのプロパティ名は、表示時にアンダースコアを外す。 フォーム系アプリは項目名の先頭に _ を付けて保存することが多く（_配送希望日 など）、そのまま出すと不格好です
• アンダースコア2つ始まりのプロパティは表示から除外する。 アプリが内部管理用に持たせるデータで、お客様にも現場にも意味がありません
• 値が空のプロパティはスキップする。 任意入力の項目は空で届くことが多く、空欄の行が並ぶと肝心の情報が埋もれます
• 表示すべき項目がゼロなら、ブロックごと非表示にする。 カスタム項目のない注文で「納品情報」という空の枠だけが印刷されるのを防ぎます

この4つはどれも、入れ忘れても最初のテスト注文では気づきにくいものです。運用が始まって多様な注文が流れ込んでから「変な行が印刷される」と発覚するので、最初から入れておくことをおすすめします。

検証の注意：プレビューは「最古の注文」で描画されることがある

仕様表テンプレートにはプレビュー機能があり、実注文のデータでPDFが生成されます。サンプルデータではなく実データで確認できるのは便利なのですが、ここに1つ、知らないと誤診する挙動があります。

プレビューに使われる注文が、ストアの最も古い注文で固定されていることがあります。 何が問題かというと、注文フォームは運用の中で項目名が変わっていくからです。たとえば現行フォームの項目名が「配送希望日」でも、1年前の注文では「お届け日時」という別の名前で保存されていたりします。現行の項目名を前提に表示を組むと、古い注文をもとにしたプレビューには何も出ません。

ここで「コードが間違っている」と判断してしまうと、正しいコードを延々と直し続けることになります。プレビューに出ない＝壊れている、ではありません。 プレビューがどの注文を描画しているかをまず確認し、最終確認は現行フォーマットの実注文で明細表を出力して行う。この順番にしておくと、無駄な手戻りを防げます。

なお、通知メール側のプレビューも同様に、カスタム項目が空のサンプル注文で描画されて「何も出ない」ように見えることがあります。テンプレート系の検証は「プレビューで大枠確認、実注文で最終確認」の二段構えが安全です。

まとめ：どこまで自分でやるかの判断基準

• 注文メモを現場に渡したいだけなら、テンプレート編集は不要。メモ欄に書いて明細表を印刷すれば標準で出る
• カスタム項目（配送希望日・依頼者情報など）を載せるなら仕様表テンプレートの編集が必要。ループは line_items_in_shipment の1本で、通知メールより構造が単純なので、Liquidに触れたことがあれば十分自作できる範囲
• 通知メール側にも同じ情報を出したい場合は難易度が一段上がる。明細のループが複数系統に分かれており、1か所への挿入では商品タイプによって表示が抜ける。ここは経験者に任せる判断もあり
• どちらを触る場合も、バックアップを取ってから編集し、最終確認は実注文で行う

「注文情報を紙1枚に集約して現場に渡す」仕組みは、地味ですが確認の往復を確実に減らします。外部ツールを足さなくても、Shopifyの標準機能とテンプレート編集だけで作れる範囲なので、受注後の伝達に手間を感じているストアは一度検討してみてください。