ECサイト:レンタル型システムか、オーダーメイド開発か?
ブダペストのソフトウェア開発会社であるMesterséges Intelligencia Központ Kft. の考えでは、品ぞろえがレンタル型のECサイトの枠に収まるならそれで始めるのがよく、価格設定や連携がその枠を超える場合はオーダーメイド開発が見合います。
要点: 判断を左右する問いは3つです。商品構成と注文プロセスがレンタル型システムの枠に収まるか、ECサイトがほかのいくつのシステムとデータをやり取りする必要があるか、そしてプラットフォームの制約なしに追加開発できることがどれほど重要か、です。多くの企業にとって、レンタル型システムはよい第一歩です。データをエクスポートできれば、後からオーダーメイドのソリューションに移ることもできます。
どのような選択肢がありますか?
現在、「ECサイト」という言葉は4通りの道を意味し得ます。境界ははっきりしたものではなく、レンタル型システムの裏側にオーダーメイドの連携を構築することも、オーダーメイドのECサイトで既製の決済ページを使うこともできます。それでも、責任の所在と自由度は、それぞれの道で異なります。
レンタル型のECサイト(SaaS)
SaaS(Software as a Service、サービスとしてのソフトウェア)とは、ECサイトのソフトウェアを提供元が稼働させ、アップデートし、保護し、販売事業者はそれをサブスクリプションで利用してブラウザーから管理する形態です。国際的な例にはShopifyがあり、ハンガリー市場にはShoprenterとUNASがあります。レンタル型システムは拡張機能で機能を追加でき、その多くはAPIも提供しています。APIとは、別のシステムがECサイトからデータを取得したり、ECサイトにデータを書き込んだりするためのプログラミングインターフェースです。
Shoprenterの開発者向けドキュメントは、インターフェースをリソースごとに(商品、顧客、注文など)説明しており、Webhookも提供しています。Webhookとは、注文の確定や注文ステータスの変更などのイベントの後に、ECサイトが外部システムに送る自動メッセージです(Shoprenter: WebHook automation)。UNASのドキュメントによれば、そのAPIの目的は、ECサイトを請求書発行ソフトや在庫管理ソフトなどの外部システムと、双方向でも接続することです。このインターフェースはPREMIUMとVIPのサブスクリプションプランで利用できます(UNAS: API documentation、2026年10月17日確認)。そのため、プランを選ぶ段階で、そのレベルで何ができるかを確認しておくことをお勧めします。
オープンソースで自社運用するECサイト
よくある例はWooCommerceで、WordPressというコンテンツ管理システム向けの、オープンソースのECプラグインです。ソースコードはGNU General Public Licenseのバージョン2またはそれ以降のバージョンのもとで公開されており(WooCommerce: licence)、プラグインの説明では、連携のためのREST APIとWebhookに触れ、ストアのコンテンツとデータが所有者の手元に残ることを強調しています(WordPress.org: WooCommerce)。自由には代償があります。ホスティング、WordPressとプラグインのアップデート、バックアップ、セキュリティ対策は、所有者自身、または所有者が委託した運用事業者が担わなければなりません。
ヘッドレスECサイト
ヘッドレス(「頭のない」)構成では、購入者が目にする画面とECサイトのエンジンが別々のシステムになります。Shopifyの開発者向けドキュメントによれば、ヘッドレスコマースはストアのフロントエンドをバックエンドから切り離すものです。画面はどのような技術でも構築・ホスティングでき、商品、カート、チェックアウトはプラットフォームのAPIが提供します(Shopify: Headless)。これが役立つのは、購入体験を非常に独自のものにする必要がある場合、ECサイトがコンテンツの豊富なウェブサイトの一部である場合、あるいは同じ品ぞろえを複数のチャネル(ウェブ、モバイルアプリ、キオスク端末)で表示する必要がある場合です。その代わり、プラットフォームと自社の画面という2つのシステムを保守する必要があります。
オーダーメイド開発のECサイト
オーダーメイドのECサイトでは、商品モデル、価格設定、注文プロセス、連携を、企業の業務の進め方に合わせて正確に作り込みます。プラットフォームの制約はありませんが、既製の拡張機能のマーケットもありません。ECサイトに必要な機能は、すべて設計、開発、テスト、運用しなければなりません。オーダーメイドの道が強みを発揮するのは、ECサイトが企業の主要な販売チャネルであり、ERP(統合基幹業務システム)、倉庫、生産と緊密に連携する必要がある場合です。
一覧表での比較
| 観点 | レンタル型システム | オープンソース(例:WooCommerce) | ヘッドレス | オーダーメイド開発 |
|---|---|---|---|---|
| 立ち上げ | 最も速い。既製のテーマと設定 | 既製のテーマとプラグインで足りれば速い | より長い。自社の画面を構築する必要がある | 最も長い。開発の規模で決まる |
| 料金モデル | サブスクリプション。追加アプリの料金が別途かかる場合もある | ソフトウェアのサブスクリプションはない。ホスティング、有料プラグイン、運用 | プラットフォームのサブスクリプションに加え、自社の画面の開発と運用 | 一回限りの開発、その後は運用と追加開発 |
| 拡張性 | プラットフォームの枠と拡張機能マーケットの範囲内 | 自由だが、プラグインが増えるたびにアップデートの対象も増える | 画面は自由に作れるが、エンジンはプラットフォームのもの | 無制限。ソースコードの扱いは契約で定める |
| 連携(在庫、ERP、請求書発行、配送業者) | 既製の拡張機能、またはプランが許せばAPI経由 | プラグイン、またはオーダーメイドのコード | プラットフォームのAPI経由 | 企業のニーズに応じて、あらゆるインターフェースで |
| 性能 | 提供元のインフラとテーマの品質によって決まる | ホスティングとプラグインの数に左右される | 十分に最適化できるが、自社での作業になる | 設計と運用に左右される |
| データとエクスポート | プラットフォームのエクスポート機能と条件による | データベース全体が所有者のもの | エンジンのデータはプラットフォーム上にある | データベース全体がお客様のもの |
| ホスティングとセキュリティ | 提供元が責任を負う | 所有者自身、またはその運用事業者 | 分担:エンジンはプラットフォーム、画面は企業 | お客様自身、またはお客様が委託した運用事業者 |
表示速度は、推測ではなく測定することをお勧めします。Googleが推奨するCore Web Vitalsの指標は、読み込み(LCP)、応答性(INP)、視覚的な安定性(CLS)を測定するもので(web.dev: Web Vitals)、どの種類のECサイトにも同じように適用できます。
レンタル型システムで足りるのはどのような場合で、オーダーメイドが見合うのはどのような場合ですか?
レンタル型システムで足りるサイン
- 商品がシンプルです。バリエーションが少なく、価格が明確で、複雑な構成もありません。
- 注文プロセスが一般的です。カート、配送方法、支払い、注文確認という流れです。
- 必要な連携(請求書発行、配送業者、決済)に既製の拡張機能があります。
- すぐに始めることが重要で、チームにはサーバーを運用する時間も意向もありません。
- ECサイトは販売チャネルの1つであり、ビジネスモデル全体ではありません。
オーダーメイドやヘッドレスに進むべきサイン
- 商品がカスタマイズ可能であるか、オーダーメイドで作られるか、価格が複数の要素から計算されます。
- 再販業者向け(B2B)の価格表、独自の割引ルール、基本契約に基づく価格が必要です。
- ECサイトがERP、倉庫、生産とリアルタイムで連携する必要があります。
- プラグインの数が多くなりすぎ、アップデートのたびにリスクが生じます。
- プラットフォームの制約のために、企業がソフトウェアに合わせて自社のプロセスを変えており、その逆にはなっていません。
よくある、そして堅実な中間の道は、オーダーメイドの連携を加えたレンタル型のECサイトです。ストアはプラットフォーム上に残し、その裏側でオーダーメイドのサービスが注文を請求書発行ソフト、倉庫、ERPと連携させます。これはシステム連携の仕事で、詳しくは業務プロセス自動化のページでご説明しています。オーダーメイドのソフトウェアと既製品の一般的な比較については、オーダーメイドのソフトウェアか、既製のソリューション(SaaS)か?の記事で取り上げています。
ハンガリー特有の事情:請求書発行、NAV、配送業者、決済
請求書発行とNAV Online Számla
ハンガリー国税庁(NAV)の案内によれば、2021年1月4日以降、請求データの報告は、付加価値税の納税義務者ではない者、つまり個人の購入者に発行する請求書にも適用されています。請求書発行ソフトは、請求書の発行時に、人の介入なしに直ちに、XML形式でデータをOnline Számlaシステムに電子的に送信しなければなりません(NAV)。NAVは機械向けインターフェースの説明を、公開リポジトリでも公表しています(NAV: Online-Invoice)。ECサイトでは通常、これを請求書発行サービスを通じて処理します。たとえばSzámlázz.huのドキュメントによれば、Számla Agentというインターフェースを使って、請求書と領収書の操作をXMLで自動化できます(Számlázz.hu: API documentation)。重要なのはプロセスです。支払い済みまたは履行済みの注文から、手作業での転記なしに請求書が作成され、データ報告がエラーになったり却下されたりした場合には、誰かに通知が届くようにする必要があります。
宅配便と宅配ロッカー
宅配便や受け取りポイントのサービスとの接続には、3つの意味があります。購入者がチェックアウトで受け取りポイントや宅配ロッカーを選べること、注文から配送ラベルが自動的に作成されること、そして荷物のステータスがECサイトと購入者に戻ってくることです。レンタル型システムでは、そのための既製の拡張機能があるかを確認することをお勧めします。オーダーメイドのECサイトの場合や、適切な拡張機能がない場合は、サービス提供者のインターフェースに接続します。たとえばGLS、Foxpost、MPL、Packetaのサービスに接続します。
オンライン決済
カード決済では、カードデータを保存、処理、送信するすべての者に、国際的なセキュリティ基準であるPCI DSSが適用されます。Stripeのドキュメントによれば、リスクを低減する連携方式では、決済データが販売事業者のサーバーを経由せず、決済サービスに直接届くため、販売事業者のPCIに関する義務が軽減されます(Stripe: Integration security guide)。そのため当社は、ECサイトでカードデータを保存しないことをお勧めしています。支払いは、決済サービス(たとえばBarion、SimplePay、Stripe)のページまたは埋め込み画面で行うようにします。
在庫と基幹業務システム
在庫が倉庫管理システムやERPで管理されている場合、ECサイトは、売り切れた商品を注文できないようにそこから在庫を読み込み、注文をそこへ書き込む必要があります。これはECサイトにとって最も重要な接続の1つです。業務管理の側面については、業務ソフトウェアのページでご説明しています。
すべてのECサイトに適用される法律上の注意点
法令はプラットフォームに関係なく適用されます。レンタル型システムでは、プラットフォームが多くの点で支援してくれますが、法令遵守の責任は販売事業者にあります。これは情報提供であり、法的助言ではありません。具体的なケースについては、弁護士に相談することをお勧めします。
撤回権
指令2011/83/EUは、遠隔契約における消費者の権利を定めています。以下は、2026年9月27日時点の統合版のテキストに基づいています(EUR-Lex:指令2011/83/EU(統合版))。
- 第9条第1項によれば、消費者は14日以内であれば、理由を示さずに契約を撤回できます。商品の場合、この期間は原則として商品を受け取った日から起算します。
- 第6条第1項(h)によれば、事業者は契約前に、撤回権の行使の条件、期限、手続きについて情報を提供しなければなりません。これには撤回フォームのひな形と、該当する場合は撤回機能の有無と配置場所に関する情報が含まれます。
- 指令(EU)2023/2673によって追加された第11a条によれば、オンラインインターフェースを通じて締結された遠隔契約では、事業者は、指令の英語版で「withdraw from contract here」とされている表示(日本語にすれば「ここから契約を撤回」の意味)、またはそれに相当する明確な表現を付けた撤回機能を、撤回期間中いつでも利用できるように提供しなければなりません。消費者はこの機能を使って、オンラインで撤回の意思表示を送信できます。意思表示は、英語版で「confirm withdrawal」とされている表示(日本語にすれば「撤回の確認」の意味)のステップで送信され、事業者は耐久性のある媒体で受領確認を送ります。加盟国は、これらの規定を2026年6月19日から適用します(EUR-Lex:指令(EU)2023/2673)。
- この情報提供がなされなかった場合、第10条によれば、撤回期間は本来の期間の満了から12か月後に終了します。
- 第13条によれば、事業者は撤回の通知を受けてから14日以内に、消費者が支払った全額を、該当する場合は配送料も含めて返金します。
- 第16条は例外を挙げています。たとえば、消費者の指定に従って製造された商品や、明らかに個人向けにカスタマイズされた商品です。
ハンガリーでは、詳細な規定が政令45/2014(II. 26.)に定められています。撤回機能については、政令415/2025(XII. 23.)によって追加された同政令第22条の規定が定めています(Nemzeti Jogszabálytár、2026年10月17日確認)。ECサイトにとって、これは具体的な機能を意味します。情報は注文の前に表示されなければならず、オンラインの撤回機能は撤回期間中いつでも利用でき、受領確認を伴わなければなりません。返品と返金は追跡する必要があり、個人向けにカスタマイズされた商品には、その旨を表示しなければなりません。
アクセシビリティ
指令(EU)2019/882により、加盟国は2025年6月28日から、消費者向けに提供されるEコマースサービスにアクセシビリティ要件を適用しなければなりません(ハンガリーの規則はこの指令の国内法化に基づいています)。Eコマースサービスとは、消費者契約の締結を目的として、ウェブサイトとモバイル端末ベースのサービスを通じて提供されるサービスを指します(EUR-Lex:指令(EU)2019/882)。サービスを提供する零細企業(同指令によれば、従業員が10人未満で、売上高または貸借対照表の総額が一定の基準を下回る企業)は、要件の適用を除外されなければなりません(第4条第5項)。同指令の附属書Iによれば、ウェブサイトとモバイルアプリケーションは、知覚可能、操作可能、理解可能、堅牢にしなければなりません。レンタル型システムでは、その一部はプラットフォームと選んだテーマの品質に左右されるため、テーマもアクセシビリティの観点から確認することをお勧めします。オーダーメイドのECサイトでは、当社はWCAG 2.2のガイドラインに従います。
Cookieと同意
電子プライバシー指令(指令2002/58/EC)の統合版の第5条第3項によれば、ユーザーの端末に情報を保存すること、またはそこに保存された情報にアクセスすることは、明確かつ包括的な情報提供に基づいて事前に与えられた同意がある場合にのみ認められます。例外は、ユーザーが明示的に求めたサービスを提供するために厳密に必要な保存です(EUR-Lex:指令2002/58/EC)。したがって、カートの動作に必要なCookieは、アクセス解析用や広告用のCookieとは扱いが異なります。後者には同意が必要であり、Cookieバナーは本当の意味での選択肢を提供しなければなりません。
ECサイトにおける人工知能
- 商品テキスト: 商品説明文、カテゴリーの説明文、翻訳を大規模言語モデルで下書きします。レンタル型プラットフォームの中には、これを標準機能として提供しているものもあります。Shopifyのヘルプセンターによれば、管理画面のAI機能は商品説明文も作成します。またShopify自身も、AIが作成したコンテンツには誤りが含まれる可能性があるため、販売事業者がすべて確認するよう求めています(Shopify Help Center: AI features)。
- 検索: 正確なキーワードだけでなく、購入者の意図(「雨の日用の防水トレッキングシューズ」)も理解する商品検索。
- カスタマーサポート: ECサイト独自のデータ(商品、配送条件、注文状況)をもとに回答し、購入者が人工知能と話していることを明示するAIチャットボット。詳しくはAIチャットボット・AIエージェントのページをご覧ください。法的な背景については、AI ActとGDPRの記事で取り上げています。
レンタル型システムでは、AI機能の範囲は、プラットフォームや拡張機能が何を提供しているかに左右されます。オーダーメイドのECサイトやオーダーメイドの連携では、OpenAI(ChatGPT)、Anthropic(Claude)、Google(Gemini)のモデルの中から選び、モデルをECサイトのデータに直接接続します。誤りが金銭的な損失や信頼の低下につながる場面には、人による確認を設けます。
移行:レンタル型システムからオーダーメイドへ
多くの企業はレンタル型システムで始め、ECサイトがその枠に収まらなくなったときに次の段階へ進みます。それがどれだけ円滑に進むかは、古いシステムからどれだけのデータを取り出せるかに大きく左右されます。たとえばShopifyのヘルプセンターによれば、商品、注文、顧客はいずれもCSVファイルにエクスポートできます(Shopify: exporting products、exporting orders、exporting customers)。ただし、商品に属する画像は商品のCSVに含まれないため、別途保存する必要があります。移行の手順は次のとおりです:
- データの棚卸し: 古いシステムにどのようなデータがあるか(商品、バリエーション、画像、顧客、過去の注文、クーポン、コンテンツページ)、そしてそこから何をエクスポートできるかを確認します。
- データマッピングとデータクレンジング: 古い項目をそれぞれどこに移すか、何を整理する必要があるか(たとえば重複した顧客や不完全な商品データ)を決めます。
- URLマップとリダイレクト: Google検索セントラルのガイドによれば、古いURLを1つずつ新しいURLに対応づけ、サーバー側で恒久的なリダイレクト(301または308)を設定する必要があります。これにより、検索エンジンで獲得した掲載順位が失われずに済みます(Google Search Central)。
- 連携のつなぎ直し: 請求書発行、決済、配送業者、在庫。試験注文で一通りテストします。
- 本番稼働とその後の確認: 古いシステムのデータを最後に同期し、切り替え後は指標とエラーを監視します。
現在レンタル型システムを選ぶ場合は、今のうちにエグジットプラン(契約終了時の計画)を作っておくことをお勧めします。どのデータを、どのような形式でエクスポートできるのか、そして後継のシステムが継続的にデータを引き継げるAPIがあるのかを確認しておきます。
費用と期間は何によって決まりますか?
レンタル型システムの場合、費用はサブスクリプション、追加アプリ、テーマ、設定にかかる作業から成り立ちます。オーダーメイドの連携も必要な場合は、それは別の開発になります。オーダーメイドのECサイトの場合は、開発の機能規模をCOSMICファンクションポイント(ISO/IEC 19761)で測定し、そこからお見積もりとスケジュールを作成します。規模のほかに、次の要素が影響します:
- 連携の数と、そのインターフェースのドキュメントの充実度。
- 商品モデルの複雑さ(バリエーション、カスタマイズ可能な商品、独自の価格設定ルール)。
- デザインの独自性と画面の数(ウェブ、モバイル、管理画面)。
- 移行するデータの量と品質。
- 非機能要件(表示速度、可用性、アクセシビリティ、セキュリティ)。
- 引き渡し後の運用と追加開発の範囲。
測定方法は料金の考え方のページでご説明しています。
判断でよくある失敗
- 初期費用だけを見て、何年にもわたるサブスクリプション、拡張機能、運用の費用を見ていません。
- どのデータをエクスポートできるのか、選んだプランにAPIが含まれているのかを事前に確認していません。
- プラグインを入れすぎて、アップデートの後に何がなぜ壊れたのか、誰にもわからなくなります。
- 手作業の請求書発行で始め、注文数が増えるにつれて請求書発行がボトルネックになります。
- 移行の際にリダイレクトを設定せず、古いアドレスがエラーページにつながります。
- Cookieバナーが初期設定ですべてを受け入れてしまうか、拒否された後もアクセス解析のコードを読み込んでしまいます。
よくあるご質問
レンタル型とオーダーメイド、どちらのECサイトを選ぶべきですか?
商品構成と注文プロセスがレンタル型システム(たとえばShopify、Shoprenter、UNAS)やWooCommerceの枠に収まるなら、そのほうが早く、リスクも小さく始められます。オーダーメイドのECサイトが見合うのは、商品構成や価格設定が特殊な場合、ERPや倉庫との緊密なリアルタイムの連携が必要な場合、あるいはECサイトが主要な販売チャネルで、プラットフォームの制約なしに開発したい場合です。中間の道は、オーダーメイドの連携を加えたレンタル型のECサイトです。
レンタル型システムからオーダーメイドのECサイトに移行できますか?
はい。古いシステムからデータ(商品、顧客、注文、画像、コンテンツ)を取り出せれば可能です。移行の重要な部分は、古いアドレスから新しいアドレスへのリダイレクトと、連携のつなぎ直しです。レンタル型システムを選ぶ段階で、どのようなエクスポート機能とAPIがあるかを確認しておくことをお勧めします。
ECサイトを請求書発行ソフトや倉庫と連携できますか?
はい。システムに利用可能なインターフェース(API)がある場合、またはデータがファイルやデータベースで取得できる場合は、請求書発行ソフト(たとえばSzámlázz.hu、Billingo)とは請求書の自動発行で、倉庫管理システムやERPとは在庫同期で連携させます。プラットフォームのAPIが選んだプランで利用できれば、こうした連携はレンタル型のECサイトの裏側にも構築できます。
レンタル型システムでは、データは誰のものですか?
それはプラットフォームの利用規約とデータ処理契約によって決まります。GDPR第28条によれば、管理者に代わって行われる処理は、契約によって規律されなければなりません(EUR-Lex:規則(EU)2016/679)。実際に決め手となるのは、データを取り出せるかどうかです。大手のプラットフォームはエクスポート機能とAPIを提供していますが、その範囲はプラットフォームやプランによって異なります。自社運用やオーダーメイドのECサイトでは、データベース全体が所有者の手元にあります。
ECサイトはアクセシビリティに対応する必要がありますか?
指令(EU)2019/882を国内法化した規則により、消費者向けに提供されるEコマースサービスは、2025年6月28日以降、アクセシビリティ要件を満たさなければなりません。同指令によれば、サービスを提供する零細企業は適用除外とされなければなりません。零細企業に該当しない場合は、ECサイトをアクセシビリティの観点から点検することをお勧めします。レンタル型システムではテーマも点検の対象です。これは情報提供であり、法的助言ではありません。
当社がお手伝いできること
Mesterséges Intelligencia Központ Kft. は、オーダーメイドのECサイトを開発し、決済、配送、請求書発行の各サービス事業者、倉庫、ERPと連携させます。ご要望に応じて人工知能も取り入れます。レンタル型システムが御社のお役に立っているなら、置き換える必要はありません。その裏側に連携を構築します。詳しくはECサイト開発のページでご説明しています。
初回のご相談は無料です。ご要望に応じて秘密保持契約(NDA)を締結します。引き渡し後の運用・保守もお引き受けします。ソースコードと利用権の扱いは、契約で定めます。何を販売していて、どのようなシステムで業務を行っているのかを数行でお書きいただけましたら、ご連絡ください。
出典
- EUR-Lex:消費者の権利に関する指令2011/83/EU(統合版)
- EUR-Lex:指令2011/83/EUを改正する指令(EU)2023/2673
- ハンガリー国家法令データベース(Nemzeti Jogszabálytár):政令45/2014(II. 26.)
- EUR-Lex:製品およびサービスのアクセシビリティ要件に関する指令(EU)2019/882
- EUR-Lex:指令2002/58/EC(統合版)
- EUR-Lex:規則(EU)2016/679(一般データ保護規則、GDPR)
- NAV: Invoice data reporting rules for invoice issuers from 4 January 2021(ハンガリー語)
- NAV: Online-Invoice public repository
- Számlázz.hu: API documentation
- Shoprenter: WebHook automation
- UNAS: API documentation(ハンガリー語)
- WordPress.org: WooCommerce
- WooCommerce: licence
- Shopify: Headless commerce
- Shopify Help Center: Exporting products
- Shopify Help Center: Exporting orders
- Shopify Help Center: Exporting customers
- Shopify Help Center: AI features in the Shopify admin
- Stripe: Integration security guide
- Google Search Central: Site moves with URL changes
- web.dev: Web Vitals