Input Type
Text、Large Text、Drop-Down Menuなど、回答内容に合う入力形式を選ぶ必要があります。
CASE STUDY 08 / PRODUCT CUSTOMIZATION / SHOPIFY
名入れ商品を、
社内で追加できる構造にする。
文字入力欄を商品ページへ置くだけでは、名入れ商品の運営環境は完成しません。商品ごとに異なる入力形式、選択肢、必須設定、表示対象、注文側の項目名を、次の商品でも再現できるルールへ変える方法を検討します。
- THEME
- Product Customization
- CASE EXAMINED
- 京都御所西 小川金正堂
- PLATFORM
- Shopify
- EVIDENCE STATUS
- Audited / Publication Ready
CENTRAL QUESTION
商品ごとに異なる名入れ条件を、社内で再現できるか。
一つの商品で入力欄が表示されれば完成なのか。それとも、どの項目を、どの商品へ、どの形式・必須条件で設定するかを社内で判断できる状態まで必要なのか。
CASE CONTEXT
商品によって、受け取る注文情報が異なった。
小川金正堂の名札、クリスタル、表彰楯、名入れギフトでは、会社名、役職、名前、名入れ文章、書体、ラッピングなど、商品ごとに購入者から受け取る情報が異なりました。
必要な回答には、1行・複数行の自由入力、候補からの選択、必須・任意があります。また、同じ項目を全商品へ表示するのではなく、商品タイプや対象商品に応じて、必要なオプションセットを紐付ける必要がありました。
2026年5月末には新たに2種類の名札が出品され、運用資料を受け取った後に社内担当者が練習としてShopifyへ登録する計画が共有されました。
ANALYSIS
入力欄ではなく、注文要件を設計する。
商品ページ上の表示だけを整えても、購入者の回答を運営側が注文情報として識別できなければ、名入れ注文は処理できません。
Requirement
注文に不可欠な回答と、希望者だけが指定する回答を必須・任意で分ける必要があります。
Assignment
商品タイプや対象商品を条件に、必要なオプションセットだけを表示する必要があります。
Order Label
商品ページの項目名と、カート・注文情報側の項目名を対応させる必要があります。
分析上の結論：名入れ機能の設計対象は、画面上の入力欄ではありません。「購入者へ何を尋ね、その回答をどの商品と注文へ結び付け、運営者がどう確認するか」という注文要件です。
DECISION FRAMEWORK
商品ごとの差を、再利用できるルールへ変える。
Decompose
名入れ条件を、項目名、入力形式、選択肢、必須設定へ分解する。
Group
共通する条件をオプションセットとしてまとめ、商品差を分ける。
Assign
商品タイプまたは対象商品を条件に、表示先を制御する。
Transfer
既存設定の確認・複製・変更・公開前確認を資料へ残す。
IMPLEMENTATION
CASEで構築した名入れ注文の設定環境。
商品別の回答項目を整理
名札、クリスタル、表彰楯、名入れギフトで必要となる文字入力、選択、書体、ラッピング等を整理しました。
Infinite Optionsへ構造化
項目名、入力形式、選択肢、必須設定、説明文をオプション項目として設定しました。
表示対象を商品条件で管理
商品タイプまたは対象商品に応じてオプションセットを紐付け、カテゴリー統合時には関連設定も調整しました。
二つの運用標準書を共有
Infinite Options運用標準書とShopify商品管理運用標準書を共有し、第2回作業として納品・承認されました。
追加2商品の登録練習へ接続
新たな2種類の名札を、社内運用担当者が資料を見ながら登録する予定として案内しました。
VERIFIED RESULTS
確認できた名入れ構造の結果。
CONFIRMED / B
複数の商品群にオプションセットが存在する
名札、クリスタル、表彰楯、名入れギフト等に対応する設定と、商品への紐付けが運用標準書に記録されています。
Evidence: Infinite Options運用標準書 / 設定記録
CONFIRMED / B
入力形式と項目名の管理基準が残された
Text、Large Text、Drop-Down Menu等の用途、必須設定、Label on ProductとLabel on Cartの扱いが資料化されました。
Evidence: Infinite Options運用標準書 Chapter 03〜05
CONFIRMED / A+B
設定変更が実商品へ反映された
商品カテゴリーの統合に伴い、コレクションだけでなくInfinite Options側の設定・紐付けも調整した記録があります。
Evidence: S-R2 / カテゴリー統合・設定調整記録
CONFIRMED / A
運用資料が納品・承認された
2026年6月8日、二つの運用標準書が共有され、クライアントから担当者へ共有して進める旨の回答と、正式納品の承諾が記録されました。
Evidence: S-R2 2026-06-08 15:16〜16:12
FINDINGS
名入れ商品を運営する企業への示唆。
アプリより先に要件を分解する
入力・選択・必須・表示対象・注文側名称を定義してから、設定へ変換します。
共通設定と例外を分ける
商品群で再利用できる項目と、個別商品だけに必要な項目を分離します。
変更の影響範囲を確認する
共有オプションセットを変更する前に、紐付く商品と表示への影響を把握します。
判断基準まで引き継ぐ
どの入力形式・既存設定・表示条件を選ぶかを、操作画面とともに残します。
LIMITS
このCASEが証明しないこと。
- Infinite Optionsの正式採用日時と、比較検討した全アプリの一覧は確定していません。
- Shopify標準機能では対応不可能だったと一般化しません。
- 全商品に対する必須・任意設定の完全な一覧は公開せず、全設定の無誤謬も証明しません。
- 追加2種類の名札は社内担当者が登録する予定まで確認でき、登録完了日時は未確認です。
- 購入者の入力内容が実際の受注で正しく処理された結果は、この記事では確認していません。
- 画像入稿、価格加算、製造工程、校正、すべてのオーダーメイド業務は研究対象外です。
- 運用標準書は社外秘のため、本文・画像・設定一覧の原本は公開しません。
EVIDENCE AUDIT
設定・資料・納品・実運用を分ける。
| 主張 | 品質区分 | 根拠・処理 |
|---|---|---|
| 名入れ項目・入力形式・表示条件 | 設定事実 | Infinite Options運用標準書、設定記録 |
| カテゴリー変更に伴う紐付け調整 | 実施事実 | S-R2、変更報告と設定記録 |
| 二つの運用標準書の共有・承認 | 成果物・納品事実 | S-R2 2026-06-08 |
| 追加2商品の社内登録 | 将来予定 | S-R2 2026-05-31〜06-08。完了結果には含めない |
| 名入れ条件を再利用可能なルールへ変える | 分析 | 要件、設定、紐付け、運用資料を統合した解釈 |
| 実注文での反映・処理成功 | 未確認 | 設定設計は確認済みだが、受注記録を公開根拠として照合していない |
公開範囲：名入れ要件の分解方法と運用設計を公開し、社外秘の標準書原本、設定一覧、商品固有の内部条件、認証情報、顧客・注文情報、非公開売上、管理画面情報は掲載しません。
公開許可：2026年2月16日の実績公開許可と、2026年6月10日のPROJECT全体公開許可を確認しています。
判定：本文の事実主張はEvidence Audited。設定・納品済み成果物と、未確認の実注文・社内登録完了を分離したPublication Ready版です。