Shopware B2B開発：2026年に高パフォーマンスのコマースストアを構築する方法

B2Bバイヤーの67%が現在、営業担当者なしで購買を完結させることを好んでいる。セルフサービスの受注管理、顧客別価格設定、見積もりワークフローを求めており、電話不要でブラウザからアクセスできることを望んでいる。

Shopware 6は、DACHのメーカーと販売代理店の多くがこれを実現するために使用しているプラットフォームだ。4年連続でShopwareはドイツのトップ1,000オンラインショップで11.5%のシェアを保持しており、すべてのプラットフォームの中で最大だ。インフラは実証済みだ。問題は、その上に正しく構築する方法だ。

このガイドでは、2026年のShopware B2B開発の全容を解説する：プラットフォームがネイティブに提供するもの、カスタム開発が必要なもの、パフォーマンスのためのアーキテクチャ設計、そして多くのプロジェクトが犯す間違いについて。

ShopwareでB2Bオンラインストアを構築するには？

Shopware B2Bストアは3つの層で構築される：コアワークフロー（見積もり、承認、従業員管理）のためのネイティブB2Bコンポーネント、ERP/CRM連携と非標準の価格ロジックのためのカスタムAPI開発、そしてパフォーマンスのためのヘッドレスまたはAPI-firstフロントエンドだ。EvolveライセンスティアでB2B機能セット全体がアンロックされる。カスタム開発は、ビジネスが必要としているがプラットフォームが提供しないすべてのものを処理する。

2026年にB2BでShopware 6を選ぶ理由

Shopware 6はゼロからAPI-firstで構築されている。すべてのストアフロント操作がStore APIを通じて実行されるため、プラットフォームは再構築なしに従来型とヘッドレスの両方のアーキテクチャをサポートする。バイヤーポータル、ERP連携、複雑な価格ルールが標準要件となるB2B運営では、これが重要な意味を持つ。

ShopwareのグローバルカスタマーベースのX80%以上がDACH地域に集中している。エクステンション、エージェンシー、インテグレーションパートナーのエコシステムはこの集中を反映している。ドイツ語圏市場にサービスを提供するメーカーや販売代理店にとって、プラットフォームサポートインフラは汎用グローバルプラットフォームにはない成熟度を持っている。

レガシーB2B SuiteはShopware 6.8で廃止される予定だ。現在の実装が旧スイートで動作している場合、B2Bコンポーネントへの移行は任意ではなく必須となる。

Shopware B2Bコンポーネントがネイティブに提供するもの

Shopware 6.6+のEvolveプランから、以下がカスタム開発なしで利用可能だ：

→ 従業員管理：企業配下のバイヤーアカウントを作成し、ロールを割り当て、従業員ごとに権限を設定する

→ 発注承認： 発注額または商品カテゴリ別に承認ワークフローを設定する

→ 見積もり管理：バイヤーがカートを見積もり依頼として送信し、営業チームが正式見積もりで応答、バイヤーが注文に変換する

→ クイック注文：バイヤーがCSVをアップロードするか商品番号を直接入力して大量注文を素早く作成する

→ ショッピングリスト：注文テンプレートを保存・再利用し、会社アカウント間で共有可能

これらはB2Bセルフサービスワークフローのコアをカバーしている。バイヤーはログインし、注文を作成し、承認に提出し、見積もりを受け取り、営業に連絡することなく確認できる。

含まれないもの：大規模な顧客別価格設定、ERP同期在庫、複雑な契約条件、マルチ倉庫ロジック。これらにはカスタム開発が必要だ。

カスタムShopware B2B開発が必要なもの

ネイティブコンポーネントはワークフローを処理する。カスタム開発は複雑さを処理する。

Shopware B2Bプロジェクトで最も一般的なカスタム開発要件：

ERPおよびPIM連携

ShopwareのStore APIは双方向データ交換をサポートするが、ERP（SAP、Microsoft Dynamics、ProAlpha）とShopwareのデータモデル間のマッピングロジックにはカスタムコネクタ開発が必要だ。商品データ、在庫数、顧客アカウント、注文ステータスはすべて定義された同期スケジュールとエラーハンドリングが必要だ。

顧客別価格設定

Shopwareは価格リストと顧客グループ価格設定をネイティブにサポートしている。卸売や産業流通で一般的な、顧客ごとの個別契約価格を持つメーカーは、通常、実行時にERPに問い合わせるカスタム価格レイヤーが必要になる。

複雑な承認階層

ネイティブ承認ワークフローは発注額による単一レベルの承認をカバーする。多段階の承認チェーン（部門長→経理→購買）にはカスタム拡張が必要だ。

B2B顧客ポータル

標準のアカウントエリアを超えて、多くのメーカーには専用ポータルが必要だ：注文履歴、配送追跡、請求書ダウンロード、契約書類へのアクセス。これはフロントエンドの構築であり、ネイティブ機能ではない。

高パフォーマンスShopware B2Bのためのアーキテクチャ決定

