概要
Shopify Functions は、Shopifyの裏側の処理そのものに自社のロジックを差し込める仕組みです。従来は「Shopifyが決めた計算ルール」を受け入れるしかなかった割引・配送・決済・在庫引当といった領域に、自分たちのビジネスルールを注入できます。
重要なのは、これがShopifyのサーバー内部で動くという点です。外部サーバーを呼び出すわけではないので速く、落ちにくい一方、その代わりに非常に厳しいリソース制限が課せられています。「自社サーバーで動かすプログラム」と同じ感覚で設計すると、確実に制限に引っかかります。
また、Functionは URLを叩いて直接実行することはできません。買い物客がカートに商品を入れた、決済画面に進んだ、といったタイミングでShopify側が勝手に呼び出します。
出典: About Shopify Functions / Function APIs
何ができるか（Function APIの一覧）
現在提供されているFunction APIは以下の7種類です。それぞれ「Shopifyのどの判断に割り込むか」が決まっています。
Function API |
何を差し替えられるか |
業務課題の例 |
|---|---|---|
Cart Transform |
カート内の商品の見せ方・値段の組み替え |
「3点セットで販売」のようなバンドル商品を、在庫は個別管理のまま1商品として見せる |
Discount |
割引の計算ロジック |
「同一カテゴリ2点目半額」「会員ランク別割引」などShopify標準では作れない割引 |
Fulfillment Constraints |
どの商品をまとめて出荷するかの制約 |
冷凍品と常温品を必ず別便にする、といった出荷ルールの強制 |
Order Routing Location Rule |
どの倉庫・店舗から出荷するかの優先順位 |
顧客に最も近い拠点を優先、特定商品は本社倉庫固定、など |
Delivery Customization |
配送方法の並び替え・改名・非表示 |
離島宛には特定の配送方法を出さない、注文金額で送料無料表示を切り替える |
Payment Customization |
決済方法の並び替え・改名・非表示 |
高額注文では代引きを隠す、B2B顧客にのみ請求書払いを出す |
Cart and Checkout Validation |
購入を進めさせるかどうかの検証 |
1人あたり購入点数の上限、特定地域への配送禁止、必須項目の入力チェック |
このほか、集荷場所（Pickup Point / Local Pickup）の選択肢を生成するAPIが unstable 版で提供されています。
出典: Function APIs
実行される順番が決まっている
複数のFunctionは好きな順に動くのではなく、決済フローの中で固定された順序で実行されます。前の段階の結果を後の段階が受け取る仕組みです。
カート内容の組み替え → 商品割引の計算 → 出荷グループの決定と拠点の割り当て → 配送方法の生成とカスタマイズ → 送料割引の計算 → 決済方法のカスタマイズ → 最終検証
この順序が実務で効いてくるのは、**「後の工程の情報は前の工程では使えない」**という点です。たとえば「選択された配送方法によって割引額を変えたい」という要件は、割引の計算が配送方法の決定より前に走るため、素直には実現できません。要件ヒアリングの段階でこの順序を知っていると、実現できない組み合わせを早期に見抜けます。
出典: Function execution order in checkout
利用できる条件（ここが最大の落とし穴）
Functionsは誰でも使えるわけではありません。アプリの配布形態によって、必要なプランが変わります。
アプリの種類 |
必要なストアのプラン |
|---|---|
公開アプリ（App Store配布）にFunctionを含める |
どのプランのストアでも利用可能 |
カスタムアプリ（特定ストア専用）にFunctionを含める |
Shopify Plus のみ |
これは提案・見積もりの現場で非常に重要です。「A社さん専用にカスタムアプリを作って割引ロジックを入れましょう」という提案は、A社がPlusでなければ成立しません。Plusでないストアに同じ機能を届けたい場合は、公開アプリとしてApp Storeに出す（=審査を通す）必要があり、開発コストも期間も大きく変わります。
さらに、外部APIを呼ぶ機能（後述のネットワークアクセス）は Shopify for enterprises 相当 が前提で、より厳しい条件になります。
出典: Functions availability / API availability
リソース制限（固定で決まっているもの）
Functionは決済という最も重要な導線の中で動くため、Shopifyは厳格な上限を設けています。プランを上げても緩和されません。
項目 |
上限 |
非エンジニア向けの言い換え |
|---|---|---|
コンパイル後のプログラムサイズ |
256 kB |
プログラム本体は非常に小さくまとめる必要がある |
実行時メモリ |
10,000 kB |
処理中に広げられる作業スペースの上限 |
スタックメモリ |
512 kB |
入れ子の深い処理は組めない |
ログ出力 |
1 kB（超過分は切り捨て） |
デバッグ情報をほとんど残せない |
同時に動かせるFunctionの数 — 1つのFunction APIあたり最大25個まで有効化できます（以前は5個でした）。複雑なロジックを1本に詰め込まず、目的ごとに分割できる余地があります。対象は決済カスタマイズ、配送カスタマイズ、カート/チェックアウト検証、出荷制約の4種です。
出典: Fixed limits / Shopify Functions can execute up to 25 functions in a single batch
リソース制限（カートの大きさで変わるもの）
以下はカート内の商品行数によって変動します。200行までは下表の値で、それを超えると行数に比例して緩和されます。
項目 |
上限（200行まで） |
実務上の意味 |
|---|---|---|
実行命令数 |
1,100万命令 |
計算量の上限。重い処理は途中で強制終了する |
入力データ |
128 kB |
Functionが受け取れる情報量の上限 |
出力データ |
20 kB |
Functionが返せる指示の量の上限 |
出力20kBの制約は要注意です。Shopifyは公式に「この上限では全商品行に対する一括の価格変換はできない」と明記しています。「カート内の全商品の価格を書き換える」といった要件は、割引Functionを使うか、B2Bカタログを使うか、対象商品を絞るかに設計変更する必要があります。
また、使用言語による差が大きい点も押さえておくべきです。Shopifyは「大きなカートで失敗しないよう、最も性能の良いRustを強く推奨する」と繰り返し明記しています。JavaScriptでも書けますが、カートが大きくなったときに命令数の上限に当たりやすくなります。「JavaScriptで作ったので開発が速く安く済みました」が、大口顧客の大量注文で破綻するという失敗パターンがあり得ます。
出典: Dynamic limits
Functionに渡せるデータの制限
Functionが必要なデータは、GraphQLの「入力クエリ」で指定します。ここにも制限があります。
入力クエリ本文は3,000バイトまで（コメントを除く）
メタフィールドの値が10,000バイトを超えると、その値は返ってこない — 大きなJSONを1つのメタフィールドに詰め込む設計は破綻します
配列で渡せる要素は100個まで
入力クエリのコストは合計30まで — メタフィールド参照は1つで3、タグ判定（hasTags）やコレクション所属判定も1つで3。単純な項目（ID、SKUなど）は1
このコスト計算から読み取れるのは、**「メタフィールドやタグを何個も参照する設計は、すぐに上限30に到達する」**ということです。メタフィールド10個を参照した時点でコスト30となり、他に何も取れなくなります。設計段階で「Functionに何を渡すか」を絞り込む作業が必須です。
外部システムとの連携（ネットワークアクセス）
Functionから外部のAPIを呼ぶことは、限定的にしかできません。
Function API |
外部API呼び出しの利用条件 |
|---|---|
Cart and Checkout Validation |
Shopify for enterprises + カスタムアプリ |
Discount Functions |
Shopify for enterprises + カスタムアプリ |
Local Pickup Delivery Option Generator |
Shopify for enterprises + カスタムアプリ |
Pickup Point Delivery Option Generator |
開発ストア および Shopify Plus + カスタムアプリ |
しかも Shopifyによる有効化申請が必要 で、開発ストアや機能プレビューでは基本的に試せません。「外部の在庫システムを見て割引を出す」といった要件は、事実上ほとんどの案件で実現できないと考えるのが安全です。
仕組みとしては、Functionが「このURLを叩いてほしい」という指示を返し、Shopifyが代わりにHTTPリクエストを実行して、その結果を本体のロジックに渡します。アプリが直接通信するわけではありません。
動作条件
タイムアウトは 100ms〜2000msの範囲でしか設定できない。数秒かかる外部APIは使えない
レスポンスは ヘッダーとボディ合わせて100kBまで
成功レスポンスは 最大300秒キャッシュされる。エラーや429は30秒キャッシュ。Cache-Controlヘッダーは無視される
接続エラーが続くと、ホスト単位で20秒以上のサーキットブレーカーが作動する
キャッシュは同一ストア内の全チェックアウトセッションで共有される。ストア間では分離される
エラーは 502 / 504 などのステータスコードとしてFunctionに返るため、フォールバック処理を必ず書く必要がある
Storefront APIの型は
@deferディレクティブと併用する場合のみサポート。オンラインストアのカートAjax APIは非対応（呼んでも502が返る）
推奨される代替手段 — Shopifyは「外部通信ではなく、事前にメタフィールドへ書き込んでおく」ことを公式に推奨しています。買い物客がチェックアウトに到達する前に、Admin APIで商品・顧客・ロケーションにデータを書き込んでおけば、Functionはそれを高速に読めます。実務ではこちらが第一選択です。
出典: About network access for Shopify Functions / About performance and resilience
できないこと・注意点
カスタムアプリでFunctionを使うにはPlusが必要です。非Plusのストアに個別対応するには公開アプリ化（審査あり）しか道がありません。見積もり前に必ずプランを確認します。
ランダム値や現在時刻は使えません。Shopifyは処理結果の再現性を保証するため、非決定的な動作を禁止しています。「毎回違う結果」「実行時刻で分岐」といったロジックは組めません。
ログでのデバッグができません。標準出力への出力は使えず、ログも1kBで切られます。本番で「なぜこの割引が出なかったのか」を追うのが難しく、テスト設計の重要度が上がります。
他社アプリのFunctionは参照できません。自社アプリのFunctionしか操作できず、他アプリのものを指定すると
Function not foundエラーになります。アプリ間の連携は成立しません。コードを動的に書き換えるアプリはApp Storeで禁止されています。「管理画面でロジックを自由に編集できる」タイプのアプリは審査を通りません。
出力20kBの壁があります。全商品行の一括価格変換には対応していません。
JavaScriptでの実装は性能リスクを伴います。Shopifyは公式にRustを強く推奨しており、大きなカートでの失敗リスクを明示しています。
Functionを削除すると完全に消えます。関連する設定（function owner）ごと永久削除され、インストール済みストアから即座にアクセス不能になります。復旧手段はありません。
実行順序は変えられません。「配送方法を見て割引を決める」といった逆順の要件は実現できません。
入力クエリのコスト上限30に到達しやすいです。メタフィールド参照は1つで3を消費します。
この機能で解決できる業務課題
Shopify標準にない販促ルールの実現 — 「まとめ買い割引」「会員ランク別価格」「特定カテゴリの2点目半額」など、標準機能では作れない販促を、決済フローの中で正しく計算できる
出荷・在庫まわりの業務ルールの自動化 — 冷凍/常温の分離出荷、拠点別の出荷優先順位、といった「これまで人が受注後に手作業で判断していたこと」をシステムに落とせる
誤注文の水際での防止 — 「1人5点まで」「離島には配送不可」などを購入前に止められる。受注後のキャンセル対応という後工程のコストを削減できる
決済・配送の出し分け — 高額注文での代引き非表示、B2B顧客への請求書払い提供など、リスク管理と顧客体験の両立
提案段階での実現可否判断 — 実行順序とリソース制限を知っていれば、「その要件はFunctionsでは無理です」を早い段階で判断でき、後戻りを防げる
Shopify Scripts の廃止とFunctions
非エンジニアが押さえておくべき背景として、旧来の Shopify Scripts（Plus向けのチェックアウトカスタマイズ機能）はすでに廃止済みです。
2026年4月15日 — Scriptsの編集・新規公開が停止
2026年6月30日 — すべてのScriptsが実行停止（すでに経過）
つまり現時点で、チェックアウトまわりのカスタマイズ手段は Functions に一本化されています。既存のShopify Plus顧客で「以前からのScriptsが動かなくなった」という相談があれば、それはこの廃止によるもので、Functionsへの移行案件として扱えます。移行対象の洗い出しには、Shopifyが提供する「Shopify Scripts customizations report」が使えます。
出典: Shopify Scripts will be deprecated on June 30, 2026
前回（2026-07-28）からの変更点
changelog を再確認しましたが、新規の追加項目はありません。最新は変わらず 07.24 の「無効なメタフィールドクエリがエラーを返すようになる（2026-10 以降）」です。
ただしこの 07.24 の変更は、本日のテーマとも接点があります。Functionsの入力クエリでもメタフィールドを多用するため、Admin API側でのメタフィールド絞り込み仕様の厳格化とあわせて、「メタフィールドに定義（definition）を正しく設定しておく」ことの重要度が上がっています。定義なしのメタフィールドに依存した実装は、Admin API側から順次弾かれていく方向です。
Functions領域で直近に効いている変更としては、6月13日の「Shopify Functions で Shop User メタフィールドが使えるようになった」があります。これ以降、新しいFunctions関連の破壊的変更は出ていません。
次回以降に整理する予定のテーマ
Webhooks と Events の使い分け・信頼性保証（shopify.dev/docs/api/webhooks） / 認証とアクセススコープ（OAuth・Token Exchange・セッショントークン） / Agents（shopify.dev/docs/agents） / Checkout拡張の制約 / Metafields・Metaobjects のデータモデル / App Store 審査要件と課金（App Pricing移行） / 新しい Discount Function API の詳細
未確認事項
ネットワークアクセスの可否表について、公式ページ内で「Shopify for enterprises」「Shopify Plus」の表記が混在しており、実際にどのプランで申請が通るかは Shopify サポートへの確認が必要です
「200行を超えると比例して緩和される」という記述はありますが、具体的な計算式は公開されていません。実際の値は Dev Dashboard または Shopify CLI でのローカル実行で確認する必要があります
25個までのFunction同時実行は、決済カスタマイズ・配送カスタマイズ・カート検証・出荷制約の4種が対象と明記されていますが、割引Functionが対象に含まれるかは明示されていません
Rust と JavaScript で実際にどの程度の命令数の差が出るかの定量データは公開されていません
Agents（shopify.dev/docs/agents）のリファレンスは本日も未着手