Function run log の詳細が 「適切な access scopes さえあれば」自動で見える

図解 ： Function run log details が access scopes で自動表示に Platform / Dev Dashboard Function run log の詳細が 「適切な access scopes さえあれば」自動で見える マーチャントに「ログを共有してください」と毎回お願いする必要はもう無い。アプリが必要なスコープを持っていれば、Dev Dashboard の function 実行ログ詳細が自動的に表示される。 このページの構成 30秒で要点 ： 何が変わったか 仕組み図解 ： スコープが鍵を握る 従来 vs 新仕様 の比較 3 種類のスコープ要求パターン トラブル時の確認手順 技術者が押さえるべきポイント 業務に活かせる3つのユースケース 提案で使える1行サマリ 1 30秒で要点 ： 何が変わったか Dev Dashboard 上の Function run log の「詳細」表示 が、マーチャントによる手動共有から 「アプリが持っている access scopes」によって自動判定 に変わった。 必要なスコープを満たしていれば、その場で詳細が見える。 従来 ： マーチャントに依頼 function run の詳細を見るために、マーチャント側で「共有」の操作をしてもらう必要があった。アプリ開発者の運用が依頼ベース。 新仕様 ： スコープで自動判定 function の input query が必要とするスコープを、アプリが GraphQL Admin API 経由で読めるなら、詳細は自動表示される。 2 仕組み図解 ： スコープが鍵を握る 判定の根拠は function の input query 。query が読むフィールドから「このログを見るには何のスコープが要るか」が機械的に決まる。 ＝ ログ閲覧権限と、本番で同じ function が実際にデータを読む権限が、 同じ rule で一致 する。 3 従来 vs 新仕様 の比較 項目 従来 新仕様（今回の変更） ログ詳細の閲覧条件 手動 マーチャントが共有する操作 自動 アプリの access scopes で判定 判定の基準 記載なし（マーチャント裁量） function の input query が要求するスコープ マーチャント依頼 都度必要 不要 反映タイミング — 必要スコープ付与後の 次回アクセス時 に自動表示 表示場所 Dev Dashboard Dev Dashboard（同じ） 4 3 種類のスコープ要求パターン 必要なスコープが付いていない場合、ドキュメントは 3 通りの取得方法を挙げている。用途で使い分ける。 常用 1. インストール時に要求 アプリが恒常的に必要とするスコープ。インストール／認証フローで宣言する。 用途 ： 標準動作で常に必要なフィールド。 保護データ 2. Protected customer data 顧客詳細・住所などは 追加の承認プロセス が必要な保護対象データ。データレベルのスコープも別途要求する。 任意 3. Optional scopes デバッグなど一時的な用途には optional scope を使う。 マーチャントが再インストール無しで付与／取消可能 。 5 トラブル時の確認手順 1 input query を確認 function の input query が読んでいるフィールドを洗い出す。 2 必要スコープと突合 そのフィールドを Admin GraphQL で読むのに必要なスコープを、アプリが保有しているか確認。 3 不足分を要求 恒常 ／ 保護データ ／ optional の 3 経路から最適なものを選んでスコープを取得する。 スコープが付与された後は、 次回ログにアクセスした時点で詳細が自動表示 される。再インストール等の追加操作は不要（optional scope の場合）。 6 技術者が押さえるべきポイント 1. 権限基準が「input query」に統一 ログ閲覧可否のロジックは function の input query から導出される。＝「本番でデータを読める権限」と「ログで見える情報」が同じ rule に揃う。 2. 顧客データは別承認が必要 customer details / addresses 等は protected customer data の承認プロセスとデータレベルスコープが追加で要る。一般スコープと別建てで設計する。 3. デバッグは optional scope が王道 恒常的に要らないが障害時だけ見たいスコープは optional として要求。再インストール無しでマーチャントが付与／取消できるため運用負荷が低い。 4. 反映は次回アクセス時 スコープ付与の効力は「次回ログにアクセスした時」から。即時リフレッシュの挙動については記載なし。再現テスト時はこのタイミング差に注意。 5. 「ログが見えない＝バグ」の前にスコープを疑う 期待した詳細が出ない時、function 側ではなく アプリのスコープ宣言 をまず疑うのが正しい順序。input query を読み直し、対応スコープがアプリの manifest に揃っているかをチェックすればほぼ解決する。 7 業務に活かせる3つのユースケース USE CASE 1 Shopify Function を載せたアプリの「障害対応フロー」改善 課題 マーチャント環境でだけ起きる function の挙動異常を、毎回「ログを共有してください」と依頼して、返事を待ってから調査していた。 打ち手 本番運用に必要なスコープを インストール時に過不足なく宣言 。デバッグ用途は optional scope として準備しておく。 効果 マーチャントへの依頼ゼロで Dev Dashboard から即時に input/output を確認 → MTTR を大幅短縮。 技術メモ input query が読むフィールドを棚卸しし、対応スコープをアプリ manifest に揃える。顧客系は protected customer data の承認も忘れない。 USE CASE 2 App Store 申請前の「スコープ妥当性レビュー」運用 課題 function を含むアプリの申請時、要求スコープが多すぎても少なすぎても審査・運用で詰む。判断根拠が曖昧だった。 打ち手 function の input query から逆算した「必要スコープ一覧」を申請ドキュメントに添付。 ログ詳細が自動表示される＝必要十分なスコープ揃い をレビュー観点に追加。 効果 過剰要求の削減（プライバシー印象の改善）と、運用後の「ログが見えない」事故の予防が両立する。 技術メモ protected customer data に該当するフィールドが input にある場合、申請とは別レーンで承認プロセスが要ることに注意。 USE CASE 3 「デバッグ専用」optional scope で運用負荷を下げる設計 課題 障害調査のために普段から強めのスコープを要求してしまい、マーチャントから「権限多すぎ」と渋られる／プライバシー監査で指摘される。 打ち手 本番要求は最小に絞り、調査時のみ要る分を optional scope として宣言 。サポート起票時に「一時的に付与してください」とマーチャントへ依頼するフローを SOP 化。 効果 恒常権限を最小化しつつ、調査時には Dev Dashboard で必要な詳細が見える状態を確保。事後に取消も可能。 技術メモ optional scope はマーチャントが 再インストール無しで付与／取消可能 。デバッグセッション開始 → 付与依頼 → 解析 → 取消、というルーチンに落とし込める。 8 提案で使える1行サマリ 「Function run log の詳細閲覧が access scopes で自動判定 に。 マーチャント依頼ゼロでデバッグでき、必要スコープは function の input query から逆算するだけ。 常用はインストール時／顧客データは protected／デバッグは optional の三層で最小権限を保て。」 source ： shopify.dev / changelog / function-run-log-details-are-now-automatically-visible-with-the-right-access-scopes published 2026-05-13 ／ generated 2026-05-23