Shopware 6.7.5で本番対応のStore APIキャッシングが導入された。パフォーマンスの差は測定可能だ：キャッシュされたレスポンスは20msで返る；キャッシュされていないオリジンリクエストは480msかかる。大規模では、適切なキャッシングでオリジンリクエストが85%以上削減される。

カタログサイズが大きく顧客別データが一般的なB2Bストアでは、パフォーマンスを決定するアーキテクチャ上の決定は：

ヘッドレスvs.従来型

Shopwareは両方をサポートする。ヘッドレス（Vue Storefront、Next.js、またはStore APIを使用するカスタムフロントエンド）は最大のフロントエンド制御と最高のパフォーマンス上限を提供する。従来のTwigベースのストアフロントは構築が速く、ほとんどのミドルマーケットB2B運営に十分だ。フロントエンド要件——プログレッシブウェブアプリ、モバイルファーストのバイヤーポータル、複雑なフィルタリング——がTwigテンプレートで綺麗に実現できる範囲を超える場合にヘッドレスを選択する。

キャッシング戦略

カタログページと商品データにCache-Control: s-maxageを正しく設定する。パーソナライズされたコンテンツ（顧客別価格、アカウントデータ）は共有キャッシュから除外する必要がある。混合キャッシュアーキテクチャ——公開ページにはCDN、認証済みバイヤーセッションにはno-cache——が標準パターンだ。

データベースクエリ最適化

商品リストでのN+1クエリは、カタログが大きいShopware B2Bストアで最も一般的なパフォーマンスボトルネックだ。Shopwareのアソシエーションローディングを正しく使用し、本番稼働前にプロファイリングを行う。

顧客ポータル体験の構築

アカウントエリアはB2Bバイヤーが最も多くの時間を費やす場所であり、ストアフロントではない。注文履歴、再注文ワークフロー、見積もり追跡、請求書管理が、プラットフォームが業務負荷を削減するか、既存の手動プロセスの上にデジタル層を追加するだけかを決定する機能だ。

ポータルをプラットフォーム機能ではなく、バイヤーのタスクを中心に構築する：

• 再注文 - 注文履歴からカートへワンクリック
• 見積もりステータス - 依頼から承認、注文までの可視化された追跡
• 承認の可視性 - バイヤーが承認チェーンのどこにいるかを確認できる
• 請求書アクセス - ERPから同期されたPDF請求書のダウンロード

Shopware B2Bの従業員管理は権限スコーピングを処理する：バイヤーは自分の注文のみ閲覧でき、購買マネージャーは会社アカウント全体を閲覧できる。顧客の実際の内部構造に合わせたロール定義を構築し、汎用的なバイヤー/管理者の分割ではなく。

2026年のShopware B2B開発チェックリスト

開発開始前

• Shopware Evolveライセンスが整っていることを確認する
• Shopwareと同期が必要なすべてのERPデータエンティティをマッピングする
• 顧客別価格ルールとマスターデータの保存場所を定義する
• 顧客セグメントごとの承認ワークフロー要件を特定する
• 決定：ヘッドレスか従来型ストアフロントか

開発中

• 初日からリトライロジックとエラーログを備えたERP連携を構築する
• 現実的なデータ量でカタログページのデータベースクエリパフォーマンスをプロファイリングする
• 実際の会社アカウント構造で承認ワークフローをエンドツーエンドでテストする
• 本番稼働前にステージングでStore APIキャッシング設定を検証する

本番稼働前

• 予想される同時バイヤーセッション数でStore APIに対してロードテストを実施する
• 顧客別価格設定が20以上のテストアカウントで正しい値を返すことを確認する
• 完全なフルフィルメントサイクルを通じてERPへの注文同期をテストする

ほとんどのShopware B2Bプロジェクトが犯す間違い

ERP連携を遅く始めすぎること。ERP同期はフェーズ2の作業ではない。顧客別価格設定、在庫精度、注文確認はすべてそれに依存している。連携を構築の最後まで先送りするプロジェクトは、一貫して本番稼働日を逃す。

承認ワークフローの仕様が不十分なこと。ネイティブの注文承認は1レベルをカバーする。顧客が多段階の調達承認で運営しており——ほとんどの中規模メーカーがそうだ——ネイティブ機能が拡張できるという仮定ではなく、カスタム構築が必要だ。

バイヤーではなく管理者のために構築すること。ポータルは管理者的な思考をする内部チームによってスコープが設定される。バイヤーはタスクの観点で考える。承認前にすべてのワークフローを実際のバイヤーシナリオでテストする。

高パフォーマンスのShopware B2Bストアを構築する

Shopware 6は2026年において、ゼロから始めることなく複雑なB2B要件を処理するのに十分な成熟度を持っている。ネイティブB2Bコンポーネントがコアのセルフサービスワークフローをカバーする。カスタム開発がB2Bコマースを運用上現実のものにする連携と複雑さを処理する。

速度、採用率、運用上のインパクトにおいてパフォーマンスを発揮するストアは、明確な決定を中心に構築されたものだ：このポータルはバイヤーに何を可能にする必要があり、すべての連携決定がその結果にどのように貢献するか。