この記事の対象: ShopifyでのEC構築・リニューアルを検討している事業者、既存ストアにギフト機能を追加したい担当者
読了時間: 約15分
ギフト対応は、要件を聞き取る段階では「ラッピングとメッセージカードを付けられるようにしたい」という一行で終わります。ところが実装に入ると、途端に決めることが増えます。有料か無料か、商品ごとに包み方が違うのか、複数商品を1つの箱にまとめるのか、のし紙の表書きは何種類あるのか、名入れはどこまで受けるのか。
そして最後に必ず出てくるのが「その情報、出荷のときに誰がどこで見るんですか」という問いです。ここを詰めずにリリースしたストアは、注文が増えたタイミングで詰まります。
この記事では、Shopifyでギフト・ラッピング・のしを設定する方法を3つの方式に整理し、それぞれがどこまで耐えるのか、どの条件を超えたら次の方式に切り替えるべきかを、実装と運用の両面から書きます。アプリ名の羅列ではなく、自分のストアの条件に当てはめて判断できる状態にすることが目的です。
Shopifyのギフト設定は「3つの受け方」に分かれる
Shopifyでギフト情報を受け取る方法は、突き詰めると3つしかありません。どのアプリを使っても、どんなカスタマイズをしても、この3つのどれか、あるいは組み合わせになります。
A. 商品オプションで受ける
- バリエーション（バリアント）に持たせる
- Line Item Property で持たせる
B. 追加商品として売る
- ラッピング資材を独立した商品にする
- カートに一緒に入れてもらう
C. カート属性で受ける
- 注文全体に1つだけ付く情報として持つ
- カートページ／チェックアウト直前で入力
Aは商品1点ごと、Cは注文1件ごとに情報が付く。この違いが後の運用を決める。
この3つは「どれが優れているか」ではなく、情報の粒度が違うという話です。1つの注文で複数の商品をそれぞれ別包装・別のし・別カードで送るなら、注文単位でしか持てないCでは足りません。逆に「この注文はぜんぶまとめて1つの箱に入れて、のしは1枚」なら、商品ごとに持たせるAは冗長になり、しかも矛盾した入力（1つの注文の中でのしの種類がバラバラ）を許してしまいます。
要件定義の最初にやるべきは、アプリを探すことではなく、この注文が「商品ごと」なのか「注文ごと」なのかを決めることです。ここが決まれば選択肢は自動的に絞れます。
3方式の比較
| 観点 | A. 商品オプション | B. 追加商品 | C. カート属性 |
|---|---|---|---|
| 情報の粒度 | 商品1点ごと | 商品として1点ごと | 注文全体で1つ |
| 課金 | オプション単体では課金できない | 商品なので普通に課金できる | 課金できない |
| 在庫管理 | バリアント方式なら可 | できる（資材の在庫を持てる） | できない |
| 管理画面での見え方 | 注文明細の各行の下に出る | 明細に1行として並ぶ | 注文詳細の「追加情報」欄 |
| 出荷伝票（ピッキングリスト）への反映 | アプリ・設定次第 | 商品なので確実に出る | 落ちやすい |
| 実装難易度 | 中（テーマ改修が要る） | 低 | 低〜中 |
| 向くケース | 商品ごとに包装を変える | 有料ラッピング・資材の在庫を持つ | 注文まるごと1つのギフト |
課金の欄に注目してください。Line Item Property（商品オプション）だけでは金額を上乗せできません。 ここはShopifyでギフト対応を組むときの最初のつまずきどころで、「ラッピングを有料オプションにしたい」のに、オプション欄を付けただけでは価格が変わらない、という事故が起きます。
有料にするなら、方法は3つに限られます。
- 有料ラッピングを商品として売る（方式B）
- バリアントに価格差を持たせる（「本体のみ」と「ギフト包装付き」で価格を分ける）
- Shopify Functions で加算する（開発の手が要る。対応プランと機能範囲は着手前に公式ドキュメントで確認）
一番堅いのは1です。理由は課金だけでなく、在庫と原価が乗るから。ラッピング資材は現物です。箱もリボンも熨斗紙も消耗品で、切れます。商品として持っていれば在庫が減り、切れれば売り止まる。オプションで受けていると、資材が尽きているのに注文だけ入り続けます。
方式A：商品オプションで受ける
バリアントで持つか、Line Item Property で持つか
同じ「商品オプション」でも、この2つは中身がまったく違います。
バリアント（商品バリエーション）
- 在庫・価格・SKUを別々に持てる
- 選択肢の数だけ組み合わせが増える
- 自由入力（名入れ・メッセージ）はできない
- 商品ページのURLに反映され、広告にも使える
Line Item Property
- 自由入力ができる（メッセージ本文など）
- 在庫も価格も持てない
- 組み合わせが増えても商品は増えない
- テーマ側にフォームを足す改修が要る
判断は単純です。在庫と価格を持たせたいならバリアント、自由入力が要るなら Line Item Property。 両方要るなら両方使います。
ただしバリアントには上限があります。1商品あたりのバリアント数、そしてオプション（選択軸）の本数に制限があるため、「サイズ×色×ラッピング有無×のし種類」のように軸を増やしていくと、あっという間に壁に当たります。ラッピング関連をバリアント軸に入れるのは、商品側の軸が少ないときだけにしてください。ここは要件定義の段階で数えられます。商品の軸が2本すでにあるなら、ラッピングは別の方式で受けるべきです。
具体的な上限値はShopify側の仕様変更で動くため、着手前に必ず現行の管理画面か公式ドキュメントで確認してください。数え方は単純で、「軸の選択肢の数を全部かけ算した数」が上限に収まるかを見るだけです。サイズ4種×色5種で20、そこにラッピング3種を足すと60。この掛け算を要件定義の紙の上でやっておけば、実装に入ってから作り直す事態は避けられます。
Line Item Property の実装で見落とされること
Line Item Property は、商品ページのフォームに properties[名前] という name 属性の入力欄を足すだけで動きます。仕組みとしては拍子抜けするほど簡単です。問題はその周辺にあります。
アンダースコアで始まるプロパティ名は、顧客側に表示されません。 _internal_code のような名前にすると、注文管理画面には出るが、注文確認メールやサンキューページには出ない。内部用のフラグを持たせるときに使いますが、逆に言うと普通の名前で作ったものは全部お客様に見えるということです。「ギフト対応の内部区分コード」をうっかり普通の名前で持たせると、注文確認メールにコードがそのまま出ます。
カートの重複マージ判定にも影響します。 Shopifyは同じバリアントを2回カートに入れると数量を+1しますが、Line Item Property の中身が違えば別の行として並びます。名入れやメッセージを受けるならこれが正しい挙動ですが、「ラッピング希望：はい」だけを持たせている場合、意図せず行が分かれることがあります。テストするなら、同じ商品を条件を変えて2回入れてみてください。
空欄の扱いに注意。 何も入力されなかったプロパティが空文字で送られると、注文明細に空っぽの項目名だけが並びます。見た目が悪いだけでなく、出荷担当が「入力があるのか無いのか」を判断できません。空なら送らない処理を入れるか、_付きの名前にして表に出さないかのどちらかです。
項目名がそのまま帳票に出ます。 プロパティ名は開発者が決めますが、それが注文管理画面と注文確認メールにそのまま表示されます。gift_message のような英語の内部名で作ると、お客様向けのメールに英語のラベルが並びます。表に出す項目は日本語で、内部用は _ 付きの英語で、と最初に分けておくのが安全です。
文字数と改行
メッセージカードで最も揉めるのがここです。カードの実物には物理的な入稿面積があります。1行何文字、何行まで。ここを決めずにフリーテキストで受けると、カードに収まらない長文が送られてきて、出荷が止まります。
やるべきことは3つ。
maxlengthを入れる（実物の面積から逆算した値）- 改行を許すなら
textarea、許さないならinput（改行が入ると印字テンプレートが崩れる） - 絵文字・機種依存文字をどうするか決めておく（印字できないフォントなら弾く。弾かないなら「印字できない文字は削除して印刷します」と明記する）
maxlength はブラウザ側の制限なので、開発者ツールから外せます。悪意がなくても、コピペで貼り付けたときに超過分がどうなるかはブラウザによって挙動が違います。受け取る側（管理画面を見る人）が超過に気づける形にしておくのが現実解です。入力欄のそばに残り文字数のカウンタを出しておくと、そもそも超過が起きにくくなります。
方式B：ラッピングを商品として売る
一番地味で、一番よく働くのがこれです。
「ギフトボックス（Mサイズ）」「のし紙（御中元）」といった商品を作り、カートに追加してもらう。それだけです。実装コストは低く、Shopifyの標準機能の上に素直に乗ります。
この方式の強さ
- 課金がそのまま通る（税区分も送料計算も標準の仕組みに乗る）
- 在庫が持てる（資材が切れたら売り止まる）
- 売上として集計できる（ギフト対応がどれだけ使われているかがそのまま分析画面に出る）
- 出荷伝票に確実に出る（商品として明細に並ぶので、落ちない）
- アプリを解約しても消えない（後述しますが、これが効きます）
最後の点は軽視されがちですが、大きな差になります。アプリで実装したギフトオプションは、アプリを止めた瞬間に入力欄が消え、過去の注文データの表示も崩れることがあります。商品として売っていれば、それはただの注文履歴なので、何が起きても残ります。
この方式の弱さ
弱点も明確です。
商品一覧に出てしまう。 「ギフトボックス」がコレクションページや検索結果に単体で並ぶのは、多くの場合望ましくありません。コレクションから外す、検索から外す、といった調整が必要です。Shopifyの商品はデフォルトでオンラインストアに公開されるので、公開設定と sitemap からの除外まで含めて扱いを決めてください。
「どの商品に対する包装なのか」が紐づかない。 3点買って2点だけギフトにしたいとき、商品として並べただけでは対応関係が分かりません。この場合は方式Aと組み合わせて、「どの商品を包むか」をLine Item Property で持つか、そもそも「1注文＝1ギフト」に運用を寄せるかの判断になります。
買い忘れる。 商品ページに「ギフトボックスはこちら」というリンクを置いても、そこを踏まないお客様は普通に買っていきます。カートページに「ラッピングを追加しますか」の導線を出す改修は、結局必要になります。ここは方式Bを選んでもテーマ改修が発生する箇所です。
最後の「数量の整合」がやっかいです。商品を3点にしたのにラッピングが1点のまま、あるいはその逆。ここを放置すると出荷側が毎回問い合わせることになります。Cart Ajax API でカート更新時に数量を追随させる実装を入れるか、「ラッピングは注文1件につき1点」と割り切るかを決めておきます。
もう1つ、ラッピング商品だけがカートに残る状態への備えが要ります。本体商品を削除してもラッピング商品はカートに残るため、ラッピングだけを購入できてしまいます。カート更新時に本体がゼロなら関連するラッピング商品も外す処理を入れるか、最低注文金額の設定で弾くか、決めておいてください。
方式C：カート属性で受ける
カート属性（Cart Attributes）は、注文全体に1セットだけ付く情報です。カートページに attributes[のし表書き] のような入力欄を置くと、注文詳細の「追加情報」欄に入ります。
実装は簡単で、テーマのカートテンプレートに数行足すだけ。アプリも要りません。
向いているケース
- 注文まるごとが1つのギフト（結婚内祝い、お中元の1件送り）
- 「配達日時の希望」「贈り主の名義」など、注文単位でしか意味を持たない情報
- ギフト利用が全体の一部で、専用アプリを入れるほどではない段階
落ちやすいポイント
出荷伝票に出ない。 ここが最大の弱点です。Shopify標準の注文印刷や、外部の配送管理システム・WMSとの連携では、カート属性が拾われないことがよくあります。注文管理画面を開けば見えるのに、印刷したピッキングリストには出ない。現場は紙を見て動くので、これに気づかないまま「のしなし」で出荷される事故が起きます。
確認するのはリリース前の1回で済みます。 テスト注文を1件通して、実際に現場が使う帳票を印刷してみてください。出ていなければ、印刷テンプレート側で拾う設定を足すか、方式Bに切り替えるかの判断になります。この検証を飛ばしたまま公開されたストアを直す仕事は、Shopify案件でそれなりの頻度で発生します。
チェックアウト画面では変更できない。 カート属性はカートページで入力する前提です。お客様がチェックアウトまで進んでから「やっぱりのしを付けたい」と思っても、戻る導線がなければ入力できません。カートページを経由しない購入導線（商品ページから直接チェックアウトへ飛ぶボタン、SNS経由の動的チェックアウト）を使っているストアでは、そもそも入力機会が生まれません。
動的チェックアウトボタン（ショップペイやGoogle Payのボタン）を出している場合、ギフト入力は丸ごとスキップされます。 ギフト対応を主軸に据えるストアなら、これらのボタンを出すかどうか自体を再検討する必要があります。表示・非表示はテーマの設定で切り替えられるので、ギフト注文の比率が高いストアでは、購入速度と入力機会のどちらを取るかを先に決めてください。
入力必須にできない。 カート属性はテーマ側のフォームなので、required を付けてもカートページを経由しないルートには効きません。「のしの用途を必ず選ばせたい」といった要件があるなら、カート属性ではなく、方式Bのバリアント選択や商品購入という形で購入経路そのものに組み込むほうが確実です。
のし（熨斗）は、ラッピングとは別問題として扱う
海外製アプリで「ギフトラッピング」を謳っているものの多くは、のしを想定していません。ここは日本のEC特有の要件で、構造が違います。
のしに必要な情報は最低3つ。
| 項目 | 内容 | 入力形式 |
|---|---|---|
| 表書き | 御祝、内祝、御中元、御歳暮、御礼、粗品など | 選択式（用途で決まる） |
| 水引 | 蝶結び／結び切り、色（紅白・黒白など）、本数 | 表書きから自動決定できることが多い |
| 名入れ | 贈り主の名前。連名・会社名・肩書き | 自由入力（文字数制限が要る） |
表書きと水引は連動します。 婚礼関係は結び切り、一般のお祝いは蝶結び。ここを別々の選択肢として並べると、お客様が誤った組み合わせを選びます。「結婚内祝い」と「蝶結び」が同時に選ばれた注文を、出荷担当が毎回目視で直すことになる。
正しい作り方は、用途を1つ選ばせて、水引と表書きは裏で決めることです。
最後のプレビューが効きます。のしは多くのお客様にとって「よく分からないまま選ぶもの」なので、選択結果が絵で見えるだけで問い合わせが減ります。実装としては、用途ごとにのし紙の画像を用意して、選択に応じて差し替えるだけです。難しい処理ではありませんが、汎用のギフトアプリではまず提供されていない部分です。
さらに、内のし／外のしの区別があります。包装紙の内側にのしを掛けるか、外側に掛けるか。これは商品ではなく配送の都合（宅配便で送るなら内のし、手渡しなら外のし、など地域や慣習で変わる）で決まるため、選択肢として出すか、店側で一律に決めるかを事前に決めておきます。出すなら説明文が要ります。
名入れの入力で決めておく3つのこと
名入れは自由入力なので、ここが一番荒れます。要件定義で決めておくのは次の3点です。
連名を何名まで受けるか。 のし紙の面積は決まっているので、3名を超えると文字が小さくなりすぎます。「連名は3名まで、それ以上は『◯◯家』でお願いします」と入力欄の説明に書いておく。入力欄を名前ごとに分ける（第1連名・第2連名）と、出荷側で並び順に迷いません。
旧字体・外字をどうするか。 「髙」「﨑」「𠮷」といった文字は、印字システムのフォントによって出ないことがあります。出ない文字が来たときの扱い（代替字で印字するか、店から確認の連絡を入れるか）を先に決めて、注記に書いておいてください。
空欄を許すか。 名入れなしのケースは実際にあります（贈り主を伏せる、店名で出す）。空欄を許すなら、出荷側に「名入れなし」と明示的に伝わる形にしてください。空文字のまま渡すと、出荷担当は「入力漏れなのか、名入れ不要なのか」が判断できず、毎回確認の連絡が入ります。
どこまでアプリで足りて、どこからテーマ改修が要るか
ここが一番聞かれる部分です。線引きは、「その要件が入力欄の問題か、印字と紐付けの問題か」で分かれます。
アプリで足りる条件
次の全部に当てはまるなら、汎用のギフトアプリで十分機能します。
- ラッピングの種類が少ない（3〜5種類まで）
- 有料でも一律料金、あるいは商品として売る形で済む
- のしが不要、または表書きが数種類で固定
- 1注文に1セットのギフト設定でよい
- 出荷は自社または少人数で、管理画面を直接見られる
この条件なら、アプリを入れて設定するだけで動きます。制作会社に頼む必要すらないケースもあります。 隠すことではないので書きますが、要件がこの範囲に収まっているなら、まずアプリを試してから足りない部分だけ相談するのが合理的です。
テーマ改修が要る条件
逆に、次のどれかに当たったら、アプリだけでは高い確率で行き詰まります。
- 商品ごとに包装の可否が違う（生鮮品は不可、大型商品は不可、など）
- のしの用途分岐がある（表書きと水引の連動、内のし／外のし）
- プレビューを見せたい（選択結果を画像で表示）
- 配送先ごとに別のギフト設定（1注文で複数箇所へ送る）
- 外部の配送システムやWMSに情報を渡す（データの形式が指定されている）
- カートの数量とラッピングの数量を連動させたい
- 自社のテーマがすでに深くカスタマイズされている（アプリが差し込む場所を確保できない）
最後の項目は見落とされます。Dawnをベースに大きく手を入れているテーマでは、アプリが自動で埋め込もうとする位置が存在しなかったり、既存のカスタムJSと衝突したりします。アプリの自動埋め込みが効かず、結局テーマにコードを手で足すことになるなら、それはもうテーマ改修です。
テーマ改修の進め方そのものについては、アップデートへの耐性を軸にまとめた記事があります。ギフト対応はカートページと商品ページの両方に手を入れる改修なので、テーマ更新のたびに壊れない形を先に決めておくべき領域です。
自前で作るか、アプリに任せるかの分岐点
自社でもDawnベースのストアを運用している立場から言うと、判断の軸は「機能があるか」ではなく「それを何年間、誰が面倒を見るか」です。
アプリは、そのアプリの開発元が保守し続けてくれる限りにおいて楽です。Shopify側の仕様変更（チェックアウト周りやテーマの構造は定期的に変わります）に追随してくれるなら、月額は保険料として妥当です。逆に、開発元が更新を止めたアプリは、ある日突然、動かなくなります。しかもその日は自分で選べません。
自前実装は、Shopifyの仕様変更が来たときに自分で直す必要がありますが、中身が全部見えているぶん、直せます。ウィッシュリストのように、アプリを入れずに実装できる機能もあります。
ギフト対応でいえば、カート属性とLine Item Property を使う範囲は自前で書けるというのが実感です。この2つはShopifyの根幹に近い仕組みで、そう簡単には無くなりません。逆に、チェックアウト画面の中に何かを差し込む要件（チェックアウト拡張が必要な領域）は、アプリか専門の開発に任せたほうが安全です。
アプリを選ぶときに実際に見るべき箇所
具体的なアプリ名を挙げて評価することはしません。使ったことのないアプリの使用感を書くのは不誠実ですし、機能も料金も変わります。代わりに、アプリの一覧ページで自分で確認できる箇所を挙げます。
| 見る場所 | 何が分かるか | 危険信号 |
|---|---|---|
| 最終更新日 | 開発が続いているか | 長期間更新が止まっている |
| レビューの最新の日付 | 今も使われているか | 最新レビューが数年前 |
| 対応言語 | 管理画面と顧客側の日本語対応 | 顧客側の文言が固定で英語のまま |
| サポートの応答 | 問題が起きたときに届くか | 問い合わせ窓口が明記されていない |
| 対応テーマの記載 | 自分のテーマで動くか | 「Online Store 2.0対応」の記載がない |
| 権限（インストール時） | 何を読み書きするか | 必要以上に広い権限を要求 |
| 低評価レビューの中身 | どこで詰まるか | 「解約後もコードが残る」系の記述 |
低評価レビューは必ず読んでください。 高評価のレビューは「便利です」で終わることが多く、情報量がありません。低評価に書かれている内容が、そのアプリで実際に起きる問題です。日本語のレビューが少なければ、英語のレビューも読む価値があります。
料金体系は無料枠があるものから月額課金のものまで幅があり、プラン改定も予告なく行われます。金額は必ず各アプリのページで最新の情報を確認してください。
もう1つ、インストール前に試せる範囲を確認しておくと失敗が減ります。無料期間があるなら、その期間内に「テスト注文を1件通して帳票まで出す」ところまでやってください。入力欄が出るところまでで満足して本番に入ると、帳票に出ないことに後で気づきます。
月額が積み上がる話
アプリ1つの月額は大きく見えません。問題は、ギフト対応だけでは終わらないことです。
Shopifyストアを運用していると、レビュー、定期購入、ポイント、配送日時指定、フォーム、SEO、翻訳、と用途ごとにアプリが増えます。1つ1つは小さくても、年間で見ると保守費用の相当部分をアプリの月額が占めるようになります。しかもこれは、機能を使っていなくても止めない限り発生し続けます。
判断の目安はシンプルで、「そのアプリの年額 × 3年」が、同じ機能を自前で作る費用を超えるかです。超えるなら、作ったほうが安く、しかも中身が自分のものになります。超えないなら、アプリで正解です。自前で作る側の費用は、要件の複雑さ（のしの分岐があるか、外部連携があるか、プレビューが要るか）で大きく変わるので、この比較は要件を確定させてから見積もりを取って行ってください。
サイト全体の維持費という文脈では、こちらの記事で項目別に分解しています。ギフト対応のアプリ月額も、この積み上げの中の一項目として扱うのが正しい見方です。
解約したときに何が残るか
契約前に必ず確認すべきなのがこれです。アプリを解約したときに起きうることは3つあります。
- テーマにコードの残骸が残る（アプリブロックではなく直接埋め込みだった場合）
- メタフィールドにデータだけ残る（アプリが読み書きしていたデータの所有権はストア側にあるが、読める形式とは限らない）
- 過去の注文の表示が崩れる（アプリ側で描画していた情報が見えなくなる）
Online Store 2.0 のアプリブロック形式で提供されているアプリは、テーマから外せば綺麗に消えます。逆に「テーマファイルに直接コードを追加します」というインストール手順のアプリは、解約後に手で消す作業が発生します。インストール手順を読めば、解約時に何が起きるかは事前に分かります。
乗り換えを考えるなら、過去の注文に付いたギフト情報をCSVで書き出せるかも先に確認しておいてください。Line Item Property とカート属性は注文データの一部なのでCSVに出ますが、アプリが独自のデータベース側に持っている情報は、解約すると取り出せなくなることがあります。
出荷の現場で誰がどこを見るか
ここまで書いた実装の話は、この一点に収束します。入力された情報を、出荷担当が見られる場所に、確実に届けること。
情報が届く経路を全部数える
Shopifyの注文情報は、次の経路のどこかで現場に届きます。
| 経路 | Line Item Property | カート属性 | 商品（方式B） |
|---|---|---|---|
| 注文管理画面 | 出る | 出る（追加情報欄） | 出る |
| 注文の印刷（納品書） | テンプレート次第 | テンプレート次第 | 出る |
| ピッキングリストアプリ | 対応状況次第 | 落ちやすい | 出る |
| 外部のWMS・配送システム | 連携仕様次第 | 落ちやすい | 出る |
| CSVエクスポート | 出る | 出る | 出る |
| 注文確認メール（顧客向け） | 出る（_なしなら） |
出ない場合が多い | 出る |
方式Bの列が全部「出る」になっているのが、この方式を推す最大の理由です。商品は、Shopifyのあらゆる出口で商品として扱われます。
リリース前に必ず通すテスト
要件が固まったら、公開前に次の順で1件通してください。テスト注文1件で全部確認できます。
3番目の「帳票を印刷」を飛ばしてはいけません。画面で見えることと、紙に出ることは別です。現場は紙を見て動きます。
テストは1件では足りない場合があります。ギフト情報を入れた注文と、入れなかった注文の2件を通してください。 空欄のときに帳票がどう出るか（空の項目名だけが並ぶ、あるいは行が詰まって見分けがつかない）は、入れた注文だけでは分かりません。複数商品でそれぞれ別の設定を入れる要件なら、その組み合わせも1件通します。
管理画面を触る人の負担
最後に、設定を維持する人の話をします。
季節ギフトは、時期によって表書きが変わります。御中元は夏、御歳暮は冬。期間が過ぎたら選択肢から外さなければ、季節外れの表書きで注文が入ります。この切り替えを誰が、どこの画面で、いつやるのかを決めておかないと、毎年同じ問い合わせが発生します。
理想は、テーマエディタから、コードを触らずに選択肢を編集できる形にしておくことです。Shopifyのセクション設定として持たせておけば、担当者がテーマエディタで文言を書き換えられます。実装時にひと手間かかりますが、運用に入ってからの差は大きい。ここを「後で足せばいい」と後回しにすると、結局、毎年制作会社に連絡が来ることになります。
あわせて、その手順を1枚の紙に残してください。 「御中元の選択肢を出す／隠す」だけの操作でも、1年経つと担当者は忘れます。テーマエディタのどのセクションを開いて、どの項目を切り替えるか。スクリーンショット付きで残しておけば、担当者が変わっても回ります。これは実装ではなく引き継ぎの話ですが、ギフト対応で毎年発生する問い合わせの大半はここが原因です。
Shopifyをコーポレートサイトと兼用している場合、この観点はさらに重要になります。ECの担当者と、会社情報を更新する担当者が別人になるからです。誰がどの画面を触るかの整理は、Shopifyをコーポレートサイトと兼用する考え方の記事でも触れている論点で、ギフト設定も同じ枠で考えると破綻しにくくなります。
表示速度への影響
ギフト関連のアプリは、商品ページとカートページにJavaScriptを追加します。1つなら誤差ですが、複数のアプリが同じページに乗ると、体感できるレベルで重くなります。
商品ページとカートページは、購入直前の最も落としたくない場所です。ギフト対応を追加した後は、必ず速度を計測し直してください。導入前後を比較すれば、そのアプリがどれだけ重いかがはっきり分かります。重すぎるなら、機能を削るか、自前実装に切り替えるかの判断材料になります。
計測は導入前に1回、導入後に1回、同じ条件で取ってください。同じページ・同じ回線・同じ時間帯で比べないと、アプリの重さかネットワークのゆらぎか区別がつきません。のしのプレビュー画像を入れる場合は、画像の重さも一緒に効いてくるので、遅延読み込みの設定まで含めて見ます。
よくある質問
Shopifyの標準機能だけでラッピングやのしに対応できますか
できます。カート属性やLine Item Propertyはテーマに数行足せば動くため、要件が「注文1件につきラッピングの有無とメッセージを受け取る」程度なら、アプリなしで実装可能です。ただし有料オプションにする場合は、ラッピングを商品として登録して課金する形にするのが確実です。標準機能だけで難しいのは、のしの用途分岐やプレビュー表示、配送先ごとの個別設定といった領域です。
ラッピング料金を有料にするにはどうすればいいですか
Line Item Property（商品オプション）だけでは価格を変えられないため、方法は3つです。ラッピングを独立した商品として販売する、商品のバリアントに価格差を持たせる、Shopify Functionsで加算処理を書く。運用のしやすさで選ぶなら商品として売る方式が有利で、資材の在庫管理と売上集計がそのまま標準機能に乗ります。
ギフトアプリは何を基準に選べばいいですか
機能一覧よりも、最終更新日・最新レビューの日付・低評価レビューの中身・対応言語・インストール方法の5つを見てください。特に低評価レビューには実際に詰まる箇所が書かれています。インストール手順が「テーマファイルに直接コードを追加」となっているものは、解約後に残骸を手で消す作業が発生します。料金は変動するため、必ず各アプリのページで最新の情報を確認してください。
のし対応は海外製のギフトアプリでできますか
多くの海外製アプリはのしを想定していません。表書きと水引の連動、内のし／外のしの区別、名入れの文字数制限といった日本固有の要件は、汎用のラッピング機能では表現できないことがほとんどです。のしを本格的に扱うなら、日本のEC事情に対応したアプリを探すか、テーマ改修で作り込む前提で見積もってください。
出荷の現場にギフト情報が届かない事故はどう防げますか
リリース前にテスト注文を1件通し、現場が実際に使う帳票を印刷して確認するのが最も確実です。管理画面で見えていても、納品書やピッキングリスト、外部の配送システムには反映されないことがあります。特にカート属性は連携先で落ちやすいため、必ず印刷物と外部システムの両方で目視してください。ギフト情報を入れた注文と入れなかった注文の2件を通すと、空欄時の見え方まで確認できます。
まとめ
Shopifyのギフト・ラッピング・のしの設定は、アプリを探す前に決めるべきことが3つあります。
- 情報の粒度：商品ごとか、注文ごとか。ここで方式が決まる
- 課金の有無：有料にするなら、商品として売るのが最も堅い
- 出荷での見え方：現場が使う帳票に確実に出るか
そのうえで、次の判断をします。
| 状況 | 選ぶべき方式 |
|---|---|
| 注文まるごと1つのギフト、無料対応 | C（カート属性）＋自前実装 |
| 有料ラッピング、資材の在庫を持つ | B（商品として販売） |
| 商品ごとに包装・のしを変える | A（Line Item Property）＋テーマ改修 |
| のしの用途分岐・プレビューが要る | テーマ改修が前提。アプリだけでは届かない |
| 要件が軽く、まず試したい | 汎用アプリを入れて、足りない部分を後で判断 |
アプリで足りるならアプリで構いません。制作会社に頼まなくても解決する範囲は確実にあり、そこを無理に工事にする理由はありません。
判断が必要になるのは、「アプリの自動埋め込みが自分のテーマで効かない」「のしの分岐が要る」「外部システムに情報を渡す必要がある」のいずれかに当たったときです。この3つのどれかに当たっているなら、その時点でテーマ改修を含めた設計の話になります。
ギフト対応は、作った瞬間より、2年目以降のほうが差が出る領域です。季節ごとの選択肢の入れ替え、資材の切り替え、アプリの月額、そして解約時に残るもの。実装方式を選ぶときは、その先の運用まで含めて数えてください。
