販売チャネルアプリの マルチチャネル対応

図解 ： 販売チャネルアプリのマルチチャネル対応（Multi-channel support for sales channel apps） Admin GraphQL API / 2026-04 販売チャネルアプリの マルチチャネル対応 1 つの販売チャネルアプリが、1 つのショップ上で複数のチャネル接続を作成・管理できるようになった。接続ごとに別々の specification（仕様ファイル）や外部アカウントを持てる。これまでアカウントや市場ごとにアプリを分割していたモデルを、1 アプリ内に集約できる。 このページの構成 そもそも何が変わるのか（30秒で理解） 仕組み図解 ： 1 アプリ → 複数チャネル 新しくできること（What's new） 新規アプリでのチャネル作成手順 既存アプリの移行でやること 新 API ／ 影響を受ける API 技術者が押さえるべき5つのポイント 業務に活かせる3つのユースケース 提案で使える1行サマリ 1 そもそも何が変わるのか これまで販売チャネルアプリは 1 アプリ＝ 1 チャネル が前提だった。 今回、 1 つのアプリが同じショップ上で複数のチャネル接続を確立 できるようになり、 接続ごとに別々の specification（仕様ファイル）や外部アカウントを割り当てられる。 従来 ： アカウント／市場ごとにアプリを分割 別アカウントや別市場で売りたいと、その数だけアプリを作って分散管理。コードもインフラも重複。 これから ： 1 アプリに複数チャネルを集約 接続を 1 アプリ内に保持し、それぞれを「別個のチャネル」として管理。分割が不要になる。 2 仕組み図解 ： 1 アプリ → 複数チャネル 構成の核は Channel Config 拡張（1 アプリに 1 つ）＋ ターゲットチャネルごとの specification ファイル（1 チャネルに 1 つ） 。 各チャネルは specificationHandle で別々の仕様を指し、 accountId / accountName で別々の外部アカウントに紐づく。 3 新しくできること（What's new） NEW 1 アプリで複数チャネル 同じショップ上に、1 つの販売チャネルアプリが複数のチャネルを確立できる。 NEW Config 拡張 ＋ 仕様ファイル Channel Config 拡張に加え、 ターゲットチャネルごとに 1 つの specification ファイル を持てる。 NEW 接続ごとに別仕様・別アカウント 各チャネルは、別々の specification と別々の外部アカウントを指し示せる。 異なるアカウント・異なる市場・異なるサーフェスで売るために、もはやアプリを分割する必要はない。接続を 1 アプリ内に保持し、 distinct channel（別個のチャネル） として扱える。 4 新規アプリでのチャネル作成手順 1 Channel Config 拡張を追加 すべての新しい販売チャネルは Channel Config 拡張を追加する。 2 仕様ファイルを定義 ターゲットチャネルごとに 1 つの specification ファイルを定義する。 3 channelCreate で接続作成 specificationHandle ・ accountId ・ accountName を渡して各チャネル接続を作る。 5 既存アプリの移行でやること 1. チャネル接続方式へ移行 レガシーな販売チャネルアプリを、移行ガイドに沿って「チャネル接続（channel connections）」を使う方式へ移行する。 2. 「1 アプリ 1 チャネル前提」のコードを点検 チャネル固有の状態を読み書きしているなら、アプリレベルの既定値に頼らず channel ID を明示的に渡す よう直す。 下流コードが「アプリにつきチャネルは 1 つ」と暗黙に仮定している箇所が要注意。マルチチャネル化した瞬間に、どのチャネルへの操作か曖昧になる。 channelId を引き回す設計 に切り替えること。 6 新 API ／ 影響を受ける API このリリースで追加された API channel チャネルの取得 channelCreate チャネル接続を作成 channelByHandle handle でチャネル取得 channelUpdate チャネルを更新 channelDelete チャネルを削除 channelFullSync チャネルのフル同期 非推奨（Deprecated）になった単一チャネル前提の API 今日時点では動作するが、将来の API バージョンで削除される。 非推奨 API 代わりに使う publishablePublishToCurrentChannel publishablePublish publishableUnpublishToCurrentChannel publishableUnpublish AppInstallation.channel ルートレベルの channels クエリ AppInstallation.publication ルートレベルの publications クエリ Product.publishedOnCurrentPublication publishedOnPublication Publishable.resourcePublicationOnCurrentPublication resourcePublications 更新（Updated）：任意の channelId を受け付けるようになった API bulkProductResourceFeedbackCreate どのチャネルに対する操作かを channelId で指定可能に。 bulkProductPublicationStatusUpdate 同上。複数チャネルを作るアプリでは channelId の指定が必須。 複数チャネルを作るアプリは channelId の引き渡しが必須。 単一チャネルのアプリなら、既存の呼び出しは変更なしでそのまま動く。 7 技術者が押さえるべき5つのポイント 1. Channel Config 拡張が前提 新しい販売チャネルはすべて Channel Config 拡張を追加する。これが複数チャネルを束ねる土台になる。 2. 仕様ファイルはチャネル単位で 1 つ ターゲットチャネルごとに specification ファイルを定義。各チャネルは別仕様・別外部アカウントを指せる。 3. channelCreate の3引数 specificationHandle ・ accountId ・ accountName をセットで渡し、各チャネル接続を作成する。 4. アプリレベル既定値への依存を断つ チャネル固有の状態を読み書きするコードは、アプリレベルの暗黙の既定に頼らず channelId を明示的に渡すよう改修する。 5. CurrentChannel / CurrentPublication 系 API は計画的に置換 publishablePublishToCurrentChannel や Product.publishedOnCurrentPublication などの「カレント」前提 API は非推奨に。今は動くが将来の API バージョンで削除されるため、 publishablePublish やルートレベルの channels / publications クエリへ早めに寄せる 。 8 業務に活かせる3つのユースケース USE CASE 1 マーケットプレイス連携アプリの「アカウント別接続」を 1 アプリに集約 課題 出店者ごと・販売アカウントごとに別接続が必要な連携を、これまでアカウント数だけアプリに分割して管理していた。 打ち手 1 アプリ内に Channel Config 拡張を入れ、アカウントごとに specification ファイルを用意。 channelCreate に accountId / accountName を渡して接続を量産する。 効果 アプリ分割が不要になり、コードベース・申請・運用が一本化。アカウント追加は仕様ファイル＋ channelCreate だけで完結。 技術メモ 各接続は別個のチャネルとして扱われるため、状態の読み書きは必ず channelId を伴わせる。 USE CASE 2 市場・地域ごとに別チャネルを切る多市場販売アプリ 課題 市場（国・地域）ごとに別々の外部アカウントや別仕様で売りたいが、1 アプリ 1 チャネル制約のため要件を満たせなかった。 打ち手 市場ごとに specification ファイルを定義し、market 単位でチャネルを channelCreate 。 bulkProductPublicationStatusUpdate に channelId を渡して市場別の公開状態を制御する。 効果 市場ごとの出品・公開を 1 アプリで分離管理。市場追加もチャネル追加で対応でき、横展開が速い。 技術メモ 複数チャネルを作る以上、 channelId の指定は必須。市場マッピングを内部で持ち、API 呼び出しに必ず添える。 USE CASE 3 既存チャネルアプリの「将来削除される API」棚卸しと先回り移行 課題 既存アプリが ...ToCurrentChannel / ...OnCurrentPublication 系の単一チャネル前提 API に依存。将来の API バージョンで削除されると動かなくなる。 打ち手 移行ガイドに沿ってチャネル接続方式へ移行。非推奨 API を publishablePublish やルートレベル channels / publications クエリへ置換し、下流コードに channelId を通す。 効果 API 削除に伴う将来の破壊を回避。同時にマルチチャネル化への足場が整い、機能拡張が容易に。 技術メモ 非推奨 API は今日時点では動作するため、本番影響を抑えつつ段階移行が可能。「カレント」前提の箇所を grep で洗い出すのが起点。 9 提案で使える1行サマリ 「1 つの販売チャネルアプリで、ショップ上に 複数のチャネル接続 を作れるようになった。 Channel Config 拡張 ＋ チャネルごとの仕様ファイル ＋ channelCreate が基本形。 アカウント・市場・サーフェス別にアプリを分割していた構成を 1 アプリへ集約でき、 既存アプリは「カレント」前提の非推奨 API を channelId ベースへ早めに移行するのが安全。」 source ： shopify.dev / changelog / multi-channel-support-for-sales-channel-apps 公開日 ： 2026-04-01（Developer Changelog